* No exceptions, ever

* No RTTI, ever

* Compile with -Os

* Limit STL to the non-allocating, non-throwing parts

* Don't allow heap usage

* Link against the C standard library so you don't get accidental heap allocations from lambdas with large capture specs and static construction and destruction fail to link

* Use alternatives to std::function (which while easy is very large and very slow)

* Limit the use of virtual functions (some people suggest eliminating them altogether but I feel like that's a bridge too far).

* Avoid inlining functions if you're not sure that they reduce down to something trivial. I've saved a kilobyte or two by moving some particularly large, commonly used functions into separate translation units so that the compiler couldn't inline them.

* Look at and track your space utilization commit by commit. If the data segment goes up unexpectedly, revisit what you're doing. You may have unwittingly allocated a big block for something. Similar for the code segment.

You get used to the constraints. Type safety, templates, and compile time programming make it 10 times better than C for the purpose in my experience. The only reason to use C is if your C++ compiler is garbage (which is often true for the tiny low powered processors). But if it's ARM you probably have access to a modern compiler and the only reason to stick with C is inertia.

I've been programming with embedded C++ for ten years and every time I have to poke into the C part of the codebase I end up hating life.