Reply by Brad Griffis April 15, 20052005-04-15
"admin" <admin@dsp-bg.info> wrote in message 
news:f5ea693a.0504120840.693fedac@posting.google.com...
> "Brad Griffis" <bradgriffis@hotmail.com> wrote in message > news:<sBu6e.543$nK5.534@newssvr33.news.prodigy.com>... >> If you right-click on the clock manager and go to properties you can >> select >> the number of microseconds per system tick. The GUI makes this >> calculation >> based on the speed you typed into the global properties so make sure the >> speed in the global properties accurately reflects the speed you're >> running >> the processor at (i.e. make sure you're setting up PLL, etc.). >> >> I think the default number of microseconds/tick is usually 1000 (i.e. 1ms >> tick). That means an interrupt is occurring every 1ms to interrupt the >> processing, update the system time, update which threads are ready to >> run, >> and then give control to the highest priority ready thread. >> >> Brad >> >> "admin" <admin@dsp-bg.info> wrote in message >> news:f5ea693a.0504091049.492c0e74@posting.google.com... >> > Hello friends, >> > >> > I am tiring to base my application on DSP/BIOS. >> > >> > Unfortunately it seems to me that this OS puts big performance >> > overhead (more than 20%). >> > >> > In the literature I couldn't manage to find a clear statement about >> > the period of invocation of the task scheduler. For my case it seems >> > that this period is about 80us. Can I control this parameter of the >> > OS? >> > >> > Any help will be highly appreciated! >> > www.dsp-bg.info >> > > > > Hello Tim, Brad > > The scheduler is invoked periodically, right? > So I have referred to the period of the above periodic action. > > Will try to describe in little bit more details. > I have set the microseconds per system tick in the clock manager to > 1000 (default value). > > I have a main task and one periodic function (with period of > invocation 8ms) in my project. > The periodic function is invoked at 8ms as it is expected. > > In the main task I have put a code to toggle the XF pin using > asm("BSET XF") and asm("BCLR XF") > > With the scope I see that the toggling is interrupted each 80 us for > about 5us. > I don't have any interrupts enabled, so I concluded that it is a > scheduler, which interrupts me each 80us. > But according Brad I have to expect invocation of the scheduler each > 1ms. > > OK probably I have missed something. Will repeat the investigation. > > > Tim, Brad, thank you for your time! > Admin >
Admin, CPU Timer 0 is typically used by DSP/BIOS to interrupt you periodically. You can look at these registers to see what the periodicity of that interrupt is. Brad
Reply by admin April 12, 20052005-04-12
"Brad Griffis" <bradgriffis@hotmail.com> wrote in message news:<sBu6e.543$nK5.534@newssvr33.news.prodigy.com>...
> If you right-click on the clock manager and go to properties you can select > the number of microseconds per system tick. The GUI makes this calculation > based on the speed you typed into the global properties so make sure the > speed in the global properties accurately reflects the speed you're running > the processor at (i.e. make sure you're setting up PLL, etc.). > > I think the default number of microseconds/tick is usually 1000 (i.e. 1ms > tick). That means an interrupt is occurring every 1ms to interrupt the > processing, update the system time, update which threads are ready to run, > and then give control to the highest priority ready thread. > > Brad > > "admin" <admin@dsp-bg.info> wrote in message > news:f5ea693a.0504091049.492c0e74@posting.google.com... > > Hello friends, > > > > I am tiring to base my application on DSP/BIOS. > > > > Unfortunately it seems to me that this OS puts big performance > > overhead (more than 20%). > > > > In the literature I couldn't manage to find a clear statement about > > the period of invocation of the task scheduler. For my case it seems > > that this period is about 80us. Can I control this parameter of the > > OS? > > > > Any help will be highly appreciated! > > www.dsp-bg.info > >
Hello Tim, Brad The scheduler is invoked periodically, right? So I have referred to the period of the above periodic action. Will try to describe in little bit more details. I have set the microseconds per system tick in the clock manager to 1000 (default value). I have a main task and one periodic function (with period of invocation 8ms) in my project. The periodic function is invoked at 8ms as it is expected. In the main task I have put a code to toggle the XF pin using asm("BSET XF") and asm("BCLR XF") With the scope I see that the toggling is interrupted each 80 us for about 5us. I don't have any interrupts enabled, so I concluded that it is a scheduler, which interrupts me each 80us. But according Brad I have to expect invocation of the scheduler each 1ms. OK probably I have missed something. Will repeat the investigation. Tim, Brad, thank you for your time! Admin
Reply by Tim Wescott April 11, 20052005-04-11
admin wrote:
> Tim Wescott <tim@wescottnospamdesign.com> wrote in message news:<115gbhpmdej59f4@corp.supernews.com>... > >>admin wrote: >> >> >>>Hello friends, >>> >>>I am tiring to base my application on DSP/BIOS. >>> >>>Unfortunately it seems to me that this OS puts big performance >>>overhead (more than 20%). >>> >>>In the literature I couldn't manage to find a clear statement about >>>the period of invocation of the task scheduler. For my case it seems >>>that this period is about 80us. Can I control this parameter of the >>>OS? >>> >>>Any help will be highly appreciated! >>>www.dsp-bg.info >> >>80us sounds reasonable for a task scheduler. >> >>If you have one critical operation (such as data collection) that must >>happen faster you may be able to put it into an interrupt, and (for >>example) set an OS event (semaphore, flag, whatever your OS calls them) >>when the whole set is collected. Interrupts don't store as much context >>as a task switch does, and they don't restore context, and they don't >>have to figure out which context to restore, so they can respond with >>much less overhead at the cost of much less flexibility. > > > Hello Tim, > > Thank you for the answer! > > Do you think I can make the period of invocation of the scheduler let say > 1ms? It is using the TMS320C55 DSP/BIOS. > > Regards > Admin
I'm sorry. I assumed when you said "period of invocation" it was poor english, and you were complaining about response time. Yes, you should be able to set the scheduler clock tick to anything you want if you understand your RTOS, and there's another post in this thread that answers how to do it. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by Jerry Avins April 11, 20052005-04-11
admin wrote:

   ...

> Hello Tim, > > Thank you for the answer! > > Do you think I can make the period of invocation of the scheduler let say > 1ms? It is using the TMS320C55 DSP/BIOS.
I've never used a commercial RTOS in my embedded projects. I preferred to write my own with just those features I needed, all of them under my control. This exchange has confirmed the soundness of that plan. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by admin April 11, 20052005-04-11
Tim Wescott <tim@wescottnospamdesign.com> wrote in message news:<115gbhpmdej59f4@corp.supernews.com>...
> admin wrote: > > > Hello friends, > > > > I am tiring to base my application on DSP/BIOS. > > > > Unfortunately it seems to me that this OS puts big performance > > overhead (more than 20%). > > > > In the literature I couldn't manage to find a clear statement about > > the period of invocation of the task scheduler. For my case it seems > > that this period is about 80us. Can I control this parameter of the > > OS? > > > > Any help will be highly appreciated! > > www.dsp-bg.info > > 80us sounds reasonable for a task scheduler. > > If you have one critical operation (such as data collection) that must > happen faster you may be able to put it into an interrupt, and (for > example) set an OS event (semaphore, flag, whatever your OS calls them) > when the whole set is collected. Interrupts don't store as much context > as a task switch does, and they don't restore context, and they don't > have to figure out which context to restore, so they can respond with > much less overhead at the cost of much less flexibility.
Hello Tim, Thank you for the answer! Do you think I can make the period of invocation of the scheduler let say 1ms? It is using the TMS320C55 DSP/BIOS. Regards Admin
Reply by Brad Griffis April 11, 20052005-04-11
If you right-click on the clock manager and go to properties you can select 
the number of microseconds per system tick.  The GUI makes this calculation 
based on the speed you typed into the global properties so make sure the 
speed in the global properties accurately reflects the speed you're running 
the processor at (i.e. make sure you're setting up PLL, etc.).

I think the default number of microseconds/tick is usually 1000 (i.e. 1ms 
tick).  That means an interrupt is occurring every 1ms to interrupt the 
processing, update the system time, update which threads are ready to run, 
and then give control to the highest priority ready thread.

Brad

"admin" <admin@dsp-bg.info> wrote in message 
news:f5ea693a.0504091049.492c0e74@posting.google.com...
> Hello friends, > > I am tiring to base my application on DSP/BIOS. > > Unfortunately it seems to me that this OS puts big performance > overhead (more than 20%). > > In the literature I couldn't manage to find a clear statement about > the period of invocation of the task scheduler. For my case it seems > that this period is about 80us. Can I control this parameter of the > OS? > > Any help will be highly appreciated! > www.dsp-bg.info >
Reply by Tim Wescott April 9, 20052005-04-09
admin wrote:

> Hello friends, > > I am tiring to base my application on DSP/BIOS. > > Unfortunately it seems to me that this OS puts big performance > overhead (more than 20%). > > In the literature I couldn't manage to find a clear statement about > the period of invocation of the task scheduler. For my case it seems > that this period is about 80us. Can I control this parameter of the > OS? > > Any help will be highly appreciated! > www.dsp-bg.info
80us sounds reasonable for a task scheduler. If you have one critical operation (such as data collection) that must happen faster you may be able to put it into an interrupt, and (for example) set an OS event (semaphore, flag, whatever your OS calls them) when the whole set is collected. Interrupts don't store as much context as a task switch does, and they don't restore context, and they don't have to figure out which context to restore, so they can respond with much less overhead at the cost of much less flexibility. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by admin April 9, 20052005-04-09
Hello friends,

I am tiring to base my application on DSP/BIOS.

Unfortunately it seems to me that this OS puts big performance
overhead (more than 20%).

In the literature I couldn't manage to find a clear statement about
the period of invocation of the task scheduler. For my case it seems
that this period is about 80us. Can I control this parameter of the
OS?

Any help will be highly appreciated!
www.dsp-bg.info