Smooth LED fading via PWM

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

[HankMcSpank]

IS there a rapido way of seeing the whole contents of EEPROM?

I'm storing a user determined byte, using this type of way..

DEFAULT_CONFIG  DATA 1
default_config_shadow var byte

default_config_shadow = 101010              '
WRITE default_config_shadow, default_config   'write the above to EEPROM

read default_config, default_config_shadow

DEBUG "def_shadow=",BIN default_config_shadow,13,10

then immdeiately afterwards, I lob another 254 bytes into EEprom too...

data   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

just wondering how that all gets accounted for in EEprom, because I'm sure there's going to be some impact with the way I read that table type data back (eg is my user defined bye stored in EEPROM memory slot0, with the rest filling sequentially afterwards?) I was previously using a counter variable to look up/reference the the data stored in EEprom, but now I'm wondering if I need to offset it by 1? (due to the user stored byte in Eeprom too ....or can I store the one user defined byte at the end of the EEPRM...the last slot)


can I look at EEprom via the Pickit2 (I had a dabble but it wasn't obvious to read!)

Many thanks.

[HenrikOlsson]

Hi Hank,
First off all, it seems as if your WRITE statement is "reversed", you should do WRITE Adress, Value but to me it seems you have it the other way around, ie. writing whatever is in default_config to adress 42 (101010) when I think you actually want the value 42 written to adress 0, or 1 perhaps.

Second, I think (pretty sure) you should be able to read the EEPROM with the PICKit2, I only have a PK3 but if you can't figure it out I'll have a go later. With that said you could dump the EEPROM content over a serial line (if you have one) with something like:

Count VAR BYTE
Result VAR BYTE

For Count = 0 to 255
  Read Count, Result
  HSEROUT ["EEPROM Location: ", DEC3 Count, ": ", DEC RESULT,13]
NEXT

Third, if the first location in EEPROM (location 0) is reserved for that "userbyte" of data then you should start your DATA table with something like DATA @1, 1, 1, 1... Which will put the first entry at location 1 instead of location 0.

Finally, remeber that DATA isn't something that executes when the program runs, it only tells the compiler/assembler to put that data in the ".hex image" so that the programmer (your PICKit2) can program the values into EEPROM together with the actual program. WRITE, on the other hand is a runtime command and does write to the EEPROM when the program executes.

Hope that helps.
/Henrik.

[HankMcSpank]

A great answer Henrik (good spot on my erroneous write too!)

That was a top heads up wrt ....DATA @1, ""

and goes some way to resolving the confusion I have wrt managing where the written Eeprom data commences being stored! Presumably I can tuck the user defined byte (called default_config) away at the very last slot of eeprom with...

DEFAULT_CONFIG  DATA 255

& then place the other 255 bytes below that?

... I'll revisit this after the kids are off to bed, but that was a great reply & gives me plenty to get my teeth into - thanks. (PS I haven't forgot about the DDS stuff you did ...I really want to revisit that as soon as I'm finished this melarkey!)

[HenrikOlsson]

Hi Hank,
No, not really....

Defalt_Config DATA 255

Will store the value 255 at location 0 in EEPROM and give that location the label or name Default_Config. If you want a value to be stored at location 255 you need to use

DATA @255, 42

Or possibly (not clear to me how the label thing it works)
Default_Config DATA @255, 42[code]
and then when the user changes that value you do

userValue VAR BYTE
WRITE 255, userValue

or possibly (still not clear how that "label" works)

userValue VAR BYTE
WRITE Default_Config, userValue

Sorry if I'm confusing you...
/Henrik.

[HankMcSpank]

Ok Henrik...I've just used your 'read the EEprom serially out onto my PC screen' (rather than try to work how to look at the data with the pickit2 itself) - it worked a treat....and certainly alleviates some angst as to "I wonder what's what inside the Eeprom space)

