Flashlight Firmware Repository

[Tom_E]

Yea, you can combine them like that - should be fine. I've been splitting them out, because it's not necessary to re-do fuses usually, but I may dnld new firmware dozen or more times in a day/eve.

[pilotdog68]

So when I compile my bistro file, I get this:

Program Memory Usage : 50 bytes 2.4 % Full

Data Memory Usage : 0 bytes 0.0 % Full

….that can’t be right

Sorry to be such a leach, but I’m lost again. How many .h files am I supposed to have? I thought it was just “tk-calibration.h” which I merged into my .c but I’m getting a million build errors.

[Tom_E]

ouch, no. Are u using Studio 7.0?

Like an #ifdef is missing an #endif or something. If you have an #ifdef that's not true, and no closing #endif, it would comment out a whole lot of code.

There should be 5 .h files

[pilotdog68]

@Tom E

ouch, no. Are u using Studio 7.0?

Like an #ifdef is missing an #endif or something. If you have an #ifdef that’s not true, and no closing #endif, it would comment out a whole lot of code.

I edited my above comment. I restarted atmel studio and now I get a few dozen build errors. Looks like I’m missing .h files

[Tom_E]

#include "tk-attiny.h"

#include "manker-calibration.h" (or equivalent)

#include "tk-delay.h"

#include "tk-voltage.h"

#include "tk-random.h"

Sorry, fonts all screwed up!!

[pilotdog68]

thanks

[ToyKeeper]

@pilotdog68

The S8 in my signature is a decent example using multiple emitters.

Okay, FET+3 for white plus 2x7135 for red out the front.

If you can sort those into a single ordering, the bistro code should still work fine and you’d only have to tweak the ramps to handle red-only and white-only modes. Or you could treat the white-only modes as a normal ramp and have the red-only and combined modes as specials, in which case it would step down from a special mode to a white mode.

My first inclination is something like…

// red channel
#define RAMP_7135 5,50,255, 0,0,0, 5,50,255
// white
#define RAMP_7135s 0,0,0, 40,255,0, 5,50,255
// white turbo
#define RAMP_FET 0,0,0, 0,0,255, 5,50,255
// where does each mode step down to?
// (for LVP, overrides simpler ramp-based logic)
PROGMEM const uint8_t stepdowns[] = {
    0, 0,1,2, 1,4,5, 1,7,8
};
// name each mode for convenience
#define R_MOON 1
#define R_MED 2
#define R_MAX 3
#define W_LOW 4
#define W_MED 5
#define W_MAX 6
#define RW_LOW 7
#define RW_MED 8
#define RW_MAX 9
...
// comment this out because we don't have a smooth ramp
//#define SOFT_START
...
// blink out voltage and stuff using only the red LED
#define BLINK_BRIGHTNESS R_MED
...
PROGMEM const uint8_t modegroups[] = {
    R_MOON, W_LOW, W_MED, W_MAX, R_MAX, 0, 0, 0,
    R_MOON, RW_LOW, RW_MED, RW_MAX, 0, 0, 0, 0,
};
...
// TODO: rewrite the LVP logic so it steps down to whatever the stepdowns array says

Is that making any sense? I think you’ll probably have to define explicitly how each mode reacts to LVP by setting the mode it should step down to. That way you get just red going dimmer until it shuts off, just white going dimmer until the final step (which turns red), then shuts off, and the combined output also staying combined until the last step. This will involve rewriting the LVP logic, but it shouldn’t be very hard.

Also, bistro doesn’t have a “tap to bump back up” like blf-a6 did for turbo. That could be added in the LVP logic though, by setting mode_idx and adding a “save_mode();” after each step-down. This isn’t done by default because it’s complicated, but in your case it should actually be much simpler. (complicated because “mode_idx” gets converted one-way to “output”, which isn’t necessarily the same as “actual_level”, so it’s tricky and the matching mode_idx value might not even exist)

Oh, and you’ll probably need to disable thermal regulation too, or rewrite it.

…

Thinking about it more, you could also get rid of the whole “stepdowns” thing and just reduce mode_idx by one at each step down, which would automatically go backward through the modes in the current group. That’s probably simpler and better, if you don’t mind it “stepping down” from 100% red to 100% white in the first mode group. Otherwise, the method I suggested would step down from 100% red to 20% red, then to 2% red, then off. Even though the mode group doesn’t have an entry for 20% red (which makes stepping back up awkward, since the required mode_idx value doesn’t exist).

@pilotdog68

Even with a single emitter though, I tend to gravitate towards this mode set:

1. Moon-ish (3 pwm level on single 7135)
2. Low (roughly 50ma)
3. Medium (100% on bank of 7135s)
4. FET turbo.

That’s much easier. You should only need to modify the modegroups array, assuming the ramps already have the levels you want somewhere. It’ll still allow soft start to work, and smooth LVP and thermal regulation.

@pilotdog68

1. LVP will step down if I’m already in a non-turbo mode, but won’t pull it out of Turbo. Also, once stepped down from medium to low, it glitches if I try to bump it back up, usual getting stuck back in Turbo. I rarely let my cells get very low, so I didn’t even notice this till recently.

2. The turbo timer works fine on some builds, but not on others. So far I haven’t identified the pattern of why it works sometimes.

1. Should behave completely differently in bistro, since the LVP code there is different. Plus, it sounds like it’ll need a rewrite for your purposes anyway.

2. Not sure what’s up with that. Bistro doesn’t have a concept of “turbo” though; just thermal regulation and LVP. So, that’s potentially either better or worse, depending on how you look at it.

[ToyKeeper]

@Texas_Ace

