Picaxe 08M2 - Using the programming port for other serial comms

paulwww

New Member
Dear picaxe users

I am using a picaxe 08M2 to bridge between a bme280 sensor and a raspberry pi. I am tight on i/o, so am using the programming port for serial communications with the pi. This works flawlessly, except for one issue:

when the picaxe starts up, it repeatedly emits a string of non-printable characters ending in PY on the serial out pin.

I assume this is some message back to the host workstation. I am using the disconnect command and preceding this with a pause 1000 but this does not stop the transmission. The only way I have found to stop it is to disconnect the serial in, and ground it for short period. The problem is when the power cycles the picaxe starts transmitting again. I guess there must be a command to stop this happening?
 

hippy

Technical Support
Staff member
Sounds like however you have connected the Serial In pin it is either floating or high when the PICAXE powers-up which is causing it to enter its download mode and what you are seeing is part of the signalling that the PICAXE has done that.

It may however be that the Pi is starting and then entering its download mode. Putting the DISCONNECT command as the first command, before any PAUSE, may improve things.

What is your circuit for the download interface on the Serial In pin and what is that connected to on the Pi ?
 

AllyCat

Senior Member
Hi,

I guess there must be a command to stop this happening?
Probably not. When power is applied, the first thing that a PICaxe ALWAYS does (before any previously-loaded program runs) it to check for a new Program download (which involves transmitting some data on the SerOut pin, if Serin is High). So the DISCONNECT is not executed and the PAUSE can only make matters worse (more time for the SerIn to go high and attempt a "new" download)..

Therefore you need a hardware solution, generally a switch or Pin-Links. But the trick I use is to increase the normal 22k programming resistor to 100k and connect the Serial Input (from the "Pi" not the Programmer) directly to Leg 2 via a diode so that it can only pull the Pin Low (i.e. anode to pin). Now, the "Pi" cannot pull the pin High, but of course you must (still) ensure that it does not pull the pin Low when you are programming the PICaxe.

To allow the "Pi" to talk to the PICaxe, the PICaxe program must first use a DISCONNECT and then enable the internal "Weak Pullup Resistor" (which is about 30k) on the SerIn pin, Leg 2. This allows the programming/serial input pin to go High and the "Pi" can pull it low via the diode. However, the PE will generate an "error" if you try to enable the WPU resistor on Leg2 using the PULLUP command, so you must use the equivalent SFR command POKESFR $8C,32 . This should work with 08, 14 and 20M2s, but not 18M2 or X2s.

Cheers, Alan.
 

paulwww

New Member
The circuit I am using is the very simplest. I have TXD on the Pi connected directly to serial in on the picaxe, and Pi RXD directly connected to serial out. This worked flawlessly, even over very long distances (~12m) albeit at a conservative 4800 baud rate. It was just the initialisation that was problematic. I followed hippy's suggestion and removed the pause before the disconnect, and this does appear to prevent the picaxe from going into download mode. I will monitor the situation and see if this works long-term. I was hoping to avoid a hardware change as I have my pcbs already fabricated, but nice to know about this approach just in case I need it in future.

Thanks for all your help!
 

SteveDee

Senior Member
I invert the serial lines for my Pi <> Picaxe serial comms projects, and that works fine.

By adding a power link to the Picaxe I can also use the Pi to reprogram the Picaxe if the need arises.
 

paulwww

New Member
Interestingly, I don't invert my lines and the data coming back from picaxe to pi is interpreted correctly, however, I do have to translate my command codes going from pi to picaxe. e.g.

A >> _
B >> /
C >> ^
E >> ]
F >> .
J >> -
K >> Z

I don't think I ever understood quite what was happening here.
 

hippy

Technical Support
Staff member
I don't think I ever understood quite what was happening here.
Perhaps post your PICAXE code and it may become obvious what the issue is and that can be explained.

It does seem odd that you need to convert data sent but not data received but that could be the case if mixing SERRXD and SEROUT with a Txxxx baud rate, or if there is some polarity or baud rate mismatch.

Depending on what your full circuit is; providing there is a current limiting resistor on Serial In, it may be possible to resolve the issue using just a signal diode between Serial In (anode) and Serial Out (cathode). That should be easy to add as a fix to existing boards.

Post full details of your circuit and it will be easier to assess.
 

paulwww

New Member
Here is the circuit:

BmeCircuitDiagram.png

and here is the relevant section of the picaxe code:

Code:
'Init Serial
   disconnect
   setfreq m4 'Default
   hsersetup B4800_4,%000
   'bit0 - background receive serial data to the scratchpad (not M2 parts)
   'bit1 - invert serial output data (0 = ?T?, 1 = ?N?)
   'bit 2 - invert serial input data (0 = ?T?, 1 = ?N?)
   
Timeout:

   hserout 0,("timeout")
   
Top:
   
   SerRxD [20000, Timeout], b12          'Read serial in port and wait for cmd byte
   
   If b12 = "_" Then
   
       'Read Chip ID
       
   ElseIf b12 = "/" Then
...
Else
	hserout 0,(b12, "error")
   EndIf

Goto Top
 

AllyCat

Senior Member
Hi,

IMHO, there should ALWAYS be a pull-down resistor on the PICaxe "Programming" input (Leg 2), there really aren't any exceptions. But its value may be open to negotiation. ;)

Cheers, Alan.
 

westaust55

Moderator
Hi,

IMHO, there should ALWAYS be a pull-down resistor on the PICaxe "Programming" input (Leg 2), there really aren't any exceptions. But its value may be open to negotiation. ;)

Cheers, Alan.
Concur with Alan.

In fact I have used a pulldown resistor as high as 100 kOhm when there is no permanently connected programming circuit on the SerialIn pin and not had problems over several circuits done that way.
 

SteveDee

Senior Member
I invert the serial lines for my Pi <> Picaxe serial comms projects...
Just to clarify my earlier comment, I was talking about hardware inversion, not software.

I seem to remember that the Pi uses "high going low" convention, while the Picaxe uses "low going high". So when the Pi TXD is not sending data it is high, but you want the Picaxe serial in to be low (hence the inverter).
 

paulwww

New Member
Ok well it looks like I will need to incorporate some modifications into the next revision of the board, but removing the pause before the disconnect has definitely fixed my problem, so I'm happy. Thanks for all your advice.
 

paulwww

New Member
Stevedee's comment that he uses hardware inversion has thickened the plot! I am not using any inversion in or out, and my transmissions from the picaxe e.g. timeout, error, numerical data is all interpreted correctly by the pi. This is not the case for codes transmitted by the pi, hence my conversion table posted earlier. So something strange is happening - but reliable.
 

hippy

Technical Support
Staff member
I had earlier missed post #8 which reveals exactly what is going on.

For input you are using SERRXD which is idle-low which needs the Pi-to-PICAXE data inverting - which your mapping seems to achieve without using actual hardware inversion.

For output you are using HSEROUT with that configured via the HSERSETUP as idle-high which is as the Pi expects.
 

SteveDee

Senior Member
Stevedee's comment that he uses hardware inversion has thickened the plot!...
It seems to me that software inversion/conversion will work just fine when the hardware is up-and-running, and comms will work as expected.

The reason I used hardware inversion is to overcome any problems when power is applied to the system and either/both Pi and Picaxe "boot". If the hardware in your configuration starts off in the default condition, then you can expect problems. If your previous instructions to reverse the convention somehow remain persistent, even when the power is coming back up after power loss, you wont have a problem.
 
Top