getting to grips with WebbotLib. (some questions.)

[dunk]

hey guys,
so i'm finally assessing whether WebbotLib is useful for my current project. (i hear all the cool SORers are using it now.)

on the whole it looks promising but it is short of documentation.
(hint to all you users of WebbotLib: time to give something back to Webbot in the form of HowTo documentation...)
while there is lots of example code for the Axon on how to connect to various hardware, i've not found any good examples of program structure yet.

my application has 2 AVRs communicating over a wireless link.
the main program loop must be kept synchronised at both ends so the transmitting phase and receiving phase of the programs do not overlap at either end.
(more on the project here: http://sites.google.com/site/mrdunk/)

so,
1) my program needs a main function that lasts exactly 20ms.
2) i need a counter that resets every 50 loops. (ie, every second.)

i speculate my appControl function would look like this:

Code: [Select]

TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){

   // this loop needs to execute once per 20ms.
   // my code in here.

   if (loopCount >= 49){
      loopCount = 0;      // is it ok to manually reset loopCount?
      // this code executes every 50 cycles. (ie, once per 50x20ms. (1 second))
      // my code in here.
   }

   return (20000 + loopStart - clockGetus());    // 20000us == 20ms. Return 20ms after function starts.
}

so, questions:
a) am i missing this sort of example in the documentation anywhere?
b) is it ok to manually reset loopCount? (ie, "loopCount = 0;") or is it better to keep my own separate counter for this?
c) how can i tell which hardware timer the system clock (loopStart) is using?
d) can i change which hardware timer the system clock is using?
e) i have a spare 16bit timer but if i didn't, could the system clock use an 8 bit one?


that's all for now,

dunk.

[KurtEck]

Hi Dunk,
Thanks for the help with the PS2 stuff.  My robot now walks and the like and can be controlled by either the PS2 and/or the XBee DIY remote control... 

I am new to this stuff as well, but will give you my thoughts... Take them with a grain of salt.

1) I think what you have mentioned might work for the timing.  I went with a different approach on my first attempt at servo group moves.  That was I would save away the clock when I setup a move (clockGetus) and then when I renentered the code I would check to see if the time has elapsed (clockHasElapsed). But then again I also wanted to check for new input...

2) Loop count- I have not tried this one, For something like this I simply created my own variable, but my guess is that would work...

...
a) I have not seen any documents that show the main function.  What I saw was sample programs like Raven...
b) I think it should not be a problem.  If you look at core.c you will find this loop:

Code: [Select]

do{
breathe();
if(delay!=0){
while(!clockHasElapsed(loopStart,delay)){
// Allow interrupts to breathe
breathe();
}
}
loopStart = clockGetus();
delay = appControl(++loopCount,loopStart);
}while(1);

c-e) looking at timer.c - After the hardware init function is called it will try to find a timer to use.  I believe that it will use an 8 bit timer but only if it can not find a 16 bit one.  I did not remember being able to see what timer it is or be able to change it.  But since it is set only after your hardware init function has been called it did not feel like it was a problem.

Good Luck
Kurt

[KurtEck]

Quick update to my first reply:  I don't think updating the counter will work as the values passed to a C function are typically passed by value, so you will just be updating your local copy.

Kurt

[madsci1016]

(hint to all you users of WebbotLib: time to give something back to Webbot in the form of HowTo documentation...)

Webbot wants to keep control of the 'official' document, and is open to suggestions for changes (I'm sure he's tired of hearing from me about the weak points) although he is busy right now with the test group and debugging his project designer.

As far as want you are trying to do, Webbot is turning away from letting people directly use timer, in fact in his next release, you won't be able to access hardware timer at all, directly or through timerOverflowAttach(). He would rather have people using the scheduler. Look through the scheduler.h section on using the scheduler.

[Webbot]

Hi Dunk

my program needs a main function that lasts exactly 20ms.

Well the main loop gets passed its start time (ie a call to clockGetus) ie loopTime just before it is called.
It can also return a time to pause by.
So if you want it calling around every 20ms then you can do a number of things:
1. Store the previous value of lastTime and check if you are belng called quicker/slower than this ie

Code: [Select]

TICK_COUNT lastTime; // the last loop time

// Called once - so store the clock
TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
    lastTime = loopCount;
}

TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){

    if(clockHasElapsed(lastTime, 20000)){
         // 20ms mas elapsed since last processed
         // so do what you wanna do
         lastTime = loopCount;
    }
    return 0; // just keep calling me
}

Or alternatively you could measure the lastTime and the loopCount and return a value to say 'pause for the remainder of 20ms'

Or even better: if you only want someting to happen every 20ms or so then use the scheduler and let it happend via interrupts

Can I reset loopCount

No - its a local variable. An you cannot reset the timer counter as I've stopped you doing it on purpose. Why? Well you've no idea what else is running off that timer.

Can I change which hardware timer the system clock is using?

Absolutely not! The lib assigns a timer on the fly. Doing TCNTx = 0 is a complete no-no.

So, right now, you're probably thinking 'Aargh - how do I do stuff?'.

But thats coz you are trying to take control of the CPU using the low-level techniques you are familiar with. And the whole point of WebbotLib is that you don't need to worry about that low-level stuff. You just need a mind shift. Eg if you want something to happen once/every N ticks/ms then you shouldn't be thinking 'I need to grab a timer of my own, set prescalers for my CPU Mhz  etc etc' - you just ask the lib and it tells you.

So lots of low-level questions from you (to which a lot of the answers are no - on purpose) - so how about a higher level requirement of what you are trying to achieve - and then I can guide you to the appropriate solution.

[Admin]

Just in defense of WebbotLib . . .

Its so much easier to balance interrupts and timers and software PWM simultaneously using WebbotLib. You don't even need to really understand how any of it works to get something effective working.

[dunk]

Just in defense of WebbotLib . . .

Its so much easier to balance interrupts and timers and software PWM simultaneously using WebbotLib. You don't even need to really understand how any of it works to get something effective working.

o, absolutely!
apologies if my first post sounds in any way critical of WebbotLib. that is certainly not how i intended it.
my application works at present (without using WebbotLib) because it has very tight control of the timing of the main function.

if WebbotLib does not suit my application it is a reflection on my level of crazy, trying to get a pair of AVRs to do that rather than WebbotLib's level of crazy.
if WebbotLib does suit my application (for which i am hopeful) it will greatly simplify development and the readability of the code.

so,
WebbotLib is absolutely the correct tool for a most applications. i'm 100% behind it and huge props to Webbot for developing and supporting it.

i intended this post to discuss if it can also be used in applications that require a more complex timing structure.
with that in mind, my next post in this thread will return to discussing my application.


dunk.

[KurtEck]

Hi again Dunk,

To again follow up on what Webbotlib/admin said, to do something similar to wanting something to run every n mS my first attempt was to generate my own timer handler which was working fine, but when I asked a question webbotlib suggested that I convert to use the scheduler, which I now have done.  So far it appears to be working great.  I did have some problems with recursion causing problems at first with version 13a of the library, but that was fixed in 13b.  If you are interested, I put a checkpoint zip file of my code up on a thread on lynxmotion forums: http://www.lynxmotion.net/viewtopic.php?f=7&t=5876

Like you I do like webbotlib and works great for most of my stuff...    I like you will have more questions, but probably should ask them in other thread.  Things like:

a) Is there a semi-clean way to get around using some of webbotlibs abstractions for isolated cases.  Example: PS2.  Got it working with OK with webbotlib, but I think I my clock pulses somewhere near 100k Hz, but some of the different specs show the PS2 running at 250k Hz.  For now it looks like it is working fine with my Lynxmotion PS2 controller...

b) Servos: I need to do some more investigation, but I am wondering if at run time if I can retrieve the servo pulse values (center/range) and potentially update them.  Why?  I would like to for example have a find zero point function for my robot, do whatever UI I wish to find the points and then have the program maybe store away the values into EEPROM, which is retrieved and used next time.  This allows the same program to be used on different robots without having to be editing/recompiled... 

...

Sorry for a semi-hijack of your questions...

Kurt

[dunk]

1. Store the previous value of lastTime and check if you are belng called quicker/slower than this ie

Code: [Select]

TICK_COUNT lastTime; // the last loop time

// Called once - so store the clock
TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
    lastTime = loopCount;
}

TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){

    if(clockHasElapsed(lastTime, 20000)){
         // 20ms mas elapsed since last processed
         // so do what you wanna do
         lastTime = loopCount;
    }
    return 0; // just keep calling me
}


yup. that looks like it will achieve what i want..

Or alternatively you could measure the lastTime and the loopCount and return a value to say 'pause for the remainder of 20ms'

yup. that's what i was trying to achieve with my code snippet in the first post.

Or even better: if you only want someting to happen every 20ms or so then use the scheduler and let it happend via interrupts

so each loop of the main part of my program takes nearly all the 20ms.
pre-WebbotLib experience would have me avoid interrupts this long at all costs.
there is a certain attraction doing things this way though. non timing critical tasks could be done in the main appControl part and most of the program would happen during the scheduler interrupt.

does anyone foresee any problems scheduling tasks of 19ms long every 20ms?


for all my questions about timers,
i didn't intend to swap clocks while running a program.
i was more how many 16bit timers i have to play with.

after more reading (and email from Webbot) i now know timers are auto assigned.
the system clock will be automagically picked from one of the remaining timers after all others required have been assigned. if all 16bit timers are used the system clock will use an 8 bit timer.


hmm.
that's about it for now.
i'll return here to let you know how i get on.

dunk.

[Webbot]

There are lots of ways to do what you need!

A scheduled task that takes 19ms is ok - since they run with interrupts re-enabled. So long as you don't reschedule the same task to run until it is just about to finish then it will be ok. ie At the start of your scheduled task dont reschedule it to run in 20ms and then do all of your stuff. Otherwise, if your stuff takes more than 20ms then the scheduled task will keep interrupt itself and you'll get a stack overflow. Obviously your main task will only get 1ms out of 20ms so will run slowly.

Another alternative: Use the scheduler to run every 20ms and then set a global variable to TRUE.
In your main loop return a delay of 0 so that it keeps whizzing around at full speed. The main loop can do the boring stuff and then check if the global variable has been set (ie 20ms has elapsed) and if so then clear it and do your 'every 20ms stuff'. This could give you an error of +1ms if the flag gets set but you have to spend 1ms doing the boring stuff before you see the changed flag.

My advice would be to bundle your code into the boring stuff, and the time critical stuff, and then experiment with calling them from the scheduler or in other ways. Your tests could just use delay calls to simulate the delay of running your code.

Anyway: good luck