From: Randy Yates on
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
From: Randy Yates on
On May 21, 12:04 pm, Randy Yates <ya...(a)ieee.org> wrote:
>   d. From which heap or stack does DSP/BIOS take memory from for
>   dynamically-created objects, such as semaphores and tasks?

Nix this - I already knew the answer: bios.MEM.BIOSOBJSEG =
prog.get("myMEM");

--Randy

From: Tim Wescott on
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
From: Vladimir Vassilevsky on

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


From: Randy Yates on
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!

> >   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...