14.1.1.2. בניית הקושחה¶

כאשר הסביבה מ-הקמת סביבת הפיתוח קיימת, בניית תמונת קושחה היא שתי פקודות make בתוספת בחירת TARGET.

14.1.1.2.1. הידור¶

ראשית בנו את mpy-cross, כלי המארח המהדר את מודולי ה-.py הקפואים לקוד-בייט (עשו זאת פעם אחת, ושוב בכל פעם שאתם מעדכנים את MicroPython):

make -j$(nproc) -C lib/micropython/mpy-cross

לאחר מכן בנו את הקושחה עבור לוח, כאשר <TARGET> הוא אחד מהשמות מהטבלה למטה:

make -j$(nproc) TARGET=<TARGET>

-j$(nproc) בונה במקביל על פני כל ליבות ה-CPU (ב-macOS השתמשו ב--j$(sysctl -n hw.ncpu)). TARGET הוא חובה – make ללא יעד נכשל עם ”Invalid or no TARGET specified“.

בנייה ראשונה מלאה, מקצה לקצה:

make sdk
make -j$(nproc) -C lib/micropython/mpy-cross
make -j$(nproc) TARGET=OPENMV4

14.1.1.2.1.1. לוחות נתמכים¶

ערכי TARGET הם שמות הספריות תחת boards/. המצלמות וצורת הסיליקון שלהן:

מצלמה	`TARGET`	MCU	Port	ליבה
OpenMV Cam M4	`OPENMV2`	STM32F427	stm32	Cortex-M4
OpenMV Cam M7	`OPENMV3`	STM32F765	stm32	Cortex-M7
OpenMV Cam H7	`OPENMV4`	STM32H743	stm32	Cortex-M7
OpenMV Cam H7 Plus	`OPENMV4P`	STM32H743 + SDRAM	stm32	Cortex-M7
OpenMV Pure Thermal	`OPENMVPT`	STM32H743 + SDRAM	stm32	Cortex-M7
OpenMV Cam N6	`OPENMV_N6`	STM32N657	stm32	Cortex-M55
OpenMV Cam RT1062	`OPENMV_RT1060`	MIMXRT1062	mimxrt	Cortex-M7
OpenMV AE3	`OPENMV_AE3`	Alif Ensemble (M55 כפול)	alif	Cortex-M55
Arduino Portenta H7	`ARDUINO_PORTENTA_H7`	STM32H747	stm32	Cortex-M7
Arduino Giga	`ARDUINO_GIGA`	STM32H747	stm32	Cortex-M7
Arduino Nicla Vision	`ARDUINO_NICLA_VISION`	STM32H747	stm32	Cortex-M7
Arduino Nano 33 BLE Sense	`ARDUINO_NANO_33_BLE_SENSE`	nRF52840	nrf	Cortex-M4
Arduino Nano RP2040 Connect	`ARDUINO_NANO_RP2040_CONNECT`	RP2040	rp2	Cortex-M0+

בנו את ה-TARGET המדויק עבור החומרה שלכם – למשל OPENMV4 עבור OpenMV Cam H7, OPENMV4P עבור H7 Plus, OPENMV_N6 עבור N6.

14.1.1.2.1.2. פלט הבנייה¶

כל מה ששייך ללוח נוחת ב-build/<TARGET>/bin/. עבור TARGET=OPENMV4 זהו build/OPENMV4/bin/, המכיל:

קובץ	מהו
`firmware.bin`	בינארי קושחה – נצרב על ידי OpenMV IDE Tools -> Load Custom Firmware ועל ידי `dfu-util`
`firmware.elf`	קושחה עם סמלי דיבאג – הקובץ שעליו אתם מכוונים את הדיבאגר
`bootloader.bin` / `.elf`	המאתחל (bootloader) (רק בלוחות שבהם המאתחל מופעל)
`openmv.bin`	תמונת מאתחל (bootloader) + קושחה משולבת
`romfs<n>.img`	תמונת מערכת קבצים ROM לקריאה בלבד הנצרבת לצד הקושחה

ה-Alif AE3 הוא דו-ליבתי, ולכן הוא מפיק firmware_M55_HP.elf / firmware_M55_HP.bin (ליבת הביצועים הגבוהים) וכן firmware_M55_HE.elf / firmware_M55_HE.bin נפרדים (ליבת היעילות הגבוהה) בתוספת תמונת תוכן עניינים (TOC) המורה ל-boot ROM היכן נמצאת תמונת כל ליבה.

14.1.1.2.1.3. ניקוי ובנייה מחדש¶

הבניות מבודדות לכל לוח תחת build/<TARGET>/. כדי למחוק את הבנייה של לוח אחד:

make TARGET=<TARGET> clean

אין distclean; clean תמיד זקוק ל-TARGET. mpy-cross משותף בין לוחות – אם אתם מעדכנים את MicroPython, בנו אותו מחדש גם:

make -C lib/micropython/mpy-cross clean
make -j$(nproc) -C lib/micropython/mpy-cross

כדי לדווח על ניצול הזיכרון flash/RAM של בנייה:

make TARGET=<TARGET> size

14.1.1.2.1.4. בנייה ב-Docker (ללא שרשרת כלים על המארח)¶

אם אתם מעדיפים לא להתקין דבר על המארח (או אם אתם בפלטפורמה ללא בנייה מקומית), השתמשו בנתיב ה-Docker:

git clone --recursive https://github.com/openmv/openmv.git
cd openmv/docker
make TARGET=<TARGET>

התוצרים מופיעים ב-openmv/docker/build/<TARGET>. עבור בניות חוזרות קיים נתיב פיתוח מצטבר המעגן את המאגר באותו נתיב מוחלט בתוך המכולה כמו על המארח, כך שנתיבי מקור הדיבאגר נפתרים ללא מיפוי מחדש:

make install-sdk
make build-firmware-dev TARGET=<TARGET>

הריצו make clean-dev בעת החלפת TARGET.

14.1.1.2.2. אפשרויות בנייה¶

התנהגות הבנייה נשלטת על ידי משתנים המועברים בשורת הפקודה של make, לדוגמה:

make -j$(nproc) TARGET=OPENMV4 DEBUG=1 V=1

המשתנים שבהם מפתח קושחה ישתמש:

משתנה	ברירת מחדל	השפעה
`TARGET`	(חובה)	הלוח לבנייה. בוחר את `boards/<TARGET>/board_config.mk`, אשר מגדיר את ה-MCU, הליבה, מפת הזיכרון, מזהי ה-USB והמודולים המופעלים.
`DEBUG`	`0`	`DEBUG=1` מהדר עם `-Og -ggdb3` (מותאם-לדיבאג, מידע דיבאג מלא של GDB) ומשבית את דחיסת טקסט ה-ROM של MicroPython – זוהי הבנייה שאתם מבצעים לה דיבאג. `DEBUG=0` מהדר עם `-O2 -DNDEBUG` (קטן יותר, מהיר יותר, ללא asserts) והיא בניית השחרור.
`V`	`0`	`V=1` מדפיס כל פקודת מהדר/מקשר במקום הסיכום הקצר `CC file.c`. השתמשו בו כדי לראות דגלים מדויקים או לאבחן בעיות בנייה.
`DEBUG_PRINTF`	`0`	`DEBUG_PRINTF=1` מגדיר את `OMV_DEBUG_PRINTF`, ומפעיל פלט `printf` של דיבאג ברמה נמוכה בקושחה (שלבו עם SWO/RTT, ראו ניפוי באגים של הקושחה).
`PROFILE_ENABLE`	`0`	`PROFILE_ENABLE=1` בונה עם מכשור קריאות-פונקציה (`-finstrument-functions`, `-DOMV_PROFILER_ENABLE=1`) כך שתוכלו לפרופל היכן מבלים זמן. `PROFILE_HASH=<N>` מגדיר את גודל טבלת הגיבוב של הפרופיילר (חזקה של שתיים; ברירת מחדל 256) ו-`PROFILE_IRQ=1` מפרופל גם קוד הרץ בהקשר פסיקה.
`STACK_PROTECTOR`	`0`	`STACK_PROTECTOR=1` מוסיף `-fstack-protector-all` – קנריות מחסנית הלוכדות גלישות חוצץ-מחסנית. שימושי בעת מרדף אחר השחתת זיכרון.
`DEBUGGER`	`JLINK`	באיזה דיבאגר משתמשים יעדי `make debug` / `make deploy`. `JLINK` הוא ברירת המחדל; `NONE` משבית את יעד ה-`debug`.

הערה

קיימים משתנים רבים נוספים (מנהלי התקן מצלמה/חיישן, מחסניות אלחוטיות, מנועי ML, מחסנית USB, אתחול מאובטח וכו«), אך אלה נקבעים לכל לוח ב-boards/<TARGET>/board_config.mk ובדרך כלל אינם נדרסים בשורת הפקודה. שינויָם הוא התאמה אישית של לוח, ולא בניית מפתח רגילה – ראו docs/boards.md במאגר הקושחה.

לעבודה יומיומית האפשרויות היחידות שאתם צריכים הן TARGET (תמיד), DEBUG=1 (בכל פעם שאתם מתכוונים לבצע דיבאג, ראו ניפוי באגים של הקושחה), ולעיתים V=1.