Do you like my hacking? If so, please consider leaving something in the
Fediverse (Mastodon etc): @Sprite_tm@social. spritesmods.com
Ofcourse, I wouldn't tell you all of this if I hadn't tried it in practice. To show the fact that my schematic actually works, here's a video. For your information: this particular implementation uses about 10mA when it's on and something like 50uA when off.
As usual, the sources for the AVRs firmware can be downloaded and are licensed under the GPLv3. Be sure to read the included README-file if you go use it, though.
As you can see, usually a schematic can be reduced a lot by thinking it through and knowing a couple of tricks. While the act of redesigning a schematic to do more with less components isn't always economical or time-efficient, it's good to know a few tricks so you can minimalize a schematic when, for example, you have to solder more then one of them by hand.
« Prev 4
15 commentsAbout the only comment I have is that you really should have a decoupling capacitor across the microcontroller's power pins. 47nF or 100nF ceramic, nothing special, just keep the leads short. Yes, it may work without one, but you'll hear it on the radio in the adjacent apartment/house, and it may stop working as the battery impedance rises with age.
Bill Porter: Nope, it's not a stack issue. The WDT is used in two ways: when the candle is 'on', it's used as a timer to periodically check the amount of ambient light: I need the interrupt behaviour there. When the candle is 'off', the interrupt functionality gets turned off (in the PowerOffUc routine, WDTCR&=~0x40;) and the AVR will reset every time the WDT hits. That causes the behaviour you see, not a stack overflow. I've clarified the code a bit in the download so it's more clear.
There's a bug in this code that I wasted a few hours chasing down. You've got a recursive function call problem that's causing a stack overflow. At least it did on my ATtiny. Here's how I believe it's happening: PowerOffUc() enters sleep mode; which means it won't return until the UC is out of sleep and the WDT interrupt is processed. The WDT wakes the uC up and immediately enters the interrupt service routine. The WDT interrupt service routine, if light out, calls a new instance of PowerOffUc(). Since the first call never returned, this kicks off a stack overflow and eventually resets the uC. Since your code checks for light out before doing anything, you aren't even aware it's stuck in a reset loop. My application is slightly different and that's how I found the bug. Hope this helps anyone who finds this page and tries using the code.
What a nice item! Thank you so much! I have 3 here running here right now - one still on the breadboard for testing several leds in combination. I prefer the red and yellow (red=LED2=better light detection) because it matches a camp fire very well. Never ever I will get desperate what to bring to a party: Might be a cake or pudding with a campfire in it? And everyone will be disappointed when unpacking this tiny device in its plastic bag and it does nothing at daylight anymore??? That will save me a lot of money and let me be THEEEE IT-Girl there - IT in 2 meanings ... @Radon222: Thank you so much for that hint with pin5 instead of pin8!!! I just started to play with the t13 and am only able to flash hex-files from others.I would like to thank Sprite and you for your work - I learned so much about essential electronics here. And besides that: I am a H+M-acintosh-user which forces me to go the really hard way: Terminal: averdude -c usbtiny -p t13 or what else - etc. No Win-AVRDude - only in a real emergency. But the smaller apps will help me to perform the first steps in programming the AVR: Making the Game of Life slower? Or: Saving more power on my LED-lights - whatever. Please excuse my bad English - I am German. Don´t hesitate to correct me. I am very happy when i am able to learn sth. more. Have a good time and CU OnWeb soon! AnnaOnWeb
It\'s a fairly standard software-PWM-routine though (though it works inverted, which doesn\'t matter becayse the numbers are random anyway): first, the leds are turned on, then a counter runs from 0 to 255. As soon as the counter has reached the desired PWM-value, the LED is turned off. Repeat that and you\'ll get a fairly good PWM signal.
I was looking at source code (I was going to try to modify it to have the LED\\\'s connected to positive and a pin, but decided against it), and I don\\\'t quite understand how the PWM is working... it looks like it sets the pins high, and then sets them high again?
Hey, thanks a lot for this article dude! it really helped :)
I just wanted to point out a minor error in the README file. It says to short pin 8 to calibrate the LEDs, but it is clear from the source code that it should be pin 5 (PB0). I tried it out and it works great with some cheap 3mm red LEDs.
Good stuff! To the guy who asked about PICs: You should be able to do this on a 12F675 - since it has the A/D converter. (The 12F629 doesn't.) Of course, you'll have to rewrite the code in assembler.
Any source code for 12fxxx PIC? :)
I got about 1.4 volts from an red LED when directly exposed to a lamp. I noticed that light sensing diodes appear to have a much larger sensor area and dont react as "nervous" as LEDs do in light sensing applications.
What kind of voltage do you get across the LEDs when they work as light sensors? I am going to get an LED now and measure the voltage across its legs. Wonder what voltage the meter will show.
The basic idea should work in the same way: the hardware needed for this is available in an ATMega8 too, IIRC. The C-code might have to be adjusted a bit, though, due to differences in architecture.
Great project! Does it work for ATmega8's, too?
Love it. But being a bit newbie I'm stuck.. I have my batting and have a addition uno which is setup as a attorney programmer, so happily got addition blink running on tiny.... But what software do I need to compile and upload this stuff. Can I use my uno as a programmer still, or do I need something else?