Prop not processing serial data correctly

Gunstar1 · 2010-01-19 07:28

I am trying to move some things from·a BS2 to the prop and have run into a problem regarding receiving serial.

On the BS2 I have a simple bit of code that grabs the text that is sent and displays it in debug.· Pretty much borrowed from the manual itself.

Baud CON T9600 
serStr VAR Byte(13) 

Main: 
serStr(12) = 0 
SERIN 1, BAUD, [noparse][[/noparse]STR serStr\12] 
DEBUG STR serStr

On the debug screen for the BS2 I get the text string I am expecting... "ELM322 v2.0"

Now I go into the prop·to·try to get get a similar string and I am having zero luck.· First since it is not inverted, it seems the only serial·object I can use is simple serial (the chip·uses·9600Baud· 8 N 1).· So I get that up and running with a simple code that init's the serial and calls rx.· I the tell debug to dec whatever is in Rx.

   Debug.start(31, 30, 0, 57600)
   ELM322.init(ELM_RX_PIN, ELM_TX_PIN, 9600)
 
   waitcnt(clkfreq + cnt)  
   repeat
     Rx := ELM322.Rx
     Debug.dec(Rx)
   ' Debug.str(string(13))

I am expecting to see the numbers that correspond to the·ASCII string that the chip sends, but instead I get "691733820114615313033262"

The 69 is E,·and the 62 appears to be the > character that·signals the end of the serial transmission (sent from the chip), but what in the world is all that stuff in the middle?· What is it I am doing wrong?
I can't continue programing until I know I can get the text that the chip sends when it first starts up... which should be:

ELM322 v2.0
 
>

·If I uncomment out that carriage return I get this in the debug screen.
69
213
38
50
178
147
152
41
72
223

I would have thought the 2 would have been identical except one would be easier to read, but·other than the first·number 69, which is the E, the rest does not match.

I am totally lost now so I would welcome any ideas.

Thanks.

Peter Jakacki · 2010-01-19 07:52

By way of a quick reply you would need to define a string either in the DAT section and then reference that label as an address in this form.

dat
elmstr   byte  "ELM322 v2.0",13,10,0

pub main
  ' ......... your code
  debug.str(@elmstr)

or

pub main
  ' ......... your code
  debug.str(string("ELM322 v2.0",13,10))

debug.str expects an address of a zero-terminated string in memory somewhere just as it does in the BS2.

P.S. scrub that reply....I see you are expecting the characters back from the "ELM" but bear in mind that the simple serial code can miss bits. Use the FullDuplexSerial and set the mode bits accordingly. I don't understand why you say you can only use SimpleSerial though. Another tip, replace debug.dec with debug.hex and pad it with a space for readbility.

Also, since SimpleSerial is used for both receiving from the ELM and transmitting to debug it will miss any receive data from the ELM while it is busy sending data to debug as you are using the same (main) cog. The cogs are used as programmable peripherals so one cog can be dedicated as a UART, or even 4 UARTS (check the OBEX).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

Post Edited (Peter Jakacki) : 1/19/2010 8:25:59 AM GMT

Gunstar1 · 2010-01-20 17:12

I am using full duplex as the debug and simple serial to talk to the elm.

As for why I don't think full duplex will work for the elm... I don't know what to set it to for non inverted receive.

'' mode bit 0 = invert rx 
'' mode bit 1 = invert tx 
'' mode bit 2 = open-drain/source tx 
'' mode bit 3 = ignore tx echo on rx

None of those mode options seem to apply.· I tried 3 but it did not show anything on the debug screen so I figured it was not what I wanted.

mojorizing · 2010-01-20 18:15

I believe what's going on here is that with the SPIN code, you're rec'ving a byte from the ELM then sending that byte out to your PC via debug. Then you're going back and recv' ing what you think is the next byte, but actually since there was a delay because of the sending of debug, simple serial is actually getting corrupted and delayed data. Unlike the BS2 code which completely loads all the string then debugs it to your PC.

