STM32的I2C设计的很不合理！

大家先反映反映自己的看法。 

从与 ATMEL ARM7 I2C、 NXP ARM7 I2C 比较的结果看。

这样的讨论好，请各位大侠拍砖

                                  

想听听，LZ先说说如何个不合理法

                                  

反正我没用硬件的

我用IO模拟的，调试起来方便！以前在别的arm7核上的片子也色这么做的
感觉硬件的不好用~

STM32不是神话、传说。

                                 主要有两个方面，两点看法。

我估计

STM32的I2C不合理，可能会影响到它【I2C】的使用以及它的可靠性、稳定性。

好多朋友调试出问题和改用软件方式就是个 提示。

回复主题：STM32的 I2C 设计的很不合理 ！

有同感，I2C调试时容易死在下面函数里出不来
ErrorStatus I2C_CheckEvent(I2C_TypeDef* I2Cx, u32 I2C_EVENT)
{
  u32 lastevent = 0;
  u32 flag1 = 0, flag2 = 0;
  ErrorStatus status = ERROR;

  /* Check the parameters */
  assert_param(IS_I2C_ALL_PERIPH(I2Cx));
  assert_param(IS_I2C_EVENT(I2C_EVENT));

  /* Read the I2Cx status register */
  flag1 = I2Cx->SR1;
  flag2 = I2Cx->SR2;
  flag2 = flag2 << 16;

  /* Get the last event value from I2C status register */
  lastevent = (flag1 | flag2) & FLAG_Mask;

  /* Check whether the last event is equal to I2C_EVENT */
  if (lastevent ==I2C_EVENT )
  {
    /* SUCCESS: last event is equal to I2C_EVENT */
    status = SUCCESS;
  }
  else
  {
    /* ERROR: last event is different from I2C_EVENT */
    status =ERROR;
  }

  /* Return status */
  return status;
}

回7楼：例程设计的不合理不表示硬件设计不合理

                                 楼主的意思是说STM32的I2C硬件模块设计的不合理，我也很想听听大家的看法。

个人看法～～

相关链接:https://bbs.eeworld.com.cn/upfiles/img/200710/2007107161256451.pdf

NETJOB大作：《 关于STM32 I2C不合理的看法 》

哈哈，楼主看样子是个老板，俺帮你把大作抄下来，以方便大家阅读评判，我这里暂时不作评价。

---

《 关于STM32 I2C不合理的看法 》
// netjob 2008-08-22
1. 关于 SCL时钟设置的处理。
在软件模拟年代，SCL是50％的PWM，就是说SCL低周期:SCL 高周期=1:1，
这是我们一贯的认识与做法。

而实在ATMEL与NXP的ARM中的I2C也是如此对待。只不过ATMEL叫TWI。

由于ATMEL公司本身也生产I2C的FLASH和SPI FLASH；我们有理由相信这种1：1是可行可靠的。

我们知道I2C是NXP（菲利普半导体）的专利 ，它应该是权威了，但我们仔细看NXP的ARM7, 它的I2C 时钟高、低周期是可变的。

我们可以设1:1，也可以设1:2等等。虽然NXP手册上是使用1:1的设计。简单的说：SCL时钟高低周期比例定了下来（1：1），那么周期越长I2C的速度就越慢。

例如：I2C的时钟是48MHZ，要I2C工作200KHZ，我们只要 把计算出的周期写入I2C寄存器就可以了。
方法： 48，000，000/(200,000*2)=120；

也就是说把时钟分频【120】，I2C 就可以工作200KHZ了。

而ST公司的STM32名堂就来了，它来了什么 保准模式，快速模式，周期比例有什么 1:2 、 16:9 。
还搞了个SCL时钟最大上升时间，它也分模式，STM32的I2C设置中就要输入这项内容。

而ST公司确实是把简单的问题复杂化了。

2。关于状态位的查询与清除
这个事实上是很简单，但说起来比较麻烦。

在I2C协议中，我们都要根据标志位来判断分析I2C总线上发生的事情。例如START发送完毕了，数据发送完毕了等等。

ATMEL公司
ATMEL的TWI可以说 非常精简。
程序只要关心的标志：
TXRDY: 发送保持寄存器就绪
RXRDY: 接收保持寄存器就绪
TXCOMP: 传输完成

NXP公司
NXP的I2C可以说 非常高效。它的每个状态标志位都有相应的清标志位，这样当I2C总线上发生的事情触发对应的标志置位后，我们可以人为的清除它。

而且它的标志位很统一，用一个【中断事件标志位】来表示，详细内容可以访问内容寄存器。

ATMEL公司和NXP公司的I2C都只有【一个】 状态寄存器。

而ST公司呢，STM32要操作【两个】状态寄存器，判断这两个寄存器的标志位。标志名目繁多，不同事件要查询不同标志位；也没有相应的清除标志位。

这也是我们最担心的，我们不知到底这个标志是新的事件产生的还是老的标志没被清除。

虽然STM32告诉了我们每个标志的清除方法。