Low-Level C Programming – CSE 325 Lecture Videos
1–10 of 27 posts
Re: Low-Level C Programming – CSE 325 Lecture Videos
#2Wow. Saving this playlist to share with coworkers!
Re: Low-Level C Programming – CSE 325 Lecture Videos
#3This is really great!! My C for Engineering professor was abysmal and I never felt like I got a quality education in it. This is something I've been really wanting to circle back to.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#4a better take on c vs c++ would be that c++ compilers are much more complex than c compilers, and might not be available on a given small platform. what he says about memory allocation is simply wrong.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#5a better take on c vs c++ would be that c++ compilers are much more complex than c compilers, and might not be available on a given small platform. what he says about memory allocation is simply wrong.
A lot of electrical engineers don't know much about how C++ (and C for that matter) actually works.
The real reason to use C in embedded programming is that "vendor_forked_gcc_from_10_years_ago" is your only compiler on most platforms, and almost certainly does not support C++ or has some bugs in its C++ compiler implementation.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#6a better take on c vs c++ would be that c++ compilers are much more complex than c compilers, and might not be available on a given small platform. what he says about memory allocation is simply wrong.
A lot of electrical engineers don't know much about how C++ (and C for that matter) actually works. The real reason to use C in embedded programming is that "vendor_forked_gcc_from_10_years_ago" is your only compiler on most platforms, and almost certainly does not support C++ or has some bugs in its C++ compiler implementation.
There are a couple exceptions here, like Infineon/Cypress’s PSoC chips, but it sort of seems like 99% of vendors have moved to Eclipse based IDEs with full support for whatever compilers work in that ecosystem.
There’s only a handful of things that matter when it comes to generating embedded code for a specific microcontroller and most of it comes down to the format required for the final linked executable, which usually boils down to an ld script.
In general any kind of ARM chip is going to work perfectly fine with the latest C++.
Or to rephrase your comment, the real reason to use C is because all the support tooling, header files, peripheral drivers, RTOS, etc. are written in C, and there’s not a huge benefit to moving user code to C++.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#7Earlier quoted context omitted.
A lot of electrical engineers don't know much about how C++ (and C for that matter) actually works. The real reason to use C in embedded programming is that "vendor_forked_gcc_from_10_years_ago" is your only compiler on most platforms, and almost certainly does not support C++ or has some bugs in its C++ compiler implementation.
There are a couple exceptions here, like Infineon/Cypress’s PSoC chips, but it sort of seems like 99% of vendors have moved to Eclipse based IDEs with full support for whatever compilers work in that ecosystem. There’s only a handful of things that matter when it comes to generating embedded code for a specific microcontroller and most of it comes down to the format required for the final linked executable, which usu…
That is really important to note: the spread of the Cortex-M0 has been amazing for embedded software. Before, compilers were vendor-managed for their proprietary core, and now they are basically mainline GCC because of the uniform use of the ARM instruction set.
I remember using a vendor fork of GCC 2 (released in 1999) to compile for a specific microcontroller in 2015, but since that vendor now releases Cortex-M0's, the vendor-blessed compiler uses a near-mainline GCC.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#8a better take on c vs c++ would be that c++ compilers are much more complex than c compilers, and might not be available on a given small platform. what he says about memory allocation is simply wrong.
A lot of electrical engineers don't know much about how C++ (and C for that matter) actually works. The real reason to use C in embedded programming is that "vendor_forked_gcc_from_10_years_ago" is your only compiler on most platforms, and almost certainly does not support C++ or has some bugs in its C++ compiler implementation.
I'm amazed that such vendors stay in business. Are embedded developers forced to put up with crappy outdated SDKs, because some legacy chipset is $0.01 cheaper per unit?
Re: Low-Level C Programming – CSE 325 Lecture Videos
#9Earlier quoted context omitted.
A lot of electrical engineers don't know much about how C++ (and C for that matter) actually works. The real reason to use C in embedded programming is that "vendor_forked_gcc_from_10_years_ago" is your only compiler on most platforms, and almost certainly does not support C++ or has some bugs in its C++ compiler implementation.
I'm amazed that such vendors stay in business. Are embedded developers forced to put up with crappy outdated SDKs, because some legacy chipset is $0.01 cheaper per unit?
Yes. Money is king, especially for high volume production. I found in my time at an embedded computer manufacturer that software, especially in house stuff, takes a back seat to everything else.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#10Earlier quoted context omitted.
A lot of electrical engineers don't know much about how C++ (and C for that matter) actually works. The real reason to use C in embedded programming is that "vendor_forked_gcc_from_10_years_ago" is your only compiler on most platforms, and almost certainly does not support C++ or has some bugs in its C++ compiler implementation.
There are a couple exceptions here, like Infineon/Cypress’s PSoC chips, but it sort of seems like 99% of vendors have moved to Eclipse based IDEs with full support for whatever compilers work in that ecosystem. There’s only a handful of things that matter when it comes to generating embedded code for a specific microcontroller and most of it comes down to the format required for the final linked executable, which usu…
Automotive embedded C developer here. Most of the code in this industry is implemented in a subset of ANSI C90. The reason is not header files, libraries or linker scripts. The reason is as the grandparent post points out: compiler availability.
For rare targets, there's just no money in making a compiler work for more than this small subset of C. My favorite example is the compiler for a really strange architecture where everything is 24 bits. Char is short is long is a pointer.
Bigger controllers tend to be ARM-based, so it's getting better.
Also Tricore has a big share, but their compiler support is getting better. There was even a rust compiler being announced recently, though I doubt it's using LLVM backend, so it's likely to be behind in terms of features.