Generic Embedded Development Environment Overview

The goal of an Embedded System Development Environment is to enable a developer to create the application firmware for a Microcontroller Control Unit (MCU) based hardware design. Application development consists of five steps:

  • Coding - writing the application in a humanly readable form
  • Building - converting the humanly readable code to a machine-readable code
  • Simulation - verifying the application will work before it is programmed into an MCU
  • Programming - placing the machine-readable code into the MCU's non-volatile program memory
  • Debugging - identifying and removing any unforeseen anomalies in operation after the application has been programmed into the MCU
dev-system.png

The primary component of a contemporary development system is a software package called an Integrated Development Environment (IDE). IDEs provide a user interface for the application developer to coordinate the development activities. Depending on the developer's needs, the IDE may communicate with other software packages called compilers and hardware devices called programmer/debuggers.

Coding

Applications are developed by writing code using languages such as C or assembly. The code is placed in text files, called source files, on the developer's computer. An embedded application typically consists of multiple source files. The content and format of the source files are determined by the language being used.

In order to enable efficient development, IDEs include a text editor and the ability to create and manage multiple source files.

Building

Once the source files have been written, they need to be converted to a form which is readable by the MCU. The process of converting source files to a format which can be read by an MCU is called building. A build is a two-step process:

  1. Each application source file is converted to a machine-readable file called an object file.
  2. The object files are then linked together, forming a single application file which can be programmed into the MCU.

Building is performed by a software tool called a compiler. IDEs offer a user interface, allowing the developer to start the build process by invoking the compiler.

Simulation

Improperly written applications can cause damage to the external hardware or the circuity of a development board. Many developers wish to determine if their application is functioning properly before they program it into an MCU. The process of verifying an application's operation before it is programmed is called software simulation.

Software simulation is a feature offered by the IDE. After a project is built, and before it is programmed into the MCU, the developer can run an interactive software simulation of the code.

NOT all IDEs provide software simulation.

Programming

Placing a built application file into an MCU's program memory requires the use of a hardware device called a programmer ( or programmer/debugger). A programmer typically connects to the developer's computer through USB and to the MCU through the MCU's specified I/O pins. After a build has been completed, using the IDE, the developer initiates the programming of the built application file into the MCU.

Debugging

Sometimes, after an application has been coded, built, and programmed into an MCU, it performs differently than the developer expects. To identify and correct the causes of these anomalies, the developer will need to "see" what the MCU sees as it executes the application code. The process of controlling an MCU's operation and observing its performance is called debugging (or hardware debugging).

Debugging is performed through the IDE and requires the device programmer to have a set of enhanced capabilities. The programmer must have the ability to pass control signals from the IDE to the MCU and return data from the MCU to the IDE. Enhanced programmers are referred to as programmer/debuggers.

© 2018 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.