SERIN "timing constraints" referenced on pg411 of the 'BSSaRM'

davejames

Hi All,

In my continuing quest for reliable serial communication between a BS2 and PC, I discovered a troubleshooting tip in the "BASIC Stamp Syntax and Reference Manual 2.2" on page 411 that reads:

···· 2. Pay attention to timing.
······ a. Be very careful to calculate and overestimate the amount of time operations should take within
··········the BASIC Stamp.· Misunderstanding the timing contraints is the source of most problems with
··········code that communcates serially.
········b. If the serial communcation in your project is bi-directional, the above statement is even more
··········critical.

Unless I've missed it, I cannot find in the manual the discussion of the aforementioned "timing constraints".

Can anyone elaborate/explain/point-me-to-the-info on these constraints?


Thanks much,

DJ


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Mike Green

The Stamps do not have buffered serial I/O. That means that a Stamp cannot receive information when it's doing something other than a SERIN statement. Even then, a SERIN statement takes a certain amount of time (not well defined) to set up for serial input and to process serial input using the formatters (like DEC). During this time, it cannot pay attention to the serial input line and will miss characters or parts of characters.

The only way to avoid running afoul of these limitations is to use some kind of external buffered serial device, whether a UART (like the MAX3100) or another microprocessor that's set up to act as a serial buffer (like those made by ProteanLogic). You can also keep serial communication speeds lower (like 2400 Baud) or switch to a faster Stamp (like the BS2px) that has more leeway for these limitations.

stamptrol

Its related to the Stamps' not having a communication buffer. That means the programs you write must have the SERIN command waiting when data is expected to arrive. If you're not waiting at that instant, you'll miss data coming in.

Luckily, several serial modifiers make this easier. They include WAIT, SKIP, STR which are well explained in the editor help file or the Stamp manual.

Timing gets in the picture when your program has other things to do as well. As the time spent doing other things gets longer, and the time between incoming bytes gets shorter at higher baud rates, a compromise has to be struck so the Stamp has time to do everything asked of it.

In practical terms, the BS2 will work best at 2400 or 4800 baud, especially if its 2 way between two or more devices. From personal experience, receiving at 9600 is pretty iffy.

I've done several comm projects over years, some running continuously for 10 years very reliably. If I can help with this particular project, just let me know.

Cheers,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

davejames

@Mr. Green - thank you. As you say "not well defined" is the kicker here.
@Mr. Sisk - thank you. My app does not require 9600 baud so slowing down may help. And thank you for the offer; I'll send you a PM.

DJ

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