Biography has not been added
- Achieving MPU security
"All existing embedded systems use the Cortex-v7M architecture." I beg to differ, Sir.
Slow down, cowboy. You're off the range.
- The end of the smartphone era: What will be the technology battlegrounds of the next decade?
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?
- On reference code
I could have written this article in a couple of sentences: Good firmware costs a lot of money. It's an inescapable fact.
- A "new" technology to watch
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.
- Those unsightly code sores
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.
- BASIC at 50
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?
- Pre-increment or post-increment in C/C++
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.
- Age Discrimination in Hiring
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.