4 ms·
> some hardware registers were being initialized in a procedure that was allocating working space for a numerical part of the program, because that's here he ha
by riskable 4y ago
> some hardware registers were being initialized in a procedure that was allocating working space for a numerical part of the program, because that's here he happened to open the log file for the first time, and he wanted the logging from the hardware registers to be the first thing in the log file, before he logged the fact that the memory had been allocated successfully.
To be fair (haha) I went from writing super organized code with loads of concise, well-documented files to writing code just as you describe when I started designing hardware and writing more complicated embedded firmwares. For whatever reason, hardware initialization boilerplate doesn't like to be spread out or organized. As soon as you try your code ends up breaking outright or becoming a vastly more complicated, gigantic mess.
It's because the hardware is soooo specific and we as software developers want to make interfaces that are as generic, high-level, and re-usable as possible. Example: You can't just write a function that takes two pin numbers and initializes I2C on them so you can talk with some module. You usually have to know--ahead of time--which two pins you're going to be passing to that function (so the types match; because each pin has its own special type haha) so the function can initialize the correct I2C bus on the chip (in the right way)... Which immediately makes such a function non-generic and kinda pointless since you'll never be able to re-use it in anything else for any other purpose. You quickly get into the habit of saying to yourself, "Why am I making this a separate function again?"
Also, the order of operations matters so much more in embedded stuff than it does in regular software. I could totally see the situation where you want to initialize logging immediately after initializing some hardware because you want the logs to reflect values that you only happen to have available during initialization... You don't need them after initialization so why waste precious memory keeping variables around just so you can log them later? Just setup the logger in the same code, write your variables, and be done with it!
Makes sense, right? Hah! Only in the world of embedded firmware!