Mikrocontroller.net - Benutzerbeiträge [de]

STM32

2022-09-24T22:37:56Z

172.26.6.198: /* Andere Programmiersprachen */

STM32 ist eine Mikrocontroller-Familie von [http://www.st.com/mcu/inchtml-pages-stm32.html ST] mit einer 32-Bit [[ARM]] Cortex-M0/M3/M4 CPU. Diese Architektur ist speziell für den Einsatz in Mikrocontrollern neu entwickelt und löst damit die bisherigen ARM7-basierten Controller weitestgehend ab. Den STM32 gibt es von ST in unzähligen Varianten mit variabler Peripherie und verschiedenen Gehäusegrößen und -formen. Durch die geringe Chipfläche des Cores ist es ST möglich, eine 32 Bit-CPU für weniger als 1 € anzubieten.

[[Bild:stm32F103xc.png|thumb|right|340px|Blockdiagramm STM32F103xC/D/E]]

== STM32-Familien ==

Bisher gibt es elf STM32-Familien:
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f0-series.html STM32F0]
** Cortex M0
** Mikrocontroller zum Einstieg
** Bis 48MHz (38 DMIPS)
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f1-series.html STM32F1]
** Cortex M3
** Bis 72MHz (61 DMIPS)
**Verschiedene Unterfamilien:
*** Connectivity line
*** Performance line
*** USB Access line
*** Access Line
*** Value line
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f2-series.html STM32F2]
** Cortex M3
** Bis 120MHz (150 DMIPS)
** Wie die STM32F1 Serie, Camera-Interface, 32-Bit Timer, Crypto-Engine...
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f3-series.html STM32F3]
** Cortex M4F
** DSP und FPU
** Bis 72MHz (90 DMIPS)
** Fast 12-bit 5 MSPS and precise 16-bit sigma-delta ADCs
** Touch sensing controller (TSC)
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series.html STM32F4]
** Cortex M4F
** DSP und FPU
** Bis 180MHz (225 DMIPS)
** Bis zu 2MB Flash
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f7-series.html STM32F7]
** Cortex M7
** DSP und FPU (Single/Double Precision)
** Bis 216MHz (462 DMIPS)
** Mehr Peripherie: SPDIF-IN/OUT, SAI, HDMI-CEC, Dual Quad SPI
** On-Chip Grafik-LCD-Controller
** DMAs auch für Ethernet, USB und Chrom-ART
* [http://www.st.com/en/microcontrollers/stm32h7-series.html STM32H7]
** Cortex M7
** Bis 400MHz (856 DMIPS)
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l0-series.html STM32L0]
** Cortex M0+
** Low Power
** mit LCD Treiber
** Bis 32MHz (26 DMIPS)
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l1-series.html STM32L1]
** Cortex M3
** Low Power
** mit LCD Treiber
** Bis 32MHz (33 DMIPS)
* [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l4-series.html STM32L4]
** Cortex M4F
** DSP und FPU (Single Precision)
** Ultra Low Power (bis zu 8nA mit I/O Wake-Up)
** Bis 80MHz (100 DMIPS)
** 128KB...1MB Flash, 64/128KB SRAM
** optional Segment-LCD Treiber
** Quarzloser Betrieb auch mit CAN (1% ab Werk) oder USB (Synch über Host) möglich
** Digital-Filter für ΣΔ-Modulatoren
* [https://www.st.com/en/microcontrollers-microprocessors/stm32g0-series.html STM32G0]
** Cortex M0+
** Bis 64MHz (ca. 60MIPS)
** 16KB...512KB Flash, bis 128KB SRAM
** 8-100 Pins
** SO-8, QFP TW im 0.8mm Raster
** Noch nicht alle gelisteten Varianten in Produktion (8.2019)
* [https://www.st.com/en/microcontrollers-microprocessors/stm32g4-series.html STM32G4]
** Cortex M4F
** FPU und DSP
** "Math Accelerator" Für Trigonometrische Funktionen, FIR, IIR
** Bis 170MHz (213 DMIPS)
** bis 512KB Flash, 128KB SRAM
** 48-128Pins
** "Mixed Signal MCU"
** Noch nicht alle gelisteten Varianten in Produktion (8.2019)

*[https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus/stm32-wireless-mcus/stm32wb-series/stm32wbx5.html STM32WB]
** Cortex M4 + Cortex M0+
** 64 MHz (M4), 32 Mhz (M0+)
** IEEE 802.15.4
** Bluetooth 5.0

* STM32T - nicht mehr in Produktion
** Cortex M3
** 72MHz
** Touch Sensing
* STM32W - nicht mehr in Produktion
** Cortex M3
** BIS 24MHz
** RF-MCU
[http://www.st.com/web/en/catalog/mmc/FM141/SC1169 Hier eine Übersicht zum Auswählen eines STM32Fxxx]

===Features===
* Cortex-M0(+) / Cortex-M3 / Cortex-M4(F) / Cortex-M7 Kern (mit FPU)
* 16KB ... 2MB [[Flash-ROM]]
* 4KB ... 512KB [[Speicher#SRAM|SRAM]]
* 2KB ... 16KB [[Speicher#EEPROM|EEPROM]] (STM32L)
* SDRAM-Controller bei den [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1806 STM32F42xxx und STM32F43xxx], bis 512 MByte externer SDRAM addressierbar
* 512 one-time programmable Bytes(STM32F2/4)
* [[IC-Gehäuseformen | Gehäuse]] 8 ... 216 Pins als SO, LCSP, TSSOP, QFN, QFP und BGA
* Derzeit sind '''über 700''' [http://www.st.com/web/en/catalog/mmc/FM141/SC1169 STM32 Derivate/Varianten verfügbar]
* Bis 72MHz CPU-Takt, bis 120MHz beim STM32F2xx, bis 168/180 MHz beim STM32F4xx, wobei eine spezielle Prefetch-Hardware bis 120/168 MHz eine Geschwindigkeit erzielt, die 0 Wait-States entspricht. Der CPU-Takt wird über einen Multiplikator aus dem internen RC-Takt oder einem externen Quarz-Takt abgeleitet. Bis 216MHz CPU-Takt bei STM32F7xx.
* Zusätzliche FPU "Math Accelerator" Für Trigonom. Funktionen (CORDIC), FIR, IIR(FMAC) (STM32G4)
* Externes Businterface (nur bei Gehäusen ab 100 Pin und nur bei STM32F4, STM32F2 und STM32F1 Performance line)
* LCD Treiber für bis zu 8x40 Segmente (nicht beim STM32F2xx)
* TFT Treiber bei [http://www2.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series/stm32f429-439.html STM32F429/STM32F439] [http://www2.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series/stm32f469-479.html STM32F469/STM32F479]
* Spannungsbereich 1,65 ... 3,6V, nur eine Betriebsspannung nötig
* Temperaturbereich bis 125 °C
* Bis zu 168 IOs, viele davon [[Pegelwandler|5V-tolerant]]
* Interner, kalibrierter RC-Oszillator mit 8MHz (16MHz bei STM32F2/F4xx)
* Externer Quarz
* Real Time Clock mit eigenem Quarz und separater Stromversorgung
* Bis zu 16 [[Timer]], je Timer bis zu 4 IC/OC/PWM Ausgänge. Davon 2x Motion Control Timer (bei STM32F103xF/G), (bis zu 32 PWM Ausgänge)
* Systick Counter
* Bis zu 3 12-Bit [[AD-Wandler]] mit insgesamt 24 AD-Eingängen, integrierter [[Temperatursensor]], Referenzspannung Vrefint und VBatt Spannungsmessung (STM32F4xx)
* Bis zu 2 12-Bit [[DA-Wandler]] (bis zu 3 beim STM32F3xx)
* Bis zu 2 [[DMA]] Controller mit bis zu 12 Kanälen (16 beim STM32F2/4xx)
* Bis zu 2x [[I2C|I²C]]
* Bis zu 5x [[UART|USART]] mit LIN, IrDA und Modem Control (bis zu 8 beim STM32F2/F4xx)
* Bis zu 3x [[SPI]] (bis zu 6 beim STM32F4xx)
* Bis zu 2x [[I2S|I²S]]
* Bis zu 3x [[CAN#STMicroelectronics STM32 (Cortex M3/M4)|CAN]]
* Hardware [[CRC]] Unit, bei der STM32F3xx Serie mit einem einstellbaren Polynom
* Unique device ID register (96 Bits)
* TRNG - True Random Number Generator (STM32F2/4xx), basierend auf analoger Schaltung
* Cryptographic Processor (CRYP) (STM32F2/4xx)
* Hash Processor (HASH) (STM32F2/4xx)
* Kamera-Interface (DCMI) (STM32F2/4xx)
* [[USB]] 2.0 Full Speed / OTG
* [[USB]] 2.0 Hi Speed OTG mit extra PHY-Chip (STM32F2/4xx)
* USB Type-C™ Power Delivery controller (STM32G0/G4)
* HDMI CEC interface (STM32G0)
* SDIO Interface (z.B. SD-Card Reader)
* Ethernet
* Watchdog mit Window-Mode
* Jedes Peripheriemodul ist separat einschaltbar, wodurch sich erheblich [[Ultra low power|Strom sparen]] lässt
* [[JTAG]] und SWD (Serial Wire Debug) Interface
* Bis zu 6 Hardware-Breakpoints für Debuggen
* und vieles mehr ...

== Struktur der Dokumentation ==
Die Dokumentation der STM32 ist im Vergleich zur [[AVR]]-Familie umfangreicher und komplexer. Sie teilt sich in mehrere Dokumente auf.
Als Beispiel der Dokumentation soll stellvertretend der [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-mainstream-mcus/stm32f1-series/stm32f103/stm32f103rc.html STM32F103RC] genannt werden. Die Seite von ST beinhaltet alle nötigen Informationen passend zu diesem Prozessor.

Diese Dokumente von ST beschreiben den Controller:

* Im [http://www.st.com/resource/en/datasheet/stm32f103rc.pdf STM32F103xC/D/E Datasheet] sind die speziellen Eigenschaften einer bestimmten Modellreihe beschrieben und die exakten Daten und Pinouts aufgeführt, sowie die Zuordnung Chipname - Flash/RAM-Größe. Die Peripheriemodule werden nur aufgeführt, nicht detailliert beschrieben.
* Im [http://www.st.com/resource/en/reference_manual/cd00171190.pdf Reference Manual (RM0008)] sind alle Peripheriemodule der jeweiligen STM32-Controllerfamilie im Detail beschrieben.
* Das [https://static.docs.arm.com/ddi0403/e/DDI0403E_c_armv7m_arm.pdf ARMv7M Architecture Reference Manual] beschreibt detailliert die abstrakte ARMv7M-Architektur, wie das Exception Model, die CPU Instruktionen inklusive Encoding, etc.
* Das [https://static.docs.arm.com/100166/0001/arm_cortexm4_processor_trm_100166_0001_00_en.pdf Cortex-M4 Technical Reference Manual] bzw. das [https://static.docs.arm.com/100165/0201/arm_cortexm3_processor_trm_100165_0201_00_en.pdf Cortex-M3 Technical Reference Manual] beschreibt Eigenschaften der Cortex-M3/4 Implementierung der Architektur, insbesondere die Geschwindigkeit der einzelnen Prozessor-Instruktionen.
* Das [http://www.st.com/resource/en/programming_manual/cd00228163.pdf STM32 Cortex-M3 Programming Manual] ist eine Zusammenfassung des ARMv7M Architecture Reference Manual bezogen auf die STM32.
* Wer nicht die ST Firmware-Library verwendet, der benötigt zusätzlich das [http://www.st.com/resource/en/programming_manual/cd00283419.pdf Flash Programming Manual] für die Betriebsart des Flash-ROMs, d.h. die frequenzabhängige Konfiguration der Waitstates.

Zusätzlich sollten auch die [http://www.st.com/resource/en/errata_sheet/cd00197763.pdf Errata Sheets] beachtet werden. Empfohlen sei auch die Appnote "[http://www.st.com/resource/en/application_note/cd00164185.pdf AN2586 Getting started with STM32F10xxx hardware development]".
Die jeweiligen Dokumentations-PDFs sind auf der Produktseite von ST eines jeden Mikrocontrollers verlinkt.

== Hardware Zugriffs-Libraries ==
=== CMSIS ===

Die CMSIS (ARM® '''C'''ortex™ '''M'''icrocontroller '''S'''oftware '''I'''nterface '''S'''tandard) ist eine Library von ARM für den Zugriff auf die herstellerübergreifenden Funktionen des ARM-Cores. Hierzu gehört bei den Cortex-M4F-Cores auch die DSP und Floating-Point Funktionalität. Weiterhin existieren eine Zahl von Helferfunktionen für den NVIC, den Sys-Tick-Counter, sowie eine SystemInit-Funktion, welche sich um die PLL kümmert.

Im Rahmen des CMSIS-Standards ([http://www.onARM.com www.onARM.com]) wurden die Headerdateien standardisiert, der Zugriff auf die Register erfolgt per '''Peripheral->Register'''. Die CMSIS C-Dateien bzw. Header enthalten auch Anpassungen für die verschiedenen Compiler. Die Portierung eines Real-Time-Betriebsystems sollte unter Verwendung der CMSIS, für Chips der verschiedenen Hersteller, stark vereinfacht möglich sein (z.B. einheitliche Adressen für Core-Hardware/Sys-Tick-Counter).

Die CMSIS ist im Download der ‎STM32 Standard Peripheral Library enthalten. Die Compiler-Hersteller liefern eine jeweils zur ihrer Tool-Version passende bzw. geprüfte Library (incl. CMSIS) aus. Diese Libs können, gegenüber den Downloads beim Chip-Hersteller, auch ältere Version beinhalten.

=== ‎STM32 Standard Peripheral Library (SPL) ===

ST bietet für jede Controller-Familie eine umfangreiche zur CMSIS passende Peripherie-Bibliothek. Alle Funktionen um die Peripherie zu benutzen sind gekapselt in einfache Strukturen und Funktionsaufrufe. Somit muss man sich nicht selbst um die Peripherie-Register kümmern. Diese Library und ihre Dokumentation setzen das grundlegende Verständnis der Funktion des jeweiligen Peripheriemoduls voraus, wie es die o.a. Referenz und diverse Appnotes vermitteln. Die Library beinhaltet außerdem für fast jede Peripherie mehrere Beispiele.
Für die USB Schnittstelle gibt es noch eine extra Library, genauso wie für Ethernet.

Die Standard Peripheral Library ist inzwischen veraltet, ST empfiehlt, sie nicht mehr zu verwenden.

Auf der "Design Resources" Seite der Produktseite von ST eines jeden STM32 Mikrocontrollers kann die Library für den jeweiligen Controller heruntergeladen werden, z.B. [http://www.st.com/web/en/catalog/tools/PF257890 hier für den o.g. STM32F103RC].

Library für STM32F4xx: [http://www.st.com/web/en/catalog/tools/PF257901# STSW-STM32065 STM32F4 DSP and standard peripherals library]

=== ‎STM32 Cube HAL ===

Hat seit 2012 die SPL abgelöst.

* https://www.st.com/en/embedded-software/stm32cube-mcu-packages.html

== Programmierung ==
Zur Programmierung der STM32 gibt es verschiedene Möglichkeiten, sowohl kommerzielle proprietäre als auch mit Freier Software.

=== Freie Software/Freeware ===
==== Selber zusammenstellen ====
Man nehme...:
* Eine Entwicklungsumgebung nach Wahl:
** [http://www.eclipse.org Eclipse] mit [http://www.eclipse.org/cdt/ C/C++ Development Tooling] und [https://gnu-mcu-eclipse.github.io/ GNU ARM Plug-in](Linux, Windows)
** [https://atollic.com/truestudio/ TrueStudio for STM32] basiert auf Eclipse
** [http://www.openstm32.org/Downloading+the+System+Workbench+for+STM32+installer System Workbench for STM32] basiert auf Eclipse
** [http://netbeans.org/ Netbeans] mit [http://plugins.netbeans.org/plugin/37426/gdbserver GDBserver-Plugin] (Linux, Windows)
** [http://www.kdevelop.org/ KDevelop] (Linux, Windows)
** [http://www.geany.org/ Geany] (Linux, Windows)
** Oder ein einfacher Texteditor
* Einen C,C++ Compiler:
** Eine der [[ARM_GCC#Fertige_GCC_Bin.C3.A4rdistributionen|GCC-Binärdistributionen]], siehe auch [[#GCC|GCC]] (je nach Distribution Linux, Windows)
* Programmiersoftware zum Flashen des Target:
** [http://openocd.sourceforge.net/ OpenOCD] unterstützt viele Debug/Programmier-Adapter (Linux, Windows)
** [https://github.com/texane/stlink Texane stlink] funktioniert gut mit den ST-Link Adaptern wie sie zB. auf den STM32 Discovery Boards zu finden sind (Linux)
** Bei Verwendung eines Segger J-Link, den [http://www.segger.com/admin/uploads/productDocs/UM08005_JLinkGDBServer.pdf Segger GDB-Server] in Verbindung mit dem beim GCC mitgelieferten GDB (Linux, Windows).
** [https://github.com/blacksphere/blackmagic/wiki Black Magic Probe] als Mikrocontrollerfirmware simuliert einen seriellen Port, der direkt von GDB verwendet werden kann. Für FTDI-MPPSE basierte Adapter und ST-Link V2 läuft Blackmagic auf dem Host und stellt den Port :2000 für GDB zur Verfügung. Stlinks können, so man sich Programmierzugang zu dem STM32F103 des Stlinks beschaffen kann, auch mit BMP Firmware umgeflasht werden.

==== Komplette IDEs ====
* [https://developer.mbed.org/platforms ARM mbed Developer Site] ist eine vollständige Entwicklungsplattform für diverse ARM-Controller auf Basis eines RTOS mit Hardware-Abstraktion und webbasierter Online-sowie Offline-IDE. Ähnlich dem Arduino-Konzept können mit mbed einfachere Aufgaben schnell umgesetzt werden. mbed basiert auf C++ und unterstützt verschiedene Compiler. Projekte können auch exportiert und für andere IDEs heruntergeladen werden. Die mbed-Library ist quelloffen und auf github gehostet.
* [https://atollic.com Atollic TrueStudio] wurde seit der Übernahme durch ST auf STM32 Mikrocontroller reduziert und ist jetzt kostenlos verfügbar. Basiert auf Eclipse, OpenOCD und [[ARM GCC]]. Ohne size limit.
* [http://www.codesourcery.com/sgpp/lite_edition.html Codesourcery Lite Edition] Mit dieser Umgebung muss man sich anfreunden können. Es sind nur wenig Beispielprojekte verfügbar. Nicht mehr kostenlos verfügbar.
* [http://www.coocox.org/ Coocox Eclipse IDE] kostenlose IDE für STM32F0/F1/F2/F3/F4, die aber mittlerweile nicht mehr weiterentwickelt wird. Basiert auf dem [[ARM GCC]] und es gibt eine breite Unterstützung. Es ist sogar ein freies RTOS verfügbar. Eine gute Wahl ohne Limits mit breiter Debugger-Unterstützung. Hilfreiche Infos gibt es [http://www.mikrocontroller.net/topic/214719?goto=new#2228482 hier] und [http://www.mikrocontroller.net/topic/214719?goto=new#2229943 hier] im Forum, Artikel: [[STM32 CooCox Installation]]
* [http://emide.org/ emIDE] kostenlose IDE von Segger. Die emIDE basiert auf Code::Blocks. Sie ist auf [[ARM GCC]] aufgebaut und unterstützt eine große Zahl an unterschiedlichen JTAG/SWD-Debuggern - natürlich auch den J-Link aus gleichem Hause.
* [http://www.emblocks.org EmBlocks] kostenlose IDE, Code::Blocks basiert, unterstützt STM32 L1/F0/F1/F2/F3/F4/W, integrierter Compiler ([[ARM GCC]]), integrierter GDB-Debugger, Jlink/ST-Link, System view (Peripherie-Register anzeigen) beim Debuggen, Project-Wizard (Eigene Wizards können mit Squirrel geschrieben werden), Basiert auf Code::Blocks. Artikel: [[STM32 - Einstieg mit Em::Blocks]]
** heißt jetzt EmBitz -> https://www.embitz.org
* [http://cms.seng.de/service-support/downloads/ Entwicklungsumgebung GNU/Linux] für STM32F1 mit OpenOCD und Olimex ARM-USB-OCD-H, Bedienung über Eclipse-IDE oder Kommandozeile.
* [http://www.openstm32.org/blog1-System-Workbench-for-STM32 System Workbench for STM32] (SW4STM32) ist eine uneingeschränkte und kostenlose IDE. Sie wird von [http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF261797 ST] offiziell unterstützt. Die Entwicklungsumgebung ist in der Version 1.0 seit 5.2.2015 erhältlich. Seit Februar 2016 ist eine Version für Linux verfügbar.

==== Andere Programmiersprachen ====

* [http://mecrisp.sourceforge.net Mecrisp-Stellaris], eine native Forth-Implementation für ARM Cortex M0/M3/M4. Es werden bereits mehrere STM32 Targets unterstützt und neue Portierungen sind herzlich willkommen. Auch Chips von TI, NXP und Freescale sind im aktuellen Paket enthalten.
Mecrisp-Stellaris läuft auf dem STM32 Controller, wo es einen optimierenden, nativen Code erzeugenden, und interaktiven Compiler als auch Laufzeitumgebung darstellt. Zur Bedienung bedarf es lediglich eines Terminal Programs. Es erlaubt auch, die selbe SWI-Verbindung über den ST-Link Adapter, womit der STM32 geflasht wird, für Terminal I/O zu verwenden!
STM32 Modelle mit 32 KB (oder mehr) Flash Speicher sind empfohlen.

=== Kommerzielle Umgebungen ===

* [http://www.keil.com/arm/mdk.asp Keil µVision] (Demo max. 32KB Code/Free für STM32F0/STM32L0): Die sehr komfortable µVison IDE ist neben dem ARM Compiler per Menue auch für einen beliebigen GNU-Compiler konfigurierbar. Damit besteht das 32k-Limit nur noch für den integrierten Debugger / Simulator. In Verbindung mit einem ULINK (ULINK2, ULINK pro für Trace, ULINK Plus für Strommessung) ist die Umgebung schon sehr einfach zu bedienen, der Compiler unterstützt parallel build. Mit der µVision lassen sich fremde ELF oder HEX Files in den Controller bzw. in den Flashspeicher des Controllers schreiben (Etwas tricky, s. "Options for Target"). Die IDE unterstützt die grafische Analyse unterschiedlicher Daten in einem gemeinsamen Display. Für den Anfänger eine gute Wahl. Der Preis ist jedoch ein guter Grund auf andere freie IDEs zu wechseln. µVison selbst kann kostenlos mit dem MDK-Evaluationkit heruntergeladen werden. [https://www.keil.com/arm/demo/eval/arm.htm#DOWNLOAD download] Wer sich nur auf STM32 Cortex M0/L0 beschränkt kann die Keil MDK auch ohne 32K Begrenzung frei nutzen. [http://www2.keil.com/stmicroelectronics-stm32/mdk download]
* [http://www.iar.com/en/Products/IAR-Embedded-Workbench/ IAR-Embedded-Workbench] (Demo max. 32KB Code) [http://supp.iar.com/Download/SW/?item=EWARM-EVAL download]
* [http://www.isystem.com/download/winideaopen winIDEAOpen] Keine Code Limitierung, GCC und Testwerkzeug beinhaltet. Läuft mit dem iTag50 Adapter, Segger J-Link und dem ST-Link
* [http://www.raisonance.com Raisonance Ride7] (GCC Compiler, kostenlose Version auf Debugging von max. 32KB Code limitiert, keine Limitierung beim Complilieren)
* [http://www.rowley.co.uk/arm/ Rowley Crossworks] (Demo 30 Tage unbeschränkt, 150$ für nichtkommerzielle Nutzung, auf GCC basierend). Mir ist nicht klar warum man für diese IDE Geld bezahlen soll. Der GNU-Compiler ist frei und die Entwicklungsumgebungen die auf Eclipse basieren, ebenfalls. Allerdings ist diese Einstellungsarbeit schon was für den etwas erfahrenen Entwickler.
* [http://www.sisy.de/index.php?id=17&no_cache=1 SiSy ARM oder SiSy Micrcontroller++] (Demo verfügbar keine Gößenbegrenzung, basiert auf GNU-Compiler, grafische Programmierung mit UML möglich, integrierter Debugger)
* [http://www.comsytec.eu/epsdebugger.php EPS Debugger Plugin, für STM32 Development mit Code::Blocks]
* [http://www.mikroe.com MikroE bietet neben Pascal und Basic auch C mit kompletter Oberfläche mit Compiler etc. pp relativ günstig]
* [http://www.visualgdb.com VIsualGDB] Wer vom Atmel Studio kommt oder sonst viele mit Visual Studio arbeitet bekommt hier ein Plugin, das wirklich Spaß macht und funktioniert. Es werden nicht nur STM32 unterstützt. Einfach kostenlose Trial-Version anschauen und probieren.

=== STM32CubeMX ===
Dies ist eine Software von ST selbst, die die Auswahl und Konfiguration von STM32-Mikrocontrollern vereinfacht:
* Auswahl der Controller oder Entwicklungsboards mit einer parametrischen Suche
* grafische Konfiguration der Pins und Alternate Functions (inkl. Überprüfung auf Kollisionen - bei Entwicklungsboards sind gewisse Pins schon vorkonfiguriert und werden angezeigt)
* grafische Konfiguration des Clock-Trees
* Generierung von C-Code entsprechend der grafischen Konfiguration. Dieser funktioniert nur mit den neuen STM32CubeMX Libraries (HAL, LL), nicht mit den alten Standard Peripheral Libraries (SPL).
* Simulation des Strom-Verbrauchs unter Auswahl verschiedenster Stromquellen und Batterien
STM32CubeMX ist Java-basiert und läuft daher problemlos auf Windows, OS X und Linux. In der Zip-Datei, welche [https://my.st.com/content/my_st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.html bei ST heruntergeladen] werden kann, befinden sich entsprechende Installer für die einzelnen Betriebssysteme.

=== Tutorials für diverse Tool-Kombinationen ===
* [[STM32 Eclipse Installation|Windows,Linux, Eclipse + Yagarto/CodeSourcery + OpenOCD/ST-Link]]
* [[STM32 Eclipse JLink Linux/Windows|Windows,Linux, Eclipse + GCC-ARM-Embedded + JLink]]
* [[Linux auf STM32|Linux auf STM32 (ucLinux)]]

* Windows
** Eclipse
*** [http://www.mikrocontroller.net/topic/216554 Windows, Eclipse, codesourcery, st-link ]
*** [http://www.firefly-power.de/ARM/debugging.html Eclipse Plugin "GDB Hardware Debugging" mit OpenOCD]
** Code::Blocks
*** [http://www.mikrocontroller.net/topic/265600 Windows, Code::Blocks, STM32F4]
** STM32 mit EmBlocks
*** [http://www.emblocks.org/web/downloads-main Download EmBlocks]
*** [https://www.youtube.com/watch?v=coHPJylnzC8 Video STM32 Project Wizzard in EmBlocks]
** Atollic TrueSTUDIO
*** [[STM32 LEDBlinken AtollicTrueStudio|Atollic TrueSTUDIO Installation + Demo]]
** MDK-ARM Lite mit Einstellungen für STM32F0/F4-Discovery Board
*** [https://www.keil.com/demo/eval/arm.htm KEIL MDK-ARM Download]
*** [https://www.youtube.com/watch?v=RXOOxby5nns&list=PL6-W3FoUyb48WFI5PQv3SDJj2G1t2FonV&index=1 Installations Video STM32F4 Discovery Board]
*** [https://www.youtube.com/watch?annotation_id=annotation_203294&feature=iv&index=4&list=PL6-W3FoUyb48WFI5PQv3SDJj2G1t2FonV&src_vid=sN4gDZ7H8gw&v=BeZcQjXxk9A Einstellungen STM32F0 Discovery Board Video]
** SiSy ARM, STM32
*** Download: [http://www.sisy.de/index.php?id=59 SiSy DEMO] kein Begrenzung der Codegröße
*** [http://www.youtube.com/watch?v=84Y3jYLWYpo Videobeispiel]
** Microsoft Visual Studio
*** [http://visualgdb.com/tutorials/arm/stm32/f4_discovery/ "STM32F4-Discovery tutorial with Visual Studio"]
* Ubuntu
** [http://cms.seng.de/service-support/downloads/ Installing a toolchain for Cortex-M3/STM32 on GNU/Linux] - How-to manual, für STM32F1 unter GNU/Linux mit OpenOCD und Olimex ARM-USB-OCD-H. Integrierte Make files, Linker Skripte, Startup-Code, diverse Tools und Demo-Projekt/Programm. Einbindung in Eclipse IDE oder Bedienung über Kommandozeile.
** [http://fun-tech.se/stm32/index.php Ubuntu, Selbstcompilierter GCC, STM32/Cortex-M3]
** [http://thetoolchain.com The ToolChain] - Automatisch installierende Entwicklungsumgebung mit eigenen und externen Treibern, Unterstützt QtCreator als IDE, Flexibel erweiterbar über Shellskripte

* [http://www.mikrocontroller.net/topic/214719 Tipps für Installation mit Eclipse]
* [[ARM-ASM-Tutorial|Tutorial zu ARM-Assembler unter Windows/Linux (Englisch)]]

===Programmieradapter===
* Der [http://www2.st.com/content/st_com/en/products/development-tools/hardware-development-tools/development-tool-hardware-for-mcus/debug-hardware-for-mcus/debug-hardware-for-stm32-mcus/st-link-v2.html ST-LINK/V2] ist ein Debugger, welcher von ST selbst angeboten wird. Jedes STM32 Discovery- oder Nucleo-Board hat einen ST-LINK V2 bzw. ST-Link V2-1 für Programmierung/Debugging per SWD on-board (teilweise abbrechbar), welcher auch für eigene STM32 Target Hardware und prinzipiell auch andere Cortex-M benutzt werden kann. Zwar ist er mit 1.8MHz Takt ein sehr langsamer Vertreter seiner Art, jedoch lassen sich mit ihm fremde Hex- und Binary-Files sowohl Debuggen als auch Flashen. Die ST-LINK-Variante auf den Nucleo- bzw. Discovery-Boards beherrscht nur SWD und kein JTAG, wohingegen der ST-Link in der Adapterversion mit Gehäuse auch JTAG beherrscht und zusätzlich auch in einer Variante mit galvanischer Trennung erhältlich ist. Die ST-LINK/V2-1 auf den NUCLEO und Discovery-Boards können auch per Softwareupdate zu einem J-Link OB umgewandelt werden. Details und Hinweise dazu [https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board hier]. Kopien des ST-Link V2 sind als "mini"-Version u.a. sehr günstig (<5€) über Ebay, Aliexpress und Co zu beziehen. Diese unterstützen jedoch ebenfalls kein JTAG und haben desweiteren den Nachteil, das der Reset-Pin nicht herausgeführt ist bzw. der mit "Reset" bezeichnete Pin nur für STM8 gedacht ist. Sämtliche ST-Link V2 und V2/1 können mittels einer von ST angebotenen [http://www2.st.com/content/st_com/en/products/embedded-software/development-tool-software/stsw-link007.html Update-Software ] auf den jeweils neuesten Stand gebracht werden.
* [http://www.segger.com/jlink-model-overview.html SEGGER J-LINK / J-TRACE] für u.a. alle ARM7/9/11, Cortex-M0/M1/M3/M4/A5/A8/A9/R4 als [http://www.segger.com/cms/j-link-edu.html Non-Commercial] J-LINK-EDU für ca. 50€ zu haben, läuft in µVision, IAR, GDB (Linux & Windows über einen eigenen [http://www.segger.com/admin/uploads/productDocs/UM08005_JLinkGDBServer.pdf GDB-Server]), ... Der J-Link ist mit Abstand der schnellste Debugger, den ich bisher testen konnte. Wer es beim Debuggen eilig hat, liegt mit dem J-Link von Segger richtig.
* Keil [http://www.keil.com/ulinkme/ ULINK-ME], [http://www.keil.com/arm/ulink2/ ULINK2], [http://www.keil.com/arm/ulinkpro/ ULINK pro] Wenn man die die µVision IDE nicht verlassen mag, kann man sich mit diesen Adaptern anfreunden, denn sie arbeiten nur mit dieser IDE zusammen. Sie benötigen keine USB-Treiber, da sie geschickt das HID-Device des Betriebssystems nutzen. Es lässt sich kein fremdes Binary oder Hex-File flashen. Der ULINK2 kostet genau soviel wie ein Segger J-Link Basic bei gleichem Funktionsumfang, der sich jedoch auch in Verbindung mit anderen IDEs (GDB, usw) einsetzen lässt.
* [http://www.raisonance.com/rlink.html Raisonance RLink]
* [http://www.isystem.com/products/itag iTag] für 50€ bei [http://www.amazon.de/dp/B009XAQ9BW Amazon] bestellbar, alternativ als [http://isystem.com/products/hardware/cortex-debugger/itag/itag-instruction Eigenbauversion (offenes Design)] läuft mit der freien winIDEAiTag version (siehe oben)

In der Regel haben die [[JTAG]] Adapter einen 20-poligen Stecker, den man direkt auf die Demo-Boards mit 20-poligem [[JTAG]]-Anschluss einstecken kann. Die Pinbelegung ist genormt, siehe Artikel [[JTAG]]. Die Discovery-Boards haben keinen separaten JTAG-Stecker, aber man kann sich zumindest für das STM32F4 Discovery einen Adapter Pinheader->JTAG Stecker leicht selbst bauen.

===Programmieradapter Open-Source===

* [https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-COOCOX/ ARM-JTAG-COOCOX], CoLinkEX Nachbau von Olimex, unterstützt JTAG sowie SWD
** [http://www.coocox.org/wiki/coocox/CoLinkEx/CoLinkEx-Support unterstützte uC]
** unterstütze IDEs: [http://www.keil.com/arm/mdk.asp Keil MDK-ARM 4.03] oder neuer, [http://www.iar.com/en/Products/IAR-Embedded-Workbench/ IAR Embedded Workbench 5.xx] oder neuer sowie die [http://www.coocox.org/CooCox_CoIDE.htm CooCox CoIDE]
* [https://www.olimex.com/Products/ARM/JTAG/ Olimex] ARM-USB-OCD (ca. 60.-, hat zusätzlich einen Spannungsausgen und einen COM Port)
* [http://www.randomprojects.org/wiki/Floss-JTAG FLOSS-JTAG]

Der Controller hat auch einen fest eingebauten Boot-Lader. Damit läßt er sich auch über eine gewöhnliche serielle Schnittstelle programmieren, ohne dass man einen JTAG-Adapter benötigt. Dies erfordert ggf. entsprechende Konfiguration über die BOOTx-Pins und/oder die Option-Bytes, und ein Programm wie [https://code.google.com/p/stm32flash/ stm32flash].

=== Demo-Projekte ===

* Einführung in die GPIO Programmierung der STM32F10x und STM32F30x Prozessoren am Beispiel des STM32F3 Discovery Boards und Vergleich zur AVR IO Registerstruktur [http://www.mikrocontroller.net/topic/300472#new]
* [[prog_bsp_timer_1_timer2|Programmbeispiel für die Verwendung von Timer2 zusammen mit dem Interrupt]]
* [http://www.firefly-power.de/ARM/printf.html Printf() debugging mit minimalem Aufwand]
* [[STM32_BLDC_Control_with_HALL_Sensor|Programmbeispiel für BLDC Motoransteuerung (Timer 1) mit HALLSensor (Timer 3)]]
* [[Cortex_M3_OCM3U]]
* Martin Thomas hat ein umfangreiches Projekt erstellt, in der die Eclipse Einstellungen enthalten sind:
** [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html "ChaN's FAT-Module with STM32 SPI"]
* [[STM32 USB-FS-Device Lib]]
* Modellbau-Sender auf STM32-Basis mit vielen Treibern [http://www.rcos.eu www.rcos.eu]
* Ausführliches [https://github.com/jkerdels/stm32edu Einstiegs-Tutorial] in Codeform für das [http://www.st.com/internet/evalboard/product/252419.jsp STM32F4 discovery board]
* [http://www.redacom.ch/keillab/ Schweizer Gondelbahnsteuerung über Webserver auf ETT STM32F ARM KIT Board in Keil RTOS] mit Webcam
* Die [http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/ Ethernut SVN Version] unterstützt inzwischen viele STM32 Typen, viele Devices und einige STM32 Demoboards
* [http://mikrocontroller.bplaced.net/wordpress/?page_id=744 Uwe Becker's Libraries für den STM32F4]
* [http://mikrocontroller.bplaced.net/wordpress/?page_id=3290 Uwe Becker's STM32F429 Discovery Board Oszilloskop], hier der [http://www.mikrocontroller.net/topic/319831#new Thread]
* [http://mikrocontroller.bplaced.net/wordpress/?page_id=3424 Uwe Becker's STM32F429 Discovery Board ZX-Spectrum Emulator]
* [[USB-Tutorial mit STM32]] enthält ein vollständiges Beispielprojekt

== Debug- und Trace-Interface (CoreSight™ Debug and Trace Technologie)==

Übersicht über beide Funktionalitäten und den Schnittstellen:
http://www.keil.com/support/man/docs/ulink2/ulink2_cs_core_sight.htm

Die Coresight-Debug-Architektur ermöglicht ein nicht-invasives Debugging, d.h. es können während des Betriebes (meistens) ohne Beeinflussung des Prozessors Daten vom Speicher gelesen und in selbigen geschrieben werden.

=== Debugger Funktionen ===

Der Debugger-Teil besitzt drei Funktionen:
* Run Control: z.B. Programm-Start, Stopp und Einzel-Schritte.
* (Program) Break Points: Ein Programm hält an, wenn der Programm Counter eine bestimmte Programm-Adresse erreicht.
** Die maximale Anzahl der gleichzeitig möglichen Break Points ist begrenzt (z.B. 6 bei einem STM32).
** Die Anzahl der Break Points ist nahezu unbegrenzt, wenn ein Debugger über den Memory Access (s.u.) sogenannte Flash Break Points unterstützt. Dabei wird ein geladenes Programm im Flash umprogrammiert, um den Debugger anzuhalten. Diese Funktionalität ist meistens ein kostenpflichtiges Zusatz-Feature des Debugger-Herstellers.
** Beinhaltet keine Data Watch Funktionalität, welche im Trace-Teil (DWT) realisiert wird.
* Memory Access: Lesen und Schreiben von Speicheradressen.
** Diese Funktionalität beinhaltet keine direkte Flash-Programmierung. Der Programmiervorgang für einen Flash ist herstellerspezifisch und muss von dem verwendeten Debugger unterstützt werden.

=== Trace Funktionen ===
Die Trace-Funktionalität wird in drei Funktionen aufgeteilt:
* ETM (Embedded Trace Macrocell): Optional, nicht jede CPU besitzt diese Hardware (Kostenfaktor, Ausstattung).
* ITM (Instrumentation Trace Macrocell): Über diesen Kanal kann ein vereinfachtes Trace des Core ermöglicht werden, sowie "printf-ähnlich" Daten über den ITM Channel 0 geschickt und im Debugger ausgegeben werden.
* DWT (Data Watchpoint & Trace Unit):
** Data Watch: 4 Access-Break-Points ( z.B. der Debugger bleibt stehen, wenn das Programm auf einen Speicher zugreift oder der Wert einer Variablen einen bestimmten Wert annimmt).
** Trace Unit: Programmverlauf (durch Lesen des Program Counters) und Interrupt Aufrufe verfolgen, sowie Zeitmessungen.

Einige der Trace-Funktionalitäten können über die JTAG-Schnittstelle angesprochen werden. Die schnelle Trace-Funktionalität (mit 4 bit Parallel-Port) steht nur mit der erweiterten DEBUG + ETM Schnittstelle zur Verfügung. Im Gegensatz zum Debugger-Teil (Run Control, Break Points und Memory Access) werden Trace-Funktionen nicht von allen Debuggern unterstützt. Debugger mit der vollen Trace-Funktionalität kosten deutlich mehr.

* Beispiele für Trace-Port-Aktivierungen für verschiedene Hersteller: http://www.keil.com/support/man/docs/jlink/jlink_capture_tracedata.htm

Die Aktivierung des parallelen Trace-Ports erfordert, je nach CPU Hersteller, zusätzliche Debugger-Makros für die Aktivierung und Port-Freischaltung. Zusätzlich sind die Schnittstellenauswahl und Einstellung (Frequenzen) im Entwicklungs-Tool (IDE) wichtig, um erfolgreich den Programm-Verlauf "tracen" zu können.

=== Debug und Trace-Schnittstellen ===
Als Debug Interface stehen zwei Varianten zur Auswahl:
* [[JTAG]]: Dafür sind mindestens 6 Steuerleitungen nötig. Unterstützt Device Chaining: Mehrere verbundene Geräte können mit einem Debugger/Programmer gleichzeitig angesteuert werden.
* SWD (Serial Wire Debug): Hier mindestens 2 Steuerleitungen (3 mit SWO, zzgl GND und 3,3V). Die SWD Schnittstelle ist in der Regel schneller und kann auch Funktionen aus dem Trace-Teil beinhalten (z.B. ITM, dafür wird der SWO-Pin benötigt). Device Chaining ist mit dieser Schnittstelle nicht möglich.

Standard-JTAG Steckerbelegungen:
http://www.keil.com/support/man/docs/ulink2/ulink2_hw_connectors.htm

=== Der 10polige JTAG-Stecker von mmvisual ===
mmvisual hat mit dieser Steckerbelegung die Standard JTAG Schnittstelle erweitert:

Ich habe diesen Part in den Artikel [http://www.mikrocontroller.net/articles/JTAG#Der_10-polige_JTAG_Stecker_von_mmvisual JTAG] verschoben.
Hinzu gekommen ist die Adapterplatine 10-Polig auf Standard JTAG 20 Polig mit TTL/V24 Wandler. [http://www.mikrocontroller.net/articles/JTAG#Die_Adapterplatine Siehe hier.]

== Hardware-Beschaltung ==

Der STM32 benötigt für den Betrieb nur (Minimalbeschaltung):

* VCC 2..3,3V (je nach Typ)
* AVCC 2..3,3V (sehr wichtig, der STM32 lässt sich ohne diese Spannung nicht programmieren)
* GND
* Reset Pin 100nF nach GND (ein Pull-Up Widerstand von ca. 40k ist intern vorhanden)
* [[#Bootmodi|Boot-Pins]]

ansonsten nur ein paar einzelne Cs 100nF an VCC/GND.

Um Programmieren zu können wird entweder noch die serielle Schnittstelle (Programmieren über den vorprogrammierten Bootloader) oder JTAG oder die SWD Schnittstelle benötigt.

=== Bootmodi ===
Unterschiedliche Bootmodi lassen sich mittels der PINs BOOT0 und BOOT1 auswählen. Siehe Application Note [https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/18225/AN2606.pdf AN2606]. Außer F1 besitzen neuere Familien ein SYSCFG_MEMR Register. In dieses Register kann man die gewünschten Boot0/1 Werte schreiben und nach einem Core-Reset (!= System_Reset) startet der Prozessor im gewünschten Mode. Eine Neu- bzw. Deinitialisierung der Peripherie empfiehlt sich!

==== Boot from FLASH ====
Startadresse wird von 0x08000004 geladen
BOOT0 Lo
BOOT1 X

==== Boot from SRAM ====
PC Startadresse wird an 0x200001E0 direkt angesprungen.
BOOT0 Hi
BOOT1 Hi
Da der interne FLASH der stm32f1x laut Datenblatt nur für 10000 Schreibvorgänge ausgelegt ist, kann mittels BOOT0 (High) und BOOT1 (High) auch aus dem zuvor mit dem Debugger (JTAG/SWD) beschriebenen SRAM booten.
Hierbei gilt zu beachten:
VTOR auf die NVIC Tabelle im SRAM vor dem auslösen des ersten Interrupts remappen.

Um ein vergleichbares Startverhalten zum FLASH zu erreichen, empfiehlt es sich,
0xF1E0F85F an 0x200001E0 zu schreiben. Diese implizite Ausführung von "ldr.w pc,
[pc, #-0x01E0]" beim Start erzwingt ein laden der Startadresse von 0x20000004.

==== Boot from SYSMEM (RS232, CAN und USB) ====
PC Startadresse wird von 0x1FFFF004 geladen
BOOT0 Hi
BOOT1 Lo

Ab F2 gibt es auch ein SYSCFG_MEMRMR Register. Schreibt man hier den Wert für "System Flash" und macht einen Corereset (keinen Systemreset), so landet man auch im Bootloader, unabhängig vom Wert der Boot Pins.

Auch ohne JTAG lässt sich ein STM32 programmieren (Bootloader-Aktivierung). Dabei stehen, je nach CPU-Typ, verschiedene Möglichkeiten zur Verfügung:
* RS-232 (bisher alle STMs)
* USB (alle USB fähigen CPUs > F103)
* CAN (wie USB nur in bestimmten MCUs)

3 zusätzliche Verbindungen müssen auf dem Board gepatcht werden. Für einen Test geht es auch mit Tastern für RESET und BOOT0.<br>
RESET=RTS (L-aktiv)<br>
BOOT0=DTR (H-aktiv)<br>
BOOT1=LOW<br>

Details sind hier im Forum: [http://www.mikrocontroller.net/topic/141711 STM32 Programmiertool]

Tools für den Download über den STM32-Bootloader:
* [http://www.st.com/web/en/catalog/tools/PF257525 STSW-MCU005 STM32 and STM8 Flash loader demonstrator]
* [https://sourceforge.net/projects/stm32flash/ stm32flash] - Open source flash program (RS-232)
* [http://dfu-util.sourceforge.net/ dfu-util] - Open source flash program (USB)

== Bewertung ==
=== Vorteile ===

'''Vorteile gegenüber ARM7:'''

* Interrupt-Controller jetzt Teil des Prozessors (als Core Peripheral), die Vector Table ist jetzt eine echte Vektortabelle, keine Sprungliste wie bei ARM7. Durch Automatismen zwischen Core und NVIC (auto register save r0..r3, lr, sp, pc) bei Interrupt Entry wird eine deutlich schnellere Ausführungszeit bei Interrupts erreicht. Der Interrupt Code muss sich nicht mehr selbst um die Sicherung der o.g. Register kümmern und eine besondere Konfiguration der Handler im Compiler entfällt. Sind vor Beendigung einer ISR (d.h. Rücksprung zum User Code) weitere Interrupts pending, so werden diese ausgeführt, ohne dass eine komplette pop-push-sequenz der Register notwendig ist. Schön beschrieben ist es hier im [https://www.hitex.com/fileadmin/documents/tools/dev_tools/dt_protected/insiders-guides/stm32/isg-stm32-v18d-scr.pdf Insider's Guide] unter 2.4.5 / Seite 20 (falls der Link nicht mehr funktioniert, direkt nach isg-stm32-v18d-scr.pdf googlen kann helfen...).
* Thumb-2 Befehlssatz, deutlich schneller als Thumb-1 und ebenso kompakt
* Weniger Pins für Debugging benötigt durch SWD
* Mehr Hardware Breakpoints machen debuggen einfacher
* Software ist einfacher weil die Umschaltung zwischen ARM Mode und Thumb Mode wegfällt

'''Vorteile gegenüber LPC1700 und LPC1300:'''

* Flexiblere Gehäuseformen mit mehr Peripherie bei kleinen Gehäusen
* FW-Lib für alle STM32 gleich, alle AppNotes/Demos beziehen sich auf diese eine FW-Lib was die Entwicklung der eigenen Applikation sehr beschleunigt.
* Genauerer und flexiblerer ADC, insbesondere gegenüber LPC1300
* Flexiblere Varianten der Peripherie >> bei weniger einen deutlichen Preisvorteil
* ab 0,85 EUR (Stand 2010) Allerdings gibts den LPC1100 mit Cortex-M0 schon ab 0,65 $!

'''Vorteile gegenüber SAM3/4:'''

* Fast alle Pins sind 5-Volt tolerant.

'''Vorteile gegenüber anderen "Kleinen" wie z.B. PIC, Atmel usw.'''
* nahezu gleicher Preis bei Hobby Anwendungen
* 32 Bit ohne Umwege in Assembler rechenbar
* Schnelle direkte Offset-Adressierung ermöglicht effizienten Zugriff auf Stack-Variablen, lokal gespeicherte Flash-Konstanten, struct/Array-Elemente
* Einfache einheitliche Adressierung des gesamten Adressraums, d.h. Pointer auf Peripherieregister, RAM & Flash können exakt gleich behandelt werden, keinerlei Banking/Umschalt-Mechanismen erforderlich auch bei großem Flash/RAM
* Interrupt-Prioritäten und Prioritätsgruppen
* Effiziente Pointerarithmetik da Registerbreite=Adressbreite
* bessere Peripherie wie USB, Ethernet, Vielzahl an Timern
* der ARM-Core hat eine höhere Taktfrequenz und kann gleichzeitig mehr in weniger Takten berechnen
* Hardware-Division, bei einigen FPU zur effizienten float-Berechnung
* Mit größerem Flash/RAM verfügbar
* Code kann direkt aus dem RAM ausgeführt werden, Speicherschutz und privilegierter Ausführungsmodus können "Kernel"- vor "Anwendungs"-Code schützen, somit wird das dynamische Nachladen von Anwendungen aus externem Speicher effizient & sicher möglich
* ... und weitere 1000 Punkte ...

'''Links'''
* [http://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_%28full%29.pdf Code Size Analyse zwischen verschiedenen µC]

=== Nachteile ===

'''Nachteil gegenüber LPC1700:'''
* STM32F1xx: nur 72 MHz statt 100 MHz (LPC1759: 120 MHz) Taktfrequenz; STM32F2xx hat diesen Nachteil nicht (ebenfalls 120MHz, STM32F4xx mit 180MHz)
* Der LPC1700 besitzt deutlich mehr Mechanismen, um die Auswirkung der Waitstates des Flash-ROMs auf Code- und Datenzugriffe zu reduzieren und das bedeutet mehr Performance bei gleicher Taktfrequenz. Beim STM32F2 entfällt dieser Nachteil wohl aufgrund des ART Accelerators.
* Alle LPC1xxx haben 32 Bit Timer. Bei den STM32 haben das nur die STM32F2xx und STM32F4xx (2 Stück)
* I2S Einheit von ST hat keinen FIFO und im 24/32Bit Modus müssen 2x16Bit Halbwörter übertragen werden. Wobei allgemein bei neuen ARM Prozessoren die vorhandenen DMA-Kanäle (basierend auf eigenen BUS-Kanälen und Speicherzugriffen) FIFO in beliebiger Größe bedeutet. (Gilt nicht bei bestimmten STM32F4xx)

'''Nachteil für Hobby-Anwender'''

* Nicht direkt "Steckbrettauglich", da kein DIL Gehäuse verfügbar. Der ebay-Shop dipmicro führt jedoch sehr günstige Lötadapter für Umsetzung von LQFP48 auf DIP48. QFP64 in 0.5mm Pinabstand und nicht 0.8mm wie AVR. Von NXP gibt es Cortex-M0 µC im DIL Gehäuse.

* Viel Peripherie, Clocks müssen alle richtig eingestellt werden, ggf. Anpassung des Startup Codes usw.

'''

* Preis-Leistungs-Verhältnis in der Regel schlechter, da geringere Verkaufsstückzahlen

== Errata, Tipps und Tricks ==
=== Hardware ===
* AD-Wandler PA0: Im Errata steht, dass hier Fehler in der Wandlung entstehen könnten, also einen anderen Pin verwenden.
* CAN-Bus PD0/PD1: Remap geht erst ab der 100-Pin-Version. Steht im RM0008 unter 9.3.3.: "CAN1 alternate function remapping". Alle Infos von RM0008 9.3.x sind interessant
* CAN und USB sind bei der F1 Serie nur bei der "◦Connectivity-Line" gleichzeitig nutzbar. Siehe Datenblätter.
* Mit internem RC-Oszillator kann die CPU mit maximal 64MHz betrieben werden. Mit einem externen Quarz sind dann 72MHz möglich.
* Für USB Betrieb muss die CPU mit 48MHz oder 72MHz betrieben werden (bei STM32F1xx).
* Der Idle Interrupt vom Usart wird zwar ausgelöst, aber nicht vom entsprechenden Statusflag angezeigt
* Der DMA fängt beim aktivieren immer von vorn an zu zählen, auch wenn er nur kurz angehalten wurde
* STM32F2xx hat kein Flash Size Register, bei STM32F4xx ist zwar ein flash Size Register beschrieben, kollidiert aber in der Adresse mit einem anderen Register
* Derivate mit internem EEPROM und nur einer Speicherbank haben das "Feature" bei write/erase des Data-Flashes (EEPROM) einen kompletten stall der code execution zu verursachen (inkl. ISRs, DMA). Desgleichen bei write/erase des internen Flash (ISP-routinen, EEPROM-Emulation).
* Der I2C hat diverse Fehler, welche im Errata des jeweiligen Modells (z.B. [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/CD00238166.pdf STM32F105xx and STM32F107xx Errata sheet] ) zu finden sind. Workarounds hierzu finden sich in der Application Note [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00209826.pdf AN2824]. Am Besten benutzt man jedoch die I2C Communication peripheral application library (CPAL) von ST ([http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF258336 STSW-STM32127])
* [http://blog.frankvh.com/category/stm32/ weitere undokumentierte Features]
* Interrupt-Flags in Statusregistern der diversen Peripherals wie der Timer müssen zu '''Beginn''' (bzw. möglichst weit vor dem Return) der ISR zurückgesetzt werden, da die ISR sonst eventuell 2x ausgeführt wird (Siehe [https://my.st.com/public/Faq/Lists/faqlst/DispForm.aspx?ID=143&level=1&objectid=141 STM32 FAQ] und [http://www.mikrocontroller.net/topic/312393#new Forum]).

=== Software ===
==== Allgemein ====
Standard-GPIOs des STM32 und im speziellen das BSRR
* Die Register bestehen aus zwei Teilen, der obere Teil BR0-15 signalisiert durch ein gesetztes Bit die zu löschenden Bits im IO-ODR-Register,der untere Teil BS0-15 signalisiert durch ein gesetztes Bit die zu setzenden Bits. Besonders ist, wenn beide Bits (oberer und unterer Teil) gesetzt sind hat das Set-Bit Priorität. Durch eine geschickte Kombination von oberen und unteren Teil kann man Speicherzugriffe Sparen. z.B. kann man solch ein Konstrukt zum ändern der unteren 8 Bit des IO-ODR-Registers "uint32_t temp = GPIOC->ODR & 0xff00; GPIOC->ODR = temp | (Eingabe & 0x00ff)" um einen Speicherzugriff verkürzen zu "GPIOC->BSRR = (Eingabe & 0x00ff) | ((0x00ff) << 16)"

==== GCC ====
Um den GCC direkt zu verwenden (zB. mit selbstgebautem makefile), falls man das nicht von einer Entwicklungsumgebung machen lässt, siehe zunächst [[ARM GCC]]. STM32-spezifisches ist:
* Wird die [[#.E2.80.8ESTM32_Standard_Peripheral_Library|STM32 Standard Peripheral Library]] und ein Quarz verwendet, so muss noch per Präprozessor-Definition die Frequenz des Quarzes angegeben werden mittels z.B. -DHSE_VALUE=8000000 für 8MHz (wie auf dem STM32F4 Discovery).

===== Startupcode & Linkerscript =====
* Damit der compilierte Code an den richtigen Stellen im Controller landet (d.h. dem Flash) muss man dem Linker ein Linkerscript mitgeben. Dies geht per "-T ''pfad_zum_linkerscript.ld''" an den Linker-Befehl. Im Archiv der [[#.E2.80.8ESTM32_Standard_Peripheral_Library|STM32 Standard Peripheral Library]] befindet sich ein Beispiel-Linkerscript für die Atollic TrueSTUDIO IDE, dieses kann direkt mit dem GCC verwendet werden. Beispielsweise für den STM32F4 befindet sich das Script im Pfad "/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Project/STM32F4xx_StdPeriph_Templates/TrueSTUDIO/STM324x7I_EVAL/stm32_flash.ld" des Archives.
* Damit beim Starten die richtigen Initialisierungen vorgenommen werden (wie globale Variablen und bei C++ Konstruktoren globaler Objekt-Instanzen) muss als erstes ein Startupcode laufen, der dann die main()-Funktion aufruft. Der Startupcode ist meistens in Assembler geschrieben, C-Code ist aber auch möglich. Im Archiv der [[#.E2.80.8ESTM32_Standard_Peripheral_Library|STM32 Standard Peripheral Library]] befindet sich ein Beispiel-Startupcode für die Atollic TrueSTUDIO IDE, dieser kann direkt mit dem GCC verwendet werden. Beispielsweise für den STM32F4 befindet sich der Code in Assemblerform im Pfad "/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Libraries/CMSIS/Device/ST/STM32F4xx/Source/Templates/TrueSTUDIO/startup_stm32f40xx.s" des Archives. Der Assemblercode kann per arm-none-eabi-as (Flags s.o.) assembliert werden, die resultierende .o -Datei normal mitgelinkt.

Zusammen bieten die beiden Dateien der Anwendung ein Standard-C-Interface, d.h. man kann wie gewohnt globale Variablen verwenden und seinen Code in die main()-Funktion schreiben.

=== Tipps für Umsteiger von Atmel/PIC/8051 ===
* Prozessortakt hat unterschiedliche Taktquellen und eine PLL.
* Alle Peripheriemodule haben einen extra Clock, den man aktivieren muss.
* Wenn man z.B. einen UART benutzen möchte, so muss man den Clock vom UART, Alternate Function IO (AFIO) und den GPIO-Port aktivieren.
* Ansonsten hat man nahezu doppelt so viele Möglichkeiten in den Peripheriemodulen.
* Interrupt-Flags müssen in der ISR selber gelöscht werden
* Forum zu [http://www.mikrocontroller.net/topic/175888 Interrupts vs. Events]

=== Errata vom STM32F4xx die nicht im Errata von ST stehen ===
* [http://www.mikrocontroller.net/topic/267439#2788478 Aktivieren von DMA], wenn mehr als 3 DMA Kanäle aktiviert werden, kann es sein dass die nicht alle korrekt bedient werden. Auch klappt der DMA mit dem FSMC nicht immer zuverlässig. [https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FWarning%20limit%20simultaneous%20DMAs%20to%202&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=811 siehe hier] [http://blog.frankvh.com/2012/01/13/stm32f2xx-stm32f4xx-dma-maximum-transactions/ und hier]
* [http://www.mikrocontroller.net/topic/260637#2700761 Nerviger Bug in "stm32f4xx.h"] Änderung Struktur GPIO_TypeDef
* [http://www.mikrocontroller.net/topic/261690#2714754 Batterie wird leer gezogen], nur bei manchen Chips mit Rev. A
* [http://www.efton.sk/STM32/STM32F4xx_doc_errors.txt Liste von Dokumentations-Fehlern]

== Bezugsquellen ==

=== Controller ===

Versandhäuser für Privatpersonen
* [http://www.reichelt.de/STM-Controller/2/index.html?;ACTION=2;LA=2;GROUPID=2950; Reichelt]
* [http://darisusgmbh.de/shop/index.php?cat=c2692_ARM-Cortex.html Darisus]
* [https://www.tme.eu/de/katalog/st-mikrocontroller_112866/ TME]
* [http://de.rs-online.com/web/c/halbleiter/prozessoren-und-mikrocontroller/mikrocontroller/?sort-by=default&sort-order=default&applied-dimensions=4294417325&lastAttributeSelectedBlock=4294425895 RS-Online]
* [http://www.mouser.de/STMicroelectronics/Semiconductors/Embedded-Processors-Controllers/Microcontrollers-MCU/ARM-Microcontrollers-MCU/_/N-a85pc?P=1z0zpefZ1yzud1pZ1yzmxr3Z1yzud8sZ1yztkjiZ1yzonn5Z1yznfad&FS=True Mouser]
* [https://www.conrad.de/de/embedded-mikrocontroller-o0214046.html Conrad]

Gewerblich liefern natürlich viele wie EBV, [http://de.futureelectronics.com Future Electronics], Farnell, Digikey usw...

=== Evaluation Boards ===
* [https://www.conrad.de/de/stmicroelectronics-entwicklungs-kits-o0214062.html diverse Nucleo- und Discovery-Boards bei Conrad]
* [https://www.reichelt.de/Einplatinen-Microcontroller/2/index.html?ACTION=2&LA=3&GROUPID=6667 diverse Nucleo-Boards bei Reichelt]
* [http://www.watterott.com/index.php?page=search&keywords=STM32&cat=40&subkat=on&mnf=&sdesc=on&desc=on&x=79&y=19 STM32 bei Watterott (unter anderem Olimex- und Nucleo-Boards)]
* [https://www.olimex.com/Products/ARM/ST/ STM32-Boards direkt bei Olimex]
* [http://shop.myavr.de/Hardware.htm?sp=artlist_kat.sp.php&katID=51 verschiedene STM32-Boards myAVR]
* [http://www.sander-electronic.de/es0028.html Sander Electronic]
* [http://www.futurlec.com/STM32_Development_Board.shtml Futurlec Evalboard, ebenso Header-Board]
* [http://www.mikrocontroller.net/articles/MP32F103-Stick:_Ein_Mini-Mikrocontroller-Board_mit_USB_und_bis_zu_4MB_Datenspeicher Artikel im Wiki, ARM mit USB und 4MB Speicher]
* [http://www.mikrocontroller.net/articles/Cortex_M3_OCM3U Cortex M3 Artikel im Wiki]
* [http://de.farnell.com/jsp/displayProduct.jsp?sku=1824325&action=view&CMP=GRHS-1000962 STM32Discovery bei Farnell] Mikrocontroller Board (STM32F100RBT6B) mit onboard USB-Programming Interface für ca. 12,50€
* [https://dsp-sys.de/24-bayerhw-de/26-xynergy-xs-so-dimm-module-mit-cortex-m4-spartan-6-ddr3-ram SO-DIMM Module mit STM32F4, Spartan-6 & DDR3 RAM] Breakout-Board mit CAN (2x isoliert), UART, LAN, SPI, I2C and USB-OTG u.v.m.

== Weblinks, Foren, Communities, Tutorials ==
* [http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks STM32 - Einstieg mit Em::Blocks Tutorial]
* [http://www.mikrocontroller.net/forum/mikrocontroller-elektronik?filter=ARM*+STM32*+Cortex* Suche im Forum]
* [[STM32 für Einsteiger]]
* http://www.openstm32.org/System+Workbench+for+STM32
* [https://community.st.com/ Forum auf der ST Homepage]
*[http://joe-c.de/pages/posts/einstieg_mikrocontroller_stm32f103_101.php Einstieg: STM32board mit Kamera (deutsch)]
* [http://diller-technologies.de/stm32_wide.html STM32 Tutorial für Standard Peripheral Library in Deutsch]
* [http://mySTM32.de STM32 C und C++ Tutorial in Deutsch ]
* [http://myugl.de Tutorial für Grafik-Librarys und SiSy-Projekte in Deutsch ]
* [http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF251717 MicroXplorer MCU graphical configuration tool ]
* [http://www.harerod.de/docs/CoreMark_STM32.pdf Testbericht über CoreMark 1.0 auf Cortex-M3/M4 mit verschiedenen Compiler- und MCU-Einstellungen]
* [http://klaus4.blogspot.com/2014/05/stm32f4-discovery-mit-opensource.html STM32-Toolchain mit Eclipse CDT 4.3, GnuArmEclipse, OpenOCD 0.8.0, Gnu Arm GCC 4.8, STM32CubeMX]
* [http://libopencm3.org/ libopenmc3 OpenSource libs für STM32 und ähnliche]
* [https://www.mikrocontroller.net/topic/423300#new Totzeitrechner für STM32]
* [https://leanpub.com/mastering-stm32 Download-Buch in englisch, min. 25$ "Mastering STM32"]
* [http://stefanfrings.de/stm32/index.html STM32 L0/F1/F3 Anleitung]
* [https://www.cs.indiana.edu/~geobrown/book.pdf "Discovering the STM32 Microcontroller" eBook (kostenlos)]
* [http://stefanfrings.de/mikrocontroller_buch2/index.html Einblick in die moderne Elektronik ohne viel Theorie] '''PDF''', Programmieranleitung für Anfänger
* [[USB-Tutorial mit STM32]]
* [http://www.pomad.fr/node/2 Sehr schönes STM32 Anfängertutorial mit Codeanalyse bis in die Register]
* [http://dodo.fb06.fh-muenchen.de/parzhuber/SKRIPT_C_STM32.pdf Einführung in die C Programmierung für Mikrocontroller Schwerpunkt STM32 Prof. Dr.-Ing.Otto Parzhuber Hochschule München FK06]

<references/>
[[Kategorie:ARM]]
[[Kategorie:STM32]]
[[Kategorie:Mikrocontroller]]

I2C als Hausbus

2022-09-21T08:26:15Z

172.26.6.198: /* Eigene Erfahrungen */

I2C als Hausbus

2022-09-21T08:22:40Z

172.26.6.198: /* Infos */

= Infos =

دا وطن افغانستان دی
دا عزت د هر افغان دى
كور د سولې، كور د تورې
هر بچى يې قهرمان دى

دا وطن د ټولو كور دى
د بلوڅو، د ازبكو
پــښــتــنو او هزاراو
د تركمنو، د تاجكو

ور سره عرب، ګوجر دي
پاميريان، نورستانيان
براهوي دي، قزلباش دي
هم ايماق، هم پشايان

دا هيواد به تل ځلېږي
لكه لمر پر شنه آسمان
په سينې كې د آسيا به
لكه زړه وي جاويدان

نوم د حق مو دى رهبر
وايو الله اكبر
وايو الله اكبر
وايو الله اكبر

= Adressierung =

Wie viele Adressen einzelne I²C Bausteine haben, ist unterschiedlich. In der Regel sind 1-8 Adressen möglich. Es gibt aber auch (neuere) Bausteine die bis zu 64 mögliche Adressen haben. Somit kann es also sein, das man evt. Probleme bekommt wenn man mehrere Bausteine des selben Typs einsetzen will.

In dieser Hinsicht ist der PCA9501 I/O Expander Baustein recht interessant. Er bietet als einer der wenigen älteren Bausteine bis zu 64 mögliche Adressen. Zudem hat er ein integriertes EEPROM (256 Byte) und ist somit für Hausbus Anwendungen gut geeignet.

Eine andere Lösung dieses Problems ist die Verwendung von I²C Multiplexern- bzw. Switches. Wie z.B. den PCA9544. Dieser Baustein kann einzelne Busabschnitte bei Bedarf abtrennen, so das man in den einzelnen Abschnitten identische Adressen verwenden kann.

= Eigene Erfahrungen =

Vor einigen Jahren war ich als Servicetechniker bei einer Geräteinstallation im Einsatz, bei der die laut Datenblatt möglichen Längen bei weitem überschritten wurden. Ab 12m ging nix mehr. Der Grund war aber nicht der I²C-Bus, sondern die Spannungsversorgung der entfernten Geräte. Die Masseleitung war auch 12m lang, und der Stromverbrauch der Geräte hat den Massepegel soweit angehoben, dass der I²C-Bus nicht mehr funktioniert hat. Mit einer dickeren Masseleitung hat's sofort wieder funktioniert.

Die Kabel sind (bezüglich der gemeinsamen Masse) eine Kette über differentiell kleiner Widerstände parallel geschaltener differentiell kleiner Kondensatoren. Durch einen Pegel-Wechsel müssen all diese kleinen Kondensatoren über die Widerstände umgeladen werden. Folge ist eine deutlich kleinere Ausbreitungs-Geschwindigkeit des Signals und ein geringerer Spannungs-Anstieg an den Anschlüssen der Geräte. Zu der Kapazität der Kabel kommt vor allem noch die Kapazität der Geräte. Im I²C-Standard von Philips ist diese Kapazität auf 400pF limitiert. Im access.bus-Standard (welcher für Computer-Komponenten und Peripherie entwickelt wurde) ist diese Kapazität auf 1000pF beschränkt. Vgl. Ausbreitungsgeschwindigkeiten, Kapazitäten bei anderen Bus-Systemen wie USB, SATA, RS485

Meine Slaves tun sich gut auf der Baumwolle Plantage. Diese arbeiten überragend!

----

Habe ein I2C Netzwerk im Haus, sternfoermig und Reihe gemischt,
vielleicht 40m alles zusammen, bei 70kHz mit P82B715 an allen Knoten,
CAT5 Kabel, laeuft einwandfrei. Musst natuerlich Fehlererkennung (NACK)
etc Routinen vorhalten.

----

Habe bei meinem I2C-Hausbus eine Kabellänge
von ca. 120m. Auch sternförmig und reihe gemischt. Taktfrequenz 96kHz,
jedes der 22 Module ist mit einem P82B715 ausgestattet. Den Pull-up
Widerstand von SDA und SCL habe ich auf 180 Ohm verringert. Läuft
fehlerfrei seit ca. 15 Jahren. Verwendetes Kabel für SCL, SDA:
2x0,14mm², geschirmt. Spannungsversorgung +/-15V und Interrupt: 5x1,5².

----

Mein I2C-Hausbus hat ca. 150m Gesamtlänge, Topologie sowohl als Stern, als auch Linien gemischt. Taktfrequenz 3 kHz und weitere Optimierungen. Einheitlicher Bus mit Masse/SDA/SCL und +12V zur Stromversorgung. Läuft seit 2004 weitgehend fehlerfrei. Dokumentation im Netz (Projekt Hauscomputer).

= Passende Sensoren / Module =
* Temperatursensor mit dem [[Temperatursensor#DS1621|DS1621]]
* [[I2C-Schaltmodul]] mit dem [[Port-Expander_PCF8574|PCF8574]]
* [http://cctools.hs-control.de/ext_index.php?artikel=1824 I²C-CAN Modul]
* [http://www.horter.de/i2c/index.htm I²C Module]

= Links =

== Allgemein ==
* [http://www.i2c-bus.org/ I²C-Bus Infoseite]
* [https://www.nxp.com/products/interfaces/ic-bus:MC_41735 Übersicht I²C Bausteine von NXP]
* [http://www.hendonsemiconductors.com/bus-buffer.asp Hendon Semiconductors (Viele Application Notes)]

== Foren Beiträge ==

* [http://www.mikrocontroller.net/topic/71426#582586 I2C über 1,2km Kabel mit CAN-Transceiver]
* [http://www.mikrocontroller.net/topic/40880 I2C über 200m Kabel mit P82B96]

== Application Notes ==

* [http://www.nxp.com/documents/application_note/AN10658.pdf AN10658 (Sending I2C-bus signals via long communications)]
* [http://www.nxp.com/documents/application_note/AN460.pdf AN460 (Using the P82B96 for bus interface)]
* [http://www.nxp.com/documents/application_note/AN255.pdf AN255 (I²C / SMBus Repeaters, Hubs and Expanders)]

== Praktische Anwendungen ==

* [http://haus-computer.de Projekt Hauscomputer]
* [https://gkiefer.github.io/home2l Projekt ''The Home2Ls'']

== Siehe auch ==

* [[Hausbus_auf_I2C-_und_ATtiny-Basis:_Home2L_Brownies|Hausbus auf I²C- und ATtiny-Basis]]

[[Kategorie:Projekte]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]

I2C als Hausbus

2022-09-21T08:20:20Z

172.26.6.198: /* Datensicherheit */

I2C als Hausbus

2022-09-21T08:19:47Z

172.26.6.198: /* Datensicherheit */

I2C als Hausbus

2022-09-21T08:18:42Z

172.26.6.198: /* Datensicherheit */

Hausbus auf I2C- und ATtiny-Basis: Home2L Brownies

2022-09-21T08:17:13Z

172.26.6.198: /* Einleitung */

== Einleitung ==
Feldmann is ein fetter
Das "''Home2L Brownies''"-Projekt verfolgt das Ziel, eine einfache, effiziente und dennoch robuste Plattform zu schaffen für einen Hausbus mit vernetzter Selbstbau-Hardware. Die Hauptziele sind:

* einfache, transparente Hardware

* hohe Zuverlässigkeit und Langzeit-Stabilität

* offene, dokumentierte und erweiterbare Software

* gute Wartbarkeit

* geringer Standby-Stromverbrauch (Ziel: eine Größenordnung / Faktor 10 weniger als ein KNX-System)

Als Sensor/Aktor-Knoten kommen ''ATtiny84/85/861''-Mikrocontroller zum Einsatz - die Knoten werden hier als ''Brownies'' bezeichnet (vgl. [https://en.wikipedia.org/w/index.php?title=Brownie_(folklore)&oldid=929557103 Wikipedia: Brownie (folklore)]). Die ''Brownies'' werden über 4-adrige Kabel (z.B. KNX/EIB) mit einem Linux-Hostrechner vernetzt. Dort werden alle Ressourcen (Sensor-Werte, Aktor-Zustände) wahlweise über eine C++-API, Python-API oder ein Kommandozeilen-Tool zugänglich gemacht.

Dieser Artikel gibt (nur) einen Überblick über das Projekt. Details sind auf der [https://github.com/gkiefer/home2l GitHub-Seite zum ''Home2L''-Projekt] zu finden. Dort finden sich auch die Dokumentation zum gesamten ''Home2L''-Projekt ([https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book'']) sowie ein ausführliches Schritt-für-Schritt-Tutorial mit Beispiel-Schaltungsaufbau.

== Messdaten einer realen Beispiel-Installation ==

* Linux-Host mit zwei ARM-Cortex-A9-CPUs und I²C-Schnittstelle (''CubieTruck'')

* 25 Brownies an einem Bus-Baum, die insgesamt u.a. bedienen:
** 43 Reed-Kontakte für 22 Fenster
** 20 Rollläden (40 Relais)
** 20 Temperatursensoren

* 4 primäre Hubs, einzelne Unter-Hubs (insgesamt drei Bus-Ebenen)

* Leistungsaufnahme insgesamt: ca. 250 Milliwatt (50 mA * 5 V) (ohne Linux-Host)

* Kommunikationsstatistik über 6 Tage: 44,3 Mio Nachrichtenwechsel, nur 11 korrigierte Übertragungsfehler (0,000025%)

== Warum 8-Bit-Mikrocontroller? ==

Für die Auswahl der ''ATtiny''-Typen sprechen die folgenden Gründe:

* Sie sind simpel, robust und ausgereift.

* Sie sind in DIP-Gehäusen verfügbar - sehr gut für Selbstbauprojekte!

* Es ist sehr wenig externe Beschaltung nötig: Zwei Widerstände, ein obligatorischer Abblockkondensator und der Mikrocontroller selbst reichen aus, um einen ''Brownie''-Knoten aufzubauen. Die Frage nach einem käuflichen (Eval-)Board stellt sich damit nicht - man braucht keins.

* Der Stromverbrauch ist gering, selbst bei 5V Versorgungsspannung. So lassen sich zum Beispiel ohne weitere Spannungswandler sowohl der Controller als auch Relais betreiben.

* Die Rechenleistung und der Speicher sind für gängige Sensorik wie Fensterkontakte oder Temperaturfühler völlig ausreichend.

Aufgrund der einfachen Beschaltung und der DIP-Gehäuse ist es zum Beispiel möglich, handgelötete Schaltungen auf einer Lochrasterplatine aufzubauen, die dennoch klein genug sind, um in einer Unterputz-Dose Platz zu finden - manchmal nützlich bei Selbstbauprojekten.

== Der ''Home2L''-Bus ==

Der ''Home2L''-Bus basiert auf I²C. Da der Takt explizit durch das SCL-Signal vorliegt, können die ''ATtinys'' mit ihrem internen Takt arbeiten, ein Quarz ist nicht nötig. Auf zusätzliche Transceiver-Bausteine, wie bei CAN oder RS485 üblich, kann ebenso verzichtet werden.

Die Spannungsversorgung beträgt 5V. Jeweils am Master befinden sich Pull-Up-Widerstände von 1 kOhm an SDA/SCL sowie jeweils auf Master- und Slave-Seite Serienwiderstände von 100 Ohm. Letztere begrenzen den Umschaltstrom insbesondere bei langen Leitungen.

Der Bus erfüllt den I²C-Standard bis auf die folgenden beiden Ausnahmen:

# Der maximale Strom liegt bei 5 mA, und die Leitungskapazitäten überschreiten in der Regel die Vorgaben des I²C-Standards.
# Es gibt eine Protokoll-Erweiterung, mit der sich Bus-Slaves gegenüber dem Master bemerkbar machen können (''Host Notification'').

Die ''Host Notification'' ist optional, sodass bei entsprechender elektrischer Beschaltung die ''Brownies'' vollkommen I²C-konform kommunizieren können.

Experimente beim Autor des ''Home2L''-Projektes haben gezeigt, dass eine Kommunikation über 100 Meter KNX-Kabel mit ca. 30 kBit/s praktisch übertragungsfehlerfrei funktioniert, ohne dass zum Beispiel spezielle Bustreiber nötig wären. Um dennoch mit elektrischen Störungen, die bei langen Leitungen auftreten können, umgehen zu können, sind eine Reihe von Techniken implementiert:

* ''Brownies'' können als ''Hub''-Knoten arbeiten und Datenverkehr tranparent an einen Unterbus und zurück durchleiten. So kann der Hausbus in einen Baum von Unterbussen aufgeteilt werden. Lange Leitungen können so in kleinere Segmente aufgeteilt werden. Hubs können beliebig tief kaskadiert werden, und jeder Hub kann prinzipiell beliebig viele eigene Slaves bedienen. Die einzige Limitierung ist die Zahl der verfügbaren Busadressen.

* Die Bitrate ist in der Regel gegenüber I²C reduziert, bei 1 MHz CPU-Takt sind aktuell etwa 30 KBit/s brutto möglich. Sie kann außerdem für kritische Unterbusse bei Bedarf weiter reduziert und so an die physikalischen Gegebenheiten angepasst werden.

* Das Protokoll definiert sehr kurze Nachrichten, sodass in der Regel keine allzu hohen Bitraten notwendig sind. Das Nachrichtenpaar (Request/Reply) für typische Wertabfragen hat zusammen 6 Bytes inklusive Adressierungen und Prüfsummen.

* CRC-Prüfsummen erlauben die Erkennung von Fehlern. Der Linux-Treiber implementiert Wiederholungsstrategien und sammelt Fehlerstatistiken, um eventuelle Problemstellen im Bus-Netz zu identifizieren zu können.

== Die Firmware ==

Die ''Brownie''-Firmware ist konfigurierbar. Sie enthält einige Basis-Funktionalität sowie eine Auswahl an ''Feature''-Modulen für verschiedene Sensor- oder Aktor-Typen. Sowohl die Feature-Auswahl als auch der Controller-Typ (aktuell ''ATtiny84'', ''ATtiny85'' oder ''ATtiny861'') sind konfigurierbar.

Der 8 KB Flash-Speicher wird in zwei Bereiche zu 2,5 KB und 5,5 KB aufgeteilt. Der vordere, kleinere Bereich enthält eine minimale ''Maintenance''-Firmware, der andere Bereich die Haupt-Firmware für den operativen Betrieb. Mit beiden Firmwares ist es möglich, die jeweils andere neu zu flashen. Somit sind Updates im Feld möglich, was sehr nützlich ist, wenn die Controller zum Beispiel an schwer zugänglichen Stellen, wie in Unterputz-Dosen, verbaut sind.

Die Basis-Funktionalität der Firmware umfasst:

* den Kommunikations-Stack für den Bus (Slave-Seite),

* Lesen und Schreiben der Konfiguration (inklusive ID und Bus-Adresse),

* Lesen der Firmware-Kennung, -Version und -Features,

* Lesen und Schreiben (sofern erlaubt) aller Speicher (Flash, RAM, EEPROM),

* Firmware-Updates,

* Reset des Controllers,

* Wechseln und Starten der Maintenance- bzw. operativen Firmware,

Zum Ansteuern von Sensoren und Aktoren stehen aktuell die folgenden Feature-Module zur Verfügung:

* GPIO: beliebige digitale Ein- und Ausgänge

* Temperaturfühler per ''ZACwire''-Protokoll (für TSiC 206/306)

* Matrix: Abfrage von Schaltern, die auch als Diodenmatrix verschaltet sein dürfen (z.B. Fenster-Kontakte, Tastenfelder). Bei Fensterkontakten ist eine "geöffnet/gekippt"-Erkennung in verschiedenen Varianten möglich.

* Rollläden (''Shades''): Ansteuerung von elektrischen Rollläden per Relais-Paar und Taster-Paar; intelligente Steuerung: aktuelle Position wird per Zeitmessung verfolgt, Rolläden bleiben auch bei Kommunikationsverlust steuerbar.

Weitere Feature-Module sind in Planung bzw. können einfach hinzugefügt werden.

== Das Wartungs-Tool ==

Für den Linux-Host gibt es ein Wartungs-Tool ''(home2l-brownie2l)''. Dieses kann mit den einzelnen ''Brownies'' über eine beliebige I²C-Schnittstelle kommunizieren, die von Linux unterstützt wird (Kernel-Modul ''i2c-dev''). Alternativ ist es auch möglich das "ELV USB-I2C"-Interface direkt zu verwenden, das sich unter Linux als serielle Schnittstelle meldet.

Mit dem Wartungs-Tool ''(home2l-brownie2l)'' kann man ...

* ... eine aktuelle Liste der ''Brownie''-Register und Konfigurationsparameter anzeigen (Online-Hilfe).

* ... einen Bus-Scan durchführen, um alle verbundenen Knoten zu identifizieren.

* ... eine Vorlage für eine ''Brownie''-Datenbank (Datei ''brownies.conf'') erzeugen. Die Datenbank ist eine Textdatei, die alle ''Brownies'' und deren Konfigurationsparameter enthält. Sie hilft bei der Wartung größerer Installationen und wird vom Ressourcen-Treiber (siehe unten) benötigt.

* ... ''Brownie''-Register lesen oder beschreiben.

* ... Konfigurationsparameter lesen oder setzen.

* ... beliebige Speicherinhalte eines ''Brownie'' auslesen und anzeigen.

* ... Firmware flashen (aus ELF-Dateien).

* ... den ''Brownie'' neustarten und dabei ggfs. die Firmware (Maintenance/operative) umschalten.

* ... die Taktgenauigkeit messen und den internen Timer (das AVR OSCCAL-Register) kalibrieren.

* ... einen Kommunikationstest durchführen.

* ... Kommunikations- und Fehlerstatistiken sammeln und anzeigen.

* ... bei Hubs: Den Unterbus ein- und ausschalten sowie Unterknoten, deren operative Firmware beim Starten abstürzt (warum auch immer ...), durch Umschalten auf die Maintenance-Firmware wiederbeleben (''Resurrection'').

* ... einige dieser Vorgänge auch im Batch-Betrieb mehrfach ausführen, um zum Beispiel mit einem Kommando bei allen Knoten ein Firmware-Update durchzuführen.

Die Bedienung des Tools wird durch die Online-Hilfe erklärt:

$ home2l brownie2l
brownie2l> help
...

== Zugriff auf Brownie-Features vom Linux-Host ==

Um die Ressourcen der ''Brownies'', wie zum Beispiel die Zustände von GPIOs oder Temperaturwerte, auf dem Host-Rechner zur Verfügung zu stellen, wird die ''Resources''-Bibliothek der ''Home2L''-Projektes verwendet. Diese bietet eine einheitliche Schnittstelle zum Zugriff auf die Ressourcen. Zugriff auf die Ressourcen ist auf drei verschiedene Arten möglich:

# interaktiv oder per Shell-Skript mit dem Tool ''home2l-shell'',
# in Python über die [https://gkiefer.github.io/home2l/home2l-api_python/index.html Python-API],
# in C/C++ über die [https://gkiefer.github.io/home2l/home2l-api_c/group__resources.html C/C++-API].

Beispiele, insbesondere zur Verwendung der ''home2l-shell'' und der Python-API, sind im [https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book'' (Kapitel 2)] zu finden.

Wer von der recht umfangreichen ''Home2L-Suite'' nur den ''Brownie''-Treiber nutzen möchte, kann die Software mit den Kommandos

make CFG=basic
sudo make CFG=basic install
/opt/home2l/bin/home2l-install -i

installieren und anschließend eine minimale Konfigurationsdatei ''/opt/home2l/etc/home2l.conf'' mit folgendem Inhalt anlegen:

rc.config="" # keine 'resources.conf'-Datei vorhanden/verwenden
drv.brownies=1 # ''Brownies''-Treiber aktivieren
br.link=/dev/i2c-1 # i2c-Gerät definieren (entsprechend anpassen!)

Dazu muss dann noch die Datei ''/opt/home2l/etc/brownies.conf'' wie oben beschrieben angelegt werden.

Anschließend kann zum Beispiel mit ''home2l-shell'' auf die Ressourcen zugegriffen werden:

$ home2l shell
home2l> l /local/brownies/
...

== Weitere Informationen ==

Das [https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book''] enthält die Dokumentation des ''Home2L''-Projektes. Dort findet sich ein ausführliches Schritt-für-Schritt-Tutorial für den Einstieg.

Der Aufbau und die Inbetriebnahme einer einfachen ''Brownie''-Schaltung auf dem Steckbrett ist dort im Abschitt ''Brownies: Integrating Do-It-Yourself Hardware'' beschrieben.

== Downloads ==

* [https://github.com/gkiefer/home2l Quellcode auf GitHub]
* [https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book'' - Dokumentation zum Projekt (englisch) mit ausführlichem Einstiegs-Tutorial]

== Siehe auch ==

* [[I2C_als_Hausbus|I2C als Hausbus]]
* [[Fensterkontakt_und_Integration_ins_Smart_Home]]

[[Kategorie:AVR-Projekte| ]]
[[Kategorie:Projekte| ]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]
[[Kategorie:AVR-Programmer und -Bootloader‏‎]]

I2C als Hausbus

2022-09-21T08:16:08Z

172.26.6.198: /* Datensicherheit */

I2C als Hausbus

2022-09-21T08:15:08Z

172.26.6.198: /* Datensicherheit */

I2C als Hausbus

2022-09-21T08:14:31Z

172.26.6.198: /* Infos */

I2C als Hausbus

2022-09-21T08:14:24Z

172.26.6.198: /* Datensicherheit */

I2C als Hausbus

2022-09-21T08:13:45Z

172.26.6.198: /* Datensicherheit */

I2C als Hausbus

2022-09-21T08:12:08Z

172.26.6.198: /* Datensicherheit */

I2C als Hausbus

2022-09-21T08:11:52Z

172.26.6.198: /* Infos */

I2C als Hausbus

2022-09-21T08:10:28Z

172.26.6.198: /* Infos */

I2C als Hausbus

2022-09-21T08:08:43Z

172.26.6.198: /* Kleinerer Pull-Up */

= Infos =

Infos allgemein zu [[Hausbus]], [[I²C]].

Es wird oft behauptet das I²C nur für Verbindungen innerhalb einer Leiterplatte gedacht ist. Das ist sicherlich die Hauptanwendung, aber es gibt auch allseits bekannte Einsatzgebiete wo etliche Meter überbrückt werden. Bei VGA (DDC) und HDMI wird z.B. eine I²C-Bus Verbindung zur Kommunikation zwischen den Endgeräten benutzt. VGA und HDMI Kabel können (offiziell) rund 15m lang sein.

Allerdings werden für diesen Einsatz oftmals auch spezielle Treiber Bausteine eingesetzt, die eine höhere Buskapazität vertragen, verbesserten ESD Schutz haben, die Pegel übersetzen (z.B. 3,3 auf 5V), Hot-Plug-fähig sind, etc. Als Beispiel sei hier der PCA9507 (NXP) aufgeführt, der einige dieser Eigenschaften besitzt.

Michael Lassey ist SCHULD!

= Verkabelung =

== Kabellänge ==

I²C ist nicht als "long range" Bus entwickelt worden. Daher ist eines der Hauptprobleme bei I²C als Hausbus, dass man ohne weiteres nicht weiter als ein paar Meter kommt.
Das liegt daran das die I²C Leitungen eine maximale Kapazität von 400pF nicht übersteigen dürfen, da der high-Zustand auf dem Bus nur passiv über Pull-Ups erreicht wird. Je mehr Kapazität an einer I²C-Bus Leitung hängt, desto länger braucht der Bus also um den high-Zustand zu erreichen. Das kann zu timing Problemen führen.

Es gibt zur Reichweitenerhöhung verschiedene Ansätze:
# Kleinerer Pull-Up
# Geschwindigkeitsreduktion
# Bustreiber
# Differentielle Übertragung
# Aktiver Pull-Up

=== Kleinerer Pull-Up ===

Da das Kernproblem darin liegt, dass der high-Zustand nur passiv erreicht wird, bietet es sich an den Pull-Up Widerstand zu verkleinern um dadurch die Zeit zu verkürzen die der Bus benötigt den high-Zustand zu Erreichen

Begrenzt wird dieses Vorhaben dadurch, dass I²C Geräte nur 3mA sinken können (Die weiter unten besprochenen Bustreiber umgehen genau dieses Problem). Bei der Berechnung der Pull-Ups muss also darauf geachtet werden, dass nicht mehr als 3mA durch einen Widerstand fließen. Eine Ausnahme stellen I²C Geräte dar, die der ''Fm+'' (oder höher) Spezifikation entsprechen (Fm+ = Fast mode Plus). Diese sind in der Lage 30mA zu stinken.

wer das liest ist doof

=== Geschwindigkeitsreduktion ===

Wenn die Busgeschwindigkeit angepasst wird, sind große Strecken und umfangreiche Verzweigungen möglich. Ein 30-Meter-Bus funktioniert zum Beispiel noch mit rund 20kHz fast ohne Probleme.
Bei Geschwindigkeiten um 1kHz, wurde im Forum schon von Buslängen von etlichen hundert Metern berichtet.

=== Bustreiber ===

Bustreiber haben die Aufgabe die maximale Buskapazität von 400pF zu erhöhen. Dies erreichen die Bausteine i.d.R. durch eine Steigerung des Stroms auf dem Bus.
Die drei bekanntesten Bustreiber für diesen Zweck sind folgende:

* P82B715 (3000pF, max. 100kHz)
* P82B96 (4000pF, max. 400kHz)
* PCA9600 (4000pF, max. 1MHz)

Alle drei Typen haben ihre Vor- und Nachteile. Wobei der PCA9600 als Nachfolger vom P82B96 angesehen werden kann und im Prinzip nur Vorteile gegenüber dem P82B96 hat (Abgesehen vom Preis und der Beschaffbarkeit ;) - [http://www.reichelt.de/PCF-I-C-Bus-Controller/PCA-9600-D/3/index.html?;ACTION=3;LA=446;ARTICLE=126478;GROUPID=2942;artnr=PCA+9600+D '''PCA9600''' Gibts nun bei Reichelt!])

Der Hauptunterschied zwischen P82B96 und PCA9600 sind die Spannungspegel an der Sx/Sy Seite des ICs. Der P82B96 kann diese Pins bei einem low-Signal nicht weiter als 0,88V nach unten ziehen (I²C kompatibel, nicht TTL kompatibel). Der verbesserte PCA9600 kann bis auf 0,74V herunter ziehen (I²C und TTL kompatibel). Des weiteren hat der PCA weniger Laufzeitverzögerung und ist bis zu 1MHz Bustakt spezifiziert.

Der P82B96 (und PCA9600) verhindert eine Rückkopplung indem er an seinen Sx/Sy Eingängen ein low bei 0,65V erkennt, ein low selber aber nur mit 0,88V ausgeben kann. Informationen die über die T/R Seite kommen, werden also von einem zweiten, parallelgeschalteten, Bustreiber des gleichen Typs nicht weitergeleitet. Im Gegensatz zum P82B715 können die ICs verschiedene Busspannungen "übersetzen". Die gepufferte Seite kann also mit einer anderen Busspannung betrieben werden als die Sx/Sy Seite.

P82B96 und PCA9600 können statisch 30mA treiben. In der Application Note AN10216 (Seite 46) wird von NXP geschrieben das mittels externer Transistoren der Strom noch weiter erhöht werden kann. Bei 30kHz wird eine mögliche Gesamtlänge von 1km angegeben.

Recht einfach aufgebaut ist der P82B715. Intern arbeitet nur ein Stromsensor, der auf der gepufferten Seite mittels Transistors den Strom bei low Pegel erhöht. Er hat somit nicht die Probleme mit bestimmten Spannungspegeln wie die P82B96 und PCA9600 ICs. Dafür muss beim P82B715 auch die ungepufferte Seite zur Gesamtbuslast mit einbezogen werden. Auch ist es nicht möglich die gepufferte Seite mit anderer Spannung zu bertreiben.
Auf der gepufferten Seite (LDA/LCL) besitzt der P82B715 nur jeweils einen Pin für jede Busleitung. Applikationen die getrennte TX und RX Pins benötigen, sind mit dem P82B715 also nicht möglich.

=== Differentielle Übertragung ===

In Kombintation mit einem Bustreiber wie dem P82B96, ist es möglich die I²C Bus Signale über RS-485 oder CAN physikalisch zu "tunneln" (PHY Layer).

Dabei werden die TX und RX Leitungen des I²C Bustreibers mit den TX und RX Leitungen des RS-485 oder CAN Treibers verbunden. Für SDA und SCL werden hierfür auf dem Übertragungskabel also insgesamt vier Leitungen benötigt.

NXP hat mit den P82B485/P82B486 auch Treiber angekündigt, die den I²C-Bus direkt auf RS485 übersetzen.

=== Aktiver Pull-Up ===

Linear Technology bietet einige ICs wie den LTC1694 an, der den passiven low-high Wechsel des I²C-Bus durch eine Stromquelle beschleunigt.

== Topologie ==

Über die günstigste Topologie (Stern, Bus,..) ist bisher nichts bekannt.

== Störsicherheit/EMV ==
Bei der Nutzung als Feldbus müssen die Busteilnehmer sowohl gegen Störungen und Überspannung geschützt werden (induktive/kapazitive Einkopplungen), als auch Maßnahmen getroffen werden gegen zu große Störabstrahlung des Busses in die Umwelt. Wesentlich ist dabei die Begrenzung des maximalen Spannungsanstieges dU/dT auf allen Busleitungen und der Schutz vor Spannungsspitzen. Dazu gibt es folgende Möglichkeiten:
* Verwendung abgeschirmter und/oder verdrillter Leitungen mit zentraler Erdung
* Überspannungsschutz bei den Busteilnehmern - durch Schottkydioden zwischen SDA/SCL gegen Masse und VCC unmittelbar an den Slaves und Serienwiderstände in den Datenleitungen in der Anbindung zum Bus (typ. 50 … 200 Ohm)
* Passive Pi-Filter an allen Busteilnehmern, abgestimmt auf die höchste Übertragungsrate
Eine effektive Variante zum Schutz vor Überspannung, Spannungsausfall beim Slave und zugleich Pegelanpassung:

[[Datei:Pegelshifter&EMV.png|600px|Schaltplan]]

= Datensicherheit =

Von Hause aus ist bei I²C keine Checksumme o.ä. vorgesehen. Einzelne Bytes werden nur mit einem ACK bestätigt.

Man muss also eigene Konzepte entwickeln um sicherzugehen, dass Daten korrekt gesendet und empfangen wurden.

Einige Möglichkeiten wären:
* Geschriebene Daten zurücklesen
* Daten immer mehrmals schreiben/lesen
* Wenn man µC als Slave programmiert, kann man eine Checksumme als zusätzliches Byte mitübertragen

Ein weiteres Problem ist, dass Slaves sowohl das SDA Datensignal, als auch das SCL Taktsignal (Clock-Stretching) dauerhaft auf "Low" ziehen können, was den Totalausfall des Busses zur Folge hat. Das kann z.B. beim Ausfall der Stromversorgung eines Slaves auftreten, es sind aber auch Schaltkreise bekannt, die diese Fehlfunktion bei längerem Betrieb zeigen (z.B. LM75). Die Auswirkungen eines lokalen Stromausfalls begrenzt ein klassischer Pegelshifter mit MOSFET, zwischen Bus und Slave geschaltet, bereits zuverlässig. Das Erlauben von Clock-Stretching ist generell ein Problem, da das Bus-Timing und somit die Reaktion des Gesamtsystems in Echtzeit nicht mehr garantiert werden können.

= Adressierung =

Wie viele Adressen einzelne I²C Bausteine haben, ist unterschiedlich. In der Regel sind 1-8 Adressen möglich. Es gibt aber auch (neuere) Bausteine die bis zu 64 mögliche Adressen haben. Somit kann es also sein, das man evt. Probleme bekommt wenn man mehrere Bausteine des selben Typs einsetzen will.

In dieser Hinsicht ist der PCA9501 I/O Expander Baustein recht interessant. Er bietet als einer der wenigen älteren Bausteine bis zu 64 mögliche Adressen. Zudem hat er ein integriertes EEPROM (256 Byte) und ist somit für Hausbus Anwendungen gut geeignet.

Eine andere Lösung dieses Problems ist die Verwendung von I²C Multiplexern- bzw. Switches. Wie z.B. den PCA9544. Dieser Baustein kann einzelne Busabschnitte bei Bedarf abtrennen, so das man in den einzelnen Abschnitten identische Adressen verwenden kann.

= Eigene Erfahrungen =

Vor einigen Jahren war ich als Servicetechniker bei einer Geräteinstallation im Einsatz, bei der die laut Datenblatt möglichen Längen bei weitem überschritten wurden. Ab 12m ging nix mehr. Der Grund war aber nicht der I²C-Bus, sondern die Spannungsversorgung der entfernten Geräte. Die Masseleitung war auch 12m lang, und der Stromverbrauch der Geräte hat den Massepegel soweit angehoben, dass der I²C-Bus nicht mehr funktioniert hat. Mit einer dickeren Masseleitung hat's sofort wieder funktioniert.

Die Kabel sind (bezüglich der gemeinsamen Masse) eine Kette über differentiell kleiner Widerstände parallel geschaltener differentiell kleiner Kondensatoren. Durch einen Pegel-Wechsel müssen all diese kleinen Kondensatoren über die Widerstände umgeladen werden. Folge ist eine deutlich kleinere Ausbreitungs-Geschwindigkeit des Signals und ein geringerer Spannungs-Anstieg an den Anschlüssen der Geräte. Zu der Kapazität der Kabel kommt vor allem noch die Kapazität der Geräte. Im I²C-Standard von Philips ist diese Kapazität auf 400pF limitiert. Im access.bus-Standard (welcher für Computer-Komponenten und Peripherie entwickelt wurde) ist diese Kapazität auf 1000pF beschränkt. Vgl. Ausbreitungsgeschwindigkeiten, Kapazitäten bei anderen Bus-Systemen wie USB, SATA, RS485

----

Habe ein I2C Netzwerk im Haus, sternfoermig und Reihe gemischt,
vielleicht 40m alles zusammen, bei 70kHz mit P82B715 an allen Knoten,
CAT5 Kabel, laeuft einwandfrei. Musst natuerlich Fehlererkennung (NACK)
etc Routinen vorhalten.

----

Habe bei meinem I2C-Hausbus eine Kabellänge
von ca. 120m. Auch sternförmig und reihe gemischt. Taktfrequenz 96kHz,
jedes der 22 Module ist mit einem P82B715 ausgestattet. Den Pull-up
Widerstand von SDA und SCL habe ich auf 180 Ohm verringert. Läuft
fehlerfrei seit ca. 15 Jahren. Verwendetes Kabel für SCL, SDA:
2x0,14mm², geschirmt. Spannungsversorgung +/-15V und Interrupt: 5x1,5².

----

Mein I2C-Hausbus hat ca. 150m Gesamtlänge, Topologie sowohl als Stern, als auch Linien gemischt. Taktfrequenz 3 kHz und weitere Optimierungen. Einheitlicher Bus mit Masse/SDA/SCL und +12V zur Stromversorgung. Läuft seit 2004 weitgehend fehlerfrei. Dokumentation im Netz (Projekt Hauscomputer).

= Passende Sensoren / Module =
* Temperatursensor mit dem [[Temperatursensor#DS1621|DS1621]]
* [[I2C-Schaltmodul]] mit dem [[Port-Expander_PCF8574|PCF8574]]
* [http://cctools.hs-control.de/ext_index.php?artikel=1824 I²C-CAN Modul]
* [http://www.horter.de/i2c/index.htm I²C Module]

= Links =

== Allgemein ==
* [http://www.i2c-bus.org/ I²C-Bus Infoseite]
* [https://www.nxp.com/products/interfaces/ic-bus:MC_41735 Übersicht I²C Bausteine von NXP]
* [http://www.hendonsemiconductors.com/bus-buffer.asp Hendon Semiconductors (Viele Application Notes)]

== Foren Beiträge ==

* [http://www.mikrocontroller.net/topic/71426#582586 I2C über 1,2km Kabel mit CAN-Transceiver]
* [http://www.mikrocontroller.net/topic/40880 I2C über 200m Kabel mit P82B96]

== Application Notes ==

* [http://www.nxp.com/documents/application_note/AN10658.pdf AN10658 (Sending I2C-bus signals via long communications)]
* [http://www.nxp.com/documents/application_note/AN460.pdf AN460 (Using the P82B96 for bus interface)]
* [http://www.nxp.com/documents/application_note/AN255.pdf AN255 (I²C / SMBus Repeaters, Hubs and Expanders)]

== Praktische Anwendungen ==

* [http://haus-computer.de Projekt Hauscomputer]
* [https://gkiefer.github.io/home2l Projekt ''The Home2Ls'']

== Siehe auch ==

* [[Hausbus_auf_I2C-_und_ATtiny-Basis:_Home2L_Brownies|Hausbus auf I²C- und ATtiny-Basis]]

[[Kategorie:Projekte]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]

I2C als Hausbus

2022-09-21T08:04:10Z

172.26.6.198: /* Kleinerer Pull-Up */

= Infos =

Infos allgemein zu [[Hausbus]], [[I²C]].

Es wird oft behauptet das I²C nur für Verbindungen innerhalb einer Leiterplatte gedacht ist. Das ist sicherlich die Hauptanwendung, aber es gibt auch allseits bekannte Einsatzgebiete wo etliche Meter überbrückt werden. Bei VGA (DDC) und HDMI wird z.B. eine I²C-Bus Verbindung zur Kommunikation zwischen den Endgeräten benutzt. VGA und HDMI Kabel können (offiziell) rund 15m lang sein.

Allerdings werden für diesen Einsatz oftmals auch spezielle Treiber Bausteine eingesetzt, die eine höhere Buskapazität vertragen, verbesserten ESD Schutz haben, die Pegel übersetzen (z.B. 3,3 auf 5V), Hot-Plug-fähig sind, etc. Als Beispiel sei hier der PCA9507 (NXP) aufgeführt, der einige dieser Eigenschaften besitzt.

= Vorteile =

Man kann Slave Bausteine "von der Stange" kaufen, ohne sich Gedanken über Protokoll und Adressierung zu machen. Denn das ist bereits schon implementiert.
Alternativ kann man aber auch eigene Slaves bauen und an den Bus hängen. Dafür haben viele µC schon eine Hardware I²C Schnittstelle integriert. Wobei man aber auch recht einfach eine I²C Schnittstelle in Software nachbilden kann.

I²C Bausteine sind reine State-Machines. Somit sind viele von Hause aus recht Stromsparend. Der PCA9554 benötigt z.B. nur 250nA im "Standby-Mode" (keine Kommunikation).

Bei I²C gibt der Master den Takt (SCL) für die Datenübertragung vor. Die Slaves benötigen im Gegensatz zu UART also keinen genauen Taktgeber (Quarz). Will man den Takt auf dem Bus verringern, so muss man das nur am Master einstellen. Die Slaves benötigen keine Änderung. So ist es auch möglich den Takt dynamisch zu variieren und z.B. wichtige Nachrichten mit geringem Takt (Störunempfindlicher) zu übertragen und andere Nachrichten mit höherem Takt.

= Verkabelung =

== Kabellänge ==

I²C ist nicht als "long range" Bus entwickelt worden. Daher ist eines der Hauptprobleme bei I²C als Hausbus, dass man ohne weiteres nicht weiter als ein paar Meter kommt.
Das liegt daran das die I²C Leitungen eine maximale Kapazität von 400pF nicht übersteigen dürfen, da der high-Zustand auf dem Bus nur passiv über Pull-Ups erreicht wird. Je mehr Kapazität an einer I²C-Bus Leitung hängt, desto länger braucht der Bus also um den high-Zustand zu erreichen. Das kann zu timing Problemen führen.

Es gibt zur Reichweitenerhöhung verschiedene Ansätze:
# Kleinerer Pull-Up
# Geschwindigkeitsreduktion
# Bustreiber
# Differentielle Übertragung
# Aktiver Pull-Up

=== Kleinerer Pull-Up ===

Da das Kernproblem darin liegt, dass der high-Zustand nur passiv erreicht wird, bietet es sich an den Pull-Up Widerstand zu verkleinern um dadurch die Zeit zu verkürzen die der Bus benötigt den high-Zustand zu Erreichen

Begrenzt wird dieses Vorhaben dadurch, dass I²C Geräte nur 3mA sinken können (Die weiter unten besprochenen Bustreiber umgehen genau dieses Problem). Bei der Berechnung der Pull-Ups muss also darauf geachtet werden, dass nicht mehr als 3mA durch einen Widerstand fließen. Eine Ausnahme stellen I²C Geräte dar, die der ''Fm+'' (oder höher) Spezifikation entsprechen (Fm+ = Fast mode Plus). Diese sind in der Lage 30mA zu sinken.

=== Geschwindigkeitsreduktion ===

Wenn die Busgeschwindigkeit angepasst wird, sind große Strecken und umfangreiche Verzweigungen möglich. Ein 30-Meter-Bus funktioniert zum Beispiel noch mit rund 20kHz fast ohne Probleme.
Bei Geschwindigkeiten um 1kHz, wurde im Forum schon von Buslängen von etlichen hundert Metern berichtet.

=== Bustreiber ===

Bustreiber haben die Aufgabe die maximale Buskapazität von 400pF zu erhöhen. Dies erreichen die Bausteine i.d.R. durch eine Steigerung des Stroms auf dem Bus.
Die drei bekanntesten Bustreiber für diesen Zweck sind folgende:

* P82B715 (3000pF, max. 100kHz)
* P82B96 (4000pF, max. 400kHz)
* PCA9600 (4000pF, max. 1MHz)

Alle drei Typen haben ihre Vor- und Nachteile. Wobei der PCA9600 als Nachfolger vom P82B96 angesehen werden kann und im Prinzip nur Vorteile gegenüber dem P82B96 hat (Abgesehen vom Preis und der Beschaffbarkeit ;) - [http://www.reichelt.de/PCF-I-C-Bus-Controller/PCA-9600-D/3/index.html?;ACTION=3;LA=446;ARTICLE=126478;GROUPID=2942;artnr=PCA+9600+D '''PCA9600''' Gibts nun bei Reichelt!])

Der Hauptunterschied zwischen P82B96 und PCA9600 sind die Spannungspegel an der Sx/Sy Seite des ICs. Der P82B96 kann diese Pins bei einem low-Signal nicht weiter als 0,88V nach unten ziehen (I²C kompatibel, nicht TTL kompatibel). Der verbesserte PCA9600 kann bis auf 0,74V herunter ziehen (I²C und TTL kompatibel). Des weiteren hat der PCA weniger Laufzeitverzögerung und ist bis zu 1MHz Bustakt spezifiziert.

Der P82B96 (und PCA9600) verhindert eine Rückkopplung indem er an seinen Sx/Sy Eingängen ein low bei 0,65V erkennt, ein low selber aber nur mit 0,88V ausgeben kann. Informationen die über die T/R Seite kommen, werden also von einem zweiten, parallelgeschalteten, Bustreiber des gleichen Typs nicht weitergeleitet. Im Gegensatz zum P82B715 können die ICs verschiedene Busspannungen "übersetzen". Die gepufferte Seite kann also mit einer anderen Busspannung betrieben werden als die Sx/Sy Seite.

P82B96 und PCA9600 können statisch 30mA treiben. In der Application Note AN10216 (Seite 46) wird von NXP geschrieben das mittels externer Transistoren der Strom noch weiter erhöht werden kann. Bei 30kHz wird eine mögliche Gesamtlänge von 1km angegeben.

Recht einfach aufgebaut ist der P82B715. Intern arbeitet nur ein Stromsensor, der auf der gepufferten Seite mittels Transistors den Strom bei low Pegel erhöht. Er hat somit nicht die Probleme mit bestimmten Spannungspegeln wie die P82B96 und PCA9600 ICs. Dafür muss beim P82B715 auch die ungepufferte Seite zur Gesamtbuslast mit einbezogen werden. Auch ist es nicht möglich die gepufferte Seite mit anderer Spannung zu bertreiben.
Auf der gepufferten Seite (LDA/LCL) besitzt der P82B715 nur jeweils einen Pin für jede Busleitung. Applikationen die getrennte TX und RX Pins benötigen, sind mit dem P82B715 also nicht möglich.

=== Differentielle Übertragung ===

In Kombintation mit einem Bustreiber wie dem P82B96, ist es möglich die I²C Bus Signale über RS-485 oder CAN physikalisch zu "tunneln" (PHY Layer).

Dabei werden die TX und RX Leitungen des I²C Bustreibers mit den TX und RX Leitungen des RS-485 oder CAN Treibers verbunden. Für SDA und SCL werden hierfür auf dem Übertragungskabel also insgesamt vier Leitungen benötigt.

NXP hat mit den P82B485/P82B486 auch Treiber angekündigt, die den I²C-Bus direkt auf RS485 übersetzen.

=== Aktiver Pull-Up ===

Linear Technology bietet einige ICs wie den LTC1694 an, der den passiven low-high Wechsel des I²C-Bus durch eine Stromquelle beschleunigt.

== Topologie ==

Über die günstigste Topologie (Stern, Bus,..) ist bisher nichts bekannt.

== Störsicherheit/EMV ==
Bei der Nutzung als Feldbus müssen die Busteilnehmer sowohl gegen Störungen und Überspannung geschützt werden (induktive/kapazitive Einkopplungen), als auch Maßnahmen getroffen werden gegen zu große Störabstrahlung des Busses in die Umwelt. Wesentlich ist dabei die Begrenzung des maximalen Spannungsanstieges dU/dT auf allen Busleitungen und der Schutz vor Spannungsspitzen. Dazu gibt es folgende Möglichkeiten:
* Verwendung abgeschirmter und/oder verdrillter Leitungen mit zentraler Erdung
* Überspannungsschutz bei den Busteilnehmern - durch Schottkydioden zwischen SDA/SCL gegen Masse und VCC unmittelbar an den Slaves und Serienwiderstände in den Datenleitungen in der Anbindung zum Bus (typ. 50 … 200 Ohm)
* Passive Pi-Filter an allen Busteilnehmern, abgestimmt auf die höchste Übertragungsrate
Eine effektive Variante zum Schutz vor Überspannung, Spannungsausfall beim Slave und zugleich Pegelanpassung:

[[Datei:Pegelshifter&EMV.png|600px|Schaltplan]]

= Datensicherheit =

Von Hause aus ist bei I²C keine Checksumme o.ä. vorgesehen. Einzelne Bytes werden nur mit einem ACK bestätigt.

Man muss also eigene Konzepte entwickeln um sicherzugehen, dass Daten korrekt gesendet und empfangen wurden.

Einige Möglichkeiten wären:
* Geschriebene Daten zurücklesen
* Daten immer mehrmals schreiben/lesen
* Wenn man µC als Slave programmiert, kann man eine Checksumme als zusätzliches Byte mitübertragen

Ein weiteres Problem ist, dass Slaves sowohl das SDA Datensignal, als auch das SCL Taktsignal (Clock-Stretching) dauerhaft auf "Low" ziehen können, was den Totalausfall des Busses zur Folge hat. Das kann z.B. beim Ausfall der Stromversorgung eines Slaves auftreten, es sind aber auch Schaltkreise bekannt, die diese Fehlfunktion bei längerem Betrieb zeigen (z.B. LM75). Die Auswirkungen eines lokalen Stromausfalls begrenzt ein klassischer Pegelshifter mit MOSFET, zwischen Bus und Slave geschaltet, bereits zuverlässig. Das Erlauben von Clock-Stretching ist generell ein Problem, da das Bus-Timing und somit die Reaktion des Gesamtsystems in Echtzeit nicht mehr garantiert werden können.

= Adressierung =

Wie viele Adressen einzelne I²C Bausteine haben, ist unterschiedlich. In der Regel sind 1-8 Adressen möglich. Es gibt aber auch (neuere) Bausteine die bis zu 64 mögliche Adressen haben. Somit kann es also sein, das man evt. Probleme bekommt wenn man mehrere Bausteine des selben Typs einsetzen will.

In dieser Hinsicht ist der PCA9501 I/O Expander Baustein recht interessant. Er bietet als einer der wenigen älteren Bausteine bis zu 64 mögliche Adressen. Zudem hat er ein integriertes EEPROM (256 Byte) und ist somit für Hausbus Anwendungen gut geeignet.

Eine andere Lösung dieses Problems ist die Verwendung von I²C Multiplexern- bzw. Switches. Wie z.B. den PCA9544. Dieser Baustein kann einzelne Busabschnitte bei Bedarf abtrennen, so das man in den einzelnen Abschnitten identische Adressen verwenden kann.

= Eigene Erfahrungen =

Vor einigen Jahren war ich als Servicetechniker bei einer Geräteinstallation im Einsatz, bei der die laut Datenblatt möglichen Längen bei weitem überschritten wurden. Ab 12m ging nix mehr. Der Grund war aber nicht der I²C-Bus, sondern die Spannungsversorgung der entfernten Geräte. Die Masseleitung war auch 12m lang, und der Stromverbrauch der Geräte hat den Massepegel soweit angehoben, dass der I²C-Bus nicht mehr funktioniert hat. Mit einer dickeren Masseleitung hat's sofort wieder funktioniert.

Die Kabel sind (bezüglich der gemeinsamen Masse) eine Kette über differentiell kleiner Widerstände parallel geschaltener differentiell kleiner Kondensatoren. Durch einen Pegel-Wechsel müssen all diese kleinen Kondensatoren über die Widerstände umgeladen werden. Folge ist eine deutlich kleinere Ausbreitungs-Geschwindigkeit des Signals und ein geringerer Spannungs-Anstieg an den Anschlüssen der Geräte. Zu der Kapazität der Kabel kommt vor allem noch die Kapazität der Geräte. Im I²C-Standard von Philips ist diese Kapazität auf 400pF limitiert. Im access.bus-Standard (welcher für Computer-Komponenten und Peripherie entwickelt wurde) ist diese Kapazität auf 1000pF beschränkt. Vgl. Ausbreitungsgeschwindigkeiten, Kapazitäten bei anderen Bus-Systemen wie USB, SATA, RS485

----

Habe ein I2C Netzwerk im Haus, sternfoermig und Reihe gemischt,
vielleicht 40m alles zusammen, bei 70kHz mit P82B715 an allen Knoten,
CAT5 Kabel, laeuft einwandfrei. Musst natuerlich Fehlererkennung (NACK)
etc Routinen vorhalten.

----

Habe bei meinem I2C-Hausbus eine Kabellänge
von ca. 120m. Auch sternförmig und reihe gemischt. Taktfrequenz 96kHz,
jedes der 22 Module ist mit einem P82B715 ausgestattet. Den Pull-up
Widerstand von SDA und SCL habe ich auf 180 Ohm verringert. Läuft
fehlerfrei seit ca. 15 Jahren. Verwendetes Kabel für SCL, SDA:
2x0,14mm², geschirmt. Spannungsversorgung +/-15V und Interrupt: 5x1,5².

----

Mein I2C-Hausbus hat ca. 150m Gesamtlänge, Topologie sowohl als Stern, als auch Linien gemischt. Taktfrequenz 3 kHz und weitere Optimierungen. Einheitlicher Bus mit Masse/SDA/SCL und +12V zur Stromversorgung. Läuft seit 2004 weitgehend fehlerfrei. Dokumentation im Netz (Projekt Hauscomputer).

= Passende Sensoren / Module =
* Temperatursensor mit dem [[Temperatursensor#DS1621|DS1621]]
* [[I2C-Schaltmodul]] mit dem [[Port-Expander_PCF8574|PCF8574]]
* [http://cctools.hs-control.de/ext_index.php?artikel=1824 I²C-CAN Modul]
* [http://www.horter.de/i2c/index.htm I²C Module]

= Links =

== Allgemein ==
* [http://www.i2c-bus.org/ I²C-Bus Infoseite]
* [https://www.nxp.com/products/interfaces/ic-bus:MC_41735 Übersicht I²C Bausteine von NXP]
* [http://www.hendonsemiconductors.com/bus-buffer.asp Hendon Semiconductors (Viele Application Notes)]

== Foren Beiträge ==

* [http://www.mikrocontroller.net/topic/71426#582586 I2C über 1,2km Kabel mit CAN-Transceiver]
* [http://www.mikrocontroller.net/topic/40880 I2C über 200m Kabel mit P82B96]

== Application Notes ==

* [http://www.nxp.com/documents/application_note/AN10658.pdf AN10658 (Sending I2C-bus signals via long communications)]
* [http://www.nxp.com/documents/application_note/AN460.pdf AN460 (Using the P82B96 for bus interface)]
* [http://www.nxp.com/documents/application_note/AN255.pdf AN255 (I²C / SMBus Repeaters, Hubs and Expanders)]

== Praktische Anwendungen ==

* [http://haus-computer.de Projekt Hauscomputer]
* [https://gkiefer.github.io/home2l Projekt ''The Home2Ls'']

== Siehe auch ==

* [[Hausbus_auf_I2C-_und_ATtiny-Basis:_Home2L_Brownies|Hausbus auf I²C- und ATtiny-Basis]]

[[Kategorie:Projekte]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]

I2C als Hausbus

2022-09-21T08:00:54Z

172.26.6.198: /* Kleinerer Pull-Up */

= Infos =

Infos allgemein zu [[Hausbus]], [[I²C]].

Es wird oft behauptet das I²C nur für Verbindungen innerhalb einer Leiterplatte gedacht ist. Das ist sicherlich die Hauptanwendung, aber es gibt auch allseits bekannte Einsatzgebiete wo etliche Meter überbrückt werden. Bei VGA (DDC) und HDMI wird z.B. eine I²C-Bus Verbindung zur Kommunikation zwischen den Endgeräten benutzt. VGA und HDMI Kabel können (offiziell) rund 15m lang sein.

Allerdings werden für diesen Einsatz oftmals auch spezielle Treiber Bausteine eingesetzt, die eine höhere Buskapazität vertragen, verbesserten ESD Schutz haben, die Pegel übersetzen (z.B. 3,3 auf 5V), Hot-Plug-fähig sind, etc. Als Beispiel sei hier der PCA9507 (NXP) aufgeführt, der einige dieser Eigenschaften besitzt.

= Vorteile =

Man kann Slave Bausteine "von der Stange" kaufen, ohne sich Gedanken über Protokoll und Adressierung zu machen. Denn das ist bereits schon implementiert.
Alternativ kann man aber auch eigene Slaves bauen und an den Bus hängen. Dafür haben viele µC schon eine Hardware I²C Schnittstelle integriert. Wobei man aber auch recht einfach eine I²C Schnittstelle in Software nachbilden kann.

I²C Bausteine sind reine State-Machines. Somit sind viele von Hause aus recht Stromsparend. Der PCA9554 benötigt z.B. nur 250nA im "Standby-Mode" (keine Kommunikation).

Bei I²C gibt der Master den Takt (SCL) für die Datenübertragung vor. Die Slaves benötigen im Gegensatz zu UART also keinen genauen Taktgeber (Quarz). Will man den Takt auf dem Bus verringern, so muss man das nur am Master einstellen. Die Slaves benötigen keine Änderung. So ist es auch möglich den Takt dynamisch zu variieren und z.B. wichtige Nachrichten mit geringem Takt (Störunempfindlicher) zu übertragen und andere Nachrichten mit höherem Takt.

= Verkabelung =

== Kabellänge ==

I²C ist nicht als "long range" Bus entwickelt worden. Daher ist eines der Hauptprobleme bei I²C als Hausbus, dass man ohne weiteres nicht weiter als ein paar Meter kommt.
Das liegt daran das die I²C Leitungen eine maximale Kapazität von 400pF nicht übersteigen dürfen, da der high-Zustand auf dem Bus nur passiv über Pull-Ups erreicht wird. Je mehr Kapazität an einer I²C-Bus Leitung hängt, desto länger braucht der Bus also um den high-Zustand zu erreichen. Das kann zu timing Problemen führen.

Es gibt zur Reichweitenerhöhung verschiedene Ansätze:
# Kleinerer Pull-Up
# Geschwindigkeitsreduktion
# Bustreiber
# Differentielle Übertragung
# Aktiver Pull-Up

=== Kleinerer Pull-Up ===

Da das Kernproblem darin liegt, dass der high-Zustand nur passiv erreicht wird, bietet es sich an den Pull-Up Widerstand zu verkleinern um dadurch die Zeit zu verkürzen die der Bus benötigt den high-Zustand zu

Begrenzt wird dieses Vorhaben dadurch, dass I²C Geräte nur 3mA sinken können (Die weiter unten besprochenen Bustreiber umgehen genau dieses Problem). Bei der Berechnung der Pull-Ups muss also darauf geachtet werden, dass nicht mehr als 3mA durch einen Widerstand fließen. Eine Ausnahme stellen I²C Geräte dar, die der ''Fm+'' (oder höher) Spezifikation entsprechen (Fm+ = Fast mode Plus). Diese sind in der Lage 30mA zu sinken.

=== Geschwindigkeitsreduktion ===

Wenn die Busgeschwindigkeit angepasst wird, sind große Strecken und umfangreiche Verzweigungen möglich. Ein 30-Meter-Bus funktioniert zum Beispiel noch mit rund 20kHz fast ohne Probleme.
Bei Geschwindigkeiten um 1kHz, wurde im Forum schon von Buslängen von etlichen hundert Metern berichtet.

=== Bustreiber ===

Bustreiber haben die Aufgabe die maximale Buskapazität von 400pF zu erhöhen. Dies erreichen die Bausteine i.d.R. durch eine Steigerung des Stroms auf dem Bus.
Die drei bekanntesten Bustreiber für diesen Zweck sind folgende:

* P82B715 (3000pF, max. 100kHz)
* P82B96 (4000pF, max. 400kHz)
* PCA9600 (4000pF, max. 1MHz)

Alle drei Typen haben ihre Vor- und Nachteile. Wobei der PCA9600 als Nachfolger vom P82B96 angesehen werden kann und im Prinzip nur Vorteile gegenüber dem P82B96 hat (Abgesehen vom Preis und der Beschaffbarkeit ;) - [http://www.reichelt.de/PCF-I-C-Bus-Controller/PCA-9600-D/3/index.html?;ACTION=3;LA=446;ARTICLE=126478;GROUPID=2942;artnr=PCA+9600+D '''PCA9600''' Gibts nun bei Reichelt!])

Der Hauptunterschied zwischen P82B96 und PCA9600 sind die Spannungspegel an der Sx/Sy Seite des ICs. Der P82B96 kann diese Pins bei einem low-Signal nicht weiter als 0,88V nach unten ziehen (I²C kompatibel, nicht TTL kompatibel). Der verbesserte PCA9600 kann bis auf 0,74V herunter ziehen (I²C und TTL kompatibel). Des weiteren hat der PCA weniger Laufzeitverzögerung und ist bis zu 1MHz Bustakt spezifiziert.

Der P82B96 (und PCA9600) verhindert eine Rückkopplung indem er an seinen Sx/Sy Eingängen ein low bei 0,65V erkennt, ein low selber aber nur mit 0,88V ausgeben kann. Informationen die über die T/R Seite kommen, werden also von einem zweiten, parallelgeschalteten, Bustreiber des gleichen Typs nicht weitergeleitet. Im Gegensatz zum P82B715 können die ICs verschiedene Busspannungen "übersetzen". Die gepufferte Seite kann also mit einer anderen Busspannung betrieben werden als die Sx/Sy Seite.

P82B96 und PCA9600 können statisch 30mA treiben. In der Application Note AN10216 (Seite 46) wird von NXP geschrieben das mittels externer Transistoren der Strom noch weiter erhöht werden kann. Bei 30kHz wird eine mögliche Gesamtlänge von 1km angegeben.

Recht einfach aufgebaut ist der P82B715. Intern arbeitet nur ein Stromsensor, der auf der gepufferten Seite mittels Transistors den Strom bei low Pegel erhöht. Er hat somit nicht die Probleme mit bestimmten Spannungspegeln wie die P82B96 und PCA9600 ICs. Dafür muss beim P82B715 auch die ungepufferte Seite zur Gesamtbuslast mit einbezogen werden. Auch ist es nicht möglich die gepufferte Seite mit anderer Spannung zu bertreiben.
Auf der gepufferten Seite (LDA/LCL) besitzt der P82B715 nur jeweils einen Pin für jede Busleitung. Applikationen die getrennte TX und RX Pins benötigen, sind mit dem P82B715 also nicht möglich.

=== Differentielle Übertragung ===

In Kombintation mit einem Bustreiber wie dem P82B96, ist es möglich die I²C Bus Signale über RS-485 oder CAN physikalisch zu "tunneln" (PHY Layer).

Dabei werden die TX und RX Leitungen des I²C Bustreibers mit den TX und RX Leitungen des RS-485 oder CAN Treibers verbunden. Für SDA und SCL werden hierfür auf dem Übertragungskabel also insgesamt vier Leitungen benötigt.

NXP hat mit den P82B485/P82B486 auch Treiber angekündigt, die den I²C-Bus direkt auf RS485 übersetzen.

=== Aktiver Pull-Up ===

Linear Technology bietet einige ICs wie den LTC1694 an, der den passiven low-high Wechsel des I²C-Bus durch eine Stromquelle beschleunigt.

== Topologie ==

Über die günstigste Topologie (Stern, Bus,..) ist bisher nichts bekannt.

== Störsicherheit/EMV ==
Bei der Nutzung als Feldbus müssen die Busteilnehmer sowohl gegen Störungen und Überspannung geschützt werden (induktive/kapazitive Einkopplungen), als auch Maßnahmen getroffen werden gegen zu große Störabstrahlung des Busses in die Umwelt. Wesentlich ist dabei die Begrenzung des maximalen Spannungsanstieges dU/dT auf allen Busleitungen und der Schutz vor Spannungsspitzen. Dazu gibt es folgende Möglichkeiten:
* Verwendung abgeschirmter und/oder verdrillter Leitungen mit zentraler Erdung
* Überspannungsschutz bei den Busteilnehmern - durch Schottkydioden zwischen SDA/SCL gegen Masse und VCC unmittelbar an den Slaves und Serienwiderstände in den Datenleitungen in der Anbindung zum Bus (typ. 50 … 200 Ohm)
* Passive Pi-Filter an allen Busteilnehmern, abgestimmt auf die höchste Übertragungsrate
Eine effektive Variante zum Schutz vor Überspannung, Spannungsausfall beim Slave und zugleich Pegelanpassung:

[[Datei:Pegelshifter&EMV.png|600px|Schaltplan]]

= Datensicherheit =

Von Hause aus ist bei I²C keine Checksumme o.ä. vorgesehen. Einzelne Bytes werden nur mit einem ACK bestätigt.

Man muss also eigene Konzepte entwickeln um sicherzugehen, dass Daten korrekt gesendet und empfangen wurden.

Einige Möglichkeiten wären:
* Geschriebene Daten zurücklesen
* Daten immer mehrmals schreiben/lesen
* Wenn man µC als Slave programmiert, kann man eine Checksumme als zusätzliches Byte mitübertragen

Ein weiteres Problem ist, dass Slaves sowohl das SDA Datensignal, als auch das SCL Taktsignal (Clock-Stretching) dauerhaft auf "Low" ziehen können, was den Totalausfall des Busses zur Folge hat. Das kann z.B. beim Ausfall der Stromversorgung eines Slaves auftreten, es sind aber auch Schaltkreise bekannt, die diese Fehlfunktion bei längerem Betrieb zeigen (z.B. LM75). Die Auswirkungen eines lokalen Stromausfalls begrenzt ein klassischer Pegelshifter mit MOSFET, zwischen Bus und Slave geschaltet, bereits zuverlässig. Das Erlauben von Clock-Stretching ist generell ein Problem, da das Bus-Timing und somit die Reaktion des Gesamtsystems in Echtzeit nicht mehr garantiert werden können.

= Adressierung =

Wie viele Adressen einzelne I²C Bausteine haben, ist unterschiedlich. In der Regel sind 1-8 Adressen möglich. Es gibt aber auch (neuere) Bausteine die bis zu 64 mögliche Adressen haben. Somit kann es also sein, das man evt. Probleme bekommt wenn man mehrere Bausteine des selben Typs einsetzen will.

In dieser Hinsicht ist der PCA9501 I/O Expander Baustein recht interessant. Er bietet als einer der wenigen älteren Bausteine bis zu 64 mögliche Adressen. Zudem hat er ein integriertes EEPROM (256 Byte) und ist somit für Hausbus Anwendungen gut geeignet.

Eine andere Lösung dieses Problems ist die Verwendung von I²C Multiplexern- bzw. Switches. Wie z.B. den PCA9544. Dieser Baustein kann einzelne Busabschnitte bei Bedarf abtrennen, so das man in den einzelnen Abschnitten identische Adressen verwenden kann.

= Eigene Erfahrungen =

Vor einigen Jahren war ich als Servicetechniker bei einer Geräteinstallation im Einsatz, bei der die laut Datenblatt möglichen Längen bei weitem überschritten wurden. Ab 12m ging nix mehr. Der Grund war aber nicht der I²C-Bus, sondern die Spannungsversorgung der entfernten Geräte. Die Masseleitung war auch 12m lang, und der Stromverbrauch der Geräte hat den Massepegel soweit angehoben, dass der I²C-Bus nicht mehr funktioniert hat. Mit einer dickeren Masseleitung hat's sofort wieder funktioniert.

Die Kabel sind (bezüglich der gemeinsamen Masse) eine Kette über differentiell kleiner Widerstände parallel geschaltener differentiell kleiner Kondensatoren. Durch einen Pegel-Wechsel müssen all diese kleinen Kondensatoren über die Widerstände umgeladen werden. Folge ist eine deutlich kleinere Ausbreitungs-Geschwindigkeit des Signals und ein geringerer Spannungs-Anstieg an den Anschlüssen der Geräte. Zu der Kapazität der Kabel kommt vor allem noch die Kapazität der Geräte. Im I²C-Standard von Philips ist diese Kapazität auf 400pF limitiert. Im access.bus-Standard (welcher für Computer-Komponenten und Peripherie entwickelt wurde) ist diese Kapazität auf 1000pF beschränkt. Vgl. Ausbreitungsgeschwindigkeiten, Kapazitäten bei anderen Bus-Systemen wie USB, SATA, RS485

----

Habe ein I2C Netzwerk im Haus, sternfoermig und Reihe gemischt,
vielleicht 40m alles zusammen, bei 70kHz mit P82B715 an allen Knoten,
CAT5 Kabel, laeuft einwandfrei. Musst natuerlich Fehlererkennung (NACK)
etc Routinen vorhalten.

----

Habe bei meinem I2C-Hausbus eine Kabellänge
von ca. 120m. Auch sternförmig und reihe gemischt. Taktfrequenz 96kHz,
jedes der 22 Module ist mit einem P82B715 ausgestattet. Den Pull-up
Widerstand von SDA und SCL habe ich auf 180 Ohm verringert. Läuft
fehlerfrei seit ca. 15 Jahren. Verwendetes Kabel für SCL, SDA:
2x0,14mm², geschirmt. Spannungsversorgung +/-15V und Interrupt: 5x1,5².

----

Mein I2C-Hausbus hat ca. 150m Gesamtlänge, Topologie sowohl als Stern, als auch Linien gemischt. Taktfrequenz 3 kHz und weitere Optimierungen. Einheitlicher Bus mit Masse/SDA/SCL und +12V zur Stromversorgung. Läuft seit 2004 weitgehend fehlerfrei. Dokumentation im Netz (Projekt Hauscomputer).

= Passende Sensoren / Module =
* Temperatursensor mit dem [[Temperatursensor#DS1621|DS1621]]
* [[I2C-Schaltmodul]] mit dem [[Port-Expander_PCF8574|PCF8574]]
* [http://cctools.hs-control.de/ext_index.php?artikel=1824 I²C-CAN Modul]
* [http://www.horter.de/i2c/index.htm I²C Module]

= Links =

== Allgemein ==
* [http://www.i2c-bus.org/ I²C-Bus Infoseite]
* [https://www.nxp.com/products/interfaces/ic-bus:MC_41735 Übersicht I²C Bausteine von NXP]
* [http://www.hendonsemiconductors.com/bus-buffer.asp Hendon Semiconductors (Viele Application Notes)]

== Foren Beiträge ==

* [http://www.mikrocontroller.net/topic/71426#582586 I2C über 1,2km Kabel mit CAN-Transceiver]
* [http://www.mikrocontroller.net/topic/40880 I2C über 200m Kabel mit P82B96]

== Application Notes ==

* [http://www.nxp.com/documents/application_note/AN10658.pdf AN10658 (Sending I2C-bus signals via long communications)]
* [http://www.nxp.com/documents/application_note/AN460.pdf AN460 (Using the P82B96 for bus interface)]
* [http://www.nxp.com/documents/application_note/AN255.pdf AN255 (I²C / SMBus Repeaters, Hubs and Expanders)]

== Praktische Anwendungen ==

* [http://haus-computer.de Projekt Hauscomputer]
* [https://gkiefer.github.io/home2l Projekt ''The Home2Ls'']

== Siehe auch ==

* [[Hausbus_auf_I2C-_und_ATtiny-Basis:_Home2L_Brownies|Hausbus auf I²C- und ATtiny-Basis]]

[[Kategorie:Projekte]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]