Bit Angle Modulation (BAM) in a PIC

[lanyong]

Yep=)))
It's something like that.


btw, i had got my first shocks from electronics mosquitowhen i tryed to understand how my photoflash works. There was ~1000V on capacitor after trafo, but it didn't scare me) i was 5 years old then)

but it is a secret for me.

we can use the 1000v to electronic mosquito,

[Mike, K8LH]

Darrel,

I think these Gentlemen may be having a little fun at your expense as they try to get a rise out of you (LOL). That's the only reason I can think of for avoiding a simple question and for becoming a bit offensive when challenged.

My precalculated "output table" or "toggle table" MIBAM method should work fine with 13 or 14 bit duty cycle values but as you've already determined I can only get refresh rates of 610-Hz (8-chan, 13-bit, 200-nsec step) or 305-Hz (16-chan, 13-bit, 400-nsec step), etc., when using an 18F' device and 40-MHz clock (Tcy = 100-nsec). ISR "overhead" would be about 77% for the example below but could be improved with some structural changes.

Take care. Kind regards, Mike

;
;  8-chan (port b), 13-bit, 200-nsec (1638.4-usec period), 610-Hz
;
v_isr_h
        movff   bdat+12,LATB    ; b12 data        (2048T)
        inDlyCy(2048*tStep-2)   ; half 2^12
        movff   bdat+11,LATB    ; b11 data        (1024T)
        inDlyCy(1024*tStep-2)   ; half 2^11
        movff   bdat+10,LATB    ; b10 data        (512T)
        inDlyCy(512*tStep-2)    ; half 2^10
        movff   bdat+09,LATB    ; b9 data         (256T)
        inDlyCy(256*tStep-2)    ; half 2^9
        movff   bdat+08,LATB    ; b8 data         (128T)
        inDlyCy(128*tStep-2)    ; half 2^8
        movff   bdat+07,LATB    ; b7 data         (64T)
        inDlyCy(64*tStep-2)     ; half 2^7
        movff   bdat+06,LATB    ; b6 data         (32T)
        inDlyCy(32*tStep-2)     ; half 2^6
        movff   bdat+05,LATB    ; b5 data         (16T)
        inDlyCy(16*tStep-2)     ; half 2^5
        movff   bdat+04,LATB    ; b4 data         (8T)
        inDlyCy(8*tStep-2)      ; half 2^4
        movff   bdat+03,LATB    ; b3 data         (4T)
        inDlyCy(4*tStep-2)      ; half 2^3
        movff   bdat+02,LATB    ; b2 data         (2T)
        inDlyCy(2*tStep-2)      ; half 2^2
        movff   bdat+01,LATB    ; b1 data         (1T)
        inDlyCy(1*tStep-2)      ; half 2^1 (0 delay)
        movff   bdat+00,LATB    ; b0 data         (1T)
        inDlyCy(1*tStep-2)      ; full 2^0 (0 delay)
        movff   bdat+01,LATB    ; b1 data         (1T)
        inDlyCy(1*tStep-2)      ; half 2^1 (0 delay)
        movff   bdat+02,LATB    ; b2 data         (2T)
        inDlyCy(2*tStep-2)      ; half 2^2
        movff   bdat+03,LATB    ; b3 data         (4T)
        inDlyCy(4*tStep-2)      ; half 2^3
        movff   bdat+04,LATB    ; b4 data         (8T)
        inDlyCy(8*tStep-2)      ; half 2^4
        movff   bdat+05,LATB    ; b5 data         (16T)
        inDlyCy(16*tStep-2)     ; half 2^5
        movff   bdat+06,LATB    ; b6 data         (32T)
        inDlyCy(32*tStep-2)     ; half 2^6
        movff   bdat+07,LATB    ; b7 data         (64T)
        inDlyCy(64*tStep-2)     ; half 2^7
        movff   bdat+08,LATB    ; b8 data         (128T)
        inDlyCy(128*tStep-2)    ; half 2^8
        movff   bdat+09,LATB    ; b9 data         (256T)
        inDlyCy(256*tStep-2)    ; half 2^9
        movff   bdat+10,LATB    ; b10 data        (512T)
        inDlyCy(512*tStep-2)    ; half 2^10
        movff   bdat+11,LATB    ; b11 data        (1024T)
        inDlyCy(1024*tStep-802) ; half 2^11
        rcall   prep            ; rebuild bdat array
        movff   btmp,LATB       ; b12 data        (2048T)
        retfie  FAST            ;
;

[Darrel Taylor]

Thanks for the Backup Mike.
It's nice to see somebody else gets the same numbers.

I'm making some progress with the "full-port" modification to MIBAM.

Actually doing the outputs is easy, just like you showed previously.
But I'm still having problems letting the user assign pins at random.

It's getting there, although a bit slower than anticipated.
<br>

[sanch0]

Thanks for the Backup Mike.
It's nice to see somebody else gets the same numbers.

