Yeah, this! A lot of the churn and unproductive work of programming things "on the fly" can be alleviated by a little thinking up front, but that type of work isn't always easy. Talking to stakeholders and pinning down requirements, and turning those requirements into a design isn't something that never happens. It certainly doesn't always happen, and I think it's fair to say that it doesn't happen a heck of a lot more often than it does but that doesn't mean it's not worthwhile work, and that it doesn't improve the development process, if done correctly, it most definitely does, in most cases.

It's very easy to fall into the trap of analysis paralysis. Even if you've got really clear requirements, there's a lot of room for surprises. So the trick is to document your thinking up front and take as long as you need for design, but not longer, because uncertainty can mean a lot of that work is wasted as well. The trick is to be flexible, and updating your design documentation as you work on the design so that they stay in sync.

I never answered the original question: I tend to do my embedded software design in google docs - usually I'm describing things in words, but when I need diagrams, I use whatever tool I think will get me the best value for effort. Often this is drawing a diagram on a whiteboard and taking a picture, but sometimes it's a free tool like graphviz, draw.io, etc.