(I was messing around with PIL and realised that the dithering capabilities were perfect for my graphical LCD. As you can see, it turned out rather well!)

Python 2.5 or 2.6?

I am a 2.6 guy, but if you are using PyGTK on Windows, 2.6 is a bad way to go. As of 2.6, the default compiler for python is VS2008, not MinGW. All of the binaries that are compiled by the gnome groups are done with MinGW, so you can’t actually use these with 2.6 (or at least I couldn’t). It sucks, I know. If you start getting errors like this:

"C:\libs\Python-2.6.1\Lib\site-packages\gtk-2.0\gobject\constants.py", line
22, in <module>
    from _gobject import type_from_name
ImportError: DLL load failed: The specified module could not be found.

you need to roll back to 2.5.

Lots of installers

To install PyGTK, run these installers (in this order):

1. python-2.5.4.msi
2. gtk2-runtime-2.16.0-2009-03-22-ash.exe
3. pycairo-1.4.12-2.win32-py2.5.exe
4. pygobject-2.14.2-2.win32-py2.5.exe
5. pygtk-2.12.1-3.win32-py2.5.exe

Then jump into python and check that it has installed okay:

>>> import gtk
>>>

In case these packages ever go away, I will mirror them here. Happy pythoning!

Installing/Removing Software

The first thing we need to do is remove the Xorg joystick driver.

sudo apt-get purge xserver-xorg-input-joystick

This stops it meddling with your joystick once and for all. To make things easier, we will install jscalibrator to test the controller.

sudo apt-get install jscalibrator

If you now run jscalibrator from the command line, it should detect your joystick/gamepad and look something like this:

If you see the name of your controller in the titlebar, all is well! If you don’t, then the HAL is not detecting your controller and you need to fix that problem first (beyond the scope of this tutorial). My controller is a Logitech Wireless Xbox controller that a friend gave me. It was broken, so I fixed it and I modified to work with a PC usb port. It’s okay if none of your button presses show up at the moment, that is what we are trying to fix. To make sure that HAL is working, you can type

lshal | grep "<controller name>"

where <controller name> is the name in the titlebar of jscalibrator. So for me it look like this

jeremy@jer:~$ lshal | grep "Logitech Xbox Cordless Controller"
info.product = 'Logitech Xbox Cordless Controller' (string)
input.product = 'Logitech Xbox Cordless Controller' (string)
jeremy@jer:~$


And it shows up! This step is actually unnecessary because jscalibrator gets the names from the HAL, but it is nice to know how everything ties together!

Adding your joystick to the HAL exceptions list

As far as I can tell, Xorg currently assumes all joysticks to be mice simply because it does not know any better. So in order for it to leave the joystick alone we have to tell HAL to keep it away from Xorg. To do this, open

/etc/hal/fdi/policy/joystick.fdi

with your favourite sudo-ed editor and change it to look like this (it should be a new file):

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="input.product" contains="Logitech Xbox Cordless Controller">
<remove key="input.x11_driver" />
</match>
</device>
</deviceinfo>

except in the place of “Logitech Xbox Cordless Controller” put the name of your controller. For completeness sake, we need to restart HAL so it reads our new policy file:

sudo /etc/init.d/hal restart

Now log out and log back in to restart the X server, and your joystick should be good to go! Try clicking some buttons and moving around the joystick in jscalibrator to test it.

I bought a unibody Macbook 13″ and love it .

No-one probably comes here since I was serving 500s for about 3 months, so I best get writing again!

The real reason behind this whole thing is price. From Little Bird, the cheapest Arduino is $17.50 while the sale is on, and that has no USB chip on it. The ones with the USB chip are >$40, not to mention the price of accessories. An Atmega88 at Futurlec is $3.80, a crystal is $1, caps are a few cents and so is the pullup resistor for reset (this will all be explained in a later post).

Development Environment

The basic tools I use for AVR development are:

• AVR Studio - A free IDE with AVR Simulator built in
• WinAVR – A free C compiler for AVRs (based on gcc) and other tools
• STK500 – There is a multitude of free or prebuilt development boards on the net

You won’t need any of these till the next tutorial; we are just going to talk about hardware for now.

AVR Hardware

You can find the datasheet for the Atmega88 here. Download it and save it somewhere safe or take it down to the print shop and get it bound; you are going to need to use it a lot. To start with today, let’s take a look at all the funky acronyms on the first page. Make sure you have it open in a different browser window or tab so you can follow along (a wikipedia tab can’t hurt either).

