RetroBSD

2.11BSD operating system for microcontrollers
It is currently Fri Jul 19, 2019 9:06 pm

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Wed Jul 27, 2016 9:12 am 

Joined: Mon Jul 25, 2016 2:23 am
Posts: 2
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
TI MSP430Image
ARM Cortex M3/M4
(Possibly Atmel AVR UC3 - 32-bit)
PS: TI MSP430 was bought from http://www.kynix.com/Detail/1269546/MSP430F2232IDA.html
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 suck.

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.


Top
 Profile  
 
PostPosted: Wed Jul 27, 2016 10:09 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
While this is completely off-topic for this site I'm going to help you anyway.

So you want a point-to-multipoint network between MCUs. What MCU you choose is really irrelevant. Personally I would use PIC, but then I love PIC. Still, if you're not architecture agnostic these days then you're artificially limiting yourself.

Step one: make things easy on yourself: use the Arduino API. Most microcontrollers now have an Arduino implementation. That will allow you to write *one* system that can be used on almost any microcontroller.

Step two: make it flexible. If you can't decide what physical layer to use then don't choose a physical layer. Make it completely layered. Design your protocol so that it can work with any physical layer, and then write drivers for the different physical layers you want to support. Open it up and document it, so that other people can write new physical layer drivers to support other hardware.

Step three: don't re-invent the wheel. There's plenty of existing protocols around, some better than others, and some more mature than others. Take ideas and concepts, and even code, from other open source or public domain protocols. The best protocols follow the same concepts. There's the "OSI seven layer model" which is used as the structure for almost all protocols, whether they realise it or not. CRC calculations are pretty standardized as well, and so are authentication and encryption. The latter is getting more important these days, especially if you are thinking of having any form of wireless communication (there has been a lot of exposure of wireless keyboards that don't encrypt recently, for instance).

So, in summary: you're starting from the wrong end. Design the protocol in such a way that you don't care what MCU or communication medium is used. Be lazy and build on what other people have already done.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Wed Jul 27, 2016 2:34 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Jeremycc,

Nice post :).

This is almost exactly the problem I am working on right now for a new product design.

It seems to me that there are three [four?] types of data.

1. Minimal bandwidth. My conclusion is that single wire shared serial makes the most sense. Examples are knowledge network of the older IBMPC days and one we do NIWire.

2. Moderate bandwidth - 10base2 is a single wire standard and of course 10/100baseT is everywhere. My choice is SPI. Not many wires, simple and pretty fast. Direct CPU connection in many cases.

3. High bandwidth - Mostly used to drive displays. Frequently has a special direct connection to the CPU system.

4. DDR and other memory. Another special case :).

There really has not been a widely deployed standard since the original 8 bit IBM PC days. Curious to me?

Anyways, that is the direction I am going these days.

Single wire serial combined with SPI in a multi-master arrangement.

For a variety of reasons, for CPUs driving this sort of bus, bit banging makes MUCH more sense [to me] when you consider bus glitches, shorts and other commonly occuring fault conditions and how to detect and recover from them.

Slave design is much simpler. I happen to prefer PIC. But many families are trivial to interface to this sort of 'bus'.

Just my two cents :).

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Mon Aug 08, 2016 7:23 am 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Hi,

Personally I'd use an ESP8266 module for every node including the server. You can use the Arduino IDE as Matt stated in his post and reuse the same code for all your remote modules. They are really cheap, about £1.40 ea on ebay and come in a variety of formats, I use the ESP12 because of the amount of IO available. I have 3 currently running my heating system, one as a web server that stores the day and night temps plus drives the relay to turn on and off the heating. The other two are asleep for 5 minutes, then wake up, read the temp, connect to the server and upload the data then goto sleep again. Very simple stuff, very easy to implement and easy to solder. I love these devices, they're awesome and Espressif are making the ESP32 (at some point) which is twin core, lower power and has Bluetooth LE 4 to boot.

And yes, this is off topic and no it's not an advert :)

HTH, Dan


Top
 Profile  
 
PostPosted: Tue Aug 09, 2016 6:56 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Dan,

Is you method wireless?

It seems to me that wired is more reliable, repeatable and does not have the usual RF problems?

Wiz


Top
 Profile  
 
PostPosted: Mon Aug 15, 2016 7:20 am 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Hi wiz,

It's WiFi and connects through my home router, I've not had any issues at all with it since I installed it over 10 months ago. The web app is very light weight and works on everything, iOS, Windows Phone and Android. The comms is a very small JSON message with the temp being sent from the thermostat to the controller box. My wife loves it and it cost me about £40 in total to build. I'm going to add a night mode and upstairs thermostat soon as the temp upstairs is higher than downstairs and we want it cooler at night time as we all sleep better.

Try one out with Arduino IDE, they're dirt cheap and very reliable IMO. Oh and they can act as both a wireless access point and a wireless end point (usual device) simultaneously!

Dan


Top
 Profile  
 
PostPosted: Tue Aug 16, 2016 5:30 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
And the esp32 shall arrive soon, people say :)
I've got a couple of ESP-12F, for $4 in total incl. shipping, but still I do not know how to start :oops:

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Tue Aug 16, 2016 6:31 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
The NodeMCU is the best way to get into the ESP's...

Also use UECIDE's ESP8266 plugins :)

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Wed Aug 17, 2016 6:25 am 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
I second what Matt says, the NodeMCU boards are perfect for starting out as everything you need is on board. You can also use the Arduino IDE with the ESP8266 plugins, just google for 'esp8266 arduino' and check out the GitHub repo. I think you can also run python on these but not sure, again google is your friend here. I can't wait for the ESP32's to become available, I've been waiting in anticipation for over a year now.

I didn't know UECIDE also worked with the esp8266, I'll definitely give that a go, thanks Matt!

As an aside note on these devices I've used a LiPo with a charging board and powered the board direct from the battery (up to 4.1v) with no issues. Probably not the best idea but it's worked reliably for me and saved money on a buck-boost converter for the power supply.

HTH, Dan


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission