No seriously, on this pages should slowly appear my efforts to automatically water my plants.

Disclaimer

I will update this site irregularly as it is one of my pet project with no clear time horizon (or direction for that matter). Mostly I do this because I'd like to keep some ordered notes and monitor some progress for my own sake only. Why then put everything online? As part of my intend to toy around with xhtml/css/js a little.

Mission statement

Alright so what is this all about? As you can see on the left I have a fair amount of plants. Who are in constant need of love, care and most of all water. Being a fair programmer and a hardware enthousiast I figured I should do something about it. Some automatic system. It can't be that hard to build a humidity detector right? And how hard can it be to control a simple servo with a computer? Right. Quite hard it turns out.

But first the Master Plan. While writing my masters thesis I was doing research on the cerebellum and (simulated) robotic control. The model which partly resulted from that research exhibited some properties which would be ideally suited for my life giving experiment. The model is able to predict the effect of it's actions and as a consequence can incorporate that knowledge into it's current actions. When you give water now the soil humidity takes a while to settle. In other words this model can gracefully approach a target humidity level. As a matter of fact it learns to do so.

Enough with the dry stuff already! Not too long ago I won a bet which resulted in this baby. Together with my slug this would make the ideal combination.

Did you know...

That you can easily apply for sample of IC's at large producers? I am completely new to this whole electronics business, but I was stumped. Got myself some temperature sensors and ADC chips.
Got my OLED display today! Really hope I will never lose the included datasheet... Can't seem to find the model on the web. Time to heat up the soldering iron!

Always make a schema

This schema roughtly shows how I want to wire up the IOW to the control program. As the slug is not fast enough to do all the necessary calculations I plan to wire everything to our shared server 'slashpunt'. Doing the calculations there should not be a problem, the results can again be send back to the slug/IOW.

Unbelieveble

Up until now I was testing my IOW on my Macbook. But I have come to the stage where I want my IOW to be permanently connected to my slug. The documentation prescribed a whole lot of make's and, more worrying, some udev. Brrrrr. Cold shivers down my spine. To my great surprise it worked in one go! Look how pretty it is:

			root@slug:/home/nobody/share/LinuxSDK/Kernel_2.6/Driver# ls /dev/usb   
			iowarrior0  iowarrior1
			root@slug:/home/nobody/share/LinuxSDK/Kernel_2.6/Driver# 
		

Two thumbs up for the people at CodeMercenaries.

Java on a ARM processor

Just don't. SableVM has not had a release since 2005, JamVM is bugged at the moment. Sun's JVM does not work on a ARM processor, haven't tried Java ME though. This morning I decided to drop the entire Java thing and compile the iowkit. This is a library supposedly implementing a nice API to the IOW. Documentation is a bit flacky on this subject. It appears there are two way of accessing your IOW, one through raw select()'s and ioctl()'s. The other using the iowkit library. This library needs to be compiled by yourself and it requires CMake, some obscure building environment. More importantly you need to search and replace some paths in several files in order to point to the correct locations. This could be better.

The IOWKit Library

As stated yesterday you have to compile the library yourself. After doing so, I had to admit that my knowledge on C++ programming was seriously lacking. I had to turn to the forums of CodeMercenaries to ask how I should use the library. There, as always, I got a reply in less than 30 minutes! They just released a newer version of the library with (remember my post of yesterday, flacky documentation, obsured build env?) better documentation and simple make! I love these guys. The included test program uses the library and supplies many starting points for future uses.

The Makefile

Dreaded for a long time it seemed that I had no choice but to start writing a Makefile to compile my programs. Well here it is:

			MODULE_DIR=/home/nobody/share/LinuxSDK/Kernel_2.6/iowkit-1.5/iowarrior-2.6
			all: advopen

			clean :
				rm -f advopen;

			advopen : advopen.c
				gcc -Wall -g -I ${MODULE_DIR} advopen.c -o advopen -liowkit
		

Especially the last option, -liowkit, took me a while to figure out. This option tells the linker which shared library it should use.

For the eyes

That wasn't too hard. Wired up the OLED display to the IOW and used the sample program included with the IOW to produce some text! Now I only need to figure out how to modify the program so I can use it. More importantly I need to figure out how to switch individual pins on the board. I have no idea how to do that and the sample programs do not appear to make me any wiser.

JamVM

Alright, a short entry. Remember JamVM which I couldn't get to work a couple of weeks ago? Well it works just as well as SableVM. As a matter of fact way better as it is still an active project (last release Feb. 2007) while SableVM appears really stale (last release 2005).

And then there was light!

I was looking into getting my OLED display to work with Java and was stumbling through the API but it was not quite clear to me how these Reports should be issued to the IOW. Then I came across this charming project called IOWJ. Actually I found it again, I forgot about it. This guy wrote an amazingly comprehensive library including just about everything I could wish for. The library would not Just Work on my slug as a jar was missing on my system (rt.jar). This jar contained the sun.misc.Queue class and as IOWJ was released before Java 1.5 it had no access to, for example, a LinkedList which is a perfect substitute. I am now modifying the original IOWJ source to use LinkedList. I really hope I can get this to work. Compiling with:

			javac -cp /path_to/codemercs.jar:/path_to/IOWJ.jar MyIOWClass.java
		

You can guess the run command. :)

Definitely 'Good Friday'!

Look at this beauty! I got it to work!! Really stoked now. Thank you Thomas! (That slug in the picture is not my actually, a flatmate decided he wanted one as well. :) )

Individual pins

Breakthrough after breakthrough. Today I got my IOW to switch individual pins on and off. First da code!

			int[] arr = {0x00, 0xf7, 0xff};
			long returnValue = dev24.writeReport(0, arr);
			if( returnValue != (long)arr.length) {
				System.out.println("Failed to write, should be: "+ \
					(long)arr.length + " was: "+ returnValue);
			}
		

It took me longest to figure out what I should sent to our dearest IOW. The integer array 'arr' holds the magic. First thing which puzzled me were all those 0xff, 0xf7 etc. This turned out to be an hex value defining a byte. See this website for a reference sheet. Here you can see that the hex value 0xf7 stands for the byte 11110111 with the MSB(Most Significant Bit) left. That MSB and LSB was an other thing I didn't get from the manual. The ReportID in the case that you want to write to interface 0 is 0x00. For example if you want to write a report to the LCD use ReportID 0x05. The ReportID is the first byte in 'arr' followed by the two bytes describing the state of the 16 (2*8) pins on my IOW24.

Intentionally left blank.

Intentionally left blank.