If you’re only going to have one type of press and can do simple coding, don’t even bother with an off time cap. Using brown out detection method works very good.
For those that don’t know how to do it, here are the details:
For this to work you have to change a fuse settings in the AVRDUDE command. “Brownout detection” must be enabled. Snipped from Alex site:
“Example of working fuse bit configuration avrdude arguments: -U lfuse:w:0x79:m -U hfuse:w:0xed:m”
The code:
First you need a byte in the “no initialise” area. Define it like this:
When the light is on normally (after all start up code) you set it to 0 with “OffCheck = 0”.
On startup when detecting a short press, just check if it is still 0 with “if (!OffCheck)”.
With the brownout fuse set the OffTime integer value survives short off presses because of the input capacitor. It decays away after about half a second. Decayed non initialised bytes are 0xFF (all bits 1), the exact opposite to 0 (all bits 0 ). Meaning if the OffCheck value is still 0 it was a short press. If it’s not 0, it has decayed to 0xFF meaning the light was off for longer.
Brownout detection works pretty well for distinguishing between short (< 0.5s) and long (> 0.5s) presses.
I haven’t made a STAR clone with it yet, but I have a non-STAR firmware published and working if you want a reference. It’s ToyKeeper/s7/s7.c in my repo linked below. It may be a bit on the fancy side though, with 15 different modes… but at least you don’t have to cycle through them to use just the basic “normal” modes.
ToyKeeper, I'm having no luck with the Offtime-Cap firmware. I'm not seeing any blinking when turning on-off-on etc. Maybe I don't understand how to use it, can you offer any advice?
The Offtime-Cap.c (.hex) firmware blinks out the ADC value of the voltage on the Offtime cap. This helps tweak the short press and medium press values for mode switching in other firmwares.
Maybe the first level is too low to light up the emitter.
And if it won’t change modes, the OTC values are probably way off.
I’m just guessing though.
…
Oh, wait. You mean offtime-cap.c? You might want to set BLINK_PWM to a higher number, perhaps. If it’s set high enough, it should at least blink once briefly after it turns on, since a zero will still register. But it’s half as bright as the regular blinks, and much shorter, so it might not light up at all if the #define is too low.
For a value of 203, for example, it should blink out “_ , ., _ _”. Or for a value of 0, it should blink out a single “.”.
But, of course, if it gives you a zero, the OTC is either not working or has been off for a long time.
I must have a compile issue. The .hex from your repository runs, but the blinks are too short for my driver. When I change BLINK_PWM and rebuild (Studio 6.2) the PWM pin just goes to 1 volt (?!) with no pwm. The .hex file I made is 132 bytes yours is 688 bytes.
Let me redo this from scratch, I have something wrong here.
EDIT: Working fine now (deleted all and recreated project) - operator error. Thanks ToyKeeper!
Okay, was BLINK_PWM the only thing you needed to change?
To help make it work on more drivers, I set it to 20 and re-published a new build. That way, even the “zero” blink will be at a level of 10, which should show up on almost anything.
Yes, all I changed was BLINK_PWM (to 40, because of my PWM-to-analog driver). 10 is probably fine for the bulk of the drivers. Of course after that success I also changed the Vref to Vcc just to see where the OffTime cap voltage range is. My driver runs on either two or three cells, so Vcc is stable at 5V. With 1.1V vref I was reading 255 on short clicks. With Vcc vref the counts were at 60 to 45 range. I'll need to do some more testing to find good values for medium and short presses.
So now I've been working with Battcheck.c to figure out where that count is. I plan on adding a second low battery step-down mode, one at 9V and one at 6V. Somehow I need to differentiate between three dead cells (9V), and two full cells (8.4V). Sounds like disaster waitin' to strike. :)
I not asking for help (yet) but I'm open to any advice.
THANK YOU for posting and hosting these programs as well as the others in the repository.
hey, im looking for a “step by step” tutorial for programing the Attiny13A useing an arduino,
just like drdanke did here in post #29, but if possible with more details and maybe even a video,
i like the idea of not need to buy the programer and the clips, and i do have the arduino alrady.
Just so happens I have another USBasp on the way. I found the latest firmware and will update one of the units when it gets here. BTW: I’m not used to handling things like this with open chip leads w/o being grounded with a wrist strap. Has anyone had an ESD failure? I think when I’m done flashing the new firmware, I’ll slip it into some 3/4” clear heatshrink tubing and shrink the two ends.
I took the next step and loaded Atmel Studio 6.2 (along with some serious bloatware from Microsoft). So far, all the c files I’ve looked at compiled fine. Finding the optimization settings was a hoot. Looking at the code, quite a bit of it makes sense.
This is all coming together just in time, because the 22mm 16 X 7135 boards arrived from OSH today, and the F13 light is in transit. I’ve got two or three other projects underway as well plus a test bench.
Okay, I made a version of STAR which uses brownout detection instead of an offtime capacitor. It’s just STAR_off_time 1.3 with that one thing changed; otherwise it’s identical.
Not guaranteed to work on every attiny13-based driver, but it works on all the ones I tried. I hear the brownout timing can vary depending on some of the other driver components.
There isn’t really any advantage to it if you already have an OTC installed. It might save a few bytes, I guess, but mostly it’s just to get an offtime-based UI on lights which don’t have (or can’t fit) the capacitor. I use this trick on a couple qlite/nanjg drivers.
I use a USBasp 2.0 programmer and grew tired of the annoying “cannot set sck period” error message every time I used it, so I fixed it (updated the firmware) for $3—and ended up with a backup programmer in the process. I gleaned the following info from a few sites including the programmer’s site. This only works if you’re currently using a USBasp 2.0 programmer.
1. Buy a USBasp 2.0 with 10-wire ribbon from Ebay, Fasttech or wherever.
2. Choose which programmer you’re going to update (the target) and mark it with a permanent marker or something,
3. Document your clip ribbon connections to your existing programmer and remove them.
4. Optional: Make sure your new programmer works. Connect to a clip, clip to an attiny13a, and test the connection. I use “avrdude –p t13 –c usbasp –n” (without the quotes).
5. Jump JP2 on the target USBasp to put it in programming mode.
6. Connect the two USBasps with the 10-wire ribbon. It can only connect one way.
7. Get the new firmware either from the developer (needs to be compiled) or get the hex file here . Lazy arse that I am, I got the hex file.
8. Put the hex file in the correct directory.
9. Plug the non-target USBasp into the USB port
10. The new firmware requires different fuse settings on the target programmer’s processor. I used the command line “avrdude –c usbasp –p atmega8 –u –U hfuse:w:0xc9:m –U lfuse:w:0xef:m” (without the quotes).
11. Flash the hex file to the target USBASP to update the firmware. I used the command line “avrdude –c usbasp –p atmega8 –U flash:w:usbasp.atmega8.2011-05-28.hex” (without the quotes). If you made your own hex file, use it in the command line.
12. Disconnect the 10-wire ribbon and remove the jumper from the target.
13. Connect the clip ribbon to the target and repeat #4 above. The “cannot set sck period” error message is now a thing of the past.
You should now be able to flash error free. Oh, I had both programmers set to 5 volts.
I have only flashed one chip with the new firmware, and it works, but I am leaving the non-target with the old firmware just in case there is some issue down the road.
I think you're the only person who has ever cared to update their firmware. It's never caused any problems for me or anyone else that I'm aware of, so my opinion has always been "if it isn't broken, don't waste time trying to fix it".
That said, I applaud you for figuring out a fix for something that isn't really broken just because it bugs you. It sounds like you'll fit in really well here (we've all been known to do things like this).
