Drohnen, Steuerung +Transfer Sensordaten, nRF52840, ARM Cortex-M4, Bluetooth 5, BLE

• Aufbau +Inbetriebnahme Entwicklungsumgebung (IAR Embedded Workbench for ARM)
• FreeRTOS, Integration +Konfiguration +Test
• Anschluss +Ansteuerung eines sog. E-Paper-Display über SPI, Anpassung SPI-Treiber
• Implementierung HW-unabhängiger Zwischenschichten über Display-Ansteuerung und FreeRTOS
• Optimierung E-Paper-Display-Ansteuerung + Test
• Erstellung Konzept zur universellen Inter-Prozessor-Kommunikation (IPC) zwischen den einzelnen Teilnehmern des Bluetooth-Netzwerkes (BLE-Sensoren, Smartphone, PC mit BLE-Sniffer), als auch komplett innerhalb einer Simulation auf einem Windows/Linux-PC ohne Bluetooth-HW

Automotive, E-Mobility, SW-Entwicklung im Projekt Batterie Management Unit

• Aufsetzen Build-Umgebung, TortoiseSVN, Repo, Compiler
• Analyse SW Architektur
• Flashen des Zielsystems über CAN und/oder Lauterbach-Debugger
• Entwicklung Simulationsumgebung für Modultests, da einfache Tests auf dem Zielsystem zu zeitaufwendig
• Portierung RTE-Umgebung (Autosar) + Simulation auf PC zum Build + Test unter MS-Visual-Studio, dadurch Beschleunigung von SW-Entwicklung +Test um den Faktor 100 (1-2 Sekunden statt 30 Minuten)
• Entwicklung diverser Module + Test auf Windows-PC

Automotive, E-Mobility, SW-Entwicklung, Ladeadapter für einen rein elektrischen Sportwagen

• Aufbau Entwicklungsumgebung (IAR, Anpassung J-Link Script für Cortex-A9/M4)
• FreeRTOS, Integration +Test +Konfiguration
• Implementierung/Anwendung vorhandenen Codes für die Inter-Prozessor-Kommunikation RPMsg für A9 (Linux) / M4 (FreeRTOS)
• Erstellung Konzept zur universellen Inter-Prozessor-Kommunikation (IPC) zwischen den beiden CPU's (A9/M4) des i.MX6SoloX
• Entwicklung eines universellen Message-Formats für Kommunikation zwischen den Prozessoren/Threads o Eigen-Entwicklung eines RPMsg-Ersatzes für die IPC-Kommunikation (A9/M4) nur unter FreeRTOS mit Hilfe des MU-Registers des i.MX6SoloX zum Test (A9/M4)auch ohne Linux
• Installation Qt-Toolchain mit Qt-Creator auf PC mit Linux Ubuntu 14.04 LTS
• Installation Cross-Compiler/Debugger für ARM-Target in QT-Creator
• Da der Vector-CAN-Stack für den benutzten Prozessor NXP i.MX6SoloX noch nicht lieferbar war, Eigen-Entwicklung einer Zwischenlösung aufbauend auf den FlexCAN-Modulen von NXP
• Integration und Inbetriebnahme Vector-CAN-Stack, Konfiguration mit GENy
• Entwicklung LED-Treiber mit I2C-Interface zum RGB-LED-Controller mit diversen Funktionen wie Blinken, Fading usw..
• Entwicklung EEPROM-Treiber mit I2C-Interface zum EEPROM
• Entwicklung Testumgebung über CAN-IsoTp
• Entwicklung UDS-Funktionalität wie z.B. UDS_Read/WriteDataByIdentifier()
• Entwicklung diverser Test-Routinen für Test des sog. PWR-Boards
• Entwicklung PWR-Board-Simulation auf einem eigenen Cortex-M4-Board (FRDM-K64F, NXP) mit Debug-Ausgabe über SPI auf FPGA-Board (DE0-Nano (ALtera/Terasic) +TFT- Display, alles selbstentwickelt, siehe unten)
• Portierung der gesamten M4-SW auf einen Lade-Adapter mit verändertem Funktionsumfang, anderer CPU (M7) +OS (ThreadX)
• Bei der Portierung wurde der Vector-CAN-Stack (inkl. IsoTp) durch eine Eigen-Entwicklung ersetzt
• Realisierung einer OS-Zwischen-Schicht zwischen Applikation und OS (FreeRTOS, ThreadX, Windows)
• Entwicklung eines Tools (MS Visual-C) zum Export der Signal/Nachrichten-Infos aus DBC-Files in include-Files (C-Syntax) +csv

