STM32Cubemx I2C代码写作以保留的寄存器位
我正在STM32F74家庭处理器上开发I2C驱动器。我正在使用STM32Cubemx低级驱动程序,我无法理解I2C启动和停止寄存器值(CR2)的定义。
该代码是在STM32F7XX_LL_I2C.H中生成的,如下所示。
/** @defgroup I2C_LL_EC_GENERATE Start And Stop Generation
* @{
*/
#define LL_I2C_GENERATE_NOSTARTSTOP 0x00000000U
/*!< Don't Generate Stop and Start condition. */
#define LL_I2C_GENERATE_STOP (uint32_t)(0x80000000U | I2C_CR2_STOP)
/*!< Generate Stop condition (Size should be set to 0). */
#define LL_I2C_GENERATE_START_READ (uint32_t)(0x80000000U | I2C_CR2_START | I2C_CR2_RD_WRN)
/*!< Generate Start for read request. */
我的问题是为什么这些定义中包含BIT 31? (0x 8 0000000U)。参考手册(RM0385)指出“位31:27保留,必须保持重置值。”。我无法决定修改生成的代码或保留31位。我会很高兴地提出建议,这是否更有可能是需要的,或者我将通过写信给保留的位来打破事情。 登记位地图(I2C_CR2)>
提前感谢!
I'm developing an I2C driver on the STM32F74 family processors. I'm using the STM32CubeMX Low Level drivers and I can't make sense of the generated defines for I2C start and stop register values (CR2).
The code is generated in stm32f7xx_ll_i2c.h and is as follows.
/** @defgroup I2C_LL_EC_GENERATE Start And Stop Generation
* @{
*/
#define LL_I2C_GENERATE_NOSTARTSTOP 0x00000000U
/*!< Don't Generate Stop and Start condition. */
#define LL_I2C_GENERATE_STOP (uint32_t)(0x80000000U | I2C_CR2_STOP)
/*!< Generate Stop condition (Size should be set to 0). */
#define LL_I2C_GENERATE_START_READ (uint32_t)(0x80000000U | I2C_CR2_START | I2C_CR2_RD_WRN)
/*!< Generate Start for read request. */
My question is why is bit 31 included in these defines? (0x80000000U). The reference manual (RM0385) states "Bits 31:27 Reserved, must be kept at reset value.". I can't decide between modifying the generated code or keeping the 31 bit. I'll happily take recommendations simply whether its more likely that this is something needed or that I'm going to break things by writing to a reserved bit.
Thanks in advance!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我在这里猜是因为谁知道图书馆作者的想法? (如果您查看源代码!)。但是我猜想检查您正在使用指定宏时,检查LL功能时是一个“肮脏的”。
但是,它存在严重缺陷,因为“技巧”仅适用于Cortex-M3/4 STM32变体(例如F1XX,F2XX,F4XX),其中I2C外围物是 em em em>非常不同的,并且只注册I2C_CR2,例如I2C_CR2 15位宽。
诀窍是库函数具有参数检查断言,例如:
is_transfer_request
的定义是这样定义的:这迫使您使用ll定义的宏作为参数,而不是某些自定义或计算的蒙版,因为它们是因为它们所有人都在其中有“未使用”检查位。
如果这确实是原因,那是一种不明智的做法,没有设想新的I2C外围。您可能会认为,在写入寄存器之前,该位已从参数中剥离。我已经检查了,不是。如果您将在每个电话上为该开销付费,这也是不可取的。
作为一种错误检测技术,如果是这样,它甚至不始终如一地应用;例如,所有的gpio_pin_xx宏都宽16位,并且由于它们是掩模而不是销钉数字,因此使用bit 31可以例如防守避免传递字面的销钉数10,其中mask
1&lt;&lt;&lt; 10
is实际上需要。传递10将指示3和1而不是10。说实话,错误的可能性要比通过错误的I2C传输请求类型更有可能。但是,最终“保留”通常是指“未使用”,但可以在将来的实施中使用” ,并且要求您使用“重置值”是确保 forther二进制兼容性的一种方式。如果您拥有这样的设备,毫无疑问,将会有相应的库更新来支持它 - 但是它需要重新编译代码。风险很低,如果您尝试在使用此位的较新的不兼容部分上运行此二进制,则可能只是一个问题。
I am guessing here because who knows what was on the minds of the library authors? (Not a lot if you look at the source code!). But I would guess that it is a "dirty-trick" to check that when calling LL functions you are using the specified macros.
However it is severely flawed because the "trick" is only valid for Cortex-M3/4 STM32 variants (e.g. F1xx, F2xx, F4xx) where the I2C peripheral is very different and registers such as I2C_CR2 are only 15 bits wide.
The trick is that the library functions have parameter checking asserts such as:
Where the
IS_TRANSFER_REQUEST
is defined thus:This forces you to use the LL defined macros as parameters and not some self-defined or calculated mask because they all have that "unused" check bit in them.
If that truly is the the reason, it is an ill-advised practice that did not envisage the newer I2C peripheral. You might think that the bit was stripped from the parameter before being written to the register. I have checked, it is not. And if did you would be paying for that overhead on every call, which is also undesirable.
As an error detection technique if that is what it is, it is not even applied consistently; for example all the GPIO_PIN_xx macros are 16 bits wide and since they are masks not pin numbers, using bit 31 could for example guard against passing a literal pin-number 10 where the mask
1<<10
is in fact required. Passing 10 would refer to pins 3 and 1 not 10. And to be honest that mistake is far more likely than, passing an incorrect I2C transfer request type.In the end however "Reserved" generally means "unused but may be used in future implementations", and requiring you to use the "reset value" is a way of ensuring forward binary compatibility. If you had such a device no doubt there would be a corresponding library update to support it - but it would require re-compilation of the code. The risk is low and probably only a problem if you attempt to run this binary on a newer incompatible part that used this bits.
我同意Clifford的观点,ST Cubemc / hal / ll库代码在某些地方是一些最糟糕的书面代码。我有一个特殊问题,上面有“ timx-&gt; ccer&amp; = 〜tim_ccer_cc1e”,其中tim_ccer_cc1e定义为0x0001,并且CCER寄存器包含保留的位,这些位应保留在0。代码。请问我的建议请求保持沉默。
I agree with Clifford, the ST CubeMC / HAL / LL library code is, in places, some of the worst written code imaginable. I have a particular issue with lines such as "TIMx->CCER &= ~TIM_CCER_CC1E" where TIM_CCER_CC1e is defined as 0x0001 and the CCER register contains reserved bits that should remain at 0. There are hundreds of such examples all throughout the library code. ST remain silent to my request for advice.