Legacy Firmware & Processor Modernization

Modernizing a 20-Year-Old Embedded System

A manufacturer running embedded control firmware that had been in production for two decades faced a familiar but urgent problem: the PIC18 microcontroller at the heart of their system was obsolete, the original CCS compiler was no longer viable, and the product needed a path forward. What began as a straightforward processor swap quickly became something more strategic, an opportunity to modernize the entire embedded architecture and build a foundation capable of supporting future enhancements such as Ethernet, IoT connectivity, and expanded processing capability for the next generation of the product.

The challenge wasn't just getting the code to compile on new hardware. It was preserving decades of proven, trusted behavior while rebuilding the system underneath it.

Customer: Industrial controls manufacturer with a long-production-run embedded platform requiring processor modernization and compiler migration

The DE Solution:

  • Architectural separation of application logic from processor-specific code, enabling platform-independent development from day one
  • Hardware abstraction layer design allowing the target processor to evolve from PIC18 to PIC32CM to ATSAMC21 with minimal application-layer impact
  • Legacy firmware analysis and selective porting, preserving behavior customers relied on and rewriting only what no longer held true on modern hardware
  • Software emulation of the Parallel Master Port (PMP) interface using GPIO, preserving the existing encoder hardware without redesign
  • Keypad scanning logic rebuilt as a periodic background service, eliminating timing dependencies tied to the original processor speed
  • AI-assisted development workflow integrated as an engineering tool, accelerating research, documentation review, and repetitive refactoring while maintaining engineering validation at every step

The DE Team Win:

  • Application layer required almost no modification across three processor platform changes during development
  • Decades of proven product behavior preserved through disciplined firmware analysis, not assumption-based rewrites
  • Encoder interface fully functional on new processor without any hardware changes to the existing board

Modern 32-bit architecture now in place, with a clear path to future enhancements including Ethernet and IoT connectivity

Our Process

Let’s Talk About Your Project

Fill out our form, and our New Project Team would be happy to meet online for 30 minutes to discuss your project and share our capabilities.

We use your information to learn more about your project and to send occasional emails with an easy opt-out (we're not fans of inbox clutter either). And your data stays private and unsold, as it should.


Frequently Asked Questions

What made this more than a standard firmware port?

The customer initially expected a compiler migration, moving existing PIC18 code from the CCS compiler to Microchip's XC8. As the project developed, they recognized an opportunity to move to a 32-bit architecture that could support future expansion. That decision changed the scope entirely. The objective became preserving the behavior of a system that had been running reliably for twenty years while rebuilding the foundation beneath it on modern hardware.

How did DE Design Works handle the risk of changing the processor platform mid-project?

The key architectural decision was separating the application logic from processor-specific code early in the project. By building the application layer as a processor-independent module, validated in a Visual Studio console environment before hardware was even selected, the team was able to change target processors three times during development with minimal impact on the application. Almost all changes were isolated to the hardware abstraction layer.

What happened when the new processor didn't have the same peripherals as the original?

The ATSAMC21 didn't include a Parallel Master Port peripheral equivalent to the one the original PIC18 used to communicate with the encoder devices. Rather than redesigning the encoder hardware, DE Design Works developed a software implementation that emulated the required PMP behavior using GPIO. The existing encoder hardware remained unchanged. From the application's perspective, the encoder interface continued behaving as it always had.

How was AI used in this project, and what were its limits?

AI tools including GitHub Copilot and NotebookLM were used as engineering accelerators, not substitutes for engineering judgment. They helped interpret twenty-year-old CCS compiler syntax, summarize component datasheets, and automate repetitive code restructuring. In one case, NotebookLM misread a pin truth table in an encoder datasheet and generated a command sequence that was off by a single bit. The original datasheet remained the source of truth. AI reduced the time required to understand the device, but engineering validation against the primary source was essential at every step.

What does this project demonstrate about legacy embedded system modernization?

Legacy code that has been running successfully for decades often contains engineering decisions that were never documented, they exist only in the behavior of the system. Rewriting working code because it looks dated introduces risk with little customer benefit. The right approach is to understand the existing behavior first, then rewrite only what genuinely no longer works on the new platform. The goal isn't modern code. The goal is reliable code that preserves what customers already trust.