Those are all beginner embedded problems. Big problems include
* You're developing a controller that controls something. Now you have to have the hardware it controls. This can be a sizable piece of industrial equipment. You may need a simulator for it.
* I've seen auto engine controls developed. Phase I was run connected to an engine simulator. Phase 2 was run connected to a test board with the auto components, including one spark plug, and an analog computer to simulate the vehicle power train. Phase 3 was run on a test stand with a real engine. Phase 4 was run in a car with a debug system plugged in. Yes, you need all that stuff.
* Safety issues. You may need a separate safety system to monitor the primary system and shut it down. Traffic lights have a simple hard-wired device which has inputs from all the green lamps, and a PC board wired with diodes to indicate which can't be on at the same time. If the checker detects a conflict, a relay trips, all the lights go to flashing red, and the CPU can't do anything about it. Some systems allow the CPU to try again after 30 seconds of flashing red, but usually it requires someone to come out and replace the electronics.
* JTAG is your friend, but JTAG is so low-level that it's a huge pain.
Phase 1 was running with blinky leds on breadboard. Phase 2 was prototyped version running under the seat of my motorcycle hooked up ti the engine sensors and datalogging the output of my hardware/software compared to the OEM ignition/FI while I rode it round the block and local neighbourhood a few times. Phase 3 was hooking my version up and riding it around... Safety issues, huh? ;-)
(Arduino driven ignition and fuel injection for a motorcycle a bunch of years back. Gave up on it 'cause though it worked well, I never got it reliable enough. Fun way to waste a year or so's worth of weekends/evenings...))
Look into megasquirt. I did a completely custom setup with it years ago and it was great. Put a few thousands miles on the car, as reliable as OEM. Built the thing from a blank citruit board, built my own wideband controller too. Was damn surprised that everything worked.
Support was pretty good for custom sensors, only problem is your knowledge has to run damn deep with these things before you can get the engine to start :)
I had wideband autotune for O2, idle control, knock retard, coolant and air temp compensation, basically every original sensor from the motor and a few extras I bolted on worked great
Of course, you need to know how to get an engine running from a blank fuel and spark map...And blank enrichment/retard and aux maps for all these sensors.
Anyways, was good fun. Lot more interesting than the toy stuff people are doing with Arduinos for the most part
I've heard better things about DIYEFI, mostly entirely because megasquirt isn't properly open source. Other than that I think they're both pretty good.
A bunch of posts in a forum that's no longer around - mostly... This was back in '08/'09 and the MegaSquirt project was getting off the ground with _way_ more capability than I had in my hardware. (And I sold that bike, right now none of my bikes run fuel injection - although I've got crazy ideas about using bits off the Honda Grom to convert my 2 stroke 125cc Cagiva Mito from carbs to FI... Maybe... One day...)
* Not giving up when your errors do lead to physical damage. Repair the heat exchange radiators that froze because you didn't test what happens when outside temperatures drop. Change the timing belts that snapped because of off-by-one mistake when estimating position of part on conveyor. Straighten the door bent by air pressure when your pressure/temperature regulator oscillates because it was tuned without taking sudden disturbances (opening the said door) into account.
* Staying motivated during the long product development cycles. Just when you think you're finished when manufacturing starts- there is still a lot of grunt work to do.
* Designing a logging system that stores enough information to pinpoint issues yet be lightweight enough.
> * JTAG is your friend, but JTAG is so low-level that it's a huge pain.
Yes, JTAG is definitely your frenemy. Hopefully you have a fast version or even better a full trace probe but those are usually vendor specific so more cost
For the Cortex series, at least -- a full trace probe will give you a buffer that allows essentially realtime instruction view, global, long-term recording of all executed instructions and memory accesses, etc. (I imagine the same idea is prevalent among all tracers, modulo whatever vendor-specific addons they have.)
An example are SEGGER products -- their ordinary JLink products (JTAG/SWD) vs their J-Trace series (dual Cortex Trace/JTAG) -- https://www.segger.com/jtrace-pro-cortex-m.html -- The difference is somewhere in the realm of $1000, in this case (plus some other CPU support differences). Their tools are even fancy enough to reconstruct the instruction trace back into live code coverage/profiling reports (using the DWARF information). Your IDE "populates" the report live as the trace comes in.
(As a side note, SEGGER makes an excellent and affordable JTAG probe if you're new to embedded stuff like me and using ARM systems. It's a standard probe but comes with a _lot_ of very useful features and is standard GDB-compatible -- the RTT features are much nicer and faster than printing over UART/SWO, for example. The non-commercial, basic version is only $60 too, so it's very affordable. I have one along with my BusBlaster for OpenOCD setups.)
I wondered briefly whether it would be possible to get cheaper open-source trace tools, like the very reasonable Olimex devices. Then I looked at the maximum trace output speed of 600Mbit and noped straight out again; far easier to pay the $1000 than try to design my own system to manage that.
* You're developing a controller that controls something. Now you have to have the hardware it controls. This can be a sizable piece of industrial equipment. You may need a simulator for it.
* I've seen auto engine controls developed. Phase I was run connected to an engine simulator. Phase 2 was run connected to a test board with the auto components, including one spark plug, and an analog computer to simulate the vehicle power train. Phase 3 was run on a test stand with a real engine. Phase 4 was run in a car with a debug system plugged in. Yes, you need all that stuff.
* Safety issues. You may need a separate safety system to monitor the primary system and shut it down. Traffic lights have a simple hard-wired device which has inputs from all the green lamps, and a PC board wired with diodes to indicate which can't be on at the same time. If the checker detects a conflict, a relay trips, all the lights go to flashing red, and the CPU can't do anything about it. Some systems allow the CPU to try again after 30 seconds of flashing red, but usually it requires someone to come out and replace the electronics.
* JTAG is your friend, but JTAG is so low-level that it's a huge pain.