Products > Programming

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

(1/4) > >>

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:

--- Quote from: ricko_uk on November 18, 2021, 12:00:21 am ---why do they use Python instead of C++?

--- End quote ---

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

DiTBho:
QT is written in c++

Nominal Animal:

--- Quote from: ricko_uk on November 18, 2021, 12:00:21 am ---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?

--- End quote ---
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.)

--- Quote from: ricko_uk on November 18, 2021, 12:00:21 am ---2) are there some nice open-source graphic libraries to draw graphs and instrument-like graphics (dials etc) with slick/modern graphics?

--- End quote ---
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).


--- Quote from: ricko_uk on November 18, 2021, 12:00:21 am ---3) why do they use Python instead of C++?
--- End quote ---
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! :)

Navigation

[0] Message Index

[#] Next page