STM32H5 החדש נותן ל־FW יותר זיכרון ומנועים שעובדים בלי להעסיק את הליבה

מיקרו־בקר כזה יושב בתוך מוצר ומפעיל אותו: קורא חיישנים, מנהל תקשורת, מגיב בזמן קבוע ומעדכן יציאות. הוא אינו מחשב Linux קטן. ה־FW שלך עדיין נכתב בדרך הרגילה ב־C או C++, יכול לרוץ בלי מערכת הפעלה או עם RTOS, ונבנה בעזרת STM32CubeMX, ‏STM32CubeH5 ודרייברי HAL או LL.

חשוב גם לנקות בלבול אפשרי סביב המילה "כוח עיבוד". בכל הדגמים האלה יש ליבת Arm Cortex‑M33 יחידה עד 250 מגה־הרץ. אין ליבה שנייה שמריצה עוד Thread של האפליקציה, ואין כאן מאיץ AI שמקבל פונקציה שכתבת. יש CPU אחד שמריץ את הקוד שלך, ולצדו מנועים ייעודיים שמבצעים פעולות מוגדרות לאחר שה־FW מכין להם עבודה.

הליבה מריצה את לולאת הבקרה, משימות ה־RTOS, פרוטוקולים ואלגוריתמים. יש לה יחידת נקודה צפה לחישובי float, הוראות DSP לעיבוד אותות ומטמון הוראות שמקטין את ההמתנה ל־Flash. ST מציינת 1,023 נקודות CoreMark, אבל זהו מבחן לליבה ולא הבטחה לזמן תגובה של המוצר. קצב אמיתי תלוי גם בגישה לזיכרון, בעומס הפס, במספר הפסיקות ובכמה עבודה הועברה לחומרה.

נקודת ייחוס טובה היא STM32F405/407, משפחה שמפתחי Embedded רבים מכירים. לפי מדריך ההגירה של ST, ‏STM32H543/553 עולה מליבת Cortex‑M4 עד 168 מגה־הרץ לליבת M33 עד 250 מגה־הרץ, ומ־192 ל־304 קילו־בייט RAM, כאשר ה־Flash נשאר עד 1 מגה־בייט. זה שדרוג משמעותי, אך לא החלפה שקופה: בקו החדש אין DCMI למצלמה, ו־USB הוא Full Speed במקום ממשק ה־High Speed שהיה בחלק מדגמי F4.

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

GPDMA הוא המנוע הכללי להעברת נתונים. ב־CubeMX בוחרים מי מפעיל ערוץ, למשל ADC, ‏SPI או UART, לאן הנתונים עוברים ומה גודל הבלוק. אפשר להכין רשימה מקושרת של פעולות, כך שה־DMA יעבור בין כמה Buffer‑ים או שלבי העברה בלי שה־CPU יתכנת מחדש את הערוץ בכל סוף בלוק. בדגמי H5 החדשים יש 12 ערוצים, העברה גם בין שני Peripheral‑ים ותמיכה בדפוסי דו־ממד. זה מתאים, למשל, לדגימת ADC רציפה אל שני Buffer‑ים בזמן שמשימת הבקרה מעבדת את הבלוק הקודם.

בדגמי STM32H5Ex/Fx נוסף Chrom‑ART2, שמופיע בתוכנה כ־DMA2D. זהו DMA שמבין תמונות: הוא יודע למלא מלבן בצבע, להעתיק אזור, להמיר פורמט פיקסלים, לשלב שתי שכבות עם שקיפות, לסובב, לשקף ולהקטין תמונה. הקוד שלך אינו מצייר את הפעולה פיקסל אחרי פיקסל. הוא מגדיר את כתובות המקור והיעד, רוחב, גובה, פורמט ושיטת השילוב, ואז מפעיל את המנוע.

בעבודה ישירה עם HAL, הזרימה נראית כך: מאתחלים DMA2D, מגדירים את שכבת הרקע או החזית בעזרת HAL_DMA2D_ConfigLayer, מפעילים פעולה בעזרת HAL_DMA2D_Start_IT או HAL_DMA2D_BlendingStart_IT, וממשיכים לעבוד עד Callback של סיום. לסיבוב ולהקטנה קיימות הגדרות נפרדות. אפשר לעבוד גם ב־Polling, אך המתנה חסומה מחזירה לליבה את צוואר הבקבוק שממנו ניסינו להיפטר.

Chrom‑ART2 מוסיף גם Command List. במקום שה־CPU יגדיר מחדש את כל הרגיסטרים עבור מילוי רקע, העתקת אייקון, שילוב טקסט וסיבוב תמונה, ה־FW בונה מראש רשימת פקודות בזיכרון ומכניס אותה לתור טבעתי. החומרה קוראת את הרשימה ומבצעת את הרצף. דרייבר HAL מספק פעולות להכנת הרשימות, הכנסתן לתור והפעלתן, ולאפליקציה נשאר לטפל בסיום או בשגיאה.

אם משתמשים ב־TouchGFX, בדרך כלל לא צריך לקרוא לכל פונקציית DMA2D ידנית. מפעילים את DMA2D ב־CubeMX, בוחרים Command List Mode בדגמי H5Ex/Fx, ו־TouchGFX Generator יוצר דרייבר שמוסר למאיץ את פעולות הציור הנתמכות. קוד ה־C++ של המסכים וה־Widgets נשאר קוד רגיל. כאשר המנוע הגרפי צריך לבצע Blit או Alpha Blend הוא בודק אם החומרה תומכת בפעולה, שולח אותה ל־DMA2D, ונופל לציור תוכנתי רק כאשר אין האצה מתאימה.

במסך RGB נכנס מנוע נוסף בשם LTDC. הוא קורא ברציפות את ה־Framebuffer ושולח את הפיקסלים אל הפאנל בקצב התצוגה. במקביל ה־CPU מחשב את מצב הממשק ו־DMA2D מעדכן אזורים בתמונה. לכן צריך סנכרון: אסור לליבה ולמאיץ לכתוב לאותו אזור בזמן ש־LTDC מציג אותו בלי אסטרטגיה של Buffer יחיד, כפול או חלקי. TouchGFX מספק Semaphore ומנגנוני החלפה, אך עדיין צריך לבחור אותם לפי הזיכרון וזמן הרענון.

כאן המספר 1.5 מגה־בייט RAM מקבל משמעות מעשית. תמונת 640×480 בפורמט RGB565, כלומר שני בתים לפיקסל, תופסת 614,400 בתים. שני Framebuffer‑ים תופסים 1,228,800 בתים ומשאירים מעט מקום ל־Stack, ‏Heap, תקשורת ונתוני האפליקציה. תמונת 1024×600 כבר תופסת 1,228,800 בתים ל־Buffer אחד. לכן ST מדברת על 640×480 מתוך ה־RAM הפנימי ועל 1024×600 בעזרת זיכרון חיצוני.

זיכרון חיצוני מוסיף מלכודת FW מוכרת. מטמון הנתונים מאיץ גישה של ה־CPU ל־PSRAM או SDRAM, אבל DMA2D ו־LTDC קוראים את הזיכרון עצמו ולא בהכרח רואים מיד עותק מלוכלך שנשאר ב־Cache. גם ה־CPU עלול לקרוא עותק ישן אחרי שה־DMA כתב לזיכרון. צריך להחליט אילו אזורים הם Cacheable, ולבצע Clean או Invalidate בטווחים הנכונים, או להשתמש במדיניות זיכרון שמונעת את חוסר העקביות. בלי זה מקבלים פסים, פריימים ישנים ותקלות שנעלמות כאשר עוצרים בדיבאגר.

המנוע השלישי והמוזר יותר נקרא PLAY, קיצור של Programmable Logic ArraY. זהו מערך קטן של 16 יחידות לוגיות. בכל יחידה יש טבלת אמת עם עד ארבע כניסות ויציאה ישירה או רשומה. הכניסות יכולות להגיע מפינים, מטיימרים, ממשקי תקשורת, משווי מתח או ביטים שהתוכנה כותבת. היציאות יכולות להגיע לפין, ל־Peripheral אחר, לדגל, לפסיקה או למנגנון ההתעוררות.

לא כותבים עבור PLAY פונקציית C שרצה במקביל. מתכננים את הלוגיקה או מכונת המצבים ב־Logisim evolution, בודקים את טבלת האמת, בוחרים ב־CubeMX את מקורות האותות והמסננים, ומייצרים קוד אתחול. ברמת HAL הרצף הוא HAL_PLAY_Init, הגדרת הכניסות, כתיבת טבלאות ה־LUT והגדרת היציאות. לאחר האתחול החומרה מגיבה לאותות בעצמה, גם כאשר הליבה עסוקה, ובחלק מהמצבים גם בזמן Stop.

שימוש מעשי ל־PLAY הוא לוגיקת דבק שבדרך כלל דורשת רכיב חיצוני או ISR קצר ומהיר: להעביר אות רק כאשר שני תנאי Enable מתקיימים, לסנן פולס קצר, לזהות צירוף של יציאת Comparator וטיימר, או להעיר את ה־CPU רק כאשר רצף מסוים התרחש. היתרון הוא זמן תגובה קבוע ופחות עומס פסיקות. המחיר הוא גודל קטן, ארבע כניסות לכל LUT וכלי פיתוח שמרגישים קרובים יותר לתכנון לוגי מאשר לכתיבת Firmware.

דוגמה מלאה היא פאנל של מכונה. ה־M33 מריץ את בקרת המוצר, Ethernet ופרוטוקול העדכון. TouchGFX מנהל את המסכים, Chrom‑ART2 מצייר אייקונים ואנימציות, LTDC מזרים את ה־Framebuffer למסך, GPDMA אוסף דגימות, ו־PLAY חוסם או מעביר אות חומרתי לפי מצב המכונה. כך ממשק גרפי אינו גונב את כל זמן הליבה מבקרת הציוד.

דוגמה אחרת היא שער תקשורת מאובטח ללא מסך. שם STM32H553 יכול להיות מעניין יותר מהדגמים הגרפיים: 1 מגה־בייט Flash, ‏304 קילו־בייט RAM, Ethernet, ‏FDCAN, ‏I3C וקריפטוגרפיה בחומרה באריזה קטנה יותר. קוד האפליקציה מטפל בפרוטוקולים ובמצב המוצר, GPDMA מזיז מסגרות נתונים, ו־TrustZone מפריד בין שירותי מפתחות לבין הקוד הרגיל.

גם כאן צריך לבחור את הסיומת הנכונה. H553 ו־H5Fx כוללים מאיצי קריפטוגרפיה; H543 ו־H5Ex הם הקווים ללא אותם מאיצים. TrustZone אינו הופך את התוכנה למאובטחת לבד. כאשר מפעילים אותו, CubeMX יוצר בדרך כלל פרויקט Secure ופרויקט Non‑Secure, והמהנדס צריך לחלק נכון Flash, ‏RAM, ערוצי DMA ו־Peripheral‑ים. הקצאת Buffer לדומיין הלא נכון יכולה להפוך שיפור ביצועים ל־HardFault.

לבדיקה ראשונה, STM32H5F5J-DK הוא הנתיב הישיר לגרפיקה: יש עליו מסך מגע 480×272, זיכרון Flash חיצוני של 512 מגה־ביט, SRAM חיצוני של 64 מגה־ביט, Ethernet, ‏microSD ודיבאגר. אפשר להתחיל מפרויקט Board מוכן של CubeH5 ו־TouchGFX, למדוד זמן Frame ועומס CPU, ואז לכבות את DMA2D או להעביר Buffer לזיכרון אחר כדי לראות מה באמת נותן את השיפור. ליישום ללא מסך, לוח Nucleo של H553 נותן נקודת התחלה פשוטה יותר.

המחיר האמיתי נמצא באינטגרציה. יותר מנועים פירושם יותר בעלים לאותו זיכרון, יותר פסיקות, תחרות על רוחב הפס וצורך להחליט מי רשאי לגשת למה. בנוסף, ST כתבה שהזמינות דרך מפיצים צפויה מאוחר יותר ב־2026, ודף ה־Discovery kit עדיין מתאר דוגמאות הנדסיות מוגבלות ומוצר שנמצא באפיון. זה בסיס טוב לניסוי עכשיו, אבל למוצר שצריך להיכנס לייצור בקרוב צריך לבדוק זמינות, Errata וגרסת CubeH5 בפועל.

החלק המעניין פה אינו רק 250 מגה־הרץ. הוא היכולת לכתוב FW שבו הליבה מקבלת החלטות, ה־DMA מזיז נתונים, Chrom‑ART2 מטפל בפיקסלים ו־PLAY מגיב לאותות קצרים. כאשר החלוקה נכונה, מקבלים מוצר שמרגיש מהיר יותר בלי להעמיס כל פעולה על ה־CPU. כאשר היא לא נכונה, מקבלים M33 מהיר שמחכה לזיכרון ומתקן Cache כל היום.