Flashlight Firmware Repository

I think your knowledge of coding and all the driver stuff exceeds mine by far

I won’t even bother to mess with job 2 ATM

Anyways, I did this out of interest and for the purpose of learning something, maybe. I would be surprised if it works and if I’ve done it right. I have no e-switch host to test it.

But maybe it’s a starting point for someone who knows what he’s doing: :smiley:

diffcheck job1

EDIT:

I am sorry for posting such crap. This doesn’t even compile right. I had
#define TURBO 245
in there, and at least it compiled. Must have taken it out before posting. But anyways, it doesn’t work, I’ve tested it, goes 245 on channel 1 instead of driving the FET…

I recommend github.com for sharing code. That way if you need to make a change you always have the version history to go back to.

In hopes it’ll help me actually get stuff done, I posted my todo list at the beginning of the thread:

Help and encouragement are welcome. :slight_smile:

The repository is currently using bzr + Launchpad instead of git + Github, but migration is still possible if a majority of the people involved want to switch.

I realize git won the DVCS wars, so bzr is definitely not the most popular choice. Launchpad now supports git though, so it’s also possible to use git without actually moving to Github.

As for Launchpad vs Github, many of their features overlap but Github is organized per-person while Launchpad is organized per-project, Github has some wiki-like features, Launchpad has much more extensive bug/task tracking, and there are a variety of other significant differences.

In any case, the options are on the table but would need a majority in favor. So far, there has been very little interest in revision control and project management tools, so I’d be happy with pretty much any system as long as people used it. I’d much rather review merge proposals instead of pulling files from forum posts, pastebins, and dropboxes…

I’m an avid github user. All my personal code is on it and all my code for work is on it as well. I’m biased, but when I found the Launchpad site it took me too long to find the source code. To me that’s the number one feature of a code repository - SHOW ME THE CODE. With Github a project might be under a user, but there’s no limit to the number of contributors you can have. Also it’s distributed so anyone who wants to do their own thing can fork off of the main repo and it doesn’t affect that main repo in any way. Maybe the code gets merged back in, maybe it never does. Github also has organizations (that are free to create) for projects that turn into a real community effort. A lot of projects that start out under one person’s account get transferred to an organization as they take off.

That’s just my opinion but I haven’t actually contributed any code yet so I consider it fully without merit or standing. I’ve got a lot of ideas though, and debuggers recently delivered and a sack of Nanjg 105c’s on a slow boat from China headed my way. I’m fully cognizant that there’s nothing you can’t do on Github, Launchpad, Gitlab, etc and I will get source code from wherever the developer chooses to share it. When I have something to share I’m putting it on Github.

From what I recall of its early days, Github started as a simple place for individual people to share git repositories. Other features were added later but weren’t as deep a part of the overall design. So, it excels at “show me the code”. Launchpad was designed more as a full-featured large-scale project management platform and a replacement for older systems like Sourceforge. Designed specifically for facilitating Linux distro development with thousands of contributors and complex relations between individual component projects built together into a whole. Its broader focus makes the code somewhat less front-and-center.

Both are good tools, though their styles are very different.

Git and bzr are functionally and conceptually almost identical. The main differences are a matter of interface. However, there is one significant conceptual difference — bzr has a concept of a “mainline” but git does not. This explains some of the consequences of that: Merging in bzr: The git approach vs the bzr approach

In common usage, git is dramatically more popular. They use different terms for the same concepts, which can be confusing. Git puts all the heads or tips into one directory while bzr defaults to one directory per head and one head per “branch”. Git prefers to wrap or reimplement common tools for use on a single directory while bzr encourages using stock tools on separate directories. Bzr supports git as just another pluggable storage back end. Git favors fast-forwards and implicit merges, while bzr favors explicit merges.

For BLF purposes, the technical differences are mostly unimportant. It’s primarily a matter of what the participants want to use.

Soo, the attiny25/45/85 has a useful extra feature (not available in tiny13) that I’ve been meaning to bring up. Tiny25/45/85s can measure their 1.1v bandgap reference. And this is really useful to us because by setting the ADC reference to vcc and measuring the 1.1 bandgap we can calculate the battery voltage. Of course it’s backwards from how measurements are normally done (use a known reference to measure an unknown) but it doesn’t matter.

Looks like setting REFS[2:0] to 0bX00 will select vcc as ADC reference, and setting MUX[3:0] to 0b1100 will select the 1.1v internal bandgap as the voltage to measure.

Apologies for letting time slip by, not bringing it up sooner.
I would have posted this in the attiny25/45/85 thread but it seems to be occupied with other things at the moment.

Hmm, interesting. So if I understand correctly, we could free up a pin and maybe remove two resistors on 1-cell tiny25/45/85 drivers? And this wouldn’t work on zener-style drivers because VCC is artificially capped?

In exchange for freeing up a pin and potentially removing a couple components, the voltage resolution would be decreased somewhat… but we’re already getting ~4.5 ADC units per 0.1V, so we have some resolution to spare right now. And it’s currently only using 8 of the 10 available bits of precision anyway.

Is this more or less correct?

Yep. I think the greatest benefit might just be gaining a bit more room on the 17mm single sided pcb. Since it sounds like we need to add components to get better stability. Small decoupling cap, FET gate resistor and/or pulldown.

Any takers? PM me. I’m offering $10 for Job 1 and $15 for Job 2 if they work. I think there should be a fair amount of crossover between the two.

I’ll do it freely if you’re not in a hurry (I have a busy week ahead) and are willing to accept that you might flash a few buggy revisions. I just got my AVR programmer working and it’ll be a change from trying to hack something from scratch, which I’m certain will involve spectacular failure at some point :slight_smile:

