- 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...

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

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)....

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.

marcovI 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.

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.

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.

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.

MysilI 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.

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.

marcovI 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.

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.

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.

DominusTI 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.