• AVR Freaks

Helpful ReplyHot!Is MCHP still developing the PIC32?

Page: < 12345.. > >> Showing page 5 of 10
Author
JPortici
Super Member
  • Total Posts : 1175
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/11 00:37:48 (permalink)
5 (1)
It's too bad we are "invisible" to microchip. Our assembly is done externally by a contractor so for microchip sales our company buys ZERO parts every year. I'm done arguing with the myopia of the sales reps (and in any case we do lower quantity, higher margin products so we would probably NOT qualify for early access even if we bought parts ourselves)
post edited by JPortici - 2020/06/11 00:42:05
#81
Keaton
Junior Member
  • Total Posts : 80
  • Reward points : 0
  • Joined: 2013/04/01 14:34:05
  • Location: Chandler AZ
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/11 01:02:03 (permalink)
3.5 (2)
Jack_M
It's too bad we are "invisible" to microchip. Our assembly is done externally by a contractor so for microchip sales our company buys ZERO parts every year. I'm done arguing with the myopia of the sales reps (and in any case we do lower quantity, higher margin products)


Hey, you are not invisible to us, sorry you think that. Most of us engineers actively and silently read these threads, with the goal to help. What type of problem are having? Do you have a L1 or L2 case number I can look at? do you have your own thread that we can respond to?
 
Our goal at microchip is never to make your life as the customer harder, in fact it is the opposite. We want to make the experience simpler and easier for you (every costumer), we want you to be able to migrate form a lesser performance PIC32 to a high end PIC32 with zero effort (harmony frame work). Yes we created several version of harmony, everything is an attempt to be an improvement the experience. like going from a hand crank model -T to a key start, to a push button start.
#82
JPortici
Super Member
  • Total Posts : 1175
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/11 03:02:02 (permalink)
5 (1)
Invisible is the term used by the sale reps i talked to, not how i feel about it. I understand wanting a minimum order on new parts. I am willing to understand not giving me samples even though you have SAMPLES AVALIABLE written in bold characters everywhere without guaranteeing for a minimum order.. But i am not willing to understand not giving out a datasheet and a timeframe of when mere mortals will be able to buy said parts, so i can at least plan ahead.
This was in the case of the dsPIC33EDV, which briefly appeared then completely disappeared. /rant
 
(Funny you make the analogy on how to start a car: Some manufactures were able to screw up the start button badly. Take Mercedes for example, it's almost impossible to switch the car "on", required for diagnosis. Instead it's either Off (but you can use the radio) or start. Or others like nissan that require the fob to be hovered near the wheel every few times, might as weel kept the good old key (but with the key you can't start the car with your smartphone. I'll leave you think about the stupidity of that). New solution breaks everything or for no real advantage are not solutions)
 
EDIT: I do not want to sound disrespectful of the efforts on the engineering side. Harmony 3 is relatively awesome IMHO, even though i prefer other solutions. I honestly wish some parts of it came standalone, namely the clock configurator and pin assignment window. A small program to do that has been on my to do list since forever, because in the end i always sigh and do the thing by hand
post edited by JPortici - 2020/06/11 04:11:51
#83
Sal Ammoniac
Super Member
  • Total Posts : 234
  • Reward points : 0
  • Joined: 2011/11/27 14:04:14
  • Location: 0
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/11 09:25:29 (permalink)
5 (1)
Keaton
 
Sorry I cannot, as much as I wish I could. PIC32 is coming out with some new and exciting stuff very very soon, you just have to hang in there, it is coming. I promise!

 
Will those new parts be coming with dozens of nasty errata like the PIC32MZ EC did?
 
#84
wdy
Starting Member
  • Total Posts : 34
  • Reward points : 0
  • Joined: 2016/10/05 06:32:30
  • Location: 0
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/25 14:50:21 (permalink)
0
Would be refreshing to welcome new and/or upgraded PIC32 members, at least I am curious enough.
Hopefully the errata will be tolerable (enough). Not that I have seen any relatively error-free MCUs in the last decade - it just gets worse, no matter the company. As if the newer generations of engineers are lacking basic skills and motivation, despite all the tools and processing power they've got on their hands.
Not jumping (hard) on the ARM train is to be applauded, IMHO. RISC-V is also very welcome, being MIPS in new clothes.
 
