Member #134773

Member Since: May 19, 2010

Country: United States


I started playing with electronics in the mid-1960s, and with computers shortly after Neil Armstrong took “one small step”. I got a degree in CS in 1980, and started working then as an engineer.

  • The efficiency values stated are usually at 100% rated output. The “quiescent” power will be somewhat less than the “inefficiency” (that is, the difference between 100% and the stated efficiency) of the input power at maximum load. Since these are around 80% efficient, the zero load power draw could, conceivably, be as high as about 20W. If you don’t use the lights many hours a day, leaving the power supply on 24/7 would negate any savings from using LEDs. Using old fashioned incandescent bulbs would produce more energy savings!

  • I think it would be a service to the less experienced to make it more clear in the description that the outputs of the dual supply are PLUS and MINUS 15V. Also, note that this supply, unlike the others, is NOT designed to work properly below 0.1A output. (I can’t determine from the documentation available whether violating this on one side affects the other side, but I suspect it might.)

  • Also, “When the system wants to shut itself down, it can release the power control line. The SYSOFF line goes low, and everyone goes to sleep.” Methinks you mean that the SYSOFF line goes HIGH, and everyone goes to sleep. (PIN_POWER_ON goes low, and since the transistor is an inverter, this allows it’s output to go high.)

    One other nit-pick: The symbols for the push buttons that you’ve used are for normally CLOSED (“NC”) ones (that is, ones that open the circuit when the button is pushed). The symbol for a normally OPEN (“NO”) have the “moving” part all on the same side. (I don’t really think you want the user to have to hold the switch down to keep the device in the “sleep” mode, with it waking up as soon as the button is released.)

  • Actually, you should be snarling at the vendor for not having used the name “_FLOAT” (or even “__FLOAT”), or, better yet, prefix (or postfix) the name with the name of the package (or the vendor), e.g. “GOOD_FLOAT”.

    Having written literally hundreds of thousands of lines of C and C++ code (as well as some other languages), the use of #defines is excellent practice. You just have to be wary of the actual naming. (IMHO, “FLOATING” is a slightly better name, though “Floating” is probably even better. Remember, the C name space is case sensitive, so “PHRED”, “Phred”, “phred”, and “pHRED” are all different names as far as the compiler is concerned.)

  • Goes to show that even an “old dog can learn new tricks”. Thanks! (I’ve been using *nix since about 1977, and had never run across this.) BTW, it also works in a “Terminal” window on OS-X (since OS-X is based on BSD Unix).

  • One other minor thing: You can guarantee that the C compiler will not use up data space for a named value if you use the #define capability, e.g.,

    #define led 13
    pinMode(led, OUTPUT);
    digitalWrite(led, HIGH);

    For those interested, what happens is that the C compiler has a “pre-processor” phase which deals with all the lines beginning with an octothorpe (the correct name for ‘#’). A #define tells the preprocessor to simply replace any (and every) occurance of the name with whatever is on the rest of the line before the (actual) compiler sees it. (Note that the preprocessor is “linear” in that a #define only affects code after the #define.)

  • A couple of “nits” this week: First (since I’m a compiler designer) “label” has a very specific meaning (i.e., the “target” of a “goto”), so it’s much better to use the term “name”.

    Second nit: When talking about floats, it’s also important to note that there is a “smallest non-zero” number that can be stored. Off on a tangent, when a math operation on a float leads to a number that’s too small to represent in a float but is clearly non-zero, it causes an “underflow” error. This leads to something of a joke: I often say “my cup runneth under” (a play on Psalm 23:5, and meant to irritate the Bible-thumpers).

    On the “strongly-typed” versus “loosely-typed”, IM[NS]HO, it is FAR better to catch potential errors at compile time than having to waste hours/days/weeks (and, if you’re trying to control something physical, destroyed hardware) trying to track down that you passed a char ‘5’ when you should have passed a byte 5.

    (One of my pet peeves is that K&R [and many other language manual authors] didn’t include a table of ASCII as an “appendix”. With Google and Wikipedia, it’s not as critical today, but 20 years ago it was VERY frustrating.) BTW, I remember the days of complications with EBCDIC. Baudot, and some other more obscure codings for characters…

  • Hmm… methinks it much more likely for Pandora to encounter “ghosts and goblins” on Halloween than on St. Patrick’s Day… ;-)

  • I actually had the opposite problem a few years ago on a M$ computer. We were testing a product that interfaced to the PC via USB, and every hundred or so, we had to tell the PC to “forget” the USBs it had seen – a tedious job, which required multiple mouse clicks (including answering “Are you sure?” for EACH ONE). And folks wonder why I dislike M$…

  • Shawn,

    I’ve suggested this to several people who have set out to learn object oriented programming. First, go read the book Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig. Don’t worry, it doesn’t have much to do with either Zen or motorcycle maintenance. And it has nothing, directly, to do with ANY computer programming, OOP or otherwise. However, it can help you to be open-minded to new paradigms, which is what you need to succeed with learning OOP.

No public wish lists :(