Online Hexdump Tool

I have just published a testing version of an online hexdump utility, which can be found here.

There exist a few online hexdump tools already, but these all require you to upload a file to a remote server, which may be inappropriate. Also, in most cases these tools produce an output quite unlike what we are used to with od, xxd and the like. I wanted something closer to what my favorite shell utilities produce.

My (still experimental) tool processes files locally in JavaScript, using HTML5 local file access and produces something similar to hexdump -C’s output, without byte grouping.

A screenshot of the tool in action is shown below:

This tool may be useful in circumstances where you don’t have a machine with a proper operating system at hand and quickly want to inspect some file.

CA Board

Some time ago I had these boards made by OSH Park, and I’m pretty pleased how they turned out. It’s great to see your own designs professionally manufactured, now just hope I didn’t screw anything up in my design. :)

This board is part of an experiment with cellular automata that I’m sometimes spending my thoughts on. Like almost all the stuff I do, this project as to compete for my attention with many other unfinished stuff.

The board will be populated with 16 Atmel ATTiny13 microcontroller, of which I had already ordered a lot of 50 pieces from Ebay.

All components will hot air soldered using stencilled on solder paste.

This weekend I experimented with programming the SO-8 packaged microcontrollers. To do so I also ordered a programming adapter from WaveShare as pictured below.

This adapter allows programming of the comtroller before soldering it to the board. I’ll probably prototype on breadboard anyway. I want to be able to dynamically load code to the controllers which will be executed in a simple virtual machine.

To test code running on the Tiny13, I’ve made a small plug with 3 LEDs that can be attached to one of the headers of the programming adapter. The LEDs show the state of PB0 - PB2, actually the inverse state, as the GPIOs sink Vcc in this case.

It didn’t take long to get the first code running on the Tiny13, blinky LEDs this weekend!

Time to think of implementing a protocol for the controllers to exchange state information, updating code on a remote controller as well as synchronizing the controllers as they will all run asynchronously by default.

Categories as Keywords in Octopress

The version of Octopress that I use for this blog requires you to give both categories as well as keywords for a page / post to have these appear in the meta tags of the generated HTML. I didn’t check what the current Octopress does in this respect, as I don’t feel like upgrading at the moment.

Since I’m lazy, I’ve updated source/_includes/head.html to fall back to using categories as keywords for a page if no keywords are given.

As this may be useful to other Octopress users, this is what I’ve changed: In source/_includes/head.html, change:

1
{% if page.keywords %}<meta name="keywords" content="{{ page.keywords }}">{% endif %}

to:

1
2
3
4
5
6
7
8
{% capture keywords %}{% if page.keywords %}
  {{ page.keywords }}
{% elsif page.categories %}
  {{ page.categories | join: ', ' }}
{% else %}
  {{ site.keywords }}
{% endif %}{% endcapture %}
<meta name="keywords" content="{{ keywords }}">

and Octopress will default to the categories of a post to use as meta keywords.

Psion Organiser II UDG Framebuffer, Part 1.75

In 2009 I wrote about using the user defined characters of the Hitachi HD44780 LCD controller as a poor man’s framebuffer. See this post for details about my experiments on a Psion Organiser II back then.

Well, somewhere this year I revisited that project and wrote a set of Psion OPL programs to create and manipulate a small framebuffer implemented in eight characters of the Psion’s little LCD. Actually, since I’m nowadays the proud owner of a Psion Organiser II model LZ64 , the LCD is larger than it was in 2009. ;)

The library of OPL programs is called UDGFB and is available on Github. Should I ever update it, expect it to appear there.

More technical details about UDGFB after the break…

Squeezebox Radio Ambient Light Sensor

Almost half a year has passed since I last wrote anything here, terrible. Anyways, here is a description of a little hack I did some time ago:

Our bedroom has this Squeezebox radio, that I mostly use as a clock and to play from Spotify.

The Squeezebox has an ambient light sensor that dims the screen when the lights go out. Which works fine, the screen is dim enough at night not to interfere with my sleep.

Anyways, of course I had enabled SSH access to the Squeezebox just after installing it. Last year I was poking around in its filesystem to discover the ambient light sensor hanging around in /sys:

1
2
$ cat /sys/bus/i2c/drivers/msp430/1-0010/ambient
345

Every variable in the hessch residence needs to be graphed, this data could not be left aside. Also, as the ambient light sensor faces the window in the bedroom, I thought this might give some interesting data on the length of the days.

MSP430 Boids

As posted before on Twitter I’ve been playing with Olimex’s MSP430-LED boosterpack. I’ve bought some ARM Cortex M3 modules from Olimex before that I liked. This modle is really nice hardware, again. Well engineered and very good value for money. I think I’ll try one of their OLinuXino boards later on too.

After trying a simple rule 110 cellular automaton as a first test for the display. I’ve now ported my Bash implementation of Craig Reynolds Boids to the MSP430 microcontroller.

A video follows after the break:

Adding LEDs to a Ruckus VF2111

Last week I bought a Ruckus Wireless bundle consisting of a VF2825 WiFi accesspoint and a VF2111 media (client) adapter. They were new in box and cheap, 15 euro for both. Snooping around in the configuration makes me believe these bundles were once offered by the Portuguese provider Clix.

These Ruckus boxes have an amazing beamforming antenna array inside and the VF2825 actually has LEDs on the antenna PCB that shine through a translucent window on top of the unit so that you can see which of the antennas are switched on at any given moment. The LEDs are pointing like a compass needle to the client that it talks to, in many cases, but reflections from the concrete walls in my house seem to spoil that effect a bit.

The VF2111 hasn’t got these LEDs, this had to be fixed of course. It was time to heat up the soldering iron!

On Ebay I ordered a couple of 0402 green SMD LEDs. Well, I quickly realized two things:

  • 0402 surface mount packages are way too small for comfort.
  • The SMT technology used in the Ruckus seem to be the larger 0603, not 0402. Which would, of course, have been less of a pain to solder.

Breathing carefully, I did manage to mount the six leds to the board, as you can see in the picture above. I only dropped three LEDs in the process, of course making them disappear forever. One PCB pad was lifted when removing the resistors that were populated on the PCB in place of the LEDs. After some micro-surgery with an Xacto knife I did manage to save the pad, though.

More Blinkenlights in the house!

I have located the console port of the VF2111 already, maybe I find the time this weekend to get a shell on the box and poke around some more. I hope the beamforming that these boxes do can make for an interesting WiFi radarscope after some hacking.

To be continued…

Some Handy Bash Functions

Probably a couple of times a day I use pipelines like foo | cut -d\ -f3 | sort -u or awk '$5 ~ /foo/ { print $3, $5 }'. Well, while working on an assignment for my study I decided that I had to put an end to this terrible neglect of using Bash’s expressiveness. :)

So, I made two additions to my stable of practical Bash functions:

match_field() Returns a boolean value when a field in a line matches a pattern:

1
2
3
4
5
# match_field <fieldnum> <RE> <line> ; match field in line
function match_field() {
  nf=${1}; re=${2}; shift 2;
  [[ ${!nf} =~ ${re} ]]
}

extract_field() Is a bit like cut, it prints the content of a field in a line:

1
2
# extract_field <fieldnum> <line> ; extract field from line
function extract_field() { nf=${1}; shift; echo ${!nf}; }

Both abuse positional parameters to select fields, expect this to break horribly when using other field separators than default $IFS.

These can be used to make many of the common cut and awk constructs that probably many of us use over and over again:

1
2
3
4
5
6
7
8
9
while read line
do
  if match_field 2 "foo" ${line}
  then
      foo=$(extract_field 1 ${line})
      bar=$(extract_field 3 ${line})
      echo ${bar} ${foo}
  fi
done < ${somefile}

This is equivalent to the awk script:

1
2
3
  ($2 ~ /foo/) {
      print $1, $3;
  }

Not really more efficient in lines of code, indeed. It doesn’t require forking awk, though. So in tight loops, this might be a bit more easy on system resources. That is all moot because this was just another exercise in going Bash all the way. :)

Cellular Automata in Bash

Stephen Wolfram eat your heart out. We don’t need no stinking Mathematica when we have Bash. I wish I could afford Mathematica, though. ;)

ca.sh Is a one-dimensional elementary cellular automaton written in Bash. This implementation uses a string of binary digits to store its world in a variable called states.

The following function reads this variable to lookup the states of a cell and its immediate neighbours:

1
2
3
4
5
6
7
8
9
# neigh <cell index> : returns neighbourhood state as integer
function neigh() {
        # cell(n - 1), wrap on edge
        state=$((4 * ${states:(${1} == 0)?${#states} - 1:${1} - 1:1}))
        # self
        state=$((state + 2 * ${states:${1}:1}))
        # cell(n + 1), wrap on edge
        echo $((state + ${states:(${1} == (${#states} - 1))?0:${1} + 1:1}))
}

Even with the comments this makes for some nice Bash code golf. I think the if-statements of the shell are plain ugly, so in this case I used the conditional operator to wrap around the begin and end of the string in states when looking up the states of the cells on the far left and right.

The value of the neighbourhood can then be fed to ca() which does return the next state for a cell based on the current rule number:

1
2
3
4
# ca <state> <rule> : returns new binary state for cell
function ca() {
        echo $(((${2}>>${1})&1));
}

Yup, that’s right, Bash has bitwise operators. :)

These two functions can then be combined like so to display succesive generations op the automaton:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# run ca algorithm
for ((;;)) {
        # display current state using ANSI colors
        display=${states//0/$'\e[0;30;44m '}
        echo ${display//1/$'\e[0;30;45m '}

        next_states=""

        # update cells
        for((c=0;c < ${#states};c++)) {
                next_states=${next_states}$(ca $(neigh ${c}) ${rule})
        }

        states=${next_states}
}

As you can see, I used a regular-expression replace to change the values in states to spaces with an ANSI escape sequence defined background color. Pretty elegant, I think. Although I don’t like the temporary variable display too much.

The full code of ca.sh is included below the break:

Querying Terminal Size in Bash

Today I stumbled upon the Bash variables COLUMNS and LINES. These look neat as, if they actually worked, would mean not having to call tput to get the current size of the terminal.
Bzzzt! Bad luck. These variables are only set when the interactive shell receives a SIGWINCH signal, they are not available to scripts, exactly where they are actually useful. I’m not sure where you’d want to use these in an interactive shell apart from useless gimmicks like having a clock in the corner of your terminal.

I wanted to use these to redraw the screen on a window resize in a new Bash hack that I’m working on. Like so:

1
2
3
4
5
trap on_resize SIGWINCH
function on_resize() {
  do_stuff ${COLUMNS} ${LINES}
  # ...etc.
}

As some sort of masochistic challenge, I’m using only pure Bash, no external commands, in the program I’m working on. So I had to come up with a way to get the dimensions of the terminal screen without resorting to tput.

The terminal escape sequence ESC-[18t makes the terminal respond with its dimensions. This can be used in the following way to query the terminal for its size:

1
2
3
4
function term_size () {
  { echo -ne \\e[18t && read -s -r -d t size; } <> /dev/tty
  echo ${size#*;}
}

For example:

hessch@substrate:~$ term_size
51;72

Update: The function above hangs on the read in some cases. Echoing using read -p is more elegant and does not suffer from hanging. Also especially on some versions of MacOS X echo -ne doesn’t grok \e for escape. The following works better:

1
2
3
4
5
6
function term_size() {
  {
      read -p $'\e[18t' -s -r -d t size }
  } <> /dev/tty
  echo ${size#*;};
}

The following two functions help accessing either the columns or the rows part:

1
2
3
4
5
6
7
function term_cols () {
    s=$(term_size); echo ${s/*;}
}

function term_rows () {
    s=$(term_size); echo ${s/;*}
}

These can be used as default values when the variables COLUMNS and LINES are unset. Like so:

hessch@substrate:~$ echo ${COLUMNS:-$(term_cols)}
72
hessch@substrate:~$ echo ${LINES:-$(term_rows)}
51

That saves some useless terminal I/O when COLUMNS and LINES are available.