Tangential - skimmed over SAME70's errata. Meh.
 
@Keaton: thanks for the heads up.
#85
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/26 12:22:25 (permalink)
5 (2)
I personally wouldn't ever more phenomenal cosmic POWAH!!! from these chips, especially since you can get higher-performance parts from ST and whatever Freescale is called now.  A 600MHz Cortex-M7 does sound mighty fine even if it is absolute overkill.
#86
MisterHemi
Super Member
  • Total Posts : 302
  • Reward points : 0
  • Joined: 2017/11/02 12:24:21
  • Location: Commerce, CA USA
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/26 12:56:19 (permalink)
4.5 (2)
jdeguire
I personally wouldn't ever more phenomenal cosmic POWAH!!! from these chips, especially since you can get higher-performance parts from ST and whatever Freescale is called now.  A 600MHz Cortex-M7 does sound mighty fine even if it is absolute overkill.




I don't think 600MHz or higher is overkill, I have applications where I need such speed.
 
TI makes some ARM processors in the 2GHz range if I remember correctly but their IDE for MacOS
doesn't include support for those processors. So I have to make other choices and if Microchip were
to make similar processors that would be a huge help to me. As it is though I may sill have to use an
FPGA for some things.

My configuration:
MacBook Pro (Retina, 15-inch, Mid 2015) with MacOS Mojave (10.14.6) and MPLAB X IDE v5.30
 
Curiosity PIC32MZ EF 1 & 2, PIC24F Curiosity, XPRESS EVAL BOARD (PIC16F18855), SAMA5D3 Xplained and various custom boards.
#87
wdy
Starting Member
  • Total Posts : 34
  • Reward points : 0
  • Joined: 2016/10/05 06:32:30
  • Location: 0
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/26 13:49:26 (permalink)
4 (1)
More effective software and systems approach is also a way to solve problems, not just throwing cores/MHz/power at them. I deal with all kinds of SoCs, MCUs, MPUs and whatnot, and I still like some aspects of the PIC32 family for one reason or another. Not the prettiest, but not bad, either.
 
Definitely would like to finally see some parts with real low consumption, though. The XLP series looks like a flop to me, judging by the errata. The good news is they are not alone, looks like a normal modern trend.
 
And by the way, there are _none_ Cortex-M parts with MMU (by design), so in this regard the MZ/EF is a real leader. Hardly can think of an MCU with MMU. Same goes with the FPU - Cortex-M4F is only single precision, which is ... funny, to say the least. IIRC Cortex-M7 was the first one to have double precision option.
 
Now, if Microchip had more talented engineers working on the silicon, a good bulk of the problems never would've existed. But as I already mentioned, this looks like a modern trend - globally accepted mediocrity. Let's see where all that leads to.
#88
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/26 14:21:03 (permalink)
0
MisterHemi
I don't think 600MHz or higher is overkill, I have applications where I need such speed.



Heh, true enough!  My experience so far where I work is that we've always managed to make use of the increasing compute power these little micros have.  We're using the PIC32MZ on some boards and we wished we had more power for those (we started on those before the Atmel acquisition).  The SAME70 ought to do nicely given that it's almost twice as fast as the MZ despite having only a 50% clock bump (dual issue + branch predictor I'm sure helps a bunch) in my basic tests,  but it's unfortunate that it has less RAM and MUCH slower flash than the MZ.
 
Oh, I have plans for these, yes I do.  Maybe I'll contact my local reps and see if they can spill any beans (though I probably couldn't share that info here, unfortunately).
#89
MisterHemi
Super Member
  • Total Posts : 302
  • Reward points : 0
  • Joined: 2017/11/02 12:24:21
  • Location: Commerce, CA USA
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/26 14:34:17 (permalink)
4.5 (2)
wdy
More effective software and systems approach is also a way to solve problems, not just throwing cores/MHz/power at them. I deal with all kinds of SoCs, MCUs, MPUs and whatnot, and I still like some aspects of the PIC32 family for one reason or another. Not the prettiest, but not bad, either.
 
