[sdiy] OT: uC Development Environments

René Schmitz synth at schmitzbits.de
Fri Mar 6 10:47:42 CET 2020

On 06.03.2020 01:30, sleepy_dog at gmx.de wrote:
> "Setup generator"

> I briefy tried this sort of stuff in PIC world (MPLAB X), and their spit
> out library / config code is buggy and is a close runner up for the Rube
> Goldberg Award with ST's HAL code. (I have nothing against justified
> complexity. I don't like signs of "let's try this architecture concept I
> heard about in class lately, as that means 'it's good', right?")

:) Overengineered software: Then the next guy comes in, he throws it all 
out, or creates another layer to make sense of it. (Or to claim it as his.)

> Although ST's stuff at least wasn't outright buggy for me so far and
> mostly just works - talking bare dev boards (Nucleo, Discovery) here,
> none of the special boards demoing other ICs and having an MCU as an aide.
> If you select in Cube MX to generate "LL" instead of "HAL" based init
> code, what you will get is a lot more lean code and closer to what you'd
> do anyway if you were on your own, just that you don't have to look up
> all the quirky details and internal dependencies of the particular
> hardware, or, as much, let's say..

Cube MX so far has worked for me, which couldn't be said of 
Atmel/Microchips ASF Advanced Software Framework.

> As things currently are, I can understand why a lot of folks still say
> "just look up the damn registers and code the init stuff yourself".

Yes, but some of the middleware drivers are way beyond that, say USB 
CDC... You don't code+debug this from scratch easily.

> Looking at the bigger picture, it is kinda insane, tough, that basically
> tens of thousands of developers are practically implementing the exact
> same code, that's just a readable wrapper around the hardware features,
> and initially stumbling over a few things and burning time.
> On aggregate, this is quite a bad impact on economy, "needlessly".
> Contrasted to the sane scenario - if ONE entity does this sh1t ONCE, and
> most sensibly that one entity is closely tied to the HW manufacturer,
> who will not stumble upon anything and burn time due to
> misunderstandings, because they have close ties to the people designing
> the HW.
> (also, the HW errata (of actually released revs) may turn out smaller
> than otherwise, if they did that, haw haw. Trying to actually eat their
> dry dogfood.)

I think that it would be a start sense if the HW designers would work 
together with application software people, so that the HW is consistent 
across a family. Say the registers of peripherals work the same....
No, sometimes every member of a product family has its own little quirks.

> Let's better not spend real money on that." Or maybe "It's only
> important that the NON-tech managers of our clients, who don't
> understand the difference between libraries and stuff that just looks
> like them, will choose our product because they think half the work is
> done already. So let's spend money at best for that requirement! (those
> poor bastards who get handed this by their boss and have to explain why
> it's not as easy as promised, muahahahahaha *Dr. Evil manic laughing
> committee sounds*)".

You nailed it right there. It's all over the SW industry.


synth at schmitzbits.de

More information about the Synth-diy mailing list