Rich,

No, I don't think I'm explaining something properly.

In my scheme, the stock UBW USB HID bootloader would be the only bootloader on the board. It may have a couple second delay added while it enumerates as HID device, waits for the PC to detect this and then start sending packets, but otherwise just a stock bootloader.

The application would just be a stock ChipKIT sketch, with the Microchip USB stack operating as a CDC device, slightly modified so that a toggle of one of the hardware handshaking lines resets the processor.

That's it.

When the processor resets, the bootloader always goes into bootloader mode, enumerates as HID, waits for a bit, then times out and starts running the sketch if the PC doesn't send it anything interesting.

The ChipKIT libraries that are linked into the sketch/application include the USB stack, hooked into the serial library of the ChipKIT core functions, set to run in INTERRUPT mode. (so that a while(1) in the sketch doesn't disable the ability to reset the processor)

Nothing too radical. But if it works, and is integrated properly to MPIDE, then we can have (almost) complete feature-parity with the ChipKIT boards without the FTDI chip.

*Brian

Now I don't think I get it again!

So where is the stk500v2 protocol interpreted?

Or are you saying MPIDE doesn't download bits with that protocol for UBW32?

-- Rich

_________________
Embedded Systems Made Easy: http://www.cpustick.com .....

Rich,

That's just it - it uses the Microchip USB HID bootloader. It's not custom written - it does not talk to avrdude. The protocol is the Microchip USB HID protocol, just like on the current UBW32.

MPIDE calls mphidflash rather than avrdude when it is time to bootload a new sketch. It's just a different command line tool, that's all.

Or, you could change avrdude to take the HEX file and use the Microchip USB HID bootloader protocol to talk to the UBW32, and then it _would_ be avrdude. Either way would work.

That's _my_ plan. But there are tons of ways to skin this cat.

Another way (as previously suggested) is to write a custom bootloader app on the PIC32 side that would understand avrdude protocol (much like the current serial based ChipKIT bootloader) but over USB.

*Brian

This is on the "to-do" list for MPIDE, that is support for downloaders other than avrdude, once this is done, then any command line downloader can be used. It is IMPORTANT that anyone thinking about writing/modifying such a program MUST remember cross platform (mac/win/linux).

Mark

Hi Brian,

Sorry, but I'd really argue against the mphidflash approach you've described ... I do understand the reasoning, but it really limits the end user to only being able to use the USB as a virtual COMport.

While I know none of the chipKIT boards come with a true (non-FTDI) USB connector at the moment (a USB "shield" is coming out this summer for the chipKIT max32 but never for the uno32 I guess), we surely want to be able to do all the tricks this shield will enable for the max32 on our UBW32 and CUI32 boards.

So instead, I would recommend only doing the following if a "USBSerial.begin(9600)" (extrapolated from the standard Arduino "Serial.begin" but specifically aimed at the PIC32's built-in USB) is found in the user's Arduino sketch:

But without needing this:

There would really be no need to make this modification to the Microchip USB stack (so that a toggle of one of the hardware handshaking lines resets the processor) in this scenario, as certain user sketches may disable interrupts anyway.

I do realize that I'm suggesting we go without auto-reset here, but why should we not allow people to utilize the full hardware functionality of the CUI32/UBW32 via MPIDE? I would much prefer people to be limited only by the hardware design rather than such decisions made for them in the software end of things...

What do we all think?

Dan

Well, guys, this was *way* easier than I expected -- partly because I had Mark's bootloader to start with, and partly because MPLAB X just works (boy, what a nice surprise!)... I just ripped everything out of the skeleton project (including all the #if's for the other MCUs!), made the USB driver poll the isr with a call from main() (one line of code change), and then added in the bootloader -- I believe it works. I tested both with avrdude and mpide downloading to my USB Starter Kit. Basically, I used a 10 second delay (like Mark uses for the non-chipKIT boards) and we blink RE0 (for both the CUI32 and UBW32). You have those 10 seconds to get the avrdude or mpide upload started, or else the application (if it exists) will be run. You can see basically all the new code in cpustick.c (sorry, I didn't rename the project files). I didn't have the guts to reprogram my UBW32v1, UBW32v2, or CUI32 -- but if you guys point me to the original bootloader files so I can go back, I can test that tomorrow night. Heck, I'll even get to sleep tonite and be chipper for work in the AM!

See the attached (MPLAB X) package. [ Please note the attached package is now quite dated -- just pull the latest from github.com ]

-- Rich

PS I put this up on github at git@github.com:rtestardi/PIC32-CDC-ACM-Stk500v2-Bootloader.git -- I've never done a public repository before, so you guys can let me know if you can get to it... I hope not just anybody can push...

_________________
Embedded Systems Made Easy: http://www.cpustick.com .....

Rich,

Wow, this is great!!! I'm going to try to find time later today and test it on a CUI32.

This will make CUI32 & UBW32 really ambidextrous, with both Arduino (the language is actually called "Wiring", right?) and StickOS BASIC! And come to think of it, it's even more flexible - as what you discovered here, Rich - http://chipkit.org/forum/viewtopic.php?f=17&t=97 - should also work fine to upload MPLAB/X hex files as compiled from standard C code, for example using Microchip's Application Libraries ( http://www.microchip.com/MAL/ - I see they've finally posted beta versions of the MAL for OS X and Linux now)... though I suppose most users who wish to write code in MPLAB/X would also have their own PICKIT3.

FYI, the HID bootloader for the CUI32 (standard MPLAB for Windows project, not MPLABX) is on the google code site (browse to source/trunk/firmware, or standard svn checkout also works of course):
http://code.google.com/p/cui32/

Dan

The other trick is to allow folks to go back and forth without a pickit... It will just take two more versions of StickOS (MPLAB X configurations are great -- this would have been unmanageable otherwise!) -- one to allow the "upgrade" command to work on the hidbl bits, which will allow you to upgrade the bootloader itself to the avrdude bootloader with a hex file, and one to actually run under the avrdude bootloader (and the "upgrade" command will work there, too, so you can go back to the hidbl bootloader with another hex file)... We can think about this stuff next week if you guys have some success with the avrdude bootloader.

-- Rich

_________________
Embedded Systems Made Easy: http://www.cpustick.com .....

Dan,

I don't follow this - why would it limit us to only CDC? Why couldn't you just enumerate as a combination device - CDC + HID, CDC + Mass Storage, etc? People have done that before with the Microchip stack - in fact, MAL has examples of this all ready to go.

And why does using mphidflash prevent you from doing whatever you want with the application side? They are completely decoupled - you can use the bootloader (and mphidflash) no matter what you do on the app side.

*Brian

Rich,

The UBW32 bootloader hex file (for MX460) is here http://schmalzhaus.com/UBW32/FW/HIDBoot ... _MX460.hex

And the UBW32 bootloader hex file (for MX795) is here : http://schmalzhaus.com/UBW32/FW/HIDBoot ... _MX795.hex

if you want to be brave.

*Brian