While you are in here TK, quick question. I have some 105C drivers laying around that I want to use up. I would like to put the A6 firmware on them, is it as simple as simply zeroing out the 7135 channel in the modes section and putting my desired modes all in the FET section? I don’t see any reason it wouldn’t but I have not messed with the A6 firmware yet.

It would run into issues because nanjg drivers don’t have an offtime capacitor. Otherwise though, should be fine.

So, no medium-press on those nanjg drivers. And you’d need to use the SRAM decay (noinit) trick to detect short versus long presses. And at that point you may as well use biscotti instead, since it’s like blf-a6 but with more mode groups. Er, unless you still want turbo step-down, which biscotti doesn’t have.

Personally, I like “s7” on my nanjg-like drivers. It’s old, and the code is awkward, but it gives me a bunch of fun blinky modes after the primary output levels.

[ToyKeeper]

@Wildcat

I’m trying to compile biscotti firmware, but I get the file size of 1026 bytes (100.2%).
…
avr-gcc -Wall -g -Os -mmcu=attiny13 -c -std=gnu99 -DATTINY=13 -I… -I…/… -I…/…/… -o biscotti.o -c biscotti.c

You might need a newer (or older?) version of avr-gcc. I built biscotti (1024 bytes) with gcc-avr 1:4.7.2-2 from Ubuntu. But I tried again just now with 1:4.8.1+Atmel3.4.5-1 from Debian, and it came out to 1032 bytes. And some have reported building it smaller with some versions of AVR Studio.

It’s a bit frustrating seeing the differences between gcc versions when a program is right at the limit, but I don’t really have a good solution other than trying a few versions and going with whatever makes the smallest result.

[ToyKeeper]

@Tom E

… according to TK’s header in bistro.c: …

I’m bad about keeping the header comments up to date. The bin/flash*sh scripts are a more reliable source of info about this. Currently, flash-25.sh says…

avrdude -c usbasp -p t25 -u -U lfuse:w:0xd2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -Uflash:w:foo.hex

[ToyKeeper]

@pilotdog68

Looks like I’m missing .h files

Sorry for all the headers. The same code kept getting duplicated in every project, and they kept getting out of sync with each other, so I moved them into a central area as modular includes. I tried to avoid making things very complicated though, so it still is vastly simplified compared to how most regular software is built.

[Wildcat]

I changed version of avr-gcc to 4.9.2 and now it compiles OK. Thank you.

Size is exactly 1024 bytes.

[Texas_Ace]

@ToyKeeper

It would run into issues because nanjg drivers don’t have an offtime capacitor. Otherwise though, should be fine.

So, no medium-press on those nanjg drivers. And you’d need to use the SRAM decay (noinit) trick to detect short versus long presses. And at that point you may as well use biscotti instead, since it’s like blf-a6 but with more mode groups. Er, unless you still want turbo step-down, which biscotti doesn’t have.

Personally, I like “s7” on my nanjg-like drivers. It’s old, and the code is awkward, but it gives me a bunch of fun blinky modes after the primary output levels.

Great, I figured I could add an OTC to the stars like people used to do. Or biscotti is actually a pretty good option as well, I like long presses though.

[ToyKeeper]

Oh, if you add the OTC, it should be fine. You’ll probably have to calibrate the OTC timings though.

[pilotdog68]

Ok friends, what am I doing wrong?

These are all unedited files, just straight from the repository. As you can see they are in the same directory, opened in the same application in Atmel7, and yet it compiles to 50 bytes. What am I missing?

[Tom_E]

Can you ZIP up your entire solution folder, all subfolders included and post it somewhere? I could try it here.

Or TK writes super tight code?

Wait - what is that main thing doing there? Delete it. Probably it's using that and ignoring bistro.

Or... Show me your Solution Explorer break out. Should be on the right hand side of the screen? It lists all the files in the project.

The way studio works is there's a solution, then a project must be added to the solution. The source code must be added into the project.

[pilotdog68]

@Tom E

Can you ZIP up your entire solution folder, all subfolders included and post it somewhere? I could try it here.

Zip Link

So I’m not missing something basic here?

[Tom_E]

Sorry, got too late for me last night. Look'n now. This is just the source code file. Did you modify anything in these files, or is this straight from downloading?

The ZIP contains only the source files, no solution file (.atsln) or project file (.cproj), so I can't attempt to reproduce what you have there. I'd like to see the complete set of files, or a screen snapshot of the expanded out solution, in "Solution Explorer".

I just noticed I have the complete bistro tripledown ATMEL Studio 7.0 solution/project ZIP'ed up and posted on my google shared drive. Here's the link:

https://drive.google.com tripledown AS7.zip

If you download this one, unzip it, and open it up with Studio 7.0 it should work - works well for me. In fact I just dnld'ed it at work, where I have 7.0 installed. Opened it up and did a "Rebuild Solution", and it worked perfectly:

Program Memory Usage : 1976 bytes 96.5 % Full
Data Memory Usage : 28 bytes 21.9 % Full

[pilotdog68]

Yes, they are the unmodified files straight from the repository.

Normally (for attiny13’s) I open Studio 7, create a new project, paste in my code from my wordpad docs, then build it. Then grab the Hex from the output files.

This time I put the header files in a folder, opened a new project, pasted the code into the project, saved that .c to the same folder as my header files, and told it to build.

I don’t think I have ever seen a .atsln file, and Studio 7 doesn’t even have the option to “save as” for the project file. I tried dropping my headers into the folder where the project file lives in Atmel’s directory, but it didn’t make a difference.

So what step am I missing?

[Tom_E]

I can't tell - need all the files. You must choose the processor somewhere I think? I don't do it that way - I copy an existing solution/project, then go from there. This way I know it's all properly configured, proper settings, etc. Starting from scratch you have to make sure everything is configured properly per MCU, optimizations, etc.