Flashlight Firmware Repository

1798 posts / 0 new
Last post
ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

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.

cajampa
Offline
Last seen: 2 years 3 months ago
Joined: 08/01/2014 - 01:55
Posts: 1963
Location: Sweden
Crux wrote:

cajampa wrote:
…Does this work on all attiny13a drivers & not only on “typical 105C driver” like the fet+7135 driver for example because that one don’t have any “stars”…

I think this can be adapted to any 13A driver because typically pin3 (Star3) is unused. Unfortunately, that pin is not in a convenient location to make this mod easy (but where is the fun in easy?). Even E-switch drivers can benefit from this mod. In fact they would have the most to gain because they are always drawing some current. But I don’t have any to test this out on… Likewise, any driver using any micro-controller should be able to adapt this technique to reduce current.

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.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

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.

viperbart
viperbart's picture
Offline
Last seen: 5 months 5 days ago
Joined: 07/22/2014 - 15:17
Posts: 444
Location: Toronto ON CA

You can fit all that on the attiny? Nice!

jhalb
jhalb's picture
Offline
Last seen: 1 year 6 months ago
Joined: 03/23/2015 - 21:24
Posts: 1350
Location: California

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!

viperbart
viperbart's picture
Offline
Last seen: 5 months 5 days ago
Joined: 07/22/2014 - 15:17
Posts: 444
Location: Toronto ON CA
jhalb wrote:
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!

Corrected.

jhalb
jhalb's picture
Offline
Last seen: 1 year 6 months ago
Joined: 03/23/2015 - 21:24
Posts: 1350
Location: California
viperbart wrote:
jhalb wrote:
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!

Corrected.


Thank you, my sincere apologies. :8)
Crux
Crux's picture
Offline
Last seen: 8 months 3 weeks ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

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

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

ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

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

There is no memory. Smile
guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
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.


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. Smile
ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

The attiny13a has two PWM channels which share a counter.

http://en.wikipedia.org/wiki/Atmel_AVR_ATtiny_comparison_chart

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
The attiny13a has two PWM channels which share a counter.

http://en.wikipedia.org/wiki/Atmel_AVR_ATtiny_comparison_chart


Got it, thanks for answering. 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.
ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

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.

Mike C
Mike C's picture
Offline
Last seen: 2 months 3 weeks ago
Joined: 01/22/2014 - 08:03
Posts: 2009
Location: Sweden

guardior wrote:
It says 64 byte available. Should I start counting variables? Basically one byte integers I guess.

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.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

Thanks for the help, again. 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?

Tom E
Tom E's picture
Offline
Last seen: 1 month 5 days ago
Joined: 08/19/2012 - 08:23
Posts: 10899
Location: LI NY

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

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

I see thanks. Yes the “i” will be put in ram if it’s a local variable, so much I get by now. Then I think I’m all good to go then, when my flasher arrives.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

You can actually eliminate the eeprom mirror entirely, and IIRC it doesn’t really increase ROM usage. I’ve been doing it that way lately. I also just found out that avr-size can do a lot of the counting for you if you run it like “avr-size -C —mcu=attiny13 foo.elf”. However, you still have to leave room for the stack, not just the variables. It’s not usually very big on a processor this small, but some temporary data still gets stored in RAM on top of the explicitly-declared variables. For example, the function call stack, and any expressions which don’t fit entirely into registers.

The extra info in that avr-size command can definitely help when you start approaching the limit.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

Yes that was the avr-size command I was talking about. So the missing byte could be something else then. I think I’ll keep the eeprom mirror for now but if I need ram more than flash I know I could get rid of it. And yeah, I also read somewhere that you should keep a few bytes on ram for the mcu to use, dunno how many though. IIRC there was a figure 70% floating around. If you go above that then you might run into ram problems.

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 05/30/2013 - 23:31
Posts: 6419
Location: Held against my will in IOWA, USA

Hey TK, is the extended config mode (memory) in blf-a6 supposed to be working? I remember seeing somewhere that it wasn’t fully implemented yet, but now I’m not sure.

Sorry if it was already mentioned.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

pilotdog68 wrote:
Hey TK, is the extended config mode (memory) in blf-a6 supposed to be working? I remember seeing somewhere that it wasn’t fully implemented yet, but now I’m not sure.

It works if recompiled with that option enabled, but it’s necessary to remove both the tactical strobe and bike flasher to make room.

The extended config mode simply converts it to use two config options (mode group and mode memory) instead of one (mode group). But if you’re recompiling anyway, you can set those both at compile time (in tk-otc.c) and have lots of room left over for other stuff.

I might still be able to reduce the size a little, and I’ll definitely try… but for now the default is one config-mode option and one star-based option.

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 05/30/2013 - 23:31
Posts: 6419
Location: Held against my will in IOWA, USA

So by ‘enable’ you just mean un-comment it? I prefer to be able to toggle both mode group and memory without disassembly. I also have no problem deleting blinkies.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 05/30/2013 - 23:31
Posts: 6419
Location: Held against my will in IOWA, USA

Another weird question: is it possible to have lvp protection enabled in one mode group, and disabled in the other?

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

Mike C wrote:
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.

Still got some time before my flasher arrives and I got a little interested in this. So to use the whole 64 byte eeprom I first must change the 31 to 63 in this line?
eepos=(eepos+1)&31; // wear leveling, use next cell

And then I decrease the eeprom array from 32 to 8 byte and loop over it 8 times? Sounds not very difficult to do and will not take that many more bytes in flash.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

guardior wrote:
Mike C wrote:
If RAM space does turn out to be your problem, you could re-write that EEPROM wear leveling routine …

And then I decrease the eeprom array from 32 to 8 byte and loop over it 8 times?

Or you could copy save_state() and restore_state() from blf-a6/tk-otc.c, which already fixed the issue. The array is completely unnecessary, since you can simply read one byte at a time. We don’t really care about speed here, just space. It uses all 64 bytes of eeprom, but only requires 1 byte of global-scope RAM and up to 2 more bytes of local-scope RAM.
Tom E
Tom E's picture
Offline
Last seen: 1 month 5 days ago
Joined: 08/19/2012 - 08:23
Posts: 10899
Location: LI NY

TK - you probably haven't re-visited the Ferrero-Rocher driver in a while, but today I saved a bunch of bytes by taking "inline" off of next_mode() and prev_mode(). Basically if you call a function more than once, chances are "inline" will waste space. I did this to my version of the e-switch driver the other day, and same thing - saved a lot on program space.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

pilotdog68 wrote:
So by ‘enable’ you just mean un-comment it? I prefer to be able to toggle both mode group and memory without disassembly. I also have no problem deleting blinkies.

Basically, comment out the ‘#define CONFIG_STARS’ line. Then make room by commenting out the two strobey modes.

I did some code changes today to make this easier. Also, I found some new ways to reduce the size overall, so it’s possible to put in the full config mode plus one of the two strobes, or full config plus both (with the bike flasher simplified). You can try that version here: http://toykeeper.net/torches/pilotdog68/

In full config mode, it will blink twice for each config option. Turn the light off between the two blinks to toggle that option. There are only two options though, mode group and mode memory (in that order).

I’m still merging changes into tk-otc.c and generally cleaning up, but it should get published in the trunk branch soon.

pilotdog68 wrote:
Another weird question: is it possible to have lvp protection enabled in one mode group, and disabled in the other?

Possible, yes. But there is no code for this right now so someone would need to write it. I think it would be reasonably simple though, just wrapping the whole LVP logic clause inside an “if (modegroup == 0)” or similar.
ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

Tom E wrote:
TK – you probably haven’t re-visited the Ferrero-Rocher driver in a while, but today I saved a bunch of bytes by taking “inline” off of next_mode() and prev_mode(). Basically if you call a function more than once, chances are “inline” will waste space. I did this to my version of the e-switch driver the other day, and same thing – saved a lot on program space.

I tried that, actually. I think it’s a matter of compile options, but for me it made no difference at all in the size or content of the build. But if it helps at least sometimes I don’t mind making it default. Smile

Here is what I see when building it (same with/without inline):

~/src/torches/trunk/ToyKeeper/Ferrero_Rocher/> ../../bin/build.sh Ferrero_Rocher
avr-gcc -Wall -g -Os -mmcu=attiny13 -o Ferrero_Rocher.o -c Ferrero_Rocher.c
avr-gcc -Wall -g -Os -mmcu=attiny13 -o Ferrero_Rocher.elf Ferrero_Rocher.o
avr-objcopy --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex Ferrero_Rocher.elf Ferrero_Rocher.hex
Program:     970 bytes (94.7% Full)
Data:         26 bytes (40.6% Full)

If my guess is correct, the “-Os” option will automatically un-inline everything which has been used more than once.

Tom E
Tom E's picture
Offline
Last seen: 1 month 5 days ago
Joined: 08/19/2012 - 08:23
Posts: 10899
Location: LI NY

Weird - just tried it again, and the difference is 48 bytes saved - 984 with inline, 948 without. I'm using Atmel Studio 6.2, and the -Os option is specified.

This is what 6.2 studio invokes for compiling:

Invoking: AVR/GNU C Compiler : 4.8.1

"C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-gcc.exe" -x c -funsigned-char -funsigned-bitfields -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -Wall -mmcu=attiny13a -c -std=gnu99 -MD -MP -MF "Ferrero_Rocher.d" -MT"Ferrero_Rocher.d" -MT"Ferrero_Rocher.o" -o "Ferrero_Rocher.o" ".././Ferrero_Rocher.c"

ToyKeeper
ToyKeeper's picture
Online
Last seen: 13 min 14 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

Tom E wrote:
Weird – just tried it again, and the difference is 48 bytes saved – 984 with inline, 948 without.

This is what 6.2 studio invokes for compiling:
“C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-gcc.exe” -x c -funsigned-char -funsigned-bitfields -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -Wall -mmcu=attiny13a -c -std=gnu99 -MD -MP -MF “Ferrero_Rocher.d” -MT“Ferrero_Rocher.d” -MT“Ferrero_Rocher.o” -o “Ferrero_Rocher.o” “.././Ferrero_Rocher.c”

Thanks!

The important option there was “-c -std=gnu99”. I added this to my build script and am now getting the same results you are. This also has reduced the size of every firmware I’ve tried so far, so I’m leaving it in as a permanent thing. Smile

This also saved enough room to let the full config mode fit into the blf-a6 firmware without having to remove anything. Big Smile

Pages