Thread: [Botix-devel] Nesting drivers
Status: Beta
Brought to you by:
vorik2005
Menu
▾
▴
botix-devel
|
From: Ger A. <in...@ge...> - 2005-12-02 20:07:21
|
Hi Wouter, Can I nest drivers in the HAL? I want to make a custom driver for my sonar-tower that can make the tower go up, make a scan etc. However, in order to do that, I need to control the servo's and the sonar, and read multiple microswitches. I want to use the other drivers in to read and use these items. Is this possible? When will the HAL be integrated in Botix? No hurry, yesterday is soon enough... I'd like to start writing the drivers!! :) See you later! Gerrrrrrrrr |
|
From: Wouter H. <ww....@zo...> - 2005-12-04 15:31:44
|
Of course everything is possible, but the main limitation here is memory. If I would add such complex behavior to the HAL I'm afraid I need a lot more datastructures. (links between devices, and the type of link (input, output, multiplex, etc)) The relation between multiple devices should reside in the "user" code I think, although it might be possible if we create an afsm abstraction where every afsm has a set of devices linked to. (Remember: afsms can coexist on the same "level") About the integration: I'm still not very happy by the way the hal is linked to the physical pins at this moment. I need to figure out how to control the pins via registers directly. We could use the current way (using avrlib to drive the pins) for now, and change the way we drive pins later. Problem is: the whole project is then only usable on avr32 for the moment. I let this decision up to you ;-) - Wouter On Fri, 2005-12-02 at 21:07 +0100, Ger Apeldoorn wrote: > Hi Wouter, > > Can I nest drivers in the HAL? > > I want to make a custom driver for my sonar-tower that can make the > tower go up, make a scan etc. > > However, in order to do that, I need to control the servo's and the > sonar, and read multiple microswitches. I want to use the other drivers > in to read and use these items. > > Is this possible? > > When will the HAL be integrated in Botix? No hurry, yesterday is soon > enough... I'd like to start writing the drivers!! :) > > See you later! > > Gerrrrrrrrr > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Botix-devel mailing list > Bot...@li... > https://lists.sourceforge.net/lists/listinfo/botix-devel |
|
From: Ger A. <in...@ge...> - 2005-12-04 19:06:30
|
Hi! See the remarks below: Wouter Houweling schreef: >Of course everything is possible, but the main limitation here is >memory. If I would add such complex behavior to the HAL I'm afraid I >need a lot more datastructures. (links between devices, and the type of >link (input, output, multiplex, etc)) > > Okay, lets not do that then. >The relation between multiple devices should reside in the "user" code I >think, although it might be possible if we create an afsm abstraction >where every afsm has a set of devices linked to. (Remember: afsms can >coexist on the same "level") > > Affirmative! :) If nessessary, I can make a seperate (custom) driver for my elevator-sonar etc... >About the integration: I'm still not very happy by the way the hal is >linked to the physical pins at this moment. I need to figure out how to >control the pins via registers directly. > >We could use the current way (using avrlib to drive the pins) for now, >and change the way we drive pins later. Problem is: the whole project is >then only usable on avr32 for the moment. I let this decision up to >you ;-) > > Why is it only usable on avr32 if we use avrlib? I dont understand as avrlib is also for all avr devices. >- Wouter > > /me >On Fri, 2005-12-02 at 21:07 +0100, Ger Apeldoorn wrote: > > >>Hi Wouter, >> >>Can I nest drivers in the HAL? >> >>I want to make a custom driver for my sonar-tower that can make the >>tower go up, make a scan etc. >> >>However, in order to do that, I need to control the servo's and the >>sonar, and read multiple microswitches. I want to use the other drivers >>in to read and use these items. >> >>Is this possible? >> >>When will the HAL be integrated in Botix? No hurry, yesterday is soon >>enough... I'd like to start writing the drivers!! :) >> >>See you later! >> >>Gerrrrrrrrr >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>_______________________________________________ >>Botix-devel mailing list >>Bot...@li... >>https://lists.sourceforge.net/lists/listinfo/botix-devel >> >> > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Botix-devel mailing list >Bot...@li... >https://lists.sourceforge.net/lists/listinfo/botix-devel > > |
|
From: Just4 F. <rb...@ho...> - 2005-12-05 10:39:54
|
>Wouter Houweling schreef: >>The relation between multiple devices should reside in the "user" code I >>think, although it might be possible if we create an afsm abstraction >>where every afsm has a set of devices linked to. (Remember: afsms can >>coexist on the same "level") >> >> >Affirmative! :) If nessessary, I can make a seperate (custom) driver for my >elevator-sonar etc... This in fact the thing I am trying to model right now, I think. I 'm trying to define a model in which every input and output is defined as an AFSM. The trick should be that several AFSMs can be combined to one AFSM, that can be used in a behaviour. The main problem right now is that it is very difficult to keep such a system as flexible and easy in configuration as desired by Botix. But I am only starting..:) To your memory problem: Since you have 2 ATmega32s, you maybe can use your second ATmega32 as a variable memory as well. Some data do not have to be online and can be put in your second ATmega32. Sounds a bit like a message server..:) Or maybe some interrupt driven processes might be put at your second ATmega32? Greetz, Richard |
|
From: Ger A. <in...@ge...> - 2005-12-05 10:55:24
|
Just4 Fun schreef: > >> Wouter Houweling schreef: > > >>> The relation between multiple devices should reside in the "user" >>> code I >>> think, although it might be possible if we create an afsm abstraction >>> where every afsm has a set of devices linked to. (Remember: afsms can >>> coexist on the same "level") >>> >>> >> Affirmative! :) If nessessary, I can make a seperate (custom) driver >> for my elevator-sonar etc... > > > This in fact the thing I am trying to model right now, I think. I 'm > trying to define a model in which every input and output is defined as > an AFSM. The trick should be that several AFSMs can be combined to one > AFSM, that can be used in a behaviour. The main problem right now is > that it is very difficult to keep such a system as flexible and easy > in configuration as desired by Botix. But I am only starting..:) I'm looking forward to your results.. The easy though flexible bit is indeed important. > > To your memory problem: Since you have 2 ATmega32s, you maybe can use > your second ATmega32 as a variable memory as well. Some data do not > have to be online and can be put in your second ATmega32. Sounds a > bit like a message server..:) Or maybe some interrupt driven processes > might be put at your second ATmega32? Euh... I've asked Sinterklaas for some ATMega8's to try some stuff out.. I hope that I'll get it tonight! ;) BTW: Do you have some (C) code to decode InfraRed signals? The second ATMega32 will be used for resource intensive and not time-critical AI tasks, such as path planning and problem dissection. So any more tasks are not really desirable. /me > > Greetz, > > Richard > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Botix-devel mailing list > Bot...@li... > https://lists.sourceforge.net/lists/listinfo/botix-devel |
|
From: Just4 F. <rb...@ho...> - 2005-12-05 14:06:52
|
>Euh... I've asked Sinterklaas for some ATMega8's to try some stuff out.. I >hope that I'll get it tonight! ;) Did you behave that well last year?? :) > >BTW: Do you have some (C) code to decode InfraRed signals? I don' t have C code, but I do have tested and functioning AVR assembler programs that can decode IR signals that are send with the RC5 protocol. That is the Phillips standard of about every TV remote control. It is an interrupt driven program to decode the signal, so I do think it will be impossible to translate everything into C. I don't expect C to be fast enough to handle RC5 reliably, but maybe you can rewrite it yourself in a way that strongly resembles the assembler program, meaning fe addressing registers directly in stead of using variables. The assembler code works fine for me (on any AVR controller) in combination with the cheapest universal tv remote control from the local Blokker retailer. Price was about 7 EUR. Interested? Greetz, Richard |
|
From: Ger A. <in...@ge...> - 2005-12-05 20:08:36
|
Just4 Fun schreef: >> Euh... I've asked Sinterklaas for some ATMega8's to try some stuff >> out.. I hope that I'll get it tonight! ;) > > > Did you behave that well last year?? :) Well, I guess, I got 7 of them and a very nice LCD I2C display with a 12 key numeric keyboard! :D >> >> BTW: Do you have some (C) code to decode InfraRed signals? > > > I don' t have C code, but I do have tested and functioning AVR > assembler programs that can decode IR signals that are send with the > RC5 protocol. That is the Phillips standard of about every TV remote > control. It is an interrupt driven program to decode the signal, so I > do think it will be impossible to translate everything into C. I don't > expect C to be fast enough to handle RC5 reliably, but maybe you can > rewrite it yourself in a way that strongly resembles the assembler > program, meaning fe addressing registers directly in stead of using > variables. The assembler code works fine for me (on any AVR > controller) in combination with the cheapest universal tv remote > control from the local Blokker retailer. Price was about 7 EUR. > > Interested? Very much so, please send it.. Is it documented? Gerrrrrrrrrrrr > > Greetz, > Richard > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Botix-devel mailing list > Bot...@li... > https://lists.sourceforge.net/lists/listinfo/botix-devel |
|
From: Just4 F. <rb...@ho...> - 2005-12-06 22:56:25
|
>From: Ger Apeldoorn <in...@ge...> >Date: Mon, 05 Dec 2005 21:08:24 +0100 >Very much so, please send it.. Is it documented? Look at http://www.igsboekamp.nl/robotigs/includes/parts_header.php?idpart=10 Greetz, Richard |
Thanks for helping keep SourceForge clean.
X