STR ArrayVar question

[MikeRant]

This looks like a nice forum.

I have a question about HSERIN and STR ArrayVar - pertains to the other modifiers as well like WAIT and WAITSTR. These all work with a character array, what if you want to use a series of numbers? I need to receive a string like "192,28,56..." and trigger off let's say 192 and 28. The other modifiers like DEC and HEX don't work with with these modifiers. I can receive the whole string and then parse it but using these modifiers seems a bit more elegant if it can be made to work.

TIA

[HenrikOlsson]

Hi,
First of all welcome!

I'm not sure if I have a definite answer for you so I'll start with presenting you with a counter question instead ;-)

It's not clear to me if the numbers are received as text (string) or as values, ie. are you receiving [1] [9] [2] [,] [2] [8] [,] [5] [6] (9 bytes there) or are you receiving [192] [44] [28] [44] [56] (5 bytes there where 44 is ASCII for the comma) or are you not actully receiving the commas, ie [192] [28] [56] (three bytes there) ?

By the sound of it you're looking at the latest, if so it shold work with the WAIT modifier, like this:

myArray VAR BYTE[32]
i VAR BYTE
 
'Clear the array for testing purposes.
For i = 0 to 31
  myArray[i] = 0
NEXT
 
' Wait for [192] [28] [56] then receive up to 32 bytes or stop when received byte is [0].
HSERIN [WAIT (192,28,56), STR myArray \32 \0]
HSEROUT [STR myArray, 13]

/Henrik.

[MikeRant]

Hi Henrik, thanks for the welcome and the information.

There are 8 bytes in the "string" sent as 8N1 so it's "Start 192 Stop" "Start 28 Stop"... (sorry for the clumsy formatting, I don't know how else to say it). So it's the last example you gave I think. From your example it seems that the first three bytes are "thrown away" and the array doesn't start to be filled until the the WAIT condition is met. In this case these initial values must be stored as well for the checksum calculation.

I had a similiar related problem in that I wanted to use the STR ArrayVar to send a string to a "serial LCD" (as you show in your example). The array contains numbers, not characters. If I filled the array with characters ("A","B","C") it worked fine. If a number (192,28,36,etc.) was in the array it was not displayed on the LCD as a decimal value. I know that when sending a number by itself with HSEROUT I use the modifier DEC but this doesn't work with STR so I resorted to a FOR/NEXT loop to send the data.

Thanks again.

[HenrikOlsson]

Hi,
That "clumsy formating" makes perfect sense so yes, it would be the last example. And yes, with WAIT or WAITSTR it does wait for the specified qualifier(s) and THEN start "saving". I guess, since you know what the qualifiers are, you should be able to add those bytes back in "manually" when you do the checksum?

It's all just numbers, as you know a byte can hold a value between 0 and 255. If myVAR holds the value 65 and you do HSEROUT[myVAR] to a terminal (or your serial LCD) you'll get "A" because 65 is the ASCII code for "A". But if you want the numeric value 65 to be displayed PBP needs to send two bytes, namely 54 and 53 which are the ASCII codes for "6" and "5" and this is what the DEC modifier does. There's no way for the STR modifier to know if/when you want it to send "6", "5" instead of 65.

If your had your values in an array you could, instead of a for-next loop simply done something like:

HSEROUT [#myArray[0], #myArray[1], #myArray[2]]

Don't know which are the most effective, time- or codewise but it's an alternative. Ah, you get it.

/Henrik.

[MikeRant]

LOL - yes, I get it. I think from an "ease of use" I'll stick with the FOR/NEXT loop (less typing than all those array vars) .

Thanks again for the help.