docs/4_APIs_and_Services/4.5_Message_Signaling/2_AGL_Service_CAN_Low_Level/2_Installation.md

   1 ---
   2 edit_link: ''
   3 title: Installation Guide
   4 origin_url: >-
   5   https://git.automotivelinux.org/apps/agl-service-can-low-level/plain/docs/2-Installation.md?h=master
   6 ---
   7
   8 <!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/apis_services/master/agl-service-can-low-level-developer-guides-api-services-book.yml -->
   9
  10 # Prerequisites
  11
  12 * An AGL system installed with latest Daring Dab version with latest Application
  13 framework version >= 0.6.
  14
  15 * Make sure you built the AGL generator else you will not be able to generate custom low-level CAN binding.
  16
  17 It will produce a _application-generated.cpp_ file to paste in the source, _CAN-binder/low-can-binding/binding/_, directory.
  18
  19 * Make sure you already set up the AGL SDK using the following [Download or Build Your SDK Installer](../../../getting_started/reference/getting-started/app-workflow-sdk.html). Alternatively, please refer to official guides available on [AGL Developer Site](../../../devguides).
  20
  21 If you need to have the graphic stack inside your SDK, you have to prepare your environment with the **iotbzh**, or **Daring Dab** flavor using _prepare_meta_ tool. To do so, run the following command in your docker image in the step 4 in place of `... [ prepare build environment ] ...`:
  22
  23 > **NOTE** These commands assume that proprietary graphic drivers for Renesas Porter board are located in _/home/devel/share/proprietary-renesas-rcar_ directory.
  24
  25 ```bash
  26 prepare_meta -f iotbzh -o /xdt -l /home/devel/mirror -p /home/devel/share/proprietary-renesas-rcar/ -t m3ulcb -e wipeconfig -e rm_work -e cleartemp
  27 /xdt/build/m3ulcb/agl-init-build-env
  28 ```
  29
  30 * (Optionnal) An [USB CAN adapter](https://shop.8devices.com/index.php?route=product/product&path=67&product_id=54) connected to connector through the [right cable](https://www.mouser.fr/ProductDetail/EasySync/OBD-M-DB9-F-ES?qs=pLQRQR43dtrcAQQLCUAIxA%3D%3D) if you want to connect to a real car through the OBD2 connector.
  31
  32 <!-- pagebreak -->
  33
  34 # Getting started
  35
  36 ## CAN config generator usage
  37
  38 ### Build requirements
  39
  40 * CMake version 3.3 or later
  41 * G++, Clang++ or any C++11 compliant compiler.
  42
  43 ### Compile
  44
  45 ```bash
  46 source /xdt/sdk/environment-setup-aarch64-agl-linux
  47 export PATH=$PATH:/xdt/sdk/sysroots/x86_64-aglsdk-linux/usr/bin
  48 export WD=$(pwd)
  49 git clone --recursive https://gerrit.automotivelinux.org/gerrit/apps/agl-service-can-low-level -b Renesas_delivery_Q2
  50 git clone --recursive https://gerrit.automotivelinux.org/gerrit/apps/low-level-can-generator
  51 cd ${WD}/low-level-can-generator
  52 mkdir -p build
  53 cd build
  54 cmake -G "Unix Makefiles" ..
  55 make
  56 ```
  57
  58 ### Naming convention
  59
  60 We chose a doted naming convention because it's a well know schema.
  61
  62 It separates and organize names into hierarchy. From the left to right, you describe your names using the more common ancestor at the left then more you go to the right the more it will be accurate.
  63
  64 Let's take an example, here is an example about standard PID name following this convention:
  65
  66 ```
  67 engine.load
  68 engine.coolant.temperature
  69 fuel.pressure
  70 intake.manifold.pressure
  71 engine.speed
  72 vehicle.speed
  73 intake.air.temperature
  74 mass.airflow
  75 throttle.position
  76 running.time
  77 EGR.error
  78 fuel.level
  79 barometric.pressure
  80 commanded.throttle.position
  81 ethanol.fuel.percentage
  82 accelerator.pedal.position
  83 hybrid.battery-pack.remaining.life
  84 engine.oil.temperature
  85 engine.torque
  86 ```
  87
  88 > **NOTE** It's recommended that you follow this naming convention to named your CAN signals.
  89 >
  90 > There is only character `*` that is forbidden in names because it's used as wildcard for subscription and unsubscription.
  91 >
  92 > This described in the below chapter.
  93
  94 ### Available decoder
  95
  96 You can use some basic decoder provided by default by the binding which are:
  97
  98 * ***decoder_t::decode_noop*** : Default decoder if not specified, return raw value from signal's bitfield.
  99 * ***decoder_t::decode_boolean*** : Coerces a numerical value to a boolean.
 100 * ***decoder_t::decode_state*** : Find and return the corresponding string state for a CAN signal's raw integer value.
 101
 102 ### Generating JSON from Vector CANoe Database
 103
 104 > **CAUTION** This chapter has not been tested since it haven't necessary automotive tools for that.
 105
 106 If you use CANoe to store your `gold standard` CAN signal definitions, you may be able to use the OpenXC `xml_to_json.py` script to make your JSON for you. First, export the Canoe .dbc file as XML - you can do this with Vector CANdb++. Next, create a JSON file according to the format defined above, but only define:
 107
 108 * CAN messages.
 109 * Name of CAN signals within messages and their generic_name.
 110 * Optionnaly name of diagnostic messages and their name.
 111
 112 To install the OpenXC utilities and runs `xml_to_json.py` script:
 113
 114 ```bash
 115 sudo pip install openxc
 116 cd /usr/local/lib/python2.7/dist-packages/openxc/generator
 117 ```
 118
 119 Assuming the data exported from Vector is in `signals.xml` and your minimal mapping file is `mapping.json`, run the script:
 120
 121 ```bash
 122 python -m openxc.utils ./xml_to_json.py signals.xml mapping.json signals.json
 123 ```
 124
 125 The script scans `mapping.json` to identify the CAN messages and signals that you want to use from the XML file. It pulls the neccessary details of the messages (bit position, bit size, offset, etc) and outputs the resulting subset as JSON into the output file, `signals.json`.
 126
 127 The resulting file together with `mapping.json` will work as input to the code generation script.
 128
 129 ### Generate your config file
 130
 131 To generate your config file you just have to run the generator using the `-m` option to specify your JSON file.
 132
 133 ```bash
 134 ./can-config-generator -m ../tests/basic.json -o application-generated.cpp
 135 ```
 136
 137 If you omit the `-o` option, then code is generated on the stdout.
 138 You also can specify a header and a footer file.
 139 These files must be valid C++ fragment as long as they will be inserted as is.
 140 Use the `-h` option to display help.
 141
 142 > **CAUTION:** Each `diagnostic_message` must define the same `bus` as the binding will use only one bus.
 143
 144 ### Supported OpenXC items
 145
 146 About now, compliance with OpenXC reference is in progress, can-config-generator and CAN\_signaling will implement them soon.
 147 `initializers`, `loopers`, `commands` and `handlers` nodes are ignored for now.
 148
 149 This generator will follow OpenXC support status of the low level CAN signaling binding.
 150
 151 > **NOTE**: The `buses` item will not be supported by this generator because the binding use another way to declare and configure buses. Please refer to the binding's documentation.
 152
 153 ## Compile and install the binding
 154
 155 ### Build requirements
 156
 157 * Kernel >= 4.8
 158 * CMake version 3.3 or later
 159 * G++, Clang++ or any C++11 compliant compiler.
 160
 161 ### Compile
 162
 163 Clone the binding repository, copy the generated file and updated the git submodules.
 164
 165 Execute the following commands from this repository:
 166
 167 ```bash
 168 cd ${WD}/agl-service-can-low-level
 169 cp ${WD}/low-level-can-generator/build/application-generated.cpp ../low-can-binding/binding
 170 ```
 171
 172 ### Installation
 173
 174 ```bash
 175 cd ${WD}/agl-service-can-low-level
 176 mkdir build
 177 cd build
 178 cmake ..
 179 make
 180 make widget
 181 ```
 182
 183 To install it manually, you need to copy the _low-can-service.wgt_ file on your target, then from it execute the following commands :
 184
 185 On your host, to copy over the network :
 186
 187 ```bash
 188 scp low-can-service.wgt root@<target_IP>:~
 189 ```
 190
 191 On the target, assuming _**wgt**_ file is in the root home directory:
 192
 193 ```bash
 194 afm-util install low-can-service.wgt
 195 { "added": "low-can-service@4.0" }
 196 ```