Iphone Compiler?

[fritz42_male]

In the words of my supposed Management Consultant colleagues at work "There be dragons!". Which is an appalling phrase and whoever uses it should be shot on sight.

I prefer 'Caveat Emptor'

 

[dsvilko]

Dippy, there may not be any benefit for you 'cos you'd get fired. If you think about it though Rev-Ed are responsible for the manufacture or sale of almost all PICAXE products. If someone familiar with PIC programming could learn the protocol they could start making compatible products. Even worse they could make their software free under the GNU and let others make their own, potentially destroying rev-ed.

I am certainly no uC programmer but what you said seems to me over-the-top paranoid. The real IP is in the PIC firmware/bootloader and the compiler. Someone who would be able to replicate the firmware in his spare time would have no trouble discovering the download protocol (that would be the 'trivial' part of his project). The Picaxe BASIC documentation (available to anyone) is certainly infinitely more helpful in replicating the firmware than is the download protocol! Also, I see no advantage in trying to replicate the Picaxe firmware as opposed to writing your own, completely different firmware with similar functionality. If anything, reverse-engineering would almost certainly be harder and for what - so you would be able to sell uC forever branded as knock-off for a few cents less? It's not as there is an army of Picaxe programmers out there who are incapable in learning some other equally simple programming language or a huge amount of useful and open Picaxe BASIC code that adds so much value to Picaxe system that any possible competitor is doomed to fail. There is not a ton of similar products out there because writing the firmware is hard not because the (probably trivially simple) download protocol is not available.

Moreover, writing a j2me 'loader' application (with a server-side compiler) wouldn't even have to make the download protocol public. I am not sure that decompiling the java bytecode would be simpler than sniffing the protocol some other way.
I am sure that the Rev-Ed will add the wireless/phone programming possibility at some point in the future. It's just the question of weather they will be one of the first to do so or one of the last.

 

[dsvilko]

hippy and I discussed this years ago and came to the conclusion that the Rx would have to emulate the loader routine.
For some PICAXEs you may need to provide a reset signal to improve chances of download.

I know almost nothing about Picaxe wireless communication so please excuse me if I ask something stupid
Before I try, is there a obvious/known reason why I shouldn't be able to program the picaxe through serial bluetooth link (or any other kind of RF serial link for that matter)? What's so special about the serial download cable that the RF link can't provide? I'm sure it's been tried before so why exactly can't it work?

 

[chris bate]

I know almost nothing about Picaxe wireless communication so please excuse me if I ask something stupid
Before I try, is there a obvious/known reason why I shouldn't be able to program the picaxe through serial bluetooth link (or any other kind of RF serial link for that matter)? What's so special about the serial download cable that the RF link can't provide? I'm sure it's been tried before so why exactly can't it work?

i recall hippy tried somting like this and it didn't work out so well for the picaxe in question,

i will say this if i were to implement a download protocol i would base it off an existing protocol or simply packetise it with a crc on the end so it could be used over a rf network ,knowing Rev-ed they probably have an even simpler idea but thats the wonderful thing about mystery

 

[Technical]

What's so special about the serial download cable that the RF link can't provide? I'm sure it's been tried before so why exactly can't it work?

Nothing special about the cable or the serial protocol, but the main issue is the RS232 'break' signal required that bluetooth/wireless/infrared etc do not generally support.

The only realistic solution to wireless programming is like this

computer-microcontroller-rx/tx module ..... rx/tx module-microcontroller-PICAXE

We have done it, but don't see it as a commercially viable product. If you take, for instance, a XBee based solution the parts cost alone is going to be at least UK£50.

So the question really is what are people prepared to pay for such a system?

 

[dsvilko]

Nothing special about the cable or the serial protocol, but the main issue is the RS232 'break' signal required that bluetooth/wireless/infrared etc do not generally support.

Didn't know about the 'break' signal. Now it makes sense. It certainly makes things much more complicated, which is a pity.

 

[MartinM57]

No pictures - takes too long...but anyone can find this out in a few minutes with a decoding sope or logic analyser. Tested with 18M2 and assuming the RS232 link is at 4800 baud during programming

When a download is initiated, the programmer raises Serin and holds it high.

PICAXE responds on Serout with:
- 64 pulses of 1ms on/1ms off. These are either timing signals or 0xF0 ascii characters
- 2 ascii bytes (possibly PICAXE chip/firmware id?)

Programmer then lowers Serin (total time raised ~150ms from start - bit of a gap after the 2 ascii bytes are received) and sends two ascii bytes back (not the same as those just received)

Then there's a bit of to-ing and fro-ing between programmer and PICAXE with a few pulses of 2ms on/2ms off (or 0x00 ascii characters?).

Then the programmer sends a stream of bytes (the 'program'), each one echo'ed back by the PICAXE....finishing with 0x2F on my simple "do while b1=1: loop" program.

Then there's a whole load of 0x00 bytes sent by the programmer (and echoed back) - guessing it's clearing the rest of FLASH memory?

The "break signalling" is probably the 150ms period that the programmer raises Serin for at the start - not all USB adapters or rx/tx pairs will pass that through.

(what fun it must be for Technical to watch rank amateurs try to decode their IP )

Back to the day job...

 

[Technical]

(what fun it must be for Technical to watch rank amateurs try to decode their IP )

Anyone can look at the protocol with a serial analyser and decode it, but that is not really the point here, it's not exactly difficult to decode (ie basically receive a byte of data, and then echo it back for computer verification!).

The issue here about wireless programming is highlighted a couple of posts above - actually reliably implementing the RS232 break signal over wireless, not what the data sent back and forth actually is.