Pic Microcontroller Detail Document

Introduction

PIC controllers are a family of small risk controllers used in embedded applications. PIC controllers are produced by the company „Microchip“ Literature can be obtained from the Microchip web site (www.icrochip.com). The growth of the 8-bit MCU market share is a testament to the PICmicro MCUs ability to meet the needs of many. This growth has made the PICmicro architecture one of the top three architectures available in the general market today. This growth was fueled by the Microchip vision of the benefits of a low-cost OTP solution. Some of the benefits for the customer include: PICmicro devices are grouped by the size of their Instruction Word. The three current PICmicro families are:

1. Base-Line: 12-bit Instruction Word length
2. Mid-Range: 14-bit Instruction Word length
3. High-End: 16-bit Instruction Word length

This manual focuses on the Mid-Range devices, which are also referred to as the PIC16Cxxx MCU family. The operation of the PIC16CXXX MCU family architecture and peripheral modules is explained but does not cover the specifics of each device. Therefore, it is not intended to replace the device datasheets but complements them. In other words, this guide supplies the general details and operation of the PICmicro architecture and peripheral modules, while the datasheets give specific details such as device memory mapping. Initialization examples are given throughout this manual.

These examples sometimes need to be written as device-specific as opposed to family generic, though they are valid for most other devices. Some modifications may be required for devices with variations in register file mappings.

Device Structure

Each part of a device can be placed into one of three groups:

1. Core
2. Peripherals
3. Special Features

The core pertains to the basic features that are required to make the device operate:

1. Device Oscillator
2. Reset logic
3. CPU (Central Processing Unit) operation
4. ALU (Arithmetic Logical Unit) operation
5. Device memory map organization
6. Interrupt operation Revision
7. Instruction set Revision Peripherals are the features that add a differentiation from a microprocessor.

These ease in interfacing to the external world (such as general-purpose I/O, LCD drivers, A/D inputs, and PWM outputs), and internal tasks such as keeping different time bases (such as timers).

The peripherals that are discussed are:

1. General-purpose I/O
2. Timer0
3. Timer1
4. Timer2
5. Capture, Compare, and PWM (CCP)
6. Synchronous Serial Port (SSP)
7. Basic Synchronous Serial Port (SSP)
8. Master Synchronous Serial Port (MSSP)
9. USART (SCI)
10. Voltage References
11. Comparators
12. 8-bit Analog to Digital (A/D)
13. Basic 8-bit Analog to Digital (A/D)
14. 10-bit Analog to Digital (A/D)
15. Slope Analog to Digital (A/D) w/ Thermister
16. Liquid Crystal Display (LCD) Drivers
17. Parallel Slave Port (PSP)

Special features are the unique features that help to do one or more of the following things: -Decrease system cost – Increase system reliability – Increase design flexibility The Mid-Range PICmicro MCUs offer several features that help achieve these goals:

1. Device Configuration bits
2. On-chip Power-on Reset (POR)
3. Brown-out Reset (BOR) logic
4. Watchdog Timer
5. Low power mode (Sleep)
6. Internal RC device oscillator
7. In-Circuit Serial Programming™ (ICSP™) Revision “DS31028A”
8. Architecture

The high performance of the PICmicro™ devices can be attributed to a number of architectural features commonly found in RISC microprocessors: ¦ Harvard architecture ¦ Long Word Instructions ¦ Single Word Instructions ¦ Single Cycle Instructions ¦ Instruction Pipelining ¦ Reduced Instruction Set ¦ Register File Architecture ¦ Orthogonal (Symmetric) Instructions Harvard Architecture: Harvard architecture has the program memory and data memory as separate memories and are accessed from separate buses. This improves bandwidth over traditional von Neumann architecture in which program and data are fetched from the same memory using the same bus.

To execute an instruction, a von Neumann machine must make one or more (generally more) accesses across the 8-bit bus to fetch the instruction. Then data may need to be fetched, operated on, and possibly written. As can be seen from this description, that bus can be extremely busy. While with a Harvard architecture, the instruction is fetched in a single instruction cycle (all 14-bits). While the program memory is being accessed, the data memory is on an independent bus and can be read and written. These separated buses allow one instruction to execute while the next instruction is fetched.

Long Word Instructions: Long word instructions have a wider (more bits) instruction bus than the 8-bit Data Memory Bus. This is possible because the two buses are separate. This further allows instructions to be sized differently than the 8-bit wide data word which allows more efficient use of the program memory since the program memory width is optimized to the architectural requirements.

Single Word Instructions: Single Word instruction opcodes are 14-bits wide making it possible to have all single-word instructions. A 14-bit wide program memory access bus fetches a 14-bit instruction in a single cycle. With single-word instructions, the number of words of program memory locations equals the number of instructions for the device. This means that all locations are valid instructions. Typically in the von Neumann architecture, most instructions are multi-byte. In general, a device with 4-KBytes of program memory would allow approximately 2K of instructions.

This 2:1 ratio is generalized and dependent on the application code. Since each instruction may take multiple bytes, there is no assurance that each location is a valid instruction. Instruction Pipeline: The instruction pipeline is a two-stage pipeline which overlaps the fetch and execution of instructions. The fetch of the instruction takes one TCY, while the execution takes another TCY. However, due to the overlap of the fetch of current instruction and execution of previous instruction, an instruction is fetched and another instruction is executed every single TCY.

Single Cycle Instructions: With the Program Memory bus being 14-bits wide, the entire instruction is fetched in a single machine cycle (TCY). The instruction contains all the information required and is executed in a single cycle. There may be a one-cycle delay in execution if the result of the instruction modified the contents of the Program Counter. This requires the pipeline to be flushed and a new instruction to be fetched. Reduced Instruction Set: (RISC) When an instruction set is well designed and highly orthogonal (symmetric), fewer instructions are required to perform all needed tasks.

With fewer instructions, the whole set can be more rapidly learned. Register File Architecture: The register files/data memory can be directly or indirectly addressed. All special function registers, including the program counter, are mapped in the data memory. Orthogonal (Symmetric) Instructions: Orthogonal instructions make it possible to carry out any operation on any register using any addressing mode. This symmetrical nature and lack of “special instructions” make programming simple yet efficient. In addition, the learning curve is reduced significantly.

The mid-range instruction set uses only two non-register oriented instructions, which are used for two of the core features. One is the SLEEP instruction which places the device into the lowest power use mode. The other is the CLRWDT instruction which verifies the chip is operating properly by preventing the on-chip Watchdog Timer (WDT) from overflowing and resetting the device.

General Mid-range PICmicro Block Diagram

Memory Organisation

There are two memory blocks, program memory, and data memory. Each block has its own bus so that access to each block can occur during the same oscillator cycle. The data memory can further be broken down into General Purpose RAM and the Special Function Registers (SFRs). Mid-Range MCU devices have a 13-bit program counter capable of addressing an 8K x 14 program memory space.

The width of the program memory bus (instruction word) is 14-bits. Since all instructions are a single word, a device with an 8K x 14 program memory has space for 8K of instructions. This makes it much easier to determine if a device has sufficient program memory for the desired application. This program memory space is divided into four pages of 2K words each (0h – 7FFh, 800h -FFFh, 1000h – 17FFh, and 1800h – 1FFFh). The figure shows the program memory map as well as the 8 level deep hardware stack. Depending on the device, only a portion of this memory may be implemented.

Please refer to the device datasheet for the available memory. To jump between the program memory pages, the high bits of the Program Counter (PC) must be modified. This is done by writing the desired value into an SFR called PCLATH (Program Counter Latch High). If sequential instructions are executed, the program counter will cross the page boundaries without any user intervention. For devices that have less than 8K words, accessing a location above the physically implemented address will cause a wraparound. That is, in a 4K-word device accessing 17FFh actually addresses 7FFh. 2K-word devices (or less) don not require paging.

Reset Vector

On any device, a reset forces the Program Counter (PC) to address 0h. We call this address the “Reset Vector Address” since this is the address that program execution will branch to when a device reset occurs. Any reset will also clear the contents of the PCLATH register. This means that any branch at the Reset Vector Address (0h) will jump to that location in PAGE0 of the program memory.

Interrupt Vector

When an interrupt is acknowledged the PC is forced to address 0004h. We call this the “Interrupt Vector Address”. When the PC is forced to the interrupt vector, the PCLATH register is not modified. Once in the service interrupt routine (ISR), this means that before any write to the PC, the PCLATH register should be written with the value that will specify the desired location in program memory. Before the PCLATH register is modified by the Interrupt Service Routine (ISR) the contents of the PCLATH may need to be saved, so it can be restored before returning from the ISR.

Stack The stack allows a combination of up to 8 program calls and interrupts to occur. The stack contains the return address from this branch in program execution. Mid-Range MCU devices have an 8-level deep x 13-bit wide hardware stack. The stack space is not part of either program or data space and the stack pointer is not readable or writable. The PC is PUSHed onto the stack when a CALL instruction is executed or an interrupt causes a branch. The stack is POPed in the event of a RETURN, RETLW or a RETFIE instruction execution. PCLATH is not modified when the stack is PUSHed or POPed.

After the stack has been PUSHed eight times, the ninth push overwrites the value that was stored from the first push. The tenth push overwrites the second push (and so on).

Special Function Registers (SFR)

The SFRs are used by the CPU and Peripheral Modules for controlling the desired operation of the device. These registers are implemented as static RAM.

The SFRs can be classified into two sets, those associated with the “core” function and those related to the peripheral functions. All Mid-Range MCU devices have banked memory in the SFR area. Switching between these banks requires the RP0 and RP1 bits in the STATUS register to be configured for the desired bank. Some SFRs are initialized by a Power-on Reset and other resets, while other SFRs are unaffected. Banking The data memory is partitioned into four banks. Each bank contains General Purpose Registers and Special Function Registers.

Switching between these banks requires the RP0 and RP1 bits in the STATUS register to be configured for the desired bank when using direct addressing. The IRP bit in the STATUS register is used for indirect addressing. Each Bank extends up to 7Fh (128 bytes). The lower locations of each bank are reserved for the Special Function Registers. Above the Special Function Registers are General Purpose Registers. All data memory is implemented as static RAM. All Banks may contain special function registers. Some “high use” special function registers from Bank0 are mirrored in the other banks for code reduction and quicker access.

Through the evolution of the products, there are a few variations in the layout of the Data Memory. The data memory organization that will be the standard for all new devices is shown in the Figure. This Memory map has the last 16-bytes mapped across all memory banks. This is to reduce the software overhead for context switching. The registers in bold will be in every device. The other registers are peripheral dependent.

Not every peripheral’s registers are shown, because some file addresses have a different register from those shown. As with all the figures, tables, and specifications presented in this reference guide, verify the details with the device-specific data sheet. Register file map: The following map shows the register file memory map of some 18-pin devices. (Unimplemented registers will read as ‘0’)

Instruction Set

The Central Processing Unit (CPU) is responsible for using the information in the program memory (instructions) to control the operation of the device. Many of these instructions operate on data memory. To operate on data memory, the Arithmetic Logical Unit (ALU) is required. In addition to performing arithmetical and logical operations, the ALU controls status bits (which are found in the STATUS register).

The result of some instructions force status bits to a value depending on the state of the result. The machine codes that the CPU recognizes are show (as well as the instruction mnemonics that the MPASM uses to generate these codes). Mid-Range MCU Instruction Set.

The Integrated Development Environment (IDE)

The core set of development tools operate under the IDE umbrella, called MPLAB.

This gives a consistent look and feels to all the development tools so that minimal learning of the new tool interface is required. The MPLAB IDE integrates all the following aspects of development:

• Source code editing
• Project management
• Machine code generation (from assembly or “C”)
• Device simulation
• Device emulation
• Device programming

This comprehensive tool suite allows the complete development of a project without leaving the MPLAB environment. MPLAB The MPLAB IDE Software brings an ease of software development previously unseen in the 8-bit microcontroller market.

MPLAB is a Windows-based application that contains:

• A full-featured editor
• Three operating modes – editor – emulator – simulator
• A project manager
• Extensive on-line help MPLAB allows you to:
  • Edit your source files. (ASM and C files)
  • One-touch assemble (or compile) and download to PIC16/17 tools
  • Debug using: – source files – absolute listing file – program memory
  • Run up to four emulators on the same PC
  • Run or Single-step – program memory – source file – absolute listing Microchip’s simulator, MPLAB-SIM, operates under the same platform as the PICMASTER emulator.

This allows the user to learn a single toolset that functions equivalently for both the simulator and the full-featured emulator. de MPLAB Software Language Support To make the device operate as desired in the application, a software program needs to be written for the microcontroller. This software program needs to be written in one of the programming languages for the device.

Currently, MPLAB supports two of Microchip’s language products:

• Microchip Assembler (MPASM)
• Microchip ‘C’ Compiler (MPLAB-C) Assembler (MPASM)

The MPASM Universal Macro Assembler is a PC-hosted symbolic assembler. It supports all Microchip microcontroller families. MPASM offers full-featured Macro capabilities, conditional assembly, and several sources and listing formats. It generates various object code formats to support Microchip’s development tools as well as third party programmers.

Provides translation of Assembler source code to object code for all Microchip microcontrollers. Macro assembly capability. Produces all the files (Object, Listing, Symbol, and special) required for symbolic debug with Microchip’s emulator systems. Supports Hex (default), Decimal and Octal source, and listing formats. MPASM provides a rich directive language to support the programming of the PICmicro. Directives are helpful in making the development of your assemble source code shorter and more maintainable. C Compiler (MPLAB-C) The MPLAB-C is a complete ‘C’ compiler for Microchip’s PICmicro family of microcontrollers.

For easier source level debugging, the compiler provides symbol information that is compatible with the MPLAB IDE memory display, Watch windows, and File register windows.

MPLINK Linker

MPLINK is a linker for the Microchip C compiler, MPLAB-C, and the Microchip relocatable assembler, MPASM. MPLINK allows you to produce modular, re-usable code with MPLAB-C and MPASM. Control over the linking process is accomplished through a linker “script” file and with command-line options. MPLINK ensures that all symbolic references are resolved and that code and data fit into the available PICmicro device.

MPLINK combines multiple input object modules generated by MPLAB-C or MPASM, into a single executable file. The actual addresses of data and the location of functions will be assigned when MPLINK is executed. This means that you will instruct MPLINK to place code and data somewhere within the named regions of memory, not to specific physical locations. Once the linker knows about the ROM and RAM memory regions available in the target PICmicro device and it analyzes all the input files, it will try to fit the application’s routines into ROM and assign it’s data variables into available RAM.

If there is too much code or too many variables to fit, MPLINK will give an error. MPLINK also provides flexibility for specifying that certain blocks of data memory are reusable, so that different routines (which never call each other and don’t depend on this data to be retained between execution) can share limited RAM space.

MPLIB Librarian MPLIB is a librarian for use with COFF object modules created using either MPASM v2. 0, MPASMWIN v2. 0, or MPLAB-C v2. 0 or later. MPLIB manages the creation and modification of library files. A library file is a collection of object modules that are stored in a single file. Libraries make linking easier. Since library files can contain many object files, the name of a library file can be used instead of the names of many separate objects when linking. Libraries help keep code small.

Since a linker only uses the required object files contained in a library, not all object files which are contained in the library necessarily wind up in the linker’s output module. Libraries make projects more maintainable. If a library is included in a project, the addition or removal of calls to that library will not require a change to the link process. Libraries help convey the purpose of a group of object modules. Since libraries can group together several related object modules, the purpose of a library file is usually more understandable that the purpose of its individual object modules.

For example, the purpose of a file named “math. lib” is more apparent that the purpose of ‘power. o’, ‘ceiling. o’, and ‘floor. o’. MPLAB-SIM Simulator Software The software simulator is a no-cost tool with which to evaluate Microchip’s products and designs. The use of the simulator greatly helps debug software, particularly algorithms. Depending on the complexity of a design project a time/cost-benefit should be looked at comparing the simulator with an emulator.

For projects that have multiple engineers in the development, the simulator in conjunction with an emulator can keep costs down and will allow speedy debug of the tough problems. MPLAB-SIM Simulator simulates the PICmicro series microcontrollers on an instruction level. On any given instruction, the user may examine or modify any of the data areas or provide external stimulus to any of the pins. The input/output radix can be set by the user and the execution can be performed in; single step, execute until the break, or in a trace mode.

MPLAB-SIM supports symbolic debugging using MPLAB-C, and MPASM. The Software Simulator offers the low-cost flexibility to develop and debug code outside of the laboratory environment making it an excellent multi-project software development tool.