Giovanni wrote:- It should be named FDCANv1 as the current rule is that LLDs take the name of the peripheral (CANv1 is historically wrong, it should be BXCANv1).
- The number of RX and TX mailboxes is set to 1, I believe there are more.
- IO macros are not very efficient, it forces the compile to write and/or read the register each time because the volatile attribute, the preferred way is to prepare a variable with all values the do a single write (unless things need to be written is sequence separately which is sometime required). In general I prefer to read/modify/write explicitly.
Thanks for the feedback.
- I was unsure if it would be better to go in the direction of unification (support STM32F and STM32G in a single driver in the future) or separation. If I name everything FDCAN, all the LLD calling functions will then also need to be renamed as well in order to match the filenames, right? So can_lld_tx_handler will be fdcan_lld_tx_handler and then all the higher level interfaces will need to also be rewritten?
- Mailboxes is not a term that is even mentioned for FDCAN, should I kill it in the FDCAN driver? I hadn't figured out how to use the second FIFO. The feature which enables unmatched filter frames to automatically get pushed into a FIFO seemed interesting, however I suppose it's best to leave these choices up to the user. There are two RX FIFOs and a single TX FIFO\Queue (decided with the config register) on the G434. I haven't read the whole series' specs, but I think this holds for most of the series if not all.
- Understood, I went for readability\simplicity, but in this case it sounds worthwhile to consolidate reads\writes.
I'll make some more progress on this, what's the best way to contribute or post updates? I assume git isn't the best, but that's how I'll continue until I hear otherwise.