<firefrommoonligh> Is the `stm32-rs/bxCAN` crate full-up? I understand it's for the bxCAN used on F3/F4/L4 etc. Deciding if I should import it, or implement from RM.
<firefrommoonligh> * Is the `stm32-rs/bxCAN` crate full-up? I understand it's for the bxCAN used on F3/F4/L4 etc, and not fdCAN. Deciding if I should import it, or implement from RM.
<dirbaio[m]1> use it, can is super complex :P
<firefrommoonligh> Thanks - all I need to know!
<firefrommoonligh> Do you think modding it for fdCAN would be easy? Is the owner open to PRs?
<dirbaio[m]1> and it's also nice that multiple hals end up exporting the same api, same with the usb stuff
<dirbaio[m]1> hm
<dirbaio[m]1> is fdcan completely different? it might make more sense to have a new crate maybe?
<firefrommoonligh> Agree. I use that USB crate
<dirbaio[m]1> like with stm32-usbd vs synopsys-usb-otg
<firefrommoonligh> Don't know - I guess I should do my homework. I've no idea how diff the bx can and FD can are. fd is used on H7, G4, and L5
<therealprof[m]> CAN comes in different flavours/versions.... FD is the latest and greatest... https://www.st.com/resource/en/application_note/dm00625700-fdcan-peripheral-on-stm32-devices-stmicroelectronics.pdf
<firefrommoonligh> Thanks
<firefrommoonligh> AFAIK FD is used on L5, G4, and H7
<firefrommoonligh> Looks like per that doc G0 too
<therealprof[m]> Yes, it's a different peripheral. Not sure whether there's a CAN 2.0 compat mode, too, i.e. how backwards compatible it is.
<therealprof[m]> Yes, CubeMX also says G0.
<therealprof[m]> But CAN != CAN. The physical layer is only a small part of it...
<firefrommoonligh> Thanks for the info
<therealprof[m]> I haven't looked into CAN on MCUs too deeply (another project in my shame basket) but there have been tons of discussions about CAN in the embedded-hal realm a while ago.
<firefrommoonligh> Nice - I'll look at the prior art. I don't have a use case for any of my projects, but am looking into it to build the HAL, and so I can know when it would be the right tool for the job.
<therealprof[m]> Also not quite sure where bxCAN sits in terms of possible layers. But it's a supported project and jschievink is a valued member of the community, so I would expect good PRs to be more than welcome. 😉
<firefrommoonligh> Awesome
<agg> I think fdcan would probably have to be entirely its own crate
<agg> the FDCAN peripheral on the new STM32s fully supports the old CAN 2.0 protocol (which is all bxcan supports)
<agg> conceivably you could include support for the FDCAN peripheral in the bxcan crate but I don't know that there's very much overlap
<agg> (i.e., you could maybe add support for CAN 2.0 using FDCAN peripheral to the bxcan crate, so that at least the API and all the types and so on would be the same for either, which would be nice, and maybe not that much work)
<dirbaio[m]1> sounds like it'd be better to make a "can2.0" trait and have both drivers implement it? like with usb-device
<dirbaio[m]1> if regblocks are completely different between fdcan and bxcan
<agg> sure, and then other microcontrollers could also implement it
<dirbaio[m]1> which I don't know
<agg> if only we had some sort of central crate for such traits
<dirbaio[m]1> hehehe
<agg> (I jest, there's obviously been a lot of discussion in PRs on e-h about CAN)
<agg> probably now that bxcan exists and has had some attention, we could take its API and make it an e-h crate
<dirbaio[m]1> it'd probably suffer from the "lowest common denominator" problem hard
<dirbaio[m]1> you couldn't use all the fancy filters etc that bxcan has
<agg> and then yea, a new fdcan crate could implement it
<agg> eh
<agg> a surprising amount of that stuff is required by the spec
<agg> welllllll
<agg> I'm sure it would still be annoying
<agg> but maybe not as awful as you'd think at first. but, I've only used ST's CAN peripheral for anything serious, so...
<agg> (I wouldn't be surprised if other microcontrollers have the exact same synopsys can peripheral, actually, and bxcan could just work on them too with a different base address :P)
<agg> only 90/1000 nets left to route on this stm32h7 board and then i will also be trying out the fdcan peripheral so I guess I'll find out soon
<firefrommoonligh> Sounds like the next step is see if agg's suggestion on fdCan periphs in legacy mode is a quick add
<firefrommoonligh> Agree re least common denominator being an EH blocker
<timokrgr[m]> <agg "probably now that bxcan exists a"> aka https://github.com/timokroeger/embedded-can ;)
<timokrgr[m]> needs updating for the recent `try_` prefix removal and the `nonblocking::` namespace conventions
<firefrommoonligh> Is that intended to be a ready-now abstraction while waiting for the EH PR and release process?
<timokrgr[m]> yeah
<timokrgr[m]> progress on the e-h PR was very slow and people were using it already
<timokrgr[m]> so the suggestion came up to have it in a separate repo for now
<firefrommoonligh> I agree with your decision
dkm[m] has quit [Quit: Idle for 30+ days]
<firefrommoonligh> A skim of the L4 and L5 RM CAN sections and reg layouts confirm agg's intuition: fdCAN needs a separate module.
<firefrommoonligh> Even to operate on CAN2.0. The reg layouts are entirely different
<firefrommoonligh> Bummer
<firefrommoonligh> I've gone with a bxCAN dependency in the HAL, and ab leaving out g0, g4, H7, and l5 CAN support for now
<Albru[m]> here we go again... using the F4 HAL, what's the easiest way to change timer frequency so that I don't have to destroy the timer and create it every time I change it?
<Albru[m]> seems like pain to me
<chmanie[m]> I was wondering if there's any more documentation on the CircularBuffer used in this example (well, apart from the generated docs): https://github.com/stm32-rs/stm32l4xx-hal/blob/master/examples/serial_dma.rs#L71
<chmanie[m]> I am a bit confused on how to read the actual data in this buffer
<chmanie[m]> I thought I could just return `buf` from the closure but that's giving me lifetime issues
<GrantM11235> I think you can copy the buffer out of the closure by just returning `*buf`
<GrantM11235> Oh. That works in stm32f1xx-hal because the buffer is an array instead of a slice.
<chmanie[m]> That means I should clone it into an array?
<chmanie[m]> But I'm still a bit confused about the difference between `partial_peek` and `peek`
<richardeoin> thalesfragoso[m]: I've not tried the h7 sdmmc peripheral without the DTEN bit
<richardeoin> I'll try it now
<richardeoin> Hmm without that bit the datapath state machine gets stuck when running the ACMD13 here: https://github.com/stm32-rs/stm32h7xx-hal/blob/master/src/sdmmc.rs#L611
<richardeoin> that's the first command after changing the bus width
<richardeoin> I don't have any ideas as to why that might be
<richardeoin> indeed it seems the DTEN bit was copied over from the F4 sdmmc code
<richardeoin> or sdio as it's called there
<thalesfragoso[m]> richardeoin I implement it with DMA without the DTEN bit this past weekend, I managed to correctly initialize the card
<thalesfragoso[m]> Which uses data path transfers
<thalesfragoso[m]> But I changed a few things to support dma
<thalesfragoso[m]> One thing I found weird on the H7 HAL implementation is that you're reading the data on RX fifo half full, instead of RX fifo not empty
<richardeoin> hmm it waits for 8 words in the RX fifo, and then reads 8 words
<richardeoin> I don't see anything fundamentaly wrong with that, except that the total number of words must always be a multiple of 8
<thalesfragoso[m]> oh yeah, I missed the for
<thalesfragoso[m]> hmm, are you clearing the data end flag somewhere ?
<thalesfragoso[m]> not sure if it's needed though
<thalesfragoso[m]> hmm, looking at the manual it says you have to make sure the fifo is empty, to go from wait_r to idle
<thalesfragoso[m]> I remember seeing somewhere that you might need to flush the FIFO for it to go back to idle, a few things change with using the DTEN bit, so not sure
<thalesfragoso[m]> but I would guess something in the FIFO handling, since I'm using DMA and it's working, and the DMA handles the fifo