X2 Background Receive

JSDL

Senior Member
I am trying to receive some test data from my phone via Bluetooth (sending 2 integers between 125 to 175 consecutively), and output to the terminal via sertxd. Would this be the proper way of receiving the 2 values from scratchpad back to back:

Code:
setfreq m16
hsersetup b19200_16, %001

main:

ptr = hserptr - 1
sertxd (#@ptrinc," ",#@ptr,cr,lf)		; echo out

goto main
The first value is correct but second is not updating. When I only send one value, works perfect. Am I missing something? Should I use hserin 0,2 instead to read the values if they must be in order?
 

techElder

Well-known member
Why are you using "ptr = hserptr - 1" ?

From the manual ...

When a byte is received it is saved to this scratchpad
address, the hserptr variable is incremented and the hserinflag flag is set (must be
cleared by user software). Therefore the value ‘hserptr -1’ indicates the last byte
written, and ‘hserinflag = 1’ indicates a byte has been received
 

hippy

Technical Support
Staff member
Also, you don't know if you have received two bytes or only one. The best option is ...

Code:
Do
  Do : Loop While ptr = hSerPtr
  b0 = @ptrInc
  Do : Loop While ptr = hSerPtr
  b1 = @ptrInc
  SerTxd( #b0, " ", #b1, CR, LF )
Loop
It is possible that you could get the two bytes out of order depending when the program starts. The solution there would be to send a marker byte before the actual two numbers, say 100 which won't be in your actual data ...

Code:
Do
  [b]Do
    Do : Loop While ptr = hSerPtr
  Loop Until @ptrInc = 100[/b]
  Do : Loop While ptr = hSerPtr
  b0 = @ptrInc
  Do : Loop While ptr = hSerPtr
  b1 = @ptrInc
  SerTxd( #b0, " ", #b1, CR, LF )
 

hippy

Technical Support
Staff member
The hSerPtr indicates where the serial buffer has got to. Initially it is zero and increments to one on the first byte received. Ptr is also initialised to zero so, while it's the same as hSerPtr, no bytes have been received.

The Do-LOOP waits while the two are the same, waits until data has been received. Using the bX = @ptrInc, the ptr will chase hserPtr, catching up to it when there are no more bytes received that have not been dealt with.
 

hippy

Technical Support
Staff member
so the marker byte would be similar to using a qualifier as with serin/hserin?
That's correct.

You could use "HSERIN 0,2,(100)" to capture the marker then two subsequent bytes into scratchpad but using background receive allows all bytes to be captured, even while the PICAXE is busy processing what has been received so far.

The "HSERIN 0,2,(100)" will only capture what comes next, while the background receive mechanism handles everything that's been, and only waits when there's more to come.
 

inglewoodpete

Senior Member
Having used background receive for wireless data reception, you soon realise that data just arrives in the scratchpad and you have to write code that recognises a data packet's start or end point and can interpret the data that precedes or follows that marker. It's not easy: a one-byte marker can easily by confused with the data, corrupted data or a spurious noise byte.

I used a 20X2 with background receive from an HC-12 (much better noise rejection) and a checksum byte followed by a two-byte end-of-packet marker (which just happened to be CR, LF), meaning that I could also eavesdrop on the data stream with my PC. The PC was running the PE6's terminal with an HC-12/USB module plugged in as a COM port.
 
Top