Embedded programming

I'm trying to learn C so that I can do some embedded programming on STM32 boards, simple things like building a game controller or something.

If I work my way through the K&R would that likely teach me enough to figure it out, or would I need more external knowledge?

Attached: 41gHB8KelXL._SX377_BO1,204,203,200_.jpg (379x499, 27K)

Other urls found in this thread:

amazon.com/Definitive-Guide-Cortex®-M3-Cortex®-M4-Processors/dp/0124080820
twitter.com/SFWRedditVideos

K&R is just a primer on the C language. There's no specifics in regards to embedded programming.

Get an Arduino starter kit or something.

>would I need more external knowledge?
yes

K&R is for people wanting to implement the C language (ie write a compiler), not for people who want to program in C.

K&R is only about C, embedded system is more than that (I/O, register, etc).

But learn K&R first, it's a very smoll book. After that grab one stm32 discovery board and start tinkering with it

wow you seem really stupid. have you even read it? it's literally just beginner exercises with strings and linked lists.

He probably got overtly excited there's a problem in the book for parsing a compound type declaration

there are few things missing in the book that you will need
>understanding volatile
>understanding linking
>how to actually structure larger projects
and several things related to stm32s
>knowing ARM Cortex-M architecture
>knowing CMSIS or HAL libraries
>knowing how to actually flash your device
>how to design your program in interrupt model, concurrency primitives available and good patterns
>knowing all sorts of hardware peripherals
>how to debug baremetal programs
you can also use some IDE (CubeIDE or Atollic come to mind) solving some stuff for you (such as flashing, interactive debugger session, generating project), this gives you quick start. there is some value learning about what the IDE does for you regarding building the project, generated files used, and how it actually loads stuff into the board - keep it for later curiosity.

not this guy, but for OP i can tell the most important thing about volatile is stuff accessed from interrupt vectors - if not marked volatile, compiler might optimize it away because there is no usual code path/access to it

>the most important thing about volatile is stuff accessed from interrupt vectors

Attached: readingapu.png (649x524, 394K)