Keep the colleague's microbu-esp32c5 tree in this repository
obu-firmware builds against vanetza-idf from microbu-esp32c5/external, but that tree was gitignored, so a clone of this repository could not build the firmware it ships. It is now committed here as ordinary files in its own folder, microbu-esp32c5/: the colleague's commit cf4b99f plus the V2X2MAP bridge's signature verification (--trust) used on the bench. Nothing is fetched from or pushed to the colleague's repository; this repository and its remotes carry everything. The folder's own .gitignore keeps build output, downloaded components and private key material out, as it did there; the committed file set is identical to that repository's tracked files. The ESP32-C5 is still flashed from obu-firmware/, which only takes vanetza-idf from microbu-esp32c5/, so the two stay separate folders. FLASHING.md says how to take a newer version of the colleague's tree (copy it over the folder, rebuild, test, commit).
This commit is contained in:
Ashin Walpola
@@ -0,0 +1,33 @@
|
||||
Title: Building for generic ARM64 device
|
||||
|
||||
# Building Vanetza for generic ARM64 device
|
||||
|
||||
This document describes building Vanetza for arm64 architecture.
|
||||
Steps for building Vanetza for arm64 are very similar to build for Cohda MK5 devices (you can see steps in the [building for Cohda MK5 document](cohda-sdk-build.md)).
|
||||
|
||||
## Cross-compiler
|
||||
|
||||
You should have GNU C/C++ cross-compiler for the arm64 architecture installed. For Debian-based distros, this can be installed by command `sudo apt install g++-aarch64-linux-gnu`.
|
||||
|
||||
## Vanetza build dependencies
|
||||
|
||||
Please see [this document](cross-compile-dependencies.md) about cross-compiling Vanetza's dependencies.
|
||||
|
||||
## Compile Vanetza
|
||||
|
||||
We assume you have copy of the Vanetza repository in your home directory at `$HOME`.
|
||||
Create a build directory and tell CMake to use the cross-compiler installed on your machine and to look up additional dependencies in `vanetza-deps`:
|
||||
|
||||
:::shell
|
||||
mkdir vanetza/vanetza-build
|
||||
cd vanetza/vanetza-build
|
||||
cmake .. \
|
||||
-DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchain-ARM64.cmake \
|
||||
-DCMAKE_FIND_ROOT_PATH=$HOME/vanetza-deps \
|
||||
-DCMAKE_INSTALL_RPATH=\$ORIGIN/../lib \
|
||||
-DCMAKE_INSTALL_PREFIX=$HOME/vanetza-dist \
|
||||
-DBUILD_SOCKTAP=ON
|
||||
make
|
||||
|
||||
This builds the Vanetza libraries and *socktap* example as well. When you do `make install`, binaries are copied to `$HOME/vanetza-dist`. You can copy the binary with libraries to the device now.
|
||||
|
||||
@@ -0,0 +1,63 @@
|
||||
Title: Building for Autotalks devices
|
||||
|
||||
# Building Vanetza for Autotalks Craton using Autotalks SDK
|
||||
|
||||
This document describes building Vanetza for the Autotalks device. There is a difference between building for Craton and Secton.
|
||||
Steps for building Vanetza for Autotalks Craton are very similar to build for Cohda MK5 devices (you can see steps in the [building for Cohda MK5 document](cohda-sdk-build.md)). Difference is that there is no virtual machine provided from Autotalks.
|
||||
|
||||
Autotalks SDK can used only in the `socktap` example, so you must always compile it when you want the SDK.
|
||||
|
||||
## Autotalks SDK
|
||||
|
||||
SDK is shipped with Autotalks devices, you should have obtained one. Until Release 18, it was recommended to build the SDK in Ubuntu 16.04, now Ubuntu 18.04 or 20.04 should be used; it was tested on the latter. For Secton, there is used gcc version 9.4.0, for Craton `arm-poky-linux-gnueabi-g++` version 11.2.0, that is installed with the poky container.
|
||||
|
||||
### Code corrections
|
||||
|
||||
With Autotalks SDK version <= 5.15.0, you will have to do a correction in file `autotalks_*_api/include/atlk/ddm_service.h` on line 615 and add there an explicit cast to `stats_tlv_t *`. Without this, you won't be able to build the project because of the `-fpermissive` flag. As of version 5.16.0, this problem is fixed.
|
||||
|
||||
In version 5.17 (Release 18), there are another problems:
|
||||
* In autotalks_{craton,secton}_api/include/common/counters.h change line 110 from `uint8_t data[]` to `uint8_t* data`
|
||||
* In autotalks_{craton,secton}_api/include/atlk/generic_compensator.h, there is missing `}` for the `extern "C"` directive (this should be solved in newer SDK)
|
||||
|
||||
Another thing you must note is in the initialization in the `socktap` example. The initialization code in `v2x_device_init()` was used directly from the example in the Autotalks SDK, therefore it should not be distributed with the library. You will have to write it yourself, but it really is almost the same as `main()` function in the basic example from the SDK.
|
||||
|
||||
In the initialization, there is a define for `SECTON_NET_NAME`. This is a network interface name which determines how is the SoC seen in Linux. It should be *enx0002ccf00006* by default, but if it is set to something else, you can change this define. You can use `ifconfig` output to determine the actual name (see Autotalks documentation for more details).
|
||||
|
||||
## Vanetza build dependencies
|
||||
|
||||
Please see [this document](cross-compile-dependencies.md) about cross-compiling Vanetza's dependencies.
|
||||
This guide was tested with precompiled libraries downloadable [from here](cohda-sdk-build.md).
|
||||
|
||||
## Compile Vanetza
|
||||
|
||||
### Compiling for Craton
|
||||
We assume you have copy of the Vanetza repository in your home directory at `$HOME`.
|
||||
Furthermore, there should be a symbolic link named `autotalks_craton_api` in your home directory, that links to the root of Craton SDK (e.g., from `/home/your_user/autotalks_craton_api` to the API compilation directory). If you have Poky toolchain installed in other directory than /opt/poky-craton2/4.0.1 (e.g. /tools/gcc/arm/new_toolchain as suggested by Autotalks), change the path in cmake/Toolchain-Autotalks-Craton.cmake.
|
||||
Create a build directory and tell CMake to use the cross-compiler installed on your machine and to look up additional dependencies in `vanetza-deps`:
|
||||
|
||||
:::shell
|
||||
mkdir vanetza/vanetza-build
|
||||
cd vanetza/vanetza-build
|
||||
cmake .. \
|
||||
-DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchain-Autotalks-Craton.cmake \
|
||||
-DCMAKE_FIND_ROOT_PATH=$HOME/vanetza-deps \
|
||||
-DCMAKE_INSTALL_RPATH=\$ORIGIN/../lib \
|
||||
-DCMAKE_INSTALL_PREFIX=$HOME/vanetza-dist \
|
||||
-DBUILD_SOCKTAP=ON \
|
||||
-DSOCKTAP_WITH_AUTOTALKS=ON
|
||||
make
|
||||
|
||||
This builds the Vanetza libraries and *socktap* example as well. When you do `make install`, binaries are copied to `$HOME/vanetza-dist`. You can copy the binary with libraries to the Craton now. You should start the binary in the same directory as you would be running code from Autotalks examples (it needs their configuration files). You must run the binary with parameter `-l autotalks` for correct choosing of the link layer.
|
||||
|
||||
### Compiling for Secton
|
||||
We assume you have copy of the Vanetza repository in your home directory at `$HOME`.
|
||||
Furthermore, there should be a symbolic link named `autotalks_secton_api` in your home directory, that links to the root of Secton SDK (e.g., from `/home/your_user/autotalks_secton_api` to the API compilation directory). The build steps are then identical with the ones described in [How to build](../how-to-build.md). Just note that for using Autotalks SDK you should use enable compilation of socktap, e.g. like this:
|
||||
|
||||
:::shell
|
||||
cmake .. \
|
||||
-DBUILD_SOCKTAP=ON \
|
||||
-DSOCKTAP_WITH_AUTOTALKS=ON
|
||||
make
|
||||
|
||||
Binary then can be ran from the same directory you would be running the Autotalks example (it needs their configuration files). You must run the binary with parameter `-l autotalks` for correct choosing of the link layer.
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
Title: Building for Cohda MK5
|
||||
|
||||
# Building Vanetza for Cohda MK5 using Cohda SDK
|
||||
|
||||
This document describes step-by-step how to build Vanetza using the Cohda SDK.
|
||||
At the end, we have Vanetza libraries and its *socktap* tool cross-compiled for Cohda MK5 devices.
|
||||
|
||||
|
||||
## Cohda SDK
|
||||
|
||||
[Cohda SDK](http://www.cohdawireless.com/solutions/sdk/) is provided by [Cohda Wireless](http://www.cohdawireless.com) along with their [MK5](http://www.cohdawireless.com/solutions/hardware/mk5-obu/) units.
|
||||
Since you are reading this build how-to you most likely already possess one of these units.
|
||||
This how-to has been created for the Release 16 of the SDK.
|
||||
The following instructions are expected to be done within the virtual machine (VM) provided by Cohda.
|
||||
|
||||
Please make sure that a recent GCC version for the *arm-linux-gnueabihf* target is installed in this VM.
|
||||
I recommend to deinstall `g++-4.8-arm-linux-gnueabihf` entirely as this version supports C++11 only poorly.
|
||||
`g++-5-arm-linux-gnueabihf` is known to work well.
|
||||
|
||||
## Vanetza build dependencies
|
||||
|
||||
Compilation of Vanetza depends on several third-party libraries, e.g. Boost, GeographicLib and Crypto++ as mentioned in Vanetza's README.
|
||||
Steps to compile those dependencies are described in our [cross-compile dependencies document](cross-compile-dependencies.md).
|
||||
For the sake of simplicity, we provide the pre-compiled dependencies for Cohda MK5 as compressed archives.
|
||||
|
||||
| Archive | Content | MD5 checksum |
|
||||
| ------- | ------- | ------------ |
|
||||
| [vanetza-deps-20171129.tar.bz2](https://app.box.com/s/zu0q7i569xsuu0qno378axwnf5w5v3op) | Boost 1.65.1, GeographicLib 1.49, Crypto++ 5.6.5 | `853a2833fde0266674d4a4dbe22fe7ef` |
|
||||
| [vanetza-deps-20191126.tar.bz2](https://app.box.com/s/hrhdl4ydx24ruak3fsfk6hlh1m7fa4ox) | Boost 1.71.0, GeographicLib 1.50, Crypto++ 8.2.0 | `1d8832949673e3935f72aac6c00a132d` |
|
||||
|
||||
At the moment, these archives are hosted on [box.com](https://www.box.com).
|
||||
We recommend to download the most recent archive in general.
|
||||
Before the next step, extract the archive's content into `/home/duser/vanetza-deps`.
|
||||
|
||||
|
||||
## Compile Vanetza
|
||||
|
||||
We assume you have copy of the Vanetza repository in your home directory at `/home/duser/vanetza`.
|
||||
Create a build directory and tell CMake to use the cross-compiler installed in the Cohda VM and to look up additional dependencies in `vanetza-deps`:
|
||||
|
||||
:::shell
|
||||
mkdir vanetza-build
|
||||
cd vanetza-build
|
||||
cmake $HOME/vanetza \
|
||||
-DCMAKE_TOOLCHAIN_FILE=$HOME/vanetza/cmake/Toolchain-Cohda-MK5.cmake \
|
||||
-DCMAKE_FIND_ROOT_PATH=$HOME/vanetza-deps \
|
||||
-DCMAKE_INSTALL_RPATH=\$ORIGIN/../lib \
|
||||
-DCMAKE_INSTALL_PREFIX=$HOME/vanetza-dist
|
||||
make
|
||||
|
||||
This builds the Vanetza libraries only. Enable the **BUILD_SOCKTAP** CMake option if you want to try *socktap* as well. Additionally, enable the **SOCKTAP_WITH_COHDA_LLC** CMake option if you want *socktap* to use 802.11p via Cohda's LLC network interface on your MK5.
|
||||
Fortunately, *socktap*'s additional *gpsd* dependency is already shipped with the Cohda SDK itself.
|
||||
You only need to specify its location by setting **GPS_LIBRARY** to `/home/duser/mk5/stack/v2x-lib/lib/mk5/libgps_static.a` and **GPS_INCLUDE_DIR** to `/home/duser/mk5/stack/v2x-lib/include`.
|
||||
Please note, that *socktap* does not make use of Cohda's socket API currently.
|
||||
We might provide a modified *socktap* application in the future.
|
||||
|
||||
|
||||
## Deployment
|
||||
|
||||
1. `make install`
|
||||
|
||||
Compile and link *socktap* with correct RPATH, binaries are copied to `$HOME/vanetza-dist`.
|
||||
|
||||
2. copy runtime dependencies
|
||||
|
||||
Copy the shared object files (*.so) from `$HOME/vanetza-deps/libs` onto the MK5, e.g. to `/home/user/vanetza/lib`.
|
||||
|
||||
3. copy *socktap* onto MK5
|
||||
|
||||
Copy the files from `$HOME/vanetza-dist` to `/home/user/vanetza` on the MK5, i.e. Vanetza libraries and its dependency libraries are located in the same directory.
|
||||
You can execute *socktap* located at `/home/user/vanetza/bin/socktap` and it will look up its shared objects in the sibling `lib` directory. If you have enabled the **SOCKTAP_WITH_COHDA_LLC** CMake option, make sure to give *socktap* the name of a Cohda LLC network interface via the command line option `--interface`/`-i` (e.g. cw-llc0).
|
||||
+55
@@ -0,0 +1,55 @@
|
||||
# Cross-Compilation of Dependencies
|
||||
|
||||
This document summarises a few hints for cross-compiling Vanetza's dependencies.
|
||||
Please note, that cross-compiling is not relevant for you if you plan to use Vanetza on the same system you have built it on.
|
||||
|
||||
|
||||
## Boost
|
||||
|
||||
Create a configuration file for Boost.Build in your home directory at `$HOME/user-config.jam` and add following line to it:
|
||||
|
||||
using gcc : arm : arm-linux-gnueabihf-g++ ;
|
||||
|
||||
The *install* stage does not work in Boost 1.71.0 (and 1.70.0) when cross-compiling.
|
||||
A workaround for this issue is to remove following lines from `tools/build/src/tools/common.jam` (around line 976):
|
||||
|
||||
# From GCC 5, versioning changes and minor becomes patch
|
||||
if $(tag) = gcc && [ numbers.less 4 $(version[1]) ]
|
||||
{
|
||||
version = $(version[1]) ;
|
||||
}
|
||||
|
||||
# Ditto, from Clang 4
|
||||
if ( $(tag) = clang || $(tag) = clangw ) && [ numbers.less 3 $(version[1]) ]
|
||||
{
|
||||
version = $(version[1]) ;
|
||||
}
|
||||
|
||||
Then, the required libraries can be built and installed at given *prefix* path:
|
||||
|
||||
:::shell
|
||||
./b2 --prefix=$HOME/vanetza-deps --with-date_time --with-program_options --with-system --no-samples --no-tests variant=release link=shared cxxstd=11 install
|
||||
|
||||
|
||||
## Crypto++
|
||||
|
||||
Version 8.2 can be cross-compiled with the provided `GNUmakefile-cross` makefile.
|
||||
|
||||
:::shell
|
||||
export CXX=arm-linux-gnueabihf-g++
|
||||
export PREFIX=$HOME/vanetza-deps
|
||||
export HAS_SOLIB_VERSION=1
|
||||
make -f GNUmakefile-cross shared
|
||||
make -f GNUmakefile-cross install
|
||||
|
||||
|
||||
## GeographicLib
|
||||
|
||||
Following steps have been tested with version 1.50.
|
||||
`$VANETZA` refers to the root directory of this repository.
|
||||
|
||||
:::shell
|
||||
mkdir build.arm
|
||||
cd build.arm
|
||||
cmake .. -DCMAKE_TOOLCHAIN_FILE=$VANETZA/cmake/Toolchain-Cohda-MK5.cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$HOME/vanetza-deps
|
||||
make install
|
||||
@@ -0,0 +1,52 @@
|
||||
# Building for cube:evk
|
||||
|
||||
The cube:evk from [cubesys - an nfiniity company](https://www.nfiniity.com/#hardware-section) fully supports the Vanetza stack and its socktap application. An integrated V2X module listens for requests whether from a local or remote application. The communication protocol between host and V2X module is covered in Google's Protobuf that is used in the respective link-layer implementation.
|
||||
|
||||
## Configuration
|
||||
Before building and running socktap you need to configure the V2X module and the WiFi once.
|
||||
|
||||
### V2X Radio Configuration - C-V2X or DSRC
|
||||
First of all select your desired radio configuration using the `v2xconfig` tool on the cube:evk:
|
||||
|
||||
:::shell
|
||||
# start dsrc or cv2x and enable auto-start
|
||||
cube> v2xconfig start enable dsrc
|
||||
|
||||
### Connect to your local WiFi
|
||||
This is only needed for the wireless remote radio mode.
|
||||
|
||||
:::shell
|
||||
cube> sudo nmcli dev wifi connect '<ssid>' password '<password>'
|
||||
# get your ip
|
||||
cube> ip a
|
||||
|
||||
## Building and Running Socktap for Wireless Remote Radio Mode
|
||||
You can build and run socktap directly on your personal computer (host) and select `cube-evk` as link-layer. Further, gpsd daemon is running on the cube:evk that can feed socktap with GNSS data.
|
||||
|
||||
In `wireless remote radio mode` you develop, debug and run Vanetza/socktap on your personal computer. There is no need to flash or transfer the application onto your cube:evk. The V2X radio on the cube:evk listens for incoming requests from remote. Both devices need to be pingable from each other only.
|
||||
|
||||
:::shell
|
||||
host> mkdir build && cd build
|
||||
host> cmake -DBUILD_SOCKTAP=ON -DSOCKTAP_WITH_CUBE_EVK=ON ..
|
||||
|
||||
# use fix position data
|
||||
host> ./bin/socktap -l cube-evk -p static --cube-ip <cube-ip>
|
||||
|
||||
# use the ublox module on the cube:evk for positioning data
|
||||
host> ./bin/socktap -l cube-evk -p gpsd --gpsd-host <cube-ip> --cube-ip <cube-ip>
|
||||
|
||||
Moreover, the integrated LTE module allows the user to do field tests with the cube:evk from remote.
|
||||
|
||||
## Building and Running Socktap on the cube:evk
|
||||
You can also build and run socktap on the cube:evk itself and it will connect to the local V2X module.
|
||||
|
||||
:::shell
|
||||
cube> mkdir build && cd build
|
||||
cube> cmake -DBUILD_SOCKTAP=ON -DSOCKTAP_WITH_CUBE_EVK=ON ..
|
||||
|
||||
# use fix position data
|
||||
cube> ./bin/socktap -l cube-evk -p static
|
||||
|
||||
# use the ublox module on the cube:evk for positioning data
|
||||
cube> ./bin/socktap -l cube-evk -p gpsd --gpsd-host 127.0.0.1
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
Title: Generate code from ASN.1
|
||||
|
||||
# How to generate code from ASN.1 definitions
|
||||
|
||||
Generating new ASN.1 structs based on ASN.1 definitions can be a daunting task requiring the appropriate ASN.1 compiler.
|
||||
In particular, we use the **asn1c** fork maintained by [mouse07410](https://github.com/mouse07410/asn1c).
|
||||
|
||||
Though the Vanetza repository comes with various pre-generated ASN.1 messages, you may want to add further or revised versions of these messages.
|
||||
In this case, the following steps guide you how to generate code from ASN.1 definitions on your own.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
We have streamlined the process of installing and using **asn1c** by relying on a Docker container.
|
||||
|
||||
1. Install Docker on your system
|
||||
2. Build the Docker container from the `vanetza/asn1/Dockerfile` as `vanetza-asn1c:latest`
|
||||
|
||||
```bash
|
||||
docker build --tag vanetza-asn1c:latest vanetza/asn1
|
||||
```
|
||||
|
||||
## Generate ASN.1 code
|
||||
|
||||
Our CMake build environment comes with a `generate_asn1c` code generation target.
|
||||
This target is available if the the `VANETZA_ASN1_WITH_ASN1C` CMake option is enabled.
|
||||
When you invoke this target, CMake will run the Docker container for you with suitable arguments.
|
||||
You can specify a custom image by modifying the `VANETZA_ASN1C_CONTAINER` CMake cache variable.
|
||||
By default, CMake will use the `vanetza-asn1c:latest` image.
|
||||
|
||||
1. Update your copy of Vanetza with the new or updated ASN.1 definitions
|
||||
2. Update the **CMakeLists.txt** file at **vanetza/asn1** accordingly
|
||||
3. Create a fresh build directory and configure CMake with enabled ASN.1 targets
|
||||
4. Invoke **asn1c** and compile Vanetza with newly generated code
|
||||
|
||||
```bash
|
||||
# Create a new build directory at the project's root
|
||||
mkdir build.asn1 && cd build.asn1
|
||||
|
||||
# Configure the build with enabled ASN.1 targets and retrieval of ISO ASN.1 files
|
||||
cmake -DVANETZA_ASN1_WITH_ASN1C=ON -DVANETZA_ASN1_WITH_ISO=ON ..
|
||||
|
||||
# Invoke the target calling asn1c
|
||||
make generate_asn1c
|
||||
|
||||
# Compile Vanetza with newly generated ASN.1 code
|
||||
cmake --build .
|
||||
```
|
||||
Reference in New Issue
Block a user