> At 115k the first line *always* drops several of chars *before* the first
> CRLF. Never the same chars. The rest of the screen is almost always
> flawless, drops a few here and there, only about 2-3% of full screens have
> an error. But I can induce a few more drops by making Win 'do something'
> such as switching to other windows. I can see behind what I switch to that
> chars are dropped, and capture to log to make sure they really are
> dropped. Overall is obviously not working well.
>
> At 57k I grab 250k worth of log and -sometimes- there're a few dropped
> chars. Not always, even 'trying' to load the system to induce them.
>
> At 38k I grabbed 500k while doing several windows Find searches, reading
> email, 'cat'ting a few meg through PuTTY, and using a text editor in a DOS
> box. The drive, screen, and system in general was doing a lot of stuff but
> the capture was -perfect-.
>
> So the Q is whether it's *remotely* *possible* that these nonpolariZed
> caps could cause these errors?

You've already shown that system loading effects the error rate.  Obviously
that's not a hardware problem.  (There may still be one, however.  Write a
loop to dump the same character continually and look at everything with a
scope.)

It appears the PIC is overrunning the PC's UART input buffer.  You need a
better higher level protocol to fix this.  I like to use a command/response
scheme.  The host sends a command, then waits for the response to that
command before sending the next.  A command could ask for 32 bytes of data,
for example.  My generic serial line routines on Windows also configure the
serial port with several Kbytes of buffer.  I've never had a PIC overrun a
PC with these mechanisms in place.

Note that the problem is usually the other way around.  The PC is more
likely to overrun the PIC because the PIC has a small input buffer.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu