Releases: quasar-team/CanModule
reduced dependency libs, neat versioning, LogIt optimized
- reduced dependency libs can be build and used, set environment
export CANMODULE_AS_STATIC_AS_POSSIBLE=1
for build and also runtime - essentially reduce dependency to boost and libsocketcan, for linux only
- for windows no changes
- default behaviour is "all shared" as before
- LogIt registering ONE component ONCE (Slava detected that ;-)
- dropped some INF Logging messages
- cmake 3.0 or higher, same as for quasar, to have much neater versioning
- versioning ONLY in the top-level CMakeLists.txt, this creates a file VERSION.h
- VERSION.h is included, and used to time-version-stamp the bins/libs
- can identify the version of a lib like that, and when it was built
- also output to ./lib for all artifacts, NOT to CanInterfaceImplementations/output any more
- see Documentation/sphinx-result/index.html "Building" for more info on master
single component logging
- back to single component logging as preferred by the team
- LogIt component name is "CanModule"
- grep for "systec", "anagate", "peak" or "sock" for vendor specific messages
- cleaned up anagate/CMakeLists.txt
- minor beauty fixes, supressed some log msg.
- updated documentation accordingly
build chain fix to disable vendors
fixing OPCUA-1421
build chain now supports optional vendor switch off, to avoid dragging along unneeded dependencies and hacking the build chain. Defaults are as before
you will have to switch off vendor builds if you want ONLY mockup, using the toolchain
SET( CANMODULE_BUILD_VENDORS “OFF”) (default is “ON”)
you can switch off selected vendor which you do not need using the toolchain
SET(CANMODULE_BUILD_SYSTEC “OFF”)
SET(CANMODULE_BUILD_ANAGATE “OFF”)
SET(CANMODULE_BUILD_PEAK “OFF”)
(default is all "ON")
build chain cleanup
CMakeLists.xtx/build chain proper cleanup:
- 32BIT/64BIT switch dropped, defaults to 64BIT
- 32BIT can be injected via toolchain of course
- VENDOR_LIB_PATH, VENDOR_LIB_FILE, VENDOR_HEADERS used everywhere consistently
- cleaned up windows/linux behavior
- should also solve OPCUA-1356 and OPCUA-1431
- wanted to do this since a long time anyway
- builds with CANX on all CI: cc7, w2016s, w10, w2008r2 so should be fine
- see https://gitlab.cern.ch/mludwig/canx for example toolchains
anagate reconnect fully tested
still some remaining issues with anagate reconnection under windows. All fixed and tested now
with cc7, w2016s, w10e, w2008r2 and multiple modules and channels. All lab tests are OK so far
concerning anagate reconnection.
quite well tested@cc7
fixed bugs:
- OPCUA-1430 (stupid me)
socketcan implementation needs "can" to be prefixed to the port number
still, the user can specify any prefix, excluding [0-9] of course, the implementation specific prefix gets added by CanModule
legal for port is: "whateverPrefix8" -> port 8 -> for socketcan becomes "can8" internally
not a good idea is "n0tGood1dea8" -> port 0 -> you probably wanted port 8
so please be reasonable - CANT-32 (difficult one)
reconnection behaviour for listening threads/handles was not correct for anagate when using several modules in parallel. Force-serialized reconnection behavior to become "one module after the other" to avoid reception handler corruption. It works for anagate. I have to check, and probably add that for the other vendors as well, and verify under windows.
broken release, use 1.1.3 [protect agains 0 messages for send]
broken release, use 1.1.3
fixing OPCUA-1415 for msg sending for all vendors.
sphinx doc and peak@windows
* Documentation, as html created by sphinx/brethe/doxygen
* all 3 vendors have a solution for linux and windows
* peak and peak-pro work for windows as well now (peak-fd NOT), small fixes
* component logging as from 1.1.0
* comments in code improved
* minor code tweaks
component logging
component logging is working for all vendors JCOP-353 solved
still no PEAK@windows
further JIRAs in progress
anagate fw reconnect (corrected tag name)
small fix so that anagate modules also reconnect all CAN ports even if there was a firmware reset. FW resets can be triggered by a software call to the anagate API, and that kind of call is NOT implemented in CanModule for anagate. Nevertheless it can easily be invoked by a networking client, since the only nargument is the ip adress of the module. It is deemed neccessary for a running client using CanModule to also survive (=reconnect) that scenarion, and in fact it is quite easily prossible. There is a wait of 10sec. needed to allow the fw to reboot fully