Recommended books to learn about embedded?

[Winfried]

Hello,

I'm only getting started with microcontrollers.

Since they're so tiny and affordable, I'm especially interested in ESP-based controllers, while a lot of books deal with Arduino and RaspberryPi.

What books would you recommended to get started, preferably in high-level languages like Python or Lua, if available?

Thank you.

[cfbsoftware]

I know next to nothing about Python or ESP but can recommend Elektor magazine and its publications. You might find something here of interest to you:

https://www.elektor.com/espressif/books

[nctnico]

'Making embedded systems' by White is a nice start. It is C oriented but also goes deep into how the hardware and software interact. The latter is very important when writing software for a system with limited resources (compared to a PC).

[rstofer]

Why not start with the Arduino?  There are thousands of projects on the Internet and both a hardware description and code is provided.

You can eventually walk away from using the Arduino libraries and write your code for bare metal.  The ATmega328P isn't the most powerful chip around but it's an easy start.

Using the familiar Arduino infrastructure and similarly functioning libraries, the Teensy 4.1 is a VERY FAST CPU with a flattened learning curve if undertaken after working with the Arduino.

https://www.pjrc.com/store/teensy41.html

The Arduino isn't the be-all end-all of uCs but it's a great place to start.

Here's a starter kit that comes with everything you need to get going with the Arduino including the code to drive all the peripherals:

https://www.amazon.com/ELEGOO-Project-Tutorial-Controller-Projects/dp/B01D8KOZF4

It also includes an Arduino UNO clone so there's nothing else to buy.  There's a lot of education in that kit.

Amazon has many other kits along the same lines.  There is also a really good starter kit for the Raspberry Pi.

https://www.amazon.com/Freenove-Raspberry-Processing-Tutorials-Components/dp/B06W54L7B5

The compatible Raspberry Pi is extra.  The code files are an education in themselves.  Plus, you do all the development on the same uC as you are using to experiment.  In that regard, it is a lot more convenient than the Arduino starter kit which requires a PC for device programming.

[Simon]

Why not start with the Arduino?  There are thousands of projects on the Internet and both a hardware description and code is provided.

God NO! The arduino was intended for "makers" and "artists". It was not meant for serious work. Sadly the world missed the point and thought they had gotten their hands an a way to program a micro like a PC.

If you truly want to learn embedded then step away from the arduino. Sure it's an inviting prospect to be able to do stuff in minutes but as soon as you have a need for the real hardware you will find you need to learn to do it properly. I wrote one program in arduino, and then looked to convert it to bare metal.

If you can hack understanding the hardware then do, and code properly. My issue was learning to code and learning the chip all in one go. Once I had my first success just having to worry about how the code is written I was willing to play with the hardware.

Micro controllers are powerful in their own right. Their power comes from their peripherals, much of these are underused in the arduino because the peripherals are so different between chips that there is no way of writing standard libraries that will work on each chip using it to it's full whilst having common code and portability.

For example in the name of compatibility the ADC library will always give a 10 bit result even on chips with a 12 bit ADC, they have to go and do this in the background to make sure you get a consistent result. If you want the full 12 bit you have to add code to get back what was taken away.

Full use of interrups? forget it.

Arduino is so removed from the hardware that it sets you on a path to programming that is not reconcilable with how you would program in bare metal or via other less ruinous abstraction systems.

[MarkF]

I agree with Simon.
If you want to learn microcontrollers and how the software interacts with hardware, stay away from all things Arduino.  Or using any libraries you might find.  They will only remove you from understanding how the microcontroller works.

 
More and more, I'm seeing people begging for a library to perform some function.  Then, they are begging for someone to explain how is works.  And after that, they are begging for someone to debug the library for them.  Sometimes, you just don't have a choice.  You can spend all your time searching for a library and learn nothing or write your own library and gain some insight.  To this day, I avoid libraries at all costs.

Also, you language of choice will be 'C'.  Unless, you want to delve into assembly language.  Which I strongly discourage.  Todays microcontrollers are fast enough that it is rare you would need to go to such lengths.  Coming from someone who started programming by toggling machine code into the front panel of a PDP-11/55 and watching lights blink.

My first introduction to microcontrollers was a module from DLP Designs that contained a PIC16F877A.  I would suggest starting with one of the 8-bit PIC16's and learning how to use the peripherals.  One of the newer ones with a builtin oscillator.  The PIC16's are simple enough that the learning curve is not too steep.  Also, the initial cost is low:  just the MCU in a DIP package and the programmer.

Take a look at a recent thread starting with my comments and working back:
   https://www.eevblog.com/forum/beginners/looking-for-practice-building-circuits-that-use-microcontrollers/msg3931733/#msg3931733

[Simon]

My experience has been AVR and now ARM. I don't see a huge amount of complexity in the ARM chips compared to the AVR when it comes to the peripherals themselves. Just ignore all the fancy stuff and treat it like an AVR on steroids. The only complication is the clock system that is complex or rather, poorly explained and you need to know that you need to introduce wait states in the non volatile memory controller when you speed up the CPU as the flash memory can only go so fast.

Interrupts are a little more complex as the interrupt controller is part of the ARM CPU and requires some delving into ARM documentation but again once you head is around it you are done.

[Simon]

is C++ really worthwhile on an MCU? I have set myself the goal to learn it but really that is just so that I can keep up with other peoples code if I do use external code.

Using third party code is valid particularly where you want to something standard and it's not worth buggering about but like converting a number to ascii but even then I ended up writing my own and it was faster than the standard library on AVR.

[MarkF]

My experience has been AVR and now ARM. I don't see a huge amount of complexity in the ARM chips compared to the AVR when it comes to the peripherals themselves. Just ignore all the fancy stuff and treat it like an AVR on steroids. The only complication is the clock system that is complex or rather, poorly explained and you need to know that you need to introduce wait states in the non volatile memory controller when you speed up the CPU as the flash memory can only go so fast.

That has been my experience with the PIC18 and PIC32 series microcontrollers I've used.  The internal oscillator configuration is a nightmare.

[Simon]

It's made worse in the case of say the SAMC (and I assume the similar SAMD) by the fact that they explain it poorly in datasheets. There really is a market out there for people to write books on these chips that actually explain how to use them rather than just list features and functionality in a way that is little more informative than some sort of computer self generated text.

For example synchronized registers are not well explained and I do not know if they were the cause of the trouble I had setting up a counter with a pre-scaler. enable, pre-scaler and mode are all in CTRLA, if you don't set the mode first if you want to be in the non default mode then you can't write to registers only available in that mode. But equally if you write to the pre-scaler before enabling the counter the pre-scaler has no effect so I found myself writing to the mode bit, then writing in one go the mode again, the pre-scaler and the enable. No clue whatsoever in the datasheet and all down to trial and error. At one point it looked like I had it working and the chip was just running at 49.5MHz instead of 48MHz but I persevered in experimenting and realized that it was merely coincidence and that the prescaler was having no effect.

That is the downside of ARM based stuff, while the peripheral functionality may not be any more complicated it's just harder work getting some things to work.

[nctnico]

Why not start with the Arduino?  There are thousands of projects on the Internet and both a hardware description and code is provided.

You can eventually walk away from using the Arduino libraries and write your code for bare metal.  The ATmega328P isn't the most powerful chip around but it's an easy start.

Using the familiar Arduino infrastructure and similarly functioning libraries, the Teensy 4.1 is a VERY FAST CPU with a flattened learning curve if undertaken after working with the Arduino.

https://www.pjrc.com/store/teensy41.html

I'd start with something like the Teensy right away. Using a slow and limited processor gets in the way quickly. IMHO the Arduino is severely outdated right from the start. Starting off with a more capable microcontrollers allows to use Micropython and go from there. Micropython already supports the Teensy 3.1; support for version 4.1 is likely to follow (some people have already created ports for the processor used on the Teensy 4.1)

