CAN Signaling Low Level binding development

Frequency thinning, minimum and maximum filtering capabilities is now implemented on master branch

You can subscribe now specifying a maximum frequency from which CAN messages will be received and pushed as well as minimum and maximum limits from beyond event can be pushed.

Simply subscribe using a classic JSON object like:

{"event": "engine.speed", "filter": { "frequency": 2, "min": 1000, "max": 2500} }

Either you can specify frequency or min or max, all of them or just one or two. It doesn't matter.

Git repository has been migrate into gerrit repository : low-level-can-service.

Updated CAN-signaling to use BCM sockets.

Now there are as many socket as described signals and no more RAW sockets. Separate reading threads have been removed in favor of systemd io event job.

CAN-config-generator is updated to the new objects organization the follow the JSON structure.

There aren't new fancy features but now everything is ready to do frequency filtering, timeout monitoring.

Feedback welcomed.

Adding references to documents pushed by @Toni Hoang in the mailing list:

• FMS Standard: http://www.fms-standard.com/Truck/down_load/fms_document_ver03_vers_14_09_2012.pdf

• Remote FMS Standard: http://www.fms-standard.com/Truck/down_load/Technical_Specification_rFMS_V2.0.0_21.09.2016.pdf

I updated the guide, you can find it here. It is more convenient to have a single access point to that point to it.

This is the most updated doc with more accurate instructions to use CAN devices, from a Porter board or a virtual CAN device by example.