Understand development process clearly help you easier to adapt to various kinds of microprocessors and embedded software programming.
1. Software development flow
Below image show the common step when working with any IDE from create new project step till flash output image into your board and run.
- Create project:
- use IDE to create new project
- specify the location of source files, compile target, memory configurations, compilation options …
- Add files to projects:
- Specify the path of any included header files
- Create new source files and write program
- Reuse files from device-driver library to reduce effort in writing new file: startup code, header files, peripheral control functions
- Setup project options:
- choose compiler and compiler optimization options
- configure memory map
- choose output file type
- config debug adapter option
- Compile and link:
- source files will be compiled separately then output corresponding object file
- a separate linking process is required to generate the final combined executable image
- IDE generates the program image in other format depend on devices requirement
- Flash programming:
- use debug adaptor to download created program image into flash
- debug adaptor can also be replace by built in one in board
- Execute program and debug:
- run program and see if it work on devices
- use debug environment in the IDE to stop the processor and check the status of system
Each step will be show in detail when we work with Keil ARM IDE and STM32F411 Board Discovery Programming.
2. Application compiling
Depend on the development tools you use, the procedure for compiling an embedded program can be different.
2.1. ARM toolchains
| Tools | Descriptions |
| C compiler | To compile C program files into object files |
| Assembler | To assemble assembly code files into object files |
| Linker | A tool to join multiple object files together and define memory configuration |
| Flash programmer | A tool to program the compiled program image to the flash memory of the microcontroller |
| Debugger | A tool to control the operation of the microcontroller and to access internal operation information so that status of the system can be examined and the program operation can be checked |
| Simulator | A tool to allow the program execution to be simulated without real hardware |
| Other utilities | Various tools, for example, file converters to convert the compiled files into various format |
2.2. GNU gcc toolchains
You can see GNU gcc toolchain is similar to ARM toolchain. However when using it, the whole application is compiled in one go instead of separating the compilation and linking stages.
3. Program flow construction
Below are same of the typical ways used to construct program flow for an application
3.1. Polling
In very simple applications, you can see a super loop runs and wait till data is ready for process, then process it, and then wait again.
However a microcontroller usually have to serve multiple interface and therefore it needs to support multiple process. Then you can see the expanded version of simple polling program to support multiple processes.
Polling method works well for very simple task, but you can also guest some of its disadvantages:
- the supper-loop become very complex, it makes the maintenance become difficult
- responsiveness of important task is very bad because the processors is running or waiting data of other processes
- waste energy during the polling when the service is not required
3.2. Interrupt driven
Interrupt driven method is used to resole problems of polling.
In this kind of application, microprocess is set into sleep mode first to reduce power. When a peripheral interruption occur, microprocessor will wake up and run corresponding interrupt service routine.
To make sure important task will be run first, interrupts from different peripherals can be assigned with different interrupt priority levels. Then when an important interrupt arrives at the time processor servicing a lower priority interrupt, the lower priority service routine will be suspended, instead of it the important task will be run and provide better responsiveness.
We can classify data from peripheral services into two parts: important part need to be done quickly and the less important one can be carried out later. Base on it, the improved version of interrupt driven can be us as a mixture of interrupt driven and polling method.
When a peripheral requires service, it triggers an interrupt request. Once the first part of the interrupt service is carried out, it updates some software variables so that the second part of the service can be executed in the polling based application code.
This method helps you to resolve interrupt driven applications problem that the high-priority interrupt handlers takes too long duration. At the same time, the processor can still enter sleep mode to save power when no servicing is needed.
3.3. Multi-tasking system
Polling combines to interrupt driven method is good, however it is not good enough when the applications get more complex.
When some ISR(Interrupt Service Routine) have same priority, or the time to process high priority ISR is too long, other ISRs don’t have time to execute then the result is still bad responsiveness.
Now these long tasks have to be processed concurrently. And the step to resolve this problem:
- dividing the processor’s time into a number of time slots
- allocate the time slots to these task
By this way, every task can be execute on time without depending on the length of length task anymore. We can manually partitioning the tasks and building a simple schedule to handle this, but it will consume a lot of time and make project harder to maintain.
The RTOS (Real-Time Operating System) was born to make this work more effective. Instead of arrange the task by manually, RTOS will make it automatically for you by providing the OS task scheduler.
Finally the result is all tasks work almost independently and the responsiveness it very good.
5. Conclusion
I hope now you can have a overall look about a microcontroller software project and its process step. In next step, we will go closer into real project implementation.
See you soon.
6. Reference
The content in this post is triggered from The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors.
Thanks author Joseph Yiu very much for a great book.
