Attiny25/45/85 FW Development Thread

1911 posts / 0 new
Last post
dthoang
Offline
Last seen: 1 year 2 months ago
Joined: 10/09/2014 - 13:30
Posts: 319
Location: Austin, TX USA
texaspyro wrote:
ToyKeeper wrote:
Oh, and after flashing at 128 kHz, it doesn’t seem to want to be flashed any more. Anyone have any idea how to recover that?

You have to slow down the ISP clock rate (to < 1/4 the CPU clock rate?)

I use a STK-500 for programming… don’t know the magic word for avrdude to change the clock rate.

With USBasp, try bridging JP1 that enables slow SCLK.

one year rookie

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 45 min ago
Joined: 01/12/2013 - 14:40
Posts: 10241
Location: (469219) 2016 HO3

I tried -B and -i for avrdude, but it can’t set SCK on this usbasp. I think it’s a newer one which does it “automagically”. I tried bridging JP3 and it didn’t seem to change anything. I think JP2 is its self-programming jumper. JP1 is used for 5V/3.3V select, and doesn’t help either. I could try to update the usbasp firmware, but it requires extra hardware I don’t have.

So, no luck yet.

Halo...
Halo...'s picture
Offline
Last seen: 3 years 7 months ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

ToyKeeper wrote:
Oh, and after flashing at 128 kHz, it doesn’t seem to want to be flashed any more. Anyone have any idea how to recover that?
:~
I should have mentioned not to go too low. Unless one has a usbasp with updated firmware. I too noticed that we can’t seem to set SCK in our cheap chinese usbasp clones. And that slow jumper doesn’t seem to work either. Sorry, TK. :ghost:

Would you happen to have an arduino laying around? You can use one of them to update the usbasp firmware. Or use the arduino to reprogram your attiny. Looks like you need a slow sck version of the ardunioISP sketch. Like this one.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 45 min ago
Joined: 01/12/2013 - 14:40
Posts: 10241
Location: (469219) 2016 HO3

I suppose I could probably use a raspberry pi 2 to do it… or get an arduino and use that. But not for about a month, at least. I’ll have very limited access to things for a while.

Halo...
Halo...'s picture
Offline
Last seen: 3 years 7 months ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

Yea, if you have one available a raspi can do it. I see adafruit has a guide.

pyro1son
pyro1son's picture
Offline
Last seen: 2 months 2 weeks ago
Joined: 03/21/2013 - 08:18
Posts: 432
Location: UK

For the ATTiny13 I’ve been using:

avrdude -p t13 -c usbasp -u -Uflash:w:battcheck.hex:a -Ulfuse:w:0×75:m -Uhfuse:w:0xFF:m

What should I be using for ATTiny85?

Pastebin                                      &nbs

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

I use 3 different .BAT files in my \AVRDUDE folder - one for testing the connection, one for fuses, and one for downloading. There are 3 fuse bytes for the 25/45/85, not two like the 13A.

T85.BAT:

avrdude -p t85 -c usbasp -n

 

85FUSES.BAT:

avrdude -p t85 -c usbasp -Ulfuse:w:0xe2:m -Uhfuse:w:0xdf:m -Uefuse:w:0xff:m
rem C3 for low byte is 6.4 Mhz

 

85NARSIL.BAT:

rem 85Narsil - downloads Narsil (Tiny85 e-switch UI configurable)
rem
avrdude -p attiny85 -c usbasp -u -Uflash:w:\Tiny254585Projects\Narsil\Narsil\Release\Narsil.hex:a

 -Ueeprom:w:\Tiny254585Projects\Narsil\Narsil\Release\Narsil.eep:a

 

This is a great tool and reference for the fuses:  ATMEL Fuse Calculator. It will generate the fuse params formatted to use with 'avrdude'.

 

Rick NJ
Offline
Last seen: 4 years 2 months ago
Joined: 01/16/2013 - 12:46
Posts: 43
Location: NJ, USA

Thanks guys. I am new to this arena and discussion like this is helpful.

It was only 6 months ago when I ordered my first 18650 (Latticebright “XP-E”) flashlight. Initially, I merely wanted to play with the electronics to modify the driver. Eventually, I concluded it is easy to get an MCU based driver, write my own firmware to achieve what I want to do. I was very apprehensive when I first considered the ATTINY85v. So I share my experience here for the next guy. May be he/she can approach with a bit more confidence.

