Boot | C31 | TMS320VC33 | VC33

Hi!,

I'm just starting with DSP programming. I've got the DSK board for the
VC33 and after browsing through the web and the documentation I tried
to compile and link the following C file:

pi_calc.c

#include <stdio.h> /* printf() is big and uses lots of heap and stack */
void main(void)
{
float a,b,c;
a = 355.0;
b = 113.0;
c = a/b;
printf("\npi=%4.11f\n",c); /* printf() is big and uses lots of heap
and stack */
printf (" %s %s" ,__TIME__, __DATE__);
}

what I did was to execute the following:

cl30 pi_calc.c -z -l rts30.lib

Then, I got the a.out file which then I tried to load to the DSP via
the DSK3DW.exe (File->load executable...). But I got an error message
saying: Extra operand(s).

Does anybody know what I did wrong? Also, is it very useful/necessary
using the Code Composer for C programming? Sorry if this problem is
something too basic. I'm just a newbie with all that.

Thank you in advance!





(You need to be a member of c3x -- send a blank email to c3x-subscribe@yahoogroups.com )

Hi Dani

Without a linker command file the linker default is to place all code and data beginning at address zero (a mistake);  Try making a map file.  The MAP file output will show where everything is being placed in memory.

If you look in DSK3DW's 'Project build' pull down you will find a dialog box that will help you generate a linker command file.  I created the following linker command file, and then used the BAT build option to create a loadable pi_calc.out file.  This however will only be enough for limited success.

It should be obvious that most DSP target boards (DSK, modem etc...) do not include text display devices.  In the JTAG code composer that job is left to the debugger.  It works by placing a breakpoint inside the print routine and than string printing the data to the 'stdout' device (a chain from the JTAG emulator to the code composer debugger). In the end, the buffer for each print statement is wiped out, but if you go poking around in the DSP memory you may find a remnant.

The approach taken in DSK3DW was to create print routines that would write strings to a DSK_STDOUT section in memory that would be configured for ROW and COL dimensions.  DSK3DW could then display that section using a memory dump, but show the data as characters rather than integer or float.  The advantage would be that *if* you did have a character display device connected to the DSP you could copy this data directly to it.

Another difference will be the 'lean and mean' stdio routines that were written for the DSK.  If you pull apart the stdio routines from RTS30.LIB you will find the resource requirements are rather large.  The DSK needed to be much more frugal with its resources, so a pared down IO library was created.

An explanation is given in the DSK3DW help file (search for sprintf or STDIO).  You will also find the canned ready to go examples HELLO.C/HELLO.OUT and HELLO2.C/HELLO2.OUT to step through.  Digging in, you will also find some 'lean and mean' string print routines for floating point, integer and hex numbers.  However, should you get interested in the normal STDIO routines, those sources are given in the compilers *.SRC files (so you can rebuild the libs if you wanted to).

Hope this helps
Keith Larson
DSP and Analog Consulting
Lincoln, Ma 01773
-------------------------

pi_calc.obj
-cr
-e c_int00
-o pi_calc.out
-m pi_calc.map
-l rts30.lib
-heap 256
-stack 256
MEMORY
{
  RAM0 : org=0x809800, len=0x000002
  RAM1 : org=0x800000, len=0x003fff
  RAM2 : org=0x804000, len=0x003fff
}
SECTIONS
{
     boot_rsrv : {} > RAM0
         .text : {} > RAM1
         .data : {} > RAM1
       .sysmem : {} > RAM1
        .const : {} > RAM1
          .bss : {} > RAM2
        .cinit : {} > RAM2
        .stack : {} > RAM2
}

Dani Fdz wrote:

Hi!,

I'm just starting with DSP programming. I've got the DSK board for the
VC33 and after browsing through the web and the documentation I tried
to compile and link the following C file:

pi_calc.c

#include <stdio.h>        /* printf() is big and uses lots of heap and stack */
void main(void)
{   
  float a,b,c;
  a = 355.0;
  b = 113.0;
  c = a/b;
  printf("\npi=%4.11f\n",c);  /* printf() is big and uses lots of heap
and stack */
  printf (" %s %s" ,__TIME__, __DATE__);
}

what I did was to execute the following:

cl30 pi_calc.c -z -l rts30.lib

Then, I got the a.out file which then I tried to load to the DSP via
the DSK3DW.exe (File->load executable...). But I got an error message
saying: Extra operand(s).

Does anybody know what I did wrong? Also, is it very useful/necessary
using the Code Composer for C programming? Sorry if this problem is
something too basic. I'm just a newbie with all that.

Thank you in advance!

(You need to be a member of c3x -- send a blank email to c3x-subscribe@yahoogroups.com )

Hi Keith,

Thanks for your answer, I got the DSK v2.02 (which doesn't have the
DSK_STDOUT option) instead of 2.04, that's why I didn't find the
Hello.c and Hello2.c examples, but know I'm ready to go :p.

What I want to do whit this DSP is an INS (Inertial Navigation
System), so I will need good functions for matrix operations,
derivatives, integration, etc. Do you know if it is possible to
generate code to the DSP from MATLAB?¿ I know that I can get C code
from any .m MATLAB file, but then can I compile that code with cl30?
If so, will it be efficient enough? What is the 'normal' thing to do
with that kind of operations? only with math.h?

Thank you in advance,

Dani.

On Apr 4, 2005 4:33 PM, Keith Larson <klarsondsp@klar...> wrote:
> Hi Dani
>
> Without a linker command file the linker default is to place all code and
> data beginning at address zero (a mistake); Try making a map file. The MAP
> file output will show where everything is being placed in memory.
>
> If you look in DSK3DW's 'Project build' pull down you will find a dialog box
> that will help you generate a linker command file. I created the following
> linker command file, and then used the BAT build option to create a loadable
> pi_calc.out file. This however will only be enough for limited success.
>
> It should be obvious that most DSP target boards (DSK, modem etc...) do not
> include text display devices. In the JTAG code composer that job is left to
> the debugger. It works by placing a breakpoint inside the print routine and
> than string printing the data to the 'stdout' device (a chain from the JTAG
> emulator to the code composer debugger). In the end, the buffer for each
> print statement is wiped out, but if you go poking around in the DSP memory
> you may find a remnant.
>
> The approach taken in DSK3DW was to create print routines that would write
> strings to a DSK_STDOUT section in memory that would be configured for ROW
> and COL dimensions. DSK3DW could then display that section using a memory
> dump, but show the data as characters rather than integer or float. The
> advantage would be that *if* you did have a character display device
> connected to the DSP you could copy this data directly to it.
>
> Another difference will be the 'lean and mean' stdio routines that were
> written for the DSK. If you pull apart the stdio routines from RTS30.LIB
> you will find the resource requirements are rather large. The DSK needed to
> be much more frugal with its resources, so a pared down IO library was
> created.
>
> An explanation is given in the DSK3DW help file (search for sprintf or
> STDIO). You will also find the canned ready to go examples
> HELLO.C/HELLO.OUT and HELLO2.C/HELLO2.OUT to step through. Digging in, you
> will also find some 'lean and mean' string print routines for floating
> point, integer and hex numbers. However, should you get interested in the
> normal STDIO routines, those sources are given in the compilers *.SRC files
> (so you can rebuild the libs if you wanted to).
>
> Hope this helps
> Keith Larson
> DSP and Analog Consulting
> Lincoln, Ma 01773
> -------------------------
>
> pi_calc.obj
> -cr
> -e c_int00
> -o pi_calc.out
> -m pi_calc.map
> -l rts30.lib
> -heap 256
> -stack 256
> MEMORY
> {
> RAM0 : org=0x809800, len=0x000002
> RAM1 : org=0x800000, len=0x003fff
> RAM2 : org=0x804000, len=0x003fff
> }
> SECTIONS
> {
> boot_rsrv : {} > RAM0
> .text : {} > RAM1
> .data : {} > RAM1
> .sysmem : {} > RAM1
> .const : {} > RAM1
> .bss : {} > RAM2
> .cinit : {} > RAM2
> .stack : {} > RAM2
> } >
>
> Dani Fdz wrote:
>
> Hi!,
>
> I'm just starting with DSP programming. I've got the DSK board for the
> VC33 and after browsing through the web and the documentation I tried
> to compile and link the following C file:
>
> pi_calc.c
>
> #include <stdio.h> /* printf() is big and uses lots of heap and stack
> */
> void main(void)
> {
> float a,b,c;
> a = 355.0;
> b = 113.0;
> c = a/b;
> printf("\npi=%4.11f\n",c); /* printf() is big and uses lots of heap
> and stack */
> printf (" %s %s" ,__TIME__, __DATE__);
> }
>
> what I did was to execute the following:
>
> cl30 pi_calc.c -z -l rts30.lib
>
> Then, I got the a.out file which then I tried to load to the DSP via
> the DSK3DW.exe (File->load executable...). But I got an error message
> saying: Extra operand(s).
>
> Does anybody know what I did wrong? Also, is it very useful/necessary
> using the Code Composer for C programming? Sorry if this problem is
> something too basic. I'm just a newbie with all that.
>
> Thank you in advance!





(You need to be a member of c3x -- send a blank email to c3x-subscribe@yahoogroups.com )

Hi Dani

Figure it this way.

1) How many times per second do you need to process and update
2) How many CPU cycles does this represent
3) How many multiplies and adds per computation loop are in the algorithm

Example:
1) 1000 updates per second (100-1000x a reasonable visual update rate)
2) With a 75 MHz CPU = 75000 cycles per update
3) 16x16 matrix = 256 operations (compiler is 3x slow to ASM?)
   You should be able to do 100 such operations in the given time

This is likely way too much CPU horsepower.  If you drop into LOPOWER, or IDLE allot, the power consumtion will go way down.  Or, have the CPU do more of the overall task.  You did not mention for example if the VC33 would be getting preprocessed data from a GPS receiver.

TI compilers are not known for hand optimized library support (everyone seems to have their own method), and matrix operations are no exception given that they are not part of the ANSI compiler standard set of core operations. If you do need speed, the ASM code for simple matrix operations (+,-) will be quite simple, you dont even need to know row and columns, just the overall size.  Multiplication is slightly tougher in that you need to step and work by columns.  Still not difficult given that the inner loop is nothing more than a MAC.  From experience I can tell you that if you do have a problem, it will likely be with Matrix inversion.  A few months back I wrote my own simple SPICE engine and wrote my own Matrix library including an inversion routine.

Simple integration and differentiation is nothing more than addition or subtraction of each element against the like element in a second array (easy).  But there are also ways to get the derivitive of a matrix relative to another element in the array (stock risk analysis engines do this).  Another tough nut but very unlikely what you need (I have little knowledge here).

Hope this helps
Best regards
Keith Larson
DSP and Analog Consultant
Lincoln, Ma 01773

http://home.comcast.net/~klarsondsp/
Dani Fdz wrote:

Hi Keith,
Thanks for your answer, I got the DSK v2.02 (which doesn't have the
DSK_STDOUT option) instead of 2.04, that's why I didn't find the
Hello.c and Hello2.c examples, but know I'm ready to go :p.
What I want to do whit this DSP is an INS (Inertial Navigation
System), so I will need good functions for matrix operations,
derivatives, integration, etc. Do you know if it is possible to
generate code to the DSP from MATLAB?¿ I know that I can get C code
from any .m MATLAB file, but then can I compile that code with cl30?
If so, will it be efficient enough? What is the 'normal' thing to do
with that kind of operations? only with math.h?
Thank you in advance,
Dani. On Apr 4, 2005 4:33 PM, Keith Larson <k...@comcast.net> wrote:

Hi Dani
Without a linker command file the linker default is to place all code and
data beginning at address zero (a mistake); Try making a map file. The MAP
file output will show where everything is being placed in memory.
If you look in DSK3DW's 'Project build' pull down you will find a dialog box
that will help you generate a linker command file. I created the following
linker command file, and then used the BAT build option to create a loadable
pi_calc.out file. This however will only be enough for limited success.
It should be obvious that most DSP target boards (DSK, modem etc...) do not
include text display devices. In the JTAG code composer that job is left to
the debugger. It works by placing a breakpoint inside the print routine and
than string printing the data to the 'stdout' device (a chain from the JTAG
emulator to the code composer debugger). In the end, the buffer for each
print statement is wiped out, but if you go poking around in the DSP memory
you may find a remnant.
The approach taken in DSK3DW was to create print routines that would write
strings to a DSK_STDOUT section in memory that would be configured for ROW
and COL dimensions. DSK3DW could then display that section using a memory
dump, but show the data as characters rather than integer or float. The
advantage would be that *if* you did have a character display device
connected to the DSP you could copy this data directly to it.
Another difference will be the 'lean and mean' stdio routines that were
written for the DSK. If you pull apart the stdio routines from RTS30.LIB
you will find the resource requirements are rather large. The DSK needed to
be much more frugal with its resources, so a pared down IO library was
created.
An explanation is given in the DSK3DW help file (search for sprintf or
STDIO). You will also find the canned ready to go examples
HELLO.C/HELLO.OUT and HELLO2.C/HELLO2.OUT to step through. Digging in, you
will also find some 'lean and mean' string print routines for floating
point, integer and hex numbers. However, should you get interested in the
normal STDIO routines, those sources are given in the compilers *.SRC files
(so you can rebuild the libs if you wanted to).
Hope this helps
Keith Larson
DSP and Analog Consulting Lincoln, Ma 01773
-------------------------
pi_calc.obj
-cr
-e c_int00
-o pi_calc.out
-m pi_calc.map
-l rts30.lib
-heap 256
-stack 256
MEMORY
{
RAM0 : org=0x809800, len=0x000002
RAM1 : org=0x800000, len=0x003fff
RAM2 : org=0x804000, len=0x003fff
}
SECTIONS
{
boot_rsrv : {} > RAM0
.text : {} > RAM1
.data : {} > RAM1
.sysmem : {} > RAM1
.const : {} > RAM1
.bss : {} > RAM2
.cinit : {} > RAM2
.stack : {} > RAM2
}
Dani Fdz wrote:
Hi!,
I'm just starting with DSP programming. I've got the DSK board for the
VC33 and after browsing through the web and the documentation I tried
to compile and link the following C file:
pi_calc.c
#include <stdio.h> /* printf() is big and uses lots of heap and stack
*/
void main(void)
{ float a,b,c;
a = 355.0;
b = 113.0;
c = a/b;
printf("\npi=%4.11f\n",c); /* printf() is big and uses lots of heap
and stack */
printf (" %s %s" ,__TIME__, __DATE__);
}
what I did was to execute the following:
cl30 pi_calc.c -z -l rts30.lib
Then, I got the a.out file which then I tried to load to the DSP via
the DSK3DW.exe (File->load executable...). But I got an error message
saying: Extra operand(s).
Does anybody know what I did wrong? Also, is it very useful/necessary
using the Code Composer for C programming? Sorry if this problem is
something too basic. I'm just a newbie with all that.
Thank you in advance!

(You need to be a member of c3x -- send a blank email to c3x-subscribe@yahoogroups.com )

Hi Keith,

First of all, thank you for spending all that time for answering me :)

As I said in my first post, I have the VC33 university DSK. And after
browsing the web, forums, ... I concluded that if I want to do
something serious, like the Inertial Navigation System I will need
Code Composer for, first, simulating my program on the PC, and then
use the JTAG emulation to see if it really works in the VC33, is it
all right? is the JTAG emulation the same as the DSK3DW debugger? (If
so, what is the XDS module for?¿...well, anyway, what is it for?)
Isn't there an alternative to Code Composer? (we can't pay 1500$ :( ).

Thank you very much.

Dani.

P.S.What I'm trying to do is exactly the section 5.3 of this document:
http://www.casde.iitb.ac.in/Publications/pdfdoc-2004/vikas-ddp.pdf On Apr 8, 2005 2:16 PM, Keith Larson <klarsondsp@klar...> wrote:
> Hi Dani
>
> Figure it this way.
>
> 1) How many times per second do you need to process and update
> 2) How many CPU cycles does this represent
> 3) How many multiplies and adds per computation loop are in the algorithm
>
> Example:
> 1) 1000 updates per second (100-1000x a reasonable visual update rate)
> 2) With a 75 MHz CPU = 75000 cycles per update
> 3) 16x16 matrix = 256 operations (compiler is 3x slow to ASM?)
> You should be able to do 100 such operations in the given time
>
> This is likely way too much CPU horsepower. If you drop into LOPOWER, or
> IDLE allot, the power consumtion will go way down. Or, have the CPU do more
> of the overall task. You did not mention for example if the VC33 would be
> getting preprocessed data from a GPS receiver.
>
> TI compilers are not known for hand optimized library support (everyone
> seems to have their own method), and matrix operations are no exception
> given that they are not part of the ANSI compiler standard set of core
> operations. If you do need speed, the ASM code for simple matrix operations
> (+,-) will be quite simple, you dont even need to know row and columns, just
> the overall size. Multiplication is slightly tougher in that you need to
> step and work by columns. Still not difficult given that the inner loop is
> nothing more than a MAC. From experience I can tell you that if you do have
> a problem, it will likely be with Matrix inversion. A few months back I
> wrote my own simple SPICE engine and wrote my own Matrix library including
> an inversion routine.
>
> Simple integration and differentiation is nothing more than addition or
> subtraction of each element against the like element in a second array
> (easy). But there are also ways to get the derivitive of a matrix relative
> to another element in the array (stock risk analysis engines do this).
> Another tough nut but very unlikely what you need (I have little knowledge
> here).
>
> Hope this helps
> Best regards
> Keith Larson
> DSP and Analog Consultant
> Lincoln, Ma 01773
>
> http://home.comcast.net/~klarsondsp/ >
> Dani Fdz wrote:
> Hi Keith,

Thanks for your answer, I got the DSK v2.02 (which doesn't have
> the
DSK_STDOUT option) instead of 2.04, that's why I didn't find the
Hello.c
> and Hello2.c examples, but know I'm ready to go :p.

What I want to do whit
> this DSP is an INS (Inertial Navigation
System), so I will need good
> functions for matrix operations,
derivatives, integration, etc. Do you know
> if it is possible to
generate code to the DSP from MATLAB?¿ I know that I
> can get C code
from any .m MATLAB file, but then can I compile that code
> with cl30?
If so, will it be efficient enough? What is the 'normal' thing to
> do
with that kind of operations? only with math.h?

Thank you in
> advance,

Dani.

On Apr 4, 2005 4:33 PM, Keith Larson
> <klarsondsp@klar...> wrote:

> Hi Dani

Without a linker command file the linker default is to place all
> code and
data beginning at address zero (a mistake); Try making a map file.
> The MAP
file output will show where everything is being placed in
> memory.

If you look in DSK3DW's 'Project build' pull down you will find a
> dialog box
that will help you generate a linker command file. I created the
> following
linker command file, and then used the BAT build option to create
> a loadable
pi_calc.out file. This however will only be enough for limited
> success.

It should be obvious that most DSP target boards (DSK, modem
> etc...) do not
include text display devices. In the JTAG code composer that
> job is left to
the debugger. It works by placing a breakpoint inside the
> print routine and
than string printing the data to the 'stdout' device (a
> chain from the JTAG
emulator to the code composer debugger). In the end, the
> buffer for each
print statement is wiped out, but if you go poking around in
> the DSP memory
you may find a remnant.

The approach taken in DSK3DW was to
> create print routines that would write
strings to a DSK_STDOUT section in
> memory that would be configured for ROW
and COL dimensions. DSK3DW could
> then display that section using a memory
dump, but show the data as
> characters rather than integer or float. The
advantage would be that *if*
> you did have a character display device
connected to the DSP you could copy
> this data directly to it.

Another difference will be the 'lean and mean'
> stdio routines that were
written for the DSK. If you pull apart the stdio
> routines from RTS30.LIB
you will find the resource requirements are rather
> large. The DSK needed to
be much more frugal with its resources, so a pared
> down IO library was
created.

An explanation is given in the DSK3DW help
> file (search for sprintf or
STDIO). You will also find the canned ready to
> go examples
HELLO.C/HELLO.OUT and HELLO2.C/HELLO2.OUT to step through.
> Digging in, you
will also find some 'lean and mean' string print routines
> for floating
point, integer and hex numbers. However, should you get
> interested in the
normal STDIO routines, those sources are given in the
> compilers *.SRC files
(so you can rebuild the libs if you wanted to).

Hope
> this helps
Keith Larson
DSP and Analog Consulting
Lincoln, Ma
> 01773
-------------------------

pi_calc.obj
-cr
-e c_int00
-o
> pi_calc.out
-m pi_calc.map
-l rts30.lib
-heap 256
-stack 256
MEMORY
{
RAM0
> : org=0x809800, len=0x000002
RAM1 : org=0x800000, len=0x003fff
RAM2 :
> org=0x804000, len=0x003fff
}
SECTIONS
{
boot_rsrv : {} > RAM0
.text : {} >
> RAM1
.data : {} > RAM1
.sysmem : {} > RAM1
.const : {} > RAM1
.bss : {}
> > RAM2
.cinit : {} > RAM2
.stack : {} > RAM2
}

Dani Fdz
> wrote:

Hi!,

I'm just starting with DSP programming. I've got the DSK board
> for the
VC33 and after browsing through the web and the documentation I
> tried
to compile and link the following C file:

pi_calc.c

#include
> <stdio.h> /* printf() is big and uses lots of heap and stack
*/
void
> main(void)
{
float a,b,c;
a = 355.0;
b = 113.0;
c = a/b;
> printf("\npi=%4.11f\n",c); /* printf() is big and uses lots of heap
and
> stack */
printf (" %s %s" ,__TIME__, __DATE__);
}

what I did was to
> execute the following:

cl30 pi_calc.c -z -l rts30.lib

Then, I got the
> a.out file which then I tried to load to the DSP via
the DSK3DW.exe
> (File->load executable...). But I got an error message
saying: Extra
> operand(s).

Does anybody know what I did wrong? Also, is it very
> useful/necessary
using the Code Composer for C programming? Sorry if this
> problem is
something too basic. I'm just a newbie with all that.

Thank you
> in advance!





(You need to be a member of c3x -- send a blank email to c3x-subscribe@yahoogroups.com )

Hi Dani

The DSK and Code Composer debuggers are two different animals, each with benefits and negatives. 

Think of the DSK debugger as a cooperative task executive kernel that has the ability to stop and start a process on interrupt, saving the entire CPU context (just like a big interrupt routine).  While in the kernel mode (process is stopped) the DSP can receive and transmit command packets and data.  This allows the DSP and host to exchange the data that you see on the PC screen, aka the data memory windows.  Likewise graph display windows are simply a reformatting of data into lines plotted in X-Y space.  If memory and graph dumps are obvious, it should not be too far of a leap to consider that (for example) the disassembly window is really nothing more than another data dump window that is 'formatted' to display mnemonics.  Considering what kind of display windows are left, you have the command window and source edit/tracking.  Ill leave this to your imagination.

So what is JTAG?  In the TI processors JTAG boundary has been expanded to include a couple of extra 'emulation' domains known as TAP's.  The name and how this works does not really matter for this discussion, but consider that if you can scan a command into a  TAP register you might be able to do something like halting the CPU clocks.  Hmm... if the CPU was *stopped* and if you had additional taps chaining together the register bits, you could probably scan that data out of the CPU, into the JTAG emulator, and then (with proper formatting) display that to the PC screen.  Or, maybe (likely) you could reverse the process and scan data *into* the CPU registers.  Pretty slick huh!  This handles the CPU registers (in the DSK the registers were in memory), so you now need to move data up and down between the host PC and the DSP.  To make that story short, the way this is done is to scan an LDI or STI opcode into the pipeline complete with an address (remember in JTAG you have total CPU control) and step the processor by 1 clock.  The memory data, now in a register, is then scanned to or from the PC.

So which is better?

JTAG
----
- Halts the CPU (nothing happens during scan)
+ Total CPU control
+ Relatively simple interface
+ No memory footprint
- Slow
- Not useful for real time applications
+ A full featured debugger
- No source code

DSK Kernel Mode Debug
---------------------
+ CPU is always running (though nested interrupts are typically off)
- CPU is less tightly controlled
- Requires some kind of host communication interface (USB, printer port, RS232...)
- Small 256 word memory footprint for executive kernel
+ Fast (as fast as the host port and PC can move data)
+ Same interface for creating host based applications
+ A full featured debugger
+ Free and (reasonably) open source software
+ Host/DSP applications (spectrum analyzers and more)

Hope this helps
Best regards
Keith Larson

By the way (here is hopefully a shameless plug).

If anyone needs this (but not being a TI employee anymore, this one is no longer free) I have a working USB interface with all of the DSK tools running on top of it.  So, just like the Printer Port DSK, the kernel is downloaded via USB allowing two way USB communication.  I have been considering marketing a VC33+USB base board product that may or may not have a CODEC and external memory.  If anyone is interested, please email me privately.  I had hoped to have this ready sooner, but have been tied up with a couple of other projects.
Dani Fdz wrote:

Hi Keith,

First of all, thank you for spending all that time for answering me :)

As I said in my first post, I have the VC33 university DSK. And after
browsing the web, forums, ... I concluded that if I want to do
something serious, like the Inertial Navigation System I will need
Code Composer for, first, simulating my program on the PC, and then
use the JTAG emulation to see if it really works in the VC33, is it
all right? is the JTAG emulation the same as the DSK3DW debugger? (If
so, what is the XDS module for?¿...well, anyway, what is it for?)
Isn't there an alternative to Code Composer? (we can't pay 1500$ :( ).

Thank you very much.

Dani.

P.S.What I'm trying to do is exactly the section 5.3 of this document:
http://www.casde.iitb.ac.in/Publications/pdfdoc-2004/vikas-ddp.pdf On Apr 8, 2005 2:16 PM, Keith Larson <k...@comcast.net> wrote:
> Hi Dani
>
> Figure it this way.
>
> 1) How many times per second do you need to process and update
> 2) How many CPU cycles does this represent
> 3) How many multiplies and adds per computation loop are in the algorithm
>
> Example:
> 1) 1000 updates per second (100-1000x a reasonable visual update rate)
> 2) With a 75 MHz CPU = 75000 cycles per update
> 3) 16x16 matrix = 256 operations (compiler is 3x slow to ASM?)
>    You should be able to do 100 such operations in the given time
>
> This is likely way too much CPU horsepower.  If you drop into LOPOWER, or
> IDLE allot, the power consumtion will go way down.  Or, have the CPU do more
> of the overall task.  You did not mention for example if the VC33 would be
> getting preprocessed data from a GPS receiver.
>
> TI compilers are not known for hand optimized library support (everyone
> seems to have their own method), and matrix operations are no exception
> given that they are not part of the ANSI compiler standard set of core
> operations. If you do need speed, the ASM code for simple matrix operations
> (+,-) will be quite simple, you dont even need to know row and columns, just
> the overall size.  Multiplication is slightly tougher in that you need to
> step and work by columns.  Still not difficult given that the inner loop is
> nothing more than a MAC.  From experience I can tell you that if you do have
> a problem, it will likely be with Matrix inversion.  A few months back I
> wrote my own simple SPICE engine and wrote my own Matrix library including
> an inversion routine.
>
> Simple integration and differentiation is nothing more than addition or
> subtraction of each element against the like element in a second array
> (easy).  But there are also ways to get the derivitive of a matrix relative
> to another element in the array (stock risk analysis engines do this).
> Another tough nut but very unlikely what you need (I have little knowledge
> here).
>
> Hope this helps
> Best regards
> Keith Larson
> DSP and Analog Consultant
> Lincoln, Ma 01773
>
> http://home.comcast.net/~klarsondsp/ >
> Dani Fdz wrote:
> Hi Keith,

Thanks for your answer, I got the DSK v2.02 (which doesn't have
> the
DSK_STDOUT option) instead of 2.04, that's why I didn't find the
Hello.c
> and Hello2.c examples, but know I'm ready to go :p.

What I want to do whit
> this DSP is an INS (Inertial Navigation
System), so I will need good
> functions for matrix operations,
derivatives, integration, etc. Do you know
> if it is possible to
generate code to the DSP from MATLAB?¿ I know that I
> can get C code
from any .m MATLAB file, but then can I compile that code
> with cl30?
If so, will it be efficient enough? What is the 'normal' thing to
> do
with that kind of operations? only with math.h?

Thank you in
> advance,

Dani.

On Apr 4, 2005 4:33 PM, Keith Larson
> <k...@comcast.net> wrote:

> Hi Dani

Without a linker command file the linker default is to place all
> code and
data beginning at address zero (a mistake); Try making a map file.
> The MAP
file output will show where everything is being placed in
> memory.

If you look in DSK3DW's 'Project build' pull down you will find a
> dialog box
that will help you generate a linker command file. I created the
> following
linker command file, and then used the BAT build option to create
> a loadable
pi_calc.out file. This however will only be enough for limited
> success.

It should be obvious that most DSP target boards (DSK, modem
> etc...) do not
include text display devices. In the JTAG code composer that
> job is left to
the debugger. It works by placing a breakpoint inside the
> print routine and
than string printing the data to the 'stdout' device (a
> chain from the JTAG
emulator to the code composer debugger). In the end, the
> buffer for each
print statement is wiped out, but if you go poking around in
> the DSP memory
you may find a remnant.

The approach taken in DSK3DW was to
> create print routines that would write
strings to a DSK_STDOUT section in
> memory that would be configured for ROW
and COL dimensions. DSK3DW could
> then display that section using a memory
dump, but show the data as
> characters rather than integer or float. The
advantage would be that *if*
> you did have a character display device
connected to the DSP you could copy
> this data directly to it.

Another difference will be the 'lean and mean'
> stdio routines that were
written for the DSK. If you pull apart the stdio
> routines from RTS30.LIB
you will find the resource requirements are rather
> large. The DSK needed to
be much more frugal with its resources, so a pared
> down IO library was
created.

An explanation is given in the DSK3DW help
> file (search for sprintf or
STDIO). You will also find the canned ready to
> go examples
HELLO.C/HELLO.OUT and HELLO2.C/HELLO2.OUT to step through.
> Digging in, you
will also find some 'lean and mean' string print routines
> for floating
point, integer and hex numbers. However, should you get
> interested in the
normal STDIO routines, those sources are given in the
> compilers *.SRC files
(so you can rebuild the libs if you wanted to).

Hope
> this helps
Keith Larson
DSP and Analog Consulting
Lincoln, Ma
> 01773
-------------------------

pi_calc.obj
-cr
-e c_int00
-o
> pi_calc.out
-m pi_calc.map
-l rts30.lib
-heap 256
-stack 256
MEMORY
{
RAM0
> : org=0x809800, len=0x000002
RAM1 : org=0x800000, len=0x003fff
RAM2 :
> org=0x804000, len=0x003fff
}
SECTIONS
{
boot_rsrv : {} > RAM0
.text : {} >
> RAM1
.data : {} > RAM1
.sysmem : {} > RAM1
.const : {} > RAM1
.bss : {}
> > RAM2
.cinit : {} > RAM2
.stack : {} > RAM2
}

Dani Fdz
> wrote:

Hi!,

I'm just starting with DSP programming. I've got the DSK board
> for the
VC33 and after browsing through the web and the documentation I
> tried
to compile and link the following C file:

pi_calc.c

#include
> <stdio.h> /* printf() is big and uses lots of heap and stack
*/
void
> main(void)
{
float a,b,c;
a = 355.0;
b = 113.0;
c = a/b;
> printf("\npi=%4.11f\n",c); /* printf() is big and uses lots of heap
and
> stack */
printf (" %s %s" ,__TIME__, __DATE__);
}

what I did was to
> execute the following:

cl30 pi_calc.c -z -l rts30.lib

Then, I got the
> a.out file which then I tried to load to the DSP via
the DSK3DW.exe
> (File->load executable...). But I got an error message
saying: Extra
> operand(s).

Does anybody know what I did wrong? Also, is it very
> useful/necessary
using the Code Composer for C programming? Sorry if this
> problem is
something too basic. I'm just a newbie with all that.

Thank you
> in advance!

> 



NEW!  You can now post a message or access and search the archives of this group on DSPRelated.com:
http://www.dsprelated.com/groups/c3x/1.php

_____________________________________
/groups/c3x/1.php

To Post:  Send an email to c...@yahoogroups.com

Other DSP Related Groups: http://www.dsprelated.com/groups.php

(You need to be a member of c3x -- send a blank email to c3x-subscribe@yahoogroups.com )