Low level control of USART - timing

Projects Programming
1

Hi folks,
I am currently trying to decide how to go about a project requireing a multi drop serial network.

There is much to think about and I have had some input in other threads but I now have a speciffic question with respect to usung the onboard USART for synchronious TX.

Is it possible to trigger a packet to be sent at a speciffic time, speciffic enough that several devices would transmit simultainiously allowing colision detection without corupting the data.

I am assuming that the baud defines the bitrate which is why I am asking about triggering the device to send its buffer content.

I appreciate that I am going to need a strategy to detect an handle colisions but first I have to understand/plan the hardware aspect of the task.

Interestingly X10 seems to work this way but it is tied to the zero cross of the AC signal which fixes the data in time ensuring all bits are encoded simultainously.

Any thoughts? would I perhaps be better doing this in software using interupts, which I suspect is what SoftSerial is doing.

Cheers,
Al

2

What problem are you trying to solve?

3

You can't do collision detection on Serial. You are thinking of the way that CAN arbitrates multiple senders so that the highest priority message "wins"? CAN must measure the voltage on the lines at several times during the transmission of each bit for this to work.

Serial is supposed to have one transmitter connected to one receiver. If you put two transmitters on the wire then they fight each other. There is no valid result - no way of saying that the MARK or SPACE will "win" the analog voltage level.

One obvious solution is "listen before transmit" but then each device would have to have both TX and RX wired together. That's not going to work because TX must hold the output in SPACE when it's not transmitting and the device trying to transmit can't overpower the local TX at the receiver. You just connected two transmitters to the one wire.

An RS232 converter chip with an "ENABLE" input can allow the transmitter to release the line for others to talk. It's best to use a master-slave protocol like MODBUS to control this as you still must prevent two transmitters from grabbing the line simultaneously.

4

I suppose that theoretically, you can queue up all your serial data in the FIFO buffer, but not enable the transmitted.
Then, in a pin-based interrupt ISR routine on all the prospective transmitters (all connected together), start the transmitter(s), and hope that various latency issues across the multiple chips don't interfere with them transmitting the same bits at the same time.

But I'm not sure what that would do for you.

5

Both good points, although I am not sure I agree with the , CAN only argument RE transmitters.
I apriciate that a USART cant be made to stop transmitting mid byte though, so in that context I would have to agree.
Also I do not know if a USART output is bypolar and if it is then again two transmitters would fail.
The upshot is that I cant argue with yoiur assesment in this context even if I dont entirly agree in general.
The point is well taken though and I hadnt considdered all the ramifications untill you mentioned it.

I have been doing some digging and I think I may have the basis of a solution, which should mitigate both your points, all be it without using the USART.

I have looked at I2C and discovered that it uses a synchronous system, having a clock line and a data line.
It also supports a stop command that releases the clock line allowing a different master to take control of the bus.

Now to be fair as a master slave architecture there is no collision detection in the spec and if were I to implement it then it wouldn't be I2C anymore but the bones of it are there and the wire library must already be handling all the timings and buffers.

support for multiple drivers sharing the same lines being the big pluss.

If I ignore collision detection for a while and work on the basis of passing a token to assign a master the only thing I would then need to address is a method of having devices listen to all traffic as opposed to packets addressed to them alone, effectivly adding a broadcast packet.

How complex is the wire library, do you think it would be practical to enhance it with a new packet type, extending the standard protocol?

Additionally do you have any suggestions with respect to making a by-directional buffer, level shifter?
The simplest option I can think of is to use 2 pins for both SCL and SDA, one to drive and one to sense that way I could use simple line drivers and loop them back without creating a latch.

I expect that I will need to find some way to detect if two masters attempt to talk but as that would almost cirtainly result in an abberent clock pulse length I suspect it isnt going to be too hard to manage.
I dont think it will be necessarry to plan on two devices talking, CAN esxque, as I can simply abort both if a bad clock occurs
Again your thoughts would be appriciated.

Thanks,
Al

6

Anyone pulled apart the wire library for any reason? a bit of insight would go a long way right about now.

Thanks,
Al

7

Dyslexicbloke:
Again your thoughts would be appriciated.

I would like to see an answer to the question in Reply #1.

Then it might be possible to offer useful suggestions. At the moment it is a classic XY problem

...R

8

The ATMEL USART does support a multi drop serial system. It does not need collision detection si

Serial is supposed to have one transmitter connected to one receiver.

is untrue.

Check the datasheet! The biggest problem would be to stop the IDE using the existing HardwareSerial class.

Mark

9

Dyslexicbloke:
Additionally do you have any suggestions with respect to making a by-directional buffer, level shifter?

10

