|
bam is ok
u will let it to 2.45kHz. the led will be not blink. i have test it.
last week, i send some thread. they r disappear, my god!
mbam will not solve the blink problem absolutely. from 127 to 128 change so much the same.
the best way is let more interrupt. and let the bit7 or bit6 or bit5 or bit4's time average in the period.
Last edited by lanyong; - 28th March 2009 at 14:21.
|
My fault. Your posts looked like SPAM.Originally Posted by lanyong
Copied half the thread in a quote and added 1 sentance with a link. (4 times)
My bad.
<br>
DT
|
Spam:)
My fault. Your posts looked like SPAM.
Copied half the thread in a quote and added 1 sentance with a link. (4 times)
My bad.
<br>
it is seemd that my english is so poor.
the bam's question is that when the period is so long, from one to 2^n change so much.such as from 1 to 2, 3->4, 7->8, 15->16, 31->32,63->64, 127->128.
so u will watch the led blink.
|
|
Testing your code
Darrel,
I started this link when I was working on an RGB backlight. I have been away from this task for quite some time but plan to get back into next month.
You mentioned that you are willing to let someone test out your code. I am using a 16F819. Will it run on this chip? Are you still looking for someone to do some testing?
|
Welcome back!
We've been busy while you were away
Absolutely! (and most others too)I am using a 16F819. Will it run on this chip?
Definitely ... Test away.Are you still looking for someone to do some testing?
I've had good reports from others so far.
Always looking for any problems though.
Thanks!
DT
|
same question and same blink
when i do the same bam as u. blink as u,haha.
i find ur post, it is very interesting.
in fact u let the bam is high, such as 2.4kHz, u will not watch the blink ,same.
|
Really? That's odd.
Which PIC are you using?
What OSC frequency, and how many LED's?
Are you assembling with MPASM or PM?
Did the program give you any warnings or errors?
<br>
DT
|
no
ten days ago. i try the bam, find from 127 to 128, the led blink.100Hz, 8bit.
i know it is change so much. so i find ur postand i send some post to urs.
last week, i let it to 2.4kHz, bam. the led will not blink.
i don't test ur mibam, i think it is good.
i use pic18, and 48 dmx512 channel. 2.4kHz bam 8 bit.
|
patents and royalty fees for BAM
I'm not sure this is the right place to ask, but I was wondering if BAM is a patented technique (e.g. by Artistic License or any other company) and hence commercial use of BAM requires fees to be paid, or if it just like PWM a technique that can be freely implemented in any device.
10x in advance for any info
|
Artistic License claims to have "Invented" BAM. But nowhere have I found a claim that they have received or even applied for a patent.
Although I have found a dozen or so patents that would probably keep A.L. from getting one if they tried.
Not that it would matter very much, because this is not BAM.
BAM is flawed, and MIBAM represents a "Significant Improvement".
<br>
DT
|
BAM has been in public domain for over one year. That alone means it is not patentable.
|
....... BAM was published by AL *specifically* to place the idea & implementation in the public domain and keep companies from patenting it.
Partly because there's been some ugliness in the professional lighting / theatre world by companies patenting (and then aggressively litigating) LED dimming and control techniques. These techniques have been obvious to those skilled in the trade since at least the 1970s, but the patents were granted nonetheless.
|
Excellent move by Artistic License.
Hopefully, by finding the Mirror Image improvement to BAM and releasing it to the public domain ...
RadikalQ3 and I have made it impossible for some squatter to patent a MIBAM equivalent too.
MIBAM - (Mirror Imaged Bit Angle Modulation)
http://www.picbasic.co.uk/forum/showthread.php?t=10564
<br>
DT
|
Hi Darrel,
May I pass along my late congrats' on some brilliant work and share a couple ideas?
Instead of using six instructions (6 cycles) per LED during each update interval you might consider updating one port at a time using an exclusive-or instruction (2 cycles) and data from an eight byte "toggle" array that's refreshed during that long 64T end-of-period interval. This reduces overhead from 288 cycles for 48 LEDs to just 12 cycles during each update interval. Using "toggle" data and an exclusive-or instruction lets us update MIBAM output bits without changing non-MIBAM bits on each port.
Since the three '1T' intervals seem to be a major bottleneck we might consider combining the center |2T|1T|1T|1T|2T| intervals into a single '7T' interval and use small in-line isochronous delays to effect precise timing between updates. This would practically eliminate "overhead" effects on the center three '1T' intervals.
Here's a pseudo C code driver example (sorry, I don't have PBP). I'm sure you realize that the "switch" function should be replaced with assembly language to reduce overhead and eliminate jitter and that the LEDs and "data benders" should probably be setup as macros as you did in your driver.
An assembly language version I wrote supports 48 LEDs at decent refresh rates at almost any clock (4-MHz, 177 Hz, 1T = 22-usecs).
Food for thought. Kind regards, Mike, K8LH
Code:unsigned char interval = 0; // ISR state machine var' unsigned char red = 44; unsigned char grn = 55; unsigned char blu = 66; volatile unsigned short ccpr1 @ 0xFBE; /* * * original intervals -> |64|32|16|8|4|2|1|1|1|2|4|8|16|32|64| * * modified intervals -> |64|32|16|8|4|----7----|4|8|16|32|64| * * */ void interrupt() // CCP1 "special event" interrupts { unsigned char Adat[8]; // porta "toggle" array unsigned char Bdat[8]; // portb "toggle" array pir1.CCP1IF = 0; // clear CCP1 interrupt flag switch(interval++) // { case 0: // 64T porta ^= Adat[7]; // portb ^= Bdat[7]; // ccpr1 = (64*tStep); // ccpr1 = half 2^7 (64T) break; // case 1: // 32T porta ^= Adat[6]; // portb ^= Bdat[6]; // ccpr1 >>= 1; // ccpr1 = half 2^6 (32T) break; // case 2: // 16T porta ^= Adat[5]; // portb ^= Bdat[5]; // ccpr1 >>= 1; // ccpr1 = half 2^5 (16T) break; // case 3: // 8T porta ^= Adat[4]; // portb ^= Bdat[4]; // ccpr1 >>= 1; // ccpr1 = half 2^4 (8T) break; // case 4: // 4T porta ^= Adat[3]; // portb ^= Bdat[3]; // ccpr1 >>= 1; // ccpr1 = half 2^3 (4T) break; // case 5: // 7T (2T+1T+1T+1T+2T) porta ^= Adat[2]; // portb ^= Bdat[2]; // ccpr1 = (7*tStep); // ccpr1 = 7*tStep (7T) delayCy(2*tStep-8); // 2T minus 8 cycles porta ^= Adat[1]; // portb ^= Bdat[1]; // delayCy(1*tStep-4); // 1T minus 4 cycles porta ^= Adat[0]; // portb ^= Bdat[0]; // delayCy(1*tStep-4); // 1T minus 4 cycles porta ^= Adat[0]; // portb ^= Bdat[0]; // delayCy(1*tStep-4); // 1T minus 4 cycles porta ^= Adat[1]; // portb ^= Bdat[1]; // break; // case 6: // 4T porta ^= Adat[2]; // portb ^= Bdat[2]; // ccpr1 = (4*tStep); // ccpr1 = half 2^3 (4T) break; // case 7: // 8T porta ^= Adat[3]; // portb ^= Bdat[3]; // ccpr1 <<= 1; // ccpr1 = half 2^4 (8T) break; // case 8: // 16T porta ^= Adat[4]; // portb ^= Bdat[4]; // ccpr1 <<= 1; // ccpr1 = half 2^5 (16T) break; // case 9: // 32T porta ^= Adat[5]; // portb ^= Bdat[5]; // ccpr1 <<= 1; // ccpr1 = half 2^6 (32T) break; // case 10: // 64T (end-of-period) porta ^= Adat[6]; // portb ^= Bdat[6]; // ccpr1 <<= 1; // ccpr1 = half 2^7 (64T) interval = 0; // prep for new period Adat[0] = 0; Adat[1] = 0; // clear Adat[] array Adat[2] = 0; Adat[3] = 0; // Adat[4] = 0; Adat[5] = 0; // Adat[6] = 0; Adat[7] = 0; // Bdat[0] = 0; Bdat[1] = 0; // clear Bdat[] array Bdat[2] = 0; Bdat[3] = 0; // Bdat[4] = 0; Bdat[5] = 0; // Bdat[6] = 0; Bdat[7] = 0; // /* * * use one "data bender" for each LED (16 cycles each) * * */ if(red.0) Bdat[0] |= 1; // 2^0 data RB0 pin if(red.1) Bdat[1] |= 1; // 2^1 data RB0 pin if(red.2) Bdat[2] |= 1; // 2^2 data RB0 pin if(red.3) Bdat[3] |= 1; // 2^3 data RB0 pin if(red.4) Bdat[4] |= 1; // 2^4 data RB0 pin if(red.5) Bdat[5] |= 1; // 2^5 data RB0 pin if(red.6) Bdat[6] |= 1; // 2^6 data RB0 pin if(red.7) Bdat[7] |= 1; // 2^7 data RB0 pin if(grn.0) Bdat[0] |= 2; // 2^0 data RB1 pin if(grn.1) Bdat[1] |= 2; // 2^1 data RB1 pin if(grn.2) Bdat[2] |= 2; // 2^2 data RB1 pin if(grn.3) Bdat[3] |= 2; // 2^3 data RB1 pin if(grn.4) Bdat[4] |= 2; // 2^4 data RB1 pin if(grn.5) Bdat[5] |= 2; // 2^5 data RB1 pin if(grn.6) Bdat[6] |= 2; // 2^6 data RB1 pin if(grn.7) Bdat[7] |= 2; // 2^7 data RB1 pin if(blu.0) Bdat[0] |= 4; // 2^0 data RB2 pin if(blu.1) Bdat[1] |= 4; // 2^1 data RB2 pin if(blu.2) Bdat[2] |= 4; // 2^2 data RB2 pin if(blu.3) Bdat[3] |= 4; // 2^3 data RB2 pin if(blu.4) Bdat[4] |= 4; // 2^4 data RB2 pin if(blu.5) Bdat[5] |= 4; // 2^5 data RB2 pin if(blu.6) Bdat[6] |= 4; // 2^6 data RB2 pin if(blu.7) Bdat[7] |= 4; // 2^7 data RB2 pin /* * * convert Bdat[] and Adat[] array "output" data to "toggle" data * * * * red 0x2C 00101100 (on RB0) * * grn 0x37 00110111 (on RB1) * * blu 0x42 01000010 (on RB2) * * * * Bdat 'output data' Bdat 'toggle data' Bdat 'toggle data' * * [0] 0x02 00000010 [0] 0x04 00000100 [0] 0x04 00000100 * * [1] 0x06 00000110 [1] 0x05 00000101 [1] 0x05 00000101 * * [2] 0x03 00000011 [2] 0x02 00000010 [2] 0x02 00000010 * * [3] 0x01 00000001 [3] 0x03 00000011 [3] 0x03 00000011 * * [4] 0x02 00000010 [4] 0x01 00000001 [4] 0x01 00000001 * * [5] 0x03 00000011 [5] 0x07 00000111 [5] 0x07 00000111 * * [6] 0x04 00000100 [6] 0x04 00000100 [6] 0x04 00000100 * * [7] 0x00 00000000 [7] 0x00 00000000 [7] 0x01 00000001 * * portb 0x00 00000000 portb 0x01 00000001 * * */ asm { movf _porta,W // get current PORTA bits andlw 0 // keep only MIBAM output bits xorwf _Adat+7,F // create 2^7 toggle bits xorwf _Adat+7,W // W simulates cumulative PORTA xorwf _Adat+6,F // create 2^6 toggle bits xorwf _Adat+6,W // xorwf _Adat+5,F // create 2^5 toggle bits xorwf _Adat+5,W // xorwf _Adat+4,F // create 2^4 toggle bits xorwf _Adat+4,W // xorwf _Adat+3,F // create 2^3 toggle bits xorwf _Adat+3,W // xorwf _Adat+2,F // create 2^2 toggle bits xorwf _Adat+2,W // xorwf _Adat+1,F // create 2^1 toggle bits xorwf _Adat+1,W // xorwf _Adat+0,F // create 2^0 toggle bits movf _portb,W // get current PORTB bits andlw 7 // keep only MIBAM output bits xorwf _Bdat+7,F // create 2^7 toggle bits xorwf _Bdat+7,W // W simulates cumulative PORTB xorwf _Bdat+6,F // create 2^6 toggle bits xorwf _Bdat+6,W // xorwf _Bdat+5,F // create 2^5 toggle bits xorwf _Bdat+5,W // xorwf _Bdat+4,F // create 2^4 toggle bits xorwf _Bdat+4,W // xorwf _Bdat+3,F // create 2^3 toggle bits xorwf _Bdat+3,W // xorwf _Bdat+2,F // create 2^2 toggle bits xorwf _Bdat+2,W // xorwf _Bdat+1,F // create 2^1 toggle bits xorwf _Bdat+1,W // xorwf _Bdat+0,F // create 2^0 toggle bits } break; // } }
Last edited by Mike, K8LH; - 26th July 2009 at 14:01.
|
WooHoo! Somebody's paying attention.
Hi Mike,
That's a VERY interesting idea!
Not sure at this point how I can let the user assign the pins at random, in any order, and any number of them, on any chip. But this sounds good enough to see if I can find a way.
For combining the smallest periods ... I already add the lsb from each side of the "mirror" into a single period to double the minimum interrupt time. Not sure where your 3rd one comes from. That would make the lsb worth 1.5.
I had also tried combining the 2 lsb's on both sides, but that reduced the resolution to 7-bit instead of 8, so the results weren't very good.
I'll see what I can do with the "Full PORT Press".
Thanks for the great idea.
Add: Hmmm, that would help minimze R-M-W issues too.
<br>
Last edited by Darrel Taylor; - 26th July 2009 at 16:56. Reason: RMW
DT
|
I'm not sure I follow you here. The duty cycle b0 bit output is still 1T long smack in the middle and the b1 bit still generates two 1T outputs on either side of the b0 1T output so we're not losing any resolution. I've just combined those |2T|1T|1T|1T|2T| outputs into a single 7T interval so that our minimum ISR interval is now 4T instead of 1T which gives us more headroom and much higher refresh intervals (even with the overhead of full ISR context save/restore)
I'm not exactly sure how to do it either and then we would still need to dynamically come up with Amask, Bmask, Cmask constants or variables for each port output-to-toggle routine but like you, I'm excited enough to try and find a way.Not sure at this point how I can let the user assign the pins at random, in any order, and any number of them, on any chip. But this sounds good enough to see if I can find a way.
With the new smaller 4T minimum ISR interval my assembly language test driver can achieve Kilohertz range refresh rates with some of the higher clock frequencies, though I'm not sure if that's really useful (grin).
Kind regards, Mike, K8LH
|
By combining those periods, you can't switch the LED for bit0, because it's combined in with bit1. That's what drops it down to 7-bit resolution. If it were a single output, you could combine them, but with multiple LED's, bit0 has to remain separate from bit1.
With MIBAM, it looks like this, with the red line being the "mirror".The 1T's on either side can be combined into a single period equal to 2T, but they can't be combined with the bit1 (2T's).Code:Bit- 1 0 0 1 |2T|1T|1T|2T|
I think I know how now, but welcome any more thoughts.I'm excited enough to try and find a way.
Just a matter of getting it done.
Thanks,
DT
|
Hi Darrel,
I think we may be confusing each other with terminology and perhaps a slight difference in our design. I was using "1T" as the PWM step size. For example, if we were to use a step size of 10-usecs and 256 steps or levels then we'd have a 2560-usec period (256*10-usecs). The b0 output is 10-usecs or 1T long. The b1 output is 20-usecs or 2T long but I split it in half with 10-usecs or 1T on either side of the b0 10-usec (1T) output. That's how I get |2T|1T|1T|1T|2T| == |20us|10us|10us|10us|20us| == |half b2|half b1|full b0|half b1|half b2|. I thought this was how you were doing it but now I suspect I didn't look closely enough at your code and I apologize.
It also seems you think I'm combining the b2, b1, and b0 outputs and reducing resolution but I'm not. I'm simply generating the b2, b1, and b0 outputs during a single interrupt interval.
More later... I'm trying to see if I can upgrade a very old 12F683 Charlieplexed 5-pin 20-LED project from 64 levels per LED to 256 levels per LED using MIBAM. Wish me luck...
Kind regards, Mike
<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/AgQTBKcg2D4&color1=0xb1b1b1&color2=0xcfcfcf&hl=en& feature=player_embedded&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowScriptAccess" value="always"></param><embed src="http://www.youtube.com/v/AgQTBKcg2D4&color1=0xb1b1b1&color2=0xcfcfcf&hl=en& feature=player_embedded&fs=1" type="application/x-shockwave-flash" allowfullscreen="true" allowScriptAccess="always" width="425" height="344"></embed></object>
.PNG)
Last edited by Mike, K8LH; - 28th July 2009 at 02:34.
|
Is it possible to combine MIBAM and DT_INTS?
Is it possible to combine MIBAM and DT_INTS?
I am attempting to use MIBAM in a program where I have been using SPWM_INT. I understand that MIBAM need exclusive use of TMR1 and HI priority INTs. The thought was to see if I could still use DT_INTs to handle low priority ints for a pulse time capture and a HSER routine. I still have to play with it to decide if I can make them function with the probability of MIBAM cutting off the other two, but that is a separate problem.
The issue that I see is that DT_INTS has:
"DEFINE INTHAND INT_ENTRY_H"
"DEFINE INTLHAND INT_ENTRY_L"
and MIBAM has:
"DEFINE INTHAND doBAM"
Can the doBAM section be added to the INT_ENTRY_h section and eliminate the "DEFINE INTHAND doBAM"? If so how?
Until I understand this better, I'm going to continue with the SPWM_INT version of the code and work on finishing the rest of the code that way. I may not need the advantages of MIBAM, but it sure is a cool routine. Even with my limited coding ability, DT's routines have multiplied my capabilities tremendously. Thank you Darrel and all the others that have put in the effort and patience and have been willing to share your wisdom so freely.
Bo
|
Since MIBAM uses a completely ASM interrupt handler, it would be much easier to make it compatible with DT_INTS instead of the other way around.
However, if you're just measuring pulse widths ... the use of Timer3 and a CCP module (Capture mode) might be more applicable. And you won't need Interrupts for that, although they can still be used with LOW Priority. It'll be more accurate with the CCP too.
The HIGH Priority interrupts will affect the "Timing" of LOW Priority ints.
The resolution of a Pulse measurement using LP ints (without CCP) will always suffer.
<br>
DT
|
what means "LP ints"? Are u talking about jitter problem? U should update T0 then (for example) in every interrupt to avoid that. If u going to use CCP with prescalers/postscalers then will get jitter error too.
What refresh rates and bit resolutions have u achieved?
p.s. very nice aproach, congratulations. and sorry 4 poor english.(
|
"LP ints" means Low Priority Interrupts on an 18F.
High Priority Interrupts can interrupt Low Priority Interrupts.
So trying to measure times exactly with Low Priority interrupts will not give very good results unless you are using hardware peripherals, like the CCP module.
<br>
DT
|
Mybam
DT
I'm sorry to ask a basic question when this development/discussion is well under way.
I don't see why one PWM output needs 256 interrupts per cycle? I would have thought only one was needed - at the appropriate time in the cycle?
I'm missing something here - probably brains!
Regards Bill Legge
|
Mybam
DT
Sorry to ask a basic question when the discussion is well advanced.
I don't see why 256 interrupts are needed for one PWM signal? I would have thought that one interrupt - at the appropriate time - in the cycle would do the trick?
I'm missing something? Brains?
Regards Bill Legge
|
There are worse body parts to be missing.I'm missing something? Brains?
You're correct.
For one PWM signal, all you need is 2 interrupts. One to turn it ON, and a second to turn it off.
It's when you have multiple PWM signals that you need to be able to turn any one of the channels OFF, at any one of the 255 time periods. So you need all thoses interrupts for every cycle. Even though nothing happens on 99% of them.
But again, blinky BAM only needs 8, and MIBAM uses 16 (doubled for the mirror image).
<br>
DT
|
What _maximum_ refresh rates and bit resolutions have u achieved? I have developed many devices with 18F working at 10 MIPS and giving 13 bit ~610Hz (14 bit is maximum at this speed IMHO). I use ASM.
|
sanch0,
I'm not sure what you're talking about ... but I don't think it's BAM.
At 610hz with 13-bit resolution, the minimum bit period would be 0.2uS
Not even an 18F running at 40Mhz could do anything with 2 instructions.
<br>
DT
|
Actually, you could do it with just 2 instructions per update (using 18F and 40-MHz clock) but it would require a blanking interval of sorts at end-of-period or at some other point in time to update/refresh duty cycle values. In this particular case it would actually be easier to implement with BAM or MIBAM compared to the more traditional PWM methods.
As a side note. I think I have a method for using MIBAM modulation on that little 20-LED charlieplexed array. The refresh rate works out to a whopping 520-Hz per LED which would allow you to fade each individual LED from black to full to black (511 steps) in less than a second. The 520-Hz per LED (or per column) rate is achieved by using a 1.5-usec step or an overall refresh rate of 2600-Hz (with a 1920-usec frame rate). Man I'm good (LOL). Seriously though, this model or method suggests that we could achieve a very respectable refresh rate even with a standard mux'd 8x8 matrix.
Mike
Last edited by Mike, K8LH; - 9th August 2009 at 13:53.
|
Charlieplexed MIBAMnow you're scaring me Mike.
Still don't have the full-port version working yet.
<br>
DT
|
What do you mean "full-port version", Sir?Charlieplexed MIBAM
Still don't have the full-port version working yet.
<br>
|
Your previous contribution starting at post#55.
<br>
DT
|
Sorry, I misunderstood.
I coded the full-port-at-a-time method driver in assembly language as part of a 16F886 project and will test it on a prototype board sometime soon.
I also coded the Charlieplexed 20-LED MIBAM driver in an assembly language project for a 16F886 host.
Both projects simply have variables and the ISR driver setup for simulation so they're far from complete demos'. When I get something up-n'-runnin' I'll post a video and the assembly code, if anyone asks for it.
Regards, Mike, K8LH
|
OK, so let me go ahead and take care of that part ...
Hey Mike,
When you get it all working, could you post the code ... and maybe show a video of it in action?
It'll help me figure out how to do it in PicBasic Pro.
DT
|
Maximum gained speed of modulation (whatever way u make it) is only limited by speed You can change output. Normally it's 2 instruction. But U can make it in single instruction also, just clearing the output if previous port stage is known. Of course it's only could be done in ASM. Blanking period - the only problem exist here. It will limit maximum duty cycle for some value, depending number of ports needed. I have many devices working at 610hz with 13-bit resolution. Tryed several different ways to get this. Not used MIBAM yet)
|
how to do it?
pls post the code.
bam is possible, we can change the H or L in two clocks in pic18. so 10M/(2^13)/2=1220.703125/2=610.3515625
|
i have 8 group i/o and get the 2450.98Hz 8 bit bam equl to 1 i/o:2450.98*8/(2^13/2^8)=610Hz.
the min time is 0.2us to change the i/o's voltage
|
I have working code for 14bit 610hz BAM with 16 output PWM channels (code could be updated to get more channels with external logic if needed), but i didn't tried to resolve flicker problem with BAM yet. I think that simple signal mirroring doesn't help to fully avoid flicker(s), it just makes it significantly lower, but maybe also affects visual perception of signal "decreasing" actual refresh rate. And there are other ways to avoid flicker trouble, too. However, MIBAM is very good approach, thanx to it's simplicity in combination with reasonable effectivity. Thank You, Darrel Taylor & RadikalQ3 for giving good explanations and usefull thoughts. Btw, additional advantage of MIBAM method is that it might slightly reduce level of generated EMI.
Last edited by sanch0; - 18th August 2009 at 02:03.
|
It's amazing how many people have come here to tell me that the Mirror Image won't fix BAM's blinking problem.
With the mirror image, there is absolutely NO blinking AT ALL. (Not even with a video camera).
Of course everyone admits that they've never even tried it.
But yet they still feel it's ok to tell the world that it won't work.
All I can do is return the favor ...
16 channel, 14-bit BAM, at 610hz, with a PIC, is IMPOSSIBLE.
It was bad enough when you said 13-bit. But now with 14-bits, the minimum period would be 0.1 µS. There's NO WAY you can set 16 outputs to the desired states with only one instruction, then set them all to new states on the very next instruction.
But then ... "I've never tried it".
<br>
DT
|
Members who have read this thread : 2You do not have permission to view the list of names.
Posting Permissions
Bookmarks