Microchip PIC32CM5164LS60064 Handleiding

Microchip Niet gecategoriseerd PIC32CM5164LS60064

Lees hieronder de 📖 handleiding in het Nederlandse voor Microchip PIC32CM5164LS60064 (18 pagina's) in de categorie Niet gecategoriseerd. Deze handleiding was nuttig voor 49 personen en werd door 2 gebruikers gemiddeld met 4.5 sterren beoordeeld

Download PDF

Pagina 1/18

MPLAB® Harmony Help - MPLAB

Harmony Overview

MPLAB Harmony Integrated Software Framework v1.11

What is MPLAB Harmony?

This topic provides an overview of MPLAB Harmony.

Description

Microchip MPLAB® Harmony is the result of a holistic, aggregate approach to creating rmware solutions for embedded systems using Microchip

PIC32 microcontrollers. As shown in the following diagram, MPLAB Harmony consists of portable, modular and compatible libraries provided by

Microchip and third-party ecosystem partners. MPLAB Harmony also includes easy-to-use development utilities like the MPLAB Harmony

Congurator (MHC) plug-in for the MPLAB X IDE, which accelerate development of highly capable and reusable PIC32 embedded rmware

applications.

MPLAB® Harmony Block Diagram

Designed almost completely in the C language (see

Note), MPLAB Harmony takes key elements of modular and object-oriented design, adds in

the exibility to use a Real-Time Operating System (RTOS) or work without one if you prefer, and provides a framework of software modules that

are easy to use, congurable for your specic needs, and that work together in complete harmony.

Note: MPLAB Harmony has not been tested with C++; therefore, support for this programming language is not supported.

Portability

Portability is a concern that is often overlooked when a silicon manufacturer provides software. However, breadth of solutions is a hallmark

strength of Microchip, and MPLAB Harmony provides simple libraries to abstract away part-specic details and make a Microchip device easy to

use, regardless of which device you choose. Any time you design a new product or update an existing one, cost must be balanced with

capabilities; however, cost is more than just the bill of materials – it’s also the Non-Refundable Engineering (NRE) cost to design and develop your

solution. MPLAB Harmony provides peripheral libraries, device drivers, and other libraries that use clear and consistent interfaces, requiring little or

no change in your application code and minimizing the engineering time and eort for each new design.

Device Drivers

The primary purpose of a MPLAB Harmony device driver (or "driver") is to provide a simple and highly abstracted interface to a peripheral, allowing

your application (or any other module in the system) to interact with a peripheral through a consistent set of functions. A driver is responsible for

managing access to a peripheral, so that requests from dierent modules do not conict with each other, and for managing the state of that

peripheral so that it always operates correctly.

Peripheral Libraries

A Peripheral Library (PLIB) is a simple access library that provides a consistent (but very low level) interface to a peripheral that is "on board" the

MCU. PLIBs hide register details, making it easier to write drivers that support multiple microcontroller families, but they are not normally used by

applications directly to interact with peripherals, as they provide little abstraction, and because they require the caller to manage the detailed

operation of a peripheral (including preventing conicting requests from other modules). Because of the lack of conict protection in a PLIB, only

one module in a system should directly access the PLIB for a peripheral. Therefore, PLIBs are primarily used to implement device drivers (and

some system services) to make them portable.

What is MPLAB Harmony?

Modularity

MPLAB Harmony libraries are modular software "building blocks" that allow you to divide-and-conquer your rmware design. The interface to each

library consists of a highly cohesive set of functions (not globally accessible variables or shared registers), so that each module can manage its

own resources. If one module needs to use the resources of another module, it calls that module's interface functions to do so. Interfaces between

modules are kept simple with minimal inter-dependencies so that modules are loosely coupled to each other. This approach helps to eliminate

conicts between modules and allows them to be more easily used together like building blocks to create the solutions you need.

Middleware Libraries

The normal usage models of some of the more complex peripherals, (i.e., USB or network interfaces) require interpreting complex protocols or

may require substantial additional processing to produce useable results, such as drawing graphical images on an LCD screen with an LCD

controller peripheral. Therefore, while a device driver may be completely sucient for a simple peripheral like a UART, some peripherals require

what is frequently called "middleware" (aptly named because it sits between your application and the hardware abstraction layer or "driver" layer). _ _

MPLAB Harmony provides several middleware library "stacks" to manage these more complex peripherals and provide the functionality you need

and expect.

MPLAB Harmony middleware "stacks" are usually built upon device drivers and system services so that they can be supported on any Microchip

microcontroller for which the required driver or service is supported. However, special purpose implementations may be available that integrate the

driver, certain services, and various modules within the "stack" for eciency.

System Services

MPLAB Harmony system services are responsible for managing shared resources so that other modules, such as drivers, middleware, and

applications, do not conict on shared resources. For example, if the TCP/IP, USB, and Graphics stacks attempted to concurrently use the Timer2

peripheral to perform some periodic task, they would very likely interfere with each other. However, if instead they used a timer system service (as

the following image illustrates), it is the responsibility of the system service to keep the separate requests from interfering with each other. The

timer service can be congured as desired for a specic system (for example, you may decide to use Timer3 instead of Timer2) isolating the

necessary changes to the conguration of a single module and preventing potential conicts.

The use of a system service is very similar the use of a device driver, except that a driver normally requires the caller to "open" it to create a

unique client-to-driver association. A system service does not normally require the caller to open the service before using it because system

services are frequently shared by many clients within the system.

Compatibility

MPLAB Harmony modules (drivers, system services, and middleware – excluding PLIBs) are "active". This means when an application calls a

module's interface function, the call will usually return immediately (unless a RTOS is in use) and the module will continue working on its own to

complete the operation. Most modules will then provide a notication mechanism so the caller (i.e., client) can determine when the operation has

nished.

Most MPLAB Harmony modules are implemented as cooperative state machines. The following image shows the basic idea of how this works.

Each module has an "Initialize" function and each module has one (or more) "Tasks" function(s) to maintain its state machine(s). The state

machines of all modules are initialized, shortly after the system comes out of reset in "main". After that (in a polled conguration, with no OS), the