Step 1: Etch

After sanding and thoroughly cleaning the Aluminium with detergent (dish soap), I etched it in a solution of lye (Sodium Hydroxide) to remove surface defects and give a matte finish, like that of the Apple MacBook. I bought the lye in a solid form, as crystals of drain cleaner, and assumed that the crystals were pure lye (a stretch, though it was the best conservative estimate I could make). I read a guide about the etching process that suggested a 15% lye solution, so I mixed 1 part lye to 6 parts water in a 5-gallon plastic bucket. Wearing gloves and goggles, I submerged the metal in the solution, and it heated up and bubbled furiously as the lye ate away the surface. I only left the piece in solution about 2 minutes, to give a consistent matte look without making pock marks.

Step 2: Desmut

I don’t have access to proper desmut solution, the solvent that takes off the impure “smut” residue that accumulates on the surface of treated Aluminium. I rinsed the part in water and cleaned it with dish soap to fair success, and proceeded to anodizing.

Step 3: Anodize

Well, this step is supposed to involve using the work piece as an anode (positive terminal) in a direct-current circuit. The theory is that the metal will form a thin oxide layer, a clear ceramic that adds scratch- and corrosion-resistance to the finish. However, I accidentally wired the system in reverse, so that the work piece was the cathode (negative terminal). The result was a strange thin film of oxide that creates rainbow interference patterns. I like the look, and I assume the coating is indeed Aluminium oxide as it should be, but I cannot know for sure. It seems to have moderate scratch resistance, but I may try again with the correct circuit some time in the future to get it right. In the mean time, I am enjoying the vintage effect the “cathodizing” created, and I may just decide to keep it this way.

Following the guide I found, I bought battery acid from the local auto parts store and mixed it into water in the ratio of 1 parts acid to 4 parts water. The acid comes as 50% solution, and the goal is to have around 10%, so a solution of about 12% acid is just about right. The solution stays at room temperature.

I fashioned an electrode (supposedly a cathode, though due to my error ultimately an anode) out of Aluminium stock, which I placed in the bottom of the bucket of acid solution. I used an old computer ATX power supply to run a current of around 16 Amps through the workpiece, dangling from a bar of Aluminium, into the acid solution and back out through the “cathode”. Because I had wired the whole thing in reverse, the intended “cathode” ended up with the MacBook-like finish while my part looked just about the same as it did going in.

I sealed the part with boiling water for about an hour, and the rainbow effects showed up. Not exactly what I was after, but cool!

Psensors Output

Once I knew the sensor name, I ran “sensors” in a terminal and found that my computer uses a chip called “applesmc-isa-300″:

travis@travis-ubuntu:~/Projects/Gauges$ sensors
applesmc-isa-0300
Adapter: ISA adapter
Exhaust  :   3074 RPM  (min = 1800 RPM)
TB0T:         +32.5°C
TC0D:         +57.2°C
TC0P:         +55.0°C
TM0P:         +58.0°C
TN0P:         +54.0°C
TTF0:         +55.0°C
TW0P:         +74.0°C
Th0H:         +54.8°C
Th0S:         +54.5°C
Th1H:         +54.2°C

Every Linux sensor has a corresponding pseudo-file for reading programmatically. I dug through online references of various sorts until I found the directory of my chipset, called ‘/sys/bus/platform/devices/applesmc.768/’. Once I had the directory, I ran sensors again with the -u flag set for “debugging” output:

travis@travis-ubuntu:~/Projects/Gauges$ sensors -u
applesmc-isa-0300
Adapter: ISA adapter
Exhaust  :
  fan1_input: 2309.000
  fan1_min: 1800.000
TB0T:
  temp1_input: 32.500
TC0D:
  temp2_input: 58.250
TC0P:
  temp3_input: 56.000
TM0P:
  temp4_input: 57.750
TN0P:
  temp5_input: 54.500
TTF0:
  temp6_input: 56.250
