> A ~47 year run for a single Micro.  Do any others do longer?

With the Z80 originally introduced in 1976, the obvious comparison is to its direct contemporary, the 6502 - which was first introduced the previous year, in 1975.  In many ways, the 6502 was to the Motorola 6800 family what the Z80 was to the Intel 8080 family.

The first year's 6502 production run lacked a working ROR instruction, which was added to the 1976 model, but software workarounds for the lack of this instruction continued to be included (often as optional patches) in commercial and hobbyist software for some time afterwards, to cater to early adopters who were still using the 1975 model - which would have included owners of the Apple I.

The 6502 remains in production today.  Like the Z80, it has long since moved to a CMOS manufacturing process and acquired a variety of backward-compatible enhancements.  The current model is the W65C02S, manufactured on TSMC's .6µm CMOS process.  Officially specified to run at 14MHz, it is often found by hobbyists to be capable of considerably more - or alternatively, it is a fully-static design which can be run at very low speeds and reduced supply voltages if desired.  It is possible to detect the execution of a "stop" instruction and gate off the clock signal for extra power savings.

Rumour has it that the 6502 remains a reasonably popular microprocessor for embedded applications that don't need a lot of computational horsepower, though often as a "hard core" rather than a discrete silicon product.  For such applications, the W65C02S is useful for technical evaluation and prototyping.  Very little external glue logic is required to interface to a JEDEC-standard SRAM and EEPROM; in extreme cases this can be reduced to a single 74HC00 device!

Regarding the Z80 you said in the Embedded Muse 490: "A ~47 year run for a single Micro. Do any others do longer?"

I know you are not counting parts that cannot be bought new today when comparing the Z80's ~47 year longevity. But it is interesting (to me anyway) what the first microprocessor was: "The first chips that could be considered microprocessors were designed and manufactured in the late 1960s and early 1970s, including the MP944 used in the F-14's Central Air Data Computer.[1] Intel's 4004 of 1971 is widely regarded as the first commercial microprocessor.[2]"[3]

Also you said: "Bob found that an open-source version of the Z80 is coming out: https://www.eenewseurope.com/en/open-source-z80-to-replace-end-of-line-chip/"

It should be noted that the Z80 has been available as an Open-Source FPGA Core since Dec 12, 2014, almost ten years ago.[4]

* References:

1. Laws, David (2018-09-20). "Who Invented the Microprocessor?". Computer History Museum. Retrieved 2024-01-19.

https://computerhistory.org/blog/who-invented-the-microprocessor/

2. Augarten, Stan (1983). The Most Widely Used Computer on a Chip: The TMS1000 (Texas Instrument). New Haven and New York: Ticknor & Fields. ISBN 978-0-89919-195-9. Retrieved 2009-12-23.

https://americanhistory.si.edu/smithsonian-chips

3. Microprocessor Chronology

https://en.wikipedia.org/wiki/Microprocessor_chronology

4. A-Z80 CPU, Open-Source FPGA Core in Verilog, License: LGPL

https://opencores.org/projects/a-z80

Recently, we've come into new corporate leadership in a large company. The new head of engineering has concluded, based on meetings with all engineering groups (mechanical, electrical, software, PM, manufacturing, etc.) that the software team is essentially the root of all evil in the company. Software is the reason that projects are delayed and run past schedule, and we "need to fix it". Now, we know that software/firmware is the bottom of the engineering pit here. Last to get requirements, but also first in line to catch all the blame. My question for the group here is, how common is this perception, and what have you done to combat this?

I think it's pretty clear to you why code instrumentation is important. After an unsuccessful search for a code instrumentation solution suitable for hard-real-time control systems a few years ago, I started collecting ideas, experimenting and then developing a suitable solution in my spare time. It was a challenge for me to see how optimal a solution could be. It was only recently that it was ready for release and is now available on Github.

This new solution is useful in general, not just for the purposes for which I originally designed it. It is my contribution to the open source community.

The new toolkit is suitable for both large RTOS-based systems and small, resource-constrained systems. The toolkit is not a replacement for existing event-oriented solutions such as  Segger SystemView or Tracealyzer, as it is based on a different concept. It provides minimally intrusive data logging and flexible data decoding. The code is optimized for 32-bit devices and executes very fast with very low stack usage. For example, only about 35 CPU cycles and 4 bytes of stack are required to log a simple event on a device with a Cortex-M4 core. Nearly 200 CPU cycles and a maximum of about 150 to 510 bytes of stack (depends on logging mode and options) are required to log an event with some other tools.

The solution is essentially a reentrant timestamped fprintf() function running on the host instead of the embedded system. There is no data encoding and no printf-style functions/strings in the embedded system. The memory footprint of the logging library is only 1 kB when all functions are used. The small number of logging functions (they are differentiated only by data size, not by data type) and the familiar printf syntax make the solution easy to use and learn. Any data type can be logged and printed (decoded on the host), including structures and bitfields. Print output can be redirected to any number of custom files, such as CSV or event log files. This allows the use of existing log and event viewers and graphing tools. The solution is ready to use for devices with an ARM Cortex-M core. Any debug probe, communication channel, or media can be used to transfer data to the host.

Custom triggers, flexible on-the-fly filtering, and sorting of data into custom files during decoding help manage the flood of data from the embedded system. Built-in statistics allow quick identification of data and time extremes. The toolkit is ideal for reverse engineering poorly documented code and analyzing complex, difficult-to-reproduce problems. Its low stack requirements virtually eliminate the possibility of stack overflows when instrumenting code.

The new toolkit is intended for developers of various embedded systems from real-time control to IoT. See the RTEdbg toolkit presentation or go to github.com/RTEdbg/RTEdbg The toolkit distribution file includes library, documentation, demo code for ARM Cortex-M, and setup for Keil MDK, IAR EWARM, MCUXpresso, and STM32CubeIDE. Comments on the new solution and documentation are welcome.