[Botix-devel] HAL for Botix

[Wouter H. <ww....@zo...>]

Hi all,

Tonight I committed the first version of a HAL for Botix.
(Botix/Hardware/Hal)

The purpose of the HAL is to provide a controlled layer over the
hardware, to protect the hardware and ease in debugging. Because the HAL
knows the purpose of the connected devices and their pins it knows when
an illegal command is performed: like setting an input pin. This greatly
reduces errors and creates a safety net for beginners.

Another purpose of the hal is to check and debug the software pin map 
to the hardware pin map by printing out what the HAL knows about the pin
usage. It is possible to show runtime the status of the devices & pins.

Last but not least: the functional programming can use symbolic device
names instead of pin address. This very much increases code readability
and makes it for easy device programming. (No knowledge required *how*
the device works, let the hal take care of that.)

Short overview of the hall:

- Class: set of devices.
- Device: abstract device which is connected to zero or more pins.
- Port: set of pins used for a device.
- Pin: actual hardware pin.
- Driver: small function which contains all logic to use a device. (i.e:
send a ping for a sonar device)

Hal->|-> Class 'Sensor' |-> Device |-> Driver 'srf04'
			 | 		 |		  					   |-> Pin A1 Input
 	    |		 |		  					   |-> Pin A2 Output
 	    |		 |
 	    |		 |-> Device	|-> Driver
 	    |		 			|-> Pin
 	    |
     	    |-> Class 'Led' -> etc.
 	    |
 	    |-> Ports |-> Pin 1 (owner device 'Sonar1'
 				  |-> Pin 2 (owner device 'Sonar1'
 				  |-> Pin 3 (owner device ''
 
Drivers do not know which actual pins they use, because there is a 
device pin map -> actual pin map. Because of this drivers can be very
generic.

To keep memory footprint low, all strings are pointers back into rom. As
always with abstraction some cpu overhead is unavoidable. At this moment
it is unknown what the performance on an actual embedded cpu (AVR) is.

Controlling the hal works like this:

register_class("switches");
register_class("leds");
register_class("sonars");
	
register_dev("led1", 
	     find_class("leds"), 	/* class */
	     1, 			/* number of pins */
	     (PORT []){1, OUTPUT}, 	/* pin list */
	     &generic_led);		/* driver */

register_dev("sonar_left" 
	     find_class("sonars"), 		/* class */
	     2, 				/* number of pins */
	     (PORT []){1, OUTPUT, 2 INPUT}, 	/* pin list */
	     &generic_led);			/* driver */

set_dev("led1", ON);
int dist = get_dev("sonar1");

A driver looks like this:

float generic_led(int mode) {
	printf("Led driver called!\n");
	switch(mode) {
		case ON: set_pin(1, ON); break;
		case OFF: set_pin(1, ON); break;
	}
}

You get the idea ;-)

At this moment this concept is working when compiling hal_demo.c on a
pc. (Botix/Hardware/Hal)

The hal should be directly driven by an protocol stack or small virtual
machine running on the CPU.

One big problem at this time is memory consumption, I will keep trying
to reduce the memory footprint.

Let met know what you all think of this!

Greetings,
Wouter