-
-
Notifications
You must be signed in to change notification settings - Fork 930
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
Improve MSP handling #3415
Improve MSP handling #3415
Conversation
haslinghuis
commented
Apr 10, 2023
•
edited
Loading
edited
- Give FC time to react to new settings
- Reduce MSP.timeout from 250 to 50ms
- Reduce timeout from 250 to 200ms
- Add new mspHelper for EEPROM write
6af758f
to
1f1031b
Compare
This comment has been minimized.
This comment has been minimized.
AUTOMERGE: (FAIL)
|
remove when already are ind queue.... but don't you risk, this case: have a long transaktion, put short status request, another long transaktion, you now want same short status since you still have the answer from first - this are with this PR skipped, and you only get an (old) answer to the short status request. |
Sure this needs a lot of testing. But see here how it was before: e87c0ca |
This code sends the callback? Now we have a MSP request and we inform when finished to the caller. With this PR is discarded, do we inform the caller too? |
PR !, you mean request ? or ... |
@McGiverGim good call, this was not handled in original code either. Added callbacks |
1f1031b
to
a4d876d
Compare
This comment has been minimized.
This comment has been minimized.
src/js/msp.js
Outdated
if (callback_msp) { | ||
callback_msp(); | ||
} |
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.
I'm not too sure if this can have some unexpected result. Some pages call the MSP commands at certain order, for example I think remember the VTX tab. With this, if I'm not wrong, it can call the callback way before if it is at the queue. But I suppose this is very similar to the code actual, is that true? I think this works because at the end, only events executed in a timer manner are affected by this.
Another question, this takes into account the parameters to the MSP command? If the same command is called twice with different parameters the second one is ignored?
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.
These are valid concerns.
I think for read
kind of operations this wouldn't matter that much, because it was read and put into FC
or whatever is needed. Though some things require arguments as you mentioned so if reading mutliple things with same command but different request then it would have stale data.
Another thing is putting the data into FC, not 100% of the flow, but would this change mean that if there are 2 MSP commands sending data to FC, only the first one would get executed? So there would be weird state where you'd click something it wouldn't work, then click again for it to be saved?
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.
The code is reverting an experimental fix from @cTn-dev as the concerns are valid but it's how it was e87c0ca
// utilizing callback/timeout system for all commands
// dev version 0.57 code below got recently changed due to the fact that queueing same MSP codes was unsupported
// and was causing trouble while backup/restoring configurations
// watch out if the recent change create any inconsistencies and then adjust accordingly
It's blazing fast - but need to log and test real situations.
🤔 As alternative for dropping last command - if it exists already - we could replace the existing with the new one. For the aux tab had to introduce a timer to stop the objects interval allowing ongoing execution.
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.
If I understand correctly how MSP2_SET_TEXT
works, every command has to be accounted for based on it's payload so we can't discard any of the messages. I know this might be an exception, but if future apis are built in similar way then it might be hard to maintain.
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.
Reverted the code to apply for MSP V1 requests only.
bef6821
to
adf7a9f
Compare
This comment has been minimized.
This comment has been minimized.
9894b2b
to
6edba4d
Compare
This comment has been minimized.
This comment has been minimized.
25e7ccc
to
9e26559
Compare
This comment has been minimized.
This comment has been minimized.
Only as suggestion, now that you are looking at how to accelerate MSP commands, we have a MULTIPLE_MSP command, more info here: #1605 |
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.
Approved, but the MSP_MULTIPLE command that I've mentioned, maybe must be an exception too? It can be used to send different commands to the FC, so it must not be "removed" if there are others in the queue.
|
Firmware buffer size overflow is solved by adding multiple MSP_MULTIPLE_MSP requests so this should certainly not be replaced if not processed before the new request. MSP_MULTIPLE_MSP (would call it MSP_BATCH) has yet no examples for implementation. #1605 🤔 But as the code already allows an ongoing process to continue adding the second command should already work. |
There is one example in the text of the PR. I don't know if it's this what you want. |
091d7fe
to
7de6e40
Compare
7de6e40
to
6b73572
Compare
This comment has been minimized.
This comment has been minimized.
6b73572
to
90a552c
Compare
This comment has been minimized.
This comment has been minimized.
dfd787e
to
3e5d644
Compare
This comment has been minimized.
This comment has been minimized.
Needed to refactor ports tab not using async as settings were not applied. @McGiverGim @nerdCopter not so sure about replacing duplicate MSP requests so dropped that for the moment as clicking other tabs sometimes hung up loading sequence without notice - using a timeout was working but don't want to add another timer as this would still allow duplicates to run. Speeding up communication works good by improving timing. |
i have it installed as my daily-driver, will keep an eye on it. ( |
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.
approving. no known problems.- MSP timeouts, but as expected.
EDIT: dismissed
SORRY, converted PR to |
3e5d644
to
3f1a5f3
Compare
3f1a5f3
to
c1b1e1a
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Do you want to test this code? Here you have an automated build: |
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.
- re-approving
c1b1e1a9
fixes last concern.