I have found for debug to be completely transparent and have no effect on your intended code, it's got to be run in a separate cog.

Rereading the post, Peter pretty much mentions what I just wrote....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!

Post Edited (mojorizing) : 1/20/2010 6:22:01 PM GMT

Ariba · 2010-01-22 04:35

Gunstar

'' mode bit 0 = invert rx
'' mode bit 1 = invert tx
'' mode bit 2 = open-drain/source tx
'' mode bit 3 = ignore tx echo on rx

This means: if you set bit 0 then rx signal is inverted, if you clear bit 0 then rx is not inverted. Same for the other bits.
So for normal Full Duplex, non inverted, the mode is 0 (none bit set).

If you set the Terminal to 9600 Baud, you can use the same FullDuplexSerial for receiving the ELM and to output the bytes to the Terminal.

Andy

Gunstar1 · 2010-01-31 02:50

mojorizing said...
I believe what's going on here is that with the SPIN code, you're rec'ving a byte from the ELM then sending that byte out to your PC via debug. Then you're going back and recv' ing what you think is the next byte, but actually since there was a delay because of the sending of debug, simple serial is actually getting corrupted and delayed data. Unlike the BS2 code which completely loads all the string then debugs it to your PC.

I have found for debug to be completely transparent and have no effect on your intended code, it's got to be run in a separate cog.

Rereading the post, Peter pretty much mentions what I just wrote....

I understand that, and now I am loading the RX to a byte array and holding it until a count is reached and then running another repeat to·send that array to the debug.· I am now getting "ELM" and then a bunch of other stuff that should not be·there.·It is progress at least.

Gunstar1 · 2010-01-31 03:16

Ok, so I backed up and tried using full duplex instead of simple serial and just send that info to debug.

A little bit more progress. Now instead of seeing the message I am supposed to get, I am seeing the full message that it sends if it did not understand the command·it was·sent... only I didn't send any command at all.

This is a pain to get a·serial device working.

Gunstar1 · 2010-01-31 04:18

Duh, I figured it out now.·

You people assumed I was more intellegent than·I really am.·

I was not paying attention to·full duplex mode·saying "bit".

Just in case someone else has the same problem I did...

'' mode bit 0 = invert rx 
'' mode bit 1 = invert tx 
'' mode bit 2 = open-drain/source tx 
'' mode bit 3 = ignore tx echo on rx

the "mode" wants a number that corresponds to the binary equivilent.·
if you want to "invert rx" and "ignore tx echo on rx" you want a binary number of 1001
1001 = 9
so you put 9 in the start call for mode

if you want to just invert tx then you want a binary number of 0010
0010 = 2

kuroneko · 2010-01-31 05:15

Gunstar1 said...
if you want to "invert rx" and "ignore tx echo on rx" you want a binary number of 1001

1001 = 9

so you put 9 in the start call for mode

if you want to just invert tx then you want a binary number of 0010

0010 = 2

So why don't you take the next step as well and actually specify the binary number as a parameter? That's OK for SPIN and PASM. I mean if it is a bit pattern then there is no point converting it into something unrecognisable [noparse]:)[/noparse]

Debug.start(31, 30, %1001, 57600)

Gunstar1 · 2010-01-31 05:28

kuroneko said...

Gunstar1 said...
if you want to "invert rx" and "ignore tx echo on rx" you want a binary number of 1001

1001 = 9

so you put 9 in the start call for mode

if you want to just invert tx then you want a binary number of 0010

0010 = 2

So why don't you take the next step as well and actually specify the binary number as a parameter? That's OK for SPIN and PASM. I mean if it is a bit pattern then there is no point converting it into something unrecognisable [noparse]:)[/noparse]
Debug.start(31, 30, %1001, 57600)

I didn't even think about it.· That would be much easier to use.

Prop not processing serial data correctly

Comments