Boeeerb MotorPiTX

Posted by on

Following my review of Ryan Walmsley’s RPi MCB, and my previous review of the RasPi Robot board it only made sense to also assemble and review the Boeeerb MotorPiTX which I also received recently.

MotorPiTX components

The MotorPiTX is a multi-function board. It has two A/B motor drivers, two servo controllers, a bunch of headers and most interesting of all an “ATX-style” soft power switch. As with so many boards, this was launched through Kickstarter. The project was successfully funded, and several stretch goals were met, so I also got some handy motors, wheels amd a battery pack included. There seems to have been some sort of mis-calculation with the prices and postage costs, though, which has meant that the kits are being sent out to backers in dribs and drabs. The first ones were delivered last September, but mine only arrived last month.

SAM_0199

The kit is naturally more complex than the single-purpose RPi MCB, and was more fiddly and time-consuming to assemble. Unfortunately I could not find any detailed assembly instructions. The kit came with a diagram, a parts list, and some assembly hints, but not the kind of step-by step instructions that often accompany Raspberry Pi kits. There was also the problem of board versions. The web site and the kickstarter page are full of pictures of earlier versions, but so far I have not been able to find a single picture of an assembled “1.0” board. This makes some things (choosing and placing headers, for example) quite tricky. If It helps anyone else, here’s a picture of mine. I have not populated all the headers, but I hope I got the rest right!

The other assembly problem was the surface-mount micro-USB socket. The pads on this are so tiny that I did not feel comfortable trying to solder this in place. Luckily, the instructions suggest to leave it off if it is too tricky!

Eventually I got the board to a point where I was comfortable with powering the board on and trying to test it. My initial attempt was to plug in a 9V PP3 battery to the barrel jack on the board. When I plugged it in the relay clicked alarmingly and the power light flashed, but then the system was quiet again. Pressing the power button on the MotorPiTX switched the Pi on, and it flashed its LEDs pretty much as usual. This was when I hit my first real problem. I don’t usually connect a keyboard and screen to my Pis, preferring to work using ssh and remote X windows. However, when I started the Pi powered by the battery connected to the MotorPiTX, for some reason it did not start up the networking. To get a network connection, I had to power the Pi from its own microUSB connection, and forgo the soft power switch. I’ll investigate this further some other time.

Having successfully powered up the Pi and the MotorPiTX board, and got a network connection, I now wanted to try the motor control. Wiring the motor was a bit more tricky than the RPi MCB, as the MotorPiTX just provides pin headers rather than screw terminals. If I had had some spare screw terminals I would have soldered them in place instead, as they seem a much better way to connect motors. Eventually, though, I used a small breadboard to connect the bare wires from my test motor to some header wires.

For comparison purposes I wanted to run the same two-second forward and backward test as I did with the RPi MCB. I had that code on the Pi already, so my first attempt was to just change the pin numbers and run that one. Unfortunately, this did not work. My next port of call was the example code. There are examples of using all the board features on GitHub, so I downloaded the motorpitx python library, and knocked together a small python program to use it:

import motorpitx
import time

motorpitx.motor1(100)
time.sleep(2)
motorpitx.motor1(-100)
time.sleep(2)
motorpitx.cleanup()

MotorPiTX uses PWM percentage for speed control, so the example above sets motor 1 to full speed ahead, waits for two seconds, sets motor 1 to full speed reverse, waits for two seconds, then stops and cleans up the outputs. Pretty straight forward really.

In conclusion, this is an interesting board with plenty of features. While I can see the theoretical advantages of the “ATX” power supply circuitry, it does complicate the board, and I could not get it to work properly. If all you want is no-nonsense control of two motors, and you don’t feel like wiring your own controller, then the Ryanteck RPi MCB is the obvious choice. If you also need servo control and general purpose I/O, then the Boeeerb MotorPiTX seems a good all-rounder.

Arduino Learning Timer

Posted by on

It’s not Raspberry Pi, but I had a hankering to make something of my own design and Arduino just seemed simpler.

This project is a learning countdown timer. In its simplest form it just has two buttons and a buzzer. For Extra bling, though, I have added a “flowing water light” (a board with eight LEDs and a multipack resistor) to show what’s going on inside. Although the system will work fine without the LEDs it is much prettier with them!

