EEVblog Electronics Community Forum

Computing => Programming => Topic started by: PerranOak on May 15, 2020, 02:41:20 pm

Title: C: freedom from PICs
Post by: PerranOak on May 15, 2020, 02:41:20 pm
I am learning C as part of my PIC "training".

what would be useful is a standalone (free) C compiler and editor that I could use to practice on without having to load programmes into the PIC or use the MPLAB simulator.

Can anyone suggest an example of such please? It would need to be for Windows.

Cheers.
Title: Re: C: freedom from PICs
Post by: andersm on May 15, 2020, 03:14:21 pm
It's not standalone, but if you qualify for a license, Visual Studio Community (https://visualstudio.microsoft.com/vs/community/) is the best free Windows development environment you can get. You can use it for traditional C console applications just fine, and it has an awesome debugger.
Title: Re: C: freedom from PICs
Post by: PerranOak on May 15, 2020, 03:50:30 pm
Thank you.

It only seems to have C++ and I am learning C. Will that be a problem?
Title: Re: C: freedom from PICs
Post by: HwAoRrDk on May 15, 2020, 04:22:28 pm
I often prototype embedded code on the desktop with Visual Studio, but there are a few things you have to watch out for. Yes, it's a C++ compiler, but if you dig around in the project settings a bit, you can set an option to tell it to compile as C code only. There are also some other options you can turn off to get rid of things to do with the C++ standard library, although I forget exactly what right now (something to do with stdafx?). Another one is if you are going to use C library functions (e.g. sprintf(), etc) you have to #define _CRT_SECURE_NO_WARNINGS before you include the library headers, otherwise it will complain that you're using 'unsafe' functions.
Title: Re: C: freedom from PICs
Post by: Doctorandus_P on May 15, 2020, 05:07:34 pm
I think the question is more about what IDE to use than what C compiler.

Although there are man C (and C++) standards, you will be pretty allright with anything as old as C99 compliant.
The most important thing though is that (almost) every C compiler confirms to these standards.
And that moves the question from "which C compiler" to: "Which IDE".

IDE's are a personal preference thing.
Some want all the bells and wistles they can get. Others do not want to put up with all that complexity and rather have something simple.
So you have to find a balance between features and simplicity that works with your personality.

When learning C (or C++) I would consider it to be mandatory to have a working Debugger. Settings breakpoints, stepping though the code and inspecting variables during execution is a great learning tool.

For the last few years I've been using Qt Creator for microcontroller stuff. The balance is pretty close to what I want, and you can also make simple 5 line programs with it which just outputs to the text window, and the debugger works for me.
With simple CLI interface you can concentrate on learning C (or C++) without having the load of complex graphical GUI's.

Apart from these general recommendations I can not say more, as I switched from windows to Linux the first time I saw a "blue tiles of death" screen when my PC booted and I will not be forced into some newfangled weird menu system I did not ask for.
Title: Re: C: freedom from PICs
Post by: Rick Law on May 15, 2020, 07:27:40 pm
For someone learning the language, my opinion is the lesser the IDE footprint the better.

IDE is getting so bloated that it is far more complex than the language itself.  The step-by-step debugger is invaluable in learning, it will let the learner see what the code is doing and thus assist learning greatly; beyond that, and in particular, the way many IDE forces one to organize files, it gets in the way.
Title: Re: C: freedom from PICs
Post by: 77algernon on May 15, 2020, 09:25:52 pm
Hello!

"Pelle's C Compiler" is completely free to use and has a small footprint (installer is about 20meg). It's a complete system with IDE, debugger, assembler, resource compiler, etc. Very nice IMO.
You can find it here:

http://www.smorgasbordet.com/pellesc/index.htm (http://www.smorgasbordet.com/pellesc/index.htm)

Good luck!
Title: Re: C: freedom from PICs
Post by: brucehoult on May 16, 2020, 08:24:59 am
When learning C (or C++) I would consider it to be mandatory to have a working Debugger. Settings breakpoints, stepping though the code and inspecting variables during execution is a great learning tool.

I completely disagree!

That was valuable back when recompiling your program took minutes or even hours.

However trying to visually parse the information you want out of debugger output is slow and tiring, and inserting debugger actions at breakpoints using a language that is not quite the same as the language your program is in is both annoying and slows the execution of your program a lot.

Far better in these days of less than 1 second program builds to do add your temporary debugging code (including any conditional tests) right in the program itself, and use printf or cout to print precisely the information you actually want in exactly the format you want. Send the output to less or to a log file and use your favorite editor or grep or less or perl or whetever you want to search for interesting things in the log.

When finished you can delete the debugging code or else add #IFs to disable it and easily use it again at some later date if you need it.
Title: Re: C: freedom from PICs
Post by: Karel on May 16, 2020, 09:56:57 am
I never use a debugger. Not on the desktop, not in embedded.
I write temporary code (as described above) that outputs debugging info to the console, a serial port or a file.
It saves a lot of time.
Title: Re: C: freedom from PICs
Post by: donotdespisethesnake on May 16, 2020, 12:08:28 pm
I've had more than one colleague who littered his code with debug printf, he never seemed to learn how to use the debugger. His code was terrible, full of bugs, he really had little clue what he was doing. So not only I had to fix his code, but also remove dozens of debugs statements so that the console was actually usable.

I quickly found a tricky bug with a watchpoint, they had been working for a couple of weeks on it. They had no idea that could be done with the debugger.

The worst thing is they provide guidance for junior engineers, who then copy those bad habits.

He is far from the only "printf maniac" I have encountered. I generally associate debug printf with bad programmers. I really have no idea why they seem to wear it as a badge of honour, it is really an admission of incompetence.

Kinda like the mechanic who turned up with just a hammer. I asked where the rest of his tools were, he explained the hammer was all he needed.
Title: Re: C: freedom from PICs
Post by: andersm on May 16, 2020, 12:29:48 pm
However trying to visually parse the information you want out of debugger output is slow and tiring, and inserting debugger actions at breakpoints using a language that is not quite the same as the language your program is in is both annoying and slows the execution of your program a lot.
That depends on the size of the program. The OP was explicitly asking about something to help learn C, so the programs are probably going to be small excercises. IMO, being able to visualize eg. control flow, loop variables and so on can be helpful under those conditions.
Title: Re: C: freedom from PICs
Post by: SiliconWizard on May 16, 2020, 02:09:56 pm
I never use a debugger. Not on the desktop, not in embedded.
I write temporary code (as described above) that outputs debugging info to the console, a serial port or a file.
It saves a lot of time.

Yeah. I also practically never use a debugger on embedded targets.
For 'non-embedded' targets, I rarely do either. I won't say never - I'll admit there are cases using a debugger will save you time, but I must be resorting to a debugger maybe just a few times a year or so. The exception rather than the rule for me.

There is one relatively common use of debuggers I have witnessed, and that I find wrong (and I'll admit I also used to do this as a beginner): launching a debugging session not to pinpoint a bug, but just to verify your code does what is intended. This is a very loose way of verifying code, and I consider doing that bad practice.
Title: Re: C: freedom from PICs
Post by: HwAoRrDk on May 16, 2020, 03:51:52 pm
There is one relatively common use of debuggers I have witnessed, and that I find wrong (and I'll admit I also used to do this as a beginner): launching a debugging session not to pinpoint a bug, but just to verify your code does what is intended. This is a very loose way of verifying code, and I consider doing that bad practice.

I don't know about that. I would advocate that stepping through code in a debugger to verify it's doing what's intended is a good thing. Obviously, the case of doing so for the sake of "I'm not sure what this code does", or "is this going to work?" shows immaturity and inexperience of one's language and/or tools. But, doing so to verify that there is no unexpected behaviour or side-effects is good.

For instance, you might have some code that shows you correct output, and you may even have unit tests to say that it gives the expected output for a whole slew of input cases. But! You never once stepped through the code in a debugger, following the execution flow and examining all the intermediate processes, so you missed a free() or made an off-by-one error and you have a subtle memory leak or buffer overflow that doesn't get checked by nor affects your test cases, but would cause problems down the road.

I am not a fan of developers who only ever check that the output "looks good to me", and calls it there. I consider that bad practice. On many occasions in the past I have been bitten by someone's code that externally appears to function perfectly, but in fact only happens to work accidentally or is full of side-effects.
Title: Re: C: freedom from PICs
Post by: itdontgo on May 16, 2020, 03:52:54 pm
After programming PICs in assembly for about 20 years I then got lumbered with a project written in C on a Raspberry Pi. I knew nothing but had to fix and update these C programs

The basic Linux C GNU is actually a decent place to start. You don't need an IDE just Notepad++ Most people have a RPi so just get started in a terminal window. To start with I was using GDB to debug the memory but I never use that now. I just output data to the terminal to see what's going on.

Google  gcc raspberry pi to get you started.
Title: Re: C: freedom from PICs
Post by: PerranOak on May 17, 2020, 10:16:57 am
All I really need it for is to get my head around various C concepts so I can then apply these to my PIC work.
Title: Re: C: freedom from PICs
Post by: cdwijs on May 20, 2020, 07:00:43 pm
I think Qt is a very good platform for C code development. It's a big install, but you get a complete IDE. (compiler, editor and debugger)
It can deal with pure C.
Title: Re: C: freedom from PICs
Post by: chriva on May 21, 2020, 07:04:08 am
A few alternatives:

My first choice by far would be to install virtualbox and do things like this in a virtual Linux machine (Debian or Ubuntu).

sudo apt-get install build-essential

Pick editor:
1 download vscode in browser of choice and install it
2 Use gedit or nano.

create a new file and rename it to something  .c
write your code in it
gcc somefilename.c && ./a.out




Alternative two on Windows:

Here is the problem: I've run maaaaany different crosscompilers on windows for embedded targets but I don't know of any free compilers to compile native code on Windows.
You have to do your own research there.
Install any editor you'd like to use. I tend to jump between notepad++ and vscode, sometimes both at the same time :P
type away in powershell or cmd to compile and run it.

Another option would be visual studio community edition and poke around in settings to enable C in your project but their C _SUCKS_!
No c99 features so you have to declare i etc before loops.
As a matter of fact, their compiler is bitching about everything. ALL declarations must be made at the top of the function or it'll throw compile errors. :)
Title: Re: C: freedom from PICs
Post by: Karel on May 21, 2020, 07:07:54 am
Here is the problem: I've run maaaaany different crosscompilers on windows for embedded targets but I don't know of any free compilers to compile native code on Windows.

https://mingw-w64.org (https://mingw-w64.org)
Title: Re: C: freedom from PICs
Post by: chriva on May 21, 2020, 07:13:00 am
I had totally forgotten about that horror but it would indeed do the job :)
Title: Re: C: freedom from PICs
Post by: Karel on May 21, 2020, 07:41:23 am
I had totally forgotten about that horror but it would indeed do the job :)

