With embedded systems you have to deal with a very limited set of resources, and you’re expected to do a lot with these limited resources. You often have to be creative about how you use them to achieve your goals. You constantly have to question your assumptions about what is required to accomplish a task. When that questioning leads you to shift your perspective in the correct way, this is when we get to innovate.
Often, we'll play around with existing solutions that aren’t resource constrained; we'll test the boundaries to see what it does when we poke it this way, or when we pull it that way. This testing gives us an idea of the limits. Then we ask, does it have to do it this way? What happens if we forgo this part or we leave that part aside? We'll test the existing systems to see how they react, and then we'll amputate parts and see how well they survive each amputation and see if we can run with that. So basically, you tear stuff apart and see how you can put it back together in a way that nobody ever did before.
Innovation happens when you need to adapt something to become something that's not existing. Sometimes you can adapt an algorithm that was never meant to run on some specific hardware by sacrificing some parts of that algorithm or using some novel technology that nobody ever envisioned working the way you’re using it.