I suppose it’s also that AVRs can be flashed with 2$ USBasp clones or the ubiquitous Arduino.
I don’t know if that has changed but for a long time you absolutely needed a PICkit for flashing PICs (or build your own parport dongle, and IIRC available software was meh, nothing like avrdude)
The LD-x4 looks like it has a PIC on it. Maybe in an effort to discourage us from hacking it 
Many of us who develop firmware are not programmers. We started by copy paste “programming”, changing a little here and there to suite our needs. For me it started with Star v1.1 on the ATtiny13a. Then when we wanted to start adding stuff we knew little about, a few search words here and there helped us out. To get started with flashing we followed excellent guides here on BLF because we didn’t have anyone to help set us up. I think quite a few of us started with this stuff only because of those guides, they are what ignited the interest, at least they where for me.
Then when you’ve done enough programming to make your own firmware you are kind of committed to AVR, not because of the actual programming but because you have a setup for programming and flashing that works. I’m on the ATtiny1634, passed through the 841, 84, 85 and 13a, still using the same flash kit and software that I started with about 5 years ago. The 1634 is more advanced than the 13a, but programing it is basically the same, a few more registers with a few more options, that’s it. I am using the 3217 for a specific project which forced me to get new hardware for flashing but I’m still using the same development software, not a big change at all. Once again BLF provided me with everything I needed to know to get me on the 3217, I probably wouldn’t have looked at it if it wasn’t for yet another excellent guide.
When I started with this stuff, I had no idea what ADC, USART, SPI, WDT, TWI, USI and all that stuff meant. I was unable to make an educated MCU choice, and in terms of flashlight firmware, most of that stuff isn’t used anyway. I think that anyone who would argue which architecture is best for flashlight firmware is biased, essentially it doesn’t make a difference. If terms of actual programming and development, what we are doing is very simple stuff.
I love MSP430, so if you do make something, please share it with us! AVR is ubiquitous and cheap, two traits that are hard to beat .
Really…AVR is not ubiquitous.
It is on the West but not on the East.
Several times we’ve heard complaints from manufacturers that our drivers are hard to make due to the hardness with parts sourcing.
For this reason…AVR is not a perfect choice. But I think the community has too few developers to make supporting multiple architectures worthwhile. And I don’t think there’s a single architecture that would be better enough than AVR to be worth migrating.
There are quite a few interesting non-AVR MCUs out there. They could make our drivers smaller or cheaper or enable some fancy stuff. I’d love to see them supported. But I think that as of now the effort is just not worth it. Especially that porting is not everything. You need to maintain a port over the years. Maintaining is less time-intensive but over long period it adds up. And it’s far less rewarding than porting itself…
Thanks for the response, as it should be noted that ATtiny is not a “ubiquitous” choice for the Chinese companies who design and manufacturer our flashlights. Perhaps they would consider AVR and MSP430 to be equally foreign and strange to use in their drivers.
TI has a large presence in India, so perhaps MSP430 would be more common than AVR there, but I don’t think that’s true of China; they are certainly much more familiar with Chinese microcontrollers.
I mainly meant that AVR is far more common and supported than MSP430 within the computing and electronics communities that most BLF members are familiar with. The Western, English-language Internet is all I’m really able to know much about. From that perspective, the AVR product line is quite “ubiquitous”, even if many people only know about Arduino.
In the West, the word “Arduino” has typically been synonymous with a handful of ATmega products. That is changing as Arduino is ported to other architectures, but it was true for at least a decade. Chinese companies have installed millions of ATmega168/328’s onto generic Arduino modules, but those products were intended for export to the West. Chinese manufacturers didn’t use AVR chips in their products, but instead preinstalled bootloaders onto them for us to use.
To be fair, there also exists an MSP430 port of the Arduino IDE called “Energia”, but I’ll bet few people have even heard of it.
TK.
Strange behavior of Candle mode in Anduril.
After uploading to fw3a Anduril with some of the modes removed, the candle mode doesn’t work too “smoothly”.
Every now and then, the brightness does not change smoothly, it just jumps up or down. Once a few steps up, one time down. I didn’t have this problem on the stock firmware. I also checked on the D4 driver and one that I built myself. It’s the same on them. I didn’t change the fusebits. I just removed “blink at ramp middle”, “bike” and “tactical” strobe.
I recorded the movie. This appears in about 20s, 27s, 45s, 1m22s, 1m46s
TIP: How to set up an ATtiny dev environment on Fedora, RHEL, CentOS and derived:
some package names are different ...
$ sudo dnf install flex byacc bison gcc libusb libusb-devel glibc-devel
$ sudo dnf install avr-gcc avr-libc avr-binutils
$ sudo dnf install avrdude
:BEER:
- SAM -
Edit: other 'related' I've installed are: $ sudo dnf install avr-gdb gcc-c++ git patch wget texinfo zip unzip make bzr
Thanks. I added that to the repository’s README file.
I’m curious what dnf is though…
… *<i>looks it up</i>* …
Oh. As wikipedia says, “DNF or Dandified YUM is the next-generation version of the Yellowdog Updater, Modified (yum)”. I hadn’t heard about yup v3. The last one I heard about was yup v2.
Anyway, uh, funny story… or maybe an apology. I must apologize for Red Hat’s package manager. It was kind of an accident.
I was trying to get Yellow Dog to switch to Debian as its base system instead of Red Hat (because of a bunch of reasons)… but the owner of the company really didn’t want to, and didn’t seem to understand the differences except that Debian had a package manager while Red Hat did not.
So the next time I visited, I found that my friend there had started writing a clone of apt (Debian’s package manager), called yup (Yellowdog UPdater). And the company needed help to get its next release out, since it was already months overdue and nowhere near ready. So I ended up building an OS installer for them. My friend who started yup got fired though (another ridiculous story there), so I inherited it. I ended up having to finish it, at least enough for the first release. I even made a GUI/TUI front end for it. But I was kind of ashamed that it existed at all, and refused to put my name in its credits file.
Eventually we got the distro and its brand new package manager to a release-able state though, the entire dev team and their manager got fired (another ridiculous story), and the OS was released. Without a dev team though, not much happened with it afterward.
It should have died there. The next major release didn’t include any of that stuff; it just went back to being a port of Red Hat without any significant extras.
But someone revived it. They liked yup so much that they dug it up from its grave and took over maintenance, calling it “yum” or “Yellowdog Updated, Modified”. And it became part of Fedora. After most of a decade, it finally even had some of its larger bugs fixed.
Looks like it’s now having its third life in the form of “dnf” or “Dandified YUM”.
It really should just be using apt though. There was even a promising-looking rpm-compatible version of apt in the works for a while… but it seems to have died off because of yum. 
So, um, … sorry about that.
Interesting ... Thanks TK!
Just noticed I forgot to add "libusb"
sudo dnf install flex byacc bison gcc libusb libusb-devel glibc-devel
- SAM -
Ah. I know exactly what that is.
The candle mode is implemented as a 3-oscillator synthesizer, where the three oscillators are modulated by three other oscillators. The output is the sum of all three plus the user-configured base brightness.
The three oscillators run at three different frequency ranges, so it makes relatively complex patterns. But some parts, like the amplitude, are totally random. So, sometimes the oscillators have their amplitude set to zero, which makes it stop flickering.
What you showed there is how it looks when the slowest wave is running but the two faster waves are stalled at zero. Normally, with one or both of the faster waves going, it gives the appearance of having really smooth curves… but the resolution is actually pretty low, and the individual steps can be seen when it changes very slowly.
Additionally, it uses the ROM itself as one of the sources of erratic data, so the behavior changes slightly with each different version of Anduril. Change anything at all in the code, and it changes the ROM, so it slightly changes the flavor of all modes which use random values. It also changes based on temperature and battery voltage, though it’s mostly just using the noise from those readings, not the signal. Regardless, it behaves a little differently as the ambient temperature changes or as the battery drains.
But mostly I think you’re seeing the “bass frequency” wave by itself, without the higher frequencies mixed in.
For a more detailed look, I graphed the actual output over time. It shows the bass wave more clearly than it would normally be perceived by eye.
I’ve been tempted to do something fancy to smooth out the brightness curves more, using the “gradual adjustment” code it uses for thermal regulation… but actually doing it has proved more complicated than I hoped. It seems difficult to do without significantly increasing the code size. If completed though, it would allow the animation to hit PWM levels in-between ramp steps, and higher resolution would look smoother.
Zhang from Neal’s Gadgets said that the Andruil firmware shipping with the FW3A is the 5-22 version. To me, reading the code history, it seems like the memory mode was made standard on 6-2. Is this correct?
Also, what is the lowest lumen output one can expect from Andruil in an FW3A running Nichia 219Cs?
The manual memory thing was added after the current batch of FW3A drivers was made. It’ll probably be in a later batch though.
About the lowest lumen output, it’s pretty random due to hardware variance, but usually about 0.1 lm to 0.3 lm.
I noticed something unexpected with the Crescendo firmware: mode memory includes the hidden modes. So if I check the battery, turn the light off, turn it back on, it comes up in battery check. Is that intentional?
And if you turn it off while it’s ramping, it memorizes that it was ramping! That seems even less likely to be intentional…
TK, I see that you merged Attiny1684 support. Nice. 
I notice there’s are new compiled Anduril .hex files (dated 08-05-19 for most flashlight builds now.
Are the changes (eg. the newly added “reset” function) also included for the other flashlight builds (eg. the BLF Q8)?
(sorry but I’m not familiar with reading the code… I can only flash hex files on my Q8)
Yes, that’s intentional.
Memorizing that it’s ramping is a side effect of how that was implemented.
I’ve been meaning to redo Crescendo at some point, to make it more intuitive, but I’ve been too busy with other things. Was going to make a nicer updated version for the Reylight Dawn, but Rey went with Texas_Ace’s version of Bistro instead.
There are some new builds from 2019-08-05, but not from 2008-05-19. The dates are in ISO 8601 standard format, YYYY-MM-DD.
Yes, the recent stuff is included. For full details of the changes, I’d suggest reading the history on Launchpad.
I told Rey having you do that firmware would be better, if you were on board I am not sure why he didn’t let you update it.
Yeah, that whole situation was pretty confusing. He changed his mind a lot, and we never knew what to expect from day to day. I’m still not sure what exactly happened or why.
In any case, Crescendo has some weird quirks which should probably be fixed eventually.