Home
Prox / RFID
Verichips
Ladder Logic
[interfacing] †
Tube Joints
Key Code From Photo
SolveSpace (3d CAD)
SketchFlat (2d CAD)
Photographs
Miscellany
Resume / Consulting
Contact Me

LDmicro Forum - issue with UART

(you are viewing a thread; or go back to list of threads)

issue with UART (by David R)
Hi,
I think I have found the problem with the UART,
when the pic is sending UART it is one Char per scan time
but the receiving pic needs to receive and process the data
ie compare for > etc.
this means that the receiving pic needs a faster scan time than
the sender.
this is no good when the pic's need to talk back to each other.

there is one work around that I found, this is to run the same scan time on all pics faster than the time to send one byte,
this seams to force the sending pic not to TX every scan time this way every thing works.

I think the way to fix this would to change the software so the sending pic sends one Char every second scan time.

This might be why Frank in the other post needed to slow to 2400bps and 1ms.

Regards
David
Wed Oct 28 2009, 05:20:04
(no subject) (by Jonathan Westhues)
As far as I'm concerned, the behavior that you describe is correct: the program transmits or receives characters either once per cycle time, or at the maximum speed possible given the baud rate, whichever is slower. As long as the UART is getting polled from within the mainline program, this is the best that you can do.

So as you note, the only way that receive works in all cases is when the cycle time is less than ~10 bit times at the specified baud rate. There is no disadvantage to choosing a baud rate slow enough that this is the case. If the generated program used a faster baud rate, but inserted extra delay between transmitted characters, then the actual number of bytes per second transferred wouldn't be any faster.

It would be better if LDmicro enabled the UART receive interrupt, stored the received characters in a buffer from that interrupt handler, and then processed them later in the cycle. But it doesn't currently do that.
Wed Oct 28 2009, 07:19:13
(no subject) (by David R)
Hi,
Thanks for your help,
The problem is not how fast the data can move, it is matching other equipment board rate and talking ok.

Using the receive buffer in the pic I think would be A great idea may be you could add this sometime ?
Regards
David
Wed Oct 28 2009, 16:13:59
Post a reply to this comment:
Your Name:
Your Email:
Subject:
(no HTML tags; use plain text, and hit Enter for a line break)
Attached file (if you want, 5 MB max):