Re: AM623 experiences

On 24/11/2024 18:12, Grant Edwards wrote:

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

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

 What he said, defintely: Avoid vendor-specific IDEs and SDKs like the
plague.

I didn't /quite/ say that.  Avoid relying on them for your builds, was what I said.  The last thing you want is your project being dependent on whatever version of the IDE and SDK the supplier provides at a given time.  For a serious project, you want to be able to take a new computer, check out the old source, install the specific toolchain you use for the project, and re-build to get exactly the same binary.  And you want to be able to do that a decade later.
I /do/ make use of parts of SDKs.  But I figure out what I need, and copy the source into my project structure.  The main point is to avoid having your project change because it is linked to some SDK stuff that gets updated by the manufacturer's tools.  Library updates happen when /I/ want them to happen, not on someone else's schedule.
Often, the actual SDK stuff is very inefficient and bizarrely structured.  But it can be convenient for things like initialisation of complex peripherals, and that's fine - you don't (normally) need efficiency during initialisation.  For real-time access - setting your pwm values, using your gpio's, etc., - it is usually best to handle things "manually".
And of course the project build gets controlled by external tools.  I like hand-written makefiles, but cmake or whatever suits is fine.
Vendor-supplied tools can be very useful for debugging, however, as well as being convenient for startup code, device initialisation, examples, and so on.  I am not at all against using them - use every tool you can get hold of that makes your job easier!  But don't make your actual project binaries dependent on them.

 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.
 

Often the demos are terrible, I agree.  And they are often wildly inconsistent.  But that doesn't mean they are completely useless - they can be inspirational too, and can be helpful to see what you are missing when your own code doesn't work.

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

I think the clearest "war story" I have seen of that kind was for a tiny 8-bit device from Freescale.  The chip had perhaps 2K of flash.  Since this was a one-off use of the chip and I didn't want to read more manuals than I needed to, I use the vendor IDE "wizard" to make the initialisation code and a "driver" for the ADC.  The resulting code was about 3.5 KB - for the 2 KB microcontroller.  So I read the manual and found that the ADC peripheral needed one single bit set to make it run as I needed.