1 / 24

Event-Driven Programming and State Machines

Event-Driven Programming and State Machines. Here. Traditional Program Structures. Often characterized by: Input from keyboard or data file Begins, performs operations, then ends (linear program) Decisions made don’t change fundamental program structure Output to monitor or data file.

mckile
Télécharger la présentation

Event-Driven Programming and State Machines

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. Event-Driven ProgrammingandState Machines

  2. Here

  3. Traditional Program Structures

  4. Often characterized by: Input from keyboard or data file Begins, performs operations, then ends (linear program) Decisions made don’t change fundamental program structure Output to monitor or data file Traditional Program Structure

  5. often asynchronous “simultaneous” inputs & outputs sequences unknowable, re-orderable no “end” or “exit” sensors (switches, light sensors, voltages, etc.) timers user inputs (keypad, push-buttons) update a display move something switch something on or off in general  CHANGE SOMETHING PHYSICAL Programming Embedded Systems Characteristics: Inputs: Outputs:

  6. Conceptual framework An excellent method for implementing Event-driven programming & state machines Emphasizes design first Gets you to use structures that: 1) make it clear how to define the low-level functions 2) make debugging code simpler The Events and Services Framework

  7. RULE #1: Recognize that tasks break down ONLY into two fundamental classes: a. Event Detectors b. Services Events and Services Framework

  8. So, What’s an Event ?

  9. What Happens with Noise

  10. With Hysteresis

  11. CORROLARY TO RULE #1: Keep Event-Detector and Service routines as short as possible. Must implement “Non-Blocking” routines Events and Services Framework

  12. Complete program structure: Initialize hardware and software Continually test for Events Round-robin scanning “Non-blocking” code Perform Service(s) when Event detected “Non-blocking” code Repeat Events and Services Framework

  13. Description of an abstract Machine At any given time, it can only be in one of a fixed number of discrete states The next state in a progression depends on inputs and the current state Idealized, instantaneous transitions from one state to the next State Machines

  14. Useful tool for describing the behavior of Event-Driven Programming tasks. Allows you to explore the behavior of the program before you implement anything. Naturally fits with the Event-Driven Programming. State Machines

  15. Optional Pumping (Qual) Event1 Action2 Spraying State Diagram Conventions Event1 Action1 (!Qual)

  16. State Diagram Conventions

  17. None Right 1 Right Open 2 Right 3 Right Example: Smart Combination Lock Combination = 1-1-8

  18. Example: Smart Combination Lock Combination = 1-1-8

  19. SES - Software Events and Services Initialize SES by calling: SES_Init(); Event-Checking Functions prototyped with the parameter EVENT_PARAMMyEventChecker(EVENT_PARAM) return unsigned char = 0 if event not detectedreturn unsigned char  0 if event detected to pass data from the Event-Checking Function to its Service Function, use SET_SHARED_BYTE_TO(foo); or SET_SHARED_WORD_TO(foo); Data passed between functions must be static Service Function prototyped with the parameter: SERVICE_PARAMMyServiceFunction(SERVICE_PARAM) no return value to read the data passed from the Event-Checking Function, use GET_SHARED_BYTE() if it’s 8-bit data, or GET_SHARED_WORD() if it’s 16-bit data.

  20. SES - Software Events and Services Register each Event Function and Service Functions in pairs: SES_Register(MyEventChecker, MyServiceFunction); Start the process by calling SES_HandleEvents() in an infinite loop. while(1) { SES_HandleEvents(); }

  21. TIMER: 8 timers available to you (0-7) Initialize timer functionality by calling the function: TMR_Init() Initialize a timer by calling the function: TMR_InitTimer(0,TIME_INTERVAL); TIME_INTERVAL = number of timer ticks (1 tick = 4.1ms) Check to see if the timer has expired by calling: TMR_IsTimerExpired(timer number); Clear the timer flags by calling: TMR_ClearTimerExpired(timer number); Timer Library

  22. ROACHLIB: You need to initialize the functions by calling RoachInit(); Functions available for controlling the motors (see documentation for full details): LeftMtrSpeed(x); RightMtrSpeed(x); x is a number from -10 (reverse) to 10 (forward) Functions available for checking the bumpers: uchar ReadBumpers(); Function available for reading the light level: uchar LightLevel(); Roach Library

  23. Pseudo-Code (PDL)PDL = Program Design Language • Pseudo-code is written in ENGLISH • Doesn’t use the syntax of any particular programming language • It is a written, low-level exploration of an implementation of an algorithm. • It can form the first level of comments for your code

More Related