RISC stands for Reduced Instruction Set Computer. An instruction is exactly what you think it is; a piece of information passed to the CPU telling it to do something. Examples include MOV (Move), AND (Bitwise AND) and LEA (Load Effective Address). As you can see by the next line on the page, the AVR only has 131 instructions so after a bit of practice you can pretty much remember the whole set. As a point of comparison, the regular x86 architecture for PCs is a CISC architecture (Complex Instruction Set Computer) and has thousands of instructions. The beauty of a high level programming language like C is that you don’t need to remember any instructions; the compiler translates your code into the correct ones depending on the architecture you are compiling for.

The next line tells you that the mega88 has 32 8bit registers (the size of a C char). Registers act in a very similar way to memory, but they are located inside the CPU and thus are much, much faster to access. The “Fully Static Operation” bullet simply indicates that, as long as power is still applied, the AVR will maintain its current state if you take the clock source away and will pick up where it stopped once the clock is enabled again. 20 MIPS @ 20MHz means that it can process 20 million instructions per second when the clock source is 20MHz; pretty snappy!

You have 3 types of memory inside of an AVR: Flash, EEPROM and SRAM. The flash is where you store your code (the binary equivalent of all your instructions). Flash is non-volatile, meaning that it will not be erased if you take away the power. Whilst you can reprogram the flash memory while your code is running, it can cause all sorts of nasty things to happen so just assume that flash is read only unless you are using a device programmer or loading new code. So how do you store things between power cycles then? EEPROM (Electrically Erasable Programmable Read Only Memory) is also non-volatile, but you can read and write to it as much as you want (the name is kind of a misnomer). Just remember though, the EEPROM has a limited number of guaranteed erase cycles (100 000 for the mega88) so don’t go too nuts writing to it or it will wear down. SRAM is volatile (you will lose it between power cycles) but it is much faster than the other two types and doesn’t suffer from the wear down problem. 

Bootloaders

Let’s take a quick jump back to Arduino land. If you’ve been paying attention, you should have been wondering why you can program an Arduino without a programming device, but you need one for every other AVR. This is the result of a magical little piece of software called the bootloader. A bootloader is a piece of software that retrieves new code from a non-standard location and loads it into the flash memory. In the Arduino, the bootloader retrieves the code over USB from the Arduino software. If you look in the memory section of the datasheet, you will see one of the bullets is “Optional Boot Code Section”; this is where the bootloader resides. When you click Upload in the Arduino software, the chip is put through a soft reset, after which the bootloader starts up and waits for data over the USB port. You can write a bootloader to load code from almost anywhere but you need a real device programmer to load the bootloader onto the chip the very first time and the maximum code size is often quite small so you will need to plan accordingly (you can’t perform RSA signature checking for example). An interesting point to note here is that the Arduino bootloader pretends to be an STK500 in order to leverage the already prevalent STK500 drivers.

Device Features

In a PC, all of these components we have been talking about are separated. The CPU is a different module to the RAM, which is a different module to the Southbridge, etc. The difference between a microprocessor and a microcontroller is that in the latter most of these components are already built in. You sacrifice some flexibility for simplicity but even then, certain AVRs have an external memory interface and almost all you can connect an external EEPROM to. Some of the modules that are built in to microcontrollers are not critical to their operation but simply provide an easier way to perform common tasks. If we look at the “Peripheral Features” section on the summary page, we can see what extra tasks this AVR can handle.

The mega88 three timers, two of which are 8 bit and one that is 16. This means that the modules can count to 255 (0xFF) and 65535 (0xFFFF) respectively. All three timers can be given a separate prescaler, meaning that for n cycles of the oscillator on the device with prescaler q, the clock will increase by the closest rounded down integer of n/q. Now that is a bit of a mouthful, so an example is probably in order: if you set the prescaler to 64, then the timer will increment every 64 clock cycles. Likewise, if you set the prescaler to 1024 then the timer will increment every 1024 cycles. The “Compare Mode” refers to the timer modules’ ability to trigger interrupts. I will talk about interrupts in more detail at a later time, but they are essentially events that tell the CPU to drop everything and handle this event immediately. The “Real Time Counter with Separate Oscillator” bullet refers to the fact that you can also have a counter that increments independently of the CPU clock cycles; you provide it with its own oscillator.

The next bullet down states that the mega88 has six PWM channels. PWM, or Pulse Width Modulation, is quite a complex topic (there are still a few bits I am hazy about) but for now, just pretend that it is a way of generating analog volatages in our digital environment. The six channels means that there are six pins on the device capable of PWM.

