08m Serin weird behavior

steliosm

Senior Member
Hello all.

I'm creating a small circuit with an 08m chip to make it act as a USB device.

I have the board connecting to my PC using an 'el cheapo' USB-2-ttl cable - no problems here. Since I need to control the 08m from an application running on the PC and also avoid having the 08m stuck on the serin command I have setup an interrupt on the serin pin. When I need to send a new command to 08m I send chr(8) to trigger an interrupt, wait a few ms and then send the single character command.

This is the command to set the interrupt:
setint %00000000, %00001000

This is the interrupt routine:

Code:
interrupt:
   ' Set the LEDs off
   low DISPLAY
   ' Store the old CMD
   let OLDCMD = CMD
   ' Get a new command from the PC
   ' Display the command prompt
   serout 1, t2400, ("*?")
   ' SerIn to get the command
   serin 3, t2400, #CMD
   ' Send audio feedback
   sound 2, (110,10)
   ' Pause before setting the interrupt again
   pause 200  
   ' Set the NEWCMDFLAG to 1
   let NEWCMDFLAG = 1
   ' Set the interrupt again
   setint %00000000, %00001000
   ' Return to main loop
   return
The problem that I'm having is that in order for the 08m to receiver and run the command I have to send 0x08 + 0x36 + 0x00 (or any other character) instead of just sending the 'interrupt' character and the command character. Sending only the 'interrupt' character and then the command (0x08 + 0x36) makes the 08m to wait for another character. I can verify this behavior buy using an 'audio feedback' sound command.

At first I thought that it was probably the serial cable but after tapping on the serin pin using the bus pirate device I saw that every character send from the PC application is actually pushed down the serial link to the 08m. Sending the characters with a delay between them doesn't change anything.

It's not a problem anymore since I found a workaround. It's just that I would like to know if it's a bug or not.

I'm using 2 08m with firmware version 9.0
 

hippy

Technical Support
Staff member
The issue is almost certainly the #CMD ...

serin 3, t2400, #CMD

This reads a sequence of ASCII digit characters up to and including a terminator ( an ASCII non-digit character which is itself then discarded ).
 

steliosm

Senior Member
Hello Hippy and thank you for your reply.

I couldn't find a reference for this serin behavior in the datasheet but it certainly explains why the 08m just sit's there and waits one more character.
I could possible use CMD instead of #CMD. I'll have a go with the code and see I can change.
 

hippy

Technical Support
Staff member
True, the manual description, "Optional #’s are for inputting ASCII decimal numbers into variables, rather than raw characters" doesn't fully explain the situation in itself and relies upon recognising that the PICAXE needs to be able to determine when a number sequence has ended or when the number sequence may be continuing; that can only be determined by what was last received as there can be no knowledge of what will next be received.

I suppose, once it becomes clear how the PICAXE works with receiving #var, and it's clear there can only be one way it can work, it becomes 'self evident' it must work that way although it's not explicitly described as such. It's always debatable when anything 'self-evident' needs to be documented or in how much detail.

There are legitimate questions though; what happens with receiving into '#bit0', '#b0' and '#w0' when either one, three or five digits have been sent.

The way the firmware works is that the PICAXE will receive an infinitely long digit string ( applying 'result=resultSoFar*10+thisDigit' as it goes, truncating to 16-bit for a receive into '#w0', truncating to 8-bit for receiving into '#b0', and truncating to just the 1-bit for receiving into '#bit0', once the terminating non-digit character has been received.

For example ...

Pause 2000
Do
SerTxd( "Enter Number : " )
SerRxd #w0
SerTxd( CR, LF, "The number was ", #w0, CR, LF, CR, LF )
Loop

Entering 123456789X shows the number was 52501.

123456789 decimal is $75BCD15 hexadecimal.
$75BCD15 & $FFFF is $CD15, truncated to 16-bits.
$CD15 is 52501 decimal.
 
Top