Multiple microcontrollers intercommunication - Page 1
Forum section: electronics / projects

author: crispus
author_rank: Regular Contributor
timestamp: January 10, 2013, 03:50:06 pm
content: I have a project with these requierements:there are multiple microcontrollers (12+). Each microcontroller is responsible with a specific task.There is a master processor (it will run Linux) which will supervise all these microcontrollers. This has a few GPIOs.All microcontrollers will communicate only with the master.** Sometimes, a microcontroller should notify the master that something need its attention.Maximum distance will about 3 meters.** needed speed: 100kbps+** - not very important requirement.What protocol will be best for this situation? SPI, I2C, USART? There are others? What are the advantages and disadvantages?Thanks.

author: Kremmen
author_rank: Super Contributor
timestamp: January 10, 2013, 04:13:48 pm
content: SPI or I2C. Not USART since it is not a bus oriented specification. 3 meters should be doable relatively easily with either. Also 100 kbps is no problem.Some time ago just out of curiosity i bought the Elektor LabWorx 1 book which is Vincent Himpe's "Mastering the I2C Bus". Vincent is even a member of this forum ("free_electron" if i'm correct).If you wish to get familiar with I2C i can recommend that book. It is a very practical, down to earth dissection of the subject, and does not leave much out.

author: Deepak
author_rank: Regular Contributor
timestamp: January 10, 2013, 04:35:09 pm
content: I'm hardly an expert on the subject, but if you're controlling multiple slaves I think i2c would be easier.Can you describe the data a little bit?

author: senso
author_rank: Frequent Contributor
timestamp: January 10, 2013, 04:48:04 pm
content: I would use rs-485, or can, i2c is such a pain.

author: Kremmen
author_rank: Super Contributor
timestamp: January 10, 2013, 04:56:32 pm
content: Only RS485 is not a link layer protocol, it defines physical layer only. So you need to have some message framing, error management and transmission control on top of that anyway. You should not directly compare RS485 and say I2C because the latter does all of that. Maybe part of the pain comes from that?CAN would work but complexity and price wise it is far from the simplest, or?

author: crispus
author_rank: Regular Contributor
timestamp: January 10, 2013, 05:18:28 pm
content: Thank you all for the replies.Quote from: Deepak on January 10, 2013, 04:35:09 pmAlmost all the time, only one microcontroller is active (exchanges messages with the master, and do some stuff accordingly), and then goes idle. Then the master choose another microcontroller and so on.Sometime, a microcontroller should announce the master that something happened. This is not a strong requirement since the master can poll periodically every slave.The data exchanged are small messages: small data (up to 2-4 bytes), commands, read status, etc and I think should be some CRC added (from what I remember, there is no hardware CRC).The microcontroller will be STM32 ARM Cortex-M0.Quote from: senso on January 10, 2013, 04:48:04 pmI thought to CAN, due to differential transmission is better in hostile environment, but is significantly expensive. For RS-485 I will need extra circuitry, right? I have to keep the costs as low as possible.Because almost every microcontroller supports I2C and SPI, these are the easiest and cheap.I have some concerns for both of them:I2C: if something goes wrong, and one of the microcontrollers sends continuously messages, the whole bus will be unusable; with SPI I can isolate it;SPI: it will require more pins / wires - I can use something like a demux in order to select the desired slave...

author: JoannaK
author_rank: Frequent Contributor
timestamp: January 10, 2013, 05:26:43 pm
content: Some extra questions that may help or confuse.Is the price the key factor? Simplicity? Reliability? Expandability? Speed?Fixed system, or flexible design?Can/should the communication be with wires or wireless?If using Wired communication, should there be any isolation?How much time/money/expertise you have for implementing this system?Any legal, environment issues/requirements (EMI, Medical, automotive)Alternatives are plenty. And it's quite possible to hack one's own if the existing don't fit.

author: crispus
author_rank: Regular Contributor
timestamp: January 10, 2013, 05:45:29 pm
content: Quote from: JoannaK on January 10, 2013, 05:26:43 pmIs the price the key factor?YesSimplicity?Yes, if possibleReliability?YesExpandability?NoSpeed?No. All the messages are short.Fixed system, or flexible design?Fixed.Can/should the communication be with wires or wireless?Wired, is cheaper, right?If using Wired communication, should there be any isolation?I think no, since all of them will be powered on from same source.How much time/money/expertise you have for implementing this system?as less as possible / as less as possbile / none (yet).Any legal, environment issues/requirements (EMI, Medical, automotive)The only issue could be the electromagnetic interference.

