Monthly Archives: September 2013

Two point five ways to access the serial console on your Beaglebone Black

Introduction

I recently purchased a Beaglebone Black (BBB) as a replacement for a Raspberry Pi which was providing the freebsd/arm builder for the Go build dashboard. Sadly the old RPi didn’t work out. I’m hoping the BBB will be a better match, faster, and more reliable.

The BBB is a substantial upgrade to the original Beaglebone for a couple of reasons.

The first is obviously the price. At less than $50 bucks AUD in my hand, it offers substantially better value for money than the original BB. This drive towards a lower price point is clearly a reaction to Arduinos and the Raspberry Pi. Having now owned both I can see the value the original BB offered, it’s a much better integrated package, but newcomers to embedded systems will vote with their wallets.

Secondly, the new BBB comes with 512mb of RAM onboard, up from the 256mb of its predecessor. For a freebsd/arm builder, this is very important. You also get 2gb of eMMc flash onboard, which comes preinstalled with Angstrom Linux.

Lastly, the processor has been bumped from 720Mhz to 1Ghz, providing you can provide sufficient current.

Of the original Beaglebone features that were cut were JTAG and serial over USB. This last point, the lack of a serial port, is the focus of the remainder of this article.

The serial pins on your Beaglebone Black

J1 serial port header

J1 serial port header

The Beaglebone Black serial port is available via the J1 header. This picture is upside down with respect to the pin numbers, pin 1 is on the right and pin 6 is on the left.

Method number one, the FTDI USB to Serial adapter.

The first, simplest, and most recommended method of connecting to your BBB is via an FTDI USB to Serial adapter. These come in all shapes and sizes, some built into the USB A plug, others like this one are just the bare board. If you’ve done any Arduino programming you’ve probably got a slew of these little things in your kit. I got mine from Little Bird Electronics for $16 bucks.

DFRobot FTDI USB to Serial adapter

DFRobot FTDI USB to Serial adapter

The FTDI adapter can do more than just level convert between USB and the BBB’s 3.3 volt signals. This one can provide power from the USB host at either 3.3 or 5 volt as well as provides breakouts for the other RS232 signals.

Normally avoiding the power supply built into the FTDI adapter would be a problem, but the designers of the BBB have already thought of this and made it super simple to directly connect the FTDI adapter, or cable, to the BBB.

FTDI adapter mounted on the J1 header

Simply put, although the male header on the BBB matches the FTDI adapter, only pins 1, 4 and 5 are actually connected on the board. This means you don’t have to worry about Vcc on pin 3 of the FTDI adapter as the pin on the BBB is not connected.

Method number two, Prolific PL2303 USB to Serial adapter

PL2303 showing the +5v lead

This is the no no wire

The second method is similar to the previous, but this time using a Prolific Technologies PL2303 USB to Serial cable. This cable is very common if you’ve used the Raspberry Pi. I got my first one from Adafruit, but I’ve since received a few more as part of other dev board kits. You can even make your own by cutting the ends of old Nokia DKU-5 cables. Irrespective all the cables use the Prolific Technology PL2303 chipset.

The drawback of the PL2303 is the red wire, this carries +5v from the USB port and can blow the arse out of your BBB. Strictly speaking it can blow up you RPi with this cable if you aren’t careful, but in the case of the BBB, there is no safe pin to connect it; you must leave it unconnected.

PL2303 showing the +5v lead unconnected

To hook up your BBB using the PL2303 connect the black, ground lead to pin 1 on the J1 header, the green RX lead to pin 4, and the white TX lead to pin 5.

Do not connect the red lead to anything!

Method three, using a Bus Pirate as serial passthrough

Bus Pirate in UART passthrough mode

Bus Pirate in UART pass through mode

This last method isn’t really practical as most people are unlikely to have a Bus Pirate, or if they do, they’ll probably also have an FTDI or PL2303 cable knocking about.

Connect the Bus Pirate as described on this page for UART mode, connect to the BP over your serial connectoin, then type this set of commands

m # to set the mode
3 # for UART mode
9 # for 115,200 bps
1 # for 8 bits, no parity
1 # for 1 stop bit
1 # for idle 1 receive polarity
2 # for normal, 3.3v output
(1) # for Transparent bridge mode
y # to start the bridge mode

Connecting to the serial console

Independent of which method to wire up your serial console, you’ll need to connect to it with some terminal software. I recommend using screen(1) for this, although some people prefer minicom(1). If you’re on Windows I think your options are limited to Teraterm Pro, but that is about all I know.

Using screen is as simple as

% sudo screen $USBDEVICE 115200

Which will start a new screen session at the almost universal speed of 115200 baud. The name of your USB device depends on your operating system. To quit screen, hit control-a then k.

Drivers

If you are using Linux, every modern distribution has drivers for the PL2302 and FTDI, nothing is required, but check dmesg(1) for the name of your device.

If you are using OS X, you will neither device is supported out of the box so you will have to download and install the drivers.

Devices names

  • On Linux, the device will be /dev/ttyUSB0 reguardless of the type of cable you are using.
  • On OS X, the name of the device depends on its driver.
    • For the FTDI driver, the device will start with /dev/tty.usbserial, eg, tty.usbserial-AD01U7TH.
    • For the PL2303 driver, the device will start with /dev/tty.PL2303, eg. tty.PL2303-000012FD.

Wrapping it up

I’m really impressed with the Beaglebone Black. While not as powerful as something like a Odroid-X2, or Pandaboard, the integration and out of the box experience is very compelling. Little touches like the layout of the J1 serial header give me confidence that the designers didn’t just aim for the lowest price point throwing quality to the wind; Cubieboard, I’m looking at you.

Should I actually get freebsd/arm up and building on the BBB, I’ll make a separate post about that.

#golang tweet popularity

Clearly I’m biased when it comes to the popularity of Go, so here is another data point.

[line_chart title=”#golang tweets per month” v_title=”tweets” width=”600px” height=”400px” scale_button=”true”]
[‘Month’, ‘Tweets’],
[ ‘2009-11’ , 60 ],
[ ‘2009-12’ , 31 ],
[ ‘2010-01’ , 14 ],
[ ‘2010-02’ , 36 ],
[ ‘2010-03’ , 56 ],
[ ‘2010-04’ , 57 ],
[ ‘2010-05’ , 62 ],
[ ‘2010-06’ , 81 ],
[ ‘2010-07’ , 149 ],
[ ‘2010-08’ , 106 ],
[ ‘2010-09’ , 225 ],
[ ‘2010-10’ , 139 ],
[ ‘2010-11’ , 219 ],
[ ‘2010-12’ , 102 ],
[ ‘2011-01’ , 173 ],
[ ‘2011-02’ , 204 ],
[ ‘2011-03’ , 258 ],
[ ‘2011-04’ , 251 ],
[ ‘2011-05’ , 694 ],
[ ‘2011-06’ , 557 ],
[ ‘2011-07’ , 393 ],
[ ‘2011-08’ , 444 ],
[ ‘2011-09’ , 401 ],
[ ‘2011-10’ , 456 ],
[ ‘2011-11’ , 385 ],
[ ‘2011-12’ , 369 ],
[ ‘2012-01’ , 344 ],
[ ‘2012-02’ , 558 ],
[ ‘2012-03’ , 877 ],
[ ‘2012-04’ , 508 ],
[ ‘2012-05’ , 450 ],
[ ‘2012-06’ , 656 ],
[ ‘2012-07’ , 782 ],
[ ‘2012-08’ , 785 ],
[ ‘2012-09’ , 1132 ],
[ ‘2012-10’ , 1052 ],
[ ‘2012-11’ , 773 ],
[ ‘2012-12’ , 888 ],
[ ‘2013-01’ , 970 ],
[ ‘2013-02’ , 1439 ],
[ ‘2013-03’ , 1478 ],
[ ‘2013-04’ , 1917 ],
[ ‘2013-05’ , 4714 ],
[ ‘2013-06’ , 5891 ],
[ ‘2013-07’ , 6599 ],
[ ‘2013-08’ , 6886 ]
[/line_chart]

Data courtesy of trendsmap

Release candidate 1 tarballs for ARM now available

Go 1.2 is on target for a December release and the Go team have just cut their first release candidate.

You can find the draft (no twitterverse, Go 1.2 isn’t released yet) release notes for Go 1.2 online here.

I have updated my unofficial ARM tarball distributions page with prebuilt go1.2rc1 tarballs. You can find them by following the link in the main header of this page.

If you are interested in following the performance improvements in Go 1.2, you may be interested in my autobench project.

Using Juju to build gccgo

The port of Juju to Go is a project I’ve been involved in at Canonical for some time now. The power behind Juju is charms, which are part configuration management and part reliable workflow engine.

One non-conventional use of Juju is something I cooked up a while ago when traveling, a Juju charm that compiles gccgo. This charm can be used to compile gccgo on a powerful instance in your cloud rather than on your puny laptop without having to worry about finding all the various dependencies that a modern gcc build requires.

The gccgo charm encapsulates all the instructions in http://golang.org/doc/install/gccgo, all you need to do is deploy it and wait for the result.

Getting started

To get started using the gccgo charm, checkout my charms repository from GitHub.

% cd $HOME
% git clone https://github.com/davecheney/charms

Bootstrap a juju environment

Each Juju service (an instance of a charm) needs to be deployed into a running environment. I’ve bootstrapped an environment on Amazon AWS as they have a nice 8 core machine which will get the job done quickly.

% juju bootstrap -e ap-southeast-2

Deploying the gccgo charm

The next step is to deploy an instance of the gccgo charm from my local charm repository. By default Juju requests the equivalent of an m1.small so we use a deploy time constraint to request a machine with a larger number of cores. The gccgo charm automatically adjusts itself to use all CPUs on the target machine.

% juju deploy --constraints "cpu-cores=8" --repository $HOME/charms \
     local:raring/gccgo

Monitoring the status of the build

All the magic of the build phase takes place in the hooks/start hook, so the build will stay at installed until the build completes (or fails).

% juju status gccgo
environment: ap-southeast-2
machines:
  "1":
    agent-state: started
    agent-version: 1.15.0.1
    dns-name: ec2-54-253-4-102.ap-southeast-2.compute.amazonaws.com
    instance-id: i-22c92a1e
    instance-state: running
    series: raring
    hardware: arch=amd64 cpu-cores=8 cpu-power=2000 mem=7168M root-disk=8192M
services:
  gccgo:
    charm: local:raring/gccgo-12
    exposed: false
    units:
      gccgo/0:
        agent-state: installed
        agent-version: 1.15.0.1
        machine: "1"
        public-address: ec2-54-253-4-102.ap-southeast-2.compute.amazonaws.com

You can also monitor the output of the build process itself using the juju debug-log command.

Grabbing the results

The gccgo charm has a number of configuration variables you can use to tweak the build process if necessary. The gccgo charm produces a tarball as its final result once the service moves to started state.

% juju get gccgo
charm: gccgo
service: gccgo
settings:
  prefix:
    default: true
    description: gccgo build prefix
    type: string
    value: /opt/gccgo
  tarfile:
    default: true
    description: gccgo final tarball
    type: string
    value: /home/ubuntu/gccgo.tar.bz2
  work:
    default: true
    description: gccgo build directory
    type: string
    value: /home/ubuntu/work

Now we know the location of the tarball, we can use the juju scp command to fetch it.

juju scp gccgo/0:/home/ubuntu/gccgo.tar.bz2 /tmp

Cleaning up

8 core virtual machines don’t come cheap, don’t forget to destroy this environment (or at least destroy the service and remove the machine) once you’re done.

# destroy service and remove build machine
% juju destroy-service gccgo
% juju destroy-machine 1    # from the output of juju status above
# or destroy the environment
% juju destroy-environment -y

How to include C code in your Go package

It looks like Go 1.4 will remove support for Go packages containing C code (as described below, don’t confuse this with CGO), so enjoy it while it lasts.

This is a short post designed to illustrate how Go package authors can write package level functions in C and call them from Go code without using cgo. The code for this article is available on GitHub, https://github.com/davecheney/ccode.

Some warnings

Before we start, there are a few warnings that need to be spelled out

  • Using C code is inherently unsafe, not just because it unholsters all the C footguns, but because you can address any symbol in the runtime. With great power comes great responsibility.
  • The Go 1 compatibility guarantee does not extend to C code.
  • C functions cannot be inlined.
  • Escape analysis cannot follow values passed into C functions.
  • Code coverage does not extend to C functions.
  • The C compilers (5c, 6c, 8c) are not as optimised as their companion Go compilers, you may find that the code generated is not as efficient as the same code in Go.
  • You are writing plan 9 style C code, which is a rough analogue of C89.

Returning a value

The first example is a simple function called True that always returns true. 

void ·True(bool res) {
        res = true;
        FLUSH(&res);
}

Even with this simple example there is a lot going on, let’s start with the function signature. The signature of True is void ·True(bool res). The void return code is required as all C to Go interworking is done via arguments passed on the stack. The Interpunkt, the middle dot, ·, is part of the package naming system in Go. By proceeding the name of the function with · we are declaring this function is part of the current package. It is possible to define C functions in other packages, or to provide a package name before the interpunkt, but it gets complicated when your package is heavily namespaced and so is beyond the scope of this article.

The next part of the function signature is the return argument specified in the C declaration style. Both calling and return arguments are supplied as parameters to any C function you want to call from Go. We’ll see in a moment how to write the corresponding forward declaration.

Moving on to the body of the function, assigning true to res is fairly straight forward, but the final line, FLUSH(&res) needs some explanation. Because res is not used inside the body of the function a sufficiently aggressive compiler may optimise the assignment away. FLUSH is used to ensure the final value of res is written back to the stack.

The forward declaration

To make the True function available to our Go code, we need to write a forward declaration. Without the forward declaration the function is invisible to the Go compiler. This is unrelated to the normal rules for making Go a symbol public or private via a capital letter.

A forward declaration for the True function looks like this 

// True always returns true.
func True() bool

The forward declaration says that True takes no arguments and returns one boolean argument. As this is a normal Go function, you can attach a comment describing the function which will appear in godoc (comments on the function in C code will not appear in documentation).

That is all you need to do make True available to Go code in your package. It should be noted that while True is a public function, this was not required.

Passing arguments to C functions

Extending from the previous example, let’s define a function called Max which returns the maximum of two ints. 

void ·Max(intptr a, intptr b, intptr res) {
        res = a > b ? a : b;
        FLUSH(&res);
}

Max is similar to the previous function; the first two arguments are function arguments, the final is the return value. Using res for the name of the return argument is not required, but appears to be the convention used heavily throughout the standard library.

The type of a and b is intptr which is the C equivalent of Go’s platform dependant int type.

The forward declaration of Max is shown below. You can see the how function arguments and return values map between Go and C functions. 

// Max returns the maximum of two integers.
func Max(a, b int) int

Passing addresses

In the previous two examples we have passed values to functions and returned copies of the result via the stack. In Go, all arguments are passed by value, and calling to C functions is no different. For this final example we’ll write a function that increments a value by passing a pointer to that value. 

void ·Inc(intptr* addr) {
        *addr+=1;
        USED(addr);
}

The Inc function takes the address of a intptr (a *int in Go terms), dereferences it, increments it by one, and stores the result at the address addr. The USED macro is similar in function to FLUSH and is used mainly to silence the compiler.

Looking at the forward declaration, we define the function to take a pointer to the int to be incremented. 

// Inc increments the value of the integer add address p.
func Inc(p *int)

Putting it all together

To demonstate using these C defined functions in Go code I’ve written a few tests which exercise the code. The code for the tests are here, and the results of running the tests are shown below. 

% go test -v
github.com/davecheney/ccode
=== RUN TestTrue
--- PASS: TestTrue (0.00 seconds)
=== RUN TestMax
--- PASS: TestMax (0.00 seconds)
=== RUN TestInc
--- PASS: TestInc (0.00 seconds)
PASS
ok      github.com/davecheney/ccode     0.005s

Conclusion

In this short article I’ve shown how you can write a Go package that includes functions written in C. While a quite niche use case, it may come in handy for someone and also lays important groundwork for writing packages containing functions in raw assembler.

Autoworkers of our generation, a response

A few days ago a post entitled Autoworkers of Our Generation floated across my radar. In his post, Greg Baugues argues that as developers, we have a short term advantage, and would do well to view our lot as a temporary anomaly. In this article I’d like to engage with his post, and respond.

The key analogy of Baugues’ post is the parallel between the Detroit auto worker of the 1980’s and the Macbook hugging developer of the new millennium. Without disagreeing with the latter characterisation, I believe the analogy with the auto worker is flawed.

Detroit, or more generally, the American car industry of the ’80s was highly uncompetitive. The Go-Go decade of Wall Street had distorted the market for home made vehicles, With the oil crisis of the previous decade a distant memory, local car manufacturers pursued larger, more expensive vehicles, presenting them as aspirational symbols of bull market opulence. Luxury sticker prices supported the wage claims of Motor City’s highly unionised workforce and for a time there was a virtuous cycle; an affluent customer base drove demand for more expensive vehicles supporting an inefficient manufacturing sector.

The results spoke for themselves. By the 90’s, foreign manufacturers moved in to capture the under serviced budget car market and created a beachhead to attack the local luxury brands from a lower manufacturing cost base. Responses from the lobbing industry in the form of import tariffs, did nothing to solve the underlying structural problems and delayed the restructuring of the domestic producers. As a last ditch measure, the local manufacturers aggressively pursued off-shoring and automation, decimating the lives of many of middle class Rust Belt families.

The parable that Baugues’ tells is clear; if you or your parents were manufacturing cars in the 80’s, you could be forgiven for thinking that you had it made. However, to accept Baugeus’ analogy of the misfortune that vested on Michigan, is to accept that software development is a purely mechanical action, prescribed, just as the creation of a motor car on a production line. I cannot agree with this. 

My career in the computer industry started in the mid 1990’s. I was there for the hysteria of the Y2k fiasco, and saw the effects of a generation of university graduates, late to the party, but none the less eager to share the spoils of unbounded consulting hours, meet the reality of the dot com collapse. In 2001 a degree in comp sci was worthless. Yet, within a few years, the industry had bounced back. With the exception of periods of industry wide delusion the demands for software developers, or more correctly the software itself, has always been strong.

In conclusion, I accept Baugues’ thesis that an economic winter is coming. It must, if for no other reason that every other boom in a western economy is followed by a bust. But I believe the further conclusion that software development will become automated to the point it can be produced en mass, is false.

I will leave you with the recommendations of the original author:

Don’t get too comfortable. Don’t get locked into a language. Don’t burn bridges for short term gain. Keep your tools sharp. Learn soft skills. Build an audience. Save some money. Network. Read.

It’s an obscenely good time to be a developer. Enjoy it while it lasts.