Helpful ReplyHot!Future of PIC32

Page: < 12345 > Showing page 2 of 5
Author
Howard Long
Super Member
  • Total Posts : 613
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: online
Re: Future of PIC32 2018/12/31 07:44:55 (permalink) ☄ Helpfulby stephaneC 2019/01/02 03:11:40
4.86 (7)
Brane313
What's so wrong with PIC32MZ then ?

 
Harmony.
 
 
#21
crosland
Super Member
  • Total Posts : 1524
  • Reward points : 0
  • Joined: 2005/05/10 10:55:05
  • Location: Bucks, UK
  • Status: offline
Re: Future of PIC32 2019/01/04 01:22:03 (permalink)
0
Interesting article about the future of the MIPS architecture https://www.eejournal.com...-turns-another-corner/
#22
Brane313
Starting Member
  • Total Posts : 46
  • Reward points : 0
  • Joined: 2018/06/16 01:23:47
  • Location: 0
  • Status: offline
Re: Future of PIC32 2019/01/04 01:35:52 (permalink)
0
To sum it up:
 
- MIPS has a problem
- RISC-V is too similar and it's free
- OTOH MIPS has quite a few cores already and good headstart
 
I still think RISC-V is the future, once it crosses some significant treshold- for example, when we see commercial parts anywhere. Once RISC-V starts humming, there is no good reason to be working on something so similar ( MIPS), which pulls in work on toolchain, IDE etctec.
 
Methinks MC would be wise to take good long look into RISC-V direction. It could solve many problems at once...
 
 
 
 
 
 
#23
JPortici
Super Member
  • Total Posts : 553
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: Future of PIC32 2019/01/04 02:06:34 (permalink)
0
There are already some RISC-V chips out there, there is already GCC and ADA support for what i'm concerned, probably other languages soon. Mirochip's microsemi is going to put out SOCs with FPGA+RISC-V but those won't be MCU-like parts of course
#24
Brane313
Starting Member
  • Total Posts : 46
  • Reward points : 0
  • Joined: 2018/06/16 01:23:47
  • Location: 0
  • Status: offline
Re: Future of PIC32 2019/01/04 05:14:53 (permalink)
0
Those chips are more  for experimenters, special apps and demonstration devboards more than anything else.
 
WRT to MIcrosemi FPGAs, yes, but they'l just use RISC-V core as a soft macro, not hard structures.
 
Difference being, it won't be much different than you implemmenting it yourself in Verilog etc, it'll basically be just packaged nicer and available with precompiled toolchain etc...
#25
Brane313
Starting Member
  • Total Posts : 46
  • Reward points : 0
  • Joined: 2018/06/16 01:23:47
  • Location: 0
  • Status: offline
Re: Future of PIC32 2019/01/04 05:18:33 (permalink)
5 (1)
I've found simple implementation and started to toy with it on Lattice's MachXO2-7000.
 
Even much smaller FPGA would eb able to carry it at decent speed and still be able to host quite rich bunch of peripherals. Mine should run at some 50MHz easily. I'm not sure how many waitstates would be forced by internal FLASH, but access to internal RAM should run like lighning. Not to mention that I could easily run the code from external NOR FLASH ( of BIOS chips kind etc)....
 
 
#26
Brane313
Starting Member
  • Total Posts : 46
  • Reward points : 0
  • Joined: 2018/06/16 01:23:47
  • Location: 0
  • Status: offline
Re: Future of PIC32 2019/01/04 05:35:09 (permalink)
0
Howard Long
Brane313
What's so wrong with PIC32MZ then ?

 
Harmony.
 
 


Why ? Because of trilllion bugs or something else ?
#27
marcov
Super Member
  • Total Posts : 246
  • Reward points : 0
  • Joined: 2006/10/08 01:59:40
  • Location: Eindhoven, NL.
  • Status: offline
Re: Future of PIC32 2019/01/04 05:42:48 (permalink) ☄ Helpfulby DominusT 2019/01/04 06:20:27
0
Brane313

Harmony.

Why ? Because of trilllion bugs or something else ?



If you get so far without the IDE plugins crashing on you in the first place. Many of drivers are very low quality and generic (e.g. doing blocking SPI instead of DMA etc), without choices.
 
I get a bit the feeling it is a framework to be demonstrated rather than used.
 
Btw, in case of the pic32mk tests that I did (and I had our applications running when I gave up due to performance problems, couldn't get more than 40MIPs out of it effectively it seems), I simply hacked the MX perib lib till it worked and used registers.
#28
JPortici
Super Member
  • Total Posts : 553
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: Future of PIC32 2019/01/04 06:03:18 (permalink)
0
marcov
I get a bit the feeling it is a framework to be demonstrated rather than used.



i honestly don't care for the peripheral drivers, always written my own, will always write my own.
What i care about is stuff i don't know how to do on my own like usb host (Also device, but device is a tad easier to understand imho and if i really really wanted i could do it) networking and graphics.
#29
Mysil
Super Member
  • Total Posts : 3206
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: Future of PIC32 2019/01/04 06:51:49 (permalink) ☄ Helpfulby DominusT 2019/01/04 06:54:04
4.25 (4)
Hi,
Some of the problem around Harmony is a learning curve that is different from other application development for PIC devices.
The hardware abstraction in Harmony peripheral layer do not correspond with hardware datasheet register documentation, and thus make debugging at register level confusing.
 
Most developers using PIC32 are commercial companies or professional consultants, that are not allowed or willing to publish source code in any large extent.
Thus there is little in ways of any open source community around PIC32MZ.
 
I cannot understand any way that RISC-V would change this in any significant way.
As far as I can understand, RISC-V and MIPS are very similar, RISC-V created as a academic and educational exercise.
In my observation, wery few problems with PIC32 devices are related to CPU or MIPS ISA.
Most Errata documented for MZ are about peripherals that does not quite work as expected.
 
MIPS having 32 accumulator registers in the CPU, is larger that 16 general purpose registers in RISC-V embedded or ARM.
Thus RTOS context switching, or software interrupt prolog and epilog code may seem slower when running in a MIPS.
In PIC32MZ  this is counteracted by 8 sets of shadow registers, and large numbers of hardware Interrupt Vector registers.
In smaller PIC32M devices, careful coding of Interrupt handlers, may help a lot in helping against any percieved disadvantage in interrupt handler performance.
If someone with suitable ability would want to, they could make a GCC variant using only 16 registers in MIPS, to compare preformance.
 
    Mysil
#30
Brane313
Starting Member
  • Total Posts : 46
  • Reward points : 0
  • Joined: 2018/06/16 01:23:47
  • Location: 0
  • Status: offline
Re: Future of PIC32 2019/01/04 07:03:08 (permalink)
0
True, my point is that cores are already very similar, so not much would change for Microchip, except they could offload the load of toolchain development to oepn sauce, with perhaps having several emplyees keeping an eye on things.
 
This way, they could offer great and fresh tools to their public free of charge. And free for inspection, tweaking and modifications.
 
 
 
#31
crosland
Super Member
  • Total Posts : 1524
  • Reward points : 0
  • Joined: 2005/05/10 10:55:05
  • Location: Bucks, UK
  • Status: offline
Re: Future of PIC32 2019/01/04 07:13:52 (permalink)
0
Brane313
- RISC-V is too similar and it's free
 



You missed the bit about MIPS being free.
And the fragmentation of RISC-V due to there being no compatibility guarantee between each vendors inmplementation.
#32
Mysil
Super Member
  • Total Posts : 3206
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: Future of PIC32 2019/01/04 07:29:15 (permalink)
0
Hi,
Most of the development toolchain is open source already,
XC32 compiler beeing a wrapped up GCC for MIPS,
and NetBeans inside MPLAB X.
Microchip is Borrowing or Buying technology wherever they find something suitable,
open source or commercial license.
 
Then together with the C compiler, there are Device Support header files that define structures and symbolic names for peripheral registers and fields.
These are specific for each device type, so isn't easily available from open source anyway.
 
Harmony isn't about CPU Instruction Set Architecture either. It is about tailoring application code to Peripherals.
 
    Mysil
#33
NorthGuy
Super Member
  • Total Posts : 5256
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: Future of PIC32 2019/01/04 07:59:28 (permalink)
0
Mysil
I cannot understand any way that RISC-V would change this in any significant way.



MIPS, RISC-V, and ARM all provide about the same level of efficiency, have similar limitations etc. However, ARM is very popular, while MIPS is not. Thus, the management and marketing wants ARM. Popularity doesn't last long, so ARM is bound to go out of favour. RISC-V has a potential to take its place. RISC-V is indeed better organized because it was created later than others and is much tidier. If RISC-V takes over the world and ARM gets out of favour, Microchip, with their SAM orientation, will be left out, exact the same way as now with PIC32. They simply have to do something not to miss the RISC-V bandwagon.
 
As to the Harmony, it is much easier to work at register level because everything is documented. However, there are lots of new recent graduates who were thought differently - they need abstraction layers, portability etc. Things like Harmony are designed to attract these people. I don't know if this is succeeding, but it certainly works against traditional PIC users. But who cares - they're dying breed.
#34
Brane313
Starting Member
  • Total Posts : 46
  • Reward points : 0
  • Joined: 2018/06/16 01:23:47
  • Location: 0
  • Status: offline
Re: Future of PIC32 2019/01/04 08:25:00 (permalink)
0
I don't like  Harmony.
It's choke full of inefficiencies, bugs and abstractions that are simply not on my " mental wavelenght".
 
Abstractions are nice if the mean something to YOU. If they are some mental ahortcuts that someone found to be nice for him ( and there is no wide consensus on that), they are more bother than they are worth.
 
It's usually a nightmare for me to remember PLIB name combo for something and so I usually am faster to open concrete thematic datasheet ( e.g ADC, SPI etc ) and simply write to some register directly and be done with it.
 
Also, many functions seem to be a mess, since they are generated....
 
 
#35
DominusT
Super Member
  • Total Posts : 1272
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
Re: Future of PIC32 2019/01/04 09:58:39 (permalink)
0
Jack_M
marcov
I get a bit the feeling it is a framework to be demonstrated rather than used.



i honestly don't care for the peripheral drivers, always written my own, will always write my own.
What i care about is stuff i don't know how to do on my own like usb host (Also device, but device is a tad easier to understand imho and if i really really wanted i could do it) networking and graphics.


Ethernet without MLA or Harmony?

 

#36
JorgeF
Super Member
  • Total Posts : 3340
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re: Future of PIC32 2019/01/04 11:21:02 (permalink)
0
Hi
DominusT
Ethernet without MLA or Harmony?

Why not?
 
It a lot of work, but, in reality, you will only do it once.
After that first time, the only thing you have to worry about is low level adjustments to cope with differences in hardware, whenever you change devices.
 

Best regards
Jorge
 
I'm here http://picforum.ric323.com too!
And it works better....
#37
DominusT
Super Member
  • Total Posts : 1272
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
Re: Future of PIC32 2019/01/04 11:25:49 (permalink)
0
JorgeF
Hi
DominusT
Ethernet without MLA or Harmony?

Why not?
 
It a lot of work, but, in reality, you will only do it once.
After that first time, the only thing you have to worry about is low level adjustments to cope with differences in hardware, whenever you change devices.
 


I have always wanted to write my own libraries for the Ethernet module, once I tried it but I realized that I was wasting my time and I had to resort to Harmony to accelerate the project. It is the only peripheral that I can not create my own code.
#38
Jim Nickerson
User 452
  • Total Posts : 5820
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: online
Re: Future of PIC32 2019/01/04 11:33:53 (permalink)
0
Maybe one could have a look here for something to start with https://github.com/Microc...net/tree/master/driver
#39
NorthGuy
Super Member
  • Total Posts : 5256
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: Future of PIC32 2019/01/04 13:07:37 (permalink)
4 (1)
DominusT
I have always wanted to write my own libraries for the Ethernet module, once I tried it but I realized that I was wasting my time and I had to resort to Harmony to accelerate the project. It is the only peripheral that I can not create my own code.



How come? It's not that difficult. Ethernet frames have very simple structure. Simple ARP protocol used to convert IP to MAC. Extremely simple IP protocol. Extremely simple UDP protocol. TCP requires some work, but it's definitely not dramatic - just need to be careful, think of all the cases. It is all in RFCs - even typical problems you may encounter.
 
May be you just haven't started from the beginning. Assemble a network with Linux which lets you send custom frames to your device. Start from decoding Ethernet frames, then add ARP, move on little by little, and you'll be done in no time.
#40
Page: < 12345 > Showing page 2 of 5
Jump to:
© 2019 APG vNext Commercial Version 4.5