1d4afb5ceSopenharmony_ci# lws meta-drivers 2d4afb5ceSopenharmony_ci 3d4afb5ceSopenharmony_ciAlthough drivers in lws (enabled in cmake by `LWS_WITH_DRIVERS`) provide 4d4afb5ceSopenharmony_ciactual drivers for some devices like I2C OLED controllers, their main job is 5d4afb5ceSopenharmony_cito conceal from user code the underlying OS APIs being used to interface 6d4afb5ceSopenharmony_cito the SoC hardware assets. 7d4afb5ceSopenharmony_ci 8d4afb5ceSopenharmony_ciCMake already allows lws to be platform-agnostic for build, the plat adaptations 9d4afb5ceSopenharmony_ciallow lws to be platform-agnostic within itself for runtime. The lws 10d4afb5ceSopenharmony_cidrivers intend to extend that agnosticism to user code. 11d4afb5ceSopenharmony_ci 12d4afb5ceSopenharmony_ciUsing this technique on supported OSes frees the user code from dependencies 13d4afb5ceSopenharmony_cion the underlying OS choice... for example, although ESP32 is very good, it 14d4afb5ceSopenharmony_cicomes with a highly specific set of apis in esp-idf that mean your code is 15d4afb5ceSopenharmony_cilocked in to esp-idf if you follow them. Esp-idf uses freertos apis for things 16d4afb5ceSopenharmony_cilike OS timers, again if you follow those you are locked into freertos, the 17d4afb5ceSopenharmony_ciend result is your work is non-portable to other platforms and completely 18d4afb5ceSopenharmony_cidependent on esp. 19d4afb5ceSopenharmony_ci 20d4afb5ceSopenharmony_ciLWS drivers provide a thin wrapper to eliminate the OS dependencies while 21d4afb5ceSopenharmony_cistill taking advantage of the work, drivers and maintenance of the underlying 22d4afb5ceSopenharmony_ciOS layer without duplicating them, but bringing the flexibility to retarget 23d4afb5ceSopenharmony_ciyour work to other scenarios... for example, there is a generic gpio object 24d4afb5ceSopenharmony_cisubclassed for specific implementations, an i2c object which may be subclassed 25d4afb5ceSopenharmony_cito use OS drivers or bitbang using the generic gpio object, buttons on top of 26d4afb5ceSopenharmony_cigeneric gpio, led class that can use generic gpio or pwm interchangeably, 27d4afb5ceSopenharmony_ciplatform-specific gpio, i2c, pwm implementations that can be used at the generic 28d4afb5ceSopenharmony_cilevel are defined to use underlying OS native apis and drivers. 29d4afb5ceSopenharmony_ci 30d4afb5ceSopenharmony_ci## Building on the next layer up 31d4afb5ceSopenharmony_ci 32d4afb5ceSopenharmony_ciAt these generic objects like buttons or led controllers, there is a stable 33d4afb5ceSopenharmony_cicodebase used by multiple implementations and the intention is to provide 34d4afb5ceSopenharmony_cibest-of-breed features there generically, like 35d4afb5ceSopenharmony_ci 36d4afb5ceSopenharmony_ci - sophisticated button press debounce and classification 37d4afb5ceSopenharmony_ci 38d4afb5ceSopenharmony_ci - high quality transitions and log-response compensation and mixing for led pwm 39d4afb5ceSopenharmony_ci 40d4afb5ceSopenharmony_ci - display dimming timers, blanking timers, generic interaction detection to unblank 41d4afb5ceSopenharmony_ci 42d4afb5ceSopenharmony_ciwhich are automatically available on top of any implementation that is ported to 43d4afb5ceSopenharmony_cilws drivers. 44d4afb5ceSopenharmony_ci 45