PIC16f1x vs PIC18f

[KM1]

Hello,

This forum is very refreshing - good content and respectful users!

I have a good amount of experience with PIC products, but not full-time day in and day out. My question is regarding the pros and cons of using the advanced versions of the PIC16f family vs the 18f family. I really like the analog peripherals amongst other features and I wonder what others think for new project development?

For example, I am looking at a redesign of a product that currently has been using the PIC16f887 for the last 5 years. I am looking at the PIC16f18877 as a replacement unit and have spent some time wading through the 600+(!) page data sheet looking for opportunities to simplify the original circuit design and take advantage of some of these features. I am not looking for a way to avoid reading the data sheet, just some other points of view.

Keith

[Orunmila]

Hi Keith,

Welcome to our forum! We aim to please 🙂

Short answer is that I think the pic16F18877 is an excellent choice to replace the 16F887. It can pretty much do everything the 887 can do better since it can go 50% faster, and has a lot more to offer like CLC’s, PPS on the pins and a host of other features.

Perhaps you can give us a little more detail on what you are aiming to do and how. Will you be using XC8 and using C for this and what are you looking for in terms of analog?

There are also a lot of interesting goto parts in the PIC18 family, in particular look at the 18FxxK42, it has interesting additional features like DMA and vectored interrupts which are not on the PIC16F1 parts. They also have more flash and RAM if that is what you need.

 

 

[N9WXU]

In general any PIC16Fxxx device such as the PIC16F887 can effectively be migrated into a PIC16F1xxxx design (such as the PIC16F18877) as that was a key objective of the F1 redesign.  Immediate advantages that you will see are more FLASH, more RAM and more peripherals.  Other advantages are very important but can be a little subtle unless you are an assembly programmer.  In C, these additional advantages tend to reveal themselves in code that is as fast and a little smaller than the same code on a PIC18.  These other advantages are a flat memory map across FLASH & RAM (at least for pointers), 2 FSR's (pointers) and more efficient banking.

The PIC16F1's have 31 banks to solve the problem of a 512byte RAM/SFR limit.  The new limit is 4K and there are a number of PIC16F1's that make that available.

The PIC18 also has a 4K RAM limit but its FLASH limit is 2MB.  There are no PIC18's with 2MB but there are many with more than 56KB (The PIC16F1 limit). The new PIC18FxxK42 family has lots of new features and more RAM but there are not very many of the new PIC18 CPU available yet.

Welcome aboard and we are very interested in what you are doing with your project.

[KM1]

My main goals with this project:

• replace the original asm code with maintainable C - I am using MPlab X and the v2 c compiler. I have the asm source code and will be working with it, but it is the product of many years of tweaking by an (older and very smart) engineer now retired.
• simplify the current board circuitry - one example is to eliminate an external AD converter and use the built in. I believe there is no need for special features provided by the existing converter (Texas Instruments TLC1543, 10-bit, serial output), I believe the converter has been in the design since before on-board AD was commonly available (mid to late 90's)? I think I can reduce my overall BOM cost by approximately 15-20%
• The PIC's main job is to read 5 channels of AD, perform some relatively simple math, provide data to the user via LEDs and 7 segment displays, and store some data for calculations. There is a serial interface to an optional device, calibration data stored in EEPROM, and a simple user interface.

Longer term, I hope to add wireless connectivity, an improved UI, and possibly combine the optional device with this one to market a combination unit which may have appeal.

I have looked at the 18fxxk42 family and will be getting some to try in addition to the 18877s I have just received.

Keith

[N9WXU]

Everything in your list of requirements looked pretty reasonable for the PIC16 until you said wireless.  For wireless, a lot depends upon the details.  Bluetooth, WiFi, Subgig, LoRa, etc will all require some kind of RF module.  Each RF module generally comes with a co-processor that handles the heavy lifting for the wireless protocol, however... Each wireless module will still have demands upon the host processor.  For example, the WINC1500 wifi driver on an ATMEGA4808 took around 10k.  After reviewing the driver, it would be possible to shrink the code quite a lot but it would be at the expense of supporting the code for the duration.

That is not to suggest that wirelesss is not appropriate for a PIC16, it is just that wireless often comes with additional expectations that are not immediately apparent.  Here are a few:

1) Security, most wireless applications require a secure and authenticated connection to the host.

2) phone interface, many wireless applications seem to be tied to iOS and Android.  This generally implies BLE4.2 but could mean wifi.

3) IoT.  Obviously wireless existed before the internet, most of the wireless customer discussions ended up being Internet of Things discussions.  This drove the security requirements.

4) Over the air update.  because security and wireless standards are moving fast, most customers end up requiring the ability to update the software to adapt with the times.  

When you start going through these requirements you can quickly find yourself in a 128k MCU and that will be a PIC18 or AVR in 8-bit land.  A reasonable rule of thumb with these kinds of applications is the PIC16/18 will require 2x the FLASH as an AVR for the same application.  The details on why this is true would be a future technical post.

[Orunmila]

I think you will be pretty happy with the PIC16F1xxxx for that kind of project. 

The main advantage of the K42 would be the additional RAM and FLASH. I totally agree with @N9WXU there - when you are adding wifi and communication protocols that counts for a lot and you may end up constrained if you are trying to do it all on the smaller PIC16. If that is the next step you may find yourself porting the code right after writing it, which is never a good timeline.

The K42 has up to 128KB of FLASH and 8KB of RAM while the PIC16 is capped at 56KB of FLASH and 4KB of RAM. Although it should be fairly straightforward to port the PIC16F18877 code to any K42 if it is written in C and if you use something like MCC to generate the hardware code for you. If you need help with that part please do give us a shout, we can definitely lend a hand with that part!

[KM1]

Thank you Orunmila and N9WXU. I appreciate you taking the time to answer my questions.

Keith