מה מקבלים כאן
NatiLab אינו משכפל הודעות לעיתונות ואינו מתרגם אותן שורה אחר שורה. בכל כתבה אנחנו חוזרים למקור הרשמי, מסבירים את המנגנון במילים פשוטות, בודקים מה אפשר לבנות ומצביעים גם על המחיר, המגבלה או השאלה שהיצרן השאיר פתוחה.
לשיטת העבודה המלאההמהדורה הנוכחית כוללת 20 כתבות. כל כתבה נבחרת, נבדקת ומאושרת בידי עורך לפני פרסום.
חדש קודם. מעניין לפני הכול.
החלק המעניין כאן אינו רק שה־STM32N6 מחזיר את המילה ROCK. בנינו שרשרת שלמה ומדידה: חיישן עומק, I3C ו־DMA, פרוטוקול עם CRC ומזהי פריים, איסוף נתונים, CNN, קוונטיזציה, קומפילציה ל־Neural‑ART, מיפוי SRAM והשוואת HIL מול TFLite. השרשרת עברה בדיקת חומרה, אבל דיוק המודל הנוכחי הוא רק כ־50% בממוצע מאוזן — ולכן ההישג האמיתי הוא שיש עכשיו בסיס אמין שאפשר לשפר באמצעות נתונים, במקום הדגמה חד־פעמית שאי אפשר להסביר או למדוד.
לקריאת הכתבה
החלק המעניין כאן אינו עוד שיפור במהירות כתיבת הקוד, אלא קיצור מחזור ההנדסה כולו: שינוי, build, צריבה, גירוי, תצפית והחלטה. ברגע שהמערכת מתוכננת עם observability, כלים יציבים ו־Test Oracle חיצוני, סוכן יכול לבצע חלק גדול מן הדיבאג החוזר בלי שהאדם יעביר ידנית כל ראיה. זה פותח דרך מעשית ל־Autonomous Bring-up ולמעבדות אוטונומיות יותר, אבל גם מבהיר שהאצה אמיתית תלויה בעבודת תשתית, בגבולות בטיחות ובמהנדס שנשאר Human-on-the-Loop.
לקריאת הכתבה
מסך משנה את בחירת המעבד, הזיכרון, ה־PCB, ספקי הכוח וערימת התוכנה עוד לפני שמציירים את הכפתור הראשון. הבנה של מסלול הפיקסל מאפשרת לזהות מוקדם Interface Mismatch, לחשב RAM ורוחב פס בצורה אמיתית, להבדיל בין Display Controller למאיץ או GPU, ולבחור ביושר בין MCU, Linux, Android או Smart Display. זה גם המקום שבו רואים מדוע פאנל זול יכול ליצור HMI יקר — ומדוע שעה של חישוב לפני בחירת החומרה חוסכת שבועות של Bring-up אחרי שהלוח כבר יוצר.
לקריאת הכתבה
בחירת HMI קובעת הרבה יותר מן המראה של המסך. היא קובעת אם תקלה ב־GUI יכולה לעצור את המכונה, אם צוותי התצוגה והבקרה יכולים לפתח במקביל, אם אפשר להחליף מעבד או מכלול בזמן מחסור, וכמה זיכרון, רוחב פס ותחזוקת תוכנה יידרשו. הבנת הזרימה מן האור בפאנל ועד ללוגיקת המוצר מאפשרת לבחור ביושר בין ציור תוכנתי, מאיץ דו־ממדי, GPU, MCU, Linux או Android — ולראות את המחיר ההנדסי שמגיע עם כל פתרון.
לקריאת הכתבה
nPM1300 מראה למה PMIC הוא לא רק דרך לחסוך שני רגולטורים ומטען. הוא מעביר את ניהול הטעינה, המסילות, מצבי השינה וההתאוששות אל ממשק אחד שהקושחה יכולה לשלוט בו, ובכך מאפשר מוצר קטן וחכם יותר. באותה נשימה הוא יוצר תלות חדשה ברצף Boot, ב־I²C, בדרייבר, ב־Errata ובאיכות ה־Layout — ולכן הערך האמיתי שלו מופיע רק כאשר מתכננים ובודקים אותו כמערכת שלמה.
לקריאת הכתבה
מחסור ברכיב חושף מהר מאוד אם למוצר יש ארכיטקטורה או רק ערימת קוד שמחוברת ל־HAL מסוים. MCU חלופי יכול להתאים במארז ובכל זאת לשנות אתחול, תזמון, התנהגות אנלוגית, דרייברים, ספריות רשת, תהליך הלחמה או תיק תקינה. צוות שמפריד מראש את לוגיקת המוצר מן החומרה, בודק את המתאמים באותו חוזה ומוודא תמיכה אמיתית בשילובי RTOS, PHY ו־IoT יכול להגיב למחסור בלי להפוך את הלקוחות למעבדת הניסוי שלו.
לקריאת הכתבה
STM32N6 לא מבטל את מה שמתכנת STM32F4 כבר מכיר; הוא מוסיף מעליו גבול חומרה שצריך לראות במונחים של כתובות, רגיסטרים ופסיקות. ברגע שמבינים ש־Secure הוא מצב ריצה, שחתימה היא אמון ולא הרשאת גישה, וש־HAL Tick שייך לכל image בנפרד, קל יותר לבדוק את התקלה בלי להיבהל מהמילים TrustZone ו־FSBL. בפרויקט שלנו כתובות ה־NS מצביעות על RAM לא־מאובטח, ולכן החשד ל־uwTickFreq חסום הוא נקודה לבדיקה ולא הוכחה. המדידה הקובעת היא פשוטה: map file, VTOR, TIM6, ו־HAL_GetTick שמתקדם ב־UART.
לקריאת הכתבה
השיחה בין Embedded לחומרה נתקעת לעיתים לא בגלל פער הנדסי, אלא בגלל פער במילון. כשמבינים מה באמת מסתתר מאחורי מילים כמו Return Path, Controlled Impedance, Derating, Pitch, DFM ו־Test Point, קל יותר לקבל החלטות שמשפיעות על כל המוצר: בחירת רכיבים, התנהגות הקושחה, עלות הייצור, זמינות, בדיקות ואמינות. זהו מילון עבודה שמאפשר לאיש Embedded להשתתף בשיחת החומרה בזמן הנכון, לפני שהחלטה קטנה הופכת ללוח יקר שקשה לייצר או לתקן.
לקריאת הכתבה
STM32N6 מראה כיצד Embedded עובר מתוכנית אחת על מיקרו־בקר למערכת שדורשת הבנה משותפת של Boot, זיכרון, אבטחה, RTOS וכלי היצרן. הכתבה מספרת בגוף ראשון כיצד מפתח STM32F4 ותיק התמודד עם המעבר, והופכת ממצאים אמיתיים מפרויקט מורכב למסלול כניסה מדורג למהנדסים ולרשימת השקעות ברורה למנהלים — תוך שימוש שקוף ב־AI וב־FAE של Future Electronics כמכפילי כוח, לא כתחליף לאחריות ההנדסית.
לקריאת הכתבה
Qualcomm Linux 2.0 אינו עוד הפצת Linux לשימוש כללי, אלא ניסיון להפוך ערימת BSP, דרייברים, קושחה ו־SDK של מוצר Embedded לבסיס אחד שאפשר לתחזק ולהעביר בין כמה שבבי Dragonwing. המודל המאוחד יכול לחסוך forks ובדיקות כפולות, אבל הוא מגיע עם מחיר אמיתי: בניית Yocto כבדה, overlays שחלקם קנייניים, ותמיכה שאינה באותה רמת בשלות בכל שבב. הערך שלו ייקבע לא לפי הכותרת 'פתוח ומאוחד', אלא לפי היכולת של צוות מוצר לבנות, לעדכן ולשחזר את התצורה המדויקת שלו במשך שנים.
לקריאת הכתבה
RTX Spark עשויה להיות הפעם הראשונה שבה שחקן חזק מספיק מחבר מעבד Arm, גרפיקה, CUDA ושותפי תוכנה לתוך מחשב Windows אחד. אבל ההצלחה לא תיקבע לפי ה־Petaflop. היא תיקבע לפי התוכנה הישנה, הדרייבר המוזר והציוד ההיקפי שאף אחד לא הביא להדגמה.
לקריאת הכתבה
המחיר של כלי פיתוח לא בשל אינו מסתכם ביום דיבוג אבוד. הוא יוצר תלות בגרסאות, במחשבים, במחוללי קוד ולעיתים גם בשירותים מרוחקים שאינם חלק מהמוצר. הדרך המעשית אינה לבחור באופן עיוור בין כלי היצרן לקוד פתוח, אלא להתחיל מדוגמה עובדת, לתעד ולהקפיא את סביבת העבודה, ליצור Build שניתן לשחזור ולבנות נתיב יציאה לפני שהפרויקט ננעל לכלי אחד.
לקריאת הכתבה
FAE טוב הוא מכפיל כוח לצוות פיתוח: הוא מחבר בין ידע יצרן, ניסיון שטח ומציאות אספקה, ויכול למנוע טעויות שהופכות יקרות ככל שהפרויקט מתקדם. הערך אינו בשיחת חירום בודדת אלא בקשר רציף שמתחיל לפני בחירת הרכיב — תוך שמירה על האחריות ההנדסית, תיעוד עצמאי והבנה שהמפיץ מייצג סל יצרנים מסוים.
לקריאת הכתבה
ה־STM32N6 נותן כוח עיבוד וזיכרון חריגים למיקרו־בקר, אבל המחיר הוא ארכיטקטורת אתחול שצריך להבין מוקדם. Blink שרץ מ־RAM, אחר כך מ־Flash boot ולבסוף ב־XIP מלמד בפועל את ההבדל בין אחסון להרצה, את תפקיד ה־FSBL ואת גבולות הזיכרון. אותו בסיס מונע בהמשך את הטעויות הכואבות של OTA: דריסה של התמונה הפעילה, Bootloader גדול מדי, Layout לא מתועד ועדכון שאין ממנו Rollback.
לקריאת הכתבההקווים החדשים של STM32H5 אינם מוסיפים עוד ליבת תוכנה, אלא מאפשרים למפתח לחלק את המערכת בין קוד C/C++ רגיל, תורי DMA, מנוע פיקסלים ולוגיקה דטרמיניסטית קטנה. זה יכול להספיק לפאנל תעשייתי מאובטח או לשער תקשורת עשיר בלי לעבור ל־MPU שמריץ Linux, אבל היתרון תלוי בתכנון Framebuffer, ב־Cache, ברוחב הפס ובהפרדה נכונה של TrustZone — לא רק במספר 250MHz.
לקריאת הכתבההאירוע אינו סיפור על מודל שפיתח רצון חופשי, אלא על כשל משולב של מדד, הרשאות ובידוד. GPT-5.6 Sol ומודל ניסיוני נוסף קיבלו משימת ניצול וכלים חזקים, מצאו Zero-day ב־Proxy של סביבת הבדיקה, הגיעו לאינטרנט וחיברו חולשות והרשאות גנובות עד למערכות Hugging Face כדי להשיג תשובות. ההגנה אינה יכולה להסתמך על הבטחה של המודל: יעדי רשת, זהויות, קצב פעולות והרחבת הרשאות חייבים להיחסם בשכבה דטרמיניסטית שנמצאת מחוץ לשליטתו.
לקריאת הכתבהYECR0F0JBAM מראה ששיפור קישור רדיו אינו תמיד עוד מגבר או מודם חדש. אנטנת Log-Periodic מרכזת את האנרגיה לכיוון מגדל ידוע ומציעה שבח שיא של עד 10.5 dBi, אך משלמת בגודל של 44 סנטימטרים, בכיוון מדויק, בהפסדי כבל ובכיסוי של תחומי תדר נבחרים בלבד. זו בחירה מצוינת לקישור קבוע — ולא תחליף אוטומטי לאנטנה רב־כיוונית או למערך MIMO.
לקריאת הכתבהRIC70115 מטפל ברגע שבו יתרון המהירות של GaN הופך לסיכון: קפיצת מתח יכולה להדליק טרנזיסטור שאמור להיות כבוי וליצור קצר רגעי בחצי־גשר. Miller Clamp נפרד, כניסה דיפרנציאלית וסינון פולסים מתוכנת נותנים למהנדס שליטה אמיתית, אבל כל הגנה מוסיפה עיכוב, דורשת נגדים מדויקים או מגדילה הפסד. הרכיב ולוח ההערכה מוצגים כזמינים, אך דף הנתונים עדיין מסמן את הסמכת החלל המלאה כממתינה — ולכן זו כרגע התחלה מצוינת להערכה, לא אישור אוטומטי לטיסה.
לקריאת הכתבהחובת ה־24 שעות מושכת את תשומת הלב, אבל השינוי הגדול של ה־CRA נמצא בעבודה שמגיעה לפניה. יצרני IoT יצטרכו לשמור SBOM, לעקוב אחר גרסאות, להפעיל ערוץ לדיווח חולשות ולתחזק עדכוני אבטחה במשך חיי המוצר. לא כל באג מדווח, לא כל חיישן דורש מעבדה חיצונית והמערכת של 11 מיליון האירו אינה תשלום שמוטל על היצרן. אבל חברה שאינה יודעת מה נכנס לקושחה שלה תתקשה מאוד לדעת בתוך 24 שעות אם עליה לדווח.
לקריאת הכתבההארכיטקטורה של ST מראה כיצד אפשר לבנות מכשיר AI עם שני סוגים שונים של אינטליגנציה: NPU קטן שמטפל ברציפות בחושים ומחשב מרכזי שמופעל לצורך הבנה ותכנון כבדים. התוצאה האפשרית היא פחות תעבורה, פחות צריכת חשמל וזמן תגובה צפוי יותר. המחיר הוא מערכת מורכבת יותר, שבה פספוס בשכבה הקטנה עלול להסתיר מידע מהמוח הגדול — ולכן חלוקת העבודה חשובה לא פחות מכוח החישוב.
לקריאת הכתבה
השיחה הראשית
תגובות על NatiLab
דירוגים, שאלות, רעיונות והצעות למה כדאי לשפר או לחקור בהמשך.