Oliver Ludwig | 1 Mar 10:14 2006

AW: Fast Timers

Hi there.
 
I assume you get Jean's Embedded Building Blocks book. Look at bol.de or amazon for it. The book describes several usefull modules, including a software timer module. They've some advantages against the common delay. See more in the book, please.
 
If you want to use a hardware timer, just set up your LCD task waiting on a refresh event (event flags). Config your hardware timer that way it fires every 200ms a timer interrupt. The timer interrupt ISR should signal a refresh event (event flag) to the refresh task.
 
However, like in real life, on a RTOS there are many roads leading to rome ;-)
 
Try to avoid delay/sleep in your comm tasks. Implement them event driven (posting semaphore or event flags). LCD or keyboard tasks can be implemented with a delay mechanism. They are usually some kind of unimportant, compared to communication tasks.
 
Have fun
Oliver
 
 
 

Von: MicriumNewsGroup <at> yahoogroups.com [mailto:MicriumNewsGroup <at> yahoogroups.com] Im Auftrag von andreas_hagele
Gesendet: Mittwoch, 1. März 2006 07:16
An: MicriumNewsGroup <at> yahoogroups.com
Betreff: [MicriumNewsGroup] Fast Timers

Hi again.
Another questions on the timers in uC/OS.
I looked at the ARM for IAR port which also has code in there to run a
text LCD.
Looking at the delays required for the LCD I see that the OSTimeDly()
function is used. However with the timer tick usually being 1-50ms
these delay will end up being much longer than needed (ms instead of us).
It does all run fine, but the update of a simple 2 line LCD might take
200ms.
It's not a big thing, but how could that been done a bit nicer?
I could employ a dedicated hardware timer for these kind of short
delays. Having Semaphores on the timer complete would allow uC/OS to
carry on with other tasks while waiting and then switch back to the
LCD task.
Or the LCD task could have a loop delay and run on lowest priority. So
it might not run a lot but when it does it will do the display faster.

Or is there some sort of a generic approach in using fast timers
within the uC/OS environment?

Cheers

Andreas







YAHOO! GROUPS LINKS


Ramakrishnan Thangamani | 1 Mar 05:10 2006
Picon

help on semaphore

Hi
      Can any one help me in getting a sample code for semapore action explaining
it completely.


Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.

SPONSORED LINKS
Technical support outsourcing Online technical support Technical support
Computer technical support Technical support software Internet technical support

YAHOO! GROUPS LINKS


Ramakrishnan Thangamani | 3 Mar 04:56 2006
Picon

Semaphore

Hi
      Can any one help me in getting a sample code for semapore action explaining
it completely.

Regards
Ramakrishnan.T

Relax. Yahoo! Mail virus scanning helps detect nasty viruses!

SPONSORED LINKS
Technical support outsourcing Online technical support Technical support
Computer technical support Technical support software Internet technical support

YAHOO! GROUPS LINKS


Leon Woestenberg | 1 Mar 19:12 2006
Picon

Re: Round Robin

Andreas,

andreas_hagele wrote:
> Hi there.
> I understand that uC/OS is not doing round robin multitasking, only
> priority based:  Paragraph 3.05 "uC/OS-II always executes the highest
> priority task ready to run".
>
> What's the recommended way to configure the tasks if there are a
> number of equal important tasks to run?
> I have about 4-6 comms tasks which needs to tick along all on the same
> 'priority', then there are some data processing tasks (lower) and some
> data backup tasks (even lower). 
> How can I get the comms tasks, let's say 5 of them, to tick along all
> on the same time slice?
>   
Typical RTOS's that support round robin scheduling (often at each single 
priority level) use time periods called quantums (quanta?).

Either a task is pre-empted immediately by any higher-priority task, or 
a task is pre-empted after its quantum has expired, and the next task at 
the same priority gets the processor.

As uCos-II does not support multiple tasks at the same priority level, 
you should either:
- add that support
- create a high priority round robin scheduler that round robins the 
priority of your set of equal threads.

Regards,

Leon.

 
Leon Woestenberg | 1 Mar 19:08 2006
Picon

Re: uCos equivalent to Unix select?

Hello,
>
> There is no way to wait on multiple events in µC/OS-II.
> If this you really need this, I have made a patch for an old µC/OS-II 
> version wich enable this functionnality. It works on a commercial 
> product for about 3 years. I have recently found a way to not use this 
> patch. This let me upgrade µC/OS-II without compatibility problem (the 
> patch modifies the core of µC/OS-II).
I haven't done anything with µC/OS-II in the last year, but I remember 
there being the flags synchronization mechanism where one or more flags 
could be posted and pended for.

This is quite identical to Unix's select(), except for the syntax.

Regards,

--

-- 
Leon Woestenberg

R&D Senior Designer
Embedded Systems and Software
Axon Digital Design

+31 (0)13 511 66 66
+31 (0)13 511 41 51

leon.woestenberg <at> axon.tv
http://www.axon.tv

 
andreas_hagele | 6 Mar 03:02 2006
Picon

Re: Fast Timers

Oliver,
thanks for that info. I read the Embedded Building Blocks some years
ago but it was someone else's copy. Might try to source it again.

In a nutshell my problem is to time things much faster than the uC/OS
system timer.
I believe as soon as I use any uc/OS functions they will response only
in the speed of the system timer (eg 10ms) not faster.

Regards

Andreas

--- In MicriumNewsGroup <at> yahoogroups.com, "Oliver Ludwig"
<oliver.ludwig <at> ...> wrote:
>
> Hi there.
>  
> I assume you get Jean's Embedded Building Blocks book. Look at
bol.de or amazon for it. The book describes several usefull modules,
including a software timer module. They've some advantages against the
common delay. See more in the book, please.
>  
> If you want to use a hardware timer, just set up your LCD task
waiting on a refresh event (event flags). Config your hardware timer
that way it fires every 200ms a timer interrupt. The timer interrupt
ISR should signal a refresh event (event flag) to the refresh task. 
>  
> However, like in real life, on a RTOS there are many roads leading
to rome ;-)
>  
> Try to avoid delay/sleep in your comm tasks. Implement them event
driven (posting semaphore or event flags). LCD or keyboard tasks can
be implemented with a delay mechanism. They are usually some kind of
unimportant, compared to communication tasks.
>  
> Have fun
> Oliver
>  
>  
>  
> 
> 

 
andreas_hagele | 5 Mar 20:55 2006
Picon

Re: Round Robin


> - add that support
> - create a high priority round robin scheduler that round robins the 
> priority of your set of equal threads.
> 

Leon,
thanks for these suggestions. I think I'll give the first one a miss
for now. Might have to learn more about uc/OS before tackling this.

The second option is a very good idea. Have a task at high priority
(scheduler) to set a high priority of next task in the list of equal
priority tasks. Having the 'scheduler' sleep for eg 1 tick and then
change to the next one.
That looks like a very simple solution.

I just somehow thought uC/OS would have something like this built in.
However a round-robin looking system does happen when each task has
some wait/sleep on a regular basis.

Cheers

Andreas 

 
Mohit Sindhwani | 6 Mar 03:19 2006
Picon

Re: Round Robin


--- Leon Woestenberg <leon.woestenberg <at> axon.tv> wrote:

> Andreas,
> 
> andreas_hagele wrote:
> > Hi there.
> > I understand that uC/OS is not doing round robin
> multitasking, only
> > priority based:  Paragraph 3.05 "uC/OS-II always
> executes the highest
> > priority task ready to run".
> >
> > What's the recommended way to configure the tasks
> if there are a
> > number of equal important tasks to run?
> > I have about 4-6 comms tasks which needs to tick
> along all on the same
> > 'priority', then there are some data processing
> tasks (lower) and some
> > data backup tasks (even lower). 
> > How can I get the comms tasks, let's say 5 of
> them, to tick along all
> > on the same time slice?
> >   
> Typical RTOS's that support round robin scheduling
> (often at each single 
> priority level) use time periods called quantums
> (quanta?).
> 
> Either a task is pre-empted immediately by any
> higher-priority task, or 
> a task is pre-empted after its quantum has expired,
> and the next task at 
> the same priority gets the processor.
> 
> As uCos-II does not support multiple tasks at the
> same priority level, 
> you should either:
> - add that support
> - create a high priority round robin scheduler that
> round robins the 
> priority of your set of equal threads.
> 
> Regards,
> 
> Leon.
> 

Actually, Infineon used to have an application note
about using Round Robin on MicroC/OS-II on their
website and you can still get a link to that page if
you ask Google.  Unfortunately that page has expired
on the Infineon site and that not seems to be lost.

If I find it, I shall post it to the list.  If someone
else has a copy of that note, it may be helpful.

Cheers
Mohit.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

 
sakthi sam | 4 Mar 17:12 2006
Picon

very urgent ,very urgent please...................

pl tell me micros os installation specification PIII
 
give me the link of website to download code with compiler but that should be run the os.thanking you,very urgent

Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.

SPONSORED LINKS
Technical support outsourcing Online technical support Technical support
Computer technical support Technical support software Internet technical support

YAHOO! GROUPS LINKS


Jean J. Labrosse | 6 Mar 13:30 2006

Re: Fast Timers

No, no, no, no!  If you have a faster time source or other events, 
uC/OS-II will respond to them as quickly as they arrive.  uC/OS-II is 
a preemptive kernel and thus, it does not have to wait for the tick 
interrupt to occur and is thus not limited to doing things every 10 
mS.

Jean

--- In MicriumNewsGroup <at> yahoogroups.com, "andreas_hagele" 
<andreas_hagele <at> ...> wrote:
>
> Oliver,
> thanks for that info. I read the Embedded Building Blocks some years
> ago but it was someone else's copy. Might try to source it again.
> 
> In a nutshell my problem is to time things much faster than the 
uC/OS
> system timer.
> I believe as soon as I use any uc/OS functions they will response 
only
> in the speed of the system timer (eg 10ms) not faster.
> 
> Regards
> 
> Andreas
> 
> 
> --- In MicriumNewsGroup <at> yahoogroups.com, "Oliver Ludwig"
> <oliver.ludwig <at> > wrote:
> >
> > Hi there.
> >  
> > I assume you get Jean's Embedded Building Blocks book. Look at
> bol.de or amazon for it. The book describes several usefull modules,
> including a software timer module. They've some advantages against 
the
> common delay. See more in the book, please.
> >  
> > If you want to use a hardware timer, just set up your LCD task
> waiting on a refresh event (event flags). Config your hardware timer
> that way it fires every 200ms a timer interrupt. The timer interrupt
> ISR should signal a refresh event (event flag) to the refresh task. 
> >  
> > However, like in real life, on a RTOS there are many roads leading
> to rome ;-)
> >  
> > Try to avoid delay/sleep in your comm tasks. Implement them event
> driven (posting semaphore or event flags). LCD or keyboard tasks can
> be implemented with a delay mechanism. They are usually some kind of
> unimportant, compared to communication tasks.
> >  
> > Have fun
> > Oliver
> >  
> >  
> >  
> > 
> >
>

 

Gmane