Understanding MCU Timing

What Actually Happens Inside That Chip?

- By Stuart Ball

What happens between your source code and the low-level machine code in your MCU is not usually obvious. In this article, Stuart investigates that disconnect.

Most of the time when we work with an MCU, we design the hardware, write and debug the software, and then we're done. Long ago, when I started out in this industry, it wasn't uncommon to use assembly language. I wrote assembly code for both MCU and DSP designs. But it didn't take long for languages like C and C++ to replace assembly. Higher level languages provide a lot of benefits: type checking, memory management, simpler code, code that's easier to maintain, and at least some abstraction from the underlying hardware. There are C and C++ compilers for most MCUs, both free tools from the manufacturers and commercially available tools. But one thing you give up with a higher-level language is a connection between the source code and the related timing.

When I was in college, many years ago, I took about every programming course available, including COBOL (that tells you how far back that was, assuming you're old enough to even know what COBOL was). We were programming on an IBM 360 mainframe computer, and I discovered there was a compiler switch that would show you the underlying assembly code generated by the compiler. The printout (no interactive terminals, at least not for this class) would show you the line of COBOL code and then the underlying assembler statements. COBOL provides a high level of abstraction, so a single COBOL statement can produce many lines of assembly code. I turned in an assignment that way; what would have been a single page of COBOL statements was many pages of assembly code. The grader gave me 100 on the assignment but added a note: “Don’t ever do this again.” At that age, I thought it was humorous. The grader obviously did not.