Multiple Hserin/Out's

[manie]

I've looked at Hippy's page showing a Picaxe ring communicating with "Txxxx" protocol via diode blocking/mixing.

I will want to have 4 x 28x1 project boards have comms back/forth with all the others in the ring but through Hserin/Hserout, set up for background receive.

The Tx'ing Axe will send an "ID" first byte to indicate which Axe is being addressed. The Rx'ing Picaxes will receive (in background) and react to it's own ID. The "other" Axes will reset Hserflag and Hserptr if the message is not for them, thus being ready for the next Hserflag interrupt. With Hserin in the background one is not tied to "rigid" data block lengths etc .

Will the above diode mixing circuit still work with Hserin/Hserout ?
Which way must the MODE bits (28x1's) be set - eg. %10 or %00 etc. ? Hippy's method asks for "Txxxx" (inverted) comms....

EDIT:
One of the above Axes will also have the RS-232 output/input from/to the 433MHz transceiever. Can this be included on it's own diode as part of the ring ?
(DB9 connector to Picaxe, currently on "normal" Serin with 5sec timeout)


I would like to thank all the future contributors to this.......

 

[hippy]

a Picaxe ring

Comms terminology can get confusing but I suspect this is a Multi-Drop Bus ( masquerading as a Star Network or drawn as a ring ) rather than a Ring Network; you wouldn't need diodes for a Ring. A true Ring would be one into the next and so on.

I've looked at Hippy's page showing a Picaxe ring communicating with "Txxxx" protocol via diode blocking/mixing.

I will want to have 4 x 28x1 project boards have comms back/forth with all the others in the ring but through Hserin/Hserout, set up for background receive.

That should ( without looking at what I had there ) work. For Txxxx baud rates it will need a pull-up and, from that pull-up, diodes with cathodes ( pointy-ends ) to each HSEROUT. All HSERIN's would take their inputs from the pull-up / diode anodes point.

Which way must the MODE bits (28x1's) be set - eg. %10 or %00 etc. ? Hippy's method asks for "Txxxx" (inverted) comms....

The 28X1 can only transmit with Txxxx on its HSEROUT pin, so you have to match HSERIN to that, thus : "HSERSETUP baud, %01" for Txxxx and background receive.

One of the above Axes will also have the RS-232 output/input from/to the 433MHz transceiever. Can this be included on it's own diode as part of the ring ?
(DB9 connector to Picaxe, currently on "normal" Serin with 5sec timeout)

Probably not as it sounds like Nxxxx baud rates used there. You would have to invert the Nxxxx to Txxxx then you could diode-mix it like any other Txxxx HSEROUT. If it's +/-12V RS232C you'd need to drop that voltage as well, and remove the negative voltage component. A MAX232 would do all those jobs.

 

[manie]

Thanks Hippy. Does this schematic showing two Picaxes and RF-->Max232---> look OK ?
Diodes I thought 1N4148's or such small switching diodes. OK ?

EDIT:
The Max Td connects to Hserout from 28x1-Hserout terminal. The attached is not clear there. The Hserout/s (colour yellow....) are on top and Hserin/s at bottom of each pair of terminals. Max232 represented by inverters....

 

[manie]

I think I had the diode to the Max232 on the wrong pin. I've moved it to the Rd pin (like data "from Hserout"...?) Is this correct ?

New schematic attached.

 

[hippy]

You don't want the 10K pull-down. A diagram of which PICAXE's communicate with which will help. If there's only two you can greatly simplify things, and if there's more than two you probably need a single shared bus not two.

I think you need ...

                         -.---.- +V
                         .|. .|.
                         | | | |
                         |_| |_|
                          |   |
.-----------.   .---|<|---|---|
|        TX |---^---|<|---|   |
|        RX |<------------|   |
`-----------'             |   |
                          |   |
                          |   |
.-----------.   .---|<|---|---|
|        TX |---^---|<|---|   |
|        RX |<------------|   |
`-----------'             |   |
                          |   |
                          |   |
.-----------.   .---|<|---|---|
|        TX |---^---|<|---|   |
|        RX |<------------|   |
`-----------'             |   |
                          |   |                   \|/
                          |   |                    |
.-----------.             |   |                    |
|        TX |---.---|<|---'   |               .----^---.
|        RX |<--|-------------^---|>|---O<|---| RXD    |
`-----------'   `-----------------------|>O---| TXD    |
                                              `--------'

But not clear exactly what the RF connects to. How are you going to stop that corrupting the PICAXE to PICAXE comms ?

 

[manie]

Hippy: Thanks, your circuit above looks like what I had in mind, except I don't quite know how the detail will look. Here is a better description.

The RF module needs to connect only to the "master" really, just for two-way data from/to the remote PC. It updates info on PC terminal screen and parameters can be set and alarms cancelled from the PC. That is the RF's job. Initially there will be the Master Environment controller, the LCD control (same job as the PC but local in the coop), one more for the additional ADC and +5v (high) limit switch interrupts. I thought of the fourth to act as the "limit" switch watchdog, only requiring to transmit data to the master and LCD updater, not requiring any serial input within the whole circuit. Or could this be TOO slow (9600 baud/8MHz) ? Curtain movement speed is 200mm per second, so 1mS = 0.2mm. 9600 baud = +- 0.1mS/bit = +- 1mS/byte, should be fast enough ????

At present (with 40x1-Master to 28x1-LCD), I stop the Hserinflag interrupt when entering data on the ADC matrix keypad(to prevent interrupt and allow keypad work, the master just keeps sending at it's preset interval - will be 30sec min and +- 120sec max interval). After sending new data to the master, the hserinflag interrupt is reset to receive new updated data at those intervals.

The master sends data out regularly for display, it only needs to receive new parameters when it changes, it also tells the 2nd 28x1 by how much to move the curtain to regulate the temperature/humidity etc.

The four "limit" switch high's needs to interrupt the 2nd Axe as well (unless 4th Axe is used for this), this is another of my problems, can this be done on the Hserin flag also ?

Does this tell you more ?

 

[hippy]

Does this tell you more ?

Not really but it could just be the time of night. Often a picture's worth a thousand words, and so's an overview without the details. Networked systems can be incredibly complicated to design and to visualise.

 

[manie]

Have a kip mate ! I'm also clocking out now, 24H25 here ! Will try and make a picture of my requirements to clarify some more, tomorrow or so..... thanks

 

[BCJKiwi]

Any reason that hi2c coudn't be used for this?

 

[manie]

BCJ:
Only reason I can think of is my lack of knowledge of the subject.... can you explain a bit more ? Principle of operation and reasons why you think it might be easier ? It certainly is a new avenue to explore......

 

[BCJKiwi]

Can sympathise! All these things seem very complex until you get into them. Armed with working examples and a couple of 28X1s, I'm sure that with the PICAXE achievements you have already made, i2c will be no problem.

i2c is a bus system.

So you avoid all the issues of a ring, and handshaking, and timeouts, etc etc.
Each device has its own address so the master simply addresses the device it wants to talk to and gets the data from it.

As you are using 28X1's, hi2c is supported and one can be a master on the bus, the other three slaves.

Only downside would be if these 28X1's were too far from each other for the i2c bus.

 

[manie]

BCJ: Not far, same box in fact. I like the i2c idea as the master can now address whichever device it wants so there is little possibility for clashes. Also the RF can go onto Hserin/Hserout. That however brings two new questions which are:

1:
If you can do a Setintflags "NOT" setup for Interrupts, is this also possible using BOTH Hserflag AND Hi2cflag ? So that if EITHER flag is raised the 28x1 can respond (here its the Axe with the RF connected to Hserin/Hserout also..)

2:
On the bus, is it compulsory that one is the Master and all else are Slaves, or can the transmitting Axe take the ROLE of "master" and just address the one it wants to talk to AS IF that one is a Slave ? That is how I understand it. The one transmitting "becomes the master" and sends TO whichever address it wants to. Am I making sense here ?

 

[BeanieBots]

1. Yes, you can trigger on any combination of the flags.
The only thing you can't do is mix hardware interrupts and flag interrupts.

2. Not 100% what you are asking.
Only ONE device on the I2C should be master.
The master initiates the 'conversation'. Slaves must not 'speak' out of turn.
The master must ask the slave what it wants to know.
The master can put information into the slave. Not the other way.

It IS possible to have more than one master. This had to be done before slave mode was implemented. However, you would need to write routines to handle bus clashes and data handshaking.

 

[inglewoodpete]

I have implemented a system where there is 1 dedicated i2c master and a number of i2c slaves. However, the slaves can flag to the master when they have something to say. This is just a wired-OR arrangement (output pin on each slave via a diode to a single shared input pin, with pullup, on the master).

When a slave has something to say, it tells interrupts the master via that wire and the master polls each of the slaves to determine which slave and what is required.

The other option was to have the master continually poll the slaves but I didn't want that processing overhead in the master.

 

[manie]

BB: Thanks. Then for now I'll go the Hserin/out route first as I know a bit more about serial than i2c ! However.......(always..)

1.
Can't the Axe be "tricked" into thinking that i2c comms has happened by the manipulation of the the i2c scl/sda pins ? That way one can use the interrupt on flags condition still.

 

[inglewoodpete]

I know a bit more about serial than i2c

I had 20 year's experience with serial comms before I tried i2c. i2c has the huge benefit in that it is a protocol 'package': so much of the data and buffer fiddling is done for you.

I suggest you try a simple link between 2 PICAXEs and in a couple of hours, you'll be converted

 

[manie]

Peter: Thanks. Saw your post a little late. That would mean that you have Setint in use and then Hserial flags ca'nt be used to get serial data ? If there was no RF from PC involved that would be a good route to take.

 

[hippy]

Where possible it's always a good idea for simplicity to have one and only one master and make everything else slaves. Multiple masters add an extra level of synchronisation and more complicated programming, particularly in system design and debugging.

Worse case scenario is a dead-lock situation ( where one is waiting for another to do something and the other is waiting for that waiting to do something ) and you cannot easily tell who is waiting for what and how they got into that situation. All you often know is that the system has ground to a halt.

Multi-node and especially multi-master systems require a lot of "what if?" analysis to ensure they are robust.

 

[manie]

Hippy: Your post #5 shows the diodes with Cathode to Hserout. On your web page for "Txxxx" comms it shows the diode the other way around (Anode to Hserout). I will do "T9600_8" baud comms. I take it then your post #5 is correct ? Thanks.

Sometimes confusion will end........

 

[hippy]

Hippy: Your post #5 shows the diodes with Cathode to Hserout. On your web page for "Txxxx" comms it shows the diode the other way around (Anode to Hserout).

Not sure where on the site you mean. This is what I can find ...

http://www.hippy.freeserve.co.uk/picaxeio.htm#Multiple_Picaxe

which doesn't actually specify the polarity which is part oversight and never using Txxxx baud rates when I can avoid them. The diagrams there are all for Nxxxx baud rates which allows SEROUT or SERTXD, SERIN or SERRXD to be used, and the signals are also the correct polarity for connecting directly to a PC's COM Port.

For Nxxxx bauds, idle at 0V, diode cathodes ( pointy-ends ) point away from the TX pins and require a pull-down.

For Txxxx bauds, idle at +V, diode cathodes ( pointy-ends ) point towards the TX pins and require a pull-up.

The principle is to keep the line at whatever the RX will be expecting when everything isdisconnected or nothing transmiting, and to use the diodes as 'open collectors' to push or pull the line in the direction of non-idle.

I'd recommend using Nxxxx baud rates whenever possible for a few reasons - It's more logical when 0V means 'nothing' or 'idle'. A LED+R to 0V shows when data is present ( and 0V will be on linking cables and buses so LED+R can be added anywhere easily ). PICAXE's and most other devices start with outputs at 0V when powered-up, raise them to +V for Txxxx operation, and the receiver can interpret such transitions as data received when nothing was sent. With a powered-down Txxxx device on a functional multi-drop bus it's possible it will kill or corrupt all comms. Resets and downloads will likely corrupt data as well.

 

[manie]

Between the 28x1 Hserout pin 6 and the diode (1n4148) Anode, I can see the signal on the 'scope about 3V down from th +5v trace, flashing as I would expect it to. When I move the probe to the diode Cathode side, I still see the signal flashes but only JUST below the +5V trace (+- 5mV ??) with the receiving Axe connected. Without the receiving Axe the signal is the same as 1st reading. In addition:

The receiving Axe goes into Sub Interrupt ONCE and on one occasion TWICE only. Then nothing. So it DID see the serial signal, it DID go to Interrupt but not again...

I am seriously getting P....off, NO SUCCESS, is this hobby achievable ??

Can this multi-serial be done via Hserial on 28x1 Project Boards ?

 

[inglewoodpete]

The receiving Axe goes into Sub Interrupt ONCE and on one occasion TWICE only. Then nothing. So it DID see the serial signal, it DID go to Interrupt but not again...

Interrupts are probably one of the more difficult things the implement. Often a lot of patience and dubugging are required. So speaks a voice of 25+ years experience in microprocessors and microcontrollers!

i2c..... That would mean that you have Setint in use and then Hserial flags ca'nt be used to get serial data ? If there was no RF from PC involved that would be a good route to take.

I was possibly a little misleading in saying 'interrupts' by a wire from each slave to the i2c master. Interrupts are something that I use sparingly. A 'good' interrupt routine has as little code as possible and is used to (immediately) capture events that can't wait.

I use an 'open' style of code structure, which always loops through a main loop. Ie processing never gets stopped in a small loop waiting for a particular event (eg key press). The main loop checks all possible conditions and acts on them appropriately. The interrupt routine will usually set and/or test a flag or two and return execution. The main loop checks these flags as part of its job.

Back to 2-way i2c. If an i2c slave wants to tell the master something, it toggles the separate line back to the master and then waits for the master to respond via i2c. There may be a delay of a few milliseconds before the master can respond and query the slave via i2c. When the slave gets the query, it releases the interrupt signal to the master.

Hope this helps
Peter

 

[BeanieBots]

I too support the methodology suggested by inglewoodpete.
It would be very little extra overhead (compared to polling a line or flags) to ask the slave if it has something to say by interrogation over I2C.

 

[manie]

Peter and BB: Thanks for the responses. Notwithstanding BCJ's kind (and flattering) words in an earlier thread, I truly thought this is IT, give up and take up beer brewing or something.....

In the meantime (not Greenwich..) I got THREE axes to exchange data, basically one is a "master" and sends out two lines of data. Each line carries the ID of one particular Axe, which then reponds with an answer. 45min so far and no hangup I could see. There is hope after all.......

I suppose one could follow a similar route as Peter's with hardware serial ?

 

[hippy]

It's always best to start at the beginning; get one PICAXE talking to another, add the diode and pull-up/pull-down and check it's still working and voltages are reasonable. Get the foundations built then move on to the next step. Check each PICAXE can talk to the other separately before putting three PICAXE's together.

SEROUT / HSEROUT using Txxx driving a PICAXE input with a pull-up should pull the voltage from +5V to about 0V6 ( the vDiode drop ) when operating. The signal coming out of SEROUT / HERSOUT should be a hard 5V or 0V.

 

[manie]

Hippy:
In post #2 you said the RF is probably Nxxx, but after checking again, it is in fact also Txxxx, so it could fit in via diode mix then ?

 

[hippy]

If it is Txxxx then yes, you can connect it same as the rest. If the 9-way D plugs into a PC and that works then it's not Txxxx on the 9-way D.

 

[manie]

On the PC side I use the Axe027 USB download cable.

PC-USB-->Axe027-->Stereo plug-->D-9pin-->Transceiver

On the 28x1 side:

Transceiver-->Max232-->Serin/Serout.