Better method of waiting on eb500 data?

SamM

I have an eb500 bluetooth module working with a bs2 (no BOE or other boards). I've connected the two together and have managed to send data from the bs2/eb500 to my bluetooth dongle on my pc and vice-versa. I'm reading the data at both ends fine.

After experimenting with the examples in the eb500 docs, I'm noticing that the presented method of waiting on data to arrive at the eb500 (from the PC/bluetooth dongle in my case) is to use something like

<simplified example>
attempt to establish a connection with SEROUT
wait for the acknowledgement with a SERIN
If the connection status pin goes low, then assume we're connected
Set the commandmode pin high to enter data mode
Sit and wait on a SERIN command until data arrives.

It's the last part that I'm having difficulty with understanding. This seems like an extremely unfriendly manner of waiting for data. Perhaps I'm just too used to event-based programming, where I'm doing thing until the "event" of data arriving calls the proper code. Is this the preferred method of receiving data from the eb500--that the code must come to a stop and wait at this command until it arrives, unable to recover if data never appears? Or is there perhaps a pin on the eb500 that activates when data arrives, and can therefor be scanned in a loop and therefore trigger/goto a SERIN at the appropriate time.....? I'm hoping I'm overlooking something.

Mike Green

There is an optional SET FLOW CONTROL described in the documentation that requires the use of 2 additional I/O pins. One pin (when true) indicates that the Stamp may send data to the eb500. The other indicates when the eb500 has data to receive. It doesn't tell you how much data is present, only that at least one byte is there. You could use it to do the SERIN which will have to wait in any event for all of the data to arrive before the Stamp will go on to the next statement. Stamps are single threaded. They can only do one thing at a time and none of the I/O is buffered. For many applications, the Stamp couldn't do anything anyway until the Bluetooth data arrives. The exception usually is when the Stamp is expected to sample other kinds of I/O like a keypad that might be used to abort some operation or override the Bluetooth data or some such thing.

By the way, the SERIN does have an optional timeout (look at the manual for SERIN), but the Stamp will miss the Bluetooth data if it's not actually waiting at a SERIN when the eb500 sends it.

Andy Lindsay (Parallax)

Use the SERIN command's optional timeout and poll for messages. It's the way to go. The eb500's flow control is buffer based; whereas, the BASIC Stamp's flow control is byte-by-byte. The two are not compatible. Also, eb500 modules Rev C and later do not have a flow control option any more.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Andy Lindsay (Parallax)

Here's an·excerpt from BoeBotControlForMsrs.bs2, which is available for download in a .zip file at the bottom of: http://www.parallax.com/detail.asp?product_id=28118.· It sends servo control pulses periodically, and then goes back to waiting for the message.· On the other end, the·PC transmits the same message·repeatedly until it recieves an acknowledgement from the BASIC Stamp.· Both PC and BASIC Stamp index each packet to make sure that a given packet doesn't get missed or acted upon twice.

DO   Resume:                                    ' If Message not rcvd, try again
  IF IN5 = 0 THEN Reset                      ' EB500 disconnected?
  PULSOUT 13, tLeft                          ' Servo control pulses
  PULSOUT 12, tRight
  SERIN 0, 84, 5, Resume,                    ' Get next command
       [noparse][[/noparse]WAITSTR buffer \ 2, buffer2,
       buffer3, buffer4]
    .
    .
    .
 
  ' Increment message index for reply.  Next message from PC has to use
  ' reply's buf[noparse][[/noparse]1].
  msgIndex = msgIndex + 1
  buffer1 = msgIndex
  SEROUT 1, 84, [noparse][[/noparse]STR buffer \5]
LOOP

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

SamM

My eb500 is rev d, so that should rule out using flow control according to Alex, thanks. Mike stated that

"the Stamp will miss the Bluetooth data if it's not actually waiting at a SERIN when the eb500 sends it"

Wouldn't this be a problem if the code is doing something akin to:

ScanKeyboardForKeyPresses
DoWhateverKeyPressSuggests
SERIN 'wait small amount of time according to timeout
DoWhatever Bluetooth data suggests
Start again

....because anytime the statements other than SERIN are doing something, the data would be lost that was coming in via bluetooth? If so, how do I make sure that I never miss the incoming bluetooth data? Wouldn't Andy's BoeBot example be relying on pure chance that it is sitting in the SERIN timeout when data arrived?

Perfect world (albeit without compatible flow control) you would expect something like

if SERIN>0 then
'do bluetooth stuff
else 'no data arrived
'do nothing, continue with other code
endif

Unsoundcode

Hi Sam, unfortunately BS2 serial input is not event driven but there are techniques that can used to improve its speed and reliability especially if you have control on what the PC is doing.

Just relying on a timeout may or may not·be unacceptable because of the amount of data you "miss" but if you can set up the PC to continually transmit at 10mS intervals and use a 20mS timeout you will increase your chances of capturing data every time.

That might still not be good enough depending on data length the timeout may have to grow to where it slows the program down too much. An alternative could be software flow control, transmit a serout[noparse][[/noparse]"get_data"] followed by a serin[noparse][[/noparse]in_data]. This exploits the fact that the PC has an event driven routine and will transmit on demand.

Whichever method you choose it is advisable to give your data a header so that the serin will always capture the complete and not a partial string.

Jeff T.