Learn About MPLAB® Code Configurator (MCC) Melody Components Using Content Manager (CM)

Introduction

MPLAB^® Code Configurator (MCC) Melody code structure is based on an embedded software architecture. By creating embedded software using an architecture based on libraries, drivers, peripheral libraries, hardware initializers, and system resources, you are essentially adopting a modular and layered approach. These layers are called components in MCC Melody. This method is common in modern embedded development, where software layers are abstracted to improve reusability, maintainability, and scalability.

Embedded software architecture can be organized into several layers, each differing in abstraction and portability. As you move up from the system layer to the application layer, both abstraction and portability increase. Many of these architecture hierarchies can exist within a single application, each controlling one aspect of its functionality. Additionally, each function may utilize all or some of these layers. For example, a graphic display may employ an architecture using all layers, and an LED indicator may only use the peripheral library and peripheral initializer layers.

Components

Let’s review each component (layer) in MPLAB X IDE and MCC Melody Content Manager:

Application

At the top is the Application component, which contains user-defined logic and is highly abstracted and portable, as it interacts mainly with standardized Application Programming Interfaces (APIs). An example would be an MPLAB X IDE project.

Libraries

Below this, the Library component provides reusable code modules or functions, offering a high level of abstraction and good portability if designed independently of hardware. There are many examples, some include Data Stream Driver, Electrically Erasable Programmable Read-Only Memory (EEPROM), and Ethernet Drivers. These are found in MCC Melody’s Content Manager:

MCC > Project Resources > Content Manager > Device Resources > Content Manager > Content Libraries > Libraries

Drivers

The Driver component interfaces directly with hardware devices, offering low abstraction and limited portability since drivers are typically hardware-specific. These drivers select the peripheral required for the task, but not the instance of the peripheral. This is the lowest component layer that can be abstracted to different peripherals. There are lots of examples of drivers, some include Analog-to-Digital Converter (ADC), Enhanced Capture/Compare/PWM (ECCP), and Universal Asynchronous Receiver/Transmitter (UART) drivers. The full list can be found in MCC Melody’s Content Manager:

MCC > Project Resources > Content Manager > Device Resources > Content Manager > Content Libraries > Drivers

Peripheral Libraries (PLIBs)

The Peripheral Library component supplies standardized functions to control hardware peripherals, providing a moderate abstraction level but no assured portability across similar hardware families. The peripheral instance is specified at this component layer. Therefore, this is the highest component layer that may not be portable to different microcontrollers. Examples include TMR1, UART2, and Master Synchronous Serial Port (MSSP) (if device has only one MSSP). Here’s where they are in Content Manager:

MCC > Project Resources > Content Manager > Device Resources > Content Manager > Content Libraries > PLIB

Hardware Peripheral Initializers

The Peripheral Initializer component is responsible for configuring and initializing hardware peripherals, with low abstraction and minimal portability due to its close ties to specific hardware. One example of the Hardware Peripheral Initializer can be found here:

MCC > Project Resources > Content Manager > Device Resources > Content Manager > Content Libraries > Hardware Peripherals

System Drivers

At the base, the System component manages core system functions such as startup, clock configuration, and interrupt handling, offering the lowest abstraction and portability, as it is tightly coupled to the hardware platform. Some examples include Clock Control, Configuration Bits, Interrupt Manager, and Pins Driver. They are listed under the System Components list:

MCC > Project Resources > Content Manager > Device Resources > Content Manager > Content Libraries > System

Back to Top

Advantages

Here are the main advantages of using an embedded software architecture:

1. Modularity and reusability

   Libraries and drivers encapsulate specific functionalities (e.g., communication protocols, sensor interfaces), making it easier to reuse code across different projects or hardware platforms. Peripheral libraries provide standardized interfaces to hardware peripherals, reducing the need to write low-level code from scratch.

2. Simplified development

   Hardware initializers and system resource managers abstract complex hardware setups, allowing developers to focus on application logic rather than hardware details. Using well-tested libraries and drivers can reduce development time and lower the risk of bugs.

3. Maintainability

   Modular code is easier to update and maintain. If a bug is found in a driver or library, it can be fixed in one place and reused everywhere. System resources (like memory management and task scheduling) are often handled by dedicated modules, improving code organization.

4. Portability

   Abstracting hardware access through drivers and libraries makes it easier to port software to new hardware platforms by swapping out only the hardware-specific layers.

5. Scalability

   New features or hardware support can be added by integrating new libraries or drivers without major changes to the application code.

   Back to Top

Disadvantages

Here are the disadvantages of using an embedded software architecture:

1. Increased overhead

   Abstraction layers (libraries, drivers) can introduce performance overhead, which may be critical in resource-constrained systems. More code and indirection can lead to increased memory usage.

2. Complexity in integration

   Integrating multiple libraries and drivers from different sources can lead to compatibility issues, version conflicts, or unexpected interactions. Debugging issues that span multiple layers can be more challenging.

3. Limited optimization

   Generic libraries and drivers may not be as optimized for specific hardware as custom, hand-written code, potentially leading to suboptimal performance.

4. Dependency management

   Relying on third-party or vendor-supplied libraries can create dependencies that may be difficult to manage, especially if updates or bug fixes are needed.

5. Potential for bloat

   Including unused features from comprehensive libraries can lead to code bloat, increasing the size of the final binary and possibly exceeding memory constraints

   Back to Top

Summary

Using an embedded software architecture based on libraries, drivers, peripheral libraries, hardware initializers, and system resources offers significant benefits in terms of modularity, maintainability, and portability. However, it can introduce performance overhead, integration complexity, and dependency management challenges, which must be carefully managed in resource-constrained embedded environments. MCC Melody leverages the benefits of this architecture using easy graphics interfaces to simplify embedded software development.

Back to Top

Learn More

• Managing MPLAB Code Configurator (MCC) Melody Component Versions
• MPLAB Code Configurator (MCC) Melody Content Manager Introduction
• Microchip Plugins Available in MPLAB® X IDE

Back to Top