I2C EEPROM बिट-बैंगिंग: ठीक लिखता है, लेकिन केवल अगर पहले बिट सेट नहीं है

Question

मैं वर्तमान में एसडीए और एससीएल लाइनों को चलाने के लिए बिट-बैंगिंग का उपयोग करके एक I2C EEPROM परियोजना पर काम कर रहा हूं।

मेरा पढ़ा हुआ फ़ंक्शन ठीक काम करता है लेकिन जब भी मैं किसी अग्रणी "1" के साथ कोई बाइट लिखता हूं, तो मैं हमेशा एफएफ वापस पढ़ता हूं; भले ही बाइट को पहले किसी और चीज के साथ प्रोग्राम किया गया हो। अग्रणी "0" एकदम सही है। यह मेरी पढ़ी हुई दिनचर्या नहीं है; जैसा कि मैं इस दायरे पर देख सकता हूं कि यह एफएफ देता है।

मैं इस बारे में सुझावों की तलाश कर रहा हूं कि ऐसा क्यों हो सकता है। क्या कोई स्पष्ट है जो मुझे याद कर सकता है जो समस्या का कारण बन सकता है? [मैं कोड पोस्ट नहीं कर सकता - कंपनी गोपनीय ... :(]

मैं जिस भी तरंग को देखता हूं, वह बिल्कुल कल्पना से मिलती है। मैं EEPROM को डिकूप कर रहा हूं। कल्पना के भीतर मेरे पुल अप 2.2k हैं। मैं इस प्रोटोटाइप में लगभग 500 हर्ट्ज देख रहा हूं। चिप मेरे प्रत्येक बाइट को ACKs भेज रही है ताकि यह उन्हें पहचान सके। लेकिन यह सिर्फ काम नहीं करता है ...

मैं एक माइक्रोचिप 24LC256 का उपयोग कर रहा हूं ।

एक बाइट के लिए सरलीकृत लेखन एल्गोरिथ्म:

wait
SDA low
SCL low
wait
for each bit
    if bit is set:   SDA high
    if bit is unset: SDA low
    wait
    SCL high
    wait
    wait
    SCL low
    wait
wait
SDA high 
SCL high
wait
wait
check ACK status
SDA low
SCL low
wait
return ACK status

एक बाइट के लिए सरलीकृत रीडिंग एल्गोरिथ्म:

wait
SCL low
SDA high
for each bit (8 bits)
    SCL high
    wait
    wait
    SCL low
    wait
    check and store received bit
    wait
do a NACK or ACK depending on if it is the last byte

Comments

@ जस्टिन - मुझे लगता है कि वह कह रहे हैं कि किसी भी पते पर 0x7F मान लिखने से काम चल जाता है, लेकिन किसी भी पते पर 0x80 लिखना किसी काम का नहीं है।

— रॉकेटमेग्नेट

यह इस तरह से सामान है जो मुझे I2C से नफरत करता है।

— रॉकेटमैग्नेट

मैं एक पागल कुबड़ा मिला है। प्रत्येक बिट कोड के लिए, क्या आप अनजाने में शिफ्ट राइट ऑपरेशन के साथ साइन-एक्सटेंड कर रहे हैं? यदि आप हैं तो आपका प्रमुख व्यक्ति 7 शिफ्ट ऑपरेशन के बाद आपको 0xFF के साथ छोड़ देगा।

— vicatcu

यहाँ विडंबना यह है कि "कंपनी गोपनीय" कोड है। यह उनके लिए मूल्यवान है। हर कोई यहां काम करने वाले कोड साझा करता है। इस कंपनी के कोड को दूसरों से अलग सेट करता है कि यह काम नहीं करता है।

— gbarry

यह कल्पना करना मुश्किल है कि क्यों एक कंपनी को कुछ I2C बिट बैंगिंग कोड को गोपनीय रखने की सख्त आवश्यकता है। इंटरनेट पर इसके आसपास बहुत कुछ है।

— राकेटमग्नेट

Answer 1

आप घड़ी के फिर से कम होने के बाद डेटा पढ़ रहे हैं। आपको यह करना होगा कि घड़ी को ऊंचा बनाने और इसे कम करने के बीच। घड़ी कम होने के बाद दास को डेटा लाइन को बदलने की अनुमति दी जाती है, जबकि यह अधिक नहीं है।

तो पढ़ना इस तरह होना चाहिए:

wait
SCL low
SDA high
for each bit (8 bits)
    SCL high                      <--------
    wait
    check and store received bit  <--------
    wait
    SCL low                       <--------
    wait
    wait
do a NACK or ACK depending on if it is the last byte

Comments

ये एक अच्छा बिंदु है; मैं ठीक कर दूँगा। हालांकि, मेरा डेटा अभी भी मेरे दायरे में सभी (एफएफ) के रूप में दिखाता है, इसलिए मेरे पढ़ने में समस्या नहीं हो सकती ... :(

— थॉमस ओ

Answer 2

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

Comments

खुशी है कि आपने इसे "लेखन समय सत्यापित करें"

मैंने आपसे कहा था कि इस तरंग को देखकर हल किया जाएगा।

— रॉकेटमेग्नेट

@Rocketmagnet मैं हमेशा तरंग को देख रहा हूं, लेकिन पहले कभी इस पर ध्यान नहीं दिया था।

— थॉमस ओ

हां, लेकिन आपने हमें लहर दिखाने के लिए नहीं दिखाया , इसके बावजूद हम बार-बार आपसे इसके लिए पूछ रहे हैं। आप इस समस्या को कुछ दिन पहले हल कर सकते थे।

— राकेटमग्नेट 16

@Rocket - मैं सहमत हूँ। काश मेरे पास उस समय एक कैमरा उपलब्ध होता। मैं जिस टेक डीपीओ का उपयोग कर रहा था उसमें फ्लॉपी ड्राइव था लेकिन कोई फ्लॉपी नहीं था। अगर मैं कर सकता था तो मैंने एक तस्वीर पोस्ट की।

— थॉमस ओ

Answer 3

ठीक है कि आपका दायरा PIC में आने वाली पहली बाइट को गलत साबित करता है इसलिए यह PIC पठन कार्य नहीं है।

क्या आपने लिखित समय को सत्यापित किया है कि प्राप्त अंत में ठीक है?

क्या यह नीचे दिए गए दोनों मोड में विफल है?

- Byte mode sequential
- Page mode Sequential

युक्ति से पता चलता है कि "मोस्ट सिगनी Bit कैंट बिट (MSB) 'b7' को 'rst' भेजा जाता है। यह भी संयोग है जब b7 = 1 कि पूरी बाइट को FF के रूप में वापस पढ़ा जाता है। इसलिए या तो इसे लिखा नहीं जाता है और केवल मिटाया जाता है (गलती की स्थिति) जब b7 = 1 होता है, या यह पूर्व सामग्री की परवाह किए बिना एफएफ के रूप में खराब पढ़ता है। चूँकि हर लिखने से पहले एक बाइट विस्तृत रूप से मिटा दी जाती है, क्या यह अभी भी एक बुरा लेखन या एक बुरा पढ़ा जा सकता है या 1 बाइट का समय अलग है।

सुझाव: सामान्य ऑपरेशन सुनिश्चित करने के लिए लिखने / पढ़ने के दौरान पीटीसी सिग्नल को सत्यापित करें।

पीटीसी का उपयोग करके ई / डब्ल्यू चक्र की लंबाई के लिए बाहरी घड़ी का उपयोग करने का एक विकल्प है। क्या आपने इसका उपयोग करने की कोशिश की है?

tE / W चक्र समय

• आंतरिक थरथरानवाला 7ms प्रकार
• बाहरी घड़ी 4 ~ 10 एमएस मिनट ~ अधिकतम

क्या यह इस मानदंड को पारित करता है?

Answer 4

ऐसा लगता है कि यह कुछ चीजें हो सकती हैं:

1. बस में और क्या है? क्या किसी अन्य डिवाइस के साथ एक बस विवाद हो सकता है जिसे रीसेट या अनइंस्टाल्यूट किया जा रहा है?
2. क्या आप सही ढंग से I / O पिन की दिशा बदल रहे हैं? यदि यह आउटपुट के मामले में ठीक काम कर रहा है, तो आप अनजाने में पिन की दिशा को इनपुट में बदलना भूल सकते हैं और हमेशा पढ़ेंगे 0xFF। पिन को एक आउटपुट के रूप में छोड़ा जा सकता है जब आप बस से ड्राइविंग कर रहे होते हैं जब आप उससे पढ़ते हैं।
3. क्या आपके पास पिन पर आंतरिक पुल-अप्स हैं और / या I / O लाइनों पर? माइक्रोकंट्रोलर आमतौर पर प्रतिरोध की एक सीमा देते हैं और निश्चित मूल्य नहीं। आप माइक्रो पर पुल-अप को निष्क्रिय करना चाहते हैं और बस में असतत लोगों का उपयोग कर सकते हैं क्योंकि आप असतत घटकों से अधिक सटीक पुल-अप प्रतिरोध प्राप्त कर सकते हैं।
4. घड़ी की ध्रुवता - क्या आप सुनिश्चित हैं कि आप घड़ी / डेटा के बीच दाहिने किनारे / चरण पर माप रहे हैं? आप यह देख सकते हैं कि आपके कार्यक्षेत्र पर क्या अच्छा लग रहा है, लेकिन यदि चरण पंक्ति से बाहर है, तो आपका EEPROM जो भी देखेगा वह 0xFFs है (और संभवत: यह एक अमान्य कमांड / स्थिति है)।

Comments

1. सिर्फ EEPROM और MCU। 2. हाँ, मेरा मानना ​​है कि मैं हूँ, क्योंकि EEPROM SDA / SCL को कम रखने में सक्षम है। 3. EEPROM से सटे बोर्ड पर 2.2k 5% पुल अप हैं।

— थॉमस ओ

# 2 के लिए, क्या आप निश्चित हैं कि EEPROM बस को कम रखने वाला है। क्या EEPROM की डेटशीट में कोई भी स्थिति है जहाँ यह सभी वापस आ जाएगी 0xFF? ऊपर मेरे संपादन भी देखें।

— जोएल बी

# 4। EEPROM "ACK" है मेरे अनुरोधों और कुछ शब्दों के साथ काम करता है, लेकिन सभी नहीं।

— थॉमस ओ

Answer 5

मैंने इसे एक टिप्पणी के रूप में प्रस्तुत किया है, लेकिन उत्तर में मेरा विश्वास चुपचाप मेरे मन की गहरी यादों में बढ़ रहा है इसलिए मैं इसे उत्तर देने के लिए प्रचार कर रहा हूं।

मैं एक पागल कूबड़ है कि यह लगभग निश्चित रूप से एक कम स्तर सॉफ्टवेयर बग है जो कुछ चर की हस्ताक्षर से संबंधित है। प्रत्येक बिट कोड के लिए, क्या आप अनजाने में शिफ्ट राइट ऑपरेशन के साथ साइन-एक्सटेंड कर रहे हैं? यदि आप हैं तो आपका प्रमुख व्यक्ति 7 शिफ्ट ऑपरेशन के बाद आपको 0xFF के साथ छोड़ देगा।

स्टीवन ने एक टिप्पणी में इस पर चर्चा की, लेकिन क्या आपने एक ऑसिलोस्कोप पर अपने लिखने के संचालन की पवित्रता देखी है, या क्या आप केवल यह मानते हैं कि वे आधे पढ़े हुए पीठ के आधार पर काम कर रहे हैं? यदि आपने मान 0xAA के लेखन संचालन को देखने की कोशिश नहीं की है, तो यह कोशिश करने के लिए एक अच्छी बात हो सकती है।

यदि आप अपने आंतरिक लूप और संबद्ध चर घोषणाओं का वास्तविक कोड प्रदान कर सकते हैं तो हम बग को देख सकते हैं।

Comments

मेरे लेखन अच्छे हैं; मैं इसे दायरे में देख सकता हूं। एक और विचित्रता: प्रमुख MSB वाले पते ठीक हैं। केवल डेटा मुद्दों का कारण बनता है! मैं जल्द ही कोड पोस्ट करने के बारे में सोचता हूं।

— थॉमस ओ

इस उत्तर के समर्थन में: यदि यह C कोड है, तो सभी 'char' घोषणाओं को 'अहस्ताक्षरित char' में बदलें और पुनः प्रयास करें।

— राउटर वैन Ooijen