מה צופן העתיד למיקרו-מעבדים?

מאת: גו’זף ייו, מהנדס מערכת,  ARM

חלק 1 – סקירה

עולם הטכנולוגיות המשובצות משתנה ללא הרף. אולי לא שמתם לב, אבל אם תנסו לרגע להיזכר במערכות המיקרו-בקרים שהיו לפני עשר שנים ותשוו אותן למערכות המיקרו-מעבדים החדשות הקיימות היום, תגלו בוודאי שתכנון ה-PCB, מארזי הרכיבים, רמת האינטגרציה, מהירות השעון וממדי הזיכרון – כל אלה משתנים ומתפתחים חדשות לבקרים. אחד הנושאים החמים ביותר בתחום היא השאלה מתי יחליט אחרון המשתמשים במיקרו-מעבדים של 8 ביט לזנוח את הארכיטקטורות המסורתיות ולעבור גם הוא לארכיטקטורות מעבדי ה-32 ביט המודרניות, כדוגמת משפחת המיקרו-מעבדים המבוססת על ה-ARM Cortex™-M. במהלך השנים האחרונות היינו עדים לתנופה משמעותית של מפתחי טכנולוגיות משובצות שמתחילים לעבור אל המיקרו-בקרים של 32 ביט, ומאמר זה ינסה לבחון כמה מהגורמים המאיצים את המעבר לטכנולוגיות החדשות. 

למה לעבור?

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

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

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

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

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

 בחלקו הבא של המאמר נראה כיצד מיקרו-בקרים של 32 ביט מנצחים במירוץ על ממדי הקוד, תחום שבעבר נחשב לנקודה חזקה במיוחד של המיקרו-בקרים של 8 ביט.

 חלק 2 – ממדי קוד

 גודל הפקודה

אנשים רבים סבורים שמיקרו-בקרים של 8 ביט משתמשים בפקודות של 8 ביט ואילו מיקרו-בקרים של 32 ביט משתמשים בפקודות של 32 ביט.

במציאות, פקודות רבות במיקרו-בקרים של 8 ביט הן בגודל 16 ביט, 24 ביט או גדלים אחרים העולים על 8 ביט, לדוגמה, גודל הפקודה של PIC18 הוא 16 ביט. אפילו עבור ארכיטקטורת ה-8051, פקודות מסוימות הן אמנם באורך בייט אחד, אבל רבות אחרות הן באורך 2 או 3 בייטים. אותו דבר נכון גם לגבי הארכיטקטורות של 16 ביט, לדוגמה, פקודות מסוימות של MSP430 הן באורך 6 בייטים (או אפילו 8 בייטים עבור ה-MSP430X).

המעבדים ARM Cortex-M3 ו-Cortex-M0 מבוססים על טכנולוגיית ה-Thumb®-2, המספקת צפיפות קוד מצוינת. עם טכנולוגיית ה-Thumb-2, המעבדים תומכים במערך הפקודות Thumb הכולל פקודות של 16 ביט כמו גם פקודות של 32 ביט, כאשר הפונקציונליות של פקודת 32 ביט היא מערך-על של גרסת ה-16 ביט. ברוב המקרים מהדר C ישתמש בגרסת ה-16 ביט של הפקודה, אלא אם כן ניתן לבצע את הפעולה רק באמצעות גרסה של 32 ביט. 

איור 1: גודל של פקודה יחידה במעבדים שונים

בתוך תוכנית שעברה הידור עבור מעבדי Cortex-M, כמות הפקודות של 32 ביט היא רק חלק קטן ממספר הפקודות הכולל. לדוגמה, פקודות ה-32 ביט בתמונת תוכנת Dhrystone שעברה הידור עבור מעבד ה-Cortex-M3 הן רק 15.8% מהמספר הכולל של הפקודות (גודל פקודה ממוצע הוא 18.53 ביטים). עבור מעבד ה-Cortex-M0 היחס של פקודות ה-32 ביט הוא אפילו נמוך יותר – רק 5.4% מכלל הפקודות (גודל פקודה ממוצע הוא 16.9 ביטים).

נצילות מערך הפקודות

גם מערך הפקודות Thumb המשמש את מעבדי סדרת ARM Cortex-M הוא יעיל במיוחד. לדוגמה, הריבוי של פקודות load, הריבוי של פקודות store, פקודות stack push ופקודות stack pop (דחיפה ושליפה ממחסנית) במעבדי סדרת Cortex-M – כל זה מאפשר ביצוע של כמה העברות נתונים על-ידי פקודה אחת יחידה. 

שיטות מיעון זיכרון רבות עצמה מאפשרות גם הן ליצור רצפי גישת זיכרון פשוטים יותר על מיקרו-בקרים מבוססי ARM. לדוגמה, ניתן לגשת לזיכרון באמצעות אוגר היסט, היסט מיידי, שיטות מיעון הקשורות ל-PC או למצביע מחסנית (שימושי עבור משתנים מקומיים) בפקודה יחידה. בנוסף ישנן תכונות נוספות כמו כוונון אוטומטי של מצביעי זיכרון. כל מעבדי ARM הם יעילים ביותר בטיפול בנתוני 8 ביט ו-16 ביט. ישנן פקודות קומפקטיות לגישת זיכרון עבור נתוני 8 ביט, 16 ביט ו-32 ביט, מסוג signed ו-unsigned. יש גם כמה פקודות הכלולות באופן מיוחד לצורך המרת סוגי נתונים. באופן כללי הטיפול בנתוני 8 ביט ו-16 ביט עם מעבדי ARM הוא קל ויעיל ממש כמו הטיפול בנתוני 32 ביט.

מעבדי סדרת ARM Cortex-M מספקים גם תכונות חזקות מאוד של ביצוע מותנה. מלבד האפשרויות המקיפות של תנאי הסתעפות (branch) עבור נתונים מסוג signed ו-unsigned, הזמינים על כל המיקרו-בקרים מבוססי ARM, מעבדי ARM Cortex-M3 מספקים גם ביצוע מותנה, ופקודות משולבות של הסתעפות והשוואה (compare) 

גם מעבדי Cortex-M0 וגם מעבדי Cortex-M3 תומכים בפעולת הכפלה של מחזור יחיד של 32 ביט. בנוסף, מעבד ה-Cortex-M3 תומך גם בפעולות של פירוק מספר שלם מסוג signed ו-unsigned, רוויה, ופעולות MAC (כפל-חיבור) של 32 ושל 64 ביט, כמו גם מספר פקודות פעולה של  bit field.

 

מיתוסים סביב יישומי 8 ביט

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

אותו מצב קורה גם במקרה של מצביעים (פוינטרים). ברוב המיקרו-בקרים של 8 או של 16 ביט נחוצים לפחות 16 ביט עבור מצביע כתובות. זה יכול אף לגדול אם משתמשים במצביעי זיכרון גנריים ב-8051 (בגלל המידע הנוסף הנדרש כדי לציין לאיזה זיכרון מתייחסים), או אם משתמשים במעבר בין “בנקים” של זיכרון או בטכניקות דומות כדי להתגבר על המחסום של זיכרון של 64kbytes. כתוצאה מכך, העיבוד של מצביעי זיכרון יכול להיות מאוד בלתי יעיל במערכות של 8 ביט.

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

דוגמה

כיצד, אם כן, באים כל הדברים הללו לביטוי בדוגמה השוואתית? לדוגמה, תוכנית ה-Dhrystone שעברה הידור עבור ארכיטקטורות שונות עם מיטוב ממדים מניבה את התוצאות הבאות:

מיקרו-בקר	SiliconLabs C8051F320	Cortex-M0	Cortex-M3
כלים	Keil µVision 3.8 PK51 8.18	RVDS 4.0-SP2	RVDS 4.0-SP2
גודל פלט בינארי (בייטים)	3186	912	900

 

חלק 2 – סיכום

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

היתרון של ממדי קוד קטנים יותר במיקרו-בקרים של ARM משפיע על הביצועים כמו גם על צריכת ההספק ועל העלויות. בחלקו הבא של המאמר נשווה בין מיקרו-בקרים המבוססים על מעבד ARM Cortex-M לבין מיקרו-בקרים של 8 ביט מההיבטים השונים הללו.

 

חלק 3 – ביצועים וצריכת הספק

אחת הסיבות לכך שרבים ממפתחי היישומים המשובצים עוברים ממיקרו-בקרים של 8 ושל 16 ביט למיקרו-בקרים של 32 ביט נעוצה בצורך בביצועים טובים יותר עבור המוצרים המשובצים שלהם. המעבר למיקרו-בקרים מבוססי ARM לא תמיד ברור ומובן, אבל כבר ידוע שהוא מוביל להקטנה בצריכת ההספק ולהארכת תוחלת החיים של סוללות במוצרים משובצים. בחלק זה של המאמר נשווה בין מיקרו-בקרים מבוססי Cortex-M לבין מיקרו-בקרים אחרים במונחים של ביצועים ושל הקטנת צריכת ההספק.

 

ביצועים

דרך שכיחה להשוות בין ביצועים של מיקרו-בקרים שונים היא להשתמש במבחן Dhrystone השוואתי. הוא חינמי, קל לשימוש וקטן מספיק כדי להיכנס לתוך מיקרו-בקרים בעלי ממדי זיכרון קטנים ביותר (אם כי לא מדובר בחבילת הבדיקות ההשוואתיות ה”אידאלית”). להתן ה-8051 המקורי היו ביצועים של 0.0094 DMIPS/MHz בלבד. התקני 8051 חדשים יותר מציעים ביצועים מעט טובים יותר, לדוגמה התקן ה-80C310 של חברת Maxim מציע DMIPS של 0.027, ועל המיקרו-מעבד 8051 המהיר ביותר הצהירה היצרנית כי הוא מציע ביצועי Dhrystone של 0.1 DMIPS/MHz. זה עדיין איטי בהרבה מהביצועים של מיקרו-מעבדים מבוססי ARM Cortex-M, כיוון שהמעבד Cortex-M3 מספק ביצועים מרביים של 1.25 DMIPS/MHz ואילו המעבד Cortex-M0 משיג ביצועים של 0.9 DMIPS/MHz.

 

ומה באשר לארכיטקטורות אחרות של 8 ושל 16 ביט? ל-PIC18 יש ביצועים של 0.02 DMIPS/MHz (שעון פנימי), איטי יותר מכמה מהתקני ה-8051. גם הביצועים של מוצרי ה-16 ביט מבית מיקרוצ’יפ משיגים פחות ממחצית מביצועיהם של המיקרו-בקרים המבוססים על מעבדי ARM Cortex-M3.

 

איור 2: השוואת ביצועים בסיסית בעזרת Dhrystone

 

מגבלותיהם של מיקרו-בקרים של 8 ושל 16 ביט

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

בעיה נוספת הגורמת לחוסר יעילות ברבים מהמיקרו-בקרים של 8 ושל 16 ביט היא המגבלות של מערך הפקודות ושל מודל המתכנת. לדוגמה, התקן ה-8051 מסתמך מאוד על צובר (ACC) ועל מצביע נתונים (DPTR) לצורך עיבוד והעברת נתונים. כתוצאה מכך נדרשות פקודות להעברת נתונים בתוך ה-ACC וה-DPTR ואל מחוצה להם וזה הופך לתקורה גדולה עבור ממדי הקוד ומחזורי הביצוע.

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

 

הביצועים של מיקרו-בקרים של 8 ושל 16 ביט יורדים עוד יותר אם יש צורך בגישה ליותר מ-64Kbytes של זיכרון. הארכיטקטורות הללו מתוכננות לעבוד עם כתובות של 16 ביט (הם משתמשים במונה תוכנית של 16 ביט, במצביעי נתונים של 16 ביט, ומערך הפקודות מתוכנן לתמוך בטווח כתובות של 64Kbytes). אם יש צורך ביותר מ-64Kbytes של זיכרון, הרי שנדרשת תוספת של תקורת פקודות וחומרה כדי לחולל את ביטי הכתובות הנוספים. עבור התקן 8051 אופייני שצריך לגשת ליותר מ-64kbytes של זיכרון, הזיכרון מחולק ל”בנקים” (מאגרים) ויש לבצע כל קוד של מעבר בין בנקים באמצעות בנק 0# (בנק קבוע). התוצאה היא עלייה בתקורת מחזורי השעון ובממדי הקוד, מה שיכול לפגוע בנצילות של השימוש בזיכרון. מיקרו-בקרים מסוימים של 16 ביט עוקפים את הבעיה הזו בעזרת מוני תוכנית גדולים יותר או באמצעות חלוקת הזיכרון למקטעים, אבל הטיפול בערכי כתובות גדולים יותר עדיין מצריך עיבוד נוסף ולכן בכל מקרה מנמיך את הביצועים ומוביל להגדלה בממדי קוד התוכנית. 

 