It's indeed far from ideal, but I have to use it for one project where users demand a windows version.
The other option is no windows version at all and they use Linux, because I refuse to use any microsoft tools.
So, Mingw it is...
Title: Re: C: freedom from PICs
Post by: cedric! on May 21, 2020, 08:18:30 am
I had totally forgotten about that horror but it would indeed do the job :)

It's indeed far from ideal, but I have to use it for one project where users demand a windows version.
The other option is no windows version at all and they use Linux, because I refuse to use any microsoft tools.
So, Mingw it is...

I routinely use the Qt IDE to hide the horror that's mingw from me.
Title: Re: C: freedom from PICs
Post by: chriva on May 21, 2020, 08:28:16 am
Their IDE is almost as bad as the arduino editor.
People have complained for YEARS that they should have tabs like literally everyone else. You think they listen? -NO!  |O
Title: Re: C: freedom from PICs
Post by: Karel on May 21, 2020, 09:47:04 am
I had totally forgotten about that horror but it would indeed do the job :)

It's indeed far from ideal, but I have to use it for one project where users demand a windows version.
The other option is no windows version at all and they use Linux, because I refuse to use any microsoft tools.
So, Mingw it is...

I routinely use the Qt IDE to hide the horror that's mingw from me.

I never use an IDE. I always use Kate on Linux for all development and testing, also for Qt. I don't even use *.ui files for graphical interfaces.
I only use Mingw from the windows commandline to recompile the source in order to offer also a windows version of the project.
But that's only after the Linux version completely done and tested. That way I keep my windows sessions as short as possible  >:D
Title: Re: C: freedom from PICs
Post by: NivagSwerdna on May 21, 2020, 09:48:03 am
I use CLion from JetBrains for cross platform development.  (I am a JetBrains fan-boy)

If you are a student... check out https://education.github.com/pack

An alternative is Visual Studio Code (I assume it has some add-ins) or Visual Studio.

Setting up a C/C++ development environment is a PIA.

PS
I spend lots of my time when developing host programs in the debugger, on the target it tends to be printf and pin wiggling.
Title: Re: C: freedom from PICs
Post by: chriva on May 21, 2020, 09:51:44 am
on the target it tends to be printf and pin wiggling.

You're lucky :D -nostdlib is par for the course when I have to do it so everything has to be from scratch. Granted, setting up a rudimentary printf is quite easy. Just send the string byte-for-byte until a 0 is encountered :)
Title: Re: C: freedom from PICs
Post by: NivagSwerdna on May 21, 2020, 10:31:10 am
You're lucky :D -nostdlib is par for the course
Actually I meant writing serial bytes... I used 'printf' as a generic term rather than a function call.  ;)
Title: Re: C: freedom from PICs
Post by: brucehoult on May 21, 2020, 11:54:11 pm
on the target it tends to be printf and pin wiggling.

You're lucky :D -nostdlib is par for the course when I have to do it so everything has to be from scratch. Granted, setting up a rudimentary printf is quite easy. Just send the string byte-for-byte until a 0 is encountered :)

Well ... that's puts() rather than printf(). A printf() that can handle %s and %d without field widths or number bases is about a dozen lines of code. Adding hex and octal and minimum widths with space or zero padding (99% of what people use) it's probably 50 to 100 lines of code.
Title: Re: C: freedom from PICs
Post by: chriva on May 22, 2020, 12:07:43 am
You could even call the function printfart() if you wanted :p

On a more serious note tho: You are indeed correct.
I tend to use the term as an umbrella for all of them for some stupid reason. -sorry :)
Title: Re: C: freedom from PICs
Post by: westfw on May 22, 2020, 02:40:17 am
Quote
I had totally forgotten about that horror
Mingw is a horror?  I recall it being relatively trivial to install.  I was just using the CLI tools; presumably that would be sufficient for "learning the basics of C"
(or, there is apparently VS Code support for mingw:  https://code.visualstudio.com/docs/cpp/config-mingw (https://code.visualstudio.com/docs/cpp/config-mingw) ) (although my very limited experience with VS Code seems to indicate that it's harder to set up than a CLI based build/compile/debug system...   Perhaps not ideal for short and sweet C training programs...)

Quote
I never use a debugger. Not on the desktop, not in embedded.
And... Are you just learning a new language?
Title: Re: C: freedom from PICs
Post by: westfw on May 22, 2020, 05:55:47 am
oh, If you sort-of think that MPLABX is OK aside from the upload/reprogram/etc cycle, you might want to try installing Netbeans with mingw for "local" compilation.  MPLABX is built on top of NetBeans, and they might be similar (depending on how much customization Microchip has done.)https://netbeans.org/community/releases/80/cpp-setup-instructions.html#compilers_windows
Title: Re: C: freedom from PICs
Post by: mikerj on May 23, 2020, 01:30:17 pm
I have Code::Blocks installed on all the machines I develop on, it will install GCC for you (if you download the full package) and it has a pretty decent IDE.  I use it for developing and unit testing algorithms/numerical functions and for knocking up small utilities for creating/reading files etc.
Title: Re: C: freedom from PICs
Post by: chriva on May 23, 2020, 01:45:15 pm
Had no clue they were still around
If they're anything like they used to I can definitely vouch for this suggestion :)
Title: Re: C: freedom from PICs
Post by: Jan Audio on June 27, 2020, 02:58:19 pm
Go for programming DOS.
It is console window, very easy.
Just about as simple as programming a PIC.

C++ is also good, just dont use classes.
For the rest you can learn, it is about the same.
Title: Re: C: freedom from PICs
Post by: pidcon on June 28, 2020, 10:39:19 am
There are online C compilers which you could try out. It's based on either gcc or clang.

https://www.onlinegdb.com/ (https://www.onlinegdb.com/)
https://repl.it/languages/C (https://repl.it/languages/C)
https://www.jdoodle.com/c-online-compiler/ (https://www.jdoodle.com/c-online-compiler/)

Otherwise, if the compiler has to be in the local Windows computer, I would suggest the C/C++ compiler from Embarcadero. It was used to be Borland's C/C++ compiler. No installation required, just set the user PATH and you're good to go. There are some features in the old compiler which is no longer necessary in the modern compilers.

https://www.embarcadero.com/free-tools/ccompiler (https://www.embarcadero.com/free-tools/ccompiler)

All the best!
Title: Re: C: freedom from PICs
Post by: ebclr on June 29, 2020, 01:18:19 pm
For C only

https://sourceforge.net/projects/orwelldevcpp/ (https://sourceforge.net/projects/orwelldevcpp/)

For c with Pic

https://www.labcenter.com/documents/?350 (https://www.labcenter.com/documents/?350)

Title: Re: C: freedom from PICs
Post by: garethw on June 30, 2020, 10:12:27 pm
Linux user here, so GCC, make, and the like. I use VSCode as my editor.
Title: Re: C: freedom from PICs
Post by: bingo600 on July 01, 2020, 05:10:36 pm
CodeBlocks is a nice & fast IDE

http://www.codeblocks.org/downloads/26 (http://www.codeblocks.org/downloads/26)

Get the one including compiler (GCC)
https://www.fosshub.com/Code-Blocks.html?dwl=codeblocks-20.03mingw-setup.exe (https://www.fosshub.com/Code-Blocks.html?dwl=codeblocks-20.03mingw-setup.exe)

/Bingo
Title: Re: C: freedom from PICs
Post by: NorthGuy on July 05, 2020, 04:43:04 pm
If you want to learn C, I would just take a text editor and a command line compiler. You can use GCC, or download free C/C++ compiler from Microsoft. Write small examples which cover the aspects you want to learn. I don't think a debugger will help here, but it might be nice to be able to look at expanded macros (which can be done by using --save-temps with GCC and watching the .i file). This is because most newbies misunderstand macros.

I would spend couple weeks writing small test programs and watching how they work. Most of things in C are straightforward. But you need to take some time to understand concepts. For example integer promotion is often neglected, but it means a lot, especially for small MCUs where C uses 16-bit integers. Other things which newbies have problems with are logic vs bitwise operations, understanding scope and duration, understanding sequence points, using pointers, understanding how structs are packed. IMHO, it is important to get a good grasp on basic concepts from the onset.
Title: Re: C: freedom from PICs
Post by: pidcon on July 21, 2020, 02:30:30 pm
First-time learners of C (or any programming language) should use an Integrated Development Environment (IDE). It will make your life easier, so that you focus on what is truly important... learning. Not having to deal with system settings, command line settings, terminals, etc. in the early stage of your studies is a good thing. Once you have mastered the language basics and also the environment on which the compiler operates, then you can look at setting up command line compiler tools.
Title: Re: C: freedom from PICs
Post by: westfw on July 21, 2020, 02:56:11 pm
“If your problem  is that you don’t know which compiler to use, and you decide to use an IDE - now you have TWO problems!”

Title: Re: C: freedom from PICs
Post by: SiliconWizard on July 21, 2020, 04:40:49 pm
Quote
I had totally forgotten about that horror
Mingw is a horror?  I recall it being relatively trivial to install.  I was just using the CLI tools; presumably that would be sufficient for "learning the basics of C"

Not sure what you call "mingw" these days. Things have evolved, and the equivalent CLI environment is now MSYS2, which is fine. https://www.msys2.org/ (https://www.msys2.org/)
It's meant to more or less "emulate" a POSIX environment and a Bash shell. If you're used to developing on Linux, or actually need autotools/autoconf, it works fairly well. If you need to build software that use "configure" on Windows, it's the way to go. It has a package manager too, so keeping it up to date is a breeze.

Now if you're fine with basic Windows CLI tools, you don't need MSYS2. You can download various binaries for GCC that don't require MSYS2, and you can also find "make" and other similar tools that will work in a basic Windows console. A nice alternative to the Windows terminal is ConEmu: https://conemu.github.io/en/ (https://conemu.github.io/en/)
Title: Re: C: freedom from PICs
Post by: brucehoult on July 21, 2020, 10:19:41 pm
First-time learners of C (or any programming language) should use an Integrated Development Environment (IDE). It will make your life easier, so that you focus on what is truly important... learning. Not having to deal with system settings, command line settings, terminals, etc. in the early stage of your studies is a good thing. Once you have mastered the language basics and also the environment on which the compiler operates, then you can look at setting up command line compiler tools.

I disagree completely!

Code: [Select]
sudo apt install gcc
<use an editor to create hello.c>
gcc hello.c -o hello
./hello

I don't know what could be easier! Certainly not any IDE I know of.

Sure, you're not going to somehow guess you need the above commands. That's what a tutorial is for. This message is sufficient.
Title: Re: C: freedom from PICs
Post by: Nominal Animal on July 22, 2020, 02:04:33 pm
I fully agree with brucehoult above.

And, at some point, follow up with a couple of quick fifteen-minute sessions on Makefiles, starting with say my "default",
Code: [Select]
CC      := gcc
CFLAGS  := -Wall -O2
LDFLAGS := -lm
PROGS   := example

all: $(PROGS)

clean:
rm -f *.o $(PROGS)

%.o: %.c
$(CC) $(CFLAGS) -c $^

example: main.o other.o
$(CC) $(CFLAGS) $^ $(LDFLAGS) -o $@
and about running sed -e 's|^  *|\t|' -i Makefile to fix indentation to use tabs instead of spaces.  (There are two spaces between ^ and * there.)

Then, a couple of examples on how to debug complex data structures by outputting their structure description in Graphviz dot format, and visualising those.

Then, it would be (in my opinion) time to visit Data Structures and Algorithms.   :)
Title: Re: C: freedom from PICs
Post by: mikerj on July 23, 2020, 09:36:46 am
I disagree completely!

Code: [Select]
sudo apt install gcc
<use an editor to create hello.c>
gcc hello.c -o hello
./hello

I don't know what could be easier! Certainly not any IDE I know of.

Sure, you're not going to somehow guess you need the above commands. That's what a tutorial is for. This message is sufficient.

Your instructions fail when tested on the most popular desktop operating system in the world.
Title: Re: C: freedom from PICs
Post by: Psi on July 23, 2020, 09:42:25 am
When learning C (or C++) I would consider it to be mandatory to have a working Debugger. Settings breakpoints, stepping though the code and inspecting variables during execution is a great learning tool.

I agree that real time debugging is useful.
But. When i encounter a problem that confuses me so much that i reach for the debugger i often find that the problem does not occur while stepping through the code.
The fact of using the debugger makes the problem go away.

It's incredibly annoying and usually ends up being some memory corruption.
Title: Re: C: freedom from PICs
Post by: pidcon on July 23, 2020, 09:44:08 am
First-time learners of C (or any programming language) should use an Integrated Development Environment (IDE). It will make your life easier, so that you focus on what is truly important... learning. Not having to deal with system settings, command line settings, terminals, etc. in the early stage of your studies is a good thing. Once you have mastered the language basics and also the environment on which the compiler operates, then you can look at setting up command line compiler tools.

