How can I cram this data in?

Archiver

Hi everyone,
I've got a device sending the following data stream to my BS2:
<XYYYYZZ<CR>
XYYYYZZ<CR>
XYYYYZZ<CR>
MNNNNOO<CR>
MNNNNOO<CR>
MNNNNOO<CR>
Where < is a signal character that precedes the data block, X and M
are characters, Z's and O's are checksum characters that I ignore,
YYYY and NNNN are either numbers or hex error codes, depending on the
value of X and M respectively, and <CR> is a carriage return (ASCII
13).

X can be either a lowercase d or upper case R. d means that YYYY is
going to be a number, R means it will be a hex error code.

M is either an a, e, b or C. If it is a, e, or b, then NNNN is a
number, C means it will be a hex error code. For example:

<d0013AB<CR>
R00E1CD<CR>
R00E1CD<CR>
a02308A<CR>
e3332C5<CR>
b0023B2<CR>

I'm trying to play with SERIN, waiting on the "<" character with
modifiers to read in the string:

SERIN ... wait[noparse][[/noparse]"<",str firstchar\1,dec4 range,skip 25, str
fourthchar\1 ...]

The skip 25 is because I don't care about the 2nd and third lines of
data.

So, it seems to choke on my attempts. It gets the first character
and the decimal 0013, but then doesn't seem to have anymore data in
the remaining variables. Does the carriage return kill the SERIN
process and cause it to abort? If so, is there a way around that?

Does anyone have a better way of doing this? I'm only receiving at
9600 baud, so do you think I can wait on the "<" character and then
stream the remainder in, scanning for the X and M character types?
Please help!

Thanks in advance,
matterama2001

Archiver

In a message dated 7/14/02 01:27:33 Eastern Daylight Time,
matt.ryan@p... writes:


> I'm trying to play with SERIN, waiting on the "<" character with
> modifiers to read in the string:
>
> SERIN ... wait[noparse][[/noparse]"<",str firstchar\1,dec4 range,skip 25, str
> fourthchar\1 ...]
>
> The skip 25 is because I don't care about the 2nd and third lines of
> data.
>

When you serin "dec data", Stamp will wait for the next non-decimal number.
If the first byte of your second string is a number, it will just freeze
there. Try putting the second serstring in a second serin and see what
happens.

Sid


[noparse][[/noparse]Non-text portions of this message have been removed]

Archiver

At 9600 baud your BS2 struggles to keep up with the data stream.
You need to keep things as simple as possible within the SERIN, and
delay as much analysis and decision-making (DECx, STR, \n, etc.) as
possible until after the SERIN is complete. The following will
use/re-use 20 of your 26 bytes of variable space, but may do the
trick:

SERIN...[noparse][[/noparse]WAIT "<", a1,b1,c1,d1,e1, SKIP 19, a2,b2,c2,d2,e2,
SKIP 3, a3,b3,c3,d3,e3, SKIP 3, a4,b4,c4,d4,e4]

This reads the 20 bytes you really care about into 20 byte
variables. Then they're available for examination,
conversion/computation/interpretation etc.

Also, assuming firstchar is a byte variable, note that

SERIN ...[noparse][[/noparse]... str firstchar\1...]

works the same as

SERIN ...[noparse][[/noparse]... firstchar....]

except the latter makes things easier and faster for your Stamp.

Regards,

Steve

Archiver

Hi Matt,

As others have pointed out, the BS2 takes a long time to interpret
the SERIN modifiers like DEC and SKIP and WAIT, too slow to keep up
with full tilt 9600 baud input. If you have control over the device,
then for better results be sure it is set for two stop bits, and add
extra inter-character pacing, or reduce the baud rate to 1200. But
sometimes the input device is a given that you have no control over.

The BS2sx is faster than the BS2, so it might be able to keep up
better. Or better yet, the BS2p has the SPSTR modifier that could
easily cram your 9600 baud string into the scratchpad RAM to be
parsed at leisure.

-- regards,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com

Archiver

Thanks Tracy (and everyone else). I actually switched to the SX last
night and it helped alot. I was fighting the BS2's throughput with
my inefficiency! So now I have been able to read in the strings I
care about, but...
In order to get it in quickly, I put everything into a byte array,
then subtract off the ASCII code 48 ("0"). Then I do some math on
stuff. For example:
data input = "d062012"
gets put into the byte array DATASTRING(8)
So, DATASTRING(0) = "d", DATASTRING(1) = "0", etc.

I only care about the last 5 numbers (62012), so then, I subtract off
the ASCII code:
for i = 2 to 6
DATASTRING(i)=ABS(DATASTRING(i))-48
next
Then, I try to reconstruct the number for use in later math:
AZVALUE = DATASTRING(2)*10000+DATASTRING(3)*1000+...+DATASTRING(6)

The problem is, AZVALUE doesn't end up equal to 62012. It looks like
it is treated as a two's complement number and wraps it over to 7458
or some other value (don't remember now). So then, I cut right to
the chase and did this:
debug dec (62000) and the output on the terminal screen was
3536!!!!!! What is this all about?? I fully expected 62000 back,
since I wasn't doing any math whatsoever!

Can you help?
Thanks,
Matt



--- In basicstamps@y..., Tracy Allen <tracy@e...> wrote:
> Hi Matt,
>
> As others have pointed out, the BS2 takes a long time to interpret
> the SERIN modifiers like DEC and SKIP and WAIT, too slow to keep up
> with full tilt 9600 baud input. If you have control over the
device,
> then for better results be sure it is set for two stop bits, and
add
> extra inter-character pacing, or reduce the baud rate to 1200. But
> sometimes the input device is a given that you have no control over.
>
> The BS2sx is faster than the BS2, so it might be able to keep up
> better. Or better yet, the BS2p has the SPSTR modifier that could
> easily cram your 9600 baud string into the scratchpad RAM to be
> parsed at leisure.
>
> -- regards,
> Tracy Allen
> electronically monitored ecosystems
> mailto:tracy@e...
> http://www.emesystems.com

Archiver

>So then, I cut right to
>the chase and did this:
>debug dec (62000) and the output on the terminal screen was
>3536!!!!!! What is this all about?? I fully expected 62000 back,
>since I wasn't doing any math whatsoever!


In twos complement, 62000 does in fact represent -3536. But the DEC
modifier should display the number as unsigned, and only SDEC would
display it as signed.

>for i = 2 to 6
> DATASTRING(i)=ABS(DATASTRING(i))-48
>next
>Then, I try to reconstruct the number for use in later math:
>AZVALUE = DATASTRING(2)*10000+DATASTRING(3)*1000+...+DATASTRING(6)

You should not need the ABS in there. The following loop should
calculate it all at once...

AZVALUE=0
for i = 2 to 6
debug datastring(i) ' check numerals
AZVALUE = AZVALUE*10 + (DATASTRING(i) -48)
next
debug tab, ? AZVALUE ' check result

-- regards
Tracy Allen
electronically monitored ecosystems
http://www.emesystems.com
mailto:tracy@e...