Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 480, December 18, 2023
Copyright 2023 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

Editor's Notes

SEGGER embOS Ultra Cycle-resolution accurate RTOS

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded" in the subject line your email will wend its weighty way to me.

Quotes and Thoughts

“The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts.” -Bertrand Russell

Tools and Tips

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

EDN has a nice article on using an oscilloscope's bandwidth filters in troubleshooting circuits.

Engineering Everything

Dan was old. Must have been 70, it seemed to the 22 year old me. Grizzled and garrulous, Dan was a chemical engineer who made a bundle designing a plant in Ankura, Turkey. He had retired onto a 35’ aluminum sailboat and held court in his cabin in Annapolis over beers many an evening. He became a good friend.

Turns out, Dan was 39 at the time. Ah, youth, thy eye sees vast age in any face tarnished by the ravages of just a few years!

Sailboats, especially the ancient one I had at the time, have all kinds of problems. Gear is constantly failing, water comes in from below and above, and one is always modifying something on the vessel.

Many a time we’d talk about a specific problem one of us faced. Dan's response was always that of an engineer, first, sailor, second. "Sure, the clevis pin failed. You could replace it, I guess. But the more interesting issue is why did it fail? What can you change so that never happens again?"

He had a rouges' gallery of broken components that he'd pull out and demonstrate. "Chafe. Even a half-inch bronze shackle will wear away if not protected. How do you think the Colorado River formed the Grand Canyon?"

Dan taught me a lot about long distance sailing. But there’s one lesson he imparted that, almost fifty years later, still shapes the way I think about most things: approach every problem and issue with an engineering perspective. Yes, I’m an EE, but that does not limit me to pushing electrons around. In school we studied statics and dynamics, which I never use in my work. But understanding loads and how things move has helped solve innumerable problems around the boat, the house, and pretty much everywhere else.

We took a big tree down not long ago. It was leaning towards an obstruction, so had to be felled "uphill." A little trig, some analysis, and in a few minutes we had rigged a nylon line between it and another hickory with a come-along putting great tension on the rather elastic nylon. Then we hung 150 pounds of water jugs from the middle of the line using a chain hoist. The load is proportional to the tangent of the angle of the line, so as the tree starts to fall is huge.

The tree came down within inches of plan. Even in logging our engineering sense and intuition comes into play.

A friend - and an engineer - has a damp basement, though there's no standing water. He didn't shop for a dehumidifier blindly. Instead he computed how much water the air in that space could hold at its usual temperature and relative humidity, and picked a unit that could remove more than that in 24 hours. Analysis leads to insight.

When the scoundrels in DC make some promise, we engineers need to hold their numbers up to scrutiny. $1T for that fighter program? Amortized over how many units? How does that compare to, say, F-16s... or a few million drones?

Alas, it seems too many Americans don't know the difference between a million and a billion, and the notion of 10**12 completely evades them. We need to educate them at the party when some bore completely confuses M, B and T.

I have learned, though, to try (though it’s so hard!) to be less analytical in relationships. Sometimes my wife has a problem, but needs a sympathetic ear, not a calculator, #2 Ticonderoga, and graph paper.

I don’t know if engineers are born or made. But there's no doubt that the engineering mindset reshapes our lives, much more so than most professions.

Embedded ChatGPT

I asked ChatGPT to write an article for the embedded muse. It produced this:

Title: The Evolving Landscape of Embedded Systems: Navigating Challenges and Embracing Opportunities

Embedded systems, the silent engines powering an increasingly interconnected world, are undergoing a transformative journey. As technology advances, the demands on embedded systems continue to escalate, presenting both challenges and exciting prospects for developers and engineers. In this article, we explore the evolving landscape of embedded systems, highlighting key trends, challenges, and opportunities.

**1. The Rise of Internet of Things (IoT): The integration of embedded systems with IoT has become a defining trend. From smart homes to industrial automation, embedded systems play a pivotal role in creating a seamless and interconnected network of devices. This connectivity, however, brings forth challenges related to security, interoperability, and the sheer volume of data generated.

**2. Edge Computing and Real-time Processing: As applications demand quicker response times and reduced latency, the significance of edge computing in embedded systems cannot be overstated. Real-time processing capabilities are essential for applications like autonomous vehicles, robotics, and critical infrastructure. Balancing computational power and energy efficiency remains a constant challenge.

**3. Open Source and Collaboration: The open-source movement is gaining momentum in the embedded systems realm. Collaborative efforts enable developers to leverage shared knowledge, accelerating innovation. However, navigating diverse ecosystems and ensuring compatibility across platforms can be a complex task.

**4. Machine Learning at the Edge: Machine learning algorithms are increasingly finding their way into embedded systems, enabling them to make intelligent decisions locally. This trend enhances the autonomy of devices but introduces challenges related to power consumption, hardware constraints, and algorithm optimization.

**5. Security Concerns: With the proliferation of connected devices, security has become a paramount concern. Protecting embedded systems from cyber threats, ensuring secure communication, and implementing robust authentication mechanisms are critical aspects that demand constant attention.

**6. Energy Efficiency and Sustainability: Embedded systems are prevalent in battery-powered devices, making energy efficiency a focal point. Striking a balance between performance and power consumption is crucial, especially in applications like wearable devices and IoT sensors.

**7. Rapid Prototyping and Development: The need for agility in development cycles has led to the rise of rapid prototyping tools and platforms. Developers can quickly iterate and test their ideas, but the challenge lies in seamlessly transitioning from prototyping to production-ready systems.

**8. Human-Machine Interaction: Enhanced user experiences and natural interfaces are driving innovations in human-machine interaction. Touchscreens, voice recognition, and gesture control are becoming integral parts of embedded systems, necessitating a multidisciplinary approach that incorporates user experience design.

Conclusion: Embedded systems continue to be at the forefront of technological innovation, shaping the way we interact with and perceive the world. Navigating the challenges presented by connectivity, security, and efficiency requires a holistic approach that combines technical prowess with adaptability. As the embedded landscape evolves, embracing collaboration, staying informed about emerging technologies, and fostering a commitment to sustainable practices will be key to success in this dynamic field. The embedded muse continues to inspire, pushing the boundaries of what is possible in the realm of embedded systems.

Pretty much meaningless pablum. So I asked for a number of different sorts of articles. All came back with exactly the same format, using bulleted points, a conclusion, etc. Not impressive.

I purposely gave it a very vague spec for some code, requesting it to "Write C code to read an a/d, smooth the data, and output it on a gpio". This was the output:

Not bad, actually. Much better than I expected. So a week later I posed the exact same query and got a much different response:

Sequence Points, Redux

After last issue's take on sequence points, a number of readers replied that the first example given is actually fine. Charles Manning responded:

You ask:
a =  ++b + ++c;

What does it do?

I know exactly what happens.

You get fired.

In pre-optimiser days there was a benefit in mixing pre and post increment with other code. For example the classic strcpy was:

 while (*dst++ = *src++);

or whatever.

These days there is absolutely zero advantage doing the above over while (*dest = *str) {

Though note that these are not 100% interchangeable since the points won't be in the same place when the loop quits.

Another was preferring pre-increment over post increment because some early compilers on some processors generated faster code. These days that does not happen with optimising compilers. Where the difference does not matter ie. free standing ++a or a++, gcc will generate the same code).

C has numerous interesting things. The best way to avoid them is to stay the hell away from any of these constructs.

My personal favourite is the way array dereferencing works.
By convention we always use array[index], but you can equally use index[array].

For example
int array[10];
for(i = 0; i < 10; i++)
i[array] = 5;    // that's the same as array[i] = 5;

equally you can do very weird stuff with strings (which are just pointers and thus a stand in for an array)

"abcdef"[3]; // gives value  d
2["abcdef']; // gives value c

Yes you CAN do that, but please don't!

C is a tool. Proper usage is required. You can cause a lot of damage if you do dumb things with a screwdriver.

The very worst aspects of C were cleaned up a long time ago when ANSI C was introduced in the 1980s.  Nobody should still be using K&R C.

In another email Charles noted:

C treats x[i] the same as *(x + i).  (x + i) is the same as (i + x), hence *(x + i) is the same as *(i + x).
So long as (x + i) resolves to a pointer we get the thumbs up from C.

Of course anyone writing i[array] should be immediately shown to the unemployment line.

Failure of the Week

Ricardo de Almeida sent this:

And this is from Tom Kunz:

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.


Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.


Joke For The Week

These jokes are archived here.

Programmer: A red-eyed, mumbling mammal capable of conversing with inanimate objects.

About The Embedded Muse

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.