I'm making some progress with the "full-port" modification to MIBAM.

Actually doing the outputs is easy, just like you showed previously.
But I'm still having problems letting the user assign pins at random.

It's getting there, although a bit slower than anticipated.
<br>

that's nice, but not so effective at all. interleaving could be used to get more channels at the same freq. and something else to get 100ns discretization.)))

[boroko]

Hi all,
I had a question that seems to have gotten lost in the fray....

I'm trying to use other interrupts in hardware functions while using MIBAM.
Specifically, a CCP HI/LO capture or USUART. the stand alone MIBAM examples work wonderfully, but when I try and incorporate a lo priority pulse capture or do comm, I run into problems. Is there a way to use incorporate the other ints and still use MIBAM? I have resorted to using a second PIC, but that isn't very elegant.

Thanks for thinking about it.
Bo

[Darrel Taylor]

Hi Bo,

If you're using an 18F, then sure ... you can have Low Priority interrupts running too. But I don't think you need interrupts for that stuff.

With MIBAM ... <strike>99.4%</strike> 94% of the processor time is un-used. It's just sitting around twiddling it's thumbs. (if it has any)

And since "capture's" retain the captured value for a while, they can easily be handled in the main loop by polling the CCPIF flag.

I've also run the USART at 250kbaud for DMX reception, again strictly polled in the main loop, while MIBAM runs in the background.

So much time ... so few things to do ... if only life were like that.
<br>

[boroko]

Thanks Darrel for the timely reply.

Yes, I'm using an 18F1320.
I guess that I was still thinking in terms of SPWM_INT where your available processor time was limited. I didn't realize that MIBAM left so much to play with.

I have been trying to get them combined and I have it to the point that the only errors that I get are 3x "Symbol not previously defined (_doBam)". I haven't gotten it to compile, so I may be way off anyway. Don't know.

I might try to better understand the magic static later, but for now,with your enlightenment, I'm going to change directions and just poll the flag.

"Not as smart as tomorrow, but smarter than yesterday!"

Thanks
Bo

[sanch0]

Hi Bo,

If you're using an 18F, then sure ... you can have Low Priority interrupts running too. But I don't think you need interrupts for that stuff.

With MIBAM ... <strike>99.4%</strike> 94% of the processor time is un-used. It's just sitting around twiddling it's thumbs. (if it has any)

And since "capture's" retain the captured value for a while, they can easily be handled in the main loop by polling the CCPIF flag.

I've also run the USART at 250kbaud for DMX reception, again strictly polled in the main loop, while MIBAM runs in the background.

So much time ... so few things to do ... if only life were like that.
<br>

This stuff would work for low-current balanced circuits or if don't need much accuracy and precision in result. Background? hmm.... If want get better results u should use HP Interrupts to minimize jitter and other timing errors. For 18F U should T2 Ints (or check and update timers everytime in HP ISR to avoid jitter). In more complicated designs parameters of switching element (or specialised driver) should be taken in to account. Sorrry for repeating what i've said earlier. P.S. Hope u wount blame be again, as the truth is far outhere) Best REGARDzzz.

[JimAvanti]

I notice this is an old thread (Starting in 2009 with the last post in 2011). I downloaded Darrel Taylor's BIBAM ver 1.1 and had it working great with a 16f690.
I am now trying it on a 18f14k22 and I can't get it working at all. From what I am reading it should work with the 18F's. I am trying to control 9 outputs (3 RGB LEDs). The 16f690 is too slow @8MHz

Does anyone know if there are any issues using this with the 18f14k22 or if there is an updated BIBAM available?
I am getting assembly errors when I try to compile: Symbol not previously defines (_VarIn), Missing arguments.

Jim

[Darrel Taylor]

Hi Jim,

It should work with the 14K22.

That error can only be generated by a BAM_PIN statement.

Make sure it looks something like this ...

BAM_PIN (PORTB,0, Duty1)

Note the comma between PORTB and 0.
Duty1 should be a BYTE var.

Make sure the designated pins are available.
The 14K22 only has RA0-RA5, RB4-RB7 and RC0-RC7

[JimAvanti]

Darrel,
I don't know what I did, but I got it to work. The code was working on the 16f690. The ports are the same on the 18f14k22 so that error should not have been there.

Anyway, I swiched to the 18f14k22 because I am trying to control 9 ports (3 RGB LEDs) and the Ramps up/down were not smooth at all on the 16f690. I was hoping the speed from 8MHz to 16MHz would fix the problem, but it didn't.

I just made a copy of the program and removed all the BIBAM code and replaced it with PWM statements (One for each of the 9 ports with a cycle of 1 and no pause). It works smooth and looks good, except the LED's are not quite as bright since they are actally taking turns being on, but they show no visible flicker.

If I could just get the BIBAM to work as smoothly. I must be doing something wrong. I am controling all 9 LED ports directly from the micro. I did try using transistors, but it made no difference.

I will keep trying, but I am running out of ideas.

Jim