• AVR Freaks

Helpful ReplyHot!Is MCHP still developing the PIC32?

Page: < 12345.. > >> Showing page 2 of 9
Author
Stefiff
Senior Member
  • Total Posts : 98
  • Reward points : 0
  • Joined: 2012/07/15 15:26:29
  • Location: 0
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/07 02:37:17 (permalink)
0
Yes, that's right. Running the program from RAM is very useful, especially if you are currently saving to flash. The idea that you usually choose a processor that you will use completely. In other words, you will put the maximum load on the processor. If not, you'll just use a weaker processor.
Especially for RAM. If you have 1M in the processor, for example, you will hardly want to use only 300k, for example. But the rest is no longer running at the same CPU speed.
Yesterday I was looking at STM32H7 at 480MHz. The maximum resolution of the display is 1024x768. That's how much I can get from PIC32MZ at 200MHz. In my opinion, the limitation here is the transfer from the RAM, wherever it is, to the display. It has to go through different controllers and buses.
post edited by Stefiff - 2020/05/07 02:46:06
#21
NorthGuy
Super Member
  • Total Posts : 6219
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/07 06:34:41 (permalink)
4.5 (2)
Stefiff
the real maximum speed that is obtained when reading a card and writing in the internal DDR2 of 1MB is about 11-12MB / s. When stored in the internal RAM, the speed rises slightly to 14-15MB / s.



Think about that.
 
The PIC has 200 MHz 16-bit wide DDR2 memory. The theoretical maximum bandwidth is 200 x 2 (for DDR) x 2 (16-bit) = 800 MB/s.
 
When you use DDR2, it decreases your throughput from 15 MB/s to 12 MB/s. 12 MB/s is 1.5% of full 800 MB/s DDR2 bandwidth. How horribly inefficient the DDR2 usage must be to turn it into a bottleneck while utilizing only 1.5% of the bandwidth?
 
 
#22
Stefiff
Senior Member
  • Total Posts : 98
  • Reward points : 0
  • Joined: 2012/07/15 15:26:29
  • Location: 0
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/07 07:27:09 (permalink)
0
This is exactly what I wrote that a real test is when you move some amount of information from the outside to your final destination. It is usually processed there, and then taken outside again. Just then it goes through several buses and modules.
In my opinion, DDR2 is the weak point of the PIC32MZ. But there is something else that has to do with the organization itself. The internal RAM is connected directly to the bus. DDR2 is connected via a controller! It has a dedicated bandwidth for the CPU and GPU. The rest is distributed among the other modules.
800MB/s is for DDR2, not for controller for DDR2.
The maximum resolution according to the GPU documentation is 800x480, and 50MHz clock.
For 24bit RGB this will be 50x 800x480 x3(RGB) x3(layers) = 172MB/s
Choose some value for CPU - 200MHz x4(32bit) /2(read or write)= 400MB/s (In practice, it is much less)
You usually also have some DMA modules running at the moment on the same DDR2.
There's not much left for all the other controllers. I tried turning the GPU on and off, the speed does not change. That is, what is set for CPU and GPU, is not usable for other modules.
#23
marcov
Super Member
  • Total Posts : 282
  • Reward points : 0
  • Joined: 2006/10/08 01:59:40
  • Location: Eindhoven, NL.
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/07 08:44:24 (permalink)
4 (2)
Jack_M
-PIC32MK, the amount of erratas that impact actual performance is just too much.

 
Even with the shaky features enabled I wasn't too impressed. My codebase mostly ran faster on a 70MIPS dspic33e than on a 120MHz mk. I really wonder why they would want to polish that turd.

Also only one shadow register set for speeding up interupts was a bit lame for a motor part.
#24
NKurzman
A Guy on the Net
  • Total Posts : 18850
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Is MCHP still developing the PIC32? 2020/05/07 09:27:21 (permalink)
0
"My codebase"  what if your Code base did more 32 bit math?  Or Floating Point?
Expecting different CPU families to match MHz for Mhz is unrealistic.  poor.And using that MIPS as to single measure of a CPU is poor.
As far as Eratta I am looking for an 80 pin PIC24 with CAN bus.  I see pretty bad Eratta in 3 families.
#25
JPortici
Super Member
  • Total Posts : 1112
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/07 13:46:41 (permalink)
4 (1)
marcov
Jack_M
-PIC32MK, the amount of erratas that impact actual performance is just too much.

 
Even with the shaky features enabled I wasn't too impressed. My codebase mostly ran faster on a 70MIPS dspic33e than on a 120MHz mk. I really wonder why they would want to polish that turd.

Also only one shadow register set for speeding up interupts was a bit lame for a motor part.


 
two USB is still nice and opens up to interesting applications..
also with 4 canbus i always thought they had "gateway" in mind.
 
but i had basically the same experience. i can handle 8 different SENT sensors in software with a dsPIC33EP and i probably could have got to 10 with a CK part if they kept using separate IC/OC modules instead of cramming everything in that stupid SCCP crap. with PIC32 (MZ,MK) and Arm (M4) at full throttle i barely managed three instead, i blamed the much higher latency in interrupts and context save/restore, and lack of a fast division engine
#26
simong123
Lab Member No. 003
  • Total Posts : 1391
  • Reward points : 0
  • Joined: 2012/02/07 18:21:03
  • Location: Future Gadget Lab (UK Branch)
  • Status: online
Re: Is MCHP still developing the PIC32? 2020/05/07 14:30:53 (permalink)
0
JPortici
 with PIC32 (MZ,MK) and Arm (M4) at full throttle i barely managed three instead, i blamed the much higher latency in interrupts and context save/restore, and lack of a fast division engine

The 'MZ should be able to do 16/16 and 32/16 divides in 16 (unsigned) or 18 (signed) clocks, compared to the dsPIC's 16. Also the MDU is a separate pipeline so non-dependant integer ops can be executed in parallel.
Similarly as I mentioned before interrupt latency is ~11clks with ASE enabled.
So whilst I won't deny that dsPIC's could be faster for your application, I don't think the problem lies where you think it does. It may be more of an architecture problem. At least on the 'MZ
#27
jdeguire
Super Member
  • Total Posts : 582
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/07 20:28:15 (permalink)
0
simong123
 
The 'MZ also has auto prologue/epilogue and vector pre-fetch which speed up interrupts greatly. However XC32 doesn't support it natively, so it requires a little messing to get it to work. It reduces latency to ~11clks @200MHz.
You have to enable the feature in CP0 and declare the interrupt functions slightly differently e.g.
void __attribute__((at_vector(_CHANGE_NOTICE_D_VECTOR),naked,nomips16)) CNDInterrupt(void)
{
    .....
    asm volatile("iret");
 
}

Note this is also all-or-nothing, all interrupts must use the extensions, and assumes shadow sets enabled.



You know, I have read about the auto-prologue/epilogue stuff, but I never got around to really looking into it.  Are the shadow registers and auto-prologue combined enough to completely eliminate the context saving (besides FPU registers, of course)?  If so, I might have to dig into that.
 
That said, I do very much appreciate the lack of effort needed by us writing the ISRs to get that on the Cortex-M devices.  They auto-stack the FPU registers, too, if you use the FPU in your ISR, which is nice.
 
Thanks for posting this!
#28
simong123
Lab Member No. 003
  • Total Posts : 1391
  • Reward points : 0
  • Joined: 2012/02/07 18:21:03
  • Location: Future Gadget Lab (UK Branch)
  • Status: online
Re: Is MCHP still developing the PIC32? 2020/05/07 21:44:42 (permalink)
5 (2)
jdeguire
Are the shadow registers and auto-prologue combined enough to completely eliminate the context saving (besides FPU registers, of course)?  If so, I might have to dig into that.

Yes. At least on the 'MZ where there are enough shadow sets.
You just have to configure PRISS and IntCtl Register (CP0Register 12, Select 1)
A bit more tricky on the 'MK if you need more than 1 interrupt level.

typedef union
{
    struct{
    unsigned :5;
    unsigned VS:5;
    unsigned :3;
    unsigned UseKStk:1;
    unsigned APE:1;
    unsigned ClrEXL:1;
    unsigned StkDec:5;
    unsigned ICE:1;
    unsigned PF:1;
    unsigned IPFDC:3;
    unsigned IPPCI:3;
    unsigned IPTI:3;
    };
    unsigned w;
} INTCTL_T;

    PRISS=0x76543210; //Set priss so Shadow Set No. = Priority


    // Configure ASE extensions
    INTCTL_T IntCtl;
    IntCtl.w=_mfc0(12,1);
    IntCtl.PF=1;            // Enable vector pre-fetch
    IntCtl.StkDec=0x4;        // 4 * 4byte words from stack
    IntCtl.ClrEXL=1;        // Clear EXL,ERL,KSU flags
    IntCtl.APE=1;            // Enable auto prologue
    IntCtl.UseKStk=0;        // Use single stack
    IntCtl.ICE=1;            // Interrupt chaining enabled
    _mtc0(12,1,IntCtl.w);





#29
JPortici
Super Member
  • Total Posts : 1112
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/07 23:30:37 (permalink)
0
simong123
JPortici
 with PIC32 (MZ,MK) and Arm (M4) at full throttle i barely managed three instead, i blamed the much higher latency in interrupts and context save/restore, and lack of a fast division engine

The 'MZ should be able to do 16/16 and 32/16 divides in 16 (unsigned) or 18 (signed) clocks, compared to the dsPIC's 16. Also the MDU is a separate pipeline so non-dependant integer ops can be executed in parallel.
Similarly as I mentioned before interrupt latency is ~11clks with ASE enabled.
So whilst I won't deny that dsPIC's could be faster for your application, I don't think the problem lies where you think it does. It may be more of an architecture problem. At least on the 'MZ


dsPIC takes 12 or 6 (in the CK) and while it takes 11 clocks to enter and exit interrupts there is also the business of contex saving :( also calling the functions to manage the sample buffer..
 
Also, my target processor would have been the MK, the MZ does not have the required amount of IC,OC,PWM. As marco pointed out, one single shadow register set, not going to make it.
Also, the real application would have had other stuff to it, obviously, but i always start with the heaviest loads first to see how much margin i have to add features. I didn't mention it before but it also took longer to process the data to assemble a frame and update the error flags (a bunch of divisions and bit checking).
 
Interestingly, i did a smaller SENT gadget (two channels, usb, stuff) with the PIC32MM just to try it. it was fun and easy and got everything done in a couple of days, but ultimately the ADC with missing codes will be the deal breaker :( the cost and complexity of an external ADC will shift everything towards a dsPIC33EP with USB
post edited by JPortici - 2020/05/07 23:38:49
#30
NorthGuy
Super Member
  • Total Posts : 6219
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/08 07:24:31 (permalink)
5 (1)
Jack_M
dsPIC takes 12 or 6 (in the CK) and while it takes 11 clocks to enter and exit interrupts there is also the business of contex saving :( also calling the functions to manage the sample buffer..

 
You may not need the context savings. There are 4 sets of shadow registers (W0 through W14). They are called "alternate working registers" and you can select them through the FALTREG fuse. Or you can switch them pragramatically at will with the "ctxtswp" instruction.
 
The latency could have been improved dramatically. Lots of time is waisted to fetch the interrupt address from the interrupt vector. It is silly. Would be much better to have registers with ISR addresses instead of the flash based IVT table (which also causes lots of problems with bootloaders and such), but some things never change.
 
#31
marcov
Super Member
  • Total Posts : 282
  • Reward points : 0
  • Joined: 2006/10/08 01:59:40
  • Location: Eindhoven, NL.
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/08 09:49:08 (permalink)
0
NKurzman
"My codebase"  what if your Code base did more 32 bit math?  Or Floating Point?

 
It was a MLA based TCP/IP modified for a wiznet W5500 chip to mostly use DMA. Meanwhile I know that the mk has SFR penalities, so in theory (if I still had any hope for the mk), I would have to rebenchmark to isolate the SPI/DMA handling (which is SFR heavy) from the protocol decoding.
 
However the even an optimist couldn't find anything in the numbers that would warrant the effort, so I skipped that. (still kudos to simong123 to even get that far)
 
I meanwhile have the first tests running on the dspicc, and hope to get a first production board this summer. It has higher speed SPI interface and motor controls (QEI is very important for us) that we need.
 
Unfortunately, many other peripherals (CAN, anything related to OC and timers) are incompatible, so conversion will take time.
 

Expecting different CPU families to match MHz for Mhz is unrealistic.  poor.And using that MIPS as to single measure of a CPU is poor.

 
Let's turn that around, in what benchmark did your MK outdo a dspice, other than running a series of NOPs ? 
 

As far as Eratta I am looking for an 80 pin PIC24 with CAN bus.  I see pretty bad Eratta in 3 families.



The mk had an errata for the pcache that invalidated the core ability to be faster than its 40MHz flash. That is *pretty* bad.
 
#32
NKurzman
A Guy on the Net
  • Total Posts : 18850
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Is MCHP still developing the PIC32? 2020/05/08 10:41:01 (permalink)
0
The ECH Had enough serious Errata that they abandoned it.
My point was different ships have different strengths and weaknesses.
Internal buses, peripherals, interrupt speed. Ect. Which may make them better or worse for a specific application.
The pic32 implementation of set and clear registers for the ports. May make it big bang faster than an ARM.
So all that must be taken into account to determine if a chip is suitable for a specific application.

But it appears in general MIPS has lost the battle. ARM seems to be the winner.
Since it appears my next project will be moving from Harmony to Linux. It appears I will be moving to ARM.

The PIC24 series chips I was looking at seem to have serious Core Errata. Still haven’t posted my question yet.
#33
NorthGuy
Super Member
  • Total Posts : 6219
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/08 11:38:03 (permalink)
5 (1)
NKurzman
But it appears in general MIPS has lost the battle. ARM seems to be the winner.



ARM (and MIPS too) has lost its battle in PCs. Then ARM found its way to  the embedded market. IMHO, this is very sad, because the real-time CPUs as in PIC24 are more suitable when it comes to controlling hardware.
 
ARM is doing well in RPi, phones and alike, where higher performance is needed and being real-time is not important. Now it tries to climb from there back to PC market - Google marketing push is very strong. Aapple is likely to join.
 
But if Huawey and alike switch to RISC-V, ARM will lose big time - everything will switch to RISC-V within 10 years or so.
 
MIPS never actually took off except in academic teaching classes.
 
#34
NKurzman
A Guy on the Net
  • Total Posts : 18850
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Is MCHP still developing the PIC32? 2020/05/08 14:26:10 (permalink)
4 (1)
I meant in Embedded.  ARM is the Player in Phones and Tablets too.  But I can't see how it is going to beat AMD /Intel in the PC World. Who knows about RISC-V  Is it so much better that everything get re-written around it.  China choice seems to be political not technological.  But ARM was not the clear winner 20 years ago.  Windows PDAs were MIPS.
I agree with you on the Real time (depending on how Real the time needs to be).
I am thinking of having a PIC24 handle that, while Linux Handles the Display and Network.
#35
NorthGuy
Super Member
  • Total Posts : 6219
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/08 15:13:22 (permalink)
0
NKurzman
But I can't see how it is going to beat AMD /Intel in the PC World.



Very easy. If Mac runs on ARM, then you can run i O S applications directly on it. And such applications can only be bought on the Aapple store, so Mac users get used to buying their apps on the Aapple store. Then all the Mac software get sold on the Aapple store, giving Aapple full control of the software market.
 
I'm sure Microsoft have similar plans. Only they moved too quickly with their Windows 10 and now they have to wait out the backlash to start pushing again. I'm sure ARM Windows laptops play an important role in pushing their agenda - move phone market mentality to PCs.
 
#36
NKurzman
A Guy on the Net
  • Total Posts : 18850
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Is MCHP still developing the PIC32? 2020/05/08 16:11:36 (permalink)
4 (1)
I meant does ARM have the same Desktop Performance as a Power hungry X86.  Microchip had ARM tablets. The X86 sold Better.  They Dropped them.  ARM is better were power is limited.  But what about a Desk top where it isn't?  I have been Avoiding Win10, but I assume it will be on my new Work Laptop.  I guess it will be time to update the Home one too.
Microsoft Tried to use a Desktop Operating System on Tablets and Failed.  Win8 was an attempt to use a Tablet OS on a Desktop.  Also a Fail.  For now there does not seem to be a good way to overlap the two different Products.  Apple has two systems. Hopefully Win10 is better that 8.1
#37
NorthGuy
Super Member
  • Total Posts : 6219
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/08 16:36:03 (permalink)
4.5 (2)
NKurzman
I meant does ARM have the same Desktop Performance as a Power hungry X86.

 
The 64-bit ARM (Aarch64) has floating point and 128-bit SIMD instructions. They're improving over time. The performance is not as good as x86, but power consumption is better. Eventually they will get close to x86.
 
NKurzman
Hopefully Win10 is better that 8.1



This is debatable. W8.1 is OS as the predecessors. W10 is a service - you surrender your PC to Microsoft so that they could use it to provide the service to you.
#38
rbuck
Super Member
  • Total Posts : 354
  • Reward points : 0
  • Joined: 2005/04/28 12:48:11
  • Location: Phoenix, AZ
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/12 09:41:22 (permalink)
5 (2)
The ARM will go down in 2 years

Really? Isn't ARM used in virtually every cell phone in the world? They will all change processors in 2 years?
#39
NorthGuy
Super Member
  • Total Posts : 6219
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Is MCHP still developing the PIC32? 2020/05/12 10:22:58 (permalink)
5 (1)
rbuck
The ARM will go down in 2 years

Really? Isn't ARM used in virtually every cell phone in the world? They will all change processors in 2 years?



I don't know if ARM goes down or not, but Android phones can be switched to RISC-V very quickly. Android is like Java - you just re-compile the run-time and it will run on any CPU. They're now switching from 32-bit ARM to 64-bit ARM and nobody is noticing. Same way, Android can be switched to RISC-V. Even easier because it doesn't involve changing the pointer size - just re-compile the source. If the US government forbids Huawei to use ARM, going to RISC-V is practically the only choice for Huawei and will have to be implemented very quickly.
#40
Page: < 12345.. > >> Showing page 2 of 9
Jump to:
© 2020 APG vNext Commercial Version 4.5