Looking for good C/C++ resources for PI

[srjacob]

I am a newbe to the PI, but I know C/C++ fairly well. Can anyone point me to a good starting point for programming C/C++ on the PI? Preferrably a good IDE with breakpoints and debugging tools would be wonderful.

Thanks for the help.

Steve

[jahboater]

I don't use IDE's so someone else will help you there.

The "official" OS called Raspbian is downloaded from here:
https://www.raspberrypi.org/downloads/raspbian/

Raspbian includes a very good C/C++ compiler pre-installed (gcc), along with all the usual professional software development tools. Many other tools such as "valgrind" may be installed by the package manager called "apt".

The debugger is gdb which is more powerful and capable than you can imagine.

There are various text editors available. Beginners use "nano". Far far more powerful is "vi".
Then there is "emacs" which is more than just an editor, it is an IDE.

[1dot0]

IMO nano and vi are really unclear, rough, and annoying.
As an editor I prefer leafpad (already installed in Raspbian), and as an editor feat. a simple but handy IDE: Geany (also already installed in Raspbian), even if a integrated debugger is missing (apart from gdb).

[Heater]

Personally, if you want to use an IDE like VS or Eclipse or InteliJ etc, I would suggest developing your code in the luxury of a regular Windows or Linux running PC that has the horse power to do all that nice interactive breakpoint and debug stuff.

When you have your application in shape then move it to the Pi and compile with the command line, g++ .... I like to use cmake to build my projects. Or qmake for Qt apps.

Of course there will be Pi specific parts of your application that won't run on the PC. Say using GPIO or whatever Pi hardware. Those can be stubbed out and simulated when developing on the PC. They can be hacked with whatever editor on the Pi.

GDB or even DDD will help with the debugging.

[The Traveler]

I am a newbe to the PI, but I know C/C++ fairly well. Can anyone point me to a good starting point for programming C/C++ on the PI? Preferrably a good IDE with breakpoints and debugging tools would be wonderful.

Programming C/C++ on the RPi is about like doing it anywhere else, your just using an ARM compiler. The GNU compiler tools and gdb debugger are standard on most linux installs and work very well.

For my programming, I use an Lubuntu box with cross compiler tool chain.

Code: Select all

sudo apt-get install build-essential
sudo apt-get install g++-arm-linux-gnueabihf
sudo apt-get install gdb-multiarch

If you install qemu, your can run your ARM compiled program on your x86, x64 linux OS. https://www.qemu.org/
Using ssh from my workbox to my RPi, I transfer the compiled executable or lib .so file. Works really well and I don't have the burden of keeping a GUI on my RPi eating up resources.

As for IDE and debugger, well, it's totally personal preference. Code::Blocks, Codelite, Anjuta all have their pros/cons. I'd just suggest trying each and choose what you like. For myself, I actually like to use nano and gdb "in the raw", ie: command line. That way if I need to debug code on my RPi, I can log in via ssh and use the same tools I use on my workbox.

Cheers.

[lianergoist]

If you want a gui for gdb, try 'Nemiver'. I have only used it a few times myself, but it seems to be quite okay. https://wiki.gnome.org/Apps/Nemiver

[ProgrammingPescador]

Hi

If you are looking for an IDE and you are a Windows PC user then I would recommend Visual Studio 2017 as it now has the ability to cross compile directly on the Pi, see here.

I do all of my C/C++ development this way as it gives you access to all the modern tools and techniques which developers have become used to and saves time and grief with having to wrestle with the command line.

I know it probably goes against the grain to recommend Microsoft tools when there are "powerful tools" like Nano available on the device, but for once this is where MS have actually done something right!

Best of luck

[srjacob]

Thanks to everyone who responded, I have decided on using code::blocks, and it's working out very well. I use Visual Studio on Windows, but I am doing hardware related stuff on the Pi, so cross-platform development wouldn't be as useful as working directly on the Pi.

I can't use the debugger because I need to get into superuser mode to run the program, but well-placed printf statements work very well.

Thanks for your help,

Steve

[ElEscalador]

I like code::blocks on the pi, although it's a bit heavy and slow used on a zero and for some reason keeps randomly closing on my latest install. I just use the leafpad text editor for small projects on a zero, for bigger projects I usually use a pi3 to write and test the code then move copy it to the zero that will be running it.

[Heater]

ProgrammingPescador,

I would recommend Visual Studio 2017 as it now has the ability to cross compile directly on the Pi, see here.

Call me pedantic but the link you gave does not describe "cross compiling". I is about editing code on the Windows PC and then building and debugging it on a remote Linux machine (Or perhaps the Linux Subsystem for Windows).

I do all of my C/C++ development this way as it gives you access to all the modern tools and techniques which developers have become used to and saves time and grief with having to wrestle with the command line.

Yes, typing "make" on a command line is such a chore. Of course after you have done it once it becomes up-arrow, return, which is pretty easy I think.

I know it probably goes against the grain to recommend Microsoft tools when there are "powerful tools" like Nano available on the device,

Visual Studio cannot beat the awesome power of nano. Of course for bigger projects I have to break out the big gun, vim.

...but for once this is where MS have actually done something right!

Close. What they perhaps did get right is Visual Studio Code. What with it being Open Source and cross-platform.

[srjacob]

What I don't like about VS is that in every new release, something is different and you need to figure out why your app won't compile or build when you upgrade. Typical of MS. For what I am doing, code::blocks works ok. However, I use VNC and code in a window on my big Windoze 10 machine. I can cut and paste blocks of code between machines, and use Filezilla to move entire projects back and forth. And, yes, I code on a Pi3 and move it to the P0 when everything is running.

I have projects the compile and run fine under vs2016. I don't want to upgrade vs and spend days trying to find out why those projects won't compile and build on the new version.

[srjacob]

I'll reply to this, and I am going to unsubscribe from this thread since my questions have been answered.

I have been programming since the mid 60's on starting on the IBM 1401 (assembler) and 1620 (fortran). I have done projects on the Intel 8086 where the only way to assemble a program was on a big mainframe. I have a patent on a radar simulator that was composed of 2 loosely coupled TI 9900 plus 8-bit slice microprocessors. That development was done in assembly language on the machine itself using TI tools.

I have done other programming projects since, but I retired from a major airlines as head of their IT Architecture and Engineering Division. In my career I h ave designed and built some of the largest systems (at that time) in the world.

Let me say that for me, developing on the target machine (if you can) is generally better because all the hardware is right there. It might take more time to build, but that's ok.

Having done some personal projects on Windows using Visual Studio an the Microsoft Foundation Class libraries, I have gotten use to, and, like an IDE. Yes, I know some of the purists like to do compiles and builds using command line tools, but I just want to get my project done as easily as possible.

Thanks for listening.

Steve

[Heater]

srjacob,

I thought the TI 9900 was a 16 bit micro-processor. TI did make 8 bit slice chips, the SN54AS888 / SN74AS888. We evealuated the TMS9900 back in the early 80's at Marconi Radar, it was judged not to be a competitor for their own in house AMD 2900 bit slice processor creation, the Locus 16.

I agree, developing on the target itself is very convenient especially when it is a full up Linux running computer, like the Pi.

Often I also like the speed and convenience of developing on a Windows or Linux PC/Laptop. Using whatever editor or IDE.

To that end I keep my code in a git repository. From there it can be pulled to the Pi or whatever other target and built on the target for final testing and use. Changes there can then easily be pushed back to the upstream repo. This saves messing around copying files up and down with scp or whatever. Besides using a source code management system is very helpful in itself.

What I don't like is becoming dependent on some IDE or others project files and build system. Give me make and Cmake. Something that is cross-platform and of general use.

[srjacob]

Heater

You are correct. The 9900 is a 16 bit processor. I used one to fly simulated airplanes around, the second plus the bit slice processors for generating radar and beacon signals. Had to build the interprocessor coupling mechanism because nothing like that existed. The simulator was used tor testing air traffic control systems.

It fit into 2 small rack cabinets and it was easy to ship to sites. The Air Foorce eventually grabbed it for testing a new radar.

[ejolson]

What I don't like is becoming dependent on some IDE or others project files and build system.

From what I can tell a single giant program that includes an editor, compiler and debugger was first popularized in the 80's with Turbo Pascal. The main reason for the integration was because the disk drives were too slow to repeatedly load the editor, compiler and debugger as separate tools and the DOS operating system didn't do disk caching. A generation of programmers who learned to program using Turbo Pascal went on to create exaggerated examples such as Java with Eclipse. At the same time Microsoft saw the vendor lock-in that happened and leveraged that for different purposes.

Unix was originally conceived as a programming environment in a different tradition. From the beginning Unix included concurrency and disk caching along with a suitable collection of tools designed for C development tied together by a programmable shell. That's why many consider GNU Linux to already be a development environment such that no all-in-one editor, compiler and debugger is needed. An interesting article that explains this point of view to people who did not grow up with Unix is

https://sanctum.geek.nz/arabesque/series/unix-as-ide/

[1dot0]

@ejolson:
apart from history, on current OS actually no integrated IDE is really needed anywhere, anymore - it's simply more a matter of user-friendlyness and convenience.
e.g., the Arduino IDE is running on Windows, x86 Linux, ARM Linux, and MacOS X (which is also Unix/Linux-based), and either platform has enough memory and diskspace to sink a ship, and that simplicity and convenience (feat also a simple and convenient API with tons of libs and classes) are the reason for it's world-wide tremendous success (and I consider also the former success of Turbo Pascal, Turbo C, Delphi, and Borland C++ Builder to be based on the same reasons).
So finally user-friendlyness, convenience, and simplicity are crucial to use, success, and dissemination, not to stick to stories of the past.

[jahboater]

Unix was originally conceived as a programming environment in a different tradition. From the beginning Unix included concurrency and disk caching along with a suitable collection of tools designed for C development tied together by a programmable shell. That's why many consider GNU Linux to already be a development environment such that no all-in-one editor, compiler and debugger is needed.

Yes. Great link!

UNIX was always considered a "software factory". It had everything needed to produce large scale software built-in.
That included the documentation - to the extent that UNIX included sophisticated photo-typesetting software for producing books and other fancy documentation. troff!
Linux is just a bit more modern.
Yes - for me UNIX/Linux has everything needed, and more, for major software development projects "programming in the large" - no need for any IDE, they are just an extra complication.

But then we have emacs - an IDE, but too difficult to use for the sort of people that rely on IDE's nowadays (to get the best from it, you need to learn Lisp ).

UNIX was designed by some very clever and very experienced software engineers. In its day we had limited crap like DOS, and mainframe OS's with horrid JCL and record structured files. Honeywell Multics was different, but too large and complex, so UNIX was born. UNIX was, and still is, a breath of fresh air...

[1dot0]

emacs...? naaahh...: Geany.
As already once stated, don't just Think! for large scale software, time to Think Different! for noobs and makers

[DougieLawson]

emacs...? naaahh...: Geany.

Naahh ...: vim. vim-full works for me. I've never ventured anywhere near emacs (will have to try one day).

Some of us are still playing with COBOL, horrid (albeit somewhat improved) JCL and mainframes with record structured files (and DL/1 databases). That's what I was doing today for my day job. Tomorrow I'll be playing with COBOL, PL/I, Assembler, JCL, Db2 SQL databases and record structured files. It's fun, it pays the bills.