 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
| Minimum inter-character delay |
 Posted: Wed Apr 07, 2004 12:55 am |
 |
|
Hi all
On PIC16F870, hardware UART at 9600bps and XTAL=3686400, what is the minimum acceptable inter-character delay for the PIC's receiver? What I mean is let's assume I have a very fast transmitter. How fast can I pump data out the data to the PIC? What is the minimum amount of time I need to wait between bytes, to give the PIC UART enough time to turn around and wait for the next byte? Thanks. |
|
 |
Ttelmah
Guest
|
| Re: Minimm inter-character delay |
| Posted: Wed Apr 07, 2004 2:10 am |
|
|
| Haplo wrote: | Hi all
On PIC16F870, hardware UART at 9600bps and XTAL=3686400, what is the minimum acceptable inter-character delay for the PIC's receiver? What I mean is let's assume I have a very fast transmitter. How fast can I pump data out the data to the PIC? What is the minimum amount of time I need to wait between bytes, to give the PIC UART enough time to turn around and wait for the next byte? Thanks. |
Zero.
The UART has one character of buffering. Once a character is received, it is transfered from the input latch to the holding register, and the input latch is capable of receiving another character straight away. The 'caveat', is that you must remove the character from the holding register, and clear the interrupt flag, before the second character is completed. At 9600bps, normal code using an interrupt driven receiver, and buffer is fine. But at very high baud rates, rather more care is needed.
Best Wishes |
|
|
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
|
| Posted: Wed Apr 07, 2004 2:43 am |
|
|
Thanks Mr.Hamlett. Maybe you can help me with this problem...
After years of doing communication between PCs and microcontrollers, I can't believe such a problem has come to haunt me...I have a PIC16F870 based board running at 3686400Hz. I'm using the hardware UART (9600,8,N,1,no interrupt) to communicate with PC. A MAX232 is used for driver. The cable between my board and PC is a standard 1-meter serial cable. The code sits in a loop, reads the bytes and puts them in an array. PCM 3.188.
Now the problem: I see some framing errors (around %0.1 of the bytes). I just can't figure out the reason for this. The crystal speed assures zero baud rate error and everything else is just standard. I've tried other boards with the same result.
I thought I was sending the data from PC too fast (although I see no Overrun errors), but according to your response this is not the case. I'm just out of ideas...I appreciate your help. |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Apr 07, 2004 3:24 am |
|
|
| Haplo wrote: | Thanks Mr.Hamlett. Maybe you can help me with this problem...
After years of doing communication between PCs and microcontrollers, I can't believe such a problem has come to haunt me...I have a PIC16F870 based board running at 3686400Hz. I'm using the hardware UART (9600,8,N,1,no interrupt) to communicate with PC. A MAX232 is used for driver. The cable between my board and PC is a standard 1-meter serial cable. The code sits in a loop, reads the bytes and puts them in an array. PCM 3.188.
Now the problem: I see some framing errors (around %0.1 of the bytes). I just can't figure out the reason for this. The crystal speed assures zero baud rate error and everything else is just standard. I've tried other boards with the same result.
I thought I was sending the data from PC too fast (although I see no Overrun errors), but according to your response this is not the case. I'm just out of ideas...I appreciate your help. |
Do the faults come in 'batches', or just randomly?. One thing that can cause problems is the inability of async RS232, to guarantee to 'resync', if the receiver starts waiting for a byte when something is already being sent, and the data is continuous. Adding a one character delay in between the sent 'data blocks' avoids this.
The other thing to consider, is that the PC UART, may not be giving accurate timings. Technically the original IBM PC, used a clock to feed the UART, that gave good timings (4.77MHz - gives just 0.25% error at 9600bps), but many modern PC's 'synthesise' the UART clock from another frequency, and give quite suprisingly large timing errors!...
Is there any possibility of a noise source causing mis-triggers of the receive system?.
One problem might be your use of 'polled' communications, though I cannot see why... I have allways used interrupt driven comms, and had no problems. Given the relatively low data rate, I cannot see why there should be a problem. Also I'd expect this to give overrun errors, rather than framing errors.
One thing to check, would be the value that CCS, are writing to the SPBRG register. It should be 5 (giving a divider of 6 - assuming it is using BRGH=0), or 23 if BRGH=1, but if the code was generating a faulty division, and 'rounding down', it would result in problems. You could also try putting the clock freqency as 3686401Hz to force the arithmetic to round up!.
One question is whether you have verified the signal level being sent by the PC?. Some modern systems (especially laptops), use +/-5v signalling, instead of +/-12v. This reduces massively the noise margins at the receiver, and if the bus is a bit heavily loaded, can result in incorrect reception.
Best Wishes |
|
|
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
|
| Posted: Wed Apr 07, 2004 3:37 am |
|
|
Thanks for your reply.
The PC is a desktop with +/-12v RS232 signals. However I'll check the timings tomorrow to see if it has a large speed error.
The problem appears to be random, and my blocks already have delays between them (around 500ms). They are fairly small too (14 bytes). The framing error usually happens in the middle of block, but also sometimes in the beginnig too.
I don't think I have noise problem. And I don't think CCS is writing a wrong register value, but I'll check. I'll also try the 3686401 crystal speed (this one is interesting!)
Just one more question: How big the baud rate error needs to be to cause frequent framing errors? |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Apr 07, 2004 4:20 am |
|
|
| CCS considers a baud rate error of 3% to be the maximum acceptable error. I've seen this value in other discussions as well, but exact value depends on your data sampling method. |
|
|
SteveS
Joined: 27 Oct 2003
Posts: 126
|
|
| Posted: Wed Apr 07, 2004 7:07 am |
|
|
Also don't be looking so closely at the serial part that you miss something else - like a forgotten WDT, some other interrupt, etc.
But, back to RS232 - for continuous RS232 I'd use interrupt driven Rx. It's the only way to capture everything and do anything else useful.
If you have a scope - check the RS232 waveforms and timing. Echo the characters back and check the PICs timing. Then you'll know how close they are.
Look thru the listing to be sure the generated code is right and some big chunk didn't get in there somehow that you didn't expect.
- SteveS |
|
|
djpark
Joined: 02 Mar 2004
Posts: 49
|
|
| Posted: Wed Apr 07, 2004 10:40 am |
|
|
I tried 115200 baud without delay in between characters and it works fine. I fed a chunk of text from PC to 16F628A hardware UART and let PIC echo back and capture by PC, then two files (in and out) compared to be the same.
This is the code I use, taken from ex_sisr.c. I use huge receive buffer so that I do not lose an incoming character during the long delay for LCD init/clear.
| Code: |
#include <16F628A.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP,PUT,NOMCLR,BROWNOUT
#use delay (clock=18432000)
#use rs232 (xmit=PIN_B2, rcv=PIN_B1, BRGH1OK)
#define BUFFER_SIZE 64
BYTE buffer[BUFFER_SIZE];
BYTE next_in = 0;
BYTE next_out = 0;
#int_rda
void serial_isr()
{
int t;
buffer[next_in]=getc();
t = next_in;
next_in = (next_in+1) % BUFFER_SIZE;
if (next_in == next_out)
next_in = t; // Buffer full !!
}
#inline
int bkbhit()
{
return (next_in != next_out);
}
BYTE bgetc()
{
BYTE c;
while (!bkbhit())
;
c=buffer[next_out];
next_out=(next_out+1) % BUFFER_SIZE;
return(c);
}
void main()
{
set_uart_speed(115200);
enable_interrupts(global);
enable_interrupts(int_rda);
...
}
|
|
|
|
RKnapp
Joined: 23 Feb 2004
Posts: 51
|
|
| Posted: Wed Apr 07, 2004 11:02 am |
|
|
Because you are so experienced with these issues I don't meant to insult your knowledge, but I do feel the framing errors (absence/presence of a stop/start bit where it is unexpected) are difficult to find because the answer is too obvious.
a) I'm wondering if another app on the PC is co-opting the UART and setting it to 1.5-bit mode whenever it starts up, so you're always on the edge and just normally don't know it.
b) Or maybe the FIFOs in your PC aren't turned on, and then the PC gets interrupted and fails to return soon enough to properly shift out a character?
c) Finally (again in the unlikely but not impossible dept.) your UART card (particularly if it's a laptop) may have a bad power supply or design. Keeping in mind that 9600 baud pulses are wider than 115k pulses, it may not have enough "off" time for the capacitors to recharge.
d) The truly most likely idea in my mind is the "timing error" idea -- that the bits are not really the expected width.
How about trying another PC?
Just some ideas,
 Robert |
|
|
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
|
| Posted: Wed Apr 07, 2004 7:36 pm |
|
|
| Thanks everyone for your comments. I tried a different PC and everything is fine. It seems as Mr.Hamlett suggested the first PC had a big baud rate error. |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Apr 08, 2004 2:10 am |
|
|
| Haplo wrote: | | Thanks everyone for your comments. I tried a different PC and everything is fine. It seems as Mr.Hamlett suggested the first PC had a big baud rate error. |
Ouch....
Unfortunately (as you may have guessed from my comments on timing errors), I have seen this. I am lucky, in having a serial 'diagnostic' box, which you can stick in line between the two devices, and will work out tha actual baud rate being used, display the data, handshakes etc., and log it all for display. It is when you stick it onto a PC, and see the data being logged as being sent at figures like 9900bps for a 'nominal' 9600bps link, that you start to worry.
Glad you have it working now.
Best Wishes |
|
|
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
|
| Posted: Thu Apr 08, 2004 4:48 pm |
|
|
| 9900bps...Yes that's about the same speed I measured when I hooked up a scope to the PC. Well, lesson learned! |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
