Προγραμματίζοντας με μηχανές καταστάσεων-State Machines 1

State Machines • Η τυπική θεμελίωση των μηχανών καταστάσεων βασίζεται συνήθως στην unified modeling language (UML) • Μηχανή Πεπερασμένων Καταστάσεων (Finite State Machine –FSM): Μια FSM αναπαριστά τoυς διάφορους τρόπους modes λειτουργίας του συστήματος με καταστάσεις (states) και τις εναλλαγές μεταξύ αυτών με μεταβάσεις (transitions), που αποτελούν και τα βασικά δομικά στοιχεία της. 2

Προσδιορισμός απαιτήσεων συστήματος • Ανάλυση – εστιάζει στις απαιτήσεις του συστήματος – τι θέλουμε να κάνει το σύστημα? – Καθορισμός απαιτήσεων (Requirements Determination): Πώς πρέπει να λειτουργεί το σύστημα και τι περιορισμοί υπάρχουν στην συμπεριφορά του ή στην ανάπτυξη του συστήματος? – Περιλαμβάνει διαπραγμάτευση με τους χρήστες. Είναι απαραίτητο στάδιο για να αποφευχθούν αντιμαχόμενες και επικαλυπτόμενες απαιτήσεις, και για να υπάρχει συμφωνία με την διάρκεια και τον προϋπολογισμό του project. Αποτέλεσμα αυτής της φάσης είναι ένα “requirements document” «αρχείο απαιτήσεων» – Requirements specification Καθορισμός απαιτήσεων: Αρχίζει όταν οι προγραμματιστές αρχίζουν να μοντελοποιούν τις απαιτήσεις χρησιμοποιώντας μια συγκεκριμένη μέθοδο (όπως UML). Έτσι το “requirements document” εμπλουτίζεται με γραφικά μοντέλα και προκύπτει το «specifications document” «αρχείο προδιαγραφών». Οι πιο σημαντικές specification τεχνικές στην αντικειμενοστραφή ανάλυση είναι τα class diagrams και τα use case diagrams. Είναι τεχνικές για specifications δεδομένων και λειτουργιών. • Σχεδιασμός – πώς θα υλοποιήσουμε (με την υπάρχουσα τεχνολογία) αυτό που πρέπει να κάνει το σύστημα? – Architectural Design (Σχεδιασμός Συστήματος): γίνεται σχεδιασμός σε σχέση με την hardware/software πλατφόρμα πάνω στην οποία θα χτιστεί το σύστημα. Περιγράφει το προϊόν ως προς τα modules. – Detailed design (Λεπτομερειακός Σχεδιασμός): περιγράφει κάθε module 3

Εισαγωγή στις Μηχανές καταστάσεων Introduction to State Machines (Davies p. 358) • Παράδειγμα απαριθμητή 2 bit – Πίνακας καταστάσεων μετάβασης (state transition table) present state-next state 4

Προγραμματίζοντας με μηχανές καταστάσεων • Οι καταστάσεις-states αναπαρίστανται με κύκλους (και στο εσωτερικό έχουμε την τιμή της μεταβλητής κατάστασης-state variable του συστήματος) • Τα βέλη δείχνουν τις μεταβάσεις ανάμεσα σε καταστάσεις με κάθε κύκλο ρολογιού. • Οι ετικέτες (labels) δείχνουν την επίδραση εισόδων ελέγχου. Για παράδειγμα το !enable δηλώνει ότι η είσοδος ελέγχου δεν είναι ενεργή. (στο παράδειγμα αυτό σημαίνει ότι παραμένει ο απαριθμητής στην ίδια κατάσταση όταν είναι ανενεργή η είσοδος ελέγχου) 5

Προγραμματίζοντας με μηχανές καταστάσεων • Παράδειγμα: To LED ανάβει όταν έχει πατηθεί ένας πλήκτρο • Δύο καταστάσεις LedOff LedOn • Μία είσοδος ελέγχου Button • Υπάρχουν δύο πεδία στην ετικέτα που χωρίζονται με /. Το πρώτο αναφέρεται στην τιμή της εισόδου ελέγχου για να πραγματοποιηθεί η μετάβαση και το δεύτερο στην ενέργεια που θα πραγματοποιηθεί • Το μεγάλο βέλος δείχνει την εισαγωγή στην αρχική κατάσταση 6

Προγραμματίζοντας με μηχανές καταστάσεων • Η μηχανή καταστάσεων δουλεύει ως εξής: – Εισέρχεται στην κατάσταση LedOff με την αρχικοποίηση. Το LED σβήνει. – Η μηχανή καταστάσεων καλείται περιοδικά. Αν το κουμπί δεν είναι πατημένο τότε έχουμε την μετάβαση για είσοδο ελέγχου !Button άρα παραμένει στην κατάσταση LedOff και δεν πραγματοποιείται κάποια ενέργεια (δεν υπάρχει /). Το LED παραμένει σβηστό. Αν το κουμπί είναι πατημένο τότε έχουμε την μετάβαση για είσοδο ελέγχου Button άρα έχουμε μετάβαση στην κατάσταση LedOn και πραγματοποιείται η ενέργεια Light LED. Το LED ανάβει. – Η μηχανή καταστάσεων παραμένει στην κατάσταση LedOn έως ότου απελευθερωθεί το κουμπί. Όταν απελευθερωθεί μεταπίπτει στην κατάσταση LedOff και πραγματοποιείται η ενέργεια Extinguish Led. Το LED σβήνει. 7

