Effective C: An Introduction to Professional C Programming

If you know C++, you know C (ignore dark corners and changes in later C standards). C++ is first and foremost a "better C" and only later everything else.

I can recommend the following for Embedded Programming;

* Michael Pont's Embedded C and Patterns for Time-Triggered Embedded Systems (PTTES). They are chock full of invaluable C code (for 8051); in particular, beg, borrow or steal PTTES (free pdf available). Also checkout his other books and his company SafeTTy Systems.

* Make: AVR programming by Elliot Williams teaches you to directly program the ATmega328P on a Arduino Uno.

* Introduction to Embedded Systems: Using Microcontrollers and the MSP430 by Jimenez, Palomera et al. is an excellent textbook explaining each hardware aspect of an embedded system and how to program them.

Note: All the above are for bare-metal embedded programming. For Embedded Linux on RPi, i suggest Exploring Raspberry Pi: Interfacing to the Real World with Embedded Linux by Derek Molloy.

Oh, a standards committee member! We have requests...

Now that C allows mixing variable declarations in with statements, it becomes annoying that variable declarations can not have labels. This hits particularly hard with the switch/case, but can also apply with ordinary named labels. The syntax to work around this defect is ugly.

The gcc extension for case ranges is really valuable.

Setting the sign bit via a cast should not cause undefined behavior. (for example, going from uint32_t to int32_t) It should just work in the obvious way. Avoiding the problem requires extremely strange code.

I'd like a way to prevent arrays from being replaced by pointers. Assignment could work. Sometimes I really want to pass an array to a function, and I don't mind if that means a megabyte is copied into the function args on the stack. Sometimes I really want to force the huge copy, and other times I'd rather have the compiler keep it in the caller's frame (but callee can mangle it unless it is const) and just pretend that the callee got more than a pointer. Array dimensions need to survive. The callee's prototype should be able to demand specific dimensions or receive them as variables, and the caller should be able to pass a portion of a larger array

The default function parameters of C++ would be useful. The UNIX API for open() would be best done this way, allowing a prototype without the need for stdarg. There doesn't seem to be any reason why default parameters would have to be at the end; a pair of adjacent commas in the middle is a fine way to indicate that the default is to be used for that missing parameter.

It's time to standardize bitfield layout so that bitfields can be used in portable code for purposes like assemblers and disassemblers. (in other words, not for purposes like access to MMIO registers) Microsoft and GNU compilers are already quite compatible on x86_64, so that would be the basis of standardization.

When a bitfield happens to have the size and alignment of a normal integer type, it should be possible to take the address. The resulting type would be a pointer to the integer type of lowest rank having the correct size.

Anonymous unions and structs would be valuable in all scopes, including at file level. This would allow careful data organization to save space, improve cache locality, prevent undesired cache line aliasing, or allow the intentional aliasing of types. Current technology typically involves abuse of the linker, which is well outside the C language.

Being able to do something like an #include, but with a blob of binary data, would be helpful for initializing big arrays. Current practice is to have build scripts convert binary files to C, to have the linker do it, and to rely on assemblers with the capability. None of that is nice to use.

So that we don't have to invoke m4 or do nasty things with recursive macros, the preprocessor could support loops.

There are a few gcc extensions that make macros far more reasonable, including statement expressions and typeof. Add those.

Would you be interested to launch translations of some of your books? I would love to make these technical books available in French and Esperanto.

I know the Rust book is already translated in some languages. I even started the Esperanto translation myself[1], but had other priorities in the mid time. Doing that in spare time doesn't help to accelerate the process, but I already achieved the translation of the Lua reference manual this way.

If you are interested, just send me an email through mathieu at culture-libre dot org, or reply to this message with some instruction on which canal you would prefer to use.

[1] https://github.com/psychoslave/Rust-libro [2] https://www.mediawiki.org/w/index.php?title=Extension:Scribu...

A good and motivational project imo can be to buy a simple sensor board for the Arduino, and write a driver yourself for it (even if drivers exist). Pick a simple sensor - some will require you to do all kinds of hoops and loops, but others are more like "startup, trigger sensor read, read out".

For this part, it's also fun to have a logic analyzer (starts at about 10 bucks) to see the change in code manifest on physical pins. It's also helpful to see that what you think you are doing, is actually happening. Eg, the SPI Chip select pin may be inverted (high when should be low and vice versa).

Then start off with a simple program that does init, and periodically read the sensor. Perhaps adding thresholds that trigger eg a LED. Then you can extend this to pipe over serial port to the rpi and push it to some server of your choice (eq mqtt), or display on a local webserver dashboard.

Go with sensors that are ordinary SPI or I2C, not some one-wire-protocol. Suggestions, BMP180 (temp, RHum), TSL2561 (light).

Have fun!

edit: if you are doing it on the Arduino, you can start off with the arduino spi/i2c libs, and later on if you wish, fire up the AVR datasheet (or whatever cpu is on your arduino) and implement i2c/spi yourself by changing registers etc on the cpu.