Making an interval timer is often complicated by problems of calibration and complex input and output just to set the time. So I wondered if I could solve both those problems by entering the interval in its native format – as a duration. This approach works on any microcontroller which runs at a reasonably steady clock speed, regardless of what that clock speed is. I’m hoping it will also be workable with a minimal AVR circuit (such as a shrimp) or maybe even one without the crystal, if I can work out how to program it.

Use is simple. To teach it a duration press the LEARN button once to start and again to stop. During learning the LEDs will show a “walking dot”. Once you have taught it a time, press green to count down to that time, then beep.

Code at https://github.com/efficacy/learning-timer.

The whole thing took me a couple of hours to design and build.

RyanTeck RPi MCB motor control board

Posted by on

It’s been a while since I did any assembly, but I seem to have built up a pile of bits again, so it’s time to break out the soldering iron…

First in the queue is the RPi MCB (Motor Control Board), the first hardware product from Ryan Walmsley (the Rastrack guy).

RPi MCB kit

RPi MCB components

This is an interesting item in many ways – financed through the hybrid-crowdfunding site Tindie, it shows that with a bit of creativity and perseverance, anyone can stand a chance of making and selling electronic stuff. It’s a pretty simple circuit, essentially just a SN754410NE chip and some connectors, but it still manages to provide a useful addition to the Raspberry Pi.

The Anabolic Cookbook steroids shop anabolic steroids raw material

RPi MCB almost complete

RPi MCB populated

Assembly was pretty simple, following the on-line assembly instructions although the screw terminals needed a bit of a wiggle and push to get them fully seated. This is probably a good thing, as it both made them easier to solder, and might even help keep them solid in the face of vibration.

Once I had all the components in place, I thought I’d have a go at doing something with it, but was brought up short by the following comment at the bottom of the assembly instructions

Next why not visit our simple coding tutorials at <Coming soon!>

There are actually a few small hints (GPIO pin numbers and so on) on the RPi MCB product page at Ryanteck, and some more in a Google Document but it is a bit disappointing that the assembly page doesn’t even include any way of testing that it has been assembled correctly.

Eventually I did manage to test it out. The example code in the Google document did work (when run using sudo) but as it is an infinite loop it never got to the GPIO cleanup, and thus left the motor running. After a bit of scrabbling with a battery connector I stopped it by removing the power. The lack of a GPIO cleanup also led to a lot of complaints about pins in use. As a more friendly test, I suggest:

##Simple motor script for the RTK-000-001
import RPi.GPIO as GPIO
import time
#Set to broadcom pin numbers
GPIO.setmode(GPIO.BCM)

#Motor 1 = Pins 17 and 18
#Motor 2 = Pins 22 and 23
GPIO.setup(17, GPIO.OUT)
GPIO.setup(18, GPIO.OUT)

#Sleep 1 second then turn 17 on
GPIO.output(18, 0)
time.sleep(1)
GPIO.output(17, 1);
time.sleep(2);
#And now the other way round
GPIO.output(17, 0)
time.sleep(1);
GPIO.output(18, 1);
time.sleep(2);
#And final cleanup
GPIO.cleanup()

which just turns each way once for two seconds, then stops and cleans up.

In conclusion, this is a nice, simple little board which “does what it says on the tin”. It could do with a bit more thought on testing the board as part of assembly, but essentially it works.

Well done Ryan, I look forward to more ideas!

Using Raspberry Pi and Chef to set up remote servers (Part 1)

Posted by on

I always have several different projects on the go at any one time, and recently this has meant that I have been setting up and tearing down remote virtual machines frequently in order to try out different system configurations and run experiments. As you might imagine, I got well and truly sick of slogging through a growing list of manual operations to get each fresh remote system installed and set up before I could even start the real work. So I decided to look into the technologies available for remote automated system management.

I started by just gathering my hand-written instructions into an executable script. For some parts of the setup(running apt-get update is hardly rocket science, for example) this was easy, but I quickly found that many of the commands I would type manually required user input, or complex edits to config files, or might only need doing in some situations. I toyed with the idea of pushing forward with my scripting approach and trying to program all these special operations, but decided that this would probably take a lot longer to do than the projects I was supposed to be doing.

Looking a bit further I found a cluster of remote administration tools, including chef, puppet, saltstack, cfengine, ansible and so on. I spent several days trying to get things working using some of these, and following all sorts of different tutorials. In pretty much every case something either did not work, or trying to find out how to accomplish what I wanted took way too long. It didn’t help that typical tutorials for these systems make all sorts of assumptions about the system being used to run the tool – particular operating system versions with particular software installed, and so on.

Eventually I did get something working using Chef, but only by abandoning the official chef tutorials (which seem more concerned with getting you to register with the company than actually helping with real tasks), and trying other stuff until I got something working. The most useful tutorial turned out to be Daniel O’Connor‘s blog post on Managing Raspberry Pi with Chef & Bitbucket. This gave me what I needed: how to get started with an absolute minimum of dependencies.

I had had so many problems and aborted attempts that I could no longer trust the state of my development machine, so I went through the tedious process of setting up a completely clean virtual machine to use. In this case a VirtualBox machine, installed from a CD image of Linux Mint 15. Once I had worked through all the installation screens and could log in to the machine, I was able to install a few things (ruby, bundler, git and so on) and follow Daniel’s steps to get the remote machine up and running. Flushed with success I checked stuff into my git repo and went home.

The next day I was somewhat disappointed. I’m guessing that I did not shut down the virtual machine properly, as it would not start up and I had to go back to an earlier snapshot. Luckily I was able to get things back in operation relatively quickly, but it did make me think. Perhaps setting up a development box in a virtual machine on a desktop computer is both overkill for this task, and not very portable. Inspired by the Xtravirt vPi, I decided instead to set up a Raspberry Pi image with the tools I need, so I can manage my remote machines from anywhere with an ethernet cable and some USB power, and without any worries about incompatibilities or missing software.

The installation process is as follows:

Start with a fresh Raspbian image, and write it to an SD card as usual. When it is written, stick it in a Raspberry Pi, plug in an ethernet cable to a nearby router, and apply some power. Don’t bother with screen and keyboard etc. This is designed to be a “headless” device controlled from another computer. You will need something which can make an ssh connection. If you don’t already have one, then I can highly recommend MobaXterm. Depending on how your local network is configured you can probably ssh to something like pi@raspberrypi.local, but you may have to use the IP address instead. Once you are connected, the real stuff begins.

First, make sure we have the basic software needed:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install ruby1.9.3 ruby1.9.1-dev rubygems bundler rake

Now we can create a skeleton installation. Note that although this is based on Daniel’s instructions, it’s not quite the same, as in this case we are using the Pi to manage a remote system, rather than using a local machine to manage the Pi.

mkdir skeleton
cd skeleton

# Set up bundler to manage Ruby dependencies
bundle init
echo 'gem "knife-solo"' >> Gemfile
echo 'gem "berkshelf"' >> Gemfile
bundle

# Initialise the Chef tools "Knife" and "Berkshelf"
knife solo init .
berks init (select "y" to overwrite ".gitignore"; select "n" to overwrite "Gemfile")

At this point we now have an empty (but hopefully working) Chef installation. To use it requires a few extra steps, but I have found that putting them into a simple script makes things a lot easier to remember. I saved the following as rebuild.sh:

#!/bin/bash
# usage rebuild.sh 
dest=$1
  
#remove any old key for that ip
ssh-keygen -f "$HOME/.ssh/known_hosts" -R $dest
  
#copy my credentials to allow smooth login
ssh-copy-id root@$dest  # and enter root password, just this once
  
#install chef on target
knife solo prepare root@$dest
  
#run chef to install the configired recipes from nides/$dest.json
bundle exec knife solo cook -VV root@$dest

running this script (with the ip address of the sever to be configured as a parameter) should connect to the remote system, install ssh credentials, then install the server end of Chef. You will probably need to enter the server root password the first time you do this.

That’s about it for this post. Next time, I’ll explore how to configure the Chef installation on the Raspberry Pi so that it will deploy the set of services you need to the remote machine.

Detective work on PiFace Control and Display

Posted by on

Having wasted all my free time yesterday on trying to find out how the PiFace CAD is interfaced to the Raspberry Pi, I thought I’d take a different approach today. When I was last working with SPI, I used my trusty Saleae Logic analyser to find out what was happening, so I thought I’d connect this up between the Raspberry Pi and the PFCAD, to see what is really going on.

