PIC32MM support

[darko.ilijevski]

Yes I agree with you to some point. But if we had that many requests for the MK, we'd support it sooner than the MZ. But it was the other way around, so we (the management, actually) decided that the MZ support would be a better choice... And the fact is that no matter what choice is made, someone will always complain. If we would restrict support only for the PIC, we would be overwhelmed with the requests to support ARM, for example. These are the facts. Also I have suggested MZ as a suitable replacement for the designs, as it has plenty of power and peripherals you can choose from.

Also:

In 2015, Microchip released the PIC32MZ EF family, using the updated MIPS M5150 Warrior M-class processor

Regards...

[p.erasmus]

PIC, we would be overwhelmed with the requests to support ARM,

May I kindly remind you that you exactly did that, nearly 3 years you did not update the dsPIC and PIC32 compilers ,while the one after the other ARM releases were produced.Adding not only new devices but hole new vendors ,We the dsPIC and PIC32 users had to wait and mE did not care if we complained at all,My Question why is this such and issue to make the ARM users wait a bit while you catch up on PIC32 you did it with a smile to the Microchip users .Again this just shows the mE bias towards the ARM products .

[darko.ilijevski]

Hello

Well in this very moment, PIC 32 has RTOS, visual TFT merged already and many MCUs supported. We even have separate 8bit PIC mcu support, separate 24/33 support... Search for the posts about the ARM and you will find so many posts about visual TFT, those people still await for the integrated VTFT. We need to cover all the fields, that need resources. I am saying old - worn phrases again now, but it's just how it is... We have to support all we offer, so it's just a matter of time. We need to cover all the angles and we will. I have forwarded the requests, we will see what happens in the next batch of MCUs support. As I have said already, stay tuned on the roadmap for the upcoming development info. I will urge our developers to put things there more frequently, since I agree it's a good thing we made, we need to make it stay alive.

Best regards

[phil31]

hi,

"PIC 32 has RTOS" .. ONLY for C compiler .. Pascal and Basic need to wait ..
same for a lot of others 'improvement' .. most of them are only fixed bug (and of course, not all even if open since several Years !)

"We have to support all we offer" .. yes, please do it !

and 32MM was announced .. but remove of the list 1 or 2 weeks before you release the 4.0 version

[darko.ilijevski]

Hello,

Can you please share with me what improvements would you like to see ? What is that bothers you the most ? How would you improve the compiler ?
I can pass your ideas to our developers, they will consider adding them for sure, if those are good ideas and suggestions.

As for the RTOS - you might already know - mikroElektronika is not the creator of the RTOS. We are merely porting it to our compilers. We heavily rely on the code that has been already written by the creators of the RTOS. To start a new development of such complicated task on BASIC or PASCAL would be a highly challenging task, even for a dedicated company which develops OS only. The problem lies in the very structure of the PASCAL and BASIC - they are different than C - simple as that. The language structure differs and writing port in PASCAL or BASIC would require redefining of the whole kernel. Currently we do not plan such task, but I wouldn't like to predict the future development directions of mikroElektronika regarding RTOS...

Best regards

[phil31]

hello

fix all previous bug in compiler himself, fix all bugs in library and provide 32MM support
keep your promises when you announce that a new bookstore will soon be available !..
(just for remember, the MQTT librairie .. asked since 2 or 3 years ....)


about bugged library, i already complain several time to your team leader .. the "best" answer was something like :
"library are provide free of charge, don't complain about it !!!" ..
the fact is that in description pages of your compilers you specifically extol the benefits of the compiler and libraries ..

regards

[darko.ilijevski]

Hi,

Fixing bugs goes without saying, of course that we want them all fixed. That is why we value our users feedback. Also I doubt that anyone from our team would say something like that - we are here to provide the users with as effortless and as joyful experience as we can.

So - as I have said, we do try to fix all the bugs, but sometimes, the problem lies within the underlying IDE we use to code, so some errors need to wait on the IDE to get fixed. That is especially true for the DPI and other graphical glitches that appear on some systems. Also, for these systems, the problem sometimes lies within the OS itself. We do try to cover all of the commonly used versions of windows, but even Microsoft has abandoned support for them so it is reasonable to expect minor problems of this kind.

Bugs get fixed whenever we release a new version, so be sure that you always use the latest build available on our site. We collect the data about the bugs in the meanwhile and when enough of it was collected, the new version gets built and released, along with some new features, and so on. It's how every software production works.
Lastly, not every report is valid - there are many supposed bugs being reported, which are actually erroneous coding. I have witnessed those more than once. Then, we try to point that out to our users and explain why it happens.

As for the new MCUs, sometimes it's not that easy to implement all the code to work with our libraries, or something doesn't go that well, or for whatever other reason, the MCU has to wait for some other release... There are so many different architectures and MCUs, almost always there is a suitable replacement which actually works. Sometimes not all the circumstances can be foreseen during the library production process...

I hope it is now more clear what is going on with this subject.



Best regards

[phil31]

Darko,

that's not what about i speak !
i speak of bugs in library .. not in compiler (even if there are some too 'of course')
or i remember too, a bug in mikroprog that is even not solved (actually i use 2.6version)
for those, some tickets are open since several YEARS !!

"Also I doubt that anyone from our team would say something like that" ==> your boss write me that !!
i'm convince that i can find this email !!

i think the only reliable solution to fix a problem in library, is to open source the libraries !
as everybody, your team don't have enough time ..

regards

[phil31]

"lol" ..
again with the ethernet library, please have a look to my problem on PIC32 BASIC compiler :
viewtopic.php?f=168&t=71083

[phil31]

as now i have the 4.0 compiler, i do same test as bug reported since several YEARS !
ticket #CDS-894-80849

several YEARS later, that is not fixed .. your best response was "we are sorry, we don't have any 64 pins chips", we can't test !! ...

[lololafripouille]

Hi,

Fixing bugs goes without saying, of course that we want them all fixed. That is why we value our users feedback. Also I doubt that anyone from our team would say something like that - we are here to provide the users with as effortless and as joyful experience as we can.

So - as I have said, we do try to fix all the bugs, but sometimes, the problem lies within the underlying IDE we use to code, so some errors need to wait on the IDE to get fixed. That is especially true for the DPI and other graphical glitches that appear on some systems. Also, for these systems, the problem sometimes lies within the OS itself. We do try to cover all of the commonly used versions of windows, but even Microsoft has abandoned support for them so it is reasonable to expect minor problems of this kind.

Bugs get fixed whenever we release a new version, so be sure that you always use the latest build available on our site. We collect the data about the bugs in the meanwhile and when enough of it was collected, the new version gets built and released, along with some new features, and so on. It's how every software production works.
Lastly, not every report is valid - there are many supposed bugs being reported, which are actually erroneous coding. I have witnessed those more than once. Then, we try to point that out to our users and explain why it happens.

As for the new MCUs, sometimes it's not that easy to implement all the code to work with our libraries, or something doesn't go that well, or for whatever other reason, the MCU has to wait for some other release... There are so many different architectures and MCUs, almost always there is a suitable replacement which actually works. Sometimes not all the circumstances can be foreseen during the library production process...

I hope it is now more clear what is going on with this subject.



Best regards

Hello Darko,

To begin, I would just like to say that I love your interventions on the forum.
They are always well explained and documented.
And in some cases you know how to be very diplomatic....
Since joining the forum, I find that problems are solved much faster than in the past.

That said, there are still some weird stuff like the time needed for a new MCU family to be supported by the compiler.
It is so frustrating when you use MAPS from microchip to select an MCU and then you have to cry on the forum because the family is not supported yet ( and have no idea when it will be ).

Im not an expert so maybe it is much more complicated that I think but maybe it will be possible to add new family more faster, "as is", without hardware and built in libraries fully tested on intermediate release. Then, you have time to test everything else for the next major release.
This allows us to start working with this great IDE. When we need a particular MCU, we are ready to code the registers directly instead of using builtin libraries.

And for your closed libraries, I know that it is your company policy to not share the code. But maybe you can sell it ?
I will be happy to pay an extra for open source libraries ( i don't know, maybe 500$ instead of 300$ today )

Have a nice day

[darko.ilijevski]

Hello,

@lololafripouille
Thanks for the kind words, it's always appreciated when someone recognizes the efforts we make in order to help as much as we can. Also don't forget that we work as a team, OK - the diplomatic part is my own , but every member of the support team, gives his/her contribution to the cause we are all striving towards.

@phil31

I have briefly took a look at the ticket - the problem seems to be undocumented / unlisted feature of the MCU itself. I will investigate into this matter and let you know what I have found out. The main problem with that issue is to locate which bit causes the mentioned problem and on what location.
For the external libraries - I can say with confidence that it's humanly impossible to maintain such a huge base of examples and libraries for all of the devices we have. If the compatibility is broken, we can try to fix it, but for some of the libraries, there are numerous reasons why it's not that simple: either the person which was working on the particular library, left the company - or there's not enough time to look back and try to fix something that should be working in the first place, when there's a new product example waiting to be written. I have said before that mE is a growing company and efforts are put into that segment, too - some libraries are open (or rather - the code doesn't need them), but lately - the whole framework is getting redesigned to be clean and interchangeable between the platforms, so the examples should work at all times. In time, every (or at least as much as possible) library will get rewritten with the new framework, at least that's the plan.

@everyone
Releasing of the new MCU family has already been discussed here - it is not that simple, and things like the problem phil31 had, make it even harder. Sometimes the code simply doesn't work - reason can be the errata, undocumented function or whatever, so the MCU doesn't make it in the release. Specifically - MM series use completely different core and instruction sets, so is a rather complex process. Sometimes it's just a practical decision that it's not worth supporting a MCU or it's just too complex / doesn't fit into our program plans...

Best regards

[phil31]

Darko,

"the problem seems to be undocumented / unlisted feature of the MCU itself." => no doubt about that !
but this ticket is open since more than 2 years !!! and the best answer from your team was "we can't test it because we don't have any 64 pins platform" ...
==> is that a professional answer ?
==> you simply closed this ticket several time, surely expecting that i don't complain again ! .. but unlucky, i just start a new design with this target and reopen the ticket because bug is ever here !!


about library, i perfectly agree.. that's why i suggest to open source codes !
most of the time, libraries are port of open source from others vendor as Microchip ..


about the incompatibility with the last Ethernet library, the problem seem in the "Net_Ethernet_Intern_doDHCPLeaseTime()" function

regards

[ilferrari]

Soon you should notice that those are not empty promises and "automated replies" which we give for every suggestion.

Thank you for staying with us!

2.5 years later, still no PIC32MM support. Neither is there support for PIC32MK, PIC32MZ-DA, etc.

This compiler is marketed as a professional toolchain. Do you think it is okay that it takes up to 3 years to add basic support for devices?

[lololafripouille]

Sorry but you are wrong,

"Pro" is not for professional but for profit.

You're welcome.