3 ms·
My first job was on working on drivers for a proprietary OS. Every time a new board came out, the protocol was to copy the code for the most similar board and s
by dehrmann 3y ago
My first job was on working on drivers for a proprietary OS. Every time a new board came out, the protocol was to copy the code for the most similar board and start making modifications. It works, but there's a whole lot of repeated logic for common init sequences and logical mapping of memory addresses to what they control. The "simulator" that was widely praised for cutting down on spin-up time for a new board was nothing more than stub code. It all worked and was maintainable, but everything was harder than it needed to be.
- ryukoposting 3y agoThis is almost a word-for-word description of the dev workflow for a proprietary embedded OS I worked on as an intern. Even the "simulator" was what you describe - some #ifdefs that turn the program into a cli program using Win32. This worked for us because our approach was to "make it right the first time, update only when necessary."
- david-gpu 3y ago> Every time a new board came out, the protocol was to copy the code for the most similar board and start making modifications I only saw that happen at one place. It was a bit of a shitshow. Big corps don't do that, they have a clear internal division between various levels of hardware-independent and hardware-specific components, down to workarounds for specific bugs in specific releases.