I already have my own firmware written for the ATTINY13A. It has all the functions I wanted but a very bad UI for selection. I was at around 1020 bytes. So, to do a better UI, I need more flash space.

While I was still deciding, I blew my ATTINY13A by mistake. So, no more deciding, Mouser was happy. With my ATTINY85V from Mouser at hand, I rush to install it. My first one did not went well. I must have a hidden solder bridge somewhere. Removing it and resolder again, the thing worked like a charm. For some reason during initial install, the ADC always read around 2.7V to 2.8V, yet measuring with DMM, the ADC pin is reading right at 4.7K to ground and 19.1K to diode. I double check the code for mistaken where I might have set the ADC pin to OUT and send a 1 there, but that was not the case. So believing it is a dry joint, I desoldered the TINY85 and resoldered it. It works.

Beside the on for the test/development board, I have another 4 for real flashlights. After the first one , the other 5 were no problem. No technical problem anyway. All went very smooth except the 4th one. The next paragraph is a distraction:

The SAGA of Chip#4
My “work flow” is: first put it on SOIC clip to check for chip operations – read the flash, eeprom, fuses, etc., then bend legs, then install. On ATTINY85V #4, it slipped the clip and shoot out of the spring-clip away from my electronic work area to somewhere around my PC desk. An hour later, a miracle that I found it in that rat-nest of wires on the ground between the PC desk and the wall. So, I finish my read-test, programmed it, and re-read it AOK. I bend the leg on this 4th one. About ready and on final check, it felt off my plier. So problem, this is not like behind the desk… An hour later, I found somehow it landed BEHIND my backup SLA battery. Ok, at least I got it. So on to soldering. After testing the TINY13A and the NANJG105c, I removed the TINY13A and reach for my ATTINY85V#4 – it is missing! The chip is gone! I looked at the floor a dozen times, I just couldn’t figure out where this chip went. It is not on the table, it is not on the floor, and it did not felt into or behind anything! I looked, and looked, on the floor, move the stuff on the table, move the stuff from boxes around around the table… Where the hell is chip#4!!!!

Back to about the 85V. I took it as a challenge to find out what I needed to do for code change. I did the research by the datasheets alone as a challenge. I came back to this thread to see what changes are recommended and I did do all those from the datasheet research alone. So I passed my own challenge.
1. FCPU change
2. ADC reference voltage bit change
3. PWM change
and, I did one more that I didn’t find mentioned here
4. eeProm write address needs to change to H & L both since it has 512 bytes, L alone is not going to do 512.

The bending of the leg is not hard. it is best to re-flatten/re-align the end-part of the leg to ensure good contact with the pad on the PCB. Secure one outer leg (nearer to edge of PCB) first, check all leg for good positioning, then secure one more leg and recheck again. Then finish soldering, check the soldering and clean up any bridging.

Now, my 4 ATTINY85V flashlights has the features/functions I wanted exactly.

That was at times a frustrating project, but it works well now. I have four “new” flashlights with TINY85V, and still have a TINY85V on my work-bench “flash light” for more playing-around-with for future versions. Getting the TINY85V’s leg bend right and installed it right requires a lot of patience, but it fits very nice and the result is very rewarding.

The SAGA of Chip#4 Episode 2
By now, it was > 4 hours on this chip alone. I cleaned the floor slowly and gently an inch strip at a time – as far as 6 feet from the table clear wall-to-wall but found nothing. By now, I am totally puzzled. How can a chip this big just vanished! I gave up, sat on the floor, and a bit dumbfounded. Suddenly, something caught my eyes in mid-air. I grab a working flashlight – this time, not on the floor, not on the table, and about 2 feet off the floor. There it was, hung on a small spider-web between the table-leg and the wall in mid-air. Well, no spider in my house was going to eat silicon for dinner that night. That chip took me half a day to finally finish. Like I said, not really a technical problem. Just a hungry spider.

Pablo E.
Pablo E.'s picture
Offline
Last seen: 3 years 1 month ago
Joined: 08/08/2015 - 13:54
Posts: 234
Location: Spain (GMT+1)

Hi,
i think i have a problem with bistro firmware or my board components.

