Simple asm delay ?

[ultiblade]

Google came up with an interesting piece of code.
I did some tests and it seems to do the trick.

If called using "@ wait 0" it delays 1uS,
if called using "@ wait 1" it delays about 2,5uS,
if called using "@ wait 2" it delays about 3uS.

asm
shortwait macro del  ; used by main wait macro
    if (del>3) && (del<8) 
        call del7+(7-(del)) 
    endif 
    if del <4 
        if del>=2 
            goto $+1
        endif
        if ((del) & 1) == 1
            nop
        endif
    endif
    endm
endasm

asm
wait macro del 
;    if (del)<0 error 'negative delay' 
;    endif 
    if (del)>=8 
        movlw ((del)-8) /4 
        call delay
        shortwait ((del-8) % 4) 
    else
        shortwait (del)
     endif
    endm

delay  
    addlw 0xff 
    skpnc 
    goto delay
    return
 
del7 goto del5      ; 7 cycle delay
del6 goto del4      ; 6 cycle delay
del5 nop            ; 5 cycle delay
del4 return         ; 4 cycle delay
ENDasm

So, the delay is not the problem anymore.
However, when called from picbasic like :

led1 var word
led2 var word

led1 = 2
led2 = 2

start:

GPIO = %01
@ wait _led1
GPIO = %10
@ wait _led2

goto start

The delay is about 33uS instead of 2. I understand that the delay would be longer, but 30uS extra ??

Can someone, please, point me in the right direction ?

[Jerson]

Once you start counting instruction cycles, you will realize how they all add up to get you to the 30uS extra that you see. A call takes 2 cycles, a return another 2, and so on.

I am a bit curious about your application and how you achieve colour fading. According to what you have shown here, you seem to be lighting the leds one behind the other with a fixed pause in between. I do not know why you have it that way, but, I would think it would be better to have them work in tandem unless you want just 1 led on at a time.

Why not use 3 PWM channels one per colour to control the intensity of each?
Now, the refresh rate for all the channels will be the same, but, the on-time for each led will be decided by its on-time variable.

Would this work for you?

[ultiblade]

Hi Jerson,

I understand your questions, let me explain some more :

I drive 3 powerled's directly from the mains using a led driver board. These led's are switched by FET's, each on it's own channel. The driver board itself is about 10x10mm, a pic with 3 pwm channels in a SO8 package is just not available. Everything larger won't fit the enclosure.

The driver cannot drive 2 or 3 led's at once, that's why i'm switching between the three. Doing so at a total delay (led1 delay + led2 delay + led3 delay)=1000Hz + some overhead.

Pauseus does it's work, and all is fading smoothly. Except for the first start of a color. This sticks to 12us. When a fade is started, the color that is being faded in does not start at 1 or 2 us but starts with an initial delay of 12uS.

Hope this makes my problem somewhat clearer ...

I did count the instruction cycles, i even did a cross comparison of the asm files, the one using a number @ wait 0 and the one using @ wait _ledRED both files are exactly the same and have the exact same length ! I played around with the variables, changed them to byte's, putting them in bank0 ....

Why would changing from a numeric value to a numeric value stored in a variable result in an overhead of 30uS, i just don't understand.

[ultiblade]

Small update :

Declaring the variables as:

ledRED VAR WORD BANK0

Does reduce the total delay somewhat, the shortest delay (0) now results in 20uS ..

[Jerson]

Try declaring your variable as BYTE instead of word. It will shave more time from the 20uS.

[Jerson]

Assuming you have TMR0 (8 bit timer) free, you can try this code

AsmDelay macro  delayus
      movlw  0FFh-delayus    ; delayus to overflow                          1T
      movwf  TMR0                                                                            1T
      bcf        INTCON, T0IF    ; clear the timer0 Overflow flag          1T
      btfss     INTCON, T0IF    ; wait till it overflows                          1T/2T
      goto      $-1                   ; back to the btfss                              2T
  
      endm

The minimum delay you will achieve will be 4T cycles or roughly 2uS at 8MHz.


The way to use it would be

      GPIO = %01
      @ AsmDelay 12
      GPIO = %10
      @ AsmDelay 24

I hope this takes you closer to your goal. The code is just a concept, you may have to correct it. One important point you should note - the maximum delay will be 255uS

[Bruce]

Try this.

asm
DelayCycles macro ncy ; ncy can be from 1 up to 256
  local n
n set   (ncy)   ; assign ncy value to label n

  while n > 2   ; inserts goto $+1 while n > 2
    goto $+1    ; burn 2 cycles
n   set   n - 2 ; n = n - 2
  endw
                ; handle left-overs
  while n > 0   ; 1 nop for odd numbers
    nop         ; burn 1 cycle
n   set   n - 1 ; n = n - 1
  endw
  endm
endasm

Main:
  HIGH 0
  @ DelayCycles 1  ; adds 1 nop
  LOW 0
  @ DelayCycles 5  ; adds 2 x goto $+1 and 1 x nop
  GOTO Main