Mikrocontroller.net - Benutzerbeiträge [de]

ARM Cortex Mikrocontroller

2017-06-18T20:15:18Z

Newgeneration: Beschreibung erweitert

Die Firma [[ARM]] stellt selbst keine Prozessoren/Controller her, sondern entwickelt nur sogenannte "IP-Cores", die von Herstellern wie Atmel, Infineon, ST, NXP, TI und vielen anderen lizenziert werden. Diese Hersteller ergänzen den Core um Speicher und Peripherie. Der Vorteil dieses Modells ist, dass dadurch sehr viele Prozessoren mit unterschiedlichster Ausstattung verfügbar sind, die alle mit dem selben Befehlssatz (und damit dem selben Compiler) programmierbar sind.

Allen ARM-Cores gemeinsam ist die 32 Bit RISC-Architektur. Um Speicherplatz zu sparen hat ARM zusätzlich zum ARM-Befehlssatz (32bit-Instruktion) den Thumb-Befehlssatz entwickelt, der bis auf einige Ausnahmen alle Befehle in 16bit codiert[http://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_%28full%29.pdf]. Den Vorteil des gesparten Speichers erkauft sich das Instruction-Set allerdings durch eine etwas langsame Ausführungsgeschwindigkeit. Die Cortex-M Controller können ausschließlich Thumb-Instruktionen ausführen. Die Vorgänger der Cortex-Serie sind die ARM7-Mikrocontroller, die entweder nur den ARM-Befehlssatz kennen oder beide. Thumb-fähige Controller sind erkennbar am '''T''' in der Bezeichnung, z.B. ARM7'''T'''DMI.

Die ARM-Cortex-Mikrocontroller sind aufgrund der vergleichbar einfachen Beschaltung und niedrigem Stromverbrauch eine echte Alternative zu 8-Bit-Controllern wie dem [[AVR]], die auch noch eine höhere Leistungsfähigkeit besitzen.

'''In diesem Artikel geht es primär um die ARM Cortex-M Mikrocontroller, weniger um ARM [[Cortex-A]] Prozessoren, welche in Smartphones, [[Raspberry Pi]] u.ä. eingesetzt werden.'''

Es gibt folgende Varianten des Cortex-M Mikrocontroller-Kerns, aufgeführt vom energieeffizientesten zum leistungsfähigsten (Liste nicht unbedingt aktuell! Am besten immer die Herstellerseiten bemühen).

== Übersicht ==
ARM hat zur Zeit diese Cores im Programm:
{| class="wikitable"
|-
! style="width: 15% | Core !! Beschreibung
|-
| Cortex-M0 || Als günstigste und Energie-effizienteste Variante gibt es den Cortex-M0 Core mit deutlich kleinerem Befehlssatz als z.B. Cortex-M3. Dieser ist der kleinster Prozessor der Serie und tritt in Konkurrenz zu 8-Bit-Controllern
|-
| Cortex-M0+ || Der M0+ ist die optimierte Variante des Cortex-M0 und vollständig kompatibel zu diesem, erweitert ihn aber zum Beispiel mit einem Single-Cycle-I/O-Port und optionalen Features des Cortex-M3, z.B. einer [[MPU]]
|-
| Cortex-M23 || Dieser Core ist der zuletzt erschienene mit ARMv8-M-Befehlssatz und der Trustzone-Erweiterung (z.B. für IoT) und ist vergleichbar mit dem Cortex-M3
|-
| Cortex-M3 || Der erste Cortex-Mikrocontroller und der Allrounder unter den Cortex-Ms. Die Leistung ist etwa mit der seiner Vorgänger, den ARM7TDMI, vergleichbar
|-
| Cortex-M33 || Der Controller ist Vergleichbar mit dem Cortex-M4, hat allerdings den neueren ARMv8-M-Befehlssatz und die Trustzone-Erweiterung (z.B. für IoT) und ist vergleichbar mit dem Cortex-M4
|-
| Cortex-M4 || Ein hochperformanter Cortex-M3 mit [[DSP]]-Erweiterungen und einer optionalen single-precision [[FPU]]
|-
| Cortex-M7 || Der leistungsfähigste Controller der Serie, der viele Features besitzt, die früher nur Anwendungs-Prozessoren hatten, unter anderem eine double-precision-[[FPU]], Instruktions- und Daten-Caches und einer 6-stufigen Pipeline mit Sprung-Vorhersage
|-
|}
Die Liste ist nach Leistungsfähigkeit sortiert. Programme sind binär-kompatibel zu "größeren" Cores, ein für einen Cortex-M0 kompiliertes Programm kann also auch von einem Cortex-M7 ausgeführt werden.

== Hersteller ==
=== ARM Cortex M0 ===
* [http://www.st.com/en/microcontrollers/stm32f0-series.html STM32F0] von [http://www.st.com STMicro], siehe [[STM32|STM32 hier im Wiki]]
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc1100-cortex-m0-plus-m0 LCP1100] und [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc1200-cortex-m0 LPC1200] von [http://www.nxp.com NXP], siehe [[LPC-Mikrocontroller|LPC-Mikrocontroller hier im Wiki]]. Für diese Controller gibt es bereits eine [[Codebase für LPC1xxx|Codebase hier im Wiki]].
* [http://www.infineon.com/XMC1000 XMC1000] von [http://www.infineon.com Infineon], siehe [[XMCxxxx|XMCxxxx hier im Wiki]]
* [http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=5dbf7d7a-b6df-4fe1-91c9-063449500ce7 NuMicro-Controller] von Nuvoton (ex Winbond), laut Datenblatt mit 2.5-5.5V Betriebsspannung!
* [http://www.cypress.com/PSOC4 PSOC4 Familie] von [http://www.cypress.com Cypress]

=== ARM Cortex M0+ ===
* [http://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx EFM32 Zero Gecko] und [http://www.silabs.com/products/mcu/32-bit/efm32-happy-gecko/pages/efm32-happy-gecko.aspx EFM32 Happy Gecko] von [http://www.silabs.com Silicon Labs], siehe [[EFM32|EFM32 hier im Wiki]]
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc800-series-cortex-m0-plus-mcus LPC800] von [http://www.nxp.com NXP]. Für diese Controller gibt es bereits eine [[Codebase für LPC1xxx|Codebase hier im Wiki]].
* [http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=KINETIS_L_SERIES Kinetis L-Serie] und [http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=KINETIS_M_SERIES Kinetis M-Serie] von [http://www.freescale.com/ Freescale]
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/e-series-5v-robust-m0-plus-m4:KINETIS_E_SERIES Kinetis E-Serie] (5V Versorgungsspannung) von [http://www.nxp.com/ NXP (Freescale)]
* [http://www.fujitsu-fm-family.com/products/fm0.html angekündigte FM0+ Familie] von [http://www.fujitsu.com/emea/services/microelectronics Fujitsu]
* [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1817?icmp=ss1817_pron_pr_feb2014 angekündigte M0+ Familie] von [http://st.com STMicroelectronics]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-C.aspx SAM C Familie] von [http://www.atmel.com/default.aspx Atmel] (5V Versorgungsspannung, nicht nur 5V-tolerant)
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-D.aspx SAM D Familie] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.cypress.com/PSOC4 PSOC4 Familie] von [http://www.cypress.com Cypress]

=== ARM Cortex M3 ===
* [http://www.silabs.com/products/mcu/32-bit/efm32-tiny-gecko/pages/efm32-tiny-gecko.aspx EFM32 Tiny Gecko], [http://www.silabs.com/products/mcu/32-bit/efm32-gecko/pages/efm32-gecko.aspx EFM32 Gecko], [http://www.silabs.com/products/mcu/32-bit/efm32-leopard-gecko/pages/efm32-leopard-gecko.aspx EFM32 Leopard Gecko] sowie [http://www.silabs.com/products/mcu/32-bit/efm32-giant-gecko/pages/efm32-giant-gecko.aspx EFM32 Giant Gecko] von [http://www.silabs.com Silicon Labs] , siehe [[EFM32|EFM32 hier im Wiki]]
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus:LPC-ARM-CORTEX-M-MCUS LPC13xx/LPC15xx/LPC17xx/LPC18xx] von NXP oder die inzwischen schon sehr ausführliche, siehe [[LPC1xxx|LPC1xxx hier im Wiki]]. Für diese Controller gibt es bereits eine [[Codebase für LPC1xxx|Codebase]].
* [http://www.ti.com/lsds/ti/microcontroller/tiva_arm_cortex/c_series/tm4c_arm_cortex-m4/overview.page TIVA] von [http://www.ti.com Texas Instruments] (vormals Stellaris, vormals Luminary Micro)
* [http://www.atmel.com/products/microcontrollers/arm/default.aspx SAM3N, SAM3S,SAM3U, SAM3A und SAM3X Serien] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.st.com/internet/mcu/family/141.jsp STM32] Baureihen [http://www.st.com/internet/mcu/subclass/1169.jsp F1]/[http://www.st.com/internet/mcu/subclass/1520.jsp F2]/[http://www.st.com/internet/mcu/subclass/1376.jsp L1]/[http://www.st.com/internet/mcu/subclass/1377.jsp W] von STMicroelectronics , siehe [[STM32|STM32 hier im Wiki]]
* [http://www.toshiba-components.com/microcontroller/TMPM330.html TMPM330] von Toshiba
* [http://www.spansion.com/Products/microcontrollers/32-bit-ARM-Core/fm3/Pages/FM3-family.aspx FM3] von [http://www.spansion.com Spansion] (vormals Fujitsu)
* [http://www.holtek.com.tw/english/products/32bit_flashmcu.htm HT32] von Holtek Semiconductor
* [http://www.cypress.com/PSOC5 PSOC5] von Cypress

=== ARM Cortex M4 ===
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus:KINETIS Kinetis Series] von Freescale (jetzt NXP)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc4300-cortex-m4-m0:MC_1403790133078 LPC43xx] von [http://www.nxp.com/ NXP] (Dual Core: M4F + bis zu 2 Cortex-M0)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc54000-low-power-cortex-m4:MC_1414576688124 LPC54xxx] von [http://www.nxp.com/ NXP] (Dual Core: M4F + bis zu einem Cortex-M0+)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc4000-cortex-m4:MC_1403790399405 LPC4xxx] von [http://www.nxp.com/ NXP]
* [http://www.silabs.com/products/mcu/32-bit/efm32-wonder-gecko/pages/efm32-wonder-gecko.aspx EFM32-Wonder Gecko] von [http://www.silabs.com Silicon Labs], siehe [[EFM32|EFM32 hier im Wiki]]
* [http://www.st.com/internet/mcu/subclass/1605.jsp STM32F3] von [http://www.st.com STMicro], siehe [[STM32|STM32 hier im Wiki]]
* [http://www.st.com/internet/mcu/subclass/1521.jsp?WT.ac=p2_bn_jun12_stm32f4series STM32F4] von [http://www.st.com STMicro], siehe [[STM32|STM32 hier im Wiki]]
* [http://www.ti.com/lsds/ti/microcontroller/tiva_arm_cortex/c_series/tm4c_arm_cortex-m4/overview.page Tiva C Series, TM4C] von [http://www.ti.com Texas Instruments]. Früher nannte Texas Instruments diese Controller ''Stellaris LM4F Series''. 2013 begann TI mit einer große Umbenennung, bei der sogar neue Typenbezeichnung vergeben wurden. So wurde zum Beispiel aus dem LM4F230H5QR der TM4C123GH6PM. Gleichzeitig begann TI die Bezeichnung ''Stellaris'' aus Datenblättern, Software-Bibliotheken und Ähnlichem zu entfernen und durch ''Tiva'' zu ersetzen. Siehe auch [http://www.ti.com/lit/an/spma050a/spma050a.pdf].
* [http://www.infineon.com/XMC4000 XMC4000] von [http://www.infineon.com Infineon], siehe [[XMCxxxx|XMCxxxx hier im Wiki]], [[XMC4500|Artikel zum XMC4500]]
* [http://www.spansion.com/Products/microcontrollers/32-bit-ARM-Core/fm4/Pages/default.aspx FM4] von [http://www.spansion.com Spansion] (vormals Fujitsu)
* [http://www.atmel.com/products/microcontrollers/arm/sam4l.aspx SAML], [http://www.atmel.com/products/microcontrollers/arm/sam4e.aspx SAME], [http://www.atmel.com/products/microcontrollers/arm/sam4n.aspx SAMN] und [http://www.atmel.com/products/microcontrollers/arm/sam4s.aspx SAMS] von [http://www.atmel.com/default.aspx Atmel]

=== ARM Cortex M7 ===
Die neueste Variante der Cortex M-Reihe ist der M7, bei dem gegenüber dem M4 zahlreiche Features hinzukommen die die Brücke zu Anwendungsprozessoren schlagen: eine double precision-FPU, Code- und Daten-Cache, eine 6-stufige Pipeline mit Sprungvorhersage, und unterm Strich eine deutlich höhere Rechenleistung. Controller basierend auf dem Cortex M7 sind u.a. von Atmel, NXP und ST erhältlich.

* [http://www.atmel.com/products/microcontrollers/ARM/SAM-E.aspx SAME] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-S.aspx SAMS] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-V.aspx SAMV] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/sam7s_se.aspx SAM7S/SE] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/sam7x_xc.aspx SAM7X/XC] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.st.com/web/en/catalog/mmc/SC1169/SS1858 Produktseite der STM32F7-Serie von ST]

=== ARM7TDMI ===
Der Vorgänger der Cortex-M-Cores ist der '''ARM7'''TDMI. Controllerfamilien dieser Klasse sind immer noch weit verbreitet:
* [[LPC2000]] von NXP
* [[AT91SAM]] von Atmel
* [[ADuC7xxx]] von Analog Devices
* [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=203&familyId=454 Texas Instruments TMS470]
* S3C24x0 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2410] von SAMSUNG
* STR7xx von ST Microelectronics [http://www.st.com/mcu/inchtml-pages-str7.html]
* und viele weitere

Mehr Informationen zur ARM-Architektur finden sich in der [http://de.wikipedia.org/wiki/ARM-Architektur Wikipedia], weiterführende Links in der [[Linksammlung#ARM|Linksammlung]].

== Compiler & Software ==
=== [[ARM_GCC|GCC]] ===
Einer der beliebtesten Compiler für ARM-Prozessoren ist der GCC. Er kann sowohl ARM- als auch Thumb-Code erzeugen. Mehr dazu unter [[ARM GCC]].

=== C/C++ IDEs ===
Kostenlose Entwicklungsumgebungen (überwiegend GCC-basiert):
* [http://www.coocox.org/software.html CooCox IDE] (Eclipse basierend)
* [https://gnuarmeclipse.github.io GNU ARM Eclipse] (Eclipse Plugin)
* [http://www.emblocks.org/web/ EmBlocks IDE] (Basiert auf Code::Blocks)
** Compiler: GNU ARM-GCC (in der Installation enthalten), RealView und IAR
** Hardware: STlink (mit "Live data"), openOCD, Jlink.
** Project Import: CoIDE, uVision, Atmel studio, MplabX, Mplab 8
** OS aware debugging
***FreeRTOS
***ChibiOS/RT
** Unterstützt sehr viele Controller(-Hersteller):
***Atmel-ARM
***NXP-ARM
***STMicro-ARM
***EnergyMicro-ARM
**Keine Beschränkungen
**Hier gehts zum ''[http://www.emblocks.org/web/downloads-main Download]'''
* [http://www.emide.org/ emIDE] Windows, komplette Visual Studio artige Entwicklungsumgebung (basierend auf Code::Blocks) mit GCC und Debugger (Unterstützung für Adapter von Segger) 
* [https://mbed.org mbed]: eine kostenlose Online-Entwicklungsumgebung basierend auf dem ARM Realview-Compiler, mit einer umfangreichen C++-Bibliothek für die Controllerfunktionen, integrierter Versionsverwaltung, und vielen Beispielprogrammen. Projekte lassen sich für Keil/IAR/GCC exportieren und offline weiterbearbeiten; die Bibliotheksfunktionen sind Open Source und auch kommerziell einsetzbar.
* [http://www.isystem.com/products/software/winidea-open winIDEAOpen]Die Fa. iSystem stellt mit der winIDEAOpen nun eine kostenlose Entwicklungsumgebung für alle Cortex-M Bauteile zur Verfügung. Als Compiler wird der GNU GCC verwendet und auch gleich mitinstalliert. Die IDE ist recht intuitiv und mit einer umfangreichen Hilfe ausgestattet. Das Ganze funktioniert mit dem GCC ohne Codesize Limit und auch ein Testwerkzeug (testIDEA) ist mit integriert. Hardwareseitig werden neben dem iSystem iTag50 [http://www.isystem.com/products/hardware/cortex-debugger/itag] auch die Segger J-Link Debug Probes sowie der ST-Link von ST unterstützt. Auf der Webseite von iSystem sind auch einige schöne Beispielprojekte für diverse Boards zu finden [http://www.isystem.com/download/winideaopen]. Demnächst soll noch die Unterstützung für die ARM und IAR Compiler hinzuzkommen. Hier gehts zum ''[http://www.isystem.com/download/winideaopen Download]'''
* '''Infineon''' bietet für seine '''XMC''' Prozessorfamilien auch eine kostenlose, professionell gepflegte C/C++ Entwicklungsumgebung an, ohne Einschränkungen auf bestimmte Typen oder Speichergrößen - alle erhältlichen XMC 1000er und 4000er Prozessoren werden unterstützt. Wenn man sich dazu noch eines der günstigen XMC Evaluierungsboards besorgt (XMC 1100 Bootkit, XMC 4500 Relax (lite) Kit o.ä.), hat man ein erstes Entwicklungssystem inklusive wiederverwendbaren HW-Debugger zur Verfügung. Die Entwicklungsumgebung basiert auf Eclipse, besitzt aber zahlreiche Erweiterungen samt Codegenerierung (sogenannte Apps), die gerade am Anfang viele Dinge abnehmen kann, da man die Peripherals damit einfach grafisch konfigurieren kann. Das ist bei Prozessoren, dessen User Manual einige hundert Seiten ausmacht (oder auch für Umsteiger von 8bitter oder anderen 32bittern), nicht unwichtig. Der generierte Code ist template-basiert, gut lesbar und kann später - wenn man mehr Erfahrung hat, für eigene Entwicklungen weiter nutzen und optimieren. Damit verliert man dann allerdings die Möglichkeit, Updates der generierten Codes aus den Apps zu bekommen, die Infineon ebenfalls kostenfrei zur Verfügung stellt. Die Software nennt sich ''Digital Application Virtual Engineer'' ([http://www.infineon.com/dave DAVE]) und kann nach Registrierung kostenlos für Windows heruntergeladen werden. Innerhalb von Dave kann man dann Apps und viele Beispiele (ohne weitere Anmeldung und Kosten) komplett oder selektiv (für bestimmte Prozessoren) herunterladen. Die aktuell stabile Version ist v3. Es ist eine neue DAVE Umgebung v4 in Arbeit, eine Betaversion kann heruntergeladen werden. Diese neue v4 Variante wird auch ein separates SDK besitzen, um Apps für Dave selbst schreiben zu können (z.B. Bauteilhersteller, die die Anbindung an den XMC für Kunden vereinfachen wollen). Einsteiger sollten aber mit v3 beginnen, um nicht über Bugs der Beta v4 zu stolpern (siehe auch im [http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum]).
* '''NXP''' bietet für seine '''LPC''' Prozessorfamilien eine kostenlose C/C++ Entwicklungsumgebung an. Die auf Eclipse basierende Entwicklungsumgebung ([http://www.lpcware.com/lpcxpresso LPCXpresso]) ist nach der Installation bis 8kB freigeschaltet und nach einer einfachen und kostenlosen Registrierung für 256kB. [http://www.lpcware.com/lpcxpresso LPCXpresso] steht für Windows, Linux und Mac zur Verfügung.
* '''ST''' bietet für seine '''STM32''' Prozessorfamilie eine kostenlose C/C++ Entwicklungsumgebung an. Die auf Eclipse basierende Entwicklungsumgebung kann nach Registrierung auf der Homepage heruntergeladen werden. [http://www.openstm32.org/]

Kommerzielle Entwicklungsumgebungen (zum Teil kostenlos mit Einschränkungen) für ARM-basierte Mikrocontroller sind z. B.:
* [http://timor.atollic.com/truestudio/ Atollic TrueStudio] (Windows), Eclipse-basierend inkl. Compiler und Linker für fast alle ARMs, jetzt auch kostenlos mit vielen Beispielen und ohne Codesize-Limitierung, dafür mit anderen Einschränkungen
* [http://www.cosmicsoftware.com/download_cortex_64k.php Cosmic Software] (Windows), bis 64kB kostenlos
* [http://rowley.co.uk/arm/ Crossworks ARM] (inkl. Toolchains basierend auf GCC und Clang, für Windows, Mac OS und Linux)
* [http://www.iar.com/ewarm/ IAR Embedded Workbench for ARM] (Windows)
* [http://www.keil.com/arm/ MDK-ARM von Keil/ARM] (Windows), Lite-Version bis 32kB kostenlos,
* [http://www2.keil.com/stmicroelectronics-stm32/mdk MDK-STM32 von KEIL] Speziell für STM32x0 kostenlos ohne Beschränkung
* [http://www.sisy.de/ SiSy MC++] (Windows), Demo-Version, keine Code-Begrenzung

=== Compiler für sonstige Programmiersprachen ===
* Basic: http://www.mikroe.com/mikrobasic/arm/
* Pascal: http://www.mikroe.com/mikropascal/arm/

=== Interpreter ===
* Forth: https://github.com/ekoeppen/CoreForth
* JavaScript: http://www.espruino.com/
* Lua: http://www.eluaproject.net/

=== ARM/XSCALE/CORTEX Instruction Set Simulator ===
Die Firma Lauterbach bietet unter der Artikelnummer LA-8809 einen Instruction Set Simulator für ARM Cores an. Die Demoversion ist zur Evaluierung kostenlos. Einschränkungen bestehen in der Anzahl der zu ladenden Debugsymbole. Der Simulator unterstützt alle gängigen ARM Derivate und lädt alle üblichen Debugformate, wie die des RealView, IAR und TI Compilers, oder der freien GCC Tools. Zum Simulator gibt es entsprechende zugehörige Debugtools, die allerdings käuflich zu erwerben sind.

* [http://www.lauterbach.com/frames.html?dwnload.html Download ARM/XSCALE/CORTEX Simulator]

== Debug- und Programmierschnittstellen (JTAG/SWD) ==

Alle ARM-basierten Prozessoren verwenden ein einheitliches [[JTAG]]-Interface, über das Debugging und Speicherzugriff erfolgen kann. Nicht standardisiert sind allerdings die Verfahren zum Beschreiben des Flash-ROMs. Deshalb muss man beachten, ob die verwendete JTAG-Software Programmierroutinen für den jeweiligen Controller besitzt.

SWD (Serial Wire Debug) ist eine neue mit den Cortex-Mikrocontrollern eingeführte Debug- und Programmierschnittstelle, die weniger Pins benötigt als JTAG. Hier wird Debug-Bandbreite bzw. Speed gegen mehr verfügbare Pins für in-circuit Debugging "getauscht". Die meisten Controller der Cortex-M0 & M3 Serie können sowohl mittels JTAG als auch mittels SWD programmiert werden, es gibt allerdings auch Exemplare (z.B. [[EFM32]] von [https://www.silabs.com Silicon Labs], XMC1100 von [http://www.infineon.com/xmc Infineon]) welche nur SWD unterstützen.

Eine Übersicht über die empfohlenen Steckerbelegungen für JTAG und SWD gibt ein [http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf Dokument von ARM].

Darüber hinaus gibt es noch herstellerspezifische Schnittstellen wie SPD (Single Pin Debug) von Infineon, oder vorinstallierte serielle Bootloader, z.B. beim [[STM32]] oder auch bei den [[Infineon XMC]], die dann z.B. über ein eigenes [http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/c166/xc166-development-tools-software-and-kits/software-downloads/channel.html?channel=ff80808112ab681d0112ab6b50fe07c9 Tool] ohne weitere Hardware - abgesehen von einem handelsüblichen seriellen Schnittstellenadapter - programmiert werden können.

Viele Entwicklungsboards enthalten auch einen On-Board-Debugadapter zum direkten Anschluss an USB, so dass kein externer SWD- oder JTAG-Adapter notwendig ist. Manche erlauben auch, diesen Adapter abzubrechen und für eigene Entwicklungen weiterzuverwenden, somit ist nach dem Kauf eines Eval-Kits nicht nötig, einen weiteren Adapter später nachzukaufen.

=== Günstige Beispiele zum Einstieg ===
Ein einfacher JTAG-Adapter für den Parallelport ist der "Wiggler"-kompatible, den man auch einfach selbst bauen kann. Als Software lässt sich unter Windows und Linux [http://openocd.berlios.de/ OpenOCD] (zusammen mit [[GDB]]) oder [http://rowley.co.uk Crossworks ARM] verwenden. Für USB gibt es ebenfalls OpenOCD-kompatible JTAG-Adapter.

Von NXP sind preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG-/-SWD-Programer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits]''' (PDF), oder diese '''[http://www.mikrocontroller.net/wikisoftware/index.php?title=LPC1xxx_Entwicklungskit_LPCXpresso Beschreibung]'''.

Von ST gibt es günstige MBED/Arduino kompatible Nucleo Entwicklungskits (ca. 12€) z.B. '''[http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260320?s_searchtype=partnumber]'''. Der integrierte ST-Link Debugger kann mittels SWD und OpenOCD als Software auch andere Chip programmieren. Die etwas teuereren Discoveryboards, z.B. '''[http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1848/PF260946?s_searchtype=partnumber]''', haben mehr externe Bauteile on-board, während die Nucleo Board über Shields erweiterbar sind. Nur bei Nucleo Boards ist eine UART Schnittstelle als Standard über USB zu erreichen, bei Discovery Boards mit ST-Link V2-1 müssen Lötbrücken gesetzt werden.

Auch Infineon bietet Arduino-kompatible Boards+Shields mit dem XMC1100 Prozessor und angeflanschtem Debugger an (ab ca. 16€). Weiters gibt es günstige XMC4500 Kits, die auch Ethernet, SPI-Flash und SDCard-Slot Optionen bieten. Am unteren Ende gibt es ein XMC1100 Kit samt Debugger ab ca. 5€, dieses Board für den Schlüsselbund sozusagen nennt sich treffend "XMC 2 Go". Die Preise können je nach Distributor stark variieren.
Siehe auch hier '''[http://www.infineon.com/cms/de/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-registered-cortex-registered-m/xmc-development-tools-kits-and-boards/channel.html?channel=db3a30433580b3710135a07902883872 XMC-Starter-Kits]'''.
Des weiteren werden auch schon Kits in Verbindung mit Sensoren zum Evaluieren angeboten, wie das "3D 2 Go" Board mit einem XMC1100 Prozessor und dem neuen 3D-Magnetfeldsensor von Infineon, um ein Beispiel zu nennen: '''[http://www.infineon.com/cms/en/product/sensor-ics/magnetic-sensors/3d-magnetic-sensor/channel.html?channel=5546d4624c9e0f0e014c9e105a8a001c 3D-Sensorkit]'''.

Von Silicon Labs gibt es [https://www.silabs.com/products/mcu/Pages/32-bit-microcontroller-tools.aspx Starter Kits] mit integriertem J-Link (Debugger) ab ca. 25 € z.B. das [https://www.silabs.com/products/mcu/lowpower/Pages/efm32tg-stk3300.aspx EFM32 Tiny Gecko Starter Kit] bei [http://www.mouser.de/ProductDetail/Silicon-Laboratories/EFM32TG-STK3300/?qs=%2fha2pyFadujBGJvO8YBq9JikBLXQGi%2fjwmF17imXuts5383tWpQKFA%3d%3d Mouser]

Der [http://www.segger.com/cms/jlink.html J-Link]-"Emulator" von Segger wird von vielen Softwarepaketen unterstützt und ist für den "nicht-kommerziellen" Einsatz von Studenten, Funkamateuren und Hobby-Bastler für ca. €50.- erhältlich (J-Link-Edu). Sein Umfang ist auf das Flashen des Speichers und das Debuggen beschränkt. Bonus: Neben den im Prozessor limitiert vorhandenen Hardware-Breakpoints (Anzahl ist MCU abhängig) sind zusätzliche Flash-Breakpoints möglich (müssen aber von der verwendeten Debug-IDE unterstüzt werden). Die sehr gut geplegte Debugger-Software unterstützt nahezu alle ARM Prozessoren. Die Trace-Option wie sie bei der PRO-Variante zur Verfügung steht, ist nicht vorhanden. Für den Preis bekommt man jedoch ein ausgewachsenes Werkzeug mit breiter Unterstützung und der Möglichkeit sowohl SWD als auch JTAG in einem Gerät vereint zu haben. Wenn man aber plant, ein oben genanntes Kit von ST, NXP, Infineon oder ähnlich zu kaufen kann man für ähnliche Kosten auch gleich ein CPU-Board dazubekommen - daher ist es sinnvoll, sich die Dokumentationen der Evalkits voher genau durchzusehen.

Der ULINK2 von Keil/ARM ist ebenfalls ein wirklich gutes Gerät. Leider ist er nicht ganz so günstig und seine Zusammenarbeit beschränkt sich auf die Arm/Keil IDE µVision. Er benötigt jedoch keine speziellen USB-Treiber sondern nutzt geschickt die Funktionalität der HID-Treiber des Betriebssystems. Das macht ihn sofort auf jedem Windows-Betriebssystem einsatzbereit.

Als Alternative zum Beschreiben des Flash über JTAG ist oft ein serieller [[Bootloader]] im Controller enthalten. Bei ST werden sie über einen speziellen Pin der MPU aktiviert und sind dank Kompression und das intelligente entfernen redundanter Information, bei der Übertragung genauso schnell wie JTAG/SWD Adapter.

== CMSIS - ARM Cortex Software Libraries ==
Der ARM Cortex Microcontroller Software Interface Standard (CMSIS) ist ein herstellerunabhängiger Hardware Abstraction Layer für die Cortex-M-Prozessor -Serie. Dieser ermöglicht konsistente und einfache Software-Schnittstellen für den Prozessor und die Peripherie, und vereinfacht damit die Software-Wiederverwendung.

CMSIS besteht aus folgenden Komponenten:

* CMSIS-CORE: Bietet eine Schnittstelle zum Cortex-M0, Cortex-M3, Cortex-M4, SC000 und SC300-Prozessorkern und Peripherie-Registern.
* CMSIS-DSP: DSP-Bibliothek mit über 60 Funktionen in Festkomma-(fractional q7, q15, q31) und single precision floating-point (32-bit)-Implementierung
* CMSIS-RTOS API: Standardisierte Programmierschnittstelle für Echtzeit-Betriebssysteme für Thread-Steuerung, Ressourcen-und Zeitmanagement. Implementierungen gibt es z.B. von Keil ([http://www.keil.com/pack/doc/cmsis_rtx/index.html RTX])
* CMSIS-SVD: System View Beschreibung - XML-Dateien, die die Programmiereransicht des kompletten Mikrocontroller-Systems einschließlich Peripheriegeräte enthalten

Der Standard ist für Cortex-M-Mikrocontroller skalierbar: Von der kleinsten 4 KB MCU bis zu MCUs mit anspruchsvoller Kommunikations-Peripherie wie Ethernet oder USB. Die "Core Peripheral Funktionen" benötigt beispielsweise weniger als 1 KB-Code und weniger als 10 Bytes RAM.

Beispiele:
* Software Beispiele von [http://www.energymicro.com/downloads/application-notes Energy Micro] basierend auf CMSIS

Mehr Informationen auf der [http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php ARM CMSIS Webseite].

== Siehe auch ==
* [[Linksammlung#ARM|Linksammlung (Abschnitt ARM)]]
* [[LPC1xxx]]
* [[LPC1xxx_Entwicklungskit_LPCXpresso]]
* [[Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red]]
* [[Codebase_f%C3%BCr_LPC1xxx]]
* [[ARM-elf-GCC-Tutorial]]
* [[AVR32]]
* [[Blackfin]]
* [[AT91SAM9260]]
* [[STM32]]
* [[JTAG]]
* [http://www.mikrocontroller.net/articles/EFM32 EFM32]
* [http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks STM32 - Einstieg mit Em::Blocks Tutorial]

== Weblinks ==
* [http://www.mySTM32.de Online Tutorial für den STM32]
* [http://www.myXMC.de Online Tutorial für den XMC von Infineon]
* [http://www.myUGL.de Online Tutorial für freie Grafikbibliothek, STM32, STM32F429, TFT, Touch]
* [http://embdev.net/forum/arm-gcc ARM-GCC Forum] im englischsprachigen "Ableger" von mikrocontroller.net embdev.net u.a. für WinARM, Yagarto, CS Codebench
* [http://www.arm.com/products/processors/cortex-m/index.php Cortex-M Produktseite von ARM]
* [http://infocenter.arm.com/help/index.jsp Infocenter von ARM Ltd.]
* [http://www.open-research.org.uk/ARMuC/ ARMuC ARM microcontroller Wiki]
* [http://chaosradio.ccc.de/cre151.html Chaosradio Express - Die ARM-Architektur]

== Literatur ==
* ARM Systems Developer's Guide (2004) ISBN 1558608745 [http://books.google.de/books?id=HKKUkDQE17QC&output=html Im Buch blättern] [http://booksite.elsevier.com/9781558608740/ Programmbeispiele aus dem Buch, u.a. FFT, FIR/IIR-Filter, Division, Wurzel]
* ARM Assembly Language - an Introduction (2007) ISBN 1847536964 [http://books.google.de/books?id=8KJX5R8mMvsC&output=html Im Buch blättern] [http://www.lulu.com/content/1172076 Verlagsseite "Book on demand"]
* ARM Rechnerarchitekturen für System-on-Chip-Design (2002) ISBN 3826608542
* Co-Verification of Hardware and Software for Arm Soc Design (2004) ISBN 0750677309
* ARM System-on-Chip Architecture (2000) ISBN 0201675196 [http://books.google.de/books?id=J_Fu_YTVD9gC&printsec=frontcover&output=html&source=gbs_summary_r&cad=0 Im Buch blättern]
* ARM Architecture Reference Manual ISBN 0201737191 [http://books.google.de/books?id=O5G-6WX1xWsC&printsec=frontcover&output=html&source=gbs_summary_r&cad=0 Im Buch blättern]
* Messen, Steuern und Regeln mit ARM-Mikrocontrollern ISBN 3772340172 [http://books.google.de/books?id=TKs4kN-zNYQC&output=html im Buch blättern]
* Programming Arm Microcontrollers: Using C and the Lpc2100 Family (2005? /ab 1. Dezember 2008) ISBN 0321263359
* Arm Assembly: Fundamentals and Techniques (ab 1. März 2009) ISBN 1439806101
* Reliable Embedded Systems: Using 8051 and ARM Microcontrollers (2007) ISBN 0321252918 600 Seiten mit CD [http://vig.pearsoned.co.uk/catalog/academic/product/0,1144,0321252918-TOC,00.html Inhaltsverzeichnis]
* C und C++ für Embedded Systems (u.a. ARM Cortex-M3) mitp-Verlag 2008 ISBN 382665949X
* The Definitive Guide to the Arm Cortex-M0 (Joseph Yiu) Newnes Verlag ISBN 0123854776
* The Definitive Guide to the Arm Cortex-M3 (Joseph Yiu) Newnes Verlag ISBN 185617963X

[[Category:ARM| ]]

ARM Cortex Mikrocontroller

2017-06-16T19:24:09Z

Newgeneration: Aktualisierung des Artikels

Die Firma [[ARM]] stellt selbst keine Prozessoren/Controller her, sondern entwickelt nur sogenannte "IP-Cores", die von Herstellern wie Atmel, Infineon, ST, NXP, TI und vielen anderen lizenziert werden. Diese Hersteller ergänzen den Core um Speicher und Peripherie. Der Vorteil dieses Modells ist, dass dadurch sehr viele Prozessoren mit unterschiedlichster Ausstattung verfügbar sind, die alle mit dem selben Befehlssatz (und damit dem selben Compiler) programmierbar sind.

Allen ARM-Cores gemeinsam ist die 32 Bit RISC-Architektur. Um Speicherplatz zu sparen hat ARM zusätzlich zum ARM-Befehlssatz (32bit-Instruktion) den Thumb-Befehlssatz entwickelt, der bis auf einige Ausnahmen alle Befehle in 16bit codiert[http://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_%28full%29.pdf]. Den Vorteil des gesparten Speichers erkauft sich das Instruction-Set allerdings durch eine etwas langsame Ausführungsgeschwindigkeit. Die Cortex-M Controller können ausschließlich Thumb-Instruktionen ausführen. Die Vorgänger der Cortex-Serie sind die ARM7-Mikrocontroller, die entweder nur den ARM-Befehlssatz kennen oder beide. Thumb-fähige Controller sind erkennbar am '''T''' in der Bezeichnung, z.B. ARM7'''T'''DMI.

Die ARM-Cortex-Mikrocontroller sind aufgrund der vergleichbar einfachen Beschaltung und niedrigem Stromverbrauch eine echte Alternative zu 8-Bit-Controllern wie dem [[AVR]], die auch noch eine höhere Leistungsfähigkeit besitzen.

'''In diesem Artikel geht es primär um die ARM Cortex-M Mikrocontroller, weniger um ARM [[Cortex-A]] Prozessoren, welche in Smartphones, [[Raspberry Pi]] u.ä. eingesetzt werden.'''

Es gibt folgende Varianten des Cortex-M Mikrocontroller-Kerns, aufgeführt vom energieeffizientesten zum leistungsfähigsten (Liste nicht unbedingt aktuell! Am besten immer die Herstellerseiten bemühen).

== Übersicht ==
ARM hat zur Zeit diese Cores im Programm:
{| class="wikitable"
|-
! style="width: 15% | Core !! Beschreibung
|-
| Cortex-M0 || Kleinster Prozessor der Serie als Konkurrent zu dem 8-Bit-Controllern und geringem Stromverbrauch
|-
| Cortex-M0+ || Der M0+ ist vollständig kompatibel zum M0, erweitert ihn aber zum Beispiel mit einem Single-Cycle-I/O-Port und optionalen Features des Cortex-M3
|-
| Cortex-M23 || Dieser Core ist der zuletzt erschienene mit ARMv8-M-Befehlssatz und der Trustzone-Erweiterung
|-
| Cortex-M3 || Der erste Cortex-Mikrocontroller und der Allrounder unter den Cortex-Ms. Die Leistung ist etwa mit der der ARM7TDMI vergleichbar
|-
| Cortex-M33 || Der Controller ist Vergleichbar mit dem Cortex-M4, hat allerdings den neueren ARMv8-M-Befehlssatz und die Trustzone-Erweiterung
|-
| Cortex-M4 || Ein hochperformanter Cortex-M3 mit [[DSP]]-Erweiterungen und einer optionalen [[FPU]]
|-
| Cortex-M7 || Der leistungsfähigste Controller der Serie, der viele Features besitzt, die früher nur Anwendungs-Prozessoren hatten
|-
|}

== Hersteller ==
=== ARM Cortex M0 ===
* [http://www.st.com/en/microcontrollers/stm32f0-series.html STM32F0] von [http://www.st.com STMicro], siehe [[STM32|STM32 hier im Wiki]]
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc1100-cortex-m0-plus-m0 LCP1100] und [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc1200-cortex-m0 LPC1200] von [http://www.nxp.com NXP], siehe [[LPC-Mikrocontroller|LPC-Mikrocontroller hier im Wiki]]. Für diese Controller gibt es bereits eine [[Codebase für LPC1xxx|Codebase hier im Wiki]].
* [http://www.infineon.com/XMC1000 XMC1000] von [http://www.infineon.com Infineon], siehe [[XMCxxxx|XMCxxxx hier im Wiki]]
* [http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=5dbf7d7a-b6df-4fe1-91c9-063449500ce7 NuMicro-Controller] von Nuvoton (ex Winbond), laut Datenblatt mit 2.5-5.5V Betriebsspannung!
* [http://www.cypress.com/PSOC4 PSOC4 Familie] von [http://www.cypress.com Cypress]

=== ARM Cortex M0+ ===
* [http://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx EFM32 Zero Gecko] und [http://www.silabs.com/products/mcu/32-bit/efm32-happy-gecko/pages/efm32-happy-gecko.aspx EFM32 Happy Gecko] von [http://www.silabs.com Silicon Labs], siehe [[EFM32|EFM32 hier im Wiki]]
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc800-series-cortex-m0-plus-mcus LPC800] von [http://www.nxp.com NXP]. Für diese Controller gibt es bereits eine [[Codebase für LPC1xxx|Codebase hier im Wiki]].
* [http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=KINETIS_L_SERIES Kinetis L-Serie] und [http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=KINETIS_M_SERIES Kinetis M-Serie] von [http://www.freescale.com/ Freescale]
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/e-series-5v-robust-m0-plus-m4:KINETIS_E_SERIES Kinetis E-Serie] (5V Versorgungsspannung) von [http://www.nxp.com/ NXP (Freescale)]
* [http://www.fujitsu-fm-family.com/products/fm0.html angekündigte FM0+ Familie] von [http://www.fujitsu.com/emea/services/microelectronics Fujitsu]
* [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1817?icmp=ss1817_pron_pr_feb2014 angekündigte M0+ Familie] von [http://st.com STMicroelectronics]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-C.aspx SAM C Familie] von [http://www.atmel.com/default.aspx Atmel] (5V Versorgungsspannung, nicht nur 5V-tolerant)
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-D.aspx SAM D Familie] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.cypress.com/PSOC4 PSOC4 Familie] von [http://www.cypress.com Cypress]

=== ARM Cortex M3 ===
* [http://www.silabs.com/products/mcu/32-bit/efm32-tiny-gecko/pages/efm32-tiny-gecko.aspx EFM32 Tiny Gecko], [http://www.silabs.com/products/mcu/32-bit/efm32-gecko/pages/efm32-gecko.aspx EFM32 Gecko], [http://www.silabs.com/products/mcu/32-bit/efm32-leopard-gecko/pages/efm32-leopard-gecko.aspx EFM32 Leopard Gecko] sowie [http://www.silabs.com/products/mcu/32-bit/efm32-giant-gecko/pages/efm32-giant-gecko.aspx EFM32 Giant Gecko] von [http://www.silabs.com Silicon Labs] , siehe [[EFM32|EFM32 hier im Wiki]]
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus:LPC-ARM-CORTEX-M-MCUS LPC13xx/LPC15xx/LPC17xx/LPC18xx] von NXP oder die inzwischen schon sehr ausführliche, siehe [[LPC1xxx|LPC1xxx hier im Wiki]]. Für diese Controller gibt es bereits eine [[Codebase für LPC1xxx|Codebase]].
* [http://www.ti.com/lsds/ti/microcontroller/tiva_arm_cortex/c_series/tm4c_arm_cortex-m4/overview.page TIVA] von [http://www.ti.com Texas Instruments] (vormals Stellaris, vormals Luminary Micro)
* [http://www.atmel.com/products/microcontrollers/arm/default.aspx SAM3N, SAM3S,SAM3U, SAM3A und SAM3X Serien] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.st.com/internet/mcu/family/141.jsp STM32] Baureihen [http://www.st.com/internet/mcu/subclass/1169.jsp F1]/[http://www.st.com/internet/mcu/subclass/1520.jsp F2]/[http://www.st.com/internet/mcu/subclass/1376.jsp L1]/[http://www.st.com/internet/mcu/subclass/1377.jsp W] von STMicroelectronics , siehe [[STM32|STM32 hier im Wiki]]
* [http://www.toshiba-components.com/microcontroller/TMPM330.html TMPM330] von Toshiba
* [http://www.spansion.com/Products/microcontrollers/32-bit-ARM-Core/fm3/Pages/FM3-family.aspx FM3] von [http://www.spansion.com Spansion] (vormals Fujitsu)
* [http://www.holtek.com.tw/english/products/32bit_flashmcu.htm HT32] von Holtek Semiconductor
* [http://www.cypress.com/PSOC5 PSOC5] von Cypress

=== ARM Cortex M4 ===
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus:KINETIS Kinetis Series] von Freescale (jetzt NXP)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc4300-cortex-m4-m0:MC_1403790133078 LPC43xx] von [http://www.nxp.com/ NXP] (Dual Core: M4F + bis zu 2 Cortex-M0)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc54000-low-power-cortex-m4:MC_1414576688124 LPC54xxx] von [http://www.nxp.com/ NXP] (Dual Core: M4F + bis zu einem Cortex-M0+)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc4000-cortex-m4:MC_1403790399405 LPC4xxx] von [http://www.nxp.com/ NXP]
* [http://www.silabs.com/products/mcu/32-bit/efm32-wonder-gecko/pages/efm32-wonder-gecko.aspx EFM32-Wonder Gecko] von [http://www.silabs.com Silicon Labs], siehe [[EFM32|EFM32 hier im Wiki]]
* [http://www.st.com/internet/mcu/subclass/1605.jsp STM32F3] von [http://www.st.com STMicro], siehe [[STM32|STM32 hier im Wiki]]
* [http://www.st.com/internet/mcu/subclass/1521.jsp?WT.ac=p2_bn_jun12_stm32f4series STM32F4] von [http://www.st.com STMicro], siehe [[STM32|STM32 hier im Wiki]]
* [http://www.ti.com/lsds/ti/microcontroller/tiva_arm_cortex/c_series/tm4c_arm_cortex-m4/overview.page Tiva C Series, TM4C] von [http://www.ti.com Texas Instruments]. Früher nannte Texas Instruments diese Controller ''Stellaris LM4F Series''. 2013 begann TI mit einer große Umbenennung, bei der sogar neue Typenbezeichnung vergeben wurden. So wurde zum Beispiel aus dem LM4F230H5QR der TM4C123GH6PM. Gleichzeitig begann TI die Bezeichnung ''Stellaris'' aus Datenblättern, Software-Bibliotheken und Ähnlichem zu entfernen und durch ''Tiva'' zu ersetzen. Siehe auch [http://www.ti.com/lit/an/spma050a/spma050a.pdf].
* [http://www.infineon.com/XMC4000 XMC4000] von [http://www.infineon.com Infineon], siehe [[XMCxxxx|XMCxxxx hier im Wiki]], [[XMC4500|Artikel zum XMC4500]]
* [http://www.spansion.com/Products/microcontrollers/32-bit-ARM-Core/fm4/Pages/default.aspx FM4] von [http://www.spansion.com Spansion] (vormals Fujitsu)
* [http://www.atmel.com/products/microcontrollers/arm/sam4l.aspx SAML], [http://www.atmel.com/products/microcontrollers/arm/sam4e.aspx SAME], [http://www.atmel.com/products/microcontrollers/arm/sam4n.aspx SAMN] und [http://www.atmel.com/products/microcontrollers/arm/sam4s.aspx SAMS] von [http://www.atmel.com/default.aspx Atmel]

=== ARM Cortex M7 ===
Die neueste Variante der Cortex M-Reihe ist der M7, bei dem gegenüber dem M4 zahlreiche Features hinzukommen die die Brücke zu Anwendungsprozessoren schlagen: eine double precision-FPU, Code- und Daten-Cache, eine 6-stufige Pipeline mit Sprungvorhersage, und unterm Strich eine deutlich höhere Rechenleistung. Controller basierend auf dem Cortex M7 sind u.a. von Atmel, NXP und ST erhältlich.

* [http://www.atmel.com/products/microcontrollers/ARM/SAM-E.aspx SAME] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-S.aspx SAMS] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-V.aspx SAMV] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/sam7s_se.aspx SAM7S/SE] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/sam7x_xc.aspx SAM7X/XC] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.st.com/web/en/catalog/mmc/SC1169/SS1858 Produktseite der STM32F7-Serie von ST]

=== ARM7TDMI ===
Der Vorgänger der Cortex-M-Cores ist der '''ARM7'''TDMI. Controllerfamilien dieser Klasse sind immer noch weit verbreitet:
* [[LPC2000]] von NXP
* [[AT91SAM]] von Atmel
* [[ADuC7xxx]] von Analog Devices
* [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=203&familyId=454 Texas Instruments TMS470]
* S3C24x0 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2410] von SAMSUNG
* STR7xx von ST Microelectronics [http://www.st.com/mcu/inchtml-pages-str7.html]
* und viele weitere

Mehr Informationen zur ARM-Architektur finden sich in der [http://de.wikipedia.org/wiki/ARM-Architektur Wikipedia], weiterführende Links in der [[Linksammlung#ARM|Linksammlung]].

== Compiler & Software ==
=== [[ARM_GCC|GCC]] ===
Einer der beliebtesten Compiler für ARM-Prozessoren ist der GCC. Er kann sowohl ARM- als auch Thumb-Code erzeugen. Mehr dazu unter [[ARM GCC]].

=== C/C++ IDEs ===
Kostenlose Entwicklungsumgebungen (überwiegend GCC-basiert):
* [http://www.coocox.org/software.html CooCox IDE] (Eclipse basierend)
* [https://gnuarmeclipse.github.io GNU ARM Eclipse] (Eclipse Plugin)
* [http://www.emblocks.org/web/ EmBlocks IDE] (Basiert auf Code::Blocks)
** Compiler: GNU ARM-GCC (in der Installation enthalten), RealView und IAR
** Hardware: STlink (mit "Live data"), openOCD, Jlink.
** Project Import: CoIDE, uVision, Atmel studio, MplabX, Mplab 8
** OS aware debugging
***FreeRTOS
***ChibiOS/RT
** Unterstützt sehr viele Controller(-Hersteller):
***Atmel-ARM
***NXP-ARM
***STMicro-ARM
***EnergyMicro-ARM
**Keine Beschränkungen
**Hier gehts zum ''[http://www.emblocks.org/web/downloads-main Download]'''
* [http://www.emide.org/ emIDE] Windows, komplette Visual Studio artige Entwicklungsumgebung (basierend auf Code::Blocks) mit GCC und Debugger (Unterstützung für Adapter von Segger) 
* [https://mbed.org mbed]: eine kostenlose Online-Entwicklungsumgebung basierend auf dem ARM Realview-Compiler, mit einer umfangreichen C++-Bibliothek für die Controllerfunktionen, integrierter Versionsverwaltung, und vielen Beispielprogrammen. Projekte lassen sich für Keil/IAR/GCC exportieren und offline weiterbearbeiten; die Bibliotheksfunktionen sind Open Source und auch kommerziell einsetzbar.
* [http://www.isystem.com/products/software/winidea-open winIDEAOpen]Die Fa. iSystem stellt mit der winIDEAOpen nun eine kostenlose Entwicklungsumgebung für alle Cortex-M Bauteile zur Verfügung. Als Compiler wird der GNU GCC verwendet und auch gleich mitinstalliert. Die IDE ist recht intuitiv und mit einer umfangreichen Hilfe ausgestattet. Das Ganze funktioniert mit dem GCC ohne Codesize Limit und auch ein Testwerkzeug (testIDEA) ist mit integriert. Hardwareseitig werden neben dem iSystem iTag50 [http://www.isystem.com/products/hardware/cortex-debugger/itag] auch die Segger J-Link Debug Probes sowie der ST-Link von ST unterstützt. Auf der Webseite von iSystem sind auch einige schöne Beispielprojekte für diverse Boards zu finden [http://www.isystem.com/download/winideaopen]. Demnächst soll noch die Unterstützung für die ARM und IAR Compiler hinzuzkommen. Hier gehts zum ''[http://www.isystem.com/download/winideaopen Download]'''
* '''Infineon''' bietet für seine '''XMC''' Prozessorfamilien auch eine kostenlose, professionell gepflegte C/C++ Entwicklungsumgebung an, ohne Einschränkungen auf bestimmte Typen oder Speichergrößen - alle erhältlichen XMC 1000er und 4000er Prozessoren werden unterstützt. Wenn man sich dazu noch eines der günstigen XMC Evaluierungsboards besorgt (XMC 1100 Bootkit, XMC 4500 Relax (lite) Kit o.ä.), hat man ein erstes Entwicklungssystem inklusive wiederverwendbaren HW-Debugger zur Verfügung. Die Entwicklungsumgebung basiert auf Eclipse, besitzt aber zahlreiche Erweiterungen samt Codegenerierung (sogenannte Apps), die gerade am Anfang viele Dinge abnehmen kann, da man die Peripherals damit einfach grafisch konfigurieren kann. Das ist bei Prozessoren, dessen User Manual einige hundert Seiten ausmacht (oder auch für Umsteiger von 8bitter oder anderen 32bittern), nicht unwichtig. Der generierte Code ist template-basiert, gut lesbar und kann später - wenn man mehr Erfahrung hat, für eigene Entwicklungen weiter nutzen und optimieren. Damit verliert man dann allerdings die Möglichkeit, Updates der generierten Codes aus den Apps zu bekommen, die Infineon ebenfalls kostenfrei zur Verfügung stellt. Die Software nennt sich ''Digital Application Virtual Engineer'' ([http://www.infineon.com/dave DAVE]) und kann nach Registrierung kostenlos für Windows heruntergeladen werden. Innerhalb von Dave kann man dann Apps und viele Beispiele (ohne weitere Anmeldung und Kosten) komplett oder selektiv (für bestimmte Prozessoren) herunterladen. Die aktuell stabile Version ist v3. Es ist eine neue DAVE Umgebung v4 in Arbeit, eine Betaversion kann heruntergeladen werden. Diese neue v4 Variante wird auch ein separates SDK besitzen, um Apps für Dave selbst schreiben zu können (z.B. Bauteilhersteller, die die Anbindung an den XMC für Kunden vereinfachen wollen). Einsteiger sollten aber mit v3 beginnen, um nicht über Bugs der Beta v4 zu stolpern (siehe auch im [http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum]).
* '''NXP''' bietet für seine '''LPC''' Prozessorfamilien eine kostenlose C/C++ Entwicklungsumgebung an. Die auf Eclipse basierende Entwicklungsumgebung ([http://www.lpcware.com/lpcxpresso LPCXpresso]) ist nach der Installation bis 8kB freigeschaltet und nach einer einfachen und kostenlosen Registrierung für 256kB. [http://www.lpcware.com/lpcxpresso LPCXpresso] steht für Windows, Linux und Mac zur Verfügung.
* '''ST''' bietet für seine '''STM32''' Prozessorfamilie eine kostenlose C/C++ Entwicklungsumgebung an. Die auf Eclipse basierende Entwicklungsumgebung kann nach Registrierung auf der Homepage heruntergeladen werden. [http://www.openstm32.org/]

Kommerzielle Entwicklungsumgebungen (zum Teil kostenlos mit Einschränkungen) für ARM-basierte Mikrocontroller sind z. B.:
* [http://timor.atollic.com/truestudio/ Atollic TrueStudio] (Windows), Eclipse-basierend inkl. Compiler und Linker für fast alle ARMs, jetzt auch kostenlos mit vielen Beispielen und ohne Codesize-Limitierung, dafür mit anderen Einschränkungen
* [http://www.cosmicsoftware.com/download_cortex_64k.php Cosmic Software] (Windows), bis 64kB kostenlos
* [http://rowley.co.uk/arm/ Crossworks ARM] (inkl. Toolchains basierend auf GCC und Clang, für Windows, Mac OS und Linux)
* [http://www.iar.com/ewarm/ IAR Embedded Workbench for ARM] (Windows)
* [http://www.keil.com/arm/ MDK-ARM von Keil/ARM] (Windows), Lite-Version bis 32kB kostenlos,
* [http://www2.keil.com/stmicroelectronics-stm32/mdk MDK-STM32 von KEIL] Speziell für STM32x0 kostenlos ohne Beschränkung
* [http://www.sisy.de/ SiSy MC++] (Windows), Demo-Version, keine Code-Begrenzung

=== Compiler für sonstige Programmiersprachen ===
* Basic: http://www.mikroe.com/mikrobasic/arm/
* Pascal: http://www.mikroe.com/mikropascal/arm/

=== Interpreter ===
* Forth: https://github.com/ekoeppen/CoreForth
* JavaScript: http://www.espruino.com/
* Lua: http://www.eluaproject.net/

=== ARM/XSCALE/CORTEX Instruction Set Simulator ===
Die Firma Lauterbach bietet unter der Artikelnummer LA-8809 einen Instruction Set Simulator für ARM Cores an. Die Demoversion ist zur Evaluierung kostenlos. Einschränkungen bestehen in der Anzahl der zu ladenden Debugsymbole. Der Simulator unterstützt alle gängigen ARM Derivate und lädt alle üblichen Debugformate, wie die des RealView, IAR und TI Compilers, oder der freien GCC Tools. Zum Simulator gibt es entsprechende zugehörige Debugtools, die allerdings käuflich zu erwerben sind.

* [http://www.lauterbach.com/frames.html?dwnload.html Download ARM/XSCALE/CORTEX Simulator]

== Debug- und Programmierschnittstellen (JTAG/SWD) ==

Alle ARM-basierten Prozessoren verwenden ein einheitliches [[JTAG]]-Interface, über das Debugging und Speicherzugriff erfolgen kann. Nicht standardisiert sind allerdings die Verfahren zum Beschreiben des Flash-ROMs. Deshalb muss man beachten, ob die verwendete JTAG-Software Programmierroutinen für den jeweiligen Controller besitzt.

SWD (Serial Wire Debug) ist eine neue mit den Cortex-Mikrocontrollern eingeführte Debug- und Programmierschnittstelle, die weniger Pins benötigt als JTAG. Hier wird Debug-Bandbreite bzw. Speed gegen mehr verfügbare Pins für in-circuit Debugging "getauscht". Die meisten Controller der Cortex-M0 & M3 Serie können sowohl mittels JTAG als auch mittels SWD programmiert werden, es gibt allerdings auch Exemplare (z.B. [[EFM32]] von [https://www.silabs.com Silicon Labs], XMC1100 von [http://www.infineon.com/xmc Infineon]) welche nur SWD unterstützen.

Eine Übersicht über die empfohlenen Steckerbelegungen für JTAG und SWD gibt ein [http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf Dokument von ARM].

Darüber hinaus gibt es noch herstellerspezifische Schnittstellen wie SPD (Single Pin Debug) von Infineon, oder vorinstallierte serielle Bootloader, z.B. beim [[STM32]] oder auch bei den [[Infineon XMC]], die dann z.B. über ein eigenes [http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/c166/xc166-development-tools-software-and-kits/software-downloads/channel.html?channel=ff80808112ab681d0112ab6b50fe07c9 Tool] ohne weitere Hardware - abgesehen von einem handelsüblichen seriellen Schnittstellenadapter - programmiert werden können.

Viele Entwicklungsboards enthalten auch einen On-Board-Debugadapter zum direkten Anschluss an USB, so dass kein externer SWD- oder JTAG-Adapter notwendig ist. Manche erlauben auch, diesen Adapter abzubrechen und für eigene Entwicklungen weiterzuverwenden, somit ist nach dem Kauf eines Eval-Kits nicht nötig, einen weiteren Adapter später nachzukaufen.

=== Günstige Beispiele zum Einstieg ===
Ein einfacher JTAG-Adapter für den Parallelport ist der "Wiggler"-kompatible, den man auch einfach selbst bauen kann. Als Software lässt sich unter Windows und Linux [http://openocd.berlios.de/ OpenOCD] (zusammen mit [[GDB]]) oder [http://rowley.co.uk Crossworks ARM] verwenden. Für USB gibt es ebenfalls OpenOCD-kompatible JTAG-Adapter.

Von NXP sind preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG-/-SWD-Programer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits]''' (PDF), oder diese '''[http://www.mikrocontroller.net/wikisoftware/index.php?title=LPC1xxx_Entwicklungskit_LPCXpresso Beschreibung]'''.

Von ST gibt es günstige MBED/Arduino kompatible Nucleo Entwicklungskits (ca. 12€) z.B. '''[http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260320?s_searchtype=partnumber]'''. Der integrierte ST-Link Debugger kann mittels SWD und OpenOCD als Software auch andere Chip programmieren. Die etwas teuereren Discoveryboards, z.B. '''[http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1848/PF260946?s_searchtype=partnumber]''', haben mehr externe Bauteile on-board, während die Nucleo Board über Shields erweiterbar sind. Nur bei Nucleo Boards ist eine UART Schnittstelle als Standard über USB zu erreichen, bei Discovery Boards mit ST-Link V2-1 müssen Lötbrücken gesetzt werden.

Auch Infineon bietet Arduino-kompatible Boards+Shields mit dem XMC1100 Prozessor und angeflanschtem Debugger an (ab ca. 16€). Weiters gibt es günstige XMC4500 Kits, die auch Ethernet, SPI-Flash und SDCard-Slot Optionen bieten. Am unteren Ende gibt es ein XMC1100 Kit samt Debugger ab ca. 5€, dieses Board für den Schlüsselbund sozusagen nennt sich treffend "XMC 2 Go". Die Preise können je nach Distributor stark variieren.
Siehe auch hier '''[http://www.infineon.com/cms/de/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-registered-cortex-registered-m/xmc-development-tools-kits-and-boards/channel.html?channel=db3a30433580b3710135a07902883872 XMC-Starter-Kits]'''.
Des weiteren werden auch schon Kits in Verbindung mit Sensoren zum Evaluieren angeboten, wie das "3D 2 Go" Board mit einem XMC1100 Prozessor und dem neuen 3D-Magnetfeldsensor von Infineon, um ein Beispiel zu nennen: '''[http://www.infineon.com/cms/en/product/sensor-ics/magnetic-sensors/3d-magnetic-sensor/channel.html?channel=5546d4624c9e0f0e014c9e105a8a001c 3D-Sensorkit]'''.

Von Silicon Labs gibt es [https://www.silabs.com/products/mcu/Pages/32-bit-microcontroller-tools.aspx Starter Kits] mit integriertem J-Link (Debugger) ab ca. 25 € z.B. das [https://www.silabs.com/products/mcu/lowpower/Pages/efm32tg-stk3300.aspx EFM32 Tiny Gecko Starter Kit] bei [http://www.mouser.de/ProductDetail/Silicon-Laboratories/EFM32TG-STK3300/?qs=%2fha2pyFadujBGJvO8YBq9JikBLXQGi%2fjwmF17imXuts5383tWpQKFA%3d%3d Mouser]

Der [http://www.segger.com/cms/jlink.html J-Link]-"Emulator" von Segger wird von vielen Softwarepaketen unterstützt und ist für den "nicht-kommerziellen" Einsatz von Studenten, Funkamateuren und Hobby-Bastler für ca. €50.- erhältlich (J-Link-Edu). Sein Umfang ist auf das Flashen des Speichers und das Debuggen beschränkt. Bonus: Neben den im Prozessor limitiert vorhandenen Hardware-Breakpoints (Anzahl ist MCU abhängig) sind zusätzliche Flash-Breakpoints möglich (müssen aber von der verwendeten Debug-IDE unterstüzt werden). Die sehr gut geplegte Debugger-Software unterstützt nahezu alle ARM Prozessoren. Die Trace-Option wie sie bei der PRO-Variante zur Verfügung steht, ist nicht vorhanden. Für den Preis bekommt man jedoch ein ausgewachsenes Werkzeug mit breiter Unterstützung und der Möglichkeit sowohl SWD als auch JTAG in einem Gerät vereint zu haben. Wenn man aber plant, ein oben genanntes Kit von ST, NXP, Infineon oder ähnlich zu kaufen kann man für ähnliche Kosten auch gleich ein CPU-Board dazubekommen - daher ist es sinnvoll, sich die Dokumentationen der Evalkits voher genau durchzusehen.

Der ULINK2 von Keil/ARM ist ebenfalls ein wirklich gutes Gerät. Leider ist er nicht ganz so günstig und seine Zusammenarbeit beschränkt sich auf die Arm/Keil IDE µVision. Er benötigt jedoch keine speziellen USB-Treiber sondern nutzt geschickt die Funktionalität der HID-Treiber des Betriebssystems. Das macht ihn sofort auf jedem Windows-Betriebssystem einsatzbereit.

Als Alternative zum Beschreiben des Flash über JTAG ist oft ein serieller [[Bootloader]] im Controller enthalten. Bei ST werden sie über einen speziellen Pin der MPU aktiviert und sind dank Kompression und das intelligente entfernen redundanter Information, bei der Übertragung genauso schnell wie JTAG/SWD Adapter.

== CMSIS - ARM Cortex Software Libraries ==
Der ARM Cortex Microcontroller Software Interface Standard (CMSIS) ist ein herstellerunabhängiger Hardware Abstraction Layer für die Cortex-M-Prozessor -Serie. Dieser ermöglicht konsistente und einfache Software-Schnittstellen für den Prozessor und die Peripherie, und vereinfacht damit die Software-Wiederverwendung.

CMSIS besteht aus folgenden Komponenten:

* CMSIS-CORE: Bietet eine Schnittstelle zum Cortex-M0, Cortex-M3, Cortex-M4, SC000 und SC300-Prozessorkern und Peripherie-Registern.
* CMSIS-DSP: DSP-Bibliothek mit über 60 Funktionen in Festkomma-(fractional q7, q15, q31) und single precision floating-point (32-bit)-Implementierung
* CMSIS-RTOS API: Standardisierte Programmierschnittstelle für Echtzeit-Betriebssysteme für Thread-Steuerung, Ressourcen-und Zeitmanagement. Implementierungen gibt es z.B. von Keil ([http://www.keil.com/pack/doc/cmsis_rtx/index.html RTX])
* CMSIS-SVD: System View Beschreibung - XML-Dateien, die die Programmiereransicht des kompletten Mikrocontroller-Systems einschließlich Peripheriegeräte enthalten

Der Standard ist für Cortex-M-Mikrocontroller skalierbar: Von der kleinsten 4 KB MCU bis zu MCUs mit anspruchsvoller Kommunikations-Peripherie wie Ethernet oder USB. Die "Core Peripheral Funktionen" benötigt beispielsweise weniger als 1 KB-Code und weniger als 10 Bytes RAM.

Beispiele:
* Software Beispiele von [http://www.energymicro.com/downloads/application-notes Energy Micro] basierend auf CMSIS

Mehr Informationen auf der [http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php ARM CMSIS Webseite].

== Siehe auch ==
* [[Linksammlung#ARM|Linksammlung (Abschnitt ARM)]]
* [[LPC1xxx]]
* [[LPC1xxx_Entwicklungskit_LPCXpresso]]
* [[Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red]]
* [[Codebase_f%C3%BCr_LPC1xxx]]
* [[ARM-elf-GCC-Tutorial]]
* [[AVR32]]
* [[Blackfin]]
* [[AT91SAM9260]]
* [[STM32]]
* [[JTAG]]
* [http://www.mikrocontroller.net/articles/EFM32 EFM32]
* [http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks STM32 - Einstieg mit Em::Blocks Tutorial]

== Weblinks ==
* [http://www.mySTM32.de Online Tutorial für den STM32]
* [http://www.myXMC.de Online Tutorial für den XMC von Infineon]
* [http://www.myUGL.de Online Tutorial für freie Grafikbibliothek, STM32, STM32F429, TFT, Touch]
* [http://embdev.net/forum/arm-gcc ARM-GCC Forum] im englischsprachigen "Ableger" von mikrocontroller.net embdev.net u.a. für WinARM, Yagarto, CS Codebench
* [http://www.arm.com/products/processors/cortex-m/index.php Cortex-M Produktseite von ARM]
* [http://infocenter.arm.com/help/index.jsp Infocenter von ARM Ltd.]
* [http://www.open-research.org.uk/ARMuC/ ARMuC ARM microcontroller Wiki]
* [http://chaosradio.ccc.de/cre151.html Chaosradio Express - Die ARM-Architektur]

== Literatur ==
* ARM Systems Developer's Guide (2004) ISBN 1558608745 [http://books.google.de/books?id=HKKUkDQE17QC&output=html Im Buch blättern] [http://booksite.elsevier.com/9781558608740/ Programmbeispiele aus dem Buch, u.a. FFT, FIR/IIR-Filter, Division, Wurzel]
* ARM Assembly Language - an Introduction (2007) ISBN 1847536964 [http://books.google.de/books?id=8KJX5R8mMvsC&output=html Im Buch blättern] [http://www.lulu.com/content/1172076 Verlagsseite "Book on demand"]
* ARM Rechnerarchitekturen für System-on-Chip-Design (2002) ISBN 3826608542
* Co-Verification of Hardware and Software for Arm Soc Design (2004) ISBN 0750677309
* ARM System-on-Chip Architecture (2000) ISBN 0201675196 [http://books.google.de/books?id=J_Fu_YTVD9gC&printsec=frontcover&output=html&source=gbs_summary_r&cad=0 Im Buch blättern]
* ARM Architecture Reference Manual ISBN 0201737191 [http://books.google.de/books?id=O5G-6WX1xWsC&printsec=frontcover&output=html&source=gbs_summary_r&cad=0 Im Buch blättern]
* Messen, Steuern und Regeln mit ARM-Mikrocontrollern ISBN 3772340172 [http://books.google.de/books?id=TKs4kN-zNYQC&output=html im Buch blättern]
* Programming Arm Microcontrollers: Using C and the Lpc2100 Family (2005? /ab 1. Dezember 2008) ISBN 0321263359
* Arm Assembly: Fundamentals and Techniques (ab 1. März 2009) ISBN 1439806101
* Reliable Embedded Systems: Using 8051 and ARM Microcontrollers (2007) ISBN 0321252918 600 Seiten mit CD [http://vig.pearsoned.co.uk/catalog/academic/product/0,1144,0321252918-TOC,00.html Inhaltsverzeichnis]
* C und C++ für Embedded Systems (u.a. ARM Cortex-M3) mitp-Verlag 2008 ISBN 382665949X
* The Definitive Guide to the Arm Cortex-M0 (Joseph Yiu) Newnes Verlag ISBN 0123854776
* The Definitive Guide to the Arm Cortex-M3 (Joseph Yiu) Newnes Verlag ISBN 185617963X

[[Category:ARM| ]]

Cortex-A

2017-06-02T08:29:06Z

Newgeneration: Update und hinzufügen der neuen Prozessoren A75 und A55

ARM Cortex-A sind von [[ARM]] konstruierte Prozessorkerne, wie sie zusammen mit dem Vorläufer ARM11 und einigen unabhängigen Implementierungen der ARM-Architektur in nahezu jedem Smartphone und Tablet verbaut sind.

ARM bezeichnet die Prozessorlinien folgendermaßen<ref>http://arm.com/products/processors/index.php</ref>:

;ARM Cortex Embedded Processors: Cortex-M Series – Cost-sensitive solutions for deterministic microcontroller applications
;ARM Cortex Real-time Embedded Processors: Cortex-R Series – Exceptional performance for real-time applications
;ARM Cortex Application Processors: Cortex-A Series – High performance processors for open Operating Systems

Die Cortex-A-Prozessoren sind deutlich leistungsstärker als ARM Cortex M Mikroprozessoren, daher werden sie eher im Application-Bereich, sprich mit Betriebssystemen, wie Linux (z.B. Debian, Arch Linux ARM, Android), Windows Mobile etc. eingesetzt.

{| class="mw-collapsible mw-collapsed wikitable"
|+ Offizielle Beschreibungen aller Cortex-A Prozessoren von ARM
|-
! style="width: 25% | ARM Core || Key Benefits
|-
| Cortex-A5 ||
* ARM’s smallest application processor with Uniprocessor (UP) and Multiprocessor (MP) licensing options
* Extremely configurable processor with optional NEON, optional FPU and L1 caches configurable from 4K-64KB
* Full feature set of Cortex-A9 processor at one third the area and power
|-
| Cortex-A7 ||
* ARMv7-A architectural extensions (40-bit physical addressing, hardware virtualization support)
* More than 20% improvement in single thread integer performance compared to Cortex-A5
* Integrated L2 cache subsystem provides improved area efficiency and up to 43% improvements in memory streaming performance
* Proven successful design, now well matched to the needs of wearable mobile devices and other UI-based consumer products
|-
| Cortex-A8 ||
* Large increase in single thread performance over it’s predecessor, the ARM11
* ARMv7-A support including NEON and TrustZone
* Widely deployed in mobile and embedded, with numerous low-cost 3rd party development platforms. A great processor on which to learn the ARM architecture.
|-
| Cortex-A9 ||
* Scalable performance and power efficiency for a broad range of 32-bit consumer, networking, enterprise and mobile applications
* Support the wide ARMv7-A 32-bit software eco-system
* Mature and silicon proven in multiple process technologies
|-
| Cortex-A15 ||
* Established ARMv7-A processor with NEON-VFP configurability
* Reliable 32-bit infrastructure computing with 1TB addressing
* Support for multi-tenant software virtualization
|-
| Cortex-A17 ||
* Highest performance for ARMv7-A software ecosystem
* Cost efficiency with premium 32-bit performance for mass-market devices
* Mature and shipped in a wide range of consumer and embedded markets
|-
| Cortex-A32 ||
* ARMv8-A architectural enhancements, full backwards compatibility with ARMv7-A software
* Higher efficiency and performance compared to Cortex-A7 processor
* New idle power management features
* Highly scalable 32-bit processor with new configuration options
|-
| Cortex-A35 ||
* Most efficient 64-bit ARMv8-A processor with full ARMv7-A compatibility
* Efficiency improvements compared to the Cortex-A7: Less active power, improved performance
* Highly scalable ARMv8-A processor with new configuration options
|-
| Cortex-A53 ||
* High efficiency CPU for wide range of applications in mobile, DTV, automotive, networking, and more
* ARMv8-A architecture at low cost for standalone entry level designs
* Versatile enough to pair with any ARMv8 core in a big.LITTLE pairing, including Cortex-A57, Cortex-A72, or even other Cortex-A53 or Cortex-A35 CPU clusters
* Mature product with high volume shipment
|-
| Cortex-A55 ||
* Extreme scalability
* Delivering great performance and efficiency for immersive experiences
* Over 3000 unique design configurations
* new DynamIQ big.LITTLE Concept
|-
| Cortex-A57 ||
* Established ARMv8-A 64-bit processor
* Reliable 64-bit infrastructure computing with 16TB addressing
* Proven functional safety documentation package
|-
| Cortex-A72 ||
* ARM’s state-of-the-art high-performance processor for infrastructure, mobile, and automotive
* Market-leading compute density across all application form factors
* Improved performance and efficiency, with full ARMv8-A 64b support.
|-
| Cortex-A73 ||
* Highest performance in mobile power envelope. Up to 30% higher performance than previous generation.
* Up to 2.8GHz frequency for highest peak performance
* New levels of sustained usage for the best user experience. Up to 30% increased power efficiency
* Smallest premium ARMv8-A processor ever. Premium CPU under 0.65mm2 per core.
|-
| Cortex-A75 ||
* New levels of performance
* 20% more integer core performance
* Latest architecture (ARMv8-A)
* new DynamIQ big.LITTLE Concept
|}

== Unterschiede zum Cortex-M ==

Die Unterschiede zu den Cortex-M Mikrocontrollern sind unter anderem folgende:
* Teilweise 64 bit Prozessoren, mit vergrößertem Adressraum (44 bit oder mehr statt 32 bit)
* Kein On-Chip Speicher (meist ein geringes RAM vorhanden, aber ein externes ist so gut wie immer trotzdem nötig) macht externes Speicherinterface nötig, was viele Pins nutzt. Auch braucht man natürlich extra Speicher- und (DDR)-SDRAM-ICs.
* Mehrere Levels von Data und Instruction Caches
* Gehäuse mit wesentlich mehr Pins, meist im BGA
* Höhere Taktfrequenz (mehr als 500 MHz sind keine Seltenheit, aktuell maximal 2.8 GHz)
* ARM big.LITTLE Konzept: mehrere "kleine" Cortex-A-Cores werden zusammen mit mehreren "großen" Cores verschalten, um Enegie zu sparen: wenn wenig Leistung nötig ist werden die Energie-effizienteren Cores benutzt, bei hohen Leistungsanforderungen übernehmen die anderen Cores
* DynamIQ: neuere Erweiterung des big.LITTLE-Konzepts für mehr Flexibilität
* ARM Jazelle für die beschleunigte Ausführung von Java-Code
* Sicherheitsmechanismen, wie eine [[MMU]] oder die ARM TrustZone Technologie
* Optional eine NEON™ Media Processing Engine
* Schnellere und präzisere [[FPU]]
* Kryptographie, wie AES- und SHA-Algorithmen, True-Random-Generators
* Digitale Interfaces, die man eher aus dem PC-Bereich kennt, wie HS-USB-Hosts, schnelles Ethernet, SD/MMC Interface, Kamera- oder Video-Dekoder, I²S, ...
* Dazu kommen aber auch klassische Mikrocontroller-Interfaces, wie UART, I²C, SPIs, interne ADCs und DACs, sowie Timer
''(für alle oben genannten Fälle gibt es natürlich auch Ausnahmen)''

Einige der oben genannten Punkte finden sich neuerdings auch in Cortex-M7-Controllern, die damit die Brücke zwischen Mikrocontrollern und Anwendungsprozessoren schlagen.

Größter Nachteil für diese Leistungsfähigen Controller wird das fehlen von On-Chip Flash und RAM sein, weil man so extra ICs braucht, was wiederum das Layouten erschwert, da ein DDR3-RAM-Design nicht mehr sonderlich einfach ist.

== Links ==

* [http://www.arm.com/products/processors/cortex-a Offizielle ARM Seite zu der Cortex-A Serie]
* [[Linux Boards]]
* [[Raspberry Pi Einführung]]
* [[ARM Cortex Mikrocontroller]]

<references/>

[[Kategorie:ARM]]

Implementierung einer Finite State Machine

2017-05-30T04:56:06Z

Newgeneration: Änderung 96470 von 46.161.9.51 (Diskussion) rückgängig gemacht.

#REDIRECT [[Statemachine#Implementierung einer objektorientiert Finite State Machine in C++]]

LeckerWecker (Zeitschloss)

2017-05-29T08:53:06Z

Newgeneration: Änderung 96450 von 46.161.9.20 (Diskussion) rückgängig gemacht.

[[Datei:LeckerWeckerZwischenstand.JPG|thumb|So gut wie fertig!]]
Egal ob man die Leckereien vor seinen Mitmenschen oder sich selbst schützen muss, das Zeitschloss '''LeckerWecker''' gibt seinen Inhalt erst nach Ablauf der eingestellten Zeit frei.

== Beschreibung ==

Das Zeitschloss LeckerWecker sperrt eine Kiste für eine einstellbare Zeit ab. Durch Drücken der Sperr-Taste für drei Sekunden lässt sich die Sperrzeit einstellen, wobei die Eingabe in Stunden und Tagen über einen Drehgeber erfolgt. Die Einstellungen werden mit der Sperr-Taste abgeschlossen oder bei 30 Sekunden Untätigkeit verworfen. Die Taste zum Entsperren gibt das elektrische Schloss frei sofern die Sperrzeit abgelaufen ist oder zeigt die verbliebene Wartezeit auf einer 7-Segmentanzeige an.

Die Schaltung ist für langen Batteriebetrieb ausgelegt und verfügt zudem über eine Batterieüberwachung. Bei leerer Batterie blinkt, während der Auslösung des elektrischen Schlosses, auf der 7-Segmentanzeige der Schriftzug <tt>bat</tt>. Bei längerer Lagerung empfiehlt sich den Türöffner mechanisch zu entsperren.

Der Nachbau soll jedem Hobbyelektroniker möglich sein. Daher wurden keine raren Spezialteile verwendet. Alle Teile lassen sich vom Baumarkt, bei eBay oder beim Elektronikversender beziehen. Für das präzise Bohren der Frontplatte empfiehlt sich eine Ständerbohrmaschine und für die Platine gibt es den Leiterplattenservice. Alles andere sollte sich auch in der kleinsten Hobbywerkstatt finden lassen.

== Aufbau ==

Die nachfolgende Bauanleitung stellt keine exakte Schritt für Schritt Anleitung dar, jedoch ist alles soweit nötig beschrieben.

=== Mechanik ===

Obwohl es sich hier um ein Elektronikprojekt handelt zeigt es sich, dass der mechanische Aufbau das meiste Geschick und die meiste Zeit erfordert.

Im ersten Schritt erfolgt das Bohren und Bestücken der großen Frontplatte. Die Maße sind dabei nicht bindend sondern eine Empfehlung. Die Löcher für die Leiterplatte müssen mit großer Sorgfalt an einer Ständerbohrmaschine gesetzt werden, denn sonst sieht unschön aus. Alle haben mit Ausnahme für das Türschloss (4mm) und den Drehgeber (8mm) einen Durchmesser von 3mm. Das Fenster für die 7-Segmentanzeige wird zunächst aufgezeichnet und dann mit vielen Bohrlöchern grob frei gemacht und anschließend mit der Feile auf seine volle Größe erweitert.

Die Leiterplatte wird mit einem Sandwich befestigt bestehend aus:
* 20mm lange M3-Zylinderkopfschraube
* 10mm lange M3-Distanzhülse
* Leiterplatte
* M3-Mutter
* Schutzplatte
* M3-Mutter

Im weiteren Steht das zweiteilige Batteriefach an, das passend zur Frontplatte gebohrt wird. Die Senkkopfschrauben werden mit einem 6mm Bohrer von Hand versenkt. Zum Schluss erfolgt die Befestigung mittels 20mm langen M3-Distanzhülsen.

Da das Schließblech so noch zu Groß ist, muss es erstmal passend zur Frontplatte zugeschnitten werden. Den Türöffner zwecks Stabilität vor den Arbeiten gleich einbauen. Als Abstandhalter dienen ein 40mm M4-Distanzhülsen und 10mm lange M4-Zylinderkopfschrauben.

An der Kiste muss jetzt das Stück für die Frontplatte heraus gesägt werden, wobei seitlich und unten eine Überlappung von 15mm erhalten bleibt. Und natürlich nicht vergessen die Verschraubung anbringen. Da reichen auch M3-Schrauben und Beilagscheiben für die Holzseite.

Soweit der einfache Teil, denn mit Falle beginnt die Pfrimelei. Als erstes wird der Abstand von der Innenkante der Frontplatte zur Spitze des Türöffner gemessen. Davon wird die Tiefe des Schlosses abgezogen. Als nächstes wird von der Spitze der Falle bis zur Innenkante der Befestigungsplatte des Einsteckschlosses gemessen. Aus diesen beiden Maßen kann die Einrückung für die Montagewinkel bestimmt werden. Da die Falle deutlich schmaler als der Türöffner ist, lässt sich die seitliche Einrückung grob über den Daumen peilen. Statt den Deckel zu verkrizeln sollte ein Blatt Papier eingeklebt werden. Damit die Kiste auch stabelbar bleibt, bieten sich M5-Senkkopfschrauben für die Befestigung der Winkel an.

Nun zum aller schwierigsten der Höhenbohrung der Montagewinkel. Zunächst wird grob ein Loch gebohrt, so dass mindestens ein Restspalt von 10mm bleibt. Nun wird die Spaltbreite ermittelt bis die Falle an der Zunge vom Türöffner anschlägt. Das ist das Maß, um der die endgültige Bohrung versetzt werden muss.

Zuletzt fehlt noch der Griff zum Öffnen der Kiste.

=== Elektronik ===

Die Drähte der Batteriehalter verlängern, so dass es eben reicht. Vielleicht mit einem übergezogenem Schrumpfschlauch die Leitungen noch bündeln und mit Kabelbinder an den Distanzhülsen fixieren.

Für das Zusammenlöten sei auf den Eagle-Schaltplan verwiesen, der sich mit der kostenlosen Light Edition öffnen und bearbeiten lässt.

Den Uhrenquarz mit Patex oder Heißkleber fixieren.

=== Software ===

Die Software liegt als Intel HEX-Format vor und kann mit jedem ISP-Programmer in den Atmel AVR geladen werden.

=== Inbetriebnahme ===

Der erste Teil der Inbetriebnahme erfolgt, wenn die Leiterplatte fertig gelötet und programmiert ist. Statt dem Türöffner dient eine LED mit Vorwiderstand als Indikator. Als Spannungsversorgung dient nicht die Batterie, sondern ein Labornetzteil mit der Spannung 9,0V und der Strombegrenzung auf 200mA.

Beim Drücken der rechten Taste leuchten die Anzeige und die Test-LED. Nach kurzem Warten gehen beide wieder aus. Nun am Labornetzteil die Spannung absenken und nach dem drücken der rechten Taste die Schwelle zur Unterspannungserkennung ermitteln. Die sollte bei 6,0V liegen. Ansonsten ggf. den Spannungsteiler R18 und R19 nach Tabelle aus der Materialliste austauschen.

{| {{Tabelle}}
! !! R18 !! R19
|----
| Zu hoch/Zu früh || 240kΩ || 1,0MΩ
|----
| Normal || 240kΩ || 1,1MΩ
|----
| Zu niedrig/Zu spät || 250kΩ || 1,2MΩ
|}

Danach die linke Taste lange drücken bis die Tagesanzeige blinkt. Nun mit dem Drehgeber testen das alle Zahlen stimmen. Die linke Taste nochmal kurz drücken und nun blinkt die Stundenanzeige. Auch hier die Zahlen mit den Drehgeber durchtesten. Nach etwa 30 Sekunden warten hört das blinken auf. Zuletzt ohne Strombegrenzung das zuverlässige auslösen des Türöffners prüfen.

Für den weiteren Aufbau den Türöffner auf Tagesentriegelung stellen solange nicht alles funktioniert. Die arbeiten gelten als abgeschlossen, wenn die Sperrzeit minutengenau über mehrere Tage gelaufen ist.

== Materialliste ==

Die Details zur Materialliste finden sich in den [[#Downloads]]

== Funktion ==

Jedem steht es frei Abwandlungen und Verbesserungen an diesem Projekt vorzunehmen. Deswegen sei nachfolgend kurz die Funktion erläutert

=== Mechanik ===

Neben dem elektrischen Türöffner wären noch weitere Lösungen für ein elektrisches Schloss denkbar gewesen. Zum einen ein Modellbauservo, der einen Riegel dreht oder verschiebt und des weiteren ein Zugmagnet als Betätiger.

=== Elektronik ===

Als Kostengründen wurde die Leiterplatte einlagig gestaltet, wobei ein zweilagiges Layout sicher weniger Umstände gemacht hätte. Aus EMV-gründen umschließt die Massefläche die gesamte Schaltung. Als Anzeige dient eine LED-7-Segmentanzeige im Multiplexbetrieb.

Eine Notstromversorgung, die nur bei Ausfall der Batterie und Elektronik das Schloss freigibt wäre super gewesen.

=== Software ===

[[Datei:Zustandsautomat.svg|thumb|]]
Im Kern besteht der LeckerWecker aus einem [[Zustandsautomat]]en, der sich im Main-Modul in einer Endlosschleife befindet. Je nach Eingangsereignis oder Zeitablauf erfolgt ein Zustandsübergang.

Die Software selbst ist in Schichten aufgebaut. Es gibt die HAL-Schicht in der alle Zugriffe auf die Hardware gekapselt sind, darauf setzen dann die Schichten mit den Funktionseinheiten auf und als oberstes das Main-Modul, das die Funktionseinheiten zu einer Anwendung verknüpft.

Die HAL-Schicht lässt sich ziemlich einfach testen. In einem separatem Unterordner befindet sich ein weiteres Makefile, das nur auf die HAL-Module verweist. Und beim entsprechenden Testschritt aufruft.

Die Modultest für die Funktionseinheiten wurden noch nicht realisiert. Naheliegend sind hierfür zwei Verfahren. Der Quellcode für die Funktionseinheiten wird in einen anderen Ordner kopiert, in dem sich ein Mockup-HAL befindet, und das ganze Makefile wird als normale PC-Anwendung realisiert, die den HAL und die Modul-Schnittstellen stimuliert. Alternativ könnte der gleiche Trick mit der Zielhardware umgesetzt werden. Hier ist nur das auswerten den Resultate schwieriger.

== Projektstatus / TODO ==
;Software
* Modultests fehlen
* Bei Spannungsaussetzer, durch Schläge auf die Kiste, mit der letzten Stunde aus dem EEPROM beginnen
* Inkonsistenz: Programmier-Taste/Sperrtaste/Entsperren/Öffnen
== Download ==

* [[:Datei: LeckerWecker.zip]]

== Siehe auch ==

* [[EEU]]
* [[:Kategorie:Timer und Uhren]]

== Weblinks ==

keine

[[Kategorie:Timer und Uhren]]

Lokale Elektroniklieferanten

2017-05-29T05:03:27Z

Newgeneration: Änderung 96433 von 46.161.9.20 (Diskussion) rückgängig gemacht.

=Einleitung=
Diese Liste enthält '''Ladengeschäfte''', bei denen man als Privatkunde lokal, vor Ort, elektronische Bauteile erhalten kann. Keine Flohmärkte, einmalige Veranstaltungen oder Geschäfte, die nur an gewerbliche Kunden verkaufen.

__TOC__

Falls die Darstellungsart nicht gefällt oder Rubriken fehlen, so bitte nicht hier ändern, sondern das Template anpassen: [[Vorlage:ElektronikLieferant]] 
So soll das Template ausgefüllt werden:
{{ElektronikLieferant
|Firmenname=hier Firmenname eintragen
|Straße=Straßenname, z. B. Musterstraße 123
|PLZ=PLZ, z. B. 12345
|Ort=Ort, z. B. München
|Telefon=Telnr., z. B. 012345/12341234
|Fax=Faxnr., z. B. 012345/12345234
|Öffnungszeiten=Öffnungszeiten eintragen Neue Zeile mit "br" abgetrennt
|Weblink=http://www.mikrocontroller.net Link ohne umschliessende eckige Klammern
|Email=Emailadresse, z. B. xxx@yyy.de
|Bemerkung=ggf. Bemerkung, ansonsten Rubrik/Feld/Variable leer lassen
}}

=Deutschland=
==Baden-Württemberg==
===Aalen===
{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Wilhelm-Zapf-Str. 9
|PLZ=73430
|Ort=Aalen
|Telefon=07361/610820
|Fax=07361/610821
|Öffnungszeiten=Mo.-Fr. 9.00 - 13.00 Uhr, 14.00 - 18.00 Uhr Sa. 9.00 - 13.00 Uhr
|Weblink=http://www.muekra.com/Filiale_Aalen
|Email=info@muekra.de
|Bemerkung=Keine SMD-Teile 
Leider gibt es den Laden nicht mehr!
}}

===Bopfingen===
{{ElektronikLieferant
|Firmenname=HENRI-electronic GmbH
|Straße=Am Stadtgraben 11
|PLZ=73441
|Ort=Bopfingen
|Telefon=07362/919093
|Fax=07362/919096
|Öffnungszeiten=Mo.-Fr. 9.30 - 12.30 Uhr, 13.30 - 18.00 Uhr Sa. 9.00 - 13.00 Uhr
|Weblink=http://www.henri.de
|Email=vertrieb@henri.de
}}

===Esslingen===
{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Bahnhofstr. 23
|PLZ=73728
|Ort=Esslingen
|Telefon=0711/355676
|Fax=0711/3108656
|Öffnungszeiten=Mo.-Fr. 9.00 - 13.00 Uhr, 14.30 - 18.00 Uhr Sa. 9.00 - 13.00 Uhr
|Weblink=https://www.muekra.de/filiale-esslingen/
|Email=info@muekra.de
|Bemerkung=Keine Mikrocontroller, keine SMD-Teile (ausser einige wenige Transistoren)
}}

===Göppingen===
{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Geislinger Str. 2
|PLZ=73033
|Ort=Göppingen
|Telefon=07161/9641718
|Fax=07161/9641730
|Öffnungszeiten=Mo.-Fr. 9.00 - 12.30 Uhr, 14.00 - 18.00 Uhr Sa. 9.00 - 13.00 Uhr
|Weblink=http://www.muekra.com/Filiale_Goeppingen
|Email=info@muekra.de
|Bemerkung=Keine Mikrocontroller, keine SMD-Teile (ausser einige wenige Transistoren). Es besteht die Möglichkeit die Bauteile die nicht im Sortiment vorhanden sind zu bestellen. Dies ist sehr günstig und passiert in 2-3 Werktagen.
}}

===Heilbronn===
{{ElektronikLieferant
|Firmenname=centralsystems GmbH
|Straße=Otto-Hahn-Straße 8
|PLZ=74078
|Ort=Heilbronn
|Telefon=07066-9192790
|Fax=07066-9192791
|Öffnungszeiten=Mo.-Do. 8.00 - 20.00 Uhr Fr. 8.00 - 12.00 Uhr 
|Weblink=http://www.centralsystems.de
|Email=info@centralsystems.de
|Bemerkung=Standardkomponenten vor allem im Bereich der EDV, keine SMD-Teile, keine Microcontroller.
}}

===Heilbronn===
{{ElektronikLieferant
|Firmenname=Krauss Elektronik GmbH
|Straße=Turmstraße 20
|PLZ=74072
|Ort=Heilbronn
|Telefon=07131/68191
|Fax=07131/68192
|Öffnungszeiten=Mo.-Mi.+Fr. 9.00 - 18.00 Uhr Do. 9.00 - 19.00 Uhr Sa. 9.00 - 13.00 Uhr
|Weblink=http://www.krauss-elektronik.de/
|Email=info@krauss-elektronik.de
|Bemerkung=
}}
===Freiburg===
{{ElektronikLieferant
|Firmenname=Omega electronic GmbH
|Straße=Eschholzstr. 58-60
|PLZ=79115
|Ort=Freiburg
|Telefon=0761/76776-0
|Fax=0761/76776-55
|Öffnungszeiten=Mo.-Sa.: 09:00 - 19:30
|Weblink=http://www.omega-electronic.de
|Email=info@omega-electronic.de
|Bemerkung=
}}

===Karlsbad===
{{ElektronikLieferant
|Firmenname=IT-WNS, Thomas Heldt
|Straße=Schulstr. 13
|PLZ=76307
|Ort=Karlsbad - Mutschelbach
|Telefon=07202/936083
|Fax=07202/936085
|Öffnungszeiten=Nach Vereinbahrung (Email-Kontakt)
|Weblink=http://www.it-wns.de
|Email=info@it-wns.de
|Bemerkung=Bestellungen im Onlineshop können wahlweise auch direkt abgeholt werden
}}

===Karlsruhe===
{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Fritz-Erler-Straße 24
|PLZ=76133
|Ort=Karlsruhe
|Telefon=0721/374270
|Fax=0721/9379171
|Öffnungszeiten=Mo.-Fr. 9.00 - 13.00 Uhr, 14.30 - 18.00 Uhr Sa. 9.00 - 13.00 Uhr
|Weblink=https://www.muekra.de/filiale-karlsruhe
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Werner Bremer Elektrotechnik & Einzelhandel
|Straße=Zähringerstraße 55a
|PLZ=76133
|Telefon=
|Fax=
|Ort=Karlsruhe
|Weblink=
|Email=
|Öffnungszeiten=
|Bemerkung=Vielleicht geschlossen?? keine Website. Versand? GESCHLOSSEN. Seit ca. 2014 ist da ein Friseur drin.
}}

===Ludwigsburg===
{{ElektronikLieferant
|Firmenname=Mayer Elektronik
|Straße=Stuttgarter Str. 32
|PLZ=71638
|Ort=Ludwigsburg
|Telefon=07141 920 711
|Fax=
|Öffnungszeiten=Mo.-Fr. 09.00-12.30 und 14.30-18.00 Uhr, Mittwoch nachmittags geschlossen, Sa. 09.00-12:30 Uhr
|Weblink=http://www.Mayer-Elektronik.de
|Email=info@Mayer-Elektronik.de
|Bemerkung= Spezialisiert auf Antennentechnik, Sat-Anlagen. Verschiedene Kleinteile erhältlich
}}

===Mannheim===
{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Morchfeldstr. 37-39
|PLZ=68199
|Ort=Mannheim - Neckarau
|Telefon=0180 6 564445 (20 Cent/Verbindung aus dem Festnetz, max. 60 Cent/Verbindung aus dem Mobilfunknetz)
|Fax=
|Öffnungszeiten=Mo.-Fr. 10.00-20.00 Uhr, Sa. 10.00-18.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-mannheim.html
|Email=filiale.mannheim@conrad.de
|Bemerkung=
}}

===Offenburg===
{{ElektronikLieferant
|Firmenname=Günther Wultschner (Elektronikladen)
|Straße=Luisenstraße 16
|PLZ=77654
|Ort=Offenburg
|Telefon=0781 43270
|Fax=
|Öffnungszeiten=Mo.-Fr. 9.30 - 18:30 Uhr Sa. 9.30 - 14.00 Uhr
|Weblink=http://www.wultschner-elektronik.de/
|Email=
|Bemerkung=
}}

===Pforzheim===
{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Westliche Karl-Friedrich-Str. 73
|PLZ=75172
|Ort=Pforzheim
|Telefon=07231 313952
|Fax=
|Öffnungszeiten=Mo.-Fr. 9.00 - 12:30 Uhr; 14.00 Uhr - 18.00 Uhr Sa. 9.00 - 13.00 Uhr
|Weblink=http://www.muekra.com/Filiale_Pforzheim
|Email=
|Bemerkung=
}}

===Reutlingen===
{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Federnseestr. 4
|PLZ=72764
|Ort=Reutlingen
|Telefon=07121/370748
|Fax=07121/370741
|Öffnungszeiten=Mo.-Fr. 9.30 - 13.00 Uhr, 14.00 - 18.00 Uhr Sa. 9.30 - 13.00 Uhr
|Weblink=http://www.muekra.com/filiale_reutlingen.html
|Email=info@muekra.de
|Bemerkung=Keine SMD-Teile
}}

===Schwäbisch Gmünd===
{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Kalter Markt 12
|PLZ=73525
|Ort=Schwäbisch Gmünd
|Telefon=07171/64352
|Fax=07171/405684
|Öffnungszeiten=Mo.-Fr. 9.00 - 12.30 Uhr, 14.00 - 18.00 Uhr Sa. 9.30 - 13.00 Uhr
|Weblink=http://www.muekra.com/Filiale_Schwaebisch_Gmuend
|Email=info@muekra.de
|Bemerkung=Keine SMD-Teile.... Laden geschlossen seit 31.12.15 !

}}

===Stuttgart===
{{ElektronikLieferant
|Firmenname=Dräger Electronic & Audio GmbH
|Straße=Hauptstätter Strasse 55
|PLZ=70178
|Ort=Stuttgart
|Telefon=+49 711 601818-46
|Fax=
|Öffnungszeiten=Montag - Freitag 10:00 - 19:00 Uhr Samstag 10:00 - 16:00 Uhr
|Weblink=http://www.dea-gmbh.de
|Email=info@draeger-electronic.de
|Bemerkung= Audio, Hifi, Tontechnik, Kabel, schon lange keine Bauelemente mehr!
}}

{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Kronenstraße 7, Altes Postquartier
|PLZ=70173
|Ort=Stuttgart
|Telefon=0180 5 564445 (14 Cent/Min. aus dem Festnetz, max. 42 Cent/Min. aus dem Mobilfunknetz)
|Fax=
|Öffnungszeiten=Mo.-Sa. 10.00-20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-stuttgart.html
|Email=filiale.stuttgart@conrad.de
|Bemerkung=
}}

===Ulm===
{{ElektronikLieferant
|Firmenname=AW-Elektronik
|Straße=Hermann-Köhl-Str. 9
|PLZ=89160
|Ort=Ulm/Dornstadt
|Dienstleistungen=Entwicklung Hard & Software; Leiterplattenbestückung SMD und THD; Leiterplattenlayout und Routing
|Weblink=http://www.aw-elektronik.de
|Email=info@aw-elektronik.de
|Öffnungszeiten=
|Telefon=
|Fax=
|Bemerkung=Nach Absprache können lagernde Bauteile gekauft werden. Am Lager sind SMD-Bauteile wie z.B. AVR, Widerstände, Kondensatoren, LEDs; Die LEDs sind als WarmWeiß 3500K (1800mcd), Kaltweis 7000K (2850mcd), Rot (1500mcd) und Blau (350mcd) und UV vorhanden.
}}

{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Neutorstr. 20
|PLZ=89073
|Ort=Ulm
|Telefon=0731/64494
|Fax=0731/6028676
|Öffnungszeiten=Mo.-Fr. 9.00 - 18.00 Uhr Sa. 9.00 - 13.00 Uhr
|Weblink=http://www.muekra.com/Filiale_Ulm.html
|Email=
|Bemerkung=Keine SMD-Teile
}}

===Villingen-Schwenningen===
{{ElektronikLieferant
|Firmenname=Buchmann Elektronik
|Straße=Wasenstraße 51
|PLZ=78054
|Ort=Villingen-Schwenningen
|Telefon=07720/1308
|Fax=07720/1360
|Öffnungszeiten=Montag bis Freitag 09.00 - 12.30 & 14.00 - 19.00 Uhr; Mittwoch Nachmittag geschlossen; Samstag geschlossen
|Weblink=http://www.buchmann-elektronik.de
|Email=buchmann-elektronik@t-online.de
|Bemerkung=keine SMD.
}}

{{ElektronikLieferant
|Firmenname=SchiBe Elektronik
|Straße=Mühlenstr. 9
|PLZ=78050
|Ort=Villingen-Schwenningen
|Telefon=07721/8879880
|Fax=07721/88798820
|Öffnungszeiten=Mo-Fr 11.00 bis 12.00 Uhr, 14.00 Uhr bis 18.30 Uhr
|Weblink=http://www.schibe.de
|Email=info@SchiBe.de
|Bemerkung=Bestellt auf Anfrage ohne Versandkosten bei Conrad mit Selbstabholung dort.
}}

==Bayern==
===Ansbach===
{{ElektronikLieferant
|Firmenname=Mehl Electronic
|Straße=Schaitbergerstr. 1
|PLZ=91522
|Ort=Ansbach
|Telefon=0981/977166
|Fax=0981/977167
|Öffnungszeiten=Montag - Freitag 09:00 - 18:00 Uhr Samtag 10:00 - 13:00 Uhr
|Weblink=http://www.electronic-mehl.de
|Email=service@electronic-mehl.de
|Bemerkung=
}}

===Aschaffenburg===
{{ElektronikLieferant
|Firmenname=VS Elektronik OHG
|Straße= Magnolienweg 3
|PLZ= 63739
|Ort=Aschaffenburg
|Telefon=06021-30460
|Fax=06021-304626
|Öffnungszeiten= Montag - Freitag: 09:00 - 18:00 Uhr Samstag: 09:00 - 13:00 Uhr
|Weblink=http://www.vs-electronic.de
|Email=info@vs-electronic.de
|Bemerkung= führt Vellemann Bausätze, PCs, Telekommunikation und Bauteile
}}

===Augsburg===
{{ElektronikLieferant
|Firmenname=rf-elektronik
|Straße= Karlstraße 2, Eingang über Obstmarkt
|PLZ=86150
|Ort=Augsburg
|Telefon=0821 39830
|Fax=0821 518727?
|Öffnungszeiten= Montag - Freitag: 10:00 - 18:00 Uhr Samstag: 10:00 - 13:00 Uhr
|Weblink=http://www.rf-elektronik.de
|Email=info@rf-elektronik.de
|Bemerkung=Bauelemente, Satellitentechnik+Zubehör, Halbleitertechnik, Satellitenanlagenbau, Akkus, im Laden befindet sich als nettes Schmankerl auch ein winziges, technisches Bücher-Antiquariat
}}

===Erlangen===
{{ElektronikLieferant
|Firmenname=Schoffer Radio-Fernseh-Elektronik
|Straße=Beethovenstraße 2
|PLZ=91052
|Ort=Erlangen
|Telefon=09131 25288
|Fax=
|Öffnungszeiten=Mo-Fr 9.00 - 12.30, 13.30-18.00 Uhr. Sa 9.30 - 13.00 Uhr
|Weblink=
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=
|Straße=Marquardsenstraße 21
|PLZ=91054
|Ort=Erlangen
|Telefon=09131 27595
|Fax=
|Öffnungszeiten=Mo-Fr 9.00 - 13.00, 14.00-18.00 Uhr. Sa 9.00 - 13.00 Uhr
|Weblink=http://www.feller-electronic.de
|Email=
|Bemerkung=
}}

===Fürth===
{{ElektronikLieferant
|Firmenname=B+D Electronic GmbH
|Straße=Königstr. 107 (gegenüber Citycenter und neben Feuerwehr)
|PLZ=90762
|Ort=Fürth
|Telefon=0911 - 77 30 40
|Fax=
|Öffnungszeiten=Mo - Fr: 10.00 - 12.30 & 14.00 - 18.00 Sa: 10.00 - 13.00
|Weblink=http://www.bdelectronic.de/
|Email=
|Bemerkung=komplettes Sortiment online einsehbar (Excel), keine Mikrocontroller
}}

===Holzheim===
{{ElektronikLieferant
|Firmenname=RH Electronic Eva Spaeth
|Straße=Ostertalstraße 15
|PLZ=86684
|Ort=Holzheim
|Telefon=08276 / 58800
|Fax=08276 / 58802
|Öffnungszeiten=
|Weblink=http://rhelectronic.tradoria.de/
|Email=eva@peterscable.de
|Bemerkung=
}}

=== Kaufbeuren ===
{{ElektronikLieferant
|Firmenname=Jantsch-Elektronik GmbH
|Straße=Porschestraße 26
|PLZ=87600
|Ort=Kaufbeuren
|Telefon=0 83 41 / 95 33-0
|Fax=0 83 41 / 37 00
|Öffnungszeiten=Mo-Fr 9:00-12:30 / 13:30-18:00 
Sa 9:00-13:00 Uhr
|Weblink= http://www.j-e.de
|Email=info@j-e.de
|Bemerkung=führt auch gebrauchte Messgeräte
}}

=== Kiefersfelden (bei Rosenheim) ===
{{ElektronikLieferant
|Firmenname=db-electronic, Jutta Richter
|Straße=Dorfstr. 30
|PLZ=83088
|Ort=Kiefersfelden
|Telefon=0 80 33 / 86 80
|Fax=0 80 33 / 76 19
|Öffnungszeiten=Mo-Fr 9:00-18:00 
Sa 10:00-12:00 Uhr
|Weblink= http://www.db-electronic.de
|Email=info@db-electronic.de
|Bemerkung=Verkauft neben aktiven, passiven und mechanischen Bauteilen, Werkzeug, technische Sprays, Messgeräte, Kleingeräte, LED-Artikel, Kabel, Akkus, Batterien und Computerzubehör
}}

===Landshut===
{{ElektronikLieferant
|Firmenname=Der Elektronik Landen
|Straße=Innere Münchener Straße 16
|PLZ=84036
|Ort=Landshut
|Öffnungszeiten=Mo - Fr 8:00 - 12:00, 14:00 - 18:00; Sa 8:00 - 12:00
|Weblink=
|Email=
|Bemerkung= kleiner, aber feiner Laden. Verkauft eher nur Analogtechnik, Röhren, und recht selten gewordene Sachen
}}

{{ElektronikLieferant
|Firmenname=Rauschhuber Electronic
|Straße=Gaußstraße 2
|PLZ=84030
|Ort=Landshut
|Öffnungszeiten=Mo - Fr 8:00 - 17:00
|Weblink=http://rauschhuber.de/
|Email=
|Bemerkung= Kleiner Laden neben MediaMarkt. Verkauft Verbrauchsmaterial, wie Zinn und Lötsauglitze, Aktive und Passive Bauelemente und Werkzeug, wie Lötkolben, Seitenschneider, Schraubendreher u.n.v.m.K..
}}

===Leiblfing (bei Straubing)===
{{ElektronikLieferant
|Firmenname=Hans Entner Funkelektronik
|Straße=Landshuter Straße 1
|PLZ=94339
|Ort=Leiblfing
|Telefon=(0 94 27) 90 20 86
|Fax=09427 - 902087
|Öffnungszeiten= leider nicht bekannt
|Weblink=
|Email=Entner-DF9RJ@t-online.de
|Bemerkung= Kleiner Laden und sehr netter Inhaber. Einige Geräte und Zubehör. Viele HF-Stecker (v.a. SMA, BNC, N und PL(UHF)) und Koax-Kabel. Bietet auch Reparaturen an.
}}

===München===
{{ElektronikLieferant
|Firmenname=AM Elektronik Vertrieb - Albert & Machl KG
|Straße=Kirchtruderinger Str. 6
|PLZ=81829
|Ort= München (Trudering)
|Telefon=089/4904180
|Fax=
|Öffnungszeiten=Mo-Do 8:00-12:00, 13:00-17:00 Uhr, Fr 8:00-12:00, 13:00-15:00 Uhr
|Weblink=http://stores.ebay.de/weri2elektronikwelt, http://www.am-elektronik.de
|Email=info@am-elektronik.de
|Bemerkung=Laden ist eher ein grosses Lager, daher am besten Bestellung per Mail und dann abholen.
}}

{{ElektronikLieferant
|Firmenname=Balzer CFS
|Straße=Implerstrasse 14
|PLZ=81371
|Ort=München
|Telefon=089/55221243
|Fax=
|Öffnungszeiten=
|Weblink=http://www.balzer-cfs.de
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Bürklin
|Straße=Grünwalder Weg 30
|PLZ=82041
|Ort=Oberhaching
|Telefon=(089) 55 875-0
|Fax=(089) 55 875-421
|Öffnungszeiten=Mo - Fr: 8:00 - 19:00
|Weblink=https://www.buerklin.com/de
|Email=info@buerklin.de
|Bemerkung= Achtung neuer Standort nicht mehr Schillerstraße !!!
}}

{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Tal 29
|PLZ=80331
|Ort=München
|Telefon=
|Fax=
|Öffnungszeiten=Mo - Fr: 9:00 - 20:00 Sa: 9:00 - 20:00
|Weblink=https://www.conrad.de/de/filialen/filiale-muenchen-tal.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Hanauer Straße 91 (gegenüber OEZ)
|PLZ=80993
|Ort=München - Moosach
|Telefon=
|Fax=
|Öffnungszeiten=Mo - Fr: 9:30 - 20:00 Sa: 9:00 - 20:00
|Weblink=https://www.conrad.de/de/filialen/filiale-muenchen-moosach.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Strixner & Holzinger
|Straße=Schillerstraße 25-29
|PLZ=80336
|Ort=München
|Telefon=
|Fax=
|Öffnungszeiten=Mo - Fr: 9:30 - 18:00
|Weblink=http://www.strixner-electronic.de, http://sh-halbleiter.de
|Email=
|Bemerkung=
}}

===Nürnberg===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Fürther Straße 212
|PLZ=90429
|Ort=Nürnberg
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo - Fr: 9:30 - 20:00 Sa: 9.30 - 18:00
|Weblink=https://www.conrad.de/de/filialen/filiale-nuernberg.html
|Email=filiale.nuernberg@conrad.de
|Bemerkung=Gegenüber ehemaligem Quelle-Stammhaus
}}

===Regensburg===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Langobardenstraße 2
|PLZ=93053
|Ort=Regensburg
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo - Sa: 10:00 - 20:00
|Weblink=https://www.conrad.de/de/filialen/filiale-regensburg.html
|Email=filiale.regensburg@conrad.de
|Bemerkung=Im Fachmarktzentrum Bajuwarenstraße
}}

===Pförring===
{{ElektronikLieferant
|Firmenname=Pollin
|Straße=Max-Pollin-Straße 1
|PLZ=85104
|Ort=Pförring
|Telefon=
|Fax=
|Öffnungszeiten=Mo.-Fr. 9 - 19 Uhr Sa. 9 - 16 Uhr
|Weblink=http://www.pollin.de/shop/static/ecenter.htm
|Email=
|Bemerkung=nähe Ingolstadt
}}

===Rosenheim===
{{ElektronikLieferant
|Firmenname=AKAZEN GmbH
|Straße=Papinstr. 8
|PLZ=83022
|Ort=Rosenheim
|Telefon=+49 (0) 8031 / 90088-0
|Fax= +49 (0) 8031 / 90088-22
|Öffnungszeiten= 9.00 - 17.00
|Weblink= http://shop.akazen.de
|Email= info@akazen.de
|Bemerkung= Online bestellen & bezahlen, Vor-Ort Abholung möglich. Shop befindet sich im Aufbau, wenn Sie etwas suchen, bitte Anfrage per Mail oder Telefon
}}

===Schweinfurt===
{{ElektronikLieferant
|Firmenname=elkra electronic
|Straße=Kerschensteinerstr. 11
|PLZ=97422
|Ort=Schweinfurt
|Telefon=09721-3870033
|Fax=09721-803295
|Öffnungszeiten=
|Weblink=http://www.elkra.de
|Email=info@elkra.de
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Spath Elektronische Bauteile
|Straße=Cramerstr. 9
|PLZ=97421
|Ort=Schweinfurt
|Telefon=09721/25186
|Fax=09721/22999
|Öffnungszeiten=
|Weblink=
|Email=
|Bemerkung=
}}

===Untermeitingen===
{{ElektronikLieferant
|Firmenname=Werner Weidemeier Ilona Elektronik
|PLZ=86836
|Ort=Untermeitingen
|Straße=Wiesenstr. 15 A
|Telefon=+49 (0) 8232 / 78598
|Fax=unbekannt
|Öffnungszeiten=unbekannt
|Weblink=kein WebLink vorhanden
|Email=keine ofizielle eMail-Adresse
|Bemerkung= Alle wichtigen und gängigen Kleinteile vorhanden. Uriger, kleiner Laden im Wohnhauskeller :-)
}}

=== Wernberg ===
{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Klaus-Conrad-Straße 2
|PLZ=92533
|Ort=Wernberg
|Telefon=
|Fax=
|Öffnungszeiten=Mo - Fr 09.00-19.00 Uhr Sa 09.00-18.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-wernberg.html
|Email=filiale.wernberg@conrad.de
|Bemerkung=auch Versandzentrum
}}

==Berlin==
===Charlottenburg-Wilmersdorf===
{{ElektronikLieferant
|Firmenname=Segor-electronics
|Straße=Kaiserin-Augusta-Allee 94
|PLZ=10589
|Ort=Berlin
|Telefon=030 4399843
|Fax=030 4399855
|Öffnungszeiten=Mo.-Fr. 10.00-13.30 Uhr und 14:30-18:00 Uhr, Sa. 10.00-13.00 Uhr
|Weblink=http://www.segor.de
|Email=sales@segor.de
|Bemerkung=Sehr gut sortiertes und vielseitiges Sortiment, preiswert, hochwertig.
}}

===Kreuzberg===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Hasenheide 14-15
|PLZ=10967
|Ort=Berlin
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Fr. 10.00-19.00 Uhr, Sa. 10.00-18.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-berlin-kreuzberg.html
|Email=
|Bemerkung=
}}

===Friedrichshain===
{{ElektronikLieferant
|Firmenname=TinkerSoup
|Straße=Frankfurter Allee 53
|PLZ=10247
|Ort=Berlin
|Telefon=03077903156
|Fax=
|Öffnungszeiten=
|Weblink=http://www.tinkersoup.de
|Email=info@tinkersoup.de
|Bemerkung=Ist ein reiner Onlineshop eigentlich, wurde 2016 von Pimoroni aus Englang gekauft. Hat deutschen Kunden Support.
}}

===Mahlsdorf===
{{ElektronikLieferant
|Firmenname=Marotronics
|Straße=Hultschiner Damm 151
|PLZ=12623
|Ort=Berlin
|Telefon=030 5163658-4
|Fax=030 5163658-5
|Öffnungszeiten=
|Weblink=https://www.marotronics.de
|Email=info@marotronics.de
|Bemerkung=Arduinolastiges Angebot(wird ausgebaut), nach Absprache Selbstabholung möglich, wer Interesse an einem DIY Rasenroboter hat kann ihn sich dort im Einsatz ansehen
}}

===Prenzlauer Berg===
{{ElektronikLieferant
|Firmenname=SLY electronic
|Straße=Erich-Weinert-Straße 139-141
|PLZ=10409
|Ort=Berlin
|Telefon=030 428492-0
|Fax=030 428492-29
|Öffnungszeiten=Mo.-Fr. 10.00-19.00(Juli+Aug nur bis 18:00) Uhr, Sa. 10.00-16.00 Uhr,
|Weblink=http://www.sly.de
|Email=mail@sly.de
|Bemerkung=Für den kleinen Laden ist das Angebot relativ groß, der Audio-bastler wird hier für fündig v.a. für Musiker: sprich Stecker, Potis (große Auswahl an Knöpfen), Fittings. im Laden wird mehr angeboten als auf der Internetseite (nicht 100% aktualisiert). Er ist im Schnitt im Vergleich zur Apotheke Conrad preisgünstiger.
}}

===Schöneberg===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Kleiststraße 30-31
|PLZ=10787
|Ort=Berlin
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Sa. 10.00-20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-berlin-schoeneberg.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Atzert Radio
|Straße=Kleiststraße 32-33
|PLZ=10787
|Ort=Berlin
|Telefon=
|Fax=
|Öffnungszeiten= nur online
|Weblink=http://www.atzert-radio.de/
|Email=
|Bemerkung=Ist geschlossen (27.3.2015) und nur noch Online verfügbar
}}

===Steglitz===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Schloßstraße 34-36
|PLZ=12163
|Ort=Berlin
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Sa. 10.00-20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-berlin-steglitz.html
|Email=
|Bemerkung=
}}

==Brandenburg==

===Cottbus===
{{ElektronikLieferant
|Firmenname=Klauck Electronic-Shop
|Straße=Karl-Liebknecht-Str. 53a
|PLZ=03046
|Ort=Cottbus
|Telefon=0355 / 797044
|Fax=
|Öffnungszeiten=
|Weblink=
|Email=
|Bemerkung=reichlich eigene Parkplätze im Hof
 Mai 2014: seit längerem geschlossen :(
}}

{{ElektronikLieferant
|Firmenname=electronic Shop cottbus
|Straße=Schweriner Str. 2
|PLZ=03046
|Ort=Cottbus
|Telefon=0355 / 2890585
|Fax=0355 / 539545
|Öffnungszeiten=Mo.-Fr. 09.00 - 12.00 Uhr, 14.00 - 18.00 Uhr
|Weblink=http://www.eshop-cb.de/eshop/
|Email=
|Bemerkung=der Shop ist sehr jung, daher ist das Team noch etwas unerfahren, macht dies aber durch Freundlichkeit wett
 Von der Straße aus nicht auszumachen, am besten zu Fuß erkunden. Mai 2014: Eintrag noch immer aktuell
}}

{{ElektronikLieferant
|Firmenname=Koenig Elektronik / Technorm
|Straße=Karl-Liebknecht-Str. 59
|PLZ=03046
|Ort=Cottbus
|Telefon=0355 22746
|Fax=
|Öffnungszeiten=Mo.-Fr. 08.00 - 14.00 Uhr
|Weblink=
|Email=
|Bemerkung=ein "typischer Krämerladen", hat aber genau das, was man vom lokalen Händer erwartet.
 richtet sich eher an gewerbliche Radiotechniker, verkauft aber problemlos auch an Endkunden.
 Laden im Hinterhof. Mai 2014: Eintrag noch aktuell
}}

===Frankfurt (Oder)===
{{ElektronikLieferant
|Firmenname=Elektronik Service Landrock
|Straße=Karl-Ritter-Platz 8-9
|PLZ=15230
|Ort=Frankfurt (Oder)
|Telefon=0335 / 6802029
|Fax=0335 / 684171
|Öffnungszeiten=Mo-Fr. 10-18 Uhr
|Weblink=http://www.landrock-elektronik.de/
|Email=
|Bemerkung=Jürgen (Chef) ist superfreundlich, habe jahrelang dort eingekauft.
}}

==Bremen==
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Borgwardstr. 2
|PLZ=28279
|Ort=Bremen
|Telefon=01 80 / 55 64 44 5
|Fax=
|Öffnungszeiten=Mo-Fr 10.00-19.00 Uhr Sa 10.00-18.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-bremen.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Schuricht Distrelec GmbH
|Straße=Rehland 8
|PLZ=28832
|Ort=Achim
|Telefon= 04 20 2 / 97 47-97
|Fax=
|Öffnungszeiten=
|Weblink=https://www.distrelec.de
|Email=
|Bemerkung= Nur telefonische Bestellung. Wenn man bei der Bestellung explizit sagt dass man die Sachen in Achim abholen möchte, dann klappt dies auch... meistens...
}}

{{ElektronikLieferant
|Firmenname=Widi-Elektronik
|Straße=Waller-Heerstraße 29
|PLZ=28217
|Ort=Bremen
|Telefon= 0421 - 39 61 137
|Fax=
|Öffnungszeiten= Mo-Sa: 9.30-13, Mo-Fr: 15-18
|Weblink=http://widi-elektronik.de/
|Email=
|Bemerkung= Hat fast alles, am besten vorher die genaue Bezeichnung im Katalog (auf der Website zu finden) aufschreiben und eine Liste vorlegen. Dann geht's auch relativ zügig
}}

==Hamburg==
=== Hammerbrook ===
{{ElektronikLieferant
|Firmenname=Radio Kölsch
|Straße=Kreuzbrook 14
|PLZ=20537
|Ort=Hamburg
|Telefon=040 / 653 00 81
|Fax=040 / 653 00 80
|Öffnungszeiten=Montag - Freitag 10:00 - 19:00 Uhr, Samstag 10:00 - 16:00 Uhr
|Weblink=http://www.radiokoelsch.de/
|Email=
|Bemerkung= Sortiment nahezu komplett umgestellt auf Leuchten und Textilkabel. Eine kleine Auswahl historischer Bauteile wird auf der Homepage noch angeboten. Ansonsten gibt es noch diverses "Chinawerkzeug" und Ersatzteile für Haushaltsgeräte
}}

===Hoheluft Ost===
{{ElektronikLieferant
|Firmenname=Statronic
|Straße=Hoheluftchaussee 84
|PLZ=20253
|Ort=Hamburg
|Telefon=040 / 422 33 22
|Fax=040 / 422 33 25
|Öffnungszeiten=
|Weblink=http://www.statronic.de
|Email=
|Bemerkung=Stand 06/2014 kaum noch Bauteile verfügbar, mit Chance bekommt man einfache Teile z.B. Schraubklemmblöcke.
}}

===Wandsbek===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Wandsbeker Zollstr. 67-69
|PLZ=22041
|Ort=Hamburg
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Fr. 09.30-20.00 Uhr, Sa. 09.00-18.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-hamburg-wandsbek.html
|Email=
|Bemerkung=
}}

===Altona===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Hahnenkamp 1
|PLZ=22765
|Ort=Hamburg
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Sa. 10.00-20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-hamburg-altona.html
|Email=
|Bemerkung=
}}

==Hessen==
===Darmstadt===
{{ElektronikLieferant
|Firmenname=Zimmermann Electronic GmbH
|Straße=Kasinostr. 2
|PLZ=64293
|Ort=Darmstadt
|Telefon=06151 - 66 69 - 240
|Fax=06151 - 66 69 - 290
|Öffnungszeiten=Mo.- Fr. 9:00 - 19:00 Uhr Sa. 9:00 - 14:00 Uhr
|Weblink=http://www.zeg-shop.de
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=EBG Electronic Business GmbH
|Straße=Bismarckstr. 61
|PLZ=64293
|Ort=Darmstadt
|Telefon=06151 / 82 91 - 0
|Fax=06151 / 82 91 - 20
|Öffnungszeiten=Montag-Freitag: 9:00 bis 18:00 Uhr Samstag: 9:00 bis 13:00 Uhr
|Weblink=http://www.ebg-darmstadt.de
|Email=info@ebg-darmstadt.de
|Bemerkung=Geschäft geschlossen wegen Insolvenz
}}

===Frankfurt/Main===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Zeil 58 + 64 (Konstabler Wache)
|PLZ=60313
|Ort=Frankfurt
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Mi. 10.00-20.00 Uhr Do.-Sa. 10.00-21.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-frankfurt.html
|Email=
|Bemerkung=
}}

===Hanau===
{{ElektronikLieferant
|Firmenname=MP Elektronik Vertriebs GmbH
|Straße=Hospitalstr. 13
|PLZ=63450
|Ort=Hanau
|Telefon=06181/253077
|Fax=06181/921450
|Öffnungszeiten= Seit 30. Nov. 2013 geschlosssen wegen jahrelanger unzumutbarer Baustellen in Hanau
|Weblink=
|Email=
|Bemerkung=
}}

===Kassel===
{{ElektronikLieferant
|Firmenname=Geddert-Elektronik (seit Januar 2014 geschlossen)
|Straße=Holländische Straße 31
|PLZ=34127
|Ort=Kassel
|Telefon=0561 / 897177
|Fax=0561 / 84329
|Öffnungszeiten=
|Weblink=
|Email=
|Bemerkung= Gibt es leider nicht mehr
}}

{{ElektronikLieferant
|Firmenname=UK-Elektronik
|Straße=Königstor 52
|PLZ=34117
|Ort=Kassel
|Telefon=0561 / 771074
|Fax=0561 / 778373
|Öffnungszeiten=Montag - Freitag 9:30 bis 18:00 Uhr, Samstag 9:30 bis 13:00 Uhr
|Weblink=http://www.uk-elektronik.com/
|Email=info@UK-Elektronik.com
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Schuro Elektronik GmbH
|Straße=Friedrich-Ebert-Straße 3
|PLZ=34117
|Ort=Kassel
|Telefon=0561 / 16415
|Fax=0561 / 770318
|Öffnungszeiten=
|Weblink=
|Email=
|Bemerkung= keine Abholung von Bauteilen möglich
}}

{{ElektronikLieferant
|Firmenname=NT-Elektronik Toprakci Nihat Elektronik
|Straße=Hoffmann-von-Fallersleben-Str 3
|PLZ=34117
|Ort=Kassel
|Telefon=0561 / 2020858
|Fax=0561 / 2020857
|Öffnungszeiten=Montag - Freitag 10:00 – 19:00 Uhr, Samstag 10:00 – 16:00 Uhr
|Weblink=http://www.nt-elektronik.de/
|Email=NT-Elektronik@hotmail.de
|Bemerkung=
}}

===Offenbach===
{{ElektronikLieferant
|Firmenname=rail- electronic GmbH
|Straße=Waldemar- Klein- Platz 1
|PLZ=63071
|Ort=Offenbach
|Telefon=069 / 88 20 72
|Fax=069 / 88 31 14
|Öffnungszeiten=Mo - Fr 10h - 19h Sa 10h - 16h
|Weblink=http://www.rail-electronic.de
|Email=info@rail-electronic.de
|Bemerkung=Computer- Hardware/ Software/ Service/ Kabel/ Stecker/ Adapter/ ... Unser Ladengeschäft befindet sich direkt im Stadion in der unteren Ladenzeile, Sie können gleich davor parken
}}

===Wetzlar===
{{ElektronikLieferant
|Firmenname=Electronic-Shop Lutz Hoffmann
|Straße=Silhöfertorstr. 3
|PLZ=35578
|Ort=Wetzlar
|Telefon=06441 / 94627
|Fax=06441 / 946271
|Öffnungszeiten=Mo. - Sa. 9.00 - 13.00 Uhr Mo. - Fr. 14.00 - 18.00 Uhr
|Weblink=http://www.funk-shop.de/
|Email=mail@funk-shop.de
|Bemerkung=
}}

===Wöllstadt===
{{ElektronikLieferant
|Firmenname=ELW Elektronik Handels GMBH
|Straße=Am Kalkofen 10
|PLZ=61206
|Ort=Wöllstadt
|Telefon=06034-4411
|Fax=06034-5739
|Öffnungszeiten=Mo. - Fr. 08.30 - 18.00 Uhr Sa. 08.30 - 13.00 Uhr
|Weblink=http://www.elw-elektronik.com/
|Email=elw-gmbh@t-online.de
|Bemerkung=
}}

==Mecklenburg-Vorpommern==
===Rostock===
{{ElektronikLieferant
|Firmenname=A-Z City-Stores
|Straße=Doberaner-Hof
|PLZ=
|Ort=Rostock
|Telefon=0381-4031171
|Fax=
|Öffnungszeiten=Mo. – Fr. 9.30 – 19.30 Uhr Sa. 9.30 – 16.00 Uhr
|Weblink=
|Email=
|Bemerkung=geringes Angebot recht teuer
}}

==Niedersachsen==
===Braunschweig===
{{ElektronikLieferant
|Firmenname=Conrad Electronic GmbH
|Straße=Sudetenstr. 4
|PLZ=38114
|Ort=Braunschweig
|Telefon=0180 5 564445
|Fax=???
|Öffnungszeiten=Mo.-Fr. 09.30-19.00 Uhr, Sa. 09.00-18.00 Uhr (Abweichend in der Vorweihnachtszeit!)
|Weblink=https://www.conrad.de/de/filialen/filiale-braunschweig.html
|Email=filiale.braunschweig@conrad.de
|Bemerkung= Die Resterampe hinter dem Hauptgebäude gibt es nicht mehr. Dorthin wurde die Modellbau-Abteilung ausgelagert.
}}

{{ElektronikLieferant
|Firmenname=ETT - Electronic Toys Trading GmbH
|Straße=Kreuzstraße 65
|PLZ=38118
|Ort=Braunschweig
|Telefon=0531-58 11 00
|Fax=0531-58 11 030
|Öffnungszeiten=
|Weblink=http://www.ett-online.de/
|Email=bestell@ett-online.de
|Bemerkung= Online-Katalog unter http://www.megakick-stores.de/. Zu Atzert-Elektronik mutiert. '''Insolvent!:''' Stand August 2014: ETT hat Insolvent angemeldet; evtl. Garantieansprüche für alte Käufe werden damit wohl verfallen; sollte das Unternehmen komplett insolvent sein, gilt dies auch für neue Käufe. Auch die angeschlossenen vier Atzert-Läden sind betroffen: alle vier sind für immer geschlossen worden. 2015 gerüchtehalber unter Löwen-Elektronik wieder eröffnet (http://löwen-elektronik.com/).
}}

{{ElektronikLieferant
|Firmenname=Elektronik Bauteile Vertrieb - Dipl.-Ing. Jörg Bassenberg
|Straße=Nußbergstraße 9
|PLZ=38102
|Ort=Braunschweig
|Telefon=0531-79 17 07
|Fax=0531-7 60 22
|Öffnungszeiten=
|Weblink=http://www.bassenberg.de/
|Email=info@bassenberg.de
|Bemerkung= Kleines Ladengeschäft, hauptsächlich ältere Bauteile vorrätig.
}}

{{ElektronikLieferant
|Firmenname=ChiliTec GmbH
|Straße=Bäckerberg 12
|PLZ=38165
|Ort=Lehre-Essenrode
|Telefon=05301-9029980
|Fax=05301-9029988
|Öffnungszeiten=Mo-Fr 8-17 Uhr
|Weblink=http://www.chilitec.de/
|Email=willkommen@chilitec.de
|Bemerkung= Elektronik-Großhandel mit Schwerpunkt auf LED-Beleuchtung und Haustechnik. Versand oder Selbstabholung möglich.
}}

===Buxtehude===
{{ElektronikLieferant
|Firmenname=Sell-Elektronik
|Straße=Brillenburgsweg 31A
|PLZ=21614
|Ort=Buxtehude
|Telefon=04161-88305
|Fax=-
|Öffnungszeiten=Mo.-Fr. 10:00-12:00 Uhr & 15:00-18:30 Uhr, Sa. 10:00-13:00 Uhr
|Weblink=
|Email=
|Bemerkung=Ladengeschäft. Riesen Sortiment an passiven, aktiven und mechanischen Bauteilen. Gute Beratung und faire Preise.
}}

===Göttingen===
{{ElektronikLieferant
|Firmenname=Göttinger Elektronik Center
|Straße=Bahnhofstr. 9
|PLZ=37130
|Ort=Gleichen
|Telefon=0551-487988
|Fax=
|Öffnungszeiten=
|Weblink=
|Email=
|Bemerkung=Ortsteil Diemarden
}}

===Goslar===
{{ElektronikLieferant
|Firmenname=Thometzek-Elektronik
|Straße=Marktstr. 12
|PLZ=38640
|Ort=Goslar
|Telefon=05321-23773
|Fax=05321-20180
|Öffnungszeiten=Mo-Sa: 9:00-13:00 Uhr, Mo,Di,Do,Fr: 14:30-18:00 Uhr
|Weblink=http://www.thometzek-elektronik.de
|Email=ruediger.thometzek@t-online.de
|Bemerkung=Kleines Ladengeschäft mit CB- und Amateurfunk, Lichttechnik, ... und Bauteilen
}}

===Hannover===
{{ElektronikLieferant
|Firmenname=Conrad Electronic GmbH
|Straße=Goseriede 3
|PLZ=30159
|Ort=Hannover
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Sa. 09.00-20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-hannover.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Radio Menzel-Electronic
|Straße=Fössestraße 6
|PLZ=30451
|Ort=Hannover
|Telefon= 0511 442607
|Fax=
|Öffnungszeiten=Mo-Fr: 10:00-13:30, 14:30-18:00 Sa: 10:00-13:30
|Weblink=http://www.menzel-electronic.de
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Zloch-Elektronik
|Straße=Calenberger Str. 33
|PLZ=30169
|Ort=Hannover
|Telefon=0511 15575
|Fax=
|Öffnungszeiten=Mo-Fr: ? Sa: ?
|Weblink=keine
|Email=
|Bemerkung= '''Geschlossen''' - Zloch Elektronik ist einer der ältesten Läden dieser Art in Hannover. Man bekommt dort auch Bauteile, die selten sind (Restbestände alter Zeiten). Anfahrt mit öffentlichen Verkehrsmitteln: Haltestelle Humboldtstraße oder Haltestelle Waterloo. Seit mindestens September 2013 geschlossen (laut Schild). Seit mindestens August 2014 wird Inventar in Umzugskisten verpackt.
}}

===Lüneburg===
{{ElektronikLieferant
|Firmenname=Beusch Elektronik
|Straße=Reichenbachstr. 8
|PLZ=21335
|Ort=Lüneburg
|Telefon=04131 33311
|Fax=
|Öffnungszeiten=Mo und Sa geschlossen, Di - Fr 10:00-13:00, 14:00-18:00
|Bemerkung=Gibt's nicht mehr! :-(
}}

{{ElektronikLieferant
|Firmenname=EleConT - Peter Schoss
|Straße=Schierenweg 29a
|PLZ=21382
|Ort=Brietlingen
|Telefon=04133 404843
|Fax=
|Öffnungszeiten=nach Absprache
|Weblink=http://www.elecont.de/
|Email=info@elecont.de
|Bemerkung=
}}

===Oldenburg===
{{ElektronikLieferant
|Firmenname=ebc Utz Kohl GmbH
|Straße=Alexanderstraße 31
|Telefon=0441 82114
|Fax=0441 85801
|Weblink=www.e-b-c-elektronik.de
|Email=kontakt@e-b-c-elektronik.de
|PLZ=26121
|Ort=Oldenburg
|Öffnungszeiten=Mo. - Fr. 9:00 - 12:30 und 13:30 - 18:00 Uhr, Sa. 9:00 - 13:00 Uhr
|Bemerkung=
}}

===Osnabrück===
{{ElektronikLieferant
|Firmenname=Heinicke-electronic
|Straße=Meller Str. 43
|PLZ=49084
|Ort=Osnabrück
|Telefon=0541 587666
|Fax=0541 586614
|Öffnungszeiten=Mo-Fr. 9:30-13:00Uhr und 14:30-18:00Uhr Sa. 9:30-13:00Uhr
|Weblink=http://www.heinicke-electronic.de/
|Email=sales@heinicke-electronic.de
|Bemerkung=Haben auch einen PC Shop nebenan.
}}

===Wilhelmshaven===
{{ElektronikLieferant
|Firmenname=Reichelt Elektronik
|Straße=Elektronikring 1
|PLZ=26452
|Ort=Sande
|Telefon=04422-955 333
|Fax=04422-955 111
|Öffnungszeiten=Montag - Donnerstag: 9:00 - 17:00 Uhr; Freitag: 9:00 - 15:30 Uhr
|Weblink=http://www.reichelt.de
|Email=
|Bemerkung=
}}

==Nordrhein-Westfalen==
===Aachen===
'''Firma AG-Elektronik
Kontakt Hirschgraben 9-11;52062 Aachen
Telefon: 0241-25226
http://www.agelektronik.de
Öffnungszeiten Mo-Fr 10:00 bis 18.30 Sa 10:00-14:00.'''
Übernommen aus [http://aachen.wikia.com/wiki/Elektronik-Teile http://aachen.wikia.com/wiki/Elektronik-Teile]. Die Liste dort ist größer.
* TH-Elektronic, Karlsgraben 47, 52062 Aachen, Tel: 404593, Fax: 404594, http://www.th-electronic.de/ Öffnungszeiten Mo-Fr 9-19:30 Sa 9-16 Uhr
* AG Elektronik, Hirschgraben 9-11, 52062 Aachen,Tel.:0241-25226 http://www.agelektronik.de/(Sehr freundlich und großes Sortiment, Werktags geöffnet Mo-Fr 10:00 bis 18.30 Sa 10:00-14:00.
* Helmut Singer Elektronik, Feldchen 16-24, D-52070 Aachen. http://www.singer-elektronik.de/ (Gebrauchte Messgeräte)

'''Nähere Umgebung:'''
* Fleu Elektronik, Kantgasse 26, 52477 Alsdorf, Tel. 02404/22240, ubestätigt: Öffnungszeiten Mo - Fr. von 09 - 12 und 15 - 19 Uhr.
* Zilles Elektronik GmbH, Bauelemente für die Elektronik, Aachener Str. 415, 41069 Mönchengladbach, Tel: 02161-176005

===Bielefeld===
{{ElektronikLieferant
|Firmenname=alpha electronic Ing. A. Berger GmbH
|Straße=Oldentruper Str. 104
|PLZ=33604
|Ort=Bielefeld
|Telefon=0521-324333
|Fax=0521-320435
|Öffnungszeiten=Mo. – Sa. 9.00 – 13.00 Uhr Mo. – Fr. 14.00 – 18.00 Uhr
|Weblink=http://www.alphaelectronic.de/
|Email=info@alphaelectronic.de
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Fuchs und Lützow Elekronik - Handelsges. mbH
|Straße=Heeper Str. 184
|PLZ=33607
|Ort=Bielefeld
|Telefon=0521-5576555
|Fax=0521-5576557
|Öffnungszeiten=Mo. – Sa. 9.00 – 13.00 Uhr Mo. – Fr. 14.00 – 18.00 Uhr
|Weblink=http://www.electronicfuchs.com/
|Email=info@electronicfuchs.com
|Bemerkung=
}}

===Bochum===
{{ElektronikLieferant
|Firmenname=Schmitt Elektronik
|Straße=Dorstener Straße 18-20
|PLZ=44787
|Ort=Bochum
|Telefon=0234 9620130
|Fax=0234 9629132
|Öffnungszeiten=Mo - Fr 09:00 - 18:00, Sa 09:00 - 14:00
|Weblink=http://www.elektronik-wunderland.de
|Email=
|Bemerkung=Alteingesessener laden, hat viel seltenes zeug aus den 70-90ern, sortiment an modernen bauteilen wie AVR eher gering. Sehr zu empfehlen.
}}

===Bonn===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Karlstraße 3
|PLZ=53115
|Ort=Bonn
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Sa. 10.00-20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-bonn.html
|Email=filiale.bonn@conrad.de
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=CSD-Electronics
|Straße=Bunsenstraße 3
|PLZ=53121
|Ort=Bonn
|Telefon=0228 85041574
|Fax=0228 85041600
|Öffnungszeiten=Mo-Do 10-12 und 14-17 Uhr Fr 10-12 und 14-16 Uhr. Andere Uhrzeiten? Anrufen!
|Weblink=http://www.csd-electronics.de/?pk_campaign=micro_locale
|Email=support@csd-electronics.de
|Bemerkung=Artikel können online bestellt und im Laden abgeholt werden
}}

{{ElektronikLieferant
|Firmenname=P & M Elektronik Bonn GmbH
|Straße=Budapester Straße 6
|PLZ=53111
|Ort=Bonn
|Telefon=0228-656005
|Fax=0228-656336
|Öffnungszeiten=Mo-Fr 09:00 – 19:00 Uhr Sa 10:00 – 16:00 Uhr
|Weblink=http://www.pm-elektronik-bonn.de/
|Email=pm-elektronikbonn@web.de
|Bemerkung=
}}

===Dortmund===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Westenhellweg 95-101
|PLZ=44137
|Ort=Dortmund
|Telefon=01805-564445
|Fax=
|Öffnungszeiten=Mo. – Fr. 10.00 – 20.00 Uhr Sa. 9.30 – 20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-dortmund.html
|Email=
|Bemerkung=direkt in der Innenstadt
}}

{{ElektronikLieferant
|Firmenname=SR-Tronic
|Straße=Beratgerstr. 28
|PLZ=44149
|Ort=Dortmund
|Telefon=0231-33671-0
|Fax=0231-33671-25
|Öffnungszeiten=Mo. – Fr. 10.00 – 18.00 Uhr
|Weblink=http://www.sr-tronic.de
|Email=info@sr-tronic.de
|Bemerkung=Ist zwar ein Versandhandel, Abholung ist aber möglich, extrem kleines Elektroniksortiment (Atmel, Eproms), ist eigentlich ein Satshop. Hat bereits Insolvenz angemeldet.
}}



=== Duisburg ===

{{ElektronikLieferant
|Firmenname=Elektro Urban
|Kurfürstenstr. 151
|46147 Oberhausen / Holten
|Telefon 0208 62 12 88
|Weblink=http://www.elur.de/
|Bemerkung= Verzogen nach Oberhausen, Kurfürstenstrasse. Siehe dort.
}}

=== Düsseldorf ===

{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Oststraße 34
|PLZ=40211
|Ort=Düsseldorf
|Telefon=0211 - 38 83 76 - 0
|Fax=0211 - 38 83 76 - 14
|Öffnungszeiten=Mo.-Sa. 10:00-19:30 Uhr
|Email=filiale.duesseldorf@conrad.de
|Weblink=https://www.conrad.de/de/filialen/filiale-duesseldorf.html
|Bemerkung=
}}

===Emsdetten===
{{ElektronikLieferant
|Firmenname=Elektronik-Shop Emsdetten
|Straße=Borghorster Str. 28
|PLZ=48282
|Ort=Emsdetten
|Telefon=02572-83546
|Fax=02572-9606299
|Öffnungszeiten=Mo: 14:30 - 18:00 Uhr, Di - Fr: 9:00 - 12:30 und 14:30 - 18:00 Uhr, Sa: 9:00 - 12:30 Uhr
|Weblink=http://www.elektronik-shop-emsdetten.de/
|Email=info@elektronik-shop-emsdetten.de
}}

===Essen===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Altendorfer Str. 11
|PLZ=45127
|Ort=Essen
|Telefon=01805-564445
|Fax=
|Öffnungszeiten=Mo. – Fr. 10.00 – 19.30 Uhr Sa. 9.30 – 18.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-essen.html
|Email=filiale.essen@conrad.de
|Bemerkung=schräg gegenüber von IKEA, Tiefgarage im UG für Kunden kostenlos, Karte an der Kasse lochen lassen
}}

===Geldern===
{{ElektronikLieferant
|Firmenname=BSAB-Elektronik Strulik & Bosch GmbH
|Straße=Zeppelinstr. 8
|PLZ=47608
|Ort=Geldern
|Telefon=02831/12051
|Fax=02831/2437
|Öffnungszeiten=Mo. – Fr. 8.00 – 17.00 Uhr
|Weblink=http://www.bsab-elektronik.de/
|Email=
|Bemerkung=
}}

===Iserlohn===

{{ElektronikLieferant
|Firmenname=Techno-Center-Schmitt
|Straße=Raiffeisenstr. 14
|PLZ=58638
|Ort=Iserlohn
|Telefon=02371/2197931
|Fax=
|Öffnungszeiten=Mo.–Fr. von 10:00 – 18:00 Uhr Sa. von 10:00 – 14:00 Uhr
|Weblink=
|Email=
|Bemerkung=
}}

===Köln===
{{ElektronikLieferant
|Firmenname=M. + M. van der Meyden GmbH
|Straße=Breite Straße 101
|PLZ=50667
|Ort=Köln
|Telefon=0221/2576369
|Fax=0221/2576369
|Öffnungszeiten=Mo.–Fr. von 9:30 – 19:00 Uhr Sa. von 10:00 – 16:30 Uhr
|Weblink=http://vandermeyden.de
|Email=http://vandermeyden.de/?page_id=13
|Bemerkung=Sehr teuer (Standard Quarz HC49/S --> 1,50€); Muss manche µCs extra bestellen, die gängigsten AVR-Typen in DIP jedoch auf Lager
}}
 

===Düren===
{{ElektronikLieferant
|Firmenname=Hallmanns Elektronik
|Straße=Weierstraße 41
|PLZ=52349
|Ort=Düren
|Telefon=02421 16635
|Fax=
|Öffnungszeiten=Mo.-Fr.: 09:00-18:00 Uhr Sa: 09:00 - 13:00 Uhr
|Weblink=http://www.hallmanns.com
|Email=info@hallmanns.com
|Bemerkung=
}}
 

===Bergisch Gladbach===
{{ElektronikLieferant
|Firmenname=MS-Elektronik
|Straße=Laurentiusstraße 20
|PLZ=51465
|Ort=Bergisch Gladbach
|Telefon=02202 - 93 22 17
|Fax=02202 - 93 22 18
|Öffnungszeiten=Mo.-Fr.: 09:00-12:30 & 14:30 - 18:30 Uhr Sa: 09:00 - 14:00 Uhr
|Weblink=http://www.ms-elektronik.info/
|Email=info@ms-elektronik.info
|Bemerkung= Auch Versand. Macht leider nichts mehr im Bereich Modellbau.
}}

{{ElektronikLieferant
|Firmenname=DARISUS GmbH
|Straße= De-Gasperi-Straße 8
|PLZ=51429
|Ort=Bergisch Gladbach
|Telefon=02204 - 98 18 11
|Fax=
|Öffnungszeiten=
|Weblink=https://darisusgmbh.de
|Email=
|Bemerkung=Nur Abholung von vorher online bestellten Teilen. Telefonisch 0 Erreichbarkeit.
}}

===Langenfeld===
{{ElektronikLieferant
|Firmenname=rs elektronik - Reinhard Sinzel
|Straße=in den Weiden 19
|PLZ=40764
|Ort=Langenfeld
|Telefon=02173/22766
|Fax=02173/25958
|Öffnungszeiten=Mo-Fr 10:00-13:00 + 15:00-18:00, Sa 10:00-13:00
|Weblink=
|Email=
|Bemerkung=
}}

===Moers===
{{ElektronikLieferant
|Firmenname=Nürnberg Electronic
|Straße=Uerdinger Str. 121
|PLZ=47441
|Ort=Moers
|Telefon=02841-32221
|Fax=02841-31733
|Öffnungszeiten=Mo.- Fr. 9:00 - 13:00 und 14:00 - 18:00 Samstag 9:00 - 13:00 Mittwoch Nachmittag geschlossen!
|Weblink=http://www.nuernberg-electronic.de/
|Email=
|Bemerkung=
}}

===Mönchengladbach===
{{ElektronikLieferant
|Firmenname=Brunenberg Elektronik
|Straße=Lürriper Straße 170
|PLZ=41065
|Ort=Mönchengladbach
|Telefon=02161-44421
|Fax=02161-42552
|Öffnungszeiten=Mo.- Fr. 9:00 - 13:00 und 14:00 - 18:00 Samstag 9:00 - 13:00 Donnerstag Nachmittag geschlossen!
|Weblink=http://www.bruntronic.de
|Email=info@bruntronic.de
|Bemerkung=Das Ladengeschäft wurde geschlossen!
}}

{{ElektronikLieferant
|Firmenname=Zilles Elektronik GmbH
|Straße=Aachener Str. 415
|PLZ=41069
|Ort=Mönchengladbach
|Telefon=02161/176005
|Fax=02161/176007
|Öffnungszeiten=Montag - Freitag 8:45 - 13:00 & 14:00 - 18:00 Samstag 9:30 - 13:00
|Weblink=http://www.zilles-elektronik.de/
|Email=info@zilles-elektronik.de
|Bemerkung=
}}

===Monheim am Rhein===

{{ElektronikLieferant
|Firmenname=Schukat electronic Vertriebs GmbH
|Straße=Daimlerstraße 26
|PLZ=40789
|Ort=Monheim am Rhein
|Telefon=02173 - 950-5
|Fax=02173 - 950-999
|Öffnungszeiten=montags bis freitags zwischen 8 Uhr und 18 Uhr
|Weblink=http://www.schukat.com
|Email=info@schukat.com
|Internet: www.schukat.com
|Bemerkung=nur Gewerblich Teile können nach Vorbestellung auch abgeholt werden !
}}

===Münster===
{{ElektronikLieferant
|Firmenname=Omega electronic GmbH
|Straße=Salzstraße 35
|PLZ=48143
|Ort=Münster
|Telefon=Tel:0251-3844540
|Fax= 0251-38445414
|Öffnungszeiten=Mo. – Sa. 10.00 – 19.30 Uhr
|Weblink=http://www.omega.ms/
|Email=info@omega.ms
|Bemerkung=Neu in Münster und sehr nah am Hauptbahnhof.
}}

=== Oberhausen ===

{{ElektronikLieferant
|Firmenname=KDH-ELEKTRONIK Klaus-Dieter Hösterey
|Straße=Kurfürstenstr. 151
|PLZ=46147
|Ort=Oberhausen-Holten
|Telefon=0208-63547742
|Fax=0208-63547744
|Öffnungszeiten=Mo–Fr 09:00–13:00 Uhr // 15:00-18:00 Uhr, Samstags 10:00-13:00 Uhr
|Email=kdh-elektronik@t-online.de
|Weblink=http://www.kdh-elektronik-oberhausen.de/
|Bemerkung= vormals Eduard Urban Elektronik Duisburg http://www.openstreetmap.de/karte.html?zoom=18&lat=51.51577&lon=6.79613&layers=B000TT
}}

===Paderborn===
Keine mehr

===Recklinghausen===
{{ElektronikLieferant
|Firmenname=Elektronik-Center Wenzlik, Inh. H.- J. Juhnke
|Straße=Halterner Straße 24
|PLZ=45657
|Ort=Recklinghausen
|Telefon=02361-14103
|Fax=02361-182489
|Öffnungszeiten=Mo.-Fr.: 9.00h-13.00h u. 14.30h-18.30h, Sa.: 10.00h-13.00h geöffnet!
|Weblink=http://www.ju-tec.de
|Email=ecw-recklinghausen@t-online.de
|Bemerkung= Elektronik Einzelhandel 35.000 verschiedene Artikel vorrätig.
}}

===Siegen===
{{ElektronikLieferant
|Firmenname=Radig Hard & Software, Inh. U. Radig
|Straße=An der Bahn 18
|PLZ=57223
|Ort=Kreuztal
|Telefon=02732-762442
|Fax=02732-762443
|Öffnungszeiten=Nach Vereinbahrung
|Weblink=http://www.ulrichradig.de
|Email=mail@ulrichradig.de
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=RME-Service
|Straße=Lärchenhof 1
|PLZ=57223
|Ort=Kreuztal
|Telefon=02732-582170
|Fax=02732-582171
|Öffnungszeiten=Do/Fr 09:00-18.00, Sa nach Vereinbahrung
|Weblink=http://www.rme-service.de/
|Email=
|Bemerkung=
}}

===Wuppertal===
{{ElektronikLieferant
|Firmenname=WE elektronik
|Straße=Sedanstraße 88
|PLZ=42281
|Ort=Wuppertal
|Telefon=0202-510444
|Fax=0202-510666
|Öffnungszeiten=Mo.- Fr. 9.00 - 18.00
|Weblink=http://www.we-wuppertal.de/
|Email=info@we-wuppertal.de
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=K&K Elektronic
|Straße=Höhne 33
|PLZ=42275
|Ort=Wuppertal
|Telefon=0202
|Fax=0202
|Öffnungszeiten=
|Weblink=
|Email=
|Bemerkung=
}}

==Rheinland-Pfalz==
===Andernach===
{{ElektronikLieferant
|Firmenname=EDV + Elektronic Systeme Manuel Zitzer e.K.
|Straße=Füllscheuer 30
|PLZ=56626
|Ort=Andernach
|Telefon=02632/9293-0
|Fax=02632/9293-33
|Öffnungszeiten=Montag-Freitag 8:00 Uhr - 12:00 Uhr und 14:00 Uhr - 18:00 Uhr, Dienstag zusätzlich bis 19:00 Uhr, Samstag geschlossen
----

|Weblink=http://www.eleksys.de/
|Email=info@eleksys.de

----

|Bemerkung=
}}

===Kaiserslautern===
{{ElektronikLieferant
|Firmenname=BURCKHARDT-ELEKTRONIK
|Straße=Waldstr. 17
|PLZ=67659
|Ort=Kaiserslautern
|Telefon=+49 (0)631 70114
|Fax=49 (0)631 70162
|Öffnungszeiten=Montag-Donnerstag 8:00 Uhr - 16:45 Uhr/Freitag 8:00 Uhr - 12:00 Uhr
|Weblink=http://www.burckhardt-elektronik.de
|Email=burckhardt-elektronik@web.de
|Bemerkung=
}}

===Koblenz===
{{ElektronikLieferant
|Firmenname=Radio Erbar
|Straße=Bahnhofstr. 40
|PLZ=56068
|Ort=Koblenz
|Telefon=0261/34782
|Fax=0261/14570
|Öffnungszeiten=Montag-Freitag 9:00 Uhr - 18:00 Uhr/Samstag 9:00 Uhr - 12:00 Uhr
|Weblink=http://www.radio-erbar.de/
|Email=webmaster@radio-erbar.de
|Bemerkung= Achtung, Elektronik-Shop für immer geschlossen. Nur noch Veranstaltungstechnik
}}

===Mainz===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Binger Str. 14-16 (nähe Hauptbahnhof)
|PLZ=55122
|Ort=Mainz
|Telefon=0180 5312111
|Fax=
|Öffnungszeiten=Mo - Sa 9.30 Uhr - 19.30 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-mainz.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Elektronik Schmidt
|Straße=Boppstraße 62 - 64
|PLZ=55118
|Ort=Mainz
|Telefon=0180 5312111
|Fax=
|Öffnungszeiten=Montag - Freitag 09.00 Uhr - 13.00 Uhr und 14.00 Uhr - 18.00 Uhr 
Samstag 09.00 Uhr - 13.00 Uhr
|Weblink=http://www.schmidt-electronic.de
|Email=
|Bemerkung=
}}

==Saarland==
=== Dillingen ===
{{ElektronikLieferant
|Firmenname=Lutwin Bosch Elektronik
|Straße=Weinligstr.38
|PLZ=66763|Ort=Dillingen|Telefon=+49 (6831) 77165
|Fax= +49 (6831) 704302
|Öffnungszeiten= Mo+Di Do+Fr 8:00-12:00 Uhr / 14:00-17:00 Uhr
|Weblink=
|Email=
|Bemerkung=Handel mit elektronischen Bauteilen und Komponenten auch Privatverkauf.
}}

=== Saarbrücken ===
{{ElektronikLieferant
|Firmenname=ESS Elektronik Service Skowronek
|Straße=Peter-Zimmer-Str. 13
|PLZ=66123
|Ort=Saarbrücken
|Telefon=+49 (681) 816414
|Fax= +49 (681) 816992
|Öffnungszeiten= Mo-Fr 8:00-12:00 Uhr / 14:00-18:00 Uhr
|Weblink=
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Trierer Straße 16-20
|PLZ=66111
|Ort=Saarbrücken
|Telefon=0180 5 564445 (derzeit 14 Cent/Min. aus dem Festnetz der Dt. Telekom. Evtl. abweichende Preise für Anrufe aus den Mobilfunknetzen.)
|Fax=
|Öffnungszeiten= Mo.-Sa. 10.00-19.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filial-saarbruecken.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=EXP Tech GmbH
|Straße=Meerwiesertalweg 23
|PLZ=66123
|Ort=Saarbrücken
|Telefon=+49 (681) 95819340
|Fax= +49 (681) 954176-19
|Öffnungszeiten=
|Weblink= http://www.exp-tech.de
|Email=
|Bemerkung= Online Verkauf, Abholung vor Ort möglich
}}

==Sachsen==
===Chemnitz===
{{ElektronikLieferant
|Firmenname=mükra electronic shop GmbH
|Straße=Reichsstraße 58
|PLZ=09113
|Ort=Chemnitz
|Telefon=0371/365736
|Fax=0371/365736
|Öffnungszeiten=Mo.-Fr. 10.00 Uhr - 18.00 Uhr Sa. 10.00 Uhr - 13.00 Uhr
|Weblink=http://www.muekra.com/filiale_chemnitz.html
|Email=
|Bemerkung=gut sortiert aber keine SMD BE | wirkt manchmal recht unfreundlich und demotiviert
}}

{{ElektronikLieferant
|Firmenname=köhler-elektronik Firma Michael Köhler
|Straße=Erfenschlager Straße 31
|PLZ=09125
|Ort=Chemnitz
|Telefon=(03 71) 51 91 03
|Fax=(03 71) 51 91 04
|Öffnungszeiten=Mo.-Fr. von 9 - 18 Uhr
|Weblink=http://www.koehler-elektronik.de
|Email=
|Bemerkung=
}}

===Dresden===
{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Friedrich-List-Platz 2 gegenüber Hauptbahnhof
|PLZ=01069
|Ort=Dresden
|Telefon=
|Fax=
|Öffnungszeiten=Mo.-Sa. 10.00-20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-dresden.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Sullus
|Straße=Tharandter Str. 67
|PLZ=01187
|Ort=Dresden
|Telefon=0351 4112100
|Fax=0351 4112146
|Öffnungszeiten=Mo.-Fr. 10.00-18.30 Uhr, Sa. 09.00-12.00 Uhr
|Weblink=http://www.sullus.de/
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Elektronic-Shop Meissen Rainer Pötzsch
|Straße=Neugasse 34
|PLZ=01662
|Ort=Meissen
|Telefon= +49 3521 452301
|Fax= +49 3521 452399
|Öffnungszeiten=Mo.-Fr. von 9 - 19 Uhr Sa. von 9 - 32 Uhr
|Weblink=http://www.electronic-poetzsch.de
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=ANVILEX GmbH
|Straße=Enderstrasse 94 Gebäude C, 1.OG
|PLZ=01277
|Ort=Dresden
|Telefon=+49 351 40945521
|Fax=+49 351 40945524
|Öffnungszeiten=
|Weblink=http://shop.anvilex.de
|Email=information@anvilex.de
|Bemerkung=
}}

===Leipzig===
{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Neumarkt 20
|PLZ=04109
|Ort=Leipzig
|Telefon=
|Fax=
|Öffnungszeiten=Mo.-Sa. 10.00-20.00 Uhr
|Weblink=https://www.conrad.de/de/filialen/filiale-leipzig.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=ELMICRO Computer GmbH & Co. KG
|Straße=Hohe Str. 9-13
|PLZ=04107
|Ort=Leipzig
|Telefon=+49-(0)341-9104810
|Fax=+49-(0)341-9104818
|Öffnungszeiten=Mo.-Sa.: 09.00-17.00 Uhr
|Weblink=http://elmicro.com/de/ela-leipzig.html
|Email=leipzig|at|elmicro.com
|Bemerkung=Besucher werden gebeten, sich kurzfristig telefonisch anzumelden.
}}

===Zwickau===
{{ElektronikLieferant
|Firmenname=Elektronik Neumerkel GmbH
|Straße=Kolpingstraße 20
|PLZ=08058
|Ort=Zwickau
|Telefon=+ 49 (0)375-589920
|Fax=+ 49 (0)375-5899222
|Öffnungszeiten=Mo. - Fr. 9:00 - 18:00 Uhr, Sa. 9:00 - 12:30 Uhr
|Weblink=http://www.neumerkel.de
|Email=info@neumerkel.de
|Bemerkung=
}}

==Sachsen-Anhalt==
===Magdeburg===
{{ElektronikLieferant
|Firmenname=mittrenga electronic
|Straße=Maxim-Gorki-Str. 34
|PLZ=39108
|Ort=Magdeburg
|Telefon=0391/7333500
|Fax=0391/7346538
|Öffnungszeiten= Dauerhaft geschlossen
|Weblink=
|Email=
|Bemerkung=Keine Microcontroller
}}
Habe heute versucht den Shop persönlich zu erreichen.
Leider war der Shop nicht mehr da.
Die Telefonnummer ist auch nicht erreichbar.
Der Inhaber ist verstorben. Leider.

===Halle (Saale)===
{{ElektronikLieferant
|Firmenname=Funkhaus Alter Markt
|Straße=Alter Markt 6
|PLZ=06108
|Ort=Halle
|Telefon=0345/2831651
|Fax=0345/2831651
|Öffnungszeiten=Mo bis Fr
|Weblink=http://www.fernsehklinik-halle.de/
|Email=Service@Fernsehklinik-Halle.de
|Bemerkung=elektronische Bauteile aller Art gut sortiert auf Lager. Nach Möglichkeit vorher telefonisch nachfragen(!), damit das Teil aus dem Lager geholt werden kann, insgesamt vergleichsweise teuer, ansonsten recht unkompliziert
}}

{{ElektronikLieferant
|Firmenname=Westfalia
|Straße=Grenzstraße 35
|PLZ=06112
|Ort=Halle
|Telefon=0345 560 62 31
|Fax=0345 560 62 32
|Öffnungszeiten=
Montag - Mittwoch 08.00 - 18.30

Donnerstag 08.00 - 19.00

Freitag 08.00 - 18.30

Samstag 08.30 - 13.30

|Weblink=
|Email=
|Bemerkung=Elektronikmäßig relativ klein sortiert, keine einzelnen Bauelemente, dafür Restposten-/Sortimentebeutel mit jeweils verschiedenen Widerständen, Kondensatoren, Transistoren, LEDs etc.
Ferner Platinen, vereinzelt Trafos, jede Menge Bausätze, Lötzubehör, Lautsprecher, Stecker, Buchsen und Kabel aller Art, Gehäuse
}}

==Schleswig Holstein==
===Kiel===
{{ElektronikLieferant
|Firmenname=Elektronik Schmidt Inh. Karl Heinz Parting
|Straße=Adelheidstr. 28
|PLZ=24103
|Ort=Kiel
|Telefon=0431 94682
|Fax=0431 92574
|Öffnungszeiten=
|Weblink=
|Email=
|Bemerkung= viele historische Bauteile verfügbar, Röhren, hat leider Ende 2015 den Laden geschlossen!
}}

===Lübeck===
{{ElektronikLieferant
|Firmenname=Lenzner Jürgen Elektronik GmbH - seit 2016 geschlossen !
|Straße=Krähenstraße 19
|PLZ=23552
|Ort=Lübeck
|Telefon=0451 77336
|Fax=
|Öffnungszeiten=
|Weblink=
|Email=
|Bemerkung= keine uC, teils historische Bauteile verfügbar, Röhren, LEDs überteuert
}}

===Schwentinental===
{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Mergenthalerstr. 22
|PLZ=24223
|Ort=Schwentinental, OT Raisdorf
|Telefon=0180 5 564445
|Fax=
|Öffnungszeiten=Mo.-Fr. 10.00-19.00 Uhr, Sa. 10.00-18.00 Uhr
|Weblink=http://www.conrad.de
|Email=
|Bemerkung=bei Kiel
}}

==Thüringen==

===Erfurt===
{{ElektronikLieferant
|Firmenname=Thiemann-Elektronik
|Straße=Schmidtstedter Str. 12
|PLZ=99084
|Ort=Erfurt
|Telefon=0361/21697687
|Fax=0361/21697688
|Öffnungszeiten=Mo-Fr 09.30-13.00 und 14.00-18.30, Sa 10.00-13.00
|Weblink=http://www.thiemann-elektronik.de
|Email=info@thiemann-elektronik.de
|Bemerkung=Nähe Hauptbahnhof 
}}

===Jena===
{{ElektronikLieferant
|Firmenname=Stefan Schmutzer VAT Elektronik
|Straße=Bachstraße 10
|PLZ=07743
|Ort=Jena
|Telefon= (03641)447184
|Fax=
|Öffnungszeiten= Mo-Fr. bis 18:00Uhr. Sa zu
|Weblink=
|Email=
|Bemerkung= reichlich teuer. Für einzelne Kleinteile jedoch definitiv zu empfehlen, wenn man nicht gleich bestellen will
}}

===Gera===
{{ElektronikLieferant
|Firmenname= Neumerkel Elektronik
|Straße=Karl-Schurz-Straße 12
|PLZ=07545
|Ort=Gera
|Telefon= +49 (0) 3 65 - 82 46 90
|Fax= +49 (0) 3 65 - 82 46 922
|Öffnungszeiten= Mo-Fr. 9.00 bis 18:00Uhr. Sa 9.00 bis 12.00
|Weblink= http://www.neumerkel.de/gera.htm
|Email=
|Bemerkung=
}}

=Österreich=
==Linz==
{{ElektronikLieferant
|Firmenname=Aigner Elektronik
|Straße=Dinghoferstr. 63
|PLZ=A-4020
|Ort=Linz
|Telefon=+43 732 669691-0
|Fax=+43 732 669691-15
|Öffnungszeiten=Mo. bis Fr. 8:30 bis 17:00 (keine Mittagssperre), Samstag 8:30 bis 12:00
|Weblink=http://www.aigner.co.at/
|Email=
|Bemerkung= September 2014: Geschäft aufgelassen !!
}}

{{ElektronikLieferant
|Firmenname=Conrad Electronic
|Straße=Kornstraße 4
|PLZ=A-4060
|Ort=Linz / Leonding
|Telefon=+43 732 683040-0
|Fax=+43 732 683040-13
|Öffnungszeiten=Mo. bis Fr. 9:00 bis 18:30, Samstab 9:00 bis 17:00
|Weblink=https://www.conrad.at/de/stores/linz.html
|Email=mailto://filiale.linz@conrad.at
|Bemerkung=
}}

==Graz==
{{ElektronikLieferant
|Firmenname=Neuhold Elektronik
|Straße=Griesplatz 1
|PLZ=A-8020
|Ort=Graz
|Telefon=+43 (0) 316 711245
|Fax=+43 (0) 316 717419
|Öffnungszeiten=Montag bis Freitag von 9.00 - 18.00 Uhr Samstag 9.00-12.30 Uhr
|Weblink=http://www.neuhold-elektronik.at/
|Email=
|Bemerkung=Großes Sortiment mit auch sehr ausgefallenen Artikeln. Führt eine breite Produktpalette. Durchweg sehr günstige Preise, jedoch manchmal bei Standardbauteilen (Mikrocontrollern z.B. AVRs) teurer als die Konkurrenz. Vergleichbar mit Pollin.
}}

{{ElektronikLieferant
|Firmenname=L-Tronik Austria
|Straße=Karlauerstraße 5
|PLZ=A-8020
|Ort=Graz
|Telefon=Tel: +43 (0) 316 904 672
|Fax=
|Öffnungszeiten=Montag bis Freitag von 9.00 - 17.00 Uhr Samstag 9.00-12.00 Uhr
|Weblink=http://www.l-tronik.com/index.php
|Email=info@lta.at
|Bemerkung=Riesiges Sortiment an Halbleitern (Auch SMD). Solartechnik, Sicherheitstechnik, Haustechnik u.s.w..
}}

{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Weblinger Gürtel 25
|PLZ=A-8054
|Ort=Graz
|Telefon=Tel: +43 (0) 50 - 20 40 73 00
|Fax=
|Öffnungszeiten=Montag bis Freitag von 9.00 - 19.30 Uhr Samstag 9.00 - 18.00 Uhr
|Weblink=https://www.conrad.at/de/stores/graz.html
|Email=filiale.graz@conrad.at
|Bemerkung=
}}

==Salzburg==
{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Alpenstraße 95 - 97
|PLZ=5020
|Ort=Salzburg
|Telefon=050 - 20 40 81 00
|Fax=
|Öffnungszeiten=Mo.-Fr. 9.30-18.30 Uhr Sa. 9.30-17.30 Uhr
|Weblink=https://www.conrad.at/de/stores/salzburg.html
|Email=
|Bemerkung=
}}

==Wien==
{{ElektronikLieferant
|Firmenname=Semaf Electronics
|Straße=Alserbachstraße 10
|PLZ=1090
|Ort=Wien
|Telefon=+43 1 276 4008
|Fax=+43 1 276 4008
|Öffnungszeiten=Mo.-Do. 10.00-18.00 Uhr Fr. 10.00-12.30 und 14.30-18.00 Uhr Sa. 10.00-12.00 Uhr
|Weblink=http://electronics.semaf.at
|Email=electronics [at] semaf.at
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Technotronic
|Straße=Laxenburger Straße 74
|PLZ=1100
|Ort=Wien
|Telefon=+43 1 6029525
|Fax=+43 1 6064794
|Öffnungszeiten=Mo.-Fr. 9.00-12.30 und 13.30-18.00 Uhr
|Weblink=
|Email=technotronic1100@gmail.com
|Bemerkung=alle anderen Filialen (Zieglergasse, Floridsdorfer Hauptstraße) mittlerweile geschlossen
}}

{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Hütteldorfer Straße 81b (Meiselmarkt U3 Johnstrasse)
|PLZ=1150
|Ort=Wien
|Telefon=050 - 20 40 75 00
|Fax=
|Öffnungszeiten=Mo.-Fr. 9.00-19.00 Uhr Sa. 9.00-18.00 Uhr
|Weblink=https://www.conrad.at/de/stores/wien-meiselmarkt.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Gewerbeparkstraße 12 (Gewerbepark Stadlau)
|PLZ=1220
|Ort=Wien
|Telefon=050 - 20 40 72 00
|Fax=
|Öffnungszeiten=Mo.-Fr. 9.00-18.30 Uhr Sa. 9.00-18.00 Uhr
|Weblink=https://www.conrad.at/de/stores/wien-stadlau.html
|Email=
|Bemerkung=
}}

{{ElektronikLieferant
|Firmenname=Conrad
|Straße=Nordring 2
|PLZ=2334
|Ort=Vösendorf/Süd
|Telefon=050 - 20 40 71 00
|Fax=
|Öffnungszeiten=Mo.-Fr. 9.30-18.30 Uhr Sa. 9.00-17.30 Uhr
|Weblink=https://www.conrad.at/de/stores/scs-voesendorf.html
|Email=
|Bemerkung=
}}

=Schweiz=
----
== Basel-Landschaft (BL) ==
=== 4450 Sissach ===
{{ElektronikLieferant
|Firmenname=Grieder Elektronik Bauteile AG
|Straße=Reuslistrasse 62
|PLZ=4450
|Ort=Sissach
|Telefon=061 976 95 95
|Fax=061 976 95 90
|Öffnungszeiten=Mo-Do 800-1200, 1300-1600 und Fr 800-1200, 1300-1500.
|Weblink=http://shop.griederbauteile.ch/
|Email=info@griederbauteile.ch
|Bemerkung=Mindestbestellwert CHF 20. Vorbestellte Waren können abgeholt werden. Der "Laden" befindet sich 10 Minuten zu Fuss vom Bahnhof Sissach.

}}
== Bern (BE) ==
=== 2560 Nidau ===
{{ElektronikLieferant
|Firmenname=Redacom AG / thinkembedded.ch Web Shop
|Straße=Hauptstrasse 96
|PLZ=2560
|Ort=Nidau
|Telefon=+41 32 332 99 55
|Fax=+41 32 332 99 59
|Öffnungszeiten=
|Weblink =http://redacom.ch/ Shop: http://thinkembedded.ch/
|Email=order@redacom.ch
|Bemerkung=Bestellungen im Onlineshop können wahlweise versendet oder abgeholt werden.
'''Sortiment:''' Diverse Microcontroller Boards, Debugger, Programmer und USB-Messinstrumente
}}

== Luzern (LU) ==
=== Emmenbrücke ===
{{ElektronikLieferant
|Firmenname=Conrad Electronic Schweiz
|Straße=Seetalstrasse 11
|PLZ=6020
|Ort=Emmenbrücke
|Telefon=0848/80 12 83
|Fax=041/267 32 14
|Öffnungszeiten=Mo/Di/Do 09:00-18:30, Mi/Fr 09:00-21:00, Sa 08:00-16:00 Uhr
|Weblink=http://www.conrad.ch/ce/de/content/filiale_emmenbruecke/
|Email=filiale.emmenbruecke@conrad.ch
|Bemerkung=5 Minuten vom Bahnhof Emmenbrücke GRATIS Parkhaus & Parkplätze
}}

== Solothurn (SO) ==
===5014 Gretzenbach===
{{ElektronikLieferant
|Firmenname=EFG Electronic AG
|Straße=Köllikerstrasse 32
|PLZ=5014
|Ort=Gretzenbach
|Telefon= 062 849 23 61
|Fax= 062 849 23 70
|Öffnungszeiten=
Mo-Fr 08:30-11:30, 13:30-18:30, Mi geschlossen, Sa 09:00-16:00
|Weblink=http://www.maxland.ch/netmax/standseiten/efg/index.html
|Email=efgag@yetnet.ch
|Bemerkung=Kabel - Messgeräte - Lautsprecher - elektronische Bauteile
kein Versand, nur Ladengeschäft
}}

== Zürich (ZH) ==
===8004 Zürich===
{{ElektronikLieferant
|Firmenname=Pusterla Elektronik AG
|Straße=Hohlstrasse 52
|PLZ=8004
|Ort= Zürich
|Telefon=044 241 56 77
|Fax=044 242 01 04
|Öffnungszeiten=
Mo-Fr 09:00-18:30, Sa 09:00-16:00
|Weblink=http://www.pusterla.ch/
|Email=info@pusterla.ch
|Bemerkung=Absoluter "Kult-Laden" mit Tradition. Wer jemals in der Schweiz einen Lötkolben in der Hand hatte, der kennt "Pusti"

Das Sortiment ist zweigeteilt: 
'''hinter dem Tresen:''' 
gutes allgemeines Bauteilesortiment, spezielle Sachen werden bestellt.
 Man nimmt sich Zeit für Fachberatung - es wird auch schon mal ein Vergleichstyp aus der Liste gesucht und dem jungen "Case-Modder" wird mit Engelsgeduld erklärt wie man den Vorwiderstand für seine coole LED-Prozessorinnenbeleuchtung berechnet.

'''vor dem Tresen - Selbstbedienung:''' 
Am Eingang nimmt man sich eine Pappschale mit Bleistift und Notizblock.
Artikel, Menge und Preise schreibt man selbst auf!

Das Sortiment bietet einen Querschnitt durch die elektronische Bauteilefertigung der letzten 50 Jahre. Sehr gute Quelle für spannungsfeste Kondensatoren und hochohmige (Leistungs-)Widerstände sowie mechanischem "Klein-Grabbel-Kram." Gute Auswahl an Gehäusen, Transformatoren (z.T. recht schräge Typen) sowie Relais und Stecker/Buchsen die die Welt wohl niemals gebraucht hat. '''Vorsicht bei Elektrolytkondensatoren:''' "historische" Lagerware, besser man hat ein ESR-Meter dabei - sodenn man hat!
 Kabel jeglicher Art gibt es ab der Rolle zum Selberabschneiden - auch 10cm sind kein Problem - ausrechnen und aufschreiben machst Du ja selber.
 Präsentation der Ware im Selbsbedienungsteil:
 Bauteile offen oder ab Gurt in kleinen, liebevoll angeschriebenen Pappschachteln (noch von Vater Pusterla), grösseren Wühlschachteln, einer Wühlecke sowie hier und da einige Merkwürdigkeiten auf dem Fussboden.
Man stelle sich das Ladenlokal eines Joint-Ventures aus Oppermann, Pollin, dem ehem. Völkner sowie dem örtlichen Entsorgungshof vor - '''das''' ist "Pusti" und so war er schon immer! 

'''Fazit:''' absolut lohnenswert, auch wenn man vielleicht nicht immer das bekommt was man wollte, dafür findet man aber alles, wonach man nie gesucht hatte!
}}

===8092 Zürich===
{{ElektronikLieferant
|Firmenname="Bastli" Fachverein der Departemente Informationstechnologie und Elektrotechnik und Maschinenbau und Verfahrenstechnik an der ETH Zürich.
|Straße=Universitätsstrasse 19
|PLZ=8092
|Ort= Zürich
|Telefon= n/a
|Fax= n/a
|Öffnungszeiten=Die Öffnungszeiten gelten nur während des Semesters.
Mo 12:15 - 13:00 Uhr 
Do 12:15 - 13:00 Uhr 

|Weblink=http://www.bastli.ethz.ch/
|Email=bastli@amiv.ethz.ch
|Bemerkung=Studentischer "Bastel-Shop"
Während den Öffnungszeiten ist der Bastli-Shop im ersten Stock des UNG geöffnet.
Ihr könnt Bauteile, welche wir an Lager haben, kaufen und euch wird mit diversen elektronischen Problemen geholfen.

Organisierte Sammelbestellungen bei Fa. Reichelt / Deutschland

'''Standort:''' 

Bastli und Messplatz befinden sich in den Räumlichkeiten des AMIV im UNG Gebäude schräg gegenüber des CAB.
Es ist das gleiche Gebäude in dem auch der ehem. AMIV-Verlag respektive ehem. WBS respektive SPOD untergebracht ist.

Das Gebäude wirkt beim ersten Kontakt wohl für jeden neuen ein bisschen abschreckend. Aber keine Scheu, wenn man durch das etwas schlecht beleuchtete Treppenhaus in den ersten Stock gelangt, wendet man sich dort gleich nach rechts. Bastli und Messplatz haben die Zimmernummern C6 und C5.
}}

=== 8305 Dietlikon ===
{{ElektronikLieferant
|Firmenname=Conrad Electronic Schweiz
|Straße=Alte Dübendorferstrasse 17
|PLZ=8305
|Ort=Dietlikon
|Telefon=0848/80 12 84 (Normaltarif)
|Fax=044/805 35 14
|Öffnungszeiten=Mo-Sa 09:00-20:00 Uhr
|Weblink=http://www.conrad.ch/ce/de/content/filiale_dietlikon/
|Email=filiale.dietlikon@conrad.ch
|Bemerkung=5 Minuten vom Bahnhof Dietlikon Parkhaus & Parkplätze vorhanden
(Stand: 2012-08-27)
}}

=== 8606 Nänikon ===
{{ElektronikLieferant
|Firmenname=Distrelec Schweiz
|Straße=Grabenstrasse 6
|PLZ=8606
|Ort=Nänikon
|Telefon=044 - 944 99 11
|Fax=044 - 944 99 88
|Öffnungszeiten=Mo-Fr 07:30-18:00 Uhr (nur Abholschalter)
|Weblink=https://www.distrelec.ch
|Email=info@distrelec.com
|Bemerkung='''Abholschalter:''' (Vorbestellung unbedingt erforderlich)
Telefonisch oder online bestellte Ware kann nach ca. 2 Stunden abgeholt werden.
 Es kann auch direkt vor Ort ab Katalog bestellt werden, allerdings dann Wartezeit von min. 2 Stunden
 Bezahlung: bar/EC- und Post-Card
}}

== St. Gallen (SG) ==
=== 9443 Widnau ===
{{ElektronikLieferant
|Firmenname=Asif Elektronik
|Straße=Schützenstrasse 35
|PLZ=9443
|Ort=Widnau
|Telefon=071/722 01 57 (Normaltarif)
|Fax=071/588 02 58
|Öffnungszeiten=Mo-Fr 14:00-17:00 Uhr (Information und Support)
|Weblink=http://www.asif-elektronik.ch
|Email=sales@asif-elektronik.ch
|Bemerkung= Sprachen: Englisch und Deutsch.
 Online Geschäft. Lieferung per Post. Abholung nur nach Vereinbarung.
 Bezahlung: Überweisung/Paypal/Kreditkarte Gratis Versand ab 50 CHF.
}}

= Luxembourg =
=== L-1510 Luxembourg ===
{{ElektronikLieferant
|Firmenname=Schallllller Electronic S.à.r.l
|Straße=19, Av. de la Faïencerie
|PLZ=1510
|Ort=Luxembourg
|Telefon=+352-475239-1
|Fax=+352-471507
|Öffnungszeiten=Montag - Freitag: 08:30 - 12:30, 13:30 - 18:00 Samstag: 09:00 - 13:00
|Weblink=http://schaller-electronic.lu/index.php?home
|Email=
|Bemerkung=
}}

=== L-6905 Niederanven ===
{{ElektronikLieferant
|Firmenname=electronic-Shop S.àr.l.
|Straße=141, route de Trèves
|PLZ=6905
|Ort=Niederanven
|Telefon=+352 269464-1
|Fax=+352 269464-64
|Öffnungszeiten=
|Weblink=www.electronic-shop.lu
|Email=info@electronic-shop.lu
|Bemerkung=Online-Bestellungen, die ein paar Tage später an der Abholtheke abgeholt werden können.
}}

=Griechenland=
==Zentralmakedonien==
===Thessaloniki===
{{ElektronikLieferant
|Firmenname=Elektronika Vasileiades
|Straße=λαγκαδα 35 (βαρδαρης)
|PLZ=54629
|Ort=Thessaloniki
|Telefon=
|Fax=
|Öffnungszeiten=Mo.-Fr. 9:00-17:00 Sa. 9:00-14:00
|Weblink=http://www.elektronik.gr/
|Email=
|Bemerkung=
}}

= Türkei =
== Istanbul ==
=== Istanbul ===
{{ElektronikLieferant
|Firmenname= Ufuk Elektronik
|Straße=Yemişçi Hasan Sok. 1
|PLZ=
|Ort=
|Telefon=
|Fax=
|Öffnungszeiten= 
|Weblink=http://www.ufukelektronik.com/
|Email=
|Bemerkung= Im Gebiet des Fähranleger Karaköy gibt es einige Läden die Bauelemente anbieten. Der aufgeführte Laden wurde nur Beispielhaft aufgeführt.
}}

= Siehe auch =
* [[Platinenhersteller]]
* [[Elektronikversender]]
* [[Eisenwarenversender]]

[[Kategorie:Lieferanten]]

Implementierung einer Finite State Machine

2017-05-29T05:02:47Z

Newgeneration: Änderung 96434 von 46.161.9.20 (Diskussion) rückgängig gemacht.

#REDIRECT [[Statemachine#Implementierung einer objektorientiert Finite State Machine in C++]]

Sinusgenerator mit IIR-Filter

2017-05-29T05:02:11Z

Newgeneration: Änderung 96435 von 46.161.9.20 (Diskussion) rückgängig gemacht.

Ein Sinusgenerator wird heute in digitaler Technik üblicherweise nach dem [[DDS]]-Verfahren aufgebaut. [[Digitale_Sinusfunktion|Näherungsverfahren für den Sinus]] sind noch eine vergleichbare Alternative sowie das Glätten eines Rechtecks oder Dreieicks mit einer Kette aus IIR-Filtern. Allen gemein ist eine Vorgabe der Frequenz in Form einer äusseren Anregung.

== Funktionsübersicht==
Weniger bekannt ist der Aufbau mit einem selbstschwingenden Filter, das lediglich aus den üblichen Bestandteilen Addierer, Multiplizierer und Zwischenspeicher besteht. Weder eine Sinustabelle, noch zeitraubende Iterationsschritte, wie beim [[AVR-CORDIC|CORDIC]]-Verfahren, sind hierfür erforderlich. Die gleichzeitige Nutzung von Sinus und Cosinus ist ohne zusätzlichen Aufwand möglich. Im Gegensatz zur DDS muss man allerdings die Amplitude stabilisieren.

== Aufbau ==

[[Bild:IIR_Sinusgenerator.png|thumb|right|320px|Allgemeiner IIR-Sinusgenerator nach <ref name="stream"/> Seite 325]]
Links vier Multiplizierer mit den Konstanten a...d, danach zwei Addierer und zwei Zwischenspeicher für eine Sampletaktperiode. Die beiden Ausgänge y1 und y2, im Buch ''Zustandsvariable'' genannt, haben je nach Oszillatortyp unterschiedliche Phasenverschiebungen. Für Sin/Cos-Oszillatoren muss sie 90 Grad betragen.

In der folgenden Tabelle sind die vier Konstanten a...d rechts mit der Hilfsvariablen k aufgelistet. Sie ergibt sich gemäß der vorletzten Spalte aus dem Winkel θ (kleines Theta), um den die Sinusschwingung pro Sampletakt weiterrückt.

Aus der gewünschten Sinusfrequenz ƒosz und der Samplefrequenz ƒsample folgt
:<math>\theta = \frac{f_\text{osz}}{f_\text{sample}}\cdot 360^\circ</math>

Die beiden ''Barkhausen-Bedingungen'' für Oszillatoren (Schleifenverstärkung = 1 und Phasendrehung = n*360°) lauten hier
*ad - bc = 1
*| a + d | < 2

{{Absatz}}

{| border="1" class="wikitable"
|+ Eigenschaften der Oszillatortypen, aus<ref name="stream"/> Seite 329
|-
!Oszillatortyp||Multiplikationen||Gleiche Ampl.||Sin/Cos||k =||Matrix [a/b/c/d]
|-
!||||(b = –c)||(a = d)||||
|-
|biquad||1||ja||nein||2·cos(θ)||[k / -1 / 1 / 0]
|-
|Digital Waveguide*||1||nein||ja||cos(θ)||[k / k-1 / k+1 / k]
|-
|Equi-ampl. staggered update||2||ja||nein||2·sin(θ/2)||[1-k² / k / -k / 1]
|-
|Quadrature staggered update||2||nein||ja||cos(θ)||[k / 1-k² / -1 / k]
|-
|Coupled standard quadrature||4||ja||ja||sin(θ)||[√(1-k²) / k / -k / √(1-k²)]
|-
|}
<nowiki>*</nowiki>) Der Typ "Digital Waveguide" ist patentiert, [http://www.google.com/patents/US5701393 US-Pat.#5701393]

== Amplitudenregelung ==
Um ein Aufschaukeln oder Abklingen der Amplitude zu verhindern, kann man:
* Nach einigen Schwingungen den Anfangszustand wieder herstellen.<ref>''Digital Filters and Signal Processing'', S. 465-469 "Digital Oscillators and Synthesizers", ISBN 079239559X</ref> Das führt zu erhöhtem Jitter und funktioniert nur für ganzzahlige Bruchteile der Samplefrequenz.
* Die Amplitude mittels "Pythagoras" berechnen, damit y1 und y2 mit einem Korrekturfaktor multiplizieren. Es reicht aus<ref name="stream">''Streamlining Digital Signal Processing'', Kapitel 33, S. 319-336 "Recursive Discrete-Time Sinusoidal Oscillators" (Übersicht über unterschiedliche Oszillatorschaltungen), ISBN 9781118278383</ref>, die Summe der Amplitudenquadrate zu berechnen, die Wurzelberechnung kann entfallen.
* Die Amplitude mittels einer einfachen AGC-Regelung permanent korrigieren.

== Vergleich mit anderen Verfahren ==
=== Nachteile ===
Das Filter muss mit einer genügend grossen Anzahl von Zwischenpunkten berechnet werden, wenn es korrekt und genügend genau schwingen soll. Das Verfahren ist daher für technische Anwendungen meist nicht nutzbringend, da sich speziell in Hardware mit unwesentlich mehr Aufwand genauere Sinusdarstellungen mit erheblich höherer Grenzfrequenz - oder umgekehrt ähnlich gute Ergenisse mit wesentlich weniger Aufwand erzielen lassen und allesamt nicht unter dem "Amplitudenproblem" leiden.

Konkret bedarf es für einen Sinus mit <6% Abweichung lediglich der parabolischen Annäherung mittels x*(1-x) ohne jegliche Interpolation. Bei Nutzung einer Sinustabelle von 8x2 Werten für Sin/Cos und gegenseitiger Steigung für Interpolation lassen sich mit nachgeschaltetem IIR-Filter Frequenzen bis direkt an Nyquist/2 erreichen, die bereits auf 1% genau berechenbar sind. Für platzsparende Applikationen ist die Nutzung eines mit mehrfachen IIR-Filtern gerundeten Dreiecks empfehlenswert.

=== Vorteile ===
Eingesetzt werden kann das Filter immer dann, wenn die Genauigkeit der sinuswelle, speziell der Amplitude unerheblich ist und niedrige Frequenzen, sowie geringe Frequenzstabilität benötigt werden, wie bei der Erzeugung von simplen Audiosignalen. Auch dann, wenn viele Kanäle zu bedienen sind und der Zugriff auf Sinustabellen und Mehrfachfilter aufgrund der benötigten Speicher ineffektiv wird. Bei FPGAs und MCUs z.B. könnte zwar der Zugriff auf die Sinustabelle noch kanalweise alternierend erfolgen - die Glättung mit Mehrfach IIR-Filtern erfordert jedoch für jeden kanal mehrere Wertespeicher entsprechender Auflösung.

== Einsatzgebiete ==

=== Musik ===
Optimal ist das Verfahren dann, wenn auf eine exakte und schnelle Amplitudenkorrektur verzichtet werden- und eine simple Regelung verwendet kann und sich die damit ergebende, natürliche Rückwirkung des Regelverhältens der Amplitudenkorrektur auf die Frequenz auch noch positiv auswirkt. Durch eine geschickte Amplitudenregelung, welche die frequenzbestimmenden Parameter die Gleichung geeignet dynamisch beeinflusst, wird die Welle sozusagen minimal beschleunigt oder gebremst, was einer geringen Frequenzmodulation gleichkommt. Auf diese Weise erzeugte Audiosignale sind "natürlicher" und musikalisch "lebendiger", insbesondere bei der Mischung mit anderen Signalen änhlicher Grundfrequenz, da die unschönen periodischen Interfrenzen unterbleiben, weil die Regelung zu einer langsamen und vor allem unkorrelierten Frequenzmodulation führt.

=== Technik ===
Das Verfahren des selbschwingenden Oszillators lässt sich dahingehend ausbauen, dass die abstrakten frequenzbestimmenden Parameter in die konkreten Werte für Dämpfung und Masse - sowie zustandsstimmenden Werte für Sinus/Cosinus-Werte in die Aspekte Geschwindigkeit und Weg konkretisiert werden, von denen sich wiederum die Beschleunigung ableiten lässt. Damit können sowohl externe Anfangsbedingungen wie Anfangsgeschwindigkeit und Anfangswert, als auch eine Beschleunigung zugeführt werden, womit eine Reihe von klassischen Feder-Masse-Dämpgungssystemen berechenbar wird. Durch Zusammenschaltung werden komplexe Gefüge in ihrem Verhalten simulier- und berechenbar, so bilden sich z.B. Oberschwingungen auf Wellen und Getrieben und deren Interaktion mit elektronischen Regelungen perfekt ab.

== Thema im Forum ==
* [http://www.mikrocontroller.net/topic/243984 iir Filter als Sinusgenerator]
* [http://www.mikrocontroller.net/topic/265393 Sinuserzeugung in VHDL]
* [http://www.mikrocontroller.net/topic/187913 FPGA Größe ausreichend für komplexen FM Synthesizer]

== Literatur ==

<references/>
3. ''Digitale Signalverarbeitung: Bausteine, Systeme, Anwendungen'', S. 51-52 "Einfacher Sinus-Cosinus-Generator", ISBN 9783905681420

== Weblinks ==
# [http://www.claysturner.com/dsp/2nd_OSC_paper.pdf Das Kapitel aus 1.] als PDF auf der [http://www.claysturner.com/ Webseite des Autors] Clay Turner (IEEE Signal Processing Magazine, Mai 2003 S.103-111)

[[Kategorie:Signalgeneratoren]]

LPC-Tutorial

2017-03-09T20:01:32Z

Newgeneration: Tutorial erstellt

''von newGeneration''

In diesem Artikel soll den Einstieg in die Programmierung der [[LPC1xxx|LPC]]-Mikrocontroller der Firma NXP mit dem [[ARM_GCC|arm-none-eabi-gcc]]-Compiler erleichtern.

Vorausgesetzt sind Grundkenntnisse der Programmiersprache [[C]]. Wer mit dieser Programmiersprache noch keine Erfahrungen hat, bzw. sie nicht sicher beherrscht, kann sich diese auch online erarbeiten, siehe dazu die [[C#C-Tutorials/Einführungen|Liste der C-Tutorials]]. Kenntnisse aus dem PC-Bereich reichen aus, man muss noch keine Mikrocontroller programmiert haben.

''Das Tutorial befindet sich noch im Aufbau''

== Vorwort ==
=== Ziel ===
Dieses Tutorial soll als erstes einmal dem Leser helfen, ein eigenes Grundgerüst zu bauen, auf das dann später aufgebaut werden kann. Weiterhin soll auf Libraries verzichtet werden, die die Hardware-Ansteuerung verschleiern, um das Maximale Verständnis des verwendeten Chips zu bekommen. Eine solche Library wäre zum Beispiel [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-mcus/software-tools/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES LPCOpen].

Ferner soll das gesamte Projekt als Makefile-Projekt angelegt werden, um maximale Portabilität zu gewährleisten. Es steht natürlich jedem frei, seine bevorzugte IDE zu verwenden. An diesem Punkt sollte LPCXpresso erwähnt werden, eine auf Eclipse basierende IDE, die von NXP speziell an die LPC-Controller angepasst wurde. Vorteil hier ist das stark vereinfachte Debuggen, da zum Beispiel die gesamten Peripherie-Einheiten mit Erklärungen hinterlegt sind.

=== Aufbau ===
==== Grundgerüst ====
In diesem Kapitel soll das Grundlegende Gerüst erstellt werden, damit der Chip C-Standard-Konform programmiert werden kann. Damit ist gemeint: es kann ganz normal mit der Funktion main() begonnen werden.

Dazu braucht man im wesentlichen zwei Dateien:
* das Linker-Skript
* den Startup-Code
Diese werden nun Schritt für Schritt erstellt und erklärt.

Am Ende dieses Artikels gibt es auch noch ein kleines Testprogramm.

==== Peripherie ====
Die Peripherie-Einheiten werden in den folgenden Artikeln erklärt:
* [[LPC-Tutorial/SCT-PWM]]
* [[LPC-Tutorial/Timer]]
* [[LPC-Tutorial/Watchdog]]
* [[LPC-Tutorial/USART]]
* [[LPC-Tutorial/I2C]]
* [[LPC-Tutorial/ADC]]
''Die Artikel (und weitere) sollten nach und nach folgen''

== Warum LPC-Mikrocontroller ==
Die LPC-Serie basiert auf lizensierten Kernen von [[ARM]], diese haben allgemein einige Vorteile:
* Der 32bit ARM-Cortex-Architektur mit entsprechender Rechenleistung
* Höherer Maximaltakt
* optionale [[MPU]] und [[FPU]]
* neuere Fertigung bedeuted energieeffizienter
Speziell die Mikrocontroller von NXP haben mehrere Vorteile:
* mehr und stromsparendere Sleep-Modes
* Einfach zu benutzende Hardwaremodule
* Mächtige Hardware (z.B. State Configurable Timer)
* Gute Dokumentation (für den Programmierer unabdingbar)
* als einzige ARMs auch im DIP-Gehäuse erhältlich

== Vorbereitungen ==
Als erstes benötigt man den Chip, den es zu programmieren gilt. Entweder man hat schon einen bestimmten, dann kann es direkt weitergehen, oder man muss sich eben noch einen bestellen. Auswahlhilfe gibt hier der Artikel [[LPC1xxx]] im Forum und der Product-Selector auf der [http://www.nxp.com/webapp/parametricSelector.sp?#/&c=c731_c380_c732&page=1 NXP-Homepage].

Dieses Tutorial bezieht sich nur auf die LPC-Mikrocontroller mit Cortex-M-Kern, nicht auf die älteren LPC2000-/LPC3000-Serien mit älteren ARM-Kernen. Auf diese lässt sich das Tutorial möglicherweise übertragen, jedoch ist es nicht garantiert.

Dieser Artikel versucht möglichst unabhängig von einem speziellen Prozessor zu sein, allerdings wurden die gesamten Beispiele auf einem LPC54102(J512BD64) getestet. Hardware-Abhängigkeiten werden in Kommentaren (fast immer ;-) ) erwähnt.

=== Chip-Dokumentation ===
Als erstes braucht man zu seinem Chip eine Dokumentation, denn ohne die wird das Programmieren seeehr schwer. Deswegen sollte man sich diese möglichst schnell zugreifbar abspeichern.

Die benötigten Dateien sind
* Das Datenblatt mitsamt Pinkonfiguration
* Das Errata-Sheet mit Hardwarefehlern
* Das User-Manual mit ausführlichen Erklärungen zum Nutzen der Hardware

Alle diese Dokumente sind auf der [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-mcus:LPC-ARM-CORTEX-M-MCUS NXP]-Homepage unter
:''Products -> LPC-Serie -> Produktreihe -> Documentation''
zu finden, einfach die aktuellsten Dokumente herunterladen und "in Griffnähe" abspeichern.

=== Toolchain ===
[[Bild:c-flow.svg|right|thumb|260px|Schritte der Kompilierung]]
Unter Toolchain versteht man die Sammlung von Programmen, die zu einem Compiler gehören, darunter fallen
* der Compiler selbst
* der Linker
* Assembler
* Debugger
* C-Standard-Library
* Utility-Programme
Es gibt Toolchains von verschiedenen Herstellern, kommerziell wie auch frei, zum Beispiel von IAR, Keil oder dem GNU-Projekt. Dieses Tutorial zielt auf den GCC, die '''G'''NU '''C'''ompiler '''C'''ollection ab, sollte aber auch auf die anderen Compiler übertragbar sein.

Da die LPC Mikrocontroller alle auf der [[ARM|ARM-Architektur]] basieren bietet sich zum Programmieren auch der offizielle (freie und kostenlose) [https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads GNU ARM Embedded Toolchain] an, die direkt von ARM gepflegt wird.

Nach dem Herunterladen und Installieren einer (GCC-)Toolchain sollte man kurz einen Minimaltest durchführen, nämlich in der Kommandozeile
<syntaxhighlight lang="bash">arm-none-eabi-gcc --version </syntaxhighlight>
Auf diesen Befehl hin sollte die Versions-Informationen ausgegeben werden. Wenn eine Fehler kommt stimmen wahrscheinlich die Pfade nicht und müssen angepasst werden.

== Grundgerüst erstellen ==
Nun können wir mit der Programmierung loslegen.

Wie oben schon angesprochen brauchen wir zum "normalen" Programmieren mit der Funktion main() als Einsprungspunkt (mindestens) zwei Dateien, den Startup-Code und das Linkerskript. Diese werden nun erstellt.

=== Linker-Skript ===
An dieser Stelle sei erst einmal auf die Online-Dokumentation dazu verwiesen: [http://www.scoberlin.de/content/media/http/informatik/gcc_docs/ld_3.html Using LD, the GNU linker - Linker Scripts].

Starten wir erst einmal mit dem Grundgerüst:
Dazu legt man eine Datei an, der Name und die Endung ist streng genommen egal, aber es empfiehlt sich ein aussagekräftiger Name (etwa die Bezeichnung des verwendeten Chips). Häufige Endungen sind .ld und .x.

Ganz oben im Linkerskript wird definiert, wo der Programmstart ist. Das ist '''nicht''' die main()-Funktion, da voher noch einiges zu tun ist. Deshalb nennen wir die Einsprungfunktion _reset. Der einfache vorangestellte Unterstrich symbolisiert Zugehörigkeit zur C-Runtime.
<syntaxhighlight lang="C">
ENTRY(_reset)
</syntaxhighlight>

Als nächstes werden die Speicher-Regionen beschrieben. Diese sind der Memory-Map im User Manual zu entnehmen. Darunter fallen alle Flash- und RAM-Bereiche. Jeder dieser Bereiche bekommt einen Namen, die Attribute (Read, Write, eXecute), den Beginn und die Länge des Bereichs.
<syntaxhighlight lang="C">
MEMORY {
/* memory map des LPC54102. Muss an den verwendeten Controller angepasst werden! */
Flash (rx): ORIGIN = 0x00000000, LENGTH = 0x00080000 /* 512kB */
SRAM0 (rwx): ORIGIN = 0x02000000, LENGTH = 0x00010000 /* 64kB */
SRAM1 (rwx): ORIGIN = 0x02010000, LENGTH = 0x00008000 /* 32kB */
SRAM2 (rwx): ORIGIN = 0x03400000, LENGTH = 0x00002000 /* 8kB */
}
</syntaxhighlight>

Danach kommt des (obere) Ende des Stacks (Achtung: der Stack muss je nach Konfiguration an einer 4 Byte oder 8 Byte Grenze ausgerichtet sein, und darf somit nicht an jeder Adresse beginnen):
<syntaxhighlight lang="C">
_stack_end = ORIGIN(SRAM0) + LENGTH(SRAM0); /* stack end at end of SRAM0 (LPC54102) */
</syntaxhighlight>

Bisher waren es alles einfach und einleuchtend. Jetzt kommt etwas, wofür man einen kleinen Einblick in den GCC braucht, nämlich seine Sections. Es gibt mehrere, jede für einen bestimmten Zweck:
* .text - Code
* .bss - Zu 0 initializierte Variablen
* .data - Initialisierte Variablen (nicht mit 0)
* .rodata - Read-Only-Varaiblen

Die Sections legt man dann in einen Memory-Bereich. Sinnvollerweise wird man die nicht-änderbaren Daten mitsamt den Code in den Flash legen, die Variablen in den RAM. Das geschieht mit dem > "Memorybereich".

Damit die .data-Section, die ja eigentlich im RAM liegt, auch mit den richtigen Werten vorbelegt werden kann, müssen diese irgendwo (im Flash) stehen. Das wird mit dem AT> Flash erreicht. Damit landen die Daten auch (nach dem Programmcode) im Flash.
<syntaxhighlight lang="C">
SECTIONS {
.text : {
_text_section_start = .;
KEEP(*(._vectors)) /* Erklaerung hierzu folgt spaeter */
*(.text)
*(.text*)
*(.rodata .rodata.* .constdata .constdata.*)
_text_section_end = .;
} > Flash

. = ALIGN(4);

.bss : {
_bss_section_start = .;
*(.bss)
*(.bss*)
_bss_section_end = .;
} > SRAM0

. = ALIGN(4);

.data : {
_data_section_start = .;
*(.data)
*(.data*)
_data_section_end = .;
} > SRAM0 AT > Flash
}
</syntaxhighlight>

Damit ist unser Linker-Skript auch schon fertig. Einige abschließende Erklärungen noch:
* die _name_section_start/end = .;-Anweisungen erzeugen globale Variablen, die die aktuelle Adresse enthalten
* . = ALIGN(4); sagt dem Linker, dass er die aktuelle Adresse an der nächsten 4 Byte-Grenze ausrichten soll
* In diesem Beispiel werden alle Konstanten Daten in den Flash gelegt
* Diesem Grundgerüst fehlen noch einige Dinge, wie zu Beispiel der Heap
Für genauere Erklärungen sollte das oben verlinkte Linker-Manual zu rate gezogen werden.

=== Startup-Code ===
So unser Linker-Skript ist nun fertig, jetzt können wir mit dem eigentlichen Programmieren beginnen. Dazu müssen wir den Code erstellen, der direkt nach dem Programmstart ausgeführt wird.

Klassisch wird dieser Code in Assembler geschrieben, jedoch bietet die ARM-Architektur einen perfekten Aufbau, um einen Startup-Code in C schreiben zu können.

Dazu legen wir eine neue Datei an, die hat meistens den Namen crt0.c für '''C'''-'''R'''un'''t'''ime.
Diese enthält als erstes die Prototypen für die aufgerufenen Funktionen, namentlich _reset(), main() und _stack_end() (ja, das Stackende wird als Funktion angesehen, macht aber nichts, weil es nur um die Adresse geht).
<syntaxhighlight lang="C">
extern int main(void);
extern void _reset(void);
extern void _stack_end(void);
</syntaxhighlight>

Daraufhin kommen die Prototypen für alle Faulthandler. Welche Faults auf dem entsprechenden Device implementiert sind, kann man dem User Manual unter Kapitel ARM Cortex Appendix und dem ARM Cortex-Mx Generic User Manual.
<syntaxhighlight lang="C">
/* die implementierten Faulthandler des LPC54102 */
void NMI_handler(void);
void HardFault_handler(void);
void MemManage_handler(void);
void BusFault_handler(void);
void UsageFault_handler(void);
void SVC_handler(void);
void DebugMon_handler(void);
void PendSV_handler(void);
void SysTick_handler(void);
</syntaxhighlight>
Danach kommen die Prototypen der Interrupts. Welche hier implementiert sind steht im User Manual unter dem Kapitel zum NVIC.

Das Define sagt dem Compiler/Linker, dass die Funktion weak ist, also von einer anderen Funktion mit selben Namen überschrieben werden kann, und einen alias hat, also, wenn sie nicht überschrieben wird, auf eine andere Funktion verweist.
<syntaxhighlight lang="C">
#define ALIAS(f) __attribute__ ((weak, alias (#f)))

/* Standard-Handler fuer nicht implementierte Interrupt-Service-Routinen */
void Default_Interrupt_Handler(void) __attribute__ ((weak));

/* Ausschnitt der implementierten Interrupts des LPC54102 */
/* wenn es dir ISR nicht gibt, dann springe in den DefaultHandler*/
void WDT_handler(void) ALIAS(Default_Interrupt_Handler);
void BOD_handler(void) ALIAS(Default_Interrupt_Handler);
/* viele ISR-Protoypen mehr */
void SPI3_handler(void) ALIAS(Default_Interrupt_Handler);
void RIT_handler(void) ALIAS(Default_Interrupt_Handler);
</syntaxhighlight>
Falls ein C++-Compiler genutzt wird, muss man alles oben stehende mit extern "C" { ... } kennzeichnen.

Bisher ist aber noch nichts passiert. Wir sagen dem Compiler zwar, dass es diese und jene Funktionen irgendwo gibt, aber weder benutzen wird diese, noch deklarieren wir sie.

Das benutzen kommt jetzt, nämlich in der Vektor-Tabelle. Diese wird mit Attributen als benutzt gekennzeichnet und in die Section "._vectors" gepackt. Diese Section wird im Linkerskript an die erste Adresse im Flash gesetzt und, da sie niemals direkt verwendet wird, mit KEEP in jedem Fall behalten.

Die Vektor-Tabelle an sich besteht aus einem Array aus [[Funktionszeiger_in_C|Funktionspointern]]:
<syntaxhighlight lang="C">
extern void (* const _vectors[])(void) __attribute__ ((used, section("._vectors")));
void (* const _vectors[])(void) = {
&_stack_end,
_reset,
/* die 14 Fault Handler an die richtige Adresse setzen */
/* siehe dazu das ARM Cortex-Mx Generic User Maual */
/* bei nicht implementierte Handlern wird einfach eine 0 eingetragen */

/* danach kommen alle Interrupts an der richtigen Stelle */
/* dies steht wiederum im User Manual */
WDT_handler,
BOD_handler,
/* ... */
SPI3_handler,
RIT_handler
};
</syntaxhighlight>
So, damit haben wir schon einen wichtigen Teil abgearbeitet. Damit könnten wir nun Interrupts nutzen, wenn wir schon ein richtiges Programm schreiben könnten. Dazu fehlt uns aber noch die _reset()-Funktion, die alle Variablen initialisiert und main() aufrauft.

Die Reset-Funktion muss im wesentlichen eines machen: die Variablen initialisieren. Zwar können noch weitere Dinge dort erledigt werden, aber das ist von Anwendung zu Anwendung unterschiedlich. Es könnten zum Beispiel die Clocks zu verschiedenen Peripherie-Modulen aktiviert werden, oder der System-Takt eingestellt werden.

Des weiteren aktiviert man gerne noch die FPU (wenn vorhanden) im Startupcode und nimmt wenn nötig Prozessor-Einstellungen vor.

Die Funktion _reset() legen wir jetzt an:
<syntaxhighlight lang="C">
void _reset(void) {
/* hole die im Linker-Skript erstellen globalen Variablen */
extern unsigned int _data_section_start;
extern unsigned int _data_section_end;
extern unsigned int _text_section_end;
extern unsigned int _bss_section_start;
extern unsigned int _bss_section_end;

unsigned int *src;
unsigned int *dest;
/* jetzt überschreiben wir alle Varaiblen in der .bss-Section mit 0 */
dest = &_bss_section_start;
while (dest < &_bss_section_end) {
*dest++ = 0;
}

/* jetzt initialisieren wir alle .data-Variablen mit den */
/* Daten, die im Flash abgelegt wurden */
src = &_text_section_end;
dest = &_data_section_start;
while (dest < &_data_section_end) {
*dest++ = *src++;
}

/* und nun folgt endlich der Aufruf von main() */
/* der return-wert wird nicht verwendet, man könnte also main als */
/* void main(void) definieren und deklarieren, spart uU etwas Speicher */
main();

/* falls main() zurückkehrt: gehe in eine Endlosschleife */
while(1) ;
}
</syntaxhighlight>
Und als letztes legen wir noch die Fault-Handler, sowie die Funktion an, die angesprungen wird, wenn ein Interrupt auftritt, der keine Interrupt-Service-Routine hat:
<syntaxhighlight lang="C">
void Default_Interrupt_Handler(void) {while(1);}
void NMI_handler(void) {while(1);}
void HardFault_handler(void) {while(1);}
void MemManage_handler(void) {while(1);}
void BusFault_handler(void) {while(1);}
void UsageFault_handler(void) {while(1);}
void SVC_handler(void) {while(1);}
void DebugMon_handler(void) {while(1);}
void PendSV_handler(void) {while(1);}
void SysTick_handler(void) {while(1);}
</syntaxhighlight>
Diese Implementierungen sind natürlich nicht sinnvoll, sondern dienen einzig und alleine dem Zweck die Fault-Handler zu erstellen. Nur warten im Falle eines Faults ist nicht sinnvoll. Siehe [https://www.mikrocontroller.net/topic/420629#new Beitrag:Cortex Faults: Was macht man im Handler?].

... Und, ob man es glaubt, oder nicht: Damit ist das Grundgerüst fertig!

Diese beiden Dateien kann man einfach ohne sie anzupassen in jedes Projekt kopieren, sofern der Chip gleich ist.

Bei unterschiedlichen Chips muss man die Memory-Eintrage im Linker-Skript, sowie die Fault- und Interrupt-Handler im Startup-Code ändern. Der Rest sollte gleich bleiben.

Ab jetzt kann man endlich richtig losprogrammieren.

== Makefile und Compiler-Settings ==
Um nicht alles ein x-tes mal zu erklären versuche ich mich hier kurz zu halten und auf weitere Artikel zu verweisen, diese sind [[Beispiel_Makefile]] für ein (AVR-)Beispiel, [[AVR-GCC-Tutorial/Exkurs_Makefiles]] für einen groben Überblick, [[ARM_GCC#Nutzung_mit_eigener_Umgebung/Kommandozeile|arm-none-eabi-gcc Parameter]] für eine Liste wichtiger Compiler-Optionen. Eine gute Seite mit einer Einführung in Makefile findet sich [http://www.ijon.de/comp/tutorials/makefile.html hier].

Hier ist ein simples Makefile, das für kleine Projekte ausreicht und leicht erweitert werden kann:
Diese Datei einfach unter dem Namen "Makefile" (ohne Endung im Projektordner speichern).
<syntaxhighlight lang="make">
## Example Makefile for arm-none-eabi-gcc and LPC-microcontrollers

OUTPUT_NAME = lpc

## Used tools
# C compiler frontend
CC = arm-none-eabi-gcc
OBJDUMP = arm-none-eabi-objdump

## list files to compile here (suffix: *.o)
OBJS = crt0.o main.o

## Path and name of the linker script
LINKER_SCRIPT = lpc.ld

## Flags
# processor-dependent flags
MCU_FLAGS = -mthumb -mcpu=cortex-m0 -mtune=cortex-m0 -mfloat-abi=soft
# Compiler flags
CFLAGS = $(MCU_FLAGS)
CFLAGS += -Wall -Og -g3 -MMD
CFLAGS += -ffunction-sections -fdata-sections -fsingle-precision-constant -fstack-usage # more options
# Linker flags
LDFLAGS = $(MCU_FLAGS) $(CFLAGS)
LDFLAGS += -T$(LINKER_SCRIPT)
LDFLAGS += -nostartfiles -Wl,--gc-sections,-print-memory-usage
LDFLAGS += # more options, e.g. libraries

## Rules
all: $(OUTPUT_NAME).elf $(OUTPUT_NAME).lss
.PHONY: clean

# Rule for creating the .elf file
$(OUTPUT_NAME).elf: $(OBJS) Makefile
@echo Linking final file...
@$(CC) $(CFLAGS) -o $(OUTPUT_NAME).elf $(OBJS) $(LDFLAGS)

# Rule for compiling every needed c file
%.o: %.c Makefile
@echo Compiling file $<...
@$(CC) -c $(CFLAGS) -o $@ $<

# Rule for generating a disassembly
%.lss: %.elf
@echo Generating disassembly...
@$(OBJDUMP) -d -S $< > $@

# delete all created files
clean:
@echo Cleaning up...
@$(RM) $(OBJS) $(OUTPUT_NAME).elf $(OUTPUT_NAME).lss $(OBJS:.o=.d) $(OBJS:.o=.i)

# include C dependencies
-include $(OBJS:.o=.d)
</syntaxhighlight>
Das Makefile ist einfach aufgebaut. Zuerst kommen die Variablen, die jeweilige Bedeutung sollte sich aus dem Namen ergben. Wichtig sind die Flags, bei denen man seine Compiler- und Linker-Option angibt. Die aktuellen Parameter sind selbstverständlich anzupassen.

Danach kommen die sogenannten Rules, die "Erstellungs-Regeln". Diese beschreiben was wann wie getan werden muss. '''''TODO''''' weiter ausführen

Zum Kompilieren muss man nun lediglich
<syntaxhighlight lang="bash">make</syntaxhighlight>
aufrufen, zum Aufräumen, also zum Löschen aller erstellen Dateien
<syntaxhighlight lang="bash">make clean</syntaxhighlight>

== Device-Header ==
Eigentlich kann man jetzt schon den gesamten Chip programmieren, ohne irgendwelche Abstriche machen zu müssen. Um etwa eine LED blinken lassen muss man "nur" folgendes schreiben:
<syntaxhighlight lang="c">
#include <stdint.h>

extern void delay_ms(uint32_t ms); /* implemented somewhere else */

int main(void) {
/* enable GPIO0 (bit 14) and IOCON (bit 13) clock in the SYSCON->AHBCLKCTRLSET register */
*(volatile uint32_t*)0x400000C8 = (1 << 13) | (1 << 14);
/* setup PIO0_29: GPIO (bits [2:0]), Pull-Up (bits [4:3]), digital mode (bit 7) */
*(volatile uint32_t*)(0x4001C000 + 29 * 0x4) = (0x0 << 0) | (0x2 << 3) | (0x1 << 7);
/* set PIO0_29 to output using the GPIO->DIR0 register */
*(volatile uint32_t*)(0x1C000000 + 0x2000 + 0) |= (1U << 29);

while(1) {
/* toggle LED at PIO0_29 using GPIO->NOT0 register */
*(volatile uint32_t*)(0x1C000000 + 0x2300 + 0) = (1U << 29);
delay_ms(500);
}
}
</syntaxhighlight>
Wer erkennt nicht auf den ersten Blick, was hier passiert? Okay, der Code ist einigermaßen gut kommentiert, und damit versteht man vas vorsich geht, aber diese kryptischen Adressen?! Auch die Bitwerte sind zu verbessern, zwar wird auch hier im Kommentar erklärt was mit welchen Bits gemacht wird, aber sprechende Namen wären deutlich schöner.

Wer will, kann den Code testen, die Adressen beziehen sich uaf einen LPC54102, der eine LED an PIO0_29 angeschlossen hat (so wie am Eval-Board für diesen Chip). Dieser Schipsel ist getestet und funktioniert. Für eine mögliche Implementierung einer einfachen delay_ms()-Funktion siehe [https://www.mikrocontroller.net/topic/378584#4301959 diesen Thread].

Aber, wie allen klar sein dürfte: So will man nicht programmieren. Selbst beim konstruieren dieses einfachen Beispiels hatten sich ursprünglich zwei Fehler in den Adressen eingeschlichen. Also: eine andere Möglichkeit muss her.

Die Lösung ist die CMSIS. ARM hat einen Standard für alle möglichen Teile eines Mikrocontroller-Systems, unter anderem das sogenannte CMSIS-SVD. Das steht für '''S'''ystem '''V'''iew '''D'''escription. Das sind Dateien, die einen kompletten Mikrocontroller beschreiben, mit Registern, Interrupts, Bits, ihren Namen. Also genau das was wir brauchen. NAja fast, wir wollen schließlich eine .h-Datei, keine .svd-Datei, diese sind nämlich nicht einfach austauschbar. Aber auch dafür gibt es eine Lösung von ARM: SVDconv.exe ist ein Kommandozeilen-Programm für unter anderem die Generierung von Device-Headern.

Das Programm kann von [https://github.com/ARM-software/CMSIS GitHub aus dem ARM-Repository] heruntergeladen werden und befindet sich unter CMSIS/Utilities/SVDConv.exe. Fehlt nur die .svd-Datei. Diese bekommt man im idealen Fall vom Hersteller des Chips. Wenn dieser seine SVDs nicht veröffentlicht gibt es auch [https://github.com/posborne/cmsis-svd dieses GitHub-Repository], das im Unterordner data eine Sammlung der Dateien von verschiedenen Herstellern beinhaltet, unter anderem eben auch die Beschreibungen für die LPC-Serie von NXP.

Dazu führt man in der Eingabeaufforderung folgendes aus:
<syntaxhighlight lang="bash">
SVDConv.exe <device-file.svd> --generate=header --fields=macro
</syntaxhighlight>
Warnings wegen "RESERVED should not be defined" kann man getrost ignorieren. Fehler sollten keine auftreten.

Mit diesem Kommando generiert man eine Header-Datei für seinen Controller. Des weiteren muss man neben den generierten Header noch die von ARM gestellten Header-Dateien core_cmX.h, core_cmFunc.h und core_cmInstr.h aus dem Verzeichnis CMSIS-master\CMSIS\Include zu seinem Header-File kopieren. Wenn beim kompilieren weitere fehlende Dateien angemahnt werden, dann auch diese aus dem Verzeichnis kopieren. Beim Fehler "fatal error: system_<device>.h: No such file or directory" hat man zwei Optionen:
* das Include löschen, damit ist man zwar nicht mehr CMSIS-kompatibel, aber hat keine arbeit
* die Datei (mit einer dazugehörigen .c-Datei) erstellen. Der Inhalt sollte der folgende sein:
:<syntaxhighlight lang="c">
#ifndef __SYSTEM_<device>_H
#define __SYSTEM_<device>_H

#ifdef __cplusplus
extern "C" {
#endif

#include <stdint.h>

extern uint32_t SystemCoreClock; /*!< System Clock Frequency (Core Clock) */

/**
* Initialize the system
*
* @param none
* @return none
*
* @brief Setup the microcontroller system.
* Initialize the System and update the SystemCoreClock variable.
*/
extern void SystemInit (void);

/**
* Update SystemCoreClock variable
*
* @param none
* @return none
*
* @brief Updates the SystemCoreClock with current core Clock
* retrieved from cpu registers.
*/
extern void SystemCoreClockUpdate (void);

#ifdef __cplusplus
}
#endif

#endif /* __SYSTEM_<device>_H */
</syntaxhighlight>
: Die .c-Datei implementiert dann die beiden Funktionen und definiert die globale Variable. Was die Funktionen tun kann man dem Doxygen-Kommentar über den Funktionen entnehmen.

Damit sind dann alle wichtigen Dateien fertig!

== Das erste Programm ==
Nun können wir endlich so programmieren, wie man es von PC oder einem anderen Controller gewöhnt ist.

Also in einer neu angelegten Datei seinen normalen Code schreiben.
<syntaxhighlight lang="C">
int i = 42;

int main(void) {

while(1) {
--i;
}
return 0;
}
</syntaxhighlight>
[[Image:Sequentielle Programme.gif|right|thumb|260px|Mikrocontroller-Programmierung]]
Dieses sollte man testweise einmal Kompilieren, um die bisherigen Schritte zu verifizieren. Wer einen Debugger hat kann auch testen, ob die Variable i mit dem richtigen Wert (42) initialisiert wird und auch schauen, ob die Variable dekrementiert wird.

Aber wie jedem klar sein sollte: das obige Programm macht nichts sinnvolles. Streng genommen macht es gar nichts. Schließlich zeichnet sich ein Mikrocontroller-Programm dadurch aus, dass es auf externe Ereignisse reagiert und Ausgaben tätigt. Diese Ein- und Ausgaben können gerade auf einem Mikrocontroller sehr vielfältig sein, von einfachen Tastern als Ein- und LEDs als Ausgabe, bis hin zu Sensordaten und ganzen Displays oder Motoren ist alles dabei.

Also muss unser Controller mit der Außenwelt kommunizieren, und genau dafür brauchen wir die I/O-Pins, beziehungsweise Peripherie im allgemeinen. Deswegen wenden wir uns als erstes dem GPIO-Modul zu.

Das neue einfache Programm sieht dann so aus:
<syntaxhighlight lang="C">
#include <stdint.h>
#include "LPC5410x.h" /* die generierte Datei fuer euren Controller */

extern void delay_ms(uint32_t ms); /* implemented somewhere else */

int main(void) {
LPC_SYSCON->AHBCLKCTRLSET0 = SYSCON_AHBCLKCTRL0_GPIO0_Msk | SYSCON_AHBCLKCTRL0_IOCON_Msk;
LPC_IOCON->PIO0_29 = (0x0 << IOCON_PIO0_29_FUNC_Pos) | /* ! */
(0x2 << IOCON_PIO0_29_MODE_Pos) | /* ! */
IOCON_PIO0_29_DIGIMODE_Msk;
LPC_GPIO->DIR0 |= (1U << 29);

while(1) {
LPC_GPIO->NOT0 = (1 << 29);
delay_ms(500);
}
}
</syntaxhighlight>
Das sieht doch schon wesentlich besser aus! Die Funktion ist 1:1 die selbe, wie im Beispiel oben, allerdings ist das doch wesentlich lesbarer, obwohl alle Kommentare fehlen. Lediglich die beiden mit /* ! */ markierten Zeilen sollten entweder kommentiert werden, oder mit einem aussagekräftigen define beschrieben werden, damit man nicht im User-Manual nachschauen muss, was 0x0 und 0x2 in diesem Kontext bedeutet.

So, ab jetzt kann jeder mit dem User-Manual als Referenz seine Applikation programmieren. Hilfe zu den einzelnen Peripherie-Einheiten findet man oben unter Aufbau/Peripherie.

== TODO ==
* (evtl ARM-Core-Config)
* Syscon
* GPIO, weiterführendes Beispiel
* Delay (AVR-Libc Style)
* Bearbeiten der Header, IOCON->PIOn_x -> IOCON->PIO[n][x], etc.
* Abschließendes Wort und Verweis auf die nächsten Kapitel

Diskussion:LPC-Mikrocontroller

2017-03-06T17:01:26Z

Newgeneration: /* Umstrukturierung der Seite */

Die Zustimmung von NXP sowie code-red zur Verlinkung bzw. zum direkten Kopieren aus der Domain www.nxp.com bzw. www.code-red-tech.com liegt mir vor. ([[Benutzer:Powerfreak|Powerfreak]] 3. Sep. 2011 (UTC))

Kann man die Cortex M0 denn mit dem einfachen GCC für M3 bearbeiten? Oder bracht es da andere Tools?
Ja, kann man, die Standard-Tools decken das mit ab

Solche Fragen bitte im Forum stellen - wie auch immer: siehe http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html und darin Erläuterungen zu -mcpu=name ([[Benutzer:Mthomas|Mthomas]] 15:35, 2. Sep. 2011 (UTC))

== Umstrukturierung der Seite ==

Wenn man sich einmal das aktuelle Portfolio von NXP anschaut ([http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-mcus:LPC-ARM-CORTEX-M-MCUS LPC Microcontrollers | NXP]), dann stellt man fest, dass diese Seite nicht mehr aktuell ist:
Es gibt mehr Typen, als die bisher erwähnten LPC1xxx-µCs.
Der Seitentitel suggeriert auch, dass es eben nur um die LPC1x00-Serie geht, obwohl die LPC800er Serie auch erwähnt wird.

Generell finde ich die Seite nicht mehr übersichtlich genug.

Ein kleiner Überblick zu den aktuellen Produktreihen:
* Cortex-Kerne
:* LPC800 mit Cortex-M0+
:* LPC1100 mit Cortex-M0+/M0
:* LPC1200 mit Cortex-M0
:* LPC1300 mit Cortex-M3
:* LPC1500 mit Cortex-M3
:* LPC1700 mit Cortex-M3
:* LPC1800 mit Cortex-M3
:* LPC4000 mit Cortex-M4
:* LPC4300 mit Cortex-M4 und M0
:* LPC54000 mit Cortex-M4 und M0+
* und eventuell auch die anderen ARM Kerne
:* (LPC2000 mit ARM7TDMI)
:* (LPC3000 mit ARM926EJ)

Deswegen mein Vorschlag: die aktuelle Seite umbenennen/verschieben auf eine neue Seite "LPC MCUs"/"LPC Mikrocontroller"/"LPC Series MCUs" (oder so ähnlich) und dann die Seite zu updaten. Darunter fällt
sowohl generell die neuen Informationen aufzunehmen, als auch ältere Daten auf den aktuellen Stand zu bringen (Der Stand der Seite scheint teilweise von 2013 oder noch früher zu sein).
Die Verlinkung links oben in der Übersicht müsste bei der Umbenennung der Seite auch angepasst werden.

Auch sollte man die Seite durchgehend in deutsch schreiben, oder wenigstens deutsche Erklärungen dazu.

Angefangen habe ich schon mal mit der neuen Vergleichstabelle, die allerdings auch noch erweiterbar ist.

Freue mich auf eure Meinungen dazu

--[[Benutzer:Newgeneration|Newgeneration]] ([[Benutzer Diskussion:Newgeneration|Diskussion]]) 18:06, 11. Feb. 2017 (CET)

:Die abgeschriebenen Übersichten sind nie so aktuell wie die Seiten der Hersteller. Die Änderungen sind schön, aber die parametrische Suche von NXP ist umfangreicher.
:Die Seite nur 'LPC' zu nennen fände ich auch besser, LPC1xxx ist mittlerweile wirklich obsolet.
:Leider ist hier das Interesse an der LPC Serie sehr gering, obwohl die sehr einfach zu programmieren sind. :Interessanter wären da eher Tutorials zum Einstieg.

:--[[Benutzer:Jojos|Jojos]] ([[Benutzer Diskussion:Jojos|Diskussion]]) 13:12, 6. Mär. 2017 (CET)

:: Natürlich hast du recht, die Herstellerseiten sind immer besser gepflegt (wenn nicht läuft echt was schief).
:: Jedoch halte ich nichts davon, einen "Artikel" zu haben, auf dem nur veraltete, z.T. schon falsche Informationen stehen, dann kann und sollte man sich die Seite gleich sparen und einfach nur auf die Herstellerseite verlinken.
:: Deswegen würde ich versuchen die Infos so gut wie möglich auf den aktuellen Stand zu bringen. Des weiteren werde ich auch immer einen Stand hinzufügen (also Stand März 2017 etc.) damit andere, die evtl. schon neure Informationen haben dann das ändern können. Die Artikelsammlung lebt schließlich davon dass viele etwas dazu beitragen.
:: Diese Änderungen können sich aber (zumindest von meiner Seite) noch hinziehen, da ich in diesem Monat doch sehr viel zu tun habe, das eine höhere Priorität hat, unter anderem auch ein Job ;-)
:: Zum Tutorial: Ich habe da schon etwas in Arbeit, allerdings ist es im Moment noch nicht reif für die Öffentlichkeit. Es muss z.B. noch verallgemeinert werden, denn im Moment bezieht es sich nur auf einen Prozessor... Es kommt, aber alles zu seiner Zeit.

:: Danke aber schon mal an dich für deine Anregung, ich dachte ich führe Selbstgespräche :)
:: --[[Benutzer:Newgeneration|Newgeneration]] ([[Benutzer Diskussion:Newgeneration|Diskussion]]) 18:01, 6. Mär. 2017 (CET)

LPC-Mikrocontroller

2017-03-03T14:51:03Z

Newgeneration: Controller farbig gemacht und Tabelle überarbeitet

[[Bild:overview_Sep2011.png|thumb|right|850px|Überblick über die aktuelle Cortex M0/3 Familie, ©NXP.com]]
[[Bild:positioning_NXPSep2011.gif|thumb|right|850px|Vergleich über die aktuelle Cortex M0/3 Familie, ©NXP.com]]

Die LPC-Familie von NXP basiert auf 32-Bit Cortex-Kernen von ARM und arbeitet mit bis zu 204MHz. Die verschiedenen Serien basieren auf den Cortex-M0/M0+/M3/M4-Kernen und sind inzwischen auch für Privatnutzer zu Preisen erhältlich, die mit denen von 8-Bit-Mikrocontrollern vergleichbar sind. Eine Auflistung der verschiedenen Typen findet sich in der Tabelle unten.

Von NXP sind preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG Programmer und Debugger oder den neuen LPC-Link2, ein reiner Programmer + Debugger) erhältlich z.B. bei [http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]. Siehe dazu auch die Dokumentation von NXP zu den [http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)] und diese [[LPC1xxx Entwicklungskit LPCXpresso]].

== Vergleich aller Typen ==
''Stand Feb. 2017''
{| class="wikitable sortable"
! rowspan="2" class="unsortable" |
! rowspan="2" style="text-align: center;" | CPU
! rowspan="2" style="text-align: center;" | Max. Frequency
! rowspan="2" style="text-align: center;" | Flash
! rowspan="2" style="text-align: center;" | SRAM
! rowspan="2" style="text-align: center;" | Voltage
! rowspan="2" style="text-align: center;" class="unsortable" | Features
|-
| bgcolor="#EAECF0" | LPC800
| style="text-align: center;" data-sort-value="2" | Cortex-M0+
| style="text-align: center;" data-sort-value="30" | 30MHz
| style="text-align: center;" data-sort-value="8" | 8-32kB
| style="text-align: center;" data-sort-value="1" | 1-8kB
| style="text-align: center;" data-sort-value="1.8" | 1.8-3.6V
| style="text-align: center;" |
SCTimer/PWM,
Switch Matrix,
Pattern Match Engine
|-
| bgcolor="#EAECF0" | LPC54000
| style="text-align: center;" data-sort-value="4" | Cortex-M41
| style="text-align: center;" data-sort-value="180" | 180MHz
| style="text-align: center;" data-sort-value="128" | 128-512kB
| style="text-align: center;" data-sort-value="96" | 96-200kB
| style="text-align: center;" data-sort-value="1.62" | 1.62-3.6V
| style="text-align: center;" |
USB,
CAN,
LCD,
Ethernet,
FlexComm,
Security
|-
| bgcolor="#EAECF0" | LPC1100
| style="text-align: center;" data-sort-value="1" | Cortex-M0/M0+
| rowspan="2" style="text-align: center;" data-sort-value="50" | 50MHz
| style="text-align: center;" data-sort-value="4" | 4-256kB
| style="text-align: center;" data-sort-value="1" | 1-36kB
| style="text-align: center;" data-sort-value="1.71" | 1.71-3.6V
| style="text-align: center;" |
USB,
CAN,
EEPROM
|-
| bgcolor="#EAECF0" | LPC1200
| style="text-align: center;" data-sort-value="0" | Cortex-M0
| style="text-align: center;" data-sort-value="32" | 32-128kB
| style="text-align: center;" data-sort-value="4" | 4-8kB
| style="text-align: center;" data-sort-value="1.8" | 1.8-3.6V
| style="text-align: center;" |
8 kV protection,
IEC 60730 Class B certified
|-
| bgcolor="#EAECF0" | LPC1300
| rowspan="4" style="text-align: center;" data-sort-value="3" | Cortex-M3
| rowspan="2" style="text-align: center;" data-sort-value="72" | 72MHz
| style="text-align: center;" data-sort-value="8" | 8-64kB
| style="text-align: center;" data-sort-value="4" | 4-12kB
| style="text-align: center;" data-sort-value="2.0" | 2.0-3.6V
| style="text-align: center;" |
USB
|-
| bgcolor="#EAECF0" | LPC1500
| style="text-align: center;" data-sort-value="64" | 64-256kB
| style="text-align: center;" data-sort-value="12" | 12-36kB
| rowspan="5" style="text-align: center;" data-sort-value="2.4"| 2.4-3.6V
| style="text-align: center;" |
USB,
CAN,
QEI
|-
| bgcolor="#EAECF0" | LPC1700
| style="text-align: center;" data-sort-value="120" | 120MHz
| style="text-align: center;" data-sort-value=" | 32-512kB
| style="text-align: center;" data-sort-value="8" | 8-96kB
| style="text-align: center;" |
USB,
CAN,
Ethernet,
LCD,
QEI
|-
| bgcolor="#EAECF0" | LPC1800
| style="text-align: center;" data-sort-value="180" | 180MHz
| style="text-align: center;" data-sort-value="512" | Flashless,
512kB-1MB
| style="text-align: center;" data-sort-value="104" | 104-200kB
| style="text-align: center;" |
Dual HS USB,
CAN,
Ethernet,
LCD,
Security
|-
| bgcolor="#EAECF0" | LPC4000
| style="text-align: center;" data-sort-value="4" | Cortex-M4
| style="text-align: center;" data-sort-value="120" | 120MHz
| style="text-align: center;" data-sort-value="64" | 64-512kB
| style="text-align: center;" data-sort-value="24" | 24-96kB
| style="text-align: center;" |
USB,
CAN,
Ethernet,
LCD
|-
| bgcolor="#EAECF0" | LPC4300
| style="text-align: center;" data-sort-value="4" | Cortex-M41
| style="text-align: center;" data-sort-value="240" | 204MHz
| style="text-align: center;" data-sort-value="512" | Flashless,
512kB-1MB
| style="text-align: center;" data-sort-value="104" | 104-282kB
| style="text-align: center;" |
Dual HS USB,
CAN,
Ethernet,
LCD,
SGPIO,
Security
|}
1: gibt es auch als Mehrkern-Prozessoren (mit 0/1/2 Cortex-M0(+)-Cores)

== Allgemeine Informationen ==

== Allgemeine Infos + User-Manuals==

=== Eckdaten LPC8xx (Cortex-M0+) ===
Die sehr stromsparende '''[http://www.nxp.com/products/microcontrollers/cortex_m0_m0/series/LPC800.html#quickreference LPC8xx]''' ist nur in Packages mit einer relativ niedrigen Pinanzahl (DIP8, SO20, TSSOP16, TSSOP20) verfügbar, hat zwischen 4-16kB Flash, und 1-4kB RAM. Die zulässige Betriebsspannung liegt zwischen 1,8V und 3,6V.

Überblick über die Features der LPC800-Serie:
* 1 I2C
* 1-2 SSP
* 2-3 UART
* 4 Timer, 1 OS-Timer
* 1 watch dog
* 4 PWM-Einheiten
* 10-bit ADC.

'''[http://www.nxp.com/download/grouping/11045/user_manual User Manual der LPC8-Familie (PDF)]'''

=== Eckdaten LPC11xx (Cortex-M0) ===
Die sehr stromsparende '''[http://ics.nxp.com/products/lpc1000/lpc11xx/ LPC11xx-Serie]''' (3,3V) bietet viele Möglichkeiten
* Der LPC1100L ist derzeit laut NXP (Sep2011) der preisgünstigste ARM auf dem Markt. Der 32Bit ARM mit einer Performance von ca. 45DMIPS @50MHZ benötigt bei dieser Taktfrequenz nur etwa 10mA. (Details siehe NXP-Seite)

* Überblick über die Features :
** LPC1100 Serie: • I2C, SSP, UART, GPIO, • Timers and watch dog timer, • 10-bit ADC, • Flash/SRAM memory, • Weitere Funktionen, siehe '''[http://www.mikrocontroller.net/articles/LPC1xxx#Features_eines_LPC11xx 2.3 Features]'''
** LPC1100L Serie zusätzlich zu LPC1100: • Power Profile mit lower power consumption in Active- und Sleep-mode, • Interne pull-ups auf VDD level, • Programmierbarer pseudo open-drain mode für GPIO Pins, • WWDT mit Clock Source Lock.
**LPC11C00 Serie zusätzlich zu LPC1100: • CAN controller, • On-chip CAN Treiber, • On-chip CAN Transceiver (LPC11C2x), • WDT (not windowed) mit Clock Source Lock.

'''[http://www.nxp.com/documents/user_manual/UM10398.pdf User Manual der LPC11-Familie (PDF)]'''

* Besonderes Augenmerk möchte ich auf die neue Serie '''[http://www.nxp.com/ps/#/i=71498 LPC111xFD]''' legen, denn in jetzt gibt es den Cortex-M0 auch im DIL 28 '''[http://www.nxp.com/redirect/pip/LPC1114FN28.html den LPC1114FN28]'''
**Des Weiteren sind damit SO20, sowie TSSOP20 und TSSOP28 Bauformen verfügbar

=== Eckdaten LPC12xx (Cortex-M0) ===
* Die Low Power '''[http://ics.nxp.com/products/lpc1000/lpc12xx/ LPC12xx-Serie]''' (3,3V) ist laut NXP (Sep2011) ein Cortex-M0 mit 32 bis 128kB Flash, einem 45 CoreMark™ Benchmark-Score bei 30MHz, 2 bis 8kB SRAM, und einem internen 1% genauen 12MHz Oscillator.

* Überblick über die Features: fMAX von 30MHz, 1 10-Bit ADC mit 8 Kanälen, 2 Comparatoren, 2 UARTs, 1 SSP/SPI, 1 I2C, DMA Controller, CRC Engine, 1 32-Bit, 5 Timer (16- und 32-Bit, + RTC), 13 PWM Kanäle, bis zu 55 GPIOs.

'''[http://www.nxp.com/documents/user_manual/UM10441.pdf User Manual der LPC12xx-Familie (PDF)]'''

=== Eckdaten LPC13xx (Cortex-M3) ===
Die sehr stromsparende '''[http://ics.nxp.com/products/lpc1000/lpc13xx/ LPC13xx-Serie]''' (3,3V) bietet im LQFP 48 Gehäuse 8..32k Flash, 2..8k SRAM, 5 Timer (mit WD), 11 PWM, 1 UART, 1IIC, 1USB, 1..2 SPI, einen 8-Kanal/10Bit AD-Wandler und eine Taktfrequenz von max. 72MHz.

'''[http://www.nxp.com/documents/user_manual/UM10375.pdf User Manual der LPC13xx-Familie (PDF)]'''

=== Eckdaten LPC17xx (Cortex-M3) ===
Die '''[http://ics.nxp.com/products/lpc1000/lpc17xx/ LPC17xx-Serie]''' hingegen enthält eine weit größere Peripherie in einem LQFP80/100/144/208 Package.
32..512k Flash, 8..96k SRAM, 6 Timer (mit WD), 6 zusätzliche PWM-Einheiten, teilweise Ethernet und STN/TFT-LCD-Controller, meist USB (teilw. mit Host+OTG), 4 UART, 2..3IIC, 1..2 CAN, 1 SPI, 2 SSP/SPI einen 6..8-Kanal/12Bit AD-Wandler, einen 10Bit DAC, Motor-Control-Einheiten, einen Encoder-Eingang und eine Taktfrequenz von max. 100MHz(120MHz) und vieles mehr.

'''[http://www.nxp.com/documents/user_manual/UM10360.pdf User Manual der LPC17xx-Familie (PDF)]'''

=== Eckdaten LPC18xx (Cortex-M3) ===
Die '''[http://ics.nxp.com/products/lpc1000/lpc18xx/ LPC18xx-Serie]''' stellt DIE "High-Performance" Controller aus der Cortex-M3-Serie. Die Taktfrequenz geht bis 150MHz, die Controller enthalten große dual-Bank Flash Speicher bis zu 1MB, ein großes On-Chip SRAM mit bis zu 200KB, zusätzliche Peripherie wie z.B. SPI Flash Interface (SPIFI) und State Configurable Timer (SCT), 2x High Speed USB (1x mit On-Chip HS PHY) und eine MPU.

'''[http://ics.nxp.com/support/documents/microcontrollers/pdf/user.manual.lpc18xx.pdf User Manual der LPC18xx-Familie (PDF)]'''

Überblick über die Features: '''[http://ics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc18xx.pdf LPC18xx Flyer von NXP]'''

=== Entwicklungskits ===
Von NXP sind sehr preiswerte Entwicklungskits (ca. 25€ für. USB-JTAG Programmer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)]'''.

=== Kostenlose Entwicklungsumgebung für ALLE hier genannten Controller ===
Für die ganze Prozessorfamilie ist eine kostenlose Entwicklungsumgebung erhältlich. Informationen unter '''[http://www.lpcware.com/lpcxpresso/home lpcware]''': Die auf Eclipse basierende Entwicklungsumgebung ist nach der Installation bis 8k freigeschaltet und nach einer einfachen und kostenlosen Registrierung für 256kB. Die IDE ist auch für '''[http://www.lpcware.com/lpcxpresso/home Linux und Mac]''' verfügbar.

Hier die '''[http://www.mikrocontroller.net/articles/Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red Installationsanleitung]'''

== LPC8xx ==

=== Familienübersicht LPC8xx ===
Bezugsquellen und Preise (Stand 06/2016)
* LPC810FN8 (DIP8): Digikey 1,09 € (bei einem Stuck).
* LPC812JD20 (SOIC-W 20): Digikey 1,26 € (bei einem Stuck).
* LPC812JDH20 (TSSOP-20): Digikey 1,44 € (bei einem Stuck).

[[Bild:LPC800_block_diagram_Jan2014.gif|thumb|right|850px|Blockdiagramm des Cortex-M0+, ©NXP.com]]

=== Blockdiagramm der LPC8xx Familie ===

=== Features eines LPC8xx ===
* System:
** ARM Cortex-M0+ processor, running at frequencies of up to 30 MHz.
** single cycle multiplier
** single cycle I/O port
** ARM Cortex-M0+ built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug, Micro Trace Buffer supported.
** System tick timer.
* Memory:
** 16 kB (LPC812M101JD20/LPC812M101JDH20/LPC812M101JDH16), 8 kB (LPC811M001JDH16) or 4kB (LPC810M021FN8) on-chip flash programming memory.
** 4kB, 2 kB, or 1 kB SRAM.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* Digital peripherals:
** Up to 18 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors. Number of GPIO pins is reduced for smaller packages down to 6.
** GPIO pins can be used as edge and level sensitive interrupt sources.
** High-current output driver (20 mA) on one pin.
** High-current sink drivers (20 mA) on two open drain pins.
** Four general purpose timers/counters with a total of four capture inputs and up to 13 match outputs.
** Programmable WatchDog Timer (WDT).
** '''Switch matrix for flexible configuration of each I/O pin function.'''
** CRC engine
* Analog peripherals:
** Comparator with internal and external references and 31 step voltage divider.
* Serial interfaces:
** UART with fractional baud rate generation, internal FIFO, and RS-485 support.
** SPI controllers with SSP features and with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Clock generation:
** 12 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** Programmable watchdog oscillator with a frequency range of 9.4 kHz to 2.3 MHz.
** 10 kHz low-power oscillator for the WKT.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, and the Watchdog clock.
* Power control:
** Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
** Power profiles residing in boot ROM allowing to optimize performance and minimize power consumption for any given application through one simple function call.
** Reduced power modes: Sleep mode, Deep-sleep mode, Power-down mode, and Deep power-down mode.
** Wake-up from Deep-sleep and Power-down modes on activity on USART, SPI, and I2C peripherals.
** Brownout detect.
* Unique device serial number for identification.
* Single 3.3 V power supply (1.8 V to 3.6 V).
* Available as DIP8, TSSOP16, SO20, and TSSOP20 package.

== LPC11xx ==

=== Familienübersicht LPC11xx ===
Bezugsquellen und Preise (Stand 01/2014):

elpro.org: von 1.61EUR (LPC1111FN33) bis 5.73EUR (LPC11U37) bei einen Stueck. Die Familie ist sehr gross mit sehr unterschiedlichen Ausfuehrungen.

[[Bild:Block.diagramM0_NXPSep2011.gif|thumb|right|850px|Blockdiagramm des Cortex-M0, ©NXP.com]]

=== Blockdiagramm der LPC11xx Familie ===

=== Features eines LPC11xx ===
* System:
** ARM Cortex-M0 processor, running at frequencies of up to 50 MHz.
** ARM Cortex-M0 built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug.
** System tick timer.
* Memory:
** 32 kB (LPC1114/LPC11C14), 24 kB (LPC1113), 16 kB (LPC1112/LPC11C12), or 8 kB (LPC1111) on-chip flash programming memory.
** 8 kB, 4 kB, or 2 kB SRAM.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* Digital peripherals:
** Up to 42 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors. Number of GPIO pins is reduced for smaller packages and LPC11C22/C24.
** GPIO pins can be used as edge and level sensitive interrupt sources.
** High-current output driver (20 mA) on one pin.
** High-current sink drivers (20 mA) on two open drain pins.
** Four general purpose timers/counters with a total of four capture inputs and up to 13 match outputs.
** Programmable WatchDog Timer (WDT).
* Analog peripherals:
** 10-bit ADC with input multiplexing among 8 pins.
* Serial interfaces:
** UART with fractional baud rate generation, internal FIFO, and RS-485 support.
** SPI controllers with SSP features and with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Clock generation:
** 12 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** Programmable watchdog oscillator with a frequency range of 7.8 kHz to 1.8 MHz.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, and the Watchdog clock.
* Power control:
** Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
** Power profiles residing in boot ROM allowing to optimize performance and minimize power consumption for any given application through one simple function call.
** Processor wake-up from Deep-sleep mode via a dedicated start logic using up to 13 of the functional pins.
** Power-On Reset (POR).
** Brownout detect with four separate thresholds for interrupt and forced reset.
* Unique device serial number for identification.
* Single 3.3 V power supply (1.8 V to 3.6 V).
* Available in the following packages: 16WLCSP, 25WLCSP 20-SOIC, 20-TSSOP, 28-DIP, 28-TSSOP, 48-LQFP, 64-LQFP, 100-LQFP, and others.

== LPC12xx ==

=== Familienübersicht LPC12xx ===
Bezugsquellen und Preise:

[[Bild:block.diagramM0_NXPSep2011.gif|thumb|right|850px|Blockdiagramm des Cortex-M0, ©NXP.com]]

=== Blockdiagramm der LPC12xx Familie ===

=== Features eines LPC12xx ===

* Processor core
** ARM Cortex-M0 processor, running at frequencies of up to 45 MHz (one wait state from flash) or 30 MHz (zero wait states from flash). The LPC122x have a high score of over 45 in CoreMark CPU performance benchmark testing, equivalent to 1.51/MHz.
** ARM Cortex-M0 built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug (SWD).
** System tick timer.
* Memory
** Up to 8 kB SRAM.
** Up to 128 kB on-chip flash programming memory.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
** Includes ROM-based 32-bit integer division routines.
* Clock generation unit
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** 12 MHz Internal RC (IRC) oscillator trimmed to 1 % accuracy that can optionally be used as a system clock.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, main clock, and Watchdog clock.
** Real-Time Clock (RTC).
* Digital peripherals
** Micro DMA controller with 21 channels.
** CRC engine.
** Two UARTs with fractional baud rate generation and internal FIFO. One UART with RS-485 and modem support and one standard UART with IrDA.
** SSP/SPI controller with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode. I2C-bus pins have programmable glitch filter.
** Up to 55 General Purpose I/O (GPIO) pins with programmable pull-up resistor, open-drain mode, programmable digital input glitch filter, and programmable input inverter.
** Programmable output drive on all GPIO pins. Four pins support high-current output drivers.
** All GPIO pins can be used as edge and level sensitive interrupt sources.
** Four general purpose counter/timers with four capture inputs and four match outputs (32-bit timers) or two capture inputs and two match outputs (16-bit timers).
** Windowed WatchDog Timer (WWDT).
* Analog peripherals
** One 8-channel, 10-bit ADC.
** Two highly flexible analog comparators. Comparator outputs can be programmed to trigger a timer match signal or can be used to emulate 555 timer behavior.
* Power
** Three reduced power modes: Sleep, Deep-sleep, and Deep power-down.
** Processor wake-up from Deep-sleep mode via start logic using 12 port pins.
** Processor wake-up from Deep-power down and Deep-sleep modes via the RTC.
** Brownout detect with three separate thresholds each for interrupt and forced reset.
** Power-On Reset (POR).
** Integrated PMU (Power Management Unit).
* Unique device serial number for identification.
* 3.3 V power supply.
* Available as 64-pin and 48-pin LQFP package.

== LPC13xx ==

=== Familienübersicht LPC13xx ===
[[Bild:LPC13xx_Selection_Guide_Sep2011.png|thumb|left|600px|Selection Guide zur LPC13xx Familie, ©NXP.com]]
 

Bezugsquellen und Preise:

LPC1313 mit 32k-Flash mit 72MHz im LQFP 48 Gehäuse. Der LPC1313 ist bei '''[http://www.darisus.de/ Darius]''' erhältlich für 3,57 € (Juli 2016), oder elpro.org für 2,29 €. Entwicklungskit INKLUSIVE JTAG-Programmer & Debugger bei '''[http://www.watterott.com/de/LPC1343-LPCXpresso-Board Watterott]''' für 23,80 € (Juli 2011)

=== Blockdiagram der LPC13xx Familie ===

[[Bild:LPC13xx Block Diagram Sep2011.png|thumb|left|680px|Blockdiagramm der LPC13xx Familie, ©NXP.com]]
 

=== Features eines LPC1313 ===
* ARM Cortex-M3 processor, running at frequencies of up to 72 MHz.
* ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
* 32 kB on-chip flash programming memory.
* 8 kB SRAM.
* In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* UART with fractional baud rate generation, modem, internal FIFO, and RS-485/EIA-485 support.
* SSP controller with FIFO and multi-protocol capabilities.
* Additional SSP controller on LPC1313FBD48/01.
* I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Up to 42 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors.
* Four general purpose counter/timers with a total of four capture inputs and 13 match outputs.
* Programmable Watchdog Timer (WDT)
* System tick timer.
* Serial Wire Debug and Serial Wire Trace port.
* High-current output driver (20 mA) on one pin.
* High-current sink drivers (20 mA) on two I2C-bus pins in Fast-mode Plus.
* Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
* Three reduced power modes: Sleep, Deep-sleep, and Deep power-down.
* Single power supply (2.0 V to 3.6 V).
* 10-bit ADC with input multiplexing among 8 pins.
* GPIO pins can be used as edge and level sensitive interrupt sources.
* Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, or the watchdog clock.
* Processor wake-up from Deep-sleep mode via a dedicated start logic using up to 40 of the functional pins.
* Brownout detect with four separate thresholds for interrupt and one thresholds for forced reset.
* Power-On Reset (POR).
* Integrated oscillator with an operating range of 1 MHz to 25 MHz.
* 12 MHz internal RC oscillator trimmed to 1 % accuracy over the entire temperature and voltage range that can optionally be used as a system clock.
* Programmable watchdog oscillator with a frequency range of 7.8 kHz to 1.8 MHz. System PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
* Code Read Protection (CRP) with different security levels.
* Unique device serial number for identification.
* Available as 48-pin LQFP package and 33-pin HVQFN package.

== LPC17xx ==

=== Familienübersicht LPC17xx ===
[[Bild:LPC17xx_Selection_Guide_Sep2011.png|thumb|left|680px|Selection Guide zur LPC17xx Familie, ©NXP.com]]
 

Bezugsquellen und Preise:

LPC1754 mit 128K Flash im LQFP80, der bei '''[http://www.darisus.de/ Darius]''' für 7€74 (Juli/2011) erhältlich ist,[den LPC1751 (32k/8k) schon für 5€95] und bei Digikey für 6€35, den LPC1764FBD100 bei '''[http://www.tme.eu/de TME]''' für 7€ Entwicklungskit INCLUSIVE JTAG-Programmer & Debugger bei '''[http://www.watterott.com/de/LPC1769-LPCXpresso Watterott]''' für 23€80 (Juli/2011)

=== Blockdiagram der LPC17xx Familie ===

[[Bild:LPC177x_178x Block Diagram Sep2011.png|thumb|left|680px|Blockdiagramm der LPC17xx Familie, ©NXP.com]]
 

=== Features eines LPC1754 ===
* ARM Cortex-M3 processor, running at frequencies of up to 100 MHz
* A Memory Protection Unit (MPU) supporting eight regions is included.
* ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
* 128 kB on-chip flash program memory with In-System Programming (ISP) and In-Application Programming (IAP) capabilities.
* 32 kB of SRAM on the CPU with local code/data bus for high-performance CPU access.
* Eight channel General Purpose DMA controller
* Serial interfaces:
* USB 2.0 full-speed controller that can be configured for either device, Host, or OTG operation with an on-chip PHY for device and Host functions
* Four UARTs with fractional baud rate generation, internal FIFO, IrDA, and DMA, Einer mit Modem I/Os und RS485 Support
* 1 CAN controller.
* 2 SSP controllers
* 1 SPI controller
* 2 I2C-bus interfaces with data rates of 1Mbit/s,
* I2S (Inter-IC Sound)
* 52 General Purpose I/O (GPIO) pins Any pin of ports 0 and 2 can be used to generate an interrupt.
* 8x 12-bit Analog-to-Digital Converter (ADC) conversion rates up to 200 kHz
* 1x 10-bit Digital-to-Analog Converter (DAC)
* Four general purpose timers/counters, with a total of eight capture inputs and ten compare outputs.
* One motor control PWM with support for three-phase motor control.
* Quadrature encoder interface that can monitor one external quadrature encoder.
* One standard PWM/timer block with external count input.
* Real-Time Clock (RTC) with a separate power domain including 20 bytes of battery-powered backup registers, An RTC interrupt can wake up the CPU from any reduced power mode.
* Watchdog Timer (WDT).
* Cortex-M3 system tick timer
* Repetitive interrupt timer
* Standard JTAG test/debug interface as well as Serial Wire Debug and Serial Wire Trace Port options.
* Four reduced power modes: Sleep, Deep-sleep, Power-down, and Deep power-down.
* Single 3.3 V power supply (2.4 V to 3.6 V).
* Four external interrupt inputs configurable as edge/level sensitive. All pins on PORT0 and PORT2 can be used as edge sensitive interrupt sources.
* Non-maskable Interrupt (NMI) input.
* Wakeup Interrupt Controller (WIC)
* Each peripheral has its own clock divider for further power savings.
* Brownout detect with separate threshold for interrupt and forced reset.
* On-chip Power-On Reset (POR).
* On-chip crystal oscillator with an operating range of 1 MHz to 25 MHz.
* 4 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
* An on-chip PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the main oscillator, the internal RC oscillator, or the RTC oscillator.
* Available as 80-pin LQFP (12 x 12 x 1.4 mm) packages.

== LPC18xx ==

=== Familienübersicht LPC18xx ===
Bezugsquellen und Preise:

=== Blockdiagramm der LPC18xx Familie ===
[[Bild:block.diagram_NXP18xx Sep2011.gif|thumb|left|680px|Blockdiagramm der LPC18xx Familie, ©NXP.com]]
 

=== Features eines LPC18xx ===
DRAFT!
* Processor core
** ARM Cortex-M3 processor, running at frequencies of up to 180 MHz.
** ARM Cortex-M3 built-in Memory Protection Unit (MPU) supporting eight regions.
** ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
** Non-maskable Interrupt (NMI) input.
** JTAG and Serial Wire Debug, serial trace, eight breakpoints, and four watch points.
** ETM and ETB support.
** System tick timer.
* On-chip memory (flashless parts LPC1850/30/20/10)
** Up to 200 kB SRAM total for code and data use.
** Two 32 kB SRAM blocks with separate bus access. Both SRAM blocks can be powered down individually.
** 64 kB ROM containing boot code and on-chip software drivers.
** 32-bit One-Time Programmable (OTP) memory for general-purpose customer use.
* On-chip memory (parts with on-chip flash)
** Up to 1 MB total dual bank flash memory with flash accelerator.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
** Up to 136 kB SRAM for code and data use.
** Two 32 kB SRAM blocks with separate bus access. Both SRAM blocks can be powered down individually.
** 32 kB ROM containing boot code and on-chip software drivers.
** 32-bit One-Time Programmable (OTP) memory for general-purpose customer use.
* Clock generation unit
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** 12 MHz internal RC oscillator trimmed to 1 % accuracy.
** Ultra-low power RTC crystal oscillator.
** Three PLLs allow CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. The second PLL is dedicated to the High-speed USB, the third PLL can be used as audio PLL.
** Clock output.
* Serial interfaces:
** Quad SPI Flash Interface (SPIFI) with four lanes and data rates of up to 40 MB per second total.
** 10/100T Ethernet MAC with RMII and MII interfaces and DMA support for high throughput at low CPU load. Support for IEEE 1588 time stamping/advanced time stamping (IEEE 1588-2008 v2).
** One High-speed USB 2.0 Host/Device/OTG interface with DMA support and on-chip PHY.
** One High-speed USB 2.0 Host/Device interface with DMA support, on-chip full-speed PHY and ULPI interface to external high-speed PHY.
** USB interface electrical test software included in ROM USB stack.
** Four 550 UARTs with DMA support: one UART with full modem interface; one UART with IrDA interface; three USARTs support synchronous mode and a smart card interface conforming to ISO7816 specification.
** Two C_CAN 2.0B controllers with one channel each.
** Two SSP controllers with FIFO and multi-protocol support. Both SSPs with DMA support.
** One Fast-mode Plus I2C-bus interface with monitor mode and with open-drain I/O pins conforming to the full I2C-bus specification. Supports data rates of up to 1 Mbit/s.
** One standard I2C-bus interface with monitor mode and standard I/O pins.
** Two I2S interfaces with DMA support, each with one input and one output.
* Digital peripherals:
** External Memory Controller (EMC) supporting external SRAM, ROM, NOR flash, and SDRAM devices.
** LCD controller with DMA support and a programmable display resolution of up to 1024H x 768V. Supports monochrome and color STN panels and TFT color panels; supports 1/2/4/8 bpp CLUT and 16/24-bit direct pixel mapping.
** SD/MMC card interface.
** Eight-channel General-Purpose DMA (GPDMA) controller can access all memories on the AHB and all DMA-capable AHB slaves.
** Up to 80 General-Purpose Input/Output (GPIO) pins with configurable pull-up/pull-down resistors and open-drain modes.
** GPIO registers are located on the AHB for fast access. GPIO ports have DMA support.
** State Configurable Timer (SCT) subsystem on AHB.
** Four general-purpose timer/counters with capture and match capabilities.
** One motor control PWM for three-phase motor control.
** One Quadrature Encoder Interface (QEI).
** Repetitive Interrupt timer (RI timer).
** Windowed watchdog timer.
** Ultra-low power Real-Time Clock (RTC) on separate power domain with 256 bytes of battery powered backup registers.
** Alarm timer; can be battery powered.
* Digital peripherals available on flash-based parts LPC18xx only:
** <tbd>
* Analog peripherals:
** One 10-bit DAC with DMA support and a data conversion rate of 400 kSamples/s.
** Two 10-bit ADCs with DMA support and a data conversion rate of 400 kSamples/s.
* Security:
** Hardware-based AES security engine programmable through an on-chip API.
** Two 128-bit secure OTP memories for AES key storage and customer use.
** Unique ID for each device.
* Power:
** Single 3.3 V (2.2 V to 3.6 V) power supply with on-chip internal voltage regulator for the core supply and the RTC power domain.
** RTC power domain can be powered separately by a 3 V battery supply.
** Four reduced power modes: Sleep, Deep-sleep, Power-down, and Deep power-down.
** Processor wake-up from Sleep mode via wake-up interrupts from various eripherals.
** Wake-up from Deep-sleep, Power-down, and Deep power-down modes via external interrupts and interrupts generated by battery powered blocks in the RTC power domain.
** Brownout detect with four separate thresholds for interrupt and forced reset.
** Power-On Reset (POR).
* Available as 100-pin, 144-pin, and 208-pin LQFP packages and as 100-pin, 180-pin, and 256-pin LBGA packages.

== Entwicklungsumgebungen ==
=== LPCWare (kostenlos) ===
[[Bild:lpcxpresso-debug_Code-red_3Sep2011.gif|thumb|right|680px|Ansicht der Entwicklungsumgebung, ©code-red-tech.com]]

==== Entwicklungs Tool ====
(Beschreibung aus der Web-Site:)
LPCXpresso's IDE (Ursprünglich von "Code RED" entwickelt, die Firma wurde 2013 von LPC gekauft) ist eine hoch integrierte Entwicklungsumgebung für LPC-Controller, und beinhaltet alle zur Entwicklung erforderlichen Tools um hoch qualitative Software in einer angemessenen Zeit zu schreiben. LPCXpresso basiert auf ein vereinfachtes Eclipse mit vielen LPC-specifischen Erweiterungen.
Des Weiteren ist eine aktuelle Version der Industrie-Standard GNU Tool-Chain mit einer propritären und optimierten C-Lib mit dabei. Die LPCXpresso IDE stellt ein voll optimiertes Executable zur Verfügung. Die einzige Beschränkung der kostenlosen Version ist eine Limitierung auf 256kB Code nach erfolgter Registrierung.
Das LPCXpresso Target Board ist eine Gemeinschaftsentwicklung von Embedded Artists, Code Red und NXP.

==== Features ====
Die LPCXpresso IDE stellt eine C-Umgebung mit Syntax-Colouring, Source-Formatierung, Funktions-Folding, sowie mit Online- und Offline Hilfe und umfangreichen Projekt-Management Funktionen zur Verfügung.
Dies beinhaltet:
* Wizards um Projekte für alle unterstützten Controller zu erstellen
* Automatische Linker Script Generierung inklusive Memory-Map Unterstützung
* Programmierung des Controllers
* On-Line Debugging
* Datenblatt-Zugriff über eingebauten Browser
* Support für die NXP LPC Microcontroller Familien, von Cortex-M0, Cortex-M3 bis Cortex-M4 und ARM7 bis ARM9

==== Peripherie und Register Views im Debugger ====
Der Peripherie-Viewer im integrierten Debugger zeigt alle Register und Bit-Felder in einer einfachen Baumstruktur.
Ein Prozessor-Register Viewer erlaubt den Zugriff auf alle Prozessor-Register und stellt eine "Smart-Formatting" Funktion zur Verfügung um komplexe Register wie Flags oder Status Register übersichtlich darstellen zu können.

==== Unterstützte Familien ====
Cortex-M0, Cortex-M3, Cortex-M4, Einzelne Controller aus der LPC2000 family, ARM966, ARM926-EJ, ARM926-EJ + VFP

==== Sehr preiswerter USB_JTAG_SWD Debugger ====
Von NXP sind sehr preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG Programmer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)]''' und diese '''[http://www.mikrocontroller.net/wikisoftware/index.php?title=LPC1xxx_Entwicklungskit_LPCXpresso Beschreibung]'''
Der neue Programmer/Debugger ist hier für ca 18€ +P&P erhältlich '''[http://www.watterott.com/de/LPC-Link-2 Programmer]'''

==== Standard Library ====
Im Download der "Code Red" Entwicklungsumgebung ist eine relativ umfangreiche Firmwarebibliothek vorhanden.

==== Installationsanleitung zur IDE ====
'''[http://www.mikrocontroller.net/articles/Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red Installationsanleitung]'''

==== Codebase für LPC11xx und LPC13xx ====
Für die Cortex-M0 und -M3 Familien existieren verschiedene Basispakete die als Startausstattung sehr gut geeignet sind. Auf microbuilder.eu findet man eine sehr interessante Version inklusive Dokumentation.

'''[http://www.mikrocontroller.net/articles/Codebase_f%C3%BCr_LPC1xxx HIER]''' findet man alle Links zur original Codebase mit allen Dateien (Stand Januar 2012) aber auch eine deutsche Übersetzung zu den Files.

=== CooCox ===

Auf der '''[http://www.coocox.org/Index.html Homepage]''' von CooCox - einem chinesischen Open-Source Projekt, auf der eine IDE für Atmel, Energy Micro, Holtek, Nuvoton, ST, TI und NXP verfügbar ist - findet man die auf Eclipse basierende "CooCox CoIDE", die sich aus dem "CoBuilder" und dem "CoDebugger" zusammensetzt.
Des Weiteren bietet man dort ein Echtzeit-Multitasking Betriebssystem, sowie SW-Versionen von zwei unterschiedliche Debugging-Adapter und ein Stand-alone Flash-Tool zum freien Download an.

Die folgenden Controller können damit programmiert und debugged werden:
LPC1111x101 LPC1111x201 LPC1112x101 LPC1112x201
LPC1113x201 LPC1113x301 LPC1114x201 LPC1114x301
LPC11C14x301 LPC11C12x301
LPC1224x101 LPC1224x121 LPC1225x301 LPC1225x321 LPC1226x301 LPC1227x301

LPC1311 LPC1313 LPC1342 LPC1343
LPC1751 LPC1752 LPC1754 LPC1756 LPC1758 LPC1759
LPC1763 LPC1764 LPC1765 LPC1766 LPC1767 LPC1768 LPC1769

=== EmBlocks ===
'''[http://www.emblocks.org/web/ Emblocks]''' ist eine kostenlose Entwicklungsumgebung. Sie unterstützt neben NXP uC weitere ARM uC (STM32, EFM32) sowie PIC, AVR und MSP430. Die IDE hat einen eingebauten GDB Debugger welcher System view (Peripherie Register anzeigen) beim Debuggen unterstützt. Ausserdem gibt es einen Project Wizzard für NXP uC 
Unterstützt wird der JLINK mit folgenden NXP uC:
LPC11Axx, LPC11Exx, LPC11Uxx, LPC11xxLV, LPC12xx, LPC13Uxx, LPC13xx, LPC17xx, LPC18xx, LPC18xx, LPC177x_8x, LPC407x_8x

=== Codebase ===
Des Weiteren existiert eine umfangreiche Sammlung von '''[http://www.coocox.org/NXP-Series.php Code-Beispielen]'''.

=== Keil ===
[https://www.keil.com/demo/eval/arm.htm KEIL MDK-ARM] (Windows, Free Version auf 32KB begrenzt, mit vielen Beispielen zu div. Evaluation Boards)
*[http://www.keil.com/arm/chips.asp unterstützte Mikrocontroller]
=== WinARM ===
[http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm WinARM] (wird derzeit nicht gepflegt)

=== GNUARM ===
[http://gnuarm.com/ GNUARM] (Linux, Windows, wird derzeit nicht gepflegt),

=== Yagarto ===
[http://www.yagarto.de/ Yagarto] (Windows, mit Eclipse-Integration)

=== CodeSourcery ===
[http://www.codesourcery.com/gnu_toolchains/arm CodeSourcery CodeBench Lite]

== CMSIS - Standard für alle Plattformen ==
Der Cortex Microcontroller Software Interface Standard (CMSIS) stellt einen "abstraction layer" für alle Cortex-Mx Controller zur Verfügung.

CMSIS stellt einen Schnittstellenstandard von ARM dar, der von vielen Tool-Herstellern unterstützt wird und ist (laut verschiedener Berichte) kompatibel mit den verschiedensten Compilern (incl GCC). Dies wird erreicht durch einheitliche Definitionen für Adressen und Namen die den Zugriff auf die Register des Cores und der Peripherie ermöglichen.
Auch Standard-Funktionen für den Start und die Interrupts stehen zur Verfügung.
Natürlich kann auch weiterhin direkt auf die HW zugegriffen werden, es geht nur um eine Vereinheitlichung von identischen Funktionen.
Da die Peripherie-Teile zumindest innerhalb eines Halbleiterherstellers für die Cortex-Mx Controller sehr ähnlich oder sogar weitgehend identisch sind kann deutlich mehr SW für verschiedene Derivate innerhalb dieser Prozessorfamilien wiederverwendet werden. (siehe Google: "CMSIS_Doulos_Tutorial.pdf").

Ein weiterer, interessanter Punkt ist die CMSIS-DSP Lib mit ihren Vektorfunktionen, Matrix-Berechnung sowie komplexen Algorithmen für Filter,
Regler und Fourietransformation sowie weiterer DSP Algorithmen (insgesamt 61).

Leider hat diese Kompatibilität auch ihre Grenzen, denn Sonderfunktionen bzw. Spezialitäten in der "gleichen" Peripherie zwischen unterschiedlichen Halbleiterherstellern werden nicht abgedeckt.
Wäre auch zu schön, wenn die Prozesorhersteller dem Entwickler dadurch einen fliegenden HW-Wechsel bzw. eine einfache Vergleichbarkeit ermöglichen würden ;-)

Eine komplette CMSIS-Lib (V2.0) "Cortex Microcontroller Software Interface Standard" ist für das "Code Red" Paket verfügbar, inklusive einer "DSP-Library"
http://support.code-red-tech.com/CodeRedWiki/NewInVersion4
bzw. für GNU / Keil / IAR unter
http://ics.nxp.com/support/documents/microcontrollers/?search=CMSIS&type=software&Search.x=8&Search.y=12

== Links ==

* Wiki
** '''[[LPC1xxx_Entwicklungskit_LPCXpresso]]'''
** '''[[Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red]]'''
** '''[[Codebase_f%C3%BCr_LPC1xxx]]'''
** '''[[LPC1xxx für Umsteiger]]'''

* Projekte
** [http://www.mikrocontroller.net/topic/264089 FreeRTOS auf LPC1768]
** [http://www.mikrocontroller.net/topic/321481 Multithreading auf LPC8xx]
** [http://www.mikrocontroller.net/topic/319537 Python Script zum Flashen des LPC8xx]

* Suche im Forum
** [http://www.mikrocontroller.net/search?query=LPC8* LPC8xx]
** [http://www.mikrocontroller.net/search?query=LPC11* LPC11xx]
** [http://www.mikrocontroller.net/search?query=LPC11* LPC11xx]
** [http://www.mikrocontroller.net/search?query=LPC12* LPC12xx]
** [http://www.mikrocontroller.net/search?query=LPC13* LPC13xx]
** [http://www.mikrocontroller.net/search?query=LPC17* LPC17xx]
** [http://www.mikrocontroller.net/search?query=LPC18* LPC18xx]

== Bezugsquellen ==

=== Controller ===
(Die Preiswertesten sind '''fett''' dargestellt)
* '''[http://darisusgmbh.de/shop/advanced_search_result.php?keywords=LPC1&x=0&y=0 Darisus]'''
* '''[http://www.elpro.org/shop/shop.php elpro]'''
* [http://www.hbe-shop.de HBE]
* [http://www.tme.eu/de/katalog#cleanParameters%3D1%26searchClick%3D1%26search%3DLPC1%26bf_szukaj%3D+ TME]
* [http://www.tn-electronics.de/advanced_search_result.php?keywords=LPC1&x=0&y=0 TN]
* [http://de.mouser.com/_/?Keyword=LPC1&Ns=Pricing|0&FS=True Mouser]
* [http://www.soselectronic.eu/?searchstring=LPC1&str=378 SOS]
* [http://de.farnell.com Farnell/Element14]

=== Evaluation Boards ===
* [http://www.watterott.com/index.php?page=search&page_action=query&desc=off&sdesc=on&keywords=LPCXpresso Watterott (24€ inclusive JTAG-Programmiergerät UND JTAG Debugger für kostenlose "Code-Red" Entwicklungsplattform)], dazu hier die [[LPC1xxx_Entwicklungskit_LPCXpresso|Beschreibung]]
* [http://www.lpctools.com/evaluationboardskitsforlpc17xx.aspx LPC-Tools]
* [http://thinkembedded.ch/NXP:::25.html thinkembedded.ch] div. Olimex Boards

== Weblinks, Foren, Communities ==

* http://www.nxp.com/#/page/content=[f=/dynamic/applicationnotes/tid-50809_sid-56890/data.xml] Appnotes
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html Projects]
* [http://mbed.org/handbook/Homepage MBED]
* [http://forums.nxp.com/forums/viewforum.php?f=1 NXP-WIKI]
* [http://knowledgebase.nxp.com/forumdisplay.php?s=389a3610c741bca7b18221d32b9c0ce0&f=4 NXP-Forum]
* [http://ics.nxp.com/lpcxpresso/ LPCXpresso]
* [http://code.google.com/p/32bitmicro/ 32BitMicro]
* [http://www.brc-electronics.nl SimpleCortex]
* [http://www.lpcware.com/ LPCWare NXP MCU community]
* [http://nanohome.be/nxp/index.html LPC175/6x und LPC23xx pin Configurator]
* [https://code.google.com/p/lpc-1768-arm-synthesizer/ MIDI controlled monophonic synthesizer based on the LPCXpresso 1768.]
* [https://code.google.com/p/lpc1343codebase/ An open source software library for NXP's Cortex-M3 based LPC1300 microcontroller family]
* [https://code.google.com/p/lpc1114codebase/ An open source software library for NXP's Cortex-M0 based LPC1100 microcontroller family]
* [https://code.google.com/p/lpc-12xx-bootloader/ A flexible bootloader for use with LPC12xx Microcontrollers from NXP, Firmware code is AES128 encrypted to secure your project / source code when giving out public firmware updates. ]
* [https://code.google.com/p/lpcxpresso-rc/ Read receiver and sensor signals for radio controlled model aircrafts configured for LPCXpresso]
* [https://code.google.com/p/olpcx/ Open toolset for LPCXpresso]
* [https://code.google.com/p/32bitmicro/ Collection of code and tools for 32 bit microcontrollers]
* [https://code.google.com/p/my-nxp-lpc1114/ my-nxp-lpc1114 study course]
* [https://code.google.com/p/nxp-lpc/ nxp-lpc]

== Entwicklungsplattformen ==

* [http://www.lpcware.com/lpcxpresso/home LPDXpresso Download (Kostenlos mit Debugger)]
* [http://www.lpcware.com LPCXpresso Homepage]
* [http://support.code-red-tech.com/CodeRedWiki/WikiHome CR-WIKI]
* [http://www.keil.com/arm/mdk.asp ARM/Keil MDK-ARM]
* IAR EWARM
* Rowley Crossworks
* Green Hills Software
* [http://www.coocox.org/CooCox_CoIDE.htm CooCox] (Kostenlos)

<references/>

[[Kategorie:ARM]]
[[Kategorie:LPC1x]]

LPC-Mikrocontroller

2017-03-03T14:42:39Z

Newgeneration: Tabelle überarbeitet und sortierbar gemacht

[[Bild:overview_Sep2011.png|thumb|right|850px|Überblick über die aktuelle Cortex M0/3 Familie, ©NXP.com]]
[[Bild:positioning_NXPSep2011.gif|thumb|right|850px|Vergleich über die aktuelle Cortex M0/3 Familie, ©NXP.com]]

Die LPC-Familie von NXP basiert auf 32-Bit Cortex-Kernen von ARM und arbeitet mit bis zu 204MHz. Die verschiedenen Serien basieren auf den Cortex-M0/M0+/M3/M4-Kernen und sind inzwischen auch für Privatnutzer zu Preisen erhältlich, die mit denen von 8-Bit-Mikrocontrollern vergleichbar sind. Eine Auflistung der verschiedenen Typen findet sich in der Tabelle unten.

Von NXP sind preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG Programmer und Debugger oder den neuen LPC-Link2, ein reiner Programmer + Debugger) erhältlich z.B. bei [http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]. Siehe dazu auch die Dokumentation von NXP zu den [http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)] und diese [[LPC1xxx Entwicklungskit LPCXpresso]].

== Vergleich aller Typen ==
''Stand Feb. 2017''
{| class="wikitable sortable"
! rowspan="2" class="unsortable" |
! rowspan="2" style="text-align: center;" | CPU
! rowspan="2" style="text-align: center;" | Max. Frequency
! rowspan="2" style="text-align: center;" | Flash
! rowspan="2" style="text-align: center;" | SRAM
! rowspan="2" style="text-align: center;" | Voltage
! rowspan="2" style="text-align: center;" class="unsortable" | Features
|-
| LPC800
| style="text-align: center;" data-sort-value="2" | Cortex-M0+
| style="text-align: center;" data-sort-value="30" | 30MHz
| style="text-align: center;" data-sort-value="8" | 8-32kB
| style="text-align: center;" data-sort-value="1" | 1-8kB
| style="text-align: center;" data-sort-value="1.8" | 1.8-3.6V
| style="text-align: center;" |
SCTimer/PWM,
Switch Matrix,
Pattern Match Engine
|-
| LPC54000
| style="text-align: center;" data-sort-value="4" | Cortex-M41
| style="text-align: center;" data-sort-value="180" | 180MHz
| style="text-align: center;" data-sort-value="128" | 128-512kB
| style="text-align: center;" data-sort-value="96" | 96-200kB
| style="text-align: center;" data-sort-value="1.62" | 1.62-3.6V
| style="text-align: center;" |
USB,
CAN,
LCD,
Ethernet,
FlexComm,
Security
|-
| LPC1100
| style="text-align: center;" data-sort-value="1" | Cortex-M0/M0+
| rowspan="2" style="text-align: center;" data-sort-value="50" | 50MHz
| style="text-align: center;" data-sort-value="4" | 4-256kB
| style="text-align: center;" data-sort-value="1" | 1-36kB
| style="text-align: center;" data-sort-value="1.71" | 1.71-3.6V
| style="text-align: center;" |
USB,
CAN,
EEPROM
|-
| LPC1200
| style="text-align: center;" data-sort-value="0" | Cortex-M0
| style="text-align: center;" data-sort-value="32" | 32-128kB
| style="text-align: center;" data-sort-value="4" | 4-8kB
| style="text-align: center;" data-sort-value="1.8" | 1.8-3.6V
| style="text-align: center;" |
8 kV protection,
IEC 60730 Class B certified
|-
| LPC1300
| rowspan="4" style="text-align: center;" data-sort-value="3" | Cortex-M3
| rowspan="2" style="text-align: center;" data-sort-value="72" | 72MHz
| style="text-align: center;" data-sort-value="8" | 8-64kB
| style="text-align: center;" data-sort-value="4" | 4-12kB
| style="text-align: center;" data-sort-value="2.0" | 2.0-3.6V
| style="text-align: center;" |
USB
|-
| LPC1500
| style="text-align: center;" data-sort-value="64" | 64-256kB
| style="text-align: center;" data-sort-value="12" | 12-36kB
| style="text-align: center;" data-sort-value="2.4" | 2.4-3.6V
| style="text-align: center;" |
USB,
CAN,
QEI
|-
| LPC1700
| style="text-align: center;" data-sort-value="120" | 120MHz
| style="text-align: center;" data-sort-value=" | 32-512kB
| style="text-align: center;" data-sort-value="8" | 8-96kB
| style="text-align: center;" data-sort-value="2.4" | 2.4-3.6V
| style="text-align: center;" |
USB,
CAN,
Ethernet,
LCD,
QEI
|-
| LPC1800
| style="text-align: center;" data-sort-value="180" | 180MHz
| style="text-align: center;" data-sort-value="512" | Flashless,
512kB-1MB
| style="text-align: center;" data-sort-value="104" | 104-200kB
| style="text-align: center;" data-sort-value="2.4" | 2.4-3.6V
| style="text-align: center;" |
Dual HS USB,
CAN,
Ethernet,
LCD,
Security
|-
| LPC4000
| style="text-align: center;" data-sort-value="4" | Cortex-M4
| style="text-align: center;" data-sort-value="120" | 120MHz
| style="text-align: center;" data-sort-value="64" | 64-512kB
| style="text-align: center;" data-sort-value="24" | 24-96kB
| style="text-align: center;" data-sort-value="2.4" | 2.4-3.6V
| style="text-align: center;" |
USB,
CAN,
Ethernet,
LCD
|-
| LPC4300
| style="text-align: center;" data-sort-value="4" | Cortex-M41
| style="text-align: center;" data-sort-value="240" | 204MHz
| style="text-align: center;" data-sort-value="512" | Flashless,
512kB-1MB
| style="text-align: center;" data-sort-value="104" | 104-282kB
| style="text-align: center;" data-sort-value="2.4" | 2.4-3.6V
| style="text-align: center;" |
Dual HS USB,
CAN,
Ethernet,
LCD,
SGPIO,
Security
|}
1: gibt es auch als Mehrkern-Prozessoren (mit 0/1/2 Cortex-M0(+)-Cores)

== Allgemeine Informationen ==

== Allgemeine Infos + User-Manuals==

=== Eckdaten LPC8xx (Cortex-M0+) ===
Die sehr stromsparende '''[http://www.nxp.com/products/microcontrollers/cortex_m0_m0/series/LPC800.html#quickreference LPC8xx]''' ist nur in Packages mit einer relativ niedrigen Pinanzahl (DIP8, SO20, TSSOP16, TSSOP20) verfügbar, hat zwischen 4-16kB Flash, und 1-4kB RAM. Die zulässige Betriebsspannung liegt zwischen 1,8V und 3,6V.

Überblick über die Features der LPC800-Serie:
* 1 I2C
* 1-2 SSP
* 2-3 UART
* 4 Timer, 1 OS-Timer
* 1 watch dog
* 4 PWM-Einheiten
* 10-bit ADC.

'''[http://www.nxp.com/download/grouping/11045/user_manual User Manual der LPC8-Familie (PDF)]'''

=== Eckdaten LPC11xx (Cortex-M0) ===
Die sehr stromsparende '''[http://ics.nxp.com/products/lpc1000/lpc11xx/ LPC11xx-Serie]''' (3,3V) bietet viele Möglichkeiten
* Der LPC1100L ist derzeit laut NXP (Sep2011) der preisgünstigste ARM auf dem Markt. Der 32Bit ARM mit einer Performance von ca. 45DMIPS @50MHZ benötigt bei dieser Taktfrequenz nur etwa 10mA. (Details siehe NXP-Seite)

* Überblick über die Features :
** LPC1100 Serie: • I2C, SSP, UART, GPIO, • Timers and watch dog timer, • 10-bit ADC, • Flash/SRAM memory, • Weitere Funktionen, siehe '''[http://www.mikrocontroller.net/articles/LPC1xxx#Features_eines_LPC11xx 2.3 Features]'''
** LPC1100L Serie zusätzlich zu LPC1100: • Power Profile mit lower power consumption in Active- und Sleep-mode, • Interne pull-ups auf VDD level, • Programmierbarer pseudo open-drain mode für GPIO Pins, • WWDT mit Clock Source Lock.
**LPC11C00 Serie zusätzlich zu LPC1100: • CAN controller, • On-chip CAN Treiber, • On-chip CAN Transceiver (LPC11C2x), • WDT (not windowed) mit Clock Source Lock.

'''[http://www.nxp.com/documents/user_manual/UM10398.pdf User Manual der LPC11-Familie (PDF)]'''

* Besonderes Augenmerk möchte ich auf die neue Serie '''[http://www.nxp.com/ps/#/i=71498 LPC111xFD]''' legen, denn in jetzt gibt es den Cortex-M0 auch im DIL 28 '''[http://www.nxp.com/redirect/pip/LPC1114FN28.html den LPC1114FN28]'''
**Des Weiteren sind damit SO20, sowie TSSOP20 und TSSOP28 Bauformen verfügbar

=== Eckdaten LPC12xx (Cortex-M0) ===
* Die Low Power '''[http://ics.nxp.com/products/lpc1000/lpc12xx/ LPC12xx-Serie]''' (3,3V) ist laut NXP (Sep2011) ein Cortex-M0 mit 32 bis 128kB Flash, einem 45 CoreMark™ Benchmark-Score bei 30MHz, 2 bis 8kB SRAM, und einem internen 1% genauen 12MHz Oscillator.

* Überblick über die Features: fMAX von 30MHz, 1 10-Bit ADC mit 8 Kanälen, 2 Comparatoren, 2 UARTs, 1 SSP/SPI, 1 I2C, DMA Controller, CRC Engine, 1 32-Bit, 5 Timer (16- und 32-Bit, + RTC), 13 PWM Kanäle, bis zu 55 GPIOs.

'''[http://www.nxp.com/documents/user_manual/UM10441.pdf User Manual der LPC12xx-Familie (PDF)]'''

=== Eckdaten LPC13xx (Cortex-M3) ===
Die sehr stromsparende '''[http://ics.nxp.com/products/lpc1000/lpc13xx/ LPC13xx-Serie]''' (3,3V) bietet im LQFP 48 Gehäuse 8..32k Flash, 2..8k SRAM, 5 Timer (mit WD), 11 PWM, 1 UART, 1IIC, 1USB, 1..2 SPI, einen 8-Kanal/10Bit AD-Wandler und eine Taktfrequenz von max. 72MHz.

'''[http://www.nxp.com/documents/user_manual/UM10375.pdf User Manual der LPC13xx-Familie (PDF)]'''

=== Eckdaten LPC17xx (Cortex-M3) ===
Die '''[http://ics.nxp.com/products/lpc1000/lpc17xx/ LPC17xx-Serie]''' hingegen enthält eine weit größere Peripherie in einem LQFP80/100/144/208 Package.
32..512k Flash, 8..96k SRAM, 6 Timer (mit WD), 6 zusätzliche PWM-Einheiten, teilweise Ethernet und STN/TFT-LCD-Controller, meist USB (teilw. mit Host+OTG), 4 UART, 2..3IIC, 1..2 CAN, 1 SPI, 2 SSP/SPI einen 6..8-Kanal/12Bit AD-Wandler, einen 10Bit DAC, Motor-Control-Einheiten, einen Encoder-Eingang und eine Taktfrequenz von max. 100MHz(120MHz) und vieles mehr.

'''[http://www.nxp.com/documents/user_manual/UM10360.pdf User Manual der LPC17xx-Familie (PDF)]'''

=== Eckdaten LPC18xx (Cortex-M3) ===
Die '''[http://ics.nxp.com/products/lpc1000/lpc18xx/ LPC18xx-Serie]''' stellt DIE "High-Performance" Controller aus der Cortex-M3-Serie. Die Taktfrequenz geht bis 150MHz, die Controller enthalten große dual-Bank Flash Speicher bis zu 1MB, ein großes On-Chip SRAM mit bis zu 200KB, zusätzliche Peripherie wie z.B. SPI Flash Interface (SPIFI) und State Configurable Timer (SCT), 2x High Speed USB (1x mit On-Chip HS PHY) und eine MPU.

'''[http://ics.nxp.com/support/documents/microcontrollers/pdf/user.manual.lpc18xx.pdf User Manual der LPC18xx-Familie (PDF)]'''

Überblick über die Features: '''[http://ics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc18xx.pdf LPC18xx Flyer von NXP]'''

=== Entwicklungskits ===
Von NXP sind sehr preiswerte Entwicklungskits (ca. 25€ für. USB-JTAG Programmer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)]'''.

=== Kostenlose Entwicklungsumgebung für ALLE hier genannten Controller ===
Für die ganze Prozessorfamilie ist eine kostenlose Entwicklungsumgebung erhältlich. Informationen unter '''[http://www.lpcware.com/lpcxpresso/home lpcware]''': Die auf Eclipse basierende Entwicklungsumgebung ist nach der Installation bis 8k freigeschaltet und nach einer einfachen und kostenlosen Registrierung für 256kB. Die IDE ist auch für '''[http://www.lpcware.com/lpcxpresso/home Linux und Mac]''' verfügbar.

Hier die '''[http://www.mikrocontroller.net/articles/Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red Installationsanleitung]'''

== LPC8xx ==

=== Familienübersicht LPC8xx ===
Bezugsquellen und Preise (Stand 06/2016)
* LPC810FN8 (DIP8): Digikey 1,09 € (bei einem Stuck).
* LPC812JD20 (SOIC-W 20): Digikey 1,26 € (bei einem Stuck).
* LPC812JDH20 (TSSOP-20): Digikey 1,44 € (bei einem Stuck).

[[Bild:LPC800_block_diagram_Jan2014.gif|thumb|right|850px|Blockdiagramm des Cortex-M0+, ©NXP.com]]

=== Blockdiagramm der LPC8xx Familie ===

=== Features eines LPC8xx ===
* System:
** ARM Cortex-M0+ processor, running at frequencies of up to 30 MHz.
** single cycle multiplier
** single cycle I/O port
** ARM Cortex-M0+ built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug, Micro Trace Buffer supported.
** System tick timer.
* Memory:
** 16 kB (LPC812M101JD20/LPC812M101JDH20/LPC812M101JDH16), 8 kB (LPC811M001JDH16) or 4kB (LPC810M021FN8) on-chip flash programming memory.
** 4kB, 2 kB, or 1 kB SRAM.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* Digital peripherals:
** Up to 18 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors. Number of GPIO pins is reduced for smaller packages down to 6.
** GPIO pins can be used as edge and level sensitive interrupt sources.
** High-current output driver (20 mA) on one pin.
** High-current sink drivers (20 mA) on two open drain pins.
** Four general purpose timers/counters with a total of four capture inputs and up to 13 match outputs.
** Programmable WatchDog Timer (WDT).
** '''Switch matrix for flexible configuration of each I/O pin function.'''
** CRC engine
* Analog peripherals:
** Comparator with internal and external references and 31 step voltage divider.
* Serial interfaces:
** UART with fractional baud rate generation, internal FIFO, and RS-485 support.
** SPI controllers with SSP features and with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Clock generation:
** 12 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** Programmable watchdog oscillator with a frequency range of 9.4 kHz to 2.3 MHz.
** 10 kHz low-power oscillator for the WKT.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, and the Watchdog clock.
* Power control:
** Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
** Power profiles residing in boot ROM allowing to optimize performance and minimize power consumption for any given application through one simple function call.
** Reduced power modes: Sleep mode, Deep-sleep mode, Power-down mode, and Deep power-down mode.
** Wake-up from Deep-sleep and Power-down modes on activity on USART, SPI, and I2C peripherals.
** Brownout detect.
* Unique device serial number for identification.
* Single 3.3 V power supply (1.8 V to 3.6 V).
* Available as DIP8, TSSOP16, SO20, and TSSOP20 package.

== LPC11xx ==

=== Familienübersicht LPC11xx ===
Bezugsquellen und Preise (Stand 01/2014):

elpro.org: von 1.61EUR (LPC1111FN33) bis 5.73EUR (LPC11U37) bei einen Stueck. Die Familie ist sehr gross mit sehr unterschiedlichen Ausfuehrungen.

[[Bild:Block.diagramM0_NXPSep2011.gif|thumb|right|850px|Blockdiagramm des Cortex-M0, ©NXP.com]]

=== Blockdiagramm der LPC11xx Familie ===

=== Features eines LPC11xx ===
* System:
** ARM Cortex-M0 processor, running at frequencies of up to 50 MHz.
** ARM Cortex-M0 built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug.
** System tick timer.
* Memory:
** 32 kB (LPC1114/LPC11C14), 24 kB (LPC1113), 16 kB (LPC1112/LPC11C12), or 8 kB (LPC1111) on-chip flash programming memory.
** 8 kB, 4 kB, or 2 kB SRAM.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* Digital peripherals:
** Up to 42 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors. Number of GPIO pins is reduced for smaller packages and LPC11C22/C24.
** GPIO pins can be used as edge and level sensitive interrupt sources.
** High-current output driver (20 mA) on one pin.
** High-current sink drivers (20 mA) on two open drain pins.
** Four general purpose timers/counters with a total of four capture inputs and up to 13 match outputs.
** Programmable WatchDog Timer (WDT).
* Analog peripherals:
** 10-bit ADC with input multiplexing among 8 pins.
* Serial interfaces:
** UART with fractional baud rate generation, internal FIFO, and RS-485 support.
** SPI controllers with SSP features and with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Clock generation:
** 12 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** Programmable watchdog oscillator with a frequency range of 7.8 kHz to 1.8 MHz.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, and the Watchdog clock.
* Power control:
** Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
** Power profiles residing in boot ROM allowing to optimize performance and minimize power consumption for any given application through one simple function call.
** Processor wake-up from Deep-sleep mode via a dedicated start logic using up to 13 of the functional pins.
** Power-On Reset (POR).
** Brownout detect with four separate thresholds for interrupt and forced reset.
* Unique device serial number for identification.
* Single 3.3 V power supply (1.8 V to 3.6 V).
* Available in the following packages: 16WLCSP, 25WLCSP 20-SOIC, 20-TSSOP, 28-DIP, 28-TSSOP, 48-LQFP, 64-LQFP, 100-LQFP, and others.

== LPC12xx ==

=== Familienübersicht LPC12xx ===
Bezugsquellen und Preise:

[[Bild:block.diagramM0_NXPSep2011.gif|thumb|right|850px|Blockdiagramm des Cortex-M0, ©NXP.com]]

=== Blockdiagramm der LPC12xx Familie ===

=== Features eines LPC12xx ===

* Processor core
** ARM Cortex-M0 processor, running at frequencies of up to 45 MHz (one wait state from flash) or 30 MHz (zero wait states from flash). The LPC122x have a high score of over 45 in CoreMark CPU performance benchmark testing, equivalent to 1.51/MHz.
** ARM Cortex-M0 built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug (SWD).
** System tick timer.
* Memory
** Up to 8 kB SRAM.
** Up to 128 kB on-chip flash programming memory.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
** Includes ROM-based 32-bit integer division routines.
* Clock generation unit
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** 12 MHz Internal RC (IRC) oscillator trimmed to 1 % accuracy that can optionally be used as a system clock.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, main clock, and Watchdog clock.
** Real-Time Clock (RTC).
* Digital peripherals
** Micro DMA controller with 21 channels.
** CRC engine.
** Two UARTs with fractional baud rate generation and internal FIFO. One UART with RS-485 and modem support and one standard UART with IrDA.
** SSP/SPI controller with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode. I2C-bus pins have programmable glitch filter.
** Up to 55 General Purpose I/O (GPIO) pins with programmable pull-up resistor, open-drain mode, programmable digital input glitch filter, and programmable input inverter.
** Programmable output drive on all GPIO pins. Four pins support high-current output drivers.
** All GPIO pins can be used as edge and level sensitive interrupt sources.
** Four general purpose counter/timers with four capture inputs and four match outputs (32-bit timers) or two capture inputs and two match outputs (16-bit timers).
** Windowed WatchDog Timer (WWDT).
* Analog peripherals
** One 8-channel, 10-bit ADC.
** Two highly flexible analog comparators. Comparator outputs can be programmed to trigger a timer match signal or can be used to emulate 555 timer behavior.
* Power
** Three reduced power modes: Sleep, Deep-sleep, and Deep power-down.
** Processor wake-up from Deep-sleep mode via start logic using 12 port pins.
** Processor wake-up from Deep-power down and Deep-sleep modes via the RTC.
** Brownout detect with three separate thresholds each for interrupt and forced reset.
** Power-On Reset (POR).
** Integrated PMU (Power Management Unit).
* Unique device serial number for identification.
* 3.3 V power supply.
* Available as 64-pin and 48-pin LQFP package.

== LPC13xx ==

=== Familienübersicht LPC13xx ===
[[Bild:LPC13xx_Selection_Guide_Sep2011.png|thumb|left|600px|Selection Guide zur LPC13xx Familie, ©NXP.com]]
 

Bezugsquellen und Preise:

LPC1313 mit 32k-Flash mit 72MHz im LQFP 48 Gehäuse. Der LPC1313 ist bei '''[http://www.darisus.de/ Darius]''' erhältlich für 3,57 € (Juli 2016), oder elpro.org für 2,29 €. Entwicklungskit INKLUSIVE JTAG-Programmer & Debugger bei '''[http://www.watterott.com/de/LPC1343-LPCXpresso-Board Watterott]''' für 23,80 € (Juli 2011)

=== Blockdiagram der LPC13xx Familie ===

[[Bild:LPC13xx Block Diagram Sep2011.png|thumb|left|680px|Blockdiagramm der LPC13xx Familie, ©NXP.com]]
 

=== Features eines LPC1313 ===
* ARM Cortex-M3 processor, running at frequencies of up to 72 MHz.
* ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
* 32 kB on-chip flash programming memory.
* 8 kB SRAM.
* In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* UART with fractional baud rate generation, modem, internal FIFO, and RS-485/EIA-485 support.
* SSP controller with FIFO and multi-protocol capabilities.
* Additional SSP controller on LPC1313FBD48/01.
* I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Up to 42 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors.
* Four general purpose counter/timers with a total of four capture inputs and 13 match outputs.
* Programmable Watchdog Timer (WDT)
* System tick timer.
* Serial Wire Debug and Serial Wire Trace port.
* High-current output driver (20 mA) on one pin.
* High-current sink drivers (20 mA) on two I2C-bus pins in Fast-mode Plus.
* Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
* Three reduced power modes: Sleep, Deep-sleep, and Deep power-down.
* Single power supply (2.0 V to 3.6 V).
* 10-bit ADC with input multiplexing among 8 pins.
* GPIO pins can be used as edge and level sensitive interrupt sources.
* Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, or the watchdog clock.
* Processor wake-up from Deep-sleep mode via a dedicated start logic using up to 40 of the functional pins.
* Brownout detect with four separate thresholds for interrupt and one thresholds for forced reset.
* Power-On Reset (POR).
* Integrated oscillator with an operating range of 1 MHz to 25 MHz.
* 12 MHz internal RC oscillator trimmed to 1 % accuracy over the entire temperature and voltage range that can optionally be used as a system clock.
* Programmable watchdog oscillator with a frequency range of 7.8 kHz to 1.8 MHz. System PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
* Code Read Protection (CRP) with different security levels.
* Unique device serial number for identification.
* Available as 48-pin LQFP package and 33-pin HVQFN package.

== LPC17xx ==

=== Familienübersicht LPC17xx ===
[[Bild:LPC17xx_Selection_Guide_Sep2011.png|thumb|left|680px|Selection Guide zur LPC17xx Familie, ©NXP.com]]
 

Bezugsquellen und Preise:

LPC1754 mit 128K Flash im LQFP80, der bei '''[http://www.darisus.de/ Darius]''' für 7€74 (Juli/2011) erhältlich ist,[den LPC1751 (32k/8k) schon für 5€95] und bei Digikey für 6€35, den LPC1764FBD100 bei '''[http://www.tme.eu/de TME]''' für 7€ Entwicklungskit INCLUSIVE JTAG-Programmer & Debugger bei '''[http://www.watterott.com/de/LPC1769-LPCXpresso Watterott]''' für 23€80 (Juli/2011)

=== Blockdiagram der LPC17xx Familie ===

[[Bild:LPC177x_178x Block Diagram Sep2011.png|thumb|left|680px|Blockdiagramm der LPC17xx Familie, ©NXP.com]]
 

=== Features eines LPC1754 ===
* ARM Cortex-M3 processor, running at frequencies of up to 100 MHz
* A Memory Protection Unit (MPU) supporting eight regions is included.
* ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
* 128 kB on-chip flash program memory with In-System Programming (ISP) and In-Application Programming (IAP) capabilities.
* 32 kB of SRAM on the CPU with local code/data bus for high-performance CPU access.
* Eight channel General Purpose DMA controller
* Serial interfaces:
* USB 2.0 full-speed controller that can be configured for either device, Host, or OTG operation with an on-chip PHY for device and Host functions
* Four UARTs with fractional baud rate generation, internal FIFO, IrDA, and DMA, Einer mit Modem I/Os und RS485 Support
* 1 CAN controller.
* 2 SSP controllers
* 1 SPI controller
* 2 I2C-bus interfaces with data rates of 1Mbit/s,
* I2S (Inter-IC Sound)
* 52 General Purpose I/O (GPIO) pins Any pin of ports 0 and 2 can be used to generate an interrupt.
* 8x 12-bit Analog-to-Digital Converter (ADC) conversion rates up to 200 kHz
* 1x 10-bit Digital-to-Analog Converter (DAC)
* Four general purpose timers/counters, with a total of eight capture inputs and ten compare outputs.
* One motor control PWM with support for three-phase motor control.
* Quadrature encoder interface that can monitor one external quadrature encoder.
* One standard PWM/timer block with external count input.
* Real-Time Clock (RTC) with a separate power domain including 20 bytes of battery-powered backup registers, An RTC interrupt can wake up the CPU from any reduced power mode.
* Watchdog Timer (WDT).
* Cortex-M3 system tick timer
* Repetitive interrupt timer
* Standard JTAG test/debug interface as well as Serial Wire Debug and Serial Wire Trace Port options.
* Four reduced power modes: Sleep, Deep-sleep, Power-down, and Deep power-down.
* Single 3.3 V power supply (2.4 V to 3.6 V).
* Four external interrupt inputs configurable as edge/level sensitive. All pins on PORT0 and PORT2 can be used as edge sensitive interrupt sources.
* Non-maskable Interrupt (NMI) input.
* Wakeup Interrupt Controller (WIC)
* Each peripheral has its own clock divider for further power savings.
* Brownout detect with separate threshold for interrupt and forced reset.
* On-chip Power-On Reset (POR).
* On-chip crystal oscillator with an operating range of 1 MHz to 25 MHz.
* 4 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
* An on-chip PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the main oscillator, the internal RC oscillator, or the RTC oscillator.
* Available as 80-pin LQFP (12 x 12 x 1.4 mm) packages.

== LPC18xx ==

=== Familienübersicht LPC18xx ===
Bezugsquellen und Preise:

=== Blockdiagramm der LPC18xx Familie ===
[[Bild:block.diagram_NXP18xx Sep2011.gif|thumb|left|680px|Blockdiagramm der LPC18xx Familie, ©NXP.com]]
 

=== Features eines LPC18xx ===
DRAFT!
* Processor core
** ARM Cortex-M3 processor, running at frequencies of up to 180 MHz.
** ARM Cortex-M3 built-in Memory Protection Unit (MPU) supporting eight regions.
** ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
** Non-maskable Interrupt (NMI) input.
** JTAG and Serial Wire Debug, serial trace, eight breakpoints, and four watch points.
** ETM and ETB support.
** System tick timer.
* On-chip memory (flashless parts LPC1850/30/20/10)
** Up to 200 kB SRAM total for code and data use.
** Two 32 kB SRAM blocks with separate bus access. Both SRAM blocks can be powered down individually.
** 64 kB ROM containing boot code and on-chip software drivers.
** 32-bit One-Time Programmable (OTP) memory for general-purpose customer use.
* On-chip memory (parts with on-chip flash)
** Up to 1 MB total dual bank flash memory with flash accelerator.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
** Up to 136 kB SRAM for code and data use.
** Two 32 kB SRAM blocks with separate bus access. Both SRAM blocks can be powered down individually.
** 32 kB ROM containing boot code and on-chip software drivers.
** 32-bit One-Time Programmable (OTP) memory for general-purpose customer use.
* Clock generation unit
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** 12 MHz internal RC oscillator trimmed to 1 % accuracy.
** Ultra-low power RTC crystal oscillator.
** Three PLLs allow CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. The second PLL is dedicated to the High-speed USB, the third PLL can be used as audio PLL.
** Clock output.
* Serial interfaces:
** Quad SPI Flash Interface (SPIFI) with four lanes and data rates of up to 40 MB per second total.
** 10/100T Ethernet MAC with RMII and MII interfaces and DMA support for high throughput at low CPU load. Support for IEEE 1588 time stamping/advanced time stamping (IEEE 1588-2008 v2).
** One High-speed USB 2.0 Host/Device/OTG interface with DMA support and on-chip PHY.
** One High-speed USB 2.0 Host/Device interface with DMA support, on-chip full-speed PHY and ULPI interface to external high-speed PHY.
** USB interface electrical test software included in ROM USB stack.
** Four 550 UARTs with DMA support: one UART with full modem interface; one UART with IrDA interface; three USARTs support synchronous mode and a smart card interface conforming to ISO7816 specification.
** Two C_CAN 2.0B controllers with one channel each.
** Two SSP controllers with FIFO and multi-protocol support. Both SSPs with DMA support.
** One Fast-mode Plus I2C-bus interface with monitor mode and with open-drain I/O pins conforming to the full I2C-bus specification. Supports data rates of up to 1 Mbit/s.
** One standard I2C-bus interface with monitor mode and standard I/O pins.
** Two I2S interfaces with DMA support, each with one input and one output.
* Digital peripherals:
** External Memory Controller (EMC) supporting external SRAM, ROM, NOR flash, and SDRAM devices.
** LCD controller with DMA support and a programmable display resolution of up to 1024H x 768V. Supports monochrome and color STN panels and TFT color panels; supports 1/2/4/8 bpp CLUT and 16/24-bit direct pixel mapping.
** SD/MMC card interface.
** Eight-channel General-Purpose DMA (GPDMA) controller can access all memories on the AHB and all DMA-capable AHB slaves.
** Up to 80 General-Purpose Input/Output (GPIO) pins with configurable pull-up/pull-down resistors and open-drain modes.
** GPIO registers are located on the AHB for fast access. GPIO ports have DMA support.
** State Configurable Timer (SCT) subsystem on AHB.
** Four general-purpose timer/counters with capture and match capabilities.
** One motor control PWM for three-phase motor control.
** One Quadrature Encoder Interface (QEI).
** Repetitive Interrupt timer (RI timer).
** Windowed watchdog timer.
** Ultra-low power Real-Time Clock (RTC) on separate power domain with 256 bytes of battery powered backup registers.
** Alarm timer; can be battery powered.
* Digital peripherals available on flash-based parts LPC18xx only:
** <tbd>
* Analog peripherals:
** One 10-bit DAC with DMA support and a data conversion rate of 400 kSamples/s.
** Two 10-bit ADCs with DMA support and a data conversion rate of 400 kSamples/s.
* Security:
** Hardware-based AES security engine programmable through an on-chip API.
** Two 128-bit secure OTP memories for AES key storage and customer use.
** Unique ID for each device.
* Power:
** Single 3.3 V (2.2 V to 3.6 V) power supply with on-chip internal voltage regulator for the core supply and the RTC power domain.
** RTC power domain can be powered separately by a 3 V battery supply.
** Four reduced power modes: Sleep, Deep-sleep, Power-down, and Deep power-down.
** Processor wake-up from Sleep mode via wake-up interrupts from various eripherals.
** Wake-up from Deep-sleep, Power-down, and Deep power-down modes via external interrupts and interrupts generated by battery powered blocks in the RTC power domain.
** Brownout detect with four separate thresholds for interrupt and forced reset.
** Power-On Reset (POR).
* Available as 100-pin, 144-pin, and 208-pin LQFP packages and as 100-pin, 180-pin, and 256-pin LBGA packages.

== Entwicklungsumgebungen ==
=== LPCWare (kostenlos) ===
[[Bild:lpcxpresso-debug_Code-red_3Sep2011.gif|thumb|right|680px|Ansicht der Entwicklungsumgebung, ©code-red-tech.com]]

==== Entwicklungs Tool ====
(Beschreibung aus der Web-Site:)
LPCXpresso's IDE (Ursprünglich von "Code RED" entwickelt, die Firma wurde 2013 von LPC gekauft) ist eine hoch integrierte Entwicklungsumgebung für LPC-Controller, und beinhaltet alle zur Entwicklung erforderlichen Tools um hoch qualitative Software in einer angemessenen Zeit zu schreiben. LPCXpresso basiert auf ein vereinfachtes Eclipse mit vielen LPC-specifischen Erweiterungen.
Des Weiteren ist eine aktuelle Version der Industrie-Standard GNU Tool-Chain mit einer propritären und optimierten C-Lib mit dabei. Die LPCXpresso IDE stellt ein voll optimiertes Executable zur Verfügung. Die einzige Beschränkung der kostenlosen Version ist eine Limitierung auf 256kB Code nach erfolgter Registrierung.
Das LPCXpresso Target Board ist eine Gemeinschaftsentwicklung von Embedded Artists, Code Red und NXP.

==== Features ====
Die LPCXpresso IDE stellt eine C-Umgebung mit Syntax-Colouring, Source-Formatierung, Funktions-Folding, sowie mit Online- und Offline Hilfe und umfangreichen Projekt-Management Funktionen zur Verfügung.
Dies beinhaltet:
* Wizards um Projekte für alle unterstützten Controller zu erstellen
* Automatische Linker Script Generierung inklusive Memory-Map Unterstützung
* Programmierung des Controllers
* On-Line Debugging
* Datenblatt-Zugriff über eingebauten Browser
* Support für die NXP LPC Microcontroller Familien, von Cortex-M0, Cortex-M3 bis Cortex-M4 und ARM7 bis ARM9

==== Peripherie und Register Views im Debugger ====
Der Peripherie-Viewer im integrierten Debugger zeigt alle Register und Bit-Felder in einer einfachen Baumstruktur.
Ein Prozessor-Register Viewer erlaubt den Zugriff auf alle Prozessor-Register und stellt eine "Smart-Formatting" Funktion zur Verfügung um komplexe Register wie Flags oder Status Register übersichtlich darstellen zu können.

==== Unterstützte Familien ====
Cortex-M0, Cortex-M3, Cortex-M4, Einzelne Controller aus der LPC2000 family, ARM966, ARM926-EJ, ARM926-EJ + VFP

==== Sehr preiswerter USB_JTAG_SWD Debugger ====
Von NXP sind sehr preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG Programmer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)]''' und diese '''[http://www.mikrocontroller.net/wikisoftware/index.php?title=LPC1xxx_Entwicklungskit_LPCXpresso Beschreibung]'''
Der neue Programmer/Debugger ist hier für ca 18€ +P&P erhältlich '''[http://www.watterott.com/de/LPC-Link-2 Programmer]'''

==== Standard Library ====
Im Download der "Code Red" Entwicklungsumgebung ist eine relativ umfangreiche Firmwarebibliothek vorhanden.

==== Installationsanleitung zur IDE ====
'''[http://www.mikrocontroller.net/articles/Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red Installationsanleitung]'''

==== Codebase für LPC11xx und LPC13xx ====
Für die Cortex-M0 und -M3 Familien existieren verschiedene Basispakete die als Startausstattung sehr gut geeignet sind. Auf microbuilder.eu findet man eine sehr interessante Version inklusive Dokumentation.

'''[http://www.mikrocontroller.net/articles/Codebase_f%C3%BCr_LPC1xxx HIER]''' findet man alle Links zur original Codebase mit allen Dateien (Stand Januar 2012) aber auch eine deutsche Übersetzung zu den Files.

=== CooCox ===

Auf der '''[http://www.coocox.org/Index.html Homepage]''' von CooCox - einem chinesischen Open-Source Projekt, auf der eine IDE für Atmel, Energy Micro, Holtek, Nuvoton, ST, TI und NXP verfügbar ist - findet man die auf Eclipse basierende "CooCox CoIDE", die sich aus dem "CoBuilder" und dem "CoDebugger" zusammensetzt.
Des Weiteren bietet man dort ein Echtzeit-Multitasking Betriebssystem, sowie SW-Versionen von zwei unterschiedliche Debugging-Adapter und ein Stand-alone Flash-Tool zum freien Download an.

Die folgenden Controller können damit programmiert und debugged werden:
LPC1111x101 LPC1111x201 LPC1112x101 LPC1112x201
LPC1113x201 LPC1113x301 LPC1114x201 LPC1114x301
LPC11C14x301 LPC11C12x301
LPC1224x101 LPC1224x121 LPC1225x301 LPC1225x321 LPC1226x301 LPC1227x301

LPC1311 LPC1313 LPC1342 LPC1343
LPC1751 LPC1752 LPC1754 LPC1756 LPC1758 LPC1759
LPC1763 LPC1764 LPC1765 LPC1766 LPC1767 LPC1768 LPC1769

=== EmBlocks ===
'''[http://www.emblocks.org/web/ Emblocks]''' ist eine kostenlose Entwicklungsumgebung. Sie unterstützt neben NXP uC weitere ARM uC (STM32, EFM32) sowie PIC, AVR und MSP430. Die IDE hat einen eingebauten GDB Debugger welcher System view (Peripherie Register anzeigen) beim Debuggen unterstützt. Ausserdem gibt es einen Project Wizzard für NXP uC 
Unterstützt wird der JLINK mit folgenden NXP uC:
LPC11Axx, LPC11Exx, LPC11Uxx, LPC11xxLV, LPC12xx, LPC13Uxx, LPC13xx, LPC17xx, LPC18xx, LPC18xx, LPC177x_8x, LPC407x_8x

=== Codebase ===
Des Weiteren existiert eine umfangreiche Sammlung von '''[http://www.coocox.org/NXP-Series.php Code-Beispielen]'''.

=== Keil ===
[https://www.keil.com/demo/eval/arm.htm KEIL MDK-ARM] (Windows, Free Version auf 32KB begrenzt, mit vielen Beispielen zu div. Evaluation Boards)
*[http://www.keil.com/arm/chips.asp unterstützte Mikrocontroller]
=== WinARM ===
[http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm WinARM] (wird derzeit nicht gepflegt)

=== GNUARM ===
[http://gnuarm.com/ GNUARM] (Linux, Windows, wird derzeit nicht gepflegt),

=== Yagarto ===
[http://www.yagarto.de/ Yagarto] (Windows, mit Eclipse-Integration)

=== CodeSourcery ===
[http://www.codesourcery.com/gnu_toolchains/arm CodeSourcery CodeBench Lite]

== CMSIS - Standard für alle Plattformen ==
Der Cortex Microcontroller Software Interface Standard (CMSIS) stellt einen "abstraction layer" für alle Cortex-Mx Controller zur Verfügung.

CMSIS stellt einen Schnittstellenstandard von ARM dar, der von vielen Tool-Herstellern unterstützt wird und ist (laut verschiedener Berichte) kompatibel mit den verschiedensten Compilern (incl GCC). Dies wird erreicht durch einheitliche Definitionen für Adressen und Namen die den Zugriff auf die Register des Cores und der Peripherie ermöglichen.
Auch Standard-Funktionen für den Start und die Interrupts stehen zur Verfügung.
Natürlich kann auch weiterhin direkt auf die HW zugegriffen werden, es geht nur um eine Vereinheitlichung von identischen Funktionen.
Da die Peripherie-Teile zumindest innerhalb eines Halbleiterherstellers für die Cortex-Mx Controller sehr ähnlich oder sogar weitgehend identisch sind kann deutlich mehr SW für verschiedene Derivate innerhalb dieser Prozessorfamilien wiederverwendet werden. (siehe Google: "CMSIS_Doulos_Tutorial.pdf").

Ein weiterer, interessanter Punkt ist die CMSIS-DSP Lib mit ihren Vektorfunktionen, Matrix-Berechnung sowie komplexen Algorithmen für Filter,
Regler und Fourietransformation sowie weiterer DSP Algorithmen (insgesamt 61).

Leider hat diese Kompatibilität auch ihre Grenzen, denn Sonderfunktionen bzw. Spezialitäten in der "gleichen" Peripherie zwischen unterschiedlichen Halbleiterherstellern werden nicht abgedeckt.
Wäre auch zu schön, wenn die Prozesorhersteller dem Entwickler dadurch einen fliegenden HW-Wechsel bzw. eine einfache Vergleichbarkeit ermöglichen würden ;-)

Eine komplette CMSIS-Lib (V2.0) "Cortex Microcontroller Software Interface Standard" ist für das "Code Red" Paket verfügbar, inklusive einer "DSP-Library"
http://support.code-red-tech.com/CodeRedWiki/NewInVersion4
bzw. für GNU / Keil / IAR unter
http://ics.nxp.com/support/documents/microcontrollers/?search=CMSIS&type=software&Search.x=8&Search.y=12

== Links ==

* Wiki
** '''[[LPC1xxx_Entwicklungskit_LPCXpresso]]'''
** '''[[Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red]]'''
** '''[[Codebase_f%C3%BCr_LPC1xxx]]'''
** '''[[LPC1xxx für Umsteiger]]'''

* Projekte
** [http://www.mikrocontroller.net/topic/264089 FreeRTOS auf LPC1768]
** [http://www.mikrocontroller.net/topic/321481 Multithreading auf LPC8xx]
** [http://www.mikrocontroller.net/topic/319537 Python Script zum Flashen des LPC8xx]

* Suche im Forum
** [http://www.mikrocontroller.net/search?query=LPC8* LPC8xx]
** [http://www.mikrocontroller.net/search?query=LPC11* LPC11xx]
** [http://www.mikrocontroller.net/search?query=LPC11* LPC11xx]
** [http://www.mikrocontroller.net/search?query=LPC12* LPC12xx]
** [http://www.mikrocontroller.net/search?query=LPC13* LPC13xx]
** [http://www.mikrocontroller.net/search?query=LPC17* LPC17xx]
** [http://www.mikrocontroller.net/search?query=LPC18* LPC18xx]

== Bezugsquellen ==

=== Controller ===
(Die Preiswertesten sind '''fett''' dargestellt)
* '''[http://darisusgmbh.de/shop/advanced_search_result.php?keywords=LPC1&x=0&y=0 Darisus]'''
* '''[http://www.elpro.org/shop/shop.php elpro]'''
* [http://www.hbe-shop.de HBE]
* [http://www.tme.eu/de/katalog#cleanParameters%3D1%26searchClick%3D1%26search%3DLPC1%26bf_szukaj%3D+ TME]
* [http://www.tn-electronics.de/advanced_search_result.php?keywords=LPC1&x=0&y=0 TN]
* [http://de.mouser.com/_/?Keyword=LPC1&Ns=Pricing|0&FS=True Mouser]
* [http://www.soselectronic.eu/?searchstring=LPC1&str=378 SOS]
* [http://de.farnell.com Farnell/Element14]

=== Evaluation Boards ===
* [http://www.watterott.com/index.php?page=search&page_action=query&desc=off&sdesc=on&keywords=LPCXpresso Watterott (24€ inclusive JTAG-Programmiergerät UND JTAG Debugger für kostenlose "Code-Red" Entwicklungsplattform)], dazu hier die [[LPC1xxx_Entwicklungskit_LPCXpresso|Beschreibung]]
* [http://www.lpctools.com/evaluationboardskitsforlpc17xx.aspx LPC-Tools]
* [http://thinkembedded.ch/NXP:::25.html thinkembedded.ch] div. Olimex Boards

== Weblinks, Foren, Communities ==

* http://www.nxp.com/#/page/content=[f=/dynamic/applicationnotes/tid-50809_sid-56890/data.xml] Appnotes
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html Projects]
* [http://mbed.org/handbook/Homepage MBED]
* [http://forums.nxp.com/forums/viewforum.php?f=1 NXP-WIKI]
* [http://knowledgebase.nxp.com/forumdisplay.php?s=389a3610c741bca7b18221d32b9c0ce0&f=4 NXP-Forum]
* [http://ics.nxp.com/lpcxpresso/ LPCXpresso]
* [http://code.google.com/p/32bitmicro/ 32BitMicro]
* [http://www.brc-electronics.nl SimpleCortex]
* [http://www.lpcware.com/ LPCWare NXP MCU community]
* [http://nanohome.be/nxp/index.html LPC175/6x und LPC23xx pin Configurator]
* [https://code.google.com/p/lpc-1768-arm-synthesizer/ MIDI controlled monophonic synthesizer based on the LPCXpresso 1768.]
* [https://code.google.com/p/lpc1343codebase/ An open source software library for NXP's Cortex-M3 based LPC1300 microcontroller family]
* [https://code.google.com/p/lpc1114codebase/ An open source software library for NXP's Cortex-M0 based LPC1100 microcontroller family]
* [https://code.google.com/p/lpc-12xx-bootloader/ A flexible bootloader for use with LPC12xx Microcontrollers from NXP, Firmware code is AES128 encrypted to secure your project / source code when giving out public firmware updates. ]
* [https://code.google.com/p/lpcxpresso-rc/ Read receiver and sensor signals for radio controlled model aircrafts configured for LPCXpresso]
* [https://code.google.com/p/olpcx/ Open toolset for LPCXpresso]
* [https://code.google.com/p/32bitmicro/ Collection of code and tools for 32 bit microcontrollers]
* [https://code.google.com/p/my-nxp-lpc1114/ my-nxp-lpc1114 study course]
* [https://code.google.com/p/nxp-lpc/ nxp-lpc]

== Entwicklungsplattformen ==

* [http://www.lpcware.com/lpcxpresso/home LPDXpresso Download (Kostenlos mit Debugger)]
* [http://www.lpcware.com LPCXpresso Homepage]
* [http://support.code-red-tech.com/CodeRedWiki/WikiHome CR-WIKI]
* [http://www.keil.com/arm/mdk.asp ARM/Keil MDK-ARM]
* IAR EWARM
* Rowley Crossworks
* Green Hills Software
* [http://www.coocox.org/CooCox_CoIDE.htm CooCox] (Kostenlos)

<references/>

[[Kategorie:ARM]]
[[Kategorie:LPC1x]]

Diskussion:LPC-Mikrocontroller

2017-02-27T09:38:47Z

Newgeneration:

LPC-Mikrocontroller

2017-02-27T09:35:18Z

Newgeneration: Vergleichstabelle eingefügt

[[Bild:overview_Sep2011.png|thumb|right|850px|Überblick über die aktuelle Cortex M0/3 Familie, ©NXP.com]]
[[Bild:positioning_NXPSep2011.gif|thumb|right|850px|Vergleich über die aktuelle Cortex M0/3 Familie, ©NXP.com]]

Die LPC-Familie von NXP basiert auf 32-Bit Cortex-Kernen von ARM und arbeitet mit bis zu 204MHz. Die verschiedenen Serien basieren auf den Cortex-M0/M0+/M3/M4-Kernen und sind inzwischen auch für Privatnutzer zu Preisen erhältlich, die mit denen von 8-Bit-Mikrocontrollern vergleichbar sind. Eine Auflistung der verschiedenen Typen findet sich in der Tabelle unten.

Von NXP sind preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG Programmer und Debugger oder den neuen LPC-Link2, ein reiner Programmer + Debugger) erhältlich z.B. bei [http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]. Siehe dazu auch die Dokumentation von NXP zu den [http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)] und diese [[LPC1xxx Entwicklungskit LPCXpresso]].

== Vergleich aller Typen ==
''Stand Feb. 2017''
{| class="wikitable"
! rowspan="2" |
! rowspan="2" style="text-align: center;" | CPU
! rowspan="2" style="text-align: center;" | Max. Frequency
! colspan="2" style="text-align: center;" | Memory
! rowspan="2" style="text-align: center;" | Voltage
! rowspan="2" style="text-align: center;" | Features
|-
| style="text-align: center;" | Flash
| style="text-align: center;" | SRAM
|-
| LPC800
| style="text-align: center;" | Cortex-M0+
| style="text-align: center;" | 30MHz
| style="text-align: center;" | 8-32kB
| style="text-align: center;" | 1-8kB
| style="text-align: center;" | 1.8-3.6V
| style="text-align: center;" |
SCTimer/PWM,
Switch Matrix,
Pattern Match Engine
|-
| LPC54000
| style="text-align: center;" | Cortex-M41
| style="text-align: center;" | 100MHz/180MHz
| style="text-align: center;" | 128-512kB
| style="text-align: center;" | 96-200kB
| style="text-align: center;" | 1,62-3.6V
| style="text-align: center;" |
USB,
CAN,
LCD,
Ethernet,
FlexComm,
Security
|-
| LPC1100
| style="text-align: center;" | Cortex-M0/M0+
| rowspan="2" style="text-align: center;" | 50MHz
| style="text-align: center;" | 4-256kB
| style="text-align: center;" | 1-36kB
| style="text-align: center;" | 1.71-3.6V
| style="text-align: center;" |
USB,
CAN,
EEPROM
|-
| LPC1200
| style="text-align: center;" | Cortex-M0
| style="text-align: center;" | 32-128kB
| style="text-align: center;" | 4-8kB
| style="text-align: center;" | 1.8-3.6V
| style="text-align: center;" |
8 kV protection,
IEC 60730 Class B certified
|-
| LPC1300
| rowspan="4" style="text-align: center;" | Cortex-M3
| rowspan="2" style="text-align: center;" | 72MHz
| style="text-align: center;" | 8-64kB
| style="text-align: center;" | 4-12kB
| style="text-align: center;" | 2.0-3.6V
| style="text-align: center;" |
USB
|-
| LPC1500
| style="text-align: center;" | 64-256kB
| style="text-align: center;" | 12-36kB
| style="text-align: center;" | 2.4-3.6V
| style="text-align: center;" |
USB,
CAN,
QEI
|-
| LPC1700
| style="text-align: center;" | 120MHz
| style="text-align: center;" | 32-512kB
| style="text-align: center;" | 8-96kB
| style="text-align: center;" | 2.4-3.6V
| style="text-align: center;" |
USB,
CAN,
Ethernet,
LCD,
QEI
|-
| LPC1800
| style="text-align: center;" | 180MHz
| style="text-align: center;" | Flashless, 512kB-1MB
| style="text-align: center;" | 104-200kB
| style="text-align: center;" | 2.4-3.6V
| style="text-align: center;" |
Dual HS USB,
CAN,
Ethernet,
LCD,
Security
|-
| LPC4000
| style="text-align: center;" | Cortex-M4
| style="text-align: center;" | 120MHz
| style="text-align: center;" | 64-512kB
| style="text-align: center;" | 24-96kB
| style="text-align: center;" | 2.4-3.6V
| style="text-align: center;" |
USB,
CAN,
Ethernet,
LCD
|-
| LPC4300
| style="text-align: center;" | Cortex-M41
| style="text-align: center;" | 204MHz
| style="text-align: center;" | Flashless,
512kB-1MB
| style="text-align: center;" | 104-282kB
| style="text-align: center;" | 2.4-3.6V
| style="text-align: center;" |
Dual HS USB,
CAN,
Ethernet,
LCD,
SGPIO,
Security
|}
1: gibt es auch als Mehrkern-Prozessoren (mit 0/1/2 Cortex-M0(+)-Cores)

== Allgemeine Infos + User-Manuals==

=== Eckdaten LPC8xx (Cortex-M0+) ===
Die sehr stromsparende '''[http://www.nxp.com/products/microcontrollers/cortex_m0_m0/series/LPC800.html#quickreference LPC8xx]''' ist nur in Packages mit einer relativ niedrigen Pinanzahl (DIP8, SO20, TSSOP16, TSSOP20) verfügbar, hat zwischen 4-16kB Flash, und 1-4kB RAM. Die zulässige Betriebsspannung liegt zwischen 1,8V und 3,6V.

Überblick über die Features der LPC800-Serie:
* 1 I2C
* 1-2 SSP
* 2-3 UART
* 4 Timer, 1 OS-Timer
* 1 watch dog
* 4 PWM-Einheiten
* 10-bit ADC.

'''[http://www.nxp.com/download/grouping/11045/user_manual User Manual der LPC8-Familie (PDF)]'''

=== Eckdaten LPC11xx (Cortex-M0) ===
Die sehr stromsparende '''[http://ics.nxp.com/products/lpc1000/lpc11xx/ LPC11xx-Serie]''' (3,3V) bietet viele Möglichkeiten
* Der LPC1100L ist derzeit laut NXP (Sep2011) der preisgünstigste ARM auf dem Markt. Der 32Bit ARM mit einer Performance von ca. 45DMIPS @50MHZ benötigt bei dieser Taktfrequenz nur etwa 10mA. (Details siehe NXP-Seite)

* Überblick über die Features :
** LPC1100 Serie: • I2C, SSP, UART, GPIO, • Timers and watch dog timer, • 10-bit ADC, • Flash/SRAM memory, • Weitere Funktionen, siehe '''[http://www.mikrocontroller.net/articles/LPC1xxx#Features_eines_LPC11xx 2.3 Features]'''
** LPC1100L Serie zusätzlich zu LPC1100: • Power Profile mit lower power consumption in Active- und Sleep-mode, • Interne pull-ups auf VDD level, • Programmierbarer pseudo open-drain mode für GPIO Pins, • WWDT mit Clock Source Lock.
**LPC11C00 Serie zusätzlich zu LPC1100: • CAN controller, • On-chip CAN Treiber, • On-chip CAN Transceiver (LPC11C2x), • WDT (not windowed) mit Clock Source Lock.

'''[http://www.nxp.com/documents/user_manual/UM10398.pdf User Manual der LPC11-Familie (PDF)]'''

* Besonderes Augenmerk möchte ich auf die neue Serie '''[http://www.nxp.com/ps/#/i=71498 LPC111xFD]''' legen, denn in jetzt gibt es den Cortex-M0 auch im DIL 28 '''[http://www.nxp.com/redirect/pip/LPC1114FN28.html den LPC1114FN28]'''
**Des Weiteren sind damit SO20, sowie TSSOP20 und TSSOP28 Bauformen verfügbar

=== Eckdaten LPC12xx (Cortex-M0) ===
* Die Low Power '''[http://ics.nxp.com/products/lpc1000/lpc12xx/ LPC12xx-Serie]''' (3,3V) ist laut NXP (Sep2011) ein Cortex-M0 mit 32 bis 128kB Flash, einem 45 CoreMark™ Benchmark-Score bei 30MHz, 2 bis 8kB SRAM, und einem internen 1% genauen 12MHz Oscillator.

* Überblick über die Features: fMAX von 30MHz, 1 10-Bit ADC mit 8 Kanälen, 2 Comparatoren, 2 UARTs, 1 SSP/SPI, 1 I2C, DMA Controller, CRC Engine, 1 32-Bit, 5 Timer (16- und 32-Bit, + RTC), 13 PWM Kanäle, bis zu 55 GPIOs.

'''[http://www.nxp.com/documents/user_manual/UM10441.pdf User Manual der LPC12xx-Familie (PDF)]'''

=== Eckdaten LPC13xx (Cortex-M3) ===
Die sehr stromsparende '''[http://ics.nxp.com/products/lpc1000/lpc13xx/ LPC13xx-Serie]''' (3,3V) bietet im LQFP 48 Gehäuse 8..32k Flash, 2..8k SRAM, 5 Timer (mit WD), 11 PWM, 1 UART, 1IIC, 1USB, 1..2 SPI, einen 8-Kanal/10Bit AD-Wandler und eine Taktfrequenz von max. 72MHz.

'''[http://www.nxp.com/documents/user_manual/UM10375.pdf User Manual der LPC13xx-Familie (PDF)]'''

=== Eckdaten LPC17xx (Cortex-M3) ===
Die '''[http://ics.nxp.com/products/lpc1000/lpc17xx/ LPC17xx-Serie]''' hingegen enthält eine weit größere Peripherie in einem LQFP80/100/144/208 Package.
32..512k Flash, 8..96k SRAM, 6 Timer (mit WD), 6 zusätzliche PWM-Einheiten, teilweise Ethernet und STN/TFT-LCD-Controller, meist USB (teilw. mit Host+OTG), 4 UART, 2..3IIC, 1..2 CAN, 1 SPI, 2 SSP/SPI einen 6..8-Kanal/12Bit AD-Wandler, einen 10Bit DAC, Motor-Control-Einheiten, einen Encoder-Eingang und eine Taktfrequenz von max. 100MHz(120MHz) und vieles mehr.

'''[http://www.nxp.com/documents/user_manual/UM10360.pdf User Manual der LPC17xx-Familie (PDF)]'''

=== Eckdaten LPC18xx (Cortex-M3) ===
Die '''[http://ics.nxp.com/products/lpc1000/lpc18xx/ LPC18xx-Serie]''' stellt DIE "High-Performance" Controller aus der Cortex-M3-Serie. Die Taktfrequenz geht bis 150MHz, die Controller enthalten große dual-Bank Flash Speicher bis zu 1MB, ein großes On-Chip SRAM mit bis zu 200KB, zusätzliche Peripherie wie z.B. SPI Flash Interface (SPIFI) und State Configurable Timer (SCT), 2x High Speed USB (1x mit On-Chip HS PHY) und eine MPU.

'''[http://ics.nxp.com/support/documents/microcontrollers/pdf/user.manual.lpc18xx.pdf User Manual der LPC18xx-Familie (PDF)]'''

Überblick über die Features: '''[http://ics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc18xx.pdf LPC18xx Flyer von NXP]'''

=== Entwicklungskits ===
Von NXP sind sehr preiswerte Entwicklungskits (ca. 25€ für. USB-JTAG Programmer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)]'''.

=== Kostenlose Entwicklungsumgebung für ALLE hier genannten Controller ===
Für die ganze Prozessorfamilie ist eine kostenlose Entwicklungsumgebung erhältlich. Informationen unter '''[http://www.lpcware.com/lpcxpresso/home lpcware]''': Die auf Eclipse basierende Entwicklungsumgebung ist nach der Installation bis 8k freigeschaltet und nach einer einfachen und kostenlosen Registrierung für 256kB. Die IDE ist auch für '''[http://www.lpcware.com/lpcxpresso/home Linux und Mac]''' verfügbar.

Hier die '''[http://www.mikrocontroller.net/articles/Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red Installationsanleitung]'''

== LPC8xx ==

=== Familienübersicht LPC8xx ===
Bezugsquellen und Preise (Stand 06/2016)
* LPC810FN8 (DIP8): Digikey 1,09 € (bei einem Stuck).
* LPC812JD20 (SOIC-W 20): Digikey 1,26 € (bei einem Stuck).
* LPC812JDH20 (TSSOP-20): Digikey 1,44 € (bei einem Stuck).

[[Bild:LPC800_block_diagram_Jan2014.gif|thumb|right|850px|Blockdiagramm des Cortex-M0+, ©NXP.com]]

=== Blockdiagramm der LPC8xx Familie ===

=== Features eines LPC8xx ===
* System:
** ARM Cortex-M0+ processor, running at frequencies of up to 30 MHz.
** single cycle multiplier
** single cycle I/O port
** ARM Cortex-M0+ built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug, Micro Trace Buffer supported.
** System tick timer.
* Memory:
** 16 kB (LPC812M101JD20/LPC812M101JDH20/LPC812M101JDH16), 8 kB (LPC811M001JDH16) or 4kB (LPC810M021FN8) on-chip flash programming memory.
** 4kB, 2 kB, or 1 kB SRAM.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* Digital peripherals:
** Up to 18 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors. Number of GPIO pins is reduced for smaller packages down to 6.
** GPIO pins can be used as edge and level sensitive interrupt sources.
** High-current output driver (20 mA) on one pin.
** High-current sink drivers (20 mA) on two open drain pins.
** Four general purpose timers/counters with a total of four capture inputs and up to 13 match outputs.
** Programmable WatchDog Timer (WDT).
** '''Switch matrix for flexible configuration of each I/O pin function.'''
** CRC engine
* Analog peripherals:
** Comparator with internal and external references and 31 step voltage divider.
* Serial interfaces:
** UART with fractional baud rate generation, internal FIFO, and RS-485 support.
** SPI controllers with SSP features and with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Clock generation:
** 12 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** Programmable watchdog oscillator with a frequency range of 9.4 kHz to 2.3 MHz.
** 10 kHz low-power oscillator for the WKT.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, and the Watchdog clock.
* Power control:
** Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
** Power profiles residing in boot ROM allowing to optimize performance and minimize power consumption for any given application through one simple function call.
** Reduced power modes: Sleep mode, Deep-sleep mode, Power-down mode, and Deep power-down mode.
** Wake-up from Deep-sleep and Power-down modes on activity on USART, SPI, and I2C peripherals.
** Brownout detect.
* Unique device serial number for identification.
* Single 3.3 V power supply (1.8 V to 3.6 V).
* Available as DIP8, TSSOP16, SO20, and TSSOP20 package.

== LPC11xx ==

=== Familienübersicht LPC11xx ===
Bezugsquellen und Preise (Stand 01/2014):

elpro.org: von 1.61EUR (LPC1111FN33) bis 5.73EUR (LPC11U37) bei einen Stueck. Die Familie ist sehr gross mit sehr unterschiedlichen Ausfuehrungen.

[[Bild:Block.diagramM0_NXPSep2011.gif|thumb|right|850px|Blockdiagramm des Cortex-M0, ©NXP.com]]

=== Blockdiagramm der LPC11xx Familie ===

=== Features eines LPC11xx ===
* System:
** ARM Cortex-M0 processor, running at frequencies of up to 50 MHz.
** ARM Cortex-M0 built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug.
** System tick timer.
* Memory:
** 32 kB (LPC1114/LPC11C14), 24 kB (LPC1113), 16 kB (LPC1112/LPC11C12), or 8 kB (LPC1111) on-chip flash programming memory.
** 8 kB, 4 kB, or 2 kB SRAM.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* Digital peripherals:
** Up to 42 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors. Number of GPIO pins is reduced for smaller packages and LPC11C22/C24.
** GPIO pins can be used as edge and level sensitive interrupt sources.
** High-current output driver (20 mA) on one pin.
** High-current sink drivers (20 mA) on two open drain pins.
** Four general purpose timers/counters with a total of four capture inputs and up to 13 match outputs.
** Programmable WatchDog Timer (WDT).
* Analog peripherals:
** 10-bit ADC with input multiplexing among 8 pins.
* Serial interfaces:
** UART with fractional baud rate generation, internal FIFO, and RS-485 support.
** SPI controllers with SSP features and with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Clock generation:
** 12 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** Programmable watchdog oscillator with a frequency range of 7.8 kHz to 1.8 MHz.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, and the Watchdog clock.
* Power control:
** Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
** Power profiles residing in boot ROM allowing to optimize performance and minimize power consumption for any given application through one simple function call.
** Processor wake-up from Deep-sleep mode via a dedicated start logic using up to 13 of the functional pins.
** Power-On Reset (POR).
** Brownout detect with four separate thresholds for interrupt and forced reset.
* Unique device serial number for identification.
* Single 3.3 V power supply (1.8 V to 3.6 V).
* Available in the following packages: 16WLCSP, 25WLCSP 20-SOIC, 20-TSSOP, 28-DIP, 28-TSSOP, 48-LQFP, 64-LQFP, 100-LQFP, and others.

== LPC12xx ==

=== Familienübersicht LPC12xx ===
Bezugsquellen und Preise:

[[Bild:block.diagramM0_NXPSep2011.gif|thumb|right|850px|Blockdiagramm des Cortex-M0, ©NXP.com]]

=== Blockdiagramm der LPC12xx Familie ===

=== Features eines LPC12xx ===

* Processor core
** ARM Cortex-M0 processor, running at frequencies of up to 45 MHz (one wait state from flash) or 30 MHz (zero wait states from flash). The LPC122x have a high score of over 45 in CoreMark CPU performance benchmark testing, equivalent to 1.51/MHz.
** ARM Cortex-M0 built-in Nested Vectored Interrupt Controller (NVIC).
** Serial Wire Debug (SWD).
** System tick timer.
* Memory
** Up to 8 kB SRAM.
** Up to 128 kB on-chip flash programming memory.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
** Includes ROM-based 32-bit integer division routines.
* Clock generation unit
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** 12 MHz Internal RC (IRC) oscillator trimmed to 1 % accuracy that can optionally be used as a system clock.
** PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
** Clock output function with divider that can reflect the system oscillator clock, IRC clock, main clock, and Watchdog clock.
** Real-Time Clock (RTC).
* Digital peripherals
** Micro DMA controller with 21 channels.
** CRC engine.
** Two UARTs with fractional baud rate generation and internal FIFO. One UART with RS-485 and modem support and one standard UART with IrDA.
** SSP/SPI controller with FIFO and multi-protocol capabilities.
** I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode. I2C-bus pins have programmable glitch filter.
** Up to 55 General Purpose I/O (GPIO) pins with programmable pull-up resistor, open-drain mode, programmable digital input glitch filter, and programmable input inverter.
** Programmable output drive on all GPIO pins. Four pins support high-current output drivers.
** All GPIO pins can be used as edge and level sensitive interrupt sources.
** Four general purpose counter/timers with four capture inputs and four match outputs (32-bit timers) or two capture inputs and two match outputs (16-bit timers).
** Windowed WatchDog Timer (WWDT).
* Analog peripherals
** One 8-channel, 10-bit ADC.
** Two highly flexible analog comparators. Comparator outputs can be programmed to trigger a timer match signal or can be used to emulate 555 timer behavior.
* Power
** Three reduced power modes: Sleep, Deep-sleep, and Deep power-down.
** Processor wake-up from Deep-sleep mode via start logic using 12 port pins.
** Processor wake-up from Deep-power down and Deep-sleep modes via the RTC.
** Brownout detect with three separate thresholds each for interrupt and forced reset.
** Power-On Reset (POR).
** Integrated PMU (Power Management Unit).
* Unique device serial number for identification.
* 3.3 V power supply.
* Available as 64-pin and 48-pin LQFP package.

== LPC13xx ==

=== Familienübersicht LPC13xx ===
[[Bild:LPC13xx_Selection_Guide_Sep2011.png|thumb|left|600px|Selection Guide zur LPC13xx Familie, ©NXP.com]]
 

Bezugsquellen und Preise:

LPC1313 mit 32k-Flash mit 72MHz im LQFP 48 Gehäuse. Der LPC1313 ist bei '''[http://www.darisus.de/ Darius]''' erhältlich für 3,57 € (Juli 2016), oder elpro.org für 2,29 €. Entwicklungskit INKLUSIVE JTAG-Programmer & Debugger bei '''[http://www.watterott.com/de/LPC1343-LPCXpresso-Board Watterott]''' für 23,80 € (Juli 2011)

=== Blockdiagram der LPC13xx Familie ===

[[Bild:LPC13xx Block Diagram Sep2011.png|thumb|left|680px|Blockdiagramm der LPC13xx Familie, ©NXP.com]]
 

=== Features eines LPC1313 ===
* ARM Cortex-M3 processor, running at frequencies of up to 72 MHz.
* ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
* 32 kB on-chip flash programming memory.
* 8 kB SRAM.
* In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
* UART with fractional baud rate generation, modem, internal FIFO, and RS-485/EIA-485 support.
* SSP controller with FIFO and multi-protocol capabilities.
* Additional SSP controller on LPC1313FBD48/01.
* I2C-bus interface supporting full I2C-bus specification and Fast-mode Plus with a data rate of 1 Mbit/s with multiple address recognition and monitor mode.
* Up to 42 General Purpose I/O (GPIO) pins with configurable pull-up/pull-down resistors.
* Four general purpose counter/timers with a total of four capture inputs and 13 match outputs.
* Programmable Watchdog Timer (WDT)
* System tick timer.
* Serial Wire Debug and Serial Wire Trace port.
* High-current output driver (20 mA) on one pin.
* High-current sink drivers (20 mA) on two I2C-bus pins in Fast-mode Plus.
* Integrated PMU (Power Management Unit) to minimize power consumption during Sleep, Deep-sleep, and Deep power-down modes.
* Three reduced power modes: Sleep, Deep-sleep, and Deep power-down.
* Single power supply (2.0 V to 3.6 V).
* 10-bit ADC with input multiplexing among 8 pins.
* GPIO pins can be used as edge and level sensitive interrupt sources.
* Clock output function with divider that can reflect the system oscillator clock, IRC clock, CPU clock, or the watchdog clock.
* Processor wake-up from Deep-sleep mode via a dedicated start logic using up to 40 of the functional pins.
* Brownout detect with four separate thresholds for interrupt and one thresholds for forced reset.
* Power-On Reset (POR).
* Integrated oscillator with an operating range of 1 MHz to 25 MHz.
* 12 MHz internal RC oscillator trimmed to 1 % accuracy over the entire temperature and voltage range that can optionally be used as a system clock.
* Programmable watchdog oscillator with a frequency range of 7.8 kHz to 1.8 MHz. System PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the system oscillator or the internal RC oscillator.
* Code Read Protection (CRP) with different security levels.
* Unique device serial number for identification.
* Available as 48-pin LQFP package and 33-pin HVQFN package.

== LPC17xx ==

=== Familienübersicht LPC17xx ===
[[Bild:LPC17xx_Selection_Guide_Sep2011.png|thumb|left|680px|Selection Guide zur LPC17xx Familie, ©NXP.com]]
 

Bezugsquellen und Preise:

LPC1754 mit 128K Flash im LQFP80, der bei '''[http://www.darisus.de/ Darius]''' für 7€74 (Juli/2011) erhältlich ist,[den LPC1751 (32k/8k) schon für 5€95] und bei Digikey für 6€35, den LPC1764FBD100 bei '''[http://www.tme.eu/de TME]''' für 7€ Entwicklungskit INCLUSIVE JTAG-Programmer & Debugger bei '''[http://www.watterott.com/de/LPC1769-LPCXpresso Watterott]''' für 23€80 (Juli/2011)

=== Blockdiagram der LPC17xx Familie ===

[[Bild:LPC177x_178x Block Diagram Sep2011.png|thumb|left|680px|Blockdiagramm der LPC17xx Familie, ©NXP.com]]
 

=== Features eines LPC1754 ===
* ARM Cortex-M3 processor, running at frequencies of up to 100 MHz
* A Memory Protection Unit (MPU) supporting eight regions is included.
* ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
* 128 kB on-chip flash program memory with In-System Programming (ISP) and In-Application Programming (IAP) capabilities.
* 32 kB of SRAM on the CPU with local code/data bus for high-performance CPU access.
* Eight channel General Purpose DMA controller
* Serial interfaces:
* USB 2.0 full-speed controller that can be configured for either device, Host, or OTG operation with an on-chip PHY for device and Host functions
* Four UARTs with fractional baud rate generation, internal FIFO, IrDA, and DMA, Einer mit Modem I/Os und RS485 Support
* 1 CAN controller.
* 2 SSP controllers
* 1 SPI controller
* 2 I2C-bus interfaces with data rates of 1Mbit/s,
* I2S (Inter-IC Sound)
* 52 General Purpose I/O (GPIO) pins Any pin of ports 0 and 2 can be used to generate an interrupt.
* 8x 12-bit Analog-to-Digital Converter (ADC) conversion rates up to 200 kHz
* 1x 10-bit Digital-to-Analog Converter (DAC)
* Four general purpose timers/counters, with a total of eight capture inputs and ten compare outputs.
* One motor control PWM with support for three-phase motor control.
* Quadrature encoder interface that can monitor one external quadrature encoder.
* One standard PWM/timer block with external count input.
* Real-Time Clock (RTC) with a separate power domain including 20 bytes of battery-powered backup registers, An RTC interrupt can wake up the CPU from any reduced power mode.
* Watchdog Timer (WDT).
* Cortex-M3 system tick timer
* Repetitive interrupt timer
* Standard JTAG test/debug interface as well as Serial Wire Debug and Serial Wire Trace Port options.
* Four reduced power modes: Sleep, Deep-sleep, Power-down, and Deep power-down.
* Single 3.3 V power supply (2.4 V to 3.6 V).
* Four external interrupt inputs configurable as edge/level sensitive. All pins on PORT0 and PORT2 can be used as edge sensitive interrupt sources.
* Non-maskable Interrupt (NMI) input.
* Wakeup Interrupt Controller (WIC)
* Each peripheral has its own clock divider for further power savings.
* Brownout detect with separate threshold for interrupt and forced reset.
* On-chip Power-On Reset (POR).
* On-chip crystal oscillator with an operating range of 1 MHz to 25 MHz.
* 4 MHz internal RC oscillator trimmed to 1% accuracy that can optionally be used as a system clock.
* An on-chip PLL allows CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. May be run from the main oscillator, the internal RC oscillator, or the RTC oscillator.
* Available as 80-pin LQFP (12 x 12 x 1.4 mm) packages.

== LPC18xx ==

=== Familienübersicht LPC18xx ===
Bezugsquellen und Preise:

=== Blockdiagramm der LPC18xx Familie ===
[[Bild:block.diagram_NXP18xx Sep2011.gif|thumb|left|680px|Blockdiagramm der LPC18xx Familie, ©NXP.com]]
 

=== Features eines LPC18xx ===
DRAFT!
* Processor core
** ARM Cortex-M3 processor, running at frequencies of up to 180 MHz.
** ARM Cortex-M3 built-in Memory Protection Unit (MPU) supporting eight regions.
** ARM Cortex-M3 built-in Nested Vectored Interrupt Controller (NVIC).
** Non-maskable Interrupt (NMI) input.
** JTAG and Serial Wire Debug, serial trace, eight breakpoints, and four watch points.
** ETM and ETB support.
** System tick timer.
* On-chip memory (flashless parts LPC1850/30/20/10)
** Up to 200 kB SRAM total for code and data use.
** Two 32 kB SRAM blocks with separate bus access. Both SRAM blocks can be powered down individually.
** 64 kB ROM containing boot code and on-chip software drivers.
** 32-bit One-Time Programmable (OTP) memory for general-purpose customer use.
* On-chip memory (parts with on-chip flash)
** Up to 1 MB total dual bank flash memory with flash accelerator.
** In-System Programming (ISP) and In-Application Programming (IAP) via on-chip bootloader software.
** Up to 136 kB SRAM for code and data use.
** Two 32 kB SRAM blocks with separate bus access. Both SRAM blocks can be powered down individually.
** 32 kB ROM containing boot code and on-chip software drivers.
** 32-bit One-Time Programmable (OTP) memory for general-purpose customer use.
* Clock generation unit
** Crystal oscillator with an operating range of 1 MHz to 25 MHz.
** 12 MHz internal RC oscillator trimmed to 1 % accuracy.
** Ultra-low power RTC crystal oscillator.
** Three PLLs allow CPU operation up to the maximum CPU rate without the need for a high-frequency crystal. The second PLL is dedicated to the High-speed USB, the third PLL can be used as audio PLL.
** Clock output.
* Serial interfaces:
** Quad SPI Flash Interface (SPIFI) with four lanes and data rates of up to 40 MB per second total.
** 10/100T Ethernet MAC with RMII and MII interfaces and DMA support for high throughput at low CPU load. Support for IEEE 1588 time stamping/advanced time stamping (IEEE 1588-2008 v2).
** One High-speed USB 2.0 Host/Device/OTG interface with DMA support and on-chip PHY.
** One High-speed USB 2.0 Host/Device interface with DMA support, on-chip full-speed PHY and ULPI interface to external high-speed PHY.
** USB interface electrical test software included in ROM USB stack.
** Four 550 UARTs with DMA support: one UART with full modem interface; one UART with IrDA interface; three USARTs support synchronous mode and a smart card interface conforming to ISO7816 specification.
** Two C_CAN 2.0B controllers with one channel each.
** Two SSP controllers with FIFO and multi-protocol support. Both SSPs with DMA support.
** One Fast-mode Plus I2C-bus interface with monitor mode and with open-drain I/O pins conforming to the full I2C-bus specification. Supports data rates of up to 1 Mbit/s.
** One standard I2C-bus interface with monitor mode and standard I/O pins.
** Two I2S interfaces with DMA support, each with one input and one output.
* Digital peripherals:
** External Memory Controller (EMC) supporting external SRAM, ROM, NOR flash, and SDRAM devices.
** LCD controller with DMA support and a programmable display resolution of up to 1024H x 768V. Supports monochrome and color STN panels and TFT color panels; supports 1/2/4/8 bpp CLUT and 16/24-bit direct pixel mapping.
** SD/MMC card interface.
** Eight-channel General-Purpose DMA (GPDMA) controller can access all memories on the AHB and all DMA-capable AHB slaves.
** Up to 80 General-Purpose Input/Output (GPIO) pins with configurable pull-up/pull-down resistors and open-drain modes.
** GPIO registers are located on the AHB for fast access. GPIO ports have DMA support.
** State Configurable Timer (SCT) subsystem on AHB.
** Four general-purpose timer/counters with capture and match capabilities.
** One motor control PWM for three-phase motor control.
** One Quadrature Encoder Interface (QEI).
** Repetitive Interrupt timer (RI timer).
** Windowed watchdog timer.
** Ultra-low power Real-Time Clock (RTC) on separate power domain with 256 bytes of battery powered backup registers.
** Alarm timer; can be battery powered.
* Digital peripherals available on flash-based parts LPC18xx only:
** <tbd>
* Analog peripherals:
** One 10-bit DAC with DMA support and a data conversion rate of 400 kSamples/s.
** Two 10-bit ADCs with DMA support and a data conversion rate of 400 kSamples/s.
* Security:
** Hardware-based AES security engine programmable through an on-chip API.
** Two 128-bit secure OTP memories for AES key storage and customer use.
** Unique ID for each device.
* Power:
** Single 3.3 V (2.2 V to 3.6 V) power supply with on-chip internal voltage regulator for the core supply and the RTC power domain.
** RTC power domain can be powered separately by a 3 V battery supply.
** Four reduced power modes: Sleep, Deep-sleep, Power-down, and Deep power-down.
** Processor wake-up from Sleep mode via wake-up interrupts from various eripherals.
** Wake-up from Deep-sleep, Power-down, and Deep power-down modes via external interrupts and interrupts generated by battery powered blocks in the RTC power domain.
** Brownout detect with four separate thresholds for interrupt and forced reset.
** Power-On Reset (POR).
* Available as 100-pin, 144-pin, and 208-pin LQFP packages and as 100-pin, 180-pin, and 256-pin LBGA packages.

== Entwicklungsumgebungen ==
=== LPCWare (kostenlos) ===
[[Bild:lpcxpresso-debug_Code-red_3Sep2011.gif|thumb|right|680px|Ansicht der Entwicklungsumgebung, ©code-red-tech.com]]

==== Entwicklungs Tool ====
(Beschreibung aus der Web-Site:)
LPCXpresso's IDE (Ursprünglich von "Code RED" entwickelt, die Firma wurde 2013 von LPC gekauft) ist eine hoch integrierte Entwicklungsumgebung für LPC-Controller, und beinhaltet alle zur Entwicklung erforderlichen Tools um hoch qualitative Software in einer angemessenen Zeit zu schreiben. LPCXpresso basiert auf ein vereinfachtes Eclipse mit vielen LPC-specifischen Erweiterungen.
Des Weiteren ist eine aktuelle Version der Industrie-Standard GNU Tool-Chain mit einer propritären und optimierten C-Lib mit dabei. Die LPCXpresso IDE stellt ein voll optimiertes Executable zur Verfügung. Die einzige Beschränkung der kostenlosen Version ist eine Limitierung auf 256kB Code nach erfolgter Registrierung.
Das LPCXpresso Target Board ist eine Gemeinschaftsentwicklung von Embedded Artists, Code Red und NXP.

==== Features ====
Die LPCXpresso IDE stellt eine C-Umgebung mit Syntax-Colouring, Source-Formatierung, Funktions-Folding, sowie mit Online- und Offline Hilfe und umfangreichen Projekt-Management Funktionen zur Verfügung.
Dies beinhaltet:
* Wizards um Projekte für alle unterstützten Controller zu erstellen
* Automatische Linker Script Generierung inklusive Memory-Map Unterstützung
* Programmierung des Controllers
* On-Line Debugging
* Datenblatt-Zugriff über eingebauten Browser
* Support für die NXP LPC Microcontroller Familien, von Cortex-M0, Cortex-M3 bis Cortex-M4 und ARM7 bis ARM9

==== Peripherie und Register Views im Debugger ====
Der Peripherie-Viewer im integrierten Debugger zeigt alle Register und Bit-Felder in einer einfachen Baumstruktur.
Ein Prozessor-Register Viewer erlaubt den Zugriff auf alle Prozessor-Register und stellt eine "Smart-Formatting" Funktion zur Verfügung um komplexe Register wie Flags oder Status Register übersichtlich darstellen zu können.

==== Unterstützte Familien ====
Cortex-M0, Cortex-M3, Cortex-M4, Einzelne Controller aus der LPC2000 family, ARM966, ARM926-EJ, ARM926-EJ + VFP

==== Sehr preiswerter USB_JTAG_SWD Debugger ====
Von NXP sind sehr preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG Programmer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits (PDF)]''' und diese '''[http://www.mikrocontroller.net/wikisoftware/index.php?title=LPC1xxx_Entwicklungskit_LPCXpresso Beschreibung]'''
Der neue Programmer/Debugger ist hier für ca 18€ +P&P erhältlich '''[http://www.watterott.com/de/LPC-Link-2 Programmer]'''

==== Standard Library ====
Im Download der "Code Red" Entwicklungsumgebung ist eine relativ umfangreiche Firmwarebibliothek vorhanden.

==== Installationsanleitung zur IDE ====
'''[http://www.mikrocontroller.net/articles/Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red Installationsanleitung]'''

==== Codebase für LPC11xx und LPC13xx ====
Für die Cortex-M0 und -M3 Familien existieren verschiedene Basispakete die als Startausstattung sehr gut geeignet sind. Auf microbuilder.eu findet man eine sehr interessante Version inklusive Dokumentation.

'''[http://www.mikrocontroller.net/articles/Codebase_f%C3%BCr_LPC1xxx HIER]''' findet man alle Links zur original Codebase mit allen Dateien (Stand Januar 2012) aber auch eine deutsche Übersetzung zu den Files.

=== CooCox ===

Auf der '''[http://www.coocox.org/Index.html Homepage]''' von CooCox - einem chinesischen Open-Source Projekt, auf der eine IDE für Atmel, Energy Micro, Holtek, Nuvoton, ST, TI und NXP verfügbar ist - findet man die auf Eclipse basierende "CooCox CoIDE", die sich aus dem "CoBuilder" und dem "CoDebugger" zusammensetzt.
Des Weiteren bietet man dort ein Echtzeit-Multitasking Betriebssystem, sowie SW-Versionen von zwei unterschiedliche Debugging-Adapter und ein Stand-alone Flash-Tool zum freien Download an.

Die folgenden Controller können damit programmiert und debugged werden:
LPC1111x101 LPC1111x201 LPC1112x101 LPC1112x201
LPC1113x201 LPC1113x301 LPC1114x201 LPC1114x301
LPC11C14x301 LPC11C12x301
LPC1224x101 LPC1224x121 LPC1225x301 LPC1225x321 LPC1226x301 LPC1227x301

LPC1311 LPC1313 LPC1342 LPC1343
LPC1751 LPC1752 LPC1754 LPC1756 LPC1758 LPC1759
LPC1763 LPC1764 LPC1765 LPC1766 LPC1767 LPC1768 LPC1769

=== EmBlocks ===
'''[http://www.emblocks.org/web/ Emblocks]''' ist eine kostenlose Entwicklungsumgebung. Sie unterstützt neben NXP uC weitere ARM uC (STM32, EFM32) sowie PIC, AVR und MSP430. Die IDE hat einen eingebauten GDB Debugger welcher System view (Peripherie Register anzeigen) beim Debuggen unterstützt. Ausserdem gibt es einen Project Wizzard für NXP uC 
Unterstützt wird der JLINK mit folgenden NXP uC:
LPC11Axx, LPC11Exx, LPC11Uxx, LPC11xxLV, LPC12xx, LPC13Uxx, LPC13xx, LPC17xx, LPC18xx, LPC18xx, LPC177x_8x, LPC407x_8x

=== Codebase ===
Des Weiteren existiert eine umfangreiche Sammlung von '''[http://www.coocox.org/NXP-Series.php Code-Beispielen]'''.

=== Keil ===
[https://www.keil.com/demo/eval/arm.htm KEIL MDK-ARM] (Windows, Free Version auf 32KB begrenzt, mit vielen Beispielen zu div. Evaluation Boards)
*[http://www.keil.com/arm/chips.asp unterstützte Mikrocontroller]
=== WinARM ===
[http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm WinARM] (wird derzeit nicht gepflegt)

=== GNUARM ===
[http://gnuarm.com/ GNUARM] (Linux, Windows, wird derzeit nicht gepflegt),

=== Yagarto ===
[http://www.yagarto.de/ Yagarto] (Windows, mit Eclipse-Integration)

=== CodeSourcery ===
[http://www.codesourcery.com/gnu_toolchains/arm CodeSourcery CodeBench Lite]

== CMSIS - Standard für alle Plattformen ==
Der Cortex Microcontroller Software Interface Standard (CMSIS) stellt einen "abstraction layer" für alle Cortex-Mx Controller zur Verfügung.

CMSIS stellt einen Schnittstellenstandard von ARM dar, der von vielen Tool-Herstellern unterstützt wird und ist (laut verschiedener Berichte) kompatibel mit den verschiedensten Compilern (incl GCC). Dies wird erreicht durch einheitliche Definitionen für Adressen und Namen die den Zugriff auf die Register des Cores und der Peripherie ermöglichen.
Auch Standard-Funktionen für den Start und die Interrupts stehen zur Verfügung.
Natürlich kann auch weiterhin direkt auf die HW zugegriffen werden, es geht nur um eine Vereinheitlichung von identischen Funktionen.
Da die Peripherie-Teile zumindest innerhalb eines Halbleiterherstellers für die Cortex-Mx Controller sehr ähnlich oder sogar weitgehend identisch sind kann deutlich mehr SW für verschiedene Derivate innerhalb dieser Prozessorfamilien wiederverwendet werden. (siehe Google: "CMSIS_Doulos_Tutorial.pdf").

Ein weiterer, interessanter Punkt ist die CMSIS-DSP Lib mit ihren Vektorfunktionen, Matrix-Berechnung sowie komplexen Algorithmen für Filter,
Regler und Fourietransformation sowie weiterer DSP Algorithmen (insgesamt 61).

Leider hat diese Kompatibilität auch ihre Grenzen, denn Sonderfunktionen bzw. Spezialitäten in der "gleichen" Peripherie zwischen unterschiedlichen Halbleiterherstellern werden nicht abgedeckt.
Wäre auch zu schön, wenn die Prozesorhersteller dem Entwickler dadurch einen fliegenden HW-Wechsel bzw. eine einfache Vergleichbarkeit ermöglichen würden ;-)

Eine komplette CMSIS-Lib (V2.0) "Cortex Microcontroller Software Interface Standard" ist für das "Code Red" Paket verfügbar, inklusive einer "DSP-Library"
http://support.code-red-tech.com/CodeRedWiki/NewInVersion4
bzw. für GNU / Keil / IAR unter
http://ics.nxp.com/support/documents/microcontrollers/?search=CMSIS&type=software&Search.x=8&Search.y=12

== Links ==

* Wiki
** '''[[LPC1xxx_Entwicklungskit_LPCXpresso]]'''
** '''[[Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red]]'''
** '''[[Codebase_f%C3%BCr_LPC1xxx]]'''
** '''[[LPC1xxx für Umsteiger]]'''

* Projekte
** [http://www.mikrocontroller.net/topic/264089 FreeRTOS auf LPC1768]
** [http://www.mikrocontroller.net/topic/321481 Multithreading auf LPC8xx]
** [http://www.mikrocontroller.net/topic/319537 Python Script zum Flashen des LPC8xx]

* Suche im Forum
** [http://www.mikrocontroller.net/search?query=LPC8* LPC8xx]
** [http://www.mikrocontroller.net/search?query=LPC11* LPC11xx]
** [http://www.mikrocontroller.net/search?query=LPC11* LPC11xx]
** [http://www.mikrocontroller.net/search?query=LPC12* LPC12xx]
** [http://www.mikrocontroller.net/search?query=LPC13* LPC13xx]
** [http://www.mikrocontroller.net/search?query=LPC17* LPC17xx]
** [http://www.mikrocontroller.net/search?query=LPC18* LPC18xx]

== Bezugsquellen ==

=== Controller ===
(Die Preiswertesten sind '''fett''' dargestellt)
* '''[http://darisusgmbh.de/shop/advanced_search_result.php?keywords=LPC1&x=0&y=0 Darisus]'''
* '''[http://www.elpro.org/shop/shop.php elpro]'''
* [http://www.hbe-shop.de HBE]
* [http://www.tme.eu/de/katalog#cleanParameters%3D1%26searchClick%3D1%26search%3DLPC1%26bf_szukaj%3D+ TME]
* [http://www.tn-electronics.de/advanced_search_result.php?keywords=LPC1&x=0&y=0 TN]
* [http://de.mouser.com/_/?Keyword=LPC1&Ns=Pricing|0&FS=True Mouser]
* [http://www.soselectronic.eu/?searchstring=LPC1&str=378 SOS]
* [http://de.farnell.com Farnell/Element14]

=== Evaluation Boards ===
* [http://www.watterott.com/index.php?page=search&page_action=query&desc=off&sdesc=on&keywords=LPCXpresso Watterott (24€ inclusive JTAG-Programmiergerät UND JTAG Debugger für kostenlose "Code-Red" Entwicklungsplattform)], dazu hier die [[LPC1xxx_Entwicklungskit_LPCXpresso|Beschreibung]]
* [http://www.lpctools.com/evaluationboardskitsforlpc17xx.aspx LPC-Tools]
* [http://thinkembedded.ch/NXP:::25.html thinkembedded.ch] div. Olimex Boards

== Weblinks, Foren, Communities ==

* http://www.nxp.com/#/page/content=[f=/dynamic/applicationnotes/tid-50809_sid-56890/data.xml] Appnotes
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html Projects]
* [http://mbed.org/handbook/Homepage MBED]
* [http://forums.nxp.com/forums/viewforum.php?f=1 NXP-WIKI]
* [http://knowledgebase.nxp.com/forumdisplay.php?s=389a3610c741bca7b18221d32b9c0ce0&f=4 NXP-Forum]
* [http://ics.nxp.com/lpcxpresso/ LPCXpresso]
* [http://code.google.com/p/32bitmicro/ 32BitMicro]
* [http://www.brc-electronics.nl SimpleCortex]
* [http://www.lpcware.com/ LPCWare NXP MCU community]
* [http://nanohome.be/nxp/index.html LPC175/6x und LPC23xx pin Configurator]
* [https://code.google.com/p/lpc-1768-arm-synthesizer/ MIDI controlled monophonic synthesizer based on the LPCXpresso 1768.]
* [https://code.google.com/p/lpc1343codebase/ An open source software library for NXP's Cortex-M3 based LPC1300 microcontroller family]
* [https://code.google.com/p/lpc1114codebase/ An open source software library for NXP's Cortex-M0 based LPC1100 microcontroller family]
* [https://code.google.com/p/lpc-12xx-bootloader/ A flexible bootloader for use with LPC12xx Microcontrollers from NXP, Firmware code is AES128 encrypted to secure your project / source code when giving out public firmware updates. ]
* [https://code.google.com/p/lpcxpresso-rc/ Read receiver and sensor signals for radio controlled model aircrafts configured for LPCXpresso]
* [https://code.google.com/p/olpcx/ Open toolset for LPCXpresso]
* [https://code.google.com/p/32bitmicro/ Collection of code and tools for 32 bit microcontrollers]
* [https://code.google.com/p/my-nxp-lpc1114/ my-nxp-lpc1114 study course]
* [https://code.google.com/p/nxp-lpc/ nxp-lpc]

== Entwicklungsplattformen ==

* [http://www.lpcware.com/lpcxpresso/home LPDXpresso Download (Kostenlos mit Debugger)]
* [http://www.lpcware.com LPCXpresso Homepage]
* [http://support.code-red-tech.com/CodeRedWiki/WikiHome CR-WIKI]
* [http://www.keil.com/arm/mdk.asp ARM/Keil MDK-ARM]
* IAR EWARM
* Rowley Crossworks
* Green Hills Software
* [http://www.coocox.org/CooCox_CoIDE.htm CooCox] (Kostenlos)

<references/>

[[Kategorie:ARM]]
[[Kategorie:LPC1x]]

ARM GCC

2017-02-12T15:59:07Z

Newgeneration:

arm-gcc ist ein freier [[C]]-Cross-[[Compiler]] für [[ARM]]-[[Mikrocontroller]].

In diesem Artikel geht es primär um den arm-none-eabi-gcc, der ein für embedded Systems optimiertes ABI (Application Binary Interface) hat. Für ARM-System, die ein eigenständiges OS (wie Linux) haben, gibt es den arm-elf-gcc.

Es gibt diverse fertige Binärdistributionen die für verschiedene Controller mit ARM-Kern verwendet werden können.

== Bestandteile ==
Die Toolchain besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen. Weit verbreitet ist die Verwendung von make zur Steuerung.

Die Bestandteile im einzelnen:
* Binutils: Assembler, Linker und weitere Hilfsprogramme.
* GCC: Der eigentliche C(++)-Compiler.
* eine C-Standardbibliothek

Die vorherrschende C-Bibliothek ist die [https://sourceware.org/newlib/ newlib] (oder auch [https://github.com/32bitmicro/newlib-nano-1.0 newlib-nano]), für andere Optionen siehe [http://wiki.osdev.org/C_Library#Implementations hier].

Bei der Auswahl der Toolchain sollte beachtet werden, dass es größere Unterschiede bei den bereitgestellten C-Bibliotheken gibt. Die Sourcery Codebench Lite-Edition stellt z.B. keine Bibliotheken mit FPU-Unterstützung bereit, so dass trotz vorhandener FPU beim Cortex-M4 nur suboptimaler Code erzegt werden kann. Siehe [http://wiki.debian.org/ArmHardFloatPort/VfpComparison] für ein kleines Beispiel und eine Erklärung.

== Fertige GCC Binärdistributionen ==
* [https://developer.arm.com/open-source/gnu-toolchain/gnu-rm GCC-ARM-Embedded] ([https://launchpad.net/gcc-arm-embedded Ältere Releases]) für Cortex-R4/R5/R7/R8/M0(+)/M3/M4(F)/M7/M23/M33. Windows, Linux, Mac, bereitgestellt von ARM selbst, vollständiger Support für FPUs, C++11, kein Code-Size-Limit
* [http://www.mentor.com/embedded-software/codesourcery Mentor Graphics Sourcery Tools (vormals CodeSourcery CodeBench Lite)] Windows, Linux
* [http://sourceforge.net/projects/devkitpro/ devkitPro]
* [http://www.lpcware.com/lpcxpresso/home LPCXpresso] (vormals CodeRed IDE) ist eine IDE von NXP für die LPC-Mikrocontroller die den GCC enthält
* [http://www.yagarto.de/ Yagarto] (Windows, mit Eclipse-Integration) - veraltet
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm WinARM] - veraltet
* GNUARM - veraltet
* summon-arm Toolchain: hat einen Compiler-Bug [http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg353473.html] und sollte daher nicht verwendet werden, wenn man floatingpoint-Typen einsetzen möchte (egal ob mit oder ohne FPU).

Beim Einsatz des gcc in Verbindung mit in C geschriebenem startup-Code bei den Optimierungsleveln "-O2" und "-O3" muss zusätzlich "-fno-gcse" gesetzt werden, da ansonsten die von der CPU benötigte NVIC-Tabelle(n) und zugehörige Funktionen unter Umständen nicht so aussehen wie sie sollten.

Siehe auch [http://embdev.net/topic/129986#1175214 ARM-GCC development resources] im Forum.

== Nutzung mit eigener Umgebung/Kommandozeile ==
Hier einige Hinweise wie man den GCC direkt verwenden kann (zB. mit selbstgebautem makefile), falls man das nicht von einer Entwicklungsumgebung machen lässt.
=== Compiler & Linker Flags ===
Die Flags, die festlegen, welcher Core verwendet wird, sind in der folgenden Tabelle beschrieben:
{| class="wikitable"
! Option
! style="text-align: center;" | Cortex-M0
! style="text-align: center;" | Cortex-M0+
! style="text-align: center;" | Cortex-M3
! style="text-align: center;" | Cortex-M4
! style="text-align: center;" | Cortex-M7
! style="text-align: center;" | Cortex-M33
! style="text-align: center;" | Cortex-M23
|-
| CPU
| -mcpu=cortex-m0[1]
| -mcpu=cortex-m0plus[1]
| -mcpu=cortex-m3
| -mcpu=cortex-m4
| -mcpu=cortex-m7
| -mcpu=cortex-m33
| -mcpu=cortex-m23
|-
| Float ABI
| colspan="3" style="text-align: center;" | -mfloat-abi=soft
| colspan="3" style="text-align: center;" | -mfloat-abi=soft

-mfloat-abi=softfp

-mfloat-abi=hard
| style="text-align: center;" | -mfloat-abi=soft
|-
| FPU
| colspan="3" |
| -mfpu=fpv4-sp-d16
| -mfpu=fpv5-d16
| ?
|
|-
| Instruction Set
| colspan="7" style="text-align: center;" | -mthumb
|}
[1]Anmerkung: Es gibt für diese Cores 2 Optionen (für den Hersteller): diese Betreffen die Multiplikationsbefehle.
* Die übliche Implementierung enthält einen 1-Takt-Multiplizierer
* Für reduzierte Chipfläche kann auche ein 32-Takt-Multiplizierer ausgewählt werden
Um nun bei Multiplikationen mit Konstanten nicht die langsame 32-Takt-Multiplikation zu nutzen kann der Compiler angewiesen werden, dort Shifts oder Ähnliches zu generieren.
Um dem Compiler das mitzuteilen wird der Parameter, der die CPU angibt, abgeändert: -mcpu=cortex-m0[plus].small-multiply

Zusätzlich zu diesen Flags gibt es noch die Maschinenunabhängigen Parameter, wovon hier nur einige wichtigen erläutert werden:

{| class="wikitable"
! style="width: 20% | Option !! Erklärung
|-
| -W[all, extra]
| Lässt den Compiler Warnungen ausgeben.
-Wall gibt nur Standard-Warnungen aus, nicht alle!
-Wextra erzeugt noch einmal mehr Warnungen.
|-
| -O[0,1,2,3,s,g]
| Wählt die Art der Optimierung.
-O0: keine Optimierung
-O[1,2,3]: Optimierung auf Ausführungsgeschwindigkeit. Je höher die Stufe, desto aggressiver ist die Optimierung. Das führt unter Umständen zu beträchtlich größerem Code
-Os: Optimierung auf Codegröße
-Og: Optimierung, aber so, dass das Debugging nicht erschwert wird
|-
| -fdata-sections
-ffunction-sections
| Teilt jeder Funktion/jeder Variable eine eigene Section zu.Damit kann der Linker mit der Option --gc-sections ungenutzte Funktionen entfernen. Siehe [[GCC:_unbenutzte_Funktionen_entfernen]]
|-
| -Wl,--gc-sections
| Der Linker verwirft unreferenzierte Sections und packt diese damit nicht ins Binary. Siehe [[GCC:_unbenutzte_Funktionen_entfernen]]
|-
| -g
| Erzeugt Debugging-Informationen.
Siehe auch [https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html GCC Debugging Options]
|-
| -fno-rtti
-fno-exceptions
| C++-Optionen
Teilt dem Compiler mit, dass
- keine Runtime Type Information zu generieren sind
- keine Exceptions benutzt werden und damit kein Overhead generiert werden muss.
|-
| -flto
| Link-Time-Optimizations:
Der Linker optimiert den kompletten Code. Da er nicht nur ein Source-File, sondern alle kennt, kann er optimieren, wo dem Compiler Informationen fehlen.
Achtung: bei älteren Compiler-Versionen muss nach diesem Flag noch einmal die Optimierungsstufe angegeben werden.
|}

Die [http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary GCC Dokumentation] listet alle Parameter auf, auch [http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options Parameter speziell für ARM].

* Siehe auch das [https://launchpadlibrarian.net/135588846/readme.txt Readme vom GCC-ARM-Embedded]
* Um das -flto -Flag verwenden zu können, muss der GCC [http://gcc.gnu.org/onlinedocs/gccint/LTO.html LTO] unterstützen. Beim GCC-ARM-Embedded ist dies ab Version 4.7-2013-q2-update der Fall.
* Die LTO erkennt die ISR's und den Interrupt Vector möglicherweise als "unbenutzt" und optimiert sie daher weg. Dies kann durch Markierung der Funktionen & Variablen mit "__attribute__ ((used))" verhindert werden.
* Alle Compileroptionen müssen auch beim Linken mit angegeben werden (ist in obiger Tabelle berücksichtigt), da auch dann u.U. Code generiert werden kann.

=== 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. Das Script ist praktisch Controller-spezifisch, es gibt Beispiel-Scripte der Controller-Hersteller.
* 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. Startupcode im allgemeinen ist meistens in Assembler geschrieben, aber die ARM-Architektur macht aber auch einfacheren C/C++-Code möglich. Auch für den Startupcode gibt es Beispiele der Controller-Hersteller.

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.

=== FPU der Cortex-M4F nutzen ===
Um die FPU zu nutzen, muss der Compiler per [[#Compiler_.26_Linker_Flags|Flag]] dazu gebracht werden, FPU-Instruktionen zu generieren.

Außerdem muss vor Benutzung der FPU-Befehle die FPU aktiviert werden, dies geschieht typischerweise im Startupcode, bevor die main() -Funktion aufgerufen wird. Hier die entsprechenden Befehle, falls sie im verwendeten Startupcode nicht onehin schon enthalten sind:
<syntaxhighlight lang="asm">/*FPU settings*/
ldr r0, =0xE000ED88 /* Enable CP10,CP11 */
ldr r1,[r0]
orr r1,r1,#(0xF << 20)
str r1,[r0]
</syntaxhighlight>
In C/C++ unter Verwendung der CMSIS geht es so:
<syntaxhighlight lang="c">
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
</syntaxhighlight>

Weiterhin sollte die GCC-Distribution auch Laufzeitbibliotheken mit FPU-Unterstützung mitbringen (CodeBench lite und Yagarto werden ohne ausgeliefert, GCC-ARM-Embedded mit).

Am Beispiel der STM32F4 mehr dazu in diesem Thread: [http://www.mikrocontroller.net/topic/261021 Floating Pointing Unit STM32F4]

== Links ==
* [http://www.mikrocontroller.net/topic/298976#3197418 Hier] finden sich noch ein paar Tipps, für den 1. kann aber mittlerweile der GCC-ARM-Embedded direkt verwendet werden, da er jetzt LTO unterstützt (s.o.).
* [https://www.mikrocontroller.net/topic/178840 Thread]: Unterschied arm-none-eabi-gcc und arm-elf-gcc

[[Category:ARM]]
[[Category:Compiler]]

ARM GCC

2017-02-12T15:54:00Z

Newgeneration: Artikel überarbeitet, neue Tabellen eigefügt

arm-gcc ist ein freier [[C]]-Cross-[[Compiler]] für [[ARM]]-[[Mikrocontroller]].

In diesem Artikel geht es primär um den arm-none-eabi-gcc, der ein für embedded Systems optimiertes ABI (Application Binary Interface) hat. Für ARM-System, die ein eigenstädniges OS (wie Linux) haben, gibt es den arm-elf-gcc.

Es gibt diverse fertige Binärdistributionen die für verschiedene Controller mit ARM-Kern verwendet werden können.

== Bestandteile ==
Die Toolchain besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen. Weit verbreitet ist die Verwendung von make zur Steuerung.

Die Bestandteile im einzelnen:
* Binutils: Assembler, Linker und weitere Hilfsprogramme.
* GCC: Der eigentliche C(++)-Compiler.
* eine C-Standardbibliothek

Die vorherrschende C-Bibliothek ist die [https://sourceware.org/newlib/ newlib] (oder auch [https://github.com/32bitmicro/newlib-nano-1.0 newlib-nano]), für andere Optionen siehe [http://wiki.osdev.org/C_Library#Implementations hier].

Bei der Auswahl der Toolchain sollte beachtet werden, dass es größere Unterschiede bei den bereitgestellten C-Bibliotheken gibt. Die Sourcery Codebench Lite-Edition stellt z.B. keine Bibliotheken mit FPU-Unterstützung bereit, so dass trotz vorhandener FPU beim Cortex-M4 nur suboptimaler Code erzegt werden kann. Siehe [http://wiki.debian.org/ArmHardFloatPort/VfpComparison] für ein kleines Beispiel und eine Erklärung.

== Fertige GCC Binärdistributionen ==
* [https://developer.arm.com/open-source/gnu-toolchain/gnu-rm GCC-ARM-Embedded] ([https://launchpad.net/gcc-arm-embedded Ältere Releases]) für Cortex-R4/R5/R7/R8/M0(+)/M3/M4(F)/M7/M23/M33. Windows, Linux, Mac, bereitgestellt von ARM selbst, vollständiger Support für FPUs, C++11, kein Code-Size-Limit
* [http://www.mentor.com/embedded-software/codesourcery Mentor Graphics Sourcery Tools (vormals CodeSourcery CodeBench Lite)] Windows, Linux
* [http://sourceforge.net/projects/devkitpro/ devkitPro]
* [http://www.lpcware.com/lpcxpresso/home LPCXpresso] (vormals CodeRed IDE) ist eine IDE von NXP für die LPC-Mikrocontroller die den GCC enthält
* [http://www.yagarto.de/ Yagarto] (Windows, mit Eclipse-Integration) - veraltet
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm WinARM] - veraltet
* GNUARM - veraltet
* summon-arm Toolchain: hat einen Compiler-Bug [http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg353473.html] und sollte daher nicht verwendet werden, wenn man floatingpoint-Typen einsetzen möchte (egal ob mit oder ohne FPU).

Beim Einsatz des gcc in Verbindung mit in C geschriebenem startup-Code bei den Optimierungslevels "-O2" und "-O3" muss zusätzlich "-fno-gcse" gesetzt werden, da ansonsten die von der CPU benötigte NVIC-Tabelle(n) und zugehörige Funktionen u.U. nicht so aussehen wie sie sollten.

Siehe auch [http://embdev.net/topic/129986#1175214 ARM-GCC development resources] im Forum.

== Nutzung mit eigener Umgebung/Kommandozeile ==
Hier einige Hinweise wie man den GCC direkt verwenden kann (zB. mit selbstgebautem makefile), falls man das nicht von einer Entwicklungsumgebung machen lässt.
=== Compiler & Linker Flags ===
Die Flags, die festlegen, welcher Core verwendet wird, sind in der folgenden Tabelle beschrieben:
{| class="wikitable"
! Option
! style="text-align: center;" | Cortex-M0
! style="text-align: center;" | Cortex-M0+
! style="text-align: center;" | Cortex-M3
! style="text-align: center;" | Cortex-M4
! style="text-align: center;" | Cortex-M7
! style="text-align: center;" | Cortex-M33
! style="text-align: center;" | Cortex-M23
|-
| CPU
| -mcpu=cortex-m01
| -mcpu=cortex-m0plus1
| -,mcpu=cortex-m3
| -mcpu=cortex-m4
| -mcpu=cortex-m7
| -mcpu=cortex-m33
| -mcpu=cortex-m23
|-
| Float ABI
| colspan="3" style="text-align: center;" | -mfloat-abi=soft
| colspan="3" style="text-align: center;" | -mfloat-abi=soft

-mfloat-abi=softfp

-mfloat-abi=hard
| style="text-align: center;" | -mfloat-abi=soft
|-
| FPU
| colspan="3" |
| -mfpu=fpv4-sp-d16
| -mfpu=fpv5-d16
| ?
|
|-
| Instruction Set
| colspan="7" style="text-align: center;" | -mthumb
|}
[1]Anmerkung: Es gibt für diese Cores 2 Optionen (für den Hersteller): diese Betreffen die Multipplikationsbefehle.
* Die übliche Implementierung enthält einen 1-Takt-Multiplizierer
* Für reduzierete Chipfläche kann auche ein 32-Takt-Multiplizierer ausgewählt werden
Um nun bei Multiplikationen mit Konstanten nicht die langsame 32-Takt-Multiplikation zu nutzen kann der Compiler angewiesen werden, dort Shifts oder Ähnliches zu generieren.
Um dem Compiler das mitzuteilen wird der Paramter, der die CPU angibt, abgeändert: -mcpu=cortex-m0[plus].small-multiply

Zusätzlich zu diesen Flags gibt es noch die Maschinenunabhängigen Parameter, wovon hier nur einige wichtigen erläutert werden:

{| class="wikitable"
! style="width: 20% | Option !! Erklärung
|-
| -W[all, extra]
| Lässt den Compiler Warnungen ausgeben.
-Wall gibt nur Standard-Warnungen aus, nicht alle!
-Wextra erzeugt noch einmal mehr Warnungen.
|-
| -O[0,1,2,3,s,g]
| Wählt die Art der Optimierung.
-O0: keine Optimierung
-O[1,2,3]: Optimierung auf Ausführungsgeschwindigkeit. Je höher die Stufe, desto aggressiver ist die Optimierung. Das führt unter Umständen zu beträchtlich größerem Code
-Os: Optimierung auf Codegröße
-Og: Optimierung, aber so, dass das Debugging nicht erschwert wird
|-
| -fdata-sections
-ffunction-sections
| Teilt jeder Funktion/jeder Variable eine eigene Section zu.Damit kann der Linker mit der Option --gc-sections ungenutzte Funktionen entfernen. Siehe [[GCC:_unbenutzte_Funktionen_entfernen]]
|-
| -Wl,--gc-sections
| Der Linker verwirft unreferenzierte Sections und packt diese damit nicht ins Binary. Siehe [[GCC:_unbenutzte_Funktionen_entfernen]]
|-
| -g
| Erzeugt Debugging-Informationen.
Siehe auch [[https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html]]
|-
| -fno-rtti
-fno-exceptions
| C++-Optionen
Teilt dem Compiler mit, dass
- keine Runtime Type Information zu generieren sind
- keine Exceptions benutzt werden und damit kein Overhead generiert werden muss.
|-
| -flto
| Link-Time-Optimizations:
Der Linker optimiert den kompletten Code. Da er nicht nur ein Source-File, sondern alle kennt, kann er optimieren, wo dem Compiler Informationen fehlen.
Achtung: bei älteren Compiler-Versionen muss nach diesem Flag noch einmal die Optimierungsstufe angegeben werden.
|}

Die [http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary GCC Dokumentation] listet alle Parameter auf, auch [http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options Parameter speziell für ARM].

* Siehe auch das [https://launchpadlibrarian.net/135588846/readme.txt Readme vom GCC-ARM-Embedded]
* Um das -flto -Flag verwenden zu können, muss der GCC [http://gcc.gnu.org/onlinedocs/gccint/LTO.html LTO] unterstützen. Beim GCC-ARM-Embedded ist dies ab Version 4.7-2013-q2-update der Fall.
* Die LTO erkennt die ISR's und den Interrupt Vector möglicherweise als "unbenutzt" und optimiert sie daher weg. Dies kann durch Markierung der Funktionen & Variablen mit "__attribute__ ((used))" verhindert werden.
* Alle Compileroptionen müssen auch beim Linken mit angegeben werden (ist in obiger Tabelle berücksichtigt), da auch dann u.U. Code generiert werden kann.

=== 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. Das Script ist praktisch Controller-spezifisch, es gibt Beispiel-Scripte der Controller-Hersteller.
* 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. Startupcode im allgemeinen ist meistens in Assembler geschrieben, aber die ARM-Architektur macht aber auch einfacheren C/C++-Code möglich. Auch für den Startupcode gibt es Beispiele der Controller-Hersteller.

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.

=== FPU der Cortex-M4F nutzen ===
Um die FPU zu nutzen, muss der Compiler per [[#Compiler_.26_Linker_Flags|Flag]] dazu gebracht werden, FPU-Instruktionen zu generieren.

Außerdem muss vor Benutzung der FPU-Befehle die FPU aktiviert werden, dies geschieht typischerweise im Startupcode, bevor die main() -Funktion aufgerufen wird. Hier die entsprechenden Befehle, falls sie im verwendeten Startupcode nicht onehin schon enthalten sind:
<pre>/*FPU settings*/
ldr r0, =0xE000ED88 /* Enable CP10,CP11 */
ldr r1,[r0]
orr r1,r1,#(0xF << 20)
str r1,[r0]</pre>
In C/C++ unter Verwendung der CMSIS geht es so:
<syntaxhighlight lang="c">
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
</syntaxhighlight>

Weiterhin sollte die GCC-Distribution auch Laufzeitbibliotheken mit FPU-Unterstützung mitbringen (CodeBench lite und Yagarto werden ohne ausgeleifert, GCC-ARM-Embedded mit).

Am Beispiel der STM32F4 mehr dazu in diesem Thread: [http://www.mikrocontroller.net/topic/261021 Floating Pointing Unit STM32F4]

== Links ==
* [http://www.mikrocontroller.net/topic/298976#3197418 Hier] finden sich noch ein paar Tipps, für den 1. kann aber mittlerweile der GCC-ARM-Embedded direkt verwendet werden, da er jetzt LTO unterstützt (s.o.).
* [https://www.mikrocontroller.net/topic/178840 Thread]: Unterschied arm-none-eabi-gcc und arm-elf-gcc

[[Category:ARM]]
[[Category:Compiler]]

Diskussion:LPC-Mikrocontroller

2017-02-11T17:06:01Z

Newgeneration: Neuer Abschnitt /* Umstrukturierung der Seite */

Gleitkommazahlen

2017-01-31T13:23:34Z

Newgeneration: Hinzufügen der Berechnung von Hand

Gleitkommazahlen sind eine Möglichkeit für Computer und Mikrocontroller mit rationalen Zahlen (also Brüche und Kommazahlen) zu rechnen. Die damit verbundene Gleitkommaarithmetik ist das Gegenstück zur [[Festkommaarithmetik]].

Um effizient mit Gleitkommazahlen zu rechnen empfiehlt sich ein Controller mit eingebauter [[FPU]], da dieser Hardware-Befehle zum Umgang mit diesen besitzt. Sonst muss die Toolchain alle Gleitkommaoperationen mittels mehrerer Hardwarebefehle nachbilden, was Zeit und Speicher kostet.

== Darstellung von Zahlen ==
Anders als gewohnt werden die Zahlen nicht einfach binär gespeichert, sondern nach dem IEEE-754-Format:

x = (-1)s * m * be

* x ist die gewünschte Zahl im Gleitkommaformat
* s ist das Vorzeichen-bit: 0 entspricht +, 1 entspricht -
* m ist die sogenannte Mantisse, sie speichert die Ziffern der Zahl
* b ist die Basis 2 und
* e ist der Exponent, dieser gibt die Position des Kommas an

Die Anzahl der Bits für Exponent und Mantisse hängen von der gewünschten Genauigkeit ab.
Die Programmiersprache [[C]] (und die davon abgeleiteten) kennen folgende Genauigkeiten:
{| class="wikitable"
|-
! style="width:10%" | Datentyp !! style="width:10%" | Anzahl Bits !! style="width:7.5%" | Sign !! style="width:10%" | Mantisse !! style="width:10%" | Exponent !! Anmerkung
|-
| ''float'' || style="text-align:right"| 32 Bit || style="text-align:right"| 1 bit || style="text-align:right"| 23 bit || style="text-align:right"| 8 bit || ''single precision''
|-
| ''double'' || style="text-align:right"| 64 Bit || style="text-align:right"| 1 bit || style="text-align:right"| 52 bit || style="text-align:right"| 11 bit || ''double precision''
Achtung: Abweichend vom Standard sind double beim [[AVR-GCC]] und der avr-libc auch nur 32 Bit!
|-
| ''long double'' || style="text-align:right"| 80 Bit || style="text-align:right"| 1 bit || style="text-align:right"| 64 bit || style="text-align:right"| 15 bit || ''extendend precision''
Achtung: Der C Standard legt nicht genau fest, wie long double zu implementieren ist. Diese Angaben sind also nicht allgemein gültig.
|}

Gespeichert wird in der folgenden Reihenfolge:

<syntaxhighlight lang="pre">
+------+----------+----------+
| Sign | Exponent | Mantisse |
+------+----------+----------+
</syntaxhighlight>
Wobei der Exponent rechtsbündig ist, die Mantisse dagegen linksbündig. Das LSB steht immer rechts, das MSB links.

== Berechnung von Hand ==
Als Beispiel soll die Zahl -12,75 dienen. Diese soll ins IEEE754-single-precision-Format gewandelt werden.

Zuerst muss man die Mantisse berechnen: Das funktioniert in 3 Schritten:
# Umrechnen: Vom Dezimalsystem ins Dualsystem konvertieren. 12,7510 -> 1100,11
# Normieren: Das Komma wird so weit verschoben, bis es genau eine führende 1 gibt. 1,10011
# Mantisse: die führende 1 Kommt bei jeder Zahl (mit Ausnahme von den Spezialfällen) vor, also ist sie redundant und wird nicht gespeichert. Somit ist das Bitmuster unserer Mantisse 10011

Der Exponent ist eigentlich auch ganz einfach: dieser gibt an, um wie viele Stellen wir das Komma verschoben haben, im Beispiel also 3. Allerdings wird im Exponent nicht nur eine 3 gespeichert, denn dann wären Negative Exponenten nicht (so einfach) möglich. Deswegen wird der Exponent 0 einfach auf die Hälfte minus 1 der maximal darstellbaren Zahl festgelegt, bei ''float'' mit einem 8-bit-Exponent also auf 256 / 2 -1 = 127. Dies nennt sich Bias. Bei ''double'' ist dieser Bias dementsprechend 1023. Um nun den "richtigen" wert des Exponenten herauszubekommen muss man nun diesen Bias zu unserem Wert 3 addieren, was 130 ergibt.

Nun muss man nur noch die Ergebnisse zusammenbasteln:
* Die Zahl ist negativ, also ist das Sign-Bit gesetzt
* Der Exponent ist 13010 bzw. 1000 00102
* Die Mantisse ist 100112 und wird linksbündig gespeichert.

<syntaxhighlight lang="pre">
+-+--------+-----------------------+
|S|Exponent| Mantisse |
+-+--------+-----------------------+
|1|10000010|10011000000000000000000|
+-+--------+-----------------------+
</syntaxhighlight>

== Vorteile ==
* hoher Dynamikbereich: je nach dem wie viele Bits genutzt werden können sehr sehr kleine und sehr große Werte dargestellt werden
* Extra definierte Zahlen für -INF (minus Unendlich), +INF (plus Unendlich) und NaN (not a number), die bei Rechenoperationen herauskommen können und somit geprüft werden können. So sind (immer bei Gleitkommarechnungen, nicht Integer) eine Zahl (ungleich 0) / 0 immer INF (+ oder - je nach dem ob die Zahl größer oder kleiner 0 war). 0/0 entspricht immer NaN. Bei Integerrechnungen sind diese Operationen undefiniert.
* Formeln können mehr oder weniger komplett und direkt übernommen werden. Es muss nur darauf geachtet werden, dass die Operationen auch in float/double ausgeführt werden.

Ein kleines Beispielprogramm:
<syntaxhighlight lang="c">
#include <stdio.h>
int main() {
double a = 5 / 3;
printf("5 / 3 = %.10f (Berechnung mittels int)\n", a);
double b = 5.0 / 3.0;
printf("5 / 3 = %.10f (Berechnung mittels double)\n", b);
double c = (double)5 / 3;
printf("5 / 3 = %.10f (Berechnung mittels cast auf double)", c);
return 0;
}
</syntaxhighlight>
Dieses hat die folgende Ausgabe:
<syntaxhighlight lang="pre">
5 / 3 = 1.0000000000 (Berechnung mittels int)
5 / 3 = 1.6666666667 (Berechnung mittels double)
5 / 3 = 1.6666666667 (Berechnung mittels cast auf double)
</syntaxhighlight>

== Nachteile ==
* Unterläufe von sehr kleinen Zahlen auf 0
* Auslöschung bei Subtraktion: Bei zwei fast gleich großen Zahlen wird das Ergebnis falsch
* Prüfen auf Gleichheit: siehe [http://stackoverflow.com/questions/17333/most-effective-way-for-float-and-double-comparison hier]
* Absorption, dazu wieder ein kleines Beispiel:
<syntaxhighlight lang="c">
#include <stdio.h>
int main() {
float little = 0.0000001F;
float huge = 100000.0000000F;
printf("little = %17.10f\n", little);
printf("huge = %17.10f\n", huge);
printf("little + huge = %17.10f", little + huge);
return 0;
}
</syntaxhighlight>
Dieses hat die folgende Ausgabe:
<syntaxhighlight lang="pre">
little = 0.0000001000
huge = 100000.0000000000
little + huge = 100000.0000000000
</syntaxhighlight>
Wie man sehen kann: Durch die viel kleinere Zahl und den damit verbundenen Ungenauigkeiten bei der Rechnung ändert die Rechnung nichts.

* Ungenaue Darstellung von Zahlen
<syntaxhighlight lang="c">
#include <stdio.h>
int main() {
// ich habe dieses Beispiel gewählt, weil meine "tolle und hochgenaue" Taschenrechner App dieses Ergebnis ausgab
printf("6,4 - 6,85 = %.15f", 6.4 - 6.85);
return 0;
}
</syntaxhighlight>
Ausgabe:
<syntaxhighlight lang="pre">
6,4 - 6,85 = -0.449999999999999
</syntaxhighlight>
Sollte ja eigentlich -0,45 sein. Aber weil der Computer mit der Basis 2, wie Menschen im allgemeinen mit der Basis 10 rechnen, sind diese für uns einfachen Zahlen für einen Computer eben nicht genau darzustellen. Und dann passieren bei Rechnungen solche Fehler

== Zusammenfassung ==
Gleitkommazahlen sind kein Allheilmittel, im Gegenteil. Sie sollten nur mit bedacht eingesetzt werden.
Das Problem ist, das viele Leute gar nicht wissen, was Gleitkommazahlen eigentlich sind und vor allem wie sie Aufgebaut sind.

Bei Problemen mit kleinem oder gar keinem Dynamikbereich ist oftmals [[Festkommaarithmetik]] die bessere Wahl.

Wenn man Gleitkommazahlen jedoch mit bedacht einsetzt und immer die möglichen Fehler im Kopf hat, dann sind diese sehr mächtig.

== Literatur ==
* [http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html What Every Computer Scientist Should Know About Floating-Point Arithmetic]
* [https://www.cs.berkeley.edu/~wkahan/MathSand.pdf Abhandlung von 1983 über Gleitkommazahlen in Taschenrechnern (HP-15C) und anderen präzisen Berechnungen (8087 FPU)]

Umstieg von Arduino auf AVR

2017-01-02T21:02:41Z

Newgeneration: /* Voraussetzungen */

''von newgenertion''

Dieser Artikel soll eine kleine Hilfestellung für alle sein, die aktuell mit einem Arduino-Board arbeiten, sich aber mehr für die Materie interessieren und auf richtige Mikrocontroller-Programmierung umsteigen wollen.

Um den Umstieg zu erleichtern werden hier einige kleine, aber hilfreiche Schritte aufgezeigt.
Diese Anleitung ist nur für die Arduinos mit einem 8bit-AVR als Prozessor (Uno, Mega, Leonardo, ...) gedacht und nicht für 32bit-Mikrocontroller (Due, ...).

Der Mikrocontroller wird in dieser Anleitung in C programmiert. Grund dafür ist die Verteilung von Programmiersprachen und deren Schwierigkeit zu erlernen.
Auf Mikrocontrollern gibt es hauptsächlich Assembler und C, wobei auch andere Sprachen im Kommen sind, so zum Beispiel C++ (das Arduino-Framework ist in C++ geschrieben).

Trotzdem soll sich hier auf C beschränkt werden, weil
# C++ schwerer zu Beherrschen ist als C
# Die meisten Arduino-Sketches eher in C geschrieben sind, mit Ausnahme der Arduino-Libraries und derer Objekte
# Assembler nochmal eine ganz andere Sprache ist

== Voraussetzungen ==
=== C-Kenntnisse ===
Wer schon C programmieren kann - damit ist mehr als if-else- und Copy&Paste-Programmierung gemeint - kann diesen Punkt selbstverständlich überspringen. Allen anderen kann ich nur wärmstens empfehlen, ein C-Buch oder wenigstens ein (gutes) C-Tutorial durchzuarbeiten.

Im Artikel [[C#PC-Programmierung|C]] stehen einige Links zu Tutorials und Einführungen zur Sprache C. Es dürfte einfacher sein, sich die C-Kenntnisse auf einem PC zu erarbeiten, da man dort viel mehr Möglichkeiten hat, sein Programm zu analysieren und auf Fehler zu reagieren.

'''Achtung:''' Tutorials, vor allem die in deutscher Sprache, sollten teilweise Hinterfragt werden. Oftmals schreibt der Autor einfach nur seine (zum Teil begrenzte) Sicht der Dinge. Es kann nicht schaden, mehr als ein Tutorial zu lesen und bei Diskrepanzen den C-Standard zu Rate zu ziehen.

=== Andere Vorkenntnisse ===
* [[Bitmanipulation]]
* [[Harvard-Architektur]]
* Wissen über [[AVR]] und [[Mikrocontroller]] allgemein kann nicht schaden

=== Software ===
* Compiler: Man sollte entweder die Pfade zu den Executables des avr-gccs in der Arduino-Umgebung zur Umgebungsvariable PATH hinzufügen oder, vor allem wenn man die Arduino-IDE später deinstallieren möchte, eine separate Compiler-Installation vornehmen. Siehe dazu [[AVR-GCC]].
* Ein Terminal-Programm wie Putty oder HTerm kann nie schaden.

== Verändern des Arduino-Sketches ==
Als Erstes sollte man sich abgewöhnen von ''Sketchen'' zu reden, damit wird man nur belächelt. Es sind ''Programme'', ''Anwendungen'', ''Applikationen'', ...

=== Anpassung von int-Typen ===
Fast sämtliche Arduino-Beispiele sehen irgendwie so aus (hier ein kleines Lauflicht):
<syntaxhighlight lang="c">
int ledPin = 13; // LED connected to digital pin 13

void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
for(int i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(ledPin, HIGH); // sets the Board-LED on
}

void loop()
{
for(int i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*
Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Fällt euch etwas auf? Nein?
Wie groß ist ein ''int''? Genau mindestens 16 bit. Und es ist ein Typ mit Vorzeichen.

Eine Variable vom Typ ''int'' kann auf einem AVR also Werte von -2^15 bis 2^15 - 1 annemhen. Das sind Zahlen zwischen -32768 und 32767. Und was wird in diesem Typ gespeichert?

* Eine ''Variable'', deren Wert sich nie ändert: int ledPin = 13;
* Und zwei Laufvariablen von 0 bis 7.
Also beides nicht wirklich das, wofür man 16 bit Variablen braucht.

Okay, dann hat man halt Variablen mit einem zu großen Typ definiert, was macht das? Schon etwas, denn der AVR ist ein 8bit-Mikrocontroller, das bedeutet grob, dass er immer nur 8bit-Zahlen auf einmal manipulieren kann, alles größere braucht mehrere Befehle und ist somit langsamer. Mikrocontroller mögen vorzeichenlose Zahlen auch lieber, als solche mit Vorzeichen.

Man sollte also bei jeder Variable überlegen, welchen Wertebereich man benötigt und dann immer den Typen so klein wie möglich, aber so groß wie nötig nehmen.

Der C-Standard bietet Typen mit genauer Bitbreite an, dafür muss nur eine Header-Datei eingebunden werden:
<syntaxhighlight lang="c">
#include <stdint.h>
</syntaxhighlight>
In dieser werden dann unter anderem die folgenden Typen definiert:
{| border="1" class="wikitable"
! Größe || Vorzeichenlos || Vorzeichenbehaftet
|-
| 8 bit || uint8_t || int8_t
|-
| 16 bit || uint16_t || int16_t
|-
| 32 bit || uint32_t || int32_t
|-
| 64 bit || uint64_t || int64_t
|}
Die Nomenklatur ist eigentlich ganz einfach:
[u]int[bits]_t, wobei das [u] für unsigned, also vorzeichenlos, steht und [bits] eben die Anzahl der Bits für die Variable angibt.

Der geänderte Source-Code sieht dann so aus:
<syntaxhighlight lang="c">
#include <stdint.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben.
Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Bei diesem Minimal-Programm hat diese Änderung wie man sieht nichts gebracht, das zeigt aber '''nicht''', dass diese Anpassung sinnlos ist, sondern, dass der Compiler sehr gut optimiert und diese unnötig großen Variablen eliminiert.

Ein anderes Beispiel ist dieses Programm. Es macht nichts außer eine volatile-Variable hochzuzählen. (Volatile zum verbieten der Optimierungen).
<syntaxhighlight lang="c">
#include <stdint.h>
// 64bit
volatile int64_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 570 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 17 Bytes (0%) des dynamischen Speichers,
2031 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Wenn man jetzt die Variable verkleinert und auf unsigned ändert:
<syntaxhighlight lang="c">
#include <stdint.h>
// 8bit
volatile uint8_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 458 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 10 Bytes (0%) des dynamischen Speichers,
2038 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Schon bei diesem Minimal-Programm sieht man einen kleinen Unterschied

Bei größeren Programmen mit mehreren Modulen kann der Compiler aber nicht mehr alles überblicken, deswegen lohnt sich spätestens dort diese Änderung.

=== Entfernen der Arduino-Libraries ===
Wer seinen Mikrocontroller richtig verstehen will, der sollte auch versuchen sämtliche Hardware-Ansteuerung selber zu programmieren.

==== Entfernen der delay()-Aufrufen ====
Zuerst einmal: delays sind so gut wie immer schlecht! Während der Controller im delay() wartet, kann er nichts anderes mehr tun!

Die Implementierung vom delay() in der Arduino-Bibliothek benutzt Interrupts und kann deswegen in Interrupts nicht funktionieren (Obwohl das sowieso eine sehr schlechte Idee ist). Um aber von Arduino und deren Library wegzukommen, benutzen wie eine andere Impementierung, nämlich die von der avr-libc. Diese bietet _delay_ms() und _delay_us() für taktgenaue Verzögerungen in Milli- bzw. Mikrosekunden-Bereich an. Dafür ist nur das Einbinden von <util/delay.h> nötig.
<syntaxhighlight lang="c">
#include <stdint.h>
#include <util/delay.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 828 Bytes (2%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>

==== Entfernen der I/O-Aufrufe ====
Dazu zählen unter anderem pinMode, digitalWrite und ditigalRead. Diese verbindet allesamt eines: Die eigenwillige Nummerierung der Pins.

Auf dem Arduino-Board sind sie zwar logisch angeordnet, aber nicht unbedingt logisch mit dem Prozessor verbunden! Deswegen muss man einmal nach seinem arduino board + Pinout googlen, dann kommen schöne Bilder, die recht Anschaulich zeigen, was womit verbunden ist. Beim Arduino Uno ist das Ganze noch recht ordentlich, beim Arduino Mega erinnert es mehr an Chaos...

Eine Seite, die viele Pinouts hat ist [https://libraries.io/github/Bouni/Arduino-Pinout libraries.io]. Dort sucht man sich einfach sein Board heraus und speichert sich am besten das Bild, denn das wird noch häufiger benötigt.

Um jetzt wirklich starten zu können fehlt nur noch eins: das Datenblatt des Prozessors. Auf der Arduino-Seite steht, was für ein Prozessor dort verbaut ist, nach diesem Datenblatt sollte man dann bei Google oder direkt beim Hersteller Atmel suchen. Beim Arduino Uno ist es der [http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf ATmega328p].

Im Datenblatt gibt es ein Kaptiel "I/O-Ports", wo haarklein erklärt wird, wie die Pins funktionieren und anzusteuern sind. Wichtig sind dazu vor allem drei [[Register]]:
* PORT''x'' - The Port ''x'' Data Register
* DDR''x'' - The Port ''x'' Data Direction Register
* PIN''x'' - The Port ''x'' Input Pin Register
Wobei das ''x'' für den Port steht. Welche Ports es gibt hängt vom jeweiligen AVR ab. Der Atmega328p hat zum Beispiel vier Stück: PORTA, PORTB, PORTC, PORTD. Ein ATmega2560 hingegen hat derer elf: PORTA - PORTH und PORTJ - PORTL.
Gemeinsam ist allen, dass ein Port maximal 8 Pins enthält (P''XN'', ''X''=Port-Buchstabe, ''N''=Port-Bit).

Genaueres gibt es hier:
* [[AVR-GCC-Tutorial#Zugriff_auf_Register| Register-Zugriffe]]
* [[AVR-GCC-Tutorial#Zugriff_auf_IO-Ports| I/O-Ports]]
Eine Kurzfassung folgt nun:

Um auf die I/O-Register (beziehungsweise Register allgemein) zugreifen zu können braucht man eine weiter Header-Datei:
<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Mittels diesen Registern kann man dann jeden einzelnen Pin steuern. Die folgende Tabelle zeigt die Einstellungsmöglichkeiten:
<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! DDRx || PORTx || IO-Pin-Zustand
|-
|align="center" | 0
|align="center" | 0
|| Eingang ohne Pull-Up (Resetzustand)
|-
|align="center" | 0
|align="center" | 1
|| Eingang mit Pull-Up
|-
|align="center" | 1
|align="center" | 0
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf LOW
|-
|align="center" | 1
|align="center" | 1
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf HIGH
|}
</center>
Das übrige PINx-Register hat nun auch wieder zwei Einsatzmöglichkeiten. Wenn der Pin ein Input-Pin ist (DDxn = 0), dann gibt dieses Register den Zustand des Pins aus, eine 1 für High und eine 0 für Low. Ist der Pin jedoch als Ausgang konfiguriert, dann können neuere AVRs (praktisch alle auf Arduinos) den Pin direkt "togglen", also umschalten: ist er aktuell High, dann wird er auf Low geschalten, und umgekehrt.

Mit diesem Wissen können wir wieder unseren Code anpacken:
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

void setup()
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 534 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Man sieht: der Speicherverbrauch wurde nochmal gedrückt, und schneller wurde das Programm auch noch.

Bleiben aber noch Fragen: Warum verbraucht dieses Mini-Programm immer noch so viel Flash? Un warum wird RAM verbraucht, obwohl keine einzige Variable verwendet wird?

'''''TODO''''': Geschwindigkeit mittels Oszi messen ''(Darf gerne auch von jemand anderem gemacht werden)''.

=== main()-Funktion statt setup() & loop() ===
Die Arduino-IDE hat im Vergleich zu anderen IDEs eine "Gemeinheit" eingebaut. Um es dem Benutzer einfacher zu manchen, ändert diese stillschweigend den Code (fügt etwa eine main()-Funktion hinzu und das include <Arduino.h>) und zieht Code mitein, selbst wenn dieser nicht genutzt wird.

So zum Beispiel die Interrupt-Routine, die den Millisekunden-Timer für die delay()-Funktion bildet: Sowohl die Routine an sich, als auch die Konfigurierung des Interrupts und auch die generelle Erlaubnis aller ISRs geschieht automatisch, ohne das der User daran etwas ändern kann.

Das ist im Normalfall auch in Ordnung, da sich der 08/15-Arduino-Benutzer gar nicht dafür interessiert.

Bei uns ist das aber etwas anderes! Also wird das Programm an ein richtiges C-Programm angeglichen, also mit einer main()-Funktion, statt setup() und loop().
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

int main(void)
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
while(1)
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
}
/*
Der Sketch verwendet 222 Bytes (0%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers,
2048 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Et voilà! Da haben wir es: Der Code-Verbrauch ist nochmal drastisch gesunken und vor allem: keine Varaible, kein RAM-Verbrauch!

Damit ist jeder Arduino-Code, der im Hintergrund dazukam, getilgt.

'''Anmerkung:''' Der Compiler mag shiften um Variablen nicht, also das (1 << i). Es ist wesentlich besser, wenn man so etwas schreibt:
<syntaxhighlight lang="c">
uint8_t mask = (1 << 0);
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= mask; // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~mask; // sets the LED on pin off
mask = (mask << 1); // shift the bit to the left
}
</syntaxhighlight>
Das ist erstens schneller und verbraucht zweitens weniger Speicher (im Beispiel nur noch 204 Bytes).

== Weg von der Arduino-IDE ==
=== Auswahl der neuen IDE ===
So, nun ist man an dem Punkt angelangt, an welchem man sich dazu entscheiden kann (und ''meiner'' Meinung auch sollte), Abschied von der Arduino-IDE zu nehmen. Diese ist in vielerlei Hinsicht nicht optimal, sei es zum Beispiel beim highlighting von Code oder der mangelnden Konfigurationsmöglichkeit.

Es gibt zahlreiche Möglichkeiten, wie man nun weiter verfahren kann:
* bei der Arduino-IDE bleiben
* auf das [[Atmel Studio]] umsteigen (entweder Version 7 mit zahlreichen neuen Features, oder VErsion 4, falls es schnell und zuverlässig sein soll)
* auf eine andere IDE (z.B. [[eclipse]]) umsteigen
* Mittels [[AVR-GCC-Tutorial/Exkurs_Makefiles|Makefiles]] und einem Editor/einer IDE seiner Wahl arbeiten

Ich persönlich habe mich nach langen arbeiten mit jeder dieser Möglichkeiten (abgesehen von der Arduino-IDE, diese habe ich mehr oder weniger direkt verworfen) für die letzte, für das Arbeiten mit Makefiles, entschieden. Dort hat man völlige Kontrolle über alles: was wird wann mit welchen Option kompiliert und was wird hinzugelinkt?

Das sollte aber jeder für sich selber herausfinden. Die Liste oben ist von der Schwierigkeit her sortiert, das bedeutet, das Makefiles das anspruchsvollste sind.

=== Einarbeiten in die neue Umgebung ===
Sobald man sich auf eine IDE festgelegt hat, sollte man sich in diese erst einmal Einarbeiten. Auf diesem Punkt kann in dieser Anleitung nicht eingegangen werden, da sich mögliche Tipps oder Ähnliches ja nach IDE unterscheiden würden.

Am besten versucht man erstmal die für sich wichtigen Funktionen zu finden und mit der neuen Umgebung allgemein zurech zu kommen.

Ziel ist auf jeden Fall, das obige Programm zu kompilieren zu bekommen.

=== Das Programm übertragen ===
So weit, so gut.

Der neue Editor/Die neue IDE läuft, der Code kompiliert.

Doch wie bringt man nun den Code auf den AVR? Dazu gibt es unter Anderem zwei Möglichkeiten auf die ich hier eingehen möchte:
* mit extra [[AVR_In_System_Programmer|Programmer/Debugger]]
* mittels dem eingebrannten [[Bootloader]]
Was das ist wird hier nicht erklärt, dafür sind die Artikel verlinkt.

==== Programmer/Debugger ====
Wer schon einen Programmer oder gar Debugger für AVRs sein Eigen nennen kann, der sollte diesen verwenden, da damit noch einmal der Speicherplatz für den Bootloader frei wird (Dadurch kann das Programm noch einmal ~2kB größer werden) und auch die Wartezeit nach jedem Reset entfällt.

Wer noch keinen Programmer hat, der muss sich nicht unbedingt einen solchen kaufen, solange er mit den eben genannten Nachteilen leben kann.

Wer aber jetzt in die Tasche greifen will, der kann sich überlegen, ob er vielleicht nicht lieber direkt einen vollwertigen Debugger kauft. Damit kann man, wie auch am PC, ein laufendes Programm anhalten, Werte von Registern anzeigen, etc. So etwas kann sehr hilfreich sein, wenn "unerklärliche" Phänomene auftreten.

Wie man mit dem Programmer dann schließlich den AVR programmiert hängt wieder von der IDE ab. Beim Atmel Studio wird man sicherlich auf den Programming Dialog zurückgreifen, bei anderen IDEs wird wahrscheinlich ein Drittprogram wie [[AVRDUDE|avrdude]] verwendet.

==== Bootloader ====
Alle Arduinos kommen mit einem vorinstalliertem Bootloader. Mit diesem lässt sich der Prozessor auch ohne Programmer über USB direkt flashen.

Also PC-Programm bietet sich dazu [[AVRDUDE|avrdude]] an. Dieses ist ein mehr oder weniger "Universales" Brennprogramm für fast alle AVR-Typen. Es beherrscht auch die Kommunikation mit dem Arduino-Bootloader. Damit kann man dann ganz einfach sein Programm übertragen. Die Kommandozeile ist leider je nach Arduino- und Bootloader-Versio etwas anderes
<syntaxhighlight lang="bash">
# beim Arduino mega ist es
$ avrdude -cwiring -patmega2560 -P<serial port> -b115200 -U flash:w:<file> -D
# andere Konfigurationen könnten sein (von mir ungetestet, gerne zu Vervollständigen)
$ avrdude -carduino -patmega328p -P<serial port> -b115200 -U flash:w:<file> -D
$ avrdude -carduino -patmega328p -P<serial port> -b57600 -U flash:w:<file> -D
$ avrdude -cstk500v2 -patmega328p -P<serial port> -b115200 -U flash:w:<file> -D
</syntaxhighlight>

== Arduino-Library Ersatz ==
Nachdem das Minimal-Programm von oben nun auf dem AVR-Board getestet wurde, geht es weiter.

Wir haben uns von Arduino verabschiedet, damit aber auch von allen Arduino-Libraries! Das bedeutet, dass selbst so banale Sachen wie Serial.println() nicht mehr existieren. Diese müssen wir nun selber schreiben.

=== Erstellen eigener Libraries ===
Hier soll nun ein Beispiel mit einer Schritt-für-Schritt-Anleitung gegeben werden. Dazu habe ich mir das UART-Modul ausgesucht.

==== Serielle Kommunikation mittels UART-Hardware ====
Das wird zwar dann die X-te UART library, aber zur Demonstration eignet sich das UART-Modul hervorragend.

'''''TODO''''': Verlinkungen zu weiterführenden Artikeln, Beispiel für UART und LCD library selbst geschrieben, ...

[[Kategorie:C]]
[[Kategorie:avr-gcc Tutorial]]
[[Kategorie:AVR]]
[[Kategorie:AVR-Boards]]
[[Kategorie:avr-gcc]]
[[Kategorie:Baustelle]]

Umstieg von Arduino auf AVR

2017-01-02T20:56:49Z

Newgeneration: Programmer/Bootloader und Libraries hinzugefügt

''von newgenertion''

Dieser Artikel soll eine kleine Hilfestellung für alle sein, die aktuell mit einem Arduino-Board arbeiten, sich aber mehr für die Materie interessieren und auf richtige Mikrocontroller-Programmierung umsteigen wollen.

Um den Umstieg zu erleichtern werden hier einige kleine, aber hilfreiche Schritte aufgezeigt.
Diese Anleitung ist nur für die Arduinos mit einem 8bit-AVR als Prozessor (Uno, Mega, Leonardo, ...) gedacht und nicht für 32bit-Mikrocontroller (Due, ...).

Der Mikrocontroller wird in dieser Anleitung in C programmiert. Grund dafür ist die Verteilung von Programmiersprachen und deren Schwierigkeit zu erlernen.
Auf Mikrocontrollern gibt es hauptsächlich Assembler und C, wobei auch andere Sprachen im Kommen sind, so zum Beispiel C++ (das Arduino-Framework ist in C++ geschrieben).

Trotzdem soll sich hier auf C beschränkt werden, weil
# C++ schwerer zu Beherrschen ist als C
# Die meisten Arduino-Sketches eher in C geschrieben sind, mit Ausnahme der Arduino-Libraries und derer Objekte
# Assembler nochmal eine ganz andere Sprache ist

== Voraussetzungen ==
=== C-Kenntnisse ===
Wer schon C programmieren kann - damit ist mehr als if-else- und Copy&Paste-Programmierung gemeint - kann diesen Punkt selbstverständlich überspringen. Allen anderen kann ich nur wärmstens empfehlen, ein C-Buch oder wenigstens ein (gutes) C-Tutorial durchzuarbeiten.

Im Artikel [[C#PC-Programmierung|C]] stehen einige Links zu Tutorials und Einführungen zur Sprache C. Es dürfte einfacher sein, sich die C-Kenntnisse auf einem PC zu erarbeiten, da man dort viel mehr Möglichkeiten hat, sein Programm zu analysieren und auf Fehler zu reagieren.

'''Achtung:''' Tutorials, vor allem die in deutscher Sprache, sollten teilweise Hinterfragt werden. Oftmals schreibt der Autor einfach nur seine (zum Teil begrenzte) Sicht der Dinge. Es kann nicht schaden, mehr als ein Tutorial zu lesen und bei Diskrepanzen den C-Standard zu Rate zu ziehen.

=== Andere Vorkenntnisse ===
* [[Bitmanipulation]]
* [[Harvard-Architektur]]
* Wissen über [[AVR]] und [[Mikrocontroller]] allgemein kann nicht schaden

== Verändern des Arduino-Sketches ==
Als Erstes sollte man sich abgewöhnen von ''Sketchen'' zu reden, damit wird man nur belächelt. Es sind ''Programme'', ''Anwendungen'', ''Applikationen'', ...

=== Anpassung von int-Typen ===
Fast sämtliche Arduino-Beispiele sehen irgendwie so aus (hier ein kleines Lauflicht):
<syntaxhighlight lang="c">
int ledPin = 13; // LED connected to digital pin 13

void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
for(int i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(ledPin, HIGH); // sets the Board-LED on
}

void loop()
{
for(int i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*
Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Fällt euch etwas auf? Nein?
Wie groß ist ein ''int''? Genau mindestens 16 bit. Und es ist ein Typ mit Vorzeichen.

Eine Variable vom Typ ''int'' kann auf einem AVR also Werte von -2^15 bis 2^15 - 1 annemhen. Das sind Zahlen zwischen -32768 und 32767. Und was wird in diesem Typ gespeichert?

* Eine ''Variable'', deren Wert sich nie ändert: int ledPin = 13;
* Und zwei Laufvariablen von 0 bis 7.
Also beides nicht wirklich das, wofür man 16 bit Variablen braucht.

Okay, dann hat man halt Variablen mit einem zu großen Typ definiert, was macht das? Schon etwas, denn der AVR ist ein 8bit-Mikrocontroller, das bedeutet grob, dass er immer nur 8bit-Zahlen auf einmal manipulieren kann, alles größere braucht mehrere Befehle und ist somit langsamer. Mikrocontroller mögen vorzeichenlose Zahlen auch lieber, als solche mit Vorzeichen.

Man sollte also bei jeder Variable überlegen, welchen Wertebereich man benötigt und dann immer den Typen so klein wie möglich, aber so groß wie nötig nehmen.

Der C-Standard bietet Typen mit genauer Bitbreite an, dafür muss nur eine Header-Datei eingebunden werden:
<syntaxhighlight lang="c">
#include <stdint.h>
</syntaxhighlight>
In dieser werden dann unter anderem die folgenden Typen definiert:
{| border="1" class="wikitable"
! Größe || Vorzeichenlos || Vorzeichenbehaftet
|-
| 8 bit || uint8_t || int8_t
|-
| 16 bit || uint16_t || int16_t
|-
| 32 bit || uint32_t || int32_t
|-
| 64 bit || uint64_t || int64_t
|}
Die Nomenklatur ist eigentlich ganz einfach:
[u]int[bits]_t, wobei das [u] für unsigned, also vorzeichenlos, steht und [bits] eben die Anzahl der Bits für die Variable angibt.

Der geänderte Source-Code sieht dann so aus:
<syntaxhighlight lang="c">
#include <stdint.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben.
Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Bei diesem Minimal-Programm hat diese Änderung wie man sieht nichts gebracht, das zeigt aber '''nicht''', dass diese Anpassung sinnlos ist, sondern, dass der Compiler sehr gut optimiert und diese unnötig großen Variablen eliminiert.

Ein anderes Beispiel ist dieses Programm. Es macht nichts außer eine volatile-Variable hochzuzählen. (Volatile zum verbieten der Optimierungen).
<syntaxhighlight lang="c">
#include <stdint.h>
// 64bit
volatile int64_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 570 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 17 Bytes (0%) des dynamischen Speichers,
2031 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Wenn man jetzt die Variable verkleinert und auf unsigned ändert:
<syntaxhighlight lang="c">
#include <stdint.h>
// 8bit
volatile uint8_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 458 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 10 Bytes (0%) des dynamischen Speichers,
2038 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Schon bei diesem Minimal-Programm sieht man einen kleinen Unterschied

Bei größeren Programmen mit mehreren Modulen kann der Compiler aber nicht mehr alles überblicken, deswegen lohnt sich spätestens dort diese Änderung.

=== Entfernen der Arduino-Libraries ===
Wer seinen Mikrocontroller richtig verstehen will, der sollte auch versuchen sämtliche Hardware-Ansteuerung selber zu programmieren.

==== Entfernen der delay()-Aufrufen ====
Zuerst einmal: delays sind so gut wie immer schlecht! Während der Controller im delay() wartet, kann er nichts anderes mehr tun!

Die Implementierung vom delay() in der Arduino-Bibliothek benutzt Interrupts und kann deswegen in Interrupts nicht funktionieren (Obwohl das sowieso eine sehr schlechte Idee ist). Um aber von Arduino und deren Library wegzukommen, benutzen wie eine andere Impementierung, nämlich die von der avr-libc. Diese bietet _delay_ms() und _delay_us() für taktgenaue Verzögerungen in Milli- bzw. Mikrosekunden-Bereich an. Dafür ist nur das Einbinden von <util/delay.h> nötig.
<syntaxhighlight lang="c">
#include <stdint.h>
#include <util/delay.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 828 Bytes (2%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>

==== Entfernen der I/O-Aufrufe ====
Dazu zählen unter anderem pinMode, digitalWrite und ditigalRead. Diese verbindet allesamt eines: Die eigenwillige Nummerierung der Pins.

Auf dem Arduino-Board sind sie zwar logisch angeordnet, aber nicht unbedingt logisch mit dem Prozessor verbunden! Deswegen muss man einmal nach seinem arduino board + Pinout googlen, dann kommen schöne Bilder, die recht Anschaulich zeigen, was womit verbunden ist. Beim Arduino Uno ist das Ganze noch recht ordentlich, beim Arduino Mega erinnert es mehr an Chaos...

Eine Seite, die viele Pinouts hat ist [https://libraries.io/github/Bouni/Arduino-Pinout libraries.io]. Dort sucht man sich einfach sein Board heraus und speichert sich am besten das Bild, denn das wird noch häufiger benötigt.

Um jetzt wirklich starten zu können fehlt nur noch eins: das Datenblatt des Prozessors. Auf der Arduino-Seite steht, was für ein Prozessor dort verbaut ist, nach diesem Datenblatt sollte man dann bei Google oder direkt beim Hersteller Atmel suchen. Beim Arduino Uno ist es der [http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf ATmega328p].

Im Datenblatt gibt es ein Kaptiel "I/O-Ports", wo haarklein erklärt wird, wie die Pins funktionieren und anzusteuern sind. Wichtig sind dazu vor allem drei [[Register]]:
* PORT''x'' - The Port ''x'' Data Register
* DDR''x'' - The Port ''x'' Data Direction Register
* PIN''x'' - The Port ''x'' Input Pin Register
Wobei das ''x'' für den Port steht. Welche Ports es gibt hängt vom jeweiligen AVR ab. Der Atmega328p hat zum Beispiel vier Stück: PORTA, PORTB, PORTC, PORTD. Ein ATmega2560 hingegen hat derer elf: PORTA - PORTH und PORTJ - PORTL.
Gemeinsam ist allen, dass ein Port maximal 8 Pins enthält (P''XN'', ''X''=Port-Buchstabe, ''N''=Port-Bit).

Genaueres gibt es hier:
* [[AVR-GCC-Tutorial#Zugriff_auf_Register| Register-Zugriffe]]
* [[AVR-GCC-Tutorial#Zugriff_auf_IO-Ports| I/O-Ports]]
Eine Kurzfassung folgt nun:

Um auf die I/O-Register (beziehungsweise Register allgemein) zugreifen zu können braucht man eine weiter Header-Datei:
<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Mittels diesen Registern kann man dann jeden einzelnen Pin steuern. Die folgende Tabelle zeigt die Einstellungsmöglichkeiten:
<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! DDRx || PORTx || IO-Pin-Zustand
|-
|align="center" | 0
|align="center" | 0
|| Eingang ohne Pull-Up (Resetzustand)
|-
|align="center" | 0
|align="center" | 1
|| Eingang mit Pull-Up
|-
|align="center" | 1
|align="center" | 0
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf LOW
|-
|align="center" | 1
|align="center" | 1
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf HIGH
|}
</center>
Das übrige PINx-Register hat nun auch wieder zwei Einsatzmöglichkeiten. Wenn der Pin ein Input-Pin ist (DDxn = 0), dann gibt dieses Register den Zustand des Pins aus, eine 1 für High und eine 0 für Low. Ist der Pin jedoch als Ausgang konfiguriert, dann können neuere AVRs (praktisch alle auf Arduinos) den Pin direkt "togglen", also umschalten: ist er aktuell High, dann wird er auf Low geschalten, und umgekehrt.

Mit diesem Wissen können wir wieder unseren Code anpacken:
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

void setup()
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 534 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Man sieht: der Speicherverbrauch wurde nochmal gedrückt, und schneller wurde das Programm auch noch.

Bleiben aber noch Fragen: Warum verbraucht dieses Mini-Programm immer noch so viel Flash? Un warum wird RAM verbraucht, obwohl keine einzige Variable verwendet wird?

'''''TODO''''': Geschwindigkeit mittels Oszi messen ''(Darf gerne auch von jemand anderem gemacht werden)''.

=== main()-Funktion statt setup() & loop() ===
Die Arduino-IDE hat im Vergleich zu anderen IDEs eine "Gemeinheit" eingebaut. Um es dem Benutzer einfacher zu manchen, ändert diese stillschweigend den Code (fügt etwa eine main()-Funktion hinzu und das include <Arduino.h>) und zieht Code mitein, selbst wenn dieser nicht genutzt wird.

So zum Beispiel die Interrupt-Routine, die den Millisekunden-Timer für die delay()-Funktion bildet: Sowohl die Routine an sich, als auch die Konfigurierung des Interrupts und auch die generelle Erlaubnis aller ISRs geschieht automatisch, ohne das der User daran etwas ändern kann.

Das ist im Normalfall auch in Ordnung, da sich der 08/15-Arduino-Benutzer gar nicht dafür interessiert.

Bei uns ist das aber etwas anderes! Also wird das Programm an ein richtiges C-Programm angeglichen, also mit einer main()-Funktion, statt setup() und loop().
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

int main(void)
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
while(1)
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
}
/*
Der Sketch verwendet 222 Bytes (0%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers,
2048 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Et voilà! Da haben wir es: Der Code-Verbrauch ist nochmal drastisch gesunken und vor allem: keine Varaible, kein RAM-Verbrauch!

Damit ist jeder Arduino-Code, der im Hintergrund dazukam, getilgt.

'''Anmerkung:''' Der Compiler mag shiften um Variablen nicht, also das (1 << i). Es ist wesentlich besser, wenn man so etwas schreibt:
<syntaxhighlight lang="c">
uint8_t mask = (1 << 0);
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= mask; // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~mask; // sets the LED on pin off
mask = (mask << 1); // shift the bit to the left
}
</syntaxhighlight>
Das ist erstens schneller und verbraucht zweitens weniger Speicher (im Beispiel nur noch 204 Bytes).

== Weg von der Arduino-IDE ==
=== Auswahl der neuen IDE ===
So, nun ist man an dem Punkt angelangt, an welchem man sich dazu entscheiden kann (und ''meiner'' Meinung auch sollte), Abschied von der Arduino-IDE zu nehmen. Diese ist in vielerlei Hinsicht nicht optimal, sei es zum Beispiel beim highlighting von Code oder der mangelnden Konfigurationsmöglichkeit.

Es gibt zahlreiche Möglichkeiten, wie man nun weiter verfahren kann:
* bei der Arduino-IDE bleiben
* auf das [[Atmel Studio]] umsteigen (entweder Version 7 mit zahlreichen neuen Features, oder VErsion 4, falls es schnell und zuverlässig sein soll)
* auf eine andere IDE (z.B. [[eclipse]]) umsteigen
* Mittels [[AVR-GCC-Tutorial/Exkurs_Makefiles|Makefiles]] und einem Editor/einer IDE seiner Wahl arbeiten

Ich persönlich habe mich nach langen arbeiten mit jeder dieser Möglichkeiten (abgesehen von der Arduino-IDE, diese habe ich mehr oder weniger direkt verworfen) für die letzte, für das Arbeiten mit Makefiles, entschieden. Dort hat man völlige Kontrolle über alles: was wird wann mit welchen Option kompiliert und was wird hinzugelinkt?

Das sollte aber jeder für sich selber herausfinden. Die Liste oben ist von der Schwierigkeit her sortiert, das bedeutet, das Makefiles das anspruchsvollste sind.

=== Einarbeiten in die neue Umgebung ===
Sobald man sich auf eine IDE festgelegt hat, sollte man sich in diese erst einmal Einarbeiten. Auf diesem Punkt kann in dieser Anleitung nicht eingegangen werden, da sich mögliche Tipps oder Ähnliches ja nach IDE unterscheiden würden.

Am besten versucht man erstmal die für sich wichtigen Funktionen zu finden und mit der neuen Umgebung allgemein zurech zu kommen.

Ziel ist auf jeden Fall, das obige Programm zu kompilieren zu bekommen.

=== Das Programm übertragen ===
So weit, so gut.

Der neue Editor/Die neue IDE läuft, der Code kompiliert.

Doch wie bringt man nun den Code auf den AVR? Dazu gibt es unter Anderem zwei Möglichkeiten auf die ich hier eingehen möchte:
* mit extra [[AVR_In_System_Programmer|Programmer/Debugger]]
* mittels dem eingebrannten [[Bootloader]]
Was das ist wird hier nicht erklärt, dafür sind die Artikel verlinkt.

==== Programmer/Debugger ====
Wer schon einen Programmer oder gar Debugger für AVRs sein Eigen nennen kann, der sollte diesen verwenden, da damit noch einmal der Speicherplatz für den Bootloader frei wird (Dadurch kann das Programm noch einmal ~2kB größer werden) und auch die Wartezeit nach jedem Reset entfällt.

Wer noch keinen Programmer hat, der muss sich nicht unbedingt einen solchen kaufen, solange er mit den eben genannten Nachteilen leben kann.

Wer aber jetzt in die Tasche greifen will, der kann sich überlegen, ob er vielleicht nicht lieber direkt einen vollwertigen Debugger kauft. Damit kann man, wie auch am PC, ein laufendes Programm anhalten, Werte von Registern anzeigen, etc. So etwas kann sehr hilfreich sein, wenn "unerklärliche" Phänomene auftreten.

Wie man mit dem Programmer dann schließlich den AVR programmiert hängt wieder von der IDE ab. Beim Atmel Studio wird man sicherlich auf den Programming Dialog zurückgreifen, bei anderen IDEs wird wahrscheinlich ein Drittprogram wie [[AVRDUDE|avrdude]] verwendet.

==== Bootloader ====
Alle Arduinos kommen mit einem vorinstalliertem Bootloader. Mit diesem lässt sich der Prozessor auch ohne Programmer über USB direkt flashen.

Also PC-Programm bietet sich dazu [[AVRDUDE|avrdude]] an. Dieses ist ein mehr oder weniger "Universales" Brennprogramm für fast alle AVR-Typen. Es beherrscht auch die Kommunikation mit dem Arduino-Bootloader. Damit kann man dann ganz einfach sein Programm übertragen. Die Kommandozeile ist leider je nach Arduino- und Bootloader-Versio etwas anderes
<syntaxhighlight lang="bash">
# beim Arduino mega ist es
$ avrdude -cwiring -patmega2560 -P<serial port> -b115200 -U flash:w:<file> -D
# andere Konfigurationen könnten sein (von mir ungetestet, gerne zu Vervollständigen)
$ avrdude -carduino -patmega328p -P<serial port> -b115200 -U flash:w:<file> -D
$ avrdude -carduino -patmega328p -P<serial port> -b57600 -U flash:w:<file> -D
$ avrdude -cstk500v2 -patmega328p -P<serial port> -b115200 -U flash:w:<file> -D
</syntaxhighlight>

== Arduino-Library Ersatz ==
Nachdem das Minimal-Programm von oben nun auf dem AVR-Board getestet wurde, geht es weiter.

Wir haben uns von Arduino verabschiedet, damit aber auch von allen Arduino-Libraries! Das bedeutet, dass selbst so banale Sachen wie Serial.println() nicht mehr existieren. Diese müssen wir nun selber schreiben.

=== Erstellen eigener Libraries ===
Hier soll nun ein Beispiel mit einer Schritt-für-Schritt-Anleitung gegeben werden. Dazu habe ich mir das UART-Modul ausgesucht.

==== Serielle Kommunikation mittels UART-Hardware ====
Das wird zwar dann die X-te UART library, aber zur Demonstration eignet sich das UART-Modul hervorragend.

'''''TODO''''': Verlinkungen zu weiterführenden Artikeln, Beispiel für UART und LCD library selbst geschrieben, ...

[[Kategorie:C]]
[[Kategorie:avr-gcc Tutorial]]
[[Kategorie:AVR]]
[[Kategorie:AVR-Boards]]
[[Kategorie:avr-gcc]]
[[Kategorie:Baustelle]]

Umstieg von Arduino auf AVR

2017-01-02T17:50:13Z

Newgeneration: Fehler korrigiert

''von newgenertion''

Dieser Artikel soll eine kleine Hilfestellung für alle sein, die aktuell mit einem Arduino-Board arbeiten, sich aber mehr für die Materie interessieren und auf richtige Mikrocontroller-Programmierung umsteigen wollen.

Um den Umstieg zu erleichtern werden hier einige kleine, aber hilfreiche Schritte aufgezeigt.
Diese Anleitung ist nur für die Arduinos mit einem 8bit-AVR als Prozessor (Uno, Mega, Leonardo, ...) gedacht und nicht für 32bit-Mikrocontroller (Due, ...).

Der Mikrocontroller wird in dieser Anleitung in C programmiert. Grund dafür ist die Verteilung von Programmiersprachen und deren Schwierigkeit zu erlernen.
Auf Mikrocontrollern gibt es hauptsächlich Assembler und C, wobei auch andere Sprachen im Kommen sind, so zum Beispiel C++ (das Arduino-Framework ist in C++ geschrieben).

Trotzdem soll sich hier auf C beschränkt werden, weil
# C++ schwerer zu Beherrschen ist als C
# Die meisten Arduino-Sketches eher in C geschrieben sind, mit Ausnahme der Arduino-Libraries und derer Objekte
# Assembler nochmal eine ganz andere Sprache ist

== C-Buch ==
Wer schon C programmieren kann - damit ist mehr als if-else- und Copy&Paste-Programmierung gemeint - kann diesen Punkt selbstverständlich überspringen. Allen anderen kann ich ihn nur wärmstens empfehlen.

Im Artikel [[C#PC-Programmierung|C]] stehen einige Links zu Tutorials und Einführungen zur Sprache C. Es dürfte einfacher sein, sich die C-Kenntnisse auf einem PC zu erarbeiten, da man dort viel mehr Möglichkeiten hat, sein Programm zu analysieren und auf Fehler zu reagieren.

'''Achtung:''' Tutorials, vor allem die in deutscher Sprache, sollten teilweise Hinterfragt werden. Oftmals schreibt der Autor einfach nur seine (zum Teil begrenzte) Sicht der Dinge. Es kann nicht schaden, mehr als ein Tutorial zu lesen und bei Diskrepanzen den C-Standard zu Rate zu ziehen.

Was auch noch wichtig ist, ist ein Verständnis über Binär-, Dezimal- und Hexadezimalzahlen, sowie über [[Bitmanipulation]].

== Verändern des Arduino-Sketches ==
Als Erstes sollte man sich abgewöhnen von ''Sketchen'' zu reden, damit wird man nur belächelt. Es sind ''Programme'', ''Anwendungen'', ''Applikationen'', ...

=== Anpassung von int-Typen ===
Fast sämtliche Arduino-Beispiele sehen irgendwie so aus (hier ein kleines Lauflicht):
<syntaxhighlight lang="c">
int ledPin = 13; // LED connected to digital pin 13

void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
for(int i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(ledPin, HIGH); // sets the Board-LED on
}

void loop()
{
for(int i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*
Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Fällt euch etwas auf? Nein?
Wie groß ist ein ''int''? Genau mindestens 16 bit. Und es ist ein Typ mit Vorzeichen.

Eine Variable vom Typ ''int'' kann auf einem AVR also Werte von -2^15 bis 2^15 - 1 annemhen. Das sind Zahlen zwischen -32768 und 32767. Und was wird in diesem Typ gespeichert?

* Eine ''Variable'', deren Wert sich nie ändert: int ledPin = 13;
* Und zwei Laufvariablen von 0 bis 7.
Also beides nicht wirklich das, wofür man 16 bit Variablen braucht.

Okay, dann hat man halt Variablen mit einem zu großen Typ definiert, was macht das? Schon etwas, denn der AVR ist ein 8bit-Mikrocontroller, das bedeutet grob, dass er immer nur 8bit-Zahlen auf einmal manipulieren kann, alles größere braucht mehrere Befehle und ist somit langsamer. Mikrocontroller mögen vorzeichenlose Zahlen auch lieber, als solche mit Vorzeichen.

Man sollte also bei jeder Variable überlegen, welchen Wertebereich man benötigt und dann immer den Typen so klein wie möglich, aber so groß wie nötig nehmen.

Der C-Standard bietet Typen mit genauer Bitbreite an, dafür muss nur eine Header-Datei eingebunden werden:
<syntaxhighlight lang="c">
#include <stdint.h>
</syntaxhighlight>
In dieser werden dann unter anderem die folgenden Typen definiert:
{| border="1" class="wikitable"
! Größe || Vorzeichenlos || Vorzeichenbehaftet
|-
| 8 bit || uint8_t || int8_t
|-
| 16 bit || uint16_t || int16_t
|-
| 32 bit || uint32_t || int32_t
|-
| 64 bit || uint64_t || int64_t
|}
Die Nomenklatur ist eigentlich ganz einfach:
[u]int[bits]_t, wobei das [u] für unsigned, also vorzeichenlos, steht und [bits] eben die Anzahl der Bits für die Variable angibt.

Der geänderte Source-Code sieht dann so aus:
<syntaxhighlight lang="c">
#include <stdint.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben.
Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Bei diesem Minimal-Programm hat diese Änderung wie man sieht nichts gebracht, das zeigt aber '''nicht''', dass diese Anpassung sinnlos ist, sondern, dass der Compiler sehr gut optimiert und diese unnötig großen Variablen eliminiert.

Ein anderes Beispiel ist dieses Programm. Es macht nichts außer eine volatile-Variable hochzuzählen. (Volatile zum verbieten der Optimierungen).
<syntaxhighlight lang="c">
#include <stdint.h>
// 64bit
volatile int64_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 570 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 17 Bytes (0%) des dynamischen Speichers,
2031 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Wenn man jetzt die Variable verkleinert und auf unsigned ändert:
<syntaxhighlight lang="c">
#include <stdint.h>
// 8bit
volatile uint8_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 458 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 10 Bytes (0%) des dynamischen Speichers,
2038 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Schon bei diesem Minimal-Programm sieht man einen kleinen Unterschied

Bei größeren Programmen mit mehreren Modulen kann der Compiler aber nicht mehr alles überblicken, deswegen lohnt sich spätestens dort diese Änderung.

=== Entfernen der Arduino-Libraries ===
Wer seinen Mikrocontroller richtig verstehen will, der sollte auch versuchen sämtliche Hardware-Ansteuerung selber zu programmieren.

==== Entfernen der delay()-Aufrufen ====
Zuerst einmal: delays sind so gut wie immer schlecht! Während der Controller im delay() wartet, kann er nichts anderes mehr tun!

Die Implementierung vom delay() in der Arduino-Bibliothek benutzt Interrupts und kann deswegen in Interrupts nicht funktionieren (Obwohl das sowieso eine sehr schlechte Idee ist). Um aber von Arduino und deren Library wegzukommen, benutzen wie eine andere Impementierung, nämlich die von der avr-libc. Diese bietet _delay_ms() und _delay_us() für taktgenaue Verzögerungen in Milli- bzw. Mikrosekunden-Bereich an. Dafür ist nur das Einbinden von <util/delay.h> nötig.
<syntaxhighlight lang="c">
#include <stdint.h>
#include <util/delay.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 828 Bytes (2%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>

==== Entfernen der I/O-Aufrufe ====
Dazu zählen unter anderem pinMode, digitalWrite und ditigalRead. Diese verbindet allesamt eines: Die eigenwillige Nummerierung der Pins.

Auf dem Arduino-Board sind sie zwar logisch angeordnet, aber nicht unbedingt logisch mit dem Prozessor verbunden! Deswegen muss man einmal nach seinem arduino board + Pinout googlen, dann kommen schöne Bilder, die recht Anschaulich zeigen, was womit verbunden ist. Beim Arduino Uno ist das Ganze noch recht ordentlich, beim Arduino Mega erinnert es mehr an Chaos...

Eine Seite, die viele Pinouts hat ist [https://libraries.io/github/Bouni/Arduino-Pinout libraries.io]. Dort sucht man sich einfach sein Board heraus und speichert sich am besten das Bild, denn das wird noch häufiger benötigt.

Um jetzt wirklich starten zu können fehlt nur noch eins: das Datenblatt des Prozessors. Auf der Arduino-Seite steht, was für ein Prozessor dort verbaut ist, nach diesem Datenblatt sollte man dann bei Google oder direkt beim Hersteller Atmel suchen. Beim Arduino Uno ist es der [http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf ATmega328p].

Im Datenblatt gibt es ein Kaptiel "I/O-Ports", wo haarklein erklärt wird, wie die Pins funktionieren und anzusteuern sind. Wichtig sind dazu vor allem drei [[Register]]:
* PORT''x'' - The Port ''x'' Data Register
* DDR''x'' - The Port ''x'' Data Direction Register
* PIN''x'' - The Port ''x'' Input Pin Register
Wobei das ''x'' für den Port steht. Welche Ports es gibt hängt vom jeweiligen AVR ab. Der Atmega328p hat zum Beispiel vier Stück: PORTA, PORTB, PORTC, PORTD. Ein ATmega2560 hingegen hat derer elf: PORTA - PORTH und PORTJ - PORTL.
Gemeinsam ist allen, dass ein Port maximal 8 Pins enthält (P''XN'', ''X''=Port-Buchstabe, ''N''=Port-Bit).

Genaueres gibt es hier:
* [[AVR-GCC-Tutorial#Zugriff_auf_Register| Register-Zugriffe]]
* [[AVR-GCC-Tutorial#Zugriff_auf_IO-Ports| I/O-Ports]]
Eine Kurzfassung folgt nun:

Um auf die I/O-Register (beziehungsweise Register allgemein) zugreifen zu können braucht man eine weiter Header-Datei:
<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Mittels diesen Registern kann man dann jeden einzelnen Pin steuern. Die folgende Tabelle zeigt die Einstellungsmöglichkeiten:
<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! DDRx || PORTx || IO-Pin-Zustand
|-
|align="center" | 0
|align="center" | 0
|| Eingang ohne Pull-Up (Resetzustand)
|-
|align="center" | 0
|align="center" | 1
|| Eingang mit Pull-Up
|-
|align="center" | 1
|align="center" | 0
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf LOW
|-
|align="center" | 1
|align="center" | 1
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf HIGH
|}
</center>
Das übrige PINx-Register hat nun auch wieder zwei Einsatzmöglichkeiten. Wenn der Pin ein Input-Pin ist (DDxn = 0), dann gibt dieses Register den Zustand des Pins aus, eine 1 für High und eine 0 für Low. Ist der Pin jedoch als Ausgang konfiguriert, dann können neuere AVRs (praktisch alle auf Arduinos) den Pin direkt "togglen", also umschalten: ist er aktuell High, dann wird er auf Low geschalten, und umgekehrt.

Mit diesem Wissen können wir wieder unseren Code anpacken:
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

void setup()
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 534 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Man sieht: der Speicherverbrauch wurde nochmal gedrückt, und schneller wurde das Programm auch noch.

Bleiben aber noch Fragen: Warum verbraucht dieses Mini-Programm immer noch so viel Flash? Un warum wird RAM verbraucht, obwohl keine einzige Variable verwendet wird?

'''''TODO''''': Geschwindigkeit mittels Oszi messen.

=== main()-Funktion statt setup() & loop() ===
Die Arduino-IDE hat im Vergleich zu anderen IDEs eine "Gemeinheit" eingebaut. Um es dem Benutzer einfacher zu manchen, ändert diese stillschweigend den Code (fügt etwa eine main()-Funktion hinzu und das include <Arduino.h>) und zieht Code mitein, selbst wenn dieser nicht genutzt wird.

So zum Beispiel die Interrupt-Routine, die den Millisekunden-Timer für die delay()-Funktion bildet: Sowohl die Routine an sich, als auch die Konfigurierung des Interrupts und auch die generelle Erlaubnis aller ISRs geschieht automatisch, ohne das der User daran etwas ändern kann.

Das ist im Normalfall auch in Ordnung, da sich der 08/15-Arduino-Benutzer gar nicht dafür interessiert.

Bei uns ist das aber etwas anderes! Also wird das Programm an ein richtiges C-Programm angeglichen, also mit einer main()-Funktion, statt setup() und loop().
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

int main(void)
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
while(1)
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
}
/*
Der Sketch verwendet 222 Bytes (0%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers,
2048 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Et voilà! Da haben wir es: Der Code-Verbrauch ist nochmal drastisch gesunken und vor allem: keine Varaible, kein RAM-Verbrauch!

Damit ist jeder Arduino-Code, der im Hintergrund dazukam, getilgt.

'''Anmerkung:''' Der Compiler mag shiften um Variablen nicht, also das (1 << i). Es ist wesentlich besser, wenn man so etwas schreibt:
<syntaxhighlight lang="c">
uint8_t mask = (1 << 0);
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= mask; // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~mask; // sets the LED on pin off
mask = (mask << 1); // shift the bit to the left
}
</syntaxhighlight>
Das ist erstens schneller und verbraucht zweitens weniger Speicher (im Beispiel nur noch 204 Bytes).

== Weg von der Arduino-IDE ==
=== Auswahl der neuen IDE ===
So, nun ist man an dem Punkt angelangt, an welchem man sich dazu entscheiden kann (und ''meiner'' Meinung auch sollte), Abschied von der Arduino-IDE zu nehmen. Diese ist in vielerlei Hinsicht nicht optimal, sei es zum Beispiel beim highlighting von Code oder der mangelnden Konfigurationsmöglichkeit.

Es gibt zahlreiche Möglichkeiten, wie man nun weiter verfahren kann:
* bei der Arduino-IDE bleiben
* auf das [[Atmel Studio]] umsteigen (entweder Version 7 mit zahlreichen neuen Features, oder VErsion 4, falls es schnell und zuverlässig sein soll)
* auf eine andere IDE (z.B. [[eclipse]]) umsteigen
* Mittels [[AVR-GCC-Tutorial/Exkurs_Makefiles|Makefiles]] und einem Editor/einer IDE seiner Wahl arbeiten

Ich persönlich habe mich nach langen arbeiten mit jeder dieser Möglichkeiten (abgesehen von der Arduino-IDE, diese habe ich mehr oder weniger direkt verworfen) für die letzte, für das Arbeiten mit Makefiles, entschieden. Dort hat man völlige Kontrolle über alles: was wird wann mit welchen Option kompiliert und was wird hinzugelinkt?

Das sollte aber jeder für sich selber herausfinden. Die Liste oben ist von der Schwierigkeit her sortiert, das bedeutet, das Makefiles das anspruchsvollste sind.

=== Einarbeiten in die neue Umgebung ===
Sobald man sich auf eine IDE festgelegt hat, sollte man sich in diese erst einmal Einarbeiten. Auf diesem Punkt kann in dieser Anleitung nicht eingegangen werden, da sich mögliche Tipps oder Ähnliches ja nach IDE unterscheiden würden.

Am besten versucht man erstmal die für sich wichtigen Funktionen zu finden und mit der neuen Umgebung allgemein zurech zu kommen.

Ziel ist auf jeden Fall, das obige Programm zu kompilieren zu bekommen.

=== Flashen mittels AVRDUDE ===
So weit, so gut.

Der neue Editor/Die neue IDE läuft, der Code kompiliert.

Wie bringt man jetzt den Code auf den AVR?
'''''TODO'''''

'''''TODO''''': Verlinkungen zu weiterführenden Artikeln, Beispiel für UART und LCD library selbst geschrieben, ...

[[Kategorie:C| ]]
[[Kategorie:avr-gcc Tutorial| ]]
[[Kategorie:AVR| ]]
[[Kategorie:AVR-Boards| ]]
[[Kategorie:avr-gcc| ]]
[[Kategorie:Baustelle| ]]

Umstieg von Arduino auf AVR

2017-01-02T17:49:27Z

Newgeneration: Fehler korrigiert

''von newgenertion''

Dieser Artikel soll eine kleine Hilfestellung für alle sein, die aktuell mit einem Arduino-Board arbeiten, sich aber mehr für die Materie interessieren und auf richtige Mikrocontroller-Programmierung umsteigen wollen.

Um den Umstieg zu erleichtern werden hier einige kleine, aber hilfreiche Schritte aufgezeigt.
Diese Anleitung ist nur für die Arduinos mit einem 8bit-AVR als Prozessor (Uno, Mega, Leonardo, ...) gedacht und nicht für 32bit-Mikrocontroller (Due, ...).

Der Mikrocontroller wird in dieser Anleitung in C programmiert. Grund dafür ist die Verteilung von Programmiersprachen und deren Schwierigkeit zu erlernen.
Auf Mikrocontrollern gibt es hauptsächlich Assembler und C, wobei auch andere Sprachen im Kommen sind, so zum Beispiel C++ (das Arduino-Framework ist in C++ geschrieben).

Trotzdem soll sich hier auf C beschränkt werden, weil
# C++ schwerer zu Beherrschen ist als C
# Die meisten Arduino-Sketches eher in C geschrieben sind, mit Ausnahme der Arduino-Libraries und derer Objekte
# Assembler nochmal eine ganz andere Sprache ist

== C-Buch ==
Wer schon C programmieren kann - damit ist mehr als if-else- und Copy&Paste-Programmierung gemeint - kann diesen Punkt selbstverständlich überspringen. Allen anderen kann ich ihn nur wärmstens empfehlen.

Im Artikel [[C#PC-Programmierung|C]] stehen einige Links zu Tutorials und Einführungen zur Sprache C. Es dürfte einfacher sein, sich die C-Kenntnisse auf einem PC zu erarbeiten, da man dort viel mehr Möglichkeiten hat, sein Programm zu analysieren und auf Fehler zu reagieren.

'''Achtung:''' Tutorials, vor allem die in deutscher Sprache, sollten teilweise Hinterfragt werden. Oftmals schreibt der Autor einfach nur seine (zum Teil begrenzte) Sicht der Dinge. Es kann nicht schaden, mehr als ein Tutorial zu lesen und bei Diskrepanzen den C-Standard zu Rate zu ziehen.

Was auch noch wichtig ist, ist ein Verständnis über Binär-, Dezimal- und Hexadezimalzahlen, sowie über [[Bitmanipulation]].

== Verändern des Arduino-Sketches ==
Als Erstes sollte man sich abgewöhnen von ''Sketchen'' zu reden, damit wird man nur belächelt. Es sind ''Programme'', ''Anwendungen'', ''Applikationen'', ...

=== Anpassung von int-Typen ===
Fast sämtliche Arduino-Beispiele sehen irgendwie so aus (hier ein kleines Lauflicht):
<syntaxhighlight lang="c">
int ledPin = 13; // LED connected to digital pin 13

void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
for(int i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(ledPin, HIGH); // sets the Board-LED on
}

void loop()
{
for(int i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*
Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Fällt euch etwas auf? Nein?
Wie groß ist ein ''int''? Genau mindestens 16 bit. Und es ist ein Typ mit Vorzeichen.

Eine Variable vom Typ ''int'' kann auf einem AVR also Werte von -2^15 bis 2^15 - 1 annemhen. Das sind Zahlen zwischen -32768 und 32767. Und was wird in diesem Typ gespeichert?

* Eine ''Variable'', deren Wert sich nie ändert: int ledPin = 13;
* Und zwei Laufvariablen von 0 bis 7.
Also beides nicht wirklich das, wofür man 16 bit Variablen braucht.

Okay, dann hat man halt Variablen mit einem zu großen Typ definiert, was macht das? Schon etwas, denn der AVR ist ein 8bit-Mikrocontroller, das bedeutet grob, dass er immer nur 8bit-Zahlen auf einmal manipulieren kann, alles größere braucht mehrere Befehle und ist somit langsamer. Mikrocontroller mögen vorzeichenlose Zahlen auch lieber, als solche mit Vorzeichen.

Man sollte also bei jeder Variable überlegen, welchen Wertebereich man benötigt und dann immer den Typen so klein wie möglich, aber so groß wie nötig nehmen.

Der C-Standard bietet Typen mit genauer Bitbreite an, dafür muss nur eine Header-Datei eingebunden werden:
<syntaxhighlight lang="c">
#include <stdint.h>
</syntaxhighlight>
In dieser werden dann unter anderem die folgenden Typen definiert:
{| border="1" class="wikitable"
! Größe || Vorzeichenlos || Vorzeichenbehaftet
|-
| 8 bit || uint8_t || int8_t
|-
| 16 bit || uint16_t || int16_t
|-
| 32 bit || uint32_t || int32_t
|-
| 64 bit || uint64_t || int64_t
|}
Die Nomenklatur ist eigentlich ganz einfach:
[u]int[bits]_t, wobei das [u] für unsigned, also vorzeichenlos, steht und [bits] eben die Anzahl der Bits für die Variable angibt.

Der geänderte Source-Code sieht dann so aus:
<syntaxhighlight lang="c">
#include <stdint.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben.
Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Bei diesem Minimal-Programm hat diese Änderung wie man sieht nichts gebracht, das zeigt aber '''nicht''', dass diese Anpassung sinnlos ist, sondern, dass der Compiler sehr gut optimiert und diese unnötig großen Variablen eliminiert.

Ein anderes Beispiel ist dieses Programm. Es macht nichts außer eine volatile-Variable hochzuzählen. (Volatile zum verbieten der Optimierungen).
<syntaxhighlight lang="c">
#include <stdint.h>
// 64bit
volatile int64_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 570 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 17 Bytes (0%) des dynamischen Speichers,
2031 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Wenn man jetzt die Variable verkleinert und auf unsigned ändert:
<syntaxhighlight lang="c">
#include <stdint.h>
// 8bit
volatile uint8_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 458 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 10 Bytes (0%) des dynamischen Speichers,
2038 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Schon bei diesem Minimal-Programm sieht man einen kleinen Unterschied

Bei größeren Programmen mit mehreren Modulen kann der Compiler aber nicht mehr alles überblicken, deswegen lohnt sich spätestens dort diese Änderung.

=== Entfernen der Arduino-Libraries ===
Wer seinen Mikrocontroller richtig verstehen will, der sollte auch versuchen sämtliche Hardware-Ansteuerung selber zu programmieren.

==== Entfernen der delay()-Aufrufen ====
Zuerst einmal: delays sind so gut wie immer schlecht! Während der Controller im delay() wartet, kann er nichts anderes mehr tun!

Die Implementierung vom delay() in der Arduino-Bibliothek benutzt Interrupts und kann deswegen in Interrupts nicht funktionieren (Obwohl das sowieso eine sehr schlechte Idee ist). Um aber von Arduino und deren Library wegzukommen, benutzen wie eine andere Impementierung, nämlich die von der avr-libc. Diese bietet _delay_ms() und _delay_us() für taktgenaue Verzögerungen in Milli- bzw. Mikrosekunden-Bereich an. Dafür ist nur das Einbinden von <util/delay.h> nötig.
<syntaxhighlight lang="c">
#include <stdint.h>
#include <util/delay.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 828 Bytes (2%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>

==== Entfernen der I/O-Aufrufe ====
Dazu zählen unter anderem pinMode, digitalWrite und ditigalRead. Diese verbindet allesamt eines: Die eigenwillige Nummerierung der Pins.

Auf dem Arduino-Board sind sie zwar logisch angeordnet, aber nicht unbedingt logisch mit dem Prozessor verbunden! Deswegen muss man einmal nach seinem arduino board + Pinout googlen, dann kommen schöne Bilder, die recht Anschaulich zeigen, was womit verbunden ist. Beim Arduino Uno ist das Ganze noch recht ordentlich, beim Arduino Mega erinnert es mehr an Chaos...

Eine Seite, die viele Pinouts hat ist [https://libraries.io/github/Bouni/Arduino-Pinout libraries.io]. Dort sucht man sich einfach sein Board heraus und speichert sich am besten das Bild, denn das wird noch häufiger benötigt.

Um jetzt wirklich starten zu können fehlt nur noch eins: das Datenblatt des Prozessors. Auf der Arduino-Seite steht, was für ein Prozessor dort verbaut ist, nach diesem Datenblatt sollte man dann bei Google oder direkt beim Hersteller Atmel suchen. Beim Arduino Uno ist es der [http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf ATmega328p].

Im Datenblatt gibt es ein Kaptiel "I/O-Ports", wo haarklein erklärt wird, wie die Pins funktionieren und anzusteuern sind. Wichtig sind dazu vor allem drei [[Register]]:
* PORT''x'' - The Port ''x'' Data Register
* DDR''x'' - The Port ''x'' Data Direction Register
* PIN''x'' - The Port ''x'' Input Pin Register
Wobei das ''x'' für den Port steht. Welche Ports es gibt hängt vom jeweiligen AVR ab. Der Atmega328p hat zum Beispiel vier Stück: PORTA, PORTB, PORTC, PORTD. Ein ATmega2560 hingegen hat derer elf: PORTA - PORTH und PORTJ - PORTL.
Gemeinsam ist allen, dass ein Port maximal 8 Pins enthält (P''XN'', ''X''=Port-Buchstabe, ''N''=Port-Bit).

Genaueres gibt es hier:
* [[AVR-GCC-Tutorial#Zugriff_auf_Register| Register-Zugriffe]]
* [[AVR-GCC-Tutorial#Zugriff_auf_IO-Ports| I/O-Ports]]
Eine Kurzfassung folgt nun:

Um auf die I/O-Register (beziehungsweise Register allgemein) zugreifen zu können braucht man eine weiter Header-Datei:
<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Mittels diesen Registern kann man dann jeden einzelnen Pin steuern. Die folgende Tabelle zeigt die Einstellungsmöglichkeiten:
<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! DDRx || PORTx || IO-Pin-Zustand
|-
|align="center" | 0
|align="center" | 0
|| Eingang ohne Pull-Up (Resetzustand)
|-
|align="center" | 0
|align="center" | 1
|| Eingang mit Pull-Up
|-
|align="center" | 1
|align="center" | 0
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf LOW
|-
|align="center" | 1
|align="center" | 1
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf HIGH
|}
</center>
Das übrige PINx-Register hat nun auch wieder zwei Einsatzmöglichkeiten. Wenn der Pin ein Input-Pin ist (DDxn = 0), dann gibt dieses Register den Zustand des Pins aus, eine 1 für High und eine 0 für Low. Ist der Pin jedoch als Ausgang konfiguriert, dann können neuere AVRs (praktisch alle auf Arduinos) den Pin direkt "togglen", also umschalten: ist er aktuell High, dann wird er auf Low geschalten, und umgekehrt.

Mit diesem Wissen können wir wieder unseren Code anpacken:
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

void setup()
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
DDRD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
DDRD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 534 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Man sieht: der Speicherverbrauch wurde nochmal gedrückt, und schneller wurde das Programm auch noch.

Bleiben aber noch Fragen: Warum verbraucht dieses Mini-Programm immer noch so viel Flash? Un warum wird RAM verbraucht, obwohl keine einzige Variable verwendet wird?

'''''TODO''''': Geschwindigkeit mittels Oszi messen.

=== main()-Funktion statt setup() & loop() ===
Die Arduino-IDE hat im Vergleich zu anderen IDEs eine "Gemeinheit" eingebaut. Um es dem Benutzer einfacher zu manchen, ändert diese stillschweigend den Code (fügt etwa eine main()-Funktion hinzu und das include <Arduino.h>) und zieht Code mitein, selbst wenn dieser nicht genutzt wird.

So zum Beispiel die Interrupt-Routine, die den Millisekunden-Timer für die delay()-Funktion bildet: Sowohl die Routine an sich, als auch die Konfigurierung des Interrupts und auch die generelle Erlaubnis aller ISRs geschieht automatisch, ohne das der User daran etwas ändern kann.

Das ist im Normalfall auch in Ordnung, da sich der 08/15-Arduino-Benutzer gar nicht dafür interessiert.

Bei uns ist das aber etwas anderes! Also wird das Programm an ein richtiges C-Programm angeglichen, also mit einer main()-Funktion, statt setup() und loop().
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

int main(void)
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
while(1)
{
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
}
/*
Der Sketch verwendet 222 Bytes (0%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers,
2048 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Et voilà! Da haben wir es: Der Code-Verbrauch ist nochmal drastisch gesunken und vor allem: keine Varaible, kein RAM-Verbrauch!

Damit ist jeder Arduino-Code, der im Hintergrund dazukam, getilgt.

'''Anmerkung:''' Der Compiler mag shiften um Variablen nicht, also das (1 << i). Es ist wesentlich besser, wenn man so etwas schreibt:
<syntaxhighlight lang="c">
uint8_t mask = (1 << 0);
for(uint8_t i = 0; i < 8; i++)
{
PORTD |= mask; // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
PORTD &= ~mask; // sets the LED on pin off
mask = (mask << 1); // shift the bit to the left
}
</syntaxhighlight>
Das ist erstens schneller und verbraucht zweitens weniger Speicher (im Beispiel nur noch 204 Bytes).

== Weg von der Arduino-IDE ==
=== Auswahl der neuen IDE ===
So, nun ist man an dem Punkt angelangt, an welchem man sich dazu entscheiden kann (und ''meiner'' Meinung auch sollte), Abschied von der Arduino-IDE zu nehmen. Diese ist in vielerlei Hinsicht nicht optimal, sei es zum Beispiel beim highlighting von Code oder der mangelnden Konfigurationsmöglichkeit.

Es gibt zahlreiche Möglichkeiten, wie man nun weiter verfahren kann:
* bei der Arduino-IDE bleiben
* auf das [[Atmel Studio]] umsteigen (entweder Version 7 mit zahlreichen neuen Features, oder VErsion 4, falls es schnell und zuverlässig sein soll)
* auf eine andere IDE (z.B. [[eclipse]]) umsteigen
* Mittels [[AVR-GCC-Tutorial/Exkurs_Makefiles|Makefiles]] und einem Editor/einer IDE seiner Wahl arbeiten

Ich persönlich habe mich nach langen arbeiten mit jeder dieser Möglichkeiten (abgesehen von der Arduino-IDE, diese habe ich mehr oder weniger direkt verworfen) für die letzte, für das Arbeiten mit Makefiles, entschieden. Dort hat man völlige Kontrolle über alles: was wird wann mit welchen Option kompiliert und was wird hinzugelinkt?

Das sollte aber jeder für sich selber herausfinden. Die Liste oben ist von der Schwierigkeit her sortiert, das bedeutet, das Makefiles das anspruchsvollste sind.

=== Einarbeiten in die neue Umgebung ===
Sobald man sich auf eine IDE festgelegt hat, sollte man sich in diese erst einmal Einarbeiten. Auf diesem Punkt kann in dieser Anleitung nicht eingegangen werden, da sich mögliche Tipps oder Ähnliches ja nach IDE unterscheiden würden.

Am besten versucht man erstmal die für sich wichtigen Funktionen zu finden und mit der neuen Umgebung allgemein zurech zu kommen.

Ziel ist auf jeden Fall, das obige Programm zu kompilieren zu bekommen.

=== Flashen mittels AVRDUDE ===
So weit, so gut.

Der neue Editor/Die neue IDE läuft, der Code kompiliert.

Wie bringt man jetzt den Code auf den AVR?
'''''TODO'''''

'''''TODO''''': Verlinkungen zu weiterführenden Artikeln, Beispiel für UART und LCD library selbst geschrieben, ...

[[Kategorie:C| ]]
[[Kategorie:avr-gcc Tutorial| ]]
[[Kategorie:AVR| ]]
[[Kategorie:AVR-Boards| ]]
[[Kategorie:avr-gcc| ]]
[[Kategorie:Baustelle| ]]

Umstieg von Arduino auf AVR

2017-01-02T17:37:40Z

Newgeneration: IDEs erweitert, AVRDUDE Kapitel angefangen

''von newgenertion''

Dieser Artikel soll eine kleine Hilfestellung für alle sein, die aktuell mit einem Arduino-Board arbeiten, sich aber mehr für die Materie interessieren und auf richtige Mikrocontroller-Programmierung umsteigen wollen.

Um den Umstieg zu erleichtern werden hier einige kleine, aber hilfreiche Schritte aufgezeigt.
Diese Anleitung ist nur für die Arduinos mit einem 8bit-AVR als Prozessor (Uno, Mega, Leonardo, ...) gedacht und nicht für 32bit-Mikrocontroller (Due, ...).

Der Mikrocontroller wird in dieser Anleitung in C programmiert. Grund dafür ist die Verteilung von Programmiersprachen und deren Schwierigkeit zu erlernen.
Auf Mikrocontrollern gibt es hauptsächlich Assembler und C, wobei auch andere Sprachen im Kommen sind, so zum Beispiel C++ (das Arduino-Framework ist in C++ geschrieben).

Trotzdem soll sich hier auf C beschränkt werden, weil
# C++ schwerer zu Beherrschen ist als C
# Die meisten Arduino-Sketches eher in C geschrieben sind, mit Ausnahme der Arduino-Libraries und derer Objekte
# Assembler nochmal eine ganz andere Sprache ist

== C-Buch ==
Wer schon C programmieren kann - damit ist mehr als if-else- und Copy&Paste-Programmierung gemeint - kann diesen Punkt selbstverständlich überspringen. Allen anderen kann ich ihn nur wärmstens empfehlen.

Im Artikel [[C#PC-Programmierung|C]] stehen einige Links zu Tutorials und Einführungen zur Sprache C. Es dürfte einfacher sein, sich die C-Kenntnisse auf einem PC zu erarbeiten, da man dort viel mehr Möglichkeiten hat, sein Programm zu analysieren und auf Fehler zu reagieren.

'''Achtung:''' Tutorials, vor allem die in deutscher Sprache, sollten teilweise Hinterfragt werden. Oftmals schreibt der Autor einfach nur seine (zum Teil begrenzte) Sicht der Dinge. Es kann nicht schaden, mehr als ein Tutorial zu lesen und bei Diskrepanzen den C-Standard zu Rate zu ziehen.

Was auch noch wichtig ist, ist ein Verständnis über Binär-, Dezimal- und Hexadezimalzahlen, sowie über [[Bitmanipulation]].

== Verändern des Arduino-Sketches ==
Als Erstes sollte man sich abgewöhnen von ''Sketchen'' zu reden, damit wird man nur belächelt. Es sind ''Programme'', ''Anwendungen'', ''Applikationen'', ...

=== Anpassung von int-Typen ===
Fast sämtliche Arduino-Beispiele sehen irgendwie so aus (hier ein kleines Lauflicht):
<syntaxhighlight lang="c">
int ledPin = 13; // LED connected to digital pin 13

void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
for(int i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(ledPin, HIGH); // sets the Board-LED on
}

void loop()
{
for(int i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*
Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Fällt euch etwas auf? Nein?
Wie groß ist ein ''int''? Genau mindestens 16 bit. Und es ist ein Typ mit Vorzeichen.

Eine Variable vom Typ ''int'' kann auf einem AVR also Werte von -2^15 bis 2^15 - 1 annemhen. Das sind Zahlen zwischen -32768 und 32767. Und was wird in diesem Typ gespeichert?

* Eine ''Variable'', deren Wert sich nie ändert: int ledPin = 13;
* Und zwei Laufvariablen von 0 bis 7.
Also beides nicht wirklich das, wofür man 16 bit Variablen braucht.

Okay, dann hat man halt Variablen mit einem zu großen Typ definiert, was macht das? Schon etwas, denn der AVR ist ein 8bit-Mikrocontroller, das bedeutet grob, dass er immer nur 8bit-Zahlen auf einmal manipulieren kann, alles größere braucht mehrere Befehle und ist somit langsamer. Mikrocontroller mögen vorzeichenlose Zahlen auch lieber, als solche mit Vorzeichen.

Man sollte also bei jeder Variable überlegen, welchen Wertebereich man benötigt und dann immer den Typen so klein wie möglich, aber so groß wie nötig nehmen.

Der C-Standard bietet Typen mit genauer Bitbreite an, dafür muss nur eine Header-Datei eingebunden werden:
<syntaxhighlight lang="c">
#include <stdint.h>
</syntaxhighlight>
In dieser werden dann unter anderem die folgenden Typen definiert:
{| border="1" class="wikitable"
! Größe || Vorzeichenlos || Vorzeichenbehaftet
|-
| 8 bit || uint8_t || int8_t
|-
| 16 bit || uint16_t || int16_t
|-
| 32 bit || uint32_t || int32_t
|-
| 64 bit || uint64_t || int64_t
|}
Die Nomenklatur ist eigentlich ganz einfach:
[u]int[bits]_t, wobei das [u] für unsigned, also vorzeichenlos, steht und [bits] eben die Anzahl der Bits für die Variable angibt.

Der geänderte Source-Code sieht dann so aus:
<syntaxhighlight lang="c">
#include <stdint.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben.
Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Bei diesem Minimal-Programm hat diese Änderung wie man sieht nichts gebracht, das zeigt aber '''nicht''', dass diese Anpassung sinnlos ist, sondern, dass der Compiler sehr gut optimiert und diese unnötig großen Variablen eliminiert.

Ein anderes Beispiel ist dieses Programm. Es macht nichts außer eine volatile-Variable hochzuzählen. (Volatile zum verbieten der Optimierungen).
<syntaxhighlight lang="c">
#include <stdint.h>
// 64bit
volatile int64_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 570 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 17 Bytes (0%) des dynamischen Speichers,
2031 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Wenn man jetzt die Variable verkleinert und auf unsigned ändert:
<syntaxhighlight lang="c">
#include <stdint.h>
// 8bit
volatile uint8_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 458 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 10 Bytes (0%) des dynamischen Speichers,
2038 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Schon bei diesem Minimal-Programm sieht man einen kleinen Unterschied

Bei größeren Programmen mit mehreren Modulen kann der Compiler aber nicht mehr alles überblicken, deswegen lohnt sich spätestens dort diese Änderung.

=== Entfernen der Arduino-Libraries ===
Wer seinen Mikrocontroller richtig verstehen will, der sollte auch versuchen sämtliche Hardware-Ansteuerung selber zu programmieren.

==== Entfernen der delay()-Aufrufen ====
Zuerst einmal: delays sind so gut wie immer schlecht! Während der Controller im delay() wartet, kann er nichts anderes mehr tun!

Die Implementierung vom delay() in der Arduino-Bibliothek benutzt Interrupts und kann deswegen in Interrupts nicht funktionieren (Obwohl das sowieso eine sehr schlechte Idee ist). Um aber von Arduino und deren Library wegzukommen, benutzen wie eine andere Impementierung, nämlich die von der avr-libc. Diese bietet _delay_ms() und _delay_us() für taktgenaue Verzögerungen in Milli- bzw. Mikrosekunden-Bereich an. Dafür ist nur das Einbinden von <util/delay.h> nötig.
<syntaxhighlight lang="c">
#include <stdint.h>
#include <util/delay.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 828 Bytes (2%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>

==== Entfernen der I/O-Aufrufe ====
Dazu zählen unter anderem pinMode, digitalWrite und ditigalRead. Diese verbindet allesamt eines: Die eigenwillige Nummerierung der Pins.

Auf dem Arduino-Board sind sie zwar logisch angeordnet, aber nicht unbedingt logisch mit dem Prozessor verbunden! Deswegen muss man einmal nach seinem arduino board + Pinout googlen, dann kommen schöne Bilder, die recht Anschaulich zeigen, was womit verbunden ist. Beim Arduino Uno ist das Ganze noch recht ordentlich, beim Arduino Mega erinnert es mehr an Chaos...

Eine Seite, die viele Pinouts hat ist [https://libraries.io/github/Bouni/Arduino-Pinout libraries.io]. Dort sucht man sich einfach sein Board heraus und speichert sich am besten das Bild, denn das wird noch häufiger benötigt.

Um jetzt wirklich starten zu können fehlt nur noch eins: das Datenblatt des Prozessors. Auf der Arduino-Seite steht, was für ein Prozessor dort verbaut ist, nach diesem Datenblatt sollte man dann bei Google oder direkt beim Hersteller Atmel suchen. Beim Arduino Uno ist es der [http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf ATmega328p].

Im Datenblatt gibt es ein Kaptiel "I/O-Ports", wo haarklein erklärt wird, wie die Pins funktionieren und anzusteuern sind. Wichtig sind dazu vor allem drei [[Register]]:
* PORT''x'' - The Port ''x'' Data Register
* DDR''x'' - The Port ''x'' Data Direction Register
* PIN''x'' - The Port ''x'' Input Pin Register
Wobei das ''x'' für den Port steht. Welche Ports es gibt hängt vom jeweiligen AVR ab. Der Atmega328p hat zum Beispiel vier Stück: PORTA, PORTB, PORTC, PORTD. Ein ATmega2560 hingegen hat derer elf: PORTA - PORTH und PORTJ - PORTL.
Gemeinsam ist allen, dass ein Port maximal 8 Pins enthält (P''XN'', ''X''=Port-Buchstabe, ''N''=Port-Bit).

Genaueres gibt es hier:
* [[AVR-GCC-Tutorial#Zugriff_auf_Register| Register-Zugriffe]]
* [[AVR-GCC-Tutorial#Zugriff_auf_IO-Ports| I/O-Ports]]
Eine Kurzfassung folgt nun:

Um auf die I/O-Register (beziehungsweise Register allgemein) zugreifen zu können braucht man eine weiter Header-Datei:
<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Mittels diesen Registern kann man dann jeden einzelnen Pin steuern. Die folgende Tabelle zeigt die Einstellungsmöglichkeiten:
<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! DDRx || PORTx || IO-Pin-Zustand
|-
|align="center" | 0
|align="center" | 0
|| Eingang ohne Pull-Up (Resetzustand)
|-
|align="center" | 0
|align="center" | 1
|| Eingang mit Pull-Up
|-
|align="center" | 1
|align="center" | 0
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf LOW
|-
|align="center" | 1
|align="center" | 1
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf HIGH
|}
</center>
Das übrige PINx-Register hat nun auch wieder zwei Einsatzmöglichkeiten. Wenn der Pin ein Input-Pin ist (DDxn = 0), dann gibt dieses Register den Zustand des Pins aus, eine 1 für High und eine 0 für Low. Ist der Pin jedoch als Ausgang konfiguriert, dann können neuere AVRs (praktisch alle auf Arduinos) den Pin direkt "togglen", also umschalten: ist er aktuell High, dann wird er auf Low geschalten, und umgekehrt.

Mit diesem Wissen können wir wieder unseren Code anpacken:
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

void setup()
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
DDRD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
DDRD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 534 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Man sieht: der Speicherverbrauch wurde nochmal gedrückt, und schneller wurde das Programm auch noch.

Bleiben aber noch Fragen: Warum verbraucht dieses Mini-Programm immer noch so viel Flash? Un warum wird RAM verbraucht, obwohl keine einzige Variable verwendet wird?

'''''TODO''''': Geschwindigkeit mittels Oszi messen.

=== main()-Funktion statt setup() & loop() ===
Die Arduino-IDE hat im Vergleich zu anderen IDEs eine "Gemeinheit" eingebaut. Um es dem Benutzer einfacher zu manchen, ändert diese stillschweigend den Code (fügt etwa eine main()-Funktion hinzu und das include <Arduino.h>) und zieht Code mitein, selbst wenn dieser nicht genutzt wird.

So zum Beispiel die Interrupt-Routine, die den Millisekunden-Timer für die delay()-Funktion bildet: Sowohl die Routine an sich, als auch die Konfigurierung des Interrupts und auch die generelle Erlaubnis aller ISRs geschieht automatisch, ohne das der User daran etwas ändern kann.

Das ist im Normalfall auch in Ordnung, da sich der 08/15-Arduino-Benutzer gar nicht dafür interessiert.

Bei uns ist das aber etwas anderes! Also wird das Programm an ein richtiges C-Programm angeglichen, also mit einer main()-Funktion, statt setup() und loop().
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

int main(void)
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
while(1)
{
for(uint8_t i = 0; i < 8; i++) {
DDRD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
DDRD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
}
/*
Der Sketch verwendet 222 Bytes (0%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers,
2048 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Et voilà! Da haben wir es: Der Code-Verbrauch ist nochmal drastisch gesunken und vor allem: keine Varaible, kein RAM-Verbrauch!

Damit ist jeder Arduino-Code, der im Hintergrund dazukam, getilgt.

== Weg von der Arduino-IDE ==
=== Auswahl der neuen IDE ===
So, nun ist man an dem Punkt angelangt, an welchem man sich dazu entscheiden kann (und ''meiner'' Meinung auch sollte), Abschied von der Arduino-IDE zu nehmen. Diese ist in vielerlei Hinsicht nicht optimal, sei es zum Beispiel beim highlighting von Code oder der mangelnden Konfigurationsmöglichkeit.

Es gibt zahlreiche Möglichkeiten, wie man nun weiter verfahren kann:
* bei der Arduino-IDE bleiben
* auf das [[Atmel Studio]] umsteigen (entweder Version 7 mit zahlreichen neuen Features, oder VErsion 4, falls es schnell und zuverlässig sein soll)
* auf eine andere IDE (z.B. [[eclipse]]) umsteigen
* Mittels [[AVR-GCC-Tutorial/Exkurs_Makefiles|Makefiles]] und einem Editor/einer IDE seiner Wahl arbeiten

Ich persönlich habe mich nach langen arbeiten mit jeder dieser Möglichkeiten (abgesehen von der Arduino-IDE, diese habe ich mehr oder weniger direkt verworfen) für die letzte, für das Arbeiten mit Makefiles, entschieden. Dort hat man völlige Kontrolle über alles: was wird wann mit welchen Option kompiliert und was wird hinzugelinkt?

Das sollte aber jeder für sich selber herausfinden. Die Liste oben ist von der Schwierigkeit her sortiert, das bedeutet, das Makefiles das anspruchsvollste sind.

=== Einarbeiten in die neue Umgebung ===
Sobald man sich auf eine IDE festgelegt hat, sollte man sich in diese erst einmal Einarbeiten. Auf diesem Punkt kann in dieser Anleitung nicht eingegangen werden, da sich mögliche Tipps oder Ähnliches ja nach IDE unterscheiden würden.

Am besten versucht man erstmal die für sich wichtigen Funktionen zu finden und mit der neuen Umgebung allgemein zurech zu kommen.

Ziel ist auf jeden Fall, das obige Programm zu kompilieren zu bekommen.

=== Flashen mittels AVRDUDE ===
So weit, so gut.

Der neue Editor/Die neue IDE läuft, der Code kompiliert.

Wie bringt man jetzt den Code auf den AVR?
'''''TODO'''''

'''''TODO''''': Verlinkungen zu weiterführenden Artikeln, Beispiel für UART und LCD library selbst geschrieben, ...

[[Kategorie:C| ]]
[[Kategorie:avr-gcc Tutorial| ]]
[[Kategorie:AVR| ]]
[[Kategorie:AVR-Boards| ]]
[[Kategorie:avr-gcc| ]]
[[Kategorie:Baustelle| ]]

Umstieg von Arduino auf AVR

2017-01-02T17:16:37Z

Newgeneration: main()-Funktion statt setup() and loop() hinzugefügt

''von newgenertion''

Dieser Artikel soll eine kleine Hilfestellung für alle sein, die aktuell mit einem Arduino-Board arbeiten, sich aber mehr für die Materie interessieren und auf richtige Mikrocontroller-Programmierung umsteigen wollen.

Um den Umstieg zu erleichtern werden hier einige kleine, aber hilfreiche Schritte aufgezeigt.
Diese Anleitung ist nur für die Arduinos mit einem 8bit-AVR als Prozessor (Uno, Mega, Leonardo, ...) gedacht und nicht für 32bit-Mikrocontroller (Due, ...).

Der Mikrocontroller wird in dieser Anleitung in C programmiert. Grund dafür ist die Verteilung von Programmiersprachen und deren Schwierigkeit zu erlernen.
Auf Mikrocontrollern gibt es hauptsächlich Assembler und C, wobei auch andere Sprachen im Kommen sind, so zum Beispiel C++ (das Arduino-Framework ist in C++ geschrieben).

Trotzdem soll sich hier auf C beschränkt werden, weil
# C++ schwerer zu Beherrschen ist als C
# Die meisten Arduino-Sketches eher in C geschrieben sind, mit Ausnahme der Arduino-Libraries und derer Objekte
# Assembler nochmal eine ganz andere Sprache ist

== C-Buch ==
Wer schon C programmieren kann - damit ist mehr als if-else- und Copy&Paste-Programmierung gemeint - kann diesen Punkt selbstverständlich überspringen. Allen anderen kann ich ihn nur wärmstens empfehlen.

Im Artikel [[C#PC-Programmierung|C]] stehen einige Links zu Tutorials und Einführungen zur Sprache C. Es dürfte einfacher sein, sich die C-Kenntnisse auf einem PC zu erarbeiten, da man dort viel mehr Möglichkeiten hat, sein Programm zu analysieren und auf Fehler zu reagieren.

'''Achtung:''' Tutorials, vor allem die in deutscher Sprache, sollten teilweise Hinterfragt werden. Oftmals schreibt der Autor einfach nur seine (zum Teil begrenzte) Sicht der Dinge. Es kann nicht schaden, mehr als ein Tutorial zu lesen und bei Diskrepanzen den C-Standard zu Rate zu ziehen.

Was auch noch wichtig ist, ist ein Verständnis über Binär-, Dezimal- und Hexadezimalzahlen, sowie über [[Bitmanipulation]].

== Verändern des Arduino-Sketches ==
Als Erstes sollte man sich abgewöhnen von ''Sketchen'' zu reden, damit wird man nur belächelt. Es sind ''Programme'', ''Anwendungen'', ''Applikationen'', ...

=== Anpassung von int-Typen ===
Fast sämtliche Arduino-Beispiele sehen irgendwie so aus (hier ein kleines Lauflicht):
<syntaxhighlight lang="c">
int ledPin = 13; // LED connected to digital pin 13

void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
for(int i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(ledPin, HIGH); // sets the Board-LED on
}

void loop()
{
for(int i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*
Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Fällt euch etwas auf? Nein?
Wie groß ist ein ''int''? Genau mindestens 16 bit. Und es ist ein Typ mit Vorzeichen.

Eine Variable vom Typ ''int'' kann auf einem AVR also Werte von -2^15 bis 2^15 - 1 annemhen. Das sind Zahlen zwischen -32768 und 32767. Und was wird in diesem Typ gespeichert?

* Eine ''Variable'', deren Wert sich nie ändert: int ledPin = 13;
* Und zwei Laufvariablen von 0 bis 7.
Also beides nicht wirklich das, wofür man 16 bit Variablen braucht.

Okay, dann hat man halt Variablen mit einem zu großen Typ definiert, was macht das? Schon etwas, denn der AVR ist ein 8bit-Mikrocontroller, das bedeutet grob, dass er immer nur 8bit-Zahlen auf einmal manipulieren kann, alles größere braucht mehrere Befehle und ist somit langsamer. Mikrocontroller mögen vorzeichenlose Zahlen auch lieber, als solche mit Vorzeichen.

Man sollte also bei jeder Variable überlegen, welchen Wertebereich man benötigt und dann immer den Typen so klein wie möglich, aber so groß wie nötig nehmen.

Der C-Standard bietet Typen mit genauer Bitbreite an, dafür muss nur eine Header-Datei eingebunden werden:
<syntaxhighlight lang="c">
#include <stdint.h>
</syntaxhighlight>
In dieser werden dann unter anderem die folgenden Typen definiert:
{| border="1" class="wikitable"
! Größe || Vorzeichenlos || Vorzeichenbehaftet
|-
| 8 bit || uint8_t || int8_t
|-
| 16 bit || uint16_t || int16_t
|-
| 32 bit || uint32_t || int32_t
|-
| 64 bit || uint64_t || int64_t
|}
Die Nomenklatur ist eigentlich ganz einfach:
[u]int[bits]_t, wobei das [u] für unsigned, also vorzeichenlos, steht und [bits] eben die Anzahl der Bits für die Variable angibt.

Der geänderte Source-Code sieht dann so aus:
<syntaxhighlight lang="c">
#include <stdint.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
delay(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
delay(1000); // waits for a second
}
/*Der Sketch verwendet 1006 Bytes (3%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben.
Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Bei diesem Minimal-Programm hat diese Änderung wie man sieht nichts gebracht, das zeigt aber '''nicht''', dass diese Anpassung sinnlos ist, sondern, dass der Compiler sehr gut optimiert und diese unnötig großen Variablen eliminiert.

Ein anderes Beispiel ist dieses Programm. Es macht nichts außer eine volatile-Variable hochzuzählen. (Volatile zum verbieten der Optimierungen).
<syntaxhighlight lang="c">
#include <stdint.h>
// 64bit
volatile int64_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 570 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 17 Bytes (0%) des dynamischen Speichers,
2031 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Wenn man jetzt die Variable verkleinert und auf unsigned ändert:
<syntaxhighlight lang="c">
#include <stdint.h>
// 8bit
volatile uint8_t a;

void setup()
{
a = 0;
}

void loop()
{
a++;
}
/*
Der Sketch verwendet 458 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 10 Bytes (0%) des dynamischen Speichers,
2038 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Schon bei diesem Minimal-Programm sieht man einen kleinen Unterschied

Bei größeren Programmen mit mehreren Modulen kann der Compiler aber nicht mehr alles überblicken, deswegen lohnt sich spätestens dort diese Änderung.

== Entfernen der Arduino-Libraries ==
Wer seinen Mikrocontroller richtig verstehen will, der sollte auch versuchen sämtliche Hardware-Ansteuerung selber zu programmieren.

=== Entfernen der delay()-Aufrufen ===
Zuerst einmal: delays sind so gut wie immer schlecht! Während der Controller im delay() wartet, kann er nichts anderes mehr tun!

Die Implementierung vom delay() in der Arduino-Bibliothek benutzt Interrupts und kann deswegen in Interrupts nicht funktionieren (Obwohl das sowieso eine sehr schlechte Idee ist). Um aber von Arduino und deren Library wegzukommen, benutzen wie eine andere Impementierung, nämlich die von der avr-libc. Diese bietet _delay_ms() und _delay_us() für taktgenaue Verzögerungen in Milli- bzw. Mikrosekunden-Bereich an. Dafür ist nur das Einbinden von <util/delay.h> nötig.
<syntaxhighlight lang="c">
#include <stdint.h>
#include <util/delay.h>

#define LED_PIN 13 // ein Define erzeugt keinen Zusätzlichen Code,
// es erfolgt schließlich nur eine Textersetzung.
// Defines immer in GROSSBUCHSTABEN

void setup()
{
pinMode(LED_PIN, OUTPUT); // sets the digital pin as output
for(uint8_t i = 0; i < 8; i++) {
pinMode(i, OUTPUT); // sets the digital pin as output
}

digitalWrite(LED_PIN, HIGH); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
digitalWrite(i, HIGH); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
digitalWrite(i, LOW); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 828 Bytes (2%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>

=== Entfernen der I/O-Aufrufe ===
Dazu zählen unter anderem pinMode, digitalWrite und ditigalRead. Diese verbindet allesamt eines: Die eigenwillige Nummerierung der Pins.

Auf dem Arduino-Board sind sie zwar logisch angeordnet, aber nicht unbedingt logisch mit dem Prozessor verbunden! Deswegen muss man einmal nach seinem arduino board + Pinout googlen, dann kommen schöne Bilder, die recht Anschaulich zeigen, was womit verbunden ist. Beim Arduino Uno ist das Ganze noch recht ordentlich, beim Arduino Mega erinnert es mehr an Chaos...

Eine Seite, die viele Pinouts hat ist [https://libraries.io/github/Bouni/Arduino-Pinout libraries.io]. Dort sucht man sich einfach sein Board heraus und speichert sich am besten das Bild, denn das wird noch häufiger benötigt.

Um jetzt wirklich starten zu können fehlt nur noch eins: das Datenblatt des Prozessors. Auf der Arduino-Seite steht, was für ein Prozessor dort verbaut ist, nach diesem Datenblatt sollte man dann bei Google oder direkt beim Hersteller Atmel suchen. Beim Arduino Uno ist es der [http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf ATmega328p].

Im Datenblatt gibt es ein Kaptiel "I/O-Ports", wo haarklein erklärt wird, wie die Pins funktionieren und anzusteuern sind. Wichtig sind dazu vor allem drei [[Register]]:
* PORT''x'' - The Port ''x'' Data Register
* DDR''x'' - The Port ''x'' Data Direction Register
* PIN''x'' - The Port ''x'' Input Pin Register
Wobei das ''x'' für den Port steht. Welche Ports es gibt hängt vom jeweiligen AVR ab. Der Atmega328p hat zum Beispiel vier Stück: PORTA, PORTB, PORTC, PORTD. Ein ATmega2560 hingegen hat derer elf: PORTA - PORTH und PORTJ - PORTL.
Gemeinsam ist allen, dass ein Port maximal 8 Pins enthält (P''XN'', ''X''=Port-Buchstabe, ''N''=Port-Bit).

Genaueres gibt es hier:
* [[AVR-GCC-Tutorial#Zugriff_auf_Register| Register-Zugriffe]]
* [[AVR-GCC-Tutorial#Zugriff_auf_IO-Ports| I/O-Ports]]
Eine Kurzfassung folgt nun:

Um auf die I/O-Register (beziehungsweise Register allgemein) zugreifen zu können braucht man eine weiter Header-Datei:
<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Mittels diesen Registern kann man dann jeden einzelnen Pin steuern. Die folgende Tabelle zeigt die Einstellungsmöglichkeiten:
<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! DDRx || PORTx || IO-Pin-Zustand
|-
|align="center" | 0
|align="center" | 0
|| Eingang ohne Pull-Up (Resetzustand)
|-
|align="center" | 0
|align="center" | 1
|| Eingang mit Pull-Up
|-
|align="center" | 1
|align="center" | 0
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf LOW
|-
|align="center" | 1
|align="center" | 1
|| [[Ausgangsstufen_Logik-ICs#Push-Pull | Push-Pull]]-Ausgang auf HIGH
|}
</center>
Das übrige PINx-Register hat nun auch wieder zwei Einsatzmöglichkeiten. Wenn der Pin ein Input-Pin ist (DDxn = 0), dann gibt dieses Register den Zustand des Pins aus, eine 1 für High und eine 0 für Low. Ist der Pin jedoch als Ausgang konfiguriert, dann können neuere AVRs (praktisch alle auf Arduinos) den Pin direkt "togglen", also umschalten: ist er aktuell High, dann wird er auf Low geschalten, und umgekehrt.

Mit diesem Wissen können wir wieder unseren Code anpacken:
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

void setup()
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
}

void loop()
{
for(uint8_t i = 0; i < 8; i++) {
DDRD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
DDRD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
/*
Der Sketch verwendet 534 Bytes (1%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers,
2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Man sieht: der Speicherverbrauch wurde nochmal gedrückt, und schneller wurde das Programm auch noch.

Bleiben aber noch Fragen: Warum verbraucht dieses Mini-Programm immer noch so viel Flash? Un warum wird RAM verbraucht, obwohl keine einzige Variable verwendet wird?

'''''TODO''''': Geschwindigkeit mittels Oszi messen.

== main()-Funktion statt setup() and loop() ==
Die Arduino-IDE hat im Vergleich zu anderen IDEs eine "Gemeinheit" eingebaut. Um es dem Benutzer einfacher zu manchen, ändert diese stillschweigend den Code (fügt etwa eine main()-Funktion hinzu und das include <Arduino.h>) und zieht Code mitein, selbst wenn dieser nicht genutzt wird.

So zum Beispiel die Interrupt-Routine, die den Millisekunden-Timer für die delay()-Funktion bildet: Sowohl die Routine an sich, als auch die Konfigurierung des Interrupts und auch die generelle Erlaubnis aller ISRs geschieht automatisch, ohne das der User daran etwas ändern kann.

Das ist im Normalfall auch in Ordnung, da sich der 08/15-Arduino-Benutzer gar nicht dafür interessiert.

Bei uns ist das aber etwas anderes! Also wird das Programm an ein richtiges C-Programm angeglichen, also mit einer main()-Funktion, statt setup() und loop().
<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/io.h> //neues Include: noetig fuer die Register
#include <util/delay.h>

//Der Arduino-Pin 13 ist auf dem Arduino Uno der Pin PB5
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB5

int main(void)
{
LED_DDR |= (1 << LED_BIT); // sets the digital pin as output

//die 8 LEDs leigen alle auf PORTD, also diesen komplett auf Ausgang
DDRD = 0xFF;

LED_PORT |= (1 << LED_BIT); // sets the Board-LED on
while(1)
{
for(uint8_t i = 0; i < 8; i++) {
DDRD |= (1 << i); // sets the LED on pin on
_delay_ms(100); // waits 100 milliseconds
DDRD &= ~(1 << i); // sets the LED on pin off
}
_delay_ms(1000); // waits for a second
}
}
/*
Der Sketch verwendet 222 Bytes (0%) des Programmspeicherplatzes.
Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers,
2048 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
*/
</syntaxhighlight>
Et voilà! Da haben wir es: Der Code-Verbrauch ist nochmal drastisch gesunken und vor allem: keine Varaible, kein RAM-Verbrauch!

Damit ist jeder Arduino-Code, der im Hintergrund dazukam, getilgt.

== Weg von der Arduino-IDE ==

'''''TODO''''': Umstieg von der Aruino-IDE auf ATMEL Studio 7 mit der Sketch Funktion oder eine beliebige andere IDE. Verlinkungen zu weiterführenden Artikeln, Beispiel für UART und LCD library selbst geschrieben, ...

[[Kategorie:C| ]]
[[Kategorie:avr-gcc Tutorial| ]]
[[Kategorie:AVR| ]]
[[Kategorie:AVR-Boards| ]]
[[Kategorie:avr-gcc| ]]
[[Kategorie:Baustelle| ]]

Umstieg von Arduino auf AVR

2017-01-02T17:07:03Z

Newgeneration:

Umstieg von Arduino auf AVR

2017-01-02T17:05:18Z

Newgeneration:

Umstieg von Arduino auf AVR

2016-12-31T12:56:55Z

Newgeneration: Die Seite wurde neu angelegt: „''von newgenertion'' Dieser Artikel soll eine kleine Hilfestellung für alle sein, die aktuell mit einem Arduino-Board arbeiten, sich aber mehr für die Mater…“

AVR Checkliste

2016-12-30T11:59:33Z

Newgeneration: JTAG Interface: (De-)Aktivierung in Software

[[Category:AVR]]
Diese Seite soll als erste Anlaufstelle dienen, wenn der [[AVR]]-Mikrocontroller mal wieder nicht so will wie er soll. Es wird versucht, die Standardfehler und Probleme aufzulisten und zu erklären, was man dagegen tun kann.

== Hardware ==

=== Pinkompatibilität ===

Wenn man einen anderen Controller als den im Schaltplan benutzt, sollte man daran denken, dass nur wenige AVR-Controller vollständig pinkompatibel und damit untereinander austauschbar sind. Manchmal liegen gar die am dringendsten benötigten Funktionen (ISP-Programmierung) bei anderen Controllern auf anderen Pins. Deshalb unbedingt vorher die Belegungen anhand der Datenblätter vergleichen!

=== Fuses ===

Die AVR-Controller haben 'Fuses' (deutsch: 'Sicherungen'), die das Verhalten des Prozessors auf grundlegender Ebene bestimmen. Ein häufiger Fehler ist beispielsweise, dass über die Fuse "CKSEL" (clock select) die falsche Taktquelle gewählt wurde. Die meisten AVRs können mit dem internen Oszillator (internal R/C), mit einem externen Oszillator (external clock), mit einem Quarz (external crystal) oder mit einem Resonator (external R/C) betrieben werden. Wenn die Einstellung über die Fusebits nicht dazu passt (z. B. external clock statt external crystal), fehlt dem Controller unter Umständen der Systemtakt und er läuft nicht an, oder man bekommt auf der seriellen Schnittstelle Nonsens, oder die Timer bzw. Zeitschleifen im Programm laufen zu langsam oder zu schnell.

Auch die Fuse "JTAGEN" (JTAG enable) verdient besondere Beachtung: Wenn sie eingeschaltet ist, ist auf einem bestimmten Port (z. B. PORTC beim ATMega32) die JTAG-Unterstützung aktiviert. Dann funktionieren vier Bits dieses Ports nicht wie gewohnt, da sie für die JTAG-Schnittstelle reserviert werden.

In dem zum STK500 gehörenden Entwicklungstool 'AVR Studio' gibt es in der Programmer-Dialogbox einen Tab 'Fuses', der controllerabhängig den Status der Fusebits anzeigt und Änderungen ermöglicht.

Siehe auch: [[AVR Fuses]].

=== ISP-Programmieradapter ===

Bei ISP-Programmieradaptern für den Parallelport kann es zu Inkompatibilitäten mit manchen Ports kommen. Tritt das Problem auch auf, wenn der ISP-Adapter an einem anderen Rechner angeschlossen ist? Funktioniert es vielleicht mit einer anderen Software? Siehe auch: [[AVR In System Programmer]].

Dauert bei einem seriellen Programmer mit eigenem Controller (STK500, Atmel AVRISP etc.) das Programmieren sehr lange, oder ist fehlerbehaftet, kann das an einer zu hohen ISP-Taktrate liegen. Sie darf 1/4 des Controllertaktes (F_CPU) nicht übersteigen. Abhilfe: ISP Taktrate heruntersetzen auf maximal 1/4 FCPU.

Beim Programmieren mit dem usbasp Programmieradapter muss die Geschwindigkeit richtig eingestellt werden. Bei einem AVR der auf den eingebauten 1 MHz läuft muss mit langsamer Geschwindigkeit (Jumper zu) programmiert werden.

=== Programmieren via SPI und angeschlossene SPI-Hardware ===
Wenn Peripherie über SPI angebunden ist, muss sich diese zum Programmierzeitpunkt auf dem Bus neutral verhalten. Normalerweise bedeutet dies, dass die Slave-Select/Chip-Select-Leitungen der Peripherie auf high gezogen werden müssen, wenn die Chips keinen internen Pull-Up haben. Werte von 10 kΩ bis 100 kΩ für normale Anwendungen haben sich bewährt.

=== Spannungsversorgung ===

Der Pin AVCC ist der Versorgungsanschluss für den AD-Wandler (ADC, analog digital converter) und den zugehörigen Port. Er ist nicht an allen AVRs vorhanden; wenn er aber existiert, so muss er auf jeden Fall angeschlossen sein, auch wenn der AD-Wandler nicht benutzt wird. Wird der AD-Wandler verwendet, sollte zur Verbesserung der Genauigkeit der AVCC-Pin über einen Lowpass-Filter angeschlossen werden (siehe Datenblatt).

Oft funktioniert die Programmierung des Controllers auch, wenn Vcc oder GND nicht richtig angeschlossen ist. Zur Sicherheit kann man mit einem Messgerät direkt an den Anschlüssen des AVRs kontrollieren (VCC-GND, AVCC-GND), ob die Verbindungen korrekt sind. Es empfiehlt sich, vor dem Einsetzen bzw. Einlöten des Controllers die Versorgungsanschlüsse nochmals zu prüfen, um sicherzustellen, dass man den IC nicht durch eine zu hohe Spannung aufgrund eines Fehlers in der Versorgung zerstört.

Die VCC-Leitung eines Controllers zu unterbrechen (aus welchen Gründen auch immer, z. B. um ihn "komplett abzuschalten") ist nicht ratsam. Falls noch irgendein Pin von einer externen Quelle auf H-Pegel gehalten wird, oder ein Pin über einen Widerstand mit VCC verbunden ist, wird der Controller laufen, weil er über diesen Pin mit Strom versorgt wird. Das ist möglich, weil der Strom über die interne Clamp-Diode des Pins nach VCC fließen kann (und das auch tut). Jeder Pin hat je eine interne Clamp-Diode gegen GND und eine gegen VCC zum Schutz vor zu niedrigen bzw. zu hohen Eingangsspannungen.

=== Reset-Pin ===

Der Reset-Pin am AVR ist 'active-low', d. h. wenn man ihn mit GND (Masse, ground) verbindet, wird der Controller zurückgesetzt gehalten. Zwar haben die meisten(!) AVRs einen internen Pullup-Widerstand, der den Reset-Pin gegen VCC "zieht", dieser ist jedoch relativ hochohmig (ca. 50 kΩ, vgl. Datenblatt) und reicht in extrem stark gestörter Umgebung nicht aus, um den Reset-Pin sicher "hochzuhalten". Als Mindestbeschaltung empfiehlt sich daher ein externer Pullup-Widerstand (typisch 10 kΩ), der den Reset-Pin mit VCC verbindet. Er sollte nicht kleiner als 4,7 kΩ sein, da der Programmieradapter sonst eventuell den Reset-Pin während des Programmiervorgangs nicht sicher auf "low" ziehen kann. Mit einem Oszilloskop kann man gut überprüfen, ob der Pegel am Reset-Pin sauber zwischen H und L wechselt. Zusätzlich sollte man auch noch einen Kondensator 47 nF oder 100 nF zwischen Reset-Pin und GND anordnen. Dieses RC-Glied sorgt dafür, dass der Controller beim Einschalten der Versorgungsspannung für eine definierte Zeitspanne im Reset gehalten wird. Im laufenden Betrieb sorgt der Kondensator dafür, dass der Reseteingang unempfindlich gegenüber Spikes und Glitches wird. Er sollte deshalb unmittelbar in Pin-Nähe beim Prozessor untergebracht werden. Achtung: Wenn [[debugWIRE]] möglich sein soll, muss dieser Kondensator weggelassen werden.

Atmel empfiehlt zusätzlich noch zum Schutz vor Überspannungen eine externe Diode nach VCC ("Clamp-Diode"), da für den Reset-Pin keine interne vorhanden ist. Mit dieser Diode funktionieren jedoch manche Programmieradapter nicht. Allerdings schützt sie den Controller davor, in den High-Voltage-Programming Mode zu schalten, zum Beispiel als Folge von Störspannung wegen EMV, und dadurch (schlimmstenfalls) den Programmspeicher zu überschreiben.

=== Programmierung nur einmal möglich? ===

Es kann vorkommen, dass ein AVR nur einmal programmiert werden kann, danach geht es nicht mehr (z. B. wird der Typ nicht mehr erkannt). Erst nachdem die Versorgungsspannung getrennt und wieder verbunden wurde, geht es erneut. In diesem Fall ist meistens der Reset-Pin kurzgeschlossen, daher lässt sich der AVR einmal programmieren.

Bei korrekter Beschaltung weist der Reset-Pin eine Spannung nahe VCC auf (z. B. 4.9 V). Ist die Spannung nahe bei GND, ist der Pin kurzgeschlossen und verursacht das beschriebene Problem.

=== Abblockkondensatoren ===

Abblockkondensatoren dienen dazu, impulsartige Einbrüche der Betriebsspannung, die durch schnelle Schaltvorgänge verursacht werden können, zu minimieren. Sie verhindern unkontrollierte Brownouts, welche durch diese Spannungseinbrüche auftreten können. Diesen Zweck erfüllen sie optimal, wenn folgende Regeln eingehalten werden:

* Ein Abblockkondensator sollte möglichst dicht am IC sitzen.
* Eine niederimpedante Anbindung sollte gegeben sein – Stegleitungen sind deshalb zu vermeiden. Dann muss die Versorgungsspannung erst durch das Pad des Abblockkondensators fließen und wird dann weiter zum IC gereicht.

* Jedes IC in einer Schaltung sollte einen Abblockkondensator besitzen.

* Bei ICs mit mehreren Anschlüssen für VCC sollte jeder VCC-Pin mit einem eigenen Abblockkondensator beschaltet werden (z. B. AVRs in SMD-Bauform wie dem ATmega16A also mit vier Kondensatoren). Dabei ist darauf zu achten, dass jeder Abblockkondensator mit einem eigenen Via auf die niederimpedante (heißt Hochfrequenz gut leitende) großflächige, nicht unterbrochene Massefläche kontaktiert wird.

* Die Länge der GND-Leitung vom Kondensator zum IC ist genau so wichtig wie die Länge der VCC-Leitung.

* Es sollten keramische Kondensatoren mit einer Kapazität von maximal 100 nF verwendet werden. Größere Kondensatoren, etwa 10 µF-Elkos, sind für diese Aufgabe nicht geeignet (und auch kein Dutzend µF-Keramikondensatoren), weil sie "zu langsam" sind. Ihre Impedanz ist bei hochfrequenten Spannungen zu groß – ein schneller, hochfrequenter Spannungsimpuls kann so nicht abgeleitet werden.

=== Quarz oder Quarzoszillator? ===

Die neueren AVRs haben einen internen [[Oszillator]], der im Auslieferungszustand über die entsprechenden Fuses eingeschaltet ist. In diesem Fall muss kein externer [[Quarze und AVR|Quarz]] mehr angeschlossen werden. Man kann in den [[AVR Fuses|Fuse-Bits]] aber einstellen, dass man einen externen Taktgenerator (''external clock'', z. B. Quarzoszillator) oder externen Quarz (''external crystal'') verwenden möchte.

Werden seriell Daten ohne Clockleitung (also ''asynchron'') übertragen, ist eine externe genauere Taktquelle meistens unverzichtbar. Zumindest sinnvoll sind sie bei UARTs (obwohl es auch ohne noch gehen mag). USB, CAN oder Ethernet funktionieren nicht ohne präzisen externen Takt. I2C/TWI oder SPI sind synchrone Übertragungsverfahren und brauchen keinen genauen Takt.

Dann, oder wenn der AVR keinen internen Takt hat, wird an die entsprechenden Pins des Controllers ein Quarz (''external crystal'', Bauelement mit zwei Pads) oder Quarzoszillator (''external clock'', Bauelement mit vier Pads) angeschlossen. Im Falle eines Quarzes werden die XTAL-Pins mit den beiden Anschlüssen des Quarzes und jeweils mit einem Kondensator (ca. 12 bis 22 pF) (vgl. Datenblatt ATMega 8) gegen Masse angeschlossen. Im Falle eines Quarzoszillators reicht es aus, den Taktausgang mit dem XTAL1-Pin zu verbinden, und den XTAL2-Pin unbeschaltet zu lassen. Die Fuses sind entsprechend einzustellen.

=== Ground-Anschlüsse ===

Bei ICs mit mehreren Masse-Anschlüssen (GND, ground) müssen immer alle Anschlüsse beschaltet werden. Siehe http://www.mikrocontroller.net/forum/read-1-107259.html

=== Eingänge ===

Taster müssen:

* entprellt werden ([[Entprellung]])

* einen [[AVR-GCC-Tutorial#Tasten_und_Schalter|Pullup-Widerstand]] besitzen, so sie ''active-low'' betrieben werden, d.h. wenn beim Tastendruck der Pin mit GND (Masse) verbunden wird (dies ist die übliche Anschaltung). Man kann einen externen Pull-Up Widerstand (typ. 10 kOhm) benutzen oder den internen aktivieren (DDR als Eingang also "0", PORT auf "1").

Will man einen Taster ''active-high'' betreiben, soll also bei Tastendruck eine "1" in PIN gelesen werden, ist ein externer Pull-Down-Widerstand (typ. 10 kOhm) gegen GND anzuschließen, denn interne Pull-Downs sind nicht verfügbar.

Symptome: Aufgrund des Prellens bekommt man bei einem Tastendruck statt eines Signals mehrere, und beim fehlenden Pullup fängt man sich Störungen (z. B. das 50 Hz-Netzbrummen) ein, da der Pin nicht auf einem "definierten Pegel" liegt, wenn der Taster nicht geschlossen ist. Soll z. B. bei einem Tastendruck eine LED angehen, dann leuchtet die LED durch das Netzbrummen plötzlich mit 50 Hz anstatt aus zu sein.

* active low: ein Anschluss des Tasters an den Port-Pin, den anderen Taster-Anschluss an GND; internen Pull-Up-Widerstand aktivieren oder externen Widerstand zwischen Port-Pin und VCC.

* active high: Taster zwischen Port-Pin und VCC; externen Widerstand zwischen Port-Pin und GND.

=== Ausgänge ===

Man sollte darauf achten, dass "kritische" Ausgänge, d.h. Ausgänge, über die nicht "nur" eine LED geschaltet wird, einen definierten Zustand haben, wenn der Portpin auf "Eingang" und damit hochohmig geschaltet ist. Dadurch wird sichergestellt, dass beim Einschalten nicht kurz ein Verbraucher geschaltet wird (z. B. "Zucken" eines Motors). Dies kann man bewerkstelligen, indem man extern Widerstände (auch hier Pull-Up bzw. Pull-Down genannt, typ. 10 kOhm) an den Ausgangs-Pins vorsieht, die den Ausgang auf den gewünschten Zustand ziehen.

=== Besonderheiten bei ATmega128 und seinen Derivaten im 64-Pin-Gehäuse===

[[Bild:isp.png|thumb|300px|right|ISP-Adapter]]
Der ATmega64 und der ATmega128 sowie alle vom ATMega128 abgeleiteten AVRs im 64-Pin-Gehäuse (ATMega641/1281/2561, AT90PWM2/3/2B/3B sowie AT90CAN32/64/128, Ausnahmen sind nur AT90USB64/128, die eine ganz andere Pinbelegung haben) haben besondere Fallstricke, über die man bei nicht ausreichendem Datenblattstudium leicht stolpert.

* Der erste betrifft den Anschluss der ISP-Signale (MISO, MOSI, SCK, RESET). Dieser erfolgt nicht wie bei den meisten anderen AVR-Controllern an den gleichnamigen Pins, sondern an PDI, PDO, SCK und RESET. Die Pinzuordnung ist:
:* MOSI → PE0 (Pin 2)
:* MISO → PE1 (Pin 3)
:* SCK → PB1 (Pin 11)
:* RESET → RESET (Pin 20)
: PEN (Pin 1) hat für normale ISP-Adapter keine Bedeutung und kann offen gelassen oder direkt mit Vcc verbunden werden. Die Benutzung der Pins PDI und PDO anstelle von MOSI und MISO gilt für praktisch alle ATmega128-Derivate im 64-Pin-TQFP-Gehäuse, darunter AT90CAN32/64/128 und ATmega641/1281/2561. Im Zweifelsfall im Datenblatt (Pin Configuration) nachsehen, ob PE0 und PE1 mit "PDI" bzw. "PDO" beschriftet sind.

* Die zweite kleine Gemeinheit betrifft die M103C-Fuse (ATmega103 Compatibility Mode, nur bei den ATmega-Typen, nicht beim AT90CAN32/64/128). Diese ist bei fabrikneuen Atmega64/128 gesetzt und sorgt dafür, dass sich diese wie ein Atmega103 verhalten.
** Dies hat zur Folge, dass ein für den ATmega64 oder ATmega128 geschriebenes Programm beim ersten RET abstürzt, da der SRAM an einer anderen Stelle endet als erwartet und somit der Prozessor keine gültige Rücksprungadresse vom Stack holen kann.
** Außerdem funktionieren einige IO-Pins an PORTC, PORTF und PORTG anders.
** Für weitere Infos bzgl. [[TWI]], [[UART]], [[Timer]], [[Bootloader]] und Kalibrierung des internen RC-Oszillators unbedingt das Datenblatt lesen.

=== Lötstellen ===

"Kalte", d. h. schlechte Lötstellen verraten sich durch ihre matte Oberfläche (bei bleihaltigem Lot). Beschädigte Lötstellen erkennt man oft an einem Riss, der sich kreisförmig um die Mitte des Lötpunktes herum gebildet hat. Solche Stellen verursachen oft erst bei mechanischer Beanspruchung Probleme.

Bei kleinen Abständen (SMD-Bauteile) müssen besonders Verbindungen zwischen benachbarten Lötungen kontrolliert werden.

Bei Lochrasterplatinen kann man mit einem spitzen Messer (Bastelmesser) die Zwischenräume von möglichen leitenden Verbindungen befreien.

== Software ==

=== Mainschleife vorhanden? ===

Insbesondere beim Testen von Interrupts kann es passieren, dass man keine eigentliche Programmschleife vorsieht, weil ja alles in den Interrupts passiert. Das führt dazu, dass der Controller nach Abarbeiten aller Befehle in <syntaxhighlight lang="c">int main(void) {}</syntaxhighlight> seine Arbeit einstellt und daher auch keine Interrupts mehr funktionieren. Demnach sollte bei rein Interrupt-basierten Programmen die Funktion mindestens so aussehen:
<syntaxhighlight lang="c">int main(void)
{
// hier Interrupts definieren
// und einschalten
while (1){}
}</syntaxhighlight>

=== Alle Interruptvektoren definiert? ===

Wenn man irgendwelche [[Interrupt]]vektoren verwendet, sollte man alle definieren, auch die nicht benutzten. Passiert es dann aufgrund eines Fehlers, dass ein Interrupt unbeabsichtigt ausgeführt wird, so führt der Controller dann eine definierte Aktion aus. Benutzt man eine Hochsprache wie C oder Basic, nimmt einem der Compiler diese Arbeit ab.

Außerdem sollte man immer im Datenblatt des Controllers nachsehen, wie die Interrupttabelle aufgebaut ist. Die kleinen AVRs verwenden ein RCALL zum Anspringen der Interrupts, welches 1 Wort lang ist. Die grossen AVRs mit mehr als 8 KiBi FLASH verwenden ein CALL, welches 2 Worte lang ist. Verwendet man nun den falschen Befehl, verschieben sich die Einsprungadressen und das Chaos ist perfekt.

In einem komplett interruptlosen Programm kann man auf die Interrupttabelle selbstverständlich verzichten (erkennbar daran, dass nirgendwo im Code Interrupts mittels Assembler-Befehl SEI eingeschaltet werden).

Oft hilft es einen Catch All Interruptvektor zu definieren um herauszufinden ob ein Fehler (z.B. ein Neubeginn des Programms) vorliegt.
<syntaxhighlight lang="c">#include <avr/interrupt.h>

ISR (BADISR_vect)
{
// Hier eine Fehlerausgabe definieren.
// Z.B. UART-Ausgabe oder ein PIN toggeln
}</syntaxhighlight>

Dann findet man solche Fehler recht schnell.

=== Alle Konfigurationsregister korrekt initialisiert? ===

Alle benötigten Konfigurationsregister (auch "I/O-Register" genannt) eines Mikrocontrollers müssen korrekt initialisiert werden. Bei Fehlfunktionen sollten diese Konfigurationen noch einmal mit dem Datenblatt abgeglichen werden.
Manchmal ist es auch sinnvoll, bestimmte Funktionen explizit abzuwählen. Ein Beispiel hierfür ist der [[Analog-Komparator]] des AVR: Schaltet man diesen ab, wenn man ihn nicht benötigt, kann man dadurch ein wenig Strom sparen.
Wenn man besonders "sauber" programmieren möchte, initialisiert man Konfigurationsregister immer, d.h. auch wenn sie nicht im Programm verwendet werden. Dies verhindert mögliche zufällige Fehlkonfigurationen.

=== Stackpointer initialisiert? (Nur in Assembler relevant) ===

Fehlerbeschreibung: ''Das Programm lief, bis ein "rcall" oder ein Interrupt eingefügt wurde. Danach ging plötzlich gar nichts mehr.''

Wahrscheinliche Ursache: Der Stack ist ein spezieller Bereich im RAM, der von Sprungbefehlen und Interruptaufrufen dazu verwendet wird, die Rücksprungadresse ins Hauptprogramm zu speichern. Da der Stack bei den AVRs nach "unten" wächst, d.h. in Richtung Anfang des RAMs, wird er üblicherweise ans Ende des RAMs gelegt. Der Stack muss vor der ersten Benutzung, am besten direkt am Anfang des Programms, initialisiert werden (sonst ist nach einem Sprung in ein Unterprogramm die Rücksprungadresse undefiniert und das Programm wird an einer unvorhersehbaren Stelle weiter ausgeführt, was in der Regel einen Absturz zur Folge hat). "Den Stack initialisieren" bedeutet, den Stackpointer auf den gewünschten "Startwert" zu setzen. Meistens wird dafür die letzte RAM-Adresse gewählt.

Die Initialisierung unterscheidet sich geringfügig je nach verwendetem AVR. Bei den alten AT90xxxx und den ATtinys ist sie mit zwei Zeilen erledigt:

<syntaxhighlight lang="avrasm">
ldi r16, RAMEND ;Die Adresse der letzten Stelle im RAM in r16 laden
out SPL, r16 ;Die Adresse in das Register SPL ausgeben
</syntaxhighlight>

Da die ATmegas mehr RAM haben, reicht das 8 bit-Register SPL nicht mehr, und es ist ein zweites (SPH) dazugekommen. Die Initialisierung des Stacks erfordert hier vier Zeilen:

<syntaxhighlight lang="avrasm">
ldi r16, LOW(RAMEND) ;Untere 8 bit des 16 bit-Wertes RAMEND laden
out SPL, r16
ldi r16, HIGH(RAMEND) ;Obere 8 bit laden
out SPH, r16
</syntaxhighlight>

=== 16bit-Register in richtiger Reihenfolge geladen/gelesen? (Nur in Assembler relevant) ===

Bei den 16-bit Registern (z. B. Timer1) genau die Hinweise im Kapitel "Accessing 16-bit Registers" beachten!

So muss z. B. das High-Byte VOR dem Low-Byte geschrieben werden, weil mit dem Schreiben des Low Byte das gesamte Register "übernommen" wird.
Beim Lesen muss zuerst das Low-Byte gelesen werden, dann das High-Byte.
Es wird dadurch garantiert, dass sich zwischen den beiden einzelnen Befehlen nicht noch das Register weiter verändert, z. B. beim 16bit Counter.
Möglich wird das durch ein "temporary Register", von dem es aber nur eines gibt - was beachtet werden muss, da zwischen diesen beiden einzelnen Lese-/Schreib-Befehlen kein Interrupt auftreten darf, der selber das temporary Rgegister benutzt.

In C oder Basic kümmert sich der Compiler um das Problem - man liest oder beschreibt dann einfach z. B. TCNT1 anstatt TCNT1H und TCNT1L einzeln.

=== Flag richtig gelöscht? ===

Ein beliebter Fehler ist, dass man überliest, dass gesetzte Flags (z. B. die Interrupt-Flags) durch beschreiben mit einer '1' und nicht mit einer '0' gelöscht werden!

Beispiel:
* das Flag ist zuerst '0'
* das Ereignis (z. B. Zählerüberlauf, also Bit TOV0 in TIFR) tritt auf und setzt das jeweilige Bit im Register auf '1'
* wir haben auf die '1' gewartet und wollen das Bit nun wieder löschen und müssen dafür eine '1' (eins!) in das Register schreiben, '''keine''' '0'. Trotzdem wird das Bit dadurch '0' z. B.:
<syntaxhighlight lang="c">
TIFR = (1<<TOV0);
</syntaxhighlight>

Das ganze ist kein Fehler, sondern hat seine guten Gründe.

Wenn Interrupts zugelassen sind (z. B. in TIMSK) und die Interruptroutine aufgerufen wird, werden diese Flags zumeist automatisch gelöscht.

Der UART-Empfangs-Interrupt (RXC in UCSRA) jedoch nicht! Der wird gelöscht durch Auslesen des Empfangsregisters (UDR). Hier liegt wiederum ein beliebter Stolperstein: Man prüft oft zuerst in der Interruptroutine die Fehlerflags (z. B. Parity) und macht dann manchmal den Fehler das empfangene Zeichen im Fehlerfall nicht auszulesen. Das führt dann zum Absturz (der IRQ wird immer wieder aufgerufen) - man muss also immer das UDR lesen auch wenn etwas Fehlerhaftes drinsteht.

Zusätzlich ist zu beachten, dass in C die Interrupt-Flags '''nicht''' mit einer Veroderung des Registers (z. B. TIFR |= (1 << TOV0)) gelöscht werden sollten, da bei dieser Operation alle anderen evtl. gesetzten Flags im betreffenden Register ebenfalls gelöscht werden. Es ist die Schreibweise von oben zu benutzen (also TIFR = (1 << TOV0))!

=== Alle Interrupt-Variablen als ''volatile'' bezeichnet? ===

Variablen können im C-Quelltext mit dem Schlüsselwort ''volatile'' ausgezeichnet werden: Der Ausdruck

<pre>volatile int i</pre>

versieht die Integervariable i mit dem Attribut ''volatile''. Dadurch wird der Compiler angewiesen, diese Variable nicht zu optimieren, sondern im Speicher abzulegen und zu beachten, dass sie von anderen Prozessen geändert werden kann. Normale Variablen können durch den Compiler auf Register reduziert werden, oder die Daten werden einmalig aus dem Speicher geladen und erst am Ende des Programmes wieder zurückgeschrieben. Das kann Probleme bereiten, wenn beispielsweise in einer [[Interrupt]]routine der Inhalt der Variablen verändert wird. Darum müssen alle globalen Variablen, die in einer ISR (''interrupt service routine'') geändert werden, als ''volatile'' gekennzeichnet werden.

=== Wo nötig Variablenzugriff atomar gestaltet? ===
Der Zugriff auf Variablen, die größer als 8 Bit sind und sowohl in der Hauptfunktion ("main") als auch in einer (oder mehrerer) ISR genutzt werden, muss [[atomar]] erfolgen. Eine Verletzung dieser Regel kann zu schwer nachvollziehbaren Problemen führen.

=== Programmierfrequenz passend? ===

Sollte ein Programmieren nicht möglich sein erst einmal die Programmiergeschwindigkeit bei AVR dude mit der Option
-B bitclock anpassen
wobei bitclock die Perioden dauer in Millisekunden (floating-point Zahl) ist. Normalerweise -B 1 für Controller mit >=4MHz daher ist bei der Erstprogrammierung ein höherer Wert zu versuchen.

== Serielle Verbindungen ==

=== [[I²C]]/[[TWI]] ===

Sind die Leitungen SCL und SDA mit einem Pullup-Widerstand ausgestattet? Die I²C-Bus-Leitungen SCL und SDA müssen über einen Pullup-Widerstand mit einem Wert von 4,7 kΩ bis 10 kΩ mit der Versorgungsspannung (+5 V) verbunden sein.

=== UART/USART ===

==== Übertragungsprobleme durch falschen oder ungenauen Takt ====

* Der interne [[Oszillator]] ist recht ungenau und nicht temperaturstabil. Daher kann die Umgebungstemperatur auch den [[UART|USART]]-Takt verändern. Für serielle, asynchrone Kommunikation per UART sollte man deshalb immer einen Quarz oder einen Oszillator verwenden, egal bei welcher Baudrate: 3% Fehler sind immer 3% Fehler, egal ob bei 1200 oder 9600 [[Baud]]. Falls doch der interne Oszillator verwendet wird: Wurde er für die richtige Frequenz und Betriebsspannung kalibriert?
* Nicht mit allen Quarzen kann man alle Baudraten genau genug erzeugen. Deswegen gibt es [[Baudratenquarz]]e wie z. B. 3,6864 MHz. Näheres steht im Datenblatt.
* Geschieht die Konfiguration des U(S)ART automatisch durch die Programmiersprache (z. B. in [[Bascom AVR|BASCOM]], [[C]]), dann muss dort der Takt ''genau'' angegeben werden. Setzt man z. B. einen 3,6864 MHz-Quarz ein, darf man dort nicht einfach "4 MHz" angeben, weil dann die Abweichung mit ca. 8% zu hoch wäre. Damit funktioniert die Übertragung nicht mehr.
* Im AVR-Studio kann man die Taktfrequenz sowohl über ein <code>#define F_CPU</code> im Quelltext als auch über das Optionsmenu oder das selbsterstellte Makefile einstellen. Es darf nur ''eine'' Variante verwendet werden!
* Wenn ein externer Oszillator oder Quarz angeschlossen ist: Sind die [[AVR Fuses | Fuses]] des Controllers so gesetzt, dass er auch verwendet wird?
* Ist die Fuse CLKDIV ''nicht'' programmiert?
* Es taucht auch des öfteren das Missverständnis auf, dass man nur F_CPU verändern muss, um den µC mit einem anderen Takt laufen zu lassen. Dem ist nicht so. Der µC-Takt wird durch die Fuses bzw. den eventuell angeschlossenen Quarz oder Quarzoszillator bestimmt. F_CPU dient nur dazu, die dadurch festgelegte Frequenz im C-Programm zur Verfügung zu haben. F_CPU ist nur eine Information, mit der man bei der Programmierung arbeiten kann. Aber ein anderer F_CPU-Wert führt nicht dazu, dass der µC dann magisch auf diese Frequenz umgestellt wird.
* Um zu prüfen, ob der externe Quarz auch wirklich verwendet wird, kann man mittels _delay_ms() testweise eine LED im Sekundentakt blinken lassen. Den Unterschied zwischen Quarz und internem RC-Oszillator kann man bei größeren Frequenzunterschieden leicht sehen. Ebenso sieht man, ob versehentlich die CLKDIV Fuse gesetzt ist: die Blinkfrequenz ist dann achtmal langsamer. Allerdings muss man auch hier aufpassen. Siehe [[AVR-GCC-Tutorial#Warteschleifen (delay.h)|AVR-GCC-Tutorial: Warteschleifen]].
* Erscheinen im Terminalprogramm kryptische Zeichen anstatt ordentlichen Buchstaben (z. B. ü statt A), liegt das zu 99,9% an einer falsch eingestellten/erzeugten Baudrate im Mikrocontroller. Meistens wiederum liegt dies daran, dass der µC nicht mit der vermeintlichen Taktrate läuft und daher die Baudratenparameter falsch berechnet werden.
* URSEL-Bit in UCSRC: Bei der Initialisierung der UART beachtet, wenn das für den verwendeten AVR notwendig ist, siehe [[AVR-GCC-Tutorial/Der_UART#Die_UART-Register|AVR-GCC-Tutorial/Der UART: Die UART-Register]].
* In den Tutorials für [[AVR-Tutorial: UART |Assembler]] und [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Der_UART GCC] wird die Nutzung recht gut erklärt und mit Beispielen erläutert.

===== Testprogramm =====

Im folgenden Programm muss angepasst werden:
*Die vermeintliche Taktfrequenz F_CPU
*der Port und der Pin, an dem eine LED angeschlossen ist.

Wird das Programm laufen gelassen, muss die LED 1 Sekunde ein/1 Sekunde aus sein. Stimmen die Zeiten nicht, ist das ein deutlicher Hinweis darauf, dass die tatsächlich vom µC verwendete Taktfrequenz nicht mit der in F_CPU angegebenen übereinstimmt. Das Programm muss mit aktivierter Optimierung <code>-Os</code> compiliert werden.
<syntaxhighlight lang="c">
// Testprogramm für CPU Takt
// Hier die vermeintliche Taktrate des µC eintragen
// Im Beispiel hier: 1MHz

#define F_CPU 1000000

#include <avr/io.h>
#include <util/delay.h>

// Hier die tatsächlich verwendeten Parameter angeben

#define LED_PORT PORTB
#define LED_DDR DDRB
#define LED_PIN PB0

int main()
{
LED_DDR |= 1 << LED_PIN;

while (1)
{
LED_PORT ^= 1 << LED_PIN;
_delay_ms(1000);
}

return 0;
}
</syntaxhighlight>

==== Sonstige Fehlerquellen bei UART/USART ====

* Funktioniert die Datenübertragung zum PC nur solange der Programmieradapter eingesteckt ist, deutet dies auf ein Problem mit der Masse hin (z. B. GND-Anschluss am RS232-Stecker nicht belegt oder dergleichen).
* Der Pegelwandler/Inverter (z. B. MAX232) muss mit Kondensatoren für die internen Ladungspumpen beschaltet werden. Beim MAX232 sind dies mindestens vier Kondensatoren ≥ 1 µF (Polung beachten!), beim MAX202, MAX232A und MAX3232 vier Kondensatoren ≥ 100 nF. Hinzu kommt der obligatorische Abblockkondensator von 100 nF keramisch zwischen VCC und GND des ICs. Das jeweilige Datenblatt gibt Auskunft über die Beschaltung bei "typischer Anwendung".
* TX/RX vertauscht? Modem- oder Nullmodemkabel?
* Bei Kommunikation mit PC: Ist die serielle Schnittstelle richtig konfiguriert? Nicht nur Baudrate, Stopp- und Parity-Bits, sondern auch Handshakeverhalten muss stimmen (kein Hardwarehandshake bei ausschließlicher Verwendung der Pins RX/TX).
* Wird das Signal eventuell durch zusätzliche Chips invertiert? (EEPROM von FT232 falsch Programmiert)
* Die Hardware und Verkabelung kann man schnell prüfen, indem man den Pin R1OUT bzw. R2OUT mit T1IN bzw. T2IN am MAX232 miteinander verbindet (je nachdem welches Pinpaar verwendet wird). Dann sollte man auf dem PC ein Terminalprogramm wie Hyperterminal starten und nach dem Eingeben von Zeichen diese sofort angezeigt bekommen, egal mit welcher Baudrate. Lediglich die Flusssteuerung muss auf "Kein" eingestellt werden.
* Man muss aber beachten, dass T1IN bzw. T2IN für diesen Test ''nicht'' mit dem Mikrocontroller verbunden sein darf, weil sonst zwei Ausgänge miteinander verbunden sind, siehe [[Ausgangsstufen Logik-ICs]]. Wenn der µC gesockelt ist, kann man ihn dafür einfach aus dem Sockel nehmen und die RX/TX Pins direkt im µC-Sockel mit einem Stück Draht verbinden.
* Ist der UART TXD-Pin als Output konfiguriert?
* Liegt Spannung an Pin 15 und 16 an? (Falsche Zeichen kommen an, aber in der richtigen Reihenfolge. Beim Test durch Kurzschluss von T1IN und R1OUT kommt nichts an)

=== SPI (Hardware) ===
* Master Mode: SS Pin als Ausgang oder auf High gelegt? (siehe hier: [http://www.holger-klabunde.de/avr/avrhelp.htm] )
* SPI zu schnell
* Hängen andere SPI-Devices am Bus, die undefiniertes CS haben?
* Sind die DDR-Register der SPI-Ports richtig gesetzt?

== Analog-Digital-Wandler ==

* Sind die Pullup-Widerstände deaktiviert? (im allgemeinen)
* (im speziellen) Bei einige Controllern liegt der JTAG mit auf den ADC-Pins. Die betroffenen ADC-Kanäle werden erst richtig funktionieren, wenn der JTAG deaktiviert ist. Das geht per Fuse oder - wenn man an die Fuses nicht mehr herankommen sollte, weil man mit einem Bootloader arbeitet - auch per Software:
<syntaxhighlight lang="c">
/* File jtag_utils.h *
* Author N.G. (newgeneration) */
#ifndef JTAG_UTILS_H_
#define JTAG_UTILS_H_

#include <avr/io.h>
#include <util/atomic.h>

// Check for the JTAG-disable-Bit (JTD)
#if defined(JTD)

// Es gibt (mindestens) zwei Moeglichkeiten, in welchem Register
// das JTD-Bit steckt: bei aelteren AVRS im MCUCSR (MCU Control
// and Status Register), bei neueren im MCUCR (MCU Control Register)
#ifdef MCUCSR
#define JTD_REGISTER MCUCSR
#else
#define JTD_REGISTER MCUCR
#endif

static inline void jtag_disable() __attribute__((always_inline));
static inline void jtag_enable() __attribute__((always_inline));

static inline void jtag_disable()
{
// Auszug aus dem Datenblatt:
/* In order to avoid unintentional disabling or enabling *
* of the JTAG interface, a timed sequence must be followed *
* when changing this bit: The application software must *
* write this bit to the desired value twice within four *
* cycles to change its value. */

// Damit das Bit auch wirklich innerhalb von 4 Zyklen zwei mal
// gesetzt wird, werden die Interrupts verboten und es wird
// inline-assembler verwendet. Damit ist man unabhängig von der
// Optimierung des Compilers.
ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{
uint8_t tmp;
__asm__ __volatile__ (
"in %[tmp], %[reg] \n\t"
"ori %[tmp], %[jtd] \n\t"
"out %[reg], %[tmp] \n\t"
"out %[reg], %[tmp] \n\t" :
[tmp] "=&d" (tmp) :
[reg] "I" (_SFR_IO_ADDR(JTD_REGISTER)), [jtd] "M" (1 << JTD)
);
}
}

static inline void jtag_enable()
{
ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{
uint8_t tmp;
__asm__ __volatile__ (
"in %[tmp], %[reg] \n\t"
"andi %[tmp], %[jtd] \n\t"
"out %[reg], %[tmp] \n\t"
"out %[reg], %[tmp] \n\t" :
[tmp] "=&d" (tmp) :
[reg] "I" (_SFR_IO_ADDR(JTD_REGISTER)), [jtd] "M" ((uint8_t)~(1 << JTD))
);
}
}

#undef JTD_REGISTER

#else /* !defined(JTD) */
#warning "Has this device a JTAG-Interface?"
#error "The device does not support JTAG disabling in software!"
#endif /* defined(JTD) */

#endif /* defined(JTAG_UTILS_H_) */
</syntaxhighlight>

== Weblinks ==
* [http://www.atmel.com/Images/Atmel-2521-AVR-Hardware-Design-Considerations_ApplicationNote_AVR042.pdf Application Note AVR042: AVR Hardware Design Considerations]
* [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Application Note AVR040: EMC Design Considerations]
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren]

C

2016-12-27T11:48:32Z

Newgeneration: C-Standards hinzugefügt

C ist eine universelle Programmiersprache in der auch hardwarenah programmiert werden kann, ursprünglich als eine Art maschinenunabhängiger Makroassembler gedacht. C ist neben Assembler die bei Mikrocontrollern am häufigsten verwendete Programmiersprache, wird aber auch außerhalb dieses Feldes häufig eingesetzt, etwa in der Anwendungs- und System-Programmierung (der Linux-Kernel ist in C geschrieben).

Die Entstehung von C hängt sehr mit der Entwicklung von [[Unix]] zusammen. Dennis Ritchie arbeitete Anfang der 70er bei Bell Laboratories (heute AT&T) an diesem neuen Betriebssystem. Ursprünglich wurde in Assembler programmiert, aber später wurde das gesamte System neu in der ersten Version von der Programmiersprache C implementiert, weil C Hardware-unabhängig(er als Assembler) ist und ein Compiler fast auf jedem System existiert oder leicht portiert werden kann.

== Sprachstandards ==

Vor 1989 gab es keine standardisierte Sprache C, nur den de-facto Standard des K&R Buches "The C Programming Language". Dieser "Standard" unterschied sich noch sehr von der aktuellen Sprache:
<syntaxhighlight lang="c">
/* K%R C */

/* Argumente wurden anders definiert, es gibt keine Prototypen */
print(str)
char *str;
{
printf("%s\n", str);
}

/* es wird implizit int angenommen, void gibt es nicht */
main()
{
print("Hallo Welt!");
return 0;
}

</syntaxhighlight>

1989 wurde der erste C-Standard verabschiedet, der unter den Namen ANSI C oder C89 lief. Diese Norm galt jedoch nur in den USA, deshalb wurde ein Jahr später C90 von der ISO verabschiedet. C89 und C90 beziehen sich aber auf die selbe Version von C.

Abgesehen von kleinen Verbesserungen vor allem bei den Character Sets im Jahre 1995 bleib C auch gleich.

1999 wurde ein neuer Standard verabschiedet, unter dem Namen C99. Dieser fügte viele neue Dinge hinzu, die oftmals schon von Compilern als Erweiterung bereitgestellt wurden, zum Beispiel inline-Functionen, größere Datentypen, etc.
C99 ist fast vollständig kompatibel zu C90, allerdings etwas strenger bei der Auslegung der Sprachelemente.

Als letztes gibt es den aktuellsten Standard C11, der hauptsächlich die C-Library erweiterte und Multithreading, sowie Atomic-Typen hinzufügte.

Streng genommen verlieren mit jeder neuen Version des Standards alle vorherigen Version ihre Gültigkeit. Soweit die Theorie, in der Praxis sieht es allerdings so aus, dass viele Compiler nur C99 unterstützen, wenn überhaupt (Microsofts offizieller C-Compiler ist bekannt dafür etwas aus der Reihe zu tanzen).

== C-Tutorials/Einführungen ==
C ist zwar universell, kann vom Supercomputer bis zum kleinsten 8bit-Controller eingesetzt werden, aber trotzdem unterscheidet sich die Arte der Programmierung.

'''Achtung:''' Tutorials, vor allem die in deutscher Sprache, sollten teilweise Hinterfragt werden. Oftmals schreibt der Autor einfach nur seine (zum Teil begrenzte) Sicht der Dinge. Es kann nicht schaden, mehr als ein Tutorial zu lesen und bei Diskrepanzen den C-Standard zu Rate zu ziehen.

=== PC-Programmierung ===
* [https://www.ime.usp.br/~pf/Kernighan-Ritchie/C-Programming-Ebook.pdf The C Programming Language] (Orginal K&R für ANSI C) als PDF
* [http://www.c-howto.de Einführung in C] von E. Fischer
* [http://www.schellong.de/c.htm C-Tutorial] von H. Schellong
* [http://www.c-plusplus.de/c.htm verschiedene Tutorials] zum Download
* [http://www.manderc.com/ Mander]: Online-Referenc für C und C++
* [http://www.tutorials.at/ tutorials.at] auch für Pascal, Basic
* [http://suparum.rz.uni-mannheim.de/manuals/c/cde.htm C-Tutorial von C. Wirth]
* [http://www.strath.ac.uk/IT/Docs/Ccourse/ C programming] by S. Holmes
* [http://www.haw-hamburg.de/rzbt/dankert/c_tutor.html/ C und C++ für UNIX, DOS und MS-Windows] von J. Dankert, zum download
* [http://openbook.galileocomputing.de/c_von_a_bis_z/ online Version des Buchs "C von A bis Z"] von J. Wolf
* [http://home.fhtw-berlin.de/~junghans/cref/ C-Referenz] von M. Leslie/G.Junghanns
* [http://info.baeumle.com/ansic.html "Einiges zu Ansi-C"] von B. Baeumle-Courth
* [http://www2.informatik.uni-wuerzburg.de/dclc-faq/ FAQ der Newsgroup de.comp.lang.c]
* [http://www.coding-guidelines.com/cbook/cbook1_0a.pdf Derek M. Jones: The New C Standard] e-Buch, engl., >1600 Seiten, mehr als "nur" Einführung/Tutorial

=== Mikrocontroller-spezifisch ===
* [[AVR-GCC-Tutorial]]
* [http://roboternetz.de/download/c_tutorial.zip Download umfangreiches C-Tutorial mit Beispielen für RN-Control und andere AVR-Boards im ZIP-Archiv] von A.Seeger
* [http://playground.boxtec.ch/doku.php/tutorials/start playground.boxtec.ch] verschiedene Tutorials für AVR mit Hardware und I2C Bus (siehe playground / tutorial)

== Weitere Links ==
* [http://en.cppreference.com/w/c C Referenz] auf cppreferece.com
* [http://www.crasseux.com/books/ctutorial/Precedence-of-operators.html#Precedence%20of%20operators Liste aller Operatoren und ihrer Prioritäten]

[[Category:Programmiersprachen]]
[[Category:C| ]]

C

2016-12-27T11:26:39Z

Newgeneration: Entstehung hinzugefügt, Links geordnet

AVR-GCC

2016-12-25T16:22:30Z

Newgeneration: /* Selbst bauen */

avr-gcc ist ein freier [[C]]-Cross-[[Compiler]] für [[AVR]]-[[Mikrocontroller]].

avr-gcc kann von der Leistungsfähigkeit kommerzieller [[Compiler]] gut mithalten. Sogar C++-Programme sind möglich; in der aktuellen Fassung wird C++ jedoch nur eingeschränkt unterstützt (Stand 3/2012).

== Bestandteile ==

Die Toolchain (Werkzeugsammlung) besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen. Weit verbreitet ist die Verwendung von make zur Steuerung, siehe [[AVR-GCC-Tutorial/Exkurs Makefiles|AVR-GCC-Tutorial: Exkurs Makefiles]].

Die Bestandteile im einzelnen:
* Binutils: Assembler, Linker und weitere Hilfsprogramme.
* GCC: Der eigentliche C(++)-Compiler.
* AVR-Libc: Die C-Standardbibliothek mit AVR-spezifischen Headerdateien und Funktionen.
* [[AVRDUDE]]: universelle AVR-Programmiersoftware, kein eigentlicher Teil der Toolchain, aber oft verwendet

== Installation ==

=== Linux/Unix ===

Atmel bietet die [http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an.

Wenn keine aktuelle avr-gcc-Version als Paket (Paketname ist, zumindest bei Debian, gcc-avr) für die verwendete Distribution zur Verfügung steht, dann können sich [[Unix]]/[[Linux]]-Nutzer den Sourcecode herunterladen und selbst kompilieren, dazu gibt es Schritt-für-Schritt-Anleitungen<ref>[http://www.nongnu.org/avr-libc/user-manual/install_tools.html AVR-Libc: Building and Installing under Linux, FreeBSD, and Others]</ref><ref>[http://www.roboternetz.de/wissen/index.php/Avr-gcc_und_avrdude_installieren www.roboternetz.de: avr-gcc und avrdude installieren]</ref>.

Das [http://www.femtoos.org FemtoOS]-Paket beinhaltet Scripte zum automatischen Herunterladen und Bauen einer avr-gcc Version 4.3.3.

Empfehlenswert ist auch [http://cdk4avr.sf.net CDK4AVR], das die entsprechenden Tools als einfach installierbare Linux-Pakete bereitstellt. Leider ist das Projekt schon etwas älter, im Forum findet sich ein [http://www.mikrocontroller.net/topic/130972 Beitrag], aktuellere Sourcen mit den entsprechenden Patches zu versehen und zu kompilieren. Patches zu den Binutils und GCC-Sourcen sind unumgänglich, da die offiziellen Sourcen aufgrund des Umfangs an Prozessortargets den aktuellsten Entwicklungen hinterherhinken und damit bereits bekannte Fehler eventuell noch nicht behoben sind. Weitere Tipps zur AVR-Programmierung unter Linux stehen im Artikel [[AVR und Linux]].

=== Mac OS X ===
Die beste fertige Toolchain ist das [http://www.obdev.at/crosspack/ Crosspack]. Dieses enthält auch die AVR-Libc, avrdude und avarice. Leider gab es bei Mac OS 10.5.6 eine tiefgreifende Änderung beim fork()-Systemcall, der bewirkt, dass avarice mit JTAGICE mkII und Dragon nicht funktioniert. Geräte mit Serial-USB-Konvertern (AVRISP clones etc) funktionieren dagegen problemlos.

Wer die Toolchain von Hand bauen möchte kann das natürlich auch tun, dazu einfach den unter "Linux/Unix" verlinkten Anleitungen folgen. Unter [[Mac OS X]] muss man dazu zuerst die [http://developer.apple.com/Tools/ Apple Developer Tools] installieren.

Teile der Toolchain (AVR-Libc und avrdude) kann folgendermaßen installieren:

==== Mit MacPorts ====
Wenn man [http://www.macports.org/ MacPorts] benutzt kann man folgendes in das Terminal eingeben, um den Toolchain zu installieren:

sudo port install avr-libc

Das Programmiertool avrdude bekommt man genauso:

sudo port install avrdude

==== Mit Hombrew ====
Mit dem neueren Tool [http://brew.sh Homebrew] funktioniert das folgendermaßen:

avrdude kann sofort installiert werden:

brew install avrdude

Für den restlichen Toolchain muss man erst ein 'Tap' hinzufügen:

brew tap larsimmisch/homebrew-avr

und kann dann den eigentlichen Toolchain installieren:

brew install avr-libc

Weblinks:

* [http://tinkerlog.com/2007/09/29/programming-avr-with-a-macbook/ Programming AVR with a MacBook] (engl.)
* [http://www.ladyada.net/library/avrdevtut/setup-mac.html AVR Tutorial from Lady Ada] (engl.)
* [http://www.obdev.at/crosspack/ Crosspack]
* [http://www.digithink.com/OSX-AVR OSX-AVR (nicht mehr aktuell)]
* [http://www.definefalsetrue.com/index.php/Mac-OS-X/bootfeedx.html BootFeedX Bootloaderfrontend]

=== Windows ===

Man kann sich auch für Windows den GCC selbst bauen oder man sucht von anderen erstellte Binaries.

Atmel bietet die [http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an. Allerdings ohne "make".

Der alte Klassiker [[WinAVR]] wird seit 2010 nicht mehr gepflegt und funktioniert
ab Windows 8 nur noch eingeschränkt.

Die Firma SysProgs bietet aktuelle Versionen der [http://gnutoolchains.com GNU Toolchain]
einschließlich "make" für viele Systemarchitekturen zum Download an.

==== Selbst bauen ====

Zuerst sei einmal die offizielle (englische) Anleitung genannt: [http://www.nongnu.org/avr-libc/user-manual/install_tools.html Building and Installing avr-gcc]

Das hier ist die etwas ausführlichere Beschreibung, die mir Johann L. gegeben hat, damit ich meinen Compiler erstellen konnte. Der Post dazu findet sich [https://www.mikrocontroller.net/topic/384825?goto=4394391#4394606 hier].

Zuerst einmal braucht man am besten ein Linux, zum Beispiel ein aktuelles Ubuntu. dort müssen diverse Programme wie gcc, autoconf, subversion usw. installiert sein. Wenn etwas fehlt meckert configure, das einfach aufmerksam lesen und dann die Programme nachinstallieren. Danach erneut configure aufrufen.
Um die Toolchain für Windows zu bauen brauchen wir noch mingw32 (aktueller Name in den meisten Paketquellen: mingw32-w64-gcc oder gcc-w64-mingw32). Eventuell findet sich das in den Paketquellen eurer Distribution, sonst kann ich auf [http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/ diese Seite] verweisen.

===== Vorbereitungen =====
Wie schon gesagt brauchen wir ein Linux, zum Beispiel in einer VM. Ein minimales Linux-Hintergrundwissen wären auch gut, aber es geht notfalls (Google & co. sind die Freunde) auch ohne.
'''Achtung:''' Auf diesem Linux darf kein avr-gcc und keine avr-libc vorhanden sein!
Dazu brauchen wir die folgende Software:
* GNU Binutils: [https://www.sourceware.org/binutils/ Download], am besten die neueste Version (runter scrollen, aktuell ist 2.27)
* GCC Sourcen: [https://gcc.gnu.org/ Download], diese sollten aus dem svn kommen (svn co svn://gcc.gnu.org/svn/gcc/branches/''branchname'' gcc ,mit ''branchname'' gcc-''version''-branch, aktuell ist gcc-6-branch) oder aus dem aktuellen ''trunk'' (svn co svn://gcc.gnu.org/svn/gcc/trunk).
* Die AVR-libc: [http://download.savannah.gnu.org/releases/avr-libc/ Download]. ''Achtung:'' Ab gcc-Version 5 muss mindestens eine avr-libc-Version >= 2.0.0 verwendet werden. Ältere GCCs brauchen natürlich auch eine avr-libc vor dieser Version.

Alles herunterladen und entpacken.

Zu den Downloads kommen dann noch 2 Umgebungsvariablen:
<syntaxhighlight lang="bash">
$ PREFIX=$HOME/local/avr
$ export PREFIX
$ PATH=$PATH:$PREFIX/bin
$ export PATH
</syntaxhighlight>
Damit legt ihr das Installationsverzeichnis fest und fügt auch gleich das Verzeichnis für die ausführbaren Dateien zum Pfad hinzu.

Im Folgenden gehe ich von diesem Ordner-Layout aus:
<pre>
$HOME
|
+ BuildToolchain
|
+ Downloads
| |
| + binutils
| + gcc
| + avr-libc
|
+ buildLinux
| |
| + binutils
| + gcc
| + avr-libc
|
+ buildWindows
|
+ binutils
+ gcc
</pre>

===== Erstellen der Binutils =====
Wechselt in das Verzeichnis BuildToolchain/buildLinux/binutils.
Von dort aus werden wir die binutils konfigurieren und erstellen.

'''Achtung:''' man darf weder GCC noch die Binutils in einem Verzeichnis innerhalb des Quellordners der Downloads konfigurieren, sonst kommen wirre Fehler. Wer sich an die Anleitung hält kann diesen Fehler (fast) nicht machen.

Also, wir sind soweit. Jetzt geht es ans Konfigurieren der binutils und danach ans kompilieren, aber das ist ganz leicht:
<syntaxhighlight lang="bash">
$ ../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls
</syntaxhighlight>
Wenn configure fehlende Programme meldet: nachinstallieren und erneut versuchen.
<syntaxhighlight lang="bash">
$ make
$ make install
</syntaxhighlight>

Damit sind die binutils für Linux fertig. Ihr könnt nachkontrollieren, ob die binutils da sind: Im Ordner $PREFIX/bin sollten sich die Dateien befinden, darunter avr-objcopy, avr-as, avr-size, etc.

===== Erstellen vom GCC =====
Als erstes muss sich der GCC noch ein paar zusätzliche Dateien herunterladen, das geschieht automatisch mit dem Befehl (ausgeführt in BuildToolchain/Downloads/gcc):
<syntaxhighlight lang="bash">
./contrib/download_prerequisites
</syntaxhighlight>
Wechselt ins Verzeichnis BuildToolchain/buildLinux/gcc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../Downloads/gcc/configure --prefix=$PREFIX --target=avr \
--enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2
$ make
$ make install
</syntaxhighlight>

===== Erstellen der avr-libc =====
Als erstes muss die avr-libs zum konfigurieren bereit gemacht werden:
Im Verzeichnis BuildToolchain/Downloads/avr-libc die Datei bootstrap ausführen
<syntaxhighlight lang="bash">
./bootstrap
</syntaxhighlight>
Danach wechselt ihr ins Verzeichnis BuildToolchain/buildLinux/avr-libc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../Downloads/avr-libc/configure --prefix=$PREFIX --build=`./config.guess` --host=avr
$ make
$ make install
</syntaxhighlight>

===== Testen unter Linux =====
So, jetzt seit ihr schon bei der Hälfte: Der Compiler läuft schon unter Linux!
Das testet ihr am besten schon mit ein paar einfachen LED-blink-Programmen, damit auch sichergestellt ist, dass bis hierhin alles geklappt hat.
Das einfachste und wichtigste Kommando dürfte sein
<syntaxhighlight lang="bash">
$ avr-gcc --version
</syntaxhighlight>
Dort sollte die Versionsnummer der GCC stehen. Wenn eine ältere Nummer dasteht, hab ihr entweder einen alten Download bemüht, oder eine andere Version vom avr-gcc war noch installiert.
Wenn der Fehler kommt, dass das Programm nicht gefunden werden kann, dann befindet sich avr-gcc nicht im PATH, das bedeutet ihr habt die Umgebungsvariablen nicht richtig gesetzt (siehe oben).

===== Bau für Windows =====
Ihr müsst keine neuen Dateien runter laden, lediglich die Programme nochmal etwas anders konfigurieren.
Die Schritte davor '''müssen''' jedoch ausgeführt werden!

Wechselt ins Verzeichnis BuildToolchain/buildWindows/binutils und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../Download/binutils/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
--host=plattform-w64-mingw32 --build=plattform-linux-gnu
$ make
$ make install
</syntaxhighlight>
Wobei ''plattform'' euer Ziel-System ist, also entweder i686 oder x86_64, je nach dem, was ihr für ein mingw installiert habt und ob ihr den Compiler für 32bit (i686) oder 64bit (x86_64) baut.

Wechselt ins Verzeichnis BuildToolchain/buildWindows/gcc und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../Downloads/gcc/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
--host=plattform-w64-mingw32 --build=plattform-linux-gnu --enable-languages=c,c++,lto --with-gnu-as \
--with-gnu-ld --disable-shared --with-dwarf2
$ make
$ make install
</syntaxhighlight>

Wechselt ins Verzeichnis BuildToolchain/buildLinux/avr-libc und führt den folgenden Befehl aus:
<syntaxhighlight lang="bash">
$ make install prefix=$HOME/local/avr4win
</syntaxhighlight>

Eigentlich ist der Compiler auch "schon" fertig. Aber in den Binaries sind noch die gesamten Symbole enthalten, was die .exe-Dateien aufbläht. Um diese los zu werden, kann man einfach noch diesen Befehl ausführen:
<syntaxhighlight lang="bash">
$ find . -name '*.exe' -exec plattform-w64-mingw32-strip {} ';'
</syntaxhighlight>

Damit sollten ihr im Ordner $HOME/local/avr4win die gesamte Toolchain haben. Diesen Ordner müsst ihr nur noch auf euren Windows-PC kopieren.
Für das klassische WinAVR fehlt noch Programmers Notepad, sowie die Utility-Programme, vor allem avrdude und make. Diese kann man entweder seperat downloaden oder aus einer WinAVR-Installation kopieren. Die Versionen davon spielen keine Rolle.

== Entwicklungsumgebungen ==

Win32:
* [[AVR-Studio]]: ab Version 4.12 mit WinAVR-Unterstützung, integrierter Simulator, Debugger, rudimentäre Projektverwaltung
* Programmers-Notepad: wird bei [[WinAVR]] mitgeliefert, ein guter Editor mit einer rudimentären Projektverwaltung
* [http://www.myavr.info/download/benutzerhandbuch_sisy_avr.pdf SiSy-AVR]: ein CASE-Tool mit WinAVR-Unterstützung, das eine Entwicklungsumgebung bereitstellt.

Plattformunabhängig:
* [http://www.eclipse.org/ Eclipse] mit CDT und dem [http://avr-eclipse.sourceforge.net/index.html AVR Eclipse Plugin]
* [[Code::Blocks]]: vielseitige, freie Entwicklungsumgebung für Windows und Linux
* [http://www.netbeans.org/ Netbeans] in der C++ - Version mit [[WinAVR]] oder [[avr-gcc]] als Toolchain

Linux:
*[http://sourceforge.net/projects/kontrollerlab/?_test=b KontrollerLab] ist eine freie Entwicklungsumgebung für AVR momentan aber noch im Beta-stadium.

== Bibliotheken / Libraries ==

Die [http://www.nongnu.org/avr-libc/ AVR-Libc] ist die gebräuchliche "Laufzeitbibliothek" zum avr-gcc C-Compiler, welche den Zugriff auf die AVR-Hardware erheblich erleichtert. Die offizielle Dokumentation zur avr-libc mit vielen Hinweisen auch zum Compiler avr-gcc und verschiedener Tools (z. B. [[AVRDUDE]]) findet man [http://www.nongnu.org/avr-libc/user-manual/index.html hier].

Auch die [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon AVRlib] enthält nützlichen Code z. B. für UART, LCD,.... Bei der Procyon AVRlib ist die Lizenz zu beachten (in Kurzform: man muss dritten auf Verlangen den gesamten Quellcode der Firmware zur Verfügung stellen, falls Teile der Procyon Bibliothek genutzt werden).

Zum Zugriff auf interne Funktionen oder externe Peripherie existieren einige fertige Komponenten. Z.B. "Projects"-Bereich von [http://www.avrfreaks.net/ avrfreaks.net] (Anmeldung erforderlich (kostenlos)).

Die Erstellung eigener Bibliotheken ist im Artikel [[Libraries]] erklärt.

== Tipps & Tricks ==

Eine Liste mit einigen Hinweisen:

* 07.10.11 → es kann Probleme mit der aktuellen Eclipse-Version (Indigo) und WinAVR geben. Falls ihr Indigo installiert habt und Eclipse die Definitionen wie z.B. DDRA nicht kennt, jedoch kompillieren kann, dann müsst ihr auf die Version Helios SR2 wechseln. Danach läuft alles wie gehabt!

* Keine "antiken" Versionen verwenden. Für MS-Windows-Nutzer: aktuelles WinAVR installieren. Für Linux/Unix-Nutzer: letzte stabile Version selbst kompilieren oder aus "Distribution-Packages" installieren (z. B. [http://cdk4avr.sourceforge.net/ cdk4avr]).

* Bei Problemen zuerst in die [http://www.nongnu.org/avr-libc/user-manual/index.html Anleitung] der avr-libc schauen. Insbesondere die FAQ lesen.

* Sicherstellen, dass der MCU-Parameter (zum Compiler/Linker, meist im Makefile defniert) mit dem Zielprozessor übereinstimmt.

* [[AVR-GCC-Tutorial]] in diesem Wiki lesen.

* Im Zweifel nicht INTERRUPT(...) sondern SIGNAL(...) nutzen. In neueren Versionen der avr-libc wurde "ISR" als Ersatz für SIGNAL eingeführt und sollte genutzt werden (SIGNAL und INTERRUPT werden langfristig entfallen). Darauf achten, dass die Vektor- bzw. Signal-Namen ("Parameter") zu ISR bzw. SIGNAL (und INTERRUPT wenn denn unbedingt erforderlich) richtig geschrieben sind. Die Namen sind in der in der entsprechenden Header-Datei (ioxxx.h) für den Controller und der avr-libc-Dokumenation aufgelistet. Im Zweifel den erzeugten Interrupt-Vektor im Assembler-Listing prüfen, es darf '''kein''' SIG_''xxx'' oder xxx_vect mehr zu sehen sein, sondern _vector_''N'' (wobei ''N'' eine Zahl ist). Neuere Versionen der avr-gcc zeigen eine Warnung, falls etwas falsch geschrieben wurde, ältere Versionen nicht.

* Zugriff auf Daten(-Tabellen) im Programmspeicher (Flash) erfolgt über Program-Space-Funktionen (pgm_read*). Lediglich die Definition einer Variablen/eines Feldes mit dem PROGMEM Attribut zu versehen, reicht (im Gegensatz zu Codevision, IAR, Imagecraft) nicht aus.

* Nicht alle AVRs werden vollständig von der avr-libc bzw. dem Compiler unterstützt. Bei Problemen hilft oft ein Blick in den erzeugten Assembler-Code. Die Anzahl der unterstützen Controller steigt jedoch mit Version zu Version von binutils, avr-libc und avrdude. Evtl. reicht einfach ein Update auf neuere Software-Versionen (z. B. im jeweils aktuellen WinAVR-Packet).

* inp(), outp(), sbi() und cbi() werden in der aktuellen Bibliotheksversion nicht offiziell unterstützt (man muss eine spezielle Header-Datei einbinden(deprecated.h). Es wird schon seit längerem empfohlen, diese Makros nicht mehr zu nutzen. Einige Anleitungen sind in diesem Punkt veraltet. Mit halbwegs aktuellen avr-gcc/avr-libc-Versionen kann einfach z. B. DDRB=0xfe bzw. foo=PINB geschrieben werden. Mit PORTB |= _BV(1) setzt man PORTB.1, mit PORTB &= ~_BV(1) löscht man es wieder, mit PORTB ^= _BV(1) kann man es umschalten (_BV(x) entspricht dabei (1<<x)). Die ersten beiden Varianten erzeugen bei eingeschalteter Optimierung und passenden Parametern (wie hier im Beispiel Register im "unteren" Speicherbereich) die SBI bzw. CBI Prozessorbefehle.

* Mit dem Tool avr-nm erhält man eine Übersicht über die Platzausnutzung in der erzeugten ELF-Datei bzw. dem damit gefüllten AVR. Das Tool wird per Kommandozeile mit
::<pre>avr-nm --size-sort --print-size -r -td <your_ELF_file></pre>
:aufgerufen und gibt eine vierspaltige Liste aus: Die erste Spalte ist die Adresse, die zweite die benötigte Größe, die dritte der Typ und die vierte der Name des Symbols. Alle Symbole vom Typ "T" (globale Funktionen), "t" (lokale Funktionen) und letztlich auch die mit einem "D" oder "d" (globale bzw. lokale Daten mit Initialisierungswerten im ROM) betreffen das FLASH-ROM. Typen "B" und "b" brauchen ausschließlich RAM (werden beim Start mit 0 initialisiert). (vgl. [http://www.mikrocontroller.net/topic/59960#467920 Forenbeitrag] von Jörg Wunsch)

* Mit dem Tool avr-size erhält man eine Übersicht über den Platzbedarf in den text, data und bss Sektionen innerhalb der ELF Binärdatei. Die Sektionen text und data benötigen Platz im FLASH-ROM und die Sektionen data und bss benötigen zur Laufzeit Platz im SRAM.

== Fußnoten ==
<references/>

== Siehe auch ==
* [[AVR-GCC-Tutorial]]
* [[AVR-GCC-Codeoptimierung]]
* [[GCC: unbenutzte Funktionen entfernen]]
* [http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna AVR-GCC Interna]

== Weblinks ==
* [http://winavr.sourceforge.net/install_config_WinAVR.pdf Tutorial von C. O'Flynn und E. Weddington] Einstieg in die Nutzung des avr-gcc unter MS-Windows mit WinAVR (englisch)
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml AVR-GCC und Linux]
* [http://www.mikrocontroller.net/forum/list-2-1.html GCC-Forum auf mikrocontroller.net]

[[Category:AVR]]
[[Category:Compiler]]
[[Kategorie:avr-gcc| ]]

AVR-GCC

2016-12-25T16:13:37Z

Newgeneration: bash-Kommandos angeglichen

avr-gcc ist ein freier [[C]]-Cross-[[Compiler]] für [[AVR]]-[[Mikrocontroller]].

avr-gcc kann von der Leistungsfähigkeit kommerzieller [[Compiler]] gut mithalten. Sogar C++-Programme sind möglich; in der aktuellen Fassung wird C++ jedoch nur eingeschränkt unterstützt (Stand 3/2012).

== Bestandteile ==

Die Toolchain (Werkzeugsammlung) besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen. Weit verbreitet ist die Verwendung von make zur Steuerung, siehe [[AVR-GCC-Tutorial/Exkurs Makefiles|AVR-GCC-Tutorial: Exkurs Makefiles]].

Die Bestandteile im einzelnen:
* Binutils: Assembler, Linker und weitere Hilfsprogramme.
* GCC: Der eigentliche C(++)-Compiler.
* AVR-Libc: Die C-Standardbibliothek mit AVR-spezifischen Headerdateien und Funktionen.
* [[AVRDUDE]]: universelle AVR-Programmiersoftware, kein eigentlicher Teil der Toolchain, aber oft verwendet

== Installation ==

=== Linux/Unix ===

Atmel bietet die [http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an.

Wenn keine aktuelle avr-gcc-Version als Paket (Paketname ist, zumindest bei Debian, gcc-avr) für die verwendete Distribution zur Verfügung steht, dann können sich [[Unix]]/[[Linux]]-Nutzer den Sourcecode herunterladen und selbst kompilieren, dazu gibt es Schritt-für-Schritt-Anleitungen<ref>[http://www.nongnu.org/avr-libc/user-manual/install_tools.html AVR-Libc: Building and Installing under Linux, FreeBSD, and Others]</ref><ref>[http://www.roboternetz.de/wissen/index.php/Avr-gcc_und_avrdude_installieren www.roboternetz.de: avr-gcc und avrdude installieren]</ref>.

Das [http://www.femtoos.org FemtoOS]-Paket beinhaltet Scripte zum automatischen Herunterladen und Bauen einer avr-gcc Version 4.3.3.

Empfehlenswert ist auch [http://cdk4avr.sf.net CDK4AVR], das die entsprechenden Tools als einfach installierbare Linux-Pakete bereitstellt. Leider ist das Projekt schon etwas älter, im Forum findet sich ein [http://www.mikrocontroller.net/topic/130972 Beitrag], aktuellere Sourcen mit den entsprechenden Patches zu versehen und zu kompilieren. Patches zu den Binutils und GCC-Sourcen sind unumgänglich, da die offiziellen Sourcen aufgrund des Umfangs an Prozessortargets den aktuellsten Entwicklungen hinterherhinken und damit bereits bekannte Fehler eventuell noch nicht behoben sind. Weitere Tipps zur AVR-Programmierung unter Linux stehen im Artikel [[AVR und Linux]].

=== Mac OS X ===
Die beste fertige Toolchain ist das [http://www.obdev.at/crosspack/ Crosspack]. Dieses enthält auch die AVR-Libc, avrdude und avarice. Leider gab es bei Mac OS 10.5.6 eine tiefgreifende Änderung beim fork()-Systemcall, der bewirkt, dass avarice mit JTAGICE mkII und Dragon nicht funktioniert. Geräte mit Serial-USB-Konvertern (AVRISP clones etc) funktionieren dagegen problemlos.

Wer die Toolchain von Hand bauen möchte kann das natürlich auch tun, dazu einfach den unter "Linux/Unix" verlinkten Anleitungen folgen. Unter [[Mac OS X]] muss man dazu zuerst die [http://developer.apple.com/Tools/ Apple Developer Tools] installieren.

Teile der Toolchain (AVR-Libc und avrdude) kann folgendermaßen installieren:

==== Mit MacPorts ====
Wenn man [http://www.macports.org/ MacPorts] benutzt kann man folgendes in das Terminal eingeben, um den Toolchain zu installieren:

sudo port install avr-libc

Das Programmiertool avrdude bekommt man genauso:

sudo port install avrdude

==== Mit Hombrew ====
Mit dem neueren Tool [http://brew.sh Homebrew] funktioniert das folgendermaßen:

avrdude kann sofort installiert werden:

brew install avrdude

Für den restlichen Toolchain muss man erst ein 'Tap' hinzufügen:

brew tap larsimmisch/homebrew-avr

und kann dann den eigentlichen Toolchain installieren:

brew install avr-libc

Weblinks:

* [http://tinkerlog.com/2007/09/29/programming-avr-with-a-macbook/ Programming AVR with a MacBook] (engl.)
* [http://www.ladyada.net/library/avrdevtut/setup-mac.html AVR Tutorial from Lady Ada] (engl.)
* [http://www.obdev.at/crosspack/ Crosspack]
* [http://www.digithink.com/OSX-AVR OSX-AVR (nicht mehr aktuell)]
* [http://www.definefalsetrue.com/index.php/Mac-OS-X/bootfeedx.html BootFeedX Bootloaderfrontend]

=== Windows ===

Man kann sich auch für Windows den GCC selbst bauen oder man sucht von anderen erstellte Binaries.

Atmel bietet die [http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an. Allerdings ohne "make".

Der alte Klassiker [[WinAVR]] wird seit 2010 nicht mehr gepflegt und funktioniert
ab Windows 8 nur noch eingeschränkt.

Die Firma SysProgs bietet aktuelle Versionen der [http://gnutoolchains.com GNU Toolchain]
einschließlich "make" für viele Systemarchitekturen zum Download an.

==== Selbst bauen ====

Zuerst sei einmal die offizielle (englische) Anleitung genannt: [http://www.nongnu.org/avr-libc/user-manual/install_tools.html Building and Installing avr-gcc]

Das hier ist die etwas ausführlichere Beschreibung, die mir Johann L. gegeben hat, damit ich meinen Compiler erstellen konnte. Der Post dazu findet sich [https://www.mikrocontroller.net/topic/384825?goto=4394391#4394606 hier].

Zuerst einmal braucht man am besten ein Linux, zum Beispiel ein aktuelles Ubuntu. dort müssen diverse Programme wie gcc, autoconf, subversion usw. installiert sein. Wenn etwas fehlt meckert configure, das einfach aufmerksam lesen und dann die Programme nachistallieren. Danach erneut configure aufrufen.
Um die Toolchain für Windows zu bauen brauchen wir noch mingw32. Eventuell findet sich das in den Paketquellen eurer Distribution, sonst kann ich auf [http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/ diese Seite] verweisen.

===== Vorbereitungen =====
Wie schon gesagt brauchen wir ein Linux, zum Beispiel in einer VM. Ein paar Linux-Hintergrundinfos wären auch gut, kann man aber auch ergooglen.
'''Achtung:''' Auf diesem Linux darf kein avr-gcc und keine avr-libc vorhanden sein!
Dazu brauchen wir die folgende Software:
* GNU Binutils: [https://www.sourceware.org/binutils/ Download], am besten die neueste Version (runter scrollen, aktuell ist 2.27)
* GCC Sourcen: [https://gcc.gnu.org/ Download], diese sollten aus dem svn kommen (svn co svn://gcc.gnu.org/svn/gcc/branches/''branchname'' gcc ,mit ''branchname'' gcc-''version''-branch, aktuell ist gcc-6-branch) oder aus dem aktuellen ''trunk'' (svn co svn://gcc.gnu.org/svn/gcc/trunk).
* Die AVR-libc: [http://download.savannah.gnu.org/releases/avr-libc/ Download]. ''Achtung:'' Ab gcc-Version 5 muss mindestens eine avr-libc-Version >= 2.0.0 verwendet werden. Ältere GCCs brauchen natürlich auch eine avr-libc vor dieser Version.

Alles herunterladen und entpacken.

Zu den Downloads kommen dann noch 2 Umgebungsvariablen:
<syntaxhighlight lang="bash">
$ PREFIX=$HOME/local/avr
$ export PREFIX
$ PATH=$PATH:$PREFIX/bin
$ export PATH
</syntaxhighlight>
Damit legt ihr das Installationsverzeichnis fest und fügt auch gleich das Verzeichnis für die ausführbaren Dateien zum Pfad hinzu.

Im Folgenden gehe ich von diesem Ordner-Layout aus:
<pre>
$HOME
|
+ BuildToolchain
|
+ Downloads
| |
| + binutils
| + gcc
| + avr-libc
|
+ buildLinux
| |
| + binutils
| + gcc
| + avr-libc
|
+ buildWindows
|
+ binutils
+ gcc
</pre>

===== Erstellen der Binutils =====
Wechselt in das Verzeichnis BuildToolchain/buildLinux/binutils.
Von dort aus werden wir die binutils konfigurieren und erstellen.

'''Achtung:''' man darf weder GCC noch die Binutils in einem Verzeichnis innerhalb des Quellordners der Downloads konfigurieren, sonst kommen wirre Fehler.

Also, wir sind soweit. Jetzt geht es ans Konfigurieren und erstellen, aber das ist ganz leicht:
<syntaxhighlight lang="bash">
$ ../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls
</syntaxhighlight>
Wenn configure fehlende Programme meldet: nachinstallieren und erneut versuchen.
<syntaxhighlight lang="bash">
$ make
$ make install
</syntaxhighlight>

Damit sind die Binutils fertig. Ihr könnt nachkontrollieren, ob die binutils da sind: Im Ordner $PREFIX/bin sollten sich die Dateien befinden, darunter avr-objcopy, avr-as, avr-size, etc.

===== Erstellen vom GCC =====
Als erstes muss sich der GCC noch ein paar zusätzliche Dateien herunterladen, das geschieht automatisch mit dem Befehl (ausgeführt in BuildToolchain/Downloads/gcc):
<syntaxhighlight lang="bash">
./contrib/download_prerequisites
</syntaxhighlight>
Wechselt ins Verzeichnis BuildToolchain/buildLinux/gcc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../Downloads/gcc/configure --prefix=$PREFIX --target=avr \
--enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2
$ make
$ make install
</syntaxhighlight>

===== Erstellen der avr-libc =====
Als erstes muss die avr-libs zum konfigurieren bereit gemacht werden:
Im Verzeichnis BuildToolchain/Downloads/avr-libc die Datei bootstrap ausführen
<syntaxhighlight lang="bash">
./bootstrap
</syntaxhighlight>
Danach wechselt ihr ins Verzeichnis BuildToolchain/buildLinux/avr-libc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../Downloads/avr-libc/configure --prefix=$PREFIX --build=`./config.guess` --host=avr
$ make
$ make install
</syntaxhighlight>

===== Testen unter Linux =====
So, jetzt seit ihr schon bei der Hälfte: Der Compiler läuft schon unter Linux!
Das testet ihr am besten schon mit ein paar einfachen LED-blink-Programmen, damit auch sichergestellt ist, dass bis hierhin alles geklappt hat.
Das einfachste und wichtigste Kommando dürfte sein
<syntaxhighlight lang="bash">
$ avr-gcc --version
</syntaxhighlight>
Dort sollte die Versionsnummer der GCC stehen. Wenn eine ältere Nummer dasteht, hab ihr entweder einen alten Download bemüht, oder eine andere Version vom avr-gcc war noch installiert.
Wenn der Fehler kommt, dass das Programm nicht gefunden werden kann, dann befindet sich avr-gcc nicht im PATH, das bedeutet ihr habt die Umgebungsvariablen nicht richtig gesetzt (siehe oben).

===== Bau für Windows =====
Ihr müsst keine neuen Dateien runter laden, lediglich die Programme nochmal etwas anders konfigurieren.
Die Schritte davor '''müssen''' jedoch ausgeführt werden!

Wechselt ins Verzeichnis BuildToolchain/buildWindows/binutils und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../Download/binutils/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
--host=plattform-w64-mingw32 --build=plattform-linux-gnu
$ make
$ make install
</syntaxhighlight>
Wobei ''plattform'' euer Ziel-System ist, also entweder i686 oder x86_64, je nach dem, was ihr für ein mingw installiert habt und ob ihr den Compiler für 32bit (i686) oder 64bit (x86_64) baut.

Wechselt ins Verzeichnis BuildToolchain/buildWindows/gcc und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../Downloads/gcc/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
--host=plattform-w64-mingw32 --build=plattform-linux-gnu --enable-languages=c,c++,lto --with-gnu-as \
--with-gnu-ld --disable-shared --with-dwarf2
$ make
$ make install
</syntaxhighlight>

Wechselt ins Verzeichnis BuildToolchain/buildLinux/avr-libc und führt den folgenden Befehl aus:
<syntaxhighlight lang="bash">
$ make install prefix=$HOME/local/avr4win
</syntaxhighlight>

Eigentlich ist der Compiler auch "schon" fertig. Aber in den Binaries sind noch die gesamten Symbole enthalten, was die .exe-Dateien aufbläht. Um diese los zu werden, kann man einfach noch diesen Befehl ausführen:
<syntaxhighlight lang="bash">
$ find . -name '*.exe' -exec plattform-w64-mingw32-strip {} ';'
</syntaxhighlight>

Damit sollten ihr im Ordner $HOME/local/avr4win die gesamte Toolchain haben. Diesen Ordner müsst ihr nur noch auf euren Windows-PC kopieren.
Für das klassische WinAVR fehlt noch Programmers Notepad, sowie die Utility-Programme, vor allem avrdude und make. Diese kann man entweder seperat downloaden oder aus einer WinAVR-Installation kopieren. Die Versionen davon spielen keine Rolle.

== Entwicklungsumgebungen ==

Win32:
* [[AVR-Studio]]: ab Version 4.12 mit WinAVR-Unterstützung, integrierter Simulator, Debugger, rudimentäre Projektverwaltung
* Programmers-Notepad: wird bei [[WinAVR]] mitgeliefert, ein guter Editor mit einer rudimentären Projektverwaltung
* [http://www.myavr.info/download/benutzerhandbuch_sisy_avr.pdf SiSy-AVR]: ein CASE-Tool mit WinAVR-Unterstützung, das eine Entwicklungsumgebung bereitstellt.

Plattformunabhängig:
* [http://www.eclipse.org/ Eclipse] mit CDT und dem [http://avr-eclipse.sourceforge.net/index.html AVR Eclipse Plugin]
* [[Code::Blocks]]: vielseitige, freie Entwicklungsumgebung für Windows und Linux
* [http://www.netbeans.org/ Netbeans] in der C++ - Version mit [[WinAVR]] oder [[avr-gcc]] als Toolchain

Linux:
*[http://sourceforge.net/projects/kontrollerlab/?_test=b KontrollerLab] ist eine freie Entwicklungsumgebung für AVR momentan aber noch im Beta-stadium.

== Bibliotheken / Libraries ==

Die [http://www.nongnu.org/avr-libc/ AVR-Libc] ist die gebräuchliche "Laufzeitbibliothek" zum avr-gcc C-Compiler, welche den Zugriff auf die AVR-Hardware erheblich erleichtert. Die offizielle Dokumentation zur avr-libc mit vielen Hinweisen auch zum Compiler avr-gcc und verschiedener Tools (z. B. [[AVRDUDE]]) findet man [http://www.nongnu.org/avr-libc/user-manual/index.html hier].

Auch die [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon AVRlib] enthält nützlichen Code z. B. für UART, LCD,.... Bei der Procyon AVRlib ist die Lizenz zu beachten (in Kurzform: man muss dritten auf Verlangen den gesamten Quellcode der Firmware zur Verfügung stellen, falls Teile der Procyon Bibliothek genutzt werden).

Zum Zugriff auf interne Funktionen oder externe Peripherie existieren einige fertige Komponenten. Z.B. "Projects"-Bereich von [http://www.avrfreaks.net/ avrfreaks.net] (Anmeldung erforderlich (kostenlos)).

Die Erstellung eigener Bibliotheken ist im Artikel [[Libraries]] erklärt.

== Tipps & Tricks ==

Eine Liste mit einigen Hinweisen:

* 07.10.11 → es kann Probleme mit der aktuellen Eclipse-Version (Indigo) und WinAVR geben. Falls ihr Indigo installiert habt und Eclipse die Definitionen wie z.B. DDRA nicht kennt, jedoch kompillieren kann, dann müsst ihr auf die Version Helios SR2 wechseln. Danach läuft alles wie gehabt!

* Keine "antiken" Versionen verwenden. Für MS-Windows-Nutzer: aktuelles WinAVR installieren. Für Linux/Unix-Nutzer: letzte stabile Version selbst kompilieren oder aus "Distribution-Packages" installieren (z. B. [http://cdk4avr.sourceforge.net/ cdk4avr]).

* Bei Problemen zuerst in die [http://www.nongnu.org/avr-libc/user-manual/index.html Anleitung] der avr-libc schauen. Insbesondere die FAQ lesen.

* Sicherstellen, dass der MCU-Parameter (zum Compiler/Linker, meist im Makefile defniert) mit dem Zielprozessor übereinstimmt.

* [[AVR-GCC-Tutorial]] in diesem Wiki lesen.

* Im Zweifel nicht INTERRUPT(...) sondern SIGNAL(...) nutzen. In neueren Versionen der avr-libc wurde "ISR" als Ersatz für SIGNAL eingeführt und sollte genutzt werden (SIGNAL und INTERRUPT werden langfristig entfallen). Darauf achten, dass die Vektor- bzw. Signal-Namen ("Parameter") zu ISR bzw. SIGNAL (und INTERRUPT wenn denn unbedingt erforderlich) richtig geschrieben sind. Die Namen sind in der in der entsprechenden Header-Datei (ioxxx.h) für den Controller und der avr-libc-Dokumenation aufgelistet. Im Zweifel den erzeugten Interrupt-Vektor im Assembler-Listing prüfen, es darf '''kein''' SIG_''xxx'' oder xxx_vect mehr zu sehen sein, sondern _vector_''N'' (wobei ''N'' eine Zahl ist). Neuere Versionen der avr-gcc zeigen eine Warnung, falls etwas falsch geschrieben wurde, ältere Versionen nicht.

* Zugriff auf Daten(-Tabellen) im Programmspeicher (Flash) erfolgt über Program-Space-Funktionen (pgm_read*). Lediglich die Definition einer Variablen/eines Feldes mit dem PROGMEM Attribut zu versehen, reicht (im Gegensatz zu Codevision, IAR, Imagecraft) nicht aus.

* Nicht alle AVRs werden vollständig von der avr-libc bzw. dem Compiler unterstützt. Bei Problemen hilft oft ein Blick in den erzeugten Assembler-Code. Die Anzahl der unterstützen Controller steigt jedoch mit Version zu Version von binutils, avr-libc und avrdude. Evtl. reicht einfach ein Update auf neuere Software-Versionen (z. B. im jeweils aktuellen WinAVR-Packet).

* inp(), outp(), sbi() und cbi() werden in der aktuellen Bibliotheksversion nicht offiziell unterstützt (man muss eine spezielle Header-Datei einbinden(deprecated.h). Es wird schon seit längerem empfohlen, diese Makros nicht mehr zu nutzen. Einige Anleitungen sind in diesem Punkt veraltet. Mit halbwegs aktuellen avr-gcc/avr-libc-Versionen kann einfach z. B. DDRB=0xfe bzw. foo=PINB geschrieben werden. Mit PORTB |= _BV(1) setzt man PORTB.1, mit PORTB &= ~_BV(1) löscht man es wieder, mit PORTB ^= _BV(1) kann man es umschalten (_BV(x) entspricht dabei (1<<x)). Die ersten beiden Varianten erzeugen bei eingeschalteter Optimierung und passenden Parametern (wie hier im Beispiel Register im "unteren" Speicherbereich) die SBI bzw. CBI Prozessorbefehle.

* Mit dem Tool avr-nm erhält man eine Übersicht über die Platzausnutzung in der erzeugten ELF-Datei bzw. dem damit gefüllten AVR. Das Tool wird per Kommandozeile mit
::<pre>avr-nm --size-sort --print-size -r -td <your_ELF_file></pre>
:aufgerufen und gibt eine vierspaltige Liste aus: Die erste Spalte ist die Adresse, die zweite die benötigte Größe, die dritte der Typ und die vierte der Name des Symbols. Alle Symbole vom Typ "T" (globale Funktionen), "t" (lokale Funktionen) und letztlich auch die mit einem "D" oder "d" (globale bzw. lokale Daten mit Initialisierungswerten im ROM) betreffen das FLASH-ROM. Typen "B" und "b" brauchen ausschließlich RAM (werden beim Start mit 0 initialisiert). (vgl. [http://www.mikrocontroller.net/topic/59960#467920 Forenbeitrag] von Jörg Wunsch)

* Mit dem Tool avr-size erhält man eine Übersicht über den Platzbedarf in den text, data und bss Sektionen innerhalb der ELF Binärdatei. Die Sektionen text und data benötigen Platz im FLASH-ROM und die Sektionen data und bss benötigen zur Laufzeit Platz im SRAM.

== Fußnoten ==
<references/>

== Siehe auch ==
* [[AVR-GCC-Tutorial]]
* [[AVR-GCC-Codeoptimierung]]
* [[GCC: unbenutzte Funktionen entfernen]]
* [http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna AVR-GCC Interna]

== Weblinks ==
* [http://winavr.sourceforge.net/install_config_WinAVR.pdf Tutorial von C. O'Flynn und E. Weddington] Einstieg in die Nutzung des avr-gcc unter MS-Windows mit WinAVR (englisch)
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml AVR-GCC und Linux]
* [http://www.mikrocontroller.net/forum/list-2-1.html GCC-Forum auf mikrocontroller.net]

[[Category:AVR]]
[[Category:Compiler]]
[[Kategorie:avr-gcc| ]]

AVR-GCC

2016-12-25T16:07:36Z

Newgeneration: Fehler korrigiert

avr-gcc ist ein freier [[C]]-Cross-[[Compiler]] für [[AVR]]-[[Mikrocontroller]].

avr-gcc kann von der Leistungsfähigkeit kommerzieller [[Compiler]] gut mithalten. Sogar C++-Programme sind möglich; in der aktuellen Fassung wird C++ jedoch nur eingeschränkt unterstützt (Stand 3/2012).

== Bestandteile ==

Die Toolchain (Werkzeugsammlung) besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen. Weit verbreitet ist die Verwendung von make zur Steuerung, siehe [[AVR-GCC-Tutorial/Exkurs Makefiles|AVR-GCC-Tutorial: Exkurs Makefiles]].

Die Bestandteile im einzelnen:
* Binutils: Assembler, Linker und weitere Hilfsprogramme.
* GCC: Der eigentliche C(++)-Compiler.
* AVR-Libc: Die C-Standardbibliothek mit AVR-spezifischen Headerdateien und Funktionen.
* [[AVRDUDE]]: universelle AVR-Programmiersoftware, kein eigentlicher Teil der Toolchain, aber oft verwendet

== Installation ==

=== Linux/Unix ===

Atmel bietet die [http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an.

Wenn keine aktuelle avr-gcc-Version als Paket (Paketname ist, zumindest bei Debian, gcc-avr) für die verwendete Distribution zur Verfügung steht, dann können sich [[Unix]]/[[Linux]]-Nutzer den Sourcecode herunterladen und selbst kompilieren, dazu gibt es Schritt-für-Schritt-Anleitungen<ref>[http://www.nongnu.org/avr-libc/user-manual/install_tools.html AVR-Libc: Building and Installing under Linux, FreeBSD, and Others]</ref><ref>[http://www.roboternetz.de/wissen/index.php/Avr-gcc_und_avrdude_installieren www.roboternetz.de: avr-gcc und avrdude installieren]</ref>.

Das [http://www.femtoos.org FemtoOS]-Paket beinhaltet Scripte zum automatischen Herunterladen und Bauen einer avr-gcc Version 4.3.3.

Empfehlenswert ist auch [http://cdk4avr.sf.net CDK4AVR], das die entsprechenden Tools als einfach installierbare Linux-Pakete bereitstellt. Leider ist das Projekt schon etwas älter, im Forum findet sich ein [http://www.mikrocontroller.net/topic/130972 Beitrag], aktuellere Sourcen mit den entsprechenden Patches zu versehen und zu kompilieren. Patches zu den Binutils und GCC-Sourcen sind unumgänglich, da die offiziellen Sourcen aufgrund des Umfangs an Prozessortargets den aktuellsten Entwicklungen hinterherhinken und damit bereits bekannte Fehler eventuell noch nicht behoben sind. Weitere Tipps zur AVR-Programmierung unter Linux stehen im Artikel [[AVR und Linux]].

=== Mac OS X ===
Die beste fertige Toolchain ist das [http://www.obdev.at/crosspack/ Crosspack]. Dieses enthält auch die AVR-Libc, avrdude und avarice. Leider gab es bei Mac OS 10.5.6 eine tiefgreifende Änderung beim fork()-Systemcall, der bewirkt, dass avarice mit JTAGICE mkII und Dragon nicht funktioniert. Geräte mit Serial-USB-Konvertern (AVRISP clones etc) funktionieren dagegen problemlos.

Wer die Toolchain von Hand bauen möchte kann das natürlich auch tun, dazu einfach den unter "Linux/Unix" verlinkten Anleitungen folgen. Unter [[Mac OS X]] muss man dazu zuerst die [http://developer.apple.com/Tools/ Apple Developer Tools] installieren.

Teile der Toolchain (AVR-Libc und avrdude) kann folgendermaßen installieren:

==== Mit MacPorts ====
Wenn man [http://www.macports.org/ MacPorts] benutzt kann man folgendes in das Terminal eingeben, um den Toolchain zu installieren:

sudo port install avr-libc

Das Programmiertool avrdude bekommt man genauso:

sudo port install avrdude

==== Mit Hombrew ====
Mit dem neueren Tool [http://brew.sh Homebrew] funktioniert das folgendermaßen:

avrdude kann sofort installiert werden:

brew install avrdude

Für den restlichen Toolchain muss man erst ein 'Tap' hinzufügen:

brew tap larsimmisch/homebrew-avr

und kann dann den eigentlichen Toolchain installieren:

brew install avr-libc

Weblinks:

* [http://tinkerlog.com/2007/09/29/programming-avr-with-a-macbook/ Programming AVR with a MacBook] (engl.)
* [http://www.ladyada.net/library/avrdevtut/setup-mac.html AVR Tutorial from Lady Ada] (engl.)
* [http://www.obdev.at/crosspack/ Crosspack]
* [http://www.digithink.com/OSX-AVR OSX-AVR (nicht mehr aktuell)]
* [http://www.definefalsetrue.com/index.php/Mac-OS-X/bootfeedx.html BootFeedX Bootloaderfrontend]

=== Windows ===

Man kann sich auch für Windows den GCC selbst bauen oder man sucht von anderen erstellte Binaries.

Atmel bietet die [http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an. Allerdings ohne "make".

Der alte Klassiker [[WinAVR]] wird seit 2010 nicht mehr gepflegt und funktioniert
ab Windows 8 nur noch eingeschränkt.

Die Firma SysProgs bietet aktuelle Versionen der [http://gnutoolchains.com GNU Toolchain]
einschließlich "make" für viele Systemarchitekturen zum Download an.

==== Selbst bauen ====

Zuerst sei einmal die offizielle (englische) Anleitung genannt: [http://www.nongnu.org/avr-libc/user-manual/install_tools.html Building and Installing avr-gcc]

Das hier ist die etwas ausführlichere Beschreibung, die mir Johann L. gegeben hat, damit ich meinen Compiler erstellen konnte. Der Post dazu findet sich [https://www.mikrocontroller.net/topic/384825?goto=4394391#4394606 hier].

Zuerst einmal braucht man am besten ein Linux, zum Beispiel ein aktuelles Ubuntu. dort müssen diverse Programme wie gcc, autoconf, subversion usw. installiert sein. Wenn etwas fehlt meckert configure, das einfach aufmerksam lesen und dann die Programme nachistallieren. Danach erneut configure aufrufen.
Um die Toolchain für Windows zu bauen brauchen wir noch mingw32. Eventuell findet sich das in den Paketquellen eurer Distribution, sonst kann ich auf [http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/ diese Seite] verweisen.

===== Vorbereitungen =====
Wie schon gesagt brauchen wir ein Linux, zum Beispiel in einer VM. Ein paar Linux-Hintergrundinfos wären auch gut, kann man aber auch ergooglen.
'''Achtung:''' Auf diesem Linux darf kein avr-gcc und keine avr-libc vorhanden sein!
Dazu brauchen wir die folgende Software:
* GNU Binutils: [https://www.sourceware.org/binutils/ Download], am besten die neueste Version (runter scrollen, aktuell ist 2.27)
* GCC Sourcen: [https://gcc.gnu.org/ Download], diese sollten aus dem svn kommen (svn co svn://gcc.gnu.org/svn/gcc/branches/''branchname'' gcc ,mit ''branchname'' gcc-''version''-branch, aktuell ist gcc-6-branch) oder aus dem aktuellen ''trunk'' (svn co svn://gcc.gnu.org/svn/gcc/trunk).
* Die AVR-libc: [http://download.savannah.gnu.org/releases/avr-libc/ Download]. ''Achtung:'' Ab gcc-Version 5 muss mindestens eine avr-libc-Version >= 2.0.0 verwendet werden. Ältere GCCs brauchen natürlich auch eine avr-libc vor dieser Version.

Alles herunterladen und entpacken.

Zu den Downloads kommen dann noch 2 Umgebungsvariablen:
<syntaxhighlight lang="bash">
$ PREFIX=$HOME/local/avr
$ export PREFIX
$ PATH=$PATH:$PREFIX/bin
$ export PATH
</syntaxhighlight>
Damit legt ihr das Installationsverzeichnis fest und fügt auch gleich das Verzeichnis für die ausführbaren Dateien zum Pfad hinzu.

Im Folgenden gehe ich von diesem Ordner-Layout aus:
<pre>
$HOME
|
+ BuildToolchain
|
+ Downloads
| |
| + binutils
| + gcc
| + avr-libc
|
+ buildLinux
| |
| + binutils
| + gcc
| + avr-libc
|
+ buildWindows
|
+ binutils
+ gcc
</pre>

===== Erstellen der Binutils =====
Wechselt in das Verzeichnis BuildToolchain/buildLinux/binutils.
Von dort aus werden wir die binutils konfigurieren und erstellen.

'''Achtung:''' man darf weder GCC noch die Binutils in einem Verzeichnis innerhalb des Quellordners der Downloads konfigurieren, sonst kommen wirre Fehler.

Also, wir sind soweit. Jetzt geht es ans Konfigurieren und erstellen, aber das ist ganz leicht:
<syntaxhighlight lang="bash">
$ ../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls
</syntaxhighlight>
Wenn configure fehlende Programme meldet: nachinstallieren und erneut versuchen.
<syntaxhighlight lang="bash">
$ make
$ make install
</syntaxhighlight>

Damit sind die Binutils fertig. Ihr könnt nachkontrollieren, ob die binutils da sind: Im Ordner $PREFIX/bin sollten sich die Dateien befinden, darunter avr-objcopy, avr-as, avr-size, etc.

===== Erstellen vom GCC =====
Als erstes muss sich der GCC noch ein paar zusätzliche Dateien herunterladen, das geschieht automatisch mit dem Befehl (ausgeführt in BuildToolchain/Downloads/gcc):
<syntaxhighlight lang="bash">
./contrib/download_prerequisites
</syntaxhighlight>
Wechselt ins Verzeichnis BuildToolchain/buildLinux/gcc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../Downloads/gcc/configure --prefix=$PREFIX --target=avr \
--enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2
$ make
$ make install
</syntaxhighlight>

===== Erstellen der avr-libc =====
Als erstes muss die avr-libs zum konfigurieren bereit gemacht werden:
Im Verzeichnis BuildToolchain/Downloads/avr-libc die Datei bootstrap ausführen
<syntaxhighlight lang="bash">
./bootstrap
</syntaxhighlight>
Danach wechselt ihr ins Verzeichnis BuildToolchain/buildLinux/avr-libc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../Downloads/avr-libc/configure --prefix=$PREFIX --build=`./config.guess` --host=avr
$make
$make install
</syntaxhighlight>

===== Testen unter Linux =====
So, jetzt seit ihr schon bei der Hälfte: Der Compiler läuft schon unter Linux!
Das testet ihr am besten schon mit ein paar einfachen LED-blink-Programmen, damit auch sichergestellt ist, dass bis hierhin alles geklappt hat.
Das einfachste und wichtigste Kommando dürfte sein
<syntaxhighlight lang="bash">
avr-gcc --version
</syntaxhighlight>
Dort sollte die Versionsnummer der GCC stehen. Wenn eine ältere Nummer dasteht, hab ihr entweder einen alten Download bemüht, oder eine andere Version vom avr-gcc war noch installiert.
Wenn der Fehler kommt, dass das Programm nicht gefunden werden kann, dann befindet sich avr-gcc nicht im PATH, das bedeutet ihr habt die Umgebungsvariablen nicht richtig gesetzt (siehe oben).

===== Bau für Windows =====
Ihr müsst keine neuen Dateien runter laden, lediglich die Programme nochmal etwas anders konfigurieren.
Die Schritte davor '''müssen''' jedoch ausgeführt werden!

Wechselt ins Verzeichnis BuildToolchain/buildWindows/binutils und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../Download/binutils/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
--host=plattform-w64-mingw32 --build=plattform-linux-gnu
$ make
$ make install
</syntaxhighlight>
Wobei ''plattform'' euer Ziel-System ist, also entweder i686 oder x86_64, je nach dem, was ihr für ein mingw installiert habt und ob ihr den Compiler für 32bit (i686) oder 64bit (x86_64) baut.

Wechselt ins Verzeichnis BuildToolchain/buildWindows/gcc und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../Downloads/gcc/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
--host=plattform-w64-mingw32 --build=plattform-linux-gnu --enable-languages=c,c++,lto --with-gnu-as \
--with-gnu-ld --disable-shared --with-dwarf2
$ make
$ make install
</syntaxhighlight>

Wechselt ins Verzeichnis BuildToolchain/buildLinux/avr-libc und führt den folgenden Befehl aus:
<syntaxhighlight lang="bash">
$ make install prefix=$HOME/local/avr4win
</syntaxhighlight>

Eigentlich ist der Compiler auch "schon" fertig. Aber in den Binaries sind noch die gesamten Symbole enthalten, was die .exe-Dateien aufbläht. Um diese los zu werden, kann man einfach noch diesen Befehl ausführen:
<syntaxhighlight lang="bash">
find . -name '*.exe' -exec plattform-w64-mingw32-strip {} ';'
</syntaxhighlight>

Damit sollten ihr im Ordner $HOME/local/avr4win die gesamte Toolchain haben. Diesen Ordner müsst ihr nur noch auf euren Windows-PC kopieren.
Für das klassische WinAVR fehlt noch Programmers Notepad, sowie die Utility-Programme, vor allem avrdude und make. Diese kann man entweder seperat downloaden oder aus einer WinAVR-Installation kopieren. Die Versionen davon spielen keine Rolle.

== Entwicklungsumgebungen ==

Win32:
* [[AVR-Studio]]: ab Version 4.12 mit WinAVR-Unterstützung, integrierter Simulator, Debugger, rudimentäre Projektverwaltung
* Programmers-Notepad: wird bei [[WinAVR]] mitgeliefert, ein guter Editor mit einer rudimentären Projektverwaltung
* [http://www.myavr.info/download/benutzerhandbuch_sisy_avr.pdf SiSy-AVR]: ein CASE-Tool mit WinAVR-Unterstützung, das eine Entwicklungsumgebung bereitstellt.

Plattformunabhängig:
* [http://www.eclipse.org/ Eclipse] mit CDT und dem [http://avr-eclipse.sourceforge.net/index.html AVR Eclipse Plugin]
* [[Code::Blocks]]: vielseitige, freie Entwicklungsumgebung für Windows und Linux
* [http://www.netbeans.org/ Netbeans] in der C++ - Version mit [[WinAVR]] oder [[avr-gcc]] als Toolchain

Linux:
*[http://sourceforge.net/projects/kontrollerlab/?_test=b KontrollerLab] ist eine freie Entwicklungsumgebung für AVR momentan aber noch im Beta-stadium.

== Bibliotheken / Libraries ==

Die [http://www.nongnu.org/avr-libc/ AVR-Libc] ist die gebräuchliche "Laufzeitbibliothek" zum avr-gcc C-Compiler, welche den Zugriff auf die AVR-Hardware erheblich erleichtert. Die offizielle Dokumentation zur avr-libc mit vielen Hinweisen auch zum Compiler avr-gcc und verschiedener Tools (z. B. [[AVRDUDE]]) findet man [http://www.nongnu.org/avr-libc/user-manual/index.html hier].

Auch die [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon AVRlib] enthält nützlichen Code z. B. für UART, LCD,.... Bei der Procyon AVRlib ist die Lizenz zu beachten (in Kurzform: man muss dritten auf Verlangen den gesamten Quellcode der Firmware zur Verfügung stellen, falls Teile der Procyon Bibliothek genutzt werden).

Zum Zugriff auf interne Funktionen oder externe Peripherie existieren einige fertige Komponenten. Z.B. "Projects"-Bereich von [http://www.avrfreaks.net/ avrfreaks.net] (Anmeldung erforderlich (kostenlos)).

Die Erstellung eigener Bibliotheken ist im Artikel [[Libraries]] erklärt.

== Tipps & Tricks ==

Eine Liste mit einigen Hinweisen:

* 07.10.11 → es kann Probleme mit der aktuellen Eclipse-Version (Indigo) und WinAVR geben. Falls ihr Indigo installiert habt und Eclipse die Definitionen wie z.B. DDRA nicht kennt, jedoch kompillieren kann, dann müsst ihr auf die Version Helios SR2 wechseln. Danach läuft alles wie gehabt!

* Keine "antiken" Versionen verwenden. Für MS-Windows-Nutzer: aktuelles WinAVR installieren. Für Linux/Unix-Nutzer: letzte stabile Version selbst kompilieren oder aus "Distribution-Packages" installieren (z. B. [http://cdk4avr.sourceforge.net/ cdk4avr]).

* Bei Problemen zuerst in die [http://www.nongnu.org/avr-libc/user-manual/index.html Anleitung] der avr-libc schauen. Insbesondere die FAQ lesen.

* Sicherstellen, dass der MCU-Parameter (zum Compiler/Linker, meist im Makefile defniert) mit dem Zielprozessor übereinstimmt.

* [[AVR-GCC-Tutorial]] in diesem Wiki lesen.

* Im Zweifel nicht INTERRUPT(...) sondern SIGNAL(...) nutzen. In neueren Versionen der avr-libc wurde "ISR" als Ersatz für SIGNAL eingeführt und sollte genutzt werden (SIGNAL und INTERRUPT werden langfristig entfallen). Darauf achten, dass die Vektor- bzw. Signal-Namen ("Parameter") zu ISR bzw. SIGNAL (und INTERRUPT wenn denn unbedingt erforderlich) richtig geschrieben sind. Die Namen sind in der in der entsprechenden Header-Datei (ioxxx.h) für den Controller und der avr-libc-Dokumenation aufgelistet. Im Zweifel den erzeugten Interrupt-Vektor im Assembler-Listing prüfen, es darf '''kein''' SIG_''xxx'' oder xxx_vect mehr zu sehen sein, sondern _vector_''N'' (wobei ''N'' eine Zahl ist). Neuere Versionen der avr-gcc zeigen eine Warnung, falls etwas falsch geschrieben wurde, ältere Versionen nicht.

* Zugriff auf Daten(-Tabellen) im Programmspeicher (Flash) erfolgt über Program-Space-Funktionen (pgm_read*). Lediglich die Definition einer Variablen/eines Feldes mit dem PROGMEM Attribut zu versehen, reicht (im Gegensatz zu Codevision, IAR, Imagecraft) nicht aus.

* Nicht alle AVRs werden vollständig von der avr-libc bzw. dem Compiler unterstützt. Bei Problemen hilft oft ein Blick in den erzeugten Assembler-Code. Die Anzahl der unterstützen Controller steigt jedoch mit Version zu Version von binutils, avr-libc und avrdude. Evtl. reicht einfach ein Update auf neuere Software-Versionen (z. B. im jeweils aktuellen WinAVR-Packet).

* inp(), outp(), sbi() und cbi() werden in der aktuellen Bibliotheksversion nicht offiziell unterstützt (man muss eine spezielle Header-Datei einbinden(deprecated.h). Es wird schon seit längerem empfohlen, diese Makros nicht mehr zu nutzen. Einige Anleitungen sind in diesem Punkt veraltet. Mit halbwegs aktuellen avr-gcc/avr-libc-Versionen kann einfach z. B. DDRB=0xfe bzw. foo=PINB geschrieben werden. Mit PORTB |= _BV(1) setzt man PORTB.1, mit PORTB &= ~_BV(1) löscht man es wieder, mit PORTB ^= _BV(1) kann man es umschalten (_BV(x) entspricht dabei (1<<x)). Die ersten beiden Varianten erzeugen bei eingeschalteter Optimierung und passenden Parametern (wie hier im Beispiel Register im "unteren" Speicherbereich) die SBI bzw. CBI Prozessorbefehle.

* Mit dem Tool avr-nm erhält man eine Übersicht über die Platzausnutzung in der erzeugten ELF-Datei bzw. dem damit gefüllten AVR. Das Tool wird per Kommandozeile mit
::<pre>avr-nm --size-sort --print-size -r -td <your_ELF_file></pre>
:aufgerufen und gibt eine vierspaltige Liste aus: Die erste Spalte ist die Adresse, die zweite die benötigte Größe, die dritte der Typ und die vierte der Name des Symbols. Alle Symbole vom Typ "T" (globale Funktionen), "t" (lokale Funktionen) und letztlich auch die mit einem "D" oder "d" (globale bzw. lokale Daten mit Initialisierungswerten im ROM) betreffen das FLASH-ROM. Typen "B" und "b" brauchen ausschließlich RAM (werden beim Start mit 0 initialisiert). (vgl. [http://www.mikrocontroller.net/topic/59960#467920 Forenbeitrag] von Jörg Wunsch)

* Mit dem Tool avr-size erhält man eine Übersicht über den Platzbedarf in den text, data und bss Sektionen innerhalb der ELF Binärdatei. Die Sektionen text und data benötigen Platz im FLASH-ROM und die Sektionen data und bss benötigen zur Laufzeit Platz im SRAM.

== Fußnoten ==
<references/>

== Siehe auch ==
* [[AVR-GCC-Tutorial]]
* [[AVR-GCC-Codeoptimierung]]
* [[GCC: unbenutzte Funktionen entfernen]]
* [http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna AVR-GCC Interna]

== Weblinks ==
* [http://winavr.sourceforge.net/install_config_WinAVR.pdf Tutorial von C. O'Flynn und E. Weddington] Einstieg in die Nutzung des avr-gcc unter MS-Windows mit WinAVR (englisch)
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml AVR-GCC und Linux]
* [http://www.mikrocontroller.net/forum/list-2-1.html GCC-Forum auf mikrocontroller.net]

[[Category:AVR]]
[[Category:Compiler]]
[[Kategorie:avr-gcc| ]]

Cortex-A

2016-12-19T13:35:47Z

Newgeneration: /* Unterschiede zum Cortex-M */

ARM Cortex-A sind von [[ARM]] konstruierte Prozessorkerne, wie sie zusammen mit dem Vorläufer ARM11 und einigen unabhängigen Implementierungen der ARM-Architektur in nahezu jedem Smartphone und Tablet verbaut sind.

ARM bezeichnet die Prozessorlinien folgendermaßen<ref>http://arm.com/products/processors/index.php</ref>:

;ARM Cortex Embedded Processors: Cortex-M Series – Cost-sensitive solutions for deterministic microcontroller applications
;ARM Cortex Real-time Embedded Processors: Cortex-R Series – Exceptional performance for real-time applications
;ARM Cortex Application Processors: Cortex™-A and Cortex-A50 Series – High performance processors for open Operating Systems

Sie sind deutlich leistungsstärker als ARM Cortex M Mikroprozessoren, daher werden sie eher im Application-Bereich, sprich mit Betriebssystemen Linux (z.B. Debian, Arch Linux ARM, Android), Windows Mobile etc. eingesetzt.

{| class="mw-collapsible mw-collapsed wikitable"
|+ Offizielle Beschreibungen aller Cortex-A Prozessoren von ARM
|-
! ARM Core || Key Benefits
|-
| Cortex-A5 ||
* ARM’s smallest application processor with Uniprocessor (UP) and Multiprocessor (MP) licensing options
* Extremely configurable processor with optional NEON, optional FPU and L1 caches configurable from 4K-64KB
* Full feature set of Cortex-A9 processor at one third the area and power
|-
| Cortex-A7 ||
* ARMv7-A architectural extensions (40-bit physical addressing, hardware virtualization support)
* More than 20% improvement in single thread integer performance compared to Cortex-A5
* Integrated L2 cache subsystem provides improved area efficiency and up to 43% improvements in memory streaming performance
* Proven successful design, now well matched to the needs of wearable mobile devices and other UI-based consumer products
|-
| Cortex-A8 ||
* Large increase in single thread performance over it’s predecessor, the ARM11
* ARMv7-A support including NEON and TrustZone
* Widely deployed in mobile and embedded, with numerous low-cost 3rd party development platforms. A great processor on which to learn the ARM architecture.
|-
| Cortex-A9 ||
* Scalable performance and power efficiency for a broad range of 32-bit consumer, networking, enterprise and mobile applications
* Support the wide ARMv7-A 32-bit software eco-system
* Mature and silicon proven in multiple process technologies
|-
| Cortex-A15 ||
* Established ARMv7-A processor with NEON-VFP configurability
* Reliable 32-bit infrastructure computing with 1TB addressing
* Support for multi-tenant software virtualization
|-
| Cortex-A17 ||
* Highest performance for ARMv7-A software ecosystem
* Cost efficiency with premium 32-bit performance for mass-market devices
* Mature and shipped in a wide range of consumer and embedded markets
|-
| Cortex-A32 ||
* ARMv8-A architectural enhancements, full backwards compatibility with ARMv7-A software
* Higher efficiency and performance compared to Cortex-A7 processor
* New idle power management features
* Highly scalable 32-bit processor with new configuration options
|-
| Cortex-A35 ||
* Most efficient 64-bit ARMv8-A processor with full ARMv7-A compatibility
* Efficiency improvements compared to the Cortex-A7: Less active power, improved performance
* Highly scalable ARMv8-A processor with new configuration options
|-
| Cortex-A53 ||
* High efficiency CPU for wide range of applications in mobile, DTV, automotive, networking, and more
* ARMv8-A architecture at low cost for standalone entry level designs
* Versatile enough to pair with any ARMv8 core in a big.LITTLE pairing, including Cortex-A57, Cortex-A72, or even other Cortex-A53 or Cortex-A35 CPU clusters
* Mature product with high volume shipment
|-
| Cortex-A57 ||
* Established ARMv8-A 64-bit processor
* Reliable 64-bit infrastructure computing with 16TB addressing
* Proven functional safety documentation package
|-
| Cortex-A72 ||
* ARM’s state-of-the-art high-performance processor for infrastructure, mobile, and automotive
* Market-leading compute density across all application form factors
* Improved performance and efficiency, with full ARMv8-A 64b support.
|-
| Cortex-A73 ||
* Highest performance in mobile power envelope. Up to 30% higher performance than previous generation.
* Up to 2.8GHz frequency for highest peak performance
* New levels of sustained usage for the best user experience. Up to 30% increased power efficiency
* Smallest premium ARMv8-A processor ever. Premium CPU under 0.65mm2 per core.
|}

== Unterschiede zum Cortex-M ==

Die Unterschiede zu den Cortex-M Mikrocontrollern sind unter anderem folgende:
* Teilweise 64 bit Prozessoren, mit vergrößertem Adressraum (44 bit oder mehr statt 32 bit)
* Kein On-Chip Speicher (meist ein geringes RAM vorhanden, aber ein externes ist so gut wie immer trotzdem nötig) macht externes Speicherinterface nötig, was viele Pins nutzt. Auch braucht man natürlich extra Speicher- und (DDR)-SDRAM-ICs.
* Mehrere Levels von Data und Instruction Caches
* Gehäuse mit wesentlich mehr Pins, meist im BGA
* Höhere Taktfrequenz (mehr als 500 MHz sind keine Seltenheit, aktuell maximal 2.8 GHz)
* ARM big.LITTLE Konzept: mehrere "kleine" Cortex-A-Cores werden zusammen mit mehreren "großen" Cores verschalten, um Enegie zu sparen: wenn wenig Leistung nötig ist werden die energieeffizierteren Cores benutzt, bei hohen Leistungsanforderungen übernehmen die anderne Cores
* ARM Jazelle für die beschleunigte Ausführung von Java-Code
* Sicherheitsmechanismen, wie eine [[MMU]] oder die ARM TrustZone Technologie
* Optional eine NEON™ Media Processing Engine
* Schnellere und präzisere [[FPU]]
* Kryptographie, wie AES- und SHA-Algorithmen, True-Random-Generators
* Digitale Interfaces, die man eher aus dem PC-Bereich kennt, wie HS-USB-Hosts, schnelles Ethernet, SD/MMC Interface, Kamera- oder Video-Dekoder, I²S, ...
* Dazu kommen aber auch klassische Mikrocontroller-Interfaces, wie UART, I²C, SPIs, interne ADCs und DACs, sowie Timer
''(für alle oben genannten Fälle gibt es natürlich auch Ausnahmen)''

Einige der oben genannten Punkte finden sich neuerdings auch in Cortex-M7-Controllern, die damit die Brücke zwischen Mikrocontrollern und Anwendungsprozessoren schlagen.

Größter Nachteil für diese Leistungsfähigen Controller wird das fehlen von On-Chip Flash und RAM sein, weil man so extra ICs braucht, was wiederum das Layouten erschwert, da ein DDR3-RAM-Design nicht mehr sonderlich einfach ist.

== Links ==

* [http://www.arm.com/products/processors/cortex-a/index.php?tab=Multicore Offizielle ARM Seite zu der Cortex-A Serie]
* [[Linux Boards]]
* [[Raspberry Pi Einführung]]

<references/>

[[Kategorie:ARM]]

FPU

2016-10-08T18:20:46Z

Newgeneration: Artikel etwas erweitert

'''F'''loating '''P'''oint '''U'''nit

Zu deutsch Gleitkommaeinheit. Diese ist Teil eines Prozessors, der spezielle Befehle für Berechnungen mit [[Gleitkommazahlen]] unterstützt. Diese Befehle beziehen sich meist auf den IEEE 754 Standard <ref>http://www.csee.umbc.edu/~tsimo1/CMSC455/IEEE-754-2008.pdf IEEE Standard for Floating-Point
Arithmetic</ref>

Durch eine solche Einheit werden die Operationen mit [[Gleitkommazahlen]] (in [[C]] die Datentypen float (''single precision'', 32bit), double (''double precision'', 64bit) und long double (''extended precision'', oftmals 80bit)) wesentlich schneller, weil in Hardware, durchgeführt.
Ist keine FPU verfügbar müssen die Operationen durch die libc der Toolchain "zu Fuß" emuliert werden, was natürlich mehr Befehle und damit mehr Laufzeit bedeutet.

Einfachere [[Mikrocontroller]], wie zum Beispiel der AVR, besitzen im Allgemeinen keine FPU, weshalb man, wenn es um Geschwindigkeit und Speicherverbrauch geht, auf [[Festkommaarithmetik]] setzen sollte. Damit kann man komplett auf Gleitkommazahlen und den damit verbundenen Overhead bei der Berechnung verzichten.

Neuere komplexere Prozessoren wie die ARM Cortex-Mikrocontroller können eine FPU eingebaut haben.

{| class="wikitable"
|-
! ARM-Cortex-M !! FPU
|-
| Cortex-M0 || Nein
|-
| Cortex-M1 || Nein
|-
| Cortex-M3 || Nein
|-
| Cortex-M4 || Optional (''single precision'')
|-
| Cortex-M7 || Optional (''single precision'')
|}

Die wesentlich leistungsfähigeren Application-Prozessoren von [[ARM]], die [[Cortex-A]], bieten im allgemeinen immer eine FPU, oftmals auch mit ''double precision''.

<references />

[[Kategorie:Mikrocontroller]]

Gleitkommazahlen

2016-10-08T11:50:30Z

Newgeneration: Erstellung der Seite

WordClock mit WS2812

2016-09-20T04:22:05Z

Newgeneration:

Dieser Artikel ist der Nachfolger der beiden Projekte [[Word_Clock]] und [[WordClock24h]]. Diese Projekte werden hier zusammengefasst und mit ein- und derselben Hard- und Software realisiert. Es ist damit der Bau einer 12-Stunden WordClock und einer minutengenauen 24-Stunden WordClock möglich.

Um die beiden Varianten zu unterscheiden, wird die 12-Stunden-Variante im folgenden '''WordClock12h''' und die 24-Stunden-Variante '''WordClock24h''' genannt.

Zugehöriger Thread im Forum: https://www.mikrocontroller.net/topic/385955

'''WordClock12h und WordClock24h:'''
{|
|-
| [[Datei:wordclock-frontplatte-v2.png|400px|left|WordClock12h]]
|| [[Datei:WordClock24h-Frontplatte-800x800.png|400px|right|WordClock24h]]
|}

= Software =

Die Software ist sowohl auf dem STM32F401RE oder STM32F411RE [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] als auch auf einem [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]] lauffähig.

=== Features ===

Die Software wird ständig weiterentwickelt. Folgende Punkte wurden bereits umgesetzt:

* Lauffähig auf STM32F401 [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo]], STM32F411 [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo]] und [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]
* Anbindung eines [[WordClock_mit_WS2812#ESP8266|ESP8266]]-WLAN-Moduls mit speziell abgestimmter Firmware
* Konfiguration über [[WordClock_mit_WS2812#Web-Interface|Webserver-Interface]]
* Fernsteuerung über IR-Fernbedienung mittels [[IRMP]]
* Fernsteuerung per [[WordClock_mit_WS2812#Android_App|Android App]]
* Einstellen des Anzeigemodus ("Sprache"), Helligkeit und der Farbe per IR-Fernbedienung/App/Web
* Konfigurierbare Nachtschaltzeiten - d.h. automatisches Abschalten zur Nachtzeit
* Anbindung von LED-Stripes des Typs [[WordClock_mit_WS2812#WS2812|WS2812]] und [[WordClock_mit_WS2812#WS2812|WS2812B]]
* Optionale Unterstützung von LED-Stripes des Typs APA102
* Optionale Unterstützung von LED-Stripes des Typs SK6812 (RGBW-LEDs)
* Sanftes Überblenden der Uhrzeiten oder verschiedene Animationen bei Uhrzeitwechsel, zB. "Explode" oder "Matrix"
* Farbanimationen, z.B. Automatischer Farbverlauf durch alle Regenbogenfarben ("Rainbow")
* Automatische Helligkeitsregelung mittels [[WordClock_mit_WS2812#LDR|LDR]] (optional)
* Anbindung einer externen DS3231-[[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]
* Anbindung eines externen I2C-[[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]
* Holen der Uhrzeit per NTP-Protokoll aus dem Internet
* Optionaler Anschluss eines [[WordClock_mit_WS2812#DCF77|DCF77]]-Moduls
* Manuelles Stellen der Uhrzeit per [[WordClock_mit_WS2812#Web-Interface|Webserver-Interface]] oder [[WordClock_mit_WS2812#Android_App|Android App]], wenn kein Internet/DCF77 verfügbar
* Optionale Temperaturmessung und -Anzeige mit [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx-Sensor]]
* Optionale Wetteranzeige über openweathermap.org
* Separate Farbauswahl für Display und Ambilight
* Ambilight mit auswählbaren Animationen: Keine, "Clock" (Umlaufende Sekundenanzeige) und "Rainbow"
* Optionale Steuerung der Stromversorgung für die LED-Stripes

=== Bugs ===

ESP-Firmware Version 2.1.0:

* Anzeigefehler - beim Wechseln in den AP-Modus wird fälschlicherweise "0.0.0.0" als IP-Adresse statt 192.168.4.1 ausgegeben. Wurde korrigiert in ESP-Version 2.1.0a.
* Umlaute in Wetteranzeigen werden nicht dargestellt. Wurde korrigiert in ESP-Version 2.1.0b.

STM32-Firmware Version 2.1.0:

* SK6812: Rot und Grün vertauscht. Behoben in STM32-Version 2.1.0a.
* Nach dem Setzen eines neuen LDR-Max-Wertes wird dieser nicht zurück an das Web-Interface übertragen und deshalb dort (bis zum nächsten Reboot) ein alter Max-Wert angezeigt. Wird korrigiert in STM32-Version 2.1.1.

=== Geplante Features ===

Für Version 2.2.0:

* Anzeige des aktuellen Datums über Laufschrift
* Anzeige von Wetterdaten über Piktogramme, Einblendung automatisch z.B. zu jeder halben/vollen Stunde

Weitere geplante Features:

* Anzeigen von Piktogrammen an bestimmten Tagen wie Geburtstag/Weihnachten etc.
* Animation "Matrix": Einstellung: In aktueller Displayfarbe oder in grün.
* Animation "Matrix": Ausblenden der Buchstaben per Strahl, Einblenden der Buchstaben durch 2. Strahl
* Snake Animation frisst nicht nur die alte Uhrzeit, sondern baut die neue Uhrzeit gleichzeitig oder in 2. Durchlauf hinter sich auf
* Neue Animation "Implode"
* Neue Animation "Flicker" (Flackern wie bei einer Leuchtstoffröhre)
* Ambilight: Sekundenzeiger mit Fading über mehrere LEDs
* Mood-Light-Funktion
* Hintergrundfarbe/Helligkeit für Display bzw. Ambilight
* Vereinfachtes Bedienkonzept für IR-Fernbedienung
* Spiele wie TRON, TETRIS, PONG

=== Download ===

'''WICHTIG'''

'''Ab Version 2.2.0 ist es unbedingt erforderlich, dass die aktuelle ESP8266-Firmware zur STM32-Firmware eingespielt wird! Ältere ESP8266-Firmware-Versionen führen auf jeden Fall zu Fehlverhalten!'''

'''EM::Blocks-Projekt, Version 2.2.0 vom 17.09.2016:''' [http://www.mikrocontroller.net/svnbrowser/wordclock24h/?view=tar Tarball]

'''SVN hier auf mikrocontroller.net:''' svn://mikrocontroller.net/wordclock24h/

'''Repo-Browser''': [http://www.mikrocontroller.net/svnbrowser/wordclock24h/ WordClock24h im SVN]

Hex-Dateien, wenn man - ohne zu compilieren - direkt flashen will:

* '''WC12h''' Version 2.2.0 Nucleo401-Board: [[Datei:Wc12h-nucleo401.hex]]
* '''WC12h''' Version 2.2.0 Nucleo411-Board: [[Datei:Wc12h-nucleo411.hex]]
* '''WC12h''' Version 2.2.0 STM32F103-Board: [[Datei:Wc12h-STM32F103.hex]]

* '''WC24h''' Version 2.2.0 Nucleo401-Board: [[Datei:Wc24h-nucleo401.hex]]
* '''WC24h''' Version 2.2.0 Nucleo411-Board: [[Datei:Wc24h-nucleo411.hex]]
* '''WC24h''' Version 2.2.0 STM32F103-Board: [[Datei:Wc24h-STM32F103.hex]]

* '''ESP8266 Firmware''' Version 2.2.0 vom 17.09.2016: [[Datei:ESP-WordClock.bin]] ('''NEU!''')

* '''[[WordClock_mit_WS2812#Android_App|Android App]]''' 2.1.0 vom 23.08.2016: [[Datei:WC24h.apk]]

Wie man diese APK unter Android installiert, kann man hier nachlesen:

http://www.pcwelt.de/ratgeber/Android-Smartphones-Apps-ausserhalb-des-Android-Market-installieren-1929591.html

Am einfachsten erlaubt man die Installation von Apps "aus unbekannten Quellen" und klickt anschließend direkt auf dem Android-Gerät auf den [[WordClock_mit_WS2812#Download|Download]]-Link. Dann kann man das Programm direkt nach dem Download installieren.

=== Software für Windows ===

Die Software zum Flashen des Programms:

* ST-Link/V2 , siehe: http://www.st.com/web/catalog/tools/FM146/CL1984/SC724/SS1677/PF251168

Alternativ kann das STM32MiniBoard auch über UART geflashed werden. Dann braucht man keinen ST-Link und verwendet folgende Software: http://www.st.com/web/en/catalog/tools/PF257525

Alternativer Link:

http://www2.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/flasher-stm32.html

Die Software für das Flashen über UART wird auch zum Aufspielen der ESP8266 Firmware des WLAN-Moduls benötigt.

Möchte man die Sources selber übersetzen:

* EM::Blocks IDE, siehe http://www.emblocks.org/

Möchte man die Debug- und Log-Meldungen als Entwickler oder zur Diagnose verfolgen, braucht man noch

* STM32 Virtual COM Port Driver: http://www.st.com/web/en/catalog/tools/PF257938 für das Nucleo-Board
* oder einen zusätzlichen USB-UART Adapter nebst Treiber für das STM32F103 Mini Development Board
* PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) oder andere Terminal-Emulation

=== WordClock-Quellcode selbst übersetzen ===

Dieser Vorgang ist nur notwendig, wenn man an den Quellen etwas ändern möchte. Im Normalfall braucht man lediglich eine der oben im [[WordClock_mit_WS2812#Download|Download]]-Kapitel angegebenen Hex-Dateien auszuwählen und diese auf den Prozessor flashen.

Wenn man an dem Programm etwas ändern oder erweitern möchte, dann startet man die zuvor installierte EM::Blocks-IDE. Aus dem SVN lädt man sich den Tarball (Link siehe Kapitel [[WordClock_mit_WS2812#Download|Download]]) und entpackt diesen unter C:\EmBlocksProjects.

Nach dem Entpacken findet man dann im Unterverzeichnis wclock24h die Projekt-Datei '''wclock24h.ebp''', um den Quellcode für ein [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] zu compilieren. In der EM::Blocks-Ide kann man nun mit '''File -> Open''' die Projekt-Datei laden.

Möchte man jedoch den Quellcode für das [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Board]] übersetzen, dann lädt man die Projektdatei '''wclock24h-F103.ebp''' aus dem Unterverzeichnis '''wclock24h-F103'''.

Anschließend wählt man in der oberen Zeile in der Mitte das Ziel aus, wofür man den Quellcode übersetzen möchte.

Beim [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo]]-Projekt werden folgende Alternativen angeboten:

WC24h:

* WC24h-Nucleo401-Debug
* WC24h-Nucleo401-Release

* WC24h-Nucleo411-Debug
* WC24h-Nucleo411-Release

WC12h:

* WC12h-Nucleo401-Debug
* WC12h-Nucleo401-Release

* WC12h-Nucleo411-Debug
* WC12h-Nucleo411-Release

In der F103-Projektdatei können folgende Varianten ausgewählt werden:

WC24h:

* WC24h-STM32F103-Debug
* WC24h-STM32F103-Release

WC12h:

* WC12h-STM32F103-Debug
* WC12h-STM32F103-Release

Die Debug-Varianten sind lediglich für die Bugsuche im Programm vonnöten. Es empfiehlt sich daher im Normalfall, die entsprechende Release-Variante auszuwählen.

Nach der Auswahl kann man dann unter '''Build -> Rebuild all target files''' den Übersetzungsvorgang starten. Danach findet man im Unterverzeichnis bin\\Release die dazugehörige Hex-Datei mit dem ST-Link-Programm dann auf dem Ziel geflasht werden kann. Das wars!

----

= Hardware =

== STM32F103C8T6 Mini-Development Board ==
{|
|- style="vertical-align:top;"
| '''Dieses Board wird für die "klassische" 10x11 WordClock12h empfohlen.'''

Dies ist ein kleines, platzsparendes Board mit ausreichendem 32Bit-Mikrocontroller. Der STM32F103C8T6 hat 64 KB Flash und 20KB RAM. Bei ebay ist er für kleines Geld (unter 4 EUR) zu haben: Einfach dort nach "STM32F103C8T6" suchen. Die Anbieter sind meist in China. Aber es gibt auch Anbieter aus Deutschland, wo das bestellte Board dann auch schon nach 2 Tagen im Briefkasten steckt. Meist sind die deutschen Anbieter aber etwas teurer.

Während die [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Boards]] bereits den "Programmer" ST-Link-V2 zum Programmieren des Flashs on-Board haben, ist dies hier nicht der Fall. Hier muss ein separates ST-Link-V2 zum einmaligen Programmieren verwendet werden. Hat man schon ein [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] zuhause, kann der darauf befindliche ST-Link verwendet werden. Oder man beschafft sich einen eigenen Programmer. Bei eBay erhält man sie bereits im einstelligen Euro-Bereich, wenn man nach "ST-Link V2" sucht.

Der Vorteil dieses Boards gegenüber dem Nucleo ist der geringe Platzbedarf. Es müssen lediglich ein paar Verbindungen zu den weiter unten erläuterten Modulen wie [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM und RTC]] sowie [[WordClock_mit_WS2812#ESP8266|ESP8266]] ESP01 gezogen werden.

Rechts ist der Anschluss eines ST-Link V2-Clones zum Flashen und die Anschluss-Skizze der WordClock an das [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]] zu sehen.
|| [[Datei:STM32F103C8T6.png|miniatur|STM32F103C8T6 Mini-Development Board]]
[[Datei:STM32F103C8T6 MiniDevBoard Schematic.png|mini|MiniDevBoard Schaltplan]]
[[Datei:STM32F103 MiniBoard STLink.jpg|mini|Flashen per ST-Link V2-Clone]]
[[Datei:WordClock24h-an-STM32F103-C8T6.png|mini|STM32F103C8T6 an STM32F103 Mini-Development Board]]
|}

== STM32F401RE Nucleo und STM32F411RE Nucleo ==
{|
|- style="vertical-align:top;"
| Es kann sowohl das 401er als auch das 411er [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] verwendet werden. Beide werden identisch genutzt.

Damit das Board später für den Einbau nur noch (incl. Shield) 2cm hoch ist, sollte man die überstehenden Enden der Steckerleisten auf der '''Unterseite''' mit einer Kneifzange kürzen. Die beiden Jumper auf der Unterseite (beim ST-Link-Device-Teil) können dabei auf die Oberseite gesteckt werden.

Es gibt mittlerweile drei verschiedene Revisionen von den Nucleo-Boards:

* "MB1136 C01": Der STM32F4x1 läuft nur mit dem ungenauen internen Oszillator
* "MB1136 C02 & C03": Der STM32F4x1 erhält seinen 8MHz Takt vom ST-Link-Device

Damit auch das Board mit der Revision "MB1136 C01" zuverlässig im HSE-Modus mit 84MHz läuft, sind folgende Hardware-Änderungen notwendig:

* Lötbrücken SB54 und SB55 entfernen (mit Lötkolben erhitzen und wegschnippen)
* Lötbrücken SB16 und SB50 entfernen (dito)
* R35 und R37 jeweils mit einem Stück Draht oder 0R-Widerstand bestücken
* Quarz X3 (8 MHz) einlöten
* C33 und C34 mit jeweils 22pF bestücken.

C33 und C34 können auch normale THT-Bauteile sein, wenn man die Drähte vorher kürzt. Ich habe sie auf der Unterseite direkt an den Quarz-Anschlüssen angebracht, siehe Foto rechts. Es geht aber auch auf der Oberseite direkt an den dafür vorgesehenen Lötstellen - dann aber vorzugsweise mit 0603 SMD-Kondensatoren.

'''Man sollte auf jeden Fall erst die beiden Drahtbrücken R35 & R37 einlöten, bevor man den Quarz bestückt. Dann hat man wesentlich mehr Platz für den Lötkolben ;-)'''

Es empfiehlt sich jedoch, diese Änderungen auch mit dem Board der Revision "MB1136 C02" bzw. C03 durchzuführen, da wir später für die endgültige Uhr den ST-Link-Teil der Platine absägen werden. Dafür ist extra eine Bruchstelle vorgesehen. Nur so ist das Board dann schmal genug, damit es hinter den 7,5cm schmalen Rand der Frontplatte passt.

Nicht wundern: Je nach Revision des Boards sind einige der oben genannten Lötbrücken erst gar nicht bestückt. Dann braucht da auch nichts entfernt zu werden. Das hier beschriebene stellt also den gewünschten Endzustand dar.

Diese Arbeit ist in ca. 10 Minuten erledigt. Besondere SMD-Lötkenntnisse benötigt man dafür nicht.

Damit das Board (nach dem Abtrennen des ST-Link) über die Stiftleiste mit Spannung versorgt werden kann (z.B. durch das Nucleo-Shield), muss "JP5" noch von "U5V" auf "E5V" umgesteckt werden.
(Zusätzlich auf dem ST-Link "JP1" entfernen, falls noch nicht abgetrennt.)
|| [[Datei:WC24h-Nucleo-Oberseite.jpg|miniatur|Nucleo: Zusätzliche Drahtbrücken R35 + R37 + 8MHz Quarz]]
[[Datei:WC24h-Nucleo-Unterseite.jpg|miniatur|Nucleo: Zu entfernende Lötbrücken + anzulötende 22pf Kondensatoren]]
[[Datei:WC24h-Nucleo-Shield.jpg|miniatur|Prototyp-Shield für das Nucleo-Board mit TSOP, ESP8266 und 3,3V Spannungsregler, später noch Anschluss für EEPROM/RTC]]
|}

== Anschluss TSOP31238 ==

Zum optionalen Steuern per IR-Fernbedienung.

{|
|- style="vertical-align:top;"
| Anschlüsse am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

TSOP-Pin1 an GND, TSOP-Pin2 an 3,3 oder 5V, TSOP-Pin3 an PC10

Anschlüsse am [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

TSOP-Pin1 an GND, TSOP-Pin2 an 3,3V oder 5V, TSOP-Pin3 an PB3

Dabei ist vorzugsweise ein Tiefpassfilter (C/R) - wie auch im Datenblatt angegeben - zu verwenden. Siehe dazu auch Schaltbild rechts.

'''Wird kein IRMP-Empfänger benutzt, sollte ein 100 kOhm Pullup-Widerstand am Eingangspin des µC-Eingangs angeschlossen werden.'''

|| [[Datei:irmp-empfaenger.png|miniatur|Anschluß eines IR-Empfängers an µC]]
|}

== Anschluss WS2812 ==
Bei der WordClock24h wird eine 16x18-Matrix verwendet, bei der WordClock12h eine 10x11-Matrix.

Die [[WordClock_mit_WS2812#WS2812|WS2812]]-LEDs werden dabei folgendermaßen verdrahtet:

==== Anschluss WS2812-Streifen für WordClock12h ====

Hier wird eine Spezialanfertigung von WS2812-Stripes eingesetzt - nämlich mit einem Rastermaß von 28,1mm. Damit ist die WordClock12h von den Maßen her kompatibel zum bisherigen [[Word_Clock]]-Projekt. Das hat den Vorteil, dass bisherige Frontplatten und Zwischenböden weiterverwendet werden können.

Bei der Wordclock12h steht jeder zweite Streifen "auf dem Kopf":

M4 +-------+ M1
O---------+ µC --------| R220 |--------O
| | +-------+ |
| | |
| 1 2 3 4 ... 11 |
| O--O--O--O--O--O--O--O--O--O--O--+ |
| | |
| 22 12 | |
| O--O--O--O--O--O--O--O--O--O--O--+ |
| | |
| | |
| O--O--O--O--O--O--O--O--O--O--O-- |
| 23 24 .... |
| |
| |
O----------------------------------------------------O
M3 M2

[[Datei:LEDS-Datakabel.jpg|miniatur]]
 

Dabei sind M1-M4 die 4 Minutenpunkte in den Ecken. Es wird keine Status-LED wie bei der WordClock24 verwendet. Tatsächlich werden hier dafür die Minutenpunkte zur zusätzlichen Statusausgabe mitbenutzt.

Beim Nucleo-Board werden bis zu 100 weitere LEDs, beim STM32-Mini-Board werden 60 weitere LEDs als Ambilight hinter der Buchstabenkette unterstützt. Diese müssen einfach hinter der LED für den letzten Buchstaben in der Kette angeschlossen werden. Die Anzahl ist variabel, maximal 100/60 Ambilight-LEDs sind möglich. Wegen des Ambilight-Modus' "Clock" (ab Software-Version 2.0.0) sind exakt 60 LEDs als Ambilight sinnvoll - auf jeder Seite 15. Dann können diese nämlich zur Sekunden-Anzeige verwendet werden.

==== Anschluss WS2812-Streifen für WordClock24h ====
Verwendet werden Standard-WS2812-Stripes mit '''60 LEDs pro Meter'''. Dabei steht - wie bei der WC12h - jeder zweite Streifen "auf dem Kopf":

+-------------------------------------------------------+
| |
1 2 3 4 ... 18 |
O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--+ |
| |
36 20 19 | |
O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--+ |
| |
| |
O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O-- |
37 38 .... |
|
|
+-------+ Status-LED |
µC -------| R220 |------------------O-------------------------------+
+-------+

Auch hier können bis zu 100 Ambilight LEDs beim Nucleo Board, bis zu 60 Ambilight LEDs beim STM32-Mini-Board, hinter der LED für den letzten Buchstaben in der Kette angeschlossen werden. Wegen des Ambilight-Modus' "Clock" (ab Software-Version 2.0.0) sind exakt 60 LEDs als Ambilight sinnvoll - auf jeder Seite 15. Dann können diese nämlich zur Sekunden-Anzeige verwendet werden.

Anschlüsse am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* Stripe +5V an externe Stromversorgung +5V
* Stripe DI über einen Serienwiderstand von 220 Ohm an PC6
* Stripe GND an externe Stromversorgung GND und(!) an GND des Boards

Anschlüsse am [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* Stripe +5V an externe Stromversorgung +5V
* Stripe DI über einen Serienwiderstand von 220 Ohm an PA8
* Stripe GND an externe Stromversorgung GND und(!) an GND des Boards

== Anschluss Temperatur-Sensor ==
'''Optional:''' [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]] als Temperatur-Sensor

Es werden unterstützt:

* DS1820
* DS18S20
* DS1822
* DS18B20

Anschlüsse am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* DS18xx-GND (Pin 1) an GND
* DS18xx-DQ (Pin 2) an PD2 und über Pullup 4,7k an DS18xx-VDD
* DS18xx-VDD (Pin 3) an Board-interne oder externe 3,3V

Anschlüsse am STM32F103 [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* DS18xx-GND (Pin 1) an GND
* DS18xx-DQ (Pin 2) an PB5 und über Pullup 4,7k an DS18xx-VDD
* DS18xx-VDD (Pin 3) an Board-interne oder externe 3,3V

Aufgrund der geringen Eigenerwärmung der DS18XX Sensoren wird empfohlen, den Sensor mit Wärmeleitpad/-kleber auf ein kleines Kühlblech zu kleben.

'''Ist kein DS18xx Temperatur-Sensor angeschlossen, wird die Temperatur über die RTC (DS3231) ermittelt.'''

== Anschluss LDR ==

'''Optional''': Fotowiderstand (LDR) zur Lichtstärkenmessung was eine Variation der Leuchtstärke der LEDs in Abhängigkeit des Umgebungslichtes ermöglicht.

Schaltung:

AGND -----+
|
R = 10K
|
µC ------+
|
LDR (Reichelt: "A 906032")
|
3,3V -----+

Wird noch der alte LDR07 von Reichelt eingesetzt, ist R = 1K besser.

Anschluss am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]: PC4
Anschluss am STM32F103 Board: PA5

'''Wird kein [[WordClock_mit_WS2812#LDR|LDR]] benutzt, muss der µC-Eingang per 10k-Pullup auf 3,3V gelegt werden!'''

== DCF77 ==

'''Optional''': DCF77 Modul

Anschlüsse am Nucleo Board:

* DCF77 GND an GND
* DCF77 V+ an 3,3V
* DCF77 Out an PC11
* DCF77 PON an PC12

Anschlüsse am STM32F103 Mini Development Board:

* DCF77 GND an GND
* DCF77 V+ an 3,3V
* DCF77 Out an PB8
* DCF77 PON an PB9

Getestet wurde die Software mit dem Reichelt-DCF77-Modul, das aber lediglich ein befriedigendes Empfangsverhalten hat. PON kann beim Reichelt-Modul offen bleiben, beim Pollin DFCF77-1 sollte man PON jedoch anschließen.

Wird ein DCF77-Modul benutzt, welches einen Open-Collector-Ausgang verwendet, muss an PC11 noch ein 100k Pullup (zu 3,3V) angeschlossen werden.

'''Wird KEIN DCF-Modul verwendet, sollte der µC-Eingang per 100k Pullup auf 3,3V gelegt werden!'''

== Anschluss ESP8266 ==

'''Optional''': [[WordClock_mit_WS2812#ESP8266|ESP8266]] ESP-01: WLAN Modul

[[Datei:WC24h-ESP8266-ESP-01.png|miniatur|Anschlussbelegung ESP8266 ESP-01 - Bauteilseite!]]

Anschlüsse [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* ESP8266 GND an GND
* ESP8266 VCC an '''externe''' 3,3V (Vorsicht: Modul zieht bis zu 200mA!)
* ESP8266 CH_PD an PA6
* ESP8266 RST an PA7
* ESP8266 GPIO0 an PA4 ('''NEU!''')
* ESP8266 TXD an USART6 RX (PA12)
* ESP8266 RXD an USART6 TX (PA11)

Anschlüsse [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* ESP8266 GND an GND
* ESP8266 VCC an '''externe''' 3,3V (Vorsicht: Modul zieht bis zu 200mA!)
* ESP8266 CH_PD an PA1
* ESP8266 RST an PA0
* ESP8266 GPIO0 an PA4 ('''NEU!''')
* ESP8266 TXD an USART2 RX (PA3)
* ESP8266 RXD an USART2 TX (PA2)

'''Wird KEIN [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul verwendet, ist nichts weiter zu beachten, da die Erkennung automatisch erfolgt.'''

== Anschluss RTC und EEPROM ==

I2C-Modul mit DS3231 als RTC und EEPROM

[[Datei:WC24h-DS3231-EEPROM.png|miniatur|DS3231 RTC + EEPROM]]

Dieses Modul (siehe auch Foto rechts) findet man bei eBay oder Amazon ab ca. 2 EUR, wenn man als Suchbegriff "DS3231 EEPROM" eingibt. Es wird als Echtzeituhr und für die Speicherung der Konfigurationsparameter verwendet. Ist kein DS18xx als Temperatursensor angeschlossen, wird die RTC auch zur Temperaturmessung genutzt.

Anschlüsse [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* I2C GND an GND
* I2C VCC an Board-interne oder externe 3,3V
* I2C SCL an PA8
* I2C SDA an PC9

Anschlüsse [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* I2C GND an GND
* I2C VCC an Board-interne oder externe 3,3V
* I2C SCL an PB6
* I2C SDA an PB7

'''NEU: AB Version 1.0 werden auch ältere [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC/EEPROM]]-Module mit DS1307 erkannt.'''

Da die Module aus China teilweise auch ohne bestückte Batterien gesendet werden, sollte man sich
genau überlegen, ob man die Batterie CR2032 oder den Akku LiR2032 einbaut.

Sind sowohl die Diode 1N4148 als auch der Widerstand neben dem [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]-IC bestückt, dann kann man auch den Akku (relativ teuren) LiR2032 einsetzen. In diesem Fall muss das Modul aber mit +5V statt 3,3V betreiben, damit der Akku überhaupt geladen wird. Sonst ist er aufgrund der Selbstendladung irgendwann leer.

Sinnvollerweise sollte man das Modul eher mit einer CR2032 Batterie betreiben. '''Dann sollte man aber sicherheitshalber die Diode oder den Widerstand (neben der Diode) auf dem Modul entfernen (falls vorhanden, siehe Bild), damit keine Ladung (und Überhitzung) der Batterie passiert'''. Das ist zwar eigentlich erst ab einer Betriebsspannung von ca. 3,7V möglich, aber sicher ist sicher. Im Normalfall reicht eine CR2032 Batterie für 5-10 Jahre.

== Anschluss USB-UART-Adapter ==

Man benötigt in folgenden Fällen einen USB-UART-Adapter:

* Logging der Meldungen auf dem PC
* Flashen des ESP8266 über das verwendete STM32-Board

Beim Nucleo ist ein USB-UART-Adapter bereits integriert - und zwar im oberen ST-Link-V2-Teil des Boards. Hier ist also kein weiterer Anschluss notwendig. Erst wenn das ST-Link-V2-Teil vom Rest des Boards abgetrennt wird, müssen RX und TX wieder verbunden werden, wenn man den UART-Adapter nutzen will. Also einfach das Board mit dem PC über USB verbinden - fertig. Eventuell muss man noch den STM32 Virtual COM Port Driver installieren. Der entsprechende Link zum Herunterladen steht unter [[WordClock_mit_WS2812#Download|Download]].

Beim Mini-Development Board wird ein externer USB-UART-Adapter benötigt. Dabei schließt man ihn folgendermaßen an:

* USB-UART TX an PA10 (RX)
* USB-UART RX an PA9 (TX)
* UAB-UART GND an GND

Solche Adapter (am besten einen, der mit 3,3V-Pegeln arbeitet) gibt es bei eBay oder Amazon für unter 5 EUR.

== Anschlusstabelle ==

{| {{Tabelle}}
|+ '''Anschlüsse'''
|- style="background-color:#eeeeee"
! Device || [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] || [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]
|-
| [[WordClock_mit_WS2812#TSOP31238|TSOP31238]] ([[IRMP]]) || GPIO: PC10 || GPIO: PB3
|-
| [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]] || GPIO: PD2 || GPIO: PB5
|-
| [[WordClock_mit_WS2812#LDR|LDR]] || GPIO: PC4 || GPIO: PA5
|-
| WordClock-Logger (USB) || USART2: TX=PA2 RX=PA3 (bereits integriert) || USART1: TX=PA9 RX=PA10 (externer USB-UART-Adapter)
|-
| [[WordClock_mit_WS2812#ESP8266|ESP8266]] (UART) || USART6: TX=PA11 RX=PA12 || USART2: TX=PA2 RX=PA3
|-
| [[WordClock_mit_WS2812#ESP8266|ESP8266]] (GPIO) || GPIO: RST=PA7 CH_PD=PA6 || GPIO: RST=PA0 CH_PD=PA1
|-
| [[WordClock_mit_WS2812#ESP8266|ESP8266]] (FLASH) || GPIO: GPIO0=PA4 ('''NEU ab V1.8.0''') || GPIO: GPIO0=PA4 ('''NEU ab V1.8.0''')
|-
| [[WordClock_mit_WS2812#DCF77|DCF77]] || GPIO: DATA=PC11 PON=PC12 || GPIO: DATA=PB8 PON=PB9
|-
| [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC / EEPROM]] || I2C3: SCL=PA8 SDA=PC9 || I2C1: SCL=PB6 SDA=PB7
|-
| [[WordClock_mit_WS2812#WS2812|WS2812]] || DMA1: PC6 || DMA1: PA8
|}

Auf dem Nucleo-Board ist USART2 bereits fest mit dem auf dem ST-Link-V2-Teil des Boards integrierten UART-USB-Adapter verbunden. Hier sind also keine extra Verbindungen mehr notwendig - erst wenn das ST-Link-V2-Teil abgesägt wird. Und auch dann kann man den USB-UART-Adapter vom ST-Link-V2 weiterverwenden.

Beim Mini-Development Board benötigt man allerdings einen externen USB-UART-Adapter - am besten einen, der mit 3,3V-Pegeln arbeitet. Diese findet man zuhauf bei Amazon oder eBay für ca. 5 EUR.

----

== Teileliste für WC12h oder WC24h und Bezugsquellen ==

{| class="wikitable"
|-
! style="width:35%" | Bezeichnung || Bezugsquelle
|-
| Board
||
STM32 MiniBoard (empfohlen für WC12h) 
[http://www.aliexpress.com/wholesale?&SearchText=STM32F103C8T6 AliExpress] 
[http://www.ebay.de/sch/i.html?&_nkw=STM32F103C8T6 eBay] 
[http://www.watterott.com/de/STM32F103C8T6-Minimum-System-Board Watterott] 
'''oder''' 
STM32 Nucleo 
[http://www.aliexpress.com/wholesale?&SearchText=nucleo AliExpress] 
[http://www.ebay.de/sch/i.html?&_nkw=STM32F411%20Nucleo eBay] 
[http://www.watterott.com/de/Nucleo-STM32F411 Watterott]
|-
| USB-UART-Adapter - NUR für MiniBoard in Kombination mit ESP8266-WLAN-Modul notwendig
|| [http://www.ebay.de/sch/i.html?&_nkw=USB%20UART%20Adapter eBay]
|-
| STM32 ST-Link - NUR für MiniBoard notwendig
|| 
Prinzipiell reicht USB-UART-Adapter aus aber ein ST-Link wird zusätzlich empfohlen: 
[http://www.aliexpress.com/wholesale?&SearchText=st-link+v2 AliExpress] 
[http://www.ebay.de/sch/i.html?&_nkw=ST-Link%20v2 eBay]
|-
| STM32 MiniBoard Shield - NUR für MiniBoard notwendig
|| Das per [[WordClock_mit_WS2812#Sammelbestellung_LED_Stripes.2C_Zwischenb.C3.B6den.2C_Shields | Sammelbestellung]] erhältliche Shield enthält sämtliche Anschlüsse um alle benötigten Module mit einander zu verbinden. Der STM32F103 wird direkt in das Shield gesteckt und verlötet - er wird nicht gesockelt! 
Folgende Komponenten werden (zusätzlich zu den bei LDR, TSOP31238, DS1820 genannten) für den Aufbau der Shield benötigt: 
[http://www.reichelt.de/METALL-220/3/index.html?&ACTION=3&LA=446&ARTICLE=11627&artnr=METALL+220 Reichelt Widerstand 220 Ohm] 
[https://www.conrad.de/de/metallschicht-widerstand-220-axial-bedrahtet-0207-06-w-yageo-mf0207fte52-220r-1-st-1417626.html Conrad Widerstand 220 Ohm] 
[http://www.reichelt.de/RAD-105-4-7-100/3/index.html?&ACTION=3&LA=446&ARTICLE=44857&artnr=RAD+105+4%2C7%2F100 Reichelt Elko 4,7uF] 
[https://www.conrad.de/de/elektrolyt-kondensator-radial-bedrahtet-25-mm-47-f-100-vdc-20-x-h-5-mm-x-11-mm-yageo-se100m4r70azf-0511-1-st-445587.html Conrad Elko 4,7uF] 
[http://www.reichelt.de/METALL-10-0K/3/index.html?&ACTION=3&LA=446&ARTICLE=11449&artnr=METALL+10%2C0K Reichelt Widerstand 10,0k] 
[https://www.conrad.de/de/metallschicht-widerstand-10-k-axial-bedrahtet-0207-06-w-1-st-418374.html Conrad Widerstand 10,0k] 
[http://www.reichelt.de/KERKO-100N/3/index.html?&ACTION=3&LA=446&ARTICLE=9265&artnr=KERKO+100N 2x Reichelt Kerko 100nF] 
[https://www.conrad.de/de/keramik-kondensator-radial-bedrahtet-100-nf-50-vdc-10-holystone-rdcx104k050dka-1-st-531855.html 2x Conrad Kerko 100nF] 
[http://www.reichelt.de/MPE-094-2-008/3/index.html?&ACTION=3&LA=446&ARTICLE=119928&artnr=MPE+094-2-008 Reichelt Buchsenleiste 8 polig] 
[https://www.conrad.de/de/buchsenleiste-standard-anzahl-reihen-2-polzahl-je-reihe-4-mpe-garry-156-3-008-0-nfx-ys0-1-st-741222.html Conrad Buchsenleiste 8 polig] 
[http://www.reichelt.de/SL-1X36G-2-54/3/index.html?&ACTION=3&LA=446&ARTICLE=19504&artnr=SL+1X36G+2%2C54 Reichelt Stiftleiste gerade 36-polig] 
[https://www.conrad.de/de/stiftleiste-standard-anzahl-reihen-1-polzahl-je-reihe-36-connfly-1-st-1390107.html Conrad Stiftleiste gerade 36-polig] 
[http://www.reichelt.de/SL-1X36W-2-54/3/index.html?&ACTION=3&LA=446&ARTICLE=19505&artnr=SL+1X36W+2%2C54 Reichelt Stiftleiste gewinkelt 36-polig] 
[https://www.conrad.de/de/stiftleiste-standard-anzahl-reihen-1-polzahl-je-reihe-36-bkl-electronic-10120185-1-st-741373.html Conrad Stiftleiste gewinkelt 36-polig] 
[http://www.reichelt.de/WSL-16G/3/index.html?&ACTION=3&LA=446&ARTICLE=22822&artnr=WSL+16G Reichelt Wannenstecker 16-polig] 
[https://www.conrad.de/de/stiftleiste-rastermass-254-mm-polzahl-gesamt-16-w-p-products-1-st-739616.html Conrad Wannenstecker 16-polig] 
[http://www.reichelt.de/PFL-16/3/index.html?&ACTION=3&LA=446&ARTICLE=14573&artnr=PFL+16 Reichelt Pfostenstecker 16-polig] 
[https://www.conrad.de/de/pfosten-steckverbinder-steckverbinder-besonderheiten-mit-zugentlastung-rastermass-254-mm-polzahl-gesamt-16-connfly-1-st-1389904.html Conrad Pfostenstecker 16-polig] 
[http://www.reichelt.de/AKL-101-02/3/index.html?&ACTION=3&LA=446&ARTICLE=36605&artnr=AKL+101-02 Reichelt Anschlußklemme 2-polig] 
[https://www.conrad.de/de/schraubklemmblock-2-mm-polzahl-2-dg126-50-02p-14-00ah-degson-gruen-1-st-1327203.html Conrad Anschlußklemme 2-polig] 
ohne IRMP (TSOP31238) wird folgender Widerstand als PullUp empfohlen: 
[http://www.reichelt.de/METALL-100K/3/index.html?&ACTION=3&LA=446&ARTICLE=11458&artnr=METALL+100K Reichelt Widerstand 100 kOhm] 
ohne DCF wird folgender Widerstand als PullUp benötigt: 
[http://www.reichelt.de/METALL-100K/3/index.html?&ACTION=3&LA=446&ARTICLE=11458&artnr=METALL+100K Reichelt Widerstand 100 kOhm] 
mit DCF werden folgende Teile für die Stabilisierungsschaltung benötigt: 
[http://www.reichelt.de/METALL-680/3/index.html?&ACTION=3&LA=446&ARTICLE=11942&artnr=METALL+680 Reichelt Widerstand 680 Ohm] 
[http://www.reichelt.de/LM-358-DIP/3/index.html?&ACTION=3&LA=446&ARTICLE=10483&artnr=LM+358+DIP Reichelt Operationsverstärker LM358] 
[http://www.reichelt.de/GS-8P/3/index.html?&ACTION=3&LA=446&ARTICLE=8231&artnr=GS+8P Reichelt IC-Sockel 8polig] 
[http://www.reichelt.de/LED-5MM-2MA-RT/3/index.html?&ACTION=3&LA=446&ARTICLE=21627&artnr=LED+5MM+2MA+RT Reichelt LED 5mm low current] 
|-
| STM32 Nucleo Shield - NUR für Nucleo-Board notwendig
|| Diese per [[WordClock_mit_WS2812#Sammelbestellung_LED_Stripes.2C_Zwischenb.C3.B6den.2C_Shields | Sammelbestellung]] erhältliche Adapterplatine wird auf das Nucleo-Board aufgesteckt. Sie enthält sämtliche Anschlüsse für alle vorgesehen Module. 
Die zusätzlich für den Aufbau des Shield benötigten Komponenten sind in einem Reichelt Warenkorb zusammengefasst: 
[https://secure.reichelt.de/index.html?&ACTION=20&LA=5010&AWKID=1198506&PROVID=2084 Reichelt Warenkorb]
|-
| WS2812 LED Stripes
|| Für die WC12h sind Stripes mit einem Sonderformat über die [[WordClock_mit_WS2812#WC12h_Sammelbestellung_LED_Stripes_und_Zwischenb.C3.B6den|Sammelbestellung]] erhältlich. 
Für die WC24h können Standard Stiles mit 60 LEDs / Meter verwendet werden. 
[http://www.aliexpress.com/wholesale?&SearchText=ws2812+60+ip30 AliExpress] 
[http://www.ebay.de/sch/i.html?&_nkw=WS2812%2060%20ip30 eBay]
|-
| Frontplatte
|| Für die WC12h sind Frontplatten über eine Sammelbestellung aus [[WordClock_mit_WS2812#WC12h_Sammelbestellung_Frontplatten | Plexiglas ]] oder [[Word_Clock#Sammelbestellung_.28Edelstahl.29 | Edelstahl]] erhältlich. 
Für die WC24h gibt es eine Sammelbestellung von Frontplatten aus
[[WordClock_mit_WS2812#WC24h_Sammelbestellung_Frontplatten | Plexiglas]]. 
Wird kein Rahmen (siehe unten) verwendet werden zusätzliche Teile (z.B. [[Word_Clock_Variante_1_-_getrennte_Steuerplatine#Befestigung_der_Frontplatte_.28.E2.80.9CPlexiglasvariante.E2.80.9D.29_an_der_Zwischenplatte| Magnete]]) zur Befestigung der Frontplatte benötigt.
|-
| Zwischenboden
|| Für die WC12h und WC24h sind Zwischenböden über eine [[WordClock_mit_WS2812#Sammelbestellung_LED_Stripes.2C_Zwischenb.C3.B6den.2C_Shields | Sammelbestellung]] erhältlich. 
|-
| Alu-Platte
|| Aluminiumblech, 1 mm Stärke. Für WC24h mit neuem Zwischenbodens ("V2") und alle WC12h Maße 310mmx310mm, für WC24h mit "altem" Zwischenboden 300mmx300mm 
[http://www.ebay.de/sch/(aluminium%2C+alu)+(blech%2C+platte) ebay]
 
|-
| DS3231 RTC
|| [http://www.aliexpress.com/wholesale?&SearchText=ds3231 AliExpress]
[http://www.ebay.de/sch/i.html?&_nkw=DS3231 eBay] 
Falls bei dem Modul keine Batterie mitgeliefert wird, wird zusätzlich folgende Knopfzelle benötigt:
[http://www.reichelt.de/directlink/CR2032/index.html?&ACTION=3&ARTICLE=26550&GROUPID=4241&ARTNR=CR+2032&&SHOW=1&SID=12UXp5iH8AAAIAAAE-gdod799e4cf62d5cd255e52464fe671b8ea Reichelt CR2032]
|-
| Netzteil
|| [http://www.pollin.de/shop/dt/NjQ1ODQ2OTk-/Stromversorgung/Netzgeraete/Festspannungs_Netzgeraete/Schaltnetzteil_FSP020_DGAA1_5_V_4_A.html Pollin Netzteil 5V 4A] 
|-
| Optional: ESP8266 ESP-01 (WLAN-Modul)
|| [http://www.aliexpress.com/wholesale?&SearchText=esp8266%20esp-01 AliExpress] 
[http://www.ebay.de/sch/i.html?&_nkw=esp8266%20ESP-01 eBay] 
[http://www.watterott.com/de/ESP8266-WiFi-Serial-Transceiver-Modul Watterott] 

Zum Anschließen des ESP8266 ESP-01 wird zusätzlich ein AMS1117 3,3 V Drop Down Spannungsregler benötigt:
 [http://www.aliexpress.com/wholesale?&SearchText=ams1117%203.3V AliExpress] 
[http://www.ebay.de/sch/i.html?&_nkw=AMS1117%203.3V eBay]
|-
| Optional: Infrarot-Decoder (IRMP)
|| [http://www.reichelt.de/TSOP-31238/3/index.html?&ACTION=3&LA=446&ARTICLE=107210&artnr=TSOP+31238&SEARCH=TSOP31238 Reichelt TSOP31238]
[http://www.reichelt.de/RAD-105-4-7-100/3/index.html?&ACTION=3&LA=446&ARTICLE=44857&artnr=RAD+105+4%2C7%2F100&SEARCH=rad+105+4%2C7%2F100 Reichelt Elko 4,7uF] 
[http://www.reichelt.de/METALL-100/3/index.html?&ACTION=3&LA=446&ARTICLE=11457&artnr=METALL+100&SEARCH=metall+100 Reichelt Widerstand 100 Ohm] 
 
Zusätzlich wird noch eine [http://www.dx.com/p/24-key-wireless-infrared-ir-remote-controller-for-rgb-led-light-bulb-1-cr2025-47019#.V0CsuCFgfs0 IR-Fernbedienung] benötigt, die optional mit einer [[WordClock_mit_WS2812#IR-Fernbedienung|Folie]] versehen werden kann.
|-
| Optional: Rahmen
||
Innenmaße 450x450 mm 
Funktioniert nicht zusammen mit Ambilight 
Z. B. [https://www.alutech.de/alu---zuschnitt-profil-18.html Alurahmen]
|-
| Optional: Ambilight
||Mittels zusätzlicher WS2812 LED Stripes per [[WordClock_mit_WS2812#Sammelbestellung_LED_Stripes.2C_Zwischenb.C3.B6den.2C_Shields | Sammelbestellung]]
Funktioniert nicht zusammen mit einem Rahmen. Erfordert Zwischenboden mit entsprechender Ausfräsung (bisher nur für WC12 per Sammelbestellung verfügbar)
|-
| Optional: Fotowiderstand (LDR) zur Lichtmessung
|| [http://www.reichelt.de/A-906032/3/index.html?&ACTION=3&LA=446&ARTICLE=47510&artnr=A+906032&SEARCH=fotowiderstand Reichelt A 906032] 
[http://www.reichelt.de/METALL-1-00K/3/index.html?&ACTION=3&LA=446&ARTICLE=11403&artnr=METALL+1%2C00K&SEARCH=metall+1%2C00k Reichelt Widerstand 1,0k] (bei Verwendung des nicht mehr erhältlichen LDR07) 
[http://www.reichelt.de/METALL-10-0K/3/index.html?&ACTION=3&LA=446&ARTICLE=11449&artnr=METALL+10%2C0K&SEARCH=metall+10%2C0k Reichelt Widerstand 10,0k] (bei Verwendung des A 906032 und auch bei Nicht-Anschluss des LDRs)
|-
| Optional: Temperatur-Sensor
|| [http://www.reichelt.de/DS-18S20/3/index.html?&ACTION=3&LA=446&ARTICLE=7207&artnr=DS+18S20&SEARCH=ds1820 Reichelt DS1820]
[http://www.reichelt.de/METALL-4-70K/3/index.html?&ACTION=3&LA=446&ARTICLE=11784&artnr=METALL+4%2C70K&SEARCH=metall+4%2C70k Reichelt Widerstand 4,7k]
|-
| Optional: DCF77-Empfänger
|| [http://www.pollin.de/shop/dt/NTQ5OTgxOTk-/Bausaetze_Module/Module/DCF_Empfangsmodul_DCF1.html Pollin DCF77 Empfänger] 
|}

----

= Start =

Dieses Kapitel beschreibt den Download der Software auf das verwendete Board und die erstmalige Prüfung und Konfiguration.

Geflasht wird mit dem ST-Link-Programm, siehe oben.

Zur Überprüfung sämtlicher Funktionen und zur Konfiguration dient die [[WordClock_mit_WS2812#Web-Interface|Web-Oberfläche]]. Dazu nimmt man eine WLAN-Verbindung mit dem ESP8266-Modul auf. Für die erste Konfiguaration wird das ESP8266 zunächst als eigener Access-Point gestartet. Anschließend kann man über das [[WordClock_mit_WS2812#Web-Interface|Web-Interface]] die Zugangsdaten zu dem eigenen WLAN-Router einstellen. Im folgenden läuft das ESP8266-Modul dann als WLAN-Client.

Für Entwickler und zur Diagnose kann man man ein Terminal-Emulationsprogramm (wie zum Beispiel PuTTY) verwenden, um über ein Mini-USB-Kabel Debug- und Log-Meldungen mitzuschneiden. Laut http://www.mikrocontroller.net/topic/356203#3979181 sollte man dabei die "blauen" USB3.0-Buchsen möglichst meiden.

== Ablauf ==

* [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] und PC mit Mini-USB-Kabel verbinden (zum Flashen, Debuggen und als COM-Schnittstelle)
* Wenn man die EM::Blocks-IDE einsetzt: Nach [[WordClock_mit_WS2812#WordClock-Quellcode_selbst_.C3.BCbersetzen|Anleitung: WordClock-Quellcode selbst übersetzen]] vorgehen
* Die entsprechende Hex-Datei (aus dem Ordner wclock24h\bin\Release oder direkt hier herunterladen) flashen

----

== Logging ==

'''Dieser Ablauf ist nur notwendig, wenn man die Log-Meldungen aus Diagnose-Zwecken mitschneiden möchte.'''

* PuTTY starten
* PuTTY einstellen: Auswahl "Serial", Serial Line: COM11 (kann abweichen, s.u.), Speed: 115200
* Einen Session-Namen eingeben, z.B. "Nucleo"
* Auf SAVE klicken, dann kann man die Session später wieder auswählen
* Open anklicken
* RESET-Button am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] drücken

'''Wichtig für [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:''': Die COM-Schnittstelle ist immer aktiv, egal, ob das Programm gerade läuft oder nicht. Wird PuTTY erst nach dem Programmstart gestartet, sieht man im Terminal nicht die bereits ausgegebenen Log-Meldungen. Um den Ablauf des Programms von Anfang an zu verfolgen, drückt man auf dem Board einfach den Reset-Knopf. Dann beginnt die Ausgabe ganz von vorn.

Sollte man Probleme mit dem Finden der richtigen COM-Schnittstelle haben, hilft der Geräte-Manager aus der Systemsteuerung weiter.

Der Hintergrund im PuTTY ist normalerweise schwarz. Möchte man lieber eine Ausgabe in schwarz auf weiß, kann man das folgendermaßen umstellen:

Change Settings -> Window -> Colours:

Default Foreground: 2 2 2
Default Bold Foreground: 0 0 0
Default Background: 245 245 245
Default Bold Background: 255 255 255
Cursor Text: 0 0 0
Cursor Color: 255 0 0
(Rest kann man so lassen)

Anschließend zurück über "Session" oben links und: "Save".

----

== Konfiguration des WLAN-Moduls ==

=== Flash des WLAN-Moduls ===

{|
|- style="vertical-align:top;"
| Für das ESP8266-Wlan-Modul wird aus Stabilitäts- und Geschwindigkeitsgründen eine spezielle auf die WordClock-Anwendung abgestimmte Firmware benutzt (siehe [[WordClock_mit_WS2812#Download|Download]]), die über das STM32-Board geflasht werden kann. Das ESP8266 kann also während des Flashens in der WordClock-Schaltung verbleiben.

Beim Nucleo wird der integrierte USB-UART-Adapter verwendet. Beim Anschluss des Nucleo-Board per USB an den PC wird automatisch ein COM-Device angelegt, z.B. COM12. Dafür braucht man aber den entsprechenden Virtual COM Port Driver, siehe [[WordClock_mit_WS2812#Software_f.C3.BCr_Windows|Software für Windows]].

Beim [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103 Mini Development Board]] wird ein externer USB-UART-Adapter, welcher mit 3,3V-Pegeln arbeitet, verwendet. Wie er angeschlossen wird, sieht man in der [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|Anschluss-Skizze]] und auch in obiger [[WordClock_mit_WS2812#Anschlusstabelle|Anschlusstabelle]].

Zum eigentlichen Flashen lädt man am besten das sehr einfach gehaltene Programm '''[https://github.com/Stadslab/ESP8266_example/raw/master/ESP8266_flasher_V00170901_00_Cloud%20Update%20Ready/esp8266_flasher.exe esp8266_flasher.exe]''' herunter.

|| [[Datei:WordClock-ESP-Flasher.png|miniatur|esp8266_flasher.exe für das ESP8266-Modul]]
|}

{|
|- style="vertical-align:top;"
| Alternativ dazu kann man auch von der Espressif-Seite zunächst die ESP8266-Flash-Software '''FLASH_DOWNLOAD_TOOLS_v2.4_150924.rar''' (http://bbs.espressif.com/download/file.php?id=856) herunterladen und das Archiv an geeigneter Stelle entpacken. Es müssen dann als Einstellungen die im Bild rechts markierten Einstellungen vorgenommen werden.

Dann ist das weitere Vorgehen:

* Eventuell gestartetes PuTTY beenden, um COM-Schnittstelle freizugeben
* Reset-Taste drücken und '''festhalten'''
* Blaue User-Taste auf dem Nucleo-Board drücken und '''festhalten''', alternativ beim STM32F103-Mini-Development Board PA6 mit einem Taster mit Masse verbinden und '''festhalten'''
* Reset-Taste loslassen
* User-Taste nach 2 Sekunden loslassen

Das WordClock-Programm auf dem STM32 versetzt dann das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul in den Flash-Modus und verbindet dann die beiden UARTs softwaremäßig 1:1, d.h. die Daten werden vom USB-Anschluss transparent an das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul weitergegeben.

Nun startet man das Programm '''esp8266_flasher.exe''' (bzw. ESP_DOWNLOAD_TOOL_V2.4.exe) und wählt durch Klick auf die Schaltfläche '''Bin''' die Datei '''ESP-WordClock.bin''' aus - siehe [[WordClock_mit_WS2812#Download|Download]]. Außerdem muss der COM-Port an den tatsächlichen Anschluss angepasst werden.

|| [[Datei:WC-ESP8266-FLASH.png|miniatur|Alternative: ESP FLASH DOWNLOAD TOOL]]
|}

Nach Drücken auf '''Download''' (bzw. '''Start''' beim Alternativprogramm) sollte nun das Flashen des [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Moduls beginnen. Eine eventuell am Ende auftretende Fehlermeldung "Failed to leave Flash mode" kann dabei getrost ignoriert werden. Anschließend startet man den STM32 (und damit auch das WLAN-Modul) neu durch kurzes Drücken der Reset-Taste.

=== Start als Access-Point ===

Um für die Konfiguration der WLAN-Daten (Zugang zum WLAN-Router oder -Gateway) mit dem ESP8266 Kontakt aufzunehmen, muss man zunächst dafür sorgen, dass das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul als Access-Point arbeitet. Dafür drückt man die blaue User-Taste auf dem Nucleo-Board, alternativ verbindet man beim STM32F103-Mini-Development Board PA6 kurz über einen Taster mit Masse.

Unmittelbar nach dem Drücken der Taste erscheint die IP-Adresse des [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Moduls als Laufschrift - und auch im Log. Nun sucht man auf dem PC oder Tablet nach dem WLAN-Netz mit dem Namen "wordclock" und verbindet das Gerät mit diesem Netz. Als Netzwerkschlüssel gibt man "1234567890" ein. Sobald die Verbindung hergestellt ist, startet man einen Browser und gibt als URL die ausgegebene IP-Adresse ein, z.B. http://192.168.4.1/ .

'''Hinweis: Durch einen Anzeigefehler in der aktuellen ESP-Firmware 2.1.0 könnte an dieser Stelle auch fälschlicherweise "0.0.0.0" als IP-Adresse ausgegeben werden. In diesem Fall ist die zu verwendende IP-Adresse 192.168.4.1.'''

Sobald die [[WordClock_mit_WS2812#Web-Interface|Web-Oberfläche]] erscheint, wählt man den Menüpunkt "Network" aus, wählt "Wlan-Client" aus und gibt die SSID ("AP") und den Key des WLAN-Routers ein und bestätigt die Eingabe mit "Save". Das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-WLAN-Modul wird nun als WLAN-Client umkonfiguriert. War das erfolgreich, erscheint nun auf dem Display die neue IP-Adresse. Die Browser-Seite wird dann ungültig. Man kann seinen PC nun wieder mit dem bisherigen WLAN-Gateway verbinden und im folgenden die neue IP-Adresse verwenden.

Gibt es an dem Ort, wo die Uhr betrieben werden soll, kein WLAN, kann das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-WLAN-Modul auch weiterhin als Accesspoint ("AP") betrieben werden, damit man es über WLAN fernsteuern kann. In diesem Fall sollte nicht "WLAN-Client", sondern "AP" ausgewählt werden, eine entsprechende SSID und einen mindestens 10 Zeichen langen Key einstellen. Anschließend kann man sich mit PC/Handy/Tablet in das neue WLAN einklinken, um die Uhr per Browser oder Android-App fernzusteuern. Ein Zugriff auf einen externen Timeserver ist dann selbstverständlich nicht mehr möglich.

=== Start als WLAN-Client ===

Bei jedem folgenden Start wird nur noch die Einstellung "WLAN-Client" verwendet. Sobald sich das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-WLAN-Modul mit dem gewünschten Access-Point ("AP") verbunden hat, wird auf dem LED-Display die neue IP-Adresse des Moduls in Laufschrift ausgegeben.

'''Tipp''': Viele WLAN-Router sorgen automatisch dafür, dass ein WLAN-Client auch noch nach Tagen dieselbe IP-Adresse hat. Wenn das nicht der Fall sein sollte, kann man meist in den Router-Einstellungen dafür sorgen, dass der Client mit der MAC-Adresse xx-xx-xx-xx-xx-xx immer dieselbe IP-Adresse vom WLAN-Router zugeteilt bekommt.

----

== Web-Interface ==

=== Main ===
{|
|- style="vertical-align:top;"
| Neben der Ausgabe der installierten Firmware-Version sieht man hier unter anderem auch, ob das EEPROM erkannt wurde. Es wird entweder "online" oder "offline" ausgegeben.

Hat man keine Verbindung zum Internet, kann man auf der Hauptseite Datum und Uhrzeit auch manuell eingeben. Außerdem kann man hier einen Ticker-Text angeben, welcher dann auf dem Display als Laufschrift ausgegeben wird.

Mit den Schaltflächen "Power on" bzw. "Power off" kann das LED-Display ein- und ausgeschaltet werden. Mit dem Klick auf "Learn IR remote control" kann eine IR-Fernbedienung angelernt werden.
|| [[Datei:Wordclock24h-Web-Main.png|miniatur|Web-Interface: Hauptmenü]]
|}

=== Network ===
{|
|- style="vertical-align:top;"
| Hier wird die aktuelle IP-Adresse und die Firmware-Version des ESP8266-Moduls angezeigt. Auch kann man hier die Verbindung zu einem WLAN-Gateway oder -Router eingeben. In diesem Fall ist der Modus von "AP" auf "WLAN-Client" umzustellen und SSID und Key einzugeben. Nach Änderung wird die gewünschte Verbindung aufgebaut und die evtl. neue IP-Adresse auf dem LED-Display als Laufschrift eingeblendet.

Ebenso kann man hier den [[WordClock_mit_WS2812#Timeserver|Timeserver]] und die [[WordClock_mit_WS2812#Timeserver|Zeitzone]] konfigurieren, siehe entsprechendes [[WordClock_mit_WS2812#Timeserver|Kapitel]].

Mit der Schaltfläche "Get net time" kann die aktuelle Uhrzeit von dem konfigurierten Timeserver ad hoc abgerufen werden. Das ist aber im Normalfall nicht notwendig, da dies ohnehin alle 3800 Sekunden automatisch geschieht.
|| [[Datei:Wordclock24h-Web-Network.png|miniatur|Web-Interface: Netzwerk-Konfiguration]]
|}

=== Temperature ===
{|
|- style="vertical-align:top;"
|
Hier wird die aktuelle Temperatur von RTC und DS18xx (sofern vorhanden) ausgegeben.

Wegen der Selbsterwärmung der Sensoren werden meist zu hohe Werte gemessen. Dagegen hilft beim DS18xx zum Beispiel ein Kühlkörper. Sollte das nicht möglich oder nicht gewünscht sein, kann hier sowohl für RTC als auch für DS18xx eine Korrektur in 0,5°C Schritten angegeben werden. Bei Eingabe von beispielsweise "5" werden 2,5°C von der Messung abgezogen. Die Korrekturwerte sollte man frühestens nach einigen Minuten Betrieb wählen, damit RTC/DS18xx auch die endgültige Betriebstemperatur erreicht haben.

Beim Betätigen der Schaltfläche "Display temperature" wird die aktuelle Temperatur auf dem LED-Display entweder als Laufschrift (WordClock12h) oder als Wort-Anzeige (Word-Clock24h) eingeblendet. Diese Anzeige kann in einem gewissen Zeitintervall auch automatisch erfolgen, siehe '''[[WordClock_mit_WS2812#Display|Display]]'''.

|| [[Datei:Wordclock24h-Web-Temperature.png|miniatur|Web-Interface: Temperatur-Konfiguration]]
|}

=== Weather ===
{|
|- style="vertical-align:top;"
|
Um Wetterdaten auf der Uhr ausgeben zu können, braucht man eine sogenannte APPID (auch API-Id genannt), die man durch eine Registrierung bei http://openweathermap.org kostenlos beziehen kann. Am einfachsten findet man sie über den Menü-Eintrag "Price". Dort kann man dann eine API-Id in der Free-Version generieren lassen.

Diese APPID wird dann hier eingetragen. Desweiteren ist notwendig:

* entweder die Angabe eines Ortes
* oder die Angabe von Geo-Koordinaten (Longitude/Lattitude)

Gerade bei Großstädten ist es sinnvoll, die genauen Koordinaten des eigenen Wohnorts anzugeben, da das Wetter bereits lokal unterschiedlich sein kann. Werden sowohl Ort als auch die Geo-Koordinaten angegeben, haben die Koordinaten Priorität. Auch kann es sein, dass bei kleineren Ortschaften der Ort selbst bei openweathermap.org unbekannt ist. Im Zweifel sollte man sich besser für die Koordinaten-Variante entscheiden. Wichtig bei der Angabe eines Ortes ist es, die Stadt in der eigenen Landessprache anzugeben, also z.B. "Koeln" oder "Muenchen". Die Angabe von z.B. "Cologne" ist nicht zielführend, weil dies ein kleiner Ort in Italien ist ;-)

Kennt man die Geo-Koordinaten vom gewünschten Standort nicht, kann man sie über Google-Earth ermitteln. Dafür muss man nicht unbedingt Google-Earth herunterladen, es reicht das Aufrufen von Google-Maps im Browser. Anschließend kann man dann unten links auf die Web-Version von Google-Earth wechseln. Ein Klick auf den eigenen Standort lässt dann die gewünschten Koordinaten erscheinen. Dabei ist die erste Zahl (irgendetwas um die 50) die Lattitude und die zweite Zahl (in der Größenordnung 7) die Longitude. Die Zahlen sollen mit Dezimalpunkt und nicht Dezimalkomma eingetragen werden.

Ein abschließender Klick auf die Schaltfläche "Get weather" bezieht dann von openweathermap.org das aktuelle Wetter vom gewünschten Standort. Die Wetterdaten (Temperatur und Wetterlage) werden dann als Laufschrift auf dem Display ausgegeben. Diese Anzeige kann in einer kommenden Version über ein einstellbares Zeitintervall dann auch automatisch erfolgen.

|| [[Datei:Wordclock24h-Web-Weather.png|miniatur|Web-Interface: Wetterdaten-Konfiguration]]
|}

=== LDR ===
{|
|- style="vertical-align:top;"
|
Die Seite zeigt den aktuellen Wert an, den der ADC am LDR misst. Um den Helligkeitsbereich bei der automatischen Helligkeitssteuerung komplett auszunutzen, kann hier eine Kalibrierung vorgenommen werden. Dazu betätigt man einmal die Minimum-Schaltfläche bei verdunkeltem Raum und einmal die Maximum-Schaltfläche bei maximaler Raumhelligkeit. Die automatische Helligkeitssteuerung verwendet dann bei einer Helligkeitsmessung diese Min-/Max-Werte zum Vergleich.

Mittels Aktivierung von "Automatic Brightness" wird die automatische Helligkeitssteerung scharfgeschaltet.

Hinweis: Es ist nicht sinnvoll, bei der Max-Messung einfach eine Taschenlampe direkt vor den LDR zu halten. Da der LDR normalerweise hinter der Frontplatte sitzt, wird so eine Helligkeit in der Praxis niemals erreicht. Die Folge wäre, dass die LEDs der Uhr dann zu dunkel leuchten würden.

|| [[Datei:Wordclock24h-Web-LDR.png|miniatur|Web-Interface: LDR-Kalibrierung]]
|}

=== Display ===
{|
|- style="vertical-align:top;"
| Unter "Display Mode" können verschiedene Sprachvarianten, die regionale Unterschiede beim Gebrauch der Uhrzeit berücksichtigen, ausgewählt werden.

Mit dem Schieberegler "Brightness" kann die Grundhelligkeit eingestellt werden. Dieser wird deaktiviert, wenn die automatische Helligkeitssteuerung aktiviert wurde. Die eigentlichen Farben des Displays stellt man dann mit den Schiebereglern "R", "G" und "B" ein.

Stellt man für das Ambilight "Use Display Colors" ein, dann werden die Einstellungen für Helligkeit und Farben auch für das Ambilight verwendet, das heißt die Farben laufen synchron.

Auch hier gibt es nochmal die Schaltflächen zum Ein- und Ausschalten des LED-Displays. Mit der Schaltfläche "Test Display" werden sämtliche LEDs bei halber (subjektiver) Helligkeit eingeschaltet (benötigt ca. 1/4 des theoretisch möglichen Maximalstroms) und einige Farben zur Kontrolle der Funktionsfähigkeit aller LEDs durchprobiert.

Bei "Temp Display Interval" lässt sich ein Zeitintervall wählen, bei weilchem die aktuell gemessene Temperatur eingeblendet werden soll. Bei Angabe von "1" passiert das jede Minute, nämlich immer bei hh:mm:30 Uhr. Bei Angabe von beispielsweise "5" wird die Temperatur dann nur noch alle 5 Minuten eingeblendet.

|| [[Datei:Wordclock24h-Web-Display.png|miniatur|Web-Interface: Einstellungen des LED-Displays]]
|}

=== Animations ===
{|
|- style="vertical-align:top;"
| Animationen werden immer dann ausgeführt, wenn sich die Anzeige ändert, zum Beispiel bei einem Uhrzeitwechsel. Hier kann man sich die gewünschte Animation aussuchen und auch die dazugehörige Geschwindigkeit eingestellt werden.

Folgende Animationen sind verfügbar:

* None - Keine Animation
* Fade - Langsames Überblenden der Buchstaben
* Roll - Rollen der Wörter von links/rechts/oben/unten
* Explode - Die Wörter wandern schnell vom Mittelpunkt sternförmig auf ihren Platz
* Snake - Eine Schlange "frisst" die zuletzt angezeigten Wörter weg
* Teletype - Die Wörter werden in "Schreibmaschinen-Geschwindigkeit" ausgegeben
* Cube - Ein Rahmen "fällt" von außen nach innen, um die Anzeige zu löschen
* Matrix - Matrix-Animation aus dem gleichnamigen Film
* Drop - Buchstaben alter Wörter fallen aus der Anzeige, Buchstaben neuer Wörter fallen von oben in die Anzeige hinein
* Squeeze - Die Wörter werden einmal kurz "gequetscht"

Eine Besonderheit ist die Animation "Random". Hier wird mit Hilfe eines Zufallsgenerators jedesmal eine andere Animation ausgewählt. Deklariert man eine Animation als Favoriten, dann wird diese von der Zufallsanimation "Random" genutzt. Anderenfalls wird sie von "Random" ignoriert.

Die Geschwindigkeit kann man in 15 Stufen einstellen. Bei Klick auf die Schaltfläche "Default" wird die Geschwindigkeit auf einen sinnvollen Standardwert gesetzt.

Als zusätzliche Farbanimation kann noch "Rainbow" ausgewählt und konfiguriert werden. Dann wechselt das Display fließend die Farben der LEDs.

|| [[Datei:Wordclock24h-Web-Animations.png|miniatur|Web-Interface: Einstellungen der Animationen]]
|}

=== Ambilight ===
{|
|- style="vertical-align:top;"
| Hier kann eine separate Animation für das Ambilight eingestellt werden.

Bei dem Ambilight-Modus "Clock" werden 20, 30 oder 60 Ambilight-LEDs als umlaufende Sekundenanzeige verwendet. Mit "#LEDs" kann man einstellen, wieviele Ambilight-LEDs sich im "Kreis" befinden. Sinnvoll sind hier 20, 30 oder 60. Ausserdem lässt sich mit "Offset of second = 0" diejenige LED einstellen, die mittig oben als Sekunde 0 angebracht ist.

Beispiel: Beginnt das Ambilight mit 60 LEDs links unten und ist im Uhrzeigersinn angebracht, dann wäre die LED mit Sekunde 0 die Nr. 22. Diese Zahl ist dann hier einzutragen.

Der Ambilight-Modus "Clock2" entspricht dem Modus "Clock". Jedoch wird hier ein zu-/abnehmender Vollkreis dargestellt.

Bei dem Ambilight-Modus "Rainbow" durchlaufen die Ambilight-LEDs langsam (über mehrere Minuten hinweg) alle Farben des Regenbogens. Dieser läuft unabhängig von der Farbanimation "Rainbow" des Displays.

Ist auf der Display-Webseite eingestellt, dass die Ambilight-Farben nicht synchronisiert werden sollen, dann kann man hier auch unhabhängig von dem Display eine eigene Helligkeit und einen anderen RGB-Wert wählen.

|| [[Datei:Wordclock24h-Web-Ambilight.png|miniatur|Web-Interface: Einstellungen des LED-Displays]]
|}

=== Timers ===
{|
|- style="vertical-align:top;"
| Mit bis zu acht Timern kann man einstellen, wann die Uhr aus- bzw. eingeschaltet werden soll. Die Einstellung kann in Abhängigkeit der Wochentage eingestellt werden.

Im Beispiel rechts wird in der Woche abends die Uhr um 22:30 Uhr abgeschaltet. Eingeschaltet wird dann morgens wieder um 07:00 Uhr. Nach dem Frühstück wird die Uhr dann um 08:00 Uhr wieder abgeschaltet, um dann abends um 17:00 Uhr wieder eingeschaltet zu werden.

Am Wochenende sieht das dann anders aus: Hier ist die Uhr abends länger eingeschaltet, nämlich bis 23:30 Uhr. Morgens geht es erst dann um 09:00 Uhr wieder weiter.
|| [[Datei:Wordclock24h-Web-Timers.png|miniatur|Web-Interface: Timer]]
|}

----

== Timeserver ==

Der Timeserver muss ein RFC 958 konformer NTP-Server sein. Voreingestellt ist ntp3.ptb.de (192.53.103.103). Alternative Timeserver sind zum Beispiel ntp1.ptb.de (192.53.103.108), ntp2.ptb.de (192.53.103.104) oder time.nist.gov (216.229.0.179).

Eine Liste von europäischen Timeservern findet man u.a. hier: http://www.pool.ntp.org/zone/europe

Den Timeserver konfiguriert man folgendermaßen:

Im Browser gibt man als URL die ausgegebene IP-Adresse ein, also z.B. http://192.168.10.1/ . Anschließend wählt man den Menüpunkt "Network" an und gibt in der entsprechenden Zeile die IP-Adresse des Wunsch-Timeservers ein und bestätigt mit "Save". Nun wird zunächst geprüft, ob der Timeserver das NTP-Protokoll unterstützt.

Die aktuelle Uhrzeit wird alle 3800 Sekunden vom Timeserver geholt. Im [[WordClock_mit_WS2812#Web-Interface|Web-Interface]] kann man die Übertragung auch jederzeit per Mausklick starten. Das funktioniert auch mit einer angelernten IR-Fernbedienung.

=== Zeitzone ===

Im [[WordClock_mit_WS2812#Web-Interface|Web-Interface]] Menüpunkt "Network" auswählen, in der Zeile "Timezone" die Abweichung von GMT eingeben. Für die mitteleuropäische Zeitzone wäre das einfach eine 1. Dies entspricht dann GMT+1. Bei einer negativen Abweichung wie GMT-1 muss dann entsprechend -1 eingegeben werden.

----

== IR-Fernbedienung ==

In den ersten 3 Sekunden leuchtet die Status-LED mit der Farbe weiß, um zu signalisieren, dass nun eine IR-Fernbedienung angelernt werden kann. Wird währenddessen irgendein gültiger IR-Code empfangen, wechselt die Status-LED für eine Sekunde auf rot (FB-Knopf loslassen!) und es wird in die Anlernroutine gesprungen. Wird kein IR-Signal empfangen, startet das Programm wie gewohnt. Die Anlernroutine kann auch über die [[WordClock_mit_WS2812#Web-Interface|Web-Oberfläche]] (Menü "Main") gestartet werden.

Man wird nun über eine Laufschrift auf dem LED-Display aufgefordert, folgende FB-Tasten zu drücken:

{| {{Tabelle}}
|+ '''Tasten für IR-Fernbedienung'''
|- style="background-color:#eeeeee"
! Taste || Funktion || Laufschrift
|-
| Power || Anzeige ein/aus || power off/on
|-
| OK || Speichern der Einstellungen || ok
|-
| MODE- || Anzeigemodus erniedrigen || decrement display mode
|-
| MODE+ || Anzeigemodus erhöhen || increment display mode
|-
| ANIM- || Animation erniedrigen || decrement animation mode
|-
| ANIM+ || Animation erhöhen || increment animation mode
|-
| HOUR- || Stunde erniedrigen || decrement hour
|-
| HOUR+ || Stunde erhöhen || increment hour
|-
| MIN- || Minute erniedrigen || decrement minute
|-
| MIN+ || Minute erhöhen || increment minute
|-
| RED- || Helligkeit der Farbe Rot erniedrigen || decrement red brightness
|-
| RED+ || Helligkeit der Farbe Rot erhöhen || increment red brightness
|-
| GREEN- || Helligkeit der Farbe Grün erniedrigen || decrement green brightness
|-
| GREEN+ || Helligkeit der Farbe Grün erhöhen || increment green brightness
|-
| BLUE- || Helligkeit der Farbe Blau erniedrigen || decrement blue brightness
|-
| BLUE+ || Helligkeit der Farbe Blau erhöhen || increment blue brightness
|-
| BRIGHT- || Grundhelligkeit erniedrigen || decrement global brightness
|-
| BRIGHT+ || Grundhelligkeit erhöhen || increment global brightness
|-
| AUTO+ || Automatische Helligkeitsregelung ein/aus || toggle auto brightness
|-
| TEMP || Anzeige der Temperatur für 5 Sekunden || get temperature
|}

Sind die FB-Tasten angelernt, kann man die Uhrzeit, den Anzeigemodus und auch die Farben mittels IR-Fernbedienung einstellen.

Es sind nur die gebräuchlichsten IR-Protokolle aktiviert, nämlich:

* SIRCS (Sony)
* NEC (Viele Hersteller, sehr verbreitet)
* SAMSUNG
* MATSUSHITA
* KASEIKYO

[[IRMP]] "versteht" jedoch bis zu 40 Protokolle. Braucht man weitere - wie RC5 oder RC6 - kann man sie in irmp/irmp-config.h freischalten. Bei Problemen empfiehlt sich die Lektüre des [[IRMP]]-Artikels.

Eine passende Fernbedienung gibt es bei '' [http://www.dealextreme.com/p/24-key-wireless-infrared-ir-remote-controller-for-rgb-led-light-bulb-1-cr2025-47019 DX] ''.

Passend beschriftet werden kann die Fernbedienung mit einem der folgenden Labels 
[[Datei:Fernbedienung Folie ZW.pdf]] 
[[Datei:Fernbedienung Folie ZW2.pdf]] 
(sie unterscheiden sich in der Anordnung des Power- und Save-Knopfes). Einfach auf eine selbstklebende Folie drucken, ausschneiden und aufkleben. Die unterste Reihe ist für weitere zusätzliche Optionen (z.B. Ambilight, usw.) noch offen.

----

== Android App ==

{|
|- style="vertical-align:top;"
|

Ist ein [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul angeschlossen und korrekt konfiguriert, kann die Uhr per [[WordClock_mit_WS2812#Android_App|Android App]] ferngesteuert werden.

Momentan können folgende Einstellungen vorgenommen werden:

* Ein-/Ausschalten der Uhr
* Manuelles Stellen von Datum/Uhrzeit über Menü -> Synchronisieren
* Anzeige der WordClock-Temperatur
* Einstellen der Farben ('''Neu''': nun auch RGBW)
* Manuelle Einstellung einer Grundhelligkeit
* Automatische Helligkeitsregelung per [[WordClock_mit_WS2812#LDR|LDR]] ein/aus
* Einstellung des Anzeigemodus
* Einstellung der Farbanimation, z.B. "Rainbow" ('''Neu''')
* Einstellung der Animation (Überblenden, Rollen, Explosion etc.)
* Einstellung, ob WC24h oder WC12h ferngesteuert werden soll

Bevor man mit der App Daten senden kann, muss man die IP-Adresse, die das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul bekommen hat, in der App einstellen. Dies geht über den Menü-Eintrag "Einstellungen". Bei älteren Android-Versionen ist dafür zunächst die spezielle Menü-Taste zu drücken, bei neueren Android-Versionen geht das auch über die Menüschaltfläche mit den drei übereinanderliegenden Punkten - siehe Bild rechts oben.

In den Einstellungen kann gewählt werden, ob eine WC24h oder eine WC12h ferngesteuert werden soll. Dies betrifft die Liste der möglichen Anzeige-Modi. Wenn SK6812 als RGBW-LEDs eingesetzt werden, dann sollte auch das Häkchen für RGBW gesetzt werden, um zusätzlich auch die Farbe "Weiß" steuern zu können.

|| [[Datei:Wc24h-Android.png|miniatur|WC24h Android App]]
|}

----

= Mechanik =

== Anbringung der WS2812-Streifen ==

{|
|- style="vertical-align:top;"
| '''WordClock24h:'''

Am besten verwendet man eine Alu-Platte mit den Maßen 300mmx300mm und 1mm Stärke. Darauf lassen sich nicht nur einfach die WS2812-LED-Streifen aufkleben, auch dient die Alu-Platte der Wärmeabfuhr. Die Alu-Platte kann man sich von einem der eBay-Händler entweder direkt erstehen oder für ca. 3,50 Euro zurechtschneiden lassen.

Den LED-Streifen schneidet man 16 Streifen à 18 LEDs. Bevor man sie auf die LED-Platte klebt, sollte man senkrecht je einen Tesa-Streifen links und rechts auf die Alu-Platte kleben, da sich gezeigt hat, dass die Schnittkanten der Streifen gern einen Kurzschluss mit der Alu-Platte bilden.

Die LED-Streifen werden dann im Zieharmonika-Verfahren aufgeklebt. Dabei steht jeder 2. Streifen auf dem Kopf. Das hat den Vorteil, dass die Verbindungen zwischen den Streifen möglichst kurz sind. Auf der rechten Seite verbindet man dann die Anschlüsse +5V mit +5V, GND mit GND und DO mit DI - siehe Bild. Man verbindet also den ersten mit dem zweiten Streifen, den dritten mit dem vierten Streifen usw.

Auf der linken Seite verbindet man lediglich DO mit DI, also den zweiten Streifen mit dem dritten, den vierten mit dem fünften usw. An den verbleibenden Lötpunkten +5V und GND lötet man an jedem *zweiten* Streifen (1, 3, 5 usw.) die Spannungsversorgung an. Praktisch ist die Verwendung eines 16-poligen Flachbandkabels, welches man auf einen Flachbandkabel-Stecker aufquetscht. Pin 1 und 2 gehen dann an 5V/GND des ersten Streifens, 3 und 4 an 5V/GND des dritten Streifens usw.

Dann kann man mittels 16-poligem Wannenstecker, den man auf eine Lochrasterplatine lötet, die Spannungsversorgung einfach verpolungssicher anstecken. Unter der Lochrasterplatine werden die geradzahligen Pins und die ungeraden Pins je mit einem Kupferdraht verbunden. Mit einer 2-poligen Schraubklemme auf der Lochrasterplatine kann dann das Netzteil angeschlossen werden - siehe Bild rechts.

|| [[Datei:Wclock24h-WS2812-auf-Alu-Platte.jpg|miniatur|16 WS2812-Streifen auf Alu-Platte]]
[[Datei:Wclock24h-16-pol-Wanne.png|miniatur|16pol Wanne zum Verbinden des Netzteils und der Streifen]]
[[Datei:Wclock24h-Spannungsvergung-Streifen.jpg|miniatur|Anschluss der Streifen an die Spannungsversorgung]]
|- style="vertical-align:top;"
| '''WordClock12h:'''
Der Aufbau ist analog zu der WordClock 24h zu betrachten. Der Unterschied liegt darin, dass bei der WC12h die LED Streifen mit dem Sonderabstand benutzt werden und dieser in 10 Streifen a 11 LEDs geteilt wird. Sowie in 4 Einzel LEDs für die Minutenanzeigen in den Ecken. 
Die Verbindung der Streifen erfolgt dann analog zu der oben beschriebenen Weise.
||
[[Datei:Aufbau WC12h WS2812.jpg|mini]]
Aufgebaute WC12h mit WS2812 Streifen.
|}

== Zwischenböden ==
Es gibt insgesamt 3 Varianten der Zwischenböden. 
Zwei Varianten für die WordClock 12h (mit und ohne Ambilight Ausparungen) und eine Variante für die WordClock 24h
{|
|- style="vertical-align:top;"
| WordClock 12h OHNE Ambilight Aussparungen
|-
|[[Datei:WC12h Boden ohne Hinten.jpeg|mini|Rückseite]]
||[[Datei:WC12h Boden ohne Vorne.jpeg|mini|Vorderseite]]
||
|- style="vertical-align:top;"
| WordClock 12h MIT Ambilight Aussparungen
|-
|[[Datei:WC12h Boden mit Hinten.jpeg|mini|Rückseite]]
||[[Datei:WC12h Boden mit Vorne.jpeg|mini|Vorderseite]]
||
|- style="vertical-align:top;"
| WordClock 24h v2
|-
|[[Datei:WC24h Boden Rueckseite.jpeg|mini|Rückseite]]
||[[Datei:WC24h Boden Vorderseite.jpeg|mini|Vorderseite]]
||[[Datei:WC24h Boden Rueckseite schraeg.jpeg|mini|Rückseite schräg]]
|}

== Frontplatten ==

(in Arbeit)

== Shield für STM32 MiniDevBoard ==
Vorgestellt wird hier das Shield für das MiniDevBoard.
Zunächst die veralte Version1 (V1):
{|
|- style="vertical-align:top;"
|Das Board ist 38x110mm und verbindet alle Komponenten miteinander. Dieses Board ist die optimale Variante für die klassische 10x11 WordClock. Es enthält alle Schnittstellen für die WordClock und ist für die WC12 als auch für die WC24 Variante geeinget.
|| [[Datei:MiniShield Vorderseite.jpg|mini]]
|- style="vertical-align:top;"
|Das Board von der Rückseite
||[[Datei:MiniShield Rueckseite.jpg|mini]]
|- style="vertical-align:top;"
|Das Board soweit bestückt - es fehlt hier noch das STM32. Das STM32 MiniDevBoard sollte direkt ohne weiteren Sockel auf das Shield gelötet werden.
||[[Datei:MiniShield Bestueckt.jpg|mini]]
|- style="vertical-align:top;"
|Hier nun das vollbestückte Shield, incl STM32, ESP8266, RTC, DS1820, AMS1117
||[[Datei:MiniShield Bestueckt incl STM32.jpg|mini]]
|- style="vertical-align:top;"
|Der Schaltplan des MiniDevBoards: Einzige Abweichung: +5V ist an die UART Schnittstelle mit raus geführt.
||[[Datei:MiniShield Schaltplan.jpg|mini]]
|}

Es gibt nun eine neue v2 vom Shield für das MiniDevBoard.
{|
|- style="vertical-align:top;"
|Die v2 enthält folgende Anpassungen:
* am UART ist nun auch +5V ausgeführt
* Rastabstand bei DS3231, TSOP, LDR, Data sind nun einheitlich und können somit mit einem durchgehenden PinHeader bestückt werden
* die Pins für das DS3231 sind gespiegelt. Damit liegt die Batterie nun oben und steht nicht mehr nach unten über
* Es wurde die Abschaltschaltung für die 5V Versorgung der WS2812 Streifen eingebaut. Somit kann optional die Versorgungsspannung geschaltet werden. 

|| [[Datei:MiniDev v2 TOP.jpg|mini]]
|- style="vertical-align:top;"
|Das Board von der Rückseite. 
'''Im Lieferzustand ist die Abschaltschlaltung gebrückt. Wird die Abschaltschaltung eingebaut, muss auf der Unterseite eine Leiterbahn durchtrennt werden! Diese ist hier rot umrandet!'''
||[[Datei:MiniDev v2 BOTTOM.jpg|mini]]
|- style="vertical-align:top;"
|Bestückte Bilder folgen noch.
|- style="vertical-align:top;"
|Der Schaltplan des MiniDevBoards als V2:
||[[Datei:MiniDev v2 Schematic.jpg|mini]]
|}

== Shield für nucleo-Board ==
Vorgestellt wird hier ein shield für das nucleo-Board.
{|
|- style="vertical-align:top;"
| Das shield ist 90mm*55mm klein und wird auf das nucleo-Board aufgesteckt. Es enthält alle bekannten Schnittstellen für die WordClock (egal ob 12h oder 24h) und ist zusammengebaut ca 19mm hoch.
Es passt somit problemlos in eine Aussparung des Zwischenbodens.
|| [[Datei:Ns-Bild1.JPG|mini]]
|- style="vertical-align:top;"
|Ebenfalls integriert sind Anschlüsse, um den abgesägten ST-link zur Programmierung oder Kommunikation über UART mit dem PC zu verbinden.
||[[Datei:Ns-stl1a.JPG|mini]]
|- style="vertical-align:top;"
|Beschreibung der Schnittstellen:
Die Belegung der meisten Schnittstellen ergibt sich aus den nebenstehenden Bildern.
Um das RTC Modul, welches entweder ein DS3231 oder ein DS1307 sein kann, mit Spannung zu versorgen, gibt es die Stiftleiste St-07, welche mit einem Jumper die Spannung am RTC Modul auf 3,3V oder 5V einstellt.
Die Stiftleiste St-04 kann per Pfostenfeldbuchse und Flachbandkabel insgesamt 8 mal die Spannung in die WS2812 Streifen einspeisen (siehe Beispiel weiter oben im Artikel).
||[[Datei:Ns-sh2.JPG|mini]]
|- style="vertical-align:top;"
|Und so schaut das bestückte Nucleo Board aus
||[[Datei:Nucleo_bestueckt.JPG|mini]]
|}
Seit Juli 2016 wird das Nucleo-shield in der Version V2.1a ausgeliefert.
[[Datei:IMG 0366mod.jpg|mini]]
Es enthält jetzt auch die Möglichkeit, die Abschaltung der WS2812 LEDs per Hardware vorzunehmen. Dazu wurde die entsprechenden Bauteile auf das Board gepackt.
Außer dem Leistungs MOSFET IRF9310 wurde alles in bedrahteter Technik ausgeführt.
Wer die Bauteile für die Abschaltung (T1, T2, D1, R7, R8 und R9) NICHT einbaut, muss, wie in nebenstehendem Bild gezeigt, vier Lötbrücken einbauen.

Analog dazu muss derjenige, der die Abschaltung einbaut, die Lötbrücken offen lassen (siehe unteres Bild, roter Kreis).

[[Datei:NS Bug-1.jpg|mini]]

Leider haben sich zwei Bugs in den Platinenentwurf eingeschlichen.
Zum einen gibt es Kurzschlüsse an den Pluspolen der Kondensatoren C1 und C3. Der Workaround besteht darin, das Bohrloch etwas aufzuweiten, um die ungewünschte Verbindung zu Masse zu trennen (siehe Bild)

[[Datei:NS Bug-2.jpg|mini]]

Der zweite Bug betrifft nur diejenigen, die die hardwaremässige Abschaltung der WS2812 LEDs einbauen.
Hier muss, wie im nebenstehenden Bild gezeigt, eine kleine Verbindung mit einem Stück Kabel hergestellt werden.

Das shield muss über St-08 mit 5V versorgt werden. Die für die Schnittstellen benötigten 3,3V wird auf dem shield selbst mit einem LM3940-3.3 erzeugt.

Hier findet ihr die Stückliste zum nucleo-Board und den link zum öffentlichen Reichelt Warenkorb (noch ohne T1, T2, D1, R7, R8 und R9).
[[Datei:Wc24wk.pdf]]
-----

= Sammelbestellungen =

== Sammelbestellung LED Stripes, Zwischenböden, Shields ==
Für die WC12h Variante der WordClock werden WS2812 Stripes als Spezialanfertigung mit einem Rastermaß von 28,1mm eingesetzt.

Es werden folgende '''WS2812 Pakete''' angeboten (WC12h):
* Paket 5 (Uhr - STM32 Basis - WS2812) - 40,80Eur : 120 WS2812-LEDs als Stripe im Sonderabstand
* Paket 6 (Ambilight - STM32 Basis - WS2812) - 20,40Eur : 60 WS2812-LEDs als Stripe im Sonderabstand
(durch die Umstellung des Ambilight Paketes auf 60 LEDs, kann die umlaufende Sekundenanzeige realisiert werden)

Für die WC24h werden die WS2812 Stripes nicht über eine Sammelbestellung bestellt, da hier das Standardformat genutzt wird.

Es werden folgende '''Zwischenböden''' angeboten:
* Zwischenboden (WC12h) mit Ambilightausfräsung (MDF 19mm gefräst) - 37,50Eur
* Zwischenboden (WC12h) ohne Ambilightausfräsung (MDF 19mm gefräst) - 37,50Eur
* Zwischenboden (WC24h) ohne Ambilightausfräsung (MDF 19mm gefräst) - 59,50Eur

Es werden folgende '''Shields''' angeboten:
* Shield für STM32 MiniDevBoard - 3,50Eur
* Shield für STM32 NucleoBoard - 5,50Eur

Der '''Versand der Shields''' erfolgt als Großbrief:
* innerhalb BRD – 4,00Eur
* Österreich – 6,00Eur
* Schweiz - 6,00Eur

Der '''Versand der WS2812-Stripes''' erfolgt als kleines Paket:
* innerhalb BRD (ohne Inseln) – 6,50Eur
* Österreich – 15,50Eur
* Schweiz – in die Schweiz kann nur als normales Paket versendet werden, Kosten hierzu siehe unten

Der '''Versand mit Zwischenboden''' erfolgt als normales Paket: 
* innerhalb BRD (ohne Inseln) - 10,00Eur (bis 2 Böden)
* innerhalb BRD (ohne Inseln) - 12,00Eur (bis 4 Böden)
* innerhalb BRD (ohne Inseln) - 18,00Eur (ab 5 Böden)
* Österreich – 20,00Eur (bis 2 Böden)
* Österreich – 25,00Eur (bis 4 Böden)
* Schweiz - 31,00Eur (bis 2 Böden)
* Schweiz - 40,00Eur (bis 4 Böden)
 
Es fallen jeweils nur die höheren Versandkosten an. 
Werden mehrere Pakete bestellt, können die tatsächlichen Versandkosten von den hier gezeigten Versandkosten abweichen. Diese ist dann von der bestellten Menge und dem Gewicht abhängig und wird dann entsprechend mitgeteilt. 
Bei Interesse bitte per PN melden (Benutzer [http://www.mikrocontroller.net/user/show/wawibu wawibu]) 
 
'''Zeitplanung''' 

<table border=1>
<tr><td>Datum</td><td>Aktion</td></tr>
<tr><td>bis 07.Oktober 2016</td><td>Sammeln der Bestellungen</td></tr>
<tr><td>10.Oktober 2016</td><td>Bestellung geht raus</td></tr>
<tr><td>~09.November 2016</td><td>Anlieferung bei mir</td></tr>
<tr><td>~14.November 2016</td><td>Versand</td></tr>
</table>

----

== WC12h Sammelbestellung Frontplatten ==

[[Datei:Wordclock-front-dia.jpg|miniatur|Frontplatte: Dia]]
[[Datei:Wordclock-front-full.jpg|miniatur|Frontplatte: Vollansicht]]
[[Datei:WordClock-gelb.jpg|miniatur|4-sprachige Frontplatte]]

Die Frontplatten bleiben identisch zu denen aus dem früheren [[Word Clock|WordClock]]-Projekt.

Die aktuelle Version, die auch für die Sammelbestellung gilt:

E S K I S T L F Ü N F <nowiki>==> ES IST FÜNF</nowiki>
Z E H N Z W A N Z I G <nowiki>==> ZEHN ZWANZIG</nowiki>
D R E I V I E R T E L <nowiki>==> DREI|VIERTEL</nowiki>
T G N A C H V O R J M <nowiki>==> NACH VOR</nowiki>
H A L B Q Z W Ö L F P <nowiki>==> HALB ZWÖLF</nowiki>
Z W E I N S I E B E N <nowiki>==> ZW|EI|N|S|IEBEN</nowiki>
K D R E I R H F Ü N F <nowiki>==> DREI FÜNF</nowiki>
E L F N E U N V I E R <nowiki>==> ELF NEUN VIER</nowiki>
W A C H T Z E H N R S <nowiki>==> ACHT ZEHN</nowiki>
B S E C H S F M U H R <nowiki>==> SECHS UHR</nowiki>

'''Damit ist es möglich, vier regionale Sprechweisen darzustellen:'''

'''Wessi-Modus:'''

es ist ein uhr
es ist fünf nach eins
es ist zehn nach eins
es ist viertel nach eins
es ist zehn vor halb zwei
es ist fünf vor halb zwei
es ist halb zwei
es ist fünf nach halb zwei
es ist zehn nach halb zwei
es ist viertel vor zwei
es ist zehn vor zwei
es ist fünf vor zwei

'''Rhein-Ruhr-Modus:'''

es ist ein uhr
es ist fünf nach eins
es ist zehn nach eins
es ist viertel nach eins
es ist zwanzig nach eins
es ist fünf vor halb zwei
es ist halb zwei
es ist fünf nach halb zwei
es ist zwanzig vor zwei
es ist viertel vor zwei
es ist zehn vor zwei
es ist fünf vor zwei

'''Ossi-Modus:'''

es ist ein uhr
es ist fünf nach eins
es ist zehn nach eins
es ist viertel zwei
es ist zehn vor halb zwei
es ist fünf vor halb zwei
es ist halb zwei
es ist fünf nach halb zwei
es ist zehn nach halb zwei
es ist dreiviertel zwei
es ist zehn vor zwei
es ist fünf vor zwei

'''Schwaben-Modus:'''

es ist ein uhr
es ist fünf nach eins
es ist zehn nach eins
es ist viertel zwei
es ist zwanzig nach halb zwei
es ist fünf vor halb zwei
es ist halb zwei
es ist fünf nach halb zwei
es ist zwanzig vor halb zwei
es ist dreiviertel zwei
es ist zehn vor zwei
es ist fünf vor zwei

'''Sammelbestellung Stand August 2016:'''

Aus der letzten Sammelbestellung sind noch Frontplatten übrig. Interessenten können sich bei mir (Benutzer [http://www.mikrocontroller.net/user/show/ukw '''ukw''']) melden.

Die Platten bestehen aus einer Plexi-Scheibe (3mm) in der Größe 45cm x 45cm und werden im Siebdruckverfahren bedruckt. Dabei wird die Scheibe von hinten zunächst mit einer Mehrfach-Schicht schwarzer Farbe bedruckt, damit sie lichtdicht ist. Lediglich die Buchstaben und Minutenpunkte bleiben frei. Anschließend kommt noch optional eine dünne weiße Schicht komplett deckend über die schwarze Farbe, sodass sie als Diffusor für die Buchstaben und Minutenpunkte wirkt.

Diese Variante heisst nun 'WC12h':

- WC12h: 45cm x 45cm mit weißer Schicht als Diffusor

Der Preis dafür beträgt pro Stück 42,- EUR.

Hinzu kommen noch 10 EUR Versandkosten für bis zu 4 Stück in einem Paket. Bei Versand in ein EU-Land kommen weitere 10 EUR hinzu, also insgesamt 20 EUR.

Die Frontplatte beinhalt alle 4 Sprachversionen:

* Wessi-Modus (viertel nach/vor)
* Ossi-Modus (viertel/dreiviertel)
* Rhein-Ruhr-Modus (viertel nach/vor, zwanzig nach/vor)
* Schwaben-Modus (viertel/dreiviertel, zwanzig nach/vor)

'''WICHTIG:'''

'''Die Frontplatte wird mit einer kaum wahrnehmbaren Schutzfolie auf der Vorder- '''und''' Rückseite geliefert. Wenn man das nicht weiß, kann es so aussehen, als ob die Frontplatte "verkratzt" sei. Diese "Kratzer" sind aber nur auf der Schutzfolie, nicht auf der Platte selbst. Daher hier nochmal der ausdrückliche Hinweis: Bitte die Schutzfolie unmittelbar vor der Montage abziehen und sich dann freuen :-)'''

'''Kleber welcher den Aufdruck nicht beschädigt:'''

- UHU plus endfest 300 2K-Epoxidkleber

----

== WC24h Sammelbestellung LED Stripes ==

Eine Sammelbstellung der LED-Stripes für die WC24h ist derzeit nicht geplant, da hier WS2812-Stripes mit dem Standard-Rastermaß von 60 LEDs/m benötigt werden. Diese sind sehr einfach bei eBay oder Amazon erhältlich.

----

== WC24h Sammelbestellung Zwischenböden ==

Wir können nun auch die WC24h Zwischenböden über die Sammelbestellung anbieten.

* Zwischenboden für Wordclock 24h (MDF 19mm gefräst) - 59,50Eur

Alle Details zu der Sammelbestellung ist weiter oben bei der [[WordClock_mit_WS2812#WC12h_Sammelbestellung_LED_Stripes_und_Zwischenb.C3.B6den|WC12h Sammelbestellung beschrieben]].

----

== WC24h Sammelbestellung Frontplatten ==

[[Datei:WordClock24h-Frontplatte-800x800.png|400px|right|WordClock24h]]

Die Frontplatte beinhalt über ein Dutzend Sprachvarianten:

* hh mm (12)
* hh mm (24)
* hh und mm (12)
* hh und mm (24)
* mm nach hh (12+)
* mm nach hh (24)
* Ossi/Berlin (12)
* Ossi/Berlin (12+)
* Oesi (12)
* Oesi (12+)
* Rhein/Ruhr (12)
* Rhein/Ruhr (12+)
* Schwaben (12)
* Schwaben (12+)
* Wessi (12)
* Wessi (12+)
* Countdown bis Mitternacht
* Temperatur

'''Stand der Sammelbestellung August 2016:'''

Aus der letzten Sammelbestellung sind noch Frontplatten übrig. Interessenten können sich bei mir (Benutzer [http://www.mikrocontroller.net/user/show/ukw '''ukw''']) melden.

Die Platten bestehen aus einer Plexi-Scheibe (3mm) in der Größe 45cm x 45cm und werden im Siebdruckverfahren bedruckt. Dabei wird die Scheibe von hinten zunächst mit einer Mehrfach-Schicht schwarzer Farbe bedruckt, damit sie lichtdicht ist. Lediglich die Buchstaben und Minutenpunkte bleiben frei. Anschließend kommt noch optional eine dünne weiße Schicht komplett deckend über die schwarze Farbe, sodass sie als Diffusor für die Buchstaben und Minutenpunkte wirkt.

Diese Variante mit 16x18 Buchstaben heisst hier 'WC24h':

- WC24h: 45cm x 45cm mit weißer Schicht als Diffusor

Der Preis dafür beträgt pro Stück 44,- EUR.

Hinzu kommen noch 10 EUR für Verpackungs- und Versandkosten für bis zu 4 Stück in einem Paket. Bei Versand in ein EU-Land kommen weitere 10 EUR hinzu, also insgesamt 20 EUR.

'''WICHTIG:'''

'''Die Frontplatte wird mit einer kaum wahrnehmbaren Schutzfolie auf der Vorder- '''und''' Rückseite geliefert. Wenn man das nicht weiß, kann es so aussehen, als ob die Frontplatte "verkratzt" sei. Diese "Kratzer" sind aber nur auf der Schutzfolie, nicht auf der Platte selbst. Daher hier nochmal der ausdrückliche Hinweis: Bitte die Schutzfolie unmittelbar vor der Montage abziehen und sich dann freuen :-)'''

'''Kleber welcher den Aufdruck nicht beschädigt:'''

- UHU plus endfest 300 2K-Epoxidkleber

----

= Anhang =

=== Historie der Software-Versionen ===

==== Android App ====

Version 2.1.0:

* Alle aktuell vorgesehenen Animationen können nun vollständig über die App ausgewählt werden
* RGBW-LED-Unterstützung: Unter dem Menü "Einstellungen" kann nun eingestellt werden, dass RGBW-LEDs eingesetzt werden.
* Die Oberfläche ist nun "scrollable", kann also bei kleineren Mobilgeräten, wo nicht alles draufpasst, gerollt werden.

Version 1.9.0:

* Neue Animationen Snake, Teletype und Cube nun auch über die App einstellbar

Version 1.8.0:

* Manuelles Stellen von Datum/Uhrzeit über Menü -> Synchronisieren
* Auswählen der Farbanimation "Rainbow"

Version 1.7.0:

* Button für Temperaturanzeige eingebaut

==== ESP8266 ESP-01 Firmware ====

Version 2.2.0:

* Diverse Verbesserungen bei der Kommunikation zwischen STM32 und ESP8266

Version 2.1.0b:

* Bugfix - Umlaute in Wettertexten wurden nicht korrekt gezeigt. Konvertierung der Umlaute von openweathermap-Inhalten von UTF8 nach ISO8859 nachgeholt.

Version 2.1.0a:

* Bugfix - beim Wechseln in den AP-Modus wurde fälschlicherweise "0.0.0.0" als IP-Adresse statt 192.168.4.1 ausgegeben.

Version 2.1.0:

* Auslagerung des HTML-Codegenerators auf den ESP8266
* Auslagerung der Schnittstelle zu Android-Geräten (Kommando-Interpreter) auf den ESP8266

Version 1.2.0:

* Neu: Ausgabe des WLAN-Modus: WLAN-Client oder AP

Version 1.1.0:

* Fehler im NTP-Client behoben: Bei vorherigen Timeouts kann eine alte Uhrzeit ausgegeben werden

==== STM32 WordClock Software ====

===== Version 2.2.0 =====

* Bugfix: Die Anzeigedauer der Temperatur ist nun nicht mehr von der Dauer der Animation abhängig.
* Bugfix Ambilight: Nach "Test Display" wurde die ursprüngliche Helligkeit des Ambilight nicht wieder hergestellt.
* Bugfix AP-Mode: Durch einen Timeout bei der ESP8266-Kommmunikation wurden die Vorgabewerte fürs Web-Interface nicht übertragen.
* RX-Ringbuffer ESP8266 -> STM32 von 128 auf 256 vergrößert.
* Timeout-Behandlung bei der Kommunikation zwischen STM32 und ESP8266 verbessert.
* Web-Interface: Checkbox "Use display colors" wurde auf die Seite "Ambilight" verschoben.
* WC12h Bugfix: Umlaute werden in der Laufschrift immer als Großbuchstaben angezeigt.
* WC12h: Font zur Laufschriftanzeige durch besser lesbaren Font ersetzt.
* WC24h: Korrektur der Anzeige von "ES IST EINS UHR" nach "ES IST EIN UHR" in bestimmten Anzeigemodi.
* Bugfix SK6812: Rot und Grün vertauscht.
* Bugfix LDR: Nach dem Setzen eines neuen LDR-Max-Wertes wurde dieser nicht zurück an das Web-Interface übertragen und deshalb dort (bis zum nächsten Reboot) ein alter Max-Wert angezeigt.

===== Version 2.1.0 =====

* Auslagerung des HTML-Codegenerators auf den ESP8266, damit Code-Ersparnis auf dem STM32 von 14KB Flash.
* Auslagerung der Schnittstelle zu Android-Geräten (Kommando-Interpreter) auf den ESP8266
* Optional: Laufschrift mit dem aktuellen Wetter (über openweathermap.org)
* Unterstützung SK6812 (optional, RGBW-LEDs)
* Verbesserungen bei der LDR-Umgebungshelligkeitsmessung
* Wegfall der Schaltfläche "Save all" im Web-Interface. Nun werden sämtliche geänderten Konfigurationsdaten sofort auch im EPROM neu gespeichert.
* Bugfix: DS18xx-Temperatur-Korrekturwert wurde bisher als RTC-Temperatur-Korrekturwert im EEPROM gespeichert.
* Bugfix: Bei der manuellen Eingabe des aktuellen Datums/Uhrzeit im Webinterface wurde das Jahr bisher als "Zufallszahl" gespeichert, wenn der ESP8266 im AP-Modus läuft, weil kein WLAN vorhanden ist.

===== Version 2.0.7 =====

* URL-Fehler im Web-Interface korrigiert für Rainbow-Geschwindigkeit und Temperatur-Anzeige-Intervall
* Fehlende Berücksichtung der Animation-Geschwindigkeiten in "Random" eingebaut
* Default-Werte für einstellbare Verzögerungen der Animationen auf WC12h verdoppelt

===== Version 2.0.6 =====

* Neue Animation "Drop"
* Neue Animation "Squeeze"
* Geschwindigkeitsregler für sämtliche Animationen
* Angaben von Favoriten für die Animationen, die dann bei der Random-Animation ausgewählt werden sollen
* Geschwindigkeitsregler für Rainbow - sowohl für Display als auch für Ambilight
* Angabe von Temperaturkorrekturen für DS18xx als auch für RTC in Schritten von 0,5°C bei Selbsterwärmung
* LED-Kalibrierung durch Messen vom dunkelsten und hellsten Wert manuell im Web-Interface möglich - ungetestet!
* Clock und Clock2 auf dem Ambilight laufen nun je nach Einstellung in der Display-Farbe oder selbstständig in der Ambilight-Farbe
* Temperatur-Anzeige auf der WC12h nun nicht mehr als Laufschrift, sondern durch zwei große Ziffern auf dem Display. Wenn die Temperatur xx,5°C und nicht xx,0°C beträgt, wird das "standesgemäß" auf der WC12h durch zwei leuchtende Minuten-LEDs angezeigt. Die Anzeige der Minuten-LEDs ist ungetestet.
* Angabe eines Intervalls, wie oft die Temperatur automatisch eingeblendet werden soll. Bei "1" wird die Temperatur einmal pro Minute eingeblendet, nämlich immer um hh:mm:30. Bei Angabe von z.B. "5" passiert das dann halt nur noch alle 5 Minuten. Wird 0 oder nichts eingegeben, wird keine Temperatur automatisch eingeblendet.

===== Version 2.0.5 =====

* Neue Animation: "Matrix".
* Bugfix: Fehler in Timerfunktion am Wochenende behoben.
* Bugfix: Fehlerhafte Offset-Berechnung in Ambilight-Animation "Clock2" korrigiert.

===== Version 2.0.4 =====

* Bugfix: Ambilight leuchtete im Synchronmodus in Rainbow-Animation nach Abschalten durch Timer weiter. Die LEDs werden nun komplett abgeschaltet.
* Bugfix: Getrennte Helligkeitssteuerung des Ambilights wurde durch Helligkeitssteuerung des Displays beeinträchtigt. Nun sind beide Helligkeiten komplett unabängig.
* Bugfix: Wenn die Uhr gem. Timer aus ist, liefen einige Animationen teilweise trotzdem alle 5 Minuten. Ist nun behoben.
* Bugfix: Keine Webserver-Kommunikation möglich, wenn der ESP-01 im AP-Modus ist und in der RTC die Uhrzeit noch nicht initialisiert wurde. Ist nun behoben.
* Neu: Anzeige von Laufschriften
* Ambilight: Sekundenzeiger nun auch für 20 oder 30 LEDs, die Zahl der Ambilight-LEDs ist nun im Webinterface konfigurierbar.
* Ambilight: Neue Sekundenanzeige mit zunehmendem/abnehmendem Vollkreis.
* Ambilight: Sekundenzeiger-Animationen: Start-LED nun über Webinterface konfigurierbar
* Web-Konfiguration: Erweiterung der Schieberegler um numerische Anzeige (zwecks besserer Reproduzierfähikeit von RGB-Werten)

===== Version 2.0.3 =====

* Bugfix: einminütiges Abschalten des Displays nach Cube-Animation behoben.

===== Version 2.0.2 =====

* Um unnötige Animationen zur vollen Minute bei der WC12h zu vermeiden, wird die DCF77-Zeit nun um hh:mm:15 verzögert ausgeliefert. Timeserver-Zugriffe pendeln sich im Laufe der Zeit auf hh:mm:30 (alle 3780 Sekunden) ein, RTC-Zugriffe werden jede Minute um hh:mm:45 ausgeführt.
* Power-Taste auf der IR-Fernbedienung kann nun beim Anlernen als Skip-Taste verwendet werden.
* DCF77-Messung: Die Zeit der vorherigen Minute wird nun als zusätzliche Plausibilitätsprüfung herangezogen
* Snake-Animation: Es werden nun gezielt die Wörter der alten Uhrzeit "gefressen".

===== Version 2.0.1 =====

* Konfiguration von "ES IST"-Anzeige korrigiert: nun auch jede halbe Stunde.
* Bugfix bei der "ES IST"-Anzeige auf WC12h: Die Anzeige wird nun 5 Minuten lang beibehalten - und nicht nur ein Minute.
* Bugfix: Farbanimationen bzw. Ambilight-Animationen verhinderten das Abschalten des Ambilights bei Power-Off.
* Umgebungs-Helligkeitsmessungen werden nun nur noch durchgeführt, wenn keine Übergangs-Animation läuft.
* Anzahl der möglichen Ambilight-LEDs nun bei Verwendung eines Nucleo-Board gleich 100, sonst 60.
* Power-Off-Signal, um LED-Spannungsversorgung abzuschalten, nun beim Mini-Board (STM32F103) auf Pin PB0.
* Fading-Effekt durch kleinere Farbänderungsschritte verstärkt.

===== Version 2.0.0 =====

* Bugfix: Abschalten des Ambilights bei Power-Off-Befehl funktionierte bisher nicht.
* Bugfix: Ein-/Ausschalten der Spannungsversorgung für LED-Stripe.
* Anzeige des Wortes "UHR" zur vollen Stunde hinzugefügt - dort, wo es bisher fehlte. Betrifft nur WC24h.
* Neue Einstellung, ob "ES IST" permanent leuchten soll oder nur zur vollen Stunde.
* Verbesserung der Rainbow-Animation (Dank an Ralf Hammeran).
* Dynamische Anpassung der automatischen Helligkeitssteuerung an die Umgebungshelligkeit (Dank an Ralf Hammeran).
* Neue Übergangs-Animationen: "Snake", "Teletype" und "Cube".
* Anzahl der möglichen Ambilight-LEDs auf 60 Stück begrenzt, siehe auch Ambilight-Modus "Clock" (umlaufende Sekundenanzeige).
* Neue Seite "Ambilight" in der Web-Konfiguration.
* Neue Einstellung, ob Ambilight-Farben synchron zu den Display-Farben angepasst werden sollen oder separat gesteuert werden sollen.
* Neue separate Farbauswahl und Helligkeitssteuerung für Ambilight.
* Neuer Ambilight-Modus "Clock": Umlaufende Sekundenanzeige.
* Neuer Ambilight-Modus "Rainbow": Regenbogenfarben-Animation jetzt auch im Ambilight möglich.
* Diverse kleinere Bugfixes

===== Version 1.9.0 =====

* Neu: Automatischer Farbwechselmodus: Rainbow

===== Version 1.8.9 =====

* Stellen der Uhrzeit über Web-Interface
* Konfiguration über Web-Interface, ob ESP8266 im AP- oder WLan-Client-Modus arbeiten soll
* Einstellung SSID und Key für AP-Modus
* Steuerung der LED-Stripe-Spannungsversorgung (ungetestet)

===== Version 1.8.8 =====

* Für WC12h kleineren Font (5x8) für Laufschriften zwecks besserer Lesbarkeit integriert
* Auswertung des Temperatur-Anzeige-Kommandos per Android App (ab Version 1.7.0)

===== Version 1.8.7 =====

* Fehler in der Wochentagsberechnung korrigiert

===== Version 1.8.6 =====

* Verzögerte Reaktion der Minuten-LEDs (WC12h) bei Farbwechsel behoben

===== Version 1.8.5 =====

* STM32F103 Mini Development Board: Abschalten des JTAGS, um PB3 u.a. als GPIO für z.B. [[IRMP]] nutzen zu können (nicht relevant für Nucleo-Variante)

===== Version 1.8.4 =====

* Korrektur der ESP8266 Flash-Pin-Definition für das STM32F103 Mini Development Board (nicht relevant für Nucleo-Variante)

===== Version 1.8.3 =====

* Bugfix bei der Temperatur-Anzeige: Es wurde immer die DS3231-Temperatur statt der DS128xx-Temperatur gezeigt
* Falsche Temperatur-Anzeige im Modus "Temperatur"
* Bezeichnungen der Anzeigemodi für WC24 gekürzt
* Manuelle Aktivierung des LDRs aus Weboberfläche entfernt. LDR-Messung ist nun immer aktiv, egal ob angeschlossen oder nicht
* Unterstützung des DCF77-Moduls wieder eingebaut
* Anzahl der Nachtschaltzeiten auf 8 erhöht - unter Berücksichtigung der Wochentage

===== Version 1.8.2 =====

* Hangup-Problem bei Aktivieren des LDRs beseitigt
* Neu: Nachtschaltzeiten in der Weboberfläche
* Optimierung des HTML-Code-Generators

===== Version 1.8.1 =====

* Fehler bei HTTP-Get-Parameter-Übergabe von Leerzeichen in SSID behoben

===== Version 1.8.0 =====

* Spezielle Firmware für ESP8266-Modul, da die Espressif-Firmware zu instabil ist und zuviele Varianten existieren
* Kommunikationsprotokoll an neue ESP-Firmware angepasst
* Direktes Flashen des ESP8266 in der WordClock-Schaltung über das verwendete STM32-Board
* Diverse kleinere Bugfixes

'''Änderung: Damit das ESP8266-Modul direkt über das STM32-Board geflasht werden kann, ist die Verbindung ESP8266-GPIO0 zu STM32 PA4 herzustellen, siehe auch: [[WordClock_mit_WS2812#Anschluss_ESP8266|Anschluss ESP8266]]'''

===== Version 1.7.0 =====

* [[MCURSES]]-Monitor durch [[WordClock_mit_WS2812#Web-Interface|WEB-Server]] ersetzt
* Laufschriften-Ausgabe der aktuellen IP-Adresse
* Kleinere Änderungen/Optimierungen
* DCF77-Decoder mangels Interesse/Notwendigkeit entfernt
* Laufschriften-Ausgabe auf dem LED-Display beim Anlernen einer IR-Fernbedienung

===== Version 1.6.3 =====

* WordClock12h: Anzeige der Temperatur durch Laufschrift
* Neue Anschlusspins für TSOP und DS18xxx am STM32F103
* Optimierung des WS2812-DMA-Transfers für STM32F103
* Temperaturmessung mit DS3231, wenn kein DS18xx angeschlossen
* Umstrukturierung der C-Sources

===== Version 1.6.2 =====

* Problem beim Verbindungsaufbau Andoid App -> WordClock behoben

===== Version 1.6.1 =====

* Zusätzliche Unterstützung der "klassischen" WordClock12h mit 10x11 LEDs
* Anpassung der [[MCURSES]]-Monitor-Oberfläche an WordClock12h-Variante
* Portierung auf STM32F103 abgeschlossen (IDE-Projekt folgt mit 1.6.2)
* Zusätzliche Unterstützung von neueren [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Firmware-Versionen 1.0.1, 1.4.0 und 1.5.0.
* Optionales [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Debugging auf zusätzlichem USART - nur für Entwickler

===== Version 1.6.0 =====

* Neben dem TIME-Protokoll (TCP) wird nun auch NTP (UDP) unterstützt - für ESP-Firmware-Versionen ab 0018000902.

===== Version 1.5.9 =====

* Unterstützung der neueren ESP Versionen 0020000903 und AT 0.21.0.0
* Vergrößerung der UART-FIFOs
* Verallgemeinerung der UART-Funktionen zwecks besserer Konfiguration
* Überarbeitung der [[MCURSES]]-Monitor-Oberfläche

===== Version 1.5.8 =====

* Bugfix: Fehler in 1.5.7 (Falsche Behandlung des DMA-Buffers) wurde behoben
* Neu: Bis zu 100 weitere LEDs hinter der Buchstabenkette werden als Ambilight angesteuert

===== Version 1.5.7 =====

* Bug in uart-Code für STM32F103 beseitigt - irrelevant für Nucleo STM324xx
* Timing für WS2812B angepasst, es werden nun WS2812 und WS2812B unterstützt
* Anzahl der möglichen [[WordClock_mit_WS2812#WS2812|WS2812]]-LEDs ist nun variabel gehalten. Das ist Voraussetzung für das demnächst verfügbare Ambilight.

===== Version 1.5.6 =====

* Unterstützung von [[WordClock_mit_WS2812#ESP8266|ESP8266]] mit neuerer Firmware, welche \r\n statt \r erwartet
* Unterstützung von verschiedenen Baudraten des [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Moduls
* Automatische Umschaltung von 9600Bd auf 115200Bd beim [[WordClock_mit_WS2812#ESP8266|ESP8266]]

===== Version 1.5.5 =====

* Optimierungen im LED-Display-Code
* Diverse Anpassungen an STM32F103

===== Version 1.5.4 =====

* Automatische IR-Anlernroutine in den ersten 3 Sekunden ab Programmstart
* Kleiner Bugfix bei den möglichen Helligkeitsstufen (Dimmer)

===== Version 1.5.2 =====

* Anzeige der Firmware-Version des [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Moduls im [[MCURSES]]-Monitor
* Korrektur in den Worttabellen für die Wörter ACHT und VIER in der zehnten Reihe

===== Version 1.5.1 =====

* Manuelle Helligkeitsregelung per [[MCURSES]]-Monitor / IR-Fernbedienung / [[WordClock_mit_WS2812#Android_App|Android App]] eingebaut
* Automatische Helligkeitsregelung per [[WordClock_mit_WS2812#LDR|LDR]] nun über [[MCURSES]]-Monitor / IR-Fernbedienung / [[WordClock_mit_WS2812#Android_App|Android App]] ein-/ausschaltbar

===== Version 1.4.2 =====

* Die geladenen aus dem [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]] RGB-Werte wurden nach dem Boot nicht mehr sofort übernommen. Ist korrigiert.

===== Version 1.4.1 =====

* Initialisierung des ADC korrigiert
* Automatische Helligkeitsregelung dunkelt nicht mehr so stark ab.

===== Version 1.4.0 =====

* Automatische Helligkeitsregelung mittels [[WordClock_mit_WS2812#LDR|LDR]]
* Helligkeitsstufen von 32 auf 64 erhöht
* LED-Testprogramm eingebaut (Taste 'T' im [[MCURSES]]-Monitor)
* Anzeige des [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]]-Typs im [[MCURSES]]-Monitor)
* Unterstützung für Status-LED '''(beachte geändertes LED-Anschluss-Schema!)'''
* [[WordClock_mit_WS2812#Android_App|Android App]] an 64 Helligkeitsstufen angepasst

===== Version 1.3.1 =====

* Sporaisches Hangup-Problem nach Auslesen der Temperatur behoben
* Fehler bei der Erkennung des Family-Codes für [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]] beseitigt
* Optimierung des Zeitverhaltens beim Zugriff auf OneWire-Bus
* Optimierung des [[WordClock_mit_WS2812#WS2812|WS2812]]-Codes

===== Version 1.3.0 =====

* Unterstützung von [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]]-Temperatursensoren
* Temperatur-Anzeige innerhalb +10°C und 39,5°C
* Korrektur Sommerzeitumstellung
* Keine Unterstützung mehr von STM32F4-Discovery

===== Version 1.2.0 =====

* IRMP-Konfigurationsfehler behoben

===== Version 1.1.0 =====

* Animationen hinzugefügt
* Neue Tabellen für Uhrzeit und Temperatur

===== Version 1.0.0 =====

* Test auf verschiedene Adressen des I2C-[[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROMs]]
* [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]-Speicherplatzverbrauch minimiert
* [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]] DS3231-Routinen auf DS1307 verallgemeinert
* Network Listener (UDP) zum Fernsteuern der Uhr über WLAN
* [[WordClock_mit_WS2812#Android_App|Android App]] zum Fernsteuern der Uhr (Ein/Aus, Farben, Anzeigemodus)

===== Version 0.9.1 =====

* [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]-Hexdump im [[MCURSES]]-Monitor eingebaut
* Zusätzliche Waitstates beim Beschreiben des [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROMs]]

===== Version 0.9 =====

* Zusätzlicher Anschluss von RST und CH_PD des [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Moduls
* Verbesserung der [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Konfiguration dank Hardware-Reset
* Nutzung des Stromsparmodus im [[WordClock_mit_WS2812#ESP8266|ESP8266]], wenn die Anzeige abgeschaltet wird
* Konfiguration der Zeitzone über [[MCURSES]]-Monitor
* Test und Überarbeitung der [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]] und [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]-Funktionen
* Synchronisation der [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]-Zeit mit dem µC-Timer
* Speichern folgender Daten im [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]:

EEPROM-Version
IRMP-Daten einer angelernten IR-Fernbedienung
Aktuell eingestellte Farben und Anzeigemodus
IP-Adresse des Timeservers
Zeitzone

===== Version 0.8 =====

* Neue IR-Fernbedienungs-Tasten POWER und OK
* Einbau einer konfigurierbaren "Nachtzeit", in der sich die Uhr selbstständig abschaltet
* Konfiguration des Timeservers über [[MCURSES]]-Monitor
* Speichern/Laden sämtlicher Konfigurations-Daten in externem EEPROM
* Initialisierung des [[WordClock_mit_WS2812#ESP8266|ESP8266]] verbessert (warten, bis nach PowerOn eine WLAN-Verbindung besteht)
* Aufteilung der Anzeige-Logik und des [[MCURSES]]-Monitors auf dsp.c und monitor.c
* Aufteilung der [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Routinen auf esp8266.c (low-level) und timeserver.c (high-level)
* Diverse Optimierungen - u.a. durch Einsatz von uint_fast8_t
* Diverse Bugfixes

===== Version 0.7.1 =====

* Portierung der Software auf STM32F411RE [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]

===== Version 0.7 =====

* Portierung der Software auf STM32F401RE [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]
* uart2.c generalisiert auf uart.c (verschiedene UARTs möglich)
* Bugfix im UART-Ringbuffer-Code (Interrupt-Sperre)
* Anzeige der Online-Devices ([[WordClock_mit_WS2812#ESP8266|ESP8266]], DCF77, EEPROM, [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]) im Terminal
* Verschiedene Optimierungen

===== Version 0.6 =====

* Konfiguration des WLAN-Moduls (SSID & Key) nun über Terminal statt fest im Code verdrahtet.
* Einstellung der Zeitzone möglich. Standard ist GMT+1, also mitteleuropäische Zeit.
* DCF77- und [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul-Aktivierung automatisch - keine Einstellung mehr im Code notwendig.
* I2C-Lib hinzugefügt (noch ungetestet und daher noch nicht verwendet).
* I2C-[[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]-Modul hinzugefügt (noch ungetestet und daher noch nicht verwendet).
* I2C-[[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]-Modul (DS3231) hinzugefügt (noch ungetestet und daher noch nicht verwendet).

Hilfe:Bearbeitungshilfe

2016-08-19T19:40:44Z

Newgeneration: Änderung 93659 von 201.219.210.26 (Diskussion) rückgängig gemacht.

== Umfangreiche Hilfe ==
Umfangreiche Hilfe befindet sich auch hier: 
'''[http://de.wikipedia.org/wiki/Hilfe:Bearbeiten de.Wikipedia.org/wiki/Hilfe:Bearbeiten]'''

== Überschriften ==

<pre>
== Überschrift ==
=== Unter-Überschrift ===
==== Unter-Unter-Überschrift ====
...
</pre>

== Formatierung ==
Eine ausführlichere Beschreibung der Gliederungs- und Formatierungsmöglichkeiten findet sich im Wikipedia Online-Lexikon: http://de.wikipedia.org/wiki/Hilfe:Bearbeitungshilfe

{| border="0"
|-
|''kursiv''
|<nowiki>''kursiv''</nowiki>
|-
|'''fett'''
|<nowiki>'''fett'''</nowiki>
|-
|unterstrichen
|<nowiki>unterstrichen</nowiki>
|-
|<s>durchgestrichen</s>
|<nowiki><s>durchgestrichen</s></nowiki>
|-
|hochgestellt
|<nowiki>hochgestellt</nowiki>
|-
|tiefgestellt
|<nowiki>tiefgestellt</nowiki>
|-
|
Festbreitenschrift
|<nowiki><Leerzeichen>Festbreitenschrift</nowiki>
|-
|
:Eingerückt
|<nowiki>:Eingerückt</nowiki>
|}

== Mathematische Formeln mit LaTex ==

[https://de.wikipedia.org/wiki/Hilfe:TeX LaTex auf Wikipedia]

== Listen ==
Es ist zu beachten, dass Leerzeilen zwischen den Aufzählungen auch zu einem semantischen Bruch führen.
{| border="0"
|-
|<tt><nowiki>* eins</nowiki> 
<nowiki>* zwei</nowiki> 
<nowiki>** zwei-eins</nowiki> 
<nowiki>** zwei-zwei</nowiki> 
<nowiki>* drei</nowiki></tt>
|
* eins
* zwei
** zwei-eins
** zwei-zwei
* drei
|-
|<tt><nowiki>
# eins</nowiki> <nowiki>
# zwei</nowiki> <nowiki>
## zwei-eins</nowiki> <nowiki>
## zwei-zwei</nowiki> <nowiki>
# drei</nowiki></tt>
|
# eins
# zwei
## zwei-eins
## zwei-zwei
# drei
|}

== Einbinden von Sourcecode ==

<code><nowiki><c>C-Code</c></nowiki></code>

Beispiel:

<c>
int main(void) {
return 0;
}
</c>

<code><nowiki><avrasm>AVR Assembler-Code</avrasm></nowiki></code>

Beispiel:

<avrasm>
; Mach fast nix!
.org 0x0000
Start:
LDI r16, 42
RJMP Start
</avrasm>

<code><nowiki><vhdl>VHDL-Code</vhdl></nowiki></code>

<vhdl>
-- Kommentar in VHDL
process(clk)
begin
if rising_dedge(clk) then
data <= data_in;
end if;
end process;
</vhdl>

<code><nowiki><pre>Sonstige Texte mmit fester Formatierung</pre></nowiki></code>

<pre>
Hallo Welt!
Leerzeichen bleiben, feste Zeichenbreite.
Geht auch für ASCII-Art
</pre>

== Einfügen von Bildern oder Dateien ==

''Hierfür ist [[Spezial:Anmelden|Anmeldung]] erforderlich!''

=== Bild erstellen ===
* Fotos müssen nicht von Hand verkleinert werden, sondern können bis 2 MB groß hochgeladen werden.
* Falls mit einem Vektorzeichenprogramm (z.B. [http://www.inkscape.org/ Inkscape]) gearbeitet wird, bitte das SVG-Format verwenden (erlaubt nachträgliche Bearbeitung durch andere!)
* Für Zeichnungen/Schaltpläne ist ansonsten das PNG-Format am besten geeignet, JPEG nur für Fotos/Scans verwenden, siehe [[Bildformate]].

=== Datei/Bild hochladen und einfügen ===

Siehe auch: [[Bebilderung]]

# Dort, wo das Bild erscheinen (oder die Datei verlinkt werden) soll, den Code <code><nowiki>[[Bild:AVR-Programmer.png]]</nowiki></code> in den Text einfügen (beliebiger Dateiname, aber mit richtiger Endung!).
# In der Vorschau oder der gespeicherten Seite auf den Platzhalter-Link "Bild:AVR-Programmer.png" klicken. Vorsicht, nicht gespeicherte Änderungen gehen verloren!
# Datei auswählen, ggf. Beschreibung eingeben und hochladen (wird automatisch umbenannt).

=== Größe festlegen ===

Folgender Code skaliert das Bild automatisch auf 200 Pixel Breite: <code><nowiki>[[Bild:AVR-Programmer.png|</nowiki>'''200px'''<nowiki>]]</nowiki></code>

== Tabellen ==

Für eine ausführlichere Liste und Beschreibung möglicher Features sei auf [http://de.wikipedia.org/wiki/Hilfe:Tabellen Wikipedia Hilfe:Tabellen] und [http://de.wikipedia.org/wiki/Hilfe:Tabellen-Referenz Wikipedia Hilfe:Tabellen-Referenz] verwiesen.

{| class="wikitable"
|+ '''Tabellen-Überschrift'''
|-
! Überschrift links || Überschrift rechts
|-
| links oben || rechts oben
|-
| links mitte || rechts mitte
|-
| links unten || rechts unten
|}

<pre>
{| class="wikitable"
|+ '''Tabellen-Überschrift'''
|-
! Überschrift links || Überschrift rechts
|-
| links oben || rechts oben
|-
| links mitte || rechts mitte
|-
| links unten || rechts unten
|}
</pre>

Um sortierbare Tabellen zu erhalten fügt man statt <tt> class="wikitable" </tt> folgendes ein: <tt> class="wikitable sortable" id="tabellexyz" </tt>

== Richtlinien ==

=== Links zu verwandten Artikeln und externen Seiten ===

Für '''interne''' Links zu verwandten Artikeln legt man einen Bereich nach dem folgenden Muster an:

<pre>
== Siehe auch ==
* [[Test]]
* [[Foobar]]
</pre>

Ähnlich bei '''externen''' Links:

<pre>
== Weblinks ==
* http://url1/
* http://url2/
* [http://url3/ Seite 3 hat einen Linktext]
</pre>

=== Link für Nachricht an eine Person/Autor ===

<pre>[http://www.mikrocontroller.net/user/show/Username_aus_Forum Alternativer Text]</pre>

[http://www.mikrocontroller.net/user/show/andreas Alternativer Text]

== Artikel löschen ==
Um eine Seite zur Löschung vorzuschlagen, auf der Seite diesen Baustein hinzufügen:

<nowiki>
{{Vorlage:Löschen|Deine Begründung...}}
</nowiki>

Näheres [http://www.mikrocontroller.net/articles/Kategorie:L%C3%B6schkandidaten hier] oder [http://www.mikrocontroller.net/topic/319411 hier]

[[Kategorie:Tipps für Autoren]]

Cortex-A

2016-08-17T22:01:51Z

Newgeneration: Unterschiede zum Cortex-M erläutert und Tabelle aller Cortex-A

ARM Cortex-A sind von [[ARM]] konstruierte Prozessorkerne, wie sie zusammen mit dem Vorläufer ARM11 und einigen unabhängigen Implementierungen der ARM-Architektur in nahezu jedem Smartphone und Tablet verbaut sind.

ARM bezeichnet die Prozessorlinien folgendermaßen<ref>http://arm.com/products/processors/index.php</ref>:

;ARM Cortex Embedded Processors: Cortex-M Series – Cost-sensitive solutions for deterministic microcontroller applications
;ARM Cortex Real-time Embedded Processors: Cortex-R Series – Exceptional performance for real-time applications
;ARM Cortex Application Processors: Cortex™-A and Cortex-A50 Series – High performance processors for open Operating Systems

Sie sind deutlich leistungsstärker als ARM Cortex M Mikroprozessoren, daher werden Sie eher im Application-Bereich, sprich mit Betriebssystemen Linux (z.B. Debian, Arch Linux ARM, Android), Windows Mobile etc. eingesetzt.

{| class="mw-collapsible mw-collapsed wikitable"
|+ Offizielle Beschreibungen aller Cortex-A Prozessoren von ARM
|-
! ARM Core || Key Benefits
|-
| Cortex-A5 ||
* ARM’s smallest application processor with Uniprocessor (UP) and Multiprocessor (MP) licensing options
* Extremely configurable processor with optional NEON, optional FPU and L1 caches configurable from 4K-64KB
* Full feature set of Cortex-A9 processor at one third the area and power
|-
| Cortex-A7 ||
* ARMv7-A architectural extensions (40-bit physical addressing, hardware virtualization support)
* More than 20% improvement in single thread integer performance compared to Cortex-A5
* Integrated L2 cache subsystem provides improved area efficiency and up to 43% improvements in memory streaming performance
* Proven successful design, now well matched to the needs of wearable mobile devices and other UI-based consumer products
|-
| Cortex-A8 ||
* Large increase in single thread performance over it’s predecessor, the ARM11
* ARMv7-A support including NEON and TrustZone
* Widely deployed in mobile and embedded, with numerous low-cost 3rd party development platforms. A great processor on which to learn the ARM architecture.
|-
| Cortex-A9 ||
* Scalable performance and power efficiency for a broad range of 32-bit consumer, networking, enterprise and mobile applications
* Support the wide ARMv7-A 32-bit software eco-system
* Mature and silicon proven in multiple process technologies
|-
| Cortex-A15 ||
* Established ARMv7-A processor with NEON-VFP configurability
* Reliable 32-bit infrastructure computing with 1TB addressing
* Support for multi-tenant software virtualization
|-
| Cortex-A17 ||
* Highest performance for ARMv7-A software ecosystem
* Cost efficiency with premium 32-bit performance for mass-market devices
* Mature and shipped in a wide range of consumer and embedded markets
|-
| Cortex-A32 ||
* ARMv8-A architectural enhancements, full backwards compatibility with ARMv7-A software
* Higher efficiency and performance compared to Cortex-A7 processor
* New idle power management features
* Highly scalable 32-bit processor with new configuration options
|-
| Cortex-A35 ||
* Most efficient 64-bit ARMv8-A processor with full ARMv7-A compatibility
* Efficiency improvements compared to the Cortex-A7: Less active power, improved performance
* Highly scalable ARMv8-A processor with new configuration options
|-
| Cortex-A53 ||
* High efficiency CPU for wide range of applications in mobile, DTV, automotive, networking, and more
* ARMv8-A architecture at low cost for standalone entry level designs
* Versatile enough to pair with any ARMv8 core in a big.LITTLE pairing, including Cortex-A57, Cortex-A72, or even other Cortex-A53 or Cortex-A35 CPU clusters
* Mature product with high volume shipment
|-
| Cortex-A57 ||
* Established ARMv8-A 64-bit processor
* Reliable 64-bit infrastructure computing with 16TB addressing
* Proven functional safety documentation package
|-
| Cortex-A72 ||
* ARM’s state-of-the-art high-performance processor for infrastructure, mobile, and automotive
* Market-leading compute density across all application form factors
* Improved performance and efficiency, with full ARMv8-A 64b support.
|-
| Cortex-A73 ||
* Highest performance in mobile power envelope. Up to 30% higher performance than previous generation.
* Up to 2.8GHz frequency for highest peak performance
* New levels of sustained usage for the best user experience. Up to 30% increased power efficiency
* Smallest premium ARMv8-A processor ever. Premium CPU under 0.65mm2 per core.
|}

== Unterschiede zum Cortex-M ==

Die Unterschiede zu den Cortex-M Mikrocontrollern sind unter anderem folgende:
* Teilweise 64 bit Prozessoren, mit vergrößertem Adressraum (44 bit oder mehr statt 32 bit)
* Kein On-Chip Speicher (meist ein geringes RAM vorhanden, aber ein externes ist so gut wie immer trotzdem nötig) macht externes Speicherinterface nötig, was viele Pins nutzt. Auch braucht man natürlich extra Speicher- und (DDR)-SDRAM-ICs.
* Mehrere Levels von Data und Instruction Caches
* Gehäuse mit wesentlich mehr Pins, meist im BGA
* Höhere Taktfrequenz (mehr als 500 MHz sind keine Seltenheit, aktuell maximal 2.8 GHz)
* ARM big.LITTLE Konzept: mehrere "kleine" Cortex-A-Cores werden zusammen mit mehreren "großen" Cores verschalten, um Enegie zu sparen: wenn wenig Leistung nötig ist werden die energieeffizierteren Cores benutzt, bei hohen Leistungsanforderungen übernehmen die anderne Cores
* ARM Jazelle für die beschleunigte Ausführung von Java-Code
* Sicherheitsmechanismen, wie eine [[MMU]] oder die ARM TrustZone Technologie
* Optional eine NEON™ Media Processing Engine
* Schnellere und präzisere [[FPU]]
* Kryptographie, wie AES- und SHA-Algorithmen, True-Random-Generators
* Digitale Interfaces, die man eher aus dem PC-Bereich kennt, wie HS-USB-Hosts, schnelles Ethernet, SD/MMC Interface, Kamera- oder Video-Dekoder, I²S, ...
* Dazu kommen aber auch klassische Mikrocontroller-Interfaces, wie UART, I²C, SPIs, interne ADCs und DACs, sowie Timer
''(für alle oben genannten Fälle gibt es natürlich auch Ausnahmen)''

Einige der oben genannten Punkte finden sich neuerdings auch in Cortex-M7-Controllern, die damit die Brücke zwischen Mikrocontrollern und Anwendungsprozessoren schlagen.

Größter Nachteil für diese Leistungsfähigen Controller wird das fehlen von On-Chip Flash und RAM sein, weil man so extra ICs braucht, was wiederum das layouten erschwert, da ein DDR3-RAM-Design nicht mehr sonderlich einfach ist.

== Links ==

* [http://www.arm.com/products/processors/cortex-a/index.php?tab=Multicore Offizielle ARM Seite zu der Cortex-A Serie]
* [[Linux Boards]]
* [[Raspberry Pi Einführung]]

<references/>

[[Kategorie:ARM]]

MPU

2016-08-17T20:46:30Z

Newgeneration: Ergänzung zum Stack

Mit dieser Abkürzung ist nicht der "Idiotentest", die sogenannte Medizinisch-Psychologische Untersuchung gemeint, sondern ein Hardwareteil in einem Prozessor: die '''Memory Protection Unit'''. Diese dient dazu, wie der Name schon sagt, den Hauptspeicher vor unerlaubten Zugriffen zu schützen.

Um ihren Zweck zu erfüllen teilt die MPU den Speicher in mehrere Regionen, die alle definierte Eigenschaften haben:
* einen festen Ort und feste Größe
* Speicher Attribute (Read, Write, Execute)
* Zugriffsrechte

Die MPU löst beim Verletzen der Zugriffsrechte einen sogenannten Fault aus, ähnlich einem Interrupt: ein Handler wird angesprungen und man kann auf den Fehler reagieren, zum Beispiel eine Fehlermeldung, Eintrag in ein Log, Memory-Dump, Breakpoint beim Debuggen, etc.

Gerade beim Stack kann es helfen, diesen zu schützen. Damit bei einer Kollision mit dem Heap oder Gobalen Variablen (bzw. beim Verlassen seiner Memory Region) einen Kontrollierten Absturz gibt, der dann auch abgefangen und geloggt werden kann.

Eine MPU kann dazu genutzt werden, um
* eine erhöhte Sicherheit bei der Code-Ausführung zu erreichen
* verschiedene Privilegien-Level in einer Anwendung
* Strikte Trennung von Code, Daten und Stack (auch zwischen verschiedenen Tasks)

= Implementierungen =
Kleine 8bit-Controller, wie z.B. die AVRs haben meist keine MPU, da Anwendungen auf diesen Controllern meist ohne Betriebssystem oder mehrere Tasks ausgeführt werden.

Auf größeren Controllern macht eine MPU mehr Sinn, weswegen die Hersteller den zusätzlichen Aufwand in Kauf nehmen und diese implementieren.
ARM Cortex-M außer dem Cortex-M0 und dem Coretx-M1 haben eine optionale MPU. Der Hersteller kann auswählen, ob eine MPU mitintegriert werden soll.
Auch einige MSP430 Controller haben eine Memory Protection Unit.

Größere Mikrocontroller, wie die Cortex-A, haben meist keine MPU, sondern eine komplette [[MMU]] (Memory Management Unit), mit dem "richtige" Betriebssysteme möglich sind.

[[Kategorie:Mikrocontroller]]
[[Kategorie:ARM]]

MPU

2016-08-17T15:43:45Z

Newgeneration: Erstellung des Artikels

Mit dieser Abkürzung ist nicht der "Idiotentest", die sogenannte Medizinisch-Psychologische Untersuchung gemeint, sondern ein Hardwareteil in einem Prozessor: die '''Memory Protection Unit'''. Diese dient dazu, wie der Name schon sagt, den Hauptspeicher vor unerlaubten Zugriffen zu schützen.

Um ihren Zweck zu erfüllen teilt die MPU den Speicher in mehrere Regionen, die alle definierte Eigenschaften haben:
* einen festen Ort und feste Größe
* Speicher Attribute (Read, Write, Execute)
* Zugriffsrechte

Die MPU löst beim Verletzen der Zugriffsrechte einen sogenannten Fault aus, ähnlich einem Interrupt: ein Handler wird angesprungen und man kann auf den Fehler reagieren, zum Beispiel eine Fehlermeldung, Eintrag in ein Log, Memory-Dump, Breakpoint beim Debuggen, etc.

Eine MPU kann dazu genutzt werden, um
* eine erhöhte Sicherheit bei der Codeausführung zu erreichen
* verschiedene Privilegien-Level in einer Anwendung
* Strikte Trennung von Code, Daten und Stack (auch zwischen verschiedenen Tasks)

= Implementationen =
Kleine 8bitter, wie z.B. die AVRs haben meist keine MPU, da Anwendungen auf diesen Controllern meist ohne Betriebssystem oder mehrere Tasks ausgeführt werden.

Auf größeren Controllern macht eine MPU mehr Sinn, weswegen die Hersteller den zusätzlichen Aufwand in Kauf nehmen und diese implementieren.
ARM Cortex-M außer dem Cortex-M0 und dem Coretx-M1 haben eine optionale MPU. Der Hersteller kann auswählen, ob eine MPU mitintegriert werden soll.
Auch einige MSP430 Controller haben eine Memory Protection Unit.

Größere Mikrocontroller, wie die Cortex-A, haben meist keine MPU, sondern eine komplette [[MMU]] (Memory Management Unit), mit dem "richtige" Betriebssysteme möglich sind.

[[Kategorie:Mikrocontroller]]
[[Kategorie:ARM]]

ARM Cortex Mikrocontroller

2016-08-02T13:10:52Z

Newgeneration: Aktualisierung der ARM-Controller aus den Portfolios der Hersteller Atmel und NXP

Die Firma ARM stellt selbst keine Prozessoren/Controller her, sondern entwickelt nur sogenannte "IP-Cores", die von Herstellern wie Atmel, Infineon, ST, NXP, TI und vielen anderen lizenziert werden. Diese Hersteller ergänzen den Core um Speicher und Peripherie. Der Vorteil dieses Modells ist, dass dadurch sehr viele Prozessoren mit unterschiedlichster Ausstattung verfügbar sind, die alle mit dem selben Befehlssatz (und damit dem selben Compiler) programmierbar sind.

Allen ARM-Cores gemeinsam ist die 32 Bit RISC-Architektur. Für diese gibt es den klassischen 32bit ARM Befehlssatz und den zusätzlichen, kleineren 16/32 Bit '''Thumb'''-Befehlssatz. Die verschiedenen Prozessoren/Controller unterstützen einen oder beide davon. Thumb-fähige Controller sind erkennbar am '''T''' in der Bezeichnung, z. B. ARM7'''T'''DMI. Thumb kodiert die meisten Instruktionen in 16bit, den Rest in 32bit, was in einem kleineren Prozessor und geringenem Platzbedarf des Codes resultiert [http://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_%28full%29.pdf]; der Nachteil ist die etwas niedrigere Geschwindigkeit. Die Cortex-M Kerne unterstützen ausschließlich den Thumb2-Befehlssatz.

Seit einigen Jahren sind ARM-basierte Mikrocontroller erhältlich, die aufgrund der vergleichbar einfachen Beschaltung und niedrigem Stromverbrauch eine echte Alternative zu 8-Bit-Controllern wie dem [[AVR]] darstellen. Die ersten Controller mit diesen Eigenschaften verwendeten den ARM7TDMI-Kern (zB. LPC2000) (ARMv4T-Architektur). Mittlerweile wurden diese vom Cortex M-Kern abgelöst (ARMv6M, ARMv7M-Architektur), welcher in verschiedenen Varianten für verschiedene Einsatzzwecke verfügbar ist.

'''In diesem Artikel geht es primär um die ARM Cortex-M Mikrocontroller, weniger um ARM [[Cortex-A]] Prozessoren, welche in Smartphones, [[Raspberry Pi]] u.ä. eingesetzt werden.'''

Es gibt folgende Varianten des Cortex-M Mikrocontroller-Kerns, aufgeführt vom energieeffizientesten zum leistungsfähigsten (Liste nicht unbedingt aktuell! Am besten immer die Herstellerseiten bemühen).

== ARM Cortex M0/M0+ ==
=== ARM Cortex M0 ===
Als günstigste und energieeffizienteste Variante gibt es die Cortex-M0 Cores mit deutlich kleinerem Befehlssatz als z.B. Cortex-M3. Diese
werden beispielsweise in folgenden Controllern eingesetzt:

* [http://www.st.com/internet/mcu/subclass/1588.jsp?WT.ac=fp_may12_stm32f0 STM32F0] von [http://www.st.com STMicro], siehe '''[[STM32|STM32 hier im Wiki]]'''
* [http://ics.nxp.com/products/lpc1000/lpc11xx/ LPC11xx] von [http://www.nxp.com NXP], siehe '''[[LPC1xxx|LPC1xxx hier im Wiki]]'''
* [http://www.infineon.com/XMC1000 XMC1000] von [http://www.infineon.com Infineon], siehe '''[[XMCxxxx|XMCxxxx hier im Wiki]]'''
* [http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=5dbf7d7a-b6df-4fe1-91c9-063449500ce7 NuMicro-Controller] von Nuvoton (ex Winbond), laut Datenblatt mit 2.5-5.5V Betriebsspannung!
* [http://www.cypress.com/PSOC4 PSOC4 Familie] von [http://www.cypress.com Cypress]
Für die M0-Familie ist für den LPC1xxx bereits eine '''[http://www.mikrocontroller.net/articles/Codebase_f%C3%BCr_LPC1xxx#Allgemeine_Informationen_zum_Aufbau_der_Code_Base Code-Base]''' und ein preisgünstiges '''[http://www.mikrocontroller.net/wikisoftware/index.php?title=LPC1xxx_Entwicklungskit_LPCXpresso Entwicklungskit]''' vorhanden.

=== ARM Cortex M0+ ===

Inzwischen gibt es auch eine optimierte Version des Cortex-M0 - die Cortex-M0+ Cores. Diese können (optional) einige Features der Cortex-M3 Serie beinhalten, wie z.B eine MPU:

* [http://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx EFM32 Zero Gecko] und [http://www.silabs.com/products/mcu/32-bit/efm32-happy-gecko/pages/efm32-happy-gecko.aspx EFM32 Happy Gecko] von [http://www.silabs.com Silicon Labs], siehe '''[[EFM32|EFM32 hier im Wiki]]'''
* [http://www.nxp.com/products/microcontrollers/cortex_m0plus/lpc800/ LPC8xx] von [http://www.nxp.com NXP]
* [http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=KINETIS_L_SERIES Kinetis L-Serie] und [http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=KINETIS_M_SERIES Kinetis M-Serie] von [http://www.freescale.com/ Freescale]
* [http://www.fujitsu-fm-family.com/products/fm0.html angekündigte FM0+ Familie] von [http://www.fujitsu.com/emea/services/microelectronics Fujitsu]
* [http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1817?icmp=ss1817_pron_pr_feb2014 angekündigte M0+ Familie] von [http://st.com STMicroelectronics]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-C.aspx SAM C Familie] von [http://www.atmel.com/default.aspx Atmel] (5V Versorgungsspannung, nicht nur 5V-tolerant)
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-D.aspx SAM D Familie] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.cypress.com/PSOC4 PSOC4 Familie] von [http://www.cypress.com Cypress]

== ARM Cortex M3 ==
Der erste Kern der Cortex M-Reihe war der Cortex-M3. Dieser ist vom Leistungsniveau her am ehesten mit seinem Vorgänger, dem ARM7TDMI vergleichbar.

Controllerfamilien dieser Klasse sind:

* [http://www.silabs.com/products/mcu/32-bit/efm32-tiny-gecko/pages/efm32-tiny-gecko.aspx EFM32 Tiny Gecko], [http://www.silabs.com/products/mcu/32-bit/efm32-gecko/pages/efm32-gecko.aspx EFM32 Gecko], [http://www.silabs.com/products/mcu/32-bit/efm32-leopard-gecko/pages/efm32-leopard-gecko.aspx EFM32 Leopard Gecko] sowie [http://www.silabs.com/products/mcu/32-bit/efm32-giant-gecko/pages/efm32-giant-gecko.aspx EFM32 Giant Gecko] von [http://www.silabs.com Silicon Labs] , siehe '''[[EFM32|EFM32 hier im Wiki]]'''
* [http://www.nxp.com LPC13xx/LPC17xx/LPC18xx] von NXP oder die inzwischen schon sehr ausführliche, siehe '''[[LPC1xxx|LPC1xxx hier im Wiki]]'''
* [http://www.ti.com/lsds/ti/microcontroller/tiva_arm_cortex/c_series/tm4c_arm_cortex-m4/overview.page TIVA] von [http://www.ti.com Texas Instruments] (vormals Stellaris, vormals Luminary Micro)
* [http://www.atmel.com/products/microcontrollers/arm/default.aspx SAM3N, SAM3S,SAM3U, SAM3A und SAM3X Serien] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.st.com/internet/mcu/family/141.jsp STM32] Baureihen [http://www.st.com/internet/mcu/subclass/1169.jsp F1]/[http://www.st.com/internet/mcu/subclass/1520.jsp F2]/[http://www.st.com/internet/mcu/subclass/1376.jsp L1]/[http://www.st.com/internet/mcu/subclass/1377.jsp W] von STMicroelectronics , siehe '''[[STM32|STM32 hier im Wiki]]'''
* [http://www.toshiba-components.com/microcontroller/TMPM330.html TMPM330] von Toshiba
* [http://www.spansion.com/Products/microcontrollers/32-bit-ARM-Core/fm3/Pages/FM3-family.aspx FM3] von [http://www.spansion.com Spansion] (vormals Fujitsu)
* [http://www.holtek.com.tw/english/products/32bit_flashmcu.htm HT32] von Holtek Semiconductor
* [http://www.cypress.com/PSOC5 PSOC5] von Cypress

Für den LPC1xxx ist bereits eine '''[http://www.mikrocontroller.net/articles/Codebase_f%C3%BCr_LPC1xxx#Allgemeine_Informationen_zum_Aufbau_der_Code_Base Code-Base]''' und ein preisgünstiges '''[[LPC1xxx_Entwicklungskit_LPCXpresso]]''' vorhanden.

== ARM Cortex M4 ==
Als hoch performante Variante gibt es dann noch die Cortex-M4 Cores welche im Kern aus einem Cortex-M3 mit zusätzlichen [[DSP]]-Funktionen und teilweise einer (single precision) FPU bestehen.

Diese werden beispielsweise in folgenden Controllern eingesetzt:
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus:KINETIS Kinetis Series] von Freescale (jetzt NXP)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc4300-cortex-m4-m0:MC_1403790133078 LPC43xx] von [http://www.nxp.com/ NXP] (Dual Core: M4F + bis zu 2 Cortex-M0)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc54000-low-power-cortex-m4:MC_1414576688124 LPC54xxx] von [http://www.nxp.com/ NXP] (Dual Core: M4F + bis zu einem Cortex-M0+)
* [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m4/lpc4000-cortex-m4:MC_1403790399405 LPC4xxx] von [http://www.nxp.com/ NXP]
* [http://www.silabs.com/products/mcu/32-bit/efm32-wonder-gecko/pages/efm32-wonder-gecko.aspx EFM32-Wonder Gecko] von [http://www.silabs.com Silicon Labs], siehe '''[[EFM32|EFM32 hier im Wiki]]'''
* [http://www.st.com/internet/mcu/subclass/1605.jsp STM32F3] von [http://www.st.com STMicro], siehe '''[[STM32|STM32 hier im Wiki]]'''
* [http://www.st.com/internet/mcu/subclass/1521.jsp?WT.ac=p2_bn_jun12_stm32f4series STM32F4] von [http://www.st.com STMicro], siehe '''[[STM32|STM32 hier im Wiki]]'''
* [http://www.ti.com/lsds/ti/microcontroller/tiva_arm_cortex/c_series/tm4c_arm_cortex-m4/overview.page Tiva C Series, TM4C] von [http://www.ti.com Texas Instruments]. Früher nannte Texas Instruments diese Controller ''Stellaris LM4F Series''. 2013 begann TI mit einer große Umbenennung, bei der sogar neue Typenbezeichnung vergeben wurden. So wurde zum Beispiel aus dem LM4F230H5QR der TM4C123GH6PM. Gleichzeitig begann TI die Bezeichnung ''Stellaris'' aus Datenblättern, Software-Bibliotheken und Ähnlichem zu entfernen und durch ''Tiva'' zu ersetzen. Siehe auch [http://www.ti.com/lit/an/spma050a/spma050a.pdf].
* [http://www.infineon.com/XMC4000 XMC4000] von [http://www.infineon.com Infineon], siehe '''[[XMCxxxx|XMCxxxx hier im Wiki]]''', [[XMC4500|Artikel zum XMC4500]]
* [http://www.spansion.com/Products/microcontrollers/32-bit-ARM-Core/fm4/Pages/default.aspx FM4] von [http://www.spansion.com Spansion] (vormals Fujitsu)
* [http://www.atmel.com/products/microcontrollers/arm/sam4l.aspx SAML] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/arm/sam4e.aspx SAME] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/arm/sam4n.aspx SAMN] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/arm/sam4s.aspx SAMS] von [http://www.atmel.com/default.aspx Atmel]

== ARM Cortex M7 ==

Die neueste Variante der Cortex M-Reihe ist der M7, bei dem gegenüber dem M4 zahlreiche Features hinzukommen die die Brücke zu Anwendungsprozessoren schlagen: eine double precision-FPU, Code- und Daten-Cache, eine 6-stufige Pipeline mit Sprungvorhersage, und unterm Strich eine deutlich höhere Rechenleistung. Controller basierend auf dem Cortex M7 sind u.a. von Atmel und ST erhältlich.

* [http://www.atmel.com/products/microcontrollers/ARM/SAM-E.aspx SAME] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-S.aspx SAMS] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/SAM-V.aspx SAMV] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/sam7s_se.aspx SAM7S/SE] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.atmel.com/products/microcontrollers/ARM/sam7x_xc.aspx SAM7X/XC] von [http://www.atmel.com/default.aspx Atmel]
* [http://www.st.com/web/en/catalog/mmc/SC1169/SS1858 Produktseite der STM32F7-Serie von ST]

== ARM7TDMI ==
Der Vorgänger der Cortex-M-Cores ist der '''ARM7'''TDMI. Controllerfamilien dieser Klasse sind immer noch weit verbreitet:
* NXP (ehemals Philips) [[LPC2000]]
* Atmel [[AT91SAM]]7
* Analog Devices [[ADuC7xxx]]
* [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=203&familyId=454 Texas Instruments TMS470]
* SAMSUNG S3C24x0 [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2410]
* STR7xx von ST Microelectronics [http://www.st.com/mcu/inchtml-pages-str7.html]
* und viele weitere

Mehr Informationen zur ARM-Architektur finden sich in der [http://de.wikipedia.org/wiki/ARM-Architektur Wikipedia], weiterführende Links in der [[Linksammlung#ARM|Linksammlung]].

== Compiler & Software ==

=== [[ARM_GCC|GCC]] ===
Einer der beliebtesten Compiler für ARM-Prozessoren ist der GCC. Er kann sowohl ARM- als auch Thumb-Code erzeugen. Mehr dazu unter [[ARM GCC]].

=== C/C++ IDEs ===
Kostenlose Entwicklungsumgebungen (überwiegend GCC-basiert):
* [http://www.coocox.org/CooCox_CoIDE.htm CooCox IDE] (Eclipse basierend)
* [http://www.emblocks.org/web/ EmBlocks IDE] (Basiert auf Code::Blocks)
** Compiler: GNU ARM-GCC (in der Installation enthalten), RealView und IAR
** Hardware: STlink (mit "Live data"), openOCD, Jlink.
** Project Import: CoIDE, uVision, Atmel studio, MplabX, Mplab 8
** OS aware debugging
***FreeRTOS
***ChibiOS/RT
** Unterstützt sehr viele Controller(-Hersteller):
***Atmel-ARM
***NXP-ARM
***STMicro-ARM
***EnergyMicro-ARM
**Keine Beschränkungen
**Hier gehts zum ''[http://www.emblocks.org/web/downloads-main Download]'''
* [http://www.emide.org/ emIDE] Windows, komplette Visual Studio artige Entwicklungsumgebung (basierend auf Code::Blocks) mit GCC und Debugger (Unterstützung für Adapter von Segger) 
* [https://mbed.org mbed]: eine kostenlose Online-Entwicklungsumgebung basierend auf dem ARM Realview-Compiler, mit einer umfangreichen C++-Bibliothek für die Controllerfunktionen, integrierter Versionsverwaltung, und vielen Beispielprogrammen. Projekte lassen sich für Keil/IAR/GCC exportieren und offline weiterbearbeiten; die Bibliotheksfunktionen sind Open Source und auch kommerziell einsetzbar.
* [http://www.isystem.com/products/software/winidea-open winIDEAOpen]Die Fa. iSystem stellt mit der winIDEAOpen nun eine kostenlose Entwicklungsumgebung für alle Cortex-M Bauteile zur Verfügung. Als Compiler wird der GNU GCC verwendet und auch gleich mitinstalliert. Die IDE ist recht intuitiv und mit einer umfangreichen Hilfe ausgestattet. Das Ganze funktioniert mit dem GCC ohne Codesize Limit und auch ein Testwerkzeug (testIDEA) ist mit integriert. Hardwareseitig werden neben dem iSystem iTag50 [http://www.isystem.com/products/hardware/cortex-debugger/itag] auch die Segger J-Link Debug Probes sowie der ST-Link von ST unterstützt. Auf der Webseite von iSystem sind auch einige schöne Beispielprojekte für diverse Boards zu finden [http://www.isystem.com/download/winideaopen]. Demnächst soll noch die Unterstützung für die ARM und IAR Compiler hinzuzkommen. Hier gehts zum ''[http://www.isystem.com/download/winideaopen Download]'''
* '''Infineon''' bietet für seine '''XMC''' Prozessorfamilien auch eine kostenlose, professionell gepflegte C/C++ Entwicklungsumgebung an, ohne Einschränkungen auf bestimmte Typen oder Speichergrößen - alle erhältlichen XMC 1000er und 4000er Prozessoren werden unterstützt. Wenn man sich dazu noch eines der günstigen XMC Evaluierungsboards besorgt (XMC 1100 Bootkit, XMC 4500 Relax (lite) Kit o.ä.), hat man ein erstes Entwicklungssystem inklusive wiederverwendbaren HW-Debugger zur Verfügung. Die Entwicklungsumgebung basiert auf Eclipse, besitzt aber zahlreiche Erweiterungen samt Codegenerierung (sogenannte Apps), die gerade am Anfang viele Dinge abnehmen kann, da man die Peripherals damit einfach grafisch konfigurieren kann. Das ist bei Prozessoren, dessen User Manual einige hundert Seiten ausmacht (oder auch für Umsteiger von 8bitter oder anderen 32bittern), nicht unwichtig. Der generierte Code ist template-basiert, gut lesbar und kann später - wenn man mehr Erfahrung hat, für eigene Entwicklungen weiter nutzen und optimieren. Damit verliert man dann allerdings die Möglichkeit, Updates der generierten Codes aus den Apps zu bekommen, die Infineon ebenfalls kostenfrei zur Verfügung stellt. Die Software nennt sich ''Digital Application Virtual Engineer'' ([http://www.infineon.com/dave DAVE]) und kann nach Registrierung kostenlos für Windows heruntergeladen werden. Innerhalb von Dave kann man dann Apps und viele Beispiele (ohne weitere Anmeldung und Kosten) komplett oder selektiv (für bestimmte Prozessoren) herunterladen. Die aktuell stabile Version ist v3. Es ist eine neue DAVE Umgebung v4 in Arbeit, eine Betaversion kann heruntergeladen werden. Diese neue v4 Variante wird auch ein separates SDK besitzen, um Apps für Dave selbst schreiben zu können (z.B. Bauteilhersteller, die die Anbindung an den XMC für Kunden vereinfachen wollen). Einsteiger sollten aber mit v3 beginnen, um nicht über Bugs der Beta v4 zu stolpern (siehe auch im [http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum]).
* '''NXP''' bietet für seine '''LPC''' Prozessorfamilien eine kostenlose C/C++ Entwicklungsumgebung an. Die auf Eclipse basierende Entwicklungsumgebung ([http://www.lpcware.com/lpcxpresso LPCXpresso]) ist nach der Installation bis 8kB freigeschaltet und nach einer einfachen und kostenlosen Registrierung für 256kB. [http://www.lpcware.com/lpcxpresso LPCXpresso] steht für Windows, Linux und Mac zur Verfügung.
* '''ST''' bietet für seine '''STM32''' Prozessorfamilie eine kostenlose C/C++ Entwicklungsumgebung an. Die auf Eclipse basierende Entwicklungsumgebung kann nach Registrierung auf der Homepage heruntergeladen werden. [http://www.openstm32.org/]

Kommerzielle Entwicklungsumgebungen (zum Teil kostenlos mit Einschränkungen) für ARM-basierte Mikrocontroller sind z. B.:
* [http://timor.atollic.com/truestudio/ Atollic TrueStudio] (Windows), Eclipse-basierend inkl. Compiler und Linker für fast alle ARMs, jetzt auch kostenlos mit vielen Beispielen und ohne Codesize-Limitierung, dafür mit anderen Einschränkungen
* [http://www.cosmicsoftware.com/download_cortex_64k.php Cosmic Software] (Windows), bis 64kB kostenlos
* [http://rowley.co.uk/arm/ Crossworks ARM] (inkl. Toolchains basierend auf GCC und Clang, für Windows, Mac OS und Linux)
* [http://www.iar.com/ewarm/ IAR Embedded Workbench for ARM] (Windows)
* [http://www.keil.com/arm/ MDK-ARM von Keil/ARM] (Windows), Lite-Version bis 32kB kostenlos,
* [http://www2.keil.com/stmicroelectronics-stm32/mdk MDK-STM32 von KEIL] Speziell für STM32x0 kostenlos ohne Beschränkung
* [http://www.sisy.de/ SiSy MC++] (Windows), Demo-Version, keine Code-Begrenzung

=== Compiler für sonstige Programmiersprachen ===
* Basic: http://www.mikroe.com/mikrobasic/arm/
* Pascal: http://www.mikroe.com/mikropascal/arm/

=== Interpreter ===
* Forth: https://github.com/ekoeppen/CoreForth
* JavaScript: http://www.espruino.com/
* Lua: http://www.eluaproject.net/

=== ARM/XSCALE/CORTEX Instruction Set Simulator ===
Die Firma Lauterbach bietet unter der Artikelnummer LA-8809 einen Instruction Set Simulator für ARM Cores an. Die Demoversion ist zur Evaluierung kostenlos. Einschränkungen bestehen in der Anzahl der zu ladenden Debugsymbole. Der Simulator unterstützt alle gängigen ARM Derivate und lädt alle üblichen Debugformate, wie die des RealView, IAR und TI Compilers, oder der freien GCC Tools. Zum Simulator gibt es entsprechende zugehörige Debugtools, die allerdings käuflich zu erwerben sind.

* [http://www.lauterbach.com/frames.html?dwnload.html Download ARM/XSCALE/CORTEX Simulator]

== Debug- und Programmierschnittstellen (JTAG/SWD) ==

Alle ARM-basierten Prozessoren verwenden ein einheitliches [[JTAG]]-Interface, über das Debugging und Speicherzugriff erfolgen kann. Nicht standardisiert sind allerdings die Verfahren zum Beschreiben des Flash-ROMs, deshalb muss man beachten ob die verwendete JTAG-Software Programmierroutinen für den jeweiligen Controller besitzt.

SWD (Serial Wire Debug) ist eine neue mit den Cortex-Mikrocontrollern eingeführte Debug- und Programmierschnittstelle, die weniger Pins benötigt als JTAG. Hier wird Debug-Bandbreite bzw. Speed gegen mehr verfügbare Pins für in-circuit Debugging "getauscht". Die meisten Controller der Cortex-M0 & M3 Serie können sowohl mittels JTAG als auch mittels SWD programmiert werden, es gibt allerdings auch Exemplare (z.B. [[EFM32]] von [https://www.silabs.com Silicon Labs], XMC1100 von [http://www.infineon.com/xmc Infineon]) welche nur SWD unterstützen.

Eine Übersicht über die empfohlenen Steckerbelegungen für JTAG und SWD gibt ein [http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf Dokument von ARM].

Darüber hinaus gibt es noch herstellerspezifische Schnittstellen wie SPD (Single Pin Debug) von Infineon, oder vorinstallierte serielle Bootloader, z.B. beim [[STM32]] oder auch bei den [[Infineon XMC]], die dann z.B. über ein eigenes [http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/c166/xc166-development-tools-software-and-kits/software-downloads/channel.html?channel=ff80808112ab681d0112ab6b50fe07c9 Tool] ohne weitere Hardware - abgesehen von einem handelsüblichen seriellen Schnittstellenadapter - programmiert werden können.

Viele Entwicklungsboards enthalten auch einen On-Board-Debugadapter zum direkten Anschluss an USB, so dass kein externer SWD- oder JTAG-Adapter notwendig ist. Manche erlauben auch, diesen Adapter abzubrechen und für eigene Entwicklungen weiterzuverwenden, somit ist nach dem Kauf eines Eval-Kits nicht nötig, einen weiteren Adapter später nachzukaufen.

=== Günstige Beispiele zum Einstieg ===
Ein einfacher JTAG-Adapter für den Parallelport ist der "Wiggler"-kompatible, den man auch einfach selbst bauen kann. Als Software lässt sich unter Windows und Linux [http://openocd.berlios.de/ OpenOCD] (zusammen mit [[GDB]]) oder [http://rowley.co.uk Crossworks ARM] verwenden. Für USB gibt es ebenfalls OpenOCD-kompatible JTAG-Adapter.

Von NXP sind preiswerte Entwicklungskits (ca. 25€ für Evaluation-Board incl. USB-JTAG-/-SWD-Programer und Debugger) erhältlich z.B. '''[http://www.watterott.com/index.php?page=search&keywords=LPCXpresso&cat=&mnf=&x=0&y=0 Watterott]'''. Siehe dazu auch die Dokumentation von NXP zu den '''[http://www.nxp.com/documents/leaflet/75016842.pdf LPCXpresso-Entwicklungskits]''' (PDF), oder diese '''[http://www.mikrocontroller.net/wikisoftware/index.php?title=LPC1xxx_Entwicklungskit_LPCXpresso Beschreibung]'''.

Von ST gibt es günstige MBED/Arduino kompatible Nucleo Entwicklungskits (ca. 12€) z.B. '''[http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260320?s_searchtype=partnumber]'''. Der integrierte ST-Link Debugger kann mittels SWD und OpenOCD als Software auch andere Chip programmieren. Die etwas teuereren Discoveryboards, z.B. '''[http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1848/PF260946?s_searchtype=partnumber]''', haben mehr externe Bauteile on-board, während die Nucleo Board über Shields erweiterbar sind. Nur bei Nucleo Boards ist eine UART Schnittstelle als Standard über USB zu erreichen, bei Discovery Boards mit ST-Link V2-1 müssen Lötbrücken gesetzt werden.

Auch Infineon bietet Arduino-kompatible Boards+Shields mit dem XMC1100 Prozessor und angeflanschtem Debugger an (ab ca. 16€). Weiters gibt es günstige XMC4500 Kits, die auch Ethernet, SPI-Flash und SDCard-Slot Optionen bieten. Am unteren Ende gibt es ein XMC1100 Kit samt Debugger ab ca. 5€, dieses Board für den Schlüsselbund sozusagen nennt sich treffend "XMC 2 Go". Die Preise können je nach Distributor stark variieren.
Siehe auch hier '''[http://www.infineon.com/cms/de/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-registered-cortex-registered-m/xmc-development-tools-kits-and-boards/channel.html?channel=db3a30433580b3710135a07902883872 XMC-Starter-Kits]'''.
Des weiteren werden auch schon Kits in Verbindung mit Sensoren zum Evaluieren angeboten, wie das "3D 2 Go" Board mit einem XMC1100 Prozessor und dem neuen 3D-Magnetfeldsensor von Infineon, um ein Beispiel zu nennen: '''[http://www.infineon.com/cms/en/product/sensor-ics/magnetic-sensors/3d-magnetic-sensor/channel.html?channel=5546d4624c9e0f0e014c9e105a8a001c 3D-Sensorkit]'''.

Von Silicon Labs gibt es [https://www.silabs.com/products/mcu/Pages/32-bit-microcontroller-tools.aspx Starter Kits] mit integriertem J-Link (Debugger) ab ca. 25 € z.B. das [https://www.silabs.com/products/mcu/lowpower/Pages/efm32tg-stk3300.aspx EFM32 Tiny Gecko Starter Kit] bei [http://www.mouser.de/ProductDetail/Silicon-Laboratories/EFM32TG-STK3300/?qs=%2fha2pyFadujBGJvO8YBq9JikBLXQGi%2fjwmF17imXuts5383tWpQKFA%3d%3d Mouser]

Der [http://www.segger.com/cms/jlink.html J-Link]-"Emulator" von Segger wird von vielen Softwarepaketen unterstützt und ist für den "nicht-kommerziellen" Einsatz von Studenten, Funkamateuren und Hobby-Bastler für ca. €50.- erhältlich (J-Link-Edu). Sein Umfang ist dabei auf das Flashen des Speichers und das Debuggen beschränkt. Die Trace-Option wie sie bei der PRO-Variante zur Verfügung steht, ist nicht vorhanden. Für den Preis (05/2013) bekommt man jedoch ein ausgewachsenes Werkzeug mit breiter Unterstützung und der Möglichkeit sowohl SWD als auch JTAG in einem Gerät vereint zu haben. Wenn man aber plant, ein oben genanntes Kit von ST, NXP, Infineon oder ähnlich zu kaufen kann man für ähnliche Kosten auch gleich ein CPU-Board dazubekommen - daher ist es sinnvoll, sich die Dokumentationen der Evalkits voher genau durchzusehen.

Der ULINK2 von Keil/ARM ist ebenfalls ein wirklich gutes Gerät. Leider ist er nicht ganz so günstig und seine Zusammenarbeit beschränkt sich auf die Arm/Keil IDE µVision. Er benötigt jedoch keine speziellen USB-Treiber sondern nutzt geschickt die Funktionalität der HID-Treiber des Betriebssystems. Das macht ihn sofort auf jedem Windows-Betriebssystem einsatzbereit.

Als Alternative zum Beschreiben des Flash über JTAG ist oft ein serieller [[Bootloader]] im Controller enthalten. Bei ST werden sie über einen speziellen Pin der MPU aktiviert und sind dank Kompression und das intelligente entfernen redundanter Information, bei der Übertragung genauso schnell wie JTAG/SWD Adapter.

== CMSIS - ARM Cortex Software Libraries ==

Der ARM Cortex Microcontroller Software Interface Standard (CMSIS) ist ein herstellerunabhängiger Hardware Abstraction Layer für die Cortex-M-Prozessor -Serie. Dieser ermöglicht konsistente und einfache Software-Schnittstellen für den Prozessor und die Peripherie, und vereinfacht damit die Software-Wiederverwendung.

CMSIS besteht aus folgenden Komponenten:

* CMSIS-CORE: Bietet eine Schnittstelle zum Cortex-M0, Cortex-M3, Cortex-M4, SC000 und SC300-Prozessorkern und Peripherie-Registern.
* CMSIS-DSP: DSP-Bibliothek mit über 60 Funktionen in Festkomma-(fractional q7, q15, q31) und single precision floating-point (32-bit)-Implementierung
* CMSIS-RTOS API: Standardisierte Programmierschnittstelle für Echtzeit-Betriebssysteme für Thread-Steuerung, Ressourcen-und Zeitmanagement. Implementierungen gibt es z.B. von Keil ([http://www.keil.com/pack/doc/cmsis_rtx/index.html RTX])
* CMSIS-SVD: System View Beschreibung - XML-Dateien, die die Programmiereransicht des kompletten Mikrocontroller-Systems einschließlich Peripheriegeräte enthalten

Der Standard ist für Cortex-M-Mikrocontroller skalierbar: Von der kleinsten 4 KB MCU bis zu MCUs mit anspruchsvoller Kommunikations-Peripherie wie Ethernet oder USB. Die "Core Peripheral Funktionen" benötigt beispielsweise weniger als 1 KB-Code und weniger als 10 Bytes RAM.

Beispiele:
* Software Beispiele von [http://www.energymicro.com/downloads/application-notes Energy Micro] basierend auf CMSIS

Mehr Informationen auf der [http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php ARM CMSIS Webseite].

== Siehe auch ==
* [[Linksammlung#ARM|Linksammlung (Abschnitt ARM)]]
* [[LPC1xxx]]
* [[LPC1xxx_Entwicklungskit_LPCXpresso]]
* [[Installationsanleitung_C-Entwicklungsumgebung_f%C3%BCr_LPC1xxx_von_Code_Red]]
* [[Codebase_f%C3%BCr_LPC1xxx]]
* [[ARM-elf-GCC-Tutorial]]
* [[AVR32]]
* [[Blackfin]]
* [[AT91SAM9260]]
* [[STM32]]
* [[JTAG]]
* [http://www.mikrocontroller.net/articles/EFM32 EFM32]
* [http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks STM32 - Einstieg mit Em::Blocks Tutorial]

== Weblinks ==
* [http://www.mySTM32.de Online Tutorial für den STM32]
* [http://www.myXMC.de Online Tutorial für den XMC von Infineon]
* [http://www.myUGL.de Online Tutorial für freie Grafikbibliothek, STM32, STM32F429, TFT, Touch]
* [http://embdev.net/forum/arm-gcc ARM-GCC Forum] im englischsprachigen "Ableger" von mikrocontroller.net embdev.net u.a. für WinARM, Yagarto, CS Codebench
* [http://www.arm.com/products/processors/cortex-m/index.php Cortex-M Produktseite von ARM]
* [http://infocenter.arm.com/help/index.jsp Infocenter von ARM Ltd.]
* [http://www.open-research.org.uk/ARMuC/ ARMuC ARM microcontroller Wiki]
* [http://chaosradio.ccc.de/cre151.html Chaosradio Express - Die ARM-Architektur]

== Literatur ==
*ARM Systems Developer's Guide (2004) ISBN 1558608745 [http://books.google.de/books?id=HKKUkDQE17QC&output=html Im Buch blättern] [http://booksite.elsevier.com/9781558608740/ Programmbeispiele aus dem Buch, u.a. FFT, FIR/IIR-Filter, Division, Wurzel]
*ARM Assembly Language - an Introduction (2007) ISBN 1847536964 [http://books.google.de/books?id=8KJX5R8mMvsC&output=html Im Buch blättern] [http://www.lulu.com/content/1172076 Verlagsseite "Book on demand"]
*ARM Rechnerarchitekturen für System-on-Chip-Design (2002) ISBN 3826608542
*Co-Verification of Hardware and Software for Arm Soc Design (2004) ISBN 0750677309
*ARM System-on-Chip Architecture (2000) ISBN 0201675196 [http://books.google.de/books?id=J_Fu_YTVD9gC&printsec=frontcover&output=html&source=gbs_summary_r&cad=0 Im Buch blättern]
*ARM Architecture Reference Manual ISBN 0201737191 [http://books.google.de/books?id=O5G-6WX1xWsC&printsec=frontcover&output=html&source=gbs_summary_r&cad=0 Im Buch blättern]
*Messen, Steuern und Regeln mit ARM-Mikrocontrollern ISBN 3772340172 [http://books.google.de/books?id=TKs4kN-zNYQC&output=html im Buch blättern]
*Programming Arm Microcontrollers: Using C and the Lpc2100 Family (2005? /ab 1. Dezember 2008) ISBN 0321263359
*Arm Assembly: Fundamentals and Techniques (ab 1. März 2009) ISBN 1439806101
*Reliable Embedded Systems: Using 8051 and ARM Microcontrollers (2007) ISBN 0321252918 600 Seiten mit CD [http://vig.pearsoned.co.uk/catalog/academic/product/0,1144,0321252918-TOC,00.html Inhaltsverzeichnis]
* C und C++ für Embedded Systems (u.a. ARM Cortex-M3) mitp-Verlag 2008 ISBN 382665949X
* The Definitive Guide to the Arm Cortex-M0 (Joseph Yiu) Newnes Verlag ISBN 0123854776
* The Definitive Guide to the Arm Cortex-M3 (Joseph Yiu) Newnes Verlag ISBN 185617963X

== Artikel aus der Kategorie ARM ==
<ncl style=compact maxdepth=2 headings=bullet headstart=2
showcats=1 showarts=1>ARM</ncl>
* [http://www.mikrocontroller.net/articles/EFM32 '''EFM32''']

* [http://www.mikrocontroller.net/articles/XMCxxxx '''Infineon XMCxxxx''']

* [https://www.mikrocontroller.net/articles/Cortex-A ARM Cortex A]

[[Category:ARM| ]]

Datei:Roboter2016.png

2016-07-07T11:01:56Z

Newgeneration: Newgeneration lud eine neue Version von Datei:Roboter2016.png hoch

Rendering erstellt mit Keyshot
CAD: Solid Edge ST8

Julian Frimmel

Benutzer:Newgeneration

2016-07-07T11:00:14Z

Newgeneration:

Hallo,

Für die paar unter euch die wissen wollen was ich so mache:

[[Datei:Roboter2016.png|mini|Unser Roboter aus dem Jahr 2016]]

ich war an einem bayrischen Gymnasiums und habe dort am Wahlfach Robotik teilgenommen.
Dort kam ich dann auch mit µCs in Verbindung.
Robotik? Was macht man das so?
* Roboter bauen, um am [https://www.robocupgermanopen.de/de/junior Robocup Junior] teilzunehmen
* Auf Wettbewerbe fahren und gegen andere Teams antreten
* anderen, vor allem jüngeren helfen
Obwohl ich nicht mehr an der Schule bin, holt mich die Robotik-AG regelmäßig wieder zurück und ich hoffe, dass ich durch Fähigkeiten, die ich im Studium lerne, den anderen Teilnehmern der AG weiter helfen kann.

Mein Team konnte auch schon einige Erfolge in der Disziplin Soccer verbuchen, darunter zwei mal die Teilnahme an der WM; dort spielen jeweils 2 gegen 2 Roboter, nach ähnlichen Regeln wie im echten Fußball.

Damit ihr euch mehr darunter vorstellen könnt gibt es hier einen Zusammenschnitt der deutschen Meisterschaft 2016:
https://www.youtube.com/watch?v=TYeKAMcxOPs

Dieses Hobby überträgt sich natürlich auch in den Privatbereich, deswegen steht mein Schreibtisch voll mit Basteleien, vor allem AVRs, STM32 und neuerdings auch ARMs von NXP.

== NEWS ==
* Auf der diesjährigen Deutschen Meisterschaft (Robocup Junior German Open 2016) haben mein Team und ich den 2. Platz erreicht und sind somit für die Weltmeisterschaft in Leipzig qualifiziert!

* Bei der vor kurzem stattfindenden Robocup Junior Weltmeisterschaft in Leipzig ([http://robocup2016.org/ offizielle Seite]) gab nicht nur einen, sondern sogar 2 Erfolge zu vermelden:
# Unser Team wurde 8. aus 22 Weltklasse Teams
# Das jüngere Team unserer Schule mit dem zurückhaltenden Namen "Ultimate Team" wurde '''Weltmeister''' in ihrer Liga! Ihre [http://ultimateteam.bplaced.net/news.html Website]
''Bilder und Videos folgen''

Damit war die WM ein riesen Erfolg für unsere AG und wir sind motiviert uns noch mehr zu steigern!

Datei:Roboter2016.png

2016-05-26T15:14:56Z

Newgeneration: Rendering erstellt mit Keyshot CAD: Solid Edge ST8 Julian Frimmel

Rendering erstellt mit Keyshot
CAD: Solid Edge ST8

Julian Frimmel

Benutzer:Newgeneration

2016-05-26T15:13:58Z

Newgeneration: auf aktuelle Saison angepasst

Hallo,

Für die paar unter euch die wissen wollen was ich so mache:
ich bin derzeit noch Schüler eines bayrischen Gymnasiums und habe dort am Wahlfach Robotik teilgenommen.
Dort kam ich dann auch mit µCs in Verbindung.
Robotik? Was macht man das so?
* Roboter bauen, um am [https://www.robocupgermanopen.de/de/junior Robocup Junior] teilzunehmen
* Auf Wettbewerbe fahren und gegen andere Teams antreten
* anderen, vor allem jüngeren helfen

[[Datei:Roboter2016.png|mini|Unser Roboter aus dem Jahr 2016]]

Mein Team konnte auch schon einige Erfolge in der Disziplin Soccer verbuchen; dort spielen jeweils 2 gegen 2 Roboter, nach ähnlichen Regeln wie im echten Fußball.
Auf der diesjährigen Deutschen Meisterschaft (Robocup Junior German Open 2016) haben mein Team und ich den 2. Platz erreicht und sind somit für die Weltmeisterschaft in Leipzig qualifiziert!
Damit ihr euch mehr darunter vorstellen könnt gibt es hier einen Zusammenschnitt der DM:
https://www.youtube.com/watch?v=TYeKAMcxOPs

Dieses Hobby überträgt sich natürlich auch in den Privatbereich, deswegen steht mein Schreibtisch voll mit Basteleien, vor allem AVRs und STM32.

AVR-GCC

2016-03-14T21:15:57Z

Newgeneration: /* Vorbereitungen */

avr-gcc ist ein freier [[C]]-Cross-[[Compiler]] für [[AVR]]-[[Mikrocontroller]].

avr-gcc kann von der Leistungsfähigkeit kommerzieller [[Compiler]] gut mithalten. Sogar C++-Programme sind möglich; in der aktuellen Fassung wird C++ jedoch nur eingeschränkt unterstützt (Stand 3/2012).

== Bestandteile ==

Die Toolchain (Werkzeugsammlung) besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen. Weit verbreitet ist die Verwendung von make zur Steuerung, siehe [[AVR-GCC-Tutorial/Exkurs Makefiles|AVR-GCC-Tutorial: Exkurs Makefiles]].

Die Bestandteile im einzelnen:
* Binutils: Assembler, Linker und weitere Hilfsprogramme.
* GCC: Der eigentliche C(++)-Compiler.
* AVR-Libc: Die C-Standardbibliothek mit AVR-spezifischen Headerdateien und Funktionen.
* [[AVRDUDE]]: universelle AVR-Programmiersoftware, kein eigentlicher Teil der Toolchain, aber oft verwendet

== Installation ==

=== Linux/Unix ===

Atmel bietet die [http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an.

Wenn keine aktuelle avr-gcc-Version als Paket (Paketname ist, zumindest bei Debian, gcc-avr) für die verwendete Distribution zur Verfügung steht, dann können sich [[Unix]]/[[Linux]]-Nutzer den Sourcecode herunterladen und selbst kompilieren, dazu gibt es Schritt-für-Schritt-Anleitungen<ref>[http://www.nongnu.org/avr-libc/user-manual/install_tools.html AVR-Libc: Building and Installing under Linux, FreeBSD, and Others]</ref><ref>[http://www.roboternetz.de/wissen/index.php/Avr-gcc_und_avrdude_installieren www.roboternetz.de: avr-gcc und avrdude installieren]</ref>.

Das [http://www.femtoos.org FemtoOS]-Paket beinhaltet Scripte zum automatischen Herunterladen und Bauen einer avr-gcc Version 4.3.3.

Empfehlenswert ist auch [http://cdk4avr.sf.net CDK4AVR], das die entsprechenden Tools als einfach installierbare Linux-Pakete bereitstellt. Leider ist das Projekt schon etwas älter, im Forum findet sich ein [http://www.mikrocontroller.net/topic/130972 Beitrag], aktuellere Sourcen mit den entsprechenden Patches zu versehen und zu kompilieren. Patches zu den Binutils und GCC-Sourcen sind unumgänglich, da die offiziellen Sourcen aufgrund des Umfangs an Prozessortargets den aktuellsten Entwicklungen hinterherhinken und damit bereits bekannte Fehler eventuell noch nicht behoben sind. Weitere Tipps zur AVR-Programmierung unter Linux stehen im Artikel [[AVR und Linux]].

=== Mac OS X ===
Die beste fertige Toolchain ist das [http://www.obdev.at/crosspack/ Crosspack]. Dieses enthält auch die AVR-Libc, avrdude und avarice. Leider gab es bei Mac OS 10.5.6 eine tiefgreifende Änderung beim fork()-Systemcall, der bewirkt, dass avarice mit JTAGICE mkII und Dragon nicht funktioniert. Geräte mit Serial-USB-Konvertern (AVRISP clones etc) funktionieren dagegen problemlos.

Wer die Toolchain von Hand bauen möchte kann das natürlich auch tun, dazu einfach den unter "Linux/Unix" verlinkten Anleitungen folgen. Unter [[Mac OS X]] muss man dazu zuerst die [http://developer.apple.com/Tools/ Apple Developer Tools] installieren.

Teile der Toolchain (AVR-Libc und avrdude) kann folgendermaßen installieren:

==== Mit MacPorts ====
Wenn man [http://www.macports.org/ MacPorts] benutzt kann man folgendes in das Terminal eingeben, um den Toolchain zu installieren:

sudo port install avr-libc

Das Programmiertool avrdude bekommt man genauso:

sudo port install avrdude

==== Mit Hombrew ====
Mit dem neueren Tool [http://brew.sh Homebrew] funktioniert das folgendermaßen:

avrdude kann sofort installiert werden:

brew install avrdude

Für den restlichen Toolchain muss man erst ein 'Tap' hinzufügen:

brew tap larsimmisch/homebrew-avr

und kann dann den eigentlichen Toolchain installieren:

brew install avr-libc

Weblinks:

* [http://tinkerlog.com/2007/09/29/programming-avr-with-a-macbook/ Programming AVR with a MacBook] (engl.)
* [http://www.ladyada.net/library/avrdevtut/setup-mac.html AVR Tutorial from Lady Ada] (engl.)
* [http://www.obdev.at/crosspack/ Crosspack]
* [http://www.digithink.com/OSX-AVR OSX-AVR (nicht mehr aktuell)]
* [http://www.definefalsetrue.com/index.php/Mac-OS-X/bootfeedx.html BootFeedX Bootloaderfrontend]

=== Windows ===

Man kann sich auch für Windows den GCC selbst bauen oder man sucht von anderen erstellte Binaries.

Atmel bietet die [http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an.

Für MS-Windows gibt es das fertig kompilierte Softwarepaket [[WinAVR]], welches allerdings seit 2010 nicht mehr gepflegt wird.

==== Selbst bauen ====

Zuerst sei einmal die offizielle (englische) Anleitung genannt: [http://www.nongnu.org/avr-libc/user-manual/install_tools.html Building and Installing avr-gcc]

Das hier ist die etwas ausführlichere Beschreibung, die mir Johann L. gegeben hat, damit ich meinen Compiler erstellen konnte. Der Post dazu findet sich [https://www.mikrocontroller.net/topic/384825?goto=4394391#4394606 hier].

Zuerst einmal braucht man am besten ein Linux, zum Beispiel ein aktuelles Ubuntu. dort müssen diverse Programme wie gcc, autoconf, subversion usw. installiert sein. Wenn etwas fehlt meckert configure, das einfach aufmerksam lesen und dann die Programme nachistallieren. Danach erneut configure aufrufen.
Um die Toolchain für Windows zu bauen brauchen wir noch mingw32. Eventuell findet sich das in den Paketquellen eurer Distribution, sonst kann ich auf [http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/ diese Seite] verweisen.

===== Vorbereitungen =====
Wie schon gesagt brauchen wir ein Linux, zum Beispiel in einer VM. Ein paar Linux-Hintergrundinfos wären auch gut, kann man aber auch ergooglen.
'''Achtung:''' Auf diesem Linux darf kein avr-gcc und keine avr-libc vorhanden sein!
Dazu brauchen wir die folgende Software:
* GNU Binutils: [https://www.sourceware.org/binutils/ Download], am besten die neueste Version (runter scrollen, aktuell ist 2.26)
* GCC Sourcen: [https://gcc.gnu.org/ Download], diese sollten, wenn mans ganz aktuell will aus dem svn kommen (svn co svn://gcc.gnu.org/svn/gcc/branches/''branchname'' gcc ,mit ''branchname'' gcc-''version''-branch, aktuell ist gcc-5-branch)
* Die AVR-libc: '''Achtung''': nicht normal downloaden, immer aus dem SVN nehmen, da die neuren GCCs eine andere Struktur der Libc erfordern. Die ist in den Releases noch nicht eingearbeitet. [http://savannah.nongnu.org/svn/?group=avr-libc Download via svn]: svn co svn://svn.savannah.nongnu.org/avr-libc/''modulename'' , wobei ''modulname'' meistens trunk ist. (Kann mit dem 2.0.0er Release der avr-libc anders sein, mit dem trunk sollte es aber immer gehen)

Alles herunterladen und entpacken.

Zu den Downloads kommen dann noch 2 Umgebungsvariablen:
<syntaxhighlight lang="bash">
$ PREFIX=$HOME/local/avr
$ export PREFIX
$ PATH=$PATH:$PREFIX/bin
$ export PATH
</syntaxhighlight>
Damit legt ihr das Installationsverzeichnis fest und fügt auch gleich das Verzeichnis für die ausführbaren Dateien zum Pfad hinzu.

Im Folgenden gehe ich von diesem Ordner-Layout aus:
<pre>
$HOME
|
+ BuildToolchain
|
+ Downloads
| |
| + binutils
| + gcc
| + avr-libc
|
+ buildLinux
| |
| + binutils
| + gcc
| + avr-libc
|
+ buildWindows
|
+ binutils
+ gcc
</pre>

===== Erstellen der Binutils =====
Wechselt in das Verzeichnis BuildToolchain/buildLinux/binutils.
Von dort aus werden wir die binutils konfigurieren und erstellen.

'''Achtung:''' man darf weder GCC noch die Binutils in einem Verzeichnis innerhalb des Quellordners der Downloads konfigurieren, sonst kommen wirre Fehler.

Also, wir sind soweit. Jetzt geht es ans Konfigurieren und erstellen, aber das ist ganz leicht:
<syntaxhighlight lang="bash">
$ ../../binutils/configure --prefix=$PREFIX --target=avr --disable-nls
</syntaxhighlight>
Wenn configure fehlende Programme meldet: nachistallieren und erneut versuchen.
<syntaxhighlight lang="bash">
$ make
$ make install
</syntaxhighlight>

Damit sind die Binutils fertig. Ich könnt nachkontrollieren, ob die binutils da sind: Im Ordner $PREFIX/bin sollten sich die Dateien befinden, darunter avr-objcopy, avr-as, avr-size, etc.

===== Erstellen vom GCC =====
Als erstes muss sich der GCC noch ein paar zusätzliche Dateien herunterladen, das geschiet automatisch mit dem Befehl (ausgeführt in BuildToolchain/Downloads/gcc):
<syntaxhighlight lang="bash">
./contrib/download_prerequisites
</syntaxhighlight>
Wechselt ins Verzeichnis BuildToolchain/buildLinux/gcc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../gcc/configure --prefix=$PREFIX --target=avr --enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2
$ make
$ make install
</syntaxhighlight>

===== Erstellen der avr-libc =====
Als erstes muss die avr-libs zum konfigurieren bereit gemacht werden:
Im Verzeichnis BuildToolchain/Downloads/avr-libc die Datei bootstrap ausführen
<syntaxhighlight lang="bash">
./bootstrap
</syntaxhighlight>
Danach wechselt ihr ins Verzeichnis BuildToolchain/buildLinux/avr-libc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../avr-libc/configure --prefix=$PREFIX --build=`./config.guess` --host=avr
$make
$make install
</syntaxhighlight>

===== Testen unter Linux =====
So, jetzt seit ihr schon bei der Hälfte: Der Compiler läuft schon unter Linux!
Das testet ihr am besten schon mit ein paar einfachen LED-blink-Programmen, damit auch sichergestellt ist, dass bis hierhin alles geklappt hat.
Das einfachste und wichtigste Kommando dürfte sein
<syntaxhighlight lang="bash">
avr-gcc --version
</syntaxhighlight>
Dort sollte die Versionsnummer der GCC stehen. Wenn eine ältere Nummer dasteht, hab ihr entweder einen alten Download bemüht, oder eine andere version vom avr-gcc war noch installiert.
Wenn der fehler kommt, dass das Programm nicht gefunden werden kann, dann befindet sich avr-gcc nicht im PATH, das bedeutet ihr habt die Umgebungsvariablen nicht richtig gesetzt (siehe oben).

===== Bau für Windows =====
Ihr müsst keine neuen Dateien runter laden, lediglich die Programme nochmal etwas anders konfigurieren.
Die Schritte davor '''müssen''' jedoch ausgeführt werden!

Wechselt ins Verzeichnis BuildToolchain/buildWindows/binutils und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../binutils/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls --host=plattform-mingw32 --build=i686-linux-gnu
$ make
$ make install
</syntaxhighlight>
Wobei ''plattform'' euer Ziel-system ist, also entweder i686 oder x86_64, je nach dem, was ihr für ein mingw32 installiert habt.

Wechselt ins Verzeichnis BuildToolchain/buildWindows/gcc und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../gcc/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls --host=plattform-mingw32 --build=i686-linux-gnu --enable-languages=c,c++,lto --with-gnu-as --with-gnu-ld --disable-shared --with-dwarf2
$ make
$ make install
</syntaxhighlight>

Wechselt ins Verzeichnis BuildToolchain/buildLinux/avr-libc und führt den folgenden Befehl aus:
<syntaxhighlight lang="bash">
$ make install prefix=$HOME/local/avr4win
</syntaxhighlight>

Damit sollten ihr im Ordner $HOME/local/avr4win die gesamte Toolchain haben. Diesen Ordner müsst ihr nur noch auf euren Windows-PC kopieren.
Für das klassische WinAVR fehlt noch Programmers Notepad, sowie die Utility-Programme, vor allem avrdude und make. Diese kann man entweder seperat downloaden oder aus einer WinAVR-Installation kopieren. Die Versionen davon spielen keine Rolle.

== Entwicklungsumgebungen ==

Win32:
* [[AVR-Studio]]: ab Version 4.12 mit WinAVR-Unterstützung, integrierter Simulator, Debugger, rudimentäre Projektverwaltung
* Programmers-Notepad: wird bei [[WinAVR]] mitgeliefert, ein guter Editor mit einer rudimentären Projektverwaltung
* [http://www.myavr.info/download/benutzerhandbuch_sisy_avr.pdf SiSy-AVR]: ein CASE-Tool mit WinAVR-Unterstützung, das eine Entwicklungsumgebung bereitstellt.

Plattformunabhängig:
* [http://www.eclipse.org/ Eclipse] mit CDT und dem [http://avr-eclipse.sourceforge.net/index.html AVR Eclipse Plugin]
* [[Code::Blocks]]: vielseitige, freie Entwicklungsumgebung für Windows und Linux
* [http://www.netbeans.org/ Netbeans] in der C++ - Version mit [[WinAVR]] oder [[avr-gcc]] als Toolchain

Linux:
*[http://sourceforge.net/projects/kontrollerlab/?_test=b KontrollerLab] ist eine freie Entwicklungsumgebung für AVR momentan aber noch im Beta-stadium.

== Bibliotheken / Libraries ==

Die [http://www.nongnu.org/avr-libc/ AVR-Libc] ist die gebräuchliche "Laufzeitbibliothek" zum avr-gcc C-Compiler, welche den Zugriff auf die AVR-Hardware erheblich erleichtert. Die offizielle Dokumentation zur avr-libc mit vielen Hinweisen auch zum Compiler avr-gcc und verschiedener Tools (z. B. [[AVRDUDE]]) findet man [http://www.nongnu.org/avr-libc/user-manual/index.html hier].

Auch die [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon AVRlib] enthält nützlichen Code z. B. für UART, LCD,.... Bei der Procyon AVRlib ist die Lizenz zu beachten (in Kurzform: man muss dritten auf Verlangen den gesamten Quellcode der Firmware zur Verfügung stellen, falls Teile der Procyon Bibliothek genutzt werden).

Zum Zugriff auf interne Funktionen oder externe Peripherie existieren einige fertige Komponenten. Z.B. "Projects"-Bereich von [http://www.avrfreaks.net/ avrfreaks.net] (Anmeldung erforderlich (kostenlos)).

Die Erstellung eigener Bibliotheken ist im Artikel [[Libraries]] erklärt.

== Tipps & Tricks ==

Eine Liste mit einigen Hinweisen:

* 07.10.11 → es kann Probleme mit der aktuellen Eclipse-Version (Indigo) und WinAVR geben. Falls ihr Indigo installiert habt und Eclipse die Definitionen wie z.B. DDRA nicht kennt, jedoch kompillieren kann, dann müsst ihr auf die Version Helios SR2 wechseln. Danach läuft alles wie gehabt!

* Keine "antiken" Versionen verwenden. Für MS-Windows-Nutzer: aktuelles WinAVR installieren. Für Linux/Unix-Nutzer: letzte stabile Version selbst kompilieren oder aus "Distribution-Packages" installieren (z. B. [http://cdk4avr.sourceforge.net/ cdk4avr]).

* Bei Problemen zuerst in die [http://www.nongnu.org/avr-libc/user-manual/index.html Anleitung] der avr-libc schauen. Insbesondere die FAQ lesen.

* Sicherstellen, dass der MCU-Parameter (zum Compiler/Linker, meist im Makefile defniert) mit dem Zielprozessor übereinstimmt.

* [[AVR-GCC-Tutorial]] in diesem Wiki lesen.

* Im Zweifel nicht INTERRUPT(...) sondern SIGNAL(...) nutzen. In neueren Versionen der avr-libc wurde "ISR" als Ersatz für SIGNAL eingeführt und sollte genutzt werden (SIGNAL und INTERRUPT werden langfristig entfallen). Darauf achten, dass die Vektor- bzw. Signal-Namen ("Parameter") zu ISR bzw. SIGNAL (und INTERRUPT wenn denn unbedingt erforderlich) richtig geschrieben sind. Die Namen sind in der in der entsprechenden Header-Datei (ioxxx.h) für den Controller und der avr-libc-Dokumenation aufgelistet. Im Zweifel den erzeugten Interrupt-Vektor im Assembler-Listing prüfen, es darf '''kein''' SIG_''xxx'' oder xxx_vect mehr zu sehen sein, sondern _vector_''N'' (wobei ''N'' eine Zahl ist). Neuere Versionen der avr-gcc zeigen eine Warnung, falls etwas falsch geschrieben wurde, ältere Versionen nicht.

* Zugriff auf Daten(-Tabellen) im Programmspeicher (Flash) erfolgt über Program-Space-Funktionen (pgm_read*). Lediglich die Definition einer Variablen/eines Feldes mit dem PROGMEM Attribut zu versehen, reicht (im Gegensatz zu Codevision, IAR, Imagecraft) nicht aus.

* Nicht alle AVRs werden vollständig von der avr-libc bzw. dem Compiler unterstützt. Bei Problemen hilft oft ein Blick in den erzeugten Assembler-Code. Die Anzahl der unterstützen Controller steigt jedoch mit Version zu Version von binutils, avr-libc und avrdude. Evtl. reicht einfach ein Update auf neuere Software-Versionen (z. B. im jeweils aktuellen WinAVR-Packet).

* inp(), outp(), sbi() und cbi() werden in der aktuellen Bibliotheksversion nicht offiziell unterstützt (man muss eine spezielle Header-Datei einbinden(deprecated.h). Es wird schon seit längerem empfohlen, diese Makros nicht mehr zu nutzen. Einige Anleitungen sind in diesem Punkt veraltet. Mit halbwegs aktuellen avr-gcc/avr-libc-Versionen kann einfach z. B. DDRB=0xfe bzw. foo=PINB geschrieben werden. Mit PORTB |= _BV(1) setzt man PORTB.1, mit PORTB &= ~_BV(1) löscht man es wieder, mit PORTB ^= _BV(1) kann man es umschalten (_BV(x) entspricht dabei (1<<x)). Die ersten beiden Varianten erzeugen bei eingeschalteter Optimierung und passenden Parametern (wie hier im Beispiel Register im "unteren" Speicherbereich) die SBI bzw. CBI Prozessorbefehle.

* Mit dem Tool avr-nm erhält man eine Übersicht über die Platzausnutzung in der erzeugten ELF-Datei bzw. dem damit gefüllten AVR. Das Tool wird per Kommandozeile mit
::<pre>avr-nm --size-sort --print-size -r -td <your_ELF_file></pre>
:aufgerufen und gibt eine vierspaltige Liste aus: Die erste Spalte ist die Adresse, die zweite die benötigte Größe, die dritte der Typ und die vierte der Name des Symbols. Alle Symbole vom Typ "T" (globale Funktionen), "t" (lokale Funktionen) und letztlich auch die mit einem "D" oder "d" (globale bzw. lokale Daten mit Initialisierungswerten im ROM) betreffen das FLASH-ROM. Typen "B" und "b" brauchen ausschließlich RAM (werden beim Start mit 0 initialisiert). (vgl. [http://www.mikrocontroller.net/topic/59960#467920 Forenbeitrag] von Jörg Wunsch)

* Mit dem Tool avr-size erhält man eine Übersicht über den Platzbedarf in den text, data und bss Sektionen innerhalb der ELF Binärdatei. Die Sektionen text und data benötigen Platz im FLASH-ROM und die Sektionen data und bss benötigen zur Laufzeit Platz im SRAM.

== Fußnoten ==
<references/>

== Siehe auch ==
* [[AVR-GCC-Tutorial]]
* [[AVR-GCC-Codeoptimierung]]
* [[GCC: unbenutzte Funktionen entfernen]]
* [http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna AVR-GCC Interna]

== Weblinks ==
* [http://winavr.sourceforge.net/install_config_WinAVR.pdf Tutorial von C. O'Flynn und E. Weddington] Einstieg in die Nutzung des avr-gcc unter MS-Windows mit WinAVR (englisch)
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml AVR-GCC und Linux]
* [http://www.mikrocontroller.net/forum/list-2-1.html GCC-Forum auf mikrocontroller.net]

[[Category:AVR]]
[[Category:Compiler]]
[[Kategorie:avr-gcc| ]]

FPGA

2016-01-22T10:39:59Z

Newgeneration: Änderung 91410 von 193.158.249.10 (Diskussion) rückgängig gemacht.

FPGA ist die Abkürzung für "'''F'''ield '''P'''rogrammable '''G'''ate '''A'''rray".

== Aufbau ==

=== Grundelemente ===

Ein FPGA besteht, ähnlich wie ein [[CPLD]], aus vielen Logikelementen, hauptsächlich [[FlipFlop]]s (FF) und davor gelagerten kombinatorischen Logikschaltungen. Diese sind entweder Verknüpfungen verschiedener Logikgatter (FPGAs der Firma Actel), die über elektronische "Schalter" entsprechend der vom Entwickler gewünschten Funktion miteinander verknüpft werden können oder es handelt sich um sogenannte LUTs (Look-Up-Table), mit denen die Logikfunktion explizit realisiert wird.

Eine '''LUT''' kann eine beliebige kombinatorische Funktion (NAND, XOR, AND, Multiplexer etc.) aus den Eingangssignalen realisieren. Die Anzahl der Eingangssignale pro LUT ist vom FPGA abhängig und liegt meist zwischen 4 und 6. Für Funktionen die mehr Eingänge erfordern als eine einzige LUT besitzt (hohes Fan-In), werden mehrere LUTs direkt miteinander verschaltet. Die [[FlipFlop]]s dienen dazu, Signalwerte zwischenzuspeichern, um sie im nächsten Takt weiterverarbeiten zu können. Das Verhältnis zwischen der Anzahl der LUTs und der Anzahl der Flip-Flops ist meist 1:1. Aktuelle FPGAs bestehen aus bis zu einigen zehntausend Logikelementen.

Die logischen Schalter und Speicher sind in den meisten FPGAs durch [[Speicher#SRAM | SRAM]]-Speicherzellen realisiert, welche beim Bootprozess passend geladen werden. Das Laden dieser Konfigurationsdaten bzw. Verknüpfungsregeln geschieht dabei in der Regel aus einem speziellen [[Speicher#Flash | Flash-ROM]]-Baustein heraus. Es kann aber auch ein Mikrocontroller benutzt werden. Die meisten FPGAs bieten daher für diesen Konfigurationsvorgang mehrere Modi an (seriell, parallel, Master/Slave). Da die SRAM-Zellen ihren Inhalt beim Abschalten der Versorgungsspannung verlieren, muss ein SRAM-basierter FPGA bei jedem Einschalten neu konfiguriert werden. Daher benötigt ein solcher FPGA einige Millisekunden bis zu einigen Sekunden, bevor er voll betriebsbereit ist.

Eine FPGA-Familie beinhaltet Typen mit unterschiedlicher Anzahl und Komplexität von Logikzellen. So enthält ein Spartan3-1000 ca. 2,5 mal so viel Logik (FF, LUTs) wie ein Spartan3-400.

FPGAs mit nichtflüchtigem Speicher basieren auf [[Speicher#EEPROM | EEPROM]]-, [[Speicher#Flash | Flash]]-Speicher (einige Familien von Lattice und Actel) oder AntiFuse- Technologie (Actel). Die sogenannten AntiFuse FPGAs sind nur einmalig programmierbar.

=== I/O Anschlüsse ===

FPGAs unterstützen als universal einsetzbare Digital-ICs eine Vielzahl von Signalstandards, um mit den unterschiedlichen Digitalbausteinen im Markt kommunizieren zu können.

==== Pegelstandards ====
Es existieren je nach FPGA-Familie verschiedene TTL-Pegel (5V, 3,3V, 2,5V), differentielle Signalstandards (LVDS, GTL, GTP) und im Hochpreisbereich serielle Hochgeschwindigkeitsstandards mit bis zu 28 Gbit/s. Oftmals sind weitere Eigenschaften wie Treiberstärke und Flankensteilheit für jeden benutzerdefinierbaren Anschluss (User-IO) einstellbar. Meist sind die Pins zu Bänken mit gleichem I/O Standard zusammengefasst. Innerhalb einer solchen Bank arbeiten alle Pins im gleichen I/O Standard und mit der selben I/O Spannung. Für hohe Taktraten wird sowohl für Daten als auch die Takte der LVDS IO-Standard verwendet. Hier sind zwei komplementäre Buffer in unmittelbarer Nachbarschaft angeordnet.

==== Signalrichtung ====
Innerhalb eines FPGAs gibt es nur eine Datenrichtung, d.h. der Ausgang eines Elementes kann nur mit Eingängen verbunden werden, da die FPGA-typischen Optimierungen nur so sinnvoll anwendbar sind. Rückwärtspfade zwischen internen Modulen müssen daher parallel und ausdrücklich aufgebaut werden. Bei den Ports hingegen kann zwischen den Optionen Eingang, Ausgang und Hochohmig gewählt werden. Die dazu benötigten
[[Ausgangsstufen Logik-ICs | Tristatebuffer]] werden implizit über VHDL definiert, indem einem Ausgang zeitabhängig der Zustand "Z" zugewiesen wird. Alternativ kann er explizit als Element eingefügt werden. Bei komplexeren FPGAs sind die Ein- und Ausgänge mit Verzögerungsgliedern versehen, die ein Anpassen des Timings bei Bussen wie z.B. schnellen Speichern ermöglichen.

==== Terminierung ====
Ebenso können je nach Hersteller und Typ interne Pull-Up und Pull-Down-Widerstände sowie Terminationswiderstände zugeschaltet werden, [[Wellenwiderstand | Terminierung]] wird ebenfalls unterstützt.

==== Test und Inbetriebnahme ====
Einige Pins übernehmen besondere Funktionen und sind somit vom Anwender nicht uneingeschränkt oder z.T. auch gar nicht nutzbar. Dazu zählen neben der [[JTAG]]-Schnittstelle z. B. die Pins zum Einlesen der Konfigurationsdaten. Zudem befinden sich hinter vielen IO-Pads sog. [[Boundary_scan| Boundary Scan]] Zellen.

==== Takteingänge ====
Einige wenige Pins (2 - 8) zum Einspeisen des Taktes für das Design vorgesehen. Für schnelle Schaltungen sollten diese reservierten Pins benutzt werden. Sie enthalten kein Eingangs-FF und wirken über instanziierbare Buffer direkt auf Taktnetze / PLLs. Bei leistungsfähigen grossen Applikationen mit mehreren Takten müssen diese genutzt werden, da nur eine begrenzte Zahl von DCMs (Digital Clock Manager) zur Verfügung steht und benachbarte IO-Pins genutzt werden müssen. Für hohe Taktraten werden LVDS-Eingänge verwendet.

==== Verwendung ====
Das I/O Verhalten wird zusammen mit vielen anderen Parametern in einer Datei festgelegt (Xilinx *.ucf, Altera *.acf, Lattice *.lpf). Alternativ können diese auch als Syntheseoption im Kommentarfeld des [[Verilog]]/[[VHDL]] Codes mit angegeben werden. Die Hersteller bieten FPGAs mit gleicher Anzahl von Logikelementen in unterschiedlichen Gehäusen an. So kann der FPGA mit der passenden Anzahl von Pins eingesetzt werden. Das obere Ende markieren Chips mit über 1500 I/Os, die kleinsten bieten ca. 50 User-I/O. Oft werden nur [[IC-Geh%C3%A4useformen#BGA|BGA]] und [[IC-Geh%C3%A4useformen#QFP|QFP]] Gehäuse (bis ca. 240 Pins) angeboten. Umgekehrt kann innerhalb einer Gehäusefamilie hochmigriert werden, d.h. bei gleichbleibendem Pinout, kann ein komplexerer FPGA eingesetzt werden. Das Layout muss dann nicht verändert werden, um eine Schaltung mit mehr Funktionen auszustatten.

=== Besondere Funktionsblöcke ===
Neben den LUTs und den FlipFlops beinhalten FPGAs komplexe Routing- und Speicherkonfigurationsoptionen innerhalb und außerhalb der logischen Elemente, die es überhaupt erst gestatten, komplexe Schalt- und Rechenstrukturen aufzubauen. Aufgrund der gestiegenen Anforderungen geht man immer mehr dazu über, häufig benötigte Schaltungsteile fast in Hardware zu integrieren.

==== DSP-Elemente ====
Für rechenintensive Designs, z. B. in der Signalverarbeitung, enthalten viele FPGAs '''Multiplizierer''' direkt auf dem Chip, die in sehr kurzer Zeit, z.B. auch einem einzigen Taktzyklus, breite Multiplikationen durchführen können. Bei modernen FPGAs treten hier noch Carry-Chains, Akkumulatoren und Speicher-FFs hinzu, um direkt lokal schnelle Summierer und Zähler realisieren zu können.
==== Block-RAMs ====
Ferner haben FPGAs oft einen von den LEs getrennt verfügbaren '''RAM'''-Bereich integriert, der sich in vielfältiger Weise ansprechen lässt. So können damit Single- oder Dualport-RAMs mit variabler Bitbreite erzeugt werden. Üblich sind mehrere (4 - 30) kleinere Dualport [[Speicher#BRAM | RAM-Blöcke]] von 4 - 16 kbit. Einige Familien besitzen einen größeren internen RAM, andere spezielle FIFO-Blöcke.
==== Taktgeneratoren ====
Zur Erzeugung der internen Takte sind '''PLL'''s (Phase Locked Loop) auf dem FPGA integriert. Einige Hersteller setzen eine Kombination aus statischen Taktmultiplizierer '''DLL'''s (Delay Locked Loop) ein. Mittels dieser Blöcke können aus einem Taktsignal weitere Takte abgeleitet werden. Typisch sind Taktverdopplung oder -vervielfachung. Ebenso kann der Takt bei gleicher Frequenz um eine einstellbare Phase verschoben erzeugt werden. Typische Anwendungen sind die Kompensation von Eingangsbufferverzögerungen, die Ansteuerung von [[Speicher#DDR-RAM | DDR-RAMs]] oder die Kompensation von Laufzeitunterschieden zwischen Takt und mit diesem getakteten Steuersignalen. Meist sind 2 - 8 Taktnetzwerke und PLL/DLLs gleicher Anzahl integriert. Siehe auch [[Taktung FPGA/CPLD]].

=== CPU im FPGA ===

Programmierbare Prozessoren sind auch in FPGA-Designs immer häufiger anzutreffen. CPUs sind zwar im Allgemeinen langsamer und weniger effizient, als eine vollständige Implementation aus Logik-Primitiven - aber bei komplexen Abläufen auch deutlich einfacher und zielführender zu programmieren, da die Strukturen festgelegt und damit bekannt sind. Insbesondere bei sequentiellen Aufgaben (Benutzerinterface, komplexe Steueraufgaben etc.) wird man gerne auf eine klassische CPU zurückgreifen. Die CPUs sind teilweise kompatibel zu etablierten Prozessorarchitekturen (MIPS, SPARC, AVR), zum Teil aber auch auf die FPGAs einzelner Hersteller hin optimiert.

Als Programmspeicher werden die FPGA-internen [[Speicher#BRAM | RAM-Blöcke]] oder externe [[Speicher]] (SDRAM, SRAM) genutzt. Für einige Prozessorkerne stehen Hochsprachen wie C, C++ etc. zur Verfügung, andere werden in Assembler programmiert.

==== Hardcores ====
Manche FPGAs haben dazu einen oder mehrere Prozessorkerne (z. B. [[AVR]] bei Atmels FPSLIC, PowerPC bei Xilinx' Virtex bzw Dual ARM A9 bei Xilinx' Zynq oder ARM Cortex-M3 bei Actel (Microsemi) SmartFusion ) als ''HardCores'' physikalisch auf dem Chip integriert, entweder als Chipstruktur auf dem FPGA-kern selbst oder als gebondeter Chip im selben Gehäuse.

==== Softcores ====
Auf der anderen Seite gibt es auch [[FPGA Soft Core | SoftCores]] (z. B. ARM-Cortex-M1 bei IGLOO-FPGA von [http://www.actel.com ACTEL]), Prozessorkerne die als Quelltext oder als vorsynthetisierte Netzliste vorliegen. In Abhängigkeit von den zur Verfügung stehenden Ressourcen können diese ''SoftCores'' beliebig instanziiert werden. Es gibt eine Vielzahl verschiedener ''SoftCores''. Einige sind sehr klein und platzsparend realisiert, damit kann man auch auf vergleichsweise kleinen aktuellen FPGAs problemlos eine 32bit-RISC-CPU integrieren.

== Eigenschaften ==

=== Chipausnutzung ===
Aufgrund des Umstandes, dass FPGAs eine Reihe von allgemeinen Funktionsblöcken, wie BRAM, Multipliers, Transceivern beinhalten, die naturgemäß nie voll ausgenutzt werden können und zudem viele Routing-Resourcen benötigen, um die gewünschten Verschaltungen zu ermöglichen, nutzen FPGAs die Chipfläche relativ schlecht aus, was zu entsprechende geringer finanzieller Effizienz führt.

=== Taktgeschwindigkeit ===
Die maximale „Geschwindigkeit“ eines FPGAs ist von der verwendeten Halbleitertechnologie (Prozess, Strukturgrößen), der internen Schaltungstopologie (Komplexität der LEs), Vorhandensein von harten Strukturen und vor allem vom Design abhängig. Dabei sind der sogenannte Datendurchsatz und die rein maximale Systemtaktfrequenz zu unterscheiden. Die erreichbare Taktfrequenz lässt sich ohne detaillierte Kenntnis des Designs nicht abschätzen, möglich sind je nach »Speed Grade« des ICs typischerweise Taktfrequenzen von 300-600 MHz für die Schaltgeschwindigkeit der reinen Logikelemente. Je nach der Anzahl und Komplexität der pro Takt durchzuführenden Operationen ergeben sich dann reale Systemtaktfrequenzen von meist 10-100 MHz für global operierende Einheiten und bis zu 300 MHz für schnelle lokale Module. Maßgeblich ist in wieweit das Design auf Fläche bzw. Geschwindigkeit hin optimiert und vom Tool synthetisiert wurde: Durch das Einbringen von zusätzlichen Registerstufen lassen sich z. B. zeitkritische Pfade entschärfen (Pipelining), sodass die Frequenz des Chips angehoben werden kann und somit der effektive Datendurchsatz erhöht wird, mit dem Nachteil der gesteigerten Latenz durch das Mehr an Takten. Der Datendurchsatz lässt sich darüber hinaus durch die Nutzung paralleler Architekturen verbessern.

Die Systemfrequenz kann-, muss aber nicht der Frequenz entsprechen, mit der Daten zyklisch eingetaktet und verarbeitet werden; zudem sind Schaltungsteile mit unterschiedlichen Taktfrequenzen zu unterscheiden: Mit einem Systemtakt von 20 MHz lassen sich z. B. 18-Bit AD-Wandler auslesen, die so z. B. alle 1 µs neue Daten liefern, die verarbeitet werden müssen. Bei der Nutzung von 5 solchen Wandlern, die sequentiell verarbeitet werden, lägen 5 MHz Datenfrequenz vor. Für andere Schaltungsteile, die z. B. asynchron an die Peripherie andocken, sowie reine »state machines« können Schaltungsteile auf der 2-4 fachen Frequenz betrieben werden.

Generell sind Fläche und Geschwindigkeit konkurrierende Größen, zwischen denen ein Optimum gefunden werden muss. Für die preiswerten FPGA-Serien wie Spartan (Xilinx) und Cyclone (Altera) sind aufgrund technologischer Randbedingungen etwa 10-30% weniger Taktgeschwindigkeit bei gleichem Design zu erwarten als bei den großen Brüdern der Virtex- (Xilinx) bzw. Stratix-Familie (Altera). Es muss mit mehr Verbrauch an Logikelementen und Taktzyklen gerechnet werden (weniger Routingreserven, geringere Zahl von LUT-Eingängen, langsamere Logikelemente). Dafür sind sie sehr preiswert.

Funktionstechnisch identische Chips werden oft in zwei oder mehr Geschwindigkeitsklassen (speed grades) angeboten, die sich meist durch Bauteilselektion bei der Produktion ergeben. Grob kann man ca. 5%-10% höhere Taktung zwischen zwei speed grades erwarten.

== Herstellung ==

FPGAs heutiger Bauart sind hochkomplexe Strukturen, da sie einerseits sehr hochgetaktet werden müssen, umfangreiche Funktionen bewerkstelligen sollen und damit genügend Resourcen haben müssen, andererseits aber preisgünstig und flexibel sein sollen, was umfangreiche Umschaltmöglichkeiten erfordert. Damit sind FPGAs als universelles Bauteil vergleichsweise teuer. Umso problematischer ist deren Fertigung:

=== Herstellungsprozess ===
FPGAs werden als Analogschaltkreis unter Verwendung von Standardbibliotheken entwickelt, indem fertige, mehrfach simulierte und getestete Blöcke zusammengeschaltet werden. Dabei haben IO-Zellen, Schaltmatritzen und vor allem Controller, RAM-Blöcke und hardcores ihre Funktion mehrfach auf Silizium bewiesen.

=== Hersteller ===

Die größten Hersteller von FPGAs sind [http://www.altera.com Altera] und [http://www.xilinx.com Xilinx]. Weitere Hersteller sind [http://www.latticesemi.com/ Lattice], [http://www.actel.com Actel] und [http://www.atmel.com Atmel].

Einige Hersteller wie Altera verfügen über keine eigene Fabrik (-> "fabless"), sondern lassen ihre entwickelten FPGAs und ASICs bei wechselnden Halbleiterherstellern fertigen. Dies führt zu jeweils günstigen Produktionskosten, allerdings auch zu Qualitätsschwankungen. Auch Liefergarantien sind schwerer zu erhalten, besonders, wenn man darauf angewiesen ist, dass ein Chip auch in 25 Jahren noch zu bekommen ist.

== Anwendung und Programmierung ==
=== Erstellung der FPGA firmware===

==== Design Flow ====
Der Aufbau komplizierter, applikationsnaher Strukturen wird meist durch automatische Routing- und Synthesewerkzeuge erledigt, welche mit einer logischen, funktionellen Beschreibung der Architektur in einer Hardwarebeschreibungssprache wie z.B. [[VHDL]] oder [[Verilog]] "gefüttert" werden. Die Hardwarebeschreibung gelingt ihrerseits z.B. mit Code-generierenden Werkzeugen, mittels derer zuvor Logikstrukturen, hardwarenahe Strukturen, Ablaufdiagramme und Zustandsautomaten formuliert wurden.

Die Korrektheit der Funktion einzelner Blöcke wie der gesamten Schaltung wird mit Simulationswerkzeugen geprüft und im Sinne der Validierung formell nachgewiesen und dokumentiert.

==== Wiederverwendbarkeit ====
Durch die Standardisierung der Architektur einerseits und die Entkopplung von applikationsorientierter Beschreibung sowie Chip- und Hersteller-spezifischer Synthese andererseits, wird die Hardware quasi als Software gebaut. Dies wiederum schafft alle Optionen der Wiederverwendung und Austausch von "Hardwareteilen". So stehen inzwischen komplett nutzbare Schaltungen wie serielle Bausteine, RAM-Controller und vieles mehr zur Verfügung - teilweise sogar in Form von Open Source Projekten.

Andererseits ist eine Tendenz erkennbar, dass Hersteller ihre Software und die damit erstellbare VHDL, speziell bei IP-Cores, immer stärker schützen und abkapseln. Diese produzieren kaum noch allgemeine VHDL, sondern nur noch herstellerspezifische Scripte. Zudem führen immer grösser werdende Unterschiede in den Chipstrukturen und Resourcen in modernen FPGAs dazu, dass die Portierbarkeit weiter eingeschränkt wird. Dies ist besonders bezüglich der Integration von Peripherie-Controllern oder ganzer Mikrocontroller der Fall. Bei SOPC-Systemen sind die generierten Strukturen praktisch überhaupt nicht mehr von einem FPGA-Hersteller zum anderen zu portieren und oftmals nicht einmal mehr zwischen FPGA-Familien desselben Herstellers kompatibel.

=== Anbindung an Mikrocontroller ===
Es gibt unterschiedliche Arten, wie ein FPGA mit einem Controller verbunden sein kann. In der Regel ist der Controller der Master und arbeitet auf den FPGA. Dabei ist zwischen direkten impulsiven Zugriffen auf den FPGA nach Massgabe des internen Ablaufs im Prozessor, die jederzeit und wortweise an irgendeine Adresse erfolgen können und blockweisem Schreiben, also permanentem Datenfluss ohne Adressierung zu unterscheiden.

Das wortweise Schreiben und Lesen erfolgt in Form eines klassischen Speicherinterfaces durch aktiven Zugriff auf den FPGA oder den FPGA hindurch auf einen RAM-Bereich, in den der FPGA seinen Speicher einblendet.

==== Memory Mapped ====
Hierunter versteht man den Zugriff des Mikrocontrollers auf das FPGA in Form eines Speichers. Dabei muss der FPGA ein klassisches Speicherinterface zur Verfügung stellen. In einzelnen Fällen reicht es auch, wenn dieser ein internes Blockram im dual ported Modus an die Ports des Mikrocontrollers heranführt.

==== Streaming IO ====
Liefert ein Mikrocontroller häufig grosse Datenmengen an einen FPGA, ist es mitunter sinnvoll auf einen aktiven Zugriff mit Wortadressierung zu verzichten und einen pipeline-Zugriff zu implementieren. Der FPGA "hört" dazu den Datenbus des FPGA ab und erkennt anhand z.B. der Aktivierung nur einer Schreibleitung den Beginn des Sendens und empfängt dann mit jedem Takt ein Wort. Was die Daten zu bedeuten haben und wohin sie zu schreiben sind, muss dann in den Daten codiert werden. Auch ist es denkbar den FPGA so zu konfigurieren, dass beim Schreiben auf eine ganz bestimmte Adresse ein grösserer Datenblock übergeben wird.

In beiden Fällen wird im FPGA ein FiFo eingesetzt, der synchron mit dem Mikroprozessortakt beschrieben wird. Auf der Seite des FPGAs muss eine FSM überwachen, ob Daten ankommen und diese geeignet verarbeiten.

==== Indirekte Busverbindung ====
Oftmals sind FPGAs und MCUs in grösseren Systemen über Busse verschaltet. So kann der FPGA an einem klassischen Daten-Adress-Bus parallel zu einem RAM und anderen Bausteinen über Adressdekodierung und Chip-Select betrieben werden, oder er wird über ein logisches Interface wie SPI angebunden.

=== Anbindung an RAMs und ROMs ===

==== DDR2 / DDR3 - RAM ====
Während die Ansteuerung eines normalen SRAMS mittels eines klassischen memory mapped interface recht einfach ist, bedürfen DRAMS- speziell mit DDR-Funktion einer aufwändigeren Schaltung, welche die komplizierte Kommoandostruktur der DDR-Ansteuerung versteht, pipelining und gfs cashing praktiziert und das RAM entsprechend bedient. Dabei sind RAM-spezifische Randbedingungen (refresh / self refresh) zu beachten. Für FPGAs existieren hier eine Reihe von konfigurierbaren IP-Cores

==== SPI-Flash ====
Die Anbindung über SPI erfolgt meist über serielle Verbindungen wie I2C, da nur wenig Bandbreite benötigt wird. In selteneren Fällen werden FPGAs parallel mit einem Flash verbunden, z.B. bei grossen FPGAs mit umfangreichem image, welches aus einem Flash schnell geladen werden soll.

=== Anbindung an Peripherie ===
Typische Anwendungen für FPGAs sind die breitbandige (grosse Busbreite und/oder hohe Taktfrequenz) Gewinnung- und Verarbeitung von Daten, bei denen DSPs oder MCUs nicht mehr (effektiv) eingesetzt werden können. Typische Beispiele dafür sind:

==== Videotechnik ====
[[Bildsensor]]en produzieren traditionell die grössten Datenmengen je Zeiteinheit und sind ohne FPGAs praktisch nicht mit der Aussenwelt in Kontakt zu bringen. FPGAs arbeiten hier entweder auf der Kunden- oder auch der Herstellerseite, um die komplexen Datenströme anzunehmen, vorzuverarbeiten und in eine reduziertes, praktikableres Datenformat umzusetzen. Auch die Annahme eines Videoformates ist praktisch nur mit FPGAs möglich.

Die benötigten Datenschnittstellen können mit Hilfe von Transceiver-Ports / LVDS manuell realisiert werden, oder es werden Umsetzer-Chips verwendet. Beispiele:

* HDMI-Transceiver für FPGAs ohne Gigabit-Transceiver
* SERDES-Transceiver für mittelpreise FPGAs ohne SERDES / sehr hohe Frequenzen
* Camera-Link-Deserializer (für langsame FPGAs)
* LVDS-Buffer-Deserializer (für langsame FPGAs ohne LVDS buffer)
* DVI-Buffer

Für Analoge Daten benötigt man selbstredend noch Video-ADCs / Video-DACs, die überhaupt erst ein digitales Signal erzeugen.

==== Gigabit-Ethernet ====
Für die Umsetzung auf den (praktisch analogen) [[Ethernet]]-Standard braucht es immer einen sogenannten [[Glossar#p|PHY]], also einen physikalischen Zusatzchip. Dieser vollzieht die [[Glossar#p|5PAM]]-Modulation und die Codierung im 10/8-Format. Die Ankopplung an den FPGA erfolgt direkt.

Während althergebrachte 100MBit-Verbindungen dabei oft noch mit UCs und softcores zu bedienen waren, können 1GBit-Netzwerke nur noch mit FPGAs sinnvoll angesteuert werden. Umgekehrt ist das Gigabit-Netzwerk eine gute Lösung, um Daten effektiv und billig in einen PC zu transportieren, da moderne PCs alle eine GBit-Karte besitzen und die Datenrate bei schnellen CPUs auch weitgehend ausgenutzt werden kann. Typische Bandbreiten bewegen sich für Linux mit unmodifizierten Treibern bei 700MBit-800MBit.

Der [[Glossar#m|MAC]], bzw MAC-ähnliche Funktionen, sind im FPGA direkt implementierbar (z.B. mit IP-Cores) und können mit einfachen [[Glossar#f|FSM]]s angesteuert werden. Für die Verwendung von C-Software ist es notwendig, einen hardcore zu verwenden, da mit softcores die Bandbreite kaum erreicht werden kann. Besonders das Verpacken der Daten, die Abarbeitung des Protokolls sowie die Bildung der Ethernet-header mit Checksummen, CRC und zusätzlichen Prüf- und Steuerinformationen sind in VHDL sehr einfach und entspannt zu erzeugen, weil parallel gearbeitet werden kann.

Die Bandbreite einer typischen [[Glossar#g|GMII]]-Verbindung mit [[Glossar#d|DDR]] beträgt 2x150MHz x 8 Bit, was mit mittleren FPGAs gut zu machen ist. Die interne Bandbreite ohne header beträgt dann typisch etwa 800MBit, z.B. 50MHz x 16 Bit für die Daten. Ab diesem Punkt ist dann wieder ein schneller softcore einsetzbar.

==== High-Speed-USB ====
Für die Übersetzung auf den immer schnelleren USB-Bus (inzwischen bis 5Gb Bandbreite!) stehen Chips zur Verfügung, die sich in vergleichsweise einfacher Weise ansteuern lassen. Eine passende Sende- und Empfangsarchtiktur ist in FPGAs relativ rasch zu implementieren.

=== Implementierung von Steuerfunktionen ===
In den meisten FPGA-Applikationen sind mehr oder weniger komplizierte Abläufe zu integrieren, die den Datenfluss steuern und die einzelnen Komponenten so mit einenander verschalten, dass sie wunschgemäss aufeinander reagieren.

Mit nativem VHDL sind einfache sequenzielle Abläufe mit überschaubaren Verschlachtelungstiefen und Schleifen direkt in Form von Zählersteuerungen oder abstrakten State Machines realisierbar. Dazu kann auf die automatische Codegeneration aus state machine designern heraus oder die halbautomatische Erzeugung von Code mit z.B. Excel zurückgreifen, die die Enumeration von states, die Abfragen und die Sprünge zu den nächsten states automatisch vollzieht. Dies hat aber seine Grenzen, weil dies früher oder später unübersichtlich wird und nicht mehr so gut pflegbar ist. Zudem kann sich der Code stark aufblähen und die Zusammenfassung etwaiger Redundanz durch die Synthese zu hohen Synthesezeiten führen.

Applikationen, die nicht ganz so zeitkritisch sind, sollten lieber mit einer flexiblen, verschachtelten Struktur von 2 state machines abgearbeitet werden, bei denen der Ablauf von der Generation des Timings für die Hardware getrennt ist. In reinen Ablaufsteuerung stehen dann wie in einem Befehlsspeicher abstrakte Codes hintereinander und werden mittels einer intelligenten Struktur sequenziell abgearbeitet werden. Diese agiert wie ein Befehlsinterpreter und stösst eine untergeordnete state machine an. Damit wird zwar mehr Zeit für die Verwaltung benötigt, es führt aber letztlich zu quantitav weniger Steuer-Code. Die Befehlsfolgen lassen sich z.B. günstig in einem ROM realisieren. Die gesamte Steuerung wird intelligenter und insgesamt kleiner.

Eine deartige Steuerlogik lässt sich soweit ausbauen, dass untergeordnete state machines wie Unterprogramme ablaufen und durch ein flexibles Hauptprogramm gesteuert werden, womit sie sich immer mehr einer Prozessorarchitektur annähert.

Wenn die Komplexität viele "Befehle" erfordert, gfs noch gerechnet und viel entschieden werden muss, lohnt der Rückgriff auf einen vorgefertigen Softcore. Dies hat den Vorteil, dass eine Standardstruktur verwendet wird, für die es erweiterte Entwicklungs- und Debugging-Software gibt. Spätestens, wenn man mit virtuellen Datenstrukturen und rekursiven Funktionen arbeitet, oder z.B. Zeichenkettenverarbeitung braucht, ist ein Softcore unerlässlich,
weil dann alle Methoden-, Variablen und sonstige Aspekte der jeweiligen Hochsprache verwendet werden können.

=== Beispiele von VHDL Code ===
Siehe [[VHDL_Softwarepool]]

== Einsatz in elektronischen Schaltungen ==
Der Einsatz von modernen FPGAs erfordert neben dem grundsätzlichen Wissen im Bezug auf den design flow und den für FPGAs optimierten Schaltungs- und Rechenstrukturen auch grosses Knowhow im Bereich der analogen Schaltungstechnik sowie auch der effektiven Vorgehensweise beim Design.

=== FPGA aus analoger Sicht ===
FPGAs bedürfen heute eines perfekten Layouts, um mit RAMs und externen Chips zusammenarbeiten zu können, da sowohl die internen, als auch externen Taktfrequenzen rapide angestiegen sind. Ferner ist grosses Augenmerk auf die Spannungsversorgungen zu legen.

=== Integration ins PCB ===
Weiter ist es heute kaum noch möglich, FPGA-Design vom board-Design funktionell zu trennen, wie man es mit Blick auf den scheinbar rein logischen Schaltungsentwurf glauben könnte und früher auch der Fall war. Da FPGAs heute stark dedizierte Funktionen enthalten, die nicht in jeder IO-Zelle zur Verfügung stehen oder spezielle Bank-Konfigurationen erforden, muss der Schaltungsentwurf und das Layouten des FPGAs und des Boards einhergehen.

=== Entwicklungsboards und Starter-Kits ===
Von mehreren Seiten gibt es im Markt eine ganze Palette von sogenannten Entwicklungs- und Evaluierungsboards. Diese eignen sich nicht nur zum Kennenlernen des Chips, bez. zur Validierung der Lösung (ob die Schaltung wie gebaut auch im konkreten Ziel-FPGAs arbeitet) sondern werden immer öfter auch in bestehenden Systemen verbaut, weil aufgrund einer geringen Stückzahl die Selbstentwicklung nicht lohnt.

Siehe [[Liste von FPGA Eval boards]]

=== FPGA als Ersatz von alten digitalen ICs und Prozessoren ===
Es gibt vielfach den Wunsch, ICs, die nicht mehr direkt zu beschaffen sind, durch FPGAs (oder wenn möglich CPLDs) zu ersetzen. Gerade ältere Schaltungen
basieren aber durchaus noch auf 5V TTL und CMOS Logik. Oft sind die Systeme nicht ohne sehr hohen Aufwand und Verlust der Wirtschaftlichkeit zu ersetzen (wie ältere, produktive Industrieanalagen oder komplexe Rechensysteme - aber auch wenn es um die Erhaltung alter Hardware bei "retro-computing" geht).

Nun bieten heute erhältliche (und günstige) FPGAs - aufgrund ihrer verwendeten Technologie - keine direkte 5V Kompatibilität mehr. FPGAs wie die Spartan II (nicht IIe), erlauben zumindest noch "5V Toleranz" auf den I/O-Pins. Das heißt: das FPGA wird zwar mit 3.3V versorgt und kann daher nur 3.3V am Ausgang treiben, erlaubt aber 5V von externen Bausteinen am Pin - dies ist nach wie vor TTL kompatibel, aber auch viele CMOS-Schaltungen können so durchaus noch betrieben werden.

Für neueste 3.3V (oder weniger) FPGAs kann man Levelshifter-Schaltungen verwenden, die entweder bidirektional ausgeführt sind und ein "open-drain-artiges" Verhalten zeigen (also beide Seiten können die Leitung nur auf Lowpegel treiben, der Highpegel wird durch pull-up Widerstände erreicht) oder die unidirektional (mit optionaler Richtungsumkehr und/oder Treiberdeaktivierung über Kontrolleingänge) gebaut sind. Verwendung von Spannungsteilern, Zenerdioden-Schaltungen oder Ausnutzung von Diodenlimitierungen der I/O Treiber des FPGAs (und Verwendung eines Serienwiderstands zur Stromlimitierung) sind zumeist nur für niedrige Schaltfrequenzen gut geeignet und sorgen für eine erhöhte Stromaufnahme.

Siehe auch: [[Pegelwandler]]

== Debugging-Hilfen ==
=== Soft-Debugging ===

=== Logikanalysatoren ===
Gerade beim [[Debugging]] größerer FPGA-Designs ist es oft notwendig, auf interne Signale und Busse zuzugreifen, die aus routing- oder Platzgründen nicht an Pins des FPGAs gelegt - und mit konventionellen Analysatoren beobachtet werden können. Nebst den einschlägigen Tools der Hersteller, welche Signal probing über JTAG gestatten (z. B. ChipsScope und SignalTap), werden in FPGAs oft mehr oder weniger komplexe [[Logic Analyzer]] integriert, welche die internen Signale in vielfältiger Weise aufzeichnen. Diese werden in Block-RAMs oder FIFOs gespeichert und durch externe Master ausgelesen. Hier kommen auf der Platine befindliche MCUs oder fremd zugreifende FPGAs / CPUs in Betracht, welche über unterschiedliche Kommunikationsverbindungen (seriell, parallel, LVDS) angeschlossen sind. Dazu werden in die FPGAs entsprechende Cores und state machines instanziiert und mit Software auf PC-Seite ausgelesen.

Nachfolgend einige Beispiele:

==== Automatisch instanziierte Logic Analyzer ====
Praktisch alle FPGA-Hersteller bieten die Möglichkeit, mit einem internen Tool ein script zu erzeugen, welches der Synthese übergeben wird, welche dann anhand von Signallisten und diversen Randbedingungen einen LA automatisiert aufbaut und verdrahtet. SampleZeit und -Takt sind dabei genauso einstellbar, wie RAM-Tiefe und -Breite. Die so generierten Datenpakete können dann mittels JTAG ausgelesen werden. Im Continous-Betrieb können so sogar permanente Datenausgaben wie bei einem Oszilloskop vorgenommen werden.

==== Proprietärer serieller Logic Analyzer ====

Die einfachste Möglichkeit ist die direkte Instanziierung eines Blockrams als FIFO mit "breitem" Busanschluss: Linksseitig besitzt das FIFO eine Breite von z. B. 256 Bit (Xilinx-Rams lassen sich ohne weitere Umbeschaltung über den Wizzard mit bis zu 1024 Bits deklarieren und nutzen). Rechtsseitig einen 16- oder 32 Bit breiten Busanschluss für einen Prozessor bzw Parallelinterface oder einen 1 Bit breiten Anschluss für ein serielles streaming interface. Mit einem FiFo-enable können die zu sampelnden Zeiten (Busphasen) festgelegt werden, z. B. anhand eines Kriteriums wie die Erfüllung einer bestimmten mathematischen Bedingung, die man in VHDL formuliert, oder es wird einfach ein Trigger gesetzt. Solange das FiFo nicht voll ist, kann geschrieben werden, was durch die interne FiFo-Verwaltung selbst bereits komplett geregelt wird.

Beim einfachen seriellen Logic Analyzer benötigt man nur noch einen kleinen Core, der permanent das FiFo liest, und den seriellen Overhead (Startbit, Stoppbit, Parity und gfs CRC) hinzufügt. Mit einem einfach Pegelwandler kann so ein PC direkt angeschlossen werden.

Auch denkbar ist die Anbindung an ein fremdes FPGA-board mit viel Speicher über (LV-)DS-Kommunikation. In komplexeren Systemen wird ein CAN- oder USB-Core eingesetzt.

Wenn mittels des Kriteriums nur ganz bestimmte kritische Phasen herausgesampelt werden (z. B. das Auftauchen eines bestimmten Rechenfehlers im FPGA) und so das Datenaufkommen je Zeiteinheit über längere Zeit betrachtet eher gering ist, kann bei geeignetem Datendurchsatz in Echtzeit dauerhaft mitprotokolliert werden.

==== BusProbe ====
Mit der BusProbe, dem Debugging Core von abaxor engineering, kann der Entwickler den Signalfluss im FPGA-Design auch über einen längeren Zeitraum überwachen und am PC aufzeichnen. Der Core verarbeitet an jedem Eingang einen kompletten Bus.

Die Daten werden gemultiplext zum PC geschickt und dort per Software demultiplext. Im PC erfolgt auch die Auswertung mit beliebigen Analyse-Tools.

Gegenüber dem Betriebssystem verhält sich die BusProbe wie eine Festplatte, von der die Daten mit gewöhnlichen Zugriffen gelesen werden können.

* Streaming der Daten zum PC mit mehr als 20 MByte/s
* keine Treiber im PC da Nutzung von Standardschnittstellen (USB oder IDE)
* Hot-Plugging
* Visualisierung mit beliebigen Programmen
* geringer Logikaufwand

[http://www.abaxor.de/produkte.html abaxor.de-Webseite]

==== open source Logikanalysator ====
===== sump.org =====
Ein einfacher, übersichtlicher Logikanalysator findet sich auf sump.org. Er liegt im Quelltext vor wird mit ins Design einsynthetisiert. Als Speicher dient wahlweise SRAM oder internes RAM. Es können 32 Kanäle mit 100 MHz (oder weniger) gesampelt werden. Die Bediensoftware läuft platformunabhängig unter Java und benötigt eine serielle Schnittstelle (auch über USB-seriell Wandler) zum Core.

[http://de.sump.org/projects/analyzer/ sump.org-Webseite]

===== Weitere =====

http://www.mikrocontroller.net/articles/Logic_Analyzer

== FPGA-Design aus Projektsicht ==
Vielfach wird die Auffassung vertreten, die FPGA-Entwicklung gehöre zur Hardwareentwicklung, da es sich um ein elektronisches Bauteil handle, welches lediglich konfiguriert werde. Man spricht bei der FPGA-Entwicklung oft auch ausdrücklich nicht vom "Programmieren" sondern "Beschreiben" der Hardware. Beides ist aus folgenden Gründen unrichtig:

* Die Vorgehensweise, die Struktur einer Schaltung durch virtuelle Konstrukte wie Logikgatter, Multiplexer und Schalter zu definieren, die in der Praxis so gar nicht exisiteren, sondern später in Form von LUTs realisiert wird, ist zwar formell eine Beschreibung einer Struktur, jedoch ist es eine sehr abstrahierte Form, da equivalente Funktionen definiert werden. Die Sollhardware wird demnach in weicher Form beschrieben.

* Der output des Designers besteht aus Grafiken, Skripten, Anweisungen, Einstellungen der Synthesesoftware und Strukturvorgaben, die nicht selbst Hardware sind, sondern Anweisungen an eine Erzeugersoftware und stellen damit ein Programm (lat. "Vorschrift") dar.

* Neben den allein schon durch die Nutzung bestimmter Funktionen wie RAMs, MCBs und Soft-Cores implizit vorgegebenen Abläufen im FPGA, werden fast immer auch noch weitere, explizite Handlungsabläufe mit Reaktionen auf äussere Einflüsse implementiert, die als klassische Software aufzufassen sind.

* Der erzeugte Code der Erzeugersoftware wiederum ist selbst ein Programm und wird zusammen wie die Quellinformation des Designers archiviert, versioniert und wie übliche Software gehandhabt.

Damit erfüllt die FPGA-Entwicklung formell mehrere Bedingungen, die als Softwareentwicklung aufgefasst und eingruppiert zu werden. Andererseits ergeben sich durch die weiter oben erwähnten, sehr ausgeprägten Themen im Bereich der Elektronik (z.B. der Nachrichten- und HF-Technik) sowie der Physik eine Vielzahl von harten Anforderungen, der klassischen Hardwareentwicklung.

Zusammengefasst kann man daher 2 grundlegende Aspekte des FPGA-Designs konstatieren, die je nach Anwendungsfall als mehr oder weniger unabhängig von einander gesehen werden können.

=== Logikdesign ===
Das funktionslogische Design besteht aus dem Entwurf des Systems, der benötigten Abläufe und der zu realisierenden Protokolle und Berechnungsverfahren. Hierbei sind Kenntnisse im Systementwurf, gfs. von SOPC-Systemen, der üblichen Bussysteme und der Software generell nötig. Hinzu treten Kenntnisse in der elementaren und/oder der komplexen abstrakten Mathematik und der Signalverarbeitung sowie der theoretischen Nachrichtentechnik. Ferner sind Methoden des Script- und Softwareentwurfes, sowie Handhabung von Software nötig.

Dies alles stellt den Anteil dar, der klassischerweise als Softwareentwicklung aufgefasst wird. Es ist die Schnittstelle zur Funktionsschicht, also der grundsätzlichen Funktion eines Gerätes.

=== Schaltungsdesign ===
Das praktische, hardwaretechnische Anteil des Designens erstreckt sich zudem über die physikalischen Themen der Temperatur- und Betriebsstabilität, der Strahlungs- und Störsicherheit, der Produzier- und Herstellbarkeit, des Wirkens und der Fehleranfälligkeit interner Schaltungsstrukturen, der Art und Weise der Ressourcennutzung bei unterschiedlichen Realisationsformen - besonders, wenn es auch Kostenoptimierung ankommt, des Analogverhalten der IOs und internen Strukturen im Bezug auf Frequenz und Pegel, der Signalintegrität der FPGAs und der Leiterbahnen sowie alle Anfordernisse im Umfeld der anzubindenen Chips.

Dies ist der Anteil der gerne als Hardwareentwicklung eingestuft wird. Er stellt die Schnittstelle zur Physik und der Fertigung dar.

=== Fazit ===
Die Verwendung von FPGAs ist heute komplexer denn je und erfordert in aller Regel starke Kenntnisse in beiden Feldern. FPGA-Entwicklung kann praktisch wie die Einbindung eines komplexen Evaluierungsboards oder einer programierbaren Steuerplatine mit festgelegten Funktionen aufgefasst werden.

== Siehe auch ==
* [[Hardwarebeschreibungssprachen]]
* [[Reset für FPGA/CPLD]]
* [[Taktung FPGA/CPLD]]
* Projekt [[Audio-DSP mit Spartan 3-FPGA]]
* Projekt [[FPGA Lab]]

== Forumlinks ==
* [http://www.mikrocontroller.net/topic/274159 Tonleiter im PLD] - Beispiel einer einfachen Musikapplikation
* [http://www.mikrocontroller.net/topic/326462?goto=3564346#3564346 Kopierschutz] für FPGAs und programmierbare ICs

== Weblinks ==
* [http://www.fpga4fun.com/index.html FPGA4Fun] - FPGA-Projekte, größtenteils mit Altera und Verilog
* [http://marcowuen.wordpress.com/2014/09/08/overview-cheap-fpga-development-boards/ Übersicht Development Boards] - Zusammenstellung günstiger FPGA Boards unter 100$
* [http://video.google.com/videoplay?docid=-4969729965240981475 Ein Vortrag, auf Englisch: General Purpose, Low Power Supercomputing Using Reconfiguration Logic]
* http://www.opencores.org - FPGA-Projekte, Opensource, jeder kann seine Eigenen einstellen und an anderen mitarbeiten. U.a. gibt es verschiedene CPUs für FPGAs.
* [http://pin4.at/pro_misc.php#fdil Projekt "FDIL v2"]: 5V DIL-Ersatz mit 100kGates Spartan II FPGA (Englisch)
* [http://members.optushome.com.au/jekent/FPGA.htm John's FPGA Page]
* [http://www.embedded.com/columns/whatsnew/197003073 More about designing with embedded FPGAs] by Bernard Cole, Embedded.com
* [http://chaosradio.ccc.de/cre117.html Chaosradio Express - FPGA]
* [http://www.pin4.at/pro_custom.php Custom IC replacements] - DIL / TTL-Replacements mit FPGA (Englisch)

[[Category:FPGA und Co|Grundlagen|Bauteile]]

Prozessorarchitekturen

2016-01-22T10:39:33Z

Newgeneration:

== Von-Neumann-Architektur ==

Die Von-Neumann-Architektur zeichnet sich dadurch aus, dass Code und Daten über die '''gleichen''' [[Bus|Busse]] übertragen werden. Dadurch gibt es erstmal keine Unterscheidung zwischen Code- und Datenbereichen und Code kann auch im Datenbereich ausgeführt werden.

Bekannte Vertreter dieser Architektur sind z. B. die 6502, [[68HC08]] Familien und die [[x86]]-Familie (Pentium, Athlon usw.).

== Harvard-Architektur ==

Das Hauptmerkmal der Harvard-Architektur ist, dass Programm- und Datenspeicher über '''getrennte''' [[Bus]]se angesteuert werden. Daraus ergibt sich der Vorteil, dass auf Daten- und Programmspeicher gleichzeitig zugegriffen werden kann. Es bedeutet aber auch, dass der echte Code im Datenspeicher nicht ausgeführt werden kann. Dazu muss er erst in den Codespeicher übertragen werden.

Benutzt wird die Harvard-Architektur z. B. von den [[AVR]]s und den meisten [[DSP]]s.

== Kritik ==

Es gibt Implementierungen, bei denen mehrere getrennte Adressräume über den gleichen Bus angesprochen werden. Beispielsweise betrifft das den I/O-Adressraum von 8080 und infolgedessen x86, der physikalisch den normalen Datenbus verwendet. Andererseits gibt es Implementierungen, bei denen separate Busse für Befehle und Daten vorliegen, obwohl sich alles im gleichen Adressraum befindet. Beispielsweise im Zusammenhang mit Caches, auch externen Caches.

In der Literatur und in diesem Artikel wird die Unterscheidung zwischen Harvard und von-Neumann meist an den Bussen festgemacht. Man kann das aber auch über die Adressräume differenzieren: Ob Programm- und Datenspeicher in einem gemeinsamen Adressraum liegen, oder getrennt adressiert werden. Denn ob die Busse selbst getrennt oder gemeinsam sind, ist für den Programmierer unsichtbar, das hat nur auf die Geschwindigkeit Einfluss. Getrennte Adressräume beeinflussen jedoch die ganze Programmierung einschliesslich Hochsprache, zumal die üblicherweise verwendete Sprache C mit Daten, die in einem getrennten Programmadressraum liegen (Flash-ROM), von Haus aus nicht umgehen kann und daher Spracherweiterungen notwendig sind (im GCC nicht möglich).

So sind sowohl PC-Prozessoren als auch die verbreiteten [[ARM]]-Versionen hinsichtlich der Busse mal dies mal jenes, je nach verwendetem Core (ARM7: von Neumann, ARM9 Harvard, bis 486: von Neumann, ab Pentium: Harvard). Wodurch das Kriterium "Busse" ziemlich sinnlos wird.

[[Kategorie:Mikrocontroller| ]]

Vektor-Font in C

2016-01-01T22:04:46Z

Newgeneration: /* Interface */

[[Bild:Vekfont_1-5.png|thumb|right|Eine PNG-Grafik für "Hallo Welt!" in den Zoom-Stufen 1-5, erstellt aus einer mit VEKFONT erzeugten [http://de.wikipedia.org/wiki/Portable_Bitmap PBM-Grafik].]]

''von [[benutzer:gjlayde|gjlayde]]''

VEKFONT ist ein C-Modul zur Erzeugung von Vektor-Schriften. Ursprünglich wurde die Software für einen [[Mikrocontroller]] der [[AVR]]-Familie geschrieben, um in einer Scope-Uhr Zeichen und Texte auf die Röhre auszugeben. Die Software ist aber so allgemein gehalten, dass sie ebenso auf einem PC einsetzbar ist.
So wurden die Beispiel-Grafiken, die in diesem Artikel zu sehen sind, nicht auf einem AVR erzeugt (was problemlos möglich wäre), sondern direkt auf einem PC.

Die Software ist in einem weiten Bereich via Defines konfigurierbar, so dass sie an die eigenen Bedürfnisse angepasst werden kann, ohne die Quelle ändern zu müssen.

== Einsatzgebiet ==
[[Bild:Vekfont_1-3.svg|thumb|right|Eine SVG-Grafik für "Hallo Welt!" in den Zoom-Stufen 1-3 und unterschiedlicher Stiftdicke gezeichnet]]

VEKFONT eignet sich zur Erzeugung von Zeichen und Texten auf flüchtigen Anzeigen wie Elektronenröhren und x/y-Medien wie einem Plotter. Pro Aufruf der Hauptroutine wird über einen Callback-Mechanismus immer genau ein Pixel ausgegeben, so dass die Routine auch in einer [[Interrupt]]-Service-Routine (ISR) verwendet werden kann. Über einen zweiten Callback wird über einen Sprung der Ausgabeposition informiert, was zur Strahlaustastung bei einer Röhre oder zum Anheben des Stiftes bei einem Plotter genutzt werden kann.

Die Software ist auf Performance ausgelegt. Auf einem µC sollen möglichst wenig der kostbaren Ressourcen "Laufzeit" und "Programmspeicher" verbraucht werden. Gleichwohl ist VEKFONT parametrierbar und kann angepasst werden, indem z. B. nur Teile des Zeichensatzes wie Großbuchstaben verwendet werden, was zur Platzersparnis führt.

== Interface ==

Um einen Text zu erzeugen, müssen zunächst einige Einstellungen vorgenommen und die Callbacks implementiert werden, dazu gehört z. B. das Initialisieren der verwendeten vecfont_t-Struktur

;vecfont_t: Die Struktur, die für die Ausgabe genutzt wird. Nur einige der wichtigsten Felder werden im folgenden erläutert.

;char* .text: Der auszugebende Text als Null-terminierter String.

;uint8_t .zoom: Die Vergrößerungsstufe. Nur ganzzahlige Zoom-Stufen sind realisiert.

;void .beam_xy (vf_uint_t x, vf_uint_t y): Die Callback-Funktion wird aufgerufen, wenn ein Pixel an die Position (x,y) auszugeben ist.

;void .beam_skip (void): Die Callback-Funktion wird aufgerufen, wenn die Ausgabe-Position einen Sprung macht.

;vf_uint_t .start.x:
;vf_uint_t .start.y: Die Start-Koordinaten legen die untere, linke Ecke des ersten Zeichens fest. Hier beginnt die Text-Ausgabe.

Nach der Initialisierung wird die Funktion vecfont_draw_letters so lange aufgerufen, bis sie einen Wert ungleich Null liefert.

;uint8_t vecfont_draw_letters (vecfont_t *vf): Bei jedem Aufruf wird genau ein Pixel ausgegeben, d.h. der Callback vf->beam_xy wird genau einmal aufgerufen. Zusätzlich kann ein Aufruf von vf->beam_skip stattfinden, der über einen Sprung der Ausgabeposition informiert.
:return-Wert ist
:;== 0: Falls die Ausgabe noch nicht fertig ist und noch weitere Pixel auszugeben sind.
:;!= 0: Falls die Ausgebe fertig ist und alle Pixel des Textes ausgegeben wurden.

Ein simples Beispielprogramm für den PC, das einfach nur Punkte in einem zweidimensionalen Array setzt, könnte so aussehen:

<syntaxhighlight lang="c">
#include "vektor-zeichen.h"

// Unser Vektorfont-Objekt
static vecfont_t font;

// Ein Array von 256 x 256 Pixeln
static char pixel[256][256];

static void beam_skip (void)
{
// Der Strahl macht jetzt einen Sprung
}

static void beam_xy (vf_uint_t x, vf_uint_t y)
{
// Es wird ein neuer Pixel gezeichnet
pixel[x][y] = 1;
}

int main ()
{
// Größe, Position und Text angeben
font.zoom = 2;
font.start.x = 10;
font.start.y = 100;
font.text = "Hallo Welt!";

// Callbacks festlegen
font.beam_skip = beam_skip;
font.beam_xy = beam_xy;

// Text rauspixeln
while (!vecfont_draw_letters (&font));

// Ausgabe von pixel[][], z.B. als Grafik
// ...

return 0;
}
</syntaxhighlight>

Übersetzt werden kann das ganze mit
gcc -std=gnu99 main.c vektor-zeichen.c vektor-zeichen-data.c -DVEKFONT='(-1)' -O2 -o main.exe

== Konfigurierung ==

Die Konfiguration der Software geschieht i.W. beim Übersetzen über das Define VEKFONT. Die meisten Features können darüber aktiviert bzw. deaktiviert werden, so dass deaktivierte und unbenutzte Features nicht unnötig Programmspeicher und/oder Laufzeit auffressen.

Standardmäßig sind alle Features deaktiviert, was dem gcc-Kommandozeilenargument -DVEKFONT='0' entspricht. Alle Features werden aktiviert durch -DVEKFONT='(-1)', was alle Bits in der Bitmaske VEKFONT setzt.

Um einen Zeichensatz zu erhalten, der Kleinbuchstaben und Umlaute unterstützt, kann man also beim Compilieren angeben
-DVEKFONT='(VF_LOWERCASE | VF_UMLAUTS)'.
Im einzelnen besteht <code>VEKFONT</code> aus den folgenden Schaltern:

;VF_UMLAUTS: Der Zeichensatz enthält Umlaute und Ligaturen (ß)
;VF_LOWERCASE: Der Zeichensatz enthält Kleinbuchstaben
;VF_ARROWS: Der Zeichensatz enthält Pfeil-Symbole, ansprechbar via <, >, \, ^
;VF_PUNKT: Der Zeichensatz kennt Punktuation wie +, -, *, ?, ...
;VF_MAP_UMLAUTS: Falls der Zeichensatz keine Umlaute enthält wird Ä als AE dargestellt, etc.
;VF_MAP_LOWERCASE: Falls der Zeichensatz keine Kleinbuchstaben enthält werden Kleinbuchstaben als Großbuchstaben dargestellt.
;VF_SHRINKY: Kleinbuchstaben 'e' und 's' ragen 1 Pixel über die Mittellinie und werden daher zu groß. Wird dieses Flag gesetzt, dann werden diese Buchstaben etwas geschrumpft, damit sie die Höhe der anderen Kleinbuchstaben erhalten.
;VF_PROPORTIONAL: Zur Laufzeit kann via <code>.proportional</code> zwischen Fixed-Font und Proportionalschrift umgestellt werden. Auf den Platzbedarf des Zeichensatzes hat das keinen Einfluss, das Programm wird aber etwas langsamer und größer.
;VF_ALWAYS_PROPORTIONAL: Die Schrift wird immer als Proportionalschrift angezeigt. Das Bit ist stärker als VF_PROPORTIONAL

Eine eingehende Dokumentation findet sich im Header vektor-zeichen.h.

== Performance ==

Der Resourcen-Verbrauch von VEKFONT kann in recht weiten Grenzen angepasst werden. An Speicherverbrauch auf einem AVR muß man rechnen
* Flash: 1/2–1 kByte für den Zeichensatz, abhängig von Konfiguration
* Flash: 1/2–1 kByte für den Programmcode, abhängig von Konfiguration
* RAM: einige Bytes + Größe der Lookup-Tabelle. Hinzu kommt die Große der Vecfont_t-Struktur, die man selbst anlegen muß.

=== Lookup-Tabelle ===
Die Lookup-Tabelle dient zum schnellen Auffinden der Zeicheninformation zu einem auszugebenden Zeichen. Standardmässig ist die Lookup-Tabelle deaktiviert, was zu einer längeren Ausführungszeit bei RAM-Ersparnis führt. Aktiviert wird die Lookup-Tabelle, indem man ihren Start und ihr Ende – jeweils in Form von ASCII-Codes – festlegt, was über die folgenden Makros geschieht:

;VF_LOOKUP_START:
;VF_LOOKUP_END: Definiert ersten und letzten ASCII-Code der Zeichen, die in die Lookup-Tabelle aufgenommen werden. Die Tabelle wird dynamisch aufgebaut, so daß die allererste Ausgabe eines Zeichens länger dauert als die Nachfolgenden Ausgaben, weil bei der Erstausgabe nach der Zeicheninformation gesucht werden muss.
Beispiel:
-DVF_LOOKUP_START=0x20 -DVF_LOOKUP_END=127

=== Verwendete Arithmetik ===

Standardmässig wird mit einer 8-Bit Arithmetik hantiert. Falls dies für die anzusteuernde Anzeige nicht ausreicht, kann per
-DVF_INT_BITS=16
zu einer 16-Bit Arithmetik umgestellt werden. Dies hat Einfluß auf die verwendeten Typen wie vf_uint_t.

=== Feste Zoom-Stufe ===

Falls nur Texte in einer einzigen Zoom-Stufe ausgegeben werden und daher keine Notwendigkeit besteht, den Zoom zur Laufzeit zu ändern, so kann er über das Makro VF_ZOOM angegeben werden. Das spart Code und Laufzeit. Beispiel:
-DVF_ZOOM=2

== Download ==

* [[Datei:Vektor-Font_in_C.zip|Vektor-Font_in_C.zip]]

Dieses Archiv enthält alle Quellen, ein Makefile sowie die Beispielprogramme pc-vecfont.c (PC), pc-vecfont-svg.c (PC), avr-vecfont.c (AVR).

Als Software wird benötigt:
* GNU make
* Eine gcc-Host-Toolchain
* Eine [[avr-gcc]]-Toolchain
* convert aus dem [http://www.imagemagick.org ImageMagick]-Paket zum Umwandeln von PBM nach PNG.
* Optional ein SVG-Betrachter wie [http://www.inkscape.org Inkview] oder [http://www.firefox.com FireFox].

;pc-vecfont.c: Erstellt aus dem per Kommandozeile angegebenen Text eine [http://de.wikipedia.org/wiki/Portable_Bitmap PBM-Grafik] mit dem Text in 5 Zoom-Stufen. Eine einfache Beispiel-Implementierung.

;pc-vecfont-svg.c: Erstellt aus dem per Kommandozeile angegebenen Text eine [http://de.wikipedia.org/wiki/Scalable_Vector_Graphics SVG-Grafik] mit dem Text in 3 Zoom-Stufen. Eine wegen des SVG-Formats etwas kompliziertere Implementierung.

;avr-vecfont.c:
;avr-vecfont-callbacks.h: Implementiert den Vektor-Font für AVR, indem die Callbacks über Hook-Makros auf Inline-Funktionen abgebildet werden. Diese Implementierung zielt auf minimalen Flash-Verbrauch und kurze Laufzeit und verwendet daher eine Lookup-Tabelle von 'A'-'Z' zum schnellen Auffinden der Zeichen-Information. Die Zoom-Stufe ist im Makefile hartcodiert auf 2 eingestellt, um Rechnungen zur Laufzeit zu vermeiden. Software inklusive Zeichensatzinformation belegen weniger als 1kByte Speicher.

:Für eingehende Dokumentation und Verständnis ist ein Blick in die Quellen angesagt.

== Forum ==
* [http://www.mikrocontroller.net/topic/108649 Vektor-Font in C]

[[Kategorie:AVR-Projekte]]
[[Kategorie:PC-Programmierung]]
[[Kategorie:Displays und Anzeigen]]
[[Kategorie:Algorithmen und Arithmetik]]