waitcnt
Newzed
Posts: 2,503
Can the Propeller execute more than one waitcnt, where waitcnt follows waitcnt?· I had an event occurring every 30 seconds and I wanted to increase it to 60 seconds.· I added another waitcnt line the same as the first but the delay stayed at 30 seconds.· Do the waitcnt's have to be separated by another instruction?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Comments
I don't know how your statement looks like but it should work with more than one waitcnt. Please be aware that the maximum time can be 53 seconds with one waitcnt statement.
Thomas
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
You can't get more than about 53 seconds' delay with a single WAITCNT with an 80MHz system clock. You simply can't fit enough bits in a 32-bit word to do that (the system clock wraps around at 32-bits). You can do two 30 second delays in succession like:
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
I don't understand why you can't get a 60 second wait with two WAITCNT statements as I've shown it.
Could you post exactly what you're doing? One of us may be able to see what you're doing wrong.
Mike
··· waitcnt(wait*28 + cnt)
··· waitcnt(wait*32 + cnt)
··· waitcnt(wait*27 + cnt)
··· waitcnt((wait*26 + 30_000_000) + cnt)
The above comes to 56.5 seconds + .375 seconds.· The rest of the time is overhead from the Propeller and the attached BS2E.
If I change 30_000_000 to 25_000_000 the time stamp show a 1-second decrease with each entry.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
Post Edited (Newzed) : 8/7/2007 7:02:57 PM GMT
What you describe doesn't make sense. I'm assuming that wait == 40_000_000 and that you're using an 80MHz system clock.
There must be something about the stuff that you're not showing us that accounts for this. Also, changing the 30_000_000 to 25_000_000 should not result in a change of 1 second. Don't forget that the overhead between the Propeller and the BS2E may account for the differences you're seeing. I suspect that the delay time is indeed correct and how you're measuring it is not.
Mike
··· waitcnt(wait*28 + cnt)
··· waitcnt(wait*32 + cnt)
··· waitcnt(wait*27 + cnt)
··· waitcnt((wait*27) + cnt)
and the time increased 1 second each reading.· I changed the last line to read:
·· waitcnt((wait*26 + 30_000_000) + cnt)
and the time decreased 1 second with each reading.· That's a change of 10_000_000 = .125 seconds
wait = 40_000_000 = .5 seconds
There were absolutely no changes to the program except the waitcnt changes.
I guess I'll just accept the 1 second increase and quit worrying about it.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
You've done this before ... come up with some kind of odd problem that doesn't make any sense, shown only part of the context, fiddled around a little, then given up.
You have a complex system here, cobbled together from bits and pieces ... this Propeller cog talking to that Propeller cog talking to a BS2e talking to a DS1302 clock chip. No wonder odd things happen.
Usually, when you have odd behavior without an explanation and understanding, it'll rear up again later and bite you ... or maybe it won't.
I don't think this has much to do with the waitcnt's. Add figuring this out to your probably long list of todo items. Stay cool!
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
That way you're always working from a fixed base time, not the time the WAITCNT executes.· That also makes the time required for the multiplication etc irrelevant (for sufficiently long delays).
·
"You've done this before ... come up with some kind of odd problem that doesn't make any sense, shown only part of the context, fiddled around a little, then given up."
I NEVER give up.· I said I had, but I didn't really mean it.· I have solved every problem I ever had - sometimes it took me days but I eventually got there.· So will it be with this one - sooner or later I will find the reason for the strange results I am getting.
I really appreciate your help, past and future.· When I stumble across the explanation for this problem, I'll let you know.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Post Edited (Graham Stabler) : 8/8/2007 8:18:22 AM GMT
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
··· waitcnt((wait*51 + 30_000_000) + cnt)
··· waitcnt((wait*59 + 7_000_000) + cnt)
Over a period of 30 minutes, the display gained 3 seconds,·which equals ·.1 seconds per minute or 6 seconds per hour.· I don't think I'm going to get much closer than that.
Sid···
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
CNT is just a 32 bit register that is incremented by the system clock. It does indeed roll over and start again. When the high order bit is a one, it will test as negative. When the high order bit is zero, it will test as positive. It's used as an unsigned 32 bit number. The WAITCNT instruction logic tests for equality with the destination field. The Spin method just adds a little overhead (microseconds) to the instruction itself.
With a 5MHz crystal, that's roughly 8KHz high which is a lot, but could be affected by crystal loading (with capacitance).
1) What board are you using for the Propeller and for the clock?
2) What's the XTALn setting in your code?
3) It would be interesting for you to borrow a frequency counter to check both oscillators.
· _clkmode = xtal1 + pll16x
· _xinfreq = 5_000_000
The DS1302 is a special module I built for the Proto Board and plugs into Prop Pins 2, 3 and 4 via a header I installed.
A frequency counter would be nice but I don't know of any one that has one.· In fact, I haven't even been able to find an electronics/Stamp/Proppeller aficionado in the Port Richey area.· So I'll just have to stumble along on my own.
I re-ran the test I reported in my last post.· Now the display is losing 4 secs every 10 minutes.· Must be due to this room warming up a bit.· Going to run it several more times with the same waitcnt parameters and see what happens.· The temperature in here has increased 2 or 3 degrees since I ran the first test this morning.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
··· waitcnt((wait*51 + 30_000_000) + cnt)
··· waitcnt((wait*59 + 7_000_000)+ cnt)
i was losing about 400ms every minute.··I increased the wait 400ms to:
··· waitcnt((wait*51 + 30_000_000) + cnt)
·· waitcnt((wait*59 + 39_000_000)+ cnt)
and I still am losing about 400ms per minute.· Before I go any further, why did the 400ms increase not·increase the display?
I thought about the 1302 inaccuracy.· If it was losing X ms every minute, the loss should be consistent and I should be able to compensate for it.· I'm not terribly concerned about how accurate the DS1302 is right now.· I'm more interested in getting a delay of 60 seconds.· I can get close to it but I can't hit it right on the button.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
How do you know what 60 seconds is? I keep coming back to this and your postings keep ignoring it.
If you have:
VAR long halfMinute
and:
halfMinute := clkfreq * 30
then:
waitcnt(halfMinute+cnt)
waitcnt(halfMinute+cnt)
will give you a 60 second delay (+ maybe 300us overhead) if your system clock is 80MHz.
If you're seeing something else, it's not the waitcnt statements.
I'm·going to change the wait count to:
waitcnt(clockfreq*30 + cnt)
Each reading should be 30 seconds plus overhead.· I'll let you know what I get.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Mike, I wrote:
waitcnt(clkfreq*30 + cnt0 and the wait was 4 secs too long each read.
So then I wrote:
waitcnt(clkfreq*26 + cnt) and the wait was 4 secs too short over 10 mins, i.e., 44:15 to 54:11
I debugged clkfreq and screen said 80_000_000. Don’t know if that was calculated or measured.
Then I wrote:
waitcnt(wait*52 + cnt) – ditto········· ·‘wait = 40_000_000
Changed wait in the CON block to 20_000_000 and wrote:
waitcnt(wait*104 + cnt) – ditto
Then I increased the wait .25 secs and wrote:
waitcnt(wait*105 + cnt) - ditto – 11:40 to 21:36
Then I increased the wait another .25 secs – total increase .5 secs - and wrote
waitcnt(wait*106 + cnt) – ditto
Then I increased the wait by 30 secs and wrote
waitcnt(wait*106 + cnt)
waitcnt(clkfreq*30 + cnt) – wait was 4 secs too short over 10 mins, i.e., 58:33 to 08:29
Added 1 sec to total wait time and wrote
waitcnt(wait*106 + cnt)
waitcnt(clkfreq*31 + cnt) – wait still 4 secs short over 10 mins – 14:21 to 24:17 – even after a 1 sec increase. How do you explain that?
I’m emotionally exhausted – think I’ll take a little nap.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Took a break from my waitcnt problems and modified my program so that everything that appears on my VGA also appears on Hyperterminal.· Now I can display the data stored in EEPROM and capture it to an Excel file.· More important, I can now use the Proto Board on the bench where I have no spare VGA - I just use Hyper as a substitute.
Back to waitcnt.· I wrote:· (wait = 20_000_000 or .25 secs)
··· waitcnt(wait*109 + cnt)······· '27.25 secs
··· waitcnt(clkfreq*29 + cnt)····· '29 secs
In 10 minutes the display lost 4 secs - 07:38:23 to 07:48:19.
I·added to the above two commands:
··· waitcnt(wait + cnt)···· 'that's .25 secs
Now the display gains 17 secs in 10 mins - 07:41:33 to 07:51:50.
I know I'm trying your patience, but can you explain why the display gains a total of 21 - (17 + 4) - secs when I add .25 secs to the wait.· This has nothing to do with the accuracy of the 1302 - so maybe it gains or loses a second every minute.· At least it is consistent and has no bearing on the waitcnt sequence.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
You're only showing a few lines from a complex program. There's interaction with a serial port. There's interaction with a Stamp with a timer on it. All of these can introduce some granularity and delays. I can't give you any idea of where the time is going because I neither have the rest of your program nor do I want it. The problem is not in the waitcnt!! If there was something wrong with this, none of the time-dependent stuff would work ... particularly serial I/O. If it were me, I'd just put in the two 30 second long waits and start looking for other causes for missing time. Don't forget that the process of measuring time and communicating time takes time.