Strange behavior with variable
Greg LaPolla
Posts: 320
in Propeller 1
I am seeing some strange behavior and I cant figure it out. I have pasted the code in question. The issue is displayStep is called and the defined string is displayed. displayStepTemp is called and displays the string built in displayStep. I have tried using bytefill before and after each call and even tried using it in each routine. I always get the same result. Any insight would be much appreciated.
VAR
byte buffer[100]
PUB MAIN
bytefill(@buffer,0,100)
...
displayStep
displayStepTemp
...
PUB displayStepTemp
fmt.sprintf(@buffer,string("Temp: %-3d"),getTemp(mStep))
disp.DrawStringSmall (106, 80, @buffer)
PUB displayStep
fmt.sprintf(@buffer,string("Step: %-3d"),mStep)
disp.DrawStringSmall (106, 60, @buffer)
Comments
What happens if you call "displayStepTemp" first before "displayStep"?
Does the same issue occur with having the 2nd routine displaying the data from the 1st?
An archive any of us could load, would likely be a big help in finding the problem.
btw, my Spin may be a bit rusty, but the @ is needed for a DAT variable to get the address, but do we need it for a VAR?
VAR and DAT variable addresses are treated the same in Spin.
I didn't see anything obviously wrong with the code as posted.
The issue seems to be within the ILI9341-spi. It came from the OBEX and is mostly assembly. My assembly skills are nearly nil.
The fix I found to work is the following
Original
Fixed
I just did a little test with this code
pub main setup wait_for_terminal(true) fmt.sprintf(@buffer,string("MASH Temp: %-3d"), 25) term.str(@buffer) term.tx(13) fmt.sprintf(@buffer,string("MASH Step: %-3d"), 7) term.str(@buffer) term.tx(13)The output is as expected. What are you seeing when there is a problem? What do you want the output to look like?On another note, I was looking at the countdown timer code and thought that the timing loop looked out of whack. When doing precise timing in a loop, what you want to do is synchronize with the system counter outside of the loop, and then add your delay to the timing variable for waitcnt() inside the loop. Generically, like this:
t := cnt repeat ' so something waitcnt(t += LOOP_TICKS)In the code you have, the cnt register is being accessed during every waitcnt call. To be honest, I thought the loop would run slow, but it turns out it runs fast. I've had the code running for nearly an hour and it's fast by about 40 seconds. Funny, some of that code in that object looks like I wrote it (my styling in some parts of it -- perhaps elements were borrowed from something else I wrote). I did write another timer object, though, and compared that with the one you're using and against accumulations of the system counter. If you let the attached code run for a while you'll see that the timer you're using is fast. I think it's in the way that it's processing the values to stop at the end. In my countdown timer I use BCD registers (like RTCs do) to eliminate divide and modulus (which are slow).here is the original loop. as you can see if it starts with the seconds register = 0 it counts negative and craps out.
tix := 99 repeat if running waitcnt(clkfreq/ TIX_DLY + cnt) tix := --tix if (tix == 0) tix := 100 scs-- if (scs == 0) AND (mns > 0) scs := 60 mns-- if (mns == 0) AND (hrs > 0) mns := 59 hrs-- if (hrs == 0) dys-- if (scs == 0) AND (mns == 0 ) resetThanks for the insight and the code!