Support for CAN-Bus

[uLipe]

I see the module uses an overpowered stm32 microcontroller.

Since this is true, what about select a cheaper one like stm32g431, which has CAN and leave this possiblity besides the traditional serial buses, making this module networkable :)

[samuk]

@runger1101001 may have comment here.

Don't forget the existing modules which can be plugged in to add functionality. https://shop.m5stack.com/products/commu-module?variant=16804786896986

[runger1101001]

Hey, this is a very good comment.

Yes, the MCU is somewhat overpowered. And it is expensive. And it is big. But, we were trying to create a prototype quickly, and it was available right now (only 20pieces) and so I ordered it and have it.

The final design should be optimised to use a different MCU if possible.

But, on the other hand, I would also make the following points:

• having more pins available than strictly necessary greatly eases both enabling the functionality (for example I think I could still activate CAN-bus, pins are available I think) and the routing, since pins can be moved around the MCU to find the best spot
• so a smaller 80 or 100 pin MCU would be appropriate
• LQFP is big, but in the end I routed it with only 0.6/0.3 vias - switching to a smaller MCU with 80 or 100 pins would mean BGA, and probably microvias, maybe even 6 layers, and ultimately a more expensive board
• driving 2 motors with 6-pwm and current sensing requires quite a bit of MCU power, so a G4 is actually not too overpowered

In terms of functionality:

• adding CAN would definately be possible, but unlike the grove I2C port which comes at the price of the connector + 2 pull-up resistors, a CAN bus would need a transceiver IC, 5V power, choke/filter, termination selection, etc... and I can tell you right now the small size CAN transceivers are all out of stock; since the CAN-bus can be added using existing M5-stack modules, we made the design decision to leave it off
• personally, I would add a buck converter to the design. Since we already have high voltage coming in, we could power the M5-stack from the ESC board, and save the user having to buy a separate base module for this
• the current design is "networkable" via I2C bus. We could easily add SPI to this, the design already connects to the M5 stack SPI bus, we would only need to add some headers to make the CS-pins selectable to enable multiple modules via SPI.
• CAN only makes sense if the modules are far apart. I'm not speaking out against CAN here, I think it is ultimately better than I2C, but also more expensive. In the context of M5-Stack, doesn't it make more sense to have stacks of drivers, locally connected via the M5-header to a M5 Core, which talks to them via I2C. The M5 cores have WLAN, and can communicate with each other that way. I think this approach is probably more what M5-users would expect?

[uLipe]

All the comments above are reasonable, my point is to see the CAN-Bus as an additional, not a replacement from I2C or SPI.

The main point of CAN is the possibility to have an distributed network with bitrate higher than I2C, would be an option to route the CAN-TX + RX pins to solder pads and advanced users could stack an transceiver board if they have, I think would have some value to make this board "hackable".

The SPI option is great since it would allow to plug the m5 wiznet modules, allowing to make a true networkable, high-speed and maybe a microROS native motion module.

[runger1101001]

Ok, I checked the pins, and the CAN is currently blocked by BOOT0, which I haven't routed out anywhere though. I'm unsure if it is needed - normally not for either DFU or SWD programming... perhaps a question for the STM forums to be sure, I can't 100% say from the datasheet. There are also BOOT-bits that can be set via the flags, so that could be another option.

Otherwise if BOOT0 is needed it could be used in conjunction with a CAN transceiver that has an EN-pin. Then we could disable CAN until boot-up is completed, and the BOOT0 pin would not be in the way. I'll try to see what can be done here.

The pins for a 2-pin (no flow control) USART connection are available though, so I will route those out still, and then we will have the option of asynchronous serial or RS485 as well.

[samuk]

I think this is a wontfix for now so closing.