Building the examples: step-by-step instructions
1. [Optional] Copy the entire "examples" tree out of the product
This step is optional, but recommended if you plan to modify the samples in any way. It will ensure you have a backup copy of the original examples, as provided by the Codec Engine product.
Important: throughout the rest of this document, we will use the following notation:
•<CE_EXAMPLES_INSTALL_DIR> - absolute path of the examples directory or the copy you made, e.g. /usr/work/examples
•<CE_INSTALL_DIR> - root directory of your Codec Engine installation. The original examples are in <CE_INSTALL_DIR>/examples.
•<BIOS_INSTALL_DIR> - root directory of your DSP/BIOS installation.
•<XDC_INSTALL_DIR> - root directory of your xdctools installation.
•directory/file - position of the file relative to the examples directory; for examples, ti/sdo/ce/examples/codecs/makefile refers to <CE_EXAMPLES_INSTALL_DIR>ti/sdo/ce/examples/codecs/makefile.
2. Edit xdcpaths.mak to customize the build for your software installation and your hardware
At the root of the Examples directory is a build-related file named xdcpaths.mak that all Codec Engine example makefiles include. All users must edit this file to specify where various software components needed by Codec Engine are on their system, and often to narrow the list of hardware platforms to build for (thereby reducing the example build time and possibly the scope of external components).
The variables defined in xdcpaths.mak that most users must assign are: DEVICES, GPPOS, PROGRAMS, and various *_INSTALL_DIR variables. Each are described more below as well as in comments throughout the xdcpaths.mak file.
Advanced users will note that these GNU make-based variables can be overridden on the command line. As a result, it is possible to tailor these makefiles without modifying them - by simply setting the variables on the command line when running "gmake".
2.1 xdcpaths.mak's DEVICES variable
The DEVICES variable indicates which hardware platforms should be built for. Most users are only interested in building for a single platform, and the other platforms can be removed from the DEVICES variable.
Note that there is a one-to-one mapping between the "short name" in the DEVICES macro and the "platform package" which is used. For example, the OMAP3530 value in DEVICES maps to the ti.platforms.evmOMAP3530 platform package.
2.2 xdcpaths.mak's GPPOS variable
The GPPOS variable indicates which GPP (General Purpose Processor, often an ARM) OS's should be built for. Most users are only interested in building for a single GPP OS (e.g. WinCE or Linux glibc or Linux uClibc), and the other GPP OS's can be removed from the GPPOS variable.
Note that there is a one-to-one mapping between the "short name" in the GPPOS macro and the "target module" which is used. For example, the WINCE value in GPPOS maps to the microsoft.targets.arm.WinCE target Module.
2.3 xdcpaths.mak's PROGRAMS variable
The PROGRAMS variable indicates roughly which system architecture the examples should be built for. Generally, Codec Engine supports "local" and "remote" codecs, and as a result there are 3 types of executables that can be built - APP_LOCAL, APP_CLIENT and DSP_SERVER.
APP_LOCAL indicates that all examples that support the apps and codecs running on the same processor should be built. This is typically set for single core devices (e.g. DM365, DM6437), but can als be set for multi-core devices (e.g. OMAP3530, DM6446) where the app and codec run on either the GPP or the DSP.
APP_CLIENT and DSP_SERVER typically go together, and indicate that all examples that support remote execution of codecs should be built. If DSP_SERVER is set in the PROGRAMS variable and an appropriate multi-core platform is set in the DEVICES variable, the examples in examples/ti/sdo/ce/examples/servers may be built. APP_CLIENT indicates the "client" side of a "client/server" system, so GPP-side apps will be built (for the appropriate GPP OS's and hardware platforms set in GPPOS and DEVICES respectively).
Note that you can set all 3 (APP_LOCAL, APP_CLIENT, and DSP_SERVER) or any subset of them. As a further example, if only DSP_SERVER is set, no applications will be built, but all components required to create a server (including codecs) will be built.
2.4 xdcpaths.mak's various *_INSTALL_DIR, CGTOOLS_* and CC_* variables
The xdcpaths.mak file also contains variables to indicate where products which Codec Engine may depend on are installed. The list of dependent products is a direct result of what values are assigned in the DEVICES, GPPOS and PROGRAMS variables. For example, if you've set PROGRAMS to only APP_LOCAL, DEVICES to only DM355, and GPP_OS to LINUX_UCLIBC, you aren't required to provide DSPLINK_INSTALL_DIR, BIOS_INSTALL_DIR, CGTOOLS_V5T or CC_V5T
Further, if you're using a "full" installation of Codec Engine (see http://tiexpressdsp.com/index.ph ... d_others_don.27t.3F for more details), many of the dependencies will be "auto-assigned" for you to the cetools/packages directory.
Please refer to the comments throughout xdcpaths.mak for more details.
Each directory contains a GNU makefile which enables you to build the sample in the current directory. Top-level directories also contain a makefile which steps into subdirectories and builds all the examples under the parent directory.
FYI, the xdcpaths.mak file is included by the individual makefiles for all the example codecs, servers, and applications.
Please keep in mind that MOST BUILD TROUBLES OCCUR WHEN ONE OF THE VARIOUS *_INSTALL_DIR VARIABLES ARE INCORRECT! Make sure there are no extra spaces (check the end of lines!), that every individual path (segment separated by the semicolon) is correct, character for character, and the build process is very likely to go smoothly.
3. Build example codecs
Change directory to ti/sdo/ce/examples/codecs and type
gmake clean
gmake
Alternatively, you can change into a specific codec's directory (e.g. ti/sdo/ce/examples/codecs/viddec_copy), and type
gmake clean
gmake
4. Build example extensions
Change directory to ti/sdo/ce/examples/extensions and type
gmake clean
gmake
Alternatively, you can change into a specific example extension directory (e.g. ti/sdo/ce/examples/extensions/scale), and type
gmake clean
gmake
5. Build example DSP servers
Note that this is only necessary for dual processor environments, like DM6446.
Change directory to ti/sdo/ce/examples/servers and type
gmake clean
gmake
Alternatively, you can change into a specific server's directory (e.g. ti/sdo/ce/examples/servers/video_copy), and type
gmake clean
gmake
Note: when developing your own codecs and applications, you will likely take one of the DSP server sample and modify it to suit your needs. These are the source files for this server application that you need to know about:
•*.cfg: Configuration script that determines what codecs should be included in the server, and how some of the components (e.g. DSKT2 and DMAN3) will be configured.
•*.tcf: TConf file for the app. It is often set to allow for a generous heap and static code and data. Be very careful with changing the memory map.
•main.c: generic main()
•link.cmd: application specific linker command file.
6. Build the GPP applications
Change directory to ti/sdo/ce/examples/apps (where the makefile is) and type
gmake clean
gmake
|
楼主
