​ ​ ​ ​ X2 Background Receive
Results 1 to 8 of 8

Thread: X2 Background Receive

  1. #1
    Senior Member
    Join Date
    Jun 2014
    Location
    Canada
    Posts
    121
    Blog Entries
    1

    Default X2 Background Receive

    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?

  2. #2
    Senior Member
    Join Date
    Feb 2010
    Location
    Don't Mess With My Texas!
    Posts
    2,296

    Default

    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
    - Tex
    __________________________________________________ _______________________
    "Truth lies dormant in our future history." ― Tex Clodhopper LXV
    “Confidence is ignorance. If you're feeling cocky, it's because there's something you don't know.” ― Eoin Colfer, Artemis Fowl

  3. #3
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    23,878

    Default

    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
      Do
        Do : Loop While ptr = hSerPtr
      Loop Until @ptrInc = 100
      Do : Loop While ptr = hSerPtr
      b0 = @ptrInc
      Do : Loop While ptr = hSerPtr
      b1 = @ptrInc
      SerTxd( #b0, " ", #b1, CR, LF )

  4. #4
    Senior Member
    Join Date
    Jun 2014
    Location
    Canada
    Posts
    121
    Blog Entries
    1

    Default

    Thanks Hippy, could you just explain the:

    Loop While ptr = hSerPtr

    part of the code

  5. #5
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    23,878

    Default

    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.

  6. #6
    Senior Member
    Join Date
    Jun 2014
    Location
    Canada
    Posts
    121
    Blog Entries
    1

    Default

    so the marker byte would be similar to using a qualifier as with serin/hserin?

  7. #7
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    23,878

    Default

    Quote Originally Posted by JSDL View Post
    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.

  8. #8
    Senior Member
    Join Date
    Jan 1970
    Location
    Perth, Western Australia
    Posts
    4,383

    Default

    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.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •