Answers below:

"Peter Choi" <choi@mecca.ca> wrote in message
news:vzePc.151070$Mr4.39959@pd7tw1no...
> Hello Brad,
>
> A few questions:
> 1) I don't want to dis-able CLK_F_isr.  I just want to know where I can
find
> this function so I know what it does exactly.

[Brad Griffis] The DSP/BIOS source code is not available.  I can't
remember - is there something in the DSP/BIOS User's Guide about it?  I
think that essentially all it does is increment the system time and then
look to see what is the highest priority thread ready to run.

> 2) I am unable to uncheck "Enable CLK Manager" in Clock Manager's
> properties.  It is greyed out.  Any ideas of when it'd not be greyed out?

[Brad Griffis] Do you have a periodic function defined?  There may actually
be one defined by default (I forget off the top of my head).  Anyway, you
have to delete all those in order to uncheck the box.  However, don't do
that unless you plan to increment the clock manually.

> 3) With DSP/BIOS doing the call to the ISR table automatically.  How does
it
> know which source file to look at when I have multiple sources?  Or I have
> to make sure that no source files have the same function name?  I think I
> know the answer to this but just want to know if DSP/BIOS have some type
of
> checking or limitation to this.

[Brad Griffis] This is more of a compiler issue.  In C all functions have
global visibility by default.  You have to use the "static" keyword in order
to make a function visible only within that file.  Based on that DSP/BIOS
can "see" any functions anywhere in your code.  As you said you need to make
sure you're not duplicating function names in your files or else you'll get
a linker error.

> 4) My last question I was inquiring what if I have a HWI_10 triggered and
> within the ISR for this HWI_10 contains a conditional statement that may
or
> may not call another SWI.  Suppose it does call this SWI, and then HWI_13
> comes along.  So doesn't this mean HWI_13 is going to pre-empt a task
being
> processed by HWI_10?

[Brad Griffis] When HWI_10 posts the SWI the SWI will not run right away.
Since HWI_10 is higher priority it will run to completion and then your SWI
will run (provided that it is now the highest priority thread).  If during
execution of that SWI you get an interrupt from HWI_10 then you're SWI will
be pre-empted, HWI_10 will run, and then your SWI will finish execution
(again provided that it is the highest priority thread ready to run).

>
> "Brad Griffis" <bradgriffis@hotmail.com> wrote in message
> news:fIPOc.1563$hI.341018@newssvr28.news.prodigy.com...
> > As I said before the CLK_F_isr is the "heartbeat" of the OS.  If you
> disable
> > it then you no longer have an OS!  That function is intentionally placed
> as
> > HWI_14 since that is the lowest priority hardware interrupt.  I believe
> you
> > can disable that CLK_F_isr by unchecking the "use clock manager" box (or
> > something similar) under the Clock Manager properties.  If you do this
> > though you will need to manually increment the "system time" at a
> consistent
> > interval within your code for things to work right.  I can't really
> imagine
> > anyone ever wanting to do this though.
> >
> > Concerning the programming of interrupts...  There is an interrupt table
> > that will reside in memory that contains a branch to your ISR.  I
believe
> > each interrupt gets something like 8 spaces in this table.  If your ISR
> can
> > fit in 8 instructions then it would be placed directly in the table.
> > Typically though the table simply branches to your ISR.  In a non-BIOS
> > project you would need to set that up. However, DSP/BIOS takes care of
> that
> > for you.  All you need to do is type the name of your function in the
> > function name box.  Another thing to note is that you need to do context
> > save/restore for your hardware interrupts.  This can done EITHER by
> checking
> > the "Use Dispatcher" box OR by putting the interrupt keyword in your
> > function declaration BUT NOT BOTH.  Your system will crash if you try to
> do
> > both of those.  I typically just click the "Use Dispatcher" box and then
> > write a straight C function.
> >
> > Concerning your last question I  am not sure what you mean by a HWI of
> level
> > 0.  Isn't that the Reset HWI?  In general though a HWI is always higher
> > priority than a SWI.  If you are in the middle of executing a SWI when a
> HWI
> > comes in the SWI will always be pre-empted such that the HWI runs to
> > completion and then you resume the SWI (provided that it is the highest
> > priority function that has not yet run).  Is that what you want to
happen?
> > If that's not how you want things to run then you can always have your
HWI
> > immediately post a SWI and do all your processing in the SWI.
> >
> > Brad
> >
> > "Peter Choi" <choi@mecca.ca> wrote in message
> > news:W3tOc.140028$od7.138452@pd7tw3no...
> > > Hello,
> > >
> > > That is a very good description Brad.  And yes it is a 6000.  I'm
using
> > CCS
> > > v2.1 on a C6711 DSK.
> > > So I'd assume the "CLK - Clock Manager" under Scheduling is the part
of
> > the
> > > RTOS that actually controls the different threads.  I haven't read
about
> > how
> > > it does that yet but I'm sure I'll very soon.
> > >
> > > Now is there a place where I can find out what this "CLK_F_isr" does
and
> > > where it is?  It just seemed odd to me that all the other HWI can be
> > > configured for what function it calls except this and the HWI_Reset
and
> > the
> > > HWI_Reserved0, HWI_Reserved1.  Though the other 3 have meaningful
names
> > that
> > > gives why it can't be re-configured.  HWI_14 is just.... well, HWI_14.
> > >
> > > Now I have never programmed interrupts before.  Is there a specific
> > location
> > > where these ISR must reside on the memory?  I'd imagine all they are
are
> > > just whatever C function that I'd like to call in one of my source
code.
> > > How does CCS knows which source files it is in?
> > >
> > > And one more final question.  I read that all HWI has priority than
all
> > SWI.
> > > Now in case I have a HWI of level 0 that calls a function, and there's
a
> > > conditional statement in this function that may cause another
interrupt.
> > > But being in code, it can only trigger a SWI.  And because it is
called
> > from
> > > a HWI of level 0, I want it to precede every other HWI or SWI
> interrupts.
> > > But what if while within this SWI, another HWI goes off?  It doesn't
> > matter
> > > that this other HWI is at a lower priority, does it?
> > >
> > >
> > > "Brad Griffis" <bradgriffis@hotmail.com> wrote in message
> > > news:dUgOc.1166$Z56.50@newssvr33.news.prodigy.com...
> > > > HWI_14 is the time-base for the RTOS.  As you mentioned, in the
Clock
> > > > Manager you can select which timer to use as well as how many
> > microseconds
> > > > per system tick.
> > > >
> > > > Consider that the main function of the RTOS is to allow for many
> threads
> > > to
> > > > run at once with configurable prioritization as well as extensive
> > > > capabilities for synchronization and communication between threads.
> For
> > > > example, a thread might do a few things and then "sleep" for a bit.
> > While
> > > > it is "sleeping" other threads will be running and other stuff will
be
> > > going
> > > > on.  In order for this whole prioritization scheme to work, there
must
> > be
> > > an
> > > > OS kernel that is in charge of everything.  That's where they system
> > tick
> > > > that I mentioned at the beginning of this post comes into play comes
> > into
> > > > play.  The OS needs to periodically take control of things and check
> to
> > > see
> > > > if it's time for a "sleeping" task to "wake-up" again.  The OS
kernel
> is
> > > > entered every time that HWI_14 interrupt (clocked by Timer 0/1)
fires.
> > > The
> > > > system tick is the heartbeat of the OS and that's why that box is
> greyed
> > > > out.  If you disabled that interrupt then the RTOS couldn't run!
> > > >
> > > > To answer your question about having a function called directly, yes
> > this
> > > > can be done.  For example, let's say your clock manager is using
Timer
> > 0.
> > > > You could write code to configure Timer 1 to generate a periodic
> > > interrupt.
> > > > Is this a 6000 DSP?  If so you can re-map the interrupts to whatever
> you
> > > > want.  That being the case you can select HWI_4 and choose the Timer
1
> > > > Interrupt as your source and put the name of your function to run in
> the
> > > > function box.  Sure, this cuts out a little bit of abstraction so
that
> > > your
> > > > function can run faster, but now your using up another timer.  If
> you're
> > > > periodic function is a multiple of your system tick then it is best
to
> > use
> > > > the "periodic function manager" to run the function.  That way you
can
> > run
> > > > multiple functions and they are all based off the system tick.
> > > >
> > > > Brad
> > > >
> > > >
> > > > "Peter Choi" <choi@mecca.ca> wrote in message
> > > > news:4V9Oc.135865$ek5.2387@pd7tw2no...
> > > > > Hello,
> > > > >
> > > > > So how and is it possible to have HWI_14 to call the "processing"
> > > function
> > > > > in the C code directly?  When I right click and select properties
on
> > > this
> > > > > HWI_14.  The function field for "CLK_F_isr" is greyed out
preventing
> > me
> > > > from
> > > > > typing in the C function.  Also, how come it shows "CLK - Clock
> > Manager"
> > > > as
> > > > > one of its dependencies?  I thought "CLK - Clock Manager" depends
on
> > > this
> > > > > HWI_14 to call the "CLK_F_isr" function, which then somehow calls
> this
> > > > > "CLK - Clock Manager".
> > > > >
> > > > >
> > > > > "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
> > > > > news:10gi8e74nppfg4a@corp.supernews.com...
> > > > >
> > > > > > They're probably just trying to demonstrate the features of the
OS
> .
> > > > > >
> > > > > > When you use an RTOS you pay an up-front cost in man-hours and
> > > processor
> > > > > > resources.  What you get back is an ease of managing a large
> > > > > > application, because it is much easier to make the various parts
> of
> > > your
> > > > > > application run virtually independent of each other.
> > > > > >
> > > > > > So of course if all you're doing is adjusting a volume then
using
> an
> > > > > > RTOS and the example code is stupid.  When you have an
application
> > > > > > that's doing ten different things at ten different speeds,
> however,
> > > this
> > > > > > sort of thing starts making sense as the least complicated way
of
> > > > > > keeping all those individually simple things from stepping on
each
> > > > other.
> > > > > >
> > > > > > You should never forget the existence of the task loop when
you're
> > > > > > looking at your RTOS, however.  If you have a dead-simple
> > application
> > > > > > that would only break down into a few tasks you should consider
> > using
> > > a
> > > > > > task loop and leave the RTOS sitting in its nice shrink wrap.
> > > > > >
> > > > > > -- 
> > > > > >
> > > > > > Tim Wescott
> > > > > > Wescott Design Services
> > > > > > http://www.wescottdesign.com
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Hello Brad,

A few questions:
1) I don't want to dis-able CLK_F_isr.  I just want to know where I can find
this function so I know what it does exactly.
2) I am unable to uncheck "Enable CLK Manager" in Clock Manager's
properties.  It is greyed out.  Any ideas of when it'd not be greyed out?
3) With DSP/BIOS doing the call to the ISR table automatically.  How does it
know which source file to look at when I have multiple sources?  Or I have
to make sure that no source files have the same function name?  I think I
know the answer to this but just want to know if DSP/BIOS have some type of
checking or limitation to this.
4) My last question I was inquiring what if I have a HWI_10 triggered and
within the ISR for this HWI_10 contains a conditional statement that may or
may not call another SWI.  Suppose it does call this SWI, and then HWI_13
comes along.  So doesn't this mean HWI_13 is going to pre-empt a task being
processed by HWI_10?


"Brad Griffis" <bradgriffis@hotmail.com> wrote in message
news:fIPOc.1563$hI.341018@newssvr28.news.prodigy.com...
> As I said before the CLK_F_isr is the "heartbeat" of the OS.  If you
disable
> it then you no longer have an OS!  That function is intentionally placed
as
> HWI_14 since that is the lowest priority hardware interrupt.  I believe
you
> can disable that CLK_F_isr by unchecking the "use clock manager" box (or
> something similar) under the Clock Manager properties.  If you do this
> though you will need to manually increment the "system time" at a
consistent
> interval within your code for things to work right.  I can't really
imagine
> anyone ever wanting to do this though.
>
> Concerning the programming of interrupts...  There is an interrupt table
> that will reside in memory that contains a branch to your ISR.  I believe
> each interrupt gets something like 8 spaces in this table.  If your ISR
can
> fit in 8 instructions then it would be placed directly in the table.
> Typically though the table simply branches to your ISR.  In a non-BIOS
> project you would need to set that up. However, DSP/BIOS takes care of
that
> for you.  All you need to do is type the name of your function in the
> function name box.  Another thing to note is that you need to do context
> save/restore for your hardware interrupts.  This can done EITHER by
checking
> the "Use Dispatcher" box OR by putting the interrupt keyword in your
> function declaration BUT NOT BOTH.  Your system will crash if you try to
do
> both of those.  I typically just click the "Use Dispatcher" box and then
> write a straight C function.
>
> Concerning your last question I  am not sure what you mean by a HWI of
level
> 0.  Isn't that the Reset HWI?  In general though a HWI is always higher
> priority than a SWI.  If you are in the middle of executing a SWI when a
HWI
> comes in the SWI will always be pre-empted such that the HWI runs to
> completion and then you resume the SWI (provided that it is the highest
> priority function that has not yet run).  Is that what you want to happen?
> If that's not how you want things to run then you can always have your HWI
> immediately post a SWI and do all your processing in the SWI.
>
> Brad
>
> "Peter Choi" <choi@mecca.ca> wrote in message
> news:W3tOc.140028$od7.138452@pd7tw3no...
> > Hello,
> >
> > That is a very good description Brad.  And yes it is a 6000.  I'm using
> CCS
> > v2.1 on a C6711 DSK.
> > So I'd assume the "CLK - Clock Manager" under Scheduling is the part of
> the
> > RTOS that actually controls the different threads.  I haven't read about
> how
> > it does that yet but I'm sure I'll very soon.
> >
> > Now is there a place where I can find out what this "CLK_F_isr" does and
> > where it is?  It just seemed odd to me that all the other HWI can be
> > configured for what function it calls except this and the HWI_Reset and
> the
> > HWI_Reserved0, HWI_Reserved1.  Though the other 3 have meaningful names
> that
> > gives why it can't be re-configured.  HWI_14 is just.... well, HWI_14.
> >
> > Now I have never programmed interrupts before.  Is there a specific
> location
> > where these ISR must reside on the memory?  I'd imagine all they are are
> > just whatever C function that I'd like to call in one of my source code.
> > How does CCS knows which source files it is in?
> >
> > And one more final question.  I read that all HWI has priority than all
> SWI.
> > Now in case I have a HWI of level 0 that calls a function, and there's a
> > conditional statement in this function that may cause another interrupt.
> > But being in code, it can only trigger a SWI.  And because it is called
> from
> > a HWI of level 0, I want it to precede every other HWI or SWI
interrupts.
> > But what if while within this SWI, another HWI goes off?  It doesn't
> matter
> > that this other HWI is at a lower priority, does it?
> >
> >
> > "Brad Griffis" <bradgriffis@hotmail.com> wrote in message
> > news:dUgOc.1166$Z56.50@newssvr33.news.prodigy.com...
> > > HWI_14 is the time-base for the RTOS.  As you mentioned, in the Clock
> > > Manager you can select which timer to use as well as how many
> microseconds
> > > per system tick.
> > >
> > > Consider that the main function of the RTOS is to allow for many
threads
> > to
> > > run at once with configurable prioritization as well as extensive
> > > capabilities for synchronization and communication between threads.
For
> > > example, a thread might do a few things and then "sleep" for a bit.
> While
> > > it is "sleeping" other threads will be running and other stuff will be
> > going
> > > on.  In order for this whole prioritization scheme to work, there must
> be
> > an
> > > OS kernel that is in charge of everything.  That's where they system
> tick
> > > that I mentioned at the beginning of this post comes into play comes
> into
> > > play.  The OS needs to periodically take control of things and check
to
> > see
> > > if it's time for a "sleeping" task to "wake-up" again.  The OS kernel
is
> > > entered every time that HWI_14 interrupt (clocked by Timer 0/1) fires.
> > The
> > > system tick is the heartbeat of the OS and that's why that box is
greyed
> > > out.  If you disabled that interrupt then the RTOS couldn't run!
> > >
> > > To answer your question about having a function called directly, yes
> this
> > > can be done.  For example, let's say your clock manager is using Timer
> 0.
> > > You could write code to configure Timer 1 to generate a periodic
> > interrupt.
> > > Is this a 6000 DSP?  If so you can re-map the interrupts to whatever
you
> > > want.  That being the case you can select HWI_4 and choose the Timer 1
> > > Interrupt as your source and put the name of your function to run in
the
> > > function box.  Sure, this cuts out a little bit of abstraction so that
> > your
> > > function can run faster, but now your using up another timer.  If
you're
> > > periodic function is a multiple of your system tick then it is best to
> use
> > > the "periodic function manager" to run the function.  That way you can
> run
> > > multiple functions and they are all based off the system tick.
> > >
> > > Brad
> > >
> > >
> > > "Peter Choi" <choi@mecca.ca> wrote in message
> > > news:4V9Oc.135865$ek5.2387@pd7tw2no...
> > > > Hello,
> > > >
> > > > So how and is it possible to have HWI_14 to call the "processing"
> > function
> > > > in the C code directly?  When I right click and select properties on
> > this
> > > > HWI_14.  The function field for "CLK_F_isr" is greyed out preventing
> me
> > > from
> > > > typing in the C function.  Also, how come it shows "CLK - Clock
> Manager"
> > > as
> > > > one of its dependencies?  I thought "CLK - Clock Manager" depends on
> > this
> > > > HWI_14 to call the "CLK_F_isr" function, which then somehow calls
this
> > > > "CLK - Clock Manager".
> > > >
> > > >
> > > > "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
> > > > news:10gi8e74nppfg4a@corp.supernews.com...
> > > >
> > > > > They're probably just trying to demonstrate the features of the OS
.
> > > > >
> > > > > When you use an RTOS you pay an up-front cost in man-hours and
> > processor
> > > > > resources.  What you get back is an ease of managing a large
> > > > > application, because it is much easier to make the various parts
of
> > your
> > > > > application run virtually independent of each other.
> > > > >
> > > > > So of course if all you're doing is adjusting a volume then using
an
> > > > > RTOS and the example code is stupid.  When you have an application
> > > > > that's doing ten different things at ten different speeds,
however,
> > this
> > > > > sort of thing starts making sense as the least complicated way of
> > > > > keeping all those individually simple things from stepping on each
> > > other.
> > > > >
> > > > > You should never forget the existence of the task loop when you're
> > > > > looking at your RTOS, however.  If you have a dead-simple
> application
> > > > > that would only break down into a few tasks you should consider
> using
> > a
> > > > > task loop and leave the RTOS sitting in its nice shrink wrap.
> > > > >
> > > > > -- 
> > > > >
> > > > > Tim Wescott
> > > > > Wescott Design Services
> > > > > http://www.wescottdesign.com
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Brad Griffis wrote:

> As I said before the CLK_F_isr is the "heartbeat" of the OS.  If you disable
> it then you no longer have an OS!  That function is intentionally placed as
> HWI_14 since that is the lowest priority hardware interrupt.  I believe you
> can disable that CLK_F_isr by unchecking the "use clock manager" box (or
> something similar) under the Clock Manager properties.  If you do this
> though you will need to manually increment the "system time" at a consistent
> interval within your code for things to work right.  I can't really imagine
> anyone ever wanting to do this though.

   ...

Your patient teaching points out that you need to understand a tool to
use it well. Ive seen OSs used where they were overkill more often than
I've seen them used where approprriate. (That may be a sampling strongly
biased by where I've been asked to look.) An OS doen nothing that
programmer can't do for himself. If it's a good OS, it distils the
tricks and avoids the traps that comprises a thoughtful programmer's
experience. Nobody should use a store-bought OS until he's written and
used some of the functions it provides for itself. Only then is he in a
position to judge its worth, understand what it does, and appreciate its
clevernesses.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

As I said before the CLK_F_isr is the "heartbeat" of the OS.  If you disable
it then you no longer have an OS!  That function is intentionally placed as
HWI_14 since that is the lowest priority hardware interrupt.  I believe you
can disable that CLK_F_isr by unchecking the "use clock manager" box (or
something similar) under the Clock Manager properties.  If you do this
though you will need to manually increment the "system time" at a consistent
interval within your code for things to work right.  I can't really imagine
anyone ever wanting to do this though.

Concerning the programming of interrupts...  There is an interrupt table
that will reside in memory that contains a branch to your ISR.  I believe
each interrupt gets something like 8 spaces in this table.  If your ISR can
fit in 8 instructions then it would be placed directly in the table.
Typically though the table simply branches to your ISR.  In a non-BIOS
project you would need to set that up. However, DSP/BIOS takes care of that
for you.  All you need to do is type the name of your function in the
function name box.  Another thing to note is that you need to do context
save/restore for your hardware interrupts.  This can done EITHER by checking
the "Use Dispatcher" box OR by putting the interrupt keyword in your
function declaration BUT NOT BOTH.  Your system will crash if you try to do
both of those.  I typically just click the "Use Dispatcher" box and then
write a straight C function.

Concerning your last question I  am not sure what you mean by a HWI of level
0.  Isn't that the Reset HWI?  In general though a HWI is always higher
priority than a SWI.  If you are in the middle of executing a SWI when a HWI
comes in the SWI will always be pre-empted such that the HWI runs to
completion and then you resume the SWI (provided that it is the highest
priority function that has not yet run).  Is that what you want to happen?
If that's not how you want things to run then you can always have your HWI
immediately post a SWI and do all your processing in the SWI.

Brad

"Peter Choi" <choi@mecca.ca> wrote in message
news:W3tOc.140028$od7.138452@pd7tw3no...
> Hello,
>
> That is a very good description Brad.  And yes it is a 6000.  I'm using
CCS
> v2.1 on a C6711 DSK.
> So I'd assume the "CLK - Clock Manager" under Scheduling is the part of
the
> RTOS that actually controls the different threads.  I haven't read about
how
> it does that yet but I'm sure I'll very soon.
>
> Now is there a place where I can find out what this "CLK_F_isr" does and
> where it is?  It just seemed odd to me that all the other HWI can be
> configured for what function it calls except this and the HWI_Reset and
the
> HWI_Reserved0, HWI_Reserved1.  Though the other 3 have meaningful names
that
> gives why it can't be re-configured.  HWI_14 is just.... well, HWI_14.
>
> Now I have never programmed interrupts before.  Is there a specific
location
> where these ISR must reside on the memory?  I'd imagine all they are are
> just whatever C function that I'd like to call in one of my source code.
> How does CCS knows which source files it is in?
>
> And one more final question.  I read that all HWI has priority than all
SWI.
> Now in case I have a HWI of level 0 that calls a function, and there's a
> conditional statement in this function that may cause another interrupt.
> But being in code, it can only trigger a SWI.  And because it is called
from
> a HWI of level 0, I want it to precede every other HWI or SWI interrupts.
> But what if while within this SWI, another HWI goes off?  It doesn't
matter
> that this other HWI is at a lower priority, does it?
>
>
> "Brad Griffis" <bradgriffis@hotmail.com> wrote in message
> news:dUgOc.1166$Z56.50@newssvr33.news.prodigy.com...
> > HWI_14 is the time-base for the RTOS.  As you mentioned, in the Clock
> > Manager you can select which timer to use as well as how many
microseconds
> > per system tick.
> >
> > Consider that the main function of the RTOS is to allow for many threads
> to
> > run at once with configurable prioritization as well as extensive
> > capabilities for synchronization and communication between threads.  For
> > example, a thread might do a few things and then "sleep" for a bit.
While
> > it is "sleeping" other threads will be running and other stuff will be
> going
> > on.  In order for this whole prioritization scheme to work, there must
be
> an
> > OS kernel that is in charge of everything.  That's where they system
tick
> > that I mentioned at the beginning of this post comes into play comes
into
> > play.  The OS needs to periodically take control of things and check to
> see
> > if it's time for a "sleeping" task to "wake-up" again.  The OS kernel is
> > entered every time that HWI_14 interrupt (clocked by Timer 0/1) fires.
> The
> > system tick is the heartbeat of the OS and that's why that box is greyed
> > out.  If you disabled that interrupt then the RTOS couldn't run!
> >
> > To answer your question about having a function called directly, yes
this
> > can be done.  For example, let's say your clock manager is using Timer
0.
> > You could write code to configure Timer 1 to generate a periodic
> interrupt.
> > Is this a 6000 DSP?  If so you can re-map the interrupts to whatever you
> > want.  That being the case you can select HWI_4 and choose the Timer 1
> > Interrupt as your source and put the name of your function to run in the
> > function box.  Sure, this cuts out a little bit of abstraction so that
> your
> > function can run faster, but now your using up another timer.  If you're
> > periodic function is a multiple of your system tick then it is best to
use
> > the "periodic function manager" to run the function.  That way you can
run
> > multiple functions and they are all based off the system tick.
> >
> > Brad
> >
> >
> > "Peter Choi" <choi@mecca.ca> wrote in message
> > news:4V9Oc.135865$ek5.2387@pd7tw2no...
> > > Hello,
> > >
> > > So how and is it possible to have HWI_14 to call the "processing"
> function
> > > in the C code directly?  When I right click and select properties on
> this
> > > HWI_14.  The function field for "CLK_F_isr" is greyed out preventing
me
> > from
> > > typing in the C function.  Also, how come it shows "CLK - Clock
Manager"
> > as
> > > one of its dependencies?  I thought "CLK - Clock Manager" depends on
> this
> > > HWI_14 to call the "CLK_F_isr" function, which then somehow calls this
> > > "CLK - Clock Manager".
> > >
> > >
> > > "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
> > > news:10gi8e74nppfg4a@corp.supernews.com...
> > >
> > > > They're probably just trying to demonstrate the features of the OS.
> > > >
> > > > When you use an RTOS you pay an up-front cost in man-hours and
> processor
> > > > resources.  What you get back is an ease of managing a large
> > > > application, because it is much easier to make the various parts of
> your
> > > > application run virtually independent of each other.
> > > >
> > > > So of course if all you're doing is adjusting a volume then using an
> > > > RTOS and the example code is stupid.  When you have an application
> > > > that's doing ten different things at ten different speeds, however,
> this
> > > > sort of thing starts making sense as the least complicated way of
> > > > keeping all those individually simple things from stepping on each
> > other.
> > > >
> > > > You should never forget the existence of the task loop when you're
> > > > looking at your RTOS, however.  If you have a dead-simple
application
> > > > that would only break down into a few tasks you should consider
using
> a
> > > > task loop and leave the RTOS sitting in its nice shrink wrap.
> > > >
> > > > -- 
> > > >
> > > > Tim Wescott
> > > > Wescott Design Services
> > > > http://www.wescottdesign.com
> > >
> > >
> >
> >
>
>

Hello,

That is a very good description Brad.  And yes it is a 6000.  I'm using CCS
v2.1 on a C6711 DSK.
So I'd assume the "CLK - Clock Manager" under Scheduling is the part of the
RTOS that actually controls the different threads.  I haven't read about how
it does that yet but I'm sure I'll very soon.

Now is there a place where I can find out what this "CLK_F_isr" does and
where it is?  It just seemed odd to me that all the other HWI can be
configured for what function it calls except this and the HWI_Reset and the
HWI_Reserved0, HWI_Reserved1.  Though the other 3 have meaningful names that
gives why it can't be re-configured.  HWI_14 is just.... well, HWI_14.

Now I have never programmed interrupts before.  Is there a specific location
where these ISR must reside on the memory?  I'd imagine all they are are
just whatever C function that I'd like to call in one of my source code.
How does CCS knows which source files it is in?

And one more final question.  I read that all HWI has priority than all SWI.
Now in case I have a HWI of level 0 that calls a function, and there's a
conditional statement in this function that may cause another interrupt.
But being in code, it can only trigger a SWI.  And because it is called from
a HWI of level 0, I want it to precede every other HWI or SWI interrupts.
But what if while within this SWI, another HWI goes off?  It doesn't matter
that this other HWI is at a lower priority, does it?


"Brad Griffis" <bradgriffis@hotmail.com> wrote in message
news:dUgOc.1166$Z56.50@newssvr33.news.prodigy.com...
> HWI_14 is the time-base for the RTOS.  As you mentioned, in the Clock
> Manager you can select which timer to use as well as how many microseconds
> per system tick.
>
> Consider that the main function of the RTOS is to allow for many threads
to
> run at once with configurable prioritization as well as extensive
> capabilities for synchronization and communication between threads.  For
> example, a thread might do a few things and then "sleep" for a bit.  While
> it is "sleeping" other threads will be running and other stuff will be
going
> on.  In order for this whole prioritization scheme to work, there must be
an
> OS kernel that is in charge of everything.  That's where they system tick
> that I mentioned at the beginning of this post comes into play comes into
> play.  The OS needs to periodically take control of things and check to
see
> if it's time for a "sleeping" task to "wake-up" again.  The OS kernel is
> entered every time that HWI_14 interrupt (clocked by Timer 0/1) fires.
The
> system tick is the heartbeat of the OS and that's why that box is greyed
> out.  If you disabled that interrupt then the RTOS couldn't run!
>
> To answer your question about having a function called directly, yes this
> can be done.  For example, let's say your clock manager is using Timer 0.
> You could write code to configure Timer 1 to generate a periodic
interrupt.
> Is this a 6000 DSP?  If so you can re-map the interrupts to whatever you
> want.  That being the case you can select HWI_4 and choose the Timer 1
> Interrupt as your source and put the name of your function to run in the
> function box.  Sure, this cuts out a little bit of abstraction so that
your
> function can run faster, but now your using up another timer.  If you're
> periodic function is a multiple of your system tick then it is best to use
> the "periodic function manager" to run the function.  That way you can run
> multiple functions and they are all based off the system tick.
>
> Brad
>
>
> "Peter Choi" <choi@mecca.ca> wrote in message
> news:4V9Oc.135865$ek5.2387@pd7tw2no...
> > Hello,
> >
> > So how and is it possible to have HWI_14 to call the "processing"
function
> > in the C code directly?  When I right click and select properties on
this
> > HWI_14.  The function field for "CLK_F_isr" is greyed out preventing me
> from
> > typing in the C function.  Also, how come it shows "CLK - Clock Manager"
> as
> > one of its dependencies?  I thought "CLK - Clock Manager" depends on
this
> > HWI_14 to call the "CLK_F_isr" function, which then somehow calls this
> > "CLK - Clock Manager".
> >
> >
> > "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
> > news:10gi8e74nppfg4a@corp.supernews.com...
> >
> > > They're probably just trying to demonstrate the features of the OS.
> > >
> > > When you use an RTOS you pay an up-front cost in man-hours and
processor
> > > resources.  What you get back is an ease of managing a large
> > > application, because it is much easier to make the various parts of
your
> > > application run virtually independent of each other.
> > >
> > > So of course if all you're doing is adjusting a volume then using an
> > > RTOS and the example code is stupid.  When you have an application
> > > that's doing ten different things at ten different speeds, however,
this
> > > sort of thing starts making sense as the least complicated way of
> > > keeping all those individually simple things from stepping on each
> other.
> > >
> > > You should never forget the existence of the task loop when you're
> > > looking at your RTOS, however.  If you have a dead-simple application
> > > that would only break down into a few tasks you should consider using
a
> > > task loop and leave the RTOS sitting in its nice shrink wrap.
> > >
> > > -- 
> > >
> > > Tim Wescott
> > > Wescott Design Services
> > > http://www.wescottdesign.com
> >
> >
>
>

HWI_14 is the time-base for the RTOS.  As you mentioned, in the Clock
Manager you can select which timer to use as well as how many microseconds
per system tick.

Consider that the main function of the RTOS is to allow for many threads to
run at once with configurable prioritization as well as extensive
capabilities for synchronization and communication between threads.  For
example, a thread might do a few things and then "sleep" for a bit.  While
it is "sleeping" other threads will be running and other stuff will be going
on.  In order for this whole prioritization scheme to work, there must be an
OS kernel that is in charge of everything.  That's where they system tick
that I mentioned at the beginning of this post comes into play comes into
play.  The OS needs to periodically take control of things and check to see
if it's time for a "sleeping" task to "wake-up" again.  The OS kernel is
entered every time that HWI_14 interrupt (clocked by Timer 0/1) fires.  The
system tick is the heartbeat of the OS and that's why that box is greyed
out.  If you disabled that interrupt then the RTOS couldn't run!

To answer your question about having a function called directly, yes this
can be done.  For example, let's say your clock manager is using Timer 0.
You could write code to configure Timer 1 to generate a periodic interrupt.
Is this a 6000 DSP?  If so you can re-map the interrupts to whatever you
want.  That being the case you can select HWI_4 and choose the Timer 1
Interrupt as your source and put the name of your function to run in the
function box.  Sure, this cuts out a little bit of abstraction so that your
function can run faster, but now your using up another timer.  If you're
periodic function is a multiple of your system tick then it is best to use
the "periodic function manager" to run the function.  That way you can run
multiple functions and they are all based off the system tick.

Brad


"Peter Choi" <choi@mecca.ca> wrote in message
news:4V9Oc.135865$ek5.2387@pd7tw2no...
> Hello,
>
> So how and is it possible to have HWI_14 to call the "processing" function
> in the C code directly?  When I right click and select properties on this
> HWI_14.  The function field for "CLK_F_isr" is greyed out preventing me
from
> typing in the C function.  Also, how come it shows "CLK - Clock Manager"
as
> one of its dependencies?  I thought "CLK - Clock Manager" depends on this
> HWI_14 to call the "CLK_F_isr" function, which then somehow calls this
> "CLK - Clock Manager".
>
>
> "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
> news:10gi8e74nppfg4a@corp.supernews.com...
>
> > They're probably just trying to demonstrate the features of the OS.
> >
> > When you use an RTOS you pay an up-front cost in man-hours and processor
> > resources.  What you get back is an ease of managing a large
> > application, because it is much easier to make the various parts of your
> > application run virtually independent of each other.
> >
> > So of course if all you're doing is adjusting a volume then using an
> > RTOS and the example code is stupid.  When you have an application
> > that's doing ten different things at ten different speeds, however, this
> > sort of thing starts making sense as the least complicated way of
> > keeping all those individually simple things from stepping on each
other.
> >
> > You should never forget the existence of the task loop when you're
> > looking at your RTOS, however.  If you have a dead-simple application
> > that would only break down into a few tasks you should consider using a
> > task loop and leave the RTOS sitting in its nice shrink wrap.
> >
> > -- 
> >
> > Tim Wescott
> > Wescott Design Services
> > http://www.wescottdesign.com
>
>

Since you didn't even tell us what processor you're using, much less 
who's RTOS (although I assume it's TI and TI) I just answered your 
questions from the text and didn't bother looking at the code.

I suspect that TI assumes that if you have to use their configuration 
expert to do your work then you shouldn't be messing with that part of 
the code.

Hopefully some Code Composter expert will answer this for you.

Peter Choi wrote:

> Hello,
> 
> So how and is it possible to have HWI_14 to call the "processing" function
> in the C code directly?  When I right click and select properties on this
> HWI_14.  The function field for "CLK_F_isr" is greyed out preventing me from
> typing in the C function.  Also, how come it shows "CLK - Clock Manager" as
> one of its dependencies?  I thought "CLK - Clock Manager" depends on this
> HWI_14 to call the "CLK_F_isr" function, which then somehow calls this
> "CLK - Clock Manager".
> 
> 
> "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
> news:10gi8e74nppfg4a@corp.supernews.com...
> 
> 
>>They're probably just trying to demonstrate the features of the OS.
>>
>>When you use an RTOS you pay an up-front cost in man-hours and processor
>>resources.  What you get back is an ease of managing a large
>>application, because it is much easier to make the various parts of your
>>application run virtually independent of each other.
>>
>>So of course if all you're doing is adjusting a volume then using an
>>RTOS and the example code is stupid.  When you have an application
>>that's doing ten different things at ten different speeds, however, this
>>sort of thing starts making sense as the least complicated way of
>>keeping all those individually simple things from stepping on each other.
>>
>>You should never forget the existence of the task loop when you're
>>looking at your RTOS, however.  If you have a dead-simple application
>>that would only break down into a few tasks you should consider using a
>>task loop and leave the RTOS sitting in its nice shrink wrap.
>>
>>-- 
>>
>>Tim Wescott
>>Wescott Design Services
>>http://www.wescottdesign.com
> 

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Hello,

So how and is it possible to have HWI_14 to call the "processing" function
in the C code directly?  When I right click and select properties on this
HWI_14.  The function field for "CLK_F_isr" is greyed out preventing me from
typing in the C function.  Also, how come it shows "CLK - Clock Manager" as
one of its dependencies?  I thought "CLK - Clock Manager" depends on this
HWI_14 to call the "CLK_F_isr" function, which then somehow calls this
"CLK - Clock Manager".


"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:10gi8e74nppfg4a@corp.supernews.com...

> They're probably just trying to demonstrate the features of the OS.
>
> When you use an RTOS you pay an up-front cost in man-hours and processor
> resources.  What you get back is an ease of managing a large
> application, because it is much easier to make the various parts of your
> application run virtually independent of each other.
>
> So of course if all you're doing is adjusting a volume then using an
> RTOS and the example code is stupid.  When you have an application
> that's doing ten different things at ten different speeds, however, this
> sort of thing starts making sense as the least complicated way of
> keeping all those individually simple things from stepping on each other.
>
> You should never forget the existence of the task loop when you're
> looking at your RTOS, however.  If you have a dead-simple application
> that would only break down into a few tasks you should consider using a
> task loop and leave the RTOS sitting in its nice shrink wrap.
>
> -- 
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

Peter Choi wrote:

> Hello,
> 
> Sorry I'm new to DSP/BIOS and I have a question after reading the online
> Tutorial at "Using DSP/BIOS->Getting Started with DSP/BIOS->Debugging
> Program Behavior".  The example source code is included below.
> 
> Why would we need to have HWI_14 to run a function called CLK_F_isr, which
> in its context (so it says in the tutorial without much explanation) run the
> CLK object, which has a user set object to call the "dataIO" function in the
> C code, which then calls a I guess a special function that decrements a what
> they termed "mailbox" value in a user set object under SWI, which then call
> the "processing" function in the C code to do the actual volume gain on the
> sample bits?
> 
> Why go through all these fuss?  Isn't there a better way to do it?  Can't we
> not just have the HWI_14 to call a function in C to decrement a counter
> value in the C code and when that counter reaches 0, do the volume gain on
> the sample bits?
> 
> If I understand correctly, HWI_14 is triggered by the TIMER, so why would
> there need to be a "CLK - Clock Manager" in the Scheduling module in the
> DSP/BIOS configuration screen to call C functions?  Afterall, the
> "Microseconds/Int" setting is global under the "CLK - Clock Manager".  It is
> not like you can have different CLK modules set with different
> "Microseconds/Int" settings to do tasks at different time.
> 
> I hope I am making sense to you guys here.
> 

They're probably just trying to demonstrate the features of the OS.

When you use an RTOS you pay an up-front cost in man-hours and processor 
resources.  What you get back is an ease of managing a large 
application, because it is much easier to make the various parts of your 
application run virtually independent of each other.

So of course if all you're doing is adjusting a volume then using an 
RTOS and the example code is stupid.  When you have an application 
that's doing ten different things at ten different speeds, however, this 
sort of thing starts making sense as the least complicated way of 
keeping all those individually simple things from stepping on each other.

You should never forget the existence of the task loop when you're 
looking at your RTOS, however.  If you have a dead-simple application 
that would only break down into a few tasks you should consider using a 
task loop and leave the RTOS sitting in its nice shrink wrap.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Hello,

Sorry I'm new to DSP/BIOS and I have a question after reading the online
Tutorial at "Using DSP/BIOS->Getting Started with DSP/BIOS->Debugging
Program Behavior".  The example source code is included below.

Why would we need to have HWI_14 to run a function called CLK_F_isr, which
in its context (so it says in the tutorial without much explanation) run the
CLK object, which has a user set object to call the "dataIO" function in the
C code, which then calls a I guess a special function that decrements a what
they termed "mailbox" value in a user set object under SWI, which then call
the "processing" function in the C code to do the actual volume gain on the
sample bits?

Why go through all these fuss?  Isn't there a better way to do it?  Can't we
not just have the HWI_14 to call a function in C to decrement a counter
value in the C code and when that counter reaches 0, do the volume gain on
the sample bits?

If I understand correctly, HWI_14 is triggered by the TIMER, so why would
there need to be a "CLK - Clock Manager" in the Scheduling module in the
DSP/BIOS configuration screen to call C functions?  Afterall, the
"Microseconds/Int" setting is global under the "CLK - Clock Manager".  It is
not like you can have different CLK modules set with different
"Microseconds/Int" settings to do tasks at different time.

I hope I am making sense to you guys here.

-------------------------------------------------
/***************************************************************************
/
/*
*/
/*     V O L U M E . C
*/
/*
*/
/*     Audio gain processing using CLK ISR as data source, and a software
*/
/*     interrupt for processing routine.
*/
/*
*/
/***************************************************************************
/

#include <std.h>

#include <log.h>
#include <swi.h>

#include "volumecfg.h"

#include "volume.h"

/* Global declarations */
Int inp_buffer[BUFSIZE];       /* processing data buffers */
Int out_buffer[BUFSIZE];

Int gain = MINGAIN;             /* volume control variable */
Uns processingLoad = BASELOAD;  /* processing routine load value */

/* Functions */
extern Void load(Uns loadValue);

Int processing(Int *input, Int *output);
Void dataIO(Void);


/*
 * ======== main ========
 */
Void main()
{
    LOG_printf(&trace,"volume example started\n");

    /* fall into DSP/BIOS idle loop */
    return;
}

/*
 *  ======== processing ========
 *
 * FUNCTION: Called from processing_SWI to apply signal processing
 *           transform to input signal.
 *
 * PARAMETERS: address of input and output buffers.
 *
 * RETURN VALUE: TRUE.
 */
Int processing(Int *input, Int *output)
{
    Int size = BUFSIZE;

    while(size--){
        *output++ = *input++ * gain;
    }

    /* additional processing load */
    load(processingLoad);

    return(TRUE);
}

/*
 *  ======== dataIO ========
 *
 * FUNCTION: Called from timer ISR to fake a periodic hardware interrupt
that
 *           reads in the input signal and outputs the processed signal.
 *
 * PARAMETERS: none.
 *
 * RETURN VALUE: none.
 */
Void dataIO()
{
    /* do data I/O */

    SWI_dec(&processing_SWI);   /* post processing_SWI software interrupt */
}