Support for chip from espressif family with Zephyr #131
Comments
|
Does it works if you revert this changes: #125 ? |
|
Thanks for the fast response @pablogs9. |
|
This repo is an example of a micro-ROS application for Let me know if you have any questions. |
|
I linked libmicroros as it is done in the example in this repo (basically I just copied 'libmicroros' module and put it in the 'modules' subdirectory for now). The strange thing is that when I enable CPP support (even with minimal parts of the std library, I have dram0_0_seg overflows (it is also happening if I try to compile for other boards, RAM and flash are being overflowed...). I wonder if that is a known limitation, or if I have something misconfigured. |
|
I do not know how big is your flash. CPP std lib tends to be big and micro-ROS is also a big library (depending on the types and features you use). Normally is a good idea to build with -Os and with -ffuntions -fsections to allow the linker to optimize out not used code sections. |
|
It has a 4MiB flash size. I set the CONFIG_SIZE_OPTIMIZATIONS flag to 'y' (which should result in setting -the Os flag to the compiler) but did not resolve the issue. I suspect the flash size of the chip is a problem because I used the same chip with esp-idf and https://github.com/micro-ROS/micro_ros_espidf_component (Zephyr and FreeRTOS probably have different footprint sizes, but I guess it should not be that much in difference). |
|
I managed to build for the -#include <posix/sys/socket.h>
-#include <posix/poll.h>
+#include <zephyr/posix/sys/socket.h>
+#include <zephyr/posix/poll.h> |
|
Unfortunately though, |
|
I have similar issue during runtime: That is happening in my app (using UDP as microros transport), as well as in your example. |
|
@towen I believe we are experiencing the same issue... For some reason it breaks when |
|
Interesting. I have occasionally had "multiple definition of 'random()'" errors, but been unable to pin them down. Is |
|
|
|
This seems like a Zephyr bug (if I try to use rand/srand in However, I think if Zephyr is using a proper random number generator (e.g. from hardware) then calling We could perhaps remove all calls to There's also |
|
I tried replacing srand and rand, but there is an issue with all libc functions. I'm just wondering if that is happening on other targets or if that is a problem specific to espressif's toolchain in Zephyr... |
|
Replacing POSIX functions with Zephyr specifics for random number generation would require modifying 'rmw-microxrcedds' source code (which, I think, is not an ideal option - I think it is using POSIX APIs for easier portability on different platforms). |
|
@OgnjenX, while I don't have a proper fix for this issue yet, please, would you try commenting this line? Let me know if it solves it for now. |
|
@sylvioalves That solves the issue with newlib functions used in the app, so I guess it is a reasonable workaround until the issue is fixed. |
|
There is still the issue with Any help would be appreciated. |
Is it possible to use this module on an ESP chip (I'm trying to use it on ESP32)?
I'm able to build 'micro_ros_zephyr_module' using 'west build -b disco_l475_iot1' but I'm having errors caused by 'app.overlay' content when building with 'west build -p auto -b esp32_devkitc_wroom':
I found in this issue statement that this module should be usable on any board supported by Zephyr.
#60 (comment)
Thanks in advance.
The text was updated successfully, but these errors were encountered: