Serial Communication byte $0f crash

flo

I'm having strange behavior on my propeller when receiving a data packet that includes the byte $0f (decimal 15)

I apologize I can't post the code right now but this is what happens: I send a series of bytes to the prop and echo it back to my terminal. One of the bytes (doesn't matter which) is incremented by one and sent:

07 00 00 00 00 00 00 00
07 00 01 00 00 00 00 00
07 00 02 00 00 00 00 00
07 00 03 00 00 00 00 00
             ...
07 00 0c 00 00 00 00 00
07 00 0d 00 00 00 00 00
07 00 0e 00 00 00 00 00
** NOTHING **
07 00 f0 00 00 00 00 00

I noticed that ascii equivalent of $0f is <shift in>. Is it possible that the bits are shifting instead of being stored in the byte array? Or when they are being read they are interpreted?


Pseudo code:

counter := 0
recbyte := comm.rxcheck

If recbyte <> -1
    x[noparse][[/noparse]counter] = recbyte
    counter++ 
    
when counter == 8
    iterate through x[noparse][[/noparse]] and comm.str(x[i]) and comm.str(carriage return)
    counter := 0

[/i]

Clock Loop

If your using the parallax serial terminal.exe then $0f or decimal 15 would end up as a position cursor (y)

You can turn the ascii control characters off in the parallax serial terminal by going into preferences and then choose the function tab.

Or your terminal program is interpreting it in this same manner.

flo

I'd argue that it has to be on the prop side because else I wouldn't read all the other bytes in my terminal as 01 02 03 04... 255 as decimals; they would all appear as ascii characters.

The reason I'm echoing it is to debug. Normally, once the byte array is full I pass the pointer to another cog to process. This works great if $0f isn't in the byte array.

Something is happening between receiving and saving into the byte array. I know the other cog works fine because I echo back the string BEFORE I send the pointer to the other cog. Therefore, its crashing somewhere in the receiving and writing to memory area.

Post Edited (flo) : 3/16/2010 7:47:05 PM GMT

Phil Pilgrim (PhiPi)

flo,

Why not post your actual code, instead of pseudocode, so we can take a look at it?

-Phil

flo

Had to run home from work: code attached to this post.

Phil Pilgrim (PhiPi)

Did you know that you have NUM.Init commented out? According to the comments in the Numbers object, it's a necessary call.

-Phil

kwinn

Well flo, you are right that the problem is not on the PST side. The attached modified version of your program prints out everything from 0 to 255. That also eliminates "Extended_FDSerial".

flo

Phil Pilgrim said...
Did you know that you have NUM.Init commented out? According to the comments in the Numbers object, it's a necessary call.

OOps, I'll fix that. But like Kwin mentioned, it's not the Extended_FDSerial as I don't do any NUM converts on receive.

kwinn

flo, I did not have time to do much of a check on the rest of the code (assuming it is even possible since it is dependent on input). I would suggest echoing the input placed in recByte immediately after the first "recByte := Comm.RxCheck" line as a hex number to PST as well as the other data. Might give a hint as to when and where the program is going astray.

It could be overwriting part of the program.