Linux: I2C Broadcom 버그 해결 방법.

드라이버의 해결 방법이 대부분의 사용자에게 더 잘 작동하도록 만드는 경우 포함되어야합니다.
적절한 패치가 있습니까?

아니, 아직.

1) 아직 I2C 드라이버를 다루지 않았습니다. 약 1 년 전, 제가 직접 쓸 계획이 있었지만, 그 일을하기 전에 다른 누군가가 그것을 썼습니다. 따라서이 드라이버를 이미 알고있는 사람은이 작업을 5 분짜리 프로젝트로 수행 할 수있는 더 나은 장비가 될 수 있습니다. 운전자를 알아가는 데는 최소한 몇 시간이 걸립니다.
2) 귀하 (또는 다른 사람)가 수정 / 해결 방법이 보장된다는 데 동의하는 경우 먼저 논의하는 것이 좋습니다.
3) 저는 이것을 "해야 할 일"로 문서화하고 싶었습니다. 잊지 말아야합니다 ....
4) 누군가가 다른 해결 방법을 제안 할 수도 있습니다.

해결 방법에 대해 말하기 : 해결 방법은 새 트랜잭션을 시작하려고 할 때 SDA 라인이 여전히 낮은 경우에도 트리거 될 수 있습니다. 그것은 분명히 "문제"상황입니다.

"잘못됨"사례는 "정상적인"사례의 경우 드뭅니다. 많은 사람들이 I2C- 버스에 하드웨어 i2c 모듈을 가지고있을 것입니다. I2C가 발명되었을 때 "10us"는 일부 칩이 요청을 처리하는 "매우 짧은"시간이었을 수 있으므로 클럭 확장이 필요했습니다. 오늘날 모든 하드웨어 I2C 구현은 "빠른 I2C"를 훨씬 더 빠르게 처리 할 수 ​​있어야합니다.

이것은 atmel 사람들이 비동기 모듈을 구현하는 방식과 결합됩니다. 모듈이 외부에서 제공되는 클럭 (i2c- 슬레이브 또는 SPI- 슬레이브)에서 실행되는 대신 모듈은 여전히 ​​프로세서 클럭에서 실행됩니다. 그리고 들어오는 모든 신호를 여러 개의 filpflops를 통과하여 동기화합니다. 좋은 하드웨어 디자인. 대안은 IMHO가 더 좋습니다. 외부 클럭에서 모듈을 실행하고 데이터가 다른 (cpu-) 클럭 도메인으로 전달 될 때 동기화합니다. 예를 들어 CPU가 8에서 실행되는 경우에도 SPI 모듈이 20MHz에서 작동 할 수 있습니다.

어쨌든. 충분한 하드웨어 흔들림.

제안 된 해결 방법 : 트랜잭션 시작시 SDA 라인이 여전히 낮을 때 추가 클록주기를 발행합니다. ( "시작"조건을 발행 할 수 있으려면 높게 시작해야합니다).

첫째, I2C에 대해 거의 알지 못합니다. 나는 Gert와 다른 사람들에게 해결 방법에 대해 이야기했습니다.

I2C에는 다음과 같은 두 가지 문제가 있습니다.

1. 당신이 설명한 시계 스트레칭 문제
2. 다시 시작할 때 I2C 상태 시스템 문제

1의 경우 Gert의 견해는 확실한 해결 방법이 없다는 것입니다.
I2C 슬레이브가 클럭 스트레칭을 지원하지 않으면 괜찮습니다.
I2C 클럭이 제한된 양만큼 늘어 나면 I2C 클럭 주파수를 낮추면 문제를 피할 수 있습니다.
이전 사례에서 떨어지지 않는 슬레이브 용 비트 쾅 드라이버로 전환하는 것이 안전한 해결 방법입니다.

당신의 제안이 효과가 있을지 모르겠습니다. 나는 그것이 문제를 줄이거 나 완전히 고치는 지 듣고 싶습니다.

Gert는 그가 시도하고 공개 할 버그에 대한 설명이 있다고 말합니다.

2의 경우 GPU I2C 드라이버에 상태 시스템 문제를 해결하는 몇 가지 코드가 있습니다.

/***********************************************************
 * Name: i2c_actual_read
 *
 * Arguments:
 *       const I2C_PERIPH_SETUP_T *periph_setup,
         const uint32_t sub_address,
         const uint32_t data_to_read_in_bytes,
         void *data
 *
 * Description: Routine to actually transfer data to the I2C peripheral
 *
 * Returns: int == 0 is success, all other values are failures
 *
 ***********************************************************/
static int32_t i2c_actual_read(  const I2C_PERIPH_SETUP_T *periph_setup,
                                 const I2C_USER_T *user,
                                 const uint32_t sub_address,
                                 const uint32_t read_nbytes,
                                 void *data,
                                 const int using_interrupt)
{
   int32_t rc = -1; /* Fail by default */
   int32_t status = 0;
   int32_t nbytes;

   uint32_t sub;
   uint8_t* read_data = (uint8_t*)data;
   uint32_t data_read = 0;

   if( NULL != periph_setup && NULL != data ) {

      // confirm that the latch is held for this transaction
      assert( i2c_state.periph_latch[ periph_setup->port ] != rtos_latch_unlocked() );

      // -> START
      // -> Slave device address | WRITE
      // <- Ack
      // -> Sub address
      // <- Ack
      // -> Sub address
      // <- Ack
      // -> ReSTART
      // -> Slave device address | READ
      // <- Ack
      // <- Data[0]
      // -> Ack
      // <- Data[1]
      // -> nAck
      // -> STOP

      I2CC_x( periph_setup->port )     = I2CC_EN | I2CC_CLEAR; /* Enable I2C and clear FIFO */
      I2CS_x( periph_setup->port )     = I2CS_ERR | I2CS_DONE | I2CS_CLKT; /* clear ERROR and DONE bits */
      I2CA_x( periph_setup->port )     = periph_setup->device_address;

      sub = sub_address;
      nbytes = periph_setup->sub_address_size_in_bytes;

      if( 0 == nbytes ) {
         /* No subaddress to send - just issue the read */
      } else {
         /*
           See i2c.v: The I2C peripheral samples the values for rw_bit and xfer_count in the IDLE state if start is set.

           We want to generate a ReSTART not a STOP at the end of the TX phase. In order to do that we must
           ensure the state machine goes RACK1 -> RACK2 -> SRSTRT1 (not RACK1 -> RACK2 -> SSTOP1). 

           So, in the RACK2 state when (TX) xfer_count==0 we must therefore have already set, ready to be sampled:
           READ ; rw_bit     <= I2CC bit 0   -- must be "read"
           ST;    start      <= I2CC bit 7   -- must be "Go" in order to not issue STOP
           DLEN;  xfer_count <= I2CDLEN      -- must be equal to our read amount

           The plan to do this is:
           1. Start the sub-add]ress write, but don't let it finish (keep xfer_count > 0)
           2. Populate READ, DLEN and ST in preparation for ReSTART read sequence
           3. Let TX finish (write the rest of the data)
           4. Read back data as it arrives

         */
         assert( nbytes <= 16 );
         I2CDLEN_x( periph_setup->port )  = nbytes;
         I2CC_x( periph_setup->port )    |= I2CC_EN | I2CC_START; /* Begin, latch the WRITE and TX xfer_count values */

         /* Wait for us to leave the idle state */
         while( 0 == ( I2CS_x(periph_setup->port) & (I2CS_TA|I2CS_ERR) ) ) {
            _nop();
         }
      }

      /* Now we can set up the parameters for the read - they don't get considered until the TX xfer_count==0 */
      I2CDLEN_x( periph_setup->port )  = read_nbytes;
      I2CC_x( periph_setup->port )     |= I2CC_EN | I2CC_START | I2CC_READ;

      /* Let the TX complete by providing the sub-address */
      while( nbytes-- ) {
         I2CFIFO_x( periph_setup->port ) = sub & 0xFF; /* No need to check FIFO fullness as sub-address <= 16 bytes long */
         sub >>= 8;
      }

      /* We now care that the transmit portion has completed; the FIFO is shared and we mustn't read out
         any of the data we were planning on writing to the slave! */

      /* Wait for peripheral to get to IDLE or one of the two RX states - this way we *know* TX has completed or hit an error */
      {
         uint32_t state;
         bool_t state_transition_complete;
         bool_t error_detected;
         do { 
            state = (I2CS_x( periph_setup->port ) & 0xf0000000) >> 28;
            state_transition_complete = ((state == 0) || (state == 4) || (state == 5));
            error_detected = (I2CS_x(periph_setup->port) & (I2CS_ERR | I2CS_CLKT)) != 0;
         } while(!state_transition_complete && !error_detected);

         if (error_detected) {
            /* Clean up, and disable I2C */
            I2CC_x( periph_setup->port ) &= ~(I2CC_INTD | I2CC_INTR);
            I2CC_x( periph_setup->port ) &= ~(I2CC_START | I2CC_READ);
            I2CS_x( periph_setup->port ) = I2CS_CLKT | I2CS_ERR | I2CS_DONE;
            I2CC_x( periph_setup->port ) |= I2CC_CLEAR;
            I2CC_x( periph_setup->port ) = 0;
            return -1;
         }
      }

      if (using_interrupt)
      {
         /* Wait for interrupt to complete. */
         i2c_state.active_buffer[periph_setup->port] = data;
         i2c_state.active_buffer_length[periph_setup->port] = read_nbytes;
         i2c_state.active_buffer_offset[periph_setup->port] = 0;
         i2c_state.pending_transfer[periph_setup->port] = I2C_PENDING_TRANSFER_READ;
         RTOS_LATCH_T latch = rtos_latch_locked();
         i2c_state.pending_latch[periph_setup->port] = &latch;

         /* Enable interrupt. */
         I2CC_x( periph_setup->port ) |= I2CC_INTD | I2CC_INTR;

         rtos_latch_get (&latch);

         i2c_state.pending_latch[periph_setup->port] = NULL;
         data_read = i2c_state.active_buffer_offset[periph_setup->port];

         rc = (data_read == read_nbytes) ? 0 : -1;
      }
      else
      {
         uint32_t time_now = 0;

         /* Loop until we've read all our data or failed. */
         while( 0 == ( I2CS_x(periph_setup->port) & (I2CS_TA|I2CS_ERR|I2CS_DONE) ) ) {
            _nop();
         }

         /* Wait for some data to arrive - we should wait, at most, I2C_TIMEOUT_IN_USECS for data to arrive every time we start waiting */
         time_now = i2c_state.systimer_driver->get_time_in_usecs( i2c_state.systimer_handle );
         while( ((i2c_state.systimer_driver->get_time_in_usecs( i2c_state.systimer_handle ) - time_now) < I2C_TIMEOUT_IN_USECS)
                && ( data_read < read_nbytes )
                && !(I2CS_x( periph_setup->port ) & I2CS_ERR) ) 
         {
            if (I2CS_x( periph_setup->port ) & I2CS_RXD) 
            {
               read_data[ data_read ] = I2CFIFO_x( periph_setup->port );
               data_read++;
               time_now = i2c_state.systimer_driver->get_time_in_usecs( i2c_state.systimer_handle  );
            }
         }

         if( (data_read != read_nbytes) /* Did we read all the data we asked for? */
             || ( (read_nbytes - data_read) != I2CDLEN_x( periph_setup->port ) ) /* Has DLEN decremented? */
             || ( 0 != (I2CS_x( periph_setup->port ) & I2CS_ERR) ) ) { /* Are there any errors? */
            rc = -1;
         } else {
            while( I2CS_DONE != (I2CS_x(periph_setup->port) & I2CS_DONE) ); /* Wait for the peripheral */
            rc = 0;
         }
      }

      /* Clean up, and disable I2C */
      I2CC_x( periph_setup->port ) &= ~(I2CC_INTD | I2CC_INTR);
      if(I2CS_x( periph_setup->port ) & I2CS_ERR) {
         //Wait for it to be idle
         while(I2CS_x( periph_setup->port ) & I2CS_TA)
            _nop();
      }
      I2CS_x( periph_setup->port ) = I2CS_ERR | I2CS_DONE;
      //Finally disable the I2C
      I2CC_x( periph_setup->port ) = 0x0;
   }

   if( !user->skip_asserts ) {
      assert( rc >= 0 );
      _nop();
   }

   return rc;
}      

사람들이이 문제를 다루고 있는지 확실하지 않지만 붙여 넣은 것이 도움이 될 수 있습니다.

이 하드웨어 버그를 완전히 근절하는 것은 불가능합니다.

이런 일이 발생하면 마스터와 슬레이브는 클록 사이클 수에 동의하지 않습니다. 따라서 슬레이브에 의해 해석되는 데이터와 의도 한 마스터 (= 라즈베리 파이 = 드라이버 / 애플리케이션)로 데이터가 다릅니다. 레지스터 어딘가에 완전히 가짜 값을 쓰고있을 수 있습니다. 매우 짜증납니다.

내가 제안한 해결 방법은 최소한 다음 트랜잭션이 작동하도록합니다. 그 영향은 절반으로 줄어들 것입니다. 두 개가 아닌 하나의 트랜잭션 만 실패했습니다. 문제가 해결되지는 않습니다.

I2C 슬레이브가 클럭 스트레칭을 지원하지 않으면 괜찮습니다.

I2C 슬레이브가 클럭 스트레칭을 필요로하지 않는다면 ....

I2C 클럭이 제한된 양만큼 늘어 나면 I2C 클럭 주파수를 낮추면 문제를 피할 수 있습니다.

예. 한 위치에 "현장에"10 개의 장치가 있습니다. 분명히 세 모듈의 클럭 주파수 (RC 클럭)는 정확히 잘못된 순간에 클럭이 늘어나 "완료"되는 방식으로 다릅니다. 클럭 주파수를 줄이면 해당 모듈의 문제가 해결되었습니다.

클럭 스트레칭 지연이 고정되지 않았지만 예를 들어 5 마이크로 초 이상 차이가 나면 문제가 발생할 수있는 통계적 가능성이 더 많거나 적습니다. 제 경우에는 슬레이브에 0.25 마이크로 초의 클록 폭이 필요합니다. 따라서 클록 스트레칭은 BCM의 클록 변경 순간까지 이어지는 5 %의 시간에 끝나고 문제가 발생합니다. 따라서이 경우 20 건의 전송 중 약 1 건이 잘못 될 것입니다. (사양은 클럭 펄스에 대해 최소 250ns라고 말합니다. 실제로 이것이 더 짧으면 보이지 않는다는 것을 의미하지는 않습니다. 볼 가능성이> 250ns에서 100 %에서 < 125ns.)

저는 어제 5 마이크로 초의 기회 창에서 2.5 마이크로 초 정도의 시간이 될 수 있도록 클럭 스트레칭 기간을 늘 렸습니다. 창 시작을 목표로하고 RC 시계가 약간 빠르게 실행되면 "0"을 눌러 버그를 유발합니다. 5를 목표로하면 똑같습니다. 그래서 지금은 나쁜 곳에서 멀어지면서 중간을 노리고 있습니다. 하지만 I2C 클럭을 80kHz로 변경하고 BAM은 민감한 지점을 목표로하고 있습니다 ... (80kHz에서 발생하지 않으면 80에서 100 사이의 값으로 발생합니다).

다음은 I2C 버그에 대한 Gert의 설명입니다.
https://dl.dropbox.com/u/3669512/2835_I2C%20interface.pdf

ㅋ! 테스트 보드를 똑같은 방식으로 계측했습니다. SCL 트레이스를 잘라내어 거기에 0.1 "점퍼 커넥터를 장착했습니다. 측정하지 않는 동안 거기에는 일반 점퍼가 있거나 내가있을 때 100 옴 저항이있는 암 커넥터가 있습니다.

나는 그것이 첫 번째 시계에만 발생한다고 생각하지 않습니다. 즉, 클럭 확장을 전혀하지 않거나 (대부분의 하드웨어 I2C 칩이 아마도 그렇듯이) 클럭 확장이 적어도 전체주기 동안 지속되도록함으로써 문제를 해결할 수 있습니다.

클럭 스트레치를 0.5 마이크로 초 단위로 변경할 수 있도록 i2c 슬레이브 코드를 계측했습니다. I2C를 통해 클럭 스트레치를 XXX로 변경하도록 명령 할 수 있으며 기본값으로 다시 변경하기 전에 50 밀리 초 동안 작동합니다. (작동하지 않는 경우 다시 작동해야합니다. 이렇게하면 로직 분석기로 SDA 및 SCL 라인을 모니터링하면서 이러한 설정에 대한 전체 값 범위를 빠르게 스캔 할 수 있습니다. "use delay XXX"를 보낸 다음 sting을 보내는 데는 25 밀리 초가 걸립니다. 스크립트에서 카운터를 증가시키고 "next delay"를 보내는 데는 쉘 스크립트가 약 100ms 걸립니다. 그래서 약 10 초 안에 100 개의 가능한 값을 스캔 할 수 있습니다.

나는 더 긴 지연에서 발생하는 버그를 보았다. 따라서 "처음에만 발생한다"라는 이론은 옳지 않습니다.

"초 효율적인"인터럽트 핸들러에 관해서 : 예, 저도 할 수 있습니다. 문제는 다음과 같습니다. 클럭 확장 기능을 사용하면 인터럽트 루틴에 "이 바이트 처리"코드를 넣을 수 있으며 몇 마이크로 초 또는 몇 밀리 초가 걸리는 것에 대해 걱정할 필요가 없습니다. 이론적으로 클럭 스트레칭은 마스터가 다음 바이트를 계속하기 전에이 바이트 처리를 완료 할 때까지 기다리도록합니다. 이 계획은 2835의 버그로 인해 완전히 망가졌습니다. 저는 이제 클럭 스트레칭을 멈추게 한 다음 70 마이크로 초 안에 바이트 처리를 완료하기를 희망합니다.

나는 클럭 스트레칭을 해제하기 위해 5 마이크로 초 반 시계의 중간을 목표로 "사이클 카운트"를해야합니다. 시작을 목표로한다면 (4.9 마이크로 초 클록 높은주기를 유발하기 위해) 내 슬레이브의 클록이 몇 퍼센트 더 빠르게 실행되고 버그가 반주기를 더 일찍 트리거 할 수 있습니다. 그래서 반 시계주기의 양쪽 끝은 위험합니다. 짧지 만 유효한 시계주기를 목표로해야합니다.

모듈의 변경은 간단합니다. SCL이 "하이 구동"(즉, 전혀 구동되지 않음)되면 I2C 모듈 마스터 클럭을 중지합니다. 이는 버스 커패시턴스가 사양을 초과 할 때 자동 클록 스트레칭이 발생하기 때문에 훨씬 더 긴 I2C 버스를 허용하는 부작용이 있습니다.

이 : http://comments.gmane.org/gmane.linux.kernel.rpi/268 및이 : http://news.gmane.org/gmane.linux.kernel.rpi 가 도움이 될 수 있습니까?

도와 주셔서 감사합니다, iz8mbw,하지만이 (하드웨어) 버그와는 아무 관련이 없습니다.

I2C 클럭을 측정했는데 드라이버가 생각하는 100kHz로 나옵니다. 드라이버는 주파수를 쿼리하고이를 사용하는 "클럭 소스"개체를 가지고 있습니다. 주파수를 인쇄하도록 드라이버를 아직 구성하지 않았습니다.

실제 버그를보고자하는 사람들을위한 정보를 위해 논리 분석가 덤프 형태의 "증거"가 있습니다.
이미지를 첨부 할 수 있지만 바이너리 LA 덤프는 첨부 할 수 없습니다. 그게 여기 있습니다 : http://prive.bitwizard.nl/LA_with_bug_scan_50_to_100_microseconds_delay.bin.gz

LA_with_bug_shot1.png 이미지에서 짧은 활동 버스트를 볼 수 있습니다. "지연을 XXX로 설정"한 다음 10 바이트를 쓰려고하지만 NACK로 인해 중단되는 작은 버스트입니다. 오른쪽에는 적절한 10 바이트 패킷이 표시됩니다. SDA 라인은 다음 번 버스트가 잘못 정렬 될 때까지 낮게 유지됩니다 (모든 비트가 이동되고 내 슬레이브에서 "xth-byte-in-packet"카운터는 해당 패킷의 시작시 존재하지 않는 시작 조건에 의해 재설정되지 않음). .

LA_with_bug_shot2.png 이미지에서 짧은 펄스가 발생하는 부분을 확대했습니다. 내가 본 가장 긴 펄스는 290ns입니다. (Atmel에 대한 데이터 시트 사양 위!)

오, 그게 어디에서 왔는지!

나는 라즈베리 파이에서 I2C로 제어하려는 프로젝트를 가지고 있으며 솔직히 포기하고 비글 보드로 전환하거나 Pi가 SPI를 통해 FPGA와 대화하는 것과 I2C 작업을 수행하는 것에 가깝습니다. .

나는 그것을 할 수 있어야 할 우편물에 게시판이 있습니다 (예상 배송 : 내일). SPI 커넥터, I2C 커넥터. 그 보드로 시도하는 좋은 프로젝트가 될 것입니다. 정보를 계속 받으려면 이메일을 보내주세요.

현재 상황 : 저는 Gert와 호환되는 행동을보고 있습니다. 슬레이브가 ATMEGA 일 때 "첫 번째 주기만 잘못 될 수 있습니다", 그리고 슬레이브가 제 ATTINY 중 하나 일 때 버그가 온전히 보이는 것입니다.

테스트 한 지연은 다음과 같습니다.

이 테스트 세션 동안 관찰 된 가장 짧은 SCL 펄스는 4.5 마이크로 초였습니다.

이제 attiny 슬레이브로 테스트 한 ACK에 대해 테스트 된 지연은 다음과 같습니다.

최소 펄스 폭은 41ns (내 측정 해상도)입니다.

아. 그것을 발견! 바이트의 ACK 이전에 클럭이 늘어나는 것은 "위험"한 것 같지만 ACK 이후 클럭이 늘어나는 것은 괜찮습니다 .....

저와 다른 사람들은 확실히 반복되는 시작 문제를 겪고 있습니다. proc hipi_i2c_read_register_rs의 http://cpansearch.perl.org/src/MDOOTSON/HiPi-0.26/BCM2835.xs 에 사용자 공간 해킹이 있습니다. 이것은 TX 단계가 완료되었는지 확인하는 방법을 올바르게 파악하지 못했지만 시도해 보거나 C 코드를 통합했다고보고 한 사용자에게는 작동하는 것 같습니다 (5 명에 불과 함). 커널 모듈을 컴파일하고 위의 코드에 대해 기존 테스트를 실행하는 방법을 배워야한다고 생각합니다.

커널이 I2C 하드웨어를 무시하고 동일한 핀에서 비트 뱅드 GPIO 기반 I2C를 사용하도록 강제 할 수는 없습니까? 나는 그것에 대한 오버 헤드가 하드웨어 자체의 버그보다 더 수용 가능할 것이라고 생각합니다.

어떤 오버 헤드를 예상하십니까? 현재 드라이버의 기본값은 100kHz 클럭입니다. 따라서 i2c intertial 센서에서 10 바이트를 읽는 데 약 1ms가 걸립니다. 비트 뱅을한다면 그 시간에 CPU 사이클을 뒤흔들 수 있습니다 ....

필자가 선호하는 것은 드라이버가 모듈 매개 변수 (또는 더 편리한 경우 별도의 모듈)를 통해 i2c 비트 뱅킹을 선택적으로 지원하는 것입니다.

많은 장치가 클럭 확장 (또는 제한된 양만큼 클럭 확장을 사용하여 감소 된 속도로 올바르게 작동 할 수 있음)을 사용하지 않으므로 이러한 경우 하드웨어 I2C 드라이버가 여전히 선호됩니다.

커널 자체에는 GPIO 핀에 비트 뱅 된 I2C 용 드라이버가 있으며,이 드라이버는 사용자 공간의 비트 뱅깅보다 오버 헤드가 훨씬 적으며 하드웨어 I2C 드라이버와 동일한 API를 노출합니다. 내 제안은 해당 드라이버와 하드웨어 I2C 드라이버를 모두 모듈로 컴파일 한 다음 기본적으로 하드웨어 드라이버를로드하는 것입니다.

헉
Pi에서 bitbanged I2C 드라이버를 사용합니까?
빌드하기 위해 추가 한 .config 옵션은 무엇입니까? 소스 패치가 있습니까?
사용할 드라이버를 선택하려면 어떻게해야합니까 (modprobe? 다른 / dev / 장치?)

Pi에서 드라이버를 사용하지 않았지만 BeagleBoard에서 성공적으로 사용하는 친구가 있습니다.
구성 옵션은 I2C_GPIO입니다.
이 드라이버와 broadcom 드라이버가 모두 모듈로 구성된 경우 드라이버를 선택하는 것은 커널 모듈을로드하는 것만 큼 간단합니다.
GPIO 모듈은 SDA 및 SCL로 사용할 GPIO를 알려주는 매개 변수가 필요합니다. 매개 변수가 무엇인지 모르겠지만 dirvers / i2c / busses / i2c-gpio.c의 잘 문서화되지 않은 소스를 기반으로합니다. 적절한 매개 변수는 'sda = X scl = Y'인 것 같습니다. 여기서 X와 Y는 사용하려는 핀입니다.

i2c-gpio 모듈 자체는 매개 변수를 전달하는 방법을 제공하지 않습니다. 따라서 플랫폼 데이터를 등록하고 최소한 버스 번호, SDA 및 SCL 핀을 구성하는 다른 모듈이 필요합니다. 나는 그러한 모듈의 개념 증명을 작성했으며 핀 0과 1에서도 작동했지만 i2c-bcm2708이로드되지 않은 상태에서 작동했습니다 (pcf8574가 i2cdetect에서 감지되었으며 gpio-pcf857x 모듈로 일부 LED를 구동 할 수있었습니다). 하지만 핀을 바꿀 때 pcf8574를 태워서 (지금은 다른 i2c 칩이 없습니다) 실제로 테스트 할 수 없었습니다. 다음 은 코드입니다.

뿡뿡
sda_pin / scl_pin 모듈 매개 변수를 만드는 것이 유용 할 수 있습니다. 풀 리퀘스트처럼.
누구든지 이것이 작동하는지 확인할 수 있습니까?

보기보다 덜 간단합니다. 플랫폼 데이터 구조가 끝까지 전달 될 것으로 예상합니다.

반면에 플랫폼은 현재 사용할 GPIO를 지정하지 않으므로 변경 작업을 수행하는 것이 합리적으로 들립니다. (일반적으로 플랫폼 데이터는 "How is / this / computer wired"를 지정합니다.)

뿡 빵뀨
구성 가능하게 만들 계획입니다. 어제 시간이 충분하지 않았습니다. 또한 한 번에 두 개 이상의 버스를 만들 수 있기를 바랍니다. GPIOS export 및 unexport sysfs 파일과 같은 동적 방식 일 수 있습니다 (하지만 그러한 버스를 완전히 내 보내지 않는 것이 가능한지 확실하지 않습니다)? 아, 또 다른 pcf8574를 찾았고 외부 풀업 저항을 사용할 때 다른 GPIO 핀에서도 잘 작동하는지 확인할 수있었습니다. 안타깝게도 테스트 할 더 정교한 I²C 장치가 없습니다. 그렇다면 이러한 모듈을 기본 커널 트리에 제공하는 데 관심이 있습니까?

뿡뿡
이와 같은 모듈을 테스트 할 설정이 없습니다. 그러나 칩이 제공하는 하드웨어 기능 (예 : I2C)에는 더 많은 사람들이 사용할 수 있도록 커널 드라이버가 있어야합니다. I2C 하드웨어에 사람들이 특정 주변 장치를 사용하지 못하게하는 버그가있는 경우 비트 뱅킹 대체 사운드가 가치가 있습니다.

따라서 사용하지 않는 사람들에게 무해 해 보이는 새 드라이버 (예 : 모듈로 빌드되고로드 될 때까지 아무것도하지 않음)를 생성하고 몇 가지 증거 (예 : 사용자 보고서를 확인하는 일부)가 있으면 올바르게 작동하는 것입니다. PR을 받아 들여 기쁩니다.

BCM2837 (RPi 3)에서 HW가 수정 되었습니까?

내 추측은 아니오입니다. 하지만 오늘 테스트 할 시간이 없을 것입니다.

BCM2837 I2C는 변경되지 않았습니다.

안타깝지만 정보에 감사드립니다.

그것은 매우 성가신 일입니다.

나는 동의한다. BCM2837 정오표에 대한 링크가 있거나 문제가 여전히 존재한다고 말하는 사람이 있습니까? 우리가 뉴스를 전달해야 할 때 편리 할 것입니다. 또는 @ P33M , Broadcom에서 일한다면 권위있는 사람으로 인용 될 수 있습니까?

그는 권위적이지만 Broadcom에서 일하지는 않습니다.

잘 됐네요. 그러나 나는 이미 구글을 검색했고, P33M이 다른 곳에서 M33P 인 것 외에는 유용하게 전달할 수있는 ID를 찾기 위해 고군분투하고 있습니다. 괜찮지 만 그가 인용 할만한 훌륭한 출처가 아님을 의미합니다. :-) 따라서 정오표 링크가 편리합니다.

@ P33M 은 Raspberry Pi에서 작동합니다. 그가 말하는 것을 권위있는 것으로 취급 할 수 있습니다.

정오표 목록이 없다고 생각합니다. 나는 그를 떠났다
그의 신원을 확인하든 말든!

2016 년 3 월 15 일 14:30에 RalphCorderoy [email protected] 은 다음과 같이 썼습니다.

잘 됐네요. 하지만 저는 이미 Google 검색을했고 P33M이 M33P 인 것 외에는
다른 곳에서는 유용하게 전달할 수있는 ID를 찾는 데 어려움을 겪습니다. 괜찮아요
그러나 그가 인용하기에 좋은 출처가 아니라는 것을 의미합니다. :-) 따라서 정오표 링크는
능숙한.

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/raspberrypi/linux/issues/254#issuecomment -196845789

@RalphCorderoy 저는 Raspberry Pi (trading) Ltd.의 직원입니다. 제 대답은 권위가 있습니다.

@ P33M , Ta, 그렇게 할 것입니다. 번거로워서 죄송합니다.

이것은 내가 작업중인 프로젝트에 영향을 미치고 있습니다. 다행히도 슬레이브 장치 펌웨어를 완벽하게 제어 할 수 있으며 잘못된 동작을 건너 뛰는 응답에 추가 반주기 지연 (클럭 스트레치)을 추가하는 해결 방법을 추가 할 수있었습니다.

문제에 대한 좋은 분석은 advamation.com 에서 찾을 수 있습니다.

Broadcom의 I2C 구현에이 불량 하드웨어가 있습니까? 아니면 하드웨어가 올바르게 작동하도록 커널을 조정할 수 있습니까?

개발중인 제품에서도이 문제가 발생 했으므로이 문제를 방금 구독했습니다.
AVR과 Pi 사이에 i2c를 사용합니다. 이제 다시 생각해야합니다.
누구든지 신뢰할 수있는 형태의 i2c 비트 뱅킹을 사용 했습니까?

@ mwilliams03 , 이 프로젝트에 관심 이 프로젝트 는 Raspberry Pi와 AVR 사이에 100kHz 및 400kHz I2C 통신을 성공적으로 구축했습니다. 나는 비트 뱅잉이 아니라 하드웨어 I2C 지원을 사용하고 핵심 포인트에 지연을 삽입합니다. AVR은 400kHz에서 추가 지연이 필요하지 않을 정도로 충분히 느립니다.

특히 다음은 I2C 문제에 대한 정보 입니다. AVR의 TWI 모듈에는 빠른 읽기를 방해하는 문제가 있습니다.

감사합니다 @ pdg137 , 나는 그것을 시도했고 처음에는 오류없이 120 만

@rewolff 는이 문제가 해결 된 것 같습니다. 이 경우이 문제를 종료하십시오.

이제 .... 레벨 시프터와 40cm의 연장 케이블을 추가합니다. 그러면 작동합니까? 이로 인해 파형의 "위쪽"에서 충분한 지연이 발생하고 갑자기 버그가 다시 발생합니다.

내가 말할 수있는 한, broadcom과 직원들은 여전히이 버그가 마지막 바이트 이후 5 마이크로 초 (실제로는 반 시계)로 제한된다고 생각합니다. 10 마이크로 초를 추가하는 것만으로도 2 개의 반 시계로 넘어 가고 문제가 없을 것입니다. 테스트에서 5 마이크로 초마다 클럭이 늘어나는 것을 멈출 수있는 "나쁜"순간을 발견했습니다.

SPI와 I2C 사이의 대칭으로 인해 다음 데이터 바이트가 "다음 데이터"인터럽트에서 "계산"되는 경우 AVR 코드에서 더 쉽습니다 .... (계속 읽기가 허용되는 인터페이스를 노출하므로 16 바이트 버퍼 항상 충분하지는 않습니다.).

나는 확신하지 못한다.

Respberry Pi와 ATMEGA 324PA 사이에 SMBus에 문제가 있습니다.이 문제와 관련이있을 수 있습니까? https://stackoverflow.com/questions/39274784/talking-smbus-between-raspberr-pi-and-atmega-324pa-avr-not-clock-stretching

내가 말할 수있는 한, broadcom과 직원들은 여전히이 버그가 마지막 바이트 이후 5 마이크로 초 (실제로는 반 시계)로 제한된다고 생각합니다.

@rewolff : Broadcom 직원들과 동의해야합니다. 내 테스트에서 Raspberry Pi 3 및 100kHz I2C (CPU가 스로틀 될 때 62kHz로 느려짐) 를 사용하면 애니메이션 과 유사한 결과

애니메이션이 소리가납니다. 그러나 그것은 내 경험과 일치하지 않습니다. 테스트를 준비해야 할 것 같습니다. 시간이 좀 걸릴 수 있습니다. 다른 일로 바쁘다.

그러나 이것이 사실이라면, 내 인터럽트 루틴 (하드웨어 클럭 확장 포함)에서 단순히 "usleep (10)"은 일반적으로 트릭을 수행하고 일이 잠기지 않게합니다. 나는 이것이 사실이 아니라고 확신합니다. :-(

@rewolff : Raspberry Pi 3에서 CPU가 600MHz로 조절되어 기본 I2C 속도가

Raspberry Pi 커널에 @kadamski 의 i2c-

또한이 전체 문제의 원인이되는 HW 버그를 해결하는 좋은 해결 방법이 될 것입니다.

@onnokort 2015 년 11 월 이후 현재 커널에있는 i2c-gpio 오버레이와 같은 의미입니까? https://github.com/raspberrypi/linux/blob/rpi-4.4.y/arch/arm/boot/dts/overlays/i2c-gpio-overlay.dts
오버레이에 대한 README에서 :

Name:   i2c-gpio
Info:   Adds support for software i2c controller on gpio pins
Load:   dtoverlay=i2c-gpio,<param>=<val>
Params: i2c_gpio_sda            GPIO used for I2C data (default "23")

        i2c_gpio_scl            GPIO used for I2C clock (default "24")

        i2c_gpio_delay_us       Clock delay in microseconds
                                (default "2" = ~100kHz)

@ 6by9 : 굉장합니다. 감사합니다. 오늘 새로운 것을 배웠습니다. 나는 이것을 아직 테스트하지 않았지만 예, 이것은 내가 찾고 있던 것과 정확히 일치합니다 (i2c-gpio-param에서 발견).

@popcornmix @ 6by9 닫을 수 있습니까? looong 시간 주위에 있었고 내 독서에서 dt param 항목은 괜찮은 옵션 인 것 같습니다.

I2C 하드웨어에서 확실히 잘 작동하지 않는 장치에 권장되는 해결 방법은 핀을 비트 배쉬하는 i2c-gpio 오버레이를 사용하는 것입니다.

그렇지 않으면 주소 ACK 단계의 클럭 확장이 업스트림 드라이버에서 지원됩니다.

추가 2 센트 : https://github.com/555kav555/i2c-bcm2835-corrected

오늘 저는 동아시아의 GY-955 패키지에있는 BNO055를 Pi 2B (BMC2835)로 100_000Hz에서 매우 추하게 작동하는지 테스트했습니다. 테스트를 위해 I2C 버스의 주파수를 50_000에서 400_000Hz로 변경했고 100_000Hz에서 문제를 발견했지만 50_000, 85_000, 115_000 및 125_000Hz의 경우 Adafruit (Adafruit_Python_BNO055)의 코드는 I2C 연결, 150_000에서 꽤 잘 작동합니다. Hz는 BNO055에 비해 너무 빠르지 만 작동하지만 값이 때때로 잘못되었습니다. 나는 오실로스코프로 주파수를 테스트하지 않았으며 / sys / class / i2c-adapter / i2c-1 / of_node / clock-frequency 파일 만 읽었으므로 약간의 불확실성이 열려 있습니다. 이제 ADA에서 BNO055에 대한 전체 인터페이스를 구현하기 시작합니다.
Facit : BMC I2C 처리의 하드웨어 버그는 100_000Hz에서만 나타납니다. 확인해야합니다.

참고로, 하드웨어 버그는 슬레이브 장치가 클록 스트레칭을 수행하고 0.9 ~ 0.999 I2C 클록주기 후에 SCL 라인을 해제 할 때 발생합니다. 라인이 상승하기 시작하고 파이 하드웨어는 다음과 같이 말할 것입니다. 오, 그는 클럭 스트레칭을하지 않았으므로 클럭 라인을 다시 낮게 당겨서 다음 클럭 펄스를 제공 할 수 있습니다.

이 버그는 클럭 기간에 남은 시간이 clk 라인이 라즈베리의 "HIGH"임계 값을 통과하기에 충분하지만 슬레이브 장치에 대해서는 충분하지 않거나 슬레이브에 노이즈 필터링이 있고 <x %의 시간 동안 높은 것으로 간주 할 때 발생합니다. 정상적인 I2C 클록 사이클 글리치.

이것은 "100kHz에서만 발생"하는 것이 아니라 슬레이브 장치의 응답 시간이 다른 값이어야한다는 점을 제외하고는 다른 많은 주파수에서도 발생합니다.

클럭이 100kHz라고 가정하면 정상주기는 5us 높고 5us 낮습니다. 이제 t = 0에서 pi가 클록 라인을 로우로 당겨 마지막 클록 사이클을 시작한다고 가정합니다. t = 5us에서 pi는 클럭 신호를 해제하지만 슬레이브는 여전히 바쁘고 클럭을 낮게 유지합니다. t = 9us에서 슬레이브가 완료되고 클럭 신호를 해제합니다. t = 10us에서 파이는 클럭 신호를보고 생각할 것입니다. 좋습니다. 클럭이 늘어나지 않습니다. 계속하면 클럭 신호가 다시 낮아집니다. 클럭 신호는 이제 1us 동안 만 높았으며 (커패시턴스 및 풀업 저항의 시간 상수로 인해 약간 더 적음) 슬레이브에서 볼 수 없습니다. 이제 다른 장치는 9 마이크로 초 후에 준비되지 않고 10.5 후에 준비됩니다. 이제 100kHz에서 파이는 "아직 낮고, 클럭이 늘어나고, 5 마이크로 초를 더 기다립니다. 이제 4.5 마이크로 초 클럭 펄스를 얻고 모든 것이 작동합니다.하지만이 장치를 90kHz로 실행하면 문제가 발생합니다. pi는 처음부터 11 마이크로 초를보고 클럭 신호는 1 마이크로 초 미만-> 문제로 높았습니다.

이것에 대해 불평하는 사람들은 다른 장치를 가진 사람들이 아닙니다. 그것들은 기본 100kHz에서 작동합니다. 그러나 버그는 여전히 매우 현실적이며 사용자와 내가 보유한 장치가 아닌 다른 버스 속도로 해당 장치에서 발생합니다.

응답 해 주셔서 감사합니다. 선택한 주파수에서 안정적인 전송을 얻은 이유를 매우 잘 설명합니다.
100_000Hz에서 문제는 9 ~ 9.99µsec 기간에 발생합니다.
85_000 Hz에서 문제는 1_000_000 / 85_000 * .9 = 10,59 µsec> 9.99 sec에서 시작하므로 클럭 스트레칭은 무시됩니다. 85_000 Hz 미만의 모든 주파수에 대해 문제의 시작점이 10,59 µsec보다 높습니다. .
115_000 Hz에서 버스 사이클은 1_000_000 / 125_000 = 8.7 µsec <9 µsec이므로 클럭 스트 레팅이 올바르게 감지되며 115_000 Hz보다 높은 모든 주파수에 대해 버스주기는 8.7 µsec 미만입니다.
그래서 문제가 생기면 필요한 주파수를 계산할 수 있습니다.
(http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html에서 정보를 읽었습니다.
기간의 .9 대신 .5가 표시되었습니다).

잘. 슬레이브가 유효한 클록 신호로 감지하는 것에 따라 다릅니다. 그리고 버스의 RC가 얼마나 지연되는지. 필자의 경우 슬레이브로 사용하는 AVR은 2 클럭 사이클 미만의 펄스를 글리치로 간주합니다. 내부 RC 클럭이 8MHz (+/- 10 % !!!) 인 경우 펄스를 감지하려면 최소 250ns가 필요합니다. I2C 사양에는 5 마이크로 초가 필요하므로 공식적으로 필요한 것과 더 이상 작동하지 않는 것 사이에는 20의 "마진"이 있습니다.

처음에 나는 노예의 시계를 늘려서 12us라고 할 수 있다고 생각했습니다. 이는 버스 커패시턴스가 문제를 다시 일으킬 수있는 충분한 지연을 추가 할 때까지 작동합니다. 따라서 해결하기가 매우 어렵습니다. 고객에게 표준 100kHz i2c를 사용하지 말라고 말해야하는 불편 함이 있습니다.

죄송합니다. 전체 구현 및 테스트 시나리오를 작성하려면 시간이 필요했습니다.
제게 주신 모든 정보에 감사 드리며 매우 도움이되었습니다.
내 테스트 시나리오는 2 개의 MEMS (GY-055로 패키징 된 BNO055, MPU-9250 / 6500으로 패키징 된 MPU9255, WHO_AM_I 레지스터에 MPU9255로 표시됨) 및 1 개의 GPIO 확장기 PCF 8574 (패키징 된 PCF 8574)로 빌드됩니다.
Pi (2b)의 I2C 클럭은 125kHz로 설정되었으며 / sys / class / i2c-adapter / i2c-1 / of_node / clock-frequency를 읽어 확인했습니다.
내 코드는 MEMS에서 데이터를 읽고 0.1 초의 지연으로 PCF 용 데이터를 쓰기 위해 100 번 실행됩니다.
결과:

• MEMS 초기화에 성공했습니다.
• I2C 버스를 통한 MEMS 데이터 읽기는 모든 사이클에서 성공적이었습니다.
• I2C 버스를 통해 PCF에 데이터를 쓰는 것은 모든 사이클에서 성공적이었습니다.

따라서 MEMS와 PCF는 표준 100kHz보다 높은 클럭을 수용합니다.
노인 환경에서는 AVR과의 통신이 직렬 회선을 통해 이루어지고, 두 번째 환경에서는 통신이 USB를 통해 이루어 지지만 완료되지 않았습니다. 실제로 BNO055로 인한 I2C 버스 문제로 인해 트립되었습니다. 내 환경을 위해 Pi 2b에 대한 해결 방법을 찾았으며 Pi 3에서도 작동하기를 바랍니다. 이것이 다음 테스트입니다. 그런 다음 2 개의 다른 MEMS, 1 개의 VL53L0X 및 1 개의 BME280을 통합해야합니다. 새로운 주파수에서 작동하고 버스 커패시턴스가 이러한 모든 요소를 ​​수용하기를 바랍니다.

저는 현재 RPi 3 Model B +에서이 문제를 다루고 있으며 Advamation 기사에서 설명하는 것과 다른 결과를보고 있습니다. 실리콘은 최근에 유행하지 않았습니까?

짧은 버전은 read-preACK, write-preACK 또는 write-postACK로 확장하면 작동하는 것처럼 보입니다. 길거나 전혀 늘려야 할 유일한 시간은 read-postACK입니다. 그래도 확실한 말을하기 전에 실험을 정리해야합니다.

먼저 용어에 대한 참고 사항입니다. Advamation 기사는 다음과 같이 말합니다.

따라서 Raspberry Pi를 사용하는 I2C는
슬레이브가 시계 확장을 전혀 사용하지 않거나
슬레이브는 I2C 읽기 ACK 단계 (ACK / NACK을 읽은 후) 직후에 종료시에만 클록을 늘이고 그 다음에는 0.5 클록주기 이상 늘립니다.

"I2C-read-ACK-phase"라는 용어는 다소 모호해 보입니다. I2C 읽기 명령 (즉, post-address R / W̅ 비트가 설정 됨) 인 경우 슬레이브는 괄호와 달리 A̅C̅K̅ 비트를 읽지 않고 기록합니다. 여기서 "read-postACK"라고 말하면 R / W̅ 비트가 주소 바로 뒤에 설정되어 (아마도 SMBus처럼 프로토콜에 의해 변경되지 않았 음) 슬레이브가 A̅C̅K̅ 응답을 작성했음을 의미합니다.

여기에서 암시했듯이 RPi가 SCL이 슬레이브에 의해 낮게 유지되고 있음을 감지하면 내부 SCL 클럭이 반주기 (5μS)만큼 지연되는 것으로 보입니다. 이 버그는 슬레이브가 _almost_ 반주기 동안 SCL을 낮게 유지하면 트리거됩니다. 이런 일이 발생하면 RPi는 여전히 SCL을 하이로 내린 다음 SCL 클럭이 트리거 될 때 즉시 아래로 내립니다. 이로 인해 일부 장치는 펄스로 볼 수 있지만 다른 장치는 그렇지 않은 런트 클럭 펄스가 발생합니다. (참고 : I2C 사양 은 5μS의 공칭 SCL 하이 타임을 의미하며 RPi I2C 인터페이스의 기본 속도 인 100kHz에서 최소 4.0μS 시간을 설정합니다.)

내 실험에서 read-preACK, write-preACK 및 write-postACK 단계에서 RPi는 허용되는 최대 SCL 하이 타임이 4μS 정도인지 확인합니다. SCL 클럭을 그 단계로 되돌리려는 것 같았습니다. RPi가 SCL 라인을 출시 한 직후 샘플링 한 것으로 의심되며, SCL이 여전히 낮 으면 SCL 클럭을 반 위상으로 되돌립니다.

그러나 read-postACK 단계에서 SCL 라인이 약 6–9μS 동안 낮게 유지되면 RPi가 런트 클럭 (<4μS, 종종 2μS 이하)을 방출하는 것을 확인했습니다. 이 단계에서 Broadcom 엔지니어는 고용량 라인에서 반 위상을 지연시킬 가능성을 줄이려는 다른 경로를 따르고 있다고 생각합니다. 슬프게도-우리가 본 것처럼-부족합니다.

따라서 현재 코드는 시간이 걸릴 수있는 read-postACK 단계 (예 : ADC 변환)에서 SCL을 ½ 사이클 이상으로 확장해야합니다. 내가 실패하면

현재 실행중인 테스트는 PIC16F1619를 슬레이브 장치로 사용합니다. 슬레이브 장치는 루프를 사용하여 ACK 전후의 읽기 및 쓰기 명령 모두에서 클록을 늘립니다. 이 루프의 길이와 오버 헤드는 3μS (RPi가 SCL을 낮게 유지하는 시간보다 작음)에서 90μS까지 0.35μS 씩 증가합니다. RPi에 두 개의 레지스터에 서로 다른 값을 제공하는 Python 프로그램이 있습니다. 그런 다음 다시 읽은 다음 다시 읽기 값이 정확하다고 주장합니다. 사용되는 값

Piquan,
Broadcom은이 문제가 첫 번째 클럭 스트레치에서만 발생한다고 선언함으로써이를 경시하고 있습니다. 나는 이것이 사실이라고 생각하지 않습니다. 당신은 그것을 확인할 수 있어야합니다. Advamation은 broadcom 문구를 따르는 것 같습니다.

@rewolff 글쎄, 그들의 해석에 뭔가가있을 수 있습니다. "첫 번째 클럭 확장"이 "주어진 단계에서 SCL이 둘 이상의 클럭 변환에 의해 확장되는 첫 번째 시간"을 의미하는 경우 해당 설명이 정확합니다. 둘 이상의 클럭 주기로 확장하면 예 : 모두 5 단계 이상 스트레칭하면 좋은 상태입니다. 적어도 내가 지금까지했던 모호한 실험에서; 더 정확한 실험은 아직 오지 않았습니다.

RPi의 I2C가 클럭 스트레치를 처리 할 수 ​​있고 처리 할 수없는 경우를 입증하고 BCM이 엔지니어에게 보낼 수있는 재현을 얻을 수있는 더 나은 실험을 수행하게되어 기쁩니다.

안타깝게도이 문제를 해결하는 데 필요한 매우 중요한 실리콘 레브가 있습니다. SCL이 (내부 또는 외부 소스에 의해) 낮게 유지 될 때 SCL 분배기 클럭을 틱하지 않아도됩니다. 이는 아마도 비용이 많이 드는 실리콘 수준의 변경이 필요할 것입니다. 대부분의 ECO는 금속 수준입니다. 이것은 ... 음, 저렴하지는 않지만 실리콘보다 훨씬 저렴합니다.

여기서 나의 주요 목표는 몇 가지 실험적 증거를 통해 RPi와 함께 작동하거나 작동하지 않을 노예 유형을 특성화하는 것입니다.

Broadcom이 I2C 컨트롤러를 재 설계하도록 설득하려면 재현 시나리오와 같은 더 견고한 데이터가 필요한 것 같습니다. 견고한 데이터가 있더라도 엔지니어는 다음 개정을 위해 실리콘을 개정 할 가치가 있다고 경영진을 설득해야합니다.

즉, 재현 가능한 시나리오를 설계하는 데 시간을 투자하여 BCM 엔지니어가 문제를 명확하게보고 테스트 할 수 있도록 할 것입니다. 하지만 저는 여기에서 발견 한 내용을 Broadcom에 전달하기 위해 커뮤니티 회원에게 의존 할 것입니다. 나는 그들에게 채널이 없습니다.

실리콘 대 금속 변화에 대한 커뮤니티에 대한 이전 의견에 대해 명확히해야합니다.

SparkFun 또는 Adafruit에서 보드를 얻는 경우, 종종 그 동작을 변경하기 위해 함께 자르거나 납땜 할 수있는 흔적이 있다는 것을 알고 있습니까? 대부분의 I2C 보드에는 주소 변경, 풀업 저항 활성화 또는 비활성화 등을 위해 변경할 수있는 트레이스가 있습니다.

Microchip 설계자는 동일한 작업을 수행합니다. 마이크로 칩의 금속층에 많은 변화를 줄 수 있으므로 실리콘 층을 변경할 필요가 없습니다. 실리콘 레이어를 변경하는 것은 어렵고 비용이 많이 드는 반면 (보드의 칩을 변경하는 것과 같이) 금속 레이어는 변경하기가 훨씬 쉽기 때문입니다 (보드의 트레이스를 변경하는 것과 같이).

설계자가 앞서 생각하고 칩의 동작을 변경하는 금속 연결 (기본적으로 점퍼)을 만들기 때문에 금속 레이어에서 많은 유용한 변경이 이루어질 수 있습니다.

그러나 계획하지 않은 변경 사항이 있고 칩 내에서 트레이스를 다시 라우팅하여 만드는 방법을 알 수없는 경우 실리콘을 변경해야합니다. 실리콘은 훨씬 더 많은 계획, 검증 및 마스킹이 필요하므로 변경하기가 어렵습니다.

“충분히 좋은”실리콘 층을 가진 많은 회사들은 가능한 한 오랫동안 그것을 사용할 것입니다. 그들은 칩의 여러 개정판에서 실리콘 층의 일부를 재사용합니다.

나는 그것이 BCM이있는 곳이라고 생각한다. 그들은 실리콘 층의이 부분을 처음부터 재 설계하는 것을 정당화하기 전에 드라이버 나 금속에서이 버그를 수정할 수 없다는 좋은 증거가 필요하다.

이 문제를 해결하기 위해 기존 실리콘을 재조정 할 가능성은 극히 낮습니다 (예비 $ 1M이 있습니까?). 하지만 미래의 칩에는 수정이있을 수 있습니다.

2018 년 9 월 5 일 수요일 02:13:19 AM -0700에 Joel Ray Holveck은 다음과 같이 썼습니다.

재현 시나리오와 같은 더 확실한 데이터가 필요한 것 같습니다.
Broadcom이 I2C 컨트롤러를 재 설계하도록 설득하십시오. 심지어
확실한 데이터를 제공하기 위해 엔지니어는 경영진에게
다음 개정을 위해 실리콘을 개정 할 가치가 있습니다.

그들은 이미 6 년 동안 3 번의 실리콘 개정을했습니다.
"고치지 않을 것"이라는 그들의 결정을 입증했습니다.

0.5 사이클 이상 늘이면 몸매가 좋아집니다.

난 그렇게 생각하지 않아. CLK를 릴리스 할 때마다 "직전
broadcom이 다시 보입니다. "시간이 지나면 짧은 맥박이 발생합니다.
클럭 신호 방출을 5 마이크로 초만큼 지연시켜
항상 0.5 사이클을 벗어납니다. 그러나 그것은 작동하지 않았습니다.

Wed, Sep 05, 2018 at 02:28:53 AM -0700, James Hughes는 다음과 같이 썼습니다.

의 respin이있을 가능성이 매우 낮습니다.
이 문제를 해결하기 위해 기존 실리콘을 사용했습니다 (예비 1 백만 달러가 있습니까?). 미래
칩은 문제를 해결할 수 있습니다.

나는 그것을 의심한다. KNOWN 버그가있는 BCM2835에서 BCM2836으로
BCM2837에 대한 동일한 버그와 BCM2837B0에 대한 동일한 버그.

이제 다음 개정판이 왜 다를 것이라고 생각하십니까?

BCM은 목표 시장을 가지고 있습니다 : 이러한 칩을위한 휴대폰과 TV 스틱. 에
그들의 목표 시장은 아무도 범용으로 소프트웨어 I2C를 수행하지 않습니다.
AVR 및 PIC와 같은 마이크로 컨트롤러. 그들은 이것을 고치지 않을 것입니다.

이 조사 노력이 필요한 것은 부끄러운 일입니다. 내가 전에 이것을 다루는 정오표를 물었을 때 그것은 하나가 없다고 생각했습니다. 이제 변경되었고 URL이 있습니까? 이상적으로는 Broadcom이 오류를 정확하게 설명하고 오류가 발생할 때 커뮤니티에 도움이되므로 호환되는 구성 요소에 대한 해결 방법이나 평가가 확신을 가지고 쉽게 해결할 수 있습니다. 설명으로 정확하게 번역하고 싶지 않은 경우 관련 HDL의 스 니펫 정도까지.

클럭 확장을 허용 할 때 반 비트 클럭 제수를 중지하라는 제안은 좋은 제안입니다. 작동합니다.

문제는 I2C 모듈의 일부가 "최대 클럭 속도"로 실행되어야한다는 것입니다. 이제 I2C 모듈은 일반적으로 200kHz보다 빠르지 않기 때문에 좋은 저전력 모듈입니다.

내 게시물의 주된 이유는 원래 게시물 의 시작 부분에서 말한 것입니다.

저는 현재 RPi 3 Model B +에서이 문제를 다루고 있으며 Advamation 기사에서 설명하는 것과 다른 결과를보고 있습니다. 실리콘은 최근에 유행하지 않았습니까?

2013 Advamation 작성 후 I2C 하드웨어 또는 드라이버에 상당한 변경 이 있었고 커뮤니티에서이 버그가이 버그에 어떤 영향을 미칠 수 있는지 알고 있다면 실험을 적절하게 변경해야합니다.

근본적인 문제는 하드웨어에 있다는 것을 알고 있지만, 누군가가 실험을 통해 드라이버에서 관련이없는 것처럼 보이는 레지스터를 변경하면 실제로이 버그의 동작이 변경된다는 것을 발견했을 수 있습니다. 또한 BCM2837에 RPi 2와 동일한 I2C 모듈이 있는지 확인 하지 않았습니다 (이 문제가 처음보고 된 이후 I2C 하드웨어가 변경되지 않았 음을 가장 최근에 확인할 수있었습니다). 또한 BCM283x 스테핑에 대한 정보를 찾지 못했습니다. 내가 아는 한, BCM2836 시대에 금속 변화가있을 수있었습니다.

나는 Broadcom을 강타하는 데 관심이 없으며 향후 개정판이 어떻게 변경 될지 추측하거나 그와 비슷한 것을 추측합니다.

여기서 나의 주요 목표는 현재 행동을 명확하게 문서화하는 것입니다. 시간이 지남에 따라 변한 것 같습니다. 향후 사용자가 내 실험을 재현하여 결과가 여전히 유효한지 확인하거나 개선하거나 다른 조건을 테스트 할 수 있도록하는 두 번째 목표가 있습니다. Broadcom 엔지니어가 원하는 경우 테스트를 쉽게 재현 할 수 있도록하는 또 다른 보조 목표가 있습니다. 이 두 가지 모두 내 실험을 게시해야한다는 것을 의미하며, 이는 또한 도움이됩니다. 내 자신의 오만 때문에 실험을 게시하는 경우 실험을 더 엄격하게 만들기 위해 더욱 노력할 것입니다.

나의 현재 실험 계획은 PIC16F1619를 슬레이브 구현으로 사용하는 것입니다. 시계 스트레칭 실험을 할 수있을만큼 빠르고 다재다능하고, 작업하기에 충분히 쉬우 며, 다른 실험자들이 내 결과를 재현 할 수있을만큼 충분히 일반적입니다. 결과가 모호하다면 FPGA로 실험을 할 수도 있습니다. 슬레이브로 비트 배싱 구성에서 다른 Raspberry Pi를 사용하여 합리적인 세분성을 얻을 수 있는지 확인할 수 있지만 실시간 테스트를 수행하려면 전체 OS가없는 것이 필요하다고 생각합니다.

다른 몇 가지 문제를 해결하려면 :

내 원본 게시물 이 불완전해서 죄송합니다. 실수로 초안을 올렸습니다. 내가 만든 변경 사항은 매우 사소하므로 그대로 두겠습니다.

나는 SCL이 외부 적으로 낮게 유지되는 동안 클럭 제수를 중지한다는 아이디어에 대해 독창성을 주장하지 않습니다. 나는 그것을 다른 곳에서 읽었지만 어디에 있는지 기억하지 못한다. 나는 그것이 raspberrypi.org 의

I2C HW 블록은 고정 / 변경되지 않았으며 bcm2835 / 6 / 7에서는 너무 비싸서 칩을 다시 회전해야하므로 그럴 가능성이 낮습니다.

나는 Advamation이 누구인지는 모르지만 RPF (T) 그룹에게는 실현되지 않았기 때문에 기사의 정확성을 보장 할 수 없습니다.

친애하는 여러분, Pi 2B와 3에서 매우 이상한 현상이 나타났습니다. 설명하려고합니다.
6 월 말에 BNO055를 구현하기 시작했을 때 이전 버전의 Raspbian을 사용했고 (지금은 버전이 아닙니다) i2cdetect를 사용하여 잘못된 I2C 주소를 많이 얻었습니다. 이를 위해 인터넷을 살펴 보았고 좋은 정보가있는이 포럼을 찾았습니다. 이를 위해 위에서 설명한대로 I2C 주파수를 변경하고 모든 고스트가 사라지고 작업 할 수 있습니다. 8 월 중순에 Raspbian을 raspbi-dev 4.14.62-v7 +로 업그레이드했고 시스템이 약간 불안정 해졌지만 작동 할 수 있습니다. 업데이트에서 업데이트까지 시스템이 더 불안정 해졌고 sd 카드에서 누출이 발견되었습니다. 따라서 NOOBS (Linux raspbi-dev 4.14.62-v7 + # 1134 SMP Tue Aug 14 17:10:10 BST 2018 armv7l)를 통해 Raspbian을 다시 설치했고 I2C 주파수 설정을 잊었지만 유령이 나타나지 않았습니다. 좋아요, 저는 버스에서 마이크로 컨트롤러를 사용하지 않고 MEMS와 GPIO 익스텐더 만 사용하지만 Raspbian의 i2c 코드에 해결 방법이 있다고 느낍니다. 또한 감지 된 누출은 불완전한 업그레이드에서 비롯되었다고 생각하며 동일한 카드를 사용하고 있으며 누출이 감지되지 않았습니다.

@ hmf2015 이 문제는 매우 구체적인 I2C 문제에 관한 것입니다. SD 카드 문제는이 I2C 문제로 인한 것이 아닙니다. SD 카드가 제대로 작동하지 않으면 새 SD 카드를 사용해보십시오. 일부 카드는 좋지 않아 빠르게 작동하지 않습니다. 내 SD 카드가 지난달 작동을 멈 췄고 교체해야했습니다.

일반적으로 I2C 고스트는이 문제로 인한 것이 아닙니다. 다음과 같은 이유로 가장 자주 발생합니다.

• 좋은 전원 공급 장치가 없습니다. 나는 이것을 좋아 한다 .
• 케이블이 너무 깁니다. I2C는 1m보다 긴 케이블에서는 잘 작동하지 않습니다.
• 케이블에는 용량 성 결합이 있습니다. I2C 핀 (SCL 및 SDA)이 함께 꼬인 경우 문제가 될 수 있습니다. 때때로 사람들은 I2C 핀을 꼬아 문제를 일으키는 연선 케이블 (예 : 이더넷 케이블)을 사용합니다. 트위스트 페어 케이블을 사용해야하는 경우 Vss (접지)로 SCL을 비틀고 Vdd (3.3V)로 SDA를 비틀십시오. 섹션 7.5에서 I2C 사양 을 확인하세요.
• I2C 장치는 5V입니다. Raspberry Pi는 3.3V에서 I / O를 수행합니다. 전압이 다르면 문제가 발생할 수 있습니다. (BNO055는 3.3V가 필요하므로 5V로 사용하면 문제가 있습니다.)

나는 우리가 특정 문제에 대해 이야기하고 있다고 말했습니다. 이 문제로 인해 일부 장치가 유령을 만들 수 있지만 많은 장치는 아닙니다. 이 문제로 인해 장치가 유령을 만들면 유령을 많이 만들지 않습니다. 나는 당신의 문제가 다르다고 생각합니다.

당신이 "sd 카드에서 누출을 발견했다"고 말할 때 무슨 뜻인지 모르겠습니다. 그것은 중요한 문제이지만이 웹 페이지의 문제에서 우리가 이야기하는 문제는 아닙니다. 이 대화는 특정 버그에 대한 것입니다. 이 버그는 SD 카드에 영향을 미치지 않습니다.

최근 Raspbian이 I2C 작동 방식을 변경했다고 생각하지 않습니다. Raspbian은이 버그를 수정할 수 없다고 생각합니다. 우리가 틀렸을 수도 있습니다. 이에 대해 알려 주셔서 감사합니다.

우리를 돕기 위해이 정보를 알려주신다면 감사합니다. 도움을 요청하기 위해이 정보를 알려주는 경우 Raspberry Pi 포럼 에서 질문 할 수

이 정보를 알려 주셔서 감사합니다!

답변 주셔서 감사합니다.하지만 sd 카드 문제는 O / S에 의해 생성되었고, 내 (Unix) 호스트에서 카드를 확인했는데 괜찮 았으며 이제 동일한 CAD가 새로 설치 한 후에도 제대로 작동합니다.
I2C 버스의 유령은 더 높은 주파수로 사라지고 이제 재설치 후에는 나타나지 않습니다. R / C 문제와 반사는 제외 할 수 있습니다. 3.3V 문제를 알고 있지만 최소 1 레벨은 더 적습니다.
BNO055 패키지에는 전압 레글 레이터가 있습니다.
나는 또한 I2C 문제가 이전과 같을 것이라고 생각했지만 현재로서는 차이를 감지하기 위해 Raspbian의 소스 코드를 조사 할 시간 (및 관심)이 없습니다. 작업 환경에서.
요소 목록은 내가 게으 르기 때문에 직렬 회선이나 USB를 통해 연결하는 마이크로 컨트롤러가 아니라 BCM이 지원하는 Andoid 환경 (실제 Unix 사용)에서 작업하고 있음을 보여줍니다. 당신의 환경에서는 조건이 저보다 더 제한적이기 때문에 당신의 문제가 줄어들지 않을지는 말할 수 없지만 저는 희망합니다.

안녕하세요 hmf2015,
이것은 포럼이 아닙니다. 이것은 버그 추적기입니다. 이 주석 목록은 문제와 관련이없는 버그에 대해 설명합니다. 적절한 포럼이나 헬프 데스크에 문제를 논의하십시오. 다시 한 번 귀하의 질문에 감사드립니다. "아마도 동일할까요? 내 설명이 해당 버그를 해결하는 데 도움이 될까요?" 그러나 지금 우리는 당신이보고있는 것이 무관하다는 것을 확실히 알고 있습니다.이 토론을 더 이상 "오염"시키지 마십시오.

뿡 빵뀨
안녕하세요, 오래 전에 다시 시작하는 동안 I2C 상태 시스템의 문제를 언급하고이 문제와 관련된 코드를 게시했습니다.
무슨 뜻인지 잘 모르겠지만 I2C에 연결된 WM8731 코덱에 문제가 있습니다.
2-3이 다시 시작되면 I2C 버스가 완전히 끊깁니다. i2cdetect는 첫 번째 줄을 제외한 어떤 정보도 표시하지 않고 전화를 끊습니다. 복구하는 유일한 방법은 전원 끄기 / 켜기주기입니다.
언급 한 문제처럼 보입니까?
4.19 메인 커널을 사용하고 있습니다.

@ sergey-suloev i2cdetect가 8 개 또는 16 개 주소 이후에 스캔을 계속하지 않을 때, 이것이이 문제와 관련이 없다고 말할 것입니다. 이 문제는 장치가 다음 클록주기를 위해 아직 준비되지 않았 음을 나타 내기 위해 클록 확장을 수행 할 때 나타납니다. I2C가 거의 40 년 전에 설계되었을 때 하드웨어 구현에서도 가능했을 것입니다. 그러나 오늘날 하드웨어는 10 마이크로 초가 하드웨어에서 구현되는 시간이되기 때문에 항상 다음 클럭 사이클을 처리 할 준비가되어 있습니다.