I disagree completely!

Code: [Select]
sudo apt install gcc
<use an editor to create hello.c>
gcc hello.c -o hello
./hello

I don't know what could be easier! Certainly not any IDE I know of.

Sure, you're not going to somehow guess you need the above commands. That's what a tutorial is for. This message is sufficient.

Fair enough. I've put in my 2 cents as a lecturer. Anyway, the OP is in good hands with the enormous support from the community experts. Signing out.
Title: Re: C: freedom from PICs
Post by: brucehoult on July 23, 2020, 10:28:12 am
I disagree completely!

Code: [Select]
sudo apt install gcc
<use an editor to create hello.c>
gcc hello.c -o hello
./hello

I don't know what could be easier! Certainly not any IDE I know of.

Sure, you're not going to somehow guess you need the above commands. That's what a tutorial is for. This message is sufficient.

Your instructions fail when tested on the most popular desktop operating system in the world.

Quite possibly. The tastes of the majority are notoriously bad. I don't drive a Toyota (or VW) either, though I'm sure many people are happy with them.

No doubt there is some equally easy equivalent there.  I have no idea, as I don't use it. I heard they added Linux and bash and so forth to it now -- surely there is a package manager? There is on the Mac -- there the first line would be "port install gcc" (well there are a couple of alternatives, just as there are others such as rpm on different Linuxes).

The key is just to get the right instructions for what you're using. That's going to be just as much an issue installing an IDE as installing a command line compiler, so is irrelevant to the IDE vs command line discussion.
Title: Re: C: freedom from PICs
Post by: brucehoult on July 23, 2020, 10:50:04 am
First-time learners of C (or any programming language) should use an Integrated Development Environment (IDE). It will make your life easier, so that you focus on what is truly important... learning. Not having to deal with system settings, command line settings, terminals, etc. in the early stage of your studies is a good thing. Once you have mastered the language basics and also the environment on which the compiler operates, then you can look at setting up command line compiler tools.

I disagree completely!

Code: [Select]
sudo apt install gcc
<use an editor to create hello.c>
gcc hello.c -o hello
./hello

I don't know what could be easier! Certainly not any IDE I know of.

Sure, you're not going to somehow guess you need the above commands. That's what a tutorial is for. This message is sufficient.

Fair enough. I've put in my 2 cents as a lecturer. Anyway, the OP is in good hands with the enormous support from the community experts. Signing out.

Oh, sting!

I guess the mean reply is I've taught a few people to program as well, but without the goal of failing half of them in the first semester :-)

If you'd said a debugger and single-stepping and so on is useful for beginners then you'd have a point, except there are perfectly good stand-alone debuggers, including GUI ones, which you can mix and match. It's not necessary or even all that useful to have an *integrated* environment.

I also don't use C as the initial language. Or Java or Python either. They all are far too magical, hiding the details of what is really going on and making it very difficult for the student to form a correct and useful mental model.
Title: Re: C: freedom from PICs
Post by: Yansi on July 23, 2020, 11:14:27 am
I never use a debugger. Not on the desktop, not in embedded.
I write temporary code (as described above) that outputs debugging info to the console, a serial port or a file.
It saves a lot of time.

That simply means you have never done any serious software work.  Blinking LED displays sure may not require any in-circuit debugger, but a real-time DSP application running with 10 DMA channels, ethernet and a GUI interface under a RTOS absolutely requires a debugger and profiler.

Discouraging beginners from using and learning how and when to use such powerful tools from the beginning is silly.
Title: Re: C: freedom from PICs
Post by: Yansi on July 23, 2020, 11:22:52 am
When learning C (or C++) I would consider it to be mandatory to have a working Debugger. Settings breakpoints, stepping though the code and inspecting variables during execution is a great learning tool.

I completely disagree!

That was valuable back when recompiling your program took minutes or even hours.

However trying to visually parse the information you want out of debugger output is slow and tiring, and inserting debugger actions at breakpoints using a language that is not quite the same as the language your program is in is both annoying and slows the execution of your program a lot.

Far better in these days of less than 1 second program builds to do add your temporary debugging code (including any conditional tests) right in the program itself, and use printf or cout to print precisely the information you actually want in exactly the format you want. Send the output to less or to a log file and use your favorite editor or grep or less or perl or whetever you want to search for interesting things in the log.

When finished you can delete the debugging code or else add #IFs to disable it and easily use it again at some later date if you need it.

See my response above.

1 second builds do not happen with complex projects.

Adding debug code to a timing and resource tight embedded application  (what is called "intrusive debugging") is simply not possible in many complex applications. That is what uneducated arduino folks do, because they don't know any better (and even can't learn any better because people who think like you) . And that is where a skilled software engineer brings up his box of tools for non-intrusive debugging.
Title: Re: C: freedom from PICs
Post by: brucehoult on July 23, 2020, 11:56:17 am
I never use a debugger. Not on the desktop, not in embedded.
I write temporary code (as described above) that outputs debugging info to the console, a serial port or a file.
It saves a lot of time.

That simply means you have never done any serious software work.

Lol.

Literally.
Title: Re: C: freedom from PICs
Post by: brucehoult on July 23, 2020, 12:11:16 pm
When learning C (or C++) I would consider it to be mandatory to have a working Debugger. Settings breakpoints, stepping though the code and inspecting variables during execution is a great learning tool.

I completely disagree!

That was valuable back when recompiling your program took minutes or even hours.

However trying to visually parse the information you want out of debugger output is slow and tiring, and inserting debugger actions at breakpoints using a language that is not quite the same as the language your program is in is both annoying and slows the execution of your program a lot.

Far better in these days of less than 1 second program builds to do add your temporary debugging code (including any conditional tests) right in the program itself, and use printf or cout to print precisely the information you actually want in exactly the format you want. Send the output to less or to a log file and use your favorite editor or grep or less or perl or whetever you want to search for interesting things in the log.

When finished you can delete the debugging code or else add #IFs to disable it and easily use it again at some later date if you need it.

See my response above.

1 second builds do not happen with complex projects.

Adding debug code to a timing and resource tight embedded application  (what is called "intrusive debugging") is simply not possible in many complex applications. That is what uneducated arduino folks do, because they don't know any better (and even can't learn any better because people who think like you) . And that is where a skilled software engineer brings up his box of tools for non-intrusive debugging.

Lol again.

I'm pretty sure Nominal Animal, NorthGuy, westfw, to name just a few (in alphabetical order), are highly skilled software engineers. They also happen to be expressing the same views as I am.
Title: Re: C: freedom from PICs
Post by: Siwastaja on July 23, 2020, 06:51:42 pm
The idea that a debugger is somehow magically non-intrusive is blatantly false.

Quite the opposite, the typical usage of debuggers, including breakpoints, single stepping, and memory view which is based on actual bus operations instead of a separate trace interface, is massively intrusive.

Almost all debugging is intrusive; you need to understand how much, and where, and how to cope.
Title: Re: C: freedom from PICs
Post by: SiliconWizard on July 24, 2020, 03:48:42 pm
The idea that a debugger is somehow magically non-intrusive is blatantly false.

Quite the opposite, the typical usage of debuggers, including breakpoints, single stepping, and memory view which is based on actual bus operations instead of a separate trace interface, is massively intrusive.

Almost all debugging is intrusive; you need to understand how much, and where, and how to cope.

Yes, of course. This is especially true when using them on embedded targets, but even with "desktop" programming, particularly as soon as you debug multi-threaded stuff, debugging can be full of suprises.

Another common point related to debuggers is that you may encounter bugs that only manifest themselves (or at least than you can only reproduce) when the code is compiled with optimizations. But optimized code is notoriously hard to debug through a debugger. Sometimes you then have to step through assembly, which can be very tedious and hard to link to the actual source code.

When you mix both aspects, the above example of using debuggers on DSPs running a lot of concurrent stuff (such as DMA) is not necessarily the best, and certainly not the easiest. You really need to know the limitations of debuggers, what you are doing and what you're looking for.

As with any other tools, debuggers have their uses, but you really need to know their limitations and how to use them properly. They are also generally not the first thing to use when trying to track a problem down or just trace code execution. As mentioned above, "manually" sending out debug messages in your code, as "old tech" as it may look to some, is often the most sensible thing to do. If done right, you can completely predict how this will impact code execution, and you can also trace long sequences of events, which is a time saver compared to manual stepping using a debugger. IME, debuggers have now become the last resort in very particular cases, not the first thing I fire up.

Now if we get back to the topic itself - and I guess the use case is starting to write simple C programs on desktop OSs - some people may use, or suggest to use a debugger as a means of understanding how code executes, and as a long as said programs are single-threaded, don't use any fancy OS asynchronous calls, etc, I guess there are few traps to be aware of then. But still, the matter of debugging optimized code may surprise some people, and the fact that optimized code may not behave like non-optimized code as well. This would be an opportunity to see for yourself, though.
Title: Re: C: freedom from PICs
Post by: Yansi on July 24, 2020, 03:52:29 pm
The idea that a debugger is somehow magically non-intrusive is blatantly false.

Quite the opposite, the typical usage of debuggers, including breakpoints, single stepping, and memory view which is based on actual bus operations instead of a separate trace interface, is massively intrusive.

Almost all debugging is intrusive; you need to understand how much, and where, and how to cope.

Sure, so massively intrusive, that your PRINTF through UART is somehow good approach, especially for a resource-limited embedded target, such as the stupid *duino. :bullshit:

Tell that to someone else.
Title: Re: C: freedom from PICs
Post by: Nominal Animal on July 24, 2020, 05:05:37 pm
It is not the debugger nor the method of debugging that matters as much as obtaining the pertinent information and understanding what is happening, that matters.

My favourite example of this is when you have a linked list, tree, or graph, and something goes b0rk.

If you reach for a debugger first, I feel for you.  Sure, debuggers like gdb nowadays are quite extensible (https://stackoverflow.com/a/23970415/13893073), so you can teach them about your data structures so you can query the application state quite effectively, but it is a lot of detective work to find out what exactly did go b0rk with a debugger.

What I do, is have a function emit the structure description in Graphviz dot language to a file, and visualize that.  For example, if I have a binary search tree,
Code: [Select]
struct node {
    struct node *le;
    struct node *gt;
    /* Some payload, say a string: */
    char *data;
};
I habitually write a debugging function for it, something along the lines of
Code: [Select]
static void debug_tree_node(FILE *out, const struct node *node)
{
    fprintf(out, "  \"%p\" [ label = \"%s\" ];\n", node, node->data);
    if (node->le) {
        debug_tree_node(file, node->le);
        fprintf(out, "  \"%p\" -> \"%p\" [ taillabel = \"<=\" ];\n", node, node->le);
    }
    if (node->gt) {
        debug_tree_node(file, node->gt);
        fprintf(out, " \"%p\" -> \"%p\" [ taillabel = \">\" ];\n", node, node->gt);
    }
}
void debug_tree(FILE *out, const struct node *tree)
{
    fprintf(out, "digraph {\n");
    if (tree) debug_tree_node(out, tree);
    fprintf(out, "}\n");
}

While this is obviously a form of "printf debugging", displaying the generated dot graph description via dot -Tx11 output is absolutely indispensable in understanding how things went b0rk, so that one can start finding out why.

(For learners, I actually prefer a more complicated version, that tracks nodes either via a dedicated "visited" field in the structure, or by putting the node addresses in a hash table.  That way the debugging output won't get dazed and confused by cyclic graphs and such.)

When a student sees the (incorrect) tree/graph their code generates, in my experience they are more likely to understand what they did wrong.
The key, of course, is to first understand the b0rk first.  And for that, I claim it does not matter what debugging tool you use, as long as you are efficient about it.

The point where I fire up my debugger, is when I need to know what is happening at the machine code level.  Usually, when I just want to track certain variables etc. in real time in a multithreaded process, I use a dedicated thread to "printf-debug" their changes.  In a couple of cases, I've written my own "debugger" using the ptrace interface, to ensure minimal interference with the target process (Heisenbugs, 'nuf said).  See e.g. here (https://stackoverflow.com/questions/18577956/how-to-use-ptrace-to-get-a-consistent-view-of-multiple-threads/18603766#18603766) for an example one for multithreaded processes I wrote in 2013.

It is perfectly okay if you disagree, but for me, these patterns have proven their worth in real life, both for myself, and as an educational tool, helping others learn.  I'm not writing this to change anyones mind, but to explain the practical reason and experience behind my opinion.
Title: Re: C: freedom from PICs
Post by: Siwastaja on July 24, 2020, 05:38:51 pm
Sure, so massively intrusive, that your PRINTF through UART is somehow good approach, especially for a resource-limited embedded target, such as the stupid *duino. :bullshit:

Obviously, do not just sprinkle printf in random places. That's a complete strawman. Similar strawman would be saying that the only thing you can do in a debugger is to single-step code.
Title: Re: C: freedom from PICs
Post by: neil555 on July 25, 2020, 07:44:14 pm
PellesC for windows is a good free compiler and has an IDE and debugger ...

http://www.smorgasbordet.com/pellesc/ (http://www.smorgasbordet.com/pellesc/)