And I was clearly wrong with respect to getting my user defined byte tucked away to slot 255, this is obviously what I needed...

WRITE 255, default_config_shadow

(definitely a case of RTFM!)

Anyway, I've learnt something from this little jaunt - I'm happy :-) (tks Henrik)

Edit: Oops - just seen your reply (was obviously typing mine while you were replying) ...anyway, the penny has dropped here!

[SteveB]

Hank,
Something to tuck away in your cranium while working with the EEPROM: It has a limited number of write cycles.

I can't remember the number of write cycles, but you will NEVER wear it out just by reprograming it. (EDIT: The 18F4620 is rated minimum 100K and typical 1M write cycles)

But you could wear it out if you repeatedly write a value during the operaitons of your code. So only make the WRITE when the user actually changes the vaule.

[Charles Linquis]

I have to admit that I haven't read all the posts, but I noticed one thing awhile "up". PLEASE don't drive a LED directly from a PIC pin! LEDs are not 'lamps'. LEDs ARE DIODES! It is CURRENT, not voltage that lights them. Since they are a diode, if you put a slowly rising voltage across them, they (at first) draw no current whatsoever. Then, when they get to the diode forward voltage (which is determined by the technology of the LED), all of the sudden, they light. So, you can have no light at all at 2.2V, and burn them up at 2.3V. If a LED with a forward voltage of 2.3V was connected to a 3V source, it wouldn't last long. So why do they work when you connect them directly to PIC pins? It is because the PIC pins have very small FETs driving them, and they have an "effective" resistance. That is, they cannot supply a huge amount of current. This current-limiting allows both the PIC and the LED to survive.
You have seen the LED flashlights that have nothing but white LEDs and 3 - AAA batteries. No resistor. The forward voltage of most white LEDs is between 3.1 and 4V (Wikipedia). The 3 batteries in series produce about 4.5V. It all works because batteries are not perfect power sources, they have an Equivalent Series Resistance (ESR) that acts like a resistor in series with the battery. This ESR allows things to work - kind of. But have you ever noticed that while you expected the LED flashlights to work forever - they don't? They fail because the makers don't put in a little extra resistance in the leads of each LED to balance the LEDs and to control the current.

Back to PICs: The PIC pins outputs are not really resistors. They may act somewhat like resistors, but they are not. The "resistance" of the pin can vary quite a bit over Vcc variations and from device to device and even pin-to-pin. As a result, the results can be unpredictable. Please put a resistor (at least) in series with your LED.

[HankMcSpank]

The PIC pins outputs are not really resistors. They may act somewhat like resistors, but they are not. The "resistance" of the pin can vary quite a bit over Vcc variations and from device to device and even pin-to-pin. As a result, the results can be unpredictable. Please put a resistor (at least) in series with your LED.

I agree they're not what we'd deem traditional resistors...but for supply of 3.268V to the (blue) LED, I'm seeing 0.337V dropped across the PIC pin - that equates to a series DC resistance in any language. I take your point about variations (though I'm not seeing it pin to pin). So with the PIC pin V drop, that only leaves about 2.95V for the blue LED (with a rated fwd voltage of about 3.2V) ...there's not much chance a blue LED will blow with just 2.95V across it (the current through it is fairly meagre at that voltage level). Fear not, I appreciate your input (& concern), but seriously...this isn't a production run - this is for my own use (& a couple of mates if my project-ette turns out to my liking) ...simply towards learning about PICs & pushing my own (small!) boundaries...I posted up my earlier findings for interest (wrt actual real world IO pin resistance) as opposed to evangelising to others about going 'resistorless'!

I do wonder though since 50 ohms is a surprisingly high figure, just how many factor the PIC's pin resistance in when calculating a LED resistor value? (I suspect not many) ...the resistance certainly can't be disregarded becuase certainly with relatively low value resistors normally in play for LEDs, the PIC pin's inherent resistance is gonna severely skew the desired end result.