OE-9.4 Embedded System Design Cycle & Software Tools

What this is and why it exists

The real idea in this unit is co-design. What runs in hardware and what runs in software is a decision made during design, not one handed to you.

That is unfamiliar to anyone coming from ordinary programming, where the hardware is a given. Here, moving a function into hardware buys speed and determinism and costs money and flexibility, and the boundary is drawn deliberately.

The practical consequence is the host and target split. You compile on one machine and run on another, which is why cross-compilation and locators exist.

The vocabulary

• Co-design — deciding the hardware and software boundary together.
• Host — the machine you develop on.
• Target — the machine the program runs on.
• Cross-compiler — a compiler producing code for a different kind of machine.
• Linker — combines compiled pieces into one program.
• Locator — assigns that program to actual addresses on the target.
• Memory map — which addresses are which memory or peripheral.
• Flashing — writing the program into the target's memory.

The mental model

Co-design asks, for each function, whether it should be circuitry or code. Hardware is fast and predictable and costs money per unit and cannot be changed after manufacture. Software is flexible and free to copy and slower and less predictable. Most systems draw the line somewhere in the middle, and the interesting part is that the line is a choice, revisited as requirements firm up.

Then the split between machines. You develop on a capable machine with a screen and a keyboard. The program runs on a device that may have neither. So the compiler on your machine must produce code for a different instruction set entirely. That is cross-compilation, and here it is the normal case rather than an exotic one.

The locator is the step with no equivalent in ordinary development, and it is worth understanding. On a desktop, the operating system decides where your program sits in memory. On a bare target there is no operating system to decide. Something has to place the code, the initialised data, the uninitialised data and the stack at actual addresses. On this device one range is flash, another is fast internal memory, another is peripheral registers. Putting the wrong thing in the wrong range does not work.

That is what a locator does, guided by a description of the target's memory map. Most puzzling early failures on a new board are located here: a program that builds cleanly and does nothing has often been placed wrongly.

Getting the software into the target is the last step, by a programming interface, a debug port, or a bootloader already running on the device. The choice matters more than it looks, because it decides whether a deployed product can be updated in the field.

What you should now be able to explain or do

State the co-design question and what each side of it costs. Explain the host and target split and why cross-compilation is normal here. Say what a locator does and why a desktop program needs no equivalent. Read a memory map and say why placement is not arbitrary. Recognise wrong placement as a likely cause of a clean build that does nothing. Say why the loading method affects field updates.

Check yourself