Blogspam Poems

These are unedited excerpts from blogspam that I’ve received over the past few days.

Sometimes it resembles a koan:

s other words, how do you try to look for blogging that suit a few things i prefer to found out about? Truly does virtually anyone learn how to BROWSE through blogging by simply issue or perhaps no matter what for digg?

Other times it’s more dada (this is from a long blogspam that resembled a chapter from Naked Lunch):

In front signing truncate are totalitarian you forced to consider. grasp your scope has roughly your problems. They at odds with you guarantees paroxysm durability. They commend you equip your marque home.

This one is more prosaic but I like the bit about beloved beans:

Basically decide on suitable and i also was optimistic that your particular venture will do delights. you8217re going to get the bigger assortment of your most attractive-beloved beans.

Finally, here we have one that feels a bit like a haiku:

Exchanging visiting to know more friends in the blog circle, so that many green hand can grow up~~~ lol~~~thanx for the advice ..I got many helpful imformation….so I can choose what I want~~~shopping on the line~~~lol

Keep up the good work, spammers, and don’t think for a second that your efforts are going unappreciated.

Thoughts on Embedded Development Boards

An embedded development board is an off-the-shelf part that includes a microcontroller and some peripherals, mounted on a PCB. It tries to not get in the way of whatever you want to do, but instead makes it easy to start writing software and attaching hardware. Some boards even include a bit of prototyping space. The idea is that developers are then free to create a custom PCB in parallel with the main hardware and software development—if at all. Historically, many embedded development boards were not that cheap and worse, to use them you needed a proprietary compiler. GCC has changed this landscape dramatically.

In the embedded software class that I’ve taught for the last 10 years, we’ve used four different development boards as the basis for labs. Two of these boards had very small user communities. One of these was the Olimex LPC-H2129 board, which I chose because it gives easy access to every pin on the MCU and also because at the time (2004, I think) it was one of the cheapest ARM boards I could find that had all of the features I wanted. However, support is nonexistent and the grand total amount of documentation for this board is a 3-page PDF. I have not-fond memories of wasting a bunch of time getting the compiler, bootstrap loader, debugger, etc. working on both Windows and Linux. Another board that we used in class had much better documentation but again a tiny user community. I was also not a big fan of the CodeWarrior IDE for this board, particularly once it became based on Eclipse and started requiring increasingly arcane sequences of GUI actions to accomplish even simple tasks.

The biggest recent change in embedded development boards is due to the large user communities that have coalesced around platforms like Arduino (>>100,000 posts in the forum), Raspberry Pi (~100,000 posts) and mbed (~20,000 posts). These are incredibly valuable resources for novices since it means there are searchable answers to almost any common question and probably people who are willing to discuss more esoteric problems if asked nicely. I used to feel a bit sad that there didn’t seem to be a good modern equivalent of the great hobbyist platforms of my childhood (Timex Sinclair, Apple II, Trash-80, etc.). However, this situation has totally changed and things are awesome now. While there are plenty of things I want in a RPi-like board (ADCs, WiFi, a Cortex A9) at some level this seems like a nearly-mature platform: it already offers excellent prototyping capabilities while also serving as a usable UNIX machine.

High-Resolution Timing on the Raspberry Pi

Just to be clear, this post is about measuring the times at which events happen. Making things happen at specific times is a completely separate (and much harder) problem.

The clock_gettime() function (under Raspbian) gives results with only microsecond resolution and also requires almost a microsecond to execute. This isn’t very helpful when trying to measure short-duration events. What we want is access to the CPU’s cycle counter, which gives closer to nanosecond resolution and has low overhead. This is easy to accomplish:

static inline unsigned ccnt_read (void)
{
  unsigned cc;
  asm volatile ("mrc p15, 0, %0, c15, c12, 1" : "=r" (cc));
  return cc;
}

The problem is that if you call this code from user mode, your process will die due to executing an illegal instruction. By default, user mode does not get to read the cycle count register. To change this, we need a silly little LKM:

#include <linux/module.h>
#include <linux/kernel.h>

/*
 * works for ARM1176JZ-F
 */

int init_module(void)
{
  asm volatile ("mcr p15,  0, %0, c15,  c9, 0\n" : : "r" (1));
  printk (KERN_INFO "User-level access to CCR has been turned on.\n");
  return 0;
}

void cleanup_module(void)
{
}

After the insmod call, the cycle count register will be accessible. For all I know there’s a good reason why this access is disabled by default, so please think twice before using this LKM on your security-critical Raspberry Pi. (UPDATE: See pm215’s comment below, but keep in mind that if a local user wants to DOS your RPi board, there are many other ways to accomplish this.)

Annoyingly, the Raspbian folks have not yet released a kernel headers package for the current kernel (3.2.27+). Also, an LKM compiled against older headers will fail to load. However, this thread contains a link to some updated headers.

Here’s a tarball containing the code from this post and also a compiled LKM for the 3.2.27+ Raspbian kernel.

I’m writing this up since cycle counters are awesome and also stupid problems like the missing kernel headers made it take an embarrassing amount of time for me to get this going. There’s a lot of ARM timer code out there but all of it that I found is either intended for kernel mode or else fails to work on an ARM11 chip. I actually had to read the manual to make this work.

The solution here is the best one that doesn’t involve modifying the kernel. A better approach would be to expose this functionality through /proc.