I don't agree, there. I.e., many libraries are just "lots of mundane code". Nothing earth-shattering or terribly novel. Toughest libraries I've seen are those that try to do FP math
*accurately* (i.e., at the fractional ulp level). There, you're better off *buying* than rolling (those sorts of details make my head hurt) +42There's a lot that can be done to give *added* structure to stuff that would otherwise *look* like a rats nest. E.g., most UI's are total crap to code in any way *other* than as an FSM.
Not only does this tend to simplify and "robustify" ("You heard it here, first, folks!" :> ) the code, but it makes it a no-brainer to tweak the code at a later date -- just by documenting those data structures (instead of trying to document a ratsnest of spaghetti code)
Exactly. You want to be able to look at something "quickly" (bad choice of word) and see where your *obvious* mistake is without sorting through pages of code wondering which *conditional* is "off by one" (">" should have been ">=", etc.). By imposing structure on it, you force mistakes in the "engine" to be more noticeable -- because they affect *lots* of execution paths instead of just one *rare* path.
I'll give you each "partial blame" on that score. You
*could* have looked around to see what the current *state* of the input queue was -- instead of just assuming "there's a message there" (apologies if I am assuming too much, here, based on what little you've said)I've learned that programming defensively when it comes to dealing with the actual iron pays off in spades! E.g., just because there was an interrupt doesn't mean there
*should* have been an interrupt! (so, expecting things to *be* indicating an interrupt can bite you)The best advice when it comes to low level drivers is to use the vendor supplied code as examples of what the code
*might* want to do. To, hopefully, clarify something that is vague in the datasheet.Like (hardware) app notes, treating them as gospel leads to pain.