Simple asm delay ?

[Acetronics2]

Hi,

The 683 has a TMR1 and also a CCP module ...

just use one of them for variable delays !!!

see asm examples in the relevant Datasheet chapter ...

may be 1 and 2 microseconds will need a "special treatment" ...

Alain

[ultiblade]

You are so right !

The thing is however, i have tmr1 setup as a counter and i use its overflow to sync the whole program on 100hz.

I have three different led's that are driven by fet's. Each led has it's own channel and due to the design of the driver, at a given moment only 1 led me be high.

To be able to shift the colors around, i turn on a certain channel for a certain ammount of time.

RED con %001
GRN con %010
BLU con %100 

loop60
    if ledred = 0 then goto noRED
    GPIO = red
    pauseus ledred
noRED:
    if ledgrn = 0 then goto noGRN
    GPIO = grn
    pauseus ledgrn
noGRN:
    if ledblu = 0 then goto noBLU  
    GPIO = blu
    pauseus ledblu  
noBLU:
goto loop60

Once interrupted the ledred / ledgrn / ledblu values are altered, but always in a way that ledred+ ledgrn + ledblu = 1000, the timer get's a reset and it then jumps back into the loop.

The example above works but pauseus can't delay faster then 12us ...

[Acetronics2]

Hi,

1µs to drive leds may really be overkill ...

but I stil think the CCP module can do the trick ...

Alain

[ultiblade]

You are right about the 1us. I'm using this to be able to fade between colors.

If I turn on the red led, wait 333uS, then turn on the green led, wait 333uS, and then the blue led and wait 333uS and then loop again, i have a white color at about 1000Hz, with no flickering. If i then increment the pauseus 333 for red and decrement the pauseus 333 for blu the color shifts smooth from white to about orange.

I use the pauseus command at 8Mhz, which has a shortest delay of 12us. In the fade cycle this results in that one (or two) led are almost off, but not completely. The last 12 cycles the led stay on for 12us, and in the last cycle it will turn off.

It works perfect except for the last few cycles ....

[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.