Flashlight Firmware Repository

From some random page I pulled up with a quick Google search:

AFAIK the GPL also allows commercial distribution, and doesn’t specifically require attribution. TK can tell us, as she works with this stuff all the time. But, I doubt those things would be hard to add if they were important to you. I think the GPL does require re-distributors provide a link to the unmodified original code, though. That would probably count as attribution. Like I said, ask TK.

Well yes, your math is correct (if you ignore self discharge), but why would the light will be in LVP mode if the cell has a full charge?

This mod helps protect the cell once it is depleted. At that point there is very little reserve capacity to feed that 112uA drain. Dropping that current to 2uA gives you 50X more time to realize that you left the switch ON. Is this a solution to all the world's problems? No, but it is a small step in the right direction.

The GPL requires re-distributors to provide the source code for whatever they are distributing. If they modified it, they need to include their modified version. If it’s unmodified, they should include the original version. Aside from just guaranteeing that everyone can use and mod it, it is also intended to make sure that people share the improvements they make.

This can be inconvenient for vendors though. It would mean, for example, that if RMM sold drivers with the BLF-A6 firmware, he would need to include a link to (or copy of) the BLF-A6 source code or at least provide it to anyone who asked for it. With the public-domain(ish) STAR firmware, he doesn’t need to do this.

Some people prefer BSD-style licenses, which make virtually no demands on anyone. One can modify BSD-licensed code and sell products using it with no need to share their code or improvements. In fact, this is where much of Microsoft’s code came from; it’s based on old BSD code. There is an ancient and ongoing debate about whether “share” or “share and share alike” is more “free”.

Regardless, I’m happy about contributions people share under any open license. You’re helping people you may never even know about. :slight_smile:

A few noob questions, what does this line do?

#define F_CPU 4800000 // CPU: 4.8MHz PWM: 9.4kHz ####### use low fuse: 0x75 #######

And these two?

#define pwminit() do{ TCCR0A=0b00100001; TCCR0B=0b00000001; }while(0 ) //chan A, phasePWM, clk/1 ->2.35kHz@1.2MHz
// #define pwminit() do{ TCCR0A=0b00100011; TCCR0B=0b00000001; }while(0 ) //fastPWM

The two last ones look like two different ways of running pwm. And the first one seems to be somehow related.

Edit: And this one?

#define PWM OCR0B

It sets the CPU clock speed and pulse generator options. It’s a little easier to read the parts of STAR which do the same thing, or the attiny13a reference manual has full details on which bits do what.

The most common options are whether to use “fast” PWM (18.75 kHz sawtooth wave) or “phase-correct” PWM (9 kHz triangle wave), and single channel or dual-channel PWM. In single-channel mode one can also select whether to use variable PFM (pulse frequency modulation) or stick with the default speed.

Ok, good to know. I didn’t know that pin3 was equivalent to star3.

Anyway as i see it, i hope this improvement will be picked up as a standard feature in the LVP in future revisions of the attiny13a drivers.

Seems like the obvious next step, for extending the protection of the LVP in single battery applications & multi battery LDO drivers.

I started on some ideas I had knocking around in the back of my head, and ended up with a FET+1 firmware which works like the diagram below… I’m curious what people think. It basically has a regular mode group, a secondary group for the most useful blinkies, and a tertiary group for a full set of blinkies.

You can fit all that on the attiny? Nice!

ToyKeeper is one of our most valued players. He She is one who is nice enough to share with EVERYONE. :bigsmile:
Puts a lot of effort into this for us. A BIG thumbs up for him her!

Corrected.

Thank you, my sincere apologies. :8)

How does one exit from tertiary mode if mode memory is enabled?

(I know I'd get lost ... )

There is no memory. :slight_smile:

Got it, I think, it’s the default pwm pin on the 105c. Just out of curiosity, how many pwm channels do the attiny13 got? Yeah I know rtfm, there must be at least two, so much I know. :slight_smile:

The attiny13a has two PWM channels which share a counter.

Got it, thanks for answering. :slight_smile: And looking at that page, I understand how flash and eeprom works but what about ram? It says 64 byte available. Should I start counting variables? Basically one byte integers I guess.

RAM gets weird. You may have to keep track of it manually, because exceeding the limit mostly just results in really bizarre behavior.

If you find your code doing things which make absolutely no sense, it might be time to check your RAM usage. I ran into issues like this when I was still using a 32-byte array in RAM to mirror the eeprom, and added some other sizable arrays on top of that. But ever since dumping the eeprom mirror and moving static arrays to progmem (ROM), I haven’t had any issues at all.

Most processors map all the different memory spaces into one linear space, so, like… 0 through 999,999 are RAM and 1,000,000 through 1,999,999 are ROM and 2,000,000 through 2,999,999 are eeprom, and so on. But the attiny doesn’t do this. All the different memory spaces overlap (use the same address space) and are instead accessed through different instructions. So, if you put an array in ROM you must use special functions to access it. The compiler doesn’t understand this though, and will happily let you access the portions of RAM which have the same address as ROM if you forget and use the wrong syntax. The attiny also doesn’t appear to segfault or otherwise crash when accessing RAM which doesn’t exist, so instead it just behaves very strangely.

So, long answer to a short question, but… yes, you might occasionally have to count variables in your head. I’m not aware of a debugger or emulator which can check these things automatically, but I haven’t really looked.

The standard Star firmware uses a 32 byte array for EEPROM block reading (was a while ago I checked, might have changed). This eats half of your memory already. As ToyKeeper already wrote, if you use more RAM space than is available some really funky things can start to happen. The first thing you can do to check is temporarily make that array much smaller while debugging problems, like 8 or even 4 bytes.

If RAM space does turn out to be your problem, you could re-write that EEPROM wear leveling routine to use the 8 byte array and loop through the EEPROM area until the mode byte is found. Then you can use the entire 64 byte EEPROM area instead of only half as the standard Star does/did. Not only RAM space is saved, wear leveling is improved too (although probably not an issue). It will however cost a little more in valuable programming space so it might not be worth it in the end, at least on the 13A. I use this method on the 84 and 85, programming space is not as much of a concern with them.

Thanks for the help, again. :slight_smile: So I’ve been trying to learn how ram works, checking the avrfreaks site and I found a patch to avr-size but it only counts global and static variables, which is understandable. It counts 42 (I can only find 41 though) bytes and yes 32 of those are the eeprom array. I found out about how PROGMEM works too. And local variables are also easy to count, not that many of them anyway. But how about constants that are not variables (c noob here)? If you got while(1) I take it the 1 is not put in ram. But if you got while(i < 1) is the 1 put in ram then?

Nope - the "1" won't be in RAM, but the "i" variable would be in RAM, assuming it's not optimized out and used only from a register. This is generally what happens...