Recommended books to learn about embedded?

[Jester]

I think you will get up to speed more quickly by putting something together, even if it starts with a blinky light. The easiest way to do that is with an Arduino just to get started. After you write a few Arduino programs  that do what you want them to do, you can move on to an actual bare metal type project, and make a blinky light from scratch. Start simple even a 8 pin PIC on a breadboard. My first embedded project was with a 6800 around 1980ish in assembler, about 10x perhaps 100x the effort and time compared to Arduino. IMO C  is a great language and worth learning. Start small and build from there.

[commie]

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

Heck, may I introduce you to paper tape and maybe once you have a grasp of that we can move onto cassette tape for input or a RS232 terminal. Di-spite what everyone is telling you, there are alternative programming languages  like Bascom AVR which are encredibly easy to use (compared to 'c') and just as powerful.   

[MarkF]

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

Heck, may I introduce you to paper tape and maybe once you have a grasp of that we can move onto cassette tape for input or a RS232 terminal. Di-spite what everyone is telling you, there are alternative programming languages  like Bascom AVR which are encredibly easy to use (compared to 'c') and just as powerful.

Get real.  The last time I wrote a Basic program was in the 80s along with my punch cards and teletype terminal.
Let's throw in a little Fortran and Pascal while we're at it.  Oh, don't forget good old Ada.
If you want to play around in your basement, write your little Basic programs till your hearts content.
But, you will be hard pressed to find Basic being used in industry now days.

Besides, C isn't any harder to program in than Basic is.  If you stay away from the fancy C++ stuff, it's just minor syntax and name differences.

It's all in what your goal is.

• If you want to quickly throw together a program to see some lights blink, get an Arduino.  Then try to write 8-bit parallel data to one of those cheap LCD displays (without a shift register).  Depending on which Arduino you have, you will quickly realize you have a mess and need to start packing bits because the MCU doesn't have an 8-bit port.  Then when you want to start doing some real complex stuff, you will need to start over with all new hardware and setup another software development environment with new software tools to learn.
• On the other hand...  If you want to understand how the MCU works, you won't get there by placing layer upon layer of libraries between your code and the MCU hardware.  It's just NOT that hard to learn how write a blinky program on a low end microcontroller.  I would even venture to say it's easier.  For example, a PIC blinky program in no more that 5 or 6 lines of C code.

THE CHOICE IS YOURS.  Neither one is bad.

[nctnico]

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

Heck, may I introduce you to paper tape and maybe once you have a grasp of that we can move onto cassette tape for input or a RS232 terminal. Di-spite what everyone is telling you, there are alternative programming languages  like Bascom AVR which are encredibly easy to use (compared to 'c') and just as powerful.

Get real.  The last time I wrote a Basic program was in the 80s along with my punch cards and teletype terminal.
Let's throw in a little Fortran and Pascal while we're at it.  Oh, don't forget good old Ada.
If you want to play around in your basement, write your little Basic programs till your hearts content.
But, you will be hard pressed to find Basic being used in industry now days.

Besides, C isn't any harder to program in than Basic is.  If you stay away from the fancy C++ stuff, it's just minor syntax and name differences.

Famous last words... you couldn't be further from the truth. Where people go wrong with C is usually pointers and index/buffer overflows. In fact, C is much harder to program in than Basic if you want a piece of software that is rock solid. Especially where it comes to dealing with types and memory. At least C++ allows to pass variable by reference and therefore offers a way to avoid the use of pointers.

And maybe Basic is no longer used today but it is replaced by other scripting languages like Lua and Python. Those languages provide some protection against common problems like buffer overflows and so on. Or at least provide ways to detect and recover gracefully instead of continuing with invalid data.

[Cerebus]

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.

Fundamentally and completely wrong.



Done using only controls presented in the IDE user interface, specifically that little triangle on the right and the "New Tab" item it leads to, which then asks you for a filename for the new file. Note that the whole thing has built successfully.

If you're going to condemn a whole platform condemn it it for things that are actually wrong with it, not for things you you couldn't figure out how to do even when they were right in front of you.

[uer166]

Here's something few people would suggest, but I find it helped me understand things with a bit of a different mindset, and allowed me to greatly improve the reliability of my systems. It's a free PDF: https://www.safetty.net/publications/pttes.

It explores ways to make time triggered systems in a down-to-earth tone even beginners can understand.

[commie]

Get real.  The last time I wrote a Basic program was in the 80s along with my punch cards and teletype terminal.

Bascom AVR is not a interpreter, it is a full compiler supporting  upto 5 dimensional arrays and 64bit double floats.

[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.

Fundamentally and completely wrong.



Done using only controls presented in the IDE user interface, specifically that little triangle on the right and the "New Tab" item it leads to, which then asks you for a filename for the new file. Note that the whole thing has built successfully.

If you're going to condemn a whole platform condemn it it for things that are actually wrong with it, not for things you you couldn't figure out how to do even when they were right in front of you.

find me the official instructions, there are non. I got into suc a mess because it does not work like it does in C. Its just a painful mess.

[nctnico]

Painfull mess is a strong term. IMHO it didn't work as you expected and it was easier for you to go bare metal. That is fine. OTOH Arduino works for a lot of people and that is also fine.

I would qualify Altium as a painfull mess but nevertheless it works for a whole lot of people. 

[Simon]

You miss the point, there is no official support for multiple files. Have a google. You will quickly find threads on forums that never come up with an actual solution other than: "I don't recommend this but this is what I do"

I ended up using the same method as our work experience student, just use header files and include them.

[Cerebus]

You miss the point, there is no official support for multiple files. Have a google. You will quickly find threads on forums that never come up with an actual solution other than: "I don't recommend this but this is what I do"

I ended up using the same method as our work experience student, just use header files and include them.

If there is no "official support" for multiple files, why does it compile and build from them fine? Pure accident? Why does it have a multi-tab interface for having lots of program documents open at once if it's unsupported? Somebody just thought it looked bare without tabs and they just happened to allow building projects with multiple files after they'd added tabs just for the appearance of it? Pull the other one...

[eugene]

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.

What is your background? How much experience do you have with electronics and programming?

Is there a reason you want to look past Raspberry Pi and Arduino? Have you already traveled that road are looking for something new?

Do you already have a ESP32 development board? Most people are attracted to the ESP32 because of all the peripherals, but the complexity makes it harder to learn. (It also seems poorly documented, but that might be just my opinion.) I recently completed a project with an ATTINY after working with sophisticated MCU's on a whole range of platforms. Working with the simple 8 bit architecture was like an ice-cold beverage on a hot summer day.

[eugene]

You miss the point, there is no official support for multiple files. Have a google. You will quickly find threads on forums that never come up with an actual solution other than: "I don't recommend this but this is what I do"

I ended up using the same method as our work experience student, just use header files and include them.

For the record, you can add as many *.c, *.cpp, and *.h files to the project as you want. Just put them all in the same folder as your main *.ino file. As always, *.h files need to be #included explicitly, but any cpp file will be compiled and linked with the main sketch. This means you should not have extraneous files in the folder, but that's just the way the toolchain works. Like any tool, if you can't figure out how to use it, then it will likely frustrate you. OTOH, learn how and you can exploit all the hardware of any Arduino compatible board completely within the Arduino environment. I've accomplished incredible feats with Teansies and just couple hours of coding.

[alexanderbrevig]

Sorry Winfried. We are derailing.
I want to back Simon up on somethng actually. For the longest time (and maybe still?) enums and typedefs (and #defines got moved too I think) did not propagate correctly. So if you used either of those, the solution was/is to either move the files into a library folder (where the preprocessor won't do anything) or do everything with those types in the main tab. Finally, you could hack the base main.cpp to include (forward) declarations there.

This all stems from the fact Arduino is C++, but spares the user from having to do function declarations they way they should be done. So, the preprocessor creates those for you, and in that process it will mess up and f.ex move the declaration above where you define a parameter type.

I would and still have recommend newbies to at least have a try with Arduino. Have a try with a raspberry pi. Have a try with a PIC, and play around with some ARM chip (not using Arduino). If a beginner can get through all that, she may stay for the adventure and fun to come.

[rstofer]

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.

Were you printing?  80. / 100. is 1 if the format specifier doesn't allow decimal places

#include <stdio.h>

void main(void)
{
  printf("%2.0f\n", 80.0  / 100.0);
}

[/font]

The output is 1 with no decimal point and no decimal digits.  There are probably other situations where rounding occurs automagically.  Underlying the Arduino IDE/toolchain is  avr-binutils, avr-gcc, and avr-lib.  They are not specific to Arduino.  I imagine it gets the right answer.  I guess we would have to see the surrounding context to figure why you got a rounded answer.

All bets are off if you have a problem with Arduino libraries but getting math wrong should be obvious to a lot of users.

https://forum.arduino.cc/t/arduino-language-vs-c-c/65526/2
https://www.nongnu.org/avr-libc/

[Simon]

I've never read anything about rounding, new one on me. Integer math is integer math, it does the division, no decimal place, you only get the remainder if you ask for it.

[Simon]

Sorry Winfried. We are derailing.
I want to back Simon up on somethng actually. For the longest time (and maybe still?) enums and typedefs (and #defines got moved too I think) did not propagate correctly. So if you used either of those, the solution was/is to either move the files into a library folder (where the preprocessor won't do anything) or do everything with those types in the main tab. Finally, you could hack the base main.cpp to include (forward) declarations there.

This all stems from the fact Arduino is C++, but spares the user from having to do function declarations they way they should be done. So, the preprocessor creates those for you, and in that process it will mess up and f.ex move the declaration above where you define a parameter type.

I would and still have recommend newbies to at least have a try with Arduino. Have a try with a raspberry pi. Have a try with a PIC, and play around with some ARM chip (not using Arduino). If a beginner can get through all that, she may stay for the adventure and fun to come.

Yea, so you have to "randomly" declare some stuff yourself. Because it's an attempt at simplifying something, trying to do it the way that something normally works anyway actually causes problems I found.

I have no problems with multiple files in a proper IDE, as soon as I try to use the arduino like a proper IDE things fall over. I look for the official method and all I find is people saying that "this is what I do". Nowhere is there official ways of doing it. Computers are methodical. They will do exactly as told, so just tell us what you told the damn computer to do!

For a large program, by the time you have made it work in arduino it looks nothing like a properly set out program in a proper IDE.

[Simon]

Using the Arduino does not get you things like this: https://www.eevblog.com/forum/microcontrollers/hd44780u-and-derivatives-bus-timings/msg3965054/#msg3965054

That display is updating on an interrupt. The Arduino based prototype takes 25ms to update and that means other stuff cannot happen unless it is on an interrupt which gets messy. This takes one half step in sending data every 100µs leaving thousands of cycles in between to do the rest of the program. Can't do that with arduino. Not because the arduino is too crap to do that but because being a system with "libraries" written to cater for any chip used you cannot leverage on the hardware. The Arduino is mostly CPU and a lot of the hardware is underused whilst the rest is badly used because they have no choice on a system that is common to an ATmega328 and a SAMD21. That is not embedded programming.

If you want to work on a higher level system that does not involve bare metal then sure, that is valid too. But then pick your system and find a book on that. It does not help these days that every term is misused and abused to sound cool and it's really difficult to have a conversation with someone and be sure we are talking about the same thing.

[Jester]

 ]

#include <stdio.h>

void main(void)
{
  printf("%2.0f\n", 80.0  / 100.0);
}

Arduino is a double edged sword. Super easy to get started with little knowledge, however because so much is hidden in a wrapper if you do have some C experience and expect normal C behaviour you don’t always get what you expect and further you don’t know when Arduino will be Arduino and when Arduino will act like actual C. I seem to recall that %f is not supported in Arduino, I tried using it in sprintf() and it did not work. Not to mention the /100 reduction in speed on I/O unless you work around the normal Arduino I/O.

That being said if your just starting out it’s a great way to get “started”

[rstofer]

Arduino is a double edged sword. Super easy to get started with little knowledge, however because so much is hidden in a wrapper if you do have some C experience and expect normal C behaviour you don’t always get what you expect and further you don’t know when Arduino will be Arduino and when Arduino will act like actual C. I seem to recall that %f is not supported in Arduino, I tried using it in sprintf() and it did not work. Not to mention the /100 reduction in speed on I/O unless you work around the normal Arduino I/O.

That being said if your just starting out it’s a great way to get “started”

That's been my point all along.  Everybody needs to start somewhere and embedded, by definition, deals with external gadgets and the Arduino Starter Kit has a lot of gadgets.  More important, it includes working code in 4 languages and full explanations.  No, an Arduino won't likely be a solution to a commercial project but it is a great place to start.

Starting with ARM from bare metal just seems like a very steep learning curve with little chance of success.  Nevertheless, Google comes up with a lot of books for starting with STM32 - search string: 'stm32 book' (no quotes).

[Simon]

Question is how much do you do with arduino before switching? I did just one program as I was dense to how C worked. once I have got my head around what was purely C and what may be hardware I went in search of more and rewrote my first program in bare metal.

Doing more than getting to grips with writing some code an the arduino will not help as once you do proper embedded you work in an entirely different way. You don't have to bare metal an ARM, just do an AVR. To do anything clever with a micro you will need to understand the chip and bare metal it or use some other abstractioan system that caters to your MCU in full.

i am writing my first bare metal project on ARM now. Firstly what i need to do the arduino is incapable of and it's not even hard, secondly all the problems I am having are with my limited experience and skills in C, nothing to do with the IDE or abstraction. As i have to work closely to the hardware I could not do it any other way.

Deadline is 5 weeks away, usable MCU's that run arduino are out of stock but I have 1000 SAMC21 chips that I asked to be ordered back in October. Next date any of those come out of a fab is November this year - apparently, so by hook or by crook I am bare metalling this little bastard !

[alexanderbrevig]

Good luck on your project!

We need to stop saying Arduino is C. It is C++

Saying Arduino can't handle something is dangerous. SAMC is already supported so one could just add the firmware you're making, reset registers to default values, the call your software from setup and claim victory.

There is nothing magical with Arduino, neither does it lock you down to using the abstractions.

For me, the little magic is broken. I still enjoy giving magic powers to others though. People blinking their first LED is magical.

[Simon]

what board has the SAMC? The problem is that the working of the arduino is different to bare metal programming. If I'm going to put some bare metal stuff in then I may as well just bare metal it. I'm either bare metal or not.

I'd not wnat to mess too much with the arduino with my own code. By the time I work out if what i wnat to do is OK, I will have done it bare metal in less time.

[rstofer]

Question is how much do you do with arduino before switching?

Perhaps just as long as it takes to work through the experiments in the Starter Kit.  Maybe use it on some future mechatronics projects, maybe not.  But it is worth the time and effort to work through the experiments.  Learn a language, learn a device/paradigm, learn something about electronics and IO, then move on.  Maybe a month's work...

I did just one program as I was dense to how C worked. once I have got my head around what was purely C and what may be hardware I went in search of more and rewrote my first program in bare metal.

Doing more than getting to grips with writing some code an the arduino will not help as once you do proper embedded you work in an entirely different way. You don't have to bare metal an ARM, just do an AVR. To do anything clever with a micro you will need to understand the chip and bare metal it or use some other abstractioan system that caters to your MCU in full.

And if the project is sizeable, you probably need to learn Linux and, in particular 'make'.  Then there is the absolute nightmare of getting OpenOCD and JTAG to work or some variant of ICSP.  You aren't using a development board with USB programming, are you?  That might not qualify as 'bare metal'.

i am writing my first bare metal project on ARM now. Firstly what i need to do the arduino is incapable of and it's not even hard, secondly all the problems I am having are with my limited experience and skills in C, nothing to do with the IDE or abstraction. As i have to work closely to the hardware I could not do it any other way.

And the Starter Kit deals with programming in C (in general) although it will be targeting Arduino.  C is a project in itself.  I started with a PIC16F877 and still like the PIC16F628 (if I am FORCED to use PICs) but my favorite among the AVRs is the ATmega128.  But I wrote the code in C on Linux, used 'make' to control the build and AVRdude to do the ICSP programming.  It worked extremely well.  I like the larger AVRs but, you know, I can do the same thing using an Arduino board as the target and not one bit of Arduino code.  In fact, the Arduino IDE uses AVRdude to do the device programming.  I don't need the IDE, I don't need the setup()/loop() structure, I can do anything the chip can do using any IDE I want along with 'make' and the avr-gcc tools.  I would just use the board to hold the chip long enough to program it.

Deadline is 5 weeks away, usable MCU's that run arduino are out of stock but I have 1000 SAMC21 chips that I asked to be ordered back in October. Next date any of those come out of a fab is November this year - apparently, so by hook or by crook I am bare metalling this little bastard !

Don't know if an RTOS is part of your solution but here's a paper:
http://ww1.microchip.com/downloads/en/appnotes/atmel-42382-getting-started-with-freertos-on-atmel-sam-flash-mcus_applicationnote_at04056.pdf

The secondary reason for using an RTOS is to segment the code.  Tasks don't need to know what other tasks are doing, they are self-contained entities.  You build your project by concentrating on the task code, not the overall structure.  Structure comes from FreeRTOS.

It is rumored that IBM used to figure 100 lines of debugged code per day per programmer.  You should have plenty of time.

[rstofer]

SAM C21 development board (just for writing code) that, ...wait for it..., has Arduino headers:

https://nl.farnell.com/microchip/atsamc21-xpro/evaluation-board-xplained-pro/dp/2492013

I didn't check stock, heck, I can't even read the page!

There's a bunch in stock at Mouser:

https://www.mouser.com/c/?marcom=187817120

Development boards can be worth their weight in gold (when the price of gold is depressed).