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