Been meaning to add this point here. In bistro-HD we probably found a neat kind of bug.
As in bistro original (although done differently) on first boot if no mode number is saved it's assumed that no data is saved so boot up initial values for the mode and all menu toggles get saved.
Unfortunately this takes, oh, maybe 30ms or so and the mode gets written first. That's bad because the mode is the check to see if there is valid data. It should get written last.
It seems this bug has probably struck some people if power is lost in the first 30ms of the first boot, which could certainly happen.
I believe, not quite certain, that this goes back to original bistro which seems to do things in the same order, but I could be wrong, as the version I actually looked at wasn't quite original. I'll check.
I have not changed this yet, because I need to review what impact reversing the saves has elsewhere. Like are there other places where it's better to write the mode out fast before the other saves? I'll have to see. It's something to consider in firmwares in general probably.
We're not really going to get ZFS installed on an attiny25 though so may have to live with some compromise. This shouldn't affect later bootups, or not in this bad of a way. Actually OTSM probably protects against bad writes to single bytes in later boots just like switch does. There should be enough cap to get through the write, although it might interfere with the click timing for that click if the battery is low. Normally that's only an issue after a menu toggle, in which case click timing isn't even important.
Hmm. Good point. I havenāt heard any reports of failure in that manner, but itās a trivial change with no impact on code size, and it should make things more robust, so it seems like a good patch to land.
It doesnāt even need to change the layout of eepromā¦ just the order of saving data.
As for writing the mode quickly, itās a separate function in bistro and gets called separately when needed. Itās not generally done for speed though, but to avoid unnecessary wear on the eeprom. The mode is wear-levelled but the config settings are not. The general guideline there is to use wear-levelling if a value is likely to change frequently during regular use, or use fixed addresses if the value only changes when the user modifies a config setting.
Yes that's right, it's usually done separately for mode only. the only question is if there's some advantage in the toggles, where both are saved. HD has reworked this significantly and I think it's ok in HD, because the mode save back to zero is now done on startup as soon as it's realized that it's a menu mode (saved a couple of duplicate instructions). In bistro, the first mode reset to zero is combined with the muggle_mode menu toggle. So if you magaged a button press at exactly the wrong 30ms there, I think you could set the muggle mode, but if mode_save is last, still end up starting back in the menu.
Presently it's just that if you click out too fast, mode gets saved to zero, you are ejected from the menu and the mode option isn't saved, but that's fine, that's what should happen if you click before the flash. So changing it creates a very tiny race right there possibly. One extra call to save_mode fixes it though.
Anyway, I didn't really mean to worry too much about any particular firmware, just to point out that we don't have atomic saves and it's good to think about save order. I have seen this bug hit probably, very hard to know something like this with certainty but it certainly can happen, and then at least removes one uncertainty.
I was a bit confused. Anyway in HD at least and I think bistro too, modes do normally get set back to zero before clicking out of the menu, but the worst would be muggle gets set and mode doesn't and you end up in some random mode, I think only of the three though as ones beyond that should wrap, unless you medium click out or long-click-memory out, then it won't wrap so then possibly a non-muggle mode still left in the array. It's definitely not as clean as saving to mode zero first but might not be so bad and probably not as bad as the firstboot bug. I'm always reluctant to add two extra bytes for an extra call if I can avoid it, lol.
So the firstboot save (reset toggle) is actually the commit if firstboot is enabled, so just saving that last fixes it in that case. In HD to save spce, the saves are in an array and looped though, so that also constrains firstboot to actually be the be the last (or could be first) toggle, which might not always be a desirable constraint in the future if adding more toggles. It seems like no free lunch.
In case it's of use to anyone, I made a little tool to calculate voltage divider values. It's based on RMM's spreadsheet and level_calc.py. Here are some example calculations with it:
> ./voltage_dividers.py
How many cells in series? (1) 4
R1 value? (191000) 560000
R2 value? (47000) 33000
MCU reference voltage? (1.1)
ADC range: 144 - 216
Standby power: ~0.049 mA
Press Enter to exit:
The ADC values should match RMM's spreadsheet, but I'm not sure if the standby power calculations are correct. I just made up a formula which got reasonably close to some values I've measured over the past couple years.
Standby current is a bit strange, assuming no bleeder resistor or tail LED the first example should just be
16.8V/(560,000Ohms+33,000Ohms)=28uA but you get 49. However all your examples are at very very low levels so leakage through anything can mean 49 is more accurate which could explain your hint at a mystery equation, especially leakage from an LDO I suspect, but that will depend on the particular components used.
You could just use the simple voltage divider current, with a note that at the level of 10uA or so other things may impact the result for the whole driver.
Hi everyone. I have a problem with one soft. Iāve been looking for a firmware for a long time that would suit my needs, and when I found it didnāt work. Itās about dth_Momentary_v1_1 by dthoang. After powering on, the led flashes and itās the end. It does not respond at all to the button. What could be the reason?
I am testing this firmware on nanjg 105e, fuses are set to LOW 75, HIGH FF. Button directly soldered to the second tiny13 output
Leviatan, sounds like itās probably a physical issueā¦ something shorted or not connected or perhaps connected to the wrong place. Hard to say exactly, without more information.
Thank you ToyKeeper, for building this repositry. I have just recently bought a USBasp board, the required wires and a Pomona SOIC8 clip and flashed my first couple of drivers. The first trial test with Nlite on a nanjg ak47 and the other using your tail-light firmware.
That tail-light firmware is pretty much just what I want. I have diddled with the code slightly; Iām mainly after the blinky modes. That is sort of strange to say because I totally have no use for blinky modes that many lights come with. Bike blinkies are different.
I changed the blinky count and frequency. I am not a ācoderā; many decades ago I wrote some simple stuff in Basic. A very long time ago.
Anyhow, I wanted to say Thanks. I hope to have some fun and learn something new.
Thank you ToyKeeper, for building this repositry. I have just recently bought a USBasp board, the required wires and a Pomona SOIC8 clip and flashed my first couple of drivers. The first trial test with Nlite on a nanjg ak47 and the other using your tail-light firmware.
That tail-light firmware is pretty much just what I want. I have diddled with the code slightly; Iām mainly after the blinky modes. That is sort of strange to say because I totally have no use for blinky modes that many lights come with. Bike blinkies are different.
I changed the blinky count and frequency. I am not a ācoderā; many decades ago I wrote some simple stuff in Basic. A very long time ago.
Anyhow, I wanted to say Thanks. I hope to have some fun and learn something new.
Ah, that makes more sense. In that case, it sounds like dth_Momentary either has a bug or is expecting a different physical layout than the others. Looking at the code, Iām guessing probably a bug. What happens if you copy the is_pressed() function from STAR_momentary.c into dth_Momentary?
I may be able to figure it out when I get back to my lab, but I donāt have any of my usual tools at the moment. So, I donāt have answers yet. Iām not very familiar with dthoangās code.
Edit: been doing some reading, found relevant discussion:
Gotta check gchart's and Flintrock' solutions.
Edit2: it still seems that my attiny is loosing its RAM too fast for my short clicks to work. I guess I need to change the capacitor on the board.
Initial post:
Hi, I have been playing with crescendo on a "red" convoy driver (at13, mine is green in fact but matches what I have seen described as "red").
For that I:
unsoldered pin5 (and put some tape under it)
removed all blinkies, memory, thermal stepdown and battcheck (to make it easier to figure out what happens)
force PORTB at 1 for the 3 pins that are floating (seemed to help, less power consumption? I remove this modification from time to time to check it doesn't have a negative impact) didn't look deep in the pin stuff, should set the pull ups (port should be all input from boot))
new ramp generated with the python script (128 steps, 1CH)
My short clicks seemed to change the length of the ramping so I uncommented:
// Just in case (SRAM could have partially decayed) ramp_dir = (ramp_dir == 1) ? 1 : -1;
And now my ramps always have the same length. But the behavior is very inconsistent when I click. I've put special blinkies in the middle of the code to try and follow what happens:
most of the clicks are seens as "long" -> ramp
some small clicks do not get me out of the while (no reset?) in this case either:
nothing happens
I keep steady on the current level (yay! but I do not understand how), not happening that often
some clicks are seen as "short", but the global short click counter has a very high value
some very weird stuff, either I am too tired to count the blinks or the programm counter jumps on some short clicks (is that possible?)
The high counter values would be coherent with the "SRAM could have partially decayed" thingy. So my globals are probably partially messed up.
To go forward, I am thinking to either:
add a capacitor somewhere (OTC stuff? I'll need to dive in older posts)
find a way to reduce the power consumption so that the RAM decays slower
order some NANJG/QLITES, but what am I going to do with the rest of my holidays (and my convoy drivers)
Any pointer is welcome, I searched on the forum but there is a lot of content and I have not been through everything yet.
The dth_momentary code was written for the NANJG 105C, but you are using the 105E. The pushbutton switch must be connected to pin 2 of the ATMEL chip. Check the continuity between your switch and pin 2. To test, you can use a piece of wire to connect pin 2 to ground.
I have a newer version of the code that I can share once you check the pin 2 connection.
I tried to flash a FET+1 Attiny25 driver with Ramping UI from the repository, but I donāt know what to do. I tried to flash the hex out of the box but it doesnāt work.
And now I canāt connect to the Attiny25, It always says ātarget doesnāt answer. Initialization failed rc= ā1. If I try with the -F says that the Device signature doesnāt match.
it also doesnāt allow to erase the chip with āavrdude -p t25 -c usbasp -u -eā
Thank you for your answer.
So I tried on 105c in two ways. With a button and a piece of wire. Both do not work. I checked the connection with a multimeter. Soft loaded the default. I did not change anything in it
