Get started with C programming

[Armxnian]

Real men code in binary.

[MK14]

Well guys, I don't want to learn Cpp now, I don't even like that language, I got a 1500 page thick book in my bookshelf which I bought for 50 bucks because I taught that Cpp would be the "only way" to write goog PC programms, bit C# does the job... Cpp is way to high for me and currently the market for C programmers (I don't want to programm to earn my money I want ro design PCB) is bigger and C is a bit more universal on small controllers so I do like to start with it. Let the flamwar c vs cpp beginn!
Thanks to everybody who helped me!


Gesendet von iPhone mit Tapatalk

If it is a relatively weak MCU, with limited RAM size (not that much), a lone programmer, and not that big a task for the MCU to do, in terms of size, complexity and other stuff. Then C, can be considered the best tool, in that situation, by many.

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

In between, there are all sorts of factors that can be taken into consideration, to help choose between the C or C++.

Don't forget that if you become VERY experienced in programming with C. It is NOT that much of a task, to upgrade yourself to C++. Whether that involves course(s), books, self-taught, etc etc. Is up to you.

If you became very competent and experienced in BOTH C and C++ (Cpp), you would have a tremendous range of jobs. Because you could go for C OR C++ ones.

[MK14]

Real men code in binary.

The trinary patch cords, for my quad Valve/tube, Circa 1941 computer, does NOT count then!

[Boomerang]

A good C complier can produce much better code than even the best assembly language programmers.

No chance. Many many years must pass before people become so dumb and compilers become so intelligent to outperform them... 

[Armxnian]

The trinary patch cords, for my quad Valve/tube, Circa 1941 computer, does NOT count then!

Hmm 1941... seems hardcore enough. I'll let it pass.

[MK14]

A good C complier can produce much better code than even the best assembly language programmers.

No chance. Many many years must pass before people become so dumb and compilers become so intelligent to outperform them... 

+1
As I understand the situation, it's a common myth, that I often hear.

Analogy: if a normal (non-racing) driver, drove their normal car on a very high speed test track. They can probably achieve much faster track times, than when they drive a formula 1 car, and end up spinning out of control all over the place, and messing up the driving completely. Hence achieving a considerably longer track time.

This does NOT mean that their car is considerably faster than a formula 1 car.

It just means they needed to get the stig or a competent formula 1 racing driver to drive it. Then the Formula 1 car will have a considerably better track time.

So yes, I agree that hopeless assembly language programmers, can mess up the programming so badly, that even a C compiler can beat their code.

But just like the stig or a good racing driver, a "real" quality assembly language programmer, can achieve very good results.

I'm NOT sure how much faster a modern day, quality assembly language programmer, could/would beat a good C compiler.

I'd love to know, but don't really have the time to try it (I'd have a partial learning curve as well, maybe eventually), and it is very difficult to get the right people to try it out.

[Karel]

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

You mean something like the Linux kernel?

[nctnico]

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

You mean something like the Linux kernel?

Actually the whole Linux kernel is object oriented programming emulated in C. The Linux kernel is the biggest mess I have ever seen and a prime example why you should program object oriented programs (large projects) in C++. If they rewrite the Linux kernel in C++ it will be faster, smaller (both code and binary), less buggy and easier to maintain.

[MK14]

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

You mean something like the Linux kernel?

Then why bother using C++? Let's use Python, Ruby or Node.js.

There are lots of potentially good languages. But some of the scripting (interpreted) ones, can be rather inefficient at their cpu processing time consumption. But it gets complicated with languages like Java, or others, when they use JIT and stuff, because that can compile it on the fly, to be approaching or maybe even faster (because of late, run time compiling, knowing what is going on), than even compiled C/C++ code.

Anyway, cpus have become so fast that scripting (interpreted) languages, don't matter that much, these days. (For 80/90%+ of software it is good enough (scripting). There are still many things which need/require the full cpu speed, available on properly compiled languages, such as C/C++ and Pascal etc).

It's kind of ironic, that C was a big part of the early (in recent times), computing history. It even still drives much of the internet, at the lowest level.

But most website languages, are NOT C or C++. In fact to use C/C++ to make a website, is not that straight forward.

C/C++ was originally designed at a time, when the internet was NOT known about, or even much predicted. Consequently, C/C++ lacks features to help website/browser/mobile-apps etc. I feel a bit sad for C/C++ in that respect.

E.g. Android phones (when I last checked), much prefer Java to C/C++. Unless you root the phone.

[Howardlong]

My advice: Forget the crap they call C++ and stick with plain C only.

Noooooo! C++ is the next 'big thing' for microcontrollers because C++ allows to circumvent the parts of C which are so error prone: pointers and you can put an entire module in it's own class so there is much less worry about name clashes with other modules. Also the ability to have fine grained control over which parts of the code can touch which variables is worth a lot because it makes code more predictable. Forget whatever negative is being said about C++ because it is either not true or not a problem in the real world. After all C++ works just fine.

The namespace thing certainly has value, but it's all the other nonsense that concerns me: the more things are abstracted, the slower and more bloated things get. Most programmers fresh out of college nowadays have a big disconnect between the code they write and how it works under the hood. The beauty of C in embedded terms is that you're always close to the metal, things tend to be fairly explicit.

Although learning the basics on a PC is a reasonable start, at the same time it should be noted that it's not the same. In particular, you have to be pretty careful about using standard library functions, they are often inappropriate on resource limited embedded platforms. printf, for example, can be quite the beast, and that's generally the first bit of code a C programmer would write on a PC platform.

[legacy]

But if it is a massively (overpowered) MCU, with huge amounts of RAM, in an extremely complicated embedded/electronics environment, with hugely complicated and multi-layered network/database communications protocols and storage control systems. Programmed by a HUGE, world wide team, over a VERY long period of time.
Then C++ is then considered as showing significant advantages, by many.

You mean something like the Linux kernel?

Actually the whole Linux kernel is object oriented programming emulated in C. The Linux kernel is the biggest mess I have ever seen and a prime example why you should program object oriented programs (large projects) in C++. If they rewrite the Linux kernel in C++ it will be faster, smaller (both code and binary), less buggy and easier to maintain.

I agree

[Philfreeze]

Actually the whole Linux kernel is object oriented programming emulated in C. The Linux kernel is the biggest mess I have ever seen and a prime example why you should program object oriented programs (large projects) in C++. If they rewrite the Linux kernel in C++ it will be faster, smaller (both code and binary), less buggy and easier to maintain.

There i fixed it for you.
Just an assumption but I don't think it will be faster or smaller but definetly much much easier to maintain. They should do it though because the speed you lose and the size you gain will be absolutely minimal but it would be much easier to maintain.

[nctnico]

My advice: Forget the crap they call C++ and stick with plain C only.

Noooooo! C++ is the next 'big thing' for microcontrollers because C++ allows to circumvent the parts of C which are so error prone: pointers and you can put an entire module in it's own class so there is much less worry about name clashes with other modules. Also the ability to have fine grained control over which parts of the code can touch which variables is worth a lot because it makes code more predictable. Forget whatever negative is being said about C++ because it is either not true or not a problem in the real world. After all C++ works just fine.

The namespace thing certainly has value, but it's all the other nonsense that concerns me: the more things are abstracted, the slower and more bloated things get. Most programmers fresh out of college nowadays have a big disconnect between the code they write and how it works under the hood. The beauty of C in embedded terms is that you're always close to the metal, things tend to be fairly explicit.

At some point you have to take a look under the hood to see what is creating a lot of code but a C++ class is nothing more than a struct with data elements and functions pointers. All in all it is very efficient and does not contain any nonsense. It is a lot like the assembly versus C debates. People think C is more bloated because they don't know what is happening under the hood and assume the worse based on their fear of change.

Although learning the basics on a PC is a reasonable start, at the same time it should be noted that it's not the same. In particular, you have to be pretty careful about using standard library functions, they are often inappropriate on resource limited embedded platforms. printf, for example, can be quite the beast, and that's generally the first bit of code a C programmer would write on a PC platform.

The concerns about standard library functions is completely unfounded. In order to re-use code one should try to use the standard library functions (POSIX) as much as possible. For embedded platforms there are lightweight libraries. C was developed on very space constrained machines so the API of the standard library functions is very much tailored to keep the memory requirements to a minimum Also keep using printf! The mistake I often see is that people are trying to create their own convoluted string printing functions and while doing so they sooner or later link the printf core in as well besides their own crap functions. If the printf core is too big then the best way around it is to create a minimal printf function which is compatible with the normal printf but can be tailored to your needs if necessary.

Actually the whole Linux kernel is object oriented programming emulated in C. The Linux kernel is the biggest mess I have ever seen and a prime example why you should program object oriented programs (large projects) in C++. If they rewrite the Linux kernel in C++ it will be faster, smaller (both code and binary), less buggy and easier to maintain.

There i fixed it for you.
Just an assumption but I don't think it will be faster or smaller but definetly much much easier to maintain. They should do it though because the speed you lose and the size you gain will be absolutely minimal but it would be much easier to maintain.

I have done quite a bit of hacking in the Linux kernel and there are many places where a compiler would be able to optimise a lot in terms of speed. In many places in the Linux kernel you need to go several stages deep into children/parents in runtime to get to certain information even though that information can be obtained at compile time.

[MK14]

There are lots of potentially good languages. But some of the scripting (interpreted) ones, can be rather inefficient at their cpu processing time consumption. But it gets complicated with languages like Java, or others, when they use JIT and stuff, because that can compile it on the fly, to be approaching or maybe even faster (because of late, run time compiling, knowing what is going on), than even compiled C/C++ code.

That's why I say it is possible to use script languages. I'm a big fan of JIT. I'm now working on a finite element engine that is supposed to support user expression input, and apparently it is not appropriate to run a string expression evaluation program in each iteration on each dynamic material of each meshed unit. Also, this allows me to implement AVX or SSE whenever these extensions are available without forcing the users to know how to program on SIMD. I can not imagine how slow the program is if I did not use JIT (actually bytecode based solution is kinda okay also, but string parsing is just plain horrible), despite I have to say writing a JIT compiler, even only for math expressions, is not easy.

You'd probably find if you write more JIT compiler sub-sections. You would find it gets much quicker and easier each time (hopefully, your mileage may vary).
I'm wondering how good AVX-512 is going to be (ignoring Knights based computers), when it eventually surfaces. Then an even longer wait until it comes to mainstream, I7 etc cpus. (if at all, depending on how Intel are planning on doing things).

Yes, that is an amazing use of JIT. Just the sort of thing, which would give a HUGE speed up factor.

Essentially a typical C/C++ program would re-interpret it each pass. Potentially taking ages. But a high/top end C/C++ programmer, may have ideas, to significantly speed up that process, WITHOUT JIT.
E.g. to translate the reg ex (etc), into what amounts to a large look-up table of function pointers.

So Pass1 (When the C/C++) runs, would interpret the reg-ex into array(s) of function pointers, and stuff.
Then on pass2..etc, the C/C++ can directly access the already interpreted reg-ex, by calling the array of function pointers, directly.

There are other ways of doing it, fast. I may NOT know enough about the specifics of what you are doing, to correctly describe a very fast non-JIT solution. So my apologies in advance. I could easily be misunderstanding your requirements.

There are often/usually MANY ways of doing things quickly and efficiently.

There have been Basic (language) interpreters, which do a similar thing. I.e. as they run through the code (interpreting it), it remembers what it needs to do. So after it has run for a while, it considerably speeds up, as it mostly ignores the source code, and directly does what it needed to do, directly. If I remember correctly, I think it went as far as remembering the actual machine code to perform, for each line. If I'm mistaken then it was a JVM (bytecode) like (p-code), mechanism instead.

BUT I have to concede that if your JIT solution, means that it goes to SSE/AVX/AVX2 (or whatever). It could still potentially beat even a fairly well written C/C++ program. The array of function pointers, is probably significantly slower than JIT compiled code, as the JIT can just put the desired/needed instructions, straight into the new code.

So on second thoughts, this JIT thing, could still be a dramatic speed/efficiency improvement.

[MK14]

You'd probably find if you write more JIT compiler sub-sections. You would find it gets much quicker and easier each time (hopefully, your mileage may vary).
I'm wondering how good AVX-512 is going to be (ignoring Knights based computers), when it eventually surfaces. Then an even longer wait until it comes to mainstream, I7 etc cpus. (if at all, depending on how Intel are planning on doing things).

Yes, that is an amazing use of JIT. Just the sort of thing, which would give a HUGE speed up factor.

Essentially a typical C/C++ program would re-interpret it each pass. Potentially taking ages. But a thigh/top end C/C++ programmer, may have ideas, to significantly speed up that process, WITHOUT JIT.
E.g. to translate the reg ex (etc), into what amounts to a large look-up table of function pointers.

So Pass1 (When the C/C++) runs, would interpret the reg-ex into array(s) of function pointers, and stuff.
Then on pass2..etc, the C/C++ can directly access the already interpreted reg-ex, by calling the array of function pointers, directly.

There are other ways of doing it, fast. I may NOT know enough about the specifics of what you are doing, to correctly describe a very fast non-JIT solution. So my apologies in advance. I could easily be misunderstanding your requirements.

There are often/usually MANY ways of doing things quickly and efficiently.

There have been Basic (language) interpreters, which do a similar thing. I.e. as they run through the code (interpreting it), it remembers what it needs to do. So after it has run for a while, it considerably speeds up, as it mostly ignores the source code, and directly does what it needed to do, directly. If I remember correctly, I think it went as far as remembering the actual machine code to perform, for each line. If I'm mistaken then is was a JVM (bytecode) like (p-code), mechanism instead.

BUT I have to concede that if your JIT solution, means that it goes to SSE/AVX/AVX2 (or whatever). It could still potentially beat even a fairly well written C/C++ program. The array of function pointers, is probably significantly slower than JIT compiled code, as the JIT can just put the desired/needed instructions, straight into the new code.

So on second thoughts, this JIT thing, could still be a dramatic speed/efficiency improvement.

So far the speed is not good -- marginally better than bytecode based solution, because I do memory access on every object at every time (tons of MOV and LEA) -- no optimum register allocation for reusing, I essentially used only few registers to do basic calculations. Memory structure of meshed objects are scalar objects, so they got packed and unpacked in each iteration, and since I'm very unfamiliar with SIMD, I'm only trying to use most basic SSE. On the other hand, GCC managed to optimize my bytecode executing routine well, and since it takes in several objects in and several out, it even manages to auto vectorize my code (of course with lots of assumptions and alignment directives).

I think I need to learn much more in compilers, but maybe not now -- I'm not doing research on compilers at all. I'm pursuing my PhD in power electronic packaging technique, and the only purpose of this simulator is to get me access to FEA tool without having to use out COMSOL workstation.

I have heard that the JIT, and especially JVM, takes ages to sort it self out (while it is compiling etc). So although it eventually reaches a nice high execution speed. IT can take a while, before that happens.
What you are doing sounds like FUN!
There are WAY too many things that you can/should/must learn in with high tech stuff. But because it is changing all the time, and so quickly as well. There is no way (being realistic), us mere humans can keep up.
You may well find, that at various times during your career, you have to make decisions as to go left, stay, right or something.
There is just not enough time in the day, to do everything and learn everything.

tl;dr
So if you had learned/practiced with compilers, you may NOT have had time to learn/practice PID control loops, and/or climb the SSE learning curve.

What annoys me (to an extent), about us humans, is that I learn and use a particular programming language or Electronics related skill, for quite a long while. Then I don't do it for 10 years, for whatever reason.
Then (usually, unless you have brains the size of mars!), you find that you have mostly forgotten how to do it.

E.g. When I was younger. I could partially solve a Rubik's cube, and with a guide book, fairly quickly, solve it completely.

Give me a Rubik's cube now (I have not used one in quite a while), I imagine I would be completely hopeless, and I've mostly forgotten how I did it.

Anyway, good luck with the super duper control stuff and things!
You're making me somewhat jealous!

[Philfreeze]

The concerns about standard library functions is completely unfounded. In order to re-use code one should try to use the standard library functions (POSIX) as much as possible. For embedded platforms there are lightweight libraries. C was developed on very space constrained machines so the API of the standard library functions is very much tailored to keep the memory requirements to a minimum Also keep using printf! The mistake I often see is that people are trying to create their own convoluted string printing functions and while doing so they sooner or later link the printf core in as well besides their own crap functions. If the printf core is too big then the best way around it is to create a minimal printf function which is compatible with the normal printf but can be tailored to your needs if necessary.

I have done quite a bit of hacking in the Linux kernel and there are many places where a compiler would be able to optimise a lot in terms of speed. In many places in the Linux kernel you need to go several stages deep into children/parents in runtime to get to certain information even though that information can be obtained at compile time.

1. if the printf core is too big I would just use the lightweight function (usually you can tell the compiler which version he should use), actually, I would always use the lightweight function on embedded systems. You don't really need more most of the time. (the only thing the lightweight printf can't to which you might need is print a floating point number directly)

2. At least the two c++ compilers I tried actually just kept the jumps as jumps. So as an example if I have foo() in another namespace/class and I use it from my main() the compiler will make a pointer to the function pointer in the namespace/class structure where the actual pointer is stored. This means it needs exactly as many steps as in C but maybe I am just bad with compiler settings 
But as I said, like you I think they should use C++ for the Linux Kernel.

[obiwanjacobi]

Put in the time and make lots of mistakes. That is how you learn anything.

[Karel]

I have more trust in the opinion of Linus Torvalds, a person that leads world's most used operating system.

http://harmful.cat-v.org/software/c++/linus

[nctnico]

I have more trust in the opinion of Linus Torvalds, a person that leads world's most used operating system.

http://harmful.cat-v.org/software/c++/linus

The fact the pope says people shouldn't use condoms doesn't make him right. The same goes for Linus. If you actually cared to read the post then you'd clearly read Linus thinks he is the god of programming and only he is right. That has all the signs of blind religious fanatism which (as history has shown many times) is holding back actual progress. Linux would be better off if Linus stopped being the boss and leave the project to people who are able to carry it into the 21st century. The biggest problem for Linux being useful as a mainstream OS are people like Linus.

[Karel]

The biggest problem for Linux being useful as a mainstream OS are people like Linus.

