Is there a way to query for presence of serial connection to enable/disable PST?

ags

I've been observing that if I'm not attentive, and reset my Propeller Proto Board which in turn loads code from EEPROM that has debugging enabled (in which I use the Parallax Serial Terminal for printing out values), it seems to cause the program to hang. From a brief look at the PST object, I am assuming this is because after a tx buffer eventually fills, further calls (in SPIN - cog0) are blocked until the buffer can be flushed - which never happens.

Is there already a well-known way to query for a serial connection? This way I could dynamically enable/disable debugging depending on a connection. It's not a big deal, but would be nice. I have so many bits of code half-done that I'd rather not spend the time to implement a solution for this on my own right now.

Thanks.

nohab

Hi,
Is it a proto board with or without USB chip?
I haven't had any problems with debugging out to the cyberspace with the old protoboard, but when I bought a protoboard with USB onboard, I ran into same problem as you.
If I remember right it's something with the power (or lack of) to the USB-chip when not connected to a PC.

Now I always have these rows in the beginning of the program:

if ina[30..31] == %11
  debugflag := 1
  debug.start(115200)
else
  debugflag := 0

and later when I might want to display a variable:

if debugflag
       debug.dec(value)

Oldbitcollector (Jeff)

An elegant solution!

Thanks!
OBC

ags

nohab wrote: »

Hi,
Is it a proto board with or without USB chip?
I haven't had any problems with debugging out to the cyberspace with the old protoboard, but when I bought a protoboard with USB onboard, I ran into same problem as you.
If I remember right it's something with the power (or lack of) to the USB-chip when not connected to a PC.

Now I always have these rows in the beginning of the program:

if ina[30..31] == %11
debugflag := 1
debug.start(115200)
else
debugflag := 0

and later when I might want to display a variable:

if debugflag
debug.dec(value)

Yes, that's exactly the case. I have the Proto Board USB, with the USB module onboard. I didn't stop to think of the power being the issue, I thought it would happen whenever there was no valid "handshake" on pins 30/31; the PST would wait for a response until it's tx buffer was full, then block further execution.

Funny, when I first got my Proto Board USB, I plugged it into a desktop USB port (didn't read one word of documentation) and immediatly tried to write/download/run my version of "Hello world." (I guess that would be "Blink LED world here) It took me about 15 minutes to realize that the USB connection was not powering the board - but it was powering the USB chip onboard (the red/blue rx/tx lights flashed very nicely even without powering the board).

So it appears that the USB chip holds pins 30/31 high when connected to a host (and powered up!), which is how your test works? That will work just fine for me, as I already have all of my PST.*() code encapsulated in "if debug" conditional blocks.

BTW, this is also a good thing to know, as it means that whenever the USB port is connected (not necessarily actively communicating with a host) pins 30/31 are not available for other use. I didn't know that either.

Thanks!