AN: Capstone Dive Computer Example - Quantum Leaps

More documents

Recommendations

Info

Application Note: Capstone Dive Computer Example www.state-machine.com 2.2 Step 2: Sequence Diagrams A good starting point in designing any event-driven system is to draw sequence diagrams for the main scenarios (main use cases) identified from the problem specification. To draw such diagrams, you need to break up your problem into active objects with the main goal of minimizing the coupling among active objects. You seek a partitioning of the problem that avoids resource sharing and requires minimal communication in terms of number and size of exchanged events. Another important consideration at this stage is deciding the ownership of resources, such as the LCD screen, the Speaker, or the LEDs. Generally, you should avoid any sharing of resources. Instead, every resource should be encapsulated inside a dedicated active object which becomes the “manager” of that resource and has exclusive access to the managed resource. All other components of the application must make requests (via events) to the respective “manager” of that resource. In case of the Capstone Dive Computer the LCD and ADC resources are assigned to the Capstone active object and the Speaker resource to the Alarm active object, respectively. The sequence diagram in Figure 4 shows the most representative event exchanges in the Capstone Dive Computer. Figure 4 The sequence diagram of the Capstone application. Copyright © Quantum Leaps, LLC. All Rights Reserved. 8 of 29
Application Note: Capstone Dive Computer Example www.state-machine.com (1) The Capstone active object starts in the “surfaced” state. (2) The Alarm active object starts in the “silent” state. (3) The system clock tick ISR posts the HEARTBEAT event to the Capstone state machine every ½ second. (4) Upon receiving the HEARTBEAT event, Capstone triggers ADC conversion to find out the ascent rate. (5) When the ADC finishes the conversion, the ADC ISR posts the ASCENT_RATE_ADC(raw) event to Capstone. The event parameter raw contains the raw, 10-bit ADC conversion value. (6) The system clock tick ISR also performs debouncing of the buttons B1 and B2 (see Figure 3). This ISR publishes event B1_DOWN when button B1 is depressed and B2_DOWN when button B2 is depressed. (7) Similarly, the system clock publishes event B1_UP when button B1 is released and B2_UP when button B2 is released. (8) Capstone ignores positive ascent rates in the “surfaced” state. However, a negative ascent rate (diving) triggers the transition to the “diving” state. (9) In the “diving” state Capstone tests for alarm conditions. If any of the alarm condition arises, the Capstone active object posts an ALARM_REQUEST(alarm_type) event to the Alarm state machine. The event parameter alarm_type conatins the enumerated type of the alarm. (10) The ALARM_REQUEST(alarm_type) event triggers transition to “playing” in the Alarm active object. (11) The Alarm active object changes the pitch of the speaker based on the TIMEOUT event produced by the system clock tick ISR. (12) When the Capstone active object determines that the alarm should be silenced, it sends the ALARM_SILENCE(alarm_type) to the Alarm active object. It is up to the Alarm active object to handle the priorities of the requested and silence alarms, as the alarms can overlap. 2.3 Step 3: Signals, Events, and Active Objects Sequence diagrams, like Figure 4, help you discover events exchanged among active objects. The choice of signals and event parameters is perhaps the most important design decision in any event-driven system. The events affect the other main application components: events and state machines of the active objects. In QP, signals are typically enumerated constants and events with parameters are structures derived from the QEvent base structure. Listing 1 shows signals and events used in the Capstone application. The sample code for the non-preemptive kernel is located in the Solutions\DiveComputer directory. NOTE: This section describes the platform-independent code of the application. This code is actually identical in both versions. #ifndef capstone_h #define capstone_h (1) enum CapstoneSignals { Copyright © Quantum Leaps, LLC. All Rights Reserved. 9 of 29
Page 1 and 2: QP state machine framework example
Page 3 and 4: 1 Introduction This Application Not
Page 5 and 6: Application Note: Capstone Dive Com
Page 9: Application Note: Capstone Dive Com
Page 19 and 20: (2) Each active object in the appli
Page 21 and 22: eturn Q_HANDLED(); } } (11) return
Page 23 and 24: (7) The memory buffer for the “sm
Page 31: Application Note: Capstone Dive Com

AN: Capstone Dive Computer Example - Quantum Leaps

Create successful ePaper yourself

Delete template?

Save as template?