1 / 12

Extending the Timing Definition Language with High Priority Interrupts

This research explores the extension of Timing Definition Language (TDL) used in embedded systems, addressing high-priority interrupts. We delve into the Logical Execution Time (LET) semantics of TDL and the necessity of worst-case execution time (WCET) in ensuring accurate task invocation timings. Various modes and communication strategies are discussed for deeply embedded hardware. We analyze challenges related to asynchronous tasks, timing domains, and how interrupts can be leveraged for precise execution. This aims to enhance performance in cost-sensitive embedded applications.

evette
Télécharger la présentation

Extending the Timing Definition Language with High Priority Interrupts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extending the Timing Definition Language with High Priority Interrupts Software & Systems Research Center (SRC) University of Salzburg Peter Hintenaus, Patricia Derler, Wolfgang Pree, Josef Templ Synchron 09

  2. Background • Deeply Embedded Hardware (Board Level) • Embedded Software

  3. Timing Definition Language Based on Giotto [Henzinger, Kirsch] Logical Execution Time (LET) Semantics Multiple modes WCET required terminate Logical Execution Time (LET) Logical task invocation time Physical start suspend resume stop (ET) stop (WCET)

  4. Timing Definition Language: Transparent Distribution communicationwindow communicationwindow Local execution and bus have to be synchronized! 5 ms Sender t inc inc inc inc ECU1 stop (WCET) stop (WCET) Receiver clientTask clientTask ECU2 10 ms

  5. Timing Definition Language: Asynchronous Extension Asynchronous Tasks triggered by • Interrupts • Input Port Updates No timing guaranties for asynchronous tasks Implemented using interrupt service routines a registry and lock-free synchronization Mode Start Mode End Mode Period Logical task invoc. 1 task invoc. 2 time Physical

  6. Flexray @ 1kHz Control @ 15kHz M Several Timing Domains Need to be able to specify timing domain! +

  7. Asynchronous Events I Sampling • Fixed Interval • Well behaved • Guaranties • Costly when fast reactions required Polling • Check whenever convenient • Well behaved • Cheap • No guaranties

  8. Asynchronous Events II Interrupts • Very fast reaction possible • Together with timer hardware precise and robust timing possible • Extremely hard to harness

  9. Interrupts I Precisely timed execution scheduled at the beginning of the LET of a synchronous task Mode Start Mode End Mode Period task invoc. 1 task invoc. 2 time Interrupt Interrupt • Deadline • Maximum delay?

  10. Interrupts II Event originating in another timing domain • Deadline • Minimum interarrival time

  11. Impact on Synchronous Tasks Specify • LET • Rate • Start within mode period • Jitter

  12. Open Work / Questions • Language extensions • Can this have a reasonable semantics? • Is transparent distribution possible with asynchronous networks? • Is this powerful enough for cost sensitive, deeply embedded applications? • Sample applications, e.g. make PMSM turn, both in simulation and reality

More Related