Release consists of the RTOS sources and three sample projects - see
Release description for details. Each sample located in separate
folder. Structure of test project folder (folders are in brackets '[]'):
[Config] - linker scripts and other utilities
[Exe] - executable product[s]
[List] - listings and other temporary text files
[Obj] - objects and other intermediate files
[Src] - test project sources
slon.vpj - SlickEdit project file
slon.Blackfin.vpw - SlickEdit workspace file
SConstruct - Scons main script file
slon is test project name.
Structure of the RTOS folder:
scmRTOS
Common - common RTOS sources
BF533 - portable part
See Distribution section and below about release using manners.
The simplest way is to employ SCons build system. Scons
is actually Python script, so Python interpreter is necessary to
use SCons. SCons, in a certain sense, is the analog of popular build utility make,
but much more powerful because of comprehensive underground of programming language (Python).
To use SCons:
- download and install Python interpreter v2.4;
- download and install SCons tool;
- launch SCons by typing tool name in command line in folder
where SConstruct file (SCons main script) located .
SCons will build the project.
If user want to use his own build system he has to specify the following
command-line options for various tools:
-proc ADSP-BF533
-g
-o Obj\<src_name>.doj
-ISrc
-I../scmRTOS/Common
-I../scmRTOS/BF533
-I$TOOLKIT_PATH$\Blackfin\include
-proc ADSP-BF533
-si-revision 0.3
-C
-c
-g
-c++
-Ov 80
-instantlocal
-Wsuppress cc1164
-path-output Obj
-save-temps
-ISrc
-I../scmRTOS/Common
-I../scmRTOS/BF533
-I$TOOLKIT_PATH$\Blackfin\include
-proc ADSP-BF533
-si-revision 0.3
-e
-save-temps
-L Obj
-Map List\slon.xml
-o Exe\slon.dxe
-T Config\BF533cpp.ldf
-Map Config\BF533cpp.ldf
-L$TOOLKIT_PATH$\Blackfin\lib532_rev_0.3
Note
where $TOOLKIT_PATH$ - path to folder with toolkit installed.
Additionally, folder Config contains some useful script utilities that user may
take into account. All utilities are Python scripts. This means that Python
interpreter must be installed to use the utilities. The utilities are:
- vdsp_lst.py
- get_info.py
- ldprg.py
- utils.py
Some compilers produces auxiliary list files, in which source code interleaved
with assembler mnemonics. This is convenient thing to inspect codegeneration.
Unfortunately, VisualDSP++ Blackfin compiler does not generate such listing
file. As maximum, the compiler can generate auxiliary assembler file that
contains assembler code with text links to source code, for example:
.LN17:
// "Src\main.cpp" line 125 col 5
P0.L = 1544;
P0.H = -64;
R0 = 10011 (X);
[P0+ 0] = R0;
.LN18:
// "Src\main.cpp" line 126 col 5
P1.L = 1548;
P1.H = -64;
R0 = 5000 (X);
[P1+ 0] = R0;
vdsp_lst.py just performs source code insertion on base of links, so the above
example looks like the following:
.LN17:
MMR32(TIMER0_PERIOD) = 10011; // "Src\main.cpp" line 125 col 5
P0.L = 1544;
P0.H = -64;
R0 = 10011 (X);
[P0+ 0] = R0;
.LN18:
MMR32(TIMER0_WIDTH) = 5000; // "Src\main.cpp" line 126 col 5
P1.L = 1548;
P1.H = -64;
R0 = 5000 (X);
[P1+ 0] = R0;
The using of vdsp_lst.py is very simple: just launch the utility with one
argument - compiler generated .s file (to enable generating of .s files command
line option -save-temps must be specified).
VisualDSP++ linker does not issue any explicit info about code and data sizes of
linked project. To get this info the user has to launch elfdump.exe utility from
VisualDSP++ toolkit. Unfortunately, elfdump outputs information in uncomfortable
format (a lot of service info, hexadecimal representation of sizes, etc.). To
fix this inconvenience get_info.py can be used. The utility gets output from
elfdump and produces info in human-readable format. See the example below:
Total : Code: 2394 bytes
Data: 3436 bytes (Segment A: 3416 bytes. Segment B: 20 bytes.)
----------------------------------
Details | Section | Size
----------------------------------
| code | 2394 bytes
| data_a | 228 bytes
| data_b | 20 bytes
| bsz_data_a | 3188 bytes
| bsz_data_b | 0 bytes
----------------------------------
get_info.py is used in the following manner:
get_info.py dump.txt
where dump.txt - text file with dump from elfdump.exe. dump.txt can be
created by simple redirect elfdump output to file.
ldprg.py is a custom user loader. This utility allows to customize loading
process by launch service executable (.dxe) before loading of main executable.
This can be useful, for example, in case when the user's program stores data
objects in SDRAM - these objects must be initialized (according to C/C++
Standard) and initializing is performed during loading the user's program.
So, if at this moment processor's SDRAM controller is not properly set up the
initializing process will fail and processor will not start properly.
Custom loader fixes this situation. The loader allows to run a special service
executable before loading main user's executable. This service executable
performs SDRAM controller setup (and other actions if need).
The using of custom user loader is the following:
ldprg.py -p <ProcessorName> -i <Initializer FileName> -e <Executable FileName> -s <Session Name>
where
<ProcessorName> is name of the used processor. Available Processors are: ADSP-BF531, ADSP-BF532, ADSP-BF533
<Initializer FileName> is name of service executable (.dxe file)
<Executable FileName> is name of main executable (.dxe file)
<Session Name> is name of debug session. Only emulator sessions are suitable.
VisualDSP++ compiler performs error message line wrapping, so error message
often occupies several (two or more) lines. Some powerful 3rd party programmer's
editors uses status line to show error message text when error locator opens
source file with error. At that moment the only first line of error message is
displayed in status line. This is very inconvenient.
utils.py contains function handle_err() that performs error message
unwrapping. The using of the function is very simple:
oerr = utils.handle_err(out)
where out - compiler's stderr stream,
oerr - the same stream with error/warning lines unwrapped.
This function cannot be used standalone - it can be used only inside Python script.
Note
When using Scons to build the project the above utilities (except ldprg.py)
are run automatically.