Is HSEROUT corrupting bit 7 ?????

[Robert Wells]

Hello Ladies and Gentlemen,

I am working on a project to drive an IBM VFD using using the following:

PicBasic Pro Version 2.50B MPASM 5.03
PIC18LF4685 also tried PIC18LF452
LTC485
10 mhz XTAL with HSPLL(X4) option

my defines are:
------------------------------------------------
DEFINE HSER_RCSTA 245
DEFINE HSER_TXSTA 101 'Async mode

DEFINE HSER_BITS 8
DEFINE HSER_ODD 0
DEFINE HSER_EVEN 0

DEFINE HSER_SPBRG 12
DEFINE HSER_SPBRGH 1
DEFINE HSER_SPBRG16 1
DEFINE HSER_CLROERR 1

' Define LCD registers and bits

DEFINE LCD_DREG PORTD
DEFINE LCD_DBIT 4

DEFINE LCD_RSREG PORTD
DEFINE LCD_RSBIT 0

DEFINE LCD_RWBIT 1
DEFINE LCD_RWREG PORTD

DEFINE LCD_EREG PORTD
DEFINE LCD_EBIT 2

DEFINE LCD_BITS 4
DEFINE LCD_LINES 2

'Define ADC settings

define ADC_BITS 10
define ADC_CLOCK 3
define ADC_SAMPLEUS 50
-----------------------------------------------------------
The baud rate is about 190k verified on scope. I am trying to send one byte commands to the LTC485 but what I get is not what I think it should be. I was trying to send HSEROUT [$87] and it came out of the pic hser port xmit pin as seen on my HP54111D oscope as 1110000($7).

So then I tried sending $7 $17 $27 ... $F7 to see what I got out on the scope. The high order nibbles are listed. As you can see bit 7 is whacked in some of the patterns:

0 0000 bad
1 1001 bad
2 0101 bad
3 1100 ok
4 0011 bad
5 1010 ok
6 0110 ok
7 1111 bad
8 0000 bad
9 1001 ok
A 0101 ok
B 1100 bad
C 0011 ok
D 1010 bad
E 0110 bad
F 1111 ok

Next I created another test section in my code to see what was happening and then wrote down the bit patterns (see below):confused::confused:. Forgive me if the formatting is messed up as I could'nt figure out how to do fixed space font. As you can see data bit seven is getting flipped on every byte. I tried another 18LF4865 as well as a 18LF452 to no avail. I am new to serial comm and a pic newbie, so maybe I missing something really obvious here? Is parity trying to flip bit 7? I thought I turned off both odd and even parity in the defines:

DEFINE HSER_ODD 0
DEFINE HSER_EVEN 0

I can post all of my code if it is neccessary. Anybody have any suggestions? Your help would be greatly appreciated.

Thank You,
Bob


's
't_| b___|____b_| s |
'a_| i ___|____i_| t |
'r_| t ___|____t_| o |
't_| 0123 | 4567 | p |

$11 |0| | 1000 | 1001 | 1 |
$22 |0| | 0100 | 0101 | 1 |
$33 |0| | 1100 | 1101 | 1 |
$44 |0| | 0010 | 0011 | 1 |
$55 |0| | 1010 | 1011 | 1 |
$66 |0| | 0110 | 0111 | 1 |
$77 |0| | 1110 | 1111 | 1 |
$88 |0| | 0001 | 0000 | 1 |
$99 |0| | 1001 | 1000 | 1 |
$AA |0| | 0101 | 0100 | 1 |
$BB |0| | 1101 | 1100 | 1 |
$CC |0| | 0011 | 0010 | 1 |
$DD |0| | 1011 | 1010 | 1 |
$EE |0| | 0111 | 0110 | 1 |
$FF |0| | 1111 | 1110 | 1 |

HSERout [$11]
pauseus 80
HSEROUT [$22]
pauseus 80
HSERout [$33]
pauseus 80
HSEROUT [$44]
pauseus 80
HSERout [$55]
pauseus 80
HSEROUT [$66]
pauseus 80
HSERout [$77]
pauseus 80
HSEROUT [$88]
pauseus 80
HSERout [$99]
pauseus 80
HSEROUT [$AA]
pauseus 80
HSERout [$BB]
pauseus 80
HSEROUT [$CC]
pauseus 80
HSEROUT [$DD]
pauseus 80
HSERout [$EE]
pauseus 80
HSEROUT [$FF]
pauseus 80

[skimask]

Turn off the PLL, slow down the baud rate and see what happens.
190k-baud is a bit fast. Might be an electrical problem vs. a software/firmware problem.

[Bruce]

Try removing these defines and see if it works.

DEFINE HSER_ODD 0
DEFINE HSER_EVEN 0

[Robert Wells]

Try removing these defines and see if it works.

DEFINE HSER_ODD 0
DEFINE HSER_EVEN 0

That did the trick! I reran the test and checked out the entire table again and it's perfect! Wow, what a relief! Strange that removing the parity defines = 0 would cause it to work. I'm guessing that would be a very important tip for people to remember in the future.

I looked under the pdf for the 18LF4685 and it says "Parity is not supported by the hardware, but can be implemented in software and stored as the 9th data bit" I wonder if that means if a person did want parity they would set the parity define and calc & stuff the 9th data bit or would PBP do it for them? Well that I will investigate. For this project I don't need parity although I will have to figure out the CRC algorithm of the VFD:eek:

Thank you skimask for the suggestion about speed / electrical problems. I wondered if that might be my problem also as my circuit layout is on the crude side. Thankfully my waveforms at 190kb have nice flat tops and nice, sharp looking rise fall profiles.

Time to glue the hair back to my head, get a little sleep and then get on with the project.

Thanks a million Bruce!
Bob