@All regarding the copyright protection situation - My primary concern is along the lines TK brought up. A chilling effect is undesirable, especially if the claims are not valid. With that said…
@Sharpie - I’ll have to defer to you for now on UK stuff as I’m in the states and I am not well versed on the other side of the pond. Is it safe for me to assume that (as far as you are aware) any “design rights” in the UK still depend on the “design” being “new”? And you’ve fully relinquished any claim you have on the 5-component design we are discussing, correct? If so any further discussion of those protections in this thread is purely academic (beyond any chilling effect it may have by scaring folks off). With that in mind, if it’s all accurate, let’s agree to table the matter of copyright until such time as you see the need to protect any new designs.
Thanks, I’m on-track if you’re on track.
We do eeprom writes now and get away with it using wear leveling. I’ll reiterate that TK and others are shooting for precisely measuring 3 periods of time. We want both analog and precision here. My take is that an improved analog circuit is the only solution which ticks all of the checkboxes.
While I have not personally used one yet, TK has mentioned specifically (in an unrelated conversation) that she’s running multiple flashlights with no OTC using brown-out-detection + SRAM decay to measure long/short. For the moment I’ll take TK’s word that this code works fine with no OTC.
You may not have stepped through all of the considerations for offtime w/ mode memory (the most popular config among those who’ve used a variety). If you aren’t fully familiar with offtime, ontime, and various memory/no-memory/short-cycle types of configuration… maybe another member can link to a good explanation? There have been many detailed explanations of varying quality posted all over the place, but I don’t have a link to one handy right now.
It does work very well. I’ve used it extensively when testing drivers (linear and boost) without OTC and a simple firmware to avoid the OTC or parts of more sophisticated firmware to intefere. This way I can use off time memory without OTC which makes especially mode testing easier: you don’t need the usual on-time double click after memory kicked in. So if we’re talking about this firmware implementation:
That trick was created by alexvh, not me. I just made it more popular.
In any case, I find it eliminates the need for an OTC when only short and long are needed. The physical OTC is still relevant if you want to adjust the button timing or give it more than two time buckets though.
I briefly tried to use the decay to measure more than just short or long, but it seems the SRAM goes from intact to fully decayed very quickly. The decay is too short to be useful, even with a large sample size. The technique can be used on slower-decaying RAM though. Apparently it’s quite useful for rate-limiting auth requests for smart cards, for example. It’ll refuse to auth until the RAM is fully decayed, using physics to prevent most brute force attacks.
EEPROM writes are almost entirely done within the first few ms the MCU has power. It’s part of the boot-up process, before the LED is even turned on. It’s very difficult for a human to turn the device off fast enough to interrupt that.
The exception is during config mode, when timed writes occur periodically while waiting for power to be disconnected.
The firmware is available if you’d like to see the details. It’s probably worth looking through regardless, to understand how the driver is being used, and answers quite a few questions which have been raised in this thread.
Not so much. The OTC drain and MCU power-down actually take longer when using a lighted tail switch. Sometimes to the point that they never fully power down at all. That’s why the bleeder resistor is required. Otherwise the tail switch is forcing current through the driver when it’s trying to be off.
Based on a quick calculation of runtime power versus capacitance… I estimate the MCU probably runs for anywhere from a dozen cycles to a few thousand clock cycles after power is switched off. This could mean up to 3ms or so.
The many-taps thing uses SRAM to count the taps, to reduce EEPROM writes.
The actual eeprom writes during that are two bytes per boot, done immediately at each boot. If the main emitter turns on, that’s confirmation that the eeprom write has completed.
The eeprom writes happen before the user touches the switch. The main emitter blinks out a number, eeprom write happens, then the main emitter does a stutter pattern telling the user to click. If it’s stuttering, the write has already completed.
Another write happens after the stuttering stops, and then it waits for a second with no output.
In most “stuck” cases, people have been doing two full clicks instead of a light tap. Usually, it’s resolve-able with a few tips or a video on how to tap the button.
The “bricked” MCUs were completely unrelated, failed at flash time with a firmware programmer. This can be fixed by removing the MCU and trying again, or in extra-difficult cases, using a high-voltage serial programmer. It also only seems to affect me so far; others haven’t reported running into this issue.
As far as I can tell, the most likely cause of a truly “stuck” driver would be if the SRAM byte used for tracking the fast taps has the unlikely trait of decaying to zeroes instead of ones. This could encourage the driver to enter config mode instead of normal running modes. (after resting a while the counter would start at, say, ten, instead of zero… and the estimated chance of this happening is one out of every few hundred MCUs… which can be dramatically reduced by using 16 bits instead of 8)
Has already been done. The result was that the attiny eeprom lasted about 10X longer than spec. However, this was at room temperature. It actually took quite a while to see the first eeprom failure.
If the attiny eeprom performs according to spec, and if the user taps the button 100 times per day, it should take about 876 years before the first eeprom write failure. If it performs according to test results, it would be closer to 10,000 years.
I did some brief tests on this, and IIRC alexvh did some much more extensive tests, and we both got the same result — the decay happens too quickly to be useful. That is, the beginning of the decay and the end of the decay happen so close together that the time between isn’t useful.
Possibly, but I expect it’d require a much larger capacitor than we can fit onto these drivers. We’d probably need capacitors measured in mF instead of uF. Regular MCU operation requires at least a few mA.
The attiny13a has one PWM counter and two channels. It is fully utilized, leaving nothing spare.
In my testing, brown-out options don’t actually make any meaningful difference. At first I thought it was required, but it’s not.
Longer SRAM decay isn’t really needed. It’s already long enough. The goal is to get the OTC to decay at a specific and consistent rate, and the obvious first test for that is to use a bigger capacitor with a resistor attached to it. Measure it at several fixed intervals, at a high and low temperature, and the results will show whether it’s a sufficient method. Possibly also measure it on both a single-cell and multi-cell driver, with the appropriate zener mod and voltage divider adjustments, in hopes that it can remain consistent (or at least usable) there too.
This is mostly just waiting on someone (maybe me?) to build wight’s latest design and measure it. I, um, don’t have the parts or experience for building drivers just yet… but hopefully I can do something about that soon.
I’m very familiar with the free software world, but I still need to find out how other hardware maker communities handle the legal aspects of what they do. I’m not sure how they lay the groundwork for free collaboration while also protecting themselves from abuse by large commercial entities.
The only small businesses I can think of which make any profit from BLF-related drivers are RMM and a few individual people who upgrade and resell lights on a limited basis. Sometimes they also build their own drivers from scratch. RMM uses his own designs, but collaborates with and contributes to the efforts of others. The general consensus about these people is that they’re beneficial and should be allowed to continue doing this.
There’s also Banggood+Manker, which is much more controversial. Explicit permission was given, but they have since overstepped the limits of the initial agreements and don’t seem at all concerned about it. Driver designs have also changed somewhat since then, which might nullify any rights. And even if the IP holders had the resources to do something about it, the relevant laws haven’t really been established in China anyway. Only large companies have enough influence to enforce their copyrights or patents there.
This.
Even the GPL hasn’t been proven there yet, and it’s pretty strong in western countries.
There are a few orders magnitude difference between Honda and a couple individuals on a forum.
As far as I’m aware, it’s simple: Look at the awesome things modders are building, and make that available to a wider audience. The BLF folks involved don’t get any payment aside from light samples, so there isn’t really any profit. Getting paid in half-broken flashlights isn’t what I’d call a business plan.
I don’t know what the future plans are, and most of it doesn’t really involve me. It’s mostly just “hey, I’ll send you a light if you’ll calibrate the firmware”. I have some concerns about the overall effects on BLF though, as it seems to shift the needle from makers toward consumers, so I’m hoping to focus on moving that needle the other way.
I don’t know about anyone else (except hank, who already chimed in), but I really value RMM’s driver production services. Not many people are willing or able to build drivers themselves, even from a kit, but they still have an interest in using complete drivers. I don’t want to interfere with that.
Setting up shop to produce, sell, and ship drivers, complete with a storefront and customer support and taxes and legal registration… is a significant ongoing investment. It’s enough that most people who could make and sell hardware don’t want to, since it’s a lot of work for very very low pay. If that’s something you’re interested in, you may want to protect your designs, maybe file for patents, etc. If not though, I hope you’ll decide to explicitly allow others to do so.
I’ve been following this thread quite closely because there’s some good stuff being discussed here underneath all the salt and I feel like I’m learning a lot from it. But I did want to address this point because I feel its a gross misrepresentation for one reason — code comments. A good developer will document their code with comments throughout, and ToyKeeper does a very good job of that. You don’t have to understand the actual code in order to understand the explanations that are included alongside it. I don’t see any comments or explanations on your circuit diagrams, or most anybody else’s for that matter.
saw some potentially incorrect info, this should be correct:
in case of split byte eeprom write, erase takes 1.8ms, write takes another 1.8ms
in case of atomic byte erase&write, it is 3.4ms
page 21 paragraph 5.5.4 table 5-1
in my own attiny85 firmware I do split byte eeprom operations, first erasing the next cell to be written in next boot cycle, and only after that, calculate next mode and write the previous “next” cell from the previous boot cycle. By doing it this way I haven’t yet gotten any cases of errors in mode switching. Even if it would happen it would only result in failure to switch mode.
Idon’t yet have a clue about page mode?
i do basically this:
read last mode and next write location,
read capacitor
calculate next mode,
erase a new next eeprom location,
write current mode to previous eeprom location
(so my previous post was wrong in the sense that I dont erase-calculate-write, I do read-calculate-erase-write)
I had errors if I waited too long between erase and write. And I first do ERASE and then WRITE, else it could happen that you have written the next mode, but not erased (marked) the location for the next eeprom write.
I had a lot of missed writes before I started doing split-erase-write because the time was insufficient during very fast mode switches (in clicky mode)
I optimized code so that all that can be delayed, waits until read-calculate-erase-write has finished so that the next mode is correctly written. I was paying attention to optimize/minimize all instructions that are occurring before erase&write, all were scrutinized.
I also write another array of different kind of events (for pattern matching purposes), so I do 2 times erase-write per boot, and it works fine after torture testing.
Since tiny85 has 8k of memory, I use optimizaton for speed /function inlining, which produces almost 6k of code, but I suppose that gets you less JMP in final assempler code. Difficult to run a benchmark, I’ve been thinking about it for a while.
I first erase (mark the pointer to) the next location, and then write the current state to the previous location. If something would happen between those erase and write operations, nothing bad would result, the mode would simply not advance to the next one. What is important here is the order: first erase must be done, and only after that the write should occur.
by atomic I was referring to Atomic byte programing (see 5.3.2), which is the standard way, using erase,then write.
For the firmware I’m building I’m using a circular array, sort of FIFO with a pointer to next write location, marked with 0xFF.
I do use wear leveling (but actually for the purpose of pattern matching in history of events, I don’t think that EEPROM cell would wear out in my lifetime)
Thanks for the tip on page mode, I’ll check it out and think if it can be used in my case. I read cca 60 bytes, and write 2, per each boot.
