next topic »

[Reply #15 on:]

Where can one find info on developing with MpLAb C32. Is a plug in required for C32?

[Reply #16 on:]

In the Microchip forums of course!

[Reply #17 on:]

Couldn't find one post in the MicroChip forums. I guess if using C32 then any code will have to be written in C as opposed the Arduino C++

[Reply #18 on:]

I guess if using C32 then any code will have to be written in C as opposed the Arduino C++

Yes.  It was C32 you asked about, and mplab.   The existence of Chipkit and MPIDE in no way means that Microchip has decided to throw away their other development tools and make everything arduino C++ compatible!   The chipkit boards are primarily being supported by chipkit.org, digilent, FUBAR Labs, and (lastly) Microchip's educational division.  If you want to use C32 and MPLAB with the Chipkit boards, you're probably expected to populate the ICSP connector and treat the board as a general purpose generic PIC32 development board (which it is, in the same way that an Arduino can be used with AVRStudio as a general purpose AVR board.)

http://chipkit.org/forum/viewtopic.php?f=19&t=25

[Reply #19 on:]

Late 2012 update. chipKIT Max32 v. Arduino Mega 2560. chipKIT is Not really a drop in board. Their company(s) are not aggressive in converting or making a compatible product with compatible libraries or conversions for popular Arduino uses.

I tried a simple application - I took a common RepRap RAMPS 1.4 board for a 3D printer and tried to compile a very popular Arduino firmware - Marlin, on the chipKIT using the supplied MPIDE. It gave errors to libraries which it could not locate. I asked MicroChip and they told me the chipKIT is not avr compatible. Hmmm, I thought they were marketing it from last year as Arduino (avr) compatible. They directly told me that Arduino is 8bit and they were 32bit and not compatible. They went on to tell me pins don't correspond, coding is not the same, voltages are different, etc....  I was left dumb looking at all the advertisement sources - even the packaging - stating 'Arduino Compatible'

So, who is telling the truth? I don't know and do not have the time or care to figure it out or to do the heavy program lifting to re-generate or convert libraries to make a non-compatible environment compatible when I can create awesome things with the Arduino - NOW!

I think they are greedy for market share, money and too lazy. They want YOU to create a market for them, a lazy company, that touts that they can play in the game then tell you all the reasons why they aren't.

MicroChip support told me I'd have to do the conversions and code writing to attach to the RAMPS. I'll just use my Mega 2560.

Thus, if you want to use chipKIT Max32 to be compatible with the Arduino - you can plug your chipKIT board to your Arduino shield and it had better be a 3.3V or else. I was told that I'd have to program pins conversions, hardware libraries etc.... So, as for me, a user, I don't see compatible. If I only had to plug something to an Arduino shield and had to do all the programming I might as well make my own board for my chosen experimental mcu too.....

Hope this saves you some time and answers some questions....

[Reply #20 on:]

The ChipKit is sort-of Arduino-compatible, but not in any sense "AVR-compatible."  What this means is that any library that was written using AVR features or capabilities beyond the things listed on the Arduino "reference" page needs to be re-written to work on the ChipKit.  This includes "little" things like using "port IO" for greater speed, as well as big things like using the AVR timers or SPI port directly rather than through the official facilities.
Some of the more popular libraries HAVE been re-written, but certainly not everything; that would be literally impossible.

[Reply #21 on:]

The ChipKit is sort-of Arduino-compatible, but not in any sense "AVR-compatible."  What this means is that any library that was written using AVR features or capabilities beyond the things listed on the Arduino "reference" page needs to be re-written to work on the ChipKit.  This includes "little" things like using "port IO" for greater speed, as well as big things like using the AVR timers or SPI port directly rather than through the official facilities.
Some of the more popular libraries HAVE been re-written, but certainly not everything; that would be literally impossible.

with my chipkit max32 I can only used 1 sensor i2c

do you know a solution to this PB ?

[Reply #22 on:]

As a hobbyist, those 32-bit chips are overkill, and too complicated to code / manage.

And I think the 8-bit chips (AVR or STM8) or the 16-bit chips (PIC24) are just about right for the hobbyists.

The ChipKit is sort-of Arduino-compatible, but not in any sense "AVR-compatible."

Obviously, at the chip / binary level, they are not compatible. But through the use of libraries, they can be made "source code-compatible", which I think is what those guys are claiming.

TI and Freescale have form factor compatible boards out there too.

[Reply #23 on:]

As a hobbyist, those 32-bit chips are overkill, and too complicated to code / manage.

And I think the 8-bit chips (AVR or STM8) or the 16-bit chips (PIC24) are just about right for the hobbyists.

Kind of depends on what you are doing.
Many 32bit architectures like the pic32/MIPS and ARM cores eliminate all the complexity of having to deal with PROGMEM.
That in itself can greatly simplify things.

Some of the advantages are not 8 bit vs 32 bit but rather an internal register design difference.
For example, the AVR register design lacks set/clear registers, which many of these other processors have.
This can also greatly simplify and speed up the run time code since you no longer have to worry about
atomicity issues. i.e. the AVR requires the use of special bit set/clear instructions or masking interrupts
while the others simply use different registers to perform the operations atomically.

While the gcc compiler on the AVR has a done a good job at optimization to generate bit set/clear instructions
in certain scenarios, these instructions don't work for all registers and only work when everything is constants.
And even when the optimizations generate AVR bit set/clear instructions they can only be used for individual bits.

--- bill

[Reply #24 on:]

@bstott,
I am using the Uno32 and the Diligent folks have done one hell of a good job in making it as compatible as they have.  No, it is not the same, but neither is the Due that also claims to be "Arduino compatible".  I would say the Uno32 and Max32 are closer to being "Adruino compatible" than the Due just because of the voltage levels.  Most of the pins on the Uno32 are 5V tolerant, and the ones that are not have protection to make them 5V tolerant.  I have also run into the issue of boards that work on the Uno do not work on the Uno32 because of interfacing differences.  So for one particular board I tweaked the library which had assembler for both the AVR and PIC chipsets.  One I tweaked some things and remapped the pins it worked fine.  So there are going to be some growing pains for those things, but I also see vendors creating shields just for the Uno32 and Max32.  So that won't be an issue down the road.

BTW, if you don't like the way they did things you have the source code and firmware and you could show them "How to do it right."  I am thinking of walking this path by making a plugin DIP version of the Uno32 that replaces the processor on existing Uno boards.  This would allow people to upgrade their Unos to a 40Mhz processor and if I do the hardware right, work with most shields.  There is already firmware hooks to allow such variants in the IDE from Diligent.  You just basically redefine the pinouts in a config file.  They also already have support for the DIP versions of the chips from Microchip of the processor used in the Uno32.  They just run at 40Mhz, but some have USBOTG.