>I've seen slight reference to the topic of polarized vs nonpolarized but
 >nothing definitive. Yours seems to talk about *time* more than others
 >which is the issue I have right now.
 >Software. Using PICUSART to learn serial. Using Tera Term at the other end
 >to talk/monitor. Everything worked on the first try in both directions at
 >115k.
 >Hardware. Using PICDEM2, has MAX232ACPE, has non-polarized caps on +5,
 >C1/C2, and V+/V-. They're the right value but not the recommended type.
 >I'm sending and logging screens of about 2.5k of hello world text, about
 >80 chars plus CRLF, about 30x to fill a screen. Then a counter so I know
 >how long it's running. (Plus a blinkie-counter just in case the term
 >messes up I want to see that the PIC is still running.) Then an ANSI
 >'clear screen and home cursor.'
 >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
 >So the Q is whether it's *remotely* *possible* that these nonpolariZed
 >caps could cause these errors?

It's unclear from your description just _when_ you are getting these
errors. If these are the first few characters sent after first powering up
the PICDEM2 then I'd say your software is not waiting long enough for
system settling before sending the test data. To be sure you should put in
a 500ms delay loop before kicking off. Or, ignore the first block of test
data and only analyse the data which follows AFTER you press the reset
button. You could also put in an idle/wait loop that waits for a button
press on S2 or S3 before starting. The subject of polarised vs NP caps
would be more relevant on and end product design which might for some
reason need to be operating immediately on power-up. On the PICDEM2 under
bench test conditions this is probably not related to your problem.

However, I think what you are saying is that you are sending a large chunk
of test data and that you are missing characters AFTER you send a "clear
screen" sequence. The amount of processor time involved in performing a
screen clear on a windoze GUI type graphic display is enormous. I once
wrote a terminal emulator in assembler for a DOS application back in the
days of 20MHz machines and even then found a "screen clear" to be quite
problematic in terms of processor time. A line feed was worse because it
involved copying every character upwards. One would think line feeds would
be worse on windoze too but perhaps your terminal emulator does more
fiddling about with a screen clear.

It sounds to me like you are hitting a Windoze bottleneck, this is
evidenced because the problem increases with higher baud rates.

When working with mechanical devices such as teleprinters and the earlier
computer printers it was always standard practise (for me) to introduce
deliberate delays in the sending device after transmitting any sequence
that would perform a significant mechanical movement in the printer, such
as carriage return, line feed or form feed. It might be best if you treat
your windoze terminal as though it were mechanical and put in a few delays,
this is far easier than bothering to implement hardware handshaking.

Phil Seakins.

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