PIC16F145X: Full-Speed USB with no external crystal

Microchip is about to release the PIC16F145X family of microcontrollers. This little guy is advertised to have Full-Speed USB capability without the need of the usual external oscillator. From the product brief it appears that this uC will use the host USB signal to tune the internal 48 MHz oscillator and comply with the USB standard. Below is a list of features for the PIC16F1459 uC.

  • Enhanced Mid-range Core with 49 Instruction, 16 Stack Levels
  • Flash Program Memory with self read/write capability
  • Internal 48MHz Oscillator
  • Universal Serial Bus 2.0 Module with clock recovery from USB host
  • 2x Standalone PWM Modules
  • Complementary Waveform Generator (CWG) Module
  • Integrated Temperature Indicator Module
  • 10 Channel 10-bit ADC with Voltage Reference
  • 2 Analog Comparators
  • 5-bit Digital to Analog Converter (DAC)
  • MI2C / SPI Module
  • Enhanced Addressable USART Module
  • 25mA Source/Sink current I/O
  • 2x 8-bit Timers (TMR0/TMR2)
  • 1x 16-bit Timer (TMR1)
  • Extended Watchdog Timer (WDT)
  • Enhanced Power-On/Off-Reset
  • Low-Power Brown-Out Reset (LPBOR)
  • Programmable Brown-Out Reset (BOR)
  • In Circuit Serial Programming (ICSP)
  • Integrated In-Circuit Debug Circuit
  • PIC16LF145x (1.8V – 3.6V)
  • PIC16F145x (1.8V – 5.5V)
  • Via the forum.

    Join the Conversation


    1. 16F and USB :( I never find it very useful to do usb communication in assembler .. and how much flash will the device have, with 16F usually having so little flash adding usb stack on it can make this device “cool” only if it cost something like 10-20c

      1. Microchip has a C language USB library – is it not available for the 16F? It certainly works well for the 18F. I used much less than 32K Flash for a commercial USB-MIDI Device based on the 18F, and some of that was for storage of user settings.

        1. There is no free C compiler for 16F. AFAIK mchip has some asm code for usb for 16F but asm for hobby projects – never, I’ll pay a 1$ more and use proper C with 18F device. Those two pins that osc frees, thanks but no thanks.. 16F ain’t something I will ever be using for hobby projects, it’s just not worth it… this chip has a market place, probably, as a cheap replacement for ftdi chips, so you can have your usb2uart or usb2fifo or usb_hid_youstick controller (read values from few buttons and few pots and send them to pc), but for anything serious it’s useles

        2. Microchip bought the HITECH C compiler and now include a lite version with MPLAB. As far as I know, it is just like the C18 and C30 compilers – no limits except expiring some optimizations I never use.

        3. “no limits except expiring some optimizations I never use”

          That’s interesting news (I think I already read this on forum too), should check, I have hitech installed with mplabx … anyhow I didn’t see the usb stack for the hitech, if anyone know about it please point me to right direction.

          As for the usb stack for 16F, there is usb stack, the only problem is that it is written in asm :(

        4. AFAIK – Sjaak has been doing a lot of work with it lately on the Bus Pirate Demo board and some other stuff, he would know best. Maybe he will see the comments and chime in :)

    2. the largest device 1459 I think will have 14K, which is only 2K less then the pic18f14K50 (which is used as the MCP2****somethin USB to UART)

      1. so it has LESS flash then the device that only does usb2uart .. not to mention how much more efficient 18F is anyhow … I really don’t see a point of that 16F except it really is 0.1$ or something like that, at least not for hobby applications

    3. I don’t think the pic18F14k50 is filled to the brim to serve as a USB to UART..maybe aound half full.
      but that irrelevant, the coolest thing about this PIC IMHO is that you don’t need a crytall

      1. Several USB microcontrollers that can do USB full speed without requiring any cristal oscillator.already exist in the market. Microchip is late in the game and it’s spects aren’t really any impresive. I guess PICs only advantage is this segment is it’s huge fan base and maybe price.

    4. As seen in the product brief, this is a new microcontroller family with 4 members.
      Two has 20 pins, two has 14 pins.
      I find the small 14 pin variants really cool.
      Hopefully they will be very cheap.
      A small 14 pin SSOP device without external crystal… can be a cost effective soultion for small, cheap gadgets manufactured in high volumes.

      About the performance: 4096 instructions and 512 bytes ram is enough for USB implementation?
      Maybe for HID profile… (I think it is one of the simplest profile)

      Ist this chip enough for the USB Infrared toy? If yes, it can be realized in a really small form factor.

    5. The PIC family is the FIRST and so far only announce family that has USB clock recovery. Therefore it is really the only family that can be expected to work with USB using the internal oscillator across the full range of temperature range. No other PIC family has specs that allow for that.

      This family also uses the “enhanced core” and is at least half way between the standard 16F family and the 18F family. It has twice the USB RAM of the 18F14K50 and that is a huge Plus. The 14K50 was short by at least 64 bytes of USB RAM for CDC.

      However for it to be really successful it is going to have to be keenly priced. At this point in time I am not sure that is going to be the case.

    6. This is the first 16F chip with USB capability (there was the 16C745, but it was low speed only and didn’t have flash!)

      USB Stack is an interesting question. Last I heard, the HiTech compiler for PIC16/PIC18 did NO optimization in “Lite” mode (unlike the gcc versions for PIC24/PIC32, which has the normal gcc optimizations and is only missing some special optimizations), resulting in incredibly crappy object code. (note that this is instantly changeable at Microsoft’s whim.)

      The 745 apparently had an ASM USB stack; I wonder if it is at all useful.

      1. The Hi Tech compiler does “anti optimizations” in lite mode so as to make the full paid full compiler produce even better optimized code in comparison. Deliberate bloat. This was shown and discussed on the microchip forum within the last month. I would not be using it to write a USB stack.

        The asm code for the 745 has been the basis for many of the asm stacks for the PIC18 and I have no doubt that it will again for the 16F1459 family and it is a good starting point.

    7. I don’t have the link sorry and the microchip forum’s search engine is totally useless. However the code shown had stuff like this.

      movlw 0
      BRA $+2
      BRA $+2
      BRA $+2
      BRA $+2

      Just deliberate bloat…

    8. of course this will be cheap, that is the whole point.

      USB in 14 pins, self tuned Osc, is going to sell ship-loads, so Microchip will have the last laugh at those claiming “far from impressive in any segment”.

      Microchip will also likely do a Preloaded version, just like they do now.
      Hopefully the offer BOTH a Preloaded series, and the source code used, so minor user tweaks are possible.

    9. Hi,

      I compiled today 2 projects for the PIC16F1459 using the free USB device stack in C using XC8 Free compiler (it has no program size limitation).

      There are several projects in the USB libraries for this device. They can be downloaded here : http://www.microchip.com/MLA

      The HID keyboard project has a size of 3785 words (46% of the device flash) in free mode
      The CDC serial emulator project has a size 4175 words (51% of the device flash) also in free mode

      The good news is that it is the same USB stack as the PIC18 so if you have used it for other projects in the past you may be able to migrate them to this cheaper PIC16F1459 device


      1. Wow, that is great. I have tried and tried again and all I get is a cryptic error message. Can you post the project somewhere? I would love to take a look and add the clock sync code that needs to be added. I think that is the only change required to the code. The linker script may need to be altered a little to ensure our double buffers are in USB ram but other than that I expect it to work out of the box.

      2. Hello,
        I’m working on an open source board project that uses the PIC16F1459 and I would very much like to use the USB bootloader. I’m looking for more details on how to get the Microchip HID Bootloader working with MPLAB-X adn XC8 as you mentioned.

        I’ve tried myself but always get an error message saying it cannot generate the makefile. I’m guessing that I need a specific .lkr file for this device and one is not present. Can I just copy/modify the PIC18F14K50 one?

        Could you post a few details about how you got the HID to compile for the PIC16F1459?

        Thank You.

      1. Sorry, I completely misread what you said. I thought (wishful thinking) that somehow you got “our” USB stack to compile. That is something that is stuck on my brain and I got misconnected the dots.

        Um, sorry!

      2. Still couldn’t get the microchip basic CDC to compile. Forget the error message but something was not right in the source code. Anyway the good news is I got my own stack compiling. Now I just have to wait on the samples to arrive to test it. :)

    10. Hi,

      You’re right regarding CDC serial emulator. There’s a little mistake in source code.
      You just need to modify the following : in the file usb_function_cdc.c you must comment the line :
      // extern BYTE_VAL *pDst


      1. Thanks but I had found and fixed that. The problem is that XC8 appears to have compiled the code part way through but MPLAB X just hangs for a minute and finally throws a meaningless message. Got me beat. I have tried all sorts of things. Maybe I should try other project.

        CLEAN SUCCESSFUL (total time: 406ms)
        make -f nbproject/Makefile-LPC_USB_Development_Kit_PIC16F1459.mk SUBPROJECTS= .build-conf
        make[1]: Entering directory `C:/Microchip Solutions v2012-07-18/USB/Device – CDC – Basic Demo/Firmware/MPLAB.X’
        make –jobs -f nbproject/Makefile-LPC_USB_Development_Kit_PIC16F1459.mk dist/LPC_USB_Development_Kit_PIC16F1459/production/MPLAB.X.production.hex
        make[2]: Entering directory `C:/Microchip Solutions v2012-07-18/USB/Device – CDC – Basic Demo/Firmware/MPLAB.X’
        “C:\Program Files\Microchip\xc8\v1.01\bin\xc8.exe” –pass1 –chip=16F1459 -Q -G –asmlist –double=24 –float=24 –emi=wordwrite –opt=default,+asm,-asmfile,+speed,-space,-debug,9 –addrqual=ignore –mode=free -P -N31 -I”..” -I”..\..\..\..\Microchip\Include” –warn=0 –summary=default,-psect,-class,+mem,-hex,-file –runtime=default,+clear,+init,-keep,-no_startup,+osccal,-resetbits,-download,-stackcall,+config,-clib,+plib “–errformat=%%f:%%l: error: %%s” “–warnformat=%%f:%%l: warning: %%s” “–msgformat=%%f:%%l: advisory: %%s” -obuild/LPC_USB_Development_Kit_PIC16F1459/production/_ext/926206843/usb_device.p1 ../../../../Microchip/USB/usb_device.c
        “C:\Program Files\Microchip\xc8\v1.01\bin\xc8.exe” –pass1 –chip=16F1459 -Q -G –asmlist –double=24 –float=24 –emi=wordwrite –opt=default,+asm,-asmfile,+speed,-space,-debug,9 –addrqual=ignore –mode=free -P -N31 -I”..” -I”..\..\..\..\Microchip\Include” –warn=0 –summary=default,-psect,-class,+mem,-hex,-file –runtime=default,+clear,+init,-keep,-no_startup,+osccal,-resetbits,-download,-stackcall,+config,-clib,+plib “–errformat=%%f:%%l: error: %%s” “–warnformat=%%f:%%l: warning: %%s” “–msgformat=%%f:%%l: advisory: %%s” -obuild/LPC_USB_Development_Kit_PIC16F1459/production/_ext/1083301514/usb_function_cdc.p1 “../../../../Microchip/USB/CDC Device Driver/usb_function_cdc.c”
        “C:\Program Files\Microchip\xc8\v1.01\bin\xc8.exe” –pass1 –chip=16F1459 -Q -G –asmlist –double=24 –float=24 –emi=wordwrite –opt=default,+asm,-asmfile,+speed,-space,-debug,9 –addrqual=ignore –mode=free -P -N31 -I”..” -I”..\..\..\..\Microchip\Include” –warn=0 –summary=default,-psect,-class,+mem,-hex,-file –runtime=default,+clear,+init,-keep,-no_startup,+osccal,-resetbits,-download,-stackcall,+config,-clib,+plib “–errformat=%%f:%%l: error: %%s” “–warnformat=%%f:%%l: warning: %%s” “–msgformat=%%f:%%l: advisory: %%s” -obuild/LPC_USB_Development_Kit_PIC16F1459/production/_ext/1472/main.p1 ../main.c
        “C:\Program Files\Microchip\xc8\v1.01\bin\xc8.exe” –pass1 –chip=16F1459 -Q -G –asmlist –double=24 –float=24 –emi=wordwrite –opt=default,+asm,-asmfile,+speed,-space,-debug,9 –addrqual=ignore –mode=free -P -N31 -I”..” -I”..\..\..\..\Microchip\Include” –warn=0 –summary=default,-psect,-class,+mem,-hex,-file –runtime=default,+clear,+init,-keep,-no_startup,+osccal,-resetbits,-download,-stackcall,+config,-clib,+plib “–errformat=%%f:%%l: error: %%s” “–warnformat=%%f:%%l: warning: %%s” “–msgformat=%%f:%%l: advisory: %%s” -obuild/LPC_USB_Development_Kit_PIC16F1459/production/_ext/1472/usb_descriptors.p1 ../usb_descriptors.c
        “C:\Program Files\Microchip\xc8\v1.01\bin\xc8.exe” –chip=16F1459 -G –asmlist -mdist/LPC_USB_Development_Kit_PIC16F1459/production/MPLAB.X.production.map –double=24 –float=24 –emi=wordwrite –opt=default,+asm,-asmfile,+speed,-space,-debug,9 –addrqual=ignore –mode=free -P -N31 -I”..” -I”..\..\..\..\Microchip\Include” –warn=0 –summary=default,-psect,-class,+mem,-hex,-file –runtime=default,+clear,+init,-keep,-no_startup,+osccal,-resetbits,-download,-stackcall,+config,-clib,+plib “–errformat=%%f:%%l: error: %%s” “–warnformat=%%f:%%l: warning: %%s” “–msgformat=%%f:%%l: advisory: %%s” -odist/LPC_USB_Development_Kit_PIC16F1459/production/MPLAB.X.production.cof build/LPC_USB_Development_Kit_PIC16F1459/production/_ext/926206843/usb_device.p1 build/LPC_USB_Development_Kit_PIC16F1459/production/_ext/1083301514/usb_function_cdc.p1 build/LPC_USB_Development_Kit_PIC16F1459/production/_ext/1472/main.p1 build/LPC_USB_Development_Kit_PIC16F1459/production/_ext/1472/usb_descriptors.p1
        Microchip MPLAB XC8 C Compiler (Free Mode) V1.01
        Copyright (C) 2012 Microchip Technology Inc.
        (1273) Omniscient Code Generation not available in Free mode (warning)
        ../../../../Microchip/USB/usb_device.c:1524: warning: constant conditional branch
        ../../../../Microchip/USB/usb_device.c:2271: warning: constant conditional branch
        ../main.c:515: warning: constant conditional branch
        ../../../../Microchip/USB/usb_device.c:2073: warning: function pointer “_outPipes.pFunc” is never assigned a valid pointer
        ../../../../Microchip/USB/usb_device.c:2785: warning: function pointer “_outPipes.pFunc” is never assigned a valid pointer
        (908) exit status = 1
        make[2]: *** [dist/LPC_USB_Development_Kit_PIC16F1459/production/MPLAB.X.production.hex] Error 1
        make[1]: *** [.build-conf] Error 2
        make: *** [.build-impl] Error 2
        Looping around allocGlobals()

        make[2]: Leaving directory `C:/Microchip Solutions v2012-07-18/USB/Device – CDC – Basic Demo/Firmware/MPLAB.X’
        make[1]: Leaving directory `C:/Microchip Solutions v2012-07-18/USB/Device – CDC – Basic Demo/Firmware/MPLAB.X’

        BUILD FAILED (exit value 2, total time: 59s)

    11. Hi,

      I see the same problem as you do. I’ll check with Microchip support how to solve that issue


    12. Apparently this Looping around allocGlobals() error has existed in the HI-TECH cum XC8 compilers for over a YEAR and there is no solution offered other than “change your code.”

      Hopefully microchip can get this sorted before the silicon hits the streets. At least I have a back-up plan. :)

      1. Thanks for passing that on. Maybe XC8 1.0 is better and I may try winding back however I thought (?) I saw the same issue written about in the XC8 V1.0 readme too. However that does not mean that it will occur. It seems to be an oddball issue that is not easy to pin down. Like I said this is a HI TECH C problem over a year old.


    13. Hi,

      Just got my samples today.
      I managed to have the HID keyboard project to compile with XC8 v1.01 and also to enumerate when connected to the PC usinf INTERNAL RC oscillator ;=)

      Tricky point is that there are 2 ICSP ports. The ICSP on pins 18 & 19 can only be used if the PIC is in LVP mode but you can ONLY put the PIC in LVP mode by using the other ICSP on pins 15 & 16.

      I’ll try the CDC serial project in the near future ;=)


      1. You got your samples already? Last I looked there was a 90 day wait. I an hanging out for mine. I have three different stacks to test with and various classes written. I am just playing with MIDI right now on the 14K50.

        You lucky $@#$#^ you! :)

      1. the upper 256 bytes of program memory are specified in the datasheet as “high endurance Flash”.
        I suppose it can be used as a.k.o. data flash memory, but it is not yet documented how o do that.

        1. Hi,

          The last 128 bytes called “High Endurance Flash” can withstand 100K Erase/Write cycles compared with normal Program Flash which has only 10K

          It is mentioned in datasheet section 29.5


        2. How can I write on flash PIC16F1459 with istructions?
          I can’t find nothin. Maybe this PIC no support EEPROM emulation.

    14. I was making some initial tests with a PIC16F1454 and found some trouble trying to use RA4 as input, it didn’t work until I clear bit 4 of the ANSELA register (this disables analog input on RA4 for PIC16F1455 and PIC16F1459), even though the PIC16F1454 does not have any analog inputs.

      I used this test code, it justs copies RA4 to RC5:

      * File: TestIO.c
      * Author: José Jorge Enríquez
      * Created on 21 de diciembre de 2013, 03:35 PM


      #pragma config FOSC = INTOSC
      #pragma config MCLRE = OFF
      #pragma config LVP = OFF
      #pragma config PLLEN = DISABLED

      // For accessing ANSELA register
      volatile unsigned char ANSELA @ 0x18C;

      int main() {
      OSCCONbits.SPLLEN = 0; // PLL disabled
      OSCCONbits.IRCF = 0b1101; // 4 MHz internal oscillator
      OSCCONbits.SCS = 0b00; // Clock determined by configuration word

      TRISCbits.TRISC5 = 0; // Led
      TRISAbits.TRISA4 = 1; // Input

      ANSELA = 0x00; // Disable analog inputs
      // Needed for RA4 to work as digital input

      OPTION_REGbits.nWPUEN = 0; // Enable weak pull-ups
      WPUAbits.WPUA4 = 1; // Enable pull-up on RA4

      while (1) {
      LATCbits.LATC5 = PORTAbits.RA4;

      return 0;

      Does anybody has this problem? Is this really an issue or I’m not configuring properly? I’ve just checked the errata sheet, but no mention of this. The chip I’m working with is revision 1005h.

    Leave a comment

    Your email address will not be published. Required fields are marked *

    Notify me of followup comments via e-mail. You can also subscribe without commenting.