Behold this ATtiny85 based EEPROM programmer. It seems like a roundabout way of doing things, but [Quinn Dunki] wanted to build to her specifications using tools she had on hand. What she came up with is an ATtinyISP USB programmer, pushing data to an ATtiny85, which then programs an EEPROM chip with said data.

The hardware is the next module for her Veronica 6502 computer build. When we last saw that project [Quinn] was planning to add persistent storage for the operating firmware. This will be in the form of an EEPROM programmed with this device. Using ISP and an ATtiny as a go-between means that she should have no problems reflashing the OS without removing the chip. But it all depends on how she designs the interface.

For example, she blew a whole bunch of time troubleshooting the device because garbage data was being written to the chip. In the end, having her manual bus programmer hooked up during the flashing operation was the culprit. Lesson learned, it’s onward and upward with the build.

We’ve been featuring [Quinn's] projects a lot lately. That’s in part because they’re really interesting, but also because she does such a great job of documenting her experience.

[Owen] has a fairly big project in the works, where he’ll need to use infrared light to send data wirelessly between two nodes. The only problem with his grand plan is that he has never built anything of the sort. As a learning exercise, he decided to try his hand at building a wireless control interface for his laptop, which he uses to play music while doing homework.

His laptop usually sits across the room from [Owen], where it is connected to a speaker and amplifier. He hates getting up repeatedly to change songs, so he figured he might as well build an IR receiver to control Winamp that responds to commands from his TV’s remote control. Using his Open Bench logic sniffer and an IR receiver from an old VCR, he deciphered his remote’s encoding system. He then programmed an ATtiny13 to decode messages received by the IR sensor, sending them to his laptop via USB.

He packaged things inside a tiny mint tin, which he hangs from a desk lamp while in use. Now he can easily perform just about any action in Winamp with a few button presses on his remote. [Owen] says that he’s incredibly happy with the results, and now that he has a firm grasp of IR signaling concepts, we can’t wait to see what he builds next.

It seems that [pppd] is always rushing out of his apartment to catch the bus, and he finds himself frequently questioning whether or not he remembered to lock the door. He often doubles back to check, and while he has never actually forgotten to lock the door, he would rather not deal with the worry.

Since he finally had some free time on his hands, he decided to put together a simple device that would help end his worry once and for all. Using an ATtiny13, [pppd] designed a circuit that would detect when his door has been unlocked and opened, beeping every few seconds until the lock is reengaged. The circuit relies on a reed switch installed inside the door frame, which is tripped by the magnet he glued to his door’s deadbolt.

He says that the system works well so far, though he does have a few improvements in mind already.

[Mike Shegedin] makes full use of an 8-pin microcontroller with this ATtiny13-based dice project. With a maximum of six I/O pins (that includes using the reset pin as I/O) he needed a couple of tricks in order to drive 14 LEDs and use a momentary push button for user input. We’re certainly familiar with the concepts here, but it still took quite a while to figure out what is going on with the schematic that [Mike] posted.

You’ve probably already guessed that he’s using Charlieplexing to drive more LEDs than he has pins. But when we started looking at the layout we thought he had drawn the schematic wrong, because there are six pairs of LEDs where the two diodes in each pair a not reverse biased, but hooked up in parallel. That, plus the fact that his battery is hooked up backwards. After several minutes of study the light bulb finally clicked on. Dice add pips (the dots on each side of a die) in pairs with the exception of the center pip. That means that you only need to control four total lines for each die (three pairs plus the center pip). There’s two ways to handle this, you could use four rows and two columns with traditional multiplexing, or you can reverse bias the two sets of LEDs for each die and use Charlieplexing. The former is a bit easier to program, the latter saves you one I/O pin and meant that [Mike] didn’t need to use the reset pin as I/O.

This is a clever addition to the collection of dice projects we’ve seen like the battery-less die, and the ATtiny2313 powered dice.

[Gadre] built his own ATtiny project without using any batteries. It’s an electronic Dice (or die if you’re being critical) which uses induction to charge a storage capacitor to act as the power source. The voltage generator is made from a tube of Perspex which houses a set of rare-earth magnets. At the enter of the tube [Gadre] machined a channel wich accepts about 1500 windings of 30 AWG magnet wire. When someone shakes the tube back and forth the magnet passes the wire, inducing a current.  The product is stored in a 4700 uF capacitor, which feeds a boost converter to power the rest of the circuit.

The ATtiny13V that controls the circuit is running its internal RC oscillator at 128 kHz, the lowest setting possible in order to minimize power consumption. After a good shake the user can press a button to roll the die, which is then displayed for several seconds on a group of seven LEDs. See for yourself in the video after the break.

Did you know that most AVR chips have a type of hardware exclusive OR (XOR) option when it comes to the logic levels of the output pins? If you look in the datasheet (the image above is a screenshot from an ATtiny13 datasheet) you’ll find a section on Toggling the Pin. It turns out that if you set a PORT as an output, writing logic one to the corresponding PIN register will toggle the logic levels of that out. This is really easy to overlook if you’re writing in C, but I’ve been working on learning a bit of assembler language and found this to be very useful. Keep reading after the break and I’ll tell you how I happened upon this info and what it’s good for.

So first off, let’s talk about why this doesn’t matter very much if you’re writing in C code. Normally if you want to toggle some output pins you’ll just write a one-liner that XOR’s with a bitmask:

PORTB ^= 0xFF;

This is a bit of C shorthand (learn more about that from my tutorial series) that performs the XOR on the current output levels and writes the result back to the port. But the same thing can be done in hardware by writing the bitmask to the PINB register:

PINB = 0xFF;

You don’t really care, because it’s just one line of code. In fact it’s probably easier to XOR the PORTB because it makes more sense conceptually. But the compiler might end up using more cycles than if you had written to the PIN register.

I happened across this feature because I was blinking some LEDs as a way to learn assembler. I had this jumble of code in an Interrupt Service Routine:

ldi myReg, 0xFF
in intReg, PORTB
eor intReg, myReg
out PORTB, intReg

It loads a bitmask into one register, loads in the current logic from PORTB to another register, performs an XOR of the two, and writes the result back to PORTB. This takes four cycles and requires two registers. Toggling bits is such a rudimentary operation I was surprised there wasn’t a command to XOR bits directly so I started searching around. I came across this article over at AVR Freaks which clued me into the bit toggle feature. Now I was able to reduce my assembler code as follows:

ldi intReg2, 0xFF	;temporarity use intReg2 as a bit mask
out PINB, intReg2	;writing to PINB effectivley does an Exclusive OR on PORTB

This results in the same toggling effect, but takes just two cycles and requires the use of only one register.

What I found most interesting is that no matter how much I use AVR chips, there ‘s never a shortage of surprises waiting to be found in the datasheet.

[Owen] just finished putting together a portable helicopter game. It’s pretty impressive, especially since he used an ATtiny13 microcontroller. That chip uses an 8-pin dip package, offering only five I/O pins (six if you use the reset pin) and 1k of programming space.

The game runs on a small cellphone-type LCD screen. The helicopter remains somewhere in the center column of the screen as the maze that makes up the game board approaches one step at a time. The single button that controls the helicopter will raise it with each step of the maze when held down, or allow it to fall when released. The player’s progress is shown as a hex value in the upper left corner of the screen. When you hit a wall, your score will be shown next to the high score for the game and will be saved in EEPROM if it’s a new record. As the game progresses, the maze gets harder based on the score. Check it out in a video clip after the break.

[Frank] decided to augment his desk lamp’s features by adding dimming controls (translated). Since the light source is a triad of LEDs the best method of dimming their intensity is to use Pulse Width Modulation. That’s the method that he went with, and luckily the SUNNAN lamp from Ikea which he’s using as the donor for the project has just enough room to squeeze in the parts necessary for this hack.

You need two main bits to use PWM with a lamp like this; a microcontroller (or possibly a timer chip like the 555) and a transistor to protect that chip from the current necessary to run the LEDs at full brightness. [Frank] went with an ATtiny13 and a 2N2222 transistor, both quite common and very inexpensive (you can even pull the microcontroller from a light bulb if you know where to look). Two buttons were added to the top of the lamp base which allow for up and down controls. There’s even an SOS function which is triggered by pressing both buttons at the same time. [Frank's] happy to show off the completed project in the clip after the break.

AVR chips are convenient because you can program them in circuit at their operating voltage. That is, unless you screw up the fuse settings and they’ll no longer listen to an In System Programmer. If you find yourself facing this problem, just build this circuit on a breadboard and ‘unbrick’ by holding down the button.

The circuit seen above is a High Voltage Serial Programmer. This is one of two high voltage protocols used by AVR chips; HVSP is for chips that don’t have enough pins to use High Voltage Parallel Programming. This rendition uses a 12V power source, which is the level necessary for the high voltage method. A 7805 linear regulator joins the mix to provide operational voltage, along with one transistor, an ATtiny2313 to control the circuit, a four-digit 7-segment display for feedback, and one button for control.

Watch the video after the break to see an ATtiny13 programmed to disable the reset pin using a breadboarded programmer. That chip is then easily rescued, having been automatically recognized by using its device signature.

Adding this board (translated) to your bathroom fan will turn it into a smart device. It’s designed to automatically shut off the fan after it’s had some time to clear humidity from the room. It replaces the wall switch which normally controls these fans by converting the fan connection to always be connected to mains.  The board draws constant power to keep the ATtiny13 running via a half-wave rectification circuit. A single LED that rises from the center of the PCB lights up to signal that the fan is in operation, but it is also used as a light sensor, similar to the LED communications hack from a couple of days ago. When the lights go on in the bathroom the microcontroller will turn on the exhaust fan via a Triac. It will remain on until the light level in the bathroom drops.

There’s an interesting timing algorithm that delays the fan startup, and varies the amount of time it will stay on in the dark depending on how long the bathroom lights were on. This way, a longer shower (which will build up more humidity) will cause the fan to remain on for the base of five minutes, plus one minute longer for every two minutes the bathroom was in use. Pretty smart, and quite useful if your bathroom sees high traffic from several family members.

Almost a month ago I started trying to reverse engineer an inexpensive LED color changing light bulb. With your help I’ve mapped out the circuit, and taken control of the bulb. But there’s still a few mysteries in this little blinker. Join me after the break to see what I’ve done so far, peruse the schematic and source code, and to help solve the two remaining mysteries.

What I’ve Accomplished

First off, thank you to all the commenters on the original post. I figured a lot out about this circuit because of that help. Notably, that the code I had dumped wasn’t any use because the lock bits had been set. There was also a lot of constructive input and conjecture about this when I shared it at the Sector67 meeting on Tuesday (a hackerspace here in Madison).

I’m happy to say that I was able to program the ATtiny13 chip while in place. I damaged the first bulb I cracked open by drilling through an inductor. The second time I was more careful, and soldered ribbon cable onto each of the microcontroller pins.

I can program this chip without removing it from the board. This is accomplished by using High Voltage Serial Programming (HVSP) while AC power is not connected. I reset the fuses to factory settings to enable the reset pin but I have been unable to program this using ISP. But that’s not really a problem. The diffuser was taped in place and I added an IDC connector for easy interface with the bulb.

The firmware I’ve written is up on GitHub. It has a few features; the default operation is to fade between red and green every 20 minutes as a porch light during this Christmas season. I’ll discuss the circuit below, but there are two unused pins on the device and I’ve added two test modes that are entered by jumping the pin to ground on the IDC connector. One of the test modes makes the red/green fader happen every 2 seconds. The other scrolls through primary and secondary colors with a 1/2 second delay.

So what we have is a microcontroller that drives two RGB LED modules in series. This chip has two available pins and 1K of programming space. So it should be relatively simple to make this into an I2C addressable module. Ideally this would be done without using AC power, sparking one of the questions I ask at the bottom of the post.

The Circuitry

I traced out the circuit board and recreated the schematic using an Ohmmeter and continuity Tester. There are two separate schematics, one for the LED control circuitry and another for the power supply.

As expected, the power supply uses the example circuit from the LNK304 datasheet. The 12V output connects to the two VCC points on the controller schematic but the ground or return path is a bit peculiar. Look at the upper leg on the PSU schematic which includes R2, R3, R10, and C7. I’ve labeled this as ‘GND (5V rail)’ because this connects to the ground side of the ATtiny13. The ‘GND (12V rail)’ connects to the low side of the LEDs but that is separated from the microcontroller ground path. Obviously the Zener diode is clamping power input for the microcontroller (which needs 5V), but I have no idea how the filter circuit leading back to the AC hot is working.

Take a look at the component list and then see if you can help solve two questions.

• R1 – inline with center conductor of light socket; ~0.5 Ohm. Might be a fuse
• R2 – 1004
• R3 – 1004
• R4 – 3001
• R5 – 1302
• R6 – 1201
• R7 – 1Bx
• R8 – 270
• R9 – 270
• R10 – 1003
• D1 – 1N4007
• D2 – 1N4007
• D3 – R106 TF
• D4 – Looks like a zener
• D5 – RGB LED
• D6 – RGB LED
• D7 – JF S1J
• IC1 – PNP Transistor
• IC2 – PNP Transistor
• IC3 – PNP Transistor
• IC4 – LNK304GN AC/DC switching converter
• IC5 – ATtiny13
• C1 – smd without label
• C2 – 50V 22 uF electrolytic
• C3 – 400V 4.7 uF electrolytic
• C4 – 400V 4.7 uF electrolytic
• C5 – 25V 100 uF electrolytic
• C6 – smd without label
• C7- smd without label
• L1 – 102J CEC
• L2 – 102J CEC

Help solve these two questions:

1. How does the GND connection for the ATtiny13 work? A complete answer will explain what the path that includes R2, R3, R10, and C7 actually does, and how it works in conjunction with the switching converter.

2. What is the easiest way to power the control circuit using DC?

Feel free to leave a comment with your thoughts. But if you’re so inclined, I’d love to read a more verbose description so post your thoughts on your own host and leave a link in the comments.

Follow Me

szczys

I went to the last monthly meeting of Sector 67, a hackerspace in Madison, WI. One of the things shown off was a color changing LED light bulb that Menards was clearing out for $1.99. Inside there’s two RGB LEDs controlled by an ATtiny13 and powered by an AC/DC buck converter. An ATtiny13 will run you around $1.25 by itself so this price is quite amazing. I grabbed a couple of these bulbs and set to work on them. Join me after the break to see what I’ve got so far.

These bulbs use a candelabra base so I grabbed an adapter and tried it out in a lamp. Here’s the result, you can see it stepping through color levels a few times a second:

We’ve seen this in a lot of mood light hacks, I want to get at the hardware and make it do my bidding. First thing’s first, time to crack it open. For some reason I thought that carefully drilling some holes around the base would help me figure out where best to use the Dremel cutting wheel. Unfortunately I immediately drilled through one of the inductor coils. Drat.

Well, no stopping now. I’m not too worried as I also bought a solid red version of this bulb. I want to see what’s inside, whether it’s the same design with unpopulated components, or the full shebang with different hardware. I assume there’s no microcontroller inside so I’ll steal the inductor from that one later.

I cut off the diffuser and got to the circuit board. Here’s some images (click for hi-res) as well as a cursory list of hardware.

Top:

• R2 – 1004
• R3 – 1004
• R4 – 3001
• R5 – 1302
• R10 – 1003
• D4 – Looks like a zener… perhaps to set down votage for the tiny13
• D5 – RGB LED
• D6 – RGB LED
• D7 – JF S1J
• IC5 – ATtiny13
• C1 – smd without label
• C7- smd without label

Bottom:

• R1 – inline with center conductor of light socket
• P1 & P2 – Labels for incoming AC power?
• L1 – 102J CEC
• L2 – 102J CEC
• C2 – 50V 22 uF electrolytic
• C3 – 400V 4.7 uF electrolytic
• C4 – 400V 4.7 uF electrolytic
• C5 – 25V 100 uF electrolytic
• C6 – smd without label
• D3 – R106 TF
• R6 – 1201
• R7 – 1Bx
• R8 – 270
• R9 – 270
• IC1 – NGS (transistor for driving LEDs?)
• IC2 – NGS (transistor for driving LEDs?)
• IC3 – NGS (transistor for driving LEDs?)
• IC4 – LNK304GN AC/DC switching converter

I wanted to see if I could talk to the ATtiny13 so I soldered wires onto the pins and hooked it up to my AVR Dragon programmer. ISP was a no go so I soldered more wire to the remaining connection and gave high voltage programming a shot. That was also a failure. But since I already hosed that inductor I have no issue popping the microprocessor off of the board. Here it is soldered onto some perfboard and inserted in a breadboard:

I tried ISP again and that was a no-go. But this time around High Voltage Serial Programming worked. I talked to the chip with AVRdude using this command:

avrdude -P usb -p t13 -c dragon_hvsp -v

That polls the chip and reads back the fuse settings. Currently the lfuse is 0x6A which is the factory default but the hfuse is 0xFA. After checking the datasheet I see that they’ve disabled the reset function (that’s why ISP doesn’t work) and enabled brownout detection. I dumped the firmware and the eeprom and that’s where I’m at. Now I need your help.

I haven’t done much reverse engineering before this so I’m not sure what to do next. I disassembled the firmware using ‘ndisasm’ but I have no idea what I can learn from it, or even how to read it. I’d love some help answering two questions:

1) Why couldn’t I talk to the chip when it was on the circuit board?

2) What can I learn from the disassembled code. Update: after running the code through an AVR disassembler it looks like this is just an ascending list of numbers. [Tiago] pointed out in the comments that this is the behavior when the lock bits have been set. It should be possible to reuse the chip by erasing it but I won’t be able to dump the firmware first. Now I’ll focus on figuring out how the board is routed.

Let me know in the comments.

[Bogdan] has some trouble getting up in the morning. A blaring alarm will do the trick but that’s no way to start the day. To get him through the dark winter months he wanted to try a sunrise simulator. He patched into the alarm signal of his bedside clock, intercepting the command from the clock’s microprocessor and using it as an input for his own ATtiny13. From there, the tiny13 gradually brightens a 150W halogen lamp using a triac until his room is as bright as a July morning. A signal is then sent to the alarm clock’s audio amplifier to turn on the audible alarm. He’s got the system set for a 20-minute sunrise so it’s just a matter of programming his alarm 20-minutes early than the ‘I absolutely have to get out of bed now’ time.

[Sixerdoodle's] garage door indicator tells him if the door is open or closed. He was inspired by the hack from last September but wanted to make it wireless. The setup uses an RF transmitter/receiver pair from Sparkfun, each controlled by an ATtiny13 microcontroller. We found his battle with RF interference from other devices to be interesting. Working out those bugs made for a great learning experience.

[Matt Meerian] introduced us to his kludge of cardboard, tape, mirrors, and electronics in the form of a clever non lethal robin trap. Whenever a pesky robin would enter the box, a sensor is triggered, the solenoid drops a lid, and the bird is contained (and we assume taken far away after that).

Of course the plan backfired; we wont spoil what happened, but you can click the link above to find out.

Related: Arduino Mouse Trap