a project by gkenion
Project Description
Andúril is an open-source firmware for LED flashlights, which runs on several versions of ATtiny chip. It provides advanced functionality like configurable modes, brightness ramping, safety lockout, etc. via a UI controlled by a single button.
Many Andúril lights are equipped with auxiliary LEDs, often multi-colored, which can be configured to shine or flash when the light is powered off. This can be useful for locating a flashlight in the dark, checking battery voltage, or determining at a glance whether lockout mode is active.
In Andúril 2, the user toggles the aux LED mode by with 7C (7 clicks) of the e-switch. Existing modes are: off low high flashing
Some members of the user community have expressed interest in a medium brightness setting, between low and high. This Hack Week project aims to implement such an option. Users will configure the new setting using the existing 7C toggle mechanism - it will be reached between low and high modes in the rotation.
Goal for this Hackweek
Objective: Add the above-described medium brightness level and test it successfully on production hardware.
This will be my first experience with firmware so I do not know if this feature will require additional effort to implement across different models of flashlight. If I am successful with one model, I will use any remaining time to implement the feature for other models I own. I will make any results of this project available to the community, including code, testing outcomes, research, and any other relevant information.
Results
The objective is incompatible with hardware constraints. This was unexpected, but it makes sense in the context of what I now know about ATtiny architecture and Andúril flashlight hardware.
Details to follow, but first a note about hardware: the device I intended to use for testing is a Noctigon DM11 flashlight. Andúril runs on a wide variety of different flashlights with different designs. Manufacturers differentiate their models by their case designs, optical properties, LED configurations, and driver designs. Despite significant variation in these properties, Andúril devices are homogeneous in the way their ATtiny microcontrollers interact with the rest of the hardware. Even across different versions of the ATtiny controller, implementation is similar and the findings of this exercise are applicable.
An Andúril flashlight comprises the following components:
- Host - the body of the device
- Battery
- Main emitter(s) - the LED(s) producing the device's primary light source. Some lights have multiple channels of main emitters.
- e-switch - An Andúril light uses its power switch to control multiple parameters, even when the main emitter is turned off. As a result, an Andúril light cannot have a power switch that mechanically disconnects the power source. Instead, the MCU accepts input via a button and controls the driver accordingly.
- MCPCB - A metal core printed circuit board houses the main emitters and AUX LEDs, providing electrical connection to the driver and thermal transfer to the host.
- Driver - The main emitters require ample power supply, which must be regulated and modulated according to user input. The driver receives instructions from the MCU and supplies power to the emmiters accordingly.
- AUX LEDs - Some Andúril lights have auxiliary LEDs mounted to the MCPCB and/or inside the switch. These can be a single color or RGB. The user can configure Andúril to illuminate them when the main emitter is off.
- Optics - reflectors, lenses, etc.
Since the AUX LEDs illuminate when the light is off, they tend to remain illuminated for extended periods of time. The user can configure them to high, low, or flashing modes, or disable them. Note the absence of a discrete driver for these LEDs in the list of components above. Using a driver to supply the AUX LEDs would increase their energy usage beyond an acceptable level, so they receive their power supply from the MCU pins.
The pin mapping for the DM11 flashlight can be found in the source file hw/hank/noctigon-dm11/hwdef.h lines 9-30. The DM11 uses an ATtiny 1634 MCU.
PA5, PA4, and PA3 supply red, green, and blue AUX LEDs, respectively. If a light is equipped with RGB switch lights, they run on the same circuits as their AUX counterparts of the same color. If a light has single-color switch LED, The MCU powers it from pin PA2. Andúril controls AUX LED color by illuminating the red, green, and blue in combinations.
To control AUX LED brightness, the MCU needs to vary the voltage supplied to the AUX LEDs. Andúril implements its existing low and high brightness settings by enabling or disabling, respectively, the pullup resistors for the relevant pins. The pullup reistors are not variable - they can either be fully enabled or fully disabled - and each pin has only one pullup resistor. Thus, implementing a brightness level between low and high is not possible with only a software change. Rather, the hardware would also need to be modified.
Unfortunately, this is a terminal blocker for this Hackweek project. I do not have the requisite knowledge or tools to modify hardware in a way that would make the objective possible. That said, I have enjoyed getting acquainted with Andúril and ATtiny, and I feel empowered to pursue related projects in the future.
Resources
My fork of Andúril, for this Hack Week project
Andúril's upstream repository, maintained by a community of developers and flashlight enthusiasts.
This project is part of:
Hack Week 23
Activity
Comments
Be the first to comment!
Similar Projects
Add a machine-readable output to dmidecode by jdelvare
Description
There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.
Goals
Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.
FizzBuzz OS by mssola
Project Description
FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).
This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.
This project is free software and you can find it here.
Goal for this Hackweek
- Better understand the RISC-V SBI interface.
- Better understand RISC-V in privileged mode.
- Have fun.
Resources
Results
The project was a resounding success 
Lots of learning, and the initial target was met.
FastFileCheck work by pstivanin
Description
FastFileCheck is a high-performance, multithreaded file integrity checker for Linux. Designed for speed and efficiency, it utilizes parallel processing and a lightweight database to quickly hash and verify large volumes of files, ensuring their integrity over time.
https://github.com/paolostivanin/FastFileCheck
Goals
- Release v1.0.0
Design overwiew:
- Main thread (producer): traverses directories and feeds the queue (one thread is more than enough for most use cases)
- Dedicated consumer thread: manages queue and distributes work to threadpool
- Worker threads: compute hashes in parallel
This separation of concerns is efficient because:
- Directory traversal is I/O bound and works well in a single thread
- Queue management is centralized, preventing race conditions
- Hash computation is CPU-intensive and properly parallelized
ESETv2 Emulator / interpreter by m.crivellari
Description
ESETv2 is an intriguing challenge developed by ESET, available on their website under the "Challenge" menu.
The challenge involves an "assembly-like" language and a Python compiler that generates .evm binary files.
This is an example using one of their samples (it prints N Fibonacci numbers):
.dataSize 0
.code
loadConst 0, r1 # first
loadConst 1, r2 # second
loadConst 1, r14 # loop helper
consoleRead r3
loop:
jumpEqual end, r3, r15
add r1, r2, r4
mov r2, r1
mov r4, r2
consoleWrite r1
sub r3, r14, r3
jump loop
end:
hlt
This language also supports multi-threading. It includes instructions such as createThread to start a new thread, joinThread to wait until a thread completes, and lock/unlock to facilitate synchronization between threads.
Goals
- create a full interpreter able to run all the available samples provided by ESET.
- improve / optimize memory (eg. using bitfields where needed as well as avoid unnecessary memory allocations)
Resources
- Challenge URL: https://join.eset.com/en/challenges/core-software-engineer
- My github project: https://github.com/DispatchCode/eset_vm2 (not 100% complete)
Achivements
Project still not complete. Added lock / unlock instruction implementation but further debug is needed; there is a bug somewhere. Actually the code it works for almost all the examples in the samples folder. 1 of them is not yet runnable (due to a missing "write" opcode implementation), another will cause the bug to show up; still not investigated, anyhow.