[Simon]

Arduino does include ARM based devices. But as I said above it's just throwing more features away because the mega328 does not have them as well. I think the language is irrelevant, it's about understanding the environment you are programming on of direct hardware access and manipulation rather than just writing high level code as you would on a larger standardized platform that has an OS.

I draw the line between things that would have some sort of OS and things that don't. If there is no OS then don't go looking for anything that tries to give you anything like that sort of standard functionality because it will be at the expense of the power of the chip and still you will not have portability.

I do rather wonder when I see terminology such as "driver" applied to code from manufacturers.

[Jeroen3]

Lol, arduino is not evil.
When dealing with the ESP controller you actually need something like it, otherwise you're going nowhere.

What books would you recommended to get started, preferably in high-level languages like Python or Lua, if available?

I would not focus on the combination of those. But as separete topics. Find a book about microcontrollers processors, find a book about python.
Like The Definitive Guide to ARM  Cortex -M3 and Cortex -M4 Processors.
I don't know of any python books, but it has reasonable documentation.
Though C and C++ are the most commonly used, so you may need some knowledge about that first.

One key thing to remember is that is doesn't matter where you program, learning to program can be with any language. The concepts remain mostly the same.
The ESP32 contains many domains... C++, gnu toolchains, python, wifi, bluetooth, web standards, operating systems. Probably more.
It's a very complicated product, but it's made very accessible (hence it's popularity) because you can use it with the Arduino libraries!

The concept of the wireless microcontroller wasn't new, but it never really took off in the tinker markets due to the remaining complexity of utilizing them.

[alexanderbrevig]

Data sheets, YouTube, blogs, forums and stack overflow is all you need. I have not found any good books,
 In truth I gave up on the prospect some years ago, tht any such book exists unless part- and tool-chain  specific.

Good luck!

C++ is definitely worth it. Forth and Rust are fun too
I'll choose another part of their tool chain does not support C++, unless a client pays me my C surcharge of course 

PS: I don't like Arduino because of personal experiences and affiliations, but I am here because of Arduino. My first project was to reimplement an Arduino project, with a custom PCB and only port manipulation. I learned a lot those weeks! It's been many years since i touched Arduino now though. (Disclaimer: I am part of the Wiring team, and have done consulting for Arduino)

[rstofer]

The thing about the Arduino kit isn't the Arduino, it's the external devices and how to interface them.  How many times do we see threads complaining that the user can't get I2C working or generally misunderstands SPI?  Just having a working knowledge of these external protocols and the gadgets that hang off of them is quite useful before getting buried in bare metal.

It's a matter of the learning curve.  Starting bare metal with the Teensy 4.1 is going to be problematic.  Getting the first project running is going to be exponentially more difficult than the same project on an Arduino.

Once the external devices are understood, porting that understanding to a Teensy is pretty easy.

OP, you didn't state where you are with 'electronics' learning.  Are you learning electronics in concert with embedded systems?  If so, I would double down on my recommendation of the Arduino kit.  Even if you only use it for a month to learn the basics, it's an easier start than the Teensy.  BTW, I go back to the beginning with Teensy boards and I like the 4.1 a lot.

If you decide to walk away from Arduino, consider the Raspberry Pi kit.  Among other things to learn (if you don't already know them) is how to build projects in C on Linux.  You will pick up some decent skills with Linux just getting the provided projects to run.  And, yes, I prefer C for everything related to uCs.  There is some merit to Python because it is the most used language (or so the users say) and it has applications well beyond mere uCs.  You wouldn't waste your time if you were to learn Python as well as C.  Note that the Starter Kit includes code for C and Python (as well as Scratch and Java).  Try them all!  Learn as much coding as you can!

Starting from nowhere, I think it's best to keep it simple and with as much handholding as possible.  There's plenty of time later to get fancy.

[Simon]

Lol, arduino is not evil.
When dealing with the ESP controller you actually need something like it, otherwise you're going nowhere.

If they are coming up with a new ecosystem for industrial applications sure. The problem for them is that they have run out of steam. Anyone can make a clone board and now that they have given their shoddy software away for free for so long people expect it to stay that way. If they have a proper commercial proposition for industrial controls then that is not the same as Arduino. I would not trust the current Arduino ecosystem anywhere near my stuff. Jeez, I had to fudge my code so that 80/100 = 1 stopped happening! keep that shite out of my sight thanks. The only code I want to debug is my own.

[alexanderbrevig]

I know it's off topic but Simon. You must have had a particularly bad experience with Arduino. It's just C++ though, so no way 80/100 == 1     Given the sheer amount of people successfully using it, it can't be that bad... Maybe give it another go some weekend? Teach it to a kid in the family perhaps?

[SiliconWizard]

It is bad, but not THAT bad indeed.

[rstofer]

I draw the line between things that would have some sort of OS and things that don't. If there is no OS then don't go looking for anything that tries to give you anything like that sort of standard functionality because it will be at the expense of the power of the chip and still you will not have portability.

I do rather wonder when I see terminology such as "driver" applied to code from manufacturers.

How does FreeRTOS fit into your definition?  Is it an OS?  Arguably, yes but it is clearly targeting embedded systems.

As to ARM, I started with the LPC2106 and graduated to the LPC2148.  These are well documented chips by NXP but quite old at this point.  I finally got to the mbed LPC1768 and used their online toolchain to build what looks to the CPU as a 100 step per inch plotter but accumulates steps and sends command strings to a LaserJet over TCP/IP.  Given the mbed network library, this is almost trivial..  Big queue on input, some crunching (accumulating steps), big queue on output and a bit of network code (state machine).  I really like this chip/board.  mbed.org is owned by ARM.

I would look for mbed compatible ARM boards given the opportunity.  The libraries are worth the effort.  The project and the libraries can be downloaded to a local machine if desired.

https://os.mbed.com/
https://os.mbed.com/platforms/
https://os.mbed.com/platforms/mbed-LPC1768/

FWIW, the LPC1768 User Manual is only 840 pages and there will be a test later..  That's actually brief in comparison to later chips.
Of course, the Datasheet is another 93 pages...

[Simon]

I know it's off topic but Simon. You must have had a particularly bad experience with Arduino. It's just C++ though, so no way 80/100 == 1     Given the sheer amount of people successfully using it, it can't be that bad... Maybe give it another go some weekend? Teach it to a kid in the family perhaps?

It was a kid that had me using it. The work experience student did a project on it and suddenly the machine he did it for was going for a demo with the customer so I had to write a load of code from scratch in a hurry in Arduino to replicate what he was trying to do. in the course of doing it I found that yes a lot of his code would not work but also hit the same problems he had due to it being the arduino. I had an topic thread on why can't I call millis or micros (can't remember which was the main problem) and it turns out that because of cross compatibility even a 32 bit ARM sporting 16kB of RAM is not allowed to do what an 8bit AVR sporting 2kB of RAM can't because we tried to make a one size fits all and if we just taught people to program embedded rather than a PC the universe would break.

[Simon]

How does FreeRTOS fit into your definition?  Is it an OS?  Arguably, yes but it is clearly targeting embedded systems.

My programming experience is limited and while I have heard of it I don't know how much it does. Does it take care of your peripheral setup and work across different devices? no I don't think so. I would not call it an OS, it's a task scheduler, it just makes coding easier when you need to manage lots of tasks to the point you need a scheduler like an OS does but I think that is as far as it goes? Basically Arduino should be scrapped for proper bare metal learning, if you want anything like it promises you go the next level up I believe to something like a raspberry pi ? Where you don't do embedded you code in a Linux OS.

As to ARM, I started with the LPC2106 and graduated to the LPC2148.  These are well documented chips by NXP but quite old at this point.  I finally got to the mbed LPC1768 and used their online toolchain to build what looks to the CPU as a 100 step per inch plotter but accumulates steps and sends command strings to a LaserJet over TCP/IP.  Given the mbed network library, this is almost trivial..  Big queue on input, some crunching (accumulating steps), big queue on output and a bit of network code (state machine).  I really like this chip/board.  mbed.org is owned by ARM.

I would look for mbed compatible ARM boards given the opportunity.  The libraries are worth the effort.  The project and the libraries can be downloaded to a local machine if desired.

https://os.mbed.com/
https://os.mbed.com/platforms/
https://os.mbed.com/platforms/mbed-LPC1768/

Yes I had a little look. Saw lots that seems to be in C++ so I have left it alone for now as I need to learn C++ first.

[Simon]

But again with ARM we are talking a vast ecosystem from chips that run at 48MHz and are resource limited but cheap to chips that are just CPU's using external memory. Lets not forget that ARM was meant to be a PC processor originally. It was only the quest for cost saving and meticolous design that produced such a low power processor that suddenly while failing to get used in it's intended application it found its way into the embedded world only to be re-extracted later as a stand alone processor.

[Simon]

It is bad, but not THAT bad indeed.

i know, but after all the other contortions I had to go through to get the damn thing to work, I just gave up. Christ you can't even officially split programs into multiple files unless you call them a library which is not technically a library just source code.

[netmonk]

I would not advice Arduino or against it.
I'm still a beginner myself and far from all the experimented and professionals around.

But what i can state is that there are some bias in the thread.

Learning is mostly motivated with rewards. Experimented peoples have already learnt and their pleasure source is somewhere else most of the time.

When you are learning new skill, it's more efficient to start small with high rewards so that the will to continue and go more difficult is keept.

Of course the way to start small is not the most efficient way to achieve mastering from the master's POV, but going straight bare metal on a mcu should not be the starting point but the target.

So this beeing said, what is better from a starter point of view
- playing with arduino on esp 32, succeeding measuring room temperature and sending data over the internet over  sunday afternoon of dirty coding
- trying to spend the next 6 months understanding interruptions/timer/ low level i2c-spi communication and getting too early frustrated leading to total loss of interest

And if you ever find a good book, then tell me. Already asked two years ago here and still no answer.

[Simon]

The question is that the OP wants to understand embedded. What do we mean by embedded? Now if you are a novice in both programming and embedded environments sure the Arduino will step you into it more gently, you "just" need to follow the instructions and start to understand how to program and not worry too much about the hardware. Oh but this is supposed to be embedded, embedded means at least to me that you are working close to the hardware. These are not so powerful chips. You have chosen them specifically because of what they can do.

I need to do CAN bus at some point. The best MCU that I can see is the SAMC, it has 2 CAN bus controllers built in, yet costs the same as just two CAN bus controllers, so you get the MCU for free. It will work at up to 5V which is still where a lot of automotive sits, oh. Arduino does not have a board that is based on it. They have the SAMD only.

Embedded means to me using things like interrupts to make the most of your hardware. These are unsupported in Arduino with the exception of pin interrupts. Sure you can go around writing your own code to access them but then excuse me? what were you using the arduino for?

Sure start with an arduino, I did, but do not expect to do anything too clever with it if you want to work in a production environment. Oh and by the way, have you noticed the chip shortage? Because I am not an arrogant berk I was happy to use a chip I had not used before, the SAMD because we already had a prototype done by the local school using the arduino. Custom hardware design based on an arduino board. But the SAMD chips are all sold, I can't possibly imagine why. So I have had to pick something else and go cold turkey because from having something I could fall back on having got the damn thing to work, I now cannot as I am forced to use another chip.

If your skillset involves being put out of work the day you cannot buy a chip that the arduino runs on then uh, good luck.