Searching \ for 'Problem with continues dataflow via usart' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/io/serials.htm?key=usart
Search entire site for: 'Problem with continues dataflow via usart'.

Truncated match.
PICList Thread
'Problem with continues dataflow via usart'
1998\08\28@185305 by RemcoB

picon face
part 0 3023 bytes
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#000000 size=2>Hi everybody,</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>I'm working on a project with a large amount of
pic's in a peer to peer network configuration.</FONT></DIV>
<DIV><FONT size=2>Each station has to recieve compute and send all the data at
the 'same' time.</FONT></DIV>
<DIV><FONT color=#000000 size=2>To do so I use a serial recieve interupt, which
move the data to a small buffer.</FONT></DIV>
<DIV><FONT color=#000000 size=2>Each program cycle I get a byte out the recieve
buffer, compute it and send the byte away.</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>Everything works perfect except when I send a
large amount of data via the bus with no pause between the bytes, then I am
loosing a byte ones in the x thousand bytes. I checked my buffers timing etc,
but it seems to be all okay. </FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>When I use a little delay now and then in the transmision { 2
ms after 1000 bytes written } it works fine.</FONT></DIV>
<DIV><FONT size=2>I discovered that the frequency in wich the fault occured
depended on the caps that I used with my crystal. </FONT><FONT size=2>When I use
a single oscillator for all my stations, it all works fine. </FONT></DIV>
<DIV><FONT size=2>So I made seperate high precision oscillators for each station
and reduceded the fault so only one byte in the several hundreds of thousands is
lost. </FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Apart from the bytes that gets lost some others gets
corrupted, dispite the parity check.</FONT></DIV>
<DIV><FONT size=2>There does not occure a single parity or framing
error.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>Has anyone any ideas on what is causing the problem, I'm
getting very tired off this problem.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>Thanx,</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Remco Brenninkmeijer</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV></BODY></HTML>

</x-html>

1998\08\28@225643 by Chip Weller

flavicon
face
 Without seeing your code and knowing more about the system topology here
are my thoughts (which you probably have had):

 I am going to assume you have a daisy chain system, each PIC received from
its "upstream" device and sends to its "downstream" device. Each PIC would
be running the same software (at least as far as the communications). Each
PIC will send the character just processed on downstream and the grab the
next character in. (If I am wrong about this assumption, ignore the rest of
this message.)

 The UART is probably running in ASYNC mode (?). Async mode of course is
really synchronous with 16x the internal bit clock. Since each PIC is not
delaying between characters at all each UART is continuously sending "start
bit, data bits, [optional parity,] stop bit(s), start bit, data bits, ...".

 Now assume PIC1 is sending to PIC2 while running about 0.005% (50ppm)
faster than PIC2 is. This means after about 10000 bits (1000 bytes of serial
data) data is off by 1/2 a bit, which is about where the system will miss
the start bit. This provides about the correct error rate, so that would be
the problem I would try to fix.

 About framing errors check the errata sheets for your device. I think
there are known problems with this feature on some chips. As far as the
parity is concerned my first impression would be your parity generation and
checking may be at fault, since that must be implemented in software.

 So how do you fix this problem? First I would plan on sending 8-bit data
(no parity). Once each n (256?) bytes I would transmit using 9-bit data
sending an extra stop-bit. This would allow the fast/slow combination PICs
in the transmission chain to resync since all receiving PICs would always
receive using 8-bit data. Note if 9-bit data is desired a slight
modification would be to delay between sending two bytes. This is slightly
complicated since the TX shift register is double buffered, you have to wait
for the TX shift register to empty, not just the buffer. This can be checked
using the TRMT flag instead of the TXIF flag. However the big problem is
there is no way to generate an interrupt on the TRMT flag change. Another
fix, which would only apply if there is one and only one originator of all
transactions, would be to run that device's Baud RATE clock at say 1% slower
than the rest. This would result an extra bit clocks between bytes sent.

 Now if you are implementing a "token ring" approach to your protocol where
the packet continuously travels the ring of PICs the approach is to create
the gaps dynamically using a double buffer. This would get rather complex
and the timing messy, but I think it could be done. The idea would be to
have maybe 1 PIC insert a gap by buffering a byte of data once every n bytes
(or maybe when the token reaches it.) There would have to be a gap in the
input data at some point to allow the buffering PIC to unload it's extra
byte before it needs to grab another one. Hopefully you are not doing this.

BTW: many people on the PICLIST don't do HTML messages, you should send it
plain text.

Chip Weller
   {Original Message removed}

1998\08\29@090251 by Chip Weller

flavicon
face
I previously wrote:


>  Without seeing your code and knowing more about the system topology here
>are my thoughts (which you probably have had):
>
>  I am going to assume you have a daisy chain system, each PIC received
from
{Quote hidden}

serial
{Quote hidden}

wait
>for the TX shift register to empty, not just the buffer. This can be
checked
>using the TRMT flag instead of the TXIF flag. However the big problem is
>there is no way to generate an interrupt on the TRMT flag change. Another
>fix, which would only apply if there is one and only one originator of all
>transactions, would be to run that device's Baud RATE clock at say 1%
slower
>than the rest. This would result an extra bit clocks between bytes sent.

> <snipped a bunch of stuff.>

Sorry about the above advice, it was late here when I wrote it. Some
problems withe the above:
1. If the system is a true ring using 9-bit on the orginator will cause it
to drop incoming data which is only 8-bit.
2. Assuming a simple double buffering system each PIC would be able to
absorb a fair amount of extra bit space. This condition woudl occur if it
takes longer to process the first character than later characters. It may
take much longer extra time delays than I proposed above, more on the order
of 1 characters worth.

I thought some more about my analysis of the problem and I think I was on
the wrong track. If I was implmenting a hardware UART I would start
searching for the next start bit directly after detecting the stop bit
(dropping the last 1/4 to 1/2 of the stop bit). Allowing shorter input data
elements than the size of the output data element would solve the start bit
overrun condition. If Microchip did this (anyone on the list known internals
of the USART?) then your system would have have the above described problem,
but a different one. With continous data transmission a faster PIC could
still overrun internal double buffering and your software FIFOs in the
system.

Assuming no software FIFO you should be able to send about 20K characters
before overrunning the double buffering on the TSR using a 50 ppm crystal
(assuming correct oscilator and such). Assuming a 10 ppm crystal/oscilator
this drop rate does match your "high precision oscillators" statement and is
probably at least 1 order of magnitude lower error rate than expected from
the stop/start bit conflict. This also may explain the lack of any framing
errors and possibly any overrun errors (the overrun could occur in your
software loop, instead of in the hardware).

This is more likely to be your problem than what I first guessed. The
solution is to somehow slow the data xmit rate by a few fractions of a
percent at the orginal source of the data by adding gaps between output
bytes, either every byte or every few bytes.

Chip Weller

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...