Shop OBEX P1 Docs P2 Docs Learn Events
BS2 9600 Baud — Parallax Forums

BS2 9600 Baud

michaelbmichaelb Posts: 4
edited 2008-02-02 00:19 in BASIC Stamp
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?

Comments

  • Bruce BatesBruce Bates Posts: 3,045
    edited 2008-02-01 00:41
    Michael -

    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!
  • michaelbmichaelb Posts: 4
    edited 2008-02-01 00:50
    Data is read a byte at a time from the array after capture. In the case of a single byte capture I also read the byte after capture. In other words, I don't try do anything until the serial capture is complete and I can read data from memory. Since the baud rate works correctly for TX, it should work for RX, I presume.
  • Mike GreenMike Green Posts: 23,101
    edited 2008-02-01 01:26
    michaelb,
    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.
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2008-02-01 02:14
    Hi michaelb, I believe the baud should be 84. I'v had problems where the serin immediatly follows a serout, sometimes a small pause will work.

    SEROUT

    PAUSE 5

    SERIN 1,84,[noparse][[/noparse]STR Data_In\8]

    Jeff T.
  • michaelbmichaelb Posts: 4
    edited 2008-02-01 02:33
    Thanks for the advice. $4054 is correct for inverting 9600 n81. I agree that it appears that we are losing some bits on the front end. Unfortunately I cannot affect the turnaround timing of the HA7S and am trying to get the BS2 ready to receive as fast as possible. Sounds like a faster processor is needed.
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2008-02-01 02:37
    Hi michael, agreed if your device is responding too quickly the Stamp will miss it. Yes 16468 is inverted, sorry I thought the HA7S was transmitting a true TTL signal.

    Jeff T.
  • michaelbmichaelb Posts: 4
    edited 2008-02-01 03:38
    Unsoundcode:
    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.
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2008-02-01 03:45
    Hi michael, possibly your only solution is a faster processor. I know the BS2 can be reliable at 9600 for short STR strings such as yours, but like I say in the past the only way I could get things working was a short pause after a serout. This really does not slow things down (if it works that is), but some devices just respond too fast. The BS2px should do it.

    Jeff T.
  • CMcGCMcG Posts: 17
    edited 2008-02-01 11:09
    Hi Michael,

    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
  • stamptrolstamptrol Posts: 1,731
    edited 2008-02-01 12:51
    Michael,

    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
    ·
  • Tracy AllenTracy Allen Posts: 6,666
    edited 2008-02-01 18:50
    According to test I made several years ago, it takes the BS2 close to 600 microseconds to set up to receive the first byte of a serin command with a timeout, e.g.,
    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
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2008-02-02 00:19
    See also allanlane5's suggestion (UART buffer) here -- http://forums.parallax.com/showthread.php?p=705748
Sign In or Register to comment.