https://www.mikrocontroller.net/api.php?action=feedcontributions&feedformat=atom&user=Leo1969
Mikrocontroller.net - Benutzerbeiträge [de]
2026-04-11T18:36:46Z
Benutzerbeiträge
MediaWiki 1.39.7
https://www.mikrocontroller.net/index.php?title=AVR_Net-IO_Bausatz_von_Pollin&diff=50397
AVR Net-IO Bausatz von Pollin
2010-09-05T19:57:01Z
<p>Leo1969: /* Bekannte Fehler */</p>
<hr />
<div>== Einleitung ==<br />
<br />
Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058]<br />
<br />
Eine Liste von Features:<br />
<br />
Ethernet-Platine mit ATMega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.<br />
<br />
Technische Daten:<br />
<br />
* Betriebsspannung 9 V AC/DC<br />
* Stromaufnahme ca. 190 mA<br />
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]<br />
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]<br />
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]<br />
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]<br />
* [[ENC28J60]]<br />
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller<br />
<br />
Maße (LxBxH): 108x76x22 mm.<br />
<br />
== Hardware ==<br />
<br />
[[Bild:AVR-NET-IO.JPG|thumb|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen sind nicht wie vorgesehen angereiht.]]Die Schaltung des AVR-NET-IO ist recht einfach:<br />
* Ein ATmega32 Mikrocontroller enthält die gesamte Software<br />
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden<br />
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.<br />
* Ein MAX232 für die serielle Schnittstelle<br />
* Zwei Spannungsregler, 5 V und 3,3 V<br />
* "Hühnerfutter"<br />
<br />
Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.<br />
<br />
Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man<br />
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter<br />
und sie stehen auch sauber in der Reihe (nicht wie auf dem Foto; die Anschlussklemmen lassen sich sauber durch einen Steg zusammenstecken).<br />
=== Erweiterungsplatine ===<br />
Seit Januar 2010 gibt es auch eine Erweiterungsplatine.<br />
<br />
[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]<br />
<br />
Diese Platine erweitert das NET-IO um:<br />
<br />
* SD-Karten-Slot über SPI<br />
* Display über PCF 8574<br />
* Infrarot<br />
* RFM12 Funkmodul (nicht im Lieferumfang enthalten)<br />
<br />
Ausserdem soll es die 3.3V Versorgung der Hauptplatine verbessern. Dazu sollte man einen 4,7 kOhm Widerstand parallel zu R2 schalten. Sonst beträgt die Ausgangsspannung nur ca. 2,8V. (Tipp aus dem u.g. Thread im Forum)<br />
<br />
Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:<br />
*R2 1,5K ersetzen mit 2K<br />
*R3 1,8K ersetzen mit 3,3K<br />
*R19 470K ersetzen zu 470Ohm<br />
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache NPN! und mehr als 100mA)<br />
<br />
ISP-Anschluß nicht vollständig durchgeschleift. Keine Verbindung der RESET-Leitung zwischen ISP und ISP1.<br />
<br />
Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354<br />
<br />
=== Hardware-Umbauten & -Verbesserungen ===<br />
<br />
* Kühlkörper auf dem 7805<br />
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen<br />
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.<br />
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen. <br />
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen <br />
* Vorwiderstände der Ethernet-LEDs größer machen (z.&nbsp;B. verdoppeln) um Strom zu sparen<br />
* Linear-Spannungsregler ersetzen<br />
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)<br />
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig.<br />
* Umbau auf 3,3 V:<br />
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler<br />
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb<br />
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )<br />
** Ersatz des MAX232 durch einen MAX3232<br />
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]<br />
* ATmega32 vom ENC28J60 takten (OSC2)<br />
* Betrieb mit Gleichspannung:<br />
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)<br />
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)<br />
* Ersatz des ATmega32 durch einen ATmega644 mit mehr FLASH-Speicher.<br />
<br />
== Inbetriebnahme der Originalsoftware ==<br />
=== Einleitung ===<br />
<br />
Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die seriell Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal einen Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt. <br />
<br />
Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:<br />
<br />
* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)<br />
* Entweder<br />
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder<br />
**ein gekreuztes(''cross over'') Ethernet-Kabel<br />
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].<br />
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)<br />
<br />
=== Gelieferten ATmega32 richtig einstellen ===<br />
<br />
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.<br />
<br />
Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.<br />
<br />
Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.<br />
<br />
==== Funktionsfähige Konfiguration - AVR-Prog ====<br />
<br />
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein. <br />
<br />
[[Bild:Avrprog.png]]<br />
<br />
Alternativ kann auch per avrdude die Einstellung getroffen werden:<br />
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m und <br />
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m<br />
<br />
Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).<br />
<br />
=== PC Konfiguration ===<br />
<br />
==== PC normalerweise nicht im 192.168.0/24 Subnetz ====<br />
<br />
Betreibt man den PC normalerweise nicht im 192.168.0/24 Subnetz, muss er wie folgt umkonfiguriert werden.<br />
<br />
Den PC vom normalen Netzwerk abstecken. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen. <br />
<br />
Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.<br />
<br />
In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel<br />
<br />
IP-Adresse: '''192.168.0.100'''<br><br />
Subnetzmaske: '''255.255.255.0'''<br><br />
Standardgateway: '''192.168.0.1'''<br />
<br />
eingeben. <br />
<br />
Alle geöffneten Dialoge nacheinander mit OK schließen.<br />
<br />
Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.<br />
<br />
Im EEPROM sind folgende Werte vorprogrammiert:<br><br><br />
3EE - 3F3 MAC-ADRESSE<br><br />
3F4 - 3F7 GATEWAY<br><br />
3F8 - 3FC NETMASK<br><br />
3FD - 3FF IP-ADRESSE<br><br />
<br />
==== PC bereits im 192.168.0/24 Subnetz ====<br />
<br />
In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.<br />
<br />
Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.<br />
<br />
=== AVR-NET-IO anschließen ===<br />
<br />
Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.<br />
<br />
Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.<br />
<br />
Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.<br />
<br />
=== Firmware 1.03 einspielen ===<br />
<br />
Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.<br />
<br />
Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.<br />
<br />
=== Abschluss ===<br />
<br />
Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.<br />
<br />
Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.<br />
<br />
== Bekannte Fehler ==<br />
<br />
Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]]<br />
<br />
* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben<br />
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)<br />
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)<br />
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.<br />
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen<br />
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)<br />
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)<br />
** ''Stand 03.09.2008, online, #all, wpe'' (Online)<br />
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.<br />
<br />
* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])<br />
<br />
* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.<br />
<br />
* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])<br />
<br />
* Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]<br />
<br />
* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.<br />
<br />
* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt.<br />
<br />
* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert<br />
<br />
* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.<br />
<br />
* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.<br />
<br />
* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.<br />
<br />
* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.<br />
<br />
* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.<br />
<br />
* Bausatz Juli '09 gekauft, grüne statt rote LED<br />
<br />
* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!<br />
<br />
* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.<br />
<br />
* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft<br />
<br />
* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.<br />
<br />
* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche<br />
<br />
*Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig<br />
<br />
* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.<br />
<br />
* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt<br />
<br />
* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.<br />
<br />
* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!<br />
<br />
* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.<br />
<br />
* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10uF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1uF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.<br />
<br />
* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte<br />
<br />
* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme<br />
<br />
* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung<br />
<br />
* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX<br />
<br />
* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.<br />
<br />
* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert<br />
<br />
* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel<br />
<br />
* Bausatz August 10 gekauft: komplett und sofort funktioniert<br />
<br />
== Andere Software für den Client-PC ==<br />
=== NetIOLib ===<br />
<br />
In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL) <br />
<br />
<br />
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]<br />
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]<br />
<br />
=== ControlIO ===<br />
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.<br />
http://www.mikrocontroller.net/topic/149695<br />
<br />
=== JAVA Lib ===<br />
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.<br />
http://son.ffdf-clan.de/?path=forumsthread&threadid=611<br />
<br />
== Andere Software statt der Originalsoftware von Pollin ==<br />
<br />
Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.<br />
<br />
=== Bascom Version von Hütti ===<br />
<br />
(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )<br />
dort am Ende der Seite.<br />
<br />
=== Ben's Bascom Quellcode ===<br />
<br />
(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )<br />
<br />
Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !<br />
<br />
=== U. Radigs Webserver ===<br />
<br />
Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex<br />
oder selbst anpassen: <br />
Ändere im File ENC28J60.H<br />
#define ENC28J60_PIN_SS 3<br />
#define ENC28J60_PIN_CS 4<br />
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)<br />
<br />
Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.<br />
<br />
IP: 192.168.0.99<br><br />
User: admin<br><br />
Pass: uli1<br><br />
<br />
Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex<br />
<br />
Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.<br />
<br />
Wer gerne als Link-LED die grüne nutzen möchte<br />
(U.Radig-Source)<br />
<br />
enc28j60.c Zeile 150<br />
<br />
"enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A)<br />
<br />
Wert 0x347A in 0x374A ändern<br />
<br />
(Quelle: http://www.mikrocontroller.net/topic/109988#994943)<br />
<br />
IP: 192.168.1.90<br><br />
User: admin<br><br />
Pass: tim<br><br />
Test: http://beitz-online.dyndns.org<br><br />
Test: http://pieper-online.dyndns.org<br><br />
<br />
Weiterentwicklung des Radig-Codes von RoBue: <br><br />
- 1-Wire-Unterstützung (Anschlus an PORTA7) <br><br />
- PORTA0-3 digitaler Eingang (ein/aus) <br><br />
- PORTA4-6 analoger Eingang (0 - 1023) <br><br />
- LCD an PORTC <br><br />
- Schalten in Abhängigkeit von Temperatur und analogem Wert <br><br />
- (Teilweise) Administration über Weboberfläche <br><br />
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 <br><br />
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) <br><br />
<br />
Test: http://avrboard.eluhost.de/<br><br />
<br />
(Quelle:<br><br />
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip<br><br />
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip<br><br />
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)<br />
<br />
Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P<br />
<br />
=== Simon Ks Webserver (uip-Stack) ===<br />
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip<br />
IP: 192.168.0.93:8080<br><br />
<br />
=== Ethersex Server ===<br />
<br />
http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.<br />
<br />
Oder <br />
[http://www.ethersex.de/firmware-builder/list.cgi hier] ein Firmware Image passend für das Pollin Net-IO mit eingebautem Webserver und Beispieldateien im Flash bauen lassen und flashen (firmware-builder). Einfacher geht´s nimmer. :-)<br />
<br />
=== Etherrape Server ===<br />
<br />
http://www.lochraster.org/etherrape/ <br />
<br />
ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.<br />
Es scheint aber bei der Weiterentwicklung wenig zu passieren.<br />
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape<br />
<br />
=== Mini SRCP Server (kommerziell, Closed-Source)===<br />
<br />
Damit wird die Platine zu einer Modellbahnsteuerung, die<br />
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen<br />
gesteuert werden kann.<br />
<br />
[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware<br />
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].<br />
<br />
=== AvrArtNode ===<br />
<br />
Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.<br />
<br />
Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]<br />
<br />
=== Webserver von G. Menke ===<br />
<br />
Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:<br />
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]<br />
<br />
=== OpenMCP ===<br />
<br />
Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt das viel Arbeit und Liebe in diesen Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-System welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.<br />
<br />
Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.<br />
<br />
[http://wiki.neo-guerillaz.de Projekt und Doku]<br />
<br />
Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.<br />
<br />
=== ENC28J60 I/O-Webserver von Thomas Heldt ===<br />
<br />
Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:<br />
<br />
[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]<br />
<br />
== Siehe auch ==<br />
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988<br />
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]<br />
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]<br />
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]<br />
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]<br />
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]<br />
<br />
[[Category:AVR-Boards]]<br />
[[Category:Ethernet|P]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=AVR_Net-IO_Bausatz_von_Pollin&diff=50396
AVR Net-IO Bausatz von Pollin
2010-09-05T19:56:31Z
<p>Leo1969: /* Bekannte Fehler */</p>
<hr />
<div>== Einleitung ==<br />
<br />
Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058]<br />
<br />
Eine Liste von Features:<br />
<br />
Ethernet-Platine mit ATMega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.<br />
<br />
Technische Daten:<br />
<br />
* Betriebsspannung 9 V AC/DC<br />
* Stromaufnahme ca. 190 mA<br />
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]<br />
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]<br />
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]<br />
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]<br />
* [[ENC28J60]]<br />
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller<br />
<br />
Maße (LxBxH): 108x76x22 mm.<br />
<br />
== Hardware ==<br />
<br />
[[Bild:AVR-NET-IO.JPG|thumb|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen sind nicht wie vorgesehen angereiht.]]Die Schaltung des AVR-NET-IO ist recht einfach:<br />
* Ein ATmega32 Mikrocontroller enthält die gesamte Software<br />
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden<br />
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.<br />
* Ein MAX232 für die serielle Schnittstelle<br />
* Zwei Spannungsregler, 5 V und 3,3 V<br />
* "Hühnerfutter"<br />
<br />
Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.<br />
<br />
Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man<br />
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter<br />
und sie stehen auch sauber in der Reihe (nicht wie auf dem Foto; die Anschlussklemmen lassen sich sauber durch einen Steg zusammenstecken).<br />
=== Erweiterungsplatine ===<br />
Seit Januar 2010 gibt es auch eine Erweiterungsplatine.<br />
<br />
[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]<br />
<br />
Diese Platine erweitert das NET-IO um:<br />
<br />
* SD-Karten-Slot über SPI<br />
* Display über PCF 8574<br />
* Infrarot<br />
* RFM12 Funkmodul (nicht im Lieferumfang enthalten)<br />
<br />
Ausserdem soll es die 3.3V Versorgung der Hauptplatine verbessern. Dazu sollte man einen 4,7 kOhm Widerstand parallel zu R2 schalten. Sonst beträgt die Ausgangsspannung nur ca. 2,8V. (Tipp aus dem u.g. Thread im Forum)<br />
<br />
Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:<br />
*R2 1,5K ersetzen mit 2K<br />
*R3 1,8K ersetzen mit 3,3K<br />
*R19 470K ersetzen zu 470Ohm<br />
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache NPN! und mehr als 100mA)<br />
<br />
ISP-Anschluß nicht vollständig durchgeschleift. Keine Verbindung der RESET-Leitung zwischen ISP und ISP1.<br />
<br />
Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354<br />
<br />
=== Hardware-Umbauten & -Verbesserungen ===<br />
<br />
* Kühlkörper auf dem 7805<br />
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen<br />
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.<br />
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen. <br />
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen <br />
* Vorwiderstände der Ethernet-LEDs größer machen (z.&nbsp;B. verdoppeln) um Strom zu sparen<br />
* Linear-Spannungsregler ersetzen<br />
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)<br />
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig.<br />
* Umbau auf 3,3 V:<br />
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler<br />
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb<br />
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )<br />
** Ersatz des MAX232 durch einen MAX3232<br />
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]<br />
* ATmega32 vom ENC28J60 takten (OSC2)<br />
* Betrieb mit Gleichspannung:<br />
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)<br />
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)<br />
* Ersatz des ATmega32 durch einen ATmega644 mit mehr FLASH-Speicher.<br />
<br />
== Inbetriebnahme der Originalsoftware ==<br />
=== Einleitung ===<br />
<br />
Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die seriell Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal einen Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt. <br />
<br />
Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:<br />
<br />
* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)<br />
* Entweder<br />
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder<br />
**ein gekreuztes(''cross over'') Ethernet-Kabel<br />
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].<br />
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)<br />
<br />
=== Gelieferten ATmega32 richtig einstellen ===<br />
<br />
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.<br />
<br />
Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.<br />
<br />
Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.<br />
<br />
==== Funktionsfähige Konfiguration - AVR-Prog ====<br />
<br />
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein. <br />
<br />
[[Bild:Avrprog.png]]<br />
<br />
Alternativ kann auch per avrdude die Einstellung getroffen werden:<br />
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m und <br />
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m<br />
<br />
Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).<br />
<br />
=== PC Konfiguration ===<br />
<br />
==== PC normalerweise nicht im 192.168.0/24 Subnetz ====<br />
<br />
Betreibt man den PC normalerweise nicht im 192.168.0/24 Subnetz, muss er wie folgt umkonfiguriert werden.<br />
<br />
Den PC vom normalen Netzwerk abstecken. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen. <br />
<br />
Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.<br />
<br />
In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel<br />
<br />
IP-Adresse: '''192.168.0.100'''<br><br />
Subnetzmaske: '''255.255.255.0'''<br><br />
Standardgateway: '''192.168.0.1'''<br />
<br />
eingeben. <br />
<br />
Alle geöffneten Dialoge nacheinander mit OK schließen.<br />
<br />
Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.<br />
<br />
Im EEPROM sind folgende Werte vorprogrammiert:<br><br><br />
3EE - 3F3 MAC-ADRESSE<br><br />
3F4 - 3F7 GATEWAY<br><br />
3F8 - 3FC NETMASK<br><br />
3FD - 3FF IP-ADRESSE<br><br />
<br />
==== PC bereits im 192.168.0/24 Subnetz ====<br />
<br />
In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.<br />
<br />
Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.<br />
<br />
=== AVR-NET-IO anschließen ===<br />
<br />
Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.<br />
<br />
Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.<br />
<br />
Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.<br />
<br />
=== Firmware 1.03 einspielen ===<br />
<br />
Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.<br />
<br />
Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.<br />
<br />
=== Abschluss ===<br />
<br />
Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.<br />
<br />
Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.<br />
<br />
== Bekannte Fehler ==<br />
<br />
Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]]<br />
<br />
* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben<br />
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)<br />
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)<br />
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.<br />
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen<br />
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)<br />
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)<br />
** ''Stand 03.09.2008, online, #all, wpe'' (Online)<br />
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.<br />
<br />
* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])<br />
<br />
* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.<br />
<br />
* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])<br />
<br />
* Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]<br />
<br />
* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.<br />
<br />
* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt.<br />
<br />
* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert<br />
<br />
* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.<br />
<br />
* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.<br />
<br />
* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.<br />
<br />
* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.<br />
<br />
* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.<br />
<br />
* Bausatz Juli '09 gekauft, grüne statt rote LED<br />
<br />
* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!<br />
<br />
* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.<br />
<br />
* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft<br />
<br />
* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.<br />
<br />
* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche<br />
<br />
*Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig<br />
<br />
* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.<br />
<br />
* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt<br />
<br />
* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.<br />
<br />
* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!<br />
<br />
* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.<br />
<br />
* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10uF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1uF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.<br />
<br />
* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte<br />
<br />
* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme<br />
<br />
* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung<br />
<br />
* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX<br />
<br />
* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.<br />
<br />
* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert<br />
<br />
* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel<br />
<br />
* Bausatz August 10 gekauf: komplett, sofort funktioniert<br />
<br />
== Andere Software für den Client-PC ==<br />
=== NetIOLib ===<br />
<br />
In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL) <br />
<br />
<br />
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]<br />
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]<br />
<br />
=== ControlIO ===<br />
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.<br />
http://www.mikrocontroller.net/topic/149695<br />
<br />
=== JAVA Lib ===<br />
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.<br />
http://son.ffdf-clan.de/?path=forumsthread&threadid=611<br />
<br />
== Andere Software statt der Originalsoftware von Pollin ==<br />
<br />
Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.<br />
<br />
=== Bascom Version von Hütti ===<br />
<br />
(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )<br />
dort am Ende der Seite.<br />
<br />
=== Ben's Bascom Quellcode ===<br />
<br />
(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )<br />
<br />
Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !<br />
<br />
=== U. Radigs Webserver ===<br />
<br />
Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex<br />
oder selbst anpassen: <br />
Ändere im File ENC28J60.H<br />
#define ENC28J60_PIN_SS 3<br />
#define ENC28J60_PIN_CS 4<br />
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)<br />
<br />
Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.<br />
<br />
IP: 192.168.0.99<br><br />
User: admin<br><br />
Pass: uli1<br><br />
<br />
Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex<br />
<br />
Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.<br />
<br />
Wer gerne als Link-LED die grüne nutzen möchte<br />
(U.Radig-Source)<br />
<br />
enc28j60.c Zeile 150<br />
<br />
"enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A)<br />
<br />
Wert 0x347A in 0x374A ändern<br />
<br />
(Quelle: http://www.mikrocontroller.net/topic/109988#994943)<br />
<br />
IP: 192.168.1.90<br><br />
User: admin<br><br />
Pass: tim<br><br />
Test: http://beitz-online.dyndns.org<br><br />
Test: http://pieper-online.dyndns.org<br><br />
<br />
Weiterentwicklung des Radig-Codes von RoBue: <br><br />
- 1-Wire-Unterstützung (Anschlus an PORTA7) <br><br />
- PORTA0-3 digitaler Eingang (ein/aus) <br><br />
- PORTA4-6 analoger Eingang (0 - 1023) <br><br />
- LCD an PORTC <br><br />
- Schalten in Abhängigkeit von Temperatur und analogem Wert <br><br />
- (Teilweise) Administration über Weboberfläche <br><br />
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 <br><br />
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) <br><br />
<br />
Test: http://avrboard.eluhost.de/<br><br />
<br />
(Quelle:<br><br />
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip<br><br />
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip<br><br />
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)<br />
<br />
Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P<br />
<br />
=== Simon Ks Webserver (uip-Stack) ===<br />
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip<br />
IP: 192.168.0.93:8080<br><br />
<br />
=== Ethersex Server ===<br />
<br />
http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.<br />
<br />
Oder <br />
[http://www.ethersex.de/firmware-builder/list.cgi hier] ein Firmware Image passend für das Pollin Net-IO mit eingebautem Webserver und Beispieldateien im Flash bauen lassen und flashen (firmware-builder). Einfacher geht´s nimmer. :-)<br />
<br />
=== Etherrape Server ===<br />
<br />
http://www.lochraster.org/etherrape/ <br />
<br />
ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.<br />
Es scheint aber bei der Weiterentwicklung wenig zu passieren.<br />
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape<br />
<br />
=== Mini SRCP Server (kommerziell, Closed-Source)===<br />
<br />
Damit wird die Platine zu einer Modellbahnsteuerung, die<br />
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen<br />
gesteuert werden kann.<br />
<br />
[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware<br />
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].<br />
<br />
=== AvrArtNode ===<br />
<br />
Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.<br />
<br />
Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]<br />
<br />
=== Webserver von G. Menke ===<br />
<br />
Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:<br />
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]<br />
<br />
=== OpenMCP ===<br />
<br />
Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt das viel Arbeit und Liebe in diesen Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-System welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.<br />
<br />
Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.<br />
<br />
[http://wiki.neo-guerillaz.de Projekt und Doku]<br />
<br />
Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.<br />
<br />
=== ENC28J60 I/O-Webserver von Thomas Heldt ===<br />
<br />
Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:<br />
<br />
[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]<br />
<br />
== Siehe auch ==<br />
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988<br />
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]<br />
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]<br />
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]<br />
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]<br />
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]<br />
<br />
[[Category:AVR-Boards]]<br />
[[Category:Ethernet|P]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=STK500&diff=42916
STK500
2010-02-06T12:34:51Z
<p>Leo1969: Änderung 42902 von Mthomas (Diskussion) wurde rückgängig gemacht.</p>
<hr />
<div>__NOTOC__<br />
Das STK500 ist ein [[AVR]]-Starterkit von Atmel. Im Gegensatz zu seinem Vorgänger ([[STK200]]) erfolgt die Programmierung beim STK500 nicht über einen Parallelport-Adapter sondern über eine [[RS-232]]-Schnittstelle.<br />
<br />
Auf der Platine sind unter anderem zwei RS-232-Stecker - einer für die Programmierung, ein zweiter vom programmierten Mikrocontroller verwendbar -, Sockel für AVRs in der [[IC-Gehäuseformen#DIP.2FDIL|DIP]]-Version, acht Leuchtdioden und acht Schalter angebracht.<br />
<br />
Die älteren STK500-Boards verfügten noch über ein [[SPI]]-programmierbares [[Flash-ROM]] (DataFlash), das aber nun nicht mehr bestückt wird, da es nicht mehr produziert wird und kein pinkompatibler Ersatz existiert.<br />
<br />
=== Deutschsprachige Bedienungsanleitung des STK500 ===<br />
<br />
Im Forum wird immer wieder nach einer deutschen Version des STK500 Handbuches gefragt. Eine übersetzte Version gibt es z.B. hier: http://www.mikrocontroller.net/attachment/42741/STK500-HW-Beschreibung.pdf<br />
<br />
<br />
[[Bild:STK500.jpg]]<br />
©2010 by Atmel Corporation<br />
<br />
== Erweiterungsplatinen ==<br />
<br />
=== STK501 ===<br />
[[Bild:STK501.jpg]]<br />
©2010 by Atmel Corporation<br />
<br />
für AVRs im 64 Pin [[IC-Gehäuseformen#QFP|QFP]]-Gehäuse (ATmega103, ATmega128)<br />
<br />
=== STK502 ===<br />
[[Bild:STK502.jpg]]<br />
©2010 Atmel Corporation<br />
<br />
für ATmega169, mit LCD<br />
<br />
=== STK503 ===<br />
[[Bild:STK503.jpg]]<br />
©2010 by Atmel Corporation<br />
<br />
für AVRs im 100 Pin [[IC-Gehäuseformen#TQFP|QFP]]-Gehäuse (ATmega640, ATmega1280)<br />
<br />
=== STK504 ===<br />
[[Bild:STK504.jpg]]<br />
©2010 by Atmel Corporation<br />
<br />
für LCD AVRs im 100 Pin [[IC-Gehäuseformen#TQFP|QFP]]-Gehäuse<br />
<br />
=== STK505 ===<br />
[[Bild:STK505.gif]]<br />
©2010 by Atmel Corporation<br />
<br />
für 14 und 20 PIN AVR Mikrocontroller<br />
<br />
=== STK520 ===<br />
[[Bild:STK520.jpg]]<br />
©2010 by Atmel Corporation<br />
<br />
für AT90PWM<br />
<br />
=== STK525 ===<br />
[[Bild:STK525.gif]]<br />
©2010 by Atmel Corporation<br />
<br />
für AT90USBxxx<br />
<br />
=== RZ502 ===<br />
[[Bild:RZ502.jpg]]<br />
©2010 by Atmel Corporation<br />
<br />
ATAVRRZ502 IEEE 802.15.4/ZigBee RF Accessory Kit / ermöglicht eine Punkt-zu-Punkt Funkverbindungsentwicklung, -Debugging und -Demonstration.<br />
<br />(Benötigt für Entwicklung neben STK500 auch das STK501)<br />
<br />
=== ADAPCAN01 ===<br />
[[Bild:ADAPCAN01.jpg]]<br />
©2010 by Atmel Corporation<br />
<br />
für AT90CAN128 / Can-Bus-Entwicklung<br />
<br />(Benötigt für Entwicklung neben STK500 auch das STK501)<br />
<br />
=== DVK90CAN1 ===<br />
[[Bild:ATDVK90CAN1.jpg]]<br />
©2010 by Atmel Corporation<br />
<br />
für AT90CAN / Can-Bus-Entwicklung<br />
<br />(Kann laut Hersteller neben dem STK500 auch eigenständig betrieben werden)<br />
<br />
==Siehe auch==<br />
[[STK500USB-Adapter]]<br />
<br />
== Web-Links ==<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735 STK500]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2926 STK501]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2906 STK502]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3569 STK503]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3553 STK504]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3768 STK505]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3625 STK520]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3878 STK525]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3945 RZ502]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3390 ADAPCAN01]<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3683 DVK90CAN1]<br />
<br />
== Bezugsquellen ==<br />
<br />
* [http://shop.mikrocontroller.net/?product_id=174 STK500] shop.mikrocontroller.net (Embedded Projects)<br />
<br />
* [http://www.sander-electronic.de/es0003.html STK500 bis STK504] (Sander Electronic)<br />
<br />
* [http://www.reichelt.de/?ARTICLE=34093 STK500] (Reichelt)<br />
* [http://www.reichelt.de/?ARTICLE=45039 STK501] (Reichelt)<br />
* [http://www.reichelt.de/?ARTICLE=50560 STK502] (Reichelt)<br />
<br />
* [http://www.avr-tools.de/component/page,shop.product_details/flypage,shop.flypage_avr/product_id,32/category_id,9/manufacturer_id,0/option,com_virtuemart/Itemid,1/ STK500] (Bergmann-Electronics (AVR Tools))<br />
* [http://www.avr-tools.de/component/page,shop.product_details/category_id,9/flypage,shop.flypage_avr/product_id,33/option,com_virtuemart/Itemid,1/ STK501] (Bergmann-Electronics (AVR Tools))<br />
* [http://www.avr-tools.de/component/page,shop.product_details/category_id,9/flypage,shop.flypage_avr/product_id,34/option,com_virtuemart/Itemid,1/ STK502] (Bergmann-Electronics (AVR Tools))<br />
* [http://www.avr-tools.de/component/page,shop.product_details/flypage,shop.flypage_avr/product_id,87/category_id,9/manufacturer_id,0/option,com_virtuemart/Itemid,1/ STK503] (Bergmann-Electronics (AVR Tools))<br />
* [http://www.avr-tools.de/component/page,shop.product_details/flypage,shop.flypage_avr/product_id,88/category_id,9/manufacturer_id,0/option,com_virtuemart/Itemid,1/ STK520] (Bergmann-Electronics (AVR Tools))<br />
* [http://www.avr-tools.de/component/page,shop.product_details/flypage,shop.flypage_avr/product_id,58/category_id,9/manufacturer_id,0/option,com_virtuemart/Itemid,1/ DVK90CAN1] (Bergmann-Electronics (AVR Tools))<br />
<br />
* [http://cgi.segor.de/user-cgi-bin/sidestep2.pl?foto=1&Q=STK500&M=1 STK500 + Erw. Übersicht] (Segor)<br />
* [http://cgi.segor.de/user-cgi-bin/sidestep2.pl?foto=1&Q=ATSTK+501&M=1 STK501] (Segor)<br />
* [http://cgi.segor.de/user-cgi-bin/sidestep2.pl?foto=1&Q=AT+STK502&M=1 STK502] (Segor)<br />
* [http://cgi.segor.de/user-cgi-bin/sidestep2.pl?foto=1&Q=AT+STK503&M=1 STK503] (Segor)<br />
* [http://cgi.segor.de/user-cgi-bin/sidestep2.pl?foto=1&Q=STK525&M=1 STK525] (Segor)<br />
<br />
* [http://www.watterott.com/Atmel-STK500 STK500] (Watterott electronic)<br />
<br />
[[Category:AVR-Boards]]<br />
[[Category:Starterkits]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=AVR_Net-IO_Bausatz_von_Pollin&diff=42513
AVR Net-IO Bausatz von Pollin
2010-01-23T21:08:19Z
<p>Leo1969: /* Bekannte Fehler */</p>
<hr />
<div>== Einleitung ==<br />
<br />
Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058]<br />
<br />
Eine Liste von Features:<br />
<br />
Ethernet-Platine mit ATMega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.<br />
<br />
Technische Daten:<br />
<br />
* Betriebsspannung 9 V AC/DC<br />
* Stromaufnahme ca. 190 mA<br />
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]<br />
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]<br />
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]<br />
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]<br />
* [[ENC28J60]]<br />
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller<br />
<br />
Maße (LxBxH): 108x76x22 mm.<br />
<br />
== Hardware ==<br />
<br />
[[Bild:AVR-NET-IO.JPG|thumb|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen sind nicht wie vorgesehen angereiht.]]Die Schaltung des AVR-NET-IO ist recht einfach:<br />
* Ein ATmega32 Mikrocontroller enthält die gesamte Software<br />
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden<br />
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.<br />
* Ein MAX232 für die serielle Schnittstelle<br />
* Zwei Spannungsregler, 5 V und 3,3 V<br />
* "Hühnerfutter"<br />
<br />
Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Sie sind nicht(!) besonders geschützt, es finden sich zum Beispiel keine Schutzdioden für die Pins in der Schaltung.<br />
<br />
Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man<br />
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter<br />
und sie stehen auch sauber in der Reihe (nicht wie auf dem Foto; die Anschlussklemmen lassen sich sauber durch einen Steg zusammenstecken).<br />
=== Erweiterungsplatine ===<br />
Seit Januar 2010 gibt es auch eine Erweiterungsplatine. Diese Platine erweitert das NET-IO um einen SD-Karten-Slot, Infrarot, Anschlussmöglichkeiten für ein Display. Ausserdem soll es die 3.3V Versorgung der Hauptplatine verbessern.<br />
<br />
http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html<br />
<br />
Bisher gibt es aber noch keine Erfahrungsberichte.<br />
=== Hardware-Umbauten & -Verbesserungen ===<br />
<br />
* Kühlkörper auf dem 7805<br />
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen<br />
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.<br />
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen. <br />
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen <br />
* Vorwiderstände der Ethernet-LEDs größer machen (z.B. verdoppeln) um Strom zu sparen<br />
* Linear-Spannungsregler ersetzen<br />
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)<br />
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig.<br />
* Umbau auf 3,3 V:<br />
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler<br />
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb<br />
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )<br />
** Ersatz des MAX232 durch einen MAX3232<br />
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]<br />
* ATmega32 vom ENC28J60 takten (OSC2)<br />
* Betrieb mit Gleichspannung:<br />
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)<br />
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)<br />
* Ersatz des ATmega32 durch einen ATmega644 mit mehr FLASH-Speicher.<br />
<br />
== Inbetriebnahme der Originalsoftware ==<br />
=== Einleitung ===<br />
<br />
Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann weder die serielle Schnittstelle, noch die Netzwerkschnittstelle zu funktionieren. Falls es Probleme geben sollte kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:<br />
<br />
* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)<br />
* Entweder<br />
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder<br />
**ein gekreuztes(''cross over'') Ethernet-Kabel<br />
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].<br />
* Die [http://www.pollin.de/shop/shop.php?cf=downloads_suchergebnis.php&fp=OA==&pg=NQ==&a=MTQ5OTgxOTk= Pollin NetServer Software], Version 1.01 (oder neuer)<br />
<br />
=== Gelieferten ATmega32 richtig einstellen ===<br />
<br />
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.<br />
<br />
Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.<br />
<br />
Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert. Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.<br />
<br />
==== Funktionsfähige Konfiguration - AVR-Prog ====<br />
<br />
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein. <br />
<br />
[[Bild:Avrprog.png]]<br />
<br />
Alternativ kann auch per avrdude die Einstellung getroffen werden:<br />
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m und <br />
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m<br />
<br />
Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).<br />
<br />
=== PC Konfiguration ===<br />
<br />
==== PC normalerweise nicht im 192.168.0/24 Subnetz ====<br />
<br />
Betreibt man den PC normalerweise nicht im 192.168.0/24 Subnetz, muss er wie folgt umkonfiguriert werden.<br />
<br />
Den PC vom normalen Netzwerk abstecken. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen. <br />
<br />
Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.<br />
<br />
In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel<br />
<br />
IP-Adresse: '''192.168.0.100'''<br><br />
Subnetzmaske: '''255.255.255.0'''<br><br />
Standardgateway: '''192.168.0.1'''<br />
<br />
eingeben. <br />
<br />
Alle geöffneten Dialoge nacheinander mit OK schließen.<br />
<br />
Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.<br />
<br />
Im EEPROM sind folgende Werte vorprogrammiert:<br><br><br />
3EE - 3F3 MAC-ADRESSE<br><br />
3F4 - 3F7 GATEWAY<br><br />
3F8 - 3FC NETMASK<br><br />
3FD - 3FF IP-ADRESSE<br><br />
<br />
==== PC bereits im 192.168.0/24 Subnetz ====<br />
<br />
In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.<br />
<br />
Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.<br />
<br />
=== AVR-NET-IO anschließen ===<br />
<br />
Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.<br />
<br />
Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.<br />
<br />
Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.<br />
<br />
=== Firmware 1.01 einspielen ===<br />
<br />
Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.<br />
<br />
Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.01 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.<br />
<br />
=== Abschluss ===<br />
<br />
Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.<br />
<br />
Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.<br />
<br />
== Bekannte Fehler ==<br />
<br />
Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]]<br />
<br />
* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben<br />
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)<br />
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)<br />
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.<br />
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen<br />
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)<br />
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)<br />
** ''Stand 03.09.2008, online, #all, wpe'' (Online)<br />
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.<br />
<br />
* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])<br />
<br />
* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.<br />
<br />
* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])<br />
<br />
* Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]<br />
<br />
* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.<br />
<br />
* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt.<br />
<br />
* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert<br />
<br />
* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.<br />
<br />
* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.<br />
<br />
* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.<br />
<br />
* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.<br />
<br />
* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.<br />
<br />
* Bausatz Juli '09 gekauft, grüne statt rote LED<br />
<br />
* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!<br />
<br />
* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.<br />
<br />
* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft<br />
<br />
* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.<br />
<br />
* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche<br />
<br />
*Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig<br />
<br />
* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.<br />
<br />
* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt<br />
<br />
* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.<br />
<br />
== Andere Software für den Client-PC ==<br />
=== NetIOLib ===<br />
<br />
In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL) <br />
<br />
<br />
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]<br />
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]<br />
<br />
=== ControlIO ===<br />
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.<br />
http://www.mikrocontroller.net/topic/149695<br />
<br />
== Andere Software statt der Originalsoftware von Pollin ==<br />
<br />
Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an.<br />
<br />
=== Bascom Version von Hütti ===<br />
<br />
(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )<br />
dort am Ende der Seite.<br />
<br />
=== Ben's Bascom Quellcode ===<br />
<br />
(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )<br />
<br />
Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !<br />
<br />
=== U. Radigs Webserver ===<br />
<br />
Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex<br />
oder selbst anpassen: <br />
Ändere im File ENC28J60.H<br />
#define ENC28J60_PIN_SS 3<br />
#define ENC28J60_PIN_CS 4<br />
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)<br />
<br />
Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.<br />
<br />
IP: 192.168.0.99<br><br />
User: admin<br><br />
Pass: uli1<br><br />
<br />
Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex<br />
<br />
Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.<br />
<br />
Wer gerne als Link-LED die grüne nutzen möchte<br />
(U.Radig-Source)<br />
<br />
enc28j60.c Zeile 150<br />
<br />
"enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A)<br />
<br />
Wert 0x347A in 0x374A ändern<br />
<br />
(Quelle: http://www.mikrocontroller.net/topic/109988#994943)<br />
<br />
IP: 192.168.1.90<br><br />
User: admin<br><br />
Pass: tim<br><br />
Test: http://beitz-online.dyndns.org<br><br />
Test: http://pieper-online.dyndns.org<br><br />
<br />
Weiterentwicklung des Radig-Codes von RoBue: <br><br />
- 1-Wire-Unterstützung (Anschlus an PORTA7) <br><br />
- PORTA0-3 digitaler Eingang (ein/aus) <br><br />
- PORTA4-6 analoger Eingang (0 - 1023) <br><br />
- LCD an PORTC <br><br />
- Schalten in Abhängigkeit von Temperatur und analogem Wert <br><br />
- (Teilweise) Administration über Weboberfläche <br><br />
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 <br><br />
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) <br><br />
<br />
Test: http://df8jb.dyndns.org/<br><br />
<br />
(Quelle:<br><br />
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip<br><br />
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip<br><br />
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)<br />
<br />
Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P<br />
<br />
=== Simon Ks Webserver (uip-Stack) ===<br />
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip<br />
IP: 192.168.0.93:8080<br><br />
<br />
=== Ethersex Server ===<br />
<br />
http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.<br />
<br />
Oder <br />
[http://www.ethersex.de/firmware-builder/list.cgi hier] ein Firmware Image passend für das Pollin Net-IO mit eingebautem Webserver und Beispieldateien im Flash bauen lassen und flashen (firmware-builder). Einfacher geht´s nimmer. :-)<br />
<br />
=== Etherrape Server ===<br />
<br />
http://www.lochraster.org/etherrape/ <br />
<br />
ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.<br />
Es scheint aber bei der Weiterentwicklung wenig zu passieren.<br />
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape<br />
<br />
=== Mini SRCP Server (kommerziell, Closed-Source)===<br />
<br />
Damit wird die Platine zu einer Modellbahnsteuerung, die<br />
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen<br />
gesteuert werden kann.<br />
<br />
[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware<br />
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].<br />
<br />
=== AvrArtNode ===<br />
<br />
Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.<br />
<br />
Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]<br />
<br />
=== Webserver von G. Menke ===<br />
<br />
Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:<br />
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]<br />
<br />
=== OpenMCP ===<br />
<br />
Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt das viel Arbeit und Liebe in diesen Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-System welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.<br />
<br />
[http://wiki.neo-guerillaz.de Projekt und Doku]<br />
<br />
Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.<br />
<br />
=== ENC28J60 I/O-Webserver von Thomas Heldt ===<br />
<br />
Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:<br />
<br />
[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]<br />
<br />
== Siehe auch ==<br />
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988<br />
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]<br />
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]<br />
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]<br />
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]<br />
<br />
[[Category:AVR-Boards]]<br />
[[Category:Ethernet|P]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=AVR_Net-IO_Bausatz_von_Pollin&diff=42299
AVR Net-IO Bausatz von Pollin
2010-01-17T20:02:58Z
<p>Leo1969: /* Bekannte Fehler */</p>
<hr />
<div>== Einleitung ==<br />
<br />
Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058]<br />
<br />
Eine Liste von Features:<br />
<br />
Ethernet-Platine mit ATMega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.<br />
<br />
Technische Daten:<br />
<br />
* Betriebsspannung 9 V AC/DC<br />
* Stromaufnahme ca. 190 mA<br />
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]<br />
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]<br />
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]<br />
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]<br />
* [[ENC28J60]]<br />
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller<br />
<br />
Maße (LxBxH): 108x76x22 mm.<br />
<br />
== Hardware ==<br />
<br />
[[Bild:AVR-NET-IO.JPG|thumb|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen sind nicht wie vorgesehen angereiht.]]Die Schaltung des AVR-NET-IO ist recht einfach:<br />
* Ein ATmega32 Mikrocontroller enthält die gesamte Software<br />
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden<br />
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.<br />
* Ein MAX232 für die serielle Schnittstelle<br />
* Zwei Spannungsregler, 5 V und 3,3 V<br />
* "Hühnerfutter"<br />
<br />
Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Sie sind nicht(!) besonders geschützt, es finden sich zum Beispiel keine Schutzdioden für die Pins in der Schaltung.<br />
<br />
Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man<br />
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter<br />
und sie stehen auch sauber in der Reihe (nicht wie auf dem Foto; die Anschlussklemmen lassen sich sauber durch einen Steg zusammenstecken).<br />
<br />
==== Hardware-Umbauten & -Verbesserungen ====<br />
<br />
* Kühlkörper auf dem 7805<br />
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen<br />
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.<br />
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen. <br />
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen <br />
* Vorwiderstände der Ethernet-LEDs größer machen (z.B. verdoppeln) um Strom zu sparen<br />
* Linear-Spannungsregler ersetzen<br />
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)<br />
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig.<br />
* Umbau auf 3,3 V:<br />
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler<br />
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb<br />
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )<br />
** Ersatz des MAX232 durch einen MAX3232<br />
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]<br />
* ATmega32 vom ENC28J60 takten (OSC2)<br />
* Betrieb mit Gleichspannung:<br />
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)<br />
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)<br />
* Ersatz des ATmega32 durch einen ATmega644 mit mehr FLASH-Speicher.<br />
<br />
== Inbetriebnahme der Originalsoftware ==<br />
=== Einleitung ===<br />
<br />
Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann weder die serielle Schnittstelle, noch die Netzwerkschnittstelle zu funktionieren. Falls es Probleme geben sollte kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:<br />
<br />
* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)<br />
* Entweder<br />
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder<br />
**ein gekreuztes(''cross over'') Ethernet-Kabel<br />
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].<br />
* Die [http://www.pollin.de/shop/shop.php?cf=downloads_suchergebnis.php&fp=OA==&pg=NQ==&a=MTQ5OTgxOTk= Pollin NetServer Software], Version 1.01 (oder neuer)<br />
<br />
=== Gelieferten ATmega32 richtig einstellen ===<br />
<br />
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.<br />
<br />
Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.<br />
<br />
Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert. Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.<br />
<br />
==== Funktionsfähige Konfiguration - AVR-Prog ====<br />
<br />
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein. <br />
<br />
[[Bild:Avrprog.png]]<br />
<br />
Alternativ kann auch per avrdude die Einstellung getroffen werden:<br />
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m und <br />
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m<br />
<br />
Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).<br />
<br />
=== PC Konfiguration ===<br />
<br />
==== PC normalerweise nicht im 192.168.0/24 Subnetz ====<br />
<br />
Betreibt man den PC normalerweise nicht im 192.168.0/24 Subnetz, muss er wie folgt umkonfiguriert werden.<br />
<br />
Den PC vom normalen Netzwerk abstecken. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen. <br />
<br />
Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.<br />
<br />
In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel<br />
<br />
IP-Adresse: '''192.168.0.100'''<br><br />
Subnetzmaske: '''255.255.255.0'''<br><br />
Standardgateway: '''192.168.0.1'''<br />
<br />
eingeben. <br />
<br />
Alle geöffneten Dialoge nacheinander mit OK schließen.<br />
<br />
Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.<br />
<br />
Im EEPROM sind folgende Werte vorprogrammiert:<br><br><br />
3EE - 3F3 MAC-ADRESSE<br><br />
3F4 - 3F7 GATEWAY<br><br />
3F8 - 3FC NETMASK<br><br />
3FD - 3FF IP-ADRESSE<br><br />
<br />
==== PC bereits im 192.168.0/24 Subnetz ====<br />
<br />
In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.<br />
<br />
Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.<br />
<br />
=== AVR-NET-IO anschließen ===<br />
<br />
Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.<br />
<br />
Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.<br />
<br />
Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.<br />
<br />
=== Firmware 1.01 einspielen ===<br />
<br />
Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.<br />
<br />
Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.01 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.<br />
<br />
=== Abschluss ===<br />
<br />
Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.<br />
<br />
Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.<br />
<br />
== Bekannte Fehler ==<br />
<br />
Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]]<br />
<br />
* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben<br />
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)<br />
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)<br />
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.<br />
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen<br />
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)<br />
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)<br />
** ''Stand 03.09.2008, online, #all, wpe'' (Online)<br />
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.<br />
<br />
* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])<br />
<br />
* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.<br />
<br />
* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])<br />
<br />
* Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]<br />
<br />
* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.<br />
<br />
* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt.<br />
<br />
* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert<br />
<br />
* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.<br />
<br />
* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.<br />
<br />
* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.<br />
<br />
* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.<br />
<br />
* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.<br />
<br />
* Bausatz Juli '09 gekauft, grüne statt rote LED<br />
<br />
* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!<br />
<br />
* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.<br />
<br />
* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft<br />
<br />
* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.<br />
<br />
* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche<br />
<br />
*Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig<br />
<br />
* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.<br />
<br />
* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt<br />
<br />
* Bausatz Okt. 09 gekauft, 100nF Kondensator und 25MHz Quarz fehlt<br />
<br />
== Andere Software für den Client-PC ==<br />
=== NetIOLib ===<br />
<br />
In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL) <br />
<br />
<br />
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]<br />
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]<br />
<br />
=== ControlIO ===<br />
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.<br />
http://www.mikrocontroller.net/topic/149695<br />
<br />
== Andere Software statt der Originalsoftware von Pollin ==<br />
<br />
Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an.<br />
<br />
=== Bascom Version von Hütti ===<br />
<br />
(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )<br />
dort am Ende der Seite.<br />
<br />
=== Ben's Bascom Quellcode ===<br />
<br />
(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )<br />
<br />
Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !<br />
<br />
=== U. Radigs Webserver ===<br />
<br />
Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex<br />
oder selbst anpassen: <br />
Ändere im File ENC28J60.H<br />
#define ENC28J60_PIN_SS 3<br />
#define ENC28J60_PIN_CS 4<br />
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)<br />
<br />
Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.<br />
<br />
IP: 192.168.0.99<br><br />
User: admin<br><br />
Pass: uli1<br><br />
<br />
Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex<br />
<br />
Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.<br />
<br />
Wer gerne als Link-LED die grüne nutzen möchte<br />
(U.Radig-Source)<br />
<br />
enc28j60.c Zeile 150<br />
<br />
"enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A)<br />
<br />
Wert 0x347A in 0x374A ändern<br />
<br />
(Quelle: http://www.mikrocontroller.net/topic/109988#994943)<br />
<br />
IP: 192.168.1.90<br><br />
User: admin<br><br />
Pass: tim<br><br />
Test: http://beitz-online.dyndns.org<br><br />
Test: http://pieper-online.dyndns.org<br><br />
<br />
Weiterentwicklung des Radig-Codes von RoBue: <br><br />
- 1-Wire-Unterstützung (Anschlus an PORTA7) <br><br />
- PORTA0-3 digitaler Eingang (ein/aus) <br><br />
- PORTA4-6 analoger Eingang (0 - 1023) <br><br />
- LCD an PORTC <br><br />
- Schalten in Abhängigkeit von Temperatur und analogem Wert <br><br />
- (Teilweise) Administration über Weboberfläche <br><br />
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 <br><br />
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) <br><br />
<br />
Test: http://df8jb.dyndns.org/<br><br />
<br />
(Quelle:<br><br />
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip<br><br />
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip<br><br />
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)<br />
<br />
Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P<br />
<br />
=== Simon Ks Webserver (uip-Stack) ===<br />
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip<br />
IP: 192.168.0.93:8080<br><br />
<br />
=== Ethersex Server ===<br />
<br />
http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.<br />
<br />
Oder <br />
[http://www.ethersex.de/firmware-builder/list.cgi hier] ein Firmware Image passend für das Pollin Net-IO mit eingebautem Webserver und Beispieldateien im Flash bauen lassen und flashen (firmware-builder). Einfacher geht´s nimmer. :-)<br />
<br />
=== Etherrape Server ===<br />
<br />
http://www.lochraster.org/etherrape/ <br />
<br />
ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.<br />
Es scheint aber bei der Weiterentwicklung wenig zu passieren.<br />
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape<br />
<br />
=== Mini SRCP Server (kommerziell, Closed-Source)===<br />
<br />
Damit wird die Platine zu einer Modellbahnsteuerung, die<br />
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen<br />
gesteuert werden kann.<br />
<br />
[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware<br />
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].<br />
<br />
=== AvrArtNode ===<br />
<br />
Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.<br />
<br />
Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]<br />
<br />
=== Webserver von G. Menke ===<br />
<br />
Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:<br />
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]<br />
<br />
=== OpenMCP ===<br />
<br />
Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt das viel Arbeit und Liebe in diesen Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-System welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.<br />
<br />
[http://wiki.neo-guerillaz.de Projekt und Doku]<br />
<br />
Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.<br />
<br />
=== ENC28J60 I/O-Webserver von Thomas Heldt ===<br />
<br />
Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:<br />
<br />
[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]<br />
<br />
== Siehe auch ==<br />
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988<br />
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]<br />
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]<br />
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]<br />
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]<br />
<br />
[[Category:AVR-Boards]]<br />
[[Category:Ethernet|P]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=IC-Geh%C3%A4useformen&diff=40521
IC-Gehäuseformen
2009-11-07T12:09:53Z
<p>Leo1969: /* Weblinks */</p>
<hr />
<div>[[Image:IC-Gehaeuseformen.jpg|thumb|Gehäuseformen im Größenvergleich]]<br />
<br />
== DIL/SIL (DIP, PDIP) ==<br />
<br />
SIL: '''S'''ingle '''I'''n '''L'''ine Package (Anschlüsse einreihig)<br />
<br />
DIL: '''D'''ual '''I'''n '''L'''ine Package (Anschlüsse zweireihig)<br />
<br />
DIP: '''D'''ual '''I'''n line '''P'''ackage<br />
<br />
PDIP: '''P'''lastic '''D'''ual '''I'''n line '''P'''ackage<br />
<br />
Meistverbreitete Gehäuseform in der Elektronik mit durchsteckbaren Anschlüssen ("Beinchen"). Beine werden durch Löcher in die Platine oder in einen Sockel gesteckt und von unten verlötet. Da die meisten DIL und SIL Gehäuse ein einheitliches Raster aufweisen und damit auf (universal-) 2,54 mm Raster-Leiterplatten steckbar sind, sind diese für Neuentwicklungen und Versuchsaufbauten wesentlich einfacher zu handhaben als [[SMD]]-Bauteile, deren Anschlußraster teils völlig exotisch sind.<br />
<br />
== SOP/SSOP/TSOP/TSSOP ==<br />
[[Bild:Top_at49bv322a.jpg|thumb|right|256px|Flash-Baustein Atmel AT49BV322A im TSOP Gehäuse]]<br />
('''T'''hin) ('''S'''hrinked) '''S'''mall '''O'''utline '''P'''ackage<br />
<br />
Eine [[SMD]]-Gehäuseform. Das rechteckige Gehäuse hat im Gegensatz zu QFP nur auf zwei Seiten Pins. Üblicherweise sind dies die längeren Seiten des rechteckigen Plastikkörpers. TSOP hat die Anschlußpins allerdings auf der schmalen Gehäuseseite. TSOP-Bauformen werden besonders häufig bei Speicherbausteinen eingesetzt, da ihre besondere Form die Verdrahtung von Bussystemen auf der Leiterplatte vereinfacht. Die Namensgebung unterscheidet sich allerdings auch von Hersteller zu Hersteller oder es werden für leicht andere Gehäuse (unterschiedliche Breite der Plastikkörper usw.) neue Namen eingeführt.<br />
<br />
== BGA ==<br />
<br />
('''F'''ine-pitch) '''B'''all '''G'''rid '''A'''rray<br />
<br />
Eine [[SMD]]-Gehäuseform. Dabei befinden sich die Kontakte in Form von Pads, meist in mehreren Reihen, auf der Unterseite des Gehäuses. Diese Pads werden in einem sogenannten "Balling-Process" mit Lot versehen, wobei sich Lotkugeln auf diesen Pads bilden. Wird ein BGA entfernt und später wieder aufgesetzt, muss dieser Prozess wiederholt werden (Reballing-Process).<br />
<br />
Wegen der für diese Prozesse notwendigen Geräte sind [[IC]]s in BGA-Gehäusen für Hobbybastelzwecke nicht gut geeignet. Dafür beschafft man sich lieber welche im DIP-Gehäuse bzw. in TQFP.<br />
<br />
Wer es dennoch versuchen möchte, findet ein interessantes Projekt zum BGA selber löten auf: <br />
http://wwwbode.cs.tum.edu/~acher/bga/<br />
<br />
== QFP ==<br />
<br />
[[Bild:Qfp.jpg|right]]<br />
<br />
'''Q'''uad '''F'''lat '''P'''ackage<br />
<br />
Eine flache, rechteckige [[SMD]]-Gehäuseform. Dabei werden die Pins an allen vier Kanten in Form relativ kleiner Kontakte nach aussen geführt. Die Handverlötung von QFP-Bauteilen ist zwar schwierig und erfordert einiges an Übung und eine ruhige Hand, ist jedoch möglich. Beachte dazu die [[SMD Löten|Hinweise zum Verlöten von SMD-Bauteilen]].<br />
<br />
Varianten:<br />
* TQFP = '''T'''hin '''Q'''uad '''F'''lat '''P'''ackage<br />
* LQFP = '''L'''ow Profile '''Q'''uad '''F'''lat '''P'''ackage<br />
* PQFP = '''P'''lastic '''Q'''uad '''F'''lat '''P'''ackage<br />
* CQFP = '''C'''eramic '''Q'''uad '''F'''lat '''P'''ackage<br />
* BQFP = '''B'''umpered '''Q'''uad '''F'''lat '''P'''ackage<br />
* SQFP = '''S'''mall '''Q'''uad '''F'''lat '''P'''ackage<br />
<br />
== Adapterplatinen für SMD-ICs ==<br />
<br />
* [[SMD 2 Steckbrett Adapter]]<br />
* http://www.ibhn.de/<br />
* http://www.segor.de/<br />
* http://www.futurlec.com/SMD_Adapters.shtml<br />
* http://www.epboard.com/eproducts/ezadapter.htm<br />
* http://www.ak-modul-bus.de/stat/platine_fuer_ics_im_tssop_gehaeuse.html (20 PIN TSSOP)<br />
* http://www.saelig.com/miva/merchant.mvc?Screen=CTGY&Category_Code=SMD<br />
* http://www.elk-tronic.de/Products/Adapter/SolderAdapter/SolderAdapter.htm<br />
* http://www.omega-research.co.uk/<br />
* http://www.sparkfun.com (-->"Breakout Boards")<br />
* http://www.schmartboard.com<br />
* http://www.c51.de/c51.de/ChipAdapter.php<br />
* http://www.tme.pl/ip/369,universal-leiterplatten-fur-integrierte-schaltkreise-in-plcc-und-qfp-gehausen,de.html<br />
* http://www.chipenable.co.uk/shop.htm (SO8-->DIL8)<br />
<br />
== Weblinks ==<br />
* http://www.ic-168.com/English/js-pk.htm - Übersicht über sehr viele verschiedene Gehäuse, mit Fotos<br />
<br />
[[Category:Bauteile]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=38584
AVR-GCC-Tutorial
2009-08-30T10:03:27Z
<p>Leo1969: /* Programmierstil */</p>
<hr />
<div>= Vorwort =<br />
<br />
Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[AVR-GCC]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Progammiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong]. Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern, weder in Assembler noch in einer anderen Sprache. <br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR Controllern finden. Bei WinAVR gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden stetig weiterentwickelt. Erläuterungen und Beispiele beziehen sich auf den C-Compiler avr-gcc ab Version 3.4 und die avr-libc ab Version 1.4.3. Die Unterschiede zu älteren Versionen werden im Haupttext und Anhang zwar erläutert, Anfängern sei jedoch empfohlen, die aktuellen Versionen zu nutzen (für MS-Windows: aktuelle Version des [[WinAVR]]-Pakets; für Linux gibt es CDK4AVR: http://cdk4avr.sf.net oder auch fertige Pakete bei verschiedenen Distributionen.). <br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in PDF-Form erhältlich bei:<br />
http://www.siwawi.arubi.uni-kl.de/avr_projects/AVR-GCC-Tutorial_-_www_mikrocontroller_net.pdf<br />
(nicht immer auf aktuellem Stand)<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels avr-gcc/avr-libc zu erstellen und zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR Controllers, der vom avr-gcc Compiler unterstützt wird (alle ATmegas und die meisten AT90, siehe Dokumentation der avr-libc für unterstützte Typen). Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man [[AVR#Starterkits|hier]].<br />
<br />
* Der avr-gcc Compiler und die avr-libc. Kostenlos erhältlich für nahezu alle Plattformen und Betriebssysteme. Für MS-Windows im Paket [[WinAVR]]; für Unix/Linux siehe auch Hinweise im Artikel [[AVR-GCC]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]] (siehe Abschnitt [[AVR-GCC-Tutorial#Exkurs: Makefiles|Exkurs: Makefiles]]).<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin ] ansehen, beide sind unter Windows und Linux einfach zu installieren. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks] (aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar). Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220&postdays=0&postorder=asc&start=0 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht "klappt"? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispieleprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu zwei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Abschnitt [[AVR-GCC-Tutorial#Exkurs: Makefiles|Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<c><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind lediglich Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xff; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5a)<br />
/* "leere" Schleife*/ // (5b)<br />
} // (5c)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (6)<br />
}<br />
</c><br />
<br />
* In der mit (1) markierten Zeile wird eine so genannte Header-Datei eingebunden. In io.h sind die Registernamen definiert, die im späteren Verlauf genutzt werden.<br />
<br />
* Bei (2) beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion main.<br />
<br />
* Die Anschlüsse eines AVR ("Beinchen") werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Richtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B zu Ausgängen.<br />
<br />
* (4) stellt die Werte der Ausgänge ein. Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential).<br />
<br />
* (5) ist die so genannte Hauptschleife (main-loop). Dies ist eine Programmschleife, welche kontinuierlich wiederkehrende Befehle enthält. In diesem Beispiel ist sie leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert (außer das Strom verbraucht wird). Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife wäre der Zustand des Controllers nach dem Programmende undefiniert.<br />
<br />
* (6) wäre das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: int main(void) besagt, dass die Funktion einen Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein auf dem Controller lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen Makefile (ohne Endung) im selben Verzeichnis, in dem auch die Datei main.c mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im folgenden Abschnitt [[AVR-GCC-Tutorial#Exkurs: Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\tmp\gcc_tut\quickstart>dir<br />
<br />
Verzeichnis von D:\tmp\gcc_tut\quickstart<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei main.hex, in der der Code für den AVR enthalten ist. <br />
<br />
<pre><br />
D:\tmp\gcc_tut\quickstart>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
<br />
[...]<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming (ISP) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann (z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio), kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine LED leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Exkurs: Makefiles =<br />
<br />
:&rarr; siehe ''[[AVR-GCC-Tutorial/Exkurs Makefiles]]''<br />
<br />
= Ganzzahlige (Integer) Datentypen =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei stdint.h definiert. <br />
Zur Nutzung der standardisierten Typen bindet man die "Definitionsdatei" wie folgt ein:<br />
<br />
<c><br />
// ab avr-libc Version 1.2.0 möglich und empfohlen:<br />
#include <stdint.h><br />
<br />
// veraltet: #include <inttypes.h><br />
</c><br />
<br />
Einige der dort definierten Typen (avr-libc Version 1.0.4):<br />
<br />
<c><br />
typedef signed char int8_t;<br />
typedef unsigned char uint8_t;<br />
<br />
typedef short int16_t;<br />
typedef unsigned short uint16_t;<br />
<br />
typedef long int32_t;<br />
typedef unsigned long uint32_t;<br />
<br />
typedef long long int64_t;<br />
typedef unsigned long long uint64_t;<br />
</c><br />
<br />
* int8_t steht für einen 8-Bit Integer mit einem Wertebereich -128 bis +127.<br />
<br />
* uint8_t steht für einen 8-Bit Integer ohne Vorzeichen (unsigned int) mit einem Wertebereich von 0 bis 255<br />
<br />
* int16_t steht für einen 16-Bit Integer mit einem Wertebereich -32768 bis +32767.<br />
<br />
* uint16_t steht für einen 16-Bit Integer ohne Vorzeichen (unsigned int) mit einem Wertebereich von 0 bis 65535.<br />
<br />
Die Typen ohne vorangestelltes ''u'' werden als vorzeichenbehaftete Zahlen abgespeichert. Typen mit vorgestelltem ''u'' dienen der Ablage von postiven Zahlen (inkl. 0). Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/(Standard) Integer Types.<br />
<br />
= Bitfelder =<br />
<br />
Beim Programmieren von Mikrocontrollern muss auf jedes Byte oder sogar auf<br />
jedes Bit geachtet werden. Oft müssen wir in einer Variablen lediglich den<br />
Zustand 0 oder 1 speichern. Wenn wir nun zur Speicherung eines einzelnen Wertes<br />
den kleinsten bekannten Datentypen, nämlich '''unsigned char''', nehmen, dann<br />
verschwenden wir 7 Bits, da ein '''unsigned char''' ja 8 Bits breit ist.<br />
<br />
Hier bietet uns die Programmiersprache C ein mächtiges Werkzeug an, mit dessen<br />
Hilfe wir 8 Bits in eine einzelne Bytevariable zusammenfassen und (fast) wie<br />
8 einzelne Variablen ansprechen können. Die Rede ist von so genannten Bitfeldern. Diese werden als Strukturelemente definiert. Sehen wir uns dazu doch am besten gleich ein Beispiel an:<br />
<br />
<c><br />
struct {<br />
unsigned bStatus_1:1; // 1 Bit für bStatus_1<br />
unsigned bStatus_2:1; // 1 Bit für bStatus_2<br />
unsigned bNochNBit:1; // Und hier noch mal ein Bit<br />
unsigned b2Bits:2; // Dieses Feld ist 2 Bits breit<br />
// All das hat in einer einzigen Byte-Variable Platz.<br />
// die 3 verbleibenden Bits bleiben ungenutzt<br />
} x;<br />
</c><br />
<br />
Der Zugriff auf ein solches Feld erfolgt nun wie beim Strukturzugriff bekannt<br />
über den Punkt- oder den Dereferenzierungs-Operator:<br />
<br />
<c><br />
x.bStatus_1 = 1;<br />
x.bStatus_2 = 0;<br />
x.b2Bits = 3;<br />
</c><br />
<br />
Bitfelder sparen Platz im RAM, zu Lasten von Platz im Flash, verschlechtern aber unter Umständen die Les- und Wartbarkeit des Codes. Anfängern wird deshalb geraten, ein "ganzes" Byte (uint8_t) zu nutzen, auch wenn nur ein Bitwert gespeichert werden soll.<br />
<br />
= Grundsätzlicher Programmaufbau eines &micro;C-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat:<br />
<br />
[[Image:Sequentielle Programme.gif]]<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
<br />
[[Image:Interrupt Programme.gif]]<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir mal<br />
die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<c><br />
#include <avr/io.h><br />
</c><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<c><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</c><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und outp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<c><br />
#include <avr/io.h><br />
<br />
...<br />
<br />
int main(void)<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
...<br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
}<br />
</c><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes.<br />
<br />
Der gcc C-Compiler (genauer der Präprozessor) unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.B. DDRB&nbsp;=&nbsp;0b00011111 (für WinAVR wurden schon ältere Versionen des gcc entsprechend angepasst). Diese Schreibweise ist jedoch nicht standardkonform und man sollte sie daher insbesondere dann nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll. <br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<c><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</c><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<c><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</c><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<c><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= (1<<PA0) | (1<<PA3); /* Interne Pull-Up fuer beide einschalten */<br />
</c><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</c><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<c><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (logisches und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also muss Bit 0 oder 2 gesetzt sein<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit !-Operator (not)<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</c><br />
<br />
Die AVR-Bibliothek (avr-libc) stellt auch Funktionen (Makros) zur Abfrage eines einzelnen Bits eines Registers zur Verfügung, diese sind bei anderen Compilern meist nicht verfügbar (können aber dann einfach durch Makros "nachgerüstet" werden).<br />
<br />
;bit_is_set (<Register>,<Bitnummer>): Die Funktion ''bit_is_set'' prüft, ob ein Bit gesetzt ist. Wenn das Bit gesetzt ist, wird ein Wert ungleich 0 zurückgegeben. Genau genommen ist es die Wertigkeit des abgefragten Bits, also 1 für Bit0, 2 für Bit1, 3 für Bit2 etc.<br />
<br />
;bit_is_clear (<Register>,<Bitnummer>): Die Funktion ''bit_is_clear'' prüft, ob ein Bit gelöscht ist. Wenn das Bit gelöscht ist, also auf 0 ist, wird ein Wert ungleich 0 zurückgegeben.<br />
<br />
Die Funktionen (eigentlich Makros) bit_is_clear bzw. bit_is_set sind nicht erforderlich, man kann und sollte C-Syntax verwenden, die universell verwendbar und portabel ist. Siehe auch [[Bitmanipulation]].<br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den Watchdog ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<c><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) ;<br />
...<br />
</c><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<c><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) ;<br />
...<br />
</c><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (LSB) und "H" (MSB) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese kann direkt zugewiesen bzw. zugegriffen werden. Die Konvertierung von 16-bit Wort nach 2*8-bit Byte erfolgt intern.<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint16_t foo;<br />
<br />
foo=ADC; /* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
</c><br />
<br />
Falls ben&ouml;tigt, kann eine 16-Bit Variable auch recht einfach manuell in ihre zwei 8-Bit Bestandteile zerlegt werden. Folgendes Beispiel demonstriert dies anhand des pseudo- 16-Bit Registers UBRR.<br />
<br />
<c><br />
/* Diese Variante ist normal am effizientesten */<br />
#include <avr/io.h><br />
#include <stdint.h><br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
typedef union {<br />
uint16_t i16;<br />
struct {<br />
uint8_t i8l;<br />
uint8_t i8h;<br />
};<br />
} convert16to8;<br />
<br />
...<br />
convert16to8 baud;<br />
baud.i16 = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
UBRRH = baud.i8h;<br />
UBRRL = baud.i8l;<br />
...<br />
<br />
/* Alternative 1:*/<br />
#include <inttypes.h><br />
<br />
uint16_t wFoo16;<br />
uint8_t bFooLow, bFooHigh;<br />
<br />
...<br />
<br />
wFoo16 = 0xAA55; /* zu "zerlegende" 16Bit-Integer */<br />
bFooHigh = (uint8_t)(wFoo16 >> 8); /* MS-Byte */<br />
bFooLow = (uint8_t)(wFoo16); /* LS-Byte */<br />
<br />
/* Alternative 2:*/<br />
<br />
#define us0(Data) (*((unsigned char *)(&Data)))<br />
#define us1(Data) (*((unsigned char *)((&Data)+1)))<br />
bFooHigh = us1(wFoo16);<br />
bFoolow = us0(wFoo16);<br />
...<br />
</c><br />
<br />
Bei einigen AVR-Typen (z.B. ATmega8, ATMega16) teilen sich UBRRH und UCSRC die gleiche Memory-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL) welches Register tats&auml;chlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und &uuml;bergibt den Wert ''3'' und ''0000 0011'' (0x3) adressiert UBRRH und &uuml;bergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den '''16-Bit-Timern''' und auch beim '''ADC''' ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem '''Lesezugriff''' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem '''Schreibzugriff''' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge beim '''Lesezugriff: Erst Low-Byte, dann High-Byte''' und für den '''Schreibzugriff: Erst High-Byte, dann Low-Byte'''.<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. '''16-Bit-Zugriffe sind generell nicht atomar!''' Wenn mit '''Interrupts''' gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise Read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
'''Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!'''<br />
<br />
In beiden Fällen (also sowohl bei den Timern als auch beim ADC) werden vom C-Compiler 16-Bit-Pseudo-Register zur Verfügung gestellt (z.B. TCNT1H/TCNT1L -> TCNT1, ADCH/ADCL -> ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. '''In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden'''. Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<c><br />
uint8_t key_pressed(const volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if ( last_state == ( *inputreg & (1<<inputbit) ) ) {<br />
return 0; /* keine Änderung */<br />
}<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = ( *inputreg & (1<<inputbit) );<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return ( *inputreg & (1<<inputbit) );<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
#include <avr/io.h><br />
<br />
uint8_t i;<br />
<br />
//...<br />
i = key_pressed( &PINB, PB1 );<br />
//...<br />
</c><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Im Übrigen können mit volatile gekennzeichnete Variablen auch als const deklariert werden, um sicherzustellen, dass sie nur noch von der Hardware änderbar sind.<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Alle Ports der AVR-Controller werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''', '''D''' usw. (abhängig von der Anzahl der Ports des verwendeten AVR). Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
7 6 5 4 3 2 1 0<br />
<br />
In C liest sich das dann so:<br />
<br />
<c><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
...<br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
// übersichtliche Alternative - Binärschreibweise<br />
DDRB = 0b00011111; /* direkte Zuweisung - übersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
<br />
...<br />
</c><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<c><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im ursprünglichen Zustand belassen:<br />
DDRB &= ~( 1 << DDB0 );<br />
// Pin 3 und 4 auf Eingang und andere im ursprünglichen Zustand belassen:<br />
DDRB &= ~( ( 1 << DDB3 ) | ( 1<<DDB4) );<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= ( 1 << DDB0) | ( 1 << DDB3 );<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</c><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<c><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</c><br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<c><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// übersichtliche Alternative - Binärschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - übersichtlich */<br />
<br />
</c><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<c><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</c><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<c><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</c><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert ware:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx, kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</c><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<c><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</c><br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<c><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<DDC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</c><br />
<br />
=== Tasten und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller gestaltet sich ebenfalls ganz einfach, wobei wir zwei unterschiedliche Methoden unterscheiden müssen: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter Pull-Up Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein Pull-Down Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten.<br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins softwaremäßig über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.B. Drehgebern) statt externer Bauteile verwenden werden können.<br />
<br />
==== (Tasten-)Entprellung ====<br />
<br />
Nun haben alle mechanischen Kontakte, sei es von Schaltern, Tastern oder auch von Relais, die unangenehme Eigenschaft zu prellen. Dies bedeutet, dass beim Schließen des Kontaktes derselbe nicht direkt Kontakt herstellt, sondern mehrfach ein- und ausschaltet bis zum endgültigen Herstellen des Kontaktes.<br />
<br />
Soll nun mit einem schnellen Mikrocontroller gezählt werden, wie oft ein solcher Kontakt geschaltet wird, dann haben wir ein Problem, weil das Prellen als mehrfache Impulse gezählt wird. Diesem Phänomen muss beim Schreiben des Programms unbedingt Rechnung getragen werden.<br />
<br />
Beim folgenden einfachen Beispiel für eine Entprellung ist zu beachten, dass der AVR im Falle eines Tastendrucks 200ms wartet, also brach liegt. Bei zeitkritische Anwendungen sollte man ein anderes Verfahren nutzen (z.B. Abfrage der Tastenzustände in einer Timer-Interrupt-Service-Routine).<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <inttypes.h><br />
#ifndef F_CPU<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* bei alter avr-libc: #include <avr/delay.h> */ <br />
<br />
/* Einfache Funktion zum Entprellen eines Tasters */<br />
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)<br />
{<br />
if ( ! (*port & (1 << pin)) )<br />
{<br />
/* Pin wurde auf Masse gezogen, 100ms warten */<br />
_delay_ms(50); // max. 262.1 ms / F_CPU in MHz<br />
_delay_ms(50); <br />
if ( *port & (1 << pin) )<br />
{<br />
/* Anwender Zeit zum Loslassen des Tasters geben */<br />
_delay_ms(50);<br />
_delay_ms(50); <br />
return 1;<br />
}<br />
}<br />
return 0;<br />
}<br />
<br />
int main(void)<br />
{<br />
DDRB &= ~( 1 << PB0 ); /* PIN PB0 auf Eingang (Taster) */<br />
PORTB |= ( 1 << PB0 ); /* Pullup-Widerstand aktivieren */<br />
...<br />
if (debounce(&PINB, PB0)) /* Falls Taster an PIN PB0 gedrueckt.. */<br />
PORTD = PIND ^ ( 1 << PD7 ); /* ..LED an Port PD7 an-<br />
bzw. ausschalten */<br />
...<br />
}<br />
</c><br />
<br />
Zum Thema Entprellen siehe auch:<br />
* Artikel [[Entprellung]]<br />
<br />
= Der UART =<br />
<br />
== Allgemeines zum UART ==<br />
<br />
Über den [[UART]] kann ein AVR leicht mit einer [[RS-232]]-Schnittstelle eines PC oder sonstiger Geräte mit "serieller Schnittstelle" verbunden werden. <br />
<br />
Mögliche Anwendungen des UART:<br />
<br />
;Debug-Schnittstelle: z.B. zur Anzeige von Zwischenergebnissen ("printf-debugging" - hier besser "UART-debugging") auf einem PC. Auf dem Rechner reicht dazu ein [[RS-232#Terminalprogramme|Terminalprogramm]] (MS-Windows: Hyperterm oder besser [http://braypp.googlepages.com/terminal Bray-Terminal], [http://www.der-hammer.info/terminal/ HTerm]; Unix/Linux z.B. minicom). Ein direkter Anschluss ist aufgrund unterschiedlicher Pegel nicht möglich, jedoch sind entsprechende Schnittstellen-ICs wie z.B. ein MAX232 günstig und leicht zu integrieren. Rechner ohne serielle Schnittstelle können über fertige USB-seriell-Adapter angeschlossen werden. <br />
;Mensch-Maschine Schnittstelle: z.B. Konfiguration und Statusabfrage über eine "Kommandozeile" oder Menüs (siehe z.B. Forumsbeitrag [http://www.mikrocontroller.net/topic/52985 Auswertung RS232-Befehle] und Artikel [[Tinykon]]) <br />
;Übertragen von gespeicherten Werten: z.B. bei einem Datenlogger<br />
;Anschluss von Geräten: mit serieller Schnittstelle (z.B. (Funk-)Modems, Mobiltelefone, Drucker, Sensoren, "intelligente" LC-Displays, GPS-Empfänger). <br />
;"Feldbusse": auf RS485/RS422-Basis mittels entsprechenden Bustreiberbausteinen (z.B. MAX485)<br />
;DMX, Midi: etc.<br />
;LIN-Bus: '''L'''ocal '''I'''nterconnect '''N'''etwork: Preiswerte Sensoren/Aktoren in der Automobiltechnik und darüber hinaus<br />
<br />
Einige AVR-Controller haben ein bis zwei vollduplexfähigen UART ('''U'''niversal '''A'''synchronous '''R'''eceiver and '''T'''ransmitter) schon eingebaut ("Hardware-UART"). <br />
Übrigens: Vollduplex heißt nichts anderes, als dass der Baustein gleichzeitig senden und empfangen kann.<br />
<br />
Neuere AVRs (ATmega, ATtiny) verfügen über einen oder zwei U'''S'''ART(s), dieser unterscheidet sich vom UART hauptsächlich durch interne FIFO-Puffer für Ein- und Ausgabe und erweiterte Konfigurationsmöglichkeiten. Die Puffergröße ist allerdings nur 1 Byte.<br />
<br />
Der UART wird über vier separate Register angesprochen. USARTs der ATMEGAs verfügen über mehrere zusätzliche Konfigurationsregister. Das Datenblatt gibt darüber Auskunft. Die Folgende Tabelle gibt nur die Register für die (veralteten) UARTs wieder.<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''UCR&nbsp;&nbsp;&nbsp;'''<br />
| '''U'''ART '''C'''ontrol '''R'''egister.<br /><br />
In diesem Register stellen wir ein, wie wir den UART verwenden möchten.<br /><br />
Das Register ist wie folgt aufgebaut:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''RXCIE'''|| '''TXCIE'''|| '''UDRIE'''|| '''RXEN'''|| '''TXEN'''|| '''CHR9'''|| '''RXB8'''|| '''TXB8'''<br />
|- <br />
! R/W<br />
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R|| W<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 1|| 0<br />
|}<br />
<br />
'''RXCIE''' ('''RX''' '''C'''omplete '''I'''nterrupt '''E'''nable)<br />
:Wenn dieses Bit gesetzt ist, wird ein UART RX Complete Interrupt ausgelöst, wenn ein Zeichen vom UART empfangen wurde. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
<br />
'''TXCIE''' ('''TX''' '''C'''omplete '''I'''nterrupt '''E'''nable)<br />
:Wenn dieses Bit gesetzt ist, wird ein UART TX Complete Interrupt ausgelöst, wenn ein Zeichen vom UART gesendet wurde. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
<br />
'''UDRIE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty '''I'''nterrupt '''E'''nable)<br />
:Wenn dieses Bit gesetzt ist, wird ein UART Datenregister Leer Interrupt ausgelöst, wenn der UART wieder bereit ist um ein neues zu sendendes Zeichen zu übernehmen. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
<br />
'''RXEN''' ('''R'''eceiver '''E'''nable)<br />
:Nur wenn dieses Bit gesetzt ist, arbeitet der Empfänger des UART überhaupt. Wenn das Bit nicht gesetzt ist, kann der entsprechende Pin des AVR als normaler I/O-Pin verwendet werden. <br />
<br />
'''TXEN''' ('''T'''ransmitter '''E'''nable)<br />
:Nur wenn dieses Bit gesetzt ist, arbeitet der Sender des UART überhaupt. Wenn das Bit nicht gesetzt ist, kann der entsprechende Pin des AVR als normaler I/O-Pin verwendet werden.<br />
<br />
'''CHR9''' (9 Bit Characters)<br />
:Wenn dieses Bit gesetzt ist, können 9 Bit lange Zeichen übertragen und empfangen werden. Das 9. Bit kann bei Bedarf als zusätzliches Stopbit oder als Paritätsbit verwendet werden. Man spricht dann von einem 11-Bit Zeichenrahmen:<br />
:1 Startbit + 8 Datenbits + 1 Stopbit + 1 Paritätsbit = 11 Bits<br />
<br />
'''RXB8''' (Receive Data Bit 8)<br />
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann enthält dieses Bit das 9. Datenbit eines empfangenen Zeichens.<br />
<br />
'''TXB8''' (Transmit Data Bit 8)<br />
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann muss in dieses Bit das 9. Bit des zu sendenden Zeichens eingeschrieben werden bevor das eigentliche Datenbyte in das Datenregister geschrieben wird.<br />
<br />
|- <br />
| '''USR&nbsp;&nbsp;&nbsp;'''<br />
| '''U'''ART '''S'''tatus '''R'''egister.<br /><br />
Hier teilt uns der UART mit, was er gerade so macht.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''RXC'''|| '''TXC'''|| '''UDRE'''|| '''FE'''|| '''OR'''|| '''-'''|| '''-'''|| '''-'''<br />
|- <br />
! R/W<br />
| R|| R/W|| R|| R|| R|| R|| R|| R<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 1|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
<br />
'''RXC''' (UART Receive Complete)<br />
:Dieses Bit wird vom AVR gesetzt, wenn ein empfangenes Zeichen vom Empfangs-Schieberegister in das Empfangs-Datenregister transferiert wurde.<br />
:Das Zeichen muss nun schnellstmöglich aus dem Datenregister ausgelesen werden. Falls dies nicht erfolgt bevor ein weiteres Zeichen komplett empfangen wurde wird eine Überlauf-Fehlersituation eintreffen. Mit dem Auslesen des Datenregisters wird das Bit automatisch gelöscht.<br />
<br />
'''TXC''' (UART Transmit Complete)<br />
:Dieses Bit wird vom AVR gesetzt, wenn das im Sende-Schieberegister befindliche Zeichen vollständig ausgegeben wurde und kein weiteres Zeichen im Sendedatenregister ansteht. Dies bedeutet also, wenn die Kommunikation vollumfänglich abgeschlossen ist.<br />
:Dieses Bit ist wichtig bei Halbduplex-Verbindungen, wenn das Programm nach dem Senden von Daten auf Empfang schalten muss. Im Vollduplexbetrieb brauchen wir dieses Bit nicht zu beachten.<br />
:Das Bit wird nur dann automatisch gelöscht, wenn der entsprechende Interrupthandler aufgerufen wird, ansonsten müssen wir das Bit selber löschen.<br />
<br />
'''UDRE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty)<br />
:Dieses Bit zeigt an, ob der Sendepuffer bereit ist, um ein zu sendendes Zeichen aufzunehmen. Das Bit wird vom AVR gesetzt (1), wenn der Sendepuffer leer ist. Es wird gelöscht (0), wenn ein Zeichen im Sendedatenregister vorhanden ist und noch nicht in das Sendeschieberegister übernommen wurde. Atmel empfiehlt aus Kompatibilitätsgründen mit kommenden µC, UDRE auf 0 zu setzen, wenn das UCSRA Register beschrieben wird.<br />
:Das Bit wird automatisch gelöscht, wenn ein Zeichen in das Sendedatenregister geschrieben wird.<br />
<br />
'''FE''' ('''F'''raming '''E'''rror)<br />
:Dieses Bit wird vom AVR gesetzt, wenn der UART einen Zeichenrahmenfehler detektiert, d.h. wenn das Stopbit eines empfangenen Zeichens 0 ist.<br />
:Das Bit wird automatisch gelöscht, wenn das Stopbit des empfangenen Zeichens 1 ist.<br />
<br />
'''DOR''' ('''D'''ata'''O'''ver'''R'''un)<br />
:Dieses Bit wird vom AVR gesetzt, wenn unser Programm das im Empfangsdatenregister bereit liegende Zeichen nicht abholt bevor das nachfolgende Zeichen komplett empfangen wurde.<br />
:Das nachfolgende Zeichen wird verworfen.<br />
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.<br />
<br />
|- <br />
| '''UDR'''<br />
| '''U'''ART '''D'''ata '''R'''egister.<br /><br />
Hier werden Daten zwischen UART und CPU übertragen. Da der UART im<br />
Vollduplexbetrieb gleichzeitig empfangen und senden kann, handelt es sich<br />
hier physikalisch um 2 Register, die aber über die gleiche I/O-Adresse<br />
angesprochen werden. Je nachdem, ob ein Lese- oder ein Schreibzugriff auf<br />
den UART erfolgt wird automatisch das richtige UDR angesprochen.<br />
|- <br />
| '''UBRR'''<br />
| '''U'''ART '''B'''aud '''R'''ate '''R'''egister.<br /><br />
In diesem Register müssen wir dem UART mitteilen, wie schnell wir gerne<br />
kommunizieren möchten. Der Wert, der in dieses Register geschrieben<br />
werden muss, errechnet sich nach folgender Formel:<br />
<br />
:<math><br />
\mathrm{UBRR} = \frac{\mathrm{Taktfrequenz}}{\mathrm{Baudrate} \cdot 16} - 1<br />
</math><br />
<br />
Es sind Baudraten bis zu 115200 Baud und höher möglich.<br />
|}<br />
<br />
== Die Hardware ==<br />
<br />
Der UART basiert auf normalem TTL-Pegel mit 0V (logisch 0) und 5V (logisch 1). Die<br />
Schnittstellenspezifikation für RS-232 definiert jedoch -3V ... -12V (logisch 1) und<br />
+3 ... +12V (logisch 0). Daher muss der Signalaustausch zwischen AVR und<br />
Partnergerät invertiert werden. Für die Anpassung der Pegel und das<br />
Invertieren der Signale gibt es fertige Schnittstellenbausteine. Der bekannteste<br />
davon ist wohl der MAX232. <br />
<!-- "Hackerloesung" auskommentiert - nicht so gut in einem "Einsteiger-Tutorial" - mthomas<br />
Allerdings kostet der auch wieder Geld und benötigt<br />
zusätzlich immerhin 4 externe Elkos.<br />
<br />
Die in den PC eingebauten Schnittstellen vertragen ohne Klagen auch den<br />
TTL-Pegel vom AVR. Allerdings müssen wir immer noch die Signale invertieren. Im<br />
einfachtesn Fall verwenden wir dazu jeweils einen einfachen NPN-Transistor und 2<br />
Widerstände. Näheres dazu erfahrt ihr in den folgenden Übungen.--><br />
<br />
Streikt die Kommunikation per UART, so ist oft eine fehlerhafte Einstellung der Baudrate die Ursache. Die Konfiguration auf eine bestimmte Baudrate ist abhängig von der Taktfrequenz des Controllers. Gerade bei neu aufgebauten Schaltungen (bzw. neu gekauften Controllern) sollte man sich daher noch einmal vergewissern, dass der Controller auch tatsächlich mit der vermuteten Taktrate arbeitet und nicht z.B. den bei einigen Modellen werksseitig eingestellten internen [[Oszillator]] statt eines externen Quarzes nutzt. Die Werte der verschiedenen fuse-bits im Fehlerfall also beispielsweise mit ''[[AVRDUDE]]'' kontrollieren und falls nötig anpassen. Grundsätzlich empfiehlt sich auch immer ein Blick in die [[AVR_Checkliste]].<br />
<br />
== UART initialisieren ==<br />
<br />
Wir wollen nun Daten mit dem UART auf die serielle Schnittstelle ausgeben. Dazu müssen wir den UART zuerst mal initialisieren. Dazu setzen wir je nach gewünschter Funktionsweise die benötigten Bits im '''U'''ART '''C'''ontrol '''R'''egister.<br />
<br />
Da wir vorerst nur senden möchten und noch keine Interrupts auswerten wollen, gestaltet sich die Initialisierung wirklich sehr einfach, da wir lediglich das '''Transmitter Enable''' Bit setzen müssen:<br />
<br />
<c><br />
UCR |= (1<<TXEN);<br />
</c><br />
<br />
Neuere AVRs mit USART haben mehrere Konfigurationsregister und erfordern eine etwas andere Konfiguration. Für einen ATmega16 z.B.:<br />
<br />
<c><br />
UCSRB |= (1<<TXEN); // UART TX einschalten<br />
UCSRC |= (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0); // Asynchron 8N1<br />
</c><br />
<br />
Nun ist noch das Baudratenregister '''UBRR''' einzustellen. Bei neueren AVRs besteht es aus zwei Registern '''UBRRL''' und '''UBRRH'''. Der Wert dafür ergibt sich aus der angegebenen Formel durch Einsetzen der Taktfrequenz und der gewünschten Übertragungsrate. Das Berechnen der Formel wird dem [[C-Präprozessor|Präprozessor]] überlassen.<br />
<br />
<c><br />
/* UART-Init beim AT90S2313 */<br />
<br />
#ifndef F_CPU<br />
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann<br />
F_CPU im Makefile definiert werden, eine nochmalige Definition<br />
hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch<br />
#ifndef/#endif <br />
<br />
Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio <br />
verwendet wird und dort eine andere, nicht zur Hardware passende <br />
Taktrate eingestellt ist: Dann wird die folgende Definition <br />
nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?) <br />
von AVRStudio - daher Ausgabe einer Warnung falls F_CPU<br />
noch nicht definiert: */<br />
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"<br />
#define F_CPU 4000000UL // Systemtakt in Hz - Definition als unsigned long beachten >> Ohne ergeben Fehler in der Berechnung<br />
#endif<br />
<br />
#define BAUD 9600UL // Baudrate<br />
<br />
// Berechnungen<br />
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden<br />
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate<br />
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.<br />
<br />
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))<br />
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! <br />
#endif<br />
<br />
int main(void)<br />
{<br />
UCR |= (1<<TXEN);<br />
UBRR = UBRR_VAL;<br />
//...<br />
}<br />
</c><br />
<!-- mthomas: warum nicht UL?, wird von AVRStudio auch mit UL übergeben --><br />
Wieder für den Mega16 mit zwei Registern für die Baudrateneinstellung eine etwas andere Programmierung. Wichtig ist, dass UBRRH '''vor''' UBRRL geschrieben wird.<br />
<br />
<c><br />
/* USART-Init beim ATmega16 */<br />
<br />
int main(void)<br />
{<br />
UCSRB |= (1<<TXEN); // UART TX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = UBRR_VAL >> 8;<br />
UBRRL = UBRR_VAL & 0xFF;<br />
}<br />
</c><br />
<br />
Für einige AVR (z.B. ATmega169, ATmega48/88/168, AT90CAN jedoch nicht für z.B. ATmega16/32, ATmega128, ATtiny2313) wird durch die Registerdefinitionen der avr-libc (io*.h) auch für Controller mit zwei UBRR-Registern (UBRRL/UBRRH) ein UBRR bzw. UBRR0 als "16-bit-Register" definiert und man kann auch Werte direkt per UBRR = UBRR_VAL zuweisen. Intern werden dann zwei Zuweisungen für UBRRH und UBRRL generiert. Dies ist nicht bei allen Controllern möglich, da die beiden Register nicht bei allen aufeinanderfolgende Addressen aufweisen. Die getrennte Zuweisung an UBRRH und UBRRL wie im Beispiel gezeigt ist universeller und portabler und daher vorzuziehen.<br />
<br />
Die Makros sind sehr praktisch, da sie sowohl automatisch den Wert für UBRR als auch den Fehler in der generierten Baudrate berechnen und im Falle einer Überschreitung (+/-1%) einen Fehler und somit Abbruch im Compilerablauf generieren. Damit können viele Probleme mit "UART sendet komische Zeichen" vermieden werden. Ausserdem kann man mühelos die Einstellung an eine neue Taktfrequenz bzw. Baudrate anpassen, ohne selber rechnen oder in Tabellen nachschlagen zu müssen.<br />
<br />
Inzwischen gibt es in der avr-libc Makros für obige Berechnung der UBRR Registerwerte aus Taktrate F_CPU und Baudrate BAUD in der Includedatei <util/setbaud.h> ([http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html]).<br />
<br />
Siehe auch:<br />
* [http://www.wormfood.net/avrbaudcalc.php WormFood's AVR Baud Rate Calculator] online.<br />
* [http://www.gjlay.de/helferlein/avr-uart-rechner.html AVR Baudraten-Rechner] in JavaScript<br />
<br />
== Senden mit dem UART ==<br />
<br />
=== Senden einzelner Zeichen ===<br />
<br />
Um nun ein Zeichen auf die Schnittstelle auszugeben, müssen wir dasselbe<br />
lediglich in das '''U'''ART '''D'''ata '''R'''egister schreiben. Vorher ist zu prüfen, ob das UART-Modul bereit ist, das zu sendende Zeichen entgegenzunehmen. Die Bezeichnungen des/der Statusregisters mit dem Bit UDRE ist abhängig vom Controllertypen (vgl. Datenblatt).<br />
<br />
<c><br />
// bei AVR mit einem UART ("classic AVR" z.B. AT90S8515)<br />
while (!(USR & (1<<UDRE))) /* warten bis Senden moeglich */<br />
{<br />
}<br />
<br />
UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */<br />
<br />
/** ODER **/<br />
<br />
// bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:<br />
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */<br />
{<br />
}<br />
<br />
UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */<br />
</c><br />
<br />
=== Schreiben einer Zeichenkette (String) ===<br />
<br />
Die Aufgabe "String senden" wird durch zwei Funktionen abgearbeitet. Die universelle/controllerunabhängige Funktion uart_puts übergibt jeweils ein Zeichen der Zeichenkette an eine Funktion uart_putc, die abhängig von der vorhandenen Hardware implementiert werden muss. In der Funktion zum Senden eines Zeichens ist darauf zu achten, dass vor dem Senden geprüft wird, ob der UART bereit ist den "Sendeauftrag" entgegenzunehmen. <br />
<br />
<c><br />
// putc fuer AVR mit einem UART (z.B. AT90S8515)<br />
int uart_putc(unsigned char c)<br />
{<br />
while(!(USR & (1 << UDRE))) /* warte, bis UDR bereit */<br />
{<br />
}<br />
<br />
UDR = c; /* sende Zeichen */<br />
return 0;<br />
}<br />
<br />
/** ODER **/<br />
<br />
// bei neueren AVRs andere Bezeichnung fuer die Statusregister, hier ATmega16:<br />
int uart_putc(unsigned char c)<br />
{<br />
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */<br />
{<br />
} <br />
<br />
UDR = c; /* sende Zeichen */<br />
return 0;<br />
}<br />
<br />
<br />
/* puts ist unabhaengig vom Controllertyp */<br />
void uart_puts (char *s)<br />
{<br />
while (*s)<br />
{ /* so lange *s != '\0' also ungleich dem "String-Endezeichen" */<br />
uart_putc(*s);<br />
s++;<br />
}<br />
}<br />
</c><br />
<br />
Die in uart_putc verwendeten Schleifen, in denen gewartet wird bis die UART-Hardware zum senden bereit ist, sind insofern etwas kritisch, da während des Sendens eines Strings nicht mehr auf andere Ereignisse reagieren werden kann. Universeller ist die Nutzung von FIFO(first-in first-out)-Puffern, in denen die zu sendenden bzw. empfangenen Zeichen/Bytes zwischengespeichert und in Interruptroutinen an die U(S)ART-Hardware weitergegeben bzw. von ihr ausgelesen werden. Dazu existieren fertige Komponenten (Bibliotheken, Libraries), die man recht einfach in eigene Entwicklungen integrieren kann. Es empfiehlt sich, diese Komponenten zu nutzen und das Rad nicht neu zu erfinden.<br />
<br />
=== Schreiben von Variableninhalten ===<br />
<br />
Sollen Inhalte von Variablen (Ganzzahlen, Fließkomma) in "menschenlesbarer" Form gesendet werden, ist vor dem Transfer eine Umwandlung in Zeichen ("ASCII") erforderlich. Bei nur einer Ziffer ist diese Umwandlung relativ einfach: man addiert den ASCII-Wert von Null zur Ziffer und kann diesen Wert direkt senden.<br />
<br />
<c><br />
//...<br />
<br />
// hier uart_putc (s.o.)<br />
<br />
// Ausgabe von 0123456789<br />
char c;<br />
<br />
for (uint8_t i=0; i<=9; ++i) {<br />
c = i + '0';<br />
uart_putc( c );<br />
// verkuerzt: uart_putc( i + '0' );<br />
}<br />
</c><br />
<br />
Soll mehr als eine Ziffer ausgegeben werden, bedient man sich zweckmäßigerweise vorhandener Funktionen zur Umwandlung von Zahlen in Zeichenketten/Strings. Die Funktion der avr-libc zur Umwandlung von vorzeichenbehafteten 16bit-Ganzzahlen (int16_t) in Zeichenketten heißt ''itoa'' (Integer to ASCII). Man muss der Funktion einen Speicherbereich zur Verarbeitung (buffer) mit Platz für alle Ziffern, das String-Endezeichen ('\0') und evtl. das Vorzeichen bereitstellen.<br />
<br />
<c><br />
#include <stdlib.h><br />
<br />
//...<br />
<br />
// hier uart_init, uart_putc, uart_puts (s.o.)<br />
<br />
int main(void)<br />
{<br />
char s[7];<br />
int16_t i = -12345;<br />
<br />
uart_init();<br />
<br />
itoa( i, s, 10 ); // 10 fuer radix -> Dezimalsystem<br />
uart_puts( s );<br />
<br />
// da itoa einen Zeiger auf den Beginn von s zurueckgibt verkuerzt auch:<br />
uart_puts( itoa( i, s, 10 ) );<br />
<br />
while (1) {<br />
;<br />
}<br />
<br />
return 0; // never reached <br />
}<br />
</c><br />
<br />
Für vorzeichenlose 16bit-Ganzzahlen (uint16_t) exisitert ''utoa''. Die Funktionen für 32bit-Ganzzahlen (int32_t und uint32_t) heißen ''ltoa'' bzw. ''ultoa''. Da 32bit-Ganzzahlen mehr Stellen aufweisen können, ist ein entsprechend größerer Pufferspeicher vorzusehen.<br />
<br />
Auch Fließkommazahlen (float/double) können mit breits vorhandenen Funktionen in Zeichenfolgen umgewandelt werden, dazu existieren die Funktionen ''dtostre'' und ''dtostrf''. dtostre nutzt Exponentialschreibweise ("engineering"-Format). (Hinweis: z.Zt. existiert im avr-gcc kein "echtes" double, intern wird immer mit "einfacher Genauigkeit", entsprechend float, gerechnet.) <br />
<br />
dtostrf und dtostre benötigen die libm.a der avr-libc. Bei Nutzung von Makefiles ist der Parameter -lm in in LDFLAGS anzugeben (Standard in den WinAVR/mfile-Makefilevorlagen). Nutzt man AVRStudio als IDE für den GNU-Compiler (gcc-Plugin) ist die libm.a unter Libaries auszuwählen: Project -> Configurations Options -> Libaries -> libm.a mit dem Pfeil nach rechts einbinden. Siehe auch die [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|FAQ]]<br />
<br />
<c><br />
#include <stdlib.h><br />
<br />
//...<br />
<br />
// hier uart_init, uart_putc, uart_puts (s.o.)<br />
<br />
/* lt. avr-libc Dokumentation:<br />
char* dtostrf(<br />
double __val,<br />
char __width,<br />
char __prec,<br />
char * __s<br />
) <br />
*/<br />
<br />
int main(void)<br />
{<br />
// Pufferspeicher ausreichend groß<br />
// evtl. Vorzeichen + width + Endezeichen:<br />
char s[8]; <br />
float f = -12.345;<br />
<br />
uart_init();<br />
<br />
dtostrf( f, 6, 3, s ); <br />
uart_puts( s );<br />
<br />
// verkürzt: uart_puts( dtostrf( f, 7, 3, s ) );<br />
<br />
while (1) {<br />
;<br />
}<br />
<br />
return 0; // never reached <br />
}<br />
</c><br />
<br />
== Empfangen ==<br />
=== einzelne Zeichen empfangen ===<br />
<br />
Zum Empfang von Zeichen muss der Empfangsteil des UART bei der Initialisierung aktiviert werden, indem das RXEN-Bit im jeweiligen Konfigurationsregister (UCSRB bzw UCSR0B/UCSR1B) gesetzt wird. Im einfachsten Fall wird solange gewartet, bis ein Zeichen empfangen wurde, dieses steht dann im UART-Datenregister (UDR bzw. UDR0 und UDR1 bei AVRs mit 2 UARTS) zur Verfügung (sogen. "Polling-Betrieb"). Ein Beispiel für den ATmega16:<br />
<br />
<c><br />
#include <inttypes.h><br />
#include <avr/io.h><br />
<br />
/* Zusaetzlich zur Baudrateneinstellung und der weiteren Initialisierung: */<br />
void Usart_EnableRX(void)<br />
{<br />
UCSRB |= ( 1 << RXEN );<br />
}<br />
<br />
/* Zeichen empfangen */<br />
uint8_t uart_getc(void)<br />
{<br />
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar<br />
;<br />
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben<br />
}<br />
</c><br />
<br />
Diese Funktion blockiert den Programmablauf. Alternativ kann das RXC-Bit in einer Programmschleife abgefragt werden und dann nur bei gesetztem RXC-Bit UDR ausgelesen werden. Eleganter und in den meisten Anwendungsfällen "stabiler" ist die Vorgehensweise, die empfangenen Zeichen in einer Interrupt-Routine einzulesen und zur späteren Verarbeitung in einem Eingangsbuffer (FIFO-Buffer) zwischenzuspeichern. Dazu existieren fertige und gut getestete [[Libraries|Bibliotheken]] <!-- "echte Libraries" (.a) wie im Verweis beschrieben sind hier eigentlich nicht gemeint, verwirrt hier etwas, da AVR-"Libraries" meist per #defines anpassbare Source-Codes sind, vielleicht so: --> und Quellcodekomponenten (z.B. UART-Library von P. Fleury, procyon-avrlib und einige in der "Academy" von avrfreaks.net).<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html Dokumenation der avr-libc/stdlib.h]<br />
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Die_Nutzung_von_printf Die Nutzung von printf]<br />
* [http://homepage.hispeed.ch/peterfleury/ Peter Fleurys] UART-Bibiliothek fuer avr-gcc/avr-libc<br />
<!-- nimmermehr: * siehe auch: Weiterführende Informationen inkl. Beispielen für die Nutzung von stdio-Funktionen (printf etc.) im [[AVR-Tutorial:_UART]]. --><br />
<br />
<br />
TODO: 9bit<br />
<br />
=== Empfang von Zeichenketten (Strings) ===<br />
<br />
Beim Empfang von Zeichenketten, muß man sich zunächst darüber im klaren sein, daß es ein Kriterium geben muß, an dem der µC erkennen kann, wann ein String zu Ende ist. Sehr oft wird dazu das Zeichen 'Return' benutzt, um das Ende eines Strings zu markieren. Dies ist vom Benutzer einfach eingebbar und er ist auch daran gewöhnt, daß er eine Eingabezeile mit einem Druck auf die Return Taste abgeschlossen wird.<br />
<br />
Prinzipiell gibt es jedoch keine Einschränkung bezüglich dieses speziellen Zeichens. Es muß nur sichergestellt werden, daß dieses spezielle 'Ende eines Strings' - Zeichen nicht mit einem im Text vorkommenden Zeichen verwechselt werden kann. Wenn also im zu übertragenden Text beispielsweise kein ';' vorkommt, dann spricht nichts dagegen, einen String mit einem ';' abschließen zu lassen.<br />
<br />
Im Folgenden wird die durchaus übliche Annahme getroffen, daß eine Stringübertragung identisch ist mit der Übertragung einer Textzeile und daher mit einem Return ('\n') abgeschlossen wird.<br />
<br />
Das Problem der Übertragung eines Strings reduziert sich damit auf die Aufgabenstellung: Empfange und Sammle Zeichen in einem char Array, bis entweder das Array voll ist oder das 'String Ende Zeichen' empfangen wurde. Danach wird der empfangene Text noch mit einem '\0' Zeichen abgeschlossen um einen Standard C-String daraus zu machen, mit dem dann weiter gearbeitet werden kann.<br />
<br />
<C><br />
/* Zeichen empfangen */<br />
uint8_t uart_getc(void)<br />
{<br />
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar<br />
;<br />
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben<br />
}<br />
<br />
void uart_gets( char* Buffer, uint8_t MaxLen )<br />
{<br />
uint8_t NextChar;<br />
uint8_t StringLen = 0;<br />
<br />
NextChar = uart_getc(); // Warte auf und empfange das nächste Zeichen<br />
<br />
// Sammle solange Zeichen, bis:<br />
// * entweder das String Ende Zeichen kam<br />
// * oder das aufnehmende Array voll ist<br />
while( NextChar != '\n' && StringLen < MaxLen - 1 ) {<br />
*Buffer++ = NextChar;<br />
StringLen++;<br />
NextChar = uart_getc();<br />
}<br />
<br />
// Noch ein '\0' anhängen um einen Standard<br />
// C-String daraus zu machen<br />
*Buffer = '\0';<br />
}<br />
</C><br />
<br />
Beim Aufruf ist darauf zu achten, dass das empfangende Array auch mit einer<br />
vernünftigen Größe definiert wird.<br />
<br />
<C><br />
<br />
char Line[40]; // String mit maximal 39 zeichen<br />
<br />
uart_gets( Line, sizeof( Line ) );<br />
</C><br />
<br />
Bei der Benutzung von sizeof() ist allerdings zu beachten, dass sizeof() nicht die Anzahl der Elemente des Arrays liefert, sondern die Länge in Byte. Da ein char nur ein Byte lang ist, passt der Aufruf 'uart_gets(Line, sizeof( Line ) );' in diesem Fall. Falls man - aus welchen Gründen auch immer - andere Datentypen benutzen möchte, sollte man zur korrekten Angabe der Array-Länge folgende Vorgehensweise bevorzugen:<br />
<br />
<C><br />
int Line[40]; // Array vom Typ int<br />
<br />
uart_gets( Line, sizeof( Line ) / sizeof( Line[0] ) );<br />
</C><br />
<br />
==Interruptbetrieb==<br />
<br />
Beim ATMEGA8 muss das RXCIE Bit im Register UCSRB gesetzt werden, damit ein Interrupt ausgelöst werden kann.<br />
Der Interrupt wird immer ausgelöst, wenn Daten erfolgreich empfangen wurden.<br />
<br />
Zusätzlich braucht man die Routine:<br />
<br />
<c><br />
ISR (USART_RXC_vect) {<br />
//irgendein Code<br />
}<br />
</c><br />
<br />
natürlich muss "Global Interrupt Enable" Aktiviert sein.<br />
!! Nur getestet beim ATMEGA8 !!<br />
<br />
[BAUSTELLE! Aus Lerngründen eventuell als eigenen UART-Interrupt-Block hinter den grundlegenden Interrupt-Teil im Tutorial und hier eine kurze Einführung und einen Verweis darauf anbieten.]<br />
<br />
* Unterschied Polling-Betrieb (bisher, oben) und Interrupt-Betrieb<br />
* Empfangen (Receive)<br />
** Verändertes UART-Init, ISR (RXC), ggf. Fallstricke ([http://www.mikrocontroller.net/topic/84256#707214 UDR in der ISR lesen!]), Philosophie einer ISR (kurz und schmerzlos), Datenaustausch ISR zu Restprogramm (volatile)<br />
** Einfachstbeispiel ([http://www.mikrocontroller.net/topic/84228#707052 Echo] (noch buggy beim Datenzugriff, siehe Lit. 2+3!)), ggf. LED zur ISR-Empfangsanzeige oder Overflow-Anzeige<br />
* FIFO-Puffer, Ringpuffer<br />
* Senden (Transmit)<br />
** Variante "UART Data Register Empty" (UDRE) <br />
** Variante "UART Transmit Complete" (TXC) <br />
* Fertige UART-Bibliotheken (->Fleury, ->Procyon)<br />
* Literatur: <br />
** 1/ [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48188 avrfreaks.net Tutorial] inkl. Diskussion (engl.)<br />
** 2/ avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_16bitio Why do some 16-bit timer registers sometimes get trashed?]<br />
** 3/ [[Interrupt]] und atomarer Datenzugriff<br />
<br />
==Software-UART==<br />
<br />
Falls die Zahl der vorhandenen Hardware-UARTs nicht ausreicht, können weitere Schnittstellen über sogennante Software-UARTs ergänzt werden. Es gibt dazu (mindestens) zwei Ansätze: <br />
* Der bei AVRs üblichste Ansatz basiert auf dem Prinzip, dass ein externer Interrupt-Pin für den Empfang ("RX") genutzt wird. Das Startbit löst den Interrupt aus, in der Interrupt-Routine (ISR) wird der externe Interrupt deaktiviert und ein Timer aktiviert. In der Interrupt-Routine des Timers wird der Zustand des Empfangs-Pins entsprechend der Baudrate abgetastet. Nach Empfang des Stop-Bits wird der externe Interrupt wieder aktiviert. Senden kann über einen beliebigen Pin ("TX") erfolgen, der entsprechend der Baudrate und dem zu sendenden Zeichen auf 0 oder 1 gesetzt wird. Die Implementierung ist nicht ganz einfach, es existieren dazu aber fertige Bibliotheken (z.B. bei [http://www.avrfreaks.net/ avrfreaks] oder in der [http://hubbard.engr.scu.edu/embedded/avr/avrlib/ Procyon avrlib]).<br />
* Ein weiterer Ansatz erfordert keinen Pin mit "Interrupt-Funktion" aber benötigt mehr Rechenzeit. Jeder Input-Pin kann als Empfangspin (RX) dienen. Über einen Timer wird der Zustand des RX-Pins mit einem vielfachen der Baudrate abgetastet (dreifach scheint üblich) und High- bzw. Lowbits anhand einer Mindestanzahl identifiziert. (Beispiel: "Generic Software Uart" Application-Note von IAR)<br />
<br />
Neuere AVRs (z.B. ATtiny26 oder ATmega48,88,168,169) verfügen über ein Universal Serial Interface (USI), das teilweise UART-Funktion übernehmen kann. Atmel stellt eine Application-Note bereit, in der die Nutzung des USI als UART erläutert wird (im Prinzip "Hardware-unterstützter Software-UART").<br />
<br />
==Handshaking==<br />
Wenn der Sender ständig sendet, wird irgendwann der Fall eintreten, daß der Empfänger nicht bereit ist, neue Zeichen zu empfangen. In diesem Fall muß durch ein '''Handshake-Verfahren''' die Situation bereinigt werden. Handshake bedeutet nichts anderes, als daß der Empfänger dem Sender mitteilt, daß er zur Zeit keine Daten annehmen kann und der Sender die Übertragung der nächsten Zeichen solange einstellen soll, bis der Empfänger signalisiert, daß er wieder Zeichen aufnehmen kann.<br />
===Hardwarehandshake (RTS/CTS)===<br />
Beim Hardwarehandshake werden zusätzlich zu den beiden Daten-Übertragungsleitungen noch 2 weitere Leitungen benötigt: '''RTS''' ('''R'''equest '''T'''o '''S'''end) und '''CTS''' ('''C'''lear '''T'''o '''S'''end). Jeder der beiden Kommunikationspartner ist verpflichtet, bevor ein Zeichen gesendet wird, den Zustand der '''RTS''' Leitung zu überprüfen. Nur wenn die Gegenstelle darauf Empfangsbereitschaft signalisiert, darf das Zeichen gesendet werden. Um der Gegenstelle zu signalisieren, daß sie zur Zeit keine Zeichen schicken soll, wird die Leitung '''CTS''' benutzt.<br />
<br />
===Softwarehandshake (XON/XOFF)===<br />
Beim Softwarehandshake sind keine speziellen Leitungen notwendig. Statt dessen werden besondere ASCII-Zeichen benutzt, die der Gegenstelle signalisieren, daß Senden einzustellen bzw. wieder aufzunehmen.<br /><br />
* '''XOFF''' Aufforderung das Senden einzustellen<br />
* '''XON''' Gegenstelle darf wieder senden<br />
<br />
Nachteilig bei einem Softwarehandshake ist es, dass dadurch keine direkte binäre Datenübertragung mehr möglich ist. Von den möglichen 256 Bytewerten werden ja 2 (nämlich '''XON''' und '''XOFF''') für besondere Zwecke benutzt und fallen daher aus.<br />
<br />
==Fehlersuche==<br />
Erstaunlich oft wird im Forum der Hilferuf laut: "Meine UART funktioniert nicht, was mache ich falsch". In der überwiegenden Mehrzahl der Fälle stellt sich dann heraus, daß es sich um ein Hardwareproblem handelt, wobei da wiederrum der Löwenanteil auf das Konto einer nicht korrekt eingestellten Taktrate geht: Der µC benutzt nicht einen angeschlossenen Quarz, so wie er auch im Programm eingetragen ist, sondern läuft immer noch mit dem internen RC-Takt. Daraus resultiert aber auch, daß der Baudraten Konfigurationswert falsch berechnet wird.<br />
<br />
Eine Checkliste zum Aufspüren solcher Fehler findet sich [[AVR_Checkliste#UART.2FUSART|hier]].<br />
<br />
==Links==<br />
FAQ zur Verarbeitung von Strings: http://www.mikrocontroller.net/articles/FAQ<br />
<br />
= Analoge Ein- und Ausgabe =<br />
<br />
Analoge Eingangswerte werden in der Regel über den AVR Analog-Digital-Converter (AD-Wandler, ADC) eingelesen, der in vielen Typen verfügbar ist (typisch 10bit Auflösung). Durch diesen werden analoge Signale (Spannungen) in digitale Zahlenwerte gewandelt. Bei AVRs, die über keinen internen AD-Wandler verfügen (z.B. ATmega162), kann durch externe Beschaltung (R/C-Netzwerk und "Zeitmessung") die Funktion des AD-Wandlers "emuliert" werden.<br />
<br />
Es existieren keine AVRs mit eingebautem Digital-Analog-Konverter (DAC). Diese Funktion muss durch externe Komponenten nachgebildet werden (z.B. PWM und "Glättung").<br />
<br />
Unabhängig davon besteht natürlich immer die Möglichkeit, spezielle Bausteine zur Analog-Digital- bzw. Digital-Analog-Wandlung zu nutzen und diese über eine digitale Schnittstelle (z.b. SPI oder I2C) mit einem AVR anzusteuern.<br />
<br />
== AC (Analog Comparator) ==<br />
<br />
Der Comparator vergleicht 2 Spannungen an den Pins AIN0 und AIN1 und gibt einen Status aus welche der beiden Spannungen größer ist. AIN0 Dient dabei als Referenzspannung (Sollwert) und AIN1 als Vergleichsspannung (Istwert). Als Referenzspannung kann auch alternativ eine interne Referenzspannung ausgewählt werden.<br />
<br />
Liegt die Vergleichsspannung (IST) unter der der Referenzspannung (SOLL) gibt der Comperator eine logische 1 aus. Ist die Vergleichsspannung hingegen größer als die Referenzspannung wird eine logische 0 ausgegeben.<br />
<br />
Der Comparator arbeitet völlig autark bzw. parallel zum Prozessor. Für mobile Anwendungen empfiehlt es sich ihn abzuschalten sofern er nicht benötigt wird, da er ansonsten Strom benötigt. Der Comparator kann Interruptgesteuert abgefragt werden oder im Pollingbetrieb.<br />
<br />
Das Steuer- bzw. Statusregister ist wie folgt aufgebaut:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|+ '''ACSR - Analog Comparator Status Register'''<br />
|- <br />
! Bit<br />
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0<br />
|- <br />
! Name<br />
| '''ACD'''|| '''ACBG'''|| '''ACO'''|| '''ACI'''|| '''ACIE'''|| '''ACIC'''|| '''ACIS1'''|| '''ACIS0'''<br />
|- <br />
! R/W<br />
| R/W|| R/W|| R|| R/W|| R/W|| R/W|| R/W|| R/W<br />
|- <br />
! Initialwert<br />
| 0|| 0|| n/a|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
<br />
;Bit 7 ACD: Analog Comparator Disable: 0 = Comparator ein, 1 = Comparator aus. Wird dieses Bit geändert kann ein Interrupt ausgelöst werden. Soll dies vermieden werden muß das Bit 3 ACIE ggf. abgeschaltet werden.<br />
<br />
;Bit 6 ACBG: Analog Comparator Bandgap Select: Ermöglicht das umschalten zwischen interner und externer Referenzspannung. 1 = interne (~1,3 Volt), 0 = externe Referenzspannung (an Pin AIN0)<br />
<br />
;Bit 5 ACO: Analog Comparator Output: Hier wird das Ergebnis des Vergleichs angezeigt. Es liegt typischerweise nach 1-2 Taktzyklen vor.<br />
:: IST < SOLL &rarr; 1<br />
:: IST > SOLL &rarr; 0<br />
<br />
;Bit 4 ACI: Analog Comparator Interrupt Flag: Dieses Bit wird von der Hardware gesetzt wenn ein Interruptereignis das in Bit 0 und 1 definiert ist eintritt. Dieses Bit löst noch keinen Interrupt aus! Die Interruptroutine wird nur dann ausgeführt wenn das Bit 3 ACIE gesetzt ist und global Interrupts erlaubt sind (I-Bit in SREG=1). Das Bit 4 ACI wird wieder gelöscht wenn die Interruptroutine ausgeführt wurde oder wenn manuell das Bit auf 1 gesetzt wird. Das Bit kann für Abfragen genutzt werden, steuert oder konfuguriert aber nicht den Comparator.<br />
<br />
;Bit 3 ACIE: Analog Comparator Interrupt Enable: Ist das Bit auf 1 gesetzt wird immer ein Interrupt ausgelöst wenn das Ereignis das in Bit 1 und 0 definiert ist eintritt.<br />
<br />
;Bit 2 ACIC: Analog Comparator Input Capture Enable: Wird das Bit gesetzt wird der Comparatorausgang intern mit dem Counter 1 verbunden. Es könnten damit z.b. die Anzahl der Vergleiche im Counter1 gezählt werden. Um den Comparator an den Timer1 Input Capture Interrupt zu verbinden muß im Timerregister das TICIE1 Bit auf 1 gesetzt werden. Der Trigger wird immer dann ausgelöst wenn das in Bit 1 und 0 definierte Ereignis eintritt.<br />
<br />
;Bit 1,0 ACIS1,ACIS0: Analog Comparator Interrupt select: Hier wird definiert welche Ereignisse einen Interrupt auslösen sollen:<br />
:* 00 = Interrupt auslösen bei jedem Flankenwechsel<br />
:* 10 = Interrupt auslösen bei fallender Flanke<br />
:* 11 = Interrupt auslösen bei steigender Flanke<br />
<br />
Werden diese Bit geändert kann ein Interrupt ausgelöst werden. Soll dies vermieden werden muß das Bit 3 gelöscht werden.<br />
<br />
== ADC (Analog Digital Converter) ==<br />
<br />
Der Analog-Digital-Konverter (ADC) wandelt analoge Signale in digitale Werte um, welche vom Controller interpretiert werden können. Einige AVR-Typen haben bereits einen mehrkanaligen Analog-Digital-Konverter eingebaut. Die Genauigkeit, mit welcher ein analoges Signal aufgelöst werden kann, wird durch die Auflösung des ADC in Anzahl Bits angegeben, man hört bzw. liest jeweils von 8-Bit-ADC oder 10-Bit-ADC oder noch höher. ADCs die in AVRs enthalten sind haben zur Zeit eine maximale Auflösung von 10-Bit.<br />
<br />
Ein ADC mit 8 Bit Auflösung kann somit das analoge Signal mit einer Genauigkeit von 1/256 des Maximalwertes darstellen. Wenn wir nun mal annehmen, wir hätten eine Spannung zwischen 0 und 5 Volt und eine Auflösung von 3 Bit, dann könnten<br />
die Werte 0V, 0.625V, 1.25, 1.875V, 2.5V, 3.125V, 3.75, 4.375, 5V<br />
daherkommen, siehe dazu folgende Tabelle:<br />
<br />
::{| class="wikitable" style="text-align:center"<br />
! Eingangsspannung am ADC [V] || Entsprechender Messwert<br />
|-<br />
| 0–0.625 || 0<br />
|-<br />
| 0.625–1.25 || 1<br />
|-<br />
| 1.25–1.875 || 2<br />
|-<br />
| 1.875–2.5 || 3<br />
|-<br />
| 2.5–3.125 || 4<br />
|-<br />
| 3.125–3.75 || 5<br />
|-<br />
| 3.75–4.375 || 6<br />
|-<br />
| 4.375–5 || 7<br />
|}<br />
<br />
Die Angaben sind natürlich nur ungefähr. Je höher nun die Auflösung des Analog-Digital-Konverters ist, also je mehr Bits er hat, um so genauer kann der Wert erfasst werden.<br />
<br />
=== Der interne ADC im AVR ===<br />
<br />
Wenn es einmal etwas genauer sein soll, dann müssen wir auf einen AVR mit eingebautem Analog-Digital-Wandler (ADC) zurückgreifen, die über mehrere Kanäle verfügen. Kanäle heißt in diesem Zusammenhang, dass zwar bis zu zehn analoge Eingänge am AVR verfügbar sind, aber nur ein "echter" Analog-Digital-Wandler zur Verfügung steht, vor der eigentlichen Messung ist also einzustellen, welcher Kanal ("Pin") mit dem Wandler verbunden und gemessen wird.<br />
<br />
Die Umwandlung innerhalb des AVR basiert auf der schrittweisen Näherung. Beim AVR müssen die Pins '''AGND''' und '''AVCC''' beschaltet werden. Für genaue Messungen sollte AVCC über ein L-C Netzwerk mit VCC verbunden werden, um Spannungsspitzen und -einbrüche vom Analog-Digital-Wandler fernzuhalten. Im Datenblatt findet sich dazu eine Schaltung, die 10uH und 100nF vorsieht.<br />
<br />
Das Ergebnis der Analog-Digital-Wandlung wird auf eine Referenzspannung bezogen. Aktuelle AVRs bieten 3 Möglichkeiten zur Wahl dieser Spannung:<br />
<br />
* Eine externe Referenzspannung von maximal '''Vcc''' am Anschlusspin '''AREF'''. Die minimale (externe) Referenzspannung darf jedoch nicht beliebig niedrig sein, vgl. dazu das (aktuellste) Datenblatt des verwendeten Controllers. <br />
<br />
* Verfügt der AVR über eine interne Referenzspannung, kann diese genutzt werden. Alle aktuellen AVRs mit internem AD-Wandler sollten damit ausgestattet sein (vgl. Datenblatt: 2,56V oder 1,1V je nach Typ). Das Datenblatt gibt auch über die Genauigkeit dieser Spannung Auskunft.<br />
<br />
* Es kann die Spannung AVcc als Referenzspannung herangezogen werden<br />
<br />
Bei Nutzung von AVcc oder der internen Referenz wird empfohlen, einen Kondensator zwischen dem AREF-Pin und GND anzuordnen. Die Festlegung, welche Spannungsreferenz genutzt wird, erfolgt z.B. beim ATmega16 mit den Bits REFS1/REFS0 im ADMUX-Register. Die zu messende Spannung muss im Bereich zwischen '''AGND''' und '''AREF''' (egal ob intern oder extern) liegen. <br />
<br />
Der '''ADC''' kann in zwei verschiedenen Betriebsarten verwendet werden:<br />
<br />
; Einfache Wandlung (Single Conversion) : In dieser Betriebsart wird der Wandler bei Bedarf vom Programm angestoßen für jeweils eine Messung.<br />
<br />
; Frei laufend (Free Running) : In dieser Betriebsart erfasst der Wandler permanent die anliegende Spannung und schreibt diese in das '''ADC Data Register'''.<br />
<br />
==== Die Register des ADC ====<br />
<br />
Der '''ADC''' verfügt über eigene Register. Im Folgenden die Registerbeschreibung eines ATMega16, welcher über 8 ADC-Kanäle verfügt. Die Register unterscheiden sich jedoch nicht erheblich von denen anderer AVRs (vgl. Datenblatt).<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''ADCSRA&nbsp;&nbsp;&nbsp;'''<br />
| '''ADC''' '''C'''ontrol and '''S'''tatus '''R'''egister A.<br /><br />
In diesem Register stellen wir ein, wie wir den '''ADC''' verwenden möchten.<br /><br />
Das Register ist wie folgt aufgebaut:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0<br />
|- <br />
! Name<br />
| '''ADEN'''|| '''ADSC'''|| '''ADFR'''|| '''ADIF'''|| '''ADIE'''|| '''ADPS2'''|| '''ADPS1'''|| '''ADPS0'''<br />
|- <br />
! R/W<br />
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
<br />
'''ADEN''' ('''AD'''C '''En'''able)<br />
:Dieses Bit muss gesetzt werden, um den ''' ADC''' überhaupt zu aktivieren. Wenn das Bit nicht gesetzt ist, können die Pins wie normale I/O-Pins verwendet werden.<br />
<br />
'''ADSC''' ('''AD'''C '''S'''tart '''C'''onversion)<br />
:Mit diesem Bit wird ein Messvorgang gestartet. In der frei laufenden Betriebsart muss das Bit gesetzt werden, um die kontinuierliche Messung zu aktivieren.<br />
:Wenn das Bit nach dem Setzen des '''ADEN'''-Bits zum ersten Mal gesetzt wird, führt der Controller zuerst eine zusätzliche Wandlung und erst dann die eigentliche Wandlung aus. Diese zusätzliche Wandlung wird zu Initialisierungszwecken durchgeführt.<br />
:Das Bit bleibt nun so lange auf 1, bis die Umwandlung abgeschlossen ist, im Initialisierungsfall entsprechend bis die zweite Umwandlung erfolgt ist und geht danach auf 0.<br />
<br />
'''ADFR''' ('''AD'''C '''F'''ree '''R'''un select)<br />
:Mit diesem Bit wird die Betriebsart eingestellt.<br />
:Ist das Bit auf 1 gesetzt arbeitet der ADC im Freerunning Modus. Dabei wird das Datenregister permanent aktualisiert. Ist das Bit hingegen auf 0 gesetzt macht der ADC nur eine Single Conversion. <br />
<br />
<br />
'''ADIF''' ('''AD'''C '''I'''nterrupt '''F'''lag)<br />
:Dieses Bit wird vom ''' ADC''' gesetzt, sobald eine Umwandlung erfolgt ist und das '''ADC Data Register''' aktualisiert wurde. Das Bit wird bei lesendem Zugriff auf '''ADC(L,H)''' automatisch (d.h. durch die Hardware) gelöscht.<br />
:Wenn das '''ADIE''' Bit sowie das '''I-Bit''' im AVR '''Statusregister''' gesetzt ist, wird der '''ADC Interrupt''' ausgelöst und die Interrupt-Behandlungsroutine aufgerufen.<br />
:Das Bit wird automatisch gelöscht, wenn die Interrupt-Behandlungsroutine aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 in das Register geschrieben wird.<br />
<br />
'''ADIE''' ('''AD'''C '''I'''nterrupt '''E'''nable)<br />
:Wenn dieses Bit gesetzt ist und ebenso das ''' I-Bit''' im Statusregister '''SREG''', dann wird der ''' ADC-Interrupt''' aktiviert.<br />
<br />
'''ADPS2...ADPS0''' ('''AD'''C '''P'''rescaler '''S'''elect Bits)<br />
:Diese Bits bestimmen den Teilungsfaktor zwischen der Taktfrequenz und dem Eingangstakt des '''ADC'''.<br />
:Der '''ADC''' benötigt einen eigenen Takt, welchen er sich selber aus der CPU-Taktfreqenz erzeugt. Der '''ADC'''-Takt sollte zwischen 50 und 200kHz sein.<br />
:Der Vorteiler muss also so eingestellt werden, dass die CPU-Taktfrequenz dividiert durch den Teilungsfaktor einen Wert zwischen 50-200kHz ergibt.<br />
:Bei einer CPU-Taktfrequenz von 4MHz beispielsweise rechnen wir<br />
<br />
:<math><br />
\begin{matrix}<br />
TF_{min}=\frac{CLK}{200\,\mathrm{kHz}}=\frac{4000000}{200000}=\mathbf{20}<br />
\\<br />
\\<br />
TF_{max}=\frac{CLK}{50\,\mathrm{kHz}}=\frac{4000000}{50000}=\mathbf{80}<br />
\end{matrix}<br />
</math><br />
<br />
:Somit kann hier der Teilungsfaktor 32 oder 64 verwendet werden. Im Interesse der schnelleren Wandlungszeit werden wir hier den Faktor 32 einstellen.<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|-<br />
! '''ADPS2'''|| '''ADPS1'''|| '''ADPS0'''|| '''Teilungsfaktor'''<br />
|-<br />
| 0|| 0|| 0|| 2<br />
|-<br />
| 0|| 0|| 1|| 2<br />
|-<br />
| 0|| 1|| 0|| 4<br />
|-<br />
| 0|| 1|| 1|| 8<br />
|-<br />
| 1|| 0|| 0|| 16<br />
|-<br />
| 1|| 0|| 1|| 32<br />
|-<br />
| 1|| 1|| 0|| 64<br />
|-<br />
| 1|| 1|| 1|| 128<br />
|}<br />
<br />
|- <br />
| '''ADCL'''<br /><br />
'''ADCH'''<br />
| '''ADC ''' Data Register<br /><br />
Wenn eine Umwandlung abgeschlossen ist, befindet sich der gemessene Wert in<br />
diesen beiden Registern. Von '''ADCH''' werden nur die beiden niederwertigsten Bits verwendet. Es müssen immer beide Register ausgelesen werden, und zwar immer '''in der Reihenfolge: ADCL, ADCH'''. <br />
Der effektive Messwert ergibt sich dann zu:<br />
<br />
<c><br />
x = ADCL; // mit uint16_t x<br />
x += (ADCH<<8); // in zwei Zeilen (LSB/MSB-Reihenfolge und<br />
// C-Operatorpriorität sichergestellt)<br />
</c><br />
<br />
oder <br />
<br />
<c><br />
x = ADCW; // je nach AVR auch x = ADC (siehe avr/ioxxx.h)<br />
</c><br />
<br />
|- <br />
| '''ADMUX&nbsp;&nbsp;'''<br />
| '''AD'''C '''Mu'''ltiple'''x'''er Select Register<br /><br />
Mit diesem Register wird der zu messende Kanal ausgewählt. Beim 90S8535<br />
kann jeder Pin von Port A als '''ADC'''-Eingang verwendet werden (=8 Kanäle).<br /><br />
Das Register ist wie folgt aufgebaut:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0<br />
|- <br />
! Name<br />
| '''REFS1'''|| '''REFS0'''|| '''ADLAR'''|| '''MUX4'''|| '''MUX3'''|| '''MUX2'''|| '''MUX1'''|| '''MUX0'''<br />
|- <br />
! '''R/W'''<br />
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
<br />
'''REFS1...REFS0''' ('''Ref'''erence'''S'''election Bits)<br />
:Mit diesen Bits kann die Referenzspannung eingestellt werden:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! '''REFS1'''|| '''REFS0'''|| '''Referenzspanung'''<br />
|-<br />
| 0|| 0|| Externes AREF<br />
|-<br />
| 0|| 1|| AVCC als Referenz<br />
|-<br />
| 1|| 0|| Reserviert<br />
|-<br />
| 1|| 1|| Interne 2,56 Volt<br />
|}<br />
<br />
<br />
'''ADLAR''' ('''ADC ''' '''L'''eft '''A'''djust '''R'''esult)<br />
:Das ADLAR Bit verändert das Aussehen des Ergebnisses der AD-Wandlung. Bei einer logischen 1 wird das Ergebnis linksbündig ausgegeben, bei einer 0 rechtsbündig. Eine Änderung in diesem Bit beeinflusst das Ergebnis sofort, ganz egal ob bereits eine Wandlung läuft.<br />
<br />
<br />
'''MUX4...MUX0'''<br />
:Mit diesen 5 Bits wird der zu messende Kanal bestimmt. Wenn man einen einfachen 1-kanaligen ADC verwendet wird einfach die entsprechende Pinnummer des Ports in die Bits 0...2 eingeschrieben.<br />
:Wenn das Register beschrieben wird, während dem eine Umwandlung läuft, so wird zuerst die aktuelle Umwandlung auf dem bisherigen Kanal beendet. Dies ist vor allem beim frei laufenden Betrieb zu berücksichtigen.<br />
<br />
:Eine Empfehlung ist deswegen diese, dass der frei laufende Betrieb nur bei einem einzelnen zu verwendenden Analogeingang verwendet werden sollte, wenn man sich Probleme bei der Umschalterei ersparen will.<br />
|}<br />
<br />
==== Aktivieren des ADC ====<br />
<br />
Um den ''' ADC''' zu aktivieren, müssen wir das '''ADEN'''-Bit im '''ADCSR'''-Register<br />
setzen. Im gleichen Schritt legen wir auch gleich die Betriebsart fest. <br />
<br />
Ein kleines Beispiel für den "single conversion"-Mode bei einem ATmega169 und Nutzung der internen Referenzspannung (beim '169 1,1V bei anderen AVRs auch 2,56V). D.h. das Eingangssignal darf diese Spannung nicht überschreiten, gegebenenfalls mit Spannungsteiler einstellen. Ergebnis der Routine ist der ADC-Wert, also 0 für 0-Volt und 1023 für V_ref-Volt.<br />
<br />
<c><br />
uint16_t ReadChannel(uint8_t mux)<br />
{<br />
uint8_t i;<br />
uint16_t result;<br />
<br />
ADMUX = mux; // Kanal waehlen<br />
ADMUX |= (1<<REFS1) | (1<<REFS0); // interne Referenzspannung nutzen<br />
<br />
ADCSRA = (1<<ADEN) | (1<<ADPS1) | (1<<ADPS0); // Frequenzvorteiler <br />
// setzen auf 8 (1) und ADC aktivieren (1)<br />
<br />
/* nach Aktivieren des ADC wird ein "Dummy-Readout" empfohlen, man liest<br />
also einen Wert und verwirft diesen, um den ADC "warmlaufen zu lassen" */<br />
ADCSRA |= (1<<ADSC); // eine ADC-Wandlung <br />
while ( ADCSRA & (1<<ADSC) ) {<br />
; // auf Abschluss der Konvertierung warten <br />
}<br />
result = ADCW; // ADCW muss einmal gelesen werden,<br />
// sonst wird Ergebnis der nächsten Wandlung<br />
// nicht übernommen.<br />
<br />
/* Eigentliche Messung - Mittelwert aus 4 aufeinanderfolgenden Wandlungen */<br />
result = 0; <br />
for( i=0; i<4; i++ )<br />
{<br />
ADCSRA |= (1<<ADSC); // eine Wandlung "single conversion"<br />
while ( ADCSRA & (1<<ADSC) ) {<br />
; // auf Abschluss der Konvertierung warten<br />
}<br />
result += ADCW; // Wandlungsergebnisse aufaddieren<br />
}<br />
ADCSRA &= ~(1<<ADEN); // ADC deaktivieren (2)<br />
<br />
result /= 4; // Summe durch vier teilen = arithm. Mittelwert<br />
<br />
return result;<br />
}<br />
<br />
...<br />
<br />
/* Beispielaufrufe: */<br />
<br />
void foo(void)<br />
{<br />
uint16_t adcval;<br />
<br />
adcval = ReadChannel(0); /* MUX-Bits auf 0b0000 -> Channel 0 */<br />
...<br />
adcval = ReadChannel(2); /* MUX-Bits auf 0b0010 -> Channel 2 */<br />
...<br />
}<br />
<br />
</c><br />
<br />
Im Beispiel wird bei jedem Aufruf der ADC aktiviert und nach der Wandlung wieder abgeschaltet, das spart Strom. Will man dies nicht, verschiebt man die mit (1) gekennzeichneten Zeilen in eine Funktion adc_init() o.ä. und löscht die mit (2) markierten Zeilen. <br />
<br />
<!-- <br />
Das Löschen des ADIF-Flags sollte, '''entgegen''' der [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_intbits FAQ], mit<br />
<c><br />
...<br />
ADCSRA |= (1<<ADIF);<br />
...<br />
</c><br />
erfolgen. Die Methode in der FAQ eignet sich nur für Register in denen '''nur''' Interrupt-Flags stehen.<br />
--><br />
<br />
=== Analog-Digital-Wandlung ohne internen ADC ===<br />
<br />
==== Messen eines Widerstandes ====<br />
<br />
[[Image:Poti.gif|framed|right]]<br />
Analoge Werte lassen sich ohne Analog-Digital-Wandler auch indirekt ermitteln. Im Folgenden wird die Messung des an einem Potentiometer eingestellten Widerstands anhand der Ladekurve eines Kondensators erläutert. Bei dieser Methode wird nur ein Portpin benötigt, ein Analog-Digital-Wandler oder Analog-Comparator ist nicht erforderlich. Es wird dazu ein Kondensator und der Widerstand (das Potentiometer) in Reihe zwischen Vorsorgungsspannung und Masse/GND geschaltet (sogen. RC-Netzwerk). Zusätzlich wird eine Verbindung der Leitung zwischen Kondensator und Potentiometer zu einem Portpin des Controllers hergestellt. Die folgende Abbildung verdeutlicht die erforderliche Schaltung. <br />
<br />
Wird der Portpin des Controllers auf Ausgang konfiguriert (im Beispiel ''DDRD&nbsp;|=&nbsp;(1<<PD2)'') und dieser Ausgang auf Logisch 1 ("High", ''PORTD&nbsp;|=&nbsp;(1<<PD2)'') geschaltet, liegt an beiden "Platten" des Kondensators das gleiche Potential '''VCC''' an und der Kondensator somit entladen. (Klingt komisch, mit ''' Vcc''' entladen, ist aber so, da an beiden Seiten des Kondensators das gleiche Potential anliegt und somit eine Potentialdifferenz von 0V besteht => Kondensator ist entladen).<br />
<br />
Nach einer gewissen Zeit ist der Kondensator entladen und der Portpin wird als Eingang konfiguriert (''DDRD&nbsp;&=&nbsp;~(1<<PD2); PORTD&nbsp;&=&nbsp;~(1<<PD2)''), wodurch dieser hochohmig wird. Der Status des Eingangspin (in PIND) ist Logisch 1 (High). Der Kondensator lädt sich jetzt über das Poti auf, dabei steigt der Spannungsabfall über dem Kondensator und derjenige über dem Poti sinkt. Fällt nun der Spannungsabfall über dem Poti unter die Thresholdspannung des Eingangspins (2/5 Vcc, also ca. 2V), wird das Eingangssignal als LOW erkannt (Bit in PIND wird 0). Die Zeitspanne zwischen der Umschaltung von Entladung auf Aufladung und dem Wechsel des Eingangssignals von High auf Low ist ein Maß für den am Potentiometer eingestellten Widerstand. Zur Zeitmessung kann einer der im Controller vorhandenen Timer genutzt werden. Der 220 Ohm Widerstand dient dem Schutz des Controllers. Es würde sonst bei Maximaleinstellung des Potentionmeters (hier 0 Ohm) ein zu hoher Strom fließen, der die Ausgangsstufe des Controllers zerstört. <br />
<br />
Mit einem weiteren Eingangspin und ein wenig Software können wir auch eine Kalibrierung realisieren, um den Messwert in einen vernünftigen Bereich (z.B: 0...100 % oder so) umzurechnen. <br />
<br />
<!-- Link 404 => auskommentiert, mthomas 9.2.2008 <br />
Ein Beispielprogramm findet sich auf [http://www.mypage.bluewin.ch/ch_schifferle/ Christian Schifferles Web-Seite] im Archiv ''ATMEL.ZIP'', welches unter den Titel ''Tutorial "Programmieren mit C für Atmel Mikrocontroller'' heruntergeladen werden kann. --><br />
<br />
==== ADC über Komparator ====<br />
<br />
[[Image:ADC ueber Komparator.gif|framed|right]]<br />
Es gibt einen weiteren Weg, eine analoge Spannung mit Hilfe des<br />
Komparators, welcher in fast jedem AVR integriert ist, zu messen. Siehe dazu<br />
auch die Application Note AVR400 von Atmel.<br />
<br />
Dabei wird das zu messende Signal auf den invertierenden Eingang<br />
des Komparators geführt. Zusätzlich wird ein Referenzsignal an den nicht<br />
invertierenden Eingang des Komparators angeschlossen. Das Referenzsignal wird<br />
hier auch wieder über ein RC-Glied erzeugt, allerdings mit festen Werten für R<br />
und C.<br />
<br />
Das Prinzip der Messung ist nun dem vorhergehenden recht<br />
ähnlich. Durch Anlegen eines LOW-Pegels an Pin 2 wird der Kondensator zuerst<br />
einmal entladen. Auch hier muss darauf geachtet werden, dass der Entladevorgang<br />
genügend lang dauert.<br />
Nun wird Pin 2 auf HIGH gelegt. Der Kondensator wird geladen. Wenn die Spannung<br />
über dem Kondensator die am Eingangspin anliegende Spannung erreicht hat<br />
schaltet der Komparator durch. Die Zeit, welche benötigt wird, um den<br />
Kondensator zu laden kann nun auch wieder als Maß für die Spannung an Pin 1<br />
herangezogen werden.<br />
<br />
Ich habe es mir gespart, diese Schaltung auch aufzubauen und<br />
zwar aus mehreren Gründen:<br />
<br />
# 3 Pins notwendig.<br />
# Genauigkeit vergleichbar mit einfacherer Lösung.<br />
# War einfach zu faul.<br />
<br />
Der Vorteil dieser Schaltung liegt allerdings darin, dass damit<br />
direkt Spannungen gemessen werden können.<br />
<br />
== DAC (Digital Analog Converter) ==<br />
<br />
Mit Hilfe eines Digital-Analog-Konverters ('''DAC''') können wir nun auch Analogsignale ausgeben. Es gibt hier mehrere Verfahren. <!-- Wenn wir beim ADC die Möglichkeit haben, mit externen Komponenten zu operieren, müssen wir bei der DAC-Wandlung mit dem auskommen, was der Controller selber zu bieten hat. --mt: hmm, richtig? verstaendlich? redundant? --><br />
<br />
=== DAC über mehrere digitale Ausgänge ===<br />
<br />
Wenn wir an den Ausgängen des Controllers ein entsprechendes<br />
Widerstandsnetzwerk aufbauen haben wir die Möglichkeit, durch die Ansteuerung<br />
der Ausgänge über den Widerständen einen Addierer aufzubauen, mit dessen<br />
Hilfe wir eine dem Zahlenwert proportionale Spannung erzeugen können. Das<br />
Schaltbild dazu kann etwa so aussehen:<br />
<br />
[[Image:DAC R2R.gif]]<br />
<br />
Es sollten selbstverständlich möglichst genaue Widerstände verwendet<br />
werden, also nicht unbedingt solche mit einer Toleranz von 10% oder mehr.<br />
Weiterhin empfiehlt es sich, je nach Anwendung den Ausgangsstrom über einen<br />
Operationsverstärker zu verstärken.<br />
<br />
=== PWM (Pulsweitenmodulation) ===<br />
<br />
Wir kommen nun zu einem Thema, welches in aller Munde ist, aber viele<br />
Anwender verstehen nicht ganz, wie [[PWM]] eigentlich funktioniert.<br />
<br />
Wie wir alle wissen, ist ein Mikrocontroller ein rein digitales Bauteil.<br />
Definieren wir einen Pin als Ausgang, dann können wir diesen Ausgang entweder<br />
auf HIGH setzen, worauf am Ausgang die Versorgungsspannung ''' Vcc''' anliegt, oder aber wir setzen den Ausgang auf LOW, wonach dann ''' 0V''' am Ausgang liegt. Was passiert aber nun, wenn wir periodisch mit einer festen Frequenz zwischen HIGH und LOW umschalten? - Richtig, wir erhalten eine Rechteckspannung, wie die folgende Abbildung zeigt:<br />
<br />
[[Image:PWM Theorie 1.gif]]<br />
<br />
Diese Rechteckspannung hat nun einen arithmetischen Mittelwert, <br />
der je nach Pulsbreite kleiner oder größer ist.<br />
<br />
[[Image:PWM Theorie 2.gif]]<br />
<br />
Wenn wir nun diese pulsierende Ausgangsspannung noch über ein RC-Glied filtern/"glätten", dann haben wir schon eine entsprechende Gleichspannung erzeugt.<br />
<br />
Mit den AVRs können wir direkt PWM-Signale erzeugen. <br />
Dazu dient der 16-Bit Zähler, welcher im sogenannten PWM-Modus betrieben werden kann.<br />
<br />
;Hinweis: In den folgenden Überlegungen wird als Controller der 90S2313 vorausgesetzt. Die Theorie ist bei anderen AVR-Controllern vergleichbar, die Pinbelegung allerdings nicht unbedingt, weshalb ein Blick ins entsprechende Datenblatt dringend angeraten wird.<br />
<br />
Um den PWM-Modus zu aktivieren, müssen im Timer/Counter1 Control<br />
Register A TCCR1A die Pulsweiten-Modulatorbits PWM10 bzw. PWM11 entsprechend nachfolgender Tabelle gesetzt werden:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! PWM11 || PWM10 || Bedeutung<br />
|- <br />
| 0 || 0 || PWM-Modus des Timers ist nicht aktiv<br />
|- <br />
| 0 || 1 || 8-Bit PWM<br />
|- <br />
| 1 || 0 || 9-Bit PWM<br />
|- <br />
| 1 || 1 || 10-Bit PWM<br />
|}<br />
<br />
Der Timer/Counter zählt nun permanent von 0 bis zur Obergrenze<br />
und wieder zurück, er wird also als sogenannter Auf-/Ab Zähler betrieben. <br />
Die Obergrenze hängt davon ab, ob wir mit 8, 9 oder 10-Bit PWM arbeiten wollen:<br />
<br />
{| class="wikitable"<br />
|- <br />
! Auflösung || Obergrenze || Frequenz<br />
|- <br />
| align="center" | 8<br />
| align="center" | 255<br />
| f<sub>TC1</sub> / 510<br />
|- <br />
| align="center" | 9<br />
| align="center" | 511<br />
| f<sub>TC1</sub> / 1022<br />
|- <br />
| align="center" | 10<br />
| align="center" | 1023<br />
| f<sub>TC1</sub> / 2046<br />
|}<br />
<br />
Zusätzlich muss mit den Bits '''COM1A1''' und '''COM1A0''' desselben<br />
Registers die gewünschte Ausgabeart des Signals definiert werden:<br />
<br />
{| class="wikitable"<br />
|- <br />
! COM1A1 || COM1A0 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Keine Wirkung, Pin wird nicht geschaltet.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Keine Wirkung, Pin wird nicht geschaltet.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Nicht invertierende PWM.<br /><br />
Der Ausgangspin wird gelöscht beim Hochzählen und gesetzt beim<br />
Herunterzählen.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Invertierende PWM.<br /><br />
Der Ausgangspin wird gelöscht beim Herunterzählen und gesetzt beim<br />
Hochzählen.<br />
|}<br />
<br />
Der entsprechende Befehl, um beispielsweise den Timer/Counter als<br />
nicht invertierenden 10-Bit PWM zu verwenden, heißt dann:<br />
<br />
alte Schreibweise (PWMxx wird nicht mehr akzeptiert)<br />
<c><br />
TCCR1A = (1<<PWM11)|(1<<PWM10)|(1<<COM1A1);<br />
</c><br />
neue Schreibweise<br />
<c><br />
TCCR1A = (1<<WGM11)|(1<<WGM10)|(1<<COM1A1);<br />
</c><br />
<br />
Damit der Timer/Counter überhaupt läuft, müssen wir im Control<br />
Register B '''TCCR1B''' noch den gewünschten Takt (Vorteiler) einstellen und<br />
somit auch die Frequenz des '''PWM'''-Signals bestimmen.<br />
<br />
{| class="wikitable"<br />
|- <br />
! CS12 || CS11 || CS10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| align="center" | 0<br />
| Stop. Der Timer/Counter wird gestoppt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| align="center" | 1<br />
| CK<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| align="center" | 0<br />
| CK / 8<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| align="center" | 1<br />
| CK / 64<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| align="center" | 0<br />
| CK / 256<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| align="center" | 1<br />
| CK / 1024<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| align="center" | 0<br />
| Externer Pin 1, negative Flanke<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| align="center" | 1<br />
| Externer Pin 1, positive Flanke<br />
|}<br />
<br />
Also um einen Takt von CK / 1024 zu generieren, verwenden wir<br />
folgenden Befehl:<br />
<br />
<c><br />
TCCR1B = (1<<CS12) | (1<<CS10);<br />
</c><br />
<br />
Jetzt muss nur noch der Vergleichswert festgelegt werden. Diesen<br />
schreiben wir in das 16-Bit Timer/Counter Output Compare Register '''OCR1A'''.<br />
<br />
<c><br />
OCR1A = xxx;<br />
</c><br />
<br />
Die folgende Grafik soll den Zusammenhang zwischen dem Vergleichswert und dem generierten '''PWM'''-Signal aufzeigen.<br />
<br />
[[Image:PWM Theorie 3.gif]]<br />
<br />
[[Image:PWM Theorie 4.gif]]<br />
<br />
Ach ja, fast hätte ich's vergessen. Das generierte '''PWM'''-Signal<br />
wird am Output Compare Pin '''OC1''' des Timers ausgegeben und leider können wir<br />
deshalb auch beim AT90S2313 nur ein einzelnes '''PWM'''-Signal mit dieser Methode generieren. Andere AVR-Typen verfügen über bis zu vier PWM-Ausgänge. Zu beachten ist außerdem, das wenn der OC Pin aktiviert ist, er nichtmehr wie üblich funktioniert und z.B. nicht einfach über PINx ausgelesen werden kann.<br />
<br />
Ein Programm, welches an einem ATmega8 den Fast-PWM Modus verwendet, den Modus 14, könnte so aussehen<br />
<C><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// OC1A auf Ausgang<br />
DDRB = (1 << PB1 ); //ATMega8<br />
// DDRD = (1 << PD5 ); //ATMega16<br />
//<br />
// Timer 1 einstellen<br />
// <br />
// Modus 14:<br />
// Fast PWM, Top von ICR1<br />
//<br />
// WGM13 WGM12 WGM11 WGM10<br />
// 1 1 1 0<br />
//<br />
// Timer Vorteiler: 1<br />
// CS12 CS11 CS10<br />
// 0 0 1<br />
//<br />
// Steuerung des Ausgangsport: Set at BOTTOM, Clear at match<br />
// COM1A1 COM1A0<br />
// 1 0<br />
<br />
TCCR1A = (1<<COM1A1) | (1<<WGM11);<br />
TCCR1B = (1<<WGM13) | (1<<WGM12) | (1<<CS10);<br />
<br />
// den Endwert (TOP) für den Zähler setzen<br />
// der Zähler zählt bis zu diesem Wert<br />
<br />
ICR1 = 0x6FFF;<br />
<br />
// der Compare Wert<br />
// Wenn der Zähler diesen Wert erreicht, wird mit<br />
// obiger Konfiguration der OC1A Ausgang abgeschaltet<br />
// Sobald der Zähler wieder bei 0 startet, wird der<br />
// Ausgang wieder auf 1 gesetzt<br />
//<br />
// Durch Verändern dieses Wertes, werden die unterschiedlichen<br />
// PWM Werte eingestellt.<br />
<br />
OCR1A = 0x3FFF;<br />
<br />
while( 1 )<br />
; <br />
}<br />
</C><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|+ '''PWM-Mode Tabelle aus dem Datenblatt des ATmega8515'''<br />
|- <br />
!Mode || WGM13 || WGM12 || WGM11 || WGM10 || Timer/Counter Mode of Operation<br />
! TOP|| Update of OCR1x at || TOV1 Flag set on<br />
|- <br />
! 0<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
| Normal<br />
| 0xFFFF<br />
| Immediate<br />
| MAX<br />
|-<br />
! 1<br />
| 0<br />
| 0<br />
| 0<br />
| 1<br />
| PWM, Phase Correct, 8-Bit<br />
| 0x00FF<br />
| TOP<br />
| BOTTOM<br />
|- <br />
! 2<br />
| 0<br />
| 0<br />
| 1<br />
| 0<br />
| PWM, Phase Correct, 9-Bit<br />
| 0x01FF<br />
| TOP<br />
| BOTTOM<br />
|-<br />
! 3<br />
| 0<br />
| 0<br />
| 1<br />
| 1<br />
| PWM, Phase Correct, 10-Bit<br />
| 0x03FF<br />
| TOP<br />
| BOTTOM<br />
|-<br />
! 4<br />
| 0<br />
| 1<br />
| 0<br />
| 0<br />
| CTC<br />
| OCR1A<br />
| Immediate<br />
| MAX<br />
|-<br />
! 5<br />
| 0<br />
| 1<br />
| 0<br />
| 1<br />
| Fast PWM, 8-Bit<br />
| 0x00FF<br />
| BOTTOM<br />
| TOP<br />
|-<br />
! 6<br />
| 0<br />
| 1<br />
| 1<br />
| 0<br />
| Fast PWM, 9-Bit<br />
| 0x01FF<br />
| BOTTOM<br />
| TOP<br />
|-<br />
! 7<br />
| 0<br />
| 1<br />
| 1<br />
| 1<br />
| Fast PWM, 10-Bit<br />
| 0x03FF<br />
| BOTTOM<br />
| TOP<br />
|-<br />
! 8<br />
| 1<br />
| 0<br />
| 0<br />
| 0<br />
| PWM, Phase an Frequency Correct<br />
| ICR1<br />
| BOTTOM<br />
| BOTTOM<br />
|- <br />
! 9<br />
| 1<br />
| 0<br />
| 0<br />
| 1<br />
| PWM, Phase an Frequency Correct<br />
| OCR1A<br />
| BOTTOM<br />
| BOTTOM<br />
|-<br />
! 10<br />
| 1<br />
| 0<br />
| 1<br />
| 0<br />
| PWM, Phase Correct<br />
| ICR1<br />
| TOP<br />
| BOTTOM<br />
|-<br />
! 11<br />
| 1<br />
| 0<br />
| 1<br />
| 1<br />
| PWM, Phase an Frequency Correct<br />
| OCR1A<br />
| TOP<br />
| BOTTOM<br />
|-<br />
! 12<br />
| 1<br />
| 1<br />
| 0<br />
| 0<br />
| CTC<br />
| ICR1<br />
| Immediate<br />
| MAX<br />
|-<br />
! 13<br />
| 1<br />
| 1<br />
| 0<br />
| 1<br />
| Reserved<br />
| -<br />
| -<br />
| -<br />
|-<br />
! 14<br />
| 1<br />
| 1<br />
| 1<br />
| 0<br />
| Fast PWM<br />
| ICR1<br />
| BOTTOM<br />
| TOP<br />
|-<br />
! 15<br />
| 1<br />
| 1<br />
| 1<br />
| 1<br />
| Fast PWM<br />
| OCR1A<br />
| BOTTOM<br />
| TOP<br />
|}<br />
<br />
Für Details der PWM Möglichkeiten, muß immer das jeweilge Datenblatt des Prozessors konsultiert werden, da sich die unterschiedlichen Prozessoren in ihren Möglichkeiten doch stark unterscheiden. Auch muß man aufpassen, welches zu setzende Bit in welchem Register sind. Auch hier kann es sein, dass gleichnamige Konfigurationsbits in unterschiedlichen Konfigurationsregistern (je nach konkretem Prozessortyp) sitzen.<br />
<br />
= LCD-Ansteuerung =<br />
<br />
==Das LCD und sein Controller==<br />
<br />
Die meisten Text-LCDs verwenden den Controller [[HD44780|'''HD44780''']] oder einen kompatiblen (z.B. KS0070) und haben 14 oder 16 Pins. Die Pinbelegung an der LCD-Controller-Platine ist praktisch immer gleich. Trotzdem lohnt sich ein Blick in das Datenblatt des Displays, da es gelegentlich Ausnahmen gibt. Die normale Pinbelegung sieht wie folgt aus:<br />
<br />
<table width="0"><br />
<tr><th width="50" align="left">Pin #</th><th width="70" align="left">Bezeichnung</th><th align="left">Funktion</th></tr><br />
<tr><td>'''1'''</td><td>Vss</td><td>GND</td></tr> <br />
<tr><td>'''2'''</td><td>Vcc</td><td>5V</td></tr> <br />
<tr><td>'''3'''</td><td>Vee</td><td>Kontrastspannung (0V bis 5V)</td></tr> <br />
<tr><td>'''4'''</td><td>RS</td><td>Register Select (Befehle/Daten)</td></tr> <br />
<tr><td>'''5'''</td><td>RW</td><td>Read/Write</td></tr> <br />
<tr><td>'''6'''</td><td>E</td><td>Enable</td></tr> <br />
<tr><td>'''7'''</td><td>DB0</td><td>Datenbit 0</td></tr> <br />
<tr><td>'''8'''</td><td>DB1</td><td>Datenbit 1</td></tr> <br />
<tr><td>'''9'''</td><td>DB2</td><td>Datenbit 2</td></tr> <br />
<tr><td>'''10'''</td><td>DB3</td><td>Datenbit 3</td></tr> <br />
<tr><td>'''11'''</td><td>DB4</td><td>Datenbit 4</td></tr> <br />
<tr><td>'''12'''</td><td>DB5</td><td>Datenbit 5</td></tr> <br />
<tr><td>'''13'''</td><td>DB6</td><td>Datenbit 6</td></tr> <br />
<tr><td>'''14'''</td><td>DB7</td><td>Datenbit 7</td></tr> <br />
<tr><td>'''15'''</td><td>A</td><td>LED-Beleuchtung, Anode</td></tr><br />
<tr><td>'''16'''</td><td>K</td><td>LED-Beleuchtung, Kathode</td></tr><br />
</table><br />
<br />
Achtung: Unbedingt von der richtigen Seite zu zählen anfangen! Meistens ist neben Pin 1 eine kleine 1 auf der LCD-Platine, ansonsten im Datenblatt nachschauen. <br />
<br />
Bei LCDs mit 16-poligem Anschluss sind die beiden letzten Pins für die Hintergrundbeleuchtung reserviert. Hier unbedingt das Datenblatt zu Rate ziehen, die beiden Anschlüsse sind je nach Hersteller verdreht beschaltet. Falls kein Datenblatt vorliegt, kann man mit einem Durchgangsprüfer feststellen, welcher Anschluss mit Masse (GND) verbunden ist.<br />
<br />
Vss wird ganz einfach an GND angeschlossen und Vcc an 5V. Vee kann man testweise auch an GND legen. Wenn das LCD dann zu dunkel sein sollte muss man ein 10k-Potentiometer zwischen GND und 5V schalten, mit dem Schleifer an Vee: <br />
<br />
[[Bild:LCD_Vee.gif]]<br />
<br />
Es gibt zwei verschiedene Möglichkeiten zur Ansteuerung eines solchen Displays: den '''8-bit-''' und den '''4-bit-'''Modus.<br />
* Für den '''8-bit-Modus''' werden (wie der Name schon sagt) alle acht Datenleitungen zur Ansteuerung verwendet, somit kann durch einen Zugriff immer ein ganzes Byte übertragen werden.<br />
* Der '''4-bit-Modus''' verwendet nur die oberen vier Datenleitungen ('''DB4-DB7'''). Um ein Byte zu übertragen braucht man somit zwei Zugriffe, wobei zuerst das höherwertige '''"Nibble"''' (= 4 Bits), also Bit 4 bis Bit 7 übertragen wird und dann das niederwertige, also Bit 0 bis Bit 3. Die unteren Datenleitungen des LCDs, die beim Lesezyklus Ausgänge sind, lässt man offen (siehe Datasheets, z.B. vom KS0070).<br />
<br />
Der 4-bit-Modus hat den Vorteil, dass man 4 IO-Pins weniger benötigt als beim 8-bit-Modus, weshalb ich mich hier für eine Ansteuerung mit 4bit entschieden habe. <br />
<br />
Neben den vier Datenleitungen (DB4, DB5, DB6 und DB7) werden noch die Anschlüsse '''RS''', '''RW''' und '''E''' (ist in manchen Unterlagen auch '''EN''' für ''Enable'' abgekürzt) benötigt. <br />
<br />
* Über '''RS''' wird ausgewählt, ob man einen Befehl oder ein Datenbyte an das LCD schicken möchte. Ist RS Low, dann wird das ankommende Byte als Befehl interpretiert, ist RS high, dann wird das Byte auf dem LCD angezeigt. <br />
* '''RW''' legt fest, ob geschrieben oder gelesen werden soll. High bedeutet lesen, low bedeutet schreiben. Wenn man RW auf lesen einstellt und RS auf Befehl, dann kann man das '''Busy-Flag''' an DB7 lesen, das anzeigt, ob das LCD den vorhergehenden Befehl fertig verarbeitetet hat (diese Methode u.a. in der LCD-Library von Peter Fleury verwendet). Ist RS auf Daten eingestellt, dann kann man z.B. den Inhalt des Displays lesen - was jedoch nur in den wenigsten Fällen Sinn macht. Deshalb kann man RW dauerhaft auf low lassen (= an GND anschließen), so dass man noch ein IO-Pin am Controller einspart. Der Nachteil ist, dass man dann das Busy-Flag nicht lesen kann, weswegen man nach jedem Befehl vorsichtshalber ein paar Mikrosekunden warten sollte, um dem LCD Zeit zum Ausführen des Befehls zu geben. Dummerweise schwankt die Ausführungszeit von Display zu Display und ist auch von der Betriebsspannung abhängig. Für professionellere Sachen also lieber den IO-Pin opfern und Busy abfragen.<br />
* Der '''E''' Anschluss schließlich signalisiert dem LCD, dass die übrigen Datenleitungen jetzt korrekte Pegel angenommen haben und es die gewünschten Daten von den Datenleitungen bzw. Kommandos von den Datenleitungen übernehmen kann.<br />
<br />
== Anschluss an den Controller ==<br />
<br />
Jetzt da wir wissen, welche Anschlüsse das LCDs benötigt, können wir das LCD mit dem Mikrocontroller verbinden: <br />
<br />
<table width="0"><br />
<tr><th align="left">Pin #-LCD</th><th align="left">Bezeichnung-LCD</th><th align="left">Pin-µC</th></tr><br />
<tr><td>'''1'''</td><td>Vss</td><td>GND</td></tr><br />
<tr><td>'''2'''</td><td>Vcc</td><td>5V</td></tr><br />
<tr><td>'''3'''</td><td>Vee</td><td>GND oder Poti (siehe oben)</td></tr> <br />
<tr><td>'''4'''</td><td>RS</td><td>PD4 am AVR</td></tr> <br />
<tr><td>'''5'''</td><td>RW</td><td>GND</td></tr> <br />
<tr><td>'''6'''</td><td>E</td><td>PD5 am AVR</td></tr> <br />
<tr><td>'''7'''</td><td>DB0</td><td>offen</td></tr> <br />
<tr><td>'''8'''</td><td>DB1</td><td>offen</td></tr> <br />
<tr><td>'''9'''</td><td>DB2</td><td>offen</td></tr> <br />
<tr><td>'''10'''</td><td>DB3</td><td>offen</td></tr> <br />
<tr><td>'''11'''</td><td>DB4</td><td>PD0 am AVR</td></tr> <br />
<tr><td>'''12'''</td><td>DB5</td><td>PD1 am AVR</td></tr> <br />
<tr><td>'''13'''</td><td>DB6</td><td>PD2 am AVR</td></tr> <br />
<tr><td>'''14'''</td><td>DB7</td><td>PD3 am AVR</td></tr> <br />
</table><br />
<br />
Wenn man die Steuerleitungen EN und RS auf Pins an einem anderen Port legen möchte, kann man so wie in diesem [http://www.mikrocontroller.net/topic/88543#751982 Forumsbeitrag] vorgehen.<br />
<br />
Ok, alles ist verbunden, wenn man jetzt den Strom einschaltet sollten ein oder zwei schwarze Balken auf dem Display angezeigt werden. Doch wie bekommt man jetzt die Befehle und Daten in das Display? <br />
<br />
== Programmierung ==<br />
Datei '''lcd-routines.h'''<br />
<c><br />
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus<br />
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial<br />
//<br />
void lcd_data(unsigned char temp1);<br />
void lcd_string(char *data);<br />
void lcd_command(unsigned char temp1);<br />
void lcd_enable(void);<br />
void lcd_init(void);<br />
void lcd_home(void);<br />
void lcd_clear(void);<br />
void set_cursor(uint8_t x, uint8_t y);<br />
<br />
// Hier die verwendete Taktfrequenz in Hz eintragen, wichtig!<br />
<br />
#define F_CPU 8000000<br />
<br />
// LCD Befehle<br />
<br />
#define CLEAR_DISPLAY 0x01<br />
#define CURSOR_HOME 0x02<br />
<br />
// Pinbelegung für das LCD, an verwendete Pins anpassen<br />
<br />
#define LCD_PORT PORTD<br />
#define LCD_DDR DDRD<br />
#define LCD_RS PD4<br />
#define LCD_EN PD5<br />
// DB4 bis DB7 des LCD sind mit PD0 bis PD3 des AVR verbunden<br />
</c><br />
<br />
Datei '''lcd-routines.c''':<br />
<c><br />
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus<br />
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial<br />
//<br />
// Die Pinbelegung ist über defines in lcd-routines.h einstellbar<br />
<br />
#include <avr/io.h><br />
#include "lcd-routines.h"<br />
#include <util/delay.h><br />
<br />
// sendet ein Datenbyte an das LCD<br />
<br />
void lcd_data(unsigned char temp1)<br />
{<br />
unsigned char temp2 = temp1;<br />
<br />
LCD_PORT |= (1<<LCD_RS); // RS auf 1 setzen<br />
<br />
temp1 = temp1 >> 4;<br />
temp1 = temp1 & 0x0F;<br />
LCD_PORT &= 0xF0;<br />
LCD_PORT |= temp1; // setzen<br />
lcd_enable();<br />
<br />
temp2 = temp2 & 0x0F;<br />
LCD_PORT &= 0xF0;<br />
LCD_PORT |= temp2; // setzen<br />
lcd_enable();<br />
<br />
_delay_us(42);<br />
}<br />
<br />
// sendet einen Befehl an das LCD<br />
<br />
void lcd_command(unsigned char temp1)<br />
{<br />
unsigned char temp2 = temp1;<br />
<br />
LCD_PORT &= ~(1<<LCD_RS); // RS auf 0 setzen<br />
<br />
temp1 = temp1 >> 4; // oberes Nibble holen<br />
temp1 = temp1 & 0x0F; // maskieren<br />
LCD_PORT &= 0xF0;<br />
LCD_PORT |= temp1; // setzen<br />
lcd_enable();<br />
<br />
temp2 = temp2 & 0x0F; // unteres Nibble holen und maskieren<br />
LCD_PORT &= 0xF0;<br />
LCD_PORT |= temp2; // setzen<br />
lcd_enable();<br />
<br />
_delay_us(42);<br />
}<br />
<br />
// erzeugt den Enable-Puls<br />
void lcd_enable(void)<br />
{<br />
// Bei Problemen ggf. Pause gemäß Datenblatt des LCD Controllers einfügen<br />
// http://www.mikrocontroller.net/topic/81974#685882<br />
LCD_PORT |= (1<<LCD_EN);<br />
_delay_us(1); // kurze Pause<br />
// Bei Problemen ggf. Pause gemäß Datenblatt des LCD Controllers verlängern<br />
// http://www.mikrocontroller.net/topic/80900<br />
LCD_PORT &= ~(1<<LCD_EN);<br />
}<br />
<br />
// Initialisierung: <br />
// Muss ganz am Anfang des Programms aufgerufen werden.<br />
<br />
void lcd_init(void)<br />
{<br />
LCD_DDR = LCD_DDR | 0x0F | (1<<LCD_RS) | (1<<LCD_EN); // Port auf Ausgang schalten<br />
<br />
// muss 3mal hintereinander gesendet werden zur Initialisierung<br />
<br />
_delay_ms(15);<br />
LCD_PORT &= 0xF0;<br />
LCD_PORT |= 0x03; <br />
LCD_PORT &= ~(1<<LCD_RS); // RS auf 0<br />
lcd_enable();<br />
<br />
_delay_ms(5);<br />
lcd_enable();<br />
<br />
_delay_ms(1);<br />
lcd_enable();<br />
_delay_ms(1);<br />
<br />
// 4 Bit Modus aktivieren <br />
LCD_PORT &= 0xF0;<br />
LCD_PORT |= 0x02;<br />
lcd_enable();<br />
_delay_ms(1);<br />
<br />
// 4Bit / 2 Zeilen / 5x7<br />
lcd_command(0x28);<br />
<br />
// Display ein / Cursor aus / kein Blinken<br />
lcd_command(0x0C); <br />
<br />
// inkrement / kein Scrollen<br />
lcd_command(0x06);<br />
<br />
lcd_clear();<br />
}<br />
<br />
// Sendet den Befehl zur Löschung des Displays<br />
<br />
void lcd_clear(void)<br />
{<br />
lcd_command(CLEAR_DISPLAY);<br />
_delay_ms(5);<br />
}<br />
<br />
// Sendet den Befehl: Cursor Home<br />
<br />
void lcd_home(void)<br />
{<br />
lcd_command(CURSOR_HOME);<br />
_delay_ms(5);<br />
}<br />
<br />
// setzt den Cursor in Zeile y (1..4) Spalte x (0..15)<br />
<br />
void set_cursor(uint8_t x, uint8_t y)<br />
{<br />
uint8_t tmp;<br />
<br />
switch (y) {<br />
case 1: tmp=0x80+0x00+x; break; // 1. Zeile<br />
case 2: tmp=0x80+0x40+x; break; // 2. Zeile<br />
case 3: tmp=0x80+0x10+x; break; // 3. Zeile<br />
case 4: tmp=0x80+0x50+x; break; // 4. Zeile<br />
default: return; // für den Fall einer falschen Zeile<br />
}<br />
lcd_command(tmp);<br />
}<br />
<br />
// Schreibt einen String auf das LCD<br />
<br />
void lcd_string(char *data)<br />
{<br />
while(*data) {<br />
lcd_data(*data);<br />
data++;<br />
}<br />
}<br />
</c><br />
<br />
Ein Hauptprogramm, welches die Funktionen benutzt, sieht zb. so aus:<br />
<br />
<c><br />
// <br />
// Anpassungen im makefile:<br />
// ATMega8 => MCU=atmega8 im makefile einstellen<br />
// lcd-routines.c in SRC = ... Zeile anhängen<br />
// <br />
#include <avr/io.h><br />
#include "lcd-routines.h"<br />
<br />
int main(void)<br />
{<br />
lcd_init();<br />
<br />
lcd_data('T');<br />
lcd_data('e');<br />
lcd_data('s');<br />
lcd_data('t');<br />
<br />
set_cursor(0,2);<br />
<br />
lcd_string("Hello World!");<br />
<br />
while(1)<br />
{<br />
}<br />
<br />
return 0;<br />
}<br />
</c><br />
<br />
Wichtig ist dabei, dass die Optimierung bei der Compilierung eingeschaltet ist, sonst stimmen die Zeiten der Funktionen _delay_us() und _delay_ms() nicht und der Code wird wesentlich länger (Siehe Dokumentation der libc im WinAVR).<br />
<br />
Ein Hauptprogramm, welches eine Variable ausgibt, sieht zb. so aus.<br />
Mittels der itoa() Funktion (itoa = <b>I</b>nteger <b>To</b> <b>A</b>scii ) wird von einem Zahlenwert eine textuelle Repräsentierung ermittelt (sprich: ein String erzeugt) und dieser String mit der bereits vorhandenen Funktion lcd_string ausgegeben:<br />
<br />
<c><br />
// <br />
// Anpassungen im makefile:<br />
// ATMega8 => MCU=atmega8 im makefile einstellen<br />
// lcd-routines.c in SRC = ... Zeile anhängen <br />
// <br />
#include <avr/io.h><br />
#include <stdlib.h><br />
#include "lcd-routines.h"<br />
<br />
// Beispiel<br />
int variable = 42;<br />
<br />
int main(void)<br />
{<br />
lcd_init();<br />
<br />
// Ausgabe des Zeichens dessen ASCII-Code gleich dem Variablenwert ist<br />
// (Im Beispiel entspricht der ASCII-Code 42 dem Zeichen *)<br />
// http://www.code-knacker.de/ascii.htm<br />
lcd_data(variable);<br />
<br />
set_cursor(0,2);<br />
<br />
// Ausgabe der Variable als Text in dezimaler Schreibweise<br />
{<br />
// ... umwandeln siehe FAQ Artikel bei www.mikrocontroller.net<br />
// WinAVR hat eine itoa()-Funktion, das erfordert obiges #include <stdlib.h><br />
char Buffer[20]; // in diesem {} lokal<br />
itoa( variable, Buffer, 10 ); <br />
<br />
// ... ausgeben <br />
lcd_string( Buffer );<br />
}<br />
<br />
while(1)<br />
{<br />
}<br />
<br />
return 0;<br />
}<br />
<br />
</c><br />
<br />
Beim Einrichten eines Projekts muss man zu der Datei mit dem Hauptprogramm auch die Datei lcd-routines.c in das Projekt aufnehmen. Dies geschieht beim AVR Studio unter Source Files im Fenster AVR GCC oder bei WinAVR im Makefile (z.B. durch SRC += lcd-routines.c).<br />
<br />
= Die Timer/Counter des AVR =<br />
<br />
Die heutigen Mikrocontroller und insbesondere die RISC-AVRs sind für viele Steuerungsaufgaben zu schnell. Wenn wir beispielsweise eine LED oder Lampe blinken lassen wollen, können wir selbstverständlich nicht die CPU-Frequenz verwenden, da ja dann nichts mehr vom Blinken zu bemerken wäre.<br />
<br />
Wir brauchen also eine Möglichkeit, Vorgänge in Zeitabständen durchzuführen, die geringer als die Taktfrequenz des Controllers sind. Selbstverständlich sollte die resultierende Frequenz auch noch möglichst genau und stabil sein.<br />
<br />
Hier kommen die im AVR vorhandenen Timer/Counter zum Einsatz.<br />
<br />
Ein Timer ist ganz einfach ein bestimmtes Register im µC, das völlig ohne Zutun des Programms, also per Hardware, hochgezählt wird. Das alleine wäre noch nicht allzu nützlich, wenn nicht dieses Hardwareregister bei bestimmten Zählerständen einen Interrupt auslösen könnte. Ein solches Ereignis ist der Overflow: Da die Bitbreite des Registers beschränkt ist, kommt es natürlich auch vor, dass der Zähler so hoch zählt, dass der nächste Zählerstand mit dieser Bitbreite nicht mehr darstellbar ist und der Zähler wieder auf 0 zurückgesetzt wird. Dieses Ereignis nennt man den Overflow und es ist möglich an dieses Ereignis einen Interrupt zu koppeln.<br />
<br />
<!-- Alternativvorschlag mthomas <br />
Jeder Timer verfügt über ein Zählerregister im Mikrocontroller, das automatisch und ohne Zutun des Programms von der Hardware weitergezählt wird. In einem einfachen Anwendungsfall stellt man den Timer auf eine Zählgeschwindigkeit (Frequenz) und kann dann anhand des Zählerstands ermitteln, wie viel Zeit vergangen ist. Das eigentlich Nützliche an Timern ist jedoch, dass man bestimmte Zählerstände mit Interrupts verknüpfen kann, so dass der Controller beim Auftreten automatisch eine vom Anwender geschriebene Routine aufruft. Eines dieser möglichen Ereignis ist der Overflow ((Zähler-)Überlauf), der dann auftritt, wenn der Wert des Zählerregisters (Timer/Counter-Register) den maximal möglichen Wert überschreitet. Der Maximalwert wird durch die Bitbreite des Zählerregisters bestimmt (z.B. 255 bei 8-Bit Timern). Beim Überlauf/Overflow wird der Zähler durch die Hardware auf 0 zurückgesetzt und die Zählung beginnt von neuem. Wurde vorher der Overflow-Interrupt für den Timer aktiviert (im Timer Control Register) unterbricht der Controller automatisch die Ausführung des Hauptprogramms und verzweigt in die Interrupt-Routine des Anwenders.<br />
--><br />
<br />
Ein anderes Anwendungsgebiet ist die Zählung von Signalen, welche über einen I/O-Pin zugeführt werden können.<br />
<br />
Die folgenden Ausführungen beziehen sich auf den AT90S2313. Für andere Modelltypen müsst ihr euch die allenfalls notwendigen Anpassungen aus den Datenblättern der entsprechenden Controller herauslesen.<br />
<br />
Wir unterscheiden grundsätzlich zwischen 8-Bit Timern, welche eine Auflösung von 256 aufweisen und 16-Bit Timern mit (logischerweise) einer Auflösung von 65536. Als Eingangstakt für die Timer/Counter kann entweder die CPU-Taktfrequenz, der Vorteiler-Ausgang oder ein an einen I/O-Pin angelegtes Signal verwendet werden. Wenn ein externes Signal verwendet wird, so darf dessen Frequenz nicht höher sein als die Hälfte des CPU-Taktes.<br />
<br />
== Der Vorteiler (Prescaler) ==<br />
<br />
Der Vorteiler dient dazu, den CPU-Takt vorerst um einen einstellbaren Faktor zu reduzieren. Die so geteilte Frequenz wird den Eingängen der Timer zugeführt.<br />
<br />
Wenn wir mit einem CPU-Takt von 4 MHz arbeiten und den Vorteiler auf 1024 einstellen, wird also der Timer mit einer Frequenz von 4 MHz / 1024, also mit ca. 4 kHz versorgt. Wenn also der Timer läuft, so wird das Daten- bzw. Zählregister (TCNTx) mit dieser Frequenz inkrementiert.<br />
<br />
== 8-Bit Timer/Counter ==<br />
<br />
Alle AVR-Modelle verfügen über mindestens einen, teilweise sogar zwei, 8-Bit Timer.<br />
<br />
Der 8-Bit Timer wird z.B bei AT90S2313 über folgende Register angesprochen (bei anderen Typen weitestgehend analog):<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''TCCR0'''<br />
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister<br />
Timer '''0'''<br />
<br />
In diesem Register stellen wir ein, wie wir den Timer/Counter verwenden möchten.<br />
<br />
Das Register ist wie folgt aufgebaut:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0<br />
|- <br />
! Name<br />
|| '''-'''|| '''-'''|| '''-'''|| '''-'''|| '''-'''|| '''CS02'''|| '''CS01'''|| '''CS00'''<br />
|- <br />
! R/W<br />
| R|| R|| R|| R|| R|| R/W|| R/W|| R/W<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
<br />
'''CS02, CS01, CS00''' ('''C'''lock '''S'''elect Bits)<br />
:Diese 3 Bits bestimmen die Quelle für den Timer/Counter:<br />
<br />
:{| class="wikitable"<br />
|- <br />
! CS02 || CS01 || CS00 || Resultat<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| align="center" | 0<br />
| Stopp, Der Timer/Counter wird angehalten.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| align="center" | 1<br />
| CPU-Takt<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| align="center" | 0<br />
| CPU-Takt / 8<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| align="center" | 1<br />
| CPU-Takt / 64<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| align="center" | 0<br />
| CPU-Takt / 256<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| align="center" | 1<br />
| CPU-Takt / 1024<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| align="center" | 0<br />
| Externer Pin '''TO''', fallende Flanke<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| align="center" | 1<br />
| Externer Pin '''TO''', steigende Flanke<br />
|}<br />
<br />
:Wenn als Quelle der externe Pin '''TO''' verwendet wird, so wird ein Flankenwechsel auch erkannt, wenn der Pin '''TO''' als Ausgang geschaltet ist.<br />
<br />
|- <br />
| '''TCNT0'''<br />
| '''T'''imer/'''C'''ou'''nt'''er Daten Register Timer '''0'''<br /><br />
Dieses ist als 8-Bit Aufwärtszähler mit Schreib- und Lesezugriff<br />
realisiert. Wenn der Zähler den Wert 255 erreicht hat beginnt er beim<br />
nächsten Zyklus wieder bei 0.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0<br />
|- <br />
! Name<br />
| '''MSB'''|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| '''LSB'''<br />
|- <br />
! R/W<br />
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
|}<br />
<br />
Um nun also den Timer0 in Betrieb zu setzen und ihn mit einer Frequenz von 1/1024-tel des CPU-Taktes zählen zu lassen, schreiben wir die folgende Befehlszeile:<br />
<br />
<c><br />
TCCR0 |= (1<<CS00)|(1<<CS02);<br />
</c><br />
<br />
Der Zähler zählt nun aufwärts bis 255, um dann wieder bei 0 zu beginnen. Der aktuelle Zählerstand steht in TCNT0. Bei jedem Überlauf von 255 auf 0 wird das Timer Overflow Flag '''TOV0''' im Timer Interrupt Flag '''TIFR'''-Register gesetzt und, falls so konfiguriert, ein entsprechender Timer-Overflow-Interrupt ausgelöst und die daran gebundene Interrupt-Routine abgearbeitet. Das TOV Flag <br />
lässt sich durch das Hineinschreiben einer 1 und nicht wie erwartet einer 0 wieder zurücksetzen.<br />
<br />
Beispiel für Compare Match Mode:<br />
<c><br />
/*Hinweis: Der Timer ist für die 1Mhz vom interne Takt des ATMEGAs*/<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
<br />
//Variablen für die Zeit<br />
volatile unsigned int millisekunden=0;<br />
volatile unsigned int sekunde=0;<br />
volatile unsigned int minute=0;<br />
volatile unsigned int stunde=0;<br />
main()<br />
{<br />
<br />
//Timer 0 konfigurieren<br />
<br />
TCCR0 =(1<<WGM01) |(1<<CS01);<br />
OCR0=125;<br />
<br />
//Compare Interrupt aktivieren<br />
TIMSK|=(1<<OCIE0);<br />
//Globale Interrupts aktivieren<br />
sei();<br />
while(1)<br />
{<br />
/*Hier kann die aktuelle Zeit ausgeben werden*/<br />
}<br />
<br />
}<br />
<br />
// Der Compare Interrupt Handler<br />
// Wird aufgerufen wenn TCNT0 = 125<br />
ISR (TIMER0_COMP_vect)<br />
{<br />
millisekunden++;<br />
if(millisekunden==1000)<br />
{<br />
sekunde++;<br />
millisekunden=0;<br />
if(sekunde==60)<br />
{<br />
minute++;<br />
sekunde=0;<br />
}<br />
if(minute ==60)<br />
{<br />
stunde++;<br />
minute=0;<br />
}<br />
}<br />
}<br />
</c><br />
<br />
== Timer-Bitzahlen verschiedener AVRs ==<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|- <br />
! AVR-Typ || Timer/Counter0 || Timer/Counter1 || Timer/Counter2<br />
|- <br />
| ATtiny2313 || 8 || 16 || -<br />
|- <br />
| ATmega8 || 8 || 16 || 8<br />
|- <br />
| ATmega88 || 8 || 16 || 8<br />
|}<br />
<br />
== 16-Bit Timer/Counter ==<br />
<br />
Viele AVR-Modelle besitzen außer den 8-Bit Timern auch 16-Bit Timer. Die 16-Bit Timer/Counter sind etwas komplexer aufgebaut als die 8-Bit Timer/Counter, bieten dafür aber auch viel mehr Möglichkeiten, als da sind:<br />
<br />
* Die [[PWM]]-Betriebsart Erzeugung eines pulsweitenmodulierten Ausgangssignals. <br />
* Vergleichswert-Überprüfung mit Erzeugung eines Ausgangssignals (Output Compare Match).<br />
* Einfangen eines Eingangssignals mit Speicherung des aktuellen Zählerwertes (Input Capturing), mit zuschaltbarer Rauschunterdrückung (Noise Filtering).<br />
<br />
Folgende Register sind dem Timer/Counter 1 zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''TCCR1A'''<br />
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister '''A''' Timer '''1'''<br /><br />
In diesem und dem folgenden Register stellen wir ein, wie wir den Timer/Counter verwenden möchten.<br /><br />
Das Register ist wie folgt aufgebaut:<br />
<br />
{| class="wikitable"<br />
|- <br />
! Bit<br />
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0<br />
|- <br />
! Name<br />
| '''COM1A1'''|| '''COM1A0'''|| '''-'''|| '''-'''|| '''-'''|| '''-'''|| '''PWM11'''|| '''PWM10'''<br />
|- <br />
! R/W<br />
| R/W|| R/W|| R|| R|| R|| R|| R/W|| R/W<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
<br />
'''COM1A1''', '''COM1A0''' ('''Co'''mpare '''M'''atch Control Bits)<br />
:Diese 2 Bits bestimmen die Aktion, welche am Output-Pin '''OC1''' ausgeführt werden soll, wenn der Wert des Datenregisters des Timer/Counter 1 den Wert des Vergleichsregisters erreicht, also ein so genannter Compare Match auftritt.<br />
:Der Pin '''OC1''' ('''PB3''' beim 2313) muss mit dem Datenrichtungsregister als Ausgang konfiguriert werden.<br />
<br />
:{| class="wikitable"<br />
|- <br />
! COM1A1 || COM1A0 || Resultat<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Output-Pin '''OC1''' wird nicht angesteuert.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Das Signal am Pin '''OC1''' wird invertiert (Toggle).<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Der Output Pin '''OC1''' wird auf 0 gesetzt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Der Output Pin '''OC1''' wird auf 1 gesetzt.<br />
|}<br />
<br />
:In der PWM-Betriebsart haben diese Bits eine andere Funktion.<br />
<br />
:{| class="wikitable"<br />
|- <br />
! COM1A1 || COM1A0 || Resultat<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Output-Pin '''OC1''' wird nicht angesteuert.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Output-Pin '''OC1''' wird nicht angesteuert.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Wird beim Hochzählen der Wert im Vergleichsregister erreicht, so wird der Pin '''OC1''' auf 0 gesetzt.<br />
Wird beim Herunterzählen der Wert im Vergleichsregister erreicht, so wird der Pin auf 1 gesetzt.<br />
<br />
Man nennt dies ''nicht invertierende PWM''.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Wird beim Hochzählen der Wert im Vergleichsregister erreicht, so wird der Pin '''OC1''' auf 1 gesetzt.<br />
Wird beim Herunterzählen der Wert im Vergleichsregister erreicht, so wird der Pin auf 0 gesetzt.<br />
<br />
Man nennt dies ''invertierende PWM''.<br />
|}<br />
<br />
'''PWM11''', '''PWM10''' ('''PWM''' Mode Select Bits)<br />
:Mit diesen 2 Bits wird die PWM-Betriebsart des Timer/Counter 1 gesteuert.<br />
<br />
:{| class="wikitable"<br />
|- <br />
! PWM11 || PWM10 || Resultat<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Die PWM-Betriebsart ist nicht aktiviert. Timer/Counter 1 arbeitet als normaler Timer bzw. Zähler.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| 8-Bit PWM Betriebsart aktivieren.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| 9-Bit PWM Betriebsart aktivieren.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| 10-Bit PWM Betriebsart aktivieren.<br />
|}<br />
<br />
|- <br />
| '''TCCR1B'''<br />
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister '''B''' Timer '''1'''<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''ICNC1'''|| '''ICES1'''|| '''-'''|| '''WGM13'''|| '''WGM12 (CTC1)'''|| '''CS12'''|| '''CS11'''|| '''CS10'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''ICNC1''' ('''I'''nput '''C'''apture '''N'''oise '''C'''anceler (4 CKs) Timer/Counter 1<br />
:oder auf Deutsch Rauschunterdrückung des Eingangssignals.<br />
:Wenn dieses Bit gesetzt ist und mit dem Input Capture Signal gearbeitet wird so werden nach der Triggerung des Signals mit der entsprechenden Flanke (steigend oder fallend) am Input Capture Pin '''ICP''' jeweils 4 Messungen mit der CPU-Frequenz des Eingangssignals abgefragt. Nur dann, wenn alle 4 Messungen den gleichen Zustand aufweisen gilt das Signal als erkannt.<br />
<br />
'''ICES1''' ('''I'''nput '''C'''apture '''E'''dge '''S'''elect Timer/Counter '''1''')<br />
:Mit diesem Bit wird bestimmt, ob die steigende ('''ICES1'''=1) oder fallende ('''ICES1'''=0) Flanke zur Auswertung des Input Capture Signals an Pin '''ICP''' heran gezogen wird.<br />
<br />
'''CTC1''' ('''C'''lear '''T'''imer/'''C'''ounter on Compare Match Timer/Counter '''1''')<br />
:Wenn dieses Bit gesetzt ist, so wird nach einer Übereinstimmung des Datenregisters '''TCNT1H'''/'''TCNT1L''' mit dem Vergleichswert in '''OCR1H'''/'''OCR1L''' das Datenregister '''TCNT1H'''/'''TCNT1L''' auf 0 gesetzt.<br />
:Da die Übereinstimmung im Takt nach dem Vergleich behandelt wird, ergibt sich je nach eingestelltem Vorteiler ein etwas anderes Zählverhalten:<br />
:Wenn der Vorteiler auf 1 gestellt, und C der voreingestellte Vergleichswert ist, dann nimmt das Datenregister, im CPU-Takt betrachtet, folgende Werte an:<br />
:... | C-2 | C-1 | C | 0 | 1 |...<br />
:Wenn der Vorteiler z.B. auf 8 eingestellt ist, dann nimmt das Datenregister folgende Werte an:<br />
:... | C-2, C-2, C-2, C-2, C-2, C-2, C-2, C-2 | C-1, C-1, C-1, C-1, C-1, C-1, C-1, C-1 | C, 0, 0, 0, 0, 0, 0, 0 |...<br />
:In der PWM-Betriebsart hat dieses Bit keine Funktion.<br />
<br />
'''CS12''', '''CS11''', '''CS10''' ('''C'''lock '''S'''elect Bits)<br />
:Diese 3 Bits bestimmen die Quelle für den Timer/Counter:<br />
<br />
:{| class="wikitable"<br />
|- <br />
! CS12 || CS11 || CS10 || Resultat<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| align="center" | 0<br />
| Stopp, Der Timer/Counter wird angehalten.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| align="center" | 1<br />
| CPU-Takt<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| align="center" | 0<br />
| CPU-Takt / 8<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| align="center" | 1<br />
| CPU-Takt / 64<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| align="center" | 0<br />
| CPU-Takt / 256<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| align="center" | 1<br />
| CPU-Takt / 1024<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| align="center" | 0<br />
| Externer Pin T1, fallende Flanke<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| align="center" | 1<br />
| Externer Pin T1, steigende Flanke<br />
|}<br />
<br />
:Wenn als Quelle der externe Pin T1 verwendet wird, so wird ein Flankenwechsel auch erkannt, wenn der Pin T1 als Ausgang geschaltet ist.<br />
|- <br />
| '''TCNT1H'''<br />'''TCNT1L'''<br />
| '''T'''imer/'''C'''ou'''nt'''er Daten Register Timer/Counter '''1'''<br />
Dieses ist als 16-Bit Aufwärtszähler mit Schreib- und Lesezugriff realisiert. Wenn der Zähler den Wert 65535 erreicht hat, beginnt er beim nächsten Zyklus wieder bei 0.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0 ||<br />
|- <br />
! Name<br />
| '''MSB'''|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| '''TCNT1H'''<br />
|- <br />
! Name<br />
|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| '''LSB'''|| '''TCNT1L'''<br />
|- <br />
! R/W<br />
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| &nbsp;<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0|| &nbsp;<br />
|}<br />
<br />
In der PWM-Betriebsart wird das Register als Auf/Ab-Zähler verwendet, d.h. der Wert steigt zuerst von 0, bis er den Überlauf von 65535 auf 0 erreicht hat. Dann zählt das Register rückwärts wiederum bis 0.<br />
<br />
Zum Auslesen des Registers wird von der CPU ein internes TEMP-Register verwendet. Das gleiche Register wird auch verwendet, wenn auf '''OCR1''' oder '''ICR1''' zugegriffen wird.<br />
<br />
Deshalb müssen vor dem Zugriff auf eines dieser Register alle Interrupts gesperrt werden, weil sonst die Möglichkeit des gleichzeitigen Zugriffs auf das Temporärregister gegeben ist, was natürlich zu fehlerhaftem Verhalten des Programms führt.. Zudem muss zuerst '''TCNT1L''' und erst danach '''TCNT1H''' ausgelesen werden.<br />
<br />
Wenn in das Register geschrieben werden soll, müssen ebenfalls alle Interrrupts gesperrt werden. Dann muss zuerst das '''TCNT1H'''-Register und erst danach das '''TCNT1L'''-Register geschrieben werden, also genau die umgekehrte Reihenfolge wie beim Lesen des Registers.<br />
|- <br />
| '''OCR1H'''<br />'''OCR1L'''<br />
| Timer/Counter '''O'''utput '''C'''ompare '''R'''egister Timer/Counter '''1'''<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0|| &nbsp;<br />
|- <br />
! Name<br />
| '''MSB'''|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| '''OCR1H'''<br />
|- <br />
! Name<br />
| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| '''LSB'''|| '''OCR1L'''<br />
|- <br />
! R/W<br />
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| &nbsp;<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0|| &nbsp;<br />
|}<br />
<br />
Der Wert im Output Compare Register wird ständig mit dem aktuellen Wert im Datenregister TCNT1H/TCNT1L verglichen. Stimmen die beiden Werte überein, so wird ein sogenannter Output Compare Match ausgelöst. Die entsprechenden Aktionen werden über die Timer/Counter 1 Control und Status Register eingestellt.<br />
<br />
Zum Auslesen des Registers wird von der CPU ein internes TEMP-Register verwendet. Das gleiche Register wird auch verwendet, wenn auf '''TCNT1''' oder '''ICR1''' zugegriffen wird.<br />
Deshalb müssen vor dem Zugriff auf eines dieser Register alle Interrupts gesperrt werden, weil sonst die Möglichkeit des gleichzeitigen Zugriffs auf das Temporärregister gegeben ist, was natürlich zu fehlerhaftem Verhalten des Programms führt. Zudem muss zuerst '''OCR1L''' und erst danach '''OCR1H''' ausgelesen werden.<br />
<br />
Wenn in das Register geschrieben werden soll, müssen ebenfalls alle Interrupts gesperrt werden. Dann muss zuerst das '''OCR1H'''-Register und erst danach das '''OCR1L'''-Register geschrieben werden, also genau die umgekehrte Reihenfolge wie beim Lesen des Registers.<br />
|- <br />
| '''ICR1H'''<br />'''ICR1L'''<br />
| Timer/Counter '''I'''nput '''C'''apture '''R'''egister Timer/Counter '''1'''<br /><br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0|| &nbsp;<br />
|- <br />
! Name<br />
| '''MSB'''|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| '''ICR1H'''<br />
|- <br />
! Name<br />
| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| &nbsp;|| '''LSB'''|| '''ICR1L'''<br />
|- <br />
! R/W<br />
| R|| R|| R|| R|| R|| R|| R|| R|| &nbsp;<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0|| &nbsp;<br />
|}<br />
<br />
Das Input Capture Register ist ein 16-Bit Register mit Lesezugriff. Es kann nicht beschrieben werden.<br />
<br />
Wenn am Input Capture Pin '''ICP''' die gemäß Einstellungen im '''TCCR1B''' definierte Flanke erkannt wird, so wird der aktuelle Inhalt des Datenregisters '''TCNT1H'''/'''TCNT1L''' sofort in dieses Register kopiert und das Input Capture Flag '''ICF1''' im Timer Interrupt Flag Register '''TIFR''' gesetzt.<br />
<br />
{{Warnung|Wie bereits oben erwähnt, müssen vor dem Zugriff auf dieses Register alle Interrupts gesperrt werden. Zudem müssen Low- und Highbyte des Registers in der richtigen Reihenfolge bearbeitet werden:<br />
;Lesen&#58;: '''ICR1L''' &rarr; '''ICR1H'''<br />
Bei Verwendung des Compilers wird der Zugriff in der korrekten Reihenfolge ausgeführt, wenn man das 16-Bit register ICR1 verwendet anstatt zwei Zugriffe auf 8-Bit Register.<br />
}}<br />
<br />
|}<br />
<br />
=== Die PWM-Betriebsart ===<br />
<br />
Wenn der Timer/Counter 1 in der PWM-Betriebsart betrieben wird, so bilden das Datenregister '''TCNT1H'''/'''TCNT1L''' und das Vergleichsregister '''OCR1H'''/'''OCR1L''' einen 8-, 9- oder 10-Bit, frei laufenden PWM-Modulator, welcher als PWM-Signal am '''OC1'''-Pin ('''PB3''' beim 2313) abgegriffen werden kann. Das Datenregister '''TCNT1H'''/'''TCNT1L''' wird dabei als Auf-/Ab-Zähler betrieben, welcher von 0 an aufwärts zählt bis zur Obergrenze und danach wieder zurück auf 0.<br />
Die Obergrenze ergibt sich daraus, ob 8-, 9- oder 10-Bit PWM verwendet wird, und zwar gemäß folgender Tabelle:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Auflösung || Obergrenze || Frequenz<br />
|- <br />
| 8 || 255 || f<sub>TC1</sub> / 510<br />
|- <br />
| 9 || 511 || f<sub>TC1</sub> / 1022<br />
|- <br />
|10 || 1023 || f<sub>TC1</sub> / 2046<br />
|}<br />
<br />
Wenn nun der Zählerwert im Datenregister den in '''OCR1H'''/'''OCR1L''' gespeicherten Wert erreicht, wird der Ausgabepin '''OC1''' gesetzt bzw. gelöscht, je nach Einstellung von '''COM1A1''' und '''COM1A0''' im '''TCCR1A'''-Register.<br />
<br />
Ich habe versucht, die entsprechenden Signale in der folgenden Grafik zusammenzufassen<br />
<br />
[[Image:PWM Theorie 3.gif]] [[Image:PWM Theorie 4.gif]]<br />
<br />
=== Vergleichswert-Überprüfung (Compare Match) ===<br />
<br />
Hier wird in ein spezielles Vergleichswertregister ('''OCR1H'''/'''OCR1L''') ein Wert eingeschrieben, welcher ständig mit dem aktuellen Zählerwert verglichen wird.<br />
Erreicht der Zähler den in diesem Register eingetragenen Wert, so kann ein Signal (0 oder 1) am Pin '''OC1''' erzeugt und/oder ein Interrupt ausgelöst werden.<br />
<br />
Zu erwähnen ist in dem Zusammenhang, dass das zur Compare-Einheit gehörende Interrupt-Flag erst beim auf die Übereinstimmung der Werte folgenden Timertakt gesetzt wird. Das ist v.a. deshalb wichtig, da es sonst bei OCRnx = 0 einen undefinierten Zustand gäbe.<br />
<br />
Möchte man ein Compare-Ereignis 100 Takte nach dem Timerüberlauf auslösen, dann muss in das betreffende Compare-Register eine 99 geschrieben werden.<br />
<br />
=== CTC-Betriebsart (Clear Timer on Compare Match) ===<br />
<br />
Das sogenannte '''Compare Match-Ereignis''' kann auch dazu verwendet werden, um den Timer automatisch zurückzusetzen (d.h. das TCNT-Register wird zu Null gesetzt). Diese Betriebsart heißt "Clear Timer on Compare Match", also auf deutsch "Lösche Timer bei Vergleichsübereinstimmung". <br />
<br />
Mit dieser Funktionalität ist es möglich, sehr präzise Taktsignale zu erzeugen, ohne dabei programmtechnisch eingreifen zu müssen. '''Diese Funktion ersetzt das bei anderen Controllern und Timern ohne Compare-Einheit erforderliche Timer Reload''' (also das Nachladen des Zählregisters mit "Überlaufwert minus gewünschte Taktzahl bis zum Überlauf", v.a. verbreitet bei 8051er-µCs).<br />
<br />
Zur Erzeugung eines Taktes per Hardware muss lediglich eine der CTC-Betriebsarten ausgewählt werden und einer der OCnx-Pins so gesetzt werden, dass er bei Auftreten des Compare Match getoggelt wird (über die COM-Bits).<br />
<br />
Die Frequenz des Taktes am entsprechenden Ausgang ist dann<br />
:<math>f_\text{OC} = \frac{f_\text{CPU}}{\text{Prescaler} \cdot \left( \text{OCRnx} + 1 \right)}</math><br />
<br />
Diese Betriebsart macht das Timer-Nachladen, das bei AVRs, die ja im Unterschied zu 8051-Derivaten keine Auto-Reload-Funktion haben, immer mit Ungenauigkeiten und programmtechnischen Klimmzügen verbunden ist, überflüssig. Ist das OCRnx einmal gesetzt, dann wird das Signal am Ausgang kontinuierlich ausgegeben, ohne dass die Anwendersoftware eingreifen muss (es sei denn, die Frequenz soll geändert werden).<br />
<br />
Beim ATmega8 hat der 8-Bit-Timer 0 keine Compare-Einheit, so dass dort CTC und auch sonstige automatische Vergleichsoperationen nicht möglich sind. Bei Timer 1 und Timer 2 ist das jedoch möglich. Bei den neueren AVRs besitzen i.d.R. ''alle'' Timer eine oder mehrere Compare-Einheiten, so dass dort eine größere Flexibilität gegeben ist.<br />
<br />
Im Unterschied zu den PWM-Betriebsarten wird die Registeraktualisierung bei CTC nicht automatisch synchronisiert. Schreibt man einen neuen Compare-Wert, dann wird dieser sofort übernommen, was zu Fehlfunktionen führen kann, wenn der neue Compare-Wert höher ist, als der aktuelle Stand von TCNTnx. In den PWM-Betriebsarten wird hingegen der TOP-Wert synchron bei Erreichen von TOP oder BOTTOM aktualisiert.<br />
<br />
=== Einfangen eines Eingangssignals (Input Capturing) ===<br />
<br />
Bei dieser Betriebsart wird an den Input Capturing Pin (ICP) des Controllers eine Signalquelle angeschlossen.<br />
Nun kann je nach Konfiguration entweder ein Signalwechsel von 0 nach 1 (steigende Flanke) oder von 1 nach 0 (fallende Flanke) erkannt werden und der zu diesem Zeitpunkt aktuelle Zählerstand in ein spezielles Register abgelegt werden. Gleichzeitig kann auch ein entsprechender Interrupt ausgelöst werden.<br />
Wenn die Signalquelle ein starkes Rauschen beinhaltet, kann die Rauschunterdrückung eingeschaltet werden. Dann wird beim Erkennen der konfigurierten Flanke über 4 Taktzyklen das Signal überwacht und nur dann, wenn alle 4 Messungen gleich sind, wird die entsprechende Aktion ausgelöst.<br />
<br />
== Gemeinsame Register ==<br />
<br />
Verschiedene Register beinhalten Zustände und Einstellungen, welche sowohl<br />
für den 8-Bit, als auch für den 16-Bit Timer/Counter in ein und demselben<br />
Register zu finden sind.<br />
<br />
{| class="wikitable" <br />
|- <br />
| '''TIMSK'''<br />
| '''T'''imer/Counter '''I'''nterrupt '''M'''a'''sk'''<br />
Register<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''TOIE1'''|| '''OCIE1A'''|| '''-'''|| '''-'''|| '''TICIE'''|| '''-'''|| '''TOIE0'''|| '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R/W || R || R/W || R<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
<br />
'''TOIE1''' ('''T'''imer/Counter '''O'''verflow '''I'''nterrupt '''E'''nable Timer/Counter '''1''')<br />
:Wenn dieses Bit gesetzt ist, wird bei einem Überlauf des Datenregisters des Timer/Counter 1 ein Timer Overflow 1 Interrupt ausgelöst. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
<br />
'''OCIE1A''' ('''O'''utput '''C'''ompare Match '''I'''nterrupt '''E'''nable Timer/Counter '''1''')<br />
:Beim Timer/Counter 1 kann zusätzlich zum Überlauf ein Vergleichswert definiert werden.<br />
<br />
:Wenn dieses Bit gesetzt ist, wird beim Erreichen des Vergleichswertes ein Compare Match Interrupt ausgelöst. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
<br />
'''TICIE''' ('''T'''imer/Counter '''I'''nput '''C'''apture '''I'''nterrupt '''E'''nable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Capture Event Interrupt ausgelöst, wenn ein entsprechendes Signalereignis am Pin PD6(ICP) auftritt. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein, wenn auch ein entsprechender Interrupt ausgelöst werden soll.<br />
<br />
'''TOIE0''' ('''T'''imer/Counter '''O'''verflow '''I'''nterrupt '''E'''nable Timer/Counter '''0''')<br />
:Wenn dieses Bit gesetzt ist, wird bei einem Überlauf des Datenregisters des Timer/Counter 0 ein Timer Overflow 0 Interrupt ausgelöst. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
<br />
|- <br />
| '''TIFR'''<br />
| '''T'''imer/Counter '''I'''nterrupt '''F'''lag '''R'''egister<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''TOV1'''|| '''OCF1A'''|| '''-'''|| '''-'''|| '''ICF1'''|| '''-'''|| '''TOV0'''|| '''-'''<br />
|- <br />
! R/W<br />
| R/W|| R/W|| R|| R|| R/W|| R|| R/W|| R<br />
|- <br />
! Initialwert<br />
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0<br />
|}<br />
<br />
'''TOV1''' ('''T'''imer/Counter '''O'''verflow Flag Timer/Counter '''1''')<br />
:Dieses Bit wird vom Controller gesetzt, wenn beim Timer 1 ein Überlauf des Datenregisters stattfindet.<br />
<br />
:In der PWM-Betriebsart wird das Bit gesetzt, wenn die Zählrichtung von auf- zu abwärts und umgekehrt geändert wird (Zählerwert = 0).<br />
<br />
:Das Flag wird automatisch gelöscht, wenn der zugehörige Interrupt-Vektor aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 (!) in das entsprechende Bit geschrieben wird.<br />
<br />
'''OCF1A''' ('''O'''utput '''C'''ompare '''F'''lag Timer/Counter '''1''')<br />
:Dieses Bit wird gesetzt, wenn der aktuelle Wert des Datenregisters von Timer/Counter 1 mit demjenigen im Vergleichsregister '''OCR1''' übereinstimmt.<br />
<br />
:Das Flag wird automatisch gelöscht, wenn der zugehörige Interrupt-Vektor aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 (!) in das entsprechende Bit geschrieben wird.<br />
<br />
'''ICF1''' ('''I'''nput '''C'''apture '''F'''lag Timer/Counter '''1''')<br />
:Dieses Bit wird gesetzt, wenn ein Capture-Ereignis aufgetreten ist, welches anzeigt, dass der Wert des Datenregisters des Timer/Counter 1 in das Input Capture Register ICR1 übertragen wurde.<br />
<br />
:Das Flag wird automatisch gelöscht, wenn der zugehörige Interrupt-Vektor aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 (!) in das entsprechende Bit geschrieben wird.<br />
<br />
'''TOV0''' ('''T'''imer/Counter '''O'''verflow Flag Timer/Counter '''0''')<br />
:Dieses Bit wird vom Controller gesetzt, wenn beim Timer 0 ein Überlauf des Datenregisters stattfindet.<br />
<br />
:Das Flag wird automatisch gelöscht, wenn der zugehörige Interrupt-Vektor aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 (!) in das entsprechende Bit geschrieben wird.<br />
|}<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Ausserdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr. Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden.<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen kleiner 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4us warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<c><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms) {<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</c><br />
<br />
== avr-libc Versionen ab 1.6 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<c><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</c><br />
<br />
= Der Watchdog =<br />
<br />
Und hier kommt das ultimative Mittel gegen die Unvollkommenheit von uns<br />
Programmierern, der Watchdog.<br />
<br />
So sehr wir uns auch anstrengen, es wird uns kaum je gelingen, das absolut<br />
perfekte und fehlerfreie Programm zu entwickeln.<br />
<br />
Der Watchdog kann uns zwar auch nicht zu besseren Programmen verhelfen aber er<br />
kann dafür sorgen, dass unser Programm, wenn es sich wieder mal in's Nirwana<br />
verabschiedet hat, neu gestartet wird, indem ein Reset des Controllers<br />
ausgelöst wird.<br />
<br />
Betrachten wir doch einmal folgende Codesequenz:<br />
<br />
<c><br />
uint8_t x;<br />
<br />
x = 10;<br />
<br />
while (x >= 0)<br />
{<br />
// tu was<br />
<br />
x--;<br />
}<br />
</c><br />
<br />
Wenn wir die Schleife mal genau anschauen sollte uns auffallen, dass dieselbe niemals beendet wird. Warum nicht? Ganz einfach, weil eine als '''''unsigned''''' deklarierte Variable niemals kleiner als Null werden kann (der Compiler sollte jedoch eine ensprechende Warnung ausgeben).<br />
Das Programm würde sich also hier aufhängen und auf ewig in der Schleife drehen.<br />
Und hier genau kommt der Watchdog zum Zug.<br />
<br />
== Wie funktioniert nun der Watchdog? ==<br />
<br />
Der Watchdog enthält einen separaten Timer/Counter, welcher mit einem intern erzeugten Takt von 1 MHz bei 5V Vcc getaktet wird. Einige Controller haben einen eigenen Watchdog Oszillator, z.B. der Tiny2313 mit 128kHz. Nachdem der Watchdog aktiviert und der gewünschte Vorteiler eingestellt wurde, beginnt der Counter von 0 an hochzuzählen. <br />
Wenn nun die je nach Vorteiler eingestellte Anzahl Zyklen erreicht wurde, löst der Watchdog einen Reset aus. Um nun also im Normalbetrieb den Reset zu verhindern, müssen wir den Watchdog regelmäßig wieder neu starten bzw. rücksetzen (Watchdog Reset). <br />
Dies sollte innerhalb unserer Hauptschleife passieren.<br />
<br />
Um ein unbeabsichtigtes Ausschalten des Watchdogs zu verhindern, muss ein spezielles Prozedere verwendet werden, um den WD auszuschalten. Es müssen zuerst die beiden Bits WDTOE und WDE in einer einzelnen Operation (also nicht mit sbi) auf 1 gesetzt werden. <br />
Dann muss innerhalb der nächsten 4 Taktzyklen das Bit WDE auf 0 gesetzt werden.<br />
<br />
Das Watchdog Control Register:<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''WDTCR'''<br />
| '''W'''atch'''D'''og '''T'''imer&nbsp; '''C'''ontrol '''R'''egister<br />
<br />
In diesem Register stellen wir ein, wie wir den Watchdog verwenden möchten.<br />
<br />
Das Register ist wie folgt aufgebaut:<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''-'''|| '''WDTOE'''|| '''WDE'''|| '''WDP2'''|| '''WDP1'''|| '''WDP0'''<br />
|- <br />
! R/W<br />
| R|| R|| R|| R/W|| R/W|| R/W|| R/W|| R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''WDTOE''' ('''W'''atch'''d'''og '''T'''urn '''O'''ff '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, wenn das Bit '''WDE''' gelöscht wird, andernfalls wird der Watchdog nicht ausgeschaltet.<br />
:Wenn das Bit einmal gesetzt ist, wird es von der Hardware nach 4 Taktzyklen automatisch wieder gelöscht.<br />
<br />
'''WDE''' ('''W'''atch'''d'''og '''E'''nable)<br />
:Wenn dieses Bit gesetzt wird, so wird der Watchdog aktiviert.<br />
:Das Bit kann nur gelöscht werden, solange das Bit '''WDTOE''' auf 1 steht.<br />
<br />
'''WDP2''', '''WDP1''', '''WDP0''' ('''W'''atch'''d'''og Timer '''P'''rescaler Bits)<br />
:Diese 3 Bits bestimmen die Anzahl Oszillatorzyklen für den Watchdog, also, wie lange es dauert, bis ein Reset ausgelöst wird:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|- <br />
! WDP2|| WDP1|| WDP0|| Anzahl Zyklen|| Typ. Timeoutzeit bei Vcc = 3V|| Typ. Timeoutzeit bei Vcc = 5V<br />
|- <br />
| 0 || 0 || 0 || 16K|| 47ms|| 15ms<br />
|- <br />
| 0 || 0 || 1 || 32K|| 94ms|| 30ms<br />
|- <br />
| 0 || 1 || 0 || 64K|| 0.19s|| 60ms<br />
|- <br />
| 0 || 1 || 1 || 128K|| 0.38s|| 0.12s<br />
|- <br />
| 1 || 0 || 0 || 256K|| 0.75s|| 0.24s<br />
|- <br />
| 1 || 0 || 1 || 512K|| 1.5s|| 0.49s<br />
|- <br />
| 1 || 1 || 0 || 1024K|| 3s|| 0.97s<br />
|- <br />
| 1 || 1 || 1 || 2048K|| 6s|| 1.9s<br />
|}<br />
<br />
|}<br />
<br />
Um den Watchdog mit dem avr-gcc Compiler zu verwenden, muss die Headerdatei ''wdt.h'' (''#include <avr/wdt.h>'') in die Quelldatei eingebunden werden. <br />
<!-- mt: das stimmt wohl nicht mehr?!:<br />
Dadurch wird auch der Startup-Code entsprechend angepasst, so dass der Watchdog nach einem Reset automatisch gestartet wird. <br />
Das WDTCR-Register wird dabei mit dem Wert 0 beschrieben. <br />
Falls ein anderer Wert gewünscht ist, so kann dies im Makfile in den Linker-Optionen eingetragen werden. <br />
Dazu muss in der Zeile LDFLAGS folgende Option angefügt werden:<br /><br />
&nbsp;&nbsp;&nbsp; --defsym __init_wdtcr__=0x1f<br /><br />
wenn beispielsweise der Wert des Registers auf 0x1f gestellt werden soll.<br /> --><br />
Danach können die folgenden Funktionen verwendet werden:<br />
<br />
* '''wdt_enable(uint8_t timeout)'''<br />
:Aktiviert den Watchdog und stellt den Vorteiler auf den gewünschten Wert ein bzw. der in timeout übergebene Wert wird in das WDTCR-Register eingetragen. Einige Timeout-Werte sind als Konstanten vordefiniert<br />
:Mögliche Timeoutwerte:<br />
<div align="center"><br />
{| class="wikitable"<br />
! Konstante || Wert || TimeOut<br />
|- <br />
| WDTO_15MS || 0 || 15 ms<br />
|-<br />
| WDTO_30MS || 1 || 30 ms<br />
|-<br />
| WDTO_60MS || 2 || 60 ms<br />
|-<br />
| WDTO_120MS || 3 || 120 ms<br />
|-<br />
| WDTO_250MS || 4 || 250 ms<br />
|-<br />
| WDTO_500MS || 5 || 500 ms<br />
|-<br />
| WDTO_1S || 6 || 1 s<br />
|-<br />
| WDTO_2S || 7| 2 s<br />
|}<br />
</div><br />
;wdt_disable():Mit dieser Funktion kann der Watchdog ausgeschaltet werden. Dabei wird das notwendige Prozedere, wie oben beschrieben, automatisch ausgeführt.<br />
;wdt_reset():Dies ist wohl die wichtigste der Watchdog-Funktionen. Sie erzeugt einen Watchdog-Reset, welcher periodisch, und zwar vor Ablauf der Timeoutzeit, ausgeführt werden muss, damit der Watchdog nicht den AVR zurücksetzt.<br />
<br />
Selbstverständlich kann das '''WDTCR'''-Register auch mit den uns bereits bekannten Funktionen für den Zugriff auf Register programmiert werden.<br />
<br />
== Watchdog-Anwendungshinweise ==<br />
<br />
Ob nun der Watchdog als Schutzfunktion überhaupt verwendet werden soll, hängt stark von der Anwendung, der genutzten Peripherie und dem Umfang und der Qualitätssicherung des Codes ab. Will man sicher gehen, dass ein Programm sich nicht in einer Endlosschleife verfängt, ist der Wachdog das geeignete Mittel dies zu verhindern. Weiterhin kann bei geschickter Programmierung der Watchdog dazu genutzt werden, bestimmte Stromsparfunktionen zu implementieren. Bei einigen neueren AVRs (z.B. dem ATTiny13) kann der Watchdog auch direkt als Timer genutzt werden, der den Controller aus einem Schlafmodus aufweckt. Auch dies kann im '''WDTCR'''-Register eingestellt werden. Außerdem bietet der WD die einzige Möglichkeit einen beabsichtigten System-Reset (ein "richtiger Reset", kein "jmp 0x0000") ohne externe Beschaltung auszulösen, was z.B. bei der Implementierung eines Bootloaders nützlich ist. Bei bestimmten Anwendungen kann die Nutzung des WD als "ultimative Deadlock-Sicherung für nicht bedachte Zustände" natürlich immer als zusätzliche Sicherung dienen. <br />
<br />
Es besteht die Möglichkeit herauszufinden, ob ein Reset durch den Watchdog ausgelöst wurde (beim ATmega16 z.B. Bit WDRF in MCUCSR). Diese Information sollte auch genutzt werden, falls ein WD-Reset in der Anwendung nicht planmäßig implementiert wurde. Zum Beispiel kann man eine LED an einen freien Pin hängen, die nur bei einem Reset durch den WD aufleuchtet oder aber das "Ereignis WD-Reset" im internen EEPROM des AVR absichern, um die Information später z.B. über UART oder ein Display auszugeben (oder einfach den EEPROM-Inhalt über die ISP/JTAG-Schnittstelle auslesen).<br />
<br />
Bei neueren AVR-Typen bleibt der Watchdog auch nach einem Reset durch den Watchdog aktiviert. Wenn ein Programm nach dem Neustart bis zur erstmaligen Rückstellung des Watchdogs länger braucht, als die im Watchdog eingestellte Zeit, sollte man den Watchdog explizit möglichst früh deaktivieren. Ansonsten resetet der Watchdog den Controller immerfort von Neuem. Die frühe Deaktivierung sollte durch eine Funktion erfolgen, die noch vor allen anderen Operationen (insbesondere vor dem mglw. länger andauernden internen Initialisierungen vor dem Sprung zu main()) ausgeführt wird. Näheres zur Implementierung mit avr-gcc/avr-libc findet sich in der Dokumentation der avr-libc (Suchbegriffe: attribut, section, init).<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Watchdog timer handling<br />
* [http://www.mikrocontroller.net/topic/77273#642501 Bug in ATtiny2313?]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Als erstes wollen wir uns noch einmal den allgemeinen Programmablauf bei der<br />
Interrupt-Programmierung zu Gemüte führen.<br />
<br />
Man sieht, dass die Interruptroutine quasi parallel zum Hauptprogramm<br />
abläuft. Da wir nur eine CPU haben ist es natürlich keine echte Parallelität,<br />
sondern das Hauptprogramm wird beim Eintreffen eines Interrupts unterbrochen,<br />
die Interruptroutine wird ausgeführt und danach erst wieder zum Hauptprogramm<br />
zurückgekehrt.<br />
<br />
[http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen soll möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammen hängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''GIMSK'''<br />
| '''G'''eneral '''I'''nterrupt '''M'''ask '''R'''egister.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
| '''GIFR'''<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Kondition, entsprechend der Konfiguration, erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Kondition, entsprechend der Konfiguration, erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
| '''MCUCR'''<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine<br />
MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt der Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
! ISC11 || ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
In der Beschreibung heißt es, der Interrupt wird getriggert, solange der Pin auf 0 bleibt, also eigentlich unbrauchbar.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
! ISC01 || ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
In der Beschreibung heißt es, der Interrupt wird getriggert, solange der Pin auf 0 bleibt, also eigentlich unbrauchbar.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Obwohl es möglich ist, zu diesem Zeitpunkt bereits wieder das GIE-bit zu setzen, wird dringend davon abgeraten. Dieses wird nämlich automatisch gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen.<br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit dem AVR GCC Compiler (WinAVR) ==<br />
<br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<c><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</c><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<c><br />
sei();<br />
</c><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<c><br />
cli();<br />
</c><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</c><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].<br />
<br />
<c><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</c><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<c><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</c><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<c><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</c><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<!--<c><br />
#include <avr/interrupt.h><br />
...<br />
INTERRUPT (signame)<br />
{<br />
/* Interrupt Code */<br />
}<br />
</c>--><br />
<br />
<c><br />
#include <avr/interrupt.h><br />
//...<br />
void XXX_vect(void) __attribute__((interrupt));<br />
void XXX_vect(void) {<br />
//...<br />
}<br />
</c><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.B. ''void TIMER0_OVF_vect(void)...''). Der Unterschied im Vergleich zu ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit automatisch wieder gesetzt und somit weitere Interrupts zugelassen werden. Dies kann zu nicht unerheblichen Problemen von im einfachsten Fall einem Stack overflow bis zu sonstigen unerwarteten Effekten führen und sollte wirklich '''nur dann''' angewendet werden, wenn man sich absolut sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)), als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</c><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<c><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</c><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable auf die der Pointer zeigt '''volatile''' ist.<br />
<br />
<c><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</c><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (ausserhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<c><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</c><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch so genannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<c><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</c><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<c><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</c><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechnungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechnungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0, PORTA ist danach 0b00000001. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-oder-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den meisten Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten ''Sleep-Modes'' ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
* '''set_sleep_mode(uint8_t mode)'''<br />
:Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
* '''sleep_enable()'''<br />
:aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
* '''sleep_cpu()'''<br />
: Versetzt den Controller in den Schlafmodus (sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt)<br />
* '''sleep_disable()'''<br />
:deaktiviert den gesetzten Schlafmodus<br />
* '''sleep_mode()'''<br />
:Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</c><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<c><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</c><br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<c><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</c><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* http://www.nongnu.org/avr-libc/user-manual/malloc.html<br />
<br />
== Programmspeicher (Flash) ==<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc nicht "transparent" möglich. D.h. es sind besondere Zugriffsfunktionen erforderlich, um Daten aus diesem Speicher zu lesen. Grundsätzlich basieren alle Zugriffsfunktionen auf der Assembler-Anweisung lpm (load program memory, bei AVR Controllern mit mehr als 64kB Flash auch elpm). Die Standard-Laufzeitbibliothek des avr-gcc (die avr-libc) stellt diese Funktionen nach Einbinden der Header-Datei pgmspace.h zur Verfügung. Mit diesen Funktionen können einzelne Bytes, Datenworte (16bit) und Datenblöcke gelesen werden. <br />
<br />
Deklarationen von Variablen im Flash-Speicher werden durch das "Attribut" PROGMEM ergänzt. Lokale Variablen (eigentlich Konstanten) innerhalb von Funktionen können ebenfalls im Programmspeicher abgelegt werden. Dazu ist bei der Definition jedoch ein ''static'' voranzustellen, da solche "Variablen" nicht auf dem Stack bzw. (bei Optimierung) in Registern verwaltet werden können. Der Compiler "wirft" eine Warnung falls static fehlt.<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
/* Byte */<br />
const uint8_t pgmFooByte PROGMEM = 123;<br />
<br />
/* Wort */<br />
const uint16_t pgmFooWort PROGMEM = 12345;<br />
<br />
/* Byte-Feld */<br />
const uint8_t pgmFooByteArray1[] PROGMEM = { 18, 3 ,70 };<br />
const uint8_t pgmFooByteArray2[] PROGMEM = { 30, 7 ,79 };<br />
<br />
/* Zeiger */<br />
const uint8_t *pgmPointerToArray1 PROGMEM = pgmFooByteArray1;<br />
const uint8_t *pgmPointerArray[] PROGMEM = { pgmFooByteArray1, pgmFooByteArray2 };<br />
//...<br />
<br />
void foo(void)<br />
{<br />
static /*const*/ uint8_t pgmTestByteLocal PROGMEM = 0x55;<br />
static /*const*/ char pgmTestStringLocal[] PROGMEM = "im Flash";<br />
// so nicht (static fehlt): char pgmTestStringLocalFalsch [] PROGMEM = "so nicht";<br />
<br />
// ...<br />
<br />
}<br />
</c><br />
<br />
=== Byte lesen ===<br />
<br />
Mit der Funktion pgm_read_byte aus pgmspace.h erfolgt der Zugriff auf die Daten. Parameter der Funktion ist die Adresse des Bytes im Flash-Speicher.<br />
<br />
<c><br />
const uint8_t pgmFooByte PROGMEM = 123;<br />
const uint8_t pgmFooByteArray1[] PROGMEM = { 18, 3 ,70 };<br />
<br />
<br />
// Wert der Ram-Variablen myByte auf den Wert von pgmFooByte setzen:<br />
uint8_t myByte;<br />
<br />
myByte = pgm_read_byte(&pgmFooByte);<br />
// myByte hat nun den Wert 123<br />
<br />
//...<br />
<br />
// Schleife ueber ein Array aus Byte-Werten im Flash<br />
uint8_t i;<br />
<br />
for (i=0;i<3;i++) {<br />
myByte = pgm_read_byte(&pgmFooByteArray1[i]);<br />
// mach' was mit myByte....<br />
}<br />
</c><br />
<br />
=== Wort lesen ===<br />
<br />
Für "einfache" 16-bit breite Variablen erfolgt der Zugriff analog zum Byte-Beispiel, jedoch mit der Funktion pgm_read_word.<br />
<br />
<c><br />
const uint16_t pgmFooWort PROGMEM = 12345;<br />
<br />
uint16_t myWord;<br />
<br />
myWord = pgm_read_word(&pgmFooWort);<br />
</c><br />
<br />
Zeiger auf Werte im Flash sind ebenfalls 16 Bits "groß" (Stand avr-gcc 3.4.x). Damit ist der mögliche Speicherbereich für "Flash-Konstanten" auf 64kB begrenzt. <!-- Einige avr-libc/pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher) (intern via Assembler Anweisung ELPM). Die Initialisierungswerde des Speicherinhalts jenseits der 64kB-Marke müssen dann jedoch auf anderem Weg angelegt werden (nicht PROGMEM, evtl. eigene Section und Linker-Optionen - TODO) /// alt - und nicht ganz korrekt: (Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kB Flash bei Controllern mit mehr als 64kB.)--><br />
<br />
<c><br />
uint8_t *ptrToArray;<br />
<br />
ptrToArray = (uint8_t*)(pgm_read_word(&pgmPointerToArray1));<br />
// ptrToArray enthält nun die Startadresse des Byte-Arrays pgmFooByteArray1<br />
// Allerdings würde ein direkter Zugriff mit diesem Pointer (z.B. temp=*ptrToArray)<br />
// '''nicht''' den Inhalt von pgmFooByteArray1[0] liefern, sondern von einer Speicherstelle<br />
// im '''RAM''', die die gleiche Adresse hat wie pgmFooByteArray1[0]<br />
// Daher muss nun die Funktion pgm_read_byte() benutzt werden, die die in ptrToArray<br />
// enthaltene Adresse benutzt und auf das Flash zugreift.<br />
<br />
for (i=0;i<3;i++) {<br />
myByte = pgm_read_byte(ptrToArray+i);<br />
// mach' was mit myByte... (18, 3, 70)<br />
}<br />
<br />
ptrToArray = (uint8_t*)(pgm_read_word(&pgmPointerArray[1]));<br />
<br />
// ptrToArray enthält nun die Adresse des ersten Elements des Byte-Arrays pgmFooByteArray2<br />
// da im zweiten Element des Pointer-Arrays pgmPointerArray die Adresse<br />
// von pgmFooByteArray2 abgelegt ist<br />
<br />
for (i=0;i<3;i++) {<br />
myByte = pgm_read_byte(ptrToArray+i);<br />
// mach' was mit myByte... (30, 7, 79)<br />
}<br />
</c><br />
<br />
=== Strings lesen ===<br />
Strings sind in C ja nichts anderes als eine Abfolge von Zeichen. Der prinzipielle Weg ist daher identisch zu "Bytes lesen" wobei allerdings auf die [http://www.mikrocontroller.net/articles/FAQ#Wie_funktioniert_String-Verarbeitung_in_C.3F Besonderheiten von Strings] (0-Terminierung) geachtet werden muss, bzw. diese zur Steuerung einer Schleife über die Zeichen im String ausgenutzt werden kann<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
const char pgmString[] PROGMEM = "Hallo world";<br />
<br />
int main()<br />
{<br />
char c;<br />
const char* addr;<br />
<br />
...<br />
<br />
addr = &pgmString;<br />
while( ( c = pgm_read_byte( addr++ ) != '\0' ) {<br />
// mach was mit c<br />
}<br />
}<br />
</c><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoir der str... Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash Speicher arbeiten kann. Die Funktionsnamen wurden dabei um ein '_P' ergänzt.<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
const char pgmString[] PROGMEM = "Hallo world";<br />
<br />
int main()<br />
{<br />
char string[40];<br />
<br />
...<br />
<br />
strcpy_P( string, pgmString );<br />
}<br />
</c><br />
<br />
=== Floats und Structs lesen ===<br />
<br />
Um komplexe Datentypen (structs), nicht-integer Datentypen (floats) aus dem Flash auszulesen, sind Hilfsfunktionen erforderlich. Einige Beispiele:<br />
<br />
<br />
<c><br />
/* Beispiel float aus Flash */<br />
<br />
float pgmFloatArray[3] PROGMEM = {1.1, 2.2, 3.3};<br />
//...<br />
<br />
/* liest float von Flash-Addresse addr und gibt diese als return-value zurueck */<br />
inline float pgm_read_float(const float *addr)<br />
{ <br />
union<br />
{<br />
uint16_t i[2]; // 2 16-bit-Worte<br />
float f;<br />
} u;<br />
<br />
u.i[0]=pgm_read_word((PGM_P)addr);<br />
u.i[1]=pgm_read_word((PGM_P)addr+2);<br />
<br />
return u.f;<br />
} <br />
...<br />
<br />
void egal(void)<br />
{<br />
int i;<br />
float f;<br />
<br />
for (i=0;i<3;i++) {<br />
f = pgm_read_float(&pgmFloatArray[i]); // entspr. "f = pgmFloatArray[i];"<br />
// mach' was mit f <br />
}<br />
}<br />
</c><br />
<br />
<br />
TODO: Beispiele fuer structs und pointer aus flash auf struct im flash (menues, state-machines etc.). Eine kleine Einleitung insbesondere auch in Bezug auf die auftretenden Schwierigkeiten liefert [http://www.mail-archive.com/avr-gcc-list@nongnu.org/msg05652.html].<br />
<br />
=== Array aus Strings im Flash-Speicher ===<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt: Zuerst die einzelnen Elemente des Arrays und im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden. Zum Auslesen wird zuerst die Adresse des i-ten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, auf das Element (den String) selbst zuzugreifen.<br />
<br />
<c><br />
#include <stdint.h><br />
#include <avr/pgmspace.h><br />
<br />
const char str1[] PROGMEM = "first_A";<br />
const char str2[] PROGMEM = "second_A";<br />
const char str3[] PROGMEM = "third_A";<br />
<br />
const char *strarray1[] PROGMEM = {<br />
str1,<br />
str2,<br />
str3<br />
};<br />
<br />
int main(void)<br />
{<br />
int i, j, l;<br />
const char *pstrflash;<br />
char work[20], work2[20];<br />
// fuer Simulation: per volatile Optimierung verhindern, <br />
// da c nicht genutzt<br />
volatile char c;<br />
<br />
for ( i = 0; i < (sizeof(strarray1)/sizeof(strarray1[0]) ); i++ ) {<br />
<br />
// setze Pointer auf die Addresse des i-ten Elements des<br />
// "Flash-Arrays" (str1, str2, ...)<br />
pstrflash = (const char*)( pgm_read_word( &(strarray1[i]) ) );<br />
<br />
// kopiere den Inhalt der Zeichenkette von der<br />
// in pstrflash abgelegten Adresse in das work-Array<br />
// analog zu strcpy( work, strarray1[i]) wenn alles im RAM<br />
strcpy_P( work, pstrflash );<br />
// verkuerzt:<br />
strcpy_P( work2, (const char*)( pgm_read_word( &(strarray1[i]) ) ) );<br />
<br />
<br />
// Zeichen-fuer-Zeichen<br />
l = strlen_P( pstrflash );<br />
for ( j=0; j < l; j++ ) {<br />
// analog zu c=strarray[i][j] wenn alles im RAM<br />
c = (char)( pgm_read_byte( pstrflash++ ) );<br />
}<br />
}<br />
<br />
while (1) { ; }<br />
}<br />
</c><br />
<br />
Siehe dazu auch die avr-libc FAQ: "How do I put an array of strings completely in ROM?"<br />
<br />
=== Vereinfachung für Zeichenketten (Strings) im Flash ===<br />
<br />
Zeichenketten können innerhalb des Quellcodes als "Flash-Konstanten" ausgewiesen werden. Dazu dient das Makro PSTR aus pgmspace.h. Dies erspart die getrennte Deklaration mit PROGMEM-Attribut.<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
#include <string.h><br />
<br />
#define MAXLEN 30<br />
<br />
char StringImFlash[] PROGMEM = "Erwin Lindemann"; // im "Flash"<br />
char StringImRam[MAXLEN];<br />
<br />
//...<br />
strcpy(StringImRam, "Mueller-Luedenscheidt");<br />
<br />
if (!strncmp_P(StringImRam, StringImFlash, 5)) { <br />
// mach' was, wenn die ersten 5 Zeichen identisch - hier nicht<br />
}<br />
else {<br />
// der Code hier wuerde ausgefuehrt <br />
} <br />
<br />
if (!strncmp_P(StringImRam, PSTR("Mueller-Schmitt"), 5)) {<br />
// der Code hier wuerde ausgefuehrt, die ersten 5 Zeichen stimmen ueberein<br />
}<br />
else {<br />
// wuerde bei nicht-Uebereinstimmung ausgefuehrt<br />
}<br />
//...<br />
</c><br />
<br />
Aber Vorsicht: Ersetzt man zum Beispiel<br />
<c><br />
const char textImFlashOK[] PROGMEM = "mit[]"; <br />
// = Daten im "Flash", textImFlashOK* zeigt auf Flashadresse<br />
</c><br />
durch<br />
<c><br />
const char* textImFlashProblem PROGMEM = "mit*";<br />
// Konflikt: Daten im BSS (lies: RAM), textImFlashFAIL* zeigt auf Flashadresse<br />
</c><br />
dann kann es zu Problemen mit AVR-GCC kommen. Zu erkennen daran, dass der Initialisierungsstring von "textImFlashProblem" zu den Konstanten ans Ende des Programmcodes gelegt wird (BSS), von dem aus er zur Benutzung eigentlich ins RAM kopiert werden sollte (und wird). Da der lesende Code (mittels pgm_read*) trotzdem an einer Stelle vorne im Flash sucht, wird Unsinn gelesen. Dies scheint ein weiters Problem des AVR-GCC (gesehen bei avr-gcc 3.4.1 und 3.4.2) bei der Anpassung an die Harvard-Architektur zu sein (konstanter Pointer auf variable Daten?!). Abhilfe ("Workaround"): Initialisierung bei Zeichenketten mit [] oder gleich im Code PSTR("...") nutzen.<br />
<br />
Übergibt man Zeichenketten (genauer: die Adresse des ersten Zeichens), die im Flash abglegt sind an eine Funktion, muss diese entsprechend programmiert sein. Die Funktion selbst hat keine Möglichkeit zu unterscheiden, ob es sich um eine Adresse im Flash oder im RAM handelt. Die avr-libc und viele andere avr-gcc-Bibliotheken halten sich an die Konvention, dass Namen von Funktionen die Flash-Adressen erwarten mit dem Suffix _p (oder _P) versehen sind.<br />
<br />
Eine Funktion, die einen im Flash abgelegten String z.B. an eine UART ausgibt, würde dann so aussehen:<br />
<br />
<c><br />
void uart_puts_p(const char *text)<br />
{<br />
char Zeichen;<br />
<br />
while (Zeichen = pgm_read_byte(text))<br />
{ /* so lange, wie mittels pgm_read_byte ein Zeichen vom Flash gelesen<br />
werden konnte, welches nicht das "String-Endezeichen" darstellt */<br />
<br />
/* Das gelesene Zeichen über die normalen Kanäle verschicken */<br />
uart_putc(Zeichen);<br />
text++;<br />
}<br />
}<br />
</c><br />
<br />
Von einigen Bibliotheken werden Makros definiert, die "automatisch" ein PSTR bei Verwendung einer Funktion einfügen. Ein Blick in den Header-File der Bibliothek zeigt, ob dies der Fall ist. Ein Beispiel aus P. Fleurys lcd-Library:<br />
<br />
<c><br />
// Ausschnitt aus dem Header-File lcd.h der "Fleury-LCD-Lib."<br />
//...<br />
extern void lcd_puts_p(const char *progmem_s);<br />
#define lcd_puts_P(__s) lcd_puts_p(PSTR(__s))<br />
//...<br />
<br />
// in einer Anwendung (wieauchimmmer.c)<br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
#include <string.h><br />
#include "lcd.h"<br />
<br />
char StringImFlash[] PROGMEM = "Erwin Lindemann"; // im "Flash"<br />
<br />
//...<br />
lcd_puts_p(StringImFlash); <br />
lcd_puts_P("Dr. Kloebner"); <br />
// daraus wird wg. #define lcd_put_P...: lcd_puts_p( PSTR("Dr. Kloebner") );<br />
//...<br />
</c><br />
<br />
=== Flash in der Anwendung schreiben ===<br />
<br />
Bei AVRs mit "self-programming"-Option (auch bekannt als Bootloader-Support) können Teile des Flash-Speichers auch vom Anwendungsprogramm selbst beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktionen in einem besonderen Speicherbereich (boot-section) des Programmspeichers/Flash abgelegt sind. Bei wenigen "kleinen" AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so "kompliziert" ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm(Flash)- und Datenspeicher(RAM) auf. Der C-Standard und der gcc-Compiler sehen keine unterschiedlichen Adressräume vor. <br />
Hat man zum Beispiel eine Funktion string_an_uart(const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette (einen Pointer, z.B. 0x01fe), "weiß" die Funktion nicht, ob die Adresse auf den Flash-Speicher oder den/das RAM zeigt. Allein aus dem Pointer-Wert (der Zahl) kann nicht geschlossen werden, ob ein "einfaches" zeichen_an_uart(s[i]) oder zeichen_an_uart(pgm_read_byte(&s[i]) genutzt werden muss, um das i-te Zeichen auszugeben.<br />
<br />
Einige AVR-Compiler "tricksen" etwas, in dem sie für einen Pointer nicht nur die Adresse anlegen, sondern zusätzlich zu jedem Pointer den Ablageort (Flash oder RAM) intern sichern. Bei Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben. Dies hat jedoch nicht nur Vorteile; Erläuterungen warum dies so ist, führen an dieser Stelle zu weit.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
== EEPROM ==<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. <br />
Dies gilt für jede einzelne Zelle. Bei geschickter Programmierung (z.B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den Gesamtspeicher, erreichen.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16bit) und Datenblöcke geschrieben und gelesen werden. <br />
<br />
Bei Nutzung des EEPROMs ist zu beachten, dass vor dem Zugriff auf diesen Speicher abgefragt wird, ob der Controller die vorherige EEPROM-Operation abgeschlossen hat. Die avr-libc-Funktionen beinhalten diese Prüfung, man muss sie nicht selbst implementieren. Man sollte auch verhindern, dass der Zugriff durch die Abarbeitung einer Interrupt-Routine unterbrochen wird, da bestimme Befehlsabfolgen vorgegeben sind, die innerhalb weniger Taktzyklen aufeinanderfolgen müssen ("timed sequence"). Auch dies muss bei Nutzung der Funktionen aus der avr-libc/eeprom.h-Datei nicht selbst implementiert werden. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Bei der Deklaration einer Variable im EEPROM, ist das Attribut für die Section ".eeprom" zu ergänzen. Siehe dazu folgendes Beispiel:<br />
<br />
<c><br />
#include <avr/io.h><br />
#include <avr/eeprom.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h> // wird in aktuellen Versionen der avr-lib mit xx.h eingebunden<br />
<br />
// EEMEM wird bei aktuellen Versionen der avr-lib in eeprom.h definiert<br />
// hier: definiere falls noch nicht bekannt ("alte" avr-libc)<br />
#ifndef EEMEM<br />
// alle Textstellen EEMEM im Quellcode durch __attribute__ ... ersetzen<br />
#define EEMEM __attribute__ ((section (".eeprom")))<br />
#endif<br />
<br />
//...<br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Feld */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3 ,70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7 ,79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
//...<br />
</c><br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<c><br />
//...<br />
uint8_t myByte;<br />
<br />
myByte = eeprom_read_byte(&eeFooByte); // lesen<br />
// myByte hat nun den Wert 123<br />
//...<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// 'Variablen' eeFooByte geschrieben<br />
//...<br />
myByte = eeprom_read_byte(&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
//...<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z.B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
#define EEPROM_DEF 0xFF<br />
uint8_t fooByteDefault = 222;<br />
if ( ( myByte = eeprom_read_byte(&eeFooByte) ) == EEPROM_DEF ) {<br />
myByte = fooByteDefault;<br />
}<br />
<br />
</c><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<c><br />
//...<br />
uint16_t myWord;<br />
<br />
myWord = eeprom_read_word(&eeFooWord); // lesen<br />
// myWord hat nun den Wert 12345<br />
//...<br />
myWord = 2222;<br />
eeprom_write_word(&eeFooWord, myWord); // schreiben<br />
//...<br />
</c><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen ''eeprom_read_block()'' bzw. ''eeprom_write_block()''. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Addresse und die Länge des Datenblocks in Bytes (size_t).<br />
<br />
TODO: '''Vorsicht!''' die folgenden Beispiele sind noch nicht geprüft, erstmal nur als Hinweis auf "das Prinzip". Evtl. fehlen "casts" und möglicherweise noch mehr.<br />
<br />
<c><br />
//...<br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
/* Datenblock aus EEPROM LESEN */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block(myByteBuffer,eeFooByteArray1,3);<br />
<br />
/* dito etwas anschaulicher aber "unnütze Tipparbeit": */<br />
eeprom_read_block(&myByteBuffer[0],&eeFooByteArray1[0],3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block(myByteBuffer,eeFooByteArray1,sizeof(myByteBuffer));<br />
<br />
/* und nun mit "16bit" */<br />
eeprom_read_block(myWordBuffer,eeFooWordArray1,sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM SCHREIBEN */<br />
eeprom_write_block(myByteBuffer,eeFooByteArray1,sizeof(myByteBuffer));<br />
eeprom_write_block(myWordBuffer,eeFooWordArray1,sizeof(myWordBuffer));<br />
//...<br />
</c><br />
<br />
"Nicht-Integer"-Datentypen wie z.B. Fließkommazahlen lassen sich recht praktisch über eine ''union'' in "Byte-Arrays" konvertieren und wieder "zurückwandeln". Dies erweist sich hier (aber nicht nur hier) als nützlich.<br />
<br />
<c><br />
//...<br />
float myFloat = 12.34;<br />
<br />
union {<br />
float r;<br />
uint8_t i[sizeof(float)];<br />
} u;<br />
<br />
u.r = myFloat;<br />
<br />
/* float in EEPROM */<br />
eeprom_write_block(&(u.i),&eeFooFloat,sizeof(float));<br />
<br />
/* float aus EEPROM */<br />
eeprom_read_block(&(u.i),&eeFooFloat,sizeof(float));<br />
/* u.r wieder 12.34 */<br />
<br />
//...<br />
</c><br />
<br />
Auch zusammengesetzte Typen lassen sich mit den Block-Routinen verarbeiten.<br />
<br />
<c><br />
//...<br />
typedef struct {<br />
uint8_t label[8];<br />
uint8_t rom_code[8];<br />
} tMyStruct;<br />
<br />
#define MAXSENSORS 3<br />
tMyStruct eeMyStruct[MAXSENSORS] EEMEM;<br />
<br />
//...<br />
<br />
void egal(void)<br />
{<br />
tMyStruct work;<br />
<br />
strcpy(work.label,"Flur");<br />
GetRomCode(work.rom_code); // Dummy zur Veranschaulichung - setzt rom-code<br />
<br />
/* Sichern von "work" im EEPROM */<br />
eeprom_write_block(&work,&eeMyStruct[0],sizeof(tMyStruct)); // f. Index 0<br />
strcpy(work.label,"Bad");<br />
GetRomCode(work.rom_code);<br />
eeprom_write_block(&work,&eeMyStruct[1],sizeof(tMyStruct)); // f. Index 1<br />
//...<br />
/* Lesen der Daten EEPROM Index 0 in "work" */<br />
eeprom_read_block(&work,&eeMyStruct[0],sizeof(tMyStruct));<br />
// work.label hat nun den Inhalt "Flur"<br />
//...<br />
}<br />
//...<br />
</c><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden (übliche Dateiendung: .eep, Daten im Intel Hex-Format). Damit können recht elegant Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen (siehe dazu die Erläuterungen im Abschnitt Exkurs: Makefiles). Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden (Write EEPROM), wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse (vgl. Datenblatt Abschnitt Fuse Bits) die vorherigen Daten (EESAVE programmed = 0), deren Position möglicherweise nicht mehr mit der Belegung im aktuellen Programm übereinstimmt oder den Standardwert nach "Chip Erase": 0xFF (EESAVE unprogrammed = 1). Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenfalls einen Standardwert nutzen.<br />
<br />
<!--Eine besondere Funktion des avr-gcc ist, dass mit entsprechenden Optionen im Makefile aus den Initialisierungswerten der Variablen im Quellcode eine Datei erzeugt werden kann, die man auf den Controller programmieren kann (.eep-Datei). Damit können sehr elegant Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. Die Vorgehensweise wird aus dem WinAVR-Beispielmakefile ersichtlich. Siehe dazu die Erläuterungen im Abschnitt Exkurs: Makefiles.--><br />
<br />
=== EEPROM-Variable auf feste Adressen legen ===<br />
<br />
Gleich zu Beginn möchte ich darauf hinweisen, dass dieses Verfahren nur ein Workaround ist, mit dem man das Problem der anscheinend "zufälligen" Verteilung<br />
der EEPROM-Variablen durch den Compiler etwas in den Griff bekommen kann.<br />
<br />
Hilfreich kann dies vor allem dann sein, wenn man z.B. über einen Kommandointerpreter (o.ä. Funktionen) direkt bestimmte EEPROM-Adressen manipulieren möchte. Auch wenn man über einen JTAG-Adapter (mk I oder mkII) den Programmablauf manipulieren möchte, indem man die EEPROM-Werte direkt ändert, kann diese Technik hilfreich sein.<br />
<br />
Im folgenden nun zwei Sourcelistings mit einem Beispiel:<br />
<br />
<c><br />
/////////////////////////////////////////////////<br />
// Datei "eeprom.h" eines eigenen Projektes<br />
/////////////////////////////////////////////////<br />
<br />
#inlcude <avr/eeprom.h> // Die EEPROM-Definitionen/Macros der avr-libc einbinden<br />
<br />
#define EESIZE 512 // Maximale Größe des EEPROMS<br />
<br />
#define EE_DUMMY 0x000 // Dummyelement (Adresse 0 sollte nicht genutzt werden)<br />
#define EE_VALUE1 0x001 // Eine Bytevariable <br />
#define EE_WORD1L 0x002 // Eine Wordvariable (Lowbyte)<br />
#define EE_WORD1H 0x003 // Eine Wordvariable (Highbyte)<br />
#define EE_VALUE2 0x004 // Eine weitere Bytevariable<br />
</c><br />
<br />
Mit den Macros '''#define EE_VALUE1''' legt man den Namen und die Adresse der<br />
'Variablen' fest.<br />
<br />
<font color=$FF0000>WICHTIG:</font>Die Adressen sollten fortlaufend, zumindest aber aufsteigend sortiert sein! Ansonsten besteht die Gefahr, daß man sehr schnell ein Durcheinander im EEPROM Speicher veranstaltet.<br />
<br />
<font color=$FF0000>WICHTIG:</font>Für den Compiler sind das lediglich Speicher-Adressen, über die auf das EEPROM zugegriffen wird. Der Compiler sieht nichts davon als eine echte Variable an und stößt sich daher auch nicht daran, wenn 2 Makros mit der gleichen Speicheradresse, bzw. überlappenden Speicherbereichen definiert werden. Es liegt einzig und alleine in der Hand des Programmierers, hier keinen Fehler zu machen.<br />
<br />
<c><br />
/////////////////////////////////////////////////<br />
// Datei "eeprom.c" eines eigenen Projektes<br />
/////////////////////////////////////////////////<br />
<br />
#include "eeprom.h" // Eigene EEPROM-Headerdatei einbinden<br />
<br />
uint8_t ee_mem[EESIZE] EEMEM =<br />
{<br />
[EE_DUMMY] = 0x00,<br />
[EE_VALUE1] = 0x05,<br />
[EE_WORD1L] = 0x01, <br />
[EE_WORD1H] = 0x00,<br />
[EE_VALUE2] = 0xFF<br />
};<br />
<br />
</c><br />
<br />
Durch die Verwendung eines Array, welches das gesamte EEPROM umfasst, bleibt<br />
dem Compiler nicht anderes übrig, als das Array so zu platzieren, dass Element 0<br />
des Arrays der Adresse 0 des EEPROMs entspricht. (''Ich hoffe nur, dass die Compilerbauer daran nichts ändern!'')<br />
<br />
Wie man in dem obigen Codelisting auch sehen kann, hat das Verfahren einen kleinen Haken. Variablen die größer sind als 1 Byte, müssen etwas umständlicher<br />
definiert werden. Benötigt man keine Initialisierung durch das Programm (was der Normalfall sein dürfte), dann kann man das auch so machen:<br />
<br />
Möchte man im EEPROM hintereinander beispielsweise Variablen, mit den Namen '''Wert''', '''Anzahl''', '''Name''' und '''Wertigkeit''' definieren, wobei Wert und Wertigkeit 1 Byte belegen sollen, Anzahl als 1 Wort (also 2 Bytes) und Name mit 10 Bytes reserviert werden soll, so geht auch folgendes:<br />
<br />
<c><br />
#define EE_DUMMY 0x000<br />
#define EE_WERT ( 0x000 + sizeof( uint8_t ) )<br />
#define EE_ANZAHL ( EE_WERT + sizeof( uint8_t ) )<br />
#define EE_NAME ( EE_ANZAHL + sizeof( uint16_t ) )<br />
#define EE_WERTIGKEIT ( EE_NAME + 10 * sizeof( uint8_t ) )<br />
#define EE_LAST ( EE_WERTIGKEIT + sizeof( uint8_t ) )<br />
</c><br />
<br />
Jedes Makro definiert also seine Startadresse durch die Startadresse der unmittelbar vorhergehende 'Variablen' plus der Anzahl der Bytes die von der vorhergehenden 'Variablen' verbraucht werden. Dadurch ist man zumindest etwas auf der sicheren Seite, dass keine 2 'Variablen' im EEPROM überlappend definiert werden. Möchte man eine weitere 'Variable' hinzufügen, so wird deren<br />
Name, einfach anstelle der EE_LAST eingesetzt und eine neue Zeile für EE_LAST eingefügt, in der dann die Größe der 'Variablen' festgelegt wird. Zb.<br />
<br />
<c><br />
#define EE_DUMMY 0x000<br />
#define EE_WERT ( 0x000 + sizeof( uint8_t ) )<br />
#define EE_ANZAHL ( EE_WERT + sizeof( uint8_t ) )<br />
#define EE_NAME ( EE_ANZAHL + sizeof( uint16_t ) )<br />
#define EE_WERTIGKEIT ( EE_NAME + 10 * sizeof( uint8_t ) )<br />
#define EE_PROZENT ( EE_WERTIGKEIT + sizeof( uint8_t ) )<br />
#define EE_LAST ( EE_PROZENT + sizeof( double ) )<br />
</c><br />
<br />
EE_PROZENT legt die Startadresse für eine neue 'Variable' des Datentyps double fest.<br />
<br />
Der Zugriff auf die EEPROM Werte kann dann z.B.so erfolgen:<br />
<c><br />
uint8_t temp1;<br />
uint16_t temp2;<br />
<br />
temp1 = eeprom_read_byte(EE_VALUE1);<br />
temp2 = eeprom_read_word(EE_WORD1L);<br />
</c><br />
<br />
Ob die in der avr-libc vorhandenen Funktionen dafür verwendet werden können, weiß ich nicht. Aber in einigen Fällen muss man sich sowieso eigene Funktionen<br />
bauen, welche die spezifischen Anforderungen (Interrupt - Atom Problem, etc.)<br />
erfüllen.<br />
<br />
Die oben beschriebene Möglichkeit ist nur eine Möglichkeit, wie man dies realisieren kann. Sie bietet einem eine relativ einfache Art die EEPROM-Werte<br />
auf beliebige Adressen zu legen oder Adressen zu ändern. Die Andere Möglichkeit besteht darin, die EEPROM-Werte wie folgt zu belegen:<br />
<br />
<c><br />
/////////////////////////////////////////////////<br />
// Datei "eeprom.c" eines eigenen Projektes<br />
/////////////////////////////////////////////////<br />
<br />
#include "eeprom.h" // Eigene EEPROM-Headerdatei einbinden<br />
<br />
uint8_t ee_mem[EESIZE] EEMEM =<br />
{<br />
0x00, // ee_dummy<br />
0x05, // ee_value1<br />
0x01, // ee_word1L<br />
0x00, // (ee_word1H)<br />
0xFF // ee_value2<br />
};<br />
</c><br />
<br />
Hierbei kann man Variablen, die größer sind als 1 Byte einfacher definieren und<br />
man muss nur die Highbyte- oder Lowbyte-Adresse in der "eeprom.h" definieren.<br />
Allerdings muss man hier höllisch aufpassen, dass man nicht um eine oder mehrere<br />
Positionen verrutscht!<br />
<br />
Welche der beiden Möglichkeiten man einsetzt, hängt vor allem davon ab, wieviele<br />
Byte, Word und sonstige Variablen man benutzt. Gewöhnen sollte man sich an beide Varianten können ;)<br />
<br />
Kleine Schlussbemerkung:<br />
<br />
* Der avr-gcc unterstützt die Variante 1 und die Variante 2<br />
* Der icc-avr Compiler unterstützt nur die Variante 2!<br />
<br />
=== Bekannte Probleme bei den EEPROM-Funktionen ===<br />
<br />
Vorsicht: Bei alten Versionen der avr-libc wurden nicht alle AVR Controller unterstützt. Z.B. bei der avr-libc Version 1.2.3 insbesondere bei AVRs "der neuen Generation" (ATmega48/88/168/169) funktionieren die Funktionen nicht korrekt (Ursache: unterschiedliche Speicheradressen der EEPROM-Register). In neueren Versionen (z.B. avr-libc 1.4.3 aus WinAVR 20050125) wurde die Zahl der unterstüzten Controller deutlich erweitert und eine Methode zur leichten Anpassung an zukünftige Controller eingeführt.<br />
<br />
In jedem Datenblatt zu AVR-Controllern mit EEPROM sind kurze Beispielecodes für den Schreib- und Lesezugriff enthalten. Will oder kann man nicht auf die neue Version aktualisieren, kann der dort gezeigte Code auch mit dem avr-gcc (ohne avr-libc/eeprom.h) genutzt werden ("copy/paste", gegebenfalls Schutz vor Unterbrechnung/Interrupt ergänzen ''uint8_t sreg; sreg=SREG; cli(); [EEPROM-Code] ; SREG=sreg; return;'', siehe Abschnitt Interrupts). Im Zweifel hilft ein Blick in den vom Compiler erzeugten Assembler-Code (lst/lss-Dateien).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/EEPROM handling<br />
<br />
=== EEPROM Register ===<br />
Um das EEPROM anzusteuern sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL da in einem 8 Bit Register keine 512 Adressen adressiert werden können<br />
;EEDR: Hier werden die Daten eingetragen die geschrieben werden sollen bzw. es enthält die gelesenen Daten<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7) wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0 wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, daß wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE =0 ist und EEWE = 1 gesetzt wird hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist wird dieses Bit automatisch wieder auf 0 gesetzt und sofern EERIE gesetzt ist ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optinal) Warten bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen wird das Bit wieder auf 0 gesetzt und das EEPROM ist für neue Lese/Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. <br />
<br />
Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschliessend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<c><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</c><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.B. '''printf''' greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<c><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</c><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Assembler und Inline-Assembler =<br />
<br />
Gelegentlich erweist es sich als nützlich, C- und Assembler-Code in einer Anwendung zu nutzen. Typischerweise wird das Hauptprogramm in C verfasst und wenige, extrem zeitkritische oder hardwarenahe Operationen in Assembler.<br />
<br />
Die "gnu-Toolchain" bietet dazu zwei Möglichkeiten:<br />
<br />
* Inline-Assembler: Die Assembleranweisungen werden direkt in den C-Code integriert. Eine Quellcode-Datei enthält somit C- und Assembleranweisungen<br />
* Assembler-Dateien: Der Assemblercode befindet sich in eigenen Quellcodedateien. Diese werden vom gnu-Assembler (avr-as) zu Object-Dateien assembliert ("compiliert") und mit den aus dem C-Code erstellten Object-Dateien zusammengebunden (gelinkt).<br />
<br />
== Inline-Assembler ==<br />
<br />
Inline-Assembler bietet sich an, wenn nur wenig Assembleranweisungen benötigt werden. Typische Anwendung sind kurze Codesequenzen für zeitkritische Operationen in Interrupt-Routinen oder sehr präzise Warteschleifen (z.B. 1-Wire). Inline-Assembler wird mit '''asm volatile''' eingeleitet, die Assembler-Anweisungen werden in einer Zeichenkette zusammengefasst, die als "Parameter" übergeben wird. Durch Doppelpunkte getrennt werden die Ein- und Ausgaben sowie die "Clobber-Liste" angegeben.<br />
<br />
Ein einfaches Beispiel für Inline-Assembler ist das Einfügen einer NOP-Anweisung (NOP steht für No Operation). Dieser Assembler-Befehl benötigt genau einen Taktzyklus, ansonsten "tut sich nichts". Sinnvolle Anwendungen für NOP sind genaue Delay(=Warte)-Funktionen.<br />
<br />
<c><br />
...<br />
/* Verzögern der weiteren Programmausführung um<br />
genau 3 Taktzyklen */<br />
asm volatile ("nop");<br />
asm volatile ("nop");<br />
asm volatile ("nop");<br />
...<br />
</c><br />
<br />
Weiterhin kann mit einem NOP verhindert werden, dass leere Schleifen, die als Warteschleifen gedacht sind, wegoptimiert werden. Der Compiler erkennt ansonsten die vermeintlich nutzlose Schleife und erzeugt dafür keinen Code im ausführbaren Programm.<br />
<br />
<c><br />
...<br />
uint16_t i;<br />
<br />
/* leere Schleife - wird bei eingeschalteter Compiler-Optimierung wegoptimiert */<br />
for (i = 0; i < 1000; i++)<br />
;<br />
<br />
...<br />
<br />
/* Schleife erzwingen (keine Optimierung): "NOP-Methode" */<br />
for (i = 0; i < 1000; i++)<br />
asm volatile("NOP");<br />
<br />
...<br />
<br />
/* alternative Methode (keine Optimierung): */<br />
volatile uint16_t j;<br />
for (j = 0; j < 1000; j++)<br />
;<br />
</c><br />
<br />
Ein weiterer nützlicher "Assembler-Einzeiler" ist der Aufruf von sleep (''asm volatile ("sleep");''), da hierzu in älteren Versionen der avr-libc keine eigene Funktion existiert (in neueren Versionen ''sleep_cpu()'' aus sleep.h).<br />
<br />
Als Beispiel für mehrzeiligen Inline-Assembler eine präzise Delay-Funktion. Die Funktion erhält ein 16-bit Wort als Parameter, prüft den Parameter auf 0 und beendet die Funktion in diesem Fall oder durchläuft die folgende Schleife sooft wie im Wert des Parameters angegeben. Inline-Assembler hat hier den Vorteil, dass die Laufzeit unabhängig von der Optimierungsstufe (Parameter -O, vgl. makefile) und der Compiler-Version ist.<br />
<br />
<c><br />
static inline void delayloop16 (uint16_t count)<br />
{<br />
asm volatile ("cp %A0, __zero_reg__ \n\t"<br />
"cpc %B0, __zero_reg__ \n\t"<br />
"breq 2f \n\t"<br />
"1: \n\t"<br />
"sbiw %0,1 \n\t"<br />
"brne 1b \n\t"<br />
"2: " <br />
: "=w" (count)<br />
: "0" (count)<br />
); <br />
}<br />
</c><br />
<br />
* Jede Anweisung wird mit '''\n\t''' abgeschlossen. Der Zeilenumbruch teilt dem Assembler mit, dass ein neuer Befehl beginnt.<br />
* Als Sprung-Marken (Labels) werden Ziffern verwendet. Diese speziellen Labels sind mehrfach im Code verwendbar. Gesprungen wird jeweils zurück (b) oder vorwärts (f) zum nächsten auffindbaren Label.<br />
<br />
Das Resultat zeigt ein Blick in die Assembler-Datei, die der Compiler mit der option <tt>-save-temps</tt> nicht löscht:<br />
<br />
<avrasm><br />
cp r24, __zero_reg__ ; count<br />
cpc r25, __zero_reg__ ; count<br />
breq 2f <br />
1: <br />
sbiw r24,1 ; count<br />
brne 1b <br />
2:<br />
</avrasm><br />
<br />
Detaillierte Ausführungen zum Thema Inline-Assembler finden sich in der Dokumentation der avr-libc im Abschnitt [http://www.nongnu.org/avr-libc/user-manual/inline_asm.html Related Pages/Inline Asm]. <br />
<br />
Siehe auch: <br />
* [http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf AVR Assembler-Anweisungsliste]<br />
* [http://www.roboternetz.de/wissen/index.php/Inline-Assembler_in_avr-gcc Deutsche Einführung in Inline-Assembler]<br />
<br />
== Assembler-Dateien ==<br />
<br />
Assembler-Dateien erhalten die Endung .S (''grosses'' S) und werden im makefile nach WinAVR/mfile-Vorlage hinter ''ASRC='' durch Leerzeichen getrennt aufgelistet.<br />
<br />
Wenn man mit dem AVR Studio arbeitet, kann alternativ auch das standardmäßig erstellte Makefile bearbeitet und folgende Zeilen eingefügt werden:<br />
<br />
<div class="code"><pre><br />
## Objects that must be built in order to link<br />
OBJECTS = (alte Dateien...) useful.o<br />
<br />
## Compile<br />
## Hier folgt eine Liste der gelinkten Dateien, darunter einfügen:<br />
useful.o: ../useful.S<br />
$(CC) $(INCLUDES) $(ASMFLAGS) -c $<<br />
<br />
</pre></div><br />
Das war es schon. Allerdings gilt es zu beachten, dass das makefile über "Project -> Configuration options" selbst einzubinden ist, sonst wird es natürlich wieder überschrieben.<br />
<br />
Im Beispiel eine Funktion ''superFunc'', die alle Pins des Ports D auf "Ausgang" schaltet, eine Funktion ''ultraFunc'', die die Ausgänge entsprechend des übergebenen Parameters schaltet, eine Funktion ''gigaFunc'', die den Status von Port A zurückgibt und eine Funktion ''addFunc'', die zwei Bytes zu einem 16-bit-Wort addiert. Die Zuweisungen im C-Code (PORTx = ...) verhindern, dass der Compiler die Aufrufe wegoptimiert und dienen nur zur Veranschaulichung der Parameterübergaben.<br />
<br />
Zuerst der Assembler-Code. Der Dateiname sei useful.S:<br />
<br />
<avrasm><br />
#include "avr/io.h"<br />
<br />
//; Arbeitsregister (ohne "r") <br />
workreg = 16<br />
workreg2 = 17<br />
<br />
//; Konstante:<br />
ALLOUT = 0xff<br />
<br />
//; ** Setze alle Pins von PortD auf Ausgang **<br />
//; keine Parameter, keine Rückgabe<br />
.global superFunc<br />
.func superFunc<br />
superFunc:<br />
push workreg<br />
ldi workreg, ALLOUT<br />
out _SFR_IO_ADDR(DDRD), workreg // beachte: _SFR_IO_ADDR()<br />
pop workreg<br />
ret<br />
.endfunc<br />
<br />
<br />
//; ** Setze PORTD auf übergebenen Wert **<br />
//; Parameter in r24 (LSB immer bei "graden" Nummern)<br />
.global ultraFunc<br />
.func ultraFunc<br />
ultraFunc:<br />
out _SFR_IO_ADDR(PORTD), 24<br />
ret<br />
.endfunc<br />
<br />
<br />
//; ** Zustand von PINA zurückgeben **<br />
//; Rückgabewerte in r24:r25 (LSB:MSB), hier nur LSB genutzt<br />
.global gigaFunc<br />
.func gigaFunc<br />
gigaFunc:<br />
in 24, _SFR_IO_ADDR(PINA)<br />
ret<br />
.endfunc<br />
<br />
<br />
//; ** Zwei Bytes addieren und 16-bit-Wort zurückgeben **<br />
//; Parameter in r24 (Summand1) und r22 (Summand2) -<br />
//; Parameter sind Word-"aligned" d.h. LSB immer auf "graden"<br />
//; Registernummern. Bei 8-Bit und 16-Bit Paramtern somit <br />
//; beginnend bei r24 dann r22 dann r20 etc.<br />
//; Rückgabewert in r24:r25<br />
.global addFunc<br />
.func addFunc<br />
addFunc:<br />
push workreg<br />
push workreg2<br />
clr workreg2<br />
mov workreg, 22<br />
add workreg, 24<br />
adc workreg2, 1 // r1 - assumed to be always zero ...<br />
movw r24, workreg<br />
pop workreg2<br />
pop workreg<br />
ret<br />
.endfunc<br />
<br />
//; oh je - sorry - Mein AVR-Assembler ist eingerostet, hoffe das stimmt so...<br />
<br />
.end<br />
</avrasm><br />
<br />
Im Makefile ist der Name der Assembler-Quellcodedatei einzutragen:<br />
<br />
<div class="code"><pre><br />
ASRC = useful.S<br />
</pre></div><br />
<br />
Der Aufruf erfolgt dann im C-Code so:<br />
<br />
<c><br />
<br />
#include <stdint.h><br />
#include <avr/io.h><br />
<br />
extern void superFunc(void);<br />
extern void ultraFunc(uint8_t setVal);<br />
extern uint8_t gigaFunc(void);<br />
extern uint16_t addFunc(uint8_t w1, uint8_t w2);<br />
<br />
int main(void)<br />
{<br />
[...]<br />
superFunc();<br />
<br />
ultraFunc(0x55);<br />
<br />
PORTD = gigaFunc();<br />
<br />
PORTA = (addFunc(0xF0, 0x11) & 0xff);<br />
PORTB = (addFunc(0xF0, 0x11) >> 8);<br />
[...]<br />
} <br />
</c><br />
<br />
Das Ergebnis wird wieder in der lss-Datei ersichtlich:<br />
<br />
<div class="code"><pre><br />
[...]<br />
superFunc();<br />
148: 0e 94 f6 00 call 0x1ec<br />
<br />
ultraFunc(0x55);<br />
14c: 85 e5 ldi r24, 0x55 ; 85<br />
14e: 0e 94 fb 00 call 0x1f6<br />
<br />
PORTD = gigaFunc();<br />
152: 0e 94 fd 00 call 0x1fa<br />
156: 82 bb out 0x12, r24 ; 18<br />
<br />
PORTA = (addFunc(0xF0, 0x11) & 0xff);<br />
158: 61 e1 ldi r22, 0x11 ; 17<br />
15a: 80 ef ldi r24, 0xF0 ; 240<br />
15c: 0e 94 ff 00 call 0x1fe<br />
160: 8b bb out 0x1b, r24 ; 27<br />
PORTB = (addFunc(0xF0, 0x11) >> 8);<br />
162: 61 e1 ldi r22, 0x11 ; 17<br />
164: 80 ef ldi r24, 0xF0 ; 240<br />
166: 0e 94 fc 00 call 0x1f8<br />
16a: 89 2f mov r24, r25<br />
16c: 99 27 eor r25, r25<br />
16e: 88 bb out 0x18, r24 ; 24<br />
<br />
[...]<br />
000001ec <superFunc>:<br />
// setze alle Pins von PortD auf Ausgang<br />
.global superFunc<br />
.func superFunc<br />
superFunc:<br />
push workreg<br />
1ec: 0f 93 push r16<br />
ldi workreg, ALLOUT<br />
1ee: 0f ef ldi r16, 0xFF ; 255<br />
out _SFR_IO_ADDR(DDRD), workreg<br />
1f0: 01 bb out 0x11, r16 ; 17<br />
pop workreg<br />
1f2: 0f 91 pop r16<br />
ret<br />
1f4: 08 95 ret<br />
<br />
000001f6 <ultraFunc>:<br />
.endfunc<br />
<br />
<br />
// setze PORTD auf übergebenen Wert<br />
.global ultraFunc<br />
.func ultraFunc<br />
ultraFunc:<br />
out _SFR_IO_ADDR(PORTD), 24<br />
1f6: 82 bb out 0x12, r24 ; 18<br />
ret<br />
1f8: 08 95 ret<br />
<br />
000001fa <gigaFunc>:<br />
.endfunc<br />
<br />
<br />
// Zustand von PINA zurückgeben<br />
.global gigaFunc<br />
.func gigaFunc<br />
gigaFunc:<br />
in 24, _SFR_IO_ADDR(PINA)<br />
1fa: 89 b3 in r24, 0x19 ; 25<br />
ret<br />
1fc: 08 95 ret<br />
<br />
000001fe <addFunc>:<br />
.endfunc<br />
<br />
<br />
// zwei Bytes addieren und 16-bit-Wort zurückgeben<br />
.global addFunc<br />
.func addFunc<br />
addFunc:<br />
push workreg<br />
1fe: 0f 93 push r16<br />
push workreg2<br />
200: 1f 93 push r17<br />
clr workreg2<br />
202: 11 27 eor r17, r17<br />
mov workreg, 22<br />
204: 06 2f mov r16, r22<br />
add workreg, 24<br />
206: 08 0f add r16, r24<br />
adc workreg2, 1 // r1 - assumed to be always zero ...<br />
208: 11 1d adc r17, r1<br />
movw r24, workreg<br />
20a: c8 01 movw r24, r16<br />
pop workreg2<br />
20c: 1f 91 pop r17<br />
pop workreg<br />
20e: 0f 91 pop r16<br />
ret<br />
210: 08 95 ret<br />
<br />
[...]<br />
</pre></div><br />
<br />
Die Zuweisung von Registern zu Parameternummer und die Register für die Rückgabewerte sind in den "Register Usage Guidelines" der avr-libc-Dokumentation erläutert.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/assembler.html avr-libc-Dokumentation: Related Pages/avr-libc and assembler programs]<br />
* [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage avr-libc-Dokumentation: Related Pages/FAQ/"What registers are used by the C compiler?"]<br />
<br />
== Globale Variablen für Datenaustausch ==<br />
<br />
Oftmals kommt man um globale Variablen nicht herum, z.B. um den Datenaustausch zwischen Hauptprogramm und Interrupt-Routinen zu realisieren. <br />
Hierzu muss man im Assembler wissen, wo genau die Variable vom C-Compiler abgespeichert wird.<br />
<br />
Hierzu muss die Variable, hier "zaehler" genannt, zuerst im C-Code als Global definiert werden, z.B. so:<br />
<br />
<c><br />
#include <avr/io.h><br />
<br />
volatile uint8_t zaehler;<br />
<br />
int16_t main (void)<br />
{<br />
// irgendein Code, in dem zaehler benutzt werden kann<br />
<br />
}<br />
</c><br />
<br />
Im folgenden Assembler-Beispiel wird der Externe Interrupt0 verwendet, um den Zähler hochzuzählen. Es fehlen die Initialisierungen des Interrupts und die Interrupt-Freigabe, so richtig sinnvoll ist der Code auch nicht, aber er zeigt (hoffentlich) wie es geht.<br />
<br />
Im Umgang mit Interrupt-Vektoren gilt beim GCC-Assembler das Gleiche, wie bei C: Man muss die exakte Schreibweise beachten, ansonsten wird nicht der Interrupt-Vektor angelegt, sondern eine neue Funktion - und man wundert sich, dass nichts funktionert (vgl. das AVR-GCC-Handbuch).<br />
<br />
<avrasm><br />
#include "avr/io.h"<br />
<br />
temp = 16<br />
<br />
.extern zaehler<br />
<br />
.global INT0_vect<br />
INT0_vect:<br />
<br />
push temp //; wichtig: Benutzte Register und das<br />
in temp,_SFR_IO_ADDR(SREG) //; Status-Register (SREG) sichern!<br />
push temp<br />
<br />
lds temp,zaehler //; Wert aus dem Speicher lesen<br />
inc temp //; bearbeiten<br />
sts zaehler,temp //; und wieder zurückschreiben<br />
<br />
pop temp //; die benutzten Register wiederherstellen<br />
out _SFR_IO_ADDR(SREG),temp<br />
pop temp<br />
reti<br />
<br />
.end<br />
</avrasm><br />
<br />
=== Globale Variablen im Assemblerfile anlegen ===<br />
<br />
Alternativ können Variablen aber auch im Assemblerfile angelegt werden. Dadurch kann auf eine .c-Datei verzichtet werden. Für das obige Beispiel könnte der Quelltext dann die Dateien zaehl_asm.S und zaehl_asm.h abgelegt werden, so dass nur noch zaehl_asm.S mit kompiliert werden müsste.<br />
<br />
Anstatt im Assemblerfile über das Schlüsselwort ''.extern '' auf eine vorhandene Variable zu verweisen, wird dazu mit dem Schlüsselwort ''.comm'' die benötigte Anzahl von Bytes für eine Variable reserviert.<br />
<br />
'''zaehl_asm.S'''<br />
<avrasm><br />
#include "avr/io.h"<br />
<br />
temp = 16<br />
<br />
//; 1 Byte im RAM für den Zähler reservieren<br />
.comm zaehler, 1<br />
<br />
.global INT0_vect<br />
INT0_vect:<br />
<br />
...<br />
</avrasm><br />
<br />
In der Headerdatei wird dann auf die Variable nur noch verwiesen (Schlüsselwort ''extern''):<br />
<br />
'''zaehl_asm.h'''<br />
<c><br />
#ifndef ZAEHL_ASM_H<br />
#define ZAEHL_ASM_H<br />
<br />
extern volatile uint8_t zaehler;<br />
<br />
#endif<br />
</c><br />
<br />
Im Gegensatz zu globalen Variablen in C werden so angelegte Variablen nicht automatisch mit dem Wert 0 initialisiert. <br />
<br />
<br />
=== Variablen größer als 1 Byte ===<br />
<br />
Variablen, die größer als '''ein''' Byte sind, können in Assembler auf ähnliche Art angesprochen werden. Hierzu müssen nur genug Bytes angefordert werden, um die Variable aufzunehmen. Soll z.B. für den Zähler eine Variable vom Typ ''unsigned long'', also ''uint32_t'' verwendet werden, so müssen 4 Bytes reserviert werden:<br />
<br />
<avrasm><br />
...<br />
// 4 Byte im RAM für den Zähler reservieren<br />
.comm zaehler, 4<br />
...<br />
</avrasm><br />
<br />
Die dazugehörige Deklaration im Headerfile wäre dann:<br />
<c><br />
...<br />
extern volatile uint32_t zaehler;<br />
...<br />
</c><br />
<br />
Bei Variablen, die größer als ein Byte sind, werden die Werte beginnend mit dem niederwertigsten Byte im RAM abgelegt. Das folgende Codeschnippsel zeigt, wie unter Assembler auf die einzelnen Bytes zugegriffen werden kann. Dazu wird im Interrupt nun ein 32-Bit Zähler erhöht:<br />
<br />
<avrasm><br />
#include "avr/io.h"<br />
<br />
temp = 16<br />
<br />
// 4 Byte im RAM für den Zähler reservieren<br />
.comm zaehler, 4<br />
<br />
.global INT0_vect<br />
INT0_vect:<br />
<br />
push temp // wichtig: Benutzte Register und das<br />
in temp,_SFR_IO_ADDR(SREG) // Status-Register (SREG) sichern !<br />
push temp<br />
<br />
// 32-Bit-Zähler incrementieren<br />
lds temp, (zaehler + 0) // 0. Byte (niederwertigstes Byte)<br />
inc temp<br />
sts (zaehler + 0), temp<br />
brne RAUS<br />
<br />
lds temp, (zaehler + 1) // 1. Byte<br />
inc temp<br />
sts (zaehler + 1), temp<br />
brne RAUS<br />
<br />
lds temp, (zaehler + 2) // 2. Byte<br />
inc temp<br />
sts (zaehler + 2), temp<br />
brne RAUS<br />
<br />
lds temp, (zaehler + 3) // 3. Byte (höchstwertigstes Byte)<br />
inc temp<br />
sts (zaehler + 3), temp<br />
brne RAUS<br />
<br />
RAUS:<br />
pop temp // die benutzten Register wiederherstellen<br />
out _SFR_IO_ADDR(SREG),temp<br />
pop temp<br />
reti<br />
<br />
.end<br />
</avrasm><br />
<br />
'''TODO:''' 16-Bit / 32-Bit Variablen, Zugriff auf Arrays (Strings)<br />
<br />
= Anhang =<br />
<br />
== Besonderheiten bei der Anpassung bestehenden Quellcodes ==<br />
<br />
Einige Funktionen aus früheren Versionen der avr-libc werden inzwischen als veraltet angesehen. Sie sind nicht mehr vorhanden oder als ''deprecated'' (missbilligt) ausgewiesen und Definitionen in <compat/deprecated.h> verschoben. Es empfiehlt sich, vorhandenen Code zu portieren und die alten Funktionen nicht mehr zu nutzen, auch wenn diese noch zur Verfügung stehen.<br />
<br />
=== Veraltete Funktionen zur Deklaration von Interrupt-Routinen ===<br />
<br />
Die Funktionen (eigentlich Makros) ''SIGNAL'' und ''INTERRUPT'' zur Deklaration von Interruptroutinen sollten nicht mehr genutzt werden. <br />
<br />
In aktuellen Versionen der avr-libc (z.B. avr-libc 1.4.3 aus WinAVR 20060125) werden Interruptroutinen, die '''nicht''' durch andere Interrupts '''unterbrechbar''' sind, mit ISR deklariert (siehe Abschnitt im Hauptteil). Auch die Benennung wurden vereinheitlicht und an die üblichen Bezeichnungen in den AVR Datenblättern angepasst. In der Dokumentation der avr-libc sind alte und neue Bezeichnungen in der Tabelle gegenübergestellt. Die erforderlichen Schritte zur Portierung:<br />
<br />
* #include von avr/signal.h entfernen<br />
* SIGNAL durch ISR ersetzen<br />
* Name des Interrupt-Vektors anpassen (SIG_* durch entsprechendes *_vect)<br />
<br />
Als Beispiel für die Anpassung zuerst ein "alter" Code:<br />
<br />
<c><br />
#include <avr/interrupt.h><br />
#include <avr/signal.h><br />
<br />
...<br />
<br />
/* Timer2 Output Compare bei einem ATmega8 */<br />
SIGNAL(SIG_OUTPUT_COMPARE2)<br />
{<br />
...<br />
}<br />
</c><br />
<br />
Im Datenblatt wird der Vektor mit TIMER2 COMP bezeichnet. Die Bezeichnung in der avr-libc entspricht dem Namen im Datenblatt, Leerzeichen werden durch Unterstriche (_) ersetzt und ein _vect angehängt. <br />
<br />
Der neue Code sieht dann so aus:<br />
<br />
<c><br />
#include <avr/interrupt.h> <br />
/* signal.h entfällt */<br />
<br />
ISR(TIMER2_COMP_vect)<br />
{<br />
...<br />
}<br />
</c><br />
<br />
Bei Unklarheiten bezüglich der neuen Vektorlabels hilft (noch) ein Blick in die Headerdatei des entsprechenden Controllers. Für das vorherige Beispiel also der Blick in die Datei iom8.h für den ATmega8, dort findet man die veraltete Bezeichnung unterhalb der aktuellen.<br />
<br />
<c><br />
...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
<br />
...<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
...<br />
</c><br />
<br />
Für '''unterbrechbare''' Interruptroutinen, die mittels ''INTERRUPT'' deklariert sind, gibt es keinen direkten Ersatz in Form eines Makros. Solche Routinen sind laut Dokumentation der avr-libc in folgender Form zu deklarieren:<br />
<br />
<c><br />
void XXX_vect(void) __attribute__((interrupt));<br />
void XXX_vect(void) {<br />
...<br />
}<br />
</c><br />
<br />
Beispiel:<br />
<br />
<c><br />
/* ** alt ** */<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
<br />
//...<br />
<br />
INTERRUPT(SIG_OVERFLOW0)<br />
{<br />
...<br />
}<br />
<br />
/* ** neu: ** */<br />
#include <avr/io.h><br />
<br />
//...<br />
<br />
void TIMER0_OVF_vect(void) __attribute__((interrupt));<br />
void TIMER0_OVF_vect(void) <br />
{<br />
...<br />
}<br />
</c><br />
<br />
Will oder kann man den Code nicht portieren, ist zur weiteren Verwendung von ''INTERRUPT'' die Header-Datei ''compat/deprecated.h'' einzubinden. Man sollte bei dieser Gelegenheit jedoch nochmals überprüfen, ob die Funktionalität von ''INTERRUPT'' tatsächlich gewollt ist. In vielen Fällen wurde ''INTERRUPT'' dort genutzt, wo eigentlich ''SIGNAL'' (nunmehr ''ISR'') hätte genutzt werden sollen.<br />
<br />
=== Veraltete Funktionen zum Portzugriff ===<br />
<br />
''inp'' und ''outp'' zum Einlesen bzw. Schreiben von Registern sind nicht mehr erforderlich, der Compiler unterstützt dies ohne diesen Umweg.<br />
<br />
<c><br />
unsigned char i, j;<br />
<br />
// alt:<br />
i = inp(PINA);<br />
j = 0xff;<br />
outp(PORTB, j);<br />
<br />
// neu (nicht mehr wirklich neu...):<br />
i = PINA<br />
j = 0xff;<br />
PORTB = j;<br />
</c><br />
<br />
Will oder kann man den Code nicht portieren, ist zur weiteren Verwendung von inp und outp die Header-Datei '''compat/deprecated.h''' einzubinden.<br />
<br />
=== Veraltete Funktionen zum Zugriff auf Bits in Registern ===<br />
<br />
''cbi'' und ''sbi'' zum Löschen und Setzen von Bits sind nicht mehr erforderlich, der Compiler unterstützt dies ohne diesen Umweg. Die Bezeichnung ist ohnehin irreführend da die Funktionen nur für Register mit Adressen im unteren Speicherbereich tatsächlich in die Assembleranweisungen cbi und sbi übersetzt werden.<br />
<br />
<c><br />
// alt:<br />
sbi(PORTB, PB2);<br />
cbi(PORTC, PC1);<br />
<br />
// neu (auch nicht mehr wirklich neu...):<br />
PORTB |= (1<<PB2);<br />
PORTC &= ~(1<<PC1);<br />
</c><br />
<br />
Will oder kann man den Code nicht portieren, ist zur weiteren Verwendung von sbi und cbi die Header-Datei '''compat/deprecated.h''' einzubinden. Wer unbedingt will, kann sich natürlich eigene Makros mit aussagekräftigeren Namen definieren. Zum Beispiel:<br />
<br />
<c><br />
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))<br />
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))<br />
#define TOGGLE_BIT(PORT, BITNUM) ((PORT) ^= (1<<(BITNUM)))<br />
</c><br />
<br />
=== Selbstdefinierte (nicht-standardisierte) ganzzahlige Datentypen ===<br />
<br />
Bei den im Folgenden genannten Typdefinitionen ist zu beachten, dass die Bezeichnungen für "Worte" teilweise je nach Prozessorplattform unterschiedlich verwendet werden. Die angegebenen Definitionen beziehen sich auf die im Zusammenhang mit AVR/8-bit-Controllern üblichen "Bit-Breiten" (In Erläuterungen zum ARM7TDMI z.B. werden oft 32-bit Integer mit "Wort" ohne weitere Ergänzung bezeichnet). Es empfiehlt sich, bei der Überarbeitung von altem Code die im Abschnitt ''standardisierten ganzzahligen Datentypen'' beschriebenen Datentypen zu nutzen (stdint.h) und damit "Missverständnissen" vorzubeugen, die z.B. bei der Portierung von C-Code zwischen verschiedenen Plattformen auftreten können.<br />
<br />
<c><br />
typedef unsigned char BYTE; // besser: uint8_t aus <stdint.h><br />
typedef unsigned short WORD; // besser: uint16_t aus <stdint.h><br />
typedef unsigned long DWORD; // besser: uint32_t aus <stdint.h><br />
typedef unsigned long long QWORD; // besser: uint64_t aus <stdint.h><br />
</c><br />
<br />
; BYTE : Der Datentyp BYTE definiert eine Variable mit 8 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 255. <br />
<br />
; WORD : Der Datentyp WORD definiert eine Variable mit 16 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 65535. <br />
<br />
; DWORD : Der Datentyp DWORD (gesprochen: Double-Word) definiert eine Variable mit 32 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 4294967295.<br />
<br />
; QWORD : Der Datentyp QWORD (gesprochen: Quad-Word) definiert eine Variable mit 64 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 18446744073709551615.<br />
<br />
== Zusätzliche Funktionen im Makefile ==<br />
<br />
=== Bibliotheken (Libraries/.a-Dateien) hinzufügen ===<br />
<br />
Um Funktionen aus Bibliotheken ("echte" Libraries, *.a-Dateien) zu nutzen, sind dem Linker die Namen der Bibliotheken als Parameter zu übergeben. Dazu ist die Option -l (kleines L) vorgesehen, an die der Name der Library angehängt wird. <br />
<br />
Dabei ist zu beachten, dass der Name der Library und der Dateiname der Library nicht identisch sind. Der hinter -l angegebene Name entspricht dem Dateinamen der Library ohne die Zeichenfolge ''lib'' am Anfang des Dateinamens und ohne die Endung ''.a''. Sollen z.B. Funktionen aus einer Library mit dem Dateinamen ''libefsl.a'' eingebunden (gelinkt) werden, lautet der entsprechende Parameter -lefsl (vergl. auch -lm zum Anbinden von libm.a). <br />
<br />
In Makefiles wird traditonell eine make-Variable LDLIBS genutzt, in die "l-Parameter" abgelegt werden. Die WinAVR-makefile-Vorlage enthält diese Variable zwar nicht, dies stellt jedoch keine Einschränkung dar, da alle in der make-Variable LDFLAGS abgelegten Parameter an den Linker weitergereicht werden. <br />
<br />
Beispiele:<br />
<br />
<div class="code"><pre><br />
# Einbinden von Funktionen aus einer Library efsl (Dateiname libefsl.a)<br />
LDFLAGS += -lefsl<br />
# Einbinden von Funktionen aus einer Library xyz (Dateiname libxyz.a)<br />
LDFLAGS += -lxyz<br />
</pre></div><br />
<br />
Liegen die Library-Dateien nicht im Standard Library-Suchpfad, sind die Pfade mittels Parameter ''-L'' ebenfalls anzugeben. (Der vordefinierte Suchpfad kann mittels ''avr-gcc --print-search-dirs'' angezeigt werden.)<br />
<br />
Als Beispiel ein Projekt ("superapp2"), in dem der Quellcode von zwei Libraries (efsl und xyz) und der Quellcode der eigentlichen Anwendung in verschiedenen Verzeichnissen mit der folgenden "Baumstruktur" abgelegt sind:<br />
<br />
<div class="code"><pre><br />
superapp2<br />
|<br />
+----- efslsource (darin libefsl.a)<br />
|<br />
+----- xyzsource (darin libxyz.a)<br />
|<br />
+----- firmware (darin Anwendungs-Quellcode und Makefile)<br />
</pre></div><br />
<br />
Daraus folgt, dass im Makefile die Verzeichnis efslsource und xyzsource in den Library-Suchpfad aufzunehmen sind:<br />
<br />
<div class="code"><pre><br />
LDFLAGS += -L../efslsource/ -L../xyzsource/<br />
</pre></div><br />
<br />
=== Fuse-Bits ===<br />
<br />
Zur Berechnung der Fuse-Bits bietet sich neben dem Studium des Datenblattes auch der [http://palmavr.sourceforge.net/cgi-bin/fc.cgi AVR Fuse Calculator] an. Gewarnt werden muss vor der Benutzung von PonyProg, weil dort durch die negierte Darstellung gern Fehler gemacht werden.<br />
<br />
Soll die Programmierung von Fuse- und Lockbits automatisiert werden, kann man dies ebenfalls durch Einträge im Makefile vornehmen, die beim Aufruf von "make program" an die genutzte Programmiersoftware übergeben werden. In der makefile-Vorlage von WinAVR (und mfile) gibt es dafuer jedoch keine "Ausfüllhilfe" (Stand 9/2006). Die folgenden Ausführungen gelten für die Programmiersoftware [[AVRDUDE]] (Standard in der WinAVR-Vorlage), können jedoch sinngemäß auf andere Programmiersoftware übertragen werden, die die Angabe der Fuse- und Lockbits-Einstellungen per Kommandozeilenparameter unterstützt (z.B. stk500.exe). Im einfachsten Fall ergänzt man im Makefile einige Variablen, deren Werte natürlich vom verwendeten Controller und den gewünschten Einstellungen abhängen (vgl. Datenblatt Fuse-/Lockbits):<br />
<br />
<c><br />
#---------------- Programming Options (avrdude) ----------------<br />
<br />
#...<br />
#Beispiel! f. ATmega16 - nicht einfach uebernehmen! Zahlenwerte anhand<br />
#--------- des Datenblatts nachvollziehen und gegebenenfalls aendern.<br />
#<br />
AVRDUDE_WRITE_LFUSE = -U lfuse:w:0xff:m<br />
AVRDUDE_WRITE_HFUSE = -U hfuse:w:0xd8:m<br />
AVRDUDE_WRITE_LOCK = -U lock:w:0x2f:m<br />
#...<br />
</c><br />
<br />
Damit diese Variablen auch genutzt werden, ist der Aufruf von avrdude im Makefile entsprechend zu ergänzen:<br />
<br />
<c><br />
# Program the device. <br />
program: $(TARGET).hex $(TARGET).eep<br />
# ohne Fuse-/Lock-Einstellungen (nach WinAVR Vorlage Stand 4/2006)<br />
# $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) \<br />
# $(AVRDUDE_WRITE_EEPROM)<br />
# mit Fuse-/Lock-Einstellungen<br />
$(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_LFUSE) \<br />
$(AVRDUDE_WRITE_HFUSE) $(AVRDUDE_WRITE_FLASH) \<br />
$(AVRDUDE_WRITE_EEPROM) $(AVRDUDE_WRITE_LOCK)<br />
</c><br />
<br />
Eine weitere Möglichkeit besteht darin, die Fuse- und Lockbit-Einstellungen vom Preprozessor/Compiler generieren zu lassen. Die Fuse-Bits werden dann bei Verwendung von AVRDUDE in eigene Hex-Files geschrieben. Hierzu kann man z.B. folgendes Konstrukt verwenden:<br />
<br />
In eine der C-Sourcen wird eine Variable je Fuse-Byte vom Typ ''unsigned char'' deklariert und in eine extra Section gepackt. Dies kann entweder in einem vorhandenen File passieren oder in ein neues (z.B. fuses.c) geschrieben werden. Das File muss im Makefile aber auf jeden Fall mit kompiliert und gelinkt werden.<br />
<br />
<c><br />
// tiny 2313 fuses low byte<br />
#define CKDIV8 7<br />
#define CKOUT 6<br />
#define SUT1 5<br />
#define SUT0 4<br />
#define CKSEL3 3<br />
#define CKSEL2 2<br />
#define CKSEL1 1<br />
#define CKSEL0 0<br />
<br />
// tiny2313 fuses high byte<br />
#define DWEN 7<br />
#define EESAVE 6<br />
#define SPIEN 5<br />
#define WDTON 4<br />
#define BODLEVEL2 3<br />
#define BODLEVEL1 2<br />
#define BODLEVEL0 1<br />
#define RSTDISBL 0<br />
<br />
// tiny2313 fuses extended byte<br />
#define SELFPRGEN 0<br />
<br />
#define LFUSE __attribute__ ((section ("lfuses")))<br />
#define HFUSE __attribute__ ((section ("hfuses")))<br />
#define EFUSE __attribute__ ((section ("efuses")))<br />
<br />
<br />
// select ext crystal 3-8Mhz<br />
unsigned char lfuse LFUSE =<br />
( (1<<CKDIV8) | (1<<CKOUT) | (1<<CKSEL3) | (1<<CKSEL2) | <br />
(0<<CKSEL1) | (1<<CKSEL0) | (0<<SUT1) | (1<<SUT0) );<br />
unsigned char hfuse HFUSE =<br />
( (1<<DWEN) | (1<<EESAVE) | (0<<SPIEN) | (1<<WDTON) | <br />
(1<<BODLEVEL2) | (1<<BODLEVEL1) | (0<<BODLEVEL0) | (1<<RSTDISBL) );<br />
unsigned char efuse EFUSE =<br />
((0<<SELFPRGEN));<br />
</c><br />
<br />
'''ACHTUNG: Die Bitpositionen wurden nicht vollständig getestet!'''<br />
<br />
Eine "1" bedeutet hier, dass das Fuse-Bit ''nicht'' programmiert wird - die Funktion also i.A. nicht aktiviert ist. Eine "0" hingegen aktiviert die meisten Funktionen. Dies ist wie im Datenblatt (1 = unprogrammed, 0 = programmed).<br />
<br />
Das Makefile muss nun noch um folgende Targets erweitert werden (mit Tabulator einrücken - nicht mit Leerzeichen):<br />
<br />
<div class="code"><pre><br />
lfuses: build<br />
-$(OBJCOPY) -j lfuses --change-section-address lfuses=0 \<br />
-O ihex $(TARGET).elf $(TARGET)-lfuse.hex<br />
@if [ -f $(TARGET)-lfuse.hex ]; then \<br />
$(AVRDUDE) $(AVRDUDE_FLAGS) -U lfuse:w:$(TARGET)-lfuse.hex; \<br />
fi;<br />
<br />
hfuses: build<br />
-$(OBJCOPY) -j hfuses --change-section-address hfuses=0 \<br />
-O ihex $(TARGET).elf $(TARGET)-hfuse.hex<br />
@if [ -f $(TARGET)-hfuse.hex ]; then \<br />
$(AVRDUDE) $(AVRDUDE_FLAGS) -U hfuse:w:$(TARGET)-hfuse.hex; \<br />
fi;<br />
<br />
efuses: build<br />
-$(OBJCOPY) -j efuses --change-section-address efuses=0 \<br />
-O ihex $(TARGET).elf $(TARGET)-efuse.hex<br />
@if [ -f $(TARGET)-efuse.hex ]; then \<br />
$(AVRDUDE) $(AVRDUDE_FLAGS) -U efuse:w:$(TARGET)-efuse.hex;<br />
fi;<br />
</pre></div><br />
<br />
Das Target "clean" muss noch um die Zeilen<br />
<div class="code"><pre><br />
$(REMOVE) $(TARGET)-lfuse.hex<br />
$(REMOVE) $(TARGET)-hfuse.hex<br />
$(REMOVE) $(TARGET)-efuse.hex<br />
</pre></div><br />
erweitert werden, wenn auch die Fuse-Dateien gelöscht werden sollen.<br />
<br />
Um nun die Fusebits des angeschlossenen Controllers zu programmieren muss lediglichein "make lfuses", "make hfuses" oder "make efuses" gestartet werden.<br />
Bei den Fuse-Bits ist besondere Vorsicht geboten, da diese das Programmieren des Controllers unmöglich machen können. Also erst programmieren, wenn man einen HV-Programmierer hat oder ein paar Reserve-AVRs zur Hand ;-)<br />
<br />
Um weiterhin den "normalen" Flash beschreiben zu können, ist es wichtig, für das Target "*.hex" im Makefile nicht nur "-R .eeprom" als Parameter zu übergeben sondern zusätzlich noch "-R lfuses -R efuses -R hfuses". Sonst bekommt AVRDUDE Probleme diese Sections in den Flash (wo sie ja nicht hingehören) zu schreiben.<br />
<br />
Siehe auch: [[AVR_Fuses#Vergleich_der_Fuses_bei_verschiedenen_Programmen|Vergleich der Fuses bei verschiedenen Programmen]]<br />
<br />
== Externe Referenzspannung des internen Analog-Digital-Wandlers ==<br />
<br />
Die minimale (externe) Referenzspannung des ADC darf nicht beliebig niedrig sein, vgl. dazu das (aktuellste) Datenblatt des verwendeten Controllers. z.B. beim ATMEGA8 darf sie laut Datenblatt (S.245, Tabelle 103, Zeile "VREF") 2,0V nicht unterschreiten. HINWEIS: diese Information findet sich erst in der letzten Revision (Rev. 2486O-10/04) des Datenblatts.<br />
<br />
Meiner <!-- Wer? - es gibt inzwischen x Leute die mehr oder weniger viel in diesem Artikel geschrieben haben --> eigenen Erfahrung nach kann man aber (auf eigene Gefahr und natürlich nicht für Seriengeräte) durchaus noch ein klein wenig weiter heruntergehen, bei dem von mir unter die Lupe genommenen ATMEGA8L (also die Low-Voltage-Variante) funktioniert der ADC bei 5V Betriebsspannung mit bis zu VREF=1,15V hinunter korrekt, ab 1,1V und darunter digitalisiert er jedoch nur noch Blödsinn). Ich würde sicherheitshalber nicht unter 1,5V gehen und bei niedrigeren Betriebsspannungen mag sich die Untergrenze für VREF am Pin AREF ggf. nach oben'''(!)''' verschieben.<br />
<br />
In der letzten Revision des Datenblatts ist außerdem korrigiert, dass ADC4 und ADC5 sehr wohl 10 Bit Genauigkeit bieten (und nicht bloß 8 Bit, wie in älteren Revisionen irrtümlich angegeben.)<br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* stdio.h, malloc() <br />
* Code-Optimierungen ("tricks"), siehe auch Application Note [http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf AVR035: Efficient C Coding for AVR]<br />
* "naked"-Funktionen<br />
* SPI siehe [http://www.uni-koblenz.de/~physik/informatik/MCU/SPI.pdf SPI Bus mit Atmel AVR]<br />
* I²C / TWI Bus [http://www.roboternetz.de/wissen/index.php/TWI]<br />
* Bootloader (bez. auf boot.h)<br />
* CAN-Bus<br />
* Einsatz von einfachen Betriebssystemen auf dem AVR<br />
* Übersicht zu den C bzw. GCC-predefined Makros (__DATE__, __TIME__,...)<br />
* ADC ; <br />
* Timer<br />
* USB ; Steuerung mit USB<br />
* Multiplexen Siebensegment<br />
* Sichere vs. effiziente Serialisierung von Datentypen<br />
* Zustandsautomaten<br />
<br />
<br />
= Softwareentwicklung =<br />
<br />
"Wild drauflos" zu programmieren kann nach einiger Zeit frustrieren, da mehr Zeit erforderlich wird, das Programm neuen Anforderungen anzupassen.<br />
Wer erst etwas Zeit darauf verwendet, ein offenes Konzept (erweiterbare Prodrammstruktur, Algorithmen) zu entwickeln (ggf. in Ruhe mit Papier und Bleistift), wird später schneller ans Ziel gelangen.<br />
<br />
http://de.wikipedia.org/wiki/Softwareentwicklung<br />
<br />
= Programmierstil =<br />
<br />
Damit ein größeres Programm (nach längerer Zeit) überschaubar bleibt, sollte man sich bei der Gliederung, Namensgebung, Formatierung und Kommentierung an bewährten, begründeten Konzepten orientieren.<br />
<br />
http://www.mikrocontroller.net/topic/130218<br />
<br />
http://www.elektroniknet.de/home/embeddedsystems/fachwissen/uebersicht/software/entwicklungssoftware/der-programmierstandard-misra/<br />
<br />
http://www.mikrocontroller.net/topic/132304<br />
<br />
http://de.wikipedia.org/wiki/Programmierstil<br />
<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]<br />
[[Kategorie:AVR]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=Reichelt-Wishlist&diff=36349
Reichelt-Wishlist
2009-05-27T21:44:06Z
<p>Leo1969: /* Baugruppen */</p>
<hr />
<div>== Reichelt Wunschliste ==<br />
<br />
Auf dieser Seite können Wünsche zur Erweiterung des Reichelt-Lieferprogramms eingetragen werden. Es ist keine offizelle Wunschliste von Reichelt und es ist nicht bekannt, ob Reichelt-Mitarbeiter diese Seite regelmässig sichten. Reichelt sollte sicherheitshalber regelmäßig angeschrieben werden, damit diese Liste nicht in Vergessenheit gerät.<br />
<br />
Damit sich die beliebtesten Artikel herauskristallisieren, macht jeder einfach '''einen''' virtuellen Strich dahinter: | (Windows: ALT-GR Taste und < Taste drücken, Mac OS X: Alt-Taste und 7 Taste drücken). Alle fünf Striche (|||||) bitte immer ein Leerzeichen einfügen.<br />
<br />
Neue Artikel einfügen darf und soll natürlich auch jeder - aber bitte die Liste vorher durchgehen (Tipp: Browser-Suchfunktion nutzen)! Einfach ganz viele Striche auf einmal hinter einem Artikel einzufügen ist zwecklos. Das erkennt man in der History und es gibt viele Leute, die diese Seite überwachen...<br />
<br />
'''Nicht sinnvoll''' ist etwas sehr exotisches, wie z.B. einen ganz bestimmten super schnellen AD-Wandler hier aufzulisten! Neue Artikel müssen sich für Reichelt ja auch rentieren und wirtschaftlich "an den Mann bringbar" sein. [Die Entscheidung, ob sich was rentiert und ob es exotisch ist, sollte man vielleicht Reichelt und den eventuellen späteren Strichle-Setzern überlassen, statt im Voraus die Schere im Kopf walten zu lassen.]<br />
<br />
= Wunschliste =<br />
== Halbleiter ==<br />
=== Controller/FPGA/CPLD ===<br />
<br />
* ALTERA MAX-II (CPLDs) ||||| ||||| ||||<br />
* ALTERA CPLD EPM30xx - Familie ||<br />
* ALTERA CPLD EPM70xx - Familie ||||| ||||| ||||| ||||| |<br />
* ALTERA Flex10K - Familie ||||<br />
* ALTERA Cyclone2 - Familie ||||| ||||| ||||| ||||| |<br />
* ALTERA Cyclone3 - Familie |||||<br />
* Atmel AVR32 im TQFP ||||| ||||| ||||<br />
* Atmel AVR mit USB AT90USB82, AT90USB162, AT90USB646, AT90USB1286 und AT90USB1287 ||||| ||||| ||||| ||||| |<br />
* Atmel ATA6612/13 (LIN-Bus SoC) ||<br />
* Atmel ATtiny261 (auch 461 und 861; bevorzugt DIP) ||||| ||||| <br />
* Atmel ATtiny2313V in SO und PDIP ||<br />
* Atmel Atmega 16A und 32A in TQFP und PDIP ||||||||||||||||||||||||||||<br />
* Atmel Atmega 16L und 32L in TQFP (waere ATMEGA 16/32L8 TQ) ||||| | <br />
* Atmel ATmega324P in TQFP und PDIP ||||| ||||| |<br />
* Atmel ATmega324PV in TQFP und PDIP ||<br />
* Atmel ATmega328P in TQFP und PDIP ||||| ||||| ||||| ||||| ||||| |||<br />
* Atmel ATmega48P in TQFP und PDIP |<br />
* Atmel ATmega644p in TQFP und PDIP |||||| ||||| ||<br />
* Atmel ATmega1284P in TQFP und PDIP |<br />
* Atmel AVR Controller mit Funkanbindung z.B. AT86RF230, AT86RF211, AT86RF401, dazu passende Quarze (evtl. SMD) 18,080 MHz (Crystek P/N 016758), Spulen 39nH. ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* Atmel AT90PWM3B (µC für Servosteuerungen und z.b. Motorsteuerungen) ||||| ||||| ||||| ||||<br />
* Atmel AT89LP4052 PDIP ||||| ||||| |<br />
* Atmel AT89S2051/4051 ||||<br />
* Atmel Dream Sound Synthesizer Chips, z.B. ATSAM3103 und ATSAM3308 ||||| ||||<br />
* Axis Etrax 100LX Risc Processor (kostenloses Linux-System vorhanden) |||||||| <br />
* Freescale Prozessoren (Coldfire) (16 + 32 Bit) ||||<br />
* Freescale DSP56F801 ||||<br />
* Freescale HCS12 Controller ||||| ||||| ||||| ||||| ||<br />
* Freescale MC9S08QG8 (DIP 16) ||||| ||||| |||<br />
* Freescale MC9S08QEx |<br />
* Infineon XC866 ||||| ||||| ||||| ||||| ||<br />
* Lattice ispMACH 4032C / 4064C / 4128C ||||<br />
* Lattice GAL 26V12 |<br />
* Luminarymicro Stellaris Serie (Cortex-M3) ||<br />
* Microchip PIC 10F2xx (+ Programmiergerät) |||| ||||| ||||| |||<br />
* Microchip PIC 16F883 und 16F886 ||<br />
* Microchip PIC 18F2585 |||<br />
* Microchip PIC 18F4523 (12/2007: PIC mit 12-Bit A/D-Wandler) |<br />
* Microchip PIC 18F4550 (PIC mit USB) ||||| ||||| |||| ||||| ||||| ||||| |||<br />
* Microchip PIC 18F6585<br />
* Microchip PIC 24 ||||| ||||| ||||| |||||<br />
* Microchip mehr dsPIC30F ||||| ||||| |<br />
* Microchip dsPIC33 ||||| ||||| |<br />
* Microchip PIC32 (MIPS) ||||| ||||| ||||<br />
* NXP LPC214x-Serie ARM7-Controller ||||| ||||| |<br />
* NXP LPC23xx/24xx ||||<br />
* NXP SAA5281 Videotextinterface ||||| |||<br />
* Maxim/Dallas DS89C450 |<br />
* Parallax Propeller CPU, 8 Cogs - DIP 40 ||||| ||||| ||||| ||||| ||||<br />
* Renesas M16C ||||||||<br />
* Silabs C8051F320 USB Mikrocontroller ||<br />
* SSV DIL/NetPCs [http://www.dilnetpc.com]http://www.dilnetpc.com ||||| ||||| |||<br />
* ST ST7MC... (µC für Servosteuerungen, und vor allem Brushless-Motoren) ||||| ||<br />
* ST STR7 Serie (ARM7TDMI) |<br />
* ST STM32 Serie (Cortex-M3) ||||| ||<br />
* TI TMS470 Arm7 ||||| |||| ||||| ||||| |<br />
* TI MSP430F167, TI MSP430F168 ||||<br />
* TI MSP430F2001/2/3 etc. im RSA-Gehäuse (=QFN) ||||| ||<br />
* TI MSP430FG4618 |<br />
* TI MSP430F2618 |||<br />
* TI TUSB3210 ||||| ||<br />
* Ubicom SX20 SX28 IP2022 ||<br />
* Zilog Z8 Encore-Microcontroller (bis 64k Flash, I²C, SPI, 2xUART, ADC, on-Chip Debugger ...) [http://www.zilog.com/products/family.asp?fam=225]www.zilog.com ||||| |<br />
* Zilog ZNEO-Microcontroller (Z16Fxxx, bis 128k Flash, 4k RAM, bis zu 76 I/Os, 3 Timer, 10-bit A/D, externer Daten-/Adressbus, on-Chip Debugger) [http://www.zilog.com/products/family.asp?fam=236] www.zilog.com |<br />
* CY7C68013A-56PVXC (Cypress EZ-USB FX2LP) ||||<br />
* XC3S 400 TQ144 |||<br />
* Mehr FPGAs (v.a aktuellere) von Xilinx, z.B. Spartan III , ALTERA CYCLONE II (v.a. auch größere Typen, die noch im TQFP-Gehäuse zu haben sind wie z.B. XC3S400 oder XC3S500E (PQFP208)) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* Ajile aj-100 (Java Real-Time Prozessor) ||<br />
* Western Design Center 65c816 ||<br />
<br />
=== Speicher ===<br />
* Atmel DataFlash, z.B. AT45DB081B (8 MBit Flash-Speicher an seriellen Bus im 8poligen Gehäuse) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* NexFlash spiFlash NX25P16 (16MBit serial Flash im SO8-Gehäuse) ||||| ||||| |||||||<br />
* Schnelles RAM (10, 15 oder 20ns, z.B. Samsung K6R1008C1D-UI10) (5V/3,3V) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* RAMs (SRAM oder DRAM) mit ordentlicher Kapazität (z.B. HY57V641620HG oder besser) ||||| ||||| |||||<br />
* 3.3V DRAM |||||<br />
* 3.3V async SRAM ab 16KByte |||||<br />
* 24LC256 oder 24AA256 oder 24LC512 oder 24AA512 ||||| |||||<br />
* FPGA Konfigurations-EEPROMS AT17LV256, AT17C65/128/256.../XCF04S/... ||||| ||||| |<br />
* EEPROM mit SPI Schnittstelle 25XX Serien ||||| ||<br />
* F-RAM mit SPI von RAMTRON ||||<br />
<br />
=== ICs ===<br />
* Max1555 - LiPo Lade IC |<br />
* Bosch CJ125 |||||<br />
* VN808 Low Treshold Octal High Side Driver 0,7A |<br />
* National Semiconductor CLC020 und CLC021 Parallel Component nach SDI-Converter |||||<br />
* Ethernet-Controller RTL8019AS und Übertrager FB2022 oder 20F-001N ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||| |||<br />
* Ethernet-Controller CS8900A ||||| |||<br />
* Fast Ethernet-Controller (DE9000A/B/E, AX88796B, ...) |<br />
* SPI-Ethernet-Controller ENC28J60 und passender Übertrager und passenden '''Grundton'''-Quarz (25,0000 MHz Grundton) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* DP83848C (Ethernet Physical Layer Transceiver/PHY, MII/RMII-Schnittstelle, passend zu AT91SAM7X) |||<br />
* Ethernet-Connector RJ-45 mit integriertem Übertrager (z.B. Taimag RJLBC-060TC1) ||||| ||||| |||||<br />
* ADS8320 ADC 16 Bit seriell ||||| ||||| ||||| ||||| ||||| ||||<br />
* DAC7612 DAC 12 Bit seriell ||||| ||||| ||||| ||||| ||<br />
* DTMF-Dekoder-Enkoder (8870, 8880) ||||| ||||| ||||| ||||| |||||<br />
* AD7524 in SMD ||||| |||| |||||<br />
* MCP23016 16Bit I²C I/O Expander ||||| ||||| ||<br />
* ISD 5116 (Sprachaufnahme bis 16min & I2C-Interface) ||||| ||||| |||||<br />
* I²C-Bus Temperatursensor DS1631Z ||||| ||||| ||||| |||<br />
* RS485 isoliert: z.B. Burr-Brown ISO485 o.ä. |||||<br />
* Maxim MAX629, MAX1795, MAX1703 (Aufwärtsregler / Step-Up-Konverter) ||||| |||| ||||| |<br />
* DAC8830 IDT (16Bit-DAC,ser. Input) ||||| |<br />
* MAX6958 / MAX6959 (I²C 4-Digit, 9-Segment LED Display Drivers with Keyscan) |||| ||||<br />
* LM3886 ||||| |<br />
* Leistungs-OP LM675 von National ||<br />
* ZHB6718 (H-Bridge für 1,5V - 20V Motoren) |||| |||||<br />
* Philips PCA82C252 oder TJA1054A oder vergleichbar ("Fault-Tolerant" CAN Transceiver, 11898-3) ||||| |||| <br />
* Maxim Switched Capacitor Tiefpass-Filter (z.B. MAX297, MAX7410) |||||<br />
* Philips PCA9555 (I2C IO, 16 Bit par. I/O, c't Project Soundcheck II) ||||<br />
* ISD 2560 -> SOIC Gehäuse (Sprachaufnahme IC) ||||| |<br />
* MCP25050 CAN-Bus Input/Output Expander ||||| ||||<br />
* STP08CL596M SO16 STM, LOW VOLTAGE 8-BIT CONSTANT CURRENT LED SINK DRIVER ||||<br />
* STP16CL596M SO24 STM, LOW VOLTAGE 8-BIT CONSTANT CURRENT LED SINK DRIVER |||<br />
* STP16CL596B1R DIP24 STM, LOW VOLTAGE 16-BIT CONSTANT CURRENT LED SINK DRIVER ||<br />
* STP08CL596B1 DIP16 STM, LOW VOLTAGE 8-BIT CONSTANT CURRENT LED SINK DRIVER ||<br />
* MAX6675 Typ-K Thermoelement nach SPI ||||| ||||| ||||| ||<br />
* Motortreiber TLE 4205 |||<br />
* LTC24xx |||<br />
* MAX6650 ||<br />
* QT511-ISSG (iPod-like Touch-Wheel-Sensor ''siehe'' [http://www.qprox.com/products/qwheel_qt510.php]) ||||| ||||<br />
* DDS-IC von Analog wie AD9833, AD9835 ||||| ||||| ||||| ||||| ||||| |||<br />
* IP101 PHY von IC+ (Distri für DE [http://www.topas.de/tt/cfs/icp_cfs_mai05.htm Topas]) ||<br />
* UDN 2987 LW (Source Driver UDN2987 in SMD-Bauform) ||<br />
* MAX7311AWG 2Wire Interface von Maxim ||<br />
* IR2011 MOSFET Treiber |||<br />
* IR21844 DIL |||<br />
* MAX 4420 Mosfet Driver ||<br />
* MAX 4429 Mosfet Driver ||<br />
* MC 34152 D-SMD SO8 Dual Mosfet Driver |<br />
* CCS-Akkulade-IC (z.B. CCS9620SL) (siehe [[http://bticcs.com/]]) |||||<br />
* LM1117MPX-1.8 und LM1117MPX-3.3 (SMD-Spannungsregler SOT-223) |||||<br />
* LTC1694-1 (I2C/SMBus Accelerator) ||||<br />
* P82B86 (I2C Dual Bi-Directional Bus Buffer) ||<br />
* CS5641 von Cirrus...The CS5461 incl. two delta-sigma A/D converters.... ||<br />
* DS1616 von Dallas Datalogger-IC |<br />
* TEA5757 FM-Tuner IC von Philips |||<br />
* TEA5768HL FM-Tuner IC von Philips |||||<br />
* VS1000 Ogg Decoder von VLSI |<br />
* VS1053 MP3/AAC/WMA/Ogg Decoder von VLSI ||||| ||<br />
* TH3122 K-Line Interface von MELEXIS ||||<br />
* MAX7313 16 LED-PWM-Dimmer (Im gegensatz zu den Philips-ICs ist jede einzelne LED-Dimmbar, dafür nur in 16 Schritten) ||||| |||| <br />
* LMX2306/LMX2316/LMX2326 PLL Synthesizer von National ||||| |<br />
* MAX127/128 8-Kanal 12bit ADC mit I2C interface |||<br />
* MIC6315 von Micrel (3,3/5V Reset Baustein mit manual Reset) ||<br />
* MMI4832 (Geber Interface Baustein EnDat, SSI, Incrementalgeber |||<br />
* CP2120 single-chip SPI to I2C bridge and GPIO port expander |<br />
* AD623 Single Supply,Rail-Rail, InstrOpamp ||||||<br />
* AD628 InstrOpAmp, high voltage inputs |<br />
* L6205 Motortreiber (2Kanal, 2,8A, DMOS)|||||<br />
* TLV27(2|4) superbilliger Rail-Rail-OP mit (3 MHZ|2.4V/µS|550µA supply) von TI ||<br />
* TLV2382ID Rail-Rail-OP von TI |<br />
* TLV320AIC23B Audio-Codec ||<br />
* Cypress CY7C67300 dual role USB controller mit OTG |||||| ||||| ||||| ||||| ||<br />
* High Side Current Sense ICs wie MAX4172 ||||||<br />
* LM397, LM321 o.ä. single op-amp in SOT23-5 5-30V supply ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||<br />
* LTC3490 ||||| ||||<br />
* QT160 6-fach Touch Sensor IC |||<br />
* TPIC6B595 (oder ähnliche 74xx595 high current (150 mA) shift register) ||||<br />
* HV9910 Schaltregler für die Hochleistungs LED^s Ub=8-450V; I beliebig; Eff. besser 90% |||||||||||||||||||||||||||||||<br />
* LM267X SimpleSwitcher Step-Down-Konverter in SO-8 Bauform |<br />
* Schnellere und gleichzeitig günstige OpAmps; Beispiel AD8055 ||<br />
<!-- "zum Beispiel" --><br />
* Clock generator IC's, z.B. PCK20?? von Philips |<br />
* uC supervisor chips + watchdog z.B.: MAX6864 ist z.Z. der beste (0.2uA!) |||<br />
* Mehr FET-Treiber (TI UCC3372x, HIPxxx , die neueren Brückentreiber von Maxim ||||| |<br />
* D/A Wandler mit 4 oder mehr Ausgängen, z.B. TLC5620/TLV5629/AD5325 ||||| ||||| ||<br />
* PLL Schaltkreise für Frequenzerzeugung. z.B. MC / ML145170 (SOIC16) / TSA5060A ||||| ||||| |||||<br />
* Digital Potentiometer (z.B. 2-Wire MAX546x, AD526x, X9C10x) ||||| ||||| ||||| ||||| |||||<br />
* Power over Ethernet Bausteine z.B. LM7050 <br />
* Automotiv ICs z.B. LM1815, LM1915, LM1949, LM9011, LM9040, LM9044, LMD18400... ||||| |<br />
* 16-bit A/D-Wandler (waren von Maxim schon im Programm, sind aber wieder herausgeflogen?) ||||<br />
* Video-AD-Wandler z.B. LTC2208 (16 Bit 130 MS/s) für FPGA und SDR |<br />
*MAX528 8-fach 8Bit DAC mit Output Buffer seriell |<br />
*LM1117 - 3,3V SOT-223 ||<br />
*LTC 1655(L) N8 16 Bit DAC interne Ref 2.048/1.25V(L Type) SPI Interface |<br />
*LTC 1661 N8 10 Bit Dual Dac mit SPI Interface |<br />
*74HCxxxx komplette Serie |<br />
*Philips TDA1543 - 2x16-Bit DAC |<br />
*LTC 4411 ideale Diode 2,6 bis 5,5V max. 2,6A im SOT-23 Gehäuse <br />
*FTDI High Speed Chips, z.B. FT2232H ||<br />
<br />
<!-- "mehr" xyz / unspezifisch --><br />
* Ethernet Magnetics (Auch POE) ||||| |||<br />
* Generell mehr DAC's (auch die teureren) von TI |||||<br />
* Generell mehr I2S IC (ADC, DAC, DSP, u.a. Crystal, BurrBrown etc.) |||<br />
* Generell mehr I²C IC ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* Generell mehr 1-Wire IC ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* Generell mehr PWM-SIC's ||||<br />
* Generell mehr SPI IC ||||| ||||| ||||| |||| (viele µC haben SPI aber kein I2C )<br />
* 74VHC-Serie komplettieren (z.B. 74VHC125D) ||||| |<br />
* MagJacks ||<br />
* TI PCM2707 ||<br />
* TI PCM1804|||<br />
<br />
=== Diskrete ===<br />
* MAX 8865 Dual, Low-Dropout, 100mA Linear Regulator |<br />
* LM317EMP oder LM317AEMP SMD-Spannungsregler einstellbar (SMD TO-223 Gehäuse) ||||| ||||| |||<br />
* L4941 Spannungsregler 5V/1A in SMD-Ausführung (DPAK) ||||| |||<br />
* LM2734 Schaltregler |||<br />
* MIC29300/29301 Spannungsregler 5,0V 3A im TO263(SMD) Gehäuse ||<br />
* MC78LCxx Serie - Ultra Low Drop Spannungsregler 3-5 Volt mit 1 Mikro-Ampere Ruhestrom ||||| ||<br />
* R-783.3-0.5 Schaltregler 4,75V - ca. 18V Eingang; 3,3V Ausgang (Hersteller Recom) ||||| ||<br />
* R-785.0-0.5 Schaltregler 6,5V - 30V Eingang; 5,0V Ausgang (Hersteller Recom) |||||| <br />
* R-785.0-1.0 Schaltregler, Ausgang 5,0V, 1A |<br />
* ZRA250F005 Referenzspanungsquelle 2,5V 0.5% SOT23 gehäuse ||||| |||| <br />
* Größere Auswahl an Step-up Reglern ||||| ||||| ||||| ||||| |||<br />
* 5,2V Lowdrop Längsregler LF52 im TO252AA von STM ||||| <br />
* Spannungsregler SMD in DPAK ||||| ||||| ||||| ||<br />
<br />
* IPW60R045CS Infineon Mosfet 600V 45mOhm Rdson 30ns tr+tf (niedrigster Rdson in der Klasse) |<br />
* SPP20N60C3 Infineon Mosfet 600V 190mOhm Rdson <10ns tr+tf (Schnellste Schaltzeit in der Klasse) ||||| |<br />
* SDT06S60 Infineon SiC 600V 6A Silizium-Carbid Schottky-Diode (kein trr, daher keine Schaltverluste) |||<br />
* mehr FETs und IGBTs (nichtnur IRF, sehr gut IXYS <- und sauteuer!) ||||| |||<br />
* Digitaltransistoren (BCR*), auch als Pärchen NPN/PNP (BCR10, BCR08pn) ||||| ||||<br />
* Niederohm-FETs in SO8, N und P ||||| |||||<br />
* Si4562DY N- and P-Channel 2.5-V (G-S) MOSFET SMD ||||| ||||| | <br />
* IRF7503/IRF7506 Dual Mosfet SMD ||||| ||||<br />
* PhotoMOS Relay (z.B. AQV257 von Panasonic; http://www.mew.co.jp/ac/e/control/relay/photomos/index.jsp) |<br />
* IPS5451S intelligenter Leistungsschalter 50 V, 35 A, 25 mΩ |<br />
* BSH205 P-Channel 1.5V(GS), 0.75A, 12V D-S |<br />
* SMD Doppeldiode Schottky 12A 60V im TO252AA z.B. 12CWQ06FN von IOR ||||| ||||| ||||| | <br />
* IR3313 o.ä. Intelligenter Leistungsschalter 32V/90A, einstellbare Strombegrenzung |<br />
<br />
* BUF420AW Schaltnetzteil Transistor von STM ||||| <br />
* Philips PDTD113E/123E und PDTB113E/123E (PNP und NPN im sot23 mit internen Widerständen für Basis und PullUp/Down ||<br />
* 2SC1971 Transistor mit hoher Frequenz und viel Leistung für Endstufen |<br />
* Hochspannuns-Widerstände (z.B. 330M/10kV) |<br />
<br />
== Sensoren/Aktoren ==<br />
* Sensirion SHT11/SHT71 (oder auch SHT15/SHT75) ||||| ||||| ||||| ||||| ||||| ||||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||<br />
* Sharp Entfernungssensoren (zb den GP2D120 oder den GP2D12) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* kleine Feuchtigkeitssensoren zur 'on-board-Montage' ||||| ||||| ||||| ||||| |<br />
* IS471 Selbstmodulierende IR-Lichtschranke ||||| ||||| ||||| ||||| |||<br />
* FSRs (Force Sensing Resistor) von Interlink Electronics ||||| ||||| ||<br />
* Drehwinkelgeber, Gyro, Kreiselsensoren ähnl. Tokin CG-L43 ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* Summer mit 20mA@5V ähnlich Conrad Nr.751553 (TDB05 kann mit 30mA@5V nicht von allen Controllern direkt getrieben werden) ||||| ||||<br />
* NanoMuscle Aktuatoren ||||| |||||<br />
* Flexinol ||||| |<br />
* Hall-Sensor UGN3503, KMZ51 ||||| ||||| |||<br />
* Magnetfeld-Sensor (Kompass-Anwendung) KMZ52 |||||<br />
* günstige Temp. Sensoren TC77 ||||| ||||| ||<br />
* Motorola/Freescale Drucksensoren z.b. MPX4250 mit AP Druckanschluss ||||| ||||| ||||| ||||| |||||<br />
* K-Typ (J-Typ) Thermocouple Temperatursensoren und passende Steckverbinder ||||| ||||| |<br />
* Induktions-Stromsensoren Coilcraft #J9199-A o.ä. ||||<br />
* Durchflussmesser (z.B. wie Conrad Nr.155374) ||||| ||||| |<br />
* Linear- und 360° Soft-Pots wie von spectrasymbol ||||<br />
* iMEMs Acceleration Sensors ADXL Series von Analog Devices ||||| ||||| |||||<br />
* LEM Stromsensoren (Transducer) der HAIS-Serie, speziell HAIS 50-P und 100-P ||||| ||||| |<br />
* Allegro Stromsensoren (z.B. ACS713, ACS756) ||<br />
* 4Hz Supersense µblox LEA-4S GPS module (Importer pointis.de) + Passende Passives Patch antenna (zB. von inpaq.com) ||||| ||<br />
* Hallsensoren z.B. TLE4905 wieder ins Programm nehmen ||<br />
* Anemometer ||<br />
* Piezo Minimotoren/Lienearaktoren von Elliptec/Siemens einzeln und günstig |||<br />
*Temperatursensor mit SPI-Interface LM74 ||<br />
* Temperatur IC TC1047 ||<br />
<br />
== Baugruppen ==<br />
* Atmel ATNGW100 von [http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=AVR32NGKit_3_26.html Atmel] = billiges Linux Board ($69=51.69€) --> [http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/NGW100_Hardware_reference Dokumentation] ||||| ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* Atmel ATSTK600 von [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4254 Atmel] |||<br />
* Atmel ATSTK1000 von [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918 Atmel] ||||| ||||| ||||| ||||<br />
* Atmel AVR Dragon von [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 Atmel] ||||| ||||| ||||| ||||| ||<br />
* Axis Etrax 100LX MCM (Multi Chip Module) A full Linux computer on a single chip! ||||| |||||<br />
* CentiPad/DevKit Embedded Linux Modul ([http://www.centipad.de www.centipad.com]) ||||| ||<br />
* DS9490R USB zu 1-Wire Dongle (auch mit Linux Treiber) |||||<br />
* Easy-Radio Module zur seriellen Datenübertragung (ER400 RS/TS/RTS) ||||| ||||| ||||| |<br />
* Foxboard = Betriebsfertiges Micro Linux System mit Axis Etrax 100LX MCM 66mm x 72mm ||||| ||||| ||||| ||||| |<br />
* FoxVHDL = FPGA Erweiterungskarte für das ACME Foxboard ||||<br />
* Hope RF Module 433 u. 868 MHz, http://www.hoperf.com/pdf/RF12.pdf ||<br />
* kostengünstige Funkschaltmodule (TLP/RLP) ||||| ||||| ||||| ||<br />
* kostengünstige Funkempfänger/Funksender 433 & 868 Mhz ||||| ||||| ||||| ||||| ||||| ||||| ||||<br />
* Lantronix XPort Embedded Device Server ([http://www.lantronix.com www.lantronix.com]) ||||| ||||||<br />
* Lantronix XPort Direct ||<br />
* low-cost Experimentierplatinen für FPGA ||||| ||||| ||||| |<br />
* Mini-Bluetooth Module (RS232-Bluetooth-"Wandler"-Platinchen) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||| ||||| |<br />
* Mini-WLan Module (RS232 zu WLan) ||||| ||||| |||||<br />
* MT1390 FM Tuner-Modul von Microtune |||<br />
* NetDCU8 von F & S Elektronik Systeme GmbH (http://www.fs-net.de) - Linux-Computerplatine mit 400MHz Samsung-ARM mit 32MB RAM, 16MB Flash und SD/Ethernet/CAN/USB/TFT/RS232 für ca. 100 Euro ||||| ||||| ||<br />
* OM5610 FM Tuner-Matchbox von Philips |||<br />
* TI - MSP430 Wireless Development Tool (AEC13895U) |<br />
* Gyro Sensoren MURATA, ENC-03J A/B ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* UM232 FTDI USB - RS232 Modul für DIL sockel |<br />
<br />
== "Passive" Bauteile ==<br />
<br />
=== Spulen etc. ===<br />
* Ordentliche Trafospulen + Kerne, z.b. ETD-Serie, oder RM10 ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* Passende Ferrite dazu: N27,N41,N67,N87,N97 ||||| ||||| ||||| ||||| ||<br />
* Magnetics CoolMu Ringkerne ||||| |||||||<br />
* Magnetics MPP Ringkerne ||||| ||||| ||<br />
* Die Micrometals Pulverkerne (-18 und -26) auch in größer ||||| |<br />
* Funk-Entstördrosseln 16A, div. Werte ||||| ||||<br />
* Funk-Entstördrosseln 47µF |||<br />
* Würth Induktivitäten ||||| ||||| ||||| |||<br />
* Übertrager für Schaltregler z.B. Epcos Typ B78304 ||||| |<br />
* SEPIC-Speicherdrosseln von Würth WE-DD (Größe M u. L) |<br />
* Sortimentskästen von Würth |<br />
<br />
=== Kondensatoren ===<br />
* Low-ESR Elkos (definiertes Fabrikat/Typ, und nicht einfach irgendwelche! (Rubycon?)) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||| ||||| ||||| ||||| ||||| ||||| ||||| ||<br />
* Low-ESR Elkos RM 3,5mm 1.000uF 6,3V (Mainboardaustausch Elko) ||<br />
* Low-ESR SMD Tantal-Elkos (definiertes Fabrikat/Typ, und nicht einfach irgendwelche! (AVX?, Epcos?)) ||||| ||||| ||||| ||||| |||<br />
* Zum MAX232 so20 passende SMD-Kerkos im Wert 1uF (0805,0603, 1206) ||||| ||||| ||||| ||||<br />
* Generell SMD-Kerkos im Wert > 100nF ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* Kleine Niedervolt-Polyproplyenkondis mit mehr Kapazität ||<br />
* Wima MKP4 ||||<br />
* Wima MKP-X2 (~275V, klein und ideal für Kondensatornetzteile) |<br />
* Günstige hochkapazitive Doppelschichtkondensatoren (z.B. Maxfarad MES2245 220F 2,3V) ||||<br />
* Keramikkond. SMD 0603/0805/1206: mehr Zwischenwerte (56p, 82p, 560p) ||||| |<br />
* Drehkondensator 20-500pf ||<br />
* Sanyo OS-Con bedrahtet und SMD ||<br />
<br />
=== Widerstände ===<br />
* SMD-Widerstande in Bauform 0603 0402 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||<br />
* SMD-Widerstände 0805 und 1206 auch unterhalb von 1 Ohm ||||| ||||| ||||| ||||| || <br />
* SMD-Widerstände unterhalb 1 Ohm, andere Gehäuse als 0805/1206 (leichter erfüllbarer Wunsch) ||||| ||||<br />
* SMD-Widerstände 0805 auch aus der E24-Reihe ||||| ||||| ||||| ||<br />
* Durchsteck-Widerstände in kleiner Bauform 0204. ||||| |||||<br />
* R2R-Widerstandsnetzwerke (z. B. 10/20kOhm für DA-Wandler an Microcontrollern) ||||| ||||| ||||| ||||| ||||| ||||| ||||<br />
* Präzisionswiderstände 0,05% und besser, ev. Drahtgewickelt ||||| ||||| |||||<br />
* Niederohm-Widerstände (Shunts ab 1mOhm im guten Gehäuse z.B. TO220) ||||| ||||| ||||| ||||| ||||| |||||<br />
* 25/50W-Widerstände (~20/50 Ohm auch weniger) ||||| ||||| ||||<br />
* Präzisions-Spannunsgteilernetzwerke ||||| ||||<br />
*Präzisionsspannungsteiler 1:10, 1:100, 1:1000 (10MOhm Gesamtwiderstand) ||<br />
* SMD-Präzisionswiderstände (0,1% TC10ppm/K =>0,1W indukt.arm) ||||| ||||| ||||| |<br />
* Null-Ohm Widerstände (Drahtbrücken) Baugröße wie 1/4W |||||<br />
<br />
=== Quarze, Quarzoszillatoren und Resonatoren ===<br />
* SMD-Quarze mit Standardgehäuse (z.B. HC49/US & HC49/UP) ||||| |||<br />
* Quarzoszillator 9,8304 Mhz ||<br />
* Quarz mit 3,200 Mhz |<br />
* 13,5600 MHz Quarz (benötigt für RFID) ||||<br />
* Quarz mit 13,56 MHz (SMD+bedrahtet) ||<br />
* 24,0000 MHz Standardquarz Grundton ('''kein 3. Oberton!!!''') (benötigt für USB-DMX-Interface) |||||<br />
* 25,0000 Mhz '''Grundton'''-Quarz (wird benötigt für Microchip TCP/IP Controller ENC28J60) ||||| |||||<br />
* Allgemein mehr Grundtonquarze bei höheren Frequenzen |<br />
* SMD Quarze/ Oszillatoren in flachen, kleinen SMD Gehäusen (SMX-A/-B) |||<br />
* Murata Keramik-Resonator CSTLS16M0X, CSTLS20M0X (obwohl 3. OW, direkt mit µC verwendbar)<br />
<br />
=== Sonstiges ===<br />
* Varistoren 14V auch als bedrahtetes Bauteil (für KFZ-Bordnetz) ||||| ||||<br />
* Suppressordioden mit Spannungsbereich zwischen 15V und 30V ||<br />
* die Auswahl läßt hier sehr stark nach<br />
* Netzfilter FFP Reihe Schurter ||<br />
* Metallbrückengleichrichter für 50A ||<br />
* Lieferungen nach Österreich ohne 150 Euro Mindestbestellwert wie alle anderen Supplier<br />
<br />
== HF Baumaterialien ==<br />
* Filter SFE10.7MA19 360khz SZP2026 |<br />
* Keramische Filter CFM455... ganzes Sortiment |||<br />
* Quarze 32 MHz 10ppm Oscillatorfrequenz 0 bis +70°C<br />
* Quarze 6,500000 MHz ||<br />
* MC68160FB<br />
* S3C4510B<br />
* MT48LC4M32B2TG-7<br />
* MC68EN302PV20<br />
* Zirkulatoren ALD4302SB statt LM239 <br />
* Transistoren MRFG35010 |<br />
* µP Compatible CTCSS Encoder,Decoder FX 365<br />
* Durchführungskondensatoren 1nF/160V (waren Ende '06 noch im Programm) |||<br />
* ZF-Quarzfilter für versch. Frequenzen (10, 20, 40 MHz) |<br />
* MMICs und Ringmischer von Mini-Circuits<br />
* PLL ICs z.B. von NXP und National für HF-UHF ||<br />
* MICRF002/022, MICRF102/103 von Micrel |||||<br />
<br />
== Optoelektronik und Leuchtmittel ==<br />
* TFT/OLED Farb-Displays, wie die bereits abgekündigten OSRAM OLEDs ||<br />
* low current SMD LEDs (z.B. Osram LG T679 - Anm.: hier gleich die neuen Varianten Lx T67K bestellen, nicht die alten 9er) ||||| ||||| ||||| ||||<br />
* SMD LED Bauform 0402 rot/gelb/grün/blau/weiss ||||| ||||| ||||| ||||<br />
* weisse SMD LED Bauform 0603 ||||| ||||| ||||<br />
* warm weisse LED ||||| ||||| ||||| |<br />
* OSRAM Hyper TOPLEDS weiss LW T67C-T2U2-5K8L ||<br />
* OSRAM Halogen Decostar 51 12V 20W GU5,3 statt des billigen NoName Zeugs ||<br />
* OSRAM Hyper TOPLEDS gelb LY T676-S1T1-26 ||<br />
* Everlight SMD-RGB (fullcolor) 19-337/R6GHBHC-A01/2T ||||<br />
* Superflux RGB LED |<br />
* 7-Segment-Anzeige, allgemein Low-Current bzw. High Efficiency Versionen anbieten ||||| |||<br />
* 7-Segment-Anzeige, blau, gem. Anode ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||||<br />
* 7-Segment-Anzeige, weiss, gem. Kathode ||||| ||||| ||||| |||||<br />
* 7-Segment-Anzeige, weiss, gem. Anode ||||| ||||| ||||| ||||| ||||| |<br />
* 7-Segment-Anzeige, blau, gem. Kathode ||||| ||||| ||||| ||||| ||||<br />
* Diese 4-Stelligen Dot-Matrix LED Anzeigen Siemens SLG 2016 oder von HP oder ähnliches ||||| |<br />
* Generell alle 7-Segment-Anzeigen auch in Blau und bis zu 100mm höhe |<br />
* Vakuum-Fluoreszenz-Displays (Dot Matrix mit Standardcontroller, z.B. Futaba "LCD Emulators") ||||| ||||| |<br />
* IL207AT (SMD Optokoppler von Infineon) ||||| ||<br />
* ILD256T (SMD AC-Optokoppler) ||||| |||||<br />
* ILD620 (DIP Optokoppler) ||||| ||||| ||||| ||||<br />
* SFH6106, SFH6206 4 Pin Optokoppler SMD ||||||<br />
* TLP113 (SMD Optokoppler) |||||<br />
* Vactrol Optokoppler (mit Fotowiderstand zur Analogsignalregelung) |||||<br />
* IR-Diode mit viel power ttp://www.lc-led.com/Catalog/department/36/category/49/1 |<br />
* IrDA-Tranceiver TFDS4500 (oder TFDU4100) wieder anbieten (war im 07/2005er Katalog noch drin) ||||| ||||<br />
* Seoul Zled P4 (100lm bei 350mA, 240lm bei 1A!) ||||| |||||<br />
* Generell: Z-Power LEDs von Seoul (günstiger und heller als Luxeon) ||||| ||<br />
* Seoul Z-LED RGB auf Platine ||<br />
* EA DOG-L128 128x64 Grafikdisplay zzgl Touch-Folie und Beleuchtung |<br />
* TLP 3617<br />
* TSOP 1730 |<br />
* TORX 178<br />
* TSOP98260 (Breitband IR-Empfangsmodul 20-60 KHz) ||<br />
* TSOP98200 (Breitband IR-Empfangsmodul 20-455 Khz) ||<br />
* PC923 (Opto MosFET Gate Treiber auch für High Side) |<br />
* TLP250 (Opto MosFET Gate Treiber auch für High Side)||||<br />
* LED Punktmatrix Anzeigen 8x8 superrot 3mm (z.B. ELM-1883SRWA (Everlight)) |<br />
* Acriche 230V~ LEDs<br />
* Luxeon Rebel weiß (180 lm) auf Star-, Mini- oder normaler Platine |<br />
* BPW 34 F / FS (aus dem Sortiment gefallen) |<br />
<br />
== Mechanisches ==<br />
* Getriebemotoren wie RB35 oder RB40 ||||| |||||<br />
* Muttern M2 |||<br />
* Stopmuttern M2 |<br />
* Zylinderkopfschrauben M2,5 x 12mm |||||<br />
* Zylinderkopfschrauben M2,5 x 20mm |||||<br />
* Zylinderkopfschrauben M2,5 x 30mm |||||<br />
* Zylinderkopfschrauben M3 x 25mm |||||<br />
* Bopla ABP oder ABPH 800-100 (10cm) Aluprofil Gehäuse |<br />
* microSD / Transflash sockel mit push-push technik (ist nervig die immer für teuren versand aus amiland kommen zu lassen) ||||| ||||| ||||| ||||| ||||| |||<br />
* M2 Gewindebohrer und Senker |||<br />
* Kapton-Baender, evtl auch mit Kupferbeschichtung (Flex-PCB) |<br />
* Distanzhülsen/-bolzen M3 in verschiedenen Längen aus Kunststoff |<br />
<br />
=== Schalter/Potis etc. ===<br />
* Drehimpulsgeber DDM Hopt+Schuler 427 SMD (evt auch normal, stehend & liegend) ||||| ||||| ||||| ||||| ||||| |<br />
* Folientastaturen ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| <br />
* Drucktastenfeld Matrix 3x4 ||||| ||||| ||||| ||||||<br />
* kleiner Joystick wie beim Atmel Butterfly ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* statt Radiohm potis bitte Prehostat oder Alphastat 16 63256-026xx ||||| ||||| ||||<br />
* Drehschalter Serie DS in allen Versionen nur vom Hersteller C&K; auch brückende Versionen anbieten ||||| |||||<br />
* bistabile Relais mit 2 Wicklungen ||||| ||||| ||||<br />
* passende Touchpanels für die coolen Blue-Line-Grafikdisplays ||||| ||||<br />
* mehrpolige Fußschalter, FS 35 bitte bei Druckschalter einordnen ||||<br />
* möglichst kleine und flache Druckschalter rastend! ||||<br />
* iPod-Wheel (Siehe: IC's=>QT511-ISSG; siehe 360° Soft-Pots - weiter oben) ||||<br />
* Taster Radiohm ST-1034 in rot, grün, gelb, blau, grau und schwarz<br />
* Leitplastikpotis im Servogehäuse |<br />
* Relais mit hohen Wirkungsgrad (daher nur geringer Spulenstrom nötig) ||<br />
* Tastköpfe für Taster9308, wie zb Omron B32-2000 oder B32-2010 |<br />
* Batteriehalter für 4 Mignonzellen mit Lötfahne (statt Druckknopf) ||<br />
* SMD-Schiebeschalter |||<br />
* Hohlwellen-Drehgeber (z.B. EC35B-Serie von Alps) ||<br />
* Taster und Kappen aus der Multimec-Reihe ||<br />
* Grayhill Series 60A Joysticks mit USB-Adapter |<br />
<br />
=== (Steck-) Verbindungen ===<br />
* Modulare Buchse RJ45 mit Übertrager und LEDs für Ethernet 10/100, z.B. SI-40138 MagJack von BEL-STEWART oder Taimag RJLBC-060TC1 ||||| ||||| |||||<br />
* Modulare Buchse RJ45 (''ohne Übertrager'') mit LEDs (oder Lichtleiter für SMD-LEDs) ||||| ||<br />
* Buchsenleisten zum Crimpen (allseitig anreihbar!, 1x1, 1x2, z.B. [http://www.newproduct.molex.com/datasheet.aspx?ProductID=92125 Molex 2081 ?] oder Harwin M20 ) ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||| ||||| <br />
* Für die LC-Displays: Adapterplatine mit anschlüssen im Raster 2,54mm (EA 9907-DIP) siehe http://www.lcd-module.de/ ||||| ||||| ||||| |||| ||||<br />
* TEXTOOL-Fassungen (Breite 7-15,24mm)/ Nullkraftsockel für kleine Mikrokontroller: DIL-20 ||||| || DIL-28 | PLCC-44 ||||| ||||| ||||| (und andere)<br />
* Nullkraftsockel für SO- oder TQFP-Gehäuse (z.B. Yamaichi) ||||| ||||| ||||| ||<br />
* Nullkraftsockel für 6-Pin SOT23 (SOT23-6) z.B. für Programmierung v. PIC10F |||||<br />
* Nullkraftsockel für DIL20 Gehäuse ||<br />
* Chipkartenkontaktiereinrichtung, die die Kontakte anhebt (keine Schleifkontakte) ||||| ||||<br />
* WOL-Verbindungskabel / Stecker / Print-Connectoren: |||||<br />
* gängige Platinenverbinder einreihig RM 2mm mit 2-15 Kontakten (in vielen Geräten verwendet, z.B. [http://www.newproduct.molex.com/datasheet.aspx?ProductID=19945 Molex 51004, 53015]): ||||| Molex 71226 |||<br />
* Floppy Stromversorgungstecker 3,5" Printausführung ||||| |<br />
* Hochwertigere 1/4" Klinkenbuchsen, z.B. von Rean oder Cliff ||||<br />
* mehrpolige, hochwertige Miniatursteckverbinder (z.B. http://www.binder-connector.de/pdfs/serien/711.pdf) |<br />
* preiswerte! Hochspannungssteckverbinder >2kV ||||<br />
* Höherwertige 3,5mm Klinkenbuchsen / -stecker (statt "EBS35" oder "KK(S/M) ..") ||||| ||<br />
* Ordentliche Lautsprecherbuchsen "Strich-Punkt" (Print oder Wand) (die Stecker sind OK) |<br />
* Schuko-Einbausteckdose (Maschinensteckdose) (mit oder ohne Klappdeckel); Flanschmaß möglichst klein (50mmx50mm); div. Farben (sw,grau,...) ||||| ||||| |<br />
* Euro-Einbausteckdose (230V~, gab's früher mal) ||||| <br />
* Carrier-IC-Sockel<br />
* JST HR Steckverbinder |||<br />
* Wannenstecker(gerade) + Pfostensteckverbinder 6-Pol. (Pfostenbuchsen gibt es 6-Pol.) ||||| ||||| ||||| ||||| ||||| ||||| || ( z.B. Harting SEK 18 Serie http://www.harting.com/en/en/de/sol/verbtech/prod/ios/description/03005/index.de.html)<br />
* Wannenstecker 2,54mm Raster auch als SMD ||||| |<br />
* Günstigere SD/MMC-Steckverbinder z.B.SDBMF-00915B0T2 von MULTICOMP(selbst bei Farnell für 1,80Euro) |||||<br />
* Einpolige Steckerleiste 2.54 ||||| |<br />
* Foliensteckverbinder (FFC) RM1,25 (z.B. 9pol, 11pol ...) |||||<br />
* Triaxstecker /-buchse (Coax mit 2.tem Schirm als 3. Kontakt) |<br />
* vernünftige Koax-Stecker und Kupplungen z. Bsp. von Hirschmann<br />
* Platinensteckverbinder für Rastermass 2,00mm ||||<br />
* Molex Steckerreihe Minifit Jr 4,2mm Rastermaß (verwendet als Stromstecker in Computern, Mainboard, PCI-E, P4/EPS ...) |<br />
* Mini SD Card Connector mit Auswurffunktion für Oberflächenmontage ||||| |<br />
* Steckverbinder für PICTIVA OLED Display Folienkabel |||||<br />
* Leiterplattenbuchse Hirschmann 4mm auch in *rot* (gab es schonmal als "PB 4 RT) ||<br />
* E10-Schraubsockel, wie sie Glühbiren haben, mit Lötstiften (Achtung es ist nicht die Fassung gemeint) ||||<br />
* RP-SMA-Buchse/-Stecker (gewinkelt/gerade) ||<br />
* WAGO 215-4mm-Stecker (Bananenstecker mit Käfigzugklemme) zur schnellen Montage bei Versuchsaufbauten ||||| ||||| ||||| ||<br />
* Die PSK-Kontakte in anderen Packungen als 20/10k.100Stk. wäre z.b. gut.1k auch. |||<br />
* OBD-Stecker. ||<br />
* Adapterprogramm SMA auf SMB ausbauen |<br />
* Micro-USB Steckverbinder ||<br />
* 2.5mm Stereo Klinkenbuchsen (3-polig) SMD ||<br />
* BNC-Stecker (wie UG 88U, Lötmontage) aber für RG174-Kabel ||<br />
* U.FL bzw. IPEX Steckbüchsen zum selbskonfektionieren von HF Kabeln ||<br />
* RJ45-Stecker 90° nach unten oder zur Seite gewinkelt |<br />
* Buchsenleisten einreihig 2,54mm (z.B. BL 1x10G8 2,54) gerade und gewinkelt TEILBAR (so wie die Stiftleisten) |<br />
* Hohlstecker für Laptops 1,7 x 4,75mm gelb |<br />
* Stiftleisten im Rastermaß 1 mm (z.B.: Samtec FTMH-120-03-F-DV-ES) |<br />
* Cablesharing Adapter 2x RJ45-Buchsen(1x Ethernet 1x ISDN)1xStecker |http://www.btr-netcom.com/Products/upload/ATCH-002661.pdf<br />
<br />
=== Kabel etc. ===<br />
* dünner Schaltdraht (< 1mm Durchmesser, isoliert mit Tefzel oder Kynar) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||<br />
* Flachbandkabel im 2,54mm Raster und dazu passende Aufpressstecker und -buchsen ||||| ||||| ||||| ||||| |||||<br />
* versilberten Kupferdraht auch < 0,6mm und alle Stärken in grösserer VPE (z.B. 500g Rolle) ||||||<br />
* Flexible Einzellitze, 0,5² in verschiedenen Farben ||||| ||||| ||||| ||||| |<br />
* bzw. angebotene Schaltlitze (H05VK) um weitere Farben erweitern! |||<br />
* das qualitativ mangelhafte 4mm Laborsteckerprogramm rausnehmen und nur noch Hirschmann anbieten ||||| ||||| ||||| ||<br />
* Zwillingslitze 2x0.14mm, z.B. Artikel: ZL214SWW-10M Kessler Elektronik |||||<br />
* Heizdraht zB.: Kanthal A1 ||<br />
* LYIF Litze (verschiedene Farben) ||||| |<br />
* dickere Mantel(Feuchtraum)leitungen, z.B. NYM J5x10 |<br />
* Folienflachkabel (FFC) RM1,25 (z.B. 9pol, 11pol ... /Länge 20cm) ||<br />
* Flachbandkabel im 1,00mm Raster, passend für Pfostenverbinder PL 2X25G 2,00 . Wird für notebookplatten benötigt. ||||<br />
*Folienflachkabel (FFC) RM 0,8 (z.B. 30pol. Länge125mm) für 8"TFT Monitor<br />
* H155 (HF-Kabel) |||<br />
Low-Loss evtl. aus diesem Programm http://www.elspec.de/hf-kabel-technologie/download-hf-technik/hf-lowloss-kabel.html<br />
* Schnepp "Laborkabel" Messleitungen |||<br />
* Litze, LiY 0,25mm^2, diverse Farben (beispielsweise von Lapp Kabel) |<br />
* Distanzbolzen mit 2 M2,5 Innengewinden vrsch. Längen |<br />
* HF-Litze(n) |<br />
<br />
== Platinen/Prototypen ==<br />
* Laser-Folien für die Druckformerstellung(Zweckform 3491) ||||| ||||| ||||| ||||| ||||| ||||<br />
* SOIC auf PDIP Gehäuse-Adapter zwecks Prototypen-Bau ||||| ||||| ||||| ||||| ||||| ||||| ||<br />
* Tonerverdichter (www.Huber-Troisdorf.com) ||||| ||||| ||||| ||||| ||||| |<br />
* Adapter TQFP (versch. PinZahlen) auf DIL/QIL ||||| ||||| ||||| ||||| ||||| ||||* Adapter QSOP (versch. PinZahlen) auf DIL/QIL ||||| |<br />
* Lötstopplaminat ||||| ||||| ||||| ||||| ||||| |<br />
* www.schmartboard.com hat super einfach zu lötende SMD-Adapter in allen Größen, nur leider keinen Vertriebspartner in Deutschland (doch: ELV). Wie wäre es mit Reichelt? ||||| ||||| ||||| ||||| ||||| |||||<br />
* Cadsoft Eagle ||||| |<br />
* Hohlkehlenlötspitzen (Ersa 0832HD) ||||| |<br />
* Hohlkehlenlötspitzen f. Weller MLR21 ||||| ||<br />
* Fotoplatinen, zweiseitig, Hartpapier(!) |||||<br />
* Entwickler NaOH-Frei von Bungard (SENO 4007 Universalentwickler) |<br />
* chemisches Zinnbad ||||| |||||<br />
* Bungard-Fotoplatinen auch in 80x100mm (halbes Euroformat), nicht nur 75x100mm ||||| |||||<br />
* Bungard-Fotoplatinen BLAU div. Formate ||||| ||||| ||<br />
* Fotoplatinen aus Hartpapier von Markenhersteller |<br />
* SMD Testplatine (3x3 Felder) wie bei Conrad |<br />
* Natrium Persulfat 2 kg Packung |||<br />
* Steckplatinenen (STECKBOARDS) im 84 x 54 Format (gibts bei Conrad ist da aber viel zu teuer)<br />
<br />
== Werkzeug und Zubehör ==<br />
* robuste Allzweck- und Teppichmesser ||||| <br />
* zöllische Gewindeschneider g1/4" und g 1/8" insbesondere interessant für Wasserkühlungen |||<br />
* einzelne Hartmetallbohrer in diversen Grössen (z.B. 0,8 1,0 1,3 1,5) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||<br />
* Arbeitsschalen zum Entwickeln und Ätzen von Platinen(*) ||||| ||||| ||<br />
* Gewindebohrer M2 und M2,5 ||||| ||<br />
* Konturenfräser/Gravurstichel, etc. zum Fräsen von Platinenprototypen (z.B. Bungard G60N/G30N) ||||| |<br />
* Tri-Wing Schraubendreher |<br />
* Ballistol Universalöl |||<br />
* ERSA Lötspitzen der Serie 842 (besonders die feinen) Reichelt führt bis jetzt nur 832, die feinen davon sind aber recht unbrauchbar<br />
<br />
== Unsortiert/Unspezifisch ==<br />
* Kundenkarte so wie bei ELV (Grundgebühr für ein Jahr, keine Versandkosten, evtl kleiner Rabatt) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||<br />
* Reichelt Katalog als PDF zum Download ||||| ||||| ||||| |||||| |||||<br />
* (durch pdf-download überflüssig:) der Reichelt Katalog auf CD/DVD |||||<br />
* In Bereichen wie Multimedia etc. (z.B. Spielekonsolen) ein aktuelleres Angebot, und nich wie z.B. bei der PS2 erst wenn schon fast das Nachfolgemodell draussen ist (Multimedia ist hier nur ein Beispiel, einfach mal an der Konkurrenz orientieren (Zum beispiel am grossen C)<br />
* mehr, aber als solche gekennzeichnete billig-Alternativprodukte, nicht nur High-End ||<br />
* Modellbau und Zubehör ||||| ||||| |||| (Wird immer mehr, man sieht, Reichelt hört dankenswerterweise auf diese Wishlist!!)<br />
* mehr SMD Bauteile ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* HCT-Logik in SMD ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||<br />
* Kleinere SMD-Bauformen (bes. bei ICs) ||||| ||||| |<br />
* mehr und v.a. kleine (Hand-) Gehäuse ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* gleicher Mindestbestellwert in Österreich und in der Schweiz wie in Deutschland ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* gleicher Mindestbestellwert in Niederlande wie in Deutschland |<br />
* Kein Mindestbestellwert (ich bezahle eh' Porto) ||||| ||||| ||<br />
* Filialen in Österreich und der Schweiz :-) ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||| |||||| ||||| || (man beachte das ":-)", es gibt auch in D keine "Filialen" - mt)<br />
* Versand nach Österreich über GLS oder sonstigen Paketdienst & auf Rechnung, damit die Spesen halbwegs im Rahmen bleiben (bei der letzten Bestellung ca. EUR 40) ||||| ||||| ||||| ||||| ||||| |||||<br />
* Günstige Versandkonditionen für die EU ||||| ||||| ||||| ||||| |||| ||||| |||<br />
* Selbstabholer-Option bei der Bestellung. Vergisst man es unter "Bemerkung" kommt es per Post :( |||| (für Plz 26xxx kommt eine Option für Abholer, Tip: falsche Plz eintragen)<br />
* Versand von Kleinteilen als Maxibrief, zwecks niedrigerem Versand ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* Option zum anklicken beim Versand, "nichtverfügbare Artikel automatisch streichen", wenn man das ins Kommentarfeld schreibt wirds nicht beachtet, oder bis das jemand liest dauert es wieder mehrere tage. ||||| |||||<br />
* mehr Familien von Logik-ICs, z.B. AC, ACT, LVC (in SMD) ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||<br />
* LiPoly-Zellen (aufladbare Lithiumakkus "Suppentüten") ||||| ||||| ||||| ||||| ||||| ||||| ||||| |<br />
* Allgemein mehr Sensoren ||||| ||||| ||||| ||||<br />
* Preiswertere Alu Druckgussgehäuse, wie z.B. von Hammond Manufacturing ||||| ||||| ||||<br />
* nicht wie die Konkurrenz jetzt schon im April den Juli-Katalog rausbringen ||||| ||||| |||||<br />
* Neuere, bessere NiMh Akkus (z.b. GP1100 2/3A, GP2000 AF, GP2200 4/5SubC) ||||| ||||| |<br />
* Funk-Entstördrosseln 16A, div. Werte |||||<br />
* Taster, Schalter und LED-Fassungen aus der Mentor FEL-Reihe ||<br />
* Lötfähige (SMD-) Kühlkörper (Fischer) ||||| ||||| ||||<br />
* Toner für Laserdrucker Kyocera FS-1010 TK17 ||||| ist ja eigentlich der gängigste Kyocera Toner<br />
* Toner für Kyocera FS800-S |<br />
* Microchip PICkit 2 ||||| |||<br />
* Möglichkeit für Selbstabholen eine Bestellung unter 10Euro abzuliefern. |<br />
* Bessere Auswahl: statt MSP430F147, F148, F149 wenigstens einen mit DAC -> MSP430F16x<br />
* Cypress PSoC Mikrocontroller |||| |||| |||| |||| |<br />
* Günstigere Osziloskope z.B. Multimetrix oder Grundig ||||| ||<br />
* Digitale Speicherosziloskope für PC ||||| |||||<br />
* Sortieren und Spezifizieren der Angebotsliste in Transistoren / FET (bessere Übersicht) ||||| ||||| ||||| z.B. 400V/6A würde schonmal ganz grob helfen und senkt außerdem unnötigen Traffic weil nicht extra jedes Datenblatt angeschaut wird<br />
* Vorschaltgeräte mit G23 Fassung (zum Bau von UV-Belichtern geeigent)|||<br />
* Speicherkarten-Adapter von SD auf CF (bzw. CFII) |||<br />
* ein Abendessen mit Angela :-) (hier dürfte wohl Angelika gemeint sein) |||<br />
* USB-Leergehäuse (z.B. wie USB-Stick, WLAN-Dongle, o.ä.) ||||| ||||<br />
* Nicht so viele Tackerklammern/Gummibänder/Tesafilm/Beutel in die Verpackungstüten machen, das nervt beim Auspacken (die kaputten Tüten kann dann auch keiner mehr brauchen, die wenigen nicht kaputt getackerten hebe ich aber gerne auf! Aber bitte weiterhin alles getrennt verpacken... oder wenigstens nicht den Zip-Verschluss tackern) ||||| ||||| ||||| ||||| ||||| ||||| ||<br />
* Reflektoren für 10mm LEDs |<br />
* Beamer Casio YC-400<br />
* OBD2 Kabel auf RJ45 Stecker ||<br />
* mehr Verpackungsmaterial z.B. kleine Schachteln oder die Plastik IC-"Schienen" einzeln (und unzerschnitten) verkaufen |||<br />
* PCMCIA Wlan-Karten (Linux kompatibel) mit externem Antennenanschluss<br />
* Warenkorb immer in gleicher Reihenfolge sortiert, nicht bei jedem Aufruf anders ||||| <br />
* PIC_BASIC_II || Programm mit HardwareKey [z.B. für Azubi's]<br />
* Reichelt T-Shirt ||||| |<br />
* Pakete nach Österreich in EINER Lieferung schicken, und nicht aus "logistischen Gründen" trennen. Würde zumindest die Hälfte der Verandkosten sparen (letztes mal fast 70€ pro Paket (!) |<br />
<br />
==Messgeräte==<br />
* FS300 Messgerät Antennenanalyzer Massenpreis 50000 Stück <br><br />
* Smart Tweezer (SMD-Pinzette mit Komponentenmessung) siehe [http://www.trgcomponents.de/TrgDE/Internet/ProductShow.aspx?ItemID=680&CategoryID=2426] ||<br />
* Hameg HM2008 Oziloscope || ( ist möglich über Service -> Produktservice -> neue Artikel anfragen)<br />
*Tektronix TDS Series Osziloskope ||<br />
<br />
= Bereits im Sortiment =<br />
<br />
* Atmel AT91SAM7S32 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||| (=> Best.: AT 91SAM7S64-AU)<br />
* Atmel AT91R40008 (32bit controller 256KB-RAM 100-lead TQFP) ||||| ||||| | (=> Best.: AT 91R40008)<br />
* LCD: auch ein- und dreizeilige Variante der DOG-Serie (EA DOGM081 & 163) |||||<br />
* Platinen Basismaterial, einseitig Cu-beschichtet, 0,5..1 mm dick ||||| ||||| ||| -->0,8mm: BEL 160x100-1-8<br />
* Atmel ATtiny45 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| => ATTINY 45-20PU, ATTINY 45-20SU, ATTINY 45V-10PU, ATTINY 45V-10SU<br />
* Atmel ATMEGA48 TQFP ||||| |||| => ATMEGA 48-20 AU<br />
* Atmel ATMEGA 88 || => ATMEGA 88-20 AU, ATMEGA 88-20 PU, ATMEGA 88V-10 AU, ATMEGA 88V-10 PU<br />
* Atmel ATMEGA644 ||||| ||||| ||||| ||||| => ATMEGA 644-20 AU, ATMEGA 644-20 PU, ATMEGA 644V-10AU, ATMEGA 644V-10MU, ATMEGA 644V-10PU<br />
* Atmel ATMEGA2560 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| || => ATMEGA 2560-16AU, ATMEGA 2560V-8AU<br />
* Atmel ATMEGA2561 ||||| | => ATMEGA 2561-16AU, ATMEGA 2561V-8AU<br />
* Philips LPC2000-Serie ARM7-Controller (LPC214x, LPC213X, LPC21xx und LPC22xx) |||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| | => Bauelemente, aktiv / Controller, Speicher / Controller, Prozessoren / Philips-Controller 80C51 / 87LPC.. / 89C51<br />
* TI MSP430F2xxx (Typen mit 16 MIPS) ||||| ||||| | => Bauelemente, aktiv / Controller, Speicher / Controller, Prozessoren / Texas MSP430 Controller<br />
* Breadboards/"Steckbretter" ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||| => STECKBOARD 1K2V, STECKBOARD 2K1V, STECKBOARD 2K4V, STECKBOARD 3K5V, STECKBOARD 4K7V (zu finden unter 'Diverses/Spielwaren' :)<br />
* RS485 ESD fest: MAX3086E oder 75180 oder ISL83086E ||||| || =>MAX485ECPA <br />
* Microchip PIC 18F2550 || => PIC 18F2550-I/P<br />
* Microchip PIC 16F88 |||| || => PIC 16F88-I/P<br />
* Microchip dsPIC ||||| ||||| ||||| ||||| | => PIC 30F2010-30 SP/SO<br />
* Logicanalyzer | => ME ANT 8 und ME ANT 16<br />
* Atmel ATMEGA8 TQFP |||| => ATMEGA 8-16 TQ<br />
* 3,3V Laengsregler (LT1086-Serie z.B.) ||||| => vgl z.B. [http://reichelt.de/?ARTIKEL=LT%201086%20CM3%2C3 LT 1086 CM3,3] (SMD) oder [http://reichelt.de/?ARTIKEL=LT%201086%20CT3%2C3 LT 1086 CT3,3] (TO-220) bei Reichelt<br />
* Flexible Messleitungen: Wie gesagt Reichelt bietet ja die ganze Palette an Bananen/Laborsteckern, Krokodilklemmen usw. an, nur die Leitungen dazu fehlen im Programm. (Sind schon im Sortiment. Fertig konfektionierte z.B.: ML 100 SW, Meterware z.B.: MESSLEITUNG 10SW)<br />
* FTDI USB Chips ||||| ||||| ||||| ||||| ||||| ||| => Best-Nr. FT232BL, FT232RL (sehr interessant), FT245BM und FT2232BM (2xUART auf USB)(noch nicht unter USB einsortiert)<br />
* CAN-Bus Controller MCP2515 |||||<br />
* VLSI MP3 Decoder ||||| ||||| ||||| | z.Zt. unter CAN-Bus(!) einsortiert. Bitte auch die neuen Gehäuse (ROHS) und Typen mit ins Angebot nehmen.<br />
* Atmel AT90CAN128 ||||| |<br />
* MMC / SDC slot ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ==> Bestell-Nr.: CONNECTOR MMC 11, CONNECTOR MMC 12, CONNECTOR SD 21 und CONNECTOR SD 22<br />
* lineare Potentiometer als Schiebepoti ||||| | - Bestell-Nr. PSM-LIN* ("mono") PSS-LIN* ("stereo")<br />
* Echtzeituhr DALAS DS1307 (auch SMD) ||||||| - Bestell-Nr. DS1307/DS1307Z<br />
* Konkret: Neuer PIC ... und PIC18F2550 ||||| ||| <br />
* MSP430F1232 |<br />
* Fädelstift, Draht und Kämme ||||| || - Bestell-Nr. Fädelstift/Fädeldraht/Fädelkamm (Warum sind diese Stifte ùnd der Draht nur so "erschreckend" teuer? => immerhin billiger als bei C...) (vielleicht weil jeder die nur 1x kauft und dann mit Draht aus anderen Quellen selber neu bewickelt?? ;-)<br />
* Mini-GPS-Module ||||| ||||| ||||| ||||| ||| - Bestell-Nr. GPS ET 102/GPS ET 202/GPS EM 401<br />
* Atmel ATmega48, ATmega168, ATtiny13 ||||| ||||| ||||| | (im neuen katalog und online verfügbar!)<br />
* CompactFlash Stecker ||||| ||||| ||||| || - Bestell-Nr. connector CF 01/ Connector CF 02 <br />
* DCF77 Empfangsmodule ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| (DCF77 Modul) (4.5.2005 ist jetzt verfügbar unter DCF77 MODUL, aber leider 50% teurer als bei der Konkurenz, störempfindlicher, grotesk schwache Ausgangstreiber)<br />
* Microchip PIC 12F683 (8pin PIC mit PWM !) => Bereits im Sortiment: Best. Nr PIC 12F683-I/P bzw. PIC 12F683-I/SN <br />
* MSP430F135 ||||| ||||| | ||||| (MSP430F135 im Programm Bestellnr.: MSP430F135 IPM)<br />
* SMD 0 Ohm in Bauform 0805 |||| -> SMD-0805 0,00<br />
* Shunt-Widerstände ||||| ||||| ||||| ||||| | (neu im Sortiment: Widerstandsdraht, Best.-Nr. "RD100/x,xx", Leider nur in teuren 100g Spulen)<br />
* dünner isolierter Draht, wie Klingeldraht nur dünner, vielleicht 0.2-0.3mm zum Fädeln von Platinen |||| => Fädeldraht nun im Sortiment<br />
* dünner Silberdraht zur Verdrahtung auf Lochrasterplatinen ||||| | (mögl. bereits im Sortiment "SILBER 0,6MM" ???)Kupferlackdraht geht nicht?<br />
* Hartmetallbohrer in mehr verschiedenen Größen (z.B. 0,6mm 0,8mm 1,1mm 1,2mm etc.) ||||| |||| => Gibt es beides Bestellnummern: "Bohrerset" oder für einzelne Bohrer "Bohrer + Größe in mm" Bsp: "Bohrer 0,6" => die kosten aber einiges, eine etwas preiswertere Alternative wäre auch nicht schlecht...<br />
* 68HC908GP32 |<br />
* überhaupt: Freescale 68HC908- und vor allem 68HCS08-Mikrocontroller fehlen total im Sortiment!<br />
* RJ45-Buchse ||| - schon im Sortiment: MEBP 8-8''x'' unter Modular-Stecker bei TK<br />
* Elektromotoren ||||| |||| (Suche: Gleichstommotor)<br />
* Microchip ICD2 || => Bestell-Nr.: DV 164005 <= Fehlt im Papierkatalog<br />
* 14,7456 MHz Quarze ||||| ||||| ||||| ||||| ||| (Bst: 14,7456-HC18)<br />
* SMD Widerstande in Bauform 1206 (SMD 1/4W...)<br />
* Atmel Atmega 128 in TQFP || (ATMEGA 128-16 TQ)<br />
* Atmel Atmega 169 in TQFP || (ATMEGA 169-16 TQ)<br />
* Atmel ATMEGA1280 ||||| ||||| ||||| |||| (ATMEGA 1280-16AU, ATMEGA 1280V-8AU)<br />
* Atmel ATMEGA8515 | (ATMEGA 8515-*)<br />
* Atmel ATtiny24/44 ||||| ||||| (ATTINY 24-*, ATTINY 44-*)<br />
* Atmel ATtiny25/85 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| | (ATTINY-25-*, ATTINY-85-* gelistet aber erst verfuegbar ab II/07)<br />
* Atmel AT91SAM7S64, AT91SAM7S256 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||| (suche AT91*)<br />
* Atmel AT91SAM7X64-256 ||||| ||| (suche AT91*)<br />
* TI MSP430F1611 (10k RAM, 48k Flash) ||||| ||||| ||||| ||||| ||||| ||||| || (MSP430F1611 IPM)<br />
* PCA9306 Dual Bi-Directional I2C-Bus and SMBus Voltage Level-Translator ||<br />
* PCA9531D 8Bit I2C_BUS LED-Dimmer ||||| |||||<br />
* PCA9551D 8Bit I2C-BUS LED-Blinker ||||| ||||<br />
* PCA9530D 2Bit I2C_BUS LED-Dimmer ||||| |<br />
* PCA9532D 16Bit I2C_BUS LED-Dimmer ||||| |||||<br />
* PCA9533D 4Bit I2C_BUS LED-Dimmer ||||| ||||<br />
* PCA9550D 2Bit I2C-BUS LED-Blinker ||||| |<br />
* PCA9553D 4Bit I2C-BUS LED-Blinker ||||| ||<br />
* PCA9552D 16Bit I2C-BUS LED-Blinker ||||| |||<br />
* Microchip PIC 18F2550 (USB, 32 KBytes Flash) | (bereits im Sortiment)<br />
* Microchip PIC 16F628A (weil: besser als 16F628) ||||<br />
* Microchip PIC 16F648 (weil mehr Programmspeicher, als 16F628) |||||<br />
* Microchip PIC 16F684 ||||| <br />
* Microchip PIC 16F688 ||||| ||<br />
* Microchip PIC 16F690 ||||| ||||| |||<br />
* Atmel ATtiny84 ||||| ||||| |||| (gelistet aber erst verfuegbar ab II/07)<br />
* TI MSP430F169 |<br />
* FT245RL (alt bekannte FTDI Chips in neuer und besserer Version, FT232RL bereits vorhanden) ||||| ||<br />
* 3,3V Längsregler SMD Ultra Low drop |||| (-> Zetex)<br />
* Schiebepotis mit passenden Knöpfen | (Bestell-Nr. PSM-LIN* ("mono") PSS-LIN* ("stereo") nicht passed?) |<br />
* OLED-Displays (zum Beispiel: [http://www.litearray.com/products-oled.php]) || (Reichelt hat jetzt Osram Pictiva Oleds im Programm. Nach "Pictiva" suchen)<br />
* OSRAM "Golden Dragon" LEDs (http://www.osram-os.com/goldendragon) ||||<br />
* Stift-/Buchsenleisten 2.54mm *zum Auseinanderbrechen* ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ("BL 1x<Polzahl>G 2,54" wird mittlerweile als teilbare Variante geliefert)<br />
* Microcontroller mit USB-Anschluss (von Cypress oder Atmel in PDIP z.B. AT89C5131, AT43USB355, CY7C637xx) ||||| ||||| ||||| ||||| ||||| ->Bereits im Sortiment: Cypress EZ-USB TQFP-44 Best. Nr AN2131 SC, Atmel AT89C5131 SO-28/PLCC-52<br />
* Renesas R8C <br />
* zu Schaltreglern LM257x u.a. passende Speicherspulen mit hohem L , niedrigem R und großer Strombelastbarkeit (zB. Würth WE-PD4) (keine "Entstörspulen") ||||| ||||| ||||| ||||| ||||| ||||| |||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| || (suche L-PIS*)<br />
* IL300 (linear Optokoppler z.B. von Vishay egal ob DIP oder SMD) ||||| ||||<br />
* IL300H (linear Optokoppler von Siemens als DIP) - andere IL300 Varianten im Programm |||<br />
* "optische" Drehgeber Fabrikat Grayhill sind lieferbar (Bst. ENC 62P22-*)<br />
* mechanische Drehimpulsgeber von Alps im Programm (suche STEC*)<br />
** Drehimpulsgeber (konkreter Vorschlag von O.R.: PEC16-4220F-S0024 von Bourns) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||<br />
** Drehimpulsgeber- weiterer Vorschlag: ALPS Encoder ST EC 11B ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||| Im Programm (STEC11B01)<br />
* PCA9633D16 4-bit I2C-bus LED driver ||<br />
* I²C-Bus to 1-Wire DALLAS DS2482-100 bzw. DS2482-800 ||||| ||||| ||||| ||||| ||||| ||||<br />
* Step-Down-Konverter in SMD Bauform (z.b. MC 34063): ||||| (->Artikel-Nr: MC 34063 AD)<br />
* Preiswerte Kontaktierungen für SD/MMC ||| (Bereits im Programm: Bestell-Nummern: CONNECTOR MMC 11 / CONNECTOR MMC 12 / CONNECTOR SD 21 / CONNECTOR SD 22) // ~9 EUR sind wohl kaum preiswert!<br />
* Eisen(III)-Chlorid ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||<br />
* EA DOG-M128 128x64 Grafikdisplay aufbau ähnlich EA DOGM162 |||||<br />
* 3,3V-Längsregler SMD zu vernünfitgen Preisen (Bsp: LF33 --> Best.Nr.: LF 33 CV, Preis: 0,76&#8364;)(der LT1086 kostet 4 Euro) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| || -> LT1117 CST-3.3V für 1.55 €<br />
* Spannungsregler in SMD-Version (7805 etc., nicht nur der 78L05) ||||| ||||| ||||| ||||| ||||| ||||| ||| -> LT1117-ADJ für 1.55€<br />
* TSic Temperatursensoren von ZMD ||| -> TSIC<br />
<br />
= Sonstiges =<br />
<br />
== zur Webseite ==<br />
<br />
Besserer Umgang mit Cookies es kommt manchmal vor das der über längere Zeit erstellt Warenkorb plötzlich leer ist, trotzdas man keine Cookies löscht oder verhindert. Eine Exportfunktion so das diese evtl. selbst sichern und wieder einbinden kann. Bei einer Registrierung(Benutzername/Passwort) könnte man evtl. den Warenkorb Serverseitig speichern.<br />
<br />
Eine Webseite ohne Frames ist eigentlich heute Stand der Technik. Oder vielleicht ist es das auch nicht mehr - ich weiss es nicht aber nach meiner Auffassung sollte es Stand der Technik sein. Denn dann hat man für jedes Produkt auch einen eindeutigen Link und kann ggf. auch in Beiträgen, Mails und Anfragen darauf verlinken.<br />
<br />
Anmerkung dazu:<br />
Verlinken auf Artikel geht schon, und zwar in der Form:<br />
http://www.reichelt.de/?ARTIKEL=ATMEGA%208-16%20DIP<br />
bzw.<br />
http://www.reichelt.de/index.html?ARTIKEL=ATMEGA%208-16%20DIP<br />
<br />
Neu zu lesen unter "Info zum Shop":<br />
Zitat:<br />
"Frames<br />
In vielen Votings wurden wir auf die Verwendung von Frames hingewiesen und dass diese Technik nicht mehr -State Of The Art- sei. Dieser Meinung schliessen wir uns in vollem Umfang an. In unserem neuen Shop werden KEINE FRAMES verwendet."<br />
<br />
Reichelt selbst macht das in seinen PDF-Prospekten auch so. Das Problem liegt nur darin, die URL jedesmal von Hand zusammenzubauen (und dabei auf die Ersetzung der Leerzeichen durch %20 zu achten) oder von einer kopierten URL alles überflüssige zu entfernen.<br />
<br />
Einfach mal einen "Permalink" button neben "artikel empfgehlen" ? Oder zurück mit der früheren Druckansicht.<br />
<br />
Hinweis: Viele Browser ersetzen Leerzeichen im Adressfeld automatisch durch %20. <br />
<br />
----<br />
<br />
Die Webseite sollte auch in Standard-Browsern wie FireFox korrekt angezeigt werden. <br />
<br />
Ich nutze reichelt schon immer mit firefox, klappt doch alles.<br />
<br />
Zitat aus "Info zum Shop":<br />
"Getestet wurden unsere Seiten mit:<br />
FireFox ab Version 1.5.0.7. für Windows und Linux<br />
Opera ab Version 9.01 für Windows<br />
Mozilla ab Version 1.7.13 für Windows<br />
Netscape ab Version 8.1 für Windows<br />
Internet Explorer ab Verion 6.0.28..."<br />
<br />
----<br />
<br />
Ferner sollte es möglich sein, Bestellungen, welche noch nicht bearbeitet werden zu verändern, also z.B. was hinzuzufügen oder zu entfernen. Bei einer Wartezeit von ca. 3 Tagen bis zum Versand fällt einem doch noch was ein :-)<br />
<br />
Das wird bereits gemacht! Einfach E-Mail an service@reichelt.de mit den Bauteilen, die man noch haben will. I-Net-Nummer nicht vergessen.<br />
<br />
Andere Möglichkeit ist anrufen, das mache ich eh immer, um eventuell nicht lieferbare Dinge zu streichen oder zu ersetzen. Geht immer, es sei denn Lieferung wird schon verpackt.<br />
----<br />
<br />
Shopprogramm: Wär es nicht komfortabel, ein Programm auf dem heimischen Rechner zu haben, welches das aktuelle Sortiment mit den aktuellen Preisen führt, wo dann auch offline Bestellungen zusammengestellt und hochgeladen werden können? So ließen sich die Merklisten auch besser verwalten.<br />
<br />
Ja, das fände ich auch sehr toll, sollte man mal drüber nachdenken.<br />
<br />
----<br />
<br />
Passwortschutz: Die derzeitige Lösung der Anmeldung im Shop ist für den heutigen Stand der Dinge recht unsicher. Ein zur Kundennummer gehörendes Passwort sollte schon sein. Was soll schon passieren, die Versandadresse ist ja bekannt, und wenn jemand anderes auf meinen Namen bestellt. läßt er sich über die Versandadresse rausfinden, außerdem weiß ja auch nicht jeder meine Kundennummer.<br />
<br />
----<br />
<br />
Eine Art Lagerbestand im Onlineshop wäre sinnvoll. Es ist mehr als ärgerlich, wenn bei einer Bestellung z.B. Kleinteile wie Kondensatoren oder Schalter fehlen, weil sie nicht auf Lager waren. Dabei gibt es gerade bei solchen Teilen genug Alternativen, sei es Farbe, Bauart oder Wert, auf die man umsteigen könnte, damit die Bestellung vollständig ist. Es würde ja vollkommen ausreichen den Bestand in Form einer Ampel, wie bei anderen Shops, mit grün, gelb und rot zu realisieren.<br />
<br />
Im Warenkorb werden Artikel, die nicht auf lager sind, mittlerweile auch so gekennzeichnet.<br />
<br />
----<br />
<br />
Früher würden neue Artiekle mit einem gelben "NEU" gekennzeichnet, jetzt ist das nicht mehr so. Hätte gerne wieder einen überblick was neu hinzugekommen ist ohne jede Artikelgruppe aufrufen zu müssen.<br />
----<br />
<br />
Nummerierung der Bauteile: Warum wird der Warenkorb nicht numeriert. Ich hasse es wenn ich manuell mit Hand zaehlen muss! Das ist auch nervig wenn man manuell per Hand vergleichen will!!<br />
<br />
----<br />
<br />
Virtuelle Bauteilekisten (vbox): Wer bei Reichelt bestellt ordert oft viele viele Kleinteile. Wenn man nun ein Gerät zum wiederholten mal baut, muss man alle Teile erneut eingeben. Könnte ich nun neben dem Warenkorb auch noch virtuelle Bauteilekisten füllen würde das neue Bestellungen sehr beschleunigen. Der Kunde als Wiederholungstäter sozusagen.<br />
<br />
Konkret:<br />
Ich habe vier verschiedene Elektronikprojekte entwickelt.Für jedes dieser Projekte lege ich bei Reichelt.de eine virtuelle Bauteilekiste mit eigenem Namen an. Die Zusammenstellung der Artikel funktioniert wie beim normalen Warenkorb. Wenn ich nun ein Projekt erneut bauen möchte, kopiere ich einfach den Inhalt der virtuellen Bauteilekiste per Knopfdruck in meinen Warenkorb. Wenn ich Projekt2 also dreimal nachbauen möchte kopiere ich die virtuelle Bauteilebox "Projekt2" dreifach in den Warenkorb.<br />
Schön wäre es auch die virtuellen Bauteilekisten mit Schaltplan und ev. Eagle - Dateien veröffentlichen zu können.<br />
<br />
Konkret:<br />
Ich habe eine Schaltung entwickelt für die ich eine persönliche virtuelle Bauteilekiste bei Reichelt.de zusammengestellt habe. Jetzt gebe ich meine persönliche virtuelle Bauteilekiste mit einer Kurzbeschreibung und einem Link auf meine Homepage(Projekthomepage) auf vbox.reichelt.de frei. Gleichzeitig setze ich auf meiner Homepage einen link auf meine öffentliche "vbox" bei Reichelt. Die öffentliche "vbox" ist dabei nur eine Referenz auf die persönliche "vbox" (synchron) und ist nur von mir veränderbar.<br />
Ich hoffe die Idee ist verständlich formuliert.<br />
<br />
EDIT: Nur so nebenbei - in anderen Shops geht das bereits RUDIMENTÄR (natürlich nicht mit öffentlichem Zugang...) in Form von Merkzetteln - die kann man meist unbegrenzt lang speichern und später einfach immer wieder in den Warenkorb legen. Das sollte das mindeste sein was man dem Kunden in einem modernen Shopsystem bietet!<br />
<br />
Und wieso ist der Login, den es früher mal gab weg? Da konnte man zumindest den aktuellen warenkorb speichern soweit ich mich erinnern kann, aber seit der neuen Website gibt's den Login nicht mehr. Ausserdem muss ich jetzt jedesmal meine Kundennummer rauskramen um meine Bestellung abzusenden - Conrad löst das beispielsweise besser. (dafür haben die aber auch ne besch...eidene Suchfunktion und nen unübersichtlichen Shop)<br />
<br />
Nebenanregung:<br />
Damit die "Bauteilekisten" nicht unmengen Platz beim Anbieter verschwenden könnte man diese auslagern.<br />
Also Nach erstellen Download als einfaches File und bei Bedarf einfach bei Bestellung übertragen.<br />
So könnte sie jeder in Ruhe offline vorbereiten und verwalten.<br />
<br />
Einfacher Kompromiss: Ein einfacher CSV-Import, -Export (Text mit Tabulator oder Semikolon getrennt) währe auch eine Alternative. Im aller einfachsten Fall könnte man das über eine Textbox realisieren. So könnte man auch eigene Projekte schneller eingeben bzw. sichern.<br />
<br />
IDEE: Offenlegung der Datenbank: Offenlegung der Datenbank oder zumindest Export fuer die User. Somit koennten die Datenbank in eine Art Datenbank gespeichert werden. Als Katalogprogramm koennte dann soetwas aehnliches wie das von Segor zum Einsatz kommen. Gibt es einen Standard dann koennten Reichelt, Conrad, Segor, etc. mit einem Programm genutzt und verglichen werden:<br />
siehe auch http://www.mikrocontroller.net/forum/read-7-363596.html<br />
Programmierunterstuetzung findet sich bestimmt. Abgesehen davon haben die Distributoren den Vorteil die Katalogdaten uebers Internet upzudaten.<br />
<br />
Zum offenlegen der Datenbank: Wie wäre es mit einem Webservice, mit dem man über SOAP auf die Datenbank zugreifen kann? Ähnlich wie bei Amazon oder auch Google.<br />
<br />
Aktuell bei Reichelt: unter MyReichelt sollen Kunden sich einloggen können und BOMs getrennt speichern können und in einem Rutsch zum Warenkorb hinzufügen können, sowie auch Links zu diesen BOMs erstellen können, die dann jeder einsehen kann. Siehe auch http://www.mikrocontroller.net/topic/62628<br />
<br />
Lösung in HTML:<br/><br />
Ich hatte für das Projekt [http://www.mikrocontroller.net/topic/82127 "Webserver ATmega32/644DIP ENC28J60"] ein Bestellformular ([http://www.mikrocontroller.net/attachment/29451/reichelt.htm reichelt.htm] <span style="font-size: 0.8em;">[Version vom 22.12.2007]</span>) gebastelt um schnell alle nötigen teile in den Reichelt – Warenkorb zulegen. Mit etwas HTML-Kenntnis dürfte eine Anpassung nicht das Problem darstellen.<br/><br />
In JavaScript, des '''reichelt.htm''' Bestellformulars, die Funktion <code>'''send()''' ''Zeile 42:'' var maxElements = 40;</code> die '''40''' durch die Anzahl der unterschiedlichen Bauteile Anpassen.<br />
<br />
== zu Artikeln ==<br />
<br />
* Kupferlackdraht: Auf der Website sind Plastikspulen abgebildet, geliefert wird jedoch seit Jahren schon lose aufgewickelter Draht, der so schlecht zu verarbeiten ist. Bitte ändern! Am besten vernünftigen Draht auf Spulen, zumindest aber das Bild anpassen.<br />
<br />
* Spitze fände ich eine verbesserte Suche für Gehäuse. Oft stehe ich vor dem Problem, meine Baugruppe ist so-und-so groß und ich brauche ein Gehäuse, in das diese Baugruppe hineinpasst. Zur Zeit muss ich mich manuell durch alle Gehäusegrößen "durchwühlen", bis ich ein passendes gefunden habe. Die Suche stelle ich mir so vor: Ich gebe die Maße ein, die das Gehäuse mindestens haben ''muss'', und bekomme alle Gehäuse angezeigt, die genau so groß oder etwas größer sind als meine Vorgaben.<br />
<br />
== Abwicklung ==<br />
<br />
* Sammelbestellung: Wenn ich etwas bei Reichelt bestelle, bestelle ich für meine Kollegen auch immer etwas mit. Wenn dann das Päckchen kommt, heisst es sortieren. Wer hatte von was, wie viel? Danach kommt das rechnen dran. Ein besonderes Highlight, sind die Nettopreise. Und auch das Verteilen der Versandkosten ist nicht ohne. Währe es nicht möglich, im Bestellvorgang eine Zuordnung zu Personen oder Projekten zu realisieren, und die Zwischensummen der Personen oder Projekte auf der Rechnung oder per Mail anzugeben. Ein Schmankerl wäre die Angabe der Bruttopreise inklusive der anteiligen Versandkosten.<br />
** Wahrscheinlich nicht möglich, siehe AGB-Klausel zu Massenbestellungen. "Garantieberechtigt" ist auch immer nur der ursprüngliche Besteller.<br />
** Welche Klausel? Mir fällt nur 13.3 ins Auge...<br />
<br />
== zu dieser Wunschliste ==<br />
<br />
(gehört eigentlich in Diskussion)<br />
<br />
* Wäre es möglich ein Script zu bauen, welches man ab und zu über diesen Artikel jagt und das die Einträge nach Anzahl der Striche ordnet? => Formatierung als Tabelle (1. Spalte: das Teil, 2. Spalte: die Striche) würde auch schon helfen.<br />
<br />
* Dass hier jeder immer nur einen Strich macht, glaube ich nicht! Ein Script was pro IP nur einen Strich zulässt wäre gut. -> Naja, alle 24h spätestens gibt es eigendlich eine neue IP...<br />
<br />
* Warum macht der 5te nicht anstelle |||| ein V :-) und anstelle vom nächsten V kommt dann ein X ....Daniel [[Benutzer:84.179.17.164|84.179.17.164]] 20:11, 4. Feb 2006 (CET)<br />
<br />
* Wenn Reichelt was aus der Liste neu ins Programm aufnimmt wäre eine Benachrichtigung per Newsletter oder RSS nett. Oder zumindest eine Rubrik "Seit XX.XX.200X neu im Programm".<br />
<br />
== Logbuch ==<br />
12.03.2009: Da haben wir ja alle verpennt, Reichelt in 2008 mal wieder an die Liste zu erinnern. Ich hab das jetzt mal nachgeholt und eine Mail an Reichelt geschickt. -- [http://www.reintechnisch.de Winfried Mueller]<br />
<br />
03.08.2007: Das Feld für "neue Artikel" scheint aus dem Reichelt Shop entfernt worden zu sein, schade da man so schnell schauen konnte was neu im Programm ist, nun ist wieder Katalogblättern angesagt. - Nicht nachvollziehbar. siehe Startseite->Service->Neu in unserem Shop <br />
<br />
18.05.2007: Habe Reichelt an diese Liste erinnert. -- Robin Tönniges<br />
<br />
14.11.2006 Ich lese mir gerade euer Wishlist durch. Finde ich gut! Aber wie ihr <br />
hier (Logbuch) über Reichelt kritisiert finde ich nicht fair! Die haben genug zu arbeiten! Bitte keine Vorurteile! Um das gehts mir hauptsächlich!<br />
Macht weiter nur nicht so! <br />
P.S. Schöne inforeiche Site<br />
Steven<br />
<br />
6.8.2006 Habe eine umfassende Kritik zu Reichelts neuem Webshop geschrieben und dabei auf unsere Wünsche bzl. Webseite, insbesondere "Virtuelle Bauteilebox" und "Gehäusesuche" hingewiesen. Verlinkung auf diese Seite ist auch erwähnt worden.<br />
<br />
5.8.2006 Hurra, Reichelt bietet endlich den ATtiny13V an! Jetzt können wir Batteriebetriebene Geräte (2,4-3V) bauen. By the way: Gibt es blaue LED's, die dazu passen?<br />
<br />
14.7.2006 Reichelt antwortete: (Zu lang, deshalb hier nur der Inhalt:) Wir haben ihre mail zur Kenntnis genommen (Forum wird angeblich ab und zu immer wieder kontrolliert). Entscheidender Satz (Original eines Mitarbeiters:)....Ich denke jedoch, dass die meisten und<br />
wichtigsten Wünsche zum Herbstkatalog eingelistet werden.<br />
<br />
14.7.2006 Reichelt erneut auf diesen Beitrag aufmerksam gemacht, erwarte Antwort.<br />
<br />
3.7.2006: beitz-online.de eine verlinkung gemailt. Ich hoffe das ist erlaubt.<br />
<br />
5.3.2006: Verlinkung gemailt<br />
<br />
12.10.2005: Verlinkung gemailt und gebeten sich darum zu kümmern<br />
<br />
07.10.2005: Reichelt eine Verlinkung gemailt und speziell auf LOW ESR Elkos und 433 Mhz Funkmodule hingewiesen. Mal sehen was die Antworten.<br />
<br />
08.07.2005: Reichelt bescheid gegeben, man möge mal wieder hier rein schauen -- Thomas O.<br />
<br />
13.05.2005: Antwort von Reichelt: der Versand ins Ausland bleibt leider bei 150 Eur -- nurmi<br />
<br />
09.05.2005: Reichelt bescheid gegeben, man möge mal wieder hier rein schauen -- nurmi<br />
<br />
08.05.2005: Pflege der Liste hier: Wenn ihr was in der Liste seht, was bereits schon im Angebot ist, löscht es bitte! Sonst ist das hier bald ein unüberschaubares Chaos. -- [http://www.reintechnisch.de Winfried Mueller]<br />
<br />
08.02.2005: Positives Feedback von Reichelt. Freuen sich über diese Form der Anregung. In der 2. Märzhälfte sollen weitere Produkte in den neuen Katalog einfließen. -- [http://www.reintechnisch.de Winfried Mueller]<br />
<br />
07.02.2005: Reichelt bescheid gegeben, man möge mal wieder hier rein schauen -- [http://www.reintechnisch.de Winfried Mueller]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=Heizungssteuerung_mit_Honeywell_HR20&diff=36077
Heizungssteuerung mit Honeywell HR20
2009-05-11T18:57:10Z
<p>Leo1969: /* The Wireless HR20 Branch */</p>
<hr />
<div>''von DarioC''<br />
<br />
= Wie alles begann =<br />
<br />
Nachdem von Uwe Felgentreu vor nunmehr vor über vier Jahren (genau am 17.11.2004 um 11:26) hier in diesem Forum den Thread mit dem Titel ''Honeywell Rondostat HR20E per AVR steuern und konfigurieren'' gestartet hat ist es nun langsam soweit, dass das Ganze auch ein Projekt wird. <br />
<br />
Den Thread dazu kann der interessierte Leser [http://www.mikrocontroller.net/topic/17603 hier nachlesen]<br />
<br />
= Projektziel =<br />
<br />
Wir konzentrieren uns in erster Linie auf den Honeywell Rondostat HR20E mit ausgelieferten Softwareversion 2.04. Dass es ähnliche andere Geräte gibt behalten wir bei der Entwicklung im Hinterkopf.<br />
<br />
Basierend auf dieser Hardware wollen wir eine neue Software entwickeln. <br />
Dabei können wir ausser der Hardware nichts weiter verwenden, da die Originalsoftware geschützt ist und nicht ausgelesen werden kann.<br />
<br />
== Phase 1 ==<br />
Die Software soll die Funktionen bieten, die die Originalsoftware auch bietet, später können dies dann um zusätzliche Funktionen erweitert werden. Die wichtigsten Funktionen sind:<br />
<br />
* Temperaturregelung<br />
* Echtzeituhr<br />
* Ausnutzen der Sleep Funktion<br />
* Anzeige Soll-Temperatur und der Uhrzeit<br />
* Einstellung der Soll-Temperatur<br />
* Uhrzeitgesteuerte Einstellung der Soll-Temperatur <br />
* Fenster-Offen-Erkennung<br />
* Ventilfreispülungsfunktion<br />
<br />
== Phase 2 ==<br />
<br />
Hier liegt der Sinn des ganzen Projektes: Durch diese zusätzlichen Funktionen wollen wir den Nutzwert des Thermostaten erheblich steigern:<br />
<br />
* Programmierung der Schaltzeiten und Temperaturen über externe Schnittstelle<br />
* Abfrage der Messwerte und Parameter über externe Schnittstelle<br />
* Vernetzung der Thermostaten untereinander<br />
* Zusätzliche externe Schnittstellen (neben UART auch CAN und Funk)<br />
* Erweiterung der Anzeige um<br />
** Ist-Temperatur <br />
** Ventilstellung<br />
** Funkschnittstelle<br />
*** RFM12 http://www.hoperf.com/rf_fsk.asp<br />
**** Library dazu im [https://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12/ SVN], [http://www.das-labor.org/wiki/Datenfunk_mit_dem_AVR Doku hier]<br />
*** Zigbee http://www.meshnetics.com/zigbee-modules<br />
** ...<br />
* Bootloader, damit Leute mitarbeiten können, die keine JTAG haben. Mit einem JTAG könnte man den Bootloader Flashen, ohne den Thermostaten öffnen zu müssen. Von da an kann man über den Programmierstecker mit einem umgebauten Handykabel den Thermostaten neu flashen.<br />
<br />
= Lizenz =<br />
Die Software wird unter GPL v2 gestellt.<br />
<br />
= Forum, Diskussion =<br />
Da der '''orginale Thread ueber den HR20''' <br />
http://www.mikrocontroller.net/topic/17603<br />
ist mittlerweile sehr lang und vereinigt sehr viele Sub-Topics, darum wurde ein neuer Thread <br />
'''OpenHR20: Firmware for Honeywell Rondostat HR20E''' in<br />
http://embdev.net/topic/118781#new erstellt. <br />
Bitte alles Firmware-spezifische dort und in Englisch schreiben, da das Entwicklerteam international ist.<br />
<br />
= Subversion Repository =<br />
Das alte SVN Repository auf https://opensvn.csie.org war zu lahm, <BR><br />
daher haben wir ein Projekt auf Sourcefore angelegt.<br />
=== Zugangsdaten ===<br />
Projektseite: http://sourceforge.net/projects/openhr20/ <BR><br />
Repository Location: https://openhr20.svn.sourceforge.net/svnroot/openhr20 <BR><br />
Browse Repository: http://openhr20.svn.sourceforge.net/viewvc/openhr20/ <BR><br />
=== Policy ===<br />
Anonymous check out ist erlaubt. <br><br />
Wer was committen will muss freigeschaltet werden. <br><br />
Dazu brauche ich den Sourceforge Accountnamen.<br><br />
Einfach eine Email mit Username und Password an hr20[at]carluccio[dot]de<br><br />
Das mache ich dann von Hand und da ich nicht alle 10 Minuten Mails bearbeite kann das auch schon mal einen oder zwei Tage dauern. <br><br />
Wenn sich ein Maintainer findet, gebe ich die Zugangsdaten gerne weiter.<br />
<br />
=== SVN Client und Anleitung ===<br />
Windows-User nutzen am besten den Tortoise-SVN-Client, den man kostenfrei [http://tortoisesvn.tigris.org hier runterladen] kann. <br><br />
Dort gibt es auch eine Anleitung zum Arbeiten mit SVN.<br />
<br />
= Analyse der Hardware =<br />
Die Analyse hat der Dario schon gemacht, zu finden ist die jeweils aktuelle Version <br />
[http://carluccio.de/images/e/e1/Hr20-analyse.pdf als PDF hier] oder [https://opensvn.csie.org/viewcvs.cgi/doc/analyse.pdf hier im SVN].<br />
== Fuses ==<br />
Here the settings of the fuses:<br />
<br />
{| border="1" cellpadding="5" <br />
! width="100" | <br />
! width="150" | Original <br />
! width="150" | OpenHR20<br />
|-<br />
| align ="center" | Extended<br />
| align ="center" | 0xFD<br />
| align ="center" | 0xFD<br />
|-<br />
| align ="center" | High<br />
| align ="center" | 0x91<br />
| align ="center" | 0x9B<br />
|-<br />
| align ="center" | Low<br />
| align ="center" | 0x62<br />
| align ="center" | 0xE2<br />
|-<br />
| align ="center" | EESAVE<br />
| align ="center" | enabled<br />
| align ="center" | disabled<br />
|-<br />
| align ="center" | BOOTSZ<br />
| align ="center" | 1024 Words (1E00) <br />
| align ="center" | 512 Words (1C00)<br />
|-<br />
| align ="center" | CKDIV8 <br />
| align ="center" | 1 <br />
| align ="center" | 0<br />
|}<br />
<br />
= TODOs =<br />
<br />
== Main-Branch / all Branches of the Project ==<br />
{| border="1" cellpadding="5" <br />
! Task<br />
! Remark<br />
! Responsible<br />
! Status<br />
|-<br />
| Code Review<br />
| Check the code, complete doxygen coments<br />
| <br />
| <span style="color:red;">''' OPEN '''</span><br />
|-<br />
| UserManual<br />
| Write a User Manual, Screenshots are in \trunk\doc\Screenshots\<br />
| <br />
| <span style="color:red;">''' OPEN '''</span><br />
|-<br />
| PC-Software<br />
| Write PC-Program to: <BR>- Read and Write OpenHR20 Settings <BR>- Log Status from OpenHR20<BR>- Visualize Logfile<BR> <br />
| <br />
| <span style="color:red;">''' OPEN '''</span><br />
|-<br />
| Bootloader<br />
| Do we still need a Bootloader ?<br />
| <br />
| <br />
|-<br />
|}<br />
<br />
== The Wireless HR20 Branch ==<br />
<br />
Dieser Projektzweig hat das Ziel, die HR20-Firmware so zu erweitern, dass sie ueber RFM12 FunkTransceiver fern-mess/steuer/regel-bar sind.<br />
<br />
'''Status:''' Noch nicht einsatzbereit.<br />
<br />
'''DONE:'''<br />
* '''Anschluss eines RFM12-Funkmoduls an die von aussen zugaenglichen JTAG-Pins.''' Die JTAG-Pins werden durch die "RFMizierte" Firmware nicht disabled sondern nur zur Laufzeit in IO-Ports verwandelt. Man kann also weiter mit JTAG draufflashen, muss das RFM aber vorher abstecken. Auch das JTAG-Debugging geht nicht mehr. Aber das COMport-Interface geht weiterhin, da die RxD/TxD-Pins nicht verwendet werden. Eventuell wenn uns der Platz fuer Code ausgeht, fliegt der COM aber raus, denn wer seine HR20 mit Funk ansteuert, braucht eigentlich keinen COM-Anschluss. Mal schaun wie eng es wird. Wer lustig ist kann das RFM auch ins HR20 reinbauen und mit kleinen Draehten von hinten an die Pinleiste verloeten. Fuer Aestethen und Leute die nicht debuggen wollen sicher interessant.<br />
* '''Senden eines 1/2/4/...minuetlichem StatusTelegramms''' ueber das RFM am JTAG. Das Telegramm wird moeglichst batterieschonend gesendet, d.h. zwischen ruebertakten des naechsten zu sendenden Bytes an den RFM legt sich das HR20 in Powerdown. Dieses StatusTelegramms enthaelt <br />
** GeraeteAdresse,<br />
** Challenge bzw. Nonce (s.u. wozu)<br />
** IstTemperatur,<br />
** SollTemperatur,<br />
** VentilPosition,<br />
** Manual oder Auto-Mode,<br />
** FehlerBits (Abmontiert, Getriebe klemmt, Batterie leer)<br />
** Checksumme.<br />
* '''Einstellen der GeraeteAdresse ueber LCD, Tasten und Rad''' und im NichtFluechtigen Speicher behalten. Ist zwar etwas kryptisch einzustellen (set Configuration Byte), aber man muss keine eigene Firmware mit hard kodierter GeraeteAdresse kompilieren. Bei exaktem User-Manual (alle 3 tasten lange duecken, Drehen bis 22 kommt, Prog druecken, Geraeteadresse eindrehen, Prog druecken) aber sicherlich kein Problem.<br />
* Die Kommunikation wird durch einen gemeinsam bekannten Schluessel gesichert. Der '''Schluessel ist im HR20 einstellbar''', analog wie die GeraeteAdresse.<br />
<br />
'''TODO:'''<br />
* '''Verschluesseln der gesammten Kommunikation''' mit [[http://de.wikipedia.org/wiki/XTEA XTEA]] damit keiner sieht dass die Heizung kalt ist was zum Einbruch einladen koennte ;-) Keine Grundsatzdiskussion bitte, den Verschluesselungscode werden wir sowieso auch anderweiteig brauchen.<br />
* nach dem StatusTelegramm ist das '''RFM kurz im Empfangsmodus um eventuelle Befehle''' (set SollTemp, set Manual/AutoMode, set Schaltzeit, set Uhrzeit, set VentilPos, ...) von einem Raumcontroller zu empfangen.<br />
* Dieser '''Raumcontroller''' ist (noch) nicht Teil des Projekts. Er kann z.B. eine typische AVR+FTDI+RFM-Schaltung sein, wie z.B. diese Hardware-Vorschlaege siehe [[AVR_RFM12]] und [http://www.das-labor.org/wiki/Datenfunk_mit_dem_AVR Datenfunk_mit_dem_AVR]. Viele von euch werden sicher eine simple Funk-zu-Serialport-Bruecke bauen, und ein Linux-Programm zur Steuerung zusammenkloppen. Evtl wird das auch mal ein Unter-Projekt.<br />
* Dieser Raumcontroller kann nun in einem Zeitfenster von ca 1/10 Sekunde nach HR20's StatusTelegramm dem HR20 einen Befehl geben. Das ganze wird mit einem '''Challenge-Response-Protokoll gesichert''', damit keine unbefugten Raumcontroller vom Nachbarn einem die Heizung verdrehen. Wir diskutieren noch im Forum, aber wahrscheinlich kann man die Challenge-Respnse-Authentication auch mit XTEA-Verschluesselung durchfuehren (wuerde den Code fuer eine Einwegfunktion sparen, wir haben bald ProgramSpace-Probleme).<br />
* Nach der Verarbeitung eines authentisierten Befehls '''sendet der HR20 ein Telegramm mit dem Resultat des Befehls''' zurueck. Danach ist der HR20 wieder bis zum naechsten Status in einer Minute (oder alle 2/4 Minuten) Offline. HR20 darf seinen RFM nicht permanent auf Empfang lassen, da dies ein Batteriekiller waere.<br />
* '''Dokumentation''' fuer ein leichtes Nachbauen und Erweitern.<br />
<br />
Wer noch Vorschlaege hat was rein soll, ab ins [[http://www.mikrocontroller.net/topic/118781 Forum]] damit.<br />
<br />
= API Beschreibung =<br />
Das Projekt wird mit doxygen dokumentiert, <br />
die API-Beschreibung kann aus dem Source-Code generiert werden.<br />
= UART Protocoll =<br />
<br />
This is the documentation for the UART Protocol in Release 74 of the SVN hosted on Sourceforge:<br />
<br />
== Com-Port Params ==<br />
* BAUD: 9600<br />
* Data: 8<br />
* Parity: N<br />
* Stop: 1<br />
<br />
== Automatic calibration ==<br />
When the HR20 is mounted, then the automatic calibration is started. <br />
The Debug-Info during the callibration is printed to the com-interface like this:<br />
<c><br />
+ 0210<br />
+ 047e<br />
+ 0437<br />
[... many lines deleted ...]<br />
- 0681<br />
- 0695<br />
- 0694<br />
+ 0210<br />
+ 047e<br />
+ 0437<br />
+ 0417<br />
+ 0454<br />
</c><br />
<br />
== Commands ==<br />
All commands have FIXED format.<br />
* command '''X.....\n ''' termination char<br />
* X is upcase char as commad name<br />
* hex numbers use ONLY lowcase chars<br />
=== print version information ===<br />
Command:<br />
<c><br />
V<CR> <br />
</c><br />
Response:<br />
<c><br />
V: OpenHR20 SW version V.VV build DDDD $Rev: REV $<br />
</c><br />
Where:<br />
* V.VV Version<br />
* DDDD Date at compilition <br />
* REV SVN Revision<br />
Example:<br />
<c><br />
V: OpenHR20 SW version 0.21 build Nov 13 2008 23:22:08 $Rev: 72 $<br />
</c><br />
=== print status ===<br />
Command:<br />
<c><br />
D<CR> <br />
</c><br />
Response:<br />
<c><br />
D: dW DD.DD.DDDD TT:TT:TT M V: VV I: IIII S: SSSS B: BBBB E: EE XW<br />
D: dW DD.MM.YY TT:TT:TT A V: VV I: IIII S: SSSS B: BBBB Is: IsIs ->new<br />
</c><br />
<br />
Where:<br />
* '''W''' Day of Week (monday=1)<br />
* '''DD.MM.YY''' actual date <br />
* '''TT:TT:TT''' actual time<br />
* '''M|A''' manual/automatic mode<br />
* '''VV''' actual position of valve [%] (00=closed, 100=opened)<br />
* '''IIII''' actual temperature<br />
* '''SSSS''' desired temperature<br />
* '''BBBB''' battary voltage [mV]<br />
* '''IsIs''' Integratorvalue<br />
* '''EE''' Error Code<br />
* '''X'''<br />
* '''W''' Window Open detected<br />
Example:<br />
<c><br />
D: d3 01.10.08 12:00:16 V: 00 I: 2103 S: 1700 B: 3259 E:04 X<br />
D: d3 25.03.09 22:44:00 A V: 05 I: 2585 S: 2500 B: 3044 Is: ef56 ->new<br />
<br />
</c><br />
<br />
=== print watched variable ===<br />
Command:<br />
<c><br />
Taa<CR> <br />
</c><br />
* '''aa''' watched variable see ''watch.c''<br />
Response:<br />
(return 2 or 4 hex numbers) <br />
<c><br />
T[aa]=VVVV<br />
</c><br />
Where:<br />
* '''aa''' watched variable see ''watch.c''<br />
* '''VVVV''' value of watched variable <br />
Example:<br />
<c><br />
T[01]=0cca<br />
</c><br />
<br />
=== get configuration byte ===<br />
Command:<br />
<c><br />
Gaa<CR> <br />
</c><br />
* '''aa''' hex address of configuration byte see eeprom.h<br />
Response:<br />
<c><br />
G[aa]=VV<br />
</c><br />
Where:<br />
* '''aa''' hex address of configuration byte see eeprom.h<br />
* '''VV''' value of configuration byte <br />
Example:<br />
<c><br />
G[13]=2d<br />
</c><br />
=== set configuration byte ===<br />
Command:<br />
<c><br />
SaaVV<CR> <br />
</c><br />
* '''aa''' hex address of configuration byte see eeprom.h<br />
* '''VV''' hex value for configuration byte (hex)<br />
Response:<br />
<c><br />
S[aa]=VV<br />
</c><br />
Where:<br />
* '''aa''' hex address of configuration byte see eeprom.h<br />
* '''VV''' value of configuration byte <br />
Example:<br />
<c><br />
S[13]=2d<br />
</c><br />
=== get timer ===<br />
Command:<br />
<c><br />
Rab<CR> <br />
</c><br />
* '''a''' day <br />
* '''b''' slot<br />
Response:<br />
<c><br />
R[ab]=cddd<br />
</c><br />
Where:<br />
* '''c''' timermode <br />
: '''0''' frost protection<br />
: '''1''' energy save<br />
: '''2''' comfort<br />
: '''3''' supercomfort<br />
* '''ddd''' time (minutes since 00:00, hex) <br />
Example:<br />
<c><br />
R[10]=21a4<br />
R[11]=121c<br />
R[12]=23c0<br />
R[13]=14ec<br />
R[14]=2fff<br />
R[15]=1fff<br />
</c><br />
comfort at 0x1a4 = 420 / 60 = 7<br />
energy save at 0x21c = 540 / 60 = 9<br />
comfort at 0x3c0 = 960 / 60 = 16<br />
energy save at 0x4ec = 1260 / 60 = 21<br />
Slot 5+6 not used.<br />
<br />
=== set timer ===<br />
Command:<br />
<c><br />
Wabcddd<CR> <br />
</c><br />
* '''a''' day <br />
* '''b''' slot<br />
* '''c''' timermode (0 to 3) <br />
* '''d''' time time (minutes since 00:00, hex) <br />
Response:<br />
<c><br />
W[ab]=cddd<br />
</c><br />
Example:<br />
<c><br />
W[10]=21a4<br />
</c><br />
<br />
=== Reboot ===<br />
Command:<br />
<c><br />
B1324<CR> <br />
</c><br />
* '''1234''' password (fixed at this moment)<br />
Response:<br />
<c><br />
<br />
</c><br />
<br />
=== set date ===<br />
Command:<br />
<c><br />
Yyymmdd<CR> <br />
</c><br />
* '''yy''' year<br />
* '''mm''' month<br />
* '''dd''' day<br />
Response:<br />
<c><br />
D: WW DDDDDDDD TTTTTTTT V: VV I: IIII S: SSSS B: BBBB E:EE X<br />
</c><br />
=== set time ===<br />
Command:<br />
<c><br />
Hhhmmss<CR> <br />
</c><br />
* '''hh''' hour<br />
* '''mm''' minute<br />
* '''ss''' seconds<br />
Response:<br />
<c><br />
D: WW DDDDDDDD TTTTTTTT V: VV I: IIII S: SSSS B: BBBB E:EE X<br />
</c><br />
<br />
=== set wanted temperature ===<br />
Command:<br />
<c><br />
Axx<CR> <br />
</c><br />
* '''xx''' temperature [unit 0.5C] (hex)<br />
Response:<br />
<c><br />
D: WW DDDDDDDD TTTTTTTT V: VV I: IIII S: SSSS B: BBBB E:EE X<br />
</c><br />
Example:<br />
20°C = 40 * 0,5 °C = 28 (hex)<br />
<c><br />
A28<CR><br />
</c><br />
<br />
<span style="color:red;">'''Attention: The value in the response is not the new value.<BR>The new value is updated some secondes later, so be patient and wait.'''</span><br />
<br />
=== set mode ===<br />
Command:<br />
<c><br />
Mxx<CR> <br />
</c><br />
* '''xx''' mode <br />
: 00 = manu<br />
: 01 = auto<br />
Response:<br />
<c><br />
D: WW DDDDDDDD TTTTTTTT V: VV I: IIII S: SSSS B: BBBB E:EE X<br />
</c><br />
<br />
= Bootloader =<br />
Um ein einfaches Update der Software, auch ohne Programmer und Zerlegen des HR20E zu ermöglichen, sollte ein Bootloader implementiert werden.<br><br />
<br />
'''Grundsatzproblem:''' Fuer ein erstes Umflashen eines eben aus der Verpackung genommenen HR20s braucht man ''immer'' einen JTAG-Programmer um ueberhaupt erstmal den Bootlader selber draufzukriegen.<br />
<br />
== Anforderungen ==<br />
* Einfaches Update ohne öffnen des HR20E<br><br />
* Nutzen bestehender Programme (Terminalprogramm), das erspart das schreiben von Update Software<br><br />
* HR20E sollte nach dem Start prüfen ob Programm gültig und nur dann das Anwenderprogramm starten<br />
* Protokoll sollte Updatevorgang aus dem laufenden Betrieb unterstützen (Sprung in den Bootloader)<br />
<br />
== Vorschlag 1 ==<br />
X-Modem Protokoll (mit CRC)<br><br />
Hier gibt es eine fertige Lösung für das Etherboot projekt, deren Übernahme gestattet ist.<br> <br />
Größe ist hier kleiner 1kB und wohl verkraftbar.<br><br />
<br />
Vorteil:<br><br />
* etablierte Technik<br />
* von anderen Herstellern verwendet<br />
* wird von den meisten Terminal-Programmen unterstützt<br />
* Gesichert durch Checksumme<br />
Nachteil:<br><br />
* Aufwendige Checksummen-Berechnung oder Lookup-Tabelle notwendig<br />
<br />
== Vorschlag 2 ==<br />
Verwendung des [[AVR_Bootloader_FastBoot_von_Peter_Dannegger]]:<br />
Der ist sehr klein, erprobt, leicht anwendbar und funzt auch sehr gut. Die Windows-Software fuer den Upload ist auch sehr gelungen. Auf Grund des o.g. Grundsatzproblems und der Tatsache dass die Neuentwicklung eines Bootladers sehr anspruchsvoll ist, halte ich es an dieser Stelle fuer besser, das Rad nicht neu zu erfinden.<br />
<br />
= Entwicklungsumgebung =<br />
* Editor, Debugger, Compiler<br />
** WinAVR version (20071221), sprich GCC 4.2.2 sowie avr-libc 1.6.0<br />
** AVR Studio 4 <br />
* JTAG ICE<br />
** Atmel AVR JTAGICE MK2 <br />
** AVR Dragon (z.B. http://elmicro.com/de/atavrdragon.html)<br />
** Olimex-Seriell http://www.olimex.com/dev/avr-jtag.html <br />
** Olimex-USB http://www.olimex.com/dev/avr-usb-jtag.html <br />
<br />
= Sonstiges =<br />
== Altes Protokoll ==<br />
[[HR20_Protocol_V2 | Hier ]] hat mal einer ein Protokoll eingegeben.<br />
Das scheint aber nicht zu der Version 2.04 zu passen. <br />
Ich habe es nicht gelöscht, falls es jemanden interessiert.<br />
<br />
[[Category:Projekte|!]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=Wanderkiste.at&diff=35860
Wanderkiste.at
2009-05-01T09:40:41Z
<p>Leo1969: /* Benutzerliste */</p>
<hr />
<div>== Motivation ==<br />
<br />
Nachdem Andreas Jakob in http://www.mikrocontroller.net/topic/118816 das Projekt einer Wanderkiste elektronischer Bauteile in der BRD ins Leben gerufen wurde dieser Beitrag auf große Resonanz gestoßen ist, ist es gut vorstellbar dieses Projekt auch in der Republik Österreich zu starten.<br />
<br />
Nachdem von diversen Autoren darauf hingewiesen wurde, daß der Beförderungsbetrag für Pakete im grenzüberschreitenden Warenverkehr innerhalb unserer Wirtschafts- und Währungsunion sehr hoch ist, bleit wohl nichts anderes über als für Österreich eine eigene Elektronikwanderkiste zu gebären.<br />
<br />
== Realisierung ==<br />
<br />
Benutzer, welche sich an diesem wundersamen Projekt beteiligen wollen tragen sich in die untere Benutzerliste ein und erhälten dann irgendwann das Paket vom aktuellen Benutzer übersendet. Man nehme sich nun aus der Postsendung jene Teile welche man gebrauchen kann und legt im Gegenzug Komponenten aus dem eigenen Bestand hinein, die man nicht mehr benötigt, die aber für andere nützlich sein könnten. Nimmt man etwas aus der Kiste, so sollte man auch etwas hinein legen, das vergleichbaren Wert hat. Man sucht sich nun aus der aktuellen Benutzerliste jemand aus, und sendet die Kiste weiter an ihn.<br />
<br />
So bekommt nun jemand für das Porto ein Überraschungspaket mit möglicherweise brauchbaren Teilen und wird seine nicht mehr benötigten Komponenten relativ sinnvoll los. <br />
<br />
=== Erstversender gesucht ===<br />
<br />
Da sich bis dato kein initialer Seeder gefunden hat, welcher ein österreichisches Wanderkistenpaket zusammenstellt und versendet, hier nun dieser Abschnitt. <br />
Das Projekt droht sonst leider im Sande zu verlaufen.<br />
<br />
== Benutzerliste ==<br />
<br />
Ich finde die Idee gut und hoffe daß mich jemand in die Empfängerliste einträgt. Meine Kontaktdaten sind:<br />
<br />
* '''Username auf mikrocontroller.net oder Email-Adresse'''<br />
<br />
*[http://www.mikrocontroller.net/user/show/leo1969 leo1969 (Leo, Kopfing, OOE)]<br />
*[http://www.mikrocontroller.net/user/show/fregat fregat (Vadim, Linz, OOE)]<br />
*[http://www.mikrocontroller.net/user/show/civicbcc Markus F. (Markus, Wien, W)]<br />
*[http://www.mikrocontroller.net/user/show/ivan Иван (Iwan, Wels, OOE)]<br />
*[http://www.mikrocontroller.net/user/show/tomedl TomEdl (Thomas, Kapfenberg, ST)]<br />
*[http://www.mikrocontroller.net/user/show/luke_ Lukas M. (Lukas, Steyrland, OOE)]<br />
*[http://www.mikrocontroller.net/user/show/Maulfisch Andy F.(Sinabelkirchen, ST)]<br />
*[http://www.mikrocontroller.net/user/show/christian_rx7 Christian_RX7 (Krenglbach, OOE)]<br />
<br />
== Lebensweg der Kiste ==<br />
<br />
Hier sollten sich Benutzer eintragen, welche die Kiste bereits empfangen haben. Es genügt der Benutzername, der Wohnort und das Empfangsdatum. Da das Projekt noch nicht gestartet wurde, sind folgende Daten nur Beispiele:<br />
<br />
* '''Erstmaliger Versand'''<br />
[http://www.mikrocontroller.net/user/show/ Paketversender, 15.12.2008, Wien/Schwechat]<br />
* '''Empfangsbestätigungen'''<br />
<br />
*[http://www.mikrocontroller.net/user/show/ Empfänger1, 19.12.2008, Gmunden, Oberösterreich]<br />
*[http://www.mikrocontroller.net/user/show/ Empfänger2, 24.12.2008, Faak am See, Kärnten]<br />
*[http://www.mikrocontroller.net/user/show/ Empfänger3, 31.12.2008, Oberwart, Burgenland]<br />
<br />
== Siehe auch ==<br />
[http://www.mikrocontroller.net/topic/118860 Thread zur Österreicher Kiste] <br><br />
[http://www.mikrocontroller.net/articles/Wanderkiste Das Wanderkistenprojekt in Deutschland]<br />
[[Category:Projekte]]</div>
Leo1969
https://www.mikrocontroller.net/index.php?title=Wanderkiste.at&diff=35859
Wanderkiste.at
2009-05-01T09:11:11Z
<p>Leo1969: /* Benutzerliste */</p>
<hr />
<div>== Motivation ==<br />
<br />
Nachdem Andreas Jakob in http://www.mikrocontroller.net/topic/118816 das Projekt einer Wanderkiste elektronischer Bauteile in der BRD ins Leben gerufen wurde dieser Beitrag auf große Resonanz gestoßen ist, ist es gut vorstellbar dieses Projekt auch in der Republik Österreich zu starten.<br />
<br />
Nachdem von diversen Autoren darauf hingewiesen wurde, daß der Beförderungsbetrag für Pakete im grenzüberschreitenden Warenverkehr innerhalb unserer Wirtschafts- und Währungsunion sehr hoch ist, bleit wohl nichts anderes über als für Österreich eine eigene Elektronikwanderkiste zu gebären.<br />
<br />
== Realisierung ==<br />
<br />
Benutzer, welche sich an diesem wundersamen Projekt beteiligen wollen tragen sich in die untere Benutzerliste ein und erhälten dann irgendwann das Paket vom aktuellen Benutzer übersendet. Man nehme sich nun aus der Postsendung jene Teile welche man gebrauchen kann und legt im Gegenzug Komponenten aus dem eigenen Bestand hinein, die man nicht mehr benötigt, die aber für andere nützlich sein könnten. Nimmt man etwas aus der Kiste, so sollte man auch etwas hinein legen, das vergleichbaren Wert hat. Man sucht sich nun aus der aktuellen Benutzerliste jemand aus, und sendet die Kiste weiter an ihn.<br />
<br />
So bekommt nun jemand für das Porto ein Überraschungspaket mit möglicherweise brauchbaren Teilen und wird seine nicht mehr benötigten Komponenten relativ sinnvoll los. <br />
<br />
=== Erstversender gesucht ===<br />
<br />
Da sich bis dato kein initialer Seeder gefunden hat, welcher ein österreichisches Wanderkistenpaket zusammenstellt und versendet, hier nun dieser Abschnitt. <br />
Das Projekt droht sonst leider im Sande zu verlaufen.<br />
<br />
== Benutzerliste ==<br />
<br />
Ich finde die Idee gut und hoffe daß mich jemand in die Empfängerliste einträgt. Meine Kontaktdaten sind:<br />
<br />
* '''Username auf mikrocontroller.net oder Email-Adresse'''<br />
<br />
*[http://www.mikrocontroller.net/user/show/leo1969 leo1969 (Leo, Kopfing, OOE)])<br />
*[http://www.mikrocontroller.net/user/show/fregat fregat (Vadim, Linz, OOE)]<br />
*[http://www.mikrocontroller.net/user/show/civicbcc Markus F. (Markus, Wien, W)]<br />
*[http://www.mikrocontroller.net/user/show/ivan Иван (Iwan, Wels, OOE)]<br />
*[http://www.mikrocontroller.net/user/show/tomedl TomEdl (Thomas, Kapfenberg, ST)]<br />
*[http://www.mikrocontroller.net/user/show/luke_ Lukas M. (Lukas, Steyrland, OOE)]<br />
*[http://www.mikrocontroller.net/user/show/Maulfisch Andy F.(Sinabelkirchen, ST)]<br />
*[http://www.mikrocontroller.net/user/show/christian_rx7 Christian_RX7 (Krenglbach, OOE)]<br />
<br />
== Lebensweg der Kiste ==<br />
<br />
Hier sollten sich Benutzer eintragen, welche die Kiste bereits empfangen haben. Es genügt der Benutzername, der Wohnort und das Empfangsdatum. Da das Projekt noch nicht gestartet wurde, sind folgende Daten nur Beispiele:<br />
<br />
* '''Erstmaliger Versand'''<br />
[http://www.mikrocontroller.net/user/show/ Paketversender, 15.12.2008, Wien/Schwechat]<br />
* '''Empfangsbestätigungen'''<br />
<br />
*[http://www.mikrocontroller.net/user/show/ Empfänger1, 19.12.2008, Gmunden, Oberösterreich]<br />
*[http://www.mikrocontroller.net/user/show/ Empfänger2, 24.12.2008, Faak am See, Kärnten]<br />
*[http://www.mikrocontroller.net/user/show/ Empfänger3, 31.12.2008, Oberwart, Burgenland]<br />
<br />
== Siehe auch ==<br />
[http://www.mikrocontroller.net/topic/118860 Thread zur Österreicher Kiste] <br><br />
[http://www.mikrocontroller.net/articles/Wanderkiste Das Wanderkistenprojekt in Deutschland]<br />
[[Category:Projekte]]</div>
Leo1969