Arm 何时实现对设备的皮质写入

当写入Cortex M0上的设备寄存器（在我的例子中，在STM32L073上）时，会出现一个问题，即在a）对设备内存的访问排序和b）确定对外围设备配置的更改实际上已经完成到任何依赖项都变为有效的程度时，应该多小心

举一个具体的例子，将内部电压调节器更改为不同的电压。您将更改写入PWR->CR，并从PWR->CSR读取状态。我看到这样的代码：

Write to PWR->CR to set the voltage range
Spin until (PWR->CSR & voltage flag) becomes zero

在我看来，这里有三个问题：

访问顺序。这是设备内存，因此相对于其他设备访问事务，事务顺序被保留。我假设这意味着写入CR和从CSR读取之间不需要DSB。一个相关的问题和答案是：

设备内存可以缓冲。当从CSR读取时，是否有可能仍在进行对CR的写入。这意味着电压标志将清晰，代码将继续。事实上，国旗还没有升得很高

硬件响应时间。在写入和最终效果之间是否存在延迟？实际上，应该始终记录这一点-对于STM32，文档明确表示，当CR寄存器更改时，将设置该标志

这里有任何比赛条件的可能性吗？我真正担心的是缓冲——当外围设备读取发生时，外围设备写入仍在进行中

访问顺序

访问是强顺序的，您不需要屏障指令来读回同一寄存器

设备内存可以缓冲。是否存在向CR写入的可能性

是的，这是可能的。但这不是因为缓冲，而是因为总线传播时间。在特定操作通过所有桥接器之前，可能需要几个时钟

硬件响应时间。写入和写入之间是否存在延迟 最终效果

---

即使存在延迟，从您的角度来看，这并不重要。如果在CR寄存器中设置位，并在状态寄存器中等待结果。只需等待状态位具有预期值。

我假设这些都是理论上的担忧，或者您是否有一个具体的例子说明某些东西不能“按预期”工作？如果1/2/3是一个问题，我希望它有大量的文档记录，否则在几乎所有的例子中，与大多数外围设备的交互都会有问题（虽然STM32的制造商示例远不是最好的，但描述的问题会使它们变得毫无价值）。在某些情况下，st文档或其代码表明您需要读取或轮询，以确认（通常需要代码执行之外的时间）模拟项，如干扰时钟。对于供应商来说，无论出于何种原因、性能等，都有可能出现设计问题，从而导致竞态条件无法通过读取但是，正如前面提到的，如果供应商没有记录这些东西，无论是主文档还是勘误表，那么当用户落入这个陷阱时，他们可能会感到痛苦。还没有听说过问题。从cortex ms的角度来看，一旦另一方确认了地址和数据，这就不再是问题了cortex-m问题，可以继续。写入可能会被触发和遗忘，从axi/ahb总线的角度来看，可以在到达目标之前很久在该总线上完成，其中读取需要到达目标并返回。这不是什么新问题，只是你的标题问题，cortex在确认地址和数据时意识到了这一点。从目标透视图TIV取决于该芯片实现中的目标和到目标的路径。它主要基于PIC16的经验，例如，写入串行传输缓冲区不会立即清除TXIF标志。但这是一个记录在案的硬件延迟问题。正如您所说，如果这些事情没有按描述的那样工作，将导致n用户陷入陷阱！这可能是一个理论上的担忧！这个答案和@old_timer在评论中所说的一样有道理。我不认为我真的很欣赏ARM设备真的像是在总线上有一个CPU和外部外设。这听起来很陈腐，但我以前使用PIC和Atmel的经验让我感到很困惑这是因为它们更紧密地集成在内核中。换句话说，PIC可以说“对串行端口的写入将在此周期内完成，并在此周期内返回”，而ARM则会说“对外围设备的写入将在其确认时完成”。这略有不同：-）@carveone实际上没有区别。Core不仅是一个控制器，而且必须在总线上（例如DMA）。只有功能有限的非常简单的架构才能设计成小型PIC或AVR uCs。是的，这是完全正确的！我采取了强迫性的方法，在那里我阅读了文档，然后想“我在这里错过了什么陷阱”。正是“写入设备内存可以缓冲”这句话引发了这一切。谢谢：-）不用担心。它不是勘误表页面比实际编程手册长的微芯片：）。你根本不用担心。我使用STM手臂很多年了，我非常高兴。