Microchip has unveiled a new dev board called the Curiosity Development Board. I had my first look at this at Bay Area Maker Faire back in May but was asked not to publicize the hardware since it wasn’t officially released yet. Yesterday I got my hands on one of the first “pilot program” demo units and spent some time working with it.
I requested a sample board out of my own curiosity. As you may know, Microchip is one of the sponsors of the 2015 Hackaday Prize, but that partnership does not include this review. However, since we do have this relationship we asked if they would throw in a few extra boards that we could give away and they obliged. More about that at the end of the post.
I haven’t really done any PIC development. I started off with Atmel chips because you could program them with a parallel port. These were the pre-Arduino days and I didn’t want to invest in a proper programmer until making sure I liked the chip family. This could not be done at the time with Microchip microcontrollers – or at least bootstrapping a programmer was harder – since they needed a 12V source when programming. That “high voltage” signal was provided by a PICkit or similar programmer. I think the Curiosity is a great way around this issue. It uses PKOB – PICkit on board – for both programming and debugging.
Curiosity has a DIP socket in the middle of the board with pin breakouts to either side. The board has a programmer/debugger built into it which means just add a USB cable and computer and you’re up and running. The setup reminds me of TI’s MSP430 Launchpad board, and I really like that one.
The machined pin header plays host to 8, 14, or 20 pin chips from the PIC12, PIC16, and PIC18 families of 8-bit processors. The early version I received shipped with a PIC16F1708 but I’m told that production versions will ship with the PIC16F1619. If that’s not the chip you’re looking for they do have a sample request button for each chip listed on the “supported devices” tab of the Curiosity page. The ability to try out a bunch of different 8-bit chips and swap them out on this board is a perfect way to get your feet wet.
My board has four rubber feet on the bottom to sit nicely on the bench (and keep the bottom side away from stray leads and other conductive detritus). For user input there is a single button, a capacitive touch button, and a potentiometer. The placement of the user button and the foot underneath is dubious. Since the button is to the outside of the foot, pressing the button tilts the whole board if you don’t hold down the opposite corner. I asked about this and Microchip had the same issue in their testing. The production boards will ship with standoffs installed at the four corners (metal for the first 500 boards and probably plastic standoffs at scale). It’s nice to see they’re working to cover all bases before these hit the public.
The corners of the board are rounded and the edges are the smoothest I’ve ever felt on a dev board. Real estate to the left of the chip and breakout headers is used by the programmer/debugger circuit located on the underside of the board, with a foot print on the top side to add an optional barrel jack for 9V input (this will be regulated by existing parts). There are also a pair of headers for connecting a bench supply that performs its own regulation.
To the right on the top of the board there are two footprints for add-on hardware. One is a dedicated design for the RN4020 BTLE module. The other footprint uses the mikroBUS pinout standard. I’ve heard the name before but this is the first time I’ve looked into it. A few of the Hackaday crew have seen the standard in action and mention that it is more popular with engineers in Europe. At the least, it’s a set of SIL outlines spaced at a multiple of 0.1″ so you can plug the modules into a breadboard (unlike the Arduino shield standard). At it’s best, Microchip is embracing a standard that has been around for more than a few years rather than try to invent their own. It’s well documented so you can build your own modules or use those already on the market from many different companies.
Perhaps the finest part of this design is the lengths that they’ve gone to in order to make all pins available. Every place that pins have been routed to function-specific footprints (mikroBus, user button, LEDs, capacitive pad, but not the BTLE header) there is an easy way to get at the signals.
To the right is a close-up of the bottom of the board. You can see there are DIL headers where pads from each row are connected together with zero Ohm resistors. Snip or desolder these jumper resistors and you disconnect the component. It’s better than cutting traces on the board because you can populate the footprint with pin headers and use jumpers to patch back in the original functionality. Nice, huh?
I downloaded and set up the MPLABX IDE. Kudos to Microchip for having a Linux version (if only Cypress could do the same for PSOC4!). After opening the sample code from the Curiosity page I chose the included compiler and selected the programmer type and was unable to build the examples. Reading through the Curiosity User Guide (PDF) I discovered that I needed to download and install the free version of the XC8 compiler. After that I had no problem building and flashing the examples. The first time around the IDE even did an automatic firmware upgrade to the PKOB programmer. This is definitely one of the easier toolchain setups I’ve gone through.
Generally I avoid proprietary toolchains (I also have the luxury of not making a living by building electronics so a bit of hassle is not big deal). I did some quick searching and I don’t think you can use the SDCC Open Source Compiler for this particular chip (PIC16F1708) but there are other chips supported by that compiler and I don’t see why this programmer wouldn’t work with Open Source programming tools as well. I just didn’t have the time to test before publishing this article.
This is a well-conceived and well-designed development board. The ability to swap out chips, and the additional breakout footprints providing access to IO pins makes this one of the most flexible dev boards of any architecture. I enjoy minimalistic “bells and whistles” so the inclusion of one button and four LEDs hit the sweet spot for me. At $20 MSRP this is a safe bet for those not wanting to take the $50 plunge on a standalone PICkit 3 programmer. Having both programming and debugging options means this will be a tool that is hard to outgrow.
Most of the major distributors have the Microchip Curiosity dev board listed, but none of them have stock yet. But since we were asking for one and already have a good relationship with Microchip we asked if they had any extras to give away to Hackaday readers. Head on over to the .Stack post for details.
The Curiosity Board was designed by [John Mouton], along with a team of talented folks over at Microchip. [John] will be joining us for a live chat about what went into the project. Add it to your calendar and start thinking of questions you might want to ask.
What a coincidence! I went to a demo at Microchip a few months back and just yesterday got a notice that they’re going to mail me one because they didn’t have any at the demo.
Avoid Microchip an their products, especially the PIC chips. Microchip is violating the GPL by withholding the source to the version of GCC that they sell for profit. you are better off with AVR or ARM chips.
Gravis, i do not why you say this, because you can download the source code for XC compilers, as a example i compiled the XC32 and i use the advanced optimizations for free. Check this
And you have missed the point. The chips that the demo board in the article supports need the XC8 compiler, which is not fully open sourced. The optimizations, without which the xc8 generates almost unusably huge code, are only in the paid for version and the source isn’t available.
Only sources for XC16 (PIC24fxxx) and XC32(PIC32) are available, because those are GCC based. XC8 is not, it was bought from Hitech, I believe, to replace the older Mplab C compiler.
How exactly is not releasing the source of XC8 that has never been GPL’d a violation of the GPL now?
@Javier Bush above started to talk about XC32 which is not really relevant in the context of the article. My point was that the demo board does not support any chips that use XC32 (PIC32s) or XC16 (PIC24s). And only those two compilers are are GCC derived and only there a potential GPL violation could be an issue – but that’s another discussion, not relevant to the article.
They are not violating the GPL. The optimizations are kept in a separate binary which is an allowed exception to the GPL copyleft mechanism.
Unfortunately, I *highly* doubt this is a “legal” path, per Microchip’s license… OTOH, the question of whether they’re using the GPL fairly is… beyond my knowledge; the method described there, for Microchip’s enabling of restrictions on a GPLed gcc does seem a bit questionable… OTOH, how different is it than, say [insert router/phone manufacturer here] not releasing their firmware source-code, and further installing an unreleased root password, when it’s clearly running linux…? (Rather’n flood this thread, I’ll made an addendum to my previous comment to Jan Ciger, here: What was stated above, and there, is based on *my understanding* of the situations discussed; I’m certainly no authority)
Yes i agree is a bit questionable the way that microchip are enabling restrictions on the XC compilers, but as i understand of GPL, they are not doing nothing illegal, Microchip release all the modifications of the GCC including the SHA-256 verification to their proprietary xclm.exe, interesting situation where they gain profit of GPL software without breaking the law.
I might have been living under a rock, but I hear this for the first time. Do you have any more information about this?
The big question had to be “why would you want to use an 8 bit microcontroller?” What does it have over the TI LaunchPad (G2) for instance?
After you’ve developed something with the dev board, you can switch over to some cheaper parts on your own PCB for a custom application. Presumably. And after that, it gets more economical to make large quantities of everything. PICs are some of the best value for a buck on DigiKey or whatever, if you can get over the closed-source compilers.
This board doesn’t appear to support the USB stuff going on with the PIC16F1454/5/9 series PICs. Meh.
Honestly, for this price get two of the ST Micro Discovery boards (they sell for about $11) and thank me later. There is a fully open toolchain (GCC), no crippled demo versions of the compilers (or megabucks for the full toolchains) necessary. The chips are a lot more advanced, with more peripherals and much faster than the piddly 8 bit PICs that fit into this demo board. Also you get a proper IDE of your choice instead of the buggy MPLabX. The best part? The 32bit STM32 ARM series chips can be found for prices comparable with the 8bit PICs. And if you don’t like STM32 series, it is not too hard to move to another vendor – ARMs are pretty much all similar and the toolchain, programmers, etc are the same.
If you are really masochistic and really really really need to deal with the small 8bit PICs, these can be easily prototyped with on a breadboard, this demoboard doesn’t really bring much to the table. You really don’t need a breakout for a DIP package … Just buy the Pickit programmer instead (costs about the same as this board). You will need it anyway should you ever want to use PICs in projects later.
AVRs: – easy to program, Arduino ecosystem is great for quickly hacking something together – few peripherals – expensive
ARMs: – harder to program, much more advanced architecture – tons of peripherals even in the smallest chips – high performance – price from few cents to tens of dollars/euro per piece, depending on capabilities – large choice!
18f midrange PICs (the old 12F and 16F series are really only for masochists, the 24F is reportedly good, as is PIC32): – chore to program, the tooling is terrible – lot of peripherals (more than AVR, less than ARM) – slow core – cheaper than AVR for comparable features – enormous range of parts but often only some are stocked and good luck finding what you need! Every PIC can have multiple versions/revisions over the years, sometimes with significant differences, e.g. PIC18F2550 (old 5V part), PIC18F25j50 (newer 3.3V part), PIC18F25k50 (newer 3.3V part but has LDO built-in, etc.)!
@Jan Ciger, “the old 12F and 16F series are really only for masochists” I’m that kind of masocchists. I even use PIC10F2xx. Do you know that 1 Billion PIC10F2xx have been sold between 2004(introduction year) and 2014. There is a lot of masochist EE out there :-)
“only some are stocked and good luck finding what you need!” Did you try ordering from https://www.microchipdirect.com/. You can even get free samples from them.
I am not disputing that a lot of these parts are being used. PIC10f2xx is a tiny 6 pin device, with something like 16B of RAM … However, for someone starting out a new project I can imagine a much better platform unless your design specifically calls for this type of device.
Yes, I do know about microchipdirect.com, but usually one isn’t buying only the PICs, so one shops at Farnell, Digikey, RS and similar places and consolidates the order to buy most from one vendor. Otherwise the shipping & handling charges go through the roof quickly (I am speaking about mere mortals, not corporate accounts with free overnight shipping and parts packed by naked virgins as a courtesy service). They ship from Thailand by TNT to Europe, so you pay shipping (~7 EUR), VAT and when the package arrives, you get charged customs by TNT on top. Gee, thanks, what a bargain …
BTW, Microchip will not send you samples unless you use corporate e-mail address for registration – they are refusing all common public e-mail services, like GMail.
Maybe they’ve changed their policy lately, but I’ve received free chips for years with a gmail account. Personally, I love the small chips. The last project I did I put an 8 pin IC on a pine wood derby car and was able to create custom lighting patterns to small “headlights” and “taillights”. No external oscillator, capacitors, or even resistors needed. Sure I was driving a few parts out of spec, but with a single IC and a few LED’s I made a pretty impressive looking car.
Its all about scale, Need to build a tablet or a cell phone, ARMs your daddy, but using one from something like you’re speaking about is just silly. Blinking a few LEDs, running a simple 4X20 LCD and a few buttons? PICs are fine for that. I’ve done amazingly complex things on PICs, 12Fs in fact, let alone the 16F and 18F parts. They blow AVRs out of the water in just about every respect because you can find a part that fits your project, rather than the other way around. It drives me nuts to see someone using a 48 pin surface mount part where a simple 8 pin through-hole part would be perfect…
These guys that do stuff on what are supposed to be full fledged eval-boards, hot glued on top of a perf-board and tacking down magnet wire to fit the eval board onto their blinky project crack me up. So locked into the eval-board they had to use in college that they can’t get beyond it and use a part that fits… Fuel up the lambo, just to go to the grocery store a block away….
And yes, I still order FREE samples, no shipping charges from microchip all the time. They are awesome to hobbyists as long as you don’t abuse them. But there again, everyone seems to value “free” over quality these days, So I could see them getting abused.
Having been exploring PIC32, and having dabbled in ARM long long ago, I’ve discovered one of the largest hurdles to be things like header-files (for register-locations), etc. and linker-scripts (for actual location of program-sections in memory, etc)… It seems to me these would also be concerns for ARM cores, and with so many ARMs out there, each of which would require their own headers/ld-files… how does one choose an arbitrary ARM and get it running? Or is it a matter of finding a *specific* ARM chip that already has such support…?
As someone else mentioned, the XC32 compiler is open-source; what’s not is its header-files/linker-scripts… That seems somewhat fair, as probably most chip-manufacturers wouldn’t release that proprietary hard-work… Seems to me, there’s a high probability (especially with so many ARM manufacturers out there) that at least *some* of them would be similarly-hesitant to release that hard-work… which means that those specific chips would be extraordinarily difficult for most early-adopters and/or newbies… at least, until someone writes their own files and open-sources them… …so we’re at the point where: 8-bit PICs are basically their own beast as far as the core, BUT now they’re releasing their free compiler with all that proprietary header/linker stuff… PIC32s are MIPS, so they allegedly don’t even need xc32-gcc, mips-gcc should work fine for them… (again, except for the proprietary header/linker stuff) And, basically, unless I’m totally mistaken, arm-gcc seems like it’d be pretty much the identical path as using mips-gcc for a PIC32, and really not much different than using pic8’s gcc for a pic8 (except for the license restrictions of the free version)… am I missing something in the ARM realm?
The ARM vendors ship their C libraries that provide all those headers and linker scripts, along with examples and documentation. However, the common micros are well documented, so anyone can create their own libraries and scripts, it is not that hard to create these for GCC. There are projects like libopencm3, ChibiOS (which isn’t only for ARM) and others that ship their own implementation.
Then there is the official CMSIS ARM standard that describes stuff that is common for all ARM cores – things like the CPU register, NVIC (interrupt controller), SysTick timer, etc.
Where you could have problems are general ARM CPUs like the ones used for smartphones. Those often contain proprietary bits (e.g. the Broadcom SOC used in Raspberry Pi) and pieces and are hard or impossible to develop for without official toolchains.
ARM microcontroller vendors not only provide linker files. startup files, register definition headers for free but entire SDKs. Go have a look at Freescale’s Kinetis SDK, TI’s Tivaware or STM32’s STM32Cube HAL libraries.
In addition Freescale & STM32 provide a completely free IDE with toolchain, debugger, libraries, configuration tools e.t.c. with no compiler crippling or code size limits. Have a look at: – Freescale’s Kinetis Design Studio – ST’s STM32 Workbench
In addition LPCXpresso is a similar free complete IDE for NXP parts with everything mentioned above. It does have a very generous 256KB code size limit…..still better than compiler crippling in my mind
In addition there’s the crapload of sub $15 dollar boards with onboard debuggers such as the ST Discovery/Nucleo, Freescale Freedom boards, TI Launchpads and NXP’s LPCXpresso boards
The 256kb limit only applies to uploading firmware from within LPCXpresso. You can build firmware larger than that just fine, and then upload it via the built in rs232 bootloader or a different method. You can even attach the debugger after that. I upload new firmware via ethernet, which is a lot faster than using jtag uploading, funny to think that NXP’s limit made me look for an alternative, and I found a better one.
And this is a Good Thing. I cut my teeth on the PicKit1. I’ve now got a Pickit2, but the ‘1 still comes out often when i need to whip up something fast with a PIC12F675.
btw my favourite PIC IDE and C compiler is sourceboost.com (and their great sim plugins – $20)… but I don’t know if it’s still actively maintained.
Tons of Mikro Bus compatible addon boards (100+) at MikroE.com They also offer fantastic compilers that are free up to a certain program size limit. I liked them so much I bought the full version MikroC compilers for Pic32 and ARM based chips. Not cheap ($250) but some of the best money I’ve spent on my circuit hobby. Not for everyone but really amazing for small projects and big ones if you can swing the investment.
As someone who purchased MikroE compilers in the past (for both PIC and dsPIC) in attempt to replace Microchip xc8 and xc16 compilers, don’t make the same mistake
MikroE support for their compiler/IDEs is abysmal. The forums are full of bug reports that are never being actioned, and my god are there some seriously annoying bugs. The compiler also cannot be decoupled from their IDE, and the device support list is seldom updated
…The most annoying bug is that their IDE polls the file being edited tens of times a second, if you store your files on a network share the network becomes saturated, and IDE updates extremely slow.
Undo sometimes results in random lines of code being truncated, the tab options are not applied, and indentation is put to absolute shit, sometimes inserted as spaces, others as tabs, and you wind up having to touch up everything all the freaking time
@mikehackaday Can you measure the spacing on those headers? They look quite a bit like LaunchPad headers…
I used to use PICs…in the 90’s….I them moved to AVRs and now ARM. I briefly revisited the PIC32s because they were the only 32-bit parts that came in a skinny 28-pdip package. But once STM32 parts started adopting the 48-qfn, 20-tssop and 32-qfp packages I had no excuse to remain with the PIC32s. I loved MPLABX and believe that its arguably the best IDE out there at the moment.
I’m not a big fan of Microchip crippling the MIPS-GCC standard optimizations. They can always charge for their own personal additions but the standard optimizations should be left untouched (specifically the -O2, -O3, -Os & -mips16e optimization flags).
One way to get around Microchip’s compiler crippling, is to download Microchip’s Arduino Like platform ;MPIDE, and integrate its toolchain (a PIC32 toolchain) into MPLABX which can be done easily. This toolchain has no crippled optimizations but comes with limited C++ support (not standard C++ libs).
In any case the M4K architecture of the PIC32MX while impressive is old (as old as the ARM7TDMI architecture)and is not optimized (power & real-time) for microcontroller applications of the 21st century. The microaptiv m14ke architecture in the PIC32MZ line is much better but a 200MHz microcontroller with Ethernet and 2MB of flash is overkill for most of my projects.
I wouldn’t touch the PIC16/18 with a 6ft pole they were outdated when the AVR’s came out back in the late 90’s. Even the PIC24s and dsPICs; sure they might be better than thr AVRs/Cortex-M0s in certain use cases, but overall I’d still either choose AVR/Cortex-M0 over them. For low cost DSP, the STM32F3s come with an FPU/Cortex-M4 and it’ll probably be more powerful and power efficient than the PIC24/dsPICs/PIC32MX.
I like the STM32 specifically. You can get many of the Discovery/Nucleo boards with built-in Debuggers/programmers for under $15. You can get the official non-isolated debugger/programmer for $18 or get a clone of it for $3 on ebay. The STM32 peripherals are very well thought out for the most part. They also have Serial and USB (on USB parts) bootloaders so technically no programmer/debugger is necessary. As far as software goes, there’s a software configuration tool called STM32CubeMX that configures all init code for you, it comes standalone or as an Eclipse plugin. I’ve coded STM32s in register-based C and I’ve also used the STM32Cube HAL peripheral libraries. They’re not perfect but I’ve been slowly getting used to them. As far as complete tool sets (IDE, toolchain, debug, program, e.t.c), ST has also finally decided to release a complete development suite for its part called the STM32 Workbench which can be downloaded from the openstm32 community site http://www.openstm32.org/. ARM micros from Freescale, NXP, and TI are also awesome and I’d consider them long before anything from Microchip at this point.
“Gorgeous board” Microchip dev boards are the ugliest ever … please take a look at mikroe.com … a happy customer !
PIC’s are obsolete now, it’s a dated architecture with little memory. The ARM is the future and very low cost too.
PICs are far from obsolete…. They are still very heavily used in mass produced products. And come in hundreds of flavors. And how could they be “outdated” to begin with? Because they are based on a solid architecture that has stability from being around for a while? Like something new makes it better because just it’s new? eh-hmm x’86? C? Spend an outrageous amount of money on an ARM that only comes in miniscule packaging and operates at voltages you are guaranteed to have to level convert for, adding yet more circuitry for power supplies just to blink some lights, which most people are doing on this website…? No thanks. Most people here aren’t building tablets and cellphones from scratch. And to use an ARM on most things below that or Wi-Fi router levels is an absolute waste.
I never run out of memory, because again, there are hundreds of flavors of PIC that I can scale to my needs. Not that they are meant for building super computers with anyway….
And why all this hate for spending money on a programming suite that works? It pays for itself after the first few times you use it. At least that’s always been the case for me and I don’t even do any production level stuff. This generation just wants everything for free, but has no problem bleeding the guy next them dry… Sad.
If I was getting into today for production purposes or as a career, I might choose something else to get started on, but PICs aren’t going away any time soon. And is certain applications, their maturity is a virtue. Not everything is for home consumers….
oh yeah there’s no multiply or divide op-code on the 8-bit PICS and I love worrying about what page I’m on, any RAM left and I could go on about the antique architecture. In my world that’s obsolete, but I can understand some people still love doing things 80’s style. MCU’s are much more powerful nowadays for no cost hit. Example:the NXP LPC812 family wipes the PIC’s butt. Waste is good because a project’s requirements always increase and demand more from the little MCU you spec’d. Times have changed, high level languages abstract the MCU so you don’t need to be in ALU anymore, lol. I would never buy Mchip stock.
So, you are comparing 8-bit PICs and 32-bit ARMs, do you? Apples and oranges. You seem to use the acronym PIC only for 8-bitters, forgetting they are producing 16-bit MCUs and DSPs, as well as 32-bit MCUs for years. Please, tell me how much better is your favorite LPC812 to PIC32MZ2048ECH064, for example. You seem to enjoy unfair comparisons, so you’ll like this one.
Yep, you are right, the MCUs are more powerful nowadays, but you still forget the Microchip isn’t producing only their 90’s stuff.
antique? you do recognize a lot of uses for these are converting analog signals to the digital realm and digital to analog don’t you. these work very well as a sub processor handling analog signals or as a complete all you need solution.
pic 18f for example, analog keyboard synthesizer midi in and out, program memory, 16 character screen display driver, as well as translating the knob and slider movements with ONE micro and a few shift registers and 2 opto isolators. all on a cheap simple do at home etched board or protoboard design.
compare with arm… level shifting everywhere, more expensive power supply or extra power converters added on, much more complex board design or surface to dip adapter needed, have to buy external chips for most everything you interface more expensive chip with higher support and design requirements for getting it running, not to mention complete overkill for the task
The PIC16 from its inception was designed to be ridiculously simple (even simpler than the HC11 & 8051) to facilitate coding in assembly….as was the norm when the architecture was first devised in the 80’s. That’s why it only has 35 assembly instructions, a hardware stack (no proper stack pointer) and a single cpu register. This architecture makes coding in assembly very easy but coding in C very difficult. That’s why there’s no proper GCC ports for the 8-bit PIC16s. PIC18 have a modified PIC16 architecture that make it more C friendly…but since the PIC18 is still based on the PIC16…..its still not truly optimized (like putting lipstick on a pig).
I also happen to believe that for PIC16/PIC18/PIC24F, one instruction takes four cycles i.e.0.25MIPS/MHZ. The Cortex-M0’s exhibit about 0.9MIPS/MHz. Most of the cortex-M0 assembly instructions are 16-bits (thumb inst set) and have a 32-bit wide data path offering an excellent tradeoff between code density, program (code + data) size and instruction set complexity. Cortex-M0 architecture is also very ‘C’ friendly.
Cortex-M0’s can exhibit very low power (Atmels SAM L MCUs consume as little as 35uA/MHz in active mode), can be bought cheaply (under $1 in 1K quantities for many 32K+ Flash devices) and can come with a crapload of peripherals. Many ARM chips come in usable SMD footprints such as 20-tssop/32-lqfp(0.8mm pitch) and 48-qfn among your standard qfp/bga offerings. Some like the LPC812 and LPC1114 even come in DIP packaging. ARM chips also come with many peripherals that are often superior to what you’ll find in PIC16/PIC18 (1MSPS 12-bit ADC for example)
So yeah PIC16/18 architecture is outdated. Can you do cool things with it ? absolutely… but why? Using a PIC16 in 2015 instead of an ARM microcontroller is a kin to trying to transmit data over the AM band instead of using WIFI or Bluetooth. It absolutely can be done and it can be a heck of a lot of fun…..but it is, in most cases not the best tool for the job……
> Using a PIC16 in 2015 instead of an ARM microcontroller is akin to trying to transmit data over the AM band instead of using WIFI or Bluetooth.
No it’s not. If one has an investment of time and money in a particular processor family, and the requirements are modest (as most 8-bit projects are)… why shouldn’t one use them, even if all you cool kids have moved onto something else?
tl;dr – I’m still productive in PICs (as are many other users). PICs are still a reasonable choice, especially the 8-bit class, which is the subject of the article. There’s lots of PIC code on the Internets.
But I’m not totally stuck in my ways. So… what would y’all consider a more current all-around 8-bit MCU that’s widely available, including as DIP?
Just got one after reading your review :) was gonna get a pickit3 programmer at mouser to get started but these board really seems better.
I am a dedicated PIC user… Most dev boards for PIC suck and are expensive. HOWEVER the “Mikroe” “Click” boards are fantastic and well priced. The “Mikroe Bus” is great and the module availability is fantastic and well priced. I love Sparkfun but now a days my money goes to Mikroe because the cater to PIC users.
I can only say good things about Mikroe products. last week i bought more than $1k of their products, because finally someone made GOOD stuff for PICs…hands down best PIC boards on the market.
As for Compilers, I PAID for “CCS Compiler” for both 16F and 18F series PICs… its an awesome compiler of which i can only say good things… I cant even begin to describe how bad the Microchip compilers are… and MPLAB, stick to v8.92 and combined with CCS and you are in for a treat.
I am in no way affiliated with any of the companies involved… just giving credit where its due IMO.
I’m also a long term PIC user, though a very frustrated one. I usually know about options but did not know about Mikroe. Their website looks good! I’ll give it a try.
Within the last two years I’ve tried three different times to move my development under the MPLAB X Harmony Configurator umbrella. What a nightmare.
I landed in this thread again due to a new HaD thread involving MikroE. I had not seen you comment, and probably you wont see mine.
Ive been using this setup for 5 years, and I cant describe how happy i am. I literally sit, and can start coding in 30 seconds.
Regarding toolchains for PIC’s, I can recommend the Proton Development Suite. http://www.protonbasic.co.uk/content.php/141-Proton-Development-Suite which I have used for many years. It is well supported and produces fast and compact code.
Just come across this board. I usually work with the PicKit 2 and program in JAL. Do you have to use MPLAB or does the software allow for programming directly from hex files?
One of the topics that are not being discussed here are the peripherals that are available on the PICs. The new PIC16 and PIC18s have amazing peripherals for smps applications and relatively simple motor control.
Im not a pic fan, (I come from using the C28x dsps) but for the simplicity and power consumption you cant beat the newer PIC16s or dsPICs.
10 Mm Width Pcbconnectors
By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more
Connectors, Cable Assemblies And Wire Harnesses - YYE,http://www.yyecon.com/