-
-
Notifications
You must be signed in to change notification settings - Fork 943
Add serial facade #4402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add serial facade #4402
Conversation
✅ Deploy Preview for origin-betaflight-app ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backs up, flashes, connects and does CLI at basically the same speed at which it does on master
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems good to me. Is not the path that I was in mind, but it seems it will work.
I always thougt that part where we must "differentiate" the different serial connections must be the serial_backend. So in the serial_backend we must decide wich serial to use, and connect with it. It must give too the "public" methods (read, write, etc.) for the rest of the code (a kind of proxy to serial) and all the code must use only this public methods. The serial class must be only an interface and must be implemented by the different serial connections.
You have used a different approach. The serial class is the class used by the rest of the code, so the serial_backend is responsible of open/close and serial must be used to read/write. I'm not too sure if this is better or not that my thoughts, I prefer to have all in one place, but it's ok to me.
Great work. I'm sure this was not easy.
I checked a few scenarios: different types of connections and reconnections, they all seem to be OK. |
Are we able to determine whether FC is already connected to another tab or app, and hijack the connection or, at lest notify the user? |
testing is already connected (or already plugged in) would be great, but not a blocking factor for me. since PWA, i've become accustomed to unplugging/plugging when the dialog sits rotating. |
This pull request includes several changes aimed at refactoring the serial communication modules and improving the handling of different device protocols. The most important changes include replacing
serialShim
withserial
, renaming and refactoring protocol files, and improving device event handling.Refactoring serial communication modules:
src/js/msp.js
: ReplacedserialShim
withserial
for serial communication. [1] [2]src/js/msp/MSPConnector.js
: ReplacedserialShim
withserial
for serial communication.src/js/port_handler.js
: ReplacedserialShim
withserial
and refactored device event handling to determine the device type based on its properties. [1] [2]Renaming and refactoring protocol files:
src/js/protocols/VirtualSerial.js
: Renamed fromvirtualSerial.js
and added methods to get connected port and devices. [1] [2]src/js/protocols/WebBluetooth.js
: Renamed frombluetooth.js
and movedbluetoothDevices
to a separate import. [1] [2] [3] [4]Improving device event handling:
src/js/port_handler.js
: Enhanced event listeners to handle device addition and removal based on device properties.src/js/port_handler.js
: Updated methods to useWEBUSBDFU
andWebBluetooth
for USB and Bluetooth devices, respectively. [1] [2] [3]These changes collectively improve the codebase by streamlining serial communication, organizing protocol files more effectively, and enhancing the handling of various device protocols.
Tested so far