1*1c60b9acSAndroid Build Coastguard Worker# lws meta-drivers 2*1c60b9acSAndroid Build Coastguard Worker 3*1c60b9acSAndroid Build Coastguard WorkerAlthough drivers in lws (enabled in cmake by `LWS_WITH_DRIVERS`) provide 4*1c60b9acSAndroid Build Coastguard Workeractual drivers for some devices like I2C OLED controllers, their main job is 5*1c60b9acSAndroid Build Coastguard Workerto conceal from user code the underlying OS APIs being used to interface 6*1c60b9acSAndroid Build Coastguard Workerto the SoC hardware assets. 7*1c60b9acSAndroid Build Coastguard Worker 8*1c60b9acSAndroid Build Coastguard WorkerCMake already allows lws to be platform-agnostic for build, the plat adaptations 9*1c60b9acSAndroid Build Coastguard Workerallow lws to be platform-agnostic within itself for runtime. The lws 10*1c60b9acSAndroid Build Coastguard Workerdrivers intend to extend that agnosticism to user code. 11*1c60b9acSAndroid Build Coastguard Worker 12*1c60b9acSAndroid Build Coastguard WorkerUsing this technique on supported OSes frees the user code from dependencies 13*1c60b9acSAndroid Build Coastguard Workeron the underlying OS choice... for example, although ESP32 is very good, it 14*1c60b9acSAndroid Build Coastguard Workercomes with a highly specific set of apis in esp-idf that mean your code is 15*1c60b9acSAndroid Build Coastguard Workerlocked in to esp-idf if you follow them. Esp-idf uses freertos apis for things 16*1c60b9acSAndroid Build Coastguard Workerlike OS timers, again if you follow those you are locked into freertos, the 17*1c60b9acSAndroid Build Coastguard Workerend result is your work is non-portable to other platforms and completely 18*1c60b9acSAndroid Build Coastguard Workerdependent on esp. 19*1c60b9acSAndroid Build Coastguard Worker 20*1c60b9acSAndroid Build Coastguard WorkerLWS drivers provide a thin wrapper to eliminate the OS dependencies while 21*1c60b9acSAndroid Build Coastguard Workerstill taking advantage of the work, drivers and maintenance of the underlying 22*1c60b9acSAndroid Build Coastguard WorkerOS layer without duplicating them, but bringing the flexibility to retarget 23*1c60b9acSAndroid Build Coastguard Workeryour work to other scenarios... for example, there is a generic gpio object 24*1c60b9acSAndroid Build Coastguard Workersubclassed for specific implementations, an i2c object which may be subclassed 25*1c60b9acSAndroid Build Coastguard Workerto use OS drivers or bitbang using the generic gpio object, buttons on top of 26*1c60b9acSAndroid Build Coastguard Workergeneric gpio, led class that can use generic gpio or pwm interchangeably, 27*1c60b9acSAndroid Build Coastguard Workerplatform-specific gpio, i2c, pwm implementations that can be used at the generic 28*1c60b9acSAndroid Build Coastguard Workerlevel are defined to use underlying OS native apis and drivers. 29*1c60b9acSAndroid Build Coastguard Worker 30*1c60b9acSAndroid Build Coastguard Worker## Building on the next layer up 31*1c60b9acSAndroid Build Coastguard Worker 32*1c60b9acSAndroid Build Coastguard WorkerAt these generic objects like buttons or led controllers, there is a stable 33*1c60b9acSAndroid Build Coastguard Workercodebase used by multiple implementations and the intention is to provide 34*1c60b9acSAndroid Build Coastguard Workerbest-of-breed features there generically, like 35*1c60b9acSAndroid Build Coastguard Worker 36*1c60b9acSAndroid Build Coastguard Worker - sophisticated button press debounce and classification 37*1c60b9acSAndroid Build Coastguard Worker 38*1c60b9acSAndroid Build Coastguard Worker - high quality transitions and log-response compensation and mixing for led pwm 39*1c60b9acSAndroid Build Coastguard Worker 40*1c60b9acSAndroid Build Coastguard Worker - display dimming timers, blanking timers, generic interaction detection to unblank 41*1c60b9acSAndroid Build Coastguard Worker 42*1c60b9acSAndroid Build Coastguard Workerwhich are automatically available on top of any implementation that is ported to 43*1c60b9acSAndroid Build Coastguard Workerlws drivers. 44*1c60b9acSAndroid Build Coastguard Worker 45