הספק נמוך

ומה באשר לצריכת ההספק? אחת הדאגות השכיחות ביותר סביב המעבר לארכיטקטורת ARM היא האם זה יגדיל את צריכת ההספק. אם בוחנים את מוצרי המיקרו-בקרים החדשים המבוססים על ARM מבינים מהר מאוד שלמיקרו-בקרים המבוססים על Cortex-M יש למעשה צריכת הספק נמוכה יותר מזו של רוב המיקרו-בקרים של 8 ושל 16 ביט.

מעבדי ARM מתוכננים לצריכת הספק נמוכה ומיישמים טכניקות רבות לעבודה בהספק נמוך. לדוגמה, המעבדים מדגמים Cortex-M0 ו-Cortex-M3 תומכים במצב שינה המוגדר בארכיטקטורה ובתכונת “שינה-ביציאה” (המאפשרת למעבד לחזור למצב שינה ברגע שהושלם הטיפול בפסיקה).

 

צריכת הספק במיקרו-בקרים

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

 

איור 3: השימוש במעבדים מבוססי ARM Cortex-M מקטין את שטח הסיליקון

 

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

 

הנצילות של גישת זיכרון

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

 

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

 

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

רמת הביצועים הגבוהה יותר של המיקרו-בקרים של 32 ביט מאפשרת הפחתה של צריכת ההספק באמצעות הרצת היישום בתדר שעון הרבה יותר נמוך. לדוגמה, יישום שפועל ב-30 מגהרץ על התקן 8051 יוכל לפעול בתדר שעון של 3 מגהרץ בלבד על מיקרו-בקר מבוסס ARM Cortex-M3 ועדיין להשיג את אותה רמת ביצועים.

 

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

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

איור 4: מיקרו-בקרים מבוססי Cortex יכולים להנמיך את צריכת ההספק של המערכת באמצעות הפחתת המחזורים האקטיביים

 

 

חלק 3 – סיכום

המיקרו-בקרים מבוססי ARM Cortex-M מספקים את נצילות האנרגיה הטובה ביותר ורמת ביצועים גבוהה בהרבה בהשוואה למיקרו-בקרים של 8 ושל 16 ביט. מעבדים מבוססי ARM מתוכננים לנצילות אנרגיה גבוהה והיישומים יכולים לנצל את היתרונות של רמת הביצועים הגבוהה כדי להקטין את צריכת ההספק במספר דרכים.

 

חלק 4 – פיתוח תוכנה ומסקנות

כל מיקרו-בקר הוא סתם חתיכת חומרה עד שמתכנתים אותו עם תוכנת יישום. בחלק זה של המאמר נבחן את ההיבטים השונים של פיתוח יישום עבור מיקרו-בקרים מבוססי ARM Cortex-M.

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

 

העברת תוכנה ממיקרו-בקרים של 8 או של 16 ביט ל-ARM

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

בהשוואה לרוב הארכיטקטורות של 8 ושל 16 ביט, התכנות של מיקרו-בקרים מבוססי ARM הרבה יותר גמיש. לדוגמה, אין מגבלה על מחסנית חומרה, ניתן לגשת לפונקציות באופן חוזר ונשנה (משתנים מקומיים שמורים במחסנית במקום במיקומי זיכרון סטטיים), ואין צורך לדאוג באשר לשמירה של ערך אוגרים מיוחד ברכיבים לניהול פסיקות (handlers) כיוון שזה מטופל על-ידי המעבד במהלך כניסת הפסיקה. לדוגמה, עבור ה-MSP430 ייתכן שתצטרכו לנטרל פסיקות במהלך תהליכי הכפלה, בעוד שעל ה-PIC ייתכן שתצטרכו לשמור מצביעים לטבלאות ואוגרי הכפלה ברכיבים לניהול פסיקות.

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

 

סוג נתונים	מיקרו-בקרים של 8 ביט/ 16 ביט	מיקרו-בקרים מבוססי ARM
מספר שלם	16-bit	32-bit (or use short int for 16-bit)
enum	8-bit/16-bit	8-bit/16-bit/32-bit
מצביע	16-bit or more	32-bit
נקודה צפה עם דיוק כפול	) 32-bit (use single precision)	64-bit (or use float for 32-bit)

 

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

 

השפעה נוספת של ההבדלים בגודל הנתונים נעוצה בממדיו של מערך הנתונים. לדוגמה, מערך מספרים שלמים ב-ROM ביישום של מיקרו-בקר של 8 ביט יכול להיות מוגדר כך:

       const int mydata = { 1234, 5678, …};

בעבודה על מיקרו-בקרים מבוססי ARM יש לשנות את זה בהתאם לדוגמה שלהלן כדי להימנע מגידול לא הכרחי בממדי ה-ROM:

       const short int mydata = { 1234, 5678, …};

 

ההבדל בפקודות נקודה צפה יכול גם הוא להוביל להבדלים קלים בתוצאות החישוב. בגלל מגבלות הביצועים של מיקרו-בקרים של 8 ושל 16 ביט, כאשר משתמשים בנתונים מסוג  double מטפלים בהם כאילו מדובר בדיוק יחיד (32 ביט). במיקרו-בקרים מבוססי ARM, הנתונים מסוג  doubleהם 64 ביט, לכן נקודה צפה של 32 ביט (דיוק יחיד) צריכה להשתמש במקום זה בסוג הנתונים float. ההבדל משפיע גם על הפונקציות המתמטיות. לדוגמה, הקוד Whetstone שלהלן יחולל פונקציות מתמטיות עם דיוק כפול על מיקרו-בקרים מבוססי ARM:

       X=T*atan(T2*sin(X)*cos(X)/(cos(X+Y)+cos(X-Y)-1.0));

For single precision only, the program code should be changed to

       X=T*atanf(T2*sinf(X)*cosf(X)/(cosf(X+Y)+cosf(X-Y)-1.0F));

 

ניפוי שגיאות

עבור משתמשים מסוימים, אחת הדרישות העיקריות בבחירת מיקרו-בקר היא תמיכה של ניפוי שגיאות. מיקרו-מעבדים המבוססים על מעבד ARM Cortex-M תומכים בתכונות מקיפות של ניפוי שגיאות, לרבות נקודות עצירה בחומרה, נקודות צפייה, גישות אוגר, וגישת זיכרון תוך כדי עבודה (on the fly). הבסיס של החיבור לניפוי שגיאות יכול להיות על JTAG או על פרוטוקול Serial Wire (שני אותות), וסידורי מחבר1 ניפוי השגיאות הסטנדרטי של Cortex מקלים מאוד על חיבור לוחות היעד למחשבים המארחים לצורך ניפוי שגיאות.

 

איור 5: תכונות של ניפוי שגיאות על מיקרו-בקרים מבוססי Cortex-M

 

עבור המשתמשים במעבד Cortex-M3, תכונות נוספות של ניפוי שגיאות זמינות באמצעות תמיכת עקבות. מעבד ה-Cortex-M3 הבסיסי תומך בעקבות נתונים סלקטיביות, עקבות אירוע, עקבות חריגה וערוץ מוצא מבוסס טקסט (עקבות מכשור). את נתוני העקבות ניתן לאסוף באמצעות ממשק פין יחיד המכונה Serial Wire Output, החולק את אותו מחבר JTAG/Serial Wire עם החיבור למחשב מארח לניפוי שגיאות. זה מאפשר איסוף של מידע שימושי אודות ביצועי התוכנית באמצעות חומרת ניפוי שגיאות זולה, ללא צורך בחומרה נוספת.

רבים מהמיקרו-בקרים המבוססים על Cortex-M3 תומכים גם ב-ETM (Embedded Trace Macrocell) המרחיב את תמיכת העקבות כך שתכלול גם עקבת פקודה מלאה. תכונה זו מאפשרת לנתח את ביצוע קוד היישום לפרטיו,  וליצור פרופיל קוד. בגלל הדמיון בין המעבדים Cortex-M0 ו-Cortex-M3 ניתן לפתח ולנפות שגיאות מיישום על מעבד Cortex-M3 עם עקבת פקודה, ולאחר מכן להעביר את אותו יישום למעבד Cortex-M0 תוך הכנסת שינויים קלים בלבד.

 

 

איור 6: תכונות עקבות מספקות רמה גבוהה של נראוּת

מבחר אפשרויות

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

 

 

איור 7: יצרניות של מיקרו-בקרים משתמשות במעבדי Cortex-M

 

יבילות תוכנה

מיקרו-בקרים מבוססי ARM Cortex-M מספקים גם רמות גבוהות של יבילות תוכנה (פורטביליות). אמנם יש כמה יצרניות של מיקרו-בקרים, אך כל אחת מהן מספקת ספריות דרייבר התקן משלה, וישנן כמה יצרניות של מהדר C המספקות חבילות הידור, תוכנות שניתן להעביר בקלות בעזרת ה-CMSIS (תקן ממשק התוכנה של מיקרו-בקר Cortex).

 

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

 

עלות המעבר

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

 

איור 8: מחירם של המיקרו-בקרים של 32 ביט הולך ויורד

 

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

 

מסקנות

המעבר ממיקרו-בקרים של 8 ביט למיקרו-בקרים המבוססים על ARM Cortex-M יכול לספק ביצועים הרבה יותר טובים ולאפשר פיתוח של תוכנות מתוחכמות בעלות נמוכה. הוא יכול גם לעזור להקטין את צריכת ההספק ואת ממדי הקוד. במעבר לארכיטקטורות חלופיות של 16 או של 32 ביט לא ניתן להשיג את אותם יתרונות.

 

	8051	ארכיטקטורות אחרות של 8 ביט	ארכיטקטורות של 16 ביט	ארכיטקטורות אחרות של 32 ביט	מיקרו-בקר מבוסס ARM Cortex
ביצועים
הספק נמוך
צפיפות קוד
>64kbytes של זיכרון (מקור, נצילות)
פסיקות עם וקטורים
השהיית פסיקות נמוכה
עלות נמוכה
ריבוי מקורות (ארכיטקטורה לא קניינית)
אפשרויות מהדר
יבילות תוכנה

 

המעבר מארכיטקטורות של 8 ביט לארכיטקטורות של  16 ביט יכול לפתור חלק מהמגבלות המוכרות לנו עם מיקרו-בקרים של 8 ביט. לארכיטקטורות של 16 ביט יש אותה בעיה של חוסר יעילות בטיפול בממדי זיכרון גדולים (מעל 64kbytes) והן בדרך-כלל מבוססות על ארכיטקטורות קנייניות, מה שמגביל את מבחר ההתקנים ואת יבילות התוכנה. ארכיטקטורות אחרות של 32 ביט מפגרות מאחור במונחים של תכונות פסיקה, נצילות אנרגיה, תכונות מערכת ותמיכת תוכנה. באופן כללי, המעבר ל-ARM מעניק את מרב היתרונות, לרבות עלות נמוכה והכנה לקראת העתיד.

 

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

 

איור 9: המיקרו-בקרים מבוססי Cortex-M מכסים את כל ההיבטים והדרישות של מערכות משובצות עמוקות ובמבט אל העתיד, יותר ויותר מוצרי מיקרו-בקרים מבוססי Cortex-M יהיו זמינים בשוק, ויותר ויותר פרויקטים משובצים יעברו ל-ARM. בטווח הרחוק כבר ברור היום שהמיקרו-בקרים המבוססים על ARM Cortex-M יהפכו לסטנדרט המקובל בשוק עבור מיקרו-בקרים.