Implementing Wireless Sensor Network Applications using Hierarchical Finite State Machines Matthias Kr¨amer, Sebastian Bader, Bengt Oelmann Department of Information Technology and Media Mid Sweden University Sundsvall, Sweden
[email protected], {sebastian.bader, bengt.oelmann}@miun.se
Abstract—In typical application scenarios of wireless sensor systems the embedded software follows a sequential programflow. Such sequential systems are easily described using a finite state machine (FSM) abstraction model, as it is known from digital circuit design and control system development. In practice, a theoretical description in the form of an FSM must be transferred into a software implementation using an efficient programming abstraction method. This paper presents the implementation of a lightweight software library, which supports the development of wireless sensor applications based on hierarchical finite state machines (HFSM). With its minimalistic design approach, the implementation creates a small memory footprint and a high efficiency in state transitions and in Interrupt Service Routine execution. By introducing a hierarchical state machine architecture it is possible to split a complex algorithm into submodules. Hence, the code modularity and reusability is improved. Moreover, it is possible to test each module independently, so that code errors can be traced back more rapidly. This results in a very reliable application software.
I. I NTRODUCTION Wireless Sensor Networks (WSN) are distributed systems composed of multiple embedded sensor devices, which are capable of transferring measurement data wirelessly to central nodes. Typical embedded devices, like wireless sensor nodes, have to cope with certain hardware limitations such as computational performance, memory, or the capacity of the energy storage. Hence, the optimization of the embedded hardand software is essential in order to meet the requirements with regards to system lifetime and cost [1]. In order to make the best use of the available hardware resources an efficient software architecture is required. Therefore, a good modeling and abstraction method is essential, since it can significantly improve the quality and efficiency of the software. Another aspect that drives the development of programming abstraction mechanisms is the ease-of-use and the degree of comfort that can be provided during the implementation and maintenance of a system. Simple system structures are often implemented without the support of a software framework or library for hardware abstraction. Such low-level systems can be beneficial in the case of a relatively simple application that requires very short
978-1-4673-5200-0/13/$31.00 ©2013 IEEE
system response times, but which do not include advanced control sequences. In order to structure the implementation of wireless sensor applications, an event-driven programming abstraction mechanism is frequently used. Events on embedded devices are generally equivalent to the occurrence of a hardware interrupt to which the system will react and then return to an idle waiting state. Typical examples of event-driven architectures are the TinyOS [2] as well as the Contiki [3] operating system. With its component based abstraction mechanism TinyOS provides a modular code structure, but does not provide a deterministic program-flow. Hence the application code requires additional sequences of management code, which makes the design more complex [4] and more difficult to debug. With the protothread mechanism, Contiki tackles this problem, but since a protothread is implemented as a monolithic function block the resulting application code is less flexible and is often difficult to maintain. More advanced middleware has been developed in order to ease the implementation of high level software algorithms and applications in Wireless Sensor Networks. These systems provide a virtual machine [5] or database [6] implementation and so the user can rely on a platform independent APIInterface. Thus, the middleware avoids the time consuming implementation of a hardware abstraction layer, but can generate significant runtime overhead and often has a large memory footprint. Another design approach, used in wireless sensor systems, is based on the finite state machine (FSM) mechanism. This mechanism fits the periodic structure of typical embedded applications, such as WSN nodes, very well. Thus, the transfer of a theoretical system description into a software implementation is easy to realize. Moreover, the FSM based abstraction makes it easier to split an algorithm into short segments (i.e. states), which can be developed and tested separately. This work presents a lightweight software framework that supports the implementation of embedded software based on hierarchical finite state machines (HFSM). It uses object oriented design patterns in C++ in order to improve code modularity and encapsulation of different segments. The min-
124
imalistic design approach also enables rapid state transitions and minimizes the variation and latency of the hardware interrupt handling system, which provides an advantage in time-constrained applications. Moreover, the portability of an implementation is improved by providing a full hardware abstraction mechanism, which also includes encapsulation of the hardware interrupt mechanism of the microcontroller. The remainder of this paper is organized as follows. Existing design approaches based on finite state machines are reviewed in Section II, while Section III presents a classification of programming abstraction methods and then continues with a formal description and practical examples of finite state machines related to Wireless Sensor Networks. In Section IV the implementation of the software framework proposed in this paper is presented. A discussion of experimental results is given in Section V and the results are compared to the classification parameters introduced in Section III. Section VI presents the conclusions drawn from this work. II. R ELATED W ORK Different implementations of wireless sensor systems used the concept of finite state machines. An over-the-air reprogramming protocol based on a state machine model is presented in [7]. In [8] a mechanism to derive a FSM based graphical description from existent TinyOS applications was designed. This approach is only usable for debugging purposes and does not improve the implementation or development process. Another approach is presented in [9], in which a state machine runtime environment has been implemented as a TinyOS component. This approach is rather simple and does not consider a hierarchical software structure. Hence the system is not usable in more complex applications. Kasten and R¨omer introduced the OSM programming language and model, used to describe hierarchical and parallel finite state machines in [4]. The state flow is described using OSM code, which is, at a later stage, compiled into native C code. State and event functions, on the other hand, are directly implemented in C. An experimental OSM compiler was developed, but until now no full tool-chain has been published. The Quantum framework [10] implements state machines based on an object oriented software framework in C++. The implementation realizes the state-flow by calling the different state handlers via a single function pointer. However, because the quantum framework enables parallel code execution, it requires a complex event posting and distribution mechanism. The SenOS operating system [11] provides a runtime environment for a finite state machine based application development. The system kernel consists of a state sequencing and event queuing mechanism. But, instead of defining an application layer, each state directly enables a driver function in the callback library of the system. Using this approach will either make the callback library less flexible because the functions would have to be quite complex, or it would cause the system to be comprised of many sub-states. The latter
would cause the program-flow graph to be cryptic and difficult to maintain. To address the limitations in existing approaches, the implementation presented in this work introduces different software abstraction layers and enables hierarchical state machines. Thus, it improves both the flexibility and modularity of the software architecture. III. T HEORY In order to improve the development process of embedded software and to handle the growing complexity of embedded devices, different programming abstraction methods have been introduced. But, since each abstraction method brings certain advantages and drawbacks, developers often have to make a tradeoff between ease-of-use and efficiency, when selecting a programming mechanism. Programming abstraction methods can be classified by a set of qualitative and quantitative parameters, which help developers to select an abstraction method that best fits their application. These parameters are Usability, Readability, Modularity, Reliability and Efficiency. A. Classification of Programming Methods Modeling and abstraction methods should satisfy the following aspects, in order to bring an advantage during the software design and implementation process. 1) Usability: A software abstraction method should help designers to formulate a real world problem in a standardized syntax. The syntax and code-structure should therefore be designed in such a manner that it is able to support a developer in understanding and formulating the problem at hand in a simple and time-efficient manner. Moreover, the transfer of a theoretical description to the final software implementation should be efficient. 2) Readability: Enforcing a good software structure, the abstraction method can improve the readability of the resulting source code and therefore assists in the prevention of code errors. 3) Modularity: Modular software designs make concurrent designs possible and speed-up the development process. Moreover, it is possible to reuse driver and sub-modules in other projects. 4) Reliability: A good software abstraction method can help to detect and prevent invalid system behavior as soon as possible in the development process. Hence the embedded software can be implemented in such a way that it is possible to avoid a system lock-up or that it is possible for the system perform to an automatic recovery from invalid system states and lock-up conditions. 5) Efficiency: In order to make the best use of available resources, the generated code should have a small memory footprint and should create minimal runtime overhead. An abstraction method, which very well fulfills the parameters mentioned previously, is the HFSM mechanism. Thus, the software framework introduced in this paper uses hierarchical finite state machines as its basic working principle.
125
Toplevel-FSM
δTB
Q0
Q0
δ δA
δ F
Q2 (a)
T0
Sub-FSM A
δB
δT T1
Q1 δ
δTA
δA
δ
Q0
T0
δAT δT F
Q1 δBT
δB T0 Sub-FSM B
(b)
Fig. 1. (a) Non-hierarchical FSM, (b) Complex State Machine, split into sub-modules
B. FSM Formalism The formalism known as the finite state machine describes sequential logical systems and is frequently applied to describe algorithms in computer science, as well as to design digital electronic circuits. As previously mentioned, in addition, embedded applications such as wireless sensor systems can be implemented using FSM based design approaches. A typical FSM M, (see Figure 1a) can either be represented graphically using state-charts [12] or can be formulated using a mathematical description [13] based on an 5-tuple that combines the following elements: (Σ, Q, qo , δ, F ) Σ Q q0 δ F
Input Alphabet (finite set of valid input events) Set of System-States Initial State q0 ∈ Q Transition function δ : Q × Σ → Q Set of Final States F ⊆ Q
A hierarchical finite state machine, (see Figure 1b) is a concept used to split large state machine definitions into sub-modules. The mathematical description can represent this splitting by describing the entire state machine as a set of sub-state machines Mhierarchical = {M0 , M1 , Mn }. M0 defines the system’s top-level module, which contains the application’s first entry point after the start-up. The 7-tuple (Σ, Q, qo , F, T, δ, δsub ) is derived from the description for non-hierarchical state machines. As can be seen below, every sub-FSM has to define a set of states that allow a transition and re-entry from and to other sub-state machines. Furthermore, a transition function which describes the program-flow between sub-state machines has to be defined. T δsub
States that allow entry/re-entry T ⊆ Q Transitions to sub-FSM δsub : Tn × Σn → Tm
C. Hierarchical Finite State Machines in WSN Applications Hierarchical finite state machines can be applied in various wireless sensor systems that require a complex system architecture. These systems often consist of multiple independent sub-modules, which have to interact via several well defined
interfaces. The following application examples emphasize the benefits of HFSMs in embedded applications. 1) Flexible Embedded Applications: Wireless sensor nodes often have to switch the currently running software according to the application scenario in which they are used. In sensor networks that rely on a dynamic mesh or a clustered topology the node must be capable of adapting to changes in the topology. In the design of end-user devices it is mandatory that the system can handle different application scenarios and can provide different services, without requiring a modification of the embedded software. In this kind of system, several application modules exist in parallel in the MCU’s memory but just one module is enabled at a time. Hence, no context switching between software modules is needed and so a full-scale real-time operating system, that comes with an enormous memory overhead, is not required. An HFSM based implementation is well suited for these scenarios, since a top-level FSM can be used to select the required application module, which is realized as a subFSM. 2) Module Splitting: With the growing complexity of wireless sensor applications, the embedded software used to run the systems becomes more advanced. In order to handle the system’s complexity it is a common design practice to split an application into sub modules, which can then be implemented and can be more easily maintained. However due to the strong coupling between different segments in a typical embedded application it can be difficult to realize this kind of module splitting efficiently. An application based on a hierarchical state machine enables efficient module splitting in the different hardware abstraction layers, while avoiding the additional overhead of a full realtime kernel. A WSN application has to perform tasks such as sensor sampling, data processing/storage and wireless communication. These modules can be implemented as a sub-state machine and they are then called by the top-level FSM. Since the modules interact via well defined interfaces the different modules are interchangeable and can easily be reused. 3) Driver Implementation: Additionally to the application layer, it can also be a good option to implement device drivers in the form of a state machine. Radio modules or intelligent sensor modules often require to trigger an interaction and then utilize the MCU to process the module’s response, a behavior which fits the FSM abstraction very well. IV. I MPLEMENTATION In order to preserve the integrity of the different software modules in the driver and application layer, it is necessary to encapsulate these modules. Therefore, the software framework presented in this paper uses an object oriented design pattern and thus, has been implemented in C++. Hence it is possible to avoid data violation by the invalid use of internal memberfunctions and attributes. The FSM framework has been structured in three abstraction-layers (Application, Support, Hardware Abstraction), which are presented in the class-diagram in Figure
126
2. The object oriented design approach uses a composition mechanism to build a flexible and easily extendable interface, while the application layer uses inheritance to gain access to the driver and FSM modules in the support layer.
Start FSM
Wake MCU & Call Interrupt Handler *
Call State-Handler *
Continue operation?
A. Application Layer This software abstraction layer contains the user-defined code modules, which describe the actual program-flow of the state machine based application. As can be seen in Figure 2, the hierarchy of the state machine architecture is represented by the class structure in this layer. Therefore, the FSM classes of the higher hierarchy levels have to be implemented as a composition of the required sub-FSM classes. The elements of an application class are defined as being static in order to allow pointer-to-function operations before an object has been initialized. Furthermore, it allows the interrupt handling system to access the user-defined interrupt handles by a group of friend functions defined in the support layer. Each FSM class consists of two core elements: a finite set of state and interrupt handler functions that describe the application’s program-flow and a data-structure, which contains the main system variables used to control the FSM handling system. B. Support Layer The support layer introduces two base classes (DriverInterface and FSM-support), that are inherited by each FSM class present in the application layer. The DriverInterface class implements a unified interface to the hardware abstraction layer, which combines the different driver modules. The other element in the support layer, the FSM-support class, combines the finite state machine and the interrupt handling system. By enabling program states in their correct order, the FSM handling system manages the correct program-flow. Hardware interrupts of the microcontroller are managed by the interrupt handling system. This system is responsible for enabling the user-defined interrupt handlers, which are defined in the application layer.
Top-level FSM Sub-FSM A
Sub-FSM B Call Handler
Application Layer
DriverInterface
FSM Support
Support Layer
Initialize Handler
Radio
Sensor A
Sensor B
UART
ADC
I2C
Hardware Abstraction Layer
Shared Memory
ISR Top
A
B
MCU Interrupt
Fig. 2. Class-diagram of an embedded application based on hierarchical state machines
Hardware Interrupt MCU enter sleep-mode
false
true
false
MCU active?
Return to toplevel
true
true
Next state valid?
false
Fig. 3. Program-flow when executing a FSM based application (* Handler defined as static member of the application-class
Since DriverInterface and FSM-support are implemented independently it is possible to create low-level applications which use just one of the modules. 1) FSM Handling System: The central element in the FSM handling system is a one-dimensional array of pointers to functions. Each element holds a pointer to a state handler function, which is initialized in the constructor of the FSM application class. These pointers will, at a later stage, be used by the FSM handling system to switch between the application states. The actual program-flow is realized by setting the index of the array of pointers to functions. This index variable is part of the data-structure used to control the FSM handling system from within the application layer. The other parameters, which are used to control the handling system, are a unique application-ID, which identifies every FSM module in the implementation, the initial state an FSM enters after the start-up or re-entry, the sleep-mode that is entered into after the state handler ends (the MCU can also stay active and jump to the next state directly) and the number of system states available in the FSM implementation. The program-flow of the FSM handling system is presented in Figure 3. Transitions between system states are either conducted directly or by invoking a low-power waiting state. In the first case the handling system directly calls the next state after the program-flow returns from the application layer. When a delay between states is requested, the microcontroller enters a low-power sleep mode and is woken by a hardware interrupt. In this case the interrupt handling system will be enabled and the next state will be selected within the user defined interrupt handler that is part of the FSM application class. 2) Interrupt Handling System: The interrupt handling system has been introduced to encapsulate the microcontroller’s hardware interrupt mechanism. Moreover, this mechanism enables the sharing of a hardware interrupt between different FSM modules of an implementation, since the developer can
127
C. Hardware Abstraction Layer The Hardware Abstraction Layer (HAL) encapsulates the microcontroller’s internal periphery modules (e.g., UART, SPI, etc.) from the support and application layer, in order to make the code portable to different hardware platforms. This abstraction layer hosts the device drivers, which are utilized in the DriverInterface class. These drivers are used to operate modules such as radio, non-volatile data storage, sensors or timer modules available on the hardware platform. V. E XPERIMENTAL S ETUP AND R ESULTS In order to evaluate the software architecture presented in this work, two application examples have been implemented. The Blink example uses a non-hierarchical FSM, while the
Enter ISR
Push MCU Registers to Stack
Array [ApplicationID] r 1 2 0
specify an independent interrupt handler for each FSM. For every hardware interrupt, which is enabled in a specific application scenario, the support layer implements an Interrupt Service Routine, which uses the same syntax as for the ordinary low-level systems. These ISRs are not members of any class and can therefore be identified as an Interrupt Service Routine during the linking process, which inserts them into the interrupt vector table of the microcontroller. In order to gain access to private class elements of the FSMsupport class, each Interrupt Service Routine is specified as a friend-function of the FSM support class. Dependent on the compiler it might also be necessary to specify a C-Prototype for each ISR, in order to make it visible to the linker. In addition to the declaration and definition of the hardware specific Interrupt Service Routines, the handling system also performs an activation of interrupts and flag clearing after a hardware interrupt has occurred. Therefore, the user-code can be implemented as being fully hardware independent. Figure 4 presents the program-flow after a hardware interrupt has been triggered. After the hardware interrupt has occurred, the Interrupt Service Routine specified in the interrupt vector of the microcontroller is entered and the required stackpush operations are performed. Following this, the jump to the user defined interrupt-handler is performed and afterwards the stack-pulling is performed and the Interrupt Service Routine ends. In order to be able to identify the array element that needs to be accessed, the interrupt handling system is using the modules unique application-ID. Since the interrupt handlers are specified as element of the FSM class, they are allowed to access the internal data structures and can therefore be used to control and influence the modules program-flow. Some applications might require the system to be able to react to fully asynchronous interrupts, which can occur at any time regardless of which FSM module is currently active. To deal with this requirement, the interrupt handling system can be configured to initialize all elements of the array in an ISR with the same function pointer. This configuration enables a secured handling of asynchronous interrupts while avoiding any additional run-time overhead.
Leave ISR
FSM 0 Interrupt Handler FSM 1 Interrupt Handler FSM 2 Interrupt Handler
Pull MCU Registers from Stack Interrupt Service Routine
Application Layer
Fig. 4. Interrupt handling mechanism: Program-flow after a hardware interrupt is detected
more advanced Sample & Send application applies a hierarchical architecture with a top-level and two sub-state machines. The software is targeting the SENTIO-em platform, which is based on an energy efficient ARM Cortex-M3 microcontroller [14], running at 32 MHz. The performance of the software framework introduced in this work has been evaluated using the classification parameters, presented in Section III. A. Qualitative Results Thread based solutions can achieve modularity and encapsulation in embedded applications. But, since a thread is usually implemented in a monolithic function block, the application code can become difficult to read and to maintain when the number of control sequences is increased. Hence the code becomes less flexible and is more difficult to debug, which will, in the end lead to less reliable software. In the examples presented in Section V-B, it is shown that the number of branches and switch/case statements can be reduced in an FSM based application. Thus, the system leads to short state and interrupt handling functions. Since transitions are defined immediately inside the handler functions, no complex transition table is required, so the number of possible transitions is limited. Hence, invalid transitions can be avoided and the reliability of the embedded application can benefit from applying FSM based programming abstraction. Since the usability as well as the readability of a source code is highly dependent on the user’s preferences, it is difficult to compare different implementations directly. Nevertheless, it is possible to analyze characteristics of the resulting application code, such as the typical length of user-code functions or the number of sub-branches and control sequences that are required. Moreover, the abstraction mechanism should make it easy to understand the relationship between a real world problem and the software implementation. As mentioned above, the FSM abstraction simplifies the translation of a theoretical description into an implementation and also focuses on well-structured and efficient user-code. Hence it improves the readability and thus also the usability of the software.
128
TABLE I L ATENCY AND VARIATION OF S YSTEM -T RANSITION T IMINGS Transition: State-to-State
AVG [μs]
STDEV [μs]
1.56 3.8 6.77
0.004 0.007 0.007
AVG [μs]
STDEV [μs]
0.77 1.74
0.007 0.007
directly (MCU does not sleep) via interrupt handler, use Sleep* via interrupt handler, use DeepSleep** Transition after HW Interrupt Entering Service Routine* Entering Interrupt-handler*
mechanism, therefore the variance and latency of transitions in the interrupt system are minimized. The interrupt handling system also implements a method to share a hardware interrupt between different modules of an embedded application. The system makes it possible for the developer to define hardware independent interrupt handling functions for each module. Thus, it brings significant progress to code modularity and hardware independence in relation to embedded software development. The software architecture applied in this work has introduced different abstraction layers, which help to unify the interface to platform-specific hardware modules. Moreover, the software framework introduced the concept of hierarchical finite state machines, a mechanism which helps to split complex applications into smaller modules that are easier to handle. Thus, it becomes easier to achieve reliability, since the submodules have a less complex structure than would be the case for a monolithic system. Furthermore, the modular structure improves the reusability of the code.
* 32 MHz MCU clock kept enabled ** 32 MHz MCU clock disabled, Crystal-Stabilization for 16k cycles after wake-up TABLE II M EMORY F OOTPRINT OF FSM BASED APPLICATIONS Module
Blink [%] [kiB]
Sample [%] [kiB]
HAL&Driver Support Application
84 3.8 12.2
72.8 2.6 24.6
Codesize
8.3 0.38 1.2 9.9
19.1 0.69 6.5 26.3
R EFERENCES
B. Quantitative Results In order to evaluate the efficiency of the proposed software framework, the duration of the different state transitions has been analyzed. The software examples mentioned previously use a GPIO pin of the microcontroller to indicate the execution time of certain code sequences. The duration of the generated pulses was then measured using a logic analyzer. As can be seen in Table I, the resulting system timings are highly deterministic and vary only in the range of the logic analyzers measurement resolution. Moreover, the latency that is caused by the FSM and interrupt handling system is maintained within the range of micro-seconds. These delays are within the same range as those in relation to a simple function call on the same hardware. Hence it has been shown that the framework minimizes the runtime overhead for FSM execution and interrupt handling. Another aspect that determines the framework’s efficiency is the memory footprint of the final binary file. Table II compares the size of the two example applications (Blink and Sample&Send), which were compiled using the g++ compiler for ARM based microcontrollers. As can be seen in Table II, the memory overhead that is introduced by the support layer is limited to (2.6 to 3.8 %) of the entire application’s memory usage. VI. C ONCLUSION In this paper a runtime system for hierarchical finite state machines targeting wireless sensor nodes has been presented. The minimalistic design approach enables a small memory footprint and deterministic system timings, in order to comply with the resource limitations of typically used platforms. The interrupt handling mechanism has been designed in such a way so that it does not rely on event-queuing or any kind of polling
[1] M. Pasha, S. Derrien, and O. Sentieys, “Toward Ultra Low-Power Hardware Specialization of a Wireless Sensor Network Node,” in 13th International Multitopic Conference, Dec. 2009. [2] P. Levis and G. David, TinyOS Programming. The Edinburg Building, Cambridge , United Kingdom: Cambridge University Press, 2009. [3] A. Dunkels, B. Gr¨onvall, and T. Voigt, “Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors,” in Proceedings of the First IEEE Workshop on Embedded Networked Sensors, EmNets-I, 2004. [4] O. Kasten and K. R¨omer, “Beyond Event Handlers: Programming Wireless Sensors with Attributed State Machines,” in Proceedings of the 4th International Symposium on Information Processing in Sensor Networks, IPSN, 2005. [5] P. Levis and D. Culler, “Mat´e: A Tiny Virtual Machine for Sensor Networks,” Special Interest Group on Operating Systems, SIGOPS, vol. 36, no. 5, pp. 85–95, Oct. 2002. [6] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, “TinyDB: An Acquisitional Query Processing System for Sensor Networks,” ACM Transactions on Database Systems, vol. 30, no. 1, pp. 122–173, Mar. 2005. [7] Y. Ling, H. Tiansheng, L. Caixing, X. Yue, and Z. Haoen, “A Reprogamming Protocol Based on State Machine for Wireless Sensor Network,” International Conference on Electrical and Control Engineering, ICECE, pp. 232–235, 2010. [8] N. Kothari, T. Millstein, and R. Govindan, “Deriving State Machines from TinyOS Programs Using Symbolic Execution,” in Proceedings of the 7th International Conference on Information Processing in Sensor Networks, IPSN, 2008, pp. 271–282. [9] S. Smolau and R. Beaubrun, “State-Oriented Programming for TinyOS,” in Proceedings of the 2007 Summer Computer Simulation Conference, SCSC, 2007, pp. 766–771. [10] M. Samek, Practical UML Statecharts in C/C++, Second Edition: Event-Driven Programming for Embedded Systems, 2nd ed. Newton, MA, USA: Newnes, 2008. [11] T.-H. Kim and S. Hong, State Machine Based Operating System Architecture for Wireless Sensor Networks, K.-M. Liew, H. Shen, S. See, W. Cai, P. Fan, and S. Horiguchi, Eds. Springer Berlin / Heidelberg, 2005, vol. 3320. [12] D. Harel, “Statecharts: A Visual Formalism for Complex Systems,” Science of Computer Programming, vol. 8, no. 3, pp. 231–274, Jun. 1987. [13] T. Hanneforth, “Finite-State Machines: Theory and Applications,” Lecture Notes, Aug. 2010. [Online]. Available: tagh.de/tom/wp-content/ uploads/FSM UnweigtedAutomata.pdf [14] Energy Micro, “EFM32G280 Datasheet F128/F64/F32,” revised: 2012august. [Online]. Available: http://cdn.energymicro.com/dl/devices/pdf/ d0006 efm32g280 datasheet.pdf
129
