Microcontrollers: From Assembly Language to C Using the PIC24 Family [2 ed.] 1305076559, 978-1305076556

Citation preview

Microcontrollers, Second Edition: From Assembly Language to C Using the PIC24 Family

Bryan A. Jones Robert B. Reese J.W. Bruce

Cengage Learning PTR

Australia, Brazil, Japan, Korea, Mexico, Singapore, Spain, United Kingdom, United States

Microcontrollers, Second Edition: From Assembly Language to C Using the PIC24 Family Bryan A. Jones, Robert B. Reese, and J.W. Bruce

Publisher and General Manager, Cengage Learning PTR: Stacy L. Hiquet

© 2015 Cengage Learning PTR. CENGAGE and CENGAGE LEARNING are registered trademarks of Cengage Learning, Inc., within the United States and certain other jurisdictions. ALL RIGHTS RESERVED. No part of this work covered by the copyright herein may be reproduced, transmitted, stored, or used in any form or by any means graphic, electronic, or mechanical, including but not limited to photocopying, recording, scanning, digitizing, taping, Web distribution, information networks, or information storage and retrieval systems, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the publisher.

Associate Director of Marketing: Sarah Panella Manager of Editorial Services: Heather Talbot Senior Product Manager: Mitzi Koontz Project and Copy Editor: Kezia Endsley Interior Layout: Shawn Morningstar Cover Designer: Luke Fletcher Proofreader: Kelly Talbot Editing Services Indexer: Kelly Talbot Editing Services

For product information and technology assistance, contact us at Cengage Learning Customer & Sales Support, 1-800-354-9706. For permission to use material from this text or product, submit all requests online at cengage.com/permissions. Further permissions questions can be emailed to [email protected].

All trademarks are the property of their respective owners. Noted figures have been reprinted with permission of the copyright owner, Microchip Technology Inc. All rights reserved. No further reprints or reproduction may be made without Microchip Inc.’s prior written consent. All images © Cengage Learning unless otherwise noted. Library of Congress Control Number: 2014945697 ISBN-13: 978-1-305-07655-6 ISBN-10: 1-305-07655-9 eISBN-10: 1-305-07656-7

Cengage Learning PTR 20 Channel Center Street Boston, MA 02210 USA Cengage Learning is a leading provider of customized learning solutions with office locations around the globe, including Singapore, the United Kingdom, Australia, Mexico, Brazil, and Japan. Locate your local office at: international.cengage.com/region. Cengage Learning products are represented in Canada by Nelson Education, Ltd. For your lifelong learning solutions, visit cengageptr.com.

Printed in the United States of America 1 2 3 4 5 6 7 16 15 14

Visit our corporate Web site at cengage.com.

RBR: To my wife (Donna) and sons (Bryan and Brandon)—thanks for putting up with me. BAJ: To my beloved wife and to my Lord; soli Deo gloria. JWB: To all of my teachers. Thank you.

Acknowledgments The authors would like to thank the following individuals for their assistance in preparing this book: ■

■

iv

ECE 4723/6723 and ECE 3724 students for their patience during the development of this text and the accompanying software libraries. That includes ECE 3724 TAs Hejia Pan, Ian Turnipseed, and Ryan Nazaretian for their assistance during this transition. Ryan also served as an ECE 4723/6723 TA. To the members of the Microchip Academic Program team at Microchip Technology Inc. for their support in using Microchip products in a higher-education environment.

About the Authors BRYAN A. JONES received B.S.E.E. and M.S. degrees in electrical engineering from Rice University, Houston, TX, in 1995 and 2002, respectively, and a Ph.D. in electrical engineering from Clemson University, Clemson, SC, in 2005. From 1996 to 2000, he was a Hardware Design Engineer for Compaq, specializing in board layout for high-availability RAID controllers. Since 2005, he has served in the Department of Electrical and Computer Engineering at Mississippi State University, Mississippi State, where he is an Associate Professor. His research interests include literate programming, engineering education, embedded systems, and visual guidance for micro air vehicles. ROBERT B. REESE received a B.S. from Louisiana Tech University, Ruston, in 1979 and M.S. and Ph.D. degrees from Texas A&M University, College Station, in 1982 and 1985, respectively, all in electrical engineering. He served as a member of the technical staff of the Microelectronics and Computer Technology Corporation (MCC), Austin, TX, from 1985 to 1988. Since 1988, he has been with the Department of Electrical and Computer Engineering at Mississippi State University, Mississippi State, where he is an Associate Professor. Courses that he teaches include Microprocessors, VLSI systems, Digital System Design, and Senior Design. His research interests include self-timed digital systems and computer architecture. J.W. BRUCE received a B.S.E. from the University of Alabama in Huntsville in 1991, an M.S.E.E. from the Georgia Institute of Technology in 1993, and a Ph.D. from the University of Nevada Las Vegas in 2000, all in electrical engineering. Dr. Bruce has served as a member of the technical staff at the Mevatec Corporation, providing engineering support to the Marshall Space Flight Center Microgravity Research Program. He also worked in the 3D Workstation Graphics Group at the Integraph Corporation, designing the world’s first OpenGL graphics accelerator for the Windows operating system. Since 2000, Dr. Bruce has served in the Department of Electrical and Computer Engineering at Mississippi State University. Dr. Bruce has contributed to the research areas of data converter architecture design and embedded systems design. He has published more than 35 technical publications, several book chapters, and one book.

v

This page intentionally left blank

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv

PART I DIGITAL LOGIC REVIEW Chapter 1

AND

COMPUTER ARCHITECTURE FUNDAMENTALS . . .1

Number System and Digital Logic Review . . . . . . . . . . . . . . .3 Learning Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Using Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Unsigned Number Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Hex to Binary, Binary to Hex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Combinational Logic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Combinational Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 The Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 The Adder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 The Incrementer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 The Shifter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Understanding Sequential Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 The Clock Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 The D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Sequential Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 The Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 The Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 The Shift Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Encoding Character Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Review Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

vii

viii

Table of Contents

Chapter 2

The Stored Program Machine . . . . . . . . . . . . . . . . . . . . . . . .33 Learning Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Problem Solving the Digital Way . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Finite State Machine Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Finite State Machine Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A Stored Program Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Instruction Set Design and Assembly Language . . . . . . . . . . . . . . . . . . 40 Hardware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Modern Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Review Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

PART II PIC24 µC ASSEMBLY LANGUAGE PROGRAMMING . . . . . . . . . . . . . . . . .51 Chapter 3

Introduction to the PIC24 Microcontroller Family . . . . . . . .53 Learning Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Introduction to Microprocessors and Microcontrollers . . . . . . . . . . . . . . . .54 The PIC24 Microcontroller Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Program Memory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Data Memory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Arrangement of Multibyte Values in Data Memory . . . . . . . . . . . . . . . 60 Data Transfer Instructions and Addressing Modes . . . . . . . . . . . . . . . . . . .62 Register Direct Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 File Register Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 WREG—The Default Working Register . . . . . . . . . . . . . . . . . . . . . . . . . 67 Immediate Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Indirect Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Instruction Set Regularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Basic Arithmetic and Control Instructions . . . . . . . . . . . . . . . . . . . . . . . . . .74 Three-Operand Addition/Subtraction. . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Two-Operand Addition/Subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Increment, Decrement Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Program Control: goto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A PIC24 Assembly Language Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 C-to-PIC24 Assembly Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 16-Bit (Word) Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 The Clock and Instruction Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Review Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

Table of Contents

Chapter 4

Unsigned 8/16-Bit Arithmetic, Logical, and Conditional Operations . . . . . . . . . . . . . . . . . . . . . . . . . .95 Learning Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Bitwise Logical Operations, Bit Operations . . . . . . . . . . . . . . . . . . . . . . . . .96 Using the Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Using Shift and Rotate Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Using Mixed 8-Bit/16-Bit Operations, Compound Operations . . . . . . . . .105 Working Register Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 LSB and MSB Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Conditional Execution Using Bit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 Unsigned Conditional Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Conditional Tests in C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Zero, Non-Zero Conditional Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Bit Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Equality, Inequality Conditional Tests. . . . . . . . . . . . . . . . . . . . . . . . . . 116 Conditional Tests for >=, >, =, , >=, >, where A >> 1 reads “A shifted to the right by one bit.” A left shift of an unsigned binary value moves all of the bits to the left by one position, and shifts a new bit value into the LSb. If the new bit shifted in is a 0, this is equivalent to multiplying the binary value by two. For example, using a 0 value for the bit shifted into the LSb, the binary value

12

Chapter 1

■

Number System and Digital Logic Review

0b0101 (5) shifted to the left by one position is 0b1010 (10). If this value is shifted to the left once more, the new value is 0b0100 (4). The value 4 is not 10 * 2; the correct result should be 20. However, the value 20 cannot fit in 4 bits; the largest unsigned value represented in 4 bits is 24 – 1 = 15. In this case, the bit shifted out of the MSb is a 1; when this happens, unsigned overflow occurs for the shift operation and the new value is incorrect in an arithmetic sense. The C language operator for a left shift is > 1 = 0b0101 0011. Shifting this value to the right by one more gives 0b0101 0011 >> 1 = 0b0010 1001 = 0x29. Therefore, 0xA7 >> 2 = 0x29.

Combinational Logic Functions Boolean algebra defines properties and laws between variables that are binary valued. The basic operations of Boolean algebra are NOT, OR, and AND, whose definitions are: ■

■ ■

NOT(A): Is 1 if A = 0; NOT(A) is 0 if A = 1 (the output is said to be the complement or inverse of the input). AND(A1, A2, ... An): Is 1 only if all inputs A1 through An have a value = 1. OR(A1, A2, ... An): Is 1 if any input A1 through An has a value = 1.

Combinational Logic Functions

13

The C language operators for bitwise complement (~), AND (&), OR (|) are used in this book for logic operations. Thus, NOT(A) = ~A, AND(A, B) = A & B, and OR(A, B) = A | B, where the Boolean variables have values of either 0 or 1. Logic operations are also defined by truth tables and by distinctively shaped symbols. A truth table has all input combinations listed in binary counting order on the left side, with the output value given on the right side of the table. Figure 1.4 lists the two-input truth tables and shape distinctive symbols for the NOT, AND, OR, NAND, NOR, and XOR (exclusive-OR) logic functions.

Figure 1.4 Truth table, logic symbols for basic two-input logic gates

A NAND function is an AND function whose output is complemented (i.e. inverted); similarly, a NOR function is an OR function whose output is complemented. An XOR function is defined by the truth table shown in Figure 1.4 or can be expressed using NOT, AND, OR operators, as shown in Equation 1.1. The C language operator for XOR is ^, thus XOR(A, B) = A ^ B. Logically stated, XOR(A, B) is 1 if A is not equal to B, and 0 otherwise. Y = (A & (~B)) | ((~A) & B) (Exclusive OR function)

(1.1)

The distinctively shaped symbol for a Boolean logic function is also referred to as the logic gate for the Boolean operation. A network of logic gates is an alternative representation of a Boolean equation. Figure 1.5 shows the Boolean equation of the XOR function drawn as a logic network using two-input gates.

14

Chapter 1

■

Number System and Digital Logic Review

Figure 1.5 AND/OR logic network for the XOR function

Figure 1.6 gives the AND/OR network, Boolean equation, and truth table for a three-input majority function; so named because the output is a 1 only when a majority of the inputs are a 1.

Figure 1.6 AND/OR logic network for the three-input majority function

An important law relating to AND/OR/NOT relationships is known as DeMorgan’s Law, with its forms shown in Figure 1.7. A “circle” or “bubble” on a gate input means that input is complemented. Note that a NAND function can be replaced by an OR function with complemented inputs (Form 1), while a NOR function can be replaced by an AND function with complemented inputs (Form 2). Forms 1 and 2 of DeMorgan’s Law can be validated by comparing the truth tables of the left and right sides, while forms 3 and 4 follow from substitution of forms 1 and 2. Complemented inputs/outputs are also known as low-true inputs/outputs, and uncomplemented inputs/outputs are called high-true inputs/outputs. Through DeMorgan’s Law and the high-true, low-true terminology, the NAND gate of Figure 1.7 can be viewed as either an AND gate with high-true inputs and a low-true output, or as an OR gate with low-true inputs and a high-true output.

Combinational Logic Functions

15

Figure 1.7 DeMorgan’s Law and the high-true, low-true terminology

DeMorgan’s Law can be used to replace all of the AND/OR gates in Figure 1.6 with NAND gates, as shown in Figure 1.8. This is important as the physical implementation of a NAND gate using Complementary Metal Oxide Semiconductor (CMOS) transistors is faster and has fewer transistors than either an AND gate or an OR gate.

Figure 1.8 NAND/NAND logic network for a three-input majority function

16

Chapter 1

■

Number System and Digital Logic Review

Logic Gate CMOS Implementations

CMOS (pronounced as “see-moss”) transistors are the most common implementation method used today for logic gates, which form the building blocks for all digital computation methods. You’ll review the basics of CMOS transistor operation here and revisit the topic in Chapter 8 when discussing computer input/output. The “C” in CMOS stands for complementary, which refers to the fact that there are two types of MOS (“moss”) transistors, N and P, whose operation is complementary to each other. Each MOS transistor type has four terminals, three of which are: Gate (g), Source (s), and Drain (d). The fourth terminal is the substrate or bulk terminal, which can be ignored in this discussion. For the purposes here, you will view a MOS transistor as an ideal switch whose operation is controlled by the gate terminal. The switch is either closed (a connection exists between source and drain, so current flows between source and drain) or open (no connection exists between source and drain, so there is no current flow between source and drain). An N-type transistor is open when the gate has a logic 0 and closed when the gate has a logic 1. A P-type transistor has complementary operation; a 1 on the gate opens the switch, a 0 closes the switch. A logic 1 is physically represented by the power supply voltage of the logic gate, or VDD. The power supply voltage used for a CMOS logic gate can vary widely, from 5 V (Volts) down to approximately 1.0 V. A logic 0 is physically represented by the system ground, or GND, which has a voltage value of 0 V (VSS is also a common designation for ground). Figure 1.9 illustrates P and N transistor operation.

Figure 1.9 CMOS transistor operation

Multiple CMOS transistors can be connected to form logic gates. Figure 1.10 shows the simplest CMOS logic gate, which is the NOT function, or inverter. When the input value is 0, the upper

Combinational Logic Functions

17

switch (the P transistor) is closed, while the lower switch (the N transistor) is open. This connects the output to VDD, forcing the output to a 1. When the input value is 1, the upper switch is open, while the lower switch is closed. This connects the output to GND, forcing the output to a 0. Thus, for an input of 0 the output is 1; for an input of 1 the output is a 0, which implements the NOT function.

Figure 1.10 CMOS inverter operation

Note that a buffer function Y = A is formed if two inverters are tied back to back as shown in Figure 1.11. It would seem that a better way to build a buffer is to switch the positions of the N and P transistors of the inverter, thus implementing the buffer with only two transistors instead of four. However, for physical reasons best left to an electronics book, a P transistor is always used to pass a 1 value, while an N transistor is always used to pass a 0 value. Thus, in digital logic, a P transistor is never tied to ground, and an N transistor is never tied to VDD, so the two-transistor buffer shown in Figure 1.11 is illegal. Because of the rule given in the previous sentence, a noninverting CMOS logic function always takes two stages of inverting logic.

Figure 1.11 CMOS buffer

18

Chapter 1

■

Number System and Digital Logic Review

Figure 1.12 shows the transistor configuration and operation of a two-input CMOS NAND gate. Note that the output is connected to ground (both bottom transistors are closed) only when both inputs are a 1 value. Also observe that no combination of inputs provides a direct path between VDD and GND; this would cause a short (low resistance path) between VDD and GND, resulting in excessive current flow. The lack of a direct path from VDD to GND means that CMOS gates have a very low power consumption when they are not switching, which is an important advantage of this technology. The four-transistor configuration for a CMOS NOR gate is left as an exercise for the review problems. Figure 1.13 shows that a CMOS AND gate is actually built from a NAND gate followed by an inverter. Similarly, a CMOS OR gate is built from a NOR gate followed by an inverter. This clearly shows why replacing AND/OR logic with NAND gates via DeMorgan’s Law is a good idea. The resulting circuit requires fewer transistors, meaning it is faster, consumes less power, and is cheaper to manufacture!

Figure 1.12 A CMOS NAND gate

Combinational Building Blocks

19

Figure 1.13 A CMOS AND gate

Combinational Building Blocks Building logic circuits on a gate-by-gate basis is an exercise that can be quite fun, once. After that, you should look for shortcuts that reduce design time for complex circuits. One method for building complex combinational circuits quickly is to use combinational building blocks. The following sections describe some commonly used combinational building blocks; this list is by no means exhaustive. It should not be surprising that some of these building blocks (the adder and shifter) implement the arithmetic operations discussed earlier.

The Multiplexer A K-to-1 multiplexer (or mux) steers one of K inputs to the output. The most common mux type is a 2-to-1 mux (two inputs, one output). A select control input S chooses the input that is passed to the output. The operation of 2-to-1 mux is written in C code as: if (S) Y = A; else Y = B;

This C code description of a mux reads as “if S is non-zero, output Y is equal to A, otherwise output Y is equal to B.” The Boolean equation for a 1-bit 2-to-1 mux is given in Equation 1.2. Y = (S & I1) | (~S & I0)

(1.2)

Figure 1.14 shows the gate equivalent for a 1-bit 2-to-1 mux and how a 4-bit 2-to-1 mux is built from four of these 1-bit building blocks. The 4-bit mux symbol in Figure 1.14 uses a bus labeling notation for the A and B inputs. In this context, a bus is simply a collection of parallel wires; a bus named A with N wires is designated as A[N–1:0]. The LSb and MSb of bus A are A[0] and A[N–1], respectively. If N = 8, the entire bus A is labeled as A[7:0], the LSb is A[0], and the MSb is A[7].

20

Chapter 1

■

Number System and Digital Logic Review

Figure 1.14 One-bit 2-to-1 mux, 4-bit 2-to-1 mux

The Adder The adder takes two n-bit inputs (A, B) and computes the n-bit sum (A + B). Most adders have a carry-in bit input for the LSb addition and a carry-out bit output from the MSb addition. A full adder logic circuit that adds A + B + Ci (carry-in) and produces the sum (S) and carry-out (Co) is a 1-bit building block of most adder circuits. Figure 1.15 shows the truth table, Boolean equations, and logic network for a full adder. The same figure shows how to build a 4-bit ripplecarry adder from four 1-bit full adders; the term ripple-carry is used because the carry ripples from the least significant bit to the most significant bit. There are many other ways to build an adder; this is the simplest form of a binary adder.

Combinational Building Blocks

21

Figure 1.15 One-bit adder, 4-bit ripple adder

The Incrementer The operation of an incrementer is described by the following C code: if (INC) Y = A + 1; else Y = A;

The INC (increment) input is a single bit input that determines if the n-bit output is A + 1 or just A. An incrementer can be built from an adder by connecting all bits of one n-bit input to zero and using the carry-in input as the INC input. This computes the sum Y = A + 0 + 1 when INC = 1 or the value Y = A + 0 + 0 when INC = 0. There are more efficient methods in terms of logic gate count to implement an incrementer, but this illustrates the flexibility of combinational building blocks in implementing different functions.

22

Chapter 1

■

Number System and Digital Logic Review

The Shifter There are many varieties of shifter combinational building blocks. The simplest type shifts by only one position and in a fixed direction (either left or right). More complex types can shift multiple positions (a barrel shifter) in either direction. Figure 1.16 shows the logic symbol for an n-bit right shifter and the internal details of a 4-bit right shifter. When EN = 1, then Y = A >> 1 with the SI input providing the input bit for the MSb. When EN = 0, then Y = A, and the SI input has no effect. This is another example of simple combinational building blocks (2-to-1 muxes) being used to build a more complex combinational building block.

Figure 1.16 N-bit right shift symbol and 4-bit right shift details

Memory A K x N memory device has K locations, with each location containing n bits. Thus, a 16 x 1 memory has 16 locations, with each location containing 1 bit. The address inputs specify the location whose contents appear on the data output. Because the address bits uniquely specify 1 of K locations, the minimum width of the address bus is ceil(log2 K). The output data bus has n bits as it is used to output a memory location’s content. Following these rules, a 16 x 1 memory has ceil(log2 16) = 4 address inputs and one data output. The idealistic view of memory presented here assumes a memory type with only these inputs and outputs, with memory contents loaded by some external means not discussed here. The most common usage of memory is to store data, and thus it’s actually a sequential logic element, which is defined in the next section. However, a memory device can also be used to implement combinational logic functions, and so that usage scenario is discussed here.

Understanding Sequential Logic

23

Figure 1.17 shows an 8 x 2 memory used to implement the sum and carry-out equations of the full adder. The full adder inputs are connected to the 3-bit address bus as A = ADDR2, B = ADDR1, and Ci = ADDR0. The 2-bit data output bus provides the outputs as Co = Q0 and S = Q1. When a memory is used in this way, it known as a lookup table (LUT). Changing the memory contents changes the logic function(s) implemented by the memory. Thus, a memory can be thought of as a programmable logic gate. Field programmable gate arrays (FPGAs) have thousands or even millions of small memories in one integrated circuit that can be programmed by the user for implementing logic functions. Sample Question: How many address and data lines does a 4 Ki x 16 memory have? Answer: The number of address inputs is ceil(log2 4Ki) = ceil(log2 22 * 210) = ceil(log2 212) = 12. The number of data outputs is 16.

Figure 1.17 Full adder implemented by an 8 x 2 memory

Understanding Sequential Logic The output of a combinational logic block is always uniquely defined by its current inputs. In contrast, the output of a sequential logic element is defined by its current inputs and also its current state, a value that is internal to the sequential logic element. A sequential logic element is a form of a memory device in that it retains internal state information between operations. In discussing sequential logic, the terms asserted and negated are used in reference to inputs, in addition to the previously defined terms of high-true and low-true. A high-true input has a high voltage level for TRUE and a low voltage level for FALSE. A low-true input has a low voltage level for TRUE and a high voltage level for FALSE. When an input is asserted, it is said to contain a TRUE value; a negated input contains a FALSE value. The symbol for a sequential logic element uses a bubble on an input to indicate low-true input or output.

24

Chapter 1

■

Number System and Digital Logic Review

The Clock Signal An important signal in a sequential logic circuit is the clock signal, whose waveform and associated definitions are shown in Figure 1.18. The following definitions are used in reference to clock waveforms: ■ ■

■

■

A rising edge is a transition from low to high; a falling edge is a transition from high to low. The period of a clock is the time in seconds (s) between two edges of the same type. A clock waveform typically has a fixed period; in other words, the period does not vary over time. The frequency of a clock is defined as 1/(period) and is measured in Hertz (Hz), where 1 Hz = 1/(1 s) (a 1 Hz clock has a period of 1 second). The high pulse width (PWH) is the amount of time the clock is high between a rising and falling edge; the low pulse width (PWL ) is the amount of time the clock remains low between a falling and rising edge. The duty cycle is the percentage of time that the clock remains high.

Clock signal equations are summarized in Equations 1.3 through 1.7 as: 1 Period

(1.3)

1 Frequency

(1.4)

PWH × 100% Period

(1.5)

Duty_cycle × Period 100

(1.6)

(100  Duty_cycle ) × Period

(1.7)

Frequency =

Period =

Duty_cycle =

PWH =

PWL=

100

Figure 1.18, the clock waveform, is an example of a timing diagram, which is a method for describing time-dependent behavior of digital systems. In a timing diagram, one or more waveforms can be displayed, and time is assumed to increase from left to right. A waveform event is a change in waveform value. If waveform event A occurs to the right of waveform event B, then A occurs after B in time. Thus, there is an implied time ordering of events that flows left to right. The clock waveform shown in Figure 1.18 is an idealized view of a clock signal; an oscilloscope trace of an actual clock signal would reveal visible rise and fall times for clock edges, and perhaps ringing (small oscillations) on the end of rising and falling edges.

Understanding Sequential Logic

25

Figure 1.18 Clock signal definitions

Table 1.4 lists commonly used units for time and frequency. A 1 kHz clock has a period of 1 ms, a 1 MHz clock has a period of 1 μs, and so forth. Timing and frequency specifications of digital circuits are contained in datasheets provided by the manufacturer. Time and frequency values are always specified using one of these units; in other words, a time is never specified as 1.05e–4 (shorthand for 1.05 × 10–4); instead, it is specified as 105 μs.

Table 1.4: Common Units for Time and Frequency Time

Frequency

milliseconds = ms = 10 s

kilohertz = kHz = 103 Hz

microseconds = µs = 10–6 s

megahertz = MHz = 106 Hz

nanoseconds = ns = 10–9 s

gigahertz = GHz = 109 Hz

picoseconds = ps = 10–12 s

terahertz = THz = 1012 Hz

–3

Sample Question: A clock has a duty cycle of 40 percent and a frequency of 19.2 kHz. What is the period and low pulse width, in microseconds? Answer: The period is 1/(19.2 kHz) = 1/(19.2 × 103) = 5.21 × 10–5 s. To convert this value to microseconds, do a unit conversion via: (5.21 × 10–5 s) × (1 µs/1 × 10–6 s) = 52.1 µs. PWL = ((100 – Duty_cycle) × Period)/100 = ((100 – 40) × 52.1 µs) /100 = 31.3 µs.

The D Flip-Flop There are many varieties of sequential logic elements. This section reviews only the dominant type used in digital logic design, the D Flip-Flop (DFF).

26

Chapter 1

■

Number System and Digital Logic Review

A DFF, as seen in Figure 1.19, can have the following input signals: ■

■

■

■

■

CK (input): The clock input; the arrival of the clock active edge sets the internal state of the DFF equal to the data input if the asynchronous inputs R, S are negated. The rising clock edge is the active clock edge for the DFF in Figure 1.19; it is said to be rising-edge triggered. A falling-edge triggered DFF has a bubble on its clock input. D (input): The data input; the internal state of the DFF is set to this value on the arrival of an active clock edge if the asynchronous inputs R, S are negated. The D input is said to be a synchronous input as it can only affect the DFF on arrival of an active clock edge. S (input): The set input; the internal state of the DFF becomes a 1 when this input is asserted. In Figure 1.19 this is a low-true input, so a low voltage on this input asserts set. This input is said to be asynchronous as its operation is independent of the clock input. R (input): The reset input; the internal state of the DFF becomes a 0 when this input is asserted. In Figure 1.19 this is a low-true input, so a low voltage on this input asserts reset. This input is also an asynchronous input. Q (output): The Q output is the value of the internal state bit.

Not all DFFs have S and R inputs; all DFFs have at least CK, D, and Q. The timing diagram in Figure 1.19 contains the following sequence of events: 1. The initial value of the DFF state bit is 0 as reflected by the Q output. 2. The D input becomes a 1, but this has no effect on the Q output, as a rising clock edge has not occurred. 3. A rising clock edge arrives. 4. The Q output changes to a 1 as the D value of 1 is clocked into the DFF by the rising clock edge. The time delay between the rising clock edge and the Q output becoming a 1 is known as a propagation delay; changes cannot occur instantaneously in physical logic circuits. Propagation delay values are dependent on the transistor topology of a logic gate and have different values for different inputs and gate types. A propagation delay given in a datasheet is specified as a maximum time for a given operating condition (supply voltage, ambient temperature). Timing diagrams in this book show propagation delay where appropriate. 5. The R input becomes a 0, asserting this input. 6. The Q output becomes a 0 after a propagation delay; note that this occurs independently of the clock edge, as the R input is an asynchronous input. 7. The S input becomes a 0, asserting this input. 8. The Q output becomes a 1 after a propagation delay; again, this occurs independent of the clock edge, as the S input is an asynchronous input.

Sequential Building Blocks

27

9. A rising clock edge arrives. The D input is a 0, but this value is not clocked into the DFF, as the S input is still asserted, which keeps the internal state at a 1. The DFF is the most commonly used edge-triggered sequential logic element in digital logic, as it takes the fewest transistors to build. Other types of sequential logic elements include the JK Flip-Flop (JKFF) and T Flip-Flop (TFF); both of these can be built by placing logic gates around a DFF.

Figure 1.19 D flip-flop symbol and operation

Sequential Building Blocks Sequential building blocks are built using combinational building blocks and sequential logic elements. The following sections review some common sequential building blocks.

The Register A register is used to store an n-bit value over successive clock periods. You might think that paralleling n DFFs would suffice, but the problem with a DFF is that it samples its D input on every active clock edge, potentially changing its value every active clock edge. Figure 1.20 shows an n-bit register built from an n-bit DFF and an n-bit 2-to-1 mux. When the load input (LD) is 1, the DFF D input receives the value of the external D input by way of the mux, and thus the register is loaded with a new value on the next active clock edge. When LD is 0, the DFF D input is connected to the DFF Q output; thus each active clock edge reloads the DFFs with their current output values.

28

Chapter 1

■

Number System and Digital Logic Review

In this way, the register retains its current value over multiple clock cycles when the load input is negated (LD = 0). Registers are key components of all computers, and Figure 1.20 should be the physical element envisioned when the term register is used in future chapters on microprocessor operation.

Figure 1.20 N-bit register

The Counter A counter is a register that has the additional capability of being able to increment (count up) or decrement (count down), or both. Figure 1.21 shows an n-bit counter that can count up. An n-bit incrementer has been added to the register design of Figure 1.20 to provide the counter functionality. The counter counts up by one when INC = 1 and LD = 0 on a rising clock edge as the DFF D input sees the value Q + 1. When INC = 0 and LD = 1, the counter loads the external D input value on the active clock edge. This allows the counter to be initialized to a value other than zero. When INC = 0 and LD = 0, the counter holds its current value. Counters are useful for producing addresses used to access memories, as sequential access of memory content is a commonly needed operation in computer systems.

The Shift Register A shift register is a register that has the additional capability of being able to shift left, right, or both directions. Figure 1.22 shows a shift register that can shift right by 1 when SHIFT = 1 and LD = 0. It uses the same design as the counter, except that a shift-right block has replaced the incrementer block. Shift registers are useful in computer input/output where an n-bit value must be communicated serially (bit by bit) to another device. The concept of serial input/output is covered in greater detail in Chapter 10.

Sequential Building Blocks

29

Figure 1.21 N-bit up counter

Figure 1.22 N-bit shift register

At this point, the usefulness of the concept of combinational and sequential building blocks should be apparent. You can envision other useful combinational building blocks such as a subtractor, decrementer, adder/subtractor, and other sequential building blocks such as up/down counters, or combined counter/shift registers. These components form the basis for the logic circuits used within modern computers.

30

Chapter 1

■

Number System and Digital Logic Review

Encoding Character Data Up to this point, the data encodings discussed have been for numerical representation of unsigned integers. Another common data type manipulated by computer systems is text, such as that printed on this page. The American Standard Code for Information Interchange (ASCII) is a 7-bit code used for encoding the English alphabet. The ASCII code contains uppercase letters, lowercase letters, punctuation marks, numerals, printer control codes, and special symbols. Table 1.5 shows the ASCII code; the top row specifies the most significant hex digit and the leftmost column the least significant hex digit of the 7-bit hex code. Thus, an A has the code 0x41, a 4 is 0x34, a z is 0x7A, and so on. The codes that are less than 0x20 are nonprintable characters that have various uses; some are printer control codes such as 0x0D (carriage return) and 0x0A (line feed). Eight bits are normally used to encode an ASCII character, with the eighth bit cleared to zero.

Table 1.5: ASCII Table Most Significant Digit 0x0

0x1

0x2

0x3

0x4

0x5

0x6

0x7

0x0

NUL

DLE

SPC

0

@

P

`

p

0x1

SOH

DC1

!

1

A

Q

a

q

0x2

STX

DC2

“

2

B

R

b

r

0x3

ETX

DC3

#

3

C

S

c

s

0x4

EOT

DC4

$

4

D

T

d

t

0x5

ENQ

NAK

%

5

E

U

e

u

0x6

ACK

SYN

&

6

F

V

f

v

0x7

BEL

ETB

‘

7

G

W

g

w

0x8

BS

CAN

(

8

H

X

h

x

0x9

TAB

EM

)

9

I

Y

i

y

0xA

LF

SUB

*

:

J

Z

j

z

0xB

VT

ESC

+

;

K

[

k

{

0xC

FF

FS

,




N

^

n

~

0xF

SI

US

/

?

O

_

o

DEL

Encoding Character Data

31

With the advent of the Web and the necessity to exchange binary-encoded text in other languages, the universal character-encoding standard, Unicode, was created (see www.unicode.org for more information). The Unicode goal is to provide a unique encoding for every character, numeral, punctuation mark, and so forth, contained within every known language. The Unicode standard allows 8-bit (1 byte), 16-bit (2 byte), and 32-bit (4 byte) encodings. The 8-bit and 16bit encodings are subsets of the 32-bit encodings; the first 128 codes (0x00 to 0x7F) are the same as the ASCII code for compatibility. Using 32 bits for each character allows for 4,294,967,296 unique characters, which is sufficient for the known character sets of the world. Individual character sets (Latin, Greek, Chinese, and so on) are assigned ranges within Unicode. Portions of the code are also reserved for use by private applications, so these codes are not assigned to any language. This book uses ASCII exclusively for character data encoding, but be aware that more sophisticated methods for text encoding exist. The number of different items in the computer world that have binary encodings is large, and thus you must be told what is being encoded in order to decipher a binary code. For example, the binary value 0b01000001 (0x41) can represent either the ASCII code for an “A” (uppercase A), or the number 65 (4 * 16 + 1 = 65), or something else entirely. Throughout this book’s remaining chapters, you will learn about other types of binary codes and the items that they encode. Sample Question: What character string is represented by “0x48 0x65 0x6C 0x6C 0x6F 0x20 0x57 0x6F 0x72 0x6C 0x64 0x21”? Answer: Translating character by character yields the popular test message: “Hello World!” Note that the string contains a space character (0x20) and an exclamation mark “!” (0x21).

Summary The goal of this chapter was to refresh some topics you have encountered previously concerning number systems, binary encoding, Boolean algebra, logic gates, combinational building blocks, and sequential building blocks. The next chapter uses these building blocks to introduce the concept of a stored program machine as a means of implementing a digital system.

32

Chapter 1

■

Number System and Digital Logic Review

Review Problems The answers to the odd-numbered problems can be found in Appendix C. 1. How many bits does it take to represent 40 items? 2. What is the largest unsigned integer that can be represented in 7 bits? 3. Convert the value 120 to binary using 8 bits. 4. Convert 89 to hex using 8 bits. 5. Convert 0xF4 to binary. 6. Convert 0xF4 to decimal. 7. Convert the value 0b10110111 to decimal. 8. Compute 0xB2 + 0x9F and give the result in hex. 9. Compute 0xB2 – 0x9F and give the result in hex. Check your work by verifying that 0xB2 + ~(0x9F) + 0x1 produces the same result. To compute ~(0x9F), complement each bit. 10. Draw the logic network and derive the truth table for the logic function F = (A&B) | C. 11. Derive the CMOS transistor network that implements the NOR function. 12. Compute 0xC3 >> 2; give the value in hex (this is a right shift by two). 13. Compute 0x2A >, >), left shift ( 2; is implemented as two one-bit shifts because of the need for byte operations since the u8_i variable is a uint8_t data type; recall that the multiple-position shifts allow only word operations. The C statement u16_k = u16_p > (W1) → W0, or 0x9335 >> 8 → W0, so W0 is modified to 0x0093. The result is non-zero, so Z = 0. The C flag is unaffected, so C = 0. 2. A word operation; this performs (W2) 15 → W0, or 0x1008 >> 15 → W0, so W0 is modified to 0x0000. The result is zero, so Z = 1. The C flag is unaffected, so C = 0. 4. A byte operation; this performs (0x1002) and == tests. For the >= comparison, C == 1 is true for both > and ==, so only the C flag must be tested to determine if k >= j is true after the subtraction k – j is performed. For the k > j comparison, C == 1 is true for both the > and == tests, so the Z == 0 flag condition must be included in the k > j test to distinguish the k > j condition from the k >= j condition. Thus, the true condition for the test k > j is C == 1 and Z == 0, or written in a Boolean format is C & ~Z. The j), so ~(C & ~Z) is equal to ~C | Z by DeMorgan’s Law (Chapter 1), or u16_j and the assembly language implementation using the test u16_k – u16_j. The false condition to branch around the if-body is u16_k u16_j test using u16_j - u16_k subtraction

Comparison and Unsigned Branch Instructions Using subtraction and simple flag tests can be confusing, because you have to remember which subtraction to use, k - j or j - k, for implementing a particular unsigned branch in the most efficient manner. The PIC24 instruction set has a set of unsigned branches that can be used for unsigned comparisons as shown in Table 4.4. These flag conditions correspond to the k – j test in Figure 4.20(a) when comparing k to j where k and j are unsigned numbers. (Signed number comparison is covered in Chapter 5.) As previously seen, the subtraction instruction can be used to affect the flags used by branch operations. However, a drawback of using the subtraction instruction is that a register or memory location value is destroyed by the subtraction result. Another way to affect flags for branch operations is to use a compare instruction, which performs subtraction with its two operands, but does not save the result, as shown in Figure 4.23. The cp{.b} Wb, Ws and cp{.b} f forms are useful for comparing

Unsigned Conditional Tests

119

two unsigned variables, while the cp{.b} Wb, #lit5 form is useful for comparing a variable against a constant. The cp0 (compare with zero) forms are a convenient method for comparing a variable against 0, whose addressing modes are more flexible than provided by the cp{.b} Wb, #lit5 instruction. Recall that Figure 4.16 used a mov instruction to accomplish a zero test by copying a memory location on top of itself to affect flags; the cp0 instruction can replace the mov instruction for the purposes of zero test.

Table 4.4: Unsigned Branches Description

Syntax

Branch Taken When

Branch >, unsigned

bra GTU,

C & ~Z

Branch >=, unsigned

bra GEU,

C

Branch u16_j is the same as the one used for the while example of Figure 4.34, but that the assembly code uses a different branch after the loop condition test because the loop condition test is at the end of the loop rather than the top of the loop. In this case, a bra GTU instruction is used, which is the true condition for u16_k > u16_j, thus causing a return to the top of the loop.

Figure 4.36 do…while to assembly language example

Another commonly used loop structure in the C language is the for loop. Figure 4.37 shows that a for loop is simply a shorthand notation for a while loop. As such, the use of a for loop structure is optional, as it can always be written as a while loop.

Figure 4.37 for loop structure

Summary This chapter explored 8/16-bit arithmetic, logical, shift, and unsigned comparison operations. The obvious limitations of 8/16-bit unsigned integer data will be removed in the next chapter, which discusses extended precision operations on signed integer data.

Review Problems

129

Review Problems The answers to the odd-numbered problems can be found in Appendix C. For problems 1 through 34, give the Z and C flags and affected registers after execution of each instruction. Assume the register and memory contents of Table 4.6 at the beginning of each problem, with initial flag values of Z = 0, C = 1. Table 4.6: Register Memory Contents Location

Value

Location

Value

W0

0x0804

0x1000

0x382A

W1

0x0806

0x1002

0xFB80

W2

0x8301

0x1004

0x80FF

W3

0xF0A2

0x1006

0x7B03

W4

0xFFFF

0x1008

0x0001

1.

add.b W4, W2, W0

2.

add W4, W2, W0

3.

sub W1,W0,W2

4.

sub.b W4,W2, W2

5.

and.b W0, W1, W1

6.

and W3, W2, W0

7.

ior W3, W1, W0

8.

ior.b W0, W1, W0

9.

xor.b W3, W4, W4

10.

xor W4, W3, W3

11.

clr W4

12.

clr.b W3

13.

setm W1

14.

setm.b W3

15.

bset.b 0x1001, #6

16.

bset 0x1004, #9

17.

bclr 0x1004, #15

130

Chapter 4

■

Unsigned 8/16-Bit Arithmetic, Logical, and Conditional Operations

18.

bclr.b 0x1005, #7

19.

btg 0x1006, #3

20.

btg.b 0x1008, #0

21.

com.b 0x1003

22.

com 0x1004

23.

lsr W3, #8, W3

24.

lsr W2,#4, W0

25.

sl W3, #12, W0

26.

sl W1, #2, W0

27.

rlnc.b 0x1000

28.

rlnc 0x1000

29.

rlc 0x1002

30.

rlc.b 0x1003

31.

rrnc 0x1000

32.

rrnc.b 0x1000

33.

rrc.b 0x1002

34.

rrc 0x1006

Write PIC24 assembly language equivalents for the following C code fragments. Assume variables u16_i, u16_k, u16_j, and u16_n are uint16_t variables, while u8_p, u8_q, and u8_r are uint8_t variables. 35. Code fragment: u16_k = u16_i + (u16_j > 4) & 0x0F;

37. Code fragment: u16_k = (uint16_t) u8_p + (u16_j > 4) & 0x0F;

Review Problems

39. Code fragment (use place holders for if-body, else-body): if ((u16_k >= 0x0400) || (u8_r == 0)) {

if-body statements } else {

else-body statements }

40. Code fragment (use place holders for if-body, else-body): if ((u16_k < u16_j) || (u8_r != u8_q)) {

if-body statements } else {

else-body statements }

41. Code fragment (use place holders for if-body, else-body): if ((u16_k != 0x0400) && (u8_r > u8_p)) {

if-body statements } else {

else-body statements }

42. Code fragment (use place holders for if-body, else-body): if ((u16_k != 0) && (u16_j >= u16_i)) {

if-body statements } else {

else-body statements }

43. Code fragment (use place holders for loop-body): while (u16_i != u16_k) {

loop-body statements }

131

132

Chapter 4

■

Unsigned 8/16-Bit Arithmetic, Logical, and Conditional Operations

44. Code fragment (use place holders for loop-body): while ((u8_r != 0) && (u8_p < u8_q)) { loop-body statements }

45. Code fragment (use place holders for loop-body): do { loop-body statements } while ((u8_r != 0) || (u8_p < u8_q))

46. Code fragment (use place holders for loop-body): do { loop-body statements } while ((u16_i != u16_k) && (u8_p > 0x50))

47. The following C code counts the number of 1 bits in u8_j and returns the answer in u8_k. Convert this to PIC24 assembly code. You may want to convert the for loop structure to a while loop structure. uint8_t u8_i,u8_j,u8_k; u8_k = 0; // init bit count for (u8_i = 0; u8_i != 8; u8_i++) { // do for 8 bits if ((u8_j & 0x01) == 1) { u8_k++; // LSb = 1, increment count } u8_j = u8_j >> 1; // look at the next bit }

48. The following C code shifts u16_k to the left for each 0 bit present in u16_j. Convert this to PIC24 assembly code. You may want to convert the for loop structure to a while loop structure. uint16_t u16_i,u16_j,u16_k; u16_k = 1; // initialize k for (u16_i = 0; u16_i != 16; u16_i++) { // do for 16 bits if ((u16_j & 0x0001) == 0) { u16_k = u16_k > 1; // look at the next bit }

Chapter 5

Extended Precision and Signed Data Operations

T

his chapter applies the arithmetic, logical, and shift operations discussed in the previous chapter to extended-precision operands; that is, operands that are larger than 16 bits. Furthermore, signed number representation and its effect on shift and comparison operations are covered.

Learning Objectives After reading this chapter, you will be able to: ■

■

■

■

Translate C language statements that perform extended-precision addition, subtraction, bitwise logical, and shift operations into PIC24 instruction sequences. Compare and contrast signed magnitude, one’s complement, and two’s complement representations of signed integers. Translate C language statements that perform shift and comparison operations using signed operands into PIC24 instruction sequences. Translate PIC24 branch instructions into machine code and be able to discuss the meaning of relative addressing.

133

134

Chapter 5

■

Extended Precision and Signed Data Operations

Extended Precision Operations Previous chapters have used unsigned 8-bit and 16-bit integers in C programs, which limits these variables to a 0 to 255 and 0 to 65,535 number range, respectively. Obviously, practical problems have a need to accommodate larger number ranges in C programs and PIC24 assembly language programs. The uint32_t data type originally given in Table 3.5 of Chapter 3 is a 32-bit unsigned integer data type that provides a 0 to 4,294,967,295 (232−1) number range. The need for 32-bit data types depends upon the microcontroller application, but most often they are needed when manipulating high-precision timing intervals. The lower 16 bits of a 32-bit integer is referred to in this book as the least significant word (LSW) and the upper 16 bits as the most significant word (MSW). Because the PIC24 CPU is a 16-bit CPU, operations on 32-bit data require approximately twice the number of instructions as 16-bit operations, split between manipulation of the LSW and MSW portions of the 32-bit datum. Because of the doubled execution time, program space, and data RAM required for 32-bit integers, they should only be used when the extra precision is required by the application.

32-Bit Assignment Operations To be consistent with PIC24 technical documentation, the term double word is also used in this text in reference to 32-bit data. Figure 5.1 shows the two forms of double word moves available in the PIC24 instruction set. The first form allows register indirect modes for the source operand and thus supports copies from data RAM into the working registers. The second form supports register indirect modes for the destination operand and thus supports working register to data RAM copies. When register direct addressing (Wn) is used for either Ws, Wns, Wd, or Wnd this specifies a double word value that resides in Wn:Wn+1, with Wn referring to the LSW and Wn+1 to the MSW. Furthermore, register direct addressing is limited to even-numbered registers (i.e., W0, W2, . . .W14). When register indirect addressing is used for either Ws or Wd, any register (W0 through W15) may be used to specify the effective address of the LSW in data RAM, with the MSW address at address LSW + 2. The effective address of the LSW must be word-aligned.

Figure 5.1 Double word (32-bit) mov instructions

Extended Precision Operations

135

A double word move example that uses register direct addressing for both Wns and Wnd is shown in Figure 5.2(a). Observe that mov.d W0, W2 copies data from the W0:W1 register pair to the W2:W3 register pair. Figure 5.2(b) illustrates a double word move from data RAM to working registers, with register indirect addressing used for Wns. The data RAM effective address for the LSW of a double word move must be word-aligned (an even address), but the register used as the source register for a register indirect addressing mode can be any working register. Observe that the destination register W2 in Figure 5.2(b) is an even-numbered register, fulfilling the requirement that a destination using register direct addressing for a double word move must be evenly numbered.

Figure 5.2 Double word (32-bit) mov examples

Figure 5.3 illustrates PIC24 assembly language implementation of C language variable assignment operations involving uint32_t data types. The PIC24 assembly language implementation for these particular assignments does not use any of the double word move forms, as it is more efficient in this case to simply use individual 16-bit operations on the LSW and MSW portions of the uint32_t data types. The double word move forms become more efficient for C pointer operations involving arrays of 32-bit data, which is covered in Chapter 6. In Figure 5.3, observe that the label u32_k refers to the LSW of the uint32_t u32_k variable, while u32_k+2 is used for the MSW. For C language assignment of uint32_t variables, the order in which the 16-bit assignments are made, LSW first or MSW first, does not matter as long as LSW is copied to LSW and MSW to MSW.

136

Chapter 5

■

Extended Precision and Signed Data Operations

Figure 5.3 C language 32-bit assignment operations

32-Bit Bitwise Logical Operations Figure 5.4 shows a bitwise AND operation applied to uint32_t operands with three assembly language implementations provided. Figure 5.4(a) uses the input/process/output approach by first copying u32_k, u32_p into the register pairs W1:W0, W3:W2. The AND operation is then performed on the LSW and MSW operands with the 32-bit result placed in the register pair W3:W2. This 32-bit result is then copied from W3:W2 to u32_k. Note that the AND instruction is applied to each 16-bit word (LSW and MSW) of the operands. It is immaterial as to the order in which a bitwise logical operation is applied to the words of a 32-bit operand, as each word operation is independent of each other, just as with the assignment operation. You might be tempted to use the mov.d instruction, as shown in Figure 5.4(b), but this is incorrect as the mov.d instruction does not support the file register addressing mode. The mov.d instruction requires use of an indirect addressing mode to access data memory and the indirect addressing modes useful for this example are discussed in Chapter 6. In this example, a mov.d approach would not save a significant number of instructions. However, Figure 5.4(c) gives an implementation that does significantly reduce the number of instructions required by using the two-operand AND instruction form. Because this approach is clearly better in terms of the required number of instructions, many of the examples in this chapter will use two-operand ALU instruction forms.

Extended Precision Operations

137

Figure 5.4 C language 32-bit bitwise logical operations

32-Bit Addition/Subtraction Figure 5.5 shows addition and subtraction using two 32-bit operands. For the addition operation, the two least significant words are added first, followed by the addition of the two most significant words, which includes the carry (C flag) produced by the least significant word addition. The subtraction is done similarly, except the subtraction of the most significant words includes the borrow produced by the least significant word subtraction. Note that unlike logical operations, the order of the operations for addition and subtraction matter in that the LSW operation is performed first, followed by the MSW operation. To accommodate the needs of extended precision addition and subtraction, the PIC24 instruction set includes the instructions addc (add with carry) and subb (subtract with borrow), as shown in Figure 5.6. These instructions support the same addressing modes as add/sub instructions previously discussed. There is also a cpb (compare with borrow) instruction for use in comparing extended precision operands.

138

Chapter 5

■

Extended Precision and Signed Data Operations

Figure 5.5 Addition/subtraction with 32-bit operands

Figure 5.6 Addition/subtraction/compare instructions for extended precision operations

Figure 5.7 illustrates the use of addc and subb instructions for performing u32_k = u32_k + u32_j and u32_p = u32_p - u32_q, where all of the variables are of type uint32_t. Figure 5.7(a) uses two-operand add/addc instruction forms; observe that the add instruction is used for the LSW of u32_k + u32_j, followed by the addc instruction for the MSW. Similarly, the sub instruction is used for the LSW of u32_p - u32_q, followed by the subb instruction for the MSW. The no carry version of addition (add) and the no borrow version of subtract (sub) is used on the LSW because there is no carry into or borrow from the LSW. Figure 5.7(b) uses three-operand add/addc instruction forms and the input/process/output approach. Figure 5.7(b) can be modified to implement u32_p = u32_p - u32_q by replacing u32_k with u32_p , u32_j with u32_q , add with sub , and addc with subb .

Extended Precision Operations

139

Figure 5.7 Addition/subtraction using addc/subb instructions

Another difference between the add/sub and addc/subb/cpb instructions, besides the inclusion of carry/borrow, is in the manner in which the addc/subb instructions affect the Z flag. The Z flag is said to be sticky in that the addc/subb instructions can only clear the Z flag, not set it. This behavior means that in a 32-bit add/addc sequence or a sub/subb sequence, the Z flag represents the zero status of the entire 32-bit result and not just the zero status of the MSW. Figure 5.8 clarifies this by giving three 32-bit subtraction examples using sub/subb. Figure 5.8(a) shows a subtraction result whose 32-bit result is 0x0000F000, a non-zero result. After the LSW subtraction, the Z flag is 0 because the sub instruction produces a value of 0xF000. After the MSW subtraction using the subb instruction, the Z flag is still 0 even though the MSW is 0x0000 because the Z flag cannot be set by subb. Thus, the final Z flag value of 0 indicates that the 32-bit result of 0x0000F000 is non-zero. Figure 5.8(b) shows another 32-bit subtraction with a non-zero result of 0x00010000, except this time the MSW is non-zero and the LSW is zero. The Z flag is set after the LSW subtraction, but the MSW subtraction using subb produces a non-zero result, so the subb instruction clears the Z flag. The final subtraction shown in Figure 5.8(c) produces a result of 0x00000000 and a final Z flag value of 1.

140

Chapter 5

■

Extended Precision and Signed Data Operations

The Z flag is set to a 1 by the sub instruction in the LSW operation. The Z flag remains a 1 after the MSW operation using the subb instruction because a zero result is produced, so subb leaves the Z flag at its previous value, which is a 1. This Z flag behavior means that the 32-bit equal (==) and (!=) testing can be performed using a cp/cpb instruction sequence followed by a branch on the Z flag.

Figure 5.8 Z flag behavior in addc/subb instructions

Figure 5.9 shows increment/decrement operations on 32-bit variables. Because there is no increment with carry instruction, an inc/addc sequence is used, as shown in Figure 5.9(a), where addc performs u32_k.MSW + 0 + Carry after the inc instruction increments u32_k.LSW. The W0 register is cleared first to ensure that addc u32_k+2 adds a zero to u32_k.MSW. The assembly code for decrementing a 32-bit variable in Figure 5.9(b) uses a similar approach via the dec/subb instruction sequence.

Extended Precision Operations

141

Figure 5.9 32-bit increment/decrement operations

32-Bit Logical Shift Right/Shift Left Operations Figure 5.10(a) shows a 32-bit logical shift right operation. The MSW of u32_k is shifted first using the lsr (logical shift right) instruction, followed by the rrc (rotate right with carry) instruction on the LSW. Recall that the rrc instruction shifts the C flag into the most significant bit. Thus, the C flag is used as a 1-bit storage register for transporting the bit shifted out of the MSW into the LSW. A shift left on a 32-bit variable is shown in Figure 5.10(b). The LSW is shifted first using an sl (shift left) instruction, followed by an rlc (rotate left with carry) on the MSW with the C flag used to transport the bit shifted out of the LSW into the MSW. Figure 5.10(c) shows an implementation for the left shift of Figure 5.10(b) using the input/process/output approach. Observe that the sl/rlc instruction forms use the two-operand register-to-register forms that shift by one position, with the sl instruction affecting the C flag. You must be careful to avoid use of the three-operand forms of the sl and lsr instructions as these instructions do not affect the carry flag causing the following rlc or rrc instructions to shift in an incorrect C flag. Figure 5.10(d) shows an incorrect left shift implementation that uses the three-operand sl form.

Zero, Non-Zero Conditional Tests A 32-bit non-zero test is shown in Figure 5.11. This is the same example used in Chapter 4 with the exception that the data type has been changed from uint16_t to uint32_t. The most straightforward method of testing a 32-bit operand for zero/non-zero is to compare the least and most significant words against 0 using cp (compare) and cpb (compare with borrow), respectively, as given in Figure 5.11(a). This works because the Z flag is sticky for cpb instruction, as previously mentioned. If the C code of Figure 5.11(a) is changed to the zero test if (!u32_k) {}, then the bra Z instruction is replaced with a bra NZ instruction to skip the if-body when u32_k is non-zero. An invalid approach for 32-bit zero test commonly tried by new assembly language programmers using the cp0 instruction is shown in Figure 5.11(b). This approach is illegal as there is no cpb0 instruction for use with the MSW comparison.

142

Chapter 5

■

Extended Precision and Signed Data Operations

Figure 5.10 32-bit logical shift right/shift left operations

Extended Precision Operations

143

Another common implementation error is given in Figure 5.11(c), in which the zero testing approach used in Chapter 4 for 16-bit variables by copying the variable on top of itself is applied to both words of the 32-bit variable. This only tests if the MSW of the 32-bit variable is zero as the Z-bit is not sticky between the two copy operations.

Figure 5.11 Assembly language for 32-bit non-zero test

A slightly more efficient zero/non-zero test is performed on a 32-bit operand by bitwise-OR’ing the operand least significant and most significant words with each other, as shown in Figure 5.12. After the bitwise-OR, a Z = true condition indicates an operand value of zero, as the final 32-bit result can only be zero if all bits in the least significant and most significant words are zero. A more complex zero/non-zero test is shown in Figure 5.13, in which the if-body is executed if u32_k is non-zero or u32_j is zero (u32_k && !u32_j). Since u32_k and u32_j are being checked for their status with respect to zero, both variables are tested by the bitwise-OR of their most significant word with their least significant word. The if-body is skipped if u32_k is zero and u32_j is non-zero.

144

Chapter 5

■

Extended Precision and Signed Data Operations

Figure 5.12 Assembly language for 32-bit non-zero test

Figure 5.13 Assembly language for 32-bit zero/non-zero test with two operands

Note that the logical OR condition || in the C code in Figure 5.13 is unrelated to the bitwise-OR used in testing each variable for zero/non-zero. If the condition in the C code in Figure 5.13 is changed to (u32_k && !u32_j), in which the if-body is executed only if u32_k is non-zero and u32_j is zero, a bitwise-OR operation is still used to test the u32_k and u32_j variables for zero/non-zero. Figure 5.14 shows the C and assembly language for this test of 32-bit variables.

Equality, Inequality Figure 5.15 shows assembly code for a 32-bit equality test. The if-body is executed if the test u32_k == u32_j is true. The test is performed by making a 32-bit comparison of the operands and skipping the if-body if the Z flag is cleared after the comparison, indicating that the operands are not equal. The 32-bit comparison is performed by using the cp instruction for the LSW comparison and the cpb for the MSW comparison. As previously discussed, the sticky behavior of the Z flag for the cpb instructions allows the Z flag to indicate the zero status of the entire 32-bit subtraction

Extended Precision Operations

145

Figure 5.14 Another assembly language for 32-bit zero/non-zero test with two operands

performed by the comparison, not just the zero status of the MSW comparison. An inequality test of u32_k != u32_j in the if condition only requires replacing bra NZ with a bra Z instruction (skip the if-body if u32_k - u32_j yields a zero result, indicating that u32_k is equal to u32_j).

Figure 5.15 Assembly language for 32-bit equality test

Comparisons of >, > =, u32_j comparison used in an if statement, where u32_k, u32_j are unsigned 32-bit operands. The only difference between this code and the 8/16-bit comparison code given in the previous chapter is that a 32-bit comparison (cp/cpb sequence) is used instead of a 16-bit comparison. It is easy to adapt any of the code examples from Chapter 4 for >, >=, 1; } while (u32_k >= u32_j); Answer: One possible solution is given in Listing 5.1. The shift right of u32_j is done by using an lsr instruction for the MSW, followed by an rrc on the LSW. The comparison u32_k >= u32_j is done by a 32-bit comparison of u32_k, u32_j using cp for the LSW comparison and cpb for the MSW comparison. Finally, a bra GEU is used to return to the top of the loop as the branch is taken if u32_k >= u32_j. Listing 5.1: Sample Question Solution top_loop: lsr u32_j+2 rrc u32_j mov u32_j,W0 cp u32_k mov u32_j+2,W0 cpb u32_k+2 bra GEU, top_loop rest of code

; logical shift right u32_j.MSW ; right shift u32_j.LSW ; u32_k.LSW - u32_j.LSW ; u32_k.MSW - u32_j.MSW ; loop if u32_k >= u32_j

64-Bit Operations A 64-bit unsigned integer is declared as unsigned long long in the C compiler used for this book, with uint64_t used as the shorthand notation that exposes the data size. Figure 5.17 shows the

Signed Number Representation

147

assembly code for a 64-bit addition of two uint64_t operands. A 64-bit variable consists of 8 bytes or four 16-bit words. Thus, four 16-bit additions are required, with the addc instruction used for all 16-bit additions after the first 16-bit addition. Because it is straightforward to extend the previously covered 32-bit operations to 64-bit operands, and because usage of 64-bit variables in 16-bit microcontroller code is rare, no further examples of 64-bit operations are given in this book.

Figure 5.17 Assembly language for 64-bit addition

Signed Number Representation All examples up to this point have used unsigned data types. Obviously, you are also interested in performing operations on signed integers such as −100 or +27, but to do this, you must have a binary encoding method that includes the sign (+/−) of a number and its magnitude. Three binary encoding methods for signed integers are signed magnitude, one’s complement, and two’s complement. These encodings share two common features, one of which is that a positive number in any of these encodings is the same and is simply the binary representation of the number. The second common feature is that the most significant bit of a negative number is 1.

Signed Magnitude Signed magnitude encoding is so named because the encoding is split into sign and magnitude, with the most significant bit used for the sign and the remaining bits for the magnitude. Figure 5.18 shows examples of signed magnitude encoding. With n bits, the number range is −2(n–1) − 1 to +2(n–1) − 1, or −127 to +127 for n = 8. Two encodings exist for zero, a positive zero and a negative zero. The advantage of signed magnitude is that the sign and magnitude are immediately accessible for manipulation by hardware, and it is inexpensive from a logic gate viewpoint to produce the

148

Chapter 5

■

Extended Precision and Signed Data Operations

negative of a number: simply complement the sign bit. However, one disadvantage of signed magnitude numbers is that the same binary adder logic used for unsigned numbers cannot be used for signed magnitude numbers. Signed magnitude arithmetic requires custom logic specifically designed for that encoding method. In a microprocessor, this would require special addition/subtraction instructions for use with signed magnitude integers and instructions for converting between unsigned and signed integer representations. Fortunately, as you’ll see shortly, two’s complement encoding allows the same binary adder logic to be used for both unsigned and signed representations, thus no separate instructions are needed for signed and unsigned addition/subtraction. However, there is one class of numbers, floating point numbers (i.e., −10.235), which do require their own dedicated arithmetic/logic units and instructions. Interestingly, a form of signed magnitude representation is used for floating point number encoding, which is discussed further in Chapter 7.

Figure 5.18 Signed magnitude encoding

One’s Complement One’s complement is so named because a −k is found by complementing each bit in the +k representation (i.e., −k = ~(+k)). With n bits, the number range is −2(n–1) − 1 to +2(n–1) − 1, or −127 to +127 for n = 8, the same as signed magnitude. Examples of one’s complement encodings are given in Figure 5.19. Two encodings exist for zero, positive zero (all 0s) and negative zero (all 1s). The binary adder logic used for unsigned numbers can be used for one’s complement numbers as long as an error of +1 is acceptable in the result, which occurs when you’re adding two negative numbers or a positive and a negative number. For example, the correct result for the sum +5 + (−2) is +3.

Signed Number Representation

149

Written as 8-bit numbers in one’s complement, the sum is 0x05 + 0xFD = 0x02 (+2), which is in error by +1. The advantage of one’s complement is that the negative value of a number is “cheap and fast”—cheap in terms of logic gates and fast in terms of delay. All that is needed is an inverter for each bit, producing one gate delay for the negation operation. One’s complement has been used within some graphics hardware accelerators for color operations on pixels, where speed is allimportant and an error of 1 LSb is acceptable.

Figure 5.19 One’s complement encoding

Two’s Complement The +1 error in one’s complement addition using binary adder logic is corrected by encoding a −k as ~(+k) + 1, the one’s complement plus one. This is called two’s complement representation and is the standard method for encoding signed integers in microprocessors. With n bits, the number range is −2(n–1) to +2(n–1) − 1, or −128 to +127 for n = 8. There is only one representation for zero (digits are all 0s), with the negative zero (digits are all 1s) of one’s complement now representing a negative one (−1). The negative number range contains one more member than the positive range. Figure 5.20 gives examples of two’s complement encodings. As stated earlier, conversion of a positive decimal number +k to two’s complement is easy, as it is simply the binary (hex) representation. The conversion of a negative decimal number to two’s complement using the formula −k = ~(+k) + 1 is error prone, as it requires the number to be converted to binary then each bit to be complemented. An easier method is to use the fact that −k = 0 − (+k), which computes −k by converting +k to hex, then subtracts that number from zero.

150

Chapter 5

■

Extended Precision and Signed Data Operations

Figure 5.20 Two’s complement encoding

Figure 5.21(a) summarizes these rules for signed decimal to two’s complement conversion and contains two sample conversions.

Figure 5.21 Signed decimal to two’s complement and vice versa

Signed Number Representation

151

An n-bit two’s complement number can be converted to signed decimal by multiplying each binary digit by its appropriate weight, with the most significant digit having a negative weight. Thus, an 8-bit two’s complement number of the form b7b6b5b4b3b2b1b0 is converted to decimal by the sum −b7*27 + b6*26 +b5*25 +b4*24 + b3*23 + b2*22 + b1*21 + b0*20. An easier and less error-prone method is to first write the binary number as a hex number. Converting the hexadecimal two’s complement number to signed decimal requires determination of the sign and the magnitude. If the most significant bit is one (most significant hex digit is 8 or greater), the number is negative. To find the magnitude of this negative number, subtract the number from zero, as +k = 0 − (−k), and convert the result to decimal. If the most significant bit is zero (hex digit is 7 or less), the number is positive, and converting it to decimal provides +k. Figure 5.21(b) summarizes these rules and shows two examples of two’s complement hex to signed decimal conversion.

Sign Extension To convert, or promote, an 8-bit unsigned number to a 16-bit unsigned value, one simply adds extra zeros to the leftmost digits. As an example, the unsigned decimal number 128 in 8 bits is 0b10000000, or 0x80. In 16 bits, the same number is 0b0000000010000000, or 0x0080. For two’s complement numbers, extra precision is gained by sign extension, which means the sign bit is replicated to produce the additional bits. Using the same example, the signed decimal number of −128 in 8 bits, two’s complement is 0b10000000, or 0x80. In 16 bits, the same number is 0b1111111110000000, or 0xFF80. Note that if zeros are used for padding instead of the sign bit, a negative number is changed to a positive number, an obviously incorrect result. For hex representation, extending the sign bit means padding with F digits for negative numbers, and 0 digits for positive numbers. The ze (zero extension) PIC24 instruction performs zero extension, while the se (sign extension) instruction performs sign extension. Code examples using the ze and se instructions are provided later in this chapter. Sample Question: Give the value of −3 as a 16-bit two’s complement number. Answer: The easiest way to accomplish this is to first write −3 as an 8-bit two’s complement number then sign extend. You know that +3 = 0x03, so −3 = 0 − (+3) = 0x00 − 0x03 = 0xFD. Sign extending (adding 1s in binary or 0xF digits in hex to the left) the 8-bit value 0xFD to a 16-bit value produces 0xFFFD. You can verify that this is correct by computing 0 − (−3) = +3, so 0x0000 − 0xFFFD = 0x0003 = +3.

Sample Question: The 8-bit value 0xA0 is a two’s complement number; give its decimal value. Answer: The MSb of 0xA0 is a 1, so this number is negative. You know that 0 − (−N) = +N, so 0x00 − 0xA0 = 0x60 = +96. Thus, the magnitude of the number is 96 and the sign is negative, so 0xA0 = −96.

152

Chapter 5

■

Extended Precision and Signed Data Operations

Two’s Complement Overflow In Chapter 1, you saw that a carry-out of the most significant bit is an indication of overflow for unsigned numbers. Now you are probably wondering how overflow is detected for addition/ subtraction of two’s complement numbers. First, let’s consider the sum (−1 + (+1)) written as 8-bit, two’s complement numbers, which is 0xFF + 0x01. The addition produces a carry-out of the most significant bit and an 8-bit result of 0x00 (0), the correct result for the sum −1 + (+1). This means that the carry flag is not useful as an overflow indicator for signed arithmetic. Instead, the two’s complement overflow flag (OV), bit 2 of the STATUS register, is the error indicator for two’s complement arithmetic. In this book, the OV flag is shortened to the V flag and is referred to as the overflow flag, with two’s complement understood. The STATUS register provides another useful flag for dealing with signed numbers: the negative (N) flag. This bit is set equal to the MSb of the operation result; thus, the condition N = 1 indicates a negative result if the result is interpreted as a two’s complement number. Once again, look at the ranges of positive and negative numbers in two’s complement in Figure 5.20. Note that overflow cannot occur when computing the sum of a positive and negative number. However, a two’s complement overflow can occur when the sum of two negative numbers yields a positive number, or when the sum of two positive numbers yields a negative number. Similar rules can be derived for subtraction. These rules are summarized in Equations 5.1 through 5.4. Observe that the subtraction rules 5.3 and 5.4 are simply the addition rules 5.1 and 5.2 stated in a different form: if +p + (+q) = –r then V = 1

(5.1)

if (–p) + (–q) = +r then V = 1

(5.2)

if (+p) – (–q) = –r then V = 1

(5.3)

if (–p) – (+q) = +r then V = 1

(5.4)

The preceding rules aid the determination of the V flag when performing addition or subtraction manually. A method more suitable for logic gate implementation is shown by the Boolean test of Equation 5.5, where CMSb is the carry-out of the most significant bit, CMSb−1 is the carry-out of the preceding bit as produced during binary addition, and ^ is the XOR operation. V = CMSb ^ CMSb–1

(5.5)

Equation 5.5 works because if two positive numbers are added (most significant bits are both 0) and CMSb−1 = 1, then CMSb must be 0 leaving behind a MSb of 1, indicating that a negative number has been produced which is overflow (for the sum of two positive numbers, the case of CMSb−1 = 0 and CMSb = 1 cannot occur). If two negative numbers are added (most significant bits are both 1), and CMSb−1 = 0, then CMSb must be 1 leaving behind a MSb of 0, indicating that a positive number has been produced which is overflow (for the sum of two negative numbers, the case of CMSb−1 = 1 and CMSb = 0 cannot occur).

Operations on Signed Data

153

Figure 5.22 illustrates the four possible cases of C, V flag settings for 8-bit addition. The operands and results are shown interpreted as both unsigned numbers and signed numbers. Observe that C = 0 if the unsigned result is correct. Similarly, V = 0 if the signed result is correct. A natural question is “How do I know if the hex numbers in Figure 5.22 are supposed to represent signed or unsigned values?” The answer is, of course, that you do not know unless you are provided with additional information. There is nothing inherent in the 8-bit code 0xFF that says it represents 255 or −1; the application that uses the numbers determines if an unsigned or signed quantity is required. In the context of μC applications, this means that the programmer knows which representation (signed or unsigned) is intended, and therefore would know which status bits are appropriate. The binary logic performing the addition does not know if the numbers represent signed or unsigned quantities, nor does it matter. The adder logic works equally well assuming either representation.

Figure 5.22 Four cases of C, V flag settings

Sample Question: Give the V, N flag settings after the 8-bit operation 0x60 + 0x40. Answer: 0x60 + 0x40 = 0xA0. The MSb of 0xA0 is 1, so N = 1 (result is negative). Two positive numbers added together produce a negative number, so V = 1.

Operations on Signed Data In Chapter 4, you learned in the carry flag discussion that the subtraction A − B is actually performed as A + (~B) +1, for which the reasoning is now clear as −B = ~B + 1 by the definition of two’s complement. Figure 5.23 illustrates how a combinational building block capable of both

154

Chapter 5

■

Extended Precision and Signed Data Operations

addition and subtraction is built from an adder and a 2-to-1 mux. The SUB input connected to the mux select and the carry-in input of the adder determines if the operation A + B or A − B is performed. When SUB = 0, the output is Y = A + B + 0; when SUB = 1, the output is A + (~B) + 1, which is actually A − B. An adder/subtractor building block is a key component of the arithmetic logic unit of any microprocessor. Figure 5.23 clearly shows the advantage of two’s complement representation for signed numbers; the same binary adder logic used for addition/subtraction of unsigned numbers is used for signed numbers, with the inclusion of an inverter and a 2-to-1 mux, two relatively simple logic gates.

Figure 5.23 Adder/subtractor building block

Unfortunately, some operations on signed numbers require different hardware than the same operation on unsigned numbers, and thus, different assembly language instruction sequences. Table 5.1 lists the arithmetic operations discussed in this book and whether different hardware is required for unsigned and signed operations. Shift and comparison operations on signed data are discussed in this chapter, while multiplication and division are postponed until Chapter 7.

Table 5.1: Unsigned Versus Signed Arithmetic Operations Operation

Same Operation for Unsigned/Signed Data?

+, –

Yes

==, !=

Yes

, >=, (right shift)

No

*, /

No

Operations on Signed Data

155

Shift Operations on Signed Data In previous shift operation examples, a zero value has always been used as the shift-in value for the LSb (left shift) or MSb (right shift). At this point, let’s consider a shift operation on a signed (two’s complement) number. Assume a right shift of the value −128 is desired, which should yield −64 as a right shift is a divide-by-two operation (actually, this depends on the number that is shifted; more on this later). The value −128 is 0x80 as an 8-bit two’s complement number, and Figure 5.24(a) shows that this becomes a 0x40, or a +64, when a zero is used as the MSb input value. In Figure 5.24(b), the sign bit is retained during the shift, keeping the MSb as one, which produces the correct value of −64 or 0xC0. For two’s complement values, the sign bit must be retained during a right shift to obtain the correct arithmetic result of division-by-two. The PIC24 μC has an instruction named arithmetic shift right (asr) that preserves the sign bit; the asr instruction has the same addressing modes as the lsr (logical shift right) instruction discussed in Chapter 4.

Figure 5.24 Logical shift right versus arithmetic shift right

Figure 5.25 shows assembly code that implements an arithmetic shift right on 16-bit and 32-bit signed integers, which are int16_t and int32_t data types, respectively. The arithmetic right shift of the signed 16-bit variable i16_k simply uses the asr instruction instead of the lsr instruction. Arithmetic shifts of variables larger than 16 bits require that the asr instruction is used on the MSW to retain the sign bit, then the rrc instruction is used on subsequent more significant words to shift each bit right. For example, the arithmetic right shift of the signed 32-bit variable i32_j first uses the asr instruction on the MSW, followed by the rrc instruction on the LSW.

156

Chapter 5

■

Extended Precision and Signed Data Operations

Figure 5.25 Assembly code for arithmetic shift right operation

Even though Figure 5.24(b) shows that an arithmetic right shift of −128 is −64, an arithmetic right shift of a negative number is only equivalent to division by 2 in the C language if the number is even. For odd negative numbers, division by 2 in C and arithmetic right shift produce different results. Integer division in C truncates, so −5/2 is equal to −2 as shown in the following code: int8_t i8_k; i8_k = –5; i8_k = i8_k/2;

// this is 0xFB // returns –2, which is 0xFE

However, the arithmetic right shift version for −5 >> 1 returns −3, as seen in the following code: i8_k = –5; i8_k = i8_k >> 1;

// this is 0xFB = 0b11111011 // asr(0b11111011) = 0b11111101 = 0xFD, which is

–3!

This difference between division and right shift is not an issue for positive numbers or unsigned numbers. This is why a right shift operation in C compilers for signed numbers is implementation dependent (some retain the sign bit, some do not). When using signed numbers and dividing by powers of two, a division operation should be used instead of a right shift operation. It would seem logical to assume that there is also a need for retaining the sign bit during the left shift of a two’s complement operand. Figure 5.26 illustrates what happens when the 8-bit value 0x20 (+32) is shifted to the left two times. After the first shift, the new value is 0x40 (+64), the correct value in an arithmetic sense as +64 = 2 * (+ 32). After the second shift, the new value is 0x80 (−128), which is obviously incorrect from an arithmetic sense as the sign changed. However, if the sign bit is kept during the shift, the result is 0x00, again an incorrect result in an arithmetic sense. This is because +64 * 2 = +128, and +128 cannot be represented in 8 bits! If the sign bit changes after a left shift of a two’s complement value, overflow has occurred. Keeping the sign bit does not help; it is simply not possible to represent the correct arithmetic value using the available bits. Therefore, there is no need to distinguish left shift operations based on unsigned versus signed data.

Operations on Signed Data

157

Figure 5.26 Left shift operation on signed data

Comparisons of >, >=, , >= , , >=, =) test, the Z flag is dropped and the flag test simplifies to (~N&~V) | (N&V). The astute reader will recognize this flag test as ~(V^N) (the exclusive-NOR of the V and N flags), which is how this test is implemented in logic gates for signed branch instructions. The flag tests for the < and , signed

bra GT,

(~Z&~N&~V) | (~Z&N&V)

Branch >=, signed

bra GE,

(~N&~V) | (N&V)

Branch > 1; } while (i32_k >= i32_j); Answer: This is the same C code as used in a sample question from earlier in the chapter, except the data type has been changed from uint32_t (unsigned) to int32_t (signed). The new solution is given in Listing 5.2, with two changes made in the assembly code from the original solution of Listing 5.1. The lsr instruction originally used for the MSW is changed to an asr instruction in order to preserve the sign bit, and the unsigned bra GEU instruction is replaced with a signed bra GE instruction. Listing 5.2: Sample Question Solution top_loop: asr i32_j+2 rrc i32_j mov i32_j,W0 cp i32_k

; arithmetic shift right i32_j.MSW ; right shift i32_j.LSW ; i32_k.LSW - i32_j.LSW

Branch Instruction Encoding

mov i32_j+2,W0 cpb i32_k+2 bra GE, top_loop ... rest of code

161

; i32_k.MSW - i32_j.MSW ; loop if i32_k >= i32_j

Sample Question: In the following code, what is the value of i8_i when the loop is exited? Assume that the compiler preserves the sign bit of i8_i during right shift operations. int8_t i8_i; i8_i = 0x80; while (i8_i < -32) { i8_i = i8_i >> 1; } Answer: The variable i8_i is declared as an int8_t, so the assignment i8_i = 0x80 initializes i8_i to −128. Each time through the loop, i8_i is divided by 2 by the right shift assuming that the sign bit is preserved. Therefore, i8_i is −128, then −64, then −32, at which point the comparison is no longer true and the loop is exited, with i8_i = −32 (0xE0).

Branch Instruction Encoding You have been using branch instructions for several chapters; now is a good time to take a closer look at the way these are encoded into machine code. The machine code format of branch instructions uses an addressing mode known as relative, in which a two’s complement offset is added to the program counter to determine the target branch address. The branch instruction encoding is shown in Figure 5.31, with the branch target address (BTA) computed by adding 2*#Slit16 to PCold + 2, where #Slit16 is a 16-bit signed offset and PCold is the address of the branch instruction. The PCold +2 value is used because the PC is already incremented when the branch target address computation is performed. The assembler computes the #Slit16 value from BTA and PCold as shown in Figure 5.31. Figure 5.32 shows an example that calculates the #Slit16 value for the machine code of a branch instruction. The machine code in Figure 5.32 is representative of the code required for a loop structure like the one given in Listing 5.2. The top_loop label (0x0200) is the branch target address, while the branch location (PCold) is 0x0212. The branch displacement (#Slit16) is calculated as −10, or 0xFFF6 in 16-bit, two’s complement format. This example shows why the displacement is a signed number. A backward branch (when the branch target is at a lower memory address) requires a negative displacement, while a forward branch (when the branch target is at a higher memory address) uses a positive displacement. It is also evident that a branch target must be within the range of the displacement that can be encoded in the branch instruction word. A 16-bit displacement means

162

Chapter 5

■

Extended Precision and Signed Data Operations

Figure 5.31 Branch instruction encoding

that the branch target must be within −32768 to +32767 instruction words of PCold + 2. The advantage of branch instructions over a goto instruction is that a branch instruction only takes one instruction word, while a goto takes two instruction words. The disadvantage of a branch instruction is its limited range; a goto instruction can jump anywhere in program memory. Fortunately, a branch’s limited range is typically not a problem, as most loops tend to be much shorter than what is allowed by the 16-bit signed displacement. Program counter relative addressing is found in almost all microprocessor instruction sets.

Summary

163

Figure 5.32 Branch instruction encoding example

Summary Extended precision operations in the PIC24 μC allow manipulation of arbitrarily-sized data, 16 bits at a time. It is clear that variables of type uint32_t/int32_t and uint64_t/int64_t should not be used unless the extra precision offered by these data types is absolutely required by the application, as calculations on these data types require more instructions, more data RAM, and longer execution time. The standard method of signed integer representation for microprocessors is two’s complement format, which uses the same binary adder logic for addition and subtraction as used for unsigned numbers. Some operations, like right shift and >, >=, =, 1; u32_j--; }

Convert the following C code segments to PIC24 instruction sequences. Assume that u64_i, u64_j, and u64_k are all uint64_t data types and are located in near RAM. If you need to use other temporary memory locations in your solution, assume that these are located in near RAM as well. 5. Code fragment: do { u64_i = u64_i - u64_k; } while ( u64_i < (u64_j + u64_k) );

6. Code fragment: if (u64_i && u64_j) { u64_k = u64_k & 0xFEDCBA9876543210; }

7. Code fragment: u64_k = u64_j | u64_i;

Review Problems

165

8. Code fragment: while (u64_i != u64_j) { u64_k = u64_k >> 1; u64_j ; }

Perform the indicated conversions: 9. 10. 11. 12. 13.

The value −42 to 8-bit two’s complement. The 8-bit two’s complement value 0xDC to decimal. The 16-bit two’s complement value 0xFBA3 to decimal. The value −390 to 16-bit two’s complement. Sign extend the 8-bit value 0x85 to 16 bits.

Do the following calculations (problems 14 through 17 use 8-bit data sizes): 14. 15. 16. 17. 18.

Give the value of the operation 0x73 + 0x65 and the Z, N, V, C flag settings. Give the value of the operation 0x90 − 0x8A and the Z, N, V, C flag settings. Give the value of the operation 0xF0 + 0xCA and the Z, N, V, C flag settings. Give the value of the operation 0x2A − 0x81 and the Z, N, V, C flag settings. In the following code segment, what is the value of i8_i when the loop is exited? int8_t i8_i, i8_j; i8_i = 0x01; i8_j = 0x80; while (i8_i > i8_j) { i8_i++; }

19. In the following code segment, what is the final value of i8_k? Use the value 1 to represent true and 0 to represent false. int8_t i8_i = i8_j = i8_k =

i8_i, i8_j; 0xA0; 0x70; (i8_i > i8_j);

20. In the following code segment, what is the final value of u8_k? Use the value 1 to represent true and 0 to represent false. uint8_t u8_i, u8_j, u8_k; u8_i = 0xA0; u8_j = 0x70; u8_k = (u8_i > u8_j);

166

Chapter 5

■

Extended Precision and Signed Data Operations

21. In the following code segment, what is the final value of i8_i assuming that the sign bit is preserved for right shifts of signed data types? int8_t i8_i; i8_i = 0xA0 >> 2;

For the following problems, assume that i16_i, i16_j, i16_k are int16_t data types, i8_p, i8_q are int8_t data types, i32_r, i32_s are int32_t data types, and i64_x is an int64_t data type. All variables are located in near RAM. Convert the following C code segments to PIC24 instruction sequences. 22. Code fragment: do { i16_i = i16_i - i16_k; } while ( i16_i < (i16_j + i16_k) );

23. Code fragment: if (i16_k >= i16_j) { i16_i = i16_i >> 2; }

24. Code fragment: i16_k = (int16_t) i8_p + (i16_j > 2) & 0xA34D;

26. Code fragment: i32_r = (int32_t) i16_k + (i32_s > 2) | 0x38DB807F;

28. Code fragment: i64_x = (int64_t) i16_k + ((int64_t) i8_p > 1; pi32_x = &i32_a; pi16_y = &i16_b; pi32_x = pi32_x + 2; pu8_w = &au8_c[3];

Assume the initial memory and register contents of Table 6.1 at the beginning of each problem, 3 through 20. Give the new register and memory contents after the instruction is executed.

Review Problems

Table 6.1: Register Memory Contents Location

Value

Location

Value

W0

0x1004

0x1000

0x382A

W1

0x1006

0x1002

0xFB80

W2

0x8301

0x1004

0x80FF

W3

0xF0A2

0x1006

0x7B03

W4

0x0004

0x1008

0x0001

W14

0x0802

0x100A

0xCE46

W15

0x1004

0x100C

0x8B17

3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.

mov [ W1],W0 mov W1, [W0 + W4] mov.b [ W1], W0 mov.b W1, [W0 + W4] mov W2, [W0++] mov W2, [ W0] mov.b W2, [W0++] mov.b W2, [ W1] mov [W1 + W4], W2 mov [++W1], W1 mov [W1], [W0++] mov.b [W1 + W4], W2 mov.b [++W1], W1 mov.b [W1], [W0++] mov.b W1, [W0 + 3] mov [W0 - 4], W1 push W1 pop W2 pop W3 push W0 lnk #6 ulnk

209

210

Chapter 6

■

Pointers and Subroutines

25. The instruction call 0x0400 is located at program memory location 0x020A. What return address is pushed on the stack? 26. The instruction rcall 0x0250 is located at program memory location 0x0220. What return address is pushed on the stack? 27. Implement the following subroutine in PIC24 assembly language. Use the policy established in this chapter for using working registers for subroutine parameters and locals. // this subroutine implements a string swap. void str_swap(char* psz_1, char* psz_2){ char c_char; while (*psz_1 != 0) { c_char = *psz_1; *psz_1 = *psz_2; *psz_2 = c_char; psz_1++; psz_2++; } }

28. Implement the following subroutine in PIC24 assembly language. Use the policy established in this chapter for using working registers for subroutine parameters and locals. // this subroutine implements an uint16_t swap. void u16_swap(uint16_t* pu16_x, uint8_t u8_i, uint8_t u8_j){ uint16_t u16_k; u16_k = pu16_x[u8_i]; pu16_x[u8_i] = pu16_x[u8_j]; pu16_x[u8_j] = u16_k; }

29. Implement the following subroutine in PIC24 assembly language. Use the policy established in this chapter for using working registers for subroutine parameters and locals. // this subroutine implements a max function. int16_t find_max(int16_t* pi16_a, uint8_t u8_cnt) { int16_t i16_k; i16_k = -32768; while (u8_cnt != 0) { if (*pi16_a > i16_k) i16_k = *pi16_a; pi16_a++; u8_cnt ; } return i16_k; }

Review Problems

211

30. Implement the following subroutine in PIC24 assembly language. Use the policy established in this chapter for using working registers for subroutine parameters and locals. // This subroutine adds the contents of two integer arrays. // The number of elements to add is given by cnt. void i16vec_add (int16_t* pi16_a, int16_t* pi16_b, uint8_t u8_cnt){ while (u8_cnt != 0) { *pi16_a = *pi16_a + *pi16_b; pi16_a++; pi16_b ++; u8_cnt ; } }

31. Implement the putstr() function of the following C code as PIC24 assembly language. Use the policy established in this chapter for using working registers for subroutine parameters and locals. Assume the putch() function expects its input parameter to be passed in the W0 register; do not implement the putch() subroutine. void putch (uint8_t u8_char) { // code not shown } // print string void putstr(char* psz_in) { while (*psz_in != 0) { putch(*psz_in); psz_in++; } }

32. Implement the getstr() function of the following C code as PIC24 assembly language. Use the policy established in this chapter for using working registers for subroutine parameters and locals. Assume the return value of the getch() function is passed back via the W0 register; do not implement the getch() subroutine. uint8_t getch(void){ // not shown } // get string void getstr(char* psz_in){ uint8_t u8_char; do { u8_char = getch();

212

Chapter 6

■

Pointers and Subroutines

*psz_in = u8_char; psz_in++; } while (u8_char != 0) }

33. Assuming that a stack frame is used for subroutine parameters and locals, give the detailed stack frame for the subroutine of problem 26. 34. Assuming that a stack frame is used for subroutine parameters and locals, give the detailed stack frame for the subroutine of problem 27. 35. Implement the subroutine of problem 26 in PIC24 assembly language assuming that a stack frame is used to pass in subroutine parameters. You must use lnk and ulnk to establish a new local frame, but you may use registers for local variables. 36. Implement the subroutine of problem 27 in PIC24 assembly language assuming that a stack frame is used to pass in subroutine parameters. You must use lnk and ulnk to establish a new local frame, but you may use registers for local variables. 37. Write PIC24 assembly code that implements main() in the following C code. Use the approach of Figure 6.31 for initializing data memory. You must show the complete solution for your init_variables subroutine. //See code for ui16_swap from the previous problem. void ui16_swap(uint16_t* pu16_x, uint8_t u8_i, uint8_t u8_j); uint16_t au16_values[] = {489, 45, 1000, 238, 30000, 10134} main { ui16_swap(&au16_values[0], 3, 5); }

38. Write PIC24 assembly code that implements main() in the following C code. Use the approach of Figure 6.31 for initializing data memory. You must show the complete solution for your init_variables subroutine. // See code for ui16_swap from previous problem. void i16vec_add(int16_t* pi16_a, int16_t* pi16_b, uint8_t u8_cnt) int16_t ai16_x[] = {-3489, 239, 900, -216, 8920, -9345}; int16_t ai16_y[] = {980, 3766, -8472, 32000, -16788, 34}; int main(void) { // Note: this passes the starting addresses of // ai16_x, ai16_y to i16vec_add i16vec_add(ai16_x, ai16_y, 6); }

Chapter 7

Advanced Assembly Language: Higher Math

T

his chapter examines various higher math topics such as multiplication and division operations for unsigned and signed integers, floating-point number representation, saturating arithmetic, BCD arithmetic, and ASCII/binary conversions.

Learning Objectives After reading this chapter, you will be able to: ■ ■ ■

■ ■ ■

Implement signed and unsigned integer multiplication in PIC24 assembly language. Implement signed and unsigned integer division in PIC24 assembly language. Discuss the formatting and storage requirements of single- and double-precision floatingpoint numbers. Implement saturating addition and subtraction operations in PIC24 assembly language. Implement BCD addition and subtraction operations in PIC24 assembly language. Implement ASCII-to-binary and binary-to-ASCII for both hex and decimal number formats in PIC24 assembly language.

213

214

Chapter 7

■

Advanced Assembly Language: Higher Math

Multiplication In C, the multiplication operation is written as product = multiplicand * multiplier. For integer multiplication, the number of bits required for the product to prevent overflow is the sum of the bits in the multiplicand and multiplier. Typically, the two operands are the same size, so two n-bit operands produce a 2n-bit result. Figure 7.1 shows a paper and pen multiplication of two 3-bit operands that produces a 6-bit product. Starting with the rightmost bit of the multiplier, a partial product is formed by multiplying the multiplier bit with the multiplicand, with the rightmost bit of the partial product aligned under the multiplier bit that produced it. Since this is binary multiplication, a 1 in the multiplier produces a partial product that is equal to the multiplier, while a 0 produces a partial product of all zero bits. The product is formed from the sum of all of the partial products.

Figure 7.1 3 x 3 unsigned multiplication

The multiplication operation can be implemented in numerous ways. The cheapest method in terms of logic gates is to not add any support for multiplication to the ALU, and to simply rely on pre-existing microprocessor add and shift operations to perform a multiplication. An algorithm for an unsigned integer multiplication using add/shifts is seen in Figure 7.2. The two n-bit operands are named mc (multiplier) and mp (multiplicand). The ph variable holds the accumulated sum of the partial products, and at algorithm termination, ph contains the upper n bits of the product. The algorithm loops n times, once for each bit of the multiplier (mp). On each loop iteration the LSb of mp is tested; if 1, the multiplicand is added to the ph variable. If the LSb of mp is 0, then addition is not performed as the partial product is zero in this case, making the addition superfluous. The shift right of the Cflag, ph, and mp values accomplishes two things: ■

■

The LSb of the ph variable is a final bit of the product; shifting ph right moves this bit into the MSb of mp, saving this bit for the result. The right shift moves the next bit of the multiplier (mp) into the LSb for testing at the top of the loop. As the loop iteration proceeds, each bit of the multiplier is examined from LSb to MSb.

Multiplication

215

After n iterations, the multiplication is finished and the loop is exited. The ph variable contains the upper n bits of the product, and mp the lower n bits. The ph variable is copied to the mc variable so that the final 2n-bit product returns in the original operands as mc:mp.

Figure 7.2 Unsigned add/shift integer multiplication algorithm

The disadvantage of the shift/add technique for multiplication is obvious—it is slow! An assembly language implementation requires several instruction cycles for each loop iteration assuming separate shift and add instructions. If hardware support for the shift/add iteration is added to the ALU in the form of a double-length shift register for the product and specialized loop control, this can be reduced to one clock cycle per loop iteration (eight clock cycles). While this would be an improvement, a faster method is to augment the ALU with a specially designed multiplier unit such as an array multiplier that produces the result in one clock cycle. Figure 7.3 shows a naive implementation of a 3 x 3 array multiplier that performs the operation of Figure 7.1. There are more efficient methods for constructing array multipliers, but this conveys the key point of an array multiplier: the product is available as a combinational delay after the inputs are applied. This means the multiplication is completed in one clock cycle (if the clock cycle is long enough). The origin of the term array multiplier is obvious from Figure 7.3, as it is built from an array of full adders

216

Chapter 7

■

Advanced Assembly Language: Higher Math

and half adders that implements the addition of the partial products. Observe that binary multiplication for each partial product bit is simply an AND gate, as the Boolean multiplication a * b is a 1 only if both inputs are 1.

Figure 7.3 Naive 3 x 3 unsigned array multiplier

The array multiplier of Figure 7.3 implements unsigned multiplication; there are iterative and array multiplier architectures [3, 4] that implement signed multiplication assuming two’s complement encoding. The PIC24 has a 16 x 16 array multiplier that accepts both signed and unsigned operands and produces either a 16-bit or a 32-bit result, depending on the variant of instruction (MULW or MUL). Figure 7.4 shows the various PIC24 multiplication instruction forms. The three-operand register addressing forms implement a 16 x 16 multiplication and support the four possible variations of unsigned/signed operands for the multiplicand/multiplier operands. The 32-bit product variant is written to the Wnd+1:Wnd register pair, with Wnd containing the least significant word and Wnd+1 the most significant word. The mul{.b} f instructions implement either a 16 x 16 or 8 x 8 unsigned multiplication, with the 32-bit product written to W3:W2, and the 16-bit product to W2. The literal forms implement a 16 x 16 multiplication using an unsigned 5-bit literal (#lit5) as the multiplier with either an unsigned or signed multiplicand in Wb, with the 32-bit result placed in the Wnd+1:Wnd register pair. For any 32-bit product, the destination register for the least significant word (Wnd) must be an even-numbered register and may not be W14.

Multiplication

217

Figure 7.4 PIC24 multiplication instruction forms

Listing 7.1 shows several multiplication examples that illustrate the differences between unsigned and signed operands. Register W0 has the 16-bit value 0xFFFF, which is 65,535 as an unsigned integer, and −1 as a two’s complement integer. Register W1 has the 16-bit value of 0x0001, which is 1 as an unsigned integer and +1 as a two’s complement integer. Observe that the mul.uu W0, W0, W2 instruction treats both input operands as unsigned, performing 65,535 * 65,535 for a result of 4,294,836,225, or 0xFFFE0001. The mul.ss W0, W0, W4 instruction treats both input operands as signed, performing −1 * −1 for a result of +1, or 0x00000001. Listing 7.1: Multiplication Instruction Examples (1) (2) (3) (4) (5) (6) (7) (8)

mov #0xFFFF, W0 mov #0x1, W1 mul.uu W0, W0, W2 mul.ss W0, W0, W4 mul.uu W0, W1, W6 mul.ss W0, W1, W8 mul.uu W0, #1, W10 mul.su W0, #1, W12

; ; ; ; ; ; ; ;

65535 unsigned, -1 signed 1 unsigned, +1 signed 65535 * 65535 = 4294836225 = 0xFFFE0001 = W3:W2 -1 * -1 = +1 = 0x00000001 = W5:W4 65535 * 1 = 65535 = 0x0000FFFF = W7:W6 -1 * +1 = -1 = 0xFFFFFFFF = W9:W8 65535 * 1 = 65535 = 0x0000FFFF = W11:W10 -1 * 1 = -1 = 0xFFFFFFFF = W13:W12

218

Chapter 7

■

Advanced Assembly Language: Higher Math

64-Bit Multiplication The shift/add approach of Figure 7.2 is scaleable, in that it can be applied to any size operand. One method for using the 16 x 16 hardware multiplication of the mul instruction for a 32 x 32 multiplication to produce a 64-bit product is shown in Figure 7.5, with s and r containing the 32-bit operands. Four 32-bit partial products are formed using 16 x 16 multiplications as pp0=sL*rL, pp1=sL*rH, pp2=sH*rL, and pp3=sH*SL, where {sL, rL} and {sH, rH} are the lower and upper words of the 32-bit operands s and r. Observe that the partial products pp1 and pp2 are shifted to the left such that the lower words of these 32-bit partial products align with the upper word of pp0; the lower word of pp3 is aligned with the upper words of pp1 and pp2. When you’re performing the word additions of the partial products, take care to propagate the carries across all partial products during the summation.

Figure 7.5 Unsigned 32 x 32 multiplication using 16 x 16 multiplications

A subroutine named mult32x32_uns that implements the 32 x 32 multiplication of Figure 7.5 is given in Listing 7.2. The s and r 32-bit input operands are passed in W1:W0 and W3:W2, respectively. The 64bit result is passed back in W3:W2:W1:W0 as per the working register usage policy established in Chapter 6. All four partial products are computed first using mult.uu instructions, with a register usage of pp0=W5:W4, pp1=W7:W6, pp2=W9:W8, and pp3=W11:W10. Additions using add and addc instructions then implement the sums of the upper and lower words of the partial products, as per Figure 7.5.

Multiplication

219

The addc instructions are used to propagate carries all the way to the upper word of pp3. The main code of Listing 7.2 shows a sample call to the mult32x32_uns subroutine. To improve the readability of the code, registers used are given symbolic names taken from Figure 7.5. For example, the two statements sL = W0 and sH = W1 cause instances of sL and sH to be replaced with W0 and W1 as the code is assembled. Listing 7.2: Unsigned 32 x 32 Bit Multiplication main: mov #0xFFFF, W0 ; mov #0xFFFF, W1 ; s = W1:W0 = 4294967295 mov #0xFFFF, W2 ; mov #0xFFFF, W3 ; r = W3:W2 = 4294967295 call mult32x32_uns ;;W3:W2:W1:W0 = 0xFFFFFFFE00000001 = 18446744065119617025 done: ;do not return bra done ; p = s * r, where: ; W1:W0 = s sL = W0 sH = W1 ; W3:W2 = r rL = W2 rH = W3 ; Use W4-W11 to store low and high words of partial products 0-3 pp0L = W4 pp0H = W5 pp1L = W6 pp1H = W7 pp2L = W8 pp2H = W9 pp3L = W10 pp3H = W11 ; 64-bit result in p = W3:W2:W1:W0 (p3:p2:p1:p0) p0 = W0 p1 = W1 p2 = W2 p3 = W3 mult32x32_uns: push W8 push W9

220

;

; ;

;

Chapter 7

■

Advanced Assembly Language: Higher Math

push W10 push W11 mul.uu sL, rL, pp0L ; sL*rL = pp0 mul.uu sL, rH, pp1L ; sL*rH = pp1 mul.uu sH, rL, pp2L ; sH*rL = pp2 mul.uu sH, rH, pp3L ; sH*rH = pp3 mov pp0L, p0 ; p0 = pp0L add pp0H, pp1L, p1 ; p1 = pp0H + pp1L now propagate carry all the way up to p3 word addc pp1H, pp2H, p2 ; p2 = pp1H + pp2H + cout(pp0H + pp1L) addc pp3H, #0, p3 ; p3 = pp3H + 0 + cout(previous sum) next sum add p1, pp2L, p1 ; p1 = pp2L + (p1 = pp0H + pp1L) now propagate carry all the way up to p3 word addc p2, pp3L, p2 ; p2 = pp3L + (p2 = pp1H + pp2H) + cout(previous_sum) addc p3, #0, p3 ; p3 = p3 + 0 + cout(previous_sum) 64-bit result p3:p2:p1:p0 pop W11 pop W10 pop W9 pop W8 return

A signed 32 x 32 bit multiplication can be implemented using the mult32x32_uns subroutine of Listing 7.2 by first converting each negative operand to a positive number, performing the unsigned multiply, and then negating the product by subtracting it from 0 if either of the operands was originally negative. Sample Question: What does the product 0x3A * 0xA8 return if the numbers are 8-bit unsigned? 8-bit signed? (two’s complement) Answer: As unsigned numbers, the product is 0x3A * 0xA8 = 58 * 168 = 9,744 = 0x2610. As signed numbers, the product is 0x3A * 0xA8 = +58 * (−88) = −5,104 = 0xEC10.

Division Equation 7.1 represents the division operation, where p is the dividend, q is the quotient, d is the divisor, and r is the remainder. q, r =

p d

(7.1)

Division

221

The relationship between q, r, p, and d is more clearly expressed by Equation 7.2. p= q×d +r

(7.2)

Implementations of the division operation typically use a 2n-bit dividend, an n-bit divisor, and produce an n-bit quotient and n-bit remainder. Figure 7.6 shows a paper and pen division of an 8-bit dividend by a 4-bit quotient, producing a 4-bit quotient and a 4-bit remainder. The subtraction performed at each step produces a partial dividend, which forms the dividend for the next stage. The last subtraction produces the remainder, which is guaranteed to be in the range 0 to d−1. Unlike multiplication, overflow can occur if the quotient requires more than n bits, which is true if the value formed by the upper n bits of the dividend is greater than or equal to the divisor.

Figure 7.6 Unsigned division (8-bit dividend, 4-bit quotient)

Several iterative division algorithms use shift/subtract operations to produce the quotient and remainder. Figure 7.7 shows the restoring division algorithm [3] for a 2n-bit dividend p and an n-bit divisor d. The high and low bytes of p are designated as pH and pL, respectively. On algorithm entry, the comparison pH >= d is performed to check for overflow; if true, the carry flag is set to 1 and the algorithm terminates. Like the add/shift multiplication algorithm, the main loop performs n iterations, with each iteration determining a quotient bit. A quotient bit is 1 if the partial dividend Cflag,pH >= d, in which case the new partial dividend is pH-d. A quotient bit is 0 if Cflag,pH < d, and the partial dividend remains the same. The first operation of the loop performs the shift Cflag←pH←pL, moving the partial dividend into the Cflag and upper n bits of pH. If the shift produces a carry, the partial dividend is greater than the divisor, so the new partial dividend is computed as pH-d→pH and the quotient bit is set to 1 (the LSb of pL is the current quotient bit). If no carry is

222

Chapter 7

■

Advanced Assembly Language: Higher Math

produced by the shift, the subtraction pH-d→pH is performed, which has two side effects: a) the comparison d>pH is determined by the state of the Cflag, and b) the new partial dividend is computed. If Cflag is a 1, this indicates that no borrow occurred, so pH >= d, the new partial dividend is valid, and the quotient bit is set to 1. If Cflag is a 0, a borrow occurred, so pH < d, meaning the partial dividend should have been left undisturbed. In this case, the operation pH+d→pH is performed to restore the partial dividend to its original value and the quotient bit is cleared to 0. This action of performing the subtraction pH-d→pH and then restoring the partial dividend, if necessary, is why this algorithm is called restoring division. When the loop terminates after n iterations, the quotient is contained in pL and the remainder in pH.

Figure 7.7 Unsigned restoring division algorithm

Division

223

There are faster iterative methods for division that use a multiplication operation in producing the quotient and remainder, but these require considerably more logic gates because an array multiplier is needed in the implementation. One method for accomplishing signed division is to convert the dividend and divisor to positive numbers, performing the unsigned division, then post-correct the sign of the quotient and remainder. If either of the original operands is negative, the quotient is negated. If the original dividend is negative, the remainder is negated. Unlike multiplication, if a microprocessor has an explicit integer division instruction, such as a 16-bit/8-bit operation, it is not possible to use this instruction in the implementation of a larger operation such as a 32-bit/16bit division. As such, some microprocessors offer different sized integer division operations such as 16-bit/8-bit, 32-bit/16-bit, and 64-bit/32-bit. Figure 7.8 shows the PIC24 division instruction forms. Both signed and unsigned 16-bit/16-bit and 32-bit/16-bit operations are available. In all cases, the 16-bit quotient and 16-bit remainder return in the W0 and W1 registers, respectively. The divisor (Wn) register must be contained in registers W2 or higher, as the dividend (Wm) is copied to registers W0 and W1 at the beginning of the operation. The W1 register either contains the most significant word of the 32-bit dividend for the 32-bit/16-bit operation, or the sign-extended or zero-extended most significant word of the 16-bit dividend for the 16-bit/16-bit operation. The N and Z flags reflect the status of the remainder. The V flag is set on overflow, which occurs if the quotient exceeds the 16-bit range. The C flag is used during the division operation and thus its final value is operand dependent. Division by zero causes an arithmetic trap (see Chapter 9 for a complete discussion of traps and interrupts).

Figure 7.8 PIC24 multiplication instruction forms

224

Chapter 7

■

Advanced Assembly Language: Higher Math

Listing 7.3 shows some division examples. The division instruction must be preceded by a repeat #17 instruction, which repeats the division instruction 17 + 1 = 18 times, as the division instruction requires 18 iterations to complete for both the 32-bit/16-bit and 16-bit/16-bit varieties. This means that 19 instruction cycles are required for division, which includes the instruction cycle for the repeat #17 instruction. The divisions of lines 8, 10, and 12 are signed divisions that change the sign of the operands, but keep their magnitudes the same. The remainder’s sign is the same as the dividend, and the quotient’s sign is positive if both operands have the same sign and negative otherwise. The division of line 17 shows an overflow example for an unsigned 32-bit/16-bit operation using the operands 65,536/1; the quotient of 65,536 exceeds the maximum unsigned 16-bit value of 65,535. The division of line 21 shows an overflow example for a signed 16-bit/16-bit operation using the operands –32,768/–1; the quotient of +32,768 exceeds the maximum positive 16-bit value of +32,767. Listing 7.3: Division Examples main: (1) mov #0x9A00, W2 ; 39,424 unsigned, -26,112 as signed (2) mov #0x6600, W3 ; 26,112 unsigned, +26,112 as unsigned (3) mov #105, W4 ; 105 unsigned, +105 signed (4) mov #0xFF97, W5 ; 65,431 unsigned, -105 signed (5) repeat #17 (6) div.u W2, W4 ; 39,424/105 = 375 = W0, r = 49 = W1 (7) repeat #17 (8) div.s W2, W4 ; -26,112/+105 = -248 = W0, r = -72 = W1 (9) repeat #17 (10) div.s W3, W5 ; +26,112/-105 = -248 = W0, r = +72 = W1 (11) repeat #17 (12) div.s W2, W5 ; -26,112/-105 = +248 = W0, r = -72 = W1 (13) mov #0x0, W6 (14) mov #0x0001, W7 ; W7:W6 = 0x00010000 = 65,536 double word (15) mov #0x01, W8 ; W8 = 1 (16) repeat #17 (17) div.ud W6, W8 ; 65,536/1 is overflow as quotient > 16-bits (18) mov #0x8000, W2 ; -32,768 signed (19) mov #0xFFFF, W3 ; -1 signed (20) repeat #17 (21) div.s W2, W3 ; -32,768/-1 is overflow since +32,768 > 16-bits

Fixed-Point and Saturating Arithmetic

225

Sample Question: What does the 16-bit/16-bit operation 0x9EF0/0x018D return for the div.u operation? For the div.s operation? Answer: The div.u operation treats its operands as unsigned numbers, so 0x9EF0 = 40,688 and 0x018D = 397. The division 40,688/397 produces values of 102 (quotient) and 194 (remainder). In hex, this is 0x0066 and 0x00C2. As a check, quotient * divisor + remainder = dividend, or 102 * 397 + 194 = 40,688. The div.s operation treats its operands as signed numbers, so 0x9EF0 = –24,848 and 0x018D = +397. The division –24,848/+397 produces values of –62 (quotient) and –234 (remainder). In hex, this is –62 = 0xFFC2, –234 = 0xFF16. As a check, quotient * divisor + remainder = dividend, or (–62) * (+397) + (–234) = –24,848.

Fixed-Point and Saturating Arithmetic Up to this point, you have viewed binary integers as having the decimal point always located to the right of the least significant bit. The formal name for this type of representation is fixed-point, because the decimal point is fixed to a particular location. The decimal point can be positioned in any location within the binary number, as long as the application is consistent about where the decimal point is located. A fixed-point binary number is said to have the format x.y, where x is the number of digits to the left of the decimal point (integer portion) and y is the number of digits to the right of the decimal point (fractional portion). The integer portion of the number has a range of 0 to 2x –1, while the fractional range is 0 to (1–2–y ). This gives a number range of 0 to (2x –2–y ). The 8-bit unsigned integer representation used to this point has thus been 8.0 fixed-point numbers, which has a number range of 0 to 255. Moving the decimal point all the way to the left gives a 0.8 fixed-point number that has a number range of 0 to (20 –2–8), or 0 to approximately 0.9961. A 6.2 fixed-point number has a number range of 0 to (26 –2–2), or 0 to 63.75. Table 7.1 shows examples of different 8-bit fixed-point formats.

Table 7.1: Sample Fixed-Point Formats Format

Min

Max

Example

8.0

0

255

0xA7 = 10100111 = 167

6.2

0

63.75

0xA7 = 101001.11 = 41.75

4.4

0

15.9375

0xA7 = 1010.0111 = 10.4375

0.8

0

0.99609375

0xA7 = 0.10100111 = 0.65234375

226

Chapter 7

■

Advanced Assembly Language: Higher Math

Decimal to x.y Binary Format The easiest method for converting an unsigned decimal number to its fixed-point representation is to multiply the number by 2y, then convert the integer portion to binary. If the remaining fraction after the multiplication by 2y is non-zero, then the resulting number is an approximation of the original number. Obviously, the more bits used for y in the x.y format, the better the approximation. Another method is to convert the integer and fractional portions separately, with the conversion of the fractional portion f done bit-by-bit through an iterative method. The iterative process performs the comparison f • 2 ≥ 1; if this is true, the new binary digit is 1 and the new fractional part is f ← ( f • 2) – 1. If f • 2 ≤ 1, the new binary digit is 0 and the new fractional part is f ← f • 2. The binary digits of the fractional part are determined left to right (most significant to least significant). The process stops when y binary bits of the final x.y binary result have been computed. Sample Question: Convert 13.365 to a binary 8-bit number in 4.4 fixed-point format. Answer: Multiplying 13.365 by 24 (16) produces 213.84. Truncating to 213, and converting to binary gives 0b11010101, or 0xD5. The following steps show the iterative method for converting the fractional portion 0.365 to its 4-bit binary representation. 1.

0.365 * 2 = 0.73, which is < 1. The first (leftmost) binary digit is 0, and the new f is 0.73.

2.

0.73 * 2 = 1.46, which is > 1. The second binary digit is 1, and the new f is 1.46 – 1 = 0.46.

3.

0.46 * 2 = 0.92, which is < 1. The third binary digit is 0; the new f is 0.92.

4.

0.92 * 2 = 1.84, which is > 1. The fourth and last binary digit is 1.

Thus, the 4-bit representation of the fractional portion is 0b0101, and the complete number is 0b11010101, or 0xD5.

x.y Binary Format to Decimal Conversion An unsigned fixed-point binary number is converted to decimal by multiplying each bit by its appropriate binary weight. The fractional bits have weights 2–1, 2–2, ... 2–y going from leftmost bit to rightmost bit. Another method is to view the n-bit number as an n.0 fixed-point number and divide that number by 2y to get the x.y decimal value. Observe that dividing by 2y is the same as shifting the n.0 fixed-point number to the right by y positions.

Fixed-Point and Saturating Arithmetic

227

Sample Question: Convert 0xD5, an unsigned 4.4 binary number, to its decimal value. Answer: The value 0xD5 is 0b11010101, so the integer portion is 1101, or 13. The fractional portion 0101 is (left to right): 0*2–1 + 1*2–2 + 0*2–3 + 1*2–4 = 0 + 0.25 + 0 + 0.0625 = 0.3125. Thus, 0xD5, an unsigned 4.4 binary number, is 13.3125. Note that the value 0xD5 was the result obtained in the previous sample problem when converting 13.365 to a 4.4 binary format. This indicates the approximation that occurs in the decimal to fixed-point binary conversion because of the limited number of bits in the fractional portion. An alternate method is to note that 0xD5 is the value 213 as an 8.0 fixed-point number and compute 213/24 = 213/16 = 13.3125.

Signed Fixed-Point Two’s complement x.y fixed-point numbers have a range of +(2x–1 –2–y ) to –2x–1. Thus, an 8.0 format has a range +(27 –2–0 ) to –27, or +127 to –128. A 6.2 format has a range of +(25 –2–2) to –25, or +31.75 to –32.0, while a 1.7 format has a range of +(20 –2–7) to –25, or +0.9921875 to –1.0. Conversion of x.y two’s complement fixed-point in binary can be done by viewing the number as an (x + y).0 number, computing its decimal magnitude by the two’s complement binary to decimal conversion rules of Chapter 5, then dividing the number by 2y. A signed decimal number can be converted to its x.y binary format by multiplying the number by 2y, then converting the integer portion to binary. Sample Question: Convert –3.25 to a binary number in 4.4 fixed-point format. Answer: Multiplying –3.25 by 24 (16) produces –52, which is 0xCC in two’s complement. Thus, –3.25 in 4.4 signed fixed-point format is 0xCC.

Sample Question: What is the decimal value of 0xD5 if this represents a 4.4 signed fixed-point number? Answer: The value 0xD5 converted to an integer decimal two’s complement number is –43. Dividing –43 by 24 (16), gives the final value of –2.6875. Observe that this is not the same decimal value obtained for 0xD5 when it was previously viewed as a 4.4 unsigned fixed-point number (the decimal value was 13.3125), which is obvious given that the signed decimal value must be negative since the most significant bit of 0xD5 is a 1. Also, the decimal value of 13.13125 exceeds the range of a signed 4.4 fixed-point number, which is +7.9375 to –8.0.

228

Chapter 7

■

Advanced Assembly Language: Higher Math

0.n Fixed-Point Format and Saturating Operations In the coverage of the multiplication operation, you may have noticed a troubling problem: to prevent overflow, the size of the operands has to keep doubling! For example, an 8 x 8 multiplication produces a 16-bit product. If this value is then used in a subsequent 16 x 16 multiplication operation, a 32-bit product is produced. Note that the product size doubles again to 64 bits if the previous 32-bit product is used in a 32 x 32 multiplication. Obviously, it is not possible to keep doubling the size of the operands in each multiplication, so eventually an n-bit value must be used to hold the result of an n x n bit multiplication. If the operands are viewed as unsigned integers between 0 and 2n–1, overflow occurs if the upper n-bit value of the actual 2n-bit product is non-zero. When overflow does occur, for multiplication, addition, or subtraction, what can be done about it? In some cases, it is sufficient to simply set an error flag and let the higher-level application code deal with the problem. In other cases, such as real-time digital signal processing applications like audio or video data manipulation, there is no way to halt the system to “fix” the overflow problem. One approach to keep functioning in the presence of overflow is to produce a value that is a reasonable approximation of the correct answer. The 0.n unsigned fixed-point format is often used for data in digital signal processing applications, because of its advantages in regard to multiplication overflow and using the same sized operands for all operations. Numbers in 0.n unsigned fixed-point format have the range [0,1) (up to 1 but not including 1), where the maximum value gets closer to 1 as n increases. When two 0.n unsigned fixed-point numbers are multiplied, the upper n bits of the 2nbit product are kept, while the lower n bits are discarded to keep the resulting product size as n bits. The lower n bits of the 0.2n product that are discarded are the least significant bits, which are the bits that one wants to be discarded if precision has to be limited. With the 0.n unsigned fixed-point representation, the multiplication operation cannot overflow, because the result is always in the range [0,1). Also, while the result is not the exact product since bits have been discarded, it is a good approximation of the correct product. It would be nice to have addition and subtraction operations that performed in a similar manner with regard to overflow; that is, when overflow occurs, a value is returned that is a close approximation of the correct result. Saturating addition and subtraction operations clip results to maximum and minimum values in the presence of overflow or underflow. Figure 7.9 shows examples of unsigned saturating addition and subtraction for 8-bit numbers. On unsigned overflow (carryout of the most significant bit), the result is saturated to all 1s, which is the maximum unsigned value. On unsigned underflow (borrow from the most significant bit), the result is clipped to the minimum value of zero. It is clear that the unsaturated results are nonsensical when overflow occurs, while the saturated results return the closest possible approximation given the range limits. Listing 7.4 shows assembly code for a sat_add subroutine that implements W0 = W0 + W1 using unsigned saturating addition. If the carry flag is set after the add instruction, the setm instruction is used to set the W0 result to all 1s. Signed saturating addition clips values to either the maximum

Fixed-Point and Saturating Arithmetic

229

Figure 7.9 Unsigned saturating addition/subtraction examples

positive value or maximum negative value on two’s complement overflow. Some microprocessors, especially those touted as being especially suited for digital signal processing applications, have specialized instructions that directly implement saturating arithmetic; Microchip’s dsPIC® microcontroller family provides one example. The C language does not have saturating arithmetic operators or data types, and thus saturating arithmetic must be implemented as a specialized library of function calls. Listing 7.4: Assembly Code for Unsigned Saturating Addition ; Do saturating word addition W0 = sat_add(W0+W1) sat_add: add W0, W1, W0 bra NC, sat_add_1 setm W0 sat_add_1: return Sample Question: What does the sum 0xA0 + 0x90 equal as a saturated unsigned addition? As a saturated signed addition? Answer: With binary addition, the sum 0xA0 + 0x90 = 0x30, with C = 1, V = 1. As a saturated unsigned addition, the result clips to the maximum unsigned value of 0xFF because unsigned overflow occurred (C = 1). As a saturated signed addition, the result clips to the maximum signed negative value of 0x80 because two negative numbers were added and the two’s complement overflow occurred (V = 1).

230

Chapter 7

■

Advanced Assembly Language: Higher Math

The dsPIC® Microcontroller Family The dsPIC® microcontroller family as represented by the dsPIC30F/dsPIC33F product lines implements a superset of the PIC24 instruction set. The dsPIC μC family preceded the PIC24 μC family in terms of release dates, and includes a separate arithmetic logic unit (ALU) that supports saturating operations on two’s complement fixed-point numbers in 16-bit, 32-bit, and 40-bit operand sizes. The additional dsPIC instructions that are not supported by the PIC24 μC are all instructions that are executed by this specialized ALU. Some of the saturating operations supported by this ALU are add, subtract, multiply to accumulator, square to accumulator, multiply-accumulate, multiplysubtract, and square-accumulate. The accumulator is a special-purpose register that allows a multiplication product to be added or subtracted from the accumulator contents in the same instruction. Many digital signal filter architectures are implemented more efficiently when this operation type is provided. Coverage of these additional instructions is beyond the scope of this text; check out the 16-bit MCU and DSC Programmer’s Reference Manual [5] for more details.

Floating-Point Number Representation Fixed-point representation forces an application to determine a priori the number of bits to devote to the integer and fractional parts. More bits used for the integer portion means less precision for the fractional part and vice versa. A floating-point (FP) representation encodes an exponent field in the binary encoding, removing the need to allocate a fixed number of bits for the integer and fractional representation. This section gives a brief overview of floating-point number encoding and floating-point number operations in microprocessors; a more detailed discussion is found in [6].

IEEE 754 Floating-Point Encoding Many different encodings for floating-point numbers have been proposed and used over the years, but in 1985, after a long review process, the IEEE 754 Standard for Binary Floating-Point Arithmetic was approved. Figure 7.10 shows the formats for single and double precision floating-point numbers in IEEE 754 format. The single precision format is 32 bits, while the double precision format is 64 bits. Each encoding is divided into sign, exponent, and significand fields. The use of the fields of Figure 7.10 to produce a floating-point number is given in Equation 7.3.

( 1)

sign

× 1.significand × 2exponent  bias

(7.3)

This is a signed magnitude encoding, so the most significant bit is the sign bit, which is 1 if the number is negative and 0 if positive. The significand field (also known as the mantissa) determines the precision of the floating-point number. You can view the significand as encoding both the integer and fractional parts of the floating-point number. The exponent field determines the range of the floating-point number. For the single precision format, the exponent field is 8 bits and is encoded

Floating-Point Number Representation

231

Figure 7.10 Single precision and double precision FP formats

in bias 127, which means that 127 has to be subtracted from the field value to determine the actual exponent. This allows exponents to be compared using an unsigned comparison, which takes fewer logic gates for implementation and can have less delay than a signed comparison. For normal floating-point numbers, the exponent codes 0x01 through 0xFE are allowed. The exponent encodings 0x00 (all 0s) and 0xFF (all 1s) are reserved for so-called special numbers, discussed later in this section. Thus, the exponent range for single precision, IEEE 754 floating-point numbers is 2+127 (10+38) to 2–126 (10–38). The double precision format uses an 11-bit exponent field, with a bias value of 1023. The exponent range for double precision, IEEE 754 floating-point numbers is 2+1023 (10+307) to 2–1022 (10–308). In the C language, the float and double types are used for single precision and double precision floating-point variables, respectively. The MPLAB ASM 30 assembler supports specification of floating-point values using the .double and .single assembler directives, for double precision and single precision encodings, respectively. Figure 7.11 shows an example of converting a decimal number to its single precision, floating-point number representation. First, the decimal number is converted to its binary representation by converting the integer and fractional parts to binary. The binary number is then normalized to the form of Equation 7.3 by shifting the number to the left or right. Each time the number is shifted to the left (multiplied by 2), the exponent is decremented by 1. Each time the number is shifted to the right (divided by 2), the exponent is incremented by 1. Observe that the 1 to the left of the decimal point in Equation 7.3 is not encoded in the significand; it is understood to be in the encoding. This is often referred to as the phantom one bit, and provides an extra bit of precision to the significand without having to provide space for it in the significand field. Converting a binary value in single precision FP format to its decimal representation is done by simply converting each component of Equation 7.3 to its decimal representation and multiplying as seen in Figure 7.12. The most common error in this conversion is to forget to add the phantom one bit to the significand.

232

Chapter 7

■

Advanced Assembly Language: Higher Math

Figure 7.11 Decimal to single precision FP format conversion

Figure 7.12 Single precision FP format to decimal conversion

Floating-Point Number Representation

233

The all-ones and all-zero exponent encodings are reserved for special number encoding. Special numbers are zero, positive/negative infinity (±∞), and NaN (Not a Number). Table 7.2 gives the encodings for special numbers. Infinity is produced when anything is divided by zero. A NaN is produced by invalid operations, such as zero divided by zero, or infinity minus infinity.

Table 7.2: Special Number Encodings Special Number

Encoding

zero

All fields are zero

±∞

Exponent field is all ones, significand is zero

NaN

Exponent field is all ones, significand is non-zero

Sample Question: What does the 32-bit value 0xFF800000 represent as a single precision floating-point number? Answer: The value is 0xFF800000 = 0b1111 1111 1000 0000 0000 0000 0000 0000. Grouping this into fields produces sign bit = 1, exponent = 1111 1111, significand is all zeros. By Table 7.2, this value is – ∞ (negative infinity).

Floating-Point Operations A complete discussion of the implementation of floating-point arithmetic is beyond the scope of this book. To provide a glimpse at what is involved in performing floating-point arithmetic, the basic steps required to perform a floating-point addition are given in Table 7.3. The hardware required to support floating-point operations is much more complex than fixed-point arithmetic. Speed comparisons of floating-point instructions versus integer instructions depend greatly on the particular hardware floating-point implementation. In comparing the latency of single precision floatingpoint operations versus integer operations on the Intel® Core™2 processor, FP add/subtraction instructions are about five times slower than integer operations, while FP multiplication and division are actually faster than integer multiplication and division [7]. For microprocessors such as the PIC24 that do not have floating-point hardware support, library subroutines are used to implement floating-point operations. To provide a feel for the relative time differences between integer and floating-point operations on the PIC24 μC, the C code in Listing 7.5 was used to test different operations (addition, multiplication, division) using uint32_t and float data types. Each loop iteration reads values from two arrays, performs an arithmetic operation on those values, and stores the result in a third array.

234

Chapter 7

■

Advanced Assembly Language: Higher Math

Table 7.3: Floating-Point Addition Steps: 1. Detect special numbers in operands and handle these boundary cases. 2. For nonspecial number operands, align the decimal points of the significands of the two operands (make the exponent fields equal) by shifting one of the operands to the left or right as many times as necessary. This process is called denormalization. 3. Add the significands. 4. Normalize the result.

Listing 7.5: Simple C Benchmark for uint32 Versus Float Operations for (u8_i = 0; u8_i < u8_cnt; u8_i++) { *p_c = *p_a + *p_b; // add contents of two arrays p_a++; p_b++;p_c++; }

Table 7.4 gives the instruction cycles per loop iteration of the code in Listing 7.5 for the three different operations tested with uint32_t and float data types. The code was compiled with the MPLAB PIC24 compiler using full optimization and executed in the MPLAB simulator. You may be surprised that float division is actually faster than the uint32_t/uint32_t operation. This occurs because this integer division operation does not map to a division that is supported in hardware by the PIC24 instruction set, and thus is performed by a subroutine. The uint32_t/uint32_t operation produces a 32-bit quotient, which is larger than the division done in the float division operation when the two 23-bit significands are divided (the quotient’s exponent is the divisor’s exponent subtracted from the dividend’s exponent). When the uint32_t/uint32_t operation is changed to a uint16_t/uint16_t operation, the instruction cycles per loop operation drop to 26 because the operation now is able to use the div.u instruction.

Table 7.4: PIC24 uint32_t versus Float C Performance Operation

Addition Multiplication Division

Instruction Cycles Per Loop Iteration uint32_t

float

float/uint32_t Ratio

12 17 462

134 128 358

11.2 7.5 0.77

BCD Arithmetic

235

The message to be gleaned from the numbers in Table 7.4 is that you should be cognizant of the execution time differences between different arithmetic operators of the same data type and between different data types (such as integer versus floating-point) for the same arithmetic operation for a target microcontroller and compiler.

BCD Arithmetic Binary coded decimal (BCD) encodes each digit of a decimal number as its 4-bit binary value. This means that the decimal value 83 is simply 0x83 as an 8-bit BCD number. Thus, an 8-bit BCD number can represent the number range 0 to 99. This is a less efficient coding scheme than binary representation, as the codes 0x9A to 0xFF and 0x?A through 0x?F are unused. Some rotary encoders that track the movement of a rotary shaft as it turns either clockwise or counterclockwise use BCD outputs. Some rotary encoders output incremental codes that only describe the direction of shaft movement; others output absolute position information. If absolute position information is given in BCD, then BCD subtraction must be performed to compute the distance between two absolute positions. Addition must be done to compute a finishing location given a starting location and a distance to travel. Adding the two numbers using binary arithmetic then post-correcting the sum to obtain the BCD value performs BCD addition. A BCD digit is a 4-bit value. When two BCD digits are added using binary addition, if the result digit is greater than 9 or if a carry is produced, the result digit must be decimal adjusted by adding 6 to produce the correct BCD digit. Similarly, when two BCD digits are subtracted using binary subtraction, if the result digit is greater than 9 or if a borrow is produced, the result digit must be decimal adjusted by subtracting 6 to produce the correct digit. The DC (decimal carry) flag in the STATUS register is used for BCD post-correction after addition operations; the DC flag is set if there is a carry from bit 3 to bit 4 during a binary addition. The daw.b Wn (decimal adjust Wn) instruction post-corrects the Wn register contents to the correct BCD value after any addition or increment instruction that affects the C and DC flags. The daw.b instruction operates only in byte mode using register direct addressing, and so the .b extension must be included. The daw.b instruction adds 6 to the lower 4 bits (lower digit) of the Wn register if the DC flag is 1 or if the lower digit is greater than 9; the upper digit is corrected by +6 if the C flag is 1 or if the upper digit is greater than 9. Unfortunately, the daw.b instruction cannot be used after a subtraction operation, so BCD subtraction requires more effort. Recall the binary subtraction A – B is performed as A + ~B + 1, where ~B + 1 is the two’s complement of B. Similarly, the BCD subtraction A – B can be performed as A + (99 – B +1), where 99 – B + 1 is the ten’s complement of B. Figure 7.13(a) shows the 8-bit BCD addition 0x39 + 0x28. After the binary addition, DCflag = 1 and the result is 0x61. Because DCflag = 1, the lower digit must be corrected by adding 6 to reach the correct result of 0x67. Figure 7.13(b) shows the BCD subtraction 0x42 – 0x24 using binary subtraction, which produces the value 0x1E and a borrow from the upper 4 bits. Because there was a borrow from the upper 4 bits, the lower digit must be post-corrected by subtracting 6 to produce the correct result of 0x18. Figure 7.13(c) shows the BCD subtraction 0x42 – 0x24

236

Chapter 7

■

Advanced Assembly Language: Higher Math

performed by adding the ten’s complement, 0x42 + (0x99 – 0x24 + 1). The ten’s complement of 0x24 is computed as 0x99 – 0x24 + 1 = 0x76. Observe that 0x24 + 0x76 = 0x00 in BCD arithmetic, or (+n) + (–n) = 0. The ten’s complement of 0x24 is then added to 0x42, or 0x42 + 0x76 = 0xB8. This sets Cflag = 1, so the upper digit is post-corrected by adding 6, producing the correct result of 0x18. Observe that Figures 7.13(b) and 7.13(c) produce the same result, but the method in Figure 7.13(c) is used on the PIC24 μC as this allows use of the daw.b instruction.

Figure 7.13 BCD addition and subtraction

Figure 7.14(a) shows assembly code for a subroutine named bcd_add8 that performs the 8-bit BCD addition of W0 = W0 + W1. The bcd_add8 subroutine is called using the numbers from Figure 7.13(a). Similarly, Figure 7.14(b) shows assembly code for a subroutine named bcd_sub8 that performs the 8-bit BCD subtraction W0 = W0 - W1 using the ten’s complement approach of Figure 7.13(c). Extended precision BCD arithmetic is done in the same manner as extended precision binary arithmetic using the addc instruction forms. Sample Question: What does 0x56 + 0x29 produce as a BCD sum? Answer: Using binary addition, 0x56 + 0x29 = 0x7F. Post-correcting for BCD produces 0x7F + 0x06 = 0x85. So, as a BCD sum, 0x56 + 0x29 = 0x85.

ASCII Data Conversion

237

Figure 7.14 Assembly code for BCD 8-bit addition and subtraction

ASCII Data Conversion A common task in microprocessor programs is to convert numerical data in ASCII format to binary or vice versa. This functionality is generally provided by formatted IO functions in high-level languages, such as the printf (ASCII output) and scanf (ASCII input) C library functions. While the amount of ASCII data manipulation required in typical microcontroller applications is limited, the need for ASCII numerical manipulation invariably arises and one should have some familiarity with the problem.

Binary to ASCII-Hex Suppose you wanted to see the bytes of a single or double precision floating-point number printed in ASCII format. The code in Figure 7.15 prints the individual bytes of a single precision and double precision floating-point number in ASCII-hex format. The C function byte2aschex() is the key piece of code in this discussion, as it converts a byte value into the ASCII-hex representation of that number. For example, the 8-bit value 0xA3 is converted to the two ASCII values 0x41, 0x33, as these are the ASCII codes for the two hex digits A and 3, respectively. The byte2aschex() function is called for each byte of the single precision and double precision floating-point numbers f and d, respectively. The generic pointer variable pu8_byte is used to iterate over the bytes of the floatingpoint numbers from most significant to least significant, which are assumed to be stored in littleendian order in memory (recall from Chapter 3 that little-endian means that bytes of a multibyte value are stored from least significant to most significant byte in increasing memory addresses).

238

Chapter 7

■

Advanced Assembly Language: Higher Math

The uint8_t au8_buf[2] array is used as temporary storage for the two ASCII characters generated by byte2aschex(). The byte2aschex() function converts each 4-bit portion (a nybble) of the u8_c input parameter by calling the nyb2aschex() function twice; first for the upper 4 bits, then for the lower 4 bits. Each 4-bit portion of u8_c represents one ASCII-hex digit, so an 8-bit number requires two bytes when converted to ASCII-hex. The nyb2aschex() function first tests its 4-bit input and if it is greater or equal to 10, then it is converted to its ASCII equivalent A (0x41) through F (0x46) by adding the value 0x37. If it is less than 10, 0x30 is added to the 4-bit value to produce the appropriate ASCII digit 0 (0x30) through 9 (0x39). The return value from the nyb2aschex() function is stored by the byte2aschex() function into the buffer pointed to by the pu8_s input parameter. In C, an integer can be printed in ASCII-hex format using the %x format in the printf() standard IO library function. An example usage is printf(“u8_c = %x”,u8_c), which prints u8_c = 3A if the binary value of u8_c is 0x3A.

Figure 7.15 C code for ASCII-hex display of floating-point numbers

ASCII Data Conversion

239

Assembly language for the byte2aschex() and nyb2aschex() functions along with a test program is shown in Figure 7.16. The byte2aschex() assembly language implementation uses W0 for u8_c and W1 for the pu8_s pointer to the buffer used for storing the two ASCII-hex digits. The nyb2aschex()assembly language implementation uses W0 as the 4-bit input value to be converted, and returns the equivalent ASCII-hex digit in W0. The test program calls byte2aschex() with 0x9A as the value to be converted in W0, and the starting address of au8_buf in W1. Upon return, the values 0x39 (ASCII 9) and 0x41 (ASCII A) are stored at buffer locations au8_buf[0] and au8_buf[1], respectively.

Figure 7.16 Assembly code implementation of the byte2aschex() function

Binary to ASCII-Decimal Table 7.5 shows the steps necessary to convert a binary number to its unsigned ASCII-decimal representation. The successive division by 10 produces the digits from least significant digit to most significant digit. The C statement printf(“%d”, i) prints the value of the i variable in decimal; the printf() C library function implements the algorithm of Table 7.5 when formatting numbers in ASCII-decimal format.

240

Chapter 7

■

Advanced Assembly Language: Higher Math

Table 7.5: Conversion of a Binary Number to Unsigned ASCII-Decimal Steps (Digits Are Determined Least Significant to Most Significant): 1. If the number is 9 or less, set the quotient to the number and go to step 3; otherwise divide the number by 10. 2. Add 0x30 to the remainder; this is the ASCII-decimal digit. 3. If the quotient is 9 or less, then this is the last non-zero digit, so add 0x30 to the quotient to get the ASCII value of the last digit, and exit. If the quotient is 10 or greater, set the number equal to the quotient and loop back to 1.

ASCII-Hex to Binary The aschex2byte() C function of Figure 7.17 does the reverse of the byte2aschex() C function, in that it converts two ASCII characters representing the hex value of an 8-bit number into the binary value of that number. The main() code of Figure 7.17 passes a uint8_t buffer containing two ASCIIhex digits to the aschex2byte() function and saves the return value in u8_c. The aschex2byte() result is checked using the C formatted input function sscanf() in the statement sscanf(buf, “%x”, &u16_i). The %x format causes the null-terminated string in u8_buf to be scanned for an ASCII-hex value, which is converted to binary and returned in the uint16_t variable u16_i. A failure message is

Figure 7.17 C code for converting ASCII-hex to binary

ASCII Data Conversion

241

printed if the result returned by aschex2byte() does not match the result returned by sscanf(). The aschex2byte() function calls the aschex2nyb() function for each ASCII-hex digit to be converted. The aschex2nyb() function first converts the character to uppercase, which does not change the characters value if it is a 0 – 9 hex digit. Then it compares the ASCII value to 0x3A; if greater than 0x3A, the character must be in the range A (0x41) to F (0x46), so the value 0x37 is subtracted to get the binary value. If the character is less than 0x3A, it must be in the range 0 (0x30) to 9 (0x39), so the value 0x30 is subtracted from the character to obtain the binary value. The resulting 4-bit value from the first call to aschex2nyb() is placed by aschex2byte() in the upper half of the uint8_t variable u8_c. The 4-bit value from the second call to aschex2nyb() is combined with the 4 bits already in the upper half of u8_c by a bitwise OR (|) operation. The resulting u8_c variable is returned as the converted 8-bit binary value. Assembly language implementations of the aschex2byte() and aschex2nyb() functions are seen in Figure 7.18 along with a test program. The assembly language implementations are straightforward conversions of the C functions. The test program calls aschex2byte() with a pointer to a buffer that contains the ASCII-hex digits 9 and A; register W0 contains the value 0x9A on return.

Figure 7.18 Assembly code implementation of the aschex2byte() function

242

Chapter 7

■

Advanced Assembly Language: Higher Math

ASCII-Decimal to Binary Table 7.6 shows the steps necessary to convert an ASCII-decimal number to its binary value. The conversion proceeds from most significant digit to least significant digit, converting each digit d to its binary value, and forming the sum r = r*10 + d where r is the cumulative result. The number range that can be converted is dependent upon the size of r. In C, ASCII-decimal to binary conversion can be accomplished with sscanf() using the %d format. An example is sscanf(buf, “%d”, &i16_i), which converts the first ASCII-decimal string found in buf to binary, and returns the result in i16_i.

Table 7.6: Conversion of an ASCII-Decimal Number to Binary Steps: 1. r = 0. 2. For each digit d in the ASCII-decimal number starting with the most significant digit, perform steps 3 and 4: 3. Convert d to its 4-bit binary value, and let r = r * 10 + d. 4. If d is the last digit, exit and return r as the result; otherwise advance to the next digit and go to step 3.

Summary Multiplication operations in the PIC24 are enhanced by the availability of a 16 x 16 array multiplier, which can be used to implement higher-precision multiplications. Hardware support for division exists in the PIC24 instruction set for 32-bit/16-bit and 16-bit/16-bit operands, and requires a repeat #17 instruction to iteratively produce each bit of the quotient. Saturating arithmetic is a method for dealing with overflow in addition and subtraction by clipping the result to either the maximum or minimum values of the number range in case of overflow or underflow, respectively. Floating-point representation encodes an exponent field in addition to magnitude and sign information, greatly expanding the number range that can be represented, at the cost of extra complexity in performing floating-point calculations. Binary coded decimal (BCD) encodes each decimal digit as a 4-bit value, providing fast conversion from BCD to decimal, and vice versa. Support for BCD arithmetic is present in the PIC24 via the DC flag and the daw.b instruction. Conversion of ASCII numerical data in hex or decimal formats to binary, and vice versa, is required for input/output operations of ASCII numerical data and is usually implemented in the form of formatted IO subroutines.

Review Problems

243

Review Problems For problems 1 through 18, give the affected registers after execution of each instruction. Indicate if overflow occurs for division instructions. Assume the register and memory contents of Table 7.7 at the beginning of each problem. Show the decimal equivalents of the operation that is performed and verify your result. Assume that the divide instructions have a repeat #17 in front of them. Table 7.7: Register Memory Contents Location

Value

Location

Value

W0

0xFFF4

W5

0x0005

W1

0x000A

W6

0xC0FF

W2

0x000C

W7

0x0001

W3

0xFF06

W8

0xE000

W4

0xFFD0

W9

0xFFFF

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

mul.uu W0, W1, W8 mul.ss W0, W1, W8 mul.us W0, W1, W8 mul.su W0, W1, W8 mul.ss W2, W3, W8 mul.us W2, W3, W8 mul.su W2, W3, W8 mul.uu W2, W3, W8 div.u W6, W2 div.s W4, W5 div.u W4, W5 div.s W4, W2 div.ud W8, W4 div.sd W8, W4 div.sd W6, W8 div.ud W8, W6 div.s W6, W9 div.ud W6, W4

244

19. 20. 21. 22. 23. 24. 25. 26. 27.

28. 29. 30.

31. 32. 33. 34. 35.

36. 37. 38.

Chapter 7

■

Advanced Assembly Language: Higher Math

What is the value 0xC4 as a 0.8 unsigned fixed-point number? What is the value 0xC4 as a 4.4 unsigned fixed-point number? What is the value 0xC4 as a 1.7 signed fixed-point number? What is the value 0xC4 as a 3.5 signed fixed-point number? Convert 23.33 to 5.3 unsigned fixed-point number. Convert 0.2325 to 0.8 unsigned fixed-point number. Convert –0.2325 to 1.7 signed fixed-point number. Convert –2.458 to 4.4 signed fixed-point number. Saturating signed addition is defined as saturating to either the maximum positive value or maximum negative value in the case of overflow using two’s complement encoding. What is the result for 0x39 + 0x59 using saturating signed 8-bit addition? What is the result for 0x8F + 0xE0 using saturating signed addition as defined by problem 27? What is the result for 0x8F + 0xE0 using saturating unsigned 8-bit addition? Write a PIC24 instruction sequence that implements signed saturating addition as defined by problem 27 assuming W0 and W1 contain the two 8-bit operands, with the saturated sum returning in W0. What is the value –0.15625 in single precision floating-point format? What is the value –545.6875 in single precision floating-point format? The value 0x42F18000 is a single precision floating-point number; what is its decimal value? The value 0xC6ED6E20 is a single precision floating-point number; what is its decimal value? Write the steps of an algorithm that compares two single precision floating-point numbers a and b. Assume both numbers are normalized before the comparison is done, and that you do not have to handle special numbers. Return 1 if a > b, −1 if a < b, and 0 if a == b. Assume that you have functions named sign(), exp(), and significand() that extracts these fields and returns them as unsigned integer values. Hint: Think about comparing the numbers by comparing the individual sign, exponent, and significand fields. How would you detect overflow in the BCD addition of two 8-bit numbers? What is the ten’s complement of the BCD value 0x58? Implement the algorithm of Table 7.6 in PIC24 assembly language for any ASCII-decimal string up to three digits (0 to 999).

PART III

PIC24 µC Interfacing Using the C Language Chapter 8 System Startup and Parallel Port I/O . . . . . . . . . . . . . . . . . . . . . . . . . . .247

Chapter 9 Interrupts and a First Look at Timers . . . . . . . . . . . . . . . . . . . . . . . . . . .317

Chapter 10 Asynchronous and Synchronous Serial I/O . . . . . . . . . . . . . . . . . . . . . . .371

Chapter 11 Data Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .449

Chapter 12 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .489

Chapter 13 Advanced Hardware Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541

Chapter 14 Operating Systems for Embedded Systems . . . . . . . . . . . . . . . . . . . . . .583

This page intentionally left blank

Chapter 8

System Startup and Parallel Port I/O

T

his chapter introduces the hardware side of the PIC24 μC family by exploring reset behavior and parallel port I/O for a dsPIC33E μC. In addition, the nuances of writing C code for PIC24 μC applications are examined. As noted, the dsPIC33E offers additional features over the PIC24E with little to no cost difference, motivating its use. However, this book focuses on generalpurpose microcontroller usage, rather than digital signal processing; therefore, the term PIC24 will be used to refer to the processor, rather than dsPIC33, to emphasize its general-purpose usage.

Learning Objectives After reading this chapter, you will be able to: ■ Implement a simple PIC24 system that has an in-circuit programming interface, a power supply, a serial interface, and a reset switch. ■ Write C code for the PIC24 μC that implements I/O via pushbutton switches and LEDs using a finite state machine approach. ■ Discuss the different features of the PIC24 parallel ports such as bidirectional capability, weak pull-ups, and open-drain outputs. ■ Describe the factors that affect dynamic power consumption in CMOS circuits. ■ Identify common features of integrated circuit datasheets. ■ Discuss the use of sleep, idle, and doze modes in the PIC24 μC and their effect on power consumption. ■ Describe the operation of the watchdog timer and its interaction with sleep and idle modes. ■ Implement a parallel interface between a PIC24 μC and a liquid crystal display module. 247

248

Chapter 8

■

System Startup and Parallel Port I/O

High-Level Languages versus Assembly Language Previous chapters explored the instruction set of the PIC24 μC and assembly language programming in the context of C programming. This was done so that the linkage from high-level language constructs such as data types, conditional statements, loop structures, subroutines, and signed/unsigned arithmetic to assembly language is clear. This understanding is needed, as most programming of microprocessors and microcontrollers is done in a high-level language such as C, not assembly language; therefore, you must be cognizant of the performance and memory usage repercussions when using features of a high-level language. For example, at this point you would not use floating-point data types for convenience (or out of ignorance), but rather would carefully weigh whether the computations required by your application actually need the large number range available with floating-point representation. You now know that using floating-point data types requires more memory space for variables, more program memory for calculations, and in most cases, more execution time for application code. The same tradeoffs apply when weighing the choice between uint32_t/int32_t and uint8_t/int8_t data types, but not on as dramatic a scale as floating-point versus integer types. Why is most programming of microprocessors and microcontrollers done in a high-level language and not assembly language? One reason is programmer productivity, which is usually measured in the number of debugged code lines produced per day by a programmer. At this point, you know that it generally takes more assembly language statements than C statements to implement the same task, because C statements imply data movement or arithmetic operations that require multiple register transfer operations when mapped to a specific microprocessor architecture. Writing more statements takes more time; hence it generally takes longer to write applications in assembly language than in a high-level language. Another reason is code clarity; code in a higher level language is typically easier to read and understand than assembly language because the fine-grain details of operator implementation are hidden. Another reason is portability; code written in a high-level language is easier to port to another microprocessor than assembly language because it is the compiler’s task to translate the C to the target microprocessor instruction set. This is important, as code is often reused from application to application, and you do not want to lose the time and money invested in creating an application suite if the target microprocessor changes. So, when is assembly language needed? One reason to write in assembly language is to implement special arithmetic functions that are not available in the high-level language of choice, such as implementing saturating integer arithmetic in C. Another reason is to write a performance-critical section of code in assembly language if the compiler cannot be trusted to produce code that meets required performance specifications. Yet another reason might be to use certain features of the processor that can only be accessed by special instructions within the instruction set. All of these reasons require an understanding of assembly language programming. Even when writing in a high-level language, you should be aware of the features of the instruction set and architecture of

High-Level Languages versus Assembly Language

249

the target processor. For example, if the target processor is a 32-bit processor, using 32-bit data types versus 8-bit data types will probably not have much impact on the execution speed of integer operations. The term embedded system is often applied to microcontroller applications because the microcontroller is hidden within the target system, with no visible external interface. A car typically has tens of microcontrollers within it, yet this fact is not apparent to the car owner. What high-level languages are used to program embedded systems? The C++ language is a popular choice for complex applications written for high-performance microprocessors. However, the C programming language is often the language of choice for an embedded system, as C was intentionally designed to provide tight coupling between C statements and assembly language. In addition, most embedded system programs are control-intensive and do not require complex data structures. Thus, the powerful data abstraction capabilities of an object-oriented programming language such as C++ are often not required in embedded system applications. If a compiler is available for a microcontroller, more often than not it will be a C compiler and not a C++ compiler. This does not mean that there are no microcontroller applications programmed in C++, but rather, that C is the more popular choice, especially for lower-performance microcontrollers. Languages such as Java that are compiled to an intermediate form that is then interpreted by a run-time execution engine are not widely used in microcontroller applications because of the performance loss when compared to an application compiled to the microcontroller’s native assembly language. This chapter begins the hardware topic coverage in this book. Over the next seven chapters, the details of the major hardware subsystems of the PIC24 μC are explored and sample applications are discussed. The hardware chapters of this book focus on the PIC24E/dsPIC33E branch of the PIC24 μC family, which provide more performance and functionality than the PIC24H/F/FK or dsPIC33F processors. However, the PIC24 and dsPIC33 variants share the same assembly language instruction set [8] and many of the same hardware modules, so porting C programs between various members of the PIC24/dsPIC33 family is not overly difficult when employing the library that accompanies this book. Most of the C interfacing examples in this book are compatible with both families, and the C library functions that are included with this book use conditional compilation to ensure that the code examples operate with both families. To exercise the features of the PIC24 hardware subsystems, application programs that transfer data between the subsystems and memory, configure subsystems for different operating modes, and check subsystem operation status are presented. These programs are written in C to promote code clarity. It is a difficult enough task to grasp the operational details of a hardware subsystem without the additional problem of struggling with long assembly language programs, where the details of memory transfers and arithmetic operator implementation mask the overall program functionality. The previous coverage of the PIC24 μC instruction set and assembly language programming techniques in the context of the C language has prepared you for moving beyond assembly language when discussing the hardware subsystems of the PIC24 μC. In covering the PIC24 μC hardware subsystems, it is expected that

250

Chapter 8

■

System Startup and Parallel Port I/O

you will refer to the PIC24E/dsPIC33E Family Reference Manual (FRM) datasheets [9-30] or the dsPIC33EP128GP502 datasheet [31] when additional details or clarification are needed. This book does not attempt to duplicate all of the information in the PIC24 datasheets, which is clearly impractical and unnecessary. Instead, this book presents key functionality of each subsystem in the context of application examples. In some cases, detailed descriptions of the registers associated with a subsystem and individual register bits are presented in this book; at other times, you are referred to the appropriate datasheet. The ability to read datasheets and extract key information is a necessary survival skill for any person interfacing microprocessors or microcontrollers to other devices. A section in this chapter is devoted to providing tips on datasheet reading for those readers who are encountering datasheets for the first time.

C Compilation for the PIC24 µC In this book, the C programs for hardware application examples use the MPLAB® XC 16 compiler for the PIC24 from Microchip Technology Inc. From this point onward, this book refers to this compiler as the “PIC24 compiler. In Chapter 2, a compiler is defined as a program that translates statements in a high-level language to assembly language. Figure 8.1 shows a conceptual view of the steps performed in transforming a C program into machine code that can be programmed into the PIC24 μC. The compiler first transforms the C code into unoptimized assembly language, which is done by looking at each C statement individually and implementing it as a sequence of instructions. The optimization stage then looks at groups of assembly language instructions and attempts to reduce the number of instructions by considering data transfer requirements of the entire group. The right side of Figure 8.1 shows an example compiler optimization, in which two C statements are translated into four assembly language instructions when each C statement is considered individually. The optimizer then considers the four assembly language instructions as a group and notes that the W0 register already contains the value of j from the previous operation, so the second mov j,W0 instruction can be removed. This is only a small example, as there are many different types of compiler optimizations that are performed. Typically, code size is reduced and performance improved after optimization. After optimization, an assembler internal to the compiler translates the assembly language to machine code that is then placed within an object code (.o) file. If a program becomes large, it is good programming practice to split the source code among several files, where each file contains functions that are related to each other. This makes the source code easier to maintain and allows a group of programmers to work on the same microcontroller application concurrently. Thus, an application may have several object files; the linker combines these files into a single file that is executed by the microprocessor. In the case of the PIC24 μC, this “executable” file is a .hex file, which contains an ASCII-hex representation of the program memory contents and is downloaded into the program memory of the PIC24 μC.

C Compilation for the PIC24 µC

251

Figure 8.1 The compilation process

Special Function Registers and Bit References A C compiler for a microcontroller must provide access to the special function registers and to individual bits of those registers. In the MPLAB® PIC24 compiler, all special function registers have matching C declarations contained in a header file (.h) that is particular to the target device. For example, a special function register used for parallel port I/O and discussed later in this chapter is named PORTB, whose memory location is 0xE12. In the PIC24 compiler installation directory, a file named C:\Program Files (x86)\Microchip\xc16\v1.20\support\dsPIC33E\h\p33EP128GP502.h is the header file used for the dsPIC33EP128GP502 μC. Within this file is contained the following line that defines the special function register PORTB as an unsigned int (16-bit) data type. extern volatile unsigned int PORTB __attribute__((__sfr__));

252

Chapter 8

■

System Startup and Parallel Port I/O

The __attribute__ keyword is an extension to standard C by the PIC24 compiler that allows variable and function attributes to be defined, allowing for specific actions to be taken by the compiler based on the attribute values. The __attribute__((__sfr__)) annotation specifies that PORTB is a special function register. A separate linker file assigns the location 0xE12 to the PORTB variable. The PORTB variable declaration allows the entire PORTB special function register to be written or read with a single C statement: PORTB = 0x3010;

// Assign PORTB a value.

An individual bit of PORTB can be tested using a bitwise & operation, as was initially done in Chapter 4. The following code fragment executes the if-body if the least significant bit of PORTB is a 1: if (PORTB & 0x0001) { // Execute if-body if LSb of PORTB is 1. }

Because operations on individual bits within special function registers are commonplace, almost all SFRs also have C struct data type definitions that allow convenient access to individual bits and bit fields. For example, within the same header file is a C struct definition named PORTBBITS that defines individual bit names for each of the 16 bits of PORTB: typedef struct tagPORTBBITS { unsigned RB0:1; unsigned RB1:1; unsigned RB2:1; unsigned RB3:1; unsigned RB4:1; unsigned RB5:1; unsigned RB6:1; unsigned RB7:1; unsigned RB8:1; unsigned RB9:1; unsigned RB10:1; unsigned RB11:1; unsigned RB12:1; unsigned RB13:1; unsigned RB14:1; unsigned RB15:1; } PORTBBITS;

The :1 after each struct element name indicates the bit width of the named element. The following line defines a variable named PORTBbits of type PORTBBITS: extern volatile PORTBBITS PORTBbits __attribute__((__sfr__));

C Compilation for the PIC24 µC

253

The PORTBbits variable definition allows individual bits of PORTB to be referred to as PORTBbits.RBn, where n is the bit number. The following code snippet sets bit 5 of PORTB and clears bit 2 of PORTB. PORTBbits.RB5 = 1; PORTBbits.RB2 = 0;

// Set bit 5 of PORTB. // Clear bit 2 of PORTB.

These C statements are mapped by the compiler into assembly language bset and bclr instructions for an efficient implementation. Individual bits can be tested using similar references; the following code fragment executes the if-body if the least significant bit of PORTB is a 1: if (PORTBbits.RB0) { // Execute if-body if LSb of PORTB is 1. }

Likewise, the common use of multi-bit fields in SFRs is supported in C. For example, the OSCCON register contains several fields: typedef struct tagOSCCONBITS { union { struct { unsigned OSWEN:1; unsigned :2; unsigned CF:1; unsigned :1; unsigned LOCK:1; unsigned IOLOCK:1; unsigned CLKLOCK:1; unsigned NOSC:3; unsigned :1; unsigned COSC:3; }; struct { unsigned :8; unsigned NOSC0:1; unsigned NOSC1:1; unsigned NOSC2:1; unsigned :1; unsigned COSC0:1; unsigned COSC1:1; unsigned COSC2:1; }; }; } OSCCONBITS; extern volatile OSCCONBITS OSCCONbits __attribute__((__sfr__));

254

Chapter 8

■

System Startup and Parallel Port I/O

This definition allows access to the entire NOSC bit field composed of three bits using statements such as OSCCONbits.NOSC = 2; or to individual bits by equivalently executing OSCCONbits.NOSC2 = 0; OSCCONbits.NOSC1 = 1; OSCCONbits.NOSC0 = 0;. Finally, the same header file has C macros that provide a shorthand reference for many of the SFR named bits and bit fields that eliminate the need to remember the SFR register name. A C macro in its simplest form allows one or more C statements to be referred to by a single label, which is the macro name. A macro is defined using the #define statement. For the PORTB bits, these macros are: #define _RB0 PORTBbits.RB0 #define _RB1 PORTBbits.RB1 #define _RB2 PORTBbits.RB2 #define _RB3 PORTBbits.RB3 #define _RB4 PORTBbits.RB4 ... etc., other RBn macros not shown....

This allows the previous code snippet that set bit 5 and cleared bit 2 of PORTB to be written as: _RB5 = 1; _RB2 = 0;

// Set bit 5 of PORTB. // Clear bit 2 of PORTB.

Similarly, a bit test of the LSb of PORTB can be written as: if (_RB0) { // Execute if-body if LSb of PORTB is 1. }

Likewise, macros are provided in the header file that access the bit fields: #define #define #define #define #define #define #define #define #define #define #define #define #define

_OSWEN OSCCONbits.OSWEN _CF OSCCONbits.CF _LOCK OSCCONbits.LOCK _IOLOCK OSCCONbits.IOLOCK _CLKLOCK OSCCONbits.CLKLOCK _NOSC OSCCONbits.NOSC _COSC OSCCONbits.COSC _NOSC0 OSCCONbits.NOSC0 _NOSC1 OSCCONbits.NOSC1 _NOSC2 OSCCONbits.NOSC2 _COSC0 OSCCONbits.COSC0 _COSC1 OSCCONbits.COSC1 _COSC2 OSCCONbits.COSC2

Therefore, the value of the bit field NOSC can be in one statement as _NOSC = 2; or by setting each bit of the field by using _NOSC2 = 0; _NOSC1 = 1; and_NOSC0 = 0;.

C Compilation for the PIC24 µC

255

The macro definitions for named bits and bit fields are only defined for unique bit names; they are not defined if the same bit name is used in more than one special function register. This book uses the macro definition for named bits wherever possible because this means that only the bit name has to be remembered, and not the special function register name.

PIC24 Compiler Run-Time Code, Variable Qualifiers/Attributes Run-time code is code generated by the compiler and executed by the processor before the main() function is entered. The run-time code produced by the PIC24 compiler performs the following steps: ■

■

■

■

Initializes the stack pointer and stack limit registers. The default actions maximize the amount of available stack space. Initializes all global variables; if an initial value is not specified for a global variable, then it is cleared. Initializes the PSV register so that constant data placed in program memory can be accessed. Calls main(); if the main() function returns then the processor is reset by executing the reset instruction. It should be noted that returning from the main() function is rarely done in embedded applications; the examples later in this chapter never return from main().

Some attributes and variable qualifiers used in the example C programs in the hardware chapters are the const qualifier and the persistent attribute. The const qualifier for a variable indicates that the program does not change the variable from its initial contents. The default action of the compiler is to place all const variables in program memory to reduce RAM usage. The const qualifier is typically used with constant strings and arrays, such as shown here: const uint8_t sz_hellomsg[] = “Hello World!”; const uint8_t au8_table[] = {0x23, 0xA0, 0x7F, 0x39};

The persistent attribute, when applied to a variable, causes the variable to be uninitialized by the run-time code. This allows the variable to track values between processor resets; one usage of persistent variables is for communicating error status after a reset. The persistent attribute applied to a variable is shown here: uint8_t u8_resetCount __attribute__((persistent));

You will use a macro form of this named _PERSISTENT, defined by the processor-specific header file (such as p33EP128GP502.h), as follows: uint8_t _PERSISTENT u8_resetCount;

256

Chapter 8

■

System Startup and Parallel Port I/O

C Macros, Inline Functions The example C programs in the hardware chapters make extensive use of C macros as a method of improving code clarity. An all-uppercase naming convention is used for macros in these programs. These are defined in various header files, either written by the authors or provided with the PIC24 compiler. So, when you see a C statement such as: CONFIG_RB11_AS_DIG_OUTPUT();

be aware that CONFIG_RB11_AS_DIG_OUTPUT() is a C macro function whose definition is found in one of the included header files. The first time that a particular macro type is used in an example program, I explain the macro’s functionality and show the C statements that the C macro represents.

Conditional Compilation Conditional compilation allows C statements to be either processed or ignored based on a macro definition or macro value. For example, different include files are used depending on processor type: #if defined(__dsPIC33EP128GP502__) #include #endif #if defined(__dsPIC33EP128GP504__) #include #endif #if defined(__dsPIC33EP128GP506__) #include #endif ... other code omitted ...

The chained if/elif conditional statements (if/else if) include file p33EP128GP502.h if macro __dsPIC33EP128GP502__ is defined, while file p33EP128GP504.h is included if macro __dsPIC33EP128GP504__ is defined, and so on. The macros __dsPIC33EP128GP502__, __dsPIC33EP128GP504__, and so on, are defined by the compiler based on the μC device setting in MPLAB®, which allows device-specific C code to be generated. The #ifdef statement can be used instead of defined(), so the following: #ifdef __dsPIC33EP128GP502__ #include #endif

C Compilation for the PIC24 µC

257

is equivalent to: #if defined(__dsPIC33EP128GP502__) #include #endif

The #ifndef macroname and #if !defined(macroname) tests can be used to detect if a macro is not defined. The macros __dsPIC33E__, __PIC24E__, and so on, are also defined by the compiler for conditional compilation based on processor family such as: #if defined(__dsPIC33E__) || defined(__PIC24E__) case 6: outString(“Fast RC Osc/16\n”); break; case 7: outString(“Fast RC Osc/N\n”); break; #elif defined(__PIC24F__) case 7 : outString(“Fast RC Osc with Postscale”); break; #else #error Unknown processor #endif

A macro’s value can also be used for controlling conditional compilation, as shown in the following code snippet: #if (NUM_UARTS >= 2) case 2 : __C30_UART = 2; // This is the default UART. configUART2(u32_baudRate); break; #endif

The #if (NUM_UARTS >= 2) test includes the code that follows only if the value of NUM_UARTS is greater than or equal to 2. Macros are defined and assigned values within a source file as follows: #define NUM_UARTS (2) #define UART1_TX_INTERRUPT

// NUM_UARTS = 2 // UART1_TX_INTERRUPT macro defined, no value.

When defining a macro, be sure to surround its definition with parentheses, to avoid a number of subtle problem: use #define NUM_UARTS (2), not #define NUM_UARTS 2. Macros can also be passed to the compiler by the -D flag, as in -DNUM_UARTS=(2) and -DUART1_TX_INTERRUPT. Macros can also be defined and assigned values within an MPLAB® project file, which are then passed to the compiler using the -D flag. More information on the MPLAB® PIC24 compiler operation can be found in the MPLAB® XC16 C Compiler User’s Guide [32], found in the docs/ subdirectory of the PIC24 compiler installation directory.

258

Chapter 8

■

System Startup and Parallel Port I/O

PIC24 Startup Schematic The version of the PIC24 μC used in most of the interfacing examples in this book is the dsPIC33EP128GP502 μC, whose pin diagram is given in Figure 8.2. This device has 128 Ki bytes of program memory, 32 Ki bytes of SRAM, and is suitable for experimentation on a protoboard given its small footprint of 28 pins provided in a dual in-line package (DIP). An external pin usually has more than one internal function mapped to it because of the limited number of pins on the 28-pin package. Control bits within special function registers determine the mapping of internal functions to external pins. For additional hardware platforms and options, see the getting started guide on the companion website (www.reesemicro.com).

Figure 8.2 dsPIC33EP128GP502 pin diagram Source: Figure redrawn by author from dsPIC33EP128GP502 datasheet (DS70000657H), Microchip Technology Inc.

A brief summary of many of the pin functions used in this book is given here; more details are provided in the appropriate chapter covering that functionality.

PIC24 Startup Schematic

■

■

■ ■

■

■

■

■ ■

■

■

■ ■

259

VDD,VSS: These are power (VDD) and ground (VSS) pins; observe that there is more than one ground pin. Integrated circuits typically have multiple power and ground pins, all of which must be connected. AVDD, AVSS: These are power (AVDD) and ground (AVSS) pins for the analog modules, which are discussed in Chapter 11. Even if the analog modules are not used, these must be connected to power and ground for the PIC24 to operate correctly. VCAP/VDDCORE: The internal voltage used by the microcontroller is available on this pin. MCLR#: This input pin resets the device when brought low. The # symbol in the name indicates a low-true signal. PGEC1/PGED1, PGEC2/PGED2, PGEC3/PGED3: Any of the PGECx/PEGDx pin pairs can be used for In-Circuit Serial Programming (ICSP), which is the process of downloading a program into the device using an external programmer without removing the device from the board. OSCI, OSCO: These pins can be used with an external crystal to provide the main clock source for the device (details in this chapter). CLKI, CLKO: An external clock can be provided via the CLKI input pin, while the internal clock can be monitored via the CLKO output pin. RAn, RBn: These pins are parallel port I/O pins (details in this chapter). ANn, VREF–, VREF+: The ANn inputs are the analog inputs for the analog-to-digital converter subsystem (Chapter 11). The VREF–/ VREF+ pins are used to provide negative and positive voltage references for the analog-to-digital converter. ASCL1/ASDA1, SCL1/SDA1: These pin pairs implement the I2C synchronous serial data interface (details in Chapter 10). RPn/RPIn: These are remappable peripheral pins that allow internal pin functions to be connected in a flexible manner to external I/O pin (details in Chapters 9 and 10). INT0: This is an external interrupt pin (details in Chapter 9). T1CK: This input can be used to provide a clock for Timer1 (details in Chapter 12).

A schematic used to test PIC24 functionality by flashing a light emitting diode (LED) is shown in Figure 8.3. The schematic functionality can be split into power, reset, serial communication, in-circuit serial programming, and application components. If you are somewhat rusty at recognizing electrical symbols, review the material in Appendix B that provides a hobbyist-level review of basic circuit theory. You only need a hobbyist-level intuition about basic circuit concepts for the interfacing topics in this book; a detailed circuit analysis background is not required.

260

Chapter 8

■

System Startup and Parallel Port I/O

Figure 8.3 PIC24 startup schematic for flashing an LED

Startup Schematic: Power The PIC24 requires that the input voltage VDD be in the range 3.0 V to 3.6 V. An external AC-toDC wall transformer (or 9 V battery) provides power that outputs 9 V unregulated, which means that the output voltage can fluctuate depending on the amount of current that is drawn. An LM2937-3.3 voltage regulator is used to provide a stable 3.3 V output as the VDD for this system (see www.reesemicro.com for a complete list of the components used in the interfacing examples of this book as well as a picture of a completed protoboard layout). The LM2937 accepts a wide input voltage (4.75 V to 26 V); 9 V is used for example purposes. The 3.3 V voltage on the PIC24 VDD pin is connected to a voltage regulator internal to the PIC24 μC that provides a digital core voltage of 1.8 V. The fuse in the power path is a safety precaution; it will blow (no longer conduct current) if excessive current is drawn from the power supply. Excessive current can be drawn if a short (a low-resistance path) is created between VDD and VSS by a wiring mistake during circuit hookup or by component failure.

PIC24 Startup Schematic

261

The total current required for this PIC24 μC system after all peripheral chips have been added is under 100 mA (1 mA = milliAmperes = 0.001 A). A 500 mA wall transformer provides a margin for hardware experiments that use higher current draw devices, such as a DC motor for driving the wheel of a small robot. The C1 capacitor is required by the LM2937 for output voltage stability with a minimum suggested value of 10 μF and maximum ESR (equivalent series resistance) of 5 Ω. The 0.1 μF C2, C4, and C5 and 10 μF C3 capacitors are called decoupling capacitors and assist in supplying transient current needs caused by high-frequency digital switching. These capacitors should be placed as close as possible to their respective power and ground pins (VDD, VCAP, AVDD, VSS, and AVSS) for maximum effectiveness. All four capacitors need to have low ESR, such as provided by low ESR tantalum and ceramic capacitors, with ceramic capacitors having lower ESR than tantalums at equivalent capacitor values. The C3 capacitor is especially critical as it helps maintain the stability of the PIC’s internal voltage regulator; the PIC24 datasheet recommends an ESR of less than 1 Ω. The L1 LED is used in two roles—the first is as a power status since the LED is on when power is applied. The second role is as an LED that can be blinked by the PIC24 via the connection from port RB15 to the LED, as shown in Figure 8.3. Because the power supply and RB15 are both driving the LED, the RB15 port is configured as an open-drain output, which means that it can be driven in two states: (a) low, pulling the LED to ground and turning it off, or (b) high impedance (floating, no drive current supplied), which turns on the LED if power is applied. Open-drain outputs are discussed in more detail later in this chapter; open-drain mode is used in this case to reduce component count and wiring (another LED and series resistor could have been used on R15 instead of sharing the power LED). To determine the resistance value of R1, note that when RB15 is pulling low (turning off L1), current flows from VDD through the resistor and into RB15. The DC specifications in the dsPIC33EP128GP502 datasheet [31] state that the RB15 pin can sink a maximum of 5 mA over its full temperature range. Solving Ohm’s law (V=IR) for resistance gives R=V/I, with the minimum resistance allowed computed as 3.3 V/5 mA = 660 Ω. The value 910 Ω provides a safety margin and is compatible with the older PIC24H family, which is limited to a maximum of 4 mA of sink current. The current flowing through the LED for RB15 in the high impedance (floating) state is (VDD − LED_Vdrop)/R1, where LED_Vdrop is the voltage drop across the LED. The LED voltage drop can be found on its datasheet for a range of currents, with a typical value of 2 V. Thus, the ON current supplied to the LED by the power supply is (3.3 − 2.0)V/ 910 Ω = 1.4 mA, which is enough to illuminate a typical LED.

Startup Schematic: Reset When power is applied to the PIC24, the device performs a power-on reset (POR), which means that the program counter is cleared to 0 and the first instruction is fetched from location 0. This is an internally generated power-on reset sequence; some microcontrollers require an external reset circuit that asserts an input pin either high or low to trigger reset after power is applied. It is also

262

Chapter 8

■

System Startup and Parallel Port I/O

convenient to have a manual reset capability during testing to restart a program without needing to cycle power. The momentary pushbutton connected to the MCLR# input applies a low voltage to MCLR# when pushed, causing the PIC24 μC to reset. The 10 kΩ (R3) resistor that connects the MCLR# pin to VDD is called a pull-up resistor, because it keeps the MCLR# input pulled up to almost 3.3 V when the pushbutton is released. If the pull-up resistor is removed, and a direct connection is made from MCLR# to VDD, a short is created when the pushbutton is pressed, causing excessive current flow and probably causing the fuse to blow. If the pull-up resistor and VDD connection is not made at all, the input varies, or floats between 0 V and VDD when the pushbutton is not pressed. A floating input can read as 0 or 1, depending on the switching activity of nearby pins, causing spurious circuit operation. A PIC24 μC with a floating MCLR# input can experience intermittent resets, a problem that is difficult to debug.

Startup Schematic: PC Serial Communication Link The example programs use functions that read or send ASCII-encoded strings to a personal computer (PC) using a serial interface known as RS232 (more details about this protocol are covered in Chapter 10). The ASCII-encoded strings exchanged between the PIC24 μC and PC are used for status and debugging messages and for data entry. A serial interface transmits data one bit at a time; Chapter 10 discusses the various serial interfaces implemented by the PIC24 μC. The J2 6-pin header represents a USB-to-RS232-serial cable from FTDI (Future Technology Devices International Limited) that is used to connect the PIC24 μC to the USB (universal serial bus) port of a PC. The FDTI TTL-232R-3.3 USB-to-TTL-serial cable referenced in Figure 8.3 is convenient in that the cable’s TXD (transmit data) and RXD (receive data) pins can be connected directly to the PIC24 μC without any additional circuitry because these pins use 0 to 3.3 V logic levels (other USB-to-serial cables may require an integrated circuit that converts from RS232 logic levels to CMOS levels; see Chapter 10 for more details). The TXD pin on the TTL-232R-3.3 cable transmits serial data from the PC to the PIC24 μC, while the RXD pin implements communication in the reverse direction from the PIC24 μC to the PC. The example programs use the RB10/RB11 pins on the PIC24 μC for the RX/TX functions required by the serial interface. The GND pin (1) on the FDTI TTL-232R-3.3 cable must be connected to the GND of the PIC24 μC. The 5 V power pin (3) of the FDTI TTL-232R-3.3 cable can be used as an alternative power supply for the LM2937-3.3 voltage regulator, but you must be careful not to exceed the maximum current limit of 500 mA allowed to a USB device.

Startup Schematic: In-Circuit Serial Programming The J1 6-pin header and their connections are optional; these are used for in-circuit serial programming of the PIC24 μC using an external programmer such as the inexpensive PICkit3 programmer available from Microchip (see the ICSP programmers section at http://www.reesemicro.com/Home/ pic24-software-library-collection/getting-started). The PICkit3 external programmer applies a clock (PGEC1), a serial data stream (PGED1), and an MCLR# signal when downloading a hex file into

ledflash.c—The First C Program for PIC24 Startup

263

program memory. The advantage of in-circuit serial programming is that the PIC24 μC does not have to be removed from the board during programming. Any of the PGECn/PGEDn input pairs can be used for the ICSP operation.

Startup Schematic: Application Components The power, reset, serial communication, and in-circuit programming components of the startup schematic will remain unchanged through most of the interfacing examples in the remaining chapters. Each interfacing example will typically add components for the particular application. The first application program flashes the L1 LED, which is a common method for proclaiming that “I am alive!” when testing a microcontroller system for the first time. See the getting started guide of the companion website (www.reesemicro.com/Home/pic24-software-library-collection/getting-started) for instruction on transferring a program, such as ledflash.c, to your PIC24 μC.

ledflash.c—The First C Program for PIC24 Startup The C code of Figure 8.4 flashes the L1 LED connected to pin RB15 in Figure 8.3. The source code for this program is contained in chap08\ledflash_nomacros.c, freely downloadable from the PIC24 library at www.reesemicro.com, as indicated by the title in Figure 8.4. All following figures likewise give the path to the source code under discussion. The statement #include “pic24_all.h” includes a standard header file used in this book’s examples; the header file’s contents are discussed later in this chapter. Figure 8.4 is the first C code listing for PIC24 μC hardware experiments presented in this book. Because of space considerations, the C source code given in the figures is typically not complete— the figure source code will usually omit C functions previously covered or omit include statements for various header files. All of the C source code files used in book figures that illustrate PIC24 μC hardware features are included on the companion website (www.reesemicro.com) in their complete form; use these source files when attempting to duplicate the experiments.

Clock Configuration The first statement of main() is a call to the function configClock() that configures the PIC24 clock source. The configClock() function is located in the file lib\src\pic24_clockfreq.c in the source file distribution for this book. The PIC24 family has several methods for clock generation, which are mentioned later in this chapter; the default method used by the examples in this book is the internal oscillator option configured for the maximum clock frequency of 120 MHz (FOSC). From Chapter 3, recall that if FOSC = 120 MHZ, then the instruction cycle time FCY is FCY = FOSC/2 = 60 MHz. Using the internal oscillator has the advantage of less wiring for the startup schematic since a clock source does not have to be provided; the clock is generated internally by the PIC24 μC.

264

Chapter 8

■

System Startup and Parallel Port I/O

Figure 8.4 chap08\ledflash_nomacros.c: C code for flashing an LED

Flashing the LED Pin RB15 is a bidirectional, parallel port pin, also referred to as a parallel input/output (PIO) pin. The term bidirectional means that the pin can be configured either as an input or as an output. The RB15 pin must be configured as an output to drive the LED, which is accomplished by the statement _TRISB15 = 0. Each bit of the special function register TRISB controls the direction of the corresponding PORTB bit. A 1 in a TRISB bit configures the corresponding PORTB pin as an input (as a memory hint, 1 looks like I for input), while a 0 configures the PORTB pin as an output (0 looks like O for output). Furthermore, the output drive type is open-drain because you are sharing the L1 LED with the power status as stated earlier, and configuration for open-drain operation is accomplished by the statement _ODCB15 = 1. Additional details on parallel port I/O are given later in this chapter. The statement _LATB15 = 0 assigns a zero to the RB15 data latch, thus driving the RB15 pin low and turning off the LED. The statement while (1) creates an infinite loop, whose loop body first calls a software time delay function named a_delay(), then toggles the value of the RB15 output with the statement _LATB15 = !_LATB15. The software delay function a_delay() is composed of two nested for

ledflash.c—The First C Program for PIC24 Startup

265

counting loops. The total delay time is dependent upon the number of instructions executed in the nested for loops and the clock frequency of the PIC24 μC. The delay can be increased or decreased by changing the initial values of the count variables u16_i, u16_k in the nested for loops of the a_delay() function. The delay must be long enough so that the LED can fully turn off or turn on between RB15 pin assignments. If the delay is too short, the LED will appear always on (though dim), even though an oscilloscope trace would reveal that RB15 is transitioning between low and high voltages (a square wave output). Software delays are easy to implement, but hardware timers are much better at creating accurate time delays. The timer subsystem of the PIC24 μC and its usage is first discussed in Chapter 9, and covered in more detail in Chapter 12. Observe that the only method of terminating the while (1) loop in Figure 8.4 is by cycling power or reset via the pushbutton on MCLR#. This infinite loop nature is typical of microcontroller applications because if the loop is exited, there is nowhere to go!

An Improved LED Flash Program Figure 8.5 shows an alternative version of the LED flash code that uses C macros for improving code clarity and for encapsulating I/O pin assignments.

Figure 8.5 chap08\ledflash.c: Improved code example for flashing an LED

The config_led1() function replaces the original statements _TRISB15 = 0, _ODCB15 = 1 that configured RB15 as an open-drain output. The reason for this change is to improve code clarity; an external reader can guess from the function name that this configures an I/O pin used for driving an

266

Chapter 8

■

System Startup and Parallel Port I/O

LED in the program. The config_led1() function definition simply uses two other macros named CONFIG_RB15_AS_DIG_OUTPUT() and ENABLE_RB15_OPENDRAIN() that contain the statements _TRISB15 = 0, _ODCB15 = 1. Again, the purpose of these macros is for improved readability; remembering that _TRISB15 = 0 configures the RB15 pin as an output and not as an input can be difficult. However, the macro name CONFIG_RB15_AS_DIG_OUTPUT() is more helpful as to what this macro accomplishes (the DIG is shorthand for digital). All uses of _LATB15 in the code of Figure 8.4 are now replaced by LED1, which is a macro defined as _LATB15. Note that _LATB15 is wrapped in parentheses, to avoid unwanted side-effects caused by macro substitution—for example, #define A_PLUS_B a+b when used in A_PLUS_B*2 evaluates as a + (b*2), not the expected (a + b)*2. Many other subtle problems exist that parentheses help eliminate. All macros should be wrapped in parentheses to avoid these problems. This improves code clarity as now it is clear when the LED is affected by the code, instead of having to remember that RB15 drives the LED. Furthermore, if you want to move the LED to a different pin, you only have to change the LED1 and CONFIG_LED1 macros. This is the greatest benefit of using macros to isolate pin assignments as it is a common desire to want to reuse sample interfacing code with different pin assignments. Finally, the a_delay() software delay function call is replaced by DELAY_MS(250) where the macro DELAY_MS(ms) implements a delay of approximately ms milliseconds. The DELAY_MS macro is defined in the lib\include\pic24_delay.h file in the book source distribution, and is shown here. #define DELAY_MS(ms) \ delayAndUpdateHeartbeatCount(CYCLES_PER_MS * ((uint32_t) (ms)));

The delayAndUpdateHeartbeatCount(uint32_t u32_cyc) function called by DELAY_MS is also defined in lib\include\pic24_delay.h as: inline static void delayAndUpdateHeartbeatCount(uint32_t u32_cyc) { __delay32(u32_cyc); u32_heartbeatCount += (u32_cyc >> 4); }

It delays u32_cyc instruction cycles by calling the __delay32(uint32_t u32_cyc) function provided by the PIC24 compiler support library. The u32_cyc variable passed to delayAndUpdateHeartbeatCount is the number of instruction cycles that execute in ms milliseconds. The CYCLES_PER_MS macro is the number of instructions cycles that execute in one millisecond, and is defined in lib\include\ pic24_clockfreq.h as: #define CYCLES_PER_MS ((uint32)(FCY * 0.001))

The FCY macro is set to the instruction cycle frequency. When using the default clock configuration discussed later in this chapter (see “Clock Generation”), its value is defined in lib\include\pic24_ clockfreq.h to be 59881250L (~60 MHz). Note the trailing L makes the number a long (equivalent to a uint32_t), causing the compiler to allocate a 32-bit value in which to store the number.

echo.c—Testing the Serial Link

267

For example, with FCY = 60 MHz, 1 ms = 60,000 instruction cycles. The u32_heartbeatCount variable updated in the delayAndUpdateHeartbeatCount() function is discussed in the next section. The lib\include\ pic24_delay.h file also includes a DELAY_US(us) macro that delays us number of microseconds. The DELAY_MS() and DELAY_US() macros should only be used for approximate timing; the hardware timers covered in Chapter 12 provide more accurate timing.

echo.c—Testing the Serial Link The subsystem of the PIC24 μC that performs serial communication over the RX/TX pins shown in the startup schematic of Figure 8.3 is called the UART (universal asynchronous receiver transmitter). The UART subsystem is covered in detail in Chapter 10; this section discusses from a user-level perspective some of the functions for receiving/transmitting ASCII data over the serial link. The internals of these functions are discussed in Chapter 10. The C code of Figure 8.6 tests the serial link by printing some status messages, then enters an infinite while (1) loop that waits for a single character to be received from the serial link using the inChar() function. The received character is placed in the u8_c variable, incremented, then written back to the serial link using the outChar() function. This means a received character of S is echoed as T, a 1 as 2, a d as e, and so on. The received character is incremented to verify that the PIC24 μC is actually reading and transmitting the character; if the character were transmitted back without modification then a short circuit between the RX and TX lines could mimic this behavior. Both the inChar() and outChar() functions are defined in lib\src\pic24_serial.c.

Figure 8.6 chap08\echo.c: Program for testing the serial link

268

Chapter 8

■

System Startup and Parallel Port I/O

The code of Figure 8.6 has some new functions that are executed before the while (1) loop is reached. These functions are: ■

■

■

■

configHeartbeat(): When debugging a μC system, a basic question that often arises is

“How do I know if the μC is alive and executing code?” The example programs reserve the RB15 pin for a heartbeat that is used to blink an attached LED. In any of the functions that perform a potentially long wait, such as inChar() that waits for arrival of a character over the serial link, the code will pulse the LED attached to the RB15 pin to indicate that the μC is alive. The heartbeat update is performed by an associated function called doHeartbeart() that is called from a user function to increment a uint32_t global variable named u32_heartbeatCount. Once the u32_heartbeatCount variable reaches a maximum value set within configHeartBeat(), the heartbeat LED is toggled and the u32_heartbeatCount is reset to 0. The heartbeat functions are found in lib\src\pic24_util.c. It should be noted that the heartbeat LED functions as a debugging tool and would not be typically included in a production design. configDefaultUART(uint32_t u32_baudRate): This function configures the UART subsystem to transmit serial data at the rate specified by the u32_baudRate parameter. There is a range of standard data rates for this type of serial link; these are defined in Chapter 10. The data rate defined by the DEFAULT_BAUDRATE macro is 230,400, which means that bits are sent at roughly 230,400 bits per second. This function is defined in lib\src\pic24_serial.c. printResetCause(): The function prints an information string about the cause of the last processor reset. A section later in this chapter discusses the various sources of CPU reset. The function also identifies the target processor, its revision number, and the clock option currently being used. This function is defined in lib\src\pic24_util.c. outString(const char* psz_s): This function transmits each character of null-terminated string over the serial link. The function assumes an ASCII-encoded string is being transmitted. The HELLO_MSG is a macro defined in lib\include\pic24_uart.h with a default value of the file name and build date of the program being compiled (in this case, echo.c).

To test the serial link, the bootloader included in the library distribution accompanying this book (see www.reesemicro.com) is run on the PC to display the received characters from the PIC24 μC and to transmit keyboard input back. Other options include RealTerm, PuTTY, and Tera Term. Follow instructions in the getting started guide at www.reesemicro.com to program and communicate with your PIC24. Figure 8.7 shows the echo.c program output in the RealTerm console window. The printResetCause() function identifies the reset cause as “Power-on” when power is applied, and then as “MCLR assertion” when the Reset button is pushed at (d). The displayed characters echoed in (c) and (e) are 1+ the ASCII values of the characters typed from the keyboard.

echo.c—Testing the Serial Link

269

Figure 8.7 Output from echo.c

asm_echo.s—Implementing Echo in Assembly The assembly language skills you learned in the previous chapters can also be used to write assembly-language programs that make use of the C functions previously discussed, as shown in Figure 8.8. This assembly code implements the echo.c code of Figure 8.6. This code calls a new C function named configBasic(const char* sz_helloMsg), defined in lib\src\pic24_util.c. This function combines the individual configuration calls used in echo.c, such as configClock(), configHeartbeat(), and so on, into one convenient function. The sz_helloMsg parameter is a message printed to the console after configuration is complete. Note that all C functions have an appended underscore when referenced from assembly, so the C function configBasic becomes _configBasic in the assembly code, inChar becomes _inChar, and outChar becomes _outChar. As in earlier assembly-language programs, the first line begins by including processor-specific headers given in xc.inc. To define a string, the .section psv psv directive instructs the assembler to place following statements in the Program Space Visibility region where C stores and accesses constants. The .asciz directive then places the “asm_echo.s ready!\n” string in the PSV area. After switching to the code section with a .text directive, the .global _main statement makes the _main label visible outside this file, so that the C start-up routines can call it after initializing C variables. Next, the mov #HELLO_MSG, W0 statement places the address of the hello message in W0, the first parameter expected by the configBasic function. The statement call _configBasic calls this function, which performs basic chip configuration as previously discussed. Next, the inChar() C function is called, which reads a character from the serial port and returns it in W0. The returned character is then incremented and sent back over the serial port by a call to outChar. Finally, a bra while_top statement loops back to the inChar() function call to repeat the process.

270

Chapter 8

■

System Startup and Parallel Port I/O

Figure 8.8 chap08\asm_echo.s: Assembly-language program for testing the serial link

Datasheet Reading—A Critical Skill You will see the phrase “Topic x is discussed in more detail in the PIC24 datasheet [ref. N]” several times in this book. It is impractical for this book to replicate all PIC24 datasheet information, as the device-specific datasheet combined with the PIC24 Family Reference Manual (FRM) is over 1,000 pages long! As such, you must become comfortable with reading PIC24 datasheets and the datasheets of other devices referenced in this book, to gain full understanding of the interfacing examples. For a microcontroller, the component datasheet such as [31] contains information specific to the features of that particular processor, but may only contain summaries if this information is common to many members of a microprocessor family. Expanded descriptions of features common to all microprocessor family members, such as the instruction set [8] or hardware subsystems [9-30], are contained in reference manuals for that family. Application notes are more varied in form—some discuss how to best use the microcontroller for a particular application, while others may give several examples of how to use a particular subsystem.

Datasheet Reading—A Critical Skill

271

The information detail in a component datasheet may initially seem overwhelming, but this can be countered by knowing how typical datasheets are organized and where to look for certain types of information. A typical component datasheet is organized as follows: ■

■

■

Initial summary and pinouts: The first section contains a device functional summary, which includes pin diagrams and individual pin descriptions. Functional description: Individual sections discuss the functional details of the device operation. In the dsPIC33EP128GP502 component datasheet, these sections correspond to the subsystems of the PIC24 μC such as the timers, the analog-to-digital converter, and so on. However, the component datasheet only contains a summary of the subsystem’s operation; a full description of the subsystem’s functionality is found in the appropriate chapter of the PIC24 Family Reference Manual (FRM) [9-30]. In the FRM, step-by-step instructions for subsystem configuration and usage are provided, with a detailed explanation of the special function registers used by the subsystem and the individual bit definitions of these SFRs. Electrical characteristics: Electrical characteristics are only found in a component datasheet and are divided into DC specifications (operating voltage, power consumption, output port drive capability, and so on) and AC specifications (timing characteristics such as propagation delay, maximum clock frequency, and so on). This section contains tables of values with minimum, typical, and maximum values; the typical values are used in this book whenever timing information is given. The electrical characteristics section always contains a table labeled as “Absolute Maximum Ratings,” which are the maximum voltage/current values that can be experienced without damaging the device. These are not the typical operating voltage/current ratings of the device. For example, for the dsPIC33EP128GP502 the maximum voltage rating of the VDD pin is –0.3 V to +4.0 V. However, the actual operating range for the VDD pin is 3.0 V to 3.6 V.

Datasheets, reference manuals, and application notes assume you have a general familiarity and previous background with similar components. Books such as this one are useful for readers who are new to these devices, or for experienced readers who are looking for a single source that combines and summarizes information from datasheets, application notes, and reference manuals. The ability to read a datasheet is a critical skill for any practicing engineer, engineering student, or hobbyist, and skills are obtained only through practice. So, take the time to peruse the PIC24 datasheets and the datasheets of other devices used in the hardware examples when working through the remaining chapters.

272

Chapter 8

■

System Startup and Parallel Port I/O

Configuration Bits Configuration bits [27] are located in device configuration registers that are mapped to locations in program memory. This means that configuration bits are nonvolatile, allowing them to retain configuration information when power is removed. Configuration bits are read on power-on and specify aspects of processor behavior such as oscillator configuration, watchdog timer behavior, power-on reset timer value, and so on. The device configuration registers for the PIC24E family are: ■

■

■

■ ■

FGS: This register specifies different protection and security modes for program memory and is not discussed in this book; see [25] for more details. FOSCSEL, FOSC: These registers specify oscillator configuration and are discussed later in this section. FWDT: This register controls watchdog timer (WDT) configuration and is discussed later in this section. FPOR: This register controls power-on reset behavior and is discussed later in this section. FICD: This register contains the debugger configuration word, which instructs the chip to start normally on a reset or to enter a debug mode.

The configuration bit settings for all of the book’s example projects are located in lib\src\pic24_ configbits.c. Configuration bit settings can be specified using a GUI-driven tool in MPLAB® X, accessible via the main menu from Window > PIC Memory View > Configuration bits, as shown in Figure 8.9. The settings chosen can then be output as C code using the Generate Source Code pushbutton.

Figure 8.9 Configuration bits GUI

Here’s a snippet of the source code produced by generating code: // FPOR #pragma config ALTI2C1 = ON #pragma config ALTI2C2 = OFF

// Alternate I2C1 pins (I2C1 mapped to // ASDA1/ASCL1 pins) // Alternate I2C2 pins (I2C2 mapped to SDA2/SCL2 // pins)

Clock Generation

273

The #pragma statement provides a mechanism for introducing compiler-specific information, which is the configuration bit settings. Here, ALTI2C1 specifies which pins (SDA1/SCL1 or ASDA1/ASCL1) the I2C serial interface is mapped to (Chapter 10 discusses the I2C serial interface); in the previous example, they are mapped to the ASDS1/ASCL1 pins. Similar logic applies to the ALTI2C2. When puzzled about a configuration bit setting, consult the additional information provided in the configuration bit description in [27]. A complete list of the configuration bits and their functions is also found within [27]. Other members of the PIC24/dsPIC33 family have many of the same configuration bit capabilities as the dsPIC33E family, but the configuration register names and bit locations differ.

Clock Generation The PIC24 family supports a wide array of clocking options [15]; this datasheet provides a complete reference. To summarize the most common options, the processor can be operated from: ■

■

■

An internal clock source, named the fast RC oscillator (FRC), provides a convenient but less accurate time base. An externally-supplied crystal, termed a primary oscillator, provides an accurate time base. The crystal must be connected between the OSC1 and OSC2 pins along with the two capacitors as shown; a typical value for the capacitors is 15 pF. See the application note in reference [43] for more information on capacitor selection. Several other options, such as a 32.768 KHz watch crystal or a low-power RC oscillator (LPRC).

This base frequency can then be modified using either a phase-locked loop, an analog circuit which can multiply the clock frequency, or dividers to produce the desired operating frequency for the processor. Again, consult the datasheet for details. The library accompanying the book provides the following options; choose one by selecting Run > Set project configuration > Customize from the main menu, selecting xc16-gcc from the Categories tree, selecting Preprocessing and messages from the option categories drop-down box, clicking on the table cell to the left of Define C macros, then entering CLOCK_CONFIG=value , where value is chosen from Table 8.1. For example, entering CLOCK_CONFIG=FRCPLL_FCY40MHz selects a 40 MHz clock. See lib\include\pic24_clockfreq.h for further details; additional options can be added with relative ease by following the instructions given there. The choice of clock changes the contents of the configClock() function, which must be called by main() to select the desired operating clock.

274

Chapter 8

■

System Startup and Parallel Port I/O

Table 8.1: dsPIC33E Clocking Options CLOCK_CONFIG Value

Description

FRC_FCY3685KHz

Fast RC oscillator, producing FCY = 3.685 MHz.

FRCPLL_FCY40MHz

Fast RC oscillator multiplied by the PLL, producing FCY = 40 MHz.

FRCPLL_FCY60MHz

Fast RC oscillator multiplied by the PLL, producing FCY = 60 MHz. This is the default for the library.

FRCPLL_FCY70MHz

Fast RC oscillator multiplied by the PLL, producing FCY = 70 MHz. This higher speed is supported only over a limited frequency range.

PRIPLL_8MHzCrystal_4MHzFCY

Primary oscillator driven by an externally-supplied 8 MHz crystal, producing FCY = 40 MHz.

PRIPLL_8MHzCrystal_40MHzFCY

Primary oscillator driven by an externally-supplied 8 MHz crystal multiplied by the PLL, producing FCY = 40 MHz.

Power-On Reset Behavior and Reset Sources You have already read three causes of processor reset [16], namely the reset instruction, power-on reset (POR), and a low-true assertion of the MCLR# input. Figure 8.10 shows the complete set of processor reset sources. Brown-out reset (BOR) occurs when the input VDD drops below the level required for maintaining an operating core voltage. Both BOR and POR trigger operation of the power-on reset timer (PWRT), which delays the release of the SYSRST# signal until the input VDD has time to settle. Once SYSRST# is released, the power-on reset clock source is started and after this is detected as stabilized, the system transitions from the reset state to the running state. A trap conflict reset occurs if a lower priority hard trap occurs when a higher priority trap is being processed; this is discussed further in Chapter 9. An illegal opcode reset occurs if the instruction that is fetched contains an illegal opcode. An uninitialized W register reset occurs if a W register is used in an indirect addressing mode before being written with a value. The integrity of the configuration information within peripheral pin select registers is monitored by maintaining copies in shadow registers; if a difference between the shadow registers and pin select registers is detected then a configuration mismatch reset is generated. Attempts to execute protected blocks of code on the chip trigger a security reset. Resets related to the watchdog timer (WDT) and sleep/idle power modes are discussed in the next section. Figure 8.11 shows the RCON register bits that reflect the source of a processor reset. These can be used to debug a system that is experiencing intermittent reset. It is important that the user application clears these bits between resets or else a previous reset condition will mask the source of the current reset.

Power-On Reset Behavior and Reset Sources

275

Figure 8.10 Reset sources Source: Figure redrawn by author from Figure 8.1 found in the dsPIC33E/PIC24E Family Reference Manual, section 8: reset (DS70602B), Microchip, Technology Inc.

Figure 8.11 RCON register bit operation Source: Figure redrawn by author from Table 8.2 found in the dsPIC33E/PIC24E Family Reference Manual, section 8: reset (DS70602B), Microchip Technology Inc.

276

Chapter 8

■

System Startup and Parallel Port I/O

Figure 8.12 shows the code for the printResetCause() function called by echo.c in Figure 8.6 (for space reasons, this a simplified version of printResetCause(); the full code is contained in lib\src\pic24_util.c). Observe that printResetCause() checks each RCON register status bit, outputs an appropriate status message if the bit is set, then clears the bit. At the end of printResetCause(), the checkDeviceandRevision() function prints the processor ID and revision and checkOscOption() function prints a status message about the current clock option.

Figure 8.12

printResetCause() function

Watchdog Timer, Sleep, Idle, and Doze Figure 8.13 shows the block diagram of the watchdog timer (WDT) subsystem [17] mentioned previously. A timer is simply an N-bit counter; when N counts have passed the amount of time is equal to N * TTMR, where TTMR is the period of the clock signal that drives the counter. When the counter’s value wraps from its maximum value back to 0, the timer is said to have expired. A timer’s timeout value can be lengthened by having a programmable prescaler to divide the input clock frequency,

Watchdog Timer, Sleep, Idle, and Doze

277

and/or by having a programmable output postscaler that accumulates multiple counter rollovers as one timer expiration event. The WDT is clocked by the LPRC oscillator. The timeout period for the WDT is affected by its prescaler and postscaler settings, both of which are set by configuration bits. The prescaler can either be a fixed divide-by-32 or divide-by-128, while the postscaler is controlled by a 4-bit field that gives settings of 1:1, 1:2, 1:4, 1:8, ... up to 1:32,768.

Figure 8.13 Watchdog timer block diagram Source: Figure redrawn by author from Figure 9.2 found in the dsPIC33E/PIC24E Family Reference Manual, section 9: watchdog timer (DS70615C), Microchip Technology Inc.

A common use of the watchdog timer is for catching coding errors during development where a programmer uses an incorrect code sequence for communicating with an external device, and an expected response from the device does not occur, resulting in an infinite wait condition. Enabling the watchdog timer during the wait for the response places a maximum time limit on the wait before a watchdog timer reset occurs. In production code, the watchdog timer can protect against

278

Chapter 8

■

System Startup and Parallel Port I/O

an infinite wait condition in case noise or hardware failure corrupts communication with an external device. It is useful to think of the watchdog timer as an alarm clock in these scenarios, signaling that too much time has elapsed. Checking the WDTO (watchdog timer timeout) bit after a reset detects when this situation has occurred. To prevent WDT timeout during normal operation, the PIC24 instruction clrwdt (clear watchdog timer, which has no arguments) must be executed periodically to reset the WDT before the WDT expires. The optional windowed mode of the WDT is enabled by the WINDIS configuration bit. In windowed mode, the WDT can only be cleared in the last 25 percent of its timer operation, or else the processor is reset. This places both minimum and maximum bounds when timing an operation, and thus provides processor reset in the case that an event requires too little time or too much time. The WDT operation is enabled by either the FWDTEN configuration bit or the SWDTEN bit contained in the RCON register (RCON). The FWDTEN bit forces the WDT to be always enabled, while the SWDTEN bit gives the application control over WDT enabling. The following lines are used in lib\src\pic24_configbits.c to configure the WDT: #pragma config WDTWIN = WIN25

// FWDT #pragma config WDTPOST = PS512 #pragma config WDTPRE = PR128 #pragma config WINDIS = OFF #pragma config FWDTEN = OFF

// Watchdog Window Select bits (WDT Window // is 25% of WDT period)

// // // // // //

Watchdog Timer Postscaler bits (1:512) Watchdog Timer Prescaler bit (1:128) Watchdog Timer Window Enable bit (Watchdog Timer in Non-Window mode) Watchdog Timer Enable bit (Watchdog timer enabled/disabled by user software)

These configuration bits allow software control of the watchdog timer (FWDTEN = OFF), disable windowed mode (WINDIS = OFF), and set the prescaler to divide-by-128 (WDTPRE = PR128) and the postscaler to 1:512 (WDTPOST = PS512). Using the nominal LPRC clock frequency of 32.768 kHz, this provides a timeout value of: WDT timeout = 1/32768 ↔ 128 ↔ 512 = 2 seconds

(8.1)

The other use of the WDT is to wake the processor from either idle or sleep mode, which are two power conservation modes [17]. Sleep mode is entered by executing the pwrsav #0 instruction, which disables the system clock and all on-chip peripherals that depend on it. Idle mode (pwrsav #1) disables the CPU, but the system clock continues to operate; peripherals must be disabled manually through their associated control registers if desired. Sleep mode is the lowest power mode available to the PIC24. When the CPU is disabled by entering either sleep or idle modes, the watchdog timer continues to operate (if enabled). If the WDT expires during idle/sleep mode, then a WDT wakeup occurs and the processor continues execution at the instruction following the pwrsav instruction. An enabled interrupt event (Chapter 9) can also wake the processor from sleep/idle mode.

Watchdog Timer, Sleep, Idle, and Doze

279

Why does entering sleep mode decrease power consumption? The answer is straightforward: if the clock is stopped, no transistors are switching, which means no energy is being dissipated, thus reducing power. Of course, some energy is being dissipated, even with the clock stopped, but the amount is much lower than with the clock running. Power dissipation in a CMOS circuit is divided into two categories: static (Ps ) and dynamic (Pd). Static power is the power dissipated when no switching activity is occurring and is due to high-resistance leakage paths between VDD and ground within CMOS transistors. Power dissipation is measured in watts (1 Watt = 1 Volt * 1 Amp), but in datasheets, power dissipation is typically given as power supply current for a particular operating condition. The dsPIC33EP128GP502 typical sleep mode current at room temperature as listed in the datasheet is approximately 35 μA, and the idle current is 20 mA @ FCY = 70 MHz. The idle current is much higher than the sleep current because the main system clock is being used to drive the peripheral subsystems. The principal contribution to dynamic power dissipation Pd is given in Equation 8.2, where VDD is the power supply voltage, f the switching frequency, and c the amount of capacitance being switched. Pd = VDD2 • f • c

(8.2)

Because power is voltage multiplied by current (V • I), replacing Pd with VDD • I in Equation 8.2 yields: VDD • I = VDD2 • f • c

(8.3)

I = VDD • f • c

(8.4)

By Equation 8.4, you can see that there is a linear relationship between I, VDD, frequency, and capacitance. Idle mode reduces the capacitance c being switched, because the CPU operation is disabled and thus fewer transistors are switching, but the clock frequency remains unchanged and is still driving the peripheral modules. Sleep mode sets frequency for the system clock to zero, since the system clock is disabled. The doze postscaler, a component of the system clock module, is another method for reducing power. The doze postscaler reduces the system clock frequency to the CPU, but keeps the system clock frequency to the rest of the peripherals unchanged. This means that timing-sensitive modules such as the UART that you use for serial communication to PC will continue to function at the same data rate, and thus the baud rate for the serial link can remain unchanged. If the system clock frequency for peripherals was also reduced, then the baud rate for the UART would also have to be reduced since the serial communication rate is derived from the system clock. If the doze postscaler is set to a 1:2 setting, which reduces the CPU clock frequency by a factor of 2, then the current drawn by the CPU portion of the PIC24 will also be reduced by one half, assuming that the static power contribution from the CPU (non-switching current draw) is small. On the dsPIC33E, static current draw is in the 10s of microamperes, as reported by the datasheet for the sleep mode current.

280

Chapter 8

■

System Startup and Parallel Port I/O

The reset.c Test Program A program named reset.c is used in this section to illustrate the concepts of persistent variables, sleep/idle mode, watchdog timer reset, watchdog timer wakeup, and doze mode. Figure 8.14 shows the portion of reset.c before entry into the program’s infinite while (1) loop. The configuration code executed before the outString(HELLO_MSG) statement is the same as for Figure 8.6 (echo.c) with one addition, the configPinsForLowPower() function that configures all of the parallel I/O pins for lowpower operation (which configures all unused pins as inputs with weak pull-ups enabled; see the next section for details), powers off unused peripherals, and disables the internal voltage regulator when in sleep mode. The function is used here because you need to measure the current draw for various power modes and want the parallel I/O pins and other peripherals configured for the least possible current draw.

Figure 8.14 chap08\reset.c: Setup portion of program

The reset.c Test Program

281

The _PERSISTENT uint8_t u8_resetCount declaration means that the u8_resetCount variable is never initialized by the C run-time code. This allows the variable to track events across processor resets; in this case it’s used as a simple counter for the number of non-POR events that occur. Observe that u8_resetCount is initialized to 0 only when the _POR bit is set, indicating that a power-on reset has occurred. If the _WDTO bit is set, indicating that a watchdog timer expiration caused the last processor reset, then the _SWDTEN bit is cleared, disabling the operation of the watchdog timer. Before entering the while (1) loop, the u8_resetCount value is printed by the function outUint8(uint8_t u8_x), which prints its argument to the console in ASCII-hex. The outUint8(uint8_t u8_x) function is found in lib\src\pic24_serial.c. Figure 8.15 shows the while (1) portion of the reset.c program. The printMenuGetChoice() function (not shown) outputs a menu of choices 1–7, where the choices are: ■

■

■

■

■

■

■

1: Enables the WDT, which is configured for a 2-second timeout period. After the menu is reprinted, a processor reset occurs when the WDT expires if no further action is taken by the user. Recall that the WDT is disabled by the code preceding the while (1) loop on a processor reset. 2: Enters sleep mode (pwrsav #0 instruction). Because the WDT is disabled at this point, the only way to wake up the processor with a user action is to cycle power or press the MCLR# reset button. A C inline assembly statement (asm) is used to insert the pwrsav #0 instruction into the C code. 3: Enters idle mode (pwrsav #1 instruction). As with sleep mode, a power cycle or pressing the MCLR# reset button is required by the user to wake the processor. 4: Enables the WDT, then enters sleep mode. The processor will sleep for approximately 2 seconds because of the particular watchdog timer configuration bit settings, then wake when the WDT expires, reprinting the menu choice. If no further action is taken by the user, the WDT expires again in 2 seconds, causing a processor reset, then the WDT is disabled before re-entering the while (1) loop. 5: Enables doze mode with an FCY divided by 2. No visible change is apparent to the user, but an ammeter shows a reduction in current draw. 6: Enables doze mode with an FCY divided by 128. No visible change is apparent to the user, but an ammeter shows a reduction in current draw. 7: Executes a software reset via the reset instruction.

282

Chapter 8

■

System Startup and Parallel Port I/O

Figure 8.16 shows some sample output from the reset.c program for the choice sequence of 1 (enable watchdog timer) in comments a through c, followed by 2 (enter sleep mode) in comments d through g, and finally 4 (enable WDT, then enter sleep mode) in comments h through j.

Figure 8.15 chap08\reset.c: while (1) portion of the reset.com program

The reset.c Test Program

283

Figure 8.16 Sample output from the reset.c program

Table 8.2 shows the VDD current draw in mA as measured by an ammeter when testing the sleep, idle, doze(/2), and doze(/128) modes using the reset.c program for two different PIC24 microcontrollers.

284

Chapter 8

■

System Startup and Parallel Port I/O

Table 8.2: PIC24 Current Draw (mA) Mode

dsPIC33EP128GP502@60 MHz FCY

PIC24FJ64GA002@16 MHz FCY

Normal Operation

35.7

5.6

Sleep

0.009

0.004

Idle

15.2

2.0

Doze (/2)

28.8

4.0

Doze (/128)

15.3

2.0

The following comments will use the numbers in Table 8.2 for the dsPIC33EP128GP502 with FCY = 60 MHz. As previously stated, the sleep mode offers the greatest reduction in current draw because it stops the system clock as well as all of the peripherals, as shown in Table 8.2 with a measured current draw of 8.8 μA. The idle mode stops the clock to the CPU, but not the clock to the peripherals, producing a 15.2 mA current draw. The doze mode of FCY/2 had a measured current draw of 28.8 mA. Because doze mode only affects the CPU clock and not the peripheral clock, you could have roughly predicted the doze mode current draw, as shown in Equation 8.5, where N is the doze mode postscaler. Doze cur.(/N mode) = Idle cur. + (Normal cur. − Idle cur.)/N

(8.5)

Idle mode current subtracted from Normal mode current is approximately the current drawn by the CPU, which is the current that is affected by doze mode. Using values from Table 8.2 for Normal and Idle currents, Equation 8.6 predicts a doze current for FCY/2 mode of 25.5 mA, which is reasonably close to the measured value of 28.8 mA. Doze current (for /2) = 15.2 + (35.7 − 15.2)/2 = 25.5 mA

(8.6)

The PIC24F has lower maximum performance than the dsPIC33E family, but offers lower power consumption at equivalent clock frequencies. The difference in current values between the two devices in Table 8.2 is exaggerated because of the clock speed inequity.

Parallel Port Operation Parallel port I/O, also termed general-purpose I/O (GPIO), refers to groups of pins whose values can be read or written as a group via special function registers. On the dsPIC33EP128GP502 μC, two parallel ports are available: PORTA and PORTB. Additional ports, such as PORTC, PORTD, PORTE, and higher are available on larger pin count versions of the PIC24 μC. Each port is 16 bits wide, but whether or not all ports are available on external pins depends on the particular PIC24 μC. For example, on the dsPIC33EP128GP502 all 16 bits of PORTB are available externally, but only the lower 5 bits of

Parallel Port Operation

285

PORTA are. The individual port pins on the dsPIC33EP128GP502 pin diagram in Figure 8.2 are named RBx or RAx, for PORTB and PORTA, respectively. The various parallel ports A, B, C, and so on, all operate the same in terms of their basic digital input/output functionality. Only PORTA and PORTB are used in the interfacing examples in this book, as the dsPIC33EP128GP502 μC is the target device.

Figure 8.17 shows the general diagram of a parallel port pin. Each parallel I/O (PIO) pin may share the external pin with other on-chip peripherals, labeled as Peripheral Modules in Figure 8.17. Control bits in special function registers determine which peripheral actually has access to the pin when multiple peripheral outputs share the same physical pin. This is shown conceptually in Figure 8.17 as the output multiplexer logic. The shaded pins are 5 V tolerant—input voltages of up to 5.5 V do not damage the pin (note that this capability requires VDD ≥ 3.0 V). The remaining pins support a maximum input voltage of VDD + 0.3 V, or 3.6 V assuming that VDD is 3.3 V. Most dsPIC33E I/O pins can sink and source a maximum of 5 mA (some exceptions exist; see [31]).

Figure 8.17 Parallel port general structure Source: Figure redrawn by author from Figure 11.1 found in the dsPICEP128GP502 datasheet (DS70000657H), Microchip Technology, Inc.

286

Chapter 8

■

System Startup and Parallel Port I/O

Each parallel port has three special function registers associated with it named PORTx/TRISx/LATx, where x is the specific port such as A or B. The TRISx register is used to configure each bidirectional port bit as either an input or output. A 1 in a TRISx register bit configures the associated PORTx register bit to be an input (note that 1 looks like I for input), while a 0 configures the associated PORTx register bit to be an output (0 looks like O for output). The LATx register is the data latch used to drive the port pins when it is configured as an output. Reading PORTx returns the values of the external pins, while reading LATx reads the data latch value. Writing to either LATx or PORTx writes to the data latch of the associated port. Individual bits are referenced as LATxy and Rxy where x gives the port’s letter (A-E) and y gives the bit within the port. In C code, these references can be written as _Rxy (_RA2, _RB5, _RB14, and so on) for bits in the PORTx register and as _LATxy/_TRISxy (_LATA2, _TRISB5, _LATB14, and so on) for bits in the LATx/TRISx registers. Generally, the code examples use individual bit assignments instead of assigning all bits of a port at once. Note that reading _LATxy may not return the same value as reading _Rxy. If the port is configured as an input, reading _LATxy returns the last value written to _LATxy or _Rxy, while reading _Rxy returns the value of the external pin. If the port is configured as an output, reading _LATxy will normally return the same value as reading _Rxy because the data latch is driving the external pin. However, if there is another external driver that is clashing with the port driver, or if the port driver itself is a special case like an open-drain output (explained later in this section), _LATxy and _Rxy may return different values when read. A write to a port bit configured as an input changes the value of the output data latch (_LATxy), but does not change the value seen on the external pin whose value is set by whatever is driving that pin. Even though in principle writing to _Rxy is equivalent to writing to _LATxy, in the case of bset (bit set) or bclr (bit clear) instructions they are not equivalent because these are read-modify-write instructions. Thus, a bit set of _Rxy reads _Rxy, modifies the value, then writes _Rxy, while a bit set of _LATxy reads _LATxy, modifies the value, then writes _LATxy. The Family Reference Manual [18] warns that the following consecutive assignments _RB2 = 1; _RB3 = 1;

// Implemented by compiler using a bset instruction // Implemented by compiler using a bset instruction

can produce an incorrect result for the second assignment (even though they are for different bits), depending on external pin loading and internal clock speed. However, using _LATxy for port writes always works: _LATB2 = 1; _LATB3 = 1;

// Implemented by compiler using a bset instruction // Implemented by compiler using a bset instruction

Because of this, the code uses _LATxy for port writes, and _RBxy for sensing (reading) a pin state. The code reads _LATxy when you want to toggle a previously written value, such as _LATB2 = !_LATB2.

Parallel Port Operation

287

Tristate Drivers Figure 8.18 shows that the output of a _TRISx latch bit y (_TRISxy) is connected to the output enable of the tristate buffer that drives the I/O pin. If _TRISxy is 0 (the port bit is an output), the tristate buffer is enabled and simply passes its input value to its output. If _TRISxy is 1 (the port bit is an input), the tristate buffer is disabled, and its output becomes high impedance, whose state is commonly designated as Z. Figure 8.18 shows that you can think of the tristate buffer enable as controlling a switch on the output of the buffer; the switch is closed when the enable is asserted, allowing the buffer to drive its output. The switch is open when the enable is negated, causing the output to float (also known as high impedance). Note that a port bit cannot be both an input and an output simultaneously; it is either one or the other based on the setting of the _TRISxy bit. The lower part of Figure 8.18 shows data flow on a bidirectional data link using one wire; data is either flowing from CPU_a to CPU_b or vice versa, but never both directions at the same time over one wire if voltage mode signaling is used (if both tristate buffers are enabled then this can cause an indeterminate voltage on the wire and it is a programming error in the μC application).

Figure 8.18 Tristate buffer operation and bidirectional I/O

288

Chapter 8

■

System Startup and Parallel Port I/O

Schmitt Trigger Input All PIO inputs use a Schmitt Trigger input buffer for driving internal signals from the external pin. Figure 8.19 shows the Vin/Vout characteristics of a Schmitt Trigger buffer. Observe that a low-tohigh transition must become close to VDD (VIH) before the buffer trips; conversely, a high-to-low transition must be close to ground (VIL) before the buffer trips. This hysteresis in the buffer action provides extra immunity against noise on the input signal and is also used for transforming slowly changing inputs into signals with fast rise and fall times.

Figure 8.19 Schmitt Trigger input buffer characteristic

Open-Drain Output Many PIO pins have the capability to be configured as an open-drain driver, which means that the PMOS pull-up is disabled, as shown in Figure 8.20(b), removing the ability of the port pin to drive its output high (instead, the output pin floats when driven high). One application of an open-drain driver is to use an external pull-up resistor to provide an output high voltage that is higher than the PIC24 VDD value of 3.3 V. In the case of Figure 8.20(c), the external pull-up is used to provide an output voltage of 5 V. The value of the pull-up resistor is chosen so that the current sunk by the pin when the output is pulled low does not exceed the maximum current specification, which is 5 mA for the majority of the dsPIC33E I/O pins. Thus, the resistor value should be at least 5 V/ .005 A = 200 Ω. Another open-drain application is shown in Figure 8.20(d), in which two open-drain outputs are connected together to form a wired logic function. This is a common usage when wanting to detect if any of the outputs are asserted low (a low-true OR function); the outputs can simply be wired together with an external pull-up without the need for a logic gate. The maximum allowed open-drain voltage for a pin is the same as the pin’s maximum allowed VIH (5.6 V for digital pins) as per the datasheet [31].

Parallel Port Operation

289

Figure 8.20 Open-drain driver and application

Most PIO ports have an open-drain control register (ODCx) that is used for enabling (_ODCxy = 1) or disabling (_ODCxy = 0) the open-drain capability. The following two C statements configure port RB11 as an open-drain output: _TRISB11 = 0; _ODCB11 = 1;

// RB11 is an output. // RB11 output is open-drain.

Internal Weak Pull-Ups and Pull-Downs Most I/Os have a capability referred to as input change notification. These pins have a weak pullup that can be enabled (_CNPUxy = 1) or disabled (_CNPUxy = 0), as well as a weak pull-down that can be enabled (_CNPDxy = 1) or disabled (_CNPDxy = 0), as shown in Figure 8.21(a). The term weak is used because the resistance is high enough that an external driver can overpower the pull-up resistor and pull the input to near ground, producing a 0 input. The weak pull-up is implemented as a highresistance P-transistor and when enabled, the gate of this transistor is 0, turning it on. Similar statements apply to pull-downs. The weak pull-up is useful for eliminating the need for an external pullup resistor on an input switch, as shown in Figure 8.21(b). If an external device providing input sometimes enters a high-impedance state, by driving its output neither high nor low, a weak pulldown could be used to produce a known value of 0 at the input to the μC. Note that a pushbutton

290

Chapter 8

■

System Startup and Parallel Port I/O

switch configured as a low-true input switch must have some form of pull-up resistor, either internal or external, or the input floats when the pushbutton is not pressed, allowing the input to be read as either 1 or 0.

Figure 8.21 Change notification weak pull-ups

The following two C statements configure RB11 as an input, then enable the weak pull-up on that pin. _TRISB11 = 1; _CNPUB11 = 1;

// RB11 is an input. // Enable weak pull-up on RB11.

Digital versus Analog Inputs One of the peripherals that shares a physical pin with the PIO module is the analog-to-digital converter (ADC) module. ADC inputs are labeled as ANn on the dsPIC33EP128GP502 pin diagram in Figure 8.2, so it is seen that RB3 is assigned the same physical pin (7) as analog input AN5. An additional complication is that in order for the parallel port to be used as an input, the analog functionality of the pin has to be disabled, which can be done using the _ANSELxy bit associated with each ANn input (the older PIC24H family used a register named PCFG for the same purpose). By default, each I/O with an ANn function is configured as an analog input (_ANSELxy = 1), but it can be configured for digital mode by clearing the _ANSELxy bit (_ANSELxy = 0). For example, RB3 shares pin 7 with AN5, so the following two C statements configure RB3 as an input: _TRISB3 = 1; // RB3 is an input. _ANSELB3 = 1; // Configure RB3 (AN5) for digital mode.

A PIO pin configured as an input, but with the analog mode enabled, will always read as 0. As suggested by the PIC24 Family Reference Manual, you will also configure a pin for digital mode when a PIO is used as an output so that the analog input circuitry does not load the output driver (this load is significant and slows signal transitions).

Parallel Port Operation

291

PIO Control Bits Summary Table 8.3 summarizes the control bits used to configure parallel I/O for a single pin of a PIC24 device.

Table 8.3: PIO Control Bits Name

Set to 1

Reset to 0

Description

_ANSxy

Enable

Disable

Analog functionality

_TRISxy

Input

Output

Configure the direction of a pin

_ODCxy

Enable

Disable

Open-drain driver for a pin

_CNPUxy/_CNPDxy

Enable

Disable

Pull-up/pull-down for a pin

PIO Configuration Macros/Functions Because of the numerous options available for PIO pins (input/output, analog/digital, weak pull-up/ pull-down, open-drain), you can use macros for PIO configuration to improve code clarity. These macros are contained in lib\include\pic24_ports.h and are: ■

■

■

Pull-up/pull-down configuration: These enable/disable the weak pull-ups/pull-downs on PORTA/PORTB pins and are named ENABLE_Rxy_PULLUP(), DISABLE_Rxy_PULLUP(), ENABLE_Rxy_PULLDOWN(), and DISABLE_Rxy_PULLDOWN(), where x = A for port A or B for port B and y gives the bit number on that port; for example, xy = B5 refers to RB5. For the dsPIC33EP128GP502, all PIO pins have an associated input change notification functionality, so all have the weak pull-up capability and pull-down (this is not true for all PIC24 microcontrollers). Open-drain configuration: These enable/disable the open-drain functionality on PORTA/PORTB pins and are named ENABLE_Rxy_OPENDRAIN() and DISABLE_Rxy_OPENDRAIN(). Input/output configuration: These configure the PORTA/PORTB pins as either inputs or outputs and are named CONFIG_Rxy_AS_DIG_INPUT()and CONFIG_Rxy_AS_DIG_OUTPUT(). The input macros disable the weak pull-up/pull-down and configure analog pins for digital mode as necessary. The output macros disable the weak pull-up/pull-down and also the open-drain capability.

The lib\include\pic24_ports_config.h file includes device-specific macros based on the target device set within MPLAB®. The following code shows simplified examples of the input/output configuration functions for the RA0 pin: // Low-level config // // Analog:

292

Chapter 8

■

System Startup and Parallel Port I/O

/// Enable analog functionality on pin RA0. #define ENABLE_RA0_ANALOG() (_ANSA0 = 1) /// Disable analog functionality on pin RA0. #define DISABLE_RA0_ANALOG() (_ANSA0 = 0) // Input/output: /// Configure pin RA0 as an input. #define CONFIG_RA0_AS_INPUT() (_TRISA0 = 1) /// Configure pin RA0 as an output. #define CONFIG_RA0_AS_OUTPUT() (_TRISA0 = 0) // Open-drain: /// Enable the open-drain driver on pin RA0. #define ENABLE_RA0_OPENDRAIN() (_ODCA0 = 1) /// Disable the open-drain driver on pin RA0. #define DISABLE_RA0_OPENDRAIN() (_ODCA0 = 0) // Change notification, pull-ups and pull-downs: /// Enable the pull-up on pin RA0. #define ENABLE_RA0_PULLUP() (_CNPUA0 = 1) /// Disable the pull-up on pin RA0. #define DISABLE_RA0_PULLUP() (_CNPUA0 = 0) /// Enable the pull-down on pin RA0. #define ENABLE_RA0_PULLDOWN() (_CNPDA0 = 1) /// Disable the pull-down on pin RA0. #define DISABLE_RA0_PULLDOWN() (_CNPDA0 = 0)

// High-level config // void CONFIG_RA0_AS_DIG_INPUT() { DISABLE_RA0_ANALOG(); CONFIG_RA0_AS_INPUT(); DISABLE_RA0_OPENDRAIN(); DISABLE_RA0_PULLUP(); DISABLE_RA0_PULLDOWN(); } void CONFIG_RA0_AS_DIG_OUTPUT() { DISABLE_RA0_ANALOG(); CONFIG_RA0_AS_OUTPUT();

LED/Switch I/O and State Machine Programming

293

DISABLE_RA0_OPENDRAIN(); DISABLE_RA0_PULLUP(); DISABLE_RA0_PULLDOWN(); }

The low-level configuration macros provide a meaningful name for the PIO control bits discussed previously. The more convenient high-level configuration functions configure a pin in the most common states (as a digital input or output); for finer control, follow a high-level configuration with a low-level configuration: CONFIG_RA0_AS_OUTPUT(); ENABLE_RA0_OPENDRAIN();

Not all pins provide all the functionality shown previously. For example, RA2 lacks analog capability. In this case, the ENABLE_RA2_ANALOG() macro is not defined, while DISABLE_RA2_ANALOG() does exist, but does nothing. When configuring many I/O ports, it is more code efficient to directly write 16-bit values to configuration registers such as _TRISx, _ANSELx, and so on. However, I will sacrifice some code efficiency for code clarity in the examples by use of these macros since this is an introductory text on microcontroller interfacing, so code clarity is more important at this point.

LED/Switch I/O and State Machine Programming A common input device is a momentary pushbutton switch. Figure 8.22 shows a pushbutton switch connected to RB13, with RB13 configured as an input with the weak pull-up enabled. When the pushbutton is released (not pressed) the RB13 input reads as 1; when the pushbutton is pressed the RB13 input reads as 0. Port RB14 is configured as a digital output for driving an LED, which has a 470 Ω series resistor. To compute the needed resistance value, recall that a typical PIO pin on the PIC24 μC can provide a maximum current of 5 mA, and so you can use this value as the target current through the LED in order to maximize the LED illumination. Next, consult the LED’s datasheet to determine the voltage drop across the LED at the selected current; a typical figure for many LEDs is 2 V. Recalling that Ohm’s law is V = IR, solving for resistance gives R = V/I, where V is the voltage drop across the resistor. With a 3.3 V supply and a 2 V drop across the LED, this leaves V = 3.3 – 2 = 1.3 V. Therefore, the resistance R = 1.3 V/0.015 A = 260 Ω, which gives the lowest resistance allowed for a 5 mA or less target current. Older PIC24 variants such as the PIC24H supply only 4 mA; to support this family as well and to add some margin of safety, a value of 470 Ω was chosen. The CONFIG_LED1() macro is used for configuring the port that drives the LED, while the config_pb() function is used for configuring the input port used for the switch. In general, macros will be used for single-line statements while functions will contain multi-line routines. Observe that the RB13 pull-up is enabled in config_pb() after the port is configured as a digital input. The PB_PRESSED() and PB_RELEASED() macros are used for testing if the switch is pressed or released, respectively.

294

Chapter 8

■

System Startup and Parallel Port I/O

In both the (a) and (b) code segments, a 1 μs delay (DELAY_US(1)) is used after configuring SW1 to allow the pull-up on the port to work. After enabling a pull-up, the PIC24 μC with a fast clock can read an input port before the input has had time to be pulled to a logic 1, so the code examples use this conservative delay after enabling weak pull-ups on input ports.

Figure 8.22 Toggling an LED after a switch press and release

Assume that you would like to toggle the LED each time the pushbutton is pressed and released (toggle means to turn the LED off if it is currently on, and vice-versa). A common mistake is shown in code segment (a), which toggles the LED when the switch is pressed (RB13 returns 0). The problem with this code is that the LED is not only toggled when the pushbutton is pressed, but is also toggled for as long as the pushbutton is held down. Human reaction times on pushbutton switches are measured in tens of milliseconds, so the LED is toggled many times for each pushbutton activation!

LED/Switch I/O and State Machine Programming

295

Code segment (b) shows a correct solution to this problem. When the while (1) loop is entered, the code becomes trapped in the loop while (PB_RELEASED), which loops waiting for the pushbutton to be pressed. Once the pushbutton is pressed, the LED is toggled and code is then trapped in the loop while (SW1_PRESSED), waiting for the pushbutton to be released. Upon release, the code becomes trapped in the loop while (SW1_RELEASED) again. Thus, the LED is toggled only once for each press and release of the pushbutton. Moving the toggle statement (LED1 = !LED1) to the end of the outer while (1) loop toggles the LED when the pushbutton is released, but the end result of toggling once for each press and release remains the same. The DELAY_MS(15) function calls are included after each change in the input switch status to ensure that all switch bounce has settled before continuing. Mechanical switch bounce can produce multiple pulses when a pushbutton is activated. The required delay is a function of the mechanics of the switch bounce, which can only be seen by using an oscilloscope to capture the switch waveform or from a manufacturer datasheet. The value of 15 ms used here should be adequate for common momentary switches. This is a simple method for debouncing a switch with the drawback that the CPU cycles spent in the software delay loop are wasted. Alternative methods for switch debouncing are presented in Chapter 9.

State Machine I/O Programming The code of Figure 8.22(b) waits for an I/O event (switch press and release) then performs an action (LED toggle). A common task in microcontroller applications is to perform a sequence of events that spans a series of I/O actions. A finite state machine (FSM) approach for code structure is useful for these types of problems. Figure 8.23 shows the LED toggle problem of Figure 8.22 cast as a state machine specification.

Figure 8.23 State machine specification of LED toggle problem

296

Chapter 8

■

System Startup and Parallel Port I/O

The state machine consists of two states, named PRESSED and RELEASED, matching the state of the pushbutton. The RELEASED state progresses to the PRESSED state when PB is pressed, toggling the LED during the transition. This is a conditional state output, because the output only occurs if a specific condition (here, the pushbutton being pressed) is true. The PRESSED state moves to the RELEASED state when PB is released. Specifying I/O actions as a state machine is common practice because the state machine is a non-ambiguous description. Figure 8.24 shows a code implementation for the LED toggle problem written in a state machine style. This style will be the preferred method for I/O problems. Although more verbose than Figure 8.22, it allows us to code complex I/O problems in a structured manner. The state names are defined using an enumerated type definition in Figure 8.24 (a) called STATE. An enumerated type provides for readable state names that improves code clarity. Each state name is assigned an integer value (incrementing up from the integer assigned to the first state, which is 0). Enumerated type variables are mapped to the int type in C. Next, a printable version of each state is defined in an array of strings named apsz_state_names. The print_state function outputs these strings when the state passed to it differs from the last state it was passed. The update_state function stores the current state in e_state and updates it based on the state machine shown in the previous figure. Finally, main initializes the hardware then repeatedly calls update_state, waiting 15 ms between calls to suppress switch bounce. At the top of the while (1) loop, the print_state(e_state) function call prints the current state name to the console if the e_state value has changed since the last call. This is useful for debugging, as the current state name is needed to determine what code is being executed. The state diagram of Figure 8.23 is implemented in update_state; the remainder of the program supports the execution of this state machine. In this function, switch (e_state) identifies the current state; specifically, each case statement maps to a state of Figure 8.23. The default state is entered whenever the switch variable does not match any of the previous case statements. It is considered good programming practice to always include a default statement in the event that the switch variable contains an unexpected value either through a programming error or some kind of memory corruption. Observe that the e_state variable is only changed if the condition for a state change is met, such as the pushbutton switch being pressed (e) in STATE_RELEASED or released in STATE_PRESSED. Because if statements are used to check conditions, rather than while statements as in Figure 8.22, the code is continually looping through the switch statement. This allows you to place a doHeartbeat() call (i) at the end of the while (1) loop to keep the heartbeat LED pulsing, giving us a visual indication that code is being executed. Switch debounce (h) is accomplished by the DELAY_MS(DEBOUNCE_DLY) at the end of the switch statement, which means that the switch input is only being checked every DEBOUNCE_DLY milliseconds (the DEBOUNCE_DLY macro is defined in lib\include\ pic24_delay.h and has a value of 15). This is satisfactory since the while (1) loop has no other work to do except to sample the switch. If other work was to be performed, and you did not want to have the DEBOUNCE_DLY delay each time through the while (1) loop, then the DELAY_MS(DEBOUNCE_DLY) could be placed at each point in the code where a switch change is detected, as was done in Figure 8.22(b).

LED/Switch I/O and State Machine Programming

Figure 8.24 chap08\ledtoggle.c: State machine code solution for LED toggle problem

297

298

Chapter 8

■

System Startup and Parallel Port I/O

Extended State in a More Complex LED/Switch I/O Problem In the previous problem, the state machine shown required only two states, PRESSED and RELEASED. However, the machine passes through four states: pressed and released when the LED is on, then pressed and released again when the LED is off. This is accomplished by storing one bit of state in the LED1 variable (on and off). This variable extends the effective states of the machine, transforming the two states of PRESSED and RELEASED into four states, which could be named ON_PRESSED, ON_RELEASED, OFF_PRESSED, and OFF_RELEASED. This extended state can be used to provide a state machine with complex behavior while limiting the number formal states to a manageably small set. For example, Figure 8.25 shows a state machine specification of a more complex LED/switch I/O problem. The LED is turned off initially. After a pushbutton press and release, the LED is turned on. A slide switch input (SW) is used to control what happens after the next pushbutton press: either branch back to the initial state or continue on to a blinking state. The LED is blinked (toggled) up to five times, as long as the pushbutton is released, then the state machine returns to its initial state. Pressing the pushbutton terminates the blinking and transitions to a final state, which returns to the initial state once the pushbutton is released. The SW input is a slide switch that connects the associated port to either GND or leaves it floating, with the internal pull-up providing a logic high when the input is floating. Figure 8.26 shows the C code implementation of Figure 8.25 in the same style as Figure 8.24. Notice that the LED is turned on and off using an unconditional state assignment – it appears without any qualifying if clause. In contrast, the extended state variable u16_led_toggles is initialized to 0 on exiting the PRESSED2 state and transitioning to the RELEASED3_BLINK state using a conditional state assignment. The remainder of the extended state usage occurs in the RELEASED3_BLINK state; in this case clause, u16_led_toggles is unconditionally incremented with each LED toggle; when this reaches 10 (which is 5 blinks), the machine moves to the initial state; if the button is pressed before 5 blinks, it moves to the PRESSED3 state. Note that in contrast to typical programming practice, a for loop was not—and should not be— used. First, consider the following equivalent code. (Yes, C does provide a goto statement.) One of the three transitions in the state machine (a transition back to the current state) no longer appears; the other two transitions are less clearly stated, making the code harder to maintain. Second, the nature of a for loop, which traps execution inside itself, prevents this code from working in an interrupt-driven context as presented in Chapter 9, significantly limiting its usefulness. Therefore, avoid loops such as for and while and allow control to pass straight through each case statement. case STATE_RELEASED3_BLINK: for (u16_led_toggles = 0; u16_led_toggles < 10; u16_led_toggles++) { LED1 = !LED1; DELAY_MS(250);

LED/Switch I/O and State Machine Programming

if (PB_PRESSED()) { e_state = STATE_PRESSED3; goto exit_case; } } e_state = STATE_RELEASED1; LED1 = 0; exit_case: break;

Figure 8.25 State machine specification for LED/switch I/O problem

299

300

Chapter 8

■

System Startup and Parallel Port I/O

Figure 8.26 chap08\ledsw1.c: Code implementation for LED/switch I/O problem

Interfacing to an LCD Module

301

Press/release macros are not defined for SW because you are simply checking if the input is a 1 or a 0 (a) as you are not associating a press/release connotation with this input. The DELAY_MS(250) call (b) in state RELEASE3_BLINK provides a delay after toggling the LED; this is needed to ensure that the blinking action is visible. Note that while the DELAY_MS() software delay is executing, the switch input is not being sampled, which means that a very fast press and release could be missed. Chapter 9 discusses alternative methods for switch sampling that avoid this problem.

Figure 8.27 Console output for LED/switch I/O implementation

Figure 8.27 shows console output while testing the C code of Figure 8.26. The SW input was 1 for the first two times that the WAIT_FOR_RELEASE2 state was exited, causing the next state to be BLINK. After this, the SW input was 0 the next two times that the WAIT_FOR_RELEASE2 state was exited, causing the following state to be WAIT_FOR_PRESS1.

302

Chapter 8

■

System Startup and Parallel Port I/O

Interfacing to an LCD Module A liquid crystal display (LCD) is often used in microcontroller applications because they are low power and can display both alphanumeric characters and graphics. Disadvantages of LCDs are that they have low viewing angles, are more expensive than LED displays, and must be lit by either ambient light or a back light. LCD character modules display multiple characters, with modules using a k x n designation where k is the number of characters displayed on each of the n display lines. LCD modules have either a parallel or serial interface, with many LCD parallel interfaces standardized around the Hitachi HD44780 LCD controller. Figure 8.28 shows a PIC24 μC to LCD interface for a Hantronix 16x2 LCD module (part# HDM16216L-5). This interface is independent of the k x n organization of the LCD module, and is applicable for most LCD modules based on the HD44780 LCD controller.

Figure 8.28 PIC24 µC to LCD interface (4-bit mode)

Interfacing to an LCD Module

303

The interface is divided into control lines (E, R/W#, RS), data lines (D7:D0), and power (VDD, VSS, VL, K, A). The 4-bit interface mode is used to reduce the number of connections between the PIC24 μC and the LCD. In 4-bit mode, 8-bit data is sent in two 4-bit transfers on lines D7:D4, allowing D3:D0 to be unconnected. The K, A inputs are for the back light display (see datasheet [33]), while the VDD − VL voltage difference determines the intensity of the displayed numerals (connecting VL to VSS provides maximum intensity but may cause VDD − VL to exceed the maximum recommended VL value on some LCD modules). A logic high on the R/W# signal indicates a read operation; the LCD module provides data to the PIC24 μC. A logic low on R/W# is a write operation; the PIC24 μC provides data to the LCD module. The E signal is a data strobe used to signal valid data on the Dn, RS, and R/W# lines. To perform a write operation, the PIC24 μC places data on the Dn/RS signals, R/W# is driven low, and E is brought high and then low. The LCD latches the input data on the falling edge of E, so the Dn lines must satisfy the setup time Tds, while the control lines RS, R/W# are latched on the rising edge of E and must satisfy the setup time Tas. Not all timings are shown on the diagram; there are small hold times about the E edges that must be satisfied as well (see [33]; these are easily satisfied by typical microcontroller operation). To read data from the LCD, data is placed on the RS signal, R/W# is driven high, and E is brought high. After the data delay time Tddr has elapsed, valid data is ready on the Dn lines from the LCD, which can then be read by the PIC24 μC. The E signal is brought low to finish the read operation. Because software assignments are used to drive the E signal, the minimum pulse width depends on the system clock frequency. At FCY = 40 MHz, the PIC24 μC is capable of producing a pulse that violates the minimum pulse width requirement of the E signal. The example code uses software delays of 1 μs as a very conservative method of ensuring that the E signal timing requirements are met and because I/O transfer performance is not an important issue in this example. Using software assignments for driving PIO pins to accomplish data transfers instead of dedicated hardware modules that drive the pins is often referred to as bit-banging. The PIC24 μC has several dedicated hardware modules for accomplishing specialized data transfers without CPU intervention; these are covered in later chapters.

3.3 V to 5 V Interfacing The LCD module used in Figure 8.28 requires a 5 V supply, the first time that you have dealt with 3.3 V to 5 V interfacing. Any input signals must be 5 V input tolerant, which means that PIC24 μC RBn ports used for the LCD D[7:4] pins must be 5 V tolerant. For output signals, a 3.3 V output port can drive a 5 V input port if the 5 V input port has TTL-level inputs (VIH is approximately 2.0 V). However, if the device has CMOS level inputs (VIH is approximately 3.8 V) then all signals will need weak external pull-ups (approximately 10 kΩ) and must be configured as open-drain outputs when acting as outputs. This would also mean that digital-only ports would have to be used for all signals since the maximum open-drain voltage is the same as the maximum input voltage. The Hantronix LCD module used in Figure 8.28 has TTL-level inputs, so external pull-ups are not required.

304

Chapter 8

■

System Startup and Parallel Port I/O

LCD Commands A subset of the available LCD commands [34] is shown in Table 8.4. If RS = 0, the D7:D0 bits represent an LCD command that affects mode, screen, or cursor position. If RS = 1, the D7:D0 bits contain data being written to or read from the LCD data display RAM (DD RAM) in the form of an ASCII character code.

Table 8.4: LCD Command Subset Command

RS

R/W#

D7:D0

Description

Clear Display

0

0

0000 0001

Clear display, return cursor to home position (82 µs ~ 1.64 ms)

Return Home

0

0

0000 001x

Returns cursor and shifted display to home (40 µs ~ 1.64 ms)

Entry Mode Set

0

0

0000 01d 0

Enable the display, set cursor move direction (d = 1 increment, d = 0 decrement) (40 µs)

Display On/Off

0

0

0000 1dcb

Display on/off (d ), Cursor on/off (c ), blink at cursor position on/off (b) (40 µs)

Cursor & Display Shift

0

0

0001 cr 00

c = 1 shift display, c = 0 move cursor, r = 1 right shift, r = 0 left shift

Function Set

0

0

001i n 000

8-bit interface (i = 1), 4-bit interface (i = 0), one line (n = 0), two lines (n = 1) (40 µs)

Set DD Address

0

0

1nnn nnnn

DD RAM address set equal to nnnnnnnn (40 µs)

Read Busy Flag

0

1

fnnn nnnn

Busy flag (f ) returns in D7 (1 = Busy), D6:D0 contains address counter value (1 µs)

Write Data

1

0

nnnn nnnn

Data nnnnnnnn written at current DD RAM address (46 µs)

Read Data

1

1

nnnn nnnn

Data nnnnnnnn at current address location in DD RAM is returned (46 µs)

The internal memory configuration of an LCD is dependent upon the particular module. The HDM16216L-5 is a 16x2 display, but its internal data display RAM has 80 total locations with 40 locations mapped to line 1 (addresses 0x00 to 0x27) and 40 locations mapped to line 2 (addresses 0x40 to 0x67). The 16x2 display is a window into these 80 locations, with only 16 characters of each line displayed at any given time, as shown in Figure 8.29. By default, the display shows locations 0x00–0x0F of line 1, and locations 0x40–0x4F of line 2. A left shift moves the display to the right, causing locations 0x01–0x10 to be displayed in line 1, and locations 0x41–0x50 in line 2. This creates the appearance that the displayed line has shifted one position to the left, as the leftmost character

Interfacing to an LCD Module

305

disappears, and the character in column 1 now appears in column 0. Continual left shifting causes the lines to scroll marquee-fashion, moving right to left across the display.

Figure 8.29 LCD data display RAM

An internal address counter determines where the current data write operation places data. The address counter also specifies the cursor location. Initializing the display sets the address counter to zero, placing the cursor to the home position of location 0 (position 0 of line 1, upper-left corner of the display). A write data operation writes data to the current address location, then increments or decrements the address counter depending on the mode setting (entry mode set command in Table 8.4). In increment mode, the address counter is incremented by one and the cursor moves one position to the right on the display. Each additional write places data at the current address counter location, and increments the address counter. Assuming the display is unshifted, the 17th write (to location 16) places data “off-screen” (the data is not visible), but the data is still contained in DD RAM. A right shift of the display has to be performed to see the data contained in location 16. Each LCD command requires a fixed amount of time to execute. The PIC24 μC software communicating with the LCD can either have built-in delays that are guaranteed to exceed the required LCD command execution time, or the LCD can be polled via the read busy flag command to determine if the module is ready for another command. Before sending a command, a polling loop is used to continually read the busy flag status; the loop is exited when the busy flag returns 0. Other commands exist for loading custom character fonts; see the datasheet [34].

306

Chapter 8

■

System Startup and Parallel Port I/O

LCD Code Example Listing 8.1 shows the macros used in the LCD C code to isolate the PIC24 μC port to LCD signal mapping. These correspond to the connections shown in Figure 8.28. Note that _LATBx assignments are used for outputs and _RBx are used for reading inputs. Listing 8.1: LCD Interface Macros #define #define #define #define #define #define #define #define #define

RS_HIGH() RS_LOW() CONFIG_RS() RW_HIGH() RW_LOW() CONFIG_RW() E_HIGH() E_LOW() CONFIG_E()

(_LATB9 = 1) (_LATB9 = 0) CONFIG_RB9_AS_DIG_OUTPUT() (_LATB13 = 1) (_LATB13 = 0) CONFIG_RB13_AS_DIG_OUTPUT() (_LATB14 = 1) (_LATB14 = 0) CONFIG_RB14_AS_DIG_OUTPUT()

#define #define #define #define #define

LCD4O LCD5O LCD6O LCD7O LCD7I

(_LATB5) (_LATB6) (_LATB7) (_LATB8) (_RB8)

#define #define #define #define #define #define #define #define

CONFIG_LCD4_AS_INPUT() CONFIG_LCD5_AS_INPUT() CONFIG_LCD6_AS_INPUT() CONFIG_LCD7_AS_INPUT() CONFIG_LCD4_AS_OUTPUT() CONFIG_LCD5_AS_OUTPUT() CONFIG_LCD6_AS_OUTPUT() CONFIG_LCD7_AS_OUTPUT()

CONFIG_RB5_AS_DIG_INPUT() CONFIG_RB6_AS_DIG_INPUT() CONFIG_RB7_AS_DIG_INPUT() CONFIG_RB8_AS_DIG_INPUT() CONFIG_RB5_AS_DIG_OUTPUT() CONFIG_RB6_AS_DIG_OUTPUT() CONFIG_RB7_AS_DIG_OUTPUT() CONFIG_RB8_AS_DIG_OUTPUT()

#define GET_BUSY_FLAG() (LCD7I)

Listing 8.2 shows some LCD utility functions. The configBusAsOutLCD() function is used to configure the pins used for the LCD D[7:4] as outputs for LCD write operations, while configBusAsInLCD() configures these same pins as inputs for LCD read operations. The outputToBusLCD(uint8_t u8_c) outputs the lower 4 bits of the u8_c argument to the LCD D[7:4] bus. The configControlLCD() function configures the ports used for the E, R/W# and RS signals and initializes them to a logic 0 value.

Interfacing to an LCD Module

Listing 8.2: LCD Utility Functions // Configure 4-bit data bus for output. void configBusAsOutLCD(void) { RW_LOW(); // RW=0 to stop LCD from driving pins CONFIG_LCD4_AS_OUTPUT(); // D4 CONFIG_LCD5_AS_OUTPUT(); // D5 CONFIG_LCD6_AS_OUTPUT(); // D6 CONFIG_LCD7_AS_OUTPUT(); // D7 } // Configure 4-bit data bus for input. void configBusAsInLCD(void) { CONFIG_LCD4_AS_INPUT(); // D4 CONFIG_LCD5_AS_INPUT(); // D5 CONFIG_LCD6_AS_INPUT(); // D6 CONFIG_LCD7_AS_INPUT(); // D7 RW_HIGH(); // R/W = 1, for read } // Output lower 4 bits of u8_c to LCD data lines. void outputToBusLCD(uint8_t u8_c) { LCD4O = u8_c & 0x01; // D4 LCD5O = (u8_c >> 1) & 0x01; // D5 LCD6O = (u8_c >> 2) & 0x01; // D6 LCD7O = (u8_c >> 3) & 0x01; // D7 } // Configure the control lines for the LCD. void configControlLCD(void) { CONFIG_RS(); // RS CONFIG_RW(); // RW CONFIG_E(); // E RW_LOW(); E_LOW(); RS_LOW(); }

307

308

Chapter 8

■

System Startup and Parallel Port I/O

Figure 8.30 shows two functions, pulseE() and writeLCD(), that are used for writing to the LCD using the macros and functions of Listings 8.1 and 8.2. The pulseE() function simply pulses the E signal line high with the DELAY_US(1) function calls providing more than enough delay for the pulse width and setup/hold times about the edges. The writeLCD() function writes one byte of data passed in u8_Cmd to the LCD, assuming a 4-bit interface. If u8_CheckBusy is non-zero, the busy flag is polled until it returns non-zero before performing the write. Observe that in the busy flag loop, the first read returns the upper 4 bits, while the second read returns the lower 4 bits. The busy flag is the MSb of the upper 4-bit transfer. Furthermore, the WDT is enabled during the busy flag polling loop so as to escape this infinite wait if there is a hardware failure (or to detect coding or wiring problems during testing). If u8_CheckBusy is zero, a pessimistic delay of 10 ms is performed before writing the byte instead of using the busy flag. After some commands, such as the function set command, the busy flag cannot be used so a delay must be performed instead. If u8_DataFlag is non-zero, the RS signal is set to 1 during the write; else it is set to 0. Finally, if u8_DataFlag is zero, only the upper 4 bits are written (the initial command that selects the 4-bit interface requires only a single 4-bit transfer as the LCD is in 8-bit mode on power-up). The code in Figure 8.31 uses the writeLCD() function within the outStringLCD(char *psz_s) function to write the psz_s string to the LCD at the current cursor location. The main() code first calls configControlLCD() to configure the PIC24 μC port pins then calls initLCD(), which initializes the display using the commands of Table 8.4. Observe that none of the writeLCD() calls in initLCD() use the busy flag for status checking; instead, the constant delay mode of writeLCD() is used. After initialization, the address counter of the LCD is at location 0. The first outStringLCD() in main() writes to the first line of the LCD. Only the first 16 characters of the string passed to outStringLCD() are visible in the display, even though the entire string is stored in the LCD data display RAM. The following statement writeLCD(0xC0, 0, 1, 1) sets the internal address counter to 0x40 (first position of second line), so that the next outStringLCD() statement writes to the second line of the display. The 0xC0 byte in the writeLCD() function call is the Set DD address command, where 0xC0 = 0b1100000. The format of this command is 1nnnnnnn, where nnnnnnn is the data display address. Thus, the lower 7 bits of 0xC0 is 1000000, or 0x40, the address of the first location on the second line. An infinite loop is then entered in which the statement writeLCD(0x18, 0, 1, 1) is followed by a 0.3 second delay. The 0x18 (0x00011000) command byte is the Cursor & Display Shift command from Table 8.4 and has the format 0001cr00, with c = 1, r = 0 specifying a display left shift. The continual looping of this command causes the strings to scroll across the display moving right to left, with a 0.2 second delay between shifts. More sophisticated LCD modules allow graphical operations, such as turning on/off a pixel specified by an X, Y screen location.

Interfacing to an LCD Module

Figure 8.30 chap08\lcd4bit.c: writeLCD(), pulseE() functions for the LCD interface

309

310

Chapter 8

■

System Startup and Parallel Port I/O

Figure 8.31 chap08\lcd4bit.c: Write two strings to LCD and shift display

The PIC24E versus the PIC24F and PIC24H Families The examples in this chapter have concentrated on the PIC24E family. Devices in the PIC24H and PIC24F families have the following principal differences (other differences exist): ■

■

The PIC24F family has a maximum FCY of 16 MHz; the PIC24H has a maximum FCY of 40 MHz; the PIC24E supports an FCY of 60 MHz over its full temperature range, and 70 MHz for a limited temperature range. The PIC24F family has a PLL with a fixed multiplication factor of 4X; the PIC24H and PIC24E offer a wide range of PLL multiplication factors.

Summary

■

■

■

311

The PIC24F FRC oscillator has a nominal 8.0 MHz frequency versus 7.37 MHz for the PIC24H and PIC24E families. The 8.0 MHz FRC oscillator coupled with the 4X PLL offers a convenient method for achieving the maximum FCY of 16 MHz. The PIC24F family’s configuration bits are stored in two packed words instead of six for the PIC24H and PIC24E families. Approximately the same functionality is offered despite the difference in size. The PIC24E has added new capabilities to several of its peripheral modules (such as the input capture and output compare modules; see Chapter 12) but in all cases has maintained upward compatibility with the PIC24H in terms of module usage.

This book’s examples are compatible with the PIC24E/H/F and dsPIC33E/F families. Built-in compiler macros such as __PIC24E__ and __PIC24H__ have been used to differentiate code between families when needed. While all of the book’s examples have been tested with the dsPIC33EP128GP502 and the PIC24HJ32GP202, many of them have also been tested with the PIC24FJ64GA002, which is a 28-pin PIC24F μC that is pin compatible with the dsPIC33EP128GP502.

Summary Code written in a high-level language (HLL) such as C is usually clearer in its intent, has fewer source lines, and is more portable than code written in assembly language. As such, many microcontroller applications are written in an HLL rather than assembly. However, understanding assembly language and the implementation of HLL constructs in assembly language is critical in writing efficient HLL microcontroller applications. The MPLAB® PIC24 compiler is used for the examples in this book and provides a powerful tool for experimenting with PIC24 applications. A simple PIC24 hardware system with a power source, a reset switch, and serial interface is used to demonstrate the basics of parallel port I/O, reset sources, and power saving modes. A PIC24 μC has many different sources of reset, with status bits in the RCON register used to determine the reset source. Reducing power consumption is an issue in many microcontroller applications, and the sleep, idle, and doze modes in the PIC24 μC can be used to reduce current draw. The watchdog timer runs on an independent clock source, and can be used to wake the PIC24 from sleep and idle modes to resume execution. The PIC24 has multiple parallel port I/O pins with bidirectional transfer capability as well as open-drain and weak pull-up functionality. An LCD module interface in 4-bit mode can be implemented using eight of the parallel port pins on the PIC24.

312

Chapter 8

■

System Startup and Parallel Port I/O

Review Problems Assume that the target device is the dsPIC33EP128GP502 μC for all problems. 1. Give the special function register bit settings that configure RB5 as a digital input, with weak pull-up disabled, and open-drain disabled. 2. Give the special function register bit settings that configure RB6 as a digital output, with weak pull-up disabled, and open-drain enabled. 3. Give the special function register bit settings that configure RB2 as a digital input, with weak pull-up enabled, and open-drain disabled. 4. Give the special function register bit settings that configure RB3 as a digital output, with weak pull-up disabled, and open-drain disabled. 5. Repeat problem 1, but use the macros discussed in this chapter to configure the given pin. 6. Repeat problem 2, but use the macros discussed in this chapter to configure the given pin. 7. Using the data of Table 8.2 for the dsPIC33EP128GP502, predict the doze mode current for FCY/4. 8. Using the data of Table 8.2 for the dsPIC33EP128GP502, predict the doze mode current for FCY/8. 9. For the following code segment, predict what you will see occur once power is applied, and explain your reasoning. int main() { ...normal config, including uart... outString(“Howdy Y’all!\n”); _SWDTEN = 1; while(1); }

10. For the following code segment, predict what you will see occur once power is applied, and explain your reasoning. int main() { ...normal config, including uart... outString(“Howdy Y’all!\n”); if (_POR) { _SWDTEN = 1; _POR = 0; } else { _SWDTEN = 0; } while(1); }

Review Problems

313

11. For the following code segment, predict what you will see occur once power is applied, and explain your reasoning. int main() { ...normal config, including uart... outString(“Howdy Y’all!\n”); asm(“pwrsav #0”); while(1); }

12. For the following code segment, predict what you will see occur once power is applied, and explain your reasoning. int main() { ...normal config, including uart... outString(“Howdy Y’all!\n”); _SWDTEN = 1; asm(“pwrsav #0”); while(1); }

The following problems assume external LEDs (LED1, LED2, and so on) and switches (SW1, SW2, and so on). When writing code for these problems, define macros for them as done in Figure 8.22 using the predefined macros in lib\include\pic24_ports.h. You may use any of the RBn ports you want to implement these problems. Assume switch inputs are pushbutton inputs, and use the internal weak pull-up of the port. 13. Assume one LED (LED1) and one switch input (SW1). Write a while (1) loop that initially will blink an LED1 once power is applied. On each press AND release of SW1, alternate between terminating the blinking and resuming the blinking. Draw a state machine chart for the problem, and implement it using the style of Figure 8.24. 14. Assume two LEDs (LED1, LED2) and one switch input (SW1). Both LEDs should be initially off. After each press AND release of SW1, change the LED state (LED1/LED2) in the sequence: OFF/ON, ON/OFF, ON/ON, OFF/OFF, OFF/ON, ON/OFF, ON/ON, OFF/OFF, and so on. Draw a state machine chart for the problem, and implement it using the style of Figure 8.24. 15. Do problem #14, except the LEDs change state whenever a press OR a release occurs for SW1. 16. Do problem #13, except the blinking terminates or resumes whenever a press OR a release occurs for SW1.

314

Chapter 8

■

System Startup and Parallel Port I/O

For Figure 8.32, assume that macros named DFF_D, DFF_CK, DFF_R, DFF_S, and DFF_Q have been defined for the RB? pins connected to the external D flip-flop (refer to Chapter 1 for a review of D flip-flop operation).

Figure 8.32 PIC24 µC to D flip-flop

17. Write a C function named uint8_t testDFFASync(uint8_t u8_op) that asynchronously resets the DFF if u8_op is non-zero, else an asynchronous set is performed. The function should return a true (non-zero uint8_t value) if the Q output returns the correct output value, else return a false value (zero). Assume nothing about the initial output states of the RB? ports when entering the function (you may assume that they have already been configured to be inputs or outputs as appropriate). When exiting the function, all outputs should be at their negated values (D, CK at 0; S, R at 1). For emphasis purposes only, use a 1 μs software delay to satisfy pulse width times, setup/hold times for the D input with regard to the clock, and propagation delay through the DFF once the inputs have been applied. 18. Write a C function named uint8_t testDFFSync(uint8_t u8_dval) that synchronously clocks in a 1 to the DFF from the D input if u8_dval is non-zero, and a 0 otherwise. The function should return a true (non-zero uint8_t value) if the Q output returns the correct output value, else return a false value (zero). Assume nothing about the initial output states of the RB? ports when entering the function (you may assume that they have already been configured to be inputs or outputs as appropriate). When exiting the function, all outputs should be at their negated values (D, CK at 0; S, R at 1). For emphasis purposes only, use a 1 μs software delay to satisfy pulse width times, setup/hold times for the D input with regard to the clock, and propagation delay through the DFF once the inputs have been applied.

Review Problems

315

For Figure 8.33, assume that macros named GATE_A, GATE_B, and GATE_Y have been defined for the RB? pins connected to the external NAND gate (refer to Chapter 1 for a review of the NAND operation).

Figure 8.33 PIC24 µC to NAND gate

19. Write a C function named uint8_t testGate(void) that exhaustively applies all input combinations to the external gate. If the gate output returns the wrong output value for an input combination, terminate the test and return a false (zero) value. If the gate returns the correct output value for all input combinations, then return a true (non-zero uint8_t value). Assume nothing about the initial output states of the RB? ports when entering the function (you may assume that they have already been configured to be inputs or outputs as appropriate). For emphasis purposes only, use a 1 μs software delay before reading the Y output after applying an input combination. 20. Repeat problem #19 except use an XOR gate as the external gate.

This page intentionally left blank

Chapter 9

Interrupts and a First Look at Timers

T

his chapter discusses interrupts, which are of critical importance when implementing efficient input/output operations for microcontroller applications. Topics include interrupt fundamentals, PIC24 μC interrupt sources, and an introduction to using interrupts for accomplishing I/O. A first look at the powerful timer subsystem of the PIC24 μC uses a timer as a periodic interrupt source.

Learning Objectives After reading this chapter, you will be able to: ■

■ ■ ■ ■ ■

■ ■

Discuss the general function of interrupts within a microprocessor and interrupt implementation on the PIC24 μC. Describe the difference between polled I/O and interrupt-driven I/O. Implement an interrupt service routine in C for the PIC24 μC. Implement an interrupt service routine using a state machine approach. Implement interrupt service routines that use the change notification and INTx interrupts. Discuss the structure of the PIC24 μC Timer2 and Timer3 subsystems and use them to generate periodic interrupts for input sampling. Implement an interface for a rotary encoder. Implement an interface for a keypad.

317

318

Chapter 9

■

Interrupts and a First Look at Timers

Interrupt Basics An interrupt in a microprocessor is a forced deviation from normal program flow by an external or internal event. On the PIC24 μC there are many possible internal and external events such as rising or falling edges on external pins, arrival of serial data, timer expiration, and so forth that can cause interrupts. Figure 9.1 illustrates what happens when an interrupt occurs on the PIC24 μC. During normal program flow, assume some external or internal event triggers an interrupt. After the current instruction is finished, the CPU interrupt priority level (discussed later), lower byte of the status register, the stack frame active bit, and the return address are pushed on the stack. The CPU interrupt priority level is then set to the priority level of the pending interrupt, and the PC is set to a predetermined location based on the pending interrupt called the interrupt vector, thus causing execution to continue at that point. After executing code to handle the interrupt, a retfie (return from interrupt) instruction is executed to return to normal program flow. The code that is executed when the interrupt occurs is referred to as the interrupt service routine (ISR). The ISR’s function is to respond to whatever event triggered the interrupt. As an example, if the interrupt was triggered by the arrival of serial input data, the ISR would read the data, save it, then return. When viewing Figure 9.1, it is tempting to think of the ISR as a subroutine that is called by the main() program. However, the ISR is never manually called as a normal C function is called; instead, the ISR is invoked automatically by the PIC24 μC interrupt hardware on an interrupt occurrence. An ISR is said to execute in the background, while the normal program flow executes in the foreground. This book informally refers to background code as ISR code execution and foreground code as main() code execution. Saving the processor context in the ISR of Figure 9.1 means to save registers used by the ISR since these same registers can be used by the foreground code. An ISR can call other subroutines, and, in fact, can call a subroutine that has been interrupted. If a subroutine is interrupted, then called from the ISR, the subroutine has been reentered (a reentrant subroutine). For correct execution, a reentrant subroutine must use dynamic allocation for locals and parameters, and the ISR must save the processor context. An ISR can itself be interrupted as is discussed later, so generally the processor context is saved to the stack (dynamic allocation is used for the processor context). You may question at this point why an interrupt capability is desirable. The I/O examples presented in the last chapter use a technique referred to as polling, where a status flag is checked repeatedly to determine data availability. This is referred to as polled I/O and is usually an inefficient method for implementing I/O operations. Imagine if your cell phone operated on the polled I/O principle. This would mean that you would occasionally have to pull it out of your pocket or purse, open it, and ask “Hello, is there anybody there?” This may seem laughable, but this is how we have been accomplishing I/O to this point. The problem with this approach is obvious—either you check your phone too often, which wastes your time, or you do not check it often enough, causing you to miss an important call. It is much more efficient to have the phone notify you of an incoming call.

Interrupt Basics

319

The ringer on your cell phone implements an interrupt; when the ringer sounds, you stop what you are doing and answer the phone, thus servicing the interrupt. When finished with the call, you then resume what you were doing earlier. This is known as interrupt-driven I/O. On the PIC24 μC, each interrupt source has an associated interrupt flag bit that becomes a 1 when the interrupt source event occurs. As an example, the U1RXIF bit is the receive character interrupt flag and becomes a 1 when asynchronous serial data is available over the RX serial pin. Most interrupt flag bits are contained in special function registers named the interrupt flag status (IFS) registers. Continuing the cell phone analogy, there are times when you do not want to answer the phone, like in a meeting or a movie theatre. At these times, you turn off the ringer, causing incoming calls to be ignored. On the PIC24 μC, most interrupt sources have an interrupt enable bit that must be a 1 in order for an interrupt to be invoked when the interrupt flag bit becomes a 1. If the interrupt enable bit is 0, the interrupt is masked or disabled. For example, the U1RXIE bit (receive character interrupt enable) is the interrupt enable for the U1RXIF interrupt. Most interrupt enable bits are contained in special function registers named the interrupt enable control (IEC) registers. It is important to understand that the interrupt enable bit being a 0 does not prevent the interrupt flag bit from becoming a 1, just like turning off the phone ringer does not prevent incoming phone calls from arriving. A 0 interrupt enable bit only prevents an interrupt from being generated; in other words, it prevents a jump to the ISR. Some interrupts on the PIC24 μC are non-maskable, which means that you cannot block the automatic jump to the ISR when the interrupt occurs (for example, a fire alarm can be considered a non-maskable interrupt as it is never disabled).

Figure 9.1 Interrupting normal program flow

320

Chapter 9

■

Interrupts and a First Look at Timers

At the risk of overusing the cell phone analogy, assume you are talking on the phone with a friend and that you are notified via call-waiting of an incoming call from your spouse, significant other, or other family member. You may say something like “Hold for a moment, there is an incoming call that I need to check,” and then switch to the other call. This means that the incoming call has a higher priority than the current call. On the PIC24 μC, each interrupt source has an interrupt priority level (IPL) associated with it. This interrupt priority level ranges from 0 to 15 and allows interrupts of a higher priority to interrupt lower-priority ISR code. Interrupt priorities are discussed in detail in the next section.

PIC24 µC Interrupt Details This section discusses PIC24 μC details such as the interrupt vector table, priority system, and the difference between traps and peripheral interrupts.

Vector Table When an enabled interrupt occurs, the PIC24 μC fetches the ISR starting address for that interrupt from the interrupt vector address assigned to that interrupt. The interrupt vector addresses are stored in a group of program memory locations known as the interrupt vector table (IVT), which is shown in Figure 9.2. These locations along with the reset vector occupy locations 0x000004 through 0x0001FF, with user code starting at location 0x000200.

Figure 9.2 Interrupt vector table Source: Figure redrawn by author from Figure 6.1 of the PIC24E FRM datasheet (DS70600C), Microchip Technology, Inc.

PIC24 µC Interrupt Details

321

The number of interrupt sources on a PIC24 μC depends on the on-chip peripherals that are implemented for that particular microcontroller. Figure 9.3 shows common interrupt sources on the dsPIC33EP128GP502 which are discussed in this book; the processor supports many additional interrupts. The “Vector Num” column gives the value written to the lower seven bits of the special function register INTTREG (INTTREG) for the currently executing interrupt, with bits INTTREG containing the interrupt’s priority. (Note: The INTTREG register is not present in the PIC24F family.) The PIC24 “Compiler Name” column gives the C function name that must be used with the PIC24 compiler when writing an ISR for that particular interrupt.

Figure 9.3 Selected dsPIC33EP128GP502 interrupt sources

322

Chapter 9

■

Interrupts and a First Look at Timers

Interrupt Priorities As mentioned previously, the PIC24 μC implements an interrupt priority system with values from 0 (lowest) through 15 (highest). Interrupt priorities 8 through 15 are reserved for a special class of interrupt sources known as traps (vector numbers 1 through 5) with each interrupt priority level assigned to a single trap source. Priorities 0 through 7 are used for non-trap interrupt sources (user interrupts), with each user interrupt source assigned a 3-bit field in a special function register that contains the interrupt’s priority level. These interrupt priority level bits are contained in a set of special function registers known as the interrupt priority control (IPC) registers. The current CPU interrupt priority level is a 4-bit value (IPL), with these bits split between two special function registers: IPL bits are in the status register (SR), while IPL is contained in the core control register (CORCON). The IPL bits are cleared at reset, which means that any enabled interrupt with priority level 1 or higher can interrupt the processor. Bits IPL are writeable, but bit IPL can only be cleared by user code (the IPL bit is set when any trap occurs, because trap priorities are 8 and higher). When an enabled interrupt occurs, the interrupt’s priority level must be higher than the current IPL bits to be recognized. If simultaneous interrupts with the same priority level occur, then the interrupt with the lower vector number is recognized first. Before the ISR is executed, the current IPL bits are saved on the stack along with the return address then the IPL bits are set to the priority level of the recognized interrupt. This disables any further interrupts within the ISR caused by interrupts with that priority level. Interrupts of a higher priority can interrupt the ISR. If an ISR is interrupted by another interrupt, this is called interrupt nesting, which can be disabled by setting the interrupt nesting disable bit (NSTDIS, in INTCON1) to a one (_NSTDIS=1). When interrupt nesting is disabled, any user-level interrupt sets the CPU IPL to 7, disabling any further userlevel interrupts. Furthermore, the IPL bits become read-only and the assigned priority levels for individual interrupts are only used to resolve simultaneous interrupts. Setting a user interrupt priority to level 0 disables that interrupt even if its interrupt enable bit is set, because the priority level is not greater than the lowest CPU priority level of 0. Setting the IPL bits to 7 disables all user interrupts. The DISI #lit14 instruction (disable interrupts temporarily) can be used to disable user interrupts with priorities 1 through 6 for #lit14 + 1 instruction cycles. This is useful for protecting critical code sections from user interrupts, which is done in the configClock() function when the clock source is being changed.

Traps A special type of interrupt source on the PIC24 μC are traps, which are internally generated, nonmaskable interrupts that immediately halt instruction execution (hard traps) or that allow a few additional instruction to execute before jumping to the ISR (soft traps). Soft trap sources include a DMA conflict write, math error (divide by zero), and stack error (triggers include the stack pointer

PIC24 µC Interrupt Details

323

falling below 0x1000 or becoming greater than the SPLIM register). Hard trap sources include oscillator failure (which occurs if the fail-safe clock monitor detects a problem or if the PLL loses lock) and address error (caused by a misaligned access or a jump or branch to unimplemented program space). Complete details on the trap error sources are given in [14]. Table 9.1 summarizes the trap error sources.

Table 9.1: Trap Summary Trap

Category

Priority

Flag(s)

Oscillator Failure

Hard

14

_OSCFAIL (oscillator fail, INTCON1), _CF (clock fail, OSCCON)

Address Error

Hard

13

_ADDRERR (address error, INTCON1)

Stack Error

Soft

12

_STKERR (stack error, INTCON1)

Math Error

Soft

11

_MATHERR (math error, INTCON1)

DMAC Error

Soft

10

_DMACERR (DMA conflict write, INTCON1)

Interrupt Latency Interrupt latency is the amount of time from when an interrupt occurs to when the interrupt source is handled. In the cell phone analogy, this is the amount of time from when the phone rings until you say “Hello.” In many cases reducing interrupt latency is important; as in the cell phone analogy, if you wait too long to answer the phone, the person calling may give up and terminate the call. Interrupt latency consists of two parts: (1) the time from when the interrupt occurs until the first instruction of the ISR is handled, and (2) the number of instructions executed in the ISR before the interrupt source is acknowledged. When an interrupt occurs, the interrupted instruction completes, then the processor takes fourteen clock cycles on the PIC24E/dsPIC33E before the first instruction of the ISR is executed. The interrupt latency for a two-cycle instruction is also 14 clocks to the first instruction of the ISR, regardless of whether the interrupt occurs in the first or second cycle of the instruction [29]. Once the ISR has begun execution, the latency until the interrupt is serviced depends on how much of the processor state has to be saved within the ISR. A complex ISR may require many working registers to be pushed on the stack at entry to the ISR. The push.s (push shadow registers) instruction that saves W0, W1, W2, W3, and the status register to the stack can help reduce the number of clocks required to save the processor context. There is only one set of shadow registers so an ISR that uses the shadow registers cannot be interrupted by a higher priority interrupt that also uses the shadow registers, or else the values saved to the shadow registers may be corrupted.

324

Chapter 9

■

Interrupts and a First Look at Timers

Return from interrupt timing consists of two instruction cycles for the retfie instruction plus five instruction cycles on the PIC24E/dsPIC33E to fetch the instruction at the return address; the instruction at the return address is executed on the eighth instruction cycle counting from retfie start.

ISR Overhead A concern in interrupt processing is the percentage of the CPU’s execution time spent in interrupt service routines. The following definitions will help you compute this percentage. ■

■ ■

■ ■

IENTRY: Number of instruction cycles for ISR entry (fourteen on the PIC24E/dsPIC33E μC; four on the PIC24F/H and dsPIC33F). IBODY: Number of instruction cycles for the ISR body (not including retfie). IEXIT: Number of instruction cycles for ISR exit (seven on the PIC24E/dsPIC33E μC; three on the PIC24F/H and dsPIC33F). FISR: Frequency (number of times per second) at which the ISR is triggered. TISR: The ISR triggering period, which is 1/FISR. For example, if an ISR is executed at 1 KHz, TISR is 1 ms.

Using these definitions, Equation 9.1 shows the percentage of a PIC24 μC’s instruction cycles consumed by an interrupt service routine: ISR% = [(IENTRY + IBODY + IEXIT) ↔ FISR]/FCY ↔ 100%

(9.1)

In Equation 9.1, the numerator is the number of ISR instructions executed in 1 second, while the denominator (FCY) is the total number of instructions executed in 1 second. Table 9.2 shows the CPU% for FCY = 60 MHz assuming an ISR body of 50 instruction cycles for varying ISR periods.

Table 9.2: ISR CPU Percentage for FCY = 60 MHz ISR% (IBODY = 50)

TISR = 10 ms

TISR = 1 ms

TISR = 100 µs

TISR = 10 µs

0.0118%

0.118%

1.18%

11.8%

The two key variables in Equation 9.1 are IBODY and FISR, as increasing either one increases the CPU time percentage consumed by the ISR. The FISR variable is set by the I/O constraints of the device being serviced by the interrupt, so only IBODY is under direct control by the application programmer. A golden rule for writing interrupt service routines is to keep an ISR as short as possible to reduce its impact on available CPU time. Furthermore, execution of an active ISR blocks the execution of other pending interrupts with the same priority, increasing the latency of those interrupts. Ideally, an ISR should service the interrupt, which generally means performing some input/output action, set one or more lags indicating to the foreground task that the interrupt occurred, then return.

ISR Functions in C

325

ISR Functions in C To create an interrupt service routine (ISR) in C, first consider a simple ISR to handle the math error trap: void _ISR _MathError(void) { ... code for ISR ... }

This ISR illustrates the essential ingredients for declaring an ISR in C: ■

■

■

The function must be named based on which ISR it handles, where the column labeled as PIC24 “Compiler Name” in Figure 9.3 gives the ISR function name to be used when writing an ISR for that particular interrupt. In this case, the function’s name _MathError indicates that it handles the math error soft trap. The function must take no parameters and return no value, denoted by the use of void functionName(void). The function must be declared with the _ISR attribute to inform the compiler to save and restore registers as shown in Figure 9.1 and to return by using a retfie instruction. Additional information on _ISR is provided later in this chapter.

The Default Interrupt The default interrupt handler provides a more complete example of interrupt handling. When no ISR is defined for an interrupt, the PIC24 compiler generates an ISR function named _DefaultInterrupt() that contains only a software reset. However, the _DefaultInterrupt() function can be overridden by the user if desired. Figure 9.4 shows the version of the _DefaultInterrupt() function contained in lib\src\pic24_util.c. As stated, observe that the _ISR macro must be used before the function name to identify this function to the PIC24 compiler as an interrupt service routine so that the compiler can generate appropriate code to save/restore registers within the ISR and to instruct the compiler to use a retfie instruction to return. The _DefaultInterrupt() function saves the contents of the INTTREG register into a persistent variable named u16_INTTREGlast; this is done because INTTREG identifies the priority and vector number of the interrupt (this register is not available in the PIC24F family). The reportError(const char *sz_errorMessage) function is then called, which saves sz_errorMessage in a persistent variable named sz_lastError, then executes a software reset. After the software reset, the printResetCause() function then prints the contents of sz_lastError if it is non-null and also the contents of the u16_INTTREGBITSlast variable if it is nonzero, thus identifying the reset source that triggered this processor reset. Figure 9.4(b) shows a program memory dump from MPLAB. Observe that all interrupt vectors have the address of _DefaultInterrupt by default.

326

Chapter 9

■

Interrupts and a First Look at Timers

Figure 9.4 Custom _DefaultInterrupt() ISR

Figure 9.5(a) shows a program that tests the _DefaultInterrupt() ISR by purposefully generating a math error trap. This is done by initializing the variable u8_zero to 0, then executing u8_zero = 1/u8_zero, which generates a divide-by-zero math error trap. The u8_zero variable is declared as volatile,

ISR Functions in C

327

which means that this memory location can be modified between instruction accesses and thus disables certain compiler optimizations. If a normal variable is used, then the compiler will optimize away this seemingly useless C statement.

Figure 9.5 chap09\trap_test.c: testing the _DefaultInterrupt() ISR with a math error trap

Figure 9.5(b) shows the console output generated by the code in Figure 9.5(a); observe that when a key is pressed, the while(1) loop is entered and the math error trap is generated. The priority (0x0B, 11) and vector number (0x04) output by printResetCause() match the priority in Table 9.1 and vector number in Figure 9.3.

An Example ISR Figure 9.6(a) shows an ISR written for the math error trap; this code would be used in the source of Figure 9.5 to handle the math error trap instead of the _DefaultInterrupt() function. The function named _MathError() is used to indicate that this ISR is for the math error trap; observe that the MPLAB program memory dump in Figure 9.6(c) now shows this function address inserted in the interrupt

328

Chapter 9

■

Interrupts and a First Look at Timers

vector table address 0x00000C that is used for the math error trap. The _MathError() code is the simplest possible ISR as all it does is clear the conditions associated with the interrupt source. In this case, the _MATHERR flag must be cleared as it is the flag that triggered the interrupt, or else the processor becomes hung in an infinite loop because each time the ISR is exited, it immediately re-enters the ISR.

Figure 9.6 chap09\trap_test_handled.c: a _MathError ISR

Change Notification Interrupts

329

The RCOUNT register is also cleared to escape the divide repeat loop faster (the divide repeat loop would eventually be escaped but multiple divide-by-zero trap errors would be generated by the same divide instruction as the RCOUNT register is decremented each time the ISR returns to the divide instruction). Figure 9.6(a) shows the assembly code generated by the PIC24 compiler for the _MathError ISR. The _ISR macro specifies the auto_psv attribute, which instructs the compiler that the ISR function may want to access data stored in program memory through the program visibility space, so the DSRPAG register is saved on the stack and then set to a value appropriate for this ISR’s location in program memory. The _ISRFAST macro used in Figure 9.6(b) specifies the _no_auto_psv attribute, which instructs the compiler that this ISR does not use the program visibility space, so the DSRPAG register does not have to be modified. This reduces the assembly code size and reduces the latency for the ISR. The code examples use the safer _ISR macro unless speed is necessary.

Change Notification Interrupts The first user interrupt source covered here is the input change notification interrupt, which is generated from a change of state on one or more change notification (CN) pins. Figure 9.7 shows a conceptual block diagram of the system. Each CNx input has an individual interrupt enable named CNIExy. If one or more CNIExy bits are a 1, then any state change on an enabled CNIExy input causes the change notification interrupt flag (CNIF) to be set. The weak pull-up/pull-down on each CNIExy pin can be optionally enabled, as discussed in Chapter 8.

Figure 9.7 Input change notification block diagram Source: Figure redrawn by author from Figure 10.6 found in the dsPIC33E/PIC24E Family Reference Manual, section 10: I/O ports (DS70000598C), Microchip Technology, Inc.

330

Chapter 9

■

Interrupts and a First Look at Timers

Wake from Sleep/Idle The change notification interrupt can be used to wake the processor from sleep or idle mode. The code given in Figure 9.8 assumes the pushbutton switch PB is attached to port RB13. The config_pb() function configures RB13 as a digital input, enables the change notification pull-up (ENABLE_RB13_PULLUP()), delays to give the pull-up time to bring the pin’s voltage up to VDD, and enables the individual change notification interrupt (ENABLE_RB13_CN_INTERRUPT()). The ENABLE_RB13_CN_INTERRUPT() is a one-line macro that maps to the statement _CNIEB13 = 1. Before the while (1) loop is entered, the change notification interrupt flag is cleared, (_CNIF = 0), the change notification priority is assigned (_CNIP = 2), and the global change notification interrupt enable is set (_CNIE = 1). When enabling interrupts, it is important to clear the associated interrupt flag before the interrupt is enabled to avoid an immediate jump to the ISR. Remember that the interrupt enable does not prevent the interrupt flag from being set; it only prevents the jump to the ISR. Using priority level 2 for this interrupt is arbitrary; the only requirement is that it is greater than 0 so that the interrupt is recognized and a jump to the ISR is made when the interrupt occurs. In the while (1) loop, a message is printed then the SLEEP() macro (mapped to asm(“pwrsav #0”)) is used to put the processor to sleep. Pressing the pushbutton generates a change notification interrupt, waking the processor and causing a jump to the _CNInterrupt() ISR, which clears the change notification interrupt flag (_CNIF = 0). Upon ISR return, execution resumes in the while (1) body. Two change notification interrupts are generated for each press and release of the switch: one for the press and one for the release.

Using a Change Notification Interrupt to Measure Interrupt Latency Figure 9.9(a) shows code for an experiment used to measure interrupt latency using a change notification interrupt. Pin RB2 is used as an output and an input to generate a change notification interrupt. The while (1) loop in main consists of _LATB2 = 1 to generate the interrupt; the two following nop instructions cause a two TCY period delay so that the interrupt is recognized during the bra instruction at the bottom of the loop. A change notification requires a minimum pulse width of two TCY periods to be recognized according to the datasheet [31]. The change notification interrupt causes transfer of control to the _CNInterrupt ISR, which clears RB2 (_LATB2 = 0). The three nop instructions in the ISR are used to provide delay for the change in RB2 status to propagate through the change notification logic before the CNIF flag is cleared and the ISR is exited. The ISR returns to the _LATB2 = 1 operation (bset) in the while (1) loop, causing the cycle to repeat.

Change Notification Interrupts

331

Figure 9.8 chap09\change_wakeup.c: using the change notification interrupt to wake from sleep

Figure 9.9(b) shows the repeating square wave on the RB2 pin caused by repeatedly bouncing between the while (1) loop and the _CNInterrupt() ISR. Both the high and low periods are eight TCY periods. This experiment was run with a slow FCY (4 MHz) so that the output port delay was small with regard to TCY; if you try this with a fast FCY such as 60 MHz you may get different results because of the variation as to where the interrupt occurs within TCY for an instruction.

332

Chapter 9

■

Interrupts and a First Look at Timers

Figure 9.9 chap09\change_latency.c: using the change notification interrupt to measure interrupt latency

INTx External Interrupts and Remappable Pins The INTx interrupt inputs are another interrupt source on the PIC24 μC and set their corresponding interrupt flags (INTxIF) on either a rising or falling edge transition as determined by their corresponding edge polarity select bit (INTxEP = 1 selects falling edges while INTxEP = 0 selects rising edges). Most PIC24 microcontrollers implement three INTx interrupt inputs (INT0, INT1, INT2). The PIC24 pin diagram of Figure 8.2 shows that INT0 is assigned pin 16 but that the INT1/INT2 inputs are not assigned to any pins. To expose this functionality, these pins must be

INTx External Interrupts and Remappable Pins

333

mapped to an external pin. Internal pin functions such as INT1/INT2 on some PIC24 microcontrollers can be assigned to external remappable I/O pins (the RPn pins in Figure 8.2) or to external remappable input-only pins (RPIn pins in Figure 8.2), which means that special function register bits control how these internal pins are mapped to external pins. The number of RPn and RPIn pins varies by processor, and some PIC24 processors lack remappable pins altogether. Table 9.3 shows some of the remappable function inputs on the dsPIC33EP128GP502. To assign one of these input functions to an external RPn/RPIn pin, the function’s RPn/RPIn selection bits shown in column 3 are assigned the value n. The input function’s RPn/RPIn selection bits are actually multiplexor select bits that steer an RPn/RPIn input to the input function pin. After reset, these RPn/RPIn selection bits are zero, which means the input is not assigned to any RPn/RPIn pin. As an example, the following statement steers pin RP38, located on port RB6, to the INT1 input function: _INT1R = 38;

// Assign INT1 to pin RP38/RB6.

The code uses a macro to accomplish this (defined in lib\include\pic24_ports.h): CONFIG_INT1_TO_RP(RB6_RP);

The value RB6_RP stands for “the remappable pin located on port RB6,” which in this case is RP38. The mapping between RP numbering and Rxy numbering varies widely across different PIC24 devices; using these values simplifies the code and allows it to work for many different processors. In order to correctly use a remappable input, be sure to configure that pin as a digital input using CONFIG_Rxy_AS_DIG_INPUT(). For example, the complete code for mapping INT1 to RB6 is: CONFIG_RB6_AS_DIG_INPUT(); CONFIG_INT1_TO_RP(RB6_RP);

Table 9.3: Selected Remappable Inputs for the dsPIC33EP128GP502 Input Name

Function Name

Example Assignment to RPn

External Interrupt 1

INT1

_INT1R = n;

External Interrupt 2

INT2

_INT2R = n;

Timer2 External Clock

T2CK

_T2CKR = n;

Input Capture 1

IC1

_IC1R = n;

Input Capture 2

IC2

_IC2R = n;

Input Capture 3

IC3

_IC3R = n;

Input Capture 4

IC4

_IC4R = n;

Output Compare Fault A

OCFA

_OCFAR = n;

UART1 Receive

U1RX

_U1RXR = n;

334

Chapter 9

■

Interrupts and a First Look at Timers

Table 9.3: Selected Remappable Inputs for the dsPIC33EP128GP502

(continued)

Input Name

Function Name

Example Assignment to RPn

UART2 Receive

U2RX

_U2RXR = n;

SPI2 Data Input

SDI2

_SDI2R = n;

SPI2 Clock Input

SCK2

_SCK2R = n;

SPI1 Slave Select Input

SS1

_SS2R = n;

Table 9.4 shows some of the remappable output functions for the dsPIC33EP128GP502. Remappable outputs may only use RPn pins, but not the RPIn pins, because these only support remappable inputs. Each remappable pin RPn is assigned a 5-bit field named RPnR; the value of this bit field controls the output function that is mapped to it. Each RPnR bit field contains the selection bits for a multiplexor that steers an output pin function to its associated RPn pin. After reset, each RPnR bit field is zero which means that no output function assignment is made. The following statement steers the U1TX output to the RP43 pin, which is shared with RB11: _RP43R = 1;

// Assign U1TX (which is function code 1) to RP43R.

The code examples use a macro to accomplish this (defined in lib\include\pic24_ports.h): CONFIG_U1TX_TO_RP(RB11_RP);

To prepare a remappable output for use, be sure to configure it as a digital output using CONFIG_Rxy_AS_DIG_OUTPUT(). The RPn configuration bits for both input and output mapping can be protected from writes by the IOLOCK bit (OSCCON). At reset, IOLOCK is cleared, which allows unlimited writes to the RPn configuration bits. Setting IOLOCK prevents further writes to the RPn configuration bits. The purpose of the IOLOCK bit is to prevent accidental reconfiguration of the I/O pins, which could be disastrous in a production system. The suggested use of the IOLOCK bit is to perform all pin configuration and then set the IOLOCK bit. The code examples are intended for experimentation purposes, and thus do not change the IOLOCK from its default state of zero. Note that the __builtin_write_OSCCONL function must be used to write the OSCCON register since an unlock sequence is required when writing to this register. The IOL1WAY bit in the configuration registers (see [27]) offers an additional level of protection against reconfiguration. The default (unprogrammed) state for IOL1WAY, which corresponds to the IOL1WAY = ON setting, prevents IOLOCK from being cleared once it is set. This means that the configuration bits cannot be changed after the IOLOCK bit is set. The default configuration bits in lib\src\pic24_configbits.c use the IOL1WAY = OFF setting, which allows normal setting/clearing of the IOLOCK bit.

INTx External Interrupts and Remappable Pins

335

Table 9.4: Selected Remappable Outputs for the dsPIC33EP128GP502 Output Name

Function Name

RPnR Value

Example Assignment to RPn

Default Port Pin

NULL

0

_RPnR = 0;

UART1 Transmit

U1TX

1

_RPnR = 1;

UART2 Transmit

U2TX

3

_RPnR = 3;

SPI2 Data Output

SDO2

8

_RPnR = 8;

SPI2 Clock Output

SCK2

9

_RPnR = 9;

SPI2 Slave Select Output

SS2

10

_RPnR = 10;

Output Compare 1

OC1

16

_RPnR = 16;

Output Compare 2

OC2

17

_RPnR = 17;

Output Compare 3

OC3

18

_RPnR = 18;

Output Compare 4

OC4

19

_RPnR = 19;

Returning to the subject of INT0/INT1/INT2 external interrupts, Listing 9.1 shows the code in Figure 9.8 modified to use INT1 for waking from sleep mode. Either a negative (falling) or a positive (rising) edge can be selected to wake the processor; the code uses a negative edge via the statement _INT1EP = 1. The CONFIG_INT1_TO_RP(RB13_RP) macro is used to steer the RB13 pin to the INT1 interrupt. Listing 9.1: chap09\int0_wakeup.c: Using INT1 to Wake from Sleep Mode // Interrupt Service Routine for INT1 void _ISR _INT1Interrupt(void) { _INT1IF = 0; //clear the interrupt bit } // Pushbutton configuration, uses RB13. void config_pb(void) { CONFIG_RB13_AS_DIG_INPUT(); //use RB13 for switch input ENABLE_RB13_PULLUP(); //enable the pull-up DELAY_US(1); // Wait for pull-up } int main(void) { configBasic(HELLO_MSG); /** Configure the switch ***********/ config_pb(); CONFIG_INT1_TO_RP(RB13_RP);

336

Chapter 9

■

Interrupts and a First Look at Timers

/** Configure INT1 interrupt */ _INT1IF = 0; //Clear the interrupt flag _INT1IP = 2; //Choose a priority _INT1EP = 1; //negative edge triggered _INT1IE = 1; //enable INT1 interrupt while (1) { outString(“Entering Sleep mode, press button to wake.\n”); //finish sending characters before sleeping WAIT_UNTIL_TRANSMIT_COMPLETE_UART1(); SLEEP(); //macro for asm(“pwrsav #0”) } }

Switch Inputs and Change Notification/INTx Interrupts It is tempting to use either the change notification or INTx interrupts for processing switch input events. However, writing code to correctly handle the multiple interrupt flag events caused by mechanical switch bounce is problematic. Timers provide an interrupt-centric way to wait until switch bounce ceases, then trigger an interrupt to update the state in a state machine. The change notification and INTx interrupts can only be directly applied to signal sources that have clean transitions, such as those produced by an external integrated circuit.

Periodic Timer Interrupts Other user interrupt sources available on the PIC24 include various timer interrupts. Recall from Chapter 8 that a timer is simply a counter, with elapsed time computed as shown in Equation 9.2, where TTMR is the timer clock period and Ticks is the number of elapsed timer counts. Time = Ticks ↔ TTMR

(9.2)

There are multiple timers available on the PIC24, some of which are special-purpose timers such as the watchdog and power-on reset timers while others are general-purpose such as Timers 1 through 5. This chapter discusses the use of Timer2 and Timer3 for generating periodic interrupts, with full coverage of timers reserved for Chapter 12. Timer2 and Timer3 are two general-purpose timers that can either act as separate 16-bit timers or be combined into one 32-bit timer named Timer2/3. Other PIC24 family members have additional paired timers numbered Timer4/5, Timer 6/7, and so on; these paired timers have the same functionality as Timer2/3. From the Timer2 block diagram of Figure 9.10, note that the timer can be clocked by either an external clock on the T2CK pin or from the internal clock (TCY). The prescaler for the Timer2 clock has four settings of 1:1, 1:8, 1:64, and 1:256. This chapter’s applications always uses the internal clock source (TGATE = 0, TCS = 0). In this mode, the Timer2 interrupt flag (T2IF)

Periodic Timer Interrupts

337

is set whenever the Timer2 register (TMR2) contents are equal to the Timer2 period register (PR2) contents, which also resets TMR2 to 0. Note: The diagram in Figure 9.10 comes from the older but clearer PIC24H datasheets; see Figure 11.2 of [19].

Figure 9.10 Timer2 block diagram Source: Figure redrawn by author from Figure 11.2 found in the PIC24H32GP202 datasheet (DS70289B), Microchip Technology, Inc.

The time between TMR2 resets is known as the Timer2 timeout period (TT2IF) and is calculated as shown in Equation 9.3 (recall that TCY is equal to 1/FCY): TT2IF = (PR2+1) ↔ PRE ↔ TCY = (PR2+1) ↔ PRE/FCY

(9.3)

Table 9.5 shows minimum and maximum TT2IF periods for FCY = 60 MHz. The minimum timeout period is also the timer accuracy, which decreases with larger prescaler values. The 32-bit Timer2/3 mode is useful for longer timeout periods.

Table 9.5: Timer2 Min/Max Timeouts for FCY = 60 MHz PRE=1

PRE=8

PRE=64

PRE=256

Min. Timeout (PR2 = 0)

16.7 ns

133 ns

1067 ns

4267 ns

Max. Timeout (PR2 = 0xFFFF = 65535)

1.09 ms

8.74 ms

70.0 ms

280 ms

Max. Timeout (32-bit mode)

71.6 s

573 s

4581 s

18325 s

338

Chapter 9

■

Interrupts and a First Look at Timers

Figure 9.11 gives detailed information on the Timer2 configuration (T2CON) register that contains the control bits shown in Figure 9.10. This chapter uses the internal clock and 16-bit mode for Timer2, which means bit settings of T32 = 0, TCS = 0, and TGATE = 0 (timers are discussed further in Chapter 12). The Timer3 block diagram is the same as Timer2, with TMR2, PR2, T2IF, and T2CK replaced by TMR3, PR3, T3IF, and T3CK. The T3CON register is the Timer3 configuration register and has the same control bits as T2CON except for the T32 bit.

Figure 9.11 T2CON register details Source: Figure redrawn by author from Register 11.1 found in the dsPIC33/PIC24 FRM section 11: timers (DS70362B), Microchip Technology, Inc.

This chapter uses Timer2 and Timer3 to generate periodic interrupts based on the T2IF or T3IF flags. A periodic interrupt is useful for sampling inputs at some desired periodic interval. Because Equation 9.3 has two variables (PR2 and PRE), there may be more than one solution for the desired

Periodic Timer Interrupts

339

interrupt period. One approach for determining PR2, PRE is to select a PRE (prescale) value, then solve for the PR2 value that gives the desired period, as shown in Equation 9.4: PR2 = (TT2IF ↔ FCY /PRE ) − 1

(9.4)

Table 9.6 shows calculated PR2 values for each possible prescaler value, assuming a desired period interrupt of 15 ms and FCY = 60 MHz. The PR2 values for PRE = 1 and PRE = 8 cannot be used since they are greater than 65535 (recall that PR2 is a 16-bit register). If accuracy is important for the periodic interrupt, then the lowest prescaler value should be used. The values in Table 9.6 are rounded to the nearest integer value.

Table 9.6: PR2/PRE Values for TT2IF = 15 ms, FCY = 60 MHz PR2

PRE=1

PRE=8

PRE=64

PRE=256

899,999 (invalid)

112,499 (invalid)

14,062

3,515

Timer Macros and Support Functions Listing 9.2 shows the Timer2 macros contained in lib\include\pic24_timer.h. Similar macros are defined for higher-numbered timers, and are compatible with the PIC24/dsPIC33 F, H, and E families. Listing 9.2: Timer Macros /* T2CON: TIMER2 CONTROL REGISTER */ #define T2_ON 0x8000 #define T2_OFF 0x0000 #define T2_OFF_ON_MASK (~T2_ON)

/* Timer2 ON */ /* Timer2 OFF */

#define T2_IDLE_STOP #define T2_IDLE_CON #define T2_IDLE_MASK

0x2000 /* stop operation during sleep */ 0x0000 /* operate during sleep */ (~T2_IDLE_STOP)

#define T2_GATE_ON #define T2_GATE_OFF #define T2_GATE_MASK

0x0040 /* Timer Gate time accumulation enabled */ 0x0000 /* Timer Gate time accumulation disabled */ (~T2_GATE_ON)

#define #define #define #define

0x0000 0x0010 0x0020 0x0030

T2_PS_1_1 T2_PS_1_8 T2_PS_1_64 T2_PS_1_256

/* Prescaler 1:1 */ /* 1:8 */ /* 1:64 */ /* 1:256 */

340

Chapter 9

■

Interrupts and a First Look at Timers

#define T2_PS_MASK

(~T2_PS_1_256)

#define T2_32BIT_MODE_ON #define T2_32BIT_MODE_OFF #define T2_32BIT_MODE_MASK

0x0008 /* Timer2 and Timer3 form a 32 bit Timer */ 0x0000 (~T2_32BIT_MODE_ON)

#define T2_SOURCE_EXT #define T2_SOURCE_INT #define T2_SOURCE_MASK

0x0002 /* External clock source */ 0x0000 /* Internal clock source */ (~T2_SOURCE_EXT)

The macros of Listing 9.2 can be used to set the T2CON register contents in a self-documenting manner, such as the following: T2CON = T2_OFF | T2_IDLE_CON | T2_GATE_OFF | T2_32BIT_MODE_OFF | T2_SOURCE_INT | T2_PS_1_64; // Results in T2CON=0x0020.

This is clearer to an external reader than writing T2CON = 0x0020 and so the code examples use this style for timer configuration. The following line of code shows how to use a mask macro to modify a bit field without disturbing the other bits in the register: T2CON = (T2CON & T2_PS_MASK) | T2_PS_1_8;

There are no individual bit macros such as _TON defined for the timer configuration registers because the bit names are the same for the different timer registers. However, in addition to the mask macros, you can also use the C structure references (see Chapter 8) to change bits in the timer registers, as shown in the following code line: T2CONbits.TON = 1;

// Turn on timer2.

The file lib\src\pic24_timer.c contains timer support functions as shown in Listing 9.3. The msToU16Ticks(uint16_t u16_ms, uint16_t u16_pre) function is based on Equation 9.3 and converts milliseconds (u16_ms parameter) to timer ticks given the timer prescale value (u16_pre parameter) and the predefined FCY macro. The usToU16Ticks() function is similar except it converts microseconds to timer ticks. Floating point computation is used internally in the timer ticks conversion functions to accommodate a wide range of FCY and timer prescale values. Because of this, it is recommended that you avoid using these functions in time-critical code sections. Calls to the ASSERT() function implement range checking within msToU16Ticks() and usToU16Ticks() to verify that the requested timeout period can fit in the uint16_t return value given the timer prescale and FCY values. If the calculation overflows the 16-bit range, then the reportError() function is called that saves an error message and executes a software reset. The error message is output to the serial console when printResetCause() is called by main(). The getTimerPrescale(TxCONbits) macro calls the getTimerPrescaleBits(uint8_t u8_TCKPS) function, which returns the timer prescale value given a timer configuration register.

Periodic Timer Interrupts

341

Listing 9.3: Timer Support Functions // Convert milliseconds to Timer ticks. uint16_t msToU16Ticks(uint16_t u16_ms, uint16_t u16_pre) { float f_ticks = FCY; uint16_t u16_ticks; f_ticks = (f_ticks*u16_ms)/u16_pre/1E3; ASSERT(f_ticks < 65535.5); u16_ticks = roundFloatToUint16(f_ticks); //back to integer return u16_ticks; } // Convert microseconds to Timer ticks. uint16_t usToU16Ticks(uint16_t u16_us, uint16_t u16_pre) { float f_ticks = FCY; uint16_t u16_ticks; f_ticks = (f_ticks*u16_us)/u16_pre/1E6; ASSERT(f_ticks < 65535.5); u16_ticks = roundFloatToUint16(f_ticks); //back to integer return u16_ticks; } // Return the timer prescale based on the TxCONbits SFR. #define getTimerPrescale(TxCONbits) getTimerPrescaleBits(TxCONbits.TCKPS) // Return the timer prescale based on the TCKPS bitfield in TxCONbits. uint16_t getTimerPrescaleBits(uint8_t u8_TCKPS) { const uint16_t au16_prescaleValue[] = { 1, 8, 64, 256 }; ASSERT(u8_TCKPS = 10) { e_state = STATE_RELEASED1; // Stop toggling u16_doBlink = 0; } if (PB_PRESSED()) { e_state = STATE_PRESSED3; // Stop toggling u16_doBlink = 0; } break;

Other than adding two conditional assignments to the RELEASED3_BLINK state, the remainder of the FSM is identical to the FSM given in the previous chapter. To actually perform the blinking, the main() code only monitors the semaphore state and performs the desired blinking: int main(void) { ... configuration code not shown ... while (1) { if (u16_doBlink) { u16_led_toggles++; DELAY_MS(250); LED1 = !LED1; printf(“toggles = %d\n”, u16_led_toggles); } doHeartbeat(); } }

Observe that the volatile modifier is used in the u16_doBlink variable declaration. This notifies the compiler that this can be modified by an external agent (e.g., an ISR) between successive accesses (reads) in the main() code and prevents certain compiler optimizations from being applied. The volatile modifier should be used with any variable modified by an ISR and accessed outside of the ISR.

346

Chapter 9

■

Interrupts and a First Look at Timers

The variable u16_doBlink is a semaphore, which is a flag set by an ISR to signal the foreground task that an I/O action has occurred. Generally, the ISR sets the semaphore indicating that an I/O action has been processed and is ready. The foreground task detects that the semaphore is set, reads the I/O event result and resets the semaphore, thus indicating to the ISR that the I/O event has been consumed. An advantage of using the foreground task to clear the semaphore is that the ISR can determine if the foreground task is processing interrupts fast enough to keep pace with I/O event occurrence. If the semaphore is still set when the ISR receives an I/O event then the foreground task is processing I/O events too slowly, and some sort of event buffering may be needed (as covered in Chapter 10). How long should the ISR period be in order to debounce a human-activated pushbutton switch? Figure 9.14 shows a low-true bouncy switch being sampled by a periodic interrupt, with bounce occurring on both switch press and release. The bounce times are labeled as TBNCE1 and TBNCE2 (generically referred to as TBNCE) and are assumed to be approximately equal to each other. For the high-to-low transition of a switch press, if the ISR samples at a high bounce point, then the ISR period must be short enough so that the next sample sees the switch activation or else the activation is missed. If the ISR samples at a low bounce point, then the ISR period must be long enough for the bounces to settle or else the next sample may be at a high bounce point, causing the ISR to see a false switch release. This means the ISR period must be greater than the bounce time (TBNCE) and less than half the expected pulse width (TPW/2) to guarantee two samples per switch activation. For human-activated switches, the pulse width (TPW) is greater than 100 ms based on human reaction times. The bounce time (TBNCE) depends on the switch, but is generally less than 5 ms. An ISR period of 15 ms works well if you want to guarantee multiple samplings of a human-activated pushbutton. Having the sampling period greater than the bounce time means that for the low-tohigh transition of a switch release, only one sample is possible during the TBNCE2 period. If the ISR samples low during TBNCE2, the next sample is a high value, generating a clean switch release event. If the ISR samples high during TBNCE2, a clean switch release event is seen because the next sample is also high.

Change Notification with a Timer A second approach further increases efficiency and responsiveness by only running the CPU when a button is pressed or released, rather than running it periodically to sample an input. This method employs a change notification interrupt to detect a pushbutton press or release. In order to avoid problems with switch bounce, the state machine will be run after a debounce delay after the pushbutton triggers a change notification interrupt; Timer3 will be used to provide this delay. Inside the state machine, the inefficient DELAY_MS statement used in the previous chapter for blinking the LED will likewise be replaced with a Timer3 interrupt.

Interrupt-Driven LED/Switch I/O

347

Figure 9.14 Switch bounce and interrupt period

This section begins by examining the change notification ISR, which disables itself to avoid switch bounce, then arms the timer to update the FSM state after a debounce delay. void _ISR _CNInterrupt(void) { // Acknowledge the interrupt, then disable it. Otherwise, any switch bounce // would cause spurious interrupts. _CNIF = 0; _CNIE = 0; // Schedule a timer interrupt after a debounce delay. timer3_arm(DEBOUNCE_DLY); }

The timer3_arm() routine provides a convenient method for scheduling a Timer3 interrupt u16_time_ms in the future: void timer3_arm(uint16_t u16_time_ms) { // If a timer interrupt has occurred but has not been processed, // discard it and rearm. _T3IF = 0;

348

Chapter 9

■

Interrupts and a First Look at Timers

// Convert arm time to Timer3 ticks. PR3 = msToU16Ticks(u16_time_ms, getTimerPrescale(T3CONbits)) - 1; TMR3 = 0; T3CONbits.TON = 1; }

After a DEBOUNCE_DLY of 15 ms, the timer interrupt occurs. The effects of switch bounce on the disabled change notification interrupt can be cleared, the change notification interrupt re-enabled, and the FSM run. void _ISR _T3Interrupt(void) { // Clear the interrupt flag. _T3IF = 0; // Stop the timer; the debounce delay is done. T3CONbits.TON = 0; // Clear the change notification interrupt because switch bounce // may have set it. _CNIF = 0; // Re-enable change notification interrupts, since the debounce // delay is done. _CNIE = 1; // Run our state machine. update_state(); }

The state machine in update_state() is almost identical to the code given in Chapter 8. Two changes must be made in order to replace the inefficient DELAY_MS call with a timer interrupt. First, a timer interrupt must be scheduled when leaving the PRESSED2 state; there are otherwise no interrupt sources (such as pushbutton presses producing a change notification interrupt or timer interrupts scheduled), which will run the code in the RELEASED3_BLINK state. The changes made inside switch (e_state) are shown in Figure 9.15. One significant benefit of this approach is efficiency: CPU cycles are used to process switch and timer interrupts, rather than idly poll a pushbutton or spend millions of CPU cycles delaying for a fixed amount of time. This is most clearly seen in the following main() routine; when done with its work, the PIC24 enters the idle state to save power. For additional savings, Timer3 can be run from an external clock source, allowing the PIC24 to sleep. int main(void) { configBasic(HELLO_MSG); config_pb(); config_sw(); CONFIG_LED1();

Interrupt-Driven LED/Switch I/O

349

configTimer3(); config_cn(); while (1) { IDLE(); } }

Unfortunately, this approach has one significant drawback: though it implements the state machine shown in Figure 9.13, its operation differs markedly from the polling and the periodic sampling approach. The differences are apparent when the next state is run. When polling or performing periodic sampling, the next state is run immediately (polling) or in 15 ms (sampling), so that the actions of the next state (turning an LED on, for example) occur almost immediately. In contrast, in this approach the next state is run only when the next event occurs. For example, a button press changes the state assignment, but does not then perform the assignment in that next state until the next button press, which occurs an indeterminate amount of time later.

Figure 9.15 chap09\ledsw1_cn.c: Changes made to update_state() from Chapter 8 for interrupt-driven operation

350

Chapter 9

■

Interrupts and a First Look at Timers

To achieve results that match the polling and period sampling approaches, a different state machine must be designed, which relies on conditional state assignments to turn the LED on and off when an event occurs, rather than waiting until the next state to do so. In particular, all unconditional state outputs must be placed as a conditional state output in all states which transition to a state with an unconditional state output. For example, consider state LED_OFF, where the unconditional assignment LED1 = 0 is made. This state can be reached from state PRESSED2 when SW == 0, state RELEASED3_BLINK when toggles >= 10, or from state PRESSED3 when PB is pressed. Therefore, the single assignment LED1 = 0 must be placed in all three of these state transitions. Likewise, the unconditional assignment LED1 = 1 in state RELEASED2 must become a conditional assignment when transitioning from PRESSED1 to RELEASED2, and LED1 = 1 in state PRESSED3 becomes a conditional assignment when transitioning from RELEASED3_BLINK to PRESSED3. The revised state machine and resulting code for update_state() is given in Figure 9.16 and Listing 9.5; these illustrate the preferred method when using this approach. Using this revised state machine, all three approaches (Chapter 8’s polling, the previous section’s input sampling, and this revised approach) now produce identical results. Listing 9.5: chap09\ledsw1_cn_revised.c: Revised update_state() for Change Notification with Timers; Changes Shown in Bold Type void update_state(void) { static state_t e_state = STATE_RELEASED1; // The number of times the LED was toggled in the blink state static uint16_t u16_led_toggles; switch (e_state) { case STATE_RELEASED1: if (PB_PRESSED()) { e_state = STATE_PRESSED1; } break; case STATE_PRESSED1: if (PB_RELEASED()) { e_state = STATE_RELEASED2; // Turn the LED on when entering STATE_RELEASED2. LED1 = 1; } break; case STATE_RELEASED2: if (PB_PRESSED()) {

Interrupt-Driven LED/Switch I/O

Figure 9.16 Revised FSM for change notification with a timer approach

351

352

Chapter 9

■

Interrupts and a First Look at Timers

e_state = STATE_PRESSED2; } break; case STATE_PRESSED2: if (PB_RELEASED() && SW) { e_state = STATE_RELEASED3_BLINK; // Zero the toggled count before entering the blink state. u16_led_toggles = 0; // Schedule a timer interrupt to start the blinking. timer3_arm(250); } if (PB_RELEASED() && !SW) { e_state = STATE_RELEASED1; // Turn the LED off when moving to STATE_RELEASED1. LED1 = 0; } break; case STATE_RELEASED3_BLINK: // Toggle the LED. LED1 = !LED1; u16_led_toggles++; printf(“toggles = %d\n”, u16_led_toggles); // Schedule a timer interrupt to continue the blinking. timer3_arm(250); if (u16_led_toggles >= 10) { e_state = STATE_RELEASED1; // Turn the LED off when moving to STATE_RELEASED1. LED1 = 0; } if (PB_PRESSED()) { e_state = STATE_PRESSED3; // Freeze the LED on when exiting the blink state. LED1 = 1; } break; case STATE_PRESSED3: if (PB_RELEASED()) { e_state = STATE_RELEASED1;

Filtering Noisy Inputs

353

// Turn the LED off when moving to STATE_RELEASED1. LED1 = 0; } break; default: ASSERT(0); } print_state(e_state); }

Filtering Noisy Inputs A common problem in microcontroller interfacing is sampling a noisy input that may have false glitches in the signal. This is a different problem than switch debouncing because the glitches can occur anywhere in the signal, unlike switch noise that occurs for a short time period after the switch changes state. This means that the periodic sampling approach alone will not guarantee correct interpretation of noisy inputs. The Schmitt Trigger (Chapter 8) input buffer on each PIO coupled with an external low-pass RC filter can provide a good solution for sampling noisy inputs. A low-pass RC filter as shown in Figure 9.17(a) has a cutoff frequency of 1/(2πRC), which means that signals at this frequency are attenuated by approximately 50 percent, with attenuation increasing with frequency. To completely block a signal at a particular frequency f, use a filter with a cutoff frequency of approximately f/10. The RC filter greatly increases the rise and fall time of the port’s input signal, but the port’s Schmitt Trigger internally transforms this slowly rising or falling signal to a clean signal transition.

Figure 9.17 Noisy input filtering

354

Chapter 9

■

Interrupts and a First Look at Timers

Figure 9.17(b) shows an experiment with RB2 supplying a square wave with pulse widths of TPW as an input signal to pin RB3. The goal of the experiment is to monitor the RB3 input state and determine RC values that either block or pass the signal transitions. Figure 9.18 shows the code that implements the experiment of Figure 9.17(b). The while (1) loop in main generates a square wave on TOUT (RB2) using software delays with high and low pulse widths of TPW. If the old input value (u8_oldvalueTIN) does not match the current RB3 input value (TIN), then * is printed and the current value is saved to u8_oldvalueTIN. Experimentation showed that values of R = 16 kΩ and C = 0.1 µF blocked pulse widths of 1 ms and passed pulse widths of 2 ms (your results may vary!). Because the source impedance of a noise source can affect the filter cutoff frequency, you should verify experimentally any external filtering circuitry by using an oscilloscope to monitor the filter output to observe its effect on the noisy input signal.

Figure 9.18 chap09\filter_test.c: RC low-pass filter experiment code

For long pulse width transients (pulse widths of multiple milliseconds), a low-pass RC filter may reduce the signal rise/fall times to unacceptably long times. In this case, a low-pass RC filter for higher frequency transients (pulse widths < 1 ms) combined with a software noise filter may be the

A Rotary Encoder Interface

355

best approach. Figure 9.19 shows the ISR for a periodic timer interrupt that is used to sample the TIN input of Figure 9.18. The ISR code includes a software glitch filter that only passes changes in the TIN input if the TIN input is stable for MIN_STABLE number of milliseconds. The u16_stableCountTIN variable is used by the ISR to track the number of successive interrupts that TIN is stable. When this counter exceeds MIN_STABLECOUNT, which is defined as MIN_STABLE/ISR_PERIOD, then the TIN value is copied to the u8_valueTIN variable used by main. Generally, the sampling period for a software glitch filter should be fast enough to achieve at least four samples for the minimum pulse width. It is not desirable to use a software filter for short pulse width transients (< 1 ms) because the ISR period becomes fairly small, requiring a larger percentage of the processor execution time.

Figure 9.19 chap09\sofilt_test.c: software glitch filter

A Rotary Encoder Interface A rotary encoder is used to encode the direction and distance of a mechanical shaft’s rotation. There are different ways to accomplish this; Figure 9.20 shows a 2-bit Gray code rotary encoder. Counterclockwise rotation (a) of the shaft produces the sequence 00, 01, 11, and 10, while clockwise rotation (b) generates 00, 10, 11, and 01. In a Gray code, adjacent encodings differ by only one bit position. Rotation direction is determined by comparing the current 2-bit value with the last value.

356

Chapter 9

■

Interrupts and a First Look at Timers

For example, if the current value is 11 and the last value is 10, the shaft is rotating in a clockwise (b) direction. One common use for a rotary encoder is as an input device on a control panel where clockwise rotation increments a selected parameter setting, while counterclockwise rotation decrements the parameter. The rotary encoder of Figure 9.20 is an incremental encoder as the shaft’s absolute position is indeterminate; only relative motion is encoded. Some rotary encoders include more bits that provide absolute shaft position, in BCD or binary encoding. An n-position encoder outputs n codes for each complete shaft rotation. Common values of n for 2-bit incremental rotary encoders are 16 and 32. However, high-precision encoders can supply hundreds of pulses per shaft rotation.

Figure 9.20 Two-bit Gray code rotary encoder

Rotary encoders use mechanical, optical, or magnetic means of detecting shaft rotation, with mechanical encoders being the least expensive and magnetic the most expensive. A key specification for optical and mechanical encoders is rotational life, with optical ~ 1 million and mechanical ~ 100,000 rotations due to mechanical wear. Magnetic encoders are meant for high-speed rotational applications with encoder lifetime measured in thousands of hours for a fixed rotational speed in revolutions per minute (RPMs). A two-bit mechanical Gray code rotary encoder, as shown in Figure 9.20(c), generally has three pins as shown, two outputs for the switches and the third output for a common ground.

A Rotary Encoder Interface

357

Figure 9.21 shows a utility function named processRotaryData() that is called to process a change in state for a 2-bit Gray code rotary encoder. The u8_curr and u8_last parameters are the current and last state values, respectively, of the encoder and are limited to values of 0, 1, 2, and 3. The *pi8_cntr parameter is a pointer to a counter that may either be incremented or decremented by one, depending upon the state change of the encoder. The function limits the counter value to between 0 and u8_max, as most counter variables associated with rotary encoder inputs have some sort of limit associated with them. In this implementation, modifications to the counter variable are halted when a limit is reached until the encoder rotation is reversed. An alternative implementation could wrap the counter after reaching a limit. If the function detects an illegal state change, perhaps caused by switch bounce or noise, then a non-zero value is returned from the function. Observe that the u8_delta value assigned in each case is based on the current and last states. For example, for a current state (u8_curr) of 0, a previous state (u8_last) of 1 from Figure 9.20 means that the encoder shaft has rotated clockwise, so the counter should be incremented by 1 (u8_delta = 1).

Figure 9.21 chap09\rot_enc.c: the processRotaryData() utility function

358

Chapter 9

■

Interrupts and a First Look at Timers

Figure 9.22 shows the ISR and main() code that reads a 2-bit Gray code rotary encoder connected to RB13 and RB12, which is periodically sampled by a 15 ms Timer3 interrupt. Because rotary encoder output is generated by switch opens and closures, the periodic sampling of the rotary encoder state handles the switch bounce. The processRotaryData() function is called by the Timer3 ISR whenever the encoder state changes, and the u8_cntrROT variable implements the rotary encoder counter variable, which is limited to a maximum value defined by ROT_MAX. The u8_errROT variable is used to hold the return value of processRotaryData() function, which is a non-zero value if an illegal state change is detected. The main() configuration code in Figure 9.22 uses the configRotaryEncoder() function to configure RB13/RB12 as inputs with weak pull-ups for the two rotary encoder outputs. The 1 μs software delay that follows is needed to give time for the weak pull-ups on the inputs to stabilize, so that the u8_valueROT variable that contains the initial state of the rotary encoder is initialized to a stable value. The while (1) loop prints the u8_cntrROT value any time a change is detected and also prints an error message if the u8_errROT variable becomes non-zero.

Figure 9.22 chap09\rot_enc.c: a 2-bit Gray code rotary encoder interface example

A Keypad Interface

359

Figure 9.22 (continued) chap09\rot_enc.c: a 2-bit Gray code rotary encoder interface example

A Keypad Interface A numeric keypad is a common element in a microcontroller system, as it provides an inexpensive method of input. A numeric keypad is simply a matrix of switches arranged in rows and columns and has no active electronics; a keypress connects a row and column pin together, as shown in Figure 9.23.

Figure 9.23 4x3 numeric keypad

360

Chapter 9

■

Interrupts and a First Look at Timers

The 4x3 numeric keypad of Figure 9.23 is shown connected to the PIC24 μC in Figure 9.24. The RB[5:3] port pins are configured as outputs driving low and connected to the row pins, while RB[9:6] are configured as inputs with the weak pull-ups enabled and connected to the column pins.

Figure 9.24 4x3 numeric keypad connected to the PIC24 µC

If no key is pressed as in Figure 9.24(a), RB[9:6] reads as 1111 because there are no connections to the RB[5:3] pins. In Figure 9.24(b), key 8 is pressed, connecting RB7 to RB4, causing RB7 to become a 0.

A Keypad Interface

361

The keypress can be detected by any of the mechanisms previously discussed, such as polling, periodic sampling via a timer interrupt, or using the change notification inputs associated with the PORTB pins. After a keypress is detected, determining which key is actually pressed is done through a procedure known as a keypad scan. The keypad scan first determines which column input is low. Then it steps through the rows, driving the one row low and the remaining rows high. If the column input originally found as low remains low, then the corresponding row for the keypress has been discovered. This scan procedure only detects one key when multiple keys are pressed, but it is straightforward to modify it to detect multiple keypresses. In Figure 9.24(b), a keypress is detected when the RB7 column input is read as low. The scan is started in Figure 9.24(c) by driving RB3 low and RB4 and RB5 high. The RB7 column input remains high, so key 9 is not pressed. In Figure 9.24(d), RB4 is driven low and RB3 and RB5 high. At this point, the RB7 column input is found to be low, indicating that key 8 is pressed creating the connection between RB4 and RB7. Listing 9.6 shows some interface macros and support functions for the keypad interface. Macros C0, C1, C2, and C3 are four column input states, with macros R0, R1, and R2 for the row states. The configKeypad() function configures the column inputs with pull-ups enabled and the rows as outputs all driving low. The remaining functions are self-explanatory. Listing 9.6: chap09\keypad.c: Interface Macros, Support Functions for Keypad Interface #define #define #define #define

C0 C1 C2 C3

(_RB9) (_RB8) (_RB7) (_RB6)

void config_column(void) { CONFIG_RB9_AS_DIG_INPUT(); CONFIG_RB8_AS_DIG_INPUT(); CONFIG_RB7_AS_DIG_INPUT(); CONFIG_RB6_AS_DIG_INPUT(); }

ENABLE_RB9_PULLUP(); ENABLE_RB8_PULLUP(); ENABLE_RB7_PULLUP(); ENABLE_RB6_PULLUP();

#define R0 (_LATB5) #define R1 (_LATB4) #define R2 (_LATB3) #define CONFIG_R0_DIG_OUTPUT() CONFIG_RB5_AS_DIG_OUTPUT() #define CONFIG_R1_DIG_OUTPUT() CONFIG_RB4_AS_DIG_OUTPUT() #define CONFIG_R2_DIG_OUTPUT() CONFIG_RB3_AS_DIG_OUTPUT()

362

Chapter 9

■

Interrupts and a First Look at Timers

void config_row(void) { CONFIG_R0_DIG_OUTPUT(); CONFIG_R1_DIG_OUTPUT(); CONFIG_R2_DIG_OUTPUT(); } void drive_row_low(void) { R0 = 0; R1 = 0; R2 = 0; } void drive_row_high(void) { R0 = 1; R1 = 1; R2 = 1; } void configKeypad(void) { config_row(); drive_row_low(); config_column(); DELAY_US(1); //wait for pull-ups to stabilize inputs }

Figure 9.25 shows the doKeyScan() function for the keypad interface, which first identifies the column input that is low, storing it in the u8_col variable. The function then scans the keypad as previously described using a for loop with loop variable u8_row. Within the loop, the u8_setOneRowLow(u8_row) function call drives the row specified by u8_row as low and the remaining rows high. When a column input is detected low during the loop, the variables u8_row and u8_col are used to access the two-dimensional array au8_keyTable to return the ASCII value of the pressed key. An “E” character is returned if the key scan finds no column input that is low, indicating that no character is available. The KEY_PRESSED() macro returns true if any column is low, while the KEY_RELEASED() macro is true if all columns are high. Figure 9.26 shows the ISR and the main() code for the keypad interface. The ISR uses a three-state FSM to detect presses and releases on the keypad. If a key is pressed for two consecutive ISR periods and the last key value has been consumed, then the keypad is scanned using the doKeyScan() function. The reason for waiting two consecutive ISR periods for the keypress is that in the previous switch sampling examples, you were guaranteed that switch samples were separated by an ISR sampling period. However, in this case the doKeyScan() function resamples the switch after the ISR has detected it as low. The doKeyScan() function will thus be sampling during the bounce period, so it could see a 1 instead of a 0. Waiting for the ISR to sample a 0 for two consecutive periods means that the doKeyScan() function will read the key during the stable-L period of Figure 9.14. The new key value is returned in u8_newKey, which functions as a semaphore when its value is non-zero. The while (1) loop in main() waits for a non-zero value in u8_newKey, prints the key value to the screen, and then clears u8_newKey.

A Keypad Interface

Figure 9.25 chap09\keypad.c: the doKeyScan() function for the keypad interface

363

364

Chapter 9

■

Interrupts and a First Look at Timers

Figure 9.26 chap09\keypad.c: the ISR and main() code for the keypad interface

On Writing and Debugging ISRs

365

On Writing and Debugging ISRs As discussed previously, when writing ISRs one must be careful not to place too much work within the ISR, as this can either cause other interrupt events to be missed or steal too much time away from the normal program flow. Within an ISR, there should never be a wait for an I/O event—that is the function of the interrupt that triggers the ISR. Because many ISRs are time sensitive, putting print statements that output data to a serial port in an ISR to examine ISR variables is often not an option, as this destroys the interrupt timing. It may be valid to place a print statement in the foreground code to examine an ISR variable, but the variable value should always be copied to a temporary variable first because the ISR variable value may be changed by the time the print statement is executed. If you are trying to trace a variable value over several interrupt intervals, then using a print statement may not be an option if the print is not fast enough to monitor the variable value. In this case, a trace buffer can be used in which copies of the variable over several interrupt intervals are kept, then printed when the trace buffer becomes full. Figure 9.27 shows a trace buffer (au8_tbuff) added to the processRotaryData() function of Figure 9.24 to track changes of the rotary encoder state. The current rotary encoder state (u8_curr) is saved if tracing is enabled (u8_startTrace is non-zero) and the trace buffer is not full. The while (1) loop of main() enables tracing, waits for the trace buffer to fill, then prints the contents of the trace buffer. Tracing is re-enabled by emptying the trace buffer (clearing u8_tnct) after the trace buffer is printed.

Figure 9.27 chap09\rot_enc_trace.c: using a trace buffer

366

Chapter 9

■

Interrupts and a First Look at Timers

Figure 9.27 (continued) chap09\rot_enc_trace.c: using a trace buffer

Summary The primary use of interrupts is to gain efficiency and responsiveness for LED/switch I/O problems. For mechanical switches such as those used in numeric keypads, this provides an effective debounce mechanism. The next chapter explores the various serial interfaces available on the PIC24 μC and interrupt-driven I/O for those servicing those interfaces, as well as various buffering techniques common to interrupt-driven I/O.

Review Problems 1. Modify the code in Figure 9.5 to generate an address error trap. 2. Modify the code in Figure 9.5 to generate a stack error trap. Why might you want to purposefully trigger a trap error? 3. In Figure 9.9, assume the NOPs in the _CNInterrupt ISR are removed. What happens and why? 4. In Figure 9.9, assume that four NOPs are used in the while (1) loop. What happens and why? 5. Give the CNIExy bit that must be set to enable the change notification on pin RA2 for the dsPIC33EP128GP502. 6. Give the CNIExy bit that must be set to enable the change notification on pin RB7 for the dsPIC33EP128GP502. 7. Write a code sequence that enables the input change notification interrupt for changes on inputs RA4 and RB12 (assume that both have been previously configured as inputs).

Review Problems

367

8. Write a code sequence that enables the input change notification interrupt for changes on inputs RB10 and RA1 (assume that both have been previously configured as inputs). 9. Assume that for a dsPIC33EP128GP502, the RB13 has a pushbutton switch connected to it, as shown in Figure 9.19, and the change notification interrupt for RB13 is enabled. For the following code snippet, how many times does the _CNInterrrupt ISR execute if the pushbutton is pressed and released one time? Assume no switch bounce and explain your answer. void _ISR _CNInterrupt(void) { DISABLE_RB13_CN_INTERRUPT(); _CNIF = 0; } int main(void) { CONFIG_RB13_AS_DIG_INPUT(); ENABLE_RB13_CN_INTERRUPT(); _CNIF = 0; _CNIP = 2; _CNIE = 1; while(1); }

10. 11. 12. 13.

// _CNIEB13 = 0; (STATEMENT A) // (STATEMENT B)

// _CNIEB13 = 1; (STATEMENT C) (STATEMENT D) (STATEMENT E) // infinite loop

Repeat problem #9, except remove statement A. Repeat problem #9, except replace statement D with _CNIP = 0. Repeat problem #9, except remove statement E. Figure 9.28 shows one switch connected to INT0 and INT1 interrupt inputs. For the code in Listing 9.7 give the order in which statements A, B, C, and D are executed given a single press and release of SW0. Assume no switch bounce, and explain your answer. Recall that if an INTxEP bit is 1, the interrupt is negative edge triggered; if 0, then it is positive edge triggered.

Figure 9.28 INT0/INT1 interrupt problem

368

Chapter 9

■

Interrupts and a First Look at Timers

Listing 9.7: Code for INT0/INT1 Interrupt Problem void _ISR _INT0Interrupt(void) { _INT0IE = 0; _INT0IF = 0; } void _ISR _INT1Interrupt (void) { _INT1IE = 0; _INT1IF = 0; } int main(void) { ...config code that enables weak pull-ups... _INT0IF = 0; _INT0IP = 2; _INT0EP = 1; _INT0IE = 1; _INT1IF = 0; _INT1IP = 2; _INT1EP = 1; _INT1IE = 1; while(1); //infinite loop }

14. 15. 16. 17. 18. 19. 20.

(STATEMENT A) (STATEMENT B)

(STATEMENT C) (STATEMENT D)

(STATEMENT (STATEMENT (STATEMENT (STATEMENT (STATEMENT (STATEMENT (STATEMENT (STATEMENT

E) F) G) H) I) J) K) L)

Repeat problem #13, except replace statement J with _INT1IP = 3. Repeat problem #13, except replace statement G with _INT0EP = 0. Repeat problem #13, except replace statement J with _INT1IP = 0. Repeat problem #13, except replace statement L with _INT1IE = 0. Repeat problem #13, except remove statement D. Repeat problem #13, except remove statement D, and replace C with _INT1IE = 1. How many PIC24 Timer2 ticks are equal to 70 μs, assuming a prescale of 1 and a FCY of 20 MHz? 21. How many PIC24 Timer2 ticks are equal to 1.2 ms, assuming a prescale of 8 and a FCY of 30 MHz? 22. What is the maximum PIC24 Timer2 timeout period, assuming a prescale of 64 and a FCY of 30 MHz? 23. What is the maximum PIC24 Timer2 timeout period, assuming a prescale of 8 and a FCY of 10 MHz? Give the answer rounded to the nearest millisecond.

Review Problems

369

The following problems assume external LEDs (LED1, LED2, and so on) and switches (SW1, SW2, and so on). You may use any of the RBn ports you want to implement these problems. Assume switch inputs are pushbutton inputs and that they use the internal weak pull-up of the port. You may use either Timer2 or Timer3 when a periodic timer interrupt is needed. 24. Assume two LEDs (LED1 and LED2) and one switch input (SW1). Both LEDs should be initially off. After each press AND release of SW1, change the LED state (LED1/LED2) in the sequence: OFF/ON, ON/OFF, ON/ON, OFF/OFF, OFF/ON, ON/OFF, ON/ON, OFF/OFF, and so on. Draw a state machine chart for the problem, with the solution done as in the style of Listing 9.5 (a change notification/timer ISR does all of the work; the while (1) loop is empty). 25. Repeat problem #23, except the LEDs change state whenever a press OR a release occurs for SW1. 26. Assume one LED (LED1) and one switch input (SW1). The LED should be initially blinking. On each press AND release of SW1, alternate between terminating the blinking and resuming the blinking. Draw a state machine chart for the problem, with the solution done as in the style of Listing 9.5 (a change notification / timer ISR does all of the work; the while (1) loop should be empty). 27. Repeat problem #26, except the blinking terminates or resumes whenever a press OR a release occurs for SW1.

This page intentionally left blank

Chapter 10

Asynchronous and Synchronous Serial I/O

T

his chapter discusses some of the serial interfaces available on the PIC24 μC: the Universal Asynchronous Receiver Transmitter (UART), the Serial Peripheral Interface (SPI), and the Inter-Integrated Circuit (I2C) bus. The protocols and operational modes of these three interfaces are discussed in detail along with interfacing examples to different external devices. Chapter 13 discusses the more complex Controller Area Network (CAN) serial protocol.

Learning Objectives After reading this chapter, you will be able to: ■ Describe the differences between synchronous and asynchronous serial data transfer. ■ Draw the waveform for an asynchronous serial data transfer that includes a start bit, data bits, and stop bits. ■ Write C code that sends and receives asynchronous serial data via the UART subsystem. ■ Discuss the signals and signaling levels associated with the EIA RS-232 interface. ■ Write C functions for performing interrupt-driven receive and transmit for the PIC24 UART. 2 ■ Compare and contrast the SPI and I C synchronous serial I/O protocols on the PIC24 μC. ■ Interface a PIC24 μC to a digital thermometer using the SPI protocol. ■ Interface a PIC24 μC to a digital potentiometer using the SPI protocol. ■ Implement PIC24 μC to PIC24 μC communication using the SPI protocol. 2 ■ Interface a PIC24 μC to a digital thermometer using the I C protocol. 2 ■ Interface a PIC24 μC to a serial EEPROM using the I C protocol. ■ Use interrupt-driven double buffering to implement continuous data stream applications. 371

372

Chapter 10

■

Asynchronous and Synchronous Serial I/O

I/O Channel Basics Parallel I/O uses a group of signals for data transfer, with a clock or data strobe signal typically used for controlling the transfer. Figure 10.1(a) shows a 16-bit parallel I/O link between CPU_a and CPU_b, with a clock signal used to perform one data transfer each clock cycle. The bandwidth of a communication channel is usually expressed either as the number of bytes transferred per second (B/s) or the number of bits transferred per second (b/s). Observe the capitalization difference between Bps (bytes/second) and bps (bits/second); Bps is related to bps via the relationship Bps = bps/8. For Figure 10.1(a), the bandwidth is 600 MB/s if the clock frequency is 300 MHz, because two bytes are transferred each clock cycle. Data sent one bit at a time is called serial data transfer, and Figure 10.1(b) shows a synchronous serial interface that uses a single bit line with a separate clock to accomplish the transfer. The bandwidth of this channel is 1/16th that of the bandwidth of Figure 10.1(b), because the 16 data lines have been replaced by only one data line. The advantage of parallel I/O is obvious: it has n times the bandwidth of a serial channel, assuming both channels use the same data transfer rate and the parallel channel has n data lines.

Figure 10.1 Parallel versus serial I/O

The principal advantage of serial I/O is that it is cheaper to implement in terms of integrated circuit, cable, and connector pin count than parallel I/O. This is especially important for microcontroller applications in which cost is typically an important constraint: fewer external pins used to communicate with external devices can lower the overall cost of the final product. In other applications, serial I/O is typically used for data transfer between devices that require external cabling, such as between a keyboard and a personal computer. This is because a serial cable requires fewer wires than a parallel cable, which reduces the cost. It also makes the cable less bulky and reduces the physical connector size, which is an issue when there are multiple I/O cable connections to a device. In

I/O Channel Basics

373

addition, wires within an I/O cable are subject to crosstalk, defined as a voltage change on a wire inducing a voltage change in a neighboring wire. Crosstalk can corrupt data transfers, resulting in an unreliable communication channel. Crosstalk increases with cable length and with higher signaling speeds. Methods for combating crosstalk increases the cabling costs, and thus serves as another reason for reducing the number of signals in an I/O cable. Parallel I/O is typically used for high-bandwidth, short-distance communication between integrated circuits in the same system. High bandwidth, low cost, and reliable transfers are desirable properties of any I/O channel. Unfortunately, these properties conflict with each other: increasing bandwidth typically increases cost and decreases the reliability of the I/O transfer. Increasing I/O channel bandwidth can be done by any combination of the following actions: 1. Increase the number of signals carrying data; e.g., increase a parallel I/O channel from 8 bits to 16 bits. 2. Decrease the amount of time between data transfers; e.g., increase the clock speed of the I/O channel. 3. Use a signaling method that encodes more data in the same time interval; e.g., use a fourlevel voltage signaling method so that 2 bits are encoded in each signaling interval (00 = 0 V, 01 = 1/3 VDD, 10 = 2/3 VDD, 11 = VDD). Methods 1 and 2 are the most common ways used to increase I/O channel bandwidth. Doubling the number of signal lines in an I/O channel doubles the bandwidth, but it also doubles the cost of the I/O channel. Decreasing the time used for each transfer increases bandwidth, but also increases the complexity of the electronics used for driving and receiving data signals, increasing the cost of each data signal. One method of decreasing the time between transfers is to use reduced voltage swing on the data lines instead of requiring the data signals to transition fully between VDD and ground. Swinging a data line by 200 millivolts to indicate a change from 1 to 0 or vice versa is accomplished faster than requiring a signal to transition from 0 to VDD. Figure 10.2 defines the terms simplex, half duplex, and duplex in reference to communication channels. A simplex channel allows data transfer in one direction only. A half-duplex channel supports transfer in either direction, but in only one direction per data transfer. A duplex channel (also referred to as full duplex) supports transfers in both directions simultaneously. A physical connection between two systems is either a unidirectional wire (transfer in only one direction) or a bidirectional wire (transfer in either direction). In Chapter 8, you saw that tristate buffers are required to implement a bidirectional port. A single unidirectional wire can implement a simplex channel, while a single bidirectional wire can implement a half-duplex channel. Two unidirectional wires can implement a duplex channel with each wire providing communication in one direction. A more complex electrical signaling method known as current-mode signaling can be used to implement a duplex channel using a single wire. However, use of current mode signaling is rare; all of the devices discussed in this book use voltage-mode signaling.

374

Chapter 10

■

Asynchronous and Synchronous Serial I/O

Figure 10.2 Simplex, half-duplex, and duplex communication channels

Synchronous, Asynchronous Serial I/O Synchronous serial I/O either sends a clock as a separate signal, as shown in Figure 10.3(b) or uses a scheme that allows the receiver’s clock to remain synchronized to the bit stream. Sending a clock as a separate signal is an intuitive solution for synchronous I/O, but at high signaling speeds wire delay becomes significant, especially in external cabling. If the wire delays of the serial data wire and clock signal are significantly mismatched, the active clock edge can clock in the wrong data bit at the receiver as is seen in Figure 10.3(b). Data/clock wire delay mismatch becomes larger the faster the signaling speed and the greater the distance. The Controller Area Network (CAN) serial transmission standard discussed in Chapter 13 uses synchronous transmission and is intended for serial communication over cables of several inches/ centimeters to several feet/meters. Because of this, its signaling methods do not send a separate clock signal, but uses a different method for maintaining synchronization as discussed further in Chapter 13. The I2C and SPI serial interfaces on the PIC24 μC, which are discussed later in this chapter, use synchronous transmission, and they all use the signaling method of Figure 10.1(b) that sends the clock with the data as a separate signal. This is because these interfaces are intended for short-distance communication between integrated circuits on the same printed circuit board. The separate clock also simplifies the logic implementation, which was important for older serial interfaces such as I2C and SPI that were defined in the 80’s because logic gates for an on-chip serial interface required a larger percentage of the total chip area at that time than it does today.

Synchronous, Asynchronous Serial I/O

375

Figure 10.3 Synchronous serial I/O: sending the clock with the data

Asynchronous Serial I/O Using NRZ Encoding Asynchronous serial I/O does not send a separate clock signal, and various signaling schemes are used to allow the receiver to read the serial data. Some schemes use a two-wire signaling method in which neither wire is a clock in the traditional sense, with transitions encoded on the wires in such a way that allows serial data to be extracted and supports dynamically varying transmission rates. This method is used by the high-speed serial I/O standard known as IEEE 1394, or FireWire. Another asynchronous method that uses only a single wire encodes serial data as non-return-to-zero (NRZ), which means that a high voltage is used for a 1 bit and a low voltage is used for a 0 bit. The serial line remains at either a high or low state when successive bits of the same value are sent. The NRZ format is the most intuitive format used for serial data encoding; other schemes exists such as bi-phase encoding that uses different edge transitions for distinguishing 1 and 0 bits (discussed in Chapter 12). Asynchronous NRZ serial transmission is what the PIC24 μC reference system of Chapter 8 uses for communication over the serial link to the attached personal computer.

376

Chapter 10

■

Asynchronous and Synchronous Serial I/O

Because a separate clock signal is not sent with the serial data, there is no issue of wire delay mismatch between clock and data, so asynchronous NRZ serial transmission can be used for long distance (meters/feet) communication. The disadvantage of asynchronous NRZ serial transmission is that it has a lower maximum data rate when compared to advanced synchronous signaling methods, for reasons to be discussed later in this section. In an asynchronous NRZ serial transfer, the sender and receiver agree on a common data rate and a common data format in terms of how many data bits are sent for each transfer. Figure 10.4 shows an asynchronous NRZ serial data frame. Before transmission begins, the line is in the idle or mark condition, which is a logic 1. The time required for sending one bit is referred to as a bit time. The start of transmission is indicated by a transition from the idle condition to logic 0, known as the space condition. This first bit, which is always a logic 0, is called the start bit and enables the receiver to detect the beginning of a transmission. Data bits are sent in the order of least significant bit (LSb) to most significant bit (MSb), with common data formats being 7 data bits + even/odd parity (discussed later in this section) or 8 data bits with no parity. The transmission ends with at least one stop bit, defined as the line remaining at 1 for at least one bit time. A total of 10 bit times are required for 1 start bit, 8 data bits, and 1 stop bit. Frame formats are identified as “(data size including parity bit, parity type, # of stop bits),” with E, O, N used for even parity, odd parity, and no parity, respectively. Thus, the frame format of Figure 10.4(a) can be (8, O, 1) if odd parity is used or (8, E, 1) if even parity is used.

Figure 10.4 Asynchronous data frame

A parity bit is a bit added by the sender to provide error detection of single-bit errors. Parity is either even or odd. The value of an even or odd parity bit is chosen so that the total number of 1 bits in the n data bits + parity bit is even or odd, respectively. For example, if a 7-bit data field is

Synchronous, Asynchronous Serial I/O

377

0b0101101, which contains an even number of 1s, odd parity selects a parity bit of 1, resulting in an odd number of 1 bits. In contrast, even parity selects a parity bit of 0, resulting in an even number of 1 bits. The receiver checks the value of the parity bit. An incorrect parity indicates that some type of transmission error has occurred. A single parity bit is guaranteed to detect any single bit error; that is, if only one bit of the n data bits + parity is received in error, the parity scheme detects that an error occurred. If multiple bit errors occur, the parity scheme might not detect the error. Figure 10.5 gives three examples of asynchronous serial data frames.

Figure 10.5 Example of asynchronous serial data frames

In Figure 10.4, each bit is sent within its own distinct signaling interval. This book refers to the signaling interval as a bit time, with the number of bits per second (bps) of the link given by Equation 10.1. Bits per second (bps) = 1/(bit_time)

(10.1)

Another term commonly used for the signaling speed of an asynchronous serial link is baud rate, whose definition is the number of signaling events per unit time. If only one bit is sent per signaling interval, baud rate is equal to bits per second. However, if more than one bit is sent per interval, such as a four-level voltage signaling scheme that sends two bits per signaling event, then bits per second is twice the baud rate. This book only discusses signaling methods in which one bit is sent per signaling interval, so baud rate is used interchangeably with bit rate. Figure 10.6 shows how phase and frequency differences between receiver and sender clocks are handled. Given a data rate of y bps, the clock used by the sender/receiver for accessing the serial data is a multiple of this rate, usually 64x, 16x, or 4x. Assuming a 16x clock, when the receiver detects a start bit (high to low transition), it counts 8 clock periods and then captures the input value.

378

Chapter 10

■

Asynchronous and Synchronous Serial I/O

After this point, the receiver samples the input line every 16 clock periods, placing the sampling point near the center of the bit interval, giving the receiver maximum tolerance for mismatch between receiver and transmitter clocks. Over time, any receiver/transmitter clock mismatch shifts the sampling point away from the bit time midpoint, eventually causing a reception error when the sampling point is shifted out of a bit interval. Sampling at the midpoint of the bit time gives a 50% error margin, or ±8 clock periods about the center of the clock interval. For a frame with 10 bit times, this gives a 50%/10 = 5% error tolerance in sender/receiver clock mismatch. This is an optimistic mismatch assumption; a more pessimistic calculation accounting for rise and fall times of the input signal and maximum phase mismatch uses only a 30% margin (approximately ±5 clock periods about the midpoint). This gives an error tolerance of 30%/10 = 3% error tolerance for sender/receiver clock mismatch. Observe that the error tolerance decreases linearly as the number of bit times in the frame increases; for this reason, asynchronous transmission frames are typically limited to 10 bit times. The cumulative error begins at zero on the next start bit transition since that is when the receiver begins counting internal clocks to determine the bit sampling position. The edge transition of the start bit is said to resynchronize the receiver to the bit stream. Cumulative error is not a problem for synchronous serial data transmission, which can send an unlimited number of bits per frame because the receiver remains synchronized to the serial input stream. Thus, even if asynchronous and synchronous serial channels have the same bit time, the synchronous channel has a higher effective data transfer rate because it does not have the overhead of the start and stop bits sent for every 8 data bits of the asynchronous transmission.

Figure 10.6 Phase and frequency differences between receiver and sender clocks

Figure 10.7 shows a software-based asynchronous serial data link. Two PORTB pins, RB2 (STX) and RB3 (SRX), implement transmit and receive, respectively, forming a duplex communication channel. The outCharSoft(uint8_t u8_c) function sends the 8-bit u8_c value serially from LSb to MSb using one stop bit. The doBitDelay(uint16_t u16_baudRate) function delays for one bit time. Observe that the outCharSoft() function assumes that STX is already in the idle (high) condition before sending the start bit. After sending the 8 data bits, the stop bit is sent, leaving the STX output in the idle condition.

Synchronous, Asynchronous Serial I/O

379

The inCharSoft() function returns an 8-bit value from the serial link by first waiting for a start bit (SRX becomes a 0). Once a start bit is detected, the doBitHalfDelay(uint16_t u16_baudRate) function waits until the middle of the bit time. It then loops eight times, delaying a full bit time and then reading the SRX input. The function delays for an additional full bit time before exiting to account for the stop bit (it does no checking to ensure that the received stop bit was a one). Software-driven serial links using parallel port bits can work well, but their maximum performance is limited by the accuracy of the delay functions used to implement bit delays. Also, even though the separate TX and RX lines of Figure 10.7 have the capability of implementing a duplex channel, the outCharSoft()/ inCharSoft() functions as written cannot perform duplex communication. This is because all of the CPU’s resources are either spent transmitting or receiving a character; it cannot do both simultaneously using the functions of Figure 10.7. One solution to this problem is to use dedicated hardware to implement the TX/RX functionality, as seen in the next section.

Figure 10.7 A software-based asynchronous serial data link

380

Chapter 10

■

Asynchronous and Synchronous Serial I/O

Sample Question: For asynchronous serial transmission, with 1 bit sent per signaling interval, what is the bit time in microseconds for a baud rate of 57,600? Answer: From Equation 10.1, you know that: bit time = 1/baud_rate = 1/57,600 = 1.736 × 10-5 s × 106 µs/s = 17.36 µs.

Sample Question: Assume a data format of 7 data bits + even parity. What is the parity bit value for the data 0x2A? Answer: 0x2A = 0b010 1010 (7 bits); the number of 1 bits is odd, so the even parity bit value is 1.

The PIC24 UART The PIC24 μC has an on-chip peripheral called the Universal Asynchronous Receiver Transmitter (UART, pronounced “you-art”) that implements an asynchronous data transceiver. For asynchronous transmission, a write to a special function register is all that is required in terms of CPU resources; the UART handles the details of sending the start, data, and stop bits. For asynchronous reception, the UART automatically shifts in any serial data it receives then sets a status flag indicating that data is ready. All the CPU has to do at that point is read a special function register to receive data. The UART subsystem, like others found on the PIC24 μC, uses special function registers in two different ways: either as data registers or as control registers. Data registers are either used for transferring data from the subsystem to the external pins (a write operation to an external device), or for transferring data from the external pins to the subsystem (a read operation from an external device). Control registers contain a mixture of configuration and status bits. Configuration bits specify the operating mode of the subsystem, while status bits indicate the operational state of the subsystem. PIC24 microcontrollers can have multiple UARTs (UART1, UART2, . . . UARTn) with identical capabilities, so their register names have a number (x) that designates its associated UARTx. For example, register UxTXREG is the data transmit register, and its name for UART1 is U1TXREG. This code refers to named bits in UART registers by their fully qualified structure reference (register.bitname) to make the functions portable to PIC24 microcontrollers with multiple UARTS, which do not have macros defined for individual UART register bits. The dsPIC33EP128GP502 used in this reference system has two UART modules. Figure 10.8 shows the UxMODE register that contains various control bits for UARTx transmit and receive operation. Figure 10.9 show the UxSTA register that contains both status and control bits for UARTx operation. You will learn about these various bits in the context of UART transmit, receive, and clock generation operations.

The PIC24 UART

Figure 10.8 Ux MODE: Mode register Source: Figure redrawn by author from Register 2.1 found in the dsPIC33E/PIC24E FRM UART datasheet (DS70000582E), Microchip Technology Inc.

381

382

Chapter 10

■

Asynchronous and Synchronous Serial I/O

Figure 10.9 Ux STA: Status and control register Source: Figure redrawn by author from Register 2-2 found in the dsPIC33E/PIC24E FRM UART datasheet (DS70000582E), Microchip Technology Inc.

The PIC24 UART

383

UARTx Transmit Operation As previously mentioned, the UxTXREG is the data output register for UARTx. This register is actually the entry point for a four-entry first-in, first-out (FIFO) buffer for the UxTSR register that performs the shifting of serial data through the UxTX pin, as shown in Figure 10.10. Together, the UxTXREG FIFO and the UxTSR register form a five-entry buffer. The UTXBF read-only status bit in Figure 10.9 is 0 if a free location is available in the UxTXREG buffer. The UTXBF status bit must be checked before any write is done to TXREG, as data written to a full buffer is not accepted. The UART subsystem supports either 8-bit or 9-bit operation, which is why the UxTXREG FIFO is shown as being 9 bits wide. The 9-bit operation mode is useful if the TX output goes to two different devices in a multi-processor system as the 9th bit is treated as an address bit. The code examples use 8-bit mode; see the dsPIC33E/PIC24E Family Reference Manual (FRM) [22] for more information on 9-bit operation. In 8-bit mode, the supported data formats using control bits from Figure 10.8 are even/odd/no parity, with either one or two stop bits. The same frame format is used for both transmit and receive.

Figure 10.10 UARTx transmitter block diagram Source: Figure redrawn by author from Figure 5.1 found in the dsPIC33E/PIC24E FRM UART datasheet (DS70000582E), Microchip Technology Inc.

384

Chapter 10

■

Asynchronous and Synchronous Serial I/O

UARTx Receive Operation Figure 10.11 shows the UARTx receiver block diagram. Serial data enters via the UxRX pin and the receiver block automatically shifts the data into the UxRSR register upon detection of a start bit. The UxRSR contents are transferred to the UxRXREG buffer after stop bit reception. As with the UxTXREG, the UxRXREG is actually a four-entry buffer, with the read-only status bit URXDA (receive buffer data available bit UxSTA) is 1 if data is available. The OERR bit (receive buffer overrun error status) is set to a 1 on reception of the stop bit of the fifth data word when the receive buffer already contains four data words. Data reception is inhibited until the OERR bit is cleared by the user, which clears all UxRXREG buffer contents as well as the UxRSR register. You must empty the buffer contents before clearing OERR if the buffer contents and UxRSR register value are to be preserved. The FERR bit (framing error status) is set to a 1 if the stop bit for the currently available word was read as a 0 instead of a 1. The PERR bit (parity error status) is a 1 if a parity error was detected for the currently available word. Both the FERR and PERR bits should be read before reading UxRXREG, as they reflect the status for the currently available word. Three other pin functions associated with the UART are BCLKx, UxRTS#, and UxCTS#. The BCLKx pin can be used to output the 16x baud rate clock, while pins UxRTS# and UxCTS# are used for hardware flow control when transmitting or receiving serial data. The UARTEN (UART enable, UxMODE) bit must be a 1 to enable the UART receiver block, with the UEN bits (UxMODE) further configuring the UxRX, UxTX pin operation. This code uses UEN = 00, which is the simplest operation mode, and disables the BCLKx, UxRTS#, and UxCTS# pin functions. See the dsPIC33/PIC24 FRM [22] for more information on using the hardware flow control features of the UART.

Baud Rate Configuration The baud rate (BR) for the UART is controlled by the baud rate clock generator and is calculated by Equation 10.2. The UxBRG register is the period register for a 16-bit timer. High- and low-speed modes are selected by the BRGH (high baud rate select bit, UxMODE) configuration bit, with BRGH = 1 used for high-speed mode and BRGH = 0 used for low-speed mode. BR = FCY/(S × (UxBRG+1))

(10.2)

where S = 16 (low speed) or S = 4 (high speed) The low-speed mode uses a 16x clock for sampling each bit time and can reach lower baud rates before exceeding the 16-bit range of UxBRG. The high-speed mode only uses a 4x clock for sampling each bit, but can reach higher baud rates than the low-speed mode. Equation 10.3 solves Equation 10.2 for UxBRG because PIC24 applications need the UxBRG value that is required to achieve a particular baud rate. UxBRG = [FCY/(S × BR)] − 1 (round to nearest integer)

(10.3)

The PIC24 UART

385

Figure 10.11 UART receiver block diagram Source: Figure redrawn by author from Figure 7.1 found in the dsPIC33E/PIC24E FRM UART datasheet (DS70000582E), Microchip Technology Inc.

Figure 10.12(a) shows UxBRG values for FCY = 40 MHz assuming use of the internal oscillator and PLL for some standard baud rates. The % Error column shows the actual baud rate achieved without rounding of the UxBRG value, but does not include error due to inaccuracy of the internal oscillator frequency. In theory, either high-speed mode or low-speed mode should be adequate because of the small percent error values. This code uses the low-speed mode because in practice we have found this mode to be the most reliable when using the internal oscillator. Figure 10.12(b) shows the use of an external 7.3728 MHz crystal with the PLL to obtain an internal FCY = 36.864 MHz (five times the crystal frequency). This “strange” crystal frequency provides perfect matching to

386

Chapter 10

■

Asynchronous and Synchronous Serial I/O

standard baud rates, and thus the % Error column values are zero. This is one reason why the base internal oscillator frequency is 7.37 kHz; an FOSC using this frequency or a division of this frequency provides better matching at higher baud rates.

Figure 10.12 UxBRG values for common baud rates

Using the PIC24 UART with C Support functions for the UARTx subsystems are defined in the files lib\include \pic24_uart.h and lib\src\pic24_uart.c. Figure 10.13(a) shows the uint8_t inChar1() function, which waits for a byte to be available in UART1 and then returns it. The IS_CHAR_READY_UART1() macro simply returns the U1STAbits.URXDA status bit, which is 1 if data is available in the receive buffer. The checkRxErrorUART1() function in Figure 10.13(c) checks the PERR, FERR, and OERR error status bits, and calls the reportError() function with an appropriate error message (recall that reportError() saves the error

Using the PIC24 UART with C

387

message in a persistent variable and then executes a software reset—the resulting error message is printed by the printResetCause() function). The checkRxErrrorUART1() function must be called before data is read from the U1RXREG register because the error bits reflect the status of the currently available byte in the receive buffer. The outChar1(uint8_t u8_c) function in Figure 10.13(b) writes the byte in u8_c to the UART1 transmit buffer once space is available. The IS_TRANSMIT_BUFFER_FULL_UART1() macro is used to check for space availability in the transmit buffer by returning the U1STAbits.UTXBF status bit, which is 1 if there is at least one free spot in the transmit buffer. Similar functions for UARTs 2, 3, and 4 are defined, with conditional compilation used to include the functions only if the target device supports those UARTs.

Figure 10.13 inChar1/outChar1 UART functions

Figure 10.14 shows functions for UART configuration. The utility function compute_brg() computes a 16-bit value for the UxBRG register using Equation 10.3 based on function parameters that specify the clock rate (u32_fcy), speed mode choice (u16_brgh) and desired baud rate (u32_baudrate).

388

Chapter 10

■

Asynchronous and Synchronous Serial I/O

The configUART1(uint32_t u32_baudRate) function does UART1 register and pin configuration. The function configures the U1RX and U1TX pins to use RB10 and RB11 pins, respectively, on the reference dsPIC33EP128GP502 system of Chapter 8. The compute_brg() function is called to compute the value needed by the U1BRG register to achieve the desired baud rate. The U1MODE and U1STA registers are configured to enable UART1 receive and transmit using a data format of 1 stop bit, no parity, and 8 data bits with no hardware flow control (that is, it does not use pins UxCTS# or UxRTS#).

Figure 10.14 UART configuration

Using the PIC24 UART with C

389

The various character I/O functions used thus far in these example programs such as outString(), outUint8(), inChar(), and so on, are contained in the file lib\src\pic24_serial.c. Figure 10.15 shows the uint8_t inChar() and void outChar(uint8_t u8_c) functions used for single character input/output in pic24_serial.c. Observe that the global variable __C30_UART determines the UARTx destination by selecting between inChar1, inChar2, and so on for inChar() and selecting between outChar1, outChar2, and so on for outChar(). Thus, the character I/O functions contained in pic24_serial.c can be dynamically switched between the available UARTs on a PIC24 microcontroller.

Figure 10.15 inChar()/outChar() serial I/O functions

Library Functions The C library functions supported by the PIC24 compilersuch as printf, scanf, and so on can also be used either with the functions in pic24_serial.c or in lieu of these functions. By default, the character I/O functions map to UART1 but there is a general mechanism in the PIC24 compiler for redirecting these functions to other peripherals—see the PIC24 16-bit Language Tools Libraries manual that comes with the compiler for more details. As stated previously, the examples here use a lightweight set of serial I/O functions because of the relatively large code footprint of the library, but this point may be moot if you are using a PIC24 μC with a large program memory. The examples occasionally use the printf function when they need to take advantage of its advanced formatting capabilities.

390

Chapter 10

■

Asynchronous and Synchronous Serial I/O

Interrupt-Driven I/O with the PIC24 UART As previously discussed, the receive and transmit components for the PIC24 UART can each buffer five bytes, four in the hardware FIFO and one in the shift register associated with the appropriate UxTX/UxRX pin. The receiver can experience buffer overrun if the UART receive buffer is not polled often enough by calling inChar(), while the outChar() function can waste clock cycles by waiting for a free location in the transmit buffer. Interrupts provide a more efficient method for performing UART I/O for both receive and transmit operations.

Interrupt-Driven UART Receive Figure 10.16 shows an example application that reads a string from the UART using the inString() function, reverses the string using the reverseString() function, then sends the reversed string to the UART. In this application, a string arriving from the UART is considered terminated by either a new line or a carriage return (see the source files available from www.reesemicro.com for code details on inString() and reverseString()). The problem with this application is that while a string is being reversed and then printed, another string may be arriving. As long as strings are typed manually from the console, as seen in Figure 10.16(b), the while (1) loop can finish reversing and printing a previous string before arrival of a new string causes a UART overrun error. However, if multiple strings are pasted into the console application from the paste buffer, then strings arrive too fast and UART receiver overrun occurs—Figure 10.16(c)—causing a processor reset when the checkRxErrrorUART1() function of Figure 10.13 detects the overrun error.

Figure 10.16 String reverse application

Interrupt-Driven I/O with the PIC24 UART

391

Fast bursts of input data on a communication channel can cause overrun problems if polled I/O is used on the channel. One solution to this problem is to use interrupt processing on the channel for reading data as soon as it is available then storing it in a temporary buffer until it can be read by the application. Within the UART receiver, the UxRXIF interrupt flag in Figure 10.11 is set by various data available conditions, as determined by the URXISEL bits (UxSTA) of Figure 10.9. The _UxRXInterrupt ISR is associated with the UxRXIF interrupt flag and can be used to read the UARTx receiver when data is available, instead of relying on inChar() to poll for data availability. (Using the cell phone analogy from Chapter 9, the phone rings when a call is available instead of you having to continually check the phone to see if somebody is trying to talk to you.) However, where does the _UxRXInterrupt ISR place the data after reading the UxRXREG register? The answer is a software FIFO, which operates like the hardware FIFOs of Figures 10.10 and 10.11 except that data memory locations are used for storage. Figure 10.17 shows the structure and operation of a software FIFO with eight locations. Two indexes, named head and tail, are used for accessing the buffer. The FIFO is empty when head is equal to tail. Data is written into the buffer by incrementing the head index then storing data at buffer[head]; see Figure 10.17(b). This means that data is available in the buffer whenever head is not equal to tail. Data is read from the buffer by incrementing tail then accessing data from buffer[tail]; see Figure 10.17(c). Observe that data comes out of the buffer in the same order in which it is placed into the buffer; hence the first-in, first-out (FIFO) designation. Figure 10.17(d) shows the buffer holding several characters. When the head index reaches the end of the buffer, the next write operation must wrap the head index to the beginning of the buffer; see Figure 10.17(e). For this reason, this data structure is also referred to as a circular buffer. In Figure 10.17(f), the write operation leaves the head index equal to the tail index, causing the buffer to appear empty even though it contains eight valid data items. This is buffer overrun, which means that under these rules for buffer insertion and extraction, an n-location buffer can hold a maximum of n – 1 data elements.

392

Chapter 10

■

Asynchronous and Synchronous Serial I/O

Figure 10.17 Software FIFO structure and operation

Figure 10.18 shows the implementation of the UART RX software FIFO in lib\src\pic24_uart.c. If the UART1_RX_INTERRUPT macro is defined, then the interrupt version of inChar1() is compiled instead of the polled version shown in Figure 10.13(a). The most convenient place to define the UART1_RX_INTERRUPT macro—Figure 10.18(a)—is in the MPLAB® X project associated with the application’s source files. The UART1_RX_FIFO_SIZE and UART1_RX_INTERRUPT_PRIORITY macros—Figure 10.18(b)—set the FIFO buffer size and interrupt priority, respectively, and can be overridden by the user. The inChar1() function now waits for data to be available in the buffer, indicated by u16_rxFifo1Head being not equal to u16_rxFifo1Tail; see Figure 10.18(c). When data is available, the tail index is incremented and wrapped if necessary, and the new data is returned from au8_rxFifo1[u16_rxFifo1Tail]. The _U1RXInterrupt ISR is triggered when data is available in the receive buffer. The head index is incremented and wrapped if necessary, as shown in Figure 10.18(f), and if head is equal to tail then a buffer overrun error is reported which resets the processor; see Figure 10.18(g). If no overrun is present, the new data is placed into the buffer at au8_rxFifo1[u16_rxFifo1Head]. The configUART1() function of Figure 10.14 is also modified to enable the U1RXIF interrupt when the UART1_RX_INTERRUPT macro is defined.

Interrupt-Driven I/O with the PIC24 UART

393

Figure 10.18 Interrupt-driven UART RX implementation

With UART RX interrupt processing enabled, the overrun case of Figure 10.16(c) does not occur when a few strings are pasted into the console window. However, every software FIFO has a finite size, and pasting a large number of strings into the console window will trigger the FIFO overrun error checked for in the _U1RXInterrupt ISR. In this case, the RX FIFO overrun error occurs even if no incoming string is greater than the RX FIFO size because the RX data is arriving at a steady rate.

394

Chapter 10

■

Asynchronous and Synchronous Serial I/O

The TX channel data rate is the same as the RX channel and the time spent by main() to reverse the string is non-zero, so the time spent processing and then sending outgoing data is greater than the time spent on processing incoming data. The main() task steadily loses ground to the incoming data, processing data from the RX input FIFO at points deeper in the RX FIFO buffer for each string that arrives. This process is illustrated in Figure 10.19, which tests UART RX for polled versus interrupt-driven using the reverse string application by sending various numbers of strings, each containing 11 characters (the RX software FIFO size was set to 8 bytes in this test). In Figure 10.19(a), the polled UART RX case experienced hardware RX FIFO overrun when only two strings were sent. While the processor was busy transmitting the first reversed string, the arriving second string overflowed the RX HW buffer. Figure 10.19(b) shows the interrupt-driven UART RX case. The UART functions are modified to use two PIO signals for status information. Signal RAXF is asserted by _U1RXInterrupt() when the RX SW FIFO has only one free location left, and signal TXWAIT is asserted by outChar1() when waiting for a free spot in the TX hardware FIFO. In Figure 10.19(b-1), the first string is received, reversed, and then the first five characters are dumped to the TX hardware FIFO causing the TXWAIT line to be asserted while outChar1() is waiting for a free location in the TX buffer. The lag between the last character of an RX string (LF) and the first character of the resulting reversed string (9) is very short. However, this gap has increased to about 1.5 character transmission times after nine RX strings have been reversed—see Figure 10.19(b-4). Also, the software FIFO is now almost full (has one free location left) as evidenced by assertion of RAXF. In Figure 10.19(b-3), the TX wait in outChar1() ends because it has reached the last five characters of the reversed string that is being sent, so they all fit in the TX HW buffer. This means the inString() function starts emptying the RX software FIFO before the arrival of the next character (8) that would trigger overflow. However, the TX of reversed strings lags further as more strings are received, and after 14 strings, the RX software FIFO overflows, as shown in Figure 10.19(c). An RX FIFO size is based on the maximum data burst size that is expected on that channel. If data is arriving at a continuous rate that is faster than what the CPU can process, then no amount of data buffering prevents overrun as eventually the software FIFO fills up. An example of a continuous data stream is an environmental sensor that outputs data at fixed intervals as long as the sensor is powered on. For a periodic input data stream, the time spent processing the output data must be less than that spent on the input data. You’ll revisit the problem of handling continuously arriving data later in this chapter.

Interrupt-Driven UART Transmit Interrupt-driven UART transmit augments the size of the TX hardware FIFO by adding a software FIFO that data is written to first before it is transferred to the UART TX HW buffer. Within the UART transmitter, the UxTXIF interrupt flag in Figure 10.10 is set by various conditions as determined by the UTXISEL bits (UxSTA) of Figure 10.9. This example uses the default

Interrupt-Driven I/O with the PIC24 UART

395

configuration of 00, which sets the UxTXIF interrupt flag when data is transferred from the TX buffer to the transmit shift register, guaranteeing a free location in the transmit buffer. In this approach, the outChar1() function places data into a software FIFO buffer, and the TX ISR transfers data out of the software FIFO buffer and into the UART transmit buffer as the TX ISR is triggered whenever a free location is available in the UART TX buffer. This is the reverse of the interruptdriven RX UART code, in which the RX ISR placed data into the software FIFO and the inChar() function took data out of it.

Figure 10.19 UART RX: Polled versus interrupt-driven testing

396

Chapter 10

■

Asynchronous and Synchronous Serial I/O

Figure 10.20 shows the C code implementation for interrupt-driven UART transmission. The UART1_TX_INTERRUPT macro (a) selects the interrupt-driven outChar1() function, which increments and wraps (d) the head index using a temporary variable named u16_tmp in order to compare it against the tail index (e). As long as the tail index (u16_txFifo1Tail) is equal to the head index (u16_txFifo1Head) the software-transmit FIFO buffer is full and the function loops until the background TX ISR frees a location in the software FIFO buffer. The u8_c parameter passed to outChar1() is then placed in the buffer at location au8_txFifo1[u16_txFifo1Head] (f).

Figure 10.20 Interrupt-driven UART TX implementation

Interrupt-Driven I/O with the PIC24 UART

397

Next, the TX interrupt is enabled by setting _UTXIE (g). If an empty location exists in the UART TX transmit buffer as indicated by the U1TXIF flag being set, then an immediate jump is made to the TX ISR. Otherwise, the UART TX transmit buffer is full, so U1TXIF is cleared. In this case, the byte remains in the software TX FIFO until the current character in the TX shift register is finished transmitting and a byte is transferred from the UART TX transmit buffer to the TX shift register, freeing a location in the TX transmit buffer, setting the U1TXF flag, and causing a jump to the TX ISR. The TX ISR (_U1TXInterrupt) first checks to see if data exists in the software FIFO by comparing the head index against the tail index. If the software FIFO is empty, the TX interrupt is disabled by clearing _UTXIE (h), but the U1TXIF flag is not cleared because it should remain set as long as an empty location exists in the TX transmit buffer. This is one of the few cases where an interrupt flag is not cleared before exit; instead, the interrupt is disabled so that the interrupt flag’s true condition does not immediately generate a jump back to the ISR after ISR exit. If data exists in the software FIFO then the tail index is incremented, wrapped if necessary (i), and the data from the software FIFO at au8_txFifo1[u16_txFifo1Head] is transferred to the UART TX buffer (j). In this condition, the U1TXIF flag is cleared before exit so that it can be set again once the currently transmitting character is finished. Listing 10.1 shows the source code for the configUART1() function originally given in Figure 10.14 modified to include conditional compilation for interrupt-driven RX/TX. In the case of interruptdriven RX, the _U1RXIF flag is cleared (_U1RXIF = 0) before the RX interrupt is enabled (_U1RXIE = 1). The _U1RXInterrupt ISR is triggered by arrival of RX data, and thus you need this interrupt enabled when the UART is configured. However, the code for interrupt driven TX only sets the interrupt priority, neither clearing the TX interrupt flag nor enabling the interrupt. This is because the TX interrupt flag is set when the UART is initialized and must remain set in order to trigger the _U1TXInterrupt ISR once a character is placed in the TX software FIFO by the outChar1() function, which enables the TX interrupt. Listing 10.1: configUART1() Source Code void configUART1(uint32_t u32_baudRate) { CONFIG_RP10_AS_DIG_PIN(); // RX RP pin must be digital CONFIG_U1RX_TO_RP(RB10_RP); // U1RX RB11 U1MODE = (0 > 10) + u16_minPWTicks; // >> 10 is same as divide by 1024 OC1RS = u32_temp; // Update pulse width value AD1CON1bits.SAMP = 1; // Start next ADC conversion for next interrupt }

PWM Control of Multiple Servos The code of Listing 12.4 uses the OC1 output to directly control one servo. However, if an application requires more servos than available PWM outputs, then how is multi-servo control accomplished? The answer is to use software control of digital outputs, with the output compare ISR controlling the digital ports used for the servo outputs, as shown in Figure 12.32. The PWM period is divided into slots, with each servo assigned a slot time in which its pulse width is varied. Using a conservative slot time of 2.8 ms means that up to seven servos can be controlled in a 20 ms period (20/2.8 = 7.1). An OCx interrupt is generated for each edge of a servo’s output, with an array used for storing servo pulse widths and variables used to track the current edge and current servo. After the falling edge of the last servo’s pulse has occurred, the OCx ISR sets the next output compare interrupt to occur at the end of the 20 ms period. This approach requires only one output compare module and one timer, with the timer’s period equal to the PWM period.

Figure 12.32 Multi-servo control scheme

PWM Application: DC Motor Speed Control and Servo Control

527

Listing 12.5 shows variable declarations and initialization code for the multi-servo control, with four servos used for this example. The initServos() function configures the four ports chosen for servo control and initializes them to low. The au16_servoPWidths[] array holds the pulse widths of the servos in Timer2 ticks. These entries are initialized to a value equivalent to 1500 μs, which is the servo’s neutral position. Timer2 is initialized to a period equal to 20 ms, with its interrupt disabled. The OC1 module is initialized to toggle mode, but the OC1 output is not mapped to a pin as you only care about the output compare interrupt and not the OC1 output. The OC1R register is initialized to 0, which means that the first OC1IF interrupt occurs at the first Timer2 rollover. Listing 12.5: Initialization Code for Multi-Servo Control #define #define #define #define #define #define

PWM_PERIOD (20000) NUM_SERVOS (4) SERVO0 (_LATB2) SERVO1 (_LATB3) SERVO2 (_LATB13) SERVO3 (_LATB14)

#define MIN_PW (600) #define MAX_PW (2400) #define SLOT_WIDTH (2800) volatile volatile volatile volatile

// In microseconds

// Minimum pulse width, in us // Maximum pulse width, in us // Slot width, in us

uint16_t au16_servoPWidths[NUM_SERVOS]; uint8_t u8_currentServo = 0; uint8_t u8_servoEdge = 1; // 1 = RISING, 0 = FALLING uint16_t u16_slotWidthTicks = 0;

void initServos(void) { uint8_t u8_i; uint16_t u16_initPW; CONFIG_RB2_AS_DIG_OUTPUT(); CONFIG_RB3_AS_DIG_OUTPUT(); CONFIG_RB13_AS_DIG_OUTPUT(); CONFIG_RB14_AS_DIG_OUTPUT(); u16_initPW = usToU16Ticks(MIN_PW + (MAX_PW - MIN_PW)/2, getTimerPrescale(T2CONbits)); // Config all servos for half maximum pulse width for (u8_i = 0; u8_i < NUM_SERVOS; u8_i++) au16_servoPWidths[u8_i] = u16_initPW; SERVO0 = 0; // All servo outputs low initially SERVO1 = 0; SERVO2 = 0; SERVO3 = 0; u16_slotWidthTicks = usToU16Ticks(SLOT_WIDTH, getTimerPrescale(T2CONbits)); }

528

Chapter 12

■

Timers

void configTimer2(void) { T2CON = T2_OFF | T2_IDLE_CON | T2_GATE_OFF | T2_32BIT_MODE_OFF | T2_SOURCE_INT | T2_PS_1_256 ; // 1 tick = 1.6 us at FCY=40 MHz PR2 = usToU16Ticks(PWM_PERIOD, getTimerPrescale(T2CONbits)) - 1; TMR2 = 0; // Clear timer2 value } void configOutputCapture1(void) { T2CONbits.TON = 0; // Disable Timer when configuring Output compare OC1R = 0; // Initialize to 0, first match will be a first timer rollover. // Turn on the compare toggle mode using Timer2 // Timer2 source, single compare toggle, just care about compare event #ifdef OC1CON1 OC1CON1 = OC_TIMER2_SRC | OC_TOGGLE_PULSE; OC1CON2 = OC_SYNCSEL_TIMER2; //synchronize to timer2 #else OC1CON = OC_TIMER2_SRC | OC_TOGGLE_PULSE; #endif _OC1IF = 0; _OC1IP = 1; _OC1IE = 1; //enable the OC1 interrupt }

Figure 12.33 shows the code for the OC1 ISR and main(). The variable u8_currentServo is used to track the current servo (0 to N-1), while variable u8_servoEdge is the current edge transition (1 for rising edge, 0 for falling edge). The _OC1Interrupt ISR first sets the current servo’s output high or low based on the u8_servoEdge variable. The next interrupt is then scheduled. For a rising edge, the next interrupt must occur at the falling edge of the servo output, which occurs at the current OC1R value plus the current servo’s pulse width. For the falling edge of a servo that is not the last servo, the next interrupt is the rising edge of the next servo, which is the start of the next servo’s slot and is calculated as u16_slotWidthTicks*(u8_CurrentServo + 1). For the falling edge of the last servo, the next interrupt occurs at the end of the period, so OC1R is cleared to 0. The main() code performs initialization, with the while (1) loop calling a helper function that allows a servo’s pulse width to be changed from the console for testing purposes. Figure 12.34 shows a logic analyzer capture of the four servo outputs with the pulse widths set to different values; the period was set to 12 ms to emphasize the pulse width differences.

PWM Application: DC Motor Speed Control and Servo Control

Figure 12.33 Multi-servo OC1 ISR and main()

Figure 12.34 Multi-servo logic analyzer capture

529

530

Chapter 12

■

Timers

A PWM DAC Notice: This section assumes some reader knowledge of low-pass RC filters; portions of this material may be difficult to understand without this background. Another application of PWM is as a “poor man’s digital-to-analog converter” in which the PWM signal is applied to a series resistor/capacitor network to produce a DC voltage that is proportional to the PWM duty cycle. This is illustrated in Figure 12.35(a). Passing this DC voltage to a unity-gain operational amplifier provides necessary current drive and prevents the load receiving this analog voltage from affecting the PWM DAC output. In this configuration, the operational amplifier provides a gain of 1 (unity gain, voltage follower configuration), with the current draw from the RC network being negligible due to the high input impedance characteristic of this operational amplifier configuration.

Figure 12.35 A PWM digital-to-analog converter

A PWM DAC

531

The RC series network forms a low-pass filter that is driven by the PWM signal. The low-pass filter removes most of the high-frequency content (e.g., the switching component) of the PWM signal, leaving only the (non-switching) DC component behind, which is averaged by the capacitor storage. The average value at the low-pass filter output is the desired DAC output. Figure 12.35(c) shows a PWM signal with a 50 percent duty cycle, meaning the PWM signal is high 50% of the time. The RC filter removes the high frequency components and thus Vc = Vout = Vref/2. Figure 12.35(d) shows a result with a 12.5 percent duty cycle PWM signal where Vc = Vout = Vref/8. The voltage ripple in Figure 12.35(b) is the high frequency content of the PWM signal that has been attenuated by the low-pass filter. Let’s examine the passive RC low-pass filter in Figure 12.35(a). The filter’s cutoff frequency in Hz is f0 = 1/(2πRC). Beyond the cutoff frequency, the filter attenuates the PWM signal frequencies at 20 dB/decade. Therefore, you can expect the PWM signal components at 10*f0 to be approximately 20 dB below those components at f0, and signal components at 100*f0 to be attenuated 20 dB below those at 10*f0 and 40 dB below those at f0. With this information, you can see that if the PWM frequency is well beyond the low-pass filter’s cutoff frequency, so switching (high frequency) components will be greatly attenuated leaving behind only the PWM’s low frequency components near DC. This filtering gives the desired result, as a signal’s DC component is equivalent to its average value. It takes a total time of five RC time constants to achieve 99.3 percent of a delta voltage change in the PWM DAC’s output voltage, with typically several PWM periods occurring during this time. Selection of the exact RC filter values is application specific, but some general rules of thumb can be helpful in getting started. Try using f0 equal to 5–10 times the PWM DAC’s update frequency. The PWM frequency should be far into the low-pass filter’s stop band to reduce output ripple. PWM frequencies should be at least 100 times the low-pass filter cutoff so that PWM switching signal components are reduced by 40 dB or more. The PWM frequency can be reduced if the lowpass filter has stronger attenuation; multiple RC low-pass filter sections can be cascaded with each section providing an additional 20 dB/decade attenuation. Higher PWM frequencies means lower voltage ripple, but less fidelity in pulse width control. Larger RC time constants also means lower voltage ripple, but require longer to reach the new DC value after a pulse width change. LCD displays that require positive and negative bias voltages outside of the supply rails often use a PWM signal driving a charge pump circuit to produce these voltages. If the PWM DAC is only to supply a fixed reference voltage (i.e., the PWM pulse width is not changed or changed infrequently), the previous paragraph’s recommendations can be relaxed, with the principal goal being to produce a reference voltage that meets some maximum voltage ripple specification. Equation 12.7 gives an approximate value for the RC time constant given a VDD power supply voltage (volts), desired ripple (volts), and PWM period (seconds). Equation 12.7 assumes that the RC time constant is at least 10 times greater than the PWM period. RC = (VDD x PWM period x 0.37)/ripple

(12.7)

532

Chapter 12

■

Timers

For example, if VDD = 3.3 V, PWM period = 0.5 ms (2 kHz), and ripple = 0.1 V, then RC is computed as 0.0061 s. An RC time constant of 0.0061 can be approximated by using common R, C component values of R = 6.2 kΩ, C = 1.0 μF. Figure 12.36 shows two oscilloscope captures for the design as specified. The transitions are from 3.0 V to 1.0 V and vice-versa. The measured transition time was 30 ms, which is 60 PWM periods and approximately five RC time constants. Measured ripple was 70 mV.

Figure 12.36 PWM DAC test

Time Keeping Using Timer1 and RTCC (PIC24H/F Families) Timer1 is referred to as a Type A timer in the Family Reference Manual, and it is different from Timer2 (Type B) and Timer3 (Type C) in that it cannot be operated in a 32-bit mode but can be driven by the secondary oscillator (external pins SOSCI and SOSCO). Timer2 and Timer3 can be driven by an external clock pin (TxCK), but not by the secondary oscillator. The secondary oscillator is a common feature found on the PIC24H/F families but is on very few devices in the PIC24E family (it is not included in the dsPIC33EP128GP502 CPU used in the Chapter 8 reference system). One use for the secondary oscillator is for real-time clock keeping (seconds, minutes, and hours) using a 32.768 kHz watch crystal. An interrupt occurs every second using this clock frequency with a period register of 0x7FFF (the period is 0x7FFF + 1 = 0x8000 = 32768 timer ticks, which is 1 second for a 32.768 kHz clock). Real time can be kept by incrementing a variable on each interrupt. See the Family Reference Manual [19] for details on the Timer1 configuration register and block diagram, as it is very similar to Timer2.

Time Keeping Using Timer1 and RTCC (PIC 24H/F Families)

533

Figure 12.37 shows code that assumes a 32.768 kHz crystal on the secondary oscillator, with the _T1Interrupt ISR incrementing the u16_seconds variable on each interrupt. The configTimer1() function configures Timer1 for an external clock, prescale of 1, PR1 value of 0x7FFF, and the interrupt is enabled. Timer1 is also configured to remain operational during sleep mode by using the T1_IDLE_CON mask. The main() function enables the secondary oscillator amplifier by setting the SOSCEN bit (OSCCON) using the PIC24 compiler’s __builtin_write_OSCCONL function. This built-in function does the necessary unlock sequence required to make changes to the OSCCON register. The external crystal will not oscillate if this amplifier is disabled. The while (1) loop prints the u16_seconds variable, then sleeps. Because Timer1 is using an external clock and is configured for operation during sleep, its interrupt can be used to wake the processor from sleep mode.

Figure 12.37 Keeping real time with Timer1

534

Chapter 12

■

Timers

The Real-Time Clock Calendar Module There is more to time keeping than just keeping track of seconds, and the Real-Time Clock Calendar (RTCC) module [42] on some PIC24F/H family members and a few PIC24E family members can track seconds, minutes, hours, days of the week, days of the month, months, and years using an external 32.768 kHz clock. The code example in this section is for the RTCC module found in the PIC24H family and was tested on a PIC24HJ64GP502 CPU. The RTCC module capabilities are fairly extensive, and this section only highlights the basic features of the module. Figure 12.38 shows the RTCC block diagram; observe that the clock/calendar time-keeping registers are each 8 bits wide and BCD encoded (see Chapter 7). Besides toggling the RTCC output, the alarm feature allows an interrupt to be generated on a match of the clock registers with the alarm registers.

Figure 12.38 RTCC block diagram Source: Figure redrawn by author from Figure 37.1 found in the PIC24H FRM datasheet (DS70310A), Microchip, Technology Inc.

Time Keeping Using Timer1 and RTCC (PIC 24H/F Families)

535

The main control register for the RTCC is named RCFGCAL (see the FRM [42] for details). The RTCPTR (RCFGCAL) pointer bits are used to access the RTCC registers using 16-bit accesses to the RTCVAL register. When the RTCPTR bits are initialized to 11, the first 16-bit access goes to UI:Year, after which RTCPTR is auto decremented so that the next access is to Month:Date, and so on. Furthermore, accesses to the RTCC registers require a special unlock sequence similar to that required for the OSCCON register. When writing to the RTCC registers, it is recommended by the FRM that the module be disabled. A status bit named RTCSYNC (RCFGCAL) is true when register rollover is 32 clock edges (~ 1 ms) from occurring; this is useful for determining when it is safe to read register values. Figure 12.39 shows the first part of a test program for the RTCC. The unionRTCC union contains two declarations, a struct named u8 that provides byte access to the RTCC registers and a uint16_t array named regs that allows 16-bit accesses to the registers. The getDateFromUser() function is used to read the initial date and time settings from the console. The getBCDvalue(char* sz_1) utility function is called by getDateFromUser() for each date/time component. The sz_1 parameter is a string used to prompt the user to enter a two-digit ASCII decimal value that is placed into sz_buff. This ASCII decimal string is then converted to binary by the sscanf function, which is then converted to a BCD 8-bit value that is returned by the function. Each of the BCD date/time components read by getDateFromUser() are stored in their appropriate u8 member of the global variable u_RTCC, which is of type unionRTCC. Figure 12.40 shows the second part of the RTCC test code. The setRTCC() function copies data from the global variable u_RTCC into the RTCC registers. The builtin_write_RTCWEN() function provided by the PIC24 compiler does the unlock sequence for the RTCC registers and sets the RTCWEN bit, allowing register modification. The RTCEN bit is cleared, disabling the module, which is suggested by the FRM during register updates. The RTCPTR bits are set to 3, and a loop does four 16-bit writes that copies data from u_RTCC to entry register RTCVAL. As mentioned earlier, each 16-bit write auto-decrements the RCCPTR bits, so each write goes to a different register pair in the RTCC. The end result is that the different time/date components of u_RTCC are written to the correct RTCC registers. Before exiting, the RTCC module is enabled by setting RTCEN, and register writes are disabled by clearing RTCWREN. The readRTCC() function does the reverse of writeRTCC(); data is copied from the RTCC registers into the u_RTCC global variable. The printRTCC() function prints time/data components from u_RTCC to the console. The main() function sets the initial time/date setting for the RTCC using the getDateFromUser() and setRTCC() functions. The while (1) loop is then entered, which monitors the RTSYNC bit to determine when it is safe to read the RTCC registers without a date or time rollover occurring during the read, which could return inconsistent data. After the RTSYNC bit is set, the RTCC registers are read and printed to the console using the readRTCC() and printRTCC() functions.

536

Chapter 12

■

Timers

Figure 12.39 RTCC example code (part 1)

Two tests of the RTCC code are shown in Figure 12.41. The left-side console output shows the data rolling over from midnight of December 31, 2015, to the next day, which is the beginning of a new year. The right-side test shows a leap year test of rolling over from February 28 to February 29 in the year 2016.

Time Keeping Using Timer1 and RTCC (PIC 24H/F Families)

537

Figure 12.40 RTCC example code (part 2)

Figure 12.41 RTCC test output

538

Chapter 12

■

Timers

Summary All of the Timerx subsystems of the PIC24 μC family, designated as Type A (Timer1), Type B (Timer2, 4, 6, and so on), and Type C (Timer3, 5, 7, and so on) are 16-bit timers that can be clocked from an internal (FCY) or external source and have a prescaler with possible values of 1, 8, 64, and 256. Additionally, the Type B and Type C timers can be combined to form a single 32-bit timer. The input capture module is used for performing accurate pulse width or period measurement. Input capture was used to decode a biphase-encoded IR signal generated by a universal remote control. The output capture mode can be used for hardware generation of various types of pulse trains, including pulse width modulation, which varies the duty cycle of a fixed period square wave. Applications of PWM include servo positioning and DC motor speed control. The secondary oscillator found on some members of the PIC24 μC family can be used with a 32.768 kHz watch crystal and Timer1 for simple timekeeping. Complete time/date timekeeping is provided by the RTCC module found on some members of the PIC24 μC family.

Review Problems 1. Refer to Figure 12.9 and assume a 40 MHz FCY and a prescale value of 8 for Timer2 operating in 16-bit mode, with PR2 = 0xFFFF. Assume that the first input capture has a value of 0xA000 and the second input capture a value of 0x1200, with one Timer2 overflow between captures. How much time has elapsed between the captures? Give the answer in microseconds. 2. Refer to Figure 12.9 and assume a 40 MHz FCY and a prescale value of 8 for Timer2 operating in 16-bit mode, with PR2 = 0xFFFF. Assume that the first input capture has a value of 0x0800 and the second input capture a value of 0xE000, with three Timer2 overflows between captures. How much time has elapsed between the captures? Give the answer in milliseconds. 3. Assume Timer2/3 operating in 32-bit mode with a 20 MHz FCY and a prescale value of 64. How long does it take for this timer to overflow? Give the answer to the nearest second. 4. Assume Timer2/3 operating in 32-bit mode with a 20 MHz FCY and a prescale value of 256. How many Timer2/3 ticks are contained in two seconds? 5. Assume a 40 MHz FCY and a prescale value of 8 for Timer2 operating in 16-bit mode. Input capture has measured 2,000 ticks between the rising edges of a square wave. What is the square wave’s frequency in kHz? 6. Assume a 16 MHz FCY and a prescale value of 1 for Timer2 operating in 16-bit mode. You want to use input capture to measure the frequency of a square wave. What is the highest frequency that can be measured assuming that you want at least four ticks per square wave period?

Review Problems

539

7. Assume a 20 MHz FCY and a prescale value of 8 for Timer2 operating in 16-bit mode. Also assume that an output compare module has been configured for pulse width modulation using a 10 ms period. What OCxRS register value is required to produce a pulse width of 5 ms? 8. Assume a 40 MHz FCY and a prescale value of 64 for Timer2 operating in 16-bit mode. Also assume that an output compare module configured for pulse width modulation using a 20 ms period is being used to control an HS-311 servo. What OCxRS register value is required to produce to position the servo arm at 45°? 9. Assume a 16 MHz FCY and a prescale value of 256 for Timer2 operating in 16-bit mode. Also assume that an output compare module configured for pulse width modulation using a 15 ms period is being used to control the speed of a DC motor using the scheme of Figure 12.30. What OCx RS register value is required to run the motor at 1/3 full speed (assume a linear relationship between DC motor speed and pulse width)? 10. Assume an input capture pin is being used to monitor the U1RX pin. Describe an approach for computing the baud rate of a connection assuming that a few 0x55 characters are sent to the port. (You do not have to write code, just describe the approach you would use and why it would work.)

This page intentionally left blank

Chapter 13

Advanced Hardware Topics

T

his chapter discusses various advanced hardware topics such as direct memory access (DMA), the Controller Area Network (CAN), and I 2C multi-master operation. This chapter also discusses using the self-programming capability of the PIC μC for non-volatile data storage and use of the comparator module.

Learning Objectives After reading this chapter, you will be able to: ■ ■ ■

■ ■

■

Use the direct memory access (DMA) capability for data transfer from peripheral modules. Use the PIC24 μC as an I2C slave. Discuss bus arbitration for multi-master busses and how bus arbitration is accomplished for CAN and I2C busses. Use two PIC24 μC as masters on an I2C bus. Compare and contrast features of the Controller Area Network (CAN) with the other serial interface standards used by the PIC24 μC. Have the PIC24 μC use its program memory for data storage purposes.

541

542

Chapter 13

■

Advanced Hardware Topics

Direct Memory Access Direct memory access (DMA) refers to hardware-assisted data transfers between memory and peripherals (both on-chip and off-chip) with minimal CPU intervention. DMA reduces the CPU overhead for data transfer and can be used to aid both single burst and continuous transfers. Some members of the PIC24 family, such as the dsPIC33EP128GP502, have a flexible DMA controller module whose block diagram is shown in Figure 13.1. Because of the DMA module’s complexity, this section highlights a portion of the module’s features and shows one code example that uses DMA transfer. See the DMA section [44] of the FRM for full details. DMA memory transfers operate with no CPU stalls when using a special dual-ported SRAM memory (DPSRAM); although standard SRAM may also be used, this incurs the penalty of CPU stalls, where the CPU must wait until a DMA transfer completes and vice versa. The term dual-ported means that the DPSRAM can be accessed simultaneously by both the DMA module and the CPU without requiring either to wait. Data is either transferred from a peripheral to (DP)SRAM, or from (DP)SRAM to a peripheral as specified by registers within each DMA channel. A DMA channel can transfer in only one direction, and there is a natural priority with channel 0 being highest and 7 the lowest if simultaneous DMA requests occur.

Figure 13.1 DMA module block diagram. Source: Figure redrawn by author from Figure 22.2 found in the PIC24 FRM (DS70223A), Microchip Technology Inc.

Direct Memory Access

543

Each channel has the following registers: ■

DMAx CON: Control register for the DMA module.

■

DMAx REO: Associates a peripheral interrupt request with a channel.

■

■ ■

DMAx STAH/L, DMAx STBH/L : (DP)SRAM starting address registers A and B; these registers specify starting locations in the (DP)SRAM for the transfer. These store a 24-bit bit address, which is divided into the upper 8 bits (DMAxSTAH, DMAxSTBH) and the lower 16 bits (DMAxSTAL, DMAxSTBL). In this book, the terms DMAxSTAH/L and DMAxSTA are used interchangeably; the same is true for DMAxSTBH/L and DMAxSTB. Some transfer modes require register A or B, while others require both. DMAx PAD: Contains the address of the peripheral data register involved in the transfer. DMAx CNT: Specifies the number of transfers required to complete a DMA request; for N transfers, this must be initialized to a value of N − 1.

There are also five global registers (DSADR, DMAPWC, DMARQC, DMALCA, and DMAPPS) used for status information on the most recent DMA transfer (see the FRM [44] for more information). The DMAxCON register details are shown in Figure 13.2. The addressing mode (AMODE) bits determine how a DMA address register steps through the (DP)SRAM buffer during a transfer. The default mode is post-increment, which means that the address buffer increments after a transfer. Once DMAxCNT+1 transfers have been performed when using post-increment mode, the DMA address register is at the end of the buffer and the address register is automatically reset back to the start of the (DP)SRAM buffer. This operates in the same manner as the head index used for the software FIFO discussed in Chapter 10. The addressing mode without post-increment always performs the transfer from the same location in (DP)SRAM. The peripheral indirect addressing mode is a special mode supported only by the ADC and ECAN™ (discussed later in this chapter) modules in which the peripheral provides the (DP)SRAM address for the transfer. The HALF bit determines if a DMA channel interrupt is generated after half of the transfers ((DMAxCNT+1)/2) have occurred, or after all of the transfers have been performed (DMAxCNT+1). DMA operation modes (MODE) use either one (DP)SRAM buffer or two (DP)SRAM buffers (ping-pong mode) and are either oneshot or continuous. In one-shot single buffer mode, once DMAxCNT+1 transfers have been performed, the DMA module is automatically disabled (the CHEN bit in the DMAxCON register is cleared). In continuous mode, transfers continue as long as the module is enabled. The ping-pong mode implements the ping-pong buffering scheme discussed near the end of Chapter 10 (Figure 10.63). The first DMAxCNT+1 transfers use the DMAxSTA buffer, then the next DMAxCNT+1 transfers are performed using the DMAxSTB buffer. This allows the CPU to either fill or empty the DMAxSTA buffer while DMA transfers use the DMAxSTB buffer. After DMAxCNT+1 transfers are performed using the DMAxSTB buffer, then the next DMAxCNT+1 transfers are performed using the DMAxSTA buffer, and thus DMA transfers ping-pong between the DMAxSTA and DMAxSTB buffers. In one-shot ping-pong mode, the DMA module is disabled after DMAxCNT+1 transfers are done with both buffers. The null data write mode (NULLW

544

Chapter 13

■

Advanced Hardware Topics

bit is set) is a special mode intended for use with SPI receive transfers in which dummy data (a null data byte) are written to the SPI port to trigger each SPI receive. Without the NULLW mode, a second DMA channel would have to be used to feed null data bytes to the SPI port to generate the received SPI data.

Figure 13.2 DMAxCON: Channel configuration register Source: Figure redrawn by author from Register 22.1 found in the dsPIC33E/PIC24E FRM (DS70348C), Microchip Technology, Inc.

Figure 13.3 shows the details for the DMAxREQ register, which is used to associate a peripheral interrupt request with the DMA channel. When a peripheral’s interrupt request flag is set, this triggers the DMA transfer, which is typically how the DMA transfer is accomplished. However, the application can also force a transfer by setting the FORCE bit (DMAxREQ).

Direct Memory Access

545

Figure 13.3 DMAxREQ: Channel IRQ select register Source: Figure redrawn by author from Register 8.2 found in the dsPIC33EP128GP502 datasheet (DS70000657H), Microchip Technology, Inc.

The following steps are required for DMA setup: 1. Write the address of the peripheral’s data register used for the transfer to the DMAxPAD register so that the DMA module knows where to read or write peripheral data. Also write the DMAxREQ IRQSEL bits with the peripheral’s IRQ number. 2. Configure the peripheral module to set its interrupt flag for each requested data transfer. Because the DMA module cannot perform error checking during the transfer (such as detecting a parity error or framing error for UART receives), any error checking must be done by the application on an interrupt-driven basis (such as using the U1EIF flag and the _U1ErrInterrupt() ISR for UART1 RX error checking, see Figure 9.3 of Chapter 9). 3. Configure the DMAxSTA address registers and the DMAxSTB address registers (only for ping-pong modes) with the (DP)SRAM addresses for the transfers. The MPLAB PIC24 compiler has a convenient built-in function for accomplishing this, as you’ll see in the code example.

546

Chapter 13

■

Advanced Hardware Topics

4. Initialize the DMAxCNT register with the number of transfers to accomplish. 5. Configure and enable the DMA module by writing to the DMAxCON register. To illustrate DMA module usage, you’ll implement the streaming data application discussed in the last section of Chapter 10 that captures UART RX data and writes it to the 24LC515 serial EEPROM using DMA channel 0 in continuous ping-pong buffer mode. Figure 13.4 shows the C code for the DMA channel 0 configuration, the _U1ErrInterrupt() ISR, and the _DMA0Interrupt() ISR. The two buffers of Figure 10.63 that are used for capturing input data are implemented as DPSRAM buffers au8_bufferA and au8_bufferB, which are each 64 bytes. The space(dma) attribute requires these buffers to be located in the DMA DPSRAM memory space. The configDMA0() function accomplishes steps 1, 3, 4, and 5 of the channel 0 configuration, with step 2 (UART configuration) accomplished by the configDefaultUART() function called by configBasic() within main(). For step 1, the assignment DMA0PAD = (unsigned int) &U1RXREG;

assigns the address of the UART1 RX register to the DMA0PAD register, causing the DMA module to read from U1RXREG for each transfer. Also in step 1, the assignment DMA0REQ = DMA_IRQ_U1RX;

associates the UART1 RX receive interrupt with channel 0, triggering a DMA transfer for each received character. For step 3, the assignments DMA0STAH DMA0STAL DMA0STBH DMA0STBL

= = = =

0x0000; __builtin_dmaoffset(au8_bufferA); 0x0000; __builtin_dmaoffset(au8_bufferB);

copy the DMA RAM addresses of buffers au8_bufferA and au8_bufferB to DMA address registers DMA0STA and DMA0STB. For step 4, the assignment DMA0CNT = DMA_TRANSFER_SIZE - 1;

// DMA_TRANSFER_SIZE is 64

sets the number of transfers to DMA_TRANSFER_SIZE, which is a value of 64, the size of each buffer. For step 5, the DMA0CON register is configured to enable the DMA module, place it in the continuous ping-pong mode, select a transfer direction of peripheral to buffer using post-increment buffer addressing, and to generate an interrupt after a buffer is full. The configDMA0() function also enables the UART receive error and DMA channel 0 interrupts. The _U1ErrInterrupt() ISR is triggered on a UART1 RX error and calls the checkRxErrorUART1() function, whose code was originally shown in Figure 10.13 and that generates a software reset on parity, framing, or overrun errors. The _DMA0Interrupt() ISR is triggered once a buffer is full and toggles the u1_bufferFlag that indicates which buffer is currently being filled by the DMA channel. The _DMA0Interrupt() ISR also sets the u1_writeFlag semaphore to inform main() that a buffer is ready to be written to the EEPROM.

Direct Memory Access

Figure 13.4 DMA example code (part 1)

547

548

Chapter 13

■

Advanced Hardware Topics

Figure 13.5 shows the main() code of the DMA example; this is a modified version of the EEPROM example main() code originally shown in Figure 10.60. This main() implements the flowchart of Figure 10.65, in which the write mode waits for a buffer to fill as indicated by the u1_writeFlag semaphore, then writes the full buffer to EEPROM as indicated by the u1_activeBuffer flag. The memWriteLC515() function used in this program has been modified from the original code shown in Figure 10.59 in that the data buffer contains only 64 locations and its first two locations are not reserved for holding the u16_MemAddr address. The modified memWriteLC515() function does not use the

Figure 13.5 DMA example code (part 2)

Using the PIC24 µC as an I2C Slave

549

memWriteNI2C1() transaction function, but instead uses primitive I2C function calls to write the 64

data bytes to the EEPROM (the source code can be found on the book’s accompanying website). The read mode in Figure 13.5 simply reads bytes out of the EEPROM in 64-block quantities and then echoes them to the console. A pause mode for console output is toggled via console input. DMA can be very useful for reducing CPU overhead in streaming data applications such as audio input or output, or packet-oriented transfers such as Ethernet. For example, the while (1) loop of main() in Figure 13.5 only has to intervene when 64 characters are received, and could be performing some other task during the arrival of these bytes.

Using the PIC24 µC as an I2C Slave In the I2C examples in Chapter 10, the PIC24 μC was always used as the bus master. However, the PIC24 μC can also function as an I2C slave, which is useful when embedding a μC within a product that requires an I2C interface. To illustrate this capability, we use the reverse string application that was originally given in Chapter 10 for demonstrating PIC24 μC operation as a SPI slave. The PIC24 μC master reads a string from the console and writes it to the PIC24 μC slave, which reverses the string as shown in Figure 13.6. The PIC24 μC master then reads the reversed string from the PIC24 μC slave and displays it on the console. In the SPI master/slave string example of Chapter 10, a PIO output from the slave was used as an output ready signal to the master to indicate when the reversed string was ready. In this example, the handshaking signal is dispensed with, as the master’s read transaction to the slave completes whenever the reversed string data is ready for transmission.

Figure 13.6 PIC24 µC Master to PIC24 µC slave using the I2C bus

550

Chapter 13

■

Advanced Hardware Topics

Figure 13.7 gives the master code for the application of Figure 13.6. For I2C communication, an I2C address must be chosen for the PIC24 μC slave. Recall from Chapter 10 that the upper four address bits are manufacturer specific and allocated by Philips Semiconductor. The value 0x0 for the upper four address bits is the general call address and is used for broadcast transactions; devices can choose to respond to or to ignore this address. The value 0xF for the upper four address bits is a reserved address that should not be used. In this example, a value of 0x60 was arbitrarily chosen, as it was a free address on the I2C address bus in the target system and did not use an upper hex digit of 0x0 or 0xF. The while (1) loop of main() reads a string from the console and determines the string’s length. It then uses the writeNI2C1() function to perform an I2C block write to the slave, after which it immediately attempts to read the reversed string from the slave via the I2C block read function readNI2C1(). The block read waits after sending the address byte until the slave has the reversed string ready for transmit.

Figure 13.7 PIC24 µC master code for I2C string reversal application

Using the PIC24 µC as an I2C Slave

551

The code for the I2C slave is interrupt-driven and uses the slave event’s interrupt flag (SI2CIF). The SI2CIF flag is set on I2C slave events, such as recognition of an address byte. The SI2C1IF flag is also set in a read transaction after an acknowledgement bit has been sent by the slave for a received data byte, and in a write transaction once a byte has been clocked out of the slave by the master and the acknowledgement bit sent by the master has been received by the slave. The master events interrupt flag (MI2CIF) is set by master events, such as completion of stop condition, start condition, repeated start, byte received or transmitted, acknowledgement transmitted, and bus collision. This implementation only uses the SI2CIF flag. The _SI2C1Interrupt() ISR code for the I2C slave is given in Figure 13.8, and contains four states. The initial state is STATE_WAIT_FOR_ADDR, which waits for an address byte whose upper seven bits match the seven bits in the slave’s address register I2C1ADD. Once the SI2C1IF interrupt is generated, the STATE_WAIT_FOR_ADDR examines the R_W bit of the I2C1STAT register, which contains the R/W# bit of the received address. For a write transaction, the next state is WAIT_FOR_WRITE_DATA that reads the incoming byte from the I2C1RCV register, and places it in a buffer (sz_1[]). Once a null byte is received indicating the end of the string, the string is reversed and placed in buffer sz_2[] and STATE_WAIT_FOR_ADDR is reentered. If STATE_WAIT_FOR_ADDR detects a read transaction, it places the first byte of the reversed string in the transmit register I2C1TRN. It then sets the SCLREL bit high, which releases the clock line from a low state that is being held by the slave, allowing the master to generate clock pulses for reading the byte. The slave’s SCLREL bit is cleared automatically after reception of the address byte for a read transaction, or an ACK bit from the master after a read byte, indicating that more read data is expected from the slave. A 0 for SCLREL means the clock line is held low by the slave, generating an I2C bus wait condition. The bus wait causes the master to hang, unable to generate clock pulses until the bus wait condition is removed, giving the slave time to respond with data for the read operation. After the first byte of the reversed string is transmitted by STATE_WAIT_FOR_ADDR, the remaining bytes are transmitted by STATE_SEND_READ_DATA. When the null byte is loaded into the I2C1TRN register indicating the end of the reversed string, the next state is STATE_SEND_READ_LAST, which is an empty state to catch the interrupt generated after the null byte is clocked out. The read transaction is then finished, and the state transitions back to STATE_WAIT_FOR_ADDR. During a write transaction, an ACK bit is generated automatically for each received byte by the slave’s I2C module. A NAK is generated instead if the last received byte has not been read yet, or if a receiver overflow condition exists. The main() code for the I2C slave is given in Figure 13.9 and it is rather simple in that all it does is configure the I2C module, initialize the I2C1ADD register with the chosen slave address, and enable the SI2CIF interrupt. The while (1) loop’s only task is to keep the heartbeat alive since the _SI2C1Interrupt() ISR performs the string reversal work. Figure 13.9(b) shows the master writing the string “MS” to the slave, with the slave returning the reversed string of “SM” in the following read transaction—see Figure 13.9(c).

552

Chapter 13

■

Advanced Hardware Topics

Figure 13.8 PIC24 µC slave ISR code for I2C string reversal application

Bus Arbitration for the I2C Bus

553

Figure 13.9 PIC24 µC slave ISR code for I2C string reversal application

Bus Arbitration for the I2C Bus In the I2C bus introduction of Chapter 10, the formal definition of a bus was given as a communication channel in which there are one or more transmitters and multiple receivers. It was also stated that the I2C bus supports multiple bus masters (multi-master); in other words, any I2C device on the bus can initiate a transaction. However, the earlier examples always assume that the PIC24 μC is the sole bus master and the PIC initiates all I2C transactions. If a bus supports multiple bus masters, there must be a bus arbitration mechanism that decides which device assumes control of the bus when there are simultaneous attempts by different bus masters to access the bus. Figure 13.10 shows two common methods of bus arbitration for multi-master buses. In centralized arbitration (see Figure 13.10(a)), a device wanting to communicate on the shared bus requests permission to access the bus via a bus request (breq) signal to an arbiter, which grants the device the bus via the bus grant (bgrant) line. In the case of simultaneous requests, the arbiter uses a priority scheme to choose which device is granted bus access. A fixed priority scheme has static priorities assigned to each device such as device #1 always having the highest priority and device #n the lowest. A fixed priority scheme can result in one device monopolizing the bus, so a rotating priority scheme is more common, in which priorities are dynamically rotated among devices in an attempt to provide equal access to the bus.

554

Chapter 13

■

Advanced Hardware Topics

Figure 13.10 Two methods of bus arbitration

The disadvantage of centralized arbitration is that each device on the bus must have its own pair of bus request/bus grant lines. Centralized arbitration is most common in backplane busses found in computer systems that have a fixed number of I/O slots, and hence, a fixed number of devices that can be present on the bus. Figure 13.10(b) shows an arbitration scheme called Carrier Sense Multiple Access/Collision Detection (CSMA/CD), which is useful when it is unknown a priori the number of devices that will be connected to a bus. In CSMA/CD, a device wanting bus access waits until the bus is idle, and then begins transmitting. If multiple devices transmit, there will be a data collision on the bus. A device must be able to sense a collision and then determine independently of the other devices what action to take. A transmitter detects a collision by sensing the bus state during transmission; if the bus state does not match what the transmitter is sending, a collision has occurred. Local area networks based on Ethernet use CSMA/CD; when a collision occurs all transmitters stop sending data, wait for a random interval (the backoff interval), and try again. The backoff interval is random to help ensure that one transmitter wins and the others lose the arbitration. If another collision occurs, the interval wait time is increased (typically doubled) and another random wait is performed. This continues until a transmitter is successful at gaining access to the bus. While this works, it also wastes time because of the need for all transmitters to wait for the random interval.

Bus Arbitration for the I2C Bus

555

The I2C bus also uses CSMA/CD for arbitration, but resolves conflicts in a manner different from Ethernet. Figure 13.11 illustrates how arbitration is performed on the I2C bus. Assuming both CPUa and CPUb begin transmitting at the same time, the first data sent after the start condition is the address byte of the I2C slave device and simultaneously, a clock signal over the SCL line. A 0 on the SDA bus overrides a 1 because of the open-drain output used to drive SDA (and also SCL). Each device senses the SDA line during transmission; if a device detects that the SDA state is different from what it has transmitted, the device immediately ceases transmission, giving up the bus. In this example, CPUa is initiating a transfer to an EEPROM (address 1010????), while CPUb is beginning a transfer to a DAC (address 0101????). CPUa stops transmitting after it sends the first (most significant) bit of its address because the initial 0 sent by CPUb overrides the 1 sent by CPUa. Observe that CPUa’s transmission did not disturb CPUb’s transmission, so no data are lost and no time is wasted by the arbitration. What if both CPUa and CPUb attempt to write to the same device? Because the address bits are the same, the arbitration continues through the data bits, until either some difference is detected or the transaction completes if both devices send exactly the same data.

Figure 13.11 I2C bus arbitration

At this point, you should understand the reason for the pull-up resistors on the I2C bus; the drivers for the SDA/SDL lines are open-drain to permit multi-master bus arbitration by having a 0 state override a 1 state. This conflict resolution in CSMA/CD is simple and effective, and is used in other CSMA/CD busses, as you’ll see when the Controller Area Network is discussed in the next section.

556

Chapter 13

■

Advanced Hardware Topics

Reverse String Revisited The reverse string application of Figure 13.6 can now be revisited knowing that each PIC24 μC can act as both a master and a slave since the I2C bus is a multi-master bus. Labeling the left-hand PIC24 μC as CPU1 and the right-hand PIC24 μC as CPU2, when CPU1 sends the string to CPU2 then CPU1 is the master and CPU2 is the slave. After CPU2 reverses the string, it acts as a bus master and sends the reversed string back to CPU1, which responds as a slave. This is a better solution than originally provided in which CPU1 was always the master and CPU2 the slave, in that CPU2 sends the reversed string when it is ready, allowing CPU1 to process the input on an interruptdriven basis. Figure 13.12 shows the _SI2C1Interrupt() ISR code, which is the same for both CPUs and stores a received string into a buffer (sz_1[]) and sets a semaphore (u8_gotString) once a complete string has arrived. The ISR uses the same state machine approach for processing an I2C write transaction as used in Figure 13.8.

Figure 13.12 ISR code for the multi-master reverse string application

Bus Arbitration for the I2C Bus

557

The main() code for the multi-master reverse string application is given in Figure 13.13. The initialization code for both CPUs is the same, as the I2CADD register must be initialized and SI2CI interrupt enabled since both CPUs act as slaves. A macro named CPU_ID is used to conditionally compile code for either CPU1 or CPU2 within the while (1) loop and also for I2C address selection for the two CPUs. The CPU1 code reads a string from the console and uses the writeNI2C1() function to send it to CPU2. Following this is a wait on the u8_gotString semaphore, which indicates reception of the reversed string, which is printed to the console. The CPU2 code waits on the u8_gotString semaphore that indicates reception of the string sent by CPU1, which is then reversed by reverseString(). The reversed string is then sent back to CPU1 using the writeNI2C1() function.

Figure 13.13 main() code for the multi-master reverse string application

558

Chapter 13

■

Advanced Hardware Topics

The Controller Area Network (CAN) The automotive market is important for microcontroller manufacturers, as a typical car or truck has tens of microcontrollers within it. The number of microcontrollers within vehicles keeps increasing as automobiles evolve to mobile computing platforms that happen to carry people between locations. An automobile is a harsh environment from an electrical noise perspective and contains electrical systems dispersed throughout the vehicle with communication distances measured in meters. CAN [46] is a half-duplex serial bus designed as a communication mechanism for intelligent peripherals within an automotive system. CAN’s signaling mechanism is designed to combat the inherent electrical noise found within vehicles. The CAN bus uses only two wires for communication, keeping electrical cabling size to a minimum, thus making it easier to route within the crowded compartments of an automobile. CAN is a true bus in the formal sense like I2C; CAN transactions are visible to all peripherals connected to the bus and each transaction includes an 11-bit identifier that is used by receivers to filter messages. The CAN bus is multi-master in that any node on the bus can initiate a transaction, with arbitration handled similarly to I2C arbitration. Figure 13.14 shows a PIC24 μC with an internal CAN module connected to a CAN bus. A CAN bus is implemented as two wires, CANH/CANL, which uses differential signaling (discussed in Figure 13.15) to form a half-duplex communication channel. A transceiver chip like the Microchip MCP2551 [47] is required to convert from CAN bus voltage levels to CMOS logic levels (similar to the MAX3232 chip for the RS232 standard as discussed in Chapter 10). The enhanced CAN (ECAN™) module on a PIC μC has separate transmit (CxTX) and receive (CxRX) pins that are multiplexed by the CAN transceiver onto CANH/CANL. The CANH/CANL wires implement differential signaling; a pair of wires is used to signal a logic state, either 0 or 1. To this point, all signaling methods discussed in this book have been single-ended; one wire is used to signal a logic 0 or 1. The disadvantage of differential signaling is that it doubles the number of wires needed and as such is primarily used for serial transfers. The advantage of differential signaling is common-mode noise rejection, as shown in Figure 13.15.

Figure 13.14 PIC24 µC with CAN system

The Controller Area Network (CAN)

559

Figure 13.15 Common-mode noise rejection in differential signaling

Common-mode noise is noise (Vn in Figure 13.15) that is injected equally (or nearly so) onto all wires within a cable. A CAN bus within an automobile can be relatively lengthy and has ample opportunity to pick up noise from neighboring cable bundles or from other nearby systems. Any common-mode noise is rejected at the receiver as the two input signal voltages are subtracted from each other to form the received voltage. Differential signaling is commonly used in external cabling that carries high-speed signals outside of a computing system. Non-return-to-zero (NRZ) asynchronous transmission is used on the CxTX/RxTX pins that connect the PIC μC to the transceiver of Figure 13.14. The differential signaling method used on the CANH/CANL wire pair is shown in Figure 13.16. A logic 1 is called the recessive state, and is defined as when CANH − CANL < +0.5 V. A logic 0 is called the dominant state and is defined as when CANH − CANL > +1.5 V. The recessive state (logic 1) is the bus idle state. The dominant state (logic 0) overrides the recessive state (logic 1); if one transmitter sends a 0 and a second transmitter sends a 1, the bus will contain a 0 state (the dominant state). Absolute DC voltage levels can range from –3 V to +32 V, and CAN transceivers such as the MCP2551 must be able to survive transient voltage surges of −150 V to +100 V. Data rates range from 10 Kbps to 1 Mbps with the maximum data rate limited by the CAN bus length. On a CAN bus, all CAN nodes must agree on the data rate.

Figure 13.16 CANH/CANL differential signaling

560

Chapter 13

■

Advanced Hardware Topics

The physical signaling shown in Figure 13.16 is not defined by the CAN 2.0 standard, but rather by the ISO-11898 specification that was created to ensure compatibility between CAN nodes in an automotive system. This means that the CAN protocol can be used with different physical signaling methods as long as the CAN 2.0 specifications are met. Data transmissions are sent in frames, with each frame split into fields, and with each field containing one or more bits, as shown in Figure 13.17. There are six different frame types: standard data, extended data, remote, error, overload, and interframe space. A standard data frame is shown in Figure 13.17(a). The start-of-frame bit (start bit) is a logic 0 that signals the beginning of a frame. The arbitration field contains an 11-bit ID and a 12th bit called the RTR bit, which is 0 for a data frame and 1 for a remote frame. An extended data frame, in which the IDE bit is a 1, has a 29-bit identifier, as shown in Figure 13.17(b). An identifier is not an address in the I2C sense; it does not have to uniquely identify either the sender or receiver. All nodes on the CAN bus receive the message; each node decides whether to act on the message based upon the value of the identifier and the contents of the message. The ECAN™ module for PIC μCs contains multiple filter/mask registers that are used to determine if a received frame should be accepted or rejected; these filter/mask registers use the ID field for accept/reject decisions. Once a frame has been accepted, it is transferred to an internal message buffer for further processing by the PIC μC application. The reason that message IDs function in this way is because many nodes on a CAN bus within an automobile are simple from a communication aspect in that they only periodically output sensor data (such as engine temperature), and there may be multiple nodes that are interested in this information. This message ID scheme provides efficient distribution of data to multiple receivers.

Figure 13.17 CAN data frames

The Controller Area Network (CAN)

561

The ID field is used for multi-master arbitration in the same manner as I2C arbitration. A CAN node must wait until the bus is idle before attempting transmission. When multiple CAN nodes simultaneously attempt to transmit, they monitor the CAN bus as the ID field is sent. A 0 state (dominant) overrides a 1 state (recessive); a CAN module ceases transmission if it detects a difference between the CAN bus state and what it has transmitted. Like I2C bus arbitration, this results in no lost bus time or in any corrupted messages. The ID field is transmitted most significant bit to least significant bit so the message with the lowest numerical ID field wins during arbitration. This assigns a fixed priority to message identifiers. Arbitration is only performed on the ID field and the CAN specification does not define what occurs if two messages with the same identifier are sent simultaneously. As such, assignment of message identifiers within a CAN system must be done in such a way as to guarantee that simultaneous transmission of messages with the same ID does not occur (the CAN spec does define this case for a collision between a standard data frame and a remote data frame, and the RTR bit in the arbitration field determines priority in this case). One strength of the CAN protocol is error detection. The cyclic redundancy check (CRC) field is a checksum based on the SOF, arbitration, control, and data fields that can detect a number of different errors, including five randomly distributed errors, any odd number of errors, and burst errors of less than 15 bits in length. The control field includes a message length so every frame received is also checked for the correct length, and each frame is also acknowledged by the receiver during the acknowledge field time (similar to the ACK bit in the I2C protocol, except this is for the entire frame). Because of the large number of bits sent in one frame, there must be a mechanism that allows the receiver to remain synchronized to the bit stream or else cumulative error between transmitter and receiver clock mismatch will cause incorrect sampling of the received bits as originally discussed in Chapter 10. This is accomplished through a technique known as bit stuffing, shown in Figure 13.18. Bit stuffing is done by the transmitter, which adds an extra bit that is the complement of the preceding bit if it detects that five bits of the same value have been transmitted. This is done to guarantee that every 6-bit interval contains a data transition (a guaranteed transition density), which allows a phase locked loop (PLL) or digital phase locked loop (DPLL) circuit at the receiver to synchronize the sampling clock to the bit stream.

Figure 13.18 Bit stuffing in CAN

562

Chapter 13

■

Advanced Hardware Topics

The bit stuffing and bit destuffing is invisible to the user and is done automatically by the transmit and receive hardware. Figure 13.18 shows an example where both a 0 and 1 are added by the bit stuffing logic to the data stream. Observe that the 1 did not actually have to be added to the bit stream to guarantee a transition in 6-bit intervals as a 1 was present in the bit stream after the five 0 bits. However, the bit stuffing logic does not know this and so the 1 bit is stuffed into the bit stream anyway. Bit destuffing by the receiver is the opposite procedure; if five bits of the same value are received, the next bit is assumed to be a stuffed bit and is removed from the data stream. Bit stuffing is also useful for bit-level error detection, as a stuck-at-0 or stuck-at-1 failure in the transmitter causes the bit destuffing logic to detect an error in the received bit stream when the received bit value does not match the expected polarity of a stuffed bit. The usage and formatting of the remaining frame types of remote frame, error frame, and overload frame are not discussed. Refer to the CAN specification for more information.

The PIC24 ECAN™ Module A block diagram of the enhanced CAN (ECAN™) module on the PIC24 μC is given in Figure 13.19. The module uses message buffers residing in DMA RAM for transmit and receive: up to eight message buffers for transmit and up to 32 for receive. The 16 acceptance filters in the RX path can be flexibly configured for matching on either an 11-bit or 29-bit message identifier. Because of the ECAN™ module’s complexity, we will not attempt to cover all of the ECAN™ module’s register details. Instead, we present an ECAN™ example and discuss some of the register usage

Figure 13.19 PIC24 ECAN™ block diagram Source: Figure redrawn by author from Figure 21.2 found in the PIC24H FRM (DS70226B), Microchip Technology, Inc.

The PIC24 ECAN™ Module

563

as required by the example. We also use some utility C functions available on this book’s website, and discuss what the functions accomplish in terms of ECAN™ transfer but do not cover their code implementation. We encourage you to peruse the utility function’s code implementations in conjunction with the ECAN™ section [48] of the PIC24 Family Reference Manual for a deeper understanding of ECAN™ module details. Figure 13.20(a) shows the ECANMSG type that the code example uses for a single message buffer, which is eight 16-bit words, or 16 bytes. Words w0, w1, w2, and w7 are used for the message identifier, control bits, and other status information. The data member contains the user payload of up to eight data bytes; the union64 data type allows the payload to be viewed as either uint8_t, uint16_t, or uint32_t items. Figure 13.20(b) shows how to declare a group of message buffers in DMA RAM. Because the DMA modules use peripheral indirect addressing (the ECAN™ module generates the address for the DMA), it is important that the DMA memory block be aligned to the nearest power of two that encompasses its size. The attribute aligned(NUM_BUF*16) does this as long as NUM_BUF is a power of two.

Figure 13.20 C data structure for message buffer

564

Chapter 13

■

Advanced Hardware Topics

The code used to initialize DMA channels for ECAN™ transmit and receive is shown in Figure 13.21. Channels 0 and 1 are used (arbitrary choices), one for write (see Figure 13.21(a)) and one for read (see Figure 13.21(b)). Each channel uses peripheral indirect addressing in word mode, continuous operation. The transfer size is eight words, so DMA0CNT is initialized to 7. For ECAN™ transmit, the DMA peripheral address register (DMA0PAD) is initialized to the address of the ECAN™ transmit register (&C1TXD), and the DMA interrupt request (DMA0REQ) to DMA_IRQ_ECAN1TX (a value of 0x46). For receive, the same registers in channel 1 are initialized to the ECAN™ receive register (&C1RXD) and DMA_IRQ_ECAN1RX (a value of 0x22), respectively. In this example, the ECAN™ transmit and receive share the same buffer space, so the address registers (DMA0STA, DMA1STA) of both channels are initialized to point to msgBuf.

Figure 13.21 C data structure for message buffer

Figure 13.22(a) shows how the bit sampling is accomplished during data reception. The number of sampling clocks used for a bit time is programmable to be from 8 to 25 time quanta (TQ), with a single time quantum equal to a sampling clock period. The time quanta are distributed between the sync segment (always 1 TQ), propagation segment, phase segment 1, and phase segment 2. When a bit edge does not occur within the sync segment, resynchronization is achieved by either lengthening phase segment 1 or by shortening phase segment 2, with the amount of adjustment limited by a parameter called the sync jump width. The base clock (FCAN) for the TQ is derived from either FCY or FOSC and cannot exceed 70 MHz for the dsPI33E/PIC24E family. The data rate is given by Equation 13.1 with PRE representing the combination of two cascaded prescalers. One prescaler is fixed to divide by two, while the other is programmable, providing prescale (PRE) values of 2×1, 2×2, 2×3, ... , 2×64. data rate (bps) = FCAN / (TQtotal × PRE)

(13.1)

The PIC24 ECAN™ Module

565

The baud rate initialization code for the ECAN™ module is given in Figure 13.22(b), which configures a 1 Mbps data rate using FCAN = 60 MHz, TQtotal = 30, and PRE = 2×1.

Figure 13.22 ECAN™ baud rate configuration

Figure 13.23 gives details on C utility functions used for ECAN™ configuration. The listed functions are for ECAN™ module 1; the same functions exist for ECAN™ module 2. The CHANGE_MODE_ECAN1() function is used to change operating modes; this example makes use of the configuration and loopback modes. The configTxRxBufferECAN1() function is used for configuring the first eight buffers (buffers 0 through 7) as either TX or RX buffers; any buffers higher than buffer 7 can only be used for RX.

566

Chapter 13

■

Advanced Hardware Topics

The configRxFilterECAN1() function is used for configuring one of the 16 available RX filters as specified by u8_filterNum. A filter can optionally be used in combination with one of three mask registers (0, 1, or 2). If a mask register is not used, then an exact match is needed between the ID stored in the filter register and the incoming message for the message to be accepted. If a mask register is used, then a 0 in a mask register bit makes that bit a don’t care for filter matching. If a match is made, the message is accepted and stored in the message buffer specified by u8_bufnum, which accepts values between 0 and 14. A message buffer value of 15 specifies that the RX message be placed in the RX FIFO, which is discussed later. The configRxMaskECAN1() function is used for configuring one of the three available mask registers.

Figure 13.23 Configuration utility functions

Figure 13.24 gives some utility functions for transmit and receive operations. These will be covered in the context of the C code that uses them.

The PIC24 ECAN™ Module

567

Figure 13.24 Transmit, receive utility functions

Configuration code that uses the functions of Figures 13.21 through 13.24 is shown in Figure 13.25. The ECAN1 module is first placed into configuration mode via CHANGE_MODE_ECAN1(ECAN_MODE_CONFIGURE) (see Figure 13.23). The baud rate is then configured for 1 Mbps assuming FCAN = 60 MHz by the configBaudECAN1() function (see Figure 13.22). The configRxFilterECAN1() function call configures filter #0 for an 11-bit identifier match on MSG_ID (value of 0x7A0, arbitrarily chosen) and uses mask register #0 in the match. Buffer RX_BUFFER_ID (a value of 1) is used to store the incoming message on a match. The configRxMaskECAN1() function call configures mask register #0 for an 11-bit mask ID type that has a value of 0x7FC, and to only match the filter ID type (which is also set as an 11-bit ID). The last two bits of the mask register value 0x7FC are zero, which means that the last two bits of an 11-bit ID are not used in the match, allowing a range of message IDs to be accepted (in this case, message IDs of 0x7A0, 0x7A1, 0x7A2, and 0x7A3 are accepted). Only two message buffers (msgBuf[NUM_BUFS]) are allocated, one for TX and one for RX, which is the minimal number to support both transmit and receive. The configTxRxBufferECAN1() function is used to mark buffer #0 as a TX buffer and buffer #1 as an RX buffer. Finally, the DMA channels are configured using the configDMA0() and configDMA1() functions of Figure 13.21.

568

Chapter 13

■

Advanced Hardware Topics

Figure 13.25 ECAN™ configuration code

Figure 13.26 shows the main() code for testing the ECAN1 module. The loopback mode is used for testing, which ties TX back to RX internally. The while (1) loop places eight bytes of test data into message buffer #0 then uses the formatStandardDataFrameECAN() function to format the message with an 11-bit message ID. The while (1) loop generates message IDs in the range of 0x7A0 through 0x7A7. The mask register value of 0x7FC causes messages 0x7A0 through 0x7A3 to be accepted since the upper nine bits of the message ID matches the upper nine bits of filter #0, while other message IDs are rejected. The startTxECAN1(0) function call causes buffer #0 to be transmitted. Transmission is finished once getTxInProgress(0) returns as zero. A small software delay is used to wait for the message to be received; if the _DMA1IF flag remains cleared after the delay then the TX message was rejected by the acceptance filters, and an appropriate message is printed to the console. If the _DMA1IF flag is set, then the message was accepted, and the message ID and message contents are read out of the RX message buffer (buffer #1) and are printed to the console. The clrRxFullFlagECAN1(rx_buff_id) function call is used to clear the full flag of buffer #1.

The PIC24 ECAN™ Module

569

Figure 13.26 ECAN™ main() code

Sample output from the test code of Figure 13.26 is shown in Figure 13.27. As expected, messages with IDs of 0x7A0 through 0x7A3 are accepted, while other message IDs are rejected.

Figure 13.27 Console output for ECAN™ test

570

Chapter 13

■

Advanced Hardware Topics

Using an ECAN™ RX FIFO The previous example used the minimum number of DMA buffers, one each for RX and TX, and assigned an acceptance filter to a single RX buffer. The ECAN™ module also has the capability of assigning multiple RX buffers arranged in a FIFO order (see Chapter 10 for a discussion of a FIFO buffer structure) to an acceptance filter. Figure 13.28 shows the code changes to the previous example required to configure the ECAN™ module to use a seven-element FIFO for RX messages. The number of message buffers is increased from two to eight, with one buffer used for TX (buffer #0) and seven for RX (buffers #1 through #7). In configECAN1(), the C1FCTRL register that controls FIFO operation is configured for the FIFO to start at buffer #1 and continue to the end of the buffer space. The RX_BUFFER_ID that is used to assign filter #0 to an RX buffer is changed from a value of 1 to a value of 15, which indicates that this filter is to use the FIFO capability for storing messages. In the RX code for main(), the GET_FIFO_READBUFFER_ECAN1() function is used to determine the buffer number that has the current RX data; this buffer number is printed with the rest of the RX data.

Figure 13.28 Code changes for using a seven-element FIFO

The PIC24 ECAN™ Module

571

Figure 13.29 shows sample output using the seven-element RX FIFO; observe that RX messages are placed in buffers #1, #2, ... #7 and then receive wraps back to buffer #1.

Figure 13.29 Sample output using RX FIFO

Using an Extended Data Frame Figure 13.30 shows the changes required to the RX FIFO code of Figure 13.28 to use an extended data frame (supporting a 29-bit message ID) instead of a standard data frame (which has an 11-bit message ID). The configRxFilterECAN1() and configRXMaskECAN1() function calls within configECAN1() are changed to configure the filter and mask registers for 29-bit IDs instead of 11-bit IDs. Within main(), the formatExtendedDataFrameECAN() function is used to format the TX message buffer with a 29-bit ID, and the RX printf() statement uses the getIdExtendedDataFrameECAN() function to extract the 29-bit message ID from the RX message buffer.

Figure 13.30 Code changes for using an extended data frame

572

Chapter 13

■

Advanced Hardware Topics

Figure 13.30 (continued) Code changes for using an extended data frame

Run-Time Self-Programming In Chapter 10, an external serial EEPROM was used as an example of I2C interfacing and provided off-chip non-volatile data storage. The PIC24 μC is also capable of self-programming its own program memory, in a process known as run-time self-programming (RTSP) [50]. This offers a convenient non-volatile storage mechanism, provided that there is free space in program memory (also referred to as flash memory). RTSP also offers a way for a PIC24 μC to upload a new program via a communication port; the code that is executed during this process is called a bootloader and resides in some protected space that is not overwritten by the new program. Flash memory is erased one page at a time, where one page is 512 instructions (recall that an instruction is three bytes, or 24 bits). A flash page is organized in 8 rows of 64 instructions and flash memory can be written as either an entire row or a single instruction. Write and erase operations are self-timed, which means the operations take a variable amount of time depending on environmental and power supply conditions, as well as the number of previous erase/write cycles. Minimum page erase time is 20 ms, while minimum row and word write times are 1.6 ms and 20 μs, respectively. When using flash memory for storing data, one must be cognizant that the number of flash erase/write cycles before possible failure is finite; the PIC24 μC datasheet for a typical processor gives 10,000 as the minimum number of guaranteed write operations (the write endurance). Conversely, the 24LC515 serial EEPROM used in Chapter 10 has a maximum erase plus write time of 5 ms and a minimum write endurance of 1,000,000 cycles. These parameters and an application’s requirements generally determine whether an external or internal non-volatile memory solution is needed.

Run-Time Self-Programming

573

Recall from Chapter 6 that the program space visibility (PSV) capability allowed program memory to be mapped into the data memory as a method of accessing program memory data. The disadvantage of this method is that only the lower 16 bits of each instruction word are available via PSV since data memory is 16 bits wide. In RTSP, a different mechanism for accessing program memory uses table read/write instructions (see Figure 13.31) that allow access to all 24 bits of an instruction. The tblrdl (table read low) instruction accesses the lower 16 bits of an instruction, while the tblrdh (table read high) instruction reads the upper eight bits. The source address register (Ws) specifies the lower 16 bits of the program memory address (the offset) for the read, while the upper bits are contained in the TBLPAG special function register. The table write instructions, tblwrl and tblwrh, write the lower 16 bits and upper eight bits of the instruction respectively. The lower 16 bits of the program memory destination address is specified in Wd, while the upper eight bits are contained in TBLPAG. The TBLPAG register must be initialized with the upper bits of a program memory address before a table read/write instruction is executed.

Figure 13.31 Table read/write instructions

574

Chapter 13

■

Advanced Hardware Topics

The table write instructions do not write directly to program memory, but rather, to an intermediate row latch. Flash memory program and erase operations are controlled by the NVMCON special function register, with details shown in Figure 13.32. An erase or write cycle is started by setting the WR control bit, which first requires a special unlock sequence similar to that used by the OSCCON register for changing oscillator options. These code examples use the PIC24 compiler built-in function __builtin_write_NVM(), which executes the unlock sequence and sets the WR bit. Figure 13.33 shows the first set of utility functions for performing RTSP. The doWriteLatchFlash() function writes u16_wordhi:u16_wordlo (only the lower 24 bits are valid) to the row latch at the program memory address specified by u16_addrhi:u16_addrlo. The doReadLatchFlash() function returns the content of a program memory location as a uint32_t from the address specified by u16_addrhi:u16_addrlo.

Figure 13.32 NVMCON register details Source: Figure redrawn by author from Register 5.1 found in the dsPIC33E/PIC24E FRM (DS70609D), Microchip Technology Inc.

Run-Time Self-Programming

575

Figure 13.33 C utility functions for RTSP (part 1)

A page erase at location u16_addrhi:u16_addrlo is accomplished by the doErasePageFlash() function; observe that the value of 0x4003 written to the NVMCON register within doErasePageFlash() enables flash modification by setting the WREN bit and specifies a page erase by setting NVMOP = 0b0011.

576

Chapter 13

■

Advanced Hardware Topics

The erase is started by a series of asm statements to unlock the NVMCON register, followed by setting the WR bit to a 1. Two nop instructions later, the code then monitors the WR bit status and does not exit the function until it is cleared, indicating that the erase is finished. Interrupts are disabled during the function call to __builtin_write_NVM() because the unlock sequence enables a write to the WR bit for only one instruction cycle, and thus cannot be interrupted in order for the unlock to succeed. The doWriteRowFlow() function writes the current row that has been loaded via table write operations; its structure is similar to doErasePageFlash(). Utility functions that write and read one page of flash memory are given in Figure 13.34. The doWritePageFlash() function writes u16_len bytes of data stored in buffer pu8_data to flash address u32_pmemAddress. This function erases the page before writing, which is generally needed since once a bit has been programmed to a 0 condition, it cannot be returned to a 1, except by an erase operation (flash memory is all 1s after an erase). The doReadPageFlash() function reads u16_len bytes into buffer pu8_data from flash address u32_pmemAddress. Both functions use the union32_t data type that offers convenient access to the low and high words of a 32-bit value, which is needed when passing the u32_pmemAddress to the utility functions of Figure 13.33.

A Sample Flash Application A typical usage of flash memory is to store N fixed-length records, where the record data and format is application dependent, such as bar codes, RFID tag values, fixed-length ASCII strings, and so on. Figure 13.35 shows a union data structure named UFDATA that stores NUM_RECORDS of size RECORD_SIZE, whose format is defined by the REC structure. Each record has a byte that indicates a status of free (FREE_STATUS) or used (USED_STATUS), and a data member that can store RECORD_SIZE bytes. Records are stored in the last page of flash memory as specified by DATA_FLASH_PAGE, whose value is processor dependent. The DATA_FLASH_PAGE value is calculated by taking the address of the last word of program memory, dividing by 1024, truncating, then multiplying by 1024. The value 1024 is the number of program memory addresses occupied by 512 instructions (512 × 2 = 1024, recall that one 24-bit instruction appears to occupy two program memory addresses). If this code is to be used on a PIC24F, PIC24E, or dsPIC33E processor, then it should be modified such that the data is stored on the second to last flash page, since the last flash page for these processors contain a packed version of the configuration bits that are copied to the configuration registers after each reset (configuration bits in the PIC24H family are stored in a special area of flash memory that is not used for program memory). The fill member of UFDATA is included to guarantee the data RAM allocation for UFDATA is a multiple of the row size, since the doWritePageFlash() function makes this assumption. All records are stored in data RAM, using the global variable fdata. The strategy is to make record modifications in data RAM using the fdata variable and write the data to flash memory when you want to make the changes permanent.

Run-Time Self-Programming

Figure 13.34 C utility functions for RTSP (part 2)

577

578

Chapter 13

■

Advanced Hardware Topics

Figure 13.35 Data structure for flash application

Utility functions for record manipulation are given in Figure 13.36. The doFormat() function marks all records as FREE_STATUS, and is used to initialize the record array. The doCommit() and doRead() functions write all records to flash memory and read all records from flash memory, respectively. The doDelete() function marks the record specified by u16_recnum parameter as free. The doInsert() function copies data from the sz_1 parameter into the first free record, and marks that record as used. There is also a doPrint() function, which is not shown, that prints all the records to the console.

Run-Time Self-Programming

579

Figure 13.36 Utility functions for record manipulation

Figure 13.37 shows the doMenu() function that provides for testing of the flash utility functions by allowing record data to be entered from the console. The main() function is also shown, which calls doMenu() after standard initialization.

580

Chapter 13

■

Advanced Hardware Topics

Figure 13.37 Flash application test function

Console output from testing the flash application is given in Figure 13.38. Two strings are entered as record data, followed by a write of the record data to flash memory. After a power cycle, the record data is read from flash memory and printed, illustrating that the records were successfully stored to non-volatile memory.

Summary This chapter surveyed some advanced topics concerning on-chip peripherals for the PIC24 µC. The I2C and CAN busses are similar in that both are multi-master and both perform bus arbitration by using open-drain drivers with a 0 bit being dominant over a 1 bit in terms of winning the arbitration. Run-time self-programming allows program memory to be used as non-volatile data storage by a user application.

Review Problems

581

Figure 13.38 Flash application console output

Review Problems 1. If two I2C bus masters access the same device on the bus simultaneously, one using a read transaction and one using a write transaction, which CPU wins the arbitration? (Assume that the only difference in the first byte of the transaction is the R/W# bit.) 2. If two CAN bus masters access the bus, one with an 11-bit message ID of 0x4A0 and one with an 11-bit message ID of 0x3F2, which CPU wins the arbitration? 3. If an acceptance filter on the PIC24 µC is set for an 11-bit ID message ID match with a value of 0x615 and it also uses a mask register whose value is 0x71F, what range of message IDs are accepted? 4. Assume the 16-bit value 0xFF00 is transmitted on the CAN bus (use MSb first). Draw the serial waveform after bit stuffing has been done. 5. Assume the 16-bit value 0xF803 is transmitted on the CAN bus (use MSb first). Draw the serial waveform after bit stuffing has been done.

582

Chapter 13

■

Advanced Hardware Topics

6. Using typical erase and write times, how much time is required to erase and write the entire flash memory of the dsPIC33EP128GP502 neglecting software overhead and data that is written one row at a time? 7. Look up the specifications for the PIC24HJ256GP206. Assume you want to use the last page of its flash memory for storage of non-volatile data. What would the value of FIRST_UNIMPLEMENTED_PMEM (first unimplemented program memory location) be for this processor, as defined in Figure 13.35? 8. Look up the specifications for the PIC24HJ128GP204. Assume you want to use the last page of its flash memory for storage of non-volatile data. What would the value of FIRST_UNIMPLEMENTED_PMEM (first unimplemented program memory location) be for this processor, as defined in Figure 13.35? The next two questions are best assigned as short reports. 9. Do research on the LIN (local interconnect network) bus and answer the following questions. a. How many wires does it need? b. Classify it as duplex, half-duplex, or simplex. c. How is addressing to devices handled? d. What are the signaling levels? e. Is it synchronous or asynchronous? f. What is the maximum transfer speed? g. What is the maximum number of devices allowed on the bus? 10. The system management bus (SMBus) is a two-wire bus that was derived from the I2C standard by Intel in 1995. It is currently used in PC motherboards and various microcontrollers. Download the SMBus specification (http://smbus.org/specs) and answer the following questions. a. Give a couple of key differences between SMBus and I2C. For the key differences you chose, give the reasoning behind these changes. b. Can you give an advantage of SMBus over the I2C bus? Defend your answer. c. Are the I2C devices used in Chapter 10 compatible with the SMBus? Defend your answer.

Chapter 14

Operating Systems for Embedded Systems

T

his chapter discusses essential concepts of operating systems for embedded systems, such as tasks, scheduling schemes, coordination and communication between tasks, and operating system services. This chapter also introduces a lightweight, cooperative multitasking operating system for the Microchip PIC24 μC family. Several example applications are provided.

Learning Objectives After reading this chapter, you will be able to: ■

■

■

■

■

■

Describe the difference between cooperative multitasking, preemptive multitasking, and programming. Write pseudo-code to outline an application with concurrently executing tasks using cooperative and preemptive multitasking approaches. Create example situations where semaphores or messaging can solve problems with synchronization and coordination. Use the Embedded Systems Operating Systems (ESOS) on the PIC24 μC to write multitasking applications. Use the services provided by ESOS to generate software timers, respond to hardware interrupts, and communicate serially via synchronous and asynchronous protocols. Develop additional services for ESOS.

583

584

Chapter 14

■

Operating Systems for Embedded Systems

The applications developed thus far in this book have been based on a pattern of hardware initialization followed by an infinite loop written in a way that is specific to the application at hand. This program structure is very straightforward and used in many embedded system applications that operate flawlessly every day. While efficient, this approach can be difficult if the application specification were to grow or if the application changes. Furthermore, much developer time is spent creating software infrastructure that will likely be needed again in future applications. The hardware support library used in the previous chapters is an attempt to create software resources that will speed development and lead to higher quality software designs. The operating system extends the concept of creating a more generic software framework. Operating systems provide basic services and perform common software housekeeping tasks that advanced embedded system applications can use. This chapter looks at some basic principles of operating systems and introduces an operating system suitable for the PIC24 μC that can be used in advanced or complex embedded system projects.

Operating System Concepts You are no doubt familiar with operating systems (OSes) for general-purpose desktop and laptop computers. Examples of popular desktop and laptop OSes are Microsoft Windows, Apple’s Mac OS X, and Linux. Often, people forget that the pretty graphical interface that represents the “computer desktop” they see is not the operating system, but merely the windowing system application running atop the OS. In actuality, the OS is the system software underneath that is responsible for coordinating the use of the hardware for applications that run on the computer. These applications include the window manager, word processors, web browsers, email clients, and games. OSes are not limited to desktop and laptop general-purpose computers. OSes can be found in most every computer system that has a reasonably complicated function to perform. OSes are literally everywhere—in your smart phone, your Internet router, and several OSes power different controllers in your automobile. There is probably an OS controlling the microwave to pop your popcorn. In fact, the most widely used OS on earth is probably an OS for embedded systems: TRON, and its derivatives, grew out of a project at the University of Tokyo in the 1980s [76]. TRON is really a software specification that has been implemented by a huge number of embedded device manufacturers of consumer devices, ovens, refrigerators, digital cameras, CD players, mobile phones, industrial controllers, and cash registers. Since TRON is a specification, as opposed to source code, the exact number of TRON systems in use is pure speculation. Estimates are in the hundreds of millions, if not billions, of copies. OSes can vary from hugely complex pieces of software (Microsoft Windows, Apple Mac OS X, and Linux) to very simple constructs that simply coordinate several tasks on a small microprocessor like the PIC24 μC.

Operating System Concepts

585

Although these OSes differ in size and style, most OSes offer fundamentally the same services to their hosted applications: ■ ■ ■

■

Control program/task execution Provide a scheduler, which determines the sequence in which programs/tasks execute Provide a consistent system in which the system can provide program execution to unexpected requests generated by hardware interrupts Provide high-level functions or services to access and control hardware, including timers, peripherals/devices, and memory

From the preceding features list, you can see that OSes can provide the embedded systems designer fundamental operations required to keep the software application running. Furthermore, these operations are needed by almost every software application and are not specific to any particular functionality. Instead of burdening the application developer with creating the code to provide these features, the OS contains them, leaving the developer free to concentrate on application-specific code. The OS controls program or task execution by creating a context in which a program can run, and then initiates code execution. This program or task context may be a dedicated processor in a multiprocessor computer, a protected memory space, or simply a stack frame, depending on the OS and its hosting hardware. The OS scheduler is responsible for determining which program or task executes next. The scheduler may use a complex algorithm based in queuing theory or operations research to select the next task to run, or the scheduler may simply run each process in a “roundrobin” manner. The OS should also provide a system by which hardware peripherals can interrupt normal program flow. Interrupts are intimately related to the ISRs that service them. Since an OS is ultimately responsible for program execution, the OS must be apprised of and manage the software that responds to interrupts. The usual approach is that an OS provides its own methods for enabling and disabling interrupts, setting interrupt priorities, and selecting software routines to respond to interrupts. Finally, OSes typically provide methods by which the user’s application code can access and control hardware. Most often, OSes provide methods for timer resources. Many OSes supply methods for accessing other peripherals such as memory, file systems, and communications. Many, but not all, OSes provide additional services depending on the OS’s goals and the capabilities of the underlying hardware. These additional services can include but are not limited to: ■ ■ ■ ■ ■

Multitasking Protected execution modes Memory management Services for communications between application tasks and between computers (networking) Task execution within fixed timing deadlines

586

Chapter 14

■

Operating Systems for Embedded Systems

Multiprocessing is the use of multiple processors to perform several differing computing activities simultaneously. Multitasking is a method by which multiple computing processes share the same processor, and resources appear to be running simultaneously. The discussion in this chapter deals almost exclusively with a single processor, multitasking system. Consider an MP3 music player as an example of a multitasking embedded computing system. Your MP3 music player likely has only one central processor, which is used to control the music decoding and audio playback. This same central processor is also responsible for drawing the display screen updates and graphics and for sensing the state of the human-machine interface such as buttons and scroll wheels. Use cases for the MP3 music player demand that the screen updates and the buttons respond during audio playback. The MP3 music player’s OS provides multitasking so that the music playback, screen updates, and button sensing appears to occur at the same time. Similarly, the OS on your desktop or laptop computer provides multitasking so that you can download email while playing a computer game and messaging with your friends. The specific functions of the MP3 music player and the desktop/ laptop computer are quite different, but both need multitasking, which is provided by the OS. Methods by which multitasking are performed vary but the illusion of concurrent execution is the same. Some OSes support protected execution modes where programs/tasks are limited in the machine instructions and resources that they are allowed to use. In this way, the OS can more easily manage and protect the limited computing resources under its control. Since it is difficult for OS software to control the machine instructions used by the programs it runs, protected execution modes are available only when the underlying hardware provides this capability. Some OSes provide memory management services. Memory management is the action of an OS to efficiently manage and utilize its available memory. Memory management by an OS is largely a software solution, so memory management is potentially available in any OS. An OS can provide additional memory management functions like memory protection. Memory protection is a scheme by which a program’s or task’s memory is protected from unauthorized access by other programs and tasks. Like protected execution modes, memory protection usually requires hardware support to detect and limit the addressing activities of programs. Without sufficient hardware support, OSes often cannot provide memory protection. Since computers are so often connected to other devices and computers, many modern OSes provide communications services. The TCP/IP stack on Ethernet is an example from the desktop/laptop computers that immediately comes to mind. Modern desktop/laptop computers also communicate with other devices via the Universal Serial Bus (USB) and IEEE 1394 (also known as “FireWire”) protocols. Embedded computers also communicate with other computers, and often do so with a much wider variety of communication protocols, such as CAN, SPI, I2C, and other serial channels such as RS232, RS422, and RS485. OSes for embedded systems may provide methods for communications on one or more of these protocols, which hide the details of the protocol from the application developer.

Operating System Concepts

587

Many embedded systems are reactive systems, that is, systems that react to and maintain ongoing interactions with their environment. These systems generate responses rather than a final result or value. Many control systems, like an airplane’s avionics or the controller for an industrial plant, are reactive systems. Reactive systems often must respond within a very tightly specified time period for proper operation. These types of reactive systems are often called real-time systems. A special OS called a real-time operating system (RTOS) exists that performs many or all of the OS functions listed earlier, but does so with a guarantee of response time. Furthermore, RTOSes can also guarantee their tasks will run a certain number of times with a maximum interval between executions. In this way, designers can count on their code having a very specific temporal behavior, which is critical for many of these control-oriented embedded system applications. A detailed discussion of these OS topics can easily fill several volumes. You can delve into OS details in [71]–[73]. This section briefly introduces the concepts of OSes needed for this specific discussion and application of an OS for embedded systems.

Tasks Computer applications can usually be described as a collection of tasks, where a task is defined as a sequence of computer instructions within a context. All of the software applications in this text fit into this description if you assume a single context: the entirety of your sequentially executing application code. The single application context becomes troublesome as the application grows in complexity. Typically, an application has several functions to perform and these functions are not necessarily dependent upon the others. An application is more maintainable if functionality can be coded such that unrelated activities are not interspersed. Figure 14.1 shows pseudo-code for an MP3 music player. The MP3 player must continuously play music, update its graphical user interface (GUI), and monitor its input/output (I/O) system for user requests. Furthermore, the MP3 music player must appear to perform all three functions simultaneously. If the MP3 player has a single microprocessor, it must interleave the functions for the three subsystems—audio, GUI, and I/O—to give the appearance of multitasking. In case of a single programming context, the functions of the three subsystems must be interleaved in a single while (1) loop by the programmer. In order for each of the three subsystems to run while giving the appearance of simultaneous execution, Figure 14.1 shows each subsystem divided into N subroutines, each with the same execution time. Code readability, reuse, and maintainability are difficult in the program form in the left side of Figure 14.1. If the MP3 music player uses an OS that supports task switching, the code for the three independent subsystem tasks can be kept separate. The right side of Figure 14.1 shows the form of task-oriented software. In this implementation, each of the three subsystems is written in its own while (1) loop, as if it existed alone. However, the OS has the ability to suspend a task’s execution and give control over to another task. The methods by which this can be done will be introduced shortly. Clearly, the individual task contexts allow independent tasks to be written without mixing in code from

588

Chapter 14

■

Operating Systems for Embedded Systems

unrelated operations. Since each subsystem exists independently of the other tasks, each task can be broken down into as many or as few steps as required. This approach with independent tasks written without concern for other application functionality is logically more consistent with the user’s perspective, is simpler for the designer, and is not as error-prone as the code form shown in the left side of Figure 14.1.

Figure 14.1 Three tasks of an MP3 music player

Multitasking and Schedulers As defined earlier, multitasking is the ability to seemingly execute more than one task at a time with only one processor. The OS gives the appearance of simultaneous execution by allowing each program or task to execute for a short period of time before switching to another program or task. The switch from one program to another is so rapid and often that the user perceives all of the programs running at the same time. This form of multitasking is called time-sharing execution. There are two basic types of time-sharing multitasking: preemptive and cooperative. In preemptive multitasking, the OS maintains a tally of how much CPU time each program task has used since the

Operating System Concepts

589

last task change. After a suitable period has elapsed, the OS suspends the task at its current operating point and activates/reactivates the next task to execute. Preemptive multitasking gives the OS complete authority in determining which tasks run, when they run, and how long they run. In cooperative multitasking, each task can execute in the CPU for as long as it needs to. If a task does not need the CPU, the task should voluntarily allow other programs or tasks to use the CPU. In cooperative multitasking, the sharing of the single CPU and its resources is reliant on each task cooperating with the sharing scheme. If a task decides to be selfish, it can monopolize the system and starve the other tasks of CPU time. The OS has no real power to stop this kind of bad task behavior, and the simultaneous execution illusion is destroyed. To place multitasking methods into context, let’s examine some historical operating systems for desktop and laptop PCs. The Disk Operating System (DOS) of the 1980s did not support multitasking. DOS programs had sole control of the computer and its resources. Microsoft Windows 3.x and the MultiFinder-based Apple Macintosh OSes (versions of Mac OS up through Mac OS 9) use cooperative multitasking. All programs written for these OSes must voluntarily cooperate for multitasking to occur. Obviously, programmers of these applications intended to cooperate. However, application code defects or hardware errors sometimes caused a program to fail to yield the CPU. The appearance to the user was that a program either monopolized the processor or the system would hang completely. The Amiga OS released in 1985, IBM’s OS/2 released in 1987, Microsoft OSes Windows 95 and later, Mac OSX released in 1999, all UNIX OSes since the first 1971 release, and Linux OSes use preemptive multitasking. Since these OSes are in complete control of task execution, a defective program or a hardware-induced hang usually can be stopped by the OS. The change from one task to another is called a context switch. In preemptive multitasking, the OS must determine when to execute a context switch. In its attempt to be fair to all running tasks, preemptive multitasking OSes must determine how much CPU time each task has used. OSes tally either the physical time period that a task has held the CPU since the last context switch, or the number of CPU instructions executed by the process since the last context switch. The latter approach is aided by special instruction count registers present in many of the large, modern processors. The former approach is readily accomplished with timer hardware and its associated interrupt. Because context switches in preemptive multitasking systems are determined completely by the OS, application code does not explicitly contain any code for context switches. Figure 14.2 shows the pseudocode for the example MP3 player under a preemptive multitasking OS. Each task runs as if in isolation from the other tasks and is completely unaware of when context switches occur. When the OS determines the time is appropriate for a context switch, the OS interrupts the current task, saves the current task’s state, recreates the saved state of another task, and resumes execution of this restored task at the point where it was last interrupted. It is the OS’s sole responsibility to save and restore the CPU registers, memory contexts such as stack frames, and program counters appropriately.

590

Chapter 14

■

Operating Systems for Embedded Systems

Figure 14.2 Pseudo-code for an MP3 music player written with a preemptive multitasking OS

In a preemptive multitasking OS, the OS determines when the context switch should occur. While this can provide protection against an errant task monopolizing the CPU, it also has the potential to be inefficient. Consider the 50 ms delay in the I/O task in Figure 14.2 running in an OS that provides its tasks with access to a variable that represents a 1 ms counter via a call to os_getCurrentTickValue(). The 50 ms delay in Figure 14.2 can be implemented by waiting for 50 ticks of the OS timer to elapse. Listing 14.1 gives possible pseudo-code for a suitable delay subroutine in the multitasking OS. Listing 14.1: Simple Delay Routine for Multitasking OS void delay(u16_delay) { uint16_t u16_initTickVal; // record OS tick count when delay routine is first called u16_initTickVal = os_getCurrentTickValue(); // wait until u16_delay milliseconds have elapsed since first call while (os_getCurrentTickValue() - u16_initTickVal 511) u16_temp = 511; // SCL divider only uses 9 bits I2C1BRG = u16_temp; I2C1CONbits.I2CEN = 1; }

Basic I2C operations performed with the Chapter 10 functions startI2C1(), stopI2C1(), restartI2C1(), and putI2C1() all have the potential to be blocked by abnormal conditions. Furthermore, these basic operations are used by many other functions to construct larger I2C transactions. In Chapter 10, these functions recorded their execution into an error string and enabled the watchdog to reset the processor in the event that the blocking state did not unblock in due time. These features are useful in the code in the earlier chapters but are not compatible with ESOS. The ESOS versions of these operations must simply instruct the task to wait until the appropriate I2C condition is met. Finally, these basic operations are used as building blocks for other more complex routines so a C language macro is most appropriate. Figure 14.28 shows the macros to implement the basic I2C operations of start, stop, restart, and put.

Figure 14.28 Basic I2C operation macros for ESOS

Design: Adding an ESOS Service for I2C

631

The basic operation getI2C() in Figure 10.49 is a bit more complicated. The process of getting a byte from the I2C bus requires that the function follow these steps: 1. 2. 3. 4. 5. 6. 7.

Wait for an I2C bus idle condition Enable the I2C receive bit Wait for the received byte Read the byte Wait for an I2C bus idle condition Acknowledge Wait for acknowledge to complete

The preceding operation must occur in sequence, and each of the wait operations has the potential to be delayed or not occur. So, ESOS should provide a macro to implement the function to get one byte from the I2C bus. However, a macro is probably a bad idea for this operation as the macro will be quite long because it must perform at least seven distinct steps. Also, the means by which the C language compiler is used to implement the multitasking in ESOS prohibits the use of more than one ESOS wait/yield macro. The ESOS function to get a byte from I2C involves waiting, so it must be a task. However, this task will be called by other tasks. Therefore, ESOS provides this operation as a child task. Figure 14.29 shows the code for the child task to get a byte from the I2C bus. If you compare the code in Figure 14.29 with the code in Figure 10.49, you will find that the two functions are very similar.

Figure 14.29 ESOS I2C operation to read a byte from bus

632

Chapter 14

■

Operating Systems for Embedded Systems

There are two key items to note in Figure 14.29. First, the arguments passed into __esos_pic24_getI2C1 are copied into local static variables to preserve their values across the wait statements. Second, the byte read from the I2C bus is placed at the address of the input argument since child tasks cannot return values to their caller. Other than changing the while (cond) waits in Figure 10.49 to ESOScompatible ESOS_TASK_WAIT_WHILE(cond), the code in Figure 14.29 is largely unchanged. With the macro in Listing 14.3 and the code in Figures 14.28 and 14.29, you are now ready to implement a full I2C transaction to read and write data to a target device.

I2C Transactions Under ESOS An I2C transaction consists of writing the target device’s address, reading or writing the correct amount of data, and responding with the appropriate acknowledgments. These I2C transactions will be called by other ESOS tasks, will have data passed into them, will pass data out of them, and will be blocked for an unknown period of time. Your only choice to satisfy all of these requirements is to implement the I2C transactions as child tasks, similar to __esos_pic24_getI2C1 in Figure 14.29. The simplest transactions write data to a target device with I2C address u8_addr. Figure 14.30 shows the code to implement the child tasks to perform these transactions. Like the child task __esos_pic24_getI2C1 in Figure 14.29, the transaction child tasks in Figure 14.30 must keep a static local copy of their arguments. Otherwise, the code in Figure 14.30 is very similar to the code in Figure 10.50. Now that ESOS has created the child tasks in Figure 14.30 to write one, two, or an arbitrary number of bytes to a target device, other tasks can spawn these tasks. The parent tasks can declare an ESOS_TASK_HANDLE for the child tasks such as the code in Figure 14.23. A more efficient way is to have the ESOS_TASK_HANDLE automatically created by the C compiler when the I2C routines are included in a project. The file esos_pic24_i2c.c that contains the code described in this section simply declares the variable storage with the line struct stTask __stChildTaskI2C;. Whenever I2C is used in an ESOS application, the user can be assured that storage for a child task has been created. Now, ESOS can further simplify the application designer’s job by providing some easy-to-use macros to implement an I2C transaction. Listing 14.4 shows macros for tasks to use in order to write data to a target I2C device. The file esos_pic24_i2c.h contains these macro definitions for your application use. Listing 14.4: Macros to Perform ESOS I 2C Write Transactions #define ESOS_TASK_WAIT_ON_WRITE1I2C1(u8_addr, u8_d1) ESOS_TASK_SPAWN_AND_WAIT((ESOS_TASK_HANDLE)&__stChildTaskI2C, __esos_pic24_write1I2C1, (u8_addr), (u8_d1)) #define ESOS_TASK_WAIT_ON_WRITE2I2C1(u8_addr, u8_d1, u8_d2) ESOS_TASK_SPAWN_AND_WAIT((ESOS_TASK_HANDLE)&__stChildTaskI2C

\ \ \ \

Design: Adding an ESOS Service for I2C

__esos_pic24_write2I2C1, (u8_addr), (u8_d1), (u8_d2)) #define ESOS_TASK_WAIT_ON_WRITENI2C1(u8_addr, pu8_d, u16_cnt) ESOS_TASK_SPAWN_AND_WAIT((ESOS_TASK_HANDLE)&__stChildTaskI2C, __esos_pic24_writeNI2C1, (u8_addr), (pu8_d), (u16_cnt))

Figure 14.30 ESOS child tasks to write data to a target I2C device

\ \

633

634

Chapter 14

■

Operating Systems for Embedded Systems

Recall that ESOS created a child task __esos_pic24_getI2C1 to read a byte from the I2C bus in Figure 14.29. This child task will be called by child tasks that perform the full I2C read transactions. Therefore, it would be useful to have a macro such as those in Listing 14.4 to facilitate using the child task __esos_pic24_getI2C1 in Figure 14.29. Also, since the task __esos_pic24_getI2C1 will be called quite often, ESOS can declare a task storage structure for it in esos_pic24_i2c.c with struct stTask __stGrandChildTaskI2C;. Listing 14.5 shows the macro used to simplify the calls to the child task __esos_pic24_getI2C1. Listing 14.5: Macros to Spawn Child Task to Read a Byte from the I 2C Bus #define ESOS_TASK_WAIT_ON_GETI2C1(pu8_get, u8_ack2Send) ESOS_TASK_SPAWN_AND_WAIT((ESOS_TASK_HANDLE)&__stGrandChildTaskI2C, __esos_pic24_getI2C1, (pu8_get), (u8_ack2Send))

\ \

With the macro in Listing 14.5, the child task to read one, two, or an arbitrary number of bytes from an I2C device is straightforward. Figure 14.31 shows the code for the I2C transactions to read data. Notice that each time the child tasks in Figure 14.31 desire to read a byte from the I2C bus, they must spawn the child task using the macro in Listing 14.5. Use of the I2C transaction child tasks in Figure 14.31 is simplified by the macros given in Listing 14.6. Notice how the macros in Listing 14.6 accept the destination variable arguments “by-name” but call the child task “by-reference.” Listing 14.6: Macros to Perform ESOS I 2C Read Transactions #define ESOS_TASK_WAIT_ON_READ1I2C1(u8_addr, u8_d1) ESOS_TASK_SPAWN_AND_WAIT((ESOS_TASK_HANDLE)&__stChildTaskI2C, __esos_pic24_read1I2C1, (u8_addr), &(u8_d1)) #define ESOS_TASK_WAIT_ON_READ2I2C1(u8_addr, u8_d1, u8_d2) ESOS_TASK_SPAWN_AND_WAIT((ESOS_TASK_HANDLE)&__stChildTaskI2C, __esos_pic24_read2I2C1, (u8_addr), &(u8_d1), &(u8_d2)) #define ESOS_TASK_WAIT_ON_READNI2C1(u8_addr, pu8_d, u16_cnt) ESOS_TASK_SPAWN_AND_WAIT((ESOS_TASK_HANDLE)&__stChildTaskI2C, __esos_pic24_readNI2C1, (u8_addr), (pu8_d), (u16_cnt))

\ \ \ \ \ \

The macros and code described in this section can be found in the source code that accompanies this book in the files esos_pic24_i2c.c and esos_pic24_i2c.h. If you examine the asynchronous communications services files esos_pic24_rs232.c and esos_pic24_rs232.h, and the SPI services files esos_pic24_spi.c and esos_pic24_spi.h, you will find the code to be similar in construction. Any custom services you desire to create will likely follow a similar pattern. In the next section, you will see the new I2C service in action.

Design: Adding an ESOS Service for I2C

Figure 14.31 ESOS child task to read data from a target device

635

636

Chapter 14

■

Operating Systems for Embedded Systems

Application Using the ESOS I2C Service and Semaphores The ESOS I2C service created in the previous section allows you to easily build ESOS applications to use I2C devices. The circuit in Figure 10.51 shows how to connect the dsPIC33EP128GP502 to the Maxim Integrated Circuits DS1631 I2C thermometer and thermostat. Figure 10.54 gives the single application version of the code used to read the current temperature from the DS1631. Although the DS1631 measures the temperature and the PIC24 μC can read this temperature via I2C, you must write data to the I2C bus to configure the DS1631 and to command the DS1631. This application exercises a large portion of the I2C services ESOS created. This section demonstrates an ESOS application to recreate the results obtained by the code in Figure 10.54 using the ESOS services for semaphores and I2C transactions. Figure 14.32 shows the initialization code of the ESOS application. The routine user_init() performs the normal initialization operations of configuring the heartbeat LED, creating semaphores and registering tasks and timers. The user_init() in Figure 14.32 also calls the ESOS I2C configuration routine esos_pic24_configI2C1 to set the PIC24 μC I2C peripheral to transfer at 400 kbps. Notice that the global variables include three semaphores and a 16-bit integer i16_temp to hold the temperature conversion results.

Figure 14.32 ESOS application for testing the DS1631 using semaphores (part 1)

Design: Adding an ESOS Service for I2C

637

The DS1631 must be configured and commanded via I2C transactions to start temperature conversions. Thus, the DS1631 cannot be started in the routine user_init() , because user_init() is not an ESOS function and cannot wait or yield. Since the DS1631 must receive I2C data to operate properly, initialization and command of the DS1631 must occur in ESOS user tasks. Figure 14.33 shows the user tasks to complete the application. The task start_ds1631 performs two I2C transactions to configure the DS1631 for 12-bit conversion results and to convert the temperature continuously. After the DS1631 is commanded to start conversions, the task start_ds1631 waits for a period of time to allow the DS1631 to acquire the first temperature reading. The task start_ds1631 signals the task read_ds1631 that the DS1631 is operating, and then the task start_ds1631 ends.

Figure 14.33 ESOS application for testing the DS1631 using semaphores (part 2)

638

Chapter 14

■

Operating Systems for Embedded Systems

Simultaneously with the execution of start_ds1631, the task read_ds1631 starts. Initially, task read_ds1631 waits on notification from start_ds1631 that the DS1631 is ready to provide temperature data. Once task read_ds1631 gets the signal, it enters an infinite loop where it performs an I2C transaction to acquire the most recent temperature reading from the DS1631. Task read_ds1631 places the results in the global variable i16_temp and signals task update that new temperature data is ready for its use. After signaling update, read_ds1631 waits for 750 ms and checks to see if task update has, indeed, consumed the temperature data. Once task update has signaled, read_ds1631 loops back to repeat the process. Upon being registered in user_init(), task update starts executing. Initially, task update waits for a signal from task read_ds1631 that temperature data is available. Once the signal is received, task update converts the raw binary DS1631 data into a floating-point temperature and prints the results to the serial output port. After the results are printed, the temperature data are no longer needed and task update signals task read_ds1631 that it can overwrite the results with new data. Task update repeats these functions continuously. In order to fully mimic the results of the code in Figure 10.54, the user task in Figure 14.33 uses the printf function in stdio.h. Use of printf could theoretically block the task update if the communication channel were not functioning properly. A blocked task update would also block other tasks from executing. A typical ESOS application would use the ESOS communication service function calls introduced in the previous sections to facilitate cooperative multitasking and allow the other unblocked tasks to continue to operate even when communication is slow or not functioning.

Application Using the ESOS I2C Service and Messaging In the previous section, you saw how semaphores can be used to coordinate or synchronize ESOS tasks as they read the DS1631 temperature sensor and display its value. However, the semaphores only provide the task synchronization. The actual temperature data was conveyed in global variables. Thus, two separate mechanisms are used to accomplish the related tasks: task coordination/ synchronization and data communication. Messaging between ESOS task can accomplish both simultaneously. In this section, you create an ESOS application to recreate the results obtained by the code in Figure 10.54 and Figures 14.32 and 14.33 using the ESOS services for messaging and I2C transactions. Figure 14.34 shows the initialization code of the ESOS application. The routine user_init() performs the normal initialization operations of configuring the heartbeat LED, and registering tasks and timers. The user_init() in Figure 14.34 also calls the ESOS I2C configuration routine esos_pic24_configI2C1 to set the PIC24 μC I2C peripheral to transfer at 400 kbps.

Design: Adding an ESOS Service for I2C

639

Figure 14.34 ESOS application for testing the DS1631 using messaging (part 1)

The DS1631 must be configured and commanded via I2C transactions to start temperature conversions. Thus, the DS1631 cannot be started in the routine user_init(), because user_init() is not an ESOS function and cannot wait or yield. Since the DS1631 must receive I2C data to operate properly, initialization and command of the DS1631 must occur in ESOS user tasks. Figure 14.34 shows a user task called start_ds1631, which initializes the DS1631 device. The task start_ds1631 performs two I2C transactions to configure the DS1631 for 12-bit conversion results and to convert the temperature continuously. After the DS1631 is commanded to start conversions, the task start_ds1631 waits for a period of time to allow the DS1631 to acquire the first temperature reading. Then, the task start_ds1631 creates an empty mail message—a message with no data payload—and sends this message to the read_ds1631 task. At this point, the job of the start_ds1631 task is complete, and task start_ds1631 ends.

640

Chapter 14

■

Operating Systems for Embedded Systems

Figure 14.35 ESOS application for testing the DS1631 using messaging (part 2)

Summary

641

Simultaneously with the execution of task start_ds1631, the task read_ds1631 in Figure 14.35 starts. Initially, task read_ds1631 waits on notification from start_ds1631 that the DS1631 is ready to provide temperature data. This notification comes in the form of the (empty) mail message sent by task start_ds1631 before it ended. Once task read_ds1631 reads this mail message signal, it enters an infinite loop where it performs an I2C transaction to acquire the most recent temperature reading from the DS1631. Task read_ds1631 creates a mail message capable of carrying two 8-bit data values. The two data bytes read from the DS1631 are copied into this mail message, and the message is sent to the update task. Reception of this mail message by the update task means that new temperature data is available, and the mail message contains that data. The combination of signal and data communication should be contrasted with the semaphore and global variables used in Figures 14.33 and 14.34. Task read_ds1631 blocks execution until it is confirmed that the update task has received the message. Once task update has received new temperature data, the read_ds1631 task loops back to repeat the process. Upon being registered in user_init(), task update starts executing. Initially, task update waits for mail message from task read_ds1631 that contains the DS1631 temperature data. Task update gets the most recent message from its mailbox discarding any older messages that may exist. Thus, task update has the most current temperature data from the DS1631. Also, note that task update’s call to ESOS_TASK_GET_LAST_MESSAGE() will cause task read_ds1631 to continue from its blocked ESOS_TASK_WAIT_ON_DELIVERY() statement. Once the message is received, task update converts the raw binary DS1631 data into a floating-point temperature and prints the results to the serial output port. Task update repeats these functions continuously. In order to fully mimic the results of the code in Figure 10.54, the user tasks in Figures 14.33 and 14.35 uses the printf function in stdio.h. Use of printf could theoretically block the task update if the communication channel were not functioning properly. A blocked task update would also block other tasks from executing. A typical ESOS application would use the ESOS communication service function calls introduced in the previous sections to facilitate cooperative multitasking and allow the other unblocked tasks to continue to operate even when communication is slow or not functioning.

Summary This chapter introduced concepts of multitasking OSes and provided an introduction to ESOS, a lightweight cooperative multitasking OS for the PIC24 μC. ESOS provides services for managing user tasks including subordinate child tasks, full-featured wait/yield conditions, mailboxes, and semaphores. ESOS also provides a collection of services so that the user can exploit the powerful hardware peripherals of the PIC24 μC. Services provided by ESOS include software timers, asynchronous and synchronous communications, and hardware interrupts.

642

Chapter 14

■

Operating Systems for Embedded Systems

Review Problems 1. Develop the code required to implement a rendezvous semaphore with four tasks instead of two. 2. Implement a binary semaphore with function similar to Figure 14.19 using the ESOSprovided user flags. A binary semaphore can take on only the values 0 and 1. 3. C language macros are used extensively in ESOS. The multiline code macros are surrounded by do-while (0) statements. Why is this construction necessary? 4. Using basic ESOS I2C operations, create a specialized service for the Maxim Integrated Circuits DS1631 Digital Thermometer and Thermostat. The service will be composed of child tasks that perform the DS1631 operations directly without using the I2C transaction functions. Create the supporting macros to make the service’s use in user tasks simpler. Some example macro names include ESOS_TASK_WAIT_GET_TEMP and ESOS_TASK_WAIT_SET_THERMOSTAT. 5. 6. 7. 8.

Reconstruct the system in Figures 9.25 and 9.26 using ESOS. Reconstruct the system in Figures 10.56 through 10.61 using ESOS. Reconstruct the system in Figures 11.21 through 11.24 using ESOS. Reconstruct the system in Figures 12.27 and 12.28 using ESOS.

PART IV

Appendixes Appendix A PIC24 Architecture and Instruction Set Summary . . . . . . . . . . . . . . . . .645

Appendix B Circuits 001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .653

Appendix C Problem Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .661

Appendix D References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .689

This page intentionally left blank

Appendix A

PIC24 Architecture and Instruction Set Summary

T

his appendix contains a summary of the PIC24 architecture and instruction set. Figures A.3 through A.10 give the instruction set summary, with Figures A.1 through A.2 providing symbols and encodings used in these summaries. The instruction set encodings and definitions are taken from the 16-bit MCU and DSC Programmer’s Reference Manual [5]. Register placeholder symbols used in instruction mnemonics are: ■

Wn: Register direct addressing; Wn specifies one of W0, W1, ... W15.

■

Wns: Register direct addressing; Wns specifies one of W0, W1, ... W15.

■

Wnd: Register direct addressing; Wnd specifies one of W0, W1, ... W15.

■

Wb: Register direct addressing; Wb specifies one of W0, W1, ... W15.

■

WREG: The working register, specifies W0 in file register instructions.

■

■

■

■

Ws: Register direct (Ws) and indirect addressing modes ([Ws], [Ws++], [Ws--], [++Ws], [--Ws]); Ws specifies one of W0, W1, ... W15. Wd: Register direct (Wd) and indirect addressing modes ([Wd], [Wd++], [Wd--], [++Wd], [--Wd]); Wd specifies one of W0, W1, ... W15. Wso: All of the addressing modes of Ws, with the additional mode of register offset indirect [Wso + Wb]; Wso specifies one of W0, W1, ... W15. Wdo: All of the addressing modes of Wd, with the additional mode of register offset indirect [Wdo + Wb]; Wdo specifies one of W0, W1, ... W15.

645

646

■

■

Appendix A

■

PIC24 Architecture and Instruction Set Summary

Wsi: Indirect addressing modes ([Ws], [Ws++], [Ws--], [++Ws], [--Ws]); Ws specifies one of W0, W1, ... W15. Used only by the tblrdl and tblrdh instructions. Wdi: Indirect addressing modes ([Wd], [Wd++], [Wd--], [++Wd], [--Wd]); Wd specifies one of W0, W1, ... W15. Used only by the tblwtl and tblwth instructions.

Figure A.1 Machine code symbols

Appendix A

■

PIC24 Architecture and Instruction Set Summary

647

Figure A.2 Addressing mode encodings

Figure A.3 Instruction table (part 1)

648

Appendix A

Figure A.4 Instruction table (part 2)

■

PIC24 Architecture and Instruction Set Summary

Appendix A

Figure A.5 Instruction table (part 3)

■

PIC24 Architecture and Instruction Set Summary

649

650

Appendix A

Figure A.6 Instruction table (part 4)

■

PIC24 Architecture and Instruction Set Summary

Appendix A

Figure A.7 Instruction table (part 5)

■

PIC24 Architecture and Instruction Set Summary

651

This page intentionally left blank

Appendix B

Circuits 001

T

his appendix gives a hobbyist-level introduction to basic circuits and covers the basic components (resistors, capacitors, and diodes) used in this book’s schematics.

Voltage, Current, and Resistance Current is the flow of electrons through a conductor. A conductor is anything that allows current flow. A good conductor offers little resistance to current flow; in other words, it does not take much work for current to flow within a good conductor. In rough terms, the amount of work it takes to move electrons between two points on a conductor is voltage. The voltage difference between one end of a conductor and the other indicates the resistance of the conductor. If the voltage drop is high, the resistance is high; conversely, if the voltage drop is low, the resistance is low. A voltage supply provides a source of current at a fixed voltage level. Current is measured in amperes (A), with a few milliamperes (mA, 1 mA = 0.001 A) being the typical current requirements of the integrated circuits used in this book. Voltage is measured in volts (V) and resistance is measured in ohms (Ω). The PIC24 μC and the integrated circuits in this book require a direct current (DC) voltage supply, typically with a voltage value of +3.3 V. A DC voltage supply means that the current flows in one direction only and that the voltage is a constant value, either positive or negative. By contrast, the power available for household appliances from wall plugs is alternating current (AC), where the voltage varies in a sinusoidal fashion between ±120 V with a frequency of 60 Hz. The AC current direction reverses itself each time the voltage value crosses 0 V. 653

654

Appendix B

■

Circuits 001

Ohm’s Law A resistor is a component with a fixed resistance value that is used to control current flow in an electrical circuit. Figure B.1 shows a basic DC circuit consisting of a DC voltage supply and one resistor with value R.

Figure B.1 Voltage/current relationship with one resistor

Equation B.1 gives Ohm’s Law, which expresses the current (I) flowing through the resistor as a function of voltage (V) and resistance (R). I = V/R

(B.1)

An ideal DC voltage source supplies the current predicted by Equation B.1; thus, a resistance of zero causes infinite current flow. A zero resistance or very low resistance path is called a short, and causes large currents to flow. A physical power supply obviously cannot supply infinite current, and thus will either fail after a short period of time or blow an internal fuse, breaking the circuit path. Figure B.2 shows how a fuse is used to protect against shorts.

Figure B.2 Using a fuse to protect against shorts

Voltage, Current, and Resistance

655

A fuse is a thin conductor that physically separates, breaking the connection, after a maximum rated current is reached. In Figure B.2(a), the switch is open so no current is flowing; in Figure B.2(b) the switch is closed, creating a short between VDD and ground; and in Figure B.2(c) the fuse has blown, creating an open path and stopping current flow. Equation B.2 is another form of Ohm’s Law that expresses voltage across a resistor as the product of current and resistance. V=I×R

(B.2)

Resistors in Series Figure B.3 shows a circuit with two resistors connected in series.

Figure B.3 Resistors in series

In this case, the current flowing through both resistors is the same and is expressed by Equation B.3, where the total resistance of the circuit is the sum of R1 and R2. Is = Vs / (R1 + R2)

(B.3)

Equations B.4 and B.5 give the voltages V1 and V2 across each resistor. V1 = Is × R1

(B.4)

V2 = Is × R2

(B.5)

Resistors in series form a voltage divider, with the sum of voltages across the resistors equal to the voltage supply value, as shown in Equation B.6. Vs = V1 + V2

(B.6)

Voltage dividers are used in Chapter 11 to build analog-to-digital and digital-to-analog converters. Observe that if R1 = R2, V1 = V2 = Vs/2; the voltage divides equally between the two resistors.

656

Appendix B

■

Circuits 001

Resistors in Parallel Figure B.4 shows a circuit with two resistors connected in parallel.

Figure B.4 Resistors in parallel

In this case, the voltage across each resistor is the same and is equal to the power supply voltage Vs. However, the current flowing through each resistor is dependent on the resistance value, as given in Equations B.7 and B.8. I1 = Vs / R1

(B.7)

I 2 = Vs / R2

(B.8)

Resistors in parallel form a current divider, with the sum of the currents through the resistors equal to the total current drawn from the power supply (Is), as shown in Equation B.9. Is = I1 + I 2

(B.9)

When measuring the total current through a system like the PIC24 reference board in this book, the current draw of each individual integrated circuit can be determined by simply removing it from the board, since the current draw of each integrated circuit adds to the total current draw. Figure B.5 illustrates this concept. Observe that the integrated circuits are connected in parallel (all supplied with the same voltage).

Figure B.5 Current draw in a total system

Voltage, Current, and Resistance

657

Polarization Most circuit elements have two terminals through which current flows. The terminals can either be polarized (have positive and negative terminals) or unpolarized. A DC power supply is polarized; it has clearly marked positive (+) and negative (−) terminals. The negative terminal is at zero volts (ground) and the positive terminal is the voltage output. A resistor is unpolarized; its operation is not affected by the direction in which its terminals are connected in a circuit.

Diodes A diode is a two-terminal device that allows current flow in one direction only. A diode’s two terminals are named the anode and the cathode; when the voltage on the anode is approximately 0.7 V higher than the cathode voltage, current flows through the diode (the turn-on voltage for a diode varies by diode type; a Schottky diode’s turn-on voltage is approximately 0.3 V). Thus, a diode is a polarized device, as circuit operation is dependent on how its terminals are connected in a circuit. On physical diodes, the cathode terminal is identified by either a band at one end or by being the shorter of the two leads. Figure B.6 shows some simple diode circuits.

Figure B.6 Diode circuits

In Figure B.6(a) no current is flowing through the diode, because the anode voltage is only 0.3 V; in Figure B.6(b) current flows through the diode, as the anode voltage is greater than the cathode voltage by more than 0.7 V; in Figure B.6(c) no current is flowing, as the diode direction is reversed in the circuit; the only way for current to flow in this circuit is if Vs produces a negative voltage. The resistor is included in series with the diode in Figure B.6 simply to limit the current flow within the circuit. A diode has internal resistance but its value depends on the diode type. A light emitting diode (LED) emits visible light in proportion to the current flowing through it; the higher the current, the brighter the light.

658

Appendix B

■

Circuits 001

Capacitors A capacitor is a two-terminal device that comes in both unpolarized and polarized varieties, depending on the material that is used to make the capacitor. Polarized capacitors have clearly marked + and − terminals. Equation B.10 gives the time-dependent current flow i(t) to a capacitor as a function of capacitance (C) and the voltage rate of change (dv/dt) across the capacitor. i(t) = C dv / dt

(B.10)

In intuitive terms, Equation B.10 says that if the voltage across a capacitor is not changing, then no current flows to the capacitor. Equation B.11 gives the time-dependent voltage across a capacitor as a function of capacitance and current. v(t) = (1/C ) 兰 i dt

(B.11)

In intuitive terms, Equation B.11 says that a capacitor stores charge, increasing its voltage, as current flows to it. You can think of a capacitor as a bucket that holds charge where the height of the bucket’s wall is proportional to voltage. Figure B.7 shows the effect of Equations B.10 and B.11 in an RC series circuit.

Figure B.7 RC series circuit

Capacitors

659

When the switch is open, the current to the capacitor and the voltage across the capacitor are both zero. At time t = 0, the switch closes and the capacitor charges up in an exponentially decaying fashion to Vs. The current jumps to its maximum value immediately after the switch closure due to the instantaneous change in voltage (maximum dv/dt), and exponentially decays to zero as the change in voltage across the capacitor (dv/dt) decreases. The Y axis is time and is marked in RC units, where the R × C product is called the time constant of the RC series circuit. The larger the time constant, the longer it takes for the capacitor to charge. In the PIC24 reference system, the polarized capacitors used across the VDD and ground pins of the PIC24 μC are used as energy reservoirs for transient current needs caused by switching activity within the microcontroller. Physical capacitors also have some resistance associated with them called the equivalent series resistance (ESR); this needs to be low in order for the capacitors to adequately meet these transient switching needs. Ceramic and some tantalum capacitor types have low ESR values. Polarized “can”-type capacitors are aluminum electrolytic, are available in large capacitance values, and are used to provide a large charge reservoir for stabilizing the DC power supply but do not have a low ESR. A comprehensive description of the physical characteristics of a capacitor is beyond the scope of this appendix, but it must be pointed out that current (charge) does not flow through a capacitor in the same way as current flows through a resistor. A capacitor is made from two parallel plates with a dielectric material between the plates. The plates (terminals) are isolated, and current does not pass between the plates. The dielectric material, the surface area of the plates, and the plate separation all determine the capacitance value. Charge collects on one of the plates, forming a voltage across the plates. Discharging or charging a capacitor as shown in Figure B.7 means to remove charge from or place charge on the capacitor via current flow, which changes the capacitor’s voltage.

This page intentionally left blank

Appendix C

Problem Solutions

Answers to all the odd-numbered problems are provided in this appendix.

Chapter 1 25 = 32, 26 = 64, so 6 bits 120 = 0x78 = 0b0111 1000 0xF4 = 0b1111 0100 0b1011 0111 = 0xB7 = 11*16 + 7 = 183 0xB2 − 0x9F = 0x13. ~0x9F = ~(0b1001 1111) = 0b0110 0000 = 0x60. So 0xB2 − 0x9F = 0xB2 + ~0x9F + 0x01 = 0xB2 + 0x60 + 0x01 = 0x13 11. See Figure C.1. 1. 3. 5. 7. 9.

Figure C.1 Problem 1.11

661

662

Appendix C

■

Problem Solutions

13. 0x2A 1 inc.b W0,W0 ;u8_i++; p47_loop_exit:

Chapter 5 1. p1_loop_top: mov u32_k,W0 sub u32_i mov u32_k+2,W0 subb u32_i+2 ;u32_i = u32_i u32_k; mov u32_j,W0 add u32_k,WREG mov W0,W2 mov u32_j+2,W0 addc u32_k+2,WREG mov W0,W3 ;W3:W2 = u32_j + u32_k mov u32_i,W0 mov u32_i+2,W1 ;W1:W0 = u32_i cp W0,W2 cpb W1,W3 ; u32_i < (u32_j + u32_k) bra LTU, p1_loop_top

3. mov ior mov mov ior mov

u32_j,W0 u32_i,WREG W0,u32_k u32_j+2,W0 u32_i+2, WREG W0,u32_k+2

Chapter 5

5. p5_loop_top: mov u64_k,W0 sub u64_i mov u64_k+2,W0 subb u64_i+2 mov u64_k+4,W0 subb u64_i+4 mov u64_k+6,W0 subb u64_i+6 mov u64_j,W0 add u64_k,WREG mov W0,W4 mov u64_j+2,W0 addc u64_k+2,WREG mov W0,W5 mov u64_j+4,W0 addc u64_k+4,WREG mov W0,W6 mov u64_j+6,W0 addc u64_k+6,WREG mov W0,W7 mov u64_i,W0 mov u64_i+2,W1 mov u64_i+4,W2 mov u64_i+6,W3 cp W0,W4 cpb W1,W5 cpb W2,W6 cpb W3,W7 bra LTU, p5_loop_top

7. p7: mov ior mov mov ior mov mov ior

u64_j,W0 u64_i,WREG W0,u64_k u64_j+2,W0 u64_i+2,WREG W0,u64_k+2 u64_j+4,W0 u64_i+4,WREG

;u64_i = u64_i

u64_k;

;W7:W4 = u64_j + u64_k

;W3:W0 = u64_i

; u64_i < (u64_j + u64_k)

669

670

Appendix C

mov mov ior mov mov mov ior mov

■

Problem Solutions

W0,u64_k+4 u64_j+6,W0 u64_i+6,WREG W0,u64_k+6 W0,u64_k+4 u64_j+6,W0 u64_i+6,W0 W0,u64_k+6

9. 11. 13. 15. 17. 19.

0xD6 −1117 0xFF85 0x90 – 0x8A = 0x06, Z = 0, N = 0, V = 0, C = 1 0x2A – 0x81 = 0xA9, Z = 0, N = 1, V = 1, C = 0 These are signed numbers—i8_i = –96 and i8_j = +112—so comparison is false, assigning 8_k a value of 0. 21. 0xA0 >> 2 = 0xE8, assuming the sign bit is preserved. 23. mov i16_j, W0 cp i16_k bra LT, p23_end_if asr i16_i asr i16_i p23_end_if:

; signed branch ; preserve sign

25. mov.b i8_q, WREG se W0, W1 mov i16_k, W0 add W0, W1, W0 asr W0, #2, W0 mov #0xA34D, W1 and W0, W1, W0 mov WREG, i16_i

; ; ; ;

W1 W0 W0 W0

= = = =

(int16_t) i8_q (sign extend) i16_k (i16_k + (int16_t) i8_q) (i16_k + (int16_t) i8_q) >> 2

; W0 = ((i16_k + (int8_t) i8_q) >> 2) & 0xA34D;

27. Code fragment: mov.b i8_q, WREG se W0, W0 clr W1 btsc W0, #15 setm W1

; W0 = (int16_t) i8_q

; W1:W0 = (int32_t) i8_q

Chapter 6

asr W1, W1 rrc W0, W0 asr W1, W1 rrc W0, W0 mov.d W0, W2 mov i32_s, W0 mov i32_s + 2, W1 sub W0, W2, W0 subb W1, W3, W1 mov #0x807F, W2 mov #0x38DB, W3 ior W0, W2, W0 ior W1, W3, W1 mov W0,i32_r mov W1,i32_r+2

; W1:W0 = (int32_t) i8_q >> 1 ; W1:W0 = (int32_t) i8_q >> 2 ; W3:W2 = (int32_t) i8_q >> 2 ; W1 = i32_s ; W1:W0 = i32_s - (int32_t) i8_q >> 2 ; W3:W2 = 0x38DB807F ; W1:W0 = (i32_s - (int32_t) i8_q >> 2) | 0x38DB807F

29. 0x34FFDF

Chapter 6 1. 3. 5. 7. 9. 11. 13. 15. 17. 19. 21. 23. 25. 27.

See Table C.4. W0 = 0x80FF, W1 = 0x0804 W0 = 0x0880, W1 = 0x0805 W0 = 0x0806, Memory Location 0x0804 = 0x8301 W0 = 0x0805, Memory Location 0x0804 = 0x8001 W2 = 0xCE46 W0 = 0x0806, Memory Location 0x804 = 0x7B03 W1=0x087B Memory Location 0x0806 = 0x0603 W15 = 0x0806, Memory Location 0x0804 = 0x0806 W15 = 0x0802, W3 = 0xFB80 W15 = 0x080C, W14 = 0x0806, Memory Location 0x0804 = 0x0802 Return address = 0x020A + 4 = 0x020E ; W0 = psz_1, W1 = psz_2, W2 used for u8_char str_swap: cp0.b [W0] ; *psz_1 != 0 bra Z, str_swap_exit mov.b [W0], W2 ; u8_char = *psz_1

671

672

Appendix C

■

Problem Solutions

mov.b [W1],[W0] mov.b W2, [W1++] inc W0, W0 bra str_swap str_swap_exit: return

; *psz_1 = *psz_2 ; *psz_2 = u8_char, psz_2++ ; psz_1++

29. ; W0 = pi16_a, W1 = u8_cnt, W2 = i16_k find_max: mov #0x8000, W2 ; i16_k = -32768 find_max_loop_top: cp0.b W1 bra Z, find_max_exit cp W2, [W0] ; i16_k < *pi16_a bra GE, find_max_skip ;signed compare mov [W0], W2 ; i16_k = *pi16_a find_max_skip: inc2 W0, W0 ; pi16_a++ dec.b W1, W1 ; u8_cnt bra find_max_loop_top find_max_exit: mov W2, W0 ; set up return value return ; W0 has pi16_a, W1 has u8_cnt, used W2 for i16_k

31. putch: nop return

; dummy

; W0 = psz_in putstr: cp0.b [W0] bra Z, putstr_exit push W0 mov [W0], W0 call putch pop W0 inc W0, W0 bra putstr putstr_exit: return

; save W0 for subroutine call ; get parameter for subroutine call

; psz_in++

Chapter 6

33. pu16_x ; FP - 12 u8_i ; FP - 10 u8_j ; FP - 8 Rtn Addr (LSW) ; FP - 6 Rtn Addr (MSW) ; FP - 4 old FP ; FP - 2 i16_k ; 1 V, so D[2] = 1. Step 3: Guess is 0110, so Vref = 6/16 × 4 V = 1.5 V. Vin of 1.8 V > 1.5 V, so D[1] = 1. Step 4: Guess is 0111, so Vref = 7/16 × 4 V = 1.75 V. Vin of 1.8 V > 1.75 V, so D[0] = 1. The final 4-bit conversion returns 0111. 9. The reference voltages for the seven comparators from the resistor string are 7/8×VREF, 6/8×VREF, 5/8×VREF, 4/8×VREF, 3/8×VREF, 2/8×VREF, and 1/8×VREF. The input voltage of 2.7 V is between 6/8×VREF = 3.0 V and 5/8×VREF = 2.5 V, so the comparators’ outputs are 0011111. 11. 10 bits of resolution is specified, so: 1 LSb = 3.0 V/210 = 3.0 V/1024 = 0.00293 V = 2.93 mV. 0.1% × 3.0 V = 0.003 V, so 3 mV/2.93 mV × 100% = 102.4% of a LSb. This means that only 9 bits of the PIC24 ADC 10-bit result should be used, as the voltage reference is not accurate enough for 10 bits. 13. 0.449 V / 3.3 V × 1024 = 139.3, truncate and convert to hex = 0x08B. 2.91 V/ 3.3 V × 1024 = 902.98, truncate and convert to hex = 0x386. 15. 0x7F = 127; 127/256 × 3.3 V = 1.637 V; 0x4B = 75; 75/256 × 3.3 V = 0.967 V; 0xCB = 203; 203/256 × 3.3 V = 2.617 V. 17. 0x17F = 383; 383/4,096 × 3.0 V = 0.280 V; 0x74B = 1,867; 1,867/4,096 × 3.0 V = 1.367 V; 0xCCB = 3,275; 3,275/4,096 × 3.0 V = 2.398 V. 19. The LM60 outputs 6.25 mV for every 1ºC and has a DC offset of 424 mV, so a 10-bit ADC stepsize with a 3.3V reference of 3.222 mV is equivalent to 0.5155ºC. 12-bit ADC stepsizes with a 3.3V reference are 0.8057 mV that is equivalent to 0.1290ºC, which is 1/4 of the previous answer. 21. A precision of 1.5 ºC corresponds to a voltage of (1.5 × 6.25 mV) = 9.375 mV. 3.3V/9.375 mV = 352 steps. Therefore, the ADC must have at least 9 bits.

686

Appendix C

■

Problem Solutions

Chapter 12 1. TDelta = (1 − 1) × (0xFFFF + 1) + (0x0000 − 0xA000) + 0x1200 = 0 + 0x6000 + 0x1200 = 24576 + 4608 = 29184 ticks. 1 Tick = 1/40 MHz × 8 = 200 ns = 0.2 μs, so 29184 ticks × 0.2 μs = 5836.8 μs. 3. 232 ticks × 1/40 MHz × 8 = 4294967296 × 1/40 MHz × 8 = 6871.9 s = 6872 s. 5. Time = 2,000 ticks × 1/40 MHz × 8 = 0.0004 seconds; Frequency is 1/0.004 s = 2500 Hz = 2.5 KHz. 7. Ticks = 0.005 seconds × 20 MHz / 8 = 12,500. 9. 1/3 full speed means a 15 ms/3 = 5 ms pulse width. Ticks = 5 ms × 16 MHz /256 = 312.5 = 312 ticks.

Chapter 13 1. The CPU using the write transaction wins because the 0 for the R/W bit wins the arbitration over the 1 bit. 3. The message ID 0x615 is 0b110 0001 0101, and the filter value of 0x71F is 0b111 0001 1111, which means message IDs that match the pattern of 0b110 xxx1 0101 are accepted. Thus, an ID with values of 0x615, 0x635, 0x655, 0x675, 0x695, 0x6B5, 0x6D5, and 0x6F5 are accepted. 5. See Figure C.7.

Figure C.7 Problem 13.5

7. The last implemented program memory location PIC24HJ256GP206 μC is 0x2ABFF (open MPLAB, set the device to PIC24HJ256GP206, and look at the last program memory address). From Figure 13.40, the last page of flash memory (DATA_FLASH_PAGE) starts at (0x2ABFF/FLASH_PAGESIZE) × FLASH_PAGESIZE, where FLASH_PAGESIZE is 8 rows × 64 instructions × 2 program memory addresses = 1024. Thus (0x2ABFF/1024) × 1024 = 170 × 1024 = 174080 = 0x2A800 (note that the division result is truncated). An alternative calculation is that the first unimplemented memory location on the PIC24HJ256GP206 μC is 0x2AC00. The last flash page will start at 0x2AC00 – FLASH_PAGESIZE = 0x2AC00 – 1024 = 0x2AC00 – 0x400 = 0x2A800. Both calculations agree. A solution is not provided for problem 9 since it is a report.

Chapter 14

687

Chapter 14 1. The solutions are varied, but here is one approach: The application initializes the required semaphores in the initialization code. ESOS_INIT_SEMAPHORE(mutex, 1); ESOS_INIT_SEMAPHORE(turnstile,0); u8_count=0; register tasks #1-4

// assumes semaphores mutex and // turnstile declared globally // global variable

Each of the four tasks contains the code: // task code EsOS_TASK_WAIT_SEMAPHORE(mutex, 1); // only one task can increment count++; // count at one time (protected by ESOS_SIGNAL_SEMPAHORE(mutex, 1); // a mutex semaphore) if (count == 4) // when 4th tasks finishes ESOS_SIGNAL_SEMAPHRE(turnstile, 1); // signal-wait-signal sequence only ESOS_TASK_WAIT_SEMAPHORE(turnstile, 1); // allows one task at a time ESOS_SIGNAL_SEMAPHORE(turnstile, 1;) // to proceed through // tasks have all synchronized at this point (RENDEZVOUS) // task code continues

3. Consider the fictitious (pseudo-code) ESOS multiline macro written without the normal do-while (0) combination: #define ESOS_MACRO_A() line1; line2; line3

\ \ \

called in the following code: if (foo==bar) ESOS_MACRO_A();

After the C compiler preprocessor completes macro processing, the preceding code would be (with indentation to emphasize the program flow): if (foo==bar) line1; line2; line3

Without the protective do-while (0) combination, the potential exists for multiline macros to have the first line of the macro conditionally execute when the intent is for the entire macro body to be conditionally executed. Solutions not provided for problems 5 and 7 since they are design project problems.

This page intentionally left blank

Appendix D

References

Note: For all dsPIC33E/PIC24E Family Reference Manual sections, visit www.microchip.com and search for “dsPIC33E/PIC24E Family Reference Manual.” [1] P. Ceruzzi, A History of Modern Computing, Second Edition. Cambridge, MA: The MIT Press, 2003. [2] G. Ifrah, The Universal History of Computing. New York: John Wiley & Sons, Inc., 2001. [3] M. Morris Mano, Computer System Architecture, Second Edition. Englewood Cliffs, NJ: Prentice-Hall, 1982. [4] W. Weste, D. Harris, CMOS VLSI Design: A Circuits and Systems Perspective, Third Edition. MA: AddisonWesley, 2005. [5] Microchip Technology Inc., 16-bit MCU and DSC Programmer’s Reference Manual, DS70157F, 2011. Available online at www.microchip.com. [6] J. Hennessy and D. Patterson, Computer Architecture: A Quantitative Approach, Second Edition. San Francisco: Morgan Kaufmann Publishers, Inc., 1996. [7] Intel Corporation, “Appendix C: Instruction Latency and Throughput,” Intel 64 and IA-32 Architectures Optimization Reference Manual, Order Number 248966-016, November 2007. Available online at www.intel.com. [8] Microchip Technology Inc., 16-bit MCU and DSC Programmer’s Reference Manual, DS70157F, 2011. Available online at www.microchip.com. [9] Microchip Technology Inc., Section 1. Introduction - dsPIC33E/PIC24E FRM, DS70573B, 2011. Available online at www.microchip.com. [10] Microchip Technology Inc., Section 2. CPU - dsPIC33E/PIC24E FRM, DS70359B, 2011. Available online at www.microchip.com. 689

690

Appendix D

■

References

[11] Microchip Technology Inc., Section 3. Data Memory - dsPIC33E/PIC24E FRM, DS70595C, 2011. Available online at www.microchip.com. [12] Microchip Technology Inc., Section 4. Program Memory - dsPIC33E/PIC24E FRM, DS70613C, 2011. Available online at www.microchip.com. [13] Microchip Technology Inc., Section 5. Flash Programming - dsPIC33E/PIC24E FRM, DS70609D, 2011. Available online at www.microchip.com. [14] Microchip Technology Inc., Section 6. Interrupts - dsPIC33E/PIC24E FRM, DS70000600D, 2011. Available online at www.microchip.com. [15] Microchip Technology Inc., Section 7. Oscillator - dsPIC33E/PIC24E FRM, DS70580C, 2011. Available online at www.microchip.com. [16] Microchip Technology Inc., Section 8. Reset - dsPIC33E/PIC24E FRM, DS70602B, 2011. Available online at www.microchip.com. [17] Microchip Technology Inc., Section 9. Watchdog Timer and Power-Saving Modes - dsPIC33E/PIC24E FRM, DS70615C, 2011. Available online at www.microchip.com. [18] Microchip Technology Inc., Section 10. IO Ports - dsPIC33E/PIC24E FRM, DS70000598C, 2011. Available online at www.microchip.com. [19] Microchip Technology Inc., Section 11. Timers - dsPIC33E/PIC24E FRM, DS70362B, 2011. Available online at www.microchip.com. [20] Microchip Technology Inc., Output Compare with Dedicated Timer - dsPIC33E/PIC24E FRM, DS70005159A, 2011. Available online at www.microchip.com. [21] Microchip Technology Inc., Section 16. Analog-to-Digital Converter (ADC) - dsPIC33E/PIC24E FRM, DS70621C, 2011. Available online at www.microchip.com. [22] Microchip Technology Inc., Universal Asynchronous Receiver Transmitter (UART) - dsPIC33E/PIC24E FRM, DS70000582E, 2011. Available online at www.microchip.com. [23] Microchip Technology Inc., Serial Peripheral Interface (SPI) - dsPIC33E/PIC24E FRM, DS70569C, 2011. Available online at www.microchip.com. [24] Microchip Technology Inc., Section 19. Inter-Integrated Circuit™ (I2C™) - dsPIC33E/PIC24E FRM, DS70330B, 2011. Available online at www.microchip.com. [25] Microchip Technology Inc., Section 21. Enhanced Controller Area Network (ECAN™) - dsPIC33E/PIC24E FRM, DS70353C, 2011. Available online at www.microchip.com. [26] Microchip Technology Inc., Section 22. Direct Memory Access (DMA) - dsPIC33E/PIC24E FRM, DS70348C, 2006. Available online at www.microchip.com. [27] Microchip Technology Inc., Device Configuration - dsPIC33E/PIC24E FRM, DS70005159A, 2011. Available online at www.microchip.com.

Appendix D

■

References

691

[28] Microchip Technology Inc., Analog-to-Digital Converter (ADC) - dsPIC33E/PIC24E FRM, DS70621C, 2011. Available online at www.microchip.com. [29] Microchip Technology Inc., Interrupts - dsPIC33E/PIC24E FRM, DS70000600D, 2011. Available online at www.microchip.com. [30] Microchip Technology Inc., Section 10. IO Ports - dsPIC33E/PIC24E FRM, DS70000598C, 2011. Available online at www.microchip.com. [31] Microchip Technology Inc., dsPIC33EPXXXGP50X, dsPIC33EPXXXMC20X/50X , and PIC24EPXXXGP/MC20X Data Sheet, DS70000657H, 2013. Available online at www.microchip.com. [32] Microchip Technology Inc., MPLAB® XC16 C Compiler User’s Guide, DS50002071C, 2013. Available online at www.microchip.com. [33] Hantronix, HDM162116L-5 Dimensional Drawing, 16 Character x 2 Lines LCD Module. Available online at www.hantronix.com. [34] Hantronix, HDM16216L-5 LCD Module Commands. Available online at www.hantronix.com. [35] Maxim, 3.0V to 5.5V, Low-Power, up to 1Mbps, True RS-232 Transceivers Using Four 0.1μF External Capacitors, MAX3222, 19-0273, Rev 7, 1/07. Available online at www.maxim-ic.com. [36] Microchip Technology Inc., MCP41XXX/42XXX Single/Dual Potentiometer with SPI Interface, DS11195C, 2003. Available online at www.microchip.com. [37] Dallas Semiconductor/Maxim, Digital Thermometer with SPI/3-Wire Interface, DS1722, 022008. Available online at www.maxim-ic.com. [38] Philips Semiconductors, The I2C Bus Specification Version 2.1, 2001. Available online at www.nxp.com. [39] Maxim Integrated Products, DS1631/DS1631A/DS1731 Digital Thermometer and Thermostat, REV 102307. Available online at www.maxim-ic.com. [40] Microchip Technology Inc., 24AA515/25LC515/24FC515 512K I2C CMOS Serial EEPROM, DS21673C, 2003. Available online at www.microchip.com. [41] Texas Instruments Inc., SN754410 Quadruple Half-H Driver, SLRS007B, revised November 1995. [42] Microchip Technology Inc., Section 29. Read-Time Clock and Calendar (RTCC) - dsPIC33E/PIC24E FRM, DS70584B, 2011. Available online at www.microchip.com. [43] Dan Matthews, AN849: Basic PICmicro Oscillator Design, Microchip Technology Inc., DS00849A, 2002. Available online at/www.microchip.com. [44] Microchip Technology Inc., Section 22. Direct Memory Access (DMA) - dsPIC33E/PIC24E FRM, DS70348C, 2011. Available online at www.microchip.com. [45] Society for Industrial and Applied Mathematics, “Inquiry Board Traces Ariane 5 Failure to Overflow Error,” SIAM News, Vol. 29, Number 8, October 1996.

692

Appendix D

■

References

[46] Robert Bosch GmbH, CAN Specification/Version 2.0, 1991. Available online at www.can.bosch.com. [47] Microchip Technology Inc., High-Speed CAN Transceiver, DS21667D, 2003. Available online at www.microchip.com. [48] Microchip Technology Inc., Section 21. Enhanced Controller Area Network (ECAN™) - dsPIC33E/PIC24E FRM, DS70353C, 2011. Available online at www.microchip.com. [49] Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC, Phillips, Universal Serial Bus Specification, Revision 2.0, April 27, 2000. Available online at http://www.usb.org. [50] Microchip Technology Inc., Section 5. Flash Programming - dsPIC33E/PIC24E FRM, DS70609D, 2011. Available online at www.microchip.com. [51] Microchip Technology Inc., Section 28. Parallel Master Port (PMP) - dsPIC33E/PIC24E FRM, DS70576B, 2011. Available online at www.microchip.com. [52] Microchip Technology Inc., Op Amp/Comparator - dsPIC33E/PIC24E FRM, DS70000357E, 2011. Available online at www.microchip.com. [53] Microchip Technology Inc., Section 27. Programmable Cyclic Redundancy Check (CRC) - dsPIC33E/PIC24E FRM, DS70346B, 2011. Available online at www.microchip.com. [54] National Semiconductor, LM 386 Low Voltage Audio Power Amplifier, DS006976, August 2000. Available online at www.national.com. [55] Dialogic® Corporation, Dialogic ADPCM Algorithm, 00-1366-001, 1988. Available online at www.dialogic.com. [56] Interactive Multimedia Association (defunct), Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems, Revision 3.0, October 21, 1992, 41 pp. Available online at http://www.cs.columbia.edu/~hgs/audio/dvi/. [57] Rodger Richey, AN643 Adaptive Differential Pulse Code Modulation Using PICmicro™ Microcontrollers, Microchip Technology Inc., DS00643B, 1997. Available online at www.microchip.com. [58] P. M. Weir, L. E. Hicks, J. B. Leatherwood, J. Wilson, MP3toFM: An Ethernet to FM Audio System, ECE 4512 Final Report, April 25, 2008. Available online at www.ece.msstate.edu/courses/design/2008/mp3tofm. [59] WIZnet, iinChip W3100A, Technical Datasheet v1.34. Available online ww.WIZnet.co.kr. [60] VLSI Solution Oy, VS1011e MPEG Audio Codec, Version 1.04, 2007-10-08. [61] Niigata Seimitsu Co., Ltd., FM Stereo Transmitter, NS73M-61LU-0101, 2006-01-06. [62] P. Burks, S. Cave, D. Johnson, and J. Ward, MOCRO: Manually Operated Compact Reflow Oven, ECE 4512 Final Report, April 25, 2008. Available online at www.ece.msstate.edu/courses/design/2007/roven. [63] Ravi Sharma, AN233 Solder Reflow Recommendation, Microchip Technology Inc., DS00233D, 2004. Available online at www.microchip.com. [64] Maxim, Cold-Junction-Compensated K-Thermocouple to-Digital Converter (0 °C to +1024 °C), MAX6675, 19-2235, Rev 1, 3/02. Available online at www.maxim-ic.com.

Appendix D

■

References

693

[65] Leonard Elevich and Veena Kudva, AN1094 Bootloader for dsPIC30F/33F and PIC24F/24H Devices, DS 1094A, 2007. Available online at www.microchip.com. [66] F. Maloberti, Data Converters. Dordrecht, The Netherlands: Springer, 2007. [67] B. Razavi, Principles of Data Conversion System Design. New York: IEEE Press, 1995. [68] Maxim, 2.5V to 5.5V, Low-Power, Single/Dual, 8-Bit Voltage-Output DACs, MAX548A, 19-1206, Rev 0, 3/97. Available online at www.maxim-ic.com. [69] Maxim, Low-Power, 12-Bit Voltage-Output DACs with Serial Interface, MAX5353, 19-1196, Rev 0, 2/97. Available online at www.maxim-ic.com. [70] Maxim, Low-Power, 2-Wire Serial 8-Bit DACs with Rail-to-Rail Outputs, MAX518, 19-0393, Rev 1, 9/02. Available online at www.maxim-ic.com. [71] A. Silberschatz, P.B. Galvin, and G. Gagne, Operating System Concepts, 8/e, New York: Wiley 2008. [72] W. Stallings, Operating Systems: Internals and Design Principles 6/e, Upper Saddle River, NJ: Prentice-Hall, 2009. [73] B. Stuart, Principles of Operating Systems: Design and Application, Cengage, 2009. [74] A.B. Downey, The Little Book of Semaphores 2/e, Version 2.1.5, Green Tea Press, 2008. Available online at www.greenteapress.com/semaphores. [75] A. Dunkels, Protothreads: Lightweight, Stackless Threads in C. Available online at www.sics.se/~adam/pt/.

This page intentionally left blank

INDEX

& operator, 13 | operator, 13 ~ operator, 13 8-bit operations, 105–109 16-bit operations, 88–91, 105–109 32-bit data (subroutines), 193–194 32-bit operations addition, 137–141 assignment operations, 134–136 bitwise logical operations, 136–137 comparison conditional tests, 144–146 equality conditional tests, 144–145 inequality conditional tests, 144–145 non-zero conditional tests, 141–144 overview, 134 shift operations, 141 subtraction, 137–141 zero conditional tests, 141–144 32-bit timers (pulse width measurement), 492–496 64-bit multiplication, 218–220 64-bit operations, 146–147

A ADCs (analog-to-digital converters) overview, 453–457 parallel port I/O, 290 PIC24

configuration, 463–469 operation, 469–474 overview, 460–463 sample and hold amplifiers, 459–460 successive approximation, 457–459 adders (combinational building blocks), 20–21 addition binary numbers, 8–9 hexadecimal numbers, 8–9 operations 32-bit, 137–141 fixed-point arithemetic, 228–229 three-operand, 74–76 two-operand, 76 addressing default working register (WREG), 67–69 file register addressing, 65–67 immediate addressing, 69–70 indirect addressing, 70–72 data dependencies, 171–172 instructions, 170–172 modes, 168–172 register indirect with signed constant offset mode, 170 troubleshooting, 170–172 instruction set regularity, 72–73 register direct addressing, 62–65 algebra, 12–19

696

Index

ALU (arithmetic logic unit), 230 amplifiers (ADCs), 459–460 analog-to-digital converters (ADCs) overview, 453–457 parallel port I/O, 290 PIC24 configuration, 463–469 operation, 469–474 overview, 460–463 sample and hold amplifiers, 459–460 successive approximation, 457–459 AND operations, 12–19 arbitration (Inter IC Bus), 553–557 architecture (PIC24), 645–652 arithmetic addition 32-bit, 137–141 binary numbers, 8–9 fixed-point arithemetic, 228–229 hexadecimal numbers, 8–9 three-operand, 74–76 two-operand, 76 BCD, 235–237 decrement instructions, 77 division, 220–225 fixed-point addition operations, 228–229 arithmetic logic unit (ALU), 230 converting binary numbers to decimal, 226–227 converting decimal numbers to binary, 226 overview, 225 saturating operations, 228–230 signed fixed-point, 227 subtraction operations, 228–229 unsupported instructions, 230 floating-point IEEE 754 encoding, 230–233 operations, 233–235 overview, 230 increment instructions, 77 multiplication 64-bit, 218–220 overview, 214–217 operators, 96–99 shift operations 32-bit operations, 141 binary numbers, 11–12

hexadecimal numbers, 11–12 signed data, 155–157 subtraction 32-bit, 137–141 binary numbers, 10–11 fixed-point arithemetic, 228–229 hexadecimal numbers, 10–11 three-operand, 74–76 two-operand, 76 arithmetic logic unit (ALU), 230 arrays 32-bit data subroutines, 193–194 implementing, 190–193 overview, 186–189 repeat instruction, 196–198 strings, 195–196 ASCII converting ASCII decimal numbers to binary, 242 ASCII hexadecimal numbers to binary, 240–241 binary numbers to decimal, 239–240 binary numbers to hexadecimal, 237–239 overview, 30–31 assembly language C comparison, 248–250 programs 16-bit operations, 88–91 data types, 80 nop instruction, 87 overview, 79–87 Word, 88–91 stored program machines, 40–44 assignment operations, 134–136 asynchronous serial I/O, 374–380. See also UART

B baud rate (UART), 384–386 BCD (binary coded decimal), 235–237 binary data, 4–7 binary numbers addition, 8–9 BCD arithmetic, 235–237 converting to ASCII decimal, 239–240 ASCII hexadecimal, 237–239 decimal, 226–227

Index

hexadecimal, 7–8 overview, 5–7 shift operations, 11–12 subtraction, 10–11 bit tests (unsigned conditional tests), 115–116 bits configuration bits, 272–273 control bits (parallel port I/O), 291 references (compilers), 251–255 bitwise logical operations (32-bit operations), 136–137 bitwise operators, 96–99 Boolean algebra operations, 12–19 branch instructions encoding, 161–163 unsigned conditional tests, 118–123 buffers Inter IC bus, 441–445 parallel port I/O Schmitt Trigger buffers, 288 tristate buffers, 287 building blocks combinational adders, 20–21 incrementers, 21 memory, 22–23 multiplexers, 19–20 overview, 19 shifters, 22 sequential counters, 28 overview, 27 registers, 27–28 shift registers, 28–29 busses (Inter IC bus) arbitration, 553–557 buffers, 441–445 ESOS messaging, 638–641 operations, 629–632 overview, 628–629 semaphores, 636–638 transactions, 632–635 interrupts, 441–445 library functions, 424–431 master-slave relationships, 549–553 overview, 419–420

registers, 427–431 reverse string, 555–557 serial EEPROM, 436–445 signals, 421–423 streaming data, 441–445 thermometer, 432–435 transactions, 423–427, 431

C C assembly language comparison, 248–250 compiler bit references, 251–255 compilation process overview, 250–251 conditional compilation, 256–257 function registers, 251–255 inline functions, 256 macros, 256 overview, 250–251 run-time code, 255 variables, 255 calendar (real-time clock calendar module), 532–537 call/return data memory stack, 177–179 stack, 174–179 CAN (controller area network), 558–572 capacitors, 658–659 cascade mode (pulse width measurement), 504–506 change notification interrupts idle, 330 I/O, 329, 345–353 latency, 330–332 LED, 345–353 sleep, 330 switches, 345–353 timers, 345–353 characters (encoding character data), 30–31 child tasks (ESOS), 621–624 circuits capacitors, 658–659 current, 653–657 diodes, 657 Ohm’s Law, 654–655 polarization, 657 resistance, 653–657 voltage, 653–657

697

698

Index

clock configuration, 273 real-time clock calendar module, 532–537 signal instruction execution, 91–92 sequential logic, 24–25 CMOS operations, 16–19 code (ASCII) converting ASCII decimal numbers to binary, 242 ASCII hexadecimal numbers to binary, 240–241 binary numbers to decimal, 239–240 binary numbers to hexadecimal, 237–239 overview, 30–31 combinational building blocks adders, 20–21 incrementers, 21 memory, 22–23 multiplexers, 19–20 overview, 19 shifters, 22 communication ESOS, 604–608 serial link startup schematic, 262 testing, 267–270 comparison conditional tests, 116–123, 144–146 comparison operations (signed data), 157–159 compilation conditional compilation, 256–257 process overview, 250–251 compiler bit references, 251–255 compilation process overview, 250–251 conditional compilation, 256–257 function registers, 251–255 inline functions, 256 macros, 256 overview, 250–251 run-time code, 255 variables, 255 complements (signed data) one’s complement, 148–149 two’s complement, 149–153 complex conditional expressions, 123–126 components (startup schematic), 263 compound operations, 105–109

computers (stored program machines) assembly language, 40–44 finite state machines comparison, 34–35 hardware, 44–47 instructions, 40–44 modern computer comparison, 48 overview, 40 conditional compilation, 256–257 conditional execution complex conditional expressions, 123–126 overview, 109–111 unsigned conditional tests bit tests, 115–116 branch instructions, 118–123 comparison conditional tests, 116–123, 144–146 equality conditional tests, 116, 144–145 inequality conditional tests, 116–118, 144–145 non-zero conditional tests, 112–114, 141–144 overview, 111–112 zero conditional tests, 112–114, 141–144 conditional tests (unsigned) bit tests, 115–116 branch instructions, 118–123 comparison conditional tests, 116–123, 144–146 equality conditional tests, 116, 144–145 inequality conditional tests, 116–118, 144–145 non-zero conditional tests, 112–114, 141–144 overview, 111–112 zero conditional tests, 112–114, 141–144 configuration ADCs, 463–469 baud rate (UART), 384–386 clock, 273 configuration bits, 272–273 UART, 386–389 configuration bits, 272–273 configuration macros (parallel port I/O), 291–293 control bits (parallel port I/O), 291 control registers (UART), 380–384 controller area network (CAN), 558–572 converting ADCs. See ADCs ASCII decimal numbers to binary, 242 ASCII hexadecimal numbers to binary, 240–241 binary numbers to ASCII decimal, 239–240 binary numbers to ASCII hexadecimal, 237–239 binary numbers to decimal, 226–227

Index

binary numbers to hexadecimal, 7–8 DACs (digital-to-analog converters) external examples, 482–486 flash, 475–482 Maxim548A, 483–486 overview, 474–475 PWM, 530–532 R-2R resistor ladder, 475–482 data overview, 450 sensors, 450–453 transducers, 450–453 data types, 106 decimal numbers to binary, 226 hexadecimal numbers to binary, 7–8 counters (sequential building blocks), 28 CPUs (SPI), 414–419 current, 653–657

D DACs (digital-to-analog converters) external examples, 482–486 flash, 475–482 Maxim548A, 483–486 overview, 474–475 PWM, 530–532 R-2R resistor ladder, 475–482 data ADCs. See ADCs binary, 4–7 converting overview, 450 sensors, 450–453 transducers, 450–453 DACs (digital-to-analog converters) external examples, 482–486 flash, 475–482 Maxim548A, 483–486 overview, 474–475 PWM, 530–532 R-2R resistor ladder, 475–482 data dependencies (indirect addressing), 171–172 data transfer. See data transfer encoding character data, 30–31 signed data. See signed data streaming data (Inter IC bus), 441–445 data dependencies (indirect addressing), 171–172

699

data memory organization, 58–60 values, 60–62 data memory stack, 175–179 data registers (UART), 380–384 data transfer default working register (WREG), 67–69 file register addressing, 65–67 immediate addressing, 69–70 indirect addressing, 70–72 data dependencies, 171–172 instructions, 170–172 modes, 168–172 register indirect with signed constant offset mode, 170 troubleshooting, 170–172 instruction set regularity, 72–73 overview, 62 register direct addressing, 62–65 data types assembly language programs, 80 type conversion, 106 datasheets, reading, 270–271 DC motor speed (PWM), 523–524 debugging ISRs, 365–366 decimal numbers converting ASCII decimal to binary, 242 converting to binary, 226 overview, 5–7 decrement instructions, 77 default interrupt handlers, 325–327 default working register (WREG), 67–69, 108 DFF (D-Flip-Flop), 25–27 digital logic, 4–7 digital-to-analog converters (DACs) external examples, 482–486 flash, 475–482 Maxim548A, 483–486 overview, 474–475 PWM, 530–532 R-2R resistor ladder, 475–482 diodes, 657 direct memory access (DMA), 542–549 disabling interrupts, 322 division, 220–225 DMA (direct memory access), 542–549 doze mode, 276–284 dynamic memory allocation, 180–182

700

Index

E ECAN™ module, 562–572 echo program, 267 EEPROM (Inter IC bus), 436–445 embedded system operating system (ESOS) child tasks, 621–624 communication, 604–608 flags, 619–620 Inter IC Bus messaging, 638–641 operations, 629–632 overview, 628–629 semaphores, 636–638 transactions, 632–635 interrupts, 624–628 messaging, 615–619 overview, 596–598 program, 602–604 semaphores, 611–615, 636–638 tasks, 598–602 timer, 608–610 encoding/encoders branch instructions, 161–163 character data, 30–31 IEEE 754 floating-point, 230–233 NRZ encoding, 375–380 one-hot encoding, 4 rotary encoders, 355–359 serial I/O, 375–380 equality conditional tests, 116, 144–145 ESOS (embedded systems operating system) child tasks, 621–624 communication, 604–608 flags, 619–620 Inter IC Bus messaging, 638–641 operations, 629–632 overview, 628–629 semaphores, 636–638 transactions, 632–635 interrupts, 624–628 messaging, 615–619 overview, 596–598 program, 602–604 semaphores, 611–615, 636–638 tasks, 598–602 timer, 608–610

execution conditional execution. See conditional execution instructions, 91–92 expressions (complex conditional expressions), 123–126 extensions (sign extension), 151, 159–161 external DACs, 482–486 external interrupts, 332–336

F families (PIC24), 310–311 file register addressing, 65–67 filtering noisy inputs, 353–355 finite state machines overview, 35–40 stored program machines comparison, 34–35 fixed-point arithmetic addition operations, 228–229 arithmetic logic unit (ALU), 230 converting binary numbers to decimal, 226–227 converting decimal numbers to binary, 226 overview, 225 saturating operations, 228–230 signed fixed-point, 227 subtraction operations, 228–229 unsupported instructions, 230 flags (ESOS), 619–620 flash (DACs), 475–482 flashing LED program, 263–267 floating-point arithmetic IEEE 754 encoding, 230–233 operations, 233–235 overview, 230 function registers, 251–255 functions function registers, 251–255 inline functions, 256 ISRs default interrupt handlers, 325–327 overview, 325 traps, 327–329 library functions Inter IC bus, 424–431 stdio.h library functions, 389 UART, 386–389

Index

G–H global variables, 203–206 goto instructions, 77–79 handlers (default interrupt handlers), 325–327 hardware (stored program machines), 44–47 hexadecimal numbers addition, 8–9 converting ASCII hexadecimal to binary, 240–241 converting to binary, 7–8 overview, 5–7 shift operations, 11–12 subtraction, 10–11

I idle, 276–284, 330 IEEE 754, 230–233 immediate addressing, 69–70 implementing arrays, 190–193 pointers, 190–193 subroutines, 179–186 in-circuit serial programming, 262–263 increment instructions, 77 incrementers (combinational building blocks), 21 indirect addressing, 70–72 data dependencies, 171–172 instructions, 170–172 modes, 168–172 register indirect with signed constant offset mode, 170 troubleshooting, 170–172 inequality conditional tests, 116–118, 144–145 infrared decoder, 507–515 initializing global variables, 203–206 inline functions, 256 input. See I/O input capture mode (pulse width measurement), 507–515 input capture module (pulse width measurement), 496–506 input change notification (parallel port I/O), 289–290 input sampling (LED/switches), 343–346 instructions branch instructions encoding, 161–163 unsigned conditional tests, 118–123 clock signal, 91–92

data transfer. See data transfer decrement, 77 execution, 91–92 fixed-point arithemetic, 230 goto, 77–79 increment, 77 indirect addressing, 170–172 move instructions default working register (WREG), 67–69 file register addressing, 65–67 immediate addressing, 69–70 indirect addressing, 70–72 instruction set regularity, 72–73 register direct addressing, 62–65 nop, 87 PIC24 overview, 645–652 program control, 77–79 repeat arrays, 196–198 pointers, 196–198 status register, 100–101 stored program machines, 40–44 unsupported instructions, 230 Inter IC bus arbitration, 553–557 buffers, 441–445 ESOS messaging, 638–641 operations, 629–632 overview, 628–629 semaphores, 636–638 transactions, 632–635 interrupts, 441–445 library functions, 424–431 master-slave relationships, 549–553 overview, 419–420 registers, 427–431 reverse string, 555–557 serial EEPROM, 436–445 signals, 421–423 streaming data, 441–445 thermometer, 432–435 transactions, 423–427, 431 interfaces/interfacing keypads, 359–364 LCD modules, 301–310

701

702

Index

interfaces/interfacing (continued) SPI master-slave relationships, 414–419 multiple CPUs, 414–419 overview, 401–408 potentiometer, 408–411 thermometer, 411–414 interrupt service routines (ISRs) debugging, 365–366 functions default interrupt handlers, 325–327 overview, 325 traps, 327–329 overhead, 324 overview, 318 rotary encoders, 355–359 writing, 365–366 interrupts change notification idle, 330 I/O, 329 latency, 330–332 sleep, 330 timers, 345–353 default interrupt handlers, 325–327 disabling, 322 ESOS, 624–628 filtering noisy inputs, 353–355 Inter IC bus, 441–445 INTx external interrupts, 332–336 I/O change notification interrupts, 345–353 input sampling, 343–346 LED, 343–353 switches, 343–353 ISRs. See ISRs latency, 323–324 nesting, 322 overview, 318–320 priorities, 322 remappable I/O pins, 332–336 service routines. See ISRs rotary encoders, 355–359 timers macros, 339–341 overview, 336–339

square waves, 341–343 testing, 341–343 traps, 322–323, 327–329 UART receive, 390–394 transmit, 394–399 vector tables, 320–321 INTx external interrupts, 332–336 I/O filtering noisy inputs, 353–355 input capture mode (pulse width measurement), 507–515 input capture module (pulse width measurement), 496–506 input change notification (parallel port I/O), 289–290 input sampling (LED/switches), 343–346 interrupts change notification interrupts, 329 UART receive, 390–394 UART transmit, 394–399 LED change notification interrupts, 345–353 input sampling, 343–346 interrupts, 343–353 state machines, 293–301 output compare module (pulse width measurement), 516–520 parallel port I/O analog-to-digital converters, 290 configuration macros, 291–293 control bits, 291 input change notification, 289–290 open-drain output, 288–289 overview, 284–286 Schmitt Trigger buffers, 288 serial I/O comparison, 372–374 tristate buffers, 287 weak pull-ups, 289–290 remappable I/O pins, 332–336 RS-232 standard, 399–400 serial I/O asynchronous, 374–380 NRZ encoding, 375–380 parallel port I/O comparison, 372–374 synchronous, 374–375 UART. See UART

Index

SPI master-slave relationships, 414–419 multiple CPUs, 414–419 overview, 401–408 potentiometer, 408–411 thermometer, 411–414 switches change notification interrupts, 345–353 input sampling, 343–346 interrupts, 343–353 state machines, 293–301 ISRs (interrupt service routines) debugging, 365–366 functions default interrupt handlers, 325–327 overview, 325 traps, 327–329 overhead, 324 overview, 318 rotary encoders, 355–359 writing, 365–366

K–L keypads, 359–364 ladders (DACs), 475–482 latency change notification interrupts, 330–332 interrupts, 323–324 LCD modules, 301–310 LEDs change notification interrupts, 345–353 flash program, 263–267 input sampling, 343–346 interrupts, 343–353 state machines, 293–301 left shift operations. See shift operations library functions Inter IC bus, 424–431 stdio.h library functions, 389 links (serial link) startup schematic, 262 testing, 267–270 local variables dynamic memory allocation, 180–182 registers, 182–186 stack frames, 199–203

703

logic digital, 4–7 logic operations, 12–19 sequential clock signal, 24–25 DFF (D-Flip-Flop), 25–27 overview, 23 logical operations (bitwise logical operations), 136–137 logical operators, 96–99 loops, 126–128 LSB operations, 108–109

M macros compiler, 256 configuration macros (parallel port I/O), 291–293 timers (interrupts), 339–341 magnitude (signed magnitude), 147–148 master-slave relationships Inter IC Bus, 549–553 SPI, 414–419 Maxim548A, 483–486 memory combinational building blocks, 22–23 data memory organization, 58–60 values, 60–62 data memory stack, 175–179 direct memory access (DMA), 542–549 dynamic memory allocation subroutine local variables, 180–182 subroutine parameters, 180–182 program memory, 57–58 regitsers, 104–105 RTSP (run-time self-programming), 572–580 messaging ESOS, 615–619, 638–641 Inter IC Bus, 638–641 OSes, 593–594 microcontrollers overview, 54–55 PIC24. See PIC24 microprocessors, 54–55 mixed operations, 105–109 modern computers, stored program machines comparison, 48

704

Index

modes indirect addressing, 168–172 pulse width measurement capture mode, 507–515 cascade mode, 504–506 modules ECAN™, 562–572 LCD, 301–310 pulse width measurement input capture module, 496–506 output compare module, 516–520 real-time clock calendar module, 532–537 motor speed (PWM), 523–524 move instructions default working register (WREG), 67–69 file register addressing, 65–67 immediate addressing, 69–70 indirect addressing, 70–72 instruction set regularity, 72–73 register direct addressing, 62–65 MSB operations, 108–109 multiple CPUs (SPI), 414–419 multiplexers, 19–20 multiplication 64-bit, 218–220 overview, 214–217 multitasking (Oses), 588–591

N NAND operations, 13–19 nesting interrupts, 322 networks (CAN), 558–572 noisy inputs, filtering, 353–355 non-return-to-zero (NRZ) encoding, 375–380 non-zero conditional tests, 112–114, 141–144 nop instruction, 87 NOR operations, 13–14, 16–19 NOT operations, 12–19 NRZ (non-return-to-zero) encoding, 375–380 number sequencing computers (stored program machines) assembly language, 40–44 finite state machines comparison, 34–35 hardware, 44–47 instructions, 40–44 modern computer comparison, 48 overview, 40

numbers ASCII decimal, converting to binary, 242 ASCII hexadecimal, converting to binary, 240–241 BCD arithetic, 235–237 binary addition, 8–9 converting to ASCII decimal, 239–240 converting to ASCII hexadecimal, 237–239 converting to decimal, 226–227 converting to hexadecimal, 7–8 overview, 5–7 shift operations, 11–12 subtraction, 10–11 decimal converting to binary, 226 overview, 5–7 hexadecimal addition, 8–9 converting to binary, 7–8 overview, 5–7 shift operations, 11–12 subtraction, 10–11

O Ohm’s Law, 654–655 one-hot encoding, 4 one’s complement, 148–149 open-drain output (parallel port I/O), 288–289 operating systems (OSes) ESOS child tasks, 621–624 communication, 604–608 flags, 619–620 interrupts, 624–628 messaging, 615–619 overview, 596–598 program, 602–604 semaphore, 611–615 tasks, 598–602 timer, 608–610 overview, 584–587 services, 594–595 tasks messaging, 593–594 multitasking, 588–591 overview, 587–588

Index

schedulers, 588–591 semaphores, 592–593 operations 8-bit, 105–109 16-bit operations, 88–91, 105–109 32-bit addition, 137–141 assignment operations, 134–136 bitwise logical operations, 136–137 comparison conditional tests, 144–146 equality conditional tests, 144–145 inequality conditional tests, 144–145 non-zero conditional tests, 141–144 overview, 134 shift operations, 141 subtraction, 137–141 zero conditional tests, 141–144 64-bit, 146–147 ADCs, 469–474 addition operations fixed-point arithemetic, 228–229 three-operand, 74–76 two-operand, 76 AND, 12–19 arrays 32-bit data subroutines, 193–194 implementing, 190–193 overview, 186–189 repeat instruction, 196–198 strings, 195–196 Boolean algebra operations, 12–19 CMOS, 16–19 compound, 105–109 default working register (WREG), 108 division, 220–225 ESOS, 629–632 fixed-point arithemetic, 228–230 floating point arithmetic, 233–235 Inter IC Bus, 629–632 logic operations, 12–19 LSB, 108–109 mixed, 105–109 MSB, 108–109 multiplication 64-bit, 218–220 overview, 214–217 NAND, 13–19

NOR, 13–14, 16–19 NOT, 12–19 OR, 12–19 pointers 32-bit data subroutines, 193–194 implementing, 190–193 overview, 186–189 repeat instruction, 196–198 strings, 195–196 rotate, 102–105 saturating operations, 228–230 shift, 102–105 32-bit operations, 141 binary numbers, 11–12 hexadecimal numbers, 11–12 signed data, 155–157 signed data comparison operations, 157–159 overview, 153–154 shift operations, 155–157 sign extension, 159–161 subtraction operations fixed-point arithemetic, 228–229 three-operand, 74–76 two-operand, 76 UART receive, 384 transmit, 383 XOR, 13 operators &, 13 |, 13 ~, 13 arithmetic, 96–99 bitwise, 96–99 logical, 96–99 OR operations, 12–19 organization data memory, 58–60 program memory, 57–58 OSes (operating systems) ESOS child tasks, 621–624 communication, 604–608 flags, 619–620 interrupts, 624–628 messaging, 615–619

705

706

Index

OSes (operating systems) (continued) overview, 596–598 program, 602–604 semaphore, 611–615 tasks, 598–602 timer, 608–610 overview, 584–587 services, 594–595 tasks messaging, 593–594 multitasking, 588–591 overview, 587–588 schedulers, 588–591 semaphores, 592–593 output. See I/O output compare module (pulse width measurement), 516–520 overflow two’s complement, 152–153 stack, 179 overhead (ISRs), 324

P parallel port I/O analog-to-digital converters, 290 configuration macros, 291–293 control bits, 291 input change notification, 289–290 open-drain output, 288–289 overview, 284–286 Schmitt Trigger buffers, 288 serial I/O comparison, 372–374 tristate buffers, 287 weak pull-ups, 289–290 parameters (subroutines) dynamic memory allocation, 180–182 registers, 182–186 stack frames, 199–203 period measurement, 504–506 persistent variables, 280–284 PIC24 ADCs configuration, 463–469 operation, 469–474 overview, 460–463 architecture, 645–652 arithmetic logic unit (ALU), 230

compiler bit references, 251–255 compilation process overview, 250–251 conditional compilation, 256–257 function registers, 251–255 inline functions, 256 macros, 256 overview, 250–251 run-time code, 255 variables, 255 data memory, 58–60–62 families, 310–311 instructions, 645–652 overview, 55–57 program memory, 57–58 startup schematic components, 263 in-circuit serial programming, 262–263 overview, 258–260 power, 260–261 reset, 261–262 serial link, 262 UART baud rate configuration, 384–386 configuration, 386–389 functions, 386–389 overview, 380–384–386 receive, 384, 390–394 registers, 380–384 stdio.h library functions, 389 transmit, 383, 394–399 unsupported instructions, 230 pins (remappable I/O pins), 332–336 pointers 32-bit data subroutines, 193–194 implementing, 190–193 overview, 186–189 repeat instruction, 196–198 stack pointers, 175 strings, 195–196 polarization (circuits), 657 ports (parallel port I/O) analog-to-digital converters, 290 configuration macros, 291–293 control bits, 291 input change notification, 289–290 open-drain output, 288–289

Index

overview, 284–286 Schmitt Trigger buffers, 288 serial I/O comparison, 372–374 tristate buffers, 287 weak pull-ups, 289–290 potentiometer (SPI), 408–411 power startup schematic, 260–261 timers, 276–284 power-on reset, 274–276 priorities (interrupts), 322 programming (in-circuit serial programming), 262–263 programs assembly language 16-bit operations, 88–91 data types, 80 nop instruction, 87 overview, 79–87 Word, 88–91 conditional execution. See conditional execution control, 77–79 echo, 267 ESOS, 602–604 LED flash, 263–267 memory, 57–58 pull-ups (weak pull-ups), 289–290 pulse width measurement 32-bit timers, 492–496 cascade mode, 504–506 infrared decoder, 507–515 input capture mode, 507–515 input capture module, 496–506 output compare module, 516–520 overview, 490–492 period measurement, 504–506 square waves, 519–520 push/pop (stack), 174–179 PWM (pulse width modulation) DACs, 530–532 DC motor speed, 523–524 overview, 520–522 servos, 524–529

R R-2R resistor ladder (DACs), 475–482 reading datasheets, 270–271 real-time clock calendar module, 532–537

707

receive (UART), 384, 390–394 references (bits), 251–255 register direct addressing, 62–65 register indirect with signed constant offset mode, 170 registers (sequential building blocks), 27–28 compiler function registers, 251–255 Inter IC bus, 427–431 memory, 104–105 register direct addressing, 62–65 register indirect with signed constant offset mode, 170 status register, 100–101 subroutine local variables, 182–186 subroutine parameters, 182–186 UART, 380–384 regularity (instruction set), 72–73 remappable I/O pins, 332–336 repeat instruction, 196–198 reset, 261–262, 274–276 resistance, 653–657 resistors (DACs), 475–482 reverse string (Inter IC Bus), 555–557 right shift operations. See shift operations rotary encoders, 355–359 rotate operations, 102–105 RS-232 standard, 399–400 RTSP (run-time self-programming), 572–580 run-time code (compiler), 255 run-time self-programming (RTSP), 572–580

S sample and hold amplifiers, 459–460 saturating operations, 228–230 schedulers (Oses), 588–591 schematic (startup) components, 263 in-circuit serial programming, 262–263 overview, 258–260 power, 260–261 reset, 261–262 serial link, 262 Schmitt Trigger buffers, 288 semaphores ESOS, 611–615, 636–638 Inter IC Bus, 636–638 OSes, 592–593 sensors (data conversion), 450–453

708

Index

sequential building blocks counters, 28 overview, 27 registers, 27–28 shift registers, 28–29 sequential logic clock signal, 24–25 DFF (D-Flip-Flop), 25–27 overview, 23 serial busses (Inter IC bus) arbitration, 553–557 buffers, 441–445 ESOS, messaging, 638–641 ESOS, operations, 629–632 ESOS, overview, 628–629 ESOS, semaphores, 636–638 ESOS, transactions, 632–635 interrupts, 441–445 library functions, 424–431 master-slave relationships, 549–553 overview, 419–420 registers, 427–431 reverse string, 555–557 serial EEPROM, 436–445 signals, 421–423 streaming data, 441–445 thermometer, 432–435 transactions, 423–427, 431 serial EEPROM, 436–445 serial I/O asynchronous, 374–380 NRZ encoding, 375–380 parallel port I/O comparison, 372–374 synchronous, 374–375 UART baud rate configuration, 384–386 configuration, 386–389 functions, 386–389 overview, 380–384–386 receive, 384, 390–394 registers, 380–384 stdio.h library functions, 389 transmit, 383, 394–399 serial link startup schematic, 262 testing, 267–270

Serial Peripheral Interface (SPI) master-slave relationships, 414–419 multiple CPUs, 414–419 overview, 401–408 potentiometer, 408–411 thermometer, 411–414 serial programming, 262–263 services interrupt service routines. See ISRs OSes, 594–595 servos (pulse width modulation), 524–529 shift operations, 102–105 32-bit operations, 141 binary numbers, 11–12 hexadecimal numbers, 11–12 signed data, 155–157 shift registers (sequential building blocks), 28–29 shifters (combinational building blocks), 22 sign extension, 151, 159–161 signals (Inter IC bus), 421–423 signed data one’s complement, 148–149 operations comparison operations, 157–159 overview, 153–154 shift operations, 155–157 sign extension, 159–161 overflow, 152–153 overview, 147 sign extension, 151, 159–161 signed magnitude, 147–148 two’s complement, 149–153 signed fixed-point, 227 signed magnitude, 147–148 sleep interrupts (change notification interrupts), 330 sleep mode, 276–284 sleep mode, 276–284 speed (DC motors), 523–524 SPI (Serial Peripheral Interface) master-slave relationships, 414–419 multiple CPUs, 414–419 overview, 401–408 potentiometer, 408–411 thermometer, 411–414 square waves pulse width measurement, 519–520 timers (interrupts), 341–343

Index

stack call/return, 174–179 data memory stack, 175–179 overflow/underflow, 179 overview, 174–175 push/pop, 174–179 stack frames, 199–203 stack pointers, 175 subroutine local variables, 199–203 subroutine parameters, 199–203 stack frames, 199–203 stack pointers, 175 startup schematic components, 263 in-circuit serial programming, 262–263 overview, 258–260 power, 260–261 reset, 261–262 serial link, 262 state machines, 293–301 status register, 100–101 stdio.h library functions, 389 stored program machines assembly language, 40–44 finite state machines comparison, 34–35 hardware, 44–47 instructions, 40–44 modern computer comparison, 48 overview, 40 streaming data (Inter IC bus), 441–445 strings arrays, 195–196 pointers, 195–196 reverse string (Inter IC Bus), 555–557 subroutines, 172–174 32-bit data arrays, 193–194 pointers, 193–194 implementing, 179–186 local variables dynamic memory allocation, 180–182 registers, 182–186 stack frames, 199–203 parameters dynamic memory allocation, 180–182 registers, 182–186 stack frames, 199–203

709

stack call/return, 174–179 data memory stack, 175–179 overflow/underflow, 179 overview, 174–175 pointers, 175 push/pop, 174–179 stack frames, 199–203 subtraction binary numbers, 10–11 hexadecimal numbers, 10–11 operations 32-bit, 137–141 fixed-point arithemetic, 228–229 three-operand, 74–76 two-operand, 76 successive approximation (ADCs), 457–459 switches change notification interrupts, 345–353 input sampling, 343–346 interrupts, 343–353 state machines, 293–301 synchronous serial I/O, 374–375

T tables (vector tables), 320–321 tasks child tasks, 621–624 ESOS, 598–602, 621–624 OSes messaging, 593–594 multitasking, 588–591 overview, 587–588 schedulers, 588–591 semaphores, 592–593 testing/tests serial link, 267–270 timers (interrupts), 341–343 unsigned conditional tests bit tests, 115–116 branch instructions, 118–123 comparison conditional tests, 116–123, 144–146 equality conditional tests, 116, 144–145 inequality conditional tests, 116–118, 144–145 non-zero conditional tests, 112–114, 141–144 overview, 111–112 zero conditional tests, 112–114, 141–144

710

Index

thermometer Inter IC bus, 432–435 SPI, 411–414 three-operand addition operations, 74–76 three-operand subtraction operations, 74–76 timers ESOS, 608–610 interrupts change notification interrupts, 345–353 macros, 339–341 overview, 336–339 square waves, 341–343 testing, 341–343 overview, 276–284 pulse width measurement 32-bit timers, 492–496 cascade mode, 504–506 infrared decoder, 507–515 input capture mode, 507–515 input capture module, 496–506 output compare module, 516–520 overview, 490–492 period measurement, 504–506 square waves, 519–520 PWM (pulse width modulation) DACs, 530–532 DC motor speed, 523–524 overview, 520–522 servos, 524–529 real-time clock calendar module, 532–537 transactions (Inter IC bus), 423–427, 431, 632–635 transducers, 450–453 transfering data default working register (WREG), 67–69 file register addressing, 65–67 immediate addressing, 69–70 indirect addressing, 70–72 data dependencies, 171–172 instructions, 170–172 modes, 168–172 register indirect with signed constant offset mode, 170 troubleshooting, 170–172 instruction set regularity, 72–73 overview, 62 register direct addressing, 62–65 transmit operations (UART), 383, 394–399

traps interrupts, 322–323 ISRs, 327–329 tristate buffers (parallel port I/O), 287 troubleshooting indirect addressing, 170–172 two’s complement (signed data), 149–153 two-operand addition operations, 76 two-operand subtraction operations, 76 type conversion, 106

U UART (Universal Asynchronous Receiver Transmitter). See also asynchronous serial I/O baud rate configuration, 384–386 configuration, 386–389 functions, 386–389 interrupts receive, 390–394 transmit, 394–399 overview, 380–384–386 receive operations, 384 registers, 380–384 stdio.h library functions, 389 transmit operations, 383 unsigned conditional tests bit tests, 115–116 branch instructions, 118–123 comparison conditional tests, 116–123, 144–146 equality conditional tests, 116, 144–145 inequality conditional tests, 116–118, 144–145 non-zero conditional tests, 112–114, 141–144 overview, 111–112 zero conditional tests, 112–114, 141–144 unsupported instructions (fixed-point arithemetic), 230

V values (data memory), 60–62 variables compiler, 255 global variables, initializing, 203–206 local variables subroutine dynamic memory allocation, 180–182 subroutine registers, 182–186 subroutine stack frames, 199–203 persistent, 280–284

Index

pointers 32-bit data subroutines, 193–194 implementing, 190–193 overview, 186–189 repeat instruction, 196–198 stack pointers, 175 strings, 195–196 vector tables (interrupts), 320–321 voltage, 653–657

W–Z watchdog timer, 276–284 weak pull-ups, 289–290 Word, 88–91 WREG (default working register), 67–69, 108 writing (ISRs), 365–366 XOR operations, 13 zero conditional tests, 112–114, 141–144

711