Developing software directly on Cortex-M1 hardware without using an operating system (bare metal) provides maximum performance and optimization opportunities but also comes with challenges. Careful planning is required to properly structure and architect the software.
Benefits of Bare Metal Cortex-M1 Development
The main benefits of developing software directly on Cortex-M1 hardware without an OS include:
- Maximized performance – no OS overhead
- Minimized memory usage – no OS code and data structures
- Full control over the hardware
- Deterministic real-time behavior
- Optimized for specific application requirements
- Easier certification for safety-critical applications
The lack of an OS provides low-level access to the Cortex-M1 hardware with no abstraction layer. This allows performance critical and timing sensitive applications to run predictably with bare minimum overhead.
Challenges of Bare Metal Cortex-M1 Programming
However, directly accessing the hardware comes with some key challenges:
- No hardware abstraction – the developer must have intimate knowledge of the target device
- Lack of driver libraries for peripherals
- No system calls for common functions like I/O
- Manual memory management required
- Concurrency and task scheduling has to be hand coded
- Higher software testing and debugging effort
So increased optimization comes at the cost of higher complexity in software architecture and implementation.
Software Architecture Considerations
Carefully designing the architecture of a bare metal Cortex-M1 application is key to managing complexity.
Main Program Loop
The simplest approach is to structure the entire program as one infinite loop. This loop checks for events and calls handler functions as needed. With this model, the hardware timer is configured to trigger an interrupt periodically to act as the tick for the main loop. This technique works well for simple applications.
Cooperative Multitasking
For more complex programs, a cooperative multitasking model can be implemented on top of the main event loop. Application tasks yield back to the main loop when they don’t have work to do. The loop schedules tasks in a priority-based cooperative manner. Task switching only occurs at well-defined points. This enables deterministic real-time behavior.
Pre-emptive Multitasking
An optional advanced technique is to implement pre-emptive multitasking. This allows the current running task to be interrupted immediately on a high priority event, forcing a context switch. While more complex, it provides the strongest real-time capabilities.
Interrupt Handlers
Hardware interrupts are serviced by dedicate interrupt service routine (ISR) functions. These should run as fast as possible. Any substantial processing should be deferred and handled in the main loop after the ISR exits.
Resource Sharing
Shared hardware resources like device peripherals need structured access mechanisms like mutexes to avoid race conditions. The exact implementation will depend on if a cooperative, pre-emptive, or hybrid multitasking model is used.
Managing Memory
Without an OS, memory management shifts fully to the application developer. Areas commonly requiring planning:
- Static allocation – Global variables and constants need placement in specific memory regions like RAM or ROM.
- Stack – Each thread or ISR needs a pre-allocated stack.
- Heap – For dynamic allocation, heap structures like linked lists can be built.
Knowing the memory map of the Cortex-M1 device and planning allocations accordingly is important.
Peripheral Access
Interfacing with on-chip peripherals like GPIO, timers, communication buses, ADC, etc requires direct manipulation of the peripheral’s registers in code. Any drivers or libraries for the peripherals must be included in the application itself.
Vendors usually provide C libraries or HALs (Hardware Abstraction Layers) to simplify peripheral access by providing APIs that hide the device register details. These should be leveraged during development.
Boot Sequence
A Cortex-M1 device will load code from a defined boot memory address on power up. Vector table, system initialization C code, and main application entry point need to be linked to bootstrap the system.
A debugger is necessary to download the program binary image onto the device initially. Once loaded, an on-chip bootloader can optionally support over the air updates.
Debugging and Validation
Debugging bare metal Cortex-M1 software requires using a supported hardware debugger like JTAG. Integration with IDEs like Eclipse, Visual Studio, and SEGGER Ozone is common.
Unit testing frameworks can help exercise modules during development. For system validation, techniques like simulation, profiling, and static analysis should be employed to verify requirements before deployment.
RTOS Integration
Once bare metal Cortex-M1 software is working, integration of a real-time operating system (RTOS) is possible. The RTOS introduces modularity and concurrency while still ensuring deterministic real-time operation. FreeRTOS is a popular open source option.
With careful planning, bare metal Cortex-M1 development allows creation of highly efficient software tailored exactly to application needs. While more complex than using an OS, the control and performance gains open many possibilities.
