Mikrocontroller.net - Benutzerbeiträge [de]

MSP430

2016-09-18T17:02:31Z

130.75.30.51: /* Links */

Der MSP430 ist ein 16 Bit-Mikrocontroller von Texas Instruments (TI). Er wurde speziell für eine geringe Stromaufnahme entwickelt, so dass er besonders für batteriebetriebene Geräte geeignet ist. Es gibt verschiedene Typen mit 1-256 kB [[Flash-ROM]], 128-18432 Byte [[RAM]], teilweise mit Hardware-Multiplizierer, [[UART]], [[AD-Wandler]] oder LCD-Treiber, die meisten im [[SMD]]-Package mit 20 bis >100 Pins. Einige neuere aus der MSP430F2xxx-Serie gibt es auch im DIP-Package (Bezeichnung: MSPxxxx '''-N'''). Der [http://www.mikrocontroller.net/part/MSP430F1121 MSP430F1121] zum Beispiel hat 4kB [[Flash-ROM]], 256B [[RAM]], 2 [[Timer]] und steckt in einem SO-20 Gehäuse.

== Entwicklungshardware ==

[[Datei:launchpad-lcd.jpg|thumb|right|250px|Das ''Launchpad'' (ca. 10€) enthält neben dem per USB ansprechbaren Programmer auch das "Spy bi Wire" Interface, mit dem der µC in der Schaltung emuliert werden kann (in Circuit emulation).]]

Für den schnellen Einstieg stellt TI mehrere Entwicklungssysteme mit USB Schnittstelle zur Verfügung. Beliebt ist, auf Grund des günstigen Preises, vor allem das [http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_%28MSP-EXP430G2%29 MSP430 Launchpad]. Es gibt jedoch noch andere wie z.B. das [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool].

Das Launchpad besitzt einen integrierten JTAG-Programmer, dessen Pins über Jumper herausgeführt sind. So kann man auch Controller direkt im Breadboard programmieren. Es können dadurch auch Controller programmiert werden, die nicht in den 20-Pin PDIP-Sockel passen, wie z.B. die MSP430F-Serie.

Weitere Adapterplatinen und [[JTAG]]-Programmer für MSP430-Controller bekommt man bei [http://olimex.com/dev/ Olimex (Bulgarien)], in Deutschland bei [http://elmicro.com/catalog/mcu/msp430/ Elektronikladen] oder [http://www.watterott.com/de/Boards-Kits/MSP430 Watterott].

Einen einfachen Schaltplan für den [[JTAG]]-Programmer von TI bzw. Olimex gibt es [[Media:MSP430-JTAG-programmer.pdf|hier]]. Die Spannungsversorgung kommt im Gegensatz zum Original allerdings nicht vom Drucker-Port sondern muss extern (am besten vom MSP430 Board) bereitgestellt werden.

Neben der JTAG-Programmierung bieten die MSP430-Controller auch die Möglichkeit, die Firmware über einen [[Bootloader]] einzuspielen. Die dafür erforderliche Hardware wird in der Application Note [http://focus.ti.com/docs/mcu/catalog/resources/appnoteabstract.jhtml?familyId=342&abstractName=slaa096d SLAA096d] von Texas Instruments beschrieben.

''Launchpad'' Bezugsquellen: [https://estore.ti.com/MSP-EXP430G2-MSP430-LaunchPad-Value-Line-Development-kit-P2031.aspx] [https://hbe-shop.de/ENTWICKLUNGSKIT-MSP430LAUNCHPAD-Typ-MSP-EXP430G2] [http://search.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=296-27570-ND] [http://www.watterott.com/de/MSP430-LaunchPad-MSP-EXP430G2] [https://www.ssl-id.de/b-redemann.de/catalog/product_info.php?products_id=151]

=== Stromversorgung ===

Der MSP430 benötigt meistens eine Spannung zwischen 1,8 und 3,6 V. Es gibt einige wenige Derivate, die mit 0.9V auskommen (z.B. MSP430L092). Einfach erzeugen kann man diese z. B. mit der folgenden Schaltung:

https://www.mikrocontroller.net/images/lm317.png

An den Eingang wird ein Steckernetzteil angeschlossen, die Ausgangsspannung lässt sich über das Potentiometer P1 einstellen.
Benutzt man für P1 einen 500Ω-Typ, kann man die Spannung in einem Bereich von 1,2 Volt und knapp 3,6 Volt einstellen. Dann kann man den MSP430 nicht durch zu hohe Versorgungsspannungen zerstören.

Für den Batteriebetrieb eines MSP430 gibt es von TI eine fertige Lösung mit wenig Peripherie: [http://focus.ti.com/docs/prod/folders/print/tps61221.html TPS61221]

Schaltung für 3,3V Versorgung: [http://focus.ti.com/lit/an/slva336/slva336.pdf]

Die neue Generation mit USB, MSP430F55xx, enthält bereits einen Längsregler von 5 V auf 3,3 V für den Betrieb an der USB-Speisespannung.
Die Minimalausstattung für die Erstinbetriebnahme ist ein Quarz (bspw. 12 MHz), ein Widerstand 1,5 kΩ und eine Drahtbrücke.

https://www-user.tu-chemnitz.de/~ygu/mb-iwp/Schrittmotorsteuerung/MSP430V1.jpg

== Programmieren und Debuggen ==
Zum Füllen des internen Flash-Programmspeichers und zum Verfolgen des Programmablaufs stehen üblicherweise drei Schnittstellen zur Verfügung:

* Der Bootloader (seriell oder USB)
* Das JTAG-Interface
* Der Spy-bi-Wire-Anschluss

=== Bootloader (Seriell oder USB) ===
Wer fehlerarm programmieren kann und für jedwede Hilfsadapter zu geizig ist, benutzt am besten den eingebauten Bootloader. Dies ist auch der günstigste Weg bei der Serienfertigung.

Zur Nutzung des seriellen Bootloaders ist es am günstigsten, [http://www.tu-chemnitz.de/~heha/iwp/Piezomess/Seriell wenn die fertige Schaltung sowieso eine serielle Schnittstelle vorsieht]. Ungünstigerweise „hört“ der Bootloader nicht auf RxD und TxD, sondern zumeist auf P1.1 und P2.2 (siehe jeweiliges Datenblatt!). Daher behilft man sich mit festen oder trennbaren Brücken zwischen P1.1 und TxD sowie P2.2 und RxD.
Von den SubD-Pins 1+4+6 geht man via Serienwiderstand bspw. 33 kΩ auf /RESET,
von den SubD-Pins 7+8 ebenso via 33 kΩ auf TCK, fertig ist der On-Board-Programmieradapter.

Richtig debuggen kann man mit der seriellen Schnittstelle nicht.

MSP430 mit USB-Schnittstelle haben ''keinen'' seriellen Bootloader. Dieser ist durch den USB-Bootloader ersetzt worden. Zu seiner Verwendung werden keine ominösen Brücken verwendet; der USB-Anschluss (den wohl jede Anwendungsschaltung mit MSP430F55xx haben wird) ist sofort zum Herunterladen der Firmware geeignet. Clevererweise meldet sich der Bootloader als HID-Gerät, das erspart den Treiber (genau genommen gibt es extra für Firmware-Updates eine eigene USB-Geräteklasse). Zum Füllen des Flash steht von Texas Instruments eine Software mit Quelltext zur Verfügung. Leider ist die API der DLL wenig brauchbar, und das Programm schluckt keine .HEX-Dateien (wie sonst üblich), sondern TI-spezifische .TXT-Dateien. Eine alternative Software für Windows gibt es [http://www-user.tu-chemnitz.de/~heha/hs_freeware/msp430-usbbsl.zip von Henrik Haftmann].

=== JTAG ===
Komfortabel und dennoch preisgünstig ist der JTAG-Anschluss. Leider benötigt dieser mindestens 5 Kontakte und damit Platz auf der Schaltung. Anschluss-Adapter für den Parallelport sind leicht zu bekommen und beinhalten im einfachsten Fall nur Schutzwiderstände. Wer keinen Parallelport hat, benötigt teurere aber komfortable USB-JTAG-Adapter.

=== Spy-Bi-Wire ===
Die TI-Erfindung Spy-Bi-Wire kommt mit nur 2 Leitungen aus. Hier sind nur spezielle USB-Adapter bekannt, die vom Hersteller zu beziehen und closed-source sind. Auf TI-Entwicklungsplatinen ist dieser Umsetzer bereits als ein weiterer Chip aufgelötet. Eine Liste möglicher Adapter ist z.B. [[http://de.wikipedia.org/wiki/Msp430#Liste_der_FETs.2C_sehr_unvollst.C3.A4ndig hier]] einsehbar.
Die verfügbaren Adapter variieren teils sehr stark in ihrem Preis aber auch in ihrer Leistungsfähigkeit.

Die kostengünstigste Lösung ist es, ein MSP430 Launchpad als USB-Programmieradapter zu verwenden. Das Launchpad ist ein kleines Entwicklungsboard von TI und kann bei Farnell bereits für unter 10 Euro bezogen werden. Die Spy-Bi-Wire Anschlüsse (RST & TEST) können einfach an J2, J3 oder J4 abgenommen und an den zu programmierenden MSP430 angeschlossen werden. Zu beachten ist nur, das man den auf dem Board eingesetzten MSP430 heraus nimmt. Siehe [http://www.ti.com/lit/ug/slau318d/slau318d.pdf Launchpad Userguide/SLAU318]

Ein genereller Nachteil bei Spy-Bi-Wire ist die zum Teil erheblich reduzierte Geschwindigkeit bei der Datenübertragung. Dies liegt v.a. daran, dass die Daten, die vorher bei JTAG über 3 Leitungen übertragen wurden (TMS, TDI, TDO) nun über eine gemeinsame bidirektionale Leitung laufen. Es gibt jedoch auch Tools die diesen Nachteil weitestgehend ausgleichen können.

Es bleibt daher zu überlegen, ob es nicht sinnvoll ist, lieber einen Chip in einem etwas größeren Gehäuse mit mehr Pins zu verwenden und dafür JTAG zu nutzen. v.a. in Sachen Selbstbaudebugger ist dies sinnvoll.

== Dokumentation ==

* TI's Website: http://www.msp430.com
*:Für jede MSP430 Familie (z. B. MSP430F1xxx) gibt es ein generelles "datasheet" und einen detailierten "user guide". Die im user guide verwendeten Registerbezeichnungen (Ports, SFRs, etc.) findet man auch bei den meisten Compilern wieder.

* Buch: Mikrocontrollertechnik Am Beispiel der MSP430-Familie
*:Dieses Lehrbuch führt in die Grundlagen der Mikrorechentechnik ein. Es beschreibt sehr detailliert den Aufbau, die Funktion und die Handhabung von Mikrocontrollern am Beispiel des MSP430F1232. Programmbeispiele sind in Assembler und C enthalten. Ideal für Einsteiger mit geringen technischen Vorkenntnissen. Autor: Matthias Sturm ISBN 3-446-21800-9, Hanser Verlag

* Buch: [http://www.medit.hia.rwth-aachen.de/aw/cms/medit/Themen/publikationen/buecher/~tic/msp430/?lang=de Das MSP430 Mikrocontroller Buch]
*: ... sagt u.a.: "Dieses Buch eröffnet einen schrittweisen Einstieg in die Welt der Mikrocontrollerprogrammierung und führt mit ausführlichen Anwendungsbeispielen in die Fähigkeiten dieser außergewöhnlichen Prozessorfamilie ein. Jede Komponente des Prozessors wird ausführlich erklärt und deren Funktion in kleinen Beispielprogrammen gleich umgesetzt. Abgerundet wird jedes Kapitel mit einigen Übungsaufgaben. So entsteht neben dem eigentlichen Lerneffekt gleichzeitig eine Referenzbibliothek von Funktionsmodulen, die später in eigenen Anwendungen leicht weiterverwendet werden können."
*: Autoren: Marian Walter und Stefan Tappertzhofen; ISBN 978-3-89576-236-9, Elektor Verlag

* Egel project page website: http://noforth.bitbucket.org/site/egel%20for%20launchpad.html
*: This page takes you by the hand in learning how the MSP430 hardware works. It does try to help you understand how the TI-documention works. Loads of examples from simple I/O to I2C and use of the low power modes. Finally some apllication examples like building your own cloning BSL or walking biped robot.

== Software ==

=== TI Code Composer Studio ===
Die Eclipse-basierte Entwicklungsumgebung von TI ist für Linux und Windows verfügbar. Enthalten sind sowohl eine auf 16 kB Codegröße beschränkte Version des TI-eigenen Compilers, als auch ein GCC-basierter Compiler ohne Codegrößenbeschränkung.

* [http://www.ti.com/tool/ccstudio-msp430 Produktseite]

===MSPGCC===

Mittlerweile (Stand 2014) gibt es von TI selbst einen neuen GCC-basierten Compiler für MSP430, welcher komplett neu entwickelt wurde [http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg11305.html], und in das Code Composer Studio seit Version 6 integriert ist.
* [http://www.ti.com/tool/msp430-gcc-opensource GCC - Open Source Compiler for MSP430 Microcontrollers]

Die folgenden Informationen beziehen sich auf ältere, nicht von TI unterstütze GCC-Versionen, und sind möglicherweise veraltet:
* Direkt mit Eclipse 3.6 Helios compilieren und debuggen [[MSP430_eclipse_helios_mspgcc4_gdb-proxy|Anleitung]] (06/2010)
* [http://msp430.ms.funpic.de/doku.php?id=msp430:entwicklungumgebung Eclipse+mspgcc+GDB-Proxy] (03/2009)
* [http://www.mikrocontroller.net/articles/Eclipse_und_MSPGCC_unter_Windows Eclipse und MSPGCC unter Windows] (03/2009)
* [http://matthias-hartmann.blogspot.com/ Use Eclipse and mspgcc - the easy way] (Windows 02/2009).
* [http://www.mikrocontroller.net/Eclipse%20und%20MSPGCC/ Eclipse und MSPGCC] (Windows 03/2006)
* [http://kurt.on.ufanet.ru/ MSPFET - FREE MSP430 flash programming utility] (Windows)
* [http://xgoat.com/wp/2009/03/25/fetproxy-an-open-source-replacement-for-msp430-gdbproxy/ FetProxy - Ein funktionierender Open-Source-Ersatz für msp430-gdbproxy] (Unix, Linux)
* [http://osx-launchpad.blogspot.com/ - Komplettpaket für Mac OS X](11/2011)

===Energia===
Diese auf der Arduino IDE basierende Entwicklungsumgebung bietet die gleiche Nutzererfahrung für MSP430-Boards, die von der Entwicklung für Arduino-Boards bekannt ist. Es werden fortlaufend Verbesserungen vorgenommen.

* [http://energia.nu/ Energia-Webseite]

===MSPDebug===
MSPDebug ist ein Programmier/- Debugwerkzeug für den [[MSP430]], ähnlich wie avrdude für die [[AVR]]s. Es beinhaltet auch einen gdb-server um in eclipse oder direkt mit msp430-gdb zu debuggen.

Momentan (0.21) unterstütze Programmer/Debugger (aus der Hilfe übernommen):
* ez430-RF2500 z.B. der Programmieradapter von der ez430-Chronos
* Olimex MSP-JTAG-TINY / ISO
* Launchpad
* GoodFET
* TI FET430UIF und Kompatible (z.B. eZ430)
* TI FET430UIF bootloader
* Flash Bootloader

Er läuft unter Linux, *BSD, OS/X und Windows.

Weblinks:
* [http://mspdebug.sourceforge.net/ Projekthomepage bei Sourceforge]
* [http://aur.archlinux.org/packages.php?ID=37648 AUR-Paket für Arch Linux]
* [http://packages.debian.org/search?suite=all&searchon=names&keywords=mspdebug Pakete für Debian Linux]

===MSP430 Instruction Set Simulator===

Die Firma Lauterbach bietet unter der Artikelnummer LA-8815 einen Instruction Set Simulator für den MSP430 an. Die Demoversion ist zur Evaluierung kostenlos. Einschränkungen bestehen in der Anzahl der zu ladenen Debugsymbole, was jedoch für die meisten (teils auch kleineren) Hobbyanwendungen kein Problem darstellen sollte.
Der Simulator unterstützt alle gängigen MSP430 Derivate, d.h. beide Instruction Sets (16bit/20bit CPUs).
Der Simulator lädt alle gängigen Debugformate, wie die des IAR Compilers, des Code Composer Studios von TI oder des freien Tools MSPGCC.

Zum Simulator gäbe es entsprechende zugehörige Debugtools für den MSP430, die käuflich zu erwerben sind.

[[Datei:msp430_sim_la8815.jpg|thumb|130px| MSP430 Simulator]]

Der Screenshot zeigt ein Beispiel mit Quellcode (HLL/ASM mixed), Register/Stack Fenster, Breakpoint-Konfiguration, Variablenansicht, Stackframe und Darstellung des anfänglichen RAM Inhalts.

* Weblinks:
** [http://www.lauterbach.com/frames.html?dwnload.html Downloadarea mit MSP430 Simulator]

===MSP430 Forth===

'''Mecrisp''' ist eine Forth-Implementation, die direkt im Microcontroller läuft und über eine serielle Schnittstelle angesprochen wird. Momentan werden die Chips MSP430F2274 und MSP430G2553 unterstützt.

Weblinks:
* [http://mecrisp.sourceforge.net/ Projekthomepage bei Sourceforge]
* [http://forth-ev.de/article.php/20120219114103966 mecrisp - nativ forth für MSP430] auf forth-ev.de

'''CamelForth/430''' ist ein ANSI Standard Forth für die Texas Instruments MSP430 Mikrocontroller-Familie. CamelForth sollte mit jedem MSP430, der wenigstens 512B RAM, 8K ROM und einen USART hat, funktionieren.

Weblinks:
* [http://www.camelforth.com/page.php?8 CamelForth/430]
* [http://forth-ev.de/article.php/20120101180840139 CF430FR - CamelForth für TI MSP430FR5739] auf forth-ev.de

'''4E4th''' ist kleines Forth das auf dem Texas Instruments LaunchPad läuft. Es steckt in der MCU MSP430G2553. Du kommunizierst mit dem 4E4th mit Hilfe eines Zeilen Editors der über einen Terminal Emulator betrieben wird. 4E4th basiert auf der MSP430 CamelForth version 0.3 von B. J. Rodriguez, welches er für das TI Tini430 board mit dem MSP430F1611 geschrieben hatte. Es ist ein ANS Forth, und belegt knapp 8K im FLASH der MSP430G2553 MCU (0xE000-0xFFFF). Weitere 8K (0xC000-0xDFFF) sind frei für eigene Experimente. 4E4th ist, wie das CamelForth auch, freie Software (GNU General Public License).

Weblinks:
* [http://forth-ev.de/index.php?topic=launchpad 4E4th auf dem LaunchPad] auf forth-ev.de
* [http://www.forth-ev.de/wiki/doku.php/projects:4e4th:start 4e4th im forth-ev.de Wiki]

[[Datei:noforth.jpg|mini|zentriert|150px|]]

'''noForth''' Is an interactive 16-bit stand-alone forth for MSP430.
Authors: Albert Nijhof & Willem Ouwerkerk.

Last update 22 april 2016: We made noForth still more robust and we made some space saving internal changes, the kernel takes less space and compiling a program is even more space efficient now. This is nice especially for the smaller 16kB processors.

noForth C,V comes in two basic variants:
* noForth C, Compact, for the smaller 16kB flash processors.
* noForth V, with Vocabularies, for larger flash memories.

New:
* Low Power noForth for MSP430G2553 boards. In Low Power noForth all 'wait-loops' are replaced with 'sleep-until-interrupted' which relatively saves a lot of energy. Low power noForth is marked with a dash: noForth C- and noForth V-.
* noForth for msp-exp430fr5969 experimenter board
* noForth for MSP430G2553 egel kit

[[Datei:egeltje1.jpg|thumb|130px|Egel]]

Weblinks:
* [http://home.hccnet.nl/anij/nof/noforth.html noForth homepage, binary's and sources]
* [http://noforth.bitbucket.org/site/egel%20for%20launchpad.html Egel project for MSP430]

=== Weitere Kommerzielle Compiler für MSP430 ===
* [http://www.imagecraft.com/devtools_MSP430.html ICC430] (45-Tage Demo; wird nach Ablauf auf 4 kByte Codegröße beschränkt)
* [http://www.rowley.co.uk/msp430/index.htm CrossWorks for MSP430] (30-Tage-Testversion nach Registrierung)
* [http://www.quadravox.com/AQ430.htm Quadravox AQ430]
* [http://www.iar.com/Products/IAR-Embedded-Workbench/TI-MSP430/ IAR Embedded Workbench for MSP430] (30-Tage-Testversion; Freie auf 4 kByte (MSP430) oder 8 kByte (MSP430X) Codegröße beschränkte "KickStart"-Edition)

== Beispielanwendungen ==

* Mathar.Com: Auf http://www.mathar.com gibt es ein paar Beispiele (in C), was man so alles mit dem MSP430 anstellen kann. Dort hat der Autor einige Anwendungen näher erläutert. Angefangen mit simplen Aufgaben wie LEDs leuchten lassen geht es weiter über eine LCD- und GLCD-Ansteuerung (HD44780- und KS0108-kompatibel) sowie einigen Beispielen zur Verwendung des integrierten A/D-Wandlers, des USARTs, des Timers und vielem mehr ... Als weitere Codebeispiele sind dort auch eine I2C-Softwareimplementation und eine CAN-Library für den MSP430 zu finden.
* Examples Ordner der freien Toolchain MSPGCC: Der "examples"-Ordner bzw. "checkout" aus dem CVS vom [[MSPGCC]] ist auch sehr umfangreich: http://mspgcc.cvs.sourceforge.net/mspgcc/examples/
* Codebeispiele auf Mikrokontroller.net: Einige [[MSP430 Codebeispiele]] finden sich auch hier in der Artikelsammlung.
* uIP Port auf Mikrokontroller.net: Der Port des TCP/IP Stacks von Adam Dunkels [[MSP430_uIP_Port|uIP 1.0 für den MSP430 findet sich hier]].
* Launchpad interne Temp. Messung mit ADC und Anzeige auf LCD: C Codebeispiel für Launchpad mit IAR Kickstartcompiler, interner ADc und LCD Ansteuerung. Vergleich Atmel 8 Bit AVR Controller und mit MSP Familie: [http://www.mikrocontroller.net/topic/222015#new]

== Links ==

* [http://www.mikrocontroller.net/forum/1/msp430 Beiträge zum MSP430 im Mikrocontroller.net Forum]
* [http://mspgcc.sourceforge.net/manual/c68.html An introduction to the TI MSP430 low-power microcontrollers]
* [http://tinymicros.com/embedded/MSP430/ The MSP430 Bugspray Database] - umfangreiche Datenbank für Bugs in MSP430-Controllern
* [http://www.mathar.com www.mathar.com] - Tutorial für Einsteiger und Fortgeschrittene: LCD, ADC, USART, I2C, CAN Programmierung in C
* [http://cnx.org/lenses/TexasInstruments/MSP430 Connexions - Texas Instruments MSP430] Tutorial (speziell für eZ430)
* [http://msp430.info MSP430.info] - Portalseite für MSP430; Info, Projekte, Paper, Entwicklungstools...
* [http://groups.yahoo.com/group/msp430 Yahoo group MSP430] - lebhaftes Forum mit vielen MSP430-Experten
* [http://www.thomas-wedemeyer.de/elektronik/msp430/msp430.html Thomas Wedemeyer's MSP430-Seiten] - Kleine Beispiel Applikationen und Tips zur Nutzung von MSPGCC mit der Dev-C++ Entwicklungsumgebung
* [http://homepage.hispeed.ch/py430/mspgcc/ msp430-gdb und Eclipse] - Eine Anleitung von Chris Liechti
* [http://passworld.co.jp/index.php?lang=GB&lieu=GPS MSP430 GPS] - [http://passworld.co.jp/index.php?lang=GB&lieu=Oximeter MSP430 Puls-Oximeter]
* [http://passworld.co.jp/ForumMSP430 MSP430 Forum]
* [http://develissimo.net/de/msp430entwicklung.html MSPGCC + Eclipse + msp430-gdbproxy / Linux / Debian / Ubuntu] - Anleitung / Tutorial zur Installation der MSPGCC Toolchain + Eclipse + msp430-gdbproxy für Linux / Debian / Ubuntu Lang=Deutsch und Englisch leider geht der link nicht mehr
* [http://www.sinelabore.com SinelaboreRT] - Generierung von Zustandsmaschinen in C speziell für kleine Low-Power Plattformen.
* [http://www.state-machine.com/msp430/ QP Framework for MSP430] - state machine Laufzeitumgebung ([http://www.state-machine.com/licensing/index.php dual licensed commercial/GPL2])
* [http://msp430.funpic.de msp430.funpic.de] - Wiki zum MSP430
* [http://mspsci.blogspot.com/2010/07/tutorial-01-getting-started.html Scientific Instruments Using the TI MSP430] - Tutorial speziell zum TI Launchpad.
* [http://43oh.com/ Four-Three-Oh!] - MSP430 News und Forum (en)
* [http://www.youtube.com/watch?v=9zfIatWxkG8&feature=relmfu Beispielvideo] - by JL (God of Mathfire)
* [http://opencores.org/project,openmsp430 openMSP430] - MSP430 als Softcore im FPGA (Verilog)
* [http://opencores.org/project,NEO430 NEO430] - sehr kleines MSP430-kompatibles SoC als Softcore im FPGA (VHDL)

== Bezugsquellen ==
=== Evaluation Boards ===
* [http://www.mikrocontroller.net/link/reichelt/msp430 reichelt.de]
* [http://thinkembedded.ch/MSP430:::10.html thinkembedded.ch]
* [http://www.sander-electronic.de/es0015.html sander-electronic]
* [http://ch.farnell.com/texas-instruments/ez430-rf2500/board-kit-fuer-msp430/dp/1382267 farnell.com]
* [http://www.ti.com/tool/msp-exp430g2 TI.com - Als Student mit Hochschulmailadresse für 10$ Versandkostenfrei]
* [https://www.ssl-id.de/b-redemann.de/catalog/product_info.php?cPath=51&products_id=205 b-redemann.de]
* [https://www.tindie.com/stores/Willem_O/ MSP430-EXP430G alternatives and expansion boards/kits.]

[[Kategorie:Mikrocontroller]]
[[Kategorie:MSP430| ]]

Diskussion:Soft-PWM

2016-01-13T13:59:16Z

130.75.30.51: /* Noch schnellere Implementierung ohne Compare Register */ Code-Formatierung gefixt

Vielleicht wärs nicht schlecht auch noch drauf hinzuweise, dass man duch ein einfaches bit-reverse die Schaltfrequenz auf die Timer-Zykluszeit hochbringen kann... Damit ist dann das obligatorische Filtern viel einfacher...

Ich hab leider keinen passenden Link gefunden der das illustriert aber mann man ja recht einfach nachprüfen...

Den Zählerwert mit dieser Tabelle
<c>
static const unsigned char BitReverseTable256[] =
{
0x00, 0x80, 0x40, 0xC0, 0x20, 0xA0, 0x60, 0xE0, 0x10, 0x90, 0x50, 0xD0, 0x30, 0xB0, 0x70, 0xF0,
0x08, 0x88, 0x48, 0xC8, 0x28, 0xA8, 0x68, 0xE8, 0x18, 0x98, 0x58, 0xD8, 0x38, 0xB8, 0x78, 0xF8,
0x04, 0x84, 0x44, 0xC4, 0x24, 0xA4, 0x64, 0xE4, 0x14, 0x94, 0x54, 0xD4, 0x34, 0xB4, 0x74, 0xF4,
0x0C, 0x8C, 0x4C, 0xCC, 0x2C, 0xAC, 0x6C, 0xEC, 0x1C, 0x9C, 0x5C, 0xDC, 0x3C, 0xBC, 0x7C, 0xFC,
0x02, 0x82, 0x42, 0xC2, 0x22, 0xA2, 0x62, 0xE2, 0x12, 0x92, 0x52, 0xD2, 0x32, 0xB2, 0x72, 0xF2,
0x0A, 0x8A, 0x4A, 0xCA, 0x2A, 0xAA, 0x6A, 0xEA, 0x1A, 0x9A, 0x5A, 0xDA, 0x3A, 0xBA, 0x7A, 0xFA,
0x06, 0x86, 0x46, 0xC6, 0x26, 0xA6, 0x66, 0xE6, 0x16, 0x96, 0x56, 0xD6, 0x36, 0xB6, 0x76, 0xF6,
0x0E, 0x8E, 0x4E, 0xCE, 0x2E, 0xAE, 0x6E, 0xEE, 0x1E, 0x9E, 0x5E, 0xDE, 0x3E, 0xBE, 0x7E, 0xFE,
0x01, 0x81, 0x41, 0xC1, 0x21, 0xA1, 0x61, 0xE1, 0x11, 0x91, 0x51, 0xD1, 0x31, 0xB1, 0x71, 0xF1,
0x09, 0x89, 0x49, 0xC9, 0x29, 0xA9, 0x69, 0xE9, 0x19, 0x99, 0x59, 0xD9, 0x39, 0xB9, 0x79, 0xF9,
0x05, 0x85, 0x45, 0xC5, 0x25, 0xA5, 0x65, 0xE5, 0x15, 0x95, 0x55, 0xD5, 0x35, 0xB5, 0x75, 0xF5,
0x0D, 0x8D, 0x4D, 0xCD, 0x2D, 0xAD, 0x6D, 0xED, 0x1D, 0x9D, 0x5D, 0xDD, 0x3D, 0xBD, 0x7D, 0xFD,
0x03, 0x83, 0x43, 0xC3, 0x23, 0xA3, 0x63, 0xE3, 0x13, 0x93, 0x53, 0xD3, 0x33, 0xB3, 0x73, 0xF3,
0x0B, 0x8B, 0x4B, 0xCB, 0x2B, 0xAB, 0x6B, 0xEB, 0x1B, 0x9B, 0x5B, 0xDB, 0x3B, 0xBB, 0x7B, 0xFB,
0x07, 0x87, 0x47, 0xC7, 0x27, 0xA7, 0x67, 0xE7, 0x17, 0x97, 0x57, 0xD7, 0x37, 0xB7, 0x77, 0xF7,
0x0F, 0x8F, 0x4F, 0xCF, 0x2F, 0xAF, 0x6F, 0xEF, 0x1F, 0x9F, 0x5F, 0xDF, 0x3F, 0xBF, 0x7F, 0xFF
};
</c>

und dann vergleicht man eigentlich BitReverseTable256[ZÄHLERWERT] mit dem eingestellten PWM-Wert...

Wenn man jetzt z.b 50% dutycycle betrachtet erkennt man schon ganz deutlich die Verbesserung:
bei jedem Vergleich wird getoggelt!

Warum kein einziger Controller den ich kenne sowas macht versteh ich nicht...

Derzeit bastle ich an einer einfachen Motorsteuerung und da wird eben ein DC-Motor per PWM vergewaltigt.
Software-PWM deshalb weil ich den Timer sowieso zur Zeitmessung verwende..
Mit dieser Methode hab' ich jetzt eine Schaltfrequenz am Motor von 14kHz :)

73

----

>Vielleicht wärs nicht schlecht auch noch drauf hinzuweise, dass man duch ein >einfaches bit-reverse die Schaltfrequenz auf die Timer-Zykluszeit hochbringen >kann... Damit ist dann das obligatorische Filtern viel einfacher...

Das nennt sich Puls-DICHTE-Modulation

>Wenn man jetzt z.b 50% dutycycle betrachtet erkennt man schon ganz deutlich die >Verbesserung:
>bei jedem Vergleich wird getoggelt!

Fast.

>Warum kein einziger Controller den ich kenne sowas macht versteh ich nicht...

Für PWM/PDM zur Erzeugung von Referenzspannungen für ADC, whatever ist das ganz nützlich. Aber . . .

>Derzeit bastle ich an einer einfachen Motorsteuerung und da wird eben ein >DC-Motor per PWM vergewaltigt.
>Software-PWM deshalb weil ich den Timer sowieso zur Zeitmessung verwende..
>Mit dieser Methode hab' ich jetzt eine Schaltfrequenz am Motor von 14kHz :)

Eben für Leistungsendstufen ist das quasi unbrauchbar, weil dann die Schaltverluste zu hoch werden, weil zu oft geschaltet wird.

MFG
Falk

----

Die Schaltverluste sollten eigentlich mit guten FETs und relativ wenig Strom nicht gravierend sein...

Das einzige was bäse ist beim schnellen Schalten ist das EMV-Problem...

Auf jedenfall rennt bei mir der Motor so sauberer... also viel konstanteres Moment.
Vor allem wenn er langsam über eine Rampe hochläuft merkt man das...

73
--[[Benutzer:Hans|Hans]] 16:58, 10. Jan. 2008 (CET)
----
[http://www.mikrocontroller.net/attachment/18048/binratemultiplier.png Binratemultiplier]
Ich glaube da wird auch irgendwie Bitreverse gemacht, das höchstwertige Bit liegt an der niederwertigsten Stelle an
73 de DB1UQ

== Intelligenter Lösungsansatz auf Atmega128 ==

Guten Tag,

ich finde es wirklich toll, daß sich jemand mal den Kopf zerbricht und so eine leistungsstarke Software PWM programmiert. Nur wurde diese Software mal auf anderen µC getestet als dem Atmega32? Ich habe es jetzt auf einem 128er und nem 64er Versucht. Bei beiden zerbröselt es einem die PWM, wenn man die Kanäle mit bestimmten Werten fütter, wie z.B. 200,0,100,30,0 usw. Da kommt dann nichts sinnvolles mehr raus. Ist die Frage ob das eine Einstellungssache für die anderen µC ist, oder ein genereller Softwarefehler. Habe leider gerade keinen 32er zur Hand, sonst würde ich das mal selber testen.

== Noch schnellere Implementierung ohne Compare Register ==
Hallo,

ich habe teils mit Hilfestellung dieses Artikels ein PWM für einen Timer ohne Compare Register implementiert. Das PWM wurde Trailing Edge implementiert. Ein Compare-Register habe ich bei dem verwendeten Timer schlichtweg nicht zur Verfügung. Ebenso verwende ich keine Multiplikationen und Divisionen, da ATtinys diese nicht vernünftiger Zeit berechnen.

Der ISR-Aufruf braucht bei mir nur 25-28 Taktzyklen (-75%). Die update-Funktion benötigt zwischen 34 (1 Kanal) und 1300 (max. 8 Kanäle) Taktzyklen (-28%). Insgesamt ist der Code mit 562 Bytes auch kompakter (-42%).

Mein Controller läuft dabei mit 8 MHz und generiert mit einem 8-Bit Timer eine 8-Bit PWM mit einer Frequenz von 122 Hz auf einem Port (8 Kanäle). Zu Testzwecken fade ich die LEDs im main-Loop.

Ich habe auch noch eine den Code für einen zusätzlichen Port integriert, aber der skaliert in der update-Funktion sehr schlecht und müsste daher ggf. überarbeitet werden.

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 8-Bit Trailing Edge Soft PWM for AVR2 Architecture *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This Soft-PWM implementation uses one 8 bit timer without the need of a *
* compare mode. It controls up to 8 channels on one port or 16 channels on *
* two ports and can easily be extended to more output ports. */

#define F_CPU 8000000 // 8 MHz

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <avr/pgmspace.h>

/* PWM Timer Settings *
* timer = timer1; mode = 8 bit normal; clock = clk/256 (31.25kHz); *
* overflow interrupt enabled (approx. 122/s) */
#define PWM_TIMER_OVF_vect TIMER1_OVF_vect
#define PWM_TCNT TCNT1
#define PWM_TIMER_SETUP { TCCR1A = 0; \
TCCR1B = 1<<CS13 | 1<<CS10 | 1<<PSR1; \
TIMSK |= 1<<TOIE1; }
/* PWM Output Port Settings *
* The first `PWM_CHANNEL_COUNT` lines of `PWM_PORT` are used. */
#define PWM_PORT PORTA
#define PWM_DDR DDRA
#define PWM_CHANNEL_COUNT 8
//#define PWM_TWO_PORTS // use a second PWM port
#define PWM_PORT_2 PORTB
#define PWM_DDR_2 PORTB
#define PWM_CHANNEL_COUNT_2 8

#define PWM_FULL_CHANNEL_COUNT PWM_CHANNEL_COUNT
#ifdef PWM_TWO_PORTS
#define PWM_FULL_CHANNEL_COUNT ( PWM_CHANNEL_COUNT + PWM_CHANNEL_COUNT_2 )
#endif

typedef struct {
uint8_t mask; // port mask
#ifdef PWM_TWO_PORTS
uint8_t mask_2;
#endif
uint8_t value; // delay or pulse width
} PWM_Slot;

// PWM timer value vector
// two vectors and pointers for seamless reconfiguration
PWM_Slot pwm_slots_a[ PWM_FULL_CHANNEL_COUNT + 1 ];
PWM_Slot pwm_slots_b[ PWM_FULL_CHANNEL_COUNT + 1 ];
PWM_Slot *pwm_slots_isr = pwm_slots_a;
PWM_Slot *pwm_slots_config = pwm_slots_b;

volatile uint8_t pwm_current_isr_slot;

ISR( PWM_TIMER_OVF_vect )
{/* This is the interrupt routine for the PWM timer overflow. It generates *
* trailing edge Soft PWM. All channels are set to zero at the start of a *
* cycle. The `value` property of a pwm_slots_isr item contains the timer *
* start value for delaying the next slot. The `mask` property holds the *
* port mask. *
* Size optimized code executes this function in the following ammount of *
* clock cycles (port mask change)/(restart): 28/25 for a single port and *
* 58/57 for two ports. 2-3 additional clock cycles per port could be saved *
* by assigning the whole port to mask resp. 0 and precalculating the full *
* mask. That way all other output lines would be assigned as well! */
uint8_t local_number = pwm_current_isr_slot;
PWM_Slot current_slot = pwm_slots_isr[local_number];
PWM_TCNT = current_slot.value;
if( current_slot.mask ){
PWM_PORT |= current_slot.mask;
#ifdef PWM_TWO_PORTS
PWM_PORT_2 |= current_slot.mask_2;
#endif
pwm_current_isr_slot = local_number + 1;
}
else {
PWM_PORT &= 0xFF<<PWM_CHANNEL_COUNT;
#ifdef PWM_TWO_PORTS
PWM_PORT_2 &= 0xFF<<PWM_CHANNEL_COUNT_2;
#endif
pwm_current_isr_slot = 0;
}
}

void update_pwm( void )
{/* This function replaces the PWM ISR parameters at the start of a PWM *
* cycle. */
PWM_Slot *pwm_slots_ptr = pwm_slots_isr;

// wait for pwm_current_isr_slot to switch to zero
if(pwm_slots_isr[0].mask)
while(pwm_current_isr_slot == 0)
{}
while(pwm_current_isr_slot)
{}

// shift pwm_slots_isr pointer;
cli();
pwm_slots_isr = pwm_slots_config;
sei();
pwm_slots_config = pwm_slots_ptr;
}

void set_pwm( PWM_Slot *channel )
{/* This function writes propper PWM isr parameters into pwm_slots_config. *
* For a single port it scales with a about 160 clock cycles per channel. *
* For two ports it scales worse (maybe 500 clock cycles per channel). IT *
* should be possible to improove this by using some pointer arithmetic and *
* a smarter sorting alogrithm in that case. */
uint8_t pwmslots = PWM_FULL_CHANNEL_COUNT;

// sort channels from max to min PWM width
for( uint8_t i = 0; i < pwmslots; i++ ){
// search channel of maximal value
uint8_t max_channel = i;
uint8_t max_value = channel[i].value;
for( uint8_t j = i; j < pwmslots; j++ ){
if( max_value < channel[j].value){
max_value = channel[j].value;
max_channel = j;
}
}
// Merge channels if value is equal to previous.
if( i && ( max_value == channel[ i - 1 ].value )){
pwmslots--;
channel[i - 1].mask |= channel[max_channel].mask;
#ifdef PWM_TWO_PORTS
channel[i - 1].mask_2 |= channel[max_channel].mask_2;
#endif
channel[max_channel] = channel[pwmslots];
i--;
}
// Else move channel of maximal value to index `i`.
else if( max_channel != i ){
PWM_Slot tmp = channel[max_channel];
channel[max_channel] = channel[i];
channel[i] = tmp;
}
}
// skip channels with a PWM width of zero
if( channel[ pwmslots - 1 ].value == 0)
pwmslots--;

// write values into pwm_slots_config
// pwm_slot[pwmslots] is black time before first/longest slot
pwm_slots_config[pwmslots].mask = 0;
#ifdef PWM_TWO_PORTS
pwm_slots_config[pwmslots].mask_2 = 0;
#endif
pwm_slots_config[pwmslots].value = channel[0].value;
uint8_t following = 0;
for(uint8_t i = pwmslots; i;){
i--;
// pwm_slot[n].mask: port mask for the n^th PWM width
pwm_slots_config[i].mask = channel[i].mask;
#ifdef PWM_TWO_PORTS
pwm_slots_config[i].mask_2 = channel[i].mask_2;
#endif
// pwm_slot[n].value: delay between n^th and n+1^st up-flank
pwm_slots_config[i].value = following - channel[i].value;
following = channel[i].value;
}
}

void initialize_pwm( void )
{/* This function initialized the Soft-PWM. */
// set data direction register for PWM port
PWM_DDR |= ~( 0xFF<<PWM_CHANNEL_COUNT );
#ifdef PWM_TWO_PORTS
PWM_DDR_2 |= ~( 0xFF<<PWM_CHANNEL_COUNT_2 );
#endif
// setup timer and activate overflow interrupt
PWM_TIMER_SETUP

// initialize PWM timer value vector
pwm_slots_a[0].mask = 0;
#ifdef PWM_TWO_PORTS
pwm_slots_a[0].mask_2 = 0;
#endif
pwm_slots_a[0].value = -1;
}

int main( void )
{ /* Main program function */
uint8_t val; // fading counter
initialize_pwm();

while(1){
// fade over the PWM channels
PWM_Slot channel[PWM_FULL_CHANNEL_COUNT];
for( uint8_t i=0; i < PWM_FULL_CHANNEL_COUNT; i++ ){
#ifdef PWM_TWO_PORTS
if( i < PWM_CHANNEL_COUNT){
channel[i].mask = 1<<i;
channel[i].mask_2 = 0;
}
else{
channel[i].mask = 0;
channel[i].mask_2 = 1<<(i - PWM_CHANNEL_COUNT);
}
#else
channel[i].mask = 1<<i;
#endif
// shift phase each channel
channel[i].value = val + i * ((1<<8) / PWM_FULL_CHANNEL_COUNT - 1);
// fade up-down (0, .., 127, 127, .., 0)
if( channel[i].value & 1<<7 )
channel[i].value = 255 - channel[i].value;
}
set_pwm(channel);
update_pwm();

// increase fading counter (0, 1, .., 255, 0, ..)
val++;
_delay_ms(10);
}
}

== Fußnoten ==
<references/>

AVR-Tutorial: Schieberegister

2015-01-28T16:38:24Z

130.75.30.51: Passenderer Begriff...

Ab und an stellt sich folgendes Problem: Man würde wesentlich mehr Ausgangspins oder Eingangspins benötigen als der [[Mikrocontroller]] zur Verfügung stellt. Ein möglicher Ausweg ist eine Porterweiterung mit einem Schieberegister. Zwei beliebte Schieberegister sind beispielsweise der 74xx595 bzw. der 74xx165.

== Porterweiterung für Ausgänge ==

Um neue Ausgangspins zu gewinnen kann der [[74xx | 74xx595]] verwendet werden. Dabei handelt es sich um ein ''8-Bit 3-state Serial-in/Serial-out or Parallel-Out Schieberegister mit einem Ausgangsregister und einem asynchronen Reset''.

Hinter dieser kompliziert anmutenden Beschreibung verbirgt sich eine einfache Funktionalität: Das Schieberegister besteht aus zwei Funktionseinheiten: Dem eigentlichen Schieberegister und dem Ausgangsregister. In das Schieberegister können die Daten seriell hineingetaktet werden und durch ein bestimmtes Signal werden die Daten des Schieberegisters in das Ausgangsregister übernommen und können von dort auf die Ausgangspins geschaltet werden.

Im Einzelnen bedeuten die Begriffe:

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Begriff || Erklärung
|-
||8-Bit
|align="left"| Acht Ausgangs[[Bit|bit]]s
|-
||3-state
|align="left"| Die acht Registerausgänge können drei Zustände, Low, High und High-Impedanz annehmen. Siehe [[Ausgangsstufen Logik-ICs]]
|-
||Serial-in
|align="left"| Serieller Eingang des Schieberegisters
|-
||Serial-out
|align="left"| Serieller Ausgang des Schieberegisters
|-
||Parallel-Out
|align="left"| Parallele Ausgänge des Ausgangsregisters
|-
||Schieberegister
|align="left"| Serielle Daten werden durch den Baustein durchgeschoben
|-
|Ausgangsregister
|align="left"| Ein Speicher, welcher die Daten des Schieberegisters zwischenspeichern kann. Dieses besteht aus acht [[FlipFlop]]s.
|-
|Asynchroner Reset
|align="left"| Die Daten im Schieberegister können asynchron zurückgesetzt werden.
|}
</center>

=== Aufbau 74xx595 ===

[[Bild:74xx595-1.png|framed|center|Pinbelegung eines 595]]

Hinweis: Die Benennung der Pins in den Datenblättern verschiedener Hersteller unterscheidet sich zum Teil. Die Funktionen der Pins sind jedoch gleich.

Achtung: Es gibt auch noch einen IC von TI mit eingebauten Treibern 50 V 150 mA, den TPIC6B595, der hat 20 Pins und eine abweichende Pinbelegung http://www.ti.com/product/tpic6b595

==== HC oder HCT? ====

[ACHTUNG: HIER STEHT VIEL MÜLL BEZUEGLICH DER SCHALTSCHWELLEN !!!
Schaltschwellen von HC, HCT, AHCT, etc. lassen sich im jeweiligen Datenblatt nachschlagen:
V_IH --> HIGH-level input voltage
V_IL --> LOW-level input voltage

74AHCT595 kann direkt von Low-Voltage MCUs angesteuert werden (2V minimum)
bei HC/HCT etc liegt die High Schaltschwelle bei 3,5V (minimum)
]

Mal gibt es 74'''HC'''595, mal 74'''HCT'''595.
Diese beiden Typen unterscheiden sich nur bei der Festlegung der Schaltschwelle an Eingangspins:
* HC: Schaltschwelle = halbe Betriebsspannung
* HCT: Schaltschwelle TTL-kompatibel bei 1,4 V
Es gibt auch 74LS595. In der modernen CMOS-Welt sollte man sich Low-Power-Schottky (= bipolar = Ruhestrom fressend) nicht mehr antun.

Im allgemeinen kann man alle Typen gleichermaßen verwenden und nimmt einfach den billigsten oder verfügbarsten. Nur beim Übergang zu echtem TTL oder verschiedenen Speisespannungen für Mikrocontroller und Portexpander wird es interessant.

Ein häufiges Szenario ist ein Mikrocontroller mit 3-V-Speisung (etwa ein ARM7 oder MSP430). Dann kann man mit einem 74'''HCT'''595, an 5 V betrieben, echte 5-V-Ausgänge und die Pegelkonvertierung dazu haben.
74'''HC'''595 funktionieren hier nur mit Glück, und bei noch geringerer Speisespannung des Controllers — etwa 2,5 V — gar nicht.

=== Pinbelegung 74xx595 ===

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! DIL Pin-Nummer || Funktion || Dieses Tutorial || Motorola / ON Semi || Philips / NXP || Fairchild || SGS|| Texas Instruments
|-
| 1 || Ausgang B || QB || QB || Q1 || QB || QB|| QB
|-
| 2 || Ausgang C || QC || QC || Q2 || QC || QC|| QC
|-
| 3 || Ausgang D || QD || QD || Q3 || QD || QD|| QD
|-
| 4 || Ausgang E || QE || QE || Q4 || QE || QE|| QE
|-
| 5 || Ausgang F || QF || QF || Q5 || QF || QF|| QF
|-
| 6 || Ausgang G || QG || QG || Q6 || QG || QG|| QG
|-
| 7 || Ausgang H || QH || QH || Q7 || QH || QH|| QH
|-
| 8 || Masse, 0 V || [nicht dargestellt] || GND || GND || GND || GND|| GND
|-
| 9 || Serieller Ausgang || QH* || SQH || Q7´ ||Q'H || QH´||QH'
|-
| 10 || Reset für Schieberegister || SCL || RESET || /MR || /SCLR || /SCLR || /SRCLR
|-
| 11 || Schiebetakt || SCK || SHIFT CLOCK || SHCP || SCK || SCK || SRCLK
|-
| 12 || Speichertakt || RCK || LATCH CLOCK || STCP || RCK || RCK || RCLK
|-
| 13 || Ausgangssteuerung || G || OUTPUT ENABLE || /OE || /G || /G || /OE
|-
| 14 || Serieller Dateneingang || SER || A || DS || SER || SI || SER
|-
| 15 || Ausgang A || QA || QA || Q0 || QA || QA|| QA
|-
| 16 || Betriebsspannung || [nicht dargestellt] || VCC || VCC || VCC || VCC|| VCC
|}
</center>

Der Baustein besteht aus zwei Einheiten:
* dem Schieberegister
* dem Ausgangsregister

Im Schieberegister werden die einzelnen Bits durchgeschoben. Mit jeder positiven Taktflanke(LOW -> HIGH) an '''SCK''' wird eine Schiebeoperation durchgeführt.

Das Ausgangsregister hat die Aufgabe die Ausgangspins des Bausteins anzusteuern. Durch dieses Ausgangsregister ist es möglich, die Schiebeoperationen im Hintergrund durchzuführen, ohne dass IC Pins ihren Wert ändern. Erst wenn die Schiebeoperation abgeschlossen ist, wird der aktuelle Zustand der Schieberegisterkette durch einen Puls an '''RCK''' in das Ausgangsregister übernommen.

===Funktionsweise===

Am Eingang '''SER''' (Pin 14) wird das gewünschte nächste Datum (0 oder 1) angelegt. Durch einen positiven Puls an '''SCK''' (Pin 11) wird der momentan an '''SER''' anliegende Wert als neuer Wert für Bit 0, das unterste Bit des Schieberegisters, übernommen. Gleichzeitig werden alle anderen Bits im Schieberegister um eine Stelle verschoben: Das Bit 6 wird ins Bit 7 übernommen, Bit 5 ins Bit 6, Bit 4 ins Bit 5, etc. sodass das Bit 0 zur Aufnahme des '''SER''' Bits frei wird.

[[Bild:74xx595-2.png|center]]

Eine Sonderstellung nimmt das ursprüngliche Bit 7 ein. Dieses Bit steht direkt auch am Ausgang '''QH*''' (Pin 9) zur Verfügung. Dadurch ist es möglich an ein Schieberegister einen weiteren Baustein 74xxx595 anzuschließen und so beliebig viele Schieberegister hintereinander zu schalten (kaskadieren). Auf diese Art lassen sich Schieberegister mit beliebig vielen Stufen aufbauen.

Wurde das Schieberegister mit den Daten gefüllt, so wird mit einem LOW-HIGH Puls am Pin 12, '''RCK''' der Inhalt des Schieberegisters in das Ausgangsregister übernommen.

[[Bild:74xx595-3.png|center]]

Mit dem Eingang '''G''' (Pin 13) kann das Ausgangsregister freigegeben werden. Liegt '''G''' auf 0, so führen die Ausgänge '''QA''' bis '''QH''' entsprechende Pegel. Liegt '''G''' auf 1, so schalten die Ausgänge '''QA''' bis '''QH''' auf [[Ausgangsstufen Logik-ICs |Tristate]]. D.h. sie treiben aktiv weder LOW oder HIGH, sondern sind hochohmig wie ein Eingang und nehmen jeden Pegel an, der ihnen von außen aufgezwungen wird.

Bleibt nur noch der Eingang '''SCL'''(Pin 10). Mit ihm kann das Schieberegister im Baustein gelöscht, also auf eine definierte 0, gesetzt werden.

Die Ansteuerung eines 74xxx595 Schieberegisters gestaltet sich sehr einfach. Im Grunde gibt es 2 Möglichkeiten:
* Mittels [[SPI]] kann der [[AVR]] das Schieberegister direkt und autark ansteuern. Das ist sehr schnell und verbraucht nur wenig CPU-Leistung
* Sind die entsprechenden SPI-Pins am AVR nicht frei, so ist auch eine softwaremäßige Ansteuerung des Schieberegisters mit einfachen Mitteln durchführbar.

=== Ansteuerung per Software===

[[Bild:Mega8-595.gif|framed|right|Anschluss eines 595]]
Für eine komplette Softwarelösung kann das Schieberegister an jede beliebige Port-Pin Kombination angeschlossen werden. Wir wählen die Pins '''PB0''', '''PB1''', '''PB2''' und '''PB3''' um dort die Schieberegisteranschlüsse '''SER''', '''SCK''', '''SCL''' und '''RCK''' anzuschließen. Des Weiteren muss das Schieberegister mit Spannung versorgt werden, auch wenn das rechts im Bild nicht eingezeichnet ist. Pin 16 muss auf +5V und Pin 8 auf GND geschaltet werden.

Die Programmierung gestaltet sich dann nach folgendem Schema: Die 8 Bits eines Bytes werden nacheinander an den Ausgang '''PB0''' ('''SER''') ausgegeben. Durch Generierung eines Pulses 0-1-0 an Pin '''PB1''' ('''SCK''') übernimmt das Schieberegister nacheinander die einzelnen Bits. Dabei ist zu beachten, dass die Ausgabe mit dem höherwertigen Bit beginnen muss, denn dieses Bit wandert ja am weitesten zur Stelle '''QH'''. Sind alle 8 Bits ausgegeben, so wird durch einen weiteren 0-1-0 Impuls am Pin '''PB3''' ('''RCK''') der Inhalt der Schieberegisterbits 0 bis 7 in die Ausgaberegister '''QA''' bis '''QH''' übernommen. Dadurch, dass am Schieberegister der Eingang '''G''' konstant auf 0-Pegel gehalten wird, erscheint dann auch die Ausgabe sofort an den entsprechenden Pins und kann zb. mit LEDs (low-current LEDs + Vorwiderstand verwenden) sichtbar gemacht werden.

Der Schieberegistereingang '''SCL''' wird auf einer 1 gehalten. Würde er
auf 0 gehen, so würde die Schieberegisterkette gelöscht. Möchte man einen weiteren Prozessorpin einsparen, so kann man diesen Pin auch generell auf Vcc legen. Das Schieberegister könnte man in so einem Fall durch Einschreiben von 0x00 immer noch löschen.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp1 = r16
.def temp2 = r17

.equ SCHIEBE_DDR = DDRB
.equ SCHIEBE_PORT = PORTB
.equ RCK = 3
.equ SCK = 1
.equ SCL = 2
.equ SIN = 0

ldi temp1, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp1
ldi temp1, HIGH(RAMEND)
out SPH, temp1

;
; Die Port Pins auf Ausgang konfigurieren
;
ldi temp1, (1<<RCK) | (1<<SCK) | (1<<SCL) | (1<<SIN) ; Anm.1
out SCHIEBE_DDR, temp1

;
; die Clear Leitung am Schieberegister auf 1 stellen
;
sbi SCHIEBE_PORT, SCL

;
; Ein Datenbyte ausgeben
;
ldi temp1, 0b10101010
rcall Schiebe
rcall SchiebeOut

loop:
rjmp loop

;-----------------------------------------------------------------------------
;
; Die Ausgabe im Schieberegister in das Ausgaberegister übernehmen
;
; Dazu am RCK Eingang am Schieberegister einen 0-1-0 Puls erzeugen
;
SchiebeOut:
sbi SCHIEBE_PORT, RCK
cbi SCHIEBE_PORT, RCK
ret

;-----------------------------------------------------------------------------
;
; 8 Bits aus temp1 an das Schieberegister ausgeben
Schiebe:
push temp2
ldi temp2, 8 ; 8 Bits müssen ausgegeben werden

Schiebe_1:
;
; jeweils das höchstwertige Bit aus temp1 ins Carry-Flag schieben
; Je nach Zustand des Carry-Flags wird die Datenleitung entsprechend
; gesetzt oder gelöscht
;
rol temp1 ; MSB -> Carry
brcs Schiebe_One ; Carry gesetzt? -> weiter bei Schiebe_One
cbi SCHIEBE_PORT, SIN ; Eine 0 ausgeben
rjmp Schiebe_Clock ; und Sprung zur Clock Puls Generierung
Schiebe_One:
sbi SCHIEBE_PORT, SIN ; Eine 1 ausgeben

;
; einen Impuls an SCK zur Übernahme des Bits nachschieben
;
Schiebe_Clock:
sbi SCHIEBE_PORT, SCK ; Clock-Ausgang auf 1 ...
cbi SCHIEBE_PORT, SCK ; und wieder zurück auf 0

dec temp2 ; Anzahl der ausgegebenen Bits runterzählen
brne Schiebe_1 ; Wenn noch keine 8 Bits ausgegeben -> Schleife bilden

pop temp2
ret
</syntaxhighlight>

Anm.1: Siehe [[Bitmanipulation]]

=== Ansteuerung per SPI-Modul===
[[Bild:Mega8-595-SPI.png|framed|right|Anschluss eines 595 per SPI]]
Noch schneller geht die Ansteuerung des Schieberegisters mittels [[Serial_Peripheral_Interface | SPI]]-Modul, welches in fast allen AVRs vorhanden ist. Hier wird der Pin '''SCL''' nicht benutzt, da das praktisch keinen Sinn hat. Er muss also fest auf VCC gelegt werden. (Oder mit den Reset-Pin des AVRs, das mit einer RC Schaltung versehen ist, verbunden werden. Damit erreicht man einen definierten Anfangszustand des Schieberegisters.) Die Pins für '''SCK''' und '''SIN''' sind durch den jeweiligen AVR fest vorgegeben. '''SCK''' vom 74xxx595 wird mit '''SCK''' vom AVR verbunden sowie '''SIN''' mit '''MOSI''' ('''M'''aster '''O'''ut, '''S'''lave '''I'''n). '''MISO''' ('''M'''aster '''I'''n, '''S'''lave '''O'''ut) ist hier ungenutzt. Es kann NICHT für '''RCK''' verwendet werden, da es im SPI-Master Modus immer ein Eingang ist! Es kann aber als allgemeiner Eingang oder für 74HC165 ([[#Porterweiterung_für_Eingänge|siehe unten]]) verwendet werden.

Der AVR-Pin '''SS''' wird sinnvollerweise als '''RCK''' benutzt, da er sowieso als Ausgang geschaltet werden '''muss''', sonst gibt es böse Überaschungen (siehe Datenblatt „SS Pin Functionality“). Dieser sollte mit einem Widerstand von 10 kΩ nach Masse, während der Start- und Initialisierungsphase, auf L-Potential gehalten werden. `('''SS''' ist während dieser Zeit noch im Tri-State und es könnte passieren, dass die zufälligen Daten des Schieberegisters in das Ausgangslatch übernommen werden.)

Bei den kleineren ATtinys mit '''USI''' (Universal Serial Interface) darf man sich von den Pin-Bezeichnungen MOSI und MISO nicht [http://de.wikipedia.org/wiki/Bockshorn_(Redensart) ins Bockshorn jagen] lassen: Hier ist MISO der Ausgang(!) '''DO''' und MOSI der Eingang(!) '''DI'''. Die Pinbezeichnungen MOSI und MISO sind nur zum Programmieren und irreführend, weil ohnehin nur für den Slave-Betrieb.

Je nach Bedarf kann man die Taktrate des SPI-Moduls zwischen 1/2 ... 1/128 des CPU-Taktes wählen. Es spricht kaum etwas dagegen mit maximaler Geschwindigkeit zu arbeiten. Die AVRs können zur Zeit mit maximal 20 MHz getaktet werden, d.h. es sind maximal 10 MHz SPI-Takt möglich. Das ist für ein 74xxx595 kein Problem. Die Übertragung von 8 Bit dauert dann gerade mal 800 ns!

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp1 = r16

; Die Definitionen müssen an den jeweiligen AVR angepasst werden

.equ SCHIEBE_DDR = DDRB
.equ SCHIEBE_PORT = PORTB
.equ RCK = PB2 ; SS
.equ SCK = PB5 ; SCK
.equ SIN = PB3 ; MOSI

ldi temp1, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp1
ldi temp1, HIGH(RAMEND)
out SPH, temp1
;
; SCK, MOSI, SS als Ausgänge schalten
;
in temp1, SCHIEBE_DDR
ori temp1, (1<<SIN) | (1<<SCK) | (1<<RCK)
out SCHIEBE_DDR,temp1
;
; SPI Modul konfigurieren
;
ldi temp1, (1<<SPE) | (1<<MSTR)
out SPCR, temp1 ; keine Interrupts, MSB first, Master
; CPOL = 0, CPHA =0
; SCK Takt = 1/2 XTAL
ldi temp1, (1<<SPI2X)
out SPSR, temp1 ; double speed aktivieren
out SPDR, temp1 ; Dummy Daten, um SPIF zu setzen
;
; Ein Datenbyte ausgeben
;
ldi temp1, 0b10101010
rcall Schiebe ; Daten schieben
rcall SchiebeOut ; Daten in Ausgangsregister übernehmen

loop:
rjmp loop

;-----------------------------------------------------------------------------
;
; Die Daten im Schieberegister in das Ausgaberegister übernehmen
;
; Dazu am RCK Eingang am Schieberegister einen 0-1-0 Puls erzeugen
;
SchiebeOut:
sbis SPSR, SPIF ; prüfe ob eine alte Übertragung beendet ist
rjmp SchiebeOut
sbi SCHIEBE_PORT, RCK
cbi SCHIEBE_PORT, RCK
ret

;-----------------------------------------------------------------------------
;
; 8 Bits aus temp1 an das Schieberegister ausgeben
;
Schiebe:
sbis SPSR, SPIF ; prüfe ob eine alte Übertragung beendet ist
rjmp Schiebe
out SPDR, temp1 ; Daten ins SPI Modul schreiben, Übertragung beginnt automatisch
ret
</syntaxhighlight>

===Kaskadieren von Schieberegistern===

[[Bild:Mega8-595-2.gif|framed|right|Kaskadieren mehrerer 595]]
Um ein Schieberegister anzuschließen genügen also im einfachsten Fall 4 freie Prozessorpins (3 wenn '''SCL''' nicht benutzt wird) um weitere 8 Ausgangsleitungen zu bekommen. Genügen diese 8 Leitungen nicht, so kann ohne Probleme ein weiteres Schieberegister an das bereits vorhandene angeschlossen werden.

Das nächste Schieberegister wird mit seinem Dateneingang '''SER''' einfach an den dafür vorgesehenen Ausgang '''QH*''' des vorhergehenden Schieberegisters angeschlossen. Die Steuerleitungen '''SCK''', '''RCK''' und '''SCL''' werden parallel zu den bereits vorhandenen geschaltet. Konzeptionell erhält man dadurch ein Schieberegister mit einer Breite von 16 Bit. Werden weiter Bausteine in derselben Manier angeschlossen, so erhöht sich die Anzahl der zur Verfügung stehenden Ausgabeleitungen mit jedem Baustein um 8 ohne dass sich die Anzahl der am Prozessor notwendigen Ausgabepins erhöhen würde. Um diese weiteren Register zu nutzen, muss man in der reinen Softwarelösung nur mehrfach die Funktion '''Schiebe''' aufrufen, um alle Daten auszugeben. Am Ende werden dann mit '''SchiebeOut''' die Daten in die Ausgangsregister übernommen.

Bei der SPI Lösung werden ebenfalls ganz einfach mehrere Bytes über SPI ausgegeben, ehe dann mittels '''RCK''' die in die Schieberegisterkette eingetakteten Bits in das Ausgangsregister übernommen werden.
Um das Ganze ein wenig zu vereinfachen, soll hier eine Funktion zur Ansteuerung mehrerer kaskadierter Schieberegister über das SPI-Modul gezeigt werden. Dabei wird die Ausgabe mehrerer Bytes über eine Schleife realisiert, mehrfache Aufrufe der Funktion sind damit nicht nötig. Statt dessen übergibt man einen Zeiger auf einen Datenblock im RAM sowie die Anzahl der zu übertragenden Bytes. Außerdem wird die Datenübernahme durch '''RCK''' standardkonform integriert. Denn bei nahezu allen ICs mit SPI wird ein sog. CS-Pin verwendet ('''C'''hip '''S'''elect) Dieser Pin ist meist LOW aktiv, d.h. wenn er HIGH ist, ignoriert der IC alle Signale an '''SCK''' und '''MOSI''' und gibt keine Daten an MISO aus. Ist er LOW, dann ist der IC aktiv und funktioniert normal. Bei der steigenden Flanke an '''CS''' werden die Daten ins Ausgangsregister übernommen. Die Funktion ist sehr schnell, da die Zeit während der die Übertragung eines Bytes läuft, dazu genutzt wird, den Schleifenzähler zu verringern und zu prüfen sowie neue Sendedaten zu laden. Zwischen den einzelnen Bytes gibt es somit nur eine Pause von max. 6 Systemtakten.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"
.def temp1 = r16

; Die Definitionen müssen an den jeweiligen AVR angepasst werden

.equ SCHIEBE_DDR = DDRB
.equ SCHIEBE_PORT = PORTB
.equ RCK = PB2 ; SS
.equ SCK = PB5 ; SCK
.equ SIN = PB3 ; MOSI

;-----------------------------------------------------------------------------
;
; Datensegment im RAM
;
;-----------------------------------------------------------------------------

.dseg
.org $60
Schiebedaten: .byte 2

;-----------------------------------------------------------------------------
;
; Programmsegment im FLASH
;
;-----------------------------------------------------------------------------

.cseg
ldi temp1, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp1
ldi temp1, HIGH(RAMEND)
out SPH, temp1
;
; SCK, MOSI, SS als Ausgänge schalten
;
in temp1,SCHIEBE_DDR
ori temp1,(1<<SIN) | (1<<SCK) | (1<<RCK)
out SCHIEBE_DDR,temp1

sbi SCHIEBE_PORT, RCK ; Slave select inaktiv
;
; SPI Modul konfigurieren
;
ldi temp1, 0b01010000
out SPCR, temp1 ; keine Interrupts, MSB first, Master
; CPOL = 0, CPHA =0
; SCK Takt = 1/2 XTAL
ldi r16,1
out SPSR,r16 ; Double Speed
out SPDR,temp1 ; Dummy Daten, um SPIF zu setzen

; den Datenblock mit Daten füllen

ldi temp1,$F0
sts Schiebedaten,temp1
ldi temp1,$55
sts Schiebedaten+1,temp1

loop:
; den Datenblock ausgeben

ldi r16,2
ldi zl,low(Schiebedaten)
ldi zh, high(Schiebedaten)
rcall Schiebe_alle ; Daten ausgeben

rjmp loop ; nur zur Simulation

;-----------------------------------------------------------------------------
;
; N Bytes an das Schieberegister ausgeben und in das Ausgaberegister übernehmen
;
; r16: Anzahl der Datenbytes
; Z: Zeiger auf Datenblock im RAM
;
;-----------------------------------------------------------------------------
Schiebe_alle:
cbi SCHIEBE_PORT, RCK ; RCK LOW, SPI Standardverfahren
push r17

Schiebe_alle_2:
ld r17,Z+
Schiebe_alle_3:
sbis SPSR,SPIF ; prüfe ob eine alte Übertragung beendet ist
rjmp Schiebe_alle_3
out SPDR,r17 ; Daten ins SPI Modul schreiben, Übertragung beginnt automatisch
dec r16
brne Schiebe_alle_2

Schiebe_alle_4:
sbis SPSR,SPIF ; prüfe ob die letzte Übertragung beendet ist
rjmp Schiebe_alle_4

pop r17
sbi SCHIEBE_PORT, RCK ; RCK inaktiv, Datenübernahme
ret
</syntaxhighlight>

Der Nachteil von Schieberegistern ist allerdings, dass sich die Zeit zum Setzen aller Ausgabeleitungen mit jedem weiteren Baustein immer weiter erhöht. Dies deshalb, da ja die einzelnen Bits im Gänsemarsch durch alle Bausteine geschleust werden müssen und für jeden einzelnen Schiebevorgang etwas Zeit notwendig ist. Ein Ausweg ist die Verwendung des SPI-Moduls, welches schneller arbeitet als die reine Softwarelösung. Ist noch mehr Geschwindigkeit gefragt, so sind mehr Port-Pins nötig. Kann ein kompletter Port mit 8 Pins für die Daten genutzt werden, sowie ein paar weitere Steuerleitungen, so können ein oder mehrere 74xxx573 eine Alternative sein, um jeweils ein vollständiges Byte auszugeben. Natürlich kann der 74xxx573 (oder ein ähnliches Schieberegister) auch mit dem 74xxx595 zusammen eingesetzt werden, beispielsweise in dem über das Schieberegister verschiedene 74xxx595 nacheinander aktiviert werden. Weitere Tips und Tricks dazu gibt es vielleicht in einem weiteren Tutorial...

=== Acht LEDs mit je 20mA pro Schieberegister ===

Will man nun acht [[LED]]s mit dem Schieberegister ansteuern, kann man diese direkt über Vorwiderstände anschließen. Doch ein genauer Blick ins Datenblatt verrät, dass der 74xx595 nur maximal 70mA über VCC bzw. GND ableiten kann. Und wenn man den IC nicht gnadenlos quälen, und damit die Lebensdauer und Zuverlässigkeit drastisch reduzieren will, gibt es nur zwei Auswege.

* Den Strom pro LED auf 70/8 = 8,75mA begrenzen; Das reicht meistens aus um die LEDs schön leuchten zu lassen, vor allem bei low-current und ultrahellen LEDs
* Wenn doch 20 mA pro LED gebraucht werden, kann man die folgende Trickschaltung anwenden.

[[bild:8x20mA_LED_mit_74xx595.png|framed|center|Mehrere LED anschließen]]

Der Trick besteht darin, dass 4 LEDs ihren Strom über das Schieberegister von VCC beziehen (HIGH aktiv) während die anderen vier ihren Strom über GND leiten (LOW aktiv). Damit bleiben ganz offiziell für jede LED 70/4 = 17,5mA. Um die Handhabung in der Software zu vereinfachen muss nur vor der Ausgabe der Daten das jeweilige Byte mit 0x0F XOR verknüpft werden, bevor es in das Schieberegister getaktet wird. Dadurch werden die LOW-aktiven LEDs richtig angesteuert und die Datenhandhabung in der Software muss nur mit HIGH-aktiven rechnen. Außerdem wird der G Eingang verwendet, um die Helligkeit aller LEDs per [[PWM]] zu steuern. Beachtet werden muss, dass die PWM im invertierten Modus generiert werden muss, da der Eingang G LOW aktiv ist.

Achtung! Die Widerstände sind auf blaue LEDs mit 3,3V Flussspannung ausgelegt. Bei roten, gelben und grünen [[LED]]s ist die Flussspannung geringer und dementsprechend muss der Vorwiderstand größer sein.

Wenn 20mA immer noch nicht reichen sollten oder z.B. RGB-LEDs mit gemeinsamer Anode angesteuert werden müssen, dann hilft nur ein stärkerer IC. Der Klassiker ist der TPIC6A595 von TI, er kombiniert ein Schieberegister mit MOSFETs, sodass hier 250mA pro Kanal zur Verfügung stehen.

=== Achtung beim Startup! ===

Die Ausgänge des '595 führen beim Einschalten undefinierte, also zufällige Pegel! Und der Eingang ¬SCL löscht nur die Schieberegister (= unnütz, um mit ¬RESET zu verbinden). Sind deshalb ''definierte'' Pegel beim Einschalten unerlässlich, muss man ¬OE beschalten:
* Entweder mit einem weiteren Mikrocontroller-Ausgang (der mit einem externen Pull-Up-Widerstand zu beschalten ist und nach dem ersten Durchschieben dauerhaft auf LOW gelegt wird)
* Oder mit einer RC(D)-Kombination, die die Ausgänge für eine gewisse Zeit auf Tristate hält. Spart ein Mikrocontroller-Pin.
Obendrein sind, wie sonst am Mikrocontroller, die betreffenden Ausgänge mit externen Pull-Up- oder Pull-Down-Widerständen zu beschalten.

== Porterweiterung für Eingänge ==

Ein naher Verwandter des 74xx595 ist der [[74xx | 74xx165]], er ist quasi das Gegenstück. Hierbei handet es sich um ein ''8-bit parallel-in/serial-out shift register''. Auf Deutsch: Ein 8 Bit Schieberegister mit parallelem Eingang und seriellem Ausgang. Damit kann man eine große Anzahl Eingänge sehr einfach und preiswert zu seinem Mikrocontroller hinzufügen.

=== Aufbau ===

[[bild:74xx165-1.png|framed|center|Pinbelegung eines 165]]

Der Aufbau ist sehr ähnlich zum 74xx595. Allerdings gibt es kein Register zum Zwischenspeichern. Das ist auch gar nicht nötig, da der IC ja einen parallelen Eingang hat. Der muss nicht zwischengespeichert werden. Es gibt hier also wirklich nur das Schieberegister. Dieses wird über den Eingang PL mit den parallelen Daten geladen. Dann können die Daten seriell mit Takten an CLK aus dem Ausgang Q7 geschoben werden.

=== Funktionsweise ===

DS ist der serielle Dateneingang, welcher im Falle von kaskadierten Schieberegistern mit dem Ausgang des vorhergehenden ICs verbunden wird.

D0..D7 sind die parallelen Dateneingänge.

Mittels des Eingangs PL ('''P'''arallel '''L'''oad) werden die Daten vom parallelen Eingang in das Schieberegister übernommen, wenn dieses Signal LOW ist. Hier muss man aber ein klein wenig aufpassen. Auf Grund der Schaltungsstruktur ist der Eingang PL mit dem Takt CLK verknüpft (obwohl es dafür keinen logischen Grund gibt :-0). Damit es nicht zu unerwünschten Fehlschaltungen kommt, muss der Takt CLK während des Ladens auf HIGH liegen. Wird PL wieder auf HIGH gesetzt, sind die Daten geladen. Das erste Bit liegt direkt am Ausgang Q7 an. Die restlichen Bits können nach und nach durch das Register geschoben werden.

Der Eingang CE ('''C'''lock '''E'''nable) steuert, ob das Schieberegister auf den Takt CLK reagieren soll oder nicht. Ist CE gleich HIGH werden alle Takte an CLK ignoriert. Bei LOW werden mit jeder positiven Flanke die Daten um eine Stufe weiter geschoben.

Wird am Eingang CLK eine LOW-HIGH Flanke angelegt und ist dabei CE auf LOW, dann werden die Daten im Schieberegister um eine Position weiter geschoben: DS->Q0, Q0->Q1, Q1->Q2, Q2->Q3, Q3->Q4, Q4->Q5, Q5->Q6, Q6->Q7. Q0..Q6 sind interne Signale, siehe [http://www.nxp.com/acrobat/datasheets/74HC_HCT165_CNV_2.pdf Datenblatt].

Q7 ist der serielle Ausgang des Schieberegisters. Dort Werden Takt für Takt die Daten ausgegeben. Hier wird normalerweise der Eingang des Mikrocontrollers oder der Eingang des nächsten Schieberegisters angeschlossen.

Q7\ ist der invertierte Ausgang des Schieberegisters. Er wird meist nicht verwendet.

=== Schaltung ===

Um nun beispielsweise zwei Schieberegister zu kaskadieren um 16 Eingangspins zu erhalten sollte man folgende Verschaltung vornehmen. Beachten sollte man dabei, dass

* der serielle Eingang DS des ersten Schieberegisters (hier IC1) auf einen festen Pegel gelegt wird (LOW oder HIGH).
* der serielle Datenausgang bei der Benutzung des SPI-Moduls an MISO und nicht an MOSI angeschlossen wird.

[[bild:74xx165-2.png|framed|center|Anschluss eines 165]]

Nachfolgend werden zwei Beispiele gezeigt, welche die Ansteuerung nach bekanntem Muster übernehmen. Nur dass hier eben Daten gelesen anstatt geschrieben werden. Zu beachten ist, dass hier ein anderer Modus der SPI-Ansteuerung verwendet werden muss, weil der Baustein das nötig macht. Das muss beachtet werden, wenn auch Schieberegister für Ausgänge verwendet werden. Dabei muss jeweils vor dem Zugriff auf die Ein- oder Ausgangsregister der Modus des Taktes (CPOL) umgeschaltet werden.

=== Ansteuerung per Software ===

<syntaxhighlight lang="avrasm">
; Porterweiterung für Eingänge mit Schieberegister 74xx165
; Ansteuerung per Software

.include "m8def.inc"

.def temp1 = r16
.def temp2 = r17
.def temp3 = r18

; Pins anpassen, frei wählbar

.equ SCHIEBE_DDR = DDRB
.equ SCHIEBE_PORT = PORTB
.equ SCHIEBE_PIN = PINB
.equ CLK = PB3
.equ PL = PB1
.equ DIN = PB2

;-----------------------------------------------------------------------------
;
; Datensegment im RAM
;
;-----------------------------------------------------------------------------

.dseg
.org 0x60
Daten: .byte 2 ; Speicherplatz für Eingangsdaten

;-----------------------------------------------------------------------------
;
; Programmsegment im FLASH
;
;-----------------------------------------------------------------------------
.cseg
ldi temp1, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp1
ldi temp1, HIGH(RAMEND)
out SPH, temp1

; CLK und PL als Ausgänge schalten

ldi temp1, (1<<clk) | (1<<pl)
out SCHIEBE_DDR, temp1

sbi schiebe_port, clk ; Takt im Ruhezustand immer auf 1
; komische Schaltung im 74xx165

; Zwei Bytes einlesen

ldi ZL,low(Daten)
ldi ZH,high(Daten)
ldi temp1,2
rcall schiebe_eingang

loop:
rjmp loop

;-----------------------------------------------------------------------------
;
; N Bytes seriell einlesen
;
; temp1 : N, Anzahl der Bytes
; Z : Zeiger auf einen Datenbereich im SRAM
;-----------------------------------------------------------------------------

schiebe_eingang:
push temp2 ; Register sichern
push temp3

cbi schiebe_port, pl ; Daten parallel laden
sbi schiebe_port, pl

schiebe_eingang_byte_schleife:

ldi temp3, 8 ; Bitzähler
schiebe_eingang_bit_schleife:
lsl temp2 ; Daten weiterschieben

; das IO Bit Din in das niederwerigste Bit von temp2 kopieren

sbic schiebe_pin, din ; wenn Null, nächsten Befehl überspringen
ori temp2,1 ; nein, Bit setzen

cbi SCHIEBE_PORT, CLK ; Taktausgang auf 0
sbi SCHIEBE_PORT, CLK ; und wieder zurück auf 1, dabei Daten schieben

dec temp3 ; Bitzähler um eins verringern
brne schiebe_eingang_bit_schleife ;wenn noch keine 8 Bits ausgegeben, nochmal

st z+,temp2 ; Datenbyte speichern
dec temp1 ; Anzahl Bytes um eins verringern
brne schiebe_eingang_byte_schleife ; wenn noch mehr Bytes zu lesen sind

pop temp3
pop temp2
ret
</syntaxhighlight>

=== Ansteuerung per SPI-Modul ===

<syntaxhighlight lang="avrasm">
; Porterweiterung für Eingänge mit Schieberegister 74xx165
; Ansteuerung per SPI-Modul

.include "m8def.inc"

.def temp1 = r16
.def temp2 = r17
.def temp3 = r18

; Pins anpassen
; diese müssen mit den SPI-Pins des AVR Typs übereinstimmen!

.equ SCHIEBE_DDR = DDRB
.equ SCHIEBE_PORT = PORTB
.equ PL = PB2 ; SS
.equ CLK = PB5 ; SCK
.equ DIN = PB4 ; MISO

;-----------------------------------------------------------------------------
;
; Datensegment im RAM
;
;-----------------------------------------------------------------------------

.dseg
.org 0x60
Daten: .byte 2 ; Speicherplatz für Eingangsdaten

;-----------------------------------------------------------------------------
;
; Programmsegment im FLASH
;
;-----------------------------------------------------------------------------
.cseg
ldi temp1, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp1
ldi temp1, HIGH(RAMEND)
out SPH, temp1

; CLK und PL als Ausgänge schalten

ldi temp1,(1<<CLK) | (1<<PL)
out SCHIEBE_DDR,temp1
;
; SPI Modul konfigurieren
;
ldi temp1, (1<<SPE) | (1<<MSTR) | (1<<CPOL)
out SPCR, temp1 ; keine Interrupts, MSB first, Master
; CPOL = 1, CPHA =0
; SCK Takt = 1/2 XTAL
ldi temp1, (1<<SPI2X)
out SPSR,temp1 ; double speed aktivieren
out SPDR,temp1 ; Dummy Daten, um SPIF zu setzen

; Zwei Bytes einlesen

ldi ZL,low(Daten)
ldi ZH,high(Daten)
ldi temp1,2
rcall schiebe_eingang

loop:
rjmp loop

;-----------------------------------------------------------------------------
;
; N Bytes seriell einlesen
;
; temp1 : N, Anzahl der Bytes
; Z : Zeiger auf einen Datenbereich im SRAM
;-----------------------------------------------------------------------------
schiebe_eingang:
push temp2 ; Register sichern

; CLK ist im Ruhezustand schon auf HIGH, CPOL=1

dummyende:
sbis SPSR,7 ; prüfe ob Dummy Übertragung beendet ist, sonst
rjmp dummyende ; kann es bei langsameren Übertragungsraten zu
; Überschneidungen kommen.

cbi schiebe_port, pl ; Daten parallel laden
sbi schiebe_port, pl

schiebe_eingang_1:
sbis SPSR,7 ; prüfe ob eine alte Übertragung beendet ist
rjmp schiebe_eingang_1

schiebe_eingang_byte_schleife:
out SPDR,temp1 ; beliebige Daten ins SPI Modul schreiben
; um die Übertragung zu starten
schiebe_eingang_2:
sbis SPSR,7 ; auf das Ende der Übertragung warten
rjmp schiebe_eingang_2

in temp2, spdr ; Daten lesen
st z+,temp2 ; Datenbyte speichern
dec temp1 ; Anzahl Bytes um eins verringern
brne schiebe_eingang_byte_schleife ; wenn noch mehr Bytes zu lesen sind

pop temp2
ret
</syntaxhighlight>

== Beides in ''einer'' Kette ==

Kann man die '595 und die '165 an ''einem'' SPI-Anschluss betreiben?

Ja, einfach verketten. Das geht auch „durcheinander“. Dafür gibt es zwei Möglichkeiten:

* Man verwendet ''getrennte'' Anschlüsse am Mikrocontroller für die Parallelübernahme der '595 (Ausgänge) und '165 (Eingänge). Dann sollten die Ausgänge am Ketten-Anfang (MOSI) und die Eingänge am Ketten-Ende (MISO) liegen. Beispielsweise werden für 3 Stück '595 und 2 Stück '165 24 Schiebetakte zum Ausgeben (mit anschließendem ↑RCLK) und 16 Schiebetakte (mit vorausgehendem ¬PL) zum Einlesen benötigt.

* Man verwendet einen ''gemeinsamen'' Anschluss '''¬L''' für ↑RCLK und ¬PL, ein Pin sparend. Die o.g. Reihenfolge der '595 und '165 ist weiterhin vorteilhaft. Nach dem o.g. Beispiel gilt folgendes Regime zum Ausgeben und Einlesen in einem Rutsch:
** Low-Nadel an ¬L (zum Laden der '165-Flipflops; die '595-Ausgänge verändern sich nicht)
** 8 x 3 = 24 Schiebetakte (auch zum Nur-Einlesen müssen die Ausgabedaten wiederholt ausgegeben werden)
** Low-Nadel an ¬L (zum Aktualisieren der '595-Ausgänge; das erneute Einlesen in den '165 ist ohne Belang)

Kann man per Software messen, wie lang die Kette ist?

Für bestimmte PnP-artige Lösungen ist es zweckmäßig, die Länge der Kette zu kennen:
Man schiebt einfach eine einzelne 1 (oder eine einzelne 0) durch die Kette, ohne Parallelübernahmen. Vorher muss man die Kette in ihrer zu erwartenden Maximallänge initialisieren. Benutzt man byteweise arbeitende Hardware-SPI, wird man auf ganze Byte-Längen vertrauen und kann für mehr Sicherheit ein bestimmtes Kennbyte durchschicken.

Kann man per Software messen, ''wo'' die '595 und die '165 liegen?

Nur wenn man davon ausgeht, dass sich die Eingänge nicht allzu schnell ändern. Das ist bei Tastern klar der Fall. Eine 100-prozentige Sicherheit gibt es nicht. Man schiebt ein bestimmtes Bitmuster (Byte) durch und nimmt '595 dort an, wo das Bitmuster auch zurückkommt. Man verwende mindestens 2 verschiedene Bitmuster, um eine derartige Eingangskombination auszuschließen. Wer ziemlich sicher gehen will, schiebt in einer Schleife alle 256 verschiedenen Kombinationen durch. Wenn (bei gemeinsamen ¬L) die Ausgänge unzulässig zappeln, muss man ¬OE beschalten, oder genau jene Bitkombinationen vermeiden.

Kann man andere SPI-Hardware in die Kette einfügen?

Genau dafür ist SPI gemacht! Aber nicht jeder (bspw.) A/D-Wandler ist dafür geeignet: Es muss möglich sein, Daten ''unverändert'' durchzuschieben. Oder wenigstens herumzuleiten. Wenn nicht, ist die einzig mögliche Anordnung ''zwischen'' den '595 (am Kettenanfang) und den '165 (am Kettenende). In der Regel wird eine gesonderte Chipselect-Leitung vom Mikrocontroller benötigt; nur in Ausnahmefällen ist o.g. '''¬L''' dafür geeignet (Datenblatt studieren!). Das Chipselect aus einem '595 zu generieren geht auch.

Was für Vorteile bringen '595 und '165 gegenüber einem größeren Mikrocontroller?

* Preis! Controller mit mehr Beinchen kosten oftmals deutlich mehr
* Günstigeres Routing zu weiter entfernten Schaltungsteilen
* Kleinere Steckverbinder zu weiteren Platinen, etwa Anzeige- und Bedien-Frontplatten
* Beliebige Verlängerbarkeit
* ESD-Schutz und Überlastschutz des Controllers
* Verbleib beim „gewohnten“ Mikrocontroller möglich

Und welche Nachteile handelt man sich ein?

* Fehlende Sonderfunktionen (etwa Hardware-PWM, Interrupts)
* Fehlende Bidirektionalität
* Geringere Geschwindigkeit sowie zusätzliche Verzögerung beim Startup
* Fehlende Weak-Pullups (bei den Eingängen, es sei denn, man verwendet veraltete 74LS165)
* Höherer Bestückungsaufwand durch das Mehr an Bauteilen

== Bekannte Probleme ==

AVR Studio 4.12 (Build 498) hat Probleme bei der korrekten Simulation des SPI-Moduls.

* Der Double-Speed Modus funktioniert nicht.

* Das Bit SPIF im Register SPSR, welches laut Dokumentation nur lesbar ist, ist im Simulator auch schreibbar! Das kann zu Verwirrung und Fehlern in der Simulation führen.

Hardwareprobleme

* Wenn das SPI-Modul aktiviert wird, wird '''NICHT''' automatisch SPIF gesetzt, es bleibt auf Null. Damit würde die erste Abfrage in ''Schiebe_alles'' in einer Endlosschleife hängen bleiben. Deshalb muss nach der Initialisierung des SPI-Moduls ein Dummy-Byte gesendet werden, damit am Ende der Übertragung SPIF gesetzt wird

* Da das SPI-Modul in Senderichtung nur einfach gepuffert ist, ist es nicht möglich absolut lückenlos Daten zu senden, auch wenn man mit '''nop''' eine feste minimale Zeit zwischen zwei Bytes warten würde. Zwischen zwei Bytes muss immer eine Pause von mind. 2 Systemtakten eingehalten werden.

== Weblinks ==

* [http://www.atmel.com/dyn/resources/prod_documents/doc2585.pdf AVR151: Setup And Use of The SPI] Atmel Application Note (PDF)
* [http://www.datasheetcatalog.com/datasheets_pdf/7/4/H/C/74HC595.shtml datasheetcatalog.com: 74HC595]
* [http://www.rn-wissen.de/index.php/Portexpander_am_AVR Roboternetz: Portexpander am AVR]
* [http://conductiveresistance.com/interactive-595-shift-register-simulator/ Interactive 595 Shift Register Simulator]
* [http://www.mikrocontroller.net/topic/215399#2145277 48 I/O Porterweiterung mit Schieberegister 74HC595 und 74HC165]
----

{{Navigation_zurückhochvor|
zurücktext=PWM|
zurücklink=AVR-Tutorial: PWM|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=SRAM|
vorlink=AVR-Tutorial: SRAM}}

[[Category:AVR-Tutorial|Schieberegister]]
[[Category:SPI]]
[[Category:Portexpander]]

Makro

2010-04-22T15:03:26Z

130.75.30.51: /* Also jetzt Macros oder Inline-Funktionen? */

Makros sind eine mehr oder weniger große Anzahl von Anweisungen, die unter einer Kurzbezeichnung zu einer Gruppe zusammengefasst sind und als Einheit verwendbar sind. Makros werden i.d.R von [[Assembler]]sprachen angeboten, sind aber auch in einigen [[HLL|höheren Programmiersprachen]] verfügbar etwa in [[C]]/[[C-Plusplus|C++]] durch den [[C-Präprozessor]]. Schließlich gibt es auch reine Makrosprachen (etwa den Makroprozessor m4 von Unix/Linux), die als Werkzeug zur systematischen Transformation von Textdateien eingesetzt werden können.

Hinsichtlich eines Makros ist zu unterscheiden zwischen dessen ''Definition'', i.d.R. einmalig und VOR der ersten Verwendung (evtl. auch in [[Include-Files]]) und dessen ''Verwendungen'' (0-mal bis beliebig oft).

== Allgemeines zu Macros ==

Besonders flexibel sind '''parametrisierbare Makros'''. Die Makro-Definition ist dann als eine Schablone zu sehen, bei der einige Stellen noch offen gehalten wurden, um sie erst später, bei der Makro-Verwendung zu füllen. Bei der Programmierung haben parametrisierbare Makros eine gewisse Ähnlichkeit zu Unterprogrammen (mit Parametern), werden aber anders als diese zum Zeitpunkt der Übersetzung ausgeführt und hinsichtlich der Parameterwerte festgelegt.

Bei der Programmierung von Mikrocontrollern ist es mitunter erforderlich, zwischen der Verwendung von Unterprogrammen und Makros abzuwägen. Universell wiederverwendbare, und deshalb in einer gewissen Umfang noch konfigurierbare Programmteile können in Form von Makros effizienter als Unterprogramme sein. Allerdings müssen die folgenden Voraussetzungen bestehen:
# Der "variable" Teil (= aktuelle Werte der Parameter) muss bei der Kompilierung festgelegt werden können. Sofern dieser Punkt nicht sichergestellt ist, scheiden (parametrisierte) Makros komplett aus.
# Der Makro wird nur ein einziges Mal in genau dieser Form verwendet. Ob die Mehrfachverwendung eines Makros mit identischen Parametern ein Vor- oder Nachteil gegenüber einem Unterprogramm ist, hängt davon ab, was optimiert werden soll. Im Hinblick auf die Ausführungsgeschwindigkeit ist der Makro vorteilhaft, geht es um geringe Code-Größe ist fast immer das Unterprogramm besser. Die Ausnahme von dieser Regel bilden triviale Makros, die weniger Machinen-Code erzeugen als der Befehl für einen Unterprogrammsprung und die notwendige Parameterübergabe.

== Macros vs. Inline Funktionen ==

Anstatt ein Macro zu verwenden, kann eine Funktion auch mit dem Schlüsselwort "inline" versehen werden. Dann erzeugt der Compiler kein Funktionsaufruf, sondern fügt den Code der Inline-Funktion direkt an dieser Stelle ein, an der die Funktion aufgerufen wird. 

=== Vorteile von Inline Funktionen ===
* Typensicherheit Der Compiler kann die Typen der Parameter prüfen und Fehler erkennen. Einem Macro kann eigentlich alles übergeben werden, was dann zu seltsamen Fehlermeldungen beim compilieren oder schlimmer einem seltsamen Programmverhalten führen. Beispiels sind im Artikel [[C-Präprozessor]] zu finden.
* Parameterauswertung Die Parameter werden ausgewertet, bevor die Inline-Funktion aufgerufen wird. Auch hier sei wieder für Beispiele auf den Artikel [[C-Präprozessor]] verwiesen.
* Optimieren Da der Compiler die Typen der Parameter kennt, versteht er möglicherweise, was in der Funktion passiert und kann den gesamten Code besser optimieren.
* Macros sind nur Hacks Macros sollten vermieden werden, da sie das Debuggen erschweren und sie der strukturierten Programmierung widersprechen. Insbesondere komplexe, vermeintlich geniale Macros, können für andere oder für einen selber nach einem halben Jahr schon komplett unverständlich sein.

=== Vorteile von Macros ===
* Textersetzung Macros sind etwas flexibler, da in ihnen bestimme Code-Schnipsel, die oft vorkommen, zusammengefasst werden können. Erst nach dem Einbauen des Macros durch den Preprozessor muss sich gültiger C-Code ergeben. Dadurch können Macros an manchen Stellen sehr flexibel eingesetzt werden.
* Macros sind genial Mit Macros kann man einige Sachen kompakt darstellen und inbesondere lästige Code-Wiederholungen vermeiden bzw. an eine Stelle zentral warten.

== Also jetzt Macros oder Inline-Funktionen? ==
Es ist wohl zum Teil eine Glaubenfrage über die sich lange vortrefflich streiten lässt. Die einen sagen, dass eben schon immer Macros verwendet wurden und sie zu C einfach dazu gehören (und zu Assembler sowieso). Die anderen sehen sie eher als Altlast aus Zeiten an, in der Code in Assember geschrieben wurde, die Compiler schlecht waren und ein Goto nichts böses war.... 
Die Erfahrung bei grösseren Projekten (vor allem im Nicht-uC oder 32-bit uC-Bereich) zeigt aber, dass der Einsatz von Macro mit Bedacht erfolgen sollte. Je abstrakter das Modul wird, desto weniger Macros sollten verwendet werden. Trotzdem sind Macros gerade dann sinnvoll, wenn man direkt an der Hardware programmiert und weit weg von strukturiert objektorientierter Programmierung ist. Um den einen oder anderen von Hand optimierten Hack kommt man dann einfach nicht herum, weil die der Compiler das sonst einfach doch nicht schafft. 
Trotzdem sei an dieser Stelle gewarnt, sich in vermeintlich tollen Macro zu verrennen, ohne über das ganze mal eine Nacht zu überschlafen. Jede vermeintliche Optimierung über Macro-Hacks sollte am Ende auch wirklich eine Optimierung sein.

An dieser Stelle erwartet der Autor hitzige Debatten und praktische Beispiele darüber, was Compiler einfach nicht hinbekommen... :)

== Siehe auch ==
* [[AVR Assembler Makros]]
* [[C Makros]]

[[Kategorie:Programmiersprachen]]

Makro

2010-04-22T15:01:54Z

130.75.30.51: /* Vorteile von Inline Funktionen */

Makros sind eine mehr oder weniger große Anzahl von Anweisungen, die unter einer Kurzbezeichnung zu einer Gruppe zusammengefasst sind und als Einheit verwendbar sind. Makros werden i.d.R von [[Assembler]]sprachen angeboten, sind aber auch in einigen [[HLL|höheren Programmiersprachen]] verfügbar etwa in [[C]]/[[C-Plusplus|C++]] durch den [[C-Präprozessor]]. Schließlich gibt es auch reine Makrosprachen (etwa den Makroprozessor m4 von Unix/Linux), die als Werkzeug zur systematischen Transformation von Textdateien eingesetzt werden können.

Hinsichtlich eines Makros ist zu unterscheiden zwischen dessen ''Definition'', i.d.R. einmalig und VOR der ersten Verwendung (evtl. auch in [[Include-Files]]) und dessen ''Verwendungen'' (0-mal bis beliebig oft).

== Allgemeines zu Macros ==

Besonders flexibel sind '''parametrisierbare Makros'''. Die Makro-Definition ist dann als eine Schablone zu sehen, bei der einige Stellen noch offen gehalten wurden, um sie erst später, bei der Makro-Verwendung zu füllen. Bei der Programmierung haben parametrisierbare Makros eine gewisse Ähnlichkeit zu Unterprogrammen (mit Parametern), werden aber anders als diese zum Zeitpunkt der Übersetzung ausgeführt und hinsichtlich der Parameterwerte festgelegt.

Bei der Programmierung von Mikrocontrollern ist es mitunter erforderlich, zwischen der Verwendung von Unterprogrammen und Makros abzuwägen. Universell wiederverwendbare, und deshalb in einer gewissen Umfang noch konfigurierbare Programmteile können in Form von Makros effizienter als Unterprogramme sein. Allerdings müssen die folgenden Voraussetzungen bestehen:
# Der "variable" Teil (= aktuelle Werte der Parameter) muss bei der Kompilierung festgelegt werden können. Sofern dieser Punkt nicht sichergestellt ist, scheiden (parametrisierte) Makros komplett aus.
# Der Makro wird nur ein einziges Mal in genau dieser Form verwendet. Ob die Mehrfachverwendung eines Makros mit identischen Parametern ein Vor- oder Nachteil gegenüber einem Unterprogramm ist, hängt davon ab, was optimiert werden soll. Im Hinblick auf die Ausführungsgeschwindigkeit ist der Makro vorteilhaft, geht es um geringe Code-Größe ist fast immer das Unterprogramm besser. Die Ausnahme von dieser Regel bilden triviale Makros, die weniger Machinen-Code erzeugen als der Befehl für einen Unterprogrammsprung und die notwendige Parameterübergabe.

== Macros vs. Inline Funktionen ==

Anstatt ein Macro zu verwenden, kann eine Funktion auch mit dem Schlüsselwort "inline" versehen werden. Dann erzeugt der Compiler kein Funktionsaufruf, sondern fügt den Code der Inline-Funktion direkt an dieser Stelle ein, an der die Funktion aufgerufen wird. 

=== Vorteile von Inline Funktionen ===
* Typensicherheit Der Compiler kann die Typen der Parameter prüfen und Fehler erkennen. Einem Macro kann eigentlich alles übergeben werden, was dann zu seltsamen Fehlermeldungen beim compilieren oder schlimmer einem seltsamen Programmverhalten führen. Beispiels sind im Artikel [[C-Präprozessor]] zu finden.
* Parameterauswertung Die Parameter werden ausgewertet, bevor die Inline-Funktion aufgerufen wird. Auch hier sei wieder für Beispiele auf den Artikel [[C-Präprozessor]] verwiesen.
* Optimieren Da der Compiler die Typen der Parameter kennt, versteht er möglicherweise, was in der Funktion passiert und kann den gesamten Code besser optimieren.
* Macros sind nur Hacks Macros sollten vermieden werden, da sie das Debuggen erschweren und sie der strukturierten Programmierung widersprechen. Insbesondere komplexe, vermeintlich geniale Macros, können für andere oder für einen selber nach einem halben Jahr schon komplett unverständlich sein.

=== Vorteile von Macros ===
* Textersetzung Macros sind etwas flexibler, da in ihnen bestimme Code-Schnipsel, die oft vorkommen, zusammengefasst werden können. Erst nach dem Einbauen des Macros durch den Preprozessor muss sich gültiger C-Code ergeben. Dadurch können Macros an manchen Stellen sehr flexibel eingesetzt werden.
* Macros sind genial Mit Macros kann man einige Sachen kompakt darstellen und inbesondere lästige Code-Wiederholungen vermeiden bzw. an eine Stelle zentral warten.

== Also jetzt Macros oder Inline-Funktionen? ==
Es ist wohl zum Teil eine Glaubenfrage über die sich lange vortrefflich streiten lässt. Die einen sagen, dass eben schon immer Macros verwendet wurden und sie zu C einfach dazu gehören (und zu Assembler sowieso). Die anderen sehen sie eher als Altlast aus Zeiten an, in der Code in Assember geschrieben wurde, die Compiler schlecht waren und ein Goto nichts böses war.... 
Die Erfahrung bei grösseren Projekten (vor allem im Nicht-uC oder 32-bit uC-Bereich) zeigt aber, dass der Einsatz von Macro mit Bedacht erfolgen sollte. Je abstrakter das Modul wird, desto weniger Macros sollten verwendet werden. Trotzdem sind Macros gerade dann sinnvoll, wenn man direkt an der Hardware programmiert und weit weg von strukturiert objektorientierter Programmierung ist. Um den einen oder anderen von Hand optimierten Hack kommt man dann einfach nicht herum, weil die der Compiler das sonst einfach doch nicht schafft. 
Trotzdem sei an dier Stelle gewarnt, sich in vermeindlich tollen Macro zu verrennen, ohne über das ganze mal eine Nacht zu überschlafen. Jede vermeindliche Optimierung über Macro-Hacks sollte am Ende auch wirklich eine Optimierung sein.

An dieser Stelle erwartet der Autor hitzige Debatten und praktische Beispiele darüber, was Compiler einfach nicht hinbekommen... :)

== Siehe auch ==
* [[AVR Assembler Makros]]
* [[C Makros]]

[[Kategorie:Programmiersprachen]]

Makro

2010-04-22T15:01:38Z

130.75.30.51: /* Vorteile von Inline Funktionen */

Makros sind eine mehr oder weniger große Anzahl von Anweisungen, die unter einer Kurzbezeichnung zu einer Gruppe zusammengefasst sind und als Einheit verwendbar sind. Makros werden i.d.R von [[Assembler]]sprachen angeboten, sind aber auch in einigen [[HLL|höheren Programmiersprachen]] verfügbar etwa in [[C]]/[[C-Plusplus|C++]] durch den [[C-Präprozessor]]. Schließlich gibt es auch reine Makrosprachen (etwa den Makroprozessor m4 von Unix/Linux), die als Werkzeug zur systematischen Transformation von Textdateien eingesetzt werden können.

Hinsichtlich eines Makros ist zu unterscheiden zwischen dessen ''Definition'', i.d.R. einmalig und VOR der ersten Verwendung (evtl. auch in [[Include-Files]]) und dessen ''Verwendungen'' (0-mal bis beliebig oft).

== Allgemeines zu Macros ==

Besonders flexibel sind '''parametrisierbare Makros'''. Die Makro-Definition ist dann als eine Schablone zu sehen, bei der einige Stellen noch offen gehalten wurden, um sie erst später, bei der Makro-Verwendung zu füllen. Bei der Programmierung haben parametrisierbare Makros eine gewisse Ähnlichkeit zu Unterprogrammen (mit Parametern), werden aber anders als diese zum Zeitpunkt der Übersetzung ausgeführt und hinsichtlich der Parameterwerte festgelegt.

Bei der Programmierung von Mikrocontrollern ist es mitunter erforderlich, zwischen der Verwendung von Unterprogrammen und Makros abzuwägen. Universell wiederverwendbare, und deshalb in einer gewissen Umfang noch konfigurierbare Programmteile können in Form von Makros effizienter als Unterprogramme sein. Allerdings müssen die folgenden Voraussetzungen bestehen:
# Der "variable" Teil (= aktuelle Werte der Parameter) muss bei der Kompilierung festgelegt werden können. Sofern dieser Punkt nicht sichergestellt ist, scheiden (parametrisierte) Makros komplett aus.
# Der Makro wird nur ein einziges Mal in genau dieser Form verwendet. Ob die Mehrfachverwendung eines Makros mit identischen Parametern ein Vor- oder Nachteil gegenüber einem Unterprogramm ist, hängt davon ab, was optimiert werden soll. Im Hinblick auf die Ausführungsgeschwindigkeit ist der Makro vorteilhaft, geht es um geringe Code-Größe ist fast immer das Unterprogramm besser. Die Ausnahme von dieser Regel bilden triviale Makros, die weniger Machinen-Code erzeugen als der Befehl für einen Unterprogrammsprung und die notwendige Parameterübergabe.

== Macros vs. Inline Funktionen ==

Anstatt ein Macro zu verwenden, kann eine Funktion auch mit dem Schlüsselwort "inline" versehen werden. Dann erzeugt der Compiler kein Funktionsaufruf, sondern fügt den Code der Inline-Funktion direkt an dieser Stelle ein, an der die Funktion aufgerufen wird. 

=== Vorteile von Inline Funktionen ===
* Typensicherheit Der Compiler kann die Typen der Parameter prüfen und Fehler erkennen. Einem Macro kann eigentlich alles übergeben werden, was dann zu seltsamen Fehlermeldungen beim compilieren oder schlimmer einem seltsamen Programmverhalten führen. Beispiels sind im Artikel [[C-Präprozessor]] zu finden.
* Parameterauswertung Die Parameter werden ausgewertet, bevor die Inline-Funktion aufgerufen wird. Auch hier sei wieder für Beispiele auf den Artikel [[C-Präprozessor]] verwiesen.
* Optimieren Da der Compiler die Typen der Parameter kennt, versteht er möglicherweise, was in der Funktion passiert und kann den gesamten Code besser optimieren.
* Macros sind nur Hacks Macros sollten vermieden werden, da sie das Debuggen erschweren und sie der strukturierten Programmierung widersprechen. Indbesondere komplexe, vermeintlich geniale Macros, können für andere oder für einen selber nach einem halben Jahr schon komplett unverständlich sein.

=== Vorteile von Macros ===
* Textersetzung Macros sind etwas flexibler, da in ihnen bestimme Code-Schnipsel, die oft vorkommen, zusammengefasst werden können. Erst nach dem Einbauen des Macros durch den Preprozessor muss sich gültiger C-Code ergeben. Dadurch können Macros an manchen Stellen sehr flexibel eingesetzt werden.
* Macros sind genial Mit Macros kann man einige Sachen kompakt darstellen und inbesondere lästige Code-Wiederholungen vermeiden bzw. an eine Stelle zentral warten.

== Also jetzt Macros oder Inline-Funktionen? ==
Es ist wohl zum Teil eine Glaubenfrage über die sich lange vortrefflich streiten lässt. Die einen sagen, dass eben schon immer Macros verwendet wurden und sie zu C einfach dazu gehören (und zu Assembler sowieso). Die anderen sehen sie eher als Altlast aus Zeiten an, in der Code in Assember geschrieben wurde, die Compiler schlecht waren und ein Goto nichts böses war.... 
Die Erfahrung bei grösseren Projekten (vor allem im Nicht-uC oder 32-bit uC-Bereich) zeigt aber, dass der Einsatz von Macro mit Bedacht erfolgen sollte. Je abstrakter das Modul wird, desto weniger Macros sollten verwendet werden. Trotzdem sind Macros gerade dann sinnvoll, wenn man direkt an der Hardware programmiert und weit weg von strukturiert objektorientierter Programmierung ist. Um den einen oder anderen von Hand optimierten Hack kommt man dann einfach nicht herum, weil die der Compiler das sonst einfach doch nicht schafft. 
Trotzdem sei an dier Stelle gewarnt, sich in vermeindlich tollen Macro zu verrennen, ohne über das ganze mal eine Nacht zu überschlafen. Jede vermeindliche Optimierung über Macro-Hacks sollte am Ende auch wirklich eine Optimierung sein.

An dieser Stelle erwartet der Autor hitzige Debatten und praktische Beispiele darüber, was Compiler einfach nicht hinbekommen... :)

== Siehe auch ==
* [[AVR Assembler Makros]]
* [[C Makros]]

[[Kategorie:Programmiersprachen]]