Hardware CAN initialization fails

[taloman]

Hi @Phono

Before corona-apocalipsis, me and my team tried using CAN communication with a Bluepill for a proof of concept and managed to make it work using the adaptation from https://github.com/Phonog/Arduino_STM32.

I'm aware that it needs modifications from Roger Clark's original core (which was not desirable for us) and I think that's maybe the reason that it is not already merged into the main branch, so we parked until we needed to develop our project.

I see now that you managed to develop something new by using the HAL from stm32. This seems very promising because actually it was one of our alternatives. Is your "library" ready to be shared? Are your intentions to make a future PR to Roger's main branch? Is your new code hosted in github as well?

We are interested in knowing if your library could work with the current version of https://github.com/rogerclarkmelbourne/Arduino_STM32 and we are also available for testing with our hardware and give you a feedback or suggestions.

PD: I know that there are alternatives like using MCP2551 with SPI (this is our plan B) or also there are some trends about migrating to https://github.com/stm32duino/Arduino_Core_STM32 although for now this would mean putting some considerable effort, so for now, we would prefer to avoid the second one.

[Phono]

At the time I used Roger's core, I started from an existing HardwareCAN library from Maple that I ported to Roger's core, as you know.
Since i have decided to move to the "official" STM32Duino core, I needed a library that could not easily be derived from the previous one.
I have a set of four projects that communicate through CAN. The environment is fixed, so I do not need the flexibility of a full-featured library.
I thus opted for a simpler approach, limited to what I needed and that was not treated as a library for the sake of ease. Instead, I wrote a pseudo library that only consists in a single .h file, which contains the whole code for the CAN interface. This code in turn calls the HAL_CAN functions for actual CAN access.
So my code is easy to integrate in my projects, just using a "#include" statement. It has a fixed speed. It only uses the receive fifo0 with no filters.
As it is, it fulfils my needs. It is only 227 lines long and seems reliable.
In any case, I would think inappropriate to use an external CAN adapter if you use a STM32, with however the exception that with an external adapter you keep the USB serial channel that is inhibited when you use the CAN, at least on a STM32F103.

[mrburnette]

...
In any case, I would think inappropriate to use an external CAN adapter if you use a STM32, with however the exception that with an external adapter you keep the USB serial channel that is inhibited when you use the CAN, at least on a STM32F103.

I think, it "depends."
If you stay with built-in CAN, your code & architecture are locked into F103'ish paradigm, but for $0.87 qty 1 from Mouser, the MCP2561/2 represents greater options in the future plus moving the controller to a more sophisticated chip.

In the above scenario, your code is dealing with an external transceiver and nothing F103 centric, so moving the microcontroller to a different brand (for whatever reason, maybe an ESP32 for WiFi) is a lots less painful. For hobby project use, I think the STM32F103 is ideal, but if I were designing for commercial, then I want more choices.

Ray