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

[Postal2]

You are free to do whatever you want. Actual businesses need supported tools. None of the stuff you suggesting even remotely related to the original post.

I read what you wrote here and I can say the same thing.

[floobydust]

It's a 1GB download and install for MPLABX, then I run it and it's plastered with social media icons Facebook etc. wants sign in Microchip account etc. Fuck I just want to write some code for your SAMD.
A message pops up "You need to install a compiler" 
I'm not the brightest to figure out their toolchain, but it came across as a hot steaming turd due to marketing and a silent push to cloud-based subscription shit. It seems unusable.

I don't have a lot of patience for Microchip lately. I think they have over 40 VP's FFS.
Their website is a dog's breakfast it returns a blank parametric table for the MCU's and what a terrible experience trying to find an MCU. Pretty much impossible.

The table is blank for an MCU (42x features) and wrong about not having EEPROM etc.  Who gets paid to make a rubbish reference guide?

Dave interviewed Exec. Chair Steve Sanghi. When he said Atmel was bloated, I stopped watching because no, Microchip is fat now. I think they are lost now, all worship Wall Street and the earnings, drive the stock up up up.

[westfw]

looking into this new MPLAB X IDE crap I've basically lost much of my love for Atmel microcontrollers.

As far as I can tell, the sort of problems you are having are FAR from unique to Microchip/Atmel.  Similar tools from other vendors have similar problems (at "Atmel Start" had the same problems back before MPLABX/Harmony.) Just take a search of the forums for peoples' experience with STMCube, and no one seems to like the "peripheral" parts of ARM's CMSIS.)

AVRDude appears to be a stalled project as far as I can tell.  There have been no new target parts added in ages. If anyone knows otherwise PLEASE tell me how I can learn more!

AVRDude is not an Atmel or Microchip product, but it has recently seen a fair amount of new development at https://github.com/avrdudes/avrdude
(in particular, assorted UPDI "programmers" and a new protocol specifically aimed at bootloaders vs actual programmers ("urboot")

[mskeete]

It's a 1GB download and install for MPLABX, then I run it and it's plastered with social media icons Facebook etc. wants sign in Microchip account etc. Fuck I just want to write some code for your SAMD.
A message pops up "You need to install a compiler" 
I'm not the brightest to figure out their toolchain, but it came across as a hot steaming turd due to marketing and a silent push to cloud-based subscription shit. It seems unusable.

I don't have a lot of patience for Microchip lately. I think they have over 40 VP's FFS.
Their website is a dog's breakfast it returns a blank parametric table for the MCU's and what a terrible experience trying to find an MCU. Pretty much impossible.

The table is blank for an MCU (42x features) and wrong about not having EEPROM etc.  Who gets paid to make a rubbish reference guide?

Dave interviewed Exec. Chair Steve Sanghi. When he said Atmel was bloated, I stopped watching because no, Microchip is fat now. I think they are lost now, all worship Wall Street and the earnings, drive the stock up up up.

I tried it a few weeks ago and gave up after a few hours. I ended up using notepad++, compiling from the command line and using avrdude.
Having used CubeMx/CubeIDE on and off for a few years, I thought i was going to miss all the debug features but I was actually more productive

[wobbly]

@mskeete,
When I was writing all my firmware on a Linux PC, using vim, avr-gcc and avrdude I can honestly say I have never been happier.

I'll keep doing that of course, for hobby stuff.  But for work I can't because the newer chips we are using aren't supported by avrdude

[mskeete]

You could still use vim and avr-gcc but with a different programmer.
Looks like avrdude is still being updated.
I wanted to try using a attiny1617 without spending a lot of money so I tried avrdude with a modded USB to serial device.

[JPortici]

It's a 1GB download and install for MPLABX, then I run it and it's plastered with social media icons Facebook etc. wants sign in Microchip account etc. Fuck I just want to write some code for your SAMD.
A message pops up "You need to install a compiler" 
I'm not the brightest to figure out their toolchain, but it came across as a hot steaming turd due to marketing and a silent push to cloud-based subscription shit. It seems unusable.

at the very end of the installation process there is a page that tells you clearly that no compilers are built in and lets you go to the compiler download page. Are you one of those types that click next without reading and then act surprised when there is a new toolbar on internet explorer and default search engine is not google anymore?

I don't have a lot of patience for Microchip lately. I think they have over 40 VP's FFS.
Their website is a dog's breakfast it returns a blank parametric table for the MCU's and what a terrible experience trying to find an MCU. Pretty much impossible.

The table is blank for an MCU (42x features) and wrong about not having EEPROM etc.  Who gets paid to make a rubbish reference guide?

Dave interviewed Exec. Chair Steve Sanghi. When he said Atmel was bloated, I stopped watching because no, Microchip is fat now. I think they are lost now, all worship Wall Street and the earnings, drive the stock up up up.

completely agree. I got the impression that after acquiring atmel they threw themselves to everything wrong with them (documentation, style, website) and let go of anything good (the community forum)
thankfully 16bit parts, which i use the most, have been spared of all this nonsense, i guess because there were no "redundancies".

[Svuppe]

And AVR128DA64 specifically is not supported by AS/MS. So if you want to use that device, then you need to use something else.

Wait WHAT? Are you sure?
I use AVR128DA28, AVR128DA48 and AVR128DB48 in MS without any problems, and have done so for a few years. Yes, also debugging with Atmel ICE.
Installing support for it was nothing more than a couple of clicks with the mouse, from within the IDE. Can't be much easier than that.

[ataradov]

I may be wrong on this, I could not find a good confirmation that it is supported and I don't have MS installed at the moment.

In any case, it is going away, it gets less and less support, so eventually it will start to fall apart. It is in a reasonable shape for 8-bit devices because that is the group that still somewhat cares about MS. For 32-bit devices some features were already broken (like working with fuses on the Cortex-M33 devices).

It is prudent to plan for its disappearance in the future if you don't want to get stuck without working tools.

[westfw]

And AVR128DA64 specifically is not supported by AS/MS.

"Not Supported" means what, exactly?  avr-gcc certainly supports the  new AVRs (via the "packs" mechanism.)  I can't speak to "full debugger support" or "Atmel Start" support...

for work I can't because the newer chips we are using aren't supported by avrdude

Sure they are.  There's a whole set of "Arduino Cores" for the newest AVR chips, and they all use avrdude for programming.

[ataradov]

I can't speak to "full debugger support"

This is generally what I mean by support. Otherwise it is just a text editor with hotkeys for building the project. And this can be achieved by any text editor.

[wobbly]

Sure they are.  There's a whole set of "Arduino Cores" for the newest AVR chips, and they all use avrdude for programming.

Sounds promising, got a link by any chance?

[westfw]

https://github.com/SpenceKonde/DxCore


I already posted the link for a recent avrdude…

[mikeselectricstuff]

...in other words, configuration that would take days to figure out from reading the 650-page datasheet! ....

"Programming guides" are often over 1000 pages long.

But you usually only need to read the sections that are applicable to what you're doing.
A problem with automatic code generation is it can be very hard to change things later. better to spend the time to understand the underlying peripheral - you'll probably recoup this in debugging. Or trying to optimise the bloaty code when you start running out of space.

[mikeselectricstuff]

After all it's made by the chip manufacturer itself!

This is a wrong way of thinking about it. Any free tools and frameworks are a cost center. They cost money to make and don't bring direct revenue. So, vendor's incentive to do as little work and as cheaply as they can get away with.

.and guess what they start the interns on....

[PlainName]

Not going to say much on this topic other than I loath the bloaty shit IDEs you get to install for these things, but it just so happens that I have the install files for MPLab X 5.45 and MPLab 8.92 if anyone is desperate enough to want them. MPLab is, I think, the last version before they obsoleted it (and it's shit, but the compiler is fine if you use a decent editor). MPLab X... reminds me of early Java apps compared to the Win32 native stuff, but still apparently better than what you get today

Also Microchip libraries for applications dated 2013 (actually downloaded 2017 I think).

[wobbly]

Thank you to everyone who has ventured opinions on this topic.  I now have a plan to deal with the near-middle future to keep the boss happy.

Likely it will involve moving to another microcontroller platform (I have a few in mind), but for legacy products I think I'll be forced to preserve some kind of static dev environment for the old tools.  Probably a curated virtual machine image with all the right stuff installed and isolated from accidental updates.

*sigh* Not the first time I've had to do this and I'm sure it won't be the last...  *glances sadly at the forlorn, yellowed Solaris box in the corner*

Cheers everyone 

[westfw]

>>I can't speak to "full debugger support"

This is generally what I mean by support.

I dunno.  I think I could live without the simulator being updated to understand the slightly different instruction timings in the new cores, for example...

Likely it will involve moving to another microcontroller platform

Good luck with that.  These days, the only chips without 1000-page datasheets and "poor" code generators are the ones that are poorly documented and have NO code generators...

The thing I find especially annoying is the clock circuitry.  Yes, I'm sure it's really swell that the chip has a PLL, a DFLL, multiple internal timebases, multiple external timebases, and a dozen different prescaler chains that can be used to provide different clocks to each peripheral, all of which are un-clocked by default.  But those are really not features that I'm very interested in "mastering" (or even "understanding") before I can start doing anything else, and I don't appreciate the "standard code template" taking 1K+ of code to do it for me.  Sigh.

[wobbly]

@westfw,
I have no problem with large datasheets.  My complaint is mainly rooted in the way certain companies misrepresent their own tool chains.

[Howardlong]

After all it's made by the chip manufacturer itself!

This is a wrong way of thinking about it. Any free tools and frameworks are a cost center. They cost money to make and don't bring direct revenue. So, vendor's incentive to do as little work and as cheaply as they can get away with.

.and guess what they start the interns on....

The whole MCC and Harmony thing is an CS academic's wet dream. Force everyone into a framework straitjacket, and abstract the f*** out of everything.

And you still have to read an understand the datasheet anyway. MCC and Harmony is just more to learn, and they're a continually moving quicksand of hundreds of moving parts, making maintenance and team development a real headache.

My MCC & Harmony MO is to only use them for complex stuff like USB and networking (and even then I have to tweak), and everything else is bare metal.

[Howardlong]

A lot of the time nightly builds fail after feature merges and are not releasable. And the development branches often contain code for the unreleased products and the release of the software is coordinated with the release of the devices.

I don't see the point of using nightly builds unless you're in the team developing or testing the product itself.

As a consumer, I don't take well to dogfood releases that haven't been tested beyond the stage of "well, it installed". Point in fact being Microchip's VS Code extensions, a complete dog's dinner of dog food if ever there was one.

[westfw]

Quote

AVRDude appears to be a stalled project as far as I can tell.

Just announced: avrdude version 8: https://www.avrfreaks.net/s/topic/a5CV400000020gfMAA/t397746

[peter-h]

Too many one-line posts

Free tools are perfectly fine for business use. You just have to freeze it at version x.x.x and carry on.

This has never changed.

Tools like Cube IDE give you a text editor, a debugger (very important) and a makefile generator. In the old days all this was separate. I don't think it was any better. Ultimately it comes down to the tool archiving policy.

Lots of corporate users think that unless they pay $xxxx then the tool is crap. But what they get is a floating license (which is guaranteed to shaft them down the road, especially with tool archiving, and much sooner if some employee runs a bootleg copy of it which arguably is the smartest thing to do) and functionally probably not actually better. I go back to PVCS, Polymake, Brief, etc so I know the history

[wobbly]

@westfw
Guess I spoke too soon!  Thank you for the heads-up. 
Looks like they've added a lot of new chips.

*Fires up Linux VM*
*Cracks knuckles*

[Howardlong]

Free tools are perfectly fine for business use. You just have to freeze it at version x.x.x and carry on.

If only it was that easy nowadays!

The problem with MCC is that it's a continually shifting quicksand made up of hundreds of different components. Creating a "gold" build install and aligning all component versions is thus easier said than done. Not only that, I am not convinced it's even possible to create a development machine anymore for some use cases as components are maintained in the cloud, and aren't directly downloadable as a good old fashioned files as far as I know.

As an example, I had a problem with a build recently where I could no longer debug the build as the debugger firmware component had broken. In the end I had to use a Python script to retrieve the otherwise hidden, but working, earlier version of the component. It's only a matter of time before no level of hackery will work for these situations anymore due to bit rot.

Furthermore, if you use the paid XC compilers, HPA licences now expire. So one day either your build might not fit anymore, or that essential optimisation tweak will break your build. Until a couple of years ago, you could continue using the same version of compiler ad infinitum, it just wouldn't support any newly released devices.

Unfortunately, a side effect of well-meaning modern software methodologies is that bit rot is an intrinsic part of the long term development cycle nowadays.