callback - 为了方便起见，我们可以编辑回调函数HAL_UART_TxCpltCallback吗？

您调用HAL_UART_Transmit_IT以“中断”（非阻塞）模式传输数据。该调用将立即返回，很可能早在数据被完全传输之前。

事件的顺序如下：

HAL_UART_Transmit_IT存储您提供的数据缓冲区的指针和长度。它不会执行复制，因此您传递的缓冲区需要保持有效，直到调用回调。例如，它不能是您将在发生回调之前执行delete [] / free的缓冲区，也不能是您要在回调调用之前从中返回的函数中本地的缓冲区。
然后为该UART启用TXE中断，每次DR（或TDR，取决于所使用的STM）为空并且可以有新数据时，都会发生此中断。书面
这时，中断立即发生。在IRQ处理程序（HAL_UART_IRQHandler）中，将新字节放入DR（TDR）寄存器中，然后将其传输-在UART_Transmit_IT中发生。
< / li>
一旦发送了此字节，TXE中断将再次触发，并且此过程将重复进行，直到到达您提供的缓冲区的末尾为止。
如果发生任何错误，将从IRQ处理程序中调用HAL_UART_ErrorCallback
如果未发生任何错误并且到达缓冲区末尾，则将调用HAL_UART_TxCpltCallback（从HAL_UART_IRQHandler-> UART_EndTransmit_IT）。

关于第二个问题，是否可以“为方便起见”编辑此回调-我想说您可以做任何您想做的事，但必须忍受修改实质上是库的代码的后果：

将HAL升级到较新版本将是一场噩梦。您必须手动重新应用对代码所做的所有更改，然后再次进行测试。在某种程度上，这可以通过某种形式的版本控制（git / svn）甚至补丁文件实现自动化，但是如果您修改的代码被ST更改，则这些补丁可能将不再适用，您必须这样做再次手动完成所有操作。这可能需要重新发现实现的更改方式并从头开始做所有工作。
没有人能够为您提供帮助，因为您的库代码不再匹配其他所有人都拥有的代码。如果您通过修改库代码引入了新的错误，那么任何人都无法重现它们。即使您提供了修改，老实说，我怀疑这里的许多人会费心去应用您的更改并在实践中进行测试。

如果我要表达我的个人意见，那就是这样：如果您认为HAL代码中存在错误，请在本地修复它们并将其报告给ST。在将来的更新中对它们进行修复后，用更新的正式版本完全覆盖您的HAL修改。如果您认为HAL代码缺乏满足您需求的功能或灵活性，则可以在此处选择两个选项：

建议您对ST进行更改。您必须记住，HAL旨在满足“通用”需求。
仅对此特定外围设备不使用HAL。这种“混合”方法正是我个人所做的。在某些情况下，HAL为给定外设提供的功能“足够好”以满足我的需求（在我的示例中是SPI，我完全依赖HAL），而在其他情况下（例如UART），我仅将HAL用于初始化，同时自己处理传输。即使您决定不使用HAL函数，它仍然可以提供一些价值-例如，您可以将其IRQ处理程序复制到代码中，然后调用您的函数。这样，您至少可以跳过开发中的某些部分。