Daisy Chain Ripple Programming

H

Hundred1906

Member
Has anyone tried downloading one picaxe through another?

I have a string of picaxes linked one to another through serial links daisy chained across an open space. It is tiresome to take each out in order to optimise my program. Each has the same program.

The plan would be to ripple load a boot loader into each and then pass the new program down the boot loaders for loading. So it would be loaded first into the very end of the chain, then into the one before that and so on until the device at the start of the chain (or perhaps the one after that) was finally loaded. Presumably one device (the top device) would retain the ability to download programs. By this stage all the boot loaders would be overwritten.

Is the standard loading protocol used by the PC available for public use?

Is there another better/cheaper way?
 
H

Hundred1906

Member
Looks as though it would be a real struggle so I will just carry on with doing it the hard way. Pity though, it could be a real benefit for distributed applications. Also I might just take a look at other controllers to see if they can do this.

Thanks.
 
H

Hundred1906

Member
Thought about this some more as doing it the hard way is just not practical. The Picaxe is programmed using just the serial interface so it ought to be possible to introduce another device into the data stream to divert it and echo back the responses without needing to know details on exactly what was flowing. Presumably the stream contains a data marker to initiate loader action in the receiving device so the introduced device cannot be another picaxe, or at least not one using pin 2 as the input, because it too would be forced into program load status.

Will give this a try in a few days, otherwise will need to start looking for another controller that can be remotely programmed. This would be a shame as I really like the PWM capability. Perhaps those involved in the SerialPower project would also be interested.
 
hippy

hippy

Ex-Staff (retired)
There are some mechanisms which allow a line of PICAXE to be programmed from one end of the line and this could possibly be achieved with fairly simple hardware.
 
H

Hundred1906

Member
Interested to find out more from hippy if possible.

Meanwhile the input from Buzby is interesting and warrants some test coding over the next few days. It means adding another chip (EEPROM) but I would probably have to add something for any solution (unless I can somehow make use of multi-tasking). Buzby is using IR to load several slave devices in parallel but my devices are relatively distant and so are wire daisy chained. The downside is that on my 08M2 controllers i2c and pwm are on the same pin so use of pwm would not be possible - maybe I can work round that.

At present each device application looks like this: Receive command - Action Command - Pass Command Onward.

I think this needs to look like: Receive Command and Test for Boot Instruction - If Boot Instruction then Download to EPROM - Transfer Boot Instruction and Data Onward - Boot Self.

That way the new program propagates down the chain.
 
Buzby

Buzby

Senior Member
Hundred1906 said:
Buzby is using IR to load several slave devices in parallel ...
Click to expand...
Hi Hundred,

Well, that was the idea, but it got no further than testing the IR comms from one PICAXE to 3 others.
I was toying with an idea for a project which was to be multiple identical robots in an arena, all programmed simultaneously via IR.
It was going to be a test bed for some ideas I'd been reading relating to emergent behaviour from simple mechanisms.

It wasn't the software or comms that stopped the project, it was the realisation that I would have to spend a lot of money, build a lot of hardware, then find somewhere big enough to keep it all !.

But I did enough with the 'eeprom to eeprom then booti2c' idea to see that it is a viable solution, either over IR or any other method.

