danjayh

This times a thousand. I do software for aerospace, and the huge majority of cost and time is not spent on actual design, but rather on reviews, verification, testing, analysis, etc. etc. etc. Imagine having to prove that every single assembler instruction in your entire compiled program (that's right - I helped do this for an entire operating system that was written in C) is correct by writing test cases that run all of them, and then instrumentation that recorded the results in gory detail. Some of the analysis is difficult or impossible to automate. sigh

We also have a massively overoptimistic project timeline. I can't go into details, but I expect several turnovers of middle management through the course of the project due to the fact that they're either a) unaware of the fact that their schedule is impossible or b) just can't stand to tell the customer 'no', because they don't want to be the long pole (to be fair, every single contractor on the entire program is in the same situation). Anyway, when something is about to slip badly schedule-wise, they'll all up and leave to dump it on the next guy (so that they don't get the blame), and then the next guy doesn't get the blame either because he wasn't the one who made the mess. It's a brilliant system.

Your career path is frighteningly similar to my own. I nearly went into the navy's nuke school out of college, but went for a private MSEE instead. In hindsight, this was a good decision.

Yes, but if you ever retype it and you want to look smart, use "µC". If you use "uC" like I did, it means you're too lazy to bother with the mu character (also, the way I typed "mu" is lazy as well).

How I'd solve this: Port it to a much faster uC, run your communications code in a fast high priority interrupt handler, will be rock solid. I think a PIC32MX7 would probably do it.