תפריט English Ukrainian רוסי עמוד הבית

ספרייה טכנית בחינם לחובבים ואנשי מקצוע ספריה טכנית בחינם


אינציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל
ספרייה חינם / ערכות של מכשירים רדיו-אלקטרוניים וחשמליים

מיקרו-בקרים למתחילים ומעלה. אנציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל

ספריה טכנית בחינם

אנציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל / מיקרו-בקרים

הערות למאמר הערות למאמר

פגישה ראשונה

ראשית, כמה מילים למי שנושא המחזור, אם לשפוט לפי כותרתו, נראה אפריורי לא מעניין או "זר". אולי עדיין לא השתמשת במיקרו-בקרים בעיצובים שלך (להלן 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? בקצרה, הם כדלקמן:

  • אין צורך לדאוג לגבי פעולות עם מספרים של קיבולת גדולה. המהדר יפיק אוטומטית את הקוד הנכון לפעולת a+b. אם a ו-b הם מספרים של 8, 16, 32 סיביות, מספרי נקודה צפה ומספרים זוגיים מסוגים שונים;
  • המהדר מגיע עם ספרייה נרחבת של פונקציות (תתי שגרות) המיישמות פעולות מתמטיות שונות (פונקציות טריגונומטריות, אקספוננציה וכו'). עבודה עם מחרוזות תווים, קלט/פלט מעוצב וכו';
  • שגיאות מתכנתים רבות מאובחנות על ידי המהדר: למשל, זה לא יאפשר לך להעביר מספר שגוי של פרמטרים או פרמטרים מהסוגים הלא נכונים לפונקציה, לשכוח לשים משפט return וכו';
  • קוד המקור שנכתב ב-C הוא הרבה יותר קל לקריאה, קומפקטי יותר, קל יותר לשינוי;
  • תוכניות שנכתבו ב-C. מועברים ביתר קלות לח"כים של משפחות אחרות.

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

  • המהדר חייב לספק מידע מספיק על מבנה התוכנית והנתונים שבהם היא משתמשת. מידע זה נקרא סימבולי (ניפוי באגים);
  • מאתר הבאגים חייב להיות מסוגל לפרש מידע זה. כל המהדרים והמרכיבים המודרניים מייצרים מידע סמלי בצורה כזו או אחרת, אך עדיין לא פותח פורמט אוניברסלי, וכל מהדר מייצר אותו בפורמט שלו. זה יוצר קשיים נוספים עבור מאפי באגים שחייבים להיות מסוגלים "להבין" מספר פורמטים של תווים.

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

מעקב אחר ביצוע התוכנית על פי טקסט המקור שלה

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

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

הצגת נתונים בשימוש בתוכנית באגים

לצורך איתור באגים מלא, המפתח צריך להיות מסוגל לראות את הנתונים שתופעלו על ידי התוכנית בכל עת. מאתר הבאגים חייב "להיות מסוגל" להציג כל נתונים המשמשים את התוכנית בצורה המתאימה ביותר.

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

נתונים בתוכניות הרכבה

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

  • שם אובייקט:
  • כתובת האובייקט בזיכרון;
  • מרחב כתובת MK בו נמצא האובייקט. למיקרו-בקרים רבים יש יותר מאזור נתונים אחד. לדוגמה, למשפחת MCS-51 יש זיכרון נתונים פנימי, זיכרון נתונים חיצוני ושטח סיביות;
  • ה-bitness של האובייקט, כלומר מספר הבתים שהוא תופס. מיקרו-בקרים של 16 סיביות, כגון חברי משפחת MCS-96, "יודעים כיצד" להפעיל 8-. 16-. נתונים של 32 סיביות. יש לציין כאן נקודה חשובה אחת. למפתח חשוב מהו הגודל הלוגי של האובייקט. לדוגמה, MK שמונה סיביות ממשפחת ה-PIC (Microchip) מפעילים בתים בלבד. אם יש צורך בתוכנית, למשל, מונה של 16 סיביות, אז יש לתפעל כל בייט בנפרד. אבל בעת איתור באגים, המתכנת רוצה לראות לא כל בייט של המונה בנפרד, אלא את שני הבייטים בו-זמנית, בצורה של משתנה של 16 סיביות. צולב-אסמבלים פופולריים אינם מספקים הזדמנות כזו. היוצא מן הכלל הוא ה-PASM-PIC Cross-assembler מבית Fiton, המאפשר לך להצהיר בתוכנית נתונים על גודל בתים, מילה, מילה כפולה, כמו גם מערכים של אובייקטים כאלה. בעת איתור באגים בתוכניות שנכתבו עם PASM-PIC. כל האובייקטים מוצגים בצורה התואמת לגודלם ולמבנה ההגיוני שלהם;
  • היקף האובייקט. אם התוכנית מורכבת ממספר מודולים, למתכנת יש הזדמנות להתאים את היקף השם בתוך מודול אחד. לפיכך, במודולים שונים יכולים להיות אובייקטים עם אותם שמות, אבל תכונות אחרות שונות. מאתר הבאגים צריך "להבין" איזה אובייקט פעיל ולהציג אותו בצורה נכונה. עם זאת, שימו לב שהתרגול של שימוש באותם שמות במודולים שונים מוביל לעיתים קרובות לבלבול ולשגיאות. אם האובייקט מוכרז גלובלי (PUBLIC) והוא גלוי בכל המודולים, אין קשיים בפרשנות.

עם המידע הנ"ל, על ה-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, באמצעות מידע מיוחד שסופק על ידי המהדר, "יודע" את הכתובות של כל המשתנים, המערכים והמבנים הסמליים). במקרה זה, המשתמש יכול לפעול עם שמות סמליים מקובלים יותר על אדם, מבלי לטרוח לזכור את הכתובות שלו;
  • לשלוט ולנתח לא רק טקסט מפורק, אלא גם את קוד המקור של תוכנית שנכתבה בשפה ברמה גבוהה, ואפילו עם הערות משלה.

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

יש לציין ש-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 הן כדלקמן:

  • אמולציה מדויקת - היעדר הגבלות כלשהן על השימוש על ידי תוכנית המשתמש במשאבי MK;
  • עד 256 קילו-בייט של זיכרון תוכניות ונתונים מדומים. תמיכה במודל זיכרון בנקאי. הקצאת זיכרון בין ה-ESS למכשיר המשתמש בדיוק של 1 בייט;
  • עד 512K נקודות שבירה של חומרה לגישה לתוכניות ונתונים,
  • תמיכת חומרה עבור תוכניות איתור באגים בשפות ברמה גבוהה;
  • מעקב אחר שמונה אותות חיצוניים שרירותיים;
  • ארבע יציאות סנכרון של ציוד משתמש;
  • מעקב בזמן אמת עם מאגר של 16 עד 64K פריימים (מערכים) של 64 סיביות עם גישה מהירה. כתובת מעקב, נתונים, אותות בקרה, טיימר בזמן אמת ושמונה אותות משתמש חיצוניים;
  • מסנן עקבות ניתן לתכנות;
  • מעבד נקודת שבירה של חומרה עם יכולת להגדיר מצב עצירה מורכב של אמולציה על ידי שילוב של כתובת, נתונים, בקרה, שמונה אותות חיצוניים, טיימר בזמן אמת, מוני אירועים וטיימר השהייה:
  • ארבע נקודות שבירה מורכבות שניתן להשתמש בהן באופן עצמאי או בשילובים עבור תנאי AND / OR / IF-THEN;
  • טיימר 48 סיביות בזמן אמת;
  • אמולציית "שקופה" - גישה "בתנועה" לזיכרון המדומה, נקודות עצירה, מעבד נקודת שבירה, חיץ מעקב, טיימר בזמן אמת;
  • מחולל שעון מבוקר עבור MK המדומה. היכולת לשנות אותו בצורה חלקה מ-500 קילו-הרץ ל-40 מגה-הרץ;
  • מערכת מובנית של אבחון עצמי של ציוד VSE. נתמך בפיתוח תוכניות ברמת ניהול פרויקטים עבור מרכיב המאקרו МСА-51 ("Fiton"/"Microcosm"), וכן עבור חבילות של כלים צולבים מ- Keil Software ו- IAR Systems;
  • תמיכה באיתור באגים סימבולי מלא של תוכניות שנוצרו באמצעות המהדרים הבאים: אסמבלר ASM51 מבית אינטל, מהדר PL/M מבית אינטל, מרכיבים ומהדרים C מבית Avocet Systems. היי-טק. תוכנת משימות;
  • שמירה וטעינה אוטומטית של קבצי תצורת חומרה, אפשרויות ממשק ואיתור באגים. הבטחת תאימות של קבצי תצורה לסימולטור PDS-51 וניידות של פרויקטים בין PICE-51 לסימולטור PDS-51;
  • היכולת להתאים אישית צבעים, גופנים והגדרות אחרות עבור כל החלונות בו זמנית ולכל חלון בנפרד.

מגוון רחב כל כך של פונקציונליות הופך את VSE לכלי איתור באגים החזק והרב-תכליתי.

סימולטורים

סימולטור - כלי תוכנה שיכול לדמות את פעולת הח"כ והזיכרון שלו. בדרך כלל, הוא מורכב ממאתר באגים, דגם CPU וזיכרון. מכשירים מתקדמים יותר מכילים דגמים של התקנים היקפיים מובנים (טיימרים, יציאות, ADCs ומערכות פסיקה).

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

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

בהתאם לסוג מאתר הבאגים בשימוש, דגמי סימולטור מסוימים תומכים בניפוי שגיאות סימבולי ברמה גבוהה של תוכניות.

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

במערכת אמיתית, ה-MC בדרך כלל "עסוק" בקריאת מידע מהתקנים חיצוניים (חיישנים) המחוברים אליו, בעיבודו ובהוצאת אותות בקרה למפעילים. על מנת לדמות פעולת חיישן בסימולטור פשוט, צריך לשנות באופן ידני את המצב הנוכחי של הדגם של המכשיר ההיקפי אליו מחובר החיישן במערכת אמיתית. אם, למשל, בעת קבלת בייט דרך יציאה טורית, מוגדר דגל מסוים, והבית עצמו נופל לתוך אוגר מסוים, אז שתי הפעולות הללו חייבות להתבצע באופן ידני בסימולטור. בחלק מהדגמים הבעיה הזו נפתרת: לסימולטורים יש כלים מובנים ליצירת מודלים של מכשירים חיצוניים המחוברים ל-MK, כולל כלים לתצוגה גרפית של מידע.

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

מנחי ניפוי באגים

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

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

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

  • עלויות נמוכות מאוד תוך שמירה על יכולת ניפוי באגים בזמן אמת, החיסרון העיקרי;
  • הסחת דעת של משאבי MK לצורך איתור באגים ותקשורת (המוניטור תופס קצת זיכרון, פסיקות, ערוץ טורי). לאחרונה הופיעו תוכניות שכמעט אינן תופסות את משאבי החומרה של חבר הכנסת (הן יידונו בסעיף "אמולטורים של ROM").

מועצות פיתוח

לוחות פיתוח, או כפי שהם נקראים בדרך כלל בספרות זרה, לוחות הערכה (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

בשנים האחרונות התקדם המחקר המדעי בתחום הנוירוטכנולוגיה ופותח אופקים חדשים לטיפול בהפרעות פסיכיאטריות ונוירולוגיות שונות. אחד ההישגים המשמעותיים היה יצירת ממריץ המוח המושתל הקטן ביותר, שהוצג על ידי מעבדה באוניברסיטת רייס. מכשיר חדשני זה, הנקרא Digitally Programmable Over-brain Therapeutic (DOT), מבטיח לחולל מהפכה בטיפולים על ידי מתן יותר אוטונומיה ונגישות למטופלים. השתל, שפותח בשיתוף מוטיב נוירוטק ורופאים, מציג גישה חדשנית לגירוי מוחי. הוא מופעל באמצעות משדר חיצוני באמצעות העברת כוח מגנו-אלקטרי, ומבטל את הצורך בחוטים ובסוללות גדולות האופייניות לטכנולוגיות קיימות. זה הופך את ההליך לפחות פולשני ומספק יותר הזדמנויות לשיפור איכות החיים של המטופלים. בנוסף לשימוש בטיפול, להתנגד ... >>

תפיסת הזמן תלויה במה מסתכלים 29.04.2024

המחקר בתחום הפסיכולוגיה של הזמן ממשיך להפתיע אותנו בתוצאותיו. התגליות האחרונות של מדענים מאוניברסיטת ג'ורג' מייסון (ארה"ב) התבררו כמדהימות למדי: הם גילו שמה שאנו מסתכלים עליו יכול להשפיע רבות על תחושת הזמן שלנו. במהלך הניסוי, 52 משתתפים עברו סדרה של מבחנים, העריכו את משך הצפייה בתמונות שונות. התוצאות היו מפתיעות: לגודל ולפרטי התמונות הייתה השפעה משמעותית על תפיסת הזמן. סצנות גדולות יותר ופחות עמוסות יצרו אשליה של זמן מאט, בעוד שתמונות קטנות ועמוסות יותר נתנו תחושה שהזמן מואץ. חוקרים מציעים שעומס חזותי או עומס יתר על הפרטים עלולים להקשות על תפיסת העולם סביבנו, מה שבתורו יכול להוביל לתפיסה מהירה יותר של זמן. לפיכך, הוכח שתפיסת הזמן שלנו קשורה קשר הדוק למה שאנו מסתכלים עליו. יותר ויותר קטן ... >>

חדשות אקראיות מהארכיון

רובוטים לכלבים של Ghost Robotics לשמירה על הגבול 12.02.2022

בארצות הברית נעשה שימוש בכלבים רובוטיים לשמירה על הגבולות. רובוטים של כלבי סיור נבדקים בגבול הדרומי של ארצות הברית.

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

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

הפיתוח מובל על ידי זרוע המחקר והפיתוח של DHS, המשרד למדע וטכנולוגיה, המתמחה ברכבי תצפית קרקעיים אוטומטיים (AGSV). המכונות נוצרות על ידי יצרנית הרובוטיקה Ghost Robotics, הידועה ברובוט Ghost Vision 60 שלהם.

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

עוד חדשות מעניינות:

▪ אופניים חשמליים של Himiway דגמי פוני, Rambler ו-Rhino

▪ יתושים מהונדסים גנטית בטוחים

▪ מערכת חדשה לננו-תרנוסטיות

▪ מיטת Balluga: מיטה חכמה

▪ כנסיות האלי

עדכון חדשות של מדע וטכנולוגיה, אלקטרוניקה חדשה

 

חומרים מעניינים של הספרייה הטכנית החופשית:

▪ חלק של האתר תחבורה אישית: יבשה, מים, אוויר. מבחר מאמרים

▪ מאמר שיער על הקצה. ביטוי עממי

▪ מאמר מדוע צ'ובקה לוותה ביערות קליפורניה על ידי עוזרים בחליפות בהירות? תשובה מפורטת

▪ מאמר טעינה ופריקה של מטענים שונים באמצעות מנופים. הוראה סטנדרטית בנושא הגנת העבודה

▪ מאמר מחולל תדרים לטאטא. אנציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל

▪ מאמר סירנה אלקטרונית דו-גוונית. אנציקלופדיה של רדיו אלקטרוניקה והנדסת חשמל

השאר את תגובתך למאמר זה:

שם:


אימייל (אופציונלי):


להגיב:





כל השפות של דף זה

בית | הספרייה | מאמרים | <font><font>מפת אתר</font></font> | ביקורות על האתר

www.diagram.com.ua

www.diagram.com.ua
2000-2024