-
-
Notifications
You must be signed in to change notification settings - Fork 65
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
Implement Mizz Zee v2.1 protocol #602
Conversation
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.
@blackspherefollower is the final reviewer on this 'cause they handle all of our device code, just figured I'd add my thoughts for using atomics since these are sinple integer types.
I might not get in front of a real keyboard until tomorrow, but the big thing I think wants changing is that the vibrate command handler should probably return the new vibration command after setting it for the loop. That way you don't have to do any of the last value checking in the loop and the loop can sleep longer and use fewer cycles. |
I got to a keyboard! I also happened to receive a new metaXsire device with a very similar command pattern, that's got a lot of the same repeating pattern: e6ef63f#diff-4fe286dab6c3ad0e0859445fcfdd7c65df07182b80998fe850f936451b0cf2f0 |
@qdot I think my comments are all addressed within reason. I think this can probably land. |
@SuhEugene FYI my hardware has arrived, so I'm able to test now, and I don't think this is behaving as expected: it feels like there's weird lag (like it's not always stopping) and worse, when I restart my test app after controlling the hardware but not restarting the device, it ignores commands outright. Did you see anything like this in your testing? |
I implemented it as a new protocol because I'm afraid of breaking something that already exists.
This is my first time using Rust so I'm sorry for making your eyes bleed.
Protocol documentation: