hserin to program?

johndk

Senior Member
Is there a way to use hserin to program the picaxe, thus eliminating the download cable? I have 433MHz radios currently communicating over this interface. It would be really nice if I could update chip programming via this connection. I envision a radio interface on my computer initially. But eventually, it would be advantageous to be able to supply a file to a master chip (via a micro SD chip and OpenLog, for instance) and have that master distribute the updates to the remote modules with which it communicates. Am I dreaming??? Or is this remotely possible.
 

hippy

Technical Support
Staff member
It would be extremely difficult even with insider knowledge of the PICAXE.
 

BESQUEUT

Senior Member
It would be extremely difficult even with insider knowledge of the PICAXE.
+1
Maybe use a local raspberry with Picaxe compiler ?
or
sniff communications between PE6 programming a first Picaxe, store this as a file, ans play that again localy with a a small Picaxe...
 

Circuit

Senior Member
Is there a way to use hserin to program the picaxe, thus eliminating the download cable? I have 433MHz radios currently communicating over this interface. It would be really nice if I could update chip programming via this connection. I envision a radio interface on my computer initially. But eventually, it would be advantageous to be able to supply a file to a master chip (via a micro SD chip and OpenLog, for instance) and have that master distribute the updates to the remote modules with which it communicates. Am I dreaming??? Or is this remotely possible.
Remotely possible indeed: Programming over a radio interface can be achieved with the ERF/URF combo http://www.picaxestore.com/index.php/en_gb/rfa030.html.
"The ERF and URF modules are the easiest and most convenient way to wirelessly communicate between a PICAXE chip and a computer."
 

hippy

Technical Support
Staff member
There are three things required to program a PICAXE; (1) getting the binary code which represents the PICAXE program, (2) getting that to the PICAXE, and (3) getting that into internal Flash memory.

The Rev-Ed 'Compiler -> AXE027/ERF -> PICAXE via serial in' mechanism is catered for by the compilers and PICAXE firmware, but changing any part of that can be a challenge.

Programming with an ERF only works because of special firmware which provides for correct polarity, break signalling and the URF/ERF pair being able to carry the download transparently as if a serial cable.

Getting the program into internal Flash memory works because it comes in via the serial in pin and the firmware caters for that.

It can be done other ways but that means knowing the protocols and/or figuring out other ways to do things. That can require additional hardware and is not always straight forward.

Probably the easiest way to achieve it would be with an X2 PICAXE having external slots in I2C Eeprom so one could program a master PICAXE external slot direct from the PC via an AXE027, then have that pass the slot memory over to a similar slave PICAXE also with external slot memory. I believe there has been past discussion of that possibility on the forum.
 

tarzan

Senior Member
Probably the easiest way to achieve it would be with an X2 PICAXE having external slots in I2C Eeprom so one could program a master PICAXE external slot direct from the PC via an AXE027, then have that pass the slot memory over to a similar slave PICAXE also with external slot memory. I believe there has been past discussion of that possibility on the forum.
Have a look here. booti2c
 

Goeytex

Senior Member
I successfully got a pair of LC-1000 RF modules to wireless program a Picaxe. I sniffed out the "protocol" using a Salea Logic Analyzer. This allowed me understand the timing. chip IDs, special codes & handshaking necessary for a successful download. Once I had that information, as proof of concept I wrote a short Picaxe program where a Picaxe faked being programmed just to capture the data sent by the Program Editor. I suppose a good port sniffer would have worked as well.

This allowed me to make a " hex file" and store in eeprom of the Master Picaxe. Code was then written where the Master Pixaxe pretended to be the Program Editor to initiate the download and send the "hex" to the slave. These RF modules did not support break signaling so I had to work around that with code and extra hardware. All in all it was a real pain. But it is doable.

INHAOS now offers an LC-2000PA Wireless USART set that supports wireless DTR. DTR could be used as a "break" if OR'd to the serin Pin. An LC3000/PA is soon to be released that will support Point to Multi-Point. Advertised range is 300 meters LOS. I may try with the LC2000 as I have several that I am testing.
 

johndk

Senior Member
I'm a little lost here and maybe I shouldn't get excited about the possibility. But here's why I want to be able to do this. I'm working on a project where we will have one base module communicating with 32 and possibly as many as 256 remote sensing modules in order to do central data collection. My goal, therefore, is to be able to distribute updated code (because we're likely to be development for some time) via a wireless transfer from the master module.

The part that's confusing me, probably because I'm not familiar with the way the Picaxe is flashed, is the talk about protocols. My radios (Dorji DRF4432D201-043L1) communicate at a rate of 14400 serial and 19200 RF. I do CRC checking and can pop 64 byte (or more) blocks into scratchpad, eeprom, or external eeprom. All of that already works. So it comes down to, I think, taking that binary image generated by the compiler and storing it somewhere on the remote module and then flashing it to my remote 28x2. If that takes an extra say 08M2 to run a small transfer program, that would be no big deal. It would certainly be worth it in saved time until design is frozen, at which I can leave out the extra chip.

So again, my question comes down to the protocol. Do we need to work out a protocol between my remote 28x2 and a new 08M2 (or whatever) 'flasher'? Or are you guys talking about the radio protocols?
 

Goeytex

Senior Member
The protocol being referred to is the method that the Program Editor/Compiler uses to download the binary program file into the Picaxe being programmed. Something like:

1. PE Sends Break and waits up to 5 sec for Picaxe to respond
2. PE Validate response
3. PE queries Picaxe for Firmware ID
4. Picaxe responds with $A5 followed by Firmware ID Byte
5: PE validates ID
6: PE Sends a 3 or 4 byte start command
7: Picaxe echos
8 PE Validates
9: Picaxce Sends $00 to tell PE to start programming
10. PE validates


A) PE then send sbinary data one byte at a time
B) Picaxe echos back each received byte as an ACK
C) PE receive & validates the ACK then increments to next bye
Repeat ABC till done
==============

These are just off the top of my head and are only meant to give you a general idea. But in the whole scope of things it is a very simple protocol. It is just difficult to implement directly via wireless due to required use of break signaling.

If you do not have one, then I suggest you get one of those $15 8-Chanel logic analyzers and use the RS232 Analyzer plugin to debug the Serial comms between the PE and the Picaxce being programmed.
 
Last edited:

johndk

Senior Member
I see. I haven't written a flash program and was under the impression one just filled flash memory with an image. Not so simple....

RevEd wouldn't want to publish those protocols, would they? That would save a lot of probing and guessing.

A suggestion for future Picaxe implementations would be to build in a 'flash from file (or image)' routine like so many hardware implementations have these days.
 

rossko57

Senior Member
A suggestion for future Picaxe implementations would be to build in a 'flash from file (or image)' routine like so many hardware implementations have these days.
But this is what PE does, programming the Picaxe from your file. Your problem is simply that the mechanism you want to use is not a good fit to the mechanism already provided.
 

johndk

Senior Member
My suggestion is that the chip have a built-in flash routine, eliminating the need for an external component such as PE. That would allow one to simply point to a binary image and active the routine to update the chip's programming. It would allow stand-alone re-programming without the need for a connection to a computer running PE.
 
Top