Προγραμματίζοντας με μηχανές καταστάσεων • Μπορούμε να γράψουμε τον κώδικα με δύο τρόπους: – Φτιάχνουμε ένα πίνακα καταστάσεων με μια στήλη επιπλέον για την ενέργεια (συνάρτηση) που πρέπει να εκτελεσθεί (κληθεί). Μπορεί να υλοποιηθεί σαν ένας πίνακας (array) με την τρέχουσα κατάσταση και τις εισόδους ελέγχου σαν δείκτες Γενικά είναι δύσκολος τρόπος σκέψης… 8

Παράδειγμα Robosapiens…. 9

Προγραμματίζοντας με μηχανές καταστάσεων • Οι απλές μηχανές καταστάσεων συνήθως υλοποιούνται χρησιμοποιώντας switch–case και if–else εντολές. Χρησιμοποιούμε την δήλωση static ώστε να διατηρείται η τιμή της μεταβλητής μεταξύ των κλήσεων της συνάρτησης • Στο παράδειγμα που ακολουθεί παρουσιάζεται το υποπρόγραμμα εξυπηρέτησης διακοπών του TimerA. Χρησιμοποιούμε την τεχνική polling για τον έλεγχο της εισόδου. • Θα μπορούσαμε να βασιστούμε στην λογική background-foreground με την χρήση Low power modes και interrupts για την είσοδο (χωρίς να χρειαζόμαστε τον TimerA που καλεί περιοδικά την μηχανή καταστάσεων). Στην περίπτωση αυτή θα είχαμε μια μηχανή καταστάσεων που καθορίζεται από γεγονότα event-driven state machine • background-foreground προγραμματισμός με low-power modes( SLAA294– MARCH 2006 MSP430 Software Coding Techniques ) και (Use an MCU’s low- power modes in foreground/background By Miro Samek President Quantum Leaps, LLC EE Times-India | October 2007) 10

11

LED is toggled on or off when the button is pressed 13

Interrupt service routine for channel 0 of Timer_A The state machine lights the LED while the button is pressed • #pragma vector = TIMERA0_VECTOR • __interrupt void TA0_ISR (void) // Acknowledged automatically • { • static enum { • LedOff, • LedOn • } LedState = LedOff; // State variable, initialized • Monitor = ON; • switch (LedState) { • case LedOff: // LED currently off • if (Button == ON) { // Button pressed? • LED = ON; // Yes: light LED • LedState = LedOn; // Change state • } else { • // No action needed • } • break; • case LedOn: // LED currently on • if (Button == OFF) { // Button released? • LED = OFF; // Yes: extinguish LED • LedState = LedOff; // Change state • } • break; • default: // Should never happen • LedState = LedOff; // Reset to initial state • break; • } • Monitor = OFF; • } 14

Real-time clock 16

State Machines for I²C Communication (Davies p.559) 17

18

Γενικές αρχές μεθοδολογίας ανάπτυξης συστήματος • Methodology • During the high-level architecture and system-level design, the research team will be looking at physical implementation issues. Although our design process, according to the work package presentation that follows, shows everything as a waterfall kind of flow, in reality the proposed platform design like all electronics design will follow an iterative, incremental process — that is, more akin to the famous ‘spiral’ model for software [Embedded Systems Handbook, Edited by Richard Zurawski, 2006 by Taylor & Francis Group, LLC p. 487]. 19

Γενικές αρχές μεθοδολογίας ανάπτυξης συστήματος 20 The spiral model

Γενικές αρχές μεθοδολογίας ανάπτυξης συστήματος The iterations and work diagram

Σύνδεσμοι • machine.com/doxygen/qpn/tutorial_page.h tmlhttp:// machine.com/doxygen/qpn/tutorial_page.h tml • visualSTATE/ visualSTATE/ • visualSTATE/Design-your-eZ430-Chronos- watch-with-IAR-visualSTATE/

Time Based Processing on an MSP430 Launchpad •I recently saw a video on MyBitBox on using bitfields in time based processes and thought it was and excellent example of a fairly advanced topic in embedded systems. In that blog, an mBed is used, which is an ARM based dev kit. I thought it would be useful to port this example to the MSP430 Launchpad. In this example, I’m using the MSP430G2231, but any MSP430 with Timer_A can be used.video on MyBitBox • •This example is used to show that microcontrollers can be setup to run several tasks at multiple intervals. The desired result is a system that executes these commands deterministically, meaning that at the desired time interval a routine WILL execute. this is useful when a microcontroller needs to multitask or divide a workload. •For this example, we’re going to setup a routine to run every second and another routine to run every 100ms. There are two LEDs on the Launchpad, so for this example we’ll toggle one LED at 100ms and the other at 1 second. •The first thing to do is define a struct with a bitfield to set flags whenever a time interval is reached.

•typedef struct time_flags { unsigned time_1ms :1; unsigned time_100ms :1; unsigned time_1s :1; }time_flags; extern volatile struct time_flags sys_time; •These flags will be set by an interrupt service routine that executes every millisecond. This ISR increments several counters. counter_base increments every millisecond until it reaches 100 and is reset. counter_100ms increments every 100ms until it reaches 10 (1 second), then it is reset. whenever we reach these desired increments we set the flags of the structs we created earlier. This method can be extended as much as desired so you could have an hour counter or day counter if you wanted.