Re: AM623 experiences

On 11/24/2024 10:12 AM, Grant Edwards wrote:

On 2024-11-24, David Brown <david.brown@hesbynett.no> wrote:

[And I'm STILL not seeing your posts.  <frown>  Something must
be broken in my server.  Yet the telephone system seems to be
working properly!  Yet another thing to look into...]

Some vendor-supplied toolchains are not bad, but some are definitely
subpar - and often many years behind the versions you get from
manufacturer independent suppliers (like ARM's build of a gcc toolchain,
or commercial gcc toolchains).  The biggest problem with microcontroller
manufacturer's tools is usually the SDK's that are frequently horrible
in all sorts of ways.

I think vendors offer tools for much the same reason as they
write app notes or illustrate "typical applications".  Their
goal is to get you USING their product, as quickly as
possible.  If you  had to hunt for development tools, then
you would likely bias your device selection based on the
availability and cost of said tools.
[I worked with a firm that offered a "development system" (compile/ASM/debug
suite plus hardware ICE, in the days before JTAG and on-chip debug
existed) for an obscure, old processor.  They recounted a story where
a customer purchased said tool -- for a fair bit of money.  And, promptly
RETURNED it with a *nasty* note complaining about the (low) quality
of the fabrication!  Some time later, they REordered the system...
when they discovered there were no other offerings in that market!]
Note the inroads Microchip made (esp with hobbyists) by offering
free/low cost tools for their devices.  I suspect their devices
were not the ideal choices for those applications -- but, the value
of HAVING the tools without spending kilobucks to buy them weighed
heavily in their decisions!

But I agree with your advice - where possible, use ARM's gcc toolchain
build for ARM development.  And make sure your project build is
independent of any IDE, whether it is from the vendor or independent.
IDE's are great for coding, and vendor-supplied IDE's can give good
debugging tools, but you want the project build itself to be independent.

This is a given, regardless.  "Sole source" suppliers are always a risk.
Moving from one ARM to another (vs a totally different architecture)
saves a lot -- but, you are still stuck with the choices the fab made
in what they decided to offer.

What he said, defintely: Avoid vendor-specific IDEs and SDKs like the
plague.
 Demo apps and libraries from Silicon vendors are usually awful -- even
worse than the toolchains. I'm pretty sure they're written by interns
who think that to be "professional" it has to incorporate layers and
layers of macros and objects and abstrcation and polymorphism and
whatnot.

The same is often true of "app notes" for hardware components.
I interviewed a prospective client about a project.  Somewhere
along the line he "proudly" presented his proposed "solution"
(then, what do you need ME for?).
I looked at it (schematic) and replied:  "This won't work."
I.e., there were signals with no driving sources!  He then
admitted to copying it from an app note (said reproduction
later verified to have been accurate; the app note was in error!)
But, you aren't likely going to RUN those apps.  And, libraries
can be rebuilt and redesigned.  So, you aren't at their "mercy"
for those things.
OTOH, if the vendor has some knowledge of a device defect (that
they aren't eager to publicize -- "trade secrets") but their
tools are aware of it and SILENTLY work-around it, then they
have a leg up on a third-party who is trying to DEDUCE how
the device works from the PUBLISHED knowledge (and personal
observations).
E.g., I would be happier knowing that a compiler would avoid
generating code that could tickle vulnerabilities in a
system (e.g., memory) over one that blindly strives for
performance (or ignorance).
Or, a compiler that knows enough about the SPECIFIC processor
(not just the FAMILY) to know how to more finely optimize its
scheduling of instructions.
[The days of expecting the code to just implement the expressed
algorithm are long past.  "What ELSE are you going to do FOR me?"]

As a result I rememeber failing to get a vendor's "hello world" demo
to run on a Cortex-M0+ because it was too large for both the flash and
RAM available on the lower end of the family.  And it wsan't even
using "printf" just a "low level" serial port driver that should have
been a few hundred bytes of code but was actually something like
10KB..

But, if they published that code, you could inspect it, determine
what it was TRYING to do and fix it (or, take a lesson from it).
It's amusing when these sorts of things are treated as "proprietary
information" ("secret").  There's nothing revolutionary in a GENERIC
standard library implementation (though there are varying degrees
of performance that can be obtained from those that are SPECIALIZED)