Hello All! I'm replying to a bunch of clues/replys in this one msg. Got some good symptoms and some very *odd* ones. Have no scope. I'm not capturing anything but getting eyeball gauges by watching 20 to 40 screens or so at a time. They go by *very* quickly, roughly 5/sec. Then gauging %ages by how many messed up for the time I watched. To clarify what I send from PIC to TTerm. I changed it slightly so it's easier to read/count, and fits in a message screen here without wrapping. Here's a typical string: 123456789 123456789 123456789 123456789 123456789 123456789 At the end of each line is a space, CR, and LF. I send 30 lines to mostly fill a term screen. Then a counter on it's own line. At the end of each screen is an ANSI cursor-home and screen clear. Regardless of sending 60 or 80 char lines, 95% of -first- lines have errors. About 98% of the time the errors -start- in the -5th- decade like these: 123456789 123456789 123456789 123456789 56789 123456789 123456789 123456789 123456789 123456789 1789 123456789 123456789 123456789 123456789 123456789 89 123456789 *Almost* *never* does the error start in the 4th decade. And interestingly, when that 5th decade is crap the sixth is very often clean as seen above. Weird. When I was sending 80 chars, about 95% of the time only the first line had any errors, and other errors were -usually- further down the screen. When I shortened it 60 as seen above about 10% of errors actually drop the CRLF and text wraps around to the next line, and about 5% to the third line. == On Sun, 6 Apr 2003, Olin Lathrop wrote: > It appears the PIC is overrunning the PC's UART input buffer. You need a > better higher level protocol to fix this. I'm actually not sure about this. Here's what I *thought* might be aggravating the problem. I run a background program that gloms unused cycles for a distributed computing project. http://www.mersenne.org. What I described above are all with the program running, the 'four clean decades then glitch' thing. When I *disabled* the program the glitches -immediately- start happening in the middle of the *third* decade, again for a 'vast majority of screens.' And as usual the rest of the 30 line screen is very clean. When I enable the program again the glitches stay in the third for about ten screens, then as soon as the background program has gone through its' first 'cycle' of operation the glitches *immediately* shift fack up to the fifth decade. One would think that a background proggie that likes to steal cycles would cause -more- glitches when it's running, yet exactly the opposite is true. :/ No, I didn't say that right. It doesn't actually cause 'more' errors, but they start in a different place in the char stream. == Dave Tweed > If charge-pump loading was your problem, you'd see modified (wrong) > characters, not just dropped characters. Never ever any funky looking chars. I don't think. (Later..) In the logs I mention below, did about 10M of captures. Used grep to look for unusual lines and there were none with other than the numeric chars the PIC sent. > No, your problem is Windows, which is anything *but* a real-time > operating system. Windows can ignore interrupts for tens if not hundreds > of milliseconds at a time if it gets "busy" (e.g., clearing a screen or > switching windows), allowing the hardware FIFOs in the UARTs to get > overrun and causing the symptoms you're seeing. You need some sort of > flow control in order to accomodate this. 98% of screens are four clean decades in the first line, then the rest of the line drops a few, and most of -those- are -only- in the fifth decade with the sixth clean. Then 29 more perfectly clean lines and the counter. Of the remaining 2% there are very occasional glitches further down the screen. But again lasting only one line. > If you really need to sustain this kind of data rate into a Windows PC, > you might consider switching to USB or even Ethernet. External > serial-to-USB or serial-to-Ethernet boxes should be able to do this with > minimal setup. This is just to monitor the PIC with more info than a typical (read: inexpensive) LCD can display. I wouldn't even be bothering with all this if the whole screen was scrambled, just back off the speed. == Regarding the 'worst and worstest cases' idea. Sending 60 chars of 0x55 and 0xAA with no space just CRLF produces pretty much the same results. I watched a few hundred screens of each. Obviously can't see where in the line the chars drop. However it was easier to see that they dropped an average of about 5 chars. 95% in the first line only. Sometimes dropped maybe up to 10, sometimes line is OK. No pattern to it. == Dwayne Reid > What kind of capacitors? If they are the correct value, they will > probably work OK regardless of what kind of cap they are. The only > potential problem type *might* be a non-polarized electrolytic > capacitor. If they are ceramic or film caps, they are fine. They appear to be metal film. They don't look disc/ceramic at all and definitely no polarization markings. > This really sounds like a windows problem and that you are over-running > the UART in the PC. If you can, try going into the hardware properties > of the UART and setting the buffer value higher. (get to device manager > (Control Panel --> System --> Device Manager --> Ports --> Com2, select > Properties --> Port Settings --> Advanced. Move the Receive Buffer > slider to a higher number.) I thought of that but forgot to try it before. It was set to 'one tick from the highest.' I moved it up and it made no difference. Then I moved it to the very bottom and it actually improved. Meaning, sending 10101010, it drops 1 char about half the time, and a perfect fitst line half the time. Very rarely drops 2 chars. Very very rarely drops a char in the second or third line. Yes, of course FIFO is selected, I'm a waaaaay old modem geek. :) Just never dealt with USART on this low a level before. What does 'Select lower settings to correct connection problems' mean? That's counter-intuitive. > An easier solution is to send a packet of characters, pause briefly, > then send some more. This gives Windows a chance to process the buffer > before it overflows. Say: 8 characters, wait 1 char time, then 8 more. > Then start making the packets larger until you see problems and back off > to whatever is reliable. Sounds too much like work. :) At that point might as well just drop the speed. vvvvvvv Weird Alert! vvvvvvvv CRAP!!! I hate it when it does this!!!!! I hate it when software behaves weirdly. As I'm writing this the TTerm is behind this PuTTY window. It's not dropping a single char. Not one. Ever. Anywhere. As soon as I bring TTerm to the top it starts dropping. Again, only 1 char about half the time. Always only the first line. And as soon as I put it in the background it stops. At 5 screens/sec I can tell when it's starting/stopping the drops very quickly. I went back to the 1234567890 strings to see exactly where it's dropping the one char and it's in the 4th decade rather than the fifth as was previous with the buffer turned all the way up. == OK, foreground/background tests, logging lots of chars... At 115k with TTerm running as a background window I ran about 5M worth of log, about 155k lines, about 5k screens, and about half a dozen lines had a glitch. Running at 56k in foreground and then background window actually got more % errors than 115k in background. Meaning ran about the same amount of time, half the lines and screens, but the same number of total error lines. At those rates I am not excessively annoyed. Won't ever need more than a few screens per minute in actual use for what I need now. Will look into better data control another time. Have a :) day! jb -- jim barchuk jb@jbarchuk.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics