Hello @gedare
After going through different MQTT implementations (specifically coreMQTT , Paho MQTT and MQTT-C) i have concluded that coreMQTT is the best among all due to the following reasons:
- MIT license
- Has high upstream activity / actively maintained
- Minimal dependencies (no threading , no malloc , no networking dependencies)
- Architecture is state machine based, the caller drives all I/O so no internal threading is needed.
- coreMQTT cross-compiled for sparc/leon3 with -Os optimization. Total .text footprint across all 6 source files: ~42 KB.
MQTT-C (not considered due to low upstream activity):
- MIT license
- Very basic implementation and extremely lean has only 2 files
- minimal upstream activity which could become a sustainability risk
- Easy to build
Paho MQTT:
- Eclipse Public License 2.0 and the Eclipse Distribution License 1.0 . (more restrictive than MIT)
- High upstream activity / actively maintained.
- Architecture is Asynchronous client , thread based and requires OS abstraction layer mutexes and timers.
- Complex build as Cmake brings in ssl and testing dependencies which can be configured later.
Project considerations.
-
- Can you build the software at all?
Was able to build coreMQTT with standard gcc with cmake on linux ( more specifically ubuntu 24 )with minimal platform config file.
Minimum dependencies (no threading , no malloc , no networking dependencies)
-
- Can you run the software on anything?
TCP transport works. Broker log shows the client connecting as rtems-test with MQTTv5 protocol, clean session, keepalive 60 which matches the MQTTConnectInfo_t config. MQTT_Init returns 0 (success). MQTT_Connect returns status 4 MQTTSendFailed, likely because the nonblocking recv fires before the broker’s CONNACK comes back. The broker accepted the connection so the issue is on the client side socket configuration, not coreMQTT itself.
-
- Can you build the software with RTEMS?
Cross-compiled all coreMQTT source files with sparc-rtems7-gcc targeting the leon3 BSP. Clean compilation with no errors or warnings, only requires -I source/include, -I source/interface, and -D_POSIX_C_SOURCE=200112L. No RTEMS-specific modifications to the coreMQTT source were needed.
-
- Can you run the software with RTEMS?
coreMQTT cross-compiles cleanly for sparc/leon3 and the transport interface needs POSIX send()/recv() which RTEMS network stack already provides. The remaining work is wiring it into rtems-net-services with waf, writing the RTEMS wrapper API, and testing on QEMU leon3 with a network-enabled BSP. This is what I’m proposing to build.
- Integration approach Contrib vs RSB
As RSB is designed for large complex packages with a lot of dependencies. It makes sense to choose contrib for the following reasons:
-
coreMQTT has 6 source files and no external dependencies as seen from the images.
-
NTP , TTCP in rtems-net-services all use in tree contrib via JSON manifest and not RSB.
-
Contrib would allow waf builds to produce libmqtt.a which means users would not have extra steps to run separate recipes before building and avoids overheads.
-
coreMQTT can be added as git submodule to pin to specific upstream releases.
6 .libbsd and lwip
coreMQTT uses a transport interface with user defined function pointers send/recv.
My implementation would only be using POSIX socket calls socket() , connect() , send() , close() , recv()
lwIP stack:
- POSIX socket API (socket, connect, send, recv, close) available through lwIP’s compatibility layer
- MSG_DONTWAIT defined and fully implemented verified in rtems-lwip source.
- MSG_NOSIGNAL defined but unimplemented, as lwIP does not generate SIGPIPE signals
- No stack-specific config needed
libbsd stack:
- Full POSIX socket API available through FreeBSD networking port
- MSG_DONTWAIT and MSG_NOSIGNAL both fully supported
- MSG_NOSIGNAL suppresses SIGPIPE on broken pipe which is needed on libbsd since it inherits BSD signal behavior
- No stack-specific config needed
Since both stacks expose the same POSIX socket API, no #ifdef guards or stack-specific configuration files are needed. Legacy stack support is not required as per your earlier guidance.
Would appreciate feedback on the above approach and I will start working on the GSoC proposal.