author: ballanux
author_rank: Contributor
timestamp: January 10, 2013, 08:23:19 pm
content: I would use RS485 with modbus protocol. It's very simple and meets all your requirements :-)

author: AndyC_772
author_rank: Super Contributor
timestamp: January 10, 2013, 09:42:14 pm
content: If you have a defined number of slaves, and enough I/O pins on your master microcontroller, I might be inclined to suggest putting every slave on its own I2C bus. This avoids having to give each one its own address, and means if something goes wrong with one then it can't break communication with the others.

author: Deepak
author_rank: Regular Contributor
timestamp: January 10, 2013, 10:08:58 pm
content: Quote from: AndyC_772 on January 10, 2013, 09:42:14 pmIf that's the case, then SPI might be the better way to go - since it's higher throughput and doesn't require pullups. Even if he's polling the to see if a MCU requires attention I'd think the power consumption would be lower than i2c.Both are protocols are supported in the linux kernel so that's a wash.

author: M. András
author_rank: Super Contributor
timestamp: January 10, 2013, 10:21:30 pm
content: sorry to interrupt, i have a simple question regarding SPI, is it possible to multiple devices send data simultaneously?

author: jerry507
author_rank: Regular Contributor
timestamp: January 10, 2013, 10:29:30 pm
content: 3 meters, don't use SPI. It is possible yes, but unless you know how to design it properly (mostly terminations at that length), it'll be a PITA.I'm a HUGE fan on CAN. Assuming your STM32 has built in CAN, all you need is a MCP2551 and you're good to go. They're $1.12 off digikey. Yes, you'll need to figure out how the module works and know something about the link layer but it's fairly simple. Addressing and CRC are built in.Just my 2 cents.

author: ballanux
author_rank: Contributor
timestamp: January 10, 2013, 10:38:48 pm
content: Although I2C can work at 3m distances if you use a driver, it isn't a field bus and shouldn't be used in this application, the same goes for SPI. 485 is cheap, easy and reliable. You can put your nodes 3 or 30 meters apart and they will work fine. Also, the modbus protocol is very simple to implement in software.Quote from: M. András on January 10, 2013, 10:21:30 pmSimultaneously, no. You have to communicate with one device at a time. Same goes for I2C and 485.

author: JoannaK
author_rank: Frequent Contributor
timestamp: January 10, 2013, 10:45:58 pm
content: Quote from: ballanux on January 10, 2013, 10:38:48 pmTechically, if you have 12 SPI buses (or i2c or uart) at the main controller ... But I doubt those come cheap.

author: Smokey
author_rank: Super Contributor
timestamp: January 10, 2013, 11:23:42 pm
content: If speed isn't that big of a deal, you can always implement 12 software i2c (or something else) ports. No one said it had to be pretty.

author: ballanux
author_rank: Contributor
timestamp: January 10, 2013, 11:51:49 pm
content: Quote from: JoannaK on January 10, 2013, 10:45:58 pmthat also wouldn't be simultaneousmostly because you would need to bit bang the data in software and there would be a big delay between one bus and anotherand having 12 spi or i2c busses would be a great mess. much more problematic that just one bus with 12 addresses. ...

author: free_electron
author_rank: Super Contributor
timestamp: January 11, 2013, 12:40:31 am
content: bitbus ? (IEEE-1118) been around for ages and is proven technology. can be run over multiple physical layers. Intel invented this long ago and released it as an IEEE standard.Bitbus is heavily used in industrial systems for robotics and factory automation because it is so robust. google for IDCX51 . IDCX51 is a fully deterministic RTOS that can handle 8 tasks (task 0 to 7 where task 0 is the bitbus node ) and compiles to about 2K of code. it supports interprocess communication between local tasks but also between local and remote tasks ! in other words this is a true distributed processing system. A 'function' does not need to reside in the local cpu but can be handled by another bitbus node. Bitbus is available on 8044 , 80152 and a number of motorola processors but you can implement it in almost any cpu.http://www.alfirin.net/flamer/bitbus/Or simply use the nine-bit uart mode.What is the principle ? the UART has a 9-bit mode where the ninth bit defines 'address/data'. any 8051 has a usert that can be switched in this mode , as do many other processors. it allows for very efficient multiprocessor systems with mnimal overhead.every 'slave' gets a unique address. The master sends the first 'byte' containing the address with the ninth bit set to 'address'the slave for which the address matches captures the datapacket and replies if so requested.The trick sits in the uart and the ninth bit. you can program the interrupt controller in such a way that an interrupt is ONLY generated upon reception of an ADDRESS packet AND if the address MATCHES yours.this means your CPU only gets interrupt if something comes in that is meant for it. ( there is a general call address as well i believe )Upon reception of that interrupt you switch the interrupt handler temporarily to 'any' received byte until the full packet has been received at which point you switch the interuupt controller back to 'address matching.this limits the receive routine. your cpu has almost zero overhead to get messages.

author: free_electron
author_rank: Super Contributor
timestamp: January 11, 2013, 12:58:49 am
content: Quote from: ballanux on January 10, 2013, 10:38:48 pmThat depends. if you use the IPMI and ATCA layer it becomes a field bus. Especially ATCA is a true fieldbus. there are whole telecoms racks with hundreds of boards in them all interconnected via ATCA which uses redundant I2C as its base layer. This is fully hot-swappable and fault tolerant and supports multiprocessor communication in an efficient way.ATCa is a standard and is used by many big hardware makers usch as Sun , Cisco , Alcatel , and many others. It is used for power control and system management. You also find it in large filers such as Netapp and EMC data warehouses. where it monitors each and every drive across multiple chassis.

author: nctnico
author_rank: Super Contributor
timestamp: January 11, 2013, 01:07:55 am
content: Quote from: Kremmen on January 10, 2013, 04:13:48 pmActually the UART is by far the best solution because a UART has filtering for spikes cause by noise so you'll get a framing error. Use it with RS485 transceivers and a simple bus-master protocol to make a rock solid system.

author: poorchava
author_rank: Super Contributor
timestamp: January 11, 2013, 09:27:42 am
content: +1 to Modbus over RS-485. This solution has few merits: it's dirt cheap (rs485 transceivers are cheap and made by dozens of companies) and relatively immune to noise thanks to differantial signalling.I would add a small change though: since modbus does not support communication initiation by slave, you could add OR-ed (either 7400 OR or diode-or) or multiplexed interrupt line. This way the main processor will know when something happens and immediately react. This will also save processor time, which would be wasted with modbus polling.

author: Alana
author_rank: Frequent Contributor
timestamp: January 11, 2013, 09:40:26 am
content: Quote from: free_electron on January 11, 2013, 12:40:31 amInteresting idea for one of my own projects. With board-to-board voltage levels like in typical RS232 it should withstand the hostile environment of model railway

author: Kremmen
author_rank: Super Contributor
timestamp: January 11, 2013, 01:07:46 pm
content: Quote from: nctnico on January 11, 2013, 01:07:55 amWell, i don't know about filtering. As far as memory serves, the USART specs i can recall do not mention anything like that. Framing error sure but that has nothing to do with filtering.My original point in not recommending USART was that it is just a way to send bytes across, not a multiple access link specification that the OP asked for. I2C is that kind of spec and SPI to some extent. Now i admit that i didn't remember the 9 bit mode of USART since it's been a while since i last did anything with it. Combined with RS485 physical layer bus it would be the best solution as far as EMI tolerance and transmission distance is concerned. You still need to design the message framing, bus access control and error recovery, but those have all been solved many times in the past. Surely an existing implementation can be found that fulfills requirements.

author: jerry507
author_rank: Regular Contributor
timestamp: January 11, 2013, 05:03:25 pm
content: Yes, they're all solved in hardware by a CAN module in a micro. Someone elses implementation will always require some work, but the hardware modules are typically more simple than implementing someones software layer.

author: AndyC_772
author_rank: Super Contributor
timestamp: January 11, 2013, 07:48:43 pm
content: Quote from: Kremmen on January 11, 2013, 01:07:46 pmTraditionally, the way a UART works is that it samples the incoming stream at 8x or 16x the baud rate, works out the start position of each bit by looking at where the transitions occur, then decides the value of each bit by taking a majority vote out of the 3 samples nearest the middle of the bit. Short duration noise spikes are supposed to get out-voted provided they only affect 1 out of the 3 samples.

author: Kremmen
author_rank: Super Contributor
timestamp: January 11, 2013, 11:42:42 pm
content: Yes yes but that is sampling, not filtering.