您打算使用哪种子板/屏蔽来进行电机控制？

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

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

在 27/10/2014 凌晨 1:19，Moffy 写道：

我从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，您将需要检查许可证，据我所知，它们非常严格。

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

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

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

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

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

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

@EliteEngCMSIS 听起来不错，但我的经验是它并没有那么好用。

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

但是，如果您想使用 CMSIS 驱动程序（USART，..），那么大多数供应商都没有可用的 CMSIS 驱动程序文件。您会发现很多非 CMSIS 对 UARTS 的支持，但没有 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 DAP
• CMSIS-DSP
• CMSIS 实时操作系统 API
• CMSIS-DRIVER-API <- 这一个可能很方便。

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

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

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

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

我昨晚阅读了 Atmel ASF 文档，我需要将它的作用映射到 CMSIS 总体图上。（是的，我忽略了与 Grbl 无关的 DSP 等） Offhand 我认为 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 用于将 LM4Flash 编译
为 Flash（仅限 TI）用于 Atmel SAM 您将使用 bossac（需要对 makefile 进行修改）

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

您可以在 Visual Studio 中编写代码，然后在命令行上编译和刷新。

Arduino Due 使用 arm-gcc-eabi 和 bossac 进行编译和烧录（您可以从 Arduino 存储库中获取可执行文件）

否则，即使您确实使用了另一个 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这可能只是您需要的 HAL，不再担心“哪个 ARM？” 

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

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

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

@csdexter你知道更多吗？

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

但值得关注它。

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

跳出框框思考总是一个好主意：这是我们正在谈论的嵌入式系统，而 grbl 是一个裸机应用程序，因此 .DLL/.so -like 语义不适用。在你让它编译并使用冻结的快照运行之后，你可以悬赏让某人成为 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 无关的代码。这对我来说是不可能的。

可以有编译器开关、依赖于 cpu 的配置文件，甚至是自动生成的代码。但它需要有一个独立于cpu的API。如果我们找到一个可以做到这一点的库，那么让我们继续吧。如果 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 编译器的任何体系结构： -)