Waitcnt and "blowing" right past the value
CharlieII
Posts: 70
For some reason I seem to be shooting right past the (value + cnt) amount during the execution of the code and obviously "never" having cnt equal value + cnt and the code "never" starting again.
I read in the manual that it takes ~381 clock cycles to execute something similar to
Waitcnt (Value + cnt)
And that you should subsequently never let "Value" get lower than ~381 or so or you will have passed the value+cnt before you even get the line executed.
I however cannot seem to even get remotely close to that level. I cannot even get down in the 20_000 range for "Value" without the system halting, which I am assuming is because I have already passed the cnt.
I checked this by lowering the processor speed to 5Mhz while leaving "Value" set to something that was apparently halting it when running at 80Mhz and it wouldn't stop anymore, but continue on with the code instead.
I cannot remember the exact code offhand, but even the example straight out of the manual in the section on "Waitcnt" would not run for me
In my own code when I initially ran into the problem I was doing something similar to this when the problem was encountered...
Or something similar. I hooked an LED to pin 10 and it would light, but not ever turn back off to make a cycle. If I upped the Offset value to say 300_000 or so it would work just fine.
What am I doing wrong here? I know the interpreter is not this slow right?
Thanks guys,
Charles
On Edit: It's not showing my indention on the forum, but I did indent properly after the repeat.
Post Edited (CharlieII) : 11/27/2007 5:40:37 AM GMT
I read in the manual that it takes ~381 clock cycles to execute something similar to
Waitcnt (Value + cnt)
And that you should subsequently never let "Value" get lower than ~381 or so or you will have passed the value+cnt before you even get the line executed.
I however cannot seem to even get remotely close to that level. I cannot even get down in the 20_000 range for "Value" without the system halting, which I am assuming is because I have already passed the cnt.
I checked this by lowering the processor speed to 5Mhz while leaving "Value" set to something that was apparently halting it when running at 80Mhz and it wouldn't stop anymore, but continue on with the code instead.
I cannot remember the exact code offhand, but even the example straight out of the manual in the section on "Waitcnt" would not run for me
In my own code when I initially ran into the problem I was doing something similar to this when the problem was encountered...
Dira[noparse][[/noparse]10]~~ Repeat Outa[noparse][[/noparse]10]~~ Waitcnt (20_000 + cnt) Outa[noparse][[/noparse]10]~ Waitcnt (20_000 + cnt)
Or something similar. I hooked an LED to pin 10 and it would light, but not ever turn back off to make a cycle. If I upped the Offset value to say 300_000 or so it would work just fine.
What am I doing wrong here? I know the interpreter is not this slow right?
Thanks guys,
Charles
On Edit: It's not showing my indention on the forum, but I did indent properly after the repeat.
Post Edited (CharlieII) : 11/27/2007 5:40:37 AM GMT
Comments
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 11/27/2007 5:37:47 AM GMT
WAITCNT( 20_000 + cnt ) will wait for roughly 250us, still not too long. WAITCNT( 80_000 + cnt ) will
finally wait for all of 1ms. If you want something you might begin to see, try WAITCNT( 8_000_000 + cnt ).
waitcnt(clkfreq/1000 * t + cnt)
where t is the time in mSec based on the clkfreq/1000 (mSec), such as:
waitnct(clkfreq/1000 * 250 + cnt) ' pause for 250 mSec
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
SelmaWare Solutions - StampPlot GUI for controllers, XBee and Propeller Application Boards
Southern Illinois University Carbondale, Electronic Systems Technologies
Because I actually have to get down to a bare minimum of 76us just to physically perform the task at hand. This was absolutely no problem for the BS2PX because it took roughly half that much time just to "turn around" from a "High" to a "Low" and so forth. Not to mention the "Pulsout" command was set in units of .8us
If I can't use the resolution that the higher clock cycles offer in the way of very precise and small delays, then unfortunately the propeller will not work for me.
Will the code utilizing the clockfreq help this issue of the processor skipping right past the value while the code is executed or will the extra code involved there make this worse?
And is a value of 20_000 really to small to keep the program running along?
Because since I couldn't get the example from the manual to run I am really questioning if something is simply wrong with what I am doing somewhere.
When I ran that exact code it would lite the LED set to the pin but never do anything else. If I raised the value higher than the 50_000, to say 500_000 then it would work fine. And at the lower values it's not a case of it cycling so fast that I cannot see it either. I have scoped it as well and this level of resolution is very easy to see on a scope and it's simply not happening. The output just goes to 3.2ish volts and stays put. I waited for around a minute one time to see if the cnt would exceed 32bits and wrap back around but I never saw a change, although without a continuted sequence to watch I likely wouldn't be able to catch that singular event anyway.
This is a case where I actually do have to get pauses down at the microsecond level to operate the device.
I am surely just overlooking something, or mistyping something here. Any help with what I am doing wrong or with why it seems to be taking the interpreter an inordinate amount of time would be greatly appreciated.
Thanks,
Charles
Post Edited (CharlieII) : 11/27/2007 1:15:38 PM GMT
Tom
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -
"If Python is executable pseudocode, then perl is executable line noise."
"The best accelerator available for a Mac is one that causes it to go at 9.81 m/s2."
"My software never has bugs. It just develops random features."
"Windows isn't a virus, viruses do something."
"Programmers are tools for converting caffeine into code."
"Enter any 11-digit prime number to continue."
Mike gave you a hint. When being new to an area you will learn most (and be frustrated least) when starting with working examples and modify them....
You can be assured that controll within 12.5 ns resolution is possible, using the timers/counters. With some care it is also possible to do this from SPIN.
(On Edit... So that others might not fall into the same trap, the above posted example code is on page 322 of the manual if anyone wants to replace "Clockfreq" with "Clockmode" in that example)
I can get the thing to do rather large pulsewidth without issue. It is only when I am trying to get some decent resolution out of it (say pw less than 10ms) that it halts. I can only see it having already past the "Value + cnt" amount with the actual clock cnt before it gets done interpreting the code.
BTW, I am not simply looking at it with my eyes, I have always been using my 60Mhz ossciloscope. Trust me, it's not happening as I can perfectly nail any pulse down to only a few us with the BS2PX and the scope shows that to be in perfect correlation with the written code.
When I expect to see the light with my eye is when there are a series of these on and off events that are seperated by a pause that is percievable to the human eye. Seeing the light staying perfectly lit up 24-7 when it should have been percievably flickering was what prompted me to start checking the code to see why it halted and the reason is that it never gets past the line that has the first waitcnt in it (I think) but don't know.
And I did verify this with the scope. The output is a perfectly stable 3.2 or so volts forever.
When I get back home I will just upload the entire section of code I am working with and hopefully you all can tell me what I am doing wrong.
Thanks for the help, I'll try and get y'all a little more to work with when I get back home.
Charles
Post Edited (CharlieII) : 11/27/2007 7:32:00 PM GMT
One issue can be a bad fitted or damaged crystal. As you have a WAITCNT setting where the output is oscillating you should check whether that frequency is as expected wrt the crystal and your setting...
And thanks again for the help.
On Edit:
This is the other code from the Manual that also wasn't acting right. Now I can see that the "Clockfreq" was the issue with it too it seems.
Also updating that example would be beneficial as well IMO.
Post Edited (CharlieII) : 11/27/2007 8:01:55 PM GMT
Everybody edits those lines so no one has noticed...
That typo is not even in the Supplement/Erratum...
It seems like your tone here might be less than genuine. Hopefully that is just communicating with a keyboard misrepresenting your real tone though.
I appologize for not assuming the examples would need help to run on their own. Bare in mind that I have no experience with spin, and a very, very limited experience with programming at all. I am truly just trying to learn this stuff and unfortunately do not actually know enough to spot every problem in the code at this point.
I only mentioned the examples because it was just this weekend that I was personally copying and pasting them (plus any indentation needed after the copy/past maneuver) assuming that the manual would have to be right, and that if even it didn't work I surely had something bad wrong with my own stuff. Having the examples in the Manual work properly is paramount for someone initially learning something IMO. Just thought that fixing those would better the manual for others.
I know my questioning here must seem elementary to most of you, but that's where I'm at with this.
Sorry.
Post Edited (CharlieII) : 11/27/2007 9:33:11 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -
"If Python is executable pseudocode, then perl is executable line noise."
"The best accelerator available for a Mac is one that causes it to go at 9.81 m/s2."
"My software never has bugs. It just develops random features."
"Windows isn't a virus, viruses do something."
"Programmers are tools for converting caffeine into code."
"Enter any 11-digit prime number to continue."
Post Edited (crgwbr) : 11/27/2007 9:42:07 PM GMT
Also, I've used code similar to what was posted in CharlieII's 11:11am post to generate pulses for RC servos. Storing CNT once and only working with the stored value is a nice way to hide the overhead of SPIN.
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
The typo you found really should be in the Errata.
This is the entire code I was working with.
Pin 10 will visibly blink but pin 11 will stay lit. The incoming signals are both visibly blinking to the naked eye and are being produced by my BS2PX.
I however cut out all the input pins and wrote the code simply trying to output only with the 320_000 + cnt and it will not visibly blink nor can you see any squarewave output on the scope.
What have I done wrong here?
Thanks.
On Edit:
I don't know what else might be altered for whatever reason, but even though in the edit screen it clearly has a "" and a "" after the Dira and Dira that begins the main routine here it simply does not show up when viewed on the forum, oh well. But be aware that I did actually designate a pin for each of those pin input direction commands at the begining.
Okay.....can't even get it to show up in the "edit" of the original post. Anyway. There should be a bracket number1 bracket behind that first "DirA" and before the ~ and a bracket number2 bracket after the second "DirA" and before the ~ on that line...
I guess this application running the forum doesn't like to see brackets around the numbers 1 and 2 huh.
Post Edited (CharlieII) : 11/28/2007 3:41:12 AM GMT
-Phil
I see no reason why I/O 11 should behave differently from I/O 10;
note that your WAITPNEs and WAITPEQs require I/O2 to be HIGH
there will be undefined waiting when you have it open...
Edit: Oh, I just see I/O 1 is tricky:
That will not work statically...
Post Edited (deSilva) : 11/28/2007 8:51:09 AM GMT
However, the input was not the issue. I could use a button or the controller and it worked fine if I didn't try to output a small pulse that required a "small" value to be added to cnt for the waitcnt command.
I am going to give it a good looking over when I get time as it sounds like the way I was writing things should have been working fine. I may have some kind of a hardware issue with my wiring that I have not found yet.
If I find the issue I will report back.
Thanks guys.