|
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
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
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
|
