Commit e505ea7b authored by Maxime Perrotin's avatar Maxime Perrotin
parents ea42ad3e 821bdb10
Introduction Spacewire testing with the STAR Dundee brick
============ ============================================
This folder contains the OAR RTEMS scaffold. The Makefile and example HW setup
source code demonstrates how to: --------
* support both debug and release compilations 1. Connect the brick to the Windows laptop, over the USB Type B (printers) to USB Type A cable.
* support compilation for native and emulated FPU usage 2. Install the STAR Dundee USB Brick SW (`spw_usb_win_x86-64_v2.61.1_2`)
* support targetting Leon2 and Leon3 CPUs 3. Launch it from `C:\Program Files\STAR-Dundee\Validation Software\run.bat`
* enable/disable showing compilation commands
* perform memory, FPU and integer testing of any Leon-based board
Building RTEMS via the RSB 4. On the GR740 side, connect a SpW cable from this port (marked with `o`)...
--------------------------
The contrib folder includes a script that you can use to compile RTEMS4.12
with the Leon2 and Leon3 BSPs from the OAR repository. Note that
[as discussed in the RTEMS mailing list](https://lists.rtems.org/pipermail/users/2016-February/029782.html),
you will need to compile your BSP for native or emulated FPU, based
on what your desired target is (i.e. edit the leon2.cfg/leon3.cfg
files to remove `-msoft-float` or not). The Makefile mirrors this
need, by pointing to different paths (see FPU_SUFFIX variable),
depending on whether you build with FPU=1 or not.
Executive summary: if you want to build native-FPU-using binaries, ```
you'll need to edit leon2.cfg/leon3.cfg and remove the `-msoft-float` x x x
before building the BSPs (that is, right after the clone from o x x
the RTEMS git repository - in line 87 of the script). x x x
```
Application sources ...to the STAR Dundee brick `Link 1`.
-------------------
The sources of your project must be set inside the Makefile, in the SRC
variable. The VPATH can be used to automatically locate them in
your source tree:
VPATH=src:Library/foo:Library/bar:...
SRC= \
init.c \
tasking.c \
gnc.c \
compute_pi.c
# Compilation options
There are 4 orthogonal compilation options that you can control:
- debug/release compilation (`CFG`)
- emulated/native FPU compilation (`FPU`)
- Leon2/Leon3 target (`LEON`)
- show/hide compilation commands (`V`)
## Debug/Release mode
Using the `CFG` Makefile parameter, you can select debug or release
compilation:
$ make CFG=debug
...
$ ls -l bin.debug.NONFPU.leon3/
-rwxr-xr-x 1 user user 645273 Mar 16 17:43 fputest
$ make CFG=release
...
$ ls -l bin.release.NONFPU.leon3/
-rwxr-xr-x 1 root root 47860 Mar 16 17:48 fputest
-rwxr-xr-x 1 root root 585178 Mar 16 17:48 fputest.debug
Notice that:
- In release compilation, the process creates a small binary
(containing only the executable code) and separately, the debug information -
for loading from inside GDB via the `file` command.
- Notice also that the output folder tells you this build did not use
native FPU, and targeted Leon3 (the defaults). To compile for
native FPU or a different Leon target, use the next two options.
## Native or emulated FPU compilation for the source files
To use native FPU compilation for the source files, use the `FPU`
Makefile parameter:
$ make CFG=debug FPU=1
To use emulation (default, if `FPU` option is not provided), pass `FPU=0`:
$ make CFG=debug FPU=0
...or just don't mention `FPU` at all:
$ make CFG=debug
The `FPU` and `CFG` options are completely independent ; you can e.g.
compile a debug version that uses native FPU, and a release one that uses
emulation. Just keep in mind that currently, 4.12
[does not allow you to use the same BSP](https://lists.rtems.org/pipermail/users/2016-February/029782.html),
for both native and emulated FPU usage ; you'll have to build separate
BSPs by tweaking the `leon2.cfg`/`leon3.cfg` files when you build RTEMS.
## Select Leon target
Use the `LEON` Makefile parameter to decide which target to build for
(currently, only `leon2` and `leon3` are supported):
$ make CFG=debug FPU=1 LEON=leon3
## Verbosity
Messages shown during compilation follow the semantics of the Linux kernel
compilation process, emitting short messages by default (CC for compilation,
LD for linking). The compilation is also incremental, taking into account
the modification timestamps of the files and their dependencies:
$ touch src/task1.c
$ make
[CC] objs.debug.NONFPU.leon3/task1.o
[LD] bin.debug.NONFPU.leon3/fputest
If you want to see the complete commands used, pass `V=1`:
$ touch src/task1.c
$ make CFG=debug FPU=0 V=1
/opt/rtems-4.12-2016.06.13.NONFPU/bin/sparc-rtems4.12-gcc -c \
-B/opt/rtems-4.12-2016.06.13.NONFPU/sparc-rtems4.12/leon3/lib \
-specs bsp_specs -qrtems -mcpu=cypress -DBSP_leon3 -ffunction-sections \
-fdata-sections -Wall -Wmissing-prototypes \
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs \
-g -Wall -D_DEBUG -I src -msoft-float \
-o objs.debug.NONFPU.leon3/task1.o src/task1.c
/opt/rtems-4.12-2016.06.13.NONFPU/bin/sparc-rtems4.12-gcc -g \
-o bin.debug.NONFPU.leon3/fputest objs.debug.NONFPU.leon3/init.o \
objs.debug.NONFPU.leon3/task1.o objs.debug.NONFPU.leon3/task2.o \
objs.debug.NONFPU.leon3/common.o -msoft-float \
-B/opt/rtems-4.12-2016.06.13.NONFPU/sparc-rtems4.12/leon3/lib \
-specs bsp_specs -qrtems -mcpu=cypress -DBSP_leon3 \
-ffunction-sections -fdata-sections -Wall -Wmissing-prototypes \
-Wimplicit-function-declaration -Wstrict-prototypes \
-Wnested-externs -Wl,--gc-sections
Built with RTEMS at /opt/rtems-4.12-2016.06.13.NONFPU/sparc-rtems4.12/leon3/lib for leon3.
# Support
For any questions/feedback, raise tickets in the repository and/or contact 5. Upon powering up the GR740, you should be seeing the brick's Link 1 LED turn green
me directly: 6. Now compile this application, and launch the generated binary inside GRMON
7. On the Windows side, go to the "Simple Test" window on the top-right, and enter this payload:
Thanassis Tsiodras
Real-time Embedded Software Engineer ```
System, Software and Technology Department 1 9 1 2 3
Address: ```
ESTEC/Office EF216
Keplerlaan 1, PO Box 299 This payload, routing-wise, means:
NL-2200 AG Noordwi
E-mail: - exit from Link 1
Athanasios.Tsiodras@esa.int - then enter through AMBA port 9
Phone: - with payload 1 2 3
+31 71 565 5332
So when you click on "Send Packet", the application will show - on the GRMON side - this:
```
SPW0: Recevied 1 packets
PKT of length 3 bytes, 0x01 0x02 0x03 0x00 0x00 0x00 0x00 0x00...
```
8. Now let's send from the GRMON side. Click on "Receive Packets" and enter this on the
GRMON prompt:
```
starting packet processing loop. enter command:
x0 1 3 1 2 3 4 5 6 7 8 9
```
This means:
- Use device 0 (grspw0)
- exit though link 1 (the `o` above)
- then enter towards target 3 (The PC side of the USB brick)
- with payload 1 2 3...
And you should see the packet arrive in the GUI of the Brick.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment