Reddit mentions of Test Driven Development for Embedded C (Pragmatic Programmers)

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.

would recommend this too!

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

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

I use CppUTest for my embedded project. It used the book Test Driven Development for Embedded C to get into it. So far I'm rather pleased with it.
There is also Unity.

I don't think there really is a standard framework that everyone uses.

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.

I haven't programmed c++ is about 15 years, so take everything I say with a grain of salt. I'll just point you in the direction of people/books that have more knowledge.

If you want to read about unit testing with C/C++, try James Grenning's writings. He, ehm, wrote the book on all this. And with a focus on embedded work, so you can be sure he deals with performance considerations.

There's a concept called 'composed method', which means that a method should do one thing, and one thing only. That also means that it should not have any side effects. And that means that either the method does an operation and returns a value, manipulates state of the class under test or, as you say, operates on some call outside the class.

In the first two cases, it's straightforward to test. In the third, we can use patterns such as dependency injection to inject a fake. Or we can use a mocking framework to isolate the class under test. In C++, this does mean that you need to at least have an interface to be able to create a fake, or make the method virtual to be able to use a mocking framework. Programming against interfaces is not a bad idea, as long as you don't overdo it. In most cases, performance won't be a major issues for this, unless you work on very small devices or have particular performance requirements.

In C#, this all is not really an issue. For JavaScript, have a look at 'Testable Javascript': some nice discussion on testing and event-based designs.

Embedded.com has a decent reference: http://www.embedded.com/collections/4397931/Object-oriented-C

This book also has some good general OO design info in addition to the test info: http://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

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

Yes, I've built several device simulators. Some were quick & easy, just enough for basic system testing. Others were much more involved and were built before the real system even existed. Now I'm at Bright Wolf and specialize in Industrial IoT System Integration. We strongly recommend the use of IoT device simulators so that you can adequately test.

Parasoft has a whole suite of tools that could help with your testing.. In particular, the unit testing framework is helpful (https://www.parasoft.com/product/cpptest/). I'm not sure what language you're using, but if you're trying to unit test embedded c I recommend this book: https://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

beyond unit testing, Parasoft also has tools that help you quickly simulate other systems. So, you don't need an entire server/system or Internet connection to test things out. Check out their API testing suite here: https://www.parasoft.com/capability/api-testing/