It doesn’t access to hidden modes, instead it enters in configuration menu when i do a med tap, no matter what mode is set.

Setting memory on/off makes no difference, always works as next mode memory.

Any idea what the problem could be? :~

ImA4Wheelr
Offline
Last seen: 12 hours 51 min ago
Joined: 02/03/2013 - 14:51
Posts: 7928
Location: SC

Rick NJ,

Thank you for sharing your experience.  I really appreciated your chip searching experiences.  I've have a couple 13a's I never found.  I need to search for spider webs in the future.  That is wild.

As far as bending the legs.  I don't bend the legs until after I flash them.  I then push the legs in at the inward arch that is just above the "foot".  That approach as worked fine each time.  I do find that I touch some pins up with a fine solder tip just to make sure vibration doesn't break the connection of pins that seem light on solder.  With the pins some much taller, the extra solder doesn't interfer with future reclipping (reflashes).

Rick NJ
Offline
Last seen: 4 years 2 months ago
Joined: 01/16/2013 - 12:46
Posts: 43
Location: NJ, USA

Yeah, it was wild. Knocking it off the table was common. Finding it on the ground was common. I never expected it to be caught by a spider-web while falling to the floor.

Where it was, it would have been almost touching my forehead the half dozen times I looked at the floor back there, but my attention was totally focused on the ground!

Like you, I took mental note also. Next time I drop another tiny parts, I would check around my table for any spider-web and see if the SMDs is dangling there.

- – - – - -

I too programmed the TINY85V before soldering. After soldering it on, my first test was reading it back and do a file-compare and re-program it again as tests. That gives me the comforting feeling the (a) it is soldered on OK (at least the programming-related pins, but good enough). and (b) it was not cooked while soldering.

My first SMD soldering job was on an ADS1115 (0.5mm pitch 16bit ADC), that went AOK the first time. Second time I worked on sub-mm pitch was an INA219 (12 bit ADC Volt Current Measurement IC). The joints looked great, but the chip was cooked to a crisp.

So, even with something as big as the TINY85V, I am always concerned about cooking the chip. Even all the TINY13A I desoldered are in working condition, if only I can find them a place to work.

EDIT: made a mistake, it was not the INA219 is a Volt/Current measurement IC. Not a 12 bit ADC.

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

Pablo E. wrote:
Hi, i think i have a problem with bistro firmware or my board components. It doesn't access to hidden modes, instead it enters in configuration menu when i do a med tap, no matter what mode is set. Setting memory on/off makes no difference, always works as next mode memory. Any idea what the problem could be? :~

I am having a similar problem, but worse - it comes up in config mode, always. I'm using the vers from 2015-10-18, but I was told the vers to use is 2015-11-08, here: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/files/head:/ToyKeeper/bistro/.

For fuses, Halo said here:

bin/flash-25.sh (2015-11-08) fuses
L: 0xe2, H: 0xdf, E: 0xff in Fuse Calculator

Looking through my files it seems I’ve been using BOD 1.8v, startup delay 64ms (max). L: 0xe2, H: 0xde, E: 0xff. I believe I been using those since the beginning with bistro, ignoring the ones mentioned in bistro.c. Thought a longer startup delay wouldn’t hurt anything.

Pablo E.
Pablo E.'s picture
Offline
Last seen: 3 years 1 month ago
Joined: 08/08/2015 - 13:54
Posts: 234
Location: Spain (GMT+1)

Thanks for the reply Tom E.

Well, fuses is something i am a bit lost.

Sorry for the few information in my previous post, it was too late:
I am using hex file from 2015-11-08, from the link you pointed, whith an attiny25v.

For fuses i used the ones in bistro.c file:
Low: 0xd2
High: 0xde
Ext: 0xff

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

I used those same fuses as you and am having problems.

I think 0xE2, 0xDF, 0xFF are the correct or best ones to use. No time to try yet though, hoping today.

Pablo E.
Pablo E.'s picture
Offline
Last seen: 3 years 1 month ago
Joined: 08/08/2015 - 13:54
Posts: 234
Location: Spain (GMT+1)
Tom E wrote:

I used those same fuses as you and am having problems.

I think 0xE2, 0xDF, 0xFF are the correct or best ones to use. No time to try yet though, hoping today.

Ok, I’ll try them.

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

