Interspecies Communication, or,,, talking between a BS2sx and an ATMEGA

xanatos · 2012-10-23 11:09

Hi all,

Using SERIN and SEROUT to talk to a "black box" kind of thing.

The "Black Box" (herein known as the BB), has a serial connection on it, which is NORMALLY used with a special cable containing a MAX232 chip, which NORMALLY goes to a PC Serial port, and is talked-to with Hyperterminal (9600, 8, N, 1)

Said BB is working using the normal setup as described above.

The actual raw serial terminal on the side of the box is straight TTL level serial data - the MAX-232 (unless I mis-understand the MAX-232) isn't adding any data to the string.

So I am theorizing that I should be able to use my BS2sx with regular old SERIN and SEROUT to talk to this thing.

The normal operation of the box when hooked to Hyperterminal is (after configuration the COM port with 9600, 8 N 1), is to issue a CR to the box, and the box then returns a > to the hyperterminal window.

The operator then would issue a two character command string to the box, and off it goes.

I am attaching my code below. When I SEROUT my CR, and WAIT for my ">", I get nothing. Ever.

Can anyone tell me what I'm missing?

Thanks!

Dave

' =========================================================================
' Initial communications setup/test for sercomm with cbox.
'
'   {$STAMP BS2sx}
'   {$PBASIC 2.5}
'
' =========================================================================
' -----[ Constants ]-------------------------------------------------------

#SELECT $STAMP
  #CASE BS2, BS2E, BS2PE
    T2400       CON     396
    T9600       CON     84
    T19K2       CON     32
  #CASE BS2SX, BS2P
    T2400       CON     1021
    T9600       CON     240
    T19K2       CON     110
  #CASE BS2PX
    T1200       CON     3313
    T2400       CON     1646
    T4800       CON     813
    T9600       CON     396
    T19K2       CON     188
    T38K4       CON     84
#ENDSELECT

' -----[ I/O Definitions ]-------------------------------------------------

  Crx           PIN     7               ' Receive Pin on Centeron Receiver
  Ctx           PIN     6               ' Transmit Pin on Centeron Receiver

' -----[ Variables ]-------------------------------------------------------

  serStr          VAR     Byte(10)


' -----[ Initialization ]--------------------------------------------------

'Pins:
'1: GND  <----  closest to reset button
'2: +5V
'3: GND
'4: TX
'5: RX   <----  closest to phone jacks

' -----[ Program Code ]----------------------------------------------------

  Main:

    DO
      DEBUG "Sending...",CR
      SEROUT Crx, T9600, [CR] '
      SERIN Ctx, T9600, 2000, nuttin, [WAIT(">")]
      DEBUG "Prompt received", CR
    LOOP
    STOP

' -----[ Subroutines ]-----------------------------------------------------

nuttin:
  DEBUG "nuttin...",CR
  RETURN

Sapphire · 2012-10-23 13:38

Xantos,

Do you have a ground connection between the BS2 and the BB, in addition to the Tx/Rx wires?

Using the MAX232 cable, can you monitor on HyperTerminal what the BS2 is sending? A "CR" is hard to see, maybe try sending a printable character "X" until that's verified.

Using the Max232 cable, can you monitor on HyperTerminal the response from the BB while the BS2 is connected? That might rule out a response other than >.

Or you could for testing change your SERIN to capture one byte and display it, to see if it's a > or something else.

Try using Inverted baud mode, in case your MAX232 isn't inverting (although it should be).

Franklin · 2012-10-23 13:38

How do you have your connections? TX to RX and RX to TX (don't forget your ground)

xanatos · 2012-10-23 14:45

Hi,

Yes, TX to RX and RX to TX verified, as well as common ground. I'll try looking at the output of the BS2 with the Max232 cable, and tapping between them as well...

I'm still thinking there's going to be a $1A or something like that showing up somewhere :-)

Thanks, I'll let you know...

Best,

Dave

xanatos · 2012-10-23 16:59

OK, I've got communication, but there are definitely preamble bytes stuffed in there. I know I have communication because I saw the hex values going by. I captured some of them in a fat string and saw bits of readable data, but widely separated by garbage characters... a small snippet here shows that the place where the text should have said "Set Temperature", instead says "

Sapphire · 2012-10-23 18:16

Xanatos,

Try putting a pull-up or pull-down resistor on the output of the BB. It might have a tri-state or open source/open drain driver, which is floating between characters. The time that it is floating may be interpreted by the BS2 as data, hence the garbage characters.

xanatos · 2012-10-23 18:26

I will try that, Sapphire, thanks. I'm also wondering if it's possible that the BS2sx isn't fast enough at 9600 to pick up so much data... Maybe I'm getting Data Slip. I'm going to try the BS2px. Tomorrow... :-)

Dave

Sapphire · 2012-10-23 18:47

Xanatos,

I don't think so. If you are not using complex formatters, and just reading into an array of bytes, the BS2sx is fast enough at 9600. Are you doing it all in one read or multiple SERIN commands? The latter would cause some bits/bytes to be missed between commands if the data stream out of the BB is continuous.

xanatos · 2012-10-23 19:13

Nope, just one big fat dump. In fact, I could use more bytes than I can specify for the sx. The px allows me to use the SPSTR command and drop it all into SPRAM (up to 126 bytes as I understand). I need to catch several strings that look exactly like this: 10 1A 47 00 0D F9 19 11 3E 43 R0125190911022 22 6F F4 48 (each!) and then do things with that data. Assuming, of course, that I can figure out how to get the data reliably...

Dave

xanatos · 2012-10-24 06:35

Hi Sapphire et al,

I tried the pull-up/pull-down resistor test, no change. Again, the garbled-looking data is identical for a given command sent to the BB, so I don't think it's noise, I think that this is data actually being sent from the box, but which is not read by Hyperterminal.

So I tried my BS2px, and while I got the EXACT same garbled data, I was able to read a LOT more data by virtue of the SPSTR formatter - and by putting the data into SPRAM then reading it out with GETs, I was able to pull up ALL the data. I found I have to SKIP the first 16 bytes, which contain the menu label, then SPSTR 126 bytes. WHen I display those 126 bytes, the full text of the menu is there with minimal garbage. Below is the code and an example of the output as debugged to my debug window:

  Main:
      x=16
      SEROUT Crx, T9600, [HEX x, CR, LF]
      SERIN Ctx, T9600, 2000, nuttin, [WAIT(">")]      ' > = DEC 62 or HEX 3E
      DEBUG ">", CR
      PAUSE 200

      serStr(39) = $F
      SEROUT Crx, T9600, [$20, "?", CR, LF]
      SERIN Ctx, T9600, 500, nuttin, [SKIP 16, SPSTR 126]

  Continue:
      FOR x = 0 TO 126
        GET x, serStr
        DEBUG STR serStr
      NEXT

' -----[ Subroutines ]-----------------------------------------------------

nuttin:
  DEBUG "nuttin...",CR
  GOTO continue

And output:

z‚‚z‚‚z‚‚z‚‚

‚5
M1= *000000 0000/00/00/00/00 0000 0
00C

M2= *000000 0000/00/00/00/00 0000 000C

M3= *000000 0000/00/00

Which should look like the hyperterminal display:

M0= *000000 0000/00/00/00/00 0000 000C
M1= *000000 0000/00/00/00/00 0000 000C
M2= *000000 0000/00/00/00/00 0000 000C
M3= *000000 0000/00/00/00/00 0000 000C

This is the worst of the examples at this point - some of the control characters coming across are interpreted by the debug window as HOME or CLS which are making it difficult to capture everything here.

I'm getting closer, but still a daunting task. If anyone recognizes what's happening and has a way around it, it would be greatly appreciated!

Dave

stamptrol · 2012-10-24 06:56

Rather than use DEBUG and its screen in the IDE, try replacing DEBUG with a SEROUT and using a generic terminal program like Hyperterminal, etc.

I had a similar issue in trying to print specific data in the DEBUG screen.

Cheers,

xanatos · 2012-10-24 07:04

Thanks Tom. The DEBUG is definitely inducing its own set of issues into the mix. I'm thinking about ways in which I can check to see if the stored byte is in the range of normal characters, or in the control or extended end of the ASCII before I send it on to the debug screen... sort of checking to see if the character is between 32 and 126 (and allowing 10 and 13 for LF and CR)... I am determined to figure this thing out! :-)

Dave

EDIT: I just set it to only debug characters between 12 and 127 and that cleaned stuff up a lot! Still - it's odd that there are 16 bytes of STUFF that come in before the data, and that somewhere, "encoded" in that preamble, is the header text, but it is no where to be seen inside of it...

xanatos · 2012-10-24 14:20

Finally got it working. Had to WAIT for a given character in the data stream that is always constant, then SKIP several bytes, then only capture 12 bytes to my array. It's working perfectly now, and for anyone else who wants to read data from a serial device that normally outputs to Hyperterminal, be aware that there ARE numerous other bytes of data in the form of NULL characters, Start-of-Text and Start-of-Heading (STX and SOH) TABs, LF, CR combinations... lots of fun. Fortunately, the Stamps have a robust enough SERIN command that you can pick out just what you want and ignore all the rest.

Thanks for the assistance folks! I appreciate your ideas.

Dave

davejames · 2012-10-24 23:13

Dave - thanks for relating the resolve. I was watching this thread with interest.

Interspecies Communication, or,,, talking between a BS2sx and an ATMEGA

Comments