Add embassy-microchip HAL #4673
Conversation
felipebalbi
force-pushed
the
microchip
branch
from
9c3a53f to
dc12a65
Compare
|
Any suggestions as to why build fails with this PR? |
While at that, also disable platforms that won't compile due to incomplete PAC.
The new name matches other examples
caused by missing embassy package metadata. |
| if addr1 == 0 || addr2 == 0 { | ||
| w.set_gc_dis(false); |
There was a problem hiding this comment.
Only if config.addr1 == Some(0) || config.addr2 == Some(0)?
There was a problem hiding this comment.
Yeah, this is an interesting part of microchip's i2c controller. The thing is always acting as both slave and master. When working as a slave, it can respond to two different addresses. If any of those addresses is 0, then it can't respond to a General Call.
I will default to None and disable General Call by default, but that means own_addr above will write 0 to both addresses.
That being said, this condition here will likely remain the same because we only have to disable General Call matching when any of the slave addresses match the general call address (0)
There was a problem hiding this comment.
I thought it was the other way around, you set an address to 0 (and have gc_dis=0) for responding to general call?
The address ‘0000000b’ is the General Call Address. An Own_Ad-
dress of 0h will match the General Call Address unless this match is
disabled by setting GC_DIS in the Configuration Register
https://ww1.microchip.com/downloads/en/DeviceDoc/00002379A.pdf
There was a problem hiding this comment.
The way I read this is:
If you set address to 0, your device will respond to general call. If you disable general call (gc_dis=1), then you can respond to address 0 as if it were a regular slave address.
No?
There was a problem hiding this comment.
That's possible, but then there wouldn't be any way to configure it to avoid acking on address 0 (either with GC or regular slave interrupt status)? I'll check on hardware (cec1736) when I get a chance. It's not a blocker for merging this, can be adjusted later.
They seem super different from anything else, but the HAL can handle the differences internally, much like the various versions of IP blocks in STM32 family. If folks prefer a different name, I'll rename, no problem :) |
|
The reason why all the stm32's are in 1 hal is there is a ton of overlap between the chips.. Does dealing with the differences between all the families microchip currently own (avr, sam, kinetis, PIC32, mec17 etc) in a single HAL make things easier or harder? |
A real embedded controller MCU.