-
Notifications
You must be signed in to change notification settings - Fork 0
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
Alternative: Add configuration commands to MicrobitSerial #201
Conversation
Preview build will be at |
const messageResponse = protocol.processResponseMessage(msg); | ||
if (!messageResponse) { | ||
return; | ||
} | ||
const responseResolve = this.responseMap.get(messageResponse.messageId); | ||
if (responseResolve) { | ||
this.responseMap.delete(messageResponse.messageId); | ||
responseResolve(messageResponse); | ||
} |
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.
As we are struggling with performance, we could avoid doing this on every periodic message by either returning at the end of the if (sensorData) {}
scope or only running this code if sensorData
was undefined
.
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.
Absolutely, thanks. 3dcd962
As per #196 but reuses the request/response code for the handshake and sticks to one listener processing incoming data.
I've dropped the state field for now as we didn't really make much use of it after this change as state is now really held by the caller of the listenToInputServices and states during that call aren't useful anymore. I guess we could use it to ignore unexpected incoming periodic data but I think it's likely fine for the UI to always reflect what's going on with incoming data.
Until we test it for real I have litte/no faith in partial reconnections so planning to leave Rob to try those once his initial work as landed.