Start an MPLAB X Project by Cloning a Git Repo

MPLAB X includes great built-in support for Git but it assumes projects are created first from within MPLAB X (File > New Project ) before managing them using Git. If you’re starting by cloning a remote repo, the simplest way is using a stand-alone Git client.

Everyone has their own favorite Git client, but in order to keep things simple for the team we’ll use the standard Git install for Windows from the Git project to clone the remote repo, and use MPLAB X’s built-in Git features for everything else.

The Git install includes Git GUI, a GUI applet for creating and cloning repositories, and a command line terminal for everything else. However we won’t have to worry about learning command line Git operation as we will be using the Git features in MPLAB X for day-to-day use.

Start the Git GUI applet,

and select Clone Existing Repository.

Clone the remote master repository locally (the master repo for me is on a Windows network drive).

When the remote repo has been cloned, Git GUI will show the current status of the new local repository – which should show no modified files (i.e. no files either staged or unstaged).

To confirm the repository was cloned correctly, you can check the commit history by accessing menu Repository > Visualize master’s History.

Now we can open the cloned local repo using MPLAB X.

Git is primarily accessed using a project’s context menu from the Project window.

However, be aware there are a few Git commands under the Team menu, including a Repository Browser that isn’t available from the project context menu.

Try accessing Show History for the project (you will need to click “Search” in the Show History view that opens).

Now I’ll ready to start hacking on the source. I’ll keep it simple and just add some TODO’s to the README.txt file. Notice how the editor shows my changes compared to the last commit in real-time!

When I’m ready to commit my changes, I can commit just the modified README.txt file,

or I can commit all modified files in the project.

To push a local commit back to the upstream origin repo, use the general-purpose Remote > Push… selection from the Project context menu.



Origin is the only remote repo configured in the local clone, so it should be indicated automatically in the Push to Remote Repository wizard.

There, all done! Wasn’t that easy?

I didn’t do show it here, but standard practice is to always Pull from the upstream repo (e.g. origin) before you try pushing code. If someone has pushed code to the master repo since your last pull (or clone), you’ll need to merge their changes from the master repo into your local repo first, then push your combined changes back to the upstream repo.

Why is Embedded Product Development Different?

Effective embedded product development involves coordinating a large number of tasks in complex relationships, managing risk and dealing with issues that arise due to uncertainty. Development teams are multi-disciplinary and can involve industrial and user experience design, mechanical design, electronics design, embedded, desktop, mobile and cloud software development, product verification and validation testing, and manufacturing process development, each with its own unique processes and workflows. Put simply, the effort needed to bring a complex high-tech networked embedded product to the world should not be underestimated.

Regulatory requirements must be met before a product can be placed for sale, including meeting electrical emission and compliance regulations, safety related requirements that may impose specific product requirements or following specific development processes, and environmental requirements affecting component selection and recycling of packaging and eventually the product itself. Managing regulatory requirements and demonstrating compliance is a critical part of the development process. 

Software development today commonly includes a wide variety of open-source software components, such as operating systems, device drivers, database systems, data encryption, and network communication stacks. Each software component is licensed by its creator, and imposing specific requirements on use. In addition, use of encryption technologies is usually subject to national security regulations. Managing this complex interrelationship of requirements requires careful attention to ensure the final software application will be free of undesired encumbrances and can be distributed legally.

Development of a high-tech product can be a complex undertaking, involving a complex relationship of simultaneous tasks. To be effective, an engineering project manager must not only have related technical experience, but must also provide a suitable balance between attention to detail and time to market, without allowing unacceptable risk or sacrificing quality.

PLM and NPI

Product Lifecycle Management (PLM) describes how a product is consciously managed from concept through design, into manufacturing and sales, and eventually to retirement. PLM includes aspects of Product Management and also Sustaining (aka Maintenance) Engineering to add features, eliminate defects, optimise process, increase quality, etc. PLM integrates people, data, processes and business systems, and provides trust-able and transparent design and manufacturing data. 

New Product Introduction (NPI) is that portion of PLM involved with the hand-over from engineering design to manufacturing and eventually introducing a product into the market for sale. NPI is a broad topic, and depending on the organization, industry and product, may include Design for Manufacturability, Pilot Production, and Validation Testing, as well as creation of marketing and sales materials, managing sales campaigns and events, developing eCommerce and service subscription processes, and whatever else can be involved in bring a product to market. 

Embedded vs Cloud vs IoT

What is an embedded or embedded-system product, you ask? What is Cloud Computing, and what does it mean when an app is in the cloud? And how is the IoT (Internet of Things) involved? In this post I’ll review some of the basics involved.

Embedded Systems

An Embedded System is a computing device that the user doesn’t really know or care is a computing device, such as a smart phone or tablet device, an HVAC monitoring and control system or a GPS-based vehicle navigation system. Developing an embedded system often involves a highly technical cross-functional team, involving product conceptualization and user experience (UX), low-power analog, digital and RF electronics design and regulatory compliance testing, and complex embedded firmware with a unix-like operating system and variety of network protocols.

Cloud Computing

Cloud Computing just means “not on my computer”. If it happens in the cloud, it’s happening on a computer somewhere, just not on yours. A web site is “in the cloud”, but is still just software running on a computing system somewhere. The technologies involved vary wildly depending on the application and the implementation strategy, but often involves a mix of unix system administration, web application development and database design and administration.

Internet of Things

The Internet of Things (IoT) is a nice marketing story with devices everywhere communicating with cloud-based services that together make the world a better place. However the success of products will depend on solving real problems for real people. Sensors will need to function in real-world conditions involving extremes in temperature, moisture and mechanical stress. The real world also has varying degrees of fault-tolerance and criticality (how likely a failure is, and what is the effort of the failure).

I hope that clarifies a bit the new wild west of interconnected networked products. Please leave a comment or question if you like.

New ERPNext v11 Update

Congratulations to the ERPNext team and entire community on the latest v11 update. I’m eager to upgrade the Swift Construction Company demo site to check it out.

Open source software does not come without cost, but so does making do with an antiquated proprietary ERP, using fragile workarounds for modules that couldn’t be included in the license, and needing to use multiple systems due to non-integrated workflows. The question is which cost will return the greatest benefit.