Re: [Botix-devel] HAL for Botix
Status: Beta
Brought to you by:
vorik2005
Menu
▾
▴
Re: [Botix-devel] HAL for Botix
|
From: Wouter H. <ww....@zo...> - 2005-11-13 16:43:08
|
On Sun, 2005-11-13 at 16:16 +0100, Ger Apeldoorn wrote:
> Hi Wouter,
>
> Looking good this HAL!
>
> What are your ideas for devices that do not connect directly to a port
> on the avr?
>
> Example: i2c compass, io pin on an i2c port expander etc.
>
> The i2c compass has got a single address and register, but the i2c port
> expanders can get different addresses and each have multiple pins.
For i2c we can use some kind of virtual device, which is what the
compass driver uses when executing commands. Port expanders can use
multiple pins and just have to be defined, right?
Device linking is possible, so led1 is connected to portexpander port 1
which is at its turn connected to a set of avr pins. (right?)
>
> Is it possible to include the driver-includes only when they are
> actually used?
>
Yep no problem, so the more we stuff things in drivers the more modulair
and 'rom' efficient things will get. This is the big advantage of using
function pointers.
> Once you've verified its workings on the AVR, you can kick out the
> existing registration structure and implement this..
>
> On MSN, you stated that we both changed hal.c and that you cannot commit
> now. You can combine the changes if i'm not mistaking, i'll check.
> Yes. On the changed (local) file, right click, choose Team and click
> Create Patch.
> Then save that patch to a file.
> Then, overwrite your local file with the one from CVS. (make a backup!)
> <- yeah right!
> Then choose Apply patch to import your own changes.
>
> That should be it. (Untested, alpha and a garanteed untill it breaks!)
> ;) Good Luck! :)
>
Done.
- Wouter
> Ger.
>
> Wouter Houweling schreef:
>
> >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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >-------------------------------------------------------
> >SF.Net email is sponsored by:
> >Tame your development challenges with Apache's Geronimo App Server. Download
> >it for free - -and be entered to win a 42" plasma tv or your very own
> >Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> >_______________________________________________
> >Botix-devel mailing list
> >Bot...@li...
> >https://lists.sourceforge.net/lists/listinfo/botix-devel
> >
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Botix-devel mailing list
> Bot...@li...
> https://lists.sourceforge.net/lists/listinfo/botix-devel
|
