Even just making software for those things can be interesting. You need to know how the memory is laid out. You need to know if an interrupt happens at the wr

Even just making software for those things can be interesting. You need to know how the memory is laid out. You need to know if an interrupt happens at the wrong spot you are broken. I had one where the data was bumping through a 485 bus and the data was coming out wonky on the other side. Meaning I had 0 control over the software or hw on the other side as it was a vendor product. But I could at least read the chips numbers and guess what the dev did with the memory segments on the other side. Turns out I was telling the thing to read over a memory boundary which caused odd results. Which lead me to breaking the command into 2 parts. Sometimes being an embedded dev is dead easy. Other times you are dealing with a GCC chain from 2003. 2 layers of some 3rd party of libs that someone bought in 2005 because the VP was good friends with a buddy in some other company that made something similar (which you may may not have the code for). With 64k of flash and RAM. And the vendor ground off the chip numbers and put their own sticker in place. Playing detective, historian, and making good guesses as you may not even have access to the firmware anymore. Then on top of that sometimes you are really lucky and have a debug port and can play the printf logging game to see what is going wrong.