Fred's Home Page

About me
csh is bad
Help out
KRoC/Linux (old)
occam upgrades
occam tutorial
Projects (PhD)
Quick gdb
UNIX crashcourse
WG / WGBuilder


(some people call these things blogs)

The last 8 entries are displayed on this page, older ones can be found here. An RSS feed is available here.


Spent about 30 minutes staring at some AVR assembly dump (from gcc toolchain) wondering why the start of FLASH didn't look like an interrupt vector table. Turns out, yes, it really was missing, and the fact the device even executed (partially successfully!) the vector-less code it had in it was a surprise. Conclusion: -c is not the flag you are looking for (when trying to build a standalone binary blob for an AVR) — obvious.. That was less of a hastle than trying to find a means to program the device in the first place (having a shelf, and tube, full of ATmega8L-8 chips). I did have a crude ZIF-socket'd prototype board hooked up to the parallel-port (via a dissected cable from one of my old Iomega Zip drives, lost technologies for you) bit-banged from uisp. The last time I used it (probably 2-3 years ago at least) it worked. This time ran into some problems (1) no parallel port on the new desktop, and (2) when I did find a box with one of those legacy port things, didn't work anyway (after rmmod'ing ppdev, parport_pc and friends). Even after botching it with an ISP connector for Atmel's own programmer, still nothing; figured the reset pullup or other resistors floating around were upsetting it perhaps. Gave up on that, found a chipless Arduino Uno and used that — worked first time :-) [1]. I'll get around to installing bootloaders on all of these chips at some point to ease future programming grief! Then back to writing the code for it (in C) that I was trying to write in the first place.

[1] Well, programmed successfully — the missing vector table caused its own wierdness, as did the fact there was a 74HC04 hex inverter on the breadboard whose Vcc wasn't connected (that caused greater wierdness).


Today's gripe: people whining about performance from MATLAB and Java, when the source data is kept as human-readable text files containing floating-point numbers (or binary strings). Some more education is clearly required — i.e. get these people to implement the sscanf() behaviour for parsing floats, then see if they have the same opinions about why their program is running so slowly. What I find quite odd is the view that a 100 MiB text file containing nothing but comma-separated floats is useful for anything other than a computer; vim will happily open it, but not many other editors will cope so well.


Spent way too many hours chasing a bug in JavaScript that I hadn't expected, but on second thought, isn't completely unexpected. Simple(ish) scenario: AJAX wotsit returns a bunch of HTML with input fields and whatnot, along with a bunch of IDs that say what they're called. After bunging the HTML into the page, the JavaScript iterates over these fields and does the appropriate JQuery stuff to setup auto-completion, on-change, etc. And it all broke. Turns out that something like this:

    for (i=0; i<thing.length; i++) {
        $("#wotsit_" + thing[i]).change (function () { do_stuff (thing[i], document.getElementById ("wotsit_" + thing[i]).value); });

does not work in the way I expect. Perhaps I should have read up more on JavaScript's anonymous functions :-).. Basically it seems that the anonymous function is only created once, but in fact I really wanted thing.length of them. Hence, regardless of which one is invoked, they all get the last value of "thing[i]" and that particular element's value. So the lesson from that is that anonymous functions are generated based on syntax, not semantics. I.e., if "thing" had, say, 3 things in it, the above loop is not equivalent to its unwound form:

    $("#wotsit_" + thing[0]).change (function () { do_stuff (thing[0], document.getElementById ("wotsit_" + thing[0]).value); });
    $("#wotsit_" + thing[1]).change (function () { do_stuff (thing[1], document.getElementById ("wotsit_" + thing[1]).value); });
    $("#wotsit_" + thing[2]).change (function () { do_stuff (thing[2], document.getElementById ("wotsit_" + thing[2]).value); });

That wasn't obvious.. Solution: more grot, returning chunks of JavaScript (unwound loops) that are then evaluated in JavaScript.


Still ploughing through a multitude of emails (around 1400 now). Getting things together for CPA-2015, with a range of good and interesting papers :-). Minor interlude for a couple of days lacking hot-water after a series of small power-cuts (that left the UPS moderately unhappy, though better now, and the house alarm whining). Reluctant to call a qualified boiler engineer, spent some time poking around the boiler PCB with a multimeter (nothing obviously wrong) and trying to follow the fault-finding flowchart in the boiler service manual (impossible state reached) [footnote: such flowcharts should really be subject to some formalism in QA to ensure completeness!]. Descaled the secondary (hot-water) heat exchanger, that gobbled up a whole half-litre of 25% hydrochloric acid solution, still fizzing slightly — hot water flows much more happily again, but didn't cure the problem (symptom was no hot water and everything in the boiler looking okay, minus it actually firing up to give hot water; central-heating fine). Turns out (perhaps obviously) that the busted component was the hot-water temperature sensor probe (a thermistor), but not busted enough to trigger the "DHW temperature sensor broken" fault. Typical readings range from 15k-Ohm to 1.5k-Ohm, this one was reading about 300 Ohms. Disconnected we now have hot water \o/, a boiler whining about a broken sensor, and a replacement in the post (for less than 5 quid). Having studied the boiler PCB/wiring in some detail, if that ever needs replacing (unlikely, but 150-200 quid) might consider a home-brew/open-source boiler solution on an Arduino. The boiler hardware itself is fail-safe (in case the PCB fails in really strange ways, the boiler will spew hot water outside, rather than explode the central heating system).

In more (or less) serious things, decided it was about time to learn and embrace the whole JQuery, JQuery-UI, JavaScript, AJAX and JSON stuff. On one hand: wow, what a grotty hack that has grown out of all control and is generally abusing the web to do things web-browsers and servers were not originally intended to do. On the other hand, allows for the fairly easy creation of fancy web-based apps, so I'll let it off. And JavaScript, despite its ills, offers a fairly quick way for people to get into rudimentary coding (without requiring anything much more than a web-browser and a functional brain) which is also good — and the nice folk over at W3Schools have plenty of decent tutorials.


Apologies for any lack of communication on my part! I've got about 4" of exam questions to mark and an inbox with over 900 messages waiting to be dealt with. Things moving forward steadily however; for urgent things, repeated email prods may be the way to go (or give me a call).


Straight into the thick of it, oof. Mostly spending time preparing teaching for this term, and I have a lot! Also picked up an extra 20% role as "Undergraduate Director of Studies (QA)", that really does require some time put into it! (and a good excuse for some crude PHP hacking to build a coursework deadline co-ordination/planning thing — as a colleague said, an interface only a mother could love, but hey, it works! ;-)).

Managed to put a bit more time into Guppy and the EV3, heading closer towards my 4x dining-philosophers. The LEGO is built but untested, and I only just tested driving the motor from Guppy the other day, but that sort of worked (needs my Github version of Ralph Hempel's ev3dev-modules that has the /dev/ interface in it). At the moment it looks like this:

@include "guppy_stdlib.gpi"

@external "guppy" "define ev3_pwm_init () -> bool = 64"
@external "guppy" "define ev3_pwm_shutdown () = 64"
@external "guppy" "define ev3_pwm_on_fwd (val int motor, val int power) = 64"
@external "guppy" "define ev3_pwm_off (val int motor) = 64"

define test_g56 (chan(string) screen!)
  timer tim
  int t
  bool b
    screen ! "hello, EV3 world!\n"
    b = ev3_pwm_init ()
    if (b == false)
      screen ! "failed to initialise PWM device..\n"

    tim ? t
    ev3_pwm_on_fwd (0x01, 30)
    tim ? after (t + 300000)
    ev3_pwm_off (0x01)

    screen ! "done!\n"

    ev3_pwm_shutdown ()

Just back from visiting the Stella Maris Primary School in Folkestone, showing a group of year 4 children some LEGO robots and answering a lot of fairly inquisitive questions! Also met Stella the class gecko, which was a fairly placid but quite large creature.


Happy New Year! :-). Picked up where I left off getting an MSc student project from last year ready for teaching in a few months. This is a simple IDE for writing AVR assembly aimed at the Arduino Uno, written in C++ (g++) using Qt (and the pretty snazzy Qt Creator IDE) also using QScintilla, calling nocc to do the lexing for QScintilla and for assembling the code proper (then avrdude to upload to the Arduino). Decided for a second time that I don't care much for object-oriented in C++. Whilst the abstraction is mostly comfortable (and does apply well to some things), layer on layer of inheritance and overriding can make it very hard to follow independent bits of code within the system, without some broad global knowledge. For the time being I'll stick to my default C approach of structures and lots of parameters-passing.


Had some crazy wind+rain on the 23rd that nearly took a tree out (now it's just leaning precariously). The storms managed to take the power out too (again, really need to replace the UPS..). The only device that survived the 8+ hour outage was my LEGO EV3 (running at essentially zero load) which has now been up for 15 days!

Last modified: 2015-11-03 19:36:30.617558195 +0000 by Fred Barnes [ds] [plain]
Page generated: Tue Nov 03 19:36:31 2015
Valid XHTML 1.0! Valid CSS!