Remove Text Formatting
Loading...

+ Reply to Thread
Page 2 of 4 FirstFirst 1234 LastLast
Results 41 to 80 of 151
  1. #41
    Join Date
    Mar 2009
    Posts
    19

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

  2. #42
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Quote Originally Posted by lanyong View Post
    last week, i send some thread. they r disappear, my god!
    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>
    DT

  3. #43
    Join Date
    Mar 2009
    Posts
    19

    Default Spam:)

    Quote Originally Posted by Darrel Taylor View Post
    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.

  4. #44
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    The blinking problem has been fixed.

    There is NO blinking at all with MIBAM.
    <br>
    DT

  5. #45
    Join Date
    Aug 2007
    Posts
    7

    Smile 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?

  6. #46
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Quote Originally Posted by Bronx68 View Post
    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.
    Welcome back!
    We've been busy while you were away
    I am using a 16F819. Will it run on this chip?
    Absolutely! (and most others too)

    Are you still looking for someone to do some testing?
    Definitely ... Test away.

    I've had good reports from others so far.
    Always looking for any problems though.

    Thanks!
    DT

  7. #47
    Join Date
    Mar 2009
    Posts
    19

    Default same question and same blink

    Quote Originally Posted by Darrel Taylor View Post
    The blinking problem has been fixed.

    There is NO blinking at all with MIBAM.
    <br>

    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.

  8. #48
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Quote Originally Posted by lanyong View Post
    when i do the same bam as u. blink as u,haha.
    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

  9. #49
    Join Date
    Mar 2009
    Posts
    19

    Default no

    Quote Originally Posted by Darrel Taylor View Post
    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>
    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 post and 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.

  10. #50
    pmfa061's Avatar
    pmfa061 Guest

    Default 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

  11. #51
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    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

  12. #52
    Join Date
    Sep 2007
    Location
    USA, CA
    Posts
    270

    Default

    BAM has been in public domain for over one year. That alone means it is not patentable.

  13. #53
    Join Date
    Nov 2004
    Posts
    61

    Default

    Quote Originally Posted by Darrel Taylor View Post
    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>
    ....... 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.

  14. #54
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Thumbs up

    Quote Originally Posted by JEC View Post
    ....... BAM was published by AL *specifically* to place the idea & implementation in the public domain and keep companies from patenting it.
    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

  15. #55
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    176

    Default

    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.

  16. #56
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    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

  17. #57
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    176

    Default

    Quote Originally Posted by Darrel Taylor View Post

    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'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)

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

    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

  18. #58
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Quote Originally Posted by Mike, K8LH View Post
    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)
    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".
    Code:
    Bit- 1  0    0  1
        |2T|1T|1T|2T|
    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).

    I'm excited enough to try and find a way.
    I think I know how now, but welcome any more thoughts.
    Just a matter of getting it done.

    Thanks,
    DT

  19. #59
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    176

    Default

    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>

    Last edited by Mike, K8LH; - 28th July 2009 at 02:34.

  20. #60
    Join Date
    Feb 2008
    Location
    Michigan, USA
    Posts
    194

    Default 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

  21. #61
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    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

  22. #62
    Join Date
    Aug 2009
    Posts
    16

    Default

    Quote Originally Posted by Darrel Taylor View Post
    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>
    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.(
    Attached Images Attached Images  

  23. #63
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    "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

  24. #64
    Join Date
    Nov 2007
    Location
    South-West of Australia. A small town called Denmark. 'Where the forest meets the sea.'
    Posts
    136

    Default 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

  25. #65
    Join Date
    Nov 2007
    Location
    South-West of Australia. A small town called Denmark. 'Where the forest meets the sea.'
    Posts
    136

    Default 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

  26. #66
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    I'm missing something? Brains?
    There are worse body parts to be missing.

    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

  27. #67
    Join Date
    Aug 2009
    Posts
    16

    Default

    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.

  28. #68
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    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

  29. #69
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    176

    Default

    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.

  30. #70
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Charlieplexed MIBAM now you're scaring me Mike.

    Still don't have the full-port version working yet.
    <br>
    DT

  31. #71
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    176

    Default

    Quote Originally Posted by Darrel Taylor View Post
    Charlieplexed MIBAM now you're scaring me Mike.

    Still don't have the full-port version working yet.
    <br>
    What do you mean "full-port version", Sir?

  32. #72
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Quote Originally Posted by Mike, K8LH View Post
    What do you mean "full-port version", Sir?
    Your previous contribution starting at post#55.
    <br>
    DT

  33. #73
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    176

    Default

    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

  34. #74
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Quote Originally Posted by Mike, K8LH View Post
    When I get something up-n'-runnin' I'll post a video and the assembly code, if anyone asks for it.
    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

  35. #75
    Join Date
    Aug 2009
    Posts
    16

    Default

    Quote Originally Posted by Darrel Taylor View Post
    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>
    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)

  36. #76
    Join Date
    Mar 2009
    Posts
    19

    Default

    Quote Originally Posted by sanch0 View Post
    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

  37. #77
    Join Date
    Mar 2009
    Posts
    19

    Default

    Quote Originally Posted by lanyong View Post
    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

  38. #78
    Join Date
    Aug 2009
    Posts
    16

    Default

    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.

  39. #79
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    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

  40. #80
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    2,525

    Default

    And Christ did not ask for anything. He was crucified though...

    Ioannis

Similar Threads

  1. decoding quadrature encoders
    By ice in forum mel PIC BASIC Pro
    Replies: 93
    Last Post: - 28th February 2017, 09:02
  2. Cordic trig assembly code for PIC18f
    By ScaleRobotics in forum mel PIC BASIC Pro
    Replies: 55
    Last Post: - 8th September 2015, 05:36
  3. AT/PS2 Keybord - PIC Interface?
    By Kamikaze47 in forum Code Examples
    Replies: 73
    Last Post: - 9th August 2009, 16:10
  4. MIBAM - (Mirror Imaged Bit Angle Modulation)
    By Darrel Taylor in forum Code Examples
    Replies: 2
    Last Post: - 15th February 2009, 16:02
  5. Bit Angle Modulation
    By BH_epuk in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 18th November 2008, 07:01

Members who have read this thread : 3

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts