Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32302

Re: AM623 experiences

Show all headers | View raw

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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

AM623 experiences Don Y <blockedofcourse@foo.invalid> - 2024-11-23 01:15 -0700
  Re: AM623 experiences David Brown <david.brown@hesbynett.no> - 2024-11-23 13:31 +0100
    Re: AM623 experiences Grant Edwards <invalid@invalid.invalid> - 2024-11-23 19:57 +0000
      Re: AM623 experiences Don Y <blockedofcourse@foo.invalid> - 2024-11-23 16:56 -0700
        Re: AM623 experiences David Brown <david.brown@hesbynett.no> - 2024-11-24 11:42 +0100
      Re: AM623 experiences David Brown <david.brown@hesbynett.no> - 2024-11-24 11:33 +0100
        Re: AM623 experiences Grant Edwards <invalid@invalid.invalid> - 2024-11-24 17:12 +0000
          Re: AM623 experiences Don Y <blockedofcourse@foo.invalid> - 2024-11-24 14:03 -0700
            Re: AM623 experiences David Brown <david.brown@hesbynett.no> - 2024-11-25 11:41 +0100
          Re: AM623 experiences David Brown <david.brown@hesbynett.no> - 2024-11-25 09:37 +0100
            Re: AM623 experiences Grant Edwards <invalid@invalid.invalid> - 2024-11-25 15:18 +0000
              Re: AM623 experiences David Brown <david.brown@hesbynett.no> - 2024-11-25 17:33 +0100
              Re: AM623 experiences Don Y <blockedofcourse@foo.invalid> - 2024-11-25 13:47 -0700
            Re: AM623 experiences pozz <pozzugno@gmail.com> - 2024-11-26 13:10 +0100

csiph-web