IDE Debug output line breaks in wrong place?

stevech · Post by **stevech** » 06 October 2006, 20:41 PM

has anyone else noticed this problem...
If the ZBasic chip sends a few dozen lines of text out the console port, the lines displayed in the IDE's debug window are incorrect and inconsistent. Using a terminal program like Bray's Terminal, the output is perfect.

Here's an example where there are line breaks in the wrong place. Looks like no characters were lost. (19.2Kbaud)

00078 state5 20:55:27.660
00079 state4 20:55:27.225
00080 state5 20:55:26.904
00081 state
4 20:55:26.467
00082 state5 20:55:26.146
00083 state4 20:55:25.709
00084 state5 20:55:25.391
00085 state4 20:55:24.955
00086 state5 20:55:24.635
00087 state4 20:55:24.199
00088 state5 20:55:23.879
00089 state4 20:55:23.441
00090 state5 20:55:23.12
1
00091 state4 20:55:22.684
00092 state5 20:55:22.365
00093 state4 20:55:21.930
00094 state5 20:55:21.609
00095 state4 20:55:21.172
00096 state5 20:55:20.854
00097 state4 20:55:20.414
00098 state5 20:55:20.096
00099 state4 20:55:19.660
00100 stat
e5 20:55:19.340

Post by **dkinzer** » 07 October 2006, 16:53 PM

It is interesting that the extra EOL is injected after 256 bytes of output. There may be improper handling of a "buffer full" condition somewhere in the IDE.

It may also be that the Windows API to the serial interface is injecting the extra EOL. If you were to add a small delay after each line output it may change the dynamics of the data buffering. I'm not suggesting that that is a solution - just a test.

Post by **dkinzer** » 07 October 2006, 17:35 PM

The only way that I have been able to replicate this problem is to crank up the Com1 speed to 115.2K. Even then the extra EOLs are farther apart than the 256 bytes that you've shown.

Are you running Com1 faster than the standard 19.2K?

stevech · Post by **stevech** » 07 October 2006, 20:40 PM

no, standard 19.2.
I suspect it happens only when I'm using a WiFi to serial bridge - that changes the timing.