Posting my initial Raspberry Pi configuration steps to enable SSH / FTP / VNC and Wifi to a WPA2 access point in case it’s of use to anyone else getting started with the Pi. WPA connection is automatic, I’ve left VNC manually started to save resources when not in use, it can be started via SSH or the console using the following command:
vncserver :1 -geometry 1024×768 -depth 16 -pixelformat rgb565
# loaded debian6-19-04-2012.img to SD card
# expanded main partition using gparted on another machine
# Linux raspberrypi 3.1.9+ #90 Wed Apr 18 18:23:05 BST 2012 armv6l GNU/Linux
sudo dpkg-reconfigure tzdata
sudo nano /etc/dhcp/dhclient.conf # set host-name
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install ca-certificates git-core proftpd tightvncserver
sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update
sudo chmod +x /usr/bin/rpi-update
sudo rpi-update # ignore error about libvchiq_arm.so
# Linux raspberrypi 3.1.9+ #159 PREEMPT Wed Jul 11 19:54:53 BST 2012 armv6l GNU/Linux
wpa_passphrase <SSID> <Passphrase> # copy hex from psk= and paste into <PSK> below
sudo nano /etc/network/interfaces
# append following to bottom:
iface wlan0 inet dhcp
After loading the planet.osm file (planet-090916.osm.bz2) into an Ubuntu 9.04 virtual machine the total disk usage was 133GB after the import. The total dropped to 115GB after doing a VMWare shrink operation however it looks like to account for future near-term expansion of the OSM data I should allow for at least 200GB of storage. I’d originally hoped to store the data on a small but fast SAS 15K RAID array on my server but the current version will only barely fit so I’ll need to consider other alternatives. It looks like costs are dropping fairly fast for some of the larger 15K SAS drives so I might defer the decision for a few months as the system isn’t required for production until the start of the year. Meanwhile I’ll just slip a 1TB SATA drive into the server for testing.
I’ve recently started importing the planet.osm file into a postgresql database using the osm2pgsql utility. When I started I couldn’t find any up-to-date statistics on the number of primitives in the database to estimate the time it would take so I’ve posted them here. I’m running on a machine with only 2GB RAM allocated under VMWare and a slow 7200RPM 1TB drive and it looks like the process will take around 5 days to complete. The final stages of creating indexes on the tables seems to be taking as long as the initial import.
Reading in file: /home/mapnik/osm/planet-090916.osm.bz2
Processing: Node(434807k) Way(33142k) Relation(212k)
Node stats: total(434807934), max(497541099)
Way stats: total(33142281), max(40900619)
Relation stats: total(212012), max(253016)
Recently I’ve been doing some work with a TinCan Tools Hammer embedded Linux board. The hammer board is a neat little piece of hardware in a 40-pin DIP form factor, it looks good from a hardware point of view although unfortunately lacking a bit in the documentation area. I had some recent frustration getting MMC/SD card support to work which turned out to be a problem in the driver, their Linux programmer tracked it down and supplied the new mach-tct_hammer.c file required to fix things from a driver point of view.
Then I had some frustration because using buildroot as per the supplied configuration was giving me different results to the filesystem loaded onto the device at the factory, namely that it ended up being mounted read only. An attempt to remount the root partition read/write complained that /proc/mounts was missing which I was able to solve by adding the following lines to the device_table.txt file:
/proc d 777 0 0 – – – – –
/proc/mounts d 777 0 0 – – – – –
/proc/devices d 777 0 0 – – – – –
Once these lines were included the root filesystem was mounted read/write by default. I then went on to add the following to device_table.txt:
/dev/mmcblk0 b 777 0 0 179 0 – – –
/dev/mmcblk0p1 b 777 0 0 179 1 – – –
/mnt/mmc d 777 0 0 – – – – –
After which I was able to successfully mount a 4GB FAT32 formatted SD card using the command:
mount /dev/mmcblk0p1 /mnt/mmc
Today I was writing an application under Ubuntu Linux where I wanted the user to be able to click on a shell script to start running the main C++ application as a daemon in the background. I found a few example scripts using the nohup and disown commands but none of them seemed to work and my application would terminate as soon as the shell window closed. I found that it was necessary to include a sleep command between spawning the process and using the $! result for the disown command.
A few of the example scripts I found didn’t include a sleep and seemed to be parts of well tested and documented packages so maybe this requirement varies by Linux distros. The following is the latter segment of the bash shell script I wrote:
nohup $INSTALLDIR/myapp </dev/null >>$INSTALLDIR/myapp.log 2>&1 &
Today I was changing my TomTom datalogger to use threads for GPS reception and initially had some linking problems despite including pthread.h in the C++ source code and adding -lpthread to the linker options. The thing that threw me at first was pthread_create linked fine but I was getting linker undefined reference errors to other common POSIX threading calls such as pthread_exit and pthread_join.
At first I was worried that arm-linux-g++ didn’t support POSIX threads and was only providing an unimplemented stub routine for pthread_create that satisified the linker but didn’t work. It turned out however that POSIX threading is supported by GCC for the ARM but it doesn’t sit well with static linking of the libraries. I’d only used static linking for initial convenience when I wasn’t sure what libraries would be required, once the project was converted to dynamic linking of the LGPL libraries required by the project everything worked fine.
By default the TomTom One doesn’t give console access over ttySAC0, instead it looks like a plug & play daemon periodically polls the port possibly for a GPRS modem. A few attempts at allowing access to the shell with TomTom Navigator running concurrently failed so rather than modifying the ttpnpd file that I use to launch my main application I created a file called SerialTTY.cap in the SDKRegistry directory:
And in the bin directory created a small shell script called SerialTTY to perform the redirection between the shell and the /dev/ttySAC0 port:
stty -F /dev/ttySAC0 115200
sh < /dev/ttySAC0 > /dev/ttySAC0 2>&1
All works well and after the initial period I didn’t see any more interference from the plug & play daemon. I noticed in the /bin directory (on the internal filesystem) that the lrz binary is provided and successfully used it to perform a zmodem file transfer. In conjunction with a few scripts this may be a more convenient way to transfer new binary images to the device rather than going through the reboot required when using the USB mass storage interface.
I was just attempting to use the /dev/buz device on a TomTom One V3 for debugging purposes but the test code below failed on the attempt to open the device driver despite trying a few combinations of open flags. The device seemed to be installed OK but I noticed in the Barcelona kernel source it is written for exclusive access so presumably the main ttn application opens it. I need the navigator application open while debugging my app so tomorrow will take a look at getting something out of a serial port.
int fd = open(“/dev/buz”, O_RDONLY | O_NONBLOCK | O_NOCTTY);
cout << "fd: " << fd << endl;
int result = ioctl(_IO('U', 3), 0);
cout << "result: " << result << endl;
Recently I picked up a FriendARM board from E-Bay for $US110 which wasn’t a bad price for the package that included accessory cables and a parallel port JTAG dongle. Package also included Protel schematics for the board which is based on a Samsung S3C2440 ARM9 CPU and includes ethernet, serial, small EEPROM, LCD touch screen, audio in/out and a few other goodies including convenient access to some TTL general purpose I/O lines. The CDROM also included a few software packages it probably shouldn’t have ;-). Unfortunately a lot of the documentation is written in Chinese however I won’t have much trouble piecing things together from the schematic, kernel sources and example code that are largely in English.
I’d hoped to get some design ideas from the board and use the S3C2440 in an upcoming Linux industrial computer that I’m contemplating putting together. Unfortunately it appears Samsung are one of those companies that treats their datasheets like crown jewels and my request for a datasheet was declined. I probably could have persisted and obtained the datasheets but would like to keep the design open and don’t want end-users of the product to have to jump through hoops to optain the datasheets. At this stage I might tend towards an Atmel device like the AT91SAM9260 which is widely available and has datasheets and code examples that can be readily downloaded as you’d expect. It is also available in a PQFP package to avoid BGA setup costs.
Small C++ source code fragment to kill a certain number of instances of a process running under Linux. For example the following sends a terminate signal to the first 999 processes with the process name Tomahawk.
killproc(“Tomahawk”, “-TERM”, 999);
int killproc(const string procname, const string killcmd, const int killcnt)
int proccnt = 0;
const string procdir("/proc");
DIR* dir = opendir(procdir.c_str());
string searchstr = "(" + procname + ")";
struct dirent *d;
while ((d = readdir(dir)) && proccnt < killcnt)
if( d->d_type == DT_DIR && dirname != "." && dirname != ".." && isdigit(dirname))
string fn = procdir + "/" + dirname + "/stat";
if (getline (f, line) && line.find(searchstr) != string::npos)
string procid = line.substr(0, line.find(" "));
string cmd = "kill " + killcmd + " " + procid;