Break up the source into smaller module related files

[mleyden]

Source is now ~2300 LOC in a single file. I would recommend breaking it down. A suggestion would be something like this: -Open-Source-Ventilator.ino (main) -config.h (defines) -ui.cpp (implement a Class-based interface that allows other types of display/keyboard to be used) -keyboard.cpp -display.cpp -control.cpp -sense.cpp -pressure.cpp -volume.cpp

[mawais15]

Hi, we are trying to use this code in development of an open source ventilator with some modification but it is really hard to go through all the code in one file. It would be really nice if it could be broken down into multiple files.

[Blimpyway]

I would even go as far as leaving only serial interaction. Have a clear, well defined .. "protocol" between a control unit and an interface unit.

The benefits are several

• The controlling code becomes simpler, clearer with fewer dependencies
• More important it can be tested thoroughly independent of UI parts availability and then closed.
• hardware/mechanical developers can tune specific parameters for their implementation number of steps, type of sensors, etc. without worrying about interface.
• Whoever develops UI-s can pick either a second uC with buttons/lcd talking serial with controlling unit , or phone/laptop based on serial over USB/bluetooth/IP channels can easily test/validate their interface without having to touch the actual controlling code. Or even an android/iphone developer can work at an application without having an actual phisical device to script a test protocol.

[mleyden]

My thoughts on the overall system design. System needs to be tolerant to single faults. See: https://whimsical.com/JBKt1qDAetj2P8nt7EF9nY

[mattd3v]

I have opened PR #30 and begun working on breaking up the source into smaller modules. Would it make sense to put the EEPROM related code into its own Memory module for device independence, or is that unnecessary? At the moment the ee code is spread throughout.

[karx]

@mattd3v I think moving them into a module should help. We can maintain the defaults, error correction, and integrity checking there itself. #6

This would also help in having a single point of persistence state kindof a picture. Should help in keeping the code clean.

The module would have to be top-level type. A shared static class maybe, as I am sure many of the other modules we have in the making would be using.

[karx]

Also, going through the code, I see alot of it is governed by compile-time logic, which seems smart and optimized.

But kindof also gets me rolling in the direction of modularizing in that direction then. Example would be the use of Serial.

It is governed by a few statics: serialTelemetry, serialVerbose, 'ArduinoPlotter', debug level, and a variable called term.

Which makes it quite hard to understand what is happening imo. Let me know what you think.

[mattd3v]

@karx I share many of the same opinions. Especially, regarding the ambiguity created by the compile time directives. I would also like to extrapolate the debugging code from the core logic.

I’d be interested in splitting the task up? Should we create issues for specific tasks?

[karx]

I would also like to extrapolate the debugging code from the core logic.

@mattd3v I would like to know your ideas regarding how to do this.

Sure, if you think you can chunk out a task for me I would like to contribute here.

Although, I must confess here. I am yet to build this project on my local system. Don't have my usual machine, using my brother's laptop actually. I luckily do have the boards in question, avr-boards and a bunch of ESP32s.

But pretty sure would not also have the necessary peripherals to test at my end.

[karx]

In the meantime in order to wrap my head around the codebase, I started to compile these compile-time directives and dynamic variables (haven't reached them yet) into a more readable and sharable format.

https://github.com/karx/Open-Source-Ventilator/tree/kaaro/refactor/configuration

Have a look and let me know if you have any better ideas on how we can make this more readable.

I have in that document also kind of proposed we have a few admin-type settings. These would include those settings/variables that can be updated after deployment, to hotfix/error correct/calibrate/hack the device after deployment on-ground.