Advertisement

johnspeth

image
Firmware/Software Engineer

Biography has not been added

johnspeth

's contributions
Articles
Comments
    • "All existing embedded systems use the Cortex-v7M architecture." I beg to differ, Sir.

    • I agree. We technologists/geeks can easily see the solution on the horizon. What we can't predict is what happens after the first family is killed due to an unforeseen hardware failure (or even worse, an unforeseen machine/human interaction anomaly). Regulators will ground plane fleets when these kinds of failures happen. How will the regulators deal with self driving cars that have a mysterious failure mode?

    • I could have written this article in a couple of sentences: Good firmware costs a lot of money. It's an inescapable fact.

    • I always start with the technical term "Embedded SW Engineer". Usually people return that "Huh?" look. Then I tell them that the multitude of computers in just about everything that is powered needs to be programmed and I'm one of the guys who does it. They understand that but few take the conversation any further.

    • I think the line: result = get_loc() ? true : false; is absolutely appropriate for good code. It serves readability and explicitly shows the Boolean nature of the result while insulating the return type of the test function from the result variable type. All the rest of Jack's examples are horrid, IMO.

    • Now that it's 50, I would think that there would be numerous public domain versions of Basic interpreters many of which should run in a small footprint on an embedded host. I searched several years ago and found a few but none that I could get to port using C. Does anyone know of a good open source or public domain embedded Basic interpreter?

    • While post- and pre- inc/dec will have defined behavior in C or C++, it's not always obvious to every person who might read the code. I think the well seasoned programmer would do a good service to his associates by avoiding heaping incrementers or decrementers into a line of code. I advocate for the one line, one operation paradigm. For example, which is less ambiguous when reading it? arr[--i] = x++; or i--; arr[i] = x; x++; C shouldn't be an exercise in how to cram the most code into one line.

    • "80% savings" "25 times longer" but at what cost of energy and at what retail price. It's great for marketing but for us engineers, the missing details are clues that Philips is hiding the cost of entry. Likewise, "potential to save 32.6 terawatt-hours of electricity in one year" fails to mention how many bulbs would need to be replaced to gain that savings. I'll be the reality is that the savings will be much much smaller when retail customers use these bulbs.

    • Yes, age discrimination is no secret, in general. It's simple economics. A company has a labor budget and will usually not pay the salary an older engineer will usually require if the budget won't allow it. However, when budgets are flexible, I suppose the age bias will exist, for after all, it probably simple human nature.