Get started with C programming - Page 1
Forum section: electronics / general

author: 97hilfel
author_rank: Regular Contributor
timestamp: March 06, 2016, 09:14:31 pm
content: Hello everybody,I'm currently in my final highschool year (in Italy so don't comare it directly to USA or somewhere else).I wanted to learn how to program on microcontrolers last year in school we learned to program Assamby and a little bit Arduino,but I want to learn real C.Currently I'm working on a project and using a Atmel SAM D20 and I'm currently stuck with programming, because I can program but I don't know how to programm efficently on controllers.I hope somebody can help me.Felix

author: ataradov
author_rank: Super Contributor
timestamp: March 06, 2016, 09:35:31 pm
content: Quote from: 97hilfel on March 06, 2016, 09:14:31 pmThat is something you will have to learn over time, there is not a single piece of advice that can help.My recommendation is to not use manufacturer libraries (ASF in case of Atmel) and program MCU directly. It is more work upfront, but greater benefit in a long run.I have a number of very simple starter projects (D20 included) herehttps://github.com/ataradov/mcu-starter-projectsYou can take that and expand it as you need.

author: 97hilfel
author_rank: Regular Contributor
timestamp: March 06, 2016, 09:40:39 pm
content: Well, I still need to get into C programing because Im used to C# on a pc where it doesn't matter how much memory you use (till you be under 2gb)Gesendet von iPhone mit Tapatalk

author: ataradov
author_rank: Super Contributor
timestamp: March 06, 2016, 09:46:01 pm
content: Quote from: 97hilfel on March 06, 2016, 09:40:39 pmThat's easy. Just start with whatever you were doing in C# and you will be forced to come up with better solutions, since your stuff won't fit into the device.But really, it is not that bad. On the MCU you are limited by the hardware you have, so it is reasonably easy to account for all the things that are consuming memory. In a typical project there will be very few big consumers (like buffers) and it is easy to calculate memory requirements upfront. Most projects are not that critical to memory and the main constraint is a CPU performance.There is not much you can do, but start doing things and optimizing as you go.

author: MK14
author_rank: Super Contributor
timestamp: March 06, 2016, 10:03:45 pm
content: Quote from: 97hilfel on March 06, 2016, 09:14:31 pmThere are a lot of C program resources on the internet, including many free book(often PDF) downloads.Some are even Embedded/Microcontroller CSuch as this one:http://learn.mikroe.com/ebooks/piccprogramming/front-matter/introduction/http://freecomputerbooks.com/langCBooks.htmlGoogle can be good for finding them.

author: RobertGogol
author_rank: Unknown
timestamp: March 06, 2016, 10:19:18 pm
content: I would recommend what I did:Learn C++ specific to program and understand 8bit AVR MCU - most important thing, even more important than learning C++ is how to compile program and upload it to MCU using programmer like simple and cheap Fishl USB - I mean leaving proto board and use standalone MCU with your own projects. It is hard at the beginning (especially working with compiler and AVRdude from... command line) but everything is explained here, and it is cheap and easy:http://hackaday.com/2010/10/23/avr-programming-introduction/and first blinking LED on breadboard with atmega16 is so beautifull!!I've looked at mine over hoursGood luck!

author: MSO
author_rank: Contributor
timestamp: March 07, 2016, 01:58:36 am
content: Learning C is one of the most beneficial things you can do for your career. Don't let anyone tell you that it's inefficient or that assembly will run rings around a C program; that's false, even when writing firmware. A good C complier can produce much better code than even the best assembly language programmers. When it comes to highly optimized code and near universal availability, from the smallest MCU to the largest mainframe computers, no other language comes close. (With the possible exception of C++.)Pickup a copy of "The C Programming Language" by Brian W. Kernighan & Dennis M. Ritchie and read it from cover to cover, twice. Pay special attention to the difference between the C language itself and its compilers and libraries. Don't, as many new to the language are wont to do, confuse the C language with its compilers and its libraries; the latter two can vary substantially in quality and efficiency but can easily be replaced with better implementation fro different vendors.http://www.amazon.com/The-Programming-Language-Brian-Kernighan/dp/0131103628Good luck with your new venture.

author: dannyf
author_rank: Super Contributor
timestamp: March 07, 2016, 02:20:15 am
content: QuoteThe biggest lesson I have learned over the years is to code with a goal to never code it again: whenever you write a piece of code, always think about how you can write it so that it can be reused later for a different project.To do that, you will need to write modular code; code with well defined inputs and outputs; code that's well debugged, etc. In the end, you learn a lot more than just coding.

author: nctnico
author_rank: Super Contributor
timestamp: March 07, 2016, 07:58:29 am
content: I'd start with programming C and C++ on a PC because it is much easier to test and debug code on a PC. A good excersize is to create a module which emulates the hardware (for example reading data from a file and the results to a file) and a module which is your microcontroller's firmware. This isn't sexy but it is a good step towards unit testing your firmware.

author: rx8pilot
author_rank: Super Contributor
timestamp: March 07, 2016, 08:21:16 am
content: Quote from: nctnico on March 07, 2016, 07:58:29 am+1Sent from my horrible mobile....

author: Jeroen3
author_rank: Super Contributor
timestamp: March 07, 2016, 08:29:33 am
content: Quote from: dannyf on March 07, 2016, 02:20:15 amThis. The amount of people that blob some code into a single file, pray for it to work, and never look at it again. Is way too high.The code becomes unmaintainable and only the original writer can make something of it for the next ~2 months.Any time later it will be cheaper to just start over. Hours are not free.But to learn code there is only 1 thing you can do: Read code. Other peoples code.Find reputable C libraries and project, and read the code. See what they are doing, recognize the architecture.

author: Brutte
author_rank: Frequent Contributor
timestamp: March 07, 2016, 10:18:19 am
content: Quote from: rx8pilot on March 07, 2016, 08:21:16 am+2Sent from my bathroom....

author: Karel
author_rank: Super Contributor
timestamp: March 07, 2016, 11:03:02 am
content: My advice: Forget the crap they call C++ and stick with plain C only.And buy this book:http://shop.oreilly.com/product/0636920033844.doAnd no, I'm not going to let me drag into a C vs. C++ flamewar so I'm not going to explain why C is so much better than C++ (for MCU's).

author: Philfreeze
author_rank: Regular Contributor
timestamp: March 07, 2016, 11:44:05 am
content: Well, to learn the C langugage there is only one "true" guide written by one of the creators of C (Ritchie) and prof. Kernighan.http://www.ime.usp.br/~pf/Kernighan-Ritchie/C-Programming-Ebook.pdf

author: legacy
author_rank: Super Contributor
timestamp: March 07, 2016, 11:57:11 am
content: I sugget to be focused on "design" instead of C coding

author: ElektroQuark
author_rank: Unknown
timestamp: March 07, 2016, 12:21:12 pm
content: About original work of K&R, don't do C evolve a bit?Is the K&R book up to date?

author: 97hilfel
author_rank: Regular Contributor
timestamp: March 07, 2016, 12:52:12 pm
content: Quote from: MSO on March 07, 2016, 01:58:36 amWell I can program assambly Inlearned it on a AW32 Freescale controller and I hated it... Because you can't implement much in assamby code and can do a lot of errors... I will read trough the rest of the awnsers later after schoolGesendet von iPhone mit Tapatalk

author: Philfreeze
author_rank: Regular Contributor
timestamp: March 07, 2016, 01:49:40 pm
content: Quote from: EdoNork on March 07, 2016, 12:21:12 pmIt evolved a bit but the the "big" new thing you will have to learn on top of K&R is the whole embedded stuff (register access, interrupts etc.)

author: nctnico
author_rank: Super Contributor
timestamp: March 07, 2016, 02:46:35 pm
content: Quote from: Karel on March 07, 2016, 11:03:02 amNoooooo! 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.

author: 97hilfel
author_rank: Regular Contributor
timestamp: March 07, 2016, 03:31:05 pm
content: 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

author: 97hilfel
author_rank: Regular Contributor
timestamp: March 07, 2016, 03:34:39 pm
content: And what Im going to do these days:Finish the asf program and grab my atmega 328PU and code on it a bit (got some of them lying around for my Arduino uno)Gesendet von iPhone mit Tapatalk

author: Dielectric
author_rank: Regular Contributor
timestamp: March 07, 2016, 03:58:51 pm
content: I've been writing C for a couple of decades now, and still found this to be helpful when I found it last year:http://c.learncodethehardway.org/book/It's a pretty badass way to learn C, and he pulls no punches about how C can really screw you over.I'm also implementing many of the ideas from Patterns in C:https://leanpub.com/patternsincHaving a structured way to attack a problem set is awesome, because IF you're diligent about the implementation, you can come back to it later and understand what you were thinking at the time. Very important! I find that a lot of the ideas pulled from OO languages are really useful in C, like function pointers and structures. There are some pretty good arguments for using C++ for embedded programming (great interview on embedded.fm's podcast, episode 137 with Dan Saks):http://embedded.fm/episodes/137Having said that, I actually don't know C++ and have only done a tiny bit of Java and Objective C so I could be totally snowed over and wrong.

author: rsjsouza
author_rank: Super Contributor
timestamp: March 07, 2016, 04:18:05 pm
content: I am usually a learner by example, therefore the approach I would take is:Start with something step-by-step such as:https://github.com/sagarsp/arduino-blink-chttps://balau82.wordpress.com/arduino-in-c/Once you have something running you can start understand its functionality, compare its structure with one of the books you bought, exploring and experimenting with it.BTW, if you don't have a Linux machine and have the bandwidth, you can downloadVirtualBoxand one of the pre-configured images fromhere. Or download VirtualBox and create your own.

author: legacy
author_rank: Super Contributor
timestamp: March 07, 2016, 04:59:11 pm
content: Quote from: 97hilfel on March 06, 2016, 09:14:31 pm"ITIS"?if so, { electronics, telecom, computer science } ?

author: 97hilfel
author_rank: Regular Contributor
timestamp: March 08, 2016, 05:57:50 am
content: Quote from: legacy on March 07, 2016, 04:59:11 pmElectronics...Gesendet von iPhone mit Tapatalk

author: Armxnian
author_rank: Regular Contributor
timestamp: March 08, 2016, 06:45:35 am
content: Real men code in binary.

author: MK14
author_rank: Super Contributor
timestamp: March 08, 2016, 06:47:35 am
content: Quote from: 97hilfel on March 07, 2016, 03:31:05 pmIf 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.

author: MK14
author_rank: Super Contributor
timestamp: March 08, 2016, 06:49:37 am
content: Quote from: Armxnian on March 08, 2016, 06:45:35 amThe trinary patch cords, for my quad Valve/tube, Circa 1941 computer, does NOT count then!

author: Boomerang
author_rank: Regular Contributor
timestamp: March 08, 2016, 07:03:42 am
content: Quote from: MSO on March 07, 2016, 01:58:36 amNo chance. Many many years must pass before people become so dumb and compilers become so intelligent to outperform them...

author: Armxnian
author_rank: Regular Contributor
timestamp: March 08, 2016, 07:07:41 am
content: Quote from: MK14 on March 08, 2016, 06:49:37 amHmm 1941... seems hardcore enough. I'll let it pass.

author: MK14
author_rank: Super Contributor
timestamp: March 08, 2016, 07:26:33 am
content: Quote from: Boomerang on March 08, 2016, 07:03:42 am+1As 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.

author: Karel
author_rank: Super Contributor
timestamp: March 08, 2016, 07:38:17 am
content: Quote from: MK14 on March 08, 2016, 06:47:35 amYou mean something like the Linux kernel?

author: nctnico
author_rank: Super Contributor
timestamp: March 08, 2016, 08:03:35 am
content: Quote from: Karel on March 08, 2016, 07:38:17 amActually 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.

author: MK14
author_rank: Super Contributor
timestamp: March 08, 2016, 08:28:34 am
content: Quote from: blueskull on March 08, 2016, 07:52:00 amThere 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.

author: Howardlong
author_rank: Super Contributor
timestamp: March 08, 2016, 08:43:32 am
content: Quote from: nctnico on March 07, 2016, 02:46:35 pmThe 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.

author: legacy
author_rank: Super Contributor
timestamp: March 08, 2016, 09:10:12 am
content: Quote from: nctnico on March 08, 2016, 08:03:35 amI agree

author: Philfreeze
author_rank: Regular Contributor
timestamp: March 08, 2016, 09:16:14 am
content: Quote from: nctnico on March 08, 2016, 08:03:35 amThere 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.

author: nctnico
author_rank: Super Contributor
timestamp: March 08, 2016, 09:22:19 am
content: Quote from: Howardlong on March 08, 2016, 08:43:32 amAt 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.QuoteThe 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.Quote from: Philfreeze on March 08, 2016, 09:16:14 amI 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.

author: MK14
author_rank: Super Contributor
timestamp: March 08, 2016, 09:22:59 am
content: Quote from: blueskull on March 08, 2016, 09:05:15 amYou'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.

author: MK14
author_rank: Super Contributor
timestamp: March 08, 2016, 09:56:44 am
content: Quote from: blueskull on March 08, 2016, 09:37:20 amI 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;drSo 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!

author: Philfreeze
author_rank: Regular Contributor
timestamp: March 08, 2016, 10:19:21 am
content: Quote from: nctnico on March 08, 2016, 09:22:19 am1. 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 settingsBut as I said, like you I think they should use C++ for the Linux Kernel.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 08, 2016, 10:37:57 am
content: Put in the time and make lots of mistakes. That is how you learn anything.

author: Karel
author_rank: Super Contributor
timestamp: March 08, 2016, 12:29:05 pm
content: 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

author: nctnico
author_rank: Super Contributor
timestamp: March 08, 2016, 12:38:09 pm
content: Quote from: Karel on March 08, 2016, 12:29:05 pmThe 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.

author: Karel
author_rank: Super Contributor
timestamp: March 08, 2016, 12:55:01 pm
content: Quote from: nctnico on March 08, 2016, 12:38:09 pmI'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.

author: nctnico
author_rank: Super Contributor
timestamp: March 08, 2016, 01:15:27 pm
content: Quote from: Karel on March 08, 2016, 12:55:01 pmNow 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.

author: Karel
author_rank: Super Contributor
timestamp: March 08, 2016, 01:27:13 pm
content: Quote from: nctnico on March 08, 2016, 01:15:27 pmBecoming the most used operating system in the world isn't something I would call "holding back".

author: Philfreeze
author_rank: Regular Contributor
timestamp: March 08, 2016, 03:45:43 pm
content: Quote from: Linus TorvaldsThat 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.

author: 97hilfel
author_rank: Regular Contributor
timestamp: March 08, 2016, 04:06:25 pm
content: 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

author: MK14
author_rank: Super Contributor
timestamp: March 08, 2016, 04:11:42 pm
content: Quote from: 97hilfel on March 08, 2016, 04:06:25 pmThat'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!

author: 97hilfel
author_rank: Regular Contributor
timestamp: March 08, 2016, 04:15:36 pm
content: Well, its nice to see that Dave got such a big and good community. This Weekend Im going to try some examples, and baybe I try to get a UART module running... Would be a big goal.Gesendet von iPhone mit Tapatalk

author: MSO
author_rank: Contributor
timestamp: March 09, 2016, 12:44:51 am
content: Run time interpreters (RTI) such as BASIC and Java give up speed and compactness in favor of convenience. Instead of edit, compile, link and execute, they offer the edit and execute paradigm which can greatly speed up development.Most RTIs utilize various strategies to overcome the loss of execution speed. These strategies include pre-compilation to byte codes and/or they will gather statistics during execution that can point out ‘hot spots’ in the code that can be compiled into machine code which is then cached for future use.Neither of these strategies comes for free. The pre-compilation into byte codes results in a start up delay and the JIT statistics is always sucking up machine cycles in addition to those used by the program itself. Both, however, can substantially speed up program execution, sometimes even approaching 50% to 60% of the speed of the statically compiled program.There exist a few cases where JIT can improve upon a statically compiled program such as when pattern matching and regular expressions are the goal of the program. In these cases, it is the nature of the input data itself that determines execution speed. Since the input data isn’t seen until runtime, the static compiler won’t take the data into account unless it also uses the output of a data profiler while compiling.Such techniques aren’t often used as with statically compiled programs the vast majority of software would suffer a loss in speed with little to no likelihood of improvement.An RTI could gain portability by generating a hardware independent byte code that could be distributed to computers with different CPUs. A local RTI could read those byte codes and translate them into machine language for the specific host computer.All in all, RTIs are doing very well if they can execute programs at half the speed of statically compiled programs.

author: Howardlong
author_rank: Super Contributor
timestamp: March 09, 2016, 08:16:29 pm
content: Quote from: MSO on March 09, 2016, 12:44:51 amIn certain very rare edge cases and contrived cases possibly, but I can't say I've ever seen any evidence of it in the real world. The slow start up though is an endemic problem. I've never really understood the point of recompiling new code each time you run a program if you're not doing run time profiling. It's not like the magic CPU changing fairies have been out in the middle of the night or they were doing run time profiling the last time the code was run. Certainly Microsoft introduced AOT (ahead of time) compilation very very early on in .NET's life when they found pretty much any non-trivial solution ran so slowly at startup.QuoteThis has been de rigeur on database engines for a couple of decades, using the data distribution as input to optimisers in near real time which frequently recompiles code in certain scenarios. This is a double edged sword. While it works a lot of the time it also introduces subtleties which makes those times it doesn't work even more difficult to fix and work around to optimise performance. Although very clever, it makes a lot of assumptions, and frequently bases its assumptions on pseudo-randomly selected but non-representative data samples which sometimes leads to bad compilation plans.Key though is the determinism, or the lack of it. Not only does this frustrate end users, one of the biggest problems in troubleshooting is creating reproducible scenarios. When the rug's being contually being pulled from under your feet when the compiler decides to take a different route depending on a butterfly flapping its wings in Peru, it just makes the task another order of magnitude harder. Sometimes it's a case of less is more.

author: Boomerang
author_rank: Regular Contributor
timestamp: March 10, 2016, 06:54:37 am
content: It could be very simple:1. You compile your source code to some P-code, byte code or whatevere the name is. This is done only once.2. When you install/deploy the program on specific machine - the byte code is converted to machine code. This is done also only once per machine.

author: ade
author_rank: Unknown
timestamp: March 14, 2016, 02:58:33 pm
content: C vs C++ is really about two programming styles: modular (C) vs. object-oriented (C++). They are very different paradigms.Choosing one style over the other has a fundamental impact on how you design, organize and implement your code, with pros and cons depending on the specific situation.Many C programmers cannot successfully make the transition to C++. They end up superficially using C++ constructs like classes, but essentially continue to program in modular style.On the flip side, as someone mentioned earlier, it's possible to apply object-oriented concepts in plain C, but that requires a lot of manual work. Many elements the Unix/Linux/BSD kernel are conceptually object-oriented.Use C when you think modular style is the best style for the problem at hand. Use C++ when you think object-oriented methods will benefit the design.For the younger amongst us, it is advisable to learn both programming styles properly, as well as other programming paradigms such as functional programming.

author: nctnico
author_rank: Super Contributor
timestamp: March 14, 2016, 03:08:07 pm
content: Quote from: ade on March 14, 2016, 02:58:33 pmI disagree. There are many things in C++ which are better than C. For example being able to pass a variable by reference, variable sizes arrays, a proper string type, the STL library, etc. Even if you program modular using the C++ features can help a lot to make a program more robust.As you wrote you can program modular and object oriented in both C and C++ so the choice between C or C++ isn't driven by the programming paradigm (modular or object based).

author: tggzzz
author_rank: Super Contributor
timestamp: March 14, 2016, 03:18:26 pm
content: Quote from: Boomerang on March 10, 2016, 06:54:37 amThat is no different to conventionalstaticcompilation and optimisation, based on what the compiler is allowed toguessabout the code sequences and data accesses. With some languages, C/C++ especially, the possibility of aliased references requires the compiler to makepessimalassumptions - ask anybody in the High Performance Computing community (and that is one reason why they prefer Fortran).The advantage ofdynamiccompilation techniques (e.g. HotSpot, Dynamo, database queries) is that the optimisations are based on what isactuallyhappening in your code and data. As with any optimisation technique, there are downsides - but is a significant number of cases the advantages outweigh the disadvantages.

author: tggzzz
author_rank: Super Contributor
timestamp: March 14, 2016, 03:22:05 pm
content: Quote from: Howardlong on March 09, 2016, 08:16:29 pmI presume you do turn off caches, because cache misses (either L1/2/3 or TLB) can cause your program to slow down by an order of magnitude. And that can happen becauseunrelatedprocesses "evict" your data or virtual addresses from the caches.

author: Howardlong
author_rank: Super Contributor
timestamp: March 14, 2016, 06:09:13 pm
content: Quote from: tggzzz on March 14, 2016, 03:22:05 pmAbsolutely. While you make an important point, that is on very much the micro-level when dealing with an enterprise level system and any cache level issues are way down in the noise and generally not easily configurable if at all at the application layer. These days pretty much everything's on VMs and SANs anyway, the chance of your average VM admin giving a crap about cache hits is very unlikely, but cache is a key reason why things often run slower on VMs to physical boxes. In the physical world, the CPU is usually only sporadically used to full capacity on (relatively) well defined processes, whereas in the VM world it's frequently a race to have the underlying CPUs used as much as possible, particularly in commodity cloud-based services.This has been one of my major concerns over the use of SANs and VMs in enterprise systems for the past fifteen or so years, that it's very difficult to provide _any_ form of reliable and guaranteed performance metrics as there are just too many unknowns. In general the SAN guys just want to give you JBOD solutions and simply aren't interested in spindle management. Luckily nowadays with tiered SANs the situation is alleviated.But at the low level, absolutely. I place pinch point code in zero wait state memory and manually tier memory when necessary. That is something a compiler generally knows little about. For less intensive stuff, that can sit in slower cached memory. In general, in an embedded real time situation, you have to be able to guarantee and profile resposnse time, but luckily usually these systems are simple enough that there are a very well defined set of process that run.Essentially, non-deterministic systems have kept the consultancy side of my business in work for a couple of decades and continue to do so. Most of my experience away from databases has been mostly with distributed systems using .NET rather than JEE in the enterprise, but I do have experience with both. Quite early on in .NET's lifecycle for example, Microsoft realised that slow start up was a major problem for anything non-trivial, and they released they needed the option of pre-compiling ahead of time. However, at the drop of a hat they will still recompile if the stars are not properly aligned. Unfortunately this also means that after security updates, it is not at all uncommon for all that code to recompile all over again, and this can take tens of minutes, churning your poor CPU cycles - cycles that would not be used if precompiled binaries had been distributed instead.As a real example of where adaptive compilation doesn't work well is when you have multiple end users (or processes) with differing requirements using the same code. In this instance, the way one user uses the code is different to another user, and in some situations this can lead to serialisation, as there is only one execution plan which is being repeatedly recompiled, and you end up with massive overhead as the same code is recompiled on each context switch/iteration/execution - think in terms of 1,000 slower. This became very apparent, for example, in SQL Server 2000, and remains a problem to this day unless you enforce a per-session execution plan, which is expensive in memory... and, coincidentally, cache of course! I don't know how a Java hot-spot compiler deals with this situation, but it is very real with adaptive run time optimisers. Indeed, I wrote a paper on it at the time. It is exactly this kind of unexpected and unintended performance behaviour which makes me wary, but equally it's given me the opportunity to earn a few quid diagnosing and fixing it when it goes wrong too.Anyway, these are just my experiences, and as I say I can hardly complain, these kinds of additional complexities and their unintended side effects are exactly what end up paying my bills after all!

author: ade
author_rank: Unknown
timestamp: March 14, 2016, 07:01:21 pm
content: Quote from: nctnico on March 14, 2016, 03:08:07 pmPass by reference is meaningless in modular C, because you don't have overloaded types (which imply objects). Otherwise it's only syntactic sugar.Modern C supports variable length arrays (since C99). It's neither good or bad. Peruse the Linux kernel and you'll see VLAs being used."Proper string type" and "STL" again are entirely meaningless outside object-oriented context. Type here imply object. You can't use your "proper string type" without instantiating string objects. You don't need generics when programming in modular style, as you don't organize by types.

author: tggzzz
author_rank: Super Contributor
timestamp: March 14, 2016, 09:13:54 pm
content: I think we ar emostly in violent agreement.Quote from: Howardlong on March 14, 2016, 06:09:13 pmWhile the points you make below are most assuredly important, the reason I chose the L1/L2/L3/TLB caches is that those are at more equivalent level to dynamic compilation. There is little that dynamic or static optimisation can do to affect SAN/network/VM level effects.QuoteIn my experience they don't even know that L1/L2/L3/TLB caches exist, let alone understanding their significance. Unfortunately most "enterprise level" programmes are little better.QuoteMy recent experience has been with telecom application servers, and there customers do measure latency (usually mean latency rather than 95th percentile latency, fortunately!).QuoteThat is, of course, when those bodies aren't peddling half-truths and even lies about performance, failure modes, and reliability.QuoteFor embedded systems that is, to some extent practical (I always liked the i960 in that respect), but I haven't seen a way to do it in application servers.QuoteI had presumed, without evidence or searching, that was the reason MS updates were so appallingly slow. Thanks for the solid experience.As for slow-startup but eventually better performance vs fast-startup but poorer performance, there's a good argument MS made the right choice for the .NET desktop. It is less clear for long-running application servers.QuoteI've always stayed away from databases, except to get rid of them as being unbeneficially heavyweight for specific telco applications.