Hi Aniello,
Oh, I'm glad to be on your thank page ^^ thanks man. I re-add the AGL mailing list since it could interest others to get the news about the low-can.
About what you try to achieve, I pushed yesterday a review[1] about using custom encoder like I exposed to you on my previous mail. You could try to use it in conjunction with already implemented custom decoder capability to add your ciphering/unciphering function on CAN messages. Here is the step to do so:
- Take your signals.json file and add fields decoder/encoder on signals you wanna cipher/uncipher. ie:
"PT_FuelLevelLow": {"generic_name": "fuel.level.low","bit_position": 55,"bit_size": 1,"factor": 1,"offset": 0,"decoder": "my_unciphering_function_name","encoder": "my_ciphering_function_name"}- write the (un)cipher functions are in a c/cpp file
- use the low-can-generator[2] and either use the flag "-h" to add the c/cpp file's content to the generated source file OR add the following key in your JSON file (look at the "basic" examples):
"extra_sources": ["handlers.cpp"],- Re-compile the low-can with the new generated c/cpp files
- Test :D
So the idea, is to leave untouched the low-can source code and add your own encoding/decoding functions to the generated cpp file. So your functions are integrated directly in the generated cpp file and so the low-can binary.
Best regards.
[1]: https://gerrit.automotivelinux.org/gerrit/#/c/18109/
[2]: https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/low-level-can-generator
On 11/20/18 11:20 PM, Aniello Carotenuto wrote:
Thanks again Romain, in case you didn't know you've got a place on my thesis' thanks page! :D
I've managed to achieve what I wanted by editing the send_frame() function inside the file you specified. Then I realised what I was doing wrong and I managed to achieve the result I wanted also by editing the build_frame() function. So, as of now, I've got multiple choices for ciphering at writing, but I have none for un-ciphering when reading. I think I could edit the message.get_data() value taken inside parse_signal_bitfield() and edit it before the call of bitfield_parse_float().
If I manage to do ciphering a de-ciphering this way in encoder and decoder respectively, then I'm done with my work. I'll keep you updated!Nello
Il giorno mar 20 nov 2018 alle ore 10:32 Romain Forlot [IoT.bzh] <romain.forlot@xxxxxxx> ha scritto:
Hi,
It depends where you did your modifications, I suggest you to modify in the write_signal function line 471 of low-can-cb.cpp file and modify directly the cf variable.
In the meantime, I'm currently implementing a way to allow users to use their own custom encoder function but would only act on the float/string value before encoding as a bit field and sending it though CAN bus. Would it be useful to you ?
Best regards.
On 11/19/18 6:05 PM, Aniello Carotenuto wrote:
Thank you Romain!
I'm not writing an application that works with CAN messages but I'd like to edit the low-can module so that every single signal that has to be sent through it gets XORed with a key (whatever mode is used). Basically what I'm trying to achieve is that the data field of each frame written through the low CAN API is ciphered while those sent with cansend command aren't. I understand that I have to play with the encoder and/or the write.c file, but still I didn't manage to do it.
I thought the return value of build_frame() would be the frame to write, so that editing cf.data would set the data field of the frame to a different value: for example, I expected that setting it to 0 would make the API actually send a frame with 0 as data field but this isn't the case. I saw some very little progress editing the return value of float_to_fixed_point() function defined in write.c. What can you tell me about this? Should I keep on trying here or should I give up totally?
I'm writing my graduation thesis on this argument, that's why I'm so hyped eheh :D
Thank you for finding the time to answer me, I appreciate it as I understand that's quite hard for you!Good evening!Nello
Il giorno lun 19 nov 2018 alle ore 14:00 Romain Forlot [IoT.bzh] <romain.forlot@xxxxxxx> ha scritto:
Hi Nello,
You had almost understood the thing ^^
There is two modes writing on CAN bus, using signal name and value,
that's what you are trying to use OR using raw frame's attributes, bus,
can_id, can_dlc, can_data. You could use the later one to achieve what
you want then it will act on the bitfield directly. Else if you wanna
use your way then you should then only pass the ciphered value to the
low-can then low-can would transmit it without any others action. It
depends on what you want to do.
A work not done at this moment would be to allow using a function
handler at reception and emission to enhance decoder and encoder
possibilities. About now, you only could develop and define a function
that will be used at decoding step to make special actions but this
hasn't been implemented for the encoding part. This would be a great
feature to a add that other might used also, to integrate advanced and
customized actions.
I'll try to add it soon but until then I suggest you to encode first the
value then pass it to the low-can either using the raw way or your way.
Best regards.
On 11/18/18 8:25 PM, Aniello Carotenuto wrote:
> Sorry for bringning up this old question. I've studied a bit more and
> I'd like to apply the simmetric ciphering only to the data part of the
> can frame in a manner that signals sent with cansend shouldn't be
> altered while those passing through the low-can API should. I've tried
> to play with the "value" parameter that build_frame() uses while
> encoding, but I had no luck yet.
--
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@xxxxxxx - www.iot.bzh - +33675142438
-- Romain Forlot - Embedded Engineer - IoT.bzh romain.forlot@xxxxxxx - www.iot.bzh - +33675142438-- Romain Forlot - Embedded Engineer - IoT.bzh romain.forlot@xxxxxxx - www.iot.bzh - +33675142438
_______________________________________________ automotive-discussions mailing list automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
