chipKIT® Development Platform

Inspired by Arduino™

CUI32 / UBW32 support?

Created Mon, 20 Jun 2011 09:14:04 +0000 by Dano

Dano

Mon, 20 Jun 2011 09:14:04 +0000

Hi Mark and All,

I'm new here, but I’d love to get your stuff working with the CUI32 and UBW32 (the forum would not let me put direct links to these as a new user, sorry - just search for them on SparkFun) along side your great ChipKIT boards!

I hope the Arduino community accepts your great MPIDE additions for the PIC32 family to integrate them directly into the official Arduino IDE soon, as it is great to have things working nicely across multiple families of ICs!

We’ve been using Microchip’s standard HID bootloader on the CUI32 by default up until now - along with a great OSX/linux bootloader app written by Phil Burgess (again, link was not allowed by the forum here) or just Microchip's own bootloading app for Windows. Neither the CUI32 nor the UBW32 board have an FTDI chip on them, but rely on PIC32s with built-in USB.

One way I could imagine of adding support the CUI32/UBW32 boards would be to incorporate the proper bootloader apps into MPIDE itself (the one mentioned above for OSX/linux and Microchip's host app for Windows), and then if a user selects CUI32/UBW32 from the boards menu it would use this as the proper bootloader tool. What do you think? (this might be a mess supporting all 3 platforms)...

I guess another (better?) way to go would be to write a new PIC32-resident bootloader compatible with avrdude (stk500v2 protocol), that configures the on-chip USB controller to show up as a CDC device (virtual COMport) instead of using the FTDI chip … this would of course require users to push the reset button on the CUI32/UBW32 boards as discussed here: http://chipkit.org/forum/viewtopic.php?f=17&t=98 which is not a big deal.

Finally, a third option would simply be to support the use of a PICKIT3 programmer, and let people go without a bootloader if selecting this option in the MPIDE boards menu.

Is there some work in any of these directions?

All the best, Dan

Mark

Mon, 20 Jun 2011 12:07:12 +0000

Dan

I like all of these ideas and we have discussed several of them already. Phil has also been in on some of the discussions. The big issue is having to write and maintain a cross platform program to support one or more of these options. It needs to be a program like avrdude that supports one or more of these other protocols.

This is definitely on the the list of things to look into but nothing has been started yet.

Mark

rtestardi

Mon, 20 Jun 2011 14:19:14 +0000

Hi Dan,

(Good to see you here! I'm guessing that's you! :-)

I think your second option may well be the easiest -- just a new bootloader for the CUI32/UBW32.

Basically, I think I can get the USB/CDC/flash code from the StickOS skeleton project to fit in the 12k bootflash -- the only real challenge is to convert the USB code to run polled without interrupts, but that should be pretty easy. Technically, I think we might be able to steal the last 4k of flash as well, but I don't think that is necessary (heck, we can steal a ton if we just pretend to be an Uno32).

A secondary issue for the CUI32 (and rev 1 of the UBW32) will be that the processor header file for the MX440F512H might not match the MX320F128H or MX795F512L exactly, so some peripheral interactions might not work.

Then I think we can support the chipKIT compatible linker files for the application directly. And the same solution would work for CUI32/UBW32, with no host-side changes needed.

-- Rich

Dano

Mon, 20 Jun 2011 15:20:53 +0000

Hi RIch,

Yes, it's me! :-)

It would be great to see if we can squeeze a StickOS skeleton-based project into the 12k bootflash!

One thing that'll make this all easier/smoother is that I've got an updated board design for the CUI32 with Markus Gritsch's help, which uses the PIC32MX795 -it's waiting in the wings here for when SparkFun uses up all their existing stock of PIC32MX440s.

I've also been talking a bit with Brian Schmalz on email, and he mentioned there might be a way of doing auto-reset all in firmware (for convenience of not having to physically hit the reset button every time you want to use the bootloader).

Cheers, Dan

rtestardi

Mon, 20 Jun 2011 16:46:41 +0000

Hi Dan,

Yes, the 795 will help -- is it an H or an L? If it is an H, it might not be as easy. (Your current H should map to the H on the Uno32 fairly well, except for the flash size.)

I'm not sure how the auto-reset in firmware will work -- since you're running an arbitrary application that might not even be using USB (or might be using USB for something completely different)... I do the manual resets of my boards and it's not that much of a pain... The only hard part is that your application can't actually run for 4-10 seconds after the board resets while the stk500v2 bootloader decides whether there is anyone trying to talk to it or not...

Anyway, if I can free up a couple of evenings here I can take a whack at using the skeleton project to start from -- I'm pretty sure it will all fit once 95% of the code is removed! :-)

-- Rich

EmbeddedMan

Mon, 20 Jun 2011 17:39:01 +0000

Yes, I have been planning on supporting the MPIDE on UBW32 at some point. Too many projects right now that I have to get done, so I haven't spent a whole lot of time on it.

However, I did prove an important piece. I took the Microchip USB stack, and built an application with it. I set it to run in INTERRUPT mode. I also slightly edited the USB stack so that when a handshaking line was toggled, it would perform a CPU reset.

Then, in this application, I wrote a while(1). This simulated a user's sketch having crashed, or gone off in the weeds.

I uploaded this application using the standard HID Bootloader, and then showed that I could reset it at any time by toggling the handshaking line from my terminal emulator. On reset, it dumps you into the HID bootloader, which can easily be modified to wait for a couple seconds before continuing. (Got that done too.)

The only place where this won't work is if the code gets hung while interrupts are disabled. Then you'd need to manually reset the board.

There's no reason this same technique can't be used with any other USB stack - nothing special about Microchip's other than I already have it working on the UBW32.

I also have a cross-platform command line PC application to do the bootloading - I've modified mphidflash and the results are here : schmalzhaus d0t com sLash EBB sLash EBB_BL sLash mphidflash_1_4.zip It needs some work on certain Linux distros, but works great otherwise.

(ARGGG! Why can't we use URLs on this forum!!)

Another way to go, as you've already pointed out, is writing a new bootloader that would talk to AVRDUDE over USB (i.e. include the USB stack). I think this would be a great way to go, but I don't have the necessary smarts to complete that task.

*Brian

rtestardi

Mon, 20 Jun 2011 17:53:06 +0000

Hi Brian,

Good to see you here, too! You'll be able to post URLs shortly -- apparently it's just a spam prevention mechanism... It lasted maybe 3 days for me.

I understand what you did, but doesn't that rely on having your code (and ISR) running in the FW that is downloaded by MPIDE? My understanding is that the HEX file downloaded by MPIDE will cover 0x9d000000 and up, and that the exception table is reprogrammed by the MPIDE in the 0x9d000000 page. So you won't be able to intercept the ISR once you have your first HEX file downloaded from MPIDE...

-- Rich

Dano

Mon, 20 Jun 2011 20:31:22 +0000

Hi,

Yes, the 795 will help -- is it an H or an L? If it is an H, it might not be as easy. (Your current H should map to the H on the Uno32 fairly well, except for the flash size.)

It's an H ... the L is covered by Brian's board extremely well, so I stuck with the smaller pin-count part - I know the registers are annoyingly different, but of course the board is a bit smaller overall.

Anyway, if I can free up a couple of evenings here I can take a whack at using the skeleton project to start from -- I'm pretty sure it will all fit once 95% of the code is removed!

That would be awesome, Rich - if you find time to get it working then we can let StickOS sit on top of this bootloader on the new CUI32 (and UBW32 as well possibly ... not sure if you want this by default Brian, but I definitely do! In my eyes it's a hell of a lot more advanced and functional than the "Firmata" firmware that all Arduinos ship with by default), and then people are free to choose their own adventure | poison | magic ;-) If they want to go back to StickOS after using the Arduino IDE for awhile, they just have to upload StickOS again - I have found in many cases that the interactive nature of StickOS really lends itself to students immediate understanding. But they still want to be able to use Arduino - each has its place!

It would be fun for us to make this work on the current iteration of CUI32 boards right now, but in order to make a clean slate for SparkFun I think I'd hold back on having them ship anything that might incorporate a new bootloader until they also update to the new revised board and retire the current one. Otherwise it'll be more difficult to explain/support questions regarding "which bootloader app do I use?" etc...

Cheers, Dan

EmbeddedMan

Mon, 20 Jun 2011 21:29:02 +0000

Hi Brian, I understand what you did, but doesn't that rely on having your code (and ISR) running in the FW that is downloaded by MPIDE? -- Rich

Rich, yes, of course. The idea would be to add to the core ChipKIT libraries the functionality to handle this 'behind the scenes' (and hook into the USART send receive as well, so it all 'just works' for sketches). You can link in different things based upon what board you select, so if you selected the UBW32, you'd get this new code compiled in, along with your sketch. So it would all be part of the 'app' - Arduino 'apps' are composed of the code from the sketch, the C/C++ runtime code, and libraries - both the core libraries that give us all of the nice Arduino functions, but also any libraries that you add in (and call).

*Brian

rtestardi

Mon, 20 Jun 2011 23:03:07 +0000

Oh, maybe I get it -- it's almost like you're creating a self-propagating bootloader... So as long as the injected code doesn't conflict with the user's code, you'd be good to go. You'd need a new linker file, too

Reminds me of the Reflections on Trusting Trust... :-)

I'm not sure I understand how the whole process would start, though... Are you thinking to keep the UBW32 bootloader around, layer a new CDC/ACM stk500v2 bootloader on top of it, and then re-inject a derivative of the new CDC/ACM stk500v2 bootloader with just the "reset changes" back into every compiled sketch (with a new linker file, of course)?

-- Rich

EmbeddedMan

Tue, 21 Jun 2011 00:40:19 +0000

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

rtestardi

Tue, 21 Jun 2011 02:21:32 +0000

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

EmbeddedMan

Tue, 21 Jun 2011 03:22:17 +0000

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

Mark

Tue, 21 Jun 2011 03:30:30 +0000

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.

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

Dano

Tue, 21 Jun 2011 05:54:23 +0000

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:

ChipKIT libraries that are linked into the sketch/application include the Microchip USB stack operating as a CDC device, hooked into the serial library of the ChipKIT core functions,

But without needing this:

set to run in INTERRUPT mode. (so that a while(1) in the sketch doesn't disable the ability to reset the processor)

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

rtestardi

Tue, 21 Jun 2011 07:18:54 +0000

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...

Dano

Tue, 21 Jun 2011 08:50:36 +0000

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 - [url]http://chipkit.org/forum/viewtopic.php?f=17&t=97[/url] - 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): [url]http://code.google.com/p/cui32/[/url]

Dan

rtestardi

Tue, 21 Jun 2011 14:18:29 +0000

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

EmbeddedMan

Tue, 21 Jun 2011 14:39:38 +0000

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. Dan

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

EmbeddedMan

Tue, 21 Jun 2011 14:56:21 +0000

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! :-) -- Rich

Rich,

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

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

if you want to be brave. :-)

*Brian

Dano

Tue, 21 Jun 2011 16:23:21 +0000

Hi Brian,

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.

Sure, people can use mphidflash to put whatever they want on the chip, and yes they could write code that would enumerate as a combo device (in fact it would be advisable to enforce this - always keeping the CDC stack active even if they didn't explicitly want it - if it's really desired to maintain auto-reset capability in all circumstances) ....

But if someone doesn't want to have the PIC32 running the CDC stack (for whatever reason, CPU cycles, etc.), and we allow this, then they would have to resort to pushing the physical reset button (and we would have to have the bootloader wait some seconds to see if any new firmware is sent upon boot anyway then).

One example (now I'm just making up a scenario): Someone who uses the UBW32 or CUI32 as the brains of their robot, and wants to do vision processing on it with e.g., http://centeye.com/products/ardueye-shields-for-arduino/ then they may not want the CDC stack running in order to preserve as many CPU cycles and memory as possible (and CDC would obviously not be necessary since the robot would not be connected to USB while roving around).

Further thoughts?

Dan

EmbeddedMan

Tue, 21 Jun 2011 16:26:36 +0000

Well, guys, this was way easier than I expected

Absolutely amazing. Rich, you are amazing.

The UBW32 (MX460 anyway) is working perfectly under MPIDE (at least as much as expected). With your new bootloader in place, Rich, I was able to upload the following sketch and have it work:

void setup() {
pinMode(26, OUTPUT);
pinMode(27, OUTPUT);
pinMode(28, OUTPUT);
pinMode(29, OUTPUT);
}

void loop() { digitalWrite(26, HIGH); // set the LED on digitalWrite(27, HIGH); // set the LED on digitalWrite(28, HIGH); // set the LED on digitalWrite(29, HIGH); // set the LED on delay(1000); // wait for a second digitalWrite(26, LOW); // set the LED off digitalWrite(27, LOW); // set the LED off digitalWrite(28, LOW); // set the LED off digitalWrite(29, LOW); // set the LED off delay(1000); // wait for a second }

I'm sure the CUI32 will work as well.

Now, to get the UBW32 as a selectable board in MPIDE . . . .

*Brian

EmbeddedMan

Tue, 21 Jun 2011 16:29:09 +0000

One example (now I'm just making up a scenario): Someone who uses the UBW32 or CUI32 as the brains of their robot, and wants to do vision processing on it with e.g., http://centeye.com/products/ardueye-shields-for-arduino/ then they may not want the CDC stack running in order to preserve as many CPU cycles and memory as possible (and CDC would obviously not be necessary since the robot would not be connected to USB while roving around). Dan

Dan,

Exactly. Worst case, the user needs to press the reset button to get their sketch uploaded. Best case, they don't. I don't see why that scheme is a bad thing. Seems pretty OK to me.

However, now that Rich has it working with his bootloader, I'm really not inclined to spend any time getting my vision of things to work. <huge grin>

*Brian

rtestardi

Tue, 21 Jun 2011 16:41:08 +0000

Thanks, Brian!

Now, to get the UBW32 as a selectable board in MPIDE . . . .

OK, so the issue then is what header file from proc should MPIDE be using for the UBW32v1, v2, and CUI32... I think long term it would be ideal if they could use the right ones and have an option for each board under Tools -> Board...

But in the meantime (unless someone can do a more detailed study of the header files), it seems for the UBW32v1 and CUI32, the user should probably select Tools -> Board -> Uno32, and for the UBW32v2, they should select Tools -> Board -> Max32.

Thoughts?

-- Rich

PS We used about 6500 bytes for the bootloader -- I think we can safely go up to 8k without disabling debug functionality of the chip...

Mark

Tue, 21 Jun 2011 16:44:59 +0000

Rich

This is great, and you didnt have to wait for the avrude replacement. Now I need to get a board that works with it so I can test the core files

Can we get "official" permission to include it on our main github site.

Mark

EmbeddedMan

Tue, 21 Jun 2011 17:07:31 +0000

Rich,

Yes, I can add support into MPIDE for CUI32 and UBW32 boards, I think. I understand the header files and config files enough to make this change and propose it to the MPIDE devs.

*Brian

rtestardi

Tue, 21 Jun 2011 17:17:50 +0000

Can we get "official" permission to include it on our main github site.

Sure, assuming you're maintaining it! :-)

Please just let me know if you have to make any fixes to the CDC/ACM or USB code.

It should work for any PIC32 with USBOTG (heck, the same code runs on Freescale MCUs with USBOTG as well :-).

-- Rich

EmbeddedMan

Tue, 21 Jun 2011 17:54:06 +0000

Rich,

Is the USB part of the software you created completely open-source? Did you write it from scratch? Does it do anything other than CDC?

Thanks-

*Brian

rtestardi

Tue, 21 Jun 2011 18:06:42 +0000

Yes, I wrote the underlying USB driver and upper level CDC/ACM function driver from scratch, and they are available freely in the StickOS skeleton project ( http://www.cpustick.com/downloads.htm ).

The USB driver can also run in host mode, but I deleted those #if's from the code in the bootloader project.

I've used the USB driver to implement HID device functions, CDC/ACM device functions, as well as CDC/ACM hosts, PIMA (camera) hosts, and MST (mass storage) hosts which I also layered fat32 on top of.

So the USB code is fairly well tested and exposed (I ran it against 30 different USB flash drives at one point).

-- Rich

PS I implimented all this stuff to be super light-weight compared to what I could find... I'm not sure how much flash a "normal" CDC/ACM and USB driver use, but I've never seen it done in bootflash before (and below the 8k limit, as well!).

rtestardi

Tue, 21 Jun 2011 20:35:09 +0000

PS it looks like if you try to load that project on a system where the pic32-gcc is not at the same path as mine (Windows), you'll have to do some manual Makefile editing. :-(

sh-4.1$ find . -type f | xargs grep -i c:\\\\
./nbproject/Makefile-CUI32.mk:MP_JAVA_PATH=C:\\Program\ Files\\Java\\jre6/bin/
./nbproject/Makefile-CUI32.mk:MP_CC=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-gcc.exe
./nbproject/Makefile-CUI32.mk:MP_AS=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-as.exe
./nbproject/Makefile-CUI32.mk:MP_LD=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-ld.exe
./nbproject/Makefile-CUI32.mk:MP_AR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-ar.exe
./nbproject/Makefile-CUI32.mk:MP_CC_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-CUI32.mk:MP_AS_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-CUI32.mk:MP_LD_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-CUI32.mk:MP_AR_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-default.mk:MP_JAVA_PATH=C:\\Program\ Files\\Java\\jre6/bin/
./nbproject/Makefile-default.mk:MP_CC=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-gcc.exe
./nbproject/Makefile-default.mk:MP_AS=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-as.exe
./nbproject/Makefile-default.mk:MP_LD=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-ld.exe
./nbproject/Makefile-default.mk:MP_AR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-ar.exe
./nbproject/Makefile-default.mk:MP_CC_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-default.mk:MP_AS_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-default.mk:MP_LD_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-default.mk:MP_AR_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-UBW32v1.mk:MP_JAVA_PATH=C:\\Program\ Files\\Java\\jre6/bin/
./nbproject/Makefile-UBW32v1.mk:MP_CC=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-gcc.exe
./nbproject/Makefile-UBW32v1.mk:MP_AS=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-as.exe
./nbproject/Makefile-UBW32v1.mk:MP_LD=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-ld.exe
./nbproject/Makefile-UBW32v1.mk:MP_AR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-ar.exe
./nbproject/Makefile-UBW32v1.mk:MP_CC_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-UBW32v1.mk:MP_AS_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-UBW32v1.mk:MP_LD_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-UBW32v1.mk:MP_AR_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-UBW32v2.mk:MP_JAVA_PATH=C:\\Program\ Files\\Java\\jre6/bin/
./nbproject/Makefile-UBW32v2.mk:MP_CC=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-gcc.exe
./nbproject/Makefile-UBW32v2.mk:MP_AS=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-as.exe
./nbproject/Makefile-UBW32v2.mk:MP_LD=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-ld.exe
./nbproject/Makefile-UBW32v2.mk:MP_AR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin\\pic32-ar.exe
./nbproject/Makefile-UBW32v2.mk:MP_CC_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-UBW32v2.mk:MP_AS_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-UBW32v2.mk:MP_LD_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/Makefile-UBW32v2.mk:MP_AR_DIR=C:\\Program\ Files\\Microchip\\MPLAB\ C32\ Suite\\bin
./nbproject/private/configurations.xml:      &lt;languageToolchainDir&gt;C:\Program Files\Microchip\MPLAB C32 Suite\bin&lt;/languageToolchainDir&gt;
./nbproject/private/configurations.xml:      &lt;languageToolchainDir&gt;C:\Program Files\Microchip\MPLAB C32 Suite\bin&lt;/languageToolchainDir&gt;
./nbproject/private/configurations.xml:      &lt;languageToolchainDir&gt;C:\Program Files\Microchip\MPLAB C32 Suite\bin&lt;/languageToolchainDir&gt;
./nbproject/private/configurations.xml:      &lt;languageToolchainDir&gt;C:\Program Files\Microchip\MPLAB C32 Suite\bin&lt;/languageToolchainDir&gt;
sh-4.1$

rtestardi

Tue, 21 Jun 2011 21:30:43 +0000

And, to save folks from bumping into the same issue, if you need to compile with the free compiler (which does not support -Os), you have some options:

---snip---

Yeah, you need to compile with -Os.

I'm sure there's lots of code in both the ftdi.c and usb.c files that can still be removed, but I did not bother to do that.

The alternative is to just change boot-linkerscript.ld and grow this line:

kseg0_boot_mem       (rx)  : ORIGIN = 0x9FC00490, LENGTH = 0x1B70

You can easily grow it to 0x2B00 (not 0x2B70, or you'll wipe config bits!) by removing these lines:

_DBG_CODE_ADDR           = 0xBFC02000;
...
  debug_exec_mem             : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
...
  .dbg_code _DBG_CODE_ADDR (NOLOAD) :
  {
    . += (DEFINED (_DEBUGGER) ? 0xFF0 : 0x0);
  } &gt; debug_exec_mem

Basically, all you lose is the ability to have the debugger load its (utility) code into the flash -- but folks hardly use debuggers with the bootloaders.

-- Rich

Mark

Wed, 22 Jun 2011 02:25:32 +0000

A secondary issue for the CUI32 (and rev 1 of the UBW32) will be that the processor header file for the MX440F512H might not match the MX320F128H or MX795F512L exactly, so some peripheral interactions might not work.

All of the CPU header files are included in the distribution.

Additional liker files for various CPUs are easy to generate and WILL be included in the distribution as they get written. I added 2 more today.

rtestardi

Thu, 23 Jun 2011 05:19:43 +0000

For folks following this thread, we've had a lot of offline discussions and decided that for boards (like the CUI32 and UBW32) that have a PRG switch, that switch will be used to enter the bootloader on boot if it is pressed, just like always. If the switch is not pressed, the application will run instantly.

For boards that don't have a PRG switch, we'll use the typical 10 second delay, with the understanding that this is quite different than the scenario where an FTDI chip is used, since when the MCU gets reset, it also resets the USB-facing function, and that's visible to the host, and causes device re-enumeration again. It gets tricky here, but it can still work with care (and a bit of lucky timing).

The latest bootloader is on github at:

git clone git@github.com:rtestardi/PIC32-CDC-ACM-Stk500v2-Bootloader.git

Including binary versions for the CUI32 and UBW32 MX460 and MX795. It should build fine on Windows or Mac (at least), with or without -Os support in the compiler (though it is bigger without).

Have fun.

-- Rich

Dano

Thu, 23 Jun 2011 10:10:39 +0000

Rich,

Great stuff! Tusind tak (1000 thanks) from Denmark.

Mark,

One more point that relates to AUTO RESET: I think we're all in agreement that it's desirable but not required on CUI32/UBW32 --- Nonetheless, something that I think WILL be required is adding a new "USBSerial.begin()" and of course corresponding "USBSerial.println()" and related functions for CUI32&UBW32 (and any other PIC32 boards that don't rely upon an FTDI chip). I hope you can help with this... ? I mentioned the idea previously in our discussion briefly: http://chipkit.org/forum/viewtopic.php?p=640#p640

If we don't add "USBSerial" functions for these boards, they will seem pretty 'broken' to most Arduino users, as the standard "Serial.begin()" functions as they are now of course require using the physical RX/TX pins corresponding to one of the PIC32s actual UARTS - For instance, I think we should strive to make File->Examples->Basics->AnalogReadSerial in MPIDE work with UBW32&CUI32 after a simple swap out of the "Serial" stuff with "USBSerial" functions (so it would look like this once the "USBSerial" functions exist):

void setup() {
  USBSerial.begin(9600);
}
void loop() {
  int sensorValue = analogRead(A0);
  USBSerial.println(sensorValue, DEC);
}

The reason I think this relates to AUTO RESET is as follows: Since we'll have to add in these new "USBSerial" functions (that will obviously require a CDC-stack - either Rich's or Microchip's - to be running on the PIC32), we might as well include Brian's neato trick, in which he modified Microchip's CDC-stack to reset the PIC32 via software (without having to push the physical RESET button) any time the handshake line (DTR) is toggled. As long as it is possible to set a flag that tells the PIC32 to enter the bootloader after this soft reset (rather than having to hold down the PROG button - but this shouldn't be a problem, right?), then we've got fully working AUTO RESET for end users as long as they have a USBSerial.begin() function in their setup()!

If they remove the reference to USBSerial.begin() in their sketch, then of course they would have to fall back upon hitting the physical PROG/RESET buttons on the CUI32/UBW32 - this is not a problem in my eyes though...

Unfortunately I'm too swamped to take on much in terms of helping develop this, but I would think we might prefer Rich's CDC-stack over Microchip's as it is much smaller :-)

In any case, I think the bootloader on CUI32/UBW32 should, once entered, stay forever in bootloader mode (no weird timeout periods to get lucky with). In other words, to run their code normally the user needs to either push RESET without holding the PROG button down, or remove power entirely and turn the board on (again without holding PROG down). The two ways in which the bootloader could be entered are: 1) as always, the PIC32 checks to see if the PROG button (RE7 for the CUI32) is held down when it boots, or 2) the PIC32 receives a DTR command while attached to USB and running the modified CDC-stack as described above.

Any other ideas?

Dan

Markus Gritsch

Thu, 23 Jun 2011 12:14:28 +0000

I would strongly vote for the auto-reset behaviour. Fast edit-compile-test cycles are mandatory for environments where no debugger is available. Pressing a switch each time slows the development down a lot. The Teensy also has just a USB microcontroller and manages the auto-reset behaviour very well.

Cheers, Markus

rtestardi

Thu, 23 Jun 2011 14:17:27 +0000

Hi Dan,

I think "USBSerial.begin()" makes total sense and ought to be trivial to do -- we already have a full USB driver in the package, and if someone wants to change it to enable interrupts, you just have to uncomment like three lines and replace one line with a delay (search for "for interrupt use"). Cdcacm_print() does the print magic (and can't be called from an isr). It's really just a question of getting this code into library to link with the user's sketch -- that ought to take just a few minutes for someone familiar with that process. If someone needs help with any of the driver debug, I'm happy to do that.

As for the rest of auto-reset, there are a number of challenges if you want to get it to work just like with an FTDI chip. The challenge you'll have if you want to use the DTR line is that I don't think you get any indication of it in a CDC/ACM protocol... You can, of course, revert back to an FTDI protocol (you can see examples of this in the "old files" archives of the cpustick.com website), with its own issues. Or you could try to get some other indication of "application open" in the CDC/ACM driver -- seems it might likely exist, but I'm not sure what it would be. Basically, you're looking for something at the protocol level that occurs during application open, but not during OS device enumeration -- that could trigger a reset.

Now as far as triggering a reset is concerned, that will cause some issues for the host -- basically, the device file it is using will go away and then come back in a few seconds, so the application will need to do: open, trigger the reset, close, wait a few seconds for the device to re-enumerate, then do re-open, the stk500v2 thing, close -- a bit of a change from what happens today, I fear (which is just open, stk500v2, close). Oh, and there's a catch-22 here -- you don't want the second re-open doing the reset, so I think the reset has to be an explicit request!

As for the teensy, that's a different animal altogether which has its own host-side application and corresponding (likely HID?) driver on the MCU. In that case, it's easy -- you can get indication of "reset requested" because the application explicitly sends the indication (vs us wanting to use the existing implicit indication of COM port open and DTR toggle). And, of course, the teensy application is smart enough to do the magic open, explicit reset, close, wait, re-open, download, close sequence. The trick there, of course, is now you have to maintain the application code for Windows, Mac, and Linux -- not impossible, but not a no-brainer, either.

This "explicit reset" application control model could trivially run on top of CDC/ACM as well -- heck, it could just send a <Ctrl-C> to the MCU -- but it's still new application code on the host. I mean, if we can modify MPIDE/avrdude to open the COM port and send a <Ctrl-C>, then close the COM port (because the handle is going away!), wait for the device to re-enumerate, and then re-open the (new) COM port to do that actual stk500v2 download, that would be a no-brainer (since someone else is maintaining the cross-platform code for us! :-)... But again, we're talking about cross-platform host code here -- I'm not sure what's the right way to get that changed.

-- Rich

Darth Maker

Thu, 23 Jun 2011 15:53:02 +0000

One small note, it should be SerialUSB.begin(), not USBSerial.begin(). There are two reasons: It fits properly with the Serial1, Serial2 convention of having the identity after the word serial, and it also makes the code more portable between these boards and the Leaflabs boards, which use SerialUSB as the instance name for the standard USB communication object. USBSerial is the object type, such that the following code is correct:

USBSerial::begin(int, int)
{...}

USBSerial SerialUSB()

int main()
{
SerialUSB.print("Hello World!");
}

Also, on the Leaflabs boards, SerialUSB.begin(); is called in the init() function, and is always running in the background unless you explicitly turn it off with a call to SerialUSB.end();. Since it is a USB periphrial, and doesn't use a UART port, you don't lose anything by having it always run, unless you need to do extremely tight timing for something. If you do end() SerialUSB, you have to push the reset button to upload code.

robotguy

Thu, 23 Jun 2011 16:24:21 +0000

void setup() {
USBSerial.begin(9600);
}
void loop() {
int sensorValue = analogRead(A0);
USBSerial.println(sensorValue, DEC);
}

This will break a whole lot of Arduino sketches. You need to be fully Arduino compatible at least at the source code level to be able to make the "Arduino compatibility" claim. :shock:

8-Dale

Markus Gritsch

Thu, 23 Jun 2011 17:08:01 +0000

Teensy uses 'Serial' for the Communication over USB and adds a 'Uart' class for real serial interface.

rtestardi

Thu, 23 Jun 2011 17:30:29 +0000

Teensy uses 'Serial' for the Communication over USB and adds a 'Uart' class for real serial interface.

To add a bit more color here, I believe they have a HID device function in their bootloader (since they don't require an INF file on Windows for it). My guess is they leave it running when they transition to the application (since it just takes an ISR), and then they intercept something like the clear_feature to endpoint 0 to trigger their reset. Alternately, they can link USB code into the application and restart the HID device function when the application starts (assuming the linked in USB code handles the clear_feature or other trigger) -- it's a bit messier, but doable.

Their "USBSerial" function (that can be bound to the application) is different -- I believe it requires an INF file on Windows and just implements CDC/ACM (just like we do). It turns out you can implement DTR/RTS here, from "Table 19: Class-Specific Request Codes":

SET_LINE_CODING 20h [USBPSTN1.2] GET_LINE_CODING 21h [USBPSTN1.2]

They tell you how the application can "jump to the bootloader" on command, here (note the bottom of the page -- Triggering Ideas): http://www.pjrc.com/teensy/jump_to_bootloader.html

Again, the bottom line is this is trivial to do if the host application is explicitly coded to trigger the reset, and then close and re-open the device handle -- there's lots of ways it can be done.

Our primary problem is we need to do two opens (an open and then a re-open), and only the first one can trigger a reset -- so that means it has to be explicitly coded on the host.

Hopefully this important point makes sense...

Darth Maker

Fri, 24 Jun 2011 04:15:48 +0000

This will break a whole lot of Arduino sketches. You need to be fully Arduino compatible at least at the source code level to be able to make the "Arduino compatibility" claim. :shock: 8-Dale

Well, this particular thread is about modifying the IDE and adding hardware files for boards that are most definitely not Arduino type boards. However, there is a very simple answer to this: "Serial" can be used as an ailiase for SerialUSB, and the actual UARTs can be referenced starting with "Serial1." Of course, at that point you might as well skip having the SerialUSB at all.

Mark

Fri, 24 Jun 2011 05:17:04 +0000

I have spent a lot of time emailing Rich and Dan and spent 40 minutes this evening on the phone with Rich.

Here is what I am doing.

If the chip supports USB and it is enabled (by board settings)

Serial.xxxx will be the USB port

Serial0.xxxx will be the normal Serial.xxxx

Serial1.xxx will not change etc etc

What there will be in the boards menu

CHIPKIT-MAX32 CHIPKIT-MAX32-USB

When you select the first one, Serial.xxx goes to uart1A as it does now

When you select the 2nd one, Serial.xxx goes to USB and Serial0.xxx goes to uart1A

For boards such as the Pic32-usb-starter kit, you will ALWAYS get USB for Serial.xxx

I hope to have this finished and working tomorrow night, this weekend at the latest.

Mark

Dano

Tue, 13 Sep 2011 13:14:19 +0000

following up on this thread, we are very soon now giving the green light to SeeedStudio on an updated version of the CUI32 board that will be called "CUI32Stem" - as mentioned here: http://www.chipkit.org/forum/viewtopic.php?f=16&t=117&p=2055&hilit=cui32stem#p2055 it is compatible with Seeed's Stem/Twig system ('GROVE' as they call it ... the Twigs are various types of sensors and actuators to plug in).

Since the CUI32Stem has the latest PIC32MX795F512H on it, we'll need to add support for this in MPIDE's 'boards' menu - many thanks for already adding in the original CUI32, this is working great with the stk500v2 bootloader that Rich wrote. So just updating the linker and associated files is all that's necessary - it will ship with both the stk500v2 bootloader installed as well as StickOS (Rich has a CUI32Stem sample board right now to test with), and all should be working smoothly!

Attached is a pic of the CUI32Stem board and a few Twigs as a preview.

Dan

ps. Gene, one of the Twigs Seeed makes is an OLED display described here: http://seeedstudio.com/wiki/Twig_-_OLED_Display_128*64 I haven't checked myself, but I wonder if this might be easily compatible with your OLED library I've seen mentioned elsewhere on the forum? I know it's a bit bigger than the 128x32 pixels of the OLED on the 'Basic I/O Shield', but if by chance it uses a similar driver chip then maybe we can give it a try! Rich has one of the Seeed OLED Twigs at the moment, so you could potentially send him a modified version of your library to throw at it if this looks promising. ;-)

GeneApperson

Tue, 13 Sep 2011 23:28:51 +0000

If you can send me some info on the interface to the OLED display, I can tell you how compatible it would be.

I know that the controller on the OLED display on the Basic I/O Shield can support up to 128x64 displays. If it happens to be the same controller, it should be pretty easy to adapt it. You may evern be able to talk me into doing the work. ;)

Gene

Dano

Wed, 14 Sep 2011 13:26:20 +0000

Hi Gene,

There's more info on Seeed's OLED in this link: http://seeedstudio.com/wiki/Twig_-_OLED_Display_128*64

It uses the SSD1308 as its controller... I wouldn't ask you to look any further if this isn't similar to the controller for the OLED on your Basic I/O shield, but if it is - then I'm sure we'd all appreciate your help (as it's surely easier for you to take a look rather than someone else having to get intimate with all the details of this controller from scratch. ;-)

Cheers, Dan

GeneApperson

Wed, 14 Sep 2011 17:03:39 +0000

The controller on the OLED on the Basic I/O Shield is the SSD1306. It may be similar to the to the SSD1308. I'll look at the data sheet. I'm getting ready to go to the Maker Faire in New York this weekend, so I'm swamped right now. I won't be able to do anything until next week.

Gene

Dano

Wed, 14 Sep 2011 19:50:17 +0000

Hi Gene,

Sounds potentially promising ... and Maker Faire sounds like great fun, I was at the first Bay Area one some years back, but haven't been in awhile since I'm living in Denmark now.

Enjoy your trip!

Cheers, Dan

KM6VV

Wed, 14 Sep 2011 20:45:07 +0000

Dan,

What are all the parts above? some look like they wouldn't need a PCB, others would be handy.

Alan KM6VV

GeneApperson

Wed, 14 Sep 2011 21:19:26 +0000

@Dan

I lied to you about not being able to look at until next week. I just spent a couple of minutes skimming the data sheet. It looks to me like the SSD1306 and SSD1308 are extremely similar. However, the seed studio twig is using an I2C interface and my Basic I/O Shield uses the SPI interface.

The SPI interface is write only, and so my library is written around the notion that the graphics is all done in a memory buffer and then the memory buffer is copied to the display when you want to update the display.

Assuming that when you initialize the seed module, you initialize the column/row mapping to have the same geometry as I am initializing mine with, it would be trivial to modify the graphics code to work. Probably the only thing that would have to change is the code that detects coordinates that are off of the display.

It would be necessary to rewrite the functions that initialize the module and write data to the display since the communications interface is totally different (i2c vs spi), but otherwise it should work. I'm not sure what the update performance would be like. On the Basic I/O shield, it takes about 0.6 ms to update the display.

Gene

Dano

Thu, 15 Sep 2011 19:47:49 +0000

Hi Gene,

Thanks for looking into this - right now I don't have my hands on a Seeed OLED display (I gave the one I had to Rich) ... but I plan on getting another one in the near future. I would guess that the I2C initialization routine must be quite similar to the SPI version in your code...

@Alan, those things pictured around the CUI32Stem sample are an assortment of 'Twigs' from Seeed Studio - see here for a complete list, but they're always adding more... http://seeedstudio.com/wiki/GROVE_System#TWIG_Series

Cheers, Dan

KM6VV

Fri, 16 Sep 2011 00:13:03 +0000

Hi Dan,

Thanks for the URL!

Alan KM6VV

adilinden

Sun, 23 Oct 2011 22:18:55 +0000

I read through the thread, and I am now left with a number of questions. I see that the MPIDE has CUI32 and UBW32 as board options. Probably the most pressing question:

Do I need to install a new bootloader in order to use CUI32 or UBW32 with MPIDE?

rtestardi

Mon, 24 Oct 2011 00:17:53 +0000

If you have the hid bootloader installed (which came by default on both the cui32 and ubw32), then yes, you have to install the new mpide-compatible bootloader, from here: https://github.com/chipKIT32/pic32-Arduino-USB-Bootloader