RTI DDS Micro on ESP8266?

3 posts / 0 new
Last post
Offline
Last seen: 1 month 1 week ago
Joined: 03/15/2020
Posts: 5
RTI DDS Micro on ESP8266?

Hello, I'm a newbie to either RTI DDS or embedded. The question is I'm having an ESP8266 board and would like to use RTI DDS Micro on that board.

There was an experiment on STM32 board found here since 2017:

https://www.rti.com/blog/how-to-build-and-run-rti-connext-dds-micro-on-a-microcontroller

However, uClinux was archived in 2018 and the STM32 board used in that test has Cortex-M chip with 2 Mbytes of Flash memory and 512+16+4 Kbytes of RAM as well. Shortly, it's much more powerful than the ESP8266-12E

So my question is: Is it possible to use RTI DDS Micro on ESP8266? Or even ESP32? If there is, which specific Linux kernel (not the full OS, uCLinux-like) could be compatible with RTI DDS Micro?

Any information would be truly appreciated.

Howard's picture
Offline
Last seen: 1 day 18 hours ago
Joined: 11/29/2012
Posts: 131

Bottom line, the ESP8266 does not have sufficient memory to run an application with Connext Micro.  The ESP32 may have sufficient memory 520 KB of memory, but you would certainly need at least 1 MB (possibly more) of FLASH.  I have no idea what OS is supported on the ESP32.  You will have to find one that will work within the resource constraints and leave about 384 KB of free RAM for Micro itself.  Then you would have to port Connext Micro's source code to work with the OS that you have selected.  Alternatively, you can use Micro without an OS, but that requires much more porting work to get Micro to work with the hardware's timing and network devices.  You would also need to find a network stack (UDP/TCP/IP) since Micro requires one.

As posted in response to your same question in a different thread...

Fundamentally, RTI Connext Micro is a source-code product.  Customers are expected to compile it for the hardware/board that they want to run it on.  Out-of-the-box, RTI Connext Micro has been ported, built, tested on a limited set of platforms (platform = compiler + OS + CPU).  For example, for Connext Micro 3.0.3, please see

https://community.rti.com/static/documentation/connext-micro/3.0.3/doc/html/building/platforms.html#reference-platforms.

Generally speaking, Micro needs about 384 KB of RAM for itself to run.  You should also take into account the RAM used by the OS as well as your own application to determine how much total system RAM is required. 

So, for the Reference platforms mentioned in the documentation, Micro comes with code that has been ported to all of those platforms as well as cmake support to generate the associated build files.

For any other platform, including "Known Customer Platforms", which includes uLinux, you may have to port various parts of Micro to use the OS that you want to use as well as the associated network stack.  This documented here:

https://community.rti.com/static/documentation/connext-micro/3.0.3/doc/html/building/porting.html

For Aduino, unless, you have a way to add external RAM and FLASH to an Aduino board, you won't be able to run Micro, not to mention you need some sort of network (Ethernet/Wifi).  If you are trying to connect Aduino to a system that includes a full network and computers that can run full Connext DDS, then you might want to look into the RTI Nano client, which is based on the DDS-XRCE specification, and allows you to use a very small client on your micro devices to connect to an RTI Nano agent running on more substantial device and serves as a gateway to full DDS applications.  See

https://www.omg.org/spec/DDS-XRCE/

https://github.com/rticommunity/nano-client

https://github.com/rticommunity/nano-agent



Offline
Last seen: 1 month 1 week ago
Joined: 03/15/2020
Posts: 5

Thank you for the detailed answer. You are right, after some time struggling with the board, DDS-XRCE seemed to be the solution. Actually, it turns out that not only RTI Nano but also other implementation of DDS-XRCE could work with RTI DDS as well. I'll investigate RTI Nano soon. Once again, thank you for the support, your answer really "enlightened" the ambiguity in my mind.