Re: AM623 experiences

On 25/11/2024 16:18, Grant Edwards wrote:

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

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.

 One of the problems that the SDK authors have to try to deal with is
that the peripherals have gotten "too" versatile.  They've got a
polled mode, an interrupt driven mode, a DMA mode, a burst mode, a
batch mode, a right-side up mode, an updisde-down mode, and three
compatibility modes so they'll work like products from 40 years ago.
 The SDK "drivers" always try to support all the modes in all possible
combinations and sometimes even allow you to switch back and forth
while the thing is running. They'll have open() and close() methods
for no apparent reason for devices that don't need to be opened or
closed.
 As a result, you end up with 3.5KB of driver for an ADC.
 Then, in the real world. 99.99% of applicatoins only use one very
sepecific mode. You either read the hardware description and write
code from scratch (though the #defines for register offsets are
useful), or you pick your way through the "driver" code for you
particular set of modes/choices to find the handful of lines of code
that you need.
 Rather than providing a full-up "driver" I would find it a _lot_ more
useful if they just provided documented code snippets to perform some
of the basic operations that one needs to perform.
 

You are absolutely correct here.
Manufacturers should employ some developers with experience actually /using/ microcontrollers.  The hardware designers should not be allowed to put in any features that don't pass a "yes, I'd use that" test.  Then the SDK designers (if such people exist) would get similar reality checks.
And the SDK people should learn that the year is 2024.  We don't need C90 compatibility - we want decent /modern/ interfaces using all useful the bells and whistles from C17, C++20, and gcc extensions so we can write safer, clearer and more efficient code.  Leave the shitty macros, void* pointers and run-time checking of compile-time values behind.