Simple asm delay ?

[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

[Jerson]

Brilliant work.

PS. It has a catch though. Te macro expansion occurs at compile time. So, you will not be able to "feed" the delay value at runtime