why do they use Python instead of C++?
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.
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.
3) why do they use Python instead of C++?Ease of development.
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.
Then again, I tend not to use nuclear bombs when a hammer would work just fine. ;DI 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.
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?
3) why do they use Python instead of C++? I assume it is possible to use C++, is that correct?
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.
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 (https://github.com/UvinduW/Cross-Compiling-Qt-for-Raspberry-Pi-4) (and this guide at interelectronix.com (https://www.interelectronix.com/qt-515-cross-compilation-raspberry-compute-module-4-ubuntu-20-lts.html)) on how to cross-compile them on Ubuntu 20 LTS using gcc-linearo-7.4.1-2019.02-x86_64_arm-linux-gnueabihf (https://releases.linaro.org/components/toolchain/binaries/7.4-2019.02/arm-linux-gnueabihf/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf.tar.xz). I wouldn't use rsync myself (to obtain the core libraries and headers needed for a cross-build), but configuring the build using
../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 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.
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.
(Anyone doing cross compiling should find reading Cross Linux From Scratch (https://trac.clfs.org/) useful, especially chapter III/step 4, building cross compile toolchains (http://clfs.org/view/clfs-embedded/arm/). 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.)
(Anyone doing cross compiling should find reading Cross Linux From Scratch (https://trac.clfs.org/) useful, especially chapter III/step 4, building cross compile toolchains (http://clfs.org/view/clfs-embedded/arm/). 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.
(Anyone doing cross compiling should find reading Cross Linux From Scratch (https://trac.clfs.org/) useful, especially chapter III/step 4, building cross compile toolchains (http://clfs.org/view/clfs-embedded/arm/). 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 cross-toolchain is the least of your problems.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 (https://developer.arm.com/open-source/gnu-toolchain/gnu-rm) for new source and binary releases. (Funnily enough, even Linaro (https://www.linaro.org/downloads/) does that for current and future releases.)
sudo apt-get install gcc-aarch64-linux-gnu
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).