Get Your Kicks With This New PIC Development Board

While development boards for micro controllers are nothing ground breaking, they can be expensive, and often times overkill for what you’re doing when they try to put everything you might use … including the kitchen sink. when [Brian] noticed his projects were starting to use Microchip PIC24 more and more, the time came to have a dev board on hand. 

top-viewThe result is a small board with breakouts for USB, UART (via FTDI), of course tons of GPIO pins, and a socket which mates with a daughter board to swap out either a PIC24FJ128GC006, or a DSPIC33EP256MU806, with the potential for more. Also packed on the board is a power regulator system and dual crystals allowing full speed operation or power sipping modes.

Schematics and PCB layout are available (in Diptrace format) along with a board template file to use with MPLAB on Once you have everything together you will need a PIC programmer, [Brian] is using a trusty Microchip MPLAB ICD 3 programmer, but naturally, others are available.

Microchip recently announced a new development board of their own for the PIC16F series. The Curiosity board has built-in support for programming and debugging (no chipKIT needed). The engineer who designed that board, [John Mouton] is going to join us on July 30th for a live chat about the design process. We’re also going to be giving away some of the first boards to come off the production line… more about that this coming week.

27 thoughts on “Get Your Kicks With This New PIC Development Board

    1. AFAIK no, and I don’t think there ever be.
      Anyone needing more power than 8-bitters with SDCC can use 32-bit PIC32 and GCC, making 16-bit PIC MCUs quite unattractive for the huge time and effort needed to develop SDCC or GCC derivative for it. I assume you know the open source tools doesn’t fall from heaven, but somebody must do it, do you?

      1. Microchip should have been in that role.

        Instead, they have universally despised open source, whereas Atmel took to it. In fact, they’re the ones that made the AVR opensource toolchain, that programs all their chips.

        PIC still requires ~20 different compilers. Pretty much, Microchip’s dev environment is a pile of human shit on top of a lagoon of pigshit. Give me AVR any day.

        1. At first, Atmel did *absolutely nothing* to support AVR GCC, it ran for years with just volunteer community support. In last few years they jumped on “open-dource” bandwagon, sodomizing this term as another marketing buzzword and trying to look like they are the ones who are doing all the hard work.

          No, you need only 3 compilers for all the Microchip portfolio. One for 8-bitter, one for 16-bitters and one for 32-bit ones. Seems logical to me.
          If you wish, you can also use completely open-sourced compilers, like SDCC or MIPS GCC, along with open-sourced programmers, like PicKit2 (which is developed in Microchip).

          If you want to contribute to this thread, please, do your homework and study how open-sourced projects with Microchip MCU’s do work – like Pinguino, RetroBSD, or Chipkit MPIDE – before acting like a complete ignorant.


    2. What’s the problem with using XC-16? In free version optimization level 1 is available an quite good. If it is not good enough one can use assembly code. It how I work and have no problem with it.

    3. There are at least four methods by which the restrictions can be removed:

      1) -O2 optimization isn’t allowed, nor higher modes. But that flag is mostly just a shortcut, activating a slew of other optimization flags. All of those other flags are allowed, can be put in manually, and provide access to almost all optimization functionality.
      2) Run Pro trial mode eternally with an altered system date, optionally in a virtual machine.
      3) Replace the license manager with a fake, that always provides an exit code of 2. On newer versions, it’s also necessary to hex edit the tools that call the manager, replacing the plaintext SHA-256 hash of the genuine manager with that of the fake.
      4) The tools that check with the license manager are almost entirely of open-source origin. Complete source code is available from Microchip. Download, remove calls to the license manager, compile.

      It’s easy for an individual to bypass the restrictions. And it can be done legally if preferred, using #1, or possibly #4.

      So I can’t understand why folks complain there is no free and open toolchain. I gained the knowledge above, fixed the limitation, and went on with coding… all in less time than it ever took me to get a free toolchain to work properly.

        1. Tried ARM. Spent my first week with it trying to figure out why my program was crashing. Discovered it would crash after the ISR executed a specific number of times, close to the size of my stack. Disassembled the compiler generated ISR entry/exit code and found it was unbalancing the stack by failing to pop one register. Posted minimal C code to replicate, along with the disassembled ISR entry/exit code. Received a response from a compiler developer, calling me a liar and troll.

          That’s true idiocy. So is your claim that “PIC still requires ~20 different compilers”. Microchip and its users’ idiocy is mild by comparison.

      1. You could also simply integrate the MPIDE toolchain into MPLABX and call it a day. This way you get an uncrippled PIC32 compiler working under MPLABX. I believe C++ support is limited (No standard C++ libs) but if you’re writing C based applications with some custom C++ classes the MPIDE toolchain is perfect.

  1. Go ARM. PICs are fraught with silicon errors, requiring costly workarounds. Read through a few of their numerous errata sheets, and you’ll quickly see what I mean.

    1. I have been working with PIC for years, 8, 16 and 32 bitters and few times I had to deal with silicon errata and the consequences were minor. And by the way ARM core don’t make the MCU. There is tens of manufacturers using ARM cores in their MCU and what goes around it is their own design and can be plague with silicon errors as well.
      Go to any MCU manufacturer and you will find silicon errata documents.

      needs examples?

      from Atmel: (this is an ARM core CPU)

      from ST microelectronics:
      (another MCU based on ARM)

      I could keep going.

    2. Like ARM is any different? Picked up the early TI chips so heavily promoted on HaD a while back and the damn chip has unusable EEPROM. Apparently, TI quietly fixed it by killing off that line and substituting a drop in replacement without any fanfare or much of anything for that matter.

      That wouldn’t be too bad but TI has no clear uprade path so it took quite a bit of research and forum postings before figuring out what was going on and what needed to be done to maintain legacy compatibility (for something that’s only a couple of years old).

    3. Sorry if the handful of people who don’t wanna learn anything new or modern are hating on you. PICs are outdated and I don’t miss ’em one bit, just like I don’t miss Windows 95.

        1. Many PICs are outdated. The dsPIC is pretty interesting, due to the real DSP core in it, and very good software library support. But … they burn crazy power. 5-8x time what an ARM micro of comparable performance does. Their debuggers are fairly limited, and their product lines and feature sets are also quite fractured.

          I am, right this second, trying to debug something on a dsPIC33F. If it was an ARM, and I had full PC trace, I could solve this problem in hours. Instead, I am picking through some blocking code bug that I can’t locate, and it will likely take me days. Oh, and this chip burns 70-80mA at 40Mhz instruction clock. An equivalent ARM (60 MIPS or so) would be 20 or less.

          Also, their chips are expensive. Sure, highly featured ARM micros are, too, but you get a crazy number of peripherals for that price. ETM cores, timers with a dozen operating modes, systicks that save tons of development interleaving, and so forth.

  2. Dev board looks good. I see there’s some empty space though. I’m fond of including a couple of busses when that happens:

    I2C: GND / VDD / SCL / SDA / INT(shared)

    These are provided as 5-pin 0.1″ male headers, times however many slots I want. My peripheral boards are standardized to this pin ordering, and so can be quickly attached with a 5-pin jumper (plus one select jumper for each SPI device). I don’t typically hard wire bus data pins to a MCU pin on the PCB, attaching them with jumpers instead.

    I just got my new PCB for TQFP44 PICs in from FusionPCB. Intended not only to be a decent dev board, but a home automation node. All MCU pins brought out to headers, I2C/SPI busses, ICSP, space for main and RTC crystals, KIS-3R33S switching regulator with added noise filters, NRF24L01+ header, soft power switch, and monitoring of unregulated supply voltage for low battery shutdown. Managed to pack it all into their cheapest 2cm x 2cm board, while using 0.1″ headers, and no SMDs smaller than 0805. Hope to heck I made no mistakes, it’s the densest and most complex board I’ve made!

  3. Neat Board! I used to be a big fan of the 16/32-bit Microchip parts. I love the MPLABX IDE, but the whole crippled compiler thing keeps me away.

    Here’s the first revision of my teensyish stm32f072 (cortexm0 based) board. Comes With 128KB Flash, 16KB RAM, 4 USARTS, 1USB, 1 1MSps ADC, DAC, 2SPI, 2 I2C, a crapload of timers/pwm/input capture/output compare facilities /real-time clock and more. The chip has a DFU USB bootloader so you only need a dfu firmware software (dfu-util) to program it. No need to mess with USB2Serial chips or external programmers!

      1. @jacques1956 You are right it does not violate the GPL License. Besides Microchip provides all the sources so technically you can build your own Microchip based C32 /XC32 compilers from scratch. But it still feels unethical when they intentionally cripple the mips-gcc optimizations such as -02 -03 -0s and -mips16e flags under the excuse that they adding there own libraries or somehow enhanced these optimizations. They can always add their own custom optimizations and charge for them separately without having to cripple the standard gcc ones.

        In any case the uncrippled ARM-GCC toolchain is available completely for free with CMSIS and linker/startup files. I prefer going IDE- less and using a text editor and makefiles so this works well for me.

        In addition most ARM microcontroller vendors now make their firmware libraries completely free and/or provide complete free tools (configuration wizards, flashers, IDE, toolchain, libraries the whole works). I’m specifically talking about Freescale, STM32, TI, Atmel, Silicon Labs, Cypress, NXP…I’m sure I missed some. They all provide a complete development suite with little to no limitations. None of them attempts to cripple their compliers.

        As for debugging, openocd is a great opensource gdb server. And there are plenty of cheap JTAG dongles out there. I can get an STLink dongle (specific to STM32’s) for as little as $3. I honestly find that I tend to rely more on printf/uart debugging and less on JTAG/SWD with the newer cores as they are more sophisticated and have multiple i can always dedicate one uart for debug.

        1. Maybe this has changed in the past few years, but OpenOCD is/was a very complicated mess of configurations and limited compatibilities, and took expert level tweaking to make work.

          For all the problems that Microchip and some of their product lines have, it is *really* easy to get MPLABX and XC16 installed and working. No account sign up, no registering for trial licenses, no code size limit. You just open the box and it works.

          1. I’ve been playing around with openOCD, bare-metal toolchains and makefiles for several years and I enjoy it. It is not hard…just has a bit of a steep learning curve. There are plenty of openocd tutorials out there. But here’s the thing with ‘reasonably’ bug-free firmware library debugging is…at least to me; not as necessary as in the past when one coded everything in register-based C.

            In my honest opinion, anyone who wants to take embedded development seriously needs to spend some time messing with Makefiles, linker files startup files e.t.c and openOCD. This’ll give them a better understanding of embedded dev tools and help them become better embedded systems developers.

            I agree that user privacy is a major concern. One can easily create a throw away email (GMAIL/MSN) account and use it to create accounts on the Freescale, STM32 (openSTM32 community) and Atmel sites. Once logged in you’ll be able to access

            – STM32’s System Workbench For STM32
            – Freescale’s Kinetis Studio
            – Atmel’s Atmel Studio

            These IDE tools are vendor specific and COMPLETE (IDE, Configuration Wizard, Programmer software, debug environment, Firmware libraries). Nothing is crippled what so ever.

            – NXP offers LPCXPresso without account creation . Code size is limited to a generous 256KB….I refuse to use LPCXpresso due to this limitation, but if I had to choose between a code size limit and a crippled compiler (aka Microchips PIC32 compiler)…I’ll go with the code size limit every single time.

            – TI also offers free complete dev tools via code composer studio downloads that are board specific. I heard that they’ll also be offering cloud-based IDE completely for free as well. You’ll need to use that throwaway account to access this stuff though.
            – An ofcourse there’s also Mbed….It’s a pretty flexible High level API that is not as amateurish as Arduino.
            – Other completely free IDE’s for ARM chips also include Emblocks and CooCox.

            – Not to mention the crapload of sub $15 development boards for ARM microcontrollers out there; most of which include on board hardware debuggers (ST-Discovery/Nucleo, TI Launchpads, Freescale’s Freedom boards, NXP’s LPCXpresso boards e.t.c)

            My point is Microchip still thinks thats it 2005. They’re at least a decade behind other vendors and will continue to fall behind if they continue to rely on technology thats anywhere from 1-3 decades old (8-bit PIC16 from the 80s, PIC18’s PIC24 & DSPIC from the 90’s and PIC32 from the 00’s…the M4K architecture is older than that).

            They need to aggressively compete in the 32-bit market and one of the ways that they can achieve this is by not crippling tools that are technically available for free. Even if the XC16 and XC32 toolchains were developed from scratch by Microchip…..offering crippled compilers in an era where most microcontroller vendors (or at least the ones that matter) are giving away complete dev tools for free will probably end up hurting their bottom line.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.