Ohhh - just tried - made no difference for me... Posting on the TK thread bout it...

Pablo E.
Pablo E.'s picture
Offline
Last seen: 3 years 1 month ago
Joined: 08/08/2015 - 13:54
Posts: 234
Location: Spain (GMT+1)

What a pity! thanks for trying, you save me quite work.

I´ll see what Toykepper says.

Rick NJ
Offline
Last seen: 4 years 2 months ago
Joined: 01/16/2013 - 12:46
Posts: 43
Location: NJ, USA
Tom E wrote:

Pablo E. wrote:
Hi, i think i have a problem with bistro firmware or my board components. It doesn’t access to hidden modes, instead it enters in configuration menu when i do a med tap, no matter what mode is set. Setting memory on/off makes no difference, always works as next mode memory. Any idea what the problem could be? :~

I am having a similar problem, but worse – it comes up in config mode, always. I’m using the vers from 2015-10-18, but I was told the vers to use is 2015-11-08, here: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/files/head:/ToyKeeper/bistro/.

For fuses, Halo said here:

bin/flash-25.sh (2015-11-08) fuses
L: 0xe2, H: 0xdf, E: 0xff in Fuse Calculator

Looking through my files it seems I’ve been using BOD 1.8v, startup delay 64ms (max). L: 0xe2, H: 0xde, E: 0xff. I believe I been using those since the beginning with bistro, ignoring the ones mentioned in bistro.c. Thought a longer startup delay wouldn’t hurt anything.

I don’t know which MCU the Bistro firmware was written for. Since you said you have memory problem, it is not likely to be a fuse problem. Instead, it points to one of the main difference between the MCU’s:

The ATTINY13 has 64 byte EEPROM
The ATTINY25 has 128 byte EEPROM
The ATTINY45 has 256 byte EEPROM
The ATTINY85 has 512 byte EEPROM

Therefore:
ATTINY13 and ATTINY25 can compile with uint8_t or int8_t and use only LOW byte address.
ATTINY45 may fail with int8_t and should use the unsigned uint8_t only.
ATTINY85 may fail with int8_t and uint8_t and should use int16_t or uint16_t. Both EEARH and EEARL must be set. When using C, EEAR should work (but of course depends on the C compiler versions).

You can expect memory may not work properly across all three MCU’s. Unless the Bistro firmware is limiting itself to the first 128 bytes of EEPROM, it may be storing your memory in nonexisting eeprom locations.

When I reworked my ATTINY13A firmware for the ATTINY85, I had to modify my EEPROM functions accordingly.

Suggestion:
- Re-burn your firmware with the fuse setting you are using, which should reset all your memory pointers and erase your EEPROM. If it works immediately after re-flashing, do an eeprom dump. Save that file.
- If re-burning doesn’t temporarily remove the problem (and you are using ATTINY25 and 0xe2, 0xdf, 0xff), eeprom space is not the problem. If it works immediately after reburn, continue.
- Keep changing so it keeps updating eeprom. After just under 64 times do another eeprom dump.
- Keep changing so it keeps updating eeprom. At just under 128 times do another eeprom dump.
- You get it, do it at before 256 times and before 512 times.
- If it fails before then, make sure you do an eeprom dump immediately after you noticed the failure.
- After the eeprom dump immediately after failure, try changing mode a couple of times (and note how many times), do another dump. This is the last one needed.

I don’t know what you use to flash, so I cannot give you the whole command, but after your burner specific stuff, it should be like:
avrdude avr_burner_specific_params -U eeprom:r:readin.hex:i
This run saves your eeprom into file readin.hex. Since you will be saving more than one, name it read128.hex, read256.hex, etc.

With that info, one can determine if it is overrunning the existing eeprom. When you do have those hex files, upload it. I’ll take a look.

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

Bistro is written for the 25. The Group buy for the X6-X5 pair is using Bistro on a 25.

Bistro builds for me on Atmel Studio 7.0 at 2038 bytes Program memory, 28 bytes Data memory. Tight on code, only 21.8% of data memory used.

Rick NJ
Offline
Last seen: 4 years 2 months ago
Joined: 01/16/2013 - 12:46
Posts: 43
Location: NJ, USA
Tom E wrote:

Bistro is written for the 25. The Group buy for the X6-X5 pair is using Bistro on a 25.