Holmes4, thanks I wil look at that, however I suspect that me attempting to modify the IDE is probably a poor plan.

#1...
Home automation network.
Star topology from hub supplying power / data over cat5
Two protacols, well instruction sets... one to ssend mapping data that host will use to map instructions from input device id's to output device id's

Nodes will carry physical IO with speciffic cabilities...Devices will all be soft so that a physical input can be mapped to a command device, a physical output can be mapped to a driver device. A second level of mapping will have output devices listen for commands or status events and exicute either instructions from the command device or predefined actions based on the source of the trigger event.

There will also be a command processor on the network to interface with outside networks and execute none critical, but more complex scripts.

My model is Clipsal Cbus...just a little less clunky and allot more flexible.

Talking needs to be scheduled, by tokens not a single master and everything needs to listen all the time for instructions that apply to devices they host.
Buss control will need to be handed off to devices in turn to report status and some form of bus interupt will have to exist so that command devices can ask for control.

Much to think about but sorting out the hardware layer with sufficiant capabilities is the first step, because the network type will drive some of the decisions with respect to protocol implementation.

Does that help...

11

Coding Badly,
Looking to shift levels up not down but it hadnt occured to me to simply look for a board, good call thanks.
Buss supply will be 24V so it would probably make sense to define a relitivly hi low, as it were, to help with noise immunity and then a significant pullup to aid signal discrimination.

12

lots more reading and found this....

It would appear that I2C is going to do much of what I am looking for out of the box...
Granted the talk conflict folliwing a restart is clearly a problem for which someone far cleverer than me appears to have a solution to, all be it at the cost of a little speed, but as the artical states it only occurs if a restart is used and I can avoid that requirement.

So... the question is now changed somewhat.

Assuming I structure all nodes as masters and let the hardware vie for supremicy when I it has something to say then what I need to do is get anything not talking to listen on two addresses, one being its unique address, absolutely as normal and one broadcast address that it reads and buffers but doesn't ACC. At the same time the sender will need to ignore NAC when sending to the broadcast address.

I appreciate it is more overhead but I suspect sending all bytes twice will be the simplest way to detect and then ignore bad data. I also realise that I will have to handle devices failing to respond, at a high level, but that is whole other issue.

Does that sound plausible and if so has anyone got any idea how to go about hacking 'wire' to implement it?
Could it be as simple as duplicating the code line that recognises the address and adding a second alias.

Thoughts?

Thanks for the help thus far, just bouncing ideas is helpful because my own searches are better targeted.
Al

13

Your collision/conflict problems are easy to solve - just use a strict master slave system. The master tells the slave when to send somthing.

Think of it as a class room. Teacher point to the pupil who is to answer. the pupils never say anything unless they are told that they can speak!

As the pupils are not allowed to put up there hands the master has to poll the slave devices.

THere are other problems (normally with addressing with I2C.

Of course you could look at using USB as this avoids the addressing problems of I2C and multi drop serial (ie - the slave must know its address!)

Mark

14

OK, two problems with I2C:

  1. The bus was originally designed for very short distances between chips on the same PCB. It has a very high sensitivity to capacitance, such that a few pico-farads can wipe out the communication. I've never got it to work reliably more than 10cm although I have seen posts on this forum claiming more than 1m. It depends on the wire you use.

You can get bus-extender chips for I2C to increase the maximum length to 20ft (5m). That's not nearly long enough for a house-sized network.

  1. The Arduino Wire library can't switch between master and slave mode. Once you tell it that it's a slave then you can't switch to master mode. So far, nobody in the Arduino world has found that to be a serious limitation, so the library has never been updated to give it this capability.

One reason for that is it simply isn't very useful to have a multi-master network that's only 0.1m to 1m long.

Dyslexicbloke:
So... the question is now changed somewhat.

Assuming I structure all nodes as masters and let the hardware vie for supremicy when I it has something to say then what I need to do is get anything not talking to listen on two addresses, one being its unique address, absolutely as normal and one broadcast address that it reads and buffers but doesn't ACC. At the same time the sender will need to ignore NAC when sending to the broadcast address.

I2C does already have broadcast addresses built in. But I2C isn't really relevant to your problem because of (1) and (2).

For a house-sized network, I would recommend anything that uses twisted-pair. RS485, Ethernet, CAN, whatever. Use Ethernet cable to hook everything up because it's high quality twisted-pair that's really really cheap. You can get away with RS232 (unbalanced) but you still need a single master which polls the slaves to ask them if they have anything to say and the slaves must have a way of releasing the reply line.

15

OK all good points...

Length...

Now I haven't tried any of this so perhaps I am just buying into hype but I have found at least two chips, recommend by other folks, that the data sheets claim will operate over 20-50m of cat 5.
Looking at the datasheets it isn't quite that simple, the driver offering 50m is not isolating the bus capacitance, but uses beefed up active pulups with current sensor circuitry. This would mean that the entire circuit, all bus legs, has to be 50m or less

However there is another family of chip that uses level offsets to prevent latching of bi-directional buffers which does provide isolation, meaning each leg could be 20m or more.

HOWEVER I recognise that this constitutes jumping trough hoops and should be avoided if possible.
I am well aware that RS485 vis bullet proof, especially at low speeds, in fact I regularly use standard 1.5mm SWA cable over huge distances without an issue. The longest so far is 1.2km, which I did not expect to work, but it is fine, all be it fine at 9600 baud

Multiple masters...
OK I get that I am bucking the trend but considder...

With home automation even simple stuff you are talking about many devices. Granted you could group some together in a single addressable node, which I will, switch plates, output units and the like but still, many

If I go with a single master then one device carries the logic, the relationship between inputs' events and actions, for the entire system. If that master fails everything has failed.
In my case the wind turbine would shut down the solar charger would back off and the generator would fail to start.
Not good when you dont have a grid, and of course there would be no lights so I could see to fix it.

OK I appriciate that some of the systems could continue in some form of fallback mode and my world wouldnt end but the whole point of intigrated systems is to well, intigrated.

In a classic master slave architecture the master would have to ask everything in turn if it had any new data and then act on it, commanding output devices to do whatever was required. that could be several devices all of which would be sent simmilar if not identical commands

What I need is a way for everything on the bus to be aware of everything else with something to say, hence broadcast.
(I didnt know about I2C address 0 when I asked.)
Essentally every message would be a broardcast, some in resonce to physical input, a button press for example and some in responce to events such as confirming a command.

Of course to do that, without a single device looking after the scheduling, there has to be some strategy to either schedule who can talk or detect when there is a conflict, probably both, and it has to be a distributed solution.

Is I2C the right choice, possibly not but then neither is 485 at least not without significant work.
I2C, even using wire, should cope with conflicts if I avoid restarts and handle resending at a high level when a send has failed.

Nick Gammon Has done a load of work on this and even has code to fix, well almost, TWI.c

I note he describes code that allows a master to also listen for broardcasts or packets sent to it so no switching modes as the master is also a slave. (not sure if it would see loopback but I assume so.)

To be honest I am frustrated, part of me wants to start from scratch, hence the origional question.
I am also struggling to believe that there isnt some interface out there that will do what I want without all the mucking about.

So far, and I will be more than happy to take other suggestions, I2C is the best fit, all be it a poor one from a hardware perspective.
The fact that Wire is less than great seems like a poor reason to abandon a protacol with almost all the features I need and hardware solutions for the length problem.

I take all your points, and everyone elses, but so far I havent seen anyone suggest a workable alternative that will do the following...

Power, devices only not lights, over the same cat5 as the data.
unsolicited transmissions from everything, all masters or perhaps more accuratly no masters, just nodes that can talk at will.

I have even wondered about taking the I2C spec, or more likely an exixting soft I2C library and working with that.
For example if the clock and data both used 2 pins each, one to pull down the line driver locally and one to sense the line state then a simple buffer would not latch up since line side signals would not affect the drive state.
This would allow significantly harder pull up and drive current and mitigate some of the electrical limits imposed with a passive high state.

Perhaps this is why all the comertial products I know anything about all use propriatory networks...
How fast can I bit bang, perhaps soft is the way to go, its not lkle the conflict resolution is hard.

Anyone with a better plan, other than just have one master, please feel free to show me how silly I am being by missing something obvious.

Thanks,
Al

16

If a flake of metal dust falls across the terminals of just one of the devices in the network then the whole network is down. Why worry about a master failing when there's so many other failure modes that affect any node?

I went through the same dilemma designing a network a couple of years ago. I've got nodes on the network that were programmed 4 years ago and they work with the data provided by nodes that I didn't know about at the time and just designed last week. I thought that CAN bus would be the best solution but I was talked out of it. I still think that CAN would have worked for my requirement and yours. I ended up with lots of repeater nodes joining everything by RS232 and NMEA sentences.

If I was doing it again, I'd probably go with CAN. It seems about the right fit for a house-sized network where anyone can transmit anything and each device just watches to see if any data is useful for it.

Other alternatives would be Ethernet, using UDP broadcast packets or one of the other various standards out there. Ethernet is very robust - you have to get a direct hit by lightning to disrupt the network. If that's a risk, use optic fibres for the long segments.

Yes Ethernet and TCP have huge overheads - hundreds of bytes to send a single-byte packet - but it's totally necessary.