This morning my “embedded” soul had an idea for supporting my “messaging” soul and spending some time in a productive way—trying to compile the Qpid Dispatch Router on a different machine with a different architecture. It’s C/C++ code, so it’s portable by definition (even if related to Linux for now). It uses Python but today this language is available on a lot of different platforms, so it seems to be no problem.
Searching for some embedded stuff in my closet and discarding Cortex-Mx based boards (for obvious reasons regarding Linux lack on them) I got my Raspberry Pi—the first version (ARM11 based, not Cortex-Ax).
I have the Pi2 as well (I have to by the third version) but I preferred to stop my research to start immediately. I followed all the steps needed (explained in my previous article) using the Pi as a normal PC (connected via SSH), and after a while for compiling directly on the board, the router was up and running !
The only tweak needed was to force CMake to use the Python 2.7 library with following command line :
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_LIBRARY=/usr/lib/arm-linux-gnueabihf/libpython2.7.so -DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_EXECUTABLE=/usr/bin/python
Because the 3.x version is installed on the Pi as well but we can’t use it for the router.
I know, it’s not the right way to compile source code for embedded devices and cross-compilation from my PC is the better way to do that but I preferred it in order to go fast and avoid setting up a complete ARM toolchain on the laptop; of course be patient. Building the Qpid Proton took me about one hour ! I suggest you get a coffee.
Before starting the router, another simple tweak was needed in order to make persistent the value of the PYTHONPATH environment variable writing the following line to the .bashrc file :
Now I have an idea … Pi with its Linux version is SSL/TLS capable but there are a lot of resources constrained devices which are able to “speak” AMQP but can’t support SSL/TLS connections. Why not use the Pi as a “shadow” IoT gateway and it’s security capabilities in order to bring the above constrained devices to reach SSL/TLS and AMQP based cloud platforms even if they can’t “speak” SSL/TLS ?