Why Parallax Serial Terminal cannot do what fullduplexserial can

JWR

In the code below the ‘fullduplexserial’ works, while the ‘Parallax Serial Terminal’, doesn’t. Notice, there are two versions of the 'go' method.
What am I doing wrong?




CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
VAR
long stack[10]
byte cog
OBJ
pst : "Parallax Serial Terminal"
debug : "fullduplexserial"
PUB start
cognew(go, @Stack)


{PUB go 'THIS WORKS
debug.start(31, 30, 0, 115200)
repeat
debug.str(string("-"))
waitcnt(clkfreq/5+cnt)}


PUB go 'THIS DOESN'T WORK
pst.start(115200)
repeat
waitcnt(clkfreq/5+cnt)
pst.str(string("+"))

Duane Degn

I doubt fullduplex would work long with just 10 longs for stack space. These methods have lots of variables, you'll need larger than normal stack space.

Cluso99

JWR: Welcome to the forum.

You would be better to post this to the Propeller 1 forum.

To post code (and keep the formatting) enclose your code between (code) and (/code) tags where ( and ) are replaced with the square bracket versions.

Dave Hein

I tried your code, and it works if the stack size is increased to 20. The Start method in the PST object calls the StartRxTx method, which adds another stack frame plus calling parameters on the stack. I count 11 longs just for that, plus Spin needs some scratchpad area on the stack.

JWR

<div>I found a weird difference between two serial communication tools: while the FullDuplexSerial run as expected, the PST didn't. Now I know that it was because stack space of 10 was short of what PST required. </div><div>Thank you very much, your help saved me a lot of time and frustration. </div><div><br></div><div>I am an intermittent and inexperienced user, relying heavily on the PE Kit Labs. I did not realize that when the PST is called in any cog other than 0, it has to have a stack space reserved, just like any method or object. Among methods in PE Kit Labs there is not a single case that shows such use, inducing my impression that the PST by design does not require a stack space declaration. </div>

Duane Degn

The reason for the stack space is the way you're starting PST in a new cog. If you just called "Go" without the cognew you wouldn't need to worry about the stack space.

So if you had run "Go" in cog 0, you won't have this problem. As it is, you're running "Go" in cog 1 and letting cog 0 die. The serial driver (either one) is likely running in cog 2.

Both PST and FDS start a new cog to run the PASM serial driver. Cog using PASM, don't require the stack scratchpad space like cogs running a Spin interpreter.

Here's a link to a thread where I tried to figure out how the stack space worked. I thought it was very interesting to watch the stack memory get used as different branches of the program were running.