Serial data with XBee

port513

I would like to have the Prop to receive data from my PC with XBee transmission.
Ihave set it up and verified that I can send a character from PC and return it from my Prop.
But if I want to send more, like a string to my Prop, how should I do that?
How do my Prop know when there is data ready on the UART?

JonnyMac

If you're using FullDuplexSerial (or one of the variants) the .rxcheck() method will tell you if there is something in the buffer. If the buffer is empty, it returns -1, otherwise it returns the next character in the buffer.

port513

So I need to read it byte for byte?
What should I look for as an end character?

JonnyMac

If you're sending the string, you know those details. Here's an example from a project I'm working on where the device can receive command packets at any time.

pub get_rx_frame : len | c

'' Transfer rx'd bytes into working buffer
'' -- returns byte count

  repeat
    c := xbee.rxtime(1)
    if (c < 0)  
      quit 
    else
      rxbuf[len++] := c

I use .rxtime() in the event that I just catch the first character; at 57600 baud 1ms is plenty of time for the XBee to RX and stuff the characters into the serial buffer. My method returns the number of characters in my buffer; if it's zero, then there is nothing to do.

If you're program is sending simple strings, you can use this then treat the working buffer as a string -- but to do this, you need to clear it to zeroes before you call this method. Let's say you have an array of 40 bytes that you want to use as your working buffer after it's been pulled from the XBee. Clear it with bytefill like this:

bytefill(@rxbuf, 0, BUF_LEN)

In Spin -- a with may languages -- strings are simply an array of characters terminated with a NUL (0). Using bytefill ensures that you'll be good no matter how long the string is.

BTW... I don't use a specialty XBee object, I have a code block that handles the details I need. In the example above, xbee is an instantiation of my variation of FullDuplexSerial.

Electrodude

If you need to split your data into packets (i.e. delimited by end characters), you should consider using the XBee's packet (API) mode instead of normal AT mode. The main advantage of it over normal mode is that you can't lose parts of packets over a flaky connection: packets will either arrive completely intact or not arrive at all, as opposed to normal mode, which can drop parts of your data. API mode also does a checksum. The obex has two similar objects for doing this: Martin Hebel's original driver and my modification of his object that uses FullDuplexSerial4 instead of normal FullDuplexSerial, which allows you to have 4 uarts in one cog instead of just one, which saves cogs for applications with lots of uarts.

port513

Would it be possible to use dscan and dprint from the Prop side?
dscan should read a string right?

I'm using C/C++ BTW