stm32plus + uavcan integration issues
Tal-seven opened this issue · comments
Hi,
This is going to be a little longer than usual, since i intend to provide maximal info about the project and the issues i'm running into. Things to consider: Issues could be due to mistakes i'm making in integration. Or this could be a genuine problem that i could be able to fix.
Project setup:
STM32F429
stm32plus + Chibios_RT (OS only) + UAVCAN.
I have been running stm32plus + chibios for a couple of weeks now without any issues. But integrating uavcan + stm32plus looks a little tricky. Uavcan depends on c++11 and isnt happy with the stm32plus provided stl implementation. For instance it requires std::function which in stm32plus's stl library is an empty header. I tried an adhoc solution by changing stm32plus provided "functional" header to <old_functional>. Now uavcan pulls in the right header from gnu c++. It fixed that particular issue, but "std functional" pulls in its own dependencies.
In file included from /usr/local/arm-none-eabi/include/stm32plus-040100/stl/stl_algobase.h:64:0,
from /usr/local/arm-none-eabi/include/stm32plus-040100/stl/memory:18,
from /usr/local/arm-none-eabi/include/stm32plus-040100/stl/string:28,
from /usr/arm-none-eabi/include/c++/7.2.1/stdexcept:39,
from /usr/arm-none-eabi/include/c++/7.2.1/array:39,
from /usr/arm-none-eabi/include/c++/7.2.1/tuple:39,
from /usr/arm-none-eabi/include/c++/7.2.1/functional:54,
from /home/talha/test/src/libuavcan/libuavcan/include/uavcan/node/subscriber.hpp:17,
from /home/talha/test/src/libuavcan/libuavcan/include/uavcan/protocol/node_status_provider.hpp:9,
from /home/talha/test/src/libuavcan/libuavcan/include/uavcan/node/node.hpp:14,
from /home/talha/test/src/libuavcan/libuavcan/include/uavcan/uavcan.hpp:14,
from /home/talha/test/src/libuavcan/libuavcan_drivers/stm32/driver/include/uavcan_stm32/uavcan_stm32.hpp:7,
from /home/talha/test/src/stm32_uavcan/./can/node.hpp:36,
from /home/talha/test/src/stm32_uavcan/src/main.cpp:9:
/usr/local/arm-none-eabi/include/stm32plus-040100/stl/stl_iterator.h:595:11: error: 'basic_istream' does not name a type; did you mean 'basic_string'?
typedef basic_istream<_CharT, _Traits> istream_type;
If you trace the error stack to the top, its clear that the gnu c++ headers are including stm32plus/stl headers. which can never be correct. So i changed the default stm32plus cmake file to not include the stl folder by default and any code that requires from stm32plus's stl library will have to include it as <stl/foo> instead.
This causes the following:
`In file included from /usr/local/arm-none-eabi/include/stm32plus-040100/stl/iterator:31:0,
from /usr/local/arm-none-eabi/include/stm32plus-040100/config/event.h:19,
from /usr/local/arm-none-eabi/include/stm32plus-040100/config/rtc.h:19,
from /usr/local/arm-none-eabi/include/stm32plus-040100/config/timer.h:24,
from /usr/local/arm-none-eabi/include/stm32plus-040100/config/timing.h:18,
from /usr/local/arm-none-eabi/include/stm32plus-040100/config/stream.h:18,
from /usr/local/arm-none-eabi/include/stm32plus-040100/config/usart.h:21,
from /home/talha/test/src/stm32_uavcan/../sys/sys.hpp:9,
from /home/talha/test/src/stm32_uavcan/can/node.cpp:38:
/usr/local/arm-none-eabi/include/stm32plus-040100/stl/stl_relops.h:37:13: error: redefinition of 'template<class _Tp> bool std::rel_ops::operator!=(const _Tp&, const _Tp&)'
inline bool operator!=(const _Tp& __x, const _Tp& __y) {
^~~~~~~~
In file included from /usr/arm-none-eabi/include/c++/7.2.1/utility:69:0,
from /usr/arm-none-eabi/include/c++/7.2.1/tuple:38,
from /usr/arm-none-eabi/include/c++/7.2.1/functional:54,
from /home/talha/test/src/libuavcan/libuavcan/include/uavcan/node/subscriber.hpp:17,
from /home/talha/test/src/libuavcan/libuavcan/include/uavcan/protocol/node_status_provider.hpp:9,
from /home/talha/test/src/libuavcan/libuavcan/include/uavcan/node/node.hpp:14,
from /home/talha/test/src/libuavcan/libuavcan/include/uavcan/uavcan.hpp:14,
from /home/talha/test/src/libuavcan/libuavcan_drivers/stm32/driver/include/uavcan_stm32/uavcan_stm32.hpp:7,
from /home/talha/test/src/stm32_uavcan/./can/node.hpp:36,
from /home/talha/test/src/stm32_uavcan/can/node.cpp:34:
/usr/arm-none-eabi/include/c++/7.2.1/bits/stl_relops.h:87:7: note: 'template<class _Tp> bool std::rel_ops::operator!=(const _Tp&, const _Tp&)' previously declared here
operator!=(const _Tp& __x, const _Tp& __y)
`
uavcan stand-alone points to gnu cxx headers and the test project includes uavcan header files which within the scope of the stm32plus test project are including gnu headers thus leading to re-definition errors. Is there a way to sort out this dependency mess. I cannot make libuavcan point to stm32plus's stl since that would just be a massive limitation and might even break alot of uavcan code.
Refactoring stm32plus against gnu c++ and entirely removing stm32plus stl would be a massive undertaking and something i will be doing in the near future. But is there an adhoc solution which fixes the issue for now and gives me time to work refactor the library, while making progress on the project.
@mikepurvis could you please weigh in on this. Thanks
I'm afraid I don't have tons to add here except to say that it has been a challenge getting stm32plus to cooperate with other libraries, particularly where c++11 is concerned, and getting rid of the vendored-in STL would a long ways toward fixing that story.
got it Thanks. Any recommendations ,guidelines, gotchas, optimization tricks to be followed while making the shift?. Basically anything that you could throw at me :) . "out-of-the-box" gnu STL seems to be good enough without any hacking. Following is the size output of the default stm32plus static lib with SGI STL and -O3
text data bss dec hex filename
226019 10133 846 236998 39dc6 (TOTALS)
This is the result with gnu libstdc++ that ships with gcc 7.2.1 and -O3.
text data bss dec hex filename
220663 10133 814 231610 388ba (TOTALS)
The only changes that i've made to the stm32plus code thus far is using forward_list in place of slist.