אינציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל מיקרו-בקרים למתחילים ומעלה. אנציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל אנציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל / מיקרו-בקרים פגישה ראשונה ראשית, כמה מילים למי שנושא המחזור, אם לשפוט לפי כותרתו, נראה אפריורי לא מעניין או "זר". אולי עדיין לא השתמשת במיקרו-בקרים בעיצובים שלך (להלן MK לקיצור) ואתה חושב שבעתיד הנראה לעין תוכל להסתדר בלעדיהם. ייתכן גם שאתה מניח שבניית מערכת מיקרו-בקר כדי לפתור את הבעיה שלך תהיה מסורבלת מדי ולא כדאית מבחינה כלכלית. אל תמהר: במיוחד בשבילך, אנחנו רוצים לתת כמה עובדות וכמה סטטיסטיקות. למשל, ניקח את קרוב המשפחה הקרוב ביותר של MK - מחשב אישי - ונשווה את עוצמת השימוש בו. לפי חברת האנליסטים Loewenbaum & Co. Inc. (ארה"ב), מספר המחשבים האישיים שיצאו בעולם בשנת 1997 הגיע לכ-20 מיליון יחידות. מסכים, זה הרבה. עכשיו תארו לעצמכם שהמספר העצום הזה הוא רק 0,2% מהייצור העולמי של MK. לפי חברת האנליטיקה IC Insights Inc. (ארה"ב) השוק העולמי ב-1998 ספג יותר מ-13,5 מיליארד מהם! המסקנה מעידה על עצמה. אם גם היום קשה למצוא תחום פעילות אנושי שבו המחשב לא היה מנוצל בצורה יעילה, אז מה אפשר לומר על ח"כ? מדוע הם הפכו כל כך פופולריים וממש חיוניים? התשובה טמונה בעצם המבנה של המיקרו-בקר. כקירוב ראשון להגדרה של מושג זה, אנו יכולים להניח שה-MC הוא מחשב הממוקם במעגל מיקרו בודד. מכאן תכונותיו האטרקטיביות העיקריות: מידות קטנות, צריכה, מחיר; ביצועים גבוהים, אמינות ויכולת התאמה לביצוע מגוון רחב של משימות. MK שונה ממיקרו-מעבד בכך שבנוסף ליחידת העיבוד המרכזית (CPU), הוא מכיל זיכרון והתקני קלט/פלט רבים: ממירים אנלוגיים לדיגיטליים, ערוצי מידע טוריים ומקבילים, טיימרים בזמן אמת, רוחב פולס. מאפננים (PWM), מחוללי פולסים ניתנים לתכנות ועוד. במבנה ובעקרון הפעולה שלו, ה-MK, במהותו, אינו שונה ממחשב אישי. לכן, המילים מיקרו-בקר ומיקרו-מחשב הן מילים נרדפות. עם זאת, המונח הראשון (מהמילה האנגלית control - manage) נפוץ יותר, מכיוון שהוא משקף את ייעודו העיקרי - שימוש במערכות בקרה אוטומטיות המובנות במגוון מכשירים: כרטיסי אשראי, מצלמות, טלפונים סלולריים, מערכות סטריאו, טלוויזיות, מכשירי וידאו. ומצלמות וידיאו, מכונות כביסה, מכוניות, תנורי מיקרוגל, מערכות אזעקה לפריצה, מערכות הצתה של מנועי בנזין, כוננים חשמליים של קטרים, כורים גרעיניים ועוד הרבה, הרבה יותר. מערכות בקרה משובצות הפכו לתופעה כה המונית, עד שלמעשה נוצר ענף חדש במשק, הנקרא Embedded Systems (מערכות משובצות - אנגלית). כיום, אלפי זנים של MK מיוצרים בעולם. הם מסופקים באריזות עם 8 עד 356 פינים, פועלים בטמפרטורות מ-55 עד +125oC בתדרים מ-32 קילו-הרץ עד 200 מגה-הרץ, מסוגלים לפעול במתח אספקה של 1,2 וולט, תוך צריכת זרם שאינו עולה על כמה מיקרואמפר. . גם מחיר המוצרים יורד כל הזמן. כמה MCUs של שמונה סיביות עולים כבר היום לא יותר מ-50 סנט, אשר ניתן להשוות לעלות של שבב "היגיון קשיח" אחד. כל זה הוביל לכך שכיום קשה יותר ויותר למצוא אזור של פעילות אנושית שבו MC לא ימצא יישום, ולתהליך ההפצה שלהם יש אופי דמוי מפולת. אנו מקווים שהעובדות שלעיל כבר הקנו אותך ליחס מכבד כלפי הדמות הראשית של הסיפור שלנו. ואכן, MC הפך לאירוע עולמי, שפלש כמעט לכל סוגי הפעילות האנושית. מה סיפק צמיחה כה מהירה בפופולריות של מוצרים אלה, שהופיעו לפני קצת יותר מ-25 שנה? מהם המכשירים הללו ומה היכולות והסיכויים שלהם? אם עדיין לא השתמשת ב-MC או במערכות המבוססות עליהם בפעילויות שלך, אז. אולי הגיע הזמן לחשוב על זה? ואם תחליט להגיש בקשה לח"כ, אז מה צריך להיות רצף הפעולות שלך? אילו קשיים עשויים לחכות לך, מה יכול לעזור לך בדרך? ננסה לענות על שאלות אלו בסדרת המאמרים המוצעת. חוק מור והחבר הכנסת הראשון עוד ב-1965, גורדון מור, אחד המייסדים העתידיים של תאגיד אינטל העוצמתי, הפנה את תשומת הלב לעובדה מעניינת. לאחר שתכנן את צמיחת הביצועים של שבבי זיכרון, הוא גילה דפוס מעניין: דגמי שבבים חדשים הופיעו כל 18 עד 24 חודשים, והקיבולת שלהם הוכפלה בערך בכל פעם. אם המגמה הזו תימשך, הציע ג'י מור, אזי כוחם של התקני מחשוב יגדל באופן אקספוננציאלי בפרק זמן קצר יחסית. התחזית של ג'י מור אושרה לאחר מכן בצורה מבריקה, והדפוס שגילה נצפה היום, ובדיוק מדהים, כשהוא בסיס לתחזיות רבות של גידול בפריון. ב-28 השנים שחלפו מאז הופעת המיקרו-מעבד 4004 (1971), מספר הטרנזיסטורים בשבב גדל ביותר מפי 12: מ-000 ל-2 בשבב Sorrettué. ובכן, בשנת 1976, הפיתוח האקספוננציאלי של טכנולוגיית המוליכים למחצה הוביל ליצירת ה-MK הראשון - 8048 על ידי אינטל. בנוסף למעבד, הוא כלל זיכרון תוכניות, זיכרון נתונים, טיימר שמונה סיביות ו-27 קווי I/O. כיום, ה-8048 הוא כבר היסטוריה, אבל המוצר הבא, שיצא על ידי אינטל ב-1980, עדיין חי וקיים. זה MK 8051. ARCHITECTURE MK 8051 חבר כנסת זה יכול להיחשב לדגם קלאסי, שבדמותו ובדמותו נוצרו מאוחר יותר מוצרים רבים אחרים. דיאגרמת הבלוק שלו מוצגת באיור. 1. CPU - הצומת הראשי של ה-MK. זה קשור למושג חשוב כל כך כמו מערכת פיקוד. ערכת ההוראות היא קבוצה ייחודית של קודים בינאריים ספציפיים למעבד נתון המגדיר רשימה של כל הפעולות האפשריות שלו. כל קוד כזה מגדיר פעולה אחת ונקרא קוד פעולה או פקודה. ככל שמשתמשים יותר קודים בערכת ההוראות, כך המעבד יכול לבצע יותר פעולות. MK 8051 הוא שמונה סיביות, כך שהאופקודים שלו הם בגודל של 8 סיביות. תיאורטית, יכולים להיות בסך הכל 256 קודים של שמונה סיביות. 8051 משתמש ב-255. בהתאם למספר קודי הפעולה בהם נעשה שימוש, מערכות ההוראות מחולקות לשתי קבוצות: CISC ו-RISC. המונח CISC פירושו מערכת מורכבת של פקודות והוא קיצור של ההגדרה האנגלית של Complex Instruction Set Computer. באופן דומה, המונח RISC פירושו ערכת הוראות מופחתת ומגיעה מהמחשב האנגלי של Reduced Instruction Set Computer. ניתן לייחס את מערכת הפיקוד MK 8051 לסוג C15C. עם זאת, למרות השימוש הנרחב במושגים הללו, יש להכיר בכך שהשמות עצמם אינם משקפים את ההבדל העיקרי בין מערכות הפיקוד CISC ו-RISC. הרעיון המרכזי של ארכיטקטורת RISC הוא בחירה קפדנית של שילובים כאלה של קודי פעולה שיכולים להתבצע במחזור אחד של מחולל השעון. הרווח העיקרי מגישה זו הוא פישוט חד של יישום החומרה של המעבד והיכולת להגדיל משמעותית את הביצועים שלו. בתחילה, ניתן היה ליישם גישה כזו רק על ידי צמצום משמעותי של מערך ההוראות, ומכאן נולד השם RISC. לדוגמה, ערכת ההוראות של חבר כנסת ממשפחת Microchir PIC כוללת רק 35 הוראות וניתן לסווג אותן כ-RISC. ברור שבמקרה הכללי, מספר הוראות של ארכיטקטורת RISC חייבות להתאים להוראה אחת של ארכיטקטורת CISC. עם זאת, רווחי הביצועים מארכיטקטורת RISC עולים בדרך כלל על ההפסדים ממערך ההוראות הפחות יעיל, וכתוצאה מכך יעילות גבוהה יותר של מערכת RISC כולה בהשוואה ל-CISC. כך. הפקודה המהירה ביותר MK 8051 מבוצעת ב-12 מחזורים. גם אם יש צורך לבצע שלוש הוראות בקר RISC עבור כל פקודה, בסופו של דבר, ארכיטקטורת RISC תספק פי XNUMX בביצועים. על הדרך, ארכיטקטורת RISC מאפשרת לך לפתור מספר משימות. ואכן, עם פישוט ה-CPU, מספר הטרנזיסטורים הדרושים ליישום שלו פוחת, ולכן שטח הגביש פוחת. זה מביא להפחתת עלות וצריכת חשמל. בשלב זה, אפשר לקרוא: העתיד שייך לארכיטקטורת RISC! עם זאת, הגבול בין שני המושגים הללו מיטשטש במהירות. לדוגמה. למכשירי MCU של משפחת AVR של Atmel יש ערכת הוראות של 120 הוראות, התואמת לסוג CISC. עם זאת, רובם מבוצעים במחזור אחד, שהוא סימן ההיכר של ארכיטקטורת RISC. כיום מקובל כי המאפיין העיקרי של ארכיטקטורת RISC הוא ביצוע הוראות במחזור אחד של מחולל השעון. מספר הפקודות כשלעצמו כבר לא משנה. מחולל השעון יוצר פולסים לסנכרון הפעולה של כל הצמתים של המכשיר. את תדירות החזרה שלהם ניתן לקבוע על ידי מהוד קוורץ או מעגל RC המחובר ליציאות של MK. בחלק מחברי הכנסת מסופק מצב הפעלה של מחולל שעונים ללא שימוש באלמנטים חיצוניים. במקרה זה, תדירות פעימות השעון תלויה בפרמטרים של הגביש, אשר נקבעים במהלך ייצורו. ROM הוא התקן זיכרון לקריאה בלבד המיועד לאחסון תוכניות, ולכן זיכרון זה נקרא לעתים קרובות זיכרון קוד או תוכנית. עד לא מזמן, היו שני סוגים עיקריים של ROM - מסכות וניתנות לתכנות. מידע מוכנס ל-mask ROMs במהלך תהליך הייצור של MC באמצעות תבניות טכנולוגיות - מסכות. לא ניתן לשנות אותו לאחר סיום מחזור הייצור. ROMים כאלה משמשים רק במקרים שבהם איכות התוכנית היא מעבר לכל ספק ויש צורך עצום ב-MK עם התוכנית הספציפית הזו. היתרון של מסיכות ROMs הוא העלות הנמוכה ביותר בייצור המוני (מכמה אלפי חתיכות). מידע ROM הניתן לתכנות נכתב באמצעות התקן הנקרא מתכנת. MK עם ROMs כאלה הם משני סוגים: פעם אחת וניתנת לתכנות שוב ושוב (ניתן לתכנות מחדש). הראשון, כפי שאומר השם עצמו, מאפשר תכנות חד פעמי בלבד, שלאחריו כבר לא ניתן למחוק את המידע (MK עם זיכרון OTP - מהאנגלית. One Time Programmable). הם משמשים בייצור בקנה מידה קטן (עד 1000 חתיכות). כאשר השימוש במסכה MK אינו מוצדק כלכלית. מיקרו-מעגלים הניתנים לתכנות שוב ושוב מחולקים ל-MK המצויד ב-ROM עם מחיקה באמצעות קרינה אולטרה-סגולה (זמין באריזות עם "חלון"), ו-MK עם זיכרון שניתן לתכנות מחדש חשמלית. החיסרון של MC עם ROM עם מחיקה על ידי קרינה אולטרה סגולה הוא עלות גבוהה מאוד ומספר קטן יחסית של מחזורי כתיבה/מחיקה (תלוי במינון הכולל של קרינת גבישים ובדרך כלל אינו עולה על 15 ... 20) נכון לעכשיו, טכנולוגיה חדשה להטמעת ROM הופכת יותר ויותר פופולרית - Flash-memory. הכשרון העיקרי שלו הוא שהוא בנוי על עיקרון התכנות החשמלי מחדש. כלומר, הוא מאפשר מחיקה והקלטה מרובה של מידע באמצעות מתכנתים. המספר המינימלי המובטח של מחזורי כתיבה/מחיקה עולה בדרך כלל על כמה אלפים. זה מגדיל משמעותית את מחזור החיים ומגביר את הגמישות של מערכות MC. מכיוון שהוא מאפשר לך לבצע שינויים בתוכנית MC הן בשלב של פיתוח המערכת והן במהלך פעולתה במכשיר אמיתי. זיכרון RAM הוא זיכרון גישה אקראית המשמש לאחסון נתונים, ולכן זיכרון זה נקרא גם זיכרון נתונים. מספר מחזורי הקריאה והכתיבה ב-RAM אינו מוגבל, אך כאשר מתח האספקה כבוי, כל המידע אובד. הארכיטקטורה של ה-MK 8051 כוללת שימוש נפרד בזיכרון תוכניות ונתונים ונקראת הרווארד. בדרך כלל, ארכיטקטורה זו משמשת לשיפור ביצועי המערכת על ידי הפרדת נתיבי גישה לתוכניות וזיכרון נתונים, אך ב-8051 היא שימשה להשגת זיכרון תוכניות ונתונים שלא דרשו את אותו גודל. האנטיפוד של הרווארד - ארכיטקטורת פון נוימן - כרוך באחסון תוכניות ונתונים בזיכרון משותף והוא אופייני ביותר למיקרו-מעבדים המיועדים לשימוש במחשבים. דוגמה לכך היא משפחת המיקרו-מעבדים x86. טיימרים TO, T1 הם טיימרים/מונים ניתנים לתכנות של 32 סיביות שניתן לתכנת לביצוע מגוון פונקציות. הם יכולים לשמש ליצירה מדויקת של מרווחי זמן, ספירת פולסים ביציאות של MK, יצירת רצף של פולסים, שעון מקלט משדר של ערוץ תקשורת טורי. טיימרים/מונים מסוגלים ליצור בקשות פסיקה, להעביר את ה-CPU לשרת אותם באירועים ולשחרר אותו מהצורך בסקר תקופתי של מצב הטיימרים. מכיוון שהיישום העיקרי של MK נמצא במערכות בזמן אמת, טיימרים / מונים הם המרכיב ההכרחי שלהם. בשינויים מסוימים, מספר הטיימרים מגיע ל-XNUMX. היציאה הטורית היא ערוץ לחילופי מידע בין הח"כ לעולם החיצון. ערוצי תקשורת כאלה תופסים מספר מינימלי של פיני קריסטל, ומספקים תקשורת למרחקים משמעותיים עם עלויות חומרה מינימליות. ה-8051 מיישם מקלט משדר טורי אוניברסלי אסינכרוני (UART) התומך בפרוטוקול הסטנדרטי RS-232C, המאפשר לארגן תקשורת בין MK זה למחשב אישי. בנוסף ל-RS-232C, הפרוטוקולים הפופולריים ביותר בעולם המערכות המשובצות הם RS-485. I2C (אוטובוס דו-כיווני דו-חוטי). SPI (ממשק היקפי טורי XNUMX חוטים). Bitbus (אוטובוס בקרה טורי), CAN (ממשק רשת בין-בקר), USB (אוטובוס טורי אוניברסלי) ועוד כמה. כמעט לכל סוג של ערוץ טורי, כיום ניתן למצוא MK שיש לו יציאה טורית מתאימה בהרכבו. יציאות I/O מקבילות הן גם חלק חיוני בכל MCU. בדרך כלל הם משמשים לתקשורת עם הסביבה הקרובה - חיישנים ומפעילים. תכונה חשובה של היציאות המקבילות של MK היא היכולת להיות מתוכנת לבצע מספר פונקציות. לדוגמה, ב-8051, פיני יציאות P0 ו-P2 יכולים לשמש כאוגרי קלט/פלט סטטיים רגילים, או בתור אפיק כתובת ונתונים לחיבור התקנים חיצוניים כגון זיכרון תוכניות נוסף, זיכרון נתונים, התקני קלט/פלט. זה נותן ל-MK גמישות אדריכלית. יציאת RXNUMX יכולה לשמש כאוגר קלט/פלט סטטי, או לבצע פונקציות מיוחדות להפעלת ערוץ טורי, טיימרים, בקר פסיקה וכו'. יכולת התכנות מחדש מאפשרת לך להשתמש בכל היציאות של ה-MC במכשיר המעוצב ביעילות מירבית. מערכת הפסיקה היא אחד החלקים החשובים ביותר של מ.כ. תכונה של מערכות בזמן אמת היא שעבורן פרמטר חשוב ביותר הוא זמן התגובה לאירועים חיצוניים. בואו נסביר בעזרת דוגמה פשוטה. כאשר מבצעים חישוב מתמטי במחשב, נוהגים להפעיל תוכנה המיועדת לבצע את החישובים הללו, ולאחר שהיא נטענת לזיכרון המחשב, מכניסים את הצהרת הבעיה וממתינים לתוצאה. לזמן ההמתנה במקרה זה אין חשיבות עקרונית (בגבולות הסביר כמובן) - הפעולה האיטית של המחשב עלולה להיות מטרידה, אך הדבר לא ישפיע על התוצאה. מערכת בזמן אמת מניחה מהירות מאוד ספציפית, מחושבת בשלב הפיתוח, של מהירות התגובה של מערכת הבקרה לאירועים חיצוניים. עיכובים מעבר לאלה המחושבים פשוט לא מקובלים כאן - הם יכולים להוביל לתוצאות קטסטרופליות. בעיות של תגובה מהירה לאירועים נפתרות על ידי ארגון מערכת של פסיקות. משתמע מכך שלכל אירוע כזה פותח "חתיכת קוד" נפרדת, שיוצר את תגובתו של חבר הכנסת אליו. "חתיכת קוד" זו נקראת שגרת בקשת פסיקה (המונח שגרת פסיקה משמש לעתים קרובות לקיצור) והיא ממוקמת בזיכרון התוכנה בכתובת ידועה. ברגע התרחשות של אירוע נתון, אות לגבי זה נשלח לכניסה של בקר הפסיקה. האחרון הוא התקן שיוצר התאמה אחד לאחד בין אות הקלט לגבי אירוע שהתרחש לבין כתובת זיכרון התוכנה שבה ממוקמת נקודת הכניסה לשגרת עיבוד בקשת הפסיקה מאירוע זה. הבקר קוטע את ביצוע ה-CPU של התוכנית הנוכחית ומתחיל את המעבר שלה לביצוע שגרת שירות ההפסקה. הזמן שחלף מרגע התרחשות האירוע ועד לתחילת ביצוע ההוראה הראשונה של שגרת הפסיקה נקרא זמן התגובה של הח"כ לאירוע. לאחר השלמת העיבוד, המעבד חוזר אוטומטית לביצוע התוכנית שנקטעה. פונקציה נוספת של בקר הפסיקה היא לתעדף אירועים. משמעות המושג עדיפות היא ששגרת פסיקה פועלת יכולה להיקטע רק על ידי אירוע אחר אם יש לה עדיפות גבוהה מזו הנוכחית. אחרת, ה-CPU יעבור לעיבוד אירוע חדש לאחר סיום עיבוד האירוע הקודם. לבקר הפסיקה, שהוא חלק מה-MK 8051, יש חמש כניסות אירועים: שתיים מהתקנים חיצוניים, שניים מטיימרים ואחת מהערוץ הטורי. בדרך כלל, כשמדברים על כל חבר כנסת, תמיד מזכירים את המשפחה שאליה הוא שייך. משפחה אחת כוללת מוצרים בעלי אותה ליבה, המובן כמערכת של מושגים כמו מערכת הוראות, דיאגרמת רצף פעולות CPU, ארגון זיכרון תוכניות וזיכרון נתונים, מערכת פסיקה ומערכת בסיסית של התקנים היקפיים. . למעשה, באיור. 1 מציג את הליבה שהפכה לבסיס ליצירת מאות שינויים אחרים של משפחת 8051. ההבדלים בין נציגיה השונים הם בעיקר בהרכב המכשירים ההיקפיים ובכמות זיכרון התוכניות או הנתונים. מאז מגוון המשימות שנפתרה על ידי ח"כ. רחב ביותר, היצרנים שלהם מנסים לשחרר כמה שיותר שינויים כדי לספק את צרכי הצרכנים המגוונים ביותר. במשפחות רבות, מספר השינויים מתקרב למאה או אפילו עולה על ערך זה. המאפיין החשוב ביותר של המשפחה הוא תאימות תוכנה ברמת הקוד הבינארי של כל חברי הכנסת הכלולים בה. זה מאפשר למפתחי מערכות להחליף משפחה אחת של מיקרו-בקרים באחרים מבלי לאבד את פיתוחי התוכנה שלהם. מטבע הדברים, ככל שמספר הזנים הכלולים במשפחה גדול יותר, כך גדל הסיכוי לבחור באפשרות הטובה ביותר, כך משפחה זו אטרקטיבית יותר עבור היזם. שאלת הבחירה הנכונה של משפחת MC לפיתוח חדש היא שאלה אסטרטגית, שכן בעיית העברת התוכנה בין מוצרים ממשפחות שונות מורכבת ביותר, ואפילו השימוש בשפות ברמה גבוהה לא תמיד מאפשר פתרון ללא הפסדים גדולים. לסוגיית קריטריוני הבחירה נחזור במאמרי המחזור הבאים. פיתוח התוכנית הוא אחד השלבים החשובים ביותר ביצירת מכשיר מבוסס MK. בלעדיו הוא "מת", אינו מגיב להשפעות חיצוניות ואינו מוציא אותות בקרה. כאשר הכוח מופעל, ה-MCU מתחיל מיד להפעיל את התוכנית שנמצאת בזיכרון התוכנית (בדרך כלל ROM) המחובר אליו. הביצוע שלו מתחיל מכתובת קבועה כלשהי, לרוב אפס. כתובת היא פשוט מספר תא ROM. התהליך מתבצע באופן הבא: ה-MCU קורא את המספר המאוחסן בזיכרון התוכנית, ובהתאם לערכו, הנקרא קוד המכונה, מבצע פעולות מסוימות על התוכן של אוגרי ה-ALU . זיכרון, יציאות וכו'. לדוגמה, על ידי קריאת המספר 32H מזיכרון התוכנית. MK "מבין" שצריך לקרוא את הערך מיציאת הקלט מספר 2 ולמקם אותו בפנקס המצברים. לעתים קרובות בית אחד לא מספיק כדי לתאר את הפעולה, ואז הח"כ קורא בתים נוספים מהזיכרון. לאחר ביצוע הפעולה, הח"כ קורא את הערך מתא הזיכרון הבא לפי הסדר וכו'. קבוצת הבתים המתארת פעולה אחת שמבצע הח"כ נקראת פקודת מכונה (הוראה), וקבוצת הפקודות כאלו שהח"כ " מבין". - מערכת הפיקוד או ערכת ההוראות שלו (סט הוראות). לחברי כנסת ממשפחות שונות יש מערכות פיקוד שונות, כלומר לקודי המכונה שלהם יש משמעויות שונות, למרות שהם מבצעים פעולות דומות. אז, התוכנית עבור MK היא רצף של מספרים, שערכיהם מציינים לה אילו פעולות לבצע. התוצאה של פיתוח תוכנית היא קובץ מחשב המכיל קודי מכונה אלה. בעזרת מתכנת ROM הוא מוכנס ("תפור") לזיכרון תוכנית MK. איך ההרכב של רצף קודי מכונה זה - תוכנית עבור MK? האם המפתח באמת צריך לזכור את הערכים של קודי מכונה ולהגדיר באופן ידני את הרצף שלהם? כך נוצרו התוכניות הראשונות עבור MK. וזה נקרא תכנות בקודי מכונה. ברור שדרך זו של פיתוח תוכניות היא מאוד גוזלת זמן ולא יעילה. השלב הראשון בהקלת תהליך יצירת התוכנות היה תוכנת מחשב - מה שנקרא מתרגם משפת האסמבלי. הרעיון היה לבטא את הפעולות שביצע הח"כ בשפה יותר קריאה אנושית ולאחר מכן להמיר את הביטויים הללו לקודי מכונה. בהוראת מכונה לדוגמה לעיל שקוראת את הערך של יציאה 2 ומכניסה אותו לצובר, ניתן לסמן בערך את הפעולה שננקטה כ-MOV A.P2. כאן המילה MOV (מהמהלך האנגלי), הנקראת instruction mnemonic, מציינת העברת ערך, ו-A ו-P2, הנקראים אופרנדים, מציינים מאיפה להשיג את הערך ואיפה לשים אותו. סימון זה נקרא שפת הרכבה. תוכנית שנכתבה עליו. מעובד על ידי מתרגם הממיר מבני שפת assembly לקודי מכונה. תכנות שפת האסיפה נפוצה עד היום. מתרגמי שפות הרכבה עבור כל משפחות המיקרו-בקרים הפופולריות הן בחינם. למרות היתרונות הברורים של תכנות ב-assembler על פני תכנות בקוד מכונה, במקרים רבים ה-assembler אינו יעיל מספיק כדי ליישם את המשימות של המפתח. העובדה היא שח"כ מסוגל לבצע רק את הפעולות הפשוטות ביותר כמו פעולות אריתמטיות על מספרים שלמים, העברות, השוואות וכו'. עבור משימות מורכבות יותר, למשל, פעולות על מספרי נקודה צפה, המפתחים היו צריכים לכתוב שגרות מיוחדות שאינן נוחות שימוש ומסורבל. השלב הבא בפיתוח תוכניות עבור MK היה יצירת תוכנות מחשב מיוחדות - מתרגמים משפות תכנות ברמה גבוהה, או מהדרים. שפת התכנות הנפוצה ביותר היא C. עם הופעת המתרגמים, פיתוח התכניות עבור MK פושט באופן דרמטי. אם, למשל, אתה צריך להוסיף שני מספרים בתוכנית, אז עכשיו זה מספיק רק לכתוב a = b + c. והמתרגם ממיר את הביטוי הזה לרצף ההכרחי של הוראות מכונה בהתאם לסוגי המשתנים a, b ו-c. השימוש בשפה ברמה גבוהה מאפשר למפתח להפשט ממערכת הפיקוד של מיקרו-בקר מסוים ולפעול עם קטגוריות פשוטות ומובנות יותר לאדם. המפתח נדרש רק לדעת את הארכיטקטורה הכללית של המיקרו-בקר. עקרונות הפעולה של התקנים היקפיים משובצים הדרושים לפתרון המשימה ומיומנויות התכנות בשפת C. התוכן הפונקציונלי של התוכנית מיושם באמצעות כלי שפת C. המכיל מספר רב של תתי שגרות (פונקציות) שונות: חשבון, לעבודה עם מחרוזות תווים ועוד רבות אחרות. שקול את תהליך יצירת תוכנית עבור MK בשפת C. תהליך הפיתוח ידרוש מחשב אישי. לאחר הבנת המשימה, המפתח כותב את קוד המקור של התוכנית שלו בשפת C באמצעות כל עורך טקסט. לאחר מכן הוא מריץ את תוכנית התרגום C. הממיר את טקסט המקור לקובץ אובייקט ביניים. המתרגם נשלט על ידי קבוצה של מקשים (את התיאור שלהם ניתן למצוא בתיעוד שלו) המצוינים בשורת הפקודה שלו. אם המפתח ביצע שגיאות תחביריות בעת כתיבת התוכנית, המתרגם מציג רשימה שלהן על המסך עם אינדיקציה לכל מספר שורה בקובץ הטקסט המקור. על המפתח לתקן את כל הבאגים. לאחר תרגום מוצלח, יש לעבד את קבצי האובייקט על ידי המקשר (מקשר), אשר יוצר את קובץ התוכנית בקודי מכונה. יש בעיה אחת בעת שימוש בשפה ברמה גבוהה. המהדר אחראי להמרת מבני שפה לקודי מכונה, וניתן לבצע המרה זו בדרגות שונות של יעילות. קריטריוני היעילות הם גודל קוד המכונה (ככל שהוא קטן יותר, כמובן, כך טוב יותר) ומהירות קוד המכונה. המשימה של הפקת קוד קומפקטי ומהיר היא קשה מאוד, והאיכות הכוללת של המהדר תלויה בפתרון שלו. מהדרים C מודרניים משתמשים באופטימיזציה מרובת רמות, תכונות ארכיטקטורה של MK מסוים, מאפשרים לך ליצור תוכניות מעורבות שבהן חלק מתתי השגרות נכתבות ב-Assembler. התהליך המתואר נראה מסורבל למדי: על המפתח להפעיל ידנית תוכנות שונות (עורך טקסט, מהדר C, קישור לזכור מפתחות בקרה, חיפוש שגיאות בתוכנה לפי מספרי שורות בקובץ. השלב האחרון עד כה בהקלת העבודה של מפתח תוכניות עבור MK היה הופעתה של פיתוח סביבות משולבות (Integrated Development Environment. IDE). סביבת פיתוח משולבת היא תוכנת מחשב המקשרת יחד את כל שלבי פיתוח התוכנית. היא משלבת עורך טקסט לכתיבת קוד מקור, מתרגמים מ-assembler ו-C, מקשר, מאתר באגים, מידע הפניה על MK וכלים אחרים הנחוצים למפתח. קביעת התצורה של מתרגמים, מקשר ורכיבים אחרים מתבצעת לא על ידי ציון מתגים בשורת הפקודה, אלא בצורה של תיבות דיאלוג שבהן אתה רק צריך לסמן את התיבות במקומות הנכונים. . הופעתן של סביבות פיתוח תוכנה משולבות הגבירה עוד יותר את היעילות של יצירת תוכניות עבור MC, אפשרה למפתח להתמקד במהות הבעיה הנפתרת ולהפשט מהפרטים הספציפיים של יישומה. חבילות פיתוח תוכנה משולבות מיוצרות על ידי מספר חברות. חבילות מיצרנים שונים דומות בתפקודן, אך שונות ביכולות השירות, קלות השימוש ואיכות קוד המכונה שנוצר. המאפיינים העיקריים של ערכות הפיתוח הפופולריות ביותר מוצגים בטבלה. ניפוי סימבולי של תוכניות עבור MK למעט חריגים נדירים, תוכניות עבור MK, עקב השגיאות שהן מכילות, אינן מתחילות לעבוד בפעם הראשונה ודורשות איתור באגים. מפתחים מתמודדים עם בעיות באגים בדרכים שונות. חלקם מאמינים שמספיק לנתח בקפידה את טקסט המקור, לראות באוסילוסקופ מה קורה ביציאות MK, וניתן לתקן את כל השגיאות. שיטה זו ישימה אם למפתח יש ניסיון רב, מכיר את ה-MK בשימוש בצורה מושלמת ויש לו מתרגם שתמיד יוצר את הקוד הנכון (בדרך כלל אסמבלר), ומספיק זמן. אחרים משתמשים במסכי ניפוי באגים תוצרת בית בתרגול שלהם - סטים של תת-שגרות מיוחדות שנטענות ל-MK יחד עם התוכנית הראשית. זה האחרון קורא לניטור תת-שגרות במחסומים, והם מספקים מידע על מצב משאבי הח"כ. כמעט כל תוכנית ניתנת לניפוי באגים בדרך זו, אבל יש לה חסרונות שיכולים להיות משמעותיים. ראשית, יש לספק למוניטור איתור באגים חלק ממשאבי ה-MC לעבודה: לפחות חלק ממרחב הכתובות של הקוד ומספר מסוים של תאי מחסנית, וכמקסימום, גם חלק מה-RAM והציוד ההיקפי. מכשירים של MC. משמש את הצג להצגת מידע. זה יכול להיות קשה להקצות משאבים לניפוי באגים אם התוכנית הראשית עצמה טוענת באופן פעיל את ה-MK. לדוגמה, ל-PIC 16С5х (Microchip) MK יש רק שני תאי מחסנית, וקשה להשתמש בקריאות תת שגרתיות לניפוי באגים. שנית, שיחות ניטור לוקחות זמן מהתוכנית הראשית, ולכן לא ניתן להתקשר אליה מחלקים קריטיים לזמן של התוכנית. שלישית, יצירת צג ניפוי באגים, כשלעצמה, לוקחת זמן. הדרך היעילה ביותר לנפות באגים בתוכניות עבור MK היא להשתמש בכלי ניפוי באגים מקצועיים מיוחדים, הכוללים ניפוי באגים בסימולטור ואמולטורים בתוך המעגל. לפני שנדבר על האפשרויות הניתנות על ידי מאפי באגים כאלה, יש צורך לגעת בבחירת המהדר, שבעזרתו מומרים טקסטי המקור של תוכניות לקוד מכונה. ברוב המוחלט של המקרים, עדיף תכנות בשפה ברמה גבוהה. השימוש ב-Assembler הכרחי אם מוטלות דרישות מחמירות מאוד על גודל ומהירות הקוד שנוצר. נכון להיום, מקרים כאלה הולכים ופוחתים, שכן כמעט תמיד אפשר לקחת חבר כנסת "מהיר" יותר עם יותר זיכרון. בנוסף, חבילות חוצות כלים מודרניות מקלות על כתיבת תוכניות מעורבות, כאשר חלק מהמודולים כתובים ב-C. והחלקים הקריטיים ביותר לביצועים נמצאים ב-assembler. מהדרים C מאפשרים גם להכניס הוראות הרכבה לקוד המקור. מהם היתרונות של תכנות ב-C בהשוואה לתכנות ב-assembler? בקצרה, הם כדלקמן:
על מנת לבצע ניפוי באגים יעיל בתוכנות הכתובות בשפה ברמה גבוהה, על המפתח לעמוד בכלי ניפוי באגים המספקים הזדמנויות מתאימות להצגת הנתונים המשמשים בתוכנה, וכן למעקב אחר ביצוע התוכנית מקוד המקור שלה. . שני תנאים נדרשים כדי שזה יהיה אפשרי:
כעת נבחן כיצד על מאתר הבאגים לפרש מידע סמלי ואילו אפשרויות יש לספק למשתמש בקשר לכך. מעקב אחר ביצוע התוכנית על פי טקסט המקור שלה באופן כללי, שורה אחת של טקסט מקור מומרת על ידי המהדר למספר הוראות מכונה. אפילו תוכנית אסמבלר מכילה כמעט תמיד פקודות מאקרו שמתרחבות למספר הוראות מעבד בעת תרגום. זה לא נוח לנפות באגים בתוכנית כזו באמצעות המפרק של הקוד שלה, אז מהדרים מכניסים טבלה של מספרי שורות למידע באגים. הוא מכיל מידע על התאמת מספרי שורות טקסט מקור ושמות קבצי טקסט מקור לכתובות מוחלטות של קוד התוכנית. מאתר הבאגים מציג את קוד המקור של התוכנית על המסך. בעקבות טבלה זו, הוא יכול להפעיל את התוכנית "שורה אחר שורה", ולבצע בשלב אחד את כל הוראות המכונה שנוצרו על ידי המהדר עבור השורה הנוכחית. טבלת מספרי השורות גם מאפשרת לך לבצע פעולות הקשריות עם טקסט התוכנית, למשל, לבצע אותו "לסמן", כלומר, למקום שצוין על ידי המשתמש בטקסט המקור, להגדיר נקודות עצירה בקווים שצוינו וכו'. פעולות הקשריות נוחים כי המפתח אינו צריך לדעת את הכתובות המתאימות לשורות טקסט המקור: מאתר הבאגים עצמו יקבע אותן מהטבלה. מאתר הבאגים חייב גם "לדעת" את הכתובות של תתי שגרות, פונקציות ותוויות קוד, ולהיות מסוגל למצוא את טקסט המקור של פונקציה לפי שמה. הצגת נתונים בשימוש בתוכנית באגים לצורך איתור באגים מלא, המפתח צריך להיות מסוגל לראות את הנתונים שתופעלו על ידי התוכנית בכל עת. מאתר הבאגים חייב "להיות מסוגל" להציג כל נתונים המשמשים את התוכנית בצורה המתאימה ביותר. ככלל, מפתחים משתמשים בנתונים בעלי שם בתוכניות, כלומר לכל אובייקט שנמצא בשימוש בתוכנית ניתן שם. אובייקטים יכולים להיות במורכבות משתנה - מתאי זיכרון פשוטים ועד למבנים מורכבים של שפות ברמה גבוהה כמו מבנים, מערכים וכו'. נתונים בתוכניות הרכבה תוכניות הרכבה משתמשות בעיקר בנתונים פשוטים, כלומר בתאי זיכרון. נעשה שימוש גם במערכים. כדי להציג נכון נתונים פשוטים, מאתר הבאגים צריך "לדעת":
עם המידע הנ"ל, על ה-debugger, לאחר קבלת שם האובייקט מהמשתמש, להציג את ערכו לפי הסוג. מאפי הבאגים ה"מתקדמים" ביותר יכולים להציג בנוסף את שאר התכונות של האובייקט. נתונים בתוכניות בשפות ברמה גבוהה הצגת אובייקטים המשמשים בשפות ברמה גבוהה היא הרבה יותר קשה בגלל מגוון מבני האובייקט, הדרכים שבהן הם מאוחסנים בזיכרון והיקפים. לדוגמה, נשתמש בשפת C, בתור הפופולרית ביותר בקרב מפתחים. מבנה של אובייקטים בנוסף למשתנים פשוטים באורכים שונים, תוכניות C משתמשות גם במשתני נקודה צפה, מבנים (struct), איגודים או איגודים (איחוד), מצביעים, מערכים חד מימדיים ורב מימדיים. האחרון יכול להיות מורכב מאובייקטים פשוטים ומורכבים (מבנים, איגודים, מצביעים). שימוש באובייקטים מורכבים בתוכניות הוא בהחלט נוח. עם זאת, בשל המורכבות של המבנה שלהם, רצוי מאוד להיות מסוגל להציג אותו בצורה נאותה בשלב ניפוי הבאגים. ב-debuggers של Fiton, ניתן להציג אובייקטים מורכבים הן בצורה דחוסה (רשימת ערכי אלמנטים) והן בצורה מורחבת, תוך ציון הכתובת, הערך והסוג של כל אלמנט מערך ו/או איבר מבנה. הטמעת מצביעים במהדרים שונים שונה. העובדה שלחבר הכנסת יש בדרך כלל מספר מרחבי כתובת יוצרת קשיים נוספים, שכן בעבודה עם מצביע, בנוסף לכתובת, יש להכיר את מרחב הכתובות אליו מצביע המצביע. ביישומים מסוימים, מזהה מרחב הכתובות הוא חלק מערך המצביע; באחרים, המהדר "יודע" זאת מראש ומייצר את הקוד המתאים. בנוסף, רכיב הכתובת במצביע יכול להיות בגודל של 8 עד 32 סיביות. בעת הצגת ערכי מצביע, מאתר הבאגים חייב "לדעת" את כל הפרטים של היישום שלהם בכל מהדר. שיטות מיקום חפצים בזיכרון בנוסף לאובייקטים סטטיים, שכתובותיהם אינן משתנות במהלך ביצוע התוכנית, בתוכנית הכתובה בשפה ברמה גבוהה, יתכנו מה שנקרא אובייקטים אוטומטיים, שזיכרון עבורם מוקצה באופן זמני במחסנית הח"כ. . הכתובות של אובייקטים כאלה אינן מוחלטות, אלא נקבעות באופן דינמי בשלב ביצוע התוכנית. הם נמדדים בדרך כלל מהערך הנוכחי של משתנה סטטי כלשהו הנקרא מצביע מחסנית (Base Pointer או BP). מכיוון שהערך של BP נוצר באופן דינמי על ידי התוכנית בזמן ריצה, הערכים של אובייקטים אוטומטיים זמינים רק בהיקף שלהם, כלומר עם ערך BP חוקי. מאתר הבאגים, בעת הצגת הערכים של אובייקטים אוטומטיים, חייב "לדעת" את הדרך שבה כתובות נקבעות, כמו גם לפקח על נכונות ערך ה-BP כמו כן, ניתן להציב באופן זמני משתנים בפנקסי ח"כים. במקרה זה, על ה-debugger "לדעת" אילו משתנים ממוקמים באילו רגיסטרים ולכמה זמן. ולבסוף, לעתים קרובות יש מצב שבו אותו אובייקט במהלך חייו משנה את האופן שבו הוא ממוקם בזיכרון, ולא פעם. זה יכול לקרות, למשל, כאשר פונקציה מקבלת פרמטר אחד או יותר באוגרים ואז דוחפת אותם אל המחסנית. שדה נראות של אובייקט כמו בתוכניות אסמבלר, לתוכניות C יש אובייקטים גלובליים הנגישים לפי שם מכל מודול, ואובייקטים הממוקמים במודול (אובייקטים אלו מוכרזים סטטיים). עם זאת, משתנים אוטומטיים ומשתנים רישום מקשים על מאפי הבאגים להציג את הערכים שלהם. העובדה היא. ראשית, משך חייו של אובייקט אוטומטי מוגבל על ידי היקפו, ושנית, לטווחים מקיפים יכולים להיות אובייקטים אוטומטיים משלהם עם אותם שמות. הבה נמחיש זאת באמצעות דוגמה לפונקציה שיש לה מספר היקפים מקוננים: המשתנה בשם "a" קיים כל עוד הפונקציה f מבוצעת, אך בהתאם לאיזה חלק של הפונקציה מבוצע, השם "a" מייצג משתנים שונים. בעת מעקב אחר הפונקציה f, מאתר הבאגים חייב, בהתאם לאיזה משתנה פעיל, להציג נכון את ערכו. בעת יצירת תוכנית, למפתח לא אכפת מהפרטים של יישום המושגים שבהם השתמש בתוכנית. במונחים של קטגוריות "מובן מאליו", הוא לרוב אינו חושד עד כמה היה קשה למפתחי מהדרים וניפוי באגים ליישם אותם. האחרונים צריכים לפתור את הבעיה של שילוב במעטפת אחת בו זמנית ממשק פשוט ואינטואיטיבי, שפע של פונקציונליות ולימוד מפורט של כל מה שקשור ליישום תכונות הארכיטקטורה ותפקוד של חבר כנסת מסוים. אם מאתר הבאגים אינו מספק למפתח כלי איתור באגים המתאימים למורכבות הבעיה הנפתרת, אזי המפתח מאבד בהכרח את הפרודוקטיביות. מי מאיתנו לא נאלץ לבלות שעות וימים בחיפוש אחר שגיאה מעצבנת או שגיאת הקלדה בטקסט המקור?! בתהליך הפיתוח והיצירה של מערכת מיקרו-מעבד, במוקדם או במאוחר מגיע הרגע שבו היא סוף סוף מתגלמת בחומרה ומתחילה להראות סימני חיים. עם זאת, ברוב המקרים הסימנים הללו מתגלים כבלתי צפויים, המערכת מתחילה לחיות את חייה. מתכנתים רבים כנראה יסכימו שכל תוכנה חדשה מכילה באגים. זו גם הסיבה שבהתחלה חבר הכנסת החדש מתנהג כמו קופסה "שחורה". על מנת להקל על תהליך איתור באגים במערכות, פותחה מחלקה שלמה של כלים. מטרתם העיקרית היא להפוך את תהליך התפקוד של חבר הכנסת שנופתה באגים "שקוף", כלומר, נשלט בקלות, נשלט באופן שרירותי ומשתנה לפי רצונו של היזם. ערכת כלים מקצועית טובה יכולה בנוסף לספק למפתח שירותים רבים, ובכך להקל מאוד על עבודתו, ולבטל את הפעולות השגרתיות. כלי ניפוי באגים עיקריים כוללים אמולטורים בתוך המעגל, סימולטורי תוכנה, לוחות פיתוח (לוחות הערכה), צגי איתור באגים ואמולטורים של ROM. ישנם גם מכשירים וסטים משולבים. אמולטורים במעגל אמולטור במעגל (ICE) הוא כלי חומרה-תוכנה שיכול להחליף מעבד מדומה במכשיר אמיתי. VSE הוא כלי איתור באגים החזק והרב תכליתי. מבחינה פונקציונלית, VEs מחולקים לאלו המחוברים למחשב חיצוני (בדרך כלל מחשב תואם IBM) ופועלים באופן אוטונומי. לאחרונים יש משאבי מחשוב משלהם ומתקני קלט/פלט, לכן, ביכולות שוות, הם הרבה יותר יקרים מהראשונים, ובאותו המחיר, הם נחותים מהם משמעותית מבחינת פונקציונליות ויכולות שירות. עם איתור באגים של המערכת, ה-VSE מחובר בדרך כלל באמצעות כבל לראש אמולציה מיוחד. לאחרונה, יחסית, הופיעו דגמי VSE שבהם ראש כזה משולב מבני עם היחידה הראשית ומוכנס למערכת המנוגדת באגים במקום ל-MK. אם לא ניתן להסיר את האחרון (הפינים מולחמים ללוח), השימוש ב-VSE מותר, בתנאי שלMC זה יש מצב ניפוי בו כל הפינים שלו נמצאים במצב השלישי (עכבה גבוהה). במקרה זה, כדי לחבר את ה-VSE, נעשה שימוש במתאם קליפ מיוחד, המחובר ישירות ליציאות של ה-MK המדומה. הכי פחות. VSE מכיל באגים, צומת אמולציה של MK. זיכרון אמולציה ותת-מערכת נקודות שבירה. TSEs מתקדמים יותר עשויים לכלול בנוסף מעקב, מעבד נקודת שבירה, פרופילר (נתח יעילות קוד תוכנית), טיימר בזמן אמת, כלי תוכנה וכלי חומרה המאפשרים לך לקרוא ולשנות את המשאבים של המעבד המדומה "בתנועה" , כלי תוכנה וחומרה המספקים ניהול סינכרוני והכרחי לאמולציה במערכות ריבוי מעבדים, סביבת פיתוח משולבת. ה-debugger הוא מעין גשר בין המפתח לכלי ה-debugging. מאתר באגים טוב מבטיח שהתוכנות הנפותות נטענות לזיכרון המערכת, הסטטוסים והתכנים של כל הרגיסטרים והזיכרון (ובמידת הצורך, השינויים שלהם) מוצגים על הצג, ותהליך האמולציה נשלט. מאפי באגים חזקים יותר (המכונים בדרך כלל מאפי באגים ברמה גבוהה או ברמה גבוהה) מאפשרים זאת גם כן.
ניפוי באגים כזה מאפשר למשתמש לשלוט בו זמנית בהתקדמות התוכנית ולראות את ההתאמה בין טקסט המקור, תמונת התוכנית בקודי מכונה ומצב כל המשאבים של המיקרו-בקר המדומה. יש לציין ש-debugger ברמה גבוהה מספק את הביצועים של כל הפונקציות שלו רק אם נעשה שימוש ב-cross-compiler המספק מידע ניקוי באגים מלא ונכון (לא כל המהדרים, במיוחד הגרסאות הפיראטיות שלהם, מסוגלים לכך), וב- באותו זמן הפורמט של המצגת שלו "מוכר" למאתר הבאגים. זיכרון אמולציה משמש בתהליך איתור הבאגים במקום ה-ROM של המערכת המפותחת. יתר על כן, זה מאפשר לך לנפות באגים בתוכנית בהיעדר מערכת אמיתית או הפריסה שלה. אם אתה צריך לערוך שינויים בתוכנית שניתנה באגים, מספיק לטעון תוכנית חדשה או שונה לזיכרון האמולטור, במקום לתכנת מחדש את ה-ROM. יש VSE. המאפשרים למשתמש "להחליף" זיכרון אמולציה במקום ROM לא רק בשלמותו, אלא גם בלוק אחר בלוק (בדגמים מסוימים, גודל הבלוק המינימלי הוא 1 בייט). לפי הסדר שצוין על ידי המשתמש. לשם כך, די לו להגדיר את התפלגות זיכרון הנתונים וזיכרון התוכנות, לפיה המעבד ייגש הן לתוכן ה-ROM במערכת המנוגדת באגים והן לתוכן זיכרון האמולציה של ה-TSE. זיכרון כזה נקרא בדרך כלל זיכרון עם אפשרות למיפוי. ה-Tracer הוא מנתח לוגי שפועל באופן סינכרוני עם המעבד ולוכד את זרימת ההוראות המתבצעות ואת מצב האותות החיצוניים שנבחרו. ישנם VSEs המאפשרים מעקב לא רק אחר אותות חיצוניים, אלא גם את מצבי המשאבים הפנימיים של ה-MC. למשל רושמים. במכשירים כאלה משתמשים בגרסאות מיוחדות של MK (גבישים אמולציה). מעבד ה-breakpoint מאפשר לעצור את ביצוע התוכנית או לבצע פעולות אחרות (לדוגמה, התחל או עצירה של ה-Tracer) כאשר מתקיימים תנאים שצוינו על-ידי המשתמש, בניגוד למנגנון ה-breakpoint הרגיל, המעבד מאפשר ליצור ולעקוב אחר תנאים של כמעט כל מורכבות ברמת החומרה, תוך כדי חיקוי התהליך אינו נגזר מקנה המידה של זמן אמת. בחלק מדגמי VSE, ניתן להשתמש במעבד נקודת השבירה לשליטה דינמית על הנותב. הפרופיל (Programmer Code efficiency Analyser) מאפשר, בהתבסס על תוצאות הפעלת התוכנה שנוגדה באגים, לקבל מידע על מספר הקריאות לחלקים שונים של התוכנית והזמן המושקע בביצוען. ניתוח המידע הסטטיסטי שסופק על ידי הפרופיל מאפשר לזהות קטעים "מתים" או לחוצים יתר על המידה של תוכניות, וכתוצאה מכך, לייעל את מבנה התוכנית הנפתלת. סביבת פיתוח משולבת היא קבוצה של כלי תוכנה התומכים בכל שלבי פיתוח התוכנה מכתיבת קוד המקור של תוכנית ועד להידור וניפוי באגים שלה, ומספקת אינטראקציה פשוטה ומהירה עם סימולטור-סימולטור תוכנה ומתכנת. נוכחותם של עורך מובנה, מנהל פרויקטים ומערכת בקרה במעטפת התוכנה VSE מקלה מאוד על עבודתו של היזם, וחוסכת ממנו הרבה פעולות שגרתיות. מבחינתו, הגבול בין כתיבת תוכנית, עריכתה וניפוי באגים מטושטש. המעבר מעריכת טקסט מקור לאיפוי באגים ולהיפך מתבצע "שקוף" וסנכרוני עם הפעלת החלונות המתאימים. מנהל הפרויקטים מתחיל באופן אוטומטי את ההידור לפי הצורך ומפעיל את חלון ממשק התוכנית המתאים. אתה יכול באותה קלות להמשיך לאיתור באגים בפרויקט באמצעות מאפר הבאגים הקיים של הסימולטור או להתחיל להבהב את ה-ROM עם תוכנית שפותחה באגים. חלק מה-ITUs מספקים למשתמשים תכונות נוספות אחרות. ביניהם, יש לציין במיוחד אחד, אם כי די ספציפי, אך במקרים מסוימים בעל חשיבות עקרונית, את היכולת לבנות מתחמי ריבוי אמולטורים הנחוצים לאיתור באגים במערכות מרובות מעבדים. מאפיין ייחודי של קומפלקס כזה הוא הבקרה הסינכרונית (ממחשב אחד ) של כמה אמולטורים. במקרה הכללי, יכולתו של ה-TSE לשלוט ולנהל את תפקודם של התקנים שפותחו באגים יכולה להיות מוגבלת (לדוגמה, טיפול שגוי בפסיקה במצב צעד, איסור על שימוש ביציאה טורית וכו'). כמו כן, יש לזכור שלכל דגם VSE יש רשימה משלו של מיקרו-בקרים ומהדרים נתמכים. עם זאת, עבור רוב המיקרו-בקרים הפופולריים, פותחו VSEs שאין להם הגבלות על השימוש במשאבים של גבישים שפותחו באגים. נמחיש את האפשרויות של ESS כזה באמצעות דגם PICE-51 של חברת Fiton כדוגמה. PICE-51 הוא התקן שנוצר באמצעות IC לוגי ניתן לתכנות (FPGA). זה איפשר להקטין באופן דרסטי את גודל ה-VSE, למזער את הסטיות של מאפייני החשמל והתדר שלו מהמאפיינים של ה-MC המדומה, ובכך להשיג דיוק אמולציה מקסימלי בתדרים של עד 33 מגה-הרץ במתחי אספקה מ-3,3 עד 5 וולט. חיקוי של כמעט כל חברי הכנסת ממשפחת MCS-51. תמיכת תוכנה פועלת בסביבת Windows. PICE-51 מורכב מלוח ראשי, מתאם להחלפה לקבוצת MK ספציפית וראש אמולציה להחלפה גם לסוג מארז ספציפי. על הלוח הראשי מורכבים טריסר ומעבד נקודת שבירה, ומעבד מחקה לסוג מסוים של MK מותקן על לוח המתאם הניתן להחלפה. ראשי האמולציה מאפשרים להתקין את המכשיר בשקעי DIP ו-PLCC בלוח המשתמש. הספק מסופק מבלוק עם מתח מוצא של +5 V (0,5 A) או ממכשיר שנמצא באגים. התקשורת עם מחשב היא באמצעות ערוץ RS-232C מבודד גלווני במהירות של 115 kbaud. תכונות ויכולות אחרות של PICE-51 הן כדלקמן:
מגוון רחב כל כך של פונקציונליות הופך את VSE לכלי איתור באגים החזק והרב-תכליתי. סימולטורים סימולטור - כלי תוכנה שיכול לדמות את פעולת הח"כ והזיכרון שלו. בדרך כלל, הוא מורכב ממאתר באגים, דגם CPU וזיכרון. מכשירים מתקדמים יותר מכילים דגמים של התקנים היקפיים מובנים (טיימרים, יציאות, ADCs ומערכות פסיקה). הסימולטור צריך "להיות מסוגל" לטעון קבצי תוכניות בכל הפורמטים הפופולריים, להציג מידע על מצב המשאבים של המיקרו-בקר המדומה בצורה מלאה ככל האפשר. וגם לספק הזדמנויות להדמיית ביצוע התוכנית הטעונה במצבים שונים. במהלך איתור באגים, המודל מריץ את התוכנית, והמצב הנוכחי של הדגם מוצג על מסך צג המחשב. על ידי טעינת התוכנית לסימולטור. המשתמש יכול להפעיל אותו במצב שלב אחר שלב או במצב רציף, להגדיר נקודות שבירה מותנות או בלתי מותנות, לשלוט ולשנות באופן חופשי את התוכן של תאי הזיכרון והרגיסטרים של המיקרו-בקר המדומה. הסימולטור מאפשר לך לבדוק במהירות את ההיגיון של ביצוע התוכנית, את נכונותן של פעולות אריתמטיות. בהתאם לסוג מאתר הבאגים בשימוש, דגמי סימולטור מסוימים תומכים בניפוי שגיאות סימבולי ברמה גבוהה של תוכניות. הסימולטור עשוי להכיל גם מספר כלי תוכנה נוספים, כגון ממשק סביבה חיצונית. הנוכחות של ממשק כזה מאפשרת לך ליצור ולהשתמש בגמישות במודל של הסביבה החיצונית של ה-MC. תפקוד ומשפיע על תוכנית ניפוי באגים לפי אלגוריתם נתון. במערכת אמיתית, ה-MC בדרך כלל "עסוק" בקריאת מידע מהתקנים חיצוניים (חיישנים) המחוברים אליו, בעיבודו ובהוצאת אותות בקרה למפעילים. על מנת לדמות פעולת חיישן בסימולטור פשוט, צריך לשנות באופן ידני את המצב הנוכחי של הדגם של המכשיר ההיקפי אליו מחובר החיישן במערכת אמיתית. אם, למשל, בעת קבלת בייט דרך יציאה טורית, מוגדר דגל מסוים, והבית עצמו נופל לתוך אוגר מסוים, אז שתי הפעולות הללו חייבות להתבצע באופן ידני בסימולטור. בחלק מהדגמים הבעיה הזו נפתרת: לסימולטורים יש כלים מובנים ליצירת מודלים של מכשירים חיצוניים המחוברים ל-MK, כולל כלים לתצוגה גרפית של מידע. מאפיין ברור של סימולטורי תוכנה הוא זה שהתוכנות הנטענות בהן מבוצעות בסולם זמן שאינו זמן אמת. עם זאת, המחיר הנמוך, היכולת לבצע ניפוי באגים גם בהיעדר דגם של המכשיר הנפתל, הופכים את סימולטורי התוכנה לכלי איתור באגים אטרקטיבי ביותר. כמו כן, יש לציין כי יש מחלקה שלמה של שגיאות שניתן לזהות רק באמצעות סימולטור. מנחי ניפוי באגים צג ניפוי באגים הוא תוכנית מיוחדת הנטענת לזיכרון של המערכת שניתקה באגים. זה מאלץ את חבר הכנסת לבצע, בנוסף למשימה המיושמת, גם פונקציות ניפוי באגים:
תוכנית המוניטור פועלת "בשילוב" עם מחשב או טרמינל פסיבי, עליו מתבצעת ההדמיה והבקרה של תהליך איתור הבאגים. היתרון של גישה זו
מועצות פיתוח לוחות פיתוח, או כפי שהם נקראים בדרך כלל בספרות זרה, לוחות הערכה (Evaluation Boards). - בנאים מקוריים ליצירת אב טיפוס של מערכות יישומיות. לאחרונה, חברות ייצור רבות, משחררות דגמים חדשים של MK. הצעות ולוחות פיתוח מתאימים. לרוב מדובר במעגל מודפס שעליו מותקן MK וכל האלמנטים הדרושים לפעולתו הרגילה וכן במערכות תקשורת עם מחשב. ככלל, הלוח מספק מקום פנוי להרכבת מכשיר המשתמש המפותח. לעיתים קיים גם "חיווט" מוכן להתקנת מכשירים נוספים המומלצים על ידי החברה (ROM, RAM, תצוגת LCD, מקלדת, ADC וכו'). לוחות ששונו על ידי המשתמש יכולים לשמש בצורה מועילה בתור בקרי לוח יחיד המובנים במוצרים בקנה מידה קטן (5...20 יח'). לנוחיות המשתמש, לוחות הפיתוח מצוידים גם בכלי איתור באגים פשוט המבוסס על צג ניפוי הבאגים. עלו כאן שתי גישות שונות: האחת משמשת לחבר כנסת. שיש אוטובוס חיצוני, והשני - לח"כים שאין להם. במקרה הראשון, צג ניפוי הבאגים מסופק כשבב ROM. אשר מותקן בשקע מיוחד על לוח הפיתוח. ללוח יש גם זיכרון RAM עבור תוכניות משתמש וערוץ תקשורת עם מחשב או מסוף. דוגמה לכך היא לוח הפיתוח שפיתחה אינטל עבור משפחת MK MCS-51. במקרה השני, לוח הפיתוח מכיל מערכות תכנות מובנות עבור ה-ROM הפנימי של ה-MK. אשר נשלטים על ידי מחשב. תוכנית המוניטור מוזנת ל-ROM של הח"כ יחד עם האפליקציה שהוכנה בהתאם (קריאות של שגרות ניפוי הבאגים של המוניטור מוכנסות במקומות הנכונים). לאחר מכן מתבצעת ריצת מבחן. כדי לבצע תיקונים לתוכנית שניתקה באגים, היא נמחקת מה-ROM והמתוקנת נכתבת בה. תוכנית היישום המוגמרת מתקבלת מהתוכנית שפותחה באגים על ידי הסרת הצג וכל הקריאות לפונקציות שלו. לוחות פיתוח עבור חברי כנסת של משפחות PIC-micro (Microchip), 80C750 (Philips), 89C2051 (Atmel) מיועדים לאלגוריתם באגים שכזה. לוחות פיתוח מצוידים לעיתים בתוכנות איתור באגים הפועלות על מחשב חיצוני "בשילוב" עם צג. תוכניות אלו הפכו לאחרונה למורכבות יותר באופן ניכר ולעתים קרובות יש להן מערך מקצועי ביותר של פונקציות ניפוי באגים (לדוגמה, סימולטור באגים) או אלמנטים שונים הטבועים רק בסביבות פיתוח משולבות בצורתם הטהורה. הערכות עשויות לכלול גם תוכניות יישומיות שבהן נתקלים לרוב בפועל. יכולות איתור הבאגים של ערכת "לוח פיתוח פלוס צג" אינן אוניברסליות כמו אלו של ESS. בנוסף, חלק ממשאבי MC בתהליך איתור באגים נבחרים כדי שהצג יפעל. עם זאת, הזמינות של סט שלם של כלי תוכנה וכלי חומרה מוכנים המאפשרים לך להתחיל בהתקנה וניפוי באגים של המערכת המיושמת ללא אובדן זמן היא במקרים רבים גורם מכריע. במיוחד כשחושבים שערכה כזו עולה פי כמה פחות מאמולטור רב תכליתי יותר. אמולטורים של רום אמולטור ROM הוא כלי תוכנה וחומרה המאפשר לך להחליף את ה- ROM של ההתקן שפותח באגים ב-RAM. שלתוכו תוכל להוריד את התוכנית מהמחשב שלך דרך אחד מערוצי התקשורת הסטנדרטיים. זה מאפשר למשתמש להימנע ממחזורים מרובים של הבהוב ROM. אמולטור ה-ROM משמש רק לאיתור באגים בתוכניות MK המסוגלות לגשת לזיכרון תוכניות חיצוני. מבחינת מורכבות ועלות, המכשיר הזה דומה ללוחות פיתוח. יש לזה יתרון אחד גדול - רבגוניות. אמולטור ה-ROM יכול לעבוד עם כל חבר כנסת. אמולטורי ה-ROM הראשונים אפשרו רק לטעון, להפעיל ולהפסיק תוכנית באמצעות איפוס מאסטר. אחר כך היו מודלים מסובכים עם יצירת חומרה של אותות עקבות לאוסילוסקופ כשהם מגיעים לכתובת מסוימת. הזיכרון המדומה במוצרים כאלה היה זמין לצפייה ולשינוי, אך שליטה על אוגרי הבקרה הפנימיים של הח"כ הייתה בלתי אפשרית עד לאחרונה. לאחרונה הופיעו מה שנקרא אמולטור ROM אינטליגנטי. הם מאפשרים לך 'להסתכל' בתוך ה-MC בלוח המשתמש ודומים בבקרת ניפוי באגים ל-VSE. קקטוס אפילו מציגה את אמולטור ה-ROM האינטליגנטי שלה למעשה בתור ה-VSE של סדרת MK, כל כך בלתי אפשרי להבחין בין עבודה עם אחד והשני.למעשה, המעבד במקרה זה אינו מוחלף, ומשתמשים בזה שעל דמי המשתמש. אמולטור ה-ROM החכם הוא הכלאה של אמולטור ה-ROM הרגיל. מוניטור באגים ומערכת למעבר מהיר של האוטובוס מאחד לשני. זה יוצר את האפקט כאילו צג ניפוי הבאגים הותקן על לוח המשתמש, ובמקביל הוא למעשה אינו תופס משאבי חומרה מה-MK, למעט אזור קטן (כ-4 KB) של שלבי תוכנה. אמולטור כזה פותח, למשל, על ידי חברת Fiton עבור כל חברי הכנסת הקיימים והעתידיים שיש להם את ליבת 8051, אך הם רוויים בנוסף בהתקני קלט/פלט שונים. המוצר תומך במכשירי MC רבים ושונים מבית פיליפס, סימנס. OKI. סביבות פיתוח משולבות באופן קפדני, סביבות פיתוח משולבות אינן בין כלי ניפוי הבאגים, עם זאת, יהיה זה שגוי להתעלם ממעמד זה של כלי תוכנה שמקלים ומזרזים מאוד את תהליך הפיתוח והניפוי של מערכות מיקרו-מעבדים. בגישה המסורתית, השלב הראשוני של כתיבת תוכנית נבנה באופן הבא. טקסט המקור מוקלד באמצעות עורך טקסט. עם סיום ההקלדה, העבודה עם עורך הטקסט נעצרת והקומפיילר המוצלב מתחיל. ככלל, תוכנית חדשה מכילה שגיאות תחביר, והמהדר מדווח עליהן למסוף המפעיל. ואז עורך הטקסט מופעל שוב, והמפעיל מחפש ומבטל את השגיאות שזוהו. יחד עם זאת, הודעות על טיבן, המוצגות על ידי המהדר, אינן נראות עוד, מכיוון שהמסך תפוס על ידי עורך טקסט. מחזור זה עשוי לחזור על עצמו יותר מפעם אחת. ואם התוכנית מורכבת יחסית, מורכבת מחלקים שונים, נתונה לעריכה או מודרניזציה, אז גם שלב ראשוני זה עשוי לדרוש מאמץ וזמן רב של המתכנת. כדי להימנע מכמות גדולה של עבודה שגרתית ובכך להגדיל משמעותית את הפרודוקטיביות של מתכנת, מה שנקרא סביבות הפיתוח המשולבות (קונכיות) של הפיתוח (Integrated Development Environment IDE) שהופיעו וצוברות פופולריות במהירות מאפשרות. ככלל, סביבה משולבת טובה משלבת את כלי ניפוי הבאגים הזמינים (אמולטור במעגל, סימולטור תוכנה, מתכנת) ומספקת למתכנת טקסטים של תוכנית בסגנון "טורבו". הסביבה המשולבת מאפשרת:
לאחרונה, הפונקציות של סביבות פיתוח משולבות הפכו לחלק מממשקי התכנות של האמולטורים והסימולטורים ה"מתקדמים" ביותר. פונקציונליות כזו, בשילוב עם ממשק ידידותי, מזרזת משמעותית את עבודתו של המתכנת. לפיכך, בבחירת כלי איתור באגים, מומלץ לקחת בחשבון את קבוצת האינדיקטורים הבאה: רשימת המיקרו-בקרים הנתמכים, הגבלות על המשאבים של מיקרו-בקרים ממולאים/מדומים, אפשרות של איתור באגים סמלי, רשימת המהדרים הנתמכים, וכן, לבסוף, יכולות שירות. מחברים: Yu.Zobnin, Sh.Kobakhidze, מוסקבה ראה מאמרים אחרים סעיף מיקרו-בקרים. תקרא ותכתוב שימושי הערות על מאמר זה. חדשות אחרונות של מדע וטכנולוגיה, אלקטרוניקה חדשה: התמצקות של חומרים בתפזורת
30.04.2024 ממריץ מוח מושתל
30.04.2024 תפיסת הזמן תלויה במה מסתכלים
29.04.2024
עוד חדשות מעניינות: ▪ אופניים חשמליים של Himiway דגמי פוני, Rambler ו-Rhino ▪ יתושים מהונדסים גנטית בטוחים עדכון חדשות של מדע וטכנולוגיה, אלקטרוניקה חדשה
חומרים מעניינים של הספרייה הטכנית החופשית: ▪ חלק של האתר תחבורה אישית: יבשה, מים, אוויר. מבחר מאמרים ▪ מאמר שיער על הקצה. ביטוי עממי ▪ מאמר מדוע צ'ובקה לוותה ביערות קליפורניה על ידי עוזרים בחליפות בהירות? תשובה מפורטת ▪ מאמר טעינה ופריקה של מטענים שונים באמצעות מנופים. הוראה סטנדרטית בנושא הגנת העבודה ▪ מאמר מחולל תדרים לטאטא. אנציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל ▪ מאמר סירנה אלקטרונית דו-גוונית. אנציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל כל השפות של דף זה בית | הספרייה | מאמרים | <font><font>מפת אתר</font></font> | ביקורות על האתר www.diagram.com.ua |