From: Randy Yates on 21 May 2010 12:04 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 21 May 2010 12:25 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 21 May 2010 12:39 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 21 May 2010 13:01 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 21 May 2010 14:13 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...
|
Next
|
Last
Pages: 1 2 3 Prev: Notch comb filter coefficients Next: Bode's Amplitude/Phase relation for discrete time systems |