socktap: Adding the Autotalks link layer #151
Conversation
There was a problem hiding this comment.
Thanks for your effort! Unfortunately, I cannot test your code on an actual Autotalks device as I have no longer access to any.
I have added several comments where I would like to see changes before merging it into the master branch. Please don't be shocked by these comments, I really appreciate your contribution!
| find_path( | ||
| AUTOTALKS_ROOT | ||
| NAMES "include/atlk/v2x_service.h" | ||
| PATHS $ENV{HOME} |
There was a problem hiding this comment.
So you expect the API to be located at /home/your_user/autotalks_craton_api? Is this suggested by Autotalks?
There was a problem hiding this comment.
I expect the user to create symbolic link from /home/your_user/autotalks_craton_api or /home/your_user/autotalks_secton_api to SDK root, I thought that it was simpler as there does not seem to be any consistent path defined by Autotalks. However, the SDK itself is found in secton-sdk-5.14.0-rel_sec_USB or craton2-sdk-5.14.0-rel_cr2_lnx for version 5.14.0, so maybe that could be used somehow?
There was a problem hiding this comment.
Would you please add a note about this expectation to autotalks-sdk-build.md?
There was a problem hiding this comment.
It was already there but I tried to make the explanation more clear
- moved v2x_device_init() to AutotalksLink constructor - moved autotalks_device_deinit() to AutotalksLink destructor, main.cpp could be revert - renamed v2x_device_init() to autotalks_device_init() - added #error to to autotalks initialization to prevent silent build of non-functioning application - wrapped functions from autotalks.hpp to vanetza::autotalks namespace - renamed Toolchain-Autotalks.cmake to Toolchain-Autotalks-Craton.cmake - added CMake variable for poky toolchain path - removed debugging loop neglected in FindAutotalks.cmake - renamed AUTOTALKS_EXECUTABLES to AUTOTALKS_OBJECTS in cmake - moved Autotalks::AtlkRemote and Autotalks::AtlkLocal dependencies to FindAutotalks.cmake - made constant for send buffer size bigger to be larger than MTU
|
I am not sure if you are happy with user manually creating the symbolic link to SDK root as mentioned above, but to me it seems good enough (as the path is not defined exactly by Autotalks). |
| ) | ||
|
|
||
| set(AUTOTALKS_INCLUDE_DIRS "${AUTOTALKS_ROOT}/include" "${AUTOTALKS_ROOT}/ref_src/include" "${AUTOTALKS_ROOT}/depend/device/include" "${AUTOTALKS_ROOT}/src/include" "${AUTOTALKS_ROOT}/src/core/include") | ||
| set(AUTOTALKS_LIBS_DIR ${AUTOTALKS_ROOT}/output.sec/x86/lib) |
There was a problem hiding this comment.
Are there only x86 libraries? May we want to check CMAKE_SYSTEM_PROCESSOR to select the right directory?
There was a problem hiding this comment.
By x86, Autotalks code generation means that the system's native compiler is used (e.g. no cross-compilation) so in this case this will really be x86 on every platform (last year I tried SDK compilation on Raspberry PI and libraries were still in x86 folder). Autotalks documentation mentions that when Secton is controlled from Craton and we are cross-compiling for Craton, output folder is armv7-32. However, I did not try this possibility.
|
|
||
| set(AUTOTALKS_INCLUDE_DIRS "${AUTOTALKS_ROOT}/include" "${AUTOTALKS_ROOT}/ref_src/include" "${AUTOTALKS_ROOT}/depend/device/include" "${AUTOTALKS_ROOT}/src/include" "${AUTOTALKS_ROOT}/src/core/include") | ||
|
|
||
| set(AUTOTALKS_LIBS_DIR ${AUTOTALKS_ROOT}/output.cr2_lnx/armv7-32/lib) |
There was a problem hiding this comment.
Here it is always arm7-32 because that is simply the Craton processor's architecture, isn't it?
Edit: see also Toolchain-Autotalks-Craton.cmake which pins the architecture to ARM.
There was a problem hiding this comment.
Yes, I think this will always stay the same as you say.
tools/socktap/autotalks.cpp
Outdated
| int autotalks_device_init(void) | ||
| { | ||
| atlk_rc_t rc; | ||
| const char* arg[] = {"./test", "enx0002ccf00006"}; |
There was a problem hiding this comment.
I have put the "enx0002ccf00006" network name in define and added a note to the documentation. I think it is hard-coded somewhere from Autotalks
| find_path( | ||
| AUTOTALKS_ROOT | ||
| NAMES "include/atlk/v2x_service.h" | ||
| PATHS $ENV{HOME} |
There was a problem hiding this comment.
Would you please add a note about this expectation to autotalks-sdk-build.md?
…o the initialization. Documentation clarification
|
Note that |
|
Sorry, I did not notice that socktap cannot be compiled. I should add socktap to the CI! |
|
Thanks for your hard work and patience @khevessy! |
|
After your fix, I've tried |
This adds Autotalks link layer to the socktap example, working on both Craton and Secton devices. Links with Autotalks libraries. Also adds possibility to build for Craton (cross-compilation for ARM using the toolchain supplied with Autotalks SDK).
Initialization of the device can be taken from the Autotalks example, as I propose in the documentation page (I used almost exactly their code, therefore I think it cannot be in the library).
I should add that my knowledge of CMake is not great, so that part may require some further work.