Part 1 seems pretty clear but about part 2, do you mean dual-pwm as in the STAR momentary, with ALT_MODES driving pin 5? Does that mean you also need PWM mode selection? I’ll post back in your driver thread once I get around to getting something done.

I’m happy to help as much as I can testing revisions, I just need someone’s help that understands this better than I do.

Both should have pwm options for pins 5 + 6 (like star momentary already does) plus toggle pin 3 for turbo and such. Really exactly what DEL did to blf-a6 for me, but versions for momentary and dual-switch lights

Dual-pwm was really overdue for STAR dual-switch anyways, but JohnnyC just didn’t see the demand for it I think

Fyi, Halo asked me if I was disabling the AtoD upon sleep mode in my Narsil version, and noticed I wasn't (same as STAR Momentary). So I added turning OFF the AtoD during power sleep mode and it cuts parasitic drain in half -- big gain for a small easy mod in the e-switch firmware we commonly use.

So, the STAR Momentary and Ferrero-Rocher both do not have this disabling of AtoD from what I can see, unless there's something I'm missing. Post #789 here has the sleep_mode code. Post #790 here has the result of using 10X values for the R1 and R3 - reduces parasitic drain by a factor of 10. I think this resistor mod needs more testing and review, because it sounds technically it's out-of-spec of the Atmel MCU's, and I'm not sure it can be used with 13A's.

It’s not a hard spec like the allowed VCC or frequency range (and even these can be stretched). What I could find in the 13A’s doc is:

The way I read this is that you can use larger resistors but the ADC will not run as quickly, which we don’t care about at all.

Ahh, that's interesting... So sounds like a pretty good solution for us. If reducing parasitic drain is important to you, then for our e-switch based lights with our custom firmware, this option of using 220K and 47K resistors is the way to go, combined with modding the code to turn off AtoD during sleep mode.

In my tests, I measured from 0.314 mA originally, then with the mods down to 0.016 mA, about a 95% drop.

I am also not sure how much the MCU reading the ADC will affect things when you are using resistors that are that high of value.

I haven't tested values this high myself on the drivers so this is just a guess, but I am predicting much lower precision overall if you go to 10x higher values.

Also, remember that higher values affect MCU turnoff times when you cut the power. This won't matter much for momentary only, but for any clicky setup it is something to keep in mind. It may not be an issue, and you may be able to compensate for it in other ways, but it is something to keep in mind.

All I did was simple tests of a cell at 3.6v and one at 4.1v and my firmware blinked out the correct voltage. Need to do a lot more testing, but I've never done calibration to begin with. I've found accuracy though to be pretty good, within 0.1v for the most part using the tables TK had, think from Dale's measurements.

Edit:

Did more tests of various cells, various levels:

Voltage Level Blinking

Actual Voltage (DMM)

18650 cell

4-1

4.12v

AWT 2500

3-5

3.505v

HE4

2-8

2.811v

Sam 15M

4-2

4.21v

30Q

4-2

4.18v

MJ1

4-1

4.14v

MJ1

2-8

2.776v

15M

2-7

2.725v

15M

2-7

2.691v

15M

It's about as good as any of my other e-switch lights.

Maybe calibration is more important when using higher values. With the calibration and using 10 bit values from the ADC I have very good accuracy. Without calibration it was good enough until I bumped into that MCU with a lower internal reference voltage.

As I have E-switch and off time cap on the same pin as the voltage divider I perhaps pay more attention to what is going on. I wrote a debugging routine that blinks out X.XX volts and I want it to be as accurate as it can be. I use real voltage values for off time measuring so the off times are calibrated with the voltage calibration. It was easier for me to see what happens with off times when checking with full and depleted cells, during different temperatures and how the voltage monitoring and off time cap charging behaved during E-switch presses and so on.

I guess for “normal” use you want need calibration, but when using these three functions on the same pin I got much better consistency if I calibrated the internal reference voltage, at least for MCUs that have unusually low/high internal reference voltage.

I think the plan is to also go with a new driver layout which adds an explicit OTC drain resistor, and probably a bigger OTC. That should help eliminate dependence on voltage divider parasitic drain.

Or use the higher-value resistors on boards which don’t care about OTC, like the fancy lighted tailcaps. If it can sleep at 0.01mA instead of 0.30mA, that’s a huge bonus for tailcap use.

So… you know how I’ve complained about not knowing how to support Windows? And how it takes pages of explanations with several screenshots to show how to do something that would only take a few short commands on a unix system? Apparently this sort of thing is so common that Microsoft decided to support unix instead of expecting unix tools to support Windows.

Windows 10 is getting the ability to natively run unmodified versions of Ubuntu. In today’s “insider preview” version, it already works.

This means that, even in Windows, you should be able to do flashlight firmware development with a few simple commands. For example, to get the tools, compile something, and flash a driver, you should be able to do something like…

  • Enable the new “Windows Subsystem for Linux” feature.
  • Click the ‘bash’ icon, or start a cmd.exe shell and type ‘bash’.
  • In that shell, run a few commands:
    • apt-get install bzr gcc-avr avr-libc binutils-avr avrdude
    • bzr branch lp:flashlight-firmware
    • cd flashlight-firmware/ToyKeeper/blf-a6
    • …/…/bin/build.sh blf-a6
    • …/…/bin/flash.sh blf-a6.hex

You don’t even have to type some of it, because pressing <Tab> will auto-complete a lot of things, and the <Up> key recalls previous commands. After the first time it’s easier since you already have it set up (assuming Windows saves the state instead of installing a fresh OS each time).

It’s only a preview so far, but once it’s a little more mature I hope this will make things easier for everyone.