Reply by Randy Yates May 22, 20102010-05-22
Note that Mariana, from TI, posted some pretty good answers to these
questions on the TI E2E forum:

  http://e2e.ti.com/support/embedded/f/355/t/48974.aspx

--Randy

Randy Yates <yates@ieee.org> writes:

> a. The javascript bios.MEM object (in the .tcf file) has a "global > stack" that can be manipulated with bios.MEM.STACKSIZE and > bios.MEM.STACKSEG. What is the "global stack" used for? > > b. Where does the C compiler stack get initialized prior to main()? > > c. Tasks (and probably other threads) have their own stacks, but > what stack does DSP/BIOS use for it's own execution? For example, > inside a TSK_switch() call, there must be a "system" stack - where > does this stack reside and what sets its size? > > d. From which heap or stack does DSP/BIOS take memory from for > dynamically-created objects, such as semaphores and tasks? > > This is DSP/BIOS 5.33.06 under CCS 3.3 SR 11. > > --Randy
-- Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven. Digital Signal Labs % She love the way Puccini lays down a tune, and mailto://yates@ieee.org % Verdi's always creepin' from her room." http://www.digitalsignallabs.com % "Rockaria", *A New World Record*, ELO
Reply by Tim Wescott May 22, 20102010-05-22
On 05/21/2010 11:13 AM, Randy Yates wrote:
> On May 21, 1:01 pm, Vladimir Vassilevsky<nos...@nowhere.com> wrote: >> The necessity to deal with that kind of nonsense diverted me from using >> any factory supplied frameworks, whether they are based on DSP/BIOS, VDK >> or Linux. First, you search for working example (1 MB of code) all over >> the Internet (if you instal Pearl version 10, then you have to install >> service pack 1.12 with Java 3.20, which makes it incompatible with the >> JTAG debugger ver 5.60, etc. etc.) Then, after you somehow managed to >> put this example into the board, you are frantically looking for a way >> to toggle a LED from this example without ruining everything. >> >> Start with bare metal. > > Yeah, I hear you Vlad. > >>> b. Where does the C compiler stack get initialized prior to main()? >> >> In wide sense, it is initialized in India. > > Yeah, well... > >> In narrow sense, it is initialized in C startup code. Linker file >> defines memory area and symbols for stack initialization. > > Yes, that is true. The problem is that using this ^&*$%(# tool REMOVES > your hand-crafted cmd file from the process and substitutes and auto- > generated, horribly disfigured surrogate based on the gui/tconf > compiler. So now you have to second-guess what the gui expects to get > what you really want. I hate working like this!
Why do you think they named it Code Composter?
>>> c. Tasks (and probably other threads) have their own stacks, but >>> what stack does DSP/BIOS use for it's own execution? For example, >>> inside a TSK_switch() call, there must be a "system" stack - where >>> does this stack reside and what sets its size? >> >>> d. From which heap or stack does DSP/BIOS take memory from for >>> dynamically-created objects, such as semaphores and tasks? >> >>> This is DSP/BIOS 5.33.06 under CCS 3.3 SR 11. >> >> The earlier you abandon it, the better you will be. > > I'm about 2 hours away from agreeing with you...
Why waste two more hours of your life? -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by Raymond Toy May 21, 20102010-05-21
On 5/21/10 8:15 PM, Randy Yates wrote:
> Raymond Toy <toy.raymond@gmail.com> writes: > >> On 5/21/10 2:13 PM, Randy Yates wrote: >>> >>> Yes, that is true. The problem is that using this ^&*$%(# tool REMOVES >>> your hand-crafted cmd file from the process and substitutes and auto- >>> generated, horribly disfigured surrogate based on the gui/tconf >>> compiler. So now you have to second-guess what the gui expects to get >>> what you really want. I hate working like this! >> >> Hi Randy! > > Hey Ray! Good to hear from you again. Are you still in NC?
Yep.
> >> You can (maybe?) ditch the gui. > > Well that's exactly what I'm trying to do - ditch the gui and just use > the tconf compiler on my own .tcf file. Problem is, there are a > gazillion objects and bazillion options for each object, and how all > those options and objects interact isn't documented and isn't obvious!!!
As you already figured out, we used the gui to generate the initial configuration and used that to create the tcf files. There was some documentation for tconf. It had a lot of information, but some was slightly wrong, and some options were missing. Perhaps it's better now? Anyway, I think I ended up reverse-engineering some of the options we needed. This was sometimes done by guessing (because the tconf manual did not match the bios manual), and sometimes done by using the gui to set the desired option and creating a new tcf file. Last resort was just guessing at the name, based on what the dsp/bios manual said. Needless to say, tconf was not very well supported at the time. :-( I hope it's better now.
> > PS: I'm using an evolved version of your build system, the one with > sed. > >> We did that for our project, and just used tconf (the command-line >> thingie) to configure our system. Learned a some javascript too, and >> it allowed use to do simple things like make sure we allocated enough >> space for everything. Couldn't do that with the gui. > > Well if you could tell me the magic letters to type, I would be > happy to enter them in my text editor! > >> Ditching the gui solved a lot of issues with repeatability and source >> code control. > > Yeah, but again, how the javascript objects and options are supposed > to work is far from obvious/well-documented. > >>>>> c. Tasks (and probably other threads) have their own stacks, but >>>>> what stack does DSP/BIOS use for it's own execution? For example, >>>>> inside a TSK_switch() call, there must be a "system" stack - where >>>>> does this stack reside and what sets its size?
I can't help with the exact name, but the system stack size was settable somehow. Our project used just one stack, shared by all the SWIs that we used. The DSP/BIOS manual was reasonable helpful in this, unlike the tconf manual. Ray
Reply by Randy Yates May 21, 20102010-05-21
Raymond Toy <toy.raymond@gmail.com> writes:
> [...]
PS: I got it to work - by creating a project from scratch with the gui and comparing the tcf files. But I'd still like to hear the answers to my questions. Here's a working tcf: /* * Note the following used to specified inside a custom Platform.tci * file and loaded with a utils.loadPlatform("monitor") command, but * has been moved here for better source control. */ /**** Begin custom monitor platform definitions ****/ var mem_ext = []; var device_regs = { /* The property l2Mode specifies the L2 cache setting. The valid values are: * "4-way cache (0k)", "4-way cache (32k)", "4-way cache (64k)", * "4-way cache (128k)", "4-way cache (256k)" */ l2Mode: "4-way cache (0k)" }; var params = { clockRate: 500, catalogName: "ti.catalog.c6000", deviceName: "6418", regs: device_regs, mem: mem_ext }; utils.loadPlatform("ti.platforms.generic", params); /**** End custom monitor platform definitions ****/ /* The following DSP/BIOS Features are enabled. */ bios.enableRealTimeAnalysis(prog); bios.enableRtdx(prog); bios.enableTskManager(prog); bios.TSK.create("tskRedLED"); bios.TSK.instance("tskRedLED").order = 1; bios.TSK.instance("tskRedLED").comment = "Red LED Task"; bios.TSK.instance("tskRedLED").fxn = prog.extern("TSK_RedLED"); prog.gen(); -- Randy Yates % "So now it's getting late, Digital Signal Labs % and those who hesitate mailto://yates@ieee.org % got no one..." http://www.digitalsignallabs.com % 'Waterfall', *Face The Music*, ELO
Reply by Randy Yates May 21, 20102010-05-21
Raymond Toy <toy.raymond@gmail.com> writes:

> On 5/21/10 2:13 PM, Randy Yates wrote: >> >> Yes, that is true. The problem is that using this ^&*$%(# tool REMOVES >> your hand-crafted cmd file from the process and substitutes and auto- >> generated, horribly disfigured surrogate based on the gui/tconf >> compiler. So now you have to second-guess what the gui expects to get >> what you really want. I hate working like this! > > Hi Randy!
Hey Ray! Good to hear from you again. Are you still in NC?
> You can (maybe?) ditch the gui.
Well that's exactly what I'm trying to do - ditch the gui and just use the tconf compiler on my own .tcf file. Problem is, there are a gazillion objects and bazillion options for each object, and how all those options and objects interact isn't documented and isn't obvious!!! PS: I'm using an evolved version of your build system, the one with sed.
> We did that for our project, and just used tconf (the command-line > thingie) to configure our system. Learned a some javascript too, and > it allowed use to do simple things like make sure we allocated enough > space for everything. Couldn't do that with the gui.
Well if you could tell me the magic letters to type, I would be happy to enter them in my text editor!
> Ditching the gui solved a lot of issues with repeatability and source > code control.
Yeah, but again, how the javascript objects and options are supposed to work is far from obvious/well-documented.
>>>> c. Tasks (and probably other threads) have their own stacks, but >>>> what stack does DSP/BIOS use for it's own execution? For example, >>>> inside a TSK_switch() call, there must be a "system" stack - where >>>> does this stack reside and what sets its size? >>> >>>> d. From which heap or stack does DSP/BIOS take memory from for >>>> dynamically-created objects, such as semaphores and tasks? >>> >>>> This is DSP/BIOS 5.33.06 under CCS 3.3 SR 11. >>> >>> The earlier you abandon it, the better you will be. >> >> I'm about 2 hours away from agreeing with you... > > On the other hand, people have successfully used dsp/bios. We did on > our project. 50 million or so phones shipped and not a single bug > report about the DSP code. (Which is not the same as no bugs.)
Congratulations! That's great. Again, good to hear from you Ray! -- Randy Yates % "Remember the good old 1980's, when Digital Signal Labs % things were so uncomplicated?" mailto://yates@ieee.org % 'Ticket To The Moon' http://www.digitalsignallabs.com % *Time*, Electric Light Orchestra
Reply by Raymond Toy May 21, 20102010-05-21
On 5/21/10 2:13 PM, Randy Yates wrote:
> > Yes, that is true. The problem is that using this ^&*$%(# tool REMOVES > your hand-crafted cmd file from the process and substitutes and auto- > generated, horribly disfigured surrogate based on the gui/tconf > compiler. So now you have to second-guess what the gui expects to get > what you really want. I hate working like this!
Hi Randy! You can (maybe?) ditch the gui. We did that for our project, and just used tconf (the command-line thingie) to configure our system. Learned a some javascript too, and it allowed use to do simple things like make sure we allocated enough space for everything. Couldn't do that with the gui. Ditching the gui solved a lot of issues with repeatability and source code control.
> >>> c. Tasks (and probably other threads) have their own stacks, but >>> what stack does DSP/BIOS use for it's own execution? For example, >>> inside a TSK_switch() call, there must be a "system" stack - where >>> does this stack reside and what sets its size? >> >>> d. From which heap or stack does DSP/BIOS take memory from for >>> dynamically-created objects, such as semaphores and tasks? >> >>> This is DSP/BIOS 5.33.06 under CCS 3.3 SR 11. >> >> The earlier you abandon it, the better you will be. > > I'm about 2 hours away from agreeing with you...
On the other hand, people have successfully used dsp/bios. We did on our project. 50 million or so phones shipped and not a single bug report about the DSP code. (Which is not the same as no bugs.) Unfortunately, I can't remember all the details about dsp/bios, so I can't help with your questions; it was too long ago now, and once we set it up, we didn't touch it. Ray
Reply by Randy Yates May 21, 20102010-05-21
On May 21, 1:01&#4294967295;pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> The necessity to deal with that kind of nonsense diverted me from using > any factory supplied frameworks, whether they are based on DSP/BIOS, VDK > or Linux. First, you search for working example (1 MB of code) all over > the Internet (if you instal Pearl version 10, then you have to install > service pack 1.12 with Java 3.20, which makes it incompatible with the > JTAG debugger ver 5.60, etc. etc.) Then, after you somehow managed to > put this example into the board, you are frantically looking for a way > to toggle a LED from this example without ruining everything. > > Start with bare metal.
Yeah, I hear you Vlad.
> > &#4294967295; b. Where does the C compiler stack get initialized prior to main()? > > In wide sense, it is initialized in India.
Yeah, well...
> In narrow sense, it is initialized in C startup code. Linker file > defines memory area and symbols for stack initialization.
Yes, that is true. The problem is that using this ^&*$%(# tool REMOVES your hand-crafted cmd file from the process and substitutes and auto- generated, horribly disfigured surrogate based on the gui/tconf compiler. So now you have to second-guess what the gui expects to get what you really want. I hate working like this!
> > &#4294967295; c. Tasks (and probably other threads) have their own stacks, but > > &#4294967295; what stack does DSP/BIOS use for it's own execution? For example, > > &#4294967295; inside a TSK_switch() call, there must be a "system" stack - where > > &#4294967295; does this stack reside and what sets its size? > > > &#4294967295; d. From which heap or stack does DSP/BIOS take memory from for > > &#4294967295; dynamically-created objects, such as semaphores and tasks? > > > This is DSP/BIOS 5.33.06 under CCS 3.3 SR 11. > > The earlier you abandon it, the better you will be.
I'm about 2 hours away from agreeing with you...
Reply by Vladimir Vassilevsky May 21, 20102010-05-21
Roll your own multitasker and drivers.


Randy Yates wrote:

> a. The javascript bios.MEM object (in the .tcf file) has a "global > stack" that can be manipulated with bios.MEM.STACKSIZE and > bios.MEM.STACKSEG. What is the "global stack" used for?
The necessity to deal with that kind of nonsense diverted me from using any factory supplied frameworks, whether they are based on DSP/BIOS, VDK or Linux. First, you search for working example (1 MB of code) all over the Internet (if you instal Pearl version 10, then you have to install service pack 1.12 with Java 3.20, which makes it incompatible with the JTAG debugger ver 5.60, etc. etc.) Then, after you somehow managed to put this example into the board, you are frantically looking for a way to toggle a LED from this example without ruining everything. Start with bare metal.
> > b. Where does the C compiler stack get initialized prior to main()?
In wide sense, it is initialized in India. In narrow sense, it is initialized in C startup code. Linker file defines memory area and symbols for stack initialization.
> c. Tasks (and probably other threads) have their own stacks, but > what stack does DSP/BIOS use for it's own execution? For example, > inside a TSK_switch() call, there must be a "system" stack - where > does this stack reside and what sets its size? > > d. From which heap or stack does DSP/BIOS take memory from for > dynamically-created objects, such as semaphores and tasks? > > This is DSP/BIOS 5.33.06 under CCS 3.3 SR 11.
The earlier you abandon it, the better you will be. VLV
Reply by Tim Wescott May 21, 20102010-05-21
Randy Yates wrote:
> a. The javascript bios.MEM object (in the .tcf file) has a "global > stack" that can be manipulated with bios.MEM.STACKSIZE and > bios.MEM.STACKSEG. What is the "global stack" used for? > > b. Where does the C compiler stack get initialized prior to main()? > > c. Tasks (and probably other threads) have their own stacks, but > what stack does DSP/BIOS use for it's own execution? For example, > inside a TSK_switch() call, there must be a "system" stack - where > does this stack reside and what sets its size? > > d. From which heap or stack does DSP/BIOS take memory from for > dynamically-created objects, such as semaphores and tasks? > > This is DSP/BIOS 5.33.06 under CCS 3.3 SR 11.
"This is Texas Instruments' DSP/BIOS etc., etc., for the TMS320-" what? And I'll give the same advice to this that I always do when folks start straying out of algorithms and into techniques for making code work on embedded hardware -- even though it's a digital signal _processor_, even if your _algorithm_ may be DSP, the _problem_ is more of an embedded programming one than a DSP algorithm one, so you could probably benefit a _lot_ from cross-posting this to comp.arch.embedded. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by Randy Yates May 21, 20102010-05-21
On May 21, 12:04&#4294967295;pm, Randy Yates <ya...@ieee.org> wrote:
> &#4294967295; d. From which heap or stack does DSP/BIOS take memory from for > &#4294967295; dynamically-created objects, such as semaphores and tasks?
Nix this - I already knew the answer: bios.MEM.BIOSOBJSEG = prog.get("myMEM"); --Randy