SPLatMan

image
officer

Biography has not been added

SPLatMan

's contributions
Articles
Comments
    • I'm with DaveSchabel. I'm old enough to to have grown up in a mostly analog world - in fact I still remember the input specs of the µA709 and 741, (though I don't remember what I had for breakfast). I must design to worst case specs, and will only use the typ numbers and curves to extrapolate as best I can. Equally worrying: I recently needed to tell a customer how much current he could safely draw out of the analog output of one of our COTS controllers. It uses a common or garden LM358 op-amp. I checked 3 brands' data sheets. *Nowhere* could I find a thermal resistance number! It would seem that engineers these days are not expected to concern themselves with such matters as Tj. Maybe they aren't taught how to calculate dissipation? Of course, my old printed data book library (once my pride and joy) went to the re-cycler years ago.

    • Bernard, I am getting seriously inconvenienced by the "You have hit you 2 article limit. Please log in" Is this something relatively new? It never used to happen. I log in, then refresh the various tabs in FireFox (I click multiple links in the newsletter then switch to FF to read the articles in tabs), but I still get the same message. Please fix or lose a reader.

    • I like it!. I shall take that as a formal proof. Now let some academic re-phrase that as a eye-glazing equation with lots of obscure non-ASCII symbols and call it Manning's Theorem, the popular version of which will be "all software faults are a result of wetware faults, not inadequate tools". Then we can all forget about it and go back to blaiming the tools for our failures.

    • We made a few thousand "glue boxes" for an HVAC company recently. The logic was at the level of a 555 and one or two gate packs. We used a 37cent 6-pin PIC instead. I could never see 32 bitter doing the same. BTW, what happened to 4 bitters? :-)

    • The above code must be untested. Compare and Branch on Non-Zero (cbnz) and Compare and Branch on Zero compare the value in a register with zero, and conditionally branch ***forward*** a constant value. The sample code expects them to branch backwards. This just cost us 30 minutes work!

    • These are well established principles. They do however deserve to be re-iterated from time to time time if only for the benefit of upcoming generations.

      However, while the author is extolling the virtues of separating function code from hardware and engineering units, he then goes on to say in his ABS example on page 2:

      The output from the core software is a current value that is desired to flow through the solenoid/load.

      Core code generating current levels? That is not divorcing the core from specific engineering units. Surely all brake solenoids don't work at identical current levels?

      This slip will do nothing to help the upcoming generations, and should have been spotted by the editors.

    • I must strongly disagree with Miro on one point, namely that his posting sounded presumptuous. Not at all. Other than that I fully agree. Encapsulation is something I have practiced in varying degrees for quite some time, purely as a self imposed discipline. Almost every time I am tempted to bend the rules I come to regret it. We are currently in the process of developing a whole new embedded controller family, along with its attendant IDE and suite of programming languages. One of the interesting debates we are having in-house is to what degree do we enforce good discipline on our users? This has to be considered in the light of the fact that our users are frequently novices, small to medium sized OEMs where the guy who will write the program has little prior programming experience (scary?). The current state of that conversation is that we will impose as few rules as possible. However, any library functions we provide will have an object type interface and be configured through design-time property sheets. That way our users will hopefully get educated without being bullied. I am using the term Object Based Programming (OBP) to signify the concept of encapsulated objects, although we have no concept of inheritance or polymorphism. I would love to be able to attend Miro's class at ESC. Unfortunately it's a long way from Australia. David Gibson, SPLat Controls, Australia.