Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: 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
future.

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:
ifneq ($(DSPBUILD),)
$(BUILDDIR)/dsp-image.h: ...
...
endif

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,

-Cat
Received on 2007-11-27


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa