|
|
View previous topic :: View next topic |
Author |
Message |
wanli
Joined: 20 Aug 2004 Posts: 5
|
Hardware flow control of UART |
Posted: Thu Sep 16, 2004 8:27 am |
|
|
Hi folks,
I am trying to do some communication between two devices(two microcontroller) via UART Port. Since the speeds of both devices are different with each other (one is 70 MHz, the other one is 20MHz), there are some bytes lost when I send a string from faster device to slower device. and even worse, sometimes some wrong characters are received.
I think I must take a flow control mechanism to control the transport. I have tried some methods, using a IO pin, but it seems nothing helpful.
Did someone ever take such hardware flow control to make UART working stable? Please tell me your experience.
Thanks a lot.
wanli |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1933 Location: Norman, OK
|
|
Posted: Thu Sep 16, 2004 8:50 am |
|
|
What two processors are you using? Obviously at least one is NOT a PIC.
Basically the clock speed of the processors makes no difference, the baud rate is the only real consideration and they must match exactly for error free commuincations.
However, if processor clock speed is far enough away from the baud rate multiple, baud rate "error" could be your problem, especially if they are off by say 1.5% in opposite directions. This documented in the PIC datasheets in ths oscillator/UART sections.
For example I use an 18.432MHZ oscillator instead of 20MHz so baud rate multiple is exactly on and I have never encountered a problem with processor to processor communications even at 115K baud. |
|
|
wanli
Joined: 20 Aug 2004 Posts: 5
|
|
Posted: Thu Sep 16, 2004 9:28 am |
|
|
Thank you first!
I use a Java executable microcontroller (ajile 80 on JStamp) which working at 73.3MHz to
communicate with a Microchip MCU PIC18F6720, which is built in on a
board, and driven by a 20MHz Oscillator. I can't change the oscillator
because it is also built in on the board.
Before two weeks I posted an article in which I descriped my problem.
http://www.ccsinfo.com/forum/viewtopic.php?p=32051&highlight=#32051
Some friends (include you) replied me and give me some suggestion. I've tried all possibilities, but there are still problems.
My serial port code are as following:
#use RS232 (baud = 115200, XMIT = PIN_SERCON_TX, RCV = PIN_SERCON_RX, BITS = 8, PARITY = N, ERRORS)
char buffer[BUFFER_SIZE];
int next_in = 0;
int next_out = 0;
#define bkbhit (next_in!=next_out)
//interrupt routine
#int_RDA
RDA_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 !!
}
//get one char from the receive buffer
char bgetc()
{
BYTE c;
while(!bkbhit) ;
c=buffer[next_out];
next_out=(next_out+1) % BUFFER_SIZE;
return(c);
}
//Main routine goes here
void main()
{
char value;
int i;
char buff;
//enable the serial port rx interrupt
enable_interrupts(INT_RDA);
enable_interrupts(global);
do
{
//here process the received data
while(bkbhit)
{
buff = bgetc();
printf( "%c", buff );
}
}
while(TRUE);
}
When I send a string from Java device to PIC, it is only right when I
insert enough delay (e.g. 20 ms) between each byte. Otherwise some bytes will be lost or even wrong.
I have tested, from PIC to the Java device, all transmit are all right. So I
think it is the problem of different speed.
Have you any idea?
I am appreciate for your reading such a long reply.
Wanli |
|
|
drh
Joined: 12 Jul 2004 Posts: 192 Location: Hemet, California USA
|
|
Posted: Thu Sep 16, 2004 11:06 am |
|
|
Here's a guess.
You have the watch dog timer enabled and it is reseting every 18ms. _________________ David |
|
|
davidpk
Joined: 29 Apr 2004 Posts: 13 Location: Opelika, AL
|
|
Posted: Thu Sep 16, 2004 3:06 pm |
|
|
I had this exact same problem with an 18F452 running at 40MHz and my desktop PC. The communication from the PC to the PIC was only single characters but the PIC would respond with a lot of data (100's of bytes). I would get about half the data then it would turn into junk.
I was trying to run at 115.2K and the baud-rate error would accumulate through the whole transmission. When I changed the baud to 57.6K the problem cleared up.
It would show up again if I had longer strings of data. The best way to fix the problem is to use a baud-rate crystal. |
|
|
Ttelmah Guest
|
|
Posted: Fri Sep 17, 2004 2:15 am |
|
|
davidpk wrote: | I had this exact same problem with an 18F452 running at 40MHz and my desktop PC. The communication from the PC to the PIC was only single characters but the PIC would respond with a lot of data (100's of bytes). I would get about half the data then it would turn into junk.
I was trying to run at 115.2K and the baud-rate error would accumulate through the whole transmission. When I changed the baud to 57.6K the problem cleared up.
It would show up again if I had longer strings of data. The best way to fix the problem is to use a baud-rate crystal. |
Yes.
There are two parts to this problem. If you look at the chips data sheet, with 20MHz, and 115200bps, the timing error listed, is -1.36%, _if_ the compiler is being smart enough to correctly select the best multiplier. This needs checking (run the code in a simulator, and verify what bits are set in the UART control registers), since otherwise the rate selected using the default multipliers, will be 9.58% in error, and this will be unacceptable (normally around 4%, is considered the worst that can reliably be used..). Use of a crystal, that is a binary multiplier of the required baud rate, helps avoid this type of problem.
However the very long times involved, suggests something else deeper may be involved (hence the other posters suggestion of the watchdog). The code as given, 'echoes' the data back, and this should be pretty fast.
The timings involved, are a processor at 5MIPS, receiving data at just over 10000cps. There should then be time for 500 instructions on the PIC between each character. Now there is a lot of latency involved in the PIC interrupt handler, but even allowing for the quite large number of instructions needed to access the array, the whole routine should easily be handled in less than 150 instructions, suggesting that the PIC should comfortably be able to handle this.
Hence I'd start by checking that the UART is being programmed to the best settings for this processor (it may not be, since this is one of the latter chips with the enhanced UART programming, and some of these features are not well supported). If not, then look at manually selecting these options.
Then look at other things (such as the watchdog), since a 20mSec response is pretty ludicrous (assuming the code is as 'shown', rather than the output being to something like a 'soft' UART, which will cause problems...).
Best Wishes |
|
|
Guest
|
|
Posted: Fri Sep 17, 2004 3:36 am |
|
|
drh wrote: | Here's a guess.
You have the watch dog timer enabled and it is reseting every 18ms. |
the setting of the MCU is:
#fuses hs,noprotect,nobrownout,nolvp,put,nowdt
There is no watch dog timer. |
|
|
wanli
Joined: 20 Aug 2004 Posts: 5
|
|
Posted: Fri Sep 17, 2004 3:38 am |
|
|
sorry, I forgot to login for above reply. |
|
|
drh
Joined: 12 Jul 2004 Posts: 192 Location: Hemet, California USA
|
|
Posted: Fri Sep 17, 2004 9:34 am |
|
|
That's why it was a guess. The post from Ttelmah is very good! _________________ David |
|
|
|
|
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
|