 

 

“p.23

uu
.qu. jaw.“ .m
Emu?! tins).

FF dﬁﬂMMsiLﬁ-ﬂ.
1.5).. #3

.15

‘ 350.3.
”1th 13.1... .I y

.5
v.

.
is... ..
v- 7... =8.
.35. .

.
.3.

qurki .19..
. ,. ..
1.231.355!

x... it
.1135 i...

I .iv 1"
than;
.Jmh1.rufv
3 iv
)ﬁﬂ»
agavﬂmrﬂs .53 ﬂ
.1. 2.
v4.3... .

5 .3."
37. 4}.

, .2}...
‘Ha
. 1!:
5.955%
5.. ..
up
’I‘ua ..
$3. $5

is}. r
.15.! 2-
1L1

 

 

 

 

IGAN B

11111111111111111111111111111 }

1 31293017 91991

 

LIBRARY
Michigan State ,
University .

 

 

 

This is to certify that the

thesis entitled

HARDWARE-SOFTWARE CO-DESIGN FOR EMBEDDED SYSTEMS
IMPLEMENTATION OF A STEPPER-MOTOR CONTROLLER

presented by
Anuradha Mulukutla

has been accepted towards fulfillment
of the requirements for

Master's degreein Electrical Eng

 

Major professor

Date //Z//;///

0-7639 MS U is an Affirmative Action/Equal Opportunity Institution

PLACE IN RETURN Box to remove this checkout from your record.

TO AVOID FINES return on or before date due.
MAY BE RECALLED with earlier due date if requested.

 

DATE DUE

DATE DUE

DATE DUE

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1/99 chanpﬁS—p.“

A ar’z. _a_- 4“.—

..A' ._ .gn-n..__..‘.-ar.. L. ._

"A

 

HARDWARE-SOFTWARE CO-DESIGN
FOR EMBEDDED SYSTEMS

IMPLEMENTATION OF A STEPPER-MOTOR CONTROLLER

By

Anuradha Mulukutla

A THESIS

Submitted to
Michigan State University
in partial fulﬁllment of the requirements
for the degree of

MASTER OF SCIENCE

Department of Electrical and Computer Engineering

1998

ABSTRACT

HARDWARE-SOFTWARE CO-DESIGN FOR EMBEDDED SYSTEMS

IMPLEMENTATION OF A STEPPER MOTOR CONTROLLER

By

Anuradha Mulukutla

Hardware-software co—design entails the combined speciﬁcation of hardware
and software at the system level, and the use of such a speciﬁcation for co-
simulation, co—synthesis and / or co-veriﬁcation of the system. The co—design method-
ology is especially relevant to embedded systems which involve software with spe-
ciﬁc functionality embedded in microprocessors, often interacting with the envi-
ronment and controlling external machinery. The objective of this thesis is to
demonstrate the hardware-software co—design ﬂow by using two implementations
of a stepper-motor controller. One approach uses a hardware chip for the pur-
pose, while the second approach is using the POLIS co-design environment and
the PTOLEMY simulator. The results of the two implementations, and a study
of hardware-software co-design considerations for system speciﬁcation, architec-
ture, hardware-software partitioning and the related trade-offs are presented, with

speciﬁc reference to the stepper-motor controller experience.

DEDICATION

This work is dedicated to my parents.

iii

ACKNOWLEDGENIEN TS

This thesis would not have been possible without the guidance, encouragement,
and support of Dr. P.D. Fisher. I extend my sincere thanks to him. I am also
thankful to Ms. Roxanne Peacock and Mr. Brian Wright of the EB technical
shop for their help. My special thanks are due to Mr. Robert Yu for his help with

handy board and the intro] software.

iv

Contents

1 INTRODUCTION 1
1.1 Objectives ............................... 3
1.2 Outline ................................. 3

2 HARDWARE-SOFTWARE CO-DESIGN 5
2.1 Acasefor co—design .......................... 5
2.2 Methodology and Trends ....................... 7

2.2.1 Speciﬁcation .......................... 8
2.2.2 Architecture .......................... 8
2.2.3 Partitioning .......................... 9
2.2.4 Iteration Between HW/SW ................. 10
2.2.5 Co-Design Tools .................. ' ...... 11
2.3 Embedded Systems .......................... 11
2.3.1 Speciﬁcation .......................... 12
2.3.2 Architecture .......................... 13
2.3.3 Partitioning .......................... 14
2.4 Summary ............................... 15

3 THE POLIS SYSTEM 16

3.1 Introduction .............................. 16
3.1.1 Formal Model ......................... 17
3.1.2 The POLIS Design Flow ................... 20

3.1.2.1 Formal Speciﬁcation ................ 21

3.1.2.2 Translation ..................... 21

3.1.2.3 Co-Simulation ................... 21

3.1.2.4 Partitioning ..................... 22

3.1.2.5 Software Synthesis ................. 22

3.1.2.6 Hardware Synthesis and Prototyping ....... 23

3.1.2.7 Other Capabilities ................. 23

3.1.3 System Requirements For POLIS .............. 24
3.2 ESTEREL ............................... 25

3.2.1 Introduction .......................... 25

3.2.2 Language Features ...................... 25

3.3 PTOLEMY .............................. 28
3.3.1 Introduction............... ........... 28
3.3.1.1 The Graphical Interface .............. 29

3.3.1.2 The DE Domain .................. 29

3.4 Summary ............................... 3O

STEPPER-MOTOR CONTROLLER USING POLIS 32

4.1 Introduction .............................. 32
4.2 A Basic Stepper-Motor ........................ 33
4.3 Functionality of the MC33192 .................... 34
4.3.1 MI Bus controller ....................... 34
4.3.1.1 Motor driver .................... 35

4.4 Speciﬁcation in Esterel ........................ 36
4.4.1 Level 1 : External Interface ................. 36
4.4.1.1 Inputs ........................ 36

4.4.1.2 Outputs ....................... 37

4.4.2 Level 2 : System Modules .................. 37
4.4.2.1 TIMER module ................... 37

4.4.2.2 BUS module .................... 38

4.4.2.3 PROGRAM module ................ 39

4.4.2.4 CONTROL module .......... ' ...... 39

4.5 Compilation .............................. 40
4.6 Fltmctional simulation in Ptolemy .................. 40
4.6.1 Hardware/ Software mapping ................. 42
4.6.2 Software Synthesis and the RTOS .............. 43

4.7 Summary ............................... 44
THE MC33192 IMPLEMENTATION 46
5.1 Introduction .............................. 46
5.2 Main Features of the M033192 ................... 47
5.2.1 MI Bus Protocol - Message Format ............. 48
5.2.2 Message Coding ........................ 49
5.2.3 Address Programming .................... 49
5.2.3.1 Step 1 ........................ 50

5.2.3.2 Step 2 ........................ 50

5.2.3.3 Step 3 ........................ 50

5.2.4 Overwrite-bit Programming ................. 50
5.2.4.1 Step 1 ........................ 50

5.2.4.2 Step 2 ........................ 51

vi

5.3

5.2.5

Motor Control .........................

Implementation of the MC33192 ...................

5.3.1
5.3.2
5.3.3

Hardware Setup ............ _ ............
MC33192 Software ......................
Software design ........................
5.3.3.1 Intialization .....................
5.3.3.2 Timer Interrupt ...................
5.3.3.3 Main .........................

5.4 Summary ...............................

6 RESULTS, ANALYSIS AND CONCLUSIONS

6.1 Introduction ..............................
The MC33192 implementation ....................
The POLIS implementation .....................

6.2
6.3

6.4

6.5

6.3.1

Ptolemy simulations .....................
6.3.1.1 Functional Veriﬁcation ...............
6.3.1.2 Timing Analysis and HW/ SW partitions .....

Analysis ................................

6.4.1
6.4.2
6.4.3

Background ..........................
Co-simulation .........................

The SMC system .......................
6.4.3.1 Timing behavior ..................
6.4.3.2 Hardware or Software ......... ‘ ......

Conclusions ........................... ’ . . .

7 RECOMMENDATIONS FOR FUTURE WORK
8 APPENDIX

vii

51
52
52
53
53
53
54
54
56

61
61
62
63
63
64
64
67
67
68
69
70
73
74

75
76

Chapter 1

INTRODUCTION

Conventional system design methods involve speciﬁcation of hardware and soft-
ware separately, requiring a pre—design partition into hardware and software. The
integration of the hardware and software is pushed toward the downstream of
system design. Since problems during testing or speciﬁcation changes can only
be corrected by expensive redesign, this leads to time-to—market and cost glitches.
Hardware-software co-design tries to address such problems by the use of a com-
bined or uniﬁed representation of the system, complemented by co-synthesis, co-
veriﬁcation and co-simulation of the system operation across the hardware and
software boundaries. Co—design could address systems with mixed hardware-
software speciﬁcations, or a general system speciﬁcation. In any case, the co-
design ﬂow includes system level simulation, hardware-software performance and
partitioning issues.

Typical application areas of embedded systems include consumer electronics,

telecommunications applications, automotive controllers, safety critical plant or
medical instrumentation, listed in increasing order of criticality. All such sys-
tems contain a CPU running software with application-speciﬁc functionality, with
interfaces to the environment, external hardware and in some cases other supervi-
sory software on a real-time basis. These considerations make it necessary to deal
with system level design issues rather than superior computing perfomance [1];
consequently, hardware-software co—design is the only alternative.

This thesis aims to understand the motivation for hardware-software co-design,
explore available tools for co-design, demonstrate the co-design methodology for
an embedded system application, and present the results of the implementation.

POLIS [2], a hardware-software co-design environment for control-dominated
embedded systems, was selected as the design tool due to its relevance to the
stepper-motor controller application, and its availability. The POLIS preferred
speciﬁcation language ESTEREL and the simulator PTOLEMY were used for the
design. A software version of the stepper motor controller was generated using
these tools and after synthesis and simulation, was tested on the 68HC11 micro-
controller. Simultaneously, the hardware implementation of the stepper-motor
controller using the MC33192 was set up and the results of the two approaches

are presented.

1.1 Objectives

The main goal of this thesis was to demonstrate the hardware-software co—design
methodology for a stepper-motor controller and establish a set of design criteria
for system speciﬁcation, architectural design, and hardware-software partitioning
to facilitate the co—design process. Towards this end, some speciﬁc objectives were
involved and these are brieﬂy described below.

The relevance of hardware-software co-design for embedded systems was to
be studied. Existing methodologies for hardware-software co—design were to be
examined. A suitable co—design environment was to be chosen and used for the
purpose of the implementation. The hardware implementation using MC33192
was to be realized and compared to the co-design implementation. The co-design
flow used in the project was to be presented, along with insights gained into system
design, hardware-software partitioning and typical trade-off issues. Current trends

and issues in hardware software co-design were to be presented.

1.2 Outline

This thesis is organized into seven chapters, beginning with this introductory
chapter. This chapter is followed by an overview of hardware software co-design
in general and embedded systems in particular. The next chapter describes the

co-design environment and design ﬂow used for this project, namely POLIS and

its associated tools. The following chapter, chapter 3, deals with the software
implementation of the stepper-motor controller using the co—design environment.
The next chapter describes the hardware implementation, using the MC33192.
Chapter six presents the results of both the approaches. The next chapter dis-
cusses the analysis and conclusions of the entire project while the ﬁnal chapter

presents some recommendations for future work.

Chapter 2

HARDWARE-SOFTWARE CO-DESIGN

2.1 A case for co—design

Traditional system design follows a sequential approach, called the ”waterfall”
model [9]. The design process begins with a system speciﬁcation, (which may be

simply the functional requirements of the system). Partitioning of hardware and

software is done at this stage itself.

 

 

 

 

 

 

 

Software ﬁxes .

 

 

 

 

System

 

 

Speciﬁcation

 

 

 

 

 

 

Software Build
Speciﬁcation Software

Hardware Build
Speciﬁcation Hardware

 

 

‘

 

l

 

HW/SW
Integration &'

 

Test

 

 

[\

 

 

 

 

 

(Long lead time)

     

No

' equiremen Yes
et?

 

 

Build
hardware

 

 

Figure 2.1: Traditional Method Of Design

 

 

Figure 2.1 [9], illustrates this approach. Designers try to map most of the spec-
iﬁcation to software, and use hardware only for timing and other constraints. Once
this is done, as shown in the ﬁgure, the design process forks into two independent
paths, one for hardware speciﬁcation and design, and the other for software. This
amounts to sending the hardware and software designers to separate work areas,
with little interaction between them, until each team is ready with their product.
Intuitively, this is a ludicrous beginning for the next design step, which involves
integration and testing of the two products into the overall system.

Current-day digital applications involve increasingly complex systems, and
contain both hardware and software components sometimes on a single chip.
These components often include programmable microprocessors, ASICs and hard-
wired devices or FPGAs. The market is highly competitive, ever increasing the
pressure to decrease time and cost of product design. With this scenario, the

traditional method suffers from obvious drawbacks, including the following.

o The pre—design partitioning of the system into hardware and software compo-
nents prevents optimization of the design by exploring alternative partitions.

0 Until integration and test, incompatibilities between the hardware and soft-
ware portions cannot be found.

0 Since hardware changes are not only expensive but also take time, only
software alternatives may be explored to ﬁx errors.

0 Since problems are discovered late in the design phase and cannot be ﬁxed
completely merely by software modiﬁcation, the resultant product is far from
optimal and may not meet the speciﬁcation.

In other words, we require a concurrent and not a sequential method of hardware-

software design as shown in the Figure 2.2 [9]. This is commonly called co-design,

6

 

Hardware/software ﬁxes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

   

No
[ v V] Y
es .
System ; Architecture HWISW Requirement Bu‘ld
Speciﬁcation mapping met? hardware

 

 

 

 

Figure 2.2: A Concurrent Method Of Design

and could be deﬁned in many ways depending on the application. The key con-
cept underlying these deﬁnitions is, however, “developing hardware and software
concurrently”; (Hugo De Man in [11], Vijay Nagasamy in [10]) and “facilitating
communication between hardware and software teams” (Karl Van Rompaey in
[11]) This also means that hardware and software branches of specialization es-
sentially overlap [1], and [12] and requires cultural shifts in design methodologies;

however, we restrict ourselves here to the. co-design methodology itself.

2.2 Methodology and Trends

Having decided that co-design is a very desirable methodology, we now describe a
general approach for hardware-software co-design, which may vary, according to
the application.

For this purpose, the co—design methodology is broadly decomposed into four
major tasks [3]. These are, system speciﬁcation, architectural design, hardware-
software partitioning and iteration between hardware and software. The co—design

process is complemented by co-simulation and co-veriﬁcation which precede the

ﬁnal implementation. An overview of these tasks is presented here for the general

case. The next section deals with the speciﬁcs for embedded systems.

2.2.1 Speciﬁcation

The functional requirements of the system are speciﬁed as the ﬁrst step. The ideal
case is to be able to arrive at architecture-independent speciﬁcations, for maximum
ﬂexibility during implementation. However, depending on hardware or software
components involved in the system, the speciﬁcation could deal with different
levels of abstraction. The key is the uniﬁed speciﬁcation of the entire system,
using a suitable modelling mechanism. This is the subject of extensive research,
and different techniques, models, and speciﬁcation languages are continuously
emerging both commercially and among research communities. SOme of these are
extended versions of C, extensions of HDLs [11], formal speciﬁcation languages
[8], [13] and [14] and recently, a uniﬁed co-design language or the CDL [15].
(Others are LOTOS and SDL for communication protocols, CSP and OCCAM
for concurrent systems, StateCharts for real time systems, C, C++ and ADA for

programming, SpecCharts for mixed hardware-software systems and so on).

2.2.2 Architecture

Architectural design may be inﬂuenced by the current application, available re-

sources, or other constraints. The hardware architecture may contain one or more

processing units, memory subsystems, application-speciﬁc hardware blocks, (IP or
intellectual property blocks) and other programmable hardware. The designer’s
job is to select an appropriate combination of such components, for the required
functionality. Some tools which automate this process using cost and size param-
eters generated for the given functionality can be found in [16], [17], [19], [20],

[21].

2.2.3 Partitioning

In general,the system speciﬁcation is modelled as tasks or processes [19], interact-
ing with each other. The partitioning step assigns each of these processes to hard-
ware and software components available from the previous step. The main issues
involved here are the granularity or abstraction of these processes, inter-process
communication, and required concurrency. Different automatic partitioning algo-
rithms [18], [20], [22] are available, which are based on cost, size or performance
parameters estimated for the given hardware or software. In some cases, partition-
ing may be done manually, as in POLIS. The designer makes decisions based on
these parameters considering timing, performance and hardware-software cross-

coupling issues.

2.2.4 Iteration Between HW/ SW

The hardware-software partitioning process is an iterative one, till an optimal
design is achieved under the given set of constraints. Software offers flexibility,
while hardware may be essential for standard functionality or timing constraints.
Different hardware-software mappings of the system may give different results.

The path from the co—design process to the ﬁnal implementation of the system is
supported by co-simulation and co—veriﬁcation environments. These tools facili-
tate integrated simulation and veriﬁcation of the hardware and software compo-

nents of the system using various techniques.

Table 2.1: HW/ SW Co-Design Tools - A Summary

 

 

 

 

 

Name Category Application Platform Source
POLIS Research Design environment Unix POLIS Project
[2] Software for control- Cadence Berkeley
dominated embedded Labs
systems
Ptolemy Research Extensible block Unix Ptolemy Project
[25] Software diagram environment UCB

for signal processing,
communications and
and HW/SW co-design

 

Eaglei Commercial Virtual Systems Unix ViewLogicI
[28] integration tool Windows NT
for co-veriﬁcation

in Embedded systems

 

Statemate Commercial Graphical Simulation Unix i-Logix Inc
[14] and software synthesis Windows NT
tool for rapid
development of
embedded systems

 

 

 

 

 

 

 

 

lFormerly sourced from Eagle Design Automation Inc.

10

2.2.5 Co-Design Tools

While different tools are available with different capabilities to support co-design,
these are domain-speciﬁc and often application-speciﬁc. Current research in the
area encompasses different aspects of hardware-software co—design from speciﬁ-
cation languages to computational models to automatic partitioning tools. The
Table 2.1 provides a brief look at some of the developmental and commercial tools
available for co-design. Details relevant to embedded systems are presented in the

following section of this chapter.

2.3 Embedded Systems

The co—design methodology outlined in the previous section is described in de-
tail for embedded systems [3], [16]. An embedded system represents a reactive
system with a ﬁxed functionality and whose behaviour depends on its interaction
with its environment. Often such systems could be very complex, comprising of
software, ASICs, microprocessors, FPGAS and analog peripherals. Co-design al-
lows concurrent development of hardware and software, offering great reductions
of time-to—market compared to software development after hardware fabrication.

We discuss the co-design tasks from the previous section, as applied to embed-
ded system design using the example of an engine-control unit hereafter referred

to as ECU, from [24].

11

2.3.1 Speciﬁcation

Initially, the functionality of the system is speciﬁed. ' This is a set of system
requirements or the response of the system to inputs. In case of the ECU, the
function is to control the torque produced by the engine by timing the fuel injection
and spark, with low fuel consumption and low exhaust emission. The injection
time is computed by using air pressure, air temperature, throttle position, engine
speed etc. The ECU produces a suitable output to drive the actuators based on
this computation. We can thus divide the basic functionality into subtasks. This
functionality is mapped into modules by using a conceptual model [16]. This may
be done using various models like data ﬂow graphs or ﬁnite state machines(FSMs).
A description of this model is then generated by means of a speciﬁcation language.
At this point, the speciﬁcation does not reflect any implementation detail.

The choice of a model depends on the application. For instance, for a signal
processing application, a dataﬂow model might be suitable. The FSM model
may be more applicable to control-dominated systems. Software systems may
need to be modelled as communicating sequential processes or CSPs [16]. In
short, the model should be most appropriate for the characteristics of the system.
While embedded system applications are diverse, certain characteristics [1], [16]

are common among such systems.
0 Software with application-speciﬁc functionality
0 State transitions responding to inputs

0 Exceptions for interaction with environment or subsystems

12

o Concurrency

These characteristics require a F SM based model, extended into a model which
also provides for concurrency. [16] describes one such model, the PSM or a
program state machine model. The speciﬁcation language Esterel, used for this
thesis uses a model based on the CFSM or the co—design FSM, described in the
next chapter. Once a description is generated, the speciﬁcation is veriﬁed for

functional correctness.

2.3.2 Architecture

Typical embedded systems have complex architectures, consisting of different
types of processors and their peripherals, FPGAs, ASICs, and external sensors
or eleCtro-mechanical devices. Often, the design is incremental, using standard
hardware parts or reusable software [5]. The selection may be between 16-bit and
32-bit processors, interconnection schemes like buses, or available alternatives for
custom hardware. The criteria could involve both technical and commercial trade-
offs.

In our ECU example, we may use a 32-bit CPU which receives the analog
and digital inputs from the environment, and directly produces actuations in the
form of PWM outputs. While this may be an easy approach, timing requirements
may not be met. Alternatively, we might use a 16-bit CPU and an FPGA which

produces the actuations. The third option may be to use a DSP to process inputs,

13

and an 8-bit CPU which computes the outputs and and F PGA which controls the

actuators [24].

2.3.3 Partitioning

As mentioned previously, the partitioning task involves the allocation of architec-
tural components to the functional operations. At this stage, co—simulation of the
partitioned design can help in performance analysis. Thus, if timing information
for a processor is available, then, the performance analysis can indicate whether
the design can meet all the system requirements. The advantage of co—design is
that flaws can be detected at this stage itself, and necessary re-partitioning or
even re-design can be done.

Once again coming back to our ECU, partitioning may be dictated by one of
several criteria. For instance if a variable is deﬁned in the DSP, while a function
using that variable is deﬁned in the CPU, we need to design a suitable interface or
bus for this purpose. Instead, it might be easier to deﬁne both the variable and the
function in the CPU. Another example would be whether we assign some of the
data processing functions to the CPU or use it only for computation. This choice
may be dictated by the processing power available or the speed of computation
required. As described in the previous section, this process is iterative. The
design is then synthesized to generate software code and hardware netlists. The

ﬁnal stage of the design is the physical implementation using prototyping and

14

testing.

2.4 Summary

In this chapter, several important issues concerning hardware-software co-design
have been discussed. The need for co—design is established. A general methodology
for co—design has been described. A brief overview of existing tools and methods is
presented. We then discussed the co—design methodology speciﬁcally for embedded
systems.

However, hardware-software co-design is also riddled with some inadequacies.
The foremost of these, is the fact that co-design techniques tend to be application-
speciﬁc and diverse. No industry standard has emerged yet and the ﬁeld abounds
with speciﬁcation languages, co-simulation and co-synthesis environments and ver-
iﬁcation methods. In other words, there is no universal solution [3]. This presents
a challenge for designers both in terms of the choices to make, and also the required
learning curve for changing technologies.

For this thesis, we have chosen the POLIS co—design methodology, due to its
suitability for control-dominated applications. In addition, the POLIS system cou-
pled with the PTOLEMY simulation environment provides a platform for system
level design right from speciﬁcation to ﬁnal implementation. In the next chapter,
we describe each component of the POLIS co-design environment, for performing

each of the co—design tasks outlined here.

15

Chapter 3

THE POLIS SYSTEM

3.1 Introduction

POLIS is a co—design environment for control-dominated embedded systems and
has been freely available on the internet since 1996. The software was created
after almost a decade of combined effort by Magneti Marelli, a major EurOpean
producer of automotive electronics, the University of California Berkeley, and
many others [2]. The motivation for the POLIS project was to ﬁnd solutions for

challenges facing the embedded system industry, some of which are listed here [5].

0 Formal customer speciﬁcations allowing changes during design
0 Use of high level languages for software design

0 Hardware-software co—design and co—simulation instead of bread-boarding
for veriﬁcation

0 Design reuse

16

Embedded systems have to deal with changing product speciﬁcations, and simul-
taneously attempt to lower the design costs, while trying to reduce the time-to-
market. In order to achieve these objectives and address the issues listed above,
the POLIS project was conceived and implemented.

This chapter describes the POLIS co-design environment, including the Esterel
speciﬁcation language and the Ptolemy simulation environment. We begin with a

description of the formal model used in POLIS, for system speciﬁcation.

3.1.1 Formal Model

As discussed in the previous chapter, we require a formal model to specify the
system. This model is called the CFSM or the Co-Design Finite State Machine.
It is based on extended ﬁnite state machines, with a ﬁnite set of variables. Each
functional module of the system is mapped to a CFSM. The CF SM speciﬁcation
is implementation-independent, and could represent either hardware or software
components. Figure 3.1,shows the CF SM speciﬁcation of a simple example taken
from the POLIS users manual [4]. The operation of the CF SM is described later
in this section.

In a CF SM, the states of the internal variables as well as the outputs, are
updated by state transitions. The result of the transition is propagated to other
CFSMs or the environment. The communication between CFSMs is not by shared

variables, but by events. The authors of POLIS [5] call the model “globally asyn-

17

chronous and locally synchronous.” This characteristic allows for the speciﬁcation
of systems consisting of hardware and software components, which exhibit asyn-
chronous communication.

POLIS uses an intermediate language called SHIFT, (Software Hardware
Interchange FormaT) to represent CFSM networks and the individual CFSM
behavior. The designer can specify the interconnecting netlist between CFSMs
graphically by using Ptolemy or by a textual netlist ﬁle.

Events are emitted by CF SMs or the environment by means of data or control
carriers called signals. The events are detected by one or more CFSMs. As events
are not buffered, the designer needs to take explicit measures in order that events
are not overwritten if transmitting and receiving CFSMS have different speeds.

These can be handshaking mechanisms, partitioning and scheduling choices.

 

key_on/
start_timer

    
   

key_off or
key_onl
alarm(0)

Figure 3.1: CFSM For Seat Belt Alarm

 

 

 

The Figure 3.1 shows the CFSM speciﬁcation for an automobile seat belt
alarm function. Five seconds after the key is on, an alarm is sounded if the seat

belt is not fastened. The alarm beeps for 5 seconds or until the key is off or belt

18

is on. The transition labels use the “/” to separate the stimulus and reaction.
This speciﬁcation can be expressed in a high level speciﬁcation language with
CFSM semantics, in this case Esterel. The Esterel speciﬁcation for this CFSM is
described later in this chapter. The next section describes each step of the POLIS

design ﬂow.

19

3.1.2 The POLIS Design Flow

 

 

[Formal Languages]

[System Behavior ]

 

 

 
 

 

   

imulation

enﬁcatio
[ Partitioned Speciﬁcation
t « ace
thesis
@5an —
\
[UnoptimizedI-IW] [ memmJ Eeriflntermformal]

Task Synthesis

   

 

er
Template
Timing
Constraints

 

 

     
 

 

 

 

 

 

 

 

Logic Synthesis

 
   
   
 

 

 

 

 

[OptimiszedI-IW]

 

Partitioning
l
[ Optimized HW ]

BOARD LEVEL PROTOTYPING .

[ physical Prototype ]

 

[ Standard Components ]

 

 

 

 

 

 

Figure 3.2: The POLIS Design Flow

The Figure 3.2 from [4] depicts the various design steps involved in the POLIS
methodology. These individual steps are described in the following paragraphs.

We begin with a formal speciﬁcation of the system.

20

3.1.2.1 Formal Speciﬁcation

Designers specify the system using a high level language with extended FSM
semantics, in this case, Esterel. (Other such languages could be StateCharts [6],
and the so called synthesizable subsets of VHDL or Verilog. ) An example of such

a speciﬁcation is described later in the section on the Esterel language.

3.1.2.2 Translation

The Esterel ﬁles with extension .strl are translated to SHIFT format using the
strl2shift translator. The input ﬁles describe the CF SM behavior and auxiliary
information like type and constant deﬁnitions. The output contains the .shift
ﬁles for the entire system and .cfsm ﬁles for individual CFSMs. The SHIFT
ﬁles are hierarchical netlists containing blocks which can be CFSMS, functions
or other netlists, and describe the signals between communicating CFSMs. More

information about SHIFT can be found in [29] and [30].

3.1.2.3 Co-Simulation

The generated ﬁles are input to POLIS which creates synthesized C code to model
all the system components, independent of their ﬁnal implementation. (The P0-
LIS design ﬂow is managed using UNIX makeﬁles, allowing ease of use.) The
co—simulation framework uses this C code as the basis. The Ptolemy simulator is

used for this project. (A VHDL simulator could also be used [4].) Initially, a func-

21

tional simulation is performed to ﬁnd and ﬁx bugs. Then, a clocked simulation
can be run with approximate timing. The co—simulation depends on the mappings

obtained by the software synthesis step, which is done after partitioning.

3.1.2.4 Partitioning

The next step involves partitioning the design, i.e., mapping individual compo-
nents, or CFSMs, to hardware or software. This can be iterative and uses the
same user interface as co-simulation. Any number of alternative partitions can be

tested.

3.1.2.5 Software Synthesis

The software CFSMs are mapped to software structures including CFSM proce-
dures and an RTOS(Real-Time Operating System). The synthesis is performed
in two steps.

0 First, the CFSM behavior is represented using an S-graph or software-graph,
which is similar to a control /data flow graph.

0 Then, the S-graph is translated into portable C-code.

This C-code is Optimized in a speciﬁc micro-controller-dependent instruction set
using a suitable compiler. In addition, a timing estimator provides estimates of
program execution times on a selected target processor.

The RTOS is application-speciﬁc, with user-selected scheduling algorithms.

Hardware-software interfaces in the design are automatically synthesised as part

of the RTOS by POLIS.

22

3.1.2.6 Hardware Synthesis and Prototyping

CF SMs selected for hardware implementation are mapped into abstract hardware
description formats like BLIF(Berkeley Language Interchange Format), VHDL,
or XNF (for implementation on FPGAs). A physical prototype of the system
can be obtained using the .xnf ﬁles and Xilinx FPGAs. Since a software version
is implemented for this thesis along with a hardware implementation using an

existing chip for a stepper-motor controller, this facility is not used for this thesis.

3.1.2.7 Other Capabilities

o POLIS also facilitates formal veriﬁcation through a translator from CFSM
networks to synchronous classical FSM networks, for input to formal veriﬁca-
tion algorithms. The system recommended by POLIS is VIS or Veriﬁcation
Interacting with Synthesis [7], from the University of California at Berkeley.
This project does not include formal veriﬁcation.

o POLIS offers some support or use of micro-controller peripherals like timers
and A/ D converters. The currently supported micro-controllers are the Mo-
torola 68HC11E9 and 68HC11gauss.

23

3.1.3 System Requirements For POLIS

Table 3.1: System Requirements

 

Package

Availability

Disk space

 

POLIS 0.3
[2]

Sun 084
Solaris 2
DEC Alpha
PC Linux

20-50Mb

 

Ptolemy 0.7
[25]

Solaris 2.5

HP-UX and others
Linux1

(with X-windows)

350Mb

 

Esterel v5

[8]

 

 

Sun solaris
DEC

Sun 084
IBM AIX

 

25-30Mb

 

Table 3.1 summarizes the system requirements for the POLIS system including
Esterel and Ptolemy. For this project, all the software was installed for Sun solaris
2.5. All the above packages can be freely downloaded from the world-wide web.

In the next section, the Esterel speciﬁcation language is described and the CFSM

example mentioned before, is discussed in detail.

 

1Binaries contributed by others

24

 

3.2 ESTEREL

3.2.1 Introduction

Embedded systems could be classiﬁed under a class of computerized systems called
“reactive systems”. They continuously react to external stimuli from the environ-
ment and their response is mainly input-driven. Further, the output values could
be continuously produced from the inputs, as in signal processing applications.
This is called “data handling”. On the other hand, producing discrete output sig—
nals from input signals is called “control handling”. The stepper-motor controller
system falls under the category of control-dominated systems.

Esterel [8] is a speciﬁcation language aimed at the control-dominated compo-
nents of reactive systems. Esterel affords a concurrent programming environment
required for reactive systems, as they interact concurrently with the environment

and are often made of concurrent modules communicating with each other.

3.2.2 Language Features

In a sequential program, an output is produced after some computation using the
input data. The programmer speciﬁes the order in which the program statements
are executed. However, this model is inadequate for reactive systems, which ex-
hibit real-time interaction with the environment, where input/ output sequencing

is important.

25

Esterel is based on a synchronous model, which accomodates this requirement,
where the program reacts instantly or synchronously with the input. This model
results in a distinctive language style for Esterel, involving timing concepts, and a
deterministic behavior. (A deterministic program produces the same output given
a particular input any number of times.)

In Esterel, signals are called events, which can be emitted and detected. An
output event is the status of an output, computed from a given input event,
which is the status of the input. These events are communicated in Esterel, by
“broadcasting.” This means, in a system with several modules, the emission of any
event is available to any module which is interested in that event. The emitting
module need not have information about the receivers. Thus, an event need not
be replicated in the system. This “broadcast semantics” distinguishes Esterel from
languages like VHDL.

Although Esterel concurrent modules are synchronous, as POLIS semantics
are globally asynchronous, there is a difference between the two. In POLIS, syn-
chronous behavior is available only till the boundary of a single CF SM. Composi-
tion of CFSMs is asynchronous.1

The basic programming unit in Esterel [27] is a module, with an interface
declaration and a body. The language has a host of useful constructs including
signal handling, looping, control statements, parallel constructs, and a wide variety

of temporal constructs. Esterel supports external functions in two host languages,

26

namely C and Ada. C functions were used for this thesis. Since it is not possible
to treat the entire language syntax here, the following example from [4] is used to
give an introductory idea to Esterel. The module listed here, essentially performs
the seat-belt alarm function, which was represented by a CFSM in the previous
section. The end_5 and end_10 signals are received from a timer module and

indicate end of the 5 second and the 10 second intervals.
module belt_control:
input reset, key-on, key.off, belt.on, end_5, end-10;
output alarm: boolean, start_timer;
loop
abort
emit alarm(false)
every key-on do
abort
emit start_timer
await end-5;
emit alarm(true);
await end_10;
when[key-off or belt_on];
emit alarm(false);
end every
when reset
end loop

The speciﬁcation consists of an interface declaration and the body of the mod-
ule. The interface consists of inputs, outputs, constants and any external func-
tions. In this example, all the inputs except alarm are pure signals, i.e., they do
not have an associated value. The alarm signal has an associated true or false
value. This module is executed as a continuous loop which is restarted when-

ever a reset signal is received. The await construct is one of the many temporal

 

1As a result of this, certain features of Esterel cannot be used in POLIS. Some of these are
discussed in later chapters.

27

constructs offered by Esterel.

3.3 PTOLEMY

3.3.1 , Introduction

Ptolemy [25] is a software environment supporting the design of reactive systems
using heterogeneous modelling, and was deveIOped at the University of California,
Berkeley. Ptolemy provides support for heterogeneous prototyping of systems in
areas like signal processing, communications and real-time control applications
among others. The key principle is the use of mixed models of computation,
realized by a specialized design style called domain, including synchronous data-
ﬂow (SDF), dynamic data-ﬂow (DDF) and discrete event (DE) models, the ﬁrst
two being used mainly for signal processing, and the last for communications and
control applications [26]. Some other domains are also supported. These domains
could be used for simulation or code generation. We ﬁrst describe the Ptolemy
user-interface and brieﬂy discuss the DE domain, which is used in POLIS for

co-simulation.1

 

1Apart from Ptolemy, the POLIS documentation describes the use of commercial VHDL
simulators or software simulation [4]

28

3.3.1.1 The Graphical Interface

The Ptolemy interactive graphical interface or pigi is a design editor for Ptolemy,
and allows the graphical construction of designs by connecting icons. This is based
on uem, a graphical editor for act, which is the Ptolemy design manager.

Each domain consists of a set of blocks, targets and associated schedulers. A
design is represented as a network of blocks. These blocks can communicate
through portholes [26]. These blocks could be hierarchical, called stars, galaxies
and universes from the lowest to the highest level. A target manages the simulation
or execution of the block, and is derived from the block. The simulation performed
by the target is governed by a scheduler which controls the sequencing of the
execution of functional modules in the design.

The pigi editor provides palettes containing icons for design blocks and enables
the user to create a graphical netlist or schematic for a particular design using
the icons. A target is generated for each design, which can then be graphically
simulated with several debugging options.

Screen snapshots showing some of the available icons are included in the Ap-

pendix.

3.3.1.2 The DE Domain

In the DE domain, the events produced by the blocks, which correspond to a

change in the system state, are represented by particle. The events are processed

29

by the schedulers in the order of their chronological occurence. Each event has
a corresponding time stamp. The DE domain is useful for high level system

modelling and contains the following sets of stars.

0 Sources : They generate signals and can be used to represent external inputs
to the system. They include buttons, clocks, and various signal and function
generators.

o Sinks : These correspond to system outputs and include text ﬁelds, graphs,
and interactive displays.

0 Control : These stars manipulate interconnections, and include forks, merges
and switches.

0 Conversion : They include type conversion stars of integer to ﬂoat and vice
versa.

0 Queues, servers, Delays : Include delays and stacks.
0 Timing stars : These include delay measuring and time-stamping functions.

0 Logic stars : As the name indicates, these stars perform logical operations.

In addition, networking and miscellaneous stars are also available. Several
menus are available in the graphical editor for design and simulation. The same
menu commands can also be typed from the vem editor. Details of the commands

and the functionality can be found in the Ptolemy users manual [26].

3.4 Summary

In the current chapter, the POLIS hardware-software co-design environment has

been described in detail. The main features of the Esterel speciﬁcation language

30

and the Ptolemy simulator have been discussed. A brief overview of the system
requirements for the software is also presented.

In the next chapter, the stepper-motor controller implementation in software,
using POLIS is described. As mentioned earlier, the functionality of the MC33192
hardware chip is replicated in software as far as possible, using the hardware-

software co-design methodology of POLIS.

31

Chapter 4

STEPPER-MOTOR CONTROLLER USING

POLIS

4.1 Introduction

As discussed before, the ﬁrst step in the design process is the system speciﬁcation.
Before we proceed to specify the system in Esterel, we need to understand the
functionality of the system. Then we proceed to divide the functionality into
suitable modules to be translated to Esterel. Thus, we describe the functionality
of the MC33192 and show how we adapt the same to our speciﬁcation. Then, the
rest of the implementation procedure is described. We begin with the operation
of a basic stepper-motor, described in the next section, to provide the necessary

background.

32

4.2 A Basic Stepper-Motor

Stepper motors are very popular in computer-controlled systems as they eliminate
the need for feeding back positional information. The power source of the stepper
needs to be continuously pulsed in speciﬁc patterns which determine the speed
and direction of a stepper’s motion. The motor consists of stator pole pieces and
a rotor shaft. The motor Operation is achieved by switching the magnetic ﬁeld of
the stator coils causing the magnetic rotor to rotate based on the direction of the
magnetic ﬁeld. Depending on the number of stator coils, the rotation steps of the

rotor and consequently the angular frequency can be controlled.

 

H§ Q i8
y [so

 

 

 

Figure 4.1: Bipolar Stepper Motor

The Figure 4.1 shows a stepper motor which can have ﬁfteen degree increments
in motion by suitably wiring the stator pole pieces and switching their polarities.
Depending on the number of the segments, very small angular movements of 0.7
to 1.8 degrees are obtained in practical applications of stepper motors. Because

of this ﬁxed stepping angle, the position of the motor can be known at any given

33

time without feedback. This is the main advantage of stepper motors over other
dc motors whose position can only be determined by using shaft encoders.

The MC33192 chip is a stepper-motor controller suitable for driving bipolar
two-phase motors. In particular, the MC33192 has applications in automotive
control systems and is suitable for controlling loads in harsh environments using

the MI bus [31]. The functionality of the chip is described next.

4.3 Functionality Of the MC33192

For the purpose of this implementation, the objective is to duplicate as many
functions as possible from the MC333192. Our speciﬁcation will then reﬂect this
functionality.

The MC331921 [31] is a serial stepper-motor controller which can be controlled
by a master micro-controller MC68HC11, hereafter called the MCU, through the
MI bus. The MC33192 sub-systems can be broadly classiﬁed into two main units,

namely the MI bus controller unit and the motor driver unit.

4.3.1 MI Bus controller

This module deals with the push-pull communication sequences with the MCU
and acts as the interface between the MI bus and the motor driver. The signal

from the MCU consists of ﬁve data and three address bits and may be program-

 

1Data sheet attached in Appendix

34

ming or control instructions. Programming could be address or overwrite bit
programming.

Control instructions include full step or half step modes of the motor, and
clockwise and counter clockwise direction. Full step is achieved by energizing both
coil bridges in the motor driver circuit, while half step is achieved by energizing
only one at a time. The motor direction can be changed by reversing the coil

current direction. The bus controller functions are brieﬂy listed here.

0 Listen on the MI bus
0 Convert the serial input signal to parallel

0 Follow programming or control instructions from the MCU and send a suit-
able signal to the motor driver.

0 Convert the status signal from the motor driver to serial

0 Transmit the status output signal

In addition to this, the bus controller also performs noise and biphase detection
of the input signal received from the MCU. So far, these functions have not been

duplicated in software.

4.3.1.1 Motor driver

Depending on the instruction received, the motor driver sends a status signal to
the MCU through the bus controller and outputs to the two motor coils. The
status signal could indicate the following.

0 Normal Operation
0 Programming

0 Selection Failed (the MC33192 could not be selected)

35

In addition, the status signals include two diagnostic signals for thermal and

back emf status. This functionality has not yet been incorporated.

4.4 Speciﬁcation in Esterel

The functionality described in the previous section was speciﬁed using the Esterel
speciﬁcation language. Initially, the external interfaces of the entire system were
deﬁned. This is the ﬁrst level of abstraction. Then, the required functionality
was divided into suitable modules, and the interfaces of each of the modules were
determined, for the second level. This is described here, along with assumptions
made whenever required. The system is called SMC, for stepper-motor controller.
(Whenever inputs or outputs are indicated without a data type next to them, they

are pure signals, which carry no value.)

4.4.1 Level 1 : External Interface
4.4.1.1 Inputs

The MCU sends programming and control instructions to operate the SMC. Pro-
gramming instructions include address programming, and overwrite bit program-
ming. Control instructions can be direction control, and half step or full step
instructions. These instructions are all sent through the MI bus interface. The

M1 bus mode is determined by bus voltage levels which are also inputs to the

36

SMC.

4.4.1.2 Outputs

The SMC communicates status codes to the MCU in response to the corresponding

MCU instructions. The SMC also provides drive signals to drive motor coils.

4.4.2 Level 2 : System Modules

The system is modularised based on each of the functions that it performs. These
may be subsequently combined if found necessary.

The functionality of the SMC considered here, excludes noise and biphase
detection. The remaining functions are described below as modules. As before,
the interface of each module, i.e., the inputs and outputs of each module are listed
and described brieﬂy. Additional signals which are used for debugging purposes

only, are listed in the Appendix, but not repeated here.

4.4.2.1 TIMER module

This module generates the timeslots required for the MI bus protocol. Commu-
nication on the MI bus is performed by the MCU by sending data in a speciﬁc
format, with each bit being coded, and sent in a ﬁxed time slot of 25 micro seconds.

The timer module generates a signal at the end of each interval.

0 Inputs

Esterel has no physical time attributes. However, we use a millisecond time
unit generated by an absolute clock, provided by Ptolemy. This input is fed

37

into a 68HC11 free-running counter(frc), as the ECLK signal. Then, the
count signal is received by a 68HC11 output-compare(oc) unit, which pro-
duces signals whenever required time is elapsed. These modules are available
as ready-to-use stars from the Ptolemy palette as 68HC11 peripherals. The
oc unit receives a start time value from any other module, awaits the time
delay and emits an output.

input ECLK, OC3_START(integer) (We use the output compare unit 3 of
the 68HC11.)
o Outputs

The ac unit receives a start time value from any other module, computes
the time delay and emits an output.

output OC3.END

4.4.2.2 BUS module

This module manages the communication between the MCU and SMC and con-
tinuously watches the time and the bus voltages. For duplicatingthe serial signals

from the MCU, we use a parallel-to—serial converter function.

0 Inputs

Depending on the MODE signal, the SMC is in programming or control
mode and accordingly the bus module receives status signals from the re-
spective modules. The BUS_SIG input determines the bus level.

input OC3.END

input MODE (boolean)

input PROGRAM-STATUS(integer)
input CONTROLSTATUSﬁnteger)
input BUS_SIG(boolean)

input RESET

0 Outputs

The PULL_FIELD value corresponds to the status signal transmitted to
the MCU. The o.BUS.SIG is the bus level transmitted to the MCU. The

38

PROGRAM-CODE and CONTROL-CODE signals are transmitted to the
program and control modules respectively.

output OC3.START(integer)
output PROGRAM-CODE(integer)
output CONTROL-CODE(integer)
output PULL.FIELD(integer)
output oBUS.SIG(boolean)

4.4.2.3 PROGRAM module

This module calls a C function to perform either address or overwrite bit program-
ming. As mentioned before, this module receives the PROGRAM_CODE signal

from the bus module and returns the PROGRAMSTATUS.

0 Inputs input PROGRAM.CODE(integer)

o Outputs output PROGRAMSTATUSGnteger)

4.4.2.4 CONTROL module

This module calls a C function to perform control operations based on MCU
inputs. Control Operations can proceed only when programming is done. As in the
case of the program module, the control module receives the CONTROL-CODE

and returns the CONTROLSTATUS to the bus module. In addition, the control

module also generates four motor output signals.

0 Inputs
input CONTROLCODE

39

o Outputs

output CONTROLSTATUSOnteger)
output MOTOR-COIL.A1(integer
output MOTOR-COIL_A2(integer)
output MOTOR-COIL_Bl(integer
output MOTOR-COIL.BZ(integer)

4.5 Compilation

The complete Esterel ﬁle listings for the project are attached in the Appendix.
The ﬁles were compiled using the strl2shift command and input to POLIS. The
shift ﬁles are read into POLIS using the read_shift command. Then, the build_sg
and the sg_to-c commands build the software graphs (S-graphs) and synthesize
the C-code respectively. The write_pl command is used to generate the Ptolemy
simulation ﬁles. These commands can be given in POLIS manually or one can
use unix makeﬁles with suitable macros. The makeﬁles are convenient to use

especially for large projects.

4.6 Functional simulation in Ptolemy

The .pl simulation ﬁles generated previously, are input to the Ptolemy environ-
ment. At ﬁrst, the pigi graphical editor is used to enter a graphical netlist of
the system, by instantiating individual modules and inter-connecting them. As

discussed before, the architectural hierarchy in Ptolemy is named with galaxies

4O

and stars, with a galaxy being the top most level. Thus in this system, we have
an SMC galaxy, comprising of the timer, bus, control and program stars in
addition to some ready-to—use Ptolemy stars for timing and other utility genera-
tion.

The testing of the galaxy is performed using a target of Ptolemy, created as
a test bed, containing signal sources, and various displays. Since the SMC is
designed for communication with an MCU, the schematic includes an mcu galaxy,
consisting of the following modules. The italicized terms will be used to refer to

these modules hereafter, for convenience.

o The men module mcu
o The OC2 timer (output compare 2) mcu timer
0 The bytein module for parallel to serial conversion ptos ‘

e The OC1 timer (output compare 1)ptos timer

The operation Of these modules is described in chapter 6, while presenting
simulation results and details. These modules comprise the driver for the SMC

software.

The schematics, or the graphical netlists are included in the Appendix, along
with simulation runs. For functional simulation, all the stars were mapped to
hardware and tested for an 8 MHz clock. The 68HCll peripherals used are the
free-running counter and the output compare unit 3. These stars are part of
the timer module. These modules are customized by selecting suitable Ptolemy
parameters like the clock pre-scaling factor of the timer counter. The simulation
is run in the debug mode and provides textual or graphical animation of the run.
The following steps describe the functional simulation procedure in detail.

0 Create the SMC schematic, by interconnecting the timer, bus, program and
control stars. These stars are created using the make star command in
Ptolemy. The timer stars, viz., frc and oc_prog_rel, corresponding to the

41

free-running counter and the output compare unit, are instantiated from
the POLIS-PERIPHERALS palette. Include the mcu galaxy, which in turn
contains the schematic of its component modules mentioned above.

0 Create the test_SMC universe, using the SMC galaxy, for the purpose of
running the simulation. Suitable sources and sinks are connected to the
galaxy in order to run the simulation and display the outputs. These are
chosen from the DE signals and sinks palette.

0 Enter all the parameters for each item, including “HW” implementation,
CPU clock, 68HC11 processor and Round.Robin scheduler. These screen
snap-shots are also included in the Appendix.

0 Verify the functional correctness of the simulation by testing the output
for various inputs. In the chapter 6, the test bench and the results of the
simulation runs are presented in a tabular form.

4.6.1 Hardware/ Software mapping

Ptolemy offers a convenient platform to perform functional simulations without
actually implementing a design, by mapping each module to hardware or software.
In the SMC design, it could be noticed that once the implementation was chosen as
software, the simulation slowed down. Also, the performance of the timer module
and the bus module improved substantially with the hardware implementation.
Thus, the simulation process provides a useful aid to the decision-making process
of choosing a hardware or software implementation of a given module.

Users can test the simulations for any number of implementations and choose
the most suitable one depending on performance and timing requirements. For
this project, since the implementation is in software, this step is not explored

further, and only test cases are presented in the results.

42

4.6.2 Software Synthesis and the RTOS

Once the simulation and design partition are satisfactory, the next step is to
translate the Ptolemy netlist into a SHIFT netlist. This is done using the ptl2shift
command. Alternatively, the makeﬁle can be modiﬁed suitably to generate this
ﬁle [4]. This shift ﬁle is read into POLIS, and synthesized into software graphs
(S-graphs) and ﬁnally C code.

An S-graph is a directed acyclic graph or dag with a set of vertices. It is
a processor-independent optimized implementation of the desired behavior and
is used for cost estimation in terms of execution time and code size, for a given
processor. Each vertex of this graph corresponds to a statement of the synthesized
C-code. The cost estimator appends the execution times against each statement
of the C-code. [4]

Then the gen_os command is used to generate application speciﬁc the real-time
operating system (RTOS). The RTOS consists of a scheduler and I/O drivers for
the design. For this project, as the target micro-controller is the 68HC11 on a
handy board, (described in the next chapter) the system setup ﬁles and hardware
initialization ﬁles in the POLIS libraries were customized accordingly. Parameters
which need to be modiﬁed include the memory map and I/O assignments. The
gen_os command offers suitable options to use modiﬁed versions of the library
ﬁles.

The steps involved in software synthesis and RTOS generation are described

43

in the following list.

0 Translate the Ptolemy netlist into a SHIFT netlist.

o Read the SHIFT ﬁle in polis.

0 Set the architecture to 68HCll. (These parameters are easily speciﬁed using
the makeﬁle.)

0 Use the timing and cost estimation commands in POLIS to generate cost
estimates for each module on the speciﬁed processor. This is useful if the
designer needs to choose between various processors.

0 The build-sg command is used to build the software graphs for each of the
modules. These are then converted to C-code using the sg_to-c command.
The C ﬁles are generated in the user speciﬁed directory.

0 The RTOS is generated using the gen_os. Each software CFSM results in a
software task. POLIS offers commands to customize the RTOS to implement
interrupt routines and conﬁgure I/ O ports for the target micro-controller.
The micro-controller peripherals used in the simulation are implemented as
initialization routines called by the RTOS.

o The ﬁnal step is to make executables for the target micro-controller. For
this project, the Introl compiler was used with the introl-compatible make

9 ﬁles generated by POLIS. The individual C ﬁles are compiled and linked
with the RTOS to make an executable for the 68HC11.

Since the SMC is entirely mapped into software, the hardware synthesis and pro-

totyping support in POLIS are not described here.

4.7 Summary

This chapter deals with the main focus of this thesis, which is the hardware-
software co—design methodology of POLIS as applied to the stepper-motor con-
troller application. To begin with, the speciﬁcation of the SMC was described

in detail, for the overall system and for the individual sub—systems. Then the

44

Ptolemy simulation procedure, and hardware/software mapping were discussed.
The previous section described the software synthesis step which involves many
hardware-speciﬁc steps, in this case for the 68HC11 micro-controller. The re-
sults of this implementation are presented in Chapter 6. In. the next chapter, the

implementation of the SMC using the MC33192 is described in detail.

45

Chapter 5

THE MC33192 IMPLEMENTATION

5.1 Introduction

The MC33192 stepper-motor controller generates four phase signals to drive two-
phase motors in half or full step mode. (Full—step involves energizing all stator
coils, while half-step provides for a smaller angle of rotation by energizing only
some stator coils Of the stepper motor.) The data sheet of the MC33192 [31]
describes the Operation of the chip in detail. We discuss the main aspects of
functionality here.

The MC33192 belongs to a family of the MI-bus or the Motorola Interconnect
bus devices. The MI-bus is normally used in automotive electronics to control
loads in a harsh environment. A master MCU can control several devices on a

single MI-bus.

46

5.2 Main Features of the MC33192

The functionality of the MC33192 can be divided into' two main units, viz., the MI
Bus Controller and the Motor Driver [31], [32]. The MI Bus Controller
performs the communication with the MCU, while the Motor Driver converts
the MCU instruction to the apprOpriate motor coil signals. The ﬁgure 5.1 [32]
shows these two units in the M033192 block diagram. We now take a closer look

at the MI bus communication between the MCU and the slave, i.e., MC33192.

Ml Bus Cormler
Oscillator
050 640 kHz 7
I Noise Detector
Di id Bi-Phase Di id
+5v q 8' Bi-Phase Prog v :19"r

 

 

 

 

 

 

 

 

 

 

 

 

 

     

 

 

 

‘--------

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

10k
:1 +5V TUB“
Programming II Logic a,“
Eli ll , I
D on Address
Programmed
~ I L11
‘ I IDual Bridge Driver L12
Latch .L : 8. L21
[2] r : IMotor Diagnostic L22
I\ A |
MI V Serial to Parallel Register I I
-l ,
M Parallel to Serial Register : 20 kHz I w
l

 

 

 

 

 

 

 

 

, Status . ‘
Encoder

 

 

 

 

Figure 5.1: Stepper Motor Controller Block Diagram [32]

5.2.1 MI Bus Protocol - Message Format

The M1 bus protocol uses a Push-Pull technique for message transfer. The push
sequence is essentially the message sent to the slave device by the master, while

the pull sequence refers to the message received by the master.

 

_L ”W .I
T 'l
m | on Enid-Fran
I

———Il——IF
3
‘5
5 E
E

 

 

 

 

 

I
WWW S‘*r\ mW‘uLIx

| I1'2a'4s'or'a'9liiz'a'4l

I I I I I I

I SIII]'1"0‘DO m 02 04 A0 A1 A2]'0”1']828180l sun]
ifill

| i mew I Ich cum I

I I ”8"” ' ' I .“W’ I

| 75p: I 475w 10qu I swam I

l‘ 'I‘ T '1 I

 

i
J_
l

 

 

3

Figure 5.2: Message Coding In The M1 Bus Protocol [32]

The messages have a ﬁxed format. Figure 5.2 from [32] shows these sequences.

The components of the message are as follows.

0 Start bit The MCU takes control of the bus by issuing a start bit, which
holds the MI bus at a logical zero state for three consecutive time slots.

0 Push Field The push ﬁeld contains the MCU message with a push-sync bit,
ﬁve data bits and three address bits, followed by a pull-sync bit, as shown
in the ﬁgure 5.2.

0 Pull Field The pull ﬁeld contains the serial data read by the MCU from the
slave device. It contains three status bits and an end-of-frame signal.

48

5.2.2 Message Coding

The push ﬁeld bits are coded using the Manchester bi-phase code. The bi-phase

code uses two time-slots to encode a single bit.

 

 

I: 2t, >

is
LOGIC'O') (l—OOIC'i')

I
I
I
PushFioidv I
I
CodedBits l
—>t
012345670123456b70
b
LLB—Phase
Noisem

PVVILW

Figure 5.3: Bi-Phase Code [32]

 

 

Figure 5.3 shows the logic levels “1” and “0” represented using bi-phase code.
This enables bit-wise error detection by the slave device which uses an exclusive-
OR detector circuit for the push sequence.

The pull ﬁeld uses a non-return to zero or NRZ code. This encoding uses a
high value represents logic “1” and a low value represents logic “0”.

- "I

I

5.2.3 Address Programming

Each MCB3192 on the MI bus is programmed with a speciﬁc address by the MCU.

The address programming sequence is performed in three steps.

49

5.2.3.1 Step 1
o The MI bus is supplied at 12 volts.

0 The MCU pushes the address to be programmed, with the
data bits set to 0.

o The MCU checks the status bits for the programming code 110.

5.2.3.2 Step 2

o The MI bus remains at 12 volts.

0 The MCU repeats the instructions in step 1.

5.2.3.3 Step 3
e The MI bus is supplied at 5 volts.

0 The MCU pushes the address to be programmed, with the
data bits set to O.

c The MCU checks the status bits for the OK code 100. .

Steps 1 and 2 are repeated until the 110 code is received. All three steps are

repeated until the 100 code is received.

5.2.4 Overwrite-bit Programming

This is performed in two steps.

5.2.4.1 Step 1
o The MI bus is supplied at 12 volts.

0 The MCU pushes the address to be programmed, with the data bits set to
0 except D4, which is set to 1.

o The MCU checks the status bits for the programming code 110.

50

5.2.4.2 Step 2
o The M1 bus is supplied at 12 volts.

0 The MCU repeats the instruction in step 1.
o The MCU checks the status bits for the OK code 100.

Steps 1 and 2 are repeated until the OK code 100 is received. Programming

failure occurs if the necessary code is not received after 8 repeats.

5.2.5 Motor Control

The Motor driver unit of the MC33192 consists of two H-bridges to provide the
motor drive signals. The H-bridge circuits are described in the device data sheet
attached in the Appendix [31]. Essentially, the when only one of the bridges is
active, the motor is in half-step mode, and when both are aCtive, the mode is
full-step. The direction of the motor is controlled by the sequence of the current
direction in the H-bridges.

Once a device is programmed, the MCU issues control instructions. The ﬁve
data bits in the push ﬁeld are used to determine motor direction and the step

mode.

51

5.3 Implementation of the MC33192

5.3.1 Hardware Setup

The ﬁgure 5.4 shows the hardware setup of the implementation [32]. The MCU
board used here is a handy board [33] with a 68HCll. The ﬁgure also shows the
MI bus interface, which consists of a single npn-transistor.

Figure 5.5 [33] shows a block diagram of the handy board, while ﬁgure 5.6 [33]
shows a schematic [of the handy bOard.

The user interface consists of the following:

0 Inputs The program_enable is a user input to begin prOgramming. The
direction, address and step are user inputs to control the motor direction,
address to be programmed, and half or full step size respectively.

0 Outputs The program status bits indicate the current status of the program.
The meaning of the status bits is deﬁned as per table 5.1 [31] below.

Table 5.1: Program Status Bits
S2 S1 SO Status

000 Not used

001 Enable programming

010 No back emf

011 Not used

100 Normal

101 Thermal

110 Programming

111 Error

 

 

 

 

 

 

 

 

 

 

 

 

 

The signal from PD2 of the handy board is used to set the MI bus at 12 volts for

the programming sequence.

52

5.3.2 MC33192 Software

As mentioned before, the software to drive the MC33192 was developed on the
MC68HC11 microcontroller for this project. The software was developed in as-
sembly language1 and downloaded on the handy board using the Interactive-C [34]
binary format. The next few paragraphs describe the design of the software pro-

gram. A complete listing of the program is attached in the Appendix.

5.3.3 Software design

The software program is divided into three modules, viz.,
c Initialization module
0 Timer Interrupt module

0 Main module

These individual modules are now described.

5.3.3.1 Intialization

This module performs the following tasks.

0 Initialize I/ O ports, reset timer and output compare unit
0 Initialize variables and stepper motor parameters

0 Initialize timer interrupt routine

0 Set controller mode to program mode or control mode

0 Set initial push-sequence depending on control or programming mode and
user-inputs.

 

1The assembly code is written speciﬁcally for use with Interactive -C.

53

5.3.3.2 Timer Interrupt

The timer interrupt module is used to generate an interrupt request every 5 msec,
and execute the appropriate timer interrupt service routine. For this purpose,
the output compare function of the 68HCll is used. Whenever the free-running
counter of the MCU matches the value in the output compare register, an interrupt

request is generated and it is serviced by an interrupt service routine.

5.3.3.3 Main

The main execution module consists of the core of the software program. Each
time the timer interrupt is generated, control is transferred to an appropriate
interrupt service sequence in the main module.

In the interrupt service routine the MCU issues the required instruction, reads
the status information and prepares the next instruction. Then, the address of
the interrupt service routine to execute the next instruction is updated. Then the
program control passes once again to the timer interrupt module to generate the
next interrupt.

The ﬁgure 5.7 describes the program operation in the form ofa ﬂow chart. The
key steps in the main module, which are the transmission of the push-sequence,

and the analysis of the pull-sequence, are described further here.

5.3.3.3.1 Push Sequence As shown in the figure 5.7, once the initialization

of the program is completed and the mode of the controller is set, the control of

54

the program passes to the main module at the next timer interrupt.

The ﬁrst step in the main module, is to convert the push sequence to bi-phase
code, and transmit it to the slave in a ﬁxed time. Each message time slot used
for this project is 25 micro seconds, as recommended in the MC33192 data sheet.
At the end of the ”push sequence, the MCU listens for the pull ﬁeld sent by the

slave device and this is analyzed as follows.

5.3.3.3.2 Pull Analysis The purpose of the pull analysis is to determine the
next push sequence and display the status information to the user. The pull-ﬁeld
status value returned by the slave device corresponds to one of the following two

C3588:

Case I The status corresponds to programming or normal Operation. In this
case, the push-sequence is updated and the status if displayed to the user. The
interrupt service routine is updated to perform the next step in the motor control

or programming, at the next timer interrupt.

Case II The status corresponds to any of the abnormal conditions listed in
table 5.1. In this case, the push-sequence is not updated, the corresponding error
code is displayed to the user, and the control is transferred to the timer interrupt
software directly. The next timer interrupt does not cause any data transmission

to the slave device. Normal Operation continues only after the error is ﬁxed and

the MCU is reset.

55

5.4 Summary

This chapter deals with the stepper—motor controller implementation using the
MC33192. To begin with, the main features of the MC33192 Operation and the MI
bus protocol were explained. Then, a description of the hardware setup with the
necessary schematics was presented. We then described the design and implemen-
tation-of the software program to control the MC33192. This chapter concludes
the description of the two approaches to implement the stepper-motor controller
used in this thesis. These are the software implementation using POLIS—Esterel-
Ptolemy environment, and the hardware version using the MC33192. In the next

chapter, the results of these two implementations are presented, and analyzed.

56

 

 

Ibo: feedback hit.-

 

 

  

 

Figure 5.4: Hardware Setup For The MC33192

57

 

 

 

 

 

SW

sud-m I
‘T i

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

 

 

 

 

 

 

 

 

 

m» u oooon Odom
er N 00095 manning .mmtho 0» 6.an
m» n 0898 Odom .0346 m. MOM 30H a No muan one :H
m> u ooomXo wuﬂuz Edna mUHOw on on Ou ud£3 Heuﬂmﬂo “and mcouudn
a» n 80va Odom m3onm 0.3m... mass .mon 9.3 :0 .x uHm. one
C? H OOOVXO WUMHB UNVHUUU ”H“ m» stOHSU O? "WOUOZ
.— L . . .3, _ _ _ 35395 W m Eumxamdam M
. , _ imam _ , ,, ,, - ,.
, _ as, a
e - mamas?» aaowummmm
Iiuw...~.a, 01881.99 _0WL0:LZ€ﬂS l
+._I_ E _ _ I
890 NH nH H3535 ., l G G
hwé 6.2,.
lemmmﬁ
mmﬁm
£6. >3
Hum

 

 

 

: EVE/7:565.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 5.5: Block diagram Of The Handy Board [33]

58

69

9'9 amﬁis

[as] homer/xi puv ﬂdO JO mementos

Iaqusuen a]

|OJIU03 00']

Indino ozagd

    
 

IaAIaoai 3| lOU.

wu ztsvtzlnsxlon
oooooovnsosst
sInduI Ieuﬁip l IOOOOdA 150 H

[II]!!! sm:

mu izctsu anu
vvvvvvv dam

ddddddd wad

u

a“ IIUWIS9
18268
1

v

ZICLIHHIO .1

aaaansoos ll

sInduI

0"LNV
60|euv

voon

 

 

 

 

I
”If r-
- egg
mull"! c
-Iax1
I
i i am
I ‘ I
St iii; 7&3
an
A9

$953

—CJ 9; moles Indino 10mm
l-—-C'J at issues indu! ﬁle
I

 

’——CI um

I

   
 
  
  

["00

  
  
   
 
    
   

m

 

  

puﬁ
“M
882150

Zli‘l

 

 

START
_ _ _ _ — — — —' INITIALIZATION

 

 

l'
|

| Initialize I/O and
I Parameters
I

I

I

l

 

 

 

 

 

Set Mode
Program/Control

————————— | ——-——1-————

 

I
I
|
I
I
TIMER INTERRUPT I
.l

 

 

 

 

I
I
I
|
I
I
I
I
|
I
I
I
l
.1

MAIN

 

 

Interrupt Service

 

 

 

 

 

 

I
: Interrupt Request
I
I

 

 

Transmit PUSH

 

 

 

 

 

PULL Analysis

 

 

 

 

Reset Timer

 

 

 

——_é—————————-——-—q
—-——-——---_—-—-

 

 

 

 

Figure 5.7: The Software Program

60

 

Chapter 6

RESULTS, ANALYSIS AND CONCLUSIONS

6.1 Introduction

In the previous two chapters, two different implementations of a stepper-motor
controller have been described. One of them used an existing hardware chip,
the MC33192, and the other used a hardware-software co-design approach. In
this chapter the results of the two implementations are presented and they are
analyzed with respect to some of the issues involved in hardware software co-
design. First, we discuss the results of the MC33192 version, and then the POLIS

implementation.

61

6.2 The MC33192 implementation

The performance of the MC33192 software was veriﬁed for speciﬁc inputs and
outputs as per the speciﬁcation. Table 6.1 indicates these inputs and outputs.

The motor modes are achieved as follows:

0 step=0/1 indicates half/full step.
0 dir=0/1 indicates clockwise/counterclockwise (cw/ccw)

o addr=0/l indicates the chip address is 2 or 4. (arbitrary)

The step sequences shown in the table are for cw Operation. They are reversed
for ccw operation.

Table 6.1: MC33192 Testing
MOTOR mode Program status1 Coil output;2
Not running Programming None
Half step OK H H
H Z
H L~
Z L
L L
L Z
L H
Z H
Full step OK H H
H L
L L
L H

 

 

 

 

 

 

 

 

 

In the next section, we discuss the POLIS implementation.

 

1The status codes are listed in table 5.1
2H, L, Z indicate forward, reverse and high impedance states of the coils

62

6.3 The POLIS implementation

As before, this implementation will be referred to as the SMC(stepper—motor con-
troller). The results of the SMC are presented in two sections - one the Ptolemy

simulation results for various test conditions; and the other the test results using

the 68HCll.'

6.3.1 Ptolemy simulations

In order to test the Ptolemy simulation, a set of important criteria were laid
down. These were necessary to ensure that all the critical aspects of the design
were tested, before proceeding with implementation. This is in keeping with one
of the goals of this thesis, i.e., to explore the POLIS hardware software co—design
methodology.

As described in chapter 3, Ptolemy offers two useful tools, in addition to other
displays, to trace simulation runs. These are the ﬁring ﬁle and the overﬂow ﬁle.
The location of these ﬁles can be speciﬁed as parameters for the test bed universe.
These ﬁles provide two key sets of information for the simulation. The ﬁring ﬁle
indicates the time stamp of ﬁring of all software stars. The overﬂow ﬁle on the
other hand, indicates all the missed events for each module, which may occur due
to asynchronous Operation of the system modules. With this background, the

following objectives were to be achieved through the tests.

0 Verify functional correctness.

63

0 Timing analysis by varying clock frequency and communication time-slots.

0 Explore various hardware software partitions. Compare an all software sim-
ulation to a combined hardware/software partition.

We now discuss each of these in detail. The second and third items in the
above list Of criteria have been combined, as timing behavior is also dependent on

whether a particular module is implemented in hardware or software.

6.3.1.1 Emctional Veriﬁcation

The test bench for functional veriﬁcation was based on the operation of the SMC
itself. This constituted testing the outputs corresponding to each input in the
control or programming modes. The control panel schematic indicating this inter-
face for the test bed is attached in the Appendix. In all cases, the operation was
as expected. Table 6.2 indicates the results obtained for the simulation. For the
functional simulation, all the modules were mapped to hardware. The overflow

ﬁle was veriﬁed to ensure that no events were missed.

6.3.1.2 Timing Analysis and HW/ SW partitions

For this thesis, the ﬁnal implementation of the SMC is software running on the
68HC11. Thus the clock-frequency of the target micro-controller was already
known to be 8 Mhz(crystal frequency), with a system clock (ECLK) of 2 Mhz.

However, in order to emulate a real world design, where architecture decisions have

 

lcw: clockwise, ccw: counter clockwise, H, L, Z indicate forward, reverse and high impedance

states of the coils

64

Table 6.2: Functional Simulation Using Ptolemy

 

 

 

 

 

 

 

 

Mode Motor statusI Coil outputs A, B Comment
1 (Programming) Not running None Pull value=6;
Addr value = 2 or 4
0 (Control) Half step H H step=0;The sequence
H Z is reversed
H L for ccw.
Z L
L L
L Z
L H
Z H
0 (Control) Full step H H step=l;The sequence
H L is reversed
L L for ccw.
L H

 

to be made by designers, the SMC behavior was analyzed for alternative clocks,
and with alternative partitions.
some partitions and clocks. This is followed by a brief explanation of the results.
The primary goal of this exercise is to gain insight into the uses of the Ptolemy

simulator and the criteria for design optimization. These issues are discussed

Table 6.3 indicates the results obtained for

towards the end of this chapter in the analysis and conclusions sections.

65

 

Table 6.3: Clocked Simulation Usin Ptolemy

 

 

 

 

Partition CPU clock Time slots Step cycle
All HW 500ns 200/25): s 2 250): 8
All SWr 5): s 200/25): s 4.5ms

2): s 250/25):s 3.6ms

1): s 250/25): s 5.1ms

500ns 275/25): s 10ms
All SW 500ns 50/ 25 ): s 5ms
except mcu, bus

 

 

 

 

 

 

Table 6.3 presents the results of the time-based simulation of the SMC system.
The partition indicates which modules are mapped to hardware, and which to
software. The CPU clock corresponds to the ECLK signal. The two time slot
values correspond to the push transmission time slot and the pull reception time
slot. The step cycle corresponds to the time taken for transmitting a push sequence
and receiving status bits. All the values in the tables only specify only upper or
lower limits of the timing parameters. Any values which are suitable multiples of
the existing values would also provide similar results. The next section presents
a detailed analysis of the above results.

The all-software partition is used to generate the downloadable ﬁle for the
68hc11 using the POLIS makeﬁles, as described in chapter 4. In the next section

a detailed analysis of each of these results is presented.

 

lThe 68hc11 peripherals(timers) are mapped to behavioral mode

66

6.4 Analysis

We now examine the co—design approach used for this thesis, in the light of the
results obtained for each implementation of the stepper-motor controller. In par-

ticular, the focus is on co—simulation and hardware/software partitioning.

6.4.1 Background

It is in order here, to note some important characteristics of the DE domain in

the Ptolemy simulation [26].

0 Time refers to simulated time.

o The simulation is event-driven with each event being time-stamped and
queued in a chronological order.

0 The DE scheduler processes events in the queue at run-time and ﬁres or
executes the appIOpriate star.

As described earlier, the “ﬁringﬁle” indicates the time stamps of the execution
of software CFSMs. An excerpt of the ﬁringﬁle looks is included next.
test.hbSMC.hbSMC1.hbMCU1.hbmcul: 0 0 start
test_hbSMC.hbSMC1.hbMCU1.hbmcu1: 290 -1 end
test_hbSMC.hbSMC1.hbbuslz 7616 0 start
test.hbSMC.hbSMC1.hbbusl: 7771 -1 end
test_hbSMC.hbSMC1.hbMCU1.hbmcul: 7771 0 start
This shows the name of the star, and the time stamp for the execution. If a

star takes too long to respond to an event, the event may be over-written by the

67

time the star is ready. These missed events or ” overﬂows” can be tracked down
using the overﬂow ﬁle, which indicates which events are missed. Then the timing
parameters of the module in question can be suitably altered in order to achieve
accurate responses. It is necessary to mention however, that some missed events
could be insigniﬁcant, while others may be critical. An excerpt of the overﬂowﬁle
is included next.
testJIbSMChbSMClhbMCUl.hbbyteinl: 17690 e.clock
test.hbSMC.hbSMC1.hbMCU1.hbbyteinl: 19130 e.clock
test.hbSMC.hbSMC1.hbMCU1.hbbyteinl: 20090 e_clock
Here, the star name, the time stamp of the event and the event name are indicated.
Also, as mentioned before, the POLIS system exhibits asynchronous execution
of concurrent modules. Thus, if synchronization is required between such mod-
ules, this can be achieved using explicit handshake mechanisms or other suitable

interfaces.

6.4.2 CO-simulation

In a system with hardware/ software modules, the co-simulation environment pro-
vides a useful tool to verify the system behavior and Optimize design criteria,
without actually building the system. Some of these are

0 Choice of HW/SW implementation for any given system component.

This could be an architecture or partitioning issue. The given system may
or may not have the ﬂexibility for major changes at the simulation stage.

68

However, various HW/ SW alternatives can be explored and the system per-
formance can be accordingly evaluated.

0 Synchronization between modules

This hinges on two important issues. First, the timing requirements speciﬁed
for the system. If no trade-offs are possible, then the strict synchronization
requirements must be met in order to ensure required performance. This
may mean sacriﬁcing cost or ﬂexibility.

Second, the interfaces designed in the system. At the design stage, some
parameters or some components may be considered more critical than others
for Optimal system performance. However, it is only during the co-simulation
stage that the behavior of the system becomes clear. It is here, that the
behavior of individual modules or sub-systems containing several modules,
can be isolated to analyse their contribution to overall system performance.
This enhances the quality of the system design and increases conﬁdence in
the ﬁnal product.

0 Performance vs Cost trade-offs.

Trade-off considerations arise at every stage of system design. At the speci-
ﬁcation stage, trade-offs could be about the requirements themselves. These
could be inﬂuenced by available resources and criticality of the system in
consideration. .

At the architecture stage, these decisions have a direct bearing on the ﬁnal
system cost. They also determine the partitioning decisions which follow
the simulation step.

In the following sections, some of the above criteria are explored further for

the stepper-motor controller case.

6.4.3 The SMC system

It is instructive to re-organize the stepper-motor controller system solely based on

the nature of the tasks performed by each component of the system.

69

6.4.3.1 Timing behavior

The mcu sub-system and the bus sub-system perfOrm operations involving se-
quencing, and are heavily dependent on timing performance. The program and
control modules are compute-intensive and have comparatively lighter loads. Ac-
cordingly, once these two modules were cleared during the functional simulation,
they do not signiﬁcantly change their behavior when they are mapped to software.
This was demonstrated during the simulations and these modules performed as
expected.

In the mcu and the bus sub—systems, the modules in question are the mcu and
the bus modules and the timing modules.

The timing performance of these sub-systems involved two different timing
criteria. One was the response of an individual module with changing timing pa-
rameters. The other was the relative timing or synchronization between different
modules.

We illustrate each of these here. As the clock frequency was changed over 5):s
to 500ns , more and more missed events occurred in the mcu subsystem with the
given timer setting. This was reﬂected in the overﬂow ﬁle. For a faster clock,
the timer settings needed to be increased in order to avoid missed events. This
problem occurs for those events where there is no explicit acknowledge.

As mentioned before, this is due to the asynchronous behavior in POLIS.

The solution is to have explicit handshake mechanisms in the code, or to space

70

important timer events sufficiently, so that clock is not too fast for the response.
In this case, we use the latter method, and increase) timer periods sufficiently to
eliminate or reduce missed events. The preceding paragraphs deal with the mcu
module alone.

Now, we move on to the more complex inter-module timing dependencies. This

involves the mcu module, parallel to serial or ptos module and the bus module.

0 If the parallel to serial converter module reads data too fast or too slow, the
result would be that same mcu data is re-read, or some data values may be
missed.

0 Further, if the bus module is scheduled incorrectly it may read junk values
from the ptos converter, thus causing incorrect or zero outputs at the drive
signals.

A closer analysis of the above leads us to the conclusion that of these two
interdependencies, the latter is more crucial because a missed step for the motor
is more tolerable than an invalid or absent output signal. Accordingly, the timers
were adjusted to eliminate invalid data ﬁrst, and then to eliminate missed events.

First the ptos timer was reset to a suitable value to eliminate erroneous reads.
This value is indicated by ﬁrst time slot in the table 6.2. This could mean that
some values are missed, but all the output data is valid.

Then, the mcu timer period was increased with faster clocks, with an approx-
imate estimate. This value is denoted by “step-cycle” in table 6.2. This helped
eliminate the missed values also, though at the cost of lower speeds. This pro-

cedure worked most of the time for all the cases. However, in some cases both

71

timers needed adjustment. The ptos timer setting was also revised to achieve cor-
rect performance. In any case, the strategy proved effective in arriving at correct
functionality for the various frequencies tested.

It was previously observed there is no standard tool for hardware software
codesign. Accordingly some design aspects are very speciﬁc to the codesign en-
vironment used. This can be illustrated by the following, with respect to this
project.

If timing criteria are well known at the outset, timing interdepencies could be
reduced during the speciﬁcation stage itself. Thus, in our case, the mcu mod-
ule and the ptos module could be combined, in order to eliminate their interface.
However, this defeats the purpose of an ”implementation-independent” speciﬁca-
tion. On the other hand, it could improve the system performance. Again, some
modularity would be sacriﬁced. This is evident in the bus module, which has a
serial to parallel converter built-in, and allows 25): 3 resolution.

As mentioned before, all critical interface signals could be modiﬁed to have a
built-in hand-shake mechanism to reduce missed events. This could signiﬁcantly
increase code size, and result in over-specifying the system. Thus, all these deci—

sions involve several system-dependent factors.

72

6.4.3.2 Hardware or Software

As indicated before, timing analysis and hardware/software partitioning are re-
lated due to better performance of hardware under strict timing requirements.
This factor is dealt with in the next section. Here, we examine other distinguish-

ing features of hardware and software particularly in the co-design case.

. Flexibility

Since software can be altered, while hardware needs to be replaced, in general
we can consider software to be more ﬂexible than hardware. An example
for the SMC system could be that the communication time slots could be
increased, in order to simplify the code, while achieving desired performance.
However in the MC33192, the MCU software needs to be tailor-made for
the required time slots. In this sense, software implementation obviously
provides some degree of “programmability” which hardware does not.

However, in an application-speciﬁc embedded system, this could be a more
complex issue. For instance, the software may be specially written for a
piece of hardware, and rewriting the software may need signiﬁcant changes
in the hardware/software interfaces.

0 Reusability

Code re-use is an important feature of system design. It may provide sig-
niﬁcant savings in large systems. In case of the SMC, the system could be
extended for multiple motors, or multiple outputs or extended functionality
by re—using existing code. This could be at the system level or modular level.
Using co-design, the new system could be Optimized for various parameters
before the ﬁnal implementation. In case of hardware, the only Option is
additional hardware and the system may not be upgradable easily.

Some practical considerations in replacing the MC33192 chip with the SMC
could be the following. The SMC may not match the speed of the hardware
chip, while being sufﬁcient for the required functionality. In an actual au-
tomobile control system, it might be more desirable to separate the MCU
from the motor due to the harsh environment. On the other hand, this could
also be achieved by providing some additional driver logic at the motor end.
Thus the decision could depend on the actual use of the system.

73

In the preceding paragraphs, several aspects of the timing and performance of
the system were discussed in the hardware/software .co—design context. The next

section presents conclusions obtained from this analysis.

6.5 Conclusions

Many features of the hardware/software co—design were presented in this thesis
over several chapters. The work in this thesis serves to demonstrate using the
SMC system, some of these characteristics. These include, criteria for co-design,
speciﬁcation, architecture and co-simulation issues.

From these analyses, certain trade-offs in using co-design are evident. The ﬁrst
of these, is the fact that the co-design process is not only application-speciﬁc, but
to a large extent, environment- speciﬁc. This was described in the previous section.
It follows, that the hardware-software co-design process, although advantageous,
may lead to certain problems. These could be the need for special resources, and
time delays for learning curves in new environments.

However, these very reasons make the co—design methodology very powerful,
and provide system designers with a number of choices and tools for optimum

design which is faster and cheaper.

74

Chapter 7

RECOMMENDATIONS FOR FUTURE WORK

The features of the POLIS co—design system used for this project provide a rea-
sonable sc0pe and focus on certain aspects of co-design. The next step would be
to continue the SMC implementation, and generate hardware/ software partitions.
These could then be used to generate .xnf ﬁles for prototyping on Xilinx boards
[4] to fully explore the capability of the POLIS environment. In addition, this
would provide the experience to develop the POLIS, Esterel, Ptolemy system into
a full-ﬂedged and integrated co—design environment with all the associated tools

in one system, for future use in MSU.

75

APPENDIX

Program Listings

module hbbus:

constant BUS..V.TIME: integer, TIME..SLOT: integer;
input OC3.END, MODE(boolean), PUSH-FIELD(integer),
PROGRAMSTATUSOnteger),
CONTROL.STATUS(integer),RESET, BUS.SIG(boolean);
output OC3.START(integer), PROGRAM-CODE(integer), CONTROLCODE
(integer), PULL_FIELD(integer),
PUSH.DEBUG(integer), PUSH_SYNC, PULL_SYNC, oBUS_SIG(boolean);
function Rx(integer, integer) :integer;

function Tx(integer, integer) :integer;

constant count8zinteger, bitcountzinteger;

signal Receive-push in

var Tcountz=0 :integer,

Bcount:=1:integer,

Curr-push :=0:integer,

Prev-push :=0:integer,

Push_bit:=0 :integer,

Pullin:=0:integer,

Pull.out:=0:integer,

pcount:=1:integer in

loop

weak abort

await BUS-SIG do

if Bcount6 then

Bcount:=Bcount+1;

if(?BUS.SIG = false) and BcountIS then

T countz=Tcount+ 1;

elsif (?BUS_SIG=true) and Bcount35 then

Tcount:=0;

end if;

if (?BUS.SIG=true) and Bcount=5 then

if Tcount=3 then

emit PUSH-SYNC;

end if;

end if;

elsif Bcountil4 and Bcountg5 then
Bcount:=Bcount+1;

if (?BUS.SIG=true) then

Push-bit:=1

else

Push-bit:=0;

end if;

78

Curr-push := Rx(Push_bit,Prev-push);
Prev-push := Curr-push;

if Bcount=14 then

emit PUSHDEBUG(Curr-push);

if (?MODE 2 true) then

emit PROGRAM-CODE(Curr-push);
else

emit CONTROL-CODE(Curr_push);
end if;

end if;

elsif Bcount=14 then
Bcount:=Bcount+1;

pause;

elsif Bcount=15 then
if(?BUS_SIG=true) then

emit PULL-SYNC;

end if;

Bcount:=1;

Prev-push:=0;

Tcount:=0;

if(?MODE=true) then

PulLin z: (?PROGRAM.STATUS);
else

Pull_in z: (?CONTROL.STATUS);
end if;

emit OC3-START(TIME_SLOT);
await OC3_END;

emit PULL_FIELD(Pull_in);

pcount:=1;
repeat 5 times
pause;

if pcounti4 then
Pull_out := Tx(PulLin, pcount);
if(Pull_out = 1) then
emit oBUS.SIG(true);
else

emit oBUS.SIG(false);
end if;

elsif pcount=4 then
emit oBUS.SIG(true);
else

emit oBUS.SIG(false);

79

end if;

pcount: =pcount+1;
end repeat;

end if;

and await;

when RESET

end loop

end var

end signal

80

module hbprogram:

input PROGRAM-CODEzinteger;

output PROGRAM-STATUS:integer,PFUNC-DEBUG : integer;
function FROG-FUNC(integer) : integer;
IOOp

await immediate PROGRAM-CODE do
pause;

var FROG-IN :=0: integer,
PROG-OUT:=0 : integer in

PROG-IN:= ?PROGRAM-CODE;
PROG-OUT:=PROG-FUNC(PROG_IN);
pause;

emit PROGRAMSTATUS(PROG-OUT);
emit PFUNC-DEBUG(PROG-OUT);

end var;

end await;

end loop

module hbcontrol:

input CONTROL-CODE :integer;

output CONTROL-STATUS: integer,

MOTOR-COIL-AI: integer, MOTOR- COIL-A2: integer,

MOTOR- COIL-Bl: integer, MOTOR- COIL-B2: integer, A-DEBUG :integer,
B-DEBUG: integer, CF UNC-DEBUG integer;

function CONTROL-FUNC(integer) : integer, MOTOR-FUNC-A(integer) :
integer, MOTOR-FUNC-B(integer) : integer, FROG-FUNC(integer):integer;
loop

await immediate CONTROL-CODE do
pause;

var Code-in :=0:integer,

Code-out :=0:integer,

Coil-A :=0:integer,

Coil-B :=0 :integer in

Code-in := ?CONTROL-CODE;
Code-out:= CONTROL-FUNC(COde-in);
Coil-A := MOTOR-FUNC-A(Code-in);
Coil-B := MOTOR-FUNC-B(Code-in);
if (Coil-A=1) then

emit MOTOR-COIL-A1(1);

emit MOTOR-COIL-A2(0);
e1sif(Coil_A=2) then

emit MOTOR-COIL-A1(0);

81

emit MOTOR-COIL-A2( 1);

else

emit MOTOR-COIL-A1(0);

emit MOTOR-COIL-A2(0);

end if;

if (Coil-8:1) then emit MOTOR-COIL-Bl(1);
emit MOTOR-COIL-B2(0);
elsif(COil_B=2) then

emit MOTOR-COIL-Bl(0);

emit MOTOR-COIL-B2(1);

else

emit MOTOR-COIL-Bl(0);

emit MOTOR-COIL-B2(0);

end if;

emit A-DEBUG (Coil-A);

emit B-DEBUG (Coil-B);

emit CONTROL-STATUS(Code-out);
emit CFUNC-DEBUG(Code-out);
end var;

end await;

end 100p

82

module hbmcu:

input DIszoolean, STEP:boolean, ADDR:boolean,

RESET;

output PUSH-VAinnteger;

constant bitcount:integer;

function Get-push(integer, integer):integer;

function Next-step(integer, integer):integer;

loop

var push.seq:=0:integer,
push-val:=0: integer,
addr:=0: integer,
step-count:=0 : integer,
prog-done:=0:integer in
weak abort

pause;

every immediate MODE do
if ?ADDR=true then

addr:=4;

elsif ?ADDR=false then

addr:=2;

end if;

if ?DIR=true and ?STEP=true then
push-seqzzl;

%fcw step-count:=7;

elsif ‘?DIR=true and ?STEP=false then
push-seq:=2;

%hcw step-count:=8;

elsif ?DIR=false and ?STEP=true then
push-seq:=3;

%fccw step-countzzl;

elsif ?DIR=false and ?STEP=false then

push-seq:=4;
‘70 hccw step-countzzl;
end if;

OC2-END, MODE:boolean,

if ?MODE=true and prog-done=0 then %programming

push-seq:=5;
step-count:=1;
positive repeat 5 times
pause;

await OC2-END do

if (step-counti4) then
push-val:=0;

83

step-countzzstep-count+1;

elsif (step-count=4) then

push-val:=8;

step-count:=step-count+1;
elsif(step-count=5) then

push-val:=8;

step..count:=8;

%terminate programming

prog-donezzl;

end if;

push-valzzpush-val+addr;

emit PUSH-VAL(push-val);

end await;

end repeat;

elsif ?MODE=false and prog-done=1 then %control
loop weak abort

pause;

await immediate OC2-END;
push-val:=Get_push(push-seq,step-count);
step-count:=Next-step(push-seq,step-count);
push-valzzpush-val+addr;

emit PUSH-VAL(push_val);

when MODE;

end loop;

end if;

end every;

when RESET;

end var;

end loop;

module hbbytein:

input Push-ﬁeldzinteger, start,clock;
output out-bitzboolean;

constant bitcount:integer;

function Tx(integer, integer):integer;
loop await immediate Push-ﬁeld;
var PUSH-IN :=0:integer,
PUSH-OUT:=0:integer,

count : integer in

count :0;

PUSH-IN := ?Push-ﬁeld;

positive repeat bitcount times

84

await clock;

count := count+1;

if counti4 or count=5 or count=14 then
emit out-bit(false);

elsif count=4 or count=15 then

emit out-bit(true);

else PUSH-OUT := Tx(PUSH-IN, (count-5));
if PUSH-OUTzl then

emit out-bit(true);

else

emit out-bit(false);

end if;

end if;

end repeat;

end var;

end loop;

85

/* Programming:

input 0 = 0 data + address say 101 then input byte is 5
output -

110 = 6

input repeat as above

output

110 = 6

input repeat as above

output

100 = 4

*/

/* Control:

See page 6 of MC datasheet. for the 8 combinations,

we shift the push three places right to eliminate address

and we list the values of just the data bits, with the order D0,to D4.
The status output for normal operation

is 100 = 4

The coil outputs are

(Here we assume that coil A high means energise A1-A2 and low means A2-A1)
Z is high impedance

INPUT coil A coil B

21 1 1

20 1 2

23 1 0

7 2 0

31 0 0

28 0 2

29 0 1

5 2 1

/* This is either ovrbit programming or address programming.
as per present options, address could be 100 or 010 (A0,A1,A2).
so, pin could be 4 or 2 any other is error.

For ovrbit, the value is 12 for address 4 and 10 for address 2.*/
#deﬁne pos 1;

#deﬁne neg 2;

#deﬁne Z 3;

#deﬁne error 4;

static int prog-ﬂag=0;

static int address=0;

int PROG-FUNC(int pin){

int pout=0;

if (prog-ﬂag ==0){

86

 

if(pin== pin== ){
address=pin;

pout = 6;
prog-ﬂagzl;

/* 6 */

} }

else if(prog-ﬂag==1){
if(pin==address){
pout=6;

/* 6 */

prog_ﬂag=2;

}

else if(prog_ﬂag==2){
if(pin==address){
pout =4;

/* 4 */

prog-ﬂag=3;

}

}

else if(prog_ﬂag== ){
if(pin==(address+8)){
pout=6;

/* 6 */

prog-ﬂag=4;

}

else if(prog-ﬂag==4){
if(pin==(address+8)){
pout=4;

/* 4 */

prog_ﬂag=5;

}

}

else{
prog-ﬂag=0;
pout=7;
return 7;

}

return pout;

}
int CONTROL-FUNC(int cﬁn){

87

int cfout=0, cfdatazcﬁn;

int mask-addr=7;

mask-addr&=cﬁn;

if(mask-addr==4||mask_addr== ){

cfdata >>=3;

if (cfdata==5||cfdata==7||cfdata==20[[cfdata==21){
cfout = 4;

} else if(cfdata==23|Icfdata==28[[cfdata==29||cfdata==31){
cfout=4;

}

}

else{
cfout=7;

}

return cfout;

}
int MOTOR-F UN C-A(int cﬁna)

{

int aout=0,cfadata=cﬁna;

int mask-addra=7;

mask_addra&=cﬁna;
if(mask-addra==4|[mask-addra== ){

cfadata >>=3;

if (cfadata== 20]] cfadata :2 21]] cfadata ==23){
aout: pos;

} else if(cfadata== 28]] cfadata :_—_ 29H cfadata ==31){
aout=neg;

} else if(cfadata ==5 ”cfadata == ){

aout = Z;

}

}

else{
aout = error;

}

return aout;

}

int MOTOR-FUNC-B(int cﬁnb)

{ int bout=0, cfbdatazcﬁnb;

int mask-addrb=7;
mask.addrb&=cﬁnb;
if(mask-addrb==4||mask-addrb==2){
cfbdata >>=3;

88

if (cfbdata== 5|| cfbdata == 21“ cfbdata ==29){
bout: pos;

} else if(cfbdata== 7|] cfbdata == 23]] cfbdata ==31){
bout=neg;

} else if(cfbdata== 20]] cfbdata == 28){

bout = Z;

l

}

else{
bout = error;

}

return bout;

}

/*Serial to Parallel converter */

int Rx(int inbit, int Prev-Frame)

{

int Frame-In=Prev.Frame;

int Mask-Msb = 256;

/* assuming LSB ﬁrst transmission*/
if (inbit==0){

Frame-In >= 1;

} else if(inbit==1){

Frame-In —= Mask-Msb;

Frame-In >= 1;

/* cout <<”\n after shifting once ” << Frame-In << ”\ n”;

/

}
/* else{

cout << ”\n input error \n”;

}*/ return Frame-In;

} int Get-push(int push-seq, int step-count)
{ const int step-array[8]={168,160,184, 56, 248, 224, 232, 40};
int push-val, index;

if(push_seq==1)

index=(step-count+2)%8;

/* fcw */

else if(push_seq==2)

index = (step-count%8)+1;

/* hcw */

else if(push_seq==3)

index = (step-count+6)%8;

/* fccw */

89

else

index = (step-count+6)%8+l;
/* hccw */

push-val: step-array[(index-1)];
return push-val;

}

int Next-step(int push-seq, int step-count)
{

int index;

if(push-seq== )
index=(step-count+2)%8;

/* fcw */

else if(push-seq==2)

index = (step-count%8)+1;
/* hcw */

else if(push_seq==3)

index = (step-count+6)%8;
/* fccw */

else

index = (step-count+6)%8+1;
/* hccw */

return index;

}

90

* Assembly code listing
* ﬁle of standard 6811 register declarations
**********************************************************

Control Registers

BASE EQU $1000

PORTA EQU $1000 ; Port A data register

RESVl EQU $1001 ; Reserved

PIOC EQU $1002 ; Parallel I/O Control register

PORTC EQU $1003 ; Port C latched data register
PORTB EQU $1004 ; Port B data register

PORTCL EQU $1005 ;

DDRC EQU $1007 ; Data Direction register for port C
PORTD EQU $1008 ; Port D data register

DDRD EQU $1009 ; Data Direction register for port D
PORTE EQU $100A ; Port E data register

CFORC EQU $100B ; Timer Compare Force Register
OClM EQU $1000 ; Output Compare 1 Mask register
OCID EQU $100D ; Output Compare 1 Data register

* Two-Byte Registers (High,Low — Use Load & Store Double to access)
TCNT EQU $100E ; Timer Count Register

TICI EQU $1010 ; Timer Input Capture register 1

TIC2 EQU $1012 ; Timer Input Capture register 2

TIC3 EQU $1014 ; Timer Input Capture register 3

TOCl EQU $1016 ; Timer Output Compare register 1
TOC2 EQU $1018 ; Timer Output Compare register 2

T OC3 EQU $101A ; Timer Output Compare register 3
TOC4 EQU $101C ; Timer Output Compare register 4
T1405 EQU $101E ; Timer Input compare 4 or Output compare 5 register
TCTLl EQU $1020 ; Timer Control register 1

TCTL2 EQU $1021 ; Timer Control register 2

TMSKl EQU $1022 ; main Timer interrupt Mask register 1
TFLGI EQU $1023 ; main Timer interrupt Flag register 1
TMSK2 EQU $1024 ; misc Timer interrupt Mask register 2
TFLG2 EQU $1025 ; misc Timer interrupt Flag register 2
PACTL EQU $1026 ; Pulse Accumulator Control register
PACNT EQU $1027 ; Pulse Accumulator Count register
SPCR EQU $1028 ; SPI Control Register

SPSR EQU $1029 ; SPI Status Register

SPDR EQU $102A ; SPI Data Register

BAUD EQU $102B ; SCI Baud Rate Control Register
SCCRI EQU $102C ; SCI Control Register 1

SCCR2 EQU $102D ; SCI Control Register 2

91

SCSR EQU $102B ; SCI Status Register

SCDR EQU $102F ; SCI Data Register

ADCTL EQU $1030 ; A/ D Control/status Register
ADRI EQU $1031 ; A/ D Result Register 1

ADR2 EQU $1032 ; A/ D Result Register 2

ADR3 EQU $1033 ; A/ D Result Register 3

ADR4 EQU $1034 ; A/ D Result Register 4

BPROT EQU $1035 ; Block Protect register

RESV2 EQU $1036 ; Reserved

RESV3 EQU $1037 ; Reserved

RESV4 EQU $1038 ; Reserved

OPTION EQU $1039 ; system conﬁguration Options
COPRST EQU $103A ; Arm/ Reset COP timer circuitry
PPROG EQU $103B ; EEPROM Programming register
HPRIO EQU $103C ; Highest Priority Interrupt and misc.
INIT EQU $103D ; RAM and I/O Mapping Register
TESTl EQU $103B ; factory Test register

CONFIG EQU $103F ; Conﬁguration Control Register
* Interrupt Vector locations

SCIINT EQU $D6 ; SCI serial system

SPIINT EQU $D8 ; SPI serial system

PAIINT EQU $DA ; Pulse Accumulator Input Edge
PAOVINT EQU $DC ; Pulse Accumulator Overﬂow
TOINT EQU $DE ; Timer Overﬂow

TOCSINT EQU $E0 ; Timer Output Compare 5
TOC4INT EQU $E2 ; Timer Output Compare 4
TOC3INT EQU $E4 ; Timer Output Compare 3
TOCZINT EQU $E6 ; Timer Output Compare 2
TOClINT EQU $E8 ; Timer Output Compare 1
TICBINT EQU $EA ; Timer Input Capture 3
TIC2INT EQU $EC ; Timer Input Capture 2
TICIINT EQU $EE ; Timer Input Capture 1

RTIINT EQU $F0 ; Real Time Interrupt

IRQINT EQU $F 2 ; IRQ External Interrupt
XIRQINT EQU $F4 ; XIRQ External Interrupt
SWIINT EQU $F6 ; Software Interrupt

BADOPINT EQU $F8 ; Illegal Opcode Trap Interrupt
NOCOPINT EQU $FA ; COP Failure (Reset)
CMEINT EQU $FC ; COP Clock Monitor Fail (Reset)
RESETINT EQU $FE ; RESET Interrupt

*************************************************

ORG MAIN-START

92

addr_sel FCB 0

dir-sel FCB 0

step-sel FCB 0

curr-step FCB 0

next-step FCB 0

motor-mode F CB 0 ; 1,2,4,8 for fcw,fccw,hcw,hccw
variable-programstatus FDB 0

pull-val FCB O

prog-count FCB 0

ovr-count F CB 0 ; see initialization module

ovr-step FCB 0 ; see init.. module

push-begin FCB $00,$A8,$A0,$BS,$38,$F8,$E0,$E8,$28; seq for half cw
push-frame FCB 0

toc-val FCB 0 ; timer int address variable

prog_status FCB 0

info-count FCB 100

subroutine-initialize-module:

*variables to be initialized

LDAA #10

STAA toc-val ; the timer init routine

LDAA #4

STAA ovr-count

LDAA #8

STAA ovr-step

LDX #BASE

LDAA #$3C

STAA DDRD,X ; make SPI pins outputs

BCLR PORTD,X $3C

LDAA #$80

STAA PACTL,X

; enable PA7 for output

BCLR PORTA,X $80
*******************************************************
* File ”ldxibase.asm”

* Fred Martin Thu Oct 10 19:49:38 1991

* The following code loads the X register with a base pointer to
the 6811 interrupt vectors: $FF00 if the 6811 is in normal mode,
and $BF00 if the 6811 is in special mode.

* The ﬁle ”6811regs.asm” must be loaded ﬁrst for this to work.
LDAA HPRIO

ANDA #$40 ; test SMOD bit

BNE *+7

93

LDX #$FF00 ; normal mode interrupts

BRA *+5

LDX #$BF00; special mode interrupts
*******************************************************
LDD #toc3-int

STD TOC3INT,X

LDX #BASE

LDD TCNT,X ; timer initialization

ADDD #10000

STD TOC3,X

LDAA #%00100000

STAA TFLG1,X

STAA TMSK1,X ; enable timer3 interrupt

LDAA #%00010000

STAA TCTL1,X ; test pa5 with this for 5msec waveform
CLI

RTS

*********************************************************

Interrupt service routine:
********************************************************

toc3-int:

LDAA #10

CMPA toc-val

BNE toc3-mid0

BSR start-timer5

BRA timer-0 ; nearest timer also if toc-val=70
*******************************************************

start-timer5:
********************************************************

init section
*********************************************************

LDX #BASE

LDAA #1

CMPA prog_status

BEQ go-normal ; device programmed-move to normal operation
BSET PORTA,X $80 ; set PA7 to 1 indicating programming
wait-prog:

LDAA $7FF F

ANDA #$04; testing d12 from user for programming

BNE wait-prog

BSET PORTD, X $10; set PD4 (PA7) is already high(processing)
BSR set -addr

94

BSET PORTD,X $04 ; enable PD2 for 12volt
LDAB addr_sel ; this is the addr to be progmed
STAB push-frame ;

LDAA #2 ; ﬁrst two steps of programming
STAA prog-count

LDAA #20 ; arbit,programming start

STAA toc-val ; toc int serviced by programming
RTS

go-normal:

wait-normal:

LDAA $7FFF

ANDA #$04

BEQ wait-normal ; await d12 disable

BSET PORTD,X $08 ; set PD3,and clr PD4 and PA7 for OK code
BCLR PORTD,X $10

BCLR PORTA,X $80

BRSET $7F F F $10 dir-cw ; otherwise, dir remains O
step-set: BRSET $7FFF $20 step-full ; otherwise,step remains half
addr-set: BSR set-addr

BSR set-push ; load the next push sequence
LDAA #60

STAA toc-val ; toc int serviced by normal loop
RTS

set-addr:

BRCLR $7FFF $08 addr-other ; testing d13 from user for address
LDAB #4 ; this is 001 in reverse a0a1a2

STAB addr-sel

RTS

addr-other:

LDAB #2 ; the address is 010

STAB addr-sel

RTS

dir-cw:

LDAA #1 ; setting direction to 1

STAA dir_sel

BRA step-set

step-full:

LDAA #1 ; setting step to full

STAA step-sel

BRA addr-set

set-push:

TST step-sel

95

BNE full-dir-chk
half-dir-chk:

TST dir-sel

BNE half-cw

BRA half-ccw-mid
************out range branch
tOC3-mid0:

BRA toc3-mid1
timer-0:

BRA timer-1
full-dir-chk:

TST dir-sel

BNE full-cw

BRA full-ccw
full-cw:

LDAA #1

STAA motor-mode

****

reqd steps are 1,3,5,7,1
*********

fcw:

LDAA curr-step

BEQ add-l

CMPA #7

BBQ add-1

CMPA #1

BBQ add-3

CMPA #3

BBQ add-5

BRA add-7
**************************0ut Of range branCh
set-push.mid5:

BRA set-push
***************************************************
full-ccw:

LDAA #2

STAA motor-mode

fccw:

LDAA curr.step

BEQ add-7 ; reqd steps are 7,5,3,1,7,..
CMPA #1

BBQ add-7

96

CMPA #7

BBQ add-5

CMPA #5

BBQ add-3

BRA add-l
************************out of range branch
half-ccw-mid:

BRA half-ccw

************************************

half-cw:

LDAA #4

STAA motor-mode
hcw: LDAA curr-step
BEQ add-1

; reqd steps are 1,2,....8,1
CMPA #8

BBQ add-1

CMPA #1

BBQ add}

CMPA #2

BBQ add-3

CMPA #3

BBQ add-4

CMPA #4

BBQ add-5

CMPA #5

BBQ add-6

CMPA #6

BBQ add-7

BEQ add-8
**************************************Out Of range branch
few-mid5:

BRA fcw

fccw-mid5:

BRA fccw

set-push-mid4:

BRA set-pusthidS

hcw-mid5:

BRA hcw

timer-1:

BRA timer-l-mi

d toc3-mid1:

97

BRA toc3-mid
********************III********************************
add-1:

LDAA #1

LDAB push-begin+1
BRA push-val

add-2:

LDAA #2

LDAB push-begin+2
BRA push-val

add-3:

LDAA #3

LDAB push-begin+3
BRA push-val

add-4:

LDAA #4

LDAB push-begin+4
BRA push-val

add-5:

LDAA #5

LDAB push-begin+5
BRA push-val

add-6:

LDAA #6

LDAB push-begin+6
BRA push-val

add-7:

LDAA #7

LDAB push-begin+7
BRA push-val

add-8:

LDAA #8

LDAB push-begin+8
BRA push-val
push-val:

STAA next-step
ORAB addr.sel ; push frame=data+address
STAB push-frame ; this is the push data
RTS

timer-l-rnid:

BRA timer-initO
half-ccw:

98

LDAA #8

STAA motor-mode
hccw:

LDAA curt-step
BEQ add-8 ; reqd steps are 8,7, ..... 1,8
CMPA #1

BBQ add-8

CMPA #2

BBQ add-1

CMPA #3

BBQ add-2

CMPA #4

BBQ add-3

CMPA #5

BBQ add-4

CMPA #6

BBQ add-5

CMPA #7

BEQ add-6

BEQ add-7

***************************************************

out of range branches
**************************************************
fcw-mid4:

BRA fcw-mid5
fccw-mid4:

BRA fccw-mid5
set-push-mid3:

BRA set-push-mid4
hcw-mid4:

BRA hcw-mid5
hccw-mid4:

BRA hccw

*****************************************************

end of init section
****************************************************
toc3_mid:

BSR push_seq-mid0 ; nearest push-seq

LDAA #20 ; this is the pull analysis part

CMPA toc-val

BEQ step-0

LDAA #30

99

CMPA toc-val

BEQ step-3

LDAA #40

CMPA toc-val

BEQ step-4

LDAA #50

CMPA toc-val

BEQ step-5.1md

LDAA #60

CMPA toe-val

BEQ push-normall

BRA timer-initO ; nearest timer also if toc-val=70
******************************************************
step-0

LDX #BASE

LDAA #6 ; check for 110 code

CMPA pull-val

BNE TI-step0 ; repeat until 110

BSET PORTD,X $08 ; set PD3

BSET PORTD,X $10 ; set PD4

BCLR PORTD,X $80

DEC prog-count

BEQ TI_step3 ; proceed with next step
BRA TI-step1-2

TI-stepO:

LDAA #2 ; ﬁrst two steps of programming
STAA prog-count

TI-step1-2:

LDAA #20 ; the next step is step-0

STAA toc-val

BRA timer-initl
*********************************************************

out of range branches
********************************************************
timer-initO:

BRA timer-initl

push-seq-midO:

BRA push-seq-mid

set-pusthidZ:

BRA set-push-mid3

few-mid3:

BRA few-mid4

100

fccw-mid3:

BRA fccw-mid4

hcw-mid3:

BRA hcw_mid4

hccw-mid3:

BRA hccw-mid4

step-5.mid:

BRA step-5
******************************************
TI-step3:

BCLR PORTD,X $04 ; disable PD2 for 5volts
LDAA #30

STAA toc-val

BRA timer-init

1

step-3:

LDAA #4

CMPA pull-val

BNE TI_step0 ; if 100 code,proceed to ovrbit program
TI-init-step4:

BSET PORTD,X $04 ; enable PD2 for 12volts
LDAB addr_sel

ADDB $08 ; setting D4 to 1 for ovrbit program
STAB push-frame ; new push for ovrbit
TI_step4:

LDAA #40 ; from second time onwards

STAA toc-val

BRA timer-initl

step-4:

DEC ovr-step

LDAA #6

CMPA pull-val

BNE TI.step5 ; code is incorrect

INC ovr-count ; correct code count for ovrbitprogram
BRA TI_step5

*******************

out of range branches
*******************

push-norma11:
BRA push-normal2
set-push-midlz
BRA set-push-mid2

101

push-seq-mid:

BRA push-seq-midl
timer-initlz

BRA timer-init
hccw-mid2

: BRA hccw-rnid3
hcw-mid2:

BRA hcw-mid3
fccw-mid2:

BRA fccw-mid3
fcw-mid2:

BRA fcw-mid3
*******************************************
TI.step5:

LDAA #50

STAA toc-val

BRA timer-init

step-5:

DEC ovr-step

LDAA #4

CMPA pull-val

BNE count-skip

INC ovr-count
count-skip:

LDAA ovr-count
CMPA ovr.step

BEQ TI-normal ; we are done with programming
err-chk:

TST ovr-step ; try 4 times before error service
BN E TI-step4

BRA error-service
********************

out of range branches
*******************

push-seq-midl:
BRA push-seq

*********************

TI-normal:

LDX #BASE

BCLR PORTD,X $04 ; clear PD2
BCLR PORTD,X $08 ; clear PD3- programming done.
BSET PORTD,X $10 ; set PD4 ok code

102

BSR set-push-midl ; get normal push value

LDAA #60

STAA toc-val

BRA timer-init

error-service:

BSET PORTD,X $18 ; set PD3, PD4 - for error code
LDAA #70 ; do nothing from now on. reset reqd
STAA toc-val

BRA timer-init

************

out of range branches
***************
push-norma12:

BRA push-normal3
timer-init:

BRA timer-init2
hccw-midI:

BRA hccw-mid2
hcw-midl:

BRA hcw-mid2
fccw-mid1:

BRA fccw-mid2

RT S

fcw-midl:

BRA fcw-mid2
*******************************************
push-seq:

*send bus violation
BSR bus-v3

send push sync

BSR push-sync

send push ﬁeld

BSR push-8

send pull sync and receive pull-data
BSR pull-3

RTS

bus-v3:

LDY #3

bus-n:

BSR delay1-25
BCLR PORTD,X $20 ; PD5 push bit
BSR delay0-25

103

BSET PORTD,X $20
BSR delay1-25 ; smaller delay
DEY

BN E bus-n

RTS

push-sync:

BCLR PORTD,X $20 ; PD5 push bit
BSR delay0_25

NOP

BSET PORTD,X $20
BSR delay0_25

NOP

BSET PORTD,X $20
BSR delay0-25

NOP

BCLR PORTD,X $20
BSR delay1_25

NOP

RTS

push-8:

LDY #8

LDAB push-frame
push-n LSLB

BCC goto-O

BRA goto-l

goto-O:

BSR code-1

BSR code-0

DEY

BNE push-n

RTS

gotO-1:

BSR code-0

BSR code-1

DEY

BNE push-n

RTS

code-0:

BCLR PORTD,X $20
BSR delay0_25

BSET PORTD,X $20
NOP

104

RTS

code-1:

BSET PORTD,X $20
BSR delay0_25
BCLR PORTD,X $20
NOP

RTS

************

out of range branches
***************
push-norma13:
BRA push-normal
timer-init2:
BRA timer-init3
hccw-midO:
BRA hccw-rnidl
hcw-midO:

BRA hcw-midl
fccw-midO:

BRA fccw-midl
fcw_mid0:

BRA few-midl
push.seq-mid2:
BSR push-seq
RT S
*****************************************
delay-75:

LDAA #22
loopl DECA
BNE loopl

RTS

delay0_25:
LDAA #1

loop2 DECA
BNE loop2

RTS

delay1-25:
LDAA #3

loopd DECA
BNE loopd

RTS

105

pull-3:

BSR send-1 ; sending pull sync bit

BSR delay0_25

BSR code-0

BSR delay1-25

BSR code-1

BSR delay1-25

BSET PORTD,X $20

LDY #0003 ; we read 3 bits

pull-next BSR delay-15 ; trying to read pull bit after this delay
LDAA PORTA,X ; move this label to prev line if delay rqd
ANDA #%00000001 ; test PAO pull bit

BBQ pull-0 ; the bit is zero

pull-1: LDAA pull-val

ORAA 7000000001

STAA pull-val

pull-0: LSL pull-val

DEY

BNE pull-next

pull-eof:

LDAA PORTA,X ; we read end Of frame. only delay is diff.
pull-eof2 BSR delay0_25 ; eof has 50micro pulse(20khz)
BSR delay-15

LDAB PORTA,X

SBA

BEQ err-eof ; if both bits are same, this is an error

RTS

err-eof BSET PORTD,X $10 ; set PA7, PD4 - for error code
BSET PORTA,X $80

LDAA #70 ; do nothing from now on. reset reqd

STAA toc-val

BRA timer-initJnid

delay-15:

LDAA #1

loop3 DECA

BNE loop3

RTS

************

out of range branches
***************

timerJnitB:

106

BRA timer-init-mid
*************************
hccw-mid:

BRA hccw-midO

hcw-mid:

BRA hcw-midO

fccw-mid:

BRA fccw-midO

fcw-mid:

BRA fcw-rnidO

*******************************************

push-normal:

LDAA #4

CMPA pull-val ; check whether status is ok code
BNE push-set ; repeat prev step if not OK
TI-next-normal

LDAA #1

CMPA motor-mode

BEQ mode-1

LSLA

CMPA motor-mode

BEQ mode-2

LSLA,

CMPA motor-mode

BEQ mode-3

BRA mode-4

mode-1 BSR fcw-mid
BRA push-set

mode-2 BSR fccw-mid
BRA push-set

mode-3 BSR hcw-mid
BRA push-set

mode-4 BSR hccw-mid
push-set:

LDAA #60 ; next push val
STAA toc-val

LDAA next-step

STAA curr.step ; overwrite currstep with the new step
BRA timer-init-mid
timer-initJnid:

nO_infO:

LDX #BASE

107

LDD T CNT,X

ADDD #5000

STD TOC3,X _
BCLR TFLG1,X %11011111 ; this will work only if'the prev
RTI ; part takes less than 5msec..

108

Ptolemy Schematics

 

Figure 7.1: The SMC Testbed Universe

110

 

Figure 7.2: The “SMC” Galaxy

111

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 7.3: The “mcu” Galaxy

112

 

 

 

Discrete Event (DE) Stars

 

 

Figure 7.4: Ptolemy Icons

 

 

bus

 

 

'lfcli

 

Signal gene

 

 

 

Coast

 

—>

 

 

+5-

. ____I

I

 

M.

—» INULL»

 

Tell

 

 

 

m,
rato '

IE

 

 

 

 

lllli’l

Signal Sources F97

 

 

 

I]:

->

 

 

 

 

  

 

Figure 7.5: Ptolemy Icons - Sources

113

 

 

 

 

 

Figure 7.6: Universe Parameters

114

 

 

 

 

 

       

 

 

mysuo I ,I rm mum

,1 mam  5 ’

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 7.7: The SMC Control Panel

115

 

 

 

 

 

Figure 7.9: The SMC Event Display

116

Orderthis docurrmt

MOTOROLA as ““475"?
- SEMICONDUCTOR M
APPLICATION NOTE ‘

AN475
Single wire Ml Bus controlling stepper motors

by Michel Burri & Dr. Pascal Renard
Senior Staff engineers. Automotive Group
Motorola SA. Geneva

1. Introduction

The Motorola Interconnect Bus (Mi Bus) is a serial bus and communications protocol which efficiently
supports distributed real time control. notably in automotive electronics. In addition to being a cost-
effective alternative to bulk wiring. it provides very high data Integrity as a result of continuous Push-Pull
communication between the system controller (Master MCU) and each device on the bus. It is suitable for
medium speed networks requiring very low cost multiplex wiring with high levels of noise immunity. The
MI Bus is suitable for controlling smart switches, motors. sensors and actuators with a single-chip
controller. The process control time can be about Ims. including diagnostics.

In automotive electronics the MI Bus can be used to control systems such as air conditioning. head light
Ievellers. mirrors. seats. window lifts. sensors. intelligent coil drivers. consoles. dashboard etc.

Figure 1-1 shows the general block diagram for the Stepper Motor Controller (SMC). The main parts of the
diagram will be discussed in the following pages.

+5V
1°“ +th
Programming and
Detection
L11
Bridge 00"” L12
Latch & L21
Motor Diagnostic
L22

Serial to Parallel Register

Parallel to Serial Register 20 kHz

Status
Encoder

 

Figure 1-1 Stepper motor controller block diagram

All trademarks are recognised.

® MOTOROLA -

0 MOTOROLA LTD .. 1993

117

"033192

IAXIWI RATINGS (All voltages «with reepedtoground. unless 0mm noted.)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ruin. w V‘I. UM!
Power Supply Voltage V
Corlinuoue Operlbon' Vcc 25
Transient Survival (Note 1) VLD 40
Digital input Voltme VI 0.3 to Vcc + 0.3 V
Output Current (T A .- — 40°C) Iocr 200 mA
Output Current (TA-100'C) IOHT 150 mA
Storage Temperature Tetg - 40 to +150 °C
Operding Terrperuure (Note 2) TA - 40 to +125 '0
Junction Temperature TJ — 40 to +150 '0
Pour Dissipation (TA - 100'C) P0 0.5 w
Lou Dump Tramient (Note 3) VLD 40 V
DC ELECTRICAL CHARACTERISTICS (Chmmucenoted undereonditiomiﬂVSVcc s155V.-40'CSTA$1m'C.
unless otherwise noted.)
W ”rebel Min 1» ﬂea um
WCumnt (Vcc- 15.5V) (Nob 4) lo - - 12 mA
OutptltCurrenthc-155V) lo - 120 - mA
H—Bridgesnumlonibhgeao-WOmAHNohs) Vow”) - - - V
TA .-4o'c - 1 .3 1e
TA I ”'6 - 1.2 1.‘
TA .1000 - 1.1 1.e
MdreeeProgramming comm-25°C) (Note 0) lpc - 1.2 - A

 

 

 

 

 

 

CONTROL LOOIC ELECTRICAL CHARACTERISTICS (Charm nobd under conditions 0.0 V s Vcc 5 1 5.5 V. - 40'C STA s

100-0. mleuotlnrwiee noted.)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

W W Iln m I. Uni
Oedllator (Nae 7) id 040 - kHz
MeeeegeTrmeSlothc-12V)(Nete0) t. 24.0 25 25.2 Ire
UWWDMBNcc-ii’VHNmﬂ ice “is - - 113
1m Ml—Bue Pull-Up Resistor Rpu 6.0 - 20 k0
lrnemal Ml—Bue Zener Diode Clamp Voltage Vd - 10 - V
Addrumgmnmingvamolmio) VI, 10 12 14 v
Program Energize Time tppw 200 1000 In
Ml-Bue Slew Rate AVIAt 1.0 1.5 2.0 VIII.-
MI—Bue '0' Level Input Voltage Threshold v). — - 13 v
Nil-Bu '1' Level Input Voltage Thmhold vm 2.4 - — v
Ml—Bue'O'l-evelOmputVoltageOo-mmA) VOL — - 1.0 V
Poem-On Reset Time (Vcc 2 7.5 V) Ipor - 250 - Its

 

 

 

 

 

 

m: 1. TMWWimuhmmnmbMﬂhMmduyﬁmwu-nThedﬁetbnonenmmmal

”War

zmmm'ng'ven-aoomienemuu‘mun

WWhmhiﬁmW.

319.301.111.1th 'nduct'uetramiedvollageWonanmmmmwnnamldmummmbhw
amnieproducingchargecurert.TheddedbnonanmlageeendiieneeueealH-Brmbheww.

 

 

emcmnmbom H—anQee'ehom uni-12.0).

5. H—BridgeSetuationVolageiereiereneedlothe peeitiveeupplyorgromdreepeetivedttuH-BrmeoupinbemHidiorm.
SdmﬁonwthBUnvoR-gedoplmthemtothepoemmmmH'gh)andthevolhgednptoyowd(wﬂhmw.

5. mmmimCmmnmwmmmebd12Vdu1'maddre-W.

7.A1ypieaqu>lieebonueeenexierrnleeram1ereeembreryual mmeirequneydmld-lz AniMapedhrhnnldMoemicWie
inedteeﬂtmefreqmmybttlewomnmduokﬂz. mdehoedhbriWonhmwmic
mordutoleraneﬂuemlty 11.0%).

0.TheMe.ageTrneSletisthei'me ”muommwwmtmmmbWDaWMMMdh
whirring-mined.

0.llitan—Buebeeomeeehomdbgomd.“Winmﬁluwmepwdnhmmw.

10. Ml—Buvolhpreqiredloredteeeprogmmhg

 

MOTOROLA ANALOG IO DEVICE DATA

118

MC33192
GENERAL DESCRIPTION

TheMcsawzieaeerlaleteppermotoroontrollerlorueeln
harsh automotive wplcatlons using multiplex wiring. The
M033192providosdln1eneoeeearylourphaeedhreeignde
tooontroltwophaeebbolarsteppermotoreoperatedlnoither
Mlorlullatepmodee.Multpleeteppermotoroontrolenm
beeperuedonarealtlmebuieuetoplremeneieeupto
200 Hz uelng a ehgle microcontroller (MCU). A primary
WooloperationietheutllzaﬁonolmeMl-Buameeeqe
mode to provide high noise immunity oommunicdion
munveryhlghoperatlngreliwilityolmotoretmping.

Themmziedeelgnedtodrlvebpolsatemernm
Invingawi'idngreeletanoeolaoaatzo'Cwilhaeippiy
vohgeot12V.ltieetpplledlnaSO-16Lplastlcpeokme
havingoightpim.ononeelde.oonneoteddrealytothelend
Irine lhue orihmcing the thermal palormmoe to alow a
powdeepellonolOSWaHZO'Camblentterm.

MpIOSInmltaneoueWOper-euon
Severalmotorecanbeoontrolledinaeerialf-hbnmne
haedotemineetheetepheqlenoyollhemobreJeinde
motoroanbeoperatedatamaxknumepeedolmOI-h
pul—lnwlthadnratlonodemeperetothreemotoreom
beoperuedeimulaneanlyueingasaflcosBBMCUatme
mtimeboe(200Hz)withdaout1.7mpor¢op.A
551-1011 mUcmoontroHeteppermotonwith
prograrneteptlme.Theeteplrecpencymuetbedooreuedto
control additional motors. To control eight motors

dnwhneoulywouldrequrethemotorepoedtobe

deaeaeedto100Hzprowdngmzowtlmedlration
persiepwithadeqlateprogramtrne.
Ul-BueGemnlDeeodptlon
‘I'heMobrolalnteroonnectBueMi—Bue)haeenal
push-pull communications protocol which efficiently
elpportadietrbutedrealtinwoontrolwhlleexhbltlngahlgh
levelotnoleei'nmunity.
UndertheSAEVehlcleNetworkoﬂegodeeJheMl—Bueie
aClaeAbuewithadataetreemtramlerbltrateinexoeeeol
zouumdmmhmlothehunmeamtrequlreea
elnglewiretocarrylheoontroldatabetweenthemaﬂerMCU
mdiaalavedevloeelhebueoanbeoperdodatlengtheip
to15metera.
Atzomzdieﬂrrwebtueedtooorwmmew
(2511:)eenbehendedbyeoltwweueingmanyMCUa
Wentherntitet.
TheMi-Bueieeumlelormedunepeednetworh
requnngverylowooetmulbbxvﬁiu.uldefmmgromd.
mmmmmmmmm
MCUtomumeelavemaamzdevloeeMthlndeld
contra

AeingleMl—Bueeenaooonplleheirwhneouewtomotive
eyebmoontrololAirCondlioning. HeodLarrpLevellerl.
Window um. Sensors. Intelligent Coll Drillers. etc. The
M—Buehaebeenfoundbbeooeteﬂealveinvehldebody
clearonlcebyreplachgtheoorwentlonalwirlnghameee.

Fimlreiehowetheintomdhlookdqamdhmiﬂ
ShmerMohrConlroller.

Flgure1. mnsbpperﬂotorComllerllooltDlem

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

m» z m -
1" DEF "‘“°"“' —<I:]:i
' nude m avid-r
50V mm _]
1011 5.0Vc—I “I”; IllO'thclT)
[.___. emu
W W i—“othm
Ludo-helm mm“ 2
' m" i
[Ionics
nu olive-u 1112(4)
In T"
r— es... ”I3“
312m
zoo
“(1)0J *[ anion-lemu- ] |
WV manhunt“- Irma! 111m
Simian

IE
it

 

 

 

 

 

 

 

 

 

 

 

 

 

 

NOTE:(‘)Pine2.0.10.11.12.13.14.15end10ceoomrnonelearlodandhedeinkgrwnd pinebrthedevioe.

 

MOTOROLA ANALOG IC DEVICE DATA

119

MC33192

U—BueAaeeeIethod

TheinlormallonontheMi—Bucieeenthafixedrneeeage
frame format (See Figure 4). The system Mcu can tale
controlofmeMl—Busatanytimewithastartbitwhlch
violieethelewofMancheeterBi-Phaeecodebyhevim
tiueeoomecutlveTrrneSlots(31.)heldconetmtiyataLoglc
'O'eme.
Pueh-PullCornmunicetionSequenoe

Communication between the system MCU and elave
10033192 devices always use the same meeeqe frame
organization. ThemU firsteendeeighteerialdetabiteover
theMl—Bueoorrprleedolﬁveoontrolblslollowedbythree
address bits. This corrlnunication serpenoe is called a 'Pueh
Field'sinceitrepreeentecornmandlnlormaloneenthomme
MCU.TheeeqlenoeoIthefivecont1-oldatabitefollowthe
orderDO.D1.DZ.DGandD4.Themreeadd'eeebitsareeent
irieerpentlalordeer.A1andA2deﬂningablnaryadaeee
code.TheoonditionofMl—Buedurlnganyofthecontrolbl
tirnewlr1dowedetlneeaepecil‘icoontrollunctlonaeehaunh
FigueZA'PulSync'bitieeentdtheendol‘therhFleld.
the positive edge of which causes al data sent to the
solededdevioetobelatchedintolheoutputclrwl.

FiguelehFleldDetaBlle

 

Dun Corerol Flotation

 

m inhiblte H—etidpo 2

 

Dir2 Establishes Diredion of 14-86ng 2 Currerl

 

E EnergizeeBridgeCoile1and2

 

Din Wishes Direaion oi H-Bridge 1 Current

 

898893

 

 

 

 

lnh1 Inhibits H—Bridge 1

 

AftermaPulISyncblieeentJollowhgthePuehFlelthe
MCUietemontheMI—Bueforeerlaldatabitaeentbackhom
theprevb11elyadrkeeeedMC$3192devioe.Thieportlonol
meoomrmnicatloneemenoeetartathe‘PuI FieldDeta"
elmeltrepreeenteinformaionpulledlromtheaddreeeed
MinandreoelvedbytheMCU.

Theadrteeeeelededmsaisedevlceeenamh
tintormoletaulebite.becktothemUreponingme
deviceeoondtlon.AtmeendofthePuehFieldlhemU

outputsaPuilSyncbitwhicheignalelheetertolthePuli
Field. InIhePullFieldareIhreebits(82.S1andSO)whlch
reponﬂiemdmeprevlouelyedd'eeeeducaalsz
mooninnglgurea.

ﬁgure 3. Pull Field m Bite

 

 

 

 

 

 

 

 

 

82 81 8 m Cour-ule
0 0 0 Not used
0 0 1 Free
0 1 0 No Bed: EMF Drivers end/or oolh tailed
0 1 1 Free
1 0 0 Normal/OK
1 o 1 Thermal Chip tempemure > 1501.:
1 1 0 Programming PROM energized
1 1 1 Selection tailed Noise on Ml—aue. felled or
dieoonneded module

 

 

 

 

 

 

 

ThepoeitiveedgeolthePullSyncpuleeuetbymemU)
conceallPueh FieidDetaeenttotheeeiededmsaiezm
beetoredlnmeoutputlatdicircultintlrnewlththeauobe
wheThbmeanetl'iedatabhareemittedinrealmie
eynchronizﬂlonwith the mU‘e machlnecycle. Theetrobe
pubeoocuraonlyalterthePuehFleldeerpenoeievﬂidﬂed
bytheadtieeeeeleaeddevlce.

IoeeegeVaiidetlon

Theoommunlcetion hemmemuwtheeeieded
Windevioelevalidonlymenmeﬂcum
(receives) the Pull Field Data having the correct oodee
(exchdng theoode'1-1-1'and‘o-o-O') followedbym
End-ol—Frarne signd. ThelreqrencyolmeEnd-ol-Frame
eignalmaybeaelb—nulitbleolmeeelecteddevloeelocei
oecillatororrelatedtoanlnlernalorexterndmlog
perarneterueingaVoltqebFremencyComemr.
ErrorDelection

AnerroriedetededwhenthePulFieldoornelmthecode
'1-1-1'folowedbytheEnd-ol—Frunepermu1entlytledba
Iogic'1‘atate(internalyirom5.ovmroughapulI—ip
resistor). ThiemeanetheoommmiceuonbehveentheMCU
andtheeelecteddevloewunotobtnined.

 

 

 

 

 

 

ﬁgmﬁﬂl—Bue‘ﬂrnlngblegrern

L Frerie A,

r7 'l

L mm 4‘ PilFidd 1

w “r '1

] PushSync 0‘: m ] M EM-ol-Frne

i i‘ T 'i II 'I I

W 3"
ui-enwn
I I1'2'3'4's's 'e's|1]2'34] I
I am ]'1"'0' oo 01 02 0:1 04 m A1 A2 Iva-Israeli set]
unz

I I B—theCoded Coded m

I I mm+q [ Fin-my ]
+32-2011Hz

Lee-'- .1... “”4 i

r T 1 I

 

 

ism-Nu

 

120

MOTOROLA ANALOG IC DEVICE DATA

”033192

Thereareiourtypesotsysternerrordwdlomwhichere
notrmtudyexciueiveﬂheeeue:
1)NobeDetectlon

TheeyeternMcamOZslevedevicesreceivethePush
FieldrnessegeiromtheMCUMoeloreeohmieSloHt.)
oitheBi—PhaeeCode.Areceiveerroroccurewhenthetwo
meesqesarrpleel‘u‘lb‘logicwbe’matohJNloieeand
Bl-Phese detectionledsa-sediurtherunderMeesage
Goring.
2)Bl—PhaseDetection

Thesyetemelendevioesreceivingthei’ushl-‘leld
messqelromihemUdetedmeBi—PhaeeCodeA
detectorerrorocwrsehenthetwotirneslotsottheBi-Pheee
CodedonotcontainmExclueive-Oﬁlogiclunction.

3)FieldCheck
Alielderrorhdeteaedwhenalixed-tormbllleld
containsmirrpropermmberoihitstlterrorcanaleobe
detectedbythemUchringthePush Field.TheMCUcUI
sheiltaneousiymonibrtheMl—Busatthetlrneitlseendng
”Awmisdetectediltheeentbitvduedoeenot
mmevduewhldiwasmonitored.

4)UrgentOutputDisdile

it the Ml—Bus becomes shorted to ground. the slave
devioeouputswillbeded:ledatteraperiodotﬂ..TheMCU
belcerthlueadrentegeolthisleemreto'globeily'disdile
theouMotsilsystemsiavedevicesbykeepingthe
Ml-Busdaiogic‘O’levelloradurationotstgormore.
Normd operation is resumed when the MCU senth e
'stenderd'instructlonovertheM—Bus.
BeeloStepper Uotor Construction end Operetlon

Steppermotorsareoonstmctedwﬂiapermanentmegnet
rohrmagnetizedwithmesemenunberoipolepairsu
conteinedinonestatorcoileection.®erationally.stepper
motorsrotateatconstantincrernentalanglesbysteppingone
supeverytirnethecurrentswitchescﬁscretelyinonestdor
iieldooiiceusingtheNorth—Southetatoriieldtorotateeither
clockwise or counter—clockwise causing the permanent
magnet rotorto follow (see Figure 5). For sirrplicity. usume
thestarthgcondtionoitheMtoAzetatorﬁeldbbetcpb
bottornpoleﬂzedNtoSendtheBleZstatoriieldtobelelt
torightpolerizedNbS.Theresulthgstatorlieldwiilprorhce
avectorwhichpointeinthediectionoipoeitionaJherotor
wl.hmiscae.behthepositionsimninFigure5(pohting
toposition 1). Thlsintlalconditioncorrespontbtothuoi
etep1inFigure6.AsmedreotionoictirrentllowinmeB1to
82statorﬁeldisrevereed.metieldpolarlyolme81t082
dsoreversesandisleittorightpolerizedStoN.Thiecauees
thereeultingetatoriieldvectorbpoinththedrectlonol
position4.ThisintumcausestheN—Srotortoiollowend
roue90°inaclockwbedrectionandpointinthedrectionot
MazThbcondtloncorresporuhtoatepZOiFigurea.
Continueddockwherotorstepswilbeexperiencedaetl'ie
strloriieldcontinuestobeincrementalyrotatedaeshawnin
shpe3.4.5.etc.olFigure6.The90‘etepeinthiesimplistlc
exarmleconetitute ‘tulletepe'Jtietobenotioedthatboth
code. in the foregoing lull step example. were simultaneously
energizedinoneoltwodrectlonthispossbletoincrement
the rotor in 45' "intermediate steps' or 'hali steps' by
alternably energizing only one stator coilatatimeinthe
mpropriete direction while turning the other stator coil ol'i.
TheaivesignabiorHaltStepopemlonareshmin

Figure7.ThePoereroutputstnesottheMC$3192consist

oltwoFi—Bridgeecweoldiving til—pols
pennenent magnet motors in either hell or full step
increment.

FIgteetPermnmmperletor
A1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MOTOROLA ANALOG IO DEVICE DATA

121

"633192

Permanent magnetic stepping motors exhibit the
characteristicdlilitytoholdashdtrotorpositionwimor
wthout a stator coil behg energized. Normally the shit
hoUhgdaiiityolthemotorwithastatorcollenergizedls
relerredtoae'i-loldngTorme’ while 'Residuel Torque'or
‘Detent Torme' refers to the shaft hold'ng wiity when a
“or col is not energized. The Holdng Torque value b
dependentontheinteractivemagneticiorcecrestedbytl’re
resultingenergizedstatortieldsw'shthatoltheperrnment
mnetrobr.TheResldralTorqueisalunctlonolthe
physicslstzeendconposltionoltheperrnanentmagnetrotor
Mootpledwlhitehtrinelcmqnetlcattremionlorthe
m—energizedstabrcorernsteriaiandasaresul.theweeker
oithetwotorques.

Itistobenobdwhenusinghaiistepoperdlonmnlyone
coll b energized during elernde step periods which
prowess a somewhd weeher Holdng Tome. Holdng
Terms is maximized when hon ooﬂe ere simultaneously

energized.lneddtion.sinceeechwindngandreeultlngﬂux
cordtionserenotpertectiymadiedloreechhallstep.
incrementelaccuracyisnotasgooduwhenhrllsmlng.

MPheeeDriveSlgIels
TheDlR1andDiRZbiteintheDdeFmreolthePueh
Fielddeterminethed‘eectlonoll-l—Bridgecurrerlflow.“
tiersthenmneu‘cileldpolarizationotthesuorcoileJor
H-Brldge outputs 'A' and '8' respealvely. The drectionel
signals DIRI and DIRZ. generated by the MCU.
comrnunicete overtheMi-Bustocontroltheton—Brldge
poweroutputstageeotthemsawzmdlvetwophaee
bhohrpermanentmemetmotors.Figure8showethe
Wteztruthtwb becoorrplsh hcremental stepphgot
themotorheclodeviseorcounter-clockwisedirealonh
eitherhallorlulstepmodes.Thestatorlieﬂpolarizationend
robrposlionareelsoshowniorrelerencerehtivetothe
beeicdepperrnotorotFigure5.

msmrmummmmmmmmuwr'

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

PushFiddaI
slap on 01 02 as or mom a: a m
Pal 11:11 in!“ 01111 E are rare A1 A2 31 u ("a") (Nob!) m
1 1 1 o 1 o 1 1 o 1 o \ \ ccw
- 2 1 o 1 x o 1 o z z I I ii
2 a 1 o 1 1 1 1 o o 1 / /
- 4 o x 1 1 1 z z o 1 —. ' .—
3 5 1 1 1 1 1 o 1 o 1 \ \
- e 1 1 1 x o o 1 o o I I
4 1 1 1 1 o 1 o 1 1 o / / v
cw
- e o x 1 o 1 z z 1 o ._ _.
o x x x o z z z z
1 1 0 1 1 Z 1 z 1
1 o o o 1 1 z 1 z
1 1 o o o z 1 z z
o o o 1 1 z z z 1

 

 

 

 

 

m:1.x-Don‘twe;Z-Highinpethnce;1nHiﬁuectwe'onjstIem-Lowaldve'mm
zmmmamwmndmmmmmwnmmmuwm

mermotorshewnin Puma.

10lﬁ1ﬂl'ehestherﬁecﬂonotcurernﬂowinH-8ridp'k.
4.0lﬁZeddﬂ'ehestheﬁecionolmentilowinH—8ridge'a’.

 

122

MOTOROLA ANALOG IO DEVICE DATA

MC33192

Ill-Businter'feceoeecrlptlon
Them—BulmerfaoeehowninFigureaismedeipofa
slngleNPNtransistor(Q1).Thetwonninhrnotlonsofthls
NPNtransistorare:
1)TodivetheMl—BusduringthePushFieldwlth
minarerZOonfcurrentwhilealsoestﬂnglow
slmationcharaderlsticchagag.
2)Toprotedthelrput10um( )pinofthemUagdnst
my Eiectro-anetic interference (EMI) cqatured on the
buswire.
WihouttheNPNtranslstor.theMCUoouldbedestroyed
neresultofreceivingexceesiveEMlenergypreseruonthe
bus.lnaddtion.thetransistorblockstheMCUfromreoelving
EMI signals which could erroneously chmge the thta
dredionregisteroftheMCUl/O.
ThemUlruitpin(Ph).ueedtoreedthePullFieldofthe
Ml—Bus.hprotectedbytwodiodes(oeand03)mdtwo
resistors(R5ande).AnytransientEMlgenerabdvoltme
presentonthebusisciampedbythetwododestoa
whdomedvolagevduenottobegreebrthentheVooor
lesstl'iantheVsssupplyvolmeeofiheMCU.

H—BmLevels

TheMl—Buscenhaveoneofteovdldlogicstdes.
reosssiveordominantJhereoeesivestdsconeqaonatoa
Lodc'l'mdisobtainedthroughuseol‘afompull-ip
resistor(RQ)to5.0 V. Thedominentmoorreqaondeba
Logic‘O'whichrepreeentsavolagelesinenoavm
0'“ by "'0 VCE(sat) of Q1.

Il-BueOvervoltegeProteotlon

An external zener dode (21) is lncorporded h the
interfacedrcuitsoasbprctecttheMCUWlePm‘)
from overvolaoes commonly encountered in automotive
mplicationsasaresultofioadDunp’ md'JurrpStur
conditions. LoadDwrpisdefinedastheiruictivetransient
generatedonthebatteryiineasaresulotopeningthe
batteryconnectionwhilethealbrrnorsystemisprowcing
chargecurrentJurrpStartovenroltagesaretheresultof
paralleling the inetdled automotive battery. through the use
of'jurrpercdlles'Joanextemalvoltageeourceinexoese
of the vehicles nominal system voltage. For 12 V
arbmotivesystemthiecorrlnonforZAtV'jumstut'
voluestobeused.

Whenanovenroltagesitudlonbmwmtmdretos
beddrnporjunpstartcordtionJhezenerdodeRst
activatedandstppliesbeeecurrenttohrmontheNPN
muorOfcsusingthebustobepulledtoleesthanoav
prearcingaLogic‘O'ontheMI—Bus.Meredurdlon
oorrespondngtost.(200pe)olcontinuoustogic‘0'onthe
buealiM033192devioeswllded>letheiroumutmNornd
operaticnisresurned. folowingtheovervolmemytheMCU
sendngouta'standard'messageinetructlon.

ﬂ—BueTerrnlnetlonNetworft
‘l'heMl-Busisresistlvelyloededeccordngbtherernber
ofM033192devicesinstaledonthebus.EechMm3192
hesaninternal 10mpuI—up resistorb5.0V. Anexternd
pul—upresistor(R7)isreconlnendedtobeueedtooptimdly
edhrsttermlnationofthebusloraloedreeistanceofeooa

FlgureOJll-BueHCUlnterlece

 

 

 

 

 

 

 

 

 

 

 

 

“ ’ ‘ 12V
m 1‘ sov 71—
gqv nun sov es Vcc
112 37 v
r—i—ﬁ 21 (1211) 2‘" 'T (12*) re as W
I VDO I :: 81 f (13V) I.” 1 1 m ) (go
. . «’(mo . - V 11>”...
I I m 22 =:
R
I a II") 02 i..— g?
I 2 am
I a 2
I n mucmszom
I_ as
.1:- 0V

 

MOTOROLA ANALOG IC DEVICE DATA

123

"033192
MESSAGE WONG

Bi—PhessCodlngsnsttsctlon
TheManchesterBl—Phuecodsshownin Figure 10
remirestwotimeslots(2t.)toencodeasinglerﬂabit.This
alowsdetectlonofasingleerroratthetirnesiotlevel.The
Iogiclevels'f'or'O’aredetennhedbytheorgmlzationof
thetwotirneslots.Thesealwayshaveoorrplernentarylogic
levelsofelhsrzsrovoltsorplusfivevolts.whichare
denoted ushg at Exclusive OR detection circuit airing the
PushFieldseqrenoeA'f'bitisdetectedwhenthefirsttlrne
slotiseetbazerologicstate(0V)followedbytheeecond
timeslotsettoalogicstateone(5.0V).Conversely.a'0'bt
isdetectedwhenthefirsttimeslotissettothelogicstrse
'ons'(5.0V)followsdbyaseoondtirnselotssttoa‘zere"
logicstets(0V).ForthssstwobitsareExciusivs-Oﬂsof
eedlother.
TheaddreseeddevicesrsceivingthePushFielddstsct
the Bi—Phase code. Bi-Phase detection involves the
surplhgofthePushFleldBi—Phasecodetwice(aandb)for
sechtimeslotAcodesrroroeourswhenthetwob‘msslobof
theBl-PhasdonotfollowalogicaiExdusive-Oﬂfunction
(sesFigurelO).
NoisemonltorlngisacoorrplishedbysanplingthePush
FieldBi-Phesecodstwics(aar1da')md(bandb')durlng
eechtirnsslot.Anoiseerrorisdete¢ediftheMoemus
velussmnothevethssemslogicsllevel.

Flgue10.NolseIBl—Phsssttsctlon

2':
WV) l W'I')
5.0V . I
PiehFisld I l l l
'B-Plus |
Godsdﬂb l —.t

01234561012315070

s b a b m

NH»...

Eachmessegefrerneconsistsoltwofislds:ThePueh
Field.inwhiohdatamdad¢essesuetrmeferredbythe
MCUtotheslave device;andthePullField,inwhichserid
thtaistransferredbacktotheMCU fromtheadrress
selsdedslavedevice.Themessagelrarneisbrokendown
into seven indvidual field segments as hdcated it Figure 4
(Start. Push Field Sync. Push Field Data. Push Field
Address. Pull Field Sync. Pull Field Data. and
End—of—Frame). The followhgliststhebitsizeandfundion
ofeaoholtheeesegments:

1)81srtisthestartofmessegeandconsistsofthreelime
slots(3t.)havingthedorninantLogic'0’stateoflessthan
0.3 V. Holding the Ml—Bus at ground forthreetlmeslots(3t.)
marlcsthebegimingofthemessagefrarnebyviolatingthe
lawoftheMImchesterCode.

 

 

 

 

2)PushFl‘sld8yncisashglebltwhichsstdzlishesinitial
timinglorthePushi-TeldDataiololow.

3)PuehFlslsthiscornprisedoffiveseridﬂebl
fiela(D0.Df.Dz.DoandD-1)whichconprisemeinstructlon
setdefiningtheconflgurationandcondionofthetwo
H—Bridgeoutputstages.

4)PushFlsldAddrsseisoonprbedofthreessrldd¢a
blilelds(A0.A1andA2)whichdsfhsthsedasssornuns
ofehDSSlﬂontheMl—Bus.

5) PullFlsldSyneisasingleblwhiohestdalishesthsend
ofthsPushFieldandtheinltleletarttirningforthsPulField
Duetofollow.

5)PullFlslsttsismadstpofthresserieldatebeielrh
($2.81and80)whichcoredrnhsexistlngmhfornetlon
ofenadd'ssseducaafoa.

7) End-of-Frsmsfieldisasigndwhlchoorrswnicabs
totheMCUthatﬂrestatusinlonnllonssntbythsMme
is .

ThePushFlsldSyncbl.PushFisldDetebis.PushFisld
Adleesbits.PullFieldSyncbitaredlcodedbythe
MurchesterBi—PhaseLCode.ThePullFieldDatabitsare
Non—Msntolero(NRZ)coded.TheEnd—ofFrameflsUls
asqrarewaveslgnalwithalrequencyonOld-lzorhighsrso
ntosvoidacondtionwhichceusssabusviolation.

ThsWIchestsrBi-Phaschodsrequireshwotlmsslots
(21.)tosncodeashglebit.Thisallowsasinglserrortobs
debcteddrrhgthstimeslot.

Address Pregrsmmlng involves the use of three
situations. Refer to Figurefo.

FlrstlnetrtwtlonSettlieMi-ﬁeconltmlydfzv.
This places the “333192 in the programming mode.
PregranmingispoesbleonlywhsntheMl—Bue'eatlzv.

Next.theMCUserielyenters"LogicZeroe'inallfivePush
FieldDatabitpositions(Do. 01.02.00and04)followedby
thedesignatedaddessvalueinthePush FieldAdtisss
positions (A0. A1.&A2).

ThemUnowwalts275usbsforsehrtlngthssecond
lnstruction.Thetotaioftl'1ePuiltirne.Deleytine.andBus
VioletlontimeMofthesecondimtruaion(150us.275pe
and75usrespectivefy)wilceusethememorycellbbe
energizedforsoous.Duringthefirst150psofthistime.the
MCUischeckingthePullFieldDataBitsSZ.Sf mdSO
looking for the programming code “110” to kidcete
corrpleteactlvationofthememorycell.

SecondlnetructloMMl-Busvolage rerndningd12V)

TheMCUrepeatsthesamePush Fieldinstruaionu
previously sent in the First instruction; entering all “Logic
Zeros'inthePush FieldDdaposiionsloIlowedbythe
designated Push Field Addess value in the “dress
positions.

Again.theMCUeUtsforthsPull,Dehy.andBusviohtlon
tirnewhilechecldngthePullFieldDatabitslookingforthe
progrernmlngcods“110”code.TheMCU mustrepedthe
initial Push Field Actress 'nstrudlon until a ‘110’ code is
received before advancingtothe Third Instruction.

Third lnstructlonThle—Bus voltageisloweredto5.0 V.

The MCU seriallyloedsiogicZeros'inalfive Push Field
Danbitpositions followedbythe programmed addresshthe
PushFieldAdtesspostiontheMCUthenchecksthsPull
Field Address status bits looking this time for the

 

124

MOTOROLA ANALOG IC DEVICE DATA

MC33192

programming OK code “100" indenting the add'ess
progmnmingtobeexecuted.
TheFirstmdSeoondlnsmmonsmustberepededuntii
the WU succusfuliy receives the programm'ng code
'100'. Addessprogramming isnotconplete until a'100"
mmemwtllsMCUwitfitfleMi-Busvome
at5.0V.
Overwrlts-Blt Programming involves the use of two
iristrtrdions.SeeFigurs11.
FirstlnetructlonHavetheMi—Buacontinuoualysetat
12Vsoastohavethem33192intheprogramrreigmode.
Progrenmingcenoniybeaooorrplishedwlththle—Busat
12V.
ThemUserlailyenters'LogicZeroa'forthsPuahFIeld
OubitsDo,Dl.02and00andaLogic'1'iorD4bit
folorredbytlreprogramnedaddessbitsAD.A1artdA2.
TheMCUnowwaits275usbeforestsrtlngthesecond
instruction.ThetotalofthePulltime.Deiaytine.mdBus
ViolationtimsMofthesecondinstmctlon(150us.275ps
and75psraapectively)wilcausethememorycslibbe
snuglzedfordtllps.0urhg01eﬁrst150psofmistim.dle
MCUiachecldngthePullFieldDataBitsforthestamsobes
82.81and80bokingfortheprogremmlngcods“110”to
lndcatsoonpleteaotivationofthememorycsll.
8scondlnstructlon(Ml—Bus remainingat12V)
TheMCUrapedsthefirstinstructionoutllnsdaboveunti
theprogrsmrnlngOKcods"1tll”iseentbacl1bthsMOU
from the selected M633192 indicating the overwrite-bl
protection to be programmed. If after eight repeat
lnatructions.thsprogrammingcode'110'ortheOKcods
'100" is not generated four times in succession.
prograrrsnir1goftheMC33192hasfaliedethisoccurs.the
Overwris—BitPrograrmringssqrenceshouldbsreviewed
mdre—atertedfromthebsginnhg.

H—Brlds- 0mm

The H-Bridge output dive circuit and associated
dagnosticencoderareehoeminFigure 12. The
outputusesintsmaldodeclanpsmf. 02. Da. D4)toprovide
transientprotectlonoftheoutputransiatorsnscesaarywhen
swbhingiruictiveloadsassoddadwlhmermotors.

MEMFDstsctlon
ThreediferentBackEMFcurrentaanoocurdspendng
onwhetinrthemotorisrursiingormmnerhwhichithbeing
shpped.ReferringtoFigure12;WhentheDir1bitissetb
iogic0.thedrectionolcmentf|owwillbefrochcthr01m
truuistorOR.CoiIA(A1toA2).andtrmsistorO4bground.
1)FsetDscey(whentransiators01.02.0GandQ48e
switchedoff).
Whgnthecurrentflowinginthecollisshmadbysetthg
theinhfbitblogicOJhebacltEMFcurrentwilcirueate
throughthevoltagestpplywccnndcﬁodeamandoaﬂ
thdtime.thevoltagedevalopedacrossthediode01is
detectedbytransistoroofhegeneruedvoltmepuiaeofm
is then encoded and sent. in the Pull-Field. to the

2)8lostcey(03andQ4areswitdrsdoff)

Whenthecurrentflowingintheoolllssnppadbysetling
theEbittoloo’cOJhebackEMFcurrentwilicircudelvough
thedodeDtmdtransistoerwhichisareulyswitchsdon.

3)thnMotorleRunning

Therotationaldrection of themotor whenever
theDirbitstateischmged.WhentheDlrbitisciw1gedfrom
alogicOtoalogic 1.trensiators02md04ueswitchedoff
mdbansistorsQf md@mswhchedon.Atthistime.the
beck EMF current wil circulate from wound through dodes
DfmdoabthevolageaumlchQJnalcmetheback
EMFcunentswilbsdstededbytranaisbrsmandOd.

Figure 11. Address Programming Olsgsm

 

 

 

 

 

 

 

“Coils r110.

mecca

 

I
l
I
arm-m !
I

 

Errargyin
Msnrastl

:13- . —-‘P—-—_'—-t

 

 

'3
q
——-_——————E ——

 

 

 

 

 

 

 

MOTOROLA ANALOG IC DEVICE DATA

125

MC33192

Flgurs12.ll-Brldgs0utputbrlve¢lreuitand0lagnoatlc£nosder
V00

        
 

BE

31-30
M "71—31

Cd!

*m

on

 

 

 

 

 

 

 

 

 

 

ii...

 

 

dd-‘doooon
d‘OO-Adoog

 

 

‘0‘0‘9‘08

 

 

 

 

10 MOTOROLA ANALOG IC DEVICE DATA

126

MC33192

Figurs118lngleWirell-Buecontrolof08tsppsrllotors

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

11»va - ,
I l : 50- mumw
5.0V Proper
'w M
L -

1'
W 111 1.46. macaw
Pout
mousse 01
mm I
1.40. m1mw
Pin ‘4‘.

crew

i.- ’
" >140- ucaamow
mot?» macaw
I
>~~60- ucasmow
I
H010 m1mw
I
~60- mmow

 

 

 

 

 

w *5; 4! 4? *5; “SI ~55 {I

 

 

MOTOROLA ANALOG IC DEVICE DATA

127

11

 

MC33192

 

OUTLINE DIMENSIONS
DW SUFFIX
PLASTIC PACKAGE
CASE 751 G—02
(SO—16L)
ISSUE A
NOTES:
1. DIMENSIONING AND TOLERANCING PER ANSI
8X P Y14.5M 1&2

2. CONTROLLING DIMENSION: MILLIMEI'ER

. DIMENSIONS A AND 8 DO NOT INCLUDE MOLD
W0-01010-25)® m W

R .
MAXIMUM MOLD PROTRUSION 0.15 (0.0%) PER

.‘U

SID .

DIMENSION o DOES NOT INCLUDE DAMBAR

J PROTRUSION. ALLOWABLE DAMBAR

10x D Peornusrou SHALL BE 0.13 (0.005) TOTAL IN
T MAXIMUM

EXCESS OF 0 DIMENSIONA
IQ)! 0.010 (o.25)®| TI A (9' B ©| 1] MATERIAL common
F uiLLruETERs
mm
xj |‘- R X 45° i 1015 1%
_L - ‘
.11. . 4
ﬂ .1:
M ._. $4.2m

J 025 0.32
M 0° 7°
_P__1.lLl!l_.._LQ.§§_l
J_._93§

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Motorola reserves the right to make changes without further notice to any products herein. Motorola makes no warranty. representation or guarantee regarding
the suitability of its products lor any particular purpose. nor does Motorola assume any liability arising out of the application or use of any product or circuit, and
specifically disclaims any and all liability, including without " ' ' . ’ ' ' ' ‘ '4 a . Typical rarameters which may be provided in Motorola
datasheets and/o r ' M" d-varyin 4'“ , , " ' “ ‘ 'r ‘ , varyuver time. Alloperating parameters,including “Typicals”
must be validated for each customer application by customer's technical experts. Motorola does not convey any license under its patent rights nor the rights of
others. Motorola products are not designed, intended. or authorized for use as components in systems intended for surgical implant into the body, or other
applications intended to support or sustain life, or for any other application in which the failure of the Motorola product could create a situation where personal injury
ordeathmayoccur.“ ""‘, r ' ”‘ ‘r J ‘ in an, L " 4 ' ' ' ' ' ,Buy ' ' ", ” '
and its officers. employees. subsidiaries. affiliates. and distributors harmless against all claims. costs. damages. and expenses. and reasonable attorney fees
arising out of. directly or indirectly. any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that
Motorola was negligent regarding the design or manufacture of the part. Motorola and ® are registered trademarks of Motorola. Inc. Motorola. Inc. is an Equal
Opportunity/Affirmative Action Employer.

 

 

 

How to reach us:

USAI EUROPE] Locations Not Listed: Motorola Literature Distribution; JAPAN: Nippon Motorola Ltd; Tatsumi—SPD—JLDC. 6F Seibu—Butsuryu—Center,
PO. Box 20912; Phoenix. Arizona 85036. 1—800—441—2447 or 802-803—5454 3—14—2 Tatsumi Koto—Ku, Tokyo 135, Japan. 03—81—6521—8315

MFAX: RMFAXO@emaiI.sps.mot.com—TOUCHTONE 802—244—6609 ASIA/PACIFIC: Motorola Semiconductors H.K Ltd.; SBTai Ping Industrial Park.
INTERNET“: http://Design-NETcom 51 Ting Kok Road. Tai Po. NT. Hong Kong. 852—26629298

 

® MOTOROLA

M33192/D
|||l||||I||||Il|||||||IIIII|||llIIIIIIIIIIIIIIIIIIIIIII

128

 

 

BIBLIOGRAPHY

 

Bibliography

[1] Philip Koopman, ”Embedded System Design Issues(the Rest of the
Story)” ,International Conference on Computer Design, IEEE Computer
Society, Los Alamitos CA, 1996, pp. 310-317.

[2] “POLIS: a framework for hardware/software co-design of embedded
systems.” [Online] Available
http: / / www—cad.eecs.berkeley.edu / Respep / Research / hsc / polis-ﬁles.html.

[3] “Hardware-Software Co—Design Study.” [Online] Available
http: / / www.mcc.com / projects / hwsw-codesign / std_prop.html.

[4] POLIS User’s Manual. [Online] Available
http: / / www-cad.eecs.berkeley.edu / Respep / Research / hsc / polis .ﬁles.html.

[5] Felice Balarin, Massimiliano Chiodo, et a1, ”Hardware-Software Co-desz'gn
0] Embedded Systems, The POLIS Approach”, Kluwer Academic
Publishers, 1997.

[6] D. Harel, A. Naamad, “The STATEMATE semantics of statecharts.”
[Online] Available
http: / / www.acm.org / pubs / toc / Abstracts / tosem / 235322.htm1

[7] VIS(Verification Interacting with Synthesis). [Online]
Available “http: / /www-
cad.eecs.berkeley.edu / Respep / Research / vis / index.html

[8] “The EST EREL Language.’ [Online] Available
http://www.inria.fr/meije/esterel/

[9] C. Kuttner, ”Hardware-Software Codesign Using Processor Synthesis”,
IEEE Design 6'5 Test of Computers, Fall 1996, pp. 43-53.

[10] ”A D&T Roundtable, Hardware-Software Codesign”, IEEE Design 85 Test
of Computers, January-March 1997, 75-83.

[11] ”ASICS and Design Tools, Design Report, ’97 Paris Forum ”, Computer
Design, June 1997, pp. 53-64.

130

 

[12] CAR. Hoare, ”Hardware and Software : Closing the gap”, Transputer
communications, June 1994, pp. 69-90.

[13] S. Schulz, J. Rosenblit, et al, ”Model-Based Codesign”, Computer, August
1998, pp. 60-67.

[14] K. Buchenrieder, C. Veith, ”A Prototyping Environment for
Control-Oriented HW/ SW Systems”, ACM 1994, pp. 60-65.

[15] ”EDA Watch, Long Overdue Uniﬁed HW/ SW Co-Design Language Comes
to Light”, Electronic Design, May 13, 1998, pp. 60-62.

[16] D. Gajski, F.Vahid, “Speciﬁcation and Design of Embedded Hardware
Software Systems”, IEEE Design 65 Test of Computers, Spring 1995, pp.
53-67.

[17] D.Gajski, F. Vahid, et al, Speciﬁcation and Design of Embedded Systems,
Prentice-Hall, Englewood Cliffs, N.J.,1994.

[18] M. Srivatsava, R. Brodersen, “Rapid Prototyping of Hardware and Software
in a Uniﬁed Framework”, Proc. Int ’1 Conf. Computer-Aided Design, IEEE
CS Press, 1992, pp 152-155.

[19] D. Thomas, J. Adams, et al, “A Model and Methodology for
Hardware/Software Codesign”, IEEE Design 85 Test of Computers, Vol. 10,
' No. 3, Sept. 1993, pp. 6-15.

[20] R.Ernst, J. Henkel, et al, “Hardware-Software Cosynthesis for
Micro-Controllers,” IEEE Design 63 Test of Computers, Vol. 10, No. 4, Dec.
1993, pp. 64-75.

[21] R.Gupta, D. Micheli, “Hardware-Software Cosynthesis for Digital Systems,”
IEEE Design 85 Test of Computers, Vol. 10, No. 3, Oct. 1993, pp. 29-41..

[22] K. Buchenreider and C. Veith, “CODES: A Practical Concurrent Design
Environment,”

[23] BL. Coumeri, D.E. Thomas, ”A Simulation Environment for
Hardware-Software Codesign”,Euro DA C, IEEE Computer Society, Los
Alamitos CA, 1995, pp. 58-63.

[24] “HW/SW Co-Design for Embedded Systems”, Alberto S-V, ILP, March
1995.

[25] “Ptolemy”. [Online] Available http://ptolemy.eecs.berkeleyedu

131

[26] “The Almagest: A Manual for Ptolemy”. [Online] Available
http: / /ptolemy.eecs.berkeley.edu/ papers/ almagest/docs/ user

[27] “The Esterel v5 Language Primer”. [Online] Available
http: //www.inria.fr/meije/esterel

[28] [Online]Available http://www.eagledes.com

[29] F. Balarin, H. Hsieh, et al, “Formal veriﬁcation of embedded systems based
on CFSM networks,” Proceedings of the Design Automation Conference,
1996.

[30] M. Chiodo, P. Giusto, et al, “A formal speciﬁcation model for
hardware/software codesign for embedded systems,” IEEE Micro,
14(4):26-36, August 1994.

[31] Motorola Analog 10 Device Data, MC33192, Motorola Inc., 1996.

[32] Michel Burri and Dr. Pascal Renard, “Single wire MI Bus controlling
stepper motors”, Motorola Semiconductor Application Note, AN4 75,
Motorola Ltd., 1993.

[33] “The Handy Board”. [Online] Available
http: / / lcs.www.media.mit.edu / groups / el / Projects / handy-board

[34] “Interactive C for the Handy Board Manual”. [Online] Available
http: / / lcs.www.media.mit.edu / groups / e1 / Projects
/handy-board/techdocs/index.html

132

 

   

HICHIGnN srnre UNIV. LIBRARIES
[llllllllllllllWill][I][Ill][lllllllllllll
31293017791991