HSERIN HSEROUT 9BIT & PARITY (Output is Losing a bit!)

I've got some 48000 bps 9,E,1 Data coming into a 12F1822 pic running at 32mhz.

Code:

---


#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!!

Attachment 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. :(

The hardware uart can't do 9E1... that would require 10 bits.

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..

Code:

---

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

---

Quote:

---

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?

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!!!

Attachment 9300

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).

Yeah, like tumbleweed says, it does seem to be ODD parity, not EVEN.

I think you are both right. Thanks a lot.
I had tried lots of combos!!! But missed odd parity...

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?

48000, 8o1 seems to work

That gives loads of errors for me..
Attachment 9313

This seems to work??

Attachment 9314

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