However, booti2c is only available on X2 parts, not M's, so it is no use for your 08's. :(

Cheers,

Buzby
 
hippy

hippy

Ex-Staff (retired)
Hundred1906 said:
Interested to find out more from hippy if possible.
Click to expand...
My idea is to have each node either connect the PC to its PICAXE or pass the PC signals on to the next node.

Some sort of "initialise" signal would set the first node in the chain to connect to the PC, download would then program that PICAXE, when programmed the PICAXE program downloaded would run, set its hardware to pass signals to the next node, then wait until it sees a later "done" signal presented after all PICAXE's have been programmed.

It should, I think, be possible to implement that switching per node using just one 74HC00 or similar.
 
Buzby

Buzby

Senior Member
hippy said:
... set its hardware to pass signals to the next node, ... 74HC00 or similar.
Click to expand...
Hi hippy,

I've never bothered trying to hack the download protocol, but we all know it needs a 'break' to kick it off.

Usually the 'break' comes from the same source as the comms, but what if the break was triggered locally ?. Could any comms method then continue the download ?

Cheers,

Buzby
 
H

Hundred1906

Member
By 'break' I assume we are talking about an extended null/low transmission. In which case a UART is probably needed to detect and pass on. That adds another device anyway so I would be just as well off with the EEPROM/i2c solution. Except of course that I now have to replace my 08M2s with x20s which is a pain and a pity because I have to rework the circuit layout, but I can live with it providing there are no other "Small Print" spec items I have missed.

I checked out PIC as an alternative but that looks just as difficult and is a whole new learning experience. There is always the option of digging out an Arduino solution which I am pretty sure would work but these are too expensive for the application.
 
Buzby

Buzby

Senior Member
Hundred1906 said:
By 'break' I assume we are talking about an extended null/low transmission. In which case a UART is probably needed to detect and pass on.
Click to expand...
Not quite.

Imagine a two way radio link into the normal serin/out pins. This can't send the 'break' that PICAXE needs to kick off the download

What I was think was thinking of was using a command over the radio to tell the remote PICAXE to pulse an output pin wired back to pulldown it's own serin.
The PICAXE would then automatically start to look for a download.

Harebrained and half-baked, but that's how all the best ideas start !.

Cheers,

Buzby
 
hippy

hippy

Ex-Staff (retired)
Hundred1906 said:
I would be just as well off with the EEPROM/i2c solution. Except of course that I now have to replace my 08M2s with x20s which is a pain and a pity because I have to rework the circuit layout, but I can live with it providing there are no other "Small Print" spec items I have missed.
Click to expand...
Any system of passing programs down the line is going to be complicated. It's not just getting code from one to another but synchronising and scheduling everything so it all works. I don't think anyone could be sure there are no small print issues until it's all working.

I'd also caution against rushing in as there may be other solutions cheaper, simpler or more suited to what you have or want. Just because they haven't been thought of yet doesn't mean they aren't out there. I think there may be a solution needing nothing more than a diode per PICAXE. That's based on what I suggested in post #12 but still needs some thinking about.
 
Buzby

Buzby

Senior Member
Hundred1906 said:
... providing there are no other "Small Print" spec items I have missed.
Click to expand...
I don't think you can call lack of remote programming a small print spec item.

I think the PICAXE documentation has quite clear instructions on how to download. - Use AXE027 and PE.

The fact that that there is no mention of support for multiple/remote/oddball programming techniques is not a failure of the documentation, or a case of small print spec.

If you needed multiple/remote/oddball programming capabilities you should have checked before you even put pen to paper, or mouse to CAD.
 
H

Hundred1906

Member
If you needed multiple/remote/oddball programming capabilities you should have checked before you even put pen to paper, or mouse to CAD.
Click to expand...
Wow. My comment was supposed to be self deprecating - I checked the pin-outs but not the detail in the spec - I am not blaming anyone else! Also I am new to these devices and I am developing the functionality as I go based on what they can do. I had assumed that these devices would be programmable down a serial cable because that is pretty much the way they are programmed, but I wasn't worried about it because the application functionality was pretty simple when I started. It's only now I have built and tested a half-dozen that I am seeing limitations that need to be worked around.

Reworking the design is pretty easy and is what I would expect to need to do probably several times over so it is not an issue and anyway I keep finding functionality in the specifications that I either hadn't noticed or appreciated before.

So back to serial downloading, and I thank you for your help so far but I am going to take up your original proposals and swap across to the X2 devices for a while because I think I can make quicker progress over the short term as the solution stays within what seems to be preferred usage models, allowing me to concentrate on sensor/application development. I am just not at this moment sufficiently familiar with the internals to be able to make progress quickly on what you call oddball programming capabilities. If the technique were known or experience available and it was down solely to implementation I would be there.
 
Buzby

Buzby

Senior Member
Hi Hundred,

Sorry if I came on a bit strong, but it did look as if you were claiming to be somewhat mislead about the PICAXE's abilities.

However, back to the issue in hand.

Please post a sketch of the serial connections, including leg numbers !, for the PC and the first three nodes.

I have a cunning plan !.

Cheers,

Buzby
 
H

Hundred1906

Member
No problem, that's language for you. Just grateful for any input especially if it also helps others. As I said the design will just get by without a program load capability but it is going to be a pain to fix if I need to change installed items.

The circuit has no pc connection as it is self contained. I take the picaxe chips out to program them on either an AXE117 or on a protoboard via an AXE029. Each controller box is the same except for a switch/jumper that indicates which is Master. All the loaded programs are identical. The boxes are simply connected in a line, input to output.

Cost is an issue so reducing the cost and number of connectors is important as ip67 connectors of any quality are expensive. So my ideal would be to program through an existing serial input connector.

I am doing some work on the comms driver to harden against cable induced noise and I might drop the Master select switch somehow in order to free up a pin. Otherwise I intended to move later to a 14M2 in order to add another sensor. Right now I would switch to an 20x2/EEPROM and I suppose should also take a look more closely at the potential in the i2c interface.

Comms use hser instructions both ways c.0/c.1 but I ought to pay more attention to c.5 as an alternative to c.1 as this would also free up a pin, though needing more care with timing conditions to avoid lockups.

The diagram is summary, not the entire design. I created it for this purpose so hope it helps.

Block Functional.jpg
 
P

Paix

Senior Member
OT and only in passing, but I assume that there is a decoupling capacitor on the real PICAXE Vcc line. That zener diode could be noisy!
 
You must log in or register to reply here.
Top