ADC (Analog to Digital Converter) allows you to read an analog voltage. So while a regular pin could only tell you whether it is +5v or 0v, an ADC pin could tell you that the voltage is currently +2.5v or +3.8v. The “10 bit” refers to the resolution of the module, or to how many decimal places it can be accurate. 10 bit means that it can tell you with an accuracy of 0 to 1023 (0×3FF). If this doesn’t make sense, don’t worry; more on this will come later. In the TQFP and QFN packages you get 8 pins that have these ADC modules attached, while in the PDIP package you get 6. TQFP (Tiny Quad Flat Pack, see image at the top of this post) and QFN (Quad Flat No leads) are chip packages used by soldering machines and expert solderers; you will most likely come accross PDIPs (Dual Inline Packages) in your electronics capers which are much larger and, unless you have the dexterity of a neurosurgeon, easier to deal with.

UART, SPI and I²C are all data transfer protocols; USART (Universal Synchronous/Asynchronous Receiver Transmitter) is the same one the COM port on your PC uses (although COM ports have been mainly phased out by now). SPI (Serial Peripheral Interface) is a special interface for talking to high speed devices like external EEPROMs or flash memory. Finally, I²C (Inter-Intergrated Circuit) is a protocol for connecting lots and lots of devices together. I²C is the protocol you will come accross the most in microcontroller-compatable chips; things like digital I/O, digital thermometers, external ADCs, real-time clocks (actual time clocks) and more. All of these have been abstracted by the underlying hardware to make them easier to use.

Although there is a lot more in this section, I am only going to talk about two more important parts now because let’s face it, this post is already long enough. The first is the external and internal interrupt sources. The AVR has many interrupts, from a timer match to a pin being pulled to +5v to a byte being received over I²C. They are very useful because they allow the AVR to become reactive as opposed to having to check for events over and over again (this makes the code much simpler as well). Finally, we have the 23 programmable I/O lines. If you look at page 2, “Pin Configurations”, you can see that most of the pins have P followed by a letter and then a number. This is a programmable I/O line that you can set to high or low. As an example, PC5 stands for Port C, pin 5. There are four ports on the mega88. The other labels in brackets refer to the modules we have been talking about previously and the pins that they can control.

In Conclusion

So concludes the basic introduction to AVR microcontrollers. Next time, we’ll go through a simple “Hello World” type application.

I would just like to say that I understand AVRs are complex. I never said that they weren’t. But if Arduinos are too expensive to include in your project or you would like to write your own libraries for them, learning about the underlying hardware is a must. Or perhaps, like me, you just like to know what is going on under the hood.

My latest two projects: developing a photography gallery for nelpix.com and creating a sort of race timer for little remote control cars (more on that later).

Have a great year everyone!

The tip I read related to the use of if/else blocks; the article said that I would be better off without the else part by setting the else value of a variable before the if statement. I think code can explain this better than a sentence, so here it is (the for loops are to make the code run for a measurable amount of time):

# speedtest1.py
# testing the speed of two optimisations
variable = 0
 
for n in range(0, 10000000):
	i = 0
	if variable:
		i = 1
 
	variable ^= 1 # flip it!

Now the code I would normally write looks something like this:

# speedtest2.py
# testing the speed of two optimisations
variable = 0
 
for n in range(0, 10000000):
	if variable:
		i = 1
	else:
		i = 0
 
	variable ^= 1 # XOR flip!

So the next logical step would be to run both scripts through the python profiler, cProfile. My testing system is a stock Q6600 running Windows XP and Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45).
Their technique:

         5 function calls in 5.626 CPU seconds
 
   Ordered by: standard name
 
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    5.626    5.626 <string>:1(<module>)
        1    5.313    5.313    5.625    5.625 speedtest1.py:3(<module>)
        1    0.000    0.000    5.626    5.626 {execfile}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
        1    0.313    0.313    0.313    0.313 {range}

My technique:

         5 function calls in 4.619 CPU seconds
 
   Ordered by: standard name
 
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    4.619    4.619 <string>:1(<module>)
        1    4.323    4.323    4.618    4.618 speedtest2.py:3(<module>)
        1    0.000    0.000    4.619    4.619 {execfile}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
        1    0.296    0.296    0.296    0.296 {range}

As you can see from the profile reports, there is just over a whole second of difference in CPU time for each of the scripts on my system, with the “optimised” one actually being the slower one.

While it might seem like I am out to attack these optimisation posts, I actually think they are a good idea. It is interesting to see other people’s coding techniques, but one must remember that computers are pseudo-unique and that something might not work better for everyone. I suggest that people who post these techniques on their blogs should provide sample code as well, so the technique can be evaluated on a case by case basis.

Note: I didn’t mention the poster of the article because it has little to do with the problem at hand. I’m sure google will help you find it if you want it.

I gave some more Project Euler a go last week and when I came across problem 20, I knew it was time for me to finally learn how to use closures. I could not find much accessible information for beginners, so I figured I would write up what I discovered. That means it’s time to grab a cup of coffee and put on your theory cap, because this topic needs a bit of explanation.

Closures and Anonymous Functions

It is important to make a distinction between these two concepts. Too often I have seen technical books and manuals introduce them as the same thing.

A closure is a very important part of recursive programming. To unashamedly copy Wikipedia’s definition, a closure is, “a function that is evaluated in an environment containing one or more bound variables.” This means that there are one or more variables that are useable by the function in the form of local variables or arguments.

An anonymous function is a function that is not given a name.

Closure + Anonymous Function = ?

My suspicion as to why people so many people get closures and anonymous functions mixed up is because in python, they are both used for 99% of cases. The keyword used in python for this is lambda. There are also many recursion specific functions, but I will only be mentioning map() and reduce().

So first up, lets look at how one would solve this problem without recursion.

Project Euler Problem 20
n! means n*(n-1)*...*3*2*1
Find the sum of the digits in the number 100!

This is easily solvable with a few for loops:

# problem20_norecursion.py
# solving problem 20 without using recursion techniques
 
factorial_result = 1
sum_result = 0
 
for number in range(1,101): # from 1 to 100
	factorial_result *= number
 
for number in str(factorial_result):
	sum_result += int(number)
 
print sum_result

Now this works very well, but the problem seems like it can be solved in less than 7 lines. It is only two very simple operations that could be easily combined.

lambda
As mentioned previously, lambda allows us to create both anonymous functions and use closures in python. The name is derived from the calculus of recursion and function definition, lambda calculus. Creating an anonymous function is just as easy as creating a regular function, only it needs to be assigned somewhere so you can access it. Return values are not needed; they are handled automatically by the interpreter. For now, we will just use a variable. Anyone who has done a reasonable amount of python before should understand what is going on in this example:

# lambda_examples.py
# examples of the usage of lambda
 
f = lambda x: x+1
g = lambda x: x*2
h = lambda x, y: x*y
 
print f(5)
print g(5)
print h(5,6)

And the output is:

6
10
30

As you can see, the syntax is identical to a def statement.
map() and reduce()
map() and reduce() are the two most useful recursion functions in python (in my opinion anyway). Let’s take a closer look at them.

The map() function takes two arguments, the first being a function with one argument and second being a sequence. It is essentially a condensed for-loop; it takes the function and feeds it every element in the sequence individually and returns a list of the results. The trick here is to not create a function outside the map() brackets, rather to create a temporary one and pass it as an argument using lambda. A few examples might help explain this:

# examples demonstrating the map() function
 
the_list = [1, 2, 3, 4, 5, 6, 7, 8]
new_list = map(lambda x: x+1, the_list)
# new_list = [2, 3, 4, 5, 6, 7, 8, 9]
 
new_list = map(lambda x: x%2, the_list)
# new_list = [1, 0, 1, 0, 1, 0, 1, 0]

Simple, isn’t it?

reduce() is slightly more complicated. It again takes two arguments, however the function now must take two arguments. This is because after performing the operation, the return value is passed as the first argument of the next iteration. So having

result = reduce(lambda x,y: x*y, range(1,10))

is equivalent to

result = ((((((((1*2)*3)*4)*5)*6)*7)*8)*9)

It is pretty obvious which looks nicer! Hopefully you can see that reduce() will allow us to do what we need to solve this problem.

Problem 20 with Recursion

# problem20_recursion.py
# solving problem 20 using recursion techniques
 
print reduce( lambda x,y: int(x)+int(y), str( reduce( lambda x, y: x*y, range(1,101)) ))

Granted, this is not the prettiest line of code I have ever written but it clearly demonstrates how recursion allows you to pack significant complexities into a single statement. lambda with a few other functions means you can turn whole loops into a single line or perform complex operations with simple lines of code.

Besides, all the cool kids are doing it.

Things that may be useful: the Sparkfun page, the datasheet.

Communication modes

(Note: The vs1002 has a backwards compatability mode with the vs1001. We will not be using it)

