Doubtless there are people here looking into designing Shields for the PICAXE base device. And, no doubt, they will also have an eye on making it compatible with 'that other' processor ;)

Obviously people can do what they like in terms of design and code , but it would be nice for users if some standards or considerations were made.
I'm sure there are many areas up for discussion, so can I start a ball rolling with considering SERIAL COMMUNICATIONS.

In many cases separate pins are used, but to save pins we may decide to share a serial data line. Thus , in effect, we have a Serial 'bus'.

I've attached some thoughts on a common standard if we all design Shields.
And I'm really referring to Shields which use a separate Micro which communicates serially to the Micro on the Shield Base.

It's all a bit scrunched up but I hope you get the idea.
Thus if we conform to a few basic standards then our shields can work together. Result: Smiles :)
(If you don't like the term "shield" then this method could also be appropriate on a serially joined Daughter Boards.)

Have a Look... electrically similar to I2C which everybody seems happy with.
(Please note: In some cases the Coder can set the to O/P , send and then set back to I/P mode. Pefectly good in 99% cases. My suggestion is merely an electrical solution.)

It may be good to discuss other proposed thoughts in separte threads with similar titles.



Technical Support
Staff member
Sounds a good idea. An alternative option may be diode mixing. That's equally electrically safe, avoids the inversion issues, can be connected directly to a PC to see what's on the bus, and a PC can be a slave or master for the bus. Modding someone's board which doesn't conform would be cutting a track and adding a diode. There may however be upper speed issues.


Yes, the easy modding is a good point. And yes, a PC bus connection would also require a teeny interface - but then you should do that as 'good practice'.
The advantage with 'open' like this is that you can mix MicroC voltages without worry. It could be one or two stage - after all low Vgs dual-MOSFET smd chips are very common for those with a steady hand and a spare 30p.
Last edited:


Well-known member
Not meaning to detract from your post, but this neat idea should be prefaced with some words about cooperating shields. Hardware solutions only solve hardware problems and do not allow for buss contention issues.

Have you some thoughts on that in relation to sharing TX lines amongst shields? I'd be interested.

... Thus , in effect, we have a Serial 'bus'.... My suggestion is merely an electrical solution....


Contentions/collisions are yet another problem ;)
I was just gving some thoughts on the electrical bit. After all, if you cock-up at th first hurdle then you'll never get to the next stage of sorting contentions....

Trying to come to some agreement on that will be really tricky so I'll leave people to do some basic checks.
And it really depends on whether the shield base is polling/requesting or whether the shields are volunteering/announcing.
A thorough solution is way beyond the scope here.

As far as Base Tx to Shield Rxs that's up to you.
I'm leaning towards an Addressing method. Nothing too complicated. I've noticed others using it too.
Last edited:


Senior Member
I also prefer the addressing method due to its simplisity, until it comes to assigning addresses...

One method I have used sends the message through each shield and if the address=1 the message is for them else they take away 1 from the address and pass it to the next sheild which does the same checks:
serin C.0,N2400,address,message
if address=1 then 
  ;do something with message
  serout C.1,N2400,(address,message)


Interesting, but I don't quite follow that.
I lean towards I2C style as people are familiar with that.


Senior Member
Ok, difficult to explain...

Errr... Imagine there are three chips connected like follows:
         _____       _____        _____
to CPU--|     |-----|     |------|     |--C-etc
        |  1  |     |  2  |      |  3  |
        |_____|     |_____|      |_____|
The cpu sends a number (address) followed by the message, for this example lets say it sends '3,"hello"', when the stream reaches IC 1 it reads '3,"hello"'. It checks the address ('3') to see if it is '1' if it is 1 it knows the message is for it, if the message is not '1' it knows to pass it to the next IC with an address 1 less. So when the stream arrives at IC 2 it will read '2,"hello"', IC 2 then check the address and as it is not 1 it passes it to the next IC with an address 1 less. IC 3 then receives '1,"hello"' and as address is '1' it knows it is for it.

So basicly the ICs can receive messages designated for them without actually knowing their address.

Hope this explination helps a bit more.



Ok, difficult to explain...

So basicly the ICs can receive messages designated for them without actually knowing their address.
It's a great explanation - no problem with that.

The second bit isn't very clear - each IC must definitely know it's address surely - e.g. chip #2 must know its address is 2 so it can pick up a message that comes into it with a number 2 on it?


I'm confused too.

In your first post you suggest that 1 is subtracted then sent on...
How does the second Shield know to ignore the first serial transmission?
How does a second (and onward) shield know the base is transmitting to Shield1 and not Shieldx?

It makes life so much easier and faster if each has an address just like I2C devices.
Nice try though.


Senior Member
@Dippy and Martin: the second IC won't receive the first serial stream as it is is sent down a line to the first IC, look at the diagram the ICs are not all connected together.

Come to think about it this wont be easy to do on the sheild... forgot about that...:eek:


"look at the diagram the ICs are not all connected together."
- umm, well your sketch in Post8 shows them connected together.:confused:
Do you mean that they don't share a common bus? (which was the whole point of this...).

Ah well, I'll have a look to see what others do. It's always nice to follow an accepted practice. But thanks for your input anyway.


Senior Member
It's common with a serial bus to have individual addresses for slaves on the bus (like i2c) and a broadcast address which allows the master to tell all slave something at once. The slaves do not normally respond to a broadcast. However, this can be accomodated too by inserting a delay proportional to the slave address: each slave has a 'window' to respond to a broadcast.

The daisy-chain configuration suggested by Jamster makes the job of the 1st slave very complicated. Could only really be achieved on a stack of shields by snipping pins off to break the bus into segments.