crystal123
Newbie
I'd like to start implementing a system consisting of N microcontrollers (N >= 2 MCUs), but I would like to know the possibilities to let them communicate one with the other.
Ideally, (N-1) microcontrollers are placed inside the house acting as clients, while the last (the "server") one is connected to a PC via USB. The problems I have right now is how to connect these (N-1) microcontrollers to the "server". The clients MCUs perform very simple tasks, so it may not be a good solution to use ARMs to do such simple jobs just because they provide CAN / PHY-MAC.
The communication will not happen more than once every few minutes for most of the devices and on demand for others. The speed is not very critical (message is short): 1 Mbit/s I think is WAY overkill for my purposes.
The MCUs I plan on using are the following.
Atmel AVR Tiny / Mega
ARM Cortex M3/M4
(Possibly Atmel AVR UC3 - 32-bit)
[Moderator action: removed link to advertiser site]
I'd like to avoid PICs if possible (personal choice), simply because there are less possibilities to program them (all the above have more or less open source tools as well as some official tools).
I know some ARMs provide CAN functionality and am not so sure about the others.
Right now I came up with these possibilities:
Simple GPIO to send data (say > 16 bits at HIGH to indicate start of message, > 16 bits at LOW to indicate end of message). However it has to be at a standard frequency << (frequency_client, frequency_server) to be able to detect all bits. Only need one cable per client MCU.
RS-232: I think this is by far the most commonly used communication protocol, but I don't know how well it scales. I'm considering up to 64 client MCUs right now (probably more later)
USB: AFAIK this is mostly like RS-232, but I don't think it scales very well in this case (though USB supports lots of devices - 255 if I remember correctly - it may be overly complicated for this application)
RJ45 / Ethernet: this is what I'd really love to use, because it allows transmission over long distances without a problem (at least with shielded >Cat 6 cable). The problem is the cost (PHY, MAC, transformer, ...). I don't know if you can actually solder it well at home though. This way I wouldn't need a client MCU
Wireless / ZigBee: modules are very expensive, though it may be the way to go in order to avoid "spaghetti" behind the desk
RF modules / transceivers: I'm speaking of those in the 300 MHz - 1 GHz band, so they should be difficult to solder at home. The modules are all built-in, but they are quite as expensive as the ZigBee (at least the RF's modules at Mouser, at Sparkfun there seem to be cheaper ones).
CAN? It seems to be very robust. Even though I don't plan to use it in automotive applications, it may still be a good alternative.
I²C / SPI / UART? Again - better avoid "spaghetti" with the cables if possible
PLCs are not really an option. Performance degrade pretty fast as the length increases and depends on the capacitance load of the power network. I think price-wise is about the same as Ethernet.
Furthermore, which protocol would be "better" in case of simultaneous transmissions (let's assume the rare case that at the very same instant two devices begin transmitting: which protocol provides the best "conflict management system" / "collision management system"?
To sum it up: I'd like to hear what may be the best solution for a distributed client system that do very light data communication, considering both flexibility (max number of devices, conflict / collision management system, ...), price, easy to make at home (soldering), ... I'd like to avoid spending 20$ on just the communication module, but at the same time having 30 wires behind the desk would ****.
The solution I'm imaging right now would be to do basic communication between near MCUs by GPIO or RS-232 (cheap!) and use Ethernet / ZigBee / Wi-Fi on one MCU per "zone" to communicate with the server (expensive, but it is still a lot cheaper than one Ethernet module per each client MCU).
Instead of cables it may as well be possible to use fiber optic / optical fibers. Though additional conversions are necessary, and I'm not sure if it'd be the best solution in this case. I'd like to hear additional details on them.
Ideally, (N-1) microcontrollers are placed inside the house acting as clients, while the last (the "server") one is connected to a PC via USB. The problems I have right now is how to connect these (N-1) microcontrollers to the "server". The clients MCUs perform very simple tasks, so it may not be a good solution to use ARMs to do such simple jobs just because they provide CAN / PHY-MAC.
The communication will not happen more than once every few minutes for most of the devices and on demand for others. The speed is not very critical (message is short): 1 Mbit/s I think is WAY overkill for my purposes.
The MCUs I plan on using are the following.
Atmel AVR Tiny / Mega
ARM Cortex M3/M4
(Possibly Atmel AVR UC3 - 32-bit)
[Moderator action: removed link to advertiser site]
I'd like to avoid PICs if possible (personal choice), simply because there are less possibilities to program them (all the above have more or less open source tools as well as some official tools).
I know some ARMs provide CAN functionality and am not so sure about the others.
Right now I came up with these possibilities:
Simple GPIO to send data (say > 16 bits at HIGH to indicate start of message, > 16 bits at LOW to indicate end of message). However it has to be at a standard frequency << (frequency_client, frequency_server) to be able to detect all bits. Only need one cable per client MCU.
RS-232: I think this is by far the most commonly used communication protocol, but I don't know how well it scales. I'm considering up to 64 client MCUs right now (probably more later)
USB: AFAIK this is mostly like RS-232, but I don't think it scales very well in this case (though USB supports lots of devices - 255 if I remember correctly - it may be overly complicated for this application)
RJ45 / Ethernet: this is what I'd really love to use, because it allows transmission over long distances without a problem (at least with shielded >Cat 6 cable). The problem is the cost (PHY, MAC, transformer, ...). I don't know if you can actually solder it well at home though. This way I wouldn't need a client MCU
Wireless / ZigBee: modules are very expensive, though it may be the way to go in order to avoid "spaghetti" behind the desk
RF modules / transceivers: I'm speaking of those in the 300 MHz - 1 GHz band, so they should be difficult to solder at home. The modules are all built-in, but they are quite as expensive as the ZigBee (at least the RF's modules at Mouser, at Sparkfun there seem to be cheaper ones).
CAN? It seems to be very robust. Even though I don't plan to use it in automotive applications, it may still be a good alternative.
I²C / SPI / UART? Again - better avoid "spaghetti" with the cables if possible
PLCs are not really an option. Performance degrade pretty fast as the length increases and depends on the capacitance load of the power network. I think price-wise is about the same as Ethernet.
Furthermore, which protocol would be "better" in case of simultaneous transmissions (let's assume the rare case that at the very same instant two devices begin transmitting: which protocol provides the best "conflict management system" / "collision management system"?
To sum it up: I'd like to hear what may be the best solution for a distributed client system that do very light data communication, considering both flexibility (max number of devices, conflict / collision management system, ...), price, easy to make at home (soldering), ... I'd like to avoid spending 20$ on just the communication module, but at the same time having 30 wires behind the desk would ****.
The solution I'm imaging right now would be to do basic communication between near MCUs by GPIO or RS-232 (cheap!) and use Ethernet / ZigBee / Wi-Fi on one MCU per "zone" to communicate with the server (expensive, but it is still a lot cheaper than one Ethernet module per each client MCU).
Instead of cables it may as well be possible to use fiber optic / optical fibers. Though additional conversions are necessary, and I'm not sure if it'd be the best solution in this case. I'd like to hear additional details on them.
Last edited by a moderator:
