דקויות פרוטוקול I2C – חלק 1

מאמר זה הוא הראשון בסדרה המתאר את ההיבטים ה“עדינים „יותר של פרוטוקול I2C, שפותח במקור על ידי פיליפס.

מכיוון שאתה קורא את הסדרה הזו, אני מניח שאתה כבר יודע מהו האוטובוס I2C, ואתה מחפש להימנע מכאבים כשתצטרך להשתמש בו בפרויקט. אם כן, הגעת למקום הנכון. אם לא, אני אוסיף בקרוב באתר מידע מקדים על I2C.

רק שיהיה ברור, הסדרה הזו לא תכלול כיסוי של מצב המהירות, מכיוון שהיא שונה מהותית מהעיצוב וההתנהגות של יישום האוטובוס המשותף של 2 חוטים, וגם היא לא נפוצה. יש הרבה חומרי עזר מצוינים באינטרנט שמכסים את המצב הזה.

להלן רשימה מהירה של מה שיוסקר בהמשך הסדרה:

  • חסר START
  • חסר STOP
  • התחלה חוזרת ונשנית
  • פיסות נתונים חסרות
  • חסר ACK/NAK
  • נתונים לאחר NAK
  • שגיאות גב אל גב
  • נגדי פולפול
  • חוזרי אוטובוס
  • יישום באמצעות ציוד היקפי TWI או I2C
  • יישום באמצעות ציוד היקפי של USI
  • יישום באמצעות ציוד היקפי של USART
  • הבדלים ב- SMBus מ- I2C

עכשיו, הלאה לדברים הטובים!

עבור מאמר זה, נתמקד ב -3 סוגי ההטמעות שתמצאו בעיצובים כיום: חומרה מלאה, תמהיל חומרה/תוכנה ותוכנה מלאה (או ‚bit-bang‘ כפי שהיא מכונה לפעמים).

הרבה בקרי מיקרו כיום, אפילו כמה התקנים נמוכים, כוללים ציוד היקפי I2C מלא בחומרה. Atmel מתייחס לשלהם כ- TWI, Microchip קורא להם I2C; ספקים אחרים משתמשים בשמות דומים. כשמשתמשים בגישה של חומרה מלאה, למעשה קשה ליצור שגיאה כלשהי באוטובוס, אלא אם אתה לא מבין איך הפריפריה פועלת או איך צריך להיראות רצף אוטובוסים I2C נכון. אולם באופן כללי, גישה זו דורשת את ההבנה הפחות מעמיקה של הפרוטוקול עצמו.

הציוד ההיקפי של USI שנמצא בחלק ממכשירי Atmel הוא עיצוב חומרה מינימלי שתלוי באינטראקציה של תוכנה כדי להפוך אותו ליישום מלא. ניתן להשתמש בפריפריה רב תכליתית זו עבור תצורות I2C, SPI ו- UART, ומתאימה למכשירים ברמה נמוכה שבהם הוספת כל שלושת הציוד ההיקפי תהיה חסרת עלויות. למרות שהוא דורש יותר קידוד מאשר ציוד היקפי של TWI או חומרה מלאה של I2C, הוא במובנים מסוימים גמיש יותר. גישה זו דורשת הבנה מעמיקה יותר של הפרוטוקול, מכיוון שאתה אחראי על מעבר ממדינה למדינה, ואפשר ללכת בכיוון הלא נכון.

לבסוף, יישום גישת תוכנה של 100% דורש הבנה מלאה של פרוטוקול I2C. כמעט כל ספק מיקרו-בקר מספק הערות יישום ודוגמאות קוד ליצירת מכשיר I2C Master באמצעות פתרון תוכנה טהורה. שלא כמו UART, I2C הוא פרוטוקול שעון (ולא מתוזמן), כך שהפרעות בביצוע הפרוטוקול נסבלות היטב, ומאפשרות טיפול בהפסקות ללא חשש לאיבוד נתונים. המהירות המרבית של הפתרון מבוסס התוכנה נקבעת בסופו של דבר על ידי מהירות השעון של המעבד, ובדרך כלל יישום Master יכול להגיע בקלות לקצב 400KHz.

יישום מבוסס תוכנה של מכשיר Slave הוא הרבה יותר מאתגר. ללא תמיכת חומרה, התוכנה חייבת לפקח גם על קווי ה- SDA וגם על קווי ה- SCL בו זמנית על מנת לזהות קצוות שעון ולדעת באופן חיובי את מצב קו ה- SDA לפני עלייתו או נפילתו של SCL. גילוי של מצב START או STOP בדרך כלל ידרוש שימוש בהפרעות, אחרת התוכנית צריכה לצרוך 100% עם ניטור SCL ו- SDA. יישומי תוכנת Slave המבוססים על תוכנה נוטים להיות כפופים למעבד, הדורשים מספר MIPS כדי להגיע לפעולה אפילו 100KHz. לכן, יישומים אמיתיים של תוכנת Slave עשויים אפילו לא להתקיים עבור משפחות מסוימות של מיקרו-בקר, ואחרות אחרות לא יכולות להגיע למהירות אוטובוס מלאה של 100KHz.

לאחר שהונחה תשתית חומרה ותוכנה זו, נצלול לעומק הפרוטוקול עצמו במאמר הבא שלנו. תודה שקראתם!

(זכויות יוצרים 2010 רוברט ג ‚פריס)



Source by Robert Fries

Empfohlene Artikel

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.