Rockbox mail archiveSubject: Re: Integrating TI CG tools
Re: Integrating TI CG tools
From: Catalin Patulea <cat_at_vv.carleton.ca>
Date: Tue, 27 Nov 2007 11:41:19 -0500
My first instinct to both these issues is to defer them in favour of
actually getting sound output working. On the other hand, I can see
how a little bit of forethough can save us some headaches in the
On Nov 27, 2007 10:34 AM, Daniel Stenberg <daniel_at_rockbox.org> wrote:
> You can, but I consider it nicer if you check for a particular value or config
> that is set in the configure that isn't the exact model number/name. So that
> for example future dms320-targets can take advantage of the fix without adding
> the target names to the test.
Something like DSPBUILD (a boolean), below ROOTDIR, FIRMDIR, et al.?
And in firmware/Makefile:
I still see this as needing per-platform ifdefs because source files
will differ across platforms. Anyway.
> My biggest thought when I read the patch was: why is this generating a .h
> file? Isn't that stuff generating some kind of data or something that is
> better (more accurately) placed in a .c file?
Some of it has to be in a .h: I read the symbol table from the COFF
file and generate #define's that let me access variables in DSP memory
by name instead of hardcoding offsets. On the other hand, the actual
code indeed is better suited for a .c file. I just got lazy ;-) Making
xml2h.py output a .c and a .h will be the easy part.. I'll have to dig
around for examples of building a .o from a generated .c :\
Thanks for the feedback,
Received on 2007-11-27