Serial communication questions...

Smitty · 2005-02-11 18:36

I have noticed something odd about serial communications across SIN...

Check out the following lines of code and see if you can explain this for me...

word1 VAR Word
word2 VAR Word
byte1 VAR Byte
byte2 VAR Byte
byte3 VAR Byte
byte4 VAR Byte

'this line reads 4 bytes into 2 words with each byte provided separately as input variable
SERIN 16, 240, 10, NO_INPUT, [noparse][[/noparse]WAIT("*"), word1.HIGHBYTE, word1.LOWBYTE, word2.HIGHBYTE, word2.LOWBYTE] 

'this line reads 4 bytes into 4variables defined as bytes
SERIN 16, 240, 10, NO_INPUT, [noparse][[/noparse]WAIT("*"), byte1, byte2, byte3, byte4]

I have tried doing this both ways and experimented with it quite a bit... I have it write back to the terminal what it stored in the variables...

Why is it that the FIRST method (reading into 2 words) receives the input more reliably that reading into 4 bytes?

I'm using a macro in the debug terminal... using 4 Byte-type variables only reads the input about half of the time... using 2 Word-type variables reads it almost every time.

Theoretically, there should be little or no difference between the two...

Jon Williams · 2005-02-11 19:21

What do you mean, "more reliable"? Both methods are accepting four bytes, there's no difference there. The only thing that differs is where the data ultimately lands.

On thing to keep in mind is that 10 milliseconds is a very short timeout for something that is coming from a terminal (and I'm assuming using huma input).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

allanlane5 · 2005-02-11 19:23

"Using a macro in the debug terminal" -- what does that mean?

Are you using the BS2 IDE to both send and get back the data?

And it looks like you have a 10 mSec timeout, which then goes to a 'NO_INPUT' label. Are you timing out at all?

10 mSec is not very much to recieve 4 bytes at 9600 baud (that '240' in there).

Clearly, it's a timing issue. It is possible that the run-time environment can store things faster with a single variable, even if accessed twice with HIGHBYTE/LOWBYTE than it can put them in 4 separate bytes.

What happens if you do:
MyStr VAR BYTE(4)

SERIN 16, 240, 10, NO_INPUT, [noparse][[/noparse] WAIT("*"), STR MyStr\4 ]

I don't know if the STR modifier will make this go faster (what I would hope) or slower.

Smitty · 2005-02-11 21:21

"Using a macro in the debug terminal" -- what does that mean?

Humans aren't able to type 5 bytes in a matter of milliseconds.· In the debug terminal, you can set macros... for example, I have Ctrl-Shift-A set to send "*TEST" to the basic stamp.

What do you mean, "more reliable"? Both methods are accepting four bytes, there's no difference there.

That's why I thought it·was odd.· Theoretically, there should be no difference.·

But, like I said, reading into two word variables receives and echoes the string "TEST" (one ASCII byte at a time) almost every time with no problems.· Reading into four one-byte variables misses some of the data about half of the time.

10 mSec is not very much to recieve 4 bytes at 9600 baud (that '240' in there).

Well, in theory 4 bytes should take 3.33 ms... does the 10 ms mean that it must receive all of the input with 10ms, or just that it will wait for·10 ms to receive the first byte?· I took it to mean the later, but I·didn't really think about that.

It is possible that the run-time environment can store things faster with a single variable, even if accessed twice with HIGHBYTE/LOWBYTE than it can put them in 4 separate bytes.

I think you may be correct... your suggestion about using an array of bytes worked better than either of the two I used as examples.· The only sufficient explanation is that the 4 byte array is in contiguous memory whereas 4 bytes and 2 words are not.· Apparantly that makes the difference.

Thanks guys.

allanlane5 · 2005-02-11 22:30

From my practice, I found that the time-out was how long the SERIN statement would stay up. If the time-out hits in the middle of a byte, too bad, you don't get that byte. Thus if your message starts coming in at the end of the time-out, it is very likely that the start of your message may be recieved, but the last few bytes not. I believe the last byte not recieved would be a zero.

And if you were sending the same message again and again (without clearing the 'destination' variables in between) it's possible that 'old' data remained in the destination. Whether you would see this as a problem depends on what you were looking for.

I think the 'STR' modifier worked best because the run-time only had to translate a single variable, instead of 2 or 4 as your other examples did. (Also I believe Jon mentioned this was the fastest way to recieve data).

Jim McCorison · 2005-02-11 22:41

Smitty said...
The only sufficient explanation is that the 4 byte array is in contiguous memory whereas 4 bytes and 2 words are not. Apparantly that makes the difference.

Actually, the memory in a stamp is layed out contigously and variables appear in memory in the same order the are in a program. Thus:

byte1    VAR    byte
byte2    VAR    byte
byte3    VAR    byte
byte4    VAR    byte

byte1(3) and byte4 point to the same location in memory.

Jim

achilles03 · 2005-02-12 02:36

One problem regarding your other post is that you're using the SX chip, therefore your units of timeout are .4ms. Therefore, a timeout of "10" is actually only 4ms! And it needs 3.33ms just to get 4 bytes? That's 667 microseconds of slack. I would like to ask you this: what's the hurry? What do you stand to gain (at the cost of reliability) by limiting the time the SERIN command is open?

Dave

Smitty · 2005-02-12 06:32

Actually, the memory in a stamp is layed out contigously and variables appear in memory in the same order the are in a program. Thus:

byte1 VAR byte
byte2 VAR byte
byte3 VAR byte
byte4 VAR byte

byte1(3) and byte4 point to the same location in memory.

That's true. But the 4 bytes are not necessarily in contiguous memory... only if they are declared successively. Does the processor have to readdress the whole thing each time?

I dunno... it's strange. The array clearly works better.

Post Edited (Smitty) : 2/12/2005 6:46:22 AM GMT

Gadgetman · 2005-02-12 10:09

Jim McCorison said...

Actually, the memory in a stamp is layed out contigously and variables appear in memory in the same order the are in a program. Thus:
byte1    VAR    byte
byte2    VAR    byte
byte3    VAR    byte
byte4    VAR    byte
byte1(3) and byte4 point to the same location in memory.

Jim

No, variables are not always in the same order as they appear in your listing.
The translator places the largest variables(words) first, then successively smaller ones.
This is to optimise the use of the limited space.

That it can cause problems for the unwary when working on multi-bank programs on the BS2p and BS2pe is another matter...

Jim McCorison · 2005-02-12 19:07

Gadgetman said...
No, variables are not always in the same order as they appear in your listing.

Actually, I guess both our statements are true. Variables are placed by size, and within size, by order of definition. To quote N&V article #115:

Jon Williams said...

Remember, the BASIC Stamp memory can be treated as an array even if we don't explicitly
declare it as such – this can be very powerful when used carefully. And this is the reason that
our variables must appear in the order that they do: the BASIC Stamp compiler assigns RAM
space by variable size and in the order of declaration.

Jim

Serial communication questions...

Comments