The vs1002 IC does all meaningful communication over the SPI port. It has two submodes if you will, one being SCI (Serial Command Interface) and the other being SDI (Serial Data Interface). SCI is for things like play control, reading and writing registers and small technical changes. Conversely, SDI is there for MP3 data and a few testing modes.

Since the AVR has only one SPI bus, we will be sharing the CS (Chip Select) line with both submodes.

Ok, enough. Get to the code!

Not quite yet, first we need to wire it up! Since it is a fairly simple circuit, I am going to put my wiring in list form (AVR -> VS1002):

• SS -> CS
• MOSI -> SI
• MISO -> SO
• SCK -> SCLK

//spi.h
// spi functions 
 
// pin setup
#define DDR_SPI 	DDRB
#define PORT_SPI	PORTB
 
#define DD_CS	2
#define DD_MOSI 3
#define DD_MISO 4
#define DD_SCK	5
 
void spi_init(); // init the SPI subsystem
 
void cs_low(); // helpers
void cs_high();
 
char spi_send(char byte); // send a byte; return rx byte

//spi.c
// spi helper functions
 
#include <avr/io.h>
 
#include "spi.h"
 
void spi_init()
{
	DDR_SPI = 0xFF; // set the whole port to output
 
	DDR_SPI &= ~(1 << DD_MISO); // change back to input
 
	SPCR = (1 << SPE) | (1 << MSTR); // set spi clock rate to fck/4
}
 
void cs_low()
{
	PORT_SPI &= ~(1 << DD_CS);
}
 
void cs_high()
{
	PORT_SPI |= (1 << DD_CS);
}
 
char spi_send(char byte)
{
	SPDR = byte; //send byte
 
	while(!(SPSR & (1 << SPIF))); //wait until its done
	return SPDR; //return the rx byte
}

//vs1002.h
// chip control functions
 
//SCI_MODE register defines (p. 26 datasheet)
#define SM_DIFF			0
#define SM_SETTOZERO		1
#define SM_RESET		2
#define SM_OUTOFWAV		3
#define SM_PDOWN		4
#define SM_TESTS		5
#define	SM_STREAM		6
#define SM_PLUSV		7
#define	SM_DACT			8
#define	SM_SDIORD		9
#define	SM_SDISHARE		10
#define	SM_SDINEW		11
#define	SM_ADPCM		12
#define	SM_ADPCM_HP		13
 
int sci_read(char address); // serial command interface read/write funcs
void sci_write(char address, int data);
 
void send_sinewave(char pitch); // send the sinewave test

//vs1002.c
// chip control functions
 
#include <avr/io.h>
 
#include "spi.h"
#include "vs1002.h"
 
int sci_read(char address)
{
	unsigned int temp;
 
	cs_low();
 
	spi_send(0x03); //send read command, don't worry about return byte
	spi_send(address); //now send the address to read
 
	temp = spi_send(0x00); //dummy byte to get out data MSBs
	temp <<= 8; //shift it along so we can fit more data in
 
	temp += spi_send(0x00); // get the LSB
 
	cs_high();
 
	return temp;
}
 
void sci_write(char address, int data)
{
	cs_low();
 
	spi_send(0x02); //send write command
	spi_send(address); //send address we are going to write to
 
	spi_send((data >> 8) & 0xFF); //send the first 8 MSBs of the data
	spi_send(data & 0xFF); //send the LSBs
 
	cs_high();
}
 
void send_sinewave(char pitch)
{
	cs_high(); //this is different to SCI, it is data over SDI (see p.21 datasheet)
 
	/* we need to send the following bytes (see p.35)
		0x53	0xEF	0x6E
		0	0	0	0
	*/
 
	spi_send(0x53);
	spi_send(0xEF);
	spi_send(0x6E);
	spi_send(pitch);
 
	for (int i=0; i < 4; i++) spi_send(0x00); // send the filler bytes
 
	cs_low();
}

//vs1002test.c
// this program will initialise the vs1002 ic and send it the sine wave test command
 
#include <avr/io.h>
 
#include "spi.h"
#include "vs1002.h"
 
int main(void)
{
	spi_init(); //set up SPI registers
	cs_high(); // probably a good idea
 
	sci_write(0x00, (1<<SM_TESTS)|(1<<SM_SDISHARE)|(1<<SM_STREAM)|(1<<SM_SDINEW));
 
	cs_low(); // for data interface
	send_sinewave(170);
}

I will probably post some more code once I have the chip working better. I can get it to play MP3s, but they are not streaming fast enough over UART so they sound off key and distorted. If you have any questions, leave me a comment and I will endeavour to help but I’m new to this chip, so no promises .