Default values “out of the box” are the same. Mid for main mode, High for additional one. However, they can be set separately for every UI (preset), because they are stored in memory separately.
No, I can’t. Every non-essential entity has been thrown out for the sake of simplicity of interface, while keeping flexibility. That’s why everything has to be done through slots.
Yes, exactly.
They are automatically saved to the workspace (Basic UI) in to EEPROM. Additionally, they can be copied to the one of three available presets. However, I want to change that logic to just four presets, which can be simply selected. Without any loads and saves in to workspace.
Stored in RAM. Only changes are written to the EEPROM and only during shutdown. That way load on EEPROM is reduced. Memory of modes wears the most, if it is used with ramping. One write operation for every shutdown, if brightness has been changed during operation. However, Unicorn has delayed shutdown, so when you switch something through shutdowns, it doesn’t count.
100’000 cycles – stated durability. In fact, it could be 3’000’000. I thing flashlight will be reduced to ash earlier.
I drink cider :).
Yes, I have estimated amount of #ifndef. How to debug that?
Also I’ve spent some time searching for entry point ( main() ), until I realised, that this project has loop()… Arduino?…
I have such interest in that question for the following reason. I’m interested in combining my Indigo with your Anduril, if it is relatively easy to accomplish. We can take familiar to people here front level of interface, and place it on top of good system algorithms, that allow to create good linear regulator on the same FET. It will be even cheaper and more compact than existing solutions on AMC7135+FET. Writing interface on assembler is perversion, but necessity, because it is not clear, how to implement system part on C. And that slows project down, because everyone is afraid to use assembler. And I can’t always support that all, can I? We’ve got “Maidans” here, so it’s hard to find time sometimes.
I don’t mind having lots of good flashlights in the world. But I can’t produce them all by myself (for mass production), and companies don’t like open source projects . But here is such a unique situation with these Narsil/Anduril – maybe it’s possible to help project in some way and at the same time push forward my own ideas.
In every Indigo I did the same (but with assembler). I wouldn’t say that thing is easy and clear. It’s tedious and worse than piecing a puzzle. There are a lot of recursions and lots of paths had to be kept in mind, if one want to get convenient interface, that can get you anywhere along with context. For me that is the most unpleasant part of work.
I write on C and assembler. And for AVR I see no possibility to use C for mentioned things, that are, on the other hand, can be easily written in assembler. With ARM problem isn’t that critical, but these MCU are worth using only in especially huge projects.
Without inline assembler this thing requires unacceptable amount of resources. There are many channels (Unicorn has 3), and they work on frequencies of tens and hundreds kHz. If you will manage to implement something like this on C, that would be interesting.
There is no wear levelling. Only wear reduction. Levelling is present in Meteor, because there are a lot of constantly changing data stored for self-calibration and at the same time a lot of free EEPROM. There are common memory for every UI and not much user data to be stored. Unicorn is another story: Every UI has independent space, store a lot of data, there aren’t much memory (128 byte), and half of it is allocated for factory settings copy (storing such things in flash is luxury). At the end, it leaves us with 16 bytes for single preset, where full configuration for particular interface should be stored. There are nothing to level wear with. Moreover, such algorithms are complex: Beside regular count of write cycles and data remap, they can find defective memory cells and put them in reserve. And use them later when there are no healthy cells left, etc. Such things require lots of memory and thorough testing, because glitches can occur many years after production, when first defective cell is detected or algorithm will stuck on last cell, continuously wearing it out. Brr…