您打算将哪种子板/屏蔽用于电机控制？

目前，它只是一个概念证明。但我只需要一些 74HC14 缓冲器来驱动我的 CNC 机器附带的外部控制器。

有趣的尝试。我还想尝试将 GRBL 移植到
Cypress Cortex M0。
我认为这对于在 Git 上发布您的项目也很有用，因此
其他一些爱好者可以从中受益。

2014 年 10 月 27 日上午 1:19，莫菲写道：

我从https://github.com/Smitter/GRBL_LM4F120H5QR下载了项目“GRBL_LM4F120H5QR” 。
我已经为 TI Stellaris Launchpad TM4C123gxl 修改了它，这是一块
12.99 美元的板，带有 80MHz ARM M4 Cortex 处理器。我的代码可以
在：https
://app.box.com/s/qmxffnhcn5sydixzg5g4 未优化但编译大小仍低于 32k。除了通讯我还没有
测试过，但是大部分代码都是从
原始的 GRBL 中重用的。

—
直接回复此电子邮件或在 GitHub
#522上查看。

好消息谢谢。

源代码可从 app.box 链接免费获得，因此爱好者可以从中受益。此外，Code Composer Studio 的工作方式与宣传的完全集成的调试一样，没有代码大小限制，而且是免费的。我的第一个示例程序在启动一个半小时后启动并运行/调试。driverlib.lib 还消除了使用外围设备的麻烦。为芯片的所有部分提供高级功能。这实际上使使用如此复杂的芯片变得相当简单，直到现在，我才停止使用 ARM 处理器。

如果您使用的是 driverlib，您将需要检查许可证，据我所知，它们非常严格。

致 EliteEng：
该许可证对于 driverlib 来说看起来不错。只要您在 TI 嵌入式设备上使用它，您就可以免费使用它。您在内部使用它，即不发布，但这不是问题，因为 TI 会免费提供它。免费无版税。

Atmel 与 Atmel Studio 及其 ASF 具有相同的许可证（类似于 TI 上的 driverlib）

令人惊讶的是，这似乎是常识。

@Moffy抱歉，这就是我所说的限制性的意思，如果您使用 driverlib 移植 GRBL，则许可证将您限制为仅使用基于 TI 的板。

如果您使用 CMSIS，它至少涵盖了所有基于 ARM 的板。

是的，EliteEng，在阅读了一些书之后，我明白了你的观点。CMSIS 更通用。

@EliteEngCMSIS 听起来不错，但我的经验是它效果不佳。

芯片供应商通常有 CMSIS 核心支持。（顺便说一下，以设备命名的 CMSIS 头文件是一个不好的选择。）

但是，如果您想使用 CMSIS 驱动程序（USART，..），那么大多数供应商都没有可用的 CMSIS 驱动程序文件。您会发现很多对 UARTS 的非 CMSIS 支持，但没有 CMSIS 驱动程序包下载。

然后考虑一下，供应商对拥有完整的 CMSIS 支持不感兴趣。CMSIS CORE 对他们来说已经足够了。完整的 CMSIS 对我们的用户有好处，但对当时的供应商来说不是那么好。

在理想的世界中，某个地方会有一个开源存储库，其中包含适用于所有供应商和所有芯片的完整 CMSIS。然后一个简单的 ‘#include “CMSIS.h”‘ 就足以支持所有的芯片。但是没有这样的存储库 CMSIS 只是一个行不通的好主意。

根据定义，CMSIS 不提供外围支持。ARM 是 CPU，而不是外围设备。外围设备特定于每个公司。
Atmel 提供了 ASF，这是一个非常完整的外围设备库。我尝试下载 TI CMSIS 头文件，但无法提取。我想比较外围设备的 API（如果有的话）。

至少你应该得到一致的引脚命名。

在 Grbl 和芯片之间添加一个抽象层（对于第一个可能非常薄）将解决许多问题，因为在移植到新的 ARM 芯片时您不会弄乱 Grbl 本身。更改将在通用 api 模块中进行，例如中断设置、usart 等。如果您提前考虑使用第二个供应商，则需要付出更多努力，但会付出巨大的代价。

刚刚查看了 TI CMSIS 头文件，它们只是引脚名称/端口名称等。不过，看看 drivelib API，从表面上看，它似乎可以或多或少地将这些调用映射到 ASF 调用。这就是抽象层发挥作用的地方。
需要大量阅读:-) Atmel 芯片非常复杂，没有看过 TI 的。

CMSIS 不仅仅是 CMSIS 核心。如果你看这里：
http ://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php

CMSIS 有：

• CMSIS 核心
• CMSiS SVD
• CMSIS 行动计划
• CMSIS-DSP
• CMSIS RTOS-API
• CMSIS-DRIVER-API <- 这个很方便。

在那个图片中，grbl 将是应用程序。所以CMSIS的理念是“应用程序”使用“CMSIS Driver-API”。Driver API 使用 Device HAL（由供应商创建）来访问外围设备。

那么 Atmel 是否提供了使用 ASF 的 CMSIS Driver-API？TI 是否提供使用“drivelib API”的 CMSIS 驱动程序 API？

我认为两者的答案都是否定的。这就是我的观点。使用 CMSIS 意味着使用 CMSIS 驱动程序 API 来实现读取和写入串行线路的代码。然后，硅供应商将需要提供 ARM 所称的“设备 HAL”。那么在哪里可以下载 Atmel/TI 设备 HAL？

因此，如果您同意 CMSIS 已损坏，那么是的，瘦 API（HAL-硬件抽象层）可能是最好的选择。然后可以为 grbl 和 Atmel ASF 和 TI drivelib 定制这个 API 来实现它。但这不是CMSIS，…

我昨晚阅读了 Atmel ASF 文档，我需要将它的作用映射到 CMSIS 总体图。（是的，我忽略了与 Grbl 无关的 DSP 等）我认为 ASF 是 CMSIS 驱动程序，但我需要执行下一步。TI似乎只有一些-Core和-DSP，没有别的。但是我也没有下载TI的工具链。DriverLib 可能是他们对 CMSIS-Driver 的想法，但同样，我需要在下周左右进行适当的查看。
不是 CMSIS 会被破坏，而是供应商支持参差不齐 但结果是一样的，在供应商之间移动并不容易。还有更多，我想在开始我的港口之前再花一周的时间阅读和涂鸦。Atmel D21 最先出现，主要是由于最佳 (IMO) 开发工具支持。

@gerritv @Moffy一个很好的起点将是这个https://github.com/microCNC/GRBL_ARM/tree/Dev，目前它基本上可以工作，但在执行所有 gcode 后尝试进入空闲状态后挂起。

它适用于 TM4C123 板，但想法是将其移植到基于 Atmel 的板上。

cpu_map.h 是可以将供应商命名约定更改为通用 GRBL 命名约定的地方。

startup_BOARD 是可以执行所有硬件启动代码的地方（启用端口和中断）

这段代码只是一个起点，只是为了在整理 GRBL v1.0 的重新结构时准备好代码。

谢谢你。很快我就会有信息过载并触发断路器:-)
我会将最后一个添加到我的组合
中……你的端口使用什么开发工具？
谢谢

我使用 linux vmware 映像进行开发，因此它是一个单独的开发环境。

Gedit 用于编码（实际上是任何文本编辑器）
arm-gcc-none-eabi
为 Atmel SAM 编译 LM4Flash 到 Flash（仅限 TI），您将使用 bossac（需要对 makefile 进行修改）

Thx，那对我没有帮助:-)我只在 Windows 上工作，并尝试坚持使用基于 Visual Studio 的工具。即使通过不同的路径，我们最终都会到达那里。

您可以在 Visual Studio 中编码，然后在命令行上编译和闪烁。

Arduino Due 使用 arm-gcc-eabi 和 bossac 编译和烧写（你可以从 Arduino repo 获取可执行文件）

否则，即使您确实使用了另一个 IDE，您也会发现它很可能使用 GCC 进行编译。

归根结底，无论您使用什么开发工具，“代码库”都应该是相同的。

没错，我只是更喜欢 VS 的编码支持和调试方便。正如你所说的 gcc，Atmel Studio 在下面是 VS。在他们的演示板上添加硬件级别调试，我会很高兴的。董事会将在 12 月下旬到达，让我在冬天编码。

以我的经验，makefile 是允许每个开发人员使用他选择的 IDE 的好东西。

Visual Studio 应该能够处理 makefile 项目。因此 gerritv 可以在与 EliteEng 使用 gedit 相同的代码库上使用 VS。

对于那些感兴趣的 Eclipse 可以使用 Makefile 项目并在 Linux 和 Windows 上运行，…

哇，要涵盖的内容太多了！是的，CMSIS 是 TI 的一个破损标准，在该标准中实施最少。他们使用了自己的 DriverLib，它非常全面，可能与 CMSIS 有很多相似之处。

然后是这个：https ://github.com/libopencm3/libopencm3这可能只是你需要停止担心“哪个 ARM？”的 HAL。;)

快速浏览一下，我看不出他们如何允许像 grbl 这样的项目支持他们所有的处理器。

然后我看到“该库的 API 尚未被认为是稳定的！请不要依赖它！”
他们还说 python 将用于生成一些代码，但我在他们的存储库中没有找到任何 python 代码。

也没有文档可以解释我如何编写一个软件，然后在多个不同的 cpu 上运行。

@csdexter你知道更多吗？

@csdexter他们还有很长的路要走，甚至可以使用，更不用说稳定了。
http://libopencm3.org/wiki/Status

但值得关注。

我是那些看到杯子半满的人之一 有一个库涵盖了 grbl 使用的基本东西（UART、定时器、GPIO），它是跨 CPU 的，对我来说听起来像是一份圣诞礼物。当然，它仍在开发中，API 可能确实会发生变化，但是是什么阻止您在发现可用并从那里开始工作的提交时冻结它？

开箱即用总是一个好主意：这是我们正在谈论的嵌入式系统，而 grbl 是一个裸机应用程序，因此 .DLL/.so 类的语义不适用。在你用冻结的快照编译和运行它之后，你可以悬赏让某人成为 grbl <–> libopencm3 关系的维护者，这样你就可以在有意义的时候继续跟踪他们的 HEAD。

@JustAnother1它的工作方式与 avr-gcc 类似-mmcu，IIRC 有一种#define或类似的机制，您可以通过它告诉库要包含哪些特定于 CPU 的头文件以及要使用的链接器脚本。

@csdexter 因为我没有找到文档，所以我查看了这个示例：
https ://github.com/libopencm3/libopencm3-examples/blob/master/examples/stm32/f4/stm32f4-discovery/usart/usart.c

这里面有很多 ST 特定的东西。如果这是示例，我不知道“–mmcu”方法应该如何工作，..

我同意认为所有其他解决方案并不完美只是作为自己推出自己的借口是不好的。而且我也认为使用某种 HAL（硬件抽象层）会很好。

但对我来说，这种 HAL /lib/whatever 最重要的特性是我可以编写其中包含类似“uart_send(“ok”)”的代码，并且其中没有硬件相关代码。

有人在我们将使用的东西上工作实际上是一件好事。在我看来，API 的变化也不算太糟。但是我看不到如何使用 libopencm3 编写与 CPU 无关的代码。这对我来说是一个nogo。

可以有编译器开关、cpu 依赖的配置文件，甚至是自动生成的代码。但它需要有一个独立于cpu的API。如果我们找到一个可以做到这一点的库，那么让我们一起去吧。IF libopencm3 可以做到这一点，而不是让我们使用它。否则我会继续寻找这样的库。

我同意uart_send("ok");，但您仍然需要处理一个特定 MCU 具有 1 个 UART 而另一个具有 3 个 UART 的情况。我认为拥有一个始终做正确事情的通用 API 在编程上是不可行的，我认为中间立场是拥有一个独立于 CPU 的 API 来使用其资源（即get_uart_count();，后跟uart_send_on(FIRST_UART, "ok");）并使用每个 CPU（甚至每个板） ) 头文件将其映射到通用标识符，这与 grbl 今天对 GPIO 映射的编码方式非常相似。

作为记录，我不久前开始研究这样的 HAL，虽然 grbl 方面很好，花花公子，但 HAL 方面很快就变得丑陋了。幸运的是，所有介入的“垃圾”都被预处理器迅速优化到几乎没有，但看起来仍然很难看，更不用说如果你必须调试东西会变得多么有趣。

编写和使用 HAL的根本问题在于，对于相同的模块来说它非常简单和漂亮，而对于略有不同的模块来说却非常丑陋和困难。例子：

• （相同）无论需要多少准备（计算指令数量），您始终可以编写一个始终做正确事情reset_cpu();的HAL 函数
• （不同）无论你多么努力，编写一个总是做正确事情set_timer(mode, prescaler, trigger, outputs);的HAL 函数总是很丑陋。您要么必须放弃一些可移植性并添加选择特定计时器的选项（具有每个 CPU 的头文件，该头文件是正确的计时器 ID 的符号常量），要么编写大量丑陋的基于预处理器的代码以允许您请求硬件模块通过它们的功能，例如#definetimer = timer_by_properties(TIMER_16BIT, TIMER_PWM, TIMER_INTERRUPT, TIMER_OUTPUT_ONE);

我的建议是拥有硬件相关的配置文件。在该文件中，可以完成功能和硬件之间的映射。就像
#define TEMPERATURE_SENSOR_HEATED_BED ADC2
#define TEMPERATURE_SENSOR_EXTRUDER_1 ADC1
…
这样代码就不需要知道这个 CPU 中有多少个硬件 UART。这也解决了“我的应用程序需要 2 个 UART 但 get_uart_count() 返回 1”的问题。

我不明白的另一点是为什么 HAL 程序员总是认为仅仅因为有一个 UART 硬件，他们就需要一个 UART 驱动程序来匹配所有功能。

@csdexter因为你有经验。你知道为什么没有人想出不同的软件驱动程序然后起诉同一个硬件模块吗？就像进行轮询和阻塞的 UART 驱动程序一样。另一个死掉的中断基于基于事件的传输，..这不会减轻“不同的硬件 – 复杂的 HAL”问题吗？

您在上面描述的称为“微型端口驱动程序”，并且确实在今天发生，但在比 MCU 更智能的机器上。Linux 和 Windows 都将某些部分实现为微型端口，其中通用功能（例如为 802.11 进行 WPA2 握手）在一个模块中实现，并且只有非常低级别的东西在微型端口驱动程序中实现——尽管，对于其余的操作系统，（通用+微型端口）对似乎是一个连续的驱动程序。
在某些情况下，微型端口被简化为要发送的命令列表（如原始二进制值），以便让硬件执行预定义的操作；在其他情况下，微型端口包含实际的代码和逻辑。

将如此详尽的泛化模型应用于嵌入式世界的问题在于，事物是如此之小，以至于每个闪存字节和每个额外的函数调用都很重要。我们在非嵌入式世界中认为理所当然的大多数事情，例如在运行时发现和枚举事物，然后动态绑定行为与资源，在嵌入式环境中无法真正存在，因为您最终会被 HAL 占用比应用程序本身更多的空间:)

回到 grbl 的需求，我相信可以为它编写一个 HAL，这并不意味着浪费闪存和/或破坏兼容性。IIRC 至少有两个不同的模拟器分支，它们基本上实现了相同的目标：让 grbl 在 AVR 以外的其他东西上编译和运行。在这些实现和我的 HAL 分支之间的某个地方，为将 grbl 的核心代码与特定于平台的东西分开奠定了中间基础，从而获得了一块 ANSI C，它可以移植到您为其编写 HAL 并具有 C 编译器的任何体系结构： -)