Microchip have dropped the ball. Is ST going to be any better?

[AndyC_772]

Many STM32 peripherals are so packed with features in silicon that the sheer number of config permutations means that a library to do every task would be massive, buggy and most options would never be used.

I liken the libraries to a tour guide or interpreter in a foreign country. They speak a language that's easy for you to understand, but also have the skills to communicate somewhere where you can't.

What you want is someone who can carry out simple instructions for you. Things like "buy a train ticket to <place>, returning tomorrow", or "order the chicken with spicy noodles". Ideally, you don't want to have to navigate and understand the transport network of a foreign city, or learn which characters represent recognisable food vs things you'd rather avoid.

Imagine, though, the usefulness of a guide whose response was "sure, no problem, you tell me exactly which words to say, and I'll say them for you". 

That's about the level of the ST libraries. You need to provide the a contents of a data structure which maps very closely to the underlying register interface, and as do that, you might as well RTFM and just program the hardware yourself.

The irony is, it's just not that hard. (Just don't try and learn the timers first, especially the complex ones... <shudder>)

[NorthGuy]

They speak a language that's easy for you to understand, but also have the skills to communicate somewhere where you can't.

It's rather the opposite - they translate from well-documented language of the datasheet to undocumented language of library implementers.

It's like watching an English movie which has been synchronously translated to Spanish. You can either try to make sense of foreign Spanish words, or you can try to listen through the translation to catch some English words in the background. Either way, it would be much easier to watch if the Spanish translation was simply removed.

[techman-001]

Many STM32 peripherals are so packed with features in silicon that the sheer number of config permutations means that a library to do every task would be massive, buggy and most options would never be used.

I liken the libraries to a tour guide or interpreter in a foreign country. They speak a language that's easy for you to understand, but also have the skills to communicate somewhere where you can't.

What you want is someone who can carry out simple instructions for you. Things like "buy a train ticket to <place>, returning tomorrow", or "order the chicken with spicy noodles". Ideally, you don't want to have to navigate and understand the transport network of a foreign city, or learn which characters represent recognisable food vs things you'd rather avoid.

Imagine, though, the usefulness of a guide whose response was "sure, no problem, you tell me exactly which words to say, and I'll say them for you". 

That's about the level of the ST libraries. You need to provide the a contents of a data structure which maps very closely to the underlying register interface, and as do that, you might as well RTFM and just program the hardware yourself.

The irony is, it's just not that hard. (Just don't try and learn the timers first, especially the complex ones... <shudder>)

Nice analogy!

I agree, it's not that hard especially as all the STM32 peripherals I've used have sensible defaults and almost run by themselves.

You're right about the timers, they're quite the perfect example of endless config permutations. I made up the list below to show which ones are the more complex, with TIM 1 being the winner and TIM6 the least complex.

For those not familiar with bitfields, every bitfield below represents a timer configuration choice.


    TIM1
            22 registers
            127 bitfields

    TIM2
            20 registers
            107 bitfields

    TIM3
            20 registers
            107 bitfields

    TIM6
            8 registers
            13 bitfields

    TIM14
            12 registers
            27 bitfields

    TIM15
            18 registers
            78 bitfields

    TIM16
            16 registers
            57 bitfields

    TIM17
            16 registers
            57 bitfields

[Jan Audio]

Because if one wants support for the latest parts then there is no choice but to upgrade MPLAB. And of late it's a cyclical problem of upgrading to fix bugs that were introduced when we upgraded to fix bugs....

What do you mean, cant you install the latest compilers in old MPLAB ?
I use the latest version 2, and like to buy the latest chips sooner or later.
Thanks for the warning.

Is there a support list per MPLAB ?
I still hope you wrong on this.

[Mangozac]

Because if one wants support for the latest parts then there is no choice but to upgrade MPLAB. And of late it's a cyclical problem of upgrading to fix bugs that were introduced when we upgraded to fix bugs....

What do you mean, cant you install the latest compilers in old MPLAB ?
I use the latest version 2, and like to buy the latest chips sooner or later.
Thanks for the warning.

Is there a support list per MPLAB ?
I still hope you wrong on this.

My problem isn't with compilers - we actually rarely have issues there! All of the issues of late have been with the programming tools.

[Bassman59]

It's silly to blame vendors. The situation is the direct consequence of dominant programming paradigm (you know "don't reinvent the wheel" and that sort of things). Instead of working software, you just get a pile of assorted wheels which are kept together purely by magic and can come crashing on you any second. The developers hardly have any control of the creatures, so hoping that they ever be able to fix the majority of bugs is purely delusional.

Quite right!

I don't completely agree with the fact the vendors are not to blame though - this still is their choice and their responsibility. But I admit it's become very hard to go against the wind when it comes to software development these days...

Like, a bunch of us may be very irritated that they almost all use Eclipse as their base IDE, but you'll also run into many users that absolutely WANT Eclipse, and since it's trendy... it's hard for a vendor to offer anything else.

So, the trend is to blame certainly, but the vendors have their part too, and lastly, the users as well!!

I think the vendors who provide software tools based on Eclipse do so because users demand multiplatform tools. gcc can be compiled for any of the three operating systems, so that's covered. Segger's J-Link works on all three OSes. And Eclipse runs equally well on Windows, macOS and Linux. Being that it's easily extended and customized makes Eclipse attractive for the silicon vendors who want to cover all of those bases.

So, yeah, I seem to have a half-dozen installs of Eclipse on my workstation ...

[brucehoult]

I think the vendors who provide software tools based on Eclipse do so because users demand multiplatform tools. gcc can be compiled for any of the three operating systems, so that's covered. Segger's J-Link works on all three OSes. And Eclipse runs equally well on Windows, macOS and Linux. Being that it's easily extended and customized makes Eclipse attractive for the silicon vendors who want to cover all of those bases.

So, yeah, I seem to have a half-dozen installs of Eclipse on my workstation ...

There certainly are a lot of customers who seem to love and demand Eclipse. I can't stand it myself. But we (SiFive) provide an Eclipse-based IDE.

Before Eclipse, we supported the Arduino IDE for the HiFive1. It is also cross-platform, and is very very easy to get started with. It's hard to regard it as "professional", though.

More recently, we  (along with Western Digital) dropped some sponsorship money on the PlatformIO people to make their product completely free for any one to use, with any supported SoC family (currently 34, including not only multiple RISC-V but also AVR, Espressif 32 & 8266, Intel 8051, PIC32, MSP430 and of course a bunch of ARM vendors), on a wide range of IDEs/editors including Cloud9, Codeanywhere, Eclipse Che, Atom, CLion, CodeBlocks, Eclipse, Emacs, NetBeans, Qt Creator, Sublime Text, Vim, Visual Studio.

We recommend using it with VS Code, but there is a wide choice.

PlatformIO claim 744 different boards are supported.

Sadly, traditional PIC is one of the few popular things not supported.

[boz]

Had to install the latest MPLABX and XC8 and XC16 on my new Windows 10 laptop to update a project to a new dsPIC chip the old MPLAB did not support. It Installed much easier than the first time I tried it about 2 years ago in fact I dont recall any issues/errors; The new pickit 4 programmer I bought to replace my ICD2 connected OK and the project upgraded compiled and programmed much the same as the old with only a slight increase of a few bytes in code and RAM.

I guess the story is different people/environments/targets have different problems and I was just lucky as I dont push past programming and simple debugging. I have looked at the newer 32 bit development boards and have been tempted by the crazy specification/prices of the newer Atmel and STM devices but have yet to move beyond 8/16 bits for commercial projects as we never get close to hardware limits.

I dont think I would drop a manufacturer or ecosystem just because they dropped the ball occasionally or you would always be moving and never get any shit done.

[westfw]

All of the issues of late have been with the programming tools.

Oh.  That presumably means that most of the discussion has been pretty useless...

We use the full spectrum of Microchip parts, from 8 pin PIC12 right up to PIC24 and PIC32.

I would expect that from a programming tool point of view, a vendor with essentially two device families and three programming protocols (JTAG, SWD, and whatever STM8 uses) would have fewer bugs than the full range of Microchip devices.

Although I've noticed that while JTAG/SWD is theoretically common across lots of chip, it doesn't actually include flash programming - that's normally done either by manipulating the internal NVM controller registers/etc, or by loading actual target code into RAM and letting it run.  That means that you can run into situations where YOUR particular tool/target combination doesn't actually have all the bits needed to achieve programming.  Theoretically (again), you can do it yourself in some "generic" way using something like OpenOCD.  But that can be a pain when you're trying to get things to work, and your IDE doesn't interface to your generic tool, and...