טיפים לשימוש ב-AI למהנדסי Embedded: המדריך המעשי

מהנדסי Embedded שמתחילים לשלב כלי AI בעבודה היומיומית חוסכים שעות של חפירה ב-Datasheets, כותבים קוד תשתית מהר יותר, ומגלים באגים שהיו לוקחים להם ימים למצוא. זו לא תחזית — זו מציאות. אבל — ויש פה "אבל" גדול — עולם ה-Embedded הוא לא Web development. כאן יש מגבלות זיכרון, דרישות Real-Time, רגיסטרים ספציפיים לחומרה, ותוצאה שגויה יכולה לשרוף רכיב פיזי. המדריך הזה לא ילמד אותך "מה זה AI". הוא ילמד אותך איך להשתמש ב-AI בצורה שבאמת עובדת בעולם שלנו — העולם שבו שורת קוד אחת לא נכונה מחממת מעבד ל-90 מעלות.

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

מה חייבים לציין בכל Prompt של Embedded?

כל פנייה לכלי AI צריכה לכלול חמישה פרטים מינימליים: סוג המיקרו-בקר (למשל STM32F407, ESP32-S3, nRF52840), מערכת ההפעלה (FreeRTOS, Zephyr, Bare-metal), הקומפיילר (GCC ARM, IAR, LLVM), מגבלות הזיכרון, ואיזו פריפריה מעורבת (SPI, I2C, UART, ADC). בלי הפרטים האלה — תקבלו קוד גנרי שלא עובר קומפילציה על הלוח שלכם.

נראה דוגמה. במקום לכתוב "Write me an SPI driver" — שזה מה שרוב האנשים עושים — כתבו ככה:

Write an SPI master driver for STM32F407VG using HAL library.
- SPI2 peripheral (PB13=SCK, PB14=MISO, PB15=MOSI, PB12=CS)
- Clock: 1 MHz, CPOL=0, CPHA=0
- Full-duplex mode
- Must work with FreeRTOS — use mutex for thread safety
- Target compiler: arm-none-eabi-gcc
- RAM budget: total 128KB, driver should use < 512 bytes stack
- Include error handling for timeout and bus fault

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

נקודת מפתח: Prompt גנרי = קוד גנרי. ככל שאתם ספציפיים יותר לגבי חומרה, RTOS ומגבלות — כך התוצאה שימושית יותר. חשבו על ה-Prompt כ-Hardware Spec של השאלה שלכם.

איך מפרקים בעיה מורכבת לסדרת Prompts?

מהנדסי Embedded מתמודדים עם בעיות שדורשות הבנה של כמה שכבות בו-זמנית — חומרה, דרייברים, לוגיקה עסקית, ותקשורת. במקום לזרוק את כל הבעיה בבת אחת, עבדו בשכבות:

שלב 1: בקשו את הגדרת הרגיסטרים והאתחול של הפריפריה. בדקו מול ה-Reference Manual — זה המקום שבו AI טועה הכי הרבה. שלב 2: בקשו את הפונקציות הבסיסיות (read, write, init, deinit). שלב 3: בקשו אינטגרציה עם ה-RTOS — tasks, queues, semaphores. שלב 4: בקשו Unit Tests.

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

לא כל משימה ב-Embedded מתאימה ל-AI. חלק מהמשימות הוא פותר בצורה מדהימה, וחלק — הוא מייצר קוד שנראה נכון אבל ישרוף לכם את הפרויקט. בואו נפרק את זה.

היכן AI חוסך הכי הרבה זמן?

כתיבת Boilerplate code: קוד אתחול פריפריות, הגדרות Clock, GPIO configuration — דברים שלוקחים זמן אבל הם שגרתיים. AI מצטיין בזה. ניתוח Datasheets: תעתיקו טבלת רגיסטרים מתוך Datasheet ותבקשו מה-AI להסביר כל ביט — זה חוסך שעות של קריאה. כתיבת Unit Tests: AI מייצר טסטים למודולים ב-C בצורה מהירה מאוד, כולל Mock functions לפריפריות. המרת קוד: מעבר מ-HAL של יצרן אחד לאחר, או מ-Bare-metal ל-RTOS — AI מבצע את ההמרה הראשונית ואתם מכווננים. תיעוד: Doxygen comments, README, תיעוד API — AI כותב את זה ברגע.

היכן חייבים לבדוק כל שורה?

Interrupt handlers: AI נוטה לשכוח לנקות flags, לא מבין priorities של NVIC, ומייצר race conditions. Timing-critical code: כל דבר שקשור ל-DMA transfers, Real-Time scheduling ו-Watchdog timers — AI לא מבין timing constraints ברמה שנדרשת. כתובות רגיסטרים ספציפיות: מודלים מזייפים כתובות רגיסטרים. חובה לאמת מול ה-Reference Manual של היצרן. זה לא ויכוח — זה עובדה.

טעות נפוצה: מהנדסים סומכים על AI בכתובות רגיסטרים בלי לבדוק. מודל שפה לא ניגש ל-Datasheet בזמן אמת — הוא "זוכר" ממה שאומן עליו, וזה לפעמים שגוי. תמיד תאמתו כתובות ו-bit fields מול המסמך הרשמי.

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

ההמלצה שלי? אל תתחייבו לכלי אחד. השתמשו ב-Copilot לכתיבת קוד שוטפת, ב-ChatGPT או Claude לדיאלוגים טכניים ודיבוג, וב-Gemini כשצריך לזרוק Datasheet של 800 עמודים ולשאול שאלות עליו.

שילוב AI בפרויקט Embedded אמיתי הוא לא "לשאול שאלה ב-ChatGPT". זה תהליך שצריך להיכנס לתוך ה-Workflow הקיים — מ-Bring-up של לוח חדש ועד CI/CD של Firmware.

מה נראה Workflow אמיתי עם AI?

שלב 1 — Bring-up: קיבלתם לוח חדש עם מיקרו-בקר שלא עבדתם איתו. במקום לבלות יום שלם בקריאת Reference Manual — העלו את ה-Datasheet ל-Gemini או ChatGPT ושאלו: "מה ה-Clock tree של הרכיב הזה? מה ה-default clock configuration after reset?" תוך דקות יש לכם תמונה ברורה.

שלב 2 — Scaffolding: בקשו מ-AI ליצור את מבנה הפרויקט — CMakeLists.txt, Linker script בסיסי, startup code. הנה דוגמה אמיתית של Prompt ותוצאה עבור CMake:

# CMakeLists.txt for STM32F407 with FreeRTOS
# Generated with AI assistance — verified and adjusted manually

cmake_minimum_required(VERSION 3.20)

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER arm-none-eabi-g++)
set(CMAKE_ASM_COMPILER arm-none-eabi-gcc)

project(embedded_ai_demo C ASM)

set(MCU_FLAGS "-mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard")
set(CMAKE_C_FLAGS "${MCU_FLAGS} -Wall -Wextra -Os -ffunction-sections -fdata-sections")
set(CMAKE_EXE_LINKER_FLAGS "${MCU_FLAGS} -T${CMAKE_SOURCE_DIR}/STM32F407VGTx_FLASH.ld -Wl,--gc-sections -specs=nano.specs")

# Source files
file(GLOB_RECURSE SOURCES
    "Core/Src/*.c"
    "Drivers/STM32F4xx_HAL_Driver/Src/*.c"
    "Middlewares/FreeRTOS/*.c"
)

# Include directories
include_directories(
    Core/Inc
    Drivers/STM32F4xx_HAL_Driver/Inc
    Drivers/CMSIS/Device/ST/STM32F4xx/Include
    Drivers/CMSIS/Include
    Middlewares/FreeRTOS/include
)

add_executable(${PROJECT_NAME}.elf ${SOURCES})

# Generate .bin and .hex
add_custom_command(TARGET ${PROJECT_NAME}.elf POST_BUILD
    COMMAND arm-none-eabi-objcopy -O binary $ ${PROJECT_NAME}.bin
    COMMAND arm-none-eabi-objcopy -O ihex $ ${PROJECT_NAME}.hex
    COMMAND arm-none-eabi-size $
)

שלב 3 — כתיבת דרייברים: בקשו מ-Copilot או ChatGPT ליצור את הדרייבר הבסיסי. בדקו כל כתובת רגיסטר. תקנו. המשיכו.

שלב 4 — טסטים: כאן AI באמת זורח. תנו לו את הפונקציה שכתבתם ובקשו Unit Tests עם Unity או CUnit framework:

// Unit test for SPI driver - generated with AI, reviewed manually
#include "unity.h"
#include "spi_driver.h"
#include "mock_stm32f4xx_hal_spi.h"

void setUp(void) {
    // Reset SPI state before each test
    SPI_Driver_DeInit();
}

void tearDown(void) {}

void test_SPI_Init_Should_Configure_Baudrate(void) {
    SPI_Config_t config = {
        .baudrate = SPI_BAUDRATE_1MHZ,
        .mode = SPI_MODE_MASTER,
        .cpol = 0,
        .cpha = 0
    };

    HAL_SPI_Init_ExpectAndReturn(NULL, HAL_OK);
    HAL_SPI_Init_IgnoreArg_hspi();

    SPI_Status_t result = SPI_Driver_Init(&config);
    TEST_ASSERT_EQUAL(SPI_OK, result);
}

void test_SPI_Transfer_Should_Return_Error_On_Timeout(void) {
    uint8_t tx_buf[4] = {0x01, 0x02, 0x03, 0x04};
    uint8_t rx_buf[4] = {0};

    HAL_SPI_TransmitReceive_ExpectAndReturn(NULL, NULL, NULL, 4, 100, HAL_TIMEOUT);
    HAL_SPI_TransmitReceive_IgnoreArg_hspi();
    HAL_SPI_TransmitReceive_IgnoreArg_pTxData();
    HAL_SPI_TransmitReceive_IgnoreArg_pRxData();

    SPI_Status_t result = SPI_Driver_Transfer(tx_buf, rx_buf, 4);
    TEST_ASSERT_EQUAL(SPI_ERR_TIMEOUT, result);
}

void test_SPI_Init_Should_Fail_On_NULL_Config(void) {
    SPI_Status_t result = SPI_Driver_Init(NULL);
    TEST_ASSERT_EQUAL(SPI_ERR_INVALID_PARAM, result);
}

int main(void) {
    UNITY_BEGIN();
    RUN_TEST(test_SPI_Init_Should_Configure_Baudrate);
    RUN_TEST(test_SPI_Transfer_Should_Return_Error_On_Timeout);
    RUN_TEST(test_SPI_Init_Should_Fail_On_NULL_Config);
    return UNITY_END();
}

שלב 5 — CI/CD: שילוב AI גם ב-Pipeline. הנה דוגמה ל-GitHub Actions שמקמפל Firmware אוטומטית:

# .github/workflows/firmware-build.yml
name: Firmware Build & Test

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    container:
      image: xpack/arm-none-eabi-gcc:latest

    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive

      - name: Install dependencies
        run: |
          apt-get update && apt-get install -y cmake ruby
          gem install ceedling

      - name: Run Unit Tests
        run: |
          ceedling test:all

      - name: Build Firmware
        run: |
          mkdir -p build && cd build
          cmake .. -DCMAKE_BUILD_TYPE=Release
          make -j$(nproc)

      - name: Check binary size
        run: |
          arm-none-eabi-size build/embedded_ai_demo.elf
          # Fail if .text exceeds 256KB
          TEXT_SIZE=$(arm-none-eabi-size build/embedded_ai_demo.elf | tail -1 | awk '{print $1}')
          if [ "$TEXT_SIZE" -gt 262144 ]; then
            echo "ERROR: .text section exceeds 256KB limit!"
            exit 1
          fi

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: firmware-binary
          path: build/embedded_ai_demo.bin

מתי כדאי להשתמש ב-Edge AI (TinyML) על המיקרו-בקר עצמו?

Edge AI — הרצת מודלים של למידת מכונה ישירות על מיקרו-בקרים — הוא אחד התחומים הצומחים ביותר ב-Embedded בשנים האחרונות. לפי סקרים בתעשייה, מעל 60% מפרויקטי IoT חדשים משלבים רכיב של עיבוד מקומי חכם. הסיבות ברורות: פרטיות (הנתונים לא עוזבים את המכשיר), השהייה נמוכה (אין צורך בענן), וחיסכון באנרגיה ובתקשורת.

כלי AI כמו ChatGPT ו-Copilot עוזרים מאוד בהקמה של פרויקטי TinyML. הם יכולים לייצר קוד Python לאימון מודל ב-TensorFlow Lite for Microcontrollers, להמיר מודל לפורמט שרץ על MCU, ולכתוב את קוד ה-C שקורא ל-Inference. הנה דוגמה בסיסית של סקריפט אימון והמרה:

# train_and_convert_tinyml.py
# Train a simple anomaly detection model and convert for MCU deployment

import tensorflow as tf
import numpy as np

# Generate synthetic sensor data (e.g., vibration readings)
np.random.seed(42)
normal_data = np.random.normal(loc=0.0, scale=1.0, size=(1000, 64))
anomaly_data = np.random.normal(loc=3.0, scale=2.0, size=(100, 64))

X_train = normal_data.astype(np.float32)

# Simple autoencoder for anomaly detection
model = tf.keras.Sequential([
    tf.keras.layers.InputLayer(input_shape=(64,)),
    tf.keras.layers.Dense(32, activation='relu'),
    tf.keras.layers.Dense(16, activation='relu'),
    tf.keras.layers.Dense(32, activation='relu'),
    tf.keras.layers.Dense(64, activation='sigmoid')
])

model.compile(optimizer='adam', loss='mse')
model.fit(X_train, X_train, epochs=50, batch_size=32, validation_split=0.1, verbose=1)

# Convert to TFLite with int8 quantization for MCU
def representative_dataset():
    for i in range(100):
        yield [X_train[i:i+1]]

converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8

tflite_model = converter.convert()

with open('anomaly_model.tflite', 'wb') as f:
    f.write(tflite_model)

print(f"Model size: {len(tflite_model)} bytes")
print(f"Model size: {len(tflite_model) / 1024:.1f} KB")

# Convert to C array for embedding in firmware
with open('anomaly_model.h', 'w') as f:
    f.write('#ifndef ANOMALY_MODEL_H\n#define ANOMALY_MODEL_H\n\n')
    f.write(f'const unsigned int anomaly_model_len = {len(tflite_model)};\n')
    f.write('alignas(8) const unsigned char anomaly_model[] = {\n')
    for i, byte in enumerate(tflite_model):
        f.write(f'0x{byte:02x}, ')
        if (i + 1) % 12 == 0:
            f.write('\n')
    f.write('\n};\n\n#endif // ANOMALY_MODEL_H\n')

print("C header generated: anomaly_model.h")

שימו לב — הקוד הזה ייוצר על ידי AI תוך דקות. אבל אתם צריכים לבדוק שגודל המודל מתאים ל-Flash של המיקרו-בקר שלכם, שה-Quantization לא הרס את הדיוק, ושה-Inference time עומד בדרישות ה-Real-Time. AI לא יבדוק לכם את זה.

שורה תחתונה לפועלים: AI הוא ה-Junior Developer הכי מהיר שיש — אבל הוא דורש Code Review צמוד. ב-Embedded, הפער בין "קוד שנראה נכון" ל"קוד שעובד על החומרה" יכול להיות הרסני. השתמשו ב-AI לייצר, השתמשו במוח שלכם לאמת.

דיבוג ב-Embedded הוא סיפור אחר לגמרי מדיבוג בתוכנה. אין לכם console.log. יש לכם אוסילוסקופ, Logic Analyzer, ולפעמים רק LED אחד שמהבהב. כאן AI יכול לעזור בצורה מפתיעה.

איך מנתחים שגיאות HardFault עם AI?

כשהמיקרו-בקר נכנס ל-HardFault — וזה קורה, לכולם — יש לכם רגיסטרים עם מידע מפורט על מה קרה. תעתיקו את הערכים ל-ChatGPT עם ההקשר הנכון:

My STM32F407 hit a HardFault. Here are the fault registers:
- CFSR (Configurable Fault Status Register): 0x00000400
- HFSR (HardFault Status Register): 0x40000000
- MMFAR: 0x00000000
- BFAR: 0x20030000
- Stack frame at fault:
  R0=0x20001234 R1=0x00000000 R2=0x08004A3C R3=0x00000001
  R12=0x00000000 LR=0x08003B21 PC=0x08004A40 PSR=0x61000000

My linker script defines:
- RAM: 0x20000000 - 0x20020000 (128KB)
- Stack top: 0x20020000

What caused this fault? Which register values indicate the problem?

AI יפרק את כל הביטים, יסביר שמדובר ב-Bus Fault כי BFAR מצביע על כתובת מעבר לגבול ה-RAM, ויציע שזה כנראה Stack Overflow או גישה ל-Buffer לא מוקצה. תוך שניות יש לכם כיוון חקירה — במקום שעה של חפירה בתיעוד ARM.

מה עוד אפשר לנתח עם AI?

תוצאות Logic Analyzer: ייצאו את הנתונים כ-CSV, העלו ל-AI ובקשו ניתוח — "למה יש Glitch על קו ה-CS?" או "מה ה-Baud rate בפועל לעומת מה שהגדרתי?". צריכת זרם: אם מדדתם פרופיל צריכה — AI יכול לזהות מצבים שבהם הרכיב לא נכנס ל-Sleep mode כמצופה. ניתוח Linker Map files: תזרקו את ה-.map file ותשאלו "איזה מודולים תופסים הכי הרבה Flash?" — מקבלים תשובה מיידית.

AI לא הולך להחליף מהנדסי Embedded — הוא הולך להפוך אותם ליעילים בצורה דרמטית. מי שילמד להשתמש בכלים האלה נכון, עם ההבנה שקוד Embedded דורש אימות מול חומרה אמיתית, ימצא את עצמו מסיים פרויקטים מהר יותר, עם פחות באגים, ועם הבנה עמוקה יותר של המערכת.

• תמיד ציינו ב-Prompt את סוג המיקרו-בקר, RTOS, קומפיילר ומגבלות זיכרון — הפרטים האלה הופכים תשובה גנרית לתשובה שימושית.
• השתמשו ב-AI לייצור Boilerplate, טסטים ותיעוד — שם הוא חוסך הכי הרבה זמן בלי סיכון גבוה.
• אמתו כל כתובת רגיסטר מול ה-Datasheet הרשמי — AI מזייף כתובות. זה לא חולשה שתיפתר בקרוב.
• פרקו בעיות מורכבות לשרשרת Prompts — שכבה אחרי שכבה, עם אימות בין לבין.
• שלבו AI ב-CI/CD Pipeline — בדיקות אוטומטיות, בדיקת גודל Binary, Static Analysis.

עודכן: 2026-10-05

האם AI יכול לכתוב Firmware שלם מאפס?

