Christmas holidays are a wonderful time to invent new projects. I decided I’d do some desktop coding for a change, and try to code an optimized image viewer for my old zipped pocket camera photos. First task of course was to read a zip file.
To my surprise, there wasn’t a “GNU standard library” available for this task like there is zlib for general compression, or libjpeg and libpng for images. Best match for my simple needs seemed to be Minizip, but at 7378 lines of code, and 2125 for just unzip.c (utilizing zlib so basically just file handling), I was not convinced, especially because I knew I had some very specific requirements to cater for (namely uncompressing all JPEGs to memory for fast rendering and thumbnail generation).
Zip File Structure – The Essentials
The ZIP file format turned out to be surprisingly simple, especially since I decided I would be sticking to bare essentials and skipping zip64 support, encryption, multifile zips, and all other compression methods than “store” (no compression) and “deflate” (easily decompressed with zlib, see below). Even with barebones setup, my zip routines would handle about 99.9 % of zips out there just fine.
Drawing on excellent ZIP format documentation from InfoZip’s latest appnote, the file structure I needed to parse seemed to have the following structure:
Today’s post is something I’ve prepared for a long time. Hardware-wise it’s a simple thing – ATtiny45 emulating a PS/2 device, sending a keypress when three knocks are detected in the attached piezoelectric sensor (or piezo buzzer as they are also called). But if your computer can boot on PS/2 keyboard input and you have your computer stowed somewhere hard to reach (or just want to impress your friends), it’s a pretty neat little gadget! Here’s a video of it in action:
My PC takes a few seconds to put anything on display, but if you look at the bottom right corner, you can see the blue power LEDs light up immediately after the knocks.
What You’ll Need
Hardware-wise this hack is super simple. You’ll need less than $10 in parts and many probably already have these lying around:
ATtiny45. Actually, any ATtiny or ATmega with 4kB or more flash, A/D converter and two timers will work with small adjustments, and with -Os -DMINIMAL compiler flags also 2kB MCUs (ATtiny2313 doesn’t have a A/D but you can either work around it or use a button)
Piezo buzzer and 1 Mohm resistor to act as knock sensor
PS/2 connector, or alternatively a passive USB-PS/2 adapter (I have half a dozen from old keyboards and mice) and USB cable (like the one I used in my V-USB tutorial)
Breadboard and wire. Alternatively you can solder it on a simple PCB like I eventually did.
Optionally, a 4k7 ohm pullup resistor for RESET line, and a LED and 330 ohm resistor to indicate state
The Schematic and Breadboard Setup
The PS/2 part as discussed in my minimal PS/2 keyboard post doesn’t require any other hardware than the ATtiny. The piezo element uses a 1 Mohm resistor like in the Arduino Knock Sensor tutorial, providing a path for voltage level to get back to zero over time. The LED is connected to PB4.
The PS/2 connector also provides power to the device. Instead of soldering a custom PS/2 connector for the project, I took a passive USB-PS/2 adapter I had lying around and used a multimeter to find out which USB pins correspond to the PS/2 ones. Not surprisingly, PS/2 GND and VCC are connected to USB GND and VCC. In my adapters, PS/2 clock was connected to D+ and data to D-. You can see the mnemonic printout I made on that one below, as well as one possible breadboard configuration.
The keyboard is something that I use daily, and whether I’m writing e-mails or coding, I’ll likely do several hours of typing a day. Last summer when I switched to US layout in coding and started using Vim, I started thinking that maybe I should upgrade my seven year old Logitech keyboard to something hopefully better. And when I get such a project, I did what I always do: Went totally overkill with research and ended up spending a few hundred euros once I had made up my mind on the “most optimal choice” for me. :)
My worldview after 2000 was essentially that laptop type flat keyboards are the way of the future, and keyboard choice mainly depends on whether you buy a Logitech or Microsoft one, and do you get the top of the line model or an OEM version for 15 euros. Enter Geekhack and some interesting discussions at Stack exchange, and it quickly became apparent that there is more to it.
First choice one needs to make is the layout of the keyboard. Kinesis makes some weird looking ones that some people swear by, and there are matrix-type layouts, I decided I would continue to risk carpal tunnel syndrome with a “normal” layout for the time being, as I don’t want to optimize my brain for a keyboard type that would only be available at home.
Many electronics projects involve the device transitioning from one state to another. On a high level, it could be that your project is initially in a state where it awaits input, and once it receives it, it goes to another state where it performs a series of actions, eventually returning back to the initial state. On a lower level, many communications protocols are often simple or increasingly complex state machines. In many cases, an elegantly implemented state machine can simplify your code and make it easier to manage.
There are several methods to implement state machines programmatically starting from simple if-conditions to state variables and switch structures. In this tutorial I’ll cover a slightly more advanced method of using callbacks or “function pointers” as they are implemented in C. This has some performance benefits, makes up for some clean code, and you’ll learn a bit on the way!
State Machines with Conditionals
First, to introduce the idea of a state machine, lets take a simple example: Blinking LEDs. Imagine you want the LED to turn on for a second, and then turn off. We could do it with a simple 2-state machine:
enum states {
LED_ON,
LED_OFF
};
enum states state = LED_OFF;
while(1) {
if(state == LED_OFF) {
led_on();
state = LED_ON;
} else {
led_off();
state = LED_OFF;
}
sleep(1); // sleep for a second
}
If you can understand the code above, you have pretty much grasped the fundamentals of state machines. We have some processing specific to given state, and when we want to go to another state, we use a variable (in this example it’s called state) to do that. And by the way, if you haven’t encountered enum before, you should check out Enumerated type in Wikipedia. It’s a very handful tool to add to your C coding arsenal.
I made a big step in coding geekdom this summer by upgrading the most low-level part of my programming workflow. It started when I got frustrated with Mac keyboard shortcuts on Scandinavian keyboard layout (they Just Don’t Work for most apps), and switched to US layout in coding. Once I made that transition, I started thinking that maybe I could improve my coding speed a bit more, and see what all the fuzz is about Vim.
The greatness of Vim in coding comes from the fact that Vim has separate modes for editing text, and navigating around. While not editing, all normal keys become powerful commands, and you can do text manipulation like duplicating lines, indenting sections etc. without ever leaving this “normal mode”.
Well, Vim is great, but an additional bonus to its power is the fact that almost every *nix system has it preinstalled. So even if I’m not on my own computer, I can just launch an SSH client and use Vim to edit the piece of code I’m working on. No need to compromise. Except color schemes, which I just couldn’t get working over Putty. Today I solved that puzzle after one and half hours of googling, and thought to share the findings, maybe someone will find this the next time they face the problem.
While banging my head against the wall with debugging my PS/2 keyboard thingy, I really wished I had a dedicated logic analyzer (preferably with PS/2 decoder, but even raw binary data would’ve been fine). So I decided to try out a long hatched idea – combine an ATtiny2313 and FTDI for some unlimited-length logic capturing with a PC. You’ll only need:
ATtiny2313
20 MHz crystal and caps (slower will also work, frequency just defines what baud rates you’ll achieve)
Optionally, some power-stabilizing capacitors, reset pullup and ISP programming header for flashing the firmware
ATtiny2313 is ideal for this, as it has all eight port B pins on one side in numerical order – attaching up to 8 logic lines is really straightforward. With 20 MHz crystal, baud rates close to 1 Mbps can be achieved in fast serial mode. I used Adafruit’s FTDI Friend for really simple (and way faster than most cheap serial adapter dongles) serial to USB conversion – just connect ATtiny RXD pin to TX, and TXD to RX, and you can even get power from the Friend so you’re all set! For crystal and that other stuff, see my ATtiny2313 breadboard header post for schematic, the picture above should fill you in with the rest.
Firmware code
This device has some of the smallest firmware codebases ever (firmware is 128 bytes). All we need to do is to set up UART with desired speed, and have the AVR chip to fire up an interrupt whenever data has been sent, and then use that to send current state of port B (using PINB):
#include <avr/io.h>
#include <avr/interrupt.h>
void USARTInit(unsigned int ubrr_value, uint8_t x2, uint8_t stopbits) {
// Set baud rate
UBRRL = ubrr_value & 255;
UBRRH = ubrr_value >> 8;
// Frame Format: asynchronous, 8 data bits, no parity, 1/2 stop bits
UCSRC = _BV(UCSZ1) | _BV(UCSZ0);
if(stopbits == 2) UCSRC |= _BV(USBS);
if(x2) UCSRA = _BV(U2X); // 2x
// USART Data Register Empty Interrupt Enable
UCSRB = _BV(UDRIE);
// Enable The receiver and transmitter
UCSRB |= _BV(RXEN) | _BV(TXEN);
}
int main() {
// 230.4 kbps, 8 data bits, no parity, 2 stop bits
USARTInit(10, 1, 2); // replace 10 with 4 to get 0.5 Mbps
sei(); // enable interrupts
while(1) {}
return 1;
}
ISR(USART_UDRE_vect) {
UDR = PINB;
}