Bistro builds for me on Atmel Studio 7.0 at 2038 bytes Program memory, 28 bytes Data memory. Tight on code, only 21.8% of data memory used.

Any idea how it reads the eeprom? Does it have wear leveling?

With my own home-made firmware (ATTINY13 version), gcc reports I use only 6 to 8 bytes of memory of 64 bytes. But in my eeprom read routine, I use 38 bytes of buffer (plus more local variables). It actually fails when I use >38, the total 64 byte RAM is not adequate. Stack-full! Stack usage is not part of “data” but certainly use RAM space. The compiler cannot always determine how much stack you are using. So total DATA is not the same as total RAM usage.

EDIT:
One more thought. If it is a group-buy, is it a fully made flashlight or buyer-modified?
The same fuse setting and the same software should work exactly the same. The only variable there is start-up condition and/or hardware issues. That it is a memory problem (he is not calling out other issues) points to probably it calling different functions (start up condition) being different or hardware problem. Calling other functions will mean different stack_usage which may affect eeprom reading function.
Is there any star selected options? If so, what are they? Does it fail with default options only?

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

Yes - all our recent firmware versions use wear leveling (mode memory and config settings).

Oh boy lots of Q's... In some of our recent BLF Group buys, we try to get a true "modded light", and it's performance/function, to the masses, and this group buy for the BLF SE X6 v2 and X5 is exactly that - cannot be bought anywhere, no modding required, fully working at high performance, but to tweak it out fully, you need to add bypass's on the springs. It's also somewhat high-end for a budget light - X6 is SS/Cu and the X5 is 100% Cu body, so these are very special. But you can also buy the pair in regular black anodized alum for cheaper.

Not sure bout star options - I don't use them - might be a compile option.

Rick NJ
Offline
Last seen: 4 years 2 months ago
Joined: 01/16/2013 - 12:46
Posts: 43
Location: NJ, USA

Tom E, thanks for the many answers.

I think Pablo E.’s flashlight failure will need some deep debugging – perhaps hardware. While less likely, even factory-made stuff can have dry joints. Hopefully he will find some solution here.

I am just not experience enough to draw it closer to help Pablo given the limited info. I am suspicious of the eeprom reading function. I made my eeprom wear-level codes use the stack because I was RAM-short with the ATTINY13A. With eeprom read, it needs a large buffer to reduce the number of reads. Since it needs to be done just once at the start, it makes perfect sense to allocate it on the stack and once finished, the rest of the program has lots of stack space to use. The original Bistro developer likely made the same choice I did since he uses only 28 bytes of fixed data. Stack issues is harder to debug as each extra step may depend on condition and thus not always taken. One of those extra step might just mess up the stack enough for stack space to run out, or overwrite something.

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

TK wrote bistro and she's a she Smile, but she also based it on previous open source driver code. Well the bistro firmware itself is well proven - Halo for one has it installed, and I think the X6/X5 sample units received in the group buy are running bistro.

I've gone thru the eeprom code once before, looked again nnow. We do  eeprom_read_byte() calls in a loop (in Bistro that way), so no need to buffer anything. Why do you care to reduce the # of reads? It's write cycles that are limited, and didn't think any issues with reads?

In my Tiny85 Narsil firmware, think I use 2 bytes to store config data w/wear leveling.

Rick NJ
Offline
Last seen: 4 years 2 months ago
Joined: 01/16/2013 - 12:46
Posts: 43
Location: NJ, USA
Tom E wrote:

TK wrote bistro and she’s a she Smile, but she also based it on previous open source driver code. Well the bistro firmware itself is well proven – Halo for one has it installed, and I think the X6/X5 sample units received in the group buy are running bistro.

I’ve gone thru the eeprom code once before, looked again nnow. We do  eeprom_read_byte() calls in a loop (in Bistro that way), so no need to buffer anything. Why do you care to reduce the # of reads? It’s write cycles that are limited, and didn’t think any issues with reads?

In my Tiny85 Narsil firmware, think I use 2 bytes to store config data w/wear leveling.

re: “Why do you care to reduce the # of reads?”
Speed. The datasheet said it take 1.8ms per read. Reading 512 bytes one at a time will take almost a full second (0.92 seconds). That is a visible delay before the flash light turn on. So, I went for a block-read to (hopefully) reduce the time it takes.

