Microchip just published their USB-MSD Programmer firmware. This open source project allows a board to enumerate as a USB Mass Storage device. Programming is as simple as copying a .hex file to the “drive”.
This code is what’s running on the $10 Xpress board that they released last month which includes a PIC18F25K50 to serve as a PICkit On Board (PKOB) programmer for the actual target micro; a PIC16F18855. In its stock version, the XPRESS-Loader firmware programs any PIC16F188xx chips that have a row size of 32 words. But it should be possible to tweak this package to program any chips that use the 8-bit LVP-ICSP protocol.
Now, this may seem like small potatoes at first look: it requires two microcontrollers on your board and is capable of programming just a small subset of the vast PIC inventory. But in our minds it’s the USB-MSD that is killer since it doesn’t require any software or drivers on the computer side of things. That’s a big invitation for all kinds of hacks. But there should be even more on the way from the Xpress team before too long.
It turns out the microcontroller [Voja Antonic] chose to use on the Hackaday | Belgrade badge is the 25k50. Since hearing about the Xpress board we’ve been talking to some of the PIC engineers and they are exploring a loader that will program onto the same chip. This means device upgrades without special hardware or drivers – perfect for badge hacking at a conference. This can be done with a precompiled hex, one created on MPLAB X, MPLAB Xpress, or others. We’ll keep you updated if we hear more on that part of the project.
We’ve had that on the Smoothieboard for years. I believe mBed had that for even longer. And I know a few other microcontrollers have bootloaders that do this. This seems pretty commonplace. Am I missing something here ?
Now there’s an open source version you can use for PIC.
Oh ok. I was reading the article the wrong way around for some reason.
I read this the same way as you and came to comment about mBed. Except mBed doesn’t require a second micro. Not sure what all the fuss is about.
Well, now that I understand I can help you. The fuss is about : This didn’t exist for Microchip before now.
Yeah, looks like microchip got a crappy USB bootloader at last – only thing that is news is that they didn’t have them before this.
mBed does require a second microcontroller. They call is the mbed interface chip.
Unfortunately, the USB drive is mounted read only on a Mac. Maybe this will allow this to get fixed.
Maybe NTFS? There are ways to mount RW.
I had no issues with the XPRESS board on my macbook pro. I was able to write a hex file to it and have it programmed just fine. What version of OS X are you running?
Whatever the latest is. I spent an hour or so trying various mounting options. Even from the command line, the volume is RO.
Whatever the latest is. I spent an hour or so trying various mount options and techniques. Even from the command line, the mount is RO.
Whatever the latest is. I spent an hour or so trying different mount opts and techniques. Even from command line, the mount only comes up RO.
Nice attempt by Microchip. The ST-Nucleo boards have a single dedicated stm32f103 IC on them that has USB composite firmware enabling it to act as a full blown STLink SWD debugger, a USB to Serial interface (usually connected to a serial port of the target microcontroller), and a USB mass storage programming interface. The portion of the ST Nucleo boards containing that chip can be broken off allowing it to be used with any external STM32 microcontroller target as well as the on-board target.
In addition to this, all STM32 parts have a serial bootloader in ROM and the USB parts also have a dfu USB bootloader in ROM. The combination of these two (cheap debuggers/ programmers & bootloaders in ROM), makes the STM32 the most hardware accessible microcontroller family on the market.
And oh did I mention that they offer a FREE & COMPLETE IDE including an ‘uncrippled GCC toolchain’ (yes I will continue to point this out until something is done about Microchip’s crippling of GCC toolchains) and a debugging software backend that can be used for development? That’s in addition to the mbed libraries and the free mbed online compiler/ide that comes with it.
This official IDE being Eclipse bundled with some plugins and you have to register on theor site to download it?
Nucleo boards are sweet. Switching from AVR, 10$ dev board with builtin on chip debugger is cool option
‘This official IDE being Eclipse’
Where did you get that idea from? I can program ST products from several different compilers, as well as bare metal.
I meant IDE’s, not compilers.
Registering for a free IDE is standard fair. Almost everyone including Atmel does it. Just use a non-business email reserved for this sort of thing and you’ll be good.
The Eclipse based ST workbench is not revolutionary, but it works well for embedded development especially if you don’t want to muck around with makefiles. I prefer to use sublime text + makefiles + STM32Cube or mbed offline libraries. It works great. OpenOCD works well with the STLink on the Nucleos. But I rarely use a debugger when coding…rely mostly on uart printf debugging.
BTW the STM32 System Workbench IDE is not exactly ‘official’. As its developed by a third party (ac6) for ST. http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF261797
Me too (sublime make and printf) just like the good old days .
Atollic truestudio is free to use without registration, works very well with Stm32cubemx and works with the stlink debugger out of the box :) I love it.
Exactly. Everyone had this for years, on nicer chips and better dev boards. PIC have an outdated product line. As far as ARM chips go, it’s not just STM32 either. For example (I’m sure there’s PLENTY of others), TI’s Tiva C have USB DFU/CAN/UART bootloaders in rom as well, using the native USB OTG, 2x CAN and 8x UART. It also has 4x SPI and 4x I2C; 256KB flash, 32KB ram, 12 bit ADC, etc. Tons of processing power as well being an ARM Cortex M4F (with floating point) clocked at 80-120MHz. Tons of nice resources too: same free GCC, an IDE based on eclipse (also compatible with IAR and Keil), TI-RTOS (plenty of other compatible RTOS), CMSIS, Tivaware libs, graphics lib, etc. There’s even a nice course for free on EDX for newcomers.
Hmmm…time to port this to the pic32mx270f256b so I can load programs into sram and run them…muahahaha….oh,,,umm,,ignore the mad scientist laugh. It’s a natural reflex.
Dean Camera’s LUFA, for AVRs, does this since 2013.
http://fourwalledcubicle.com/blog/2013/03/the-new-lufa-bootloader/
http://fourwalledcubicle.com/blog/2013/03/the-new-new-lufa-bootloader/
http://fourwalledcubicle.com/blog/2013/08/lufa-130901-beta-released/
I’ve been a fan of Dean for a long time. Haven’t been back to his website in forever. It’s interesting to see he’s at Blackmagic Design now. That sounds like some awesome hardware to work on (highest-end video equipment for those that haven’t heard of it).
Done this for PIC32, and has been possible for many others within Microchip’s own line. STM32s, atmel’s SAM(also AVRs as pointed above). What Microchip needs to do is release a non-crippled toolchain(which is based on open source gcc and family anyway).
Every time there is topic about Microchip whatever, someone chimes in and complains there is not any free compiler for PIC32. So, again:
There is MIPS GCC around for years (people were using it long time before Microchip started to produce PIC32), as well as chipkit compiler (derived for MIPS GCC), now part of Arduino in a form of plugin – it really can’t be any simpler. There you have it, non-crippled toolchain and simple IDE for beginners with open-sourced chipkit boards.
I use vanilla MIPS GCC to compile Litebsd project, it is under my projects on hackaday.io. It works perfectly under Linux.
Using open source software and open-source and open hardware tools under open-source OS to build and program different open source OS into PIC32. Is there any higher-level of open-ness to achieve?
That an uncrippled toolchain *exists*, does not excuse Microchip for their actions regarding the toolchain. Hell, they still charge for their 8-bit toolchains last time I checked, and those are positively terrible.
I love Microchip’s hardware; they have great peripherals. But I’m moving away from them because they are at their core, not very open source friendly.
Not sure if Atmel will adopt that attitude with the merger, but I hope not.
Last time I used SDCC for 8-bit PIC, it was completely free. I use it for STM8 too, as I’m not aware of any decent non-crippled compiler for it. Anyway, whatever Microchip will do with _their_ toolchain, open source tools are here to stay.
It’s going to be interesting.
Ive never thought of Microchip being a hacker or lone wolf friendly company. $€£1000 out of the gate is enough to kill most independent projects unless you’ve got the money to just throw down. Their dev tools have been a little spotty too. Just as [Dave Jones] about the upgrade from PIC2 to PIC3 Kits.
But Microchip has always had good peripherals.
I’ve never understood why a company in the business of selling hardware charges for the development software to use it. Goddamit even Microsoft now give away the devsoft (VS2015) to use on their (virtual) hardware (Windows). How can Microchip compete when it costs $700+ to get an un-crippled compiler.
In all fairness, *historically* what they were really selling was support, and historically you actually got decent support for what you paid. These days the support you get with the software is a joke. Companies really should give all the dev tools away free (including the optimizer in the case of Microchip compilers) and then sell real support at an appropriate price.
Are there any strings attached to the newly released code? Like their previous USB sources could *not* be included in your own open source repos and downloads, the end user had to first download your code, then the Microchip sources from their site official and then he could try compile it all together providing he got the versions and paths right.
Pic development takes a step towards ease of use and openness? Nah… Just wait until some Goon in Microchip’s Marketing Dept. hears about it.
The key point here, is that the ‘main’ PIC doesn’t have to waste the space for USB (USB MSD has existed on the PIC for ages, but is bulky), The much smaller PIC, is what has the MicroChip code, and (of course) is designed to do nothing except program the chip to which is attached. Makes a very fast way to implement re-programmability, without the space cost and development costs of a bootloader based approach. It’s potentially useful in some environments.
Obvious question is whether new chips be added to those supported?.
As a long term PIC user, the worst thing is their current development environment. Bring back something with the abilities of their older MPLAB, which works (MPLAB-X is really poor), and they would sell a lot more chips.
“PIC engineers and they are exploring a loader that will program onto the same chip”
How did the single chip, usb mass storage bootloader work out?
Did they get it working?