-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Fix OSD task timing when using MSP #13388
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -44,16 +44,16 @@ void serialWrite(serialPort_t *instance, uint8_t ch) | |
} | ||
|
||
|
||
void serialWriteBuf(serialPort_t *instance, const uint8_t *data, int count) | ||
void serialWriteBufNoFlush(serialPort_t *instance, const uint8_t *data, int count) | ||
{ | ||
if (instance->vTable->writeBuf) { | ||
instance->vTable->writeBuf(instance, data, count); | ||
} else { | ||
for (const uint8_t *p = data; count > 0; count--, p++) { | ||
|
||
while (!serialTxBytesFree(instance)) { | ||
}; | ||
// The transmit buffer is large enough to hold any single message, so only wait once | ||
while (serialTxBytesFree(instance) < (uint32_t)count) { | ||
}; | ||
|
||
for (const uint8_t *p = data; count > 0; count--, p++) { | ||
serialWrite(instance, *p); | ||
} | ||
} | ||
|
@@ -107,11 +107,6 @@ void serialSetBaudRateCb(serialPort_t *serialPort, void (*cb)(serialPort_t *cont | |
} | ||
} | ||
|
||
void serialWriteBufShim(void *instance, const uint8_t *data, int count) | ||
{ | ||
serialWriteBuf((serialPort_t *)instance, data, count); | ||
} | ||
|
||
void serialBeginWrite(serialPort_t *instance) | ||
{ | ||
if (instance->vTable->beginWrite) | ||
|
@@ -123,3 +118,14 @@ void serialEndWrite(serialPort_t *instance) | |
if (instance->vTable->endWrite) | ||
instance->vTable->endWrite(instance); | ||
} | ||
|
||
void serialWriteBuf(serialPort_t *instance, const uint8_t *data, int count) | ||
ledvinap marked this conversation as resolved.
Show resolved
Hide resolved
|
||
{ | ||
serialBeginWrite(instance); | ||
serialWriteBufNoFlush(instance, data, count); | ||
serialEndWrite(instance); | ||
} | ||
void serialWriteBufShim(void *instance, const uint8_t *data, int count) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (technically, this function belongs to buf_write.[ch]) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not quite sure what badness we're forcing on the user here. It's common code irrespective of UART implementation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, but this interface is necessary/used only for bufWrite functions. So it is not serial-related, but buf_write related function. |
||
{ | ||
serialWriteBuf((serialPort_t *)instance, data, count); | ||
} |
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.
(this will cause system freeze when someone tries to write more. But it may be better that busy-waiting for long time)
Maybe we can change it into nonblocking-write semantics - just write data the fit buffer and return number of bytes written.
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've checked and the transmit buffer never gets close to filling up, so this is fallback behaviour. Rather than dropping characters this would indeed block and the task would be late and if bad enough detected by the CPU load check. I consider this preferable to random MSP dropped packets and resulting strange undefined OSD behaviour.
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.
And it's worth noting that the check is now only being done once which is more efficient.
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.
Buffer filling is bad - it will cause busy waiting, which will degrade performance. But if some code tries to write more than transmit buffer size, it will immediately crash FC.