לא. AI יכול לייצר חלקים משמעותיים של הקוד — Boilerplate, דרייברים בסיסיים, טסטים — אבל Firmware שלם דורש הבנת מערכת שאין ל-AI: מגבלות תזמון, אינטראקציות בין פריפריות, דרישות אמינות ובטיחות. השתמשו ב-AI ככלי שמאיץ אתכם, לא ככלי שמחליף אתכם.

איזה מודל AI הכי טוב לקוד C של Embedded?

נכון להיום, GPT-4o ו-Claude מציגים את התוצאות הטובות ביותר לקוד C/C++ ממוקד Embedded. GitHub Copilot מצוין להשלמה בזמן אמת בתוך IDE. לניתוח Datasheets ארוכים, Gemini עם חלון ההקשר הגדול שלו עדיף. אין פתרון אחד — שלבו כלים.

האם בטוח להשתמש ב-AI כשעובדים על פרויקט עם IP רגיש?

זו שאלה קריטית. כשמשתמשים ב-ChatGPT או Copilot בענן — הקוד שלכם עובר לשרתים חיצוניים. חברות ישראליות רבות בתחום הביטחוני אוסרות שימוש בכלי AI חיצוניים. פתרונות: הרצת מודלים מקומיים כמו Code Llama, שימוש ב-GitHub Copilot Enterprise עם הגדרות פרטיות, או עבודה עם API שמוגדר לא לשמור נתונים. תמיד בדקו את מדיניות החברה.

כמה זמן לוקח למהנדס Embedded ללמוד להשתמש ב-AI ביעילות?

מהנדסים שמגיעים עם ניסיון ב-Embedded מתחילים לראות תוצאות תוך שבוע-שבועיים של שימוש יומיומי. המעבר מ"AI ככלי שאלות" ל-"AI כחלק מה-Workflow" לוקח בדרך כלל חודש-חודשיים. ההשקעה מחזירה את עצמה מהר — במיוחד בכתיבת טסטים ותיעוד.

האם TinyML רלוונטי לכל פרויקט Embedded?

לא. TinyML רלוונטי כשיש צורך בזיהוי תבניות, חריגות, או קלט חיישנים שדורש עיבוד חכם — למשל Predictive Maintenance, זיהוי קול, זיהוי תנועה. אם הפרויקט שלכם הוא בקר תעשייתי פשוט עם לוגיקה דטרמיניסטית — TinyML מיותר. אל תשלבו טכנולוגיה בשביל הבאזז.

מה ההבדל בין שימוש ב-AI ב-Embedded לעומת פיתוח Web?

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

האם יש סכנה שאסתמך יותר מדי על AI ואפסיק ללמוד?

כן, וזו סכנה אמיתית. AI נותן תשובות מהירות — אבל אם לא מבינים למה הקוד עובד, לא תדעו לתקן כשהוא לא עובד. כלל אצבע: אם AI נתן לכם קוד שאתם לא יכולים להסביר שורה-שורה — עצרו ולמדו. AI הוא מאיץ ללמידה, לא תחליף ללמידה.

אם הגעת עד לכאן — יש לך את הסקרנות הנכונה. וסקרנות היא בדיוק מה שמפריד בין מי שמשתמש ב-AI ככלי לחיפוש מהיר לבין מי שהופך אותו למנוע פיתוח אמיתי. אנחנו רואים אותך כבר כמה צעדים קדימה — גם אם אתה עדיין לא. באתר rt-ed.co.il יש מדריכים נוספים על Embedded, Edge AI ו-TinyML — כולם כתובים מנסיון אמיתי של מהנדסים שעובדים על חומרה אמיתית, לא על מצגות. בוא ללמוד, לנסות, לשבור ולתקן. ככה בונים מהנדסים.

• קורס סייבר ואבטחת מידע
• קורס Real Time Embedded
• קורס דאטה סיינס
• קורס למידת מכונה AI
• קורס דאטה אנליסט
• קורס DEVOPS
• קורס IT
• קורס אוטומציה
• קורס Full Stack
• קורס בניית אתרים