botix-devel Mailing List for Botix C Robotics Framework

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hij geeft een error 107  op S1 (eerste device)

Ik heb een paar screenshots bijgesloten van avr-insight met de variabelen en 
waar t misgaat.

Hellup!!

Greetz,
Ger.

Hi,

I've made a Bash-scripts directory that contains a few scripts to switch 
registry.c and h files.

good luck with it ;)

Ger.

Sounds good, keep me posted!

- Wouter

On Tue, 2006-06-06 at 20:47 +0200, Ger Apeldoorn wrote:
> Ey Wouter,
> 
> After some modifications, the new memory saving hal works. (Avr doesnt have 
> uint4_t type variables)
> 
> I succesfully registered my 24 devices and dumped a pinmap & devmap.
> 
> I fiddled a bit with my drive unit, but it is not in working order. First 
> suspect is something in the hardware but it is hard to measure with my scope 
> which turns out to be pretty useless.. :(
> 
> Greetings,
> Ger.
> 
> 
> _______________________________________________
> Botix-devel mailing list
> Bot...@li...
> https://lists.sourceforge.net/lists/listinfo/botix-devel

Ey Wouter,

After some modifications, the new memory saving hal works. (Avr doesnt have 
uint4_t type variables)

I succesfully registered my 24 devices and dumped a pinmap & devmap.

I fiddled a bit with my drive unit, but it is not in working order. First 
suspect is something in the hardware but it is hard to measure with my scope 
which turns out to be pretty useless.. :(

Greetings,
Ger.

Hi Wouter,

How is the Hal optimalisation doing??? There's no rush if you'll get it done 
yesterday! ;)

Greetings,
Ger.

Hi,

Here's some news about the cvs service from sourceforge.

This week, I was fed up with the regularly failing sf cvs service and put it 
on my own server. 

I'll look into it which is better for our needs.

For now,

Greetings,
Ger.
Greetings,

You are receiving this mail because you are a project admin for
a SourceForge.net-hosted project. One of our primary services,
CVS, suffered a series of interrelated, critical hardware failures
in recent weeks. We understand how frustrating this CVS outage
must be to you and your users; however, our top priority remains
preservation of the integrity of your data.

The series of CVS hardware failures prompted us to expedite the
deployment of planed improvements to our CVS infrastructure,
drawing upon much of the knowledge that we gained from our
Subversion deployment. Our improved CVS service architecture,
which we plan to deploy tomorrow afternoon (2006-05-12), will
offer greater performance and stability and will eliminate several
single points of failure.

The Site Status page (https://www.sf.net/docs/A04) will be
updated as soon as the new infrastructure is rolled out. In the
interim, please read the important information provided below
to learn about how these changes will affect your project.

Summary of changes, effective 2006-05-12:

1. Hostname for CVS service

Old: cvs.sourceforge.net

New: PROJECT_UNIX_NAME.cvs.sourceforge.net

This change will require new working copies to be checked out of all
repositories (so control files in the working copy will point to the
right place). We will be updating the instructions we supply, but
instructions that your team has written within documentation, etc. will
need to be updated.

cvs -d:pserver:ano...@cv...:/cvsroot/gaim co gaim

would be changed to

cvs -d:pserver:ano...@ga...:/cvsroot/gaim co gaim

2. ViewCVS

We are moving from ViewCVS to its successor, ViewVC. ViewVC is
currently in use for our Subversion service.

3. Sync delay

Old: CVS pserver, tarballs and ViewCVS provided against a separate
server which is a minimum of three hours behind developer CVS.

New: ViewVC will be provided against developer CVS (it will be current).
CVS pserver will be provided against a secondary server (not developer
server) with a maximum expected delay of two hours.

Follow-up work is planned (this infrastructure takes us 80% of the way)
to essentially eliminate the sync delay.

4. Read-only rsync service

As a new service offering, we are now providing read-only rsync access
against developer CVS. This allows projects to efficiently make
on-demand backups of their entire CVS repository.

All projects should be making regular backups of their CVS repository
contents using this service.

5. Nightly tarball service

Nightly tarball service is being dropped in lieu of read-only rsync
service. Projects which currently depend on nightly tarballs for
repository backups will need to begin using rsync to make a backup copy
of their repository contents.

We see this as a major functional improvement. For a number of reasons,
tarballs have fallen out of sync with the data in the repository at
times in the past few years. Tarballs required a substantial amount of
additional disk, and I/O to generate. The move to read-only rsync
allows backups to be produced on-demand, with an update frequency chosen
by the project.

6. Points of failure

In the past, developer CVS service for all projects was provided from a
single host. CVS pserver service was provided from individual backend
heads based on a split of the data.

Under our new design, developer CVS and most of our CVS-related services
are provided from one of ten CVS hosts (count subject to increase with
growth). Each host is independent, and makes a backup copy of the
repository data of another host (which is used to provide the pserver
CVS service).

Failure of a single host will impact only the availability of data on
that host. Since the data is split among a larger number of hosts, the
size of data impacted by an individual host outage is substantially
smaller, and the time required for us to restore service will be
substantially shorter.

This rapid architecture change has been made possible specifically using
the research we performed for our recent launch of Subversion service.
We've applied our best practices, produced a substantial amount of
internal documentation, and kept an eye toward maintainability.
This effort has allowed us to deploy this new architecture quickly
once hardware was received, and will permit us to quickly scale
this service horizontally as growth and demand requires. 

Many other minor improvements have also been made to improve the service
offering and make it less trouble-prone. The most important of which are
listed above. For a full description of the new service offering, and
for information on how to use the services described above, please refer
to the site documentation for the CVS service after the service has been
launched: https://www.sf.net/docs/E04

Thank you,

The SourceForge.net Team 

.

Hi,

Here's some news about the cvs service from sourceforge.

This week, I was fed up with the regularly failing sf cvs service and put it 
on my own server. 

I'll look into it which is better for our needs.

For now,

Greetings,
Ger.

Hi Wouter,

Only just had a chance to take a look at your refactoring of the HAL due 
to my 3rd son being born and all... ;)

I think it is nessesary to use enums to make it easier. These numbers 
just arent as clear as i'd like. -Working on it-

You mentioned that you're working on the AFSMs and made real progress.
Can you put it in CVS pls?

Thanks,
Ger.

Well, I am not so much recovering from the holidays, but more from a heart 
attaque.... So I am going slow for a while....

Greetz

Richard

>From: Ger Apeldoorn <in...@ge...>
>Reply-To: bot...@li...
>To: Botix development mailing list <bot...@li...>
>Subject: [Botix-devel] Silence... BUT NO MORE! ;)
>Date: Sun, 08 Jan 2006 18:24:08 +0100
>
>Hi all!
>
>Everybody recovering from the holidays?
>
>My robot stood still for three weeks, just no time to spare in spite of
>the fact that I had 2 weeks of vacation between my old- and my new job.
>
>My server was infected with the Linux/Lupper worm that installed a
>rootkit. I wanted to reinstall it with Ubuntu for a while and took this
>event to do this. Lots of work.... But it is on Ubuntu now, bye
>mandriva!
>
>Tonight I'll go work at it again and I'm looking forward to it. Wouter
>put in some great algorithms to use hardware with drivers, but they
>still need some work he told me.
>
>Hope to hear from you people soon... Lets give Botix another push in the
>right direction!
>
>Ger.

><< signature.asc >>

Hi all!

Everybody recovering from the holidays?

My robot stood still for three weeks, just no time to spare in spite of
the fact that I had 2 weeks of vacation between my old- and my new job.

My server was infected with the Linux/Lupper worm that installed a
rootkit. I wanted to reinstall it with Ubuntu for a while and took this
event to do this. Lots of work.... But it is on Ubuntu now, bye
mandriva!

Tonight I'll go work at it again and I'm looking forward to it. Wouter
put in some great algorithms to use hardware with drivers, but they
still need some work he told me.=20

Hope to hear from you people soon... Lets give Botix another push in the
right direction!

Ger.

>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

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

>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

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

>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

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
>  
>

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

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

Hi Ger,

A reaction on what you write....

>From: Ger Apeldoorn <in...@ge...>
>Subject: [Botix-devel] robot_default_configuration
>Date: Wed, 23 Nov 2005 20:44:59 +0100
>
>Hi Richard,
>
>I've looked at the robot_default_configuration file you've submitted.
>
>To be honest, I don't like it very much. Perhaps the big advantage of this 
>approach is the minimal memory usage but at a high price...
>I like the similar registration of AFSMs and behaviours though...

First of all, it just in a very early stage yet.... and will certainly be 
due to many essential changes yet... The basic idea behind this 
configuration file is not so much a more effectiv memory usage. That could 
be a side effect. The primary goal is to approach the entire robot as one 
subsumbtion system, rather then a gathering of hardware that is pushed into 
a subsumption alike framework.

It is indeed hard (if not impossible) to invoke hardware in this file and I 
do agree that it will not be the right way to do so. The step I am working 
on now is to make the link between the subsumbtion configuration and the 
hardware layer. The hardware layer can either be your system, or Wouters 
system. But since I have the feeling that Wouters system is also preferred 
by you, I will concentrate on his system. I am not at all content yet with 
my own definitions of AFSMs. It is indeed very unpractible.

>Cons
>1) A specific sensor cannot be searched by name anymore.
That should be possible.

>2) This approach requires lots of code to process all the defines when you 
>try to actually make use of them in the code.
More preprocessor code to create a better system should never be considered 
a problem! But as mentioned b4, hardware should be exluded from this file.

>3) I think it is not an option to register sensors this way, because you 
>cannot loop through all sensors/devices easily.
Well, you can, that is why I did built in a layer 8. But looping all your 
sensors and then processing them is just entirely AGAINST subsumption. But 
you can by putting them in layer 8 and have them processed sequentially.

>4) You cannot debug easily
Indeed, absolutely true for the moment.

>Wouter is working on an excellent way to register all devices in a really 
>flexible way and what I've seen it do makes me think this is the way to go. 
>He'll try to deliver something workable soon.
>This will not be a memory hogging thing like i've produced, it will not 
>waste memory space. (remember u08 wouter!)
>
>For an idea, you can look at the Hardware/HAL directory.
There are >several major improvements to that in the pipeline.
>
>We need to come up with a similar registration of behaviours and afsms. 
>Untill then, I'll use the 'old' fake structures that checks for a level0 
>event, then level1 etc....
Btw... levels do not exist in subsumption.... these are layers...

>
>If you still want to pursue this approach, I could make a fork in CVS or 
>you could develop it further locally... Please let me know what you want to 
>do..

So it is ment as a configuration file to define the subsumption logic. I am 
right now working on the layer that should connect to your hardware 
definitions. That just will take some time since I have to devellop the 
hardware along the line.

So I would suggest, just leave it for the time being and keep it in the back 
of your head as a system that should configure the multiple processors, the 
behaviours and the according AFSMs. It should not define hardware, although 
(I must admit) the current uploaded version suggests so. I am develloping 
this system locally and only uploading some major items, also as a backup 
and to be able to switch between machines.

Greetz

Richard

Hi Richard,

I've looked at the robot_default_configuration file you've submitted.

To be honest, I don't like it very much. Perhaps the big advantage of 
this approach is the minimal memory usage but at a high price...
I like the similar registration of AFSMs and behaviours though...

Cons
1) A specific sensor cannot be searched by name anymore.
2) This approach requires lots of code to process all the defines when 
you try to actually make use of them in the code.
3) I think it is not an option to register sensors this way, because you 
cannot loop through all sensors/devices easily.
4) You cannot debug easily

Wouter is working on an excellent way to register all devices in a 
really flexible way and what I've seen it do makes me think this is the 
way to go. He'll try to deliver something workable soon.
This will not be a memory hogging thing like i've produced, it will not 
waste memory space. (remember u08 wouter!)

For an idea, you can look at the Hardware/HAL directory. There are 
several major improvements to that in the pipeline.

We need to come up with a similar registration of behaviours and afsms. 
Untill then, I'll use the 'old' fake structures that checks for a level0 
event, then level1 etc....

If you still want to pursue this approach, I could make a fork in CVS or 
you could develop it further locally... Please let me know what you want 
to do..

Greetings,
Ger.

Hi Richard,

Just4 Fun schreef:

> Hi all,
>
> I know that classes etc are the way to program nowadays. However, 
> Atmel controllers are not designed to have classes or anything. They 
> are just made to run some simple assembler code. There is hardly any 
> RAM, so what does it benifit? If Botix should remain compatible, you 
> should consider, that RAM usage should be minimized to almost any 
> price. The least price is programmmers convienience. Please consider 
> RAM usage, and (maybe) possible compiler options to avoid RAM usage.

Class is not only a java class, but also english for "klasse", or type 
of device. This HAL is not really object oriented in the java or C++ sense.

>
>>> 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?
>>
> Port expanders are just a way of interfacing the controllers. They 
> don't have to know anything about what is going on, they just have to 
> interface / expand. So they should just be an extra interfacing layer, 
> that can be addressed by input/output devices, as if it was just 
> processor hardware.

Yes, but a device behind a port expander is addressed in a different 
manner (for the controller) than a device directly to a pin. Botix 
should know how to address it.

>
>> nope, the expander is connected to i2c. You're talking about a shift 
>> register. (cheaper, but requires a number of io pins.)
>
> This problem should also be solved if an expander is just regarded as 
> some way to interface between controller and periphials, but not as an 
> item on itself. It does not contribute to the robot, it contributes to 
> the controller.

I agree.

>
> Although the previous may sound negativ, I still think that the 
> implementation of such a layer is an improvement on Botix. Only thing 
> is that an ATmega32 may not be considered as a standard Atmel 
> controller. It is a controller that comes out of the Atmel top line. I 
> think you should also test your software on a cheaper controller????

Yes, but the memory constraint will probably be a problem. We've got to 
do our best to minimalize memory consumption, but when we add a layer 
(which was there from the beginning) to make it easier to configure for 
the end-user extra memory utilization is inevitable.

Unless we hard-code all the nessessary ports and pins directly into the 
code controlling the sonar for  instance, we've got to store this 
information somewhere. As much of the static data as possible should be 
stored in flash, and I know Wouter is trying to achieve that.

But you are right, it should be tested on a cheaper controller (f.e. 
atmega8) That's where you come in! ;)

Ger.

>
> Greetz,
>
> Richard
>
>
>
>
> -------------------------------------------------------
> 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

Hi all,

I know that classes etc are the way to program nowadays. However, Atmel 
controllers are not designed to have classes or anything. They are just made 
to run some simple assembler code. There is hardly any RAM, so what does it 
benifit? If Botix should remain compatible, you should consider, that RAM 
usage should be minimized to almost any price. The least price is 
programmmers convienience. Please consider RAM usage, and (maybe) possible 
compiler options to avoid RAM usage.

>>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?
Port expanders are just a way of interfacing the controllers. They don't 
have to know anything about what is going on, they just have to interface / 
expand. So they should just be an extra interfacing layer, that can be 
addressed by input/output devices, as if it was just processor hardware.

>nope, the expander is connected to i2c. You're talking about a shift 
>register. (cheaper, but requires a number of io pins.)
This problem should also be solved if an expander is just regarded as some 
way to interface between controller and periphials, but not as an item on 
itself. It does not contribute to the robot, it contributes to the 
controller.

Although the previous may sound negativ, I still think that the 
implementation of such a layer is an improvement on Botix. Only thing is 
that an ATmega32 may not be considered as a standard Atmel controller. It is 
a controller that comes out of the Atmel top line. I think you should also 
test your software on a cheaper controller????

Greetz,

Richard

Hi WOuter

>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?
>  
>
Yeah, mine have got 8 io pins each. When read, you get a byte containing 
the entire set of bits. You've got to AND them with a bitmask to 
determine if a single bit is high or low.
They can be used as output too.

>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?) 
>
>  
>
nope, the expander is connected to i2c. You're talking about a shift 
register. (cheaper, but requires a number of io pins.)

>>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.
>  
>
Excellent! :)

Gerrrrrrrr

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

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.

Is it possible to include the driver-includes only when they are 
actually used?

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! :)

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
>  
>

2005	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (8)	Nov (57)	Dec (8)
2006	Jan (2)	Feb (1)	Mar	Apr	May (3)	Jun (3)	Jul (1)	Aug	Sep	Oct	Nov	Dec

botix-devel Mailing List for Botix C Robotics Framework

botix-devel — Developers mailing list