Shop OBEX P1 Docs P2 Docs Learn Events
Waitcnt and "blowing" right past the value — Parallax Forums

Waitcnt and "blowing" right past the value

CharlieIICharlieII Posts: 70
edited 2007-11-28 21:50 in Propeller 1
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 confused.gif


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 Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2007-11-27 05:32
    Use [noparse][[/noparse]code] ... [noparse][[/noparse]/code] tags to envelop your code, and your indentation will be preserved.

    -Phil

    Post Edited (Phil Pilgrim (PhiPi)) : 11/27/2007 5:37:47 AM GMT
  • CharlieIICharlieII Posts: 70
    edited 2007-11-27 05:38
    Thanks
  • Mike GreenMike Green Posts: 23,101
    edited 2007-11-27 06:22
    WAITCNT( 400 + cnt ) doesn't wait very long. At an 80MHz clock, we're talking about maybe 5us.
    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 ).
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2007-11-27 06:47
    If you want to use code that relates to real time values, regardless of the clock speed, use:

    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
  • CharlieIICharlieII Posts: 70
    edited 2007-11-27 13:06
    Surely the language is fast enough for me to call for 20_000 + the current clock count and still perform the task right? Even that would create a delay over 3 times longer than what I have to produce.

    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.

    
    CON
    
      _clkfreq = xtal1 'Set for slow crystal
      _xinfreq = 5_000_000 'Use 5 MHz accurate crystal
    
        repeat
          !outa[noparse][[/noparse]0] 'Toggle pin 0
          waitcnt(50_000 + cnt) 'Wait for 10 ms
    
    
    




    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
  • Mike GreenMike Green Posts: 23,101
    edited 2007-11-27 15:29
    Unless you've mistyped, you show "_clkfreq = xtal1" when this should be "_clkmode = xtal1"
  • TomSTomS Posts: 128
    edited 2007-11-27 15:58
    How do you know the LED isn't turning off?· At a 50% duty cycle and on/off times less than·the persistance of your eyes·you will see the·LED at half brightness, which is probably indistinguishable from full brightness.



    Tom
  • crgwbrcrgwbr Posts: 614
    edited 2007-11-27 16:35
    I agree with Tom on this one. Unless you have hooked the pin up to a very fast oscilloscope, then you probable just don't notice the LED flickering. I beleive that the eye only uses about 30fps. Therefore, a frame would last ~33.3 mS making it impossible to see a 10 mS pulse.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "... 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."
  • deSilvadeSilva Posts: 2,967
    edited 2007-11-27 16:50
    @CharlieII
    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.
  • CharlieIICharlieII Posts: 70
    edited 2007-11-27 17:02
    The example I posted is cut and pasted directly from the Propeler Manual off of the website. The typo in the clock sequencing explains why it would not work for me.

    (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
  • deSilvadeSilva Posts: 2,967
    edited 2007-11-27 17:38
    CharlieII said...
    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.
    Yes, that would be fine! Because it makes little sense what you are reporting up to now...

    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...
  • CharlieIICharlieII Posts: 70
    edited 2007-11-27 19:11
    I appologize if I am being vague in my questioning. Hopefully by laying out the entire section that is getting messed up you all can help me to see why it's not working.

    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.

    
    CON
    
      _clkfreq = xtal1 'Set for slow crystal
      _xinfreq = 5_000_000 'Use 5 MHz accurate
    
    PUB Toggle | Time
      Time := cnt 'Get current system
      repeat
        waitcnt(Time += 50_000) 'Wait for 10 ms
        !outa[noparse][[/noparse]0] 'Toggle pin 0
    
    
    



    Also updating that example would be beneficial as well IMO.

    Post Edited (CharlieII) : 11/27/2007 8:01:55 PM GMT
  • deSilvadeSilva Posts: 2,967
    edited 2007-11-27 20:26
    Oh, dear...
    Everybody edits those lines so no one has noticed...
    That typo is not even in the Supplement/Erratum...
  • CharlieIICharlieII Posts: 70
    edited 2007-11-27 21:28
    deSilva said...
    Oh, dear...
    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
  • crgwbrcrgwbr Posts: 614
    edited 2007-11-27 21:36
    This should work:

    CON
    
      _clkmode = xtal1           'Set for slow crystal
      _xinfreq = 5_000_000    'Use 5 MHz accurate
    
    PUB Toggle
      dira[noparse][[/noparse]0] := %1
      repeat
        waitcnt(clkfreq/1000*10 + cnt)   'Wait for 10 ms
        !outa[noparse][[/noparse]0]                       'Toggle pin 0
    
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "... 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
  • LawsonLawson Posts: 870
    edited 2007-11-27 21:52
    wow, I'm surprised that typo in the manual didn't raise a error in the propeller tool when it was compiled to byte code. Still even if the prop tool just took "xtal1" as a binary number, none of the code uses the internal "Clkfreq" value so I'm unsure why it failed for you.

    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?
  • mparkmpark Posts: 1,305
    edited 2007-11-27 23:35
    CharlieII said...
    deSilva said...
    Oh, dear...
    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.
    ...
    Actually, I think deSilva was being·sincere. There's just something about the way he writes in English (which is not his native tongue) that occasionally sets some folks' nerves on end. Don't take it personally. It's all part of the deSilva charm.

    The typo you found really should be in the Errata.
  • CharlieIICharlieII Posts: 70
    edited 2007-11-28 02:53
    That's what I was hoping to hear. I know how hard it is to communicate tone in your writing when in a casual grammar environment like an internet forum.


    This is the entire code I was working with.

    
    CON
    'Set clock speed to 80 MHz
      _clkmode = xtal1 + pll16x        'Sets the clock speed to 80 MHz using a times 16 multiplier
      _xinfreq = 5_000_000             'Crystal speed: 5 MHz
    
      
    
    
    
    
    PUB Start                          'A PUBlick procedure named Start                                                            
                           
    
    
                                                                                                                                  
                                                                
    
      DirA~                        
      DirA~                        
      DirA[noparse][[/noparse]10]~~                      
      DirA[noparse][[/noparse]11]~~                       
    
      Repeat
    
        Waitpne(0, |< 1, 0)            
        Outa[noparse][[/noparse]10]~~                    
    
        Waitpne(0, |< 2, 0)            
        Outa[noparse][[/noparse]11]~~                    
        Waitcnt(320000 + cnt)         
        Outa[noparse][[/noparse]11]~                     
        Waitpne(0, |< 2, 0)          
        Outa[noparse][[/noparse]11]~~                    
        Waitcnt(320000 + cnt)         
        Waitpne(0, |< 2, 0)           
        Outa[noparse][[/noparse]11]~~                   
        Waitcnt(320000 + cnt)         
        Outa[noparse][[/noparse]11]~                     
        Waitpne(0, |< 2, 0)            
        Outa[noparse][[/noparse]11]~~                     
        Waitcnt(320000 + cnt)        
        Waitpeq(0, |< 1, 0)            
        Outa[noparse][[/noparse]10]~                    
    
        Waitpne(0, |< 2, 0)            
        Outa[noparse][[/noparse]11]~~                     
        Waitcnt(320000 + cnt)         
        Outa[noparse][[/noparse]11]~                      
        Waitpne(0, |< 2, 0)            
        Outa[noparse][[/noparse]11]~~                    
        Waitcnt(320000 + cnt)         
        Waitpne(0, |< 2, 0)             
        Outa[noparse][[/noparse]11]~~                     
        Waitcnt(320000 + cnt)          
        Outa[noparse][[/noparse]11]~                      
        Waitpne(0, |< 2, 0)           
        Outa[noparse][[/noparse]11]~~                     
        Waitcnt(320000 + cnt)
    
    
    
    




    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 Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2007-11-28 03:58
    The problem you're having is that [noparse][[/noparse]1] and [noparse][[/noparse]2] are special formatting tags (font size) that the forum uses. If you filter your code through my formatter (www.phipi.com/format), it will take care of the bracket problem for you. But you can't re-edit your post after that without going through the formatting again.

    -Phil
  • deSilvadeSilva Posts: 2,967
    edited 2007-11-28 08:29
    Lawson said...
    wow, I'm surprised that typo in the manual didn't raise a error in the propeller tool when it was compiled to byte code.
    580 x 400 - 31K
  • deSilvadeSilva Posts: 2,967
    edited 2007-11-28 08:43
    @CharlieII
    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:
        Waitpne(0, |< 1, 0)            
    .....      
        Waitpeq(0, |< 1, 0)
    


    That will not work statically...

    Post Edited (deSilva) : 11/28/2007 8:51:09 AM GMT
  • CharlieIICharlieII Posts: 70
    edited 2007-11-28 21:50
    I had another controller sending a squarewave input to the propeller. I realized a little bit ago that the controller supplying the input was running a 5v signal being that it was the BS2PX....

    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.
Sign In or Register to comment.