re: “In my Tiny85 Narsil firmware, think I use 2 bytes to store config data w/wear leveling.”
I am a damn optimist. I use 256 for each byte. I also have two bytes of long-term memory using up all of 512 bytes of eeprom! That would be 25.6million clicks. I want to make sure it would last till I meet my maker, if my click switch itself lasts that long… Like I said, I am a damn optimist.

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

By the time you click 25 million times, we'll be getting 5000 lumens in a keychain light with no heat Smile - time for an upgrade has long past.

Pablo E.
Pablo E.'s picture
Offline
Last seen: 3 years 1 month ago
Joined: 08/08/2015 - 13:54
Posts: 234
Location: Spain (GMT+1)
Rick NJ wrote:
I think Pablo E.’s flashlight failure will need some deep debugging – perhaps hardware. While less likely, even factory-made stuff can have dry joints. Hopefully he will find some solution here.

Hi Rick,
i don’t discard a hardware failure.

I thought also i have been sold wrong capacitors as, if i am not wrong, too big cap could explaing “next mode” memory; right?.

As for dry joints, i am planning to do a second driver, this should shed some light on the subject.

Tom, could you confirm your mode memory doesn’t work properly?

Tom E
Tom E's picture
Online
Last seen: 3 min 49 sec ago
Joined: 08/19/2012 - 08:23
Posts: 12686
Location: LI NY

I got no modes at this point, so can't test mode memory - all I get is config mode - that's it.

Rick NJ
Offline
Last seen: 4 years 2 months ago
Joined: 01/16/2013 - 12:46
Posts: 43
Location: NJ, USA
Tom E wrote:

By the time you click 25 million times, we’ll be getting 5000 lumens in a keychain light with no heat Smile - time for an upgrade has long past.

Ahem, it is 25.6 million. Failing at 25 million will be a premature failure. Like I said, I am an optimist…

Rick NJ
Offline
Last seen: 4 years 2 months ago
Joined: 01/16/2013 - 12:46
Posts: 43
Location: NJ, USA
Pablo E. wrote:
Rick NJ wrote:
I think Pablo E.’s flashlight failure will need some deep debugging – perhaps hardware. While less likely, even factory-made stuff can have dry joints. Hopefully he will find some solution here.

Hi Rick,
i don’t discard a hardware failure.

I thought also i have been sold wrong capacitors as, if i am not wrong, too big cap could explaing “next mode” memory; right?.

As for dry joints, i am planning to do a second driver, this should shed some light on the subject.

Tom, could you confirm your mode memory doesn’t work properly?

re: “I thought also i have been sold wrong capacitors as, if i am not wrong, too big cap could explaing “next mode” memory; right?”

I have not peeked inside the Bistro firmware code, so I would not be able to definitely answer that. I have read JonnyC’s OffTime capacitor code. If Bistro is like JonnyC’s work:

- an oversize capacitor will length the bleed-off time. It should have the effect of lengthening the duration of what it calls quick-click. So a longer wait between click is accepted as the “quick”.

- an undersize capacitor will shorten the bleed-off time. It should have the effect of speeding up time. If it is too-awful-small (too far below 1uF), you would not have quick click at-all. the fastest on/off would still be seen as power-off-too-long.

Do you have a DMM with capacitor measurement?

As for me, I did not use an off-timer capacitor. During my testing, I found my capacitors to be varying too much. With multiple flashlights, I do not want to individually calibrate each capacitor for the “off timer count.

So, in my code, I set a flag at power on and increment the mode and save. After a delay, I cleared the flag before I restore/store the mode memory. So I know with the flag whether it was turned off quickly last time (before the delay expired), or not.

Halo...
Halo...'s picture
Offline
Last seen: 3 years 7 months ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

Rick NJ wrote:
Any idea how it reads the eeprom? Does it have wear leveling?

ToyKeeper has a code repository. :bigsmile: In addition to her own code, she has also archived lots of other peoples open source code. http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files All of her code would be in “bin” and “ToyKeeper”. Other people’s code is under their respective BLF usernames.

Bistro in her normal repository: trunk/files/head:/ToyKeeper/bistro/
Bistro in her testing repository: tiny25/files/head:/ToyKeeper/bistro/

Pages