ChipKit uC32

This post maybe better located in 'Bar Sport', but I'll risk the byline of "alternative microcontrollers" here.

I am wondering if anyone has used this or the ChipKit MAX32, and what your impressions are.

http://www.digilentinc.com/Products/Detail.cfm?Prod=CHIPKIT-UC32

I just got one from digikey yesterday [newly in stock with them]. Before anyone says "not Arduino",
I was pleased to discover that the Multiplatform-IDE looks just like the Arduino IDE and back supports
all standard Arduino boards, and I can mount Arduino shields.

Best of all, Digilent has built the bootloader and libraries so that all of the stock Arduino sketches
work unchanged [or am I wrong here?].

I downloaded the 'BlinkWithoutDelay' sketch right off, and it ran first time unchanged. I did try a
Netduino a while back [read as, stayed in the ARM world], but never got past installing the many 100s
of MBytes of 3 different dev tools, so that bogged.

mpide looks like the Arduino IDE because they started with the Arduino/processing IDE code.

I haven't use the Uc32 (didn't know it existed till now) but I have used the Uno32 with mpide quite a bit.
I don't use Windows or Apple stuff so I have no idea how well it works in those environments.

My opinion is that the h/w is a better design than the Due. Cheaper too.
One of the main reasons I like the h/w better is that the chipkit boards use a processor that is 5v tolerant.
This means that many 5v shields will "just work" vs on DUE you have to be careful or
you can blow up your pins.

mpide is nice. I've corrected a few minor issues in their platforms.txt mainly to correct the ARDUINO define.
I recently went through an exercise to get the pic32 core to run using the new Arduino 1.5 IDE
See this thread: chipKIT32/chipKIT-core · Discussions · GitHub

Just be aware that the pic32 core is not up to date with all the last minute changes
the Arduino team threw in going into Arduino 1.0 so view the pic32 more as a 0023 core.
Also keep in mind that because the Arduino core code is so limiting, and slow in some cases,
that many libraries are stepping outside the "Arduino" environment and talking directly to AVR
registers. This makes the code non portable and hence will not work on the chipkit boards.

Having looked extensively at the IDEs, and how they interact with the toolsets
i'd say:
I like mpide better than Arduino pre 1.x IDE or the Arduino 1.0, 1.0.1, or 1.0.2 IDEs
However, I like the way new 1.5 IDE interfaces to the tools better than mpide
The 1.5 IDE is MUCH easier to create/modify a board(s).txt file than on mpide.

Another positive thing for both mpide and Arduino 1.5 IDE is that now you can modify
compiler & linker options all the way down to a per board basis. This allows you to tweak
compile options for things like source level debugging
or even alter the link options to link in the floating point versions
of the xxprintf() code. In the past you could not do this.

I'd also say that both the Arduino team and the mpide folks need to start working
on better separating the IDE from the toolsets and cores.
Moving forward it has the potential to start to become a disaster to have
to rev and release everything when there is a simple change in just one of the cores.
i.e. just because you update DUE code you don't want to have to release an
entire "IDE" package when nothing has changed in the AVR code.

pm me your email address if you want to discuss further or get your chipkit stuff running
under the Arduino 1.5 IDE.

--- bill

Hey Bill, thanks for all the info. I wasn't sure if anyone would respond over here, but I specifically
wanted some feedback from people living in the Arduino world, :-).

I did start looking at the chipkit forum yesterday, and will definitely look at the idea of using the
regular Arduino IDE for the chipkit, I hadn't even imagined it could be done. I'll look at your comments
over there, and respond there with any specific questions, so as to spare the guys here. I realized
that mpide 0023 was compatible with the older Arduino IDE rather than the 1.0 changes, and that
I'd need to check the IDE libraries source for AVR-register calls.

But it was really nice that I didn't have to spend a week messing around with the development
environment just to get a simple sketch to work, more like 5-minutes.

Just one question, did you find a way to do a verbose build with mpide, so you could watch the
download in progress? I tried adding the build.verbose=true statement to preferences.txt but it
didn't do anything [yes, I closed preferences.txt after exiting the IDE].

Again, thanks for your reply. I have a rather large program for my robot on the Duemilanove
where I ran out of program/RAM space that I want to transfer to a larger cpu.

I'd also say that both the Arduino team and the mpide folks need to start working
on better separating the IDE from the toolsets and cores.

Absolutely agree.

However, the arduino targets a different user base and the ability to tweak deeper into the ide (thus more chances to mess it up) may not be as appreciated.

I personally would have loved the arduino being made into a package / libraries so that I can use my own choice of ides to develop code - the arduino ide is a royal pain.

oric_dan(333):
Just one question, did you find a way to do a verbose build with mpide, so you could watch the
downlond in progress?

Just press when you build the sketh.
(It works the same as the pre Arduino 1.x IDE)

Again, thanks for your reply. I have a rather large program for my robot on the Duemilanove
where I ran out of program/RAM space that I want to transfer to a larger cpu.

Not just lots of extra room, but also much faster and no more having to deal with
with Harvard architecture issues.
Just declare things const and you get them in flash and have direct access to them
with pointers, like you would expect in C.

If all you need is more resources and don't need the extra speed or shield capability,
then Teensy ++ 2.0 is a really nice solution and might get you back up and running
even quicker since it is AVR and Paul has ported many of the AVR based libraries to his
boards.

Another cost effective option for more speed and resources if you don't need
shields and can live with 3v i/o is the Teensy 3 board.

--- bill

Bill, thanks for the additional info. I didn't know about the , but have been using
const with the MPLAB C compiler for the PIC24 for quite a while.

In regards the robot program, I started doing it on the PIC24 on one robot and then used the
same basic concept on the Arduino on another robot, but quickly ran out of program/RAM space.
The Teensy would probably be a good choice too, but I am writing the software to be largely
interchangeable on different systems, as long as they all have C, so the uC32 or the Teensy should
make little difference to the code, especially as the uC32 looks very Arduino-like to the coder
[ie, me].

FYI, I am following the ideas laid down in what is called the 3-Layer-Architecture from back in
the 1990s [much more powerful than subsumption]. I actually have several more layers, and
only the "lowest" level layer is hardware-specific, so that's the only thing needs be changed
between different cpu chips, and actually between walking robot and rolling robot. It's all fun.

Have you seen the new pic32 parts in 28 pin dips?
Now that is a nice hobbyist processor.
32 bit processor, 128k of code and 32k of ram at 40mhz, with 5v tolerant pins for about $4

The chipkit guys are working on the Arduino/mpide core right now.

--- bill

Have you seen the new pic32 parts in 28 pin dips?

Thanks for pointing this out, google search shows I'm far behind the times in realizing it. I did know about
the 28-pin ARM previously. I see mouser has them in stock.

I'm likely in the vast minority here, since there seems to be a stampede to 32-bit chips like ARM, but as
someone who's been dealing with 8-bitters for a very longggggggg time, I'm actually not all that enamored
of the 32-bit chips. They're probably great for floating point point, but I'm not so sure for much else.

Looking at my C code in general, I probably use 16-bit integers 95% of the time, with few floats and only the
occasional long, so probably a 16-bit uC who be more efficient. The 32-bitter would probably be ok as long as
it uses RAM efficiently, but if all RAM is treated in 32-bit chunks, then it cannot be good. So I'm not sure about
32-bits. Have to do more research on how RAM is handled.

On looking at the 28-pin PIC32, I see the pinout is identical [including the placement of 5V tolerant pins] to the
PIC24 that I've been using, so would be easy to try it. It does have 32KB RAM and the PIC24 only 8KB, so that
would be a big plus. OTOH, the PIC24 is a 16-bit architecture, which as I said above, seems ideal for the usual
coding form.

Isn't there some kind of 16 bit mode (MIPS16e) in the pic32?

--- bill

Isn't there some kind of 16 bit mode (MIPS16e) in the pic32?

Yes, that's mentioned in the datasheet, which I only downloaded 15-minutes ago, so I haven't
had time to see what it even means. The 28-pin PIC32 does also have remappable peripherals,
which is a really handy feature, so maybe in MIPS16e mode, it's like a PIC24 with 32KB of RAM.
Interesting.

• MIPS16e® code compression

  • 16-bit encoding of 32-bit instructions to
    improve code density
  • Special PC-relative instructions for efficient
    loading of addresses and constants
  • SAVE and RESTORE macro instructions for
    setting up and tearing down stack frames
    within subroutines
  • Improved support for handling 8 and 16-bit data types

The 16e feature is like ARM's "thumb" instructions. Shorter (16bit) instructions, but the data is all still 32bits.

The last time I looked, the ChipKit MPIDE didn't use the short instructions...

For those that are interested in experimenting with the 28 pin versions of the PIC32MX I have created a breadboard layout, ChipKIT BB32, http://chipkit.net/chipkit-bb32/ that works with MPIDE and its Libraries. It forms the basis of a series of esoteric examples, that I am working on on my blog http://caroper.blogspot.com, to highlight features of the ChipKIT that are hard or Impossible to do with the Arduino.

It is also intended to facilitate development and testing of your application in one convenient small footprint and when the application works you just swap out the Device with a blank one (available from Microchip with the Bootloader pre installed) and drop the Programmed Device into your target hardware.

As Bill said, it is a great Hobby Processor, especially now that it comes with a bootloader installed.

Cheers
Chris

Hi Chris, Bill (westfw) just gave a link to your page on the other current Uno32
thread. Your blog pages look good, l was just reading through them last
night. I think you may have Dat and Clk swapped on the ICSP header.

Hi Chris, just wanted to report back. Your blog page was helpful in getting the
PIC32 setup and going. Thanks. I managed to burn the DP32 bootloader into a
blank chip using my PICKit3. I only had a 4-Mhz xtal, so had to change a couple
of configuration DIV settings.

Once I got the hang of how to get the DP32 into bootloader mode, and watching
the USB peripheral go in and out of recognition by the PC [bizarre], things are
working well now. Helpful writeup.

I'm using the PIC32 in my board made for the PIC24, so it's an easy drop-in
upgrade to 32-bits, :-). Now to see if some of the MPIDE/Arduino sketches
and libraries work.

oric_dan:
Hi Chris, Bill (westfw) just gave a link to your page on the other current Uno32
thread. Your blog pages look good, l was just reading through them last
night. I think you may have Dat and Clk swapped on the ICSP header.

Thanks for the heads up on the ICSP pin labels :slight_smile:

I think I will leave it as is now as I have a new and vastly improved design almost ready to go live soon, complete with 2 Board definitions for MPIDE, a choice of 3 bootloaders and Bootloader swapping from inside MPIDE (No need for a PICKit3 to update / replace the Bootloaders).

Cheers
Chris

Chris, this is a picture of the PIC24 pcb that I have the PIC32 currently running in. It has a
lot of the PIC peripherals remapped to specific I/O pins, due to the hardwired cktry on the
board. I'm currently using it with the USB bootloader to get things going, but prefer to use
a UART and FTDI cable. Made to work standalone or as an Arduino shield.

super1.jpg