Electronics > Projects, Designs, and Technical Stuff
Cheap Chinese Cree XM-L T6 modification
<< < (5/6) > >>
0xdeadbeef:

--- Quote from: mikerj on December 14, 2015, 10:35:00 am ---Are EEPROM write errors really a problem for this application?  If the flashlight starts up in a different mode to the one you expect, it's really not a big deal, it just takes a few more clicks.

--- End quote ---
Sure. But if you don't consider a write error in your design you could as well be stuck in an "unexpected state" forever. It's always better to do a proper design than to be surprised by a bad one.
Rick Law:

--- Quote from: 0xdeadbeef on December 14, 2015, 11:22:24 am ---
--- Quote from: mikerj on December 14, 2015, 10:35:00 am ---Are EEPROM write errors really a problem for this application?  If the flashlight starts up in a different mode to the one you expect, it's really not a big deal, it just takes a few more clicks.

--- End quote ---
Sure. But if you don't consider a write error in your design you could as well be stuck in an "unexpected state" forever. It's always better to do a proper design than to be surprised by a bad one.

--- End quote ---

I thought about that during the initial coding.  The worst I can expect is all the modes get set in different than intended.  So I made sure that my "safety related" features are not software controlled.
Software controlled are:
- Which set of modes, set 1 or set 2.
- Should it blink to acknowledge saving current mode as default start up
- What kind of acknowledgement?  Blink the mode number or just one quick blink.
Hardware controlled (shorting one of the "Stars" to ground)
- Bypass turbo timer and let full blast go forever at the risk of overheating
- Bypass low battery mode (drop down to moonlight level only when <= 2.7v)

The low battery mode doesn't do a full off but goes to 10 of 255 pwm.  So, in case of power outage, I have the option to "trade the life of the battery for a bit more light."
0xdeadbeef:
Even though I'd prefer some kind of power latch approach where the µC could measure on and off times of the switch (e.g. combined with soft power on/off), some people seem to have come up with ideas to store at least the information that the switch was currently on (or the other way round: to say that it was off for a longer time):

This site provides "off-time" firmware versions that make use of an additional 1µF capacitor on one of the port pins (star 4) as flag:
http://drjones.nerdcamp.net/

And here is some code that claims to use an SRAM cell to store the information that the switch was one for 500ms:
https://github.com/alexvanh/basic_off_time_driver/blob/master/driver.c
Which is not completely impossible as SRAM consists of flip-flops which need only very little energy to keep their state.
Problem is that this is probably not very reliable. Like it might work on some controllers, but not on others.

BTW: another site with custom firmware - looks like an EEPROM only approach:
http://jcapsolutions.github.io/blf-firmware/



nukie:
I have used the write at switch on approach since 2006 with an Attiny13 with one of an early Luxeon star. Never a problem with 10uF bypass cap with two AA nimh.

There are other ways to detect mode change without EEPROM, the chinese are pretty good with PIC chips.
Rick Law:

--- Quote from: 0xdeadbeef on December 14, 2015, 10:55:40 pm ---Even though I'd prefer some kind of power latch approach where the µC could measure on and off times of the switch (e.g. combined with soft power on/off), some people seem to have come up with ideas to store at least the information that the switch was currently on (or the other way round: to say that it was off for a longer time):

This site provides "off-time" firmware versions that make use of an additional 1µF capacitor on one of the port pins (star 4) as flag:
http://drjones.nerdcamp.net/

And here is some code that claims to use an SRAM cell to store the information that the switch was one for 500ms:
https://github.com/alexvanh/basic_off_time_driver/blob/master/driver.c
Which is not completely impossible as SRAM consists of flip-flops which need only very little energy to keep their state.
Problem is that this is probably not very reliable. Like it might work on some controllers, but not on others.

BTW: another site with custom firmware - looks like an EEPROM only approach:
http://jcapsolutions.github.io/blf-firmware/

--- End quote ---

I credited my knowledge to them: Dr. Jones and JohnnyC (jcapsolutions).  Apart from studying the datasheets, I studied their work to figure out how things are done as I wade into AVR without Arduino.  I use their work as a cheat sheet and reference.

After I got my replacement ATTINY85 on my test setup (replacing the blown ATTINY13), it just occur to me that I don't need any fancy timing/brownout detect type things here.

Since my approach consist of two EEPROM related steps:
OldIndex = Index++;
if (Index>=MaxIndex) Index=0;
WriteNewData(Index);
EraseOldData(OldIndex);

If it didn't complete the WriteNewData(), EraseOldData() never got done.

If EraseOldData() did not start or started but did not complete, upon power up, that oldData or partially erased oldData would be found to be the first un-erased byte.  Upon boot up, it would think that is the new data, but the bits may be partially erased.

So, after finding the Index for the byte, assume this may be partially erased and see if there is data at "the other / older" Index (Index during write before Index++, adjusting for wrap around index).  If there is, the erase did not occur or did not finish, so use the data at the "other Index" and forget this partially completed mode change.

Good thing about it being "just a flashlight".  Worst case is, what it mess up is just a mode change.  Now that my ATTINY85 is working, I have more code space to work with.  I can begin playing around with more things.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod