They said it couldn't be done!

- ...but I'll show them. I'll show them all. Muahahahaaa. Igor, you can put the lightning conductor away now.
- Yeth marthter.


Ok so I finally managed to wade through the Internet's mire of awful Googled code to my goal of actually writing a message on an LCD panel. Who said the internet was the greatest research tool ever devised? Not me that's who.

Anyway, I still have a few bugs to iron out of this LCD panel interface code (it could be faster, the sleep() calls are excessively long at the moment) but at least my wiring is vaguely sane.

Soldering on in the face of adversity.

I thought I'd treat myself to a bit of raw electronics this week. Nothing too complicated though, my electronics knowledge is something I really need to work on one day.

So, anyway I bought a couple of LCD panels ("DEM 16217 SYH-LY" see here) so that I can have some means to display status information while the robot is disconnected. By "status information" I really mean a way of monitoring when all daemons have started, if and when any daemons die for some reason and also things like RAM usage, CPU load and uptime.

Currently I'm half way through setting up a prototype circuit on a breadboard so that I have something to send instructions to, from the C code that I'm throwing together to make sure everything is going to work nicely.

As soon as I have written a message on the LCD panel with my software I can tear the prototype to bits and solder the chopped cable to the LCD panel permanently. I'll need to get an enclosure box for the panel too to prevent any damage that it would otherwise sustain as a result of GS's murderous, bloodthirsty rampages.

When this is done the LCD driver daemon will be similar to the logfile daemon in that any other daemon can send messages to it and have them displayed on the LCD panel any time. I think I may finally be getting somewhere with LCAV.

Smokin' Pipes

I have designed a simple but hopefully effective means for the various daemon processes to communicate with eachother. Before any daemons are started, the parent process populates an array, each element contains a pipe (pair of integers), a function pointer (for the daemon to execute when it starts) and an integer in which to store the PID of the daemon after it has started.

These pipes are all initialised in the parent process and all the function pointers are filled in. Then a macro causes the set of daemons to fork() and store their PIDs in the array.

This means that every single daemon has access to all of the other daemons' pipe handles. So at run time each daemon can talk to any of the others simply by open()ing whatever pipe handle it wants to talk to and writing messages to it. Info about the parent process is also stored in the array so it can talk to its daemons if needed.

This is all very neat and tidy and simple to code but it's probably not very robust as far as detecting when any of the daemons have died for some reason. I still need to do some investigations into it but I suspect that I could either test the pipes in some way to check the remote end is still open using standard system calls) or possibly by periodically polling each pipe to prompt a timely response from the remote end.

I chose this method over TCP sockets for two reasons: 1) its faster and 2) I don't plan to move any daemons onto different computers, this will not be a distributed computing platform (at least not to start with).

Enlightenment

I spent the last year in Tibet learning about nirvana and being at one with whatever, got bored with yak milk, came home. That neatly explains my lack of blog activity lately.

I'm tearing up my original designs for Grumpy Snail and I'm redesigning the LCAV software from scratch more or less. This is because I've learned a heap about linux server/daemon programming since 12 months ago.

My new design is going to be more stable and fault tolerant and basically simpler than the previous ideas.

I've had a few sparks of interest from my chums at VBForums.com and so I'm kind of resurrecting this project from the limbo state it has been languishing in since last summer, plus it's a good a project as any for practicing my linux programming away from work.

Make like a tree

The last few days have been too hot / busy / drunken to get any useful coding done on this project.

However, tomorrow I'm going to start designing the makefile(s) for the compilation / linking of the various modules together.

As I've said previously, I'm going to have the default make target (of each individual module) perform the compilation (-c) of the object files. A secondary (recessive) target will be called "standalone" and will perform a full compilation to an executable for that particular module.

This means I can easily unit-test each module separately from the main application. This will be most useful for valgrind and gdb debugging. To handle special cases where the actual code needs to be different (for instance, providing a main() function) the standalone targets will all provide #define STANDALONE, which will let the compiler make sense of the code for its module. The master makefile may also have a standalone target that makes all of the standalone binaries all at once, although this will be of limited usefulness apart from code-sanity testing.

This will undoubtedly get a bit complex later on in the development. I'm not sure how I'll get around the pipe comms issues in the standalone versions but I'll burn that bridge when I come to it.

the makefiles will be arranged in a tree, one master makefile in the top-level directory and then another makefile for each module inside that module's code folder. This will allow all the standalones to be segregated away from each other and should minimize makefile rot, as most of the sub-makefiles will be almost identical to each other and therefore can easily be repaired / recovered. This will be a bit more work but in the long run should save some dependency hassles.

DB test successful

Just finished hooking up the toolchain test for MySQL and GCC. Everything compiled and ran successfully apart from an alarming number of memory issues in MySQL and the Velleman K8055 libraries, as reported by valgrind.

As a simple test I have setup the k8055 board and I'm reading its input channels every second and inserting the values into a table in the database. This is actually pretty close to the main functionality of the gsk8055d daemon as I had originally designed it. There will be extra functionality in the final version that allows ad hoc channel reads / writes. These extras will need to go into a separate table because of efficiency optimisation.

As it stands, I have just compiled this as a standalone program for now. The main daemon tree will need much further planning before any real functionality is inserted. I feel it more important to have the skeleton working robustly (kernel signals, logging etc) before everything else.

I'm designing the daemon modules to be compilable as standalone / embedded anyway so they can hopefully be debugged as standalones before being united into one big app much later on in the project.

Handover.

Moved all the live source to grumpy. Also made a start on the mysql tables. I'll be backing up source and DB to external HDD every few days or after every major bug fix.