I had a thought about half-way through my freshman year that seemed like a really good idea.  I wanted to make self-inflating tires.  With the help of George Hansel, who pointed me in the direction of the peristaltic pump, I began drawing up iterations of the prototype in my head, but I never got around to realizing any of them.

I spent about ten minutes rigging up a quick prototype that worked phenomenally.  I was really surprised how easy it is!

Here’s the bike, fitted with a rubbery (though probably vinyl) surgical tubing taped around the circumference of the rear tire.

One side of the tube (suction side) connects to one syringe (or the open air) and the other, pressurized, side connects to the innertube.  In this case, I wasn’t able to connect to the actual innertube, so I used another syringe instead.

Before pumping, the reservoir syringe is filled with air (left) and the syringe to be filled is empty (right).

Within two rotations of the wheel, all of the air from the reservoir syringe is now in the syringe on the right.  It works!

You can see how the peristaltic pump keeps its seal - the tube runs next to itself for a bit, which allows new air to be pulled in from the suction end and old, pressurized air to flow out of the pressurized end.

Pretty cool, huh?

Too bad it took me 3 years to do it…

I ran into an interesting and non-intuitive problem today, while compiling my first large (>10kB) program for an avr microcontroller.  The issue had to do with GCC’s ‘instinct’ to allocate large chunks of memory (BIG variables) to program memory (what you want it to do) and an AVR’s ‘instinct’ to load all variables into RAM, then keep them there.  Unfortunately, RAM and other forms of fast memory are expensive, so you won’t find much of it in your microcontroller [2-4 kB in most 8-bit AVRs].  You will, however, find plenty of flash memory [16kB’s of cheap and plentiful bits!] that would be happy to store your variables.  So, there has to be a way to keep your variables in the flash (program) memory, right?

Right! AVRGCC has already solved the majority of the problem by writing an easy-to-use macro to help you keep your variables in program memory.  Simply model your case after the following:

#include <avr/pgmspace.h>

int variable PROGMEM = 10;

unsigned char array[222] PROGMEM = { 22,22,22,22,22…. };

TCNT1 = pgm_read_byte(&(variable));

TCNT0 = pgm_read_byte(&(array[22]));

The macro PROGMEM tells the AVR to refrain from storing your data in RAM.  The macro pgm_read_* reads the next * (in this case byte) from the pointer given.  The &() looks up the memory address of the data inside the parentheses, so that pgm_read_* can operate on that memory address pointer.

You can read more about this here: http://www.nongnu.org/avr-libc/user-manual/pgmspace.html

Another artifact of writing large programs is waiting for them to flash to your micro.  One flash of 3Mb was taking about thirty seconds to flash at the default spi delay speed.  I looked up a good rule of thumb for programming clock speeds using AVRDUDE’s -i flag.  Apparently, 1/4 of the AVR’s clock speed is acceptable.  

Since my AVR is running at 8MHz, we can pass the -i flag 1/2MHz = .5 uS.  Unfortunately, the -i flag wants an integer, so the lowest we can go is 1 uS.

avrdude -c usbtiny -p m168 -i 1 -F -U flash:w:bicycles.hex

After using the -i flag I got flashing down to 3 seconds!  That’s an order of magnitude faster! 

I was given some excellent advice by j. earlier today, pertaining to my lack of focus on personal projects.  She told me about an artist and a writer who stuck to rigorous schedules in order to consistently be productive over days, weeks, months, and years.  Apparently, one writer would write from eight till twelve every day, no matter how many letters into a word he/she was when the hand struck midnight.

Today I started a two hour daily block for olopede.  I looked over what I’d done thus far and realized that I can’t achieve perfection in a circuit design while depending solely on simulation and calculation, nor without iteration.  I began a new iteration of FunGen today with [mostly] the same VCO core that I have been working with but added a new AGC feedback loop to solve the saturation problems that I was getting.  I also finally figured out git.

I think this two hour thing is going to work out.

Thanks, j.