[flagged]
Low-Level C Programming – CSE 325 Lecture Videos
11–20 of 27 posts
Re: Low-Level C Programming – CSE 325 Lecture Videos
#12Earlier 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?
Multiply by 10 million units and you now save $100,000 by using that chipset. In reality, as I understand it, the price difference is often at least $0.10 between the dirt cheap chip and the one with a nice developer experience.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#13Earlier 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?
I kinda love the not-C compiler used for the $.03 Padauk microcontrollers. It's fun, but then again I'm an EE at heart and don't need a lot of abstraction on top of the hardware.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#14Earlier quoted context omitted.
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…
> Char is short is long is a pointer.
I thought char was required by the C standard to be 8 bits. If everything is 24 bits, how do you cover 24 bit address space with 8 bit pointers?
Re: Low-Level C Programming – CSE 325 Lecture Videos
#15Earlier quoted context omitted.
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…
> Char is short is long is a pointer. I thought char was required by the C standard to be 8 bits. If everything is 24 bits, how do you cover 24 bit address space with 8 bit pointers?
> I thought char was required by the C standard to be 8 bits
It's not. (EDIT: it is required to be at least 8 bits though)
Re: Low-Level C Programming – CSE 325 Lecture Videos
#16a 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.
The real reason to use C over C++ is that when you can't use heap allocated memory, you can't use 90+% of C++. At that point, you've inflicted upon yourself all the C++ footguns and have thrown away any of the C++ useful bits.
Once that happens, you might as well just use C.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#17Earlier quoted context omitted.
> Char is short is long is a pointer. I thought char was required by the C standard to be 8 bits. If everything is 24 bits, how do you cover 24 bit address space with 8 bit pointers?
> I thought char was required by the C standard to be 8 bits It's not. (EDIT: it is required to be at least 8 bits though)
Welcome to C! The guns are free, but you can only point them at your foot.
The C standard specifies so much less than everyone thinks.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#18Earlier 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.
The real reason to use C over C++ is that when you can't use heap allocated memory, you can't use 90+% of C++. At that point, you've inflicted upon yourself all the C++ footguns and have thrown away any of the C++ useful bits. Once that happens, you might as well just use C.
I disagree with you here. Off the top of my head, these are the things I like about embedded C++ (and embedded Rust):
* RAII makes modern C++ a lot cleaner for things like holding locks, disabling interrupts, and other stuff that needs to be unwound at function exit, and doesn't need heap allocation. Until C gets 'defer', the cleanest alternative is gotos.
* Operator overloading is pretty nice for code where you have custom data types (like 2-element vectors), which can be very common with DSP systems.
* References give you a non-nullable pointer type.
* Template-based data structures are much nicer than the C alternative: macros.
* std::array is kind of nice, and doesn't have dynamic memory. Also, while std::string is pretty unsafe, std::string_view is very nice!
* For the few dynamic data structures you may want to use, you can write a quick allocator and hook that into every std data structure you want rather than writing your own data structures. The "null allocator" strategy is an option: just return the same pointer to one fixed chunk of memory, and fail if the data structure grows too big. You can also do the "init allocator" strategy: Only allow dynamic allocation during initialization.
Re: Low-Level C Programming – CSE 325 Lecture Videos
#19Earlier 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.
The real reason to use C over C++ is that when you can't use heap allocated memory, you can't use 90+% of C++. At that point, you've inflicted upon yourself all the C++ footguns and have thrown away any of the C++ useful bits. Once that happens, you might as well just use C.
You can’t use 90% of the STL, sure. But there’s nothing in C++ that requires heap allocation (maybe exceptions? But those are turned off in embedded code anyways)
Re: Low-Level C Programming – CSE 325 Lecture Videos
#20a 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.
C++ could be simplified by removing older features, and redundant features that are longer recommended.