Computing stuff tied to the physical world

Posts Tagged ‘Linux’


Another new kid on the block

In Linux, ARM on Jun 10, 2013 at 00:01

Besides the Odroid U2 quad-core Linux board mentioned a few days ago, there’s another option in the same price range as the Raspberry Pi – the Beaglebone Black, a.k.a. “BBB”:

Screen Shot 2013-06-06 at 23.15.47

Yeah, ok, it’s slightly more expensive, but it comes with 2 GB of speedy eMMC memory built-in, whereas you need to add an SD card to make the RPi start up.

This is a bigger deal than you might think, because the BBB comes with Angström Linux pre-installed, and you can get going by simply plugging the BBB into a USB port:

  • the moment you do, a memory disk appears, and it gets auto-mounted
  • there’s a “start.htm” file you can double-click to launch your web browser
  • then just follow instructions and you’ll be up and running

This is very similar to the way the MBED ARM module works, and it shows that streamlining the first encounter really can help people to get started – fast!

From a general point of view, the Beaglebone black is actually quite different from the RPi, despite their obvious similarities of both being low-cost, low-power, yet fairly performant little Linux stand-alone boards with with keyboard-monitor-and-mouse capability and built-in Ethernet. Here’s where they differ, at least as I see it:

  • The RPi is aimed at the educational market, i.e. for learning about Linux and doing cool stuff with it once you’ve mastered that first step. Get a board, hook into a huge community, get your hands dirty, and start learning and hacking!

  • The BBB is aimed more at the embedded Linux market, i.e. for building all sorts of advanced projects with Linux and a powerful computing platform inside. Plug it in, put your Linux and physical computing skills to work, and make neat things happen!

The difference? The RPi is the most affordable solution out there, and does really well at being a complete Linux system with fairly good video and audio capabilities, but somewhat limited I/O expandability (even just thinking about how to hook up and size an expansion board on top is a puzzle). The BBB is packed with faster and more powerful hardware (but less focused on video and audio) and is loaded with expansion connectors and pins, ready to add a board, or even a whole stack of them. Even without boards on top (called capes), you have tons of I/O pins to play with – whether you need digital, analog, PWM, or all sorts of bussed interfaces, it’s often all there.

Some details about the BBB running at 300 MHz idle (it scales to 1000 MHz on demand):

# cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 297.40
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc08
CPU revision    : 2

Hardware        : Generic AM33XX (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

For a nice 20-min story about a project where RPi’s and BBB’s were used, see this video.

There’s a project called BoneScript, which aims to make the Beaglebone’s I/O capabilities as easy to use from JavaScript (i.e. Node.js) as what the Arduino IDE did for C/C++ and the ATmega’s I/O pins. Sounds like an excellent step in the right direction to me.

Either way, I see a bright future ahead for Node.js running on these little boards!


Speedy Raspberry

In Hardware, Linux on Jun 3, 2013 at 00:01

The Raspberry Pi is an amazing little board, with an amazing amount of power and functionality at an incredible price – it’s probably fair to say that our technology geek’s world will never be the same again, now that we have the RPi.

But it’s no speed monster…

Sometimes during development, it really gets in the way – especially when you’re used to working on a modern fast laptop, which is some 20 times faster (and that’s per-core).

So I decided to overclock one of my RPi’s, and see what it does. Overclocking in Raspbian is trivial with the standard raspi-config utility:

Screen Shot 2013-05-28 at 16.52.58

Just go to the Overclock section, and pick one:

Screen Shot 2013-05-28 at 16.46.48

I went for the fastest there is, but decided to run a 2-hour test to make sure it really works. Turns out that someone has already done all the work, and even created such a stress test:

root@raspberrypi:~# ./overclock-test.sh 
Testing overclock stability...
reading: 1
945+1 records in
945+1 records out
3965190144 bytes (4.0 GB) copied, 352.455 s, 11.3 MB/s
reading: 2
[...]
reading: 10
945+1 records in
945+1 records out
3965190144 bytes (4.0 GB) copied, 358.522 s, 11.1 MB/s
writing: 1
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 95.2065 s, 5.6 MB/s
writing: 2
[...]
writing: 10
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 83.4848 s, 6.4 MB/s
./overclock-test.sh: line 18:  2414 Terminated
              nice yes > /dev/null
CPU freq: 1000000
CPU temp: 58376
[    5.217175] Registered led device: led0
[    8.943589] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    9.418819] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   19.181046] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   19.431053] bcm2835-cpufreq: switching to governor ondemand
[   19.431082] bcm2835-cpufreq: switching to governor ondemand
[   21.736829] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SS
[   22.134893] ip_tables: (C) 2000-2006 Netfilter Core Team
[   22.174573] nf_conntrack version 0.5.0 (7774 buckets, 31096 max)
[  750.951153] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
Not crashed yet, probably stable.

Ya gotta love that last message, nicely semi re-assuring ;)

I did fit a set of cooling fins from Watterott (some nice IR heat pictures there):

DSC_4475

As checked with vcgencmd measure_temp, the temperature never rose above 58.4°C.

Onwards!

,

Carambola 2 power consumption

In Hardware, Linux on May 7, 2013 at 00:01

The Carambola 2 mentioned yesterday is based on a SoC design which uses amazingly little power – considering that it’s running a full Linux-based OpenWrt setup.

There are a couple of ways to measure power consumption. If all you’re after is the average power on idle, then all you need to do is insert a multimeter in the power supply line and set it in the appropriate milliamp range. Wait a minute or so for the system to start up, and you’ll see that the Carambola 2 draws about 72 mA @ 5V, i.e. roughly a third of a watt.

If you have a lab power supply, you can simply read the power consumption on its display.

But given an oscilloscope, it’s actually much more informative to see what the power consumption graph is, i.e. over time. This will show the startup power use and also allows seeing more detail, since these systems often periodically cycle through different activities.

The setup for “seeing” power consumption is always the same: just insert a small resistor in series with the “Device Under Test”, and measure the voltage drop over that resistor:

JC's Grid, page 51

Except that in this case, we need to use a smaller resistor to keep the voltage drop within bounds. Given that the expected currents will be over 100 mA, a 100 Ω resistor would completely mess up the setup. I found a 0.1 Ω SMD resistor in my lab supplies, so that’s what I used – mounting it on a 2-pin header for convenience:

DSC_4448

With 0.1 Ω, a 100 mA current produces a voltage of 10 mV. This should have a negligible effect on the power supplied to the Carambola 2 (a 1 Ω resistor should also work fine).

Here’s the result on the scope – white is the default setup, yellow is with WiFi enabled:

SCR11

Sure takes all the guesswork out of what the power consumption is doing on startup, eh?


Embedded Linux – Carambola 2

In Hardware, Linux on May 6, 2013 at 00:01

This has got to be one of the lowest-cost and simplest embedded Linux boards out there:

DSC_4447

It’s the Carambola 2 by 8devices.com:

Screen Shot 2013-05-04 at 11.02.06

The 28 x 38 mm (!) bare board is €19 excl VAT and shipping, and the development bundle (as shown above) is €33. The latter has a Carambola2 permanently soldered onto it, with 2 Ethernet ports, a slave USB / console / power port, a USB host port, a WiFi chip antenna (which is no longer on the base board, unlike the original Carambola), and a switching power supply to generate 3.3V from the USB’s 5V.

The processor is a MIPS-based Atheros chip, and with 64 MB ram and 11 MB of available flash space, there is ample room to pre-populate this board with a lot of files and software.

The convenience of the development setup, is that it includes an FTDI chip, so it comes up as a USB serial connection – you just need to find out what port it’s on, connect to it at 115200 baud via a terminal utility such as “screen” on Mac or Linux, and you’ll be hacking around in OpenWrt Linux in no time.

Note that this setup is very different from a Raspberry Pi: MIPS ≠ ARM, for one. The RPi has a lot more performance and RAM, has hardware floating point, and is more like a complete (portable) computer with its HDMI video out port. The benefit of the Carambola 2 is its built-in WiFi, built-in flash, and its low power – more on that tomorrow.

,

Node.js on Raspberry Pi

In Software on Jan 6, 2013 at 00:01

After all this fiddling with Node.js on my Mac, it’s time to see how it works out on the Raspberry Pi. This is a running summary of how to get a fresh setup with Node.js going.

Linux

I’m using the Raspbian build from Dec 16, called “2012-12-16-wheezy-raspbian”. See the download page and directory for the ZIP file I used.

The next step is to get this image onto an SD memory card. I used a 4 GB card, of which over half will be available once everything has been installed. Plenty!

Good instructions for this can be found at elinux.org – in my case the section titled Copying an image to the SD card in Mac OS X (command line). With a minor tweak on Mac OSX 10.8.2, as I had to use the following command in step 10:

sudo dd bs=1m if=~/Downloads/2012-12-16-wheezy-raspbian.img of=/dev/rdisk1

First boot

Next: insert the SD card and power up the RPi! Luckily, the setup comes with SSH enabled out of the box, so only an Ethernet cable and 5V power with USB-micro plug are needed.

When launched and logged in (user “pi”, password “raspberry” – change it!), it will say:

Please run 'sudo raspi-config'

So I went through all the settings one by one, overclocking set to “medium”, only 16 MB assigned to video, and booting without graphical display. Don’t forget to exit the utility via the “Finish” button, and then restart using:

$ sudo shutdown -r now

Now is a good time to perform all pending updates and clean up:

$ sudo -i
# apt-get update
# apt-get upgrade
# apt-get clean
# reboot

The reboot at the end helps make sure that everything really works as expected.

Up and running

That’s it, the system is now ready for use. Some info about my 256 MB RPi:

$ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT \
                    Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
$ free
             total       used       free     shared    buffers     cached
Mem:        237868      51784     186084          0       8904      25972
-/+ buffers/cache:      16908     220960
Swap:       102396          0     102396
$ df -H
Filesystem      Size  Used Avail Use% Mounted on
rootfs          3.9G  1.6G  2.2G  42% /
/dev/root       3.9G  1.6G  2.2G  42% /
devtmpfs        122M     0  122M   0% /dev
tmpfs            25M  213k   25M   1% /run
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs            49M     0   49M   0% /run/shm
/dev/mmcblk0p1   59M   18M   42M  30% /boot
$ cat /proc/cpuinfo 
Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 0004
Serial          : 00000000596372ab
$

So far, it’s just a standard boilerplate setup. Yawn…

Node.js

On to Node.js! Unfortunately, the build included in Debian/Raspbian is 0.6.19, which is a bit old. I’d rather get started with the 0.8.x series, so here’s how to build it from source.

But first, let’s use this simple trick to get write permission in /usr/local as non-root:

$ sudo usermod -aG staff pi

Note: you have to logout and back in, or reboot, to get the new permissions.

With that out of the way, code can be built and installed as user “pi” – no need for sudo:

$ curl http://nodejs.org/dist/v0.8.16/node-v0.8.16.tar.gz | tar xz 
$ cd node-v0.8.16
$ ./configure
$ make
(... two hours of build output gibberish ...)
$ make install

That’s it. A quick check that everything is in working order:

$ node -v
v0.8.16
$ npm -v
1.1.69
$ which node
/usr/local/bin/node
$ ldd `which node`
  /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x40236000)
  libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x40074000)
  librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x40036000)
  libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x40107000)
  libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x4023f000)
  libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x4007f000)
  libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x400a7000)
  libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x402b0000)
  /lib/ld-linux-armhf.so.3 (0x400d2000)
$

Oh, one more thing – the RPi doesn’t come with “git” installed, so let’s fix that right now:

$ sudo apt-get install git

There. Now you’re ready to start cookin’ with node and npm on the RPi. Onwards!

PS. If you don’t want to wait two hours, you can download my build, unpack with “tar xfz node-v0.8.16-rpi.tgz”, and do a “cd node-v0.8.16 && make install” to copy the build results into /usr/local/ (probably only works if you have exactly the same Raspbian image).


Linux real-time hickups

In Hardware, Software on Sep 24, 2012 at 00:01

To give you an idea why a simple little Linux board (the Carambola on OpenWrt in this case) is not a convenient platform for real-time use, let me show you some snapshots.

I’ve been trying to toggle two I/O pins in a burst to get some data out. The current experiment uses a little C program which does ioctl(fd, GPIO_SET, ...) and ioctl(fd, GPIO_CLEAR, ...) calls to toggle the I/O pins. After the usual mixups, stupid mistakes, messed up wires, etc, I get to see this:

SCR18

A clean burst on two I/O pins, right? Not so fast… here’s what happens some of the time:

SCR19

For 10 ms, during that activity, Linux decides that it wants to do something else and suspends the task! (and the system is idling 85% of the time)

If you compare the hex string at the bottom of these two screenshots, you can see that the toggling is working out just fine: both are sending out 96 bytes of data, and the first few bytes are identical.

The situation can be improved by running the time-critical processes with a higher priority (nice --20 cmd...), but there can still be occasional glitches.

Without kernel support, Linux cannot do real-time control of a couple of I/O pins!


Timing troubles with upload

In AVR, Hardware on Sep 22, 2012 at 00:01

Since the Raspberry Pi can now reset a JeeNode, I assumed that uploading would be a piece of cake. Hmmm… maybe not quite.

The trouble is timing, and I’m currently I was pulling my hair out on this one:

  • the plan is to reset the JeeNode and then have avrdude upload new code to it
  • this works automagically when opening a serial port causes DTR to go low
  • but here, we don’t have DTR or RTS, this is a basic serial port on GPIO pins
  • what we do have, is a GPIO pin 18 which can be pulled low to force a reset

At the moment, there seems to be a major problem with timing:

SCR31

Here’s how to decode this screen shot:

  • the YELLOW line is serial from RPi to JeeNode
  • the BLUE line is serial from JeeNode to RPi
  • the MAGENTA line is the reset pulse on the GPIO pin

The way I test this, is via a shell script which first toggles reset using /sys/class/gpio/…, and then launches avrdude to perform the upload, using these commands:

echo 18 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio18/direction
echo 1 >/sys/class/gpio/gpio18/value
sleep 0.1
echo 0 >/sys/class/gpio/gpio18/value
avrdude -pm328p -carduino -P/dev/ttyAMA0 -D -Uflash:w:test.hex:i
echo 18 >/sys/class/gpio/unexport

Here’s what actually happens, I think:

  • the GPIO pin is correctly pulsed high and then dropped low after 0.1 s
  • the scope triggers on that falling edge, presumably same time as the ATmega resetting
  • after 323 ms, I see a 30 µs blip on the outgoing serial pin
  • after 674 ms, it looks like avrdude sends out it’s “0” wakeup character
  • after about 750 ms, the JeeNode starts sending the RFM12demo greeting
  • after 946 ms, the second “0” wakeup goes out
  • after 1197 ms, the third and final “0” goes out

In other words: it looks like avrdude is starting to send the 0’s too late! – and as a result, the JeeNode’s boot loader passes control to the sketch and never enters the upload cycle. After a few seconds, avrdude then gives up:

avrdude: ser_recv(): programmer is not responding

Note that reset and serial communication both work properly, as verified several times.

Trouble is, apart from redoing all in a single app, I see no way to reduce the startup time of avrdude. The SD card is perhaps not the fastest, but it’s no slouch either:

# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   248 MB in  2.00 seconds = 123.77 MB/sec
 Timing buffered disk reads:  50 MB in  3.05 seconds =  16.40 MB/sec
#

Is a reset + upload via GPIO not possible? I’m not giving up, but it sure ain’t workin’ yet!

Update – Problem solved, stay tuned for the explanation tomorrow…


Resetting a JeeNode from a RPi

In Hardware, Software on Sep 21, 2012 at 00:01

Now that the JeeNode talks to the Raspberry Pi, it’d be interesting to be able to reset the JeeNode as well, because then we could upload new sketches to it.

It’s not hard. As it so happens, the next pin on the RPi connector we’re using is pin 12, called “GPIO 18”. Let’s use that as a reset pin – and because this setup is going to become a bit more permanent here, I’ve made a little converter board:

DSC 4149

This way, a standard JeeLabs Extension Cable can be used. All we need is a board with two 6-pin female headers, connected almost 1-to-1, except for GND and +5V, which need to be crossed over (the other wire runs on the back of the PCB to avoid shorts).

This takes care of the hardware side of resets. Now the software. This is an example of just how much things are exposed in Linux (once you know where to find all the info).

There’s a direct interface into the kernel drivers called /sys, and this is also where all the GPIO pins can be exposed for direct access via shell commands or programs you write. Let’s have a look at what’s available by default:

$ sudo ls /sys/class/gpio/
export  gpiochip0  unexport
$

The “export” entry lets us expose individual GPIO pins, so the first thing is to make pin 18 available in the /sys area:

sudo echo 18 >/sys/class/gpio/export

That will create a virtual directory called /sys/class/gpio/gpio18/, which has these entries:

$ sudo ls /sys/class/gpio/gpio18/
active_low  direction  edge  power  subsystem  uevent  value
$

All we’ll need is the direction and value of that pin. Let’s first make in an output pin:

sudo echo out >/sys/class/gpio/gpio18/direction

Now, we’re ready to reset the JeeNode. I found out that the pin needs a negative transition (from 1 to 0) to do this, so the following three commands will do the trick:

sudo echo 1 >/sys/class/gpio/gpio18/value
sudo echo 0 >/sys/class/gpio/gpio18/value
sudo echo 1 >/sys/class/gpio/gpio18/value

And sure enough, the JeeNode resets, and the terminal I have running in another window shows the RF12demo startup message again:

Screen Shot 2012 09 18 at 14 32 09

We’re in control – shell over sketch!


Serial hookup JeeNode to Raspberry Pi

