Rhapsody on small processor platforms

(1)

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

Rhapsody on small processor platforms

Examensarbete utfört i Elektroniksystem vid Tekniska högskolan i Linköping

av

Per-Oskar Andersson

LITH-ISY-EX--08/4006--SE Linköping 2008

Department of Electrical Engineering Linköpings tekniska högskola

Linköpings universitet Linköpings universitet

(2)

(3)

Rhapsody on small processor platforms

Examensarbete utfört i Elektroniksystem

vid Tekniska högskolan i Linköping

av

Per-Oskar Andersson

LITH-ISY-EX--08/4006--SE

Handledare: Kent Palmkvist

isy, Linköpings universitet

Anders Sipuri

CC Systems AB Examinator: Kent Palmkvist

isy, Linköpings universitet Linköping, 2 June, 2008

(4)

(5)

Avdelning, Institution

Division, Department

Department of Electrical Engineering Department of Electrical Engineering Linköpings universitet

SE-581 83 Linköping, Sweden

Datum Date 2008-06-02 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport

URL för elektronisk version

http://www.isy.liu.se http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-4006 ISBN — ISRN LITH-ISY-EX--08/4006--SE

Serietitel och serienummer

Title of series, numbering

ISSN

—

Titel

Title

Rhapsody på små processorplattformar Rhapsody on small processor platforms

Författare

Author

Per-Oskar Andersson

Sammanfattning

Abstract

Rhapsody is a Model-Driven Development (MDD) tool for embedded and real-time system design. The purpose of this thesis is to determine if Rhapsody can be used for software development on small processor platforms such as the Atmel AVR. Rhapsody is normally used on platforms running an operating system. Therefore certain adaptations are needed in order to use it on platforms without an operating system. These adaptations and their affect on the usability of the tool, advantages and disadvantages are all studied while porting AVR-software to Rhapsody on one of CC Systems products, the robust on-board computer CC Pilot XL II.

Nyckelord

(6)

(7)

Abstract

Rhapsody is a Model-Driven Development (MDD) tool for embedded and real-time system design. The purpose of this thesis is to determine if Rhapsody can be used for software development on small processor platforms such as the Atmel AVR. Rhapsody is normally used on platforms running an operating system. Therefore certain adaptations are needed in order to use it on platforms without an operating system. These adaptations and their affect on the usability of the tool, advantages and disadvantages are all studied while porting AVR-software to Rhapsody on one of CC Systems products, the robust on-board computer CC Pilot XL II.

Sammanfattning

Rhapsody är ett verktyg för modelldriven utveckling och design av inbyggda sy-stem och realtidssysy-stem. Syftet med detta examensarbete är att undersöka om Rhapsody kan användas för att utveckla mjukvara till små processorplattformar som Atmel’s AVR. Då Rhapsody normalt används till plattformar med ett ope-rativsystem behöver vissa modifieringar göras för att möjliggöra utveckling mot plattformar utan operativsystem. Dessa modifieringar, deras för och nackdelar samt påverkan på utvecklingsprocessen undersöks medan AVR-mjukvara porteras till Rhapsody. Mjukvaran som porteras är en del av styrsystemet till en av CC Systems produkter: CC Pilot XL II, en robust fordonsdator.

(8)

(9)

Acknowledgments

I would like to thank Anders Sipuri, Johan Strandberg and Anders Öberg at CC Systems for excellent support and supervision during the making of this thesis. I also want to thank the rest of the staff in Alfta for making it a great time! Big thanks also to my university supervisor Kent Palmkvist.

(10)

(11)

3.4.2 No Framework . . . 22 4 Method 23 4.1 Choosing a Compiler . . . 23 4.2 Implementation Language . . . 23 4.3 Property-Files . . . 24 4.4 Hardware . . . 24 4.5 Debugging . . . 25 4.6 Software . . . 25 4.6.1 PC-Module . . . 26 4.6.2 Display-Module . . . 26 4.6.3 Example Project . . . 27 4.7 Implementation Methods . . . 29 4.7.1 IDF . . . 29 4.7.2 NOF . . . 29

4.7.3 Manual Statechart Implementation . . . 30

5 Results 31 5.1 Example Project . . . 32 5.2 PC Module . . . 33 5.3 Display Module . . . 34 5.4 Summary . . . 35 6 Discussion 37 6.1 Rhapsody Experiences . . . 37

6.2 State Machine Modelling . . . 37

6.3 Alternative Uses of Rhapsody . . . 38

6.4 What Method to Use? . . . 38

6.5 Other Tools . . . 39 6.6 Future Work . . . 39 6.7 Conclusions . . . 40 7 Glossary 41 Bibliography 43 A HeatingController 45

(13)

Chapter 1

Introduction

This thesis has been written within the context of master thesis studies at the Computer Science and Engineering programme (D-programme) at Linköping Uni-versity. The topic of the thesis has been suggested by CC Systems AB and most of the work has been performed at their office in Alfta.

CC Systems is a electronics/software company which supplies control systems, products and platforms for various types of heavy vehicles. One of these products is the CC Pilot XL II which is a powerful and robust on-board PC.

This thesis investigates if it is possible to use the code-generating tool Rhapsody to develop software for small processor platforms such as the Atmel AVR which is used in CC Pilot XL II.

1.1 Background

Rhapsody is a Unified Modeling Language (UML) based tool which can generate source code targeting embedded systems. With such a tool it is possible to reduce development time and automatically improve documentation and overview com-pared to manual development. Rhapsody can be used in all the steps in creating an application: Analysis, Design, Implementation and testing.

The CCP XL II is composed by a display unit and a PC unit. Each of these units has an AVR processor which handles internal communication, backlight con-trol and temperature monitoring among other things. The two AVR processors have state machine based software. CC Systems wants to update this software using Rhapsody in order to simplify maintenance and further development.

1.2 Goals

The main goals of this thesis project was to study if and how Rhapsody can be used to generate code for Atmel AVR by making working Rhapsody-implementations of the existing AVR-software. Since Rhapsody is primarily used on platforms running an operating system, the necessary steps to make it usable on small processor

(14)

2 Introduction

platforms needed to be investigated. If there was enough time, or if Rhapsody was deemed not suitable for small processor platforms, other similar tools were to be investigated as well.

1.3 Limitations

In order to fulfill the goal of making working Rhapsody implementations, several limitations have been imposed on the project. Although there are several similar products on the market, Rhapsody is the only tool investigated in this thesis. Due to licensing issues, the version of Rhapsody used in this thesis is 6.1 although newer versions were available. The techniques discussed in this thesis could be used on a number of different small platform systems, but they have only been tested on two members of the Atmel AVR family of microcontrollers. Due to the sheer size of the generated code and in consideration of the company’s copyright, no production code is included in the thesis. Instead, a small example project has been developed for demonstrating purposes.

1.4 Hardware and Software

1.4.1 Hardware

The following hardware has been used in the context of this thesis:

• CC Systems CC Pilot XL II

The CC Pilot XL II is a powerful, versatile and robust on-board PC, ideal for use in control and information systems. It is composed by a display module and a PC module and uses Windows XP as operating system. For detailed information see the product leaflet [1].

(15)

1.5 Organisation 3

• Atmel AVR JTAGICE mkIIR

The JTAGICE mkII is a development tool for On-chip debugging of Atmel AVR processors. For detailed information see the Atmel website [2].

• Atmel ATMega16 and ATMega644

The Atmel ATMega16 and ATMega644 microcontrollers are part of Atmel’s low-power CMOS 8-bit microcontroller series based on the AVR enhanced RISC architecture. The two microcontrollers are pin-compatible and the main difference between them is that Mega644 has larger Flash program memory, EEPROM and SRAM. Detailed information and data sheets are available at [3] and [4].

1.4.2 Software

The following software tools have been used in the context of this thesis:

• Ilogix Rhapsody 6.1

Ilogix Rhapsody is a Model-Driven Development (MDD) tool. Rhapsody is thoroughly described in chapter 3 Rhapsody. See the telelogic website [5] for the latest version.

• IAR Systems IAR Embedded workbench 4.21

IAR Embedded Workbench is a set of development tools for building and debugging embedded applications using assembler, C and C++. See the IAR website [6] for more information.

• Atmel AVR Studio 4

Atmel AVR Studio 4 is an Integrated Development Environment (IDE) for writing and debugging AVR applications. See the Atmel website [7] for more information.

1.5 Organisation

The thesis is organised in the following chapters:

• Chapter 1 Introduction

Introduction, background and goals for the thesis.

• Chapter 2 UML Introduction

Short theoretical introduction to UML. Readers allready familiar with UML may want to skip this chapter.

• Chapter 3 Rhapsody

Short introduction to Rhapsody explaining the necessary concepts discussed in the later chapters.

• Chapter 4 Method

(16)

4 Introduction

• Chapter 5 Results

Presents the results of the different methods.

• Chapter 6 Discussion

(17)

Chapter 2

UML Introduction

The Unified Modeling Language (UML) is an industry-standard language used to model systems. Primarily it is used to model object-oriented software systems, but it can also be used for other purposes such as business modelling. Graphical objects are used in different types of diagrams for specification, visualisation and documentation. UML is managed by The Object Management Group [8] together with the software industry. At the time of writing this thesis, the latest published version was UML 2.1.1 (2007).

This chapter is by no means a full description of UML, there are many books written on this subject, but rather a short introduction describing the most im-portant language elements, some of which are referenced later in this thesis. For readers that want to study UML 2.0 further, [9] and [10] are recommended.

2.1 UML 2.0

Version 2.0 of UML introduced a number of new constructs, elements and diagrams as well as improved language organisation, domain specific specializations and a higher degree of precision in the language definition. This makes Model Driven Development possible to a greater extent than in UML 1.x.

Some examples of improvements are:

• Nested Classifiers

Classifiers (Model elements such as Classes, Objects, Activities) can be nested which, for example, makes complex state machines possible by nesting many simple statemachines.

• Four New Diagrams

UML 2.0 introduces the Package Diagram, Composite Structure Diagram, Timing Diagram and the Interaction Overview Diagram.

• Improved Symbols and Semantics

The symbols have been improved or changed in many of the diagrams, adding more functionality and better semantics for the different diagrams.

(18)

6 UML Introduction

• Better Extendability

UML 2.0 offers better extendability than UML 1.x. Stereotypes, profiles and OCL can be used to adapt the language to specific domains.

2.2 UML Views

Ideally, describing an entire system in one easy to understand graph would be preferred. This is however impossible in all but the most simple cases. The concept of views has therefore been introduced to UML. Each view is described by a number of UML diagrams, described in section 2.5 – together describing a particular aspect of the design. The UML 4+1 View model is shown in Figure 2.1 and will be described in this section.

Figure 2.1. UML 4+1 View Model

2.2.1 Use-Case View

The use-case view describes the functionality the system should deliver. It is intended for customers, designers, developers and testers. The desired usage of the system is described in a set of use-case diagrams. Activity diagrams may also be used in this view. The use-case view ties all the other views together.

2.2.2 Logical View

This view describes how the system functionality is provided, in terms of struc-tural elements. Different levels of abstraction describe the logical architecture. A number of diagrams are used in this view: Class diagrams, Object diagrams, Package diagrams, Composite Structure diagrams and State diagrams. Modeling begins with Class and Package diagrams and is then expanded as needed with the other diagrams.

(19)

2.3 UML Model Elements 7

2.2.3 Implementation View

The implementation view, sometimes called component view, focuses on software module organization. Software is packaged into components which can be devel-oped and tested. The component diagram is the only diagram used in this view.

2.2.4 Process View

The process view divides the system into processes and processors, addressing issues of concurrency, distribution and fault tolerance. Sequence and Communi-cation diagrams are the most commonly used diagrams. The view can also be extended with activity, timing and interaction overview diagrams.

2.2.5 Deployment View

The deployment view shows the physical deployment of the system, in terms of processing elements such as computers and which processes that run on them. The connection between the elements to form the complete system is also described here. In order to describe this, deployment diagrams are used.

2.3 UML Model Elements

There are a great number of building elements in UML 2.0, structural, behavioral, grouping and annotational elements. It is difficult to classify them, since many of them can be part of both structural and behavioral diagrams. The elements are connected by relationships to create complete diagrams. This section describes examples of some of the most important or most used elements which can be seen in Figure 2.2.

(20)

• Class

A class is a description of an object type. The class describes the properties and behaviour of all instansiated objects of the class. A class is a structural element.

• Object

Objects are run time instantiations of classes. Objects can be both structural and behavioral.

• Component

A component is an replaceable, executable entity used in component dia-grams. Components are structural elements.

• Package

A package is a representation of a directory. A way to organize elements hierarchically. Packages are grouping elements.

• Use Case

A use case describes a functionality that the system will have or a goal that an actor wants to fulfill. This is done witout describing how it is implemented in any way. A use case is behavioral.

• Activity

Activities are behavioral elements used in activity diagrams to represent a physical or logical activity.

• State

States are behavioral elements used in state diagrams to represent the dif-ferent states the model can have.

• Note

A note is an annotational element, usually used as a short description of a diagram.

2.4 UML Relationships

An UML relationship is a connection between model elements adding semantics to the model. There are about 20 relationships defined. Figure 2.3 shows examples of some of the most used relationships.

• Dependency

A dependency relationship indicates that a change of the supplier model element may affect the client model element (but not the reverse).

• Association

An association relationship is a structural relationship between two elements that shows that objects of one classifier connect to objects of the other clas-sifier.

(21)

2.5 UML Diagrams 9

• Directional Association

A directed association is a one way navigable association.

• Generalization

A generalization specifies that a child element is based on a general parent element. Typically one parent has multiple children.

• Aggregation

An aggregation specifies that one element is a part of another element.

Figure 2.3. UML Relationship Examples

2.5 UML Diagrams

UML diagrams are the actual graphs that show how the different model elements are arranged and related. Each diagram is drawn to illustrate a particular aspect of the system and a system is usually described by several types of diagrams. Diagrams are often part of specific views as described in 2.2 and a diagram is often allocated to a view when it is drawn. This section describes the basic concepts behind each of the thirteen types of diagrams defined in UML 2.1.1. The diagrams are divided into three categories:

• Structure Diagrams

Includes the Class Diagram, Object Diagram, Component Diagram, Com-posite Structure Diagram, Package Diagram and the Deployment Diagram.

• Behavior Diagrams

Includes the Use Case Diagram, Activity Diagram and the State Diagram.

• Interaction Diagrams

Includes the Sequence Diagram, Communication Diagram, Timing Diagram and the Interaction Overview Diagram.

(22)

2.5.1 Class Diagram

Class diagrams show the static structure of classes in the system. Static, in this case, means that the described structure is valid at all time in the life cycle of the application. The class attributes and operations and the relationships between the classes are shown.

Figure 2.4. Class Diagram Example

2.5.2 Object Diagram

An Object diagram is a variant of a class diagram and uses a similar notation. Instead of classes, the object diagram shows a snapshot image of the object in-stances at a specific time. It can be used to exemplify a complex class diagram.

(23)

2.5.3 Component Diagram

Component diagrams show the physical structure of the code in terms of compo-nents. A component can be a source code component, a binary or an executable component. Dependencies between the different components are shown, as well as their respective interfaces. The component diagram is particularly good for early architectural modelling of a system.

Figure 2.6. Component Diagram Example

2.5.4 Composite Structure Diagram

Composite structure diagrams describe the functionality or the internal structure of a classifier. It can represent the different parts of a class. It can also represent the collaboration of a set of interconnected elements at runtime. The elements or the classifiers themselves can interact through ports or connectors. The diagram type is good to use early in the design phase.

Figure 2.7. Composite Structure Diagram Example

2.5.5 Package Diagram

Package diagrams describe the system in terms of logical groupings. Only pack-ages and the relations between them are allowed in a package diagram. Packpack-ages typically represent a directory, allowing for a logical hierarchical representation of the elements of the system. Package diagrams show a high level overview of the architecture.

(24)

Figure 2.8. Package Diagram Example

2.5.6 Deployment Diagram

Deployment diagrams model the physical architecture of the hardware and soft-ware units in the system. Deployment diagrams are populated with nodes, describ-ing a specific device in the system. Nodes can be shown as types or as instances describing either the characteristics of a device or actual occurrences of the device. Node communication can be described by associations and the protocol used can be indicated by applying a stereotype to the association.

(25)

2.5.7 Use Case Diagram

Use case diagrams show actors and their connections to different use cases. A use case describes a functionality that the system will have or a goal that the actor wants to fulfill. An actor is a description of someone interacting with the system. Use cases and use case diagrams are produced in the process of use case modelling, an iterative process between the developers and the users of the system leading up to a requirement specification.

Figure 2.10. Use Case Diagram Example

2.5.8 Activity Diagram

Activity diagrams show a sequential flow of activities in an operation or an inter-action. Activity diagrams are similar to state diagrams, but the primary purpose is to capture the actions and the results in terms of object state changes. Activ-ity diagrams are often divided into swimlanes, describing who is responsible for the actions taking place in the respective lane. Common elements of the activity diagram are initial and final node, activities, decision nodes and transitions.

(26)

Figure 2.11. Activity Diagram Example

2.5.9 State Diagram

State diagrams capture the life cycle of objects or systems. They describe the different states the object can be in and how events affect the states over time. A system can only be in one of the possible states unless a special type of state is used, concurrent states (AND or OR-states). The transition between states can be initiated by an event and guarded by a guard-condition. Actions can be performed on state changes. States can also have state variables, representing the attributes of a class. Common elements used in state diagrams are initial and final node, states, transitions, events, actions and guards. State diagrams are also explained in section 3.3.1, Statecharts.

(27)

2.5.10 Sequence Diagram

Sequence diagrams model the exchange of messages over time between objects. Time passes downward the vertical lines in the diagram and timing constraints can be added if applicable. Sequence diagrams model specific run time scenarios of the messages exchanged and the correct order of them. Messages can be synchronous or asynchronous represented by horizontal arrows with solid or stick heads. The lifetime of objects can also be specified by marking the destruction of the object by an X on the life line.

Figure 2.13. Sequence Diagram Example

2.5.11 Communication Diagram

Communication diagrams model the interactions between objects and the mes-sages that are passed. In order to show the sequence of mesmes-sages, a chronological number is added to each message indicating the correct order. Communication diagrams, formerly known as collaboration diagrams in UML 1, uses a combina-tion of informacombina-tion from the Class, Sequence and Use case diagrams to show a collection of collaborating objects.

(28)

2.5.12 Timing Diagram

Timing diagrams are a special type of sequence diagram, focusing on timing con-straints. They show the behaviour of objects in a given period of time. Time is increased from left to right and the diagram is similar to electrical hardware timing diagrams used by electrical engineers. The timeline can be discrete or a general value lifeline, described by text.

Figure 2.15. Timing Diagram Example

2.5.13 Interaction Overview Diagram

Interaction overview diagrams are a variation of activity diagrams. They visualize the interaction between different interaction diagrams such as sequence diagrams, communication diagrams or even another interaction overview diagram. The dia-gram notation is exactly the same as in activity diadia-grams, but the activity elements are replaced by an interaction diagram which is drawn in a frame.

(29)

Chapter 3

Rhapsody

3.1 Rhapsody Introduction

I-Logix Rhapsody was developed by I-Logix, a company acquired by Telelogic AB in 2006. The version 6.1 described here was developed before the acquisition. Future versions are therefore called Telelogic Rhapsody.

Rhapsody is a Model-Driven Development (MDD) tool for embedded and real-time system design. Rhapsody generates code from graphical models which can be specified in the modelling languages UML 2.0, SysML or DoDAF. The entire de-sign process can be modelled in Rhapsody, from analysis and system dede-sign with requirements and use-cases, to development, simulation and verification. Lan-guages supported for code-generation is C, C++, Ada, and Java. The generated code can be edited by the user and the changes can dynamically be roundtripped back into the graphical model.

The code generated by Rhapsody is Operating System (OS) independent. Support for individual Real Time Operating Systems (RTOS) is made through a framework called object execution framework (OXF). The OXF itself is also OS-independent, except for a set of adaptor classes called OS abstraction layer (OSAL). In order to support a new RTOS, the OXF needs to be rebuilt for the new target, but only the OSAL needs to be set up for the new environment. Rhap-sody comes with support for some commonly used real time operating systems, including Linux, OSE and VxWorks. Since the generated code is OS-independent, the same model can be used to generate code for different target systems at the same time.

3.2 User Interface

The Rhapsody user interface is comprised of a set of toolbars, the Rhapsody Browser and the Diagram Drawing Area. Typically the user selects a statechart or another type of diagram in the browser and then edits it in the diagram drawing area. When items are drawn on a diagram, Rhapsody automatically updates the

(30)

18 Rhapsody

model with the new elements.

All parts of the project can be seen in the Rhapsody browser. The browser is used to change initial values of variables, edit the code for operations or to add new classes, statecharts or other items. It is also used for accessing the huge amount of properties associated with each type of element. Different kinds of popup windows are used for these operations. Figure 3.1 shows the user interface when working with the example project described in 4.6.3.

Figure 3.1. Rhapsody User Interface

3.3 UML in Rhapsody

Rhapsody has full support for UML 2.0 as well as several other standards. How-ever, most of the diagram-types are not directly used for code-generation, but instead for documentation and analysing purposes. The constructive diagrams in Rhapsody are Object Model Diagrams (OMDs), Statecharts and Activity di-agrams. The constructive diagrams will be discussed further below. Sequence Diagrams are partially constructive; Rhapsody can create objects and operations from them, but the behaviour of the objects and operations will have to be defined in an OMD, Statechart or in code. Non-constructive diagrams such as Use Case Diagrams and Requirements Diagrams can be drawn as part of the design process. This section covers the diagrams used in this thesis, which are related to code-generation in Rhapsody: Statecharts and OMDs.

(31)

3.3 UML in Rhapsody 19

3.3.1 Statecharts

Statecharts and Activity Diagrams are both used to describe the behaviour of a class, but they can also be used for other types of objects. Statecharts are more suited for event-driven behaviour while activity diagrams are best used for workflow behaviour that is not event-driven. This is because statecharts usually remain in one state until an internal or external event occurs. A class can have a statechart or an activity diagram but not both. Statecharts and activity diagrams are not very different; the code generated from them is almost identical. Activity diagrams will not be used in this thesis project, which is why only statecharts is described more thorough.

A statechart is Rhapsody’s representation of the UML state diagram. State-charts is a powerful tool to model a system’s behaviour over time. It is a represen-tation of a finite state machine. Statecharts consist of states, transitions, triggers, guards and actions.

• State

A state is a graphical representation of the status of an object. States can be nested; there is no limit on the number of substates or levels of states. Two special types of states are worth mentioning; Or-states and And-states. An Or-state is a state broken down into exclusive substates, the state is always exclusively in either of the substates. And-states represent a concurrent state where each substate is active concurrently.

• Transition

A transition is the representation of a change of state. Transitions can have a trigger, guard, and actions.

• Trigger

There are three types of triggers which can be used in Rhapsody: events, triggered operations and timeouts. An event is an asynchronous, one-way communication between objects. A triggered operation is synchronous and can have a return-value. A timeout is a special operation with the syntax tm(timeunit) where timeunit usually is milliseconds. The timeout is sched-uled when the origin state is entered. It triggers after the specified time as long as the origin state has not been left.

• Guard

Guards are expressions that must evaluate to true for the transition to take place. A guard can be a variable or a function.

• Action

Actions are functions or code that is executed when the transition takes place.

(32)

20 Rhapsody

Figure 3.2 shows a small example of a Statechart drawn in Rhapsody containing two states, three transitions, an event, a timeout and a guard. A default transition makes the system start by entering the Idle state. When an event called evActive occurs, the action doStuff() is executed, and the system enters the Active state. A timeout is triggered after 1000 ms but the transition back to the Idle state is only taken if the guard isDone? is true.

Figure 3.2. Rhapsody Statechart Example

3.3.2 Object Model Diagrams

An Object Model Diagram (OMD) is a combination of the UML class diagram and the UML object diagram. It specifies the structure and static relations of the classes in a system. Classes, objects and packages as well as many different relations can be drawn in the diagram; Rhapsody generates code for everything drawn.

A Class is a description of a set of objects that have the same properties. Classes can contain attributes, operations, events, relations and many other things. Objects are basically instantiations of a class but objects can also be created without specifying a class. Packages are containers for classes and objects. All classes must be placed in a package, if a class is not placed in a specific package, it will be put in the default package. Examples of relations are dependency, association and inheritance.

Figure 3.3 shows a small example of an OMD. A home heating system with one furnace and three rooms are modelled. Two classes, Furnace and Room are modelled in a package called HomeHeatingSystem. These two classes have a few attributes and operations. An association between the two classes models the static relation between them. Each Furnace-object has three rooms and each Room object is associated with one furnace.

(33)

3.4 Rhapsody Without an OS 21

Figure 3.3. Rhapsody OMD Example

3.4 Rhapsody Without an OS

Rhapsody is primarily targeted for 32-bit processors running (real time) operating systems. It is however possible to use Rhapsody to develop code for environments without an OS. In order to do that, the OXF needs to be replaced by a framework which does not depend on an operating system. The Interrupt Driven Framework (IDF) is such a framework and it is available for Rhapsody in C and C++. Instead of using the operating systems support for threads and timers, this framework is driven entirely by interrupts. There is also a way to use Rhapsody without a framework at all. This is simply a set of rules and settings incorporated into a Rhapsody profile called No Framework (NOF).

3.4.1 Interrupt Driven Framework

The IDF itself is a Rhapsody model which can be customised by the developer to support new target environments. It is built into a library which should be included in projects using the IDF. The IDF replaces the OS and the OXF and works in a way as a tiny operating system. This is illustrated in Table 3.1.

There are of course both advantages and disadvantages of using the IDF. The biggest advantage is that the IDF can be used on small targets for which there is no RTOS available. The IDF can also be used for testing on new environments before porting of the OXF has been done to the new OS. The downside is that some of the functionality of the OXF is not available for the IDF:

(34)

22 Rhapsody

• Threads can be used but they are not true threads. The threads are

sched-uled by interrupts.

• Animation (graphical debugging) is not supported.

• Several code generation settings need to be set in a specific way. • Some classes are not integrated with the IDF.

• No dynamic allocation of heaps. Specific sizes need to be set up for the

environment.

To sum up, the developer has a more limited set of options when developing for the IDF compared to the OXF.

Table 3.1. Rhapsody Framework Configuration

3.4.2 No Framework

The No Framework (NOF) approach is a way to use Rhapsody generated statechart-code without any framework. It imposes limitations in how Rhapsody can be used. Using the NOF-profile enables the use of statecharts, but there is no support for the timeout-function tm(), which is often used with statecharts. Events can only be called synchronously and without parameters, while the IDF supports synchronous and asynchronous events, with or without parameters.

The NOF is available as a Rhapsody profile (a file with settings that can be imported to projects) and two source code files containing macros and definitions of some classes and functions necessary for statecharts. There is really only one advantage to using the NOF: The code size overhead associated with a framework is reduced which enables use on really small targets.

(35)

Chapter 4

Method

This study tries to determine if Rhapsody can be used to generate code for small microcontrollers such as the Atmel ATMega16. In order to demonstrate this, two existing applications are ported to Rhapsody, and one small example project is developed. This chapter describes the methods used and some of the problems that arose during the development.

4.1 Choosing a Compiler

CC Systems currently uses the tool IAR Embedded Workbench (IAR) for some of their AVR projects. This tool includes both C and C++ compilers as well as a linker and all the necessary parts of a complete integrated development environ-ment. It also contains support for on-chip debugging through various interfaces. The drivers and the existing code for the CCP XL II were made with IAR. There-fore, it came naturally to try to use this tool with Rhapsody.

In order to compile, make and run from within the Rhapsody IDE, Rhapsody must first be integrated with the IAR tools. Section 4.3 describes how this was done. Rhapsody could theoretically be used without performing this integration, but development would then require having the IAR IDE open at the same time, importing the code from Rhapsody. Rhapsody would be used only to generate the code. This would however slow down the development time significantly. It is a major advantage to be able to quickly compile in Rhapsody to see any generated errors. As we will learn later on, it was still necessary to use the IAR IDE when debugging on the actual hardware since no support for this exists in Rhapsody.

4.2 Implementation Language

Since Rhapsody is available for several languages, including C and C++, it was first necessary to make a choice between these two languages. The original software for the CCP XL II was written in C, but since it is easy to use code written in C in C++ projects, that did not affect the decision. The decision to use C++ was

(36)

24 Method

made after testing the C and C++ versions of the IDF. The C++ version was easier and faster to get working with the AVR processors. Another big advantage of C++ was the ability to use the NOF-settings, which was only available for Rhapsody in C++.

4.3 Property-Files

In order to use IAR with Rhapsody, a settings-file must first be created. Such a file is called a property-file and it contains, in plain text, different properties and their values. The property-files are read by Rhapsody when a project is opened.

These files were created by studying the commands used by the IAR IDE during compilation and linking, while making changes to existing property-files used for other environments. In order to be able to change the settings of the IAR tools, such as what processor-type to compile for or whether to use IDF or NOF, it was necessary to create several files, one for each major setting. A sample from one of these files is included in Listing 4.1. The whole files are unfortunately too big to be included in this report. The files contain settings for the Rhapsody code-generator, IDF/NOF-related settings, paths to the IAR tools and a makefile-template that Rhapsody uses when building a program.

After setting up these files, Rhapsody uses the IAR compiler and linker tools independently, without any need for the IAR IDE. The IAR software must still be installed and licensed for the setup to work.

Listing 4.1. Property-file sample

P r o p e r t y BuildCommandSet Enum " Debug , R e l e a s e " " Debug " P r o p e r t y S p e c E x t e n s i o n S t r i n g " . h " P r o p e r t y ImpExtension S t r i n g " . cpp " P r o p e r t y CPPCompileRelease S t r i n g " −z9 −−c r o s s _ c a l l _ p a s s e s =2 −D NDEBUG" P r o p e r t y LinkDebug S t r i n g "− r t " P r o p e r t y L i n k R e l e a s e S t r i n g "− F i n t e l −e x t e n d e d " P r o p e r t y CPUModel S t r i n g " m16 "

4.4 Hardware

The CCP XL II is as described in section 1.4.1 based on two parts, the PC Module and the Display Module. The AVR processors in the modules are programmable by the JTAG-interface which is an industry-standard interface for integrated cir-cuits. IAR together with the Atmel JTAGICE mkII was used for code-loading and debugging. During the project it was discovered that the original ATMega16 microcontroller did not have enough memory to handle the code generated by Rhapsody for the IDF. Therefore it was necessary to find a replacement microcon-troller in order to continue the project. Luckily, such a microconmicrocon-troller existed,

(37)

4.5 Debugging 25

the ATMega644 which has the same footprint as the ATMega16. The two micro-controllers differ mainly by the size of the different memories according to Table 4.1.

Flash program memory EEPROM SRAM ATMega16 16K Bytes 512 Bytes 1K Bytes ATMega644 64K Bytes 2K Bytes 4K Bytes

Table 4.1. ATMega16 & ATMega644

4.5 Debugging

While the different projects can be compiled and built within the Rhapsody IDE, there was still the problem of debugging the software in an efficient way. Rhapsody has support for debugging, animation in statecharts and other features, but this requires the use of the OXF with an operating system. In order to debug the soft-ware running on the hardsoft-ware, it was necessary to manually import the generated files into an IAR project. While this method did work well, debugging the gener-ated code manually was certainly more difficult than debugging manually written code. The structure and size of the code and the calls to framework-functions made the code more difficult to follow.

4.6 Software

The task of the project was to port the original AVR-software into a Rhapsody implementation. This thesis will not focus on the software itself, but instead on the process of porting it and the usage of Rhapsody on small processors. In order to demonstrate the difference in the methods used, while still keeping the size of the demonstrated code within reasonable limits, a small example project was created.

The two modules of the CC Pilot XL II both contain AVR processors which are used for controlling all functionality that is not controlled by the PC operating system. This functionality includes control of the start up and shutdown process of the modules, hard drive heating, temperature monitoring, display brightness settings and external button handling. The two modules communicate with each other by a Serial Peripheral Interface Bus (SPI). The PC-module AVR also commu-nicates with the PC by the standard serial interface (RS-232). This is illustrated in Figure 4.1.

(38)

26 Method

Figure 4.1. CCP XL II communication

4.6.1 PC-Module

The software of the PC-module AVR consists of a main function with a state machine written originally in C. Most of the functionality is however placed in several drivers from which functions are called from the state machine. There are drivers for SPI, serial interface, I2C, EEPROM etc. Porting of the software to Rhapsody was done by integrating the drivers and modelling the state machine as a Rhapsody statechart. Only minor changes had to be done to the drivers - mainly issues concerning the change to C++ from C, and the change of microcontrollers between ATmega16 and ATmega644.

Due to the structure of the software, there was no need to model different classes and objects in an OMD. Doing so would require a complete rewrite and design of the drivers used and would not be possible in the scope of this thesis project. A simple design with statecharts was the only viable option. The example project does however demonstrate how OMDs can be used to model the structure and relations of an application.

Development started by using the IDF Framework. During this stage it was discovered that the IDF itself used up more memory (SRAM) than was available on the ATmega16 which was the original microcontroller used on both modules. The ATmega16 was replaced by an ATmega644 which has 4k SRAM compared to the 1k of the ATmega16. When the IDF-implementation was working properly, an attempt to use the No Framework settings was made. This lead to reduced memory requirements and the original ATmega16 could be used again. More on the details of using the IDF and NOF can be found in section 4.7.

4.6.2 Display-Module

The software of the display-module is organised in the same way as the PC-module software: A state machine and drivers. Therefore the porting process was done in the same way. Since this module was ported after the PC-module, no

(39)

IDF-4.6 Software 27

implementation was made since the NOF-profile gave much smaller code and no change of hardware was required. Making an IDF-implementation could have been done relatively easy, but it was decided not to do this in order to minimize hardware changes and save time.

4.6.3 Example Project

A small example project was made in order to quickly evaluate new settings and to demonstrate the difference in code-size and memory usage. The project describes a small part of the PC-module functionality: regulating the hard drive heating. Hard drives should not be used in very low temperatures. Therefore the hard drive needs to be warmed up if the temperature is too low at start-up. The heating is stopped when the temperature reaches a certain value and the PC can now safely be started.

This functionality was modelled in Rhapsody with the IDF framework and the NOF-profile. A manual statechart implementation was also made in order to show the difference in code size. The manual implementation is further described in section 4.7.3. The OMD and the statechart described below are identical for the IDF and the NOF versions of the project.

An OMD was drawn with a package containing two classes: Harddrive which represent the physical hard drive and HeatingController which regulates the heat-ing of the hard drive. The OMD is shown in Figure 4.2. The temperature values used are -5 ◦C - +5◦C. The directed association drawn between the two classes represents that the controller controls a hard drive but the hard drive has no knowl-edge of the controller. The behaviour of the HeatingController was modelled with a statechart, which can be seen in Figure 4.3.

The HeatingController is very simple: every 100ms a timeout expires and the temperature is read. If the temperature is below minTemp, the heater is started. The heater is on until the temperature reaches above stopTemp and it will not be turned on again unless the temperature drops below minTemp again.

The generated source code for the HeatingController is included in Appendix A, HeatingController, as an example of how Rhapsody generated statechart code looks like. The source code from the example project is in total about a thousand lines of code. The following files are generated or used in the project:

• MainDefaultComponent.h/cpp Contains the main function which starts

the framework.

• HD_Heat_PKG.h/cpp Includes the two classes Harddrive and

Heat-ingController, generated from the OMD in Figure 4.2.

• HeatingController.h/cpp Contains the statechart code generated by the

statechart in Figure 4.3.

• Harddrive.h/cpp Functions for reading the temperature and turning the

heating on or off.

(40)

28 Method

• Avr.h Device-specific header-files and defines.

• NOFDefinitions.h/cpp NOF-specific functions and definitions. Only

in-cluded in the NOF-project.

Figure 4.2. Example Project OMD

(41)

4.7 Implementation Methods 29

4.7 Implementation Methods

Three different methods were used for the PC-module and the example project: IDF, NOF and manual statechart implementation. The display module was only implemented using the NOF-profile. This section describes the usage of the dif-ferent methods.

4.7.1 IDF

Using the IDF requires a software interrupt to be set up. The interrupt updates a time-variable in the framework by calling the function OXFTick(). The interrupt was implemented in the files Interrupt.h/cpp which are included in all projects.

Several changes had to be made to the IDF-model in order to make it compile with the IAR compiler and to reduce its memory footprint. Since the IDF is a big Rhapsody-model, it is impossible to include the model or the modifications in this thesis. It is possible that the size of the library could have been further reduced by making bigger changes to the model, but there was not enough time to investigate this further.

4.7.2 NOF

As described in 3.4.2 the NOF-profile lacks support for the statechart timer func-tion tm(). This is a big drawback compared to IDF, which is fully funcfunc-tional in this respect. An attempt to add this functionality was therefore made by rewriting the existing files that came with the NOF-profile. An existing timer in the drivers was used to reproduce the original timer functionality. Making it work with the generated code was done by redefining some of the classes and functions used by the framework and using macros to redefine some individual lines of code produced by the code-generator.

The original files called definitions.h and variables.h were replaced by the new files NOFDefinitions.h and NOFDefinitions.cpp. No other changes were necessary. This approach enables the use of the tm() function in NOF-statecharts but with one disadvantage: there can only be one timeout scheduled at the time. There was, due to the code-generator, no way to add support for multiple simultaneous timeouts as in the IDF and OXF frameworks. The projects described in this thesis did however not need support for multiple timeouts and therefore the modified NOF worked just as well as the IDF.

These modifications rely on a separate timer implemented in a driver. The timer is a simple interrupt-driven timer developed by CC Systems. The timer is driven by an interrupt in the same way as the IDF internal timer: A time-variable is updated at every interrupt. The same file, Interrupt.cpp, is used for both IDF and NOF. The code in the NOFDefinitions files could easily be modified to use another similar timer-implementation instead.

(42)

30 Method

4.7.3 Manual Statechart Implementation

A manual statechart implementation was made for the example project. The PC-Module statechart was also manually implemented, keeping all other files the same as in the IDF and NOF projects, but without the framework. The purpose of these implementations was to see how much overhead that was added by a Rhapsody-implementation compared to a manual implementation. Due to a lack of time, no manual implementation of the Display module was made. The original software is of course also manually implemented, but a comparison between the original software and the Rhapsody generated software could not be made since they are written in different languages (C/C++) which uses different compiler-settings. The size of the original code is however similar to that of the manual implementations described here.

Example Project

The files MainDefaultComponent.cpp, containing the main function, and Heating-Controller.cpp, containing the statechart code were replaced by one file, main.cpp. In fairness of the comparison between the manual code and the generated Rhap-sody code, the state machine code was written in such a way it might be written in a more advanced application. The functionality of the example project could be written in a much simpler way, without a timer and a separate class for the hard drive, which would reduce code size further. The simplest way would be using just an interrupt that triggers every 100us, and turns on/off the heater according to the current temperature. The only differences between the manual implementa-tion and the two Rhapsody implementaimplementa-tions are the state machine code and the fact that it does not use any additional framework as in the IDF version.

PC-Module

As in the example project, the main function and the generated statechart code was replaced by one file, main.cpp. This way, all the rest of the code is exactly the same as in the Rhapsody projects. This should be better than comparing with the original C-software which is slightly different, but with the same functionality.

(43)

Chapter 5

Results

This chapter shows the result of the different projects and implementation meth-ods. The design statecharts for the projects are presented as well as code size and memory usage. Part of the result of this thesis is also the settings-files pro-duced and the modifications made to the IDF and NOF, which could be used by other developers to quickly begin using Rhapsody on Atmel targets. Due to size limitations these files could not be included in this thesis.

The memory usage presented in the following sections may need an explanation: Code memory is the memory used to store the program code in the flash memory of the AVR. Data memory is the runtime memory usage (allocated in the internal SRAM of the AVR). Some additional data memory is needed for dynamically allocated objects, although the use of dynamic memory allocation was minimized during the development. The exact numbers may change with different compiler settings, but all results presented here are made with the same settings. The difference between the results is what is most interesting to study.

(44)

32 Results

5.1 Example Project

The Example Project of a harddrive heater was made in three different versions in order to study the difference in code size and memory usage. Table 5.1 lists the memory usage for the different projects and Figure 5.1 shows the statechart used in the IDF and NOF projects.

IDF NOF Manually Written Statechart Code Memory 7122 Bytes 1500 Bytes 1318 Bytes

Data Memory 1639 Bytes 147 Bytes 150 Bytes

Table 5.1. Example Project Memory Usage

(45)

5.2 PC Module 33

5.2 PC Module

The PC Module was made in three different versions: IDF, NOF and Manually written statechart. Table 5.2 lists the memory usage of the different versions. The statechart for the PC Module NOF project is shown in Figure 5.2. The IDF version is similar. All three versions have the same functionality and works well. There seems to be no loss in performance although this could not be thoroughly tested.

IDF NOF Manually Written Statechart Code Memory 18006 Bytes 10756 Bytes 8928 Bytes

Data Memory 1998 Bytes 503 Bytes 492 Bytes

Table 5.2. PC Module Memory Usage

(46)

34 Results

5.3 Display Module

The Display Module was only made in the NOF version and the memory usage and statechart are shown in Table 5.3 and Figure 5.3. It works well and has exactly the same functionality as the original software.

NOF Code Memory 7317 Bytes Data Memory 503 Bytes

Table 5.3. Display Module Memory Usage

(47)

5.4 Summary 35

5.4 Summary

As we can see in Figure 5.4, the overhead is not so big if we compare the NOF projects and the manually written statechart projects. The IDF framework does add significant overhead, but that was expected as it has more functionality than NOF. We can also see that the relative difference in size between IDF and the others decreases as the application code increases in size.

(48)

(49)

Chapter 6

Discussion

This thesis has shown that Rhapsody can be used to develop software for small processor platforms. It does however require some work to get it to work properly since Rhapsody is designed to be used on platforms running an operating system. Two methods of getting around this problem have been studied and each has its pros and cons. This chapter discusses the use of Rhapsody and looks briefly at additional tools.

6.1 Rhapsody Experiences

Rhapsody is an advanced program with very many features, many of which have not been used during this thesis project since they require a target with an oper-ating system. Working with Rhapsody is quick and easy once you get to know it, but there is a significant learning threshold to the beginner. The GUI is easy to navigate and gives a good overview of the different parts of the project. There are thousands of different settings that can be changed and some of them are poorly documented, a fact that slows down the development. Creating settings-files for new target environments can be difficult. Working with graphical diagrams instead of writing code may seem odd to developers used to writing efficient low level code. Using a graphical environment sometimes imposes limitations compared to writ-ing manual code. This is especially true when uswrit-ing the NOF settwrit-ings. Some things are impossible to realize with the code generator, for example simultaneous timers. Of course everything is possible to do manually after the code generation, but some things one might want to change are then overwritten by the generator the next time, making some tasks more difficult than they should be.

6.2 State Machine Modelling

There are several advantages to use statecharts in a tool such as Rhapsody com-pared to writing the code manually. First of all, it is easy to make changes to the state machine without the need to modify the code in several places. Illegal state

(50)

38 Discussion

changes may be introduced when writing the code manually, this is not possible in a generated state machine. It is easier to get an overview of the functionality of the state machine in a graphical model compared to studying the program code. These advantages come more in consideration as the state machine gets bigger. Another advantage is for documenting purposes. The state machine can easily be exported as an image. There are also some disadvantages: As can be seen in Figure 5.4, the generated code is usually much bigger than manually written code and it is also more difficult to read and debug. Graphical debugging capabilities would solve the later problem.

6.3 Alternative Uses of Rhapsody

In some cases, the use of generated statechart code can be too costly in terms of code size when working with small processor platforms. In this case, Rhap-sody could still be used during the design phase. Requirements, use-cases and other non-code generating diagrams could be modelled. The code generating class diagrams could be designed and the automatic documentation features could be used. The functional code could then be edited manually without any advanced code generation. This approach can be used even without adapting Rhapsody to the compiler tools of the platform used, since compilation can easily be performed outside of the Rhapsody IDE.

6.4 What Method to Use?

As can be seen in tables 5.1 and 5.2, using the NOF-profile makes for much smaller memory requirements than the IDF. The overhead compared to a manual imple-mentation is not very big. There are however some disadvantages to using the NOF-profile which should be considered when choosing method. The lack of a timer for statecharts is one such disadvantage - which only partly can be worked around. Another limitation is that just one type of event can be used instead of three different types in the IDF. One also has to manually create certain functions and manually add calls to other functions when using the NOF-profile. All this means that it takes some time to learn how to use the NOF-profile correctly, and that it does limit the options you have as a developer. Still, it is the only option if we really want to use Rhapsody with statecharts on very small platforms with data memory capacities of less than 2kb.

The IDF on the other hand has full support of Rhapsody’s statechart features and is easier to use than the NOF-profile. However, the framework uses a lot of memory which means that the smaller processor platforms can not be used at all with the IDF. A minimum of 4kb data memory is recommended, more is needed if the application uses a lot of memory. The framework also needs to be configured for usage on new platforms and new property files also have to be created or adapted to the new platforms.

Which method to use is mainly depending on the nature of the application and the available hardware. First of all, one should consider whether to use Rhapsody

(51)

6.5 Other Tools 39

or another code generating tool at all, and in what way. If the application is simple there really is no need to use such an advanced tool for code generation. If the application contains an advanced structure of classes and much of the functionality can be described by state machines, then there is clearly an advantage to use Rhapsody in the development. Whether to use IDF or the NOF-profile must then be decided based on the memory constraints of the hardware and the limitations of the NOF-profile.

6.5 Other Tools

There are a number of similar set of tools with the same or slightly different functionality than Rhapsody on the market. There was no time to evaluate all of them in the scope of this thesis. A quick scan of the market reveals several potential candidates for additional studies: No Magic MagicDraw UML, Artisan Software ARTiSAN Studio , AltovaR UModelR , Borland BorlandR TogetherR , IBMR

Rational Rose and IAR visualSTATE. These are just a sample and there areR

many other products with similar capacity. Looking at the specifications of these products, one of them stood out as being targeted at small processor systems, namely IAR visualSTATE.

IAR visualSTATE

IAR Visualstate is a set of tools for designing, testing and implementing embedded applications based on state machine diagrams. It is tightly integrated to IAR Embedded Workbench which enables true state machine debugging on hardware with direct graphical feedback.

From a quick look at the evaluation edition, it looks like this tool might be a better choice than Rhapsody for CC Systems AVR-projects since it seems to be aimed more at the small processor platforms the company works with. The integration to IAR Embedded Workbench, which the company already uses, and the fact that visual statechart debugging is available is a major plus. This feature, which has been shown is not available with Rhapsody for small processor systems, is really the key to make the best use of graphical code-generating design. Further studies of this tool are recommended.

6.6 Future Work

Although Rhapsody can be used in its current state to generate code for small processor platforms, using the techniques described in this thesis, additional re-search needs to be done. From the view of the company CC Systems, additional studies of newer versions of Rhapsody is recommended, as well as studies of other tools such as IAR visualSTATE. Perhaps these are good topics for other thesis projects. The use of the IDF framework could be further studied to see if the memory requirements could be reduced. In a more general point of view, stud-ies on how to generate efficient code with very little overhead from statecharts

(52)

40 Discussion

and other UML diagrams would be an area to explore further. Despite the rapid developments in electronics and microcontrollers, it seems as these small, cheap, 8 and 16 bits devices such as the Atmel AVR are here to stay for quite a while longer, and developing good software design platforms for these devices is certainly worthwhile.

6.7 Conclusions

This thesis has shown that Rhapsody can be used to generate full production code for small processor platforms. However, its use is limited to the following conditions: The software needs to be of a certain complexity to justify the use of a code generating tool. If the application is small enough, it would be faster and more efficient to manually write all code. If the software is complex, the target system needs to have the necessary memory capacity to handle the overhead compared to manually written code. This is less of a problem when using the NOF-settings, but these have other limitations which may pose a problem in large designs. Complexity, in this case, means that the software can be described in a large set of classes, statecharts and events. Some functionality, such as low level hardware drivers, may not be described in this way, and the use of Rhapsody for this type of software is limited.

All in all, working with Rhapsody could definitively shorten development times for certain types of projects, but the tool requires some experience to be used efficiently. Maintenance of Rhapsody generated software could be easier than manually written code, assuming that the developers know the tool well.

(53)

Chapter 7

Glossary

Ada High-level computer programming language based on Pascal.

AVR The Atmel AVR is a modified Harvard architecture 8-bit RISC single chip

microcontroller. The family of AVR’s uses Flash Memory for program stor-age, EEPROM for permanent storage and SRAM for volatile storstor-age, all integrated on one single chip.

C, C++ General purpose programming languages. C++ was developed as an

extension to C, introducing object-oriented features.

CCP XL CC Pilot XL. A powerful, versatile and robust on-board PC by CC

Systems AB.

CMOS Complementary Metal–Oxide–Semiconductor. Major class in integrated

circuits used in microcontrollers, RAM and other logic circuits.

DoDAF Department of Defense Architecture Framework. A system architecture

framework used by the American military and also by private and public companies.

EEPROM Electrically Erasable Programmable Read-Only Memory. Non-volatile

computer memory realized as arrays of floating-gate transistors.

Flash Memory Non-volatile computer memory. It is a specific type of EEPROM

that is erased and programmed in large blocks.

GUI Graphical User Interface. User interface which allows people to interact

with a computer.

I2C Inter-Integrated Circuit. A multi-master serial computer bus using two wires. IDE Integrated Development Environment. Software application for software

de-velopment.

IDF Interrupt Driven Framework. Framework used by Rhapsody to support

plat-forms without an operating system.

(54)

42 Glossary

Java Programming language developed by Sun Microsystems. Java is typically

compiled to bytecode that runs on Java virtual machines available for many computer architectures.

LVDS Low-Voltage Differential Signaling is a differential signalling system often

used with flat panel display monitors.

MDD Model–Driven Development. A trademark of the Obejct Management

Group, OMG.

NOF NO Framework. A Rhapsody profile enabling use of Rhapsody generated

statechart code without any framework.

OCL Object Constraint Language. OCL is a notational language for design of

software systems. OCL is a subset of UML.

OMD Object Model Diagram. A combination of the UML class diagram and the

UML object diagram used by Rhapsody.

OMG Object Management Group. A consortium, aimed at setting standards for

distributed object-oriented systems, modeling and model-based standards.

OSAL Operating System Abstraction Layer. A set of adaptor classes used by

Rhapsody to interface the OXF with individual operating systems.

OSE Operating System Embedded. Real-time embedded OS created by the

Swedish company ENEA.

OXF Object Execution Framework. A framework used by Rhapsody to support

different operating systems.

RISC Reduced Instruction Set Computing. CPU-design strategy where simple

instructions are made to execute very fast instead of a more complex, rich instructionset.

RS-232 Recommended Standard 232. Standard for serial binary data signals

commonly used in computer serial ports.

RTOS Real-Time Operating System. Multitasking OS intended for real-time

applications. Often used in embedded systems.

SPI Serial Peripheral Interface Bus. Synchronous serial data link standard where

devices communicate in master/slave mode.

SRAM Static Random Access Memory. Volatile semiconductor memory that

does not need to be periodically refreshed like dynamic RAM (DRAM).

SysML Systems Modeling Language. Defined as an extension of a subset of UML. UML Unified Modeling Language. Industry-standard language used primarily to

model object-oriented software systems.

Rhapsody on small processor platforms

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

Rhapsody on small processor platforms

Rhapsody on small processor platforms

Examensarbete utfört i Elektroniksystem

vid Tekniska högskolan i Linköping

av

Abstract

Sammanfattning

Acknowledgments

Contents

Chapter 1

Introduction

1.1

Background

1.2

Goals

1.3

Limitations

1.4

Hardware and Software

1.4.1

Hardware

1.4.2

Software

1.5

Organisation

Chapter 2

UML Introduction

2.1

UML 2.0

2.2

UML Views

2.2.1

Use-Case View

2.2.2

Logical View

2.2.3

Implementation View

2.2.4

Process View

2.2.5

Deployment View

2.3

UML Model Elements

2.4

UML Relationships

2.5

UML Diagrams

2.5.1

Class Diagram

2.5.2

Object Diagram

2.5.3

Component Diagram

2.5.4

Composite Structure Diagram

2.5.5

Package Diagram

2.5.6

Deployment Diagram

2.5.7

Use Case Diagram

2.5.8

Activity Diagram

2.5.9

State Diagram

2.5.10

Sequence Diagram

2.5.11

Communication Diagram

2.5.12

Timing Diagram

2.5.13

Interaction Overview Diagram

Chapter 3

Rhapsody

3.1