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.)

 

 

PLM using Parts&Vendors

Parts&VendorsTM from Trilogy Design was the seminal PLM (Product Lifecycle Management) software in the late 90’s for small teams who needed to manage design and purchasing information. A spreadsheet approach can be perfectly adequate if you have only one BOM (Bill of Materials) and each part is sourced from only one supplier, but quickly loses effectiveness when planning or purchasing for product builds with the same part being used in multiple sub-assemblies, and it gets worse if a part is available from multiple sources. Parts&Vendors uses a database, which allows the same part to be referenced by as many assemblies as needed, or as many sources as needed.

Parts&Vendors was originally released for Windows 98SE, and provided a single point of truth for everything to do with product development (parts, BOMs, suppliers, purchasing, supporting documents, etc.) that could be accessed by anyone in the team. It even even included rudimentary inventory and build management. Parts&Vendors enabled teams to work more efficiently with more cooperation and less bureaucracy, and was affordable by the smallest businesses – only US$69/user if you didn’t need per-user login, creating purchase orders or an ECO workflow (and only slightly more if you did).

Parts&Vendors was discontinued in January 2014 when Trilogy-Design folded operations, essentially a casualty of insurmountable technical debt. Although no longer available for purchase, Parts&Vendors is the oldest software I use on a daily basis, and my gold standard for evaluating software PLM features for use by SMEs – both dedicated PLM software as well as general purpose ERP software.

Parts&Vendors Overview

Item Master Tab

Parts are accessed through the Item Master tab, and the list of parts can be sorted, filtered or searched as needed.

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 saved documents or a web page for reference.

Although it wasn’t formal document control with a submit/approve/check-in/check-out type workflow, the simple approach was adequate for a conscientious team.

Assemblies

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.

Purchasing

Parts can be easily ordered,

and an order can be left “open” to accumulate parts until it was decided to place the order, resulting in a purchase Purchase Order (PO). In some organizations the PO would be sent directly to the vendor, while in other organizations the PO would be sent internally as a “purchase request” to issue a “real” PO.

Purchasing could also be performed for a BOM, including any sub-assemblies, by selecting the top-level BOM and quantity, and generating a Purchase List,

and then generating Purchase Orders from the Purchase List.

Receiving

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.

Manufacturing

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. 

Customers

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. However, the limitations were acceptable given the it was never the intent of P&V to also be a first-class POS (Point Of Sale) or CRM (Customer Relationship Management) system. 

Security and User Permissions

Out-of-the-box, Parts&Vendors allowed anyone to do anything, which made setup easy and promoted user adoption. If more control was needed to prevent users from inadvertently causing trouble, user logins could be used and assigned to groups with assigned role-based permissions.

First, create a group with appropriate permissions.

Then create a user and assign to the appropriate group.

Conclusion

I hope you have enjoyed this limited look at Parts&Vendors. In my experience, it combined the features and ease of use needed for small teams to be efficient, without imposing overhead they are unable to support. The paradox of enterprise software is that you may need it once you are successful, but you won’t have the resources to use it until you are successful.

If you are using Parts&Vendors and need advise or help migrating to a new system, please contact me using the Contact form. Parts&Vendors includes built-in export capability that can be used if you are methodical, and there are also ways to access database data directly without using Microsoft AccessTM (JET database schema and user interface IDE) or if using a Unix-type operating system.

ERPNext Change Management

I followed a defect report through the ERPNext change management process to understand the process. Nice job guys!.

The issue had to do with the Service Provider Chapter member listings on erpnext.org. John Clarke, the chapter leader, created an issue in the erpnext project repo on Github using screenshots I made.

 

Next, 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.

Trusted and Transparent. Nice work! 

Product Lifecycle Management (PLM) using ERPNext

Search for other ERPNext-related posts

Product Lifecycle Management (PLM) involves managing everything about a product from cradle to grave – from design and new product introduction (NPI) to termination or end-of-life. PLM encompasses product management, engineering design, product-specific business and manufacturing processes, new product introduction (NPI), and product data management. A PLM system integrates people, parts, processes and issues, and provides a trustable and transparent infrastructure backbone for the business.

Enterprise Resource Management (ERP) is a superset of PLM. ERP was born from a manufacturing need, but a modern ERP today includes accounting and financials, sales, customer relationship management, human resource management, and other core business systems – including PLM. However, modern ERP systems have also become complicated and expensive, and a successful implementation often requires that the business more conform to the ERP than vice versa. A new type of ERP is emerging, called Postmodern ERP. Postmodern ERPs are designed from the ground up to be simple and flexible, more capable of modelling a business than imposing conformity, and available to organizations of even modest requirements or means.

ERPNext is a postmodern ERP system, and includes basic PLM functionality. Although not as feature-rich as a dedicated PLM might be, ERPNext is capable for many situations, it is also less complicated, already integrated, and a capable starting point to build on. Features of ERPNext related to PLM include:

  • Integrated data. Items (parts), purchase specifications, engineering design documents, revisions, projects, issues, etc. All information is conveniently managed in one consistent system.
  • Visible, trusted, change management with social notification.
  • Scaled according to number of users, number of items and complexity of product trees, supply chain complexity, etc.

This tutorial will follow the Aircraft Wireless product designed and manufactured by the fictional Swift Construction Company.

Goals

The goals of this tutorial are to:

  • Create child and parent items to model an assembly.
  • Identify item supplier information for purchasing, including purchase and OEM specifications.
  • Demonstrate a suitable change management process.

Future revisions of this post will expand on topics such as including anticipated purchase, process and labour costs for preliminary cosgt analysis, and defining appropriate work centers in the manufacturing process.

Definitions

Here are some terms defined in the context here.

  • CSV (Command Separated Value). CSV is a common text data interchange format, with data values separated by commas. E.g. ’12,”this is text, not a number”, 15.0′ might be one line from a CSV file (notice the text is quoted because of a contained comma). Although the acronym specifies the data element separator is a comma, other separator characters such as a tab or semi-colon are also often used.
  • ECO (Engineering Change Order). The name of a change management process often found in an engineering or manufacturing environment, which defines the process for making a change to an item, and thereby changing its revision level. Sometimes the ECO process is preceded by an Engineering Change Request (ECR) process in a two-phase ECR/ECO process.
  • OEM (Original Equipment Manufacturer). Items may be purchased from distributors, and there may be more than one distributor selling a particular OEM item. In this case, often it is the OEM item that is critical, not who it is purchased from.
  • Release. A release is a milestone in the development life-cycle of a top-level or child item, and is associated with a specific revision-level. A release provides a convenient point for synchronizing various project activities, including product features and capability, purchasing and manufacturing activities, press releases, pre-production and trade show demos, etc.
  • Revision Level. An item carries has a revision level, that can be used to reference the item, and its supporting documentation, as it existed at a particular point in time. An item, and its revision level, can be updated following a well-defined process.

Item Codes and Revision Levels

I will use an “8+2” format item code, with 8 digits to specify the unique item (aka part number), and 2 digits to specify the item’s revision level.

The following is the bill of materials for the custom inductor in the Aircraft Wireless.

20000001-00,"IND,830UH,AIRCRAFT WIRELESS"
|-- 90000001-00,"WIRE,MAGNET,38AWG,POLY"
|-- 90000002-00,"MAG,FERRITE ROD,1/4IN X 4IN,MATL=61"
\-- 90000003-00,"TAPE,ELECTRICAL,3/4"",BLUE,VINYL"

I will need to create the parts required for the SCC Aircraft Wireless Release-1 prototype .  To create a new item, access the Item List in ERPNext and click New.

If necessary, a new unit of measure (UOM) can be created on the fly for the unit an item is managed in and consumed by.

The unit of measure for the wire in the custom inductor (PN 90000001-00) is centimetres (cm), meaning the wire will be inventoried in cm and consumed by the cm. However, it will be purchased in the vendor’s unit of measure, which is a Spool. Both cm and Spool will need to be created as they are not already defined in ERPNext’s UOM List.

The purchase UOM for an item is specified in the Purchase Details section of the item master data.

Be aware that the default UOM also determintes the inventory stock quantity. Because the default UOM for the wire is centimeters, inventory will also be managed in centimeters. In an inventory audit, it will be necessary to convert from counted full spools to centimeters because the audit count will be in centimeters. Depending on the business, there are other out-of-box options which may work better in practise.

When the purchase UOM for an item is different from the item’s default UOM, the relationship or conversation factor must be specified in the Units of Measure section of the Item master data. In the case of the inductor wire, the conversion factor from spool to cm is 588,264 (the datasheet for the wire indicates a spool contains 19,300 feet of wire, and 19300 ft x 30.48 cm/ft  gives 588,264 cm/Spool).

Supplier details are also entered in the Item master data, including specifying the OEM and OEM part number if relevant.

An image can be associated with an item in the item master data for the convenience of users in recognising or understanding the item. Files and other documents that specify or support the item can also be attached, such as the supplier catalogue page, a preliminary supplier quotation, or engineering design documents.

Attach Supporting Documentation

If a document already uploaded pertains to multiple items, the already-uploaded document can be attached instead of uploading a new document. It is also possible to enter item master data by importing CSV format data. This would likely be the preferred method when implementing ERPNext for an established organization.

Create Bills of Materials

Child items of a parent are specified using a Bill of Materials (BOM), including child item quantities. ERPNext revisions BOMs independently from Items, and creates BOM-20000001-00-001 as the initial BOM for Item 20000001-00.

Managing Change

Using the revisioning strategy outlined here, revising a child item in ERPNext can be done by simply duplicating it and increase the revision level in the Item Code. The revision level of the child’s parent item may or may be changed, depending on the policies of the organization. Generally a change in fit, form, or function mandates at least a revision level change, if not a completely new item with new root item code. The revision level of the parent may not be required to change if the fit, form or function of the parent has not changed as a result of the child’s revision.

If the revision level of the parent is not required to change, the parent’s BOM can simply be updated with the new child revision level. ERPNext will create a new BOM revision level, but the revision level of the parent item is not affected. If the revision level of the parent does change, a new BOM will need to be created for the new revision level of the parent (and listing the child at its new revision level).

Organizations typically have an approval process for revising a product, often called an Engineering Change Order (ECO) process. An approval signature document is commonly used to capture approval from stakeholders, including product management, engineering, sales, manufacturing, quality and finance. The signed approval document can be attached to the related item or BOM in ERPNext.

Summary

This has been a short overview of PLM using ERPNext. Although ERPNext is not a dedicated PLM system, its out-of-box capabilities are more than adequate to support basic PLM operations. Should additional capabilities be necessary, they can be developed on the ERPNext platform itself, or dedicated PLM software (existing or custom developed) can be integrated with ERPNext.

Please leave a comment or use the contact form for more information.