Posts Tagged ‘embedded systems

C.H.I.P. or Raspberry Pi Zero

Posted in Technicalon Dec 2, 2015

There are two really cheap small single board computers coming out, and while I haven’t yet had a chance to play with either, I have some opinions based on the specifications of each.

The Raspberry Pi Zero is a $5 slimmed down version of a Raspberry Pi. To get it running, you need a microUSB power supply and a microSD card. To view any output, you would need a mini-HDMI cable to connect to a display. To provide any input, or for any network connectivity, you would need a USB adapter, like a USB-OTG cable, and then the appropriate USB device. (Alternatively, you could solder something to the GPIO holes.)

The C.H.I.P. is a $9 computer which comes with 4 GB of flash, built in Wifi, and Bluetooth. To get it running, all you need is a microUSB power supply. All you need is a 2.5mm composite audio/video cable to connect it to a display. For input, you can quickly connect a USB or Bluetooth device.

Both computers run Linux on a 1 GHz processor and 512 MB of RAM.

At first look, the C.H.I.P. looks to be almost twice the price of a Raspberry Pi Zero. But before you can even turn on the Raspberry Pi Zero, you have to provide a microSD card. That card eats up most or all of the $4 price difference.

So for simple operation, the C.H.I.P. provides enough to get things working faster and cheaper. If I want to turn it into a wireless IoT-styled sensor, the C.H.I.P provides everything I would need to do that but the sensor. Whereas with the Raspberry Pi Zero I would have to add the microSD card, a USB-OTG adapter, a USB Wifi Adapter, and then the sensor.

However, the C.H.I.P. has a harder time competing with high-resolution video. By itself, the C.H.I.P. only provides low-resolution composite video. You can buy a VGA module for $10 or an HDMI module for $15. The Raspberry Pi Zero provides HDMI output with just your adapting cable.

The Raspberry Pi Zero also allows greater storage flexibility. Want 32 GB? Simply use a 32 GB microSD card. With the C.H.I.P., you would need to add USB storage.

So whether the Raspberry Pi Zero wins or looses over the C.H.I.P., depends on the application. But for many IoT applications, I think the C.H.I.P. provides more bang for the buck.

Over the last few years, Google has been working on their own pet programming language, called Go.  It is a high level language that is compiled to native binary code.  I took a quick look at Go to determine whether or not it would be good on an embedded system.


It is very easy to build a cgo compiler that will cross compile to ARM.  If you are using ARM or x86 for your embedded system, you can have a program compiled and running on your system in just a few minutes.  If you are using another architecture, you may be out of readily available support, but not out of luck–the gccgo compiler may provide just what you need.

Go links everything statically.  This means that you never have to worry about getting all the run-time dynamically linked libraries at just the right version on your embedded system.

Go is a nice high-level language that doesn’t require an interpreter.  Interpreters can be big and slow, which isn’t ideal for an embedded system.


Go binaries are big.  This is because everything is always statically linked.  Go binaries also contain a certain amount of run-time overhead like garbage collection.

Go was developed first for x86.  Support for other architectures have come after support for x86, so running Go on an ARM isn’t as well tested as running Go on an x86.

Go is new.  You don’t get years and years of experience with Go as you would with other languages like C++.  Additionally, you are less likely to find highly-experience Go programmers as you would with other more common langauges.


Because Go binaries are big, it makes it impractical to use Go on an embedded system except for in a few cases.  If you have lots and lots of storage on your embedded system, Go becomes more practical. If you are using Go to write a single monolithic program for your embedded system, the binary size overhead may be less of an issue.  If you want to write lots of small applications (which use dynamically linked libraries) than Go is not for you.

Because Go is new, it may not have seen as much testing as might be needed for critical embedded systems.  But if you need to quickly get a prototype working, Go might speed up development.  I would imagine that a large company might want to stay away from Go for now, but small startups who like to take risks might justify using Go to capture the big development rewards.

I’m taking an open source software engineering class at PSU, and I have a presentation to the class about Embedded system programming, and how writing open source software for embedded systems is different than writing other types of open source software.

Many articles on the web introduce the Open Source concept to embedded system engineers, this presentation attempted to do the opposite: introduce embedded system engineering to open source advocates.

Embedded Open Source