Microchip Launches New Family Of PICs

Over the last few years, we’ve seen projects and products slowly move from 8-bit microcontrollers to more powerful ARM microcontrollers. The reason for this is simple — if you want to do more stuff, like an Internet-connected toaster, you need more bits, more Flash, and more processing power. This doesn’t mean 8-bit microcontrollers are dead, though. Eight bit micros are still going strong, and this week Microchip announced their latest family of 8-bit microcontrollers.

The PIC16F15386 family of microcontrollers is Microchip’s latest addition to their portfolio of 8-bit chips. This family of microcontrollers is Microchip’s ‘everything and the kitchen sink’ 8-bit offering. Other families of PICs have included features such as a complementary waveform generator, numerically controlled oscillator, a configurable logic controller, power saving functionality and the extreme low power features, but never before in one piece of silicon.

This feature-packed 8-bit includes a few new tricks not seen before in previous Microchip offerings. Of note are power management features (IDLE and DOZE modes), and a Device Information Area on the chip that contains factory-calibrated data (ADC voltage calibration and a fixed voltage reference) and an ID unique to each individual chip.

As you would expect from a new family of PICs, the 16F15386 is compatible with the MPLAB Xpress IDE and the MPLAB Code Configurator, a graphical programming environment. The products in the family range from 8-pin packages (including DIP!) with 3.5kB of program Flash to 48-pin QFPs with 28kB of program Flash. The goal for Microchip is to provide a wide offering, allowing designers to expand their builds without having to change microcontroller families.

All of these chips can be sampled now, although the lower pin count devices won’t be available through normal means until next month.

102 thoughts on “Microchip Launches New Family Of PICs

    1. Good for light fast semi closed control loops and pooling sensors. I was making some actuated artificial skin a while back. A dozen little 8 bit micros grabbing data and feeding back in a closed look, with a little extra to command a response, overlayed on top of it loop.

    2. Sure, the guys from microchip like Steve Sanghi Microchip’s CEO, their counselors and the hole marketing team is wrong about the microcontroller market. You may prefer to put a fancy arm in a 8 pin soic on your led dimmer, but the market may think the opposite.

      The rule of thumb here is simple and clear? Hey engineers, what would you prefer? A poor peripheral ARM or a rich 8 bit micro full of stuffs to play around?

          1. Now _that’s_ the crux of the matter!
            This little black duck switched to the GNU toolchain a quarter of a century ago, and has used it on Motorola 68k, PowerPC, NEC 850, Atmel AVR, etc. and never had to unbox and untangle a proprietary compiler since. The effort of building a cross toolchain on Linux was never a really big deal, and if you’re not busting for the latest version, then an effortless apt-get invocation is all it takes to be on the air with the new CPU, using familiar tools. Instant productivity, and not a cent to outlay on OS or tools.

            Having not seen PIC in GCC “Supported targets”, I’ve never been motivated to discover what a PIC is when it’s not “Position Independent Code”.

            But for anyone happy with other toolchains, the PIC might be a fine choice. I have no way of knowing.

      1. I want FAST (1 instruction per cycle – OK, I can live with two, wink) 8-bitters with NO added cost for peripherals (I’ll add my own). Bit-width doesn’t drive me for small state-machine/consumer products, etc. But the thing must be timer/counter rich and the native tool-chain MUST be zero-cloud, cross-platform, reasonably priced (no annual hooks/fees), non-BLOATED (yeah hat keeps me away from CPLD’s) and Not-Crippled (note I didn’t specify “Free” or “Open-Source” I’m willing to pay a bit). A bonus would be parts based on the “core” minimal part with some on-die peripherals. But that’s icing on the cake as far as I’m concerned. Low power is a plus, but we’re already there functionally these days.

    3. pic12F509 (8 pin) can do more that you can image, my poor-boy-unable-to-see-beyoud-his-nose. now better go back to click “like” on facebook using your iphone7…. here we have to work. go.

    4. Agreed. Compare a STM32F031 with a PIC12F509 for example. Not too much difference in cost, but 32-bit, 32KB flash, 4KB ram, 20 I/O versus 8-bit, 1.5KB Flash, 41 bytes ram, 5 I/O. Not much of a contest.

          1. Just nitpicking – power down current is 2,4uA maximal at 5V (1,2 at 2V, with typical currents one order of magnitude lower), for this device, designed as FLASH replacement for PIC12C508 OTP, 1990’s part. All of this assuming temperatures up to 85 deg C. The 9uA figure is for 125 deg C, which is unspecified for STM part.

          2. Read the datasheet better.

            1) Standby for the ARM is *power down* – it shuts off the entire core voltage, so the processor essentially resets. Standby for the PIC wakes up after an input pin change or WDT timeout. The equivalent under the ARM is “Stop” mode, which is much higher, 41 uA.

            2) “Max” is Microchip being panicky. Typical is 0.1 uA for the PIC vs. 5.5 uA for the ARM.

          3. @jaromirs: At 125C, chances are that you won’t be looking at using AA battery. That temperature range is for simple parts like MOSFET/Diodes for extended industrial temperature or automotive range. For reliability, it is recommended to keep junction temperature for chips below 105C.

            The shelf life of alkaline batteries are typically not specified for >40C as they don’t last long. They do specify NiMH for up to 60C. So this whole battery operation operation above 60C is moot.

            Reference: data.energizer.com/pdfs/temperat.pdf

      1. I agree. And in fact I prefer the STM architecture to that of the pic nine out of 10 days of the week. (I have a 10 day week) but every now and then it’s really nice when you can pick up a part and the data sheet is less than 100 pages and you can do the whole project in assembly that reminds you of your carefree days of the 90s…

  1. I gave up on the 8 bit PICs back when the only reasonable compiler was the CCS one and I got tired of paying for support or buying a new compiler any time microchip added a new part.
    I see that Microchip now offers their own C compiler, but I can’t seem to find pricing information on their website. Anyone know if there is a free or reasonably priced version for home use?
    In general, the AVR and its free tools have worked out well for me, but it did seem easier to set up the on chip features of the PIC.

    1. Their MPLabX and XC compilers are free and cross platform. You can upgrade the XC compilers to a paid version which offers more optimizations if you want/need, but getting started is free.

        1. Yes,thats another option. I was probably more important back in the MPLab 8 days so you weren’t stuck on windows but since mplab x works on anything.
          Might be fun to put sdcc on a Pi or BeagleBone though.

          1. I use PICs for a ton a projects. C? Use Assembly. Most of what they use them for can be easily done in assembly. I love PICs. I work with ARM too but each has its place.

    2. I’m using XC compiler right now. Free for standard version with no optimization. Work for small project where I don’t even know what to optimize (maybe in C code compiling to asm.)
      Beside, you can always look for open source compiler. In this case, SDCC work quite well. SDCC only lack libraries which you can always port from XC free version. But then again, why would you do that if XC is already free except supporting open source community.

      Sorry for my English. Not my mother language.

      1. CCS? I used pic back in the 90’s with Parallax’s programmer and then recently with XC8, XC16, etc. I haven’t used CCS, what is it and what does it do that the XC’s can’t?

  2. 8 bit micros are not dead! So much simpler to get up and running, so easy to understand all the configuration registers. I remember what it was like to start using an 8-bit micro in assembler, and it wasn’t long before I was writing useful applications. An ARM Cortex has been tough to wrap my head around even without having to craft my own startup and linker scripts, and while using a crapton of glue libraries.

    It’s impossible to beat price/performance of the ARM chips, that’s for sure. And if you’re getting paid to develop in ARM, there’s no risk you’ll accidentally whip out a fully working application in a single day and lose your source of income…nope you’ve got bread for a month. But for applications where I really, REALLY need to feel in control (for safety or other reasons) I will continue to stick with 8 bit micros where I understand what is happening at every clock toggle.

    Regarding the PICs above, I like the NCO frequency synth; useful. I was excited about the factory-trimmed reference voltage until I went into the datasheet and saw it’s +/- 5% accuracy.

    1. The first time on an ARM Cortex may take a while, but if you do several projects with similar chips, it goes a lot quicker. Whipping out a fully working application in a single day is certainly possible.

      1. Do people painfully get to a working Blink project on a new ARM variant, and then guard that project with their lives, basing all future projects on it as a starting point? That’s what it seems like to me…with 8-bit micros I’ve always started with a blank slate and sometimes learned better ways of getting the project off the ground each time.

        1. Usually I start by taking a project that has the most in common, and modifying that, but without all the hyperbole you’ve sketched. When I was still working a lot with 8 bit CPUs, like the AVR series, I did the same thing. And if there’s something I can improve, I’ll do that. That doesn’t require starting from scratch, though.

        2. When I first got an STM32 I didn’t realize you needed to turn on the GPIO peripheral clock (in addition to configuring the system clock) to get my blinking LED to work. Banged my head against a wall for several days before someone clued me in.

          I feel like the 8-bit peripheral registers are so much easier to wrap your head around. ARM is great because it has a huge number of features but horrible because those manifest themselves in a huge number of registers. Lacking the ability to internalize all the functions of each register you are then left trying to wrap your head around the supplied peripheral libraries.

          ARM are low-cost when compared to their performance… just make sure you need all that performance and if not I like to stick to the 8-bit hardware.

          1. True, and a good user manual can make all the difference. Some vendors take the effort of mentioning the clocks issue inside the GPIO chapter, so you have all the information you need in one place. Others let you search the entire user manual yourself, looking for all the little gotchas.

          2. That’s the whole point of taking a look at vendor supplied examples, everything is there most of the time, even if you don’t want to use their SDK/peripheral libs

          3. > That’s the whole point of taking a look at vendor supplied examples, everything is there most of the time, even if you don’t want to use their SDK/peripheral libs

            But often the critical bits, like turning on the clocks, are done in the peripheral libs, and not in the example code.

      2. I don’t get the “it’s easier/it’s harder” thing. They’re just different devices. 8/16 bit micros are cheap and ludicrously low power. ARM devices are typically much higher power and more expensive. Even architecturally, each is going to have a niche.

        1. You can also get modern ARM devices in low power options. Less than 10 uA running on low frequency oscillator, and less than 0.5 uA in sleep mode. But when you need it, you can turn on high speed oscillators for a moment, and run at full performance.

          1. Sure. But unfortunately you usually have to dig really, really hard through the datasheet to figure out whether or not a certain low-power mode is going to work. Determine what things can wake you up, determine how long it takes to wake up from something, determine what you need to do to shut things off and what race conditions can happen, etc. It’s not trivial.

            I usually do have a problem finding a niche for PICs, since they’re a very weird architecture. But MSP430s tend to beat out ARMs pretty handily when it comes to power and usability for me, and AVRs are often competitive as well. I have yet to find an ARM which can act as an I2C slave being in low-power at all times until addressed and being able to respond without clock stretching. Their wakeup times are usually too long (and in some the only wakeup occurs at the start bit of the I2C message, meaning they’re awake for tons of messages that aren’t for them).

    1. Most of opensource projects do accept code commits from users, I assume GCC to be the same ;-)
      On the serious note, what’s wrong with SDCC? This is THE compiler for 8-bitters, GCC is targeted more to 32 and 64-bitters, there is not much of 8-bit forks of GCC.

      1. GCC/Binutils for AVR is actively supported by Atmel. I’ve used it for commercial development, and use it now for hobby stuff – admittedly just the assembler on the itty bitty ATtiny devices which don’t warrant ‘C’. Heck, I prefer to implement state machines using assembler macros, as ‘C’ just gets in the way.

    1. You mean the serial number? Difference between this and Pentium IIIs, is that you write all of the code for this. So you know what’s done with it, or not.

      If you’re not writing the code, if it’s a PIC in some device you’ve bought, then you get no say in it anyway, it could contain a unique serial number in an EEPROM.

      The issue with PCs, is that they’re PCs. People do a whole lot of their everyday stuff on them. That’s when forced tracing is creepy and bad.

  3. 8-bit micros are not dead….but they generate way less buzz than 32-bit ARM micros and are probably used in less products than lets say in the 1990s. 32-bit ARM micros are now just as cheap and low power as 8-bit micros, come in a wide variety of form-factors/packages and with a wide variety of peripherals and memory densities. They are easier to use due to vendor provided peripheral libraries and efforts like mBed and Arduino/Energia.

    Now as far as 8-bit micros go..the PIC16/PIC18 families have got to be have the most architecturally inferior and stunted 8-bit CPU cores that can be purchased for cash. The AVRs architecture has always been orders of magnitude better. The 68HC11, MSP430 (16bits I know), heck even the 8051 and 6052 also offer a better CPU choice.

      1. I use the PIC10 in some projects. I have lights for cycling and I have written different blink patterns in assembler. The PIC10F322 works great for that. Not much code space very few peripherals but it gets the job done.

  4. If there is no Arduino support, I would not bother. For a hobbyist, it is cheaper to buy a high-precision ADC and connect it to Arduino-compatible board (Atmel, TI, STM, etc) via SPI or I2C using existing library than spend a day trying to put together dev environment for PIC and then another week trying to figure out how to use their new ADC.

    1. You can sit down with the datasheet for your target device and MPLAB X and knock it out quick enough, in ASM. They’re simple little devices to hack on. Part of what kept me interested in PICs over other microcontrollers has been the rich peripheral set, and the quality of documentation. And free samples :)

    2. I can’t say I agree with that. I got the ADC working on all pics I used so far in at most a couple of hours (a dozen PIC16Fs, a few PIC18F/PIC24F and PIC32). It’s true the higher the PICxx number the more work it takes to get it to work but I usually just use the manual for the ADC, set the registers, choose the interrupt if necessary and go.
      Arduino libraries sure are convenient but if you’re looking to take samples at 6MHz (using a PIC32MZ) then you’re out of luck. The PIC32MZ can handle up to 18MSPS.
      The thing is that Microchip usually stick to the peripheral design between different cores but just add features and functionality the higher up the chain you go. More interrupt options like direct ADC interrupt vectors, peripheral pin select (so you can multipurpose the pin if you like or design PCB first, then work on the firmware later knowing you can setup the pins in firmware later).
      It’s also not that difficult to adapt arduino libraries for use with PICs. I’ve done this with a color lcd display, and the PID control from MARLIN firmware for example.

      Every time I look in the products available on the microchip site I’m amazed what they’re able to squeeze in. But you have to be aware that some advertized features didn’t make it into actual silicon. Always read the PICs errata document before considering using it. Some ADCs are not working or not working well in some PICs.

  5. For some time now I’ve been working with PICs with very similar features (e.g. PIC16F18346), so I’m not sure why these new models are such big news. But in response to some criticism in previous comments: The peripherals on these PICs are truly amazing, and for certain applications more than make up for whatever disadvantages 8-bit or the PIC architecture have.

    For instance, there’s this Peripheral Pin Select (PPS) module that allows rerouting of many digital functions to most of the pins. I have already used it successfully to talk to 4 different devices over UART from the same little and cheap MCU (*hardware* UART, that is). As long as the communication doesn’t have to be simultaneous, you can have even more devices attached, and broadcast data to one, many or all of them at once if the baudrate matches.

    Also, some new PICs have this digital signal modulator, where you can combine signals from different sources internally – extremely easy and low-resource way to operate, for example, an IR LED with the standard 38KHz modulation.

    My first MCUs were AVRs, so I can’t be blamed for blindingly defending whatever it was I’ve learned first :-) The PICs are not perfect and they’re definitely not the best solution for each and every job, but they can do A LOT and 8-bit definitely isn’t dead.

    1. The Peripherals on some of the newer PIC16/18 maybe somewhat sophisticated when compared to those on the older PIC16/PIC18s (anyone remember the PIC16F877 and the PIC16F84???) and the 8-bit AVRs. Having said that though, the peripherals on many ARM 32-bit micros are more often than not still more sophisticated than anything that you’ll find on a newer PIC16/18 part.

      Integrating sophisticated peripherals with an inferior CPU core such as that of the PIC16/PIC18 is like putting $5000 rims on a crappy ford pinto from the 70s or like an 80 year old on Viagra. Both are very bad ideas…

      1. I really don’t think this comparison is valid; it’s like demanding a Ferrari for every little trip to the supermarket, just because that old Ford has an inferior motor. If I can get a certain job done with a cheap PIC after a quick look at the datasheet, and there’s no need for assembly or advanced optimizations, then why not?

        I don’t have anything against ARM MCUs, one day I’ll find the time to learn and use some of them properly… it just seems that too many people badmouth the 8-bitters on irrelevant grounds.

        1. An ARM Cortex-M0 (48MHz) is more like a Subaru WRX, whereas a cortex-M4 (80 MHZ) is like a Dodge Charger. A cortex-m4/m7 running at 180MHz+ is like a Ferrari. You see not all ARM 32-bit micros are fast beasts like you claim. There’s a huge range or performance from different ARM 32-bit micros

          Also, If you can have a Subaru WRX or a dodge charger for the same (or about the same) price as a Ford Pinto…..why would you still want to buy the Pinto?

          1. …I’m not even familiar with these cars :-)

            My point is, I guess, that for the kind of projects I work on at the moment, my major consideration is convenience; It can be things like 5V operation (to interface with older parts/modules), DIP packages for quick breadboard prototyping (yes, I know there are adapter boards but DIP is still easier), a clear, concise datasheet that’s actually one document instead of 2,000 pages in five different documents, the knowledge that this MCU will still be available a few years from now…

    1. I wish i had one a few years ago. I was working on a cochlear implant (for guinea pigs). We would go from 1bit current setting to 5bit. PWM was too slow and noisy. (500kHz intosc and 32kHz xtal). We where also out of timers.

  6. 28 kB of program flash? And the assembler opcodes to machine code cross reference still fits on 3×5 index card? Hot damn! Young folks these days have no appreciation for “on the metal and in the metal” programming where you have to use your smarts instead of letting a compiler do it.

  7. My current love is the STM8S003 – available for 15-19 cents from China, ~28cents from ST @ one-off. It’s actually quite good too. Much as I love my Cortex M0’s and M3’s, the price of an STM8 puts it at a whole different level. Runs C great. Caveat: their IDE sucks – it actually doesn’t have a keyboard shortcut for “Run”. …Really ST?
    Anyway, great bang for the (much less than a) buck. I lost interest in PICs and 8051s a long time ago personally.

        1. Well, commercial compilers are sometimes better in some aspects than the open-sourced ones, written by volunteers. That guy above wrote about GCC, so I assume he was worried about open-source compiler, what XC8 isn’t. I know and use XC8, even MCC18 (using it actively for 12 years), I made some PIC projects for both SDCC and XC8, available on my .io page.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s