I'm not aware of that problem. Linux is the most used operating system thanks to it's usefulness,
robustness, reliability and ability to adapt. Credits to people like Torvalds for accomplishing that.

[nctnico]

The biggest problem for Linux being useful as a mainstream OS are people like Linus.

I'm not aware of that problem. Linux is the most used operating system thanks to it's usefulness,
robustness, reliability and ability to adapt. Credits to people like Torvalds for accomplishing that.

Now the downside: due to ever changing APIs, driver models, lack of proper documentation, etc supporting Linux kernel device drivers for their hardware is a real nightmare for any manufacturer. This is one of the severe problems which is holding Linux back and Linus is directly responsible for that.

[Karel]

... severe problems which is holding Linux back and Linus is directly responsible for that.

Becoming the most used operating system in the world isn't something I would call "holding back".

[Philfreeze]

any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

That is an argument but I think most of the arguments he makes are just stupid.
(kind of including this one actually)

Nobody says that the Linux Kernel would have to use every feature C++ has and even less does it mean that they have to use the standard library.
I don't think he should use everything C++ can but it would be intelligent to use parts of C++ like classes, private-public syntax, namespaces and some more.
Alone for this things it would be nice to use C++ instead of C.

Problem is, Linus is known to be pretty excentric and he doesn't like being wrong.


P.S.
I don't have anything against C, actually I almost always use C and I don't have that much C++ experience.

[97hilfel]

Well I think I'm going to start with a simple Blink example on a AtMega328 and baybe on a small PIC...


Gesendet von iPhone mit Tapatalk

[MK14]

Well I think I'm going to start with a simple Blink example on a AtMega328 and baybe on a small PIC...


Gesendet von iPhone mit Tapatalk

That's a good idea. You can then progress in iterative stages.

Jumping in TOO deep, especially early on, can be counter productive.

At first, you may find that even the tiniest of programs, has a number of problems to solve. Such as weird compiler errors, and then the fact that it may not work at first.

Press on and be patient. Thing should soon/gradually improve.

Then come back here and argue with mini-flame (Linux/C/C++) wars!