<dirbaio[m]>
and it looks nothing like the chibios table lmao
<dirbaio[m]>
* and it looks nothing like the chibios table lol... I wonder where they got their versioning from
<thalesfragoso[m]>
<dirbaio[m] "and it looks nothing like the ch"> Way more versions, is your parser considering it to be the same if all registers match ?
<thalesfragoso[m]>
> <@dirbaio:matrix.org> and it looks nothing like the chibios table lol... I wonder where they got their versioning from
<thalesfragoso[m]>
* Way more versions, is your parser considering it to be the same only if all registers match ?
<dirbaio[m]>
i've been scraping these XMLs and the C headers for peripheral addrs and interrupts
<thalesfragoso[m]>
yeah, those are important, why we can't get the addresses from the svd ?
<dirbaio[m]>
there are less SVDs than chips and I'm not sure how to map them
<dirbaio[m]>
and XMLs have more interesting stuff anyway
<dirbaio[m]>
all the GPIO AF mappings for all chips
<dirbaio[m]>
all the DMA stream/channel mappings too
<dirbaio[m]>
so maybe we can autogenerate all the `impl TxPin<UART3> for PC8` spam :D
<thalesfragoso[m]>
cool, we have some mapping for the dma streams in the F4 repo, not sure how they were made though
<adamgreig-m>
<thalesfragoso[m] "Maybe chibiOS did things semi-ma"> this is definitely how it worked, the chibios ones ignore a lot of small differences
<adamgreig-m>
presumably the xml files do not ignore the small differences?
<adamgreig-m>
chibios only needs the subset of bits that their drivers touch to be the same, then it pulls in the device-specific header and just relies on the names existing
<adamgreig-m>
<dirbaio[m] "maybe it means "designed for tsm"> yea, this would make sense, but does imply they are all fabbed at tsmc
<adamgreig-m>
curious anyway
<dirbaio[m]>
ah yeah, no idea what they manufacture where
<dirbaio[m]>
thoughts on having one "repo/project" for the yaml data and another for the "pac"?
<dirbaio[m]>
like, the yamls could be useful for more stuff
<adamgreig-m>
i'd defo keep the autogenerated svd2rust code out of the repo that has all the yamls
<dirbaio[m]>
reviews suck otherwise :)
<adamgreig-m>
in stm32-rs it just doesn't get checked in ever, there's the -nightlies repo you can depend on but otherwise it's built and published; in stm32ral i do check it in and it's a chore because it's so huge
<adamgreig-m>
(but stm32ral uses stm32-rs repo to get the svd files which works well)
<dirbaio[m]>
what about autogenerated yamls?
<adamgreig-m>
and a few other projects use the stm32-rs svd files that way too i believe? tinygo and some zig things maybe
<adamgreig-m>
dunno, depends how wordy they are I guess
<adamgreig-m>
or how generally useful for others
<dirbaio[m]>
huuuuge 😂
<adamgreig-m>
do they need to exist?
<dirbaio[m]>
I guess so :S
<dirbaio[m]>
there's yamls for each chip like this
<dirbaio[m]>
`peripherals` refers to another yaml that has peripheral addrs
<adamgreig-m>
yea, that would work, or the other way around and have the parent chip stm32f103.yaml contain a variant mapping that has the flash/ram details
<adamgreig-m>
you could possibly encode which pins are available in the package somehow
<adamgreig-m>
(I don't know you can do it just from your `package` key since it depends on package+chip I expect)
<dirbaio[m]>
yeah we have that info too :)
<dirbaio[m]>
it's in the xmls
<adamgreig-m>
yea
<adamgreig-m>
dunno what you'd use it for but I guess in theory the peripherals crate could only expose the singletons for the ports that are available
<adamgreig-m>
gets a bit messy with the pin remapping i guess
<dirbaio[m]>
so now it's "only" a matter of adding more regblocks and mapping them up
<korken89[m]>
Nice, reminds me of ChibiOS HAL
<korken89[m]>
He really nailed it with supporting almost all STM32s with little code
<henrik_alser[m]>
Regarding yesterday's i2c address nack hanging issue i just had time to look into it, turns out it actually bails out as it should first time AF ("acknowledge failure") is set but when you try to make another transaction it hangs forever. According to the f411 manual one must manually generate a stop (or repeated start) condition in the case of an acknowledge failure. So maybe we should add this?
<henrik_alser[m]>
(I guess this shouldn't be considered a "user responsibility" since it might be out of the users control if used within a driver through embedded-hal etc)
bob_twinkles[m] has quit [Quit: Idle for 30+ days]
<therealprof[m]>
<henrik_alser[m] "Regarding yesterday's i2c addres"> My brain fails me but I thought we already addressed clearing errors before returning? If there's more to do we should certainly add all required actions...
<henrik_alser[m]>
Yes it clears the error but the hardware is left in a faulty state
<henrik_alser[m]>
* Yes it clears the error but the pins are left in a faulty state
<henrik_alser[m]>
Hmm, just had another look with a scope and it seems to actually be ok with NACK errors, seems it hangs after ARLO errors.
<henrik_alser[m]>
Also when pullup resistors (internal or external) are missing it hangs in that while loop
<henrik_alser[m]>
Maybe the missing pullups is the problem, and might sometimes return ARLO and sometimes nothing?
<henrik_alser[m]>
(Btw, maybe we should add the posibility to use `internal_pull_up(true)` on AF4 type pins aswell (not only OpenDrain), since now you first need to make it a normal open drain pin and set the pullup and then turn it into AF4 if you wanna use i2c with the internal pullups)
<henrik_alser[m]>
* Maybe the missing pullups is the problem (like intermittent connection), and might sometimes return ARLO and sometimes nothing?
<therealprof[m]>
<henrik_alser[m] "Maybe the missing pullups is the"> Yeah, as mentioned, when the hardware setup is bogus anything could happen; part of the problem is a missing mandatory timeout in I2C so there're no good way to handle bogus signals on the wire, a glitch could also be interpreted as a valid signal or some bus participant stretching the clock ad infinitum.