EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: JPortici on January 19, 2017, 01:59:56 pm
-
A board already in production have an expansion header because this was anticipated: There is need of a second MCU (almost ALL resources of MCU #1 were used)
At this stage:
MCU #2 has to communicate via canbus, asking and reading back from devices on the bus and communicating the values to the master MCU.
MCU #1 doesn't need to say much to #2.
I think a simple UART should be more than adequate.
In the future, however, MCU #2 will also have to do signal handling and manipulation and faster communication will be nedded from #1 to #2 and vice-versa.
For example, maps are saved in external eeprom, which can be accessed only by #1. Communication with computer host is also possible from #1 only
this is the scheme:
+------------+ +-------+ +-------+ +----------------+
| An/Dig IOs | | | | | | |
| EEPROM | /---\ | MCU | /---\ | MCU | /---\ | CAN |
| Host Comm | \---/ | #1 | \---/ | #2 | \---/ | Maybe Add. IOs |
| Port | | | | | | |
+------------+ +-------+ +-------+ +----------------+
and of course, much higher bandwidth would be needed, for example at startup when loading maps from eeprom to #2 using #1 as a buffer in the middle. what did you do in such situations?
Changing from UART or other standards at any point is possible as i have four reprogrammable pins (aah, the beauty of PPS)
*** the boards will be stacked on top of each other. i don't expect the comm traces lenght to be more than 5-6 cm ****
-
In my experience it will be faster and cheaper to replace the existing boards with a bigger MCU. If speed is already an issue now then you are in for a boatload of trouble. Communication will fail every now and then so you will need error checking, retries, recovery strategy, etc to make it reliable. With that in mind something trivial like reading an eeprom in another device suddenly becomes hard and takes a lot of code and CPU cycles.
-
SPI maybe.
-
In my experience it will be faster and cheaper to replace the existing boards with a bigger MCU. If speed is already an issue now then you are in for a boatload of trouble. Communication will fail every now and then so you will need error checking, retries, recovery strategy, etc to make it reliable. With that in mind something trivial like reading an eeprom in another device suddenly becomes hard and takes a lot of code and CPU cycles.
I know. Wish i could, but this particular MCU doesn't come in a bigger package and/or with more memory/more timers. changing family would mean having to emulate some peripherals in software (which i can do but it's a giant PITA) or migrate to a different core so basically rewrite the software from scratch
Speed is not really an issue here, i've just run out of pins/peripherals.
In case i stay with uart (and for example use crazy high bitrates over the Mbps at startup and more humane bitrates like 57.6k / 115.2k later) our network protocol is simple enough to not add much overhead and robust enough for detecting errors.
-
If you have an existing protocol which has proven itself then a large part of the solution is already there. Still I'd consider redesigning the whole thing with a larger MCU. It may seem like a lot of work now but in the end you'll have a much more future proof device and knowledge (so screws look like screws because you have more tools than a hammer). At least do a re-design where everything which needs to happen realtime does not need to be communicated over the bus.
-
At least do a re-design where everything which needs to happen realtime does not need to be communicated over the bus.
this is already happening
-
I know I'm very strongly opiniated about this but I've seen it going wrong too many times: Either to use microcontrollers people knew already and/or unclear design goals where the communication was some kind of 'catch all' afterthought. 8)
-
You could put the UART into 9 bit mode in order to allow sending of arbitrary data bytes and still have an unambiguous start of packet indicator. (Too bad common PC serial ports don't support it...)
Another choice is I2C which has built in packetization to begin with. It's also not sensitive to frequency differences between the two microcontrollers.
-
For two IC's UART is what I would recommend since it offers hardware parity and easy protocols when dealing with one-to-one communication.
If you have a one-to-many, then you use SPI.
If you have many-to-many, then you must use -unfortunately- i2c. It has very fragile physical layer, beware.
On the two latter ones you have to write some layers with checksums or parity.
You've already used CAN, but I would put CAN on the top of the list.
Will you be able to load the load the application in the secondary chip using jtag or a bootloader? You can't afford to manually program them and use two bin files, this will fail when outsourced.