Selling my Soul?

I received my monthly activity report for dalescott.net traffic from Google today, a thought-provoking top-level summary provided at “no cost” (although some will say it’s already cost me my soul ;-)).

This is technology research for me. Big enterprise expends effort where a return is expected. I follow their lead looking for the concepts that will provide immediate value to smaller businesses, and that can be implemented at a fraction of the cost through participation in Open Source ecosystems. 

Start a Windows MPLAB X Project by Cloning a Git Repo

Microchip’s MPLAB X IDE includes a Git client for committing, pushing upstream, pulling downstream, etc, but not for cloning an existing project from a remote repository. In this post, I’ll show how to use the standard Git install for Windows from the Git project to clone a project from a remote repository, and then the basics for using MPLAB X’s built-in Git client for everything else.

I’ll be using MPLAB X on Windows. Although MAC OS X and Linux are also supported for MPLAB X, I don’t use OS X and I’ve been unable to use MPLAB X MCC (the MPLAB Code Configurator) on Linux.

Git GUI

The standard Git install for Windows from the Git project includes Git GUI, a basic Git client GUI app.

Download and install Git, then launch Git GUI.

and select Clone Existing Repository.

Clone the remote repository. In this example, I’m cloning from a Windows network drive.

You could also use the ssh protocol to clone from a remote server, in which case the source location will be something like the following (you will be prompted for your private ssh key passphrase after clicking Clone):

ssh://dalescott@dalescott.net/home/dalescott/sourceProject.X.git sourceProject

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

Open project in MPLAB X

Now you can open your cloned project in 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 aren’t available in 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, but standard practice is to first Pull from the upstream repo (e.g. origin) before you try pushing a local commit to the upstream repository. If someone has pushed code since your last pull (or clone), you’ll need to merge their changes into your local project first, then push the combined changes 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.