In Hardware on Sep 20, 2012 at 00:01

One way to connect an RFM12B to a Raspberry Pi is to simply plug in a JeeLink, using the built-in USB capabilities of the RPi. But that’s a bit of a detour – why go through USB?

Since the JeeNode’s FTDI connector can use 5V power and has TX/RX pins at 3.3V logic level, it’s actually a perfect match for directly connecting to a Raspberry Pi. Let’s do it.

I’ll be using the command shell on the RPi, using a network SSH connection, but this could also be done from the console with a keyboard, of course.

There are a couple of hurdles we’ll need to overcome. First one is to figure out which pins to use on the RPi’s 26-pin I/O connector. I found a good schematic on elinux.org:

Screen Shot 2012 09 16 at 17 26 45

We’re going to use 4 pins: 5V, Ground, TXD, and RXD. But first, let’s figure out how to reach those pins in Linux. I found out that the serial port we need is “ttyAMA0”:

$ ls -l /dev/ttyAMA0 crw-rw—- 1 root tty 204, 64 Sep 16 17:13 /dev/ttyAMA0 $

That port is only accessible by users in access group “tty” (and root). So first, let’s make sure user “pi” can access it, by adding ourselves to that group:

sudo usermod -a -G tty pi

Now logout and log back in to make these changes take effect.

> Note: not all RPi Linux distro’s are set up in the same way. If ttyAMA0’s group is “dialout” instead of “tty”, chances are that you’re already a member (type “id” to find out). In that case, skip the above usermod command.

But that’s not all. By default, there’s a “getty” process running on this serial port:

$ ps ax | grep getty 2126 tty1 Ss+ 0:00 /sbin/getty –noclear 38400 tty1 2127 tty2 Ss+ 0:00 /sbin/getty 38400 tty2 2128 tty3 Ss+ 0:00 /sbin/getty 38400 tty3 2129 tty4 Ss+ 0:00 /sbin/getty 38400 tty4 2130 tty5 Ss+ 0:00 /sbin/getty 38400 tty5 2131 tty6 Ss+ 0:00 /sbin/getty 38400 tty6 2132 ? Ss+ 0:00 /sbin/getty -L ttyAMA0 115200 vt100 2292 pts/0 S+ 0:00 grep getty $

This lets you connect to the serial port and login. Very convenient, but in this case we don’t want to log in, we want to take over control of this serial port for talking to the JeeNode. So we have to disable getty on ttyAMA0:

  1. edit the file /etc/inittab as root (I used “sudo vi /etc/inittab”)
  2. change this line: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 to #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100. I.e. comment it out, and save these changes.
  3. run the command “sudo kill -1 1” to pick up these inittab changes

And that’s it. There is no longer a process trying to respond to our serial port.

> Note: again, this may not be needed if you don’t see “ttyAMA0” listed in the ps output.

You also have to make sure that the kernel doesn’t log its console output to this serial port. Look in the file “/boot/cmdline.txt” and remove the text console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 if present. Then reboot.

Now we’re ready for a quick loopback test:

DSC 4143

Connect a single jumper as indicated (a little jumper block would also work), connecting RXD with TXD. This means that everything sent out serially will be sent back and received serially as well. A very convenient test that we’ve got all the Linux stuff set up properly.

Oh, wait – first let’s get the utility installed which lets us type to the serial port:

sudo apt-get install screen

Now we can test the serial port, at last:

$ screen /dev/ttyAMA0 57600 …

You should see a blank screen, and whatever you type in should show up on the screen. If this is indeed the case, then there is data going out and back into the serial port. To really make sure, disconnect the jumper and the echoing will stop. Excellent. Almost there.

Screen is a very convenient utility, but you need to remember how to get back out of it. The key sequence is CTRL+A followed by “\” (the backslash key).

For now, you can leave it running, or start it up again later. The last step is to hook up the JeeNode. This requires 4 wires:

DSC 4144

Note carefully the order of these female-to-female jumper wires, top to bottom:

  • on the RPi: green, white, black, gap, blue
  • on the JeeNode: gap, green, white, blue, gap, black

I used a JeeNode, pre-loaded with the standard RFM12B sketch, and set to receive packets from my main home monitoring setup here at JeeLabs. I also enabled “collect mode (“1c”) so that it wouldn’t try to acknowledge packets, just lurking and reporting what comes in. And sure enough, it works:

Screen Shot 2012 09 16 at 17 17 17

Easy! (once you know how to overcome all the software and hardware hurdles, that is…)

Update – additional contributed notes.