need an expert in pasm for serial comm

dirkdb

I try for serverals months this:
I want to intercept the serial communication stream (mavlink) between an APM 2.6 (autopilot) and MINIOSD. I know that is [8 byte,no parity,1 stopbit,57600 baud and [fe] is the startbyte of a cycle], with a Parallax Serial Terminal pasm code I have the follow: [fe][X][X][80][80]..... in steed of [fe][X][X][01][01]..... ( in hex and with X don't care byte ) ; I know that the normal rs232 comm are in little endian, if I recieve it in big endian if have : [7f][X][X][01][01] it's just a mater to RCR(rotate c right) and RCL(rotate c left) and shift the bytes to the right place: ==> it is very wierd.

When i connect mavlink comm stream direct with a max232 to a serial comm port of a pc and with a serial terminal like TERMITE (and others) I have the right thing: [fe][X][X][01][01]......

The question is: is there a reason for? Is there a difference between a uint8_t an the byte i recieve with propeller?

I need some advice!!!!!

Thanks in advance

Duane Degn

It would help if you posted the code you're using as an archive.

PST doesn't automatically display non-printed characters. You need a method in your program to detect unprinted characters and then display them in hexadecimal. (You might want all the characters display in hex.)

PST displays ASCII characters. These usually start with the space character (32), though some of the other characters will cause changes in the terminal. For example 7 will make a bell sound and 13 will move the cursor to the next line of on the window.

Heater.

dirkdb,

Welcome to the forum.

I think you are going to have to sort out the formatting of your post before anyone can understand it.

All I can say is that normal RS232 serial communication is not big-endian or little-endian in the normal sense of the terms. Such serial links only know about characters ( 7 or 8 bits). They do not care what they mean.

If you are talking about the bit ordering within a byte I have never seen that be the wrong way around. Certainly RCL/RCR would not fix it if they were.

ksltd

You are using endian-ness incorrectly. Big Endian and Little Endian refer to byte ordering, not bit ordering. To reverse bit ordering, use the REV instruction or the >< operator in Spin. But that's not your problem.

You say that you're expecting to receive a byte sequence of: [fe][X][X][80][80]
but are instead receiving a byte sequence of: [fe][X][X][01][01]

I'm not exactly sure of your notation, but I'm guessing that the things inside the square brackets are byte values and that the "X" is the ascii character X or a don't care. It doesn't really matter which. Here's the issue that I see:

You're correctly receiving the FE, which is 11111110 binary. You're incorrectly receiving the 80, which is 10000000 binary. I'm not familiar with the code you're using but I'm confident that if the bits are in the incorrect order, then all bytes would be affected. But clearly they are not. If the FE was flipped around, it would be a 7F. We can eliminate bit reversal as your problem.

To me, this smells more like a baud rate problem with the receiver code you're using. Here's why:

Remember that the 10 bit frame is Start-Data-Stop and so that 80 looks like 111_0_10000000_1_111 on the wire. The leading 0 is the start bit, the trailing 1 is the stop bit; the other 1s are idle time. I'd bet that the timing is off at 57600 and that the bit that makes the 8 is being lost and the bit that makes the 1 is actually part of the stop bit. This is exactly the behavior to be expected when the software uart's performance limits have been exceeded.


Post the code ...

dirkdb

Thanks for the quick replies....

sorry for the compac explanation of my problem and sorry for my bad English....
Maybe the code.spin helps....

dirkdb

ksltd wrote: »

You are using endian-ness incorrectly. Big Endian and Little Endian refer to byte ordering, not bit ordering. To reverse bit ordering, use the REV instruction or the >< operator in Spin. But that's not your problem.

You say that you're expecting to receive a byte sequence of: [fe][X][X][80][80]
but are instead receiving a byte sequence of: [fe][X][X][01][01]

I'm not exactly sure of your notation, but I'm guessing that the things inside the square brackets are byte values and that the "X" is the ascii character X or a don't care. It doesn't really matter which. Here's the issue that I see:

You're correctly receiving the FE, which is 11111110 binary. You're incorrectly receiving the 80, which is 10000000 binary. I'm not familiar with the code you're using but I'm confident that if the bits are in the incorrect order, then all bytes would be affected. But clearly they are not. If the FE was flipped around, it would be a 7F. We can eliminate bit reversal as your problem.

To me, this smells more like a baud rate problem with the receiver code you're using. Here's why:

Remember that the 10 bit frame is Start-Data-Stop and so that 80 looks like 111_0_10000000_1_111 on the wire. The leading 0 is the start bit, the trailing 1 is the stop bit; the other 1s are idle time. I'd bet that the timing is off at 57600 and that the bit that makes the 8 is being lost and the bit that makes the 1 is actually part of the stop bit. This is exactly the behavior to be expected when the software uart's performance limits have been exceeded.


Post the code ...

that is the problem: i have lower/rise the baudrate but no effect.....

kwinn

.........with Parallax Serial Terminal pasm code I have the follow: [fe][X][X][80][80]

When i connect mavlink comm stream direct with a max232 to a serial comm port of a pc and with a serial terminal like TERMITE (and others) I have the right thing: [fe][X][X][01][01]

Hex 80 is binary 1000 0000
Hex 01 is binary 0000 0001

It looks like the bits are reversed from your pasm code. Since the data is 8 bit, no parity, 1 stop bit try using the FullDuplexSerial object and some spin code instead of your code to see if it then displays the correct information.

ksltd

That soft UART has more than a few problems. It has a hard coded 1440 ticks per bit, which corresponds to 55555 baud at 80HMz, a long way from 57600. The right value is 1389. 1440/1389 is an error of about 3% per bit. After 9 bits, you're off by 27% on the long side. The result is you're sampling the stop bit as I'd guessed.

Replace the 1440 with "(80_000_000 + (57600 / 2)) / 57600".

It has a bundle of other problems, too - but that's the most egregious. Try it and see.

ksltd

Kwinn

80 Hex is 1000_0000 binary ... not 0100_0000

But this ain't a bit reversal problem ...

ksltd

Also, at the beginning of your receiver, you have the following sequence of instructions:

receive TEST Rxmask,ina WZ 'wait for start bit on rx pin
IF_NZ JMP #receive

MOV rxbits,#9 'ready to receive byte 9 == 8bit + stopbit ?????
MOV rxcnt,bitticks
SHR rxcnt,#1
ADD rxcnt,cnt

Change the last four to be the following five instead:

mov rxcnt,cnt
mov rxbits,bitticks
shr rxcnt,#1 ' 1 should work, but this may need to be a 2 depending on the device transmitting
add rxcnt,rxbits
mov rxbits,#9

kwinn

ksltd wrote: »

Kwinn

80 Hex is 1000_0000 binary ... not 0100_0000

But this ain't a bit reversal problem ...

Yes, I noticed the typo a couple of minutes after I posted it, and I agree that it's probably a timing problem.

dirkdb

ksltd wrote: »

Also, at the beginning of your receiver, you have the following sequence of instructions:

receive TEST Rxmask,ina WZ 'wait for start bit on rx pin
IF_NZ JMP #receive

MOV rxbits,#9 'ready to receive byte 9 == 8bit + stopbit ?????
MOV rxcnt,bitticks
SHR rxcnt,#1
ADD rxcnt,cnt

Change the last four to be the following five instead:

mov rxcnt,cnt
mov rxbits,bitticks
shr rxcnt,#1 ' 1 should work, but this may need to be a 2 depending on the device transmitting
add rxcnt,rxbits
mov rxbits,#9

Thanks a lot, i'll try this to morrow and let you now the results!!!!!!!!!!
Maybe this ends my really nightmare!!!!!!

dirkdb

ksltd wrote: »

Also, at the beginning of your receiver, you have the following sequence of instructions:

receive TEST Rxmask,ina WZ 'wait for start bit on rx pin
IF_NZ JMP #receive

MOV rxbits,#9 'ready to receive byte 9 == 8bit + stopbit ?????
MOV rxcnt,bitticks
SHR rxcnt,#2 <=========2 instead of 1
ADD rxcnt,cnt

I can't wait for the result:

i have make the change " shr rxcnt,#2 " and i've reduced the " bitticks " for transmitting as you sayed

==> IT'S WORKING!!!!!!!!!!!!!!!!!SOLVED!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!THANKS A LOT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!