Automotive, Batterieladestation, ZigBee, Demo, Aufbau Entwicklungsumgebung (Hard- +und Software)

Hardware:

• Anschluss ZigBee-Modul (XBee pro) #1 an ein FPGA-Entwicklungsboard De1-SoC (ALtera/Terasic/ARM) mit 2 x Cortex A9 +Linux)
• Anschluss ZigBee-Modul #2 an ein FPGA-Entwicklungsboard DE0-Nano (ALtera/Terasic)
• Anschluss von jeweils einem Cortex-M4-Board
• Die Verbindung zwischen den Cortex-M4-Boards und dem jeweiligem FPGA erfolgt über SPI mit der maximal möglichen Datenrate von 16 MBit/s. 

Kommunikationswege:

• ZigBee-Modul -> FPGA-UART -> FPGA-SPI -> M4-SPI -> Cortex-M4
• Cortex-M4 -> M4-SPI -> FPGA-SPI -> FPGA-UART -> ZigBee-Modul
• Cortex-M4 -> M4-SPI -> FPGA-SPI -> FPGA-GPU -> TFT-Display bzw. VGA
• ARM Cortex A9 -> "HPS to FPGA Bridge" -> FPGA-GPU -> TFT-Display bzw. VGA
• sämtliche VHDL-Module (wie z.B.: FPGA-SPI, FPGA-UART, FPGA-GPU, SDRAM-Controller, Video-in/out, GPU (Grafik-Processing-Unit), Logic-Analyzer, Auslesen ADC, usw..) wurden von mir selbst entwickelt.

Ausnahme:

Falls geeignete Module wie z.B. Fifo in der Altera-Lib (MegaWizard) vorhanden waren, wurden diese natürlich verwendet.

Software:

• IAR Embedded Workbench +rtos MQX-4.1
• selbstentwickelte Interface-Library zum FPGA
• Funktionen für Datenübertragung innerhalb eines ZigBee-Netzwerkes (API-Mode)
• Darstellung der gesendeten/empfangenen ZigBee-Nachrichten über den Cortex-M4 an das FPGA (selbstentwickelte GPU (Grafik-Processing-Unit, VHDL)).
• Installation Yocto-Linux +Testprogramm auf FPGA-Entwicklungsboard De1-SoC

Automotive, Laser-Scanner, Low-Level-Design, Code-Refactory, Modultests

• Installation Entwicklungsumgebung (QT, Doxygen, Python)
• Überarbeitung +Generierung Low-Level-Design Dokumente mit Doxygen aus Sourcecode
• Überarbeitung +Erweiterung Modultests (C++) bis Code/Branch-Coverage 100%/98% (gcov)erreicht wurde, Verknüpfung mit DOORS-Anforderungen, Gen. Testreport
• Überarbeitung der C++-Klassen entsprechend PC-Lint-Warnungen

Automotive, Parkassistenz-System, Source-Code-Generierung aus DOORS-export

• Installation Entwicklungsumgebung (perl)
• perl-script Entwicklung für Konvertierung: XLS (DOORS-export) -> XML -> C-Source und XML -> XLS Erzeugte C-Source war MISRA-konform

Automotive, Parkassistenz-System, Power-PC Controller, HW-nahes Debugging

• Installation Entwicklungsumgebung (GHS-Compiler, WinIdea, CANoe usw..)
• Bearbeitung diverser Tickets (Bugfix, QAC, Korrektur Source-Files)

Mitarbeit an der SW-Entwicklung für einen Gaszähler (mit ARM Cortex-M3)

• MISRA-kompatible Portierung der "Testing Framework for C, CUnit" zum Ablauf auf der Zielhardware (ARM Cortex-M3 von STM) als auch   auf einem Windows-PC. Es wurden nur die Funktionen aus CUnit portiert, die auch wirklich benötigt wurden. Zusätzlich wurden Funktionen für die formatierte Ausgabe über die UART-Schnittstelle entwickelt. Vereinfachung (Source-Code-Umfang) gegenüber CUnit-Original: Faktor 20
• Entwicklung diverser SW-Module +CUnit-Tests (u.a. Timer, UART usw..)

Echtzeitsysteme, FPGA-Design, ZigBee (HW/SW-Entwicklung)

• Integration eines handelsüblichen ZigBee-Moduls in ein FPGA-Projekt
• Anschluss USB-Serial-Converter von FTDI an das FPGA zur Konfiguration des ZigBee-Moduls über das Tool XCTU des Herstellers Digi International
• HW-Entwicklung:
  • UART-Modul in VHDL (FPGA) + HW-Fifo für Nios2
  • Switch zwischen UART-Nios2 +UART-USB
• SW-Entwicklung:
  • Treiber für UART (230 KB)
  • Funktionen für Datenübertragung innerhalb eines      ZigBee-Netzwerks (API-Mode)
• die HW wurde 2 x aufgebaut, an jeder HW kann ein TFT-Display zur Datenvisualisierung angeschlossen werden.   Die Text/Grafik-Ein-/Ausgabe erfolgte über den Softcore-Prozessor Nios2 an das FPGA (selbstentwickelte GPU (Grafik-Processing-Unit, VHDL)).
• Durchführung eines Feldtests zur Bestimmung des max. möglichen Datendurchsatzes +Reichweite
• der verwendete Softcore-Prozessor Nios2 bootet direkt aus dem EPCS-Flash des FPGA
• Anschluss des Dev-Boards FRDM-K64F (Kinetis K64, ARM Cortex-M4) von Freescale über die SPI-Schnittstelle (16 MBaud) an das FPGA
• HW-Entwicklung (VHDL) eines SPI-Moduls (Slave) auf dem FPGA
• HW-Entwicklung (VHDL, schematisch) zur Koppelung des SPI-Moduls an die selbstentwickelte GPU (Grafik-Processing-Unit, VHDL)
• SW-Entwicklung (C) eines SPI-Treibers für ARM Cortex-M4
• SW-Entwicklung (C) diverser Funktionen für die Text+Grafikausgabe über SPI an das FPGA
• Integration des selbstentwickelten Logic-Analyzers (VHDL) in das FPGA zur Visualisierung der HW-Signale (SPI_MOSI,.. ZigBee UART usw..)
• HW-Entwicklung (VHDL): Implementierung Touch-Screen-Interface (resistiv) mit Auslesen ADC, Konvertierung in Screen-Koordinaten, Button-Interface usw.. innerhalb des Video-Kontrollers (FPGA) +Interface zum SPI-Kontroller
• SW-Entwicklung (C): Realisierung SW-Funktionen zum Touch-Screen-Interface

• Integration/Aktivierung Softcore-CPU Nios II mit dem Altera Quartus-II Design-Tool Qsys +SW-Boot aus dem EPCS-Flash.
• Integration/Aktivierung HPS (Hard Processor System = 2x ARM Cortex-A9, 800 Mhz) im Kameraprojekt (FPGA-Entwicklung mit Cyclone-V SoC, Altera) mit dem Altera Quartus-II Design- Tool Qsys.
• Entwicklung von Interface-Funktionen in ANSI-C auf der HPS-Seite (CPU=ARM Cortex-A9) zum Testen der Kommunikation CPU <-> FPGA.
• Entwicklung/Integration PCIe-Interface (PCI-Express) mit dem Quartus-II Design-Tool Qsys auf dem FPGA Cyclone-IV GX. (Dieses PCIe-Interface (PCIe x 1, max. 250 MByte/s Duplex) verbindet das FPGA Cyclone-IV GX mit der CPU (Intel Atom)
• Entwicklung/Anpassung/Integration PCI-Express-Treiber für Win7 und embedded Linux (Yocto)
• Zum Test des PCIe-Interface wurde des selbstentwickelte Finite-Elemente-Programm verwendet, das die Grafik-Befehle über das PCIe-Interface an die selbstentwickelte GPU (Grafik-Processing-Unit, FPGA) ausgibt. Dieses Testprogramm läuft auf der CPU-Seite (Intel Atom) sowohl unter Windows-7, als auch Linux (Yocto). Auf dem Cyclone-V SoC (ARM Cortex A9) nur unter Linux (Yocto).
• Das Testprogramm ist übrigens ein mit MS Visual Studio 2008 bzw. gcc erzeugtes Konsolen-Programm, d.h. es werden nicht die entsprechende API von Linux oder Win7 zur Grafikausgabe benutzt. Diese Grafikausgaben gehen über DE2i-150(FPGA Cyclone IV GX + Intel Atom): Intel-Atom -> PCIe -> GPU(FPGA) -> TFT-Display DE1-SoC (FPGA Cyclone V Soc (inkl. ARM Cortex A9)): ARM Cortex A9 -> "HPS to FPGA Bridge" -> GPU(FPGA) -> TFT-Display

• Integration und Test des selbstentwickelten Realtime-Kernels rtos32 auf dem FPGA-Entwicklungsboard DE2i-150 (Terasic/Altera /Intel). Messen der Datentransferrate zwischen 2 Threads über Message-Queues (Message-Size: 1 KByte, Taskwechselfrequenz: 0,99 MHz, Datentransferrate: 968 MByte/s).
  • Kurzbeschreibung des Echtzeit-Kernels rtos32:
    • läuft im Ring-0, d.h. alternativ zu Win7/Linux
    • Source-Code (> 12000 Zeilen) in x86-Assembler (32-bit protected mode, Speichermodell: FLAT)
    • pre-emptive scheduling (direkte Aktivierung einer wartenden Task aus einer Interrupt-Service-Routine)
  • Intertask-Kommunikation:
    • Events (32 pro Task)
    • Semaphore
    • Message-Queues
  • beliebige Anzahl von SW-Timer
  • Kennzahlen (getestet auf dem FPGA-Entwicklungsboard DE2i-150 (CPU: 1,6 GHz Intel Atom N2600):
    • SetEvents + WaitEvents +Taskwechsel = 0.489 us
    • ReleaseSM + GetSM +Taskwechsel = 0.574 us
    • SendMail + GetMail (1 KByte) +Taskwechsel = 1.009 us
• Im Einzelnen wurden u.a. folgende Funktionseinheiten, Module (VHDL) entwickelt. Verwendbar sind sie z.B. für die FPGA's Cyclone-IV GX und Cyclone-V SoC. Getestet wurden sie auf den FPGA-Entwicklungsboards DE2i-150 (Terasic/Altera/Intel), DE1-SoC (Terasic/Altera/ARM), DE0-Nano(Terasic/Altera), dem selbstentwickelten Logic- Analyzer und mit ModelSim):
  • SDRAM-Controller für SDRAM (32Mx16), (100 % Eigenentwicklung, nicht Qsys-Lib!) Die Entwicklung erfolgte mit Hilfe eines VHDL-Simulations-Modell für ein DDR-RAM, das von mir auf SDRAM umgeschrieben wurde, einer Testumgebung +ModelSim:
    • Speichertakt: 125 MHz
    • Datenrate: 240 Myte/s (max. 250 MByte/s theoretisch möglich)
    • Burstmode: 1..256 (variabel)
    • 2-Kanal-FIFO-Interface:
      • XGA-Interface (VGA Video Display), 125 MByte/s
      • GPU (davon 27 x 2 = 54 MByte/s für Video-Signal, verbleiben max. 60 MByte/s für GPU-Befehle wie DrawTo(x,y)
  • cam_video_ctrl
  • Video-Display-Controller für VGA/TFT-RGB-Monitore, stellt neben den Videodaten aus dem SDRAM (125 MByte/s) auch den Inhalt eines Text-Framebuffer dar (Overlay, 128x48 ASCII-Zeichen).
  • cam_gpu_ctrl
    • nimmt die Kamera-Signale (55 MByte/s) aus dem cam_fifo entgegen und sendet sie als Packet an den SDRAM-Controller
    • nimmt die Grafik-Kommandos von der CPU entgegen und überträgt die zu setzenden Pixel an den SDRAM-Controller
  • Entwicklung eines VHDL-Moduls zum Einlesen des Video-Kamera- Signals über ADV7180 (SDTV Video Decoder) inkl. Initialisierung über I2C
  • Entwicklung VHDL-Modul zur Text-Ausgabe auf LCD-Display (2x16)
  • Realisierung (100 % Eigenentwicklung) eines Soft-Core 16-bit RISC Prozessors (ähnlich zum XGATE der Fa. Freescale), 125 MIPS auf FPGA Cyclone-IV (125 Mhz Takt)
  • Entwicklung eines Einfachst-Logik-Analysator zum Testen der FPGA-internen/externen Signale. Sehr geringer Resourcenverbrauch ( < 5 % auf 5CSEMA5F31C6), benötigt kein externes RAM (z.B. SDRAM, SRAM) für die Darstellung der Logik-Signale auf dem Monitor. Komplett unabhängig vom Rest, da eigener Video-Controller usw. Sample-Rate: 8 ns, 16-Kanal, Ausgabe auf VGA/RGB-TFT-Interface

• Überarbeitung MemStack, RTE-Generierung mit CESSAR
• Integration, diverse Fehlerbeseitigungen auf Grund der Ergebnisse der FAT-Tests
• Unterstützung +Einarbeitung neuer SW-Team-Mitglieder

Automotive-Bereich, München Mitarbeit an einem Radar-basierten Fahrerassistenz-System in insgesamt 5 Subprojekten

• Portierung der gesamten Rahmen-SW vom MPC5675K (Komodo) auf den MPC5775 (Racerunner) aufbauend auf den Ergebnissen der Basis-SW-Entwicklung und der bestehenden SW für MPC5675K (Komodo, mit Ethernet). Zum Startzeitpunkt der Portierung war keinerlei Unterstützung von Seiten der Basis-SW-Entwicklung bzgl. Ethernets vorhanden. Ausnahme: MCAL (Ethernet) für MPC5775 von Freescale war verfügbar
• Integration MCAL (Ethernet) MPC5775 (Racerunner)
• Anpassung TCP/IP-Stack
• Fehlerbeseitigung
• Diese Portierung wurde von mir praktisch alleine innerhalb von 2 Monaten durchgeführt.
• Daneben leistete ich Support für das Bootloader-Team, damit der Bootloader für den Racerunner ebenfalls Ethernet-fähig gemacht werden konnte.
• Integration Bootloader +Applikation (beides Ethernet) o nach 2 Monaten funktionierte die Diagnose über Ethernet mit den BMW-Tools Diagnoser und EDIABAS.
• mit ESys konnte dann auch das Racerunner-Steuergerät über Ethernet geflasht und codiert werden.
• FAT-Tests waren ebenfalls möglich.
• Übergabe der gesamten Portierung +Know-How an das SW-Entwicklungs-Team

• Umstellung der Rahmen-SW auf Autosar-4.0 / 4.1
• Umstellung Diagnose auf Ethernet
• Durchführung FAT-Tests +Fehlerbeseitigung

• Portierung eines EBI-Interfaces (der Datentransfer erfolgte per DMA) vom MPC5674F (Lyre) auf MPC5675K (Komodo)   (Interface zwischen einem XILINX-FPGA und dem Mikro-Kontroller)
• Anpassung des Bootloaders an den MPC5675K
• Überarbeitung Bootloader für Download des FPGA-Codes
• Adaption CAN/Diagnose, Implementierung einer einfachen Restbus- Simulation (CANalyzer)
• Fehlerlokalisierung +Beseitigung nach Fahrzeugversuchen an Hand von Trace-Log-Daten