Blogging to Nowhere

Introduction: Since finishing my Part IV Project, I’ve been threatening to do some embedded/microcontroller stuff in my spare time at home. I’ve now finally go around to it and I thought I’d start by playing with a few components I had left over from a Uni project a while back. I’ve also ordered an Arduino board (see below), but it hasn’t arrived yet. When it does, I think I’m going to have a go programming it in C rather than the random Arduino language, as I have much more experience of programming embedded systems than your average Arduino user. I’ll report on my progress when I have some!

In the Electrical and Computer Engineering Deaprtment of the University of Auckland, where I work we have a little device, internally known as the ‘DonKey’. The purpose of this is to allow easy programming of Atmel AVR based microcontrollers via USB, rather than the simpler serial interface. We also have some internally developed software to program microcontrollers via the device, unfortunately this software is pretty much windows only (we did have a successful attempt to compile it for Linux, but this was quite a while ago, a better solution would be to use a native Linux application).

Internally the DonKey uses an FTDI based USB to UART chip (specifically the FT232R) to communicate with the microcontroller. This presents some problems as, despite being the basis of the programmer on incredibly popular Arduino boards, the main Linux programming tool (AVRdude) has no official FTDI support. I think this is largely due to the use of a bootloader on the Arduino boards, which negates the need of the programming tool to directly flash the board. If however you brick the AVR on the Arduino, you would be out of luck and would need a physical programmer (more on this below).

The DonKey in all it's glory.

In this howto I’ll cover how to get the DonKey working on Linux with AVRdude. Luckily, while researching how I might go about this I found that a large part of the work had been done for me, due to the fact that the Arduino also uses these chips. I found instructions on doswa.com on how to patch and compile AVRdude for just this purpose (so you could flash a bootloader to a new AVR).

These instructions work quite well for the DonKey, up until you get to running the ‘./configure’ command, I replaced this with:

$ ./configure --prefix=$HOME/.local

to setup the code to do a local install in my home directory (as I want this to be my primary version of AVRdude, but not to screw with things on the root filesystem).

Next I followed the instructions on modifiying the makefile and compiling AVRdude via the ‘make’ command. After ‘make’ I also typed:

$ make install

to install into the directory setup earlier. Now AVRdude is installed, the next thing to do is a bit of configuration, firstly you’ll want to make sure it’s on your $PATH so add the following to your ~/.bashrc file:

export PATH=$HOME/.local/bin:$PATH

and run the command:

$ source ~/.bashrc

to re-read the file.

The next issue is that you may wish to remove any copy of AVRdude that is otherwise installed (I found that sometimes my shell would run the wrong one – especially if you use ’sudo’ to run it):

sudo apt-get remove --purge avrdude

Now, I just mentioned above that you might use ’sudo’ to run AVRdude, well according to the doswa article you do need to use sudo when using the FTDI based programmers. I’m not sure why this is, but it’s not very useful if you want to be able to call AVRdude from a Makefile or the like.

I solved this by setting a ’suid root’ on my AVRdude binary. For those that don’t know what this is, the suid bit is a Unix permission setting that makes any program with it run under it’s owning user rather than the user who called it. If the owner happens to be root, the program runs as root even if the user who calls it isn’t. This is probably really insecure if you do it a lot, but you should be OK in this case.

WARNING: Despite what I say, it might not be OK. Allowing any program unrestricted root access has the potential to hose your system and scatter all your data to the winds. FOLLOW THESE INSTRUCTIONS AT YOUR OWN RISK!!

So here we go:

$ sudo chown root:root ~/.local/bin/avrdude
$ sudo chmod u+s ~/.local/bin/avrdude

Now you should be able to successfully run AVRdude on FTDI based devices without resorting to using sudo every time.

But, what of the DonKey I hear you cry! Well all we have to do to support the DonKey is give AVRdude a little bit of configuration which tells it what the DonKey actually is. This can go in ~/.avrduderc, and looks a bit (well exactly) like this:

programmer
id = "donkey";
desc = "University of Auckland ECE DonKey";
type = ft245r;
miso = 1; # D1
sck = 2; # D2
mosi = 3; # D3
reset = 4; # D4
;

OK, now you should be able to successfully use the DonKey with AVRdude, using a command similar to this:

avrdude -c donkey -p m8 -P ft0 -U myawesomeavrproject.hex

Note: this command is for the ATMega8 as denoted by the ‘-p m8′, check the AVRdude manual page for the correct -p option if you are using a different type of AVR.

OK, well that’s pretty much it, I’ll post back soon regarding my other progress with some microcontroller stuff. Bye for now!

A while ago I covered netbooting/installation on ubuntu, well I’ve now found an even easier way to do this! It’s probably the easiest way to go about this as it really only involves editing one config file. Some of the info here comes from the official Ubuntu documentation on this, though my approach is actually easier, since you don’t need a separate tftp server.

The main piece of software you will need is dnsmasq, which you can install with the command:

sudo apt-get install dnsmasq

I already had this installed as I’m using it as a DNS cache for my network (which is also pretty useful). It turns out that dnsmasq is a bit of a ’swiss army knife’, it can do DHCP, DNS and TFTP all together and very easily. You should edit the config file:

sudo nano /etc/dnsmasq.conf (continue reading…)

Hi, it’s been a while since I’ve posted anything here, mainly because I’ve been incredibly busy with Uni and work and haven’t had time for hacking on anything interesting at home. However, I’m going to tell you about a really interesting and quite novel use for netbooks that I’ve been setting up at work, hopefully someone else will find it useful and use it in a similar way…

A while ago my boss came to me with an idea. He wanted to purchase a number of netbooks and install LimeSurvey on each of them to be used as a mobile survey unit, that could be taken to schools, colleges, workplaces, etc. and used to collect data for research projects. I pointed out that if we were to install LimeSurvey on all the netbooks each would need an individual webserver and MySQL server, which apart from being a lot of effort would fragment the dataset and make it much more difficult to collect the data together.

Hence, I suggested that we setup one of the machines as the server and set it’s built-in Wifi to work as an access point for the others so they could access the server. This means that no external network access is required, you carry the server with you! (continue reading…)

Since posting this article I have found a much easier way to do this. This article is still great background information and goes into more detail if you want to take this further, but you should consider reading my new article.

Well, I promised something technical and here it is. It’s turned into a bit of a mammoth post, but the end result is pretty cool!

The idea of being able to install your favourite Linux distro over the network and so do away with burning CD’s (which ultimately get used once and then thrown away) is tantalizing. Not to mention the serious geek points for anyone who has a boot server on their network.

I started out using this article as a reference, as the process seemed relatively simple. However, I soon found out that this article wasn’t strictly accurate and didn’t explain some things too brilliantly! So I decided to see if I could do better.

The following is my account of setting up my own boot server on a spare box I had lying around (though you can just as easily do it on your main computer). I started from a base install of Ubuntu Server 8.10 (Intrepid Ibex) which I installed in the normal way (i.e. from a CD). (continue reading…)