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 */ }
DSP/BIOS question
Started by ●July 29, 2004
Reply by ●July 29, 20042004-07-29
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
Reply by ●July 29, 20042004-07-29
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
Reply by ●July 29, 20042004-07-29
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
Reply by ●July 29, 20042004-07-29
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 mefrom> 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 eachother.> > > > 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 > >
Reply by ●July 30, 20042004-07-30
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 threadsto> 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 begoing> on. In order for this whole prioritization scheme to work, there must bean> 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 tosee> 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 periodicinterrupt.> 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 thatyour> 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 onthis> > 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 onthis> > 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 andprocessor> > > resources. What you get back is an ease of managing a large > > > application, because it is much easier to make the various parts ofyour> > > 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 usinga> > > task loop and leave the RTOS sitting in its nice shrink wrap. > > > > > > -- > > > > > > Tim Wescott > > > Wescott Design Services > > > http://www.wescottdesign.com > > > > > >
Reply by ●July 31, 20042004-07-31
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 usingCCS> v2.1 on a C6711 DSK. > So I'd assume the "CLK - Clock Manager" under Scheduling is the part ofthe> RTOS that actually controls the different threads. I haven't read abouthow> 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 andthe> HWI_Reserved0, HWI_Reserved1. Though the other 3 have meaningful namesthat> 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 specificlocation> 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 allSWI.> 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 calledfrom> 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'tmatter> 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 manymicroseconds> > 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 mustbe> an > > OS kernel that is in charge of everything. That's where they systemtick> > that I mentioned at the beginning of this post comes into play comesinto> > 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, yesthis> > can be done. For example, let's say your clock manager is using Timer0.> > 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 touse> > the "periodic function manager" to run the function. That way you canrun> > 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 preventingme> > from > > > typing in the C function. Also, how come it shows "CLK - ClockManager"> > 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-simpleapplication> > > > that would only break down into a few tasks you should considerusing> a > > > > task loop and leave the RTOS sitting in its nice shrink wrap. > > > > > > > > -- > > > > > > > > Tim Wescott > > > > Wescott Design Services > > > > http://www.wescottdesign.com > > > > > > > > > > > >
Reply by ●July 31, 20042004-07-31
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. �����������������������������������������������������������������������
Reply by ●August 1, 20042004-08-01
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 youdisable> it then you no longer have an OS! That function is intentionally placedas> HWI_14 since that is the lowest priority hardware interrupt. I believeyou> 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 aconsistent> interval within your code for things to work right. I can't reallyimagine> 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 ISRcan> 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 ofthat> 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 bychecking> the "Use Dispatcher" box OR by putting the interrupt keyword in your > function declaration BUT NOT BOTH. Your system will crash if you try todo> 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 oflevel> 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 aHWI> 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 SWIinterrupts.> > 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 manythreads> > 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 checkto> > see > > > if it's time for a "sleeping" task to "wake-up" again. The OS kernelis> > > 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 isgreyed> > > 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 whateveryou> > > 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 inthe> > > 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. Ifyou'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 callsthis> > > > "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 partsof> > your > > > > > application run virtually independent of each other. > > > > > > > > > > So of course if all you're doing is adjusting a volume then usingan> > > > > 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 > > > > > > > > > > > > > > > > > > > >
Reply by ●August 2, 20042004-08-02
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 canfind> 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 doesit> 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 typeof> 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 mayor> 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 taskbeing> 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. Ibelieve> > 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 tohappen?> > If that's not how you want things to run then you can always have yourHWI> > 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'musing> > CCS > > > v2.1 on a C6711 DSK. > > > So I'd assume the "CLK - Clock Manager" under Scheduling is the partof> > the > > > RTOS that actually controls the different threads. I haven't readabout> > 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" doesand> > > 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_Resetand> > the > > > HWI_Reserved0, HWI_Reserved1. Though the other 3 have meaningfulnames> > 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 areare> > > just whatever C function that I'd like to call in one of my sourcecode.> > > How does CCS knows which source files it is in? > > > > > > And one more final question. I read that all HWI has priority thanall> > SWI. > > > Now in case I have a HWI of level 0 that calls a function, and there'sa> > > conditional statement in this function that may cause anotherinterrupt.> > > But being in code, it can only trigger a SWI. And because it iscalled> > 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 theClock> > > > 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 willbe> > > going > > > > on. In order for this whole prioritization scheme to work, theremust> > 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 OSkernel> 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 usingTimer> > 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 Timer1> > > > 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 sothat> > > 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 bestto> > use > > > > the "periodic function manager" to run the function. That way youcan> > 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 propertieson> > > this > > > > > HWI_14. The function field for "CLK_F_isr" is greyed outpreventing> > 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" dependson> > > 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 theOS> . > > > > > > > > > > > > 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 thenusing> an > > > > > > RTOS and the example code is stupid. When you have anapplication> > > > > > that's doing ten different things at ten different speeds, > however, > > > this > > > > > > sort of thing starts making sense as the least complicated wayof> > > > > > keeping all those individually simple things from stepping oneach> > > > other. > > > > > > > > > > > > You should never forget the existence of the task loop whenyou'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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >