User Tools

Site Tools


agl-distro:sep2017-can-f2f

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
agl-distro:sep2017-can-f2f [2017/09/11 07:56]
claneys adding meetings notes
agl-distro:sep2017-can-f2f [2017/09/11 08:03] (current)
claneys
Line 82: Line 82:
   * All day: Social networking   * All day: Social networking
  
-Meeting notes +==== Meeting notes ====
-=============+
  
 CAN F2F meeting summary - Vannes - September 2017 CAN F2F meeting summary - Vannes - September 2017
  
-Transport as a plugin +=== Transport as a plugin ​=== 
----------------------+
 We all agree on separation of the transport layer from low-level CAN binding and to load it as a plugin depending on the need of the binding. ​ We all agree on separation of the transport layer from low-level CAN binding and to load it as a plugin depending on the need of the binding. ​
  
Line 97: Line 96:
 So far, a transport plugin only needs to implement simple functions: '​open'/'​close'/'​read'/'​write'​. Configuration has to made by sending a header message with or without can_data, just like a BCM CAN socket is configured (see [1][2]). So far, a transport plugin only needs to implement simple functions: '​open'/'​close'/'​read'/'​write'​. Configuration has to made by sending a header message with or without can_data, just like a BCM CAN socket is configured (see [1][2]).
  
-High level binding +=== High level binding ​=== 
-------------------+
 Second, we need a "​high"​ level binding that should understand signals coming from different sources. As we separate transport from binding, this is natural to think that we need to gather and be able to compose higher signals from the raw signals provided by the low level. ​ Second, we need a "​high"​ level binding that should understand signals coming from different sources. As we separate transport from binding, this is natural to think that we need to gather and be able to compose higher signals from the raw signals provided by the low level. ​
  
Line 109: Line 108:
 Development began on Github[3]. Development began on Github[3].
  
-Simulation +=== Simulation ​=== 
-----------+
 On the simulation, test & benchmark side, Kusakabe-san already defined an AGL CAN signals bundle that he uses for his test and simulation [4]. CAN signals have been extracted in XML files and converted into JSON OpenXC format. This could be used with the low-can service (to be checked). Maybe Kusakabe-san could provide candump files scenario if it is already available or we can use CANdevStudio or even write a small piece of code to play some basic scenarios. CANdevStudio is a quick and easy way to do that if it supports can-utils log format. Then we will all have the same base to make our tests and benchmarks.  On the simulation, test & benchmark side, Kusakabe-san already defined an AGL CAN signals bundle that he uses for his test and simulation [4]. CAN signals have been extracted in XML files and converted into JSON OpenXC format. This could be used with the low-can service (to be checked). Maybe Kusakabe-san could provide candump files scenario if it is already available or we can use CANdevStudio or even write a small piece of code to play some basic scenarios. CANdevStudio is a quick and easy way to do that if it supports can-utils log format. Then we will all have the same base to make our tests and benchmarks.
  
Line 117: Line 116:
 [2] : http://​www.brownhat.org/​docs/​socketcan/​llcf-api.html [2] : http://​www.brownhat.org/​docs/​socketcan/​llcf-api.html
 [3] : https://​github.com/​iotbzh/​afb-signal-composer [3] : https://​github.com/​iotbzh/​afb-signal-composer
-[4] : https://​rawgit.com/​w3c/​automotive-bg/​master/​snapshots/​data_spec_snapshot_latest.html+[4] : https://​rawgit.com/​w3c/​automotive-bg/​master/​snapshots/​data_spec_snapshot_latest.html ​
agl-distro/sep2017-can-f2f.1505116591.txt.gz · Last modified: 2017/09/11 07:56 by claneys