VSC terminal problems

ManAtWork

I'm using VSC with FlexSpin, loadp2 and the built-in terminal for debugging. I've just noticed that when I print many, many lines without delay the buffer of the serial terminal overflows and some of the output is simply dropped.

240108.85us 1354 -04 RX Datagram i=63 dg=18 wc=1
240321.13us 1360 -06 TX Datagram i=64 c=5 a=03e8:0120 s=2
240327.33us 1368 0074.49us 2377 -02 enqueue pending cyc=0
340102.41us 2381 -04 RX Datagram i=104 dg=60 wc=1
340107.33us 2387 -05 HandleDG len=10 cnt=35 srv=3000 cmd=60
340115.46us 2394 -03 WriteSDO index=1c13 subIndex=00

This is a snippet of a very long logfile output (several 1000 lines). The first numer is a timestamp. The second number is my buffer index (to make sure it's not a bug in my buffer handler). In the 3rd line the output stops right after the '1368' and several 100 lines are skipped. The the output continues just in the middle of a timestamp '...0074.49us'. I've double checked that this is not caused by multiple cogs calling printf() concurrently. I've stopped all other cogs before printing the logfile.

If I add a _waitms (10); after printing each line the problems are gone. However, I'm not sure if the text is lost on the propeller side or on the PC.

Another problem is that the terminal program is hogging 100% CPU time of one of the cores.

I think there should be a better method waiting for characters received than busy waiting.

Can anybody recommend a different terminal software that can be installed for VSC?

Wuerfel_21

The buffer overflow problem is with loadp2 itself (or rather, it doesn't happen with PropTool/PNut's terminal). You can try running loadp2 in another terminal emulator or redirecting the output to a file, it will still happen. Changing some of the serial port buffer settings changes how often it happens, but you can't make it stop entirely. I'm pretty sure I complained about this ages ago but no one seemed to care. I just kinda worked around it - reduce amount of data printed and re-run whatever test I'm doing if it still corrupts the interesting part. This bug is only on Windows however, so upgrading to Linux will fix it.

Simonius

the last time i checked, proptool would not find any serial ports in wine under linux

Wuerfel_21

@Simonius said:
the last time i checked, proptool would not find any serial ports in wine under linux

such is still the case. Maybe a table will clear your confusion

	Windows	Linux
PropTool	Good	Can't find serial port
PNut	Good	Good(?)
loadp2	Buffer overflow bug	Good

ManAtWork

I'm not even sure if it's a bug of load2p or the terminal itself. Sometimes, PNut also can't keep up with the data stream. But it priorizes things correctly and decides that buffering of the data is more important than the screen update. So the screen output temporarily locks up but given enough time it eventually catches up, again.

Wuerfel_21

It is certainly loadp2. As mentioned, it happens even when you redirect the output to a file.

Simonius

There are more than one failures overlaying each other
1. proptool seems to fetch byte by byte from the driver instead of a chunk of say 100 bytes at once, which results in many many dll calls and huge overall CPU load
2. there is no handshaking, the fifo in the ftdi chip or the computer will just overrun and then drop data, the DTR signal is used otherwise (wired to the reset of the propeller)

ManAtWork

@Wuerfel_21 said:
It is certainly loadp2. As mentioned, it happens even when you redirect the output to a file.

Ok, thanks. If loadp2 is to blame then it can be fixed.

@Simonius said:
1. proptool seems to fetch byte by byte from the driver instead of a chunk of say 100 bytes at once, which results in many many dll calls and huge overall CPU load

I don't care about the CPU load when there is active data transfer over the serial bus. It's just annoying that it still needs 100% CPU while it's completely idle. That keeps my PC fan spinning at higher PRMs.

2. there is no handshaking, the fifo in the ftdi chip or the computer will just overrun and then drop data, the DTR signal is used otherwise (wired to the reset of the propeller)

Ok, that should be fixed by making the buffer larger and pulling larger chunks at once if possible.

ManAtWork

Another funny problem is that sometimes the terminal inserts a blank after each character.

Looks like an editor that displays a UTF16 file an UTF8. But that's not the case. the "02" in the last line has no gap in between.