The first problem, as I pointed out in my initial review of the PiFace Control and Display, was that the PFCAD board does not provide easy access to any of the Pi’s GPIO pins. I did not want to mess around unsoldering the PFCAD, so my solution was to extend the Pi’s GPIO pins with the same kind of “long leg” socket that I use for my own circuit boards.

SAM_0092

SAM_0094


I then ran the “sysinfo” example, which had worked fine yesterday: python3 /usr/share/doc/python3-pifacecad/examples/sysinfo.py. Oddly, it failed, with a very strange complaint.

Traceback (most recent call last):
  File "/usr/share/doc/python3-pifacecad/examples/sysinfo.py", line 5, in 
    import pifacecad
  File "/usr/lib/python3/dist-packages/pifacecad/__init__.py", line 19, in 
    from pifacecommon.interrupts import (
EOFError: EOF read where not expected

After a bit of poking around, it seems that something has gone wrong with “python3”. When I tried the outwardly similar python /usr/share/doc/python3-pifacecad/examples/sysinfo.py it worked without any complaints. I can only assume that this is a result of SD card corruption when the Pi was powered off. Maybe I should use my Pi Supply switch, after all.

My first run of the “sysinfo” example showed some activity on the MOSI and MISO lines, but did not trigger the SPI analyser. It looked like I was monitoring the wrong select line. So I switched to triggering on CS1 and bingo!

pfcad-1

Now we are getting somewhere. The PFCAD is using CS1. Looking at the data being transferred, I see a chain of short groups of bytes:

  1. 0x40 0x0A 0x08
  2. 0x41 0x0A 0x00
  3. 0x40 0x00 0xFF
  4. 0x40 0x0C 0xFF
  5. 0x40 0x13 0x00
  6. 0x40 0x01 0x00
  7. 0x40 0x04 0xFF

Then quite a long gap (around 22ms) before we get to anything else. It seems quite likely that this is some sort of initialisation sequence, so lets try to send it from some other code and see what happens.

#include 
#include 
#include 
#include 
#include 

#include 

#define CHANNEL 1

void send3(uint8_t a, uint8_t b, uint8_t c) {
  uint8_t buf[3];

  buf[0] = a;
  buf[1] = b;
  buf[2] = c;
  wiringPiSPIDataRW(CHANNEL, buf, 3);
}

void main(int argc, char** argv) {
  if (wiringPiSPISetup(CHANNEL, 4000000) < 0) {
    fprintf (stderr, "SPI Setup failed: %s\n", strerror (errno));
    exit(errno);
  }

  printf("start\n");
  send3(0x40, 0x0A, 0x0B);
  send3(0x41, 0x0A, 0x00);
  send3(0x40, 0x00, 0xFF);
  send3(0x40, 0x0C, 0xFF);
  send3(0x40, 0x13, 0x00);
  send3(0x40, 0x01, 0x00);
  send3(0x40, 0x04, 0xFF);
  printf("done\n");
}

This is a fairly simple piece of C code, using Gordon's WiringPi library to do the low-level SPI twiddling, but I was impressed to see that it had some effect. It switched off the back-light on the PFCAD display! This is more than I managed in a day of code autopsy and head scratching.

I could keep on with this approach, and transcribe all the rest of the bytes I saw on the SPI bus, but I would prefer to work at a slightly higher level. So I need to work out what these mean. This means dipping into the MCP23S17 datasheet.

From the documentation, the MCP23S17 expects three-byte sequences of the form OPCODE REGISTER VALUE. OPCODE varies according to which MCP23S17 is being addressed, but in this case 0x40 is WRITE and 0x41 is READ. I'm not sure at the moment what the PFCAD software is doing with its write then read of register 0x0A, but I'm guessing it might be a check to see if the port expander is present and working. The others seem relatively straightforward, though.

Register address Register name this value does
0x00 Bank A IO direction all inputs
0x0C Bank A pull-ups all pull up
0x13 Bank B GPIO data all low
0x01 Bank B IO direction all outputs
0x04 Bank A interrupt enable compare against DEFVAL (reg 0x03)

These seem to appear in a slightly strange order, but the intention is clear. The LCD is connected to bank "B", so the bank is set to output with initially low values. Bank A is set as inputs with pull-up resistors and default interrupt handling, so those are either unused, or connected to the PFCAD buttons.

One of the Bank B data lines is obviously connected to the back-light input on the HD44780, so when they are all set low, the backlight switches off.

I think that's enough detective work for now. I'll see how much further I can get another time!

Programming Raspberry Pi add-ons (a rant and a plea)

Posted by on

I love the Raspberry Pi. Sure it has its warts, but overall it is very well suited to an amazingly large range of uses. What I’m not so keen on, though, is the Python. Not that I have anything against the programming language (or John Cleese, Eric Idle et al., come to that), but it’s just not how I want to write software right now.

I have plenty of experience in a load of other programming languages, including C, C++, Java, Ruby, FORTH, APL, BASIC and so on. I’m even getting more familiar with Javascript and node.js. These are all general-purpose programming languages, in one form or another available on the Raspberry Pi, and would be perfectly suitable for writing Raspberry Pi software and controlling Raspberry Pi hardware.

Except that (mostly) you can’t easily use these languages to control off-the shelf third-party Raspberry Pi hardware.

This limitation is nothing to do with these programming languages, nor with the Raspberry Pi, nor its operating systems. It’s to do with the software and documentation provided with the hardware.

Most recently I have bumped into this with the PiFace Control and Display. I think the board and its features are great, and the supplied example programs do show some of the things it is capable of. But the supplied code is all Python. And, try as I might, I can’t find any documentation about the actual hardware which might enable me to use it with anything else. I can tell from examining the board that it has a MCP23s17 port expander on an SPI port with a HD44780 LCD driver and some switches connected to it, but to make sensible use of the hardware using anything other than the supplied Python code I need to know details such as which GPIO pins are connected to what, and whether they are inputs or outputs, which SPI device numbers are used, whether the display is in “4 bit” or “8 bit” mode, and so on. I spent several hours yesterday poking through the PiFace CAD Python code and trying things out in a C program, but so far I have not managed to successfully even clear the LCD display or switch the backlight on or off, let alone write any characters.

I’m really not trying to single out the PFCAD, here. Over the last year or so I have bought a large proportion of the available Raspberry Pi expansion boards, and I think its fair to say that most of them had this problem in one way or another. It almost seems as if the promotion of Python as an introductory Raspberry Pi programming language in schools (a role I’m sure it suits quite well) has obscured the fact that what we actually have is a flexible platform which can and should also be used for everything from for hobbyist tinkering, follow-on education in wider computer topics, product prototyping, and embedded use. And it could so easily be.

Everyone who makes an electronic component provides a datasheet. That datasheet gives enough information, in a mostly standardised form, for anyone with some experience to have a go at using the component. When I tried interfacing an MCP3002 ADC chip to a Raspberry Pi, I made use of such datasheets to understand what I needed to do. If the manufacturer had only produced software examples, I’m pretty sure they would not have made them for my hand-made board plugged into a Raspberry Pi! Without a datasheet, nobody will buy or use your component.

MCP3002 board under construction

My plea is this:

If you produce add-on hardware for a Raspberry Pi, it is vital that you document and make available enough hardware details that anyone with a bit of understanding can use your hardware from any language or operating environment. Let the growing community of skilled developers help you out by writing libraries, drivers, examples and tutorials for languages and uses you don’t have time, skills or inclination to do. Don’t assume everyone will use only your software!

If you want to also provide some sort of language-independent kernel driver, and/or libraries and examples in multiple languages, good on you, but it’s still no substitute for the raw information. As I found out almost a year ago, it can be surprisingly hard to rebuild drivers even on a stock Raspbian Linux system.

My hope is that if everyone tries to do this we will (soon?) begin to see the familiarities between devices and start to standardise on how things are documented. A pool of developers could then form, able to pick up and work with any add-on hardware based on a quick examination of its datasheet. This in turn could help the production of general-purpose software tools which can ease the development of libraries, drivers, examples and tutorials. At the moment everything seems unique and puzzling, the simplest of details are tedious or even impossible to find out, and hardly any extension hardware gains enough momentum to escape the orbit of the original developers. This is crazy, and must be limiting hardware and software sales.

So, am I missing something? is this kind of documentation and developer pool available already? Can someone point me at some sort of datasheet for The PiFace Control and Display board, or for any of the dozens of other add-on boards and devices which have been produced so far?

Pi Face Control and Display Case

Posted by on

In my excitement at ordering the new PiFace Control and Display board, I also ordered a black plastic case to hold both the Raspberry Pi with the add on board fitted.

SAM_0090_small

I can’t say that I’m very impressed, though. The case consists of two “U”-shaped halves, which clip together to form a closed case. For many electronic projects this is a tried-and-tested design, but it works best if all the cut-outs for sockets, knobs and stuff are on one half of the case, and there is a bit of room around the board for access and wiring. That way the board can be secured in place, yet the case can be easily opened for modification and maintenance. This combination of a Raspberry Pi with a PiFace Control and Display fitted requires cut-outs on five of the six faces of the case, and almost all of those have protruding sockets or buttons. This means that the case needs to be bent alarmingly out of shape even to get a single board in place.

I just about managed to squeeze my red Chinese Pi into the bottom part of the case, but had no end of trouble trying to fit the delicate-looking protruding buttons of the PiFace Control and Display at the same time. I tried fitting the PFCAD to the Pi first, then put the Pi in first and tried mangling the case to get the board in place and on to the GPIO pins at the same time. Eventually I abandoned both approaches as I was seriously scared of damaging the Pi, the PFCAD, or both.

In conclusion I can’t really recommend this case. It’s a nice enough idea but it simply does not seem practical, especially for the price of £13.78, almost as much as the PFCAD board itself! I would have been much better with a PFCAD version of the cheap acrylic “jigsaw case“, or better still, a new design from the clever people at ModMyPi or Pimoroni

PiFace Control and Display

Posted by on

I was very excited to read about the new PiFace Control and Display board. On a first look at the spec it seems to have a really sweet set of features. A two line display, some general purpose buttons, a left/right/click joggle wheel and an infra-red sensor. This little board opens up a world of possibilities for using the Raspberry Pi as a standalone device without a screen, keyboard or mouse.

I was particularly impressed at the price. Farnell has it for just £21 – less than the price of a USB infra-red “dongle” on its own. I ordered one straight away and it arrived today! As a side note, I also ordered the special Raspberry PiPiFace Control and Display case for it, but that’s a story for another day.

Read Pearson Reviews & Rationales: Pharmacology with “Nursing Reviews & Rationales” (4th Edition) Paperback – isuzu rodeo ue and rodeo sport ua 1999 2002 service repair workshop manual original fsm winstrol for sale sports pharmacology: maximum effect without compromising health

SAM_0085_small

Keen to get started I began by following the “operating instructions” linked from the Farnell page. These were a reasonable start, but did have a few problems.

I started with a fresh image of the latest Raspbian (2013-09-25) from the official downloads page. When it started up I used the options in the initial raspi config screen to expand the SD card partition and enable SPI (this is in the “advanced” submenu, but it is needed for the display to work. The instructions leapt straight in to

sudo apt-get install python3-pifacecad

but this did not work for me. I needed to do sudo apt-get update first.

Once I had installed the pifacecad driver, I followed the instructions and tried:

python3 /usr/share/doc/python3-pifacecad/examples/sysinfo.py

It kind of worked, but the LCD was barely visible. If I twisted it around to look at it from odd angles, I could get hints that there was something on the screen. The document I was following seemed to be aware of the problem, but just offered:

If your LCD has nothing appearing on it or its character spaces are all
black, try adjusting the contrast screw with a small star head screwdriver. You can try using a chip on glass LCD display with a smaller footprint and lower power consumption.

Unfortunately it completely fails to mention where to find the mystery “contrast screw”.

A bit of googling led me to some more PiFace Control and Display documentation at github. This did at least describe where the contrast screw might be found. In case anyone else is in a similar position, here’s a photo of me adjusting it!

SAM_0089

A bit of twiddling made it nice and black. The python command to display the IP address and so on is all very nice but I wanted to move on to other stuff, so I exited it with ctrl-C.

The next section of the document concentrated on setting up the infra red remote input. This was not as smooth as the python screen driver, though. The first step was to install and test the lirc_rpi module:

sudo modprobe lirc_rpi gpio_in_pin=23
pidof lirc

The “pidof” just returned to the command prompt. It neither reported a pid number nor gave an error message. I can only assume this means everything is OK. The next step is to test the hardware to see if any infra-red signals are making their way through to the lirc driver.

mode2 –d /dev/lirc0

This gave a splurge of “ulse 621” “pace 543” down the left side of the screen. I’m sorry to say that it took me a few moments to realise that the first character was off the edge of the screen, so it is probably really reporting “pulse” and “space” timings. This did prompt me to give up on direct keyboard and screen, and fall back to my usual ssh access. Handily, I did not need to fiddle around to work out the IP address – it was already on the LCD display!

I wanted to try it out with an old remote handset. I could not find its name in the big list of LIRC remotes, so I went for the “generate your own configuration” approach. It was a bit tedious, but once I realised that the key names were of the form BTN_0, KEY_PREVIOUS and so on, I was away. When I had recorded all the buttons I could find, I rebooted as per instructions and ran “irw” to test the remote control. This gave me nothing. The hardware is still working, as the mode2 –d /dev/lirc0 command still shows the pulses.

It’s entirely possible that the old remote (or its batteries) is at fault here, though. Not all the buttons seem to even send an IR code, and I have no idea how old the batteries are. I’ll try again tomorrow with a different remote and see if that makes any difference.

In conclusion I really like this board. It has such a nice set of features and price that I can already imagine lots of uses for it. The documentation is a bit sketchy in places, but that is to be expected. I would have liked a short section on using the buttons and joggle wheel just to prove that everything is working.

As for the hardware design, my main concern is that (as with so many boards) it gobbles up all the pins on the GPIO header, effectively preventing its use as a control interface for other hardware. Even something as simple as providing header pads for SPI and/or i2c would make this much more useful in combination with other hardware. It might be possible to replace the 26-way header with one with longer legs, but the IR sensor is positioned very close to the header and might get in the way of things plugged in.

“Cerberus” a single USB cable for Raspberry Pi, Arduino and Freedom boards

Posted by on

If your workbench is anything like mine it’s covered in cables of one sort or another. Anything that helps manage that tangled complexity is a good thing, so I was very interested when I saw the “cerberus” multi-headed USB cable available from Sparkfun and distributors.

"Cerberus" multi-headed USB cable

As I hope you can see from the picture, it has a standard USB “A” plug on one end, and the three most common options on the other (“B” plug, mini-USB, and micro-USB). Conveniently these are the three plugs used for power and/or data by the three main development boards I use: Raspberry Pi uses micro-USB for power, Freescale Freedom boards have a mini-USB socket for power and programming, and Arduino Uno expects a USB type B.

There’s no electronics in this cable, so it’s not clever enough to use for data with more than one board, but it does supply 5V USB power to all three ends, so with a decent 5V supply at the “A” end, it might be able to power multiple boards. I haven’t tried this, as all the boards other than the Raspberry Pi have the data pins connected and I’m not convinced that there would be no ill effects from connecting these data pins together. If you really want to do this, then you might consider using a “USB condom” (a fancy name for a USB socket and plug with just the power wires connected).

This lead seems useful enough that I have put it into my travel kit, so I can at least be sure of a USB cable to power whatever I am working on.

Building a “prototino” Arduino clone

Posted by on

In an attempt to get back into blogging about my Raspberry Pi and microcontroller projects I have been looking through my collection of parts and kits, to see what I can make, or at very least assemble. One of the kits I bought a few months ago was a “prototino“. This is essentially an Arduino squashed on to the end of a bit of prototyping board (hence the name, I guess).

Prototino before assembly

The kit of parts is pretty minimal, a PCB, a socketed AVR controller, a crystal and some bits and bobs (resistors, capacitors and an LED). The kit also provided a voltage regulator, but I held off from fitting that at the moment, as I’m likely to power the board with pre-regulated 5V from some other component, such as a raspberry Pi!

Prototino after assembly

SAM_0010-shrunk


Once assembled, the board is pretty neat, and fits comfortably in an Altoids tin. Now I just need to work out what to do with it…