-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
AP_Logger: write formats out as required rather than at start of log #27301
AP_Logger: write formats out as required rather than at start of log #27301
Conversation
I like where this is going! |
I would be worth testing with various log parsers, but I think we should be OK so long as were guaranteed to get the format for the message before the message. Certainly the js parser will loose any message before its format. |
944295d
to
9dc672f
Compare
Tested:
.... I think that shows we're OK. Given that WriteStreaming can pop up its head at any point and write out a FMT message, I think the tools already need to cope. |
9dc672f
to
76cffc2
Compare
Of course, I hadn't thought abut it like that. As you say it should be fine. |
Tested on a bench CubeOrange.
|
I've now tested this with a dataflash backend (revo-mini) The interleaving is much more pronounced here:
|
Also works with mavlink backend:
|
76cffc2
to
baea6dc
Compare
Flew this on one of my Bixlers, replay and log-disarmed, 0 packets lost. |
bool AP_Logger_Backend::emit_format_for_type(LogMessages a_type) | ||
{ | ||
// linearly scan the formats structure to find the format for the type: | ||
for (uint8_t i=0; i< num_types(); i++) { |
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.
might as well make a variable for num_types()
We may need to resurrect the
push_log_blocks
stuff here to try to make more room?This might stop us dropping any messages at the start of a log...