<Snipped> 
 
Now, if Microchip had more talented engineers working on the silicon, a good bulk of the problems never would've existed. But as I already mentioned, this looks like a modern trend - globally accepted mediocrity. Let's see where all that leads to.




 
True but in some cases you simply need more horsepower, so to speak, for example i'm working on projects for use with audio wavetable synthesis and I need speed and DMA to handle many request and transfers. 

My configuration:
MacBook Pro (Retina, 15-inch, Mid 2015) with MacOS Mojave (10.14.6) and MPLAB X IDE v5.30
 
Curiosity PIC32MZ EF 1 & 2, PIC24F Curiosity, XPRESS EVAL BOARD (PIC16F18855), SAMA5D3 Xplained and various custom boards.
#90
MisterHemi
Super Member
  • Total Posts : 302
  • Reward points : 0
  • Joined: 2017/11/02 12:24:21
  • Location: Commerce, CA USA
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/26 14:38:04 (permalink)
0
jdeguire
MisterHemi
I don't think 600MHz or higher is overkill, I have applications where I need such speed.



Heh, true enough!  My experience so far where I work is that we've always managed to make use of the increasing compute power these little micros have.  We're using the PIC32MZ on some boards and we wished we had more power for those (we started on those before the Atmel acquisition).  The SAME70 ought to do nicely given that it's almost twice as fast as the MZ despite having only a 50% clock bump (dual issue + branch predictor I'm sure helps a bunch) in my basic tests,  but it's unfortunate that it has less RAM and MUCH slower flash than the MZ.
 
Oh, I have plans for these, yes I do.  Maybe I'll contact my local reps and see if they can spill any beans (though I probably couldn't share that info here, unfortunately).




I'm also just getting started with the SAME70 parts too.... I'm not sure yet what i'll use them for but I figured they may be a good alternative to the PIC32MZ. At the moment i'm having issues with USB DMA transfers on the PIC32MZ and i'm now in contact with Microchip support, so hopefully they can give me more information because USB DMA doesn't have much documentation and i'm using my own stack (more efficient) rather than Harmony.
 
If I can get that resolved that would be good, if not then i'll see if it's easier with the SAME70.

My configuration:
MacBook Pro (Retina, 15-inch, Mid 2015) with MacOS Mojave (10.14.6) and MPLAB X IDE v5.30
 
Curiosity PIC32MZ EF 1 & 2, PIC24F Curiosity, XPRESS EVAL BOARD (PIC16F18855), SAMA5D3 Xplained and various custom boards.
#91
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/29 11:25:08 (permalink)
0
MisterHemi
 
I'm also just getting started with the SAME70 parts too.... I'm not sure yet what i'll use them for but I figured they may be a good alternative to the PIC32MZ. At the moment i'm having issues with USB DMA transfers on the PIC32MZ and i'm now in contact with Microchip support, so hopefully they can give me more information because USB DMA doesn't have much documentation and i'm using my own stack (more efficient) rather than Harmony.
 
If I can get that resolved that would be good, if not then i'll see if it's easier with the SAME70.



I may have said this before on this thread, but a big motivation for me to use the Arm parts is that the toolchain is much more up-to-date.  We use C++ and the MIPS toolchain doesn't even fully support C++11, yet the Arm toolchain has C++14.  Still old, but at least less so.  C++11 added nice features to the language, such as variadic templates (a type-safe alternative to stdarg), std::atomic, type traits, and static_assert(), that would be nice even in a micro.
 
I do like the PIC32MZ, though I've used the USB only with Harmony 2.  I have used the DMA with the PMP peripheral to talk to an Epson graphics controller and found it to be slower than I'd like.  I think I get roughly 8MT/s from the DMA to PMP even though the PMP's wait states are configured for about twice that.  I suspect that the bus architecture is the limiting factor as there's probably some time between when the PMP interrupt triggers and when the DMA sees it.  It doesn't help that the PMP has literally zero buffer and so you must transfer one word at a time, which is silly to me.
 
Then again, all of the SAME70 and SAME54 peripherals seem to forgo buffers in favor of lots of DMA channels, so maybe that was the idea with the PMP on the MZ as well.  I haven't tried to use the DMA yet as I really haven't had much time to use the SAME54 and E70, so I can't say how their performance fares.
 
Unfortunately, one issue you may run into on the SAM parts if you decide to try them is the datasheet.  Maybe it's just me, but I find the datasheet more difficult to read than the PIC32 ones.  To me it reads like random paragraphs were just removed, particularly in the introduction sections for each peripheral.  I wonder if Atmel didn't quite the technical writing team that Microchip has.  Either way, I don't care for the documentation for the SAM devices.
#92
MisterHemi
Super Member
  • Total Posts : 302
  • Reward points : 0
  • Joined: 2017/11/02 12:24:21
  • Location: Commerce, CA USA
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/29 22:38:15 (permalink)
0
jdeguire
MisterHemi
 
I'm also just getting started with the SAME70 parts too.... I'm not sure yet what i'll use them for but I figured they may be a good alternative to the PIC32MZ. At the moment i'm having issues with USB DMA transfers on the PIC32MZ and i'm now in contact with Microchip support, so hopefully they can give me more information because USB DMA doesn't have much documentation and i'm using my own stack (more efficient) rather than Harmony.
 
If I can get that resolved that would be good, if not then i'll see if it's easier with the SAME70.



 
Unfortunately, one issue you may run into on the SAM parts if you decide to try them is the datasheet.  Maybe it's just me, but I find the datasheet more difficult to read than the PIC32 ones.  To me it reads like random paragraphs were just removed, particularly in the introduction sections for each peripheral.  I wonder if Atmel didn't quite the technical writing team that Microchip has.  Either way, I don't care for the documentation for the SAM devices.




 
Yes, i've noticed the SAM data sheets are lacking indeed!
 
I've recently started using the SAME70 and trying to figure it out still.

My configuration:
MacBook Pro (Retina, 15-inch, Mid 2015) with MacOS Mojave (10.14.6) and MPLAB X IDE v5.30
 
Curiosity PIC32MZ EF 1 & 2, PIC24F Curiosity, XPRESS EVAL BOARD (PIC16F18855), SAMA5D3 Xplained and various custom boards.
#93
friesen
Super Member
  • Total Posts : 2154
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: online
Re: Is MCHP still developing the PIC32? 2020/06/30 13:05:53 (permalink)
0
wdy
 
And by the way, there are _none_ Cortex-M parts with MMU (by design), so in this regard the MZ/EF is a real leader. Hardly can think of an MCU with MMU. Same goes with the FPU - Cortex-M4F is only single precision, which is ... funny, to say the least. IIRC Cortex-M7 was the first one to have double precision option.




I could never find anything resembling a real MMU in the MZ DA I have used.  Some Cortex-M have MPU, which is probably more useful.
 
If CrossWorks + JLINK would support the PIC32, my ears would perk up.

Erik Friesen
#94
andersm
Super Member
  • Total Posts : 2843
  • Reward points : 0
  • Joined: 2012/10/07 14:57:44
  • Location: 0
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/30 13:58:09 (permalink)
5 (1)
friesenI could never find anything resembling a real MMU in the MZ DA I have used.

The core used in the MZ DA does have a real MMU with a TLB. The default startup code even sets up static mappings for the EBI and SQI memory regions (KSEG2/3 can only be accessed via the MMU).
 
The MPU in Cortex-M3/M4 devices isn't that useful in practice, because of limits in region size and alignment. The newer cores have an improved design.
#95
wdy
Starting Member
  • Total Posts : 34
  • Reward points : 0
  • Joined: 2016/10/05 06:32:30
  • Location: 0
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/06/30 14:09:01 (permalink)
0
Some MCUs (even 8-bitters) have primitive protection of regions, without explicitly calling them MPUs.
Generally, MPUs are just that - MPUs. Nothing in common with MMU.
 
Hell, MZ/EF even has Hypervisor mode, because of the MIPS Warrior core.
#96
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/07/01 08:08:49 (permalink)
4 (1)
Yup, have a look at Section 50 of the PIC32 Reference Manual (or whichever one is the microAptiv CPU section) and check out the CP0 register section.  You access the TLB using the Index register and each entry is made up of the contents of the EntryLo0, EntryLo1, EntryHi, and PageMask registers.  The MIPS MMU does not have a separate page table it looks to in the case of a TLB miss.  It will instead raise the TLB Refill exception and require you to fill the TLB with the correct mappings.
#97
DominusT
Super Member
  • Total Posts : 1456
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: online
Re: Is MCHP still developing the PIC32? 2020/07/16 09:11:35 (permalink)
3 (1)
PIC32MZW1 series Wi-Fi SoC, which is a 200MHz high performance MCU with industrial leading Wi-Fi connectivity and rich peripheral options. PIC32MZW1 has 1MB embedded flash and 256KB SRAM:

https://www.microchip.com/wwwproducts/en/WFI32E01PE
 
#98
pboddie
Junior Member
  • Total Posts : 34
  • Reward points : 0
  • Joined: 2017/05/09 06:22:45
  • Location: 0
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/07/16 09:14:58 (permalink)
0
NorthGuy
Also, if Microchip decides to go to RISC-V, they will provide their own tools. RISC-V is very similar to MIPS, and Microchip's compilers are based on GCC, so this won't be difficult to do.



And as an aside to whoever it was complaining about compilers not keeping up with various language specifications, you can pretty much use a MIPS-targeted GCC from your GNU/Linux distribution to target PIC32, and that is always going to be up-to-date. Otherwise, just configure and build a compiler using Buildroot if you're worried about accidentally generating unsupported instructions.
 
Anyway, in response to those who didn't foresee any RISC-V products from Microchip, I just noticed this board which uses this RISC-V-based SoC/FPGA combination. And sure enough, Microchip burden it with weird software obligations:
 
Microchip
Developing on the PolarFire SoC Icicle kit requires a Libero Silver license, which is free of charge and valid for one year.

 
In case anyone is wondering, Libero has nothing to do with nappies/diapers but is Microchip's proprietary FPGA design suite. The more sustainable route would involve supporting genuinely open - yes, "libre" - toolchains so that people can use whatever works for them and continue to do so indefinitely.
 
Increasing the initial and ongoing costs of developer adoption hardly ever works out for new products and platforms, at least with respect to making them broadly popular. And genuinely open toolchains also don't need temporary lockdown licences, either. Nor USB dongle licences (apparently a thing), licence managers, or licence selectors. All of those things just give people reasons to look elsewhere.
#99
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/07/16 13:15:51 (permalink)
0
pboddie
 
And as an aside to whoever it was complaining about compilers not keeping up with various language specifications, you can pretty much use a MIPS-targeted GCC from your GNU/Linux distribution to target PIC32, and that is always going to be up-to-date. Otherwise, just configure and build a compiler using Buildroot if you're worried about accidentally generating unsupported instructions.

That would be me.  The issue isn't the toolchain itself, but rather the surrounding libraries and header files that rely on extra features that Microchip has added to XC32, such as their extra attributes and the pragmas for setting up the configuration registers on the devices.  To that end, I'm actually working on a code generator that will generate headers, linker scripts, config files, and startup code for devices that do not rely on XC32-specific features.  The eventual goal is to use them with a Clang-based toolchain (I'm also working on an MPLAB X plugin to make it work).  I'm still a very, very long way from having anything useful, though.
 
Page: < 12345.. > >> Showing page 5 of 10
Jump to:
© 2020 APG vNext Commercial Version 4.5