Command of the day: ^]

You may have seen it hundreds of times but few know what it means.

Escape character is '^]'.
It is actually quite obvious is you know that the caret ^ is a shorthand notation for 'Control' (or <Ctrl> as would be more familiar to windows users).

So what is it? It is not actually a command but a keystroke for the telnet command. It opens a command prompt from where you can enter a variety of commands.

Possibly the most exciting thing you can do is then press ^Z ( <Ctrl>+z ) and suspend your telnet session, returning you to your local shell. You can then resume later by using your shell job control (ie. 'fg').

Some other useful commands are

• quit (or press ^C)
• send brk (which if supported will send a break)
• speed 115200 (which if supported will switch the serial line speed)
• close (disconnect the session)
• open (establish a new session)
• help (list the available commands)

And there are many more documented in the telnet man page.

In this day and age, any server shell access should be via a secure protocol like ssh. telnet remains however as a handy tool for testing TCP servers and accessing specialised equipment like serial concentrators.

It is also worth noting that telnet is actually a protocol and not just a raw TCP stream. There is a lot of negotiation which is done to ensure that your terminal works correctly. Often this only becomes obvious when your terminal does not work correctly.

XBMC 13.2 on CentOS-6

For a while I have been running XBMC 13.0 on CentOS-6. I turns out that there is a known issue in that version which prevents it from playing .m4a files.
The solution is to upgrade to 13.2 which for me means rebuilding a new RPM.
For you, that means downloading the new version from http://www.chrysocome.net/downloads/xbmc-13.2-1.el6.x86_64.rpm
And don't forget to get the deps from http://rpmfusion.org/ and EPEL.

Command of the day: column

Often I come across a new command which I think Wow! I always wanted to know how to do that.

I decided that I will blog about them and that way I will have a record for next time when I forget how to do it.

So my first command of the day I is one I saw on a Red Hat post. It can show the contents of a file tabulated into easy to read columns.

Example:
cat /etc/passwd | column -s : -t


Now you are probably aware of the <tab> character, often entered as \t or in bash as $'\t'. It will advance the cursor to the next tab stop which is traditionally every 8 characters. Well what if you have a tab delimited file but some data is longer than 8 characters and some it less. Well when you look at it, the output will be all over the place.

Using column you can get all your tab columns to line up like this:
cat data | column -s $'\t' -t
Note: for this to work correctly you must have a value in every column (perhaps a bug?)

FIPS integrity verification test failed.

After installing the updates for CentOS-6.6, my box started showing this warning when I run ssh:

FIPS integrity verification test failed.

I did not enable FIPS and don't much want it.
There are two ways to turn FIPS off. First option is to remove /etc/system-fips
rm -f /etc/system-fips
Second is to uninstall dracut-fips (which is the package which owns /etc/system-fips).
rpm --erase dracut-fips
The down side of this is that the package might come back. Something obviously caused it to be installed in the first place though I don't know what. There don't seem to be any rpm dependencies.

Arduino IR Blaster

My IR blaster is built on a LeoStick which is an arduino compatible USB stick. I must be a sucker for punishment because I thought it would be easy to make one of the many IR libraries work on here and control my Samsung TV.

There were two problems with my plan. First, the defacto IR libraries don't allow me to use the necessary IO pins and second, Samsung IR codes are not supported.

Rather than detail what when wrong, I will present my solutions.

The first problem arises because the LeoStick has a green LED attached to Digital IO pin 9 which is the default PWM Timer used by Ken Shirriff's IR library. The solution is an updated fork of this library Chris Young which implements more Timer chips and enables selecting Digital IO pin 5. Do to that, edit IRLibTimer.h and find the section with the heading 'it's probably Leonardo' (the LeoStick is apparently compatible with the Leonardo). Comment out the default #define and uncomment the IR_USE_TIMER3. (I wonder why we can't select this at run time?). Based on the IRLib manual, I also installed my IR LED with whatever resistors I had on hand (470 ohm I think).

So, thanks to the hard work of these guys, I have got my LED working. Now, to make it talk Samsung protocol.

There were a few snippits of code in various forums but I had to piece that together into the format for IRLib. I have only added sending as I already have a list of codes from SamyGO and LIRC. The only code I wanted to use is TV_POWER 0xE0E040BF because once the TV is on, I can talk to it via the network.

I have submitted my changes as a GitHub pull request. If they are not accepted in the upstream library you can find them here https://github.com/jnewbigin/IRLib

The final piece to the puzzle is making the IR code send when I want it to. To keep this generic, I made my sketch read a hexadecimal code from the serial port. When it receives a code it just send it, thus allowing control over the time and the code. This could probably be integrated with LIRC but I am just using a simple shell command
echo 0xE0E040BF > /dev/ttyACM0

So here is my sketch. There is not much error detection in the serial reading but what is the worst that can go wrong?

/* Example program for from IRLib – an Arduino library for infrared encoding and decoding
 * Version 1.3   January 2014
 * Copyright 2014 by Chris Young http://cyborg5.com
 * Based on original example sketch for IRremote library
 * Version 0.11 September, 2009
 * Copyright 2009 Ken Shirriff
 * http://www.righto.com/
 *
 * Modified by John Newbigin to support Samsung and USB control May 2014
 */
#include <IRLib.h>

IRsend My_Sender;

void setup()
{
  Serial.begin(9600);
}

void p(char *fmt, ... ){
        char buf[128]; // resulting string limited to 128 chars
        va_list args;
        va_start (args, fmt );
        vsnprintf(buf, 128, fmt, args);
        va_end (args);
        Serial.print(buf);
}

// 0xE0E040BF = Power
void sendCode(unsigned long code)
{
   p("Sending SAMSUNG 0x%08lx\n", code);

  for (int i = 0; i < 3; i++)
  {
    My_Sender.send(SAMSUNG, code, 0);
    delay(30);
  }
}

unsigned long ir_code = 0;
void loop() {
  while(Serial.available() <= 0)
  {
    delay(10);
  }
  int incomingByte = Serial.read();

  int nibble = -1;
  if(incomingByte == 10)
  {
    p("Got newline\n");
    sendCode(ir_code);
    ir_code = 0;
  } 
  else if(incomingByte == 13)
  {
    // ignore
  }
  else if(incomingByte >= '0' && incomingByte <= '9')
  {
    nibble = incomingByte - '0';
    p("Got digit %d\n", nibble);
  }
  else if(incomingByte >= 'a' && incomingByte <= 'f')
  {
    nibble = incomingByte - 'a' + 10;
    p("Got hex digit %d\n", nibble);
  }
  else if(incomingByte >= 'A' && incomingByte <= 'F')
  {
    nibble = incomingByte - 'A' + 10;
    p("Got hex digit %d\n", nibble);
  }
  else if(incomingByte = 'x')
  {
    p("Starting number\n");
    ir_code = 0;
  }
  else
  {
    p("Got %d\n", incomingByte);
  }
 
  if(nibble >= 0)
  {
    ir_code<<= 4;
    ir_code+= nibble;
    p("Code is 0x%08lx\n", ir_code);
  }
}

OpenSCAD for CentOS 6

I am thinking about getting a 3D Printer but before jumping in, I wanted to test out some software to see how hard it is to drive these things.

OpenSCAD

It was suggested that I check out OpenSCAD, the programmers 3D CAD program.

As usual, for CentOS-6, it did not exist. Building it was tricky and required a bit of finesse. You can download my beta build and dependencies from http://www.chrysocome.net/download

Installation Instructions

Note: gmp 5.0 is named gmp5 so it can co-exist with the system version 4.3
Note: mpfr 3.1 is names mpfr3 so it can co-exist with the system version 2.4
yum install gmp5-5.0.5-3.el6.x86_64.rpm mpfr3-3.1.0-2.el6.x86_64.rpm CGAL-4.1-1.el6.x86_64.rpm opencsg-1.3.2-6.el6.x86_64.rpm openscad-2013.06-8.el6.x86_64.rpm --enablerepo=epel

I also need to make sure that the MCAD libraries are correctly packaged. I'll try and make an updated version soon.

FreeCAD

 

FreeCAD is a more traditional click and draw interface which is apparently very good and has many features. It can also be scripted with python. RPMs are available from RPM Fusion Nonfree

Conclusion

I need a lot of practice before I will be making any 3D objects!

NVIDIA GPU Temp

On my old TV setup I used nvclock to get the NVIDIA GPU temperature and graph it using rrdtool (along with other temperatures and fan speeds).

nvclock was always a bit of a hack and does not work any more (at least, it won't do anything useful for me).

I know the nvidia-settings tool can display the temperature (and much more information) so there must be a modern way to access this data. A quick google showed up the nvidia-smi tool.

Quick and dirty,
nvidia-smi -q | grep Temperature -A 1
will show the current temperature.
    Temperature
        Gpu                     : 72 C

Interestingly, the output can also be in XML format. Combined with some xslt magic, it is possible to get the temperature in a more structured way.
echo '<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method='text'/>
<xsl:template match="/">
<xsl:for-each select="//gpu_temp">
<xsl:value-of select="."/>
<xsl:text>&#xa;</xsl:text>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
' > nvidia-temp.xml
nvidia-smi --dtd > nvsmi_device_v6.dtd
nvidia-smi -q -x | xsltproc nvidia-temp.xml -

Note: Your driver might be using a different dtd version. Adjust as required. (nvidia-smi --dtd | head -1 | cut -d ' ' -f 2 will give the correct name)

If you have multiple cards and want to know which card has which temperature then you can alter the xsl to format it as you require with something like
<xsl:value-of select="ancestor::gpu/@id"/> or <xsl:value-of select="ancestor::gpu/uuid"/>
eg
0000:04:00.0 Quadro K2000 31 C
0000:05:00.0 Quadro K2000 32 C

The new TV is almost here

Now that summer has hit, it is time to head indoors and tinker with the TV. Some clever planning when I last upgraded the disk in my CentOS-4 machine meant that the required partitions and space for CentOS-6 was available without having to alter anything.

That meant that installing CentOS-6 was relatively easy. (I did it the hard way and PXE booted off the work server via VPN). After a minimal install I configured the machine in puppet and managed to leverage most of my Linux SOE config.

After that was finished, I had a workstation but not a TV. Next step XBMC. That installed without any trouble but would not play any audio and the video kept going choppy. Not what I was expecting.

The choppy video was being caused by high load caused by the sosreport program. I don't know what crashed, and I don't much care. There is no point sending me an email about it.

I remember wrestling with this in the past without any satisfactory result. This time, rpm --erase sos did the trick. (I have to make sure puppet does not put it back.).

The audio seemed to be a problem with PulseAudio. I don't much care for this either. I have never needed it before and it does not appear to support S/PDIF / EC958 which I need so it has to go. Once again, no satisfactory instructions so rpm --erase alsa-plugins-pulseaudio seems required.

After a restart (I hate that!), all traces of pulseaudio are gone and XBMC is offering me S/PDIF again. Audio and video now working.

Next hurdle, Remote Controls. I have lots of experience with LIRC in the past because I had to make some modifications to the old version to get it to do everything I wanted. As hoped, there has been some improvement in this area but alas, also some steps backwards.

The first remote is a DVICO Fusion remote. This is a supported model but requires configuration in /etc/sysconfig/lirc and /etc/lirc/lircd.conf
/etc/sysconfig/lirc wants to know the device but it is a dynamically assigned USB HID device. This means UDEV rules ahead. It would be ideal if LIRC came with these but it seems not. Luckily I have my old EL4 rule but the new new udev uses a new format for rules. This was what I came up with in the end:
/etc/udev/rules.d/20-dvico.rules
SUBSYSTEM!="usb", GOTO="end"
KERNEL!="hiddev*", GOTO="end"
ATTRS{idVendor}=="0fe9", ATTRS{idProduct}=="9010", SYMLINK+="dvico"
LABEL="end"

Now I can configure lirc and it should work reliably (unless I have two receivers, which I do but I only use one!).

Copy the lircd.conf config file from the files supplied in lirc-remotes and that is ready to go.

It seems I still need to build a Lircmap.xml file for XBMC before it will work there. Lets hope I can find a sample on the internet. Writing XML by hand is not what I call fun.

The next challenge with LIRC is my IR Blaster which controls the stereo. This uses the kernel driver called lirc_serial. I understand that this is not an enterprise solution but if lirc_dev can be in the kernel, why no lirc_serial? Well, no worries, perhaps I'll find a package which has the driver. I do require that the driver will work after a kernel update so the atrpms package is no good. And is is only version 0.8 and I am using LIRC 0.9 (may not be an issue but I want them to match).

I guess I'll just build one myself.  Enter a world of 'lirc_serial: disagrees about version of symbol' errors. Briefly, some lirc drivers are now in the EL6 kernel. lirc_serial depends on lirc_dev. The lirc_dev in the kernel is back ported so checking kernel version numbers for the correct API does not work reliably. Also, modversions seem to be cached so once the errors are fixed, the resulting module still does not work.

Finally, I abandoned the LIRC build scripts and went straight to the kernel Makefile. After tweaking a few #defines I had a working build. I then packages in into an elrepo style kmod package and now I have a working ilrc_serial driver (which you can download from http://www.chrysocome.net/download). LIRC does not come with the definition for Panasonic remotes but I have the old one on hand which still works (yay). The LIRC init script does not handle starting multiple instances so I will have to hack that up too. At least I can specify the location of the .pid file which I think was a show stopper in the old version.

The next job is to work out if I can use my IR Blaster to turn the TV on too. For a SMART TV, there are not many options for turning it on...

Lazarus has come to life

Most of my windows programming is still done in Delphi 5. This was released in 1999 which makes it positively ancient. (Even more scary is that some programs started life in Delphi 2).

Not long after Delphi 5, Borland lost the plot (or prehaps they already had when they changed their name to Inprise). Although Delphi 7 was available, when I looked up upgrading the .net experiment was under way and it seemed like the end of the road for Delphi. I had hoped for a cross platform modern version to appear but that never really happened. Eventually the crazy was transferred to Embarcadero (whatever that is) and I still don't understand what works with what.


While all that was going on, I kept an eye on another program, Free Pascal. Free Pascal always showed such promise but the IDE was reminiscent of programming c++ under DOS.

Finally it seems though, I might have found what I have been looking for.  Lazarus, the Delphi styled IDE for Free Pascal. Matured enough for a 1.0 release and soon to be 1.2. Native unicode support and cross platform (Linux, Windows, OS-X).

Although there are a few sharp corners (don't import a unit called strings!), I am planning on converting my projects over to Lazarus and hopefully bringing them back from the dead too. My initial testing has been positive.

With any luck my programs will be playing nice with Windows 7, running on Linux and being recompiled without having to pay any license fees. It has taken a long time but I think it has been worth it.

Now if I could just press for Android support too...

XBMC on CentOS 6

After years of putting it off I have finally taken the plunge into XBMC.

My plan is to hook it up as a front end for the Digital ORB pvr.

RpmFusion have packages for XBMC version 11 for CentOS 6. This is a good start as many of the audio & video packages from RpmForge (which I am sure most CentOS 6 users have) are too old for XBMC.

Unfortunately there is no package for XBMC version 12 which apparently has much better pvr support. The bug database entry suggested that it would be relatively easy to fix... and it was https://bugzilla.rpmfusion.org/show_bug.cgi?id=2699

So now I have a relatively stable base to start my integration. Lets hope that I get it working before XBMC version 13 comes out and changes everything again.

If you want to run XBMC yourself, you will need my xbmc and taglib packages from http://www.chrysocome.net/downloads and any dependencies from rpmfusion and epel.

You can also get the Digital ORB from my downloads directory. It does come with instructions but has not been widely tested yet. Stay tuned.

Using xorg without a mouse

I always like it when I learn something new. Particularly when I read something one the web which turn out to work.

I wanted to find a way to move the mouse cursor without a mouse. I can actually do this with my lirc based remote but I have a new wireless keyboard for my linux 'TV' and I wanted to have a way to use that too.

A google search turned up an interesting page which suggested the X.org has this functionality built in and to my surprise it worked. It even had instructions for keyboards without a numeric keypad (like mine). Apparently "MouseKeys" and "PlotMode" has always been a feature in X.org and XFree86.

I must be in PlotMode at the moment which is quite slow. I will have to practice enabling Accelerated mode <Fn><Alt><Shift><Num Lock> should be the key I need.

@reboot jobs will be run at computer's startup.

"@reboot jobs will be run at computer's startup."
What on earth does that mean?

These days RedHat use cronie as the system cron daemon. Described as 'based on the original cron' I think it is a fork of vixi-cron which was used until EL5.

For some time, both of these cron daemons have had an @reboot syntax which allows you to run scripts at (more or less) boot time (when the cron daemon is started). This allows users to start long running processes without the sysadmin having to write an initscript.

It also happens that from time to time, the cron daemon crashes. This is not ideal because cron is the very tool which can be used to periodically confirm that a daemon has not crashed. For now I have added a check to puppet to ensure that the cron daemon is running.

When the cron daemon is started, it logs some messages, one of which is the cryptic:
@reboot jobs will be run at computer's startup.
message. I understand that it is trying to tell me something but it fals short of conveying the message. The internet did not have much to say on the topic either so I had to resort to the source code.

The source of the message is from within the run_reboot_jobs function. The function first checks the existence of a (so called) lock file. The file is
/var/run/cron.reboot
If this file is present, the message is printed out and none of the @reboot jobs are run. If the file is absent, it is created and then the @reboot jobs are queued up to be run.

Perhaps the message should read:
Lock file /var/run/cron.reboot present. @reboot jobs have already been run. skipping.

So that is the mystery almost solved. The remaining details are that during boot, the rc.sysinit script removed a number of stale lock files, including the contents of /var/run. This ensures that at boot time, the cron daemon runs the @reboot jobs.

If you wanted to re-run the @reboot jobs without rebooting your server, you can easily trick it with:
rm /var/run/cron.reboot
service crond restart

Perhaps that could also be added to the init script so you run
service crond restart-boot

chkconfig priorities

I recently had a problem on a CentOS-6 machine where my dhcp server did not start at boot because it was serving a virtual network interface which did not yet exist.

The best solution to this problem would be for the dhcp server to start up and wait for the network interface to come up. Many other network tools do this successfully so I don't know why dhcpd should be different. That problem is however too big for me to fix on my server so I need a more simple approach.

To solve this, I would like to adjust my dhcp server to start after the virtual network interface service. CentOS-6 uses the (old) RedHat style init scripts (with some LSB configuration too). RedHat like to proclaim that they use upstarts now but all the upstarts do is make a call to the /etc/rc.d/rc script, just like init used to do.

So, the problem is still based around the System V style scripts which have magic comments which define when to start & stop the scripts.

This is the relevant parts of the header for the dhcp server (/etc/rc.d/init.d/dhcpd):
### BEGIN INIT INFO
# Provides: dhcpd
# Default-Start:
# Default-Stop:
# Should-Start: portreserve
# Required-Start: $network
# Required-Stop:
# Short-Description: Start and stop the DHCP server
# Description: dhcpd provides the Dynamic Host Configuration Protocol (DHCP)
#              server.
### END INIT INFO
#
# The fields below are left around for legacy tools (will remove later).
#
# chkconfig: - 65 35

Despite the comments about being legacy, when installed using chkconfig, the priorities used are indeed Start 65, Kill 35. We can confirm this with a simple ls
ls /etc/rc.d/rc?.d/*dhcpd

The virtual network is also controlled by an init script with a more modest header (/etc/rc.d/init.d/vand):
# chkconfig: 2345 95 05
# description: Virtual Area Network Deamon

Not surprisingly, this will Start at 95 and Kill at 05.

The first idea I had was to modify the dhcpd init scrip directly. Unfortunately this script is not marked as config file (in the rpm) so when a new version comes out, my changes will be lost. I need something better than that.

It is not immediately obvious but chkconfig does have the ability to alter the priorities. This is called override (but not to be confused with the command line parameter --override).


I was unable to find and documentation on the override but I did work out that his minimal config file was all that was needed:


/etc/chkconfig.d/dhcp:
### BEGIN INIT INFO
# Required-Start: vand
### END INIT INFO

When chkconfig reads the headers from the dhpcd init script, it will also read this file (because it has the same basename) and override the values from the init script.

All that is needed is to apply the settings with:
chkconfig dhcpd on

Some information about LSB init scripts can be found here http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html

The final job is to make puppet aware of my changes. Perhaps in my next post.

ProLiant Virtual Serial Port

While working through the configuration of iLO3 for our HP DL380 G7 servers, I found a few pages talking about the Virtual Serial Port (VSP).

This sounded interesting so I though I would try it out. I was using this page as a guide http://www.fatmin.com/2011/06/redirect-linux-console-to-hp-ilo-via-ssh.html but it was a bit out of date.

The first thing to mention was that this does indeed work with iLO3. When configuring your iLO3, remember that in order to ssh to iLO3 you must have a PTY (-t -t), use protocol version 2 (-2) and use DSA keys (ssh-keygen -t dsa). My old configuration for older versions of iLO used exactly the opposite for all of these settings which took some time to figure out (and HP only recently identified/fixed the bugs with ssh keys).

Once you can ssh to your iLO interface, you can issue the command
VSP
and it will start a terminal emulator (actually, it just passes everything through to your terminal program so you can use xterm if you want but safer to assume a vt102). To exit, press ESCape and then ( and you will return to the iLO prompt.

For the OS configuration, I found that I had to make a few alterations. First, RHEL6/CentOS6 uses upstarts and not inittab. If you are not booting with a serial console you must create your own init script:
/etc/init/ttyS1.conf
# ttyS1 - agetty
#
# This service maintains a agetty on ttyS1 for iLO3 VSP.

stop on runlevel [S016]
start on runlevel [235]

respawn
exec agetty -8 -L -w /dev/ttyS1 115200 vt102

You can then enable the console with the command
start ttyS1
Next time you reboot it should start automatically.

In order to log in as root you must add the terminal it to the /etc/securetty file:
echo '/dev/ttyS1' >>  /etc/securetty

So that was all good. Now I want to roll this out to all my servers. To do this I needed some puppet magic. Not surprising, puppet let me down on most of the steps for this.
# Install the init script. This one is easy, just dump in the file 

file { "/etc/init/ttyS1.conf":
...
}

# Add the entry to securetty
augeas { "securetty_ttyS1":
# Ha ha. securetty has a special lens which is different to most other config files
context => "/files/etc/securetty",
changes => [ "ins 0 before /files/etc/securetty/1",
             "set /files/etc/securetty/0 ttyS1",
],
onlyif  => "match *[.='ttyS1'] size == 0",
}

# Enable & start the service. My version of puppet does not support upstarts on CentOS so I can't do this:
service { "ttyS1":
provider => upstart,
ensure => running,
enable => true,
}
# Instead I have created my own type
define upstart($ensure = "running", enable = "true") {
        service { "upstart-$name":
                provider => 'base',
                ensure => $ensure,
                enable => $enable,
                hasstatus => true,
                start  => "/sbin/initctl start $name",
                stop   => "/sbin/initctl stop $name",
                status => "/sbin/initctl status $name | /bin/grep -q '/running'",
        }
}
upstart{"ttyS1": }

And finally, I need to make sure the server BIOS is configured with the VSP.

package { "hp-health": ensure => present } ->
service { "hp-health":
        ensure => running,
        hasstatus => true,
        hasrestart => true,
        enable => true,
} ->
exec { "vsp":
        logoutput => "true",
        path => ["/bin", "/sbin", "/usr/bin", "/usr/sbin"],
        command => "/sbin/hpasmcli -s 'SET SERIAL VIRTUAL COM2'",
        unless => "/sbin/hpasmcli -s 'SHOW SERIAL VIRTUAL' | grep 'The virtual serial port is currently COM2'",
        require => Class['hp_drivers::service'],
} ->

# while we are messing with the serial ports, make COM1 work as the physical device
exec { "com1":
        logoutput => "true",
        path => ["/bin", "/sbin", "/usr/bin", "/usr/sbin"],
        command => "/sbin/hpasmcli -s 'SET SERIAL EMBEDDED PORTA COM1'",
        unless => "/sbin/hpasmcli -s 'SHOW SERIAL EMBEDDED' | grep 'Embedded serial port A: COM1'",
        require => Class['hp_drivers::service'],
}

Graphing the inputs of PCF8591

As discussed in previous posts, the PCF8591 provides up to four analog inputs. Displaying these inputs as numbers makes it hard to visualise what is really going on so here I will present some code which can graph the values in real time.

I am still using my demo board from I2C Analog to Digital Converter. (Thanks to Martin X for finding the YL-40 the schematic on the The BrainFyre Blog)

DX pcf8591-8-bit-a-d-d-a-converter-module-150190 YL-40 schematic

It is not clear from the schematic (or looking at the board) but the four inputs are:

• AIN0 - Jumper P5 - Light Dependent Resistor (LDR)
• AIN1 - Jumper P4 - Thermistor
• AIN2 - Not connected
• AIN3 - Jumper P6 - Potentiometer

It also seems that the board has I2C pull-up resistors which are not required because the Raspberry Pi already has them. This does not appear to cause any problems.

So my plan is to graph the four inputs so I can visualise them responding to changes.

Once again, I don't want to set out to teach C programming but I will be introducing a library called curses (actually ncurses) which makes it easy to display a text interface in a terminal window (virtual terminal).

It will also be able to adjust the analog output value using the + and - keys.

I will only add notes where I am doing something new from the example shown in Programming I2C.

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/i2c-dev.h>
We need a new header file
#include <ncurses.h>

int main( int argc, char **argv )
{
        int i;
        int r;
        int fd;
        unsigned char command[2];
        unsigned char value[4];
        useconds_t delay = 2000;

        char *dev = "/dev/i2c-1";
        int addr = 0x48;

        int j;
        int key;
Here we do some ncurses setup. This will allow us to check for a keyboard key press without having to wait for one to be pressed.
        initscr();
        noecho();
        cbreak();
        nodelay(stdscr, true);
        curs_set(0);

This will print out a message on the screen (at the current cursor location which is the top left)
        printw("PCF8591");


This will print out some labels for our graph bars. The text is printed at the specified location (row, column)
        mvaddstr(10, 0, "Brightness");
        mvaddstr(12, 0, "Temperature");
        mvaddstr(14, 0, "?");
        mvaddstr(16, 0, "Resistor");

We must now call refresh which will cause ncurses to update the screen with our changes
        refresh();
        fd = open(dev, O_RDWR );
        if(fd < 0)
        {
                perror("Opening i2c device node\n");
                return 1;
        }

        r = ioctl(fd, I2C_SLAVE, addr);
        if(r < 0)
        {
                perror("Selecting i2c device\n");
        }

        command[1] = 0;
        while(1)
        {
                for(i = 0; i < 4; i++)
                {
                        command[0] = 0x40 | ((i + 1) & 0x03); // output enable | read input i
                        r = write(fd, &command, 2);
                        usleep(delay);
                        // the read is always one step behind the selected input
                        r = read(fd, &value[i], 1);
                        if(r != 1)
                        {
                                perror("reading i2c device\n");
                        }
                        usleep(delay);
 The full range of the analog value 0 - 255 would not fit on most screens so we scale down by a factor of 4. This should fit on a 80x25 terminal nicely.
                        value[i] = value[i] / 4;


Position the cursor at the start of the bar
                        move(10 + i + i, 12);
For each position in the graph, either draw a * to show the value or a space to remove any * that might be there from a previous value
                        for(j = 0; j < 64; j++)
                        {
                                if(j < value[i])
                                {
                                        addch('*');
                                }
                                else
                                {
                                        addch(' ');
                                }
                        }
                }

                refresh();
 Check the keyboard and process the keypress
                key = getch();
                if(key == 43)
                {
                        command[1]++;
                }
                else if(key == 45)
                {
                        command[1]--;
                }
                else if(key > -1)
                {
                        break;
                }
        }

Shutdown ncurses
        endwin();
        close(fd);
        printf("%d\n", key);
        return(0);
}


To compile this program you need to use a new flag -l which says to link with the spcecified library (ncurses)

gcc -Wall -o pcf8591d-graph pcf8591d-graph.c -lncurses

When you run the program you should see something like this:
PCF8591


Brightness  *****************************************************

Temperature *******************************************************

?           *********************

Resistor    *****************************************

While it is running the graphs should move as you change the inputs. Try for example shining a torch on the LDR or adjusting the Pot.

You can adjust the green LED with + and - (hint, use - to go from 0 to 255 for maximum effect). Any other key will cause the program to quit.

The graph shows nicely how the inputs can change but it also shows how the value can fluctuate without any input changes. I can't explain exactly why but I would expect much of the fluctuation is because of the lack of a stable external clock/oscillator and/or instability in the reference voltage. Needless to say this is a low cost demo board and may not be exploiting the full potential of the PCF8591.

Here is the complete source code (pcf8591d-graph.c):
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/i2c-dev.h>
#include <ncurses.h>

int main( int argc, char **argv )
{
        int i;
        int r;
        int fd;
        unsigned char command[2];
        unsigned char value[4];
        useconds_t delay = 2000;

        char *dev = "/dev/i2c-1";
        int addr = 0x48;

        int j;
        int key;

        initscr();
        noecho();
        cbreak();
        nodelay(stdscr, true);
        curs_set(0);
        printw("PCF8591");

        mvaddstr(10, 0, "Brightness");
        mvaddstr(12, 0, "Temperature");
        mvaddstr(14, 0, "?");
        mvaddstr(16, 0, "Resistor");
        refresh();
        fd = open(dev, O_RDWR );
        if(fd < 0)
        {
                perror("Opening i2c device node\n");
                return 1;
        }

        r = ioctl(fd, I2C_SLAVE, addr);
        if(r < 0)
        {
                perror("Selecting i2c device\n");
        }

        command[1] = 0;
        while(1)
        {
                for(i = 0; i < 4; i++)
                {
                        command[0] = 0x40 | ((i + 1) & 0x03); // output enable | read input i
                        r = write(fd, &command, 2);
                        usleep(delay);
                        // the read is always one step behind the selected input
                        r = read(fd, &value[i], 1);
                        if(r != 1)
                        {
                                perror("reading i2c device\n");
                        }
                        usleep(delay);

                        value[i] = value[i] / 4;
                        move(10 + i + i, 12);

                        for(j = 0; j < 64; j++)
                        {
                                if(j < value[i])
                                {
                                        addch('*');
                                }
                                else
                                {
                                        addch(' ');
                                }
                        }
                }
                refresh();

                key = getch();
                if(key == 43)
                {
                        command[1]++;
                }
                else if(key == 45)
                {
                        command[1]--;
                }
                else if(key > -1)
                {
                        break;
                }
        }

        endwin();
        close(fd);
        printf("%d\n", key);
        return(0);
}

scp files with spaces in the filename

scp is a great tool. Built to run over ssh it maintains a good unix design. It does however cause a few problems with it's nonchalant handling of file names.

For example, transferring a file which has a space in the name causes problems because of the amount of escaping required to get the space to persist on the remote side of the connection.

Copying files from local to remote is easy enough, just quote or escape the file name using your shell.
scp Test\ File remote:
scp 'Test File' remote:
scp "Test File" remote:

Copying files from remote to local can be more tricky
scp remtote:Test\ File .
scp: Test: No such file or directory
scp: File: No such file or directory

scp stimulus:"Test File" .
scp: Test: No such file or directory
scp: File: No such file or directory

scp "stimulus:Test File" .
scp: Test: No such file or directory
scp: File: No such file or directory

The escaping is working on your local machine but the remote is still splitting the name at the space.

To solve that, we need an extra level of escape, one for the remote server. Remember that your shell will eat the \ so you need a double \\ to send it to the remote
scp remote:Test\\\ File .
Test File              100%    0     0.0KB/s   00:00

You can also combine the remote escape with local quoting
scp remote:"Test\ File" .
or
scp "remote:Test\ File" .

Best solution of all, avoid spaces in file names. If you can't avoid it, I find the easiest solution is to replace ' ' with '\\\ '.
 

SMART errors and software RAID

For a while now I have been having an intermittent problem with some of my drives. They seem to be working but stop responding to SMART. If I reboot they don't show up any more but if I power off and back on they work fine.

I have two 640Gig WD Green drives in a software RAID1 and another WD Blue drive. After a suspend/resume, sometimes one of the drives is MIA. The kernel thinks it is still there but my SMART tools can't talk to it and start to complain.

The Blue drive has a bad (unreadable) sector but touch wood, that has not caused a problem yet. SMART knows about this and tells me about it frequently. This however does not appear to be the problem. There is a telling message is in dmesg:

sd 0:0:0:0: [sda] START_STOP FAILED

sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK

PM: Device 0:0:0:0 failed to resume: error 262144

So for some reason, the disk is not responding when the computer resumes. I guess it is a timeout (and I wonder if I can extend it?) Anyway, now I have the situation where my disk is not working even though I know there is nothing actually wrong with it.

Luckily I am using software RAID and the other disk is working so I can continue about my business without crashing or loosing data. After poking and prodding a few different things I have worked out a solution:

• Hot-remove the device (from the kernel)

echo 1 > /sys/block/sda/device/delete

• Rescan for the device to hot-add it to the kernel

echo "- - -" > /sys/class/scsi_host/host0/scan

• Add the 'failed' drive back into the RAID set

mdadm /dev/md127 --re-add /dev/sda2

You must remove the existing (sda) device first or the disk will be re-detected and added with a new name (sde in my case).

Because I have a write-intent bitmap, the RAID set knows what has changed since the drive was failed and only the changes must be re-synced which is quite fast.

There seems to be a 'vibe' that green drives are not good for RAID. I don't really think this is a problem because the drive is green, I think it is a problem because the driver is not trying hard enough to restart the disk.

So in the end this was not a SMART problem after all. Not there there are no bugs to fix there. Particularly in udisks-helper-ata-smart-collect which keeps running and locking up sending the load average into the hundreds. For a tool designed to detect error conditions it probably needs a bit more work.

My next job is to select a replacement drive for the faulty WD Blue...

I2C Analog to Digital Converter

The first device I hooked to my Raspberry Pi is based on the PCF8591 Analog to Digital Converter (ADC). This chip has 4 analog inputs (ADC) and one analog output or Digital to Analog Converter (DAC).

I am using a pre-assembled board from Deal Extreme which comes with the chip, a temperature sensor, light sensor, variable resistor and LED. This provides a simple showcase for the chip and more importantly, it has a light sensor which is important to my project. The board was only a few dollars http://dx.com/p/pcf8591-8-bit-a-d-d-a-converter-module-150190 there are also other similar boards on there.

PCF8591 demo board. GPIO pins are visible on the right.

The first step is to physically hook up the board. Mine came with the required cables (often called dupont cables) which is also a handy way to start. The cables must be connected to the Raspberry Pi GPIO pins nominated for I2C. These have the required 'pull up resistors' already installed. (These are what make the wires operate like a bus). The pins are

• P1-01 +3.3v (VCC)
• P1-03 Data (SDA)
• P1-05 Clock (SCL)
• P1-09 Ground (GND)

Raspberry Pi showing GPIO cables connected.

My demo board has a red power indicator LED which came on once I powered up.

The next big test is to see if the i2c driver can talk to your chip. The Raspberry Pi actually comes configured with two I2C buses and for reasons unknown, on my system the bus labelled I2C0 is allocated the Linux device i2c-1.

Scanning both buses won't hurt.

jnewbigin@raspberrypi:~$ i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --                         

You can see here that a device has been detected at address 0x48. This is the expected address for my chip so that means we are in business.

Reading and writing to the chip is quite straight forward but the chip does have a few nuances.  The first read after power on will return 0x80. The analog to digital conversion is performed when you make a read request but the read will return the previous sample so it is always one sample behind. This is not too confusing unless you are switching to read a different input.

I will show how to read the data using the command line tools i2cget and i2cset. In another blog post I will show how you can interface with the chip from c code.

All these commands take a parameter 1 to specify which i2c bus and I pass -y which skips the safety warning. (We know what we are doing so this is OK. On other hardware such as your PC, things can and do go wrong by using these commands).

The most basic read is the default channel (input 0).

jnewbigin@raspberrypi:~$ i2cget -y 1 0x48

0x80

That is the power on status code. Now we read again

jnewbigin@raspberrypi:~$ i2cget -y 1 0x48

0xd2

That is the value that was sampled when we made our first read (the one that returned 0x80).
Now cover up the light sensor and read again

jnewbigin@raspberrypi:~$ i2cget -y 1 0x48

0xd2

Yep, no change. The new value has been sampled so now we read it

jnewbigin@raspberrypi:~$ i2cget -y 1 0x48

0xeb

Now we get the new value.

Now, switch to read another input, input number 1

jnewbigin@raspberrypi:~$ i2cset -y 1 0x48 0x01

jnewbigin@raspberrypi:~$ i2cget -y 1 0x48

0xeb

First we get an old value.

jnewbigin@raspberrypi:~$ i2cget -y 1 0x48

0xcf

Then the new value

We can repeat to select channel 2 and 3.

We can enable the analog output by adding bit 0x40 to the set command and then specify a value for the DAC

jnewbigin@raspberrypi:~$ i2cset -y 1 0x48 0x41 0xff

And the indicator LED turns on

jnewbigin@raspberrypi:~$ i2cset -y 1 0x48 0x41 0x00

And the indicator LED turns off. You can of course set it to any value between 0x00 and 0xff and see the LED dim and turn off. (You can also see why LEDs don't make good analog indicators).

FlashCache

For some time I have been using FlashCache on my PC at home. Of course I did it the hard way because I wanted it seamlessly integrated at boot time so I could use the cache on my root filesystem.

My hard work seems to have paid off and I have now officially published the fruits of it at http://chrysocome.net/dracut-flashcache

Now CentOS-6 users can get started with FlashCache with (hopefully) a minimum of fuss.

Just as soon as I get time to upgrade my machine at work I will be running it there too.

Raspberry Pi I2C

I have a Raspberry Pi and lets face it, who doesn't?

I have played with linux on many architectures before including PPC, Hitachi, MIPS, PA-RISC and Sparc so I figure I had better have a go at ARM too.

Apart from playing around, I plan to create a light controller module for my garden lights. This will require some hardware hacking which is always a bit of fun but my main plan is to bring it together with some fancy software.

In previous projects I have interfaced with GPIO and I2C to run door controllers and read swipe cards (Mostly on the WRT54G).

I could not find accurate instructions for getting I2C going on the rpi so here are my instructions for users for raspbian:

Install some tools

# apt-get install i2c-tools

edit  /etc/modprobe.d/raspi-blacklist.conf and comment out the line


i2c-bcm2708

I don't know why it comes as blacklisted.

edit /etc/modules and add the lines

i2c-bcm2708
i2c-dev

This will make sure the drivers are loaded during the boot.

create a file /etc/udev/rules.d/99-i2c.rules and add the line

SUBSYSTEM=="i2c-dev", MODE="0666"

This will give all users access to the i2c devices. You could instead set the owner or group but the rpi is not normally being used as a multi-user device

Now you can test these changes without a reboot:

modprobe i2c-bcm2708

modprobe i2c-dev

udevadm trigger
ls -l /dev/i2c*

And you should see output like this (Your date will be different):

crw-rw-rwT 1 root i2c 89, 0 Nov 18 22:36 /dev/i2c-0
crw-rw-rwT 1 root i2c 89, 1 Nov 18 22:36 /dev/i2c-1

If that works, reboot and run the ls again. The devices should be there and have world read/write permissions.

Now, to connect up some hardware and show that it works. Look for a new blog soon.