Microchip PIC24F Development using MLA, EZBL, Git and Dropbox – Part 1

I recently started working with a client on the final stages of a new product development project. The hardware design is based on a Microchip PIC24FJ1024GB610 microcontroller and firmware is being developed on a Microchip Explorer 16/32 development system until prototype hardware is fully tested. I have been working almost exclusively recently with the TI MSP432, and it’s been great fun familiarizing myself with Microchip’s 16-bit development environment. 

Tutorials and demo applications are great sources of information, but are often from the perspective of a single developer, and brush over details such as source traceability and effective team development – often important within an enterprise to reduce risk and expedite time-to-market.

In this new series of blog posts, I will explore using the Microchip Library for Applications (MLA) as the basis of a new project, managing source files in a version control system (Git), sharing a source repository amongst a team using Dropbox, and finally integrating an application with the Microchip Easy Bootloader (EZBL). 

Development Environment Summary

  • Windows 10 development workstation
  • GitExtensions 2.50.02
  • MPLAB v4.05 (necessary at this time to use Easy Bootloader)
  • MLA v2017_03_06
  • Microchip Explorer 16/32 development board with PIC24FJ1024GB610 PIM
  • MikroElektronika microSD click (mikroBUS™ microSD Card module)

Create new MPLABX project

Microchip provides the MLA (Microchip Library for Applications) which includes demo applications which can be used as the basis of a new project. Two important components of the new instrument’s functionality is to present an internal SD Card to a USB host as a Mass Storage Device (MSD), and to support in-field firmware updating.

Based on this functionality, it was appropriate to start with the MLA msd_sd_card_reader demo app, and integrate EZBL after getting the demo code running on the Explorer 16/32 development system, .

Unfortunately the MLA does not include a specific app for the Explorer 16/32 and PIC24FJ1024GB610, so I will have to adapt the Explorer 16 demo app for the PIC24FJ256GB210.

Copy the selected demo app to the ~\MPLABXProjects directory and rename it to something meaningful.

The project directory includes sources files and MPLABX project meta-data.

Now that there are files in the project it’s time to put it under version control. I will use Git for the project source file version control system (VCS), and have installed GitExtensions which integrates with Windows Explorer. MPLABX includes a built-in Git client which can be convenient but is less featured than GitExtensions. I’ll try to show the MPLABX Git client in a future post.

Start by using GitExtensions to create a working Git repo from the project directory.

Create a suitable .gitignore file so that Git will ignore files we don’t need to keep in the repo (generally the intermediate and debug compiler output). MPLABX  project meta-data will be kept in the repo though, as it includes specifying which files the compiler is to use, the include path settings, the target processor, etc. The new project files are then committed to the repo.

The project won’t build yet though because I haven’t copied the MLA support files into the project yet. I’m going to simply copy the MLA framework\ and bsp\ directories into the project. Even though I likely won’ t need all the files, it’s convenient to have a complete and consistent MLA in the project as it will simplify use and maintenance.

The source file directories in the project properties must be configured for the new MLA location within the project directory structure.

The build configuration must also be updated. I created a new configuration by copying the existing build configuration, and renaming it according my target processor and set the new configuration active.  

I also set the target Device to the PIC24FJ1024GB610, and picked the Explorer 16/32 development system in Hardware Tools.

I had hoped the project would build at this point, but at least not complain about missing files. This was not the case. Performing Clean and Build Project produced a torrent of missing files.

Investigating, I first found the build configuration includes specifying the “C include dirs” for the xc16-gcc compiler pre-processor, seemingly duplicating the project Source Directories. I made the preprocessing include directories the same as the Project Properties Source Folders set earlier.

I then noticed that files reported missing in the build output were not shown with a “!” in the project navigator, and they also didn’t have the expected “H” or “C” in their file icon. 

I don’t understand why the files they weren’t found since I had corrected the include file settings. I had thought path settings were all relative to the project directory, but for some reason MPLABX expects the framework directory to be in the root of the drive, instead of the root of the project. Not sure what else to do, I individually removed each include and source file and then used “Add existing item” to re-add each file.

The project still doesn’t build, but now there are no errors due to missing files.

Now that all the files are found, I will commit the updated project to the Git repo.

In upcoming posts, I will fix the undeclared symbol errors, push my local dev repo to a Dropbox repo to share with others, and finally integrate the demo app with the Microchip Easy Bootloader.

For Followup

The correct use of include directory settings is still not clear to me. Manually removing and re-adding each source file would be extremely laborious and error prone in a significant project, and I am concerned I may have made the project non-portable in the process.

There is a note in the Getting Started document for the Microchip Libraries for Applications on this topic, which I need to explore in the future. Point 1 seems to imply though that at least the framework directory must be in the same location on each development system.

Project Include Path Settings

1. Path to the framework folder: In order for the projects to build, the include path up to the framework folder should be
provided for each build configuration and must be placed in the “Includes directories” list in the compiler properties for the
project. The framework module header files expect this. It is already done for the examples provided with MLA, but for the
customer specific project, this needs to be done.

2. Path to system_config.h: For each build configuration, the path to system_config.h needs to be provided.

3. Path to the application project src folder: The hardware independent code resides in the src folder for the application.
The path to the src folder needs to be provided for each build configuration.

For a project to be portable from one machine to another, it is recommended that the paths in the MPLAB X are relative,
while adding files to MPLAB X and while specifying include paths.

(Getting Started, Microchip Libraries for Applications. (c) 2013 Microchip. help_mla_getting_started.pdf, page 11.)



ERPNext vs Parts&Vendors Part 1

In the late 90’s, Parts&VendorsTM (PV) was the seminal multi-user application for embedded-electronics design teams to manage the parts and assemblies used in their various projects. It was a Windows desktop application and managed everything to do with an embedded-type product, including parts, vendors, manufacturers, purchasing, supporting documents, and even included rudimentary stock control to support small-volume manufacturing.

After almost 15 years on top, PV was discontinued January 2014. From the perspective of an outside observer, PV failed by not staying relevant and by creating an insurmountable technical debt. User teams were working more cooperatively with less authoritarian overhead, but the PV database did not suffer clients crashing or WAN latencies gracefully. Eventually best practices for Windows app development moved on and the effort to update PV became insurmountable.

Today, PV is still a standard that others can be compared to, especially ERPNext – a new web-based fully-featured open-source ERP system that is getting considerable well-deserved attention. However, before comparing PV to ERPNext, we need to first review some basic PV functionality.

Parts&Vendors UX / UI 

Item Master Tab

Parts are accessed through the Item Master tab.

Item Details

Selecting a part provides detailed information on sources (vendors) as well as other useful information.

Files and URLs

Documents and web sites can be associated with a part,

making it easy to access local documents or a web page for reference.

Unfortunately PV did not include a document control user interface to keep things in order, or utilities to verify document paths or list parts referencing a particular file. The shared directory approach worked well for a small conscientious team, or one with a dedicated “librarian”, but not with a more “entrepreneurial” team (if you know what I mean <wink>).


A part may be grouped with others in an Assembly. You can easily tell what assemblies include a particular part in PV from the part’s Used On tab. 

It’s also easy to navigate from a part to a containing assembly, and back. This is also called traversing a product tree containing child parts and parent parts.

An assembly has a Parts List (aka Bill-of-Materials or BOM) that lists its child parts.


Parts can be easily ordered,

An order can accumulate parts until it is placed with a vendor, eventually resulting in a purchase Purchase Order (PO).

In a smaller organization, the engineering team often does the ordering themselves. In a larger organization, a “real” purchase order may need to be created in a separate parallel system (e.g. QuickBooks). The exact process will depend on an organization’s size, structure, and history.


When the ordered parts arrive, the PO is retrieved and the order item marked received, 

which updates the stock on hand.

The assembly Parts List is one way to see when the parts necessary to build an assembly are in stock.


Once all the child parts for an assembly are in stock, a “Kit List” is generated from the “Build” tab for manufacturing. Stock on hand can be reduced for the kitted items, and later increased for the finished assembly when completed. 


PV can also manage clients and client orders, although the functionality is not integrated with stock control and closing an order does not reduce quantity on hand of the ordered items. The functionality is understandable though given it was never a goal of PV to be a POS (Point Of Sale) or CRM (Customer Relationship Management) system. 


This completes a quick refresher of Parts&Vendors. In the next post I will compare ERPNext to Parts&Vendors.

ERPNext Change Management

I found a small issue in the behavior of the Service Provider listings on the erpnext.org website. Not a big deal, but worth correcting. I was also interested in understanding the process first hand from issue report to fixed code.

I had first noticed the number of members shown in the Calgary Chapter short description wasn’t the same as the number of members listed on the detail page. I suspected I was the cause, having just joined the chapter and then left, while investigating a separate problem with my profile 

The summary view shows two members in the Calgary Chapter, but there are three listings on the detailed page.

My colleague John Clarke (founder of the ERPNext Foundation Calgary Chapter) created an issue in the erpnext project repo on Github with my screenshots attached for explanation.


Back at ERPNext headquarters in Mumbai, a developer named Vishdha assigned the issue to himself. He also left a record showing the incorrect data had been removed from the production site database.

Nabinhait, a senior developer, added the issue to the January 2018 milestone (implying a monthly cadence to releases). Vishadh found the issue had been corrected in a pull request he issued two weeks ago (but obviously not yet pushed to the production site). Leaving a trail for others to follow, Vishadh added a reference to the issue in the pull request, and cross-referenced the pull request in the issue.

Following trail from the issue to Vishdha’s Pull Request, the pull request is comprised of changes to 7 files in four individual commits.

Reviewing the individual commits,

we can drill down one final level to see the actual changes Vishdha made in each file. 

However, although a fix was committed to the erpnext code repository two weeks ago, it’s clearly not yet on the foundation server (erpnext.org).

Vishdha wasn’t finished yet though and submitted a pull request to add the fix to the non_profit domain, which was subsequently merged into master by nabinhait which then officially closed the issue.

Transparent and trusted. What more could you want?