feature/zephyr #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/zephyr"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Zephyr Branch in main-Branch überführen. Es wird keine andere Plattform/Entwicklung mehr verfolgt.
Ersetzt die PlatformIO-Build-Konfiguration durch ein Zephyr-Projekt: - CMakeLists.txt: Zephyr-Entry-Point, target_sources(app), Platzhalter fuer add_subdirectory der lib/-Submodules. - prj.conf: C++20, SERIAL/SPI/GPIO/FLASH/NVS, mbedTLS-Defaults. - Kconfig: Anwendungsspezifischer Stub. - boards/custom/zehnder_knx_gw/: Custom Board (Hardware-Model v2) fuer den STM32L471RE inkl. DTS-Skelett (USART1 Konsole, USART2 KNX, SPI1 SPIRIT1, Flash-Partitionierung). - src/main.cpp: Minimales Zephyr-Skelett (printk/LOG_INF) ersetzt das bisherige Arduino-setup()/loop()-Schema. Konkrete Pin-Zuordnungen im DTS sind als TODO markiert und werden noch gegen den Schaltplan abgeglichen. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Drei Bausteine, die die Arduino-API-Abhaengigkeiten aufloesen: 1. src/Thread.{h,cpp} Abstrakte Thread-Basisklasse, die die Zephyr-Thread-API kapselt. Stack wird per K_THREAD_STACK_DEFINE in der TU der abgeleiteten Klasse deklariert und als Pointer+Size uebergeben (Alignment- Probleme mit Class-Member-Stacks vermieden). KNX- und SPIRIT1- Threads werden in spaeteren Schritten davon abgeleitet. 2. lib/arduino-shim/ Minimaler Arduino-API-Shim auf Zephyr-APIs (millis, micros, delay, delayMicroseconds, Print-Basisklasse, GPIO-Stubs). Wird primaer fuer AceTime gebraucht. 3. lib/knx-zephyr-platform/ ZephyrPlatform erbt direkt von Platform aus dem knx-Submodule (NICHT von ArduinoPlatform). Liegt ausserhalb des Submoduls, damit Upstream sauber bleibt. UART-Pfad ueber Ringbuffer + IRQ-Callback bereits implementiert; Persistenz-Methoden noch als Stubs (TODO). CMakeLists.txt: bindet beide Adapter-Libraries jetzt aktiv ein. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Vorher stand die Groesse der KNX-Persistenz an drei Stellen: - DTS-Partition (boards/.../zehnder_knx_gw.dts) - Compile-Define in lib/knx-zephyr-platform/CMakeLists.txt - Hardcoded Returnwert in ZephyrPlatform::getNonVolatileMemorySize() Jetzt ist die DT-Partition 'knx_partition' die einzige Quelle: - CMakeLists.txt liest die Groesse zur Configure-Zeit via dt_nodelabel() + dt_reg_size() und setzt KNX_FLASH_SIZE entsprechend fuer den knx-Stack. - ZephyrPlatform::getNonVolatileMemorySize() liefert direkt DT_REG_SIZE(DT_NODELABEL(knx_partition)). - Ein static_assert garantiert, dass beide Pfade dieselbe Zahl liefern. Wer die Persistenz spaeter vergroessern oder verschieben moechte, aendert ausschliesslich den reg-Eintrag der DT-Partition. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Der von der ST-SPIRIT1-Workbench generierte Init-Code wird ueber die neue Methode RFTransceiver::configureRadio() in die Aufrufkette aufgenommen: RFTransceiver::instance().init(); // Zephyr-Treibersetup RFTransceiver::instance().configureRadio(); // SRES + Workbench- // Register + VCO-Calib RFTransceiver::instance().start(); // IRQ-Thread Aenderungen im Detail: - src/generated/spirit1/Register_Setting.c '#include "MCU_Interface.h"' ergaenzt, damit die im Workbench-Output verwendeten SpiritSpi*-Aufrufe ueber die Makros auf unsere RadioSpi*- Adapter umgelenkt werden (ohne diesen Include wuerde der Linker auf undefinierte Symbole laufen). Hinweis im File: bei erneutem Export aus der Workbench wieder ergaenzen. - src/RFTransceiver.{h,cpp} Neue Methode configureRadio() ruft SpiritBaseConfiguration() (SRES + Workbench-Register-Init) gefolgt von SpiritVcoCalibration() (TX/RX- VCO-Werte). Vorwaerts-Deklarationen der beiden Workbench-Funktionen im extern "C"-Block, da Register_Setting.c keinen eigenen Header besitzt. - CMakeLists.txt Register_Setting.c jetzt teil des app-Targets. Generierter Code wird mit -w gebaut, damit projektweite Warn-Levels nicht durch Vendor- Code-Stil verletzt werden. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Die zuvor als LOG_WRN-Stubs hinterlassenen Persistenzfunktionen sind jetzt echte Implementierungen gegen Zephyrs Flash-Map-API. Statt alle hoeheren NV-Memory-Methoden zu ueberschreiben, nutzen wir die Buffer-Verwaltung der KNX-Stack-Base-Class und liefern nur die Low-Level-Primitiva: - userFlashStart() Memory-mapped Pointer auf Partitionsanfang (Adresse zur Compile-Zeit aus DT-Flash-Node- Basis + Partitions-Offset abgeleitet). - userFlashSizeEraseBlocks() Partitionsgroesse / (Page * Eraseblock). - flashPageSize() erase-block-size-Property des Flash-Controllers (STM32L4 = 2048, RP2040 = 4096) — vorher 2048 hartcodiert. - flashEraseBlockSize() 1 Page pro Eraseblock. - flashErase(idx) flash_area_erase(). - flashWritePage(idx, data) flash_area_write(). Aus zephyr_platform.h entfernt: die Override-Deklarationen von getNonVolatileMemoryStart/Size, commitNonVolatileMemory sowie beide writeNonVolatileMemory- und die readNonVolatileMemory-Methode. Die Base-Class-Default-Implementierungen erledigen das fuer Flash-Mode korrekt. ZephyrPlatform haelt jetzt einen flash_area-Handle, den der Konstruktor ueber flash_area_open(FIXED_PARTITION_ID(knx_partition), ...) initialisiert. Der Handle ist fuer die gesamte Anwendungslaufzeit gueltig — bei fixed-partitions ist kein Close noetig. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Stellt die Primitiva bereit, die das Zehnder-RF-Protokoll benoetigt: - encryptBlock / decryptBlock AES-128-ECB, ein 16-Byte-Block - encryptEcb / decryptEcb AES-128-ECB, mehrere Bloecke - crc8(data, length, seed) CRC-8 Polynom 0x07, beliebiger Seed (RF-Protokoll: 0x0B) - hmacSha256(key, data, out[32]) HMAC-SHA-256 (fuer Pairing) AES-Kontexte werden pro Aufruf lokal angelegt und mit mbedtls_aes_free() sicher freigegeben — kein langlebiges Schluesselmaterial in Klassenmembern, dadurch implizit thread-safe ohne Mutex. Diffie-Hellman fuer Pairing ist noch NICHT abgedeckt — wird ergaenzt, sobald die Implementation_guide den DH-Aufbau finalisiert hat. prj.conf um CONFIG_MBEDTLS_CIPHER=y und CONFIG_MBEDTLS_MD=y erweitert, damit der generische Cipher-Layer und der Message-Digest-Layer (Basis fuer HMAC) gebaut werden. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Die Heater-Klasse vermittelt zwischen Application (KNX) und RFProtocol: KNX-Application <--> Heater <--> RFProtocol <--> RFTransceiver Sie kapselt das Heizgeraet auf Anwendungsebene und erlaubt der Application einen typsicheren Zugriff (Mode-Enum, Temperatur in °C, Boost-Dauer in Minuten) — die Protokoll-Codierungen (tempX2, Modus-Bytes 0x01..0x08, 1/100 °C-Codierung der Raumtemperatur) bleiben hier intern. Zwei Daten-Pfade: 1. Befehle (Application -> Heater -> RFProtocol): setMode, setComfortSetpoint, setEcoSetpoint, setBoost, setWindowOpenDetection, setSensorMode, sendRoomTemperature, syncRtc, setWeeklySchedule, startPairing. Eingangswerte werden validiert/geclampt (Setpoint 7..28 °C bzw. 7..19 °C ECO, Boost 15..120 min). 2. Zustands-Updates (RFProtocol -> Heater -> Application): updateMode/-ComfortSetpoint/-EcoSetpoint/-HeatingStatus/ -SensorMode/-BoostActive/-Reachable. Heater haelt den zuletzt bestaetigten Geraete-Zustand und feuert bei Aenderung den jeweiligen Observer-Callback. Damit reagiert die Application auf eingehende Burst-RX-Werte, ohne RFProtocol direkt zu kennen. Quelle der Mode-Codes und Sollwert-Kodierung: doc/Implementation_guide.md Abschnitt 7 und 8. Da RFProtocol noch nicht existiert (vorhandener Header ist nur ein Entwurf), ist die Klasse per Forward-Declaration eingebunden und die Setter loggen aktuell nur LOG_INF. Die Update-Pfade sind dagegen vollstaendig implementiert — sobald RFProtocol live ist, kann es die update*()-Methoden direkt befuellen. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>Ab mbedTLS 4 liegen die klassischen Header (mbedtls/aes.h, mbedtls/md.h) nicht mehr im oeffentlichen Include-Pfad — sie sind unter mbedtls/private/ und auf dem Pfad zur Entfernung. Stattdessen ist die PSA-Crypto-API der unterstuetzte Weg, und Zephyr exponiert sie ueber CONFIG_PSA_CRYPTO=y. Diese Migration ersetzt die mbedtls_aes_*- und mbedtls_md_*-Aufrufe durch psa_cipher_encrypt/decrypt (AES-128-ECB) und psa_mac_compute (HMAC- SHA-256). Die public API der Crypto-Klasse bleibt unveraendert, sodass keine Aufrufer angepasst werden muessen. Details: * psa_crypto_init() wird ueber einen C++20-Magic-Static genau einmal thread-safe ausgefuehrt — kein eigenes Locking noetig. * Schluessel werden pro Aufruf als volatile PSA-Keys importiert und am Ende mit psa_destroy_key() zerstoert; damit bleibt der bisherige Pure-Function-Stil erhalten und es leakt kein Klartext-Schluessel. * Die ECB-Pfade (encryptBlock/decryptBlock und encryptEcb/decryptEcb) teilen sich einen internen doEcb-Helper. Da PSA fuer ECB_NO_PADDING keinen IV einfuegt und Multi-Block intern zerlegt, entfaellt die bisherige Block-Schleife. * Header-Kommentar in Crypto.h auf PSA-Konfiguration aktualisiert. Die noetigen Kconfig-Symbole (CONFIG_PSA_CRYPTO=y plus PSA_WANT_KEY_TYPE_ AES/ALG_ECB_NO_PADDING/KEY_TYPE_HMAC/ALG_HMAC/ALG_SHA_256) waren in prj.conf bereits gesetzt. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>DT_MTD_FROM_FIXED_PARTITION liefert den Flash-CONTROLLER (flash-controller@ 40022000) — auf dem es weder erase-block-size noch write-block-size gibt. DT_PROP(..., erase_block_size) brach daher beim Compile mit "not declared in this scope" ab. Korrekt ist DT_MEM_FROM_FIXED_PARTITION: liefert den Flash-Chip-Memory-Node (flash@8000000, compatible "soc-nv-flash"), wo erase-block-size und write-block-size deklariert sind. Auch DT_REG_ADDR gibt dort die korrekte Memory-Base zurueck (STM32L4: 0x08000000); das ist semantisch sauberer als am Controller-reg=0x40022000 zu drehen, das nur den Peripherie-Registersatz adressiert. Zusaetzlich: * static_assert auf DT_NODE_EXISTS(KNX_FLASH_DEV_NODE) — wenn die Partition mal nicht unter einem soc-nv-flash haengt, liefert das DT_MEM_FROM_FIXED_PARTITION-Macro DT_INVALID_NODE und der Fehler schlaegt fruehzeitig mit klarer Meldung zu. * Erklaerungsblock vor der Define-Kaskade ergaenzt, der die Falle Controller-vs-Memory-Node dokumentiert. Damit baut der Zehnder-KNX-Gateway erstmals vollstaendig durch (zephyr.elf, ~34 KB FLASH). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>