Linux: I2C ब्रॉडकॉम बग वर्कअराउंड।

यदि ड्राइवर में वर्कअराउंड इसे अधिकांश उपयोगकर्ताओं के लिए बेहतर बनाता है, तो सुनिश्चित करें कि इसे शामिल किया जाना चाहिए।
क्या आपके पास एक उपयुक्त पैच है?

नहीं अभी तक नहीं।

1) मैंने अभी तक I2C ड्राइवर में देरी नहीं की है। लगभग एक साल पहले, मेरे पास इसे स्वयं लिखने की योजना थी लेकिन इससे पहले कि मैं इसके आसपास पहुँचता, किसी और ने इसे लिखा था। इसलिए जो पहले से ही इस ड्राइवर को जानता है, वह पांच मिनट की परियोजना के रूप में ऐसा करने के लिए बेहतर हो सकता है। ड्राइवर को जाने में मुझे कम से कम कई घंटे लगेंगे।
2) यदि आप (और शायद अन्य) सहमत हैं कि फिक्स / वर्कअराउंड वॉरंटेड है तो पहले इस पर चर्चा करें।
3) मैं इसे एक "टूडू" के रूप में प्रलेखित करना चाहता था, हमें इसे नहीं भूलना चाहिए ...।
4) हो सकता है कि कोई व्यक्ति एक अलग समाधान सुझाएगा।

वर्कअराउंड के बारे में बोलना: एसडीए लाइन द्वारा वर्कअराउंड को तब भी कम किया जा सकता है जब हम एक नया लेनदेन शुरू करने की कोशिश कर रहे हैं। यह स्पष्ट रूप से एक "समस्या" स्थिति है।

"यह गलत हो जाता है" मामला "सामान्य" मामलों के लिए दुर्लभ हो सकता है। कई लोगों के पास I2C- बस में एक हार्डवेयर-आई 2 सी मॉड्यूल होगा। जब I2C का आविष्कार किया गया था "10us" अनुरोधों को संभालने के लिए कुछ चिप्स के लिए "बहुत ही कम" समय सीमा हो सकती है, इसलिए घड़ी की स्ट्रेचिंग आवश्यक थी। आजकल किसी भी हार्डवेयर I2C कार्यान्वयन को "फास्ट I2C" को और भी तेजी से संभालने में सक्षम होना चाहिए।

यह उस तरह से मेल खाता है जिस तरह से एटम वालों ने अपने एसिंक्स मॉड्यूल को लागू किया था। बाहरी रूप से प्रदान की गई घड़ी (i2c-slave या SPI-slave) पर मॉड्यूल चलाने के बजाय, मॉड्यूल अभी भी प्रोसेसर घड़ी पर चलता है। और यह सभी आने वाले संकेतों को फ़िलिप्लोप्स के एक समूह के माध्यम से पारित करके सिंक्रनाइज़ करता है। अच्छा हार्डवेयर डिजाइन। विकल्प IMHO बेहतर है: बाहरी घड़ी से मॉड्यूल को चलाएं, और जब डेटा अन्य (सीपीयू-) घड़ी डोमेन से गुजरता है तो सिंक्रनाइज़ करें। उदाहरण के लिए, SPI मॉड्यूल 20MHz पर कार्य करने की अनुमति देता है, भले ही CPU केवल 8 पर चलता हो।

वैसे भी। पर्याप्त हार्डवेयर जुआ।

सुझाए गए समाधान: लेन-देन की शुरुआत में एक अतिरिक्त घड़ी चक्र जारी करें जब एसडीए लाइन अभी भी कम है। (यह "स्टार्ट" स्थिति जारी करने में सक्षम होने के लिए उच्च शुरू होना चाहिए)।

सबसे पहले, मैं I2C के बारे में बहुत कम जानता हूं। मैंने वर्क के बारे में गर्ट और अन्य लोगों से बात की है।

I2C के साथ दो समस्याओं के बारे में जाना जाता है:

1. आपके द्वारा बताई गई घड़ी की स्ट्रेचिंग की समस्या
2. पुनरारंभ करते समय I2C राज्य मशीन के साथ समस्या

1 के लिए, गर्ट का विचार है कि कोई मूर्खतापूर्ण समाधान नहीं है।
अगर I2C गुलाम आप ठीक हैं घड़ी खींच समर्थन नहीं करता है।
यदि I2C घड़ी एक बंधी हुई राशि से फैलती है, तो I2C घड़ी की आवृत्ति कम करने से समस्या से बचा जा सकता है
पिछले मामलों में नहीं पड़ने वाले गुलामों के लिए एक बिट पीटने वाले ड्राइवर पर स्विच करना एक सुरक्षित समाधान है।

मुझे नहीं पता कि आपका प्रस्ताव काम करेगा या नहीं। मुझे यह सुनने में दिलचस्पी होगी कि क्या यह समस्या को कम करता है, या इसे पूरी तरह से ठीक करता है।

गर्ट का कहना है कि उनके पास बग की एक निराशा है कि वह कोशिश करेंगे और रिहा हो जाएंगे।

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 डिवाइस हैं। जाहिरा तौर पर मॉड्यूल के तीन की घड़ी की आवृत्ति (आरसी घड़ी) इस तरह से अलग होती है कि वे घड़ी के साथ "गलत तरीके से" समाप्त हो जाती हैं। घड़ी की आवृत्ति को कम करने से उन मॉड्यूल के लिए समस्याएं तय हो गई हैं।

यदि क्लॉक स्ट्रेचिंग में देरी तय नहीं है, लेकिन, कहते हैं, 5 से अधिक माइक्रोसेकंड से भिन्न होता है, तो समस्या को मारने का अधिक या कम सांख्यिकीय मौका होता है। मेरे मामले में दास को घड़ी की चौड़ाई के 0.25 माइक्रोसेकंड की आवश्यकता होती है। तो घड़ी का खिंचाव 5% समय में समाप्त हो जाता है, जो कि घड़ी को बदलने में बीसीएम के लिए अग्रणी होता है, तब चीजें गलत हो जाती हैं। तो, इस मामले में, 20 में से 1 हस्तांतरण गलत होगा। (स्पेक्स का कहना है कि एक घड़ी पल्स के लिए मिनट 250ns है। वास्तव में इसका मतलब यह नहीं है कि अगर यह छोटा है तो यह नहीं देखा जाएगा। मुझे लगता है कि इसके देखे जाने की संभावना 100% से> 250ns से 0% <पर रैखिक रूप से जाती है। 125 नं।)

मैंने कल घड़ी की स्ट्रेचिंग अवधि को इस तरह से बढ़ाया है कि यह 5 माइक्रोसेकंड विंडो-ऑफ-अवसर में 2.5 माइक्रोसेकंड के निशान के आसपास होगा। अगर मैं खिड़की की शुरुआत के लिए लक्ष्य रखता हूं और मेरी आरसी घड़ी तेजी से चलती है, तो मैं "0" को मारूंगा जो बग को ट्रिगर करता है। अगर मैं 5 के लिए लक्ष्य, एक ही बात है। इसलिए अब मैं बुरी जगहों से दूर, बीच में निशाना साध रहा हूं। लेकिन I2C घड़ी को 80kHz में बदलें, और BAM, मैं संवेदनशील स्थान के लिए सही लक्ष्य बना रहा हूं ... (और अगर यह 80kHz के साथ नहीं होता है, तो यह 80 और 100 के बीच कुछ मूल्य के साथ होगा)।

यहाँ Gert का I2C बग का वर्णन है:
https://dl.dropbox.com/u/3669512/2835_I2C%20interface.pdf

हा! मैंने अपने टेस्ट-बोर्ड को बिल्कुल उसी तरीके से लिखा है। मैंने SCL ट्रेस को काट दिया है और वहां पर एक 0.1 "जम्पर कनेक्टर लगा दिया है। जबकि वहां न नापने पर एक सामान्य जम्पर या 100 ओम अवरोधक वाली महिला कनेक्टर होती है।

मुझे नहीं लगता कि यह केवल पहली घड़ी में होता है। इसका मतलब है कि मैं समस्या के चारों ओर काम कर सकता है या तो घड़ी खींचकर बिल्कुल नहीं (जैसा कि अधिकांश हार्डवेयर I2C चिप्स शायद करते हैं), या घड़ी के खिंचाव को कम से कम एक पूर्ण चक्र तक ले जाने के कारण।

मैंने अपने i2c स्लेव कोड को इस तरह से इंस्ट्रूमेंट किया है कि मैं घड़ी के खिंचाव को 0.5 माइक्रोसेकंड इंक्रीमेंट से बदल सकता हूं। मैं इसे I2C पर XXX के लिए क्लॉक स्ट्रेच को बदलने के लिए कमांड कर सकता हूं और फिर यह डिफ़ॉल्ट मानों को वापस बदलने से पहले 50 मिलिसेकंड के लिए उस तरह काम करता है। (अगर यह काम नहीं करता है, तो हमें इसे फिर से काम करने की आवश्यकता है। इस तरह से मैं इन सेटिंग्स के लिए मूल्यों की एक पूरी श्रृंखला को जल्दी से स्कैन कर सकता हूं, जबकि एक तर्क विश्लेषक के साथ एसडीए और एससीएल लाइनों की निगरानी करना। "देरी देरी XXX" भेजना और फिर। एक स्टिंग भेजने में 25 मिलिसेकंड लगते हैं। स्क्रिप्ट में एक काउंटर बढ़ाना और "अगली देरी" भेजना शेल स्क्रिप्ट को लगभग 100ms में ले जाता है। इसलिए मैं लगभग 10 सेकंड में 100 संभावित मानों को स्कैन कर सकता हूं।

मैं अब देरी पर हो रहा बग देखा है। तो सिद्धांत: "यह केवल पहले पर होता है" सही नहीं है।

"सुपर कुशल" रुकावट हैंडलर के रूप में: हाँ, मैं भी ऐसा कर सकता हूं। बात यह है: क्लॉक स्ट्रेचिंग फीचर मुझे इंटरप्ट रूटीन में "इस बाइट को हैंडल" कोड डालने की अनुमति देता है और कुछ माइक्रोसेकंड या कुछ मिलिसेकंड लेने की चिंता नहीं करता है। सिद्धांत रूप में घड़ी की स्ट्रेचिंग सुनिश्चित करेगी कि मास्टर अगले एक के साथ जारी रखने से पहले इस बाइट को संभालने के लिए मेरा इंतजार कर रहा है। 2835 में बग के साथ उस योजना का पूरी तरह से पर्दाफाश हो गया है। मैं अब केवल घड़ी की स्ट्रेचिंग को रोकने का कारण बनता हूं, और फिर 70 माइक्रोसेकंड में बाइट को संभालने के लिए समाप्त होने की उम्मीद करता हूं।

मेरे लिए "साइकल काउंट" है, जिसका उद्देश्य मेरे लिए 5 माइक्रोसेकंड की आधी घड़ी के बीच में घड़ी की स्ट्रेचिंग जारी करना है। अगर मैं शुरुआत के लिए लक्ष्य रखता हूं (4.9 माइक्रोसेकंड क्लॉक-हाई-पीरियड का कारण बनने के लिए) तो मेरे गुलाम की घड़ी कुछ प्रतिशत तेजी से चल सकती है और बग को आधा चक्र पहले ट्रिगर कर सकती है। तो आधे-घड़ी के चक्र के दोनों छोर खतरनाक हैं, मुझे एक छोटे, लेकिन मान्य पर्याप्त घड़ी चक्र के लिए लक्ष्य बनाना है।

मॉड्यूल में परिवर्तन IMHO सरल है: जब SCL "उच्च संचालित होता है" (अर्थात बिल्कुल भी संचालित नहीं होता है), I2C मास्टर मास्टर घड़ी को रोकें। यह बहुत लंबे समय तक I2C बसों को अनुमति देने का साइड इफेक्ट है क्योंकि स्वचालित कैप स्ट्रेचिंग तब होती है जब बस कैपेसिटेंस कल्पना से ऊपर है।

यह: http://comments.gmane.org/gmane.linux.kernel.rpi/268 और यह: http://news.gmane.org/gmane.linux.kernel.rpi मदद कर सकता है?

मदद करने की कोशिश करने के लिए धन्यवाद, iz8mbw, लेकिन उन लोगों को इस (हार्डवेयर) बग से कोई लेना देना नहीं है।

मैंने अपनी I2C घड़ी को मापा है और यह 100kHz के रूप में सामने आता है जो ड्राइवर को लगता है कि यह होना चाहिए। ड्राइवर के पास एक "क्लॉक सोर्स" ऑब्जेक्ट है, जो आवृत्ति के लिए प्रश्न करता है और इसका उपयोग करता है। मैंने अभी तक आवृत्ति को प्रिंट करने के लिए अपने ड्राइवर को साधन नहीं दिया है।

बस उन लोगों के लिए जानकारी के लिए जो बग को कार्रवाई में देखना चाहते हैं, मेरे पास लॉजिक अनलसीयर डंप के रूप में कुछ "सबूत" हैं।
हम्म मैं छवियों को संलग्न कर सकता हूं, लेकिन बाइनरी ला डंप नहीं। वह यहां है: 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 के साथ एक रास्पबेरी पाई से नियंत्रित करने की कोशिश कर रहा हूं और मैं ईमानदारी से बस देने के करीब हूं और या तो बीगलबोर्ड पर स्विच कर रहा हूं या एसपीआई के माध्यम से एक एफपीजीए से बात कर रहा हूं जो फिर I2C सामान करता है ।

मेरे पास मेल में एक बोर्ड है जो ऐसा करने में सक्षम होना चाहिए (अपेक्षित डिलीवरी: कल)। एसपीआई कनेक्टर, I2C कनेक्टर। उस बोर्ड के साथ प्रयास करने के लिए एक अच्छी परियोजना होगी। अगर आपको सूचित किया जाना है तो मुझे एक ईमेल भेजें।

वर्तमान स्थिति: मैं व्यवहार को गर्ट के साथ देख रहा हूं: "जब दास एक ATMEGA है, तो केवल पहला चक्र गलत हो सकता है", और जब मैं अपने ATTINYs में से एक होता हूं, तो मैं पूरी ताकत से बग को देख रहा हूं।

यहाँ विलंब मैंने परीक्षण किया है:

और इस परीक्षण-सत्र के दौरान मनाया गया सबसे छोटा एससीएल पल्स 4.5 माइक्रोसेकंड था।

अब अटारी दास के साथ परीक्षण, ACK के लिए परीक्षित विलंब हैं:

और न्यूनतम पल्स चौड़ाई 41ns (मेरा माप रिज़ॉल्यूशन) है:

आह। मिल गया! ऐसा लगता है कि एक बाइट के एसीके से पहले की घड़ी "खतरनाक" है, लेकिन एसीके के बाद की घड़ी ठीक है .....

मैं और अन्य निश्चित रूप से बार-बार शुरू होने वाले मुद्दे को मार रहे हैं। मेरे पास http://cpansearch.perl.org/src/MDOOTSON/HiPi-0.26/BCM2835.xs हैपी में हिपी_आई 2 सी_ड्रेड_ग्रेस्टर_र्स है। यह उन उपयोगकर्ताओं के लिए काम करता है जिन्होंने इसे आज़माने या सी कोड को शामिल करने की रिपोर्ट की है (हालांकि यह केवल 5 लोग हैं), भले ही मुझे सही ढंग से पता नहीं चला कि यह कैसे निर्धारित किया जाए कि TX चरण पूरा हो गया था। मुझे लगता है कि मुझे कर्नेल मॉड्यूल संकलित करने और उपरोक्त कोड के खिलाफ मौजूदा परीक्षण चलाने के लिए सीखने की आवश्यकता है।

क्या हम सिर्फ कर्नेल को I2C हार्डवेयर को अनदेखा करने के लिए बाध्य नहीं कर सकते थे और उसी पिन पर बिटबिंग GPIO- आधारित I2C का उपयोग कर सकते थे? मुझे लगता है कि इसके लिए ओवरहेड अधिक स्वीकार्य होगा फिर हार्डवेयर में बग्स।

आप किस ओवरहेड की उम्मीद करते हैं? वर्तमान ड्राइवर 100kHz घड़ी में चूक करता है। तो एक i2c इंटरटीअल सेंसर से 10 बाइट को पढ़ने में लगभग 1ms लगता है। यदि आप बिटबैंग करते हैं, तो आपको उस समय सीपीयू चक्रों को मंथन करने की संभावना है ...।

मेरी प्राथमिकता ड्राइवर के लिए वैकल्पिक रूप से बिटबैंगिंग i2c को एक मॉड्यूल पैरामीटर (या शायद एक अलग मॉड्यूल यदि वह अधिक सुविधाजनक है) के माध्यम से समर्थन करना होगा।

कई डिवाइस क्लॉक स्ट्रेचिंग का उपयोग नहीं करते हैं (या बाउंड स्ट्रेच द्वारा क्लॉक स्ट्रेच कम गति पर सही तरीके से काम कर सकते हैं), इसलिए हार्डवेयर I2C ड्राइवर अभी भी उन मामलों में बेहतर है।

कर्नेल में ही GPIO पिन पर बिटबैंग I2C के लिए एक ड्राइवर है, इस ड्राइवर के पास उपयोगकर्तास्पेस से बिटबैंगिंग की तुलना में बहुत कम ओवरहेड है, और हार्डवेयर I2C ड्राइवरों के समान एपीआई को उजागर करता है। मेरा सुझाव उस ड्राइवर और हार्डवेयर I2C ड्राइवर दोनों को मॉड्यूल के रूप में संकलित करना होगा, फिर हार्डवेयर ड्राइवर को डिफ़ॉल्ट रूप से लोड करें।

@ फेरिन
क्या आप पाई पर बिटबैंग I2C ड्राइवर का उपयोग करते हैं?
इसे बनाने के लिए आपने क्या .config विकल्प जोड़े हैं? किसी भी स्रोत पैच?
आप ड्राइवर का उपयोग करने के लिए क्या चयन करते हैं (modprobe? अलग / देव / उपकरणों?)

पाई पर ड्राइवर का उपयोग नहीं किया, लेकिन मेरा एक दोस्त है जो इसे बीगलबोर्ड पर सफलतापूर्वक उपयोग करता है।
कॉन्फ़िगरेशन विकल्प I2C_GPIO है।
यदि दोनों और ब्रॉडकॉम ड्राइवर को मॉड्यूल के रूप में कॉन्फ़िगर किया गया था, तो ड्राइवर चुनना कर्नेल मॉड्यूल को लोड करने के समान सरल होगा।
GPIO मॉड्यूल को यह बताने के लिए मापदंडों की आवश्यकता होती है कि किस GPIO को SDA और SCL के रूप में उपयोग करना है, मुझे नहीं पता कि पैरामीटर क्या हैं, लेकिन dirvers / i2c / busses / i2c-gpio.c में बहुत अच्छी तरह से प्रलेखित स्रोत पर आधारित नहीं है, ऐसा लगता है कि उपयुक्त पारम 'sda = X scl = Y' हैं जहां X और Y आपके द्वारा उपयोग की जाने वाली चींटी हैं।

I2c-gpio मॉड्यूल स्वयं इसके मापदंडों को पारित करने का कोई तरीका प्रदान नहीं करता है। तो आपको एक और मॉड्यूल की आवश्यकता है जो प्लेटफ़ॉर्म डेटा को पंजीकृत करता है और कम से कम बस नंबर, एसडीए और एससीएल पिन को कॉन्फ़िगर करता है। मैंने इस तरह के एक मॉड्यूल की अवधारणा का प्रमाण लिखा है और यह 0 और 1 पर भी काम करता है लेकिन i2c-bcm2708 लोड किए बिना (pcf8574 i2cdetect द्वारा पता लगाया गया था, मैं gpio-pcf857x मॉड्यूल के साथ कुछ एलईडी ड्राइव करने में सक्षम था)। लेकिन तब मैंने अपना PCf8574 जला दिया जब पिन बदल रहा था (और मेरे पास अभी कोई अन्य i2c चिप्स नहीं है) तो मैं वास्तव में इसका परीक्षण नहीं कर सका। यहाँ कोड है

@ कदामसी
Sda_pin / scl_pin मॉड्यूल पैरामीटर बनाना उपयोगी हो सकता है। जैसा कि एक अनुरोध होगा।
क्या कोई उनके लिए इस काम की पुष्टि कर सकता है?

जितना दिखता है, उससे कम तुच्छ है: यह उम्मीद करता है कि यह सभी तरह से एक प्लेटफॉर्मडेटा संरचना को पारित कर देगा।

दूसरी ओर, प्लेटफ़ॉर्म यह निर्धारित नहीं करता है कि आप आज कौन से जीपीआईओ का उपयोग करने जा रहे हैं, इसलिए इसे बदलने के लिए काम में लाना उचित लगता है। (सामान्य रूप से प्लेटफ़ॉर्म डेटा निर्दिष्ट करता है: "कैसे / यह / कंप्यूटर वायर्ड है")

@ पोपकोर्नमिक्स
मैं उन्हें विन्यास करने की योजना बना रहा हूं, मेरे पास कल पर्याप्त समय नहीं था। मैं यह भी चाहूंगा कि एक समय में एक से अधिक बसों को बनाने में सक्षम हो। शायद गतिशील तरीके से, जैसे GPIOS export और unexport sysfs फाइलें (लेकिन मुझे यकीन नहीं है कि क्या ऐसी बस को साफ करना संभव है)? ओह, और मुझे एक और pcf8574 मिला और यह पुष्टि कर सकता है कि बाहरी पुलअप प्रतिरोधों का उपयोग करने पर यह विभिन्न GPIO पिनों पर भी अच्छी तरह से काम करता है। दुर्भाग्य से मेरे पास परीक्षण करने के लिए अधिक परिष्कृत I²C उपकरण नहीं हैं। तो क्या आप डिफ़ॉल्ट कर्नेल ट्री में ऐसे मॉड्यूल प्रदान करने में रुचि रखते हैं?

@kadamski
मेरे पास इस तरह के मॉड्यूल का परीक्षण करने के लिए सेटअप नहीं है। हालाँकि, किसी भी हार्डवेयर में चिप प्रदान करता है (जैसे I2C) में कर्नेल ड्राइवर होने चाहिए ताकि अधिक से अधिक लोग उनका उपयोग कर सकें। यदि I2C हार्डवेयर में बग हैं जो कुछ निश्चित बाह्य उपकरणों का उपयोग कर लोगों को रोकेंगे तो एक बिटबैंगिंग वैकल्पिक ध्वनियों को सार्थक करेगा।

इसलिए, यदि आप एक नया ड्राइवर बनाते हैं, जो इसका उपयोग न करने वाले लोगों के लिए हानिरहित दिखता है (यानी एक मॉड्यूल के रूप में बनाया गया है, और लोड होने तक कुछ भी नहीं करता है), और कुछ सबूत हैं (यानी कुछ उपयोगकर्ता रिपोर्ट की पुष्टि करते हुए) यह सही ढंग से काम कर रहा है, तो मैं एक पीआर स्वीकार करने के लिए खुश हूँ।

क्या एचसी को बीसीएम 2837 (आरपी ​​3 में) पर तय किया गया है?

मेरा अनुमान है: नहीं। लेकिन मेरे पास आज इसे परखने का समय नहीं है।

BCM2837 I2C अपरिवर्तित है।

यह दुर्भाग्यपूर्ण है, लेकिन जानकारी के लिए धन्यवाद।

बहुत गुस्सा आता है।

मैं सहमत हूँ। क्या किसी के पास BCM2837 इरेटा, या इसी तरह की एक कड़ी है, जिसमें समस्या अभी भी मौजूद है? जब हम पर समाचार पारित करना होगा, तो यह काम करेगा। या @ P33M , शायद आपको

वह आधिकारिक है, हालांकि ब्रॉडकॉम के लिए काम नहीं करता है।

अच्छी बात है। लेकिन मैं पहले से ही Googled, और P33M के अलावा M33P कहीं और होने के नाते, एक आईडी खोजने के लिए संघर्ष करता हूं जिसे मैं उपयोगी रूप से पास कर सकता हूं। जो ठीक है, लेकिन इसका मतलब है कि वह उद्धरण देने के लिए एक महान स्रोत नहीं है। :-) तो एक इरेटा लिंक काम आएगा।

@ P33M रास्पबेरी पाई के लिए काम करता है। आप वह कह सकते हैं जो वह आधिकारिक कहती है।

मुझे नहीं लगता कि इरेटा सूची है, शायद होनी चाहिए। मैंने उसे छोड़ दिया है
उसकी पहचान की पुष्टि करने के लिए, या नहीं!

15 मार्च 2016 को 14:30 बजे, RalphCorderoy सूचनाएं @github.com ने लिखा:

अच्छी बात है। लेकिन मैं पहले ही Googled हूं, और P33M के अलावा M33P है
कहीं और, एक आईडी खोजने के लिए संघर्ष मैं उपयोगी रूप से पास कर सकता हूं। जो ठीक है,
लेकिन इसका मतलब है कि वह एक महान स्रोत नहीं है। :-) तो एक इरेटा लिंक होगा
काम।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें:
https://github.com/raspberrypi/linux/issues/254#issuecomment -196845789

@ राल्फकॉर्डॉय मैं रास्पबेरी पाई (ट्रेडिंग) लिमिटेड का कर्मचारी हूं। मेरा जवाब आधिकारिक है।

@ P33M , टा, कि करूँगा। परेशानी के लिए क्षमा कीजिए।

यह एक परियोजना को प्रभावित कर रहा है जिस पर मैं काम कर रहा हूं। सौभाग्य से, गुलाम डिवाइस फर्मवेयर पर मेरा पूरा नियंत्रण है और मैं अपनी प्रतिक्रियाओं में एक अतिरिक्त आधे अवधि की देरी (घड़ी का खिंचाव) को जोड़ने के काम के उपयोग को जोड़ने में सक्षम था जो बुरे व्यवहार को छोड़ देता है।

समस्या का अच्छा विश्लेषण advamation.com पर पाया जा सकता है।

ब्रॉडकॉम के I2C कार्यान्वयन में यह खराब हार्डवेयर है या क्या सही तरीके से व्यवहार करने के लिए हार्डवेयर प्राप्त करने के लिए कर्नेल घुमाव संभव हैं?

मैंने अभी इस मुद्दे की सदस्यता ली है क्योंकि मैंने एक उत्पाद के साथ इसका सामना किया है जिसे मैं विकसित कर रहा हूं
जो एक AVR और Pi के बीच i2c का उपयोग करता है। अब मुझे इस पर पुनर्विचार करने की आवश्यकता है।
क्या किसी ने i2c बिट के किसी भी विश्वसनीय रूप का इस्तेमाल किया है?

@ mwilliams03 , आपको इस परियोजना में दिलचस्पी हो सकती है, जिसमें मैंने रास्पबेरी पाई और एक AVR के बीच 100 kHz और 400 kHz I2C संचार को सफलतापूर्वक स्थापित किया है। मैं बिट-बैंगिंग नहीं हूं, बल्कि हार्डवेयर I2C समर्थन का उपयोग कर रहा हूं और प्रमुख बिंदुओं पर देरी सम्मिलित कर रहा हूं। यह पता चला कि AVR इतना धीमा है कि 400 kHz पर किसी भी अतिरिक्त देरी की आवश्यकता नहीं है।

विशेष रूप से, यहां I2C मुद्दों के बारे में जानकारी है । यह भी ध्यान दें कि AVR के TWI मॉड्यूल में त्वरित रीडिंग को रोकने वाला मुद्दा है ।

धन्यवाद @ pdg137 , मैंने इसे आज़माया और पहली बार में मुझे बिना किसी त्रुटि के 1.2 मिलियन

@rewolff ऐसा लगता है कि इस मुद्दे को हल कर दिया गया है। अगर ऐसा है, तो कृपया इस मुद्दे को बंद करें।

और अब .... एक स्तरीय शिफ्टर और 40 सेमी विस्तार केबल जोड़ें .. क्या यह तब काम करता है? संभावना है कि यह तरंगों के "अप" पक्ष पर पर्याप्त देरी का कारण बनता है, और अचानक, बग फिर से हमला करता है।

जहां तक ​​मैं बता सकता हूं, ब्रॉडकॉम और कर्मचारी अभी भी सोचते हैं कि यह बग एक बाइट के अंतिम बिट के बाद FIRST 5 माइक्रोसेकंड (वास्तव में आधा घड़ी) तक सीमित है। तब सिर्फ 10 माइक्रोसेकंड जोड़ने से दो आधा घड़ियां आगे बढ़ेंगी और कोई समस्या नहीं होनी चाहिए। मेरे परीक्षण में, मुझे हर 5 माइक्रोसेकंड को फैलाने वाली घड़ी को रोकने के लिए "बुरे" क्षण मिलते हैं।

SPI और I2C के बीच समरूपता के कारण यह मेरे AVR कोड में आसान होता है यदि अगले डेटाबेट को "अगले डेटा" इंटरप्ट में "गणना" किया जाता है .... (मैं एक इंटरफ़ेस को उजागर करता हूं जहां पढ़ना जारी रखना अनुमत है, इसलिए 16 बाइट बफर है हमेशा पर्याप्त नहीं है।)

मैं आश्वस्त नहीं हूं।

मैं एक रिस्पबेरी पाई और एक ATMEGA 324PA के बीच SMBus के साथ मुद्दों का सामना कर रहा हूं - क्या ये इस मुद्दे से संबंधित हो सकते हैं? https://stackoverflow.com/questions/39274784/talking-smbus-between-raspberr-pi-and-atmega-324pa-avr-not-clock-stretching

जहां तक ​​मैं बता सकता हूं, ब्रॉडकॉम और कर्मचारी अभी भी सोचते हैं कि यह बग एक बाइट के अंतिम बिट के बाद FIRST 5 माइक्रोसेकंड (वास्तव में आधा घड़ी) तक सीमित है।

@ क्रूलेफ : मुझे ब्रॉडकॉम के कर्मचारियों से सहमत होना होगा। मेरे परीक्षणों में, रास्पबेरी पाई 3 और 100 kHz I2C (जो सीपीयू के थ्रॉटल होने पर 62 kHz तक धीमा हो जाता है) के साथ, मुझे advamation.com से एनीमेशन के समान परिणाम मिल

एनीमेशन ध्वनि लगता है। हालाँकि यह मेरे अनुभव के अनुरूप नहीं है। शायद मुझे एक परीक्षण स्थापित करना चाहिए। कुछ समय लग सकता है। यह अन्य सामान के साथ व्यस्त है।

लेकिन अगर ऐसा होता, तो बस मेरी रुकावट की दिनचर्या (हार्डवेयर क्लॉक स्ट्रेचिंग) में एक "usleep (10)" सामान्य रूप से चाल चली जाती और चीजें लॉक नहीं होतीं। मुझे पूरा यकीन है कि ऐसा नहीं था। : --(

@rewolff : रास्पबेरी पाई 3 पर, मैंने सीपीयू को 600 मेगाहर्ट्ज पर थ्रोटल होते देखा है, जिसके परिणामस्वरूप 62 kHz की डिफ़ॉल्ट I2C गति है। तो आप अपने गुलाम के ISR में 17 माइक्रोसेकंड के लिए सो जाना चाहिए अगर ISR SCL के गिरने के किनारे पर शुरू होता है। या अगर आपको लगता है कि सीपीयू 600 मेगाहर्ट्ज से नीचे गिर सकता है, तो अधिक समय तक सोएं।

क्या रास्पबेरी पाई कर्नेल में @kadamski का i2c-

यह एक अच्छा वर्कअराउंड होगा जो इस पूरे मामले को प्रभावित करते हुए एचडब्ल्यू बग को संबोधित करता है।

@onnokort i2c-gpio ओवरले का मतलब नवंबर 2015 से वर्तमान गुठली में मौजूद है? 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-para में पाया गया)।

@popcornmix @ 6by9 क्या इसे बंद किया जा सकता है? एक looong समय के आसपास रहा है, और मेरे पढ़ने से डीटीटी परम सामान एक अच्छा विकल्प लगता है।

उन उपकरणों के लिए अनुशंसित वर्कअराउंड जो निश्चित रूप से हमारे I2C हार्डवेयर के साथ अच्छी तरह से नहीं खेलते हैं, i2c-gpio ओवरले का उपयोग करना है, जो बिट्स को पिन करता है।

अन्यथा, पता ACK चरण में स्ट्रेचिंग अपस्ट्रीम चालक द्वारा समर्थित है।

एक और दो सेंट: https://github.com/555kav555/i2c-bcm2835-correct

प्रिय सब, आज मैंने पूर्वी एशिया से GY-955 के पैकेज GY-955 में BNO055 का परीक्षण किया है जो Pi 2B (BMC2835) के साथ 100_000 हर्ट्ज पर बहुत बदसूरत व्यवहार करता है। परीक्षणों के लिए, मैंने I2C बस की आवृत्ति को 50_000 से 400_000 हर्ट्ज में बदल दिया है और मुझे 100_000 हर्ट्ज पर समस्याएं मिली हैं, लेकिन 50_000, 85_000, 115_000 और 125_000 हर्ट्ज के लिए Adafruit (Adafruit_Python_BNO055) कोड I2C कनेक्शन के साथ बहुत अच्छा काम करता है, 150_000 बीएनओ ०५५ के लिए हर्ट्ज बहुत तेज़ लगता है, यह काम करता है लेकिन मान कभी-कभी गलत होते हैं। मैं स्वीकार करता हूं, मैंने एक आस्टसीलस्कप द्वारा आवृत्ति का परीक्षण नहीं किया है, मैंने केवल फ़ाइल / sys / class / i2c-अनुकूलक / i2c-1 / of_node / घड़ी-आवृत्ति को पढ़ा है, इसलिए कुछ अनिश्चितता खुली रह गई है। अब मैं एडीए में BNO055 के लिए एक पूर्ण इंटरफ़ेस लागू करना शुरू करता हूं।
सुविधा: BMC I2C हैंडलिंग में हार्डवेयर बग केवल 100_000 हर्ट्ज पर दिखाई देता है, इसकी पुष्टि की जानी चाहिए।

बस FYI करें, हार्डवेयर बग तब होता है जब दास डिवाइस क्लॉक स्ट्रेचिंग करता है और 0.9 से 0.999 I2C घड़ी अवधि के बाद SCL लाइन जारी करता है। लाइन उठना शुरू हो जाएगी, और पाई हार्डवेयर कहेंगे: ओह, उसने क्लॉक स्ट्रेचिंग नहीं की, इसलिए मैं क्लॉक लाइन को फिर से कम करके अगली क्लॉक पल्स प्रदान कर सकता हूं।

बग तब होता है जब घड़ी की अवधि में शेष समय, राकबेरी के लिए "हाई" थ्रेशोल्ड पास करने के लिए क्लॉक लाइन के लिए पर्याप्त होता है, लेकिन गुलाम उपकरणों के लिए नहीं या जब गुलाम के पास शोर फ़िल्टरिंग होता है और <x% के दौरान उच्च मानता है सामान्य I2C घड़ी चक्र एक गड़बड़।

यह "केवल 100kHz पर नहीं होता है", बल्कि कई अन्य आवृत्तियों पर भी होता है, सिवाय इसके कि दास डिवाइस के प्रतिक्रिया समय के बाद एक अलग मूल्य होना चाहिए।

मान लीजिए कि घड़ी 100kHz है, तो एक सामान्य चक्र 5us उच्च और 5us कम होगा। अब मान लीजिए कि t = 0 पीआई क्लॉक लाइन को कम करके अंतिम घड़ी चक्र शुरू करता है। T = 5us पर pi क्लॉक सिग्नल जारी करता है, लेकिन दास अभी भी व्यस्त है, घड़ी को कम रखता है। T = 9us पर दास किया जाता है और घड़ी संकेत जारी करता है। T = 10us पर pi क्लॉक सिग्नल को देखेगा, और सोचेगा: Ok, कोई क्लॉक स्ट्रेचिंग नहीं है, इसलिए जारी रखें, और यह क्लॉक सिग्नल को फिर से कम खींचता है। घड़ी का संकेत अब केवल 1us (उच्च समाई और पुलअप प्रतिरोधों के समय के कारण थोड़ा कम) के लिए उच्च हो गया है और गुलाम द्वारा नहीं देखा जा सकता है। अब एक अलग उपकरण 9 माइक्रोसेकंड के बाद नहीं बल्कि 10.5 के बाद तैयार हो जाता है। अब 100kHz पर, पीआई देखेंगे "अभी भी कम है, घड़ी की स्ट्रेचिंग, एक और 5 माइक्रोसेकंड की प्रतीक्षा करें। अब हमें 4.5 माइक्रोसेकंड की घड़ी पल्स मिलेगी और चीजें काम करेंगी। लेकिन इस डिवाइस को 90kHz पर चलाएं, और यह परेशानी में पड़ जाता है। अब पीआई शुरू से 11 माइक्रोसेकंड पर दिखेगा, और घड़ी का सिग्नल एक माइक्रोसेकंड से कम के लिए उच्च रहा होगा -> समस्याएं।

जो लोग इस बारे में शिकायत करते हैं, वे अन्य उपकरण नहीं हैं। वे डिफ़ॉल्ट 100kHz पर काम करते हैं। लेकिन बग अभी भी बहुत वास्तविक है और आपके और मेरे पास मौजूद उपकरणों की तुलना में अन्य बस गति पर उन उपकरणों पर होगा।

प्रतिक्रिया के लिए धन्यवाद, यह बहुत अच्छा समझाता है, मेरे द्वारा चुने गए आवृत्तियों पर मुझे विश्वसनीय हस्तांतरण क्यों मिला:
100_000 हर्ट्ज पर समस्याएं 9 से 9.99 सेकेंड की अवधि में बढ़ जाती हैं
85_000 हर्ट्ज पर समस्याएं 1_000_000 / 85_000 * .9 = 10,59 secsec> 9.99 सेकंड पर शुरू होती हैं, इसलिए घड़ी की स्ट्रेचिंग को नजरअंदाज कर दिया जाता है, मुझे लगता है कि सभी आवृत्तियों के लिए तो 85_000 हर्ट्ज की समस्याओं का प्रारंभ बिंदु 10,59 µsec से अधिक है। ।
115_000 हर्ट्ज पर बस चक्र 1_000_000 / 125_000 = 8.7 µsec <9 clockecec है, इसलिए घड़ी की स्ट्रेचिंग को सही ढंग से पता लगाया जाता है, 115_000 हर्ट्ज से अधिक सभी आवृत्तियों के लिए बस चक्र कम है तो 8.7 µsec।
इसलिए जब मुझे कोई समस्या होती है तो मुझे उस आवृति की गणना कर सकते हैं जिसकी मुझे आवश्यकता है।
(मैंने http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html पर जानकारी पढ़ी)
नोट किया गया था। एक अवधि के .9 के बजाय .5)।

कुंआ। यह इस बात पर निर्भर करता है कि आपका दास वैध घड़ी संकेत के रूप में क्या पता लगाता है। और आपके बस में आरसी कितना विलंब करता है। मेरे मामले में, AVR I एक गुलाम के रूप में उपयोग करता है, दो घड़ी चक्र से कम दालों को एक गड़बड़ मानता है। 8MHz (+/- 10% !!!) की आंतरिक आरसी घड़ी के साथ, पल्स का पता लगाने के लिए कम से कम 250ns होना चाहिए। I2C विनिर्देशों के लिए 5 माइक्रोसेकंड की आवश्यकता होती है, इसलिए आधिकारिक तौर पर आवश्यक और अब काम नहीं करने वाले के बीच 20 "मार्जिन" का एक कारक है।

पहले मैंने सोचा था कि मैं अपने दास में घड़ी का खिंचाव बढ़ाऊंगा 12us कहने के लिए थोड़ा सा पैदा करता है। यह तब तक काम करता है जब तक कि बस कैपेसिटेंस फिर से एक समस्या पैदा करने के लिए पर्याप्त देरी जोड़ता है। इसलिए आसपास काम करना बहुत मुश्किल है। अपने ग्राहकों को मानक 100kHz i2c का उपयोग नहीं करने के लिए बताने के लिए कष्टप्रद।

क्षमा करें, लेकिन मुझे पूर्ण कार्यान्वयन और परीक्षण परिदृश्य लिखने के लिए कुछ समय चाहिए था।
आपने मुझे जो भी जानकारी दी, उसके लिए मैं आपको धन्यवाद देता हूं, यह बहुत मददगार था।
मेरा परीक्षण परिदृश्य GY-055 के रूप में पैक किए गए 2 MEMS (BNO055, MPU9255 MPU-9250/6500 के रूप में पैक किया गया है, WHO_AM_I रजिस्टर MPU9255 कहता है) और 1 GPIO एक्सटेंडर PCF 8574 (पैकेज्ड PCF 8574)।
Pi (2b) पर I2C घड़ी को 125 kHz पर सेट किया गया था, जिसे पढ़ने / sys / class / i2c-adapter / i2c-1 / of_node / clock-frequency द्वारा सत्यापित किया गया था।
मेरा कोड एमईएमएस से 100 बार रीडिंग डेटा और 0.1 सेकंड की देरी के साथ पीसीएफ के लिए डेटा लिखता है।
परिणाम:

• एमईएमएस का प्रारंभिक सफल रहा।
• I2C बस पर एमईएमएस डेटा से पढ़ना सभी चक्रों पर सफल रहा।
• I2C बस के ऊपर PCF को डेटा लिखना सभी चक्रों में सफल रहा।

इसलिए एमईएमएस और पीसीएफ एक घड़ी उच्च मानक 100 kHz स्वीकार करते हैं।
एवीआर के सांप्रदायिककरण को एक बड़े वातावरण में सीरियल लाइन के माध्यम से किया जाता है, मेरे दूसरे एक में संचार यूएसबी पर किया जाएगा, लेकिन यह समाप्त नहीं हुआ है, वास्तविक मैं बीएनओ 05 द्वारा आई 2 सी बस की समस्याओं के कारण ट्रिप किया गया है, लेकिन मुझे लगता है कि अपने वातावरण के लिए मुझे एक पाई 2 बी के लिए वर्कअराउंड मिला और मुझे उम्मीद है कि यह एक पाई 3 के साथ भी काम करेगा, यह अगली परीक्षा है। और फिर मुझे 2 अन्य MEMS, 1 VL53L0X और 1 BME280 को एकीकृत करना है, मुझे उम्मीद है कि यह नए आवृति के साथ काम करेगा और बस समाई इन सभी तत्वों को स्वीकार करता है।

मैं इस मुद्दे के साथ अब आरपीआई 3 मॉडल बी + पर खेल रहा हूं, और मैं एडवांस लेख के वर्णन के मुकाबले अलग परिणाम देख रहा हूं। सिलिकॉन हाल ही में संशोधित नहीं किया गया था, यह था?

लघु संस्करण है, अगर मैं रीड-प्रीएक, राइट-प्रेक, या राइट-पोस्टबैक पर खिंचाव करता हूं तो चीजें काम करने लगती हैं; एकमात्र समय जब मुझे लंबे समय तक या निश्चित रूप से स्ट्रेच करने के लिए सुनिश्चित किया जाना चाहिए, सब पढ़ने-पोस्टबैक है। हालांकि मुझे कुछ भी कहने से पहले मुझे अपने प्रयोग को साफ करने की आवश्यकता है।

सबसे पहले, शब्दावली के बारे में एक नोट। उन्नति लेख कहता है:

तो, रास्पबेरी पाई के साथ I2C अगर केवल काम करता है
दास घड़ी-स्ट्रेचिंग का उपयोग बिल्कुल नहीं करता है, या
गुलाम केवल I2C-read-ACK- चरण (ACK / NACK पढ़ने के बाद) के अंत में / सीधे घड़ी को स्ट्रेच करता है, लेकिन फिर 0.5 से अधिक घड़ी अवधियों द्वारा।

शब्द "I2C-read-ACK- चरण" कुछ अस्पष्ट लगता है। यदि यह एक I2C रीड कमांड है (यानी, पोस्ट-एड्रेस R / W is बिट सेट है), तो गुलाम A writingC theK̅ बिट लिख रहा होगा, इसे नहीं पढ़ना, पेरेंटेटिकल के विपरीत। जब मैं यहां "रीड-पोस्टबैक" कहता हूं, तो मेरा मतलब है कि पता के बाद आर / डब्ल्यू was बिट सही तरीके से सेट किया गया था (और संभवतः एसएमबीस जैसे प्रोटोकॉल द्वारा नहीं बदला गया है), इसलिए गुलाम ने सिर्फ इसकी ए̅सी̅के। प्रतिक्रिया लिखी है।

जैसा कि इधर-उधर संकेत किया गया है, ऐसा लगता है कि अगर आरपीआई को लगता है कि SCL एक गुलाम द्वारा कम आयोजित किया जा रहा है, तो यह एक आधा चक्र (5μS) द्वारा अपनी आंतरिक SCL घड़ी में देरी करेगा। बग को ट्रिगर किया जाता है यदि गुलाम _LAST_ एक आधे चक्र के लिए SCL को कम रखता है। यदि ऐसा होता है, तो आरपीआई अभी भी एससीएल को उच्च होने देगा, और फिर इसके बाद तुरंत इसे नीचे खींच देगा जब इसकी एससीएल घड़ी ट्रिगर हो जाएगी। इसका परिणाम एक रन क्लॉक पल्स में होता है, जिसे कुछ डिवाइस पल्स के रूप में देख सकते हैं जबकि अन्य नहीं। (संदर्भ के लिए: I2C कल्पना का अर्थ है 5μS का नाममात्र SCL उच्च समय, और 100kHz पर 4.0μS का न्यूनतम समय स्थापित करता है, जो RPi के I2C इंटरफ़ेस की डिफ़ॉल्ट गति है।)

मेरे प्रयोगों में, रीड-प्रीएक, राइट-प्रीएक और राइट-पोस्ट बैक चरणों में, आरपीआई सुनिश्चित करेगा कि अधिकतम एससीएल उच्च समय यह अनुमति देगा 4μS या तो। यह उन चरणों में अपनी SCL घड़ी को पीछे धकेलने को तैयार लग रहा था। मुझे संदेह है कि आरपीआई ने इसे जारी करने के तुरंत बाद एससीएल लाइन का नमूना लिया, और अगर एससीएल अभी भी कम था, तो इसने एससीएल घड़ी को आधे चरण में वापस धकेल दिया।

हालाँकि, रीड-पोस्टबैक चरण में, मैंने देखा कि आरपीआई रन क्लॉक (<4μS, अक्सर 2μS या उससे कम) का उत्सर्जन करेगा यदि SCL लाइन लगभग 6-9μS के लिए कम रखी गई थी। मुझे संदेह है कि इस चरण में, ब्रॉडकॉम इंजीनियर एक अलग रास्ते का अनुसरण करते हैं जो इस बात की संभावना कम कर देता है कि उन्हें उच्च-कैपेसिटी लाइन पर आधे चरण में देरी करनी पड़ेगी। अफसोस की बात है - जैसा कि हमने देखा है - यह कम पड़ता है।

इसलिए, मेरे वर्तमान कोड को पढ़ने के बाद के चरण में beyond चक्र से परे SCL को फैलाने की जरूरत है जो कि कुछ समय ले सकता है (जैसे एडीसी रूपांतरण)। अगर मैं असफल रहा

वर्तमान परीक्षण जो मैं चला रहा हूं, एक PIC16F1619 एक गुलाम डिवाइस के रूप में उपयोग कर रहा हूं। गुलाम डिवाइस घड़ी को पढ़ने और लिखने के लिए कमांड का उपयोग करता है। इस लूप प्लस ओवरहेड की लंबाई 0.35μS वेतन वृद्धि में 3μS (आरपीआई SCL कम समय) से 90μS तक भिन्न होती है। मेरे पास आरपीआई पर एक पायथन कार्यक्रम है जो दो रजिस्टरों को अलग-अलग मान देगा, फिर उन्हें वापस पढ़ें, और यह पढ़ें कि बैक-रीड मान सही हैं। उपयोग किए जा रहे मूल्य

पिकन,
ब्रॉडकॉम ने घोषणा करते हुए कहा है कि यह समस्या केवल पहले घड़ी के खिंचाव पर होती है। मुझे नहीं लगता कि यह मामला है। आपको इसे सत्यापित करने में सक्षम होना चाहिए। उन्नति ब्रॉडकॉम मूर्तियों का अनुसरण करती हुई प्रतीत होती है।

@rewolff खैर, उनकी व्याख्या के लिए कुछ हो सकता है। यदि, "पहली घड़ी के खिंचाव" से उनका मतलब है कि "किसी दिए गए चरण में पहली बार है कि SCL एक से अधिक घड़ी अनुवाद द्वारा फैलाया गया है" तो उनका वर्णन सटीक है: यदि आप एक से अधिक घड़ी चक्र द्वारा खिंचाव करते हैं, तो हाँ: सभी में चरण, यदि आप> .5 चक्र तक फैलते हैं, तो आप अच्छे आकार में हैं। कम से कम, अस्पष्ट प्रयोगों में मैंने अब तक किया है; अधिक सटीक प्रयोग अभी बाकी हैं।

जब आरपीआई का I2C घड़ी स्ट्रेच को संभाल नहीं सकता है, और रिप्रोज प्राप्त कर सकता है, जो कि बीसीएम इंजीनियरों को भेज सकता है, प्रदर्शित करने के लिए कुछ बेहतर प्रयोग करने में मुझे खुशी है।

अफसोस की बात यह है कि इस मुद्दे को ठीक करने के लिए एक बहुत महत्वपूर्ण सिलिकॉन रिव्यू की आवश्यकता होगी; जब SCL कम (आंतरिक या बाहरी स्रोत द्वारा) आयोजित किया जाता है, तो उन्हें SCL विभक्त घड़ी पर टिक नहीं करना चाहिए। संभवतः सिलिकॉन-स्तर के बदलाव की आवश्यकता है, जो महंगा है; अधिकांश ईसीओ धातु-स्तर के होते हैं, जो कि ... अच्छा है, सस्ता नहीं है, लेकिन सिलिकॉन की तुलना में सस्ता है।

मेरा मुख्य लक्ष्य कुछ प्रायोगिक साक्ष्यों के साथ आरपीआई के साथ काम करने वाले दासों के प्रकारों को चिह्नित करना है।

ऐसा लगता है कि हमें अधिक ठोस डेटा की आवश्यकता है, जैसे कि रेप्रो परिदृश्य, ब्रॉडकॉम को I2C नियंत्रक को फिर से इंजीनियर करने के लिए मनाने के लिए। ठोस आंकड़ों के साथ भी, इंजीनियरों को प्रबंधन को यह समझाना होगा कि यह अगले संशोधन के लिए संशोधित सिलिकॉन के लायक है।

उस ने कहा, मैं प्रतिलिपि प्रस्तुत करने योग्य परिदृश्यों को डिजाइन करने में कुछ समय लगाऊंगा ताकि बीसीएम इंजीनियर समस्या को स्पष्ट रूप से देख सकें और परख सकें। हालांकि, ब्रॉडकॉम को अपने निष्कर्षों को बताने के लिए मैं समुदाय के सदस्यों पर निर्भर हूं; मेरे पास उनका चैनल नहीं है।

मुझे समुदाय के लिए अपनी पिछली टिप्पणी के बारे में कुछ स्पष्ट करना चाहिए, सिलिकॉन बनाम धातु परिवर्तन के बारे में।

आप जानते हैं कि, यदि आपको स्पार्कफुन या एडफ्रूट से एक बोर्ड मिलता है, तो अक्सर यह पता चलता है कि आप अपने व्यवहार को बदलने के लिए एक साथ कटौती या मिलाप कर सकते हैं? अधिकांश I2C बोर्डों में निशान होते हैं जिन्हें आप पता बदलने के लिए बदल सकते हैं, पुल-अप प्रतिरोधों को सक्षम या अक्षम कर सकते हैं, आदि।

माइक्रोचिप डिजाइनर भी यही काम करते हैं। माइक्रोचिप की धातु परतों पर वे बहुत सारे बदलाव कर सकते हैं, ताकि उन्हें सिलिकॉन परतों को बदलना न पड़े। ऐसा इसलिए है क्योंकि सिलिकॉन परतों को बदलना कठिन और महंगा है (जैसे कि बोर्ड पर चिप को बदलना), जबकि धातु की परतों को बदलना बहुत आसान है (जैसे बोर्ड पर निशान बदलना)।

धातु की परतों में कई उपयोगी बदलाव किए जा सकते हैं, क्योंकि डिजाइनर आगे सोचते हैं और धातु कनेक्शन (जंपर्स, अनिवार्य रूप से) बनाते हैं जो एक चिप के व्यवहार को बदलते हैं।

लेकिन अगर वहाँ एक बदलाव है जिसकी उन्होंने योजना नहीं बनाई है, और यह पता नहीं लगा सकते हैं कि चिप के भीतर निशान को फिर से कैसे बनाया जाए, तो उन्हें सिलिकॉन बदलना होगा। सिलिकॉन को बहुत अधिक योजना, सत्यापन और मास्किंग की आवश्यकता है, इसलिए इसे बदलना मुश्किल है।

कई कंपनियों, अगर उनके पास एक सिलिकॉन परत है, जो "काफी अच्छा" है, तो इसे यथासंभव लंबे समय तक उपयोग करेंगे। वे चिप के कई संशोधनों में सिलिकॉन परत के कुछ हिस्सों का पुन: उपयोग करेंगे।

मुझे संदेह है कि बीसीएम कहां है: उन्हें अच्छे सबूतों की जरूरत है कि यह बग ड्राइवर या धातु में तय नहीं किया जा सकता है इससे पहले कि वे खरोंच से सिलिकॉन परत के इस हिस्से को फिर से इंजीनियरिंग कर सकें।

यह बहुत कम संभावना नहीं है कि इस मुद्दे को ठीक करने के लिए एक्सिसिटिंग सिलिकॉन का एक रिस्पांस होगा (एक अतिरिक्त $ 1M?)। भविष्य के चिप्स में एक सुधार हो सकता है, हालांकि कौन जानता है।

ऑन बुध, सितम्बर 05, 2018 को 02:13:19 पूर्वाह्न -0700, जोएल रे होलवेक ने लिखा:

ऐसा लगता है कि हमें अधिक ठोस डेटा की आवश्यकता है, जैसे कि रिप्रो परिदृश्य, को
I2C नियंत्रक को फिर से इंजीनियर करने के लिए ब्रॉडकॉम को मनाओ। भी साथ
ठोस डेटा, इंजीनियरों को प्रबंधन को समझाना होगा
यह अगले संशोधन के लिए सिलिकॉन को संशोधित करने के लायक है।

उनके पास पहले से ही छह साल और 3 सिलिकॉन संशोधन हैं जहां वे
अपने निर्णय का प्रदर्शन किया है: "ठीक नहीं होगा"।

यदि आप> .5 चक्र तक बढ़ते हैं, तो आप ~ अच्छे आकार में हैं।

मुझे ऐसा नहीं लगता है। हर बार जब आप CLK को "इससे पहले" जारी करते हैं
ब्रॉडकॉम फिर से दिखता है "समय अवधि, आपको छोटी दालें मिलती हैं। मैं आसानी से प्राप्त कर सकता हूं।"
5 बेकार microseconds द्वारा घड़ी संकेत की रिहाई में देरी
हमेशा 0.5 चक्र से बाहर रहें। लेकिन वह काम नहीं आया।

ऑन बुध, सितम्बर 05, 2018 को 02:28:53 पूर्वाह्न -0700, जेम्स ह्यूजेस ने लिखा:

यह बहुत कम संभावना है कि वहाँ की एक सांस की जाएगी
इस मुद्दे को ठीक करने के लिए सिलिकॉन को बाहर करना (एक अतिरिक्त $ 1M?) मिला। भविष्य
चिप्स में हालांकि सुधार हो सकता है।

मुझे शक है। हम BCM2835 के साथ BCOWN28 से BCM2836 से गए
BCM2837 के लिए एक ही बग BCM2837B0 के लिए सटीक एक ही बग के साथ।

अब आपको क्यों लगता है कि अगला संशोधन अलग होगा?

बीसीएम में एक लक्ष्य बाजार है: इन चिप्स के लिए फोन और टीवी-स्टिक्स। में
उनका लक्ष्य बाजार कोई भी सामान्य उद्देश्य पर सॉफ्टवेयर-I2C नहीं कर रहा है
AVRs और PICs जैसे माइक्रोकंट्रोलर। वे इसे ठीक करने नहीं जा रहे हैं।

यह शर्म की बात है कि इस खोजी प्रयास की आवश्यकता है, हालांकि यह बहुत अच्छा है। जब मैंने एक इरेटा के लिए कहा जो इसे कवर करता है तो यह सोचा गया था कि कोई नहीं था। क्या अब बदल गया है और एक यूआरएल है? आदर्श रूप से, ब्रॉडकॉम गलती का सही वर्णन करके समुदाय की मदद करेगा और जब ऐसा होता है तो संगत घटकों के वर्कअराउंड या मूल्यांकन से आत्मविश्वास के साथ काम करना आसान होगा। यहां तक ​​कि प्रासंगिक एचडीएल के स्निपेट की सीमा तक यदि वे विवरण में सटीक रूप से अनुवाद करने का प्रयास नहीं करना चाहते हैं।

घड़ी की स्ट्रेचिंग की अनुमति देते समय आधा-बिट-घड़ी-विभाजक को रोकने का सुझाव एक अच्छा है। यह काम करेगा।

इसके साथ समस्या यह है कि I2C मॉड्यूल का वह हिस्सा फिर "पूर्ण घड़ी की गति" पर चलने की आवश्यकता होगी। अब I2C मॉड्यूल एक अच्छा कम-शक्ति वाला है क्योंकि यह सामान्य रूप से 200kHz से अधिक नहीं चलता है।

मेरे पोस्ट का मुख्य कारण यह था कि मैंने अपने मूल पोस्ट की शुरुआत में क्या कहा था:

मैं इस मुद्दे के साथ अब आरपीआई 3 मॉडल बी + पर खेल रहा हूं, और मैं एडवांस लेख के वर्णन के मुकाबले अलग परिणाम देख रहा हूं। सिलिकॉन हाल ही में संशोधित नहीं किया गया था, यह था?

अगर हम 2013 के एडवांस राइटअप के बाद I2C हार्डवेयर या ड्राइवर में महत्वपूर्ण परिवर्तन हुए हैं , और समुदाय को पता है कि वे इस बग को कैसे प्रभावित कर सकते हैं, तो मुझे अपने प्रयोगों में उचित बदलाव करना चाहिए।

मुझे पता है कि मूलभूत समस्या हार्डवेयर में है, लेकिन सभी के लिए मुझे पता है, किसी ने प्रयोग द्वारा पाया हो सकता है कि ड्राइवर में एक उचित-असंबंधित रजिस्टर को बदलना वास्तव में इस बग के व्यवहार को बदल देता है। मैंने यह भी पुष्टि नहीं की है कि BCM2837 में RP2 2 के समान ही I2C मॉड्यूल है (सबसे हाल ही में मुझे निश्चित पुष्टि मिल सकती है कि I2C हार्डवेयर अपरिवर्तित था क्योंकि यह समस्या पहले बताई गई थी)। मुझे बीसीएम 283 एक्स स्टेपिंग में से किसी के बारे में कोई जानकारी नहीं मिली है; सभी मुझे पता है, BCM2836 के युग में धातु परिवर्तन हो सकता था।

मुझे ब्रॉडकॉम को कोसने में कोई दिलचस्पी नहीं है, यह अनुमान लगाते हुए कि वे भविष्य के संशोधन, या ऐसा कुछ भी कैसे बदल सकते हैं।

यहां मेरा प्राथमिक लक्ष्य वर्तमान व्यवहार को स्पष्ट रूप से दस्तावेज करना है; ऐसा लगता है कि यह समय के साथ बदल गया है। मेरे पास भविष्य के उपयोगकर्ताओं को मेरे प्रयोगों को फिर से देखने की अनुमति देने के लिए एक माध्यमिक लक्ष्य है कि क्या परिणाम अभी भी मान्य हैं, या अन्य स्थितियों में सुधार या परीक्षण करना है। मेरे पास एक और माध्यमिक लक्ष्य है कि वे ब्रॉडकॉम इंजीनियरों को आसानी से यदि वे चाहें तो परीक्षणों को पुन: पेश करने की अनुमति दें। इन दोनों का मतलब है कि मुझे अपने प्रयोगों को प्रकाशित करने की आवश्यकता है, जो भी मदद करता है: अपने स्वयं के पति के कारण , यदि मैं अपने प्रयोगों को प्रकाशित कर रहा हूं, तो मैं उन्हें कठोर बनाने के लिए अधिक प्रेरित होऊंगा।

मेरी वर्तमान प्रायोगिक योजना गुलाम कार्यान्वयन के रूप में PIC16F1619 का उपयोग करना है; यह तेजी से और बहुमुखी है कि स्ट्रेचिंग प्रयोगों को करना आसान है, साथ काम करने के लिए पर्याप्त आसान है, और यह पर्याप्त है कि अन्य प्रयोगकर्ता मेरे परिणामों को पुन: पेश कर सकें। यदि परिणाम अस्पष्ट हैं, तो मैं एक FPGA के साथ एक प्रयोग भी कर सकता हूं। मैं देख सकता हूं कि क्या मैं गुलाम के रूप में एक बिट-बशिंग कॉन्फ़िगरेशन में एक और रास्पबेरी पाई का उपयोग करके उचित ग्रैन्युलैरिटी प्राप्त कर सकता हूं, लेकिन मुझे संदेह है कि मुझे वास्तविक समय परीक्षण करने के लिए पूरे ओएस के बिना कुछ की आवश्यकता होगी।

कुछ और बातें सामने आईं:

क्षमा करें कि मेरा मूल पद अधूरा था; मैंने गलती से एक शुरुआती ड्राफ्ट पोस्ट कर दिया था। मैं इसे छोड़ दूंगा, क्योंकि मैंने जो बदलाव किए हैं वे बहुत मामूली हैं।

मैं घड़ी के विभाजन को रोकने के विचार पर मौलिकता का दावा नहीं करता, जबकि SCL को बाहरी रूप से कम रखा गया था। मैंने पढ़ा है कि कहीं और, लेकिन याद नहीं है कि कहां; मुझे लगा कि यह I2C घड़ी में Gasp van Loo से

I2C HW ब्लॉक को ठीक नहीं किया गया है / बदल दिया गया है, और bcm2835 / 6/7 में होने की संभावना नहीं है, क्योंकि इसके लिए चिप के रिस्पॉन्स की आवश्यकता होगी जो कि बस बहुत महंगा है।

मुझे नहीं पता कि एडवांटेज कौन हैं, लेकिन वे आरपीएफ (टी) समूह के लिए अवास्तविक हैं, इसलिए मैं लेख की सटीकता की गारंटी नहीं दे सकता।

प्रिय सब, मुझे अपने पीआई 2 बी और 3 पर बहुत अजीब फेनोमेनन मिला, मैं समझाने की कोशिश करता हूं:
जब मैंने जून के अंत में BNO055 को लागू करना शुरू किया, तो मैंने एक बड़े रास्पियन (अब संस्करण नहीं है) का उपयोग किया और मुझे i2cdetect का उपयोग करके बहुत सारे अमान्य I2C पते मिले। उसके लिए मैंने नेट में देखा और मुझे यह मंच अच्छे से मिला। उसके लिए मैंने ऊपर वर्णित I2C बारंबारता को बदल दिया और सभी भूत गायब हो गए और मैं काम कर सकता हूं। अगस्त के मध्य में मैंने रासबीयन को बधाई दी कि मुझे लगता है कि रास्पबी-देव 4.14.62-v7 + और सिस्टम थोड़ा अस्थिर हो गया था, लेकिन मैं काम कर सकता हूं। अद्यतन से अद्यतन करने के लिए सिस्टम अधिक अस्थिर हो गया, एसडी कार्ड पर विख्यात लीक। इसलिए मैंने NOOBS (Linux raspbi-dev 4.14.62-v7 + # 1134 SMP Tue 14 14 17:10:10 BST 2018 armv7l) के माध्यम से रास्पियन को फिर से स्थापित किया और मैं I2C की आवृत्ति सेट करना भूल गया लेकिन कोई भूत दिखाई नहीं दिया। ठीक है, मैं बस पर केवल MEMS और GPIO एक्सटेंडर में माइक्रोकंट्रोलर का उपयोग नहीं करता हूं, लेकिन मुझे लगता है कि रास्पियन के i2c कोड में वर्कअराउंड है। इसके अलावा, मुझे लगता है कि पता चला लीक एक अपूर्ण उन्नयन से आया था, मैं उसी कार्ड का उपयोग कर रहा हूं और कोई लीक का पता नहीं चला है।

@ hmf2015 यह समस्या एक बहुत ही विशिष्ट I2C समस्या के बारे में है। एसडी कार्ड के साथ समस्याएं I2C की इस समस्या के कारण नहीं हैं। यदि आपका एसडी कार्ड सही काम नहीं कर रहा है, तो आपको एक नया एसडी कार्ड आज़माना चाहिए। कुछ कार्ड अच्छे नहीं हैं, और जल्दी से काम करना बंद कर देते हैं। मेरे एसडी कार्ड ने पिछले महीने काम करना बंद कर दिया, और मुझे इसे बदलना पड़ा।

आमतौर पर, I2C भूत इस समस्या के कारण नहीं हैं। वे सबसे अधिक बार होते हैं क्योंकि:

• आपके पास अच्छी बिजली की आपूर्ति नहीं है। मुझे यह पसंद है।
• आपके केबल बहुत लंबे हैं। I2C 1 मी से अधिक लंबे केबल के साथ अच्छी तरह से काम नहीं करता है।
• आपके केबल में कैपेसिटिव कपलिंग होती है। यदि आपके पास I2C पिन (एससीएल और एसडीए) एक साथ मुड़ हैं, तो यह एक समस्या बना सकता है। कभी-कभी, लोग मुड़-जोड़ी केबल (ईथरनेट केबल की तरह) का उपयोग करते हैं जो I2C पिन को घुमाते हैं, और इससे समस्याएँ होती हैं। यदि आपको मुड़-जोड़ी केबल का उपयोग करना है, तो एससीएल को वीडी (ग्राउंड) और एसडीए के साथ वीडी (3.3 वी) के साथ मोड़ दें। खंड 7.5 में I2C युक्ति को देखें।
• आपके I2C डिवाइस में 5V है। रास्पबेरी पाई 3.3V पर I / O करता है। यदि वोल्टेज अलग हैं, तो यह समस्या पैदा कर सकता है। (BNO055 को 3.3V की आवश्यकता है, इसलिए यदि आप इसे 5V के साथ उपयोग कर रहे हैं, तो आपको समस्या है।)

मैंने कहा कि हम एक विशेष समस्या के बारे में बात कर रहे हैं। कुछ डिवाइस इस समस्या के कारण भूत बन सकते हैं, लेकिन कई डिवाइस नहीं। यदि डिवाइस इस समस्या के कारण भूत बनाते हैं, तो वे कई भूत नहीं बनाते हैं। मुझे लगता है कि आपकी समस्या अलग है।

मुझे नहीं पता कि आपके कहने का क्या मतलब है जब आप कहते हैं कि "एसडी कार्ड पर लीक"। यह एक महत्वपूर्ण समस्या है, लेकिन यह कोई समस्या नहीं है कि हम इस वेब पेज के मुद्दे पर बात करें। यह बातचीत एक विशेष बग के बारे में है। वह बग SD कार्ड को प्रभावित नहीं करता है।

मुझे नहीं लगता है कि हाल ही में रास्पियन ने I2C कैसे काम करता है, इसे बदल दिया। हमें लगता है कि रास्पियन इस बग को ठीक नहीं कर सकते। हम गलत हो सकते हैं। इस बारे में हमें बताने के लिए धन्यवाद।

यदि आप केवल हमारी मदद करने के लिए हमें यह जानकारी बता रहे हैं, तो हम आपको धन्यवाद देते हैं। यदि आप हमसे सहायता मांगने के लिए यह जानकारी बता रहे हैं, तो आप रास्पबेरी पाई मंचों पर पूछना चाह सकते हैं। फोरम कई चीजों के बारे में बात करते हैं, जैसे I2C, SD कार्ड, GPIO एक्सटेंडर और कई और चीजें। जिन चीजों को आप देख रहे हैं, वही चीजें हो सकती हैं जिनके बारे में हम बात कर रहे हैं, लेकिन वे अलग-अलग चीजें हो सकती हैं। मंचों पर लोग आपको यह जानने में मदद कर सकते हैं कि आपको कौन सी समस्याएं दिखाई दे रही हैं।

यह जानकारी हमें बताने के लिए धन्यवाद!

उत्तर के लिए धन्यवाद, लेकिन sd कार्ड समस्या O / S द्वारा निर्मित की गई थी, मैंने अपने (Unix) होस्ट पर कार्ड की जाँच की, और यह ठीक था, और अब नई स्थापना के बाद वही कैड काम करता है।
I2C बस पर भूत एक उच्च आवृत्ति द्वारा गायब हो जाते हैं और अब पुनर्स्थापना के बाद वे प्रकट नहीं होते हैं, आर / सी समस्याएं और प्रतिबिंब जो मैं कर सकता हूं, मुझे लगता है, बाहर। मैं 3.3V समस्याओं को जानता हूं, लेकिन न्यूनतम 1 स्तर कम है।
BNO055 पैकेज में एक वोल्टेज रेगुलेटर है।
मैंने यह भी सोचा था कि I2C की समस्याएं पहले की तरह ही होंगी, लेकिन ऐसा नहीं है, इस समय मेरे पास समय (और ब्याज) नहीं है कि अंतर का पता लगाने के लिए रास्पियन के स्रोत कोड को देखें, मुझे दिलचस्पी है काम के माहौल पर।
तत्वों की सूची केवल यह दिखाना चाहिए, कि मैं बीसीएम के समर्थन के रूप में एन्डॉइड वातावरण (एक वास्तविक यूनिक्स के साथ) में काम कर रहा हूं, न कि माइक्रोकंट्रोलर के साथ, जो मैं आलसी होने के बाद से सीरियल लाइन या यूएसबी के माध्यम से संलग्न करता हूं। आपके वातावरण में स्थितियाँ मेरी तुलना में अधिक प्रतिबंधित हैं, इसलिए मैं यह नहीं कह सकता कि क्या आपकी समस्याएं कम हो जाती हैं, लेकिन मुझे उम्मीद है।

हाय hmf2015,
यह कोई फोरम नहीं है। यह एक बग ट्रैकर है। इस सूची-टिप्पणियों में एक बग की चर्चा की गई है जो आपकी समस्याओं से संबंधित नहीं है। कृपया एक उपयुक्त मंच या हेल्पडेस्क के साथ अपनी समस्या पर चर्चा करें। फिर से, हम आपके प्रश्न की सराहना करते हैं: "शायद यह वही है? शायद मेरा विवरण उस बग को हल करने में मदद करता है?" लेकिन अब हम यह सुनिश्चित करने के लिए जानते हैं कि जो आप देख रहे हैं वह असंबंधित है, कृपया इस चर्चा को आगे "प्रदूषित" न करें।

@ पोपकोर्नमिक्स
नमस्ते, बहुत समय पहले आपने पुनरारंभ के दौरान I2C राज्य मशीन के साथ एक समस्या का उल्लेख किया है और इस मुद्दे के बारे में कुछ कोड पोस्ट किए हैं।
मुझे यकीन नहीं है कि आपका क्या मतलब है लेकिन मेरे पास WM8731 के साथ एक मुद्दा है I2C से जुड़ा कोडेक।
2-3 बार पुनरारंभ होने के बाद I2C बस पूरी तरह से लटक जाती है। i2cdetect 1 लाइन को छोड़कर कोई भी जानकारी नहीं दिखाता है और लटका भी है। ठीक होने का एकमात्र तरीका शक्ति नीचे / ऊपर चक्र है।
क्या यह आपके द्वारा उल्लिखित मुद्दों की तरह दिखता है?
मैं ४.१ ९ मेनिन कर्नेल का उपयोग कर रहा हूं।

@ sergey-suloev जब i2cdetect 8 या 16 पतों के बाद स्कैनिंग जारी नहीं रखता है, तो मैं कहूंगा कि यह इस मुद्दे से संबंधित नहीं है। जब डिवाइस क्लॉक स्ट्रेचिंग करते हैं तो यह इंगित करता है कि वे अगले घड़ी चक्र के लिए तैयार नहीं हैं। जब I2C को लगभग 40 साल पहले डिज़ाइन किया गया था, तो हार्डवेयर कार्यान्वयन के लिए भी यह संभव है। लेकिन आजकल, हार्डवेयर हमेशा अगले घड़ी चक्र को संभालने के लिए समय में तैयार होता है क्योंकि 10 माइक्रोसेकंड हार्डवेयर में लागू किसी चीज के लिए समय का होता है।