Abstract Timers and their Implementation onto the ARM Cortex-M family of MCUs Per Lindgren, Emil Fresk, Marcus Lindner and Andreas Lindner Luleå University of Technology Email:{per.lindgren, emil.fresk, marcus.lindner, andreas.lindner}@ltu.se David Pereira and Luís Miguel Pinho CISTER / INESC TEC, ISEP Email: {dmrpe,lmp}@isep.ipp.pt ABSTRACT amendable to both static and run-time verification. The Real-Time For the Masses (RTFM) is a set of languages and supporting rtfm-core compiler produces C code that com- tools being developed to facilitate embedded software devel- piled together with a RTFM run-time system renders an exe- opment and provide highly efficient implementations geared cutable. The RTFM-kernel is an architecture targeting bare to static verification. The RTFM-kernel is an architecture metal (single-core) platforms designed to provide highly ef- designed to provide highly efficient and predicable Stack Re- ficient and predicable Stack Resource Policy (SRP) based source Policy based scheduling, targeting bare metal (single- scheduling by exploiting the underlying interrupt hardware. core) platforms. However, in prior work no kernel support was given for We contribute beyond prior work by introducing a plat- asynchronous tasks with timing offsets. In this paper we form independent timer abstraction that relies on existing address this problem with the goal to provide a transparent, RTFM-kernel primitives. We develop two alternative im- abstract, and generic way of managing timer queue(s) and plementations for the ARM Cortex-M family of MCUs: a underlying hardware timer(s). Transparent w.r.t its use, i.e. generic implementation, using the ARM defined SysTick- the programmer should not need to think in terms of hard- /DWT hardware; and a target specific implementation, us- ware timers when specifying the application at hand. Ab- ing the match compare/free running timers. While sacri- stract in terms of the RTFM-kernel, (the obligation of the ficing generality, the latter is more flexible and may reduce kernel is merely to manage scheduling) thus we seek a solu- overall overhead. Invariants for correctness are presented, tion where the kernel itself is free of dependencies both to and methods to static and run-time verification are dis- timer queue implementations and timer hardware specifics. cussed. Overhead is bound and characterized. In both cases Furthermore, the solution should be generic enough to cover the critical section from release time to dispatch is less than a broad range of embedded platforms with little or no effort 2us on a 100MHz MCU. Queue and timer mechanisms are of porting. Additional requirements for robustness, perfor- directly implemented in the RTFM-core language and can mance and predictability are efficient, bound time imple- be included in system-wide scheduling analysis. mentations, complying with the task and resource model of SRP, along with invariants for correctness. In this paper we contribute beyond prior work by intro- 1. INTRODUCTION ducing a platform independent timer abstraction that relies In the mainstream of embedded programming C-code still on the existing kernel primitives. The proposed abstrac- remains the predominant means for software development. tion allows application and target specific implementations To facilitate the development a vast number of light-weight of timer queues and timer handlers. The timer handlers are operating systems are available, e.g., FreeRTOS [1], ChibiOS treated as ordinary tasks in the system, while each queue is [2], and RIOT [3] and for larger platforms, Linux/POSIX managed under protection of a critical section (resource) in based and Win32 derivates. In common, they provide a the system. thread based concurrency model, where the programmer has Requirements to support abstract timers with respect to to take the full responsibility of coordinating scheduling and analysis and code generation in the rtfm-core compiler resource management as very little support is given by the are discussed along with their performance implications. As programming models and supporting tools [4]. a proof of concept, we develop and characterize two alter- In this paper, we explore a language based approach. The native timer implementations for the ARM Cortex-M fam- reactive programming model of RTFM-core (-core in the fol- ily of MCUs: a generic (single queue/handler) implementa- lowing) provides tasks with timing constraints and critical tion using the ARM defined SysTick/DWT hardware), and a sections (treated as single-unit resources). As such -core multi-queue/handler implementation exploiting vendor spe- provides a model suitable to specify the timely behavior of cific match-compare/free running timer hardware. the embedded software, as well as a formal underpinning Our experimental results indicate that for both generic and vendor specific timers the critical section from task re- This work was partially supported by Portuguese National Funds through lease time to dispatch is less than 2us on a 100MHz MCU. FCT (Portuguese Foundation for Science and Technology) and by ERDF We show that the vendor specific timers can be exploited to (European Regional Development Fund) through COMPETE (Opera- reduce latency, total overhead and priority inversion in the tional Programme âAŸThematic˘ Factors of CompetitivenessâA˘ Z),´ within system. Furthermore, we discuss the outsets for SRP based project FCOMP-01-0124-FEDER-037281 (CISTER); and by FCT and EU analysis of programs scheduled by virtual timers under the ARTEMIS JU, within project ARTEMIS/0001/2013, JU grant nr. 621429 (EMC2) RTFM-kernel. Finally we present ongoing and future undertakings and EWiLi’15, October 8th, 2015, Amsterdam, The Netherlands. sum up the presented contributions to conclude the work. Copyright retained by the authors. 2. THE RTFM-CORE LANGUAGE Definition We introduce a mapping M from virtual timers The RTFM-core language is based on the notions of tasks VT 's to physical timers PT 's, allocated on the target hard- and resources in correspondence to the Stack Resource Pol- ware. icy (SRP) model defined in [5]. For a detailed description A physical timer is shared if M(VT ) = M(VT ); i 6= j. on the original work on -core we refer the reader to [6]. Here i j We have the two edge cases, when M is a 1-1 (complete) we give a brief overview. mapping between virtual and physical timers, and the case 2.1 RTFM-core programming model when we have a single (shared) physical timer. In -core tasks execute concurrently and run-to-completion. Definition For a physical timer PTi, we denote bw(PTi) as A task may request asynchronous execution of other tasks the bit-width and f(PTi) as the frequency of operation (in and claim (named) single-unit resource(s) for the duration Hz), ra(PTi) as the range of the timer (in seconds), derived of critical section(s) in a nested manner. Functionality is bw from 2 =f, and pr(PTi) as the precision of the timer (in expressed using ordinary C-code. In recent work [7] the seconds), given as pr = 1=f. -core language has been extended to provide messages (task execution requests with timing offsets): E.g., the range is given by 2bw(PTi)=f, e.g. a 32-bit timer async after X before Y t(:::), where X, defines the operating a 1MHz gives a range of 232=1 ∗ 106Hz = 4295s, (baseline) offset from the release time of the sender (base- with a precision of 1 ∗ 10−6s = 1us. line); Y , gives the relative deadline and t is the identifier of the task to execute. 3.2 ARM Cortex-M defined timers The Cortex-M range of MCUs share the ARM defined core 2.2 RTFM-kernel design providing a 24-bit SysTick timer and a 32-bit debug timer In short each task is implemented directly as an inter- (defined in the DWT unit). rupt handler bound to the interrupt vector. Requesting a task for execution amounts to pending the correspond- 3.2.1 SysTick timer ing interrupt, while claiming a resource for a critical sec- The SysTick timer is provided in order to generate peri- tion amounts to manipulating the interrupt hardware such odic interrupts. When enabled, it counts downwards, and to reflect the semantics of the system ceiling under SRP. when transitioning from 1 to 0 it sets a flag and (option- The RTFM-kernel encapsulate the operations required for ally) generates a SysTick interrupt. On zero, it assumes the SRP based scheduling in a minimalistic API implemented value of the RELOAD register, hence a periodic behavior can as C-code macros. Those of interest for the presentation be achieved with a minimal of programming effort. The cur- are: RTFM_pend(i), which requests execution of the cor- rent counter value (CURRENT) can be read, while a write to responding task i; RTFM_lock(c), which reads and stores CURRENT, forces CURRENT = RELOAD. The frequency of op- the old ceiling value on the stack and sets the new ceiling; eration, is determined by setting the clock source (core/ex- and finally, RTFM_unlock(c), which restores the old ceil- ternal). (Some implementations provide the option to pre- ing value from the stack. scale the core clock, e.g., /8.) The priority of the SysTick Currently the scheduling primitives have been implemented interrupt is programmable, and an interrupt can be pended for the ARM Cortex-M range of MCUs [8]. The system ceil- by setting the PENDSTSET bit in the ICSR (Interrupt Con- ing is enforced either through interrupt masking (M0/M0+), trol and State Register). The SysTick timer is stopped when or through (atomic) accesses to the NVIC BASEPRI register the processor is halted during debug. (M3 and above). 3.2.2 Debug timer 2.3 RTFM-core compiler The debug unit (DWT) provides a 32-bit, free running The rtfm-core compiler analyses the declarative (static) cycle count register (DWT_CYCCNT).