Migrating to a newer device . . .

When a design and a system works, especially an embedded one, there is a high degree of reluctance to migrate or change to a new device. Standalone and single-purpose systems incur a level of resources, changing anything in the design can negatively affect the project workings.

On the upside, changing the micro controlling system functions may be at the demand of necessary advantages. Advances in device features, silicon manufacturing technology, and stock availability may induce strong reason especially if it saves money. In embedded design, every resource counts from a single memory address to an I/O pin. Extrapolated across a production run, small elements have major consequences.

A recent project feasibility study for a solar-powered charger revealed this comparing the PIC16F785 vs the newer PIC16F1709 there was, to begin with, a price point disparity of approximately ~R7 / device. Given the cost-sensitive nature of the project, the reduced cost in using what is effectively a drop-in replacement, the decision was taken to migrate the design.

For a feature, side by side comparison you can view the two devices on Microchip's website

• PIC16F785: https://www.microchip.com/wwwproducts/en/PIC16F785
• PIC16F1709: https://www.microchip.com/wwwproducts/en/PIC16F1709
• The key points for us were 1) Lower cost, 2) better program memory and working registers, 3) A UART as a way to introduce a user interface
• Our toolchain is the MikroC Pro Compiler, with MikroE's proprietary programmer.

Migrating Code

While I will not go into all of the design specifics, for IP's sake I will discuss one element of the migration that has been tricky. Since the PIC16F1709 has additional ie more features packed in the same footprint, peripherals are multiplexed on the same PINS. The PIC16F1709 also has remappable pins. Remappable being those pins that can be redirected from a default to a designated pin.

As with most PICs, the first step would be to 1) Disable the analogs, 2) Switch of the comparators, and then configure the PWM outs. We are using the PWMs to drive the LED lights which are draw power from the battery.

While the remappable pin library is well documented in the Mikroe help file, we did run into a snag where since version 7.2 there were known issues with the remappable library, which can be viewed here Mikroe Forum.

While this may have seemed like a serious issue with the decision to migrate the device, a quick email to the Mikroe support desk resulted in a new library for the remappable PWM being supplied and a code sample that got the problems solved and us back on track.

Remappable Libray

This was my first project using a device with this feature and it requires that it be enabled the in Library manager and referred to in the code. Seeing as we are using both the PWM outputs, both were declared.

PPS_Mapping_NoLock(_RC4, _OUTPUT, _CCP1);

PPS_Mapping_NoLock(_RC5, _OUTPUT, _CCP2);

And then configuring the device requires that it's referred to as remappable:

PWM1_Remappable_Init(5000);

PWM1_Remappable_Start();

PWM1_Remappable_Set_Duty(startDuty);

The code is available in the Mikroe Forum if you want to obtain a copy.

Conclusion

While initially there was some apprehension to move to the newer device, the outcome has shown that working with the various industry stakeholders does enable easy device migration. In other words, if you do hit a snag don't panic look for the help that you need.

It is still early stages, however, the migration has not been too hectic and it's subsequently evident that we have made a good decision.

#microchip #mikroe