PDA

View Full Version : HSERIN HSEROUT 9BIT & PARITY (Output is Losing a bit!)



retepsnikrep
- 9th January 2023, 12:03
I've got some 48000 bps 9,E,1 Data coming into a 12F1822 pic running at 32mhz.




#config
__config _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _PWRTE_OFF & _MCLRE_OFF & _BOREN_OFF & _CLKOUTEN_OFF & _FCMEN_OFF
__config _CONFIG2, _PLLEN_OFF & _LVP_OFF
#ENDCONFIG

DEFINE HSER_BAUD 48000 'Set Baud rate to 48000bps
DEFINE HSER_BITS 9 'Set to 9 bit mode
DEFINE HSER_EVEN 1 'Set Even Parity
DEFINE HSER_CLROERR 1 'Clear overflow error automatically

Start: 'Main program start

hserin [wait($83), str IpuData\15] 'Rxd Data
hserout [$83, str IpuData\15] 'Txd Data

goto start



My code basically waits for the start of a 16 byte packet and receives it then spits it back out again.

I have been watching the data in/out with my Saleae Logic and the output seems to be one bit short!!

9299

I have two serial analyzers running with the same settings. 48000 bps, 9,E,1

The top line/channel is the incoming data which decodes correctly.
The second line is the outgoing data but is does not decode correctly and each byte seems to be one bit short!

If I change the settings of the Saleae output analyser to 8 bit with parity then the data is correct.
So the pic is receiving it correctly but the hserout is wrong for some reason.
Where is my missing bit?

The device that receives this data ultimately is refusing it because it is not the correct length..
Why this discrepancy? What am I missing?

Serin2 also exhibits the same behavior?

I had to resort to Microsoft edge to post this as Chrome still gives too many redirects errors. :(

tumbleweed
- 9th January 2023, 16:11
The hardware uart can't do 9E1... that would require 10 bits.

retepsnikrep
- 9th January 2023, 17:44
Maybe I mislead you then, sorry I mean 8,E,1 (1 start bit, 8 data bits, 1 parity bit and one stop bit)

The below sort of works just moving the 9th bit and the 8 Bit data straight across from the RX to TX.

The receiving device is now accepting the input but Saleae logic still shows errors in the data the PIC is outputting???
Something weird is going on..




Start: 'Main program start

do while PIR1.5 = 0 'Wait for RX data
loop

do while PIR1.4 = 0 'Wait for TX to be ready
loop

TXSTA.0 = RCSTA.0
TXREG = RCREG

goto start

HenrikOlsson
- 10th January 2023, 07:06
The receiving device is now accepting the input but Saleae logic still shows errors in the data the PIC is outputting???
Something weird is going on..

If you still have the protocol decoder set to 9E1 then I believe that would be the problem since the output from the PIC is 8E1 (11bits total). Likely the input is 8E1 as well, don't you think?

retepsnikrep
- 10th January 2023, 07:23
Yes but setting the decoder to 8E1 on the input gives parity errors. ???

Attached is some logic 1.2.40 data. The top line is the incoming data.

Perhaps some kind soul could have a look at it and see what they make of it.
Have I got the baud rate/parity etc right for the incoming data decoder?
I've tried loads of variations!!

The shortest pulse is about 20us

Note the output data is now at least the same length as the input and the receiving device seems to accept it, but the output decoder with the same settings as the input gives errors!!!

9300

tumbleweed
- 10th January 2023, 11:38
If you set both channels of the protocol decoders to 8 data bits, odd parity, 1 stop then the errors go away (8O1), but I don't know about the data.

Are you sure about the format? You don't include the parity bit in the count of data bits. Typical formats would be 8N1, 8E1, or 8O1.
Normally, in 9-bit mode there's no parity used (9N1).

HenrikOlsson
- 10th January 2023, 19:26
Yeah, like tumbleweed says, it does seem to be ODD parity, not EVEN.

retepsnikrep
- 12th January 2023, 05:38
I think you are both right. Thanks a lot.
I had tried lots of combos!!! But missed odd parity...

retepsnikrep
- 5th February 2023, 11:24
Attached is another Saelea logic data file in which I am struggling to work out the baud rate and parity etc.
It's from a similar device to my earlier posts in this thread so logically you would think format etc would be similar.

The shortest pulse/bit is about 19.30us so that equates to about 51813bps

But that doesn't work in the analyser unless I am missing something.

Only 55000 8, E,1 seems to decode without errors??
But I'm not convinced that is correct.

If I then program my PIC with that baud rate etc it returns garbage or misses the data entirely.
I've even tried using osctune to shift the PIC baud rate up and down but no joy yet.

I'm tempted to try autobaud but that looks pretty tricky from the PIC16F886 datasheet.

What do members think the data rate/parity is of the attached file?

tumbleweed
- 5th February 2023, 13:32
48000, 8o1 seems to work

retepsnikrep
- 5th February 2023, 13:41
That gives loads of errors for me..
9313

retepsnikrep
- 5th February 2023, 13:48
This seems to work??

9314

tumbleweed
- 5th February 2023, 16:47
Oops, I grabbed the wrong file. Sorry!

What you have there seems to work... 48000 E81 (but the timing is REALLY tight for 48000)

Just an fyi - when you try these don't pick '9-bit + parity' modes, at least not to start. It's usually either '8 data + parity' (if there is a parity) or '9 data w/no parity'.
Most UARTS won't do 9 data bits + a parity bit