Hi
To build the application that you have in mind:
1. Disable #define ETH_INTERFACE to remove everything to do with Ethernet and the TCP/IP stack
2. #define USB_INTERFACE, #define USB_DEVICE_SUPPORT #defined USE_USB_CDC, #define USE_USB_MSD, #define SDCARD_SUPPOT [adds CDC-MSD composite with access to SD card]
3. #define SUPPORT_ADC, #define TEST_ADC, #define TEST_AD_DA shows regular single shot sampling and in/out limit (see the ADC/DAC document) and a DMA based sample to DAC (when DAC available or to a PWM output which can be RC filtered to extract the analogue level) (if USB audio is enabled it will also send it to a USB loudspeaker)
4. With #define USB_SERIAL_CONNECTIONS (and #USB_CDC_DEVICE_COUNT set to a higer value) the USB CDC will have multiple CDC interfaces and perform multiple USB<->UART bridges. UART is interrupt or DMA driven and there is usually a command line interface on one as standard. UART parameters are controlled by USB host and can be changed in real-time on the command line interface. [Options for HW or SW flow control, RS485 and single-wire or Modbus if #define USE_MODBUS and either #define MODBUS_RTU and/or #define MODBUS_ASCII are enabled]
5. With #define I2C_INTERFACE there are about 10 standard slave devices to chose from (like accelerometers, EEPROM, port expanders) but I don't have a discovery reference today
6. With #define SUPPORT_PORT_INTERRUPTS and #define IRQ_TEST each GPIO can generate an individual interrupt callback (each one can be enabled/disabled as required and their interrupt level,edge set up). With #define DMA_PORT_MIRRORING some GPIO inputs can use DMA to mirror their state to other ports - see also the video: https://youtu.be/zNWIG-O7ZW0
7. HW driven SW timer lists are integrated in the uTasker OS and usually use the SYSTICK (but can be configured to use other HW timers if there is a reason to do it - on Kinetis parts the low power timer was sometimes used in place since it allows lower power consumption and continued operation when the processor is using very low power modes (since the LPTIMER continues to run in these states)
8. Various HW timer delays that can be triggered from GPIO input changes are available but maybe no reference that exactly matches
9. #define SUPPORT_PWM_MODULE and #define TEST_PWM will generate various PWM outputs based on either GPT or FlexPWM
10. #define SUPPORT_TIMER and #define TEST_CAPTURE shows input pulse measurements (the HW timer document explains various methods also using DMA or PWM value determination)
11. Presently there is no specific quadrature input reference
12. #define SDCARD_SUPPORT includes SD card and FAT operation and a DOS like interface on the command line interface for file system usage (if FTP, HTTP are enabled these can also directly access the SD card). It uses utFAT which has more features that FatSF (like undelete, file analysis, LFN patent workaround - see utFAT document).
With #define USB_INTERFACE, #define USB_HOST_SUPPORT #defined USB_MSD_HOST the same is true for memory sticks (both memory stick and SD card are usable if all are enabled at the same time whereby the SD card will be disk
13. #define SUPPORT_RTC enables RTC and its time/date can be configured on the command line interface. If SNTP or time server are enabled (and the TCP stack is running over Ethernet, RNDIS or WiFi or a 4G modem - which can also be enabled) the time will be updated from these sources. See the "time management" document.
14. Some specific things may not be possible and that is where the developer adds the code to to what remains.
In addition there are various LCD solutions (graphic stuff, CANopen, DMX, and numerous other things that have been integrated over the last 15 years based mainly on real industrial product requirements and the goal is to allow all of these to be used seamlessly on almost any of the supported devices that supply the needed peripherals. In some cases there may be peripheral conflicts due to lack or resources but these are logical restrictions and not necessarily errors in the concept).
So the above configuration can be made to maybe get 50..80% of generally needed functionality, which can work on any Kinetis or i.MX RT parts with no additional work. There is a simulation model for each part and the majority of the configurations can be tested in the simulation environment without needing to do anything on the HW for the moment. The developer now adjusts and adds what else is needed to shape the final product with the overall aim to get the product reliably "finished" faster than the competitors (using other methods).
Of course there will never be everything that one would like to have immediately since that would be an illusion and impossible to realise and maintain. But there is a lot to accelerate developments. There is of course a certain amount of code included which the configuration controls but it is not overwhelming or over powering. From the user's perspective this is how the project looks - it is designed to hide the bigger details and so keep things fairly simple:
At the end of the day it is one of various solutions - some might find it good and some might find it bad but it can usually (even drastically) improve development efficiency and decrease costs. This means that it is worth considering if these are of concern.
Regards
Mark