在一个半相关的说明中，因为这是自从您将我的状态灯插件添加到您的 plugins.h 以来我第一次构建图像​​，我也能够通过在我的 my_machine 中包含这一新行来简单地添加它。H：

#define STATUS_LIGHT_ENABLE 1 // 启用 RGB 状态灯插件

并重命名我的 init 函数以匹配 plugins.h 的预期内容。我将更新我的 github 以尽快反映更改。

到目前为止一切正常。也谢谢你的改变。

啊，是的，我必须禁用我的 VFD 和 MODBUS 插件才能启用 keypad.c。我只是把 VFD 和 MODBUS 放回去并得到以下错误：

在 src\driver.c:30:0 包含的文件中：
src\driver.h:125:2: error: #error “Only an option that uses the UART serial port can be enabled!”
#error “只能启用一个使用 UART 串​​口的选项！”
^
在 src\eeprom\eeprom_24AAxxx.c:26:0 中包含的文件中：
src/driver.h:125:2: 错误：#error “只能启用一个使用 UART 串​​行端口的选项！”
#error “只能启用一个使用 UART 串​​口的选项！”
^
在包含自 src\encoder\encoder.h:26:0 的文件中，
来自 src\encoder\encoder.c:25:
src\encoder../driver.h:125:2: error: #error “Only one option使用UART串口的可以启用！”
＃错误 ”
^
在 src\eeprom\eeprom_24LC16B.c:24:0:
src/driver.h:125:2: error: #error “Only one option that uses the UART serial port can be enabled!”文件中
#error “只能启用一个使用 UART 串​​口的选项！”
^
*** [.pio\build\teensy41\src\eeprom\eeprom_24AAxxx.co] 错误 1
​​** [.pio\build\teensy41\src\driver.co] 错误 1
​​** [.pio\build\ teensy41\src\encoder\encoder.co] 错误 1
​​** [.pio\build\teensy41\src\eeprom\eeprom_24LC16B.co] 错误 1
​​在 src\fans\fans.c:24:0 包含的文件中：
src /driver.h:125:2: error: #error “只能启用一个使用 UART 串​​口的选项！”
#error “只能启用一个使用 UART 串​​口的选项！”

*** [.pio\build\teensy41\src\fans\fans.co] 错误 1
​​在 src\enet.c:22:0 包含的文件中：src\driver.h
:125:2: 错误：#error “只能启用一个使用 UART 串​​口的选项！”
#error “只能启用一个使用 UART 串​​口的选项！”
^
*** [.pio\build\teensy41\src\enet.co] 错误 1
​​============================== ========= [失败] 耗时 4.34 秒 =================================== ====

UART = 5 的定位毕竟不能解决这个问题。知道是什么原因造成的吗？

抱歉，第一次发生这种情况时我不得不躲开。很明显问题出在哪里 – driver.c 的第 125 行，我能够通过删除该行中的 KEYPAD_TEST 来临时解决它。

似乎逻辑需要考虑使用额外的 UART 作为缓解因素，但这里存在需要解决的操作顺序问题以及应在何处声明辅助 UART。你怎么看？

蜘蛛网正在离开我的大脑。问题是目前没有一种机制可以增加一个以上的 UART，对吗？所以我们似乎需要一个 UART_MODBUS 和 UART_KEYPAD 的概念作为示例，然后我们可以将它们指向正确的位置？

我正在查看 modbus.c 并尝试确定我是否可以使用 MODBUS-SERIAL_PORT 作为替代方法来告诉用户 UART1 仅用于 modbus 流量，但似乎多个并行 UART 尚未完全添加？

但似乎还没有完全添加多个并行 UART？

是和否…我最近在内核中添加了对注册和声明（打开）UART 端口的支持，目前最多四个。STM32F4xx 有最多两个端口的代码，并且用户已经为他的特定需求添加了两个额外端口的插件（并且他有支持该功能的硬件）。目前 iMXRT1062 驱动程序仅支持一个端口，可以添加更多端口——但是要使用哪个 MCU UART 端口/引脚？在没有请求的情况下，我是否应该花时间为驱动程序添加端口？

一些技术细节（我需要开始编写更多文档）：

我添加了一个结构体io_stream_properties_t，它在向核心注册 UART 流时使用。这包含有关端口实现属性的信息，代码可以使用这些属性来查找和声明具有所需属性的端口实现。还有一个instance字段是“端口号”，可用于明确声明端口，例如，通过定义MODBUS_SERIAL_PORT符号由 modbus 插件完成。流通过driver.c调用uart.c中的serialRegisterStreams()向内核注册，而uart.c又调用内核中的stream_register_streams()使端口可发现和可声明。
STM32F4xx代码做的更多因为它为 $pins 命令添加了 pin 信息…

当用户插件代码添加端口时会出现先有鸡还是先有蛋的问题——这些端口在注册之前无法被发现，因此代码顺序变得很重要。是否应该对每个插件进行预初始化调用，或者需要端口的代码是否应该延迟声明直到启动序列完成？后一种选择是我更喜欢的。

因此，仍有工作要做，但我相信，配置 grblHAL 所需的灵活性以及用户插件添加需要 I/O 引脚和 UART 端口的代码的基础已经到位。

@5ocworkshop
我最近开发了一个针对中型触摸屏优化的 webUI。用户界面还具有许多键盘快捷键，如果您熟悉 javascript，也可以轻松编辑这些快捷键。您可以尝试以下链接中的代码并发表您的意见。
https://github.com/karoria/grblTouch

但似乎还没有完全添加多个并行 UART？

是和否…我最近在内核中添加了对注册和声明（打开）UART 端口的支持，目前最多四个。STM32F4xx 有最多两个端口的代码，并且用户已经为他的特定需求添加了两个额外端口的插件（并且他有支持该功能的硬件）。目前 iMXRT1062 驱动程序仅支持一个端口，可以添加更多端口——但是要使用哪个 MCU UART 端口/引脚？在没有请求的情况下，我是否应该花时间为驱动程序添加端口？

好问题。grblHAL2000 板在设计中也有两个 UART。Serial1 连接到 Modbus 接口，Serial8 连接到 40 针 RaspberryPi 接头。Pi 接口的目的是提供一个可扩展的接口，用于开发各种扩展，如替代吊坠、切割声学分析、更复杂的相机相关功能或可能更复杂的 ATC 或其他机器人功能，以防 grblHAL 被更广泛地用作传统 CNC 之外的运动控制系统。

一些技术细节（我需要开始编写更多文档）：

我添加了一个结构体io_stream_properties_t，它在向核心注册 UART 流时使用。这包含有关端口实现属性的信息，代码可以使用这些属性来查找和声明具有所需属性的端口实现。还有一个instance字段是“端口号”，可用于明确声明端口，例如，通过定义MODBUS_SERIAL_PORT符号由 modbus 插件完成。流通过driver.c调用uart.c中的serialRegisterStreams()向内核注册，而uart.c又调用内核中的stream_register_streams()使端口可发现和可声明。STM32F4xx代码做的更多因为它为 $pins 命令添加了 pin 信息…

我试图使用 MODBUS_SERIAL_PORT 但我无法确定在那里使用的正确值是什么以及它如何映射到 UART，或者我可能只是遇到了单个 UART 限制？

我能理解这不是您的优先事项。我最近从路由器升级到 VFD/Spindle，并通过 Pi 在 IR 接口上使用基本的慢跑/悬垂功能。我将查看 STM 代码，看看我是否可以从中改编一些内容以在板上启用第二个 UART。我认为，鉴于 grblHAL 出色的可扩展性，支持两个 UART，一个用于 MODBUS，一个用于附件插件是一个很好的起点。

或者也许我只是遇到了单个 UART 限制？

你之前是。

我将查看 STM 代码，看看我是否可以从中改编一些内容以在板上启用第二个 UART。

基本上它是关于复制大部分现有代码并为第二个 UART 修改它。我SERIAL2_MOD在几个驱动程序中使用符号来保护第二个端口的代码，并试图规范函数名称。大多数用于访问端口的函数现在都是静态的并通过指针结构访问，因此遵守这些命名约定不再那么重要，但我仍然通常这样做。

grblHAL 的可扩展性使其成为一种编程平台，我最近添加了一个HPGL 解释器作为插件– 无需更改核心中的一行代码。我这样做有几个原因，一个是作为核心可扩展性的概念验证（或某种酸性测试？）。