BS2 9600 Baud
michaelb
Posts: 4
I am trying to interface a BS2 with an HA7S device which can read and write to 1-wire devices. The interface of the HA7S is fixed at 9600N81 serial for TX and RX icommunication, one port for TX and one port for RX. I can successfully write from the BS2 through the HA7S, but when reading, the expected 8 Bytes do not correspond to the string sent by the 1-wire device.
1) I have used a scope to verify that data is being sent to the BS2.
2) using single byte or STR reads via SERIN , I receive 8 bytes (or one byte) of data but the HEX information does not compare with the data read by independent means. In single byte or string the first byte is the same.
3) I have experimented with normal and inverted data formats.
The read code snippet is like this:
Data_In VAR Byte(9)
following a SEROUT ...
SERIN 1,$4054,[noparse][[/noparse]STR Data_In\8]
Read data:
AE 65 F6 F6 F6 EC F6 D6
Should be:
F5 00 08 00 92 5A 20 10
Is this a speed problem or am I missing something?
1) I have used a scope to verify that data is being sent to the BS2.
2) using single byte or STR reads via SERIN , I receive 8 bytes (or one byte) of data but the HEX information does not compare with the data read by independent means. In single byte or string the first byte is the same.
3) I have experimented with normal and inverted data formats.
The read code snippet is like this:
Data_In VAR Byte(9)
following a SEROUT ...
SERIN 1,$4054,[noparse][[/noparse]STR Data_In\8]
Read data:
AE 65 F6 F6 F6 EC F6 D6
Should be:
F5 00 08 00 92 5A 20 10
Is this a speed problem or am I missing something?
Comments
You don't show us how you're doing the data dump to show the illustrated data. That may or may not be a problem.
Is IS possible that the STR formatter is slowing things down, but I would expect lost bytes rather than all garbage data. To answer your question, more often than not garbage data is frequently caused by an incorrect BAUDMODE (baud rate especially).
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There is no pleasure in having nothing to do;
the fun is in having lots to do, and not doing it!
9600 Baud is at the upper limit of what the BS2 can reliably receive. There's a bit of setup time for the SERIN and for each of the "formatter"s like STR and sometimes the data comes in too quickly and the Stamp misses the first bit which throws the rest off.
Check the Baud constant. I don't remember what the proper values are in hexadecimal. That's probably not the problem, but check it anyway.
I used an HA7S a few years ago and I remember having the same sort of problem. I eventually just switched to using a BS2sx or BS2p for the extra speed.
SEROUT
PAUSE 5
SERIN 1,84,[noparse][[/noparse]STR Data_In\8]
Jeff T.
Jeff T.
I tried it both ways, inverted seemed like less nonsense, but you may be right because I must talk to it in normal mode and it would make sense that it would send data the same way. Since it is garbled either way, I still need a better solution.
Jeff T.
I too have struggled with past projects interfacing to external devices at 9600baud and higher where I have no control over the external device's reply speed.
It looks like you are suffering bit slide where because the stamp is not correctly catching the first byte coming in from the HA7S, it is reading in start and stop bits and interpreting them as part of the data values - hence your garbage.
In my applications I have been able to accept losing the first byte or two and was able to get the following data that I needed with a 'skip', formatter. Hopefully in your application the first byte from the HA7S is always the same and thus skippable (is that a proper word?).
SERIN 1,$4054,[noparse][[/noparse]skip 1, STR Data_In\7]
or
SERIN 1,$4054,[noparse][[/noparse]skip 2, STR Data_In\6]
Good luck
Carl
Just to echo the consensus, 9600 is almost always too fast for the BS2 (unless going Stamp to Stamp with flow control).
The Bs2sx and px will give you the capability you need, plus more working space in the form of a scratch pad RAM.
Cheers,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk
http://www.siskconsult.com
·
serin 6,$54,1000,nodata,[noparse][[/noparse]str zoom\6] ' 600 microseconds for BS2
That is the delay from the completion of the preceding command to the point where the SERIN will receive the first and subsequent bytes correctly. The corresponding delay on the BS2sx or BS2p is closer to 240 microseconds. It would be somewhat shorter without the timeout, but in either case, it is quite possible for a device on the other end to commence data transmission with only a few microseconds of turnaround time. Many devices assume that they will be talking to a host that has a serial buffer that is immediately ready to receive more data. It is a problem with many many external devices. Most often, those devices do not have any provision for flow control (SERIN 1\2,...), Even a speedier Stamp does not help.
There are external serial buffers you can use, that will receive and store characters so that the Stamp can read them in at a leisurely pace. For example, the MAX3100 family, or ProteanLogic, or the DIY serila buffer in Al Williams' SX programming book (now free download)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com