TW0P:
  temp7_input: 74.000
Th0H:
  temp8_input: 56.000
Th0S:
  temp9_input: 55.750
Th1H:
  temp10_input: 55.500

The verbose output told me that the sensor I want, TC0D, is also called “temp2_input”. Looking in the

/sys/bus/platform/devices/applesmc.768/

directory, I found a pseudo-file called “temp2_input”. Perfect!

When my Python script reads ’/sys/bus/platform/devices/applesmc.768/temp2_input’, it gets a string something like “59500″ corresponding to 59.5°C. My script converts the number to a float, divides by 1000, then rounds off to the nearest integer so I can fit the number in one byte. Awesome!

I wrote a Python script using the PyBlueZ stack to connect to the Bluesmirf. I had tried using PySerial, a great package, to write directly to the symbolic /dev/rfcomm0 representing serial bluetooth devices in Linux, but the connection had problems. The problems I thought I could avoid by switching to PyBlueZ popped up again, and I am still hunting for  solution.

When I start the Python script, which I call “gauges-daemon” since eventually it will run as a Linux daemon, or background task, the connection opens fine and the gauges respond. However, after a certain period of activity the script suddenly encounters BluetoothError #11, “Resource Temporaily Unavailable.” To counter this error I thought I could have the script re-open the connection, but then I get error #16, “Device or Resource Busy”.

I did some permuting and found that I can start the script, wait for it to fail, and then re-start the BlueSmirf. This allows the script to reconnect. The evidence seems to suggest that the problem is with the BlueSmirf, though I have pored over the datasheet (PDF) and found no mention about necessary steps to keep connections alive.

EDIT: The problem was a buffer overflow on the PC. I was sending Bluetooth messages to the Gauges, which would respond with status text. Because the Python script never read the port for incoming messages, these incoming packets collected in the Bluetooth serial buffer and everything halted until the buffer was cleared.

I fixed the Python script to represent the necessary changes:

import psutil
import serial
import string
import time
import bluetooth

sampleTime = 1
numSamples = 5
lastTemp = 0

TEMP_CHAR = 't'
USAGE_CHAR = 'u'
SENSOR_NAME = 'TC0D'

filename = '/sys/bus/platform/devices/applesmc.768/temp2_input'

def parseSensorsOutputLinux(output):
	return int(round(float(output) / 1000))

def connect():
	while(True):
		try:
			gaugeSocket = bluetooth.BluetoothSocket(bluetooth.RFCOMM)
			gaugeSocket.connect(('00:06:66:42:22:96', 1))
			break;
		except bluetooth.btcommon.BluetoothError as error:
			gaugeSocket.close()
			print "Could not connect: ", error, "; Retrying in 10s..."
			time.sleep(10)
	return gaugeSocket;

gaugeSocket = connect()
while(True):
	usage = psutil.cpu_percent(interval=sampleTime)
	sensorFile = open(filename)
	temp = parseSensorsOutputLinux(sensorFile.read())
	try:
		gaugeSocket.send(USAGE_CHAR)
		gaugeSocket.send(chr(int(usage)))
		#print("Wrote usage: " + str(int(usage)))

		gaugeSocket.send(TEMP_CHAR)
		gaugeSocket.send(chr(temp))
		print gaugeSocket.recv(1024)
		#print("Wrote temp: " + str(temp))
	except bluetooth.btcommon.BluetoothError as error:
		print "Caught BluetoothError: ", error
		time.sleep(5)
		gaugeSocket = connect()
		pass

gaugeSocket.close()

The stock gauge

I love the look and feel of vintage analog gauges, like those on the instrumentation panels of WWII-era planes and submarines. They have a certain aura of importance and longevity that attracts me. I have been thinking about a wireless hardware add-on that artfully displays my computer’s temperature and CPU usage, and I figured that some of those old gauges would be awesome for this project if I could find them at the right price.

I had actually looked around online for vintage panel meters before, but I was too specific: I was trying to find DC panel meters for voltages under 12V. I recently realized that I could instead choose any of the multitude of DC meters available on eBay, as most of them simply use scaling resistors to calibrate to the ranges on their faces. So, I ordered two that I thought looked cool, for around $20 each.

I got the first gauge in the mail today. It’s a “20 mA” DC current meter, with a metal faceplate, solid glass crystal, and a metal housing. It has two screw terminals on the back. It’s also waterproof and ruggedized. Of course, I want it to display CPU temperature and not “DC Milliamperes,” so I immediately started the teardown.

The Teardown

The gauge has a metal face held on by six small machine screws. Removing these, along with the three mounting screws, I exposed the crystal.

The crystal lifts off, though it was a bit stuck down due to years of pressure on the rubber gasket. Prying up gently around the gasket, the crystal easily peeled off and I was left with the exposed inner gauge.

To get the gauge assembly out I had to remove the screw terminal nuts on the back of the unit. Then everything slid out of the housing.

The faceplate was held in place by two hex-headed machine screws. Removing these, I carefully slid the plate out from under the indicator needle. I popped the plate into the scanner, and it was time for a face lift.

The Face Lift

I loved the look of the face that came in the gauge. It just had the wrong label and units. So, I scanned the plate with a flatbed scanner, then cleaned up all around the edges with GIMP, my image editor of choice. I also rotated the face to align it with the program’s grid.

The plate had the word “MILLIAMPERES” across the center, so the first change I made was replacing this text with “CPU TEMP”. I also changed the smaller “D.C.” label to “°C”, and masked out all the numerals with background color.

To find the range of values I needed, I installed “Psensor,” a graphing utility for system vitals monitoring on Ubuntu. Then I opened every application I could, running multiple browsers with videos and music, etc. I wanted to find the maximum temperature of the CPU under normal conditions. It peaked around 88º C, so I decided on 50-100º C for the indicated values on the new faceplate.

Matching fonts as closely as I could, I aligned the new numerals where the old ones had been. I printed a test page, and fortunately it was exactly the right size!

I got out some fancy stationery that happened to closely match the color of the faceplate, and printed my new design on high quality. I cut the design out with a razor knife, and then carefully applied removable double-sided tape across the whole plate. I trimmed away the edges of the tape so it would’t show.

Finally, I applied the new face plate design and smoothed it down gently. Time to reassemble!

The Reassembly

From here the project was simply a matter of working in reverse. The plate when onto the gauge assembly, and both of its screws went back in.

Then I slid the whole assembly into the housing, and applied the (now clean) crystal, followed by the outer gasket and metal face.

Around back, the screw terminal accessories went back on, and it was time to try some electrical experiments.

Calibration

I wanted to find the full-swing current of the gauge. It was labelled “50mA”, but it came with resistors attached in parallel to the screw terminals on the back. I removed the resistors, attaching my multimeter across the gauge terminal. Its resistance mode measured the gauge at precisely 10 ohms.

Next I hooked the gauge to a 1.3V DC power supply in series with an ammeter and a 10K potentiometer. Dialing down the resistance, the gauge made a full swing at almost exactly 5mA. When I am ready to hook it to a microcontroller, there won’t be a problem sourcing such a small drive current. Awesome!

My thinking was largely inspired by the TED talk I had just watched, at http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html, about what speaker Barry Schwartz calls “The Paradox of Choice.” His thesis is that, given some choice over none, people tend to be happier, but at some critical point the number of choices overwhelms the consumer and people simply cannot feel happy about their choices.

Today’s consumers have perhaps more choices than ever before, and arguably more choices in tech than in any other department of goods. Take a look at Lenovo’s website. I was browsing the latest and greatest in workforce laptops, and I was greeted by a web page spread wider than my five-year-old laptop’s 1080 horizontal pixels. Scrolling up and down and over and back I saw more laptops than I could reasonably hold in mind at a time, and worse, I couldn’t discern the difference between most of them. How do I choose between “SmartBuy” and “Enhanced Experience” ? How could I know whether a ThinkPad on the lower end of its price range would serve me better than an IdeaPad outfitted with the more luxurious options?

It’s not Lenovo’s fault, per se, that their offering are so diverse; nor is this a problem with Lenovo in particular. Over-diversification is common to basically every tech company today, and especially those marketed to the US consumers. I understand that some enterprise managers want very specific options, but detailed customization of this fine grain is not appropriate on a product home page. In situations like this one, in which I am trying to evaluate the state of the tech market, I am tempted to ask the designers and engineers, “Which product are you proud of? Which one of these options did you work hardest on?”

I suppose that, at the root of it, I want to know that modern designers and scientists and engineers are driven — like those of yesteryear seemed to be — by good quality and pride in craftsmanship. Our country needs things that get better with age. Or, at least, things that don’t obsolete so quickly.

I don’t mean to imply that I oppose technological innovation and progress; contrarily, I believe that technology is a transformative and potentially empowering and beneficial element of humanity. I simply think that we need to shift our mainstream focus from consuming more goods, more quickly, to valuing what we have.

This kind of shift would benefit hugely from interoperable and modular parts. If my computer can accept a new processor a few years down the road, I will be more likely to keep it. I could simply upgrade the components that need upgrading and keep the rest, which is in all likelihood perfectly functional. Incremental modifications and upgrades would save consumers money, cause companies to focus on long-lasting product designs, and ultimately help people live a bit lighter on the world.

I’m calling on technological collaboration, but also a shift in our social paradigm. It’s time for everyone to slow down, evaluate our priorities, and ultimately reduce consumption.

I don’t profess environmental concern as a means of self-valuation or absolution. I know that many people use “environment” and “green” as words to throw around in gaining credibility. I truly love and respect the natural world, and I also believe that environmental safety is directly connected to our safety. However far people think they can divorce themselves from the environment, we are all fundamentally connected to our natural roots.

The circuit boards have come back through BatchPCB, and I couldn’t be happier with the results. The lines are clean, the sizes are just to spec, and I got 20 boards instead of the ten I ordered (presumably to account for manufacturing defects, though I haven’t found any). I populated one of the PCBs, and the design works!

The Boards

The StarTiny boards turned out just right. Granted, it’s a very simple design. However, the price was right at just $3 per board. I originally hoped to order in the US, but the cost was just too high for an entry-level designer trying to get a feel for the manufacturing process.

The Code

The code I had written for my solderless-breadboard ATtiny was close to correct, though the timings were a bit off from what I wanted. As I’ve said before, there’s not enough flash space to include floating-point math libraries, so I had to forgo the sin() function I used on the Ardweeny. The code uses a rudimentary linear ramp to approximate the sine, and the results are pretty good, though there is a bit less visual distinction between the nodes.

I altered the pin mappings in the code to reflect the connections on the PCB, and I think with a few more tweaks I can get the look just right.

Change of Plans with Paper

The paper doesn’t pass light as well as I had hoped. I could try sourcing brighter LEDs, but they would have to stay under the 20mA drive capabilities of the ‘tiny. I think I might go with lighter-colored (and thinner) paper instead. The issue then would be structural integrity, though.

Photos of the Paper Patterns

I can’t wait to get the PCBs to bring these colors to life!

Enter the StarTiny

I made the new StarTiny PCB with gEDA. It is based on the ATtiny13 microcontroller from Atmel, as the name suggests. The tiny13 has just enough storage space to hold the necessary firmware for the star. It comes in a compact 8-SOIC package that fits neatly between the five LEDs on the board.

The Order

I ordered 10 of the StarTiny PCBs through BatchPCB, a Sparkfun-related frontend to the Chinese Gold Phoenix PCB fab. The boards are only 1.25″ to a side, so the cost comes out to only $3.95 per board. There’s a $10 per-order tooling fee (for panelization and human design verification) and a $5 shipping fee.

StarTiny v1 Overview

 The Files

As you may have read in the first post on the Stardweeny, I’m sharing the design files freely. I want anyone to be able to share in the simple joy of soothing, blinky LEDs! The effect is really quite charming. Also, if you want, you can order your own PCB directly via BatchPCB.

• StarTiny v1 Gerber Files

StarTiny v1 by Travis Geis is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at www.zenlogic.org.
Permissions beyond the scope of this license may be available at http://www.zenlogic.org/.

Testing the ATtiny13 with one LED

This year for the holidays I created a little dynamic ornament with five channels of independent LED light. The prototype, which had to be finished in a matter of days, used an Ardweeny board from Solarbotics. The Ardweeny is based on the ATmega328, a great chip with more than five hardware channels for PWM (pulse-width modulation). While I love the ATmega chips, they get a bit pricey at $5 apiece just to drive some LEDs.

I was shopping on Digi-Key for alternatives and decided to try a couple of ATtiny13 microcontrollers. The ATtiny13 is a small, low-power AVR with the standard 8-bit core size, and conveniently comes with a 9.6-MHz internal RC oscillator. Because the ATtiny has an internal oscillator, I knew I could keep my hardware very minimal and thus very small, a requirement for the small paper ornament I was hoping to build.

The problem is that the ATtiny13 has only one PWM output. If I used only its hardware functionality, I would get one channel of control, where I needed five. To solution is to implement a simple software PWM. In this post I describe my process of getting software PWM (and embedded C programming in general) working on the ATtiny13.

The first step with programming any part is reading the datasheet [link]. The Attiny13 comes with 1KB of internal flash memory for programs. When I ordered it this sounded plenty large for my purposes, but I forgot to account for the heavy Arduino libraries I’m used to using, whose needed functionality I would have to implement myself in the code. 1KB turns out to feel like a tiny amount of space.

1KB is too small to hold the floating-point math libraries of AVR-LibC, the C library I use for AVR programs. It’s also too small to hold the math.h library, which includes the trigonometry functions. In my ’328-based prototype I used a sin() function to calculate the brightness levels of the light channels, to give a soothing light pulsation. That won’t be an option on the tiny13.

I had a lot of trouble getting started with C on the ATtiny. It’s not too complicated once you get going, though.

[steps for strting with libc]

Implementing Software PWM

Software PWM uses an inbuilt functionality of the microcontroller called a timer. The timer counts off clock cycles, and when it reaches a certain point, in this case its maximum value of 255 (the max value of a single unsigned byte), the timer triggers an interrupt.

The interrupt is important precisely because it interrupts the running code. Specifically, it tells the microcontroller to jump to a predefined location in program memory, execute the instructions there, and then return to the main routine. For software-based PWM, the timer interrupt is perfect. It frees up the main program logic by periodically and consistently executing the same function, called an Interrupt Service Routine.

So the desired program flow looks like this:

main(){
	loop infinitely, changing the output levels
	accordingly.
}

ISR(){
	run now and then, twiddling the hardware
	outputs to correspond with the output levels
	set in main
}

The main function in my case was supposed to set the output level of each of five LEDs such that one LED would “lead” the others in a gentle up-down pulsation. The ISR would be responsible for dealing with the actual on-off settings of the LEDs.

For my project I chose a PWM resolution of one byte, or eight bits. A byte allows for 256 possible output levels, plenty more than the eye can see in brightness gradation. A resolution of 256 means that there are 256 “time slots” wherein an LED can turn on or off.

For example, if the brightness of the LED is supposed to be 255, it is on from time slot “0″ all the way to time slot “255″—in other words, all the time. If the brightness is 0, the LED is off for every cycle. If the brightness is 100, the LED is on for the first hundred cycles, then off for the remaining 155.

The resulting output is not smooth, but a series of full-on and full-off positions that, to the relatively slow human eye, average together to some intermediate brightness. So, now we know roughly what the ISR should do:

1. Read the desired brightness level of an LED, in the form of a global variable.
2. Read the current progress through the 256 cycles
3. Compare the brightness level to the current progress
1. If the progress is lower than the desired on-time, turn the LED on.
2. If the progress is past the desired on-time, turn the LED off.
4. Increment the progress by one.

AVR-LibC says that the ISR for the timer interrupt on the tiny13 has the signature

ISR(TIM0_OVF_vect){}

The TIM0_OVF_vect parameter indicates that this ISR (potentially one of several) is specifically for interrupts triggered by a TIMER0 overflow.

Given the pin number of each LED channel, and the brightness level desired, the ISR body looks like:

ISR(TIM0_OVF_vect)
{
	if(ISRcounter < ch1) PORTB |= (1 << CH1_PIN); //Write the ch1 pin high
	else PORTB &= ~(1 << CH1_PIN); //Write the ch1 pin low

	if(ISRcounter < ch2) PORTB |= (1 << CH2_PIN);
	else PORTB &= ~(1 << CH2_PIN);

	if(ISRcounter < ch3) PORTB |= (1 << CH3_PIN);
	else PORTB &= ~(1 << CH3_PIN);

	if(ISRcounter < ch4) PORTB |= (1 << CH4_PIN);
	else PORTB &= ~(1 << CH4_PIN);

	if(ISRcounter < ch5) PORTB |= (1 << CH5_PIN);
	else PORTB &= ~(1 << CH5_PIN);

	ISRcounter++;
}

where ch1, ch2, …, ch5 are the single-byte output levels of each channel, and CH1_PIN, CH2_PIN, …, CH5_PIN are the pin numbers for each channel.

The ISR is actually very simple:

ISRcounter holds the current count of ISR runs (0 to 255). For each channel, if the ISRcounter is less than the brightness level desired for that channel, write the LED HIGH (PORTB |= (1 << pinNumber)). Once the counter exceeds the desired brightness level, keep writing the LED LOW (PORTB &= ~(1 << pinNumber)). So, in effect, the brightness level byte is simply the ON-time of the LED, out of 255.

The rest of the code can now fall into place:

#define F_CPU 9.6E6L /* CPU Freq. Must come before delay.h include. 9.6MHz */

#include  /* For data types */
#include  /* Register and port definitions */
#include  /* Busy-wait delay functions */
#include  /* Exposes timers, counters and ISR functions */

#define CH1_PIN PB0 /* Bind output channels to specific PortB pins. This depends on schematic. */
#define CH2_PIN PB1
#define CH3_PIN PB2
#define CH4_PIN PB3
#define CH5_PIN PB4

#define TIME_OFFSET 50
#define DELAY_MS 3

uint8_t ch1, ch2, ch3, ch4, ch5; /* The one-byte PWM level of each channel */
uint8_t directions = 0xFF;
/*
This one-byte flag holds five channel direction bit flags
0x [nothing] [nothing] [nothing] [ch5] [ch4] [ch3] [ch2] [ch1]
*/

volatile uint8_t ISRcounter = 0; /* Count the number of times the ISR has run */
uint8_t timeCount;

int main(void);

int main(void)
{
	/* Setup */
	ch1 = 0;
	ch2 = TIME_OFFSET;
	ch3 = 2 * TIME_OFFSET;
	ch4 = 3 * TIME_OFFSET;
	ch5 = 4 * TIME_OFFSET;

	DDRB = 0xFF; //Every PORTB pin is output
	PORTB = 0x00; //Start with every pin low

	TCCR0B |= (1 << CS00); // disable timer prescale (=clock rate)
	TIMSK0 |= (1 << TOIE0); // enable timer overflow interrupt specifically 	sei(); // enable interrupts in general 	/* Loop */ 	while(1){ 		if(directions & 1) ch1++; 		else ch1--; 		if(directions & 0B00000010) ch2++; 		else ch2--; 		if(directions & 0B00000100) ch3++; 		else ch3--; 		if(directions & 0B00001000) ch4++; 		else ch4--; 		if(directions & 0B00010000) ch5++; 		else ch5--; 		if(ch1 > 254) directions &= ~0B00000001;
		else if(ch1 < 1) directions |= 0B00000001; 		if(ch2 > 254) directions &= ~0B00000010;
		else if(ch2 < 1) directions |= 0B00000010; 		if(ch3 > 254) directions &= ~0B00000100;
		else if(ch3 < 1) directions |= 0B00000100; 		if(ch4 > 254) directions &= ~0B00001000;
		else if(ch4 < 1) directions |= 0B00001000; 		if(ch5 > 254) directions &= ~0B00010000;
		else if(ch5 < 1) directions |= 0B00010000;

		_delay_ms(DELAY_MS);
	}
	return 0;
}

Like all AVR-LibC programs, the main() function is divided into a setup phase, which runs once at the time of power-up, and a loop phase, which runs after setup as long as power is supplied. The setup function here sets the five LED channels to a starting brightness with an interval determined by the macro TIME_OFFSET, so-named because it simulates the amount of time by which each LED leads the one “behind” it in the circular brightness pattern.

Then the loop logic uses a one-bit “direction” flag to decide whether to increment or decrement the brightness of each channel, and finally a comparison checks whether the direction needs to reverse (in case the LED is at minimum or maximum brightness). The loop delays by time DELAY_MS, in milliseconds, and starts again.

That’s it! Beyond setting up the timer details with the lines

	TCCR0B |= (1 << CS00); // disable timer prescale (=clock rate)
	TIMSK0 |= (1 << TOIE0); // enable timer overflow interrupt specifically

	sei(); // enable interrupts in general

as given in the ATtiny13 datasheet, the main() function and the ISR together handle everything the program has to do to make pretty blinky lights.

There is one more step, actually. By default, the ATtiny13 ships with a 1/8th clock prescaler enabled, a fuse called “CKDIV8″ or “clock divide 8.” To make the timer count quickly enough for the PWM to be invisible to the human eye, we need to disable this clock divisor. To do so, we must run the command

"avrdude -c usbtiny -p t13 -U lfuse:w:0x7A:m"

instructing avrdude to wirte 0x7A to the low fuse. This is the same as the default low fuse value in every way but the CKDIV8 bit, which has been disabled.

The complete code:

/*
* Stardweeny Source Code
* Author: Travis Geis
* Version: 1
* Date: January 2012
* URL: http://zenlogic.org/
*
* file: main.c
*
* The Stardweeny project runs five channels of software PWM to
* control the five individual LEDs in the points of a paper star.
*
* Inspired by and dedicated to Linda Geis.
*
* For this code to work correctly, lfuse = 0x7A. (Disabling CKDIV8)
* Run the command "avrdude -c usbtiny -p t13 -U lfuse:w:0x7A:m"
*/

#define F_CPU 9.6E6L /* CPU Freq. Must come before delay.h include. 9.6MHz */

#include  /* For data types */
#include  /* Register and port definitions */
#include  /* Busy-wait delay functions */
#include  /* Exposes timers, counters and ISR functions */

#define CH1_PIN PB0 /* Bind output channels to specific PortB pins. This depends on schematic. */
#define CH2_PIN PB1
#define CH3_PIN PB2
#define CH4_PIN PB3
#define CH5_PIN PB4

#define TIME_OFFSET 50
#define DELAY_MS 3

uint8_t ch1, ch2, ch3, ch4, ch5; /* The one-byte PWM level of each channel */
uint8_t directions = 0xFF;
/*
This one-byte flag holds five channel direction bit flags
0x [nothing] [nothing] [nothing] [ch5] [ch4] [ch3] [ch2] [ch1]
*/

volatile uint8_t ISRcounter = 0; /* Count the number of times the ISR has run */
uint8_t timeCount;

int main(void);

/*
* int main(void):
*
* The main function runs automatically when the AVR powers up.
* It never returns, and so dispatches all other actions for the
* microcontroller.
*
* The goal is to make a sinusoidal light intensity with time.
*
*/

int main(void)
{
	/* Setup */
	ch1 = 0;
	ch2 = TIME_OFFSET;
	ch3 = 2 * TIME_OFFSET;
	ch4 = 3 * TIME_OFFSET;
	ch5 = 4 * TIME_OFFSET;

	DDRB = 0xFF; //Every PORTB pin is output
	PORTB = 0x00; //Start with every pin low

	TCCR0B |= (1 << CS00); // disable timer prescale (=clock rate)
	TIMSK0 |= (1 << TOIE0); // enable timer overflow interrupt specifically 	 	sei(); // enable interrupts in general 	 	/* Loop */ 	while(1){ 		if(directions & 1) ch1++; 		else ch1--; 		if(directions & 0B00000010) ch2++; 		else ch2--; 		if(directions & 0B00000100) ch3++; 		else ch3--; 		if(directions & 0B00001000) ch4++; 		else ch4--; 		if(directions & 0B00010000) ch5++; 		else ch5--; 		if(ch1 > 254) directions &= ~0B00000001;
		else if(ch1 < 1) directions |= 0B00000001; 		if(ch2 > 254) directions &= ~0B00000010;
		else if(ch2 < 1) directions |= 0B00000010; 		if(ch3 > 254) directions &= ~0B00000100;
		else if(ch3 < 1) directions |= 0B00000100; 		if(ch4 > 254) directions &= ~0B00001000;
		else if(ch4 < 1) directions |= 0B00001000; 		if(ch5 > 254) directions &= ~0B00010000;
		else if(ch5 < 1) directions |= 0B00010000;

		_delay_ms(DELAY_MS);
	}
	return 0;
}
/*
* The ISR is responsible for toggling the states of the five output channels
* based on the current global variables for the desired brightness levels.
* Because the brightnesses (ch1 ... ch5) are single-byte values, the range
* of values is 0 to 255. Thus the ISR needs to restart its counting cycle every
* 256th time it is called.
*
* To avoid undesired wiggle on the PWM, the ISR updates evey channel's pin
* every time it runs. It should take the same number of cycles every time.
* The duty period of the PWM is the first section. Thus the LED goes ON then OFF.
*/
ISR(TIM0_OVF_vect)
{
	if(ISRcounter < ch1) PORTB |= (1 << CH1_PIN); //Write the ch1 pin high
	else PORTB &= ~(1 << CH1_PIN); //Write the ch1 pin low

	if(ISRcounter < ch2) PORTB |= (1 << CH2_PIN);
	else PORTB &= ~(1 << CH2_PIN);

	if(ISRcounter < ch3) PORTB |= (1 << CH3_PIN);
	else PORTB &= ~(1 << CH3_PIN);

	if(ISRcounter < ch4) PORTB |= (1 << CH4_PIN);
	else PORTB &= ~(1 << CH4_PIN);

	if(ISRcounter < ch5) PORTB |= (1 << CH5_PIN);
	else PORTB &= ~(1 << CH5_PIN);

	ISRcounter++;
}

Feel free to use the code any way you want. Have fun!

I think while I’m at it I will add a LM317 variable regulator and an Adafruit Panel Volt Meter to keep an eye on the voltage of the regulator. I could even add a current-sensing resistor, though I probably won’t need it.

I started off intending to roll my own supply, but it turns out they don’t get much smaller than the ATXs for what those do. I like having all the separate power lines, and the overcurrent protection is priceless.