Using an input clock-line and input resistors...

[Grogster]

Hi all.

I want to connect several DIFFERENT PICAXE's to a common control line, but just connecting the inputs(via the resistors) to the line, will muck up the resistor value, unless you know exactly how many are going to be connected - the resistors in parallel(via the bus cable) thing.

So I just want to put a 914 in front of each input - see the attached GIF file.
http://img27.imageshack.us/img27/5118/picaxeclocklineinputse.gif

This seems to work fine on the breadboard, and each input keeps it's 10k across the input to deck, but I would like others here to make sure I am on the right track with this, as there will be up to 12 seperate units on the one line.

What happens, is that each PICAXE that wants to send it's message checks this line to see if it is active, and if it is, then that unit knows that another unit is talking on the data-bus, so it waits before trying again(in an endless loop) until it sees this line is inactive, then it sends it's message, after first pulling the control line high itself, to signal to any others that IT is now using the bus(therefore, the others then wait, if they want to talk too).

Very simple, but effective, and works brilliantly on the prototyping breadboard and setup to prevent any data-collisions(with four picaxe's), even if I deliberately set two off at the same time, my only concern is basically if there is a limit to how many I can couple up like this - if I can get my 12, i'll be happy. Essentially, I am trying to decide if I can go ahead, without actually building a network of 12 to play with, and based on the testing of 4 or so, it should be expandable out to 12 without any major problem, correct?

Each unit only sends 6 bytes, so there should be no problems with long messages.

 

[BeanieBots]

I'm a little confused between your text and your diagram.
Is the "common line" driven by just one PICAXE output?
Are the outputs of that circuit going to PICAXE inputs?

If yes to both, then no need for all that circuitry at all.
Just connect all the inputs together and connect to the single output.
If you are concerned that one or more of the inputs can become an output, then just put a single resistor between input and common line. (1k to 10k).

If all the connections on the right are outputs, that circuit won't work at all.

Maybe if you were to draw the complete diagram (only a few channels required, not all twelve) clearly showing what are inputs and what are outputs it would be clearer what you are trying to do.

 

[Dippy]

I'm a bit confused too - but, in my case, that's not difficult

Basically you have a rectified input to each PICAXE to smooth the serial data for easier detection.
I can understand that. Though adding more like this could affect signal shape.

This assumes I have got the "Coomon Input Line" as your 'bus' from PICAXE Serial Outputs?????

Does this mean you have an extra line to each PICAXE for a proper Serial DATA In?

And an extra Serial Out from each PICAXE to put data on 'bus'?
If so, there could be problems there if the other PICAXE's pins are in output mode.
The solution is quite easy but depends on which PICAXE i.e. the pin config.

I agree with BB, more description (but not more PICAXEs) is required.

 

[Grogster]

OK, sorry for the confusion.

The "Common input line" is a single core in a multicore cable, connected in parallel to every "Node" on the serial-bus cable.

The line is held low(via a 560R resistor) at the processing end of the bus, so is normally-low.
Each node can pull this common-line high when it wants to send data along the serial bus, and it first checks that this line is low before it tries to send - a high present on this line, indicates that another node somewhere else, is currently transmitting serial data on the bus, and so that node then waits and repeatedly polls this line until it is low, meaning no other nodes are using the bus, and it can then transmit it's serial message. It is important to understand that I am NOT sending serial along the common-line in the diagram - it is just on/off logic.

Serial comms are sent out on an output of each chip, diode-gated to the bus as explained to me by other members here on another thread, and the serial line uses another core in the cable.

My original problem was resistors in parallel.
If I connected up 12 odd standard input resistor arrangements across a common bus cable, all the 10k resistors get connected in parallel across the cable, and this ends up being something in the order of 200R/1k or so at each input, so it is not suitable. I want to use diodes on the input, but before the resistors, as in the diagram, to isolate each node's input from the bus, essentially, so that each node still has the 10k/1k input resistance, without the problem of lowering the effective input resistance, if they are all connected together.

 

[Dippy]

OK, so "Common Input Line" is really a "Busy" or "Data Being Sent" line?

You have 2 other wires for Rx & Tx, or just a single line for Rx&Tx ?

Sorry, I'm still confused.
If this Busy line is simply connected to all PIC inputs then the resistance is the paralleled compound of all the Res+PIC Input Impedances.
If so, then you simply have the fan-out limitations. Can't be sure without a drawing.

Ah well, you know what you're doing and if it works then go with it.

 

[Grogster]

OK, so "Common Input Line" is really a "Busy" or "Data Being Sent" line?

You have 2 other wires for Rx & Tx, or just a single line for Rx&Tx ?

Sorry, I'm still confused.
If this Busy line is simply connected to all PIC inputs then the resistance is the paralleled compound of all the Res+PIC Input Impedances.
If so, then you simply have the fan-out limitations. Can't be sure without a drawing.

Ah well, you know what you're doing and if it works then go with it.

Yes, BUSY line - that's probably a better description then mine!!!!


Just Tx - none of the nodes need to Rx, as they auto-Tx every couple of minutes if not reset.

Guess I will have to do a better drawing...


I will try to do this ASAP, and upload so you can get some clarification.
It will be two-node only, and block-diagram type, but I will show the lines and the inputs and outputs so you can see what I am trying to do - again - sorry for the confusion...

 

[Grogster]

OK, here is a block-diagram of how things are setup:
http://img200.imageshack.us/img200/5904/picaxeclocklineinputsbl.gif

 

[hippy]

For a single busy ( "someone is transmitting" line ) that seems overly complicated to me. I'm not sure why you need parallel R's.

All that is needed is a single common busy line pulled-up at a single point with an R (4K7?). Every PICAXE reads the line and if high knows it can transmit, if low knows someone else has the line and waits.

When a PICAXE comes to transmit it sets its input as a low output, so now every other PICAXE will see that the line is low. Any number of PICAXE's can do this without electrical contention, the danger is if one sets its output high. To overcome that, and for PICAXE's which do not have input-can-be-output pins, use one pin always as input, and a separate output diode-mixed to the busy line ( pointy end towards PICAXE ) and keep the output high when not got the bus, low when it has.

A single 'busy' bus is not absolutely reliable. The problem comes when two or more PICAXEs happen to synchronise up. Both read the bus see its low, and both think they can have access to it. Sod's Law says you'll never see a problem in testing, but it will be a major one when deployed.

 

[moxhamj]

Yes, this is very confusing. Especially this The line is held low(via a 560R resistor) at the processing end of the bus, so is normally-low.
Each node can pull this common-line high when it wants to send data along the serial bus, and it first checks that this line is low before it tries to send - a high present on this line, indicates that another node somewhere else, is currently transmitting serial data on the bus, and so that node then waits and repeatedly polls this line until it is low, meaning no other nodes are using the bus, and it can then transmit it's serial message. It is important to understand that I am NOT sending serial along the common-line in the diagram - it is just on/off logic.

Ok, leave aside all the serial data for the moment, because that is even more complicated again. For the busy line, every node can pull this high, right? That is kind of the opposite of the arrow in the picture which goes into the picaxe implying it pulls the line low. Actually it doesn't really matter whether you pull a line low or high - all that changes is whether you use a pull up or a pull down diode.

Start with a common bus. Connect nothing to it. It will float, ie have an undefined voltage. You want it to rest low, and be pulled high, right? So, pull that bus low with a single 4k7 resistor to ground.

Now add a node. Use a 914 diode. Pointy end to the bus. If a picaxe pin goes high, it makes the bus high. Add more nodes with diodes. Now any picaxe can put the line high. If more than one put the line high, then the line is still high. This is a "wire OR" gate. It is the same logic as an OR gate. Indeed, you could use multiple OR gates if you wanted instead of diodes.

(Hippy's answer above is the opposite and is a wire-AND solution. Both are equally valid. Indeed, I built an 8 input wire-AND circuit just today)

Next problem, sensing the bus. Can you spare a different pin to sense the bus, or use the same pin. The latter can be done but needs some more components.

Not sure about the capacitor in the circuit, what does that do?

And, having done all that, it still won't work 100% reliably, for the reason that Hippy says.

And if it is not 100% reliable, then you will eventually end up in a serin hang situation (for inputs) or data packets clashing (for outputs).

So, if that is going to happen, you may as well design for it anyway. And if you do that, then you don't need the busy bus.

Many on this forum have pondered this issue.

A few solutions:

You can keep the packets short, wire-or the data packets onto a data bus and send packets several times to make sure they get through. Works up to a point, until the traffic gets too busy.

You can reset nodes and then only one node can transmit.

You can have a 'token ring', and only the node with the token can speak. This was used in early computer networks. You do need some code though if the token gets dropped.

You can transmit slowly using systems that don't use serin, and avoid the hang. Eg morse code type speeds and poll two or more inputs at the same time (and read data from both at the same time. And buffer data from inputs at the same time too)

You can have a master clock that polls around the picaxes in turn, and picaxes can only talk when the clock says they can (cf the internal structure of the Propeller chip). Not that hard to implement with logic chips eg a couple of 4017 chips daisy chained and a 555.

And there are more methods too.

At the most fundamental level, the problem is that the picaxe can't listen to two (or more) serin inputs at once. Other chips can but not the picaxe. If you can't do that, you can't build a router, and this is the fundamental building block of a router. (Plus you need a buffer for each input.)

I think if you have multiple nodes, and each node is only ever transmitting, and you want 100% reliability (not 99.9), it could be worth looking at the 'reset' solution where a master controller resets picaxes and then the picaxe sends its data when it is reset. But that won't work if the system has 'urgent' data on particular nodes.

More info on the application would be most helpful...

 

[Grogster]

Oh dear...
Every attempt to clarify things seems to be confusing you all even more...

hippy wrote:
When a PICAXE comes to transmit it sets its input as a low output, so now every other PICAXE will see that the line is low. Any number of PICAXE's can do this without electrical contention, the danger is if one sets its output high. To overcome that, and for PICAXE's which do not have input-can-be-output pins, use one pin always as input, and a separate output diode-mixed to the busy line ( pointy end towards PICAXE ) and keep the output high when not got the bus, low when it has.

This is essentially how I have done it - one input pin reads the busy line, and another seperate output pulls the busy line high, if the input pin sees that it is low. There is a 914 diode(pointy end to busy line in my case) between the output and the busy line, to block any high on the line coming back into that node's output pin.

Dr_Acula wrote:
Ok, leave aside all the serial data for the moment, because that is even more complicated again. For the busy line, every node can pull this high, right? That is kind of the opposite of the arrow in the picture which goes into the picaxe implying it pulls the line low. Actually it doesn't really matter whether you pull a line low or high - all that changes is whether you use a pull up or a pull down diode.

Yes, every node can pull the line high.
I sucessfully confused you all again with the arrows, which were meant to show the flow of things - arrows into boxes are inputs, arrows out are outputs.
I should have put that in text a'la the on-board regulation thing - sorry - my bad everyone...

Dr_Acula wrote:
Start with a common bus. Connect nothing to it. It will float, ie have an undefined voltage. You want it to rest low, and be pulled high, right? So, pull that bus low with a single 4k7 resistor to ground.

OK - I elected for a 560R pull-down, to give the busy line a very firm low potential, but perhaps that is not really necessary, based on comments here, and 4k7 seems to be a more preferred choice...

Dr_Acula wrote:
Now add a node. Use a 914 diode. Pointy end to the bus. If a picaxe pin goes high, it makes the bus high. Add more nodes with diodes. Now any picaxe can put the line high. If more than one put the line high, then the line is still high. This is a "wire OR" gate. It is the same logic as an OR gate. Indeed, you could use multiple OR gates if you wanted instead of diodes.

This is EXACTLY the concept of how the nodes are wired to the bus.


Dr_Acula wrote:
Next problem, sensing the bus. Can you spare a different pin to sense the bus, or use the same pin. The latter can be done but needs some more components.

Yes - this is exactly how it is done - one input pin looks at the bus to see if it is high, and another output pin is used to pull the line high if it is not - not forgetting the diode on the output pin, to prevent other nodes killing each other's output pins...

Dr_Acula wrote:
Not sure about the capacitor in the circuit, what does that do?

I stole this from another project which I was helped with here, where I was getting false-tripping on an input. A member suggested a 100n across the 10k pull-down input resistor to help filter off any induced noise in the line, as the door-switchs are connected to the input via a length of cable. I automatically applied the same here, in the attempt to solve the potential of the picaxe seeing a little spike as a high, when the line is in fact low.

DON'T WORRY - I am using a method of checking at least twice that the line is in-fact high - it dosn't loop at the very first high, as that could still be rouge - I learnt well from that other thread with the false-tripping problem I had, and since adding that 100n cap on the input and doing a 2x check the problem has never resurfaced, but I digress...

Thanks for your other comments - I am pondering them now, and will get back to you.
As I only ever need any node to transmit and never receive, and the data message consists of only 6 bytes at 2400 baud, it only takes a very short time to transmitt that message.

System is a form of security thing, in a two story apartment complex, which monitors all the entry/exit doors, and also a few other doors, such as maintenence cupboard and communications room etc, so if any of these are opened at night, a message is sent.
I don't want to get to specific, as I have managed to confuse you all enough, but suffice it to say, that the 6-byte messages are translated to more specific messages at the other end of the bus, which consists of an 18X chip, listening to the bus for pre-detirmined 6-byte command codes, from which it then decides which message to output to a pager transmitter. This all works beautifully so far on the test bench.

As we are only monitoring door switches, and one would hope that there would not be more then two or three people ever trying to break into the same building on the same night there should not really be that much of a chance of data-collisions, unless 12 burglars tried to open all the entry points on the same night, at the same time.

Hopefully this helps, and does not hinder, your understanding of what I am doing.

 

[hippy]

DON'T WORRY - I am using a method of checking at least twice that the line is in-fact high - it dosn't loop at the very first high, as that could still be rouge

Two PICAXE's could still end up in passing all tests for availability of line before both grab it for themselves, even with multiple checks and variable delay times.

A simple solution would be to have your busy line as analogue; one 10K pullup and each with a 10K pull-down. When no one has the bus it will READADC around $FF, when one has the bus it falls to around $80, when two or more have the bus it falls well below $80. You can then test with

Do
Gosub FreeBus
Do : Loop until bus = ~$FF
Gosub GrabBus
Gosub VariableDelay
Loop until bus ~= $80

As we are only monitoring door switches ... there should not really be that much of a chance of data-collisions, unless 12 burglars tried to open all the entry points on the same night, at the same time.

A common technique in security applications is "Keep Alive", units send that they are working and door is closed rather than sending failed ( impossible ) or door is opened ( which may have be intercepted ). The absence of the unit being okay and door closed triggers the alarm.

It's the same principle as often heard on TV; "If you don't hear from me in an hour, blow it up".

 

[vttom]

With the application you describe in mind, I like the idea of polled I/O...

Basically, the "master" PICAXE has 1 RX line and 1 TX line.

The TX line from the master gets connected in parallel to the RX line of every "slave" PICAXE.

The TX lines from all the slave PICAXEs get connected in parallel to the RX line of the master (either use bi-directional pins at the slaves, or output pins with pull-up/down diodes, and a single pull-down/up resistor at the master).

The master then polls each slave in turn by sending a message over the common wire. In essence, the master is saying "Hey slave 1, how are things?". Slave 1 then responds with "OK" or "Not so good", etc. Then the master will say "Hey slave 2, how are things?" and so on.

If there is no response for 1 or more slaves, then the master knows there is a connectivity problem and alerts you to that fact.

The trick is that each slave has to be unique. You can do this when you program them, or you can use some number of input pins configured with jumpers or DIP-switches, that each slave reads on start-up.

 

[hippy]

With the application you describe in mind, I like the idea of polled I/O... Basically, the "master" PICAXE has 1 RX line and 1 TX line.

By diode mixing what the master sends and what the slaves reply with on to the same line, there can be a single data line. An X1 or X2 could use either timeout on SERIN or background HSERSETUP to recieve the reply and know when something's gone wrong.

The disadvantage is that slaves cannot be doing anything else while waiting for the master's serial data but that could use the 'send a pulse to interrupt' prefixing the data.

 

[Grogster]

Two PICAXE's could still end up in passing all tests for availability of line before both grab it for themselves, even with multiple checks and variable delay times.

A simple solution would be to have your busy line as analogue; one 10K pullup and each with a 10K pull-down. When no one has the bus it will READADC around $FF, when one has the bus it falls to around $80, when two or more have the bus it falls well below $80. You can then test with

Do
Gosub FreeBus
Do : Loop until bus = ~$FF
Gosub GrabBus
Gosub VariableDelay
Loop until bus ~= $80

I understand the readadc idea, and it's a very good idea - I will give that some serious thought. Perhaps I am not understanding something, but I thought that a high/low busy line should be enough. If one node wants to transmitt, and it looks at the busy line, if it is high(in my case) that node knows the bus is busy and it waits in a loop until the busy line is low, then it knows it can send it's data - I don't quite understand how this can cause a conflict.

Due to the speed of the picaxe, the chances of data-collisions are extremely small given the message length(6 bytes), the baud rate(2400) and use of the busy line.

I guess you are trying to tell me that at any given point, any one or more nodes could look at the busy line, and see it as low(for example), so try to take it high and transmit their data on the data-bus wire, at EXACTLY the same instant, which would, naturally, cause garbled comms - is that what you mean?

I still don't see how you coulden't fix that with variable delay loops looking at the busy line until it is free - again UNLESS two or more nodes looked at the busy line at EXACTLY the same instant...

A common technique in security applications is "Keep Alive", units send that they are working and door is closed rather than sending failed ( impossible ) or door is opened ( which may have be intercepted ). The absence of the unit being okay and door closed triggers the alarm.

It's the same principle as often heard on TV; "If you don't hear from me in an hour, blow it up".

A very good point - I think I will change that aspect to what you suggest.

 

[Grogster]

Another quick thought: Using the ADC idea, is it not also possible for two or more nodes to read the line at the same time - just as with the 1/0 logic, see the busy line as $FF, and try to talk in exactly the same way, causing exactly the same garbled comms problem?

I don't think I fully grasp this concept yet!

 

[vttom]

The disadvantage is that slaves cannot be doing anything else while waiting for the master's serial data

Good point. Another way would be to use a separate "attention" signal wire. The master asserts the attention line before it wants to send something. The slaves all detect this and execute a serin. Then the master waits a certain amount of time, de-asserts the attention line, sends it message down the serial bus, then waits for a reply.

 

[hippy]

@ Grogster : It's hard to visualise. Consider two people with tunnel vision going to pick up a cup of tea. They look (L) to see if anyone has hold of it already or have taken it and if not take(T) it. The simple case of failure ...

1 : ---L-----L-T
2 : ---L-----L-T

So we add a variable amount of time between looks, and that appears to work at first glance ...

1 : ---L-----L-TTTTTTTTTT
2 : ---L---------L---------L

But if they both first look at different times ...

1 : -------L-----L-T
2 : ---L---------L-T

There's also a short period between looking and taking and in an unlucky situation that will allow a collision ....

1 : ------L-----L-TT
2 : ---L---------L-T

No matter how infinitesimally small you make the gap between look and take there is still a possibility of the second taking their final look at that instant. It also doesn't matter how many looks one does or what the gap is between them, it's that final look then take which always poses the problem.

What makes it difficult to visualise is we are all used to thinking in terms of cause and effect, action and reaction, if this happens such and such will follow. In this case you have to think backwards, how could we arrive at a situation, and how do we avoid arriving at that situation.

When you realise it's that final look then take which is the problem, no matter how close you bring them together, zoom in and there's a gap, and if there's a gap the other could look during the gap. You can minimise collisions but not avoid them. Sod's Law defines "minimised" as "never or rarely happens, until you need it to work, then it consistently fails at such times".

 

[hippy]

Another quick thought: Using the ADC idea, is it not also possible for two or more nodes to read the line at the same time - just as with the 1/0 logic, see the busy line as $FF, and try to talk in exactly the same way

No, it's a "put delay, then look" process. Each effectively puts a token on the table and only proceeds when there's only one token on the table. No token is put on the table if it's not empty and then there's a check for only one token before proceeding, otherwise each takes their tokens back and starts again. When it's working well 1 won't put a token down if 2 has and vice versa. When a collision happens and both think it's okay to put down a token the later check that only one token is there fails.

The delay between putting one's token down and checking there is only one has to be longer than the time it takes the other to see there's no token and putting their own down. So the worse case scenario is ...

1 : --------L--T--L
2 : -------L--T--L

No matter how you juggle the tiiming ( as long as there is a suitable delay ) it's not possible for two tokens on the table and not be detected on the second look.

 

[Grogster]

OK, thanks very much everyone, for your comments and suggestions.
I am breadboarding the new version now, using an analog busy line as suggested by hippy. I'll let you know what happens during the testing phase. Special thanks to hippy for explaining the busy-line problems and solutions - that helped my understanding a lot.

Thanks again, people.