alexvh's firmware. Update: Hidden strobe, Ramping and optional mode memory added.

Yea I get what they are, PIC used them in EVERYTHING (MPLAB 8.x) but you have to manually add them to the project tree. So in AS6.2 you don’t have to do anything at all but name them and the compiler handles looking them up?

Sure. I’ve never had to do anything manual to get includes working… in Atmel Studio, in other IDE’s, on the CLI, etc… it’s strange to me that MPLAB requires you to do something special to get includes to work… but sure enough, Google shows exactly the kind of thing you are talking about… Set The Include Directory Path - Developer Help

Just bumping the thread so people can see my update at the top. Ramping and optional mode memory added to firmware.

Thanks, I’ll take a closer look very soon!

Thanks. I’ll give this a run through AVR Studio to see if I have the same problem as before.

I’m hoping that problem was fixed by making the variables that are held after a power off volatile. It should prevent the compiler from doing optimizations that stop the trick from working.

I tried this on a different driver, a FET-based one designed by BLF members. It works! The lows aren’t low enough on a FET, and the ramp shape is a little weird, but the off-time memory seems to work as intended.

I will probably try using this technique on some of my non-OTC lights, since it seems like a solid improvement over “short-cycle” on-time memory.

Also, I added this code into my repository, linked in my sig below. Thanks for making it GPL! :slight_smile:

FWIW, I adapted this technique into my brass-edc.c firmware just now, and it seems to work well.

Additionally, it reduced the size of the ROM by 262 bytes! Now I have more than a quarter of the ROM to play with if I want (it went from 1018 bytes down to 756). This method allowed me to remove everything related to the WDT, eeprom, wear levelling, and the “short cycle” memory bit.

It’d be better if it could detect short/med/long presses instead of just short/long, but it’s still a big improvement over on-time memory. :slight_smile:

(I’m particularly happy about this, because I wanted off-time mem on this light but it doesn’t have enough room to add a capacitor and still be able to reflash it or fit a battery)

I found short-cycle still useful with off-time memory: have memory, but no need to cycle through all modes.

Could you elaborate on that?

I could see short-cycle being really useful for lights which are configurable via button presses, or as a shortcut back to mode 0 when “long press” isn’t mapped to that. Or generally for increasing the inputs from “long/short” to something deeper… “short(off)-short(on) / short-long / long-short / long-long”. But I don’t know specifically what you do with it.

With normal (off-time) memory, a tap cycles through all modes, while with short-cycle (off-time) memory, a single tap restarts at the first mode, and only consecutive taps switch through the modes; i.e. long-off -> memory; long-on, short-off ->mode 0 ; short-on,short-off ->next ; (and I actually found it comfortable to additionally have long-off, short-on, short-off -> mode 0, too).

Okay, that makes sense. I pretty much always prefer no memory on clickies, so I have “long-off -> mode 0” and “short-off -> next”. Or for on-time memory, “long-on,tap -> mode 0” and “short-on,tap -> next”. I haven’t ever felt a need for both.

The main thing I change with an off-time cap is to add a “medium-off” action, which either goes to the previous mode (if mode > 0 ) or to a sequence of hidden modes (if mode <= 0 ). It’s nice as a shortcut to turbo or battery-check.

For e-switches though… memory can be pretty nice. From off I’ll usually do “long-press -> moon”, “short-press -> memorized mode”, and “double-press -> turbo”. I like the instant access to all three.

You can of course just ramp up linearly by incrementing the pwm in a loop with a delay, I might add this. I used an array because I liked the smooth ramping, you can tell when you are near the max or min brightness because it is increasing or decreasing more slowly (also, I just think it looks cool). You might prefer the SQUARED ramp profile. If anyone has any ideas for different ramping profiles I’d be interested in trying them. Or if someone wants a different min or max in the ramp I could add that to the firmware.

On that topic, see ramp_calc.py and Ramping_UI_table.c in my firmware collection:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/Ferrero_Rocher/

It implements a few different ramp curves, but it requires an e-switch to work properly. My favorite is logarithmic, but cubic is closer to visually-linear. Also, it can optionally smooth out the lowest few levels by using PFM in addition to PWM, but this extra-low part of the curve has a different shape than the rest and is intensely voltage-sensitive.

I haven’t attempted to do ramping on a clicky switch light, because the interface is awkward and I didn’t like the idea of grinding through eeprom write cycles while it ramps. You solved the eeprom issue, but the UI is still a concern.

Anyway, I’ve been playing with my new no-OTC off-time light (ToyKeeper/s7/brass-edc.c) for a couple hours now and I’m really happy with it. Thanks!

Tested fine compiling with AVR Studio.

Flashed to a 105c, works fine.

:beer:

Hm, it seems I have to try again on a different driver, as I found it too short when I had tried, and I'm not a slow 'half-press'er :)

Edit: Tried again, indeed works well. Must have tried it with some old drivers with slight differences, don't know. Oh my, I could have had that months ago. /edit

ToyKeeper: Yes, for momentary buttons most of my firmwares allow switching on directly to memo/moon/max, too. For Clickies I like no-memory and short-cycle memory: My EDC (currently the brass, too) I have 2 groups, one for normal use with moon/L/M/H with (short-cycle) memory, so I don't have to click to the right mode every time, and one with moon1,moon2,lower,low,med without memory for indoor night time, always comes on at lowest, so it doesn't disturb anyone.

I'm trying to flash the brass-edc firmware, but I'm getting the following verification error;

avrdude: verification error, first mismatch at byte 0x0000
0x00 != 0x0c
avrdude: verification error; content mismatch


I've compiled it, as well as trying your .hex file.

Command line;

avrdude -p t13 -c usbasp -u -Uflash :w:brass-edc.hex:a -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m


I have stars 3 & 4 grounded, but I don't think that would interfere with the process.

Any idea what's going on?

all you coders are AWESOME!!!

Gotta try the ramp on my triple build where I attempted to tweak the code and now the darn thing only starts in moon mode :frowning:

You coding genius are incredible!

That sounds like what always happened before I switched from a 5-wire connection to a 6-wire one. I could flash (sometimes), but the verification step would always fail.

I doubt stars 3+4 should matter, assuming they’re on pins 2 and 3. The flashing process uses pins 1/4/5/6/7/8 but not 2/3. However, it could still potentially be an issue. I’d suggest double-checking the other six pins though, in case one isn’t making full contact.

My command line is in flash-noinit.sh:

  #/bin/sh
  FIRMWARE=$1
  avrdude -c usbasp -p t13 -u -Uflash:w:$FIRMWARE -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m

The only differences I see are a space after -Uflash, and a :a after the firmware file.

Thanks. It appears it was a connection problem. I just tried again now, & it flashed fine.