Programming over Bluetooth

hex

Well-known member
Apologies if already covered, but forum search found nothing obvious.

I proved to myself that home-made PICAXE programming over serial port is straight forward, once I realised that async serial signals (TTL) need to be inverted compared to standard TTL serial.

I am trying to migrate from desktop PC to laptop, and would like to avoid the mess of USB hubs and RS232 converters if I can.

The thought that comes to mind to use Bluetooth to carry UART-style signals between laptop (with PACAXE editor) and home-made Bluetooth receiver, with or without inversion of TTL serial Tx and Rx. 2 way async Serial over Bluetooth.

Am I missing something, or could this actually work?

Anybody tried already?

Many thanks
 
I'm sure it could be done ... but you'd probably need some kind of MCU on the bluetooth receiving end to handle the actual serial transaction with the PICAXE ... as @PhilHornby pointed out: there is the "break" signal, which is non-standard ... It'd be a fun challenge, but totally doable I'm sure.
 
  • Like
Reactions: hex
I'm sure it could be done ... but you'd probably need some kind of MCU on the bluetooth receiving end to handle the actual serial transaction with the PICAXE ... as @PhilHornby pointed out: there is the "break" signal, which is non-standard ... It'd be a fun challenge, but totally doable I'm sure.

Reading through the aforementioned thread, @Goeytex had it working - though with a couple of extra Picaxe's in the mix.

I investigated an alternative approach (using the Eltima Serial over IP software, a (old) copy of which is shipped with Picaxe Editor)). I had a cunning plan to use an ESP8266 at the programming end - but I didn't come close to having it working (at least, not for remote programming) :(

See: https://picaxeforum.co.uk/threads/s...cted-to-another-computer-over-internet.30564/
 
  • Like
Reactions: hex
Thanks PhilHornby and bpowell :)

"It'd be a fun challenge, but totally doable" - well I am certainly up for that challenge!

Break signal - interesting

"though with a couple of extra Picaxe's in the mix."
Is that a PIC at send AND receive end of link - if so, this makes the project pointless for me. Might as well just hook up USB hub to laptop, like I do now. Horrible, but works.
Two PICs at receive end... that would be fine

Need to go away and think some more...
Not as simple as I had first hoped, but then perhaps a whole lot more fun because of the challenge.

Need to read up on what Goeytex did, then either copy his method, or find my own.

Does modern serial Bluetooth have the capability to communicate a break signal?

Is the break signal sent by computer to PIC, or by PIC to computer, or both?
EDIT: now that I think a little - I reckon PIC bluetooth has to communicate a break to the laptop bluetooth serial port. To repeat previous question, can bluetooth send a break signal to laptop bluetooth?

Many thanks for the info so far, and for any more hints that might follow :)
 
Last edited:
Does modern serial Bluetooth have the capability to communicate a break signal?
Is the break signal sent by computer to PIC, or by PIC to computer, or both
I don't think so .... the "break signal" is just pulling the TX line low for a period of time ... more than a single character would pull it low ...
 
  • Like
Reactions: hex
I don't think so .... the "break signal" is just pulling the TX line low for a period of time ... more than a single character would pull it low ...
This seems to kill the project.

Pity :(

Will stay positive and try to think of a way.

Very much appreciate all of the input. A few words of wisdom from you guys has probably saved me weeks of failed effort.

Love this forum: love the world of PICAXE
 
I don't think so .... the "break signal" is just pulling the TX line low for a period of time ... more than a single character would pull it low ...
Hi,

Actually, the "Programming" signal pulls the slave PICaxe input pin HIGH for (up to) about 5 seconds, until the target responds with a High on its Programming Output Pin. Note that these are "genuine RS232" Polarity signals, not the (inverted) "RS232-TTL" Polarity and Levels more commonly found now. Then there is an interactive programming/verification process, witness an occasional Error message, usually when the supply rail is excessively low (e.g. flat battery supply).

I'm certainly not an expert on Bluetooth, but don't believe that it normally carries a Break signal, so you probably would need some sort of custom detection at the "sending" end of the programming path. :( Or perhaps sufficient "intelligence" at the receiving end?

Cheers, Alan.
 
  • Like
Reactions: hex
don't believe that it normally carries a Break signal, so you probably would need some sort of custom detection at the "sending" end of the programming path. :( Or perhaps sufficient "intelligence" at the receiving end?

Cheers, Alan.
Thanks Alan,

I am guessing that it is the PICAXE IDE that needs to see a break signal. (or perhaps more precisely, inverted break signal as sent by target PICAXE)
If Bluetooth cannot provide a break signal within my laptop, then I see no easy way to fool the IDE programming software.

Presumably the AXE IDE programs on the fly, so without modification, it will not send out a program.

I do not see that any amount of intelligence at the receiving end can get over the need for break.

I suspect that this is a lost cause, but I still live in hope that my understanding is flawed, or there is some obvious solution that I am missing

"Sufficient intelligence at receiving end" does not put me off right away, but modifying anything within the laptop seems like a killer.

"some sort of custom detection at the "sending" end" does put me off.

I suspect that I should give up on this quest.

All good stuff though, and I have learnt a lot today.

Many thanks
 
Last edited:
Hi,

A Logic Analyser (or even the PCB 'Scope) on the Programming I/O pins might give a few clues (but I've not tried this). My thoughts would be along the lines of sending a "preamble" to a separate (08M2) PICaxe, which monitors the Programming lines. It might be sent via the Terminal Emulator, or perhaps the "Check PICaxe Device Type connected" command (which probably uses a similar interface protocol). For example, an (ASCII) preamble (e.g. at a different baud rate) could cause the secondary PICaxe to apply a "break" signal to the target until the desired programming data begins to appear. But it might also be necessary for the secondary PICaxe to synthesise/override the return signals up to this point.

AFAIK, the baud rate in Bluetooth communications can be largely "notional" (which might be why the break command doesn't exist); On occasions I've had successful BT serial communications even when the baud rate was set incorrectly!

Cheers, Alan.
 
Since all on this forum have been very kind with assistance, thought I would give an update on progress.

1 Read this thread and the linked threads more carefully to get a better understanding of options and issues.

2 Built a breakout board to make monitoring with scope and Logic Analyser easier. Scope shows the long break signal periods that have been talked about.

3 Ordered up a couple of AXE028 adapter boards to make it easier to invert signals when desired.

4 Tried a few Bluetooth receivers, of which only HC06 appeared to offer any hope at all. Programmed HC06 for 4800 baud and used AXE028 to invert signals. Proved to myself what was already known: that HC06 will not do the job.

5 Decided to give up on Bluetooth for now, at least until a new brainwave occurs.

6 Will think about wireless Ethernet possibilities. I suspect that is not for me, but do not have a reason to dismiss the idea right now

Many thanks for all of the guidance :)
 
Back
Top