How to determine incoming string length

xanatos

I am using the Datalogger and two XBee Pro XSCs, and two BS2SXs.·

The "TX" side of the two systems will be reading in data from the PINK Server using the SERIN function, and that data will be written to the datalogger and sent via the XBees to the remote unit where it will be acted on in some way (mostly a comparison of time information with the local DS1302 clock on that end).

The data read from the server may be of varying lengths - I have done what I can to standardize the lengths of the most important parts - the date & time stamp - but I also need to collect variables that will contain an undeterminable data length.· It could be names, operator numbers, almost anything.

The datalogger needs to know ahead of time how much data you will be writing to it.

How can I make this determination programattically so I can tell the datalogger's write routine how long the data string will be?

On a related note, the XBees need to know how much data to read on their SERIN line.· Here's the code:

[noparse][[/noparse]code]
RX········· PIN 14···················· ' Receive Pin
TX········· PIN 13···················· ' Transmit Pin
X·········· VAR Byte
HIGH TX······························· ' Idle transmit pin
DO
· SERIN RX, 84, [noparse][[/noparse]STR X\16]··············· ' Receive data
· DEBUG STR X, CR
LOOP
[noparse][[/noparse]/code]

Right now, on the TX side, I am just adding a bunch of spaces at the end of the string ( SEROUT XTX, 240, [noparse][[/noparse]"Hola! X is ", DEC X, "······ ", CR] ) and letting the receive side's STR specification truncate the data after a fixed point...· but I'm thinking there has GOT to be a better, more precise way of doing this.· Ideas?

Thanks very much,

Dave X


·

Mike Green

First of all, you're using X as a 16 byte array. You need to declare it as such ("X VAR Byte(16)"). What you have works, but you'll run into problems if you declare any other variables.

You need some kind of delimiter at the end of your string. One that's easy to use is CR since you already have that on your transmit side. Change your "STR X\16" to "STR X\16\CR". The SERIN statement will fill the rest of the string with zero bytes when it gets the CR character. To find the length of your data, you just have to search X for a zero byte like:

length = 0
DO WHILE length < 16
   if X(length) = 0 THEN EXIT
   length = length + 1
LOOP

An alternative option is to send the length of the string as a byte so you might have:

SERIN RX,84,[noparse][[/noparse]length,STR X\length]

Post Edited (Mike Green) : 6/23/2009 4:46:16 PM GMT

xanatos

That looks good, I'll try that out, looks exactly like what I need, Thanks!!!

Curiosity - in regards to "run into problems if I declare any other variables" - I am still somewhat fuzzy on this subject. Will just declaring it eliminate those problems? And... what kinds of problem symptoms would I encounter if I declared other variables... I ask because knowing this might help me understand better what I've read on this subject.

Thanks again, this is great info.

Dave X

Mike Green

The Stamp PBasic compiler allocates variables from the available pool of 26 bytes (for the BS2 Stamps). If you declare X as a byte, then Y as another byte, the compiler will put Y immediately after the first (only) byte of X. If you're using X as an array, Y becomes the same as the 2nd byte of the array (X(1)). That's probably not what you want. If you declare X as an array of 16 bytes, the compiler knows to put Y after the 16 bytes (in the 17th byte of the variable space).

Complicating this, if you have variables of different sizes (byte, word, nibble, bit), the compiler sorts these so the words come first, then the bytes, then the nibbles, then the bits. This is so no space is wasted in making sure that things are aligned to the proper storage boundaries.

xanatos

Thanks - now I get it! On to my next question - variable persistence after a power failure...

Dave