1 # Install AFB Websocket CLI client to test the binding.
3 You can test it using afb-client-demo CLI tool provided by the RPM package _libafbwsc-dev_.
5 You can find this package in your build environment, using docker SDK recommended setup the file is `/xdt/build/tmp/deploy/rpm/<your-target-arch>/`.
7 After a successful bitbake build and using Renesas RCar Gen2, Porter, you have to copy the file if your board is connected to your network and you know its IP address:
10 $ scp /xdt/build/tmp/deploy/rpm/cortex15hf_neon/libafbwsc-dev-1.0-r0.cortexa15hf_neon.rpm root@<target_IP>:~
13 Else, you have to copy into the SDcard with the AGL image installed on it.
15 From the docker image copy RPM to the shared directory between docker image and your host:
18 $ cp /xdt/build/tmp/deploy/rpm/cortex15hf_neon/libafbwsc-dev-1.0-r0.cortexa15hf_neon.rpm ~/share
21 Then plugin you SDcard in your Linux host \(Windows can't read ext4 filesystem AGL runs on\) and copy RPM file on it.
23 From your host, identify SDcard block device node here it is **sdc** with the correct capacity automounted by the desktop manager:
28 └─docker-253:0-3146365-pool 253:3 0 100G 0 dm
29 └─docker-253:0-3146365-e9f80849a2681e18549d3a4238cbf031e44052e36cd88a0abf041804b799b61c
30 253:4 0 10G 0 dm /var/lib/docker/devicemapper/mnt/e9f80849a2681e18549d3a4238cbf031e44052e36cd88a0abf041804b799b61c
31 sdb 8:16 0 238.5G 0 disk
32 ├─sdb2 8:18 0 238G 0 part
33 │ └─Shamash-agl 253:1 0 238G 0 lvm /home/claneys/Workspace/agl-docker
34 └─sdb1 8:17 0 500M 0 part /boot
35 sr0 11:0 1 1024M 0 rom
36 loop0 7:0 0 100G 0 loop
37 └─docker-253:0-3146365-pool 253:3 0 100G 0 dm
38 └─docker-253:0-3146365-e9f80849a2681e18549d3a4238cbf031e44052e36cd88a0abf041804b799b61c
39 253:4 0 10G 0 dm /var/lib/docker/devicemapper/mnt/e9f80849a2681e18549d3a4238cbf031e44052e36cd88a0abf041804b799b61c
40 sdc 8:32 1 14.9G 0 disk
41 └─sdc1 8:33 1 2G 0 part /run/media/claneys/97f418a5-612f-44e9-b968-a19505695151
42 sda 8:0 0 931.5G 0 disk
43 ├─sda2 8:2 0 500G 0 part
44 │ ├─Shamash-home 253:2 0 150G 0 lvm /home
45 │ └─Shamash-root 253:0 0 50G 0 lvm /
46 └─sda1 8:1 0 16G 0 part [SWAP]
49 Copy, still from your host:
51 > **CAUTION:** Make sure to sync IO with sync command before unplug your SDcard. It could be corrupted if removed before all pending IO aren't done.
54 $ sudo umount /dev/sdc1
56 $ sudo mount /dev/sdc1 $SDCARD
57 $ sudo cp ~/devel/docker/share/libafbwsc-dev-1.0-r0.cortexa15hf_neon.rpm $SDCARD/home/root
62 Insert the modified SDcard in your Porter board and boot from it. You are ready to go.
64 ## Configure the AGL system
66 ### Virtual CAN device
68 Connected to the target, here is how to load the virtual CAN device driver and set up a new vcan device :
72 # ip link add vcan0 type vcan
73 # ip link set vcan0 up
76 ### CAN device using the USB CAN adapter
78 Using real connection to CAN bus of your car using the USB CAN adapter connected to the OBD2 connector.
80 Once connected, launch `dmesg` command and search which device to use :
85 [ 131.871441] usb 1-3: new full-speed USB device number 4 using ohci-pci
86 [ 161.860504] can: controller area network core (rev 20120528 abi 9)
87 [ 161.860522] NET: Registered protocol family 29
88 [ 177.561620] usb 1-3: USB disconnect, device number 4
89 [ 191.061423] usb 1-2: USB disconnect, device number 3
90 [ 196.095325] usb 1-2: new full-speed USB device number 5 using ohci-pci
91 [ 327.568882] usb 1-2: USB disconnect, device number 5
92 [ 428.594177] CAN device driver interface
93 [ 1872.551543] usb 1-2: new full-speed USB device number 6 using ohci-pci
94 [ 1872.809302] usb_8dev 1-2:1.0 can0: firmware: 1.7, hardware: 1.0
95 [ 1872.809356] usbcore: registered new interface driver usb_8dev
98 Here device is named `can0`.
100 This instruction assuming a speed of 500000kbps for your CAN bus, you can try others supported bitrate like 125000, 250000 if 500000 doesn't work:
103 # ip link set can0 type can bitrate 500000
104 # ip link set can0 up
106 can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
108 can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
109 bitrate 500000 sample-point 0.875
110 tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
111 sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
115 For a Porter board, you'll have your CAN device as `can1` because `can0` already exists as an embedded device.
117 The instructions will be the same:
120 # ip link set can1 type can bitrate 500000
121 # ip link set can1 up
123 can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
125 can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
126 bitrate 500000 sample-point 0.875
127 tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
128 sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
132 ## Configure the binding
134 Configure the binding specifying in the JSON configuration file the CAN device\(s\) that it will to connect to. Edit file _/var/lib/afm/applications/low-can-binding/0.1/can\_buses.json_ and change the CAN device name to the one you will use :
136 Using virtual CAN device as described in the previous chapter:
143 Using real CAN device, this example assume CAN bus traffic will be on can0.
150 On a Porter board there is an embedded CAN device so `can0` already exists.
152 So you might want to use your USB CAN adapter plugged to the OBD2 connector, in this case use `can1`:
159 If you have several specify CAN bus devices use an array:
163 "canbus": [ "can0", "can1" ]
167 > **CAUTION VERY IMPORTANT:** Make sure the CAN bus\(es\) you specify in your configuration file match those specified in your generated source file with the [can-config-generator](http://github.com/iotbzh/can-config-generator).
169 ## Run it, test it, use it !
171 You can run the binding using **afm-util** tool, here is the classic way to go :
174 # afm-util run low-can-binding@0.1
178 You can find instructions to use afm-util tool [here](http://docs.iot.bzh/docs/apis_services/en/dev/reference/af-main/afm-daemons.html#using-afm-util), as well as documentation about Application Framework.
180 But you can't control nor interact with it because you don't know security token that **Application Framework** gaves it at launch.
182 So, to test it, it is better to launch the binding manually. In the following example, we will use port **1234** and left empty security token for testing purpose:
185 # afb-daemon --ldpaths=/usr/lib/afb:/var/lib/afm/applications/low-can-binding/0.1/libs/ --rootdir=/var/lib/afm/applications/low-can-binding/0.1/ --port=1234 --token=
186 NOTICE: binding [/usr/lib/afb/afb-dbus-binding.so] calling registering function afbBindingV1Register
187 NOTICE: binding /usr/lib/afb/afb-dbus-binding.so loaded with API prefix dbus
188 NOTICE: binding [/usr/lib/afb/authLogin.so] calling registering function afbBindingV1Register
189 NOTICE: binding /usr/lib/afb/authLogin.so loaded with API prefix auth
190 NOTICE: binding [/var/lib/afm/applications/low-can-binding/0.1/libs//low-can-binding.so] calling registering function afbBindingV1Register
191 NOTICE: binding /var/lib/afm/applications/low-can-binding/0.1/libs//low-can-binding.so loaded with API prefix low-can
192 NOTICE: Waiting port=1234 rootdir=/var/lib/afm/applications/low-can-binding/0.1/
193 NOTICE: Browser URL= http:/*localhost:1234
194 NOTICE: vcan0 device opened and reading {binding low-can}
195 NOTICE: Initialized 1/1 can bus device(s) {binding low-can}
198 On another terminal, connect to the binding using previously installed _**AFB Websocket CLI**_ tool:
201 # afb-client-demo ws://localhost:1234/api?token=
204 You will be on an interactive session where you can communicate directly with the binding API.
206 The binding provides at this moment 2 verbs, _subscribe_ and _unsubscribe_, which can take argument by a JSON **event** object.
208 The argument value is the CAN message **generic\_name** as described in the JSON file used to generate cpp file for the binding.
210 To use the _**AFB Websocket CLI**_ tool, a command line will be like the following :
213 <api> <verb> <arguments>
218 * API : _**low-can**_.
219 * Verb : _**subscribe**_ or _**unsubscribe**_
220 * Arguments : _**{ "event": "driver.doors.open" }**_
222 ### Subscription and unsubscription
224 You can ask to subscribe to chosen CAN event with a call to _subscribe_ API verb with the CAN messages name as JSON argument.
226 > **NOTE:** If no argument is provided, then you'll subscribe to all signals at once.
228 For example from a websocket session:
231 low-can subscribe { "event": "doors.driver.open" }
232 ON-REPLY 1:low-can/subscribe: {"jtype":"afb-reply","request":{"status":"success","uuid":"a18fd375-b6fa-4c0e-a1d4-9d3955975ae8"}}
235 Subscription and unsubscription can take wildcard in their _event_ value.
237 To receive all doors events :
240 low-can subscribe { "event" : "doors*" }
241 ON-REPLY 1:low-can/subscribe: {"jtype":"afb-reply","request":{"status":"success","uuid":"511c872e-d7f3-4f3b-89c2-aa9a3e9fbbdb"}}
244 Then you will receive an event each time a CAN message is decoded for the event named _doors.driver.open_
247 ON-EVENT low-can/messages.doors.driver.open({"event":"low-can\/messages.doors.driver.open","data":{"name":"messages.doors.driver.open","value":true},"jtype":"afb-event"})
250 Notice that event shows you that the CAN event is named _messages.doors.driver.open_ but you ask for event about _doors.driver.open_.
252 This is because all CAN messages or diagnostic messages are prefixed by the JSON parent node name, **messages** for CAN messages and **diagnostic\_messages** for diagnostic messages like OBD2.
254 This will let you subscribe or unsubcribe to all signals at once, not recommended, and better make filter on subscribe operation based upon their type. Examples:
257 low-can subscribe { "event" : "*speed*" } --> will subscribe to all messages with speed in their name. Search will be make without prefix for it.
258 low-can subscribe { "event" : "speed*" } --> will subscribe to all messages begin by speed in their name. Search will be make without prefix for it.
259 low-can subscribe { "event" : "messages*speed*" } --> will subscribe to all CAN messages with speed in their name. Search will be on prefixed messages here.
260 low-can subscribe { "event" : "messages*speed" } --> will subscribe to all CAN messages ending with speed in their name. Search will be on prefixed messages here.
261 low-can subscribe { "event" : "diagnostic*speed*" } --> will subscribe to all diagnostic messages with speed in their name. Search will be on prefixed messages here.
262 low-can subscribe { "event" : "diagnostic*speed" } --> will subscribe to all diagnostic messages ending with speed in their name. Search will be on prefixed messages here.
265 You can stop receiving event from it by unsubscribe the signal the same way you did for subscribe
268 low-can unsubscribe { "event": "doors.driver.open" }
269 ON-REPLY 2:low-can/unsubscribe: {"jtype":"afb-reply","request":{"status":"success"}}
270 low-can unsubscribe { "event" : "doors*" }
271 ON-REPLY 3:low-can/unsubscribe: {"jtype":"afb-reply","request":{"status":"success"}}
274 ### Using CAN utils to monitor CAN activity
276 You can watch CAN traffic and send custom CAN messages using can-utils preinstalled on AGL target.
278 To watch watch going on a CAN bus use:
284 Or for an USB CAN adapter connected to porter board:
290 Send a custom message:
293 # cansend can0 ID#DDDDAAAATTTTAAAA
296 You can also replay a previously dumped CAN logfiles. These logfiles can be found in _can_samples_ directory under Git repository. Following examples use a real trip from an Auris Toyota car.
298 Trace has been recorded from a CAN device `can0` so you have to map it to the correct one you use for your tests.
300 Replay on a virtual CAN device `vcan0`:
302 # canplayer -I trip_test_with_obd2_vehicle_speed_requests vcan0=can0
305 Replay on a CAN device `can0`:
307 # canplayer -I trip_test_with_obd2_vehicle_speed_requests can0
310 Replay on a CAN device `can1` (porter by example):
312 # canplayer -I trip_test_with_obd2_vehicle_speed_requests can1=can0