Do-It-All protocol

Archive
#1

Hi guys,

I need for a commercial project that involve one (or more) master, and several slaves a protocol that is fast, that can discover new slaves automatically with unique ids, and that let slaves initiate dialog when data need to be sent back to the master.

I have studied in the past weeks several existing protocols, including 1wire, I2C, SPI and others. They all have some missing bits for my needs, either by design or because missing complete implementation in NET micro framework.
I know I could use a complete network protocol, like CAN but it seems a bit complex to me, just to exchange hardware data like buttons pushed or led colors though a bunch of wires.

To resume my Holy Grail quest:

  • single master needed, but multiple masters would be great
  • multiple slaves, that can initiate data sending to the master
  • new slaves can popup at any time on the network, hot plugged and with a unique ID. Each slave will have it’s own microcontroller.
  • fast, I need to exchange possibly camera stills later and fast acquisition data like acceleration or orientation.
  • all need to be connected in parallel on the same set of cables, like SPI, I2C, 1Wire, etc…

I do have in mind making my own bit banging protocol using parallel data and dedicated wires for hand shaking (something like 10 cables or so), I was just wondering if I missed something in the existing world of protocols? I’m a .NET software programmer, and even if I have some background in hardware and microcontrollers, I’ve been doing Windows programming for so long now that my hardware knowledge is a bit… outdated! :smiley:

Any advices?

#2

I would use a simple uart and implement a software handler to cover what you need. Take LIN fit for example, but you still do it in a simpler way.

#3

@ Gus - Ah! I missed this one. A sort of 1wire I believe after a quick look? I’m going to consider it, thanks for pointing it to me. 1wire from Maxim seemed good enough, but it’s the speed limitation that I’m a bit afraid of.

#4

One wire will be a problem. Just use uart with a transceiver to make it one wire… How I would do it.

#5

So with the UART solution, how do you avoid cross talk?

#6

So, using something like that, and talking to it using the serial line?

http://www.mouser.com/ds/2/302/TJA1021-843191.pdf

#7

hmmm… from the LIN documentation http://www.st.com/web/en/resource/technical/document/application_note/CD00004273.pdf

“Only the master is able to initiate a communication.”

Uh… that mean a new slave appearing on the network cannot say “I’m there”, the master have to check. Also, if the slave is a button it cannot broadcast “I’m pushed” to the master, the master have to pool all the slaves.

hmmm… looks like the same constraints as the 1wire protocol…

#8

tell us a little more about the network topology. the protocol you described is IP/UDP.

how is everything to be wired? how do you add/wire a new device? would Ethernet with hubs/switches work?

#9

Maybe LON. Check out. [url]http://www.echelon.com/[/url]

It can be a 2 wire protocol. Multi-master I believe.

#10

I guess CAN might work here.
Just saw you considered CAN already.
On SW side ist really simple.
Each message has it’s own ID, everyone can send at any time, listen to what you are interested in.
HW side, there are ready to use Transceivers, you could use CAN DW module as a template.

#11

@ Reinhard Ostermeier - Yea but he wants people to come and go randomly and have no previous address when they show up. This is a case for IP/UART!

#12

LON… a new one to check, thanks :slight_smile:

About CAN, I just had a quick overlook really and I guess it would fit the bill, I just need to add a hardware additional module to each slave, and I was hoping to do it all with only a single small microcontroller per slave. On the other hand, if I use most of the slave’s microcontroller IO, I’ll need another one to talk to the outside world, so a CAN module might be not a bad idea after all :slight_smile:
Also I might need a G80 as a master instead of the G30 I was contemplating to benefit from its CAN integration. This increase the bill quite a lot. But I could live with a more expensive master, I just need the slaves to be dirt cheap!

Ok, I’ll tell you more about the network. I cannot say about what it will do (very fun commercial project intended for consumers, still confidential for a while), but I can explain what it would need.

There’s a master, typically a .NET micro framework based microcontroller. I want that because I’m a NET Windows programmer by trade, and it’s so f… easy to program! :smiley: I have a Panda II and I enjoyed immensely tinkering with it a few years ago.
More than one master might be possible, but I would happily keep a constraint that make them behave as slaves to the master they are connected to, and as single master for their own connected slaves.

There’s slaves, possibly quite a lot. I could reasonably limit to 255 max if the identifier need to be a byte. Each slave have it’s own microcontroller, more or less powerful depending of what it do. Minimum a Arduino pro mini. There are present on the network when it is powered on, and one or more can be added to or removed from the network at any time. So they need to identify themselves proactively to the master. They can have their own unique ID recorded in their EEPROM.
Some slaves will be connected closely to the master, typically with a flat ribbon cable. Others will be at a distance connected in the wild with the cheapest cable possible (10 to 100 meters ideally). The external connection cable need to be readily available; plain home electric cable would be great, or RJ11 phone cable.
Some other slaves would be connected wireless, I’m not sure how right now. I guess with one of those cheap serial/WIFI module.

Some slaves will do about nothing, a simple button or a led, others will do a lot. Their cost and what they have as a microcontroller and I/O will vary greatly. But the simplest ones, like buttons, really need to have a very low cost. They all need to report their status to the master, and possibly receive commands to activate “things” connected to them.

There could be a mix of protocols, say a fast CAN or custom bit banging for the close slave modules connected by ribbon cable, one slower like 1wire for external modules, and serial for wireless ones. Of course having a single protocol to talk to them all would be even better!

The network can be completely proprietary, as well as the command format exchanged between master and slaves. I don’t really need to answer to any given existing protocol.
I don’t need any kind of “safety” for the transmission, checksum error check would be more than enough. Hacking into the signals might be part of the “fun” for users :wink:

Due to environment constraints, all modules, master and slaves will be potted in resin, making them hard impact resistant bricks. So I better pick the right hardware from the start :slight_smile: I plan to keep accessible the USB connection to upgrade the master’s software, but the slaves will loose any possibility of upgrade when manufactured. So the protocol they answer to, if it is not custom, must be reliable and stays compatible reasonably with future protocol versions.

I’m trying to grasp all that is currently done, but it’s so vast I could use some advices, about what to look at and consider.

  • I am hesitating so far between:

  1. Use a “standard” one or 2 wire protocol, but speed exchange and slave implementation for microcontrollers seem to be always an issue.

  2. bit banging my own parallel protocol internally on a flat ribbon cable, and use serial and a flavor of single or double wire protocol for external exchange.

  3. use a network protocol like CAN for all, even if it increase the bill.

  4. maybe I missed something?

#13

Then yes you need can bus. Use a bridge like a Nordic radio or Zigbee to connect wireless slaves.

#14

If I understand correctly what I read from CAN BUS Protocol, a new node can appear on the bus at any time as long as it is reading only the data, but to be able to transmit it needs an identifier unique to the bus. And dynamic allocation of this identifier doesn’t seem to be part of the protocol.

Say for example I have a master node reading/writing the bus, and 2 slave node buttons that are plugged to the bus. The buttons cannot know which identifiers are already used on the bus, and they must have different ones between them to be identified as separate buttons, even being the exact same module, on a physical point of view (a “button”).

This could have being solved with a large unique identifier like 1wire protocol, but the id in CAN being both “small” (11 bits standard, and 29 bits extended) and prioritized (low number = high priority), it cannot be a random unique id really. I’m not sure if CAN would solve my problem of having new nodes plugged at any time on the bus and identifying themselves.

Also, a maximum of 8 bytes for data is rather short, that mean to send a lot of data the header overhead of is quite large. CAN seem more oriented to a number of pre-determined nodes, sending a lot of small data, like for sensors… in a car :smiley:

But still, interesting… maybe there’s a way to do that “dynamic allocation” of identifiers on a can bus? Or extend the length of the data buffer transmitted? As it being done?

#15

guess a dynamic allocation is possible, yes :slight_smile:
I had that scheme in mind but it’s good to see that it has being done successfully:

CAN is on the top of my wish list now… thanks for pointing me again to it…

Now, about this rather ridiculous maximum amount of data… 8 bytes… :think:

#16

That’s because it was originally designed for automotive use where the data packets are small. You can break up your data into multiple packets if you need to send more than 8 bytes. It’s not really ideal for the likes of video or audio. It’s more of a sensor and/or control network.

#17

@ Dave McLaughlin - Yes, that’s what I understood. Thanks. I guess an additional protocol layer that break a buffer in small bits is nothing compared to redoing a whole hardware protocol from scratch :slight_smile: Anyway most of my needs will fit 8 bytes, Large data buffers will exist, must not that often.

I think I’m happy with using CAN, unless someone tell me about something else, or a flaw I didn’t see about it.
And my old Panda II seems to have it already, so I only need a small adapter to plug to an arduino for tests between them.

#18

@ DanielM - You need CAN tranceiver ICs to go between the µC and the physical wires to make CAN bus work. Those ICs add cost.

#19

@ Mr. John Smith - Could you please show me the kind of hardware that need to be added to a G80 TH Module or a FEZ Panda III to screw the twisted pair needed for CAN? They both have CAN bus, I thought the hardware was part of the uC.

Would it be something like that that need to be added to each CAN port from the uC?

1 Like
#20

Yes; spot on.

EDIT: And there is one last catch. You have to adjust the resistance of the devices on the network so that the total is ~120 ohms. It is however possible to connect devices using only schotty diodes, but I haven’t been able to get that working personally. I’ve gone through your pains before. Perhaps you will find a solution that I did not.