search

andysworkshop / stm32plus

The C++ library for the STM32 F0, F100, F103, F107 and F4 microcontrollers
http://www.andybrown.me.uk
Other
745 stars 224 forks source link

stm32plus + uavcan integration issues #216

Closed Tal-seven closed 4 years ago

Tal-seven commented 6 years ago

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

Tal-seven commented 6 years ago

@mikepurvis could you please weigh in on this. Thanks

mikepurvis commented 6 years ago

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.

Tal-seven commented 6 years ago

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.