0

I have tried cross-compiling some small C++ code for a Raspberry Pi Model 3b using my Windows machine via Ubuntu-20.04 on WSL2. It uses the Paho MQTT C and C++ libraries to subscribe to and sometimes publish some messages. I'm pretty sure that most of it works since MQTT subscriptions work, as well as publishing messages using a QoS of 0.

However, when publishing with a QoS of 1 or 2, I get a runtime error: MQTT error [-9]: Invalid QoS value

When I try publishing with a QoS less than 0 or greater than 2, I get this instead: MQTT error [-9]: Bad QoS

I have compiled the same code in the RPi itself and the code runs without any issues.

I'm not completely sure what is happening, but I tried checking why I'm getting the same reason code but different error messages. It appears that the Bad QoS message is written in mqtt/message.h, which can be found in the C++ library, while the Invalid QoS Value can be found in MQTTAsync.c, from the C library.

neil
  • 13
  • 3

2 Answers2

0

As far as I know MQTT only supports 3 levels of QoS. QoS 0, 1 and 2. Thus using "QoS less than 0 or greater than 2" will indeed give the "Invalid QoS Value" Error. I suspect cross compilation is doing something unintended. It would be great if you could share more information about the project. Like What MQTT broker do you use? How do you cross compile etc.

Thank You. Naveen PS

Naveen PS
  • 13
  • 5
  • Hi, I intend to use mostly QoS 1 (QoS 2 in some cases). I only did the tests with QoS outside the 0-2 range as a "sanity check" for the compiler. And it indeed gave me a small clue as to what was happening and what was producing the error. I'll try to edit the question to show what I did to set up the cross-compiler, but a short summary is that I used the predefined armv8-rpi3-linux-gnueabihf config from crosstool-NG and modified it a little to add a sysroot, then I copied /usr/lib, /usr/include, /lib, and /usr/local from my RPi to the cross compiler's sysroot. – neil Sep 01 '22 at 05:42
0

Just fixed this issue a few days ago. Inspected the predefined targets of the RPi's gcc and as it turns out, it's slightly different: march is armv6+fp instead of armv8

I also edited my CMakeLists.txt to perform find_package on both the eclipse-paho-mqtt-c and PahoMqttCpp packages, and fixed the target_link_libraries line, targetting the link libraries in a more 'specific' way:

target_link_libraries(myproject PahoMqttCpp::paho-mqttpp3 eclipse-paho-mqtt-c::paho-mqtt3as)

I'm actually unsure which one fixed my issues, I'm currently not willing to re-build the toolchain for the armv8 march just to check if the march parameter fixed it, since it takes a little under 30mins.

neil
  • 13
  • 3