After three months of work, it's finally done!
About a year and a half ago, I decided that I wanted to branch out from the fairly limited world of low-power 8-bit AVR microcontrollers into something better. Very few consumer products are made with such antiquated technology, and I figured that moving up to something like a 32-bit ARM processor would open a lot of doors for my projects.
I quickly ran out and purchased development kits from three major ARM processor manufacturers.
Judging from the fact that the TI LaunchPad Evaluation kit is still wrapped in plastic, you might guess that I haven't gotten a lot of use out of these.
All of my projects so far have been either entirely analog or "bare-metal" C compiled with AVRGCC and programmed using AVRDUDE. AVRs are simple processors with a limited number of peripherals. As such, my code usually speaks directly to the special function registers of the part by manually modifying specific bits to turn on the ADC or start a timer.
As processors get more complicated, doing all of this special programming by hand becomes overly cumbersome especially considering that some simple tasks require multiple operations that must be performed in a certain order and in some cases within certain timing constraints. Each development kit came with a whole body of software that contains special functions to manage a lot of these operations for you.
Up to this point, I had been accustomed to keeping my entire project code inside a single main.c file. This is a horrible strategy for software development as it makes code very difficult to maintain, but I've never considered myself a software developer and it's always worked for me. I started my life as a firmware developer by writing assembly code for the 8051; In fact, I didn't even know what an AVR was until after I started working on my first pre-ch00ftech attempt at a persistence of vision display. What a mess.
Though programming in C has made my life about 1000 times easier, I've always liked that with assembly, you have 100% control over of the processor and can predict and account for its every action. As machine code gets covered up with more and more layers of abstraction, I tend to get a little anxious and have thus avoided using other people's libraries for far longer than I should have.
This "bare-metal" coding strategy was no longer going to work for these more complex ARM processors, but when trying to incorporate their libraries into my little scripts, I got overwhelmed and eventually gave up. Reading a software library is a lot like reading a schematic. There is a general way things are supposed to be, and when you have zero familiarity with these standards, it makes it very easy to get lost.
For example, at one point I might have written:
When I should have written:
Which caused some odd behavior since this line is present in stm32f10x_gpio.h
#define GPIO_Pin_4 ((uint16_t)0x0010) /*!< Pin 4 selected */
I generally learn best when a project is 90% stuff I know how to do and 10% new stuff, but this task had the percentages flipped the other way around and even with all of the documentation, I got lost pretty fast. Besides, I've never found it easy to just pick up and learn a topic unless there's a specific reason for learning it. That reason didn't come for another year.
Thermal Printers and Instant Cameras
While waiting at Nordstrom for my newly hemmed jeans to get rung up, I noticed how fast their thermal receipt printers print. Thermal printers don't use ink but instead use a special paper that turns black when heated. As the paper is rolled out, a row of tiny heaters "burns" tiny dots in the page that can be organized to make up text. As a result, they have a very small number of moving parts. Usually, it's just the feed motor and sometimes a paper cutter.
A few years ago, I saw an ad for a internet-connected thermal printer called Little Printer which I still think is a brilliant product if only it had better content for US customers (and cost about $100 less). There's something innately fun about having a paper copy of something trivial like the weather forecast or the "word of the day" when everything has been moved online. Despite the short shelf-life of thermal printed text, having a physical copy in front of you gives you a certain sense of permanence and with the digital world so well organized, it's much easier to accidentally stumble across physical keepsakes that may be strewn about in the real world.
Wanting to do something with a thermal printer, I immediately started thinking up ideas. My first idea was...some kind of scanner thing? I guess? It was supposed to be a little motorized car that would roll across a document while scanning it in, and then thermally print out a copy of that document over top. I have no idea why I thought this would be a good idea, but that didn't stop me from spending $50 on this which I still haven't even unwrapped:
I think my confidence was still a little inflated from reverse engineering a children's toy, and I thought that it would be trivial to do the same for a high-speed, full-color, proprietary scan head. Regardless, something must have come up because I never did order a thermal printer.
Fast-forward three years. I'm waiting at Nordstrom and it hits me. I should just make a camera!
Instant-photos managed to stay a part of popular culture from the 50s up until about the mid 2000s when the instant feedback and low-cost of digital cameras made them the new de-facto standard for sharing memories without a trip to the 1-Hour Photo.
The reality is that instant photos have always been terrible and it's a miracle they lasted as long as they did. Polaroid film was extremely expensive, the printed images were small, the picture quality was terrible, the cameras bulky, and you still had to wait a few minutes to see if your picture came out at all.
In its death-throes, Polaroid released the I-Zone camera which took even crappier, smaller pictures and had an annoying length of tape on either end of the picture that was larger than the image itself.
Regardless, Polaroid was fairly successful for a very long time. I suppose the point is that people are willing to go a long way to get instant photos, and apparently image quality and size is not high on the requirements list.
This theme has persisted into the digital realm as well. The quality of a photo is almost irrelevant to a majority of the point-and-shoot population. Many pictures aren't meant to adorn the halls of an art museum; they're just an aid to help unlock a specific memory. The Facebook comments under the picture are almost as important as the image itself. I've seen people post phone screenshots to Instagram because it was easier than actually downloading and saving the image they were looking at. That 0.8MP version of that 8MP image is "good enough" so why bother use anything better?
Here's a Polaroid picture of me on the first day I soloed when I was working on my private pilot's license:
It's blurry, the colors are washed out, and the image itself is pretty small. But who cares? A higher resolution picture won't tell you that I was nervous as hell and sang "Bang on the Drum All Day" the entire time I was in the air while secretly fearing that I was somehow accidentally holding down the transmit button and doing impromptu karaoke to the entire airport.
The real issue with Polaroid has never been image quality, it's been price. I remember feeling very nervous when using a Polaroid camera as each press of the shutter was another $2-3 spent. It's almost as if the apprehension associated with the price tag was directly at-odds with the spontaneity of instant images in general.
So while eating a club sandwich in the Nordstrom Grill, I thought it might be cool to take both of these issues to their extremes. Make a camera the produces extremely low quality instant images for an extremely low price. You still get the novelty and benefits of a physical keepsake, and as long as the pictures are somewhat recognizable, they still serve the purpose of helping you catalog and recall memories.
Conveniently, Christmas is coming up, and this is the perfect gift for my sister who has made a hobby of working with novelty toy cameras. They don't take super amazing pictures, but they have a bunch of really neat lenses that let you do things like extend the image frame to cover the sprocket holes or shoot 120 film. Here's a roll that we developed together:
It's some buildings and clouds in Korea.
So the task was to produce a portable camera that can print images instantly using an optical module and a thermal printer. Of course, processing a decent image quickly requires far more processing power than what's available in an 8-bit AVR, so unless I wanted my instant-pictures to take weeks, this was the perfect project to get me started on ARM.