Top products from r/embedded

As others have said here, learning is never a waste of time. But, despite your post title, I think that's not what you're asking. You seem to be trying to figure out whether you should switch careers and whether it's realistic to think you can do so. First, you should ask yourself why you want to do this. You've said you love embedded, so I assume you think you'll find it's more engaging than QA and devops. You might take a moment to reflect upon your reasons though. Is it truly because you think it'll be more fun than what you're doing now? It is possible you feel that you've plateaued in your current position and you're hoping to change the trajectory of your career with a dramatic change to something you've enjoyed in the past? Are you hoping to make more money or have more control over your work? Do you dislike your boss?

Those questions might sound leading--as though I presume to know what you're really thinking. I don't, and they're just examples of where your head could possibly be at. It's important to question your motivation for changing careers because there might be a smarter, shorter path to getting what you truly want. For example, if you generally like QA/devops, but you're feeling like you're hitting a dead-end career-wise, you might first question whether there's a way to increase your trajectory while leveraging your six years of experience before changing direction. Maybe you could move to an area with a hotter devops scene where people are solving really tough infrastructure and scaling problems; where you'd suddenly have more senior mentors who've done some really cool stuff in your field.

But, let's assume you sort of fell into a QA/devops role and you're certain it's not your passion. In fact, you'd even be willing to take a pay cut to work on embedded projects. You should look around for local opportunities and see what's required. Here's the first entry-level position in Kentucky (Louisville--no clue if that's near you) that I found:
https://careers.geappliances.com/job/GEAPUS88/Software-Engineer-Embedded

It's asking for a BS in Electrical, Computer or Software Engineering or equivalent. Considering that they list it explicitly in this intermediate-level posting, I'm pretty sure they'll consider a Computer Science degree. Other than that, they pretty much just want you to know C (it sounds like you do, even if you're still learning), understand test-driven development (read this book), have a passion for software (sounds like you do), speak Mandarin (unless you do speak it, pick that as the one requirement you're allowed to ignore. GE is large and probably has a number of opportunities that could be a better fit), and have 1-5 years of experience of embedded development (which is where your time investment comes in through personal projects).

Sound attractive and tractable? Look around more and get comfortable with similar opportunities near you--or in areas to where you'd be willing to move. Spend some time shoring up your skills and completing some personal projects that you'd be proud to talk about in an interview. Your list of things you'd like to learn is a great place to start from. You shouldn't need to buy much equipment to get started. If you don't have access to an oscilloscope, pick up something like a Logic 4 for $110: https://www.saleae.com.

When you start applying, don't just blast your resume and a form letter to jobs email addresses. Spend some time on LinkedIn and see if you can get an introduction to a hiring manager. Regardless of whether you're addressing a contact via an introduction or a generic jobs email address, write a custom cover letter that explains why you're excited about the opportunity and how you can leverage your passion and your six years of experience in a different software tech industry. Pick out a few bullet points in the job posting and address them directly. Using the GE posting as an example, talk about how your QA experience has given you an understanding of how to write testable code; how you understand that build automation and automated testing are valuable; how you know exactly when to apply manual testing to things that are costly to automate. You love applying this knowledge along with your demonstrated passion for embedded engineering to build amazing, high-quality hardware products. You're excited because you've not seen many companies advertising continuous integration and test-driven development as part of their embedded development workflows; you think those are great practices for accelerating development, improving product quality, and responding to feature changes without regressing. Etc.

Whoops. Have to wrap up this tome and go walk the dog. Regardless of what you decide career-wise, if you love embedded work, you should most definitely keep it up as a hobby. Writing low-level code in C will give you a better understanding of your hardware, exposure to both good and terrible patterns, and an intuition for what higher-level languages might be doing under the hood. The diversity of experience will make you a better developer (and the same is true for, say, an embedded developer considering a project in Haskell).

Good luck.

Edit: spelling

Not sure what your budget is (buy used books or South Asia editions), but you may find the following useful :-)

Also, unless required, avoid programming in assembly but use C/C++ exclusively. This allows you to carry over much of your acquired knowledge across various MCU families.

• Make: AVR Programming This will teach you programming directly-to-the-metal on AVR using C. If you have the Arduino IDE installed, you already have the "avr-gcc" compiler toolchain as part of the package and hence you just need to setup your path and use the the toolchain in your Makefile. The book takes you by hand and shows you everything. Note that you can use the same Arduino board to do both "Arduino language" programming and "AVR C" programming.
  
  
• Designing Embedded Hardware Excellent overview of the hardware aspects of Embedded Systems. As a Software guy, this book is the one which clarified hardware for me.
  
  
• Building Embedded Systems: Programmable Hardware A very good book on all practical aspects of embedded programming. Hard-won knowledge which will make you a "professional" embedded engineer.
  
  
• Introduction to Embedded Systems: Using Microcontrollers and the MSP430 Excellent and comprehensive textbook detailing the hardware and software aspects of embedded systems. Every topic starts with an illustrated overview of the hardware and then shows you how to program for it.
  
  
• Embedded C Introductory book on C programming for 8051. The example code is simple and direct thus enabling you to grasp the concepts clearly.
  
  
• Patterns for Time-Triggered Embedded Systems Comprehensive and full of C code showing how to program all standard peripherals for an 8051. You can translate the code to your favourite MCU family. The book is available for free from the author's company website.
  
  
• ARM System Developer's Guide An oldie but still the best for firmware programming on the ARM microprocessor.
  
  
• Practical Microcontroller Engineering with ARM technology An exhaustive book on programming the Tiva version of the ARM Cortex-M4 MCU. The book reads like a manual but the ARM Cortex is complex enough that there is no easy way to learn it.
  
  
• The Engineering of Reliable Embedded Systems Advanced book showing how to implement industrial quality embedded software on various ARM platforms. The 1st edition of the book was available for free on the web.
  
  and finally;
  
  
• Computer Systems: A Programmer's Perspective A must-read textbook to understand the low-level details for a x86/x86-64 system. Many of these details are similar for MCUs and hence you will understand them better.

Here is a breakdown of what you need to do/know as an Embedded Developer (STM32 based):

1- Understand your tools.

Understand how to use embedded development tools such as compilers, debuggers (hardware and software) and built environements. You can go the GCC-ARM+Make+openOCD/texane_stlink route but this is a time-consuming process and though I do recommend it, it is not necessary. Almost all vendors have a free development IDE available nowadays. For STM32, have a look at their System workbench IDE developed along with AC6. It is eclipse based and includes compiler and integrated openOCD for debugging. The STM32CubeMX code generator is also a very nice tool.

For debuggers, there are plenty of official and unofficial STLink debuggers that can be bought for anywhere between $5-$200. The cheaper ones work great. All ST-Nucleo boards come with built-in debuggers. If you intend to use other ARM chips have a look at the JLink debugger. It's more expensive but worth every penny.

For simply programming the STM32, you can use the STLink debugging hardware, ST-Nucleo drag and drop programmer, or the bootloader. All STM32s come with builtin USB/Serial bootloaders that can be activated via changing voltage levels on the BOOT0 and reset pins. This is a really neat feature that all STM32 developers need to be familiar with.

​

2 - Understand your hardware.

Read the reference manual for whatever chip that you are interested in. Know the chips memory map. You also need to understand how to perform bitwise manipulations in C. Specifically you need to be able to:

- set/clear & toggle one or more bits in a register

- test the state of a particular bit or group of bits in a register

You should leverage the information in the reference manual and knowledge of bitwise manipulation to write your own simple GPIO and Serial driver functions (polling based). Same goes for simple peripherals including SPI, I2C, ADC, DAC, Timers, PWM, and even the onboard DMA.

You also need to be familiar with the CPU's/SOC's Interrupt architecture i.e. how to enable/disable interrupts globally, locally and write your own Interrupt subroutines.

If you can do this then you understand the hardware enough to bend it to your will. You do not need to know the CPU architecture i.e. pipelining, caching e.t.c though it does not hurt and will occasionally come in handy.

​

3 - Understand how to use the hardware vendor's provided API.

Writing your own drivers is great but the hardware vendor's API provides better portability and is `usually` better tested and supported than custom drivers. Also writing custom drivers for more advanced peripherals such as USB, Ethernet, SD card interface e.t.c. can be quite a challenge. It's better to utilize the available vendor API instead for those big boy peripherals . Don't try to jump directly to the Vendor API for all peripherals though. Understand the hardware and at least build and test a couple of simple custom drivers as mentioned in step 2.

​

4- Understand how to use an RTOS.

Nowadays more and more projects rely on a real-time operating system(RTOS). FreeRTOS is a very good and popular choice. Learn how to use it. RTOS knowledge and use is essential for large embedded developer projects.

​

Books:

- Carmine Novello's Mastering STM32

- Muhammamd Ali Mazidi's STM32 Arm Programming for Embedded Systems

- Jim Cooling's Real-time Operating Systems Book 2 - The Practice: Using STM Cube, FreeRTOS and the STM32 Discovery Board

- Warren Gay's Beginning STM32

Good luck

https://www.amazon.com/Beginning-STM32-Developing-FreeRTOS-libopencm3/dp/1484236238

Also check out ESP32 with it's own great SDK. They made a POSIX like layer for FreeRTOS and have a load of ported light libs for it. All just GCC and Make so nice and simple. (Big thing in the POSIX layer is a PThreads implementation with all the standard Threads, Mutexs and Conditionals, etc)

All very Unix/POSIX/Linux command line but I always recommend developers to be able to at least get by in that environment. Saying that often get down voted here, but I stand by it.

I'd also recommend Linux'ing up to, with a Pi (or other cheap ARM thing) or an old machine.

Anyway, hope those snippets help. Have fun! :-)

You may be able to find a job that uses no C++ at all, especially on legacy projects, but pretty much every relevant new project is C++. You absolutely should know both C and C++ if you're serious about embedded development and I estimate that at least 70% of the jobs require C++, at least in western Europe.

You can start your embedded C++ journey with Real-Time C++: Efficient Object-Oriented and Template Microcontroller Programming, which explains the subset of (modern) C++ most often used for embedded programming. There is a lot more to C++ than this. It's probably the most complex language in mainstream use. This will get you started, but I suggest expanding your general C++ knowledge right after you read the book.

This book also assumes thorough knowledge of embedded C, which in turn requires excellent knowledge of C in general. So I suggest you learn C well (I suggest reading C Programming: A Modern Approach by K. N. King), then learning about embedded C (Making Embedded Systems: Design Patterns for Great Software by Elecia White and Test Driven Development for Embedded C by James Grenning), and then learning embedded C++ from the previously mentioned book. Then you should broaden your general C++ knowledge and learn about design patterns (these are canonical approaches to solving frequently encountered problems). You'll have to learn Make (and probably CMake) along the way, and should use git from the get go. This is my brief intro to embedded programming.

Course 1 was definitely useful but I also found it pretty easy. I've been busy with other things for the last several days (mostly learning Fusion 360) so I'm still on the UART lesson. I think the most useful part so far has been learning more about design patterns. I've been concurrently reading Making Embedded Systems and the combination of the book and the course has been great.

When I switched away from arduino the microcontroller tutorials on https://www.newbiehack.com/MicrocontrollerTutorial.aspx really helped me out. The book make:avr was inexpensive and good too. The i2c library that comes as a download for the book is really easy to understand, too.

http://www.amazon.com/gp/aw/d/1449355781/ref=mp_s_a_1_1?qid=1427629852&sr=8-1&keywords=make+avr&pi=AC_SY200_QL40&dpPl=1&dpID=510a6bjDnWL&ref=plSrch


I would recommend using atmel studio and a programmer of some sort - avrisp mk2 if it's still available or the atmel ice. Avrisp is a programmer only and the ice is a debugger as well.


Buy some atmega328p in a dip package and bread board it out so you know how to setup all the connections. The newbiehack tutorials will show you how.

Feel free to get in touch if you have any questions

Seconding what other users have posted here, the datasheet is your best friend. But I might also recommend for a beginner MSP430 Microcontroller Basics by John H. Davies. I also started with the Arduino as well and when I did my internship at TI, this is the book my mentor recommended to me. The author does a really good job of going in-depth into every feature of the MSP430 and explains not just what the feature is but what it could be used for. He also provides workable Assembly and C examples. And the book isn't just good for the MSP430, you'll learn about topics that useful across the spectrum of embedded systems.

I second freeRTOS. Pick up an Atmel dev board. They have good support for freeRTOS. Big concepts here will be stack management, mutex/semaphores for thread safe operations, using message queues to communicate between threads, blocking/non blocking operations, and find a profiler so you can visualize your efficiency.

For driver development I will point you towards Linux. Try writing a basic storage or GPIO driver on a raspberry pi. I have linked a book below that will help with understanding Linux drivers. The big thing is you will have to use ioctl calls to communicate with your driver.
Link to book!

Wow, cannot believe that nobody recommended the excellent book by Scherz and Monk: Practical Electronics for Inventors. I guess this is what you are looking for.

​

Sounds like you don't know some of your low-level computing fundamentals as well as you should for the jobs you want. I recommend studying up on those, and then developing more familiarity with them by tinkering or doing relevant projects.

​

If you're looking for a book recommendation, try Computer Systems: A Programmer's Perspective. If you read and understand chapter 2 (it's dry, hang in there), your question #1 will seem trivial to you (and you'll learn much more as well; pretty much all of it is important material). The book overall is a great read for embedded programmers, and anyone doing any form of low-level computing. There is a newer edition but the one I linked is the one I read.

​

I started early on with Arduino and moved into lower level embedded with the stm32 discovery line of development boards. Attached link of a good starting board that has tons of example code from ST.

https://www.mouser.com/ProductDetail/STMicroelectronics/STM32F407G-DISC1?qs=mKNKSX85ZJejxc9JOGT45A%3D%3D

If you want a decent intro book into embedded topics, this book does a decent job of introducing the different parts of working on an embedded project:

https://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149

​

Between the Arduino and Pi, the Arduino is more representative of an embedded device. It introduces you to resource constrained system that can be a good starting point for working with digital and analog io's and can let you hook up to communication bus enabled peripherals that use UART, I2C, and SPI. The biggest problem is that it will not introduce you immediately to debugging and standard compilation tools. However, arduino has been a starting point for many developers. Good luck!

I agree. I was recommended this one:

https://www.amazon.com/Embedded-Linux-Development-Project-Cookbook/dp/1788399218/ref=nodl_

When I asked here a couple of months ago and it’s been helpful as well.

I'm in a similar boat, VSCode + PlatformIO seems to be the best option that I've found.

Also this book is a good place to start, although they're focusing on the Blue Pill instead of a nucleo board - https://www.amazon.com/Beginning-STM32-Developing-FreeRTOS-libopencm3/dp/1484236238

I found the Make AVR programming book very helpful. I took an online embedded course offered through my university last year and the instructor and content were awful. If it wasn't for this book I never would have passed the course or been able to decipher any of the course material or assignments. I ended up with an A which was solely due to this book and does not reflect on the quality of instruction I was offered in any way. I'm still salty about the $1k I spent on the course but a credit is a credit I suppose.

https://www.amazon.ca/AVR-Programming-Learning-Software-Hardware/dp/1449355781

When I know that an interview is gona be technical - I run through Expert C Programming: Deep C Secrets by van Linden. It's pretty dope - not boring and goes pretty deep on the low-level stuff.

Fellow Embedded Engineer here.
You learn this from books: The Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4 Processors.
And just RTFM of course: Cortex M4 technical reference manual.

And of course the chip vendors documentation, since there will be some implementation defined stuff (eg: which memory bank stuff will boot to).

Don't forget the compiler and linker documentation. Lot's stuff is there, just scrolling through once gives you so much more understanding, and what you might find there if your solving some problem later on. Like the special instructions, and the compiler flags and conditions for it to actually use the FPU.

If you're going to try this bare metal assembly programming, I'd recommend the Cortex M0, since an M4 often comes in a complex chip.

Just FYI there is a 3rd edition out. Great book.

Real Time C++ 3rd Edition

>This one includes a lot of useful stuff: Real-Time C++: Efficient Object-Oriented and Template Microcontroller Programming

Does it involve hands on programming practices/projects or it's mainly theory? I haven't bought a single book on programming and I am wondering if it's worth a shot -- specially now that I am looking to work on STM32 and low level drivers and maybe RTOS as well

There aren't any that I'd recommend, unfortunately.

This book is not specifically about embedded C, but about embedded in general:

https://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149

Anything by Jack Ganssle is good as well.

It's not ARM based, but this book about the MSP430 was very helpful to me. This is arguably a better starting point because the MSP430 processor is simpler than an ARM processor, but there is still a lot of carry over.

Here's a few books I highly recommend:

Making Embedded Systems by Elecia White

An Embedded Software Primer by David Simon

Programming Embedded Systems in C and C++ by Michael Barr - out of print, but still a decent book.

Also, embedded guru Jack Ganssle has a long list of embedded books he's reviewed here: http://www.ganssle.com/bkreviews.htm - lots of good stuff on there

Are you familiar with logic design (multiplexers, decoders, registers, logic gates, etc)? Computer Organization and Design covers a lot of it and is relatively easy to read. But having some background in digital logic will help a lot.

Would you recommend a kit like this?

Making Embedded Systems: Design Patterns for Great Software https://www.amazon.com/dp/1449302149/ref=cm_sw_r_cp_apa_i_BbryCbHZDAV0T

Great book:
https://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149/ref=sr_1_1?ie=UTF8&qid=1525458632&sr=8-1&keywords=embedded+systems+elecia+white

in college, my intro computer engineering class used Digital Design and Computer Architecture by Harris and Harris. It talks mostly about the PIC32, but the concepts are the same. It also covers FPGAs. The 1st edition doesn't include a chapter on C, so it might be better for you to get the second edition.

Get the book Test Driven Development for Embedded C

https://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X/

It covers all this and more in a very useful level of detail.

Friend, There's a nice book showing how to do TDD in embedded systems from James Granning: https://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

Anyways, The magic to do off target testing is to abstract everything that is platform dependent and mock it out on the test build. Some will say if you mock out platform it will be left with nothing to test, but it is not true, anytime you have a data in RAM, it is testable, so you can test most of your embedded code: interrupt handlers, serial buffering, business logic, actuator. By this point you must have figured out that what is mocked out of the application is the peripheral functions and hardware outward.

JoesGym has used dependency injection to abstract hardware, which depending the way it is done it can get big or heavy. I do recommend to start simpler, select ".c" files for a ".h" interface accordingly to the platform in the build scripts, so, for real code, your "uart.c" will actually talk to the peripheral, where in test code "uart.c" will put the data in a special place to be later checked during tests.

In case you'd like to have a look at a simple led blink with TDD project, this is one: https://github.com/flplv/UnitTestingEmbeddedC-Demo1

I found this one very helpful

https://www.amazon.co.uk/Definitive-Guide-Cortex%C2%AE-M0-Cortex-M0-Processors/dp/0128032774

would recommend this too!

https://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

This was mine: https://www.amazon.com/Digital-Design-Computer-Architecture-Second/dp/0123944244

Starts at the electrical layer and works up. I really like it.

Then buy this book which explains exactly how to do that, as well as what the Arduino IDE does for you.

Ah, a question I'm eminently qualified to answer, since I'm working right now on a project where I won't have working hardware for another 2 weeks and need to get the software working before then.

Yes you can do this, and yes you should.

At my company, we do this routinely. Writing code with a nice IDE is much easier and faster than the crappy IDEs for the embedded processors. Debugging code on Windows can be an order of magnitude faster than doing it on hardware.

First, break everything down into components. I do VoIP stuff, so at the core there's the audio processing and network libraries. Then there's platform-specific stuff, like what audio hardware and buttons and LEDs are attached. Then there's application code (or you might prefer the term "business logic"), the stuff that says "when the button on the front panel is pressed, it calls a phone number and turns on the LED".

So to make a Windows port of this, what would I need to do? The core libraries are designed to be cross-platform anyway, so that's already solved. The hardware-specific stuff, there's no choice; it has to be unique code for the target platform and for Windows, since Windows doesn't have GPIOs where I can plug in buttons and LEDs.

The application code in between is where you need to focus. That's the portion that can run on any platform, which you want to develop and debug now. The trick is making your code modular enough that you can do this.

So in my case, let's look at the buttons and LEDs. On hardware, they're just GPIOs. On Windows, I'll have to mock something else up. In some cases, a simple GUI with a button to click, and any kind of box that changes color or something to indicate the LED would be sufficient. Or I could go simpler, and just read keypresses in a CLI app, and print out the status of the LED whenever it gets set. No matter what, the application code needs to be unaware of how the buttons and LEDs work. So you need some kind of simple API, so that the application code can call ledSet(id, state) and ledSet will be implemented differently on hardware or on Windows. Similarly, the buttons would have a simple API so that they e.g. submit an event like BUTTON_DOWN with a data to indicate which button.

There's an excellent book called Test Driven Development for Embedded C which goes into a lot more detail about how to structure and mock up things like this.

> Can I and or should I model the system in Unity (game engine) and use that as a test device? (is this feasible or just a lote of extra work for no pay off?)

Maybe. It sounds like it would be incredibly useful as a way to visualize what the device would be doing. But is it worth it? I don't know anything about Unity, but this certainly sounds like a difficult task. Could you simply print out the machine's position to the console? Would you be able to know by reading that whether it's correct?

For that matter, how will you debug this when it's on hardware? If the gantry doesn't go where you intended it to, how will you determine where the fault lies? If this were my VoIP device, we'd be dumping stuff to the syslog, which is pretty much the same as using the console. But then, we don't have to deal with 3D positioning.

> My question is how do I know if my code is usable or working correctly if I cant compile it load it onto the micro controller and run it?

How do you know it's usable or working correctly if you can run it on the microcontroller?

This goes right back to the book I mentioned. Suppose the only output you care about in this system is the position of the gantry. If you operate some controls and it goes where you intended, then you say it works. What if you operate the controls and it doesn't go where you intended? How will you debug it? How will you determine whether the fault happened when you interpreted the user's input, or calculated where to send the gantry, or controlled the gantry to put it in that position?

If you can separate the business logic from the hardware, then you have a way to simulate this on a PC, but you also have a way to test it. You can test the business logic with mockups and test hooks, so that you can prove quickly and easily with a testing framework that when you give inputs X Y Z, it instructs the gantry to move to X' Y' Z', or that the gantry correctly takes the inputs from stepper motors and drives their output to adjust their position, etc.

> How do I run code if I don't actually have the physical device (i.e. three stepper motor configured in a three plain gantry system?).

Mockups. Again, the book is very helpful for this. But basically, you need to simulate it somehow. If you're debugging other parts of the system (like the web interface), maybe you don't care about the stepper motors; you tell the gantry to move somewhere, and the dummy mockup just immediately reports back that it did.

Otherwise, you need to simulate it somehow. You may want to manually invent values that the stepper motors might report, to deliberately stress your control of it. You could work out a formula to pretend like the stepper motors are being controlled; I would expect they exhibit a bit of lag (you start driving the motor at 300rpm, but it takes a few hundred milliseconds to reach that speed) so maybe you can come up with a formula or delay or something that approximates this behavior. You could also add some randomness, and have the mockup add/subtract a random value in its reports, which might change over time (or every time), to mock up the stepper motors' inability to read their position with 100% accuracy.

https://github.com/ThrowTheSwitch/Unity and https://cpputest.github.io/

These are the frameworks used in this helpful book: https://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

EDIT: Remove unfinished sentence.

Here's the newest edition of the cookbook:

https://www.amazon.com/gp/aw/d/1788399218/ref=dp_ob_neva_mobile

Non-mobile: http://www.amazon.com/dp/1449355781/ref=mp_s_a_1_1?qid=1427629852&sr=8-1&keywords=make+avr&pi=AC_SY200_QL40&dpPl=1&dpID=510a6bjDnWL&ref=plSrch

^That's ^why ^I'm ^here, ^I ^don't ^judge ^you. ^PM ^/u/xl0 ^if ^I'm ^causing ^any ^trouble. ^WUT?

https://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839
That one? Isn't that more high level though?