serrxd timeout problem

Volhout

New Member
After programming picmicro assembly for more that a decade, I found the picaxe processors on the web. And they offer quite a bit of functionality that I had to craft myself in assembly before. So I ordered a 28X2 and build a breadboard, so see if this picaxe system is any good.

I am surprised. It really works well !! The only drawback I found so far is that none of the USB-serial convertors I had available works (so in the end I will have to purchase the picaxe one). Currently use a P4 PC which still has a single serial port.

Since I would like to have a seemless integration between IDE and serial port control, I was surprized to see there is a serrxd and sertxd set of commands. Bravo !! But (unless I misunderstood) I have not been able to make this seemless integration work.

I would like to achieve that the picaxe board goes into programming mode as soon as I close the terminal window in the IDE (so I can re-program the chip). I wrote a short routine to try this, where I wait for 1 second (time to be determined) for characters from serrxd, andthen check for programming mode, and back to serrxd. I use the timeout command for that.

Problem is .... it works in the simulator ... but it does not work on the actual picaxe chip. See attached code ....

Code:
'demonstrator to use programming serial port also for debugging
'and control.

'use PICAXE 28X2, running internally at 8MHz, therefore
'timing and frequencies are double.
'baudrate = 9600, timeouts are in 0.5mSec steps.

main:
	'we scan for 1 second if a command is issued
	'if not we print a "." and scan for another second
	'in between we reconnect to allow interruption from
	'the programmer.

	
	do
retry_it:	disconnect
		serrxd [2000, timout],b0	'2000 = 1 sec, get char
		reconnect
		sertxd (#b0)		'reply char ascii code
	loop until b0 = 113			'if q then quit
	sertxd (13,10,"terminated")

	do
	loop until b0 = 0			'wait forever
					'problem here ... for some reason
					'we seem to fall back in the first do loop
	end


timout:
	'this timeout happens inside the do loop
	'if we return to the do loop we do not cause a 
	'stack conflict (I hope).
		reconnect		'needed ?
		sertxd (".")		'activity dot
		goto retry_it
What happens is that after the termination with a "q", the simulator jumps to the infinite do loop. But the actual 28X2 ends up (I am nort sure how) in the first do loop, the one with the serrxd command, and the timeouts continue after printing 2 rubbisch characters.
There must be some stack problem, that does not show in the simulator.

Can anybody show me where I go wrong ? I am not sure what happens with the timeout. Does the timout leave the stack in place (in other words, 1 level up in the do loop), or does it flush the stack ?
 

Buzby

Senior Member
Hi Volhout,

Welcome to the forum !

Start simple !.

The PICAXE is always ready to accept a new program, even while it running.

The program download starts with a 'break', which the PICAXE sees and switches to download mode.

The 'disconnect' and 'reconnect' are not needed for 99% of PICAXE programs, even ones using sertxd and serrxd.

'disconnect' stops the PICAXE listening to the serial line, so it will never see the request from the PC.

Cheers,

Buzby
 
Last edited:

Volhout

New Member
Hi Buzby,

Thanks for the welcome and the quick reply. I have simplified the program to loop around serrxd and sertxd (basically echo-ing everything that comes in via the serial port) but as long as I am in that loop I can only re-program the chip if I hard reset. That is nice for development, but not interesting when the reset button is in a remote location (sealed test chamber), and you want to upgrade software.

I tried without the disconnect and reconnect, but that does not work. I have managed to make it work with the disconnect and reconnect, but not via timeout, but via the termination with "q".

Code:
main:
	disconnect
	do
		serrxd b0			'wait infinite for char
		sertxd (b0)
	loop until b0 = 113			'q

	sertxd (13,10,"terminated")
	reconnect

	do
		'nope
	loop until b0 = 0			'forever
	
	end
That works ..... but only if the termination character is "q". If you terminate with "quit" the serrxd receives 3 more characters, and some way these show up corrupted in the terminal window ("fzx" behind "terminated") and the programmer can only access the chip after hard reset. See attached.

flush.JPG

Maybe I am asking something unique, and I should run 2 RS232 cables into the test chamber ? I feel this is not something that is solved easilly.
Is there any way you know this could be done ?

Regards,

Volhout
 

MartinM57

Moderator
Is there any way you know this could be done ?
I'm a bit confused what you are trying to achieve. With no disconnect/reconnect commands in your code, the PICAXE will happily respond to being programmed at any time - OK, there are a few commands that will stop this, but are you using them?

I would like to achieve that the picaxe board goes into programming mode as soon as I close the terminal window in the IDE (so I can re-program the chip)
What do you mean by this?
 

hippy

Technical Support
Staff member
That works ..... but only if the termination character is "q". If you terminate with "quit" the serrxd receives 3 more characters, and some way these show up corrupted in the terminal window ("fzx" behind "terminated") and the programmer can only access the chip after hard reset.
It is because you are sending more than the "q".

After the "q" the program reconnects and waits for download. With download enabled the subsequent "uit" confuses the 28X2; it thinks it's a possible download initiation when it is not and after a short delay restarts the program, disconnects again, requiring a hard-reset ( or sending a "q" to reconnect ). You will better see what is happening if you add a SERTXD to the start of your program.

After sending "q" to the program and having it terminate you should not send anything further via the terminal.
 

Volhout

New Member
Thanks for the feedback.

hippy: that makes sense, and should be possible to achieve that I only send the q. I wanted to make it more robust. Read below, I can always reset the board by removing +5V en repowering, but I am not sure what the servo's will do during this process, if they glitch, I loose test samples. And opening up the chamber during a test is a no-go.

MartinM57: I have an environmental test chamber where I need to re-position material during the test. I plan to do this with RC servo motors, under control of a Windows PC running a Visual Basic program that also controls other equipment. Mechanically I need 7 servo's to make the re-positioning. I use the picaxe to receive instructions from the Visual Basic program via serial port. The picaxe will be inside a sealed box with the servo's in the environmental test chamber. During development phase I would like to have the ability to re-program the picaxe easilly. To get electrical cables into the chamber is difficult (sealing), so I would like to run as few wires as possible. Currently it is +5V, RX and TX for serial control/download and GND.
The commands I use are serrxd and sertxd. And yes, these interfere with the programmer, since they use the same I/O pins. I have tested without disconnect and reconnect, but that simply does not work on my test board.
 

MartinM57

Moderator
I can always reset the board by removing +5V en repowering, but I am not sure what the servo's will do during this process, if they glitch, I loose test samples. And opening up the chamber during a test is a no-go.
What might they do while the PICAXE is being re-programmed - suggest you test both cases and find out :)
To get electrical cables into the chamber is difficult (sealing), so I would like to run as few wires as possible. Currently it is +5V, RX and TX for serial control/download and GND.
So run a 6 core cable instead of 4?
The commands I use are serrxd and sertxd. And yes, these interfere with the programmer, since they use the same I/O pins.
Perhaps consider using the timeout feature of serrxd in some way to get the PICAXE in connected mode periodically?
 

Buzby

Senior Member
Hii Volhout,

I would strongly suggest that you run a 6 core and use hser for control and coms, leaving the programming port available for programming and debugging.

Sertxd is very limited compared to even serin / serout, and hser beats them both !.

Keeping the program port free I would say is essential if you can't physically access your PICAXE.

EDIT :

Sorry, I missed you were using servos.

In that case definatley don't use sertxd/serrxd/serin/serout. See manual 2 about conflicting commands.

Run 6 wires and use hser.

Cheers,

Buzby.
 
Last edited:

hippy

Technical Support
Staff member
This is a more resilient way to take a PICAXE back to downloading but you still mustn't send anything through terminal after "Ready for download" is reported.

Code:
#Picaxe 28X2
#Terminal 9600

Disconnect

SerTxd( CR, LF, "Started", CR, LF )

Do
  SerRxd b0
  SerTxd(b0)
Loop Until b0 = "q"

Do
  SerRxd [2000,Terminate], b0
  SerTxd(b0)
Loop

Terminate:
  SerTxd( CR, LF, "Ready for download", CR, LF )
  Reconnect
  Do : Loop
 

Volhout

New Member
Hi Buzby,

I will take your advise, and start using hser (in the background). I missed the remark about the real time conflict between the serrxd/txd and servo commands.
I assumed since the servo pulses continued throughout the program, they would run independently, under interrupt. And as such it should not disrupt timing on the 9600 baud serrxd command (I assume this is timed with clock cpu cycles) too much. But I have been mistaken about the complexity of the interrupt routine, and the delay it causes.
A lot of assumptions .... glad you showed me the warning...

Regards,

Volhout

P.S. we can close this topic now... I know what to do ...
 

Buzby

Senior Member
Hi Volhout,

I'm glad you chose to use hser for comms & control, you will make much smoother progess using this.

I found the picaxe processors on the web. And they offer quite a bit of functionality that I had to craft myself in assembly before.
The PICAXE can drive a huge range of 'stuff', like your servos, with out any complex code.
( You may also need some temperature sensors in your environmental chamber, PICAXE 1-Wire device support is built in. As is I2C, and SPI. )

One point I would like to raise might be an issue.

When a programme download is active the I/O state changes.

I've never tested to see exactly what happens, but if you have servos running and then download a new program they may glitch.

There are plenty members of the forum with huge experience running servos on PICAXE, they will know.

And that leads us on to the best thing about PICAXE - The Forum !.

If you have any questions at all, the forum is the place to ask them.

We've got members here who know everything from flashing a LED, to communicating with weather balloons !

And they don't bite !

Cheers,

Buzby
 

Volhout

New Member
Buzby,

When a programme download is active the I/O state changes
I haven's seen servo glitches yet, but I am testing with some old toolbox servo's from a scavenged RC airplane. And the actual project servo's may behave different.
After giving it a bit of thought (fruitfull, these tips from your side), I will add pull-up/pull-downresistors to the layout, so I can forse the servo control lines to a "safe" state for the servo's during reprogramming. The actual servo's are digital, and are tested to have no position loss when the input signal is cut off. Only thing I need to ensure is that I do not stop the servo signal in the middle of a active pulse. It must terminate at the end of a 20mSec loop. I will put a logic analyzer on the 8 (7) servo lines and check if the servopos x,OFF correctly terminates the servo pulses, or if it cut's them in halve....

Another bit of thought......

Regards, and thanks for all the advise...

Volhout
 
Last edited:
Top