PIC18F87J60 UART Receive Errors

[Ttelmah]

Oh my God, you are using a software UART!.. Aaargh. No wonder you have
problems. If you are even fractionally late getting to the read, bits will be
missed. You talked about UART3, as if you had a hardware UART.
You need first of all to use a simulator, and run the whole code between
the calls to the kbhit, and verify that this will always be completed
in less than the character time. The software UART absolutely _requires_
you are sitting waiting for the character before it arrives. No buffering
possible or existing.
No the hardware UART's have two characters of hardware buffering. No
software buffering unless you enable it.
Do you have any interrupts running at all?. If so you need to use the
disable_interrupts option on the software serial of there will be timing
errors.

[temtronic]

sigh.................
for some 'silly' reason I thought that PIC had 5 HW UARTS.....

There is very,very little chance of getting a software UART to do your task !!
OK, it could be done, but you need to be very clever with cutting code..

Honestly the BEST solution, is to replace with a PIC that HAS at least 4 HW UARTS.

seems you need 3 ,now, and I'm betting my PICStart+, you'll need another before this thread is finished !

Jay

[Ttelmah]

I too, thought the chip had more hardware UARTs.
Have to ask what the other connections are used for?. It is possible that
he might be better using the software UART for one of the other channels.
Honestly the chances of getting this to work are very poor. Could the RX line be tricked to generate an interrupt?. If so would improve the chance of
getting this to work, and increasing the speed would also jelp.

[JerryR]

Hi Guys:

Sounds like you two understand the capabilities of the SW UART better than I. Guess I should have specified SW UART was being used.

Well, according to two other Engineers this same code and hardware works well with the previously developed hardware that interfaces to it.

Just how "crippled" is the SW UART? Really hard to imagine I'm going to be able to sell a hardware redesign to the customer to accommodate a new uC. Might need a plan B.

Thanks guys.

[newguy]

[JerryR]

Thanks all for your interest.

Just to add more information:

The "transmitter, under development, does produce an attention signal to the receiver when it has eight bytes of command traffic for the "receiver". The "receiver", using the SW UART, does block global interrupts when it hears this attention signal from the transmitter. So there should be noting happening, as far as interrupts, during SW UART processing. When the eight bytes are received and processed, this attention signal is not asserted and global interrupts are re-enabled.

The current accessory board that communicates with the receiver, seems to work correctly and I'm producing the same signal manipulations and traffic as it according to o-scope, logic analyser and PC COM port.



Thinking of a plan B, now.

[Ttelmah]

OK.
I'd suggest you change in one massive way.
Have a timer programmed to timeout just slightly after the time for all
the bytes.
When you get the signal, start this.
Then receive the bytes just directly into a buffer. Do not try to process them
while receiving. All the loop does is receive all the bytes. If the timer times
out, abort, flag that something is wrong, and stop.
When all eight bytes have been received, then perform the processing.
The key is that you have no time to perform the processing between the
bytes. When one byte finishes the next will start almost immediately. With
the hardware UART, you have the byte time to process. With the software
UART, you do not. The next byte can occur immediately. So you cannot
afford to be doing the processing you show between the bytes. You have to
do this after the transmission completes.

The maths you are doing in the receive CRC part of your code takes too
long. Basically this takes more than the half a bit time you have to get
back waiting for the next byte. Hence your problem.

[temtronic]

do all that Mr. T says !!!
The 'failsafe' timer is a must have addition.

Nothing is worse than having a SW UART stuck forever because the serial cable 'magically' disconnected itself midway while collecting bytes.......BTDT...not a great day that was !!!

If you look at CCS manual ,their examples( FAQ section) show a 'timed serial' , though using the HW UART, it's the same 'failsafe' method.

When you cut code, think like the product is bound for Mars and HAS to work no matter what goofy thing, that no one thought of , happens....

[Ttelmah]

The critical thing to understand here is just how little time you have between
bytes. Assuming the bytes are sent 'back to back', the code must be back
at the "if (kbhit" line in less than half a bit time. Now at your serial rate this
is just under 8uSec. If you get back later than this the read code will be
sampling 'late' in the bits. Result the data shift you are seeing. Now the
simple act of saving a byte to an array and incrementing a pointer will take
several uSec, so adding another 5uSec for the maths, takes you out of the
acceptable time.

[temtronic]

One possible 'trick' (learned from Microchip ) is to lower the baudrate.
If possible, change to 19,200 or 9600. That allows a lot of time between bits to do other things......
Early on Microchip's apnotes showed PS2 mouse code, in assembler ( I did say early ! ) and they did a LOT in between bits.

While probably not an option for you, still, it's worth the read.

[JerryR]

Solved!

Well guys, I should be whipped for not considering the simplest!

I was returning my attention signal from the addon board, before the last byte transmitted a that caused the serial read to bail out early which corrupted the last one or two bytes. Now have transmitted ~1500 commands without a single CRC mismatch.

Well, I learned a lot and, unfortunately wasted your time. But please accept my sincere thanks for riding along with me.

All the best

[temtronic]

It's always good to 'shake up the gray cells', once in awhile !!
sure glad you FOUND the cause AND a solution....

Jay

[Ttelmah]

Key thing is that the software serial does need the whole attention of the CPU.
Sounds as if you were actually interrupting or going to some other code,
either of which would cause a disaster... :(

Glad you have found what was causing it.