Smooth LED fading via PWM

[HankMcSpank]

so I'm running out of program memory, I'm presently using the subroutine below to lookup a counter value (count1 below) to get a preset hpwm value (duty)....

Smooth_fade:    
Lookup count1, [ _
  0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, _
  1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3, _
  3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,5,5,5, _
  5,5,5,5,5,6,6,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8,8,8,9,9, _
  9,9,10,10,10,10,10,11,11,11,11,12,12,12,13,13,13,13, _
  14,14,14,15,15,15,16,16,16,17,17,18,18,18,19,19,20,  _
  20,20,21,21,22,22,23,23,24,24,25,26,26,27,27,28,29,  _
  29,30,31,31,32,33,33,34,35,36,36,37,38,39,40,41,42,  _
  42,43,44,45,46,47,48,50,51,52,53,54,55,57,58,59,60,  _
  62,63,64,66,67,69,70,72,74,75,77,79,80,82,84,86,88,  _
  90,91,94,96,98,100,102,104,107,109,111,114,116,119,  _
  122,124,127,130,133,136,139,142,145,148,151,155,158, _
  161,165,169,172,176,180,184,188,192,196,201,205,210, _
  214,219,224,229,234,239,244,250,255], duty
  return

,....now since I've not much program space left , is there any way I can win some room back by for example stuffing the above 256 bytes into EEPROM and then look up the values similar to above? (EEPROM is a bit of a new area to me...I've never had to bother with it before!)

If so....would you be so helpful to put me on the right track? (I'm figuring the 256 bytes will need writing into the PIC at the time of programming it & from thereon afterwards it can be read from EEPROM while the program is running?)

[HenrikOlsson]

Hi Hank,
You use DATA to store the constants to EEPROM at program time. Then you use READ to retreive them at runtime. Something like:

Data 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, _
  1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3, _
  3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,5,5,5, _
  5,5,5,5,5,6,6,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8,8,8,9,9, _
  9,9,10,10,10,10,10,11,11,11,11,12,12,12,13,13,13,13, _
  14,14,14,15,15,15,16,16,16,17,17,18,18,18,19,19,20,  _
  20,20,21,21,22,22,23,23,24,24,25,26,26,27,27,28,29,  _
  29,30,31,31,32,33,33,34,35,36,36,37,38,39,40,41,42,  _
  42,43,44,45,46,47,48,50,51,52,53,54,55,57,58,59,60,  _
  62,63,64,66,67,69,70,72,74,75,77,79,80,82,84,86,88,  _
  90,91,94,96,98,100,102,104,107,109,111,114,116,119,  _
  122,124,127,130,133,136,139,142,145,148,151,155,158, _
  161,165,169,172,176,180,184,188,192,196,201,205,210, _
  214,219,224,229,234,239,244,250,255
 
Smooth_fade:
  Read Count1, duty

/Henrik.

[HankMcSpank]

Hi Henrik,

Great, many thanks ....simple enough & it works a treat!

Weirdly even though I imported all those values to Excel to check there are 256 entries (there are) - I got an error when I came to compile (stack overflow)....I took one entry out & then it compiled ok. Hey ho....but I just got rid of one of the multitude of 1s in there.

Many thanks....I've a bit more room to "breathe" in my bloaty program again

[HankMcSpank]

For this specifically LED it might work and as long as the voltage is absolutely stable.

But I insist on using a current source. You will be able to control the brightness for a really 0 to 100%.

Even for a test it is interesting.

I have a client that for more than a year is refering to his power (chinese) LEDs as 24Volts... And I reply with the current of your LEDs is....

Ioannis

If my calculations are right, when sinking current, my 16f1828 is working out at about 52 Ohms of series resistance per pin - now whether the resistance comes by way of a resistor, or the resistive properties of the silicon inside the PIC IO driving circuitry...resistance is resistance?

V Supply = 3.268V
V drop measured across blue LED = 2.931V
remianing V drop across PIC pin = 3.268V-2.931V = 0.337V
Current through LED (inferred by measuring current into whole circuit - 11 LEDS - then taking a little off (3mA for the PIC) & dividing by 11 = 6.4mA

Resistance of PIC pin R = V/I =....or 0.337V/0.0064A = 52.65 Ohms.

So why not simply treat the PIC's pin as a series 52 ohm resistor for the purposes of LED current calculations? (ie what am I missing?)

[HankMcSpank]

So if I want to store a (ser defined) setting that will remembered after the battery/power source has been removed from the PIC ..is EEPROM is my only option?

If so, I have a problemette...I presently have 256 bytes that already goes into EEPROM at program time..

Data 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, _
  1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3, _
  3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,5,5,5, _
  5,5,5,5,5,6,6,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8,8,8,9,9, _
  9,9,10,10,10,10,10,11,11,11,11,12,12,12,13,13,13,13, _
  14,14,14,15,15,15,16,16,16,17,17,18,18,18,19,19,20,  _
  20,20,21,21,22,22,23,23,24,24,25,26,26,27,27,28,29,  _
  29,30,31,31,32,33,33,34,35,36,36,37,38,39,40,41,42,  _
  42,43,44,45,46,47,48,50,51,52,53,54,55,57,58,59,60,  _
  62,63,64,66,67,69,70,72,74,75,77,79,80,82,84,86,88,  _
  90,91,94,96,98,100,102,104,107,109,111,114,116,119,  _
  122,124,127,130,133,136,139,142,145,148,151,155,158, _
  161,165,169,172,176,180,184,188,192,196,201,205,210, _
  214,219,224,229,234,239,244,250,255

ok, my first problem is, there's 256 bytes there...which maxes my EEPROM out. (16F1828)

Now assuming i have no other way of storing a user chosen varaiable after the power has been removed (other than EEPROM), THEN I suppose I will need to forsake one of the 256 bytes in that table above ...therefore 255 bytes + 1 byte that the user chooses (& gets stored away when he presses a switch).

But how do I control all of this. In other words if I trim the above from 256 bytes, to 255 bytes to free up one byte of EEPROM space, then the 255 bytes will go straight into EEPROM as it does now ....but how do I store the remaining (user defined) byte in the last available slot of EEPROM?

Sorry for n00by flavour here...but a prolific search didn't yield much that I can digest/apply to this conundrum.

[cncmachineguy]

Hank do you have any code space left?

[HankMcSpank]

Hi Bert,

Yes, it's getting tight, but about 400 bytes left....

[SteveB]

How about something like this:

Data 1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3, _
  3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,5,5,5, _
  5,5,5,5,5,6,6,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8,8,8,9,9, _
  9,9,10,10,10,10,10,11,11,11,11,12,12,12,13,13,13,13, _
  14,14,14,15,15,15,16,16,16,17,17,18,18,18,19,19,20,  _
  20,20,21,21,22,22,23,23,24,24,25,26,26,27,27,28,29,  _
  29,30,31,31,32,33,33,34,35,36,36,37,38,39,40,41,42,  _
  42,43,44,45,46,47,48,50,51,52,53,54,55,57,58,59,60,  _
  62,63,64,66,67,69,70,72,74,75,77,79,80,82,84,86,88,  _
  90,91,94,96,98,100,102,104,107,109,111,114,116,119,  _
  122,124,127,130,133,136,139,142,145,148,151,155,158, _
  161,165,169,172,176,180,184,188,192,196,201,205,210, _
  214,219,224,229,234,239,244,250,255
 
Smooth_fade:
    IF Count1 = 0 THEN 
         duty = 0
    ELSE
         IF Count1 < 26 THEN 
             duty = 1
         ELSE
             Read Count1-25, duty
         ENDIF
    ENDIF
    RETURN

WriteUserByte:
    WRITE 255, UserByte
    RETURN

ReadUserByte:
    READ 255, UserByte
    RETURN

Now you have the upper 25 EEPROM addresses to use. More space could be saved by using similar logic. But this hopefully gets the point across.

Good luck,
Steve

[SteveB]

My math was a little off, the line for the reading of the EEPROM should be

READ count1-26, duty

As a side note, you could make it really simple just by leaving the original table as-is and using this:

Smooth_fade: 
     IF Count1 = 0 THEN 
          duty = 0 
     ELSE 
          Read Count1, duty 
     ENDIF
RETURN

WriteUserByte: 
     WRITE 0, UserByte 
     RETURN

ReadUserByte: 
     READ 0, UserByte 
     RETURN

[HankMcSpank]

Bert.. re putting my table into program memory....it's still a work in progress and with only 400 bytes left...it only takes a couple of debug commands and I'm over the limit :-(

Byte_Butcher ...that's a good lead!

SteveB..... if I'm reading your code right, it's what Byte_butcher proposed? (& is good clawback of EEPROM)

I'll have a dabble later....many thanks for the input.

[SteveB]

SteveB..... if I'm reading your code right, it's what Byte_butcher proposed? (& is good clawback of EEPROM)

Yes, I took the suggestion from Byte_Butcher and fleshed it out a little.

[Byte_Butcher]

I've gotta go stack wood, so this is quickk and needs fixing, but this is the sort of thing I was thinking:

count = count + 1

If count < 33 then address = 1                   'all "counts" less than 33 point to address 1 
        if count < 1 then 
        address = 0                                     'unless count is 0. Then it points to address 0
        endif
        else address = count - 33                     'all counts above 33 get offset down so they pick up the sequence starting at address 2
endif

steve

edited to add:

Never mind, Steve B already did it.