You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
...lot of datasheet...
The main thing having skimmed through the datasheets is what you already tackled: timed commands. Each command has its deferred, particularly to interpret response. Common to the responses is that they are of variable length and their end is detected by receiving a null character.
These protocols can be implemented as technical functions/objects working on descriptive data to implement them in a generic way and can be easily reused on a higher level of implementation, for example on the sensor. The dynamic nature of JavaScript comes handy to achieve that.
You can start with each command and related response interpretations as own object. After a few implementations you then factor out repeated/shared function oriented things into service object(s) and specific data/control oriented things into descriptor/specification objects. Factoring out specifics is though not limited to data/control oriented things, a function can be part of it as well, passed as reference to the shared function objects and invoked there. When you 'feel' that things get too complicated or too obscure, you may revert some of the steps and adjust course, or stop all together. Your design should after all reflect the things that you encounter in real and thought world.
Abstraction is not always simplifying complexity, but can make it manageable by creating manageable, robust code. Sounds plausible... but a lot of aspects fold into the term 'manageable'. Each aspects and its weight is derived from the requirements found top down, bottom up, outside in, inside out,...