Best development tools for Raspberry Pi Compute Module - Preferably in C/C++ ?

[ricko_uk]

Hi,
I am thinking of writing some code for Raspberry Pi's Compute Module (practically the same as the Rasp Pi) which has a lot of graphics to display in real time sensors values etc.
After some googling it seems that most people use Python for coding on the Raspberry Pi instead of C++.

Few questions:
1) what are the best (most complete, reliable and well supported) cross platform dev tools (so that - for speed - I can code/compile on PC then download on the Pi) that I can use to code in C++ which make easy to develop full graphical interfaces as described above?
2) are there some nice open-source graphic libraries to draw graphs and instrument-like graphics (dials etc) with slick/modern graphics?
3) why do they use Python instead of C++? I assume it is possible to use C++, is that correct?

Thank you

[DiTBho]

why do they use Python instead of C++?

because python is the new hype (kind of basic of the 2020s) and people love it

[DiTBho]

QT is written in c++

[Nominal Animal]

1) what are the best (most complete, reliable and well supported) cross platform dev tools (so that - for speed - I can code/compile on PC then download on the Pi) that I can use to code in C++ which make easy to develop full graphical interfaces as described above?

Depends on what you mean by "PC".  If Linux, then the standard dev packages, and maybe clang.  Since the OS stays the same, all you need to do is recompile your programs for the target architecture.

Note that this means that you develop your GUI/UI on Linux, without connecting to the RasPi/whatever Linux SBC you use, at all.
When you have something you are willing to test in real life, you just recompile the same sources on the RasPi/Linux SBC, and run it.

If you want to set up an actual cross-development environment, where you could just push the binaries to run on the RasPi/Linux SBC, that takes more effort.
To keep things simple and easier to debug, just use native tools, and transfer the sources only.

If by "PC" you mean Windows or Mac desktops, I dunno; I don't use those.  (I do believe that on Macs, if you set up a Qt development environment, then your code is directly portable to Linux too.)

2) are there some nice open-source graphic libraries to draw graphs and instrument-like graphics (dials etc) with slick/modern graphics?

If you use C, I recommend Gtk+ 3; if you use C++, I recommend Qt 5.

You can design your dials/backgrounds in Inkscape as SVG (vector graphics, so that they can be resized without affecting the fidelity), and use the SVG files in both Gtk+ (using librsvg, which provides the SVG format gdk-pixbuf support) and Qt (using QtSVG).

3) why do they use Python instead of C++?

Ease of development.

When you use Gtk or Qt from Python, there is very, very little actual Python code there.  One of the strengths of Python is that it can interface directly to native libraries (written in C or C++) with very little Python code needed.  A typical Python3 + Qt5 program spends most of the CPU time running the code in the native libraries, and actually very little running the Python interpreter.  For simple applications, and for applications where the computation is done in the native library code, the difference between using Python, or C or C++, to implement the user interface (display widgets), is pretty small.  The biggest "cost" is increased memory use (as the Python interpreter needs some memory, too), but when you have at least a gigabyte of it or more, it just doesn't matter enough compared to the ease of writing Python.

I personally do like doing the user interface part in Python, with any heavy calculation done in either a C/C++ library, or in a companion process that the UI starts and communicates with using pipes/sockets.  (In certain cases, when the target is an appliance, and the companion driver controls some device, the companion process may be called a "driver", as in "userspace driver".  A better name is "backend".  A typical case might be an UI for a plasma cutter, where you have a driver or "backend" for each plasma control format – G-code, HPGL, whatever.)

[ricko_uk]

Thank you as always!

[SiliconWizard]

Also depends on what your needs exactly are.
Do you need a full desktop-like GUI solution (with all the usual: widgets, dialogs, menus, you name it...)? In which case you already got answers. GTK, QT, wxWindows too. And a few others.

If you are going to implement your own visuals, OTOH, and are looking for something more barebones but allowing pretty graphics, you could consider using Cairo directly. If all you need is to display information in a window, with nice antialiased looks, then merely creating a window and using Cairo to render your graphics in can be a nice approach. (Note that GTK uses Cairo...) That's what I would personally use if I need some kind of "dashboard" display, and not a full-fledged application. Then again, I tend not to use nuclear bombs when a hammer would work just fine.

[Nominal Animal]

If you are going to implement your own visuals, OTOH, and are looking for something more barebones but allowing pretty graphics, you could consider using Cairo directly.

You can also run (hardware-accelerated) Qt directly on top of the framebuffer, fullscreen, without X or Wayland.

I do believe you may need to recompile Qt libraries for the target device, because the EGLFS backend may not be enabled in the default libraries. Raspberry Pi, among others, definitely has hardware EGL support.  I don't know if the current Qt libraries on the 'Pi Linux distributions have EGLFS backend enabled or not... Anyway, for a full-screen appliance, you should trim out the unnecessary stuff and rebuild size/feature-optimized Qt libraries for yourself, anyway.

(The native compile does take ages, that I freely admit.  But it is more like a hammer that is kept in a way too elaborate storage box.  When you get it out in the form you like, it's surprisingly lightweight to swing around.)

With C++, you can definitely use Cairo.  I just don't know how you can currently get EGL-accelerated output out of Cairo, without X, Wayland, or Gtk+.

Then again, I tend not to use nuclear bombs when a hammer would work just fine.

I think you're mixing which one is the hammer and which one the nuclear bomb, if you consider the dependencies and the complexity of the entire target.

(Unless, of course, you can show how to get EGL-accelerated output out of Cairo on top of raw framebuffer on 'Pi's, without X or Wayland, and not recompiling Pango/Atk/etc., and not requiring Gtk+ or SDL.  I'd be happy to eat humble pie here, because if that works, then I too would recommend Cairo over Qt for this kind of stuff. )

[ejeffrey]

Hi,
I am thinking of writing some code for Raspberry Pi's Compute Module (practically the same as the Rasp Pi) which has a lot of graphics to display in real time sensors values etc.
After some googling it seems that most people use Python for coding on the Raspberry Pi instead of C++.

Few questions:
1) what are the best (most complete, reliable and well supported) cross platform dev tools (so that - for speed - I can code/compile on PC then download on the Pi) that I can use to code in C++ which make easy to develop full graphical interfaces as described above?

Raspberry pi is just linux so pretty much any dev tools that support linux will support the pi.  You just need the Arm toolchain for whatever compiler you use.

3) why do they use Python instead of C++? I assume it is possible to use C++, is that correct?

Because the raspberry pi is designed to be easy entry to beginners and python is a lot easier and faster to learn than C++, and of all popular languages has the most extensive 1st party standard library and the widest variety of 3rd party extension modules available for reuse that allows you to get started with a project more quickly.  But yes you can use C++, C, Java, or whatever you want.  It's just a mostly standard Linux environment that happens to be in a very small form factor.  When it comes to using the pi specific peripherals such as GPIO, serial interfaces, and cameras, there are C/C++ interfaces that you can use from any language with a foreign function interface, but there will be by far more examples and documentation for python.

[SiliconWizard]

No one asked here not to use X, as far as I got it. If you're going to use a RPi instead of a MCU, getting Linux and X is an obvious benefit.
You can use EGL on the Pi without X and get acceleration - I've done it - but IIRC, Cairo's direct support for EGL is merely experimental. So that probably wouldn't be a reasonable option especially if you have never done it before. Another option on the Pi is to directly use OpenVG - it was provided with the Pi when I checked, don't know if it's still the case. OpenVG is a bit lower-level than Cairo, of course, but it still has functions for drawing basic graphics objects, fonts, etc. Drawing your own dashboards with it is relatively straightforward if you're familiar with vector graphics.

So anyway, when you have X (without necessarily needing any desktop environment), you can use Cairo directly.

Other configurations are more involved anyway - like Qt on the framebuffer - and judging from the OP's questions, I doubt they'd be up for that. Really. They were most probably thinking of even booting the Pi to a full desktop environment and run an app from there...

But X+Cairo is certainly easier to do than even getting Qt to run on the framebuffer. Your answer shows you're probably heavily biased (as we all tend to be) by your own projects and your own abilities. Having to tailor and build Qt from source and then using it successfully is likely something that many people, just willing to have some graphics display, will do only with a gun on their head. As to the the library itself, Cairo is certainly much simpler than Qt and doesn't require C++. So, yes, it's definitely a lot lighter overall, but it's interesting how different ways of seeing things can lead to completely different "conclusions".

[Nominal Animal]

Your answer shows you're probably heavily biased (as we all tend to be) by your own projects and your own abilities.

Well, that's a given, of course.  And that's also why I explicitly said I was ready to eat humble pie; I only know what I know, and it ain't that much, and I'm often wrong.

Yet, if I err, I want to err on the side of "don't be scared, just go ahead and try it", rather than "just use off-the-shelf stuff and it'll be good enough, because this stuff is hard".

Having to tailor and build Qt from source and then using it successfully is likely something that many people, just willing to have some graphics display, will do only with a gun on their head.

Hm. There is this guide at GitHub (and this guide at interelectronix.com) on how to cross-compile them on Ubuntu 20 LTS using gcc-linearo-7.4.1-2019.02-x86_64_arm-linux-gnueabihf.  I wouldn't use rsync myself (to obtain the core libraries and headers needed for a cross-build), but configuring the build using

Code: [Select]

../qt-everywhere-src-5.15.0/configure -release -opengl es2  -eglfs -device linux-rasp-pi4-v3d-g++ -device-option CROSS_COMPILE=~/rpi/tools/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- -sysroot ~/rpi/sysroot -prefix /usr/local/qt5.15 -extprefix ~/rpi/qt5.15 -opensource -confirm-license -skip qtscript -skip qtwayland -skip qtwebengine -nomake tests -make libs -pkg-config -no-use-gold-linker -v -recheckor equivalent (adjusting paths as necessary) looks about right to me, for compiling Qt 5.15.

One shouldn't feel threatened to do this, if one is really interested in making a 'Pi into a single-application appliance (no login, one full-screen application).  The cross-compile aspect of the above guides are much bigger "thing" than reconfiguring and rebuilding a library one needs, even though the compile takes annoyingly long.

Someone (not me, I don't have a 'Pi 4) could also rewrite that guide into one that produces a binary Debian package, so that people (Raspberry Pi OS maintainers?) could do a rebuild when deemed useful, and everyone else could just install the binaries.  Or heck, just put together a debian/ subdir one, so that one could do a native build on a 'Pi 4 (which might take a day or two) to obtain that binary library package, without any of that cross-compilation stuff.

And one shouldn't feel daunted by making a Linux appliance in the first place.  Sure, it takes experience to make it robust and reliable, but if everyone prefers getting shot over trying this, who's gonna get the experience needed?

[blacksheeplogic]

Or heck, just put together a debian/ subdir one, so that one could do a native build on a 'Pi 4 (which might take a day or two) to obtain that binary library package, without any of that cross-compilation stuff.

Not sure, I find building on ARM based systems code that's not been ported and tested is time consuming. You run into one dependency after another. It's also quite slow. Cross compiling I've just found to be faster.

[Nominal Animal]

True... Generally, it isn't that much work to make source packages buildable using Debian tools, and modifying an existing Debian source package to use different configuration, but qtbase-opensource-src has an extensive dependency list, it might not be feasible on say a Raspberry Pi.

That said, cross compilation itself isn't problem-free, as shown by aforementioned guides using a cross-toolchain from Linaro instead; but it too is a matter of configuring and building the toolchain correctly, and constructing a working build environment corresponding to the target system.

(Anyone doing cross compiling should find reading Cross Linux From Scratch useful, especially chapter III/step 4, building cross compile toolchains.  It's not black magic, just complicated due to the interdependencies between the tools.  For example, to build a proper C/C++ cross compiler from scratch, you first build an intermediate C compiler, to compile the C library that the actual cross compiler will use.)

[brucehoult]

Or heck, just put together a debian/ subdir one, so that one could do a native build on a 'Pi 4 (which might take a day or two) to obtain that binary library package, without any of that cross-compilation stuff.

Not sure, I find building on ARM based systems code that's not been ported and tested is time consuming. You run into one dependency after another. It's also quite slow. Cross compiling I've just found to be faster.

Cross-compiling doesn't decrease the dependency program, it increases it.

The Pi 4 is pretty darn fast -- plenty fast enough when compiling code you've written yourself. Sure, it struggles compared to a modern x86 or Apple Silicon PC if you compile something huge like gcc or llvm or qt on it.

If building something on the Pi is too slow then doing a NATIVE build in ARM qemu on a big PC (or, better, in a simple VM on an Apple Silicon Mac, if you're running 64 bit code on the Pi) gives you access to more CPU cores (possibly 8 or 16 times more), possibly much more RAM, faster disk I/O etc. But without adding the sometimes very big hassles of cross-compiling.

[brucehoult]

(Anyone doing cross compiling should find reading Cross Linux From Scratch useful, especially chapter III/step 4, building cross compile toolchains.  It's not black magic, just complicated due to the interdependencies between the tools.  For example, to build a proper C/C++ cross compiler from scratch, you first build an intermediate C compiler, to compile the C library that the actual cross compiler will use.)

The cross-toolchain is the least of your problems.

sudo apt-get install gcc-aarch64-linux-gnu

Boom. Done.

The real problem is build setups for software packages which don't support cross-compilation, or in which is seldom used or tested and someone has broken it.

This happens a lot more than you might think. Sticking to native builds in an emulator or vm is much much more reliable.

[SiliconWizard]

(Anyone doing cross compiling should find reading Cross Linux From Scratch useful, especially chapter III/step 4, building cross compile toolchains.  It's not black magic, just complicated due to the interdependencies between the tools.  For example, to build a proper C/C++ cross compiler from scratch, you first build an intermediate C compiler, to compile the C library that the actual cross compiler will use.)

The cross-toolchain is the least of your problems.

sudo apt-get install gcc-aarch64-linux-gnu

Boom. Done.

The real problem is build setups for software packages which don't support cross-compilation, or in which is seldom used or tested and someone has broken it.

This happens a lot more than you might think. Sticking to native builds in an emulator or vm is much much more reliable.

Yes, I second that. =)

[brucehoult]

(Anyone doing cross compiling should find reading Cross Linux From Scratch useful, especially chapter III/step 4, building cross compile toolchains.  It's not black magic, just complicated due to the interdependencies between the tools.  For example, to build a proper C/C++ cross compiler from scratch, you first build an intermediate C compiler, to compile the C library that the actual cross compiler will use.)

The cross-toolchain is the least of your problems.

sudo apt-get install gcc-aarch64-linux-gnu

Boom. Done.

The real problem is build setups for software packages which don't support cross-compilation, or in which is seldom used or tested and someone has broken it.

This happens a lot more than you might think. Sticking to native builds in an emulator or vm is much much more reliable.

Yes, I second that. =)

The problem of course is the Pi 4 is probably 2-4 times faster than qemu arm on x86, so you need a LOT more cores to compensate.

Running aarch64 Ubuntu on both the Pi and in a VM on an M1 Pro Mac would be perfect.

See my tests from a year ago (!!) comparing among other things arm64 Ubuntu on a Pi 4 vs arm64 Ubuntu in a vm on a Mac -- see "pi4" and "minivm" figures. They were slightly different versions of Ubuntu, but that won't be material.

https://hoult.org/arm64_mini.html

Apple Silicon was more than 4 times faster than the Pi 4 for single-threaded tasks, and 6 1/2 times faster for the large software build.

A 14" or 16" MacBookPro with M1 Pro has twice as many high performance cores as that Mi Mini and might well be 10x faster than a Pi 4 for large software builds or other highly multithreaded tasks.

[brucehoult]

An 8 GB Pi 4 has enough RAM to capture the advantages you list. Many people's development PCs don't have more. Older generation RAM, certainly, but reasonably well matched to the CPU cores.

The eMMC on the compute module is much better than SD card on the regular Pi 4.

If you're using ccache / distcc then the actual compiles only see already preprocessed compiles of single C files. This is perfect for using the Pi to run all the tricky build scripts and configuration programs and generally the things that go wrong on cross-building, and hand off only the simple compiles of the preprocessed C to a cross-compiler running on faster x86 machines. The x86 machines then don't need to have any Pi headers or libraries or other Pi-specific configuration.

[PKTKS]

Anything i checked with python thing..

Ended up like a SWAP HOG PIG...

PYTHON  for casual newbies..
Applets not really serious.. or small scripts

Really serious code .. C

Paul

[Nominal Animal]

The cross-toolchain is the least of your problems.

sudo apt-get install gcc-aarch64-linux-gnu

Except, as noted in the above guide, the GCC version in Ubuntu 20 LTS is "too old".  (I don't know the details, but obviously there is a reason they didn't just use the distro-provided cross-compiler packages.)  I do believe this is related to the fact that the GNU Arm Embedded Toolchain PPA is no longer maintained, an instead just refers users to go to developer.arm.com for new source and binary releases.  (Funnily enough, even Linaro does that for current and future releases.)

The real problem is build setups for software packages which don't support cross-compilation, or in which is seldom used or tested and someone has broken it.

I fully agree with that in general; I only disagree with respect to Qt (and certain other very-often-cross-compiled packages, like GCC and clang toolchains).

In general, I personally do prefer to just Debian-ify (on Debian-based systems) any sources I compile from scratch, by adding the debian/ subdirectory and patches etc., then compiling the package natively; and testing the generated binaries on a separate image (usually I just clone the disk or snapshot the VM before installing any development tools).  This makes maintenance and version dependency tracking much easier.

Those who work with Debian-based Linux distributions, really should consider reading Debian packaging tutorial (as PDF) and Debian New Maintainers' Guide.  As Debian is based on a community of volunteers, it has slowly evolved quite nice and easy tools for packaging software into .deb packages.  It is one of those things that if you try to do it without reading the guides/tutorial, it is difficult to grok and looks very arcane, but as the guides explain the ideas, it becomes rather easy and simple in the end.

Similarly for RPM packaging.  Some prefer .rpm/.srpm over .deb, but both have sound ideas behind their operation, and work surprisingly well in practice, in millions of installations.

The version dependency issues discussed here and elsewhere are not due to the package format, but due to ignorant packagers who mark version dependencies carelessly.
It is very rare that the actual sources need to be changed due to library API changing; it's just that the packager didn't care enough to check which versions suffice, and just marks the versions they used as dependencies.  This is a common occurrence even in Debian itself.

(The exception is, of course, library major versions, and when a package switches from one implementation to another.)

[Nominal Animal]

To simplify my stance:

If I was an active Raspberry Pi developer, I'd certainly maintain the Qt-on-raw-EGLFS packages for myself and others to use, as Debian packages.  That would mean that anyone writing C++ or Python applications on top of Qt could do their development on their desktop Linux machines, and simply transfer the Python to the 'Pi, or cross-compile C++ to 'Pi or copy the sources over and do a native compile, and it would Just Work.

When done once, maintaining the packages is relatively little work, considering that Qt does not release new versions very often, and one can even test the development versions to see if anything significant that needs action is coming ones way in the next release.

The problem is that the Raspberry Pi community is rather inwards-facing, and pretty hostile to open source projects in general.  Their attitude is such that experienced developers rather quickly ditch the community altogether, and either just do their own thing (without any association or cooperation with the Pi community), or like me, switch to other SBCs with friendlier communities.  This is why there is nobody providing such packages –– as far as I know! I could be wrong here! –– right now.

I myself am right now fiddling with routers and Odroid HC-1 and such, that do not have displays at all; and am actually looking at using Teensy 4.0 as an external USB framebuffer for such devices, for application developers to use for human interfaces – router status displays and such.  Qt and Gtk+ are way too heavyweight here, as I'll almost certainly use Teensy itself to render antialiased fonts and such, focusing on text, image blitting, and animated widgets like progress bars and such.  The last time I personally did Qt-on-raw-framebuffer stuff was with Qt 4 (interactive kiosk-type displays), and although the initial learning step was steep, it became rather easy quite quickly.

If someone wants to get good standing in the Raspberry Pi community, packaging alternate versions of the Qt libraries this way, with maybe a guide on how to install a minimal Debian/Armbian – sorry, "Raspberry Pi OS" – with the alternate Qt packages for developing appliances on top of raw accelerated framebuffer, could be a good way to do that.  (It's not nearly as hard as one might believe; but it is just the initial learning step to grok how the system is built, and the rest is rather straightforward.)  Just be careful to focus on the Raspberry Pi, and never mention licenses (except perhaps that only LGPL-licensed parts of Qt are used, so can be used in proprietary projects also if dynamically linked), and never mention/recommend any open source projects, open source paradigm, or Free/Open Source Software principles, and you should be good.  Treat them as somebody with good intentions but extremely strong prejudices against FLOSS, and you should have no issues at all.