Can always roughly design both and go with whichever you think suits best. I’ve got tons of things I’ve designed over the years and never built or never finished, but I learned something from each of them.
True, true. Very likely possibility!
1 Like
I designed a lot of CAN communications in robotic trucks. I prefer sending a bunch of state periodically than any kind of send/respond. It just fits better with the CAN protocol. So you never depend on one message to get somewhere. One micro might be sending a bitfield with states related to idle, running, alarm, initialized, etc. The second might be sending values for X Y Z, etc.
For a sensor, Ideally it can fit everything into one 8Byte message. And just send everything all the time. If it can’t fit in one, then Ideally it can be split logically so each message stands alone. It would be less than ideal if X was in a separate message than Y, because they might be slightly out of sync on receipt. You could put stuff like error state in a separate message than XYZ position. Or play games like having a base position and then a more frequent offset from the base position to fit everything into smaller messages.
You should also use intel endian (little endian) if you have to cross a byte boundary. J1939 does that and that made it pretty much the standard for CAN. But you can do what you want.
It’s fun. But definitely trickier than SPI.
5 Likes
Gotcha! Sounds simple enough. I’ll mess around with that when I have time, but I’ll probably just stick with SPI for now while it works
1 Like