cheapest pic32 boards?

[JPortici]

Greetings!

I have a hobby project based on a dspic33ev64gs504. the pic is running almost at capacity (because of the damned two excecution cycles when accessing non sfr ram.) and i was wondering to see if and how much it would have benefit me to run it on a pic32.

maybe some, because of a bit of 32 bit math*? maybe none, because again of access time and interrupt latencies? who knows? let's find out.


(*its purpose is generating some waveforms, of which i'd like to increase the bit depth without too much overhead. of course, new hardware is necessary.)


I've never used PIC32, I have yet to decide which family to use.

First i'd like to have a minimal set up to download code to run to and eventually connect stuff to.

I don't want to buy components and lay, etch and solder a board, as I am inclined to use a TQFP part anyway.

Is there an inexpensive PIC32 protooboard? like in the teensy or the stm discovery... regulator, crystal, pic32, breakout pins and at a ridiculously low price ( <10€ )? i've already scanned olimex and ebay, but didn't have any luck, or correct keywords.


I am not considering using arm for this one so don't propose it please.

[ez24]

Microstick II  ?

[JPortici]

33 eur for one, according to MCHP direct

[MK14]

33 eur for one, according to MCHP direct

The higher end PIC32MZ parts, one-off prices are significantly more than 10 Euros each (just for the MCU).
 

Some manufacturer's sell their boards at very low prices, to help sell their parts. But if they don't do that (Microchip don't seem to), then you have to pay much more realistic prices.
Sorry!

But ebay are selling some for about £10.50 each for delivery to the UK (worldwide available).
But I think you get what you pay for and it seems very basic and may not have much documentation etc.

Example (you need to select it in the pull down menu options on the page):
http://www.ebay.co.uk/itm/BV507-PIC32-DIY-Home-Controller-with-OLED-and-Wifi-/311499897975

[MK14]

The cheapest way is probably to just use the (P)DIP 28 pin package versions, on a breadboard, verostrip or similar.
It just needs power and connection to the pic programming lead (ICSP), and maybe slightly more, depending on what you want to do with it etc. The datasheet has simple examples of minimum setups (if I remember correctly).

Total cost about 1 Euro, if you go for the cheapo PIC32MM series.

[voltsandjolts]

I am not considering using arm for this one so don't propose it please.

Awww, where is the fun in that. We could have made this thread a 30 page flame war! 

Maybe Olimex:

https://www.olimex.com/Products/Duino/PIC32/open-source-hardware

[MK14]

I am not considering using arm for this one so don't propose it please.

Awww, where is the fun in that. We could have made this thread a 30 page flame war! 

Maybe Olimex:

https://www.olimex.com/Products/Duino/PIC32/open-source-hardware

That is quite amazing. Doing it for only 9.95 Euros.

https://www.olimex.com/Products/Duino/PIC32/PIC32-PINGUINO-MX220/open-source-hardware

I knew about Olimex ones, but thought they started at about 25 or more Euros.
Good find!

[JPortici]

@MK14 I already saw that (ebay link). looking at the situation i am actually re thinking about spinning my own.

I was more oriented on a MX part though, i don't think i'd need ridiculously high clock speeds, 12bit adc and fpu. I've eyed the PIC32MX330F064H
The errata doesn't seem to affect me.
Only downside i can see from the datasheet, i wished i could push the ADC at higher speed.
I first settled with the dspic33ep64gs for this project because it had five adc cores, and i was using three to sample a total of 24 control voltages at audio rate without too much hassle, but then i ran into the MIPS wall.. effective MIPS cut in half by memory access. Damn your slow ram microchip!!

what the hell, a pic32mx + adapter board + protoboard in the next order

----

Not in the mood for a flame war, been into too many recently


EDIT (after link at olimex): what the hell! i didn't even look in the duino section 
EDIT2: nah. that + icsp adapter cable + vat + shipping... i'll just do my own, sigh.

[forrestc]

I've never used PIC32, I have yet to decide which family to use.

I'm using the PIC32MZ2048EFM100 on a project here.   The part itself is over $10USD in quantity, so it's going to be hard to get a eval board for that part for the price point you're looking for.  However, if you're looking for more performance, you might need to go there.   The MZ has a hardware FPU which does 32 bit floating point math very quickly, and is rated at 415DMIPS.    If you go this way, stay far away from the *EC* parts, they're crap.  I joke that the 'C' must stand for crap, and 'F' (as in the EF parts) stands for 'Fixed'.

I suspect the PIC32MM parts will actually be slower than what you're using.  They're designed for low-power applications, i.e. battery driven.   

The PIC32MX may be fast enough, and there should be some boards out there at a reasonable price point.

I unfortunately tend to buy the fairly expensive microchip ones mainly because it's easier to convince Microchip there's a problem if you can reproduce it on one of their eval boards, so I don't have a good reference for the ultra-low-cost boards.   

I've somehow skipped over the dspics so I don't have a good reference to compare to.  Are you just running out of cpu cycles, or is it memory, or is it something else?   Have you spent some time verifying your math is as optimized as possible?   If you can characterize what type of processing you need to do and how much of it I might be able to tell you if the PIC32MZ would run it.

-forrest

[JPortici]

I'm using the PIC32MZ2048EFM100 on a project here.   The part itself is over $10USD in quantity, so it's going to be hard to get a eval board for that part for the price point you're looking for.  However, if you're looking for more performance, you might need to go there.   The MZ has a hardware FPU which does 32 bit floating point math very quickly, and is rated at 415DMIPS.    If you go this way, stay far away from the *EC* parts, they're crap.  I joke that the 'C' must stand for crap, and 'F' (as in the EF parts) stands for 'Fixed'.

I suspect the PIC32MM parts will actually be slower than what you're using.  They're designed for low-power applications, i.e. battery driven.   

The PIC32MX may be fast enough, and there should be some boards out there at a reasonable price point.

Thank you forrest, i already know the main differences in the three families... and the related problems! The MZ EF still have a pretty scary errata.

As i later said, i think i'm oriented with the MX. don't need the more advanced features, i think, and the simpler things are the better. infact, i plan NOT to use harmony. (of course, i'm not planning to use usb/ethernet/whatever peripherals need a software stack to operate reliably at this time)
 
the MM? I wanted a reason to use them since the moment they came out. Ah, but i can't use them at work due to commercial temperature range only and time for hobby projects is scarce, and i usually want to use more advanced peripherals and core (so i go to dspics).
Also, for this project i need at least a 44 pin device

PIC32MK (MM with connectivity? yes please), PIC32WK (supposedly MX/Z with wireless/wifi) and PIC32MZ DA.. ah when will they be unveiled??

I unfortunately tend to buy the fairly expensive microchip ones mainly because it's easier to convince Microchip there's a problem if you can reproduce it on one of their eval boards, so I don't have a good reference for the ultra-low-cost boards.

true that.

I've somehow skipped over the dspics so I don't have a good reference to compare to.  Are you just running out of cpu cycles, or is it memory, or is it something else?   Have you spent some time verifying your math is as optimized as possible?   If you can characterize what type of processing you need to do and how much of it I might be able to tell you if the PIC32MZ would run it.
-forrest

Well, newer dspics are something you should at least give a look at. I'm talking about the dsPIC33EV family (currently one model only, i think it's the cheapest micro you can find with two hardware SENT peripherals, without having to go for much more expensive cores. Plus, it's five volts. I plan to do great(er) things if they release a bigger chip.. i've run out of ram,timers,pwm,everything and i am considering making a dual-mcu board with this one if necessary) and the dsPIC33EP64GS504 and others from its family. same complaint, run out of flash/ram and stuff.

Anyway, the problem i was having on the dspic is that even though the 33E can achieve 70 MIPS, in practice you are limited by (i suspect*) the memory access time, as per reference manual the MCU need one additional cycle (so 2 or 3-4-5) for any operation that access non SFR ram. Loading/storing a variable? two cycles. using indirect addressing to GP ram? two cycles. Reading flash is slow as hell too.
My firmware surely need a rewriting, i became much better at coding in this last year. it's working but it could be better.. but i'm also in the mood of trying new things

*i suspect that, because this additional instruction cycle is fixed, at every frequency... but it was not necessary on the 33F that can achieve 30 or 40 MIPS, depending on model..

[hans]

If you're doing periodic ADC sampling , have you looked up DMA to automate the peripheral > memory transfers in any meaningful way? Or maybe make a small hardware change to use DMA acceleration on other stuff?
After all, you don't want the CPU to be choked by interrupts anyway. DMA is where these modern chips find their strength.

Interrupt latency and I/O access on 32-bit chips is likely going to be even worse, relatively speaking. In most cases these chips have more registers to push&pop on interrupt, and need to perform read-modify-write operations on any I/O register.

Considering you're using a 70MHz dsPIC versus a 80MHz PIC32MX, I'm not sure if there is a lot of gain to be had. But OTOH I haven't had a case example where I implemented 2 identical pieces of firmware on a dsPIC and PIC32MX, and compared the results. So I'm eager to find out , actually.
Of course the PIC32MX will outperform the dsPIC in math and CPU operations, but then again it also depends a lot how the code is written, if you can use any of the 32-bit math at all and how much compiler can do to optimize it.

I'm also sure the PIC32MX RAM & memory bus is quicker. I think I measured like 10-20MB/s parallel port read/write speed on the PIC32MX at 80MHz, and that wasn't even the limit.
However, if you do read/write that fast the CPU can stall a few cycles from memory arbitration. E.g. if you toggle an I/O pin in a while(1) loop while DMA is reading 20MB/s from the parallel port, you may see some jitter on the GPIO.

FLASH is slow on almost any chip. Most high speed chips use FLASH accelerators/page caching to speed up linear execution. This great until you hit a cache miss and still encounter a slow down. A miss can happen from potentially and jump, like if statement, loop, interrupt and function calls.
I think there was a topic from Dannyf which had a result of Dhrystone benchmarks the community ran across many MCU's and compiler tweaks. It turns out the PIC32MX has a better score/MHz if it ran at 20-30MHz than at 80MHz. This is also visible in the coremarks table, because the highest coremark/MHz is achieved at 30MHz instead of 80MHz.
http://www.eembc.org/benchmark/reports/benchreport.php?bench_scores=1512,1511&suite=CORE
But of course, running a CPU slower won't make it faster in absolute terms.

If you don't want this, pick the PIC32MZ.

[JPortici]

If you're doing periodic ADC sampling , have you looked up DMA to automate the peripheral > memory transfers in any meaningful way? Or maybe make a small hardware change to use DMA acceleration on other stuff?
After all, you don't want the CPU to be choked by interrupts anyway. DMA is where these modern chips find their strength.

I wish. three lines of 8 mux'd sources, so each read need to change the channel AND the mux index. I couldn't think of a way to use the DMA for this.
With a dspic i would either use the three cores of the GS or the 12bit ADC in 4-symultaneous-10bit mode of others, after each read just increment the mux index.

my firmware uses only two interrupts anyway: fast timer that pushes out samples*, acquire adc result, start new conversion. slow timer for user input sampling, debouncing and stuff

*spi interrupt call seems to be broken in GS series. opened a ticket, confirmed, never heard from them again. not shown in errata. oh well, there's LDAC for syncronization.

thanks for reminding me that MX has "dumb" adc in it. thinking again of using costly MZ and new features to justify the wasted horsepower.

[JPortici]

going on planning my board... settled with the PIC32MZ0512EFF064 (want to interconnect boards with can, don't care about krypto)
EVERY pin is assigned to a function, if i wanted it to be used at its full potential (PMP for display, USB, CAN, I2S are all optional stuff at the moment)

I'm not sure if i should already cross that MCU away and use the 100 pin version.

I would already know the answer if i was using a dspic, but in this case I am trusting the datasheet when it says that a pin remap has priority over everything. For example: i don't care about the OTG function on usb so want to remap the USBID pin to a PWM output. should work, right?
and all the GPIOs i'll use are muxed with the PMP address port, which i don't need so if i set up the PMP to use only the data lines i should be able to use the GPIOs, correct?

i tried using harmony to set up the pins. couldn't be able to use it.
why is it so hard to make a program just for pin planning, that is simple to use, like st and nxp do? i have to download and install the 2 and a half GB of crap just to use a pin plannign feature that is very confusing (at least to me)

[Howardlong]

I think if you're already struggling on the 64 pin you should already go to 100 pins. The PPS on these devices is not very orthogonal, and as I'm sure you've found many peripherals are tied to various pins, it's really quite frustrating at times. Some pins have better drive than others too which might be a consideration.

Regarding PMP you can mask out the address bits but for the data bits you either have 8 or 16 bits. Depending on your application, you might find the EBI more suited (it's faster and roughly maps onto the PMP pins) but it still has similar limitations on the data lines.

I avoid Harmony unless I'm using the complex peripherals like USB or ethernet. In that case I use a hybrid combination of Harmony and my own direct SFR access wrapped up in my own API for the other peripherals. Very occasionally I use the PLIB functions rather than direct SFR access where it makes more sense.

Harmony mostly just gets in the way. God knows I've tried to use it, but the overhead of using it is just too much in terms of bugs, learning curve, lack of maintainability with the machine-generated code, and its strait-jacket framework. Everything is such a fight with it!

So in general I start with a boiler plate main.c template for my non-Harmony projects wih PiC32MZ and develop largely outside of Harmony except for manually including the Harmony peripheral library and adding the processor .a file to the project.

Edit: attached my current standard PIC32MZ main.c template which initialises all the standard stuff including prefetch cache, appropriate flash wait states and the interrupt controller, and sets the oscillator to 200MHz using the FRC as its reference, so it should work on any board. There are also all the trap routines which come in handy for debugging. It toggles an LED at 1Hz on RH0 off a timer interrupt. You will need to c:/microchip/harmony/v1_09/framework/ in your include directories, and add the appropriate library (C:\microchip\harmony\v1_09\bin\framework\peripheral\PIC32MZ1024EFH144_peripherals.a in this case). Note that some smaller MZ devices have a bug in the PLIBs that reset non-existent registers so you may get errors relating to that, if so just use the 144 pin libraries in the smaller chip.

EDIT: *** Please see the updated main.c two posts down which fixes a couple of shortcomings of this one.

[JPortici]

much appreciated. your "main.c" would have been my next question, the startup code.

i want to use the pmp just for driving TFTs, so i won't need address bits.. or at least i won't for those i've seen on buydisplay and the like
Argh, board space is tight i hope a 100pin will fit

[Howardlong]

much appreciated. your "main.c" would have been my next question, the startup code.

i want to use the pmp just for driving TFTs, so i won't need address bits.. or at least i won't for those i've seen on buydisplay and the like
Argh, board space is tight i hope a 100pin will fit

I've updated the main.c to cover for the EBI bug in the 100 and 124 pin peripheral.a. This includes specifically identifying each peripheral library you need by uncommenting it appropriately rather than including peripheral.h, and setting a linker flag. You could alternatively enable all of them (except EBI which has the bug) and put them in your own peripheral.h.

In addition I've made reference to the need to use atomic methods in certain places, either using the SFR CLR/SET/INV pseudo registers, or using the PLIB functions.

The code now toggles RF3 (also the USBID pin).

Code: [Select]

// Basic PIC32MZ template

// This requires Harmony to be installed but only the Peripheral Library is used, none of the framework nonsense.
// The CPU is set up to run at 200MHz from the built in FRC, and the wait states, prefetch cache and interrupt controller are all initialised (see CPUInit()).
// All GPIO pins are set to digital outputs, low (see GPIOInit()).
// It toggles the RF3 pin at 1Hz, using a 50Hz interrupt on timer 2.
// The Exception code is optional and is there to help in some debugging circumstances.

// Build with the following non-default settings:
// o Add include dir (Properties/Conf:/XC32/Common include dirs = c:/microchip/harmony/v1_10/framework/)
// o Add appropriate peripheral library (e.g. Properties/Conf:/Libraries/Add Library/Object file = C:\microchip\harmony\v1_10\bin\framework\peripheral\PIC32MZ1024EFH144_peripherals.a)
// o Gcc optimization level 1 or higher (Properties/Categories/Conf:/XC32/xc32-gcc/Optimization/optimization-level = 1)
// o Linker remove unused sections (Properties/Categories/Conf:/XC32/xc32-ld/Remove unused sections = CHECKED)


[JPortici]

quick update

seeing the quest was hopeless i just went on and designed one board that i could already put in use with other sub boards.

though i was unable to route everything to keep size small (for example, pins were assigned to PMP, think 16bit display... I2S, canbus, ..)
I also used this as an excuse to try ALLPCB (very nice result)

Now waiting for mouser delivery later this week...