[sdiy] OT: uC Development Environments

sleepy_dog at gmx.de sleepy_dog at gmx.de
Fri Mar 6 01:30:28 CET 2020


"Setup generator"

these visual MCU configurators several vendors now offer don't just
generate init code for the hardware, they also manage used modules in
the way that you can't accidentally use stuff that would conflict (e.g.
due to special function mux combination restrictions or what have you).
Also, in the ST CubeMX stuff, the clock tree view with all the warning
labels when something is out of bounds somewhere are helpful.

The stuff  does run on Linux, as does their IDE, which is basically
their bought out Atollic TrueStudio, an Eclipse fork with some added
nieceties for embedded dev.

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?")

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..


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".

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.)

So, ideally, in my book, there should be vendor made libraries for it all.
But... to this day, this stuff seems to be made by a mix of interns and
the the new hire out of college, because the HW-biased tech management
people think "aw, well, some libraries that need to be consistent and
stable over time and should have not silly pitfalls by confusing
features and be understood by a million or so - how hard can it be?
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*)".



Jay Schwichtenberg wrote:
> Gordon,
>
> Setup generator. A number of the Eclipse based environments have
> windows that show the processor or board that you've selected. You can
> then select a multi-use pin and say it's a serial or SPI or ...
> interface. It will then generate setup code and load a driver for that
> pin/peripheral. I usually go through the drivers and sometime the
> setup code after it's generated to clean up, optimize and fix.
>
> Other than doing  Arduino boards directly the Arduino IDE isn't
> something I would use. For me it's pretty much way at the bottom of
> the list because as you said it limits what you can do easily and it's
> not really C.
>
> Interrupts can be tricky but a lot depends on what your doing, the
> resources available and the timing requirements. Some times you can do
> every thing in the ISR, sometimes a DPC (Deferred Procedure Call, even
> though this is a Windows thing you do it else where too), sometimes
> semaphores/mutexes are needed, sometimes queues are needed and on and on.
>
> Happy coding.
> Jay S.
>
> On 3/4/2020 11:34 PM, Gordonjcp wrote:
>> On Wed, Mar 04, 2020 at 03:08:52PM -0800, Jay Schwichtenberg wrote:
>>> Gordon,
>>>
>>> That works. But I would prefer an environment that has some sort of
>>> setup
>>> generator.
>>>
>> Not sure what you mean by "setup generator"?
>>
>>> I've found that typically if you have to write setup code and
>>> drivers for
>>> the peripherals you use that can take significantly more time then
>>> writing
>>> the application. That being said I usually leave the setup code
>>> alone and
>> If you're using the Arduino libraries you'll very soon run up against
>> limitations that stem from making it "easy to use" and "works on
>> everything" that get in the way of "doesn't do weird shit".
>>
>> For ARM you really need to look at libopencm3, but I'm not sure if
>> anything similar exists for AVR8.
>>
>> On AVR8 I tend to end up writing everything on bare metal eventually
>> without using anything more than stdlib functions, particularly for
>> things like interrupt handlers where I've generally got a very very
>> specific thing I want it to do - like, for serial interrupts, if it's
>> handling MIDI it has to do the MIDI clock task *right now* right
>> there in the handler, and not queue that byte.
>>
>> Trying to do DSP on an 8-bit 16MHz chip that has only add, subtract
>> and 8x8 unsigned multiply is quite a challenge, and the only reason I
>> bother writing synth code for AVR8 is probably the same reason I like
>> Rubik cubes.
>>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy






More information about the Synth-diy mailing list