Prev: Notch comb filter coefficients
Next: Bode's Amplitude/Phase relation for discrete time systems
From: Raymond Toy on 21 May 2010 20:07
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
From: Randy Yates on 21 May 2010 20:15
Raymond Toy <toy.raymond(a)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(a)ieee.org % 'Ticket To The Moon'
http://www.digitalsignallabs.com % *Time*, Electric Light Orchestra
From: Randy Yates on 21 May 2010 20:19
Raymond Toy <toy.raymond(a)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(a)ieee.org % got no one..."
http://www.digitalsignallabs.com % 'Waterfall', *Face The Music*, ELO
From: Raymond Toy on 21 May 2010 21:15
On 5/21/10 8:15 PM, Randy Yates wrote:
> Raymond Toy <toy.raymond(a)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
From: Tim Wescott on 22 May 2010 00:47
On 05/21/2010 11:13 AM, Randy Yates wrote:
> On May 21, 1:01 pm, Vladimir Vassilevsky<nos...(a)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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Notch comb filter coefficients
Next: Bode's Amplitude/Phase relation for discrete time systems