Bringing resource efficient real-time programming to the masses Per Lindgren Professor Embedded Systems
Why Focus on Software • 40 billion devices in 2020 (Artemis) • Their functionality is to a large extent defined by their embedded software. • More versions of software than hardware ( many different applications can be run on the same platform, we want flexibility ) • More versions of hardware than software ( we want compatibility over different platforms, we want code re-use )
Why Focus on Software • Embedded programming is different from general purpose programming. – Lots of interaction with the environment (HW) – (Hard) timing constraints – Resource limitations • Memory • Power – Requirements • Safety (error containment, etc.)
Huge efforts are spent • Fact 1, Often dominating cost for development of ES • Fact 2, C is the dominating programming language • Fact 3, (Real-Time) Operating Systems offer (some) help – Thread OS model not necessary the right abstraction • Definitely not corresponding to HW intuition – Still hard to verify (lots of testing) – Analysis is not available to the masses, e.g., • NEAVA (Ericsson/Huawei, low level programming … no analysis) • Abelko, Microbit, Optronic, D- Flow, … no analysis • …. Just testing testing testing testing • It’s not because our companies are bad, why then … we’ll come to this
(Real-Time) Operating System • For resource constained systems FreeRTOS, TinyOS, Contiki, etc. Offer infrastructure, like a road with traffic lights, road signs, and police… however – Manual coding is chosen when: • OS not needed/too complicated/wrong abstraction • Too high overhead – Other approaches required • Guarantees/proofs are required
Formal methods (analysis) • Typically requires expert knowledge • Non-standard programming models – Synchronuous languages (Esterel) – Time triggered models (Giotto) – etc. far from industrial C background • Difficult/Expensive/Time consuming not available to the masses
RTFM: Real Time For the Masses • Simple reactive system model • Simple C-programming API – Static jobs (interrupts), resources (critical sections) • Simple Scheduler – Uses the interrupt hardware efficiently • Simple Analysis Possible – Derives configuration for the scheduler – Compile time stack/heap memory analysis – Schedulablity test, (response time analysis)
RTFM: Step 1, past • SIES 2013 Real-Time For the Masses: Step 1. Programming API and Static Priority SRP Kernel Primitives – Motivation – Related work – Roadmap – Task model (theoretical underpinning) – Programmer’s API – Kernel implementation (zero/constant overhead can be obtained) – Kernel configuration and tool for basic analysis – Evaluation (comparison to FreeRTOS faster by magnitues) & future work SUB MICRO SECOND RESPONSE TIME ALLOWS REAL-TIME APPLICATIONS TO RUN AT MHz SPEED IN SOFTWARE
RTFM: Step2, present • Adding Virtual Interrupts – Constant time mechanism for virtual interrupts (used in cases the application specifies larger number of tasks then the number of (free) interrupt sources provided by the underlying HW) • Adding queues to RTFM – Tasks invoked by parameters (can be seen as messages) – Hugely facilitates programming – We have a highly efficient, constant time mechanism • In place access for both sender and receiver – Extending memory analysis to cope with messages • Queue lengths are determined at compile time – An important step towards supporting TinyTimber (CRO model)
RTFM: Step 3, future • Adding timing constraints to tasks – Facilitates development of real-time systems – A direct match to the notion of time underlying Timber/CRO • Use as infrastructure for executing TinyTimber programs – Mapping of TinyTimber API to RTFM • Make use of the time constrained tasks with parameters • Make use of analysis (memory/schedulability etc.) • RTFM language – An imperative language that combines the notion of concurrent reactive objects (CRO) with a sub-set of C – Make a CRO->TinyTimber compiler (executed by RTFM) – Facilitate programming, preserve efficiency, easy to analyse
RTFM: Current & Future work/Activites • It is already useful (ARM Cortex M0/M3 supported, i.e. the next gen Freescale-MULLE). Available now. • Works directly within LPCXpresso toolchain (Phillips ARM division) List of contributors (so far…) • Per Lindgren • Johan Eriksson • Simon Aittamaa • Andrey Kruglyak • Fredrik Häggström • (Henrik Mäkitaavola, future?) • your name here…
RTFM: Current & Future work/Activites • Get you people that develop low level code involved. • We can support you get going. – You get real time performance, and analysis – We get use cases • What we need to do is to set up a RTFM site (LTU hosted?) – Scope/motivation, roadmap, status – Wiki for developers and users – Git/Svn for code base and examples
RTFM & Related activities • Projects at EISLAB concerning embedded software – SVK (Modeling/Simulation) – EMC2 (Arcticus effort 500 kEuro, LTU will match) – ESIS 2.5 D-FLOW/Neava (verification) – Arrowhead/SKF (supporting software) • (Dependable) Communication and computation systems • Control Systems • Mobile Systems I.E., embedded software is the backbone/infrastructure
RTFM: So what is it? Inputs Outputs
RTFM: So what is it? Inputs Outputs Sensors Actuators Reacts to Ethernet external and Zigbee Zigbee Ethernet internal events CAN BUS CAN BUS Wireless 802.4 Wireless 802.4
Externally triggered tasks Inputs Outputs Res A Res B Res C
Resources might be shared e.g., Resource B Inputs Outputs Res B
Tasks, internally triggered Inputs Outputs
Tasks, internally triggered, periodic Inputs Outputs Reset (one-shot) After 10 us
RTFM: API (Super Simple!!!!!)
RTFM: Binding to environment
RTFM: Binding to environment Inputs Outputs
RTFM: Task description C-code
RTFM: Task description C-code Inputs Outputs
RTFM: Shared resource
RTFM: Shared resource Inputs Outputs
RTFM: Internally triggered task
RTFM: Internally triggered task Inputs Outputs
RTFM: Internal task with shared resource
RTFM: Internal task with shared resource Inputs Outputs
Tasks, internally triggered, with timing constraints (after, before) Step 3 Inputs Outputs
RTFM: Kernel (Super Simple!!!!!)
Scheduling by interrupt HW
RTFM: Resource protection
4 byte OH per LOCK
Single instruction OH, for LOCK/UNLOCK
Enforcing consistency (required by HW)
Single instruction job request
Evaluation Unbeatable performance, even by manual coding!!! Cycles => Time, Cycles => Power, Memory => Size, Mem => Cost, Mem => Power
RTFM: Real Time For the Masses, it’s here!!! And Real-Time Comes for Free • Builds of the Bulk of Theoretical Results from Academia • Stack Resource Policy • Draws on complete understanding of the Hardware • Simple C-Code API • GCC compatible, i.e., works inside industrial Tool Chains • Comes with Safe Schedulabilty (Response Time Analysis) • Comes with Safe Stack-depth analysis • Future work • Messages with payloads, Timers, etc. as discussed • Exploit Low-Power potential. • Additional analysis (offset based, etc. tighter results) • Mapping from TinyOS/TinyTimber/REKO/Rubus
Thank you for listening now RTFM!
Recommend
More recommend
