Beginner PASM ?

AGCB

What causes this? This is a slight modification of the PM PASM Blink program.

When loaded it does not start to alternately toggle till about 45 seconds later, then works correctly. Why the long initial delay?

Thanks
Aaron

CON                                  
  _clkmode = xtal1 + pll16x          
  _xinfreq = 5_000_000               

PUB main                               
  cognew(@toggle, 0)                 

DAT                           
           org         0             
toggle     mov         dira,   pin                                      
           mov         time,   cnt
           add         time,   #9
           mov         outa,   out    'start w/ 17 on, 16 off         
:loop      waitcnt     time,   delay
           xor         outa,   pin                       
           jmp         #:loop        

'-----------------------
pin        long       %11_0000_0000_0000_0000     'pins 16 & 17
out        long       %10_0000_0000_0000_0000    ' starting outa value 
delay      long       10_000_000     
time       res        1             

kuroneko

The #9 offset is only valid for a back-to-back mov/add/waitcnt sequence (minimal overhead). Since you use an extra mov you'd have to use #13.

AGCB

So what actually is this add for?

kuroneko

AGCB wrote: »

So what actually is this add for?

To make sure that you don't have to wait for a full 32bit wrap around. Only sampling cnt and then doing a waitcnt on it obviously misses the target which is where the adjustment comes in. It makes sure that the first waitcnt executes with minimal overhead (6 cycles).

AGCB

OK. So how do I figure the correct number to add or is there one that will work all/most of the time.

And what is happening in the 45 seconds? edit: I assume the cnt register is counting up ang rolling over to get back to the original value when time was set

kuroneko

AGCB wrote: »

OK. So how do I figure the correct number to add or is there one that will work all/most of the time.

The following sequence is minimal when adjusted by #9:

mov     cnt, cnt
                add     cnt, #9
                waitcnt cnt, advance

IOW it will take exactly 14 cycles (4+4+6). Any insn between the initial move and the final wait has to be accounted for. This is easy for your ordinary insn, if you plan to include hubops you're better off using a catch all offset or restructure your code accordingly. It's all down to what you want to achieve.

And what is happening in the 45 seconds? edit: I assume the cnt register is counting up ang rolling over to get back to the original value when time was set

Correct and that happens to take about 53sec @80MHz.

AGCB

So then are all subsequent waitcnt commands also going to be subject to having to wait for the cnt to equal the original set point?

Is there a different way of adding a short delay that avoids this?

AGCB

By a 'catch all offset' do you mean adding a number of ticks to the current cnt?

kuroneko

AGCB wrote: »

So then are all subsequent waitcnt commands also going to be subject to having to wait for the cnt to equal the original set point?

Not sure what you mean here. The #9 business is for the first wait ever, e.g. when entering a loop. After that you usually add something to the target value which is used by the next wait insn, e.g. waitcnt target, advance will wait for target == cnt, the next waitcnt - if used with target - will release advance cycles later (target_n+1 = target_n + advance).

kuroneko

AGCB wrote: »

By a 'catch all offset' do you mean adding a number of ticks to the current cnt?

If you don't know how long your hubop would take (8..23) then you'd have to add a number large enough to cover that. If you do know the exact amount will be sufficient.

AGCB

What does insn mean?

kuroneko

insn is short for instruction. Apologies.

AGCB

Thanks much kuroneko! I'll do some playing around and if I still have trouble understanding, come back.
Aaron