Microchip MPLAB X and the MCC - is this a dependable dev platform?

[ataradov]

All MCC/Harmony components can be archived locally and a stable configuration is possible. And the system is designed to work without internet connection at all. There are instructions on how to download individual components from GitHub. This is used by the people that have to work in secured environments.

The issue here is that if you do have internet connection, you need to be vigilant and not let it update anything. There are many components that depend on each other and updating one of them (like the MCC plugin) may necessitate update of the actual code, which is likely not desirable.

At the same time, it never updates anything automatically. It just offers to update things, so you need to read the dialogs that pop up and not just click "OK" to dismiss them.

[cv007]

I know the chip is a complex one (considering my background in simpler micros)

This series is about as simple as they come. The first test you made in getting the dac to work requires accessing 3 peripheral registers to setup, and 1 to set the dac value, which is spelled out in the datasheet. Even when you get to something like twi/i2c, there are about 6 registers in the peripheral that are used with half of those used only for init/setup. You are in PIC16 territory as far as complexity.

To gauge complexity of most mcu's, go to the peripheral register summary in the datasheet. In many cases you will look it over and conclude there cannot be that much complexity with relatively few registers. After you then read the peripheral description and mentally black out the registers/bitfields you know you will not be using, you are left with an even smaller subset.

At the same time, it never updates anything automatically. It just offers to update things, so you need to read the dialogs that pop up and not just click "OK" to dismiss them.

There are various options available- set proxy settings so it has no internet access, turn off checking for updates, disable notification plugin, and probably others.

[Howardlong]

All MCC/Harmony components can be archived locally and a stable configuration is possible. And the system is designed to work without internet connection at all. There are instructions on how to download individual components from GitHub. This is used by the people that have to work in secured environments.

The issue here is that if you do have internet connection, you need to be vigilant and not let it update anything. There are many components that depend on each other and updating one of them (like the MCC plugin) may necessitate update of the actual code, which is likely not desirable.

At the same time, it never updates anything automatically. It just offers to update things, so you need to read the dialogs that pop up and not just click "OK" to dismiss them.

For the time being, yes, you can keep and maintain a local setup without internet and without it updating. How long will that last?

As previously noted, there are hundreds of components within MCC alone to control. There also many dozens of DFPs and tool packs. DFP updates frequently break builds, either with a naming refactor or simply broken or missing SFR definitions.

For a team of developers creating and maintaining the same environments is going to be especially taxing.

Furthermore, seemingly benign DFPs and tool pack updates appear as notifications on a weekly basis. Usually I just keep and install everything, including old DFPs and including any new MCC content, as I develop on both a laptop and a desktop, and want to know they have everything required. However sometimes these releases regress, such as the debugger issue I mentioned.

Unfortunately thanks to modern software practices, developers are wasting more and more time maintaining their environments, rather than doing actual programming.

Gone are the days when I’d get a simple integrated annual setup to a complete IDE including toolchain. It’s now up to the developer to pick and choose from hundreds of moving parts, often with guesswork and multiple failures, when one component won’t work with another. It’s time toolchain vendors did a bit more of their own dogfooding rather than throwing spaghetti at the walls.

[peter-h]

You can archive most tools which don't require internet access for anything. The ultimate way is to install in a VM (I use VMware) and then you archieve the VM. Maybe 10GB for a win7-64 one with Cube IDE and a big project. But then your boss will object to the use of a unlicensed Windows in the VM (works if you choose Mode not Copy when reinstalling the VM elsewhere).

[ataradov]

For the time being, yes, you can keep and maintain a local setup without internet and without it updating. How long will that last?

As long as there are military/aerospace customers out there. They always have a requirement of working without internet connection.

Usually I just keep and install everything, including old DFPs and including any new MCC content, as I develop on both a laptop and a desktop, and want to know they have everything required.

If you constantly update, then you should expect things to change/break occasionally. It is impossible to constantly change the software without introducing some incompatibility. This is especially obvious if you rely on non-public APIs, as often happen i n embedded development.

Gone are the days when I’d get a simple integrated annual setup to a complete IDE including toolchain.

You can still do that. Disable internet connection in the IDE and download all the packs manually once. You will have exact setup. You can have the same exact setup on however many machines you want. This is not even a "hack" this is a fully supported mode.

You take advantage of that "modern" way of development where you have two machines synchronized over the internet. And then you complain about that synchronization.

[PlainName]

Doesn't always work.

We made a series of products based on the 80186 and used BC++3.1 to compile everything. Seemed to work well, and no problem at all getting a new workstation set up to produce the exact same code as any other one. Except... I happened to notice the the same code compiled on two different workstations produced different hex files. We tried all the workstations and found that half of them produced one version of hex file, the other half producing the other version. Previous checks had been with two workstations in the same half, which is why it took a while to notice.

Can't remember what it turned out to be but it was non-obvious, and unless you knew you had that problem you'd never know until you needed to make the exact same hex file from the same code and couldn't.

[peter-h]

What tends to get you is software which "calls home" every few months. It can be quite non-obvious.

I guess mil customers do a special deal to avoid the need for an internet connection. But also a floating license server can be a machine in your office. I once asked a salesman (of some £20k program - probably Cadence formerly Protel) what happens if that license server blows up, say 10 years from now. He said you can duplicate it if you can get an ETH card with a programmable MAC # since the license server just uses that There are such cards. Still a crap solution. But it means you can jut use a small intranet.

[Howardlong]

You take advantage of that "modern" way of development where you have two machines synchronized over the internet. And then you complain about that synchronization.

Actually I do both. New projects I start with the latest IDE, DFPs etc. Older projects I keep on the older toolchains unless I specifically have a piece of maintenance work that necessitates an upgrade.

I have 13 versions of MPLAB X installed on my desktop, as well as the venerable old MPLAB 8.92.

1 x MCC18 version.

6 x 64 bit versions of XC8, and 4 x 32 bit versions.

2 x 64 bit versions of XC16, and 2 x 32 bit versions.

4 x 64 bit versions of XC32, and 3 x 32 bit versions.

2 versions of XC-DSC.

Respectfully, you're missing my point. To create a new working build environment is no longer a simple task, especially once you use MCC, which practically speaking you pretty much have to when using complex peripherals like USB or networking. It's time consuming and likely to be fraught with problems getting everything in line.

[bson]

And if you don't want a debugger and will be using an external programmer, then it is no different from any generic IDE/text editor.

Unless he switches to ARM... in which case OpenOCD and GDB will do fine and in many cases better than an IDE.  For example being able to TCL script GDB is very handy to dump linked data structures.  As is being able to cast data to things like polymorphic headers and payload types.

[Howardlong]

You can archive most tools which don't require internet access for anything. The ultimate way is to install in a VM (I use VMware) and then you archieve the VM. Maybe 10GB for a win7-64 one with Cube IDE and a big project. But then your boss will object to the use of a unlicensed Windows in the VM (works if you choose Mode not Copy when reinstalling the VM elsewhere).

Actually, for archiving, that's exactly what I do, with VMWare Workstation, and have been doing for a very long time. However, not even that is reliable any more, as you also need to maintain the HPA within the VM if you use newer Pro level compilers. As I already mentioned earlier in the thread, your -Os or -O3 will no longer work with the newer compilers after the HPA runs out.

I don't have a boss to worry about. You can re-use an HPA if you add an additional disconnected dummy NIC to the VM and set its MAC address appropriately, but that won't get you over the HPA running out. There are "ways" to circumvent the whole HPA requirement and its expiry on XC16, XC32 and XC-DSC if absolutely necessary. XC8, not so much, you'll need a valid HPA.

There is also a monthly subscription option. Yeah, nah ;-)

[Howardlong]

What tends to get you is software which "calls home" every few months. It can be quite non-obvious.

I guess mil customers do a special deal to avoid the need for an internet connection. But also a floating license server can be a machine in your office. I once asked a salesman (of some £20k program - probably Cadence formerly Protel) what happens if that license server blows up, say 10 years from now. He said you can duplicate it if you can get an ETH card with a programmable MAC # since the license server just uses that There are such cards. Still a crap solution. But it means you can jut use a small intranet.

I got caught with exactly that on my way to a client some years ago now (not a Microchip project, this was C++ on ARM, and it used a licensed framework). I had a few tweaks and finishing touches to do on my way to the customer, an 11 hour flight away in Hong Kong. Of course, the PoS framework decided it was time to phone home while I was on the plane, and this was in the days before internet connectivity on a longhaul flight was commonplace.

Prior to this, I had no knowledge of it ever needing to do that. I discovered later from the vendor that it phoned home every couple of weeks, and I was "just unlucky". There was a workaround, to force a license refresh manually before going offline, but I didn't know that.

[PlainName]

When I programmed Windows I used TMSSoftware components. I religiously downloaded the source to them, and built the components from source to make sure they would work. The license was perpetual but, as usualy, upgrade support was only 12 months. Who cares! I didn't want to upgrade so quite happy with that.

Then I migrated to a new PC and the bloody components wouldn't work without phoning home to authorise. OK, no problem - perpetual license, see. Except the license server would only work with a support contract... Workaround was to fake the license server on the LAN, but that opened my eyes a bit.

Just don't get me started on LogViewPlus - fantastic app, but the developer pulls that kind of stunt and as a result I refuse to invest anything in using it now. Much rather use an inferior product that doesn't fuck over the users, and happy to slag it off to anyone that will listen

[marcov]

What is the point of MCC?

After some very negative experiences with MCC and Harmony back when the pic32mk came out (stability and lacking features like DMA options for e.g. SPI), I gave it another try a while back to gear up for dspic33A.   (I now mostly use dspic33e<yyy>MC/MU8xx)

What surprised me is how little it abstracts. The dialogs are mostly just lists with the same options for each field in the peripheral's registers,  only in cases where you must make choices the options are named in a drop down. 

So I get the feeling while it saves some minor looking up what value X means in a datasheet, it is not easier on any
fundamental level. The resulting code generation step does pack all settings in single assignments to registers though, while I quite often use XXXXbits.fieldzzz  to set the options to keep it readable. (since most of those are during startup, the performance difference doesn't matter much)

It seems that the pin configuration is the major attraction, but that doesn't appeal to me chiefly because most of our firmwares  can be compiled to several versions of the boards that often shuffle pins to make room for some feature (and/or upgrade/downgrade  the CPU from 64 to 100 pin or from MC to MU and vice versa). This came in handy during the Corona crisis when the MC variants and higher pincounts were pretty much unobtainium.  Or do I miss something and is something like that (one firmware, multiple pin layouts) possible?

A simple purpose built header generator tool that generates a header from an INI file that lists a symbolic pinout + the exact CPU suffices. Slightly ironic that I got the principles of that abstraction from how Microchips MLA TCP/IP stack applies to various boards.

[Doctorandus_P]

[Warning: Rant (only half on topic)]

My first uC programming was with the PIC16F84 and was short lived. I found the convoluted instruction set and programming in assembly horrible.
Then the AT90S2313 was released. One of the first uC's supported by GCC and I jumped on it. Had lots of fun. Later I also used some bigger versions such as the ATMEGA8, 16, 32 and 328, and they have a fair bit of compatibility, although often there were annoying little differences such as renaming the same bits in registers, which makes software incompatible, or little changes in timers. Mostly improvements, but I just wanted software compatibility so I don't have to keep on rewriting my own libraries.

Then the ATtinies came. I bought a bunch (about 20) but never used them. They did not even have a Uart. (My mistake).
Just today I was looking at Microchip again. Specifically ATtiny3226 and AVR32DD20. and they also break compatibility. Uart is quite different. For 20 years or so I've been waiting (longing) for an easy breadboardable AVR (size ATTINY2313) with a fair amount of memory, but Neither Atmel nor Microchip never made them. I wish I could cut of 8 or so pins from the ATMEGA328, but some smart guy decided to put the programming pins at one end, and the reset pin on the opposite end, so that's a no go either. That leaves using a QFP on a small adapter board. And an another annoying thing about the ATMEGA(32)8 line: You can't have an 8-bit databus and a UART at the same time. The UART is on the only 8-bit port it has.

Some 10 years ago I had a look at the Xmega's. Loads of nice features, but they were so completely different, that I might as well look further. My current goal is the ST line of processors. They have a fair bit of compatibility in peripherals from the smallest STM8 to the biggest STM32. The difference between 8 and 32 bit does not matter much when writing C. My big problem is the horrible Cube software, but that's a different chapter.

But overall. I've simply lost interest in Atmel / Microchip. They have a different processor line and different programming interfaces every 3 years or so. I lost track of what their programming tools cost, but you can buy an official ST-Link V3 for around EUR 10, and it programs all ST processors and it does it quickly too.

Even 20+ years ago people were complaining daily about the MPlab software that was so buggy that it was barely usable. Atmel also had some complex monster back then, but I just used GCC and some header files and was happy enough with that.
"avr-gcc --version" gives 5.4.0 on my linux box. That is from 2015. 9 years old. Microchip is hostile against Open source. They tried obfuscating they are using GCC for some years, and they probably still make access difficult. I will keep on using the old ATMEGA series, because I know how they work and I've based all my personal libraries on it (I never used "arduino")

Even their forum (avrfreaks) is hostile. I once posted there frequently, and every now and then I wondered why people who were also long time posters suddenly disappeared. This happened at least 5 times during the time I was posting there, and then I discovered why. The people who call themselves "moderators" on that forum behave like arrogant gods. They delete whole threads and delete any topic that they do not like. This reduces contributes to typing monkeys, and at some point I just never logged in again. Every two or 3 years I have a short look at that forum, and when they changed their forum software there was some glitch and a bunch of hidden topics / posts were visible. Among those I read questions form others about whether anyone knows what happened to me.

[wobbly]

I had the same experience on AVRFreaks.  Probably the most toxic tech forum I ever used.  Didn't stay there long!  The second worst was probably (and possibly surprisingly) the Parallax forums.  The whole place was a massive ego festival.  Maybe it's better these days, but I won't be going back.  I did like the Propeller micro though.

[Howardlong]

What is the point of MCC?

Unless you're using networking or USB, it adds little if any practical value.

Noobs like it because they've been hoodwinked into thinking it's doing them a favour.

I do use it to generate boilerplate for programmable logic, but then I just copy and paste the generated code template out of a dummy MCC project and into my bare metal project.

The level of its usefulness varies depending on the processor. Most PIC32 have a fairly extensive and usable clock configuration page for example.

But apart from networking and USB, you're going to need to understand the peripherals at a datasheet level whether you use MCC or not, so IMHO you're better off writing and maintaining your own boiler plate bare metal libs. At least they're unlikely to pull that rug from under your feet.

The SPI and I2C drivers are written to cover all bases and so tend to be bloated.

Furthermore, they're in the process of renaming MCC generated functions with "Master" or "Slave" in identifier names to acquiesce to the demands of a tiny number of very vocal student activists who're never going to be serious embedded engineers, but they do love the smell of power.

[JPortici]

What is the point of MCC?

Unless you're using networking or USB, it adds little if any practical value.

Even then, you can use the MLA. Code is probably 100% the same (it is at least for USB. I just had to use MCC that one time and i hated them for it with the PIC24FJ GU series, which lacked clear explanations on how to enable the FRC auto tune for crystal-less USB)
And the MLA is usually better. Can you do vendor USB in MCC now? can you do ANY usb besides CDC-UART, and possibly HID, now?

[ataradov]

MLA is not supported anymore, so you are limited to the old devices it supports.

And for ARM at least MCC has a full and pretty good USB stack.

[JPortici]

MLA is not supported anymore, so you are limited to the old devices it supports.

Nope, code is the same, the only thing missing is the appropriate include switch with the device model for the appropriate file.
MLA headers have no idea of what a PIC24FJ256GU406 is, you just need to add it.

** I'm sure that there is a full USB stack for ARM cores, as the MCC/MLA stack for 8/16bit devices is. The problem is that MCC editor won't let you use all the features. I don't know if it's management stupidity to drive you away from the parts, or inability to find out how to cram everything in the interface, but the parts and the library are pretty capable of doing everything.

[Howardlong]

** I'm sure that there is a full USB stack for ARM cores, as the MCC/MLA stack for 8/16bit devices is. The problem is that MCC editor won't let you use all the features. I don't know if it's management stupidity to drive you away from the parts, or inability to find out how to cram everything in the interface, but the parts and the library are pretty capable of doing everything.

FWIW, few earlier PIC32MXs were also supported by legacy MLA.

The very fact that software abstraction libraries change so often, while the hardware peripherals themselves remain largely static, is one of the best reasons to maintain one's own libraries of boilerplate.

[MathWizard]

So if you lived out in the middle of no where, and had no internet, but you had a phone and phone book, getting any electronics must be hard. Can you make phone orders on Digikey or other big sites these days ? Would they mail out datasheets ?

And assuming you can find the phone number of some big parts maker, I guess a lot of them won't sell to a hobbiyst, or little company even. These days, I wonder how many will mail out datasheet's, manuals, brochures, etc.

I wonder what the most complete set of MCU's and programs, driver disks, etc, that you can order over the phone, and then still not need internet for later on.

I haven't burned a DVD in a few years, but yeah it's time to burn a few more with just programs/drivers/etc, and a few datasheets and books from the past few years.