-
Notifications
You must be signed in to change notification settings - Fork 7
/
README.rtems
178 lines (120 loc) · 5.55 KB
/
README.rtems
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
Instructions how to compile ORTE for RTEMS
==========================================
Build process of ORTE for RTEMS differs from build
for Linux and Windows even that all required changes
to actual source files are included in the common
source base.
The build for RTEMS requires access to the RTEMS BSP
and executive include files and libraries in addition
to selection cross-compiler and associated C library
files. It should be possible through autoconf/configure
options but we have not tested that approach because
we use OMK system for many of our Linux, RTEMS, etc.
projects and OMK provides rules suitable for RTEMS
projects.
See OMK homepage for more details about OMK
http://rtime.felk.cvut.cz/omk/
Example/template application (rtems-omk-template)
for RTEMS OMK project is provided in repository
http://rtime.felk.cvut.cz/gitweb/rtems-devel.git
The RTEMS specific OMK rules are used for ORTE build
cp Makefile.rules.rtems Makefile.rules
Then RTEMS target BSP is selected by specifying
RTEMS_MAKEFILE_PATH definition written into "config.target"
file
echo RTEMS_MAKEFILE_PATH=/opt/rtems4.10/powerpc-rtems4.10/icecube >config.target
This declaration selects directory where RTEMS Makefile.inc
file for given BSP is located.
The ORTE components can be configured in "config.omk" file
echo "# ORTE for RTEMS configuration" >config.omk
The RTEMS cannot run multiple processes. It is not problem
for RTEMS because it allows to specify and maintain multiple
domains and applications in single address space. Even ORTE
manager can be started directly from user application.
But standalone applications are used for testing
and standalone manager is easiest way to start development
too. The problem of independent starting of multiple
services in RTEMS environment had been solved by providing
applications as libraries with renamed C main() function.
This arrangement is selected for manager by
echo CONFIG_OC_ETH_ORTE_MANAGER_AS_LIBRARY=y >>config.omk
The same way examples and their build as libraries can be selected
echo CONFIG_OC_ETH_ORTE_EXAMPLES=y >>config.omk
echo CONFIG_OC_ETH_ORTE_EXAMPLES_AS_LIBRARY=y >>config.omk
Option to start the ORTE examples and manager interactively
is usesfull for testing. That is why commands for services
invocations from RTEMS shell are provided
echo CONFIG_OC_ETH_ORTE_RTEMS_SHELL=y >>config.omk
The commands set includes even "spawn" command implementation
to run services in background/parallel.
User application can include commands provided by "orte_rtems_shell"
and other ORTE services libraries ("ortemanager", "orteping",
"ortespy", ...) by registerring corersponding commands
rtems_shell_add_cmd("ortemanager", "orte",
"start orte manager",
ortemanager_main);
rtems_shell_add_cmd("orteping", "orte",
"start orteping",
orte_ping_main);
...
rtems_shell_add_cmd("spawn", "orte",
"spawn task or command in background",
orte_spawn_main);
The example application (orte/examples/rtems-shell) for RTEMS
testing is provided. Default provided network configuration
for this example uses DHCP failsafe option.
orte/examples/rtems-shell/networkconfig.h
The application binary image linked with RTEMS system
is available in "_compiled/<bsp_name>/bin" directory.
I.e.
_compiled/lpc17xx_ea_ram/bin/orte_rtems_shell_example
The build is tarted by simple "make" command after above
configuration
make V=1
provides invoked full commands printing.
make clean
or
make distclean
can be used to clean the project. Project can be build for multiple
BSPs when "RTEMS_MAKEFILE_PATH" is used directly as argument
of "make" command. Each BSP specific build uses its separate
build "_build/<bsp>" and output "_compiled/<bsp>" directory.
Example ORTE ping run under RTEMS
=================================
The ORTE applications require to start "ortemanager"
on each node. Manager "help" is shown when manager
command is invoked in RTEMS shell
ortemanager -h
It can be started in background by
spawn ortemanager -e
If more networked nodes are used then they need to be specified
when manager is started
spawn ortemanager -e -p 192.168.1.9 -k 192.168.1.51
ORTE ping publisher can be started now
spawn orteping -p
same as subscriber
spawn orteping -s
Both can be started specifying both -p and -s option.
Log level can be elevated as well
spawn orteping -p -s -v ALL.6
Limitations when ORTE is build and used with RTEMS
==================================================
The ORTE IDL compiler cannot be build to run on RTEMS
(CONFIG_OC_ETH_ORTE_IDL=n). But it can be build as part
of Linux build and used for RTEMS sources generation.
ORTE/DDS RTPS standard is based on building whole
network model on each participating node. That requires
considerable amount of memory. ORTE has little use
for devices equipped with less than 2 or 4 MB of RAM.
The situation is even worse for above describe examples
because each is run as separate application and each builds
its own copy of model/database (This is not a problem for
real application which registers all publishers and subscribers
to single domain at given node).
ORTE has full support for big and little endian interoperability
provided by IDL and types registration. The XDR serialization
and deserialization is used for all management/control communications.
But orteping uses delivery of 4 byte raw content in the test
without IDL or application local endianess resolution.
This results in byte-reversed numbers print when test is run
between nodes with different endiannes.