המעבר ממעגל שעובד למוצר שאפשר למכור מתחיל בהחלטות הנדסיות מוקדמות. בחירה נכונה של מודול, אנטנה, סוללה, ספק כוח ומארז יכולה לצמצם בדיקות חוזרות, ובלבד ששומרים על תנאי האישורים ועל עקיבות לאורך הייצור והשינויים.
לקריאת הכתבהמה מקבלים כאן
הודעת יצרן נכנסת. הסבר הנדסי יוצא.
NatiLab אינו משכפל הודעות לעיתונות ואינו מתרגם אותן שורה אחר שורה. בכל כתבה אנחנו חוזרים למקור הרשמי, מסבירים את המנגנון במילים פשוטות, בודקים מה אפשר לבנות ומצביעים גם על המחיר, המגבלה או השאלה שהיצרן השאיר פתוחה.
לשיטת העבודה המלאה- עובדהמה בדיוק הוכרז ובאיזה מקור רשמי אפשר לבדוק זאת.
- מנגנוןאיך הדבר עובד בתוך המוצר, לא רק איך קוראים לו.
- שיקול הנדסילמי זה שימושי, מה המחיר ההנדסי ומה עדיין לא ידוע.
המהדורה הנוכחית כוללת 20 כתבות. כל כתבה נבחרת, נבדקת ומאושרת בידי עורך לפני פרסום.
הכתבות
חדש קודם. מעניין לפני הכול.
הערך של Wi-SUN מתברר כשמסתכלים על מה שחוסך מאיתנו הפרופיל לבנות לבד: הסכמה על העברת הנתונים, הצטרפות מאומתת, ניתוב דרך שכנים וניהול מכשירים בעלי תפקידי אנרגיה שונים. הוא אינו מגדיר עבורנו מהו מד מים טוב, אינו מבטיח טווח בכל התקנה ואינו מחליף אבטחת יישום. הוא מספק תשתית תקשורת שעליה אפשר לבנות את המוצר, בתנאי שמבינים היכן היא מסתיימת. בסופו של המסע, שמונת בתי המדידה שלנו לא השתנו במשמעותם. סביבם נוספו כתובות, כללי העברה והגנות; בדרך התחלפו שכנים ומסגרות, ובקצה השרת פירש שוב ״12,345 ליטרים״. זה המודל שכדאי להחזיק בראש לפני שבוחרים שבב. מכאן אפשר לשאול שאלות מדויקות: מי מריץ כל שכבה, איזה מפתח נמצא אצל מי, מה קורה אחרי אובדן חשמל וכמה זמן מותר למקלט לישון. אלה כבר שאלות על מערכת שאפשר לתכנן, ולא רק על רדיו שאפשר לקנות.
לקריאת הכתבה
BLE Channel Sounding מקרב מדידת מרחק מדויקת לרכיב רדיו שכבר נמצא כמעט בכל מוצר, אבל הוא אינו מבטל את הגאומטריה, מערכי האנטנות והאלגוריתמים שנדרשים כדי להפוך מרחק לכיוון ולמיקום. ההשוואה ל־UWB חושפת שהחלטת התכנון האמיתית אינה רק דיוק מול מחיר: היא קובעת מי נושא את המורכבות, כמה עוגנים צריך, כיצד המערכת מתנהגת מול גוף וקירות, ומה קורה לסוללה ולקיבולת כאשר עוברים מהדגמה לתגים רבים בשטח.
לקריאת הכתבה
במוצר שמיוצר שוב ושוב, חיסכון קטן בזיכרון, בזמן תגובה או באנרגיה יכול להצדיק עבודת תוכנה משמעותית. AI עשוי להזיז את נקודת האיזון אם יוזיל את עבודת המדידה וההתאמה לחומרה, ולא רק את כתיבת הקוד הראשונית. ההזדמנות היא לבנות מוצר שמתאים טוב יותר למשימה שלו, תוך שמירה על תמיכה בשירותים, אמינות ויכולת תחזוקה. את ההחלטה אם להסיר שכבה, לשפר אותה או להשאיר אותה צריך לקבל לפי המוצר השלם והתוצאות שנמדדו.
לקריאת הכתבה
קבל הוא לעיתים הרכיב הזול ביותר ב־BOM, אבל הוא יכול לקבוע אם מסילת מתח יציבה, אם ממיר מתחמם, אם מסנן נשאר מכוון, אם מוצר עומד בתקינת רשת ואם הייצור נעצר בגלל חוסר. ברגע שמחברים בין הפיזיקה של הדיאלקטרי לבין ESR, ESL, ריפל, חיי עבודה וזמינות, בחירת קבל מפסיקה להיות ניחוש לפי µF והופכת להחלטת מערכת שאפשר להסביר, למדוד ולתת לה חלופה.
לקריאת הכתבה
המעבר מ־Flash ל־MRAM, RRAM ו־PCM אינו רק החלפת חומר בתוך תא זיכרון. הוא מאפשר ליצרנים להעביר MCU לתהליכי 28–16 ננומטר, לשלב ליבות מהירות, תקשורת ואבטחה, ולשנות את זמן התכנות והעדכון של מוצר שלם. אבל אין כאן מנצח מוחלט: כל פתרון משלם בזרם כתיבה, מורכבות ייצור, שונות, חום, צפיפות או בשלות. למהנדס שבוחר MCU, סוג הזיכרון הופך עכשיו לחלק מהחלטת הארכיטקטורה ולא לשורה שאפשר לדלג עליה בדף הנתונים.
לקריאת הכתבה
החלק המעניין כאן אינו השיא העגול של 5GHz לבדו, אלא הניסיון של Qualcomm לטפל בקיר הזיכרון בתוך מעטפת החום של טלפון. FlexCache עשוי להפחית cache misses וקנסות של מעבר עבודה בין ליבות שונות, אבל החברה עדיין לא פרסמה את הנתונים שמאפשרים לכמת את היתרון. מול Intel ו־AMD התדר כבר נמצא באותה שכונה; ההכרעה תגיע מ־IPC, ביצועים רציפים, אנרגיה למשימה וגודל קבוצת העבודה שנשארת במטמון.
לקריאת הכתבה
החלק המעניין כאן אינו רק שה־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 טוב הוא מכפיל כוח לצוות פיתוח: הוא מחבר בין ידע יצרן, ניסיון שטח ומציאות אספקה, ויכול למנוע טעויות שהופכות יקרות ככל שהפרויקט מתקדם. הערך אינו בשיחת חירום בודדת אלא בקשר רציף שמתחיל לפני בחירת הרכיב — תוך שמירה על האחריות ההנדסית, תיעוד עצמאי והבנה שהמפיץ מייצג סל יצרנים מסוים.
לקריאת הכתבה
השיחה הראשית
תגובות על NatiLab
דירוגים, שאלות, רעיונות והצעות למה כדאי לשפר או לחקור בהמשך.