Mikrocontroller.net - Benutzerbeiträge [de]

Linksammlung

2009-10-31T10:55:19Z

Thymythos: Siemens S55/C60

Auf dieser Seite werden Links zu anderen interessanten Mikrocontroller- und Elektronikseiten gesammelt.
'''
Die alte Linkseite findet man [http://www.mikrocontroller.net/en/links hier].

Hinzufügen von Links:
# [http://www.mikrocontroller.net/wikisoftware/index.php?title=Linksammlung&action=edit Bearbeiten] anklicken
# Link unter der entsprechenden Kategorie eintragen
# "Artikel speichern" klicken

== Suchen & Finden ==

''Verkauf einem hungrigen Mann einen Fisch und du hast ein Geschäft gemacht, bring ihm das Angeln bei und du hast einen Kunden verloren! (asmo)''

* [http://www.supplyframe.com/ SupplyFrame] - Datasheet and Electronic Spec Search Engine
* [http://www.globalspec.com/ GlobalSpec] - The Engineering Search Engine
* [http://www.alldatasheet.com/ alldatasheet] - Datasheet Search
* [http://www.datasheetarchive.com/ datasheetarchive] - Datasheet Search
* [http://www.msarnoff.org/chipdb/ ChipDB] - Pinouts von gängigen µCs.

== [[AVR]] ==

=== Herstellerseiten ===

* [http://www.atmel.com/products/avr/ Atmel.com] Herstellerseiten
* [http://www.atmel.com/dyn/general/updates.asp Atmel.com updates] Liste der letzten Änderungen in Datenblättern und Beispielcode auf ATMEL.com (nicht nur für AVRs)
* [http://www.filmetrics.com Filmetrics Inc.] (Filmetrics manufactures affordable thin-film measurement instruments capable of measuring thin films from 3nm to 0.5mm in thickness.)

=== Information (Foren, Mailinglisten, Linksammlungen) ===
* [http://progforum.com Batronix Elektronik Forum] Gut besuchtes Forum für allgemeine Elektronik, Mikrocontroller und Programmierung
* [http://www.avrfreaks.net/ AVR Freaks] AVR Forum, Samples, Tutorials, User-Projekte, GCC für AVR (Registrierung empfohlen)
* [http://avr-asm.tripod.com Atmel AVR ASM Site]
* [http://www.mikrocontroller.net Mikrocontroller.net] - AVR Tutorials, Examples, LINKS, Forum (D)
* [http://www.openavr.org/ Openavr.org] "central repository of information for the various open source tools available for the development of software for Atmel's AVR family of 8-bit RISC microcontrollers"
* [http://www.omegav.ntnu.no/avr/resources.php3 Omega V's AVR Resource List]
* [http://www.omegav.ntnu.no/avr/newresources.php3 Omega V's AVR NEW Resource List]
* [http://www.ipass.net/hammill/newavr.htm Atmel AVR Embedded Microcontroller Resources]
* [http://members.tripod.com/Stelios_Cellar/AVR/AVR%20Info.html Stelios Cellar Atmel AVR Info Page] - Samples, Links
* [http://www.elektronik-projekt.de Elektronik Projekt] - Hauptthemen sind AVR und Roboter
* [http://www.microschematic.com/ AVR Microcontroller inside] (nett gemacht, Engl. Seite am 07-09-2008 nicht erreichbar)
* [http://electrons.psychogenic.com/avr/ Intro To AVR Microcontrollers] (noch(?) sehr wenig Information)
* [http://embeddedcompilers.com/avr/ Compilers for AVR family] (C, Pascal, Basic)
* [http://avrmicrocontrollers.com/ AVR Microcontrollers] - A web site about AVR microcontrollers
* [http://www.itwissen.info ITWissen.info] (gutes Lexikon)
* [http://www.evalboard.de Evalboard] (Linksammlung, Boarddesign, KnowHow, Tools)

=== Entwicklungswerkzeuge (Compiler/Assembler/Debugger/Tools/Libraries) ===

==== C ====
* [http://sourceforge.net/projects/winavr WinAVR] (pronounced "whenever") is a suite of executable, open source software development tools for the Atmel AVR series [for the] Windows platform" (includes GNU GCC)
* [http://sourceforge.net/projects/kontrollerlab KontrollerLab] is a free GPL open-source development environment based on KDE, using the avr-gcc, UISP and AVRDUDE
* [http://www.nongnu.org/avr-libc/ avr-libc] avr-gcc's "standard"-library

* [http://hubbard.engr.scu.edu/embedded/avr/avrlib/ Procyon AVRlib] a lot of device drivers and Visual-Studio link for avr-gcc
* [http://rod.info/avr.html rod.info on AVR] esp. for AVR GNU development tools setup under Linux
* [http://www.sisy.de SiSy AVR] - graphische Entwicklungsumgebung mit C/C++ Codegenerierung aus Struktogrammen und Klassendiagrammen
* [http://shop.embedit.de/product__206.php AtmanAVR C/C++ IDE]
* [http://www.iar.com IAR Embedded Workbench]
* [http://www.hpinfotech.com CodeVisionAVR] C-Compiler für AVRs mit Terminal
* [http://www.myAVR.de myAVRWorkpad] kompakte Entwicklungsumgebung für AVRs mit Terminal
* [http://www.amctools.com/vmlab.htm VMLab] komplette IDE mit Debugger und Simulator (auch Peripheriehardware)
* [http://www.forestmoon.com/Software/AvrIoDesigner/ AVR IO Designer] is a utility to generate initialization source code in C/C++ for the various devices, ports and registers of Atmel AVR processors. The intent is to allow the user to explore the devices specific to a selected processor and experiment with settings thru a user interface that assists in understanding the complexities involved. The user can also assign custom variable names to PORT IO pins thereby keeping track of the IO resources in use. These names are emitted in the generated code for use in the user’s program. (Windows .NET 2.0 erforderlich)
* [http://www.piconomic.co.za/avrlib/index.html Piconomic AVRLIB] is a collection of firmware for Atmel AVR microcontrollers. The aim is to share source code, experience and expertise (in the eye of the beholder) with the community of engineers, scientists and enthusiasts.

==== Assembler ====

* [http://avr-asm.tripod.com Atmel AVR ASM Site]
* [http://www.tavrasm.org/ tavrasm] - Toms Linux (Atmel) AVR Assembler
* [http://www.avr-asm-tutorial.net/gavrasm/index_de.html gavrasm] - Gerds Linux/Win/DOS AVR Assembler
* [http://avra.sourceforge.net/ avra] - avra ATMEL AVR Assembler für Linux, FreeBSD, AmigaOS und Win32
* [http://algrom.net/english.html Algorithm Builder] - graphische Makro-Assembler Entwicklungsumgebung
* [http://www.sisy.de SiSy AVR] - graphische Entwicklungsumgebung mit Assembler Codegenerierung aus Programmablaufplänen
* [http://www.sbprojects.com/sbasm/sbasm.htm SB-Assembler] - Freeware Cross-Assembler unter DOS. (6502, 6800, 6801, 6804, 6805, 6809, 68HC08, 68HC11, Z8, Z80, Z180, 8080, 8085, 8021, 8041, 8048, 8051, AVR, PIC1684,...)
* [http://www.myAVR.de myAVRWorkpad] kompakte Entwicklungsumgebung für AVRs mit Terminal

==== Disassembler ====

* [http://www.datarescue.com/idabase/ IDA-Pro] -Disassembler und Debugger für fast alle bekannten Prozessoren. Evaluation Version verfügbar. Tagline: ''The most advanced tool for Hostile Code Analysis, Vulnerability and Software Reverse Engineering''
* [http://avr.jassenbaum.de/ja-tools ReAVR] - Disassembler und ACXutility Binary Tool
* [http://www.visi.com/~dwinker/revava/ revava] - Disassembler
* [http://www.frozeneskimo.com/electronics/vavrdisasm-free-avr-disassembler/ vAVRdisasm] - Free AVR Disassembler
* [http://biew.sourceforge.net/en/biew.html BVIEW] is multiplatform portable viewer of binary files with built-in editor in binary, hexadecimal and disassembler modes. It includes '''AVR'''/Java/i86-i386-AMD64/ARM-XScale/PPC64 disassemblers, russian codepages convertor, full preview of formats - MZ, NE, PE, NLM, coff32, elf partial - a.out, LE, LX, PharLap; code navigator and more over. (GPL)

==== BASIC ====
* [http://www.mcselec.com/bascom-avr.htm Bascom AVR]
* [http://www.fastavr.com FastAVR] - und mit 'ASM' Ausgabe, Nokia3310 LCD Unterstützung
* [http://www.nettypes.de/mbasic mikrocontrollerBASIC Freeware] - mit Simulator für ATmega32, ATmega128 und C-CONTROL.
* [http://www.mikroe.com/en/compilers/mikrobasic/avr/ mikroBasic] - Comprehensive, stand-alone Basic compiler for AVR microcontrollers
* [http://home.arcor.de/EDAconsult/Page3/index.html?c~3.1 MCS BASIC-52] - Original-Übersetzung 1988 INTEL MCS BASIC-52 USERS MANUAL 220 Seiten frei Download als PDF
* [http://www.DieProjektseite.de Beetle-Basic] Leistungsfähiges Basic-Betriebssystem im AVR.

==== Pascal ====
* [http://www.e-lab.de AVRco Pascal Compiler] - AVR Pascal Compiler mit umfangreicher Funktionslibrary
* [http://www.mikroe.com/en/compilers/mikropascal/avr/ mikroPascal] - Comprehensive, stand-alone Pascal compiler for AVR microcontrollers

==== Forth ====
* [http://www.robo-forth.de www.robo-forth.de] - AVR Forth Compiler mit umfangreicher Funktionslibrary für Servos, Motore und Sensoren
* [http://amforth.sourceforge.net/ amforth] - Forth for Atmel ATmega micro controllers von Matthias Trute. [http://www.mikrocontroller.net/topic/55807#430816 Diskussion]

==== Java ====
* [http://www.harbaum.org/till/nanovm NanoVM] - Java VM für AVR-Mikrocontroller ([[NanoVM|deutsches Wiki]])

==== Ada ====
* [http://avr-ada.sourceforge.net/ AVR-Ada] - Ada Compiler innerhalb von GCC (GNAT) für AVR. Enthält eine kleine Laufzeitbibliothek ohne Tasking und ohne Exceptions.

==== Virgil ====
* [http://compilers.cs.ucla.edu/virgil/index.html The Virgil Programming Language] is designed for building robust, flexible, and scalable software systems on embedded hardware platforms. Virgil builds on ideas from object-oriented, statically typed languages like Java, providing a clean, consistent source language. Its compiler system provides an efficient implementation for resource-constrained environments.

==== LabVIEW ====
* http://www.ni.com/embedded/ Informationen zu LabVIEW, der graphischen Entwicklungsumgebung von National Instruments
* http://www.labviewforum.de/ Deutsches Labview-Forum

=== Tutorials und Beispiele ===
* [http://www.meinemullemaus.de/elektronik/avr_workshop/index.html AVR Mikrocontroller] Einfühung in AVR Mikrocontroller mit Nachbau des Spiels "Senso".
* [http://www.avrbeginners.net AVRBeginners.net] Beginners Guides to AVRs
* [http://electrons.psychogenic.com/avr/ electrons.psychgenic.com] AVR Microcontroller Section - Einführung und Tutorial (E)
* [http://www.wikidorf.de/reintechnisch/Inhalt/AVRProjekt-9V-LED-Lampe reintechnisch.de] AVR Tutorial: 9V-LED-Lampe
* [http://digitaltechnik.mschoeffler.de digitaltechnik.mschoeffler.de] Einführung in die Grundlagen der Digitaltechnik
* [http://arm.hsz-t.ch arm.hsz-t.ch] Einfühung in ARM7 Mikrocontroller und uClinux.
* [http://www.schaltungsforum.de Das Schaltungsforum] ist eine Seite für Anfänger und Profis welche ständig mit Tutorials erweitert wird. Stellt Eure Projekte online. Die Seite befindet noch im Aufbau und Eure Mithilfe ist erwünscht.
* [http://www.mikrocontrollerspielwiese.de mikrocontrollerspielwiese.de] ist eine Seite, die an Anfänger gerichtet ist und Experimente und fertige Projekte komplett mit Code und Eagle-Dokumenten zur Verfügung stellt.
* [http://www.earthshinedesign.co.uk/ASKManual/Site/ASKManual.html The Complete Beginners Guide to the Arduino]
* [http://www.codeproject.com/KB/system/ArduinoVB.aspx Arduino with Visual Basic] by Carl Morey auf codeproject.com
* [http://www.elo-web.de/elo/mikrocontroller-und-programmierung/avr-anwendungen ELO-AVR-Anwendungen] bietet eine wachsende Sammlung kleinerer AVR-Projekte, überwiegend für die ATTiny-Serie.
* [http://www.schramm-software.de/tipps/ AVR-Tipps] Programmier-Tipps und AVR-Experimente.

==== C ====
* [[AVR-GCC-Tutorial]]
* [http://www.smileymicros.com/QuickStartGuide.pdf Quick Start Guide for using the WinAVR Compiler with ATMEL's AVR Butterfly] ([http://www.smileymicros.com www.smileymicros.com], PDF)
* [http://www.piconomic.co.za/avr.html Piconomic Design Atmel AVR Course] is for the engineer who wants to switch to the 8-bit Atmel AVR microcontroller and learns by example. C language and compiler experience is a prerequisite. (Beim Nachbau des AVR-Boards '''Copyright notice''' beachten!)
* [http://www.avrtutor.com/tutorial/thermo/contents.htm avrtutor] - an attempt to provide a real tutorial for the ATMEL AVR microcontrollers.
* [http://www.sparkfun.com/commerce/present.php?p=BEE-1-PowerSupply Spark Fun Electronics] - Beginning Embedded Electronics (Atmega8, englisch)
* [http://metku.net/index.html?path=articles/microcontroller-part-1/index_eng metku.net] - How to get started with microcontrollers (ATtiny45, Steckbrett)

==== Assembler ====
* [http://avr-asm.tripod.com Atmel AVR ASM Site]
* [http://www.avr-asm-tutorial.net Atmel AVR Microcontroller Assembler Tutorial] (D)
* [http://www.itee.uq.edu.au/~cse/_atmel/AVR_Studio_Tutorial/ Einstieg in AVRStudio 4] (viele Abbildungen, Engl.)
* [[AVR-Studio]]

==== Bascom ====
* [http://www.mcselec.com/ MCS Elektronik] BASCOM AVR Demo zum Download

==== Pascal ====
* [http://www.elektronik-projekt.de/content/download/avrco_tut2.pdf AVRco Pascal Tutorial] - von Markus
* [http://www.ibrtses.com/embedded/avr.html ein paar Seiten zum AVR] (ASM und Pascal) von ibrt

=== Hardware (Prototypen-Platinen-Boards etc.) ===

* [http://retrodan.tripod.com Atmel AVR Butterfly Site]
* [http://www.simplesign.de simplesign.de] Controller Module, Bausätze. Auf Kundenwünsche wird sehr gerne eingegangen -> Link geht nicht (13.7.2009)
* [http://www.fox4you.cc Austria] Development Tools for ATMEL ATmega Microcontrollers Connections via USB and LAN
* [http://www.kanda.com Kanda] Starter Kits and Development Tools for different Microcontrollers
* [http://www.dontronics.com Dontronics] Starter Kits and Development Tools for different Microcontrollers, Linkpages for AVR and PIC
* [http://www.mikrocontroller.com mikrocontroller.com] u.a. Platine AVR-Ctrl, AVR-Webserver (D)
* [http://mikrocontroller.cco-ev.de/eng/ AVR webserver] RTL8019, 3COM (E)
* [http://www.microcontroller-starterkits.de Microcontroller-Starterkits] Starter Kits for different Microcontrollers (D)
* [http://www.olimex.com Olimex Ltd.] DevelopmentBoards and Tools
* [http://www.krause-robotik.de Krause Robotik] Controller Boards & Zubehör
* [http://www.robotikhardware.de robotikhardware.de] Controller Boards
* [http://www.ssv-embedded.de SSV Embedded Systems] 32-bit Mikrocontrollermodule und -boards, Starter Kits etc.
* [http://shop.embedit.de/browse_002_21__.php Embedit] Mikrocontrollermodule und -boards
* [http://www.display3000.com Display3000] Farbdisplays, Mikrocontrollermodule und -boards mit TFT-Farbdisplays; Experimentierplatinen und Ansteuerplatinen für TFT Farbdisplays
* [http://www.glyn.de GLYN High-Tech Distribution] Mikrocontroller Applikationen, TFT-Displays, LCD-Anzeigen, Memory Cards
* [http://www.myavr.de myAVR] Einsteigerboards und Zubehör
* [http://www.siphec.com/ SIPHEC] Development Boards für AVR, MSP430, USB
* [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=OA==&a=MTY5OTgxOTk=&w=OTk4OTY4&ts=0 ATMEL Evaluations-Board Bausatz] ([http://www.pollin.de/shop/downloads/D810038B.PDF PDF]) und [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=OA==&a=MzU5OTgxOTk=&w=OTk4OTY4&ts=0 ATMEL Funk-Evaluations-Board Bausatz] ([http://www.pollin.de/shop/downloads/D810046B.PDF PDF]) von Pollin
* [http://www.lochraster.org/etherrape/ Etherrape] Atmaga 644 mit Ethernet und TCP/IP als Bausatz.
* [http://www.ic-board.de/index.php?cat=c4_Programmer.html AVR Programmieradapter],[http://www.ic-board.de/index.php?cat=c3_Funkmodule.html ZigBee-ready Funkmodule/Funk-USB-Sticks] und [http://www.ic-board.de/index.php?cat=c13_ICradio-Bundles.html Funk Starterkits] von In-Circuit
* [http://www.ic-board.de/index.php?cat=c2_ICnova-Module.html AVR32 AP7000 Linux Board] mit 2xEthernet, TFT, Audio, SDCARD, USB-Host/Devive, Funk...
* [http://www.freeduino.org/ Freeduino.org] - Riesige Linksammlung zu dem '''Ardunio'''(R) AVR-Board (Kit) und dessen Clones und Mutanten (DIY oder Kit)
* [http://www.freeduino.de/ freeduino.de] - Anleitungen und Tutorials, Arduino Wiki, Blog, Tools in Deutsch
* [http://www.das-labor.org/wiki/Laborboard Das Laborboard] von das-labor.org (DIY)
* [http://avrboards.com/ AVR Boards] - Some information about AVR microcontrollers and development boards
* [http://six.media.mit.edu:8080/6 number six] - Open Source Design, Atmega32. Alle Pins sind auf eine 2x20 Pol Wannenstiftleiste herausgeführt.
* http://www.maares.de/tools USB Memory Stick am AVR Butterfly. AVR Butterfly Trägerplatine zum Anschluß von VDRIVE, VMUSIC, RFM12.
* [http://www.wiring.org.co/ Wiring] is an open source programming environment and electronics i/o board for exploring the electronic arts, tangible media, teaching and learning computer programming and prototyping with electronics.
* [http://binaryideas.blogspot.com/2008/08/project-quick-avr-part-3_26.html QuickAVR] - DIY Prototypenboard zum Aufstecken auf ein Breadboard (ATmega168, 16 MHz, no SMD)
* [http://www.chip45.com/ chip45] Atmel AVR Module und Boards mit USB, RS232/485, CAN, Ethernet, Funkmodule, sowie ISP Programmieradapter.
* [http://www.rakers.de/catalog Dr. Rakers] <b>AVR Boards und Experimentierplatinen</b> mit USB, Ethernet, RS232, CAN, LCD etc. in hochwertiger Qualität zu günstigen Preisen.
* [http://nibo.nicai-systems.de Roboterbausatz Nibo] - autonomer <b>Roboter</b> mit einem ATmega128 und einem ATmega88
* [http://www.aevum-mechatronik.de Modularis] - AVR Mikrocontroller-Boards (z.T. mit Zusatz-Speicher und USB) die über Flachbandkabel erweitert werden können. Es gibt bis jetzt Zubehör-Module mit Taster, Motor H-Brücke, XBee und Winkelsensor.
* [http://www.comsys.ch/Tern-Embedded-Systeme.151.0.html Tern Embedded Systeme] - C++ programmierbare Kontroller mit 586, i386EX, Am188ES und V25 Prozessoren, Entwicklungstools.
* [http://www.schramm-software.de/bausatz/ Schramm-Software] - AVR Mikrocontroller-Bausätze

=== Programmierhard- und Software ===
* [http://www.obdev.at/products/avrusb/avrdoper.html AVR-Doper] Einfach nachzubauender, STK500-kompatibler Programmer mit USB-Anschluss. Beherrscht auch HVSP, nicht jedoch HVPP. Open Source.
* [http://www.bsdhome.com/avrdude/ AVRDUDE] AVR ISP-Programmerierwerkzeug für Unix/Linux/BSD und Windows. Kommandozeile [http://sourceforge.net/projects/avrdude-gui/ (oder mit GUI)], AVR Butterfly-Unterstützung
* [http://www.lancos.com/prog.html PonyProg] neben AVR für diverse seriell programmierbare Bauteile (Grafische Nutzeroberfläche und Kommandozeile), siehe auch [[Pony-Prog Tutorial]]
* [http://savannah.nongnu.org/projects/uisp/ uisp] AVR ISP-Programmierwerkzeug für Unix/Linux/BSD und Windows (Kommandozeile)
* [http://www.myplace.nu/avr/yaap/ yaap]
* [http://www.xs4all.nl/~sbolt/e-index.html SP12]
* [http://www.mikrocontroller-projekte.de/Mikrocontroller/AVR-Prog/AVR-Programmer.html AVR910 kompatibler Programmer] mit aktueller, beschleunigter Firmware.
* [http://www.der-hammer.info/hvprog STK500 kompatibler Programmer] als Nachbauprojekt. Siehe auch [[STK500]]
* [http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=73&products_id=41 Preiswerter Standard ISP (STK200 kompatibel)]
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/evertool/ Evertool] kombinierter ISP & [[JTAG]] Programmer (kompatibel zum "original" Atmel AVRISP und Atmel JTAGICE)
* [http://www.olimex.com Olimex] (Bulgarischer Anbieter) Kostengünstig
* [http://www.avr-projekte.de/isp.htm AVR910-USB Programmer] incl. USB-Modul und USB->Seriell Wandler
*[http://www.fischl.de/usbasp/ USBasp] – USB-Programmer bestehend aus ATmega8 (kein spezieller USB-Chip notwendig)
* [http://home.arcor.de/bernhard.michelis Amadeus-USB] - Highspeed-Programmer für PIC18, PIC24, dsPIC30, PIC32, dsPIC33 und AVR. Bietet auch Möglichkeiten zur Fehlersuche.
* [http://www.e-dsp.com Signalgenerator] - Signalgenerator software
* [http://www.myavr.de/shop/artikel.php?artID=42 mySmartUSB] - USB Programmer und USB-UART-Bridge, AVR910 und AVR911 kompatibel
* [http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=73&products_id=161 USB-Programmer für Bascom Programmierer]
* [http://www.virtualserialport.com/ Virtual Serial Port] Software for serial port communication and null-modem emulation
* [http://www.ic-board.de/index.php?cat=c4_Programmer.html AVR Programmieradapter und JTAGICE MKII]
* [http://www.helmix.at/hapsim/index.htm HAPSIM graphischer Simulator ] zu graphischen Simulation von Tasten /LED /LCD und Terminal in AVR Studio Freeware !!!
* [http://www.ic-board.de/index.php?cat=c4_Programmer.html AVR Programmieradapter und JTAGICE MKII]
* [http://www.myavr.de/download.php?suchwort=ProgTool myAVR ProgTool] nette Programmieroberfläche (free)
* [http://b9.com/elect/avr/kavrcalc/ KAVRCalc] is a free calculator to assist in programming AVR microcontrollers (Baudrate, Watchdog, Timer, ...)
* [http://www.chip45.com/CrispAVR-USB CrispAVR-USB] STK500 V2 kompatibler ISP Adapter mit USB Schnittstelle für Atmel AVR Mikrocontroller (1,8V-5,5V).
* [http://ucom-ir.nicai-systems.de UCOM-IR] - Programmieradapter mit USB Schnittstelle (AT90USB162) und IR-Sender/Empfänger, STK500 V2 kompatibel
* [http://www.anagate.de/products/programmers.htm AnaGate Programmer] Serielle Programmer mit LAN-Anschluss für I2C und SPI inkl. Programmier-API für Windows/Linux (Shop)

=== Projekte und Quellcodebibliotheken ===

====Bibliotheken====
* [http://www.nongnu.org/avr-libc/ AVR Libc]
* [http://hubbard.engr.scu.edu/embedded/avr/avrlib/docs/html/index.html Procyon AVRlib]
* [http://homepage.hispeed.ch/peterfleury Peter Fleury's Pages] - UART / LCD (HD44780) / I²C (TWI)/ AVR-GCC Bibliotheken, STK500v2 Bootloader
*[http://sourceforge.net/projects/avrfix Fixed Point Library Based on ISO/IEC Standard DTR 18037 for Atmel AVR microcontrollers, u.a. Cordic-Algorithmen] und [http://www.enti.it.uc3m.es/wises07/presentations/session2/05%20-%20Fixed%20Point%20Library%20According%20to%20ISOIEC%20Standard%20DTR%2018037%20for%20Atmel%20AVR%20ProcessorsWISES07-fixedpointlibrary%20-%20Elmenreich.pdf Kurzbeschreibung dazu als Powerpoint-PDF TU Wien Febr. 2007]

==== Betriebssysteme & Co. ====
* [http://www.tinyos.net/ TinyOS] - Komponentenbasiertes Betriebssystem für Sensorknoten. Bringt eigene C-ähnliche Hochsprache nesC mit.
* [http://www.chris.obyrne.com/yavrtos/ YAVRTOS] - Yet Another Atmel® AVR® Real-Time Operating System von Chris O'Byrne (C, Atmega32, GPL3 Lizenz)
* [http://www.freertos.org/ FreeRTOS] is a portable, open source, mini Real Time Kernel - a free to download and royalty free RTOS that can be used in commercial applications. (AVR, MSP430, PIC, ARM7, ...)
* [http://www.barello.net/avrx/index.htm AvrX Real Time Kernel] (IAR ASM oder IAR/GCC C, GPL2 Lizenz)
* [http://scmrtos.sourceforge.net/ scmRTOS] - Single-Chip Microcontroller Real-Time Operating System (C++, AVR, MSP430, Blackfin, ARM7, FR (Fujitsu, [http://www.opensource.org/licenses/mit-license.php MIT Lizenz]).
* [http://www.circuitcellar.com/avr2004/DA3650.html csRTOS] - cooperative single-stack RTOS aus dem Circuit Cellar AVR 2004 Design Contest. [http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=987&item_type=project csRTOS port to ATmega32] und [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=50743&start=all&postdays=0&postorder=asc Diskussion] auf www.avrfreaks.net führte zur Weiterentwicklung als [http://www.mtcnet.net/~henryvm/4AvrOS/ 4AvrOS] - cooperative scheduler
* [http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_type=project&item_id=230 OPEX] - freeware cooperative scheduler with lots of calendar and I/O functions von Steve Childress (Download auf www.avrfreaks.net ggf. Registrierung notwendig)
* [http://www.mikrocontroller.net/topic/12176#79672 Scheduler] von Peter Dannegger
* [http://www.mikrocontroller.net/topic/25087#186454 RTC-Scheduler] von ape
* [http://www.sics.se/~adam/pt/ Protothreads] - Lightweight, Stackless Threads in C (open source BSD-style license)
* [http://www.micrium.com/products/rtos/kernel/rtos.html uC/OS-II] is a real time operating system developed by Jean J. Labrosse. You can obtain the source code for the OS by buying Labrosse's excellent book ''MicroC/OS-II The Real-Time Kernel (2nd edition)''. [http://www.ee.lut.fi/staff/Julius.Luukko/ucos-ii/avr/index.shtml Port for AVR (gcc 3.x)] and [http://www.myplace.nu/avr/ucos/index.htm AVR (gcc 2.x)].
* [http://freshmeat.net/projects/qp/ QP] is a lightweight, portable framework/RTOS for embedded systems (ARM, Cortex-M3, 8051, AVR, MSP430, M16C, HC08, NiosII, and x86). GPL (und kommerzielle Lizenz verfügbar)
* [http://www.femtoos.org/ Femto OS] von Ruud Vlaming ist ein preemptives Betriebssystem für die kleinsten Mikrocontroller aus der AVR Serie bis ca. 16 KB ROM und 1 KB RAM. Spezielle Targets sind: ATtiny861/461/261. Geschrieben in C. Freie Software, GPLv3.
* [http://www.projects-lab.com/?p=344 kaOS] is a real-time, multithreaded, preemptive operating system for the ATmega32 microcontroller, which loads and executes programs from a Secure Digital or MMC card. Authors Nicholas Clark & Adam Liechty. (Circuit Cellar AVR Wettbewerb 2006)
* [http://helium.sourceforge.net/ Helium] is a minimalistic real-time kernel for the HC(S)08 core by Freescale and Atmel AVR.
* [http://dev.bertos.org/ BeRTOS] is a completely free, open source, real time operating system (RTOS) suitable for embedded platforms. Runs on many microprocessors and microcontrollers, ranging from 8 bits to 32 bits CPUs and even PCs.

==== Projektsammlungen ====

* [http://www.DieProjektseite.de Die Elektronik-Projektseite und Heimat des BasicBeetle] Hauptthema ist der BasicBeetle. Ein modularer, leistungsfähiger, in Basic programmierbarer Mikrorechner speziell für Steuerungen. Mit vielen Programmen, Tiipps und Tricks, Informationen ...
* [http://www.Happy-Micro.de Happy-Micro.de] Die Internetsite für Hobbyelektroniker, Mikrocontroller-Anwender, Programmierer und alle, die Spaß an Computern und Elektronik haben. Bei Happy-Micro.de steht der Spaß am Entwickeln von Programmen und Schaltungen im Vordergrund. Jeder Benutzer hat die Möglichkeit auch als Autor mitzumachen und seine Schaltungen oder Programme zu veröffentlichen. Freier Bilderdownload für die eigene Homepage.
* [http://iwenzo.de Elektronik und Informationen] Wissenswertes aus der Unterhaltungselektronik..
* [http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/ Cornell University ECE 476 Microcontroller Design Final Projects]
* [http://www.serasidis.gr/ Serasidis Vasilis' AVRsite] u.a. GLCD, SMS, PAL
* [http://www.riccibitti.com Alberto Ricci Bitti] u.a. PAL Video-Interface
* [http://www.ulrichradig.de Mikrocontroller and more] AVR - Projekte (Ethernet, LCD, Relaiskarte usw.) und mehr
* [http://home.arcor.de/burkhard-john/index.html Burkhard John] (D)
* [http://home.planet.nl/~meurs274/ AVRmicrocontrollerprojects] u.a. Text-LCD, Schrittmotor, Thermometer
* [http://hem.bredband.net/robinstridh/ Robin Stridh] Rotor-Anzeige, Video-Interface
* [http://www.dertien.dds.nl/content/avrprojects.html dertien.dds.nl AVR-Projects]
* [http://www.microsps.com MicroSPS.com] Grafische Programmierung des AVR mit EAGLE
* [http://www.h-mpeg.de h-mpeg Festplatten mp3 Player] IDE Ansteuerung, IDE Filesystem, LCD Ansteuerung etc. in 8K Code. Quelltext unter GPL
* [http://www.embedtronics.com/ embedtronics.com]
* [http://www.siwawi.arubi.uni-kl.de/avr_projects M. Thomas' AVR Projekte] untern Anderem AVR Butterfly avr-gcc-port, DB101 gcc-port, BC100 gcc-port, Bootloader, Programmier- und Debughardware, Software-UART, DS1820-Lib., experimentelle avrdude-Versionen, AVR und CAN mit MCP2515 
* [http://www.mictronics.de Michaels Electronic Projects] AVR Projekte (EN) - ua. Sony/Becker CD/MD Wechsler Emulator, RDS-Decoder, GPS Infos, OBD J1850 VPW Interface, USB<>CAN Bus Interface. Informationen zu CD Wechsler Protokollen. MP3stick - MP3 Player mit ATmega128, color LCD, SD/MMC Karte und VS1011b
* [http://www.stahlbucht.de/elektronik/node13/ node13] modulares AVR 8515 Projekt: eine Controller-Platine, an die sich weitere Ein-Ausgabemodule (Tastenfeld, LEDs, LCD-Modul) anschliessen lassen
* [http://www.mikrocontroller-projekte.de www.mikrocontroller-projekte.de] Diverse Projekte mit AVR Controllern. AVR910 Programmer, Testboard und Modellbauelektronik
* [http://www.roboternetz.de/phpBB2 Roboternetz-Mikrocontroller Projekte.de] Diverse Projekte mit AVR und anderen Controllern, insbesondere im Bereich Robotik
* [http://www.avr-projekte.de AVR-Projekte.de] Belichtungstimer, FT232RL Schaltungen,LED-Fading über Fernbedienung, HD44780-LCD über USB und Seriell, AVR910-USB Programmer, Basteleien: Ätzmaschine,Kompressor.
* [http://openeeg.sourceforge.net/ openeeg.sourceforge.net] Das OpenEEG Projekt befasst sich mit der Entwicklung eines preiswerten Elektro-Enzephalographie (EEG) Geräts und dessen freier Steuersoftware zur Messung elektrischer Gehirnströme. Sein µPC-Herz ist ein AT90S4433 bzw. ein ATmega8. Ziel sind auch verschiedene EEG Anwendungen z.B. im Bereich mentaler Trainingsmethoden (Neurofeedback).
* [http://www.amateurfunkbasteln.de/ www.amateurfunkbasteln.de] Seite von Michael Wöste (DL1DMW) u.a. CPU-Board mit AT89C2051, AT89C4051 oder AVR AT90S2313, CPU-Board mit Atmel AT90S8535, Experimentierplatine mit ATmega103, Programmer für AT89C2051/AT89C4051, 32-Kanal-Logik-Analysator bis 40 MHz (Entwurf von David L. Jones)
* [http://www.atmel.com/dyn/products/app_notes.asp?family_id=607 Atmel - AVR 8-Bit RISC - Application Notes] Anwendungshinweise und Beispiele vom Hersteller
* [http://www.projects.cappels.org/ Dick Cappels' Project Pages]
* [http://see-by-touch.sourceforge.net/index.html SeebyTouch - Blinden-Seh-Ersatzsystem] Computerbilder fühlen durch ein einfaches Gerät (Bauanleitung) und freier Software (für 10 Betriebssysteme) - eine neue Erfahrung für alle
* [http://www.loetstelle.net www.loetstelle.net] Verschiedene kleinere AVR-Projekte rund um LEDs, z.B. RGB Dimmer, Moodlight. Diverse Elektronikprojekte und Grundlagen
* [http://www.dietmar-weisser.de Selbstbauprojekte Elektronik] kleine Sammlung von Elektronikprojekten zum Thema Leiterplattenfertigung, Hochfrequenztechnik und Mikrocontroller.
* [http://www.myplace.nu/avr/ Jesper's AVR pages] Yampp MP3 Player, Yaap Programmer, DDS mit 2313+R2R, Gitarrentuner, Frequenzzähler.
* [http://www.microsyl.com/ MicroSyl MCU] MP3 Player, MegaLoad, HCLoad, Propeller Clock, Freq Meter, BarCode Reader, Door Bell, OneWire Lib, Text LCD Lib, Graph LCD Lib, Nokia LCD Lib, Led Sign with MMC MemoryCard, Intercom
* [http://www.jeroen.homeunix.net/ http://www.jeroen.homeunix.net/] Aufbau eines elektronischen Rouletts auf basis eines AVRs
* [http://thomaspfeifer.net thomaspfeifer.net] Reflow-Ofen, Laminator-Temperaturregelung, USB-Atmel-Programmer, SMD-Tricks u.v.m.
* [http://www.scienceprog.com Scienceprog - embedded theory and projects] - AVR, ARM theory and projects
* [http://www.iuse.org Hausautomatisierung] - CAN-Bus mit ATmega32-Controllern und Bedienfeldern, Admin-Tools zum Updaten via CAN, Traffic Dumper etc.
* [http://www.myevertool.de AVRSAM] - AT91SAM7S Header Board annährend 100% Pinkompatibel zu den folgenden AVR Mikrocontroller: AT90S8535 / ATMEGA8535 / ATMEGA16 / ATMEGA32
* [http://members.aon.at/hausbus Hausbus Home] - Hausbus-Projekt unter Verwendung von ATmega8, ATtiny13 und ATmega128
* [http://www.thomas-wedemeyer.de/elektronik/AVR/avr-dcf-clock.html AVR-DCF-Clock] - DCF-Uhr mit bunter LED-Anzeige - ATmega8
* [http://www.grasbon.de/genuhr.html GenuhR] - DCF-Funkuhr / Wecker/ Timer mit LED-Punktmatrixanzeige. Das Projekt beschreibt den Aufbau des kompletten Gerätes beginnend beim Schaltplan bis hin zur Montage in ein Gehäuse.
* [http://www.avrguide.com/ AVR Projektsammlung] bei www.avrguide.com
* AVR Synth http://www.elby-designs.com/avrsynth/avrsyn-about.htm http://www.jarek-synth.strona.pl/
* [http://elm-chan.org/he_e.html Electronic Lives Manufacturing] - Aufbauten in Fädeldrahttechnik, tlw. auf Japanisch, aber mit englischen Sourcecodes
* AVR Synthesizer http://www.avrx.se/
* [http://freenet-homepage.de/wedis-bastelecke/ Wedis-Bastelecke] - Modellbahn DCC-Servo-Zubehördecoder DCC Servo Decoder mit ATmega8 / Servo Differenzierbaugruppe für Modellbau
* http://www.electronicspit.com - Verschiedene Elektronikprojekte (LED-Matrix, PAL-Video)
* http://web.archive.org/web/20050415222337/http://www.hebel23.de/ RDS RADIO: ATMega32, TEA5757, T6963C, TDA7330B in C
* [http://www.gasenzer.dk Analog/Digital and MPU Eletronic Projects] PAL/VGA Terminal, CallerID, Ethernet, Wireless Bridge, LPC2214, AT91RM9200, Sony Unilink Controlled Wireless MP3 Player.
* [http://www.circuitcellar.com/avr2004/ Circuit Cellar AVR Design Contest 2004] mit Projektbeschreibungen
* [http://www.circuitcellar.com/avr2006/ Circuit Cellar AVR Design Contest 2006] mit Projektbeschreibungen
* [http://www.heesch.net/avr.aspx www.heesch.net/avr.aspx] AVR Mikrokontroller Projekte, z.B. IDE-Interface, DS1821 Thermometer, Morse-Dekoder
* [http://www.schaltungsforum.de Das Schaltungsforum] ist eine Seite für Anfänger und Profis welche ständig mit Tutorials erweitert wird. Stellt Eure Projekte online. Die Seite befindet noch im Aufbau und Eure Mithilfe ist erwünscht.
* [http://avrprojekte.de/] Viele Projekte mit LEDs(LED-Matrixen) und AVRs
* [http://arduino.milkcrate.com.au/ little-scale's arduino page]

==== Schnittstellen ====
===== TCP/IP =====
* [http://www.laskater.com/projects/uipAVR.htm TCP/IP Stack für AVR] mit Realtek RTL8019AS oder Axis AX88796 Netzwerk-Chips (open source für avr-gcc und Imagecraft). Passende Hardware in [http://www.edtp.com/ diesem online-shop]
* [http://www.ethernut.de Ethernut] - AVR based Hardware with Ethernet-Interface, Multithreading OS, Software and Hardwaredesign is free
* [http://www.ethersex.de/index.php/Feature_Liste Ethersex] - Trotz des bescheuerten Namens sehr empfehlenswert. Viele flexibel einbindbare Module für diverse Hardware.
* [http://wiki.neo-guerillaz.de OpenMCP] Bekanntes Board auf Basis des ATmega2561 und ENC28j60. Läuft auf auf dem AVR-NETIO und dem myAVR.
* [http://www.cesko.host.sk/IgorPlugUDP/IgorPlug-UDP%20(AVR)_eng.htm IgorPlug-UDP AVR] - Ethernet & UDP/IP in Software implementiert
* [http://members.home.nl/bzijlstra/software/examples/RTL8019as.htm] RTL8019 Bascom
* [http://members.home.nl/bzijlstra/software/examples/RTL8019as.htm AVR und RTL8019]
* [http://avr.auctionant.de/avr-ip-webcam AVR IP Webcam]
* http://mikrocontroller.cco-ev.de/de/webcam.php
* [http://avr.auctionant.de/avrETH1/ avrETH1 - Webserver mit enc28j60 und Webcam-Support]
* [http://www.sics.se/~adam/uip/ uIP-Stack, Teil des Contiki OS]
* [http://www.harbaum.org/till/spi2cf/ WLAN-Implementierung auf Basis einer PRISM-CF-Karte und uIP]
* http://www.circuitcellar.com/AVR2006/winners/DE/AT2581.htm MEGA128(CAN) PCMCIA
* [http://www.ic-board.de/index.php?cat=c2_ICnova-Module.html AVR32 AP7000 Linux Board] mit 2xEthernet, TFT, Audio, SDCARD, USB-Host/Devive, Funk...
* [https://berlin.ccc.de/wiki/AVR-Board_mit_Ethernet AVR-Board mit Ethernet mit dem ENC28J60 von Microchip]
* [http://www.roland-riegel.de/mega-eth/ AVR-Ethernet-Board mit extra SRAM, SD/MMC, USB und zugehöriger Software]

===== CAN =====
* [http://www.canathome.de/ Can@Home] - CAN als "Installationsbus", u.a. mit AVRs (D)
* [http://www.iuse.org/ www.iuse.org] - Hausautomatisierung auf CAN Basis
* [http://www.port.de/ www.port.de] - Professionelle CAN/CANopen Entwicklungswerkzeuge
* [http://can-wiki.info CAN-WIKI] - spezielle Wiki Site für CAN bus (Englisch)
* [[CAN-Bus]] - Eintrag in diesem Wiki
* [[CAN als Hausbus]] - Eintrag in diesem Wiki
* [http://www.canhack.de/ www.canhack.de] - Ein Forum, dass sich mit dem CAN bus im Auto beschäftigt
* [http://www.edevices.lt/ www.edevices.lt ] - USB2CAN inexpensive USB to CAN bus converter

===== USB =====
* [http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm Igor-Plug] - USB Device interface in AVR Firmware - no extra Interface IC needed, read the License
* [http://www.obdev.at/products/vusb/index-de.html V-USB] – USB-Implementation in C nach gleichem Prinzip wie Igor-Plug, aber einfacher zu verwenden, GPL-ähnliche Lizenz (Nutzung des Projekts ''erfordert'' Veröffentlichung), englisch kommentierter Code
* [http://www.xs4all.nl/~dicks/avr/usbtiny/ USBTiny] – weitere Software-USB-Implementierung in C; sehr ähnlich AVR-USB; steht aber unter GPL; relativ wenige Beispiele
* MJoy USB Joystick Controller on AVR ATmega8
* [http://www.ime.jku.at/tusb/ TUSB3210-Controller, HID, LIBUSB] Ein Projektseminar, in dem es darum ging, die USB-Schnittstelle des TUSB3210 zu aktivieren und die Daten eines ADC an den PC zu senden. USB-Implementierung für µC und PC.
* [http://www.b-redemann.de Steuern und Messen mit USB - FT232, 245 und 2232] Das aktuelle Buch zu den USB-Controllern von FTDI. Viele Beispielprogramme in C, zwei Projektbeschreibungen: I²C-Bus mit LM75A und ein Web-Projekt. Bauteilesatz und USB-Modul mit dem FT2232 zum schnellen Einstieg in die Thematik. Buch / Teilesatz über Segor oder dieser Seite erhältlich.
* [http://www.eltima.com/products/usb-over-ethernet/ USB to Ehternet Connector] - Share your USB devices via LAN/Internet
* [http://www.ixbat.de Viele kleine USB Projekte] Rund um die Bibliothek usbn2mc http://usbn2mc.berlios.de. Dies ist eine einfache Bibliothek für den USBN9604/03 von National Semiconductor
* [http://www.rahand.eu Mega8D12] - Schritt für Schritt zum virtuellen COM-Port. Ein Einsteiger-Tutorial zur CDC-Klasse mit Schaltung und Firmware (ATmega8 und PDIUSBD12).
* http://www.maares.de/tools USB_ISO: Isolierter Schnittstellenwandler USB auf RS232 (TTL) mit FT232RL und ADUM1402. Galvanische Trennung für das Zielsystem.

===== DMX512 =====
* [http://Dworkin-DMX.de Konverter RS232 zum DMX512] Steuerung DMX-fähigen Geräten mit einem PC. Es gibt Low cost Variante zum selber basteln.
* [http://www.hoelscher-hi.de/hendrik/light/profile.htm Hennes Sites] Bauanleitungen für DMX-Dimmerpacks, DMX-Switchpacks, PWM-Controller, ... Tutorial für Senden und Empfangen von DMX-Daten mit AVRs.
* [http://www.lj-skinny-development.de/lj2000/ DMX Lichtanlage im Selbstbau] Projekt für den Selbstbau einer kompletten Lichtanlage zur Steuerung über DMX. Projekt beinhaltet alles was man für den Betrieb einer eigenen Lichtanlage benötigt (Mischpult, Steuersoftware, Dimmer, Scanner mit Iris, Shutter-Dimmer, 2 rotierenden Goborädern, 2 Farbrädern, CMY-Farbmischeinheit, Prisma, Fokus ...).
* [http://digital-enlightenment.de Digital Enlightenment ]Verschiedene DMX-Selbstbauprojekte

===== PS2 =====
* [http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1086&item_type=project&timestamp=2007-09-04%2018:34:41 PC keyboard to an AVR]

===== LANC =====
* [http://dsc.ijs.si/3dlancmaster/ 3D LANC Master from Damir Vrancic] is a device which keeps in synchronisation some of Sony camcorders by using LANC (CONTROL-L, ACC) protocol. (Open Hardware + Open Source, Atmega8).
* [http://jochendony.homeip.net/content/view/22/26/ LANC Lib] for AVRGCC. Read and write LANC commands.
* [http://blog.makezine.com/archive/2008/12/controlling_sony_camcorders_with_th.html Controlling Sony camcorders with the Arduino]

===== MMC/SD-Card =====
* [http://www.roland-riegel.de/sd-reader/index.html MMC/SD card reader example application] von Roland Riegel (Atmega8, Atmega168 für FAT16)
* [http://www.captain.at/electronic-atmega-mmc.php MMC Flash] bzw. [http://www.captain.at/electronic-atmega-sd-card.php SD Flash ] Memory Extension für Atmegas von Captain. (Atmega16, Atmega32)
* http://arm.hsz-t.ch MMC, SD, SDHC Kartentreiber für ARM7 Mikrocontroller
* [http://www.mikrocontroller.net/articles/FAT32 Wiki und FAT16/32 Bibliothek für atmega]

==== LC-Displays ====

===== Text (character-mode) HD44870 =====
* [http://jump.to/fleury P.Fleury]
* avrfreaks Projekt 59 (Chris E.) und andere
* Procyon avrlib v. Pascal Slang (GPL)
* Bray
* [http://www.sprut.de/electronic/lcd/index.htm Spruts LCD-Seite]
* [http://elm-chan.org/docs/lcd/lcd3v.html Standard-LCD auf 3V betreiben (eng)]
* [http://www.harbaum.org/till/lcd2usb LCD2USB, LCD mit AVR am USB betreiben]

===== Grafik T6963C etc. =====

* http://www.holger-klabunde.de/avr/avrboard.htm#t6963
* [[Projekt T6963-LCD-Ansteuerung]] nur PC, keine Änderung seit Juli 2006
* avrfreaks.net - TOSHIBA_LCD_T6963C, AVR Graphics
* http://www.mikrocontroller.net/topic/48456 C
* http://www.mikrocontroller.net/topic/54563 C
* http://www.mikrocontroller.net/topic/48584 ASM
* [http://passworld.co.jp/ForumMSP430/viewtopic.php?t=47 Grafik LCDs] - 128 x 112 Grayscale für MSP430 und andere uCs.
* http://www.display3000.com/ Farb-TFT-Module inkl. Mikrocontroller (ATMega128; ATMega2561 und AT90CAN128)
* [http://www.tklinux.de/sed1330.html SED1330 an ATMega]. Library für SED 1330 controller an ATmega
In der Codesammlung gibt es auch für andere Controller was.

===== Siemens S55/C60 =====
* [http://sandiding.tripod.com/m55.html S55-Display Pinbelegung]
* [http://www.mikrocontroller.net/topic/22643 Forumbeitrag]

===== Siemens S65/M65/CX65 =====
* [http://www.superkranz.de/christian/S65_Display/DisplayIndex.html S65-Display] vom Siemens S65/M65/CX65, 132x176 Pixel, 65536 Farben, günstig als Ersatzteil zu bekommen.

===== Nokia 3210/3310 =====
* [http://www.microsyl.com MicroSyl.Com]

* [http://www.deramon.de/nokia3310lcd.php Deramon.de]


===== Nokia 6100 LCD =====

* [http://www.myplace.nu/mp3/download/download.php Yampp 7 Software Download Seite]: Archiv "yampp-7 with colour LCD firmware" enthält avr-gcc/avr-as Routinen für 6100-LCDs mit Philips- oder Epson-Controller (nicht direkt eine "Library")
*[http://www.e-dsp.com/controlling-a-color-graphic-lcd-epson-s1d15g10-controller-with-an-atmel-avr-atmega32l/ S1D15G10]: Routine code für den Epson S1D15G10 Controller
*[http://thomaspfeifer.net/nokia_6100_display.htm Nokia 6100 Display am AVR] Anzeige von RGB-Bildern (für avr-gcc)
*[http://www.optixx.org/ www.optixx.org] Code zur Ansteuerung von Philips und Epson

===== KS0108 =====
* [http://hubbard.engr.scu.edu/embedded/avr/avrlib Procyon avrlib (GPL)]
* avrfreaks UP
* apetech.de nicht mehr erreichbar http://www.mikrocontroller.net/topic/68316

====GPS====
* http://www.holger-klabunde.de/avr/avrboard.htm#GPSdisplay GPS-Daten auf LCD
* [http://www.geoclub.de/forum57.html www.geoclub.de] - Elektronik beim Geocaching
* [http://passworld.co.jp/ForumMSP430/viewtopic.php?t=22 passworld.co.jp] - Do It Yourself GPS

== [[8051|8051 / MCS51]] ==
* [http://mcu8051ide.sourceforge.net/ MCU 8051 IDE] - MCU 8051 IDE is a new modern graphical IDE for microcontrollers based on 8051. MCU 8051 IDE is noncommercial open-source software for Linux.
* [http://www.rakers.de/catalog Dr. Rakers] Entwicklungssystem mit C-Compiler, BASIC-Compiler und Makroassembler für alle 8051-Mikrocontroller (80C552, 80C515(C), 80C537). Auch für Hobbyisten bezahlbar.
* [http://www.progshop.com/versand/software/prog-studio/index.html Prog-Studio] - Moderne Assembler Entwicklungsumgebung für 8051 Mikrocontroller mit Debugger, Edit & Continue, Code-Folding, Intelli-Sense, Monitorung und mehr
* [http://www.yCModule.de yCModule: µController-Systeme] - Preisgünstige µController-Module, ISP-Programmiertools und Applikationsboards
* [http://www.erikbuchmann.de/ Erik Buchmanns Mikrocontroller-Seite] - Assemblerkurs und mehrere Projekte
* [http://www.holger-klabunde.de/projects/8051.htm Experimentierboard für 8051 Controller] von Holger Klabunde.
* [http://www.woe.de.vu/ World Of Electronics] - Projekte mit den 8051-Controllern von Atmel
* [http://www.thomas-wedemeyer.de/elektronik/8051/8051.html Controllerplatine mit SAB80C535]
* [http://www.maxim.ph.tc Selbstbau-Programmer] für 2051er
* [http://www.nomad.ee/micros/8052bas.html 8052 BASIC Projects] - IDE-Interface
* [http://home.t-online.de/home/s.holst/sh51/index.html Mikrokontroller sh51] Schaltplan für 80C535-Board
* 8051-Makroassembler [http://plit.de/asem-51/ ASEM-51] (Freeware)
* [http://sdcc.sourceforge.net/ SDCC - Small Device C Compiler] - freier ANSI-C compiler für Intel 8051, Maxim DS80C390 und Zilog Z80 kompatible Controller.
* [http://sdccokr.dl9sec.de/ The SDCC Open Knowledge Resource]
* [http://www.wickenhaeuser.de/ Wickenhäuser C Compiler] - Preisgünstiger C Compiler
* [http://home.tiscali.cz:8080/~cz056018/lanc_a.htm LANC-Remote] Projekt von Jiří Šmach zur Steuerung von Videorekordern oder Camcordern über das Control-L (LANC) Protokoll mit Hilfe eines AT89C2051.
* [http://www.microcontroller-starterkits.de Microcontroller-Starterkits] Starter-Kits für verschiedene Microcontroller (D) preisgünstige Platinen (ab 12,95 Euro für AT89S8252). Beim uC-Dualboard : Das Board ist nutzbar mit AVR-Controllern und 8051-Controllern!
* [http://turbo51.com Turbo51 - Free Pascal compiler for 8051]
* [http://self8051.de/ self8051.de] - Dein Nachschlagewerk - Befehlsreferenz, Eigenschaften, Derivate

== MSP430 ==
* [http://www.mathar.com MSP430 Tutorials] - Tutorials, Anleitungen und viele Beispielprojekte mit dem MSP430-Mikrocontroller
* [http://www.student-zw.fh-kl.de/~stwi0001/imp/msp430/pwm430/index.htm Pulsweitenmodulation mit dem MSP430] - sehr ausführliche Einführung
* [http://www.thomas-wedemeyer.de/elektronik/msp430/msp430.html Kleine Projekte mit dem MSP430] - Schaltplan und Layout zu einem MSP430F149-Board und einem ADXL-G-Sensor mit MSP430
* [http://tinymicros.com/embedded/MSP430/ The MSP430 Bugspray Database] - umfangreiche Datenbank für Bugs in MSP430-Controllern
* [http://msp430.info MSP430.info] - Portalseite für MSP430; Info, Projekte (MIDI, USB)
* [http://groups.yahoo.com/group/msp430 Yahoo group MSP430] - lebhaftes Forum mit vielen MSP430-Experten
* [http://homepage.hispeed.ch/py430/mspgcc/ mps430-gdb und Eclipse] - Eine Anleitung von Chris Liechti
* [http://passworld.co.jp/ForumMSP430 Forum MSP430] - Projekte mit MSP430 (GPS, BlueTooth usw...)
* TI Design-WEttbewerb: http://www.designmsp430.com/View.aspx (dateien liegen evtl. in /projects/)
* [http://www.sics.se/project/mspsim MSPsim] - a Java-based simulator of MSP430 sensor network platforms (BSD License (revised))
* [http://develissimo.net/de/msp430entwicklung MSPGCC + Eclipse + msp430-gdbproxy / Linux / Debian / Ubuntu] - Anleitung / Tutorial zur Installation der MSPGCC Toolchain + Eclipse + msp430-gdbproxy für Linux / Debian / Ubuntu Lang=Deutsch und Englisch
* [http://travisgoodspeed.blogspot.com/ Travis Goodspeed's Blog]

== ARM ==

=== Herstellerseiten ===
* [http://www.arm.com ARM] - Entwickler des ARM-Prozessorkerns (kein Hersteller von ICs)
* [http://infocenter.arm.com ARM Infocenter] Sammlung Technischer Informationen

* [http://www.analog.com/ Analog Devices] ADuC7xxx ARM7TDMI Serie unter ''Analog Microcontrollers''
* [http://www.atmel.com/products/AT91/ Atmel AT91 Startseite]
* [http://www.at91.com AT91.COM] - Atmel ARM Informationsseite (Forum, Beispielcodes etc.)
* [http://www.cirrus.com/en/products/pro/techs/T7.html Cirrus Logic]
* [http://www.filmetrics.com Filmetrics Inc.] (Filmetrics manufactures affordable thin-film measurement instruments capable of measuring thin films from 3nm to 0.5mm in thickness.)
* [http://www.freescale.com/mac7100 Freescale MAC7100]
* [http://www.hilscher.com Hilscher netX] (ARM926 core)
* [http://www.intel.com/design/intelxscale/ Intel XSCALE Startseite], siehe auch [http://www.marvell.com/ Marvell]
* [http://www.luminarymicro.com/ Luminiary Micro] Controller mit Cortex M3 core
* [http://www.standardics.nxp.com/microcontrollers/ NXP (ehemals Philips) Microcontroller Startseite] für sämtliche Mikrocontroller (ARM7, MCS51 etc.), neben LPC2000, LPC3000 auch die LH7xxxx BlueStreak-Serie (ehemals Sharp Microelectronics)
* [http://www.lpc2000.com lpc2000.com] Infoseite für NXP (ex. Philips) LPC1700 Cortex-M3 basierende Typen, LPC2000, ARM7 basierende Typen und LPC3000, ARM9 basierende Typen. Auch andere Cortex-M3 Bausteine sind erfasst
* [http://www.okisemi.com/eu/1.Products/ARM32bit.html OKI ARM-Controller Startseite]
* [http://www.samsung.com/Products/Semiconductor/ Samsung] ARM7/9 unter ''Mobile SoC''
* [http://mcu.st.com/mcu/ STMicroelectronics (ST) Microcontroller Startseite] u.a. STR7, STR9, STM32 Support-Forum
* [http://www.ti.com/ Texas Instruments] TMS470 ARM7TDMI Serie

=== Information (Foren, Mailinglisten, Linksammlungen) ===
* [http://www.neko.ne.jp/~freewing/cpu/arm_olimex/ Freewing Linksammlung] zu den NXP (ex. Philips) LPC-ARM7-Controllern (Assemblerbeispiele u.a. für Nokia 3310-GLCD)
* [http://www.open-research.org.uk/ARMuC ARM Microcontroller Wiki]

* [http://tech.groups.yahoo.com/group/ADuC7000/ ADuC7000 Yahoo-Group]
* [http://www.at91.com AT91 Forum] (Atmel Rousset)
* [http://tech.groups.yahoo.com/group/AT91SAM/ AT91SAM Yahoo-Group]
* [http://en.mikrocontroller.net/forum/17 arm-elf-gcc WinARM Forum] (auch für Yagarto)
* [http://www.codesourcery.com/archives/arm-gnu/maillist.html Sourcery G++ Lite Edition User Forum/Mailing-List
* [http://tech.groups.yahoo.com/group/gnuarm/ GNUARM Yahoo-Group]
* [http://www.keil.com/forum/ Keil/ARM Forum]
* [http://groups.yahoo.com/group/lpc2000/ LPC2000 Yahoo-Group]
* [http://www.mcu-related.com MCU related] Neuigkeiten zu MCUs, überwiegend ARM / Cortex-M3 basierend mit Vergleichen von RTOS und anderen Entwicklungstools
* [http://forum.sparkfun.com/ Sparkfun Foren]
* [http://mcu.st.com/mcu/modules.php?name=Splatt_Forums STMicroelectronis Forum]

=== Entwicklungswerkzeuge (Compiler/Assembler/Debugger/Tools) ===

* [http://www.st-angliamicro.com/software.asp Anglia Idealist IDE und Anglia Toolchain] GNU toolchain für Win32-hosts inkl. Beispielen für STR7, STR9 und STM32. IDE kostenlost aber registrierungspflichtig
* [http://www.codesourcery.com/gnu_toolchains/ Codesourcery] GNU Toolchains für ARM (Hosts: Linux, MS Windows, Solaris; Targets: arm-elf, arm-linux, SybianOS)
* [http://devkitpro.org/ devkitPro/devkitARM] GNU-Toolchain für MS-Windows "Hosts". Vor allem auf GBA abgestimmt aber auch für andere ARM-Controller geeignet (arm-elf)
* [http://www.gnuarm.org GNU ARM] GNU Compiler-Toolchain für ARM mit binutils, gcc für C, C++, Java, newlib, gdb/Insight. Binaries für Linux und MS-Windows mit Cygwin
* [http://www.ghs.com/ Green Hills Software]
* [http://www.hitex.de Hitex] IDE für diverse Compiler, Debugger
* [http://www.iar.com IAR] Embedded Workbench, kommerzielle IDE/Compiler, codegrößenbeschränkte Evaluierungsversion verfügbar
* [http://www.isystem.com/ iSYSTEM] Integrated Development Environment, USB/JTAG interface, OnChip Emulation and Trace
* [http://www.keil.com Keil/ARM RVDK/uVision] kommerzielle IDE/Compiler, unterstützt zwei Compiler (ARM RealView, GNU/gcc), codegrößenbeschränkte Evaluierungsversion verfügbar (IDE/Compiler unbeschränkt für GNU), guter Debugger, guter Simulator (teilw. mit Hardwaresimulation) Simulator und Debugger in der Evaluierungsversion auch bei Nutzung der GNU-Toolchain auf 16kB beschränkt
* [http://mct.de/download.html#free MCT Demoversion C-Compiler für ARM und 68k] ARM C-Compiler basiert auf GCC laut Herstellerinformation jedoch mit Codegrößenbeschränkung 
* [http://www.mpeforth.com www.mpeforth.com] - A free Forth system with 125 page manual for all Philips LPC2xxx CPUs with at least 64k Flash and 16k RAM and cystal frequency of 10, 12, or 14.7456 MHz.
* [http://www.rowley.co.uk/ Rowley] Kommerzielle IDE für GNU-Compiler, eigene libc (nicht newlib), Debugger (inkl. gutem Support für Wiggler)
* [http://h-storm.tantos.homedns.org/gcc_arm.htm Tantos gcc for ARM Targets] eine weitere ARM-GNU-Toolchain für MS-Windows "Hosts"
* [http://www.yagarto.de Yagarto] GNU arm-elf-Toolchain, Eclipse, OpenOCD für Win32 inkl. Setup
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html#winarm WinARM] eine an WinAVR angelehnte Sammlung von Entwicklungswerkzeugen (binutils, arm-elf-gcc, newlib, ''newlib-lpc'', Programmers Notepad, ''Beispiel-Makefiles und Beispielcode'') für alle ARM-Controller. Beispiele für Philips LPC2000 und Atmel AT91SAM7S (ARM7TDMI) u.a.
* [http://rtlab.tekproj.bth.se/wiki/index.php/Dissy#Architecture_support Dissy] is a disassembler for Linux and UNIX which supports multiple architectures and allows easy navigation through the code. Dissy is implemented in Python and uses objdump for disassembling files.
* http://arm.hsz-t.ch Entwicklungsumgebung für ARM7 Mikrocontroller basierend auf der Knoppix CD. Keine Harddisk installation nötig für uClinux.

* [http://openocd.berlios.de/web/ OpenOCD] Open On-Chip Debugger: Schnittstelle ("gdb-Server") zwischen Wiggler-komaptiblem JTAG-Interface und GNU-debugger (gdb/Insight-gdb), ebenfalls Unterstützung für JTAG-Hardware auf FTDI2232-Basis, Flash-Programmierfunktion für LPC2k, AT91SAM7S u.a.
* [http://macraigor.com/full_gnu.htm OCDLibRemote] Schnittstelle zwischen WIGGLER-kompatibler JTAG Hardware und dem GNU-Debugger (gdb)
* [http://gdb-jtag-arm.sourceforge.net/ GDB-JTAG-ARM] GDB JTAG Tools
* [http://jtagpack.sourceforge.net/ JTAG-Pack] GDB JTAG Tools
* [http://www.hjtag.com H-JTAG] RDI-Interface für Wiggler, Flash-Funktionen für diverse interne und externe Speicher
* [http://www.clibb.de/ lpc21isp] Flashutility für LPC21xx, ISP via "Bootloader" ("multiplattform")

*http://www.abatron.ch Abatron] BDI1000 & BDI2000, On-Chip Debuggers für ARM, 68k, Coldfire uvm.
* [http://www.amontec.com Amontec] JTAGkey, JTAG-Adapter auf Basis des FTDI2232
* [http://www.keil.com Keil/ARM ULINK/ULINK2/ULINK-ME] JTAG-Adapter, USB-Anschluss, wird von Keil uVision unterstützt, ULINK2 teilw. auch von Codesourcery G++ (lt. Hestellerangaben)
* [http://www.kristech.eu Kristech] USB-Scarab, JTAG Adapter, kommt mit eigener Debugger-UI, kompatibel zu Olimex
* [http://www.lauterbach.de Lauterbach] TRACE32 JTAG-Adapter, USB und Ethernet-Anschluss, eigene Software
* [http://www.olimex.com Olimex] JTAG-Adapter: Wiggler-Nachbau (ParPort) und Adapter auf Basis des FTDI2232 (USB)
* [http://www.ronetix.at/peedi.html Ronetix Peedi]
* [http://www.segger.de Segger J-Link] JTAG-Adapter, USB-Anschluss, unterstützt z.B. von IAR, Keil uVision (via RDI) (OEM: IAR J-Link, SAM-ICE)
* [http://www.signalyzer.com/ Signalyzer] Signalyzer Tool, u.a. JTAG-Adapter auf Basis des FTDI2232
* [http://www.sinelabore.com sinelaboreRT] - generiert leicht lesbaren C-Code aus einer Zustandsmaschine. Die Generierung berücksichtig speziell die Bedürfnisse eingebetteter Echtzeitsysteme.

=== Tutorials und Beispiele ===
* [http://www.dreamislife.com/arm/ LPC210x ARM7 Microcontroller Tutorial] - Assembler-Beispiele (arm-elf-as) für das Olimex LPC-MT-Board (Philips LPC2106 ARM7TDMI)
* [http://re-eject.gbadev.org/index.php gcc-Assembler für ARM] - Befehlsübersicht
* [http://patater.com/gbaguy/gbaasm.htm GBA ASM Tutorial] - ARM7 Assembler Tutorial mit arm-elf-as ("gcc") (Allgemein und GBA)
* [http://www.robsite.de/daten/tutorials/devgba/gba_asm1.html GBA Assembler Tutorial] - ARM7TDMI, Schwerpunkt auf GBA
* [http://www.sparkfun.com/tutorial/ARM/ARM_Cross_Development_with_Eclipse.pdf Eclipse+CDT+gnuarm-Tutorial]
* [http://mct.de/download/armsamples/map.html Beispiele in C, für ARM7-Controller von Philips und ADI]
* [http://www.embedded.com/design/opensource/201802580 Embedded.com: Building Bare-Metal ARM Systems with GNU] Teil 10, Links zu den Teilen 1-9 auf der Seite
* [http://www.sparkfun.com/datasheets/DevTools/SAM7/at91sam7%20serial%20communications.pdf AT91SAM7 Serial Communications] von James P. Lynch (PDF, www.sparkfun.com)
* [http://www.kaczurba.pl/aduc ADuC7000 Tutorial] von Witold Kaczurba (www.kaczurba.pl)

=== Projekte und Quellcodebibliotheken ===
* [http://hubbard.engr.scu.edu/embedded/arm/armlib/ Procyon ARMlib-LPC2100] - Treiber, Beispiele (Lizenz: GPL, kaum weiterentwickelt)
* [http://www.standardics.nxp.com/support/documents/?type=software NXP BlueStreak] Code für LH7xxxx (ehemals Sharp)
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html M. Thomas' ARM Projekte] "Projectvorlagen" für AT91SAM7 und LPC2000 mit GNU-Toolchain Einsteiger-Projekte für AT91SAM7, LPC2000, ADuC7000 u.a. (u.a. Blinky, UART, Interrupt, C++, GLCD mit KS0108, DS18x20, DCF77, Anpassungen von FAT16/32-Libraries) 
* [http://mcu.st.com/ STMicro] Treiber und Beispiel für STR7, STR9 und STM32
* [http://www.gnuarm.com/~lpc2000/ Mirror der LPC2100-Group Dateien] (veraltet, aber ohne Yahoo-Account zugänglich.)
* [http://www.geocities.com/leon_heller/lpc2104.html Simple LPC210x Prototyping System]
* [http://wiki.sikken.nl/index.php?title=LPCUSB LPCUSB] - Open-source [[USB]] stack for the built-in USB controller in LPC214x microcontrollers von Bertrik Sikken. [http://lpcusb.cvs.sourceforge.net/lpcusb/host/benchmark/main.c?revision=1.2&view=markup Sample code]
* [http://www.olimex.com Olimex] Einige Beispiele auf den "Produktseiten" der ARM Boards.
* [[ARM MP3/AAC Player]]
* [http://www.jcwren.com/arm/ J.C. Wrens Beispielprojekt] für LPC214x
* [http://www.keil.com/download/list/arm.htm Beispiele von Keil] abgestimmt auf deren Boards und Realview-Toolchain, Portierung auf andere Boards und Compiler relativ einfach, Lizenz beachten.
* [http://www.luminarymicro.com/ Luminary Micro Driverlib] für Stellaris Cortex-M3
* [http://r2d2.stefanm.com/gps-tracker.html GPS-Tracker] mit Navigation auf LPC2103-Basis (Complier: GCC)
* [http://elua.berlios.de elua] Lua für ARM-controller
* [http://freemodbus.berlios.de/ FreeMODBUS] "A Modbus ASCII/RTU and TCP implementation" (für STR71x, AT91SAM7, LPC214x, auch: AVR, MSP430 u.a.)
* [http://bettyhacks.com BettyHacks] Freie Firmware für die eingestellte, interaktive TV-Fernbedienung betty-tv

=== Betriebssysteme ===
* [http://agnix.sourceforge.net/ Agnix]
* [http://www.bertos.org/ BeRTOS] is a completely free, open source, real time operating system (RTOS) suitable for embedded platforms. Runs on many microprocessors and microcontrollers, ranging from 8 bits to 32 bits CPUs and even PCs.
* [http://chibios.sourceforge.net/ ChibiOS/RT]
* [http://sources.redhat.com/ecos/ eCos] - "Real-Time-Operating-System" o.a. auch für ARM7
* [http://www.freertos.org/ FreeRTOS (.org!)] - "Real-Time-Kernel" unter anderem für ARM7 (LPC2xxx) auch AVR, MSP430, '51er
* [http://l4ka.org/ L4Ka]
* [http://www.toradex.com/colibri_downloads/Linux/readme.txt Linux 2.4.29 für Toradex Colibri] basierend auf Intel XScale PXA270
* [http://www.linux4sam.org Linux4SAM] Informationen, Anleitungen und Code zur Anwendung von Linux auf AT91SAM9xxx
* [http://www.freertos.com/ NicheTask] (URL ist www.freertos.com aber hat nichts mit FreeRTOS(.org) zu tun)
* [http://www.ethernut.de/en/software/index.html Nut/OS]
* [http://nuttx.sourceforge.net/ NuttX RTOS] (ARM7TDMI port for TI TMS320C5471 also called a C5471 or TMS320DM180).
* [http://www.phoenix-rtos.org/ Phoenix-RTOS]
* [http://picoos.sourceforge.net/ PicoOS]
* [http://prex.sourceforge.net Prex] is a portable real-time operating system for embedded systems. The small, reliable, and low power kernel is written in the C language based on microkernel design. The file system, Unix process, and networking features are provided by user mode tasks. (ARM, i386, geplant: MIPS, PowerPC, Hitachi-SH und Win32)
* [http://www.rtems.org/ RTEMS]
* [http://www.tnkernel.com/downloads.html TNKernel] - "Real-Time-Kernel" TNKernel ist ein kompakter und sehr schneller Echtzeitkernel unter anderem für ARM7 (Philips LPC2106/LPC21XX/LPC22xx, Samsung S3C44B0X, Atmel AT91SAM7S128, STMicroelectronics STR711FR2)
* [http://www.ucos-ii.com/ uC/OS-II RTOS]
* [http://www.DieProjektseite.de BasicBeetle] Basic-Betriebssystem im AVR

=== Hardware (Prototypen-Platinen etc.) ===

* [http://www.armkits.com/ Embest] Philips, Samsung und Atmel ARM Boards und Module, JTAG-Hard- und Software
* [http://www.waveplayer.de/ Embedded-Waveplayer] mit ARM7-Prozessor EP7309 (MIDI- und RS232-Steuerung)
* [http://www.embeddedartists.com/ Embedded Artists] bietet verschiedene preisgünstige Platinen (ab 25 Euro für LPC213x Familie)
* [http://www.hiteg.com Hiteg] SAMSUNG und Intel XScale basierende boards. (Deutsches Unternehmen in China)
* [http://www.hitex.de/ Hitex] Starter-Kits für Philips LPC2000, ST STR7, Atmel AT91M
* [http://www.iar.com/ IAR] Starter-Kits für Atmel, Oki, Philips, ST und TI
* [http://www.ic-board.de/index.php?cat=c12_ICswift-Module.html ic-board.de] Kommunikationsplattform auf Basis des AT91SAM7X256 mit Ethernet, USB, CAN und Funk Schnittstellen
* [http://www.keil.com/ Keil] Philips LPC2000 und ST STR7/9 Boards und Starter-Kits
* [http://www.lpctools.com/ LPCTools] bietet verschiedene Starter Kits für die LPC2000-Familie
* [http://www.makingthings.com/ MakingThings] Make Controller Kit (AT91SAM7X256)
* [http://mct.de/index.html MCT Paul und Scherer] Starterkits für ARM7 (NXP LPC2000, ADI ADUC7000)
* [http://shop.mikrocontroller.net Mikrocontroller.net Shop] Platinen mit AT91SAM7, LPC2xxx, JTAG
* [http://www.microcontroller-starterkits.de Microcontroller-Starterkits] Starter-Kits für verschiedene Microcontroller (D) preisgünstige Platinen (ab 12,95 Euro für LPC2129 und 2194) sowie Entwicklungsboard komplett bestückt
* [http://stores.ebay.de/Micro-Research Micro-Research] Development- und Header-Boards für LPC2000 und ADuC7000
* [http://www.olimex.com Olimex] Bulgarischer Anbieter günstiger ARM Prototypen- und Header-Boards (LPC2000, STR7, AT91SAM, ADI, TI, OKI u.a.)
* [http://www.propox.com/?lang=en Propox]
* [http://www.revely.com/ Revely] Evaluations- und Demo-Boards mit Sharp ARM Controllern. Teilweise mit SVGA-Anschluss.
* [http://www.skpang.co.uk/catalog/index.php SKPang electronics] Entwicklungsboards für diverse ARM7/9 (UK)
* [http://www.dilnetpc.com SSV Embedded Systems] bietet verschiedene Starter Kits für die verschiedenen DIL/NetPC u.a. (A)DNP/9200 SBC mit AT91RM9200
* [http://www.taskit.de taskit] [https://ssl.kundenserver.de/taskit.de/at91shop/shop_content.php?coID=10 Development- und Header-Boards für AT91SAM7S/X], AT91RM9200, AT91SAM9
* [http://www.toradex.com/e/products.html Toradex] Colibri: Intel XScale PXA270 DevKit (Schweiz)

== [[PIC]] ==

=== Herstellerseiten ===
* [http://www.microchip.com Microchip] Hersteller der PIC Microcontroller
* [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014&part=SW006011 Microchip C18 Student Edition] - die "Student Edition" des Microchip C18 C Compilers für die PIC18 Serie ist kostenlos verfügbar.
* [http://www.powercontact.de Systemtechnik Leber] Offizieller Microchip Design Partner für professionelles Microcontroller Design und Hersteller von Leistungsstellern, Thyristorstellern und Halbleiterelais...

=== Entwicklungstools / Tutorials / Foren ===
* [http://www.osterer.co.at www.osterer.co.at] Entwicklungs-Board mit integrierten Programmer/Debugger für PIC18F4550.
* [http://www.martins-elektronikwelt.tk www.martins-elektronikwelt.tk] ICD1-Debugger-Nachbau im Kleinstformat u. SMD Technik (so groß wie eine halbe Scheckkarte).
* [http://www.sprut.de/electronic/pic/index.htm PIC-Microchip-Controller (www.sprut.de)] Diese Seite soll dem Anfänger die ersten Schritte in die Welt der Microcontroller der Firma Microchip erleichtern. Betrachtet werden die 14-Bit-Controller der Serien PIC16Fxxx bzw PIC12Fxxx.
* [http://www.fernando-heitor.de PIC: Programmierung in CCS (www.fernando-heitor.de)] Dies ist eine weitere Seite die dem Anfänger, der sich mit PICs beschäftigt, auf die Beine hilft. Sie befasst sich hauptsächlich mit dem CCS-Compiler und hat dazu ein sehr gutes Tutorial. Ausserdem bietet die Seite ein Forum speziell für PIC Mikrocontroller.
* [http://www.cc5x.de CC5X] Programmierkurs für PIC-Microkontroller in C (CC5X Compiler)] Programmierkurs mit Beispielen und Schaltplänen, fertige Hardware- und Softwarelösungen. In diesem Kurs sind auch einige Unterprogramme detailliert erklärt.
* [http://www.microchipc.com/ MicrochipC.com] Programmieren von PIC-Microcontrollern mit C. (Enthält auch Links und Bootloader für diverse PICs.)
* [http://www.amodio.biz/projects/PIC10BaseT/index.html Internetworking with Microchip Microcontrollers - PIC18F4620+ENC28J60]
* [http://pic18fusb.online.fr/wiki/wikka.php?wakka=WikiHome Wiki about Microchip USB PIC] (PIC18F2550, PIC18F4550...)
* [http://piklab.sourceforge.net/ Piklab] is an integrated development environment for applications based on Microchip PIC and dsPIC microcontrollers similar to the MPLAB environment. It integrates with several compiler and assembler toolchains (like gputils, sdcc, c18) and with the simulator gpsim. It supports the most common programmers (serial, parallel, ICD2, Pickit2, PicStart+) and debuggers (ICD2).
* [http://www.members.aon.at/electronics/pic/picpgm/_main.html PICPgm - Free PIC Development Programmer for Windows] Einfacher PIC Programmer für Windows. Unterstützt eine Vielzahl von PIC-Chips und wird ständig erweitert.
* [http://www.stolz.de.be InCircuit-Programmer und -Debugger (www.stolz.de.be)] Einfacher Nachbau des Microchip ICD2s. Zum Programmieren und Debuggen.
* [http://www.winpicprog.co.uk WinPicProg] Programmer und Tutorials für Anfänger von Nigel Goodwin (Englisch)
* [http://www.tigal.com EasyPIC3, EasyPIC4, Easy8051A, EasyAVR, Easy-was-weiss-ich (www.tigal.com)] - Distributor für Produkte von [http://www.mikroelektronika.co.yu mikroelektronika] und weiteren Herstellern
*[http://www.pro-zukunft.de Pro Zukunft] Evaluation-Board für PIC16F84A, hands-on-training und Print-Lehrgang. Für Schulen, Ausbildungsbetriebe & Hobbyelektroniker.
* [http://www.wselektronik.at www.wselektronik.at] Bausatz für "Full Speed ICD2" (USB2.0, Debugger, Programmer) oder Fertiggerät erhältlich.
* [http://www.uchobby.com/index.php/2008/04/19/pic-development-linux-style/ How to setup for PIC microcontroller development on Linux] von Steven Moughan
* [http://www.dattalo.com/gnupic/gpsim.html#docs gpsim] is a full-featured software simulator for Microchip PIC microcontrollers distributed under the GNU General Public License.
* [http://dev.frozeneskimo.com/software_projects:vpicdisasm vPICdisasm] is a Microchip PIC Mid-Range family firmware disassembler. This single-pass disassembler can read Intel HEX and Motorola S-Record formatted files containing valid PIC firmware. (GPL)
* [http://pikdev.free.fr/ PiKdev] is a simple graphic IDE for the development of PIC-based applications. It currently supports assembly language. C language is also supported for PIC 18 devices. PiKdev is developed in C++ under Linux and is based on the KDE environment.
* [http://www.yenka.com/en/Yenka_PICs/ Yenka PICs] lets you write routines using simple flowcharts, and test them on-screen, before using them to program real PIC or PICAXE chips. To help spread the news about Yenka, we're offering free copies of Yenka PICs for use at home or school.

=== Projektsammlungen/Einzelprojekte ===

* [http://www.martins-elektronikwelt.tk www.martins-elektronikwelt.tk] Viele Projekte mit den PIC Mikrocontrollern, u.a. SMS-Schaltzentrale, SD/MMC-FAT32-MP3-Player, Lichtschranken, Funk-Wetterempfänger, PS/2 am PIC usw.
* [http://www.Firmware-On-Demand.com Firmware-On-Demand] Umfangreiche Firmware-Bibliothek.
* [http://www.picguide.org PIC Guide] Eine große Sammlung von PIC-Projekten für den Anfänger
* [http://www.rentron.com www.rentron.com] Anfänger-taugliche Projekte für PIC und [[8051]] von Reynolds Electronics (Englisch)
* [http://www.ing-pfenninger.ch/artikel.html PIC-Projekte] Einige PIC-Projekte zum Nachbauen wie IR-Lichtschranke, Frequenzzähler.
* [http://mondo-technology.com/ SuperProbe] - Logic Probe,(Auf der linken Seite ganz oben) Logic pulser, Frequency Counter, Event Counter, Voltmeter, Diode Junction Voltage, Capacitance Measurement, Inductance Measurement, Signal Generator, Video Patern, Serial Ascii, Midi Note, R/C Servo, Square Wave, Pseudo Random Number, ir38, PWM in einem... (PIC16F870)
* [http://www.circuitcellar.com/microchip2007/ Microchip 16-Bit Embedded Control 2007 Design Contest] bei [http://www.circuitcellar.com/ Circuit cellar]
* [http://mondo-technology.com/ Mondo Technologiy] Grosse Ansammlung von PIC-Projekten
* [http://micrognurtos.sourceforge.net uGNU/RTOS] is a microcontroller-targeted serial real time operating system. It has been ported to USART capable Microchip PIC16 devices. It supports I/O operations and some internal registry operations. The user can interact with the chip through the RS-232 serial cable and a shell. The user can type a small list of commands and see the results on the chip's outputs. (LGPL)

== [[Z8]] ==
* [http://www.z8micro.com/forum/ Z8 Encore! Microcontroller Discussion Forum - Dedicated to the ZiLOG Z8 Encore! Microcontroller] Ein der Z8 Encore!-Mikrocontrollerfamilie gewidmetes Diskussionsforum (in Englisch).
* [http://groups.yahoo.com/group/z8encore/ Yahoo! Groups : z8encore] Yahoo-Gruppe, die sich mit den Z8 Encore! Mikrocontrollern beschäftigt (Anmeldung bei Yahoo erforderlich).
* [[Zilog Encore Experimentierplatine]] (Z8F6421 Familie mit DIP-40 Gehäuse)

== Programmierbare Logik ([[CPLD]]/[[FPGA]]/[[GAL]]) ==

* [http://www.opencores.org/ OpenCores.org], VHDL Sourcen
* [http://www.fpga4fun.com/ fpga4fun], umfangreiche Seite mit Einführung und Beispielen, berücksichtigt Xilinx & Altera
* [http://opencollector.org/history/freecore/ Freecore], unter 'Module library' gibt's einige freie Designs
* [http://www.cmosexod.com/ CMOSExod], Designs unter 'Free IP'
* [https://digilent.us/ Digilent], Hersteller verschiedener FPGA/CPLD-Boards (u.a. Xilinx Spartan Starter Kit)
* [http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=39 Terasic], Anbieter von Altera FPGA-Boards
* [http://shop.trenz-electronic.de/catalog/ Trenz Elektronik], verkauft verschiedene FPGA/CPLD-Boards
* [http://www.xess.com/index.html XESS], Anbieter von FPGA-Boards (Xilinx), unter Support gibts es eine Menge Beispiele
* [http://members.optushome.com.au/jekent/FPGA.htm Private Seite von John Kent], enthält eine Menge Links und auch einige Designs
* [http://www.mediatronix.com/Tools.htm Mediatronix tools], Picoblaze und DSP tools
* [http://www.ixo.de/info/usb_jtag/ ixo.de usbjtag] - USB-JTAG Adapter, fast kompatibel zu Altera USB-Blaster, wahlweise basierend auf FT245+CPLD oder Cypress FX2 Controller
* [http://www.fpgacpu.org/links.html FPGA CPU Links]
* [http://www.fpga-forum.com/wbb Forum mit allgemeinen Diskussionen zum Thema FPGA und FAQ's speziell zu den Cesys FPGA Karten]
* [http://www.cesys.biz Online Shop für Cesys FPGA Karten]

== DSP ==

=== Embedded Linux & DSP ===

* [http://www.tetrix-systems.de/embedded.html combined embedded Linux-DSP Solutions]

=== Misc. ===

* [http://open.neurostechnology.com/node/1020 TI c54x DSP Compilertools (ohne Debugger)] frei für Open Source Projekte.

== Wettbewerbe (Contests) ==

Verschiedene Hersteller veranstalten zur Promotion ihrer Produkte Designwettbewerbe, aus denen teilweise komplette Projektunterlagen hervorgehen (Schaltung, Source).

'''2009'''
* [http://www.designmsp430.com/ Design MSP430 Ultra-Low Power Challenge]
* [http://makezine.com/halloweencontest/ Make: Halloween Contest 2009], sponsored by Microchip Technology!
* [http://www.bricogeek.com/contest/let-arduino-play/resultados.php Let Arduino Play Contest]
* [http://www.dlpdesign.com/designcontest/ DLP Design DLP-232PC Design Contest]
* [http://www.libelium.com/tienda/catalog/contest.php Arduino contest by Libelium]
* [http://www.expli.de/wettbewerb/coole-avr-microcontroller-elektronik-ideen/ EXPLI Elektronik Wettbewerb]: Die coolsten Elektronik Projekte & AVR Microcontroller Anleitungen
* [http://www.stm32circle.com/projects/contest.php STM32 Primer2 Design Competition 2009]
* [http://www.parallax.com/tabid/603/Default.aspx 2009 Propeller Design Contest]

'''2008'''
* [http://www.parallax.com/tabid/720/Default.aspx Propeller Design Contest]
* [http://www.psocidcindia.com/index.php PSoC Innovator Design Challenge India 2008]
* [http://www.mypic32.com Microchip PIC32 Design Challenge]
* [http://contest.renesasinteractive.com/ HEW Target Server Design Contest 2008]
* [http://www.stm32circle.com/projects/result_contest_2008.php STM32 Primer Design Competition 2008]

'''2007'''
* [http://www.circuitcellar.com/wiznet/index.html WIZnet iEthernet Design Contest 2007]
* [http://www.circuitcellar.com/microchip2007/ Microchip 16-Bit Embedded Control 2007 Design Contest]

'''2006'''
* [http://www.designmsp430.com/View.aspx 2006 MSP430 eZ Design Contest]
* [http://www.circellar.com/msp430/ MSP430 Design Contest]
* [http://www.luminarymicro.com/DesignStellaris2006 Luminary Micro DesignStellaris2006]
* [http://www.circuitcellar.com/avr2006/ Atmel AVR Design Contest 2006]

'''2005'''
* [http://www.jandspromotions.com/philips2005/index.htm Philips ARM Design Contest 2005] (LPC213x)
* [http://www.circuitcellar.com/renesas2005m16c/index.htm Renesas M16C Design Contest 2005]
* [http://www.edn.com/article/CA516007.html Cornelius van Drebbel's Mad Design Contest] (NEC)

'''2004'''
* [http://www.circuitcellar.com/avr2004/ Atmel AVR 2004 Design Contest]
* [http://www.circuitcellar.com/psoc2004/ PSoC High Integration Challenge 2004]
* [http://www.jandspromotions.com/zilog2004/ Zilog 2004 Flash Nets Cash Design Contest] (eZ80Acclaim!)
* [http://www.jandspromotions.com/wirelesschallenge/index.html 2004 Freescale Wireless Design Challenge] (MC13191/92/93 RF Transceivers, [[Meshnetics Zigbee|ZigBee]])

'''2003'''
* [http://www.circuitcellar.com/fi2003/ MOTOROLA FLASH INNOVATION 2003 DESIGN CONTEST] (Motorola HC08)
* [http://www.circuitcellar.com/renesas/ Renesas H8 Design 2003 Contest]
* [http://www.jandspromotions.com/zilog2003/ ZiLOG Flash for Cash Z8 Encore®! International Design Contest]
* [http://www.jandspromotions.com/efield203/index.htm 2003 Motorola E-Field Sensor Contest] (MC33794)

'''2001'''
* [http://www.circuitcellar.com/dl2001/ Atmel 'Design Logic 2001' Design Contest]

== Interfaces & Protokolle ==
Siehe auch [[Linksammlung#Schnittstellen]]

=== Infrarot (IR) ===

* [http://www.sbprojects.com/knowledge/ir/ir.htm Übersicht IR-Protokolle] von San Bergmans (engl.): ITT, JVC, NEC, Nokia NRC17, Sharp, Sony SIRC, Philips RC-5, RC-6, RC-MM, RECS80, RCA, X-Sat
* [http://www.vishay.com/docs/80071/dataform.pdf Data formats fpr IR controls (PDF)] von Vishay.

=== Parallelport ===

* [http://www.projects-lab.com/?p=1139 ECPMON] - ECP Parallel Port Monitor ([[M16C]]/62P)

=== iPod ===
* [http://ipodlinux.org/IPod_to_T%26A_remotecontrol_adapter IPod to T&A remotecontrol adapter] ([[PIC]]-Projekt)

=== [[RFID]] ===

* [http://www.mwjournal.com/journal/article.asp?HH_ID=AR_905 Radio Frequency Identification: Evolution of Transponder Circuit Design] - Übersichtsartikel aus dem Microwave Journal
* [http://www.foebud.org/rfid Die StopRFID-Seiten des FoeBuD e.V.]
* [http://www.rfzone.org/free-rf-ebooks/ PDF-Bücher (englisch) ]- Bücher über RF, Antennen und elektromagnetische Wellen.

* http://cq.cx/proxmark3.pl Jonathan Westhues RFID Leser/Schreiber/Cloner

http://www.message_bocracco.com/

==== 13,56 MHz RFID ====
* [http://www.openpcd.org/ OpenPCD - a free 13.56MHz RFID reader design] for Proximity Coupling Devices (PCD) based on 13,56MHz communication. This device is able to screen informations from Proximity Integrated Circuit Cards (PICC) conforming to vendor-independent standards such as ISO 14443, ISO 15693 as well as proprietary protocols such as Mifare Classic. (AT91SAM7S128 [[ARM]] Projekt)
* [http://www.rf-dump.org/ RFDump] is a backend GPL tool to directly interoperate with any RFID ISO-Reader to make the contents stored on RFID tags accessible. (Linux)

==== 2,4 GHz RFID ====
* [http://www.openbeacon.org/ OpenBeacon] - a free active 2.4GHz beacon design. (Reader: USB oder Ethernet; Tags: RF_Chip: NRF24L01, PIC16F684)

=== [[DMX512]] ===
* [http://www.soundlight.de/techtips/dmx512/dmx512.htm DMX-512 - was ist das?] Eine Übersicht von SOUNDLIGHT.
* [http://www.oksidizer.com/electronic/spp2dmx/index_en.html OksiD DMX 3/1 is a Standard Parallel Port DMX 512 interface for IBM compatible PCs]. Drei Output Universe und ein Input Universe (Universe = 512 channels). Open project. All source code and schematics are available for free.
* [http://www.usbdmx.com/usb_dmx_interface.html USB DMX Interface revision 1.3] - opto isolated, bus powered, DMX512 from/to [[USB]]interface with both in and out universes. Cheap and simple to build.
* [http://www.dmx512-online.com/ Ujjal's DMX512 Seite]
* [http://llg.cubic.org/dmx4linux/ DMX4Linux 2.6] - A DMX device driver package for Linux (incl. hardware schematics with TI [[MSP430]])

=== Verschiedenes ===
* [http://www.taelektroakustik.de/deu/index.htm T&A Kommandos] - '''RC''' und '''RCII''' Kommandoset der Philips PRONTO Familie zur Steuerung von Audiogeräten. Dokumentation siehe unter Downloads.
* [http://www.marjorie.de/ps2/ps2_protocol.htm Das PS/2 Maus und PS/2- oder AT-Tastatur-Protokoll] (Original auf [http://www.computer-engineering.org/])
* [http://www.hth.com/snap/ S.N.A.P - Scaleable Node Address Protocol]. S.N.A.P is an free and open network protocol. The protocol was primary developed for PLM-24 based home automation and control systems but it is a generic protocol and not limited to this. S.N.A.P can be used in any type of applications where an easy to learn and light weighted network protocol is needed.
* [http://www.ulrichradig.de/home/index.php/avr/avr_-_rc PPM / PWM Encoder/Decoder für R/C Funkfernsteuerungen] von Ulrich Radig (AVR, C)
* [http://www.national.com/analog/interface/lvds_owners_manual LVDS Owner's Manual - 4th Edition] von National Semiconductor
* [http://sound.westhost.com/heatsinks.htm The Design of Heatsinks]
* [http://www.mictronics.de/?page=becker Becker Unilink]

== Leiterplattenhersteller ==

siehe [[Platinenhersteller|Platinenhersteller]]

== Schulungen (Online) ==

* [http://www.esacademy.com/myacademy/ www.esacademy.com] (engl.) - C, CAN, I²C, BlueTooth, PWM, USB, 51LPC, ARM (Einführung)
* [http://www.elprak.ch Elektronik in der Praxis] Präsentationen zu verschiedenen Themen der Elektronik in der Praxis. Lötvideo, das den zeitlichen Ablauf beim Löten anschaulich darstellt.
* [http://www.national.com/onlineseminar/ www.national.com] - Amplifiers, Audio, Data Acquisition, Die Products, Displays, Interface, Microcontrollers, Military/Aerospace, Power, Thermal Management, Wireless
* [http://www.circuitrework.com Circuit Technology Center] - Surgeon grade rework and repair, by the book and guaranteed. Deeplink: [http://www.circuitrework.com/guides/guides.shtml Guides]
* [http://www.onlinetutorials.de/index.htm onlinetutorials.de] - Linksammlung zu Tutorials für höhere Programmiersprachen ([[HLL]]) wie C, C++, Java, BASIC, Perl, PHP, ...
* [http://www.awce.com/classroom/ AWCE Interactive Classroom] - Embedded Systems (Using the APP-IV with GCC, Getting Started with the PIC 18F Family), Electronics (CLARC/HBSIG DSP Study Group, Basic Circuits), RoadMap to Programmable Logic
* [http://www.ibiblio.org/kuphaldt/socratic/ Socratic Electronics] (englisch)
* [http://www.embedded.com/design/multicore/201200638;jsessionid=4T1T0OZQW4PFSQSNDLRSKH0CJUNN2JVN?printable=true The basics of programming embedded processors] von Wayne Wolf. Neun Artikel bei embedded.com (englisch)
* [http://webcast.berkeley.edu/course_details.php?seriesid=1906978507 EE 42/EE 100 Introduction to Digital Electronics] - Webcast, Spring 2008 (englisch)
* [http://freevideolectures.com freevideolectures.com] - Webcasts zu naturwissenschaftlichen Theman (englisch)
* [http://www.circuitsage.com/ Circuit Sage], a complete source of information to help you design circuits fast. (Linksammlung zu Software, Artikeln Büchern und Websites)
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Umfangreiche Sammlung von kleinen Lehrgängen und Schaltungen. Ideal für Anfänger aber auch für Fortgeschrittene
* [http://homepages.internet.lu/absolute3/tronic/ 3D Virtual Development] - Sammlung von vielen Grundschaltungen im Bereich Oszillator, Operationsverstärker, Empfangstechnik. Vereinzelt in Englisch.

== Skripte ==

* [http://www.janson-soft.de/skripte/index.html Linksammlung von Volker Lange-Janson]
* [http://wwwex.physik.uni-ulm.de/lehre/physikalischeelektronik/phys_elektr/phys_elektr.html Physikalische Elektronik und Messtechnik] von Othmar Marti und Dr. Alfred Plettl, Universität Ulm

== Messequipment ==
* [http://www.filmetrics.com Filmetrics Inc.] (Filmetrics manufactures affordable thin-film measurement instruments capable of measuring thin films from 3nm to 0.5mm in thickness.)
=== Logikanalyse ===
* [http://www.pctestinstruments.com Intronix LogicPort], Günstiger, aber sehr leistungsfähiger Logikanalysator mit USB-Anschluß an PC (34Ch, 500MHz Timing, 34 x 2kSa mit Kompression, ca. 295 Euro [http://www.shop.display3000.com/elektronik/messgeraete/index.html hier])
* [http://www.tech-tools.com/dv_main.htm TechTools DigiView], Günstiger Logikanalysator mit USB-Anschluß an PC (18Ch, 100MHz Timing, 128kSa mit Kompression, [http://elmicro.com/de/digiview.html ca. 430Euro])
* [http://www.tribalmicro.com/logic_an/ Tribalmicro], PC hosted LA (32ch, 40MHz Timing, 128kSa, ca. 1700$)
* [http://www.nci-usa.com/frame_products_overview.htm NCI GoLogic], Logikanalysator mit USB-Anschluß an PC (34 oder 72Ch, 500MHz Timing, 1 oder 2MSa, ca. 3000..5500$)
* [http://www.tek.com/products/logic_analyzers/index.html Tektronix], Verschiedene Geräte, standalone oder modular (ab 34ch, 2GHz Timing, ab 512kSa, gut und teuer)
* [http://www.home.agilent.com/DEger/nav/-536902443.0/pc.html Agilent], Verschiedene Geräte, standalone, modular oder PC-hosted (ab 34ch, ab 800MHz timing, ab 256kSa, gut und teuer)
* [http://www.sump.org/projects/analyzer/ Sumps LA], günstiges Projekt für einen LA basierend auf einem Digilent Spartan Board (32ch, 100MHz Timing, 256kSa, Kosten Digilent Board ca. 100$ + Versand/Zoll)
* [http://www.meilhaus.de/produkte/usb-mobile-messtechnik/?user_produkte%5BPATTR%5D=HPG_3-UPG1_3-UPG2_2&user_produkte%5BPR%5D=8&cHash=2c8edb93e2 Meilhaus Electronic - MEphisto Scope UM203] Robustes, mobiles 16 bit Kombi-Instrument 7 Mess-Geräte in einem! (ab 348€)
* [http://www.hacker-messtechnik.de/13722/59001.html TravelLogic TL2x36], Logikanalysator zum Anschluß an PC über USB, (36ch, 4GHz timing, 200MHz state, Speicher bis 72MBit, Preis ab ca. 500,- netto)
* [http://www.inovaflex.de/index.html Bus und Logic Analyzer] 100MHz Samplerate und integrierten SPI, I²C, CAN Interpreter, erweiterbar als Oszilloskop
* [http://www.saleae.com/logic/ logic] - Logik-Analyzer mit 8 Kanälen, mit Software zur Analyse von SPI, I2C, UART, etc... (ca 150$ + Versand/Zoll)

* Eine Übersicht über verschiedene Selbstbauprojekte: [[Logic_Analyzer]]

=== Oszilloskope ===

siehe die separate [http://www.mikrocontroller.net/articles/Oszilloskop Seite] zum Thema

=== Generatoren ===
[http://www.meilhaus.de/produkte/mess-und-steuer-karten/?user_produkte%5BPR%5D=23&cHash=64a269a3c6 Meilhaus Electronic - ME-6x00] Waveform-Generator - potentialfrei isolierte 16 bit Analog-Ausgabe-Karte (ab EUR 1138,00)

== Vermischtes ==

=== Foren ===
* [http://www.sparkfun.com/cgi-bin/phpbb/ Spark Fun Electronics] MicroController Ideas and Support (Englisch) ([[AVR]], [[PIC]], [[MSP]], [[ARM]], OpenOCD)
* [http://www.edaboard.com/ EDAboard.com] International Electronics Forum Center (Englisch)
* [http://stsboard.de STS Reparatur Forum] Forum für Radio und Fernsehtechniker
* [http://formu.iwenzo.de Elektronik Reparatur Forum] Informationselektroniker Reparatur Forum

=== Projektsammlungen ===
Meist in Englisch.
* [http://circuitscout.com/ Circuit Scout] - Online Suchmaschine
* [http://www.epanorama.net ePanorama.net]
* [http://www.commlinx.info Electronic Schematics] from CommLinx Solutions Pty Ltd
* [http://www.discovercircuits.com Discover Circuits] a collection of 25000+ electronic circuits or schematics
* [http://www.next.gr/ Next] Electronic Circuit Database
* [http://www.beyondlogic.org/ BeyondLogic.org] Diverse Mikrocontroller und Interfacing Projekte
* [http://www.uoguelph.ca/~antoon/circ/circuits.htm Circuits for the Hobbyist] by VA3AVR
* [http://www.stefpro.de/ StefPro.de] Diverse Projekte und Datenblattsammlung nach Kategorien, Microcontroller, Digital und Analog... Sowie Tutorial "Grundlagen der Bestückung von Platinen" und anderes Wissen
* [http://www.schaltplaene-online.de/ www.schaltplaene-online.de] Umfangreiche Linksammlung zu Schaltplänen aller Art
* [http://www.avr-projects.info www.avr-projects.info] Liste mit AVR-Projekten, die von jedem Besucher erweitert werden kann (wiki like)
* [http://www.halloweenmonsterlist.info/ MoNsTeRlIsT of Halloween Projects]
* [http://www.open-innovation-projects.org Open Innovation Projects] - Sammlung von offenen Projekten zu physischen Produkten, darunter etliche Mikrocontroller-Projekte. Man kann selber Projekte hinzufügen.

=== Referenzen, Beschreibungen, Standards ===
* Extraseite: [[Datenblätter]]
* [http://www.technick.net Technik.Net] Pinouts, Circuits and Guides
* [http://pinouts.ru/ pinout.ru] und [http://www.hardwarebook.info/ hardwarebook.info] - Online handbooks of hardware pinouts, cables schemes and connectors layouts
* [http://www.networktechinc.com/technote.html Keyboard, Monitor & Mouse Pinouts] for PC, SUN, MAC, USB, FireWire, RS232, Digital Flat Panel and EVC configurations
* [http://www.q1.fcen.uba.ar/materias/iqi/joygus/tvgames.html Special joysticks used in TV games]
* [http://www.cs.net/lucid/intel.htm Intel-Hex-Format]
* [http://home.teleport.com/~brainy/fat32.htm FAT32 Structure Information] - Written by Jack Dobiash
* [http://www.pjrc.com/tech/8051/ide/fat32.html Understanding FAT32 Filesystems] mit Beispielen (engl.)
* [http://www.rev-ed.co.uk/docs/picaxe_manual3.pdf Microcontroller Interfacing Circuits] - Revolution Education Ltd.

=== Online-Bücher ===
* [http://www.allaboutcircuits.com/ All About Circuits] - Series of online textbooks covering electricity and electronics. The information provided is great for both students and hobbyists who are looking to expand their knowledge in this field. (Englisch)
* http://www.computer-books.us/ - überwiegend zu höheren Programmiersprachen. Englisch.
* [http://www.vias.org/feee/index.html FEEE - Fundamentals of Electrical Engineering and Electronics]
* [http://www.nrbook.com/a/bookcpdf.php Numerical Recipes in C, Second Edition (1992)]
* [http://www.specamotor.de/freebook.php Electrical drives for precision engineering designs] Prof.dr.ir. Compter

=== Bedienungsanleitungen / Manuals ===
* [http://bama.edebris.com/manuals/ BAMA Archiv]
* [http://www.big-list.com/ Big-List.com] - This is a directory of over 600 dealers in used high technology equipment. Most deal in used electronic test equipment or semiconductor production equipment. Included are dealers in related high technology items, rental companies, equipment auction sites, test equipment manual dealers, foreign (non-U.S.) used equipment dealers, cal labs, and repair services.

=== Ungewöhnliche Basteleien (Hacks) ===
Auf eigene Gefahr und nicht immer ganz ernst... Meist in Englisch.

* Metablogs (tägliche News)
** [http://www.makezine.com/ Makezine]
** [http://www.hackaday.com/ Hack a Day]
** [http://www.hackedgadgets.com/ HackedGadgets]
** [http://www.hacknmod.com/ Hack N' Mod]

* Foren
** [http://www.fingers-welt.de/home.htm Fingers elektrische Welt]
** [http://forum.hackedgadgets.com/ HackedGadgets Forum]
** [http://stsboard.de Reparatur Forum]


* Projektsammlungen
** Final Projects der Kurse [http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/ ECE476] (Microcontroller Design) und [http://instruct1.cit.cornell.edu/courses/ece576/FinalProjects/ ECE576] (Advanced Microcontroller Systems on a Programmable Chip) an der Cornell University
** [http://www.coolcircuit.com/gadgets/ Cool Circuit]
** www.electronics-lab.com/blog/ <br> Stand 4.9.09: Warnung: Attackierende Webseite!

* DIY-Anleitungen
** [http://www.instructables.com/ instructables]
** [http://www.scitoys.com/ Scitoys] You Can Make With Your Kids

* Mix
** [http://www.evilmadscientist.com Evil Mad Scientist Laboratories] - u.a. The Flying Spaghetti Monster, on toast ;-)
** [http://home.earthlink.net/~lenyr/index.html Spark, Bang, Buzz and Other Good Stuff] ([http://www.sparkbangbuzz.com Neue Sachen])
** [http://www.electricstuff.co.uk/ Mike's Electric Stuff] - Antique Glass, Tesla coils and high-voltage stuff, Lasers
** [http://electricity.pbwiki.com/ DHS electricity]
** [http://www.elephantstaircase.com/wiki/index.php?title=Main_Page Elephant Staircase]
** [http://mycpu.eu Eine selbstgebaute CPU aus TTL-Gattern]
** [http://www.knollep.de/ Knolles Bauanleitungen]
** [http://www.ikalogic.com/index.php ikalogic.com]
** [http://www.electronicsinfoline.com/ Electronics Infoline]
** [http://www.uchobby.com/ uC Hobby]
** [http://elettrolinux.com elettrolinux] - Elektronik und Linux (engl.)

=== Zeitschriften über Elektronik und µC ===
* [http://www.eue24.net/ E&E Faszination Elektronik] - Das einzigartige Magazin für Elektronik-Entwickler und Elektronik-Interessierte
* [http://www.embedded.com embedded.com] - Hauptaugenmerk auf die Philosophie drumherum
* [http://www.siliconchip.com.au/ Silicon Chip] - Freie Artikel unter ''Free Preview''
* [http://www.circuitcellar.com/ Circuit Cellar] - Freie Artikel unter ''Digital Library''
* [http://www.elektronikpraxis.vogel.de/themen/hardwareentwicklung/mikrocontrollerprozessoren/ Elektronikpraxis - Das professionelle Elektronikmagazin]
* [http://www.funkamateur.de/ FUNKAMATEUR] - Elektronik, Amateurfunk, CB-Funk u. v. a. m.
* [http://www.edn.com/ EDN] (etwas schwer zu finden, aber lesenswert: die [http://www.edn.com/index.asp?layout=news&spacedesc=designIdeas Design Ideas])
* [http://www.franzis.de/elo-das-magazin ELO - Das Magazin] für Elektronik-Einsteiger
* [http://techonline.com/ TechOnline]
* [http://www.elektor.de/ Elektor]
* [http://www.techbriefs.com/tech-briefs/electronics-techbriefs NASA Tech Briefs] - Electronics & Computers
* [http://et.nmsu.edu/~etti/ Technology Interface Journal]
* [http://dev.emcelettronica.com/ Your Electronics Open Source]
* [http://www.element-14.com element14.com] is an information portal and community specifically built for electronic design engineers.

Diskussion:RFM12 Protokoll Stack

2009-07-23T19:48:42Z

Thymythos: /* Anregungen */

== Fehler ==

'''F:''' ''(17.09.2008)'' Im IE haben die Hamming-Tabellen alle einen schwarzen Hintergrund und schwarze Schrift (Im Firefox ist die Darstellung i.o.)<br>
'''A:''' Ich hab die Kurzschreibweise für Farben verwendet (#f12 statt #ff1122), ist aber eigentlich leider nur in CSS erlaubt... (Aber es scheint eine gute Methode zu sein um Inhalte vor IE nutzern zu verstecken *g*)<br><br>fixed!

== Anregungen ==

'''F:''' ''(31.08.2008)'' Ist der Code bereits benutzbar? Falls ja fände ein Beispielprogramm sehr hilfreich.<br>
'''A:''' Im LLC fehlt noch ein bisschen was, aber PHY und MAC sind benutzbar.

'''I:''' Der Hersteller empfiehlt 4 bytes Preamble zu senden.<br>
'''A:''' Kann man natürlich machen (und ist immernoch kompatible zum MAC). Bisher war's bei mir nicht nötig.

== Fragen ==

'''F:''' ''(04.09.2008)'' Warum gibt es auf LLC-Ebene keine Paketlängeninformation? (Jörg Wunsch)<br>
'''A:''' Overhead. Durch das Paketendezeichen ist die Länge definiert. Zugegeben, in manchen Applikationen erscheint es sinnvoll vor dem Empfang des Paketes die Länge zu wissen, aber IP hat z.B. dafür ein eigenes Feld.

'''F:''' ''(07.10.2008)'' Benutzung?
Der Stack auf Layer 3 sieht ja so eigentlich ganz einfach zu verwenden aus. Aber wie genau benutze ich den jetzt?
Die einfachste Methode wäre ja beim Layer 3 ein init und sofort Daten draufschieben. Aber ich sehe im Quellcode keine Verbindung zu beispielsweise RFM12_PHY_init(). Also um welche Funktionen muss ich mich wirklich kümmern, um auf Layer 3 Bytes hin und her zu schicken?
Und ist das bischen was am 31.08.2008 fehlte inzwischen drinne?

[[Benutzer:Malte|Malte]] 19:15, 7. Okt. 2008 (CEST)

'''A:''' So in etwa hab ich mir das API gedacht:
<c>
#include "rfm12_phy.h"
#include "rfm12_mac.h"
#include "rfm12_llc.h"

#define MY_RECEIVER 2
#define MY_PROTOCOL 13
#define BUF_SIZE 16

uint8_t *buffer = "Hello world";
uint8_t pos;

void myrx(uint8_t data) {
// TODO: handle rx data
}

int16_t mytx(void) {
if(pos < sizeof(buffer))
return txBuf[pos++];
return RFM12_L3_EOD;
}

void myack(bool ack) {
printf("Sending ");
if(ack) printf("OK\n");
else printf("failed\n");
}

void main() {
RFM12_L3_Protocol_t proto = {myrx, mytx, myack};

RFM12_PHY_init();
RFM12_MAC_init();
RFM12_MAC_setChannel(1);
RFM12_LLC_registerType(MY_PROTOCOL, proto);

while(1) {
while(RFM12_MAC_mediaBusy());
pos = 0;
RFM12_LLC_sendFrame(MY_PROTOCOL, MY_RECEIVER, false);
}
}
</c>

Diskussion:RFM12 Protokoll Stack

2009-07-23T19:48:23Z

Thymythos: /* Anregungen */

== Fehler ==

'''F:''' ''(17.09.2008)'' Im IE haben die Hamming-Tabellen alle einen schwarzen Hintergrund und schwarze Schrift (Im Firefox ist die Darstellung i.o.)<br>
'''A:''' Ich hab die Kurzschreibweise für Farben verwendet (#f12 statt #ff1122), ist aber eigentlich leider nur in CSS erlaubt... (Aber es scheint eine gute Methode zu sein um Inhalte vor IE nutzern zu verstecken *g*)<br><br>fixed!

== Anregungen ==

'''F:''' ''(31.08.2008)'' Ist der Code bereits benutzbar? Falls ja fände ein Beispielprogramm sehr hilfreich.<br>
'''A:''' Im LLC fehlt noch ein bisschen was, aber PHY und MAC sind benutzbar.

'''I:''' Der Hersteller empfiehlt 4 bytes Preamble zu senden.
'''A:''' Kann man natürlich machen (und ist immernoch kompatible zum MAC). Bisher war's bei mir nicht nötig.

== Fragen ==

'''F:''' ''(04.09.2008)'' Warum gibt es auf LLC-Ebene keine Paketlängeninformation? (Jörg Wunsch)<br>
'''A:''' Overhead. Durch das Paketendezeichen ist die Länge definiert. Zugegeben, in manchen Applikationen erscheint es sinnvoll vor dem Empfang des Paketes die Länge zu wissen, aber IP hat z.B. dafür ein eigenes Feld.

'''F:''' ''(07.10.2008)'' Benutzung?
Der Stack auf Layer 3 sieht ja so eigentlich ganz einfach zu verwenden aus. Aber wie genau benutze ich den jetzt?
Die einfachste Methode wäre ja beim Layer 3 ein init und sofort Daten draufschieben. Aber ich sehe im Quellcode keine Verbindung zu beispielsweise RFM12_PHY_init(). Also um welche Funktionen muss ich mich wirklich kümmern, um auf Layer 3 Bytes hin und her zu schicken?
Und ist das bischen was am 31.08.2008 fehlte inzwischen drinne?

[[Benutzer:Malte|Malte]] 19:15, 7. Okt. 2008 (CEST)

'''A:''' So in etwa hab ich mir das API gedacht:
<c>
#include "rfm12_phy.h"
#include "rfm12_mac.h"
#include "rfm12_llc.h"

#define MY_RECEIVER 2
#define MY_PROTOCOL 13
#define BUF_SIZE 16

uint8_t *buffer = "Hello world";
uint8_t pos;

void myrx(uint8_t data) {
// TODO: handle rx data
}

int16_t mytx(void) {
if(pos < sizeof(buffer))
return txBuf[pos++];
return RFM12_L3_EOD;
}

void myack(bool ack) {
printf("Sending ");
if(ack) printf("OK\n");
else printf("failed\n");
}

void main() {
RFM12_L3_Protocol_t proto = {myrx, mytx, myack};

RFM12_PHY_init();
RFM12_MAC_init();
RFM12_MAC_setChannel(1);
RFM12_LLC_registerType(MY_PROTOCOL, proto);

while(1) {
while(RFM12_MAC_mediaBusy());
pos = 0;
RFM12_LLC_sendFrame(MY_PROTOCOL, MY_RECEIVER, false);
}
}
</c>

Platinenhersteller

2009-07-18T15:43:08Z

Thymythos: Preisvergleichstabelle

== Einleitung ==
Die Vor- und Nachteile von Platinenherstellern/-lieferanten werden relativ häufig im [http://www.mikrocontroller.net/forum/platinen Forum] diskutiert (und führen ab und zu zu Flamewars :-). Damit man schnell einen Überblick über die verschiedenen Möglichkeiten erhält, soll hier eine Liste zusammengetragen werden.

Jeder kann/soll seinen Beitrag leisten, d.h. wenn man einen Platinenlieferanten kennt, der noch nicht erwähnt ist, einfach hinzufügen. Falls man den Hersteller nicht so gut kennt, einfach mal den Namen und die URL hinzufügen, es gibt sicherlich andere, die den Hersteller so gut kennen, dass sie sich zutrauen, ein Urteil über die Leistung zu fällen.

Eigentümer oder Mitarbeiter der gelisteten Firmen mögen bitte der Versuchung widerstehen, die Einträge mit werbeähnlichen Texten oder Werbung zu ergänzen. Zufriedene Kunden mögen bitte darauf achten, ihre Zufriedenheit so zu formulieren, dass nicht der Eindruck entsteht, der Eintrag sei von einem Hersteller zur "Verschönerung" gemacht worden.

PS.: Das Ganze soll so ähnlich werden wie [[Elektronik-Versender]], da hat das auch sehr gut geklappt!

'''Diese Seite kann nur von angemeldeten Benutzern bearbeitet werden!''' Bei neuen Einträgen bitte die Sortierung beachten.

Einige Hinweise, Hilfestellungen zur Platinenfertigung und Auftragsvergabe gibt es auch in der [http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.6 de.sci.electronics-FAQ].

===Preise===
Zur besseren Vergleichbarkeit bei jedem Hersteller dazu schreiben, was '''eine doppelseitige durchkontaktierte Eurokarte (160mm x 100mm) mit deutscher MwSt.''' ohne Versand kostet.
Dazu noch die Lieferzeit und ob Lötstopplack und Bestückungsdruck dabei ist.
''Zusätzlich'' kann man noch die Preise für andere Formate, Stückzahlen etc. dazu schreiben.

== Liste der Hersteller ==

=== Deutschland ===

==== amsTechnology ====
Homepage: http://www.amstechnology.de
* Leiterplatten und Bestückung (Prototypen und Kleinserien, bis hin zur Großserie)
* Sehr schnell
* Ein- und doppelseitige Leiterplatten, Multilayer.
* Layoutservice
* SMD- und THT Bestückung
* Gerätebau
* günstige Preise
* sehr gute Qualität
* Lieferzeit an 3 AT
* Bauelementebeschaffung auch schon bei 1 Stück (super funktioniert)

==== andus electronic ====
Homepage: http://www.andus.de
* Prototypen Fertigung
* Top Qualität
* Top Service
* Vergleichsweise Teuer

==== ANTtronic ====
Homepage: http://www.anttronic.de/pcb/

* gute Preise, aber Lieferzeit beachten!

==== Basista Leiterplatten ====
Homepage: http://www.basista.de
* Eurokarte doppelseitig für 52€ inkl. MwSt / mit Stopplack + Best.Druck 94€ inkl. MwSt
* Prototypen standardmäßig chemisch zinnbehandelt
* Preise OK
* Früher geliefert ohne Aufpreis (7 statt 10 AT)
* Qualität OK

==== Conti ====
Homepage: http://www.contag.de
* Berliner Platinenhersteller
* vergleichsweise teuer, aber dafür schnell (ab 4 Stunden!!)

==== Elischer Leiterplatten ====
e-mail: Melischer@aol.com
* sehr gute Preise, Qual.1A
* 3KW Lieferzeit
* Daten laut Google: Dipl.-Ing. A. Elischer, Am Forst 7, 72574 Bad Urach Tel. 07125-4498
* Layoutentwurf, LP Entwicklung, herstellen, bestücken, löten, prüfen

==== Fischer Leiterplatten GmbH ====
Homepage: http://www.f-l.de/
* 1 Europlatine inkl. Lack, ohne Bestückungsdruck für 46,50€ in 10 Tagen
* zweiseitig
* durchkontaktiert
* Lötstopp
* Bestückungsdruck einseitig
* Bohrungen no limit
* Verkauf nur an Gewerbetreibende

==== HAKA Elektronik-Leiterplatten GmbH ====
Homepage: http://www.haka-lp.de/
* bei Platinen kleiner 1 qdm gibt es entsprechend mehr ohne Aufpreis
* unter Angebote -> Zwillingsangebot gibt es 2 Europakarten (durchkontaktiert, Lötstop) für knapp 50,-, günstig, wenn man sich seines Layouts sicher ist - auch hierbei kostenlose Duplizierung kleinerer Layouts; Zwillingsangebot ist beschränkt auf Eagle- oder Target-3001-Dateien
* Lieferzeit 10 Werktage
* sehr gute Qualität



==== LEITON ====
Homepage: [http://www.leiton.de/ leiterplatten-online.de]
* Flexible Leiterplatten online kalkulieren
* Alle Layouts werden in der CAM eingehend geprüft
* Schnellste Bearbeitung von Anfragen
* Diverse Spezialfertigungen (Aluminiumkern, HF, hoch-Tg etc.)
* Fließender Übergang vom Prototyp in die Serie möglich
* Niederlassungen in Hongkong & China für Großserien (LeitOn HK Ltd.)
* Relativ günstig
* bei mehreren kleinen Leiterplatten wird nach Gesamtfläche berechnet, nicht nach Mindestfläche x Mindestpreis x Stückzahl
* Doppelseitige Europlatine mit Lötstop in 8 Tagen 61,25 Eur
* In 15 Tagen 49 Eur
* Gute Qualität
* Bis 8-lagig und ab 12 Std.

==== Microcirtec ====
Homepage: http://www.microcirtec.de
* Direct - Online - Shop — zum Kalkulieren-Bestellen und Kaufen
* Mit Auftragsverfolgung per Online
* Vom Rapid Prototyping bis zur Rapid Mass-Production
* Qualität betrachten wir als selbstverständlich

==== mmetoolshop / MME-Leiterplatten ====
Homepage: http://mme-pcb.de
eBay: http://stores.ebay.de/mmetoolshop
* Verkauft sowohl über die eigene Homepage als auch über eBay (zu identischen Konditionen)
* Europakarte: ES: 20,60 EUR, DSDK: 41,50 EUR
* Durchkontaktierung bei zweiseitigen Leiterplatten ist im Preis inbegriffen
* Trennen und Bohren inklusive
* Stopplack (11€) und Bestückungsdruck (16€) kosten extra
* min. Abstand 0,20 mm, min. Leiterbahnbreite 0,20 mm, kleinste Bohrung 0,4 mm

* Lieferzeit 8-12 Arbeitstage (bei mir waren es nur 5 Werktage)
* Überlieferung kostet nichts (häufig wird eine Leiterplatte mehr geliefert, bei mir waren es bei vier bestellten Platinen zwei mehr)
* Mit einer bestellten einseitigen Platine (DIL Bauteile) bin ich sehr zufrieden

==== Multi PCB Ltd. ====
Homepage: http://www.multipcb.de/leiterplatten.html

* nur für Gewerbetreibende
* Eurokarte doppelseitig mit Lötstopplack und Bestückungsdruck 78€ inkl. MwSt
* Online Kalkulator

* farbiger Lötstopplack und Bestückungsdruck möglich
* 48 Stunden Express
* Kompletter Design-Rule-Check der CAM-Daten
* Diverse Spezialfertigungen (Flex, Starrflex, Metallkern, HF, hoch-Tg, etc.)
* Sehr gute Qualität

==== M & V Leiterplatten - Vertriebs GmbH ====
Homepage: http://www.mvpcb.de/
* Bin sehr zufrieden, gute Preise, 10 - 14 Tage
* Top Qualität, nichts auszusetzen
* Qualität sehr gut, hohe Auflösung, auch SMD fine pitch möglich

==== PCB Pool ====
Homepage: http://www.pcb-pool.de/
* ideal für einzelne Boards und Klein(st)serien
* Preise im üblichen Rahmen
* Günstigere Preise für 10er oder 20er Auflage
* sehr gute Qualität
* Lieferzeit ab 2 AT
* SMD-Schablonen
* Kosten vor Bestellung eindeutig ersichtlich - keine unerwarteten Nebenkosten

==== Q-print/Q-PCB ====
Homepage: http://www.Q-PCB.de
* ideal für einzelne Boards und Klein(st)serien
* supergünstige Preise
* gute Qualität (u.U. Lötstop etwas unsauber)
* keine Zusatzpreise für 2x Lötstoplack o.ä.
* 150 µm kleinste Strukturbreite
* ohne Aufpreis bekommt man entweder HAL oder Ni/Au, gegen Aufpreis kann man aus einem von beiden wählen
* SMD-Schablonen
* Lieferzeit ab 4 AT
* Platine 50mm x 60mm, doppelseitig: ~45€ incl. Versand und Nachnahme
* Platine 100mm x 160mm, doppelseitig: 49€ +7€ für Lötstopp +7€ Versand

==== The PCB-Shop / Europrint Deutschland GmbH ====
Homepage: http://www.thepcbshop.com
* Punktabzug, da der Preisrechner nur mit Internet Explorer funktioniert
* gute Qualität
* guter Preis (inkl. gratis Überlieferungen - 30 kleine Platinen bestellt, 35 bekommen)
* wenig Statusinformationen (Link zur Statusseite kommt per Mail, dort ändert sich der Status und der Empfänger eigentlich täglich - ist aber trotzdem fristgerecht angekommen)

==== Würth Elektronik GmbH & Co. KG ====
Homepage: http://www.we-online.de
* gehört sicherlich nicht zu den preisgünstigsten
* kann Bauteile in der Leiterplatte fertigen (R, C, Potis u.a.)
* beherrscht Microvias in allen erdenklichen Varianten
* sehr kompetentes Ansprechpersonal

==== Onlineshop WEdirekt ====

Homepage: http://www.wedirekt.de
* PCB's in Basistechnologie, 2-8 Lagen
* SMD Schablonen in allen Ausführungen
* Europlatine doppelseitig mit Lötstopplack 67€ inkl. MwSt
* Design- und Applikationsfachbücher rund um EMV


=== Deutschland sehr günstige===
Diese Hersteller zeichnen sich durch einen sehr günstigen Preis von '''unter 30€ pro doppelseitiger Eurokarte''' aus und können '''keine Durchkontaktierungen''' herstellen.

==== Cadgrafik Bauriedl (nur Filme) ====
Homepages: http://cadgrafik-bauriedl.de/leiterplattenfilme.htm

* Überträgt Layouts auf hochwertige Folie/Film zum Selberätzen
* 1,15 € / 100 cm² Film, 2,50 € Mindestbestellwert (Stand März 2009)
* 2 € Porto (Stand März 2009)

==== EBC Utz Kohl ====
Homepage: [http://www.e-b-c-elektronik.de http://www.e-b-c-elektronik.de]
* recht einfach gehalten, daher wirklich günstig
* Ideal für den Bastler, denen es auf den Preis ankommt
* Geätzt einseitig Euroformat 160 x 100mm 16,- EUR (zzgl 1,- EUR Entsorgungspauschale pro Platine)
* Geätzt doppelseitig Euroformat 160 x 100mm 26,20 (zzgl 2,- EUR Entsorgungspauschale pro Platine)
* doppelseitige Platinen sind nicht durchkontaktiert !
* eigentlich ein Ladengeschäft, versendet jedoch auch

==== Objektif Leiterplatten Ätzstudio ====
e-mail: objektif@gmx.de
* Europlatine ab 7,-- Euro
* hohe Qualität
* Lieferzeit 1 bis 2 Wochen
* Keine Durchkontaktierungen möglich

==== Platinenbelichter ====
Homepage: http://www.platinenbelichter.de
* sehr preiswert
* Ein- und Doppelseitig bis 300x200mm
* eine doppelseitige Europlatine kostet 13,50 EUR Grundpreis + Bohrung 1,8cent + Optionen
* Keine Durchkontaktierungen möglich
* Lieferzeit von bis zu 8 '''Arbeits'''tagen nach Geldeingang

==== Platinendesign ====
Homepage: http://www.platinendesign.de/
* sehr preiswert
* Ein- und Doppelseitig bis 200x250mm
* eine doppelseitige Europlatine kostet 14 EUR Grundpreis + Bohrung 2cent + Optionen
* keine Angabe ob Durchkontaktiert
*Lötstoplack grün
* Lieferzeit von bis zu 8 '''Arbeits'''tagen nach Geldeingang

=== Ausland ===

==== BatchPCB ====
Homepage: http://www.batchpcb.com (USA)
* Vermittler und keine eigene Herstellung ("PCB pooling service"), Hersteller vermutlich meist [[Platinenhersteller#Gold Phoenix|Gold Phoenix]]
* verbandelt mit Sparkfun ("off shoot of Spark Fun Electronics")
* "We only offer one service at this time: 2 layer PCBs with soldermask both sides and silkscreen both sides. The minimum trace width is 8mil with 8 mil spacing."
* relativ günstig, lange Lieferzeiten, weiteres siehe Homepage und [http://www.batchpcb.com/faq.php BatchPCB FAQ]

==== BILEX-LP ====
Homepage http://www.bilex-lp.com/ (Bulgarien)
* deutschsprechender Ansprechpartner
* liefern bleifreie Platinen(RoHs konform)
* 31€ für eine doppelseitige Eurokarte ohne Lack und Druck
* SMD- und THT Bestückung
* Layoutservice
* Lieferzeit ab 3-4 AT
* insgesamt von 5 bis 7 AT Anlieferung bei Airmail (Porto ab 4,-Euro)
* FedEx wollte von Bulgarien aus ab 27,-Euro, 1-2AT)
* Löcher größer 6 mm wurden nicht gebohrt, sondern gefreast(gegen Anfrage)
* Berichtete Qualitätsmängel (mglw. Einzelfälle): ausgefranste Plantinenfräsung, Lötstoplack hebt ab(nur bei Sn-Pb beschichtung, nehmen Sie besser Ni-Au).
* Fräsungen müssen extra bestellt werden! Aber trotzdem guenstig

==== CUBE CZ s.r.o. ====
Homepage http://www.cube.cz/ (Tschechische Republik)

==== Euro PCB Ltd. ====
Homepage http://www.europcb.com/ (Großbritannien)
* Günstige Leiterplatten
* Schnelle Lieferung
* Qualitativ OK

==== Gold Phoenix ====
Homepage http://www.goldphoenixpcb.biz/ (VR China)

==== MakePCB ====
Homepage http://www.makepcb.com/ (Shanghai, VR China)

==== OLIMEX Ltd. ====
Homepage http://www.olimex.com (Bulgarien)

Habe mehrere Jahre bei Olimex meine Prototypen herstellen lassen. Stets saubere Arbeit erhalten. Bis ich denen mal falsche Gerber-Dateien zusandte. Als ich einige Stunden spaeter den Fehler bemerkt hatte, bat ich um Stornierung und Neuzusendung. Gegen ein zusaetzliches Entgelt wurde dies akzeptiert.
Die angesagten Zusatzkosten wurden zwar von mir nicht abgebucht, aber ich erhielt 1 Woche spaeter die anfaenglich falsch zugesandten PCB's.
Die Zusammenfassung des darauffolgenden Email-Verkehrs: Ein Schulterzucken seitens Olimex und die Bitte, eine neue, kostenpflichte Bestellung zu taetigen.

==== PAD2PAD ====
Homepage http://www.pad2pad.com/ (USA)
* Bestücken die Platinen auch mit Digikey-Bauteilen.

==== PCBCart ====
Homepage http://www.pcbcart.com/ (China)
* auch kompliziertere Designs
* schnell und zuverlässig

==== PCBPro ====
Homepage http://www.pcbpro.com/ (USA)
* Bei größeren Mengen (z.B. 100 Stück) sehr niedrige Preise

==== Top-Tec-PCB ====
Homepage http://www.top-tec-pcb.com/ (Großbritannien)
* Günstig für Klein- bis Großserien
* Discount bei Nachbestellung
* sehr gute Technik (z.B. 100µm Bohren oder 75µm Leiterbahn)
* deutschsprechender Ansprechpartner
* liefern bleifreie Platinen (HAL, chem. Gold, Silber u. Zinn)
* 48h Eildienst

==== The PCB Shop ====
Homepage http://www.thepcbshop.com/ (Belgien)
* Für einfache Sachen

==== PIU-Printex ====
Homepage http://www.piu-printex.at/ (Österreich)

== Preisvergleichstabelle (Stand Juli 2009) ==

Preise für ein oder zwei Europlatinen (160x100), doppelseitig, kein Druck, inkl. MwSt, ohne Versand.

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
!Hersteller || Preis (€) 1x || Preis (€) 2x
|-
|''ohne Lötstopp''
|----
!Basista Leiterplatten
| 43,66 || 81,61
|----
!Fischer Leiterplatten GmbH
| 39,00 || 80,00
|-
!HAKA Elektronik-Leiterplatten GmbH
| 45,00 || 49,88
|-
!LEITON
| 39,98 || 76,01
|-
!MME-Leiterplatten
| 41,44 || ?
|-
!PCB Pool
| 50,27 || 100,54
|-
!Q-print/Q-PCB
| 48,89 || ?
|-
|''mit Lötstopp''
|-
!Multi PCB Ltd.
| 65,60 || 131,20
|-
!M & V Leiterplatten - Vertriebs GmbH
| 62,82 || ?
|-
!Onlineshop WEdirekt
| 67,06 || 94,01
|}



[[Category:Platinen]]

RFM12

2009-01-13T17:19:59Z

Thymythos: /* Status Read */

Beschreibung der Funkmodule RFM01, RFM02 und RFM12.

Benötigt werden in der Minimal-Version im FIFO-Modus nur die Anschlüsse nSEL, SDO, SDI und SCK, eben das komplette SPI-Interface. Der Zugriff auf das Sende- und Empfangs-FIFO ist per Software möglich, ebenso die Abfrage der Statusbits. Deshalb werden z.B. nIRQ und nFFS nicht unbedingt benötigt. nIRQ signalisiert unter anderem, dass das Modul bereit ist Daten zu empfangen. Wenn Daten empfangen wurden, kann dies über den FFIT-Pin abgefragt werden (falls die Füllschwelle eingestellt wurde). nFFS dient dazu das FIFO direkt anzusprechen (es ist quasi der Chipselect für das FIFO), davon wird in der Minimalversion aber kein Gebrauch gemacht. Der Pin muss daher auf high-Pegel gelegt werden!
An CLK kann eine Frequenz von 1MHz bis 10MHz eingestellt werden. Hiermit kann dann z.B. der Mikrocontroller versorgt werden.
Reset ist ein Open-Collector-Ausgang und gleichzeitig der Reset-Eingang. Er sollte daher entweder gar nicht, oder aber hochohmig angeschlossen werden.

Im FIFO-Mode kann das Modul konfiguriert werden mit dem Empfang zu warten, bis die Daten 0x2DD4 empfangen wurden. Sobald dieses Bitmuster empfangen wurde, werden Daten in das FIFO geschrieben, bis man das FIFO abschaltet und die Mustererkennung neu startet.

Als weitere Modi stehen unter anderem ein synchroner Modus zur Verfügung (no FIFO mode), in dem der Sender/Empfänger den Bittakt ausgibt, und synchron dazu die zu sendenden Daten einliest bzw. die empfangenen Daten ausgibt. Der SPI Bus ist trotzdem zur Initialisierung des Moduls notwendig.

== FAQ ==

=== SPI Interface ===

* Maximale Datenrate: 2,5MHz (10MHz Quarz / 4)

=== CLK-Ausgang bleibt bei 1 MHz ===

* Vor dem Umschalten (mit 0xC0E0) länger warten.

=== RFM12 empfängt ein paar Bytes, dann nur Müll ===

* Es wird zu langsam gesendet (TX FIFO underrun)
* Es wird zu langsam empfangen (RX FIFO overrun)

Die Status-Bits helfen hier beim Debuggen. SPI sollte auf maximaler Transferrate stehen.

=== RFM empfängt nur Müll ===

http://www.mikrocontroller.net/topic/73560#605528

Deine Module verhalten sich normal. Man muß mit den Gain- und AFC-Bits
eine ganze Weile spielen, bis die Module korrekt laufen (kommt auf die
Anwendung an). Fakt ist: der Empfänger empfängt ständig Datenmüll als
Rauschen. Wenn der FIFO durch die Präambel getriggert wird, sind die
Daten im FIFO ziemlich korrekt, wenn alles "gut" eingestellt ist. Der
FIFO sollte per Interrupt dann auch sofort abgeholt werden, da sonst das
nächste Byte das alte direkt überschreibt. Jeder zusammenhängende
Datensatz (mehrere Bytes an einem Stück) muß von einer Präambel
eingeleitet werden. Nach dem kompletten Einlesen eines Datensatzes muß
der FIFO abgeschaltet, wieder eingeschaltet und für den Empfang der
nächsten Präambel neu scharf gemacht werden.

=== RFM hängt sich auf ===

Wenn man die AFC nicht begrenzt, also keinen Wertebereich vorgibt, die eine maximale Abweichung korrigiert wird passiert es nach einer Weile, dass sich der Empfänger aufhängt, die Offsetbits im Status werden maximal und dann geht gar nichts mehr, er hängt fest.

Siehe auch
* Forenbeitrag [http://www.mikrocontroller.net/topic/82456#689660 RFM12: Erfahrungen ]

=== Kommunikation mit RFM funktioniert nur sporadisch ===

* Ist die Versorgungsspannung stabil? (evtl. Kondensator einbauen)

----

== Register ==

Von https://www.mikrocontroller.net/attachment/24947/RFM12.txt

Dieses Dokument beschreibt die Nutzung des RFM12 TRX Moduls!

''' WICHTIG '''

Dieses Dokument wurde aus mehreren Quellen zusammengestellt, und kann Fehler enthalten!
Es können Abweichungen in Bezug auf RF01 / RF02 / RF12 / RFM01 / RFM02 und andere Module auftreten!
Es wurde das Datenblatt vom RFM12B und RF12 von www.hoperf.com als Basis genuzt. Zusätzlich wurden diese Informationen mit Hilfe von Forums-Nutzern (https://www.mikrocontroller.net/topic/71682) weiter vervollständigt!

''' WICHTIG '''

'''Hinweis:''' Die LNA-Eingangsimpedanz beträgt 250 Ohm, und muss beim Anschluss einer 50-Ohm-Antenne entsprechend angepasst werden, um das Rauschen zu minimieren! '' -- (Auf den Pollin-Modulen bereits vorhanden)''

=== Configuration Setting ===
Hex = 80 & xx
Bit-Syntax:
{| cellpadding="2" cellspacing="0" border="1"
!width="20%"| Byte ||width="40%"| 1 || 2
|-
!Bits
|{{8Bit|width=100%| 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 }}||{{8Bit|width=100%| el | ef | b1 | b0 | x3 | x2 | x1 | x0}}|}
el (TX FIFO) = Sendepuffer für Datentransfer nutzen (1 = An / 0 = Aus)
ef (RX FIFO) = Empfangspuffer für Datenspeicherung nutzen (1 = An / 0 = Aus)
b... = Zu nutzende Basisfrequenz (00=315MHz / 01=433MHz / 10=868MHz / 11=915MHz)
x... = Interner Clock des Chips kann durch verschieben einer Kondensator-Anpass-Stufe bestimmt werden.
0,5pF pro Schritt. Basis ist 8,5pF -> (0000=8,5 / 0001=9,0 / 0010=9,5 / ...)

=== Power-Managment ===
Hex = 82 & xx
Bit-Syntax: 10000010 | er | ebb | et | es | ex | eb | ew | dc
er = Empfänger einschalten (1 = an / 0 = Aus)
ebb = ... (Synthesizer muss aktiv sein!) (1 = an / 0 = aus)
et = Sender einschalten (1 = an / 0 = Aus) (Wenn das TX-Register aktiv und mit Daten gefüllt ist/wurde,
werden diese Daten sofort gesendet) (1 = an / 0 = aus)
es = Schaltet den Synthesizer ein. (1 = an / 0 = aus)
ex = Schaltet den Quarz-Oszilator ein. (1 = an / 0 = aus)
eb = Vergleichbar mit BrownOutDetection -> Erkennt eine zu geringe Betriebsspannung und erzeugt einen Interrupt,
um einen drohenden Spannungsaufall anzukündigen (1 = An / 0 = Aus)
ew = Aktiviert den WakeUpTimer des Prozessors. (1 = an / 0 = aus)
dc = Deaktiviert die Ausgabe des SystemClocks auf dem CLK Pin am Chip (1 = Keine ClockAusgabe / 0 = Clock ausgeben)

=== PLL Setting ===
Hex = 198 + y
Bit-Syntax: 110011000 | ob1 | ob0 | lpx | ddy | ddit | bw1 | bw0
ob... = ... (00= 5 oder 10MHz [standard] / 01=3.3MHz / 1x=2.5MHz oder weniger)
lpx = Wählt den Low-Power-Mode für den Quarz-Oszilator aus. (0=1ms [620µA] / 1=2ms [460µA])
ddy = ...
ddi = Schaltet das Dithering in PLL-Schleife ab. (1=abgeschaltet / 0=eingeschaltet)
bw... = Wählt die Bandbreite des PLL-Signals aus. (00=86.2kbps [-107dBc/Hz] / 01=256kbps [-102dBc/Hz]) Bei 1MHz Offset Phasenrauschen.

=== LowBatt / µC Clock Control ===
Hex = c0 & xx
Bit-Syntax: 11000000 | d2 | d1 | d0 | v4 | v3 | v2 | v1 | v0
d... = Bestimmt den Teilungsfaktor für die Clockausgabe am CLK-Pin in Abhängigkeit des Internen SystemTakts.
(000=1 / 001=1.25 / 010=1.66 / 011=2 / 100=2.5 / 101=3.33 / 110=5 / 111=10)
v... = Bestimmt die Minimalspannung, ab der ein Interrupt durchgeführt werden
muss. (Ähnlich einer BrownOutDetection). Im Power-Managment muss das eb-Bit
aktiv sein, damit dies funktioniert.

=== Frequency-setting ===
Bestimmt den Offset der Sende- und Empfangsfrequenz. Dieser Offset wird auf das Basisband im Configuration Setting hinzu gerechnet.
Hex = a & xxx
Bit-Syntax:
{| cellpadding="2" cellspacing="0" border="1"
!width="20%"| Byte ||width="40%"| 1 || 2
|-
!Bits
|{{8Bit|width=100%| 1 | 0 | 1 | 0 | f11 | f10 | f9 | f8 }}||{{8Bit|width=100%| f7 | f6 | f5 | f4 | f3 | f2 | f1 | f0}}|}

f... = Bestimmt den Offsetwert der Frequenz.
Als Basis gilt das eingestellte Band im Configuration-Settings-Kommando

freq = 10 * C1 * (C2 + f/4000) [MHz]

{| cellspacing="0" border="1" style="text-align:center;"
! Band || C1 || C2
|-
| 315 || 1 || 31
|-
| 433 || 1 || 43
|-
| 868 || 2 || 43
|-
| 915 || 3 || 30
|}

=== Data-Rate ===
Hex = c6 & xx
Bit-Syntax: 11000110 | cs | r6 | r5 | r4 | r3 | r2 | r1 | r0
cs = Vorteiler, Faktor 7. Hiermit kann ein Vorteiler aktiviert werden,
der die errechnete Baudrate (r...) durch 7 teilt.
r... = Baudratenteilerfaktor

=== RX Control ===
Hex = 94 & xx
Bit-Syntax: 10010 | p20 | d1 | d2 | i2 | i1 | i0 | g1 | g0 | r2 | r1 | r0
p20 = Bestimmt die Funktion des Pin20 (nINT / VDI) am RFM12 Chip (1 = VDI-Ausgang / 0 = Interrupt-Eingang)
d... = (Valid Data Indicator). Definiert die Geschwindigkeit, mit der bestimmt wird, ob ein Signal korrekt ist, oder nicht.
(00=schnell / 01=mittel / 10=langsam / 11=immer an). Je nach eingestellter Variante werden
unterschiedliche Hardware- und Software-Kombinationen genuzt.
Fast: CR_Lock OR DQD ... Medium: CR_Lock AND ( DRSSI OR DQD ) ...
SLOW: R/S FlipFlop aus (SET) DRSSI OR DQD OR CR_Lock und (CLR) DRSSI AND DQD AND CR_Lock .
i... = Bestimmt die Bandbreite des Empfängers in KHz (KiloHertz).
(000=Reserviert / 001=400 / 010=340 / 011=270 / 100=200 / 101=134 / 110=67 / 111=Reserviert)
g... = (LNA-Gain) Verstärkungsfaktor des Rauscharmen-Eingangs-Signal-Verstärkers (LNA Low Noise Amplifier).
Werte in dBm (Dezibel [Grösse: Milliwatt]) Mögliche Werte sind: 0 / -6 / -14 / -20
r... = (DRSSI = Digital Received Signal Strength Indication) Minimale Empfangssignalfeldstärke.
6 dBm pro Schritt: (000=-103 / 001=-97 / 010=-91 / ...)

=== Synchron Pattern ===
Hex = ce & xx
Bit-Syntax: 11001110 | b7 | b6 | b5 | b4 | b3 | b2 | b1 | b0
b... = Legt den Wert fest, der als Synchronisations-Byte für die Datenfilterung verwendet werden soll.

=== Data Filter ===
Hex = c2 & xx
Bit-Syntax: 11000010 | al | ml | -unknow- (1) | s | -unknow- (1) | f2 | f1 | f0
al = Baudratenregenerator schaltet automatisch in den langsamen Modus,
sobald er einen Takt erkannt hat.
ml = schneller/langsamer Modus
-unknown- (1) = ??? (Standard = 1) (Auch im Datenblatt von IA4420 so beschrieben)
s = (DataFilter) Typ des Datenfilters (0=DigitalFilter / 1=AnalogFilter).
Bei Nutzung des Analog-Filters kann kein FIFO sowie kein ClockRecovery genuzt werden.
-unknown- (1) = ??? (Standard = 1) (Auch im Datenblatt von IA4420 so beschrieben)
f... = (DQD Threshold) Bestimmt den Schwellwert, ab dem ein Signal als gut empfunden wird,
und der Empfänger dieses weiterverarbeiten soll.
DQD (data quality detection) zählt die "Spikes" des ungefilterten Signals, und bestimmt darüber die Qualität der Daten.

=== FIFO und RESET-Mode ===
Hex = ca & xx
Bit-Syntax: 11001010 | f3 | f2 | f1 | f0 | sp | al | ff | dr
f... = (FIFO interrupt Level)
sp = (Sync-Pattern length) Legt die Länge des Synchron-Patterns fest
(0 = 2Byte / 1 = 1Byte)
al = (FIFO Fill Condition) Legt den Wert fest, ab dem das Füllen des FIFOs beginnt.
(0=Synchron / 1=Ständig). Bei Nutzung des Synchron-Modus, werden erst dann Daten in den FIFO geschrieben,
wenn eine definierte 8-Bit od. 16-Bit lange Datenfolge empfangen wurde (Standard ist Hex: 2dd4,
das LSB kann geändert werden und stellt das 8-Bit Synchron-Pattern dar).
ff = (FIFO Fill) Startet das Einlesen der empfangenen Daten in den FIFO-Puffer.
Wenn al (FIFO Fill Condition) auf synchron steht, dann startet das Setzen dieses Bits die Synchronisation-Bit-Erkennung.
dr = (Sens Reset Mode) Wenn dieses Bit auf 0 steht, wird bei einer Schwankung von 200mV auf
der VCC-Leitung (Spannungsversorgung des Chips), ein System-Reset ausgelöst.

=== Automatic Frequency Control ===
Hex = c4 & xx
Bit-Syntax: 11000100 | a1 | a0 | rl1 | rl0 | st | fi | oe | en
a... = Modus der AFC-Schaltung, 0=Auto, 1=einmalig nach Einschalten, 2=Solange VDI low ist, 3=unabhängig von VDI
r... = (Range Limit) Frequenzraster (00=KeineBegrenzung / 01=+15 > -16 / 10=+7 > -8 / 11=+3 > -4)
st = Berechneten Offset-Wert übernehmen
fi = Genauer Berechnungsmodus (besser aber lansgamer)
oe = AFC-Offset freischalten
en = AFC-Berechnung aktivieren

=== TX Configuration Control ===
Hex = 98 & xx
Bit-Syntax: 1001100 | mp | m3 | m2 | m1 | m0 | -unknow- (0) | p2 | p1 | p0
mp = (Modulation Polarity) Bestimmt die Richtung der FSK-Erzeugung (invertiert das Spektrum).
m... = (fDeviation) Bestimmt den Frequenzabstand des High- und Low-Wertes bei der Ubertragung im FSK-Betrieb. Basis ist der mp-Wert.
-unknown- (0) = ??? (Standard = 0) (Auch im Datenblatt von IA4420 so beschrieben)
p... = Bestimmt die relative Ausgangsleistung des Senders anhand des dBm-Wertes (Dezibel [Grösse: Milliwat]) 3-dBm-Schritte.
(000=0 / 001=-3 / 010=-6 / ...). Der Wert steht im Zusammenhang mit der angeschlossenen Antennen-Impedanz.

=== Wake-Up Timer ===
Bestimmt die Zeitperiode der zyklischen Einschaltung des WakeUp-Timers
Hex = e & xxx
Bit-Syntax: 111 | R4 | R3 | R2 | R1 | R0 | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0
R = Exponent der Zeit
M = Zeit

=== Low Duty-Cycle ===

Bestimmt die maximale Sendezeit pro Stunde. Dies ist wichtig, um sich an gesetzliche Frequenzzuteilungsrichtlinien zu halten, die bestimmen, wie lang jemand mit einer definierten Sendeleistung auf einer bestimmten Frequenz (mit eventuell definierter Betriebsart [Modulationstyp]) senden darf.)

hex = 6400 + Bits
Bit-Syntax: 1100100 | r| d6 | d5 | d4 | d3 | d2 | d1 | d0 | en
r = ??????????????????
d... = Einschaltdauer während der zyklischen Einschaltung
en = zyklische Einschaltung aktivieren

=== RX FIFO Read ===
Hex = b000
Bit-Syntax: 1011000000000000

Dieses Kommando löst die Rückgabe eines Datenbytes (synchron mit dem 8. Bit) aus. Es ist nötig, dass das ef-Bit (RX-FIFO) im Configuration Setting gesetzt wurde, um diese Funktion nutzen zu können!

=== TX Register Write ===
Dieses Kommando schreibt Daten in den TX-Puffer. Wenn der Sender aktiv ist, wird dieses sofort gesendet. el (TX-Register) muss im Configuration-Setting-Kommando aktiv sein.
Hex = b8 & xx
Bit-Syntax: 10111000 | DataByteToSend
DataByteToSend = Das Datenbyte, welches gesendet werden soll.

(Senden Funktioniert nur wenn zuvor der Status abgefragt wurde)

=== Status Read ===
Dieses Kommando löst die Rückgabe des Statusregisters aus, welches nach der ersten 0 im ersten Bit synchron übertragen wird.
Hex = 0000
Bit-Syntax: 0000000000000000<000>
Rückgabe-Syntax: x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | x10 | x11 | x12 | x13 | x14 | x15 | x16 | x17 | x18
x0 -> x5 = Interrupt bits
x6 -> x15 = Status Bits
x16 -> x18 = FIFO
x0 = FFIT / RGIT (RGIT = TX-Register ist bereit neue Daten zu senden ... kann mit dem TX-Register gelöscht werden)
(FFIT = Die Anzahl der Datenbits im FIFO-Puffer hat das eingestellte Limit erreicht.
Kann mit einer der FIFO-Lesemethoden gelöscht werden)
x1 = POR (PowerOnReset)
x2 = FFOV / RGUR (RGUR = Der Datenstrom beim Senden ist abgerissen, da nicht schnell genug Daten nachgeladen wurden)
(FFOV = Der RX-FIFO ist übergelaufen)
x3 = WKUP
x4 = EXT (Externer IRq vom nINT-Pin)
x5 = LBD (Low Battery Detected)
x6 = FFEM (Der FIFO-Puffer ist leer/EMpty)
x7 = RSSI/ATS (ATS = )(RSSI = Die Signalstärke ist über dem eingestelltem Limit)
x8 = DQD
x9 = CRL
x10 = ATGL
x11 = OFFS_6 (sign of offset)
x12 = OFFS_3
x13 = OFFS_2
x14 = OFFS_1
x15 = OFFS_0
x16 = FO
x17 = FO+1
x18 = FO+2

== Bezugsquellen ==
* [[Elektronikversender#csd-electronics|csd-electronics]]
* [[Elektronikversender#IT-WNS|IT-WNS]]
* [[Elektronikversender#Pollin_Electronic|Pollin Electronic]]

== Links ==

* [[AVR RFM12]]
* [[RFM12 Protokoll Stack]]
* [http://www.mikrocontroller.net/topic/93801 Bezugsquellen]
* [http://roulette.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12 Library zur Ansteuerung des RFM12]

Folgende Links sind mit Vorsicht zu genießen, da die Datenblätter teilweise fehlerbehaftet sind. Es empfiehlt sich, direkt mit dem Datenblatt des RF12 (das ist das IC auf dem Modul) zu arbeiten. Dieses ist so gut wie fehlerfrei.

* [http://www.hoperf.com/pdf/RF12.pdf Datenblatt des ICs RF12] (PDF)
* [http://www.hoperf.com/pdf/RFM12.pdf Datenblatt des Moduls RFM12] (PDF)
* [http://www.hoperf.com/pdf/RF12_code.pdf Programming Guide] (PDF)
* [http://www.hoperf.com/pdf/RF12TOOLS.pdf Demo Kit User Manual] (PDF)
* [http://www.pollin.de/shop/downloads/D810047S.ZIP Beispielprogramm von Pollin] (ZIP)

[[Kategorie:Bauteile]]
[[Kategorie:Funk]]

FIFO

2008-12-05T14:50:38Z

Thymythos: /* FIFO mit C-Präprozessor */ neu

Ein FIFO (<b>F</b>irst-<b>I</b>n-<b>F</b>irst-<b>O</b>ut) ist ein Pufferspeicher nach dem "Warteschlangen-Prinzip". Pufferspeicher dienen dazu, für einen Prozessor Daten aufzufangen, die er noch nicht verarbeiten kann. Ein FIFO funktioniert definitionsgemäß so, dass das erste Element (First In), welches "hinten" in die Warteschlange eingefügt wird, später auch als erstes "vorne" herausgeholt wird (First Out).

Das Gegenstück zu FIFO ist LIFO, worunter man einen dem "Stapel-Prinzip" folgenden Pufferspeicher versteht (Last In - First Out; Elemente werden stets "oben auf den Stapel" gelegt und auch stets von oben wieder heruntergenommen).

Ein bekanntes Beispiel für einen FIFO-Speicher ist der des [[UART]]s im PC. Dieser sammelt ankommende Daten solange, bis er fast voll ist (meist 14 Bytes). Dann wird ein [[Interrupt]] ausgelöst und der Prozessor kann "auf einen Rutsch" alle Daten auf einmal auslesen. Ganz am Anfang hatten UARTs keinen FIFO und erzeugten für jedes empfangene Byte einen Interrupt, so wie es heute noch die meisten Mikrocontroller machen. Damit ist aber die CPU-Belastung wesentlich höher, was bei höheren Datenraten zu Problemen führen kann.

Die Umsetzung eines FIFOs in Software heißt Ringpuffer und weist auch eine feste Puffergröße auf. Wesentlicher Vorteil gegenüber der verketteten Liste ist die schnellere Ausführungszeit und der geringere Aufwand.

== Standard-Ringpuffer ==

Vorteile:
* Simpel
* Leicht verständlich
* Daten können auch vom Typ struct sein

Nachteile:
* Schell aber nicht optimal

=== Beschreibung ===
{|
|-
|
[[Bild:Ringpuffer.png|300px]]
|
[[Bild:Circular buffer.png|200px]]
|}

Die Inhalte des Puffers werden in einem schlichten Array gespeichert und der Zugriff erfolgt über einen Integer-Index. Erreicht ein Index die Obergrenze springt dieser auf Null zurück. Ein größer-gleich statt nur eines ist-gleich Vergleichs ist sicherer gegenüber Programmfehlern, bei denen der Index verstellt wurde.
<c>
write = write + 1;
if (write >= BUFFER_SIZE)
write = 0;
</c>
Haben Lese- und Schreib-Index den gleichen Wert wird der Puffer als leer angesehen. Wenn write+1 und read identisch sind wird der Puffer als voll angesehen. Nun fehlt noch der Sonderfall bei dem read gleich Null ist, hier funktioniert der write+1-Vergleich nicht mehr und die Abfrage einer zusätzlichen Bedingung ist zur voll-Abfrage erforderlich.

<c>
read == write => leer

write + 1 == read || read == 0 && write+1 == BUFFER_SIZE => voll
</c>

Bei gleichzeitigem Zugriff zwischen UART-ISR und Hauptprogramm muss ausgeschlossen werden, dass das Hauptprogramm beim Lesen aus dem Puffer nicht durch den Interrupt unterbrochen werden kann. Ansonsten können Programmabstürze passieren, deren Ursache oft nicht nachvollziehbar ist. Als Abhilfe dienen [[Interrupt#Atomarer_Datenzugriff|Atomare Abschnitte]], solche können durch keinen Interrupt unterbrochen werden. Die Radialkur deaktiviert alle Interrupts, besser ist die Deaktivierung eines einzelnen Interrupts. Im Allgemeinen werden versäumte Interrupte nach erneuter Aktivierung nachgeholt, da ein Flag gesetzt wurde. Wichtig ist vorallem, dass die Ausführungszeit des Atomaren Abschnitts und der ISR geringer ist als der Intervall in dem Interrupte erfolgen, da ansonsten ein Interrupt verloren gehen könnte.

<c>
cli()
ret = BufferOut(&var);
sei()
</c>

=== Code-Beispiel ===
<c>
#define BUFFER_SIZE 23

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

uint8_t BufferIn(uint8_t byte)
{
//if (write >= BUFFER_SIZE)
// write = 0; // erhöht sicherheit

if (buffer.write + 1 == buffer.read || buffer.read == 0 && buffer.write + 1 == BUFFER_SIZE)
return FAIL; // voll

buffer.data[buffer.write] = byte;

write = write + 1;
if (write >= BUFFER_SIZE)
write = 0;
}

uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return FAIL;
*pByte = buffer.data[buffer.read];

buffer.read = buffer.read + 1;
if (buffer.read >= BUFFER_SIZE)
buffer.read = 0;
return SUCCESS;
}
</c>

== 2<sup>n</sup>-Ringpuffer - die schnellste Lösung ==

Vorteile:
* Durch Bitmaske auf den Feld-Index ''write'' kann der nicht "Amoklaufen" und beliebige Inhalte im Speicher überschreiben
* Sehr einfach, sehr schnell
* Daten können auch vom Typ ''struct'' sein
Nachteile:
* Nur Größenfaktoren von 2<sup>n</sup> möglich
* Nur in speziellen Fällen Pointerreferenz möglich

=== Beschreibung ===

Wenn der Index am oberen Ende angekommen ist springt er an den Anfang zurück. Die Definition der Obergrenze wird nicht durch einen Vergleich realisiert, sondern durch Modulo-Arithmetik. Dies kann sehr einfach und schnell durch Maskieren des Index-Werts umgesetzt werden.

Beispiel:
<c>
( write + 1 ) & MASK

15 = 0b00001111
15 + 1 = 16 = 0b000010000
16 & MASK = 0b000010000 & 0b000001111 = 0b000000000
</c>

Daraus folgt das ''write'' nur einen Wert zwischen 0 und 15 einnehmen kann. Das ganze funktioniert nur mit Zahlen der Reihe 2<sup>n</sup>.

Da der Puffer nur eine endliche Größe aufweist, muss eine voll/leer Indikation verfügbar sein. read == write bedeutet Puffer leer, entsprechend bedeutet write + 1 == read, dass keine weiteren Elemente mehr hinzugefügt werden können, denn sonst würde das Hinzufügen weiterer Daten einen Pufferüberlauf hervorrufen. Für die Behandlung des Pufferüberlaufs gibt es zwei Methoden, nichts tun und Fehler zurück geben oder ältesten Puffer-Inhalt verwerfen (read+1).

<c>
read == ((write + 1) & MASK)
</c>

Auch hier verhindert die Bitmaske einen möglichen Überlauf. Weiter zu beachten ist, dass ein Byte durch die voll/leer Indikation verloren geht, der Puffer hat hier nur eine größe von 15 statt 16 Byte

Und noch ein kleiner Trick. Bei einer Zahl der Reihe 2^n lässt sich auf einfache Weise immer eine passende Bitmaske erzeugen und man sieht gleichzeitig klar die Anzahl der genutzten Bytes.

<c>
# define SIZE 16
# define MASK (SIZE-1)

16 = 0b010000
16 - 1 = 0b001111
</c>

Im Normalbetrieb sollte der Puffer nie voll ausgereizt sein und wenn der Puffer bereits überläuft ist es für die Systemstabilität und Fehleranlyse oft schon zu spät, denn von einem nicht mehr funktionierenden Gerät lässt sich nur wenig Information herauskitzeln. Da kann ein Frühwarmsystem mehr bieten, wobei zwei Ausprägungen typisch sind, Höchstwert merken und eine Meldeschwelle einführen.

<c>
freeMemory = (read - write - 1 ) & MASK);
if (freeMemory < floodmark)
floodmark = freeMemory;
</c>

<c>
if ( (read - write - 1 ) & MASK) <= FLOODMARK;
FloodmarkExcess();
</c>

=== Code-Beispiel ===

<c>
#define BUFFER_SIZE 16 // muss 2^n betragen (8, 16, 32, 64 ...)
#define BUFFER_MASK (BUFFER_SIZE-1) // Klammern auf keinen Fall vergessen

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

uint8_t BufferIn(uint8_t byte)
{
uint8_t next = ((buffer.write + 1) & BUFFER_MASK);
if (buffer.read == next)
return FAIL;
buffer.data[buffer.write] = byte;
// buffer.data[buffer.write & BUFFER_MASK] = byte; // absolut Sicher
buffer.write = next;
}

uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return FAIL;
*pByte = buffer.data[buffer.read];
buffer.read = (buffer.read+1) & BUFFER_MASK;
return SUCCESS;
}
</c>

=== FIFO mit C-Präprozessor ===

<c>
#ifndef FIFO_H_
#define FIFO_H_

#include <stdint.h>

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[64];
} FIFO64_t;

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[128];
} FIFO128_t;

#define FIFO_init(fifo) { fifo._read = 0; fifo._write = 0; }

#define FIFO_available(fifo) ( fifo._read != fifo._write )

#define FIFO_read(fifo, size) ( \
(FIFO_available(fifo)) ? \
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
)

#define FIFO_write(fifo, data, size) { \
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
if(tmphead != fifo._read) { /* if buffer is not full */ \
fifo._write = tmphead; /* store new index */ \
fifo._buffer[tmphead] = data; /* store data in buffer */ \
} \
}

#define FIFO64_read(fifo) FIFO_read(fifo, 64)
#define FIFO64_write(fifo, data) FIFO_write(fifo, data, 64)

#define FIFO128_read(fifo) FIFO_read(fifo, 128)
#define FIFO128_write(fifo, data) FIFO_write(fifo, data, 128)

#endif /*FIFO_H_*/
</c>

== Weblinks ==
* [http://en.wikipedia.org/wiki/Circular_buffer Circular buffer], englische Wikipedia

[[Kategorie:Grundlagen]]

AVR RFM12

2008-11-30T14:44:26Z

Thymythos: /* Flashcraft Funkboard */ Level 3, Bild rechts

Schaltungen und Software für AVR und das Funkmodul [[RFM12]].

== SVN ==

svn://mikrocontroller.net/rfm12

Wegen Zugangsdaten bitte bei [http://www.mikrocontroller.net/user/show/andreas Andreas Schwarz] melden.

----

== Software ==

=== Treiber ===

[http://www.mikrocontroller.net/attachment/22473/rfm12_pc.zip Firmware v1.0.0] von Benedikt K.

[http://www.mikrocontroller.net/attachment/23542/RMxx_Driver.tar.bz2 Firmware v2.0.1] von Jürgen Eckert

{| border="1" cellspacing="0"
|+ Funktionalität
|-
! || Beschreibung || Software
|-
!1. Stufe:
| Die Daten von der seriellen Schnittstelle werden über die Funkstrecke auf die serielle Schnittstelle der anderen Seite übertragen. (Wir freuen uns über jedes Byte das ankommt)
| [http://www.mikrocontroller.net/topic/67273#564945 Claude Schwarz], [http://www.mikrocontroller.net/topic/71682#584915 Benedikt K.] oder [http://www.mikrocontroller.net/attachment/36742/RFM12_V3.zip Manuel Stahl]
|-
! 2. Stufe:
| Es findet eine Fehlererkennung (z.B. mit CRC-Summen) statt. Fehlerhafte Daten werden erneut angefordert. Dadurch gehen auf der Funkstrecke keine Daten verloren und es werden keine Daten verfälscht.
| [http://www.mikrocontroller.net/topic/71682#585851 Benedikt K.]
|-
! 3. Stufe:
| Die Datenübertragung wird individualisiert. Dadurch können zwei Funkstrecken, die im gleichen Empfangsbereich liegen nebeneinander arbeiten, ohne sich zu beeinträchtigen.
| [[RFM12_Protokoll_Stack]]
|-
! 4. Stufe:
| Die Datenübertragung wird verschlüsselt und damit abhörsicher.
|
|-
!5. Stufe:
| Neben den Daten der seriellen Schnittstelle werden auch Änderungen der Statusleitungen übertragen. Damit erhält man eine "RS232-Verlängerung" über eine Funkstrecke, die fehlerfrei arbeitet und zu einer Drahtverbindung weitestgehend kompatibel ist.
|
|}

=== RS232 <-> RFM12 ===

TODO

=== USB <-> RFM12 ===

Mit '''[http://www.obdev.at/products/avrusb/index.html avrusb]''' lässt sich ein USB-Slave in Software emulieren.

* '''[http://www.recursion.jp/avrcdc/ AVR-CDC]''' läuft mit Anpassung der USB-Pins. ''(Zumindest unter Windows an einem USB2.0-Port)''

Adapter für '''[http://www.embedded-projects.net/?page_id=135 USBprog]:'''

* Funktionierender Code liegt im oben genannten SVN
* Implementiert die USB-CDC-Klasse (kein Treiber nötig)
* Sicherung der Übertragung durch Hamming-Code
* Work in progress... (Manuel Stahl)

----

== Hardware ==

=== Basismodul V1.0 ===

'''Prozessor'''

ATmega8 TQFP32 (kompatibel ATmega48, ATmega88, ATmega168)

'''Schnittstellen'''

* RS232
* I²C:
* USB
* GPIO

'''Platine'''

[[Bild:AVR RFM12 Schematic.png|200px|ATmega48 + USB]]
[[Bild:AVR RFM12 Board TOP.png|220px|2-lagig top]]
[[Bild:AVR RFM12 Board BOTTOM.png|240px|2-lagig bottom]]
[[Bild:AVR_RFM12_Photo.jpg|240px|Photo]]

<div style="float:left; border-right:1px solid gray; padding-right:10px;">
'''Bauteile:'''

Größe: SMD 0603

* R1, R2: 68R (nur USB)
* R3, R4: 10k
* R5: 1k5 (nur USB)
* C1, C2: 22pF
* C3 - C9: 100nF
* Q1: 12Mhz (nur USB)
* D1, D2: beliebig, Minimelf
* IC3: MAX3221CUE
</div>

<div style="float:left; border-right:1px solid gray; padding: 0px 0px 10px 10px; width:33%">
'''Kosten:'''

* MiniUSB SMD: '''1,25€'''
* HF-Buchse MMCX: '''4,25€'''
* ATmega48: '''2,85€'''
* MAX3221CUE: '''1,10€'''
* Quarz 12Mhz 30ppm: '''1,19€'''
* Kleinkram: '''< 1,10€'''

* habe ein verbindliches Angebot für 24 Stück von http://mme-pcb.de/: '''4,00€ pro Platine'''
</div>

<div style="float:left; padding: 0px 0px 10px 10px; width:33%">
''' Bugs / Erweiterungen:'''

* Der 1,5k Widerstand muss direkt an den VCC-Pin angelötet werden (Pad ist nicht verbunden)
* Beim Fertigen wurde das Polygon, welches das VCC-Signal durch die eine Ecke des ATmega48 leitet, unterbrochen. Hier hilft nur eine Drahtbrücke.
* Unter den RFM12 und unter das Quarz am Besten Isolierband kleben!
* Beim Programmieren sollte der SEL des RFM12 (J1 der zweite Pin vom RS232 aus) auf VCC gelegt werden
</div>
<div style="clear:both"></div>

[http://www.mikrocontroller.net/attachment/24012/RFM12.brd Board (Eagle)]:

[[Bild:AVR RFM12 Board top bestuecken.png|200px|top]]
[[Bild:Board bottom bestuecken.png|200px|bottom]]
----

=== Flashcraft Funkboard ===

[http://flashcraft.de/index.php/funkboard-uebersicht Homepage des Projekts]

Eine andere Funklösung mit dem RFM12 bietet das '''Open Source''' Flashcraft Funkboard von Florian Scherb.

[[Bild:Flashcraft_funkboard_pic.jpg|right]]

'''Es enthält'''
* Funkboard Platine
* Code für AVR
* PC Terminalprogramm
* Dokumentation

'''Überblick:'''

# Über 55 Seiten starke Dokumentation
# PC Terminalprogramm zum Testen und Konfigurieren
# Abmessungen: 32x34mm, Montage durch 2 Stiftleisten im 2,54mm Raster
# ATmega32 übernimmt komplette Ansteuerung
# 3 Schnittstellen sind vorgesehen: I2C, SPI, UART (derzeit nur UART)
# SMA-Antennenanschluss
# Niedrige Stromaufnahme: 40mA im normalen Betrieb, 2 Schlafmodis mit Stromverbrauch bis min. 25µA!
# Betriebsspannungsbereich von 3,2 - 5,4V (mit ATmega32L)
# 5V oder 3V Spannungsregler onBoard! Direkter Batteriebetrieb möglich; Kann externe Schaltung versorgen!
# uvm.

'''Außerdem:'''

# Kontrolle über fast alle Konfigurationen, direkt im Betrieb änderbar, kein Umprogrammieren notwendig!
# Zahlreiche Sicherheitsfeatures wie Acknowledge, CRCs,...
# RS232-Treiberbaustein MAX3221 onBoard. Damit TTL- und RS232-UART möglich
# Clock Takt am Funkboard abgreifbar, z.B. für externen Mikrocontroller
# Totzeiten ca. 1,5 Millisekunden beim Wechsel zwischen Sende- und Empfangsbetrieb
# uvm.

'''Schaltpläne, Board-Layout, Sourcecodes und andere Files sind auf der [http://flashcraft.de/index.php/funkboard-uebersicht Homepage] des Funkboard-Projekts verfügbar.'''
----

=== USBprogRFM12 ===

Da der USBprog genau das SPI-Interface des ATmega32 zur Verfügung stellt, eignet er sich perfekt als USB-RFM12-Adapter.

[[Bild:USBprogRFM12_schematic.png|200px|USBprogRFM12]] [[Bild:USBprogRFM12_board.png|200px|USBprogRFM12]]

[[Bild:USBprogRFM12.jpg|400px|USBprogRFM12]]

----

== Links ==

* [http://www.mikrocontroller.net/topic/65984 Allgemeine Diskussion]
* [http://www.mikrocontroller.net/topic/71682 bidirektionale RS232 Funkbrücke mit RFM12]
* [http://www.das-labor.org/wiki/Datenfunk_mit_dem_AVR Datenfunk mit dem AVR] bei das-labor.org

[[Kategorie:Projekte]]
[[Kategorie:AVR]]
[[Kategorie:Funk]]

Vorlage:8Bit

2008-11-29T15:08:33Z

Thymythos:

{| cellpadding="2" cellspacing="0" border="0" width="{{{width}}}"
|- style="font-size:80%"
! style="border-right:1px solid gray;" | 0
! style="border-right:1px solid gray;" | 1
! style="border-right:1px solid gray;" | 2
! style="border-right:1px solid gray;" | 3
! style="border-right:1px solid gray;" | 4
! style="border-right:1px solid gray;" | 5
! style="border-right:1px solid gray;" | 6
! 7
|- style="text-align:center"
| width="12.8%" style="border-right:1px solid gray;" | {{{1}}}
| width="12.8%" style="border-right:1px solid gray;" | {{{2}}}
| width="12.8%" style="border-right:1px solid gray;" | {{{3}}}
| width="12.8%" style="border-right:1px solid gray;" | {{{4}}}
| width="12.8%" style="border-right:1px solid gray;" | {{{5}}}
| width="12.8%" style="border-right:1px solid gray;" | {{{6}}}
| width="12.8%" style="border-right:1px solid gray;" | {{{7}}}
| width="12.8%" | {{{8}}}
|}

<noinclude>
Diese Vorlage kann zum Formatieren von Bytes verwendet werden.

<nowiki>
{{Vorlage:8Bit|width=200| a | b | c | d | e | f | g | h }}
</nowiki>
</noinclude>

RFM12

2008-11-29T14:51:27Z

Thymythos: /* Frequency-setting */

Beschreibung der Funkmodule RFM01, RFM02 und RFM12.

Benötigt werden in der Minimal-Version im FIFO-Modus nur die Anschlüsse nSEL, SDO, SDI und SCK, eben das komplette SPI-Interface. Der Zugriff auf das Sende- und Empfangs-FIFO ist per Software möglich, ebenso die Abfrage der Statusbits. Deshalb werden z.B. nIRQ und nFFS nicht unbedingt benötigt. nIRQ signalisiert unter anderem, dass das Modul bereit ist Daten zu empfangen. Wenn Daten empfangen wurden, kann dies über den FFIT-Pin abgefragt werden (falls die Füllschwelle eingestellt wurde). nFFS dient dazu das FIFO direkt anzusprechen (es ist quasi der Chipselect für das FIFO), davon wird in der Minimalversion aber kein Gebrauch gemacht. Der Pin muss daher auf high-Pegel gelegt werden!
An CLK kann eine Frequenz von 1MHz bis 10MHz eingestellt werden. Hiermit kann dann z.B. der Mikrocontroller versorgt werden.
Reset ist ein Open-Collector-Ausgang und gleichzeitig der Reset-Eingang. Er sollte daher entweder gar nicht, oder aber hochohmig angeschlossen werden.

Im FIFO-Mode kann das Modul konfiguriert werden mit dem Empfang zu warten, bis die Daten 0x2DD4 empfangen wurden. Sobald dieses Bitmuster empfangen wurde, werden Daten in das FIFO geschrieben, bis man das FIFO abschaltet und die Mustererkennung neu startet.

Als weitere Modi stehen unter anderem ein synchroner Modus zur Verfügung (no FIFO mode), in dem der Sender/Empfänger den Bittakt ausgibt, und synchron dazu die zu sendenden Daten einliest bzw. die empfangenen Daten ausgibt. Der SPI Bus ist trotzdem zur Initialisierung des Moduls notwendig.

== FAQ ==

=== SPI Interface ===

* Maximale Datenrate: 2,5MHz (10MHz Quarz / 4)

=== CLK-Ausgang bleibt bei 1 MHz ===

* Vor dem Umschalten (mit 0xC0E0) länger warten.

=== RFM12 empfängt ein paar Bytes, dann nur Müll ===

* Es wird zu langsam gesendet (TX FIFO underrun)
* Es wird zu langsam empfangen (RX FIFO overrun)

Die Status-Bits helfen hier beim Debuggen. SPI sollte auf maximaler Transferrate stehen.

=== RFM empfängt nur Müll ===

http://www.mikrocontroller.net/topic/73560#605528

Deine Module verhalten sich normal. Man muß mit den Gain- und AFC-Bits
eine ganze Weile spielen, bis die Module korrekt laufen (kommt auf die
Anwendung an). Fakt ist: der Empfänger empfängt ständig Datenmüll als
Rauschen. Wenn der FIFO durch die Präambel getriggert wird, sind die
Daten im FIFO ziemlich korrekt, wenn alles "gut" eingestellt ist. Der
FIFO sollte per Interrupt dann auch sofort abgeholt werden, da sonst das
nächste Byte das alte direkt überschreibt. Jeder zusammenhängende
Datensatz (mehrere Bytes an einem Stück) muß von einer Präambel
eingeleitet werden. Nach dem kompletten Einlesen eines Datensatzes muß
der FIFO abgeschaltet, wieder eingeschaltet und für den Empfang der
nächsten Präambel neu scharf gemacht werden.

=== RFM hängt sich auf ===

Wenn man die AFC nicht begrenzt, also keinen Wertebereich vorgibt, die eine maximale Abweichung korrigiert wird passiert es nach einer Weile, dass sich der Empfänger aufhängt, die Offsetbits im Status werden maximal und dann geht gar nichts mehr, er hängt fest.

Siehe auch
* Forenbeitrag [http://www.mikrocontroller.net/topic/82456#689660 RFM12: Erfahrungen ]

=== Kommunikation mit RFM funktioniert nur sporadisch ===

* Ist die Versorgungsspannung stabil? (evtl. Kondensator einbauen)

----

== Register ==

Von https://www.mikrocontroller.net/attachment/24947/RFM12.txt

Dieses Dokument beschreibt die Nutzung des RFM12 TRX Moduls!

''' WICHTIG '''

Dieses Dokument wurde aus mehreren Quellen zusammengestellt, und kann Fehler enthalten!
Es können Abweichungen in Bezug auf RF01 / RF02 / RF12 / RFM01 / RFM02 und andere Module auftreten!
Es wurde das Datenblatt vom RFM12B und RF12 von www.hoperf.com als Basis genuzt. Zusätzlich wurden diese Informationen mit Hilfe von Forums-Nutzern (https://www.mikrocontroller.net/topic/71682) weiter vervollständigt!

''' WICHTIG '''

'''Hinweis:''' Die LNA-Eingangsimpedanz beträgt 250 Ohm, und muss beim Anschluss einer 50-Ohm-Antenne entsprechend angepasst werden, um das Rauschen zu minimieren! '' -- (Auf den Pollin-Modulen bereits vorhanden)''

=== Configuration Setting ===
Hex = 80 & xx
Bit-Syntax:
{| cellpadding="2" cellspacing="0" border="1"
!width="20%"| Byte ||width="40%"| 1 || 2
|-
!Bits
|{{8Bit|width=100%| 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 }}||{{8Bit|width=100%| el | ef | b1 | b0 | x3 | x2 | x1 | x0}}|}
el (TX FIFO) = Sendepuffer für Datentransfer nutzen (1 = An / 0 = Aus)
ef (RX FIFO) = Empfangspuffer für Datenspeicherung nutzen (1 = An / 0 = Aus)
b... = Zu nutzende Basisfrequenz (00=315MHz / 01=433MHz / 10=868MHz / 11=915MHz)
x... = Interner Clock des Chips kann durch verschieben einer Kondensator-Anpass-Stufe bestimmt werden.
0,5pF pro Schritt. Basis ist 8,5pF -> (0000=8,5 / 0001=9,0 / 0010=9,5 / ...)

=== Power-Managment ===
Hex = 82 & xx
Bit-Syntax: 10000010 | er | ebb | et | es | ex | eb | ew | dc
er = Empfänger einschalten (1 = an / 0 = Aus)
ebb = ... (Synthesizer muss aktiv sein!) (1 = an / 0 = aus)
et = Sender einschalten (1 = an / 0 = Aus) (Wenn das TX-Register aktiv und mit Daten gefüllt ist/wurde,
werden diese Daten sofort gesendet) (1 = an / 0 = aus)
es = Schaltet den Synthesizer ein. (1 = an / 0 = aus)
ex = Schaltet den Quarz-Oszilator ein. (1 = an / 0 = aus)
eb = Vergleichbar mit BrownOutDetection -> Erkennt eine zu geringe Betriebsspannung und erzeugt einen Interrupt,
um einen drohenden Spannungsaufall anzukündigen (1 = An / 0 = Aus)
ew = Aktiviert den WakeUpTimer des Prozessors. (1 = an / 0 = aus)
dc = Deaktiviert die Ausgabe des SystemClocks auf dem CLK Pin am Chip (1 = Keine ClockAusgabe / 0 = Clock ausgeben)

=== PLL Setting ===
Hex = 198 + y
Bit-Syntax: 110011000 | ob1 | ob0 | lpx | ddy | ddit | bw1 | bw0
ob... = ... (00= 5 oder 10MHz [standard] / 01=3.3MHz / 1x=2.5MHz oder weniger)
lpx = Wählt den Low-Power-Mode für den Quarz-Oszilator aus. (0=1ms [620µA] / 1=2ms [460µA])
ddy = ...
ddi = Schaltet das Dithering in PLL-Schleife ab. (1=abgeschaltet / 0=eingeschaltet)
bw... = Wählt die Bandbreite des PLL-Signals aus. (00=86.2kbps [-107dBc/Hz] / 01=256kbps [-102dBc/Hz]) Bei 1MHz Offset Phasenrauschen.

=== LowBatt / µC Clock Control ===
Hex = c0 & xx
Bit-Syntax: 11000000 | d2 | d1 | d0 | v4 | v3 | v2 | v1 | v0
d... = Bestimmt den Teilungsfaktor für die Clockausgabe am CLK-Pin in Abhängigkeit des Internen SystemTakts.
(000=1 / 001=1.25 / 010=1.66 / 011=2 / 100=2.5 / 101=3.33 / 110=5 / 111=10)
v... = Bestimmt die Minimalspannung, ab der ein Interrupt durchgeführt werden
muss. (Ähnlich einer BrownOutDetection). Im Power-Managment muss das eb-Bit
aktiv sein, damit dies funktioniert.

=== Frequency-setting ===
Bestimmt den Offset der Sende- und Empfangsfrequenz. Dieser Offset wird auf das Basisband im Configuration Setting hinzu gerechnet.
Hex = a & xxx
Bit-Syntax:
{| cellpadding="2" cellspacing="0" border="1"
!width="20%"| Byte ||width="40%"| 1 || 2
|-
!Bits
|{{8Bit|width=100%| 1 | 0 | 1 | 0 | f11 | f10 | f9 | f8 }}||{{8Bit|width=100%| f7 | f6 | f5 | f4 | f3 | f2 | f1 | f0}}|}

f... = Bestimmt den Offsetwert der Frequenz.
Als Basis gilt das eingestellte Band im Configuration-Settings-Kommando

freq = 10 * C1 * (C2 + f/4000) [MHz]

{| cellspacing="0" border="1" style="text-align:center;"
! Band || C1 || C2
|-
| 315 || 1 || 31
|-
| 433 || 1 || 43
|-
| 868 || 2 || 43
|-
| 915 || 3 || 30
|}

=== Data-Rate ===
Hex = c6 & xx
Bit-Syntax: 11000110 | cs | r6 | r5 | r4 | r3 | r2 | r1 | r0
cs = Vorteiler, Faktor 7. Hiermit kann ein Vorteiler aktiviert werden,
der die errechnete Baudrate (r...) durch 7 teilt.
r... = Baudratenteilerfaktor

=== RX Control ===
Hex = 94 & xx
Bit-Syntax: 10010 | p20 | d1 | d2 | i2 | i1 | i0 | g1 | g0 | r2 | r1 | r0
p20 = Bestimmt die Funktion des Pin20 (nINT / VDI) am RFM12 Chip (1 = VDI-Ausgang / 0 = Interrupt-Eingang)
d... = (Valid Data Indicator). Definiert die Geschwindigkeit, mit der bestimmt wird, ob ein Signal korrekt ist, oder nicht.
(00=schnell / 01=mittel / 10=langsam / 11=immer an). Je nach eingestellter Variante werden
unterschiedliche Hardware- und Software-Kombinationen genuzt.
Fast: CR_Lock OR DQD ... Medium: CR_Lock AND ( DRSSI OR DQD ) ...
SLOW: R/S FlipFlop aus (SET) DRSSI OR DQD OR CR_Lock und (CLR) DRSSI AND DQD AND CR_Lock .
i... = Bestimmt die Bandbreite des Empfängers in KHz (KiloHertz).
(000=Reserviert / 001=400 / 010=340 / 011=270 / 100=200 / 101=134 / 110=67 / 111=Reserviert)
g... = (LNA-Gain) Verstärkungsfaktor des Rauscharmen-Eingangs-Signal-Verstärkers (LNA Low Noise Amplifier).
Werte in dBm (Dezibel [Grösse: Milliwatt]) Mögliche Werte sind: 0 / -6 / -14 / -20
r... = (DRSSI = Digital Received Signal Strength Indication) Minimale Empfangssignalfeldstärke.
6 dBm pro Schritt: (000=-103 / 001=-97 / 010=-91 / ...)

=== Synchron Pattern ===
Hex = ce & xx
Bit-Syntax: 11001110 | b7 | b6 | b5 | b4 | b3 | b2 | b1 | b0
b... = Legt den Wert fest, der als Synchronisations-Byte für die Datenfilterung verwendet werden soll.

=== Data Filter ===
Hex = c2 & xx
Bit-Syntax: 11000010 | al | ml | -unknow- (1) | s | -unknow- (1) | f2 | f1 | f0
al = Baudratenregenerator schaltet automatisch in den langsamen Modus,
sobald er einen Takt erkannt hat.
ml = schneller/langsamer Modus
-unknown- (1) = ??? (Standard = 1) (Auch im Datenblatt von IA4420 so beschrieben)
s = (DataFilter) Typ des Datenfilters (0=DigitalFilter / 1=AnalogFilter).
Bei Nutzung des Analog-Filters kann kein FIFO sowie kein ClockRecovery genuzt werden.
-unknown- (1) = ??? (Standard = 1) (Auch im Datenblatt von IA4420 so beschrieben)
f... = (DQD Threshold) Bestimmt den Schwellwert, ab dem ein Signal als gut empfunden wird,
und der Empfänger dieses weiterverarbeiten soll.
DQD (data quality detection) zählt die "Spikes" des ungefilterten Signals, und bestimmt darüber die Qualität der Daten.

=== FIFO und RESET-Mode ===
Hex = ca & xx
Bit-Syntax: 11001010 | f3 | f2 | f1 | f0 | -unknow- (0) | al | ff | dr
f... = (FIFO interrupt Level)
-unknown- (0) = ??? (Standard = 0) (Auch im Datenblatt von IA4420 so beschrieben)
al = (FIFO Fill Condition) Legt den Wert fest, ab dem das Füllen des FIFOs beginnt.
(0=Synchron / 1=Ständig). Bei Nutzung des Synchron-Modus, werden erst dann Daten in den FIFO geschrieben,
wenn eine definierte 16Bit-Datenfolge empfangen wurde (Standard ist Hex: 2dd4).
ff = (FIFO Fill) Startet das Einlesen der empfangenen Daten in den FIFO-Puffer.
Wenn al (FIFO Fill Condition) auf synchron steht, dann startet das Setzen dieses Bits die Synchronisation-Bit-Erkennung.
dr = (Sens Reset Mode) Wenn dieses Bit auf 0 steht, wird bei einer Schwankung von 200mV auf
der VCC-Leitung (Spannungsversorgung des Chips), ein System-Reset ausgelöst.

=== Automatic Frequency Control ===
Hex = c4 & xx
Bit-Syntax: 11000100 | a1 | a0 | rl1 | rl0 | st | fi | oe | en
a... = Modus der AFC-Schaltung, 0=Auto, 1=einmalig nach Einschalten, 2=Solange VDI low ist, 3=unabhängig von VDI
r... = (Range Limit) Frequenzraster (00=KeineBegrenzung / 01=+15 > -16 / 10=+7 > -8 / 11=+3 > -4)
st = Berechneten Offset-Wert übernehmen
fi = Genauer Berechnungsmodus (besser aber lansgamer)
oe = AFC-Offset freischalten
en = AFC-Berechnung aktivieren

=== TX Configuration Control ===
Hex = 98 & xx
Bit-Syntax: 1001100 | mp | m3 | m2 | m1 | m0 | -unknow- (0) | p2 | p1 | p0
mp = (Modulation Polarity) Bestimmt die Richtung der FSK-Erzeugung (invertiert das Spektrum).
m... = (fDeviation) Bestimmt den Frequenzabstand des High- und Low-Wertes bei der Ubertragung im FSK-Betrieb. Basis ist der mp-Wert.
-unknown- (0) = ??? (Standard = 0) (Auch im Datenblatt von IA4420 so beschrieben)
p... = Bestimmt die relative Ausgangsleistung des Senders anhand des dBm-Wertes (Dezibel [Grösse: Milliwat]) 3-dBm-Schritte.
(000=0 / 001=-3 / 010=-6 / ...). Der Wert steht im Zusammenhang mit der angeschlossenen Antennen-Impedanz.

=== Wake-Up Timer ===
Bestimmt die Zeitperiode der zyklischen Einschaltung des WakeUp-Timers
Hex = e & xxx
Bit-Syntax: 111 | R4 | R3 | R2 | R1 | R0 | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0
R = Exponent der Zeit
M = Zeit

=== Low Duty-Cycle ===

Bestimmt die maximale Sendezeit pro Stunde. Dies ist wichtig, um sich an gesetzliche Frequenzzuteilungsrichtlinien zu halten, die bestimmen, wie lang jemand mit einer definierten Sendeleistung auf einer bestimmten Frequenz (mit eventuell definierter Betriebsart [Modulationstyp]) senden darf.)

hex = 6400 + Bits
Bit-Syntax: 1100100 | r| d6 | d5 | d4 | d3 | d2 | d1 | d0 | en
r = ??????????????????
d... = Einschaltdauer während der zyklischen Einschaltung
en = zyklische Einschaltung aktivieren

=== RX FIFO Read ===
Hex = b000
Bit-Syntax: 1011000000000000

Dieses Kommando löst die Rückgabe eines Datenbytes (synchron mit dem 8. Bit) aus. Es ist nötig, dass das ef-Bit (RX-FIFO) im Configuration Setting gesetzt wurde, um diese Funktion nutzen zu können!

=== TX Register Write ===
Dieses Kommando schreibt Daten in den TX-Puffer. Wenn der Sender aktiv ist, wird dieses sofort gesendet. el (TX-Register) muss im Configuration-Setting-Kommando aktiv sein.
Hex = b8 & xx
Bit-Syntax: 10111000 | DataByteToSend
DataByteToSend = Das Datenbyte, welches gesendet werden soll.

(Senden Funktioniert nur wenn zuvor der Status abgefragt wurde)

=== Status Read ===
Dieses Kommando löst die Rückgabe des Statusregisters aus, welches nach der ersten 0 im ersten Bit synchron übertragen wird.
Hex = 0000
Bit-Syntax: 0000000000000000<000>
Rückgabe-Syntax: x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | x10 | x11 | x12 | x13 | x14 | x15 | x16 | x17 | x18
x0 -> x5 = Interrupt bits
x6 -> x15 = Status Bits
x16 -> x18 = FIFO
x0 = FFIT / RGIT (RGIT = TX-Register ist bereit neue Daten zu senden ... kann mit dem TX-Register gelöscht werden)
(FFIT = Die Anzahl der Datenbits im FIFO-Puffer hat das eingestellte Limit erreicht.
Kann mit einer der FIFO-Lesemethoden gelöscht werden)
x1 = POR (PowerOnReset)
x2 = FFOV / RGUR (RGUR = Der Datenstrom beim Senden ist abgerissen, da nicht schnell genug Daten nachgeladen wurden)
(FFOV = Der RX-FIFO ist übergelaufen)
x3 = WKUP
x4 = EXT
x5 = LBD
x6 = FFBM (Der FIFO-Puffer ist leer)
x7 = RSSI/ATS (ATS = )(RSSI = Die Signalstärke ist über dem eingestelltem Limit)
x8 = DQD
x9 = CRL
x10 = ATGL
x11 = OFFS_4
x12 = OFFS_3
x13 = OFFS_2
x14 = OFFS_1
x15 = OFFS_0
x16 = FO
x17 = FO+1
x18 = FO+2

== Bezugsquellen ==
* [[Elektronikversender#csd-electronics|csd-electronics]]
* [[Elektronikversender#IT-WNS|IT-WNS]]
* [[Elektronikversender#Pollin_Electronic|Pollin Electronic]]

== Links ==

* [[AVR RFM12]]
* [[RFM12 Protokoll Stack]]
* [http://www.mikrocontroller.net/topic/93801 Bezugsquellen]

Folgende Links sind mit Vorsicht zu genießen, da die Datenblätter teilweise fehlerbehaftet sind. Es empfiehlt sich, direkt mit dem Datenblatt des RF12 (das ist das IC auf dem Modul) zu arbeiten. Dieses ist so gut wie fehlerfrei.

* [http://www.hoperf.com/pdf/RF12.pdf Datenblatt des ICs RF12] (PDF)
* [http://www.hoperf.com/pdf/RFM12.pdf Datenblatt des Moduls RFM12] (PDF)
* [http://www.hoperf.com/pdf/RF12_code.pdf Programming Guide] (PDF)
* [http://www.hoperf.com/pdf/RF12TOOLS.pdf Demo Kit User Manual] (PDF)
* [http://www.pollin.de/shop/downloads/D810047S.ZIP Beispielprogramm von Pollin] (ZIP)

[[Kategorie:Bauteile]]
[[Kategorie:Funk]]

RFM12

2008-11-29T14:12:56Z

Thymythos: /* Kommunikation mit RFM funktioniert nur sporadisch */ Linie

Beschreibung der Funkmodule RFM01, RFM02 und RFM12.

Benötigt werden in der Minimal-Version im FIFO-Modus nur die Anschlüsse nSEL, SDO, SDI und SCK, eben das komplette SPI-Interface. Der Zugriff auf das Sende- und Empfangs-FIFO ist per Software möglich, ebenso die Abfrage der Statusbits. Deshalb werden z.B. nIRQ und nFFS nicht unbedingt benötigt. nIRQ signalisiert unter anderem, dass das Modul bereit ist Daten zu empfangen. Wenn Daten empfangen wurden, kann dies über den FFIT-Pin abgefragt werden (falls die Füllschwelle eingestellt wurde). nFFS dient dazu das FIFO direkt anzusprechen (es ist quasi der Chipselect für das FIFO), davon wird in der Minimalversion aber kein Gebrauch gemacht. Der Pin muss daher auf high-Pegel gelegt werden!
An CLK kann eine Frequenz von 1MHz bis 10MHz eingestellt werden. Hiermit kann dann z.B. der Mikrocontroller versorgt werden.
Reset ist ein Open-Collector-Ausgang und gleichzeitig der Reset-Eingang. Er sollte daher entweder gar nicht, oder aber hochohmig angeschlossen werden.

Im FIFO-Mode kann das Modul konfiguriert werden mit dem Empfang zu warten, bis die Daten 0x2DD4 empfangen wurden. Sobald dieses Bitmuster empfangen wurde, werden Daten in das FIFO geschrieben, bis man das FIFO abschaltet und die Mustererkennung neu startet.

Als weitere Modi stehen unter anderem ein synchroner Modus zur Verfügung (no FIFO mode), in dem der Sender/Empfänger den Bittakt ausgibt, und synchron dazu die zu sendenden Daten einliest bzw. die empfangenen Daten ausgibt. Der SPI Bus ist trotzdem zur Initialisierung des Moduls notwendig.

== FAQ ==

=== SPI Interface ===

* Maximale Datenrate: 2,5MHz (10MHz Quarz / 4)

=== CLK-Ausgang bleibt bei 1 MHz ===

* Vor dem Umschalten (mit 0xC0E0) länger warten.

=== RFM12 empfängt ein paar Bytes, dann nur Müll ===

* Es wird zu langsam gesendet (TX FIFO underrun)
* Es wird zu langsam empfangen (RX FIFO overrun)

Die Status-Bits helfen hier beim Debuggen. SPI sollte auf maximaler Transferrate stehen.

=== RFM empfängt nur Müll ===

http://www.mikrocontroller.net/topic/73560#605528

Deine Module verhalten sich normal. Man muß mit den Gain- und AFC-Bits
eine ganze Weile spielen, bis die Module korrekt laufen (kommt auf die
Anwendung an). Fakt ist: der Empfänger empfängt ständig Datenmüll als
Rauschen. Wenn der FIFO durch die Präambel getriggert wird, sind die
Daten im FIFO ziemlich korrekt, wenn alles "gut" eingestellt ist. Der
FIFO sollte per Interrupt dann auch sofort abgeholt werden, da sonst das
nächste Byte das alte direkt überschreibt. Jeder zusammenhängende
Datensatz (mehrere Bytes an einem Stück) muß von einer Präambel
eingeleitet werden. Nach dem kompletten Einlesen eines Datensatzes muß
der FIFO abgeschaltet, wieder eingeschaltet und für den Empfang der
nächsten Präambel neu scharf gemacht werden.

=== RFM hängt sich auf ===

Wenn man die AFC nicht begrenzt, also keinen Wertebereich vorgibt, die eine maximale Abweichung korrigiert wird passiert es nach einer Weile, dass sich der Empfänger aufhängt, die Offsetbits im Status werden maximal und dann geht gar nichts mehr, er hängt fest.

Siehe auch
* Forenbeitrag [http://www.mikrocontroller.net/topic/82456#689660 RFM12: Erfahrungen ]

=== Kommunikation mit RFM funktioniert nur sporadisch ===

* Ist die Versorgungsspannung stabil? (evtl. Kondensator einbauen)

----

== Register ==

Von https://www.mikrocontroller.net/attachment/24947/RFM12.txt

Dieses Dokument beschreibt die Nutzung des RFM12 TRX Moduls!

''' WICHTIG '''

Dieses Dokument wurde aus mehreren Quellen zusammengestellt, und kann Fehler enthalten!
Es können Abweichungen in Bezug auf RF01 / RF02 / RF12 / RFM01 / RFM02 und andere Module auftreten!
Es wurde das Datenblatt vom RFM12B und RF12 von www.hoperf.com als Basis genuzt. Zusätzlich wurden diese Informationen mit Hilfe von Forums-Nutzern (https://www.mikrocontroller.net/topic/71682) weiter vervollständigt!

''' WICHTIG '''

'''Hinweis:''' Die LNA-Eingangsimpedanz beträgt 250 Ohm, und muss beim Anschluss einer 50-Ohm-Antenne entsprechend angepasst werden, um das Rauschen zu minimieren! '' -- (Auf den Pollin-Modulen bereits vorhanden)''

=== Configuration Setting ===
Hex = 80 & xx
Bit-Syntax:
{| cellpadding="2" cellspacing="0" border="1"
!width="20%"| Byte ||width="40%"| 1 || 2
|-
!Bits
|{{8Bit|width=100%| 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 }}||{{8Bit|width=100%| el | ef | b1 | b0 | x3 | x2 | x1 | x0}}|}
el (TX FIFO) = Sendepuffer für Datentransfer nutzen (1 = An / 0 = Aus)
ef (RX FIFO) = Empfangspuffer für Datenspeicherung nutzen (1 = An / 0 = Aus)
b... = Zu nutzende Basisfrequenz (00=315MHz / 01=433MHz / 10=868MHz / 11=915MHz)
x... = Interner Clock des Chips kann durch verschieben einer Kondensator-Anpass-Stufe bestimmt werden.
0,5pF pro Schritt. Basis ist 8,5pF -> (0000=8,5 / 0001=9,0 / 0010=9,5 / ...)

=== Power-Managment ===
Hex = 82 & xx
Bit-Syntax: 10000010 | er | ebb | et | es | ex | eb | ew | dc
er = Empfänger einschalten (1 = an / 0 = Aus)
ebb = ... (Synthesizer muss aktiv sein!) (1 = an / 0 = aus)
et = Sender einschalten (1 = an / 0 = Aus) (Wenn das TX-Register aktiv und mit Daten gefüllt ist/wurde,
werden diese Daten sofort gesendet) (1 = an / 0 = aus)
es = Schaltet den Synthesizer ein. (1 = an / 0 = aus)
ex = Schaltet den Quarz-Oszilator ein. (1 = an / 0 = aus)
eb = Vergleichbar mit BrownOutDetection -> Erkennt eine zu geringe Betriebsspannung und erzeugt einen Interrupt,
um einen drohenden Spannungsaufall anzukündigen (1 = An / 0 = Aus)
ew = Aktiviert den WakeUpTimer des Prozessors. (1 = an / 0 = aus)
dc = Deaktiviert die Ausgabe des SystemClocks auf dem CLK Pin am Chip (1 = Keine ClockAusgabe / 0 = Clock ausgeben)

=== PLL Setting ===
Hex = 198 + y
Bit-Syntax: 110011000 | ob1 | ob0 | lpx | ddy | ddit | bw1 | bw0
ob... = ... (00= 5 oder 10MHz [standard] / 01=3.3MHz / 1x=2.5MHz oder weniger)
lpx = Wählt den Low-Power-Mode für den Quarz-Oszilator aus. (0=1ms [620µA] / 1=2ms [460µA])
ddy = ...
ddi = Schaltet das Dithering in PLL-Schleife ab. (1=abgeschaltet / 0=eingeschaltet)
bw... = Wählt die Bandbreite des PLL-Signals aus. (00=86.2kbps [-107dBc/Hz] / 01=256kbps [-102dBc/Hz]) Bei 1MHz Offset Phasenrauschen.

=== LowBatt / µC Clock Control ===
Hex = c0 & xx
Bit-Syntax: 11000000 | d2 | d1 | d0 | v4 | v3 | v2 | v1 | v0
d... = Bestimmt den Teilungsfaktor für die Clockausgabe am CLK-Pin in Abhängigkeit des Internen SystemTakts.
(000=1 / 001=1.25 / 010=1.66 / 011=2 / 100=2.5 / 101=3.33 / 110=5 / 111=10)
v... = Bestimmt die Minimalspannung, ab der ein Interrupt durchgeführt werden
muss. (Ähnlich einer BrownOutDetection). Im Power-Managment muss das eb-Bit
aktiv sein, damit dies funktioniert.

=== Frequency-setting ===
Bestimmt den Offset der Sende- und Empfangsfrequenz. Dieser Offset wird auf das Basisband im Configuration Setting hinzu gerechnet.
Hex = a & xxx
Bit-Syntax: 1010 | f11 | f10 | f9 | f8 | f7 | f6 | f5 | f4 | f3 | f2 | f1 | f0
f... = Bestimmt den Offsetwert der Frequenz.
Als Basis gilt das eingestellte Band im Configuration-Settings-Kommando

=== Data-Rate ===
Hex = c6 & xx
Bit-Syntax: 11000110 | cs | r6 | r5 | r4 | r3 | r2 | r1 | r0
cs = Vorteiler, Faktor 7. Hiermit kann ein Vorteiler aktiviert werden,
der die errechnete Baudrate (r...) durch 7 teilt.
r... = Baudratenteilerfaktor

=== RX Control ===
Hex = 94 & xx
Bit-Syntax: 10010 | p20 | d1 | d2 | i2 | i1 | i0 | g1 | g0 | r2 | r1 | r0
p20 = Bestimmt die Funktion des Pin20 (nINT / VDI) am RFM12 Chip (1 = VDI-Ausgang / 0 = Interrupt-Eingang)
d... = (Valid Data Indicator). Definiert die Geschwindigkeit, mit der bestimmt wird, ob ein Signal korrekt ist, oder nicht.
(00=schnell / 01=mittel / 10=langsam / 11=immer an). Je nach eingestellter Variante werden
unterschiedliche Hardware- und Software-Kombinationen genuzt.
Fast: CR_Lock OR DQD ... Medium: CR_Lock AND ( DRSSI OR DQD ) ...
SLOW: R/S FlipFlop aus (SET) DRSSI OR DQD OR CR_Lock und (CLR) DRSSI AND DQD AND CR_Lock .
i... = Bestimmt die Bandbreite des Empfängers in KHz (KiloHertz).
(000=Reserviert / 001=400 / 010=340 / 011=270 / 100=200 / 101=134 / 110=67 / 111=Reserviert)
g... = (LNA-Gain) Verstärkungsfaktor des Rauscharmen-Eingangs-Signal-Verstärkers (LNA Low Noise Amplifier).
Werte in dBm (Dezibel [Grösse: Milliwatt]) Mögliche Werte sind: 0 / -6 / -14 / -20
r... = (DRSSI = Digital Received Signal Strength Indication) Minimale Empfangssignalfeldstärke.
6 dBm pro Schritt: (000=-103 / 001=-97 / 010=-91 / ...)

=== Synchron Pattern ===
Hex = ce & xx
Bit-Syntax: 11001110 | b7 | b6 | b5 | b4 | b3 | b2 | b1 | b0
b... = Legt den Wert fest, der als Synchronisations-Byte für die Datenfilterung verwendet werden soll.

=== Data Filter ===
Hex = c2 & xx
Bit-Syntax: 11000010 | al | ml | -unknow- (1) | s | -unknow- (1) | f2 | f1 | f0
al = Baudratenregenerator schaltet automatisch in den langsamen Modus,
sobald er einen Takt erkannt hat.
ml = schneller/langsamer Modus
-unknown- (1) = ??? (Standard = 1) (Auch im Datenblatt von IA4420 so beschrieben)
s = (DataFilter) Typ des Datenfilters (0=DigitalFilter / 1=AnalogFilter).
Bei Nutzung des Analog-Filters kann kein FIFO sowie kein ClockRecovery genuzt werden.
-unknown- (1) = ??? (Standard = 1) (Auch im Datenblatt von IA4420 so beschrieben)
f... = (DQD Threshold) Bestimmt den Schwellwert, ab dem ein Signal als gut empfunden wird,
und der Empfänger dieses weiterverarbeiten soll.
DQD (data quality detection) zählt die "Spikes" des ungefilterten Signals, und bestimmt darüber die Qualität der Daten.

=== FIFO und RESET-Mode ===
Hex = ca & xx
Bit-Syntax: 11001010 | f3 | f2 | f1 | f0 | -unknow- (0) | al | ff | dr
f... = (FIFO interrupt Level)
-unknown- (0) = ??? (Standard = 0) (Auch im Datenblatt von IA4420 so beschrieben)
al = (FIFO Fill Condition) Legt den Wert fest, ab dem das Füllen des FIFOs beginnt.
(0=Synchron / 1=Ständig). Bei Nutzung des Synchron-Modus, werden erst dann Daten in den FIFO geschrieben,
wenn eine definierte 16Bit-Datenfolge empfangen wurde (Standard ist Hex: 2dd4).
ff = (FIFO Fill) Startet das Einlesen der empfangenen Daten in den FIFO-Puffer.
Wenn al (FIFO Fill Condition) auf synchron steht, dann startet das Setzen dieses Bits die Synchronisation-Bit-Erkennung.
dr = (Sens Reset Mode) Wenn dieses Bit auf 0 steht, wird bei einer Schwankung von 200mV auf
der VCC-Leitung (Spannungsversorgung des Chips), ein System-Reset ausgelöst.

=== Automatic Frequency Control ===
Hex = c4 & xx
Bit-Syntax: 11000100 | a1 | a0 | rl1 | rl0 | st | fi | oe | en
a... = Modus der AFC-Schaltung, 0=Auto, 1=einmalig nach Einschalten, 2=Solange VDI low ist, 3=unabhängig von VDI
r... = (Range Limit) Frequenzraster (00=KeineBegrenzung / 01=+15 > -16 / 10=+7 > -8 / 11=+3 > -4)
st = Berechneten Offset-Wert übernehmen
fi = Genauer Berechnungsmodus (besser aber lansgamer)
oe = AFC-Offset freischalten
en = AFC-Berechnung aktivieren

=== TX Configuration Control ===
Hex = 98 & xx
Bit-Syntax: 1001100 | mp | m3 | m2 | m1 | m0 | -unknow- (0) | p2 | p1 | p0
mp = (Modulation Polarity) Bestimmt die Richtung der FSK-Erzeugung (invertiert das Spektrum).
m... = (fDeviation) Bestimmt den Frequenzabstand des High- und Low-Wertes bei der Ubertragung im FSK-Betrieb. Basis ist der mp-Wert.
-unknown- (0) = ??? (Standard = 0) (Auch im Datenblatt von IA4420 so beschrieben)
p... = Bestimmt die relative Ausgangsleistung des Senders anhand des dBm-Wertes (Dezibel [Grösse: Milliwat]) 3-dBm-Schritte.
(000=0 / 001=-3 / 010=-6 / ...). Der Wert steht im Zusammenhang mit der angeschlossenen Antennen-Impedanz.

=== Wake-Up Timer ===
Bestimmt die Zeitperiode der zyklischen Einschaltung des WakeUp-Timers
Hex = e & xxx
Bit-Syntax: 111 | R4 | R3 | R2 | R1 | R0 | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0
R = Exponent der Zeit
M = Zeit

=== Low Duty-Cycle ===

Bestimmt die maximale Sendezeit pro Stunde. Dies ist wichtig, um sich an gesetzliche Frequenzzuteilungsrichtlinien zu halten, die bestimmen, wie lang jemand mit einer definierten Sendeleistung auf einer bestimmten Frequenz (mit eventuell definierter Betriebsart [Modulationstyp]) senden darf.)

hex = 6400 + Bits
Bit-Syntax: 1100100 | r| d6 | d5 | d4 | d3 | d2 | d1 | d0 | en
r = ??????????????????
d... = Einschaltdauer während der zyklischen Einschaltung
en = zyklische Einschaltung aktivieren

=== RX FIFO Read ===
Hex = b000
Bit-Syntax: 1011000000000000

Dieses Kommando löst die Rückgabe eines Datenbytes (synchron mit dem 8. Bit) aus. Es ist nötig, dass das ef-Bit (RX-FIFO) im Configuration Setting gesetzt wurde, um diese Funktion nutzen zu können!

=== TX Register Write ===
Dieses Kommando schreibt Daten in den TX-Puffer. Wenn der Sender aktiv ist, wird dieses sofort gesendet. el (TX-Register) muss im Configuration-Setting-Kommando aktiv sein.
Hex = b8 & xx
Bit-Syntax: 10111000 | DataByteToSend
DataByteToSend = Das Datenbyte, welches gesendet werden soll.

(Senden Funktioniert nur wenn zuvor der Status abgefragt wurde)

=== Status Read ===
Dieses Kommando löst die Rückgabe des Statusregisters aus, welches nach der ersten 0 im ersten Bit synchron übertragen wird.
Hex = 0000
Bit-Syntax: 0000000000000000<000>
Rückgabe-Syntax: x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | x10 | x11 | x12 | x13 | x14 | x15 | x16 | x17 | x18
x0 -> x5 = Interrupt bits
x6 -> x15 = Status Bits
x16 -> x18 = FIFO
x0 = FFIT / RGIT (RGIT = TX-Register ist bereit neue Daten zu senden ... kann mit dem TX-Register gelöscht werden)
(FFIT = Die Anzahl der Datenbits im FIFO-Puffer hat das eingestellte Limit erreicht.
Kann mit einer der FIFO-Lesemethoden gelöscht werden)
x1 = POR (PowerOnReset)
x2 = FFOV / RGUR (RGUR = Der Datenstrom beim Senden ist abgerissen, da nicht schnell genug Daten nachgeladen wurden)
(FFOV = Der RX-FIFO ist übergelaufen)
x3 = WKUP
x4 = EXT
x5 = LBD
x6 = FFBM (Der FIFO-Puffer ist leer)
x7 = RSSI/ATS (ATS = )(RSSI = Die Signalstärke ist über dem eingestelltem Limit)
x8 = DQD
x9 = CRL
x10 = ATGL
x11 = OFFS_4
x12 = OFFS_3
x13 = OFFS_2
x14 = OFFS_1
x15 = OFFS_0
x16 = FO
x17 = FO+1
x18 = FO+2

== Bezugsquellen ==
* [[Elektronikversender#csd-electronics|csd-electronics]]
* [[Elektronikversender#IT-WNS|IT-WNS]]
* [[Elektronikversender#Pollin_Electronic|Pollin Electronic]]

== Links ==

* [[AVR RFM12]]
* [[RFM12 Protokoll Stack]]
* [http://www.mikrocontroller.net/topic/93801 Bezugsquellen]

Folgende Links sind mit Vorsicht zu genießen, da die Datenblätter teilweise fehlerbehaftet sind. Es empfiehlt sich, direkt mit dem Datenblatt des RF12 (das ist das IC auf dem Modul) zu arbeiten. Dieses ist so gut wie fehlerfrei.

* [http://www.hoperf.com/pdf/RF12.pdf Datenblatt des ICs RF12] (PDF)
* [http://www.hoperf.com/pdf/RFM12.pdf Datenblatt des Moduls RFM12] (PDF)
* [http://www.hoperf.com/pdf/RF12_code.pdf Programming Guide] (PDF)
* [http://www.hoperf.com/pdf/RF12TOOLS.pdf Demo Kit User Manual] (PDF)
* [http://www.pollin.de/shop/downloads/D810047S.ZIP Beispielprogramm von Pollin] (ZIP)

[[Kategorie:Bauteile]]
[[Kategorie:Funk]]

AVR-GCC-Tutorial

2008-11-24T13:09:50Z

Thymythos: /* TODO */

= Vorwort =

Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[AVR-GCC]] erleichtern.

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.

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.

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.).

Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.

Dieses Tutorial ist in PDF-Form erhältlich bei:
http://www.siwawi.arubi.uni-kl.de/avr_projects/AVR-GCC-Tutorial_-_www_mikrocontroller_net.pdf
(nicht immer auf aktuellem Stand)

= Benötigte Werkzeuge =

Um eigene Programme für AVRs mittels avr-gcc/avr-libc zu erstellen und zu testen, wird folgende Hard- und Software benötigt:

* 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]].

* 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]].

* 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]]).

* 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]]).

= Was tun, wenn's nicht "klappt"? =

* 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.

* Die [[AVR Checkliste]] durcharbeiten.

* 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.

* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.

* Das [http://www.mikrocontroller.net/forum/2 GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.

* Das avr-gcc-Forum bei [http://www.avrfreaks.net avrfreaks] nach vergleichbaren Problemen absuchen.

* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.

* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRFREAKS] (anmelden).

* Google oder yahoo befragen schadet nie.

* 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.

* Die Beispieleprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.

* 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.lugbz.org/documents/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.

= Erzeugen von Maschinencode =

Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z. 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. 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:

* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z. 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 für den avr-gcc (ohne Anspruch auf Vollständigkeit): AtmanAvr C (relativ günstig), KamAVR (kostenlos), VMLab (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. B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen.

* 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).

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. 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.

= Einführungsbeispiel =

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.

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.

Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.

<c>
/* Alle Zeichen zwischen Schrägstrich-Stern
und Stern-Schrägstrich sind lediglich Kommentare */

// Zeilenkommentare sind ebenfalls möglich
// alle auf die beiden Schrägstriche folgenden
// Zeichen einer Zeile sind Kommentar

#include <avr/io.h> // (1)

int main (void) { // (2)

DDRB = 0xff; // (3)
PORTB = 0x03; // (4)

while(1) { // (5a)
/* "leere" Schleife*/; // (5b)
} // (5c)

/* wird nie erreicht */
return 0; // (6)
}
</c>

* 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.

* Bei (2) beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion main.

* 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.

* (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).

* (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.

* (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.

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]].

<pre>
D:\tmp\gcc_tut\quickstart>dir

Verzeichnis von D:\tmp\gcc_tut\quickstart

28.11.2006 22:53 <DIR> .
28.11.2006 22:53 <DIR> ..
28.11.2006 20:06 118 main.c
28.11.2006 20:03 16.810 Makefile
2 Datei(en) 16.928 Bytes
</pre>

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.

<pre>
D:\tmp\gcc_tut\quickstart>make all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: main.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -
o obj/main.o

Linking: main.elf
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o
--output main.elf -Wl,-Map=main.map,--cref -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex

[...]
</pre>

Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z. 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. B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio), kann natürlich ebenfalls genutzt werden.

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.

= Exkurs: Makefiles =

Wenn man bisher gewohnt ist, mit integrierten Entwicklungsumgebungen à la Visual-C Programme zu erstellen, wirkt das makefile-Konzept auf den ersten Blick etwas kryptisch. Nach kurzer Einarbeitung ist diese Vorgehensweise jedoch sehr praktisch. Diese Dateien (üblicher Name: 'Makefile' ohne Dateiendung) dienen der Ablaufsteuerung des Programms make, das auf allen Unix/Linux-Systemen installiert sein sollte, und in einer Fassung fuer MS-Windows auch in [[WinAVR]] (Unterverzeichnis utils/bin) enthalten ist.

Im Unterverzeichnis ''sample'' einer WinAVR-Installation findet man eine sehr brauchbare Vorlage, die sich einfach an das eigene Projekt anpassen lässt ([[Media:Makefile|lokale Kopie Stand Sept. 2004]]). Wahlweise kann man auch [http://www.sax.de/~joerg/mfile/ mfile] von Jörg Wunsch nutzen. mfile erzeugt ein makefile nach Einstellungen in einer grafischen Nutzeroberfläche, wird bei WinAVR mitinstalliert, ist aber als TCL/TK-Programm auf nahezu allen Plattformen lauffähig.

''Die folgenden Ausführungen beziehen sich auf das WinAVR Beispiel-Makefile.''

Ist im Makefile alles richtig eingestellt, genügt es, sich drei Parameter zu merken, die über die shell bzw. die Windows-Kommandozeile (cmd.exe/command.com) als Parameter an "make" übergeben werden. Das Programm make sucht sich "automatisch" das Makefile im aktuellen Arbeitsverzeichnis und führt die darin definierten Operationen für den entsprechenden Aufrufparameter durch.

{| border=1
| ''make all''
| Erstellt aus den im Makefile angegebenen Quellcodes eine ''hex''-Datei (und ggf. auch ''eep''-Datei).
|-
| ''make program''
| Überträgt die hex-Datei (und wahlweise auch die eep-Datei für den EEPROM) zum AVR.
|-
| ''make clean''
| löscht alle temporären Dateien, also auch die hex-Datei
|}

Diese Aufrufe können in die allermeisten Editoren in "Tool-Menüs" eingebunden werden. Dies erspart den Kontakt mit der Kommandozeile. Bei WinAVR sind die Aufrufe bereits im Tools-Menü des mitgelieferten Editors Programmers-Notepad eingefügt.

Üblicherweise sind folgende Daten im Makefile anzupassen:
* Controllertyp

* Quellcode-Dateien (c-Dateien)

* Typ und Anschluss des Programmiergeräts

Seltener sind folgende Einstellungen durchzuführen:
* Grad der Optimierung

* Methode zur Erzeugung der Debug-Symbole (Debug-Format)

* Assembler-Quellcode-Dateien (S-Dateien)

Die in den folgenden Unterabschnitten gezeigten Makefile-Ausschnitte sind für ein Programm, das auf einem ATmega8 ausgeführt werden soll. Der Quellcode besteht aus den c-Dateien superprog.c (darin main()), uart.c, lcd.c und 1wire.c. Im Quellcodeverzeichnis befinden sich diese Dateien: superprog.c, uart.h, uart.c, lcd.h, lcd.c, 1wire.h, 1wire.c und das makefile (die angepasste Kopie des WinAVR-Beispiels).

Der Controller wird mittels [[AVRDUDE]] über ein [[STK200]]-Programmierdongle an der Schnittstelle lpt1 (bzw. /dev/lp0) programmiert. Im Quellcode sind auch Daten für die ''section .eeprom'' definiert (siehe Abschnitt [[AVR-GCC-Tutorial#EEPROM|Speicherzugriffe]]), diese sollen beim Programmieren gleich mit ins EEPROM geschrieben werden.

== Controllertyp setzen ==

Dazu wird die "make-Variable" MCU entsprechend dem Namen des verwendeten Controllers gesetzt. Eine Liste der von avr-gcc und der avr-libc unterstützten Typen findet sich in der [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc].

<div class="code"><pre>
# Kommentare in Makefiles beginnen mit einem Doppelkreuz
...

# ATmega8 at work
MCU = atmega8
# oder MCU = atmega16
# oder MCU = at90s8535
# oder ...
...
</pre></div>

== Quellcode-Dateien eintragen ==

Der Name der Quellcodedatei, welche die Funktion main enthält, wird hinter TARGET eingetragen. Dies jedoch ohne die Endung ''.c''.

<div class="code"><pre>
...
TARGET = superprog
...
</pre></div>

Besteht das Projekt wie im Beispiel aus mehr als einer Quellcodedatei, sind die weiteren c-Dateien (nicht die Header-Dateien, vgl. [[Include-Files (C)]]) durch Leerzeichen getrennt bei SRC einzutragen. Die bei TARGET definierte Datei ist schon in der SRC-Liste enthalten. Diesen Eintrag nicht löschen!

<div class="code"><pre>
...
SRC = $(TARGET).c uart.c lcd.c 1wire.c
...
</pre></div>

Alternativ kann man die Liste der Quellcodedateien auch mit dem Operator += erweitern.

<div class="code"><pre>
SRC = $(TARGET).c uart.c 1wire.c
# lcd-Code fuer Controller xyz123 (auskommentiert)
# SRC += lcd_xyz.c
# lcd-Code fuer "Standard-Controller" (genutzt)
SRC += lcd.c
</pre></div>

== Programmiergerät einstellen ==

Die Vorlagen sind auf die Programmiersoftware [[AVRDUDE]] angepasst, jedoch lässt sich auch andere Programmiersoftware einbinden, sofern diese über Kommandozeile gesteuert werden kann (z. B. stk500.exe, uisp, sp12).

<div class="code"><pre>
...
# Einstellung fuer STK500 an com1 (auskommentiert)
# AVRDUDE_PROGRAMMER = stk500
# com1 = serial port. Use lpt1 to connect to parallel port.
# AVRDUDE_PORT = com1 # programmer connected to serial device

# Einstellung fuer STK200-Dongle an lpt1
AVRDUDE_PROGRAMMER = stk200
AVRDUDE_PORT = lpt1
...
</pre></div>

Sollen Flash(=.hex) und EEPROM(=.eep) zusammen auf den Controller programmiert werden, ist das Kommentarzeichen vor AVRDUDE_WRITE_EEPROM zu löschen.

<div class="code"><pre>
...
# auskommentiert: EERPOM-Inhalt wird nicht mitgeschrieben
#AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(TARGET).eep

# nicht auskommentiert: EERPOM-Inhalt wird mitgeschrieben
AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(TARGET).eep
...
</pre></div>

== Anwendung ==

Das erstellte Makefile und der Code müssen im gleichen Ordner sein, auch sollte der Dateiname nicht verändert werden.

Die Eingabe von ''make all'' im Arbeitsverzeichnis mit dem Makefile und den Quellcodedateien erzeugt (unter anderem) die Dateien superprog.hex und superprog.eep. Abhängigkeiten zwischen den einzelnen c-Dateien werden dabei automatisch berücksichtigt. Die ''superprog.hex'' und ''superprog.eep'' werden mit ''make program'' zum Controller übertragen. Mit ''make clean'' werden alle temporären Dateien gelöscht (="aufgeräumt").

== Sonstige Einstellungen ==

=== Optimierungsgrad ===

Der gcc-Compiler kennt verschiedene Stufen der Optimierung. Nur zu Testzwecken sollte die Optimierung ganz deaktiviert werden (''OPT = 0''). Die weiteren möglichen Optionen weisen den Compiler an, möglichst kompakten oder möglichst schnellen Code zu erzeugen. In den weitaus meisten Fällen ist ''OPT = s'' die empfohlene Einstellung, damit wird kompakter und oft auch der schnellste Maschinencode erzeugt. Beim Update auf eine neue Compilerversion ist zu beachten, dass diese möglicherweise intern andere Optimierungsalgorithmen verwendet und sich dadurch die Größe des Machinencodes etwas ändert, ohne dass man im Quellcode etwas geändert hat.

Als Orientierungswerte die Größe des Maschinencodes bei verschiedenen Optionen für einen nicht näher spezifizierten relativ kleinen Testcode bei Verwendung einer nicht näher spezifizierten Compilerversion.

* -O0 : 12'217 Byte

* -O1 : 9'128 Byte

* -O2 : 1'670 Byte

* -O3 : 3'004 Byte

* -Os : 1'695 Byte

Im diesem Testfall führt die Option -O2 mit zum kompaktesten Code, dies allerdings hier nur mit 25 Bytes "Vorsprung". Es kann durchaus sein, dass nur wenige Programmerweiterungen dazu führen, dass Compilieren mit -Os wieder in kompakteren Code resultiert.

Siehe dazu auch:
* [http://www.nongnu.org/avr-libc/user-manual/using_tools.html#gcc_optO avr-libc manual Abschnitt Using the gnu-tools/Compiler-Optionen]

* [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_optflags avr-libc Manual FAQ Nr. 16] (Stand avr-libc Version 1.4.5)

=== Debug-Format ===

Unterstützt werden die Formate stabs und dwarf-2. Das Format wird hinter ''DEBUG ='' eingestellt. Siehe dazu Abschnitt ''Eingabedateien zur Simulation''.

=== Assembler-Dateien ===

Die im Projekt genutzten Assembler-Dateien werden hinter ASRC durch Leerzeichen getrennt aufgelistet. Assembler-Dateien haben immer die Endung .S (großes S). Ist zum Beispiel der Assembler-Quellcode eines Software-UARTs in einer Datei softuart.S enthalten, lautet die Zeile: ''ASRC = softuart.S''

=== Taktfrequenz ===

Neuere Versionen der WinAVR/Mfile Vorlage für Makefiles beinhalten die Definition einer Variablen F_CPU (WinAVR 2/2005). Darin wird die Taktfrequenz des Controllers in Hertz eingetragen. Die Definition steht dann im gesamten Projekt ebenfalls unter der Bezeichnung F_CPU zur Verfügung (z. B. um daraus UART-, SPI- oder ADC-Frequenzeinstellungen abzuleiten).

Die Angabe hat rein "informativen" Charakter, die tatsächliche Taktrate wird über den externen Takt (z. B. Quarz) bzw. die Einstellung des internen R/C-Oszillators bestimmt. Die Nutzung von F_CPU hat also nur Sinn, wenn die Angabe mit dem tatsächlichen Takt übereinstimmt.

Innerhalb neuerer Versionen der avr-libc (ab Version 1.2) wird die Definition der Taktfrequenz (F_CPU) zur Berechnung der Wartefunktionen in delay.h genutzt. Diese funktionieren nur dann korrekt, wenn F_CPU mit der tatsächlichen Taktfrequenz übereinstimmt.
F_CPU muss dazu jedoch nicht unbedingt im makefile definiert werden. Es reicht aus, wird aber bei mehrfacher Anwendung unübersichtlich, vor ''#include <util/delay.h>'' (veraltet: ''#include <avr/delay.h>'') ein ''#define F_CPU [hier Takt in Hz]UL'' einzufügen. Bei Nutzung von delay.h ist darauf zu achten, dass die Optimierung des Compilers nicht ausgeschaltet ist, sonst wird sehr viel Code erzeugt und die Wartezeit stimmt nicht mit der gewünschten Zeitspanne überein. Vgl. dazu den [http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html entsprechenden Abschnitt der Dokumentation].

== Eingabedateien zur Simulation in AVR-Studio ==

Mit älteren AVR-Studio-Versionen kann man nur auf Grundlage so genannter ''coff''-Dateien simulieren. Neuere Versionen von AVR-Studio (ab 4.10.356) unterstützen zudem das modernere aber noch experimentelle dwarf-2-Format, das ab WinAVR 20040722 (avr-gcc 3.4.1/Binutils inkl. Atmel add-ons) "direkt" vom Compiler erzeugt wird.

; Vorgehensweise bei dwarf-2:
* Im Makefile bei DEBUG: <div class="code"><pre>DEBUG=dwarf-2</pre></div>

* ''make all'' (evtl. vorher ''make clean'')

* Die erzeugte ''elf''-Datei (im Beispiel oben ''superprog.elf'') in AVR-Studio laden

* AVR-Simulator und zu simulierenden Controller wählen, "Finish"

* Weiteres siehe AVR-Studio Online-Hilfe

; Vorgehensweise bei extcoff: (sollte nur noch in Ausnahmefällen genutzt werden)

* Im Makefile bei DEBUG: <div class="code"><pre>DEBUG=stabs</pre></div>

* ''make extcoff'' (evtl. vorher ''make clean'')

* Die erzeugte ''cof''-Datei (im Beispiel oben ''superprog.cof'') in AVR-Studio laden

* AVR-Simulator und zu simulierenden Controller wählen, "Finish"

* Weiteres siehe AVR-Studio Online-Hilfe

Beim Simulieren scheinen oft "Variablen zu fehlen". Ursache dafür ist, dass der Compiler diese "Variablen" direkt Registern zuweist. Dies kann vermieden werden, indem die Optimierung abgeschaltet wird (im makefile). Man simuliert dann jedoch ein vom optimierten Code stark abweichendes Programm. Das Abschalten der Optimierung wird nicht empfohlen.

Statt des Software-Simulators kann das AVR-Studio auch genutzt werden, um mit dem ATMEL JTAGICE, einem Nachbau davon (BootICE, Evertool o. ä.) oder dem ATMEL JTAGICE MKII "im System" zu debuggen. Dazu sind keine speziellen Einstellungen im makefile erforderlich. Debugging bzw. "In-System-Emulation" mit dem JTAGICE und JTAGICE MKII sind in der AVR-Studio Online-Hilfe beschrieben.

Die Verwendung von Makefiles bietet noch viele weitere Möglichkeiten, einige davon werden im Anhang [[AVR-GCC-Tutorial#Zus.C3.A4tzliche_Funktionen_im_Makefile|Zusätzliche Funktionen im Makefile]] erläutert.

= Ganzzahlige (Integer) Datentypen =

Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.

Standardisierte Datentypen werden in der Header-Datei stdint.h definiert.
Zur Nutzung der standardisierten Typen bindet man die "Definitionsdatei" wie folgt ein:

<c>
// ab avr-libc Version 1.2.0 möglich und empfohlen:
#include <stdint.h>

// veraltet: #include <inttypes.h>
</c>

Einige der dort definierten Typen (avr-libc Version 1.0.4):

<c>
typedef signed char int8_t;
typedef unsigned char uint8_t;

typedef short int16_t;
typedef unsigned short uint16_t;

typedef long int32_t;
typedef unsigned long uint32_t;

typedef long long int64_t;
typedef unsigned long long uint64_t;
</c>

* int8_t steht für einen 8-Bit Integer mit einem Wertebereich -128 bis +127.

* uint8_t steht für einen 8-Bit Integer ohne Vorzeichen (unsigned int) mit einem Wertebereich von 0 bis 255

* int16_t steht für einen 16-Bit Integer mit einem Wertebereich -32768 bis +32767.

* uint16_t steht für einen 16-Bit Integer ohne Vorzeichen (unsigned int) mit einem Wertebereich von 0 bis 65535.

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.

= Bitfelder =

Beim Programmieren von Mikrocontrollern muss auf jedes Byte oder sogar auf
jedes Bit geachtet werden. Oft müssen wir in einer Variablen lediglich den
Zustand 0 oder 1 speichern. Wenn wir nun zur Speicherung eines einzelnen Wertes
den kleinsten bekannten Datentypen, nämlich '''unsigned char''', nehmen, dann
verschwenden wir 7 Bits, da ein '''unsigned char''' ja 8 Bits breit ist.

Hier bietet uns die Programmiersprache C ein mächtiges Werkzeug an, mit dessen
Hilfe wir 8 Bits in eine einzelne Bytevariable zusammenfassen und (fast) wie
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:

<c>
struct {
unsigned bStatus_1:1; // 1 Bit für bStatus_1
unsigned bStatus_2:1; // 1 Bit für bStatus_2
unsigned bNochNBit:1; // Und hier noch mal ein Bit
unsigned b2Bits:2; // Dieses Feld ist 2 Bits breit
// All das hat in einer einzigen Byte-Variable Platz.
// die 3 verbleibenden Bits bleiben ungenutzt
} x;
</c>

Der Zugriff auf ein solches Feld erfolgt nun wie beim Strukturzugriff bekannt
über den Punkt- oder den Dereferenzierungs-Operator:

<c>
x.bStatus_1 = 1;
x.bStatus_2 = 0;
x.b2Bits = 3;
</c>

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.

Wenn man nur ein paar wenige Variablen vom Typ bool verwenden möchte, kann man
auch die Headerdatei <stdbool.h> einbinden und sich dann wie gewohnt einen Booltyp anlegen. Variablen dieses Typs brauchen dennoch 1 Byte Speicher, ermöglichen aber eine genaue Unterscheidung zwischen Zahlenvariable und boolscher Variable.

= Grundsätzlicher Programmaufbau eines µC-Programms =

Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in
welcher Programmiersprache das Programm geschrieben wird.

== Sequentieller Programmablauf ==

Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im
Wesentlichen immer den gleichen Aufbau hat:

[[Image:Sequentielle Programme.gif]]

== Interruptgesteuerter Programmablauf ==

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.

[[Image:Interrupt Programme.gif]]

= Zugriff auf Register =

Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die
Inhalte der Register sowohl auslesen als auch beschreiben.

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
die 8-Bit Register.

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.

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:

<c>
#include <avr/io.h>
</c>

Ist im Makefile der MCU-Typ z. 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.


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:

<pre>
[...]
# MCU Type ("name") setzen:
MCU = atmega16
[...]

[...]
## Verwendung des Inhalts von MCU (hier atmega16) fuer die
## Compiler- und Assembler-Parameter
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)
[...]

[...]
## Aufruf des Compilers:
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]
$(OBJDIR)/%.o : %.c
@echo
@echo $(MSG_COMPILING) $<
$(CC) -c $(ALL_CFLAGS) $< -o $@
[...]
</pre>

Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:

<c>
// avr/io.h
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)
[...]
#if defined (__AVR_AT94K__)
# include <avr/ioat94k.h>
// [...]
#elif defined (__AVR_ATmega16__)
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:
# include <avr/iom16.h>
// [...]
#else
# if !defined(__COMPILING_AVR_LIBC__)
# warning "device type not defined"
# endif
#endif
</c>

== Schreiben in Register ==

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.

Beispiel:

<c>
#include <avr/io.h>

...

int main(void)
{
/* Setzt das Richtungsregister des Ports A auf 0xff
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */
DDRA = 0xff;

/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */
PORTA = 0x03;
...

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);
}
</c>

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.

Der gcc C-Compiler (genauer der Präprozessor) unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.B. DDRB = 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.

=== Verändern von Registerinhalten ===

Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen.

<c>
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht
</c>

Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten.

Beispiel:
<c>
#include <avr/io.h>
...
#define MEINBIT 2
...
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */
</c>

Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.

Beispiel:
<c>
#include <avr/io.h>
...
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */
PORTA |= (1<<PA0) | (1<<PA3); /* Interne Pull-Up fuer beide einschalten */
</c>

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.

Siehe auch:
* [[Bitmanipulation]]
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers

== Lesen aus Registern ==

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.

Beispiel:

<c>
#include <avr/io.h>
#include <stdint.h>

uint8_t foo;

//...

int main(void)
{
/* kopiert den Status der Eingabepins an PortB
in die Variable foo: */
foo = PINB;
//...
}
</c>

Die 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:

<c>
#define MEINBIT0 0
#define MEINBIT2 2

uint8_t i;

extern test1();

// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist
i = PINA; // Inhalt in Arbeitsvariable
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (logisches und)
// falls das Bit gesetzt war, hat i den Inhalt 1
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)?
test1() // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen
}
// verkürzt:
if ( ( PINA & 0x01 ) != 0 ) {
test1();
}
// nochmals verkürzt:
if ( PINA & 0x01 ) {
test1();
}
// mit definierter Bitnummer:
if ( PINA & ( 1 << MEINBIT0 ) ) {
test(1);
}

// Funktion aufrufen, wenn Bit 0 oder Bit 2 gesetzt ist
if ( PINA & 0x05 ) {
test1(); // Vergleich <> 0 (wahr), also muss Bit 0 oder 2 gesetzt sein
}
// mit definierten Bitnummern:
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt
test1();
}

// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist
i = PINA; // einlesen in temporäre Variable
i = i & 0x01; // maskieren von B
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist
test2();
}
// analog mit !-Operator (not)
if ( !i ) {
test2();
}
// nochmals verkürzt:
if ( !( PINA & 0x01 ) ) {
test2();
}
</c>

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 Macros "nachgerüstet" werden).

;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, 4 für Bit2 etc.

;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.

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]].

=== Warten auf einen bestimmten Zustand ===

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).

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.

<c>
#include <avr/io.h>
...

/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */

#define WARTEPIN PINA
#define WARTEBIT PA2

// mit der avr-libc Funktion:
loop_until_bit_is_set(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// _nicht_ ungleich 0 (also 0) ist.
while ( !(WARTEPIN & (1 << WARTEBIT)) ) ;
...
</c>

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.

<c>
#include <avr/io.h>
...

/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */
#define WARTEPIN PINB
#define WARTEBIT PB4

// avr-libc-Funktion:
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// gesetzt (1) ist
while ( WARTEPIN & (1<<WARTEBIT) ) ;
...
</c>

Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers
* [[Bitmanipulation]]

= Zugriff auf IO-Ports =

Alle Ports der AVR-Controller werden über Register gesteuert. Dazu sind
jedem Port 3 Register zugeordnet:

{| border="1"
|-
| '''DDRx'''
| Datenrichtungsregister für Port'''x'''.
'''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.
|-
| '''PINx'''
| Eingangsadresse für Port'''x'''.
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.
|-
| '''PORTx'''
| Datenregister für Port'''x'''.
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).
|}

Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern
(GPIO - General Purpose Input/Output). 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.

== Datenrichtung bestimmen ==

Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.

Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang
verwendet werden, muss das entsprechende Bit gelöscht sein.

Beispiel:
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

+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
7 6 5 4 3 2 1 0

In C liest sich das dann so:

<c>
// in io.h wird u.a. DDRB definiert:
#include <avr/io.h>

...

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);

...
</c>

Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:

<c>
// Alle Pins des Ports B als Ausgang definieren:
DDRB = 0xff;
// Pin0 wieder auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~( 1 << DDB0 );
// Pin 3 und 4 auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~( ( 1 << DDB3 ) | ( 1<<DDB4) );
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
DDRB |= ( 1 << DDB0) | ( 1 << DDB3 );
// Alle Pins auf Eingang:
DDRB = 0x00;
</c>

== Vordefinierte Bitnummern für I/O-Register ==

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):

<c>
...
/* PORTC */
#define PC7 7
#define PC6 6
#define PC5 5
#define PC4 4
#define PC3 3
#define PC2 2
#define PC1 1
#define PC0 0

/* DDRC */
#define DDC7 7
#define DDC6 6
#define DDC5 5
#define DDC4 4
#define DDC3 3
#define DDC2 2
#define DDC1 1
#define DDC0 0

/* PINC */
#define PINC7 7
#define PINC6 6
#define PINC5 5
#define PINC4 4
#define PINC3 3
#define PINC2 2
#define PINC1 1
#define PINC0 0
</c>

== Digitale Signale ==

Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.

== Ausgänge ==
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.

Mit dem Befehl
<c>
#include <avr/io.h>
...
PORTB = 0x04; /* besser PORTB=(1<<PB2) */
</c>
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).

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:

<c>
#include <avr/io.h>
...
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */
/* vereinfacht durch Nutzung des |= Operators : */
PORTB |= (1<<PB2);

/* auch mehrere "gleichzeitig": */
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */
</c>

"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:

<c>
#include <avr/io.h>
...
PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */
</c>

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.

''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:''

Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:
* zuerst die Bits im PORTx-Register setzen
* anschließend die Datenrichtung auf Ausgang stellen

Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert ware:
* setze PORTx: interner Pull-Up aktiv
* setze DDRx: Ausgang ("high")

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''.

== Eingänge (Wie kommen Signale in den µC) ==

Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.

=== Signalkopplung ===

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.

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.

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.

Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.

<font color="#FF0000">Dabei ist wichtig, zur Abfrage der Eingänge '''nicht''' etwa Portregister '''PORTx''' zu verwenden, '''sondern''' Eingangsregister '''PINx'''. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".</font> (Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände.)

Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:

<c>
#include <avr/io.h>
#include <stdint.h>
...
uint8_t bPortD;
...
bPortD = PIND;
...
</c>

Mit den C-Bitoperationen kann man den Status der Bits abfragen.

<c>
#include <avr/io.h>
...
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */
if ( PINC & (1<<PINC1) ) {
/* Aktion */
}

/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */
if ( !(PINB & (1<<PINB2)) ) {
/* Aktion */
}
...
</c>

=== Tasten und Schalter ===

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''):

{| border="1"
|-
| '''Active Low'''
| '''Active High'''
|-
| [[Image:Active Low.gif]]
| [[Image:Active High.gif]]
|-
| 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.

Der Widerstandswert des Pull-Up Widerstands 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 haben sogar an den meisten Pins softwaremäßig zuschaltbare interne Pull-Up Widerstände, welche wir natürlich auch verwenden können.

| 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.
|}

==== Pull-Up Widerstände aktivieren ====

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.

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.

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.

<c>
#include <avr/io.h>
...
DDRD = 0x00; /* alle Pins von Port D als Eingang */
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */
...
DDRC &= ~(1<<DDC7); /* Pin PC7 als Eingang */
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */
</c>

==== (Tasten-)Entprellung ====

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.

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.

<c>
#include <avr/io.h>
#include <inttypes.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* bei alter avr-libc: #include <avr/delay.h> */

/* Einfache Funktion zum Entprellen eines Tasters */
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)
{
if ( ! (*port & (1 << pin)) )
{
/* Pin wurde auf Masse gezogen, 100ms warten */
_delay_ms(50); // max. 262.1 ms / F_CPU in MHz
_delay_ms(50);
if ( *port & (1 << pin) )
{
/* Anwender Zeit zum Loslassen des Tasters geben */
_delay_ms(50);
_delay_ms(50);
return 1;
}
}
return 0;
}

int main(void)
{
DDRB &= ~( 1 << PB0 ); /* PIN PB0 auf Eingang (Taster) */
PORTB |= ( 1 << PB0 ); /* Pullup-Widerstand aktivieren */
...
if (debounce(&PINB, PB0)) /* Falls Taster an PIN PB0 gedrueckt.. */
PORTD = PIND ^ ( 1 << PD7 ); /* ..LED an Port PD7 an-
bzw. ausschalten */
...
}
</c>

Bei diesem Beispiel 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).

Zum Thema Entprellen siehe auch:
* Artikel [[Entprellung]]

== Analog ==

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.

== 16-Bit Portregister (ADC, ICR1, OCR1, TCNT1, UBRR) ==

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.

<c>
#include <avr/io.h>
#include <stdint.h>
...
uint16_t foo;

foo=ADC; /* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */
</c>

Falls benö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.

<c>
/* Diese Variante ist normal am effizientesten */
#include <avr/io.h>
#include <stdint.h>
#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

typedef union {
uint16_t i16;
struct {
uint8_t i8l;
uint8_t i8h;
};
} convert16to8;

...
convert16to8 baud;
baud.i16 = F_CPU / (UART_BAUD_RATE * 16L) -1;
UBRRH = baud.i8h;
UBRRL = baud.i8l;
...

/* Alternative 1:*/
#include <inttypes.h>

uint16_t wFoo16;
uint8_t bFooLow, bFooHigh;

...

wFoo16 = 0xAA55; /* zu "zerlegende" 16Bit-Integer */
bFooHigh = (uint8_t)(wFoo16 >> 8); /* MS-Byte */
bFooLow = (uint8_t)(wFoo16); /* LS-Byte */

/* Alternative 2:*/

#define us0(Data) (*((unsigned char *)(&Data)))
#define us1(Data) (*((unsigned char *)((&Data)+1)))
bFooHigh = us1(wFoo16);
bFoolow = us0(wFoo16);
...
</c>

Bei einigen AVR-Typen (z.B. ATmega8) 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ächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3'' und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''.

Bei einigen 16-bit Registern (insbesondere die der 16-bit Timer) erfolgen Schreibzugriffe über das sogenannte ''temporary Register''. Die Reihenfolge der Zugriffe bestimmt, wann der Wert tatsächlich ins Register geschrieben wird. Typisch wird erst das High-Byte beschrieben (xxxH) und intern im temporary Register zwischengespeichert. Nachdem das Low-Byte (xxxL) geschrieben wurde, setzt der Controller mit diesem und dem im temporary Register zwischengespeicherten Wert für das High-Byte das 16-bit Register. Dabei ist zu beachten, dass intern nur ein temporary Register verfügbar ist, welches in Interruptroutinen mglw. mit einem anderen Wert überschrieben wird, wenn dort ebenfalls 16-bit Register beschrieben werden. avr-gcc/avr-libc berücksichtigen die korrekte Reihenfolge automatisch, wenn die Register mit ihrem "16-bit Label" (ohne H bzw. L) angesprochen werden, dabei ist der Schutz des temporary Registers vor Überschreiben durch Interruptroutinen dennoch zu beachten (im Zweifel beim Schreibzugriff die Interrupts kurzzeitig global deaktivieren).

Im Umgang mit 16-Bit Registern siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8
* Datenblatt Abschnitt ''Accessing 16-bit Registers''

== IO-Register als Parameter und Variablen ==

Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:

<c>
uint8_t key_pressed(const volatile uint8_t *inputreg, uint8_t inputbit)
{
static uint8_t last_state = 0;

if ( last_state == ( *inputreg & (1<<inputbit) ) ) {
return 0; /* keine Änderung */
}

/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */
_delay_ms(20);

/* Zustand für nächsten Aufruf merken: */
last_state = ( *inputreg & (1<<inputbit) );

/* und den entprellten Tastendruck zurückgeben: */
return ( *inputreg & (1<<inputbit) );
}

/* Beispiel für einen Funktionsaufruf: */

#include <avr/io.h>

uint8_t i;

//...
i = key_pressed( &PINB, PB1 );
//...
</c>

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.

Im Übrigen können mit volatile gekennzeichnete Variablen auch als const deklariert werden, um sicherzustellen, dass sie nur noch von der Hardware änderbar sind.

= Der UART =

== Allgemeines zum UART ==

Über den [[UART]] kann ein AVR leicht mit einer [[RS-232]]-Schnittstelle eines PC oder sonstiger Geräte mit "serieller Schnittstelle" verbunden werden.

Mögliche Anwendungen des UART:

* 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.
* "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])
* Übertragen von gespeicherten Werten: z.B. bei einem Datenlogger
* Anschluss von Geräten mit serieller Schnittstelle (z.B. (Funk-)Modems, Mobiltelefone, Drucker, Sensoren, "intelligente" LC-Displays, GPS-Empfänger).
* "Feldbusse" auf RS485/RS422-Basis mittels entsprechenden Bustreiberbausteinen (z.B. MAX485)
* DMX, Midi etc.
* LIN-Bus ('''L'''ocal '''I'''nterconnect '''N'''etwork): Preiswerte Sensoren/Aktoren in der Automobiltechnik und darüber hinaus

Einige AVR-Controller haben ein bis zwei vollduplexfähigen UART ('''U'''niversal '''A'''synchronous '''R'''eceiver and '''T'''ransmitter) schon eingebaut ("Hardware-UART").
Übrigens: Vollduplex heißt nichts anderes, als dass der Baustein gleichzeitig senden und empfangen kann.

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.

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.

{| border="1"
|-
| '''UCR   '''
| '''U'''ART '''C'''ontrol '''R'''egister.<br />
In diesem Register stellen wir ein, wie wir den UART verwenden möchten.<br />
Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''RXCIE'''
| align="center" | '''TXCIE'''
| align="center" | '''UDRIE'''
| align="center" | '''RXEN'''
| align="center" | '''TXEN'''
| align="center" | '''CHR9'''
| align="center" | '''RXB8'''
| align="center" | '''TXB8'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 0
|}

'''RXCIE''' ('''RX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
: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.

'''TXCIE''' ('''TX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
: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.

'''UDRIE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty '''I'''nterrupt '''E'''nable)
: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.

'''RXEN''' ('''R'''eceiver '''E'''nable)
: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.

'''TXEN''' ('''T'''ransmitter '''E'''nable)
: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.

'''CHR9''' (9 Bit Characters)
: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:
:1 Startbit + 8 Datenbits + 1 Stopbit + 1 Paritätsbit = 11 Bits

'''RXB8''' (Receive Data Bit 8)
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann enthält dieses Bit das 9. Datenbit eines empfangenen Zeichens.

'''TXB8''' (Transmit Data Bit 8)
: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.

|-
| '''USR   '''
| '''U'''ART '''S'''tatus '''R'''egister.<br />
Hier teilt uns der UART mit, was er gerade so macht.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''RXC'''
| align="center" | '''TXC'''
| align="center" | '''UDRE'''
| align="center" | '''FE'''
| align="center" | '''OR'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''RXC''' (UART Receive Complete)
:Dieses Bit wird vom AVR gesetzt, wenn ein empfangenes Zeichen vom Empfangs-Schieberegister in das Empfangs-Datenregister transferiert wurde.
: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.

'''TXC''' (UART Transmit Complete)
: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.
: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.
:Das Bit wird nur dann automatisch gelöscht, wenn der entsprechende Interrupthandler aufgerufen wird, ansonsten müssen wir das Bit selber löschen.

'''UDRE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty)
: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.
:Das Bit wird automatisch gelöscht, wenn ein Zeichen in das Sendedatenregister geschrieben wird.

'''FE''' ('''F'''raming '''E'''rror)
:Dieses Bit wird vom AVR gesetzt, wenn der UART einen Zeichenrahmenfehler detektiert, d.h. wenn das Stopbit eines empfangenen Zeichens 0 ist.
:Das Bit wird automatisch gelöscht, wenn das Stopbit des empfangenen Zeichens 1 ist.

'''OR''' ('''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.
:Das nachfolgende Zeichen wird verworfen.
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.

|-
| '''UDR'''
| '''U'''ART '''D'''ata '''R'''egister.<br />
Hier werden Daten zwischen UART und CPU übertragen. Da der UART im
Vollduplexbetrieb gleichzeitig empfangen und senden kann, handelt es sich
hier physikalisch um 2 Register, die aber über die gleiche I/O-Adresse
angesprochen werden. Je nachdem, ob ein Lese- oder ein Schreibzugriff auf
den UART erfolgt wird automatisch das richtige UDR angesprochen.
|-
| '''UBRR'''
| '''U'''ART '''B'''aud '''R'''ate '''R'''egister.<br />
In diesem Register müssen wir dem UART mitteilen, wie schnell wir gerne
kommunizieren möchten. Der Wert, der in dieses Register geschrieben
werden muss, errechnet sich nach folgender Formel:

<math>
\begin{matrix}
\mathrm{UBRR} = \frac{\mathrm{Taktfrequenz}}{\mathrm{Baudrate} \cdot 16} - 1
\end{matrix}
</math>

Es sind Baudraten bis zu 115200 Baud und höher möglich.
|}

== Die Hardware ==

Der UART basiert auf normalem TTL-Pegel mit 0V (LOW) und 5V (HIGH). Die
Schnittstellenspezifikation für RS-232 definiert jedoch -3V ... -12V (LOW) und
+3 ... +12V (HIGH). Zudem muss der Signalaustausch zwischen AVR und
Partnergerät invertiert werden. Für die Anpassung der Pegel und das
Invertieren der Signale gibt es fertige Schnittstellenbausteine. Der bekannteste
davon ist wohl der MAX232.


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]].

== UART initialisieren ==

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.

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:

<c>
UCR |= (1<<TXEN);
</c>

Neuere AVRs mit USART haben mehrere Konfigurationsregister und erfordern eine etwas andere Konfiguration. Für einen ATmega16 z.B.:

<c>
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC |= (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0); // Asynchron 8N1
</c>

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.

<c>
/* UART-Init beim AT90S2313 */

#ifndef F_CPU
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann
F_CPU im Makefile definiert werden, eine nochmalige Definition
hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
#ifndef/#endif

Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio
verwendet wird und dort eine andere, nicht zur Hardware passende
Taktrate eingestellt ist: Dann wird die folgende Definition
nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?)
von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
noch nicht definiert: */
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
#define F_CPU 4000000UL // Systemtakt in Hz - Definition als unsigned long beachten >> Ohne ergeben Fehler in der Berechnung
#endif

#define BAUD 9600UL // Baudrate

// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif

int main(void)
{
UCR |= (1<<TXEN);
UBRR = UBRR_VAL;
//...
}
</c>

Wieder für den Mega16 mit zwei Registern für die Baudrateneinstellung eine etwas andere Programmierung. Wichtig ist, dass UBRRH '''vor''' UBRRL geschrieben wird.

<c>
/* USART-Init beim ATmega16 */

int main(void)
{
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
}
</c>

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.

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.

Siehe auch:
* [http://www.wormfood.net/avrbaudcalc.php WormFood's AVR Baud Rate Calculator] online.

== Senden mit dem UART ==

=== Senden einzelner Zeichen ===

Um nun ein Zeichen auf die Schnittstelle auszugeben, müssen wir dasselbe
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).

<c>
// bei AVR mit einem UART ("classic AVR" z.B. AT90S8515)
while (!(USR & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */

/** ODER **/

// bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */
</c>

=== Schreiben einer Zeichenkette (String) ===

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.

<c>
// putc fuer AVR mit einem UART (z.B. AT90S8515)
int uart_putc(unsigned char c)
{
while(!(USR & (1 << UDRE))) /* warte, bis UDR bereit */
{
}

UDR = c; /* sende Zeichen */
return 0;
}

/** ODER **/

// bei neueren AVRs andere Bezeichnung fuer die Statusregister, hier ATmega16:
int uart_putc(unsigned char c)
{
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = c; /* sende Zeichen */
return 0;
}

/* puts ist unabhaengig vom Controllertyp */
void uart_puts (char *s)
{
while (*s)
{ /* so lange *s != '\0' also ungleich dem "String-Endezeichen" */
uart_putc(*s);
s++;
}
}
</c>

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.

=== Schreiben von Variableninhalten ===

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.

<c>
//...

// hier uart_putc (s.o.)

// Ausgabe von 0123456789
char c;

for (uint8_t i=0; i<=9; ++i) {
c = i + '0';
uart_putc( c );
// verkuerzt: uart_putc( i + '0' );
}
</c>

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.

<c>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

int main(void)
{
char s[7];
int16_t i = -12345;

uart_init();

itoa( i, s, 10 ); // 10 fuer radix -> Dezimalsystem
uart_puts( s );

// da itoa einen Zeiger auf den Beginn von s zurueckgibt verkuerzt auch:
uart_puts( itoa( i, s, 10 ) );

while (1) {
;
}

return 0; // never reached
}
</c>

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.

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.)

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]]

<c>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

/* lt. avr-libc Dokumentation:
char* dtostrf(
double __val,
char __width,
char __prec,
char * __s
)
*/

int main(void)
{
// Pufferspeicher ausreichend groß
// evtl. Vorzeichen + width + Endezeichen:
char s[8];
float f = -12.345;

uart_init();

dtostrf( f, 6, 3, s );
uart_puts( s );

// verkürzt: uart_puts( dtostrf( f, 7, 3, s ) );

while (1) {
;
}

return 0; // never reached
}
</c>

== Empfangen ==
=== einzelne Zeichen empfangen ===

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:

<c>
#include <inttypes.h>
#include <avr/io.h>

/* Zusaetzlich zur Baudrateneinstellung und der weiteren Initialisierung: */
void Usart_EnableRX(void)
{
UCSRB |= ( 1 << RXEN );
}

/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}
</c>

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]]  und Quellcodekomponenten (z.B. UART-Library von P. Fleury, procyon-avrlib und einige in der "Academy" von avrfreaks.net).

siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html Dokumenation der avr-libc/stdlib.h]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Die_Nutzung_von_printf Die Nutzung von printf]
* [http://homepage.hispeed.ch/peterfleury/ Peter Fleurys] UART-Bibiliothek fuer avr-gcc/avr-libc


TODO: 9bit

=== Empfang von Zeichenketten (Strings) ===

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.

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.

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.

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.

<C>
/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}

void uart_gets( char* Buffer, uint8_t MaxLen )
{
uint8_t NextChar;
uint8_t StringLen = 0;

NextChar = uart_getc(); // Warte auf und empfange das nächste Zeichen

// Sammle solange Zeichen, bis:
// * entweder das String Ende Zeichen kam
// * oder das aufnehmende Array voll ist
while( NextChar != '\n' && StringLen < MaxLen - 1 ) {
*Buffer++ = NextChar;
StringLen++;
NextChar = uart_getc();
}

// Noch ein '\0' anhängen um einen Standard
// C-String daraus zu machen
*Buffer = '\0';
}
</C>

Beim Aufruf ist darauf zu achten, dass das empfangende Array auch mit einer
vernünftigen Größe definiert wird.

<C>
char Line[40]; // String mit maximal 39 zeichen

uart_gets( Line, sizeof( Line ) );
</C>

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:

<C>
int Line[40]; // Array vom Typ int

uart_gets( Line, sizeof( Line ) / sizeof( Line[0] ) );
</C>

==Interruptbetrieb==

Beim ATMEGA8 muss das RXCIE Bit im Register UCSRB gesetzt werden, damit ein Interrupt ausgelöst werden kann.
Der Interrupt wird immer ausgelöst, wenn Daten erfolgreich empfangen wurden.

Zusätzlich braucht man die Routine:

<c>
ISR (USART_RXC_vect) {
//irgendein Code
}
</c>

natürlich muss "Global Interrupt Enable" Aktiviert sein.
!! Nur getestet beim ATMEGA8 !!

[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.]

* Unterschied Polling-Betrieb (bisher, oben) und Interrupt-Betrieb
* Empfangen (Receive)
** 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)
** 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
* FIFO-Puffer, Ringpuffer
* Senden (Transmit)
** Variante "UART Data Register Empty" (UDRE)
** Variante "UART Transmit Complete" (TXC)
* Fertige UART-Bibliotheken (->Fleury, ->Procyon)
* Literatur:
** 1/ [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48188 avrfreaks.net Tutorial] inkl. Diskussion (engl.)
** 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?]
** 3/ [[Interrupt]] und atomarer Datenzugriff

==Software-UART==

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:
* 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]).
* 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)

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").

==Handshaking==
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.
===Hardwarehandshake (RTS/CTS)===
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.

===Softwarehandshake (XON/XOFF)===
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 />
* '''XOFF''' Aufforderung das Senden einzustellen
* '''XON''' Gegenstelle darf wieder senden

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.

==Fehlersuche==
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.

Eine Checkliste zum Aufspüren solcher Fehler findet sich [[AVR_Checkliste#UART.2FUSART|hier]].

= Analoge Ein- und Ausgabe =

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 analogen 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.

Es existieren keine AVRs mit eingebautem Digital-Analog-Konverter (DAC). Diese Funktion muss durch externe Komponenten nachgebildet werden (z.B. PWM und "Glättung").

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.

== AC (Analog Comparator) ==

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 Comperator 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>

ACSR (0x28) - Analog Comparator Status Register<BR>
{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''ACD'''
| align="center" | '''ACBG'''
| align="center" | '''ACO'''
| align="center" | '''ACI'''
| align="center" | '''ACIE'''
| align="center" | '''ACIC'''
| align="center" | '''ACIS1'''
| align="center" | '''ACIS0'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | n/a
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

<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>
Ergebnis: <BR>IST < SOLL --> 1<BR>
IST > SOLL --> 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) ==

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.

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
die Werte 0V, 0.625V, 1.25, 1.875V, 2.5V, 3.125V, 3.75, 4.375, 5V
daherkommen, siehe dazu folgende Tabelle:

<div align="center">
{| border="1"
|-
| align="center" | '''Eingangsspannung am ADC'''
| align="center" | '''Entsprechender Messwert'''
|-
| align="center" | 0...<0.625V
| align="center" | 0
|-
| align="center" | 0.625...<1.25V
| align="center" | 1
|-
| align="center" | 1.25...<1.875V
| align="center" | 2
|-
| align="center" | 1.875...<2.5V
| align="center" | 3
|-
| align="center" | 2.5...<3.125V
| align="center" | 4
|-
| align="center" | 3.125...<3.75V
| align="center" | 5
|-
| align="center" | 3.75...<4.375V
| align="center" | 6
|-
| align="center" | 4.375...5V
| align="center" | 7
|}
</div>

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.

=== Der interne ADC im AVR ===

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.

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.

Das Ergebnis der Analog-Digital-Wandlung wird auf eine Referenzspannung bezogen. Aktuelle AVRs bieten drei Möglichkeiten zur Wahl dieser Spannung:

* 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.

* 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.

* Die '''interne''' Referenzspannung wird auf '''Vcc''' bezogen, eine externe Referenzspannung auf '''GND (Masse)'''. Davon unabhängig werden digitalisierte Spannungen '''immer''' auf GND bezogen. Beim ATMEGA8 z.B. ist der Pin AREF über 32kOhm mit GND verbunden, d.h. man muss diese doch extrem niedrige Eingangsimpedanz mit in die Berechnung für einen Spannungsteiler einbeziehen, bzw. kann diesen Widerstand als R2 gleich mit benutzen. Formel für Spannungsteiler: Udiv = U / ((R1 + R2) / R2)

Bei Nutzung von Vcc 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.

Der '''ADC''' kann in zwei verschiedenen Betriebsarten verwendet werden:

; Einfache Wandlung (Single Conversion) : In dieser Betriebsart wird der Wandler bei Bedarf vom Programm angestoßen für jeweils eine Messung.

; Frei laufend (Free Running) : In dieser Betriebsart erfasst der Wandler permanent die anliegende Spannung und schreibt diese in das '''ADC Data Register'''.

==== Die Register des ADC ====

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).

{| border="1"
|-
| '''ADCSRA   '''
| '''ADC''' '''C'''ontrol and '''S'''tatus '''R'''egister A.<br />
In diesem Register stellen wir ein, wie wir den '''ADC''' verwenden möchten.<br />
Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''ADEN'''
| align="center" | '''ADSC'''
| align="center" | '''ADFR'''
| align="center" | '''ADIF'''
| align="center" | '''ADIE'''
| align="center" | '''ADPS2'''
| align="center" | '''ADPS1'''
| align="center" | '''ADPS0'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''ADEN''' ('''AD'''C '''En'''able)
: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.

'''ADSC''' ('''AD'''C '''S'''tart '''C'''onversion)
:Mit diesem Bit wird ein Messvorgang gestartet. In der frei laufenden Betriebsart muss das Bit gesetzt werden, um die kontinuierliche Messung zu aktivieren.
: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.
: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.

'''ADFR''' ('''AD'''C '''F'''ree '''R'''un select)
:Mit diesem Bit wird die Betriebsart eingestellt.
: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.

'''ADIF''' ('''AD'''C '''I'''nterrupt '''F'''lag)
: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.
:Wenn das '''ADIE''' Bit sowie das '''I-Bit''' im AVR '''Statusregister''' gesetzt ist, wird der '''ADC Interrupt''' ausgelöst und die Interrupt-Behandlungsroutine aufgerufen.
: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.

'''ADIE''' ('''AD'''C '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist und ebenso das ''' I-Bit''' im Statusregister '''SREG''', dann wird der ''' ADC-Interrupt''' aktiviert.

'''ADPS2...ADPS0''' ('''AD'''C '''P'''rescaler '''S'''elect Bits)
:Diese Bits bestimmen den Teilungsfaktor zwischen der Taktfrequenz und dem Eingangstakt des '''ADC'''.
: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.
:Der Vorteiler muss also so eingestellt werden, dass die CPU-Taktfrequenz dividiert durch den Teilungsfaktor einen Wert zwischen 50-200kHz ergibt.
:Bei einer CPU-Taktfrequenz von 4MHz beispielsweise rechnen wir

:<math>
\begin{matrix}
TF_{min}=\frac{CLK}{200\,\mathrm{kHz}}=\frac{4000000}{200000}=\mathbf{20}
\\
\\
TF_{max}=\frac{CLK}{50\,\mathrm{kHz}}=\frac{4000000}{50000}=\mathbf{80}
\end{matrix}
</math>

:Somit kann hier der Teilungsfaktor 32 oder 64 verwendet werden. Im Interesse der schnelleren Wandlungszeit werden wir hier den Faktor 32 einstellen.
<dl><dd>
{| style="" border="1"
|-
| align="center" | '''ADPS2'''
| align="center" | '''ADPS1'''
| align="center" | '''ADPS0'''
| align="center" | '''Teilungsfaktor'''
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 2
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 2
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 4
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | 8
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 16
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | 32
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | 64
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | 128
|}
</dd></dl>
|-
| '''ADCL'''<br />
'''ADCH'''
| '''ADC ''' Data Register<br />
Wenn eine Umwandlung abgeschlossen ist, befindet sich der gemessene Wert in
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'''.
Der effektive Messwert ergibt sich dann zu:

<c>
x = ADCL; // mit uint16_t x
x += (ADCH<<8); // in zwei Zeilen (LSB/MSB-Reihenfolge und
// C-Operatorpriorität sichergestellt)
</c>

oder

<c>
x = ADCW; // je nach AVR auch x = ADC (siehe avr/ioxxx.h)
</c>

|-
| '''ADMUX  '''
| '''AD'''C '''Mu'''ltiple'''x'''er Select Register<br />
Mit diesem Register wird der zu messende Kanal ausgewählt. Beim 90S8535
kann jeder Pin von Port A als '''ADC'''-Eingang verwendet werden (=8 Kanäle).<br />
Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''REFS1'''
| align="center" | '''REFS0'''
| align="center" | '''ADLAR'''
| align="center" | '''MUX4'''
| align="center" | '''MUX3'''
| align="center" | '''MUX2'''
| align="center" | '''MUX1'''
| align="center" | '''MUX0'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''REFS1...REFS0''' ('''Ref'''erence'''S'''election Bits)
:Mit diesen Bits kann die Referenzspannung eingestellt werden:
<dl><dd>
{| style="" border="1"
|-
| align="center" | '''REFS1'''
| align="center" | '''REFS0'''
| align="center" | '''Referenzspanung'''
|-
| align="center" | 0
| align="center" | 0
| align="center" | Externes AREF
|-
| align="center" | 0
| align="center" | 1
| align="center" | AVCC als Referenz
|-
| align="center" | 1
| align="center" | 0
| align="center" | Reserviert
|-
| align="center" | 1
| align="center" | 1
| align="center" | Interne 2,56 Volt
|}
</dd></dl>

'''ADLAR''' ('''ADC ''' '''L'''eft '''A'''djust '''R'''esult)
: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 rechtsündig. Eine Änderung in diesem Bit beeinflusst das Ergebnis sofort, ganz egal ob bereits eine Wandlung läuft.

'''MUX4...MUX0'''
: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.
: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.

: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.
|}

==== Aktivieren des ADC ====

Um den ''' ADC''' zu aktivieren, müssen wir das '''ADEN'''-Bit im '''ADCSR'''-Register
setzen. Im gleichen Schritt legen wir auch gleich die Betriebsart fest.

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.

<c>
uint16_t ReadChannel(uint8_t mux)
{
uint8_t i;
uint16_t result;

ADMUX = mux; // Kanal waehlen
ADMUX |= (1<<REFS1) | (1<<REFS0); // interne Referenzspannung nutzen

ADCSRA = (1<<ADEN) | (1<<ADPS1) | (1<<ADPS0); // Frequenzvorteiler
// setzen auf 8 (1) und ADC aktivieren (1)

/* nach Aktivieren des ADC wird ein "Dummy-Readout" empfohlen, man liest
also einen Wert und verwirft diesen, um den ADC "warmlaufen zu lassen" */
ADCSRA |= (1<<ADSC); // eine ADC-Wandlung
while ( ADCSRA & (1<<ADSC) ) {
; // auf Abschluss der Konvertierung warten
}
result = ADCW; // ADCW muss einmal gelesen werden,
// sonst wird Ergebnis der nächsten Wandlung
// nicht übernommen.

/* Eigentliche Messung - Mittelwert aus 4 aufeinanderfolgenden Wandlungen */
result = 0;
for( i=0; i<4; i++ )
{
ADCSRA |= (1<<ADSC); // eine Wandlung "single conversion"
while ( ADCSRA & (1<<ADSC) ) {
; // auf Abschluss der Konvertierung warten
}
result += ADCW; // Wandlungsergebnisse aufaddieren
}
ADCSRA &= ~(1<<ADEN); // ADC deaktivieren (2)

result /= 4; // Summe durch vier teilen = arithm. Mittelwert

return result;
}

...

/* Beispielaufrufe: */

void foo(void)
{
uint16_t adcval;

adcval = ReadChannel(0); /* MUX-Bits auf 0b0000 -> Channel 0 */
...
adcval = ReadChannel(2); /* MUX-Bits auf 0b0010 -> Channel 2 */
...
}

</c>

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.



=== Analog-Digital-Wandlung ohne internen ADC ===

==== Messen eines Widerstandes ====

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.

[[Image:Poti.gif]]

Wird der Portpin des Controllers auf Ausgang konfiguriert (im Beispiel ''DDRD |= (1<<PD2)'') und dieser Ausgang auf Logisch 1 ("High", ''PORTD |= (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).

Nach einer gewissen Zeit ist der Kondensator entladen und der Portpin wird als Eingang konfiguriert (''DDRD &= ~(1<<PD2); PORTD &= ~(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.

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.



==== ADC über Komparator ====

Es gibt einen weiteren Weg, eine analoge Spannung mit Hilfe des
Komparators, welcher in fast jedem AVR integriert ist, zu messen. Siehe dazu
auch die Application Note AVR400 von Atmel.

Dabei wird das zu messende Signal auf den invertierenden Eingang
des Komparators geführt. Zusätzlich wird ein Referenzsignal an den nicht
invertierenden Eingang des Komparators angeschlossen. Das Referenzsignal wird
hier auch wieder über ein RC-Glied erzeugt, allerdings mit festen Werten für R
und C.

[[Image:ADC ueber Komparator.gif]]

Das Prinzip der Messung ist nun dem vorhergehenden recht
ähnlich. Durch Anlegen eines LOW-Pegels an Pin 2 wird der Kondensator zuerst
einmal entladen. Auch hier muss darauf geachtet werden, dass der Entladevorgang
genügend lang dauert.<br />
Nun wird Pin 2 auf HIGH gelegt. Der Kondensator wird geladen. Wenn die Spannung
über dem Kondensator die am Eingangspin anliegende Spannung erreicht hat
schaltet der Komparator durch. Die Zeit, welche benötigt wird, um den
Kondensator zu laden kann nun auch wieder als Maß für die Spannung an Pin 1
herangezogen werden.

Ich habe es mir gespart, diese Schaltung auch aufzubauen und
zwar aus mehreren Gründen:

# 3 Pins notwendig.
# Genauigkeit vergleichbar mit einfacherer Lösung.
# War einfach zu faul.

Der Vorteil dieser Schaltung liegt allerdings darin, dass damit
direkt Spannungen gemessen werden können.

== DAC (Digital Analog Converter) ==

Mit Hilfe eines Digital-Analog-Konverters ('''DAC''') können wir nun auch Analogsignale ausgeben. Es gibt hier mehrere Verfahren. 

=== DAC über mehrere digitale Ausgänge ===

Wenn wir an den Ausgängen des Controllers ein entsprechendes
Widerstandsnetzwerk aufbauen haben wir die Möglichkeit, durch die Ansteuerung
der Ausgänge über den Widerständen einen Addierer aufzubauen, mit dessen
Hilfe wir eine dem Zahlenwert proportionale Spannung erzeugen können. Das
Schaltbild dazu kann etwa so aussehen:

[[Image:DAC R2R.gif]]

Es sollten selbstverständlich möglichst genaue Widerstände verwendet
werden, also nicht unbedingt solche mit einer Toleranz von 10% oder mehr.
Weiterhin empfiehlt es sich, je nach Anwendung den Ausgangsstrom über einen
Operationsverstärker zu verstärken.

=== PWM (Pulsweitenmodulation) ===

Wir kommen nun zu einem Thema, welches in aller Munde ist, aber viele
Anwender verstehen nicht ganz, wie '''[[PWM]]''' eigentlich funktioniert.

Wie wir alle wissen, ist ein Mikrocontroller ein rein digitales Bauteil.
Definieren wir einen Pin als Ausgang, dann können wir diesen Ausgang entweder
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:

[[Image:PWM Theorie 1.gif]]

Diese Rechteckspannung hat nun einen arithmetischen Mittelwert,
der je nach Pulsbreite kleiner oder größer ist.

[[Image:PWM Theorie 2.gif]]

Wenn wir nun diese pulsierende Ausgangsspannung noch über ein RC-Glied filtern/"glätten", dann haben wir schon eine entsprechende Gleichspannung erzeugt.

Mit den AVRs können wir direkt '''PWM'''-Signale erzeugen.
Dazu dient der 16-Bit Zähler, welcher im sogenannten '''PWM'''-Modus betrieben werden kann.

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.

Um den '''PWM'''-Modus zu aktivieren, müssen im Timer/Counter1 Control
Register A '''TCCR1A''' die Pulsweiten-Modulatorbits '''PWM10''' bzw. '''PWM11''' entsprechend nachfolgender Tabelle gesetzt werden:

{| border="1"
|-
| align="center" | '''PWM11'''
| align="center" | '''PWM10'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| PWM-Modus des Timers ist nicht aktiv.
|-
| align="center" | 0
| align="center" | 1
| 8-Bit PWM.
|-
| align="center" | 1
| align="center" | 0
| 9-Bit PWM.
|-
| align="center" | 1
| align="center" | 1
| 10-Bit PWM.
|}

Der Timer/Counter zählt nun permanent von 0 bis zur Obergrenze
und wieder zurück, er wird also als sogenannter Auf-/Ab Zähler betrieben.
Die Obergrenze hängt davon ab, ob wir mit 8, 9 oder 10-Bit PWM arbeiten wollen:

{| border="1"
|-
| align="center" | '''Auflösung'''
| align="center" | '''Obergrenze'''
| '''Frequenz'''
|-
| align="center" | 8
| align="center" | 255
| f<sub>TC1</sub> / 510
|-
| align="center" | 9
| align="center" | 511
| f<sub>TC1</sub> / 1022
|-
| align="center" | 10
| align="center" | 1023
| f<sub>TC1</sub> / 2046
|}

Zusätzlich muss mit den Bits '''COM1A1''' und '''COM1A0''' desselben
Registers die gewünschte Ausgabeart des Signals definiert werden:

{| border="1"
|-
| align="center" | '''COM1A1'''
| align="center" | '''COM1A0'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| Keine Wirkung, Pin wird nicht geschaltet.
|-
| align="center" | 0
| align="center" | 1
| Keine Wirkung, Pin wird nicht geschaltet.
|-
| align="center" | 1
| align="center" | 0
| Nicht invertierende PWM.<br />
Der Ausgangspin wird gelöscht beim Hochzählen und gesetzt beim
Herunterzählen.
|-
| align="center" | 1
| align="center" | 1
| Invertierende PWM.<br />
Der Ausgangspin wird gelöscht beim Herunterzählen und gesetzt beim
Hochzählen.
|}

Der entsprechende Befehl, um beispielsweise den Timer/Counter als
nicht invertierenden 10-Bit PWM zu verwenden, heißt dann:

alte Schreibweise (PWMxx wird nicht mehr akzeptiert)
<c>
TCCR1A = (1<<PWM11)|(1<<PWM10)|(1<<COM1A1);
</c>
neue Schreibweise
<c>
TCCR1A = (1<<WGM11)|(1<<WGM10)|(1<<COM1A1);
</c>

Damit der Timer/Counter überhaupt läuft, müssen wir im Control
Register B '''TCCR1B''' noch den gewünschten Takt (Vorteiler) einstellen und
somit auch die Frequenz des '''PWM'''-Signals bestimmen.

{| border="1"
|-
| align="center" | '''CS12'''
| align="center" | '''CS11'''
| align="center" | '''CS10'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stop. Der Timer/Counter wird gestoppt.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CK
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CK / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CK / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CK / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CK / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin 1, negative Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin 1, positive Flanke
|}

Also um einen Takt von CK / 1024 zu generieren, verwenden wir
folgenden Befehl:

<c>
TCCR1B = (1<<CS12) | (1<<CS10);
</c>

Jetzt muss nur noch der Vergleichswert festgelegt werden. Diesen
schreiben wir in das 16-Bit Timer/Counter Output Compare Register '''OCR1A'''.

<c>
OCR1A = xxx;
</c>

Die folgende Grafik soll den Zusammenhang zwischen dem Vergleichswert und dem generierten '''PWM'''-Signal aufzeigen.

[[Image:PWM Theorie 3.gif]]

[[Image:PWM Theorie 4.gif]]

Ach ja, fast hätte ich's vergessen. Das generierte '''PWM'''-Signal
wird am Output Compare Pin '''OC1''' des Timers ausgegeben und leider können wir
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.

Ein Programm, welches an einem ATMega8 den Fast-PWM Modus verwendet, den Modus 14, könnte so aussehen
<C>
#include <avr/io.h>

int main()
{
// OC1A auf Ausgang
DDRB = (1 << PB1 );

//
// Timer 1 einstellen
//
// Modus 14:
// Fast PWM, Top von ICR1
//
// WGM13 WGM12 WGM11 WGM10
// 1 1 1 0
//
// Timer Vorteiler: 1
// CS12 CS11 CS10
// 0 0 1
//
// Steuerung des Ausgangsport: Set at BOTTOM, Clear at match
// COM1A1 COM1A0
// 1 0

TCCR1A = (1<<COM1A1) | (1<<WGM11);
TCCR1B = (1<<WGM13) | (1<<WGM12) | (1<<CS10);

//
// den Endwert (TOP) für den Zähler setzen
// der Zähler zählt bis zu diesem Wert

ICR1 = 0x6FFF;

//
// der Compare Wert
// Wenn der Zähler diesen Wert erreicht, wird mit
// obiger Konfiguration der OC1A Ausgang abgeschaltet
// Sobald der Zähler wieder bei 0 startet, wird der
// Ausgang wieder auf 1 gesetzt
//
// Durch Verändern dieses Wertes, werden die unterschiedlichen
// PWM Werte eingestellt.

OCR1A = 0x3FFF;

while( 1 )
;
}
</C>

PWM Mode Tabelle aus dem Datenblatt des Atmega 8515:

{| border="1"
|-
| align="center" | '''Mode'''
| align="center" | '''WGM13'''
| align="center" | '''WGM12'''
| align="center" | '''WGM11'''
| align="center" | '''WGM10'''
| align="center" | '''Timer/Counter Mode of Operation'''
| align="center" | '''TOP'''
| align="center" | '''Update of OCR1x at'''
| align="center" | '''TOV1 Flag set on'''
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | Normal
| align="center" | 0xFFFF
| align="center" | Immediate
| align="center" | MAX
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | PWM, Phase Correct, 8-Bit
| align="center" | 0x00FF
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 2
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | PWM, Phase Correct, 9-Bit
| align="center" | 0x01FF
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 3
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | PWM, Phase Correct, 10-Bit
| align="center" | 0x03FF
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 4
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | CTC
| align="center" | OCR1A
| align="center" | Immediate
| align="center" | MAX
|-
| align="center" | 5
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | Fast PWM, 8-Bit
| align="center" | 0x00FF
| align="center" | BOTTOM
| align="center" | TOP
|-

| align="center" | 6
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | Fast PWM, 9-Bit
| align="center" | 0x01FF
| align="center" | BOTTOM
| align="center" | TOP
|-

| align="center" | 7
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | Fast PWM, 10-Bit
| align="center" | 0x03FF
| align="center" | BOTTOM
| align="center" | TOP
|-

| align="center" | 8
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | PWM, Phase an Frequency Correct
| align="center" | ICR1
| align="center" | BOTTOM
| align="center" | BOTTOM
|-
| align="center" | 9
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | PWM, Phase an Frequency Correct
| align="center" | OCR1A
| align="center" | BOTTOM
| align="center" | BOTTOM
|-
| align="center" | 10
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | PWM, Phase Correct
| align="center" | ICR1
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 11
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | PWM, Phase an Frequency Correct
| align="center" | OCR1A
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 12
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | CTC
| align="center" | ICR1
| align="center" | Immediate
| align="center" | MAX
|-
| align="center" | 13
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | Reserved
| align="center" | -
| align="center" | -
| align="center" | -
|-
| align="center" | 14
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | Fast PWM
| align="center" | ICR1
| align="center" | BOTTOM
| align="center" | TOP
|-
| align="center" | 15
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | Fast PWM
| align="center" | OCR1A
| align="center" | BOTTOM
| align="center" | TOP
|-
|}

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.

= LCD-Ansteuerung =

==Das LCD und sein Controller==

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:

<table width="0">
<tr><th width="50" align="left">Pin #</th><th width="70" align="left">Bezeichnung</th><th align="left">Funktion</th></tr>
<tr><td>'''1'''</td><td>Vss</td><td>GND</td></tr>
<tr><td>'''2'''</td><td>Vcc</td><td>5V</td></tr>
<tr><td>'''3'''</td><td>Vee</td><td>Kontrastspannung (0V bis 5V)</td></tr>
<tr><td>'''4'''</td><td>RS</td><td>Register Select (Befehle/Daten)</td></tr>
<tr><td>'''5'''</td><td>RW</td><td>Read/Write</td></tr>
<tr><td>'''6'''</td><td>E</td><td>Enable</td></tr>
<tr><td>'''7'''</td><td>DB0</td><td>Datenbit 0</td></tr>
<tr><td>'''8'''</td><td>DB1</td><td>Datenbit 1</td></tr>
<tr><td>'''9'''</td><td>DB2</td><td>Datenbit 2</td></tr>
<tr><td>'''10'''</td><td>DB3</td><td>Datenbit 3</td></tr>
<tr><td>'''11'''</td><td>DB4</td><td>Datenbit 4</td></tr>
<tr><td>'''12'''</td><td>DB5</td><td>Datenbit 5</td></tr>
<tr><td>'''13'''</td><td>DB6</td><td>Datenbit 6</td></tr>
<tr><td>'''14'''</td><td>DB7</td><td>Datenbit 7</td></tr>
<tr><td>'''15'''</td><td>A</td><td>LED-Beleuchtung, Anode</td></tr>
<tr><td>'''16'''</td><td>K</td><td>LED-Beleuchtung, Kathode</td></tr>
</table>

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.

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.

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:

[[Bild:LCD_Vee.gif]]

Es gibt zwei verschiedene Möglichkeiten zur Ansteuerung eines solchen Displays: den '''8-bit-''' und den '''4-bit-'''Modus.
* 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.
* 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).

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.

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.

* Ü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.
* '''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.
* 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.

== Anschluss an den Controller ==

Jetzt da wir wissen, welche Anschlüsse das LCDs benötigt, können wir das LCD mit dem Mikrocontroller verbinden:

<table width="0">
<tr><th align="left">Pin #-LCD</th><th align="left">Bezeichnung-LCD</th><th align="left">Pin-µC</th></tr>
<tr><td>'''1'''</td><td>Vss</td><td>GND</td></tr>
<tr><td>'''2'''</td><td>Vcc</td><td>5V</td></tr>
<tr><td>'''3'''</td><td>Vee</td><td>GND oder Poti (siehe oben)</td></tr>
<tr><td>'''4'''</td><td>RS</td><td>PD4 am AVR</td></tr>
<tr><td>'''5'''</td><td>RW</td><td>GND</td></tr>
<tr><td>'''6'''</td><td>E</td><td>PD5 am AVR</td></tr>
<tr><td>'''7'''</td><td>DB0</td><td>offen</td></tr>
<tr><td>'''8'''</td><td>DB1</td><td>offen</td></tr>
<tr><td>'''9'''</td><td>DB2</td><td>offen</td></tr>
<tr><td>'''10'''</td><td>DB3</td><td>offen</td></tr>
<tr><td>'''11'''</td><td>DB4</td><td>PD0 am AVR</td></tr>
<tr><td>'''12'''</td><td>DB5</td><td>PD1 am AVR</td></tr>
<tr><td>'''13'''</td><td>DB6</td><td>PD2 am AVR</td></tr>
<tr><td>'''14'''</td><td>DB7</td><td>PD3 am AVR</td></tr>
</table>

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.

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?

== Programmierung ==
Datei '''lcd-routines.h'''
<c>
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
//
void lcd_data(unsigned char temp1);
void lcd_string(char *data);
void lcd_command(unsigned char temp1);
void lcd_enable(void);
void lcd_init(void);
void lcd_home(void);
void lcd_clear(void);
void set_cursor(uint8_t x, uint8_t y);

// Hier die verwendete Taktfrequenz in Hz eintragen, wichtig!

#define F_CPU 8000000

// LCD Befehle

#define CLEAR_DISPLAY 0x01
#define CURSOR_HOME 0x02

// Pinbelegung für das LCD, an verwendete Pins anpassen

#define LCD_PORT PORTD
#define LCD_DDR DDRD
#define LCD_RS PD4
#define LCD_EN PD5
// DB4 bis DB7 des LCD sind mit PD0 bis PD3 des AVR verbunden
</c>

Datei '''lcd-routines.c''':
<c>
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
//
// Die Pinbelegung ist über defines in lcd-routines.h einstellbar

#include <avr/io.h>
#include "lcd-routines.h"
#include <util/delay.h>

// sendet ein Datenbyte an das LCD

void lcd_data(unsigned char temp1)
{
unsigned char temp2 = temp1;

LCD_PORT |= (1<<LCD_RS); // RS auf 1 setzen

temp1 = temp1 >> 4;
temp1 = temp1 & 0x0F;
LCD_PORT &= 0xF0;
LCD_PORT |= temp1; // setzen
lcd_enable();

temp2 = temp2 & 0x0F;
LCD_PORT &= 0xF0;
LCD_PORT |= temp2; // setzen
lcd_enable();

_delay_us(42);
}

// sendet einen Befehl an das LCD

void lcd_command(unsigned char temp1)
{
unsigned char temp2 = temp1;

LCD_PORT &= ~(1<<LCD_RS); // RS auf 0 setzen

temp1 = temp1 >> 4; // oberes Nibble holen
temp1 = temp1 & 0x0F; // maskieren
LCD_PORT &= 0xF0;
LCD_PORT |= temp1; // setzen
lcd_enable();

temp2 = temp2 & 0x0F; // unteres Nibble holen und maskieren
LCD_PORT &= 0xF0;
LCD_PORT |= temp2; // setzen
lcd_enable();

_delay_us(42);
}

// erzeugt den Enable-Puls
void lcd_enable(void)
{
// Bei Problemen ggf. Pause gemäß Datenblatt des LCD Controllers einfügen
// http://www.mikrocontroller.net/topic/81974#685882
LCD_PORT |= (1<<LCD_EN);
_delay_us(1); // kurze Pause
// Bei Problemen ggf. Pause gemäß Datenblatt des LCD Controllers verlängern
// http://www.mikrocontroller.net/topic/80900
LCD_PORT &= ~(1<<LCD_EN);
}

// Initialisierung:
// Muss ganz am Anfang des Programms aufgerufen werden.

void lcd_init(void)
{
LCD_DDR = LCD_DDR | 0x0F | (1<<LCD_RS) | (1<<LCD_EN); // Port auf Ausgang schalten

// muss 3mal hintereinander gesendet werden zur Initialisierung

_delay_ms(15);
LCD_PORT &= 0xF0;
LCD_PORT |= 0x03;
LCD_PORT &= ~(1<<LCD_RS); // RS auf 0
lcd_enable();

_delay_ms(5);
lcd_enable();

_delay_ms(1);
lcd_enable();
_delay_ms(1);

// 4 Bit Modus aktivieren
LCD_PORT &= 0xF0;
LCD_PORT |= 0x02;
lcd_enable();
_delay_ms(1);

// 4Bit / 2 Zeilen / 5x7
lcd_command(0x28);

// Display ein / Cursor aus / kein Blinken
lcd_command(0x0C);

// inkrement / kein Scrollen
lcd_command(0x06);

lcd_clear();
}

// Sendet den Befehl zur Löschung des Displays

void lcd_clear(void)
{
lcd_command(CLEAR_DISPLAY);
_delay_ms(5);
}

// Sendet den Befehl: Cursor Home

void lcd_home(void)
{
lcd_command(CURSOR_HOME);
_delay_ms(5);
}

// setzt den Cursor in Zeile y (1..4) Spalte x (0..15)

void set_cursor(uint8_t x, uint8_t y)
{
uint8_t tmp;

switch (y) {
case 1: tmp=0x80+0x00+x; break; // 1. Zeile
case 2: tmp=0x80+0x40+x; break; // 2. Zeile
case 3: tmp=0x80+0x10+x; break; // 3. Zeile
case 4: tmp=0x80+0x50+x; break; // 4. Zeile
default: return; // für den Fall einer falschen Zeile
}
lcd_command(tmp);
}

// Schreibt einen String auf das LCD

void lcd_string(char *data)
{
while(*data) {
lcd_data(*data);
data++;
}
}
</c>

Ein Hauptprogramm, welches die Funktionen benutzt, sieht zb. so aus:

<c>
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include "lcd-routines.h"

int main(void)
{
lcd_init();

lcd_data('T');
lcd_data('e');
lcd_data('s');
lcd_data('t');

set_cursor(0,2);

lcd_string("Hello World!");

while(1)
{
}

return 0;
}
</c>

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).

Ein Hauptprogramm, welches eine Variable ausgibt, sieht zb. so aus.
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:

<c>
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include <stdlib.h>
#include "lcd-routines.h"

// Beispiel
int variable = 42;

int main(void)
{
lcd_init();

// Ausgabe des Zeichens dessen ASCII-Code gleich dem Variablenwert ist
// (Im Beispiel entspricht der ASCII-Code 42 dem Zeichen *)
// http://www.code-knacker.de/ascii.htm
lcd_data(variable);

set_cursor(0,2);

// Ausgabe der Variable als Text in dezimaler Schreibweise
{
// ... umwandeln siehe FAQ Artikel bei www.mikrocontroller.net
// WinAVR hat eine itoa()-Funktion, das erfordert obiges #include <stdlib.h>
char Buffer[20]; // in diesem {} lokal
itoa( variable, Buffer, 10 );

// ... ausgeben
lcd_string( Buffer );
}

while(1)
{
}

return 0;
}

</c>

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).

= Die Timer/Counter des AVR =

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.

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.

Hier kommen die im AVR vorhandenen Timer/Counter zum Einsatz.

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.



Ein anderes Anwendungsgebiet ist die Zählung von Signalen, welche über einen I/O-Pin zugeführt werden können.

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.

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.

== Der Vorteiler (Prescaler) ==

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.

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.

== 8-Bit Timer/Counter ==

Alle AVR-Modelle verfügen über mindestens einen, teilweise sogar zwei, 8-Bit Timer.

Der 8-Bit Timer wird z.B bei AT90S2313 über folgende Register angesprochen (bei anderen Typen weitestgehend analog):

{| border="1"
|-
| '''TCCR0'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister
Timer '''0'''

In diesem Register stellen wir ein, wie wir den Timer/Counter verwenden möchten.

Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''CS02'''
| align="center" | '''CS01'''
| align="center" | '''CS00'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''CS02, CS01, CS00''' ('''C'''lock '''S'''elect Bits)
:Diese 3 Bits bestimmen die Quelle für den Timer/Counter:
<dl><dd>
{| border="1"
|-
| align="center" | CS02
| align="center" | CS01
| align="center" | CS00
| Resultat
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stopp, Der Timer/Counter wird angehalten.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CPU-Takt
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CPU-Takt / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CPU-Takt / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CPU-Takt / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CPU-Takt / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin '''TO''', fallende Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin '''TO''', steigende Flanke
|}
</dd>
</dl>
:Wenn als Quelle der externe Pin '''TO''' verwendet wird, so wird ein Flankenwechsel auch erkannt, wenn der Pin '''TO''' als Ausgang geschaltet ist.

|-
| '''TCNT0'''
| '''T'''imer/'''C'''ou'''nt'''er Daten Register Timer '''0'''<br />
Dieses ist als 8-Bit Aufwärtszähler mit Schreib- und Lesezugriff
realisiert. Wenn der Zähler den Wert 255 erreicht hat beginnt er beim
nächsten Zyklus wieder bei 0.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''MSB'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''LSB'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}
|}

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:

<c>
TCCR0 |= (1<<CS00)|(1<<CS02);
</c>

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
lässt sich durch das Hineinschreiben einer 1 und nicht wie erwartet einer 0 wieder zurücksetzen.

== 16-Bit Timer/Counter ==

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:

* Die [[PWM]]-Betriebsart Erzeugung eines pulsweitenmodulierten Ausgangssignals.
* Vergleichswert-Überprüfung mit Erzeugung eines Ausgangssignals (Output Compare Match).
* Einfangen eines Eingangssignals mit Speicherung des aktuellen Zählerwertes (Input Capturing), mit zuschaltbarer Rauschunterdrückung (Noise Filtering).

Folgende Register sind dem Timer/Counter 1 zugeordnet:

{| border="1"
|-
| '''TCCR1A'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister '''A''' Timer '''1'''<br />
In diesem und dem folgenden Register stellen wir ein, wie wir den Timer/Counter verwenden möchten.<br />
Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''COM1A1'''
| align="center" | '''COM1A0'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''PWM11'''
| align="center" | '''PWM10'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''COM1A1''', '''COM1A0''' ('''Co'''mpare '''M'''atch Control Bits)
: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.
:Der Pin '''OC1''' ('''PB3''' beim 2313) muss mit dem Datenrichtungsregister als Ausgang konfiguriert werden.

<dl><dd>
{| border="1"
|-
| align="center" | COM1A1
| align="center" | COM1A0
| Resultat
|-
| align="center" | 0
| align="center" | 0
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 0
| align="center" | 1
| Das Signal am Pin '''OC1''' wird invertiert (Toggle).
|-
| align="center" | 1
| align="center" | 0
| Der Output Pin '''OC1''' wird auf 0 gesetzt.
|-
| align="center" | 1
| align="center" | 1
| Der Output Pin '''OC1''' wird auf 1 gesetzt.
|}
</dd></dl>
:In der PWM-Betriebsart haben diese Bits eine andere Funktion.
<dl><dd>
{| border="1"
|-
| align="center" | COM1A1
| align="center" | COM1A0
| Resultat
|-
| align="center" | 0
| align="center" | 0
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 0
| align="center" | 1
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 1
| align="center" | 0
| Wird beim Hochzählen der Wert im Vergleichsregister erreicht, so wird der Pin '''OC1''' auf 0 gesetzt.
Wird beim Herunterzählen der Wert im Vergleichsregister erreicht, so wird der Pin auf 1 gesetzt.

Man nennt dies ''nicht invertierende PWM''.
|-
| align="center" | 1
| align="center" | 1
| Wird beim Hochzählen der Wert im Vergleichsregister erreicht, so wird der Pin '''OC1''' auf 1 gesetzt.
Wird beim Herunterzählen der Wert im Vergleichsregister erreicht, so wird der Pin auf 0 gesetzt.

Man nennt dies ''invertierende PWM''.
|}
</dd></dl>

'''PWM11''', '''PWM10''' ('''PWM''' Mode Select Bits)
:Mit diesen 2 Bits wird die PWM-Betriebsart des Timer/Counter 1 gesteuert.
<dl><dd>
{| border="1"
|-
| align="center" | PWM11
| align="center" | PWM10
| Resultat
|-
| align="center" | 0
| align="center" | 0
| Die PWM-Betriebsart ist nicht aktiviert. Timer/Counter 1 arbeitet als normaler Timer bzw. Zähler.
|-
| align="center" | 0
| align="center" | 1
| 8-Bit PWM Betriebsart aktivieren.
|-
| align="center" | 1
| align="center" | 0
| 9-Bit PWM Betriebsart aktivieren.
|-
| align="center" | 1
| align="center" | 1
| 10-Bit PWM Betriebsart aktivieren.
|}
</dd></dl>
|-
| '''TCCR1B'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister '''B''' Timer '''1'''

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''ICNC1'''
| align="center" | '''ICES1'''
| align="center" | '''-'''
| align="center" | '''WGM13'''
| align="center" | '''WGM12 (CTC1)'''
| align="center" | '''CS12'''
| align="center" | '''CS11'''
| align="center" | '''CS10'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''ICNC1''' ('''I'''nput '''C'''apture '''N'''oise '''C'''anceler (4 CKs) Timer/Counter 1
:oder auf Deutsch Rauschunterdrückung des Eingangssignals.
: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.

'''ICES1''' ('''I'''nput '''C'''apture '''E'''dge '''S'''elect Timer/Counter '''1''')
: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.

'''CTC1''' ('''C'''lear '''T'''imer/'''C'''ounter on Compare Match Timer/Counter '''1''')
: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.
:Da die Übereinstimmung im Takt nach dem Vergleich behandelt wird, ergibt sich je nach eingestelltem Vorteiler ein etwas anderes Zählverhalten:
:Wenn der Vorteiler auf 1 gestellt, und C der voreingestellte Vergleichswert ist, dann nimmt das Datenregister, im CPU-Takt betrachtet, folgende Werte an:
:... | C-2 | C-1 | C | 0 | 1 |...
:Wenn der Vorteiler z.B. auf 8 eingestellt ist, dann nimmt das Datenregister folgende Werte an:
:... | 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 |...
:In der PWM-Betriebsart hat dieses Bit keine Funktion.

'''CS12''', '''CS11''', '''CS10''' ('''C'''lock '''S'''elect Bits)
:Diese 3 Bits bestimmen die Quelle für den Timer/Counter:
<dl><dd>
{| border="1"
|-
| align="center" | CS12
| align="center" | CS11
| align="center" | CS10
| Resultat
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stopp, Der Timer/Counter wird angehalten.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CPU-Takt
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CPU-Takt / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CPU-Takt / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CPU-Takt / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CPU-Takt / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin T1, fallende Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin T1, steigende Flanke
|}
</dd></dl>
:Wenn als Quelle der externe Pin T1 verwendet wird, so wird ein Flankenwechsel auch erkannt, wenn der Pin T1 als Ausgang geschaltet ist.
|-
| '''TCNT1H'''<br />'''TCNT1L'''
| '''T'''imer/'''C'''ou'''nt'''er Daten Register Timer/Counter '''1'''
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.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
| align="center" |  
|-
| '''Name'''
| align="center" | '''MSB'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''TCNT1H'''
|-
| '''Name'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''LSB'''
| align="center" | '''TCNT1L'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" |  
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" |  
|}

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.

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.

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.

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.
|-
| '''OCR1H'''<br />'''OCR1L'''
| Timer/Counter '''O'''utput '''C'''ompare '''R'''egister Timer/Counter '''1'''
{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
| align="center" |  
|-
| '''Name'''
| align="center" | '''MSB'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''OCR1H'''
|-
| '''Name'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''LSB'''
| align="center" | '''OCR1L'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" |  
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" |  
|}

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.

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.
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.

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.
|-
| '''ICR1H'''<br />'''ICR1L'''
| Timer/Counter '''I'''nput '''C'''apture '''R'''egister Timer/Counter '''1'''<br />
{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
| align="center" |  
|-
| '''Name'''
| align="center" | '''MSB'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''ICR1''''''H'''
|-
| '''Name'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''LSB'''
| align="center" | '''ICR1''''''L'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" |  
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" |  
|}

Das Input Capture Register ist ein 16-Bit Register mit Lesezugriff. Es kann nicht beschrieben werden.

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.

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:

{| border="0"
|-
| Lesen:
| '''ICR1L''' -> '''ICR1H'''
|}
|}

=== Die PWM-Betriebsart ===

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.
Die Obergrenze ergibt sich daraus, ob 8-, 9- oder 10-Bit PWM verwendet wird, und zwar gemäß folgender Tabelle:

{| border="1"
|-
| align="center" | '''Auflösung'''
| align="center" | '''Obergrenze'''
| '''Frequenz'''
|-
| align="center" | 8
| align="center" | 255
| f<sub>TC1</sub> / 510
|-
| align="center" | 9
| align="center" | 511
| f<sub>TC1</sub> / 1022
|-
| align="center" | 10
| align="center" | 1023
| f<sub>TC1</sub> / 2046
|}

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.

Ich habe versucht, die entsprechenden Signale in der folgenden Grafik zusammenzufassen

[[Image:PWM Theorie 3.gif]] [[Image:PWM Theorie 4.gif]]

=== Vergleichswert-Überprüfung ===

Hier wird in ein spezielles Vergleichswertregister ('''OCR1H'''/'''OCR1L''') ein Wert eingeschrieben, welcher ständig mit dem aktuellen Zählerwert verglichen wird.
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.

=== Einfangen eines Eingangssignals (Input Capturing) ===

Bei dieser Betriebsart wird an den Input Capturing Pin (ICP) des Controllers eine Signalquelle angeschlossen.
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.
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.

== Gemeinsame Register ==

Verschiedene Register beinhalten Zustände und Einstellungen, welche sowohl
für den 8-Bit, als auch für den 16-Bit Timer/Counter in ein und demselben
Register zu finden sind.

{| border="1"
|-
| '''TIMSK'''
| '''T'''imer/Counter '''I'''nterrupt '''M'''a'''sk'''
Register

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''TOIE1'''
| align="center" | '''OCIE1A'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''TICIE'''
| align="center" | '''-'''
| align="center" | '''TOIE0'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R
| align="center" | R/W
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''TOIE1''' ('''T'''imer/Counter '''O'''verflow '''I'''nterrupt '''E'''nable Timer/Counter '''1''')
: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.

'''OCIE1A''' ('''O'''utput '''C'''ompare Match '''I'''nterrupt '''E'''nable Timer/Counter '''1''')
:Beim Timer/Counter 1 kann zusätzlich zum Überlauf ein Vergleichswert definiert werden.

: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.

'''TICIE''' ('''T'''imer/Counter '''I'''nput '''C'''apture '''I'''nterrupt '''E'''nable)
: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.

'''TOIE0''' ('''T'''imer/Counter '''O'''verflow '''I'''nterrupt '''E'''nable Timer/Counter '''0''')
: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.

|-
| '''TIFR'''
| '''T'''imer/Counter '''I'''nterrupt '''F'''lag '''R'''egister

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''TOV1'''
| align="center" | '''OCF1A'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''ICF1'''
| align="center" | '''-'''
| align="center" | '''TOV0'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R
| align="center" | R/W
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''TOV1''' ('''T'''imer/Counter '''O'''verflow Flag Timer/Counter '''1''')
:Dieses Bit wird vom Controller gesetzt, wenn beim Timer 1 ein Überlauf des Datenregisters stattfindet.

: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).

: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.

'''OCF1A''' ('''O'''utput '''C'''ompare '''F'''lag Timer/Counter '''1''')
:Dieses Bit wird gesetzt, wenn der aktuelle Wert des Datenregisters von Timer/Counter 1 mit demjenigen im Vergleichsregister '''OCR1''' übereinstimmt.

: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.

'''ICF1''' ('''I'''nput '''C'''apture '''F'''lag Timer/Counter '''1''')
: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.

: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.

'''TOV0''' ('''T'''imer/Counter '''O'''verflow Flag Timer/Counter '''0''')
:Dieses Bit wird vom Controller gesetzt, wenn beim Timer 0 ein Überlauf des Datenregisters stattfindet.

: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.
|}

 

= Warteschleifen (delay.h) =

Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:

* Warten im Sinn von Zeitvertrödeln
* Warten auf einen bestimmten Zustand an den I/O-Pins
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)
* Warten auf einen bestimmten Zählerstand (siehe Counter)

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.

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.

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.

Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.

== avr-libc Versionen kleiner 1.6 ==

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.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus
<c>
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */

/*
lange, variable Verzögerungszeit, Einheit in Millisekunden

Die maximale Zeit pro Funktionsaufruf ist begrenzt auf
262.14 ms / F_CPU in MHz (im Beispiel:
262.1 / 3.6864 = max. 71 ms)

Daher wird die kleine Warteschleife mehrfach aufgerufen,
um auf eine längere Wartezeit zu kommen. Die zusätzliche
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig
ungenau werden (macht hier vielleicht 2-3ms aus).
*/

void long_delay(uint16_t ms) {
for(; ms>0; ms--) _delay_ms(1);
}

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
long_delay(1000); // Eine Sekunde warten...
}

return 0;
}
</c>

== avr-libc Versionen ab 1.6 ==

_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.

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.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6
<c>
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...
// funktioniert nicht mit Bibliotheken vor 1.6

}
return 0;
}
</c>

= Der Watchdog =

Und hier kommt das ultimative Mittel gegen die Unvollkommenheit von uns
Programmierern, der Watchdog.

So sehr wir uns auch anstrengen, es wird uns kaum je gelingen, das absolut
perfekte und fehlerfreie Programm zu entwickeln.

Der Watchdog kann uns zwar auch nicht zu besseren Programmen verhelfen aber er
kann dafür sorgen, dass unser Programm, wenn es sich wieder mal in's Nirwana
verabschiedet hat, neu gestartet wird, indem ein Reset des Controllers
ausgelöst wird.

Betrachten wir doch einmal folgende Codesequenz:

<c>
uint8_t x;

x = 10;

while (x >= 0)
{
// tu was

x--;
}
</c>

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).
Das Programm würde sich also hier aufhängen und auf ewig in der Schleife drehen.
Und hier genau kommt der Watchdog zum Zug.

== Wie funktioniert nun der Watchdog? ==

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.
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).
Dies sollte innerhalb unserer Hauptschleife passieren.

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.
Dann muss innerhalb der nächsten 4 Taktzyklen das Bit WDE auf 0 gesetzt werden.

Das Watchdog Control Register:

{| border="1"
|-
| '''WDTCR'''
| '''W'''atchog '''T'''imer  '''C'''ontrol '''R'''egister

In diesem Register stellen wir ein, wie wir den Watchdog verwenden möchten.

Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''WDTOE'''
| align="center" | '''WDE'''
| align="center" | '''WDP2'''
| align="center" | '''WDP1'''
| align="center" | '''WDP0'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''WDTOE''' ('''W'''atch'''d'''og '''T'''urn '''O'''ff '''E'''nable)
:Dieses Bit muss gesetzt sein, wenn das Bit '''WDE''' gelöscht wird, andernfalls wird der Watchdog nicht ausgeschaltet.
:Wenn das Bit einmal gesetzt ist, wird es von der Hardware nach 4 Taktzyklen automatisch wieder gelöscht.

'''WDE''' ('''W'''atch'''d'''og '''E'''nable)
:Wenn dieses Bit gesetzt wird, so wird der Watchdog aktiviert.
:Das Bit kann nur gelöscht werden, solange das Bit '''WDTOE''' auf 1 steht.

'''WDP2''', '''WDP1''', '''WDP0''' ('''W'''atch'''d'''og Timer '''P'''rescaler Bits)
:Diese 3 Bits bestimmen die Anzahl Oszillatorzyklen für den Watchdog, also, wie lange es dauert, bis ein Reset ausgelöst wird:
<dl><dd>
{| border="1"
|-
| align="center" | WDP2
| align="center" | WDP1
| align="center" | WDP0
| align="center" | Anzahl Zyklen
| align="center" | Typ. Timeoutzeit bei Vcc = 3V
| align="center" | Typ. Timeoutzeit bei Vcc = 5V
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 16K
| align="center" | 47ms
| align="center" | 15ms
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 32K
| align="center" | 94ms
| align="center" | 30ms
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 64K
| align="center" | 0.19s
| align="center" | 60ms
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | 128K
| align="center" | 0.38s
| align="center" | 0.12s
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 256K
| align="center" | 0.75s
| align="center" | 0.24s
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | 512K
| align="center" | 1.5s
| align="center" | 0.49s
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | 1024K
| align="center" | 3s
| align="center" | 0.97s
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | 2048K
| align="center" | 6s
| align="center" | 1.9s
|}
</dd></dl>
|}

Um den Watchdog mit dem AVR-GCC Compiler zu verwenden, muss die Headerdatei ''wdt.h'' (''#include <avr/wdt.h>'') in die Quelldatei eingebunden werden.

Danach können die folgenden Funktionen verwendet werden:

* '''wdt_enable(uint8_t timeout)'''
: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
:Mögliche Timeoutwerte:
<div align="center">
{| border="1"
! Konstante
! Wert
! TimeOut
|-
| WDTO_15MS
| 0
| 15 ms
|-
| WDTO_30MS
| 1
| 30 ms
|-
| WDTO_60MS
| 2
| 60 ms
|-
| WDTO_120MS
| 3
| 120 ms
|-
| WDTO_250MS
| 4
| 250 ms
|-
| WDTO_500MS
| 5
| 500 ms
|-
| WDTO_1S
| 6
| 1 s
|-
| WDTO_2S
| 7
| 2 s
|}
</div>
* '''wdt_disable()'''
:Mit dieser Funktion kann der Watchdog ausgeschaltet werden. Dabei wird das notwendige Prozedere, wie oben beschrieben, automatisch ausgeführt.
* '''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.

Selbstverständlich kann das '''WDTCR'''-Register auch mit den uns bereits bekannten Funktionen für den Zugriff auf Register programmiert werden.

== Watchdog-Anwendungshinweise ==

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.

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).

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Watchdog timer handling
* [http://www.mikrocontroller.net/topic/77273#642501 Bug in ATtiny2313?]

= Programmieren mit Interrupts =

Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich
die Programmierung unter Zuhilfenahme der Interrupts des AVR.

Als erstes wollen wir uns noch einmal den allgemeinen Programmablauf bei der
Interrupt-Programmierung zu Gemüte führen.

[[Image:Interrupt Programme.gif]]

Man sieht, dass die Interruptroutine quasi parallel zum Hauptprogramm
abläuft. Da wir nur eine CPU haben ist es natürlich keine echte Parallelität,
sondern das Hauptprogramm wird beim Eintreffen eines Interrupts unterbrochen,
die Interruptroutine wird ausgeführt und danach erst wieder zum Hauptprogramm
zurückgekehrt.

[http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]

== Anforderungen an Interrupt-Routinen ==

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:

* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)
* Keine langen Programmschleifen.
* 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.

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.

(*)
Hinweis:
Es gibt allerdings die seltene Situation, dass man gerade eingelesene
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!

== Interrupt-Quellen ==

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.

* Reset
* Externer Interrupt 0
* Externer Interrupt 1
* Timer/Counter 1 Capture Ereignis
* Timer/Counter 1 Compare Match
* Timer/Counter 1 Überlauf
* Timer/Counter 0 Überlauf
* UART Zeichen empfangen
* UART Datenregister leer
* UART Zeichen gesendet
* Analoger Komparator

Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").

== Register ==

Der AT90S2313 verfügt über 2 Register die mit den
Interrupts zusammen hängen.

{| border="1"
|-
| '''GIMSK'''
| '''G'''eneral '''I'''nterrupt '''M'''ask '''R'''egister.<br />

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''INT1'''
| align="center" | '''INT0'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''INT1''' (External '''Int'''errupt Request '''1''' Enable)
: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.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
: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.

'''INT0''' (External '''Int'''errupt Request '''0''' Enable)
: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.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
: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.

|-
| '''GIFR'''
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''INTF1'''
| align="center" | '''INTF0'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''INTF1''' (External '''Int'''errupt Flag '''1''')
: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.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.

'''INTF0''' (External '''Int'''errupt Flag '''0''')
: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.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.
|-
| '''MCUCR'''
| '''MCU''' '''C'''ontrol '''R'''egister.

Das MCU Control Register enthält Kontrollbits für allgemeine
MCU-Funktionen.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''SE'''
| align="center" | '''SM'''
| align="center" | '''ISC11'''
| align="center" | '''ISC10'''
| align="center" | '''ISC01'''
| align="center" | '''ISC00'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''SE''' ('''S'''leep '''E'''nable)
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.

'''SM''' ('''S'''leep '''M'''ode)
:Dieses Bit bestimmt der Schlafmodus.
: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")

'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.
<dl><dd>
{| border="1"
|-
| align="center" | '''ISC11'''
| align="center" | '''ISC10'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT1''' erzeugt einen Interrupt.

In der Beschreibung heißt es, der Interrupt wird getriggert, solange der Pin auf 0 bleibt, also eigentlich unbrauchbar.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.
|}
</dd></dl>
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.

<dl><dd>
{| border="1"
|-
| align="center" | '''ISC01'''
| align="center" | '''ISC00'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT0''' erzeugt einen Interrupt.

In der Beschreibung heißt es, der Interrupt wird getriggert, solange der Pin auf 0 bleibt, also eigentlich unbrauchbar.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.
|}
</dd></dl>
|}

== Allgemeines über die Interrupt-Abarbeitung ==

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, rate ich dringend davon ab. 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
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.



== Interrupts mit dem AVR GCC Compiler (WinAVR) ==


Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').

<c>
// fuer sei(), cli() und ISR():
#include <avr/interrupt.h>
</c>

Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.

<c>
sei();
</c>

Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.

<c>
cli();
</c>

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 Interrups aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:

<c>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>

//...

void NichtUnterbrechenBitte(void)
{
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister

tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern
cli(); // Interrupts global deaktivieren

/* hier "unterbrechnungsfreier" Code */

/* Beispiel Anfang
JTAG-Interface eines ATmega16 per Software deaktivieren
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229):
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */

MCUCSR |= (1<<JTD);
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information

/* Beispiel Ende */

SREG = tmp_sreg; // Status-Register wieder herstellen
// somit auch das I-Flag auf gesicherten Zustand setzen
}

void NichtSoGut(void)
{
cli();

/* hier "unterbrechnungsfreier" Code */

sei();
}

int main(void)
{
//...

cli();
// Interrupts global deaktiviert

NichtUnterbrechenBitte();
// auch nach Aufruf der Funktion deaktiviert

sei();
// Interrupts global aktiviert

NichtUnterbrechenBitte();
// weiterhin aktiviert
//...

/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */
cli();
// Interrupts jetzt global deaktiviert

NichtSoGut();
// nach Aufruf der Funktion sind Interrupts global aktiviert
// dies ist mglw. ungewollt!
//...

}
</c>



Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft. Dazu existiert die Definition (ein Makro) '''ISR'''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe Abschnitt (TODO: verlinken) im Anhang.


=== ISR ===

(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. vgl. [[AVR-GCC-Tutorial#Anhang|Anhang]])



<c>
#include <avr/interrupt.h>
//...
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */
{
/* Interrupt Code */
}
</c>

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.

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.

<c>
//...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */

/* avr/iom8.h - definitions for ATmega8 */
//...

/* Interrupt vectors */

/* External Interrupt Request 0 */
#define INT0_vect _VECTOR(1)
#define SIG_INTERRUPT0 _VECTOR(1)

/* External Interrupt Request 1 */
#define INT1_vect _VECTOR(2)
#define SIG_INTERRUPT1 _VECTOR(2)

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)

/* Timer/Counter2 Overflow */
#define TIMER2_OVF_vect _VECTOR(4)
#define SIG_OVERFLOW2 _VECTOR(4)

/* Timer/Counter1 Capture Event */
#define TIMER1_CAPT_vect _VECTOR(5)
#define SIG_INPUT_CAPTURE1 _VECTOR(5)

/* Timer/Counter1 Compare Match A */
#define TIMER1_COMPA_vect _VECTOR(6)
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)

/* Timer/Counter1 Compare Match B */
#define TIMER1_COMPB_vect _VECTOR(7)
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)

//...
</c>


Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:

<c>
#include <avr/interrupt.h>
/* veraltet: #include <avr/signal.h> */

ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */
{
/* Interrupt Code */
}

ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
/* Interrupt Code */
}

ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */
{
/* Interrupt Code */
}

// und so weiter und so fort...
</c>

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]]).

Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.

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.

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.

=== Unterbrechbare Interruptroutinen ===

"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.



<c>
#include <avr/interrupt.h>
//...
void XXX_vect(void) __attribute__((interrupt));
void XXX_vect(void) {
//...
}
</c>

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. 

siehe auch: Hinweise in [[AVR-GCC]]

siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

== Datenaustausch mit Interrupt-Routinen ==

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.

Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.

<c>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdint.h>
//...

// Schwellwerte
// Entprellung:
#define CNTDEBOUNCE 10
// "lange gedrueckt:"
#define CNTREPEAT 200

// hier z.B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt
#define KEY_PIN PINA
#define KEY_PINNO PA2

// beachte: volatile!
volatile uint8_t gKeyCounter;

// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt
ISR(TIMER1_COMPA_vect)
{
// hier wird gKeyCounter veraendert. Die übrigen
// Programmteile müssen diese Aenderung "sehen":
// volatile -> aktuellen Wert immer in den Speicher schreiben
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
}
else {
gKeyCounter = 0;
}
}

//...

int main(void)
{
//...
/* hier: Initialisierung der Ports und des Timer-Interrupts */
//...
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der
// ISR geschriebene Wert bekannt sein:
// volatile -> aktuellen Wert immer aus dem Speicher lesen
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"
if (gKeyCounter == CNTREPEAT) {
/* hier: Code fuer "Taste lange gedrueckt" */
}
else {
/* hier: Code fuer "Taste kurz gedrueckt" */
}
}
//...
}
</c>

=== volatile und Pointer ===

Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable auf die der Pointer zeigt '''volatile''' ist.

<c>
volatile uint8_t *a; // das Ziel von a ist volatile

uint8_t *volatile a; // a selbst ist volatile
</c>

=== Variablen größer 1 Byte ===

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:

<c>
//...
volatile uint16_t gMyCounter16bit;
//...
ISR(...)
{
//...
gMyCounter16Bit++;
//...
}

int main(void)
{
uint16_t tmpCnt;
//...
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.
tmpCnt = gMyCounter16bit;

// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"
// bleiben konsistent
cli(); // Interupts deaktivieren
tmpCnt = gMyCounter16Bit;
sei(); // wieder aktivieren

// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten
uint8_t sreg_tmp;
sreg_tmp = SREG; /* Sichern */
cli()
tmpCnt = gMyCounter16Bit;
SREG = sreg_tmp; /* Wiederherstellen */

// oder: mehrfach lesen, bis man konsistente Daten hat
uint16_t count1 = gMyCounter16Bit;
uint16_t count2 = gMyCounter16Bit;
while (count1 != count2) {
count1 = count2;
count2 = gMyCounter16Bit;
}
tmpCnt = count1;
//...
}
</c>

== Interrupt-Routinen und Registerzugriffe ==

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.

Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:

<c>
#include <avr/io.h>

int main(void)
{
//...
PORTA |= (1<<PA0);

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
//...
}
</c>

Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:

<div class="code"><pre>
...
PORTA |= (1<<PA0);
d2: d8 9a sbi 0x1b, 0 ; 27 (a)

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
d4: 8b b3 in r24, 0x1b ; 27 (b)
d6: 8c 61 ori r24, 0x1C ; 28 (c)
d8: 8b bb out 0x1b, r24 ; 27 (d)
...
</pre></div>

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.

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.

Lösungsmöglichkeiten:
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").
* 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).

* 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)

== Was macht das Hauptprogramm? ==

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.

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.

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals

= Sleep-Modes =

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.
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.

* '''set_sleep_mode(uint8_t mode)'''
: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.
* '''sleep_enable()'''
:aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus
* '''sleep_cpu()'''
: Versetzt den Controller in den Schlafmodus (sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt)
* '''sleep_disable()'''
:deaktiviert den gesetzten Schlafmodus
* '''sleep_mode()'''
: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).

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).

<c>
#include <avr/io.h>
#include <avr/sleep.h>

int main(void)
{
...

while (1) {
...
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

// Code hier wird erst nach Auftreten eines entsprechenden
// "Aufwach-Interrupts" verarbeitet
...
}
}
</c>

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():

<c>
#include <avr/io.h>
...
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren
SMCR = (3<<SM0) | (1<<SE);
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h
...
</c>

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.

= Speicherzugriffe =

Atmel AVR-Controller verfügen typisch über drei Speicher:

* [[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.

* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.

* [[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.

Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"
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.

== RAM ==

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.

Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "allozieren" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.

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).

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.

Beispiel zur Verwendung von malloc():
<c>
#include <stdlib.h>

void foo(void) {
// neuen speicherbereich anlegen,
// platz für 10 uint16
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));

// darauf zugreifen, als wärs ein gewohnter Buffer
pBuffer[2] = 5;

// Speicher (unbedingt!) wieder freigeben
free(pBuffer);
}
</c>

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.

siehe auch:
* http://www.nongnu.org/avr-libc/user-manual/malloc.html

== Programmspeicher (Flash) ==

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.

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.

<c>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

//...

/* Byte */
const uint8_t pgmFooByte PROGMEM = 123;

/* Wort */
const uint16_t pgmFooWort PROGMEM = 12345;

/* Byte-Feld */
const uint8_t pgmFooByteArray1[] PROGMEM = { 18, 3 ,70 };
const uint8_t pgmFooByteArray2[] PROGMEM = { 30, 7 ,79 };

/* Zeiger */
const uint8_t *pgmPointerToArray1 PROGMEM = pgmFooByteArray1;
const uint8_t *pgmPointerArray[] PROGMEM = { pgmFooByteArray1, pgmFooByteArray2 };
//...

void foo(void)
{
static /*const*/ uint8_t pgmTestByteLocal PROGMEM = 0x55;
static /*const*/ char pgmTestStringLocal[] PROGMEM = "im Flash";
// so nicht (static fehlt): char pgmTestStringLocalFalsch [] PROGMEM = "so nicht";

// ...

}
</c>

=== Byte lesen ===

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.

<c>
const uint8_t pgmFooByte PROGMEM = 123;
const uint8_t pgmFooByteArray1[] PROGMEM = { 18, 3 ,70 };

// Wert der Ram-Variablen myByte auf den Wert von pgmFooByte setzen:
uint8_t myByte;

myByte = pgm_read_byte(&pgmFooByte);
// myByte hat nun den Wert 123

//...

// Schleife ueber ein Array aus Byte-Werten im Flash
uint8_t i;

for (i=0;i<3;i++) {
myByte = pgm_read_byte(&pgmFooByteArray1[i]);
// mach' was mit myByte....
}
</c>

=== Wort lesen ===

Für "einfache" 16-bit breite Variablen erfolgt der Zugriff analog zum Byte-Beispiel, jedoch mit der Funktion pgm_read_word.

<c>
const uint16_t pgmFooWort PROGMEM = 12345;

uint16_t myWord;

myWord = pgm_read_word(&pgmFooWort);
</c>

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. 

<c>
uint8_t *ptrToArray;

ptrToArray = (uint8_t*)(pgm_read_word(&pgmPointerToArray1));
// ptrToArray enthält nun die Startadresse des Byte-Arrays pgmFooByteArray1
// Allerdings würde ein direkter Zugriff mit diesem Pointer (z.B. temp=*ptrToArray)
// '''nicht''' den Inhalt von pgmFooByteArray1[0] liefern, sondern von einer Speicherstelle
// im '''RAM''', die die gleiche Adresse hat wie pgmFooByteArray1[0]
// Daher muss nun die Funktion pgm_read_byte() benutzt werden, die die in ptrToArray
// enthaltene Adresse benutzt und auf das Flash zugreift.

for (i=0;i<3;i++) {
myByte = pgm_read_byte(ptrToArray+i);
// mach' was mit myByte... (18, 3, 70)
}

ptrToArray = (uint8_t*)(pgm_read_word(&pgmPointerArray[1]));

// ptrToArray enthält nun die Adresse des ersten Elements des Byte-Arrays pgmFooByteArray2
// da im zweiten Element des Pointer-Arrays pgmPointerArray die Adresse
// von pgmFooByteArray2 abgelegt ist

for (i=0;i<3;i++) {
myByte = pgm_read_byte(ptrToArray+i);
// mach' was mit myByte... (30, 7, 79)
}
</c>

=== Floats und Structs lesen ===

Um komplexe Datentypen (structs), nicht-integer Datentypen (floats) aus dem Flash auszulesen, sind Hilfsfunktionen erforderlich. Einige Beispiele:

<c>
/* Beispiel float aus Flash */

float pgmFloatArray[3] PROGMEM = {1.1, 2.2, 3.3};
//...

/* liest float von Flash-Addresse addr und gibt diese als return-value zurueck */
inline float pgm_read_float(const float *addr)
{
union
{
uint16_t i[2]; // 2 16-bit-Worte
float f;
} u;

u.i[0]=pgm_read_word((PGM_P)addr);
u.i[1]=pgm_read_word((PGM_P)addr+2);

return u.f;
}
...

void egal(void)
{
int i;
float f;

for (i=0;i<3;i++) {
f = pgm_read_float(&pgmFloatArray[i]); // entspr. "f = pgmFloatArray[i];"
// mach' was mit f
}
}
</c>

TODO: Beispiele fuer structs und pointer aus flash auf struct im flash (menues, state-machines etc.)

=== Array aus Zeichenketten im Flash-Speicher ===

Felder aus Zeichenketten im Flash-Speicher werden in zwei Schritten angelegt: Zuerst die einzelnen Elemente des Arrays und im Anschluss ein Array, in dem die Addressen der Zeichenketten 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 (die Zeichenkette) selbst zuzugreifen.

<c>
#include <stdint.h>
#include <avr/pgmspace.h>

const char str1[] PROGMEM = "first_A";
const char str2[] PROGMEM = "second_A";
const char str3[] PROGMEM = "third_A";

const char *strarray1[] PROGMEM = {
str1,
str2,
str3
};

int main(void)
{
int i, j, l;
const char *pstrflash;
char work[20], work2[20];
// fuer Simulation: per volatile Optimierung verhindern,
// da c nicht genutzt
volatile char c;

for ( i = 0; i < (sizeof(strarray1)/sizeof(strarray1[0]) ); i++ ) {

// setze Pointer auf die Addresse des i-ten Elements des
// "Flash-Arrays" (str1, str2, ...)
pstrflash = (const char*)( pgm_read_word( &(strarray1[i]) ) );

// kopiere den Inhalt der Zeichenkette von der
// in pstrflash abgelegten Adresse in das work-Array
// analog zu strcpy( work, strarray1[i]) wenn alles im RAM
strcpy_P( work, pstrflash );
// verkuerzt:
strcpy_P( work2, (const char*)( pgm_read_word( &(strarray1[i]) ) ) );

// Zeichen-fuer-Zeichen
l = strlen_P( pstrflash );
for ( j=0; j < l; j++ ) {
// analog zu c=strarray[i][j] wenn alles im RAM
c = (char)( pgm_read_byte( pstrflash++ ) );
}
}

while (1) { ; }
}
</c>

Siehe dazu auch die avr-libc FAQ: "How do I put an array of strings completely in ROM?"

=== Vereinfachung für Zeichenketten (Strings) im Flash ===

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.

<c>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <string.h>

#define MAXLEN 30

char StringImFlash[] PROGMEM = "Erwin Lindemann"; // im "Flash"
char StringImRam[MAXLEN];

//...
strcpy(StringImRam, "Mueller-Luedenscheidt");

if (!strncmp_P(StringImRam, StringImFlash, 5)) {
// mach' was, wenn die ersten 5 Zeichen identisch - hier nicht
}
else {
// der Code hier wuerde ausgefuehrt
}

if (!strncmp_P(StringImRam, PSTR("Mueller-Schmitt"), 5)) {
// der Code hier wuerde ausgefuehrt, die ersten 5 Zeichen stimmen ueberein
}
else {
// wuerde bei nicht-Uebereinstimmung ausgefuehrt
}
//...
</c>

Aber Vorsicht: Ersetzt man zum Beispiel
<c>
const char textImFlashOK[] PROGMEM = "mit[]";
// = Daten im "Flash", textImFlashOK* zeigt auf Flashadresse
</c>
durch
<c>
const char* textImFlashProblem PROGMEM = "mit*";
// Konflikt: Daten im BSS (lies: RAM), textImFlashFAIL* zeigt auf Flashadresse
</c>
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.

Ü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.

Eine Funktion, die einen im Flash abgelegten String z.B. an eine UART ausgibt, würde dann so aussehen:

<c>
void uart_puts_p(const char *text)
{
char Zeichen;

while (Zeichen = pgm_read_byte(text))
{ /* so lange, wie mittels pgm_read_byte ein Zeichen vom Flash gelesen
werden konnte, welches nicht das "String-Endezeichen" darstellt */

/* Das gelesene Zeichen über die normalen Kanäle verschicken */
uart_putc(Zeichen);
text++;
}
}
</c>

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:

<c>
// Ausschnitt aus dem Header-File lcd.h der "Fleury-LCD-Lib."
//...
extern void lcd_puts_p(const char *progmem_s);
#define lcd_puts_P(__s) lcd_puts_p(PSTR(__s))
//...

// in einer Anwendung (wieauchimmmer.c)
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <string.h>
#include "lcd.h"

char StringImFlash[] PROGMEM = "Erwin Lindemann"; // im "Flash"

//...
lcd_puts_p(StringImFlash);
lcd_puts_P("Dr. Kloebner");
// daraus wird wg. #define lcd_put_P...: lcd_puts_p( PSTR("Dr. Kloebner") );
//...
</c>

=== Flash in der Anwendung schreiben ===

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.

=== Warum so kompliziert? ===

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.
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.

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.

* 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

== EEPROM ==

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.
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.

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.

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.

Bei der Deklaration einer Variable im EEPROM, ist das Attribut für die Section ".eeprom" zu ergänzen. Siehe dazu folgendes Beispiel:

<c>
#include <avr/io.h>
#include <avr/eeprom.h>
#include <avr/interrupt.h>
#include <inttypes.h> // wird in aktuellen Versionen der avr-lib mit xx.h eingebunden

// EEMEM wird bei aktuellen Versionen der avr-lib in eeprom.h definiert
// hier: definiere falls noch nicht bekannt ("alte" avr-libc)
#ifndef EEMEM
// alle Textstellen EEMEM im Quellcode durch __attribute__ ... ersetzen
#define EEMEM __attribute__ ((section (".eeprom")))
#endif

//...

/* Byte */
uint8_t eeFooByte EEMEM = 123;

/* Wort */
uint16_t eeFooWord EEMEM = 12345;

/* float */
float eeFooFloat EEMEM;

/* Byte-Feld */
uint8_t eeFooByteArray1[] EEMEM = { 18, 3 ,70 };
uint8_t eeFooByteArray2[] EEMEM = { 30, 7 ,79 };

/* 16-bit unsigned short feld */
uint16_t eeFooWordArray1[4] EEMEM;
//...
</c>

=== Bytes lesen/schreiben ===

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:

<c>
//...
uint8_t myByte;

myByte = eeprom_read_byte(&eeFooByte); // lesen
// myByte hat nun den Wert 123
//...
myByte = 99;
eeprom_write_byte(&eeFooByte, myByte); // schreiben
// der Wert 99 wird im EEPROM an die Adresse der
// 'Variablen' eeFooByte geschrieben
//...
myByte = eeprom_read_byte(&eeFooByteArray1[1]);
// myByte hat nun den Wert 3
//...

// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"
// (z.B. wenn die .eep-Datei nach Programmierung einer neuen Version
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE
// deaktiviert ist (unprogrammed/1)
//
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.

#define EEPROM_DEF 0xFF
uint8_t fooByteDefault = 222;
if ( ( myByte = eeprom_read_byte(&eeFooByte) ) == EEPROM_DEF ) {
myByte = fooByteDefault;
}

</c>

=== Wort lesen/schreiben ===

Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:

<c>
//...
uint16_t myWord;

myWord = eeprom_read_word(&eeFooWord); // lesen
// myWord hat nun den Wert 12345
//...
myWord = 2222;
eeprom_write_word(&eeFooWord, myWord); // schreiben
//...
</c>

=== Block lesen/schreiben ===

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).

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.

<c>
//...
uint8_t myByteBuffer[3];
uint16_t myWordBuffer[4];

/* Datenblock aus EEPROM LESEN */

/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse
in das RAM-Array myByteBuffer */
eeprom_read_block(myByteBuffer,eeFooByteArray1,3);

/* dito etwas anschaulicher aber "unnütze Tipparbeit": */
eeprom_read_block(&myByteBuffer[0],&eeFooByteArray[0],3);

/* dito mit etwas Absicherung betr. der Länge */
eeprom_read_block(myByteBuffer,eeFooByteArray1,sizeof(myByteBuffer));

/* und nun mit "16bit" */
eeprom_read_block(myWordBuffer,eeFooWordArray1,sizeof(myWordBuffer));

/* Datenlock in EEPROM SCHREIBEN */
eeprom_write_block(eeFooByteArray1,myByteBuffer,sizeof(myByteBuffer));
eeprom_write_block(eeFooWordArray1,myWordBuffer,sizeof(myWordBuffer));
//...
</c>

"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.

<c>
//...
float myFloat = 12.34;

union {
float r;
uint8_t i[sizeof(float)];
} u;

u.r = myFloat;

/* float in EEPROM */
eeprom_write_block(&eeFooFloat,&(u.i),sizeof(float));

/* float aus EEPROM */
eeprom_read_block(&(u.i),&eeFooFloat,sizeof(float));
/* u.r wieder 12.34 */
//...
</c>

Auch zusammengesetzte Typen lassen sich mit den Block-Routinen verarbeiten.

<c>
//...
typedef struct {
uint8_t label[8];
uint8_t rom_code[8];
} tMyStruct;

#define MAXSENSORS 3
tMyStruct eeMyStruct[MAXSENSORS] EEMEM;

//...

void egal(void)
{
tMyStruct work;

strcpy(work.label,"Flur");
GetRomCode(work.rom_code); // Dummy zur Veranschaulichung - setzt rom-code

/* Sichern von "work" im EEPROM */
eeprom_write_block(&eeMyStruct[0],&work,sizeof(tMyStruct)); // f. Index 0
strcpy(work.label,"Bad");
GetRomCode(work.rom_code);
eeprom_write_block(&eeMyStruct[1],&work,sizeof(tMyStruct)); // f. Index 1
//...
/* Lesen der Daten EEPROM Index 0 in "work" */
eeprom_read_block(&work,&eeMyStruct[0],sizeof(tMyStruct));
// work.label hat nun den Inhalt "Flur"
//...
}
//...
</c>

=== EEPROM-Speicherabbild in .eep-Datei ===

Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklaration abgeleiteten 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.



=== EEPROM-Variable auf feste Adressen legen ===

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
der EEPROM-Variablen durch den Compiler etwas in den Griff bekommen kann.

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.

Im folgenden nun zwei Sourcelistings mit einem Beispiel:

<c>
/////////////////////////////////////////////////
// Datei "eeprom.h" eines eigenen Projektes
/////////////////////////////////////////////////

#inlcude <avr/eeprom.h> // Die EEPROM-Definitionen/Macros der avr-libc einbinden

#define EESIZE 512 // Maximale Größe des EEPROMS

#define EE_DUMMY 0x000 // Dummyelement (Adresse 0 sollte nicht genutzt werden)
#define EE_VALUE1 0x001 // Eine Bytevariable
#define EE_WORD1L 0x002 // Eine Wordvariable (Lowbyte)
#define EE_WORD1H 0x003 // Eine Wordvariable (Highbyte)
#define EE_VALUE2 0x004 // Eine weitere Bytevariable
</c>

Mit den Macros '''#define EE_VALUE1''' legt man den Namen und die Adresse der
'Variablen' fest.

<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.

<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.

<c>
/////////////////////////////////////////////////
// Datei "eeprom.c" eines eigenen Projektes
/////////////////////////////////////////////////

#include "eeprom.h" // Eigene EEPROM-Headerdatei einbinden

uint8_t ee_mem[EESIZE] EEMEM =
{
[EE_DUMMY] = 0x00,
[EE_VALUE1] = 0x05,
[EE_WORD1L] = 0x01,
[EE_WORD1H] = 0x00,
[EE_VALUE2] = 0xFF
};

</c>

Durch die Verwendung eines Array, welches das gesammte EEPROM umfasst, bleibt
dem Compiler nicht anderes übrig, als das Array so zu platzieren, dass Element 0
des Arrays der Adresse 0 des EEPROMs entspricht. (''Ich hoffe nur, dass die Compilerbauer daran nichts ändern!'')

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
definiert werden. Benötigt man keine Initialisierung durch das Programm (was der Normalfall sein dürfte), dann kann man das auch so machen:

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:

<c>
#define EE_DUMMY 0x000
#define EE_WERT ( 0x000 + sizeof( uint8_t ) )
#define EE_ANZAHL ( EE_WERT + sizeof( uint8_t ) )
#define EE_NAME ( EE_ANZAHL + sizeof( uint16_t ) )
#define EE_WERTIGKEIT ( EE_NAME + 10 * sizeof( uint8_t ) )
#define EE_LAST ( EE_WERTIGKEIT + sizeof( uint8_t ) )
</c>

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
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.

<c>
#define EE_DUMMY 0x000
#define EE_WERT ( 0x000 + sizeof( uint8_t ) )
#define EE_ANZAHL ( EE_WERT + sizeof( uint8_t ) )
#define EE_NAME ( EE_ANZAHL + sizeof( uint16_t ) )
#define EE_WERTIGKEIT ( EE_NAME + 10 * sizeof( uint8_t ) )
#define EE_PROZENT ( EE_WERTIGKEIT + sizeof( uint8_t ) )
#define EE_LAST ( EE_WERTIGKEIT + sizeof( double ) )
</c>

EE_PROZENT legt die Startadresse für eine neue 'Variable' des Datentyps double fest.

Der Zugriff auf die EEPROM Werte kann dann z.B.so erfolgen:
<c>
uint8_t temp1;
uint16_t temp2;

temp1 = eeprom_read_byte(EE_VALUE1);
temp2 = eeprom_read_word(EE_WORD1L);
</c>

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
bauen, welche die spezifischen Anforderungen (Interrupt - Atom Problem, etc.)
erfüllen.

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
auf beliebige Adressen zu legen oder Adressen zu ändern. Die Andere Möglichkeit besteht darin, die EEPROM-Werte wie folgt zu belegen:

<c>
/////////////////////////////////////////////////
// Datei "eeprom.c" eines eigenen Projektes
/////////////////////////////////////////////////

#include "eeprom.h" // Eigene EEPROM-Headerdatei einbinden

uint8_t ee_mem[EESIZE] EEMEM =
{
0x00, // ee_dummy
0x05, // ee_value1
0x01, // ee_word1L
0x00, // (ee_word1H)
0xFF // ee_value2
};
</c>

Hierbei kann man Variablen, die größer sind als 1 Byte einfacher definieren und
man muss nur die Highbyte- oder Lowbyte-Adresse in der "eeprom.h" definieren.
Allerdings muss man hier höllisch aufpassen, dass man nicht um eine oder mehrere
Positionen verrutscht!

Welche der beiden Möglichkeiten man einsetzt, hängt vor allem davon ab, wieviele
Byte, Word und sonstige Variablen man benutzt. Gewöhnen sollte man sich an beide Varianten können ;)

Kleine Schlussbemerkung:

* Der avr-gcc unterstützt die Variante 1 und die Variante 2
* Der icc-avr Compiler unterstützt nur die Variante 2!

=== Bekannte Probleme bei den EEPROM-Funktionen ===

Vorsicht: Bei alten Versionen der avr-libc wurden nicht alle AVR Controller untersü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.

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).

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/EEPROM handling

=== EEPROM Register ===
Um das EEPROM anzusteuern sind drei Register von Bedeutung.<BR>
<LI> 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><BR>
<LI> EEDR Hier werden die Daten eingetragen die geschrieben werden sollen bzw. es enthält die gelesenen Daten
<BR><BR>
<LI> 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>

<TABLE BORDER=1>
<TR>
<TD>Bit</TD>
<TD> </TD>
<TD>     7     </TD>
<TD>     6     </TD>
<TD>     5     </TD>
<TD>     4     </TD>
<TD>     3     </TD>
<TD>     2     </TD>
<TD>     1     </TD>
<TD>     0     </TD>
</TR>
<TR>
<TD>Name</TD>
<TD> </TD>
<TD>-</TD>
<TD>-</TD>
<TD>-</TD>
<TD>-</TD>
<TD>EERIE</TD>
<TD>EEMWE</TD>
<TD>EEWE</TD>
<TD>EERE</TD>
</TR>
<TR>
<TD>Read/Write</TD>
<TD></TD>
<TD>R</TD>
<TD>R</TD>
<TD>R</TD>
<TD>R</TD>
<TD>R/W</TD>
<TD>R/W</TD>
<TD>R/W</TD>
<TD>R/W</TD>
</TR>
<TR>
<TD>Init Value</TD>
<TD></TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
</TR>

</TABLE>
<BR><BR>

<U>Bedeutung der Bits:</U><BR>
Bit 4-7 nicht belegt.<BR><BR>

<U>Bit 3 (EERIE) - EEPROM Ready Interrupt Enable:</U> 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>

<U>Bit 2(EEMWE) - EEPROM Master Write Enable:</U> 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>

<U>Bit 1 (EEWE) - EEPROM Write Enable:</U> 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. <BR>
Ein Schreibvorgang sieht typischerweise wie folgt aus:<BR>
1. EEPROM Bereitschaft abwarten (EEWE=0)
2. Adresse übergeben an EEAR<BR>
3. Daten übergeben an EEDR<BR>
4. Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1 <BR>
5. (Optinal) Warten bis Schreibvorgang abgeschlossen ist.<BR>
<BR><BR>
<U>Bit 0 EERE – EEPROM Read Enable:</U> 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.<BR>
Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<BR>
1. Bereitschaft zum lesen prüfen (EEWE=0)<BR>
2. Adresse übergeben an EEAR<BR>
3. Lesezyklus auslösen mit EERE = 1<BR>
4. Warten bis Lesevorgang abgeschlossen EERE = 0<BR>
5. Daten abholen aus EEDR<BR>
<BR><BR>

= Die Nutzung von printf =

Um komfortabel Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bietet sich printf/sprintf an.
<c>
#include <stdio.h>
#include <stdint.h>

// ...
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)
// ...

uint16_t counter;

void uart_puti( uint16_t value )
{
uint8_t s[20];

sprintf( s, "Zählerstand: %d", value );
uart_puts( s );
}

int main()
{
counter = 5;

uart_puti( counter );
uart_puti( 42 );
}
</c>

Eine weitere elegante Möglichkeit besteht darin, die Ausgabe stdout auf eigene Ausgabefunktionen umzuleiten. Dazu wird dem Ausgabemechanismus eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben (wie auch immer die Ausgabe stattfindet). Alle anderen, höheren, Funktionen greifen letztendlich auf diese eine Ausgabefunktion zurück, die die Ausgabe eines einzelnen Zeichens vornimmt.

<c>
#include <avr/io.h>
#include <stdio.h>

void uart_init(void);
int uart_putchar(char c, FILE *stream);

static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );

void uart_init(void)
{
/* hier µC spezifischen Code zur Initialisierung */
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */

// Beispiel:
//
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz
// 9600 Baud 8N1

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)

UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
}

int uart_putchar( char c, FILE *stream )
{
if( c == '\n' )
uart_putchar( '\r', stream );

loop_until_bit_is_set( UCSRA, UDRE );
UDR = c;
return 0;
}

int main(void)
{
uart_init();
stdout = &mystdout;
printf( "Hello, world!\n" );
return 0;
}

// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74
// + Ergänzungen
</c>

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.

Der Nachteil aller printf-Varianten: Sie sind recht speicherintensiv.

= Assembler und Inline-Assembler =

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.

Die "gnu-Toolchain" bietet dazu zwei Möglichkeiten:

* Inline-Assembler: Die Assembleranweisungen werden direkt in den C-Code integriert. Eine Quellcode-Datei enthält somit C- und Assembleranweisungen
* 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).

== Inline-Assembler ==

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.

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.

<c>
...
/* Verzögern der weiteren Programmausführung um
genau 3 Taktzyklen */
asm volatile ("nop");
asm volatile ("nop");
asm volatile ("nop");
...
</c>

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.

<c>
...
uint16_t i;

/* leere Schleife - wird bei eingeschalteter Compiler-Optimierung wegoptimiert */
for (i = 0; i < 1000; i++)
;

...

/* Schleife erzwingen (keine Optimierung): "NOP-Methode" */
for (i = 0; i < 1000; i++)
asm volatile("NOP");

...

/* alternative Methode (keine Optimierung): */
volatile uint16_t j;
for (j = 0; j < 1000; j++)
;
</c>

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).

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.

<c>
static inline void delayloop16 (uint16_t count)
{
asm volatile ("cp %A0, __zero_reg__ \n\t"
"cpc %B0, __zero_reg__ \n\t"
"breq 2f \n\t"
"1: \n\t"
"sbiw %0,1 \n\t"
"brne 1b \n\t"
"2: "
: "=w" (count)
: "0" (count)
);
}
</c>

* Jede Anweisung wird mit '''\n\t''' abgeschlossen. Der Zeilenumbruch teilt dem Assembler mit, dass ein neuer Befehl beginnt.
* 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 ausffindbaren Label.

Das Resultat zeigt ein Blick in die Assembler-Datei, die der Compiler mit der option <tt>-save-temps</tt> nicht löscht:

<avrasm>
cp r24, __zero_reg__ ; count
cpc r25, __zero_reg__ ; count
breq 2f
1:
sbiw r24,1 ; count
brne 1b
2:
</avrasm>

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].

Siehe auch:
* [http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf AVR Assembler-Anweisungsliste]
* [http://www.roboternetz.de/wissen/index.php/Inline-Assembler_in_avr-gcc Deutsche Einführung in Inline-Assembler]

== Assembler-Dateien ==

Assembler-Dateien erhalten die Endung .S (''grosses'' S) und werden im makefile nach WinAVR/mfile-Vorlage hinter ''ASRC='' durch Leerzeichen getrennt aufgelistet.

Wenn man mit dem AVR Studio arbeitet, kann alternativ auch das standardmäßig erstellte Makefile bearbeitet und folgende Zeilen eingefügt werden:

<div class="code"><pre>
## Objects that must be built in order to link
OBJECTS = (alte Dateien...) useful.o

## Compile
## Hier folgt eine Liste der gelinkten Dateien, darunter einfügen:
useful.o: ../useful.S
$(CC) $(INCLUDES) $(ASMFLAGS) -c $<

</pre></div>
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.

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.

Zuerst der Assembler-Code. Der Dateiname sei useful.S:

<avrasm>
#include "avr/io.h"

//; Arbeitsregister (ohne "r")
workreg = 16
workreg2 = 17

//; Konstante:
ALLOUT = 0xff

//; ** Setze alle Pins von PortD auf Ausgang **
//; keine Parameter, keine Rückgabe
.global superFunc
.func superFunc
superFunc:
push workreg
ldi workreg, ALLOUT
out _SFR_IO_ADDR(DDRD), workreg // beachte: _SFR_IO_ADDR()
pop workreg
ret
.endfunc

//; ** Setze PORTD auf übergebenen Wert **
//; Parameter in r24 (LSB immer bei "graden" Nummern)
.global ultraFunc
.func ultraFunc
ultraFunc:
out _SFR_IO_ADDR(PORTD), 24
ret
.endfunc

//; ** Zustand von PINA zurückgeben **
//; Rückgabewerte in r24:r25 (LSB:MSB), hier nur LSB genutzt
.global gigaFunc
.func gigaFunc
gigaFunc:
in 24, _SFR_IO_ADDR(PINA)
ret
.endfunc

//; ** Zwei Bytes addieren und 16-bit-Wort zurückgeben **
//; Parameter in r24 (Summand1) und r22 (Summand2) -
//; Parameter sind Word-"aligned" d.h. LSB immer auf "graden"
//; Registernummern. Bei 8-Bit und 16-Bit Paramtern somit
//; beginnend bei r24 dann r22 dann r20 etc.
//; Rückgabewert in r24:r25
.global addFunc
.func addFunc
addFunc:
push workreg
push workreg2
clr workreg2
mov workreg, 22
add workreg, 24
adc workreg2, 1 // r1 - assumed to be always zero ...
movw r24, workreg
pop workreg2
pop workreg
ret
.endfunc

//; oh je - sorry - Mein AVR-Assembler ist eingerostet, hoffe das stimmt so...

.end
</avrasm>

Im Makefile ist der Name der Assembler-Quellcodedatei einzutragen:

<div class="code"><pre>
ASRC = useful.S
</pre></div>

Der Aufruf erfolgt dann im C-Code so:

<c>
extern void superFunc(void);
extern void ultraFunc(uint8_t setVal);
extern uint8_t gigaFunc(void);
extern uint16_t addFunc(uint8_t w1, uint8_t w2);

int main(void)
{
[...]
superFunc();

ultraFunc(0x55);

PORTD = gigaFunc();

PORTA = (addFunc(0xF0, 0x11) & 0xff);
PORTB = (addFunc(0xF0, 0x11) >> 8);
[...]
}
</c>

Das Ergebnis wird wieder in der lss-Datei ersichtlich:

<div class="code"><pre>
[...]
superFunc();
148: 0e 94 f6 00 call 0x1ec

ultraFunc(0x55);
14c: 85 e5 ldi r24, 0x55 ; 85
14e: 0e 94 fb 00 call 0x1f6

PORTD = gigaFunc();
152: 0e 94 fd 00 call 0x1fa
156: 82 bb out 0x12, r24 ; 18

PORTA = (addFunc(0xF0, 0x11) & 0xff);
158: 61 e1 ldi r22, 0x11 ; 17
15a: 80 ef ldi r24, 0xF0 ; 240
15c: 0e 94 ff 00 call 0x1fe
160: 8b bb out 0x1b, r24 ; 27
PORTB = (addFunc(0xF0, 0x11) >> 8);
162: 61 e1 ldi r22, 0x11 ; 17
164: 80 ef ldi r24, 0xF0 ; 240
166: 0e 94 fc 00 call 0x1f8
16a: 89 2f mov r24, r25
16c: 99 27 eor r25, r25
16e: 88 bb out 0x18, r24 ; 24

[...]
000001ec <superFunc>:
// setze alle Pins von PortD auf Ausgang
.global superFunc
.func superFunc
superFunc:
push workreg
1ec: 0f 93 push r16
ldi workreg, ALLOUT
1ee: 0f ef ldi r16, 0xFF ; 255
out _SFR_IO_ADDR(DDRD), workreg
1f0: 01 bb out 0x11, r16 ; 17
pop workreg
1f2: 0f 91 pop r16
ret
1f4: 08 95 ret

000001f6 <ultraFunc>:
.endfunc

// setze PORTD auf übergebenen Wert
.global ultraFunc
.func ultraFunc
ultraFunc:
out _SFR_IO_ADDR(PORTD), 24
1f6: 82 bb out 0x12, r24 ; 18
ret
1f8: 08 95 ret

000001fa <gigaFunc>:
.endfunc

// Zustand von PINA zurückgeben
.global gigaFunc
.func gigaFunc
gigaFunc:
in 24, _SFR_IO_ADDR(PINA)
1fa: 89 b3 in r24, 0x19 ; 25
ret
1fc: 08 95 ret

000001fe <addFunc>:
.endfunc

// zwei Bytes addieren und 16-bit-Wort zurückgeben
.global addFunc
.func addFunc
addFunc:
push workreg
1fe: 0f 93 push r16
push workreg2
200: 1f 93 push r17
clr workreg2
202: 11 27 eor r17, r17
mov workreg, 22
204: 06 2f mov r16, r22
add workreg, 24
206: 08 0f add r16, r24
adc workreg2, 1 // r1 - assumed to be always zero ...
208: 11 1d adc r17, r1
movw r24, workreg
20a: c8 01 movw r24, r16
pop workreg2
20c: 1f 91 pop r17
pop workreg
20e: 0f 91 pop r16
ret
210: 08 95 ret

[...]
</pre></div>

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.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/assembler.html avr-libc-Dokumentation: Related Pages/avr-libc and assembler programs]
* [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?"]

== Globale Variablen für Datenaustausch ==

Oftmals kommt man um globale Variablen nicht herum, z.B. um den Datenaustausch zwischen Hauptprogramm und Interrupt-Routinen zu realisieren.
Hierzu muss man im Assembler wissen, wo genau die Variable vom C-Compiler abgespeichert wird.

Hierzu muss die Variable, hier "zaehler" genannt, zuerst im C-Code als Global definiert werden, z.B. so:

<c>
#include <avr/io.h>

volatile uint8_t zaehler;

int16_t main (void)
{
// irgendein Code, in dem zaehler benutzt werden kann

}
</c>

Im foldenden 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.

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).

<avrasm>
#include "avr/io.h"

temp = 16

.extern zaehler

.global INT0_vect
INT0_vect:

push temp //; wichtig: Benutzte Register und das
in temp,_SFR_IO_ADDR(SREG) //; Status-Register (SREG) sichern!
push temp

lds temp,zaehler //; Wert aus dem Speicher lesen
inc temp //; bearbeiten
sts zaehler,temp //; und wieder zurückschreiben

pop temp //; die benutzten Register wiederherstellen
out _SFR_IO_ADDR(SREG),temp
pop temp
reti

.end
</avrasm>

=== Globale Variablen im Assemblerfile anlegen ===

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.

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.

'''zaehl_asm.S'''
<avrasm>
#include "avr/io.h"

temp = 16

//; 1 Byte im RAM für den Zähler reservieren
.comm zaehler, 1

.global INT0_vect
INT0_vect:

...
</avrasm>

In der Headerdatei wird dann auf die Variable nur noch verwiesen (Schlüsselwort ''extern''):

'''zaehl_asm.h'''
<c>
#ifndef ZAEHL_ASM_H
#define ZAEHL_ASM_H

extern volatile uint8_t zaehler;

#endif
</c>

Im Gegensatz zu globalen Variablen in C werden so angelegte Variablen nicht automatisch mit dem Wert 0 initialisiert.

=== Variablen größer als 1 Byte ===

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:

<avrasm>
...
// 4 Byte im RAM für den Zähler reservieren
.comm zaehler, 4
...
</avrasm>

Die dazugehörige Deklaration im Headerfile wäre dann:
<c>
...
extern volatile uint32_t zaehler;
...
</c>

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:

<avrasm>
#include "avr/io.h"

temp = 16

// 4 Byte im RAM für den Zähler reservieren
.comm zaehler, 4

.global INT0_vect
INT0_vect:

push temp // wichtig: Benutzte Register und das
in temp,_SFR_IO_ADDR(SREG) // Status-Register (SREG) sichern !
push temp

// 32-Bit-Zähler incrementieren
lds temp, (zaehler + 0) // 0. Byte (niederwertigstes Byte)
inc temp
sts (zaehler + 0), temp
brne RAUS

lds temp, (zaehler + 1) // 1. Byte
inc temp
sts (zaehler + 1), temp
brne RAUS

lds temp, (zaehler + 2) // 2. Byte
inc temp
sts (zaehler + 2), temp
brne RAUS

lds temp, (zaehler + 3) // 3. Byte (höchstwertigstes Byte)
inc temp
sts (zaehler + 3), temp
brne RAUS

RAUS:
pop temp // die benutzten Register wiederherstellen
out _SFR_IO_ADDR(SREG),temp
pop temp
reti

.end
</avrasm>

'''TODO:''' 16-Bit / 32-Bit Variablen, Zugriff auf Arrays (Strings)

= Anhang =

== Besonderheiten bei der Anpassung bestehenden Quellcodes ==

Einige Funktionen, die in frühren Versionen der avr-libc vorhanden waren, 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.

=== Veraltete Funktionen zur Deklaration von Interrupt-Routinen ===

Die Funktionen (eigentlich Makros) ''SIGNAL'' und ''INTERRUPT'' zur Deklaration von Interruptroutinen sollten nicht mehr genutzt werden.

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:

* #include von avr/signal.h entfernen
* SIGNAL duch ISR ersetzen
* Name des Interrupt-Vektors anpassen (SIG_* durch entsprechendes *_vect)

Als Beispiel für die Anpassung zuerst ein "alter" Code:

<c>
#include <avr/interrupt.h>
#include <avr/signal.h>

...

/* Timer2 Output Compare bei einem ATmega8 */
SIGNAL(SIG_OUTPUT_COMPARE2)
{
...
}
</c>

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.

Der neue Code sieht dann so aus:

<c>
#include <avr/interrupt.h>
/* signal.h entfällt */

ISR(TIMER2_COMP_vect)
{
...
}
</c>

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.

<c>
...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */
/* avr/iom8.h - definitions for ATmega8 */

...

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)
...
</c>



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:

<c>
void XXX_vect(void) __attribute__((interrupt));
void XXX_vect(void) {
...
}
</c>

Beispiel:

<c>
/* ** alt ** */
#include <avr/io.h>
#include <avr/interrupt.h>

//...

INTERRUPT(SIG_OVERFLOW0)
{
...
}

/* ** neu: ** */
#include <avr/io.h>

//...

void TIMER0_OVF_vect(void) __attribute__((interrupt));
void TIMER0_OVF_vect(void)
{
...
}
</c>

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.

=== Veraltete Funktionen zum Portzugriff ===

''inp'' und ''outp'' zum Einlesen bzw. Schreiben von Registern sind nicht mehr erforderlich, der Compiler unterstützt dies ohne diesen Umweg.

<c>
unsigned char i, j;

// alt:
i = inp(PINA);
j = 0xff;
outp(PORTB, j);

// neu (nicht mehr wirklich neu...):
i = PINA
j = 0xff;
PORTB = j;
</c>

Will oder kann man den Code nicht portieren, ist zur weiteren Verwendung von inp und outp die Header-Datei '''compat/deprecated.h''' einzubinden.

=== Veraltete Funktionen zum Zugriff auf Bits in Registern ===

''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.

<c>
// alt:
sbi(PORTB, PB2);
cbi(PORTC, PC1);

// neu (auch nicht mehr wirklich neu...):
PORTB |= (1<<PB2);
PORTC &= ~(1<<PC1);
</c>

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:

<c>
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))
#define TOGGLE_BIT(PORT, BITNUM) ((PORT) ^= (1<<(BITNUM)))
</c>

=== Selbstdefinierte (nicht-standardisierte) ganzzahlige Datentypen ===

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.

<c>
typedef unsigned char BYTE; // besser: uint8_t aus <stdint.h>
typedef unsigned short WORD; // besser: uint16_t aus <stdint.h>
typedef unsigned long DWORD; // besser: uint32_t aus <stdint.h>
typedef unsigned long long QWORD; // besser: uint64_t aus <stdint.h>
</c>

; BYTE : Der Datentyp BYTE definiert eine Variable mit 8 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 255.

; WORD : Der Datentyp WORD definiert eine Variable mit 16 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 65535.

; DWORD : Der Datentyp DWORD (gesprochen: Double-Word) definiert eine Variable mit 32 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 4294967295.

; QWORD : Der Datentyp QWORD (gesprochen: Quad-Word) definiert eine Variable mit 64 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 18446744073709551615.

== Zusätzliche Funktionen im Makefile ==

=== Bibliotheken (Libraries/.a-Dateien) hinzufügen ===

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.

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).

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.

Beispiele:

<div class="code"><pre>
# Einbinden von Funktionen aus einer Library efsl (Dateiname libefsl.a)
LDFLAGS += -lefsl
# Einbinden von Funktionen aus einer Library xyz (Dateiname libxyz.a)
LDFLAGS += -lxyz
</pre></div>

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.)

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:

<div class="code"><pre>
superapp2
|
+----- efslsource (darin libefsl.a)
|
+----- xyzsource (darin libxyz.a)
|
+----- firmware (darin Anwendungs-Quellcode und Makefile)
</pre></div>

Daraus folgt, dass im Makefile die Verzeichnis efslsource und xyzsource in den Library-Suchpfad aufzunehmen sind:

<div class="code"><pre>
LDFLAGS += -L../efslsource/ -L../xyzsource/
</pre></div>

=== Fuse-Bits ===

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.

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):

<c>
#---------------- Programming Options (avrdude) ----------------

#...
#Beispiel! f. ATmega16 - nicht einfach uebernehmen! Zahlenwerte anhand
#--------- des Datenblatts nachvollziehen und gegebenenfalls aendern.
#
AVRDUDE_WRITE_LFUSE = -U lfuse:w:0xff:m
AVRDUDE_WRITE_HFUSE = -U hfuse:w:0xd8:m
AVRDUDE_WRITE_LOCK = -U lock:w:0x2f:m
#...
</c>

Damit diese Variablen auch genutzt werden, ist der Aufruf von avrdude im Makefile entsprechend zu ergänzen:

<c>
# Program the device.
program: $(TARGET).hex $(TARGET).eep
# ohne Fuse-/Lock-Einstellungen (nach WinAVR Vorlage Stand 4/2006)
# $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) \
# $(AVRDUDE_WRITE_EEPROM)
# mit Fuse-/Lock-Einstellungen
$(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_LFUSE) \
$(AVRDUDE_WRITE_HFUSE) $(AVRDUDE_WRITE_FLASH) \
$(AVRDUDE_WRITE_EEPROM) $(AVRDUDE_WRITE_LOCK)
</c>

Eine weiter 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:

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.

<c>
// tiny 2313 fuses low byte
#define CKDIV8 7
#define CKOUT 6
#define SUT1 5
#define SUT0 4
#define CKSEL3 3
#define CKSEL2 2
#define CKSEL1 1
#define CKSEL0 0

// tiny2313 fuses high byte
#define DWEN 7
#define EESAVE 6
#define SPIEN 5
#define WDTON 4
#define BODLEVEL2 3
#define BODLEVEL1 2
#define BODLEVEL0 1
#define RSTDISBL 0

// tiny2313 fuses extended byte
#define SELFPRGEN 0

#define LFUSE __attribute__ ((section ("lfuses")))
#define HFUSE __attribute__ ((section ("hfuses")))
#define EFUSE __attribute__ ((section ("efuses")))

// select ext crystal 3-8Mhz
unsigned char lfuse LFUSE =
( (1<<CKDIV8) | (1<<CKOUT) | (1<<CKSEL3) | (1<<CKSEL2) |
(0<<CKSEL1) | (1<<CKSEL0) | (0<<SUT1) | (1<<SUT0) );
unsigned char hfuse HFUSE =
( (1<<DWEN) | (1<<EESAVE) | (0<<SPIEN) | (1<<WDTON) |
(1<<BODLEVEL2) | (1<<BODLEVEL1) | (0<<BODLEVEL0) | (1<<RSTDISBL) );
unsigned char efuse EFUSE =
((0<<SELFPRGEN));
</c>

'''ACHTUNG: Die Bitpositionen wurden nicht vollständig getestet!'''

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).

Das Makefile muss nun noch um folgende Targets erweitert werden (mit Tabulator einrücken - nicht mit Leerzeichen):

<div class="code"><pre>
lfuses: build
-$(OBJCOPY) -j lfuses --change-section-address lfuses=0 \
-O ihex $(TARGET).elf $(TARGET)-lfuse.hex
@if [ -f $(TARGET)-lfuse.hex ]; then \
$(AVRDUDE) $(AVRDUDE_FLAGS) -U lfuse:w:$(TARGET)-lfuse.hex; \
fi;

hfuses: build
-$(OBJCOPY) -j hfuses --change-section-address hfuses=0 \
-O ihex $(TARGET).elf $(TARGET)-hfuse.hex
@if [ -f $(TARGET)-hfuse.hex ]; then \
$(AVRDUDE) $(AVRDUDE_FLAGS) -U hfuse:w:$(TARGET)-hfuse.hex; \
fi;

efuses: build
-$(OBJCOPY) -j efuses --change-section-address efuses=0 \
-O ihex $(TARGET).elf $(TARGET)-efuse.hex
@if [ -f $(TARGET)-efuse.hex ]; then \
$(AVRDUDE) $(AVRDUDE_FLAGS) -U efuse:w:$(TARGET)-efuse.hex;
fi;
</pre></div>

Das Target "clean" muss noch um die Zeilen
<div class="code"><pre>
$(REMOVE) $(TARGET)-lfuse.hex
$(REMOVE) $(TARGET)-hfuse.hex
$(REMOVE) $(TARGET)-efuse.hex
</pre></div>
erweitert werden, wenn auch die Fuse-Dateien gelöscht werden sollen.

Um nun die Fusebits des angeschlossenen Controllers zu programmieren muss lediglichein "make lfuses", "make hfuses" oder "make efuses" gestartet werden.
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 ;-)

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.

Siehe auch: [[AVR_Fuses#Vergleich_der_Fuses_bei_verschiedenen_Programmen|Vergleich der Fuses bei verschiedenen Programmen]]

== Externe Referenzspannung des internen Analog-Digital-Wandlers ==

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.

Meiner  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.

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.)

= TODO =
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR
* stdio.h, malloc()
* Code-Optimierungen ("tricks"), siehe auch Application Note [http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf AVR035: Efficient C Coding for AVR]
* "naked"-Funktionen
* SPI siehe [http://www.uni-koblenz.de/~physik/informatik/MCU/SPI.pdf SPI Bus mit Atmel AVR]
* I²C / TWI Bus [http://www.roboternetz.de/wissen/index.php/TWI]
* Bootloader (bez. auf boot.h)
* CAN-Bus
* Einsatz von einfachen Betriebssystemen auf dem AVR
* Übersicht zu den C bzw. GCC-predefined Makros (__DATE__, __TIME__,...)
[[Category:AVR]]
* ADC ;
* Timer
* USB ; Steuerung mit USB
* Multiplexen Siebensegment
* Sichere vs. effiziente Serialisierung von Datentypen
* Zustandsautomaten

RFM12 Protokoll Stack

2008-11-23T16:34:45Z

Thymythos: /* Media Access Control (MAC) */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate (Vorschlag: feste Kanal-Baudraten-Zuordnung)
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.
# Die maximale Paketlänge beträgt 50ms. Die maximale Anzahl Bytes hängt daher von der Baudrate ab.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#9fffa8" | ''n Byte Daten''
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16 || bgcolor="#9fffa8" | 0 - 8*n || bgcolor="#9fffa8" | 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (7-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

;Version
:Das Versionsfeld gibt die verwendete Version an (aktuell ist Version 1 = 0b00).
:Wenn die Version nicht unterstützt ist, wird der Empfang abgebrochen.

;Adressierung
:Broadcast (0xff) an alle Geräte (immer ohne ACK)
:127 Multicast-Gruppen (0x80 - 0xfe)
:128 Geräteadressen (0x00 - 0x7f) (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau ''(Version 1)''
|-
!
! Version
! need ACK
! is ACK
! TypeID
! Empfänger
! Sender
! ''0-m Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 2 || 1 || 1 || 4 || 8 || 8 || 0 - 8*m || 8
|-
! Bits (nach FEC)
| 4 || 2 || 2 || 8 || 16 || 16 || 0 - 16*m || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll:

* Muss immer implementiert sein
* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth
* Unterscheidung Request / Response

{| border="1" cellspacing="0" cellpadding="5"
|+ Nachrichten
|-
! ID || Request || Response
|-
| 0x00 || Device Discovery || Device Information
|-
| 0x01 || Available Layer 3 Protos || Protocol Information
|}



=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:right;"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|-
! Baudrate
| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k ||115.2k || 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k
|}

In der EU sind nur die Kanäle 4-7 möglich. Alle anderen Frequenzen stören andere Funkdienste und können zu nicht unerheblichen Bußgeldern und Kosten für Messeinsätze führen. '''Achtung: die Module dürfen auf den anderen Kanälen nur von Personen mit Amateurfunkgenehmigung betrieben werden!'''

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-23T15:10:17Z

Thymythos: /* Logical Link Control (LLC) */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate (Vorschlag: feste Kanal-Baudraten-Zuordnung)
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.
# Die maximale Paketlänge beträgt 50ms. Die maximale Anzahl Bytes hängt daher von der Baudrate ab.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 8*n || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (7-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

;Version
:Das Versionsfeld gibt die verwendete Version an (aktuell ist Version 1 = 0b00).
:Wenn die Version nicht unterstützt ist, wird der Empfang abgebrochen.

;Adressierung
:Broadcast (0xff) an alle Geräte (immer ohne ACK)
:127 Multicast-Gruppen (0x80 - 0xfe)
:128 Geräteadressen (0x00 - 0x7f) (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau ''(Version 1)''
|-
!
! Version
! need ACK
! is ACK
! TypeID
! Empfänger
! Sender
! ''0-m Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 2 || 1 || 1 || 4 || 8 || 8 || 0 - 8*m || 8
|-
! Bits (nach FEC)
| 4 || 2 || 2 || 8 || 16 || 16 || 0 - 16*m || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll:

* Muss immer implementiert sein
* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth
* Unterscheidung Request / Response

{| border="1" cellspacing="0" cellpadding="5"
|+ Nachrichten
|-
! ID || Request || Response
|-
| 0x00 || Device Discovery || Device Information
|-
| 0x01 || Available Layer 3 Protos || Protocol Information
|}



=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:right;"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|-
! Baudrate
| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k ||115.2k || 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-23T14:51:15Z

Thymythos: /* Logical Link Control (LLC) */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate (Vorschlag: feste Kanal-Baudraten-Zuordnung)
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.
# Die maximale Paketlänge beträgt 50ms. Die maximale Anzahl Bytes hängt daher von der Baudrate ab.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 8*n || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (7-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

;Adressierung
:Broadcast (0xff) an alle Geräte (immer ohne ACK)
:127 Multicast-Gruppen (0x80 - 0xfe)
:128 Geräteadressen (0x00 - 0x7f) (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll:

* Muss immer implementiert sein
* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth
* Unterscheidung Request / Response

{| border="1" cellspacing="0" cellpadding="5"
|+ Nachrichten
|-
! ID || Request || Response
|-
| 0x00 || Device Discovery || Device Information
|-
| 0x01 || Available Layer 3 Protos || Protocol Information
|}



=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:right;"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|-
! Baudrate
| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k ||115.2k || 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-23T14:43:02Z

Thymythos: /* Media Access Control (MAC) */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate (Vorschlag: feste Kanal-Baudraten-Zuordnung)
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.
# Die maximale Paketlänge beträgt 50ms. Die maximale Anzahl Bytes hängt daher von der Baudrate ab.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 8*n || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll:

* Muss immer implementiert sein
* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth
* Unterscheidung Request / Response

{| border="1" cellspacing="0" cellpadding="5"
|+ Nachrichten
|-
! ID || Request || Response
|-
| 0x00 || Device Discovery || Device Information
|-
| 0x01 || Available Layer 3 Protos || Protocol Information
|}



=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:right;"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|-
! Baudrate
| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k ||115.2k || 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-23T14:42:30Z

Thymythos: /* Media Access Control (MAC) */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate (Vorschlag: feste Kanal-Baudraten-Zuordnung)
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.
# Die maximale Paketlänge beträgt 50ms. Die maximale Anzahl Bytes hängt daher von der Baudrate ab.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll:

* Muss immer implementiert sein
* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth
* Unterscheidung Request / Response

{| border="1" cellspacing="0" cellpadding="5"
|+ Nachrichten
|-
! ID || Request || Response
|-
| 0x00 || Device Discovery || Device Information
|-
| 0x01 || Available Layer 3 Protos || Protocol Information
|}



=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:right;"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|-
! Baudrate
| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k ||115.2k || 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-23T14:32:56Z

Thymythos: /* Typ 0: Management */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate (Vorschlag: feste Kanal-Baudraten-Zuordnung)
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll:

* Muss immer implementiert sein
* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth
* Unterscheidung Request / Response

{| border="1" cellspacing="0" cellpadding="5"
|+ Nachrichten
|-
! ID || Request || Response
|-
| 0x00 || Device Discovery || Device Information
|-
| 0x01 || Available Layer 3 Protos || Protocol Information
|}



=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:right;"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|-
! Baudrate
| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k ||115.2k || 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

AVR RFM12

2008-11-23T10:50:51Z

Thymythos: /* Hardware */ kompakter

Schaltungen und Software für AVR und das Funkmodul [[RFM12]].

== SVN ==

svn://mikrocontroller.net/rfm12

Wegen Zugangsdaten bitte bei [http://www.mikrocontroller.net/user/show/andreas Andreas Schwarz] melden.

----

== Software ==

=== Treiber ===

[http://www.mikrocontroller.net/attachment/22473/rfm12_pc.zip Firmware v1.0.0] von Benedikt K.

[http://www.mikrocontroller.net/attachment/23542/RMxx_Driver.tar.bz2 Firmware v2.0.1] von Jürgen Eckert

{| border="1" cellspacing="0"
|+ Funktionalität
|-
! || Beschreibung || Software
|-
!1. Stufe:
| Die Daten von der seriellen Schnittstelle werden über die Funkstrecke auf die serielle Schnittstelle der anderen Seite übertragen. (Wir freuen uns über jedes Byte das ankommt)
| [http://www.mikrocontroller.net/topic/67273#564945 Claude Schwarz], [http://www.mikrocontroller.net/topic/71682#584915 Benedikt K.] oder [http://www.mikrocontroller.net/attachment/36742/RFM12_V3.zip Manuel Stahl]
|-
! 2. Stufe:
| Es findet eine Fehlererkennung (z.B. mit CRC-Summen) statt. Fehlerhafte Daten werden erneut angefordert. Dadurch gehen auf der Funkstrecke keine Daten verloren und es werden keine Daten verfälscht.
| [http://www.mikrocontroller.net/topic/71682#585851 Benedikt K.]
|-
! 3. Stufe:
| Die Datenübertragung wird individualisiert. Dadurch können zwei Funkstrecken, die im gleichen Empfangsbereich liegen nebeneinander arbeiten, ohne sich zu beeinträchtigen.
| [[RFM12_Protokoll_Stack]]
|-
! 4. Stufe:
| Die Datenübertragung wird verschlüsselt und damit abhörsicher.
|
|-
!5. Stufe:
| Neben den Daten der seriellen Schnittstelle werden auch Änderungen der Statusleitungen übertragen. Damit erhält man eine "RS232-Verlängerung" über eine Funkstrecke, die fehlerfrei arbeitet und zu einer Drahtverbindung weitestgehend kompatibel ist.
|
|}

=== RS232 <-> RFM12 ===

TODO

=== USB <-> RFM12 ===

Mit '''[http://www.obdev.at/products/avrusb/index.html avrusb]''' lässt sich ein USB-Slave in Software emulieren.

* '''[http://www.recursion.jp/avrcdc/ AVR-CDC]''' läuft mit Anpassung der USB-Pins. ''(Zumindest unter Windows an einem USB2.0-Port)''

Adapter für '''[http://www.embedded-projects.net/?page_id=135 USBprog]:'''

* Funktionierender Code liegt im oben genannten SVN
* Implementiert die USB-CDC-Klasse (kein Treiber nötig)
* Sicherung der Übertragung durch Hamming-Code
* Work in progress... (Manuel Stahl)

----

== Hardware ==

=== Basismodul V1.0 ===

'''Prozessor'''

ATmega8 TQFP32 (kompatibel ATmega48, ATmega88, ATmega168)

'''Schnittstellen'''

* RS232
* I²C:
* USB
* GPIO

'''Platine'''

[[Bild:AVR RFM12 Schematic.png|200px|ATmega48 + USB]]
[[Bild:AVR RFM12 Board TOP.png|220px|2-lagig top]]
[[Bild:AVR RFM12 Board BOTTOM.png|240px|2-lagig bottom]]
[[Bild:AVR_RFM12_Photo.jpg|240px|Photo]]

<div style="float:left; border-right:1px solid gray; padding-right:10px;">
'''Bauteile:'''

Größe: SMD 0603

* R1, R2: 68R (nur USB)
* R3, R4: 10k
* R5: 1k5 (nur USB)
* C1, C2: 22pF
* C3 - C9: 100nF
* Q1: 12Mhz (nur USB)
* D1, D2: beliebig, Minimelf
* IC3: MAX3221CUE
</div>

<div style="float:left; border-right:1px solid gray; padding: 0px 0px 10px 10px; width:33%">
'''Kosten:'''

* MiniUSB SMD: '''1,25€'''
* HF-Buchse MMCX: '''4,25€'''
* ATmega48: '''2,85€'''
* MAX3221CUE: '''1,10€'''
* Quarz 12Mhz 30ppm: '''1,19€'''
* Kleinkram: '''< 1,10€'''

* habe ein verbindliches Angebot für 24 Stück von http://mme-pcb.de/: '''4,00€ pro Platine'''
</div>

<div style="float:left; padding: 0px 0px 10px 10px; width:33%">
''' Bugs / Erweiterungen:'''

* Der 1,5k Widerstand muss direkt an den VCC-Pin angelötet werden (Pad ist nicht verbunden)
* Beim Fertigen wurde das Polygon, welches das VCC-Signal durch die eine Ecke des ATmega48 leitet, unterbrochen. Hier hilft nur eine Drahtbrücke.
* Unter den RFM12 und unter das Quarz am Besten Isolierband kleben!
* Beim Programmieren sollte der SEL des RFM12 (J1 der zweite Pin vom RS232 aus) auf VCC gelegt werden
</div>
<div style="clear:both"></div>

[http://www.mikrocontroller.net/attachment/24012/RFM12.brd Board (Eagle)]:

[[Bild:AVR RFM12 Board top bestuecken.png|200px|top]]
[[Bild:Board bottom bestuecken.png|200px|bottom]]
----

=== Flashcraft Funkboard ===

[http://flashcraft.de/index.php/funkboard-uebersicht Homepage]

# SMA-Antennenanschluss
# Abmessungen:32x34mm, leichte Montage durch 2 Stiftleisten im 2,54mm Raster
# ATmega32 onBoard, übernimmt komplette Ansteuerung
# 3 Schnittstellen zur Ansteuerung sind vorgesehen: I2C, SPI, UART
# Geringe Stromaufnahme: 10mA im normalen Betrieb, 2 Schlafmodis mit Stromverbrauch bis min. 25µA!
# Betriebsspannungsbereich von 3,2 - 5,4V
# 5V oder 3V Spannungsregler onBoard! Direkter Batteriebetrieb möglich; Kann externe Schaltung versorgen!
# Über 50 Seiten starke Dokumentation
# Komplettes Projekt online verfügbar!
----

=== USBprogRFM12 ===

Da der USBprog genau das SPI-Interface des ATmega32 zur Verfügung stellt, eignet er sich perfekt als USB-RFM12-Adapter.

[[Bild:USBprogRFM12_schematic.png|200px|USBprogRFM12]] [[Bild:USBprogRFM12_board.png|200px|USBprogRFM12]]

[[Bild:USBprogRFM12.jpg|400px|USBprogRFM12]]

----

== Links ==

* [http://www.mikrocontroller.net/topic/65984 Allgemeine Diskussion]
* [http://www.mikrocontroller.net/topic/71682 bidirektionale RS232 Funkbrücke mit RFM12]
* [http://www.das-labor.org/wiki/Datenfunk_mit_dem_AVR Datenfunk mit dem AVR] bei das-labor.org

[[Kategorie:Projekte]]
[[Kategorie:AVR]]
[[Kategorie:Funk]]

AVR RFM12

2008-11-23T10:38:18Z

Thymythos: /* Flashcraft Funkboard */

Schaltungen und Software für AVR und das Funkmodul [[RFM12]].

== SVN ==

svn://mikrocontroller.net/rfm12

Wegen Zugangsdaten bitte bei [http://www.mikrocontroller.net/user/show/andreas Andreas Schwarz] melden.

----

== Software ==

=== Treiber ===

[http://www.mikrocontroller.net/attachment/22473/rfm12_pc.zip Firmware v1.0.0] von Benedikt K.

[http://www.mikrocontroller.net/attachment/23542/RMxx_Driver.tar.bz2 Firmware v2.0.1] von Jürgen Eckert

{| border="1" cellspacing="0"
|+ Funktionalität
|-
! || Beschreibung || Software
|-
!1. Stufe:
| Die Daten von der seriellen Schnittstelle werden über die Funkstrecke auf die serielle Schnittstelle der anderen Seite übertragen. (Wir freuen uns über jedes Byte das ankommt)
| [http://www.mikrocontroller.net/topic/67273#564945 Claude Schwarz], [http://www.mikrocontroller.net/topic/71682#584915 Benedikt K.] oder [http://www.mikrocontroller.net/attachment/36742/RFM12_V3.zip Manuel Stahl]
|-
! 2. Stufe:
| Es findet eine Fehlererkennung (z.B. mit CRC-Summen) statt. Fehlerhafte Daten werden erneut angefordert. Dadurch gehen auf der Funkstrecke keine Daten verloren und es werden keine Daten verfälscht.
| [http://www.mikrocontroller.net/topic/71682#585851 Benedikt K.]
|-
! 3. Stufe:
| Die Datenübertragung wird individualisiert. Dadurch können zwei Funkstrecken, die im gleichen Empfangsbereich liegen nebeneinander arbeiten, ohne sich zu beeinträchtigen.
| [[RFM12_Protokoll_Stack]]
|-
! 4. Stufe:
| Die Datenübertragung wird verschlüsselt und damit abhörsicher.
|
|-
!5. Stufe:
| Neben den Daten der seriellen Schnittstelle werden auch Änderungen der Statusleitungen übertragen. Damit erhält man eine "RS232-Verlängerung" über eine Funkstrecke, die fehlerfrei arbeitet und zu einer Drahtverbindung weitestgehend kompatibel ist.
|
|}

=== RS232 <-> RFM12 ===

TODO

=== USB <-> RFM12 ===

Mit '''[http://www.obdev.at/products/avrusb/index.html avrusb]''' lässt sich ein USB-Slave in Software emulieren.

* '''[http://www.recursion.jp/avrcdc/ AVR-CDC]''' läuft mit Anpassung der USB-Pins. ''(Zumindest unter Windows an einem USB2.0-Port)''

Adapter für '''[http://www.embedded-projects.net/?page_id=135 USBprog]:'''

* Funktionierender Code liegt im oben genannten SVN
* Implementiert die USB-CDC-Klasse (kein Treiber nötig)
* Sicherung der Übertragung durch Hamming-Code
* Work in progress... (Manuel Stahl)

----

== Hardware ==

=== Basismodul V1.0 ===

==== Prozessor ====

ATmega8 TQFP32 (kompatibel ATmega48, ATmega88, ATmega168)

==== Schnittstellen ====

* RS232
* I²C:
* USB
* GPIO

==== Platine ====

[[Bild:AVR RFM12 Schematic.png|200px|ATmega48 + USB]]
[[Bild:AVR RFM12 Board TOP.png|220px|2-lagig top]]
[[Bild:AVR RFM12 Board BOTTOM.png|240px|2-lagig bottom]]
[[Bild:AVR_RFM12_Photo.jpg|240px|Photo]]

'''Bauteile:'''

Größe: SMD 0603

* R1, R2: 68R (nur USB)
* R3, R4: 10k
* R5: 1k5 (nur USB)
* C1, C2: 22pF
* C3 - C9: 100nF
* Q1: 12Mhz (nur USB)
* D1, D2: beliebig, Minimelf
* IC3: MAX3221CUE

==== Bugs / Erweiterungen ====

* Der 1,5k Widerstand muss direkt an den VCC-Pin angelötet werden (Pad ist nicht verbunden)
* Beim Fertigen wurde das Polygon, welches das VCC-Signal durch die eine Ecke des ATmega48 leitet, unterbrochen. Hier hilft nur eine Drahtbrücke.
* Unter den RFM12 und unter das Quarz am Besten Isolierband kleben!
* Beim Programmieren sollte der SEL des RFM12 (J1 der zweite Pin vom RS232 aus) auf VCC gelegt werden

==== Fertigung ====

Kosten:

* MiniUSB SMD: '''1,25€'''
* HF-Buchse MMCX: '''4,25€'''
* ATmega48: '''2,85€'''
* MAX3221CUE: '''1,10€'''
* Quarz 12Mhz 30ppm: '''1,19€'''
* Kleinkram: '''< 1,10€'''

* habe ein verbindliches Angebot für 24 Stück von http://mme-pcb.de/: '''4,00€ pro Platine'''

[http://www.mikrocontroller.net/attachment/24012/RFM12.brd Board]:

[[Bild:Board bottom bestuecken.png|200px|bottom]]
[[Bild:AVR RFM12 Board top bestuecken.png|200px|top]]

=== Flashcraft Funkboard ===

[http://flashcraft.de/index.php/funkboard-uebersicht Homepage]

# SMA-Antennenanschluss
# Abmessungen:32x34mm, leichte Montage durch 2 Stiftleisten im 2,54mm Raster
# ATmega32 onBoard, übernimmt komplette Ansteuerung
# 3 Schnittstellen zur Ansteuerung sind vorgesehen: I2C, SPI, UART
# Geringe Stromaufnahme: 10mA im normalen Betrieb, 2 Schlafmodis mit Stromverbrauch bis min. 25µA!
# Betriebsspannungsbereich von 3,2 - 5,4V
# 5V oder 3V Spannungsregler onBoard! Direkter Batteriebetrieb möglich; Kann externe Schaltung versorgen!
# Über 50 Seiten starke Dokumentation
# Komplettes Projekt online verfügbar!

=== USBprogRFM12 ===

Da der USBprog genau das SPI-Interface des ATmega32 zur Verfügung stellt, eignet er sich perfekt als USB-RFM12-Adapter.

[[Bild:USBprogRFM12_schematic.png|200px|USBprogRFM12]] [[Bild:USBprogRFM12_board.png|200px|USBprogRFM12]]

[[Bild:USBprogRFM12.jpg|400px|USBprogRFM12]]

----

== Links ==

* [http://www.mikrocontroller.net/topic/65984 Allgemeine Diskussion]
* [http://www.mikrocontroller.net/topic/71682 bidirektionale RS232 Funkbrücke mit RFM12]
* [http://www.das-labor.org/wiki/Datenfunk_mit_dem_AVR Datenfunk mit dem AVR] bei das-labor.org

[[Kategorie:Projekte]]
[[Kategorie:AVR]]
[[Kategorie:Funk]]

AVR-GCC-Tutorial

2008-11-23T09:39:54Z

Thymythos: /* TODO */

AVR-GCC-Tutorial

2008-11-22T11:00:08Z

Thymythos: /* 16-Bit Portregister (ADC, ICR1, OCR1, TCNT1, UBRR) */ Fehler im Beispiel (keine Dereferenzierung)

AVR RFM12

2008-11-20T14:07:22Z

Thymythos: /* Platine */ Photo

Schaltungen und Software für AVR und das Funkmodul [[RFM12]].

== SVN ==

svn://mikrocontroller.net/rfm12

Wegen Zugangsdaten bitte bei [http://www.mikrocontroller.net/user/show/andreas Andreas Schwarz] melden.

----

== Software ==

=== Treiber ===

[http://www.mikrocontroller.net/attachment/22473/rfm12_pc.zip Firmware v1.0.0] von Benedikt K.

[http://www.mikrocontroller.net/attachment/23542/RMxx_Driver.tar.bz2 Firmware v2.0.1] von Jürgen Eckert

{| border="1" cellspacing="0"
|+ Funktionalität
|-
! || Beschreibung || Software
|-
!1. Stufe:
| Die Daten von der seriellen Schnittstelle werden über die Funkstrecke auf die serielle Schnittstelle der anderen Seite übertragen. (Wir freuen uns über jedes Byte das ankommt)
| [http://www.mikrocontroller.net/topic/67273#564945 Claude Schwarz], [http://www.mikrocontroller.net/topic/71682#584915 Benedikt K.] oder [http://www.mikrocontroller.net/attachment/36742/RFM12_V3.zip Manuel Stahl]
|-
! 2. Stufe:
| Es findet eine Fehlererkennung (z.B. mit CRC-Summen) statt. Fehlerhafte Daten werden erneut angefordert. Dadurch gehen auf der Funkstrecke keine Daten verloren und es werden keine Daten verfälscht.
| [http://www.mikrocontroller.net/topic/71682#585851 Benedikt K.]
|-
! 3. Stufe:
| Die Datenübertragung wird individualisiert. Dadurch können zwei Funkstrecken, die im gleichen Empfangsbereich liegen nebeneinander arbeiten, ohne sich zu beeinträchtigen.
| [[RFM12_Protokoll_Stack]]
|-
! 4. Stufe:
| Die Datenübertragung wird verschlüsselt und damit abhörsicher.
|
|-
!5. Stufe:
| Neben den Daten der seriellen Schnittstelle werden auch Änderungen der Statusleitungen übertragen. Damit erhält man eine "RS232-Verlängerung" über eine Funkstrecke, die fehlerfrei arbeitet und zu einer Drahtverbindung weitestgehend kompatibel ist.
|
|}

=== RS232 <-> RFM12 ===

TODO

=== USB <-> RFM12 ===

Mit '''[http://www.obdev.at/products/avrusb/index.html avrusb]''' lässt sich ein USB-Slave in Software emulieren.

* '''[http://www.recursion.jp/avrcdc/ AVR-CDC]''' läuft mit Anpassung der USB-Pins. ''(Zumindest unter Windows an einem USB2.0-Port)''

Adapter für '''[http://www.embedded-projects.net/?page_id=135 USBprog]:'''

* Funktionierender Code liegt im oben genannten SVN
* Implementiert die USB-CDC-Klasse (kein Treiber nötig)
* Sicherung der Übertragung durch Hamming-Code
* Work in progress... (Manuel Stahl)

----

== Hardware ==

=== Basismodul V1.0 ===

==== Prozessor ====

ATmega8 TQFP32 (kompatibel ATmega48, ATmega88, ATmega168)

==== Schnittstellen ====

* RS232
* I²C:
* USB
* GPIO

==== Platine ====

[[Bild:AVR RFM12 Schematic.png|200px|ATmega48 + USB]]
[[Bild:AVR RFM12 Board TOP.png|220px|2-lagig top]]
[[Bild:AVR RFM12 Board BOTTOM.png|240px|2-lagig bottom]]
[[Bild:AVR_RFM12_Photo.jpg|240px|Photo]]

'''Bauteile:'''

Größe: SMD 0603

* R1, R2: 68R (nur USB)
* R3, R4: 10k
* R5: 1k5 (nur USB)
* C1, C2: 22pF
* C3 - C9: 100nF
* Q1: 12Mhz (nur USB)
* D1, D2: beliebig, Minimelf
* IC3: MAX3221CUE

==== Bugs / Erweiterungen ====

* Der 1,5k Widerstand muss direkt an den VCC-Pin angelötet werden (Pad ist nicht verbunden)
* Beim Fertigen wurde das Polygon, welches das VCC-Signal durch die eine Ecke des ATmega48 leitet, unterbrochen. Hier hilft nur eine Drahtbrücke.
* Unter den RFM12 und unter das Quarz am Besten Isolierband kleben!
* Beim Programmieren sollte der SEL des RFM12 (J1 der zweite Pin vom RS232 aus) auf VCC gelegt werden

==== Fertigung ====

Kosten:

* MiniUSB SMD: '''1,25€'''
* HF-Buchse MMCX: '''4,25€'''
* ATmega48: '''2,85€'''
* MAX3221CUE: '''1,10€'''
* Quarz 12Mhz 30ppm: '''1,19€'''
* Kleinkram: '''< 1,10€'''

* habe ein verbindliches Angebot für 24 Stück von http://mme-pcb.de/: '''4,00€ pro Platine'''

[http://www.mikrocontroller.net/attachment/24012/RFM12.brd Board]:

[[Bild:Board bottom bestuecken.png|200px|bottom]]
[[Bild:AVR RFM12 Board top bestuecken.png|200px|top]]

=== USBprogRFM12 ===

Da der USBprog genau das SPI-Interface des ATmega32 zur Verfügung stellt, eignet er sich perfekt als USB-RFM12-Adapter.

[[Bild:USBprogRFM12_schematic.png|200px|USBprogRFM12]] [[Bild:USBprogRFM12_board.png|200px|USBprogRFM12]]

[[Bild:USBprogRFM12.jpg|400px|USBprogRFM12]]

----

== Links ==

* [http://www.mikrocontroller.net/topic/65984 Allgemeine Diskussion]
* [http://www.mikrocontroller.net/topic/71682 bidirektionale RS232 Funkbrücke mit RFM12]
* [http://www.das-labor.org/wiki/Datenfunk_mit_dem_AVR Datenfunk mit dem AVR] bei das-labor.org

[[Kategorie:Projekte]]
[[Kategorie:AVR]]
[[Kategorie:Funk]]

Datei:AVR RFM12 Photo.jpg

2008-11-20T14:06:31Z

Thymythos:

RFM12 Protokoll Stack

2008-11-18T21:59:04Z

Thymythos: /* Kanalzuordnung */ Baudrate

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate (Vorschlag: feste Kanal-Baudraten-Zuordnung)
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll: Beacons etc.

* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth

=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:right;"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|-
! Baudrate
| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k ||115.2k || 9.6k || 19.2k || 115.2k|| 9.6k || 19.2k || 115.2k|| 9.6k
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-18T21:53:19Z

Thymythos: /* Layer 1: Physical */ Baudrate

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate (Vorschlag: feste Kanal-Baudraten-Zuordnung)
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll: Beacons etc.

* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth

=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-18T09:04:15Z

Thymythos: /* Logical Link Control (LLC) */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).
:Die FEC sorgt außerdem dafür, dass genügend 0-1 Transitionen vorkommen. So kann der Empfänger den Takt auch bei langen Paketen besser halten.

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll: Beacons etc.

* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth

=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-18T08:51:48Z

Thymythos: /* Frames */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll: Beacons etc.

* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth

=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''0-28 Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-224
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12 Protokoll Stack

2008-11-18T08:50:39Z

Thymythos: /* Logical Link Control (LLC) */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''0-28 Byte Daten''
! CRC-8
|----
! Bits (vor FEC)
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-224 || 8
|-
! Bits (nach FEC)
| 16 || 16 || 2 || 2 || 2 || 2 || 8 || 0-448 || 16
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll: Beacons etc.

* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth

=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''n Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-480
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

NesC

2008-11-15T16:23:09Z

Thymythos: Die Seite wurde neu angelegt: NesC ist eine Auszeichnungssprache für C, ähnlich dem C-Präprozessor. Der nesC Compiler ''ncc'' erweitert die Toolchain und wird als erstes aufgerufen. Er erzeugt au...

NesC ist eine Auszeichnungssprache für C, ähnlich dem C-Präprozessor. Der nesC Compiler ''ncc'' erweitert die Toolchain und wird als erstes aufgerufen. Er erzeugt aus ''*.nc'' Dateien C-Quellcode.

NesC wird im Betriebssystem [http://www.tinyos.net TinyOS] verwendet.

'''Beispiel:''' TimerMilliP.nc
<c>
// $Id: TimerMilliP.nc,v 1.5 2008/06/11 00:46:27 razvanm Exp $
/*
* "Copyright (c) 2005 The Regents of the University of California.
* All rights reserved.
*
* Permission to use, copy, modify, and distribute this software and its
* documentation for any purpose, without fee, and without written agreement is
* hereby granted, provided that the above copyright notice, the following
* two paragraphs and the author appear in all copies of this software.
*
* IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
* DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT
* OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF
* CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
* ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO
* PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS."
*
*/
/**
* Components should never wire to this component. This is the
* underlying configuration of virtualized millisecond timers.
* It auto-wires wires the timer
* implementation (TimerC) to the boot sequence and exports the
* various Timer interfaces.
*
* @author Philip Levis
* @author Cory Sharp
* @date May 16 2005
*/

#include "Timer.h"

configuration TimerMilliP {
provides interface Timer<TMilli> as TimerMilli[uint8_t id];
}
implementation {
components HilTimerMilliC, MainC;
MainC.SoftwareInit -> HilTimerMilliC;
TimerMilli = HilTimerMilliC;
}
</c>

== Links ==

* Sourceforge: [http://sf.net/projects/nescc]

[[Kategorie:Programmiersprachen]]

RFM12 Protokoll Stack

2008-11-12T17:42:42Z

Thymythos: /* Layer 2: Data Link */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Hier noch ein paar Anregungen zur Verbesserung des MAC: [http://www.comsoc.org/livepubs/surveys/public/2q00issue/gummalla.html]

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''n Byte Daten''
! CRC-8
|----
! Bits
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-480 || 8
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll: Beacons etc.

* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth

=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''n Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-480
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

RFM12

2008-11-12T16:02:22Z

Thymythos: /* Kommunikation mit RFM funktioniert nur sporadisch */

Beschreibung der Funkmodule RFM01, RFM02 und RFM12.

Benötigt werden in der Minimal-Version im FIFO-Modus nur die Anschlüsse nSEL, SDO, SDI und SCK, eben das komplette SPI-Interface. Der Zugriff auf das Sende- und Empfangs-FIFO ist per Software möglich, ebenso die Abfrage der Statusbits. Deshalb werden z.B. nIRQ und nFFS nicht unbedingt benötigt. nIRQ signalisiert unter anderem, dass das Modul bereit ist Daten zu empfangen. Wenn Daten empfangen wurden, kann dies über den FFIT-Pin abgefragt werden (falls die Füllschwelle eingestellt wurde). nFFS dient dazu das FIFO direkt anzusprechen (es ist quasi der Chipselect für das FIFO), davon wird in der Minimalversion aber kein Gebrauch gemacht. Der Pin muss daher auf high-Pegel gelegt werden!
An CLK kann eine Frequenz von 1MHz bis 10MHz eingestellt werden. Hiermit kann dann z.B. der Mikrocontroller versorgt werden.
Reset ist ein Open-Collector-Ausgang und gleichzeitig der Reset-Eingang. Er sollte daher entweder gar nicht, oder aber hochohmig angeschlossen werden.

Im FIFO-Mode kann das Modul konfiguriert werden mit dem Empfang zu warten, bis die Daten 0x2DD4 empfangen wurden. Sobald dieses Bitmuster empfangen wurde, werden Daten in das FIFO geschrieben, bis man das FIFO abschaltet und die Mustererkennung neu startet.

Als weitere Modi stehen unter anderem ein synchroner Modus zur Verfügung (no FIFO mode), in dem der Sender/Empfänger den Bittakt ausgibt, und synchron dazu die zu sendenden Daten einliest bzw. die empfangenen Daten ausgibt. Der SPI Bus ist trotzdem zur Initialisierung des Moduls notwendig.

== FAQ ==

=== SPI Interface ===

* Maximale Datenrate: 2,5MHz (10MHz Quarz / 4)

=== CLK-Ausgang bleibt bei 1 MHz ===

* Vor dem Umschalten (mit 0xC0E0) länger warten.

=== RFM12 empfängt ein paar Bytes, dann nur Müll ===

* Es wird zu langsam gesendet (TX FIFO underrun)
* Es wird zu langsam empfangen (RX FIFO overrun)

Die Status-Bits helfen hier beim Debuggen. SPI sollte auf maximaler Transferrate stehen.

=== RFM empfängt nur Müll ===

http://www.mikrocontroller.net/topic/73560#605528

Deine Module verhalten sich normal. Man muß mit den Gain- und AFC-Bits
eine ganze Weile spielen, bis die Module korrekt laufen (kommt auf die
Anwendung an). Fakt ist: der Empfänger empfängt ständig Datenmüll als
Rauschen. Wenn der FIFO durch die Präambel getriggert wird, sind die
Daten im FIFO ziemlich korrekt, wenn alles "gut" eingestellt ist. Der
FIFO sollte per Interrupt dann auch sofort abgeholt werden, da sonst das
nächste Byte das alte direkt überschreibt. Jeder zusammenhängende
Datensatz (mehrere Bytes an einem Stück) muß von einer Präambel
eingeleitet werden. Nach dem kompletten Einlesen eines Datensatzes muß
der FIFO abgeschaltet, wieder eingeschaltet und für den Empfang der
nächsten Präambel neu scharf gemacht werden.

=== RFM hängt sich auf ===

Wenn man die AFC nicht begrenzt, also keinen Wertebereich vorgibt, die eine maximale Abweichung korrigiert wird passiert es nach einer Weile, dass sich der Empfänger aufhängt, die Offsetbits im Status werden maximal und dann geht gar nichts mehr, er hängt fest.

Siehe auch
* Forenbeitrag [http://www.mikrocontroller.net/topic/82456#689660 RFM12: Erfahrungen ]

=== Kommunikation mit RFM funktioniert nur sporadisch ===

* Ist die Versorgungsspannung stabil? (evtl. Kondensator einbauen)

== Register ==

Von https://www.mikrocontroller.net/attachment/24947/RFM12.txt

Dieses Dokument beschreibt die Nutzung des RFM12 TRX Moduls!

''' WICHTIG '''

Dieses Dokument wurde aus mehreren Quellen zusammengestellt, und kann Fehler enthalten!
Es können Abweichungen in Bezug auf RF01 / RF02 / RF12 / RFM01 / RFM02 und andere Module auftreten!
Es wurde das Datenblatt vom RFM12B und RF12 von www.hoperf.com als Basis genuzt. Zusätzlich wurden diese Informationen mit Hilfe von Forums-Nutzern (https://www.mikrocontroller.net/topic/71682) weiter vervollständigt!

''' WICHTIG '''

'''Hinweis:''' Die LNA-Eingangsimpedanz beträgt 250 Ohm, und muss beim Anschluss einer 50-Ohm-Antenne entsprechend angepasst werden, um das Rauschen zu minimieren! '' -- (Auf den Pollin-Modulen bereits vorhanden)''

=== Configuration Setting ===
Hex = 80 & xx
Bit-Syntax: 10000000 | el | ef | b1 | b0 | x3 | x2 | x1 | x0
el (TX FIFO) = Sendepuffer für Datentransfer nutzen (1 = An / 0 = Aus)
ef (RX FIFO) = Empfangspuffer für Datenspeicherung nutzen (1 = An / 0 = Aus)
b... = Zu nutzende Basisfrequenz (00=315MHz / 01=433MHz / 10=868MHz / 11=915MHz)
x... = Interner Clock des Chips kann durch verschieben einer Kondensator-Anpass-Stufe bestimmt werden.
0,5pF pro Schritt. Basis ist 8,5pF -> (0000=8,5 / 0001=9,0 / 0010=9,5 / ...)

=== Power-Managment ===
Hex = 82 & xx
Bit-Syntax: 10000010 | er | ebb | et | es | ex | eb | ew | dc
er = Empfänger einschalten (1 = an / 0 = Aus)
ebb = ... (Synthesizer muss aktiv sein!) (1 = an / 0 = aus)
et = Sender einschalten (1 = an / 0 = Aus) (Wenn das TX-Register aktiv und mit Daten gefüllt ist/wurde,
werden diese Daten sofort gesendet) (1 = an / 0 = aus)
es = Schaltet den Synthesizer ein. (1 = an / 0 = aus)
ex = Schaltet den Quarz-Oszilator ein. (1 = an / 0 = aus)
eb = Vergleichbar mit BrownOutDetection -> Erkennt eine zu geringe Betriebsspannung und erzeugt einen Interrupt,
um einen drohenden Spannungsaufall anzukündigen (1 = An / 0 = Aus)
ew = Aktiviert den WakeUpTimer des Prozessors. (1 = an / 0 = aus)
dc = Deaktiviert die Ausgabe des SystemClocks auf dem CLK Pin am Chip (1 = Keine ClockAusgabe / 0 = Clock ausgeben)

=== PLL Setting ===
Hex = 198 + y
Bit-Syntax: 110011000 | ob1 | ob0 | lpx | ddy | ddit | bw1 | bw0
ob... = ... (00= 5 oder 10MHz [standard] / 01=3.3MHz / 1x=2.5MHz oder weniger)
lpx = Wählt den Low-Power-Mode für den Quarz-Oszilator aus. (0=1ms [620µA] / 1=2ms [460µA])
ddy = ...
ddi = Schaltet das Dithering in PLL-Schleife ab. (1=abgeschaltet / 0=eingeschaltet)
bw... = Wählt die Bandbreite des PLL-Signals aus. (00=86.2kbps [-107dBc/Hz] / 01=256kbps [-102dBc/Hz]) Bei 1MHz Offset Phasenrauschen.

=== LowBatt / µC Clock Control ===
Hex = c0 & xx
Bit-Syntax: 11000000 | d2 | d1 | d0 | v4 | v3 | v2 | v1 | v0
d... = Bestimmt den Teilungsfaktor für die Clockausgabe am CLK-Pin in Abhängigkeit des Internen SystemTakts.
(000=1 / 001=1.25 / 010=1.66 / 011=2 / 100=2.5 / 101=3.33 / 110=5 / 111=10)
v... = Bestimmt die Minimalspannung, ab der ein Interrupt durchgeführt werden
muss. (Ähnlich einer BrownOutDetection). Im Power-Managment muss das eb-Bit
aktiv sein, damit dies funktioniert.

=== Frequency-setting ===
Bestimmt den Offset der Sende- und Empfangsfrequenz. Dieser Offset wird auf das Basisband im Configuration Setting hinzu gerechnet.
Hex = a & xxx
Bit-Syntax: 1010 | f11 | f10 | f9 | f8 | f7 | f6 | f5 | f4 | f3 | f2 | f1 | f0
f... = Bestimmt den Offsetwert der Frequenz.
Als Basis gilt das eingestellte Band im Configuration-Settings-Kommando

=== Data-Rate ===
Hex = c6 & xx
Bit-Syntax: 11000110 | cs | r6 | r5 | r4 | r3 | r2 | r1 | r0
cs = Vorteiler, Faktor 7. Hiermit kann ein Vorteiler aktiviert werden,
der die errechnete Baudrate (r...) durch 7 teilt.
r... = Baudratenteilerfaktor

=== RX Control ===
Hex = 94 & xx
Bit-Syntax: 10010 | p20 | d1 | d2 | i2 | i1 | i0 | g1 | g0 | r2 | r1 | r0
p20 = Bestimmt die Funktion des Pin20 (nINT / VDI) am RFM12 Chip (1 = VDI-Ausgang / 0 = Interrupt-Eingang)
d... = (Valid Data Indicator). Definiert die Geschwindigkeit, mit der bestimmt wird, ob ein Signal korrekt ist, oder nicht.
(00=schnell / 01=mittel / 10=langsam / 11=immer an). Je nach eingestellter Variante werden
unterschiedliche Hardware- und Software-Kombinationen genuzt.
Fast: CR_Lock OR DQD ... Medium: CR_Lock AND ( DRSSI OR DQD ) ...
SLOW: R/S FlipFlop aus (SET) DRSSI OR DQD OR CR_Lock und (CLR) DRSSI AND DQD AND CR_Lock .
i... = Bestimmt die Bandbreite des Empfängers in KHz (KiloHertz).
(000=Reserviert / 001=400 / 010=340 / 011=270 / 100=200 / 101=134 / 110=67 / 111=Reserviert)
g... = (LNA-Gain) Verstärkungsfaktor des Rauscharmen-Eingangs-Signal-Verstärkers (LNA Low Noise Amplifier).
Werte in dBm (Dezibel [Grösse: Milliwatt]) Mögliche Werte sind: 0 / -6 / -14 / -20
r... = (DRSSI = Digital Received Signal Strength Indication) Minimale Empfangssignalfeldstärke.
6 dBm pro Schritt: (000=-103 / 001=-97 / 010=-91 / ...)

=== Synchron Pattern ===
Hex = ce & xx
Bit-Syntax: 11001110 | b7 | b6 | b5 | b4 | b3 | b2 | b1 | b0
b... = Legt den Wert fest, der als Synchronisations-Byte für die Datenfilterung verwendet werden soll.

=== Data Filter ===
Hex = c2 & xx
Bit-Syntax: 11000010 | al | ml | -unknow- (1) | s | -unknow- (1) | f2 | f1 | f0
al = Baudratenregenerator schaltet automatisch in den langsamen Modus,
sobald er einen Takt erkannt hat.
ml = schneller/langsamer Modus
-unknown- (1) = ??? (Standard = 1) (Auch im Datenblatt von IA4420 so beschrieben)
s = (DataFilter) Typ des Datenfilters (0=DigitalFilter / 1=AnalogFilter).
Bei Nutzung des Analog-Filters kann kein FIFO sowie kein ClockRecovery genuzt werden.
-unknown- (1) = ??? (Standard = 1) (Auch im Datenblatt von IA4420 so beschrieben)
f... = (DQD Threshold) Bestimmt den Schwellwert, ab dem ein Signal als gut empfunden wird,
und der Empfänger dieses weiterverarbeiten soll.
DQD (data quality detection) zählt die "Spikes" des ungefilterten Signals, und bestimmt darüber die Qualität der Daten.

=== FIFO und RESET-Mode ===
Hex = ca & xx
Bit-Syntax: 11001010 | f3 | f2 | f1 | f0 | -unknow- (0) | al | ff | dr
f... = (FIFO interrupt Level)
-unknown- (0) = ??? (Standard = 0) (Auch im Datenblatt von IA4420 so beschrieben)
al = (FIFO Fill Condition) Legt den Wert fest, ab dem das Füllen des FIFOs beginnt.
(0=Synchron / 1=Ständig). Bei Nutzung des Synchron-Modus, werden erst dann Daten in den FIFO geschrieben,
wenn eine definierte 16Bit-Datenfolge empfangen wurde (Standard ist Hex: 2dd4).
ff = (FIFO Fill) Startet das Einlesen der empfangenen Daten in den FIFO-Puffer.
Wenn al (FIFO Fill Condition) auf synchron steht, dann startet das Setzen dieses Bits die Synchronisation-Bit-Erkennung.
dr = (Sens Reset Mode) Wenn dieses Bit auf 1 steht, wird bei einer Schwankung von 200mV auf
der VCC-Leitung (Spannungsversorgung des Chips), ein System-Reset ausgelöst.

=== Automatic Frequency Control ===
Hex = c4 & xx
Bit-Syntax: 11000100 | a1 | a0 | rl1 | rl0 | st | fi | oe | en
a... = Modus der AFC-Schaltung, 0=Auto, 1=einmalig nach Einschalten, 2=Solange VDI low ist, 3=unabhängig von VDI
r... = (Range Limit) Frequenzraster (00=KeineBegrenzung / 01=+15 > -16 / 10=+7 > -8 / 11=+3 > -4)
st = Berechneten Offset-Wert übernehmen
fi = Genauer Berechnungsmodus (besser aber lansgamer)
oe = AFC-Offset freischalten
en = AFC-Berechnung aktivieren

=== TX Configuration Control ===
Hex = 98 & xx
Bit-Syntax: 1001100 | mp | m3 | m2 | m1 | m0 | -unknow- (0) | p2 | p1 | p0
mp = (Modulation Polarity) Bestimmt die Richtung der FSK-Erzeugung (invertiert das Spektrum).
m... = (fDeviation) Bestimmt den Frequenzabstand des High- und Low-Wertes bei der Ubertragung im FSK-Betrieb. Basis ist der mp-Wert.
-unknown- (0) = ??? (Standard = 0) (Auch im Datenblatt von IA4420 so beschrieben)
p... = Bestimmt die relative Ausgangsleistung des Senders anhand des dBm-Wertes (Dezibel [Grösse: Milliwat]) 3-dBm-Schritte.
(000=0 / 001=-3 / 010=-6 / ...). Der Wert steht im Zusammenhang mit der angeschlossenen Antennen-Impedanz.

=== Wake-Up Timer ===
Bestimmt die Zeitperiode der zyklischen Einschaltung des WakeUp-Timers
Hex = e & xxx
Bit-Syntax: 111 | R4 | R3 | R2 | R1 | R0 | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0
R = Exponent der Zeit
M = Zeit

=== Low Duty-Cycle ===

Bestimmt die maximale Sendezeit pro Stunde. Dies ist wichtig, um sich an gesetzliche Frequenzzuteilungsrichtlinien zu halten, die bestimmen, wie lang jemand mit einer definierten Sendeleistung auf einer bestimmten Frequenz (mit eventuell definierter Betriebsart [Modulationstyp]) senden darf.)

hex = 6400 + Bits
Bit-Syntax: 1100100 | r| d6 | d5 | d4 | d3 | d2 | d1 | d0 | en
r = ??????????????????
d... = Einschaltdauer während der zyklischen Einschaltung
en = zyklische Einschaltung aktivieren

=== RX FIFO Read ===
Hex = b000
Bit-Syntax: 1011000000000000

Dieses Kommando löst die Rückgabe eines Datenbytes (synchron mit dem 8. Bit) aus. Es ist nötig, dass das ef-Bit (RX-FIFO) im Configuration Setting gesetzt wurde, um diese Funktion nutzen zu können!

=== TX Register Write ===
Dieses Kommando schreibt Daten in den TX-Puffer. Wenn der Sender aktiv ist, wird dieses sofort gesendet. el (TX-Register) muss im Configuration-Setting-Kommando aktiv sein.
Hex = b8 & xx
Bit-Syntax: 10111000 | DataByteToSend
DataByteToSend = Das Datenbyte, welches gesendet werden soll.

(Senden Funktioniert nur wenn zuvor der Status abgefragt wurde)

=== Status Read ===
Dieses Kommando löst die Rückgabe des Statusregisters aus, welches nach der ersten 0 im ersten Bit synchron übertragen wird.
Hex = 0000
Bit-Syntax: 0000000000000000<000>
Rückgabe-Syntax: x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | x10 | x11 | x12 | x13 | x14 | x15 | x16 | x17 | x18
x0 -> x5 = Interrupt bits
x6 -> x15 = Status Bits
x16 -> x18 = FIFO
x0 = FFIT / RGIT (RGIT = TX-Register ist bereit neue Daten zu senden ... kann mit dem TX-Register gelöscht werden)
(FFIT = Die Anzahl der Datenbits im FIFO-Puffer hat das eingestellte Limit erreicht.
Kann mit einer der FIFO-Lesemethoden gelöscht werden)
x1 = POR (PowerOnReset)
x2 = FFOV / RGUR (RGUR = Der Datenstrom beim Senden ist abgerissen, da nicht schnell genug Daten nachgeladen wurden)
(FFOV = Der RX-FIFO ist übergelaufen)
x3 = WKUP
x4 = EXT
x5 = LBD
x6 = FFBM (Der FIFO-Puffer ist leer)
x7 = RSSI/ATS (ATS = )(RSSI = Die Signalstärke ist über dem eingestelltem Limit)
x8 = DQD
x9 = CRL
x10 = ATGL
x11 = OFFS_4
x12 = OFFS_3
x13 = OFFS_2
x14 = OFFS_1
x15 = OFFS_0
x16 = FO
x17 = FO+1
x18 = FO+2

== Bezugsquellen ==
* [[Elektronikversender#csd-electronics|csd-electronics]]
* [[Elektronikversender#IT-WNS|IT-WNS]]
* [[Elektronikversender#Pollin_Electronic|Pollin Electronic]]

== Links ==

* [[AVR RFM12]]
* [[RFM12 Protokoll Stack]]
* [http://www.mikrocontroller.net/topic/93801 Bezugsquellen]

Folgende Links sind mit Vorsicht zu genießen, da die Datenblätter teilweise fehlerbehaftet sind. Es empfiehlt sich, direkt mit dem Datenblatt des RF12 (das ist das IC auf dem Modul) zu arbeiten. Dieses ist so gut wie fehlerfrei.

* [http://www.hoperf.com/pdf/RF12.pdf Datenblatt des ICs RF12] (PDF)
* [http://www.hoperf.com/pdf/RFM12.pdf Datenblatt des Moduls RFM12] (PDF)
* [http://www.hoperf.com/pdf/RF12_code.pdf Programming Guide] (PDF)
* [http://www.hoperf.com/pdf/RF12TOOLS.pdf Demo Kit User Manual] (PDF)
* [http://www.pollin.de/shop/downloads/D810047S.ZIP Beispielprogramm von Pollin] (ZIP)

[[Kategorie:Bauteile]]
[[Kategorie:Funk]]

AVR-GCC-Tutorial

2008-11-09T15:57:47Z

Thymythos: /* volatile und Pointer */

= Vorwort =

Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[AVR-GCC]] erleichtern.

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.

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.

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).

Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.

Dieses Tutorial ist in PDF-Form erhältlich bei:
http://www.siwawi.arubi.uni-kl.de/avr_projects/AVR-GCC-Tutorial_-_www_mikrocontroller_net.pdf
(nicht immer auf aktuellem Stand)

= Benötigte Werkzeuge =

Um eigene Programme für AVRs mittels avr-gcc/avr-libc zu erstellen und zu testen, wird folgende Hard- und Software benötigt:

* 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]].

* 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]].

* 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]]).

* 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]]).

= Was tun, wenn's nicht "klappt"? =

* 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.

* Die [[AVR Checkliste]] durcharbeiten.

* 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.

* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.

* Das [http://www.mikrocontroller.net/forum/2 GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.

* Das avr-gcc-Forum bei [http://www.avrfreaks.net avrfreaks] nach vergleichbaren Problemen absuchen.

* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.

* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRFREAKS] (anmelden).

* Google oder yahoo befragen schadet nie.

* 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.

* Die Beispieleprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.

* 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.lugbz.org/documents/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.

= Erzeugen von Maschinencode =

Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z. 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. 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:

* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z. 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 für den avr-gcc (ohne Anspruch auf Vollständigkeit): AtmanAvr C (relativ günstig), KamAVR (kostenlos), VMLab (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. B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen.

* 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).

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. 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.

= Einführungsbeispiel =

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.

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.

Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.

<c>
/* Alle Zeichen zwischen Schrägstrich-Stern
und Stern-Schrägstrich sind lediglich Kommentare */

// Zeilenkommentare sind ebenfalls möglich
// alle auf die beiden Schrägstriche folgenden
// Zeichen einer Zeile sind Kommentar

#include <avr/io.h> // (1)

int main (void) { // (2)

DDRB = 0xff; // (3)
PORTB = 0x03; // (4)

while(1) { // (5a)
/* "leere" Schleife*/; // (5b)
} // (5c)

/* wird nie erreicht */
return 0; // (6)
}
</c>

* 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.

* Bei (2) beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion main.

* 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.

* (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).

* (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.

* (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.

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]].

<pre>
D:\tmp\gcc_tut\quickstart>dir

Verzeichnis von D:\tmp\gcc_tut\quickstart

28.11.2006 22:53 <DIR> .
28.11.2006 22:53 <DIR> ..
28.11.2006 20:06 118 main.c
28.11.2006 20:03 16.810 Makefile
2 Datei(en) 16.928 Bytes
</pre>

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.

<pre>
D:\tmp\gcc_tut\quickstart>make all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: main.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -
o obj/main.o

Linking: main.elf
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o
--output main.elf -Wl,-Map=main.map,--cref -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex

[...]
</pre>

Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z. 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. B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio), kann natürlich ebenfalls genutzt werden.

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.

= Exkurs: Makefiles =

Wenn man bisher gewohnt ist, mit integrierten Entwicklungsumgebungen à la Visual-C Programme zu erstellen, wirkt das makefile-Konzept auf den ersten Blick etwas kryptisch. Nach kurzer Einarbeitung ist diese Vorgehensweise jedoch sehr praktisch. Diese Dateien (üblicher Name: 'Makefile' ohne Dateiendung) dienen der Ablaufsteuerung des Programms make, das auf allen Unix/Linux-Systemen installiert sein sollte, und in einer Fassung fuer MS-Windows auch in [[WinAVR]] (Unterverzeichnis utils/bin) enthalten ist.

Im Unterverzeichnis ''sample'' einer WinAVR-Installation findet man eine sehr brauchbare Vorlage, die sich einfach an das eigene Projekt anpassen lässt ([[Media:Makefile|lokale Kopie Stand Sept. 2004]]). Wahlweise kann man auch [http://www.sax.de/~joerg/mfile/ mfile] von Jörg Wunsch nutzen. mfile erzeugt ein makefile nach Einstellungen in einer grafischen Nutzeroberfläche, wird bei WinAVR mitinstalliert, ist aber als TCL/TK-Programm auf nahezu allen Plattformen lauffähig.

''Die folgenden Ausführungen beziehen sich auf das WinAVR Beispiel-Makefile.''

Ist im Makefile alles richtig eingestellt, genügt es, sich drei Parameter zu merken, die über die shell bzw. die Windows-Kommandozeile (cmd.exe/command.com) als Parameter an "make" übergeben werden. Das Programm make sucht sich "automatisch" das Makefile im aktuellen Arbeitsverzeichnis und führt die darin definierten Operationen für den entsprechenden Aufrufparameter durch.

{| border=1
| ''make all''
| Erstellt aus den im Makefile angegebenen Quellcodes eine ''hex''-Datei (und ggf. auch ''eep''-Datei).
|-
| ''make program''
| Überträgt die hex-Datei (und wahlweise auch die eep-Datei für den EEPROM) zum AVR.
|-
| ''make clean''
| löscht alle temporären Dateien, also auch die hex-Datei
|}

Diese Aufrufe können in die allermeisten Editoren in "Tool-Menüs" eingebunden werden. Dies erspart den Kontakt mit der Kommandozeile. Bei WinAVR sind die Aufrufe bereits im Tools-Menü des mitgelieferten Editors Programmers-Notepad eingefügt.

Üblicherweise sind folgende Daten im Makefile anzupassen:
* Controllertyp

* Quellcode-Dateien (c-Dateien)

* Typ und Anschluss des Programmiergeräts

Seltener sind folgende Einstellungen durchzuführen:
* Grad der Optimierung

* Methode zur Erzeugung der Debug-Symbole (Debug-Format)

* Assembler-Quellcode-Dateien (S-Dateien)

Die in den folgenden Unterabschnitten gezeigten Makefile-Ausschnitte sind für ein Programm, das auf einem ATmega8 ausgeführt werden soll. Der Quellcode besteht aus den c-Dateien superprog.c (darin main()), uart.c, lcd.c und 1wire.c. Im Quellcodeverzeichnis befinden sich diese Dateien: superprog.c, uart.h, uart.c, lcd.h, lcd.c, 1wire.h, 1wire.c und das makefile (die angepasste Kopie des WinAVR-Beispiels).

Der Controller wird mittels [[AVRDUDE]] über ein [[STK200]]-Programmierdongle an der Schnittstelle lpt1 (bzw. /dev/lp0) programmiert. Im Quellcode sind auch Daten für die ''section .eeprom'' definiert (siehe Abschnitt [[AVR-GCC-Tutorial#EEPROM|Speicherzugriffe]]), diese sollen beim Programmieren gleich mit ins EEPROM geschrieben werden.

== Controllertyp setzen ==

Dazu wird die "make-Variable" MCU entsprechend dem Namen des verwendeten Controllers gesetzt. Eine Liste der von avr-gcc und der avr-libc unterstützten Typen findet sich in der [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc].

<div class="code"><pre>
# Kommentare in Makefiles beginnen mit einem Doppelkreuz
...

# ATmega8 at work
MCU = atmega8
# oder MCU = atmega16
# oder MCU = at90s8535
# oder ...
...
</pre></div>

== Quellcode-Dateien eintragen ==

Der Name der Quellcodedatei, welche die Funktion main enthält, wird hinter TARGET eingetragen. Dies jedoch ohne die Endung ''.c''.

<div class="code"><pre>
...
TARGET = superprog
...
</pre></div>

Besteht das Projekt wie im Beispiel aus mehr als einer Quellcodedatei, sind die weiteren c-Dateien (nicht die Header-Dateien, vgl. [[Include-Files (C)]]) durch Leerzeichen getrennt bei SRC einzutragen. Die bei TARGET definierte Datei ist schon in der SRC-Liste enthalten. Diesen Eintrag nicht löschen!

<div class="code"><pre>
...
SRC = $(TARGET).c uart.c lcd.c 1wire.c
...
</pre></div>

Alternativ kann man die Liste der Quellcodedateien auch mit dem Operator += erweitern.

<div class="code"><pre>
SRC = $(TARGET).c uart.c 1wire.c
# lcd-Code fuer Controller xyz123 (auskommentiert)
# SRC += lcd_xyz.c
# lcd-Code fuer "Standard-Controller" (genutzt)
SRC += lcd.c
</pre></div>

== Programmiergerät einstellen ==

Die Vorlagen sind auf die Programmiersoftware [[AVRDUDE]] angepasst, jedoch lässt sich auch andere Programmiersoftware einbinden, sofern diese über Kommandozeile gesteuert werden kann (z. B. stk500.exe, uisp, sp12).

<div class="code"><pre>
...
# Einstellung fuer STK500 an com1 (auskommentiert)
# AVRDUDE_PROGRAMMER = stk500
# com1 = serial port. Use lpt1 to connect to parallel port.
# AVRDUDE_PORT = com1 # programmer connected to serial device

# Einstellung fuer STK200-Dongle an lpt1
AVRDUDE_PROGRAMMER = stk200
AVRDUDE_PORT = lpt1
...
</pre></div>

Sollen Flash(=.hex) und EEPROM(=.eep) zusammen auf den Controller programmiert werden, ist das Kommentarzeichen vor AVRDUDE_WRITE_EEPROM zu löschen.

<div class="code"><pre>
...
# auskommentiert: EERPOM-Inhalt wird nicht mitgeschrieben
#AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(TARGET).eep

# nicht auskommentiert: EERPOM-Inhalt wird mitgeschrieben
AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(TARGET).eep
...
</pre></div>

== Anwendung ==

Das erstellte Makefile und der Code müssen im gleichen Ordner sein, auch sollte der Dateiname nicht verändert werden.

Die Eingabe von ''make all'' im Arbeitsverzeichnis mit dem Makefile und den Quellcodedateien erzeugt (unter anderem) die Dateien superprog.hex und superprog.eep. Abhängigkeiten zwischen den einzelnen c-Dateien werden dabei automatisch berücksichtigt. Die ''superprog.hex'' und ''superprog.eep'' werden mit ''make program'' zum Controller übertragen. Mit ''make clean'' werden alle temporären Dateien gelöscht (="aufgeräumt").

== Sonstige Einstellungen ==

=== Optimierungsgrad ===

Der gcc-Compiler kennt verschiedene Stufen der Optimierung. Nur zu Testzwecken sollte die Optimierung ganz deaktiviert werden (''OPT = 0''). Die weiteren möglichen Optionen weisen den Compiler an, möglichst kompakten oder möglichst schnellen Code zu erzeugen. In den weitaus meisten Fällen ist ''OPT = s'' die empfohlene Einstellung, damit wird kompakter und oft auch der schnellste Maschinencode erzeugt. Beim Update auf eine neue Compilerversion ist zu beachten, dass diese möglicherweise intern andere Optimierungsalgorithmen verwendet und sich dadurch die Größe des Machinencodes etwas ändert, ohne dass man im Quellcode etwas geändert hat.

Als Orientierungswerte die Größe des Maschinencodes bei verschiedenen Optionen für einen nicht näher spezifizierten relativ kleinen Testcode bei Verwendung einer nicht näher spezifizierten Compilerversion.

* -O0 : 12'217 Byte

* -O1 : 9'128 Byte

* -O2 : 1'670 Byte

* -O3 : 3'004 Byte

* -Os : 1'695 Byte

Im diesem Testfall führt die Option -O2 mit zum kompaktesten Code, dies allerdings hier nur mit 25 Bytes "Vorsprung". Es kann durchaus sein, dass nur wenige Programmerweiterungen dazu führen, dass Compilieren mit -Os wieder in kompakteren Code resultiert.

Siehe dazu auch:
* [http://www.nongnu.org/avr-libc/user-manual/using_tools.html#gcc_optO avr-libc manual Abschnitt Using the gnu-tools/Compiler-Optionen]

* [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_optflags avr-libc Manual FAQ Nr. 16] (Stand avr-libc Version 1.4.5)

=== Debug-Format ===

Unterstützt werden die Formate stabs und dwarf-2. Das Format wird hinter ''DEBUG ='' eingestellt. Siehe dazu Abschnitt ''Eingabedateien zur Simulation''.

=== Assembler-Dateien ===

Die im Projekt genutzten Assembler-Dateien werden hinter ASRC durch Leerzeichen getrennt aufgelistet. Assembler-Dateien haben immer die Endung .S (großes S). Ist zum Beispiel der Assembler-Quellcode eines Software-UARTs in einer Datei softuart.S enthalten, lautet die Zeile: ''ASRC = softuart.S''

=== Taktfrequenz ===

Neuere Versionen der WinAVR/Mfile Vorlage für Makefiles beinhalten die Definition einer Variablen F_CPU (WinAVR 2/2005). Darin wird die Taktfrequenz des Controllers in Hertz eingetragen. Die Definition steht dann im gesamten Projekt ebenfalls unter der Bezeichnung F_CPU zur Verfügung (z. B. um daraus UART-, SPI- oder ADC-Frequenzeinstellungen abzuleiten).

Die Angabe hat rein "informativen" Charakter, die tatsächliche Taktrate wird über den externen Takt (z. B. Quarz) bzw. die Einstellung des internen R/C-Oszillators bestimmt. Die Nutzung von F_CPU hat also nur Sinn, wenn die Angabe mit dem tatsächlichen Takt übereinstimmt.

Innerhalb neuerer Versionen der avr-libc (ab Version 1.2) wird die Definition der Taktfrequenz (F_CPU) zur Berechnung der Wartefunktionen in delay.h genutzt. Diese funktionieren nur dann korrekt, wenn F_CPU mit der tatsächlichen Taktfrequenz übereinstimmt.
F_CPU muss dazu jedoch nicht unbedingt im makefile definiert werden. Es reicht aus, wird aber bei mehrfacher Anwendung unübersichtlich, vor ''#include <util/delay.h>'' (veraltet: ''#include <avr/delay.h>'') ein ''#define F_CPU [hier Takt in Hz]UL'' einzufügen. Bei Nutzung von delay.h ist darauf zu achten, dass die Optimierung des Compilers nicht ausgeschaltet ist, sonst wird sehr viel Code erzeugt und die Wartezeit stimmt nicht mit der gewünschten Zeitspanne überein. Vgl. dazu den [http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html entsprechenden Abschnitt der Dokumentation].

== Eingabedateien zur Simulation in AVR-Studio ==

Mit älteren AVR-Studio-Versionen kann man nur auf Grundlage so genannter ''coff''-Dateien simulieren. Neuere Versionen von AVR-Studio (ab 4.10.356) unterstützen zudem das modernere aber noch experimentelle dwarf-2-Format, das ab WinAVR 20040722 (avr-gcc 3.4.1/Binutils inkl. Atmel add-ons) "direkt" vom Compiler erzeugt wird.

; Vorgehensweise bei dwarf-2:
* Im Makefile bei DEBUG: <div class="code"><pre>DEBUG=dwarf-2</pre></div>

* ''make all'' (evtl. vorher ''make clean'')

* Die erzeugte ''elf''-Datei (im Beispiel oben ''superprog.elf'') in AVR-Studio laden

* AVR-Simulator und zu simulierenden Controller wählen, "Finish"

* Weiteres siehe AVR-Studio Online-Hilfe

; Vorgehensweise bei extcoff: (sollte nur noch in Ausnahmefällen genutzt werden)

* Im Makefile bei DEBUG: <div class="code"><pre>DEBUG=stabs</pre></div>

* ''make extcoff'' (evtl. vorher ''make clean'')

* Die erzeugte ''cof''-Datei (im Beispiel oben ''superprog.cof'') in AVR-Studio laden

* AVR-Simulator und zu simulierenden Controller wählen, "Finish"

* Weiteres siehe AVR-Studio Online-Hilfe

Beim Simulieren scheinen oft "Variablen zu fehlen". Ursache dafür ist, dass der Compiler diese "Variablen" direkt Registern zuweist. Dies kann vermieden werden, indem die Optimierung abgeschaltet wird (im makefile). Man simuliert dann jedoch ein vom optimierten Code stark abweichendes Programm. Das Abschalten der Optimierung wird nicht empfohlen.

Statt des Software-Simulators kann das AVR-Studio auch genutzt werden, um mit dem ATMEL JTAGICE, einem Nachbau davon (BootICE, Evertool o. ä.) oder dem ATMEL JTAGICE MKII "im System" zu debuggen. Dazu sind keine speziellen Einstellungen im makefile erforderlich. Debugging bzw. "In-System-Emulation" mit dem JTAGICE und JTAGICE MKII sind in der AVR-Studio Online-Hilfe beschrieben.

Die Verwendung von Makefiles bietet noch viele weitere Möglichkeiten, einige davon werden im Anhang [[AVR-GCC-Tutorial#Zus.C3.A4tzliche_Funktionen_im_Makefile|Zusätzliche Funktionen im Makefile]] erläutert.

= Ganzzahlige (Integer) Datentypen =

Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.

Standardisierte Datentypen werden in der Header-Datei stdint.h definiert.
Zur Nutzung der standardisierten Typen bindet man die "Definitionsdatei" wie folgt ein:

<c>
// ab avr-libc Version 1.2.0 möglich und empfohlen:
#include <stdint.h>

// veraltet: #include <inttypes.h>
</c>

Einige der dort definierten Typen (avr-libc Version 1.0.4):

<c>
typedef signed char int8_t;
typedef unsigned char uint8_t;

typedef short int16_t;
typedef unsigned short uint16_t;

typedef long int32_t;
typedef unsigned long uint32_t;

typedef long long int64_t;
typedef unsigned long long uint64_t;
</c>

* int8_t steht für einen 8-Bit Integer mit einem Wertebereich -128 bis +127.

* uint8_t steht für einen 8-Bit Integer ohne Vorzeichen (unsigned int) mit einem Wertebereich von 0 bis 255

* int16_t steht für einen 16-Bit Integer mit einem Wertebereich -32768 bis +32767.

* uint16_t steht für einen 16-Bit Integer ohne Vorzeichen (unsigned int) mit einem Wertebereich von 0 bis 65535.

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.

= Bitfelder =

Beim Programmieren von Mikrocontrollern muss auf jedes Byte oder sogar auf
jedes Bit geachtet werden. Oft müssen wir in einer Variablen lediglich den
Zustand 0 oder 1 speichern. Wenn wir nun zur Speicherung eines einzelnen Wertes
den kleinsten bekannten Datentypen, nämlich '''unsigned char''', nehmen, dann
verschwenden wir 7 Bits, da ein '''unsigned char''' ja 8 Bits breit ist.

Hier bietet uns die Programmiersprache C ein mächtiges Werkzeug an, mit dessen
Hilfe wir 8 Bits in eine einzelne Bytevariable zusammenfassen und (fast) wie
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:

<c>
struct {
unsigned bStatus_1:1; // 1 Bit für bStatus_1
unsigned bStatus_2:1; // 1 Bit für bStatus_2
unsigned bNochNBit:1; // Und hier noch mal ein Bit
unsigned b2Bits:2; // Dieses Feld ist 2 Bits breit
// All das hat in einer einzigen Byte-Variable Platz.
// die 3 verbleibenden Bits bleiben ungenutzt
} x;
</c>

Der Zugriff auf ein solches Feld erfolgt nun wie beim Strukturzugriff bekannt
über den Punkt- oder den Dereferenzierungs-Operator:

<c>
x.bStatus_1 = 1;
x.bStatus_2 = 0;
x.b2Bits = 3;
</c>

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.

Wenn man nur ein paar wenige Variablen vom Typ bool verwenden möchte, kann man
auch die Headerdatei <stdbool.h> einbinden und sich dann wie gewohnt einen Booltyp anlegen. Variablen dieses Typs brauchen dennoch 1 Byte Speicher, ermöglichen aber eine genaue Unterscheidung zwischen Zahlenvariable und boolscher Variable.

= Grundsätzlicher Programmaufbau eines µC-Programms =

Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in
welcher Programmiersprache das Programm geschrieben wird.

== Sequentieller Programmablauf ==

Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im
Wesentlichen immer den gleichen Aufbau hat:

[[Image:Sequentielle Programme.gif]]

== Interruptgesteuerter Programmablauf ==

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.

[[Image:Interrupt Programme.gif]]

= Zugriff auf Register =

Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die
Inhalte der Register sowohl auslesen als auch beschreiben.

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
die 8-Bit Register.

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.

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:

<c>
#include <avr/io.h>
</c>

Ist im Makefile der MCU-Typ z. 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.


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:

<pre>
[...]
# MCU Type ("name") setzen:
MCU = atmega16
[...]

[...]
## Verwendung des Inhalts von MCU (hier atmega16) fuer die
## Compiler- und Assembler-Parameter
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)
[...]

[...]
## Aufruf des Compilers:
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]
$(OBJDIR)/%.o : %.c
@echo
@echo $(MSG_COMPILING) $<
$(CC) -c $(ALL_CFLAGS) $< -o $@
[...]
</pre>

Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:

<c>
// avr/io.h
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)
[...]
#if defined (__AVR_AT94K__)
# include <avr/ioat94k.h>
// [...]
#elif defined (__AVR_ATmega16__)
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:
# include <avr/iom16.h>
// [...]
#else
# if !defined(__COMPILING_AVR_LIBC__)
# warning "device type not defined"
# endif
#endif
</c>

== Schreiben in Register ==

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.

Beispiel:

<c>
#include <avr/io.h>

...

int main(void)
{
/* Setzt das Richtungsregister des Ports A auf 0xff
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */
DDRA = 0xff;

/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */
PORTA = 0x03;
...

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);
}
</c>

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.

Der gcc C-Compiler (genauer der Präprozessor) unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.B. DDRB = 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.

=== Verändern von Registerinhalten ===

Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen.

<c>
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht
</c>

Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten.

Beispiel:
<c>
#include <avr/io.h>
...
#define MEINBIT 2
...
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */
</c>

Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.

Beispiel:
<c>
#include <avr/io.h>
...
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */
PORTA |= (1<<PA0) | (1<<PA3); /* Interne Pull-Up fuer beide einschalten */
</c>

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.

Siehe auch:
* [[Bitmanipulation]]
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers

== Lesen aus Registern ==

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.

Beispiel:

<c>
#include <avr/io.h>
#include <stdint.h>

uint8_t foo;

//...

int main(void)
{
/* kopiert den Status der Eingabepins an PortB
in die Variable foo: */
foo = PINB;
//...
}
</c>

Die 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:

<c>
#define MEINBIT0 0
#define MEINBIT2 2

uint8_t i;

extern test1();

// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist
i = PINA; // Inhalt in Arbeitsvariable
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (logisches und)
// falls das Bit gesetzt war, hat i den Inhalt 1
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)?
test1() // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen
}
// verkürzt:
if ( ( PINA & 0x01 ) != 0 ) {
test1();
}
// nochmals verkürzt:
if ( PINA & 0x01 ) {
test1();
}
// mit definierter Bitnummer:
if ( PINA & ( 1 << MEINBIT0 ) ) {
test(1);
}

// Funktion aufrufen, wenn Bit 0 oder Bit 2 gesetzt ist
if ( PINA & 0x05 ) {
test1(); // Vergleich <> 0 (wahr), also muss Bit 0 oder 2 gesetzt sein
}
// mit definierten Bitnummern:
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt
test1();
}

// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist
i = PINA; // einlesen in temporäre Variable
i = i & 0x01; // maskieren von B
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist
test2();
}
// analog mit !-Operator (not)
if ( !i ) {
test2();
}
// nochmals verkürzt:
if ( !( PINA & 0x01 ) ) {
test2();
}
</c>

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 Macros "nachgerüstet" werden).

;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, 4 für Bit2 etc.

;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.

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]].

=== Warten auf einen bestimmten Zustand ===

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).

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.

<c>
#include <avr/io.h>
...

/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */

#define WARTEPIN PINA
#define WARTEBIT PA2

// mit der avr-libc Funktion:
loop_until_bit_is_set(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// _nicht_ ungleich 0 (also 0) ist.
while ( !(WARTEPIN & (1 << WARTEBIT)) ) ;
...
</c>

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.

<c>
#include <avr/io.h>
...

/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */
#define WARTEPIN PINB
#define WARTEBIT PB4

// avr-libc-Funktion:
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// gesetzt (1) ist
while ( WARTEPIN & (1<<WARTEBIT) ) ;
...
</c>

Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers
* [[Bitmanipulation]]

= Zugriff auf IO-Ports =

Alle Ports der AVR-Controller werden über Register gesteuert. Dazu sind
jedem Port 3 Register zugeordnet:

{| border="1"
|-
| '''DDRx'''
| Datenrichtungsregister für Port'''x'''.
'''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.
|-
| '''PINx'''
| Eingangsadresse für Port'''x'''.
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.
|-
| '''PORTx'''
| Datenregister für Port'''x'''.
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).
|}

Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern
(GPIO - General Purpose Input/Output). 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.

== Datenrichtung bestimmen ==

Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.

Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang
verwendet werden, muss das entsprechende Bit gelöscht sein.

Beispiel:
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

+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
7 6 5 4 3 2 1 0

In C liest sich das dann so:

<c>
// in io.h wird u.a. DDRB definiert:
#include <avr/io.h>

...

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);

...
</c>

Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:

<c>
// Alle Pins des Ports B als Ausgang definieren:
DDRB = 0xff;
// Pin0 wieder auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~( 1 << DDB0 );
// Pin 3 und 4 auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~( ( 1 << DDB3 ) | ( 1<<DDB4) );
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
DDRB |= ( 1 << DDB0) | ( 1 << DDB3 );
// Alle Pins auf Eingang:
DDRB = 0x00;
</c>

== Vordefinierte Bitnummern für I/O-Register ==

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):

<c>
...
/* PORTC */
#define PC7 7
#define PC6 6
#define PC5 5
#define PC4 4
#define PC3 3
#define PC2 2
#define PC1 1
#define PC0 0

/* DDRC */
#define DDC7 7
#define DDC6 6
#define DDC5 5
#define DDC4 4
#define DDC3 3
#define DDC2 2
#define DDC1 1
#define DDC0 0

/* PINC */
#define PINC7 7
#define PINC6 6
#define PINC5 5
#define PINC4 4
#define PINC3 3
#define PINC2 2
#define PINC1 1
#define PINC0 0
</c>

== Digitale Signale ==

Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.

== Ausgänge ==
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.

Mit dem Befehl
<c>
#include <avr/io.h>
...
PORTB = 0x04; /* besser PORTB=(1<<PB2) */
</c>
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).

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:

<c>
#include <avr/io.h>
...
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */
/* vereinfacht durch Nutzung des |= Operators : */
PORTB |= (1<<PB2);

/* auch mehrere "gleichzeitig": */
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */
</c>

"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:

<c>
#include <avr/io.h>
...
PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */
</c>

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.

''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:''

Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:
* zuerst die Bits im PORTx-Register setzen
* anschließend die Datenrichtung auf Ausgang stellen

Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert ware:
* setze PORTx: interner Pull-Up aktiv
* setze DDRx: Ausgang ("high")

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''.

== Eingänge (Wie kommen Signale in den µC) ==

Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.

=== Signalkopplung ===

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.

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.

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.

Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.

<font color="#FF0000">Dabei ist wichtig, zur Abfrage der Eingänge '''nicht''' etwa Portregister '''PORTx''' zu verwenden, '''sondern''' Eingangsregister '''PINx'''. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".</font> (Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände.)

Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:

<c>
#include <avr/io.h>
#include <stdint.h>
...
uint8_t bPortD;
...
bPortD = PIND;
...
</c>

Mit den C-Bitoperationen kann man den Status der Bits abfragen.

<c>
#include <avr/io.h>
...
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */
if ( PINC & (1<<PINC1) ) {
/* Aktion */
}

/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */
if ( !(PINB & (1<<PINB2)) ) {
/* Aktion */
}
...
</c>

=== Tasten und Schalter ===

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''):

{| border="1"
|-
| '''Active Low'''
| '''Active High'''
|-
| [[Image:Active Low.gif]]
| [[Image:Active High.gif]]
|-
| 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.

Der Widerstandswert des Pull-Up Widerstands 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 haben sogar an den meisten Pins softwaremäßig zuschaltbare interne Pull-Up Widerstände, welche wir natürlich auch verwenden können.

| 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.
|}

==== Pull-Up Widerstände aktivieren ====

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.

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.

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.

<c>
#include <avr/io.h>
...
DDRD = 0x00; /* alle Pins von Port D als Eingang */
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */
...
DDRC &= ~(1<<DDC7); /* Pin PC7 als Eingang */
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */
</c>

==== (Tasten-)Entprellung ====

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.

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.

<c>
#include <avr/io.h>
#include <inttypes.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* bei alter avr-libc: #include <avr/delay.h> */

/* Einfache Funktion zum Entprellen eines Tasters */
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)
{
if ( ! (*port & (1 << pin)) )
{
/* Pin wurde auf Masse gezogen, 100ms warten */
_delay_ms(50); // max. 262.1 ms / F_CPU in MHz
_delay_ms(50);
if ( *port & (1 << pin) )
{
/* Anwender Zeit zum Loslassen des Tasters geben */
_delay_ms(50);
_delay_ms(50);
return 1;
}
}
return 0;
}

int main(void)
{
DDRB &= ~( 1 << PB0 ); /* PIN PB0 auf Eingang (Taster) */
PORTB |= ( 1 << PB0 ); /* Pullup-Widerstand aktivieren */
...
if (debounce(&PINB, PB0)) /* Falls Taster an PIN PB0 gedrueckt.. */
PORTD = PIND ^ ( 1 << PD7 ); /* ..LED an Port PD7 an-
bzw. ausschalten */
...
}
</c>

Bei diesem Beispiel 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).

Zum Thema Entprellen siehe auch:
* Artikel [[Entprellung]]

== Analog ==

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.

== 16-Bit Portregister (ADC, ICR1, OCR1, TCNT1, UBRR) ==

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.

<c>
#include <avr/io.h>
#include <stdint.h>
...
uint16_t foo;

foo=ADC; /* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */
</c>

Falls benö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.

<c>
#include <avr/io.h>
#include <stdint.h>
#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

typedef union {
uint16_t i16;
struct {
uint8_t i8l;
uint8_t i8h;
};
} convert16to8;

...
convert16to8 baud;
baud.i16 = F_CPU / (UART_BAUD_RATE * 16L) -1;
UBRRH = baud.i8h;
UBRRL = baud.i8l;
...

/*alternativ:*/
#include <inttypes.h>

uint16_t wFoo16;
uint8_t bFooLow, bFooHigh;

...

wFoo16 = 0xAA55; /* zu "zerlegende" 16Bit-Integer */
bFooHigh = (uint8_t)(wFoo16 >> 8); /* MS-Byte */
bFooLow = (uint8_t)(wFoo16); /* LS-Byte */
...
#define us0(Data) ((unsigned char *)(&Data))
#define us1(Data) ((unsigned char *)((&Data)+1))
bFooHigh = us1(wFoo16);
bFoolow = us0(wFoo16);
...
</c>

Bei einigen AVR-Typen (z.B. ATmega8) 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ächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3'' und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''.

Bei einigen 16-bit Registern (insbesondere die der 16-bit Timer) erfolgen Schreibzugriffe über das sogenannte ''temporary Register''. Die Reihenfolge der Zugriffe bestimmt, wann der Wert tatsächlich ins Register geschrieben wird. Typisch wird erst das High-Byte beschrieben (xxxH) und intern im temporary Register zwischengespeichert. Nachdem das Low-Byte (xxxL) geschrieben wurde, setzt der Controller mit diesem und dem im temporary Register zwischengespeicherten Wert für das High-Byte das 16-bit Register. Dabei ist zu beachten, dass intern nur ein temporary Register verfügbar ist, welches in Interruptroutinen mglw. mit einem anderen Wert überschrieben wird, wenn dort ebenfalls 16-bit Register beschrieben werden. avr-gcc/avr-libc berücksichtigen die korrekte Reihenfolge automatisch, wenn die Register mit ihrem "16-bit Label" (ohne H bzw. L) angesprochen werden, dabei ist der Schutz des temporary Registers vor Überschreiben durch Interruptroutinen dennoch zu beachten (im Zweifel beim Schreibzugriff die Interrupts kurzzeitig global deaktivieren).

Im Umgang mit 16-Bit Registern siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8
* Datenblatt Abschnitt ''Accessing 16-bit Registers''

== IO-Register als Parameter und Variablen ==

Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:

<c>
uint8_t key_pressed(const volatile uint8_t *inputreg, uint8_t inputbit)
{
static uint8_t last_state = 0;

if ( last_state == ( *inputreg & (1<<inputbit) ) ) {
return 0; /* keine Änderung */
}

/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */
_delay_ms(20);

/* Zustand für nächsten Aufruf merken: */
last_state = ( *inputreg & (1<<inputbit) );

/* und den entprellten Tastendruck zurückgeben: */
return ( *inputreg & (1<<inputbit) );
}

/* Beispiel für einen Funktionsaufruf: */

#include <avr/io.h>

uint8_t i;

//...
i = key_pressed( &PINB, PB1 );
//...
</c>

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.

Im Übrigen können mit volatile gekennzeichnete Variablen auch als const deklariert werden, um sicherzustellen, dass sie nur noch von der Hardware änderbar sind.

= Der UART =

== Allgemeines zum UART ==

Über den [[UART]] kann ein AVR leicht mit einer [[RS-232]]-Schnittstelle eines PC oder sonstiger Geräte mit "serieller Schnittstelle" verbunden werden.

Mögliche Anwendungen des UART:

* 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 Bray-Terminal, [http://www.mikrocontroller.net/forum/read-8-155472.html#new 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.
* "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])
* Übertragen von gespeicherten Werten: z.B. bei einem Datenlogger
* Anschluss von Geräten mit serieller Schnittstelle (z.B. (Funk-)Modems, Mobiltelefone, Drucker, Sensoren, "intelligente" LC-Displays, GPS-Empfänger).
* "Feldbusse" auf RS485/RS422-Basis mittels entsprechenden Bustreiberbausteinen (z.B. MAX485)
* DMX, Midi etc.
* LIN-Bus ('''L'''ocal '''I'''nterconnect '''N'''etwork): Preiswerte Sensoren/Aktoren in der Automobiltechnik und darüber hinaus

Einige AVR-Controller haben ein bis zwei vollduplexfähigen UART ('''U'''niversal '''A'''synchronous '''R'''eceiver and '''T'''ransmitter) schon eingebaut ("Hardware-UART").
Übrigens: Vollduplex heißt nichts anderes, als dass der Baustein gleichzeitig senden und empfangen kann.

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.

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.

{| border="1"
|-
| '''UCR   '''
| '''U'''ART '''C'''ontrol '''R'''egister.<br />
In diesem Register stellen wir ein, wie wir den UART verwenden möchten.<br />
Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''RXCIE'''
| align="center" | '''TXCIE'''
| align="center" | '''UDRIE'''
| align="center" | '''RXEN'''
| align="center" | '''TXEN'''
| align="center" | '''CHR9'''
| align="center" | '''RXB8'''
| align="center" | '''TXB8'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 0
|}

'''RXCIE''' ('''RX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
: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.

'''TXCIE''' ('''TX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
: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.

'''UDRIE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty '''I'''nterrupt '''E'''nable)
: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.

'''RXEN''' ('''R'''eceiver '''E'''nable)
: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.

'''TXEN''' ('''T'''ransmitter '''E'''nable)
: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.

'''CHR9''' (9 Bit Characters)
: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:
:1 Startbit + 8 Datenbits + 1 Stopbit + 1 Paritätsbit = 11 Bits

'''RXB8''' (Receive Data Bit 8)
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann enthält dieses Bit das 9. Datenbit eines empfangenen Zeichens.

'''TXB8''' (Transmit Data Bit 8)
: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.

|-
| '''USR   '''
| '''U'''ART '''S'''tatus '''R'''egister.<br />
Hier teilt uns der UART mit, was er gerade so macht.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''RXC'''
| align="center" | '''TXC'''
| align="center" | '''UDRE'''
| align="center" | '''FE'''
| align="center" | '''OR'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''RXC''' (UART Receive Complete)
:Dieses Bit wird vom AVR gesetzt, wenn ein empfangenes Zeichen vom Empfangs-Schieberegister in das Empfangs-Datenregister transferiert wurde.
: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.

'''TXC''' (UART Transmit Complete)
: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.
: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.
:Das Bit wird nur dann automatisch gelöscht, wenn der entsprechende Interrupthandler aufgerufen wird, ansonsten müssen wir das Bit selber löschen.

'''UDRE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty)
: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.
:Das Bit wird automatisch gelöscht, wenn ein Zeichen in das Sendedatenregister geschrieben wird.

'''FE''' ('''F'''raming '''E'''rror)
:Dieses Bit wird vom AVR gesetzt, wenn der UART einen Zeichenrahmenfehler detektiert, d.h. wenn das Stopbit eines empfangenen Zeichens 0 ist.
:Das Bit wird automatisch gelöscht, wenn das Stopbit des empfangenen Zeichens 1 ist.

'''OR''' ('''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.
:Das nachfolgende Zeichen wird verworfen.
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.

|-
| '''UDR'''
| '''U'''ART '''D'''ata '''R'''egister.<br />
Hier werden Daten zwischen UART und CPU übertragen. Da der UART im
Vollduplexbetrieb gleichzeitig empfangen und senden kann, handelt es sich
hier physikalisch um 2 Register, die aber über die gleiche I/O-Adresse
angesprochen werden. Je nachdem, ob ein Lese- oder ein Schreibzugriff auf
den UART erfolgt wird automatisch das richtige UDR angesprochen.
|-
| '''UBRR'''
| '''U'''ART '''B'''aud '''R'''ate '''R'''egister.<br />
In diesem Register müssen wir dem UART mitteilen, wie schnell wir gerne
kommunizieren möchten. Der Wert, der in dieses Register geschrieben
werden muss, errechnet sich nach folgender Formel:

<math>
\begin{matrix}
\mathrm{UBRR} = \frac{\mathrm{Taktfrequenz}}{\mathrm{Baudrate} \cdot 16} - 1
\end{matrix}
</math>

Es sind Baudraten bis zu 115200 Baud und höher möglich.
|}

== Die Hardware ==

Der UART basiert auf normalem TTL-Pegel mit 0V (LOW) und 5V (HIGH). Die
Schnittstellenspezifikation für RS-232 definiert jedoch -3V ... -12V (LOW) und
+3 ... +12V (HIGH). Zudem muss der Signalaustausch zwischen AVR und
Partnergerät invertiert werden. Für die Anpassung der Pegel und das
Invertieren der Signale gibt es fertige Schnittstellenbausteine. Der bekannteste
davon ist wohl der MAX232.


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]].

== UART initialisieren ==

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.

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:

<c>
UCR |= (1<<TXEN);
</c>

Neuere AVRs mit USART haben mehrere Konfigurationsregister und erfordern eine etwas andere Konfiguration. Für einen ATmega16 z.B.:

<c>
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC |= (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0); // Asynchron 8N1
</c>

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.

<c>
/* UART-Init beim AT90S2313 */

#ifndef F_CPU
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann
F_CPU im Makefile definiert werden, eine nochmalige Definition
hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
#ifndef/#endif

Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio
verwendet wird und dort eine andere, nicht zur Hardware passende
Taktrate eingestellt ist: Dann wird die folgende Definition
nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?)
von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
noch nicht definiert: */
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
#define F_CPU 4000000UL // Systemtakt in Hz - Definition als unsigned long beachten >> Ohne ergeben Fehler in der Berechnung
#endif

#define BAUD 9600UL // Baudrate

// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif

int main(void)
{
UCR |= (1<<TXEN);
UBRR = UBRR_VAL;
//...
}
</c>

Wieder für den Mega16 mit zwei Registern für die Baudrateneinstellung eine etwas andere Programmierung. Wichtig ist, dass UBRRH '''vor''' UBRRL geschrieben wird.

<c>
/* USART-Init beim ATmega16 */

int main(void)
{
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
}
</c>

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.

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.

Siehe auch:
* [http://www.wormfood.net/avrbaudcalc.php WormFood's AVR Baud Rate Calculator] online.

== Senden mit dem UART ==

=== Senden einzelner Zeichen ===

Um nun ein Zeichen auf die Schnittstelle auszugeben, müssen wir dasselbe
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).

<c>
// bei AVR mit einem UART ("classic AVR" z.B. AT90S8515)
while (!(USR & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */

/** ODER **/

// bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */
</c>

=== Schreiben einer Zeichenkette (String) ===

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.

<c>
// putc fuer AVR mit einem UART (z.B. AT90S8515)
int uart_putc(unsigned char c)
{
while(!(USR & (1 << UDRE))) /* warte, bis UDR bereit */
{
}

UDR = c; /* sende Zeichen */
return 0;
}

/** ODER **/

// bei neueren AVRs andere Bezeichnung fuer die Statusregister, hier ATmega16:
int uart_putc(unsigned char c)
{
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = c; /* sende Zeichen */
return 0;
}

/* puts ist unabhaengig vom Controllertyp */
void uart_puts (char *s)
{
while (*s)
{ /* so lange *s != '\0' also ungleich dem "String-Endezeichen" */
uart_putc(*s);
s++;
}
}
</c>

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.

=== Schreiben von Variableninhalten ===

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.

<c>
//...

// hier uart_putc (s.o.)

// Ausgabe von 0123456789
char c;

for (uint8_t i=0; i<=9; ++i) {
c = i + '0';
uart_putc( c );
// verkuerzt: uart_putc( i + '0' );
}
</c>

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.

<c>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

int main(void)
{
char s[7];
int16_t i = -12345;

uart_init();

itoa( i, s, 10 ); // 10 fuer radix -> Dezimalsystem
uart_puts( s );

// da itoa einen Zeiger auf den Beginn von s zurueckgibt verkuerzt auch:
uart_puts( itoa( i, s, 10 ) );

while (1) {
;
}

return 0; // never reached
}
</c>

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.

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.)

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]]

<c>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

/* lt. avr-libc Dokumentation:
char* dtostrf(
double __val,
char __width,
char __prec,
char * __s
)
*/

int main(void)
{
// Pufferspeicher ausreichend groß
// evtl. Vorzeichen + width + Endezeichen:
char s[8];
float f = -12.345;

uart_init();

dtostrf( f, 6, 3, s );
uart_puts( s );

// verkürzt: uart_puts( dtostrf( f, 7, 3, s ) );

while (1) {
;
}

return 0; // never reached
}
</c>

== Empfangen ==
=== einzelne Zeichen empfangen ===

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:

<c>
#include <inttypes.h>
#include <avr/io.h>

/* Zusaetzlich zur Baudrateneinstellung und der weiteren Initialisierung: */
void Usart_EnableRX(void)
{
UCSRB |= ( 1 << RXEN );
}

/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}
</c>

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]]  und Quellcodekomponenten (z.B. UART-Library von P. Fleury, procyon-avrlib und einige in der "Academy" von avrfreaks.net).

siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html Dokumenation der avr-libc/stdlib.h]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Die_Nutzung_von_printf Die Nutzung von printf]
* [http://homepage.hispeed.ch/peterfleury/ Peter Fleurys] UART-Bibiliothek fuer avr-gcc/avr-libc


TODO: 9bit

=== Empfang von Zeichenketten (Strings) ===

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.

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.

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.

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.

<C>
/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}

void uart_gets( char* Buffer, uint8_t MaxLen )
{
uint8_t NextChar;
uint8_t StringLen = 0;

NextChar = uart_getc(); // Warte auf und empfange das nächste Zeichen

// Sammle solange Zeichen, bis:
// * entweder das String Ende Zeichen kam
// * oder das aufnehmende Array voll ist
while( NextChar != '\n' && StringLen < MaxLen - 1 ) {
*Buffer++ = NextChar;
StringLen++;
NextChar = uart_getc();
}

// Noch ein '\0' anhängen um einen Standard
// C-String daraus zu machen
*Buffer = '\0';
}
</C>

Beim Aufruf ist darauf zu achten, dass das empfangende Array auch mit einer
vernünftigen Größe definiert wird.

<C>
char Line[40]; // String mit maximal 39 zeichen

uart_gets( Line, sizeof( Line ) );
</C>

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:

<C>
int Line[40]; // Array vom Typ int

uart_gets( Line, sizeof( Line ) / sizeof( Line[0] ) );
</C>

==Interruptbetrieb==

Beim ATMEGA8 muss das RXCIE Bit im Register UCSRB gesetzt werden, damit ein Interrupt ausgelöst werden kann.
Der Interrupt wird immer ausgelöst, wenn Daten erfolgreich empfangen wurden.

Zusätzlich braucht man die Routine:

<c>
ISR (USART_RXC_vect) {
//irgendein Code
}
</c>

natürlich muss "Global Interrupt Enable" Aktiviert sein.
!! Nur getestet beim ATMEGA8 !!

[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.]

* Unterschied Polling-Betrieb (bisher, oben) und Interrupt-Betrieb
* Empfangen (Receive)
** 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)
** 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
* FIFO-Puffer, Ringpuffer
* Senden (Transmit)
** Variante "UART Data Register Empty" (UDRE)
** Variante "UART Transmit Complete" (TXC)
* Fertige UART-Bibliotheken (->Fleury, ->Procyon)
* Literatur:
** 1/ [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48188 avrfreaks.net Tutorial] inkl. Diskussion (engl.)
** 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?]
** 3/ [[Interrupt]] und atomarer Datenzugriff

==Software-UART==

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:
* 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]).
* 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)

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").

==Handshaking==
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.
===Hardwarehandshake (RTS/CTS)===
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.

===Softwarehandshake (XON/XOFF)===
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 />
* '''XOFF''' Aufforderung das Senden einzustellen
* '''XON''' Gegenstelle darf wieder senden

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.

==Fehlersuche==
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.

Eine Checkliste zum Aufspüren solcher Fehler findet sich [[AVR_Checkliste#UART.2FUSART|hier]].

= Analoge Ein- und Ausgabe =

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 analogen 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.

Es existieren keine AVRs mit eingebautem Digital-Analog-Konverter (DAC). Diese Funktion muss durch externe Komponenten nachgebildet werden (z.B. PWM und "Glättung").

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.

== AC (Analog Comparator) ==

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 Comperator 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>

ACSR (0x28) - Analog Comparator Status Register<BR>
{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''ACD'''
| align="center" | '''ACBG'''
| align="center" | '''ACO'''
| align="center" | '''ACI'''
| align="center" | '''ACIE'''
| align="center" | '''ACIC'''
| align="center" | '''ACIS1'''
| align="center" | '''ACIS0'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | n/a
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

<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>
Ergebnis: <BR>IST < SOLL --> 1<BR>
IST > SOLL --> 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) ==

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.

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
die Werte 0V, 0.625V, 1.25, 1.875V, 2.5V, 3.125V, 3.75, 4.375, 5V
daherkommen, siehe dazu folgende Tabelle:

<div align="center">
{| border="1"
|-
| align="center" | '''Eingangsspannung am ADC'''
| align="center" | '''Entsprechender Messwert'''
|-
| align="center" | 0...<0.625V
| align="center" | 0
|-
| align="center" | 0.625...<1.25V
| align="center" | 1
|-
| align="center" | 1.25...<1.875V
| align="center" | 2
|-
| align="center" | 1.875...<2.5V
| align="center" | 3
|-
| align="center" | 2.5...<3.125V
| align="center" | 4
|-
| align="center" | 3.125...<3.75V
| align="center" | 5
|-
| align="center" | 3.75...<4.375V
| align="center" | 6
|-
| align="center" | 4.375...5V
| align="center" | 7
|}
</div>

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.

=== Der interne ADC im AVR ===

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.

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.

Das Ergebnis der Analog-Digital-Wandlung wird auf eine Referenzspannung bezogen. Aktuelle AVRs bieten drei Möglichkeiten zur Wahl dieser Spannung:

* 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.

* 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.

* Die '''interne''' Referenzspannung wird auf '''Vcc''' bezogen, eine externe Referenzspannung auf '''GND (Masse)'''. Davon unabhängig werden digitalisierte Spannungen '''immer''' auf GND bezogen. Beim ATMEGA8 z.B. ist der Pin AREF über 32kOhm mit GND verbunden, d.h. man muss diese doch extrem niedrige Eingangsimpedanz mit in die Berechnung für einen Spannungsteiler einbeziehen, bzw. kann diesen Widerstand als R2 gleich mit benutzen. Formel für Spannungsteiler: Udiv = U / ((R1 + R2) / R2)

Bei Nutzung von Vcc 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.

Der '''ADC''' kann in zwei verschiedenen Betriebsarten verwendet werden:

; Einfache Wandlung (Single Conversion) : In dieser Betriebsart wird der Wandler bei Bedarf vom Programm angestoßen für jeweils eine Messung.

; Frei laufend (Free Running) : In dieser Betriebsart erfasst der Wandler permanent die anliegende Spannung und schreibt diese in das '''ADC Data Register'''.

==== Die Register des ADC ====

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).

{| border="1"
|-
| '''ADCSRA   '''
| '''ADC''' '''C'''ontrol and '''S'''tatus '''R'''egister A.<br />
In diesem Register stellen wir ein, wie wir den '''ADC''' verwenden möchten.<br />
Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''ADEN'''
| align="center" | '''ADSC'''
| align="center" | '''ADFR'''
| align="center" | '''ADIF'''
| align="center" | '''ADIE'''
| align="center" | '''ADPS2'''
| align="center" | '''ADPS1'''
| align="center" | '''ADPS0'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''ADEN''' ('''AD'''C '''En'''able)
: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.

'''ADSC''' ('''AD'''C '''S'''tart '''C'''onversion)
:Mit diesem Bit wird ein Messvorgang gestartet. In der frei laufenden Betriebsart muss das Bit gesetzt werden, um die kontinuierliche Messung zu aktivieren.
: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.
: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.

'''ADFR''' ('''AD'''C '''F'''ree '''R'''un select)
:Mit diesem Bit wird die Betriebsart eingestellt.
: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.

'''ADIF''' ('''AD'''C '''I'''nterrupt '''F'''lag)
: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.
:Wenn das '''ADIE''' Bit sowie das '''I-Bit''' im AVR '''Statusregister''' gesetzt ist, wird der '''ADC Interrupt''' ausgelöst und die Interrupt-Behandlungsroutine aufgerufen.
: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.

'''ADIE''' ('''AD'''C '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist und ebenso das ''' I-Bit''' im Statusregister '''SREG''', dann wird der ''' ADC-Interrupt''' aktiviert.

'''ADPS2...ADPS0''' ('''AD'''C '''P'''rescaler '''S'''elect Bits)
:Diese Bits bestimmen den Teilungsfaktor zwischen der Taktfrequenz und dem Eingangstakt des '''ADC'''.
: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.
:Der Vorteiler muss also so eingestellt werden, dass die CPU-Taktfrequenz dividiert durch den Teilungsfaktor einen Wert zwischen 50-200kHz ergibt.
:Bei einer CPU-Taktfrequenz von 4MHz beispielsweise rechnen wir

:<math>
\begin{matrix}
TF_{min}=\frac{CLK}{200\,\mathrm{kHz}}=\frac{4000000}{200000}=\mathbf{20}
\\
\\
TF_{max}=\frac{CLK}{50\,\mathrm{kHz}}=\frac{4000000}{50000}=\mathbf{80}
\end{matrix}
</math>

:Somit kann hier der Teilungsfaktor 32 oder 64 verwendet werden. Im Interesse der schnelleren Wandlungszeit werden wir hier den Faktor 32 einstellen.
<dl><dd>
{| style="" border="1"
|-
| align="center" | '''ADPS2'''
| align="center" | '''ADPS1'''
| align="center" | '''ADPS0'''
| align="center" | '''Teilungsfaktor'''
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 2
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 2
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 4
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | 8
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 16
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | 32
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | 64
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | 128
|}
</dd></dl>
|-
| '''ADCL'''<br />
'''ADCH'''
| '''ADC ''' Data Register<br />
Wenn eine Umwandlung abgeschlossen ist, befindet sich der gemessene Wert in
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'''.
Der effektive Messwert ergibt sich dann zu:

<c>
x = ADCL; // mit uint16_t x
x += (ADCH<<8); // in zwei Zeilen (LSB/MSB-Reihenfolge und
// C-Operatorpriorität sichergestellt)
</c>

oder

<c>
x = ADCW; // je nach AVR auch x = ADC (siehe avr/ioxxx.h)
</c>

|-
| '''ADMUX  '''
| '''AD'''C '''Mu'''ltiple'''x'''er Select Register<br />
Mit diesem Register wird der zu messende Kanal ausgewählt. Beim 90S8535
kann jeder Pin von Port A als '''ADC'''-Eingang verwendet werden (=8 Kanäle).<br />
Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''REFS1'''
| align="center" | '''REFS0'''
| align="center" | '''ADLAR'''
| align="center" | '''MUX4'''
| align="center" | '''MUX3'''
| align="center" | '''MUX2'''
| align="center" | '''MUX1'''
| align="center" | '''MUX0'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''REFS1...REFS0''' ('''Ref'''erence'''S'''election Bits)
:Mit diesen Bits kann die Referenzspannung eingestellt werden:
<dl><dd>
{| style="" border="1"
|-
| align="center" | '''REFS1'''
| align="center" | '''REFS0'''
| align="center" | '''Referenzspanung'''
|-
| align="center" | 0
| align="center" | 0
| align="center" | Externes AREF
|-
| align="center" | 0
| align="center" | 1
| align="center" | AVCC als Referenz
|-
| align="center" | 1
| align="center" | 0
| align="center" | Reserviert
|-
| align="center" | 1
| align="center" | 1
| align="center" | Interne 2,56 Volt
|}
</dd></dl>

'''ADLAR''' ('''ADC ''' '''L'''eft '''A'''djust '''R'''esult)
: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 rechtsündig. Eine Änderung in diesem Bit beeinflusst das Ergebnis sofort, ganz egal ob bereits eine Wandlung läuft.

'''MUX4...MUX0'''
: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.
: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.

: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.
|}

==== Aktivieren des ADC ====

Um den ''' ADC''' zu aktivieren, müssen wir das '''ADEN'''-Bit im '''ADCSR'''-Register
setzen. Im gleichen Schritt legen wir auch gleich die Betriebsart fest.

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.

<c>
uint16_t ReadChannel(uint8_t mux)
{
uint8_t i;
uint16_t result;

ADMUX = mux; // Kanal waehlen
ADMUX |= (1<<REFS1) | (1<<REFS0); // interne Referenzspannung nutzen

ADCSRA = (1<<ADEN) | (1<<ADPS1) | (1<<ADPS0); // Frequenzvorteiler
// setzen auf 8 (1) und ADC aktivieren (1)

/* nach Aktivieren des ADC wird ein "Dummy-Readout" empfohlen, man liest
also einen Wert und verwirft diesen, um den ADC "warmlaufen zu lassen" */
ADCSRA |= (1<<ADSC); // eine ADC-Wandlung
while ( ADCSRA & (1<<ADSC) ) {
; // auf Abschluss der Konvertierung warten
}
result = ADCW; // ADCW muss einmal gelesen werden,
// sonst wird Ergebnis der nächsten Wandlung
// nicht übernommen.

/* Eigentliche Messung - Mittelwert aus 4 aufeinanderfolgenden Wandlungen */
result = 0;
for( i=0; i<4; i++ )
{
ADCSRA |= (1<<ADSC); // eine Wandlung "single conversion"
while ( ADCSRA & (1<<ADSC) ) {
; // auf Abschluss der Konvertierung warten
}
result += ADCW; // Wandlungsergebnisse aufaddieren
}
ADCSRA &= ~(1<<ADEN); // ADC deaktivieren (2)

result /= 4; // Summe durch vier teilen = arithm. Mittelwert

return result;
}

...

/* Beispielaufrufe: */

void foo(void)
{
uint16_t adcval;

adcval = ReadChannel(0); /* MUX-Bits auf 0b0000 -> Channel 0 */
...
adcval = ReadChannel(2); /* MUX-Bits auf 0b0010 -> Channel 2 */
...
}

</c>

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.



=== Analog-Digital-Wandlung ohne internen ADC ===

==== Messen eines Widerstandes ====

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.

[[Image:Poti.gif]]

Wird der Portpin des Controllers auf Ausgang konfiguriert (im Beispiel ''DDRD |= (1<<PD2)'') und dieser Ausgang auf Logisch 1 ("High", ''PORTD |= (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).

Nach einer gewissen Zeit ist der Kondensator entladen und der Portpin wird als Eingang konfiguriert (''DDRD &= ~(1<<PD2); PORTD &= ~(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.

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.



==== ADC über Komparator ====

Es gibt einen weiteren Weg, eine analoge Spannung mit Hilfe des
Komparators, welcher in fast jedem AVR integriert ist, zu messen. Siehe dazu
auch die Application Note AVR400 von Atmel.

Dabei wird das zu messende Signal auf den invertierenden Eingang
des Komparators geführt. Zusätzlich wird ein Referenzsignal an den nicht
invertierenden Eingang des Komparators angeschlossen. Das Referenzsignal wird
hier auch wieder über ein RC-Glied erzeugt, allerdings mit festen Werten für R
und C.

[[Image:ADC ueber Komparator.gif]]

Das Prinzip der Messung ist nun dem vorhergehenden recht
ähnlich. Durch Anlegen eines LOW-Pegels an Pin 2 wird der Kondensator zuerst
einmal entladen. Auch hier muss darauf geachtet werden, dass der Entladevorgang
genügend lang dauert.<br />
Nun wird Pin 2 auf HIGH gelegt. Der Kondensator wird geladen. Wenn die Spannung
über dem Kondensator die am Eingangspin anliegende Spannung erreicht hat
schaltet der Komparator durch. Die Zeit, welche benötigt wird, um den
Kondensator zu laden kann nun auch wieder als Maß für die Spannung an Pin 1
herangezogen werden.

Ich habe es mir gespart, diese Schaltung auch aufzubauen und
zwar aus mehreren Gründen:

# 3 Pins notwendig.
# Genauigkeit vergleichbar mit einfacherer Lösung.
# War einfach zu faul.

Der Vorteil dieser Schaltung liegt allerdings darin, dass damit
direkt Spannungen gemessen werden können.

== DAC (Digital Analog Converter) ==

Mit Hilfe eines Digital-Analog-Konverters ('''DAC''') können wir nun auch Analogsignale ausgeben. Es gibt hier mehrere Verfahren. 

=== DAC über mehrere digitale Ausgänge ===

Wenn wir an den Ausgängen des Controllers ein entsprechendes
Widerstandsnetzwerk aufbauen haben wir die Möglichkeit, durch die Ansteuerung
der Ausgänge über den Widerständen einen Addierer aufzubauen, mit dessen
Hilfe wir eine dem Zahlenwert proportionale Spannung erzeugen können. Das
Schaltbild dazu kann etwa so aussehen:

[[Image:DAC R2R.gif]]

Es sollten selbstverständlich möglichst genaue Widerstände verwendet
werden, also nicht unbedingt solche mit einer Toleranz von 10% oder mehr.
Weiterhin empfiehlt es sich, je nach Anwendung den Ausgangsstrom über einen
Operationsverstärker zu verstärken.

=== PWM (Pulsweitenmodulation) ===

Wir kommen nun zu einem Thema, welches in aller Munde ist, aber viele
Anwender verstehen nicht ganz, wie '''[[PWM]]''' eigentlich funktioniert.

Wie wir alle wissen, ist ein Mikrocontroller ein rein digitales Bauteil.
Definieren wir einen Pin als Ausgang, dann können wir diesen Ausgang entweder
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:

[[Image:PWM Theorie 1.gif]]

Diese Rechteckspannung hat nun einen arithmetischen Mittelwert,
der je nach Pulsbreite kleiner oder größer ist.

[[Image:PWM Theorie 2.gif]]

Wenn wir nun diese pulsierende Ausgangsspannung noch über ein RC-Glied filtern/"glätten", dann haben wir schon eine entsprechende Gleichspannung erzeugt.

Mit den AVRs können wir direkt '''PWM'''-Signale erzeugen.
Dazu dient der 16-Bit Zähler, welcher im sogenannten '''PWM'''-Modus betrieben werden kann.

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.

Um den '''PWM'''-Modus zu aktivieren, müssen im Timer/Counter1 Control
Register A '''TCCR1A''' die Pulsweiten-Modulatorbits '''PWM10''' bzw. '''PWM11''' entsprechend nachfolgender Tabelle gesetzt werden:

{| border="1"
|-
| align="center" | '''PWM11'''
| align="center" | '''PWM10'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| PWM-Modus des Timers ist nicht aktiv.
|-
| align="center" | 0
| align="center" | 1
| 8-Bit PWM.
|-
| align="center" | 1
| align="center" | 0
| 9-Bit PWM.
|-
| align="center" | 1
| align="center" | 1
| 10-Bit PWM.
|}

Der Timer/Counter zählt nun permanent von 0 bis zur Obergrenze
und wieder zurück, er wird also als sogenannter Auf-/Ab Zähler betrieben.
Die Obergrenze hängt davon ab, ob wir mit 8, 9 oder 10-Bit PWM arbeiten wollen:

{| border="1"
|-
| align="center" | '''Auflösung'''
| align="center" | '''Obergrenze'''
| '''Frequenz'''
|-
| align="center" | 8
| align="center" | 255
| f<sub>TC1</sub> / 510
|-
| align="center" | 9
| align="center" | 511
| f<sub>TC1</sub> / 1022
|-
| align="center" | 10
| align="center" | 1023
| f<sub>TC1</sub> / 2046
|}

Zusätzlich muss mit den Bits '''COM1A1''' und '''COM1A0''' desselben
Registers die gewünschte Ausgabeart des Signals definiert werden:

{| border="1"
|-
| align="center" | '''COM1A1'''
| align="center" | '''COM1A0'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| Keine Wirkung, Pin wird nicht geschaltet.
|-
| align="center" | 0
| align="center" | 1
| Keine Wirkung, Pin wird nicht geschaltet.
|-
| align="center" | 1
| align="center" | 0
| Nicht invertierende PWM.<br />
Der Ausgangspin wird gelöscht beim Hochzählen und gesetzt beim
Herunterzählen.
|-
| align="center" | 1
| align="center" | 1
| Invertierende PWM.<br />
Der Ausgangspin wird gelöscht beim Herunterzählen und gesetzt beim
Hochzählen.
|}

Der entsprechende Befehl, um beispielsweise den Timer/Counter als
nicht invertierenden 10-Bit PWM zu verwenden, heißt dann:

alte Schreibweise (PWMxx wird nicht mehr akzeptiert)
<c>
TCCR1A = (1<<PWM11)|(1<<PWM10)|(1<<COM1A1);
</c>
neue Schreibweise
<c>
TCCR1A = (1<<WGM11)|(1<<WGM10)|(1<<COM1A1);
</c>

Damit der Timer/Counter überhaupt läuft, müssen wir im Control
Register B '''TCCR1B''' noch den gewünschten Takt (Vorteiler) einstellen und
somit auch die Frequenz des '''PWM'''-Signals bestimmen.

{| border="1"
|-
| align="center" | '''CS12'''
| align="center" | '''CS11'''
| align="center" | '''CS10'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stop. Der Timer/Counter wird gestoppt.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CK
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CK / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CK / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CK / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CK / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin 1, negative Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin 1, positive Flanke
|}

Also um einen Takt von CK / 1024 zu generieren, verwenden wir
folgenden Befehl:

<c>
TCCR1B = (1<<CS12) | (1<<CS10);
</c>

Jetzt muss nur noch der Vergleichswert festgelegt werden. Diesen
schreiben wir in das 16-Bit Timer/Counter Output Compare Register '''OCR1A'''.

<c>
OCR1A = xxx;
</c>

Die folgende Grafik soll den Zusammenhang zwischen dem Vergleichswert und dem generierten '''PWM'''-Signal aufzeigen.

[[Image:PWM Theorie 3.gif]]

[[Image:PWM Theorie 4.gif]]

Ach ja, fast hätte ich's vergessen. Das generierte '''PWM'''-Signal
wird am Output Compare Pin '''OC1''' des Timers ausgegeben und leider können wir
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.

Ein Programm, welches an einem ATMega8 den Fast-PWM Modus verwendet, den Modus 14, könnte so aussehen
<C>
#include <avr/io.h>

int main()
{
// OC1A auf Ausgang
DDRB = (1 << PB1 );

//
// Timer 1 einstellen
//
// Modus 14:
// Fast PWM, Top von ICR1
//
// WGM13 WGM12 WGM11 WGM10
// 1 1 1 0
//
// Timer Vorteiler: 1
// CS12 CS11 CS10
// 0 0 1
//
// Steuerung des Ausgangsport: Set at BOTTOM, Clear at match
// COM1A1 COM1A0
// 1 0

TCCR1A = (1<<COM1A1) | (1<<WGM11);
TCCR1B = (1<<WGM13) | (1<<WGM12) | (1<<CS10);

//
// den Endwert (TOP) für den Zähler setzen
// der Zähler zählt bis zu diesem Wert

ICR1 = 0x6FFF;

//
// der Compare Wert
// Wenn der Zähler diesen Wert erreicht, wird mit
// obiger Konfiguration der OC1A Ausgang abgeschaltet
// Sobald der Zähler wieder bei 0 startet, wird der
// Ausgang wieder auf 1 gesetzt
//
// Durch Verändern dieses Wertes, werden die unterschiedlichen
// PWM Werte eingestellt.

OCR1A = 0x3FFF;

while( 1 )
;
}
</C>

PWM Mode Tabelle aus dem Datenblatt des Atmega 8515:

{| border="1"
|-
| align="center" | '''Mode'''
| align="center" | '''WGM13'''
| align="center" | '''WGM12'''
| align="center" | '''WGM11'''
| align="center" | '''WGM10'''
| align="center" | '''Timer/Counter Mode of Operation'''
| align="center" | '''TOP'''
| align="center" | '''Update of OCR1x at'''
| align="center" | '''TOV1 Flag set on'''
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | Normal
| align="center" | 0xFFFF
| align="center" | Immediate
| align="center" | MAX
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | PWM, Phase Correct, 8-Bit
| align="center" | 0x00FF
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 2
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | PWM, Phase Correct, 9-Bit
| align="center" | 0x01FF
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 3
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | PWM, Phase Correct, 10-Bit
| align="center" | 0x03FF
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 4
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | CTC
| align="center" | OCR1A
| align="center" | Immediate
| align="center" | MAX
|-
| align="center" | 5
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | Fast PWM, 8-Bit
| align="center" | 0x00FF
| align="center" | BOTTOM
| align="center" | TOP
|-

| align="center" | 6
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | Fast PWM, 9-Bit
| align="center" | 0x01FF
| align="center" | BOTTOM
| align="center" | TOP
|-

| align="center" | 7
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | Fast PWM, 10-Bit
| align="center" | 0x03FF
| align="center" | BOTTOM
| align="center" | TOP
|-

| align="center" | 8
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | PWM, Phase an Frequency Correct
| align="center" | ICR1
| align="center" | BOTTOM
| align="center" | BOTTOM
|-
| align="center" | 9
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | PWM, Phase an Frequency Correct
| align="center" | OCR1A
| align="center" | BOTTOM
| align="center" | BOTTOM
|-
| align="center" | 10
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | PWM, Phase Correct
| align="center" | ICR1
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 11
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | PWM, Phase an Frequency Correct
| align="center" | OCR1A
| align="center" | TOP
| align="center" | BOTTOM
|-
| align="center" | 12
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | CTC
| align="center" | ICR1
| align="center" | Immediate
| align="center" | MAX
|-
| align="center" | 13
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | Reserved
| align="center" | -
| align="center" | -
| align="center" | -
|-
| align="center" | 14
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | Fast PWM
| align="center" | ICR1
| align="center" | BOTTOM
| align="center" | TOP
|-
| align="center" | 15
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | Fast PWM
| align="center" | OCR1A
| align="center" | BOTTOM
| align="center" | TOP
|-
|}

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.

= LCD-Ansteuerung =

==Das LCD und sein Controller==

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:

<table width="0">
<tr><th width="50" align="left">Pin #</th><th width="70" align="left">Bezeichnung</th><th align="left">Funktion</th></tr>
<tr><td>'''1'''</td><td>Vss</td><td>GND</td></tr>
<tr><td>'''2'''</td><td>Vcc</td><td>5V</td></tr>
<tr><td>'''3'''</td><td>Vee</td><td>Kontrastspannung (0V bis 5V)</td></tr>
<tr><td>'''4'''</td><td>RS</td><td>Register Select (Befehle/Daten)</td></tr>
<tr><td>'''5'''</td><td>RW</td><td>Read/Write</td></tr>
<tr><td>'''6'''</td><td>E</td><td>Enable</td></tr>
<tr><td>'''7'''</td><td>DB0</td><td>Datenbit 0</td></tr>
<tr><td>'''8'''</td><td>DB1</td><td>Datenbit 1</td></tr>
<tr><td>'''9'''</td><td>DB2</td><td>Datenbit 2</td></tr>
<tr><td>'''10'''</td><td>DB3</td><td>Datenbit 3</td></tr>
<tr><td>'''11'''</td><td>DB4</td><td>Datenbit 4</td></tr>
<tr><td>'''12'''</td><td>DB5</td><td>Datenbit 5</td></tr>
<tr><td>'''13'''</td><td>DB6</td><td>Datenbit 6</td></tr>
<tr><td>'''14'''</td><td>DB7</td><td>Datenbit 7</td></tr>
<tr><td>'''15'''</td><td>A</td><td>LED-Beleuchtung, Anode</td></tr>
<tr><td>'''16'''</td><td>K</td><td>LED-Beleuchtung, Kathode</td></tr>
</table>

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.

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.

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:

[[Bild:LCD_Vee.gif]]

Es gibt zwei verschiedene Möglichkeiten zur Ansteuerung eines solchen Displays: den '''8-bit-''' und den '''4-bit-'''Modus.
* 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.
* 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).

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.

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.

* Ü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.
* '''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.
* 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.

== Anschluss an den Controller ==

Jetzt da wir wissen, welche Anschlüsse das LCDs benötigt, können wir das LCD mit dem Mikrocontroller verbinden:

<table width="0">
<tr><th align="left">Pin #-LCD</th><th align="left">Bezeichnung-LCD</th><th align="left">Pin-µC</th></tr>
<tr><td>'''1'''</td><td>Vss</td><td>GND</td></tr>
<tr><td>'''2'''</td><td>Vcc</td><td>5V</td></tr>
<tr><td>'''3'''</td><td>Vee</td><td>GND oder Poti (siehe oben)</td></tr>
<tr><td>'''4'''</td><td>RS</td><td>PD4 am AVR</td></tr>
<tr><td>'''5'''</td><td>RW</td><td>GND</td></tr>
<tr><td>'''6'''</td><td>E</td><td>PD5 am AVR</td></tr>
<tr><td>'''7'''</td><td>DB0</td><td>offen</td></tr>
<tr><td>'''8'''</td><td>DB1</td><td>offen</td></tr>
<tr><td>'''9'''</td><td>DB2</td><td>offen</td></tr>
<tr><td>'''10'''</td><td>DB3</td><td>offen</td></tr>
<tr><td>'''11'''</td><td>DB4</td><td>PD0 am AVR</td></tr>
<tr><td>'''12'''</td><td>DB5</td><td>PD1 am AVR</td></tr>
<tr><td>'''13'''</td><td>DB6</td><td>PD2 am AVR</td></tr>
<tr><td>'''14'''</td><td>DB7</td><td>PD3 am AVR</td></tr>
</table>

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.

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?

== Programmierung ==
Datei '''lcd-routines.h'''
<c>
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
//
void lcd_data(unsigned char temp1);
void lcd_string(char *data);
void lcd_command(unsigned char temp1);
void lcd_enable(void);
void lcd_init(void);
void lcd_home(void);
void lcd_clear(void);
void set_cursor(uint8_t x, uint8_t y);

// Hier die verwendete Taktfrequenz in Hz eintragen, wichtig!

#define F_CPU 8000000

// LCD Befehle

#define CLEAR_DISPLAY 0x01
#define CURSOR_HOME 0x02

// Pinbelegung für das LCD, an verwendete Pins anpassen

#define LCD_PORT PORTD
#define LCD_DDR DDRD
#define LCD_RS PD4
#define LCD_EN PD5
// DB4 bis DB7 des LCD sind mit PD0 bis PD3 des AVR verbunden
</c>

Datei '''lcd-routines.c''':
<c>
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
//
// Die Pinbelegung ist über defines in lcd-routines.h einstellbar

#include <avr/io.h>
#include "lcd-routines.h"
#include <util/delay.h>

// sendet ein Datenbyte an das LCD

void lcd_data(unsigned char temp1)
{
unsigned char temp2 = temp1;

LCD_PORT |= (1<<LCD_RS); // RS auf 1 setzen

temp1 = temp1 >> 4;
temp1 = temp1 & 0x0F;
LCD_PORT &= 0xF0;
LCD_PORT |= temp1; // setzen
lcd_enable();

temp2 = temp2 & 0x0F;
LCD_PORT &= 0xF0;
LCD_PORT |= temp2; // setzen
lcd_enable();

_delay_us(42);
}

// sendet einen Befehl an das LCD

void lcd_command(unsigned char temp1)
{
unsigned char temp2 = temp1;

LCD_PORT &= ~(1<<LCD_RS); // RS auf 0 setzen

temp1 = temp1 >> 4; // oberes Nibble holen
temp1 = temp1 & 0x0F; // maskieren
LCD_PORT &= 0xF0;
LCD_PORT |= temp1; // setzen
lcd_enable();

temp2 = temp2 & 0x0F; // unteres Nibble holen und maskieren
LCD_PORT &= 0xF0;
LCD_PORT |= temp2; // setzen
lcd_enable();

_delay_us(42);
}

// erzeugt den Enable-Puls
void lcd_enable(void)
{
// Bei Problemen ggf. Pause gemäß Datenblatt des LCD Controllers einfügen
// http://www.mikrocontroller.net/topic/81974#685882
LCD_PORT |= (1<<LCD_EN);
_delay_us(1); // kurze Pause
// Bei Problemen ggf. Pause gemäß Datenblatt des LCD Controllers verlängern
// http://www.mikrocontroller.net/topic/80900
LCD_PORT &= ~(1<<LCD_EN);
}

// Initialisierung:
// Muss ganz am Anfang des Programms aufgerufen werden.

void lcd_init(void)
{
LCD_DDR = LCD_DDR | 0x0F | (1<<LCD_RS) | (1<<LCD_EN); // Port auf Ausgang schalten

// muss 3mal hintereinander gesendet werden zur Initialisierung

_delay_ms(15);
LCD_PORT &= 0xF0;
LCD_PORT |= 0x03;
LCD_PORT &= ~(1<<LCD_RS); // RS auf 0
lcd_enable();

_delay_ms(5);
lcd_enable();

_delay_ms(1);
lcd_enable();
_delay_ms(1);

// 4 Bit Modus aktivieren
LCD_PORT &= 0xF0;
LCD_PORT |= 0x02;
lcd_enable();
_delay_ms(1);

// 4Bit / 2 Zeilen / 5x7
lcd_command(0x28);

// Display ein / Cursor aus / kein Blinken
lcd_command(0x0C);

// inkrement / kein Scrollen
lcd_command(0x06);

lcd_clear();
}

// Sendet den Befehl zur Löschung des Displays

void lcd_clear(void)
{
lcd_command(CLEAR_DISPLAY);
_delay_ms(5);
}

// Sendet den Befehl: Cursor Home

void lcd_home(void)
{
lcd_command(CURSOR_HOME);
_delay_ms(5);
}

// setzt den Cursor in Zeile y (1..4) Spalte x (0..15)

void set_cursor(uint8_t x, uint8_t y)
{
uint8_t tmp;

switch (y) {
case 1: tmp=0x80+0x00+x; break; // 1. Zeile
case 2: tmp=0x80+0x40+x; break; // 2. Zeile
case 3: tmp=0x80+0x10+x; break; // 3. Zeile
case 4: tmp=0x80+0x50+x; break; // 4. Zeile
default: return; // für den Fall einer falschen Zeile
}
lcd_command(tmp);
}

// Schreibt einen String auf das LCD

void lcd_string(char *data)
{
while(*data) {
lcd_data(*data);
data++;
}
}
</c>

Ein Hauptprogramm, welches die Funktionen benutzt, sieht zb. so aus:

<c>
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include "lcd-routines.h"

int main(void)
{
lcd_init();

lcd_data('T');
lcd_data('e');
lcd_data('s');
lcd_data('t');

set_cursor(0,2);

lcd_string("Hello World!");

while(1)
{
}

return 0;
}
</c>

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).

Ein Hauptprogramm, welches eine Variable ausgibt, sieht zb. so aus.
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:

<c>
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include <stdlib.h>
#include "lcd-routines.h"

// Beispiel
int variable = 42;

int main(void)
{
lcd_init();

// Ausgabe des Zeichens dessen ASCII-Code gleich dem Variablenwert ist
// (Im Beispiel entspricht der ASCII-Code 42 dem Zeichen *)
// http://www.code-knacker.de/ascii.htm
lcd_data(variable);

set_cursor(0,2);

// Ausgabe der Variable als Text in dezimaler Schreibweise
{
// ... umwandeln siehe FAQ Artikel bei www.mikrocontroller.net
// WinAVR hat eine itoa()-Funktion, das erfordert obiges #include <stdlib.h>
char Buffer[20]; // in diesem {} lokal
itoa( variable, Buffer, 10 );

// ... ausgeben
lcd_string( Buffer );
}

while(1)
{
}

return 0;
}

</c>

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).

= Die Timer/Counter des AVR =

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.

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.

Hier kommen die im AVR vorhandenen Timer/Counter zum Einsatz.

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.



Ein anderes Anwendungsgebiet ist die Zählung von Signalen, welche über einen I/O-Pin zugeführt werden können.

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.

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.

== Der Vorteiler (Prescaler) ==

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.

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.

== 8-Bit Timer/Counter ==

Alle AVR-Modelle verfügen über mindestens einen, teilweise sogar zwei, 8-Bit Timer.

Der 8-Bit Timer wird z.B bei AT90S2313 über folgende Register angesprochen (bei anderen Typen weitestgehend analog):

{| border="1"
|-
| '''TCCR0'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister
Timer '''0'''

In diesem Register stellen wir ein, wie wir den Timer/Counter verwenden möchten.

Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''CS02'''
| align="center" | '''CS01'''
| align="center" | '''CS00'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''CS02, CS01, CS00''' ('''C'''lock '''S'''elect Bits)
:Diese 3 Bits bestimmen die Quelle für den Timer/Counter:
<dl><dd>
{| border="1"
|-
| align="center" | CS02
| align="center" | CS01
| align="center" | CS00
| Resultat
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stopp, Der Timer/Counter wird angehalten.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CPU-Takt
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CPU-Takt / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CPU-Takt / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CPU-Takt / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CPU-Takt / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin '''TO''', fallende Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin '''TO''', steigende Flanke
|}
</dd>
</dl>
:Wenn als Quelle der externe Pin '''TO''' verwendet wird, so wird ein Flankenwechsel auch erkannt, wenn der Pin '''TO''' als Ausgang geschaltet ist.

|-
| '''TCNT0'''
| '''T'''imer/'''C'''ou'''nt'''er Daten Register Timer '''0'''<br />
Dieses ist als 8-Bit Aufwärtszähler mit Schreib- und Lesezugriff
realisiert. Wenn der Zähler den Wert 255 erreicht hat beginnt er beim
nächsten Zyklus wieder bei 0.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''MSB'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''LSB'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}
|}

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:

<c>
TCCR0 |= (1<<CS00)|(1<<CS02);
</c>

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
lässt sich durch das Hineinschreiben einer 1 und nicht wie erwartet einer 0 wieder zurücksetzen.

== 16-Bit Timer/Counter ==

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:

* Die [[PWM]]-Betriebsart Erzeugung eines pulsweitenmodulierten Ausgangssignals.
* Vergleichswert-Überprüfung mit Erzeugung eines Ausgangssignals (Output Compare Match).
* Einfangen eines Eingangssignals mit Speicherung des aktuellen Zählerwertes (Input Capturing), mit zuschaltbarer Rauschunterdrückung (Noise Filtering).

Folgende Register sind dem Timer/Counter 1 zugeordnet:

{| border="1"
|-
| '''TCCR1A'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister '''A''' Timer '''1'''<br />
In diesem und dem folgenden Register stellen wir ein, wie wir den Timer/Counter verwenden möchten.<br />
Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''COM1A1'''
| align="center" | '''COM1A0'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''PWM11'''
| align="center" | '''PWM10'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''COM1A1''', '''COM1A0''' ('''Co'''mpare '''M'''atch Control Bits)
: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.
:Der Pin '''OC1''' ('''PB3''' beim 2313) muss mit dem Datenrichtungsregister als Ausgang konfiguriert werden.

<dl><dd>
{| border="1"
|-
| align="center" | COM1A1
| align="center" | COM1A0
| Resultat
|-
| align="center" | 0
| align="center" | 0
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 0
| align="center" | 1
| Das Signal am Pin '''OC1''' wird invertiert (Toggle).
|-
| align="center" | 1
| align="center" | 0
| Der Output Pin '''OC1''' wird auf 0 gesetzt.
|-
| align="center" | 1
| align="center" | 1
| Der Output Pin '''OC1''' wird auf 1 gesetzt.
|}
</dd></dl>
:In der PWM-Betriebsart haben diese Bits eine andere Funktion.
<dl><dd>
{| border="1"
|-
| align="center" | COM1A1
| align="center" | COM1A0
| Resultat
|-
| align="center" | 0
| align="center" | 0
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 0
| align="center" | 1
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 1
| align="center" | 0
| Wird beim Hochzählen der Wert im Vergleichsregister erreicht, so wird der Pin '''OC1''' auf 0 gesetzt.
Wird beim Herunterzählen der Wert im Vergleichsregister erreicht, so wird der Pin auf 1 gesetzt.

Man nennt dies ''nicht invertierende PWM''.
|-
| align="center" | 1
| align="center" | 1
| Wird beim Hochzählen der Wert im Vergleichsregister erreicht, so wird der Pin '''OC1''' auf 1 gesetzt.
Wird beim Herunterzählen der Wert im Vergleichsregister erreicht, so wird der Pin auf 0 gesetzt.

Man nennt dies ''invertierende PWM''.
|}
</dd></dl>

'''PWM11''', '''PWM10''' ('''PWM''' Mode Select Bits)
:Mit diesen 2 Bits wird die PWM-Betriebsart des Timer/Counter 1 gesteuert.
<dl><dd>
{| border="1"
|-
| align="center" | PWM11
| align="center" | PWM10
| Resultat
|-
| align="center" | 0
| align="center" | 0
| Die PWM-Betriebsart ist nicht aktiviert. Timer/Counter 1 arbeitet als normaler Timer bzw. Zähler.
|-
| align="center" | 0
| align="center" | 1
| 8-Bit PWM Betriebsart aktivieren.
|-
| align="center" | 1
| align="center" | 0
| 9-Bit PWM Betriebsart aktivieren.
|-
| align="center" | 1
| align="center" | 1
| 10-Bit PWM Betriebsart aktivieren.
|}
</dd></dl>
|-
| '''TCCR1B'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister '''B''' Timer '''1'''

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''ICNC1'''
| align="center" | '''ICES1'''
| align="center" | '''-'''
| align="center" | '''WGM13'''
| align="center" | '''WGM12 (CTC1)'''
| align="center" | '''CS12'''
| align="center" | '''CS11'''
| align="center" | '''CS10'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''ICNC1''' ('''I'''nput '''C'''apture '''N'''oise '''C'''anceler (4 CKs) Timer/Counter 1
:oder auf Deutsch Rauschunterdrückung des Eingangssignals.
: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.

'''ICES1''' ('''I'''nput '''C'''apture '''E'''dge '''S'''elect Timer/Counter '''1''')
: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.

'''CTC1''' ('''C'''lear '''T'''imer/'''C'''ounter on Compare Match Timer/Counter '''1''')
: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.
:Da die Übereinstimmung im Takt nach dem Vergleich behandelt wird, ergibt sich je nach eingestelltem Vorteiler ein etwas anderes Zählverhalten:
:Wenn der Vorteiler auf 1 gestellt, und C der voreingestellte Vergleichswert ist, dann nimmt das Datenregister, im CPU-Takt betrachtet, folgende Werte an:
:... | C-2 | C-1 | C | 0 | 1 |...
:Wenn der Vorteiler z.B. auf 8 eingestellt ist, dann nimmt das Datenregister folgende Werte an:
:... | 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 |...
:In der PWM-Betriebsart hat dieses Bit keine Funktion.

'''CS12''', '''CS11''', '''CS10''' ('''C'''lock '''S'''elect Bits)
:Diese 3 Bits bestimmen die Quelle für den Timer/Counter:
<dl><dd>
{| border="1"
|-
| align="center" | CS12
| align="center" | CS11
| align="center" | CS10
| Resultat
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stopp, Der Timer/Counter wird angehalten.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CPU-Takt
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CPU-Takt / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CPU-Takt / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CPU-Takt / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CPU-Takt / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin T1, fallende Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin T1, steigende Flanke
|}
</dd></dl>
:Wenn als Quelle der externe Pin T1 verwendet wird, so wird ein Flankenwechsel auch erkannt, wenn der Pin T1 als Ausgang geschaltet ist.
|-
| '''TCNT1H'''<br />'''TCNT1L'''
| '''T'''imer/'''C'''ou'''nt'''er Daten Register Timer/Counter '''1'''
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.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
| align="center" |  
|-
| '''Name'''
| align="center" | '''MSB'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''TCNT1H'''
|-
| '''Name'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''LSB'''
| align="center" | '''TCNT1L'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" |  
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" |  
|}

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.

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.

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.

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.
|-
| '''OCR1H'''<br />'''OCR1L'''
| Timer/Counter '''O'''utput '''C'''ompare '''R'''egister Timer/Counter '''1'''
{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
| align="center" |  
|-
| '''Name'''
| align="center" | '''MSB'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''OCR1H'''
|-
| '''Name'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''LSB'''
| align="center" | '''OCR1L'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" |  
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" |  
|}

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.

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.
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.

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.
|-
| '''ICR1H'''<br />'''ICR1L'''
| Timer/Counter '''I'''nput '''C'''apture '''R'''egister Timer/Counter '''1'''<br />
{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
| align="center" |  
|-
| '''Name'''
| align="center" | '''MSB'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''ICR1''''''H'''
|-
| '''Name'''
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" |  
| align="center" | '''LSB'''
| align="center" | '''ICR1''''''L'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" |  
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" |  
|}

Das Input Capture Register ist ein 16-Bit Register mit Lesezugriff. Es kann nicht beschrieben werden.

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.

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:

{| border="0"
|-
| Lesen:
| '''ICR1L''' -> '''ICR1H'''
|}
|}

=== Die PWM-Betriebsart ===

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.
Die Obergrenze ergibt sich daraus, ob 8-, 9- oder 10-Bit PWM verwendet wird, und zwar gemäß folgender Tabelle:

{| border="1"
|-
| align="center" | '''Auflösung'''
| align="center" | '''Obergrenze'''
| '''Frequenz'''
|-
| align="center" | 8
| align="center" | 255
| f<sub>TC1</sub> / 510
|-
| align="center" | 9
| align="center" | 511
| f<sub>TC1</sub> / 1022
|-
| align="center" | 10
| align="center" | 1023
| f<sub>TC1</sub> / 2046
|}

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.

Ich habe versucht, die entsprechenden Signale in der folgenden Grafik zusammenzufassen

[[Image:PWM Theorie 3.gif]] [[Image:PWM Theorie 4.gif]]

=== Vergleichswert-Überprüfung ===

Hier wird in ein spezielles Vergleichswertregister ('''OCR1H'''/'''OCR1L''') ein Wert eingeschrieben, welcher ständig mit dem aktuellen Zählerwert verglichen wird.
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.

=== Einfangen eines Eingangssignals (Input Capturing) ===

Bei dieser Betriebsart wird an den Input Capturing Pin (ICP) des Controllers eine Signalquelle angeschlossen.
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.
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.

== Gemeinsame Register ==

Verschiedene Register beinhalten Zustände und Einstellungen, welche sowohl
für den 8-Bit, als auch für den 16-Bit Timer/Counter in ein und demselben
Register zu finden sind.

{| border="1"
|-
| '''TIMSK'''
| '''T'''imer/Counter '''I'''nterrupt '''M'''a'''sk'''
Register

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''TOIE1'''
| align="center" | '''OCIE1A'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''TICIE'''
| align="center" | '''-'''
| align="center" | '''TOIE0'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R
| align="center" | R/W
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''TOIE1''' ('''T'''imer/Counter '''O'''verflow '''I'''nterrupt '''E'''nable Timer/Counter '''1''')
: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.

'''OCIE1A''' ('''O'''utput '''C'''ompare Match '''I'''nterrupt '''E'''nable Timer/Counter '''1''')
:Beim Timer/Counter 1 kann zusätzlich zum Überlauf ein Vergleichswert definiert werden.

: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.

'''TICIE''' ('''T'''imer/Counter '''I'''nput '''C'''apture '''I'''nterrupt '''E'''nable)
: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.

'''TOIE0''' ('''T'''imer/Counter '''O'''verflow '''I'''nterrupt '''E'''nable Timer/Counter '''0''')
: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.

|-
| '''TIFR'''
| '''T'''imer/Counter '''I'''nterrupt '''F'''lag '''R'''egister

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''TOV1'''
| align="center" | '''OCF1A'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''ICF1'''
| align="center" | '''-'''
| align="center" | '''TOV0'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R
| align="center" | R/W
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''TOV1''' ('''T'''imer/Counter '''O'''verflow Flag Timer/Counter '''1''')
:Dieses Bit wird vom Controller gesetzt, wenn beim Timer 1 ein Überlauf des Datenregisters stattfindet.

: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).

: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.

'''OCF1A''' ('''O'''utput '''C'''ompare '''F'''lag Timer/Counter '''1''')
:Dieses Bit wird gesetzt, wenn der aktuelle Wert des Datenregisters von Timer/Counter 1 mit demjenigen im Vergleichsregister '''OCR1''' übereinstimmt.

: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.

'''ICF1''' ('''I'''nput '''C'''apture '''F'''lag Timer/Counter '''1''')
: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.

: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.

'''TOV0''' ('''T'''imer/Counter '''O'''verflow Flag Timer/Counter '''0''')
:Dieses Bit wird vom Controller gesetzt, wenn beim Timer 0 ein Überlauf des Datenregisters stattfindet.

: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.
|}

 

= Warteschleifen (delay.h) =

Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:

* Warten im Sinn von Zeitvertrödeln
* Warten auf einen bestimmten Zustand an den I/O-Pins
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)
* Warten auf einen bestimmten Zählerstand (siehe Counter)

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.

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.

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.

Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.

== avr-libc Versionen kleiner 1.6 ==

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.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus
<c>
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */

/*
lange, variable Verzögerungszeit, Einheit in Millisekunden

Die maximale Zeit pro Funktionsaufruf ist begrenzt auf
262.14 ms / F_CPU in MHz (im Beispiel:
262.1 / 3.6864 = max. 71 ms)

Daher wird die kleine Warteschleife mehrfach aufgerufen,
um auf eine längere Wartezeit zu kommen. Die zusätzliche
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig
ungenau werden (macht hier vielleicht 2-3ms aus).
*/

void long_delay(uint16_t ms) {
for(; ms>0; ms--) _delay_ms(1);
}

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
long_delay(1000); // Eine Sekunde warten...
}

return 0;
}
</c>

== avr-libc Versionen ab 1.6 ==

_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.

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.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6
<c>
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...
// funktioniert nicht mit Bibliotheken vor 1.6

}
return 0;
}
</c>

= Der Watchdog =

Und hier kommt das ultimative Mittel gegen die Unvollkommenheit von uns
Programmierern, der Watchdog.

So sehr wir uns auch anstrengen, es wird uns kaum je gelingen, das absolut
perfekte und fehlerfreie Programm zu entwickeln.

Der Watchdog kann uns zwar auch nicht zu besseren Programmen verhelfen aber er
kann dafür sorgen, dass unser Programm, wenn es sich wieder mal in's Nirwana
verabschiedet hat, neu gestartet wird, indem ein Reset des Controllers
ausgelöst wird.

Betrachten wir doch einmal folgende Codesequenz:

<c>
uint8_t x;

x = 10;

while (x >= 0)
{
// tu was

x--;
}
</c>

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).
Das Programm würde sich also hier aufhängen und auf ewig in der Schleife drehen.
Und hier genau kommt der Watchdog zum Zug.

== Wie funktioniert nun der Watchdog? ==

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.
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).
Dies sollte innerhalb unserer Hauptschleife passieren.

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.
Dann muss innerhalb der nächsten 4 Taktzyklen das Bit WDE auf 0 gesetzt werden.

Das Watchdog Control Register:

{| border="1"
|-
| '''WDTCR'''
| '''W'''atchog '''T'''imer  '''C'''ontrol '''R'''egister

In diesem Register stellen wir ein, wie wir den Watchdog verwenden möchten.

Das Register ist wie folgt aufgebaut:

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''WDTOE'''
| align="center" | '''WDE'''
| align="center" | '''WDP2'''
| align="center" | '''WDP1'''
| align="center" | '''WDP0'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''WDTOE''' ('''W'''atch'''d'''og '''T'''urn '''O'''ff '''E'''nable)
:Dieses Bit muss gesetzt sein, wenn das Bit '''WDE''' gelöscht wird, andernfalls wird der Watchdog nicht ausgeschaltet.
:Wenn das Bit einmal gesetzt ist, wird es von der Hardware nach 4 Taktzyklen automatisch wieder gelöscht.

'''WDE''' ('''W'''atch'''d'''og '''E'''nable)
:Wenn dieses Bit gesetzt wird, so wird der Watchdog aktiviert.
:Das Bit kann nur gelöscht werden, solange das Bit '''WDTOE''' auf 1 steht.

'''WDP2''', '''WDP1''', '''WDP0''' ('''W'''atch'''d'''og Timer '''P'''rescaler Bits)
:Diese 3 Bits bestimmen die Anzahl Oszillatorzyklen für den Watchdog, also, wie lange es dauert, bis ein Reset ausgelöst wird:
<dl><dd>
{| border="1"
|-
| align="center" | WDP2
| align="center" | WDP1
| align="center" | WDP0
| align="center" | Anzahl Zyklen
| align="center" | Typ. Timeoutzeit bei Vcc = 3V
| align="center" | Typ. Timeoutzeit bei Vcc = 5V
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 16K
| align="center" | 47ms
| align="center" | 15ms
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| align="center" | 32K
| align="center" | 94ms
| align="center" | 30ms
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| align="center" | 64K
| align="center" | 0.19s
| align="center" | 60ms
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| align="center" | 128K
| align="center" | 0.38s
| align="center" | 0.12s
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| align="center" | 256K
| align="center" | 0.75s
| align="center" | 0.24s
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| align="center" | 512K
| align="center" | 1.5s
| align="center" | 0.49s
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| align="center" | 1024K
| align="center" | 3s
| align="center" | 0.97s
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| align="center" | 2048K
| align="center" | 6s
| align="center" | 1.9s
|}
</dd></dl>
|}

Um den Watchdog mit dem AVR-GCC Compiler zu verwenden, muss die Headerdatei ''wdt.h'' (''#include <avr/wdt.h>'') in die Quelldatei eingebunden werden.

Danach können die folgenden Funktionen verwendet werden:

* '''wdt_enable(uint8_t timeout)'''
: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
:Mögliche Timeoutwerte:
<div align="center">
{| border="1"
! Konstante
! Wert
! TimeOut
|-
| WDTO_15MS
| 0
| 15 ms
|-
| WDTO_30MS
| 1
| 30 ms
|-
| WDTO_60MS
| 2
| 60 ms
|-
| WDTO_120MS
| 3
| 120 ms
|-
| WDTO_250MS
| 4
| 250 ms
|-
| WDTO_500MS
| 5
| 500 ms
|-
| WDTO_1S
| 6
| 1 s
|-
| WDTO_2S
| 7
| 2 s
|}
</div>
* '''wdt_disable()'''
:Mit dieser Funktion kann der Watchdog ausgeschaltet werden. Dabei wird das notwendige Prozedere, wie oben beschrieben, automatisch ausgeführt.
* '''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.

Selbstverständlich kann das '''WDTCR'''-Register auch mit den uns bereits bekannten Funktionen für den Zugriff auf Register programmiert werden.

== Watchdog-Anwendungshinweise ==

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.

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).

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Watchdog timer handling
* [http://www.mikrocontroller.net/topic/77273#642501 Bug in ATtiny2313?]

= Programmieren mit Interrupts =

Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich
die Programmierung unter Zuhilfenahme der Interrupts des AVR.

Als erstes wollen wir uns noch einmal den allgemeinen Programmablauf bei der
Interrupt-Programmierung zu Gemüte führen.

[[Image:Interrupt Programme.gif]]

Man sieht, dass die Interruptroutine quasi parallel zum Hauptprogramm
abläuft. Da wir nur eine CPU haben ist es natürlich keine echte Parallelität,
sondern das Hauptprogramm wird beim Eintreffen eines Interrupts unterbrochen,
die Interruptroutine wird ausgeführt und danach erst wieder zum Hauptprogramm
zurückgekehrt.

[http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]

== Anforderungen an Interrupt-Routinen ==

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:

* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)
* Keine langen Programmschleifen.
* 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.

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.

(*)
Hinweis:
Es gibt allerdings die seltene Situation, dass man gerade eingelesene
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!

== Interrupt-Quellen ==

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.

* Reset
* Externer Interrupt 0
* Externer Interrupt 1
* Timer/Counter 1 Capture Ereignis
* Timer/Counter 1 Compare Match
* Timer/Counter 1 Überlauf
* Timer/Counter 0 Überlauf
* UART Zeichen empfangen
* UART Datenregister leer
* UART Zeichen gesendet
* Analoger Komparator

Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").

== Register ==

Der AT90S2313 verfügt über 2 Register die mit den
Interrupts zusammen hängen.

{| border="1"
|-
| '''GIMSK'''
| '''G'''eneral '''I'''nterrupt '''M'''ask '''R'''egister.<br />

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''INT1'''
| align="center" | '''INT0'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''INT1''' (External '''Int'''errupt Request '''1''' Enable)
: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.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
: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.

'''INT0''' (External '''Int'''errupt Request '''0''' Enable)
: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.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
: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.

|-
| '''GIFR'''
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''INTF1'''
| align="center" | '''INTF0'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''-'''
|-
| '''R/W'''
| align="center" | R/W
| align="center" | R/W
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
| align="center" | R
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''INTF1''' (External '''Int'''errupt Flag '''1''')
: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.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.

'''INTF0''' (External '''Int'''errupt Flag '''0''')
: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.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.
|-
| '''MCUCR'''
| '''MCU''' '''C'''ontrol '''R'''egister.

Das MCU Control Register enthält Kontrollbits für allgemeine
MCU-Funktionen.

{| border="1"
|-
| '''Bit'''
| align="center" | 7
| align="center" | 6
| align="center" | 5
| align="center" | 4
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0
|-
| '''Name'''
| align="center" | '''-'''
| align="center" | '''-'''
| align="center" | '''SE'''
| align="center" | '''SM'''
| align="center" | '''ISC11'''
| align="center" | '''ISC10'''
| align="center" | '''ISC01'''
| align="center" | '''ISC00'''
|-
| '''R/W'''
| align="center" | R
| align="center" | R
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
| align="center" | R/W
|-
| '''Initialwert'''
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
| align="center" | 0
|}

'''SE''' ('''S'''leep '''E'''nable)
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.

'''SM''' ('''S'''leep '''M'''ode)
:Dieses Bit bestimmt der Schlafmodus.
: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")

'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.
<dl><dd>
{| border="1"
|-
| align="center" | '''ISC11'''
| align="center" | '''ISC10'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT1''' erzeugt einen Interrupt.

In der Beschreibung heißt es, der Interrupt wird getriggert, solange der Pin auf 0 bleibt, also eigentlich unbrauchbar.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.
|}
</dd></dl>
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.

<dl><dd>
{| border="1"
|-
| align="center" | '''ISC01'''
| align="center" | '''ISC00'''
| '''Bedeutung'''
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT0''' erzeugt einen Interrupt.

In der Beschreibung heißt es, der Interrupt wird getriggert, solange der Pin auf 0 bleibt, also eigentlich unbrauchbar.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.
|}
</dd></dl>
|}

== Allgemeines über die Interrupt-Abarbeitung ==

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, rate ich dringend davon ab. 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
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.



== Interrupts mit dem AVR GCC Compiler (WinAVR) ==


Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').

<c>
// fuer sei(), cli() und ISR():
#include <avr/interrupt.h>
</c>

Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.

<c>
sei();
</c>

Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.

<c>
cli();
</c>

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 Interrups aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:

<c>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>

//...

void NichtUnterbrechenBitte(void)
{
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister

tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern
cli(); // Interrupts global deaktivieren

/* hier "unterbrechnungsfreier" Code */

/* Beispiel Anfang
JTAG-Interface eines ATmega16 per Software deaktivieren
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229):
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */

MCUCSR |= (1<<JTD);
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information

/* Beispiel Ende */

SREG = tmp_sreg; // Status-Register wieder herstellen
// somit auch das I-Flag auf gesicherten Zustand setzen
}

void NichtSoGut(void)
{
cli();

/* hier "unterbrechnungsfreier" Code */

sei();
}

int main(void)
{
//...

cli();
// Interrupts global deaktiviert

NichtUnterbrechenBitte();
// auch nach Aufruf der Funktion deaktiviert

sei();
// Interrupts global aktiviert

NichtUnterbrechenBitte();
// weiterhin aktiviert
//...

/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */
cli();
// Interrupts jetzt global deaktiviert

NichtSoGut();
// nach Aufruf der Funktion sind Interrupts global aktiviert
// dies ist mglw. ungewollt!
//...

}
</c>



Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft. Dazu existiert die Definition (ein Makro) '''ISR'''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe Abschnitt (TODO: verlinken) im Anhang.


=== ISR ===

(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. vgl. [[AVR-GCC-Tutorial#Anhang|Anhang]])



<c>
#include <avr/interrupt.h>
//...
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */
{
/* Interrupt Code */
}
</c>

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.

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.

<c>
//...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */

/* avr/iom8.h - definitions for ATmega8 */
//...

/* Interrupt vectors */

/* External Interrupt Request 0 */
#define INT0_vect _VECTOR(1)
#define SIG_INTERRUPT0 _VECTOR(1)

/* External Interrupt Request 1 */
#define INT1_vect _VECTOR(2)
#define SIG_INTERRUPT1 _VECTOR(2)

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)

/* Timer/Counter2 Overflow */
#define TIMER2_OVF_vect _VECTOR(4)
#define SIG_OVERFLOW2 _VECTOR(4)

/* Timer/Counter1 Capture Event */
#define TIMER1_CAPT_vect _VECTOR(5)
#define SIG_INPUT_CAPTURE1 _VECTOR(5)

/* Timer/Counter1 Compare Match A */
#define TIMER1_COMPA_vect _VECTOR(6)
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)

/* Timer/Counter1 Compare Match B */
#define TIMER1_COMPB_vect _VECTOR(7)
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)

//...
</c>


Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:

<c>
#include <avr/interrupt.h>
/* veraltet: #include <avr/signal.h> */

ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */
{
/* Interrupt Code */
}

ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
/* Interrupt Code */
}

ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */
{
/* Interrupt Code */
}

// und so weiter und so fort...
</c>

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]]).

Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.

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.

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.

=== Unterbrechbare Interruptroutinen ===

"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.



<c>
#include <avr/interrupt.h>
//...
void XXX_vect(void) __attribute__((interrupt));
void XXX_vect(void) {
//...
}
</c>

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. 

siehe auch: Hinweise in [[AVR-GCC]]

siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

== Datenaustausch mit Interrupt-Routinen ==

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.

Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.

<c>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdint.h>
//...

// Schwellwerte
// Entprellung:
#define CNTDEBOUNCE 10
// "lange gedrueckt:"
#define CNTREPEAT 200

// hier z.B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt
#define KEY_PIN PINA
#define KEY_PINNO PA2

// beachte: volatile!
volatile uint8_t gKeyCounter;

// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt
ISR(TIMER1_COMPA_vect)
{
// hier wird gKeyCounter veraendert. Die übrigen
// Programmteile müssen diese Aenderung "sehen":
// volatile -> aktuellen Wert immer in den Speicher schreiben
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
}
else {
gKeyCounter = 0;
}
}

//...

int main(void)
{
//...
/* hier: Initialisierung der Ports und des Timer-Interrupts */
//...
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der
// ISR geschriebene Wert bekannt sein:
// volatile -> aktuellen Wert immer aus dem Speicher lesen
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"
if (gKeyCounter == CNTREPEAT) {
/* hier: Code fuer "Taste lange gedrueckt" */
}
else {
/* hier: Code fuer "Taste kurz gedrueckt" */
}
}
//...
}
</c>

=== volatile und Pointer ===

Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable auf die der Pointer zeigt '''volatile''' ist.

<c>
volatile uint8_t *a; // das Ziel von a ist volatile

uint8_t *volatile a; // a selbst ist volatile
</c>

=== Variablen größer 1 Byte ===

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:

<c>
//...
volatile uint16_t gMyCounter16bit;
//...
ISR(...)
{
//...
gMyCounter16Bit++;
//...
}

int main(void)
{
uint16_t tmpCnt;
//...
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.
tmpCnt = gMyCounter16bit;

// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"
// bleiben konsistent
cli(); // Interupts deaktivieren
tmpCnt = gMyCounter16Bit;
sei(); // wieder aktivieren

// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten
uint8_t sreg_tmp;
sreg_tmp = SREG; /* Sichern */
cli()
tmpCnt = gMyCounter16Bit;
SREG = sreg_tmp; /* Wiederherstellen */

// oder: mehrfach lesen, bis man konsistente Daten hat
uint16_t count1 = gMyCounter16Bit;
uint16_t count2 = gMyCounter16Bit;
while (count1 != count2) {
count1 = count2;
count2 = gMyCounter16Bit;
}
tmpCnt = count1;
//...
}
</c>

== Interrupt-Routinen und Registerzugriffe ==

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.

Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:

<c>
#include <avr/io.h>

int main(void)
{
//...
PORTA |= (1<<PA0);

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
//...
}
</c>

Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:

<div class="code"><pre>
...
PORTA |= (1<<PA0);
d2: d8 9a sbi 0x1b, 0 ; 27 (a)

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
d4: 8b b3 in r24, 0x1b ; 27 (b)
d6: 8c 61 ori r24, 0x1C ; 28 (c)
d8: 8b bb out 0x1b, r24 ; 27 (d)
...
</pre></div>

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.

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.

Lösungsmöglichkeiten:
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").
* 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).

* 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)

== Was macht das Hauptprogramm? ==

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.

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.

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals

= Sleep-Modes =

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.
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.

* '''set_sleep_mode(uint8_t mode)'''
: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.
* '''sleep_enable()'''
:aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus
* '''sleep_cpu()'''
: Versetzt den Controller in den Schlafmodus (sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt)
* '''sleep_disable()'''
:deaktiviert den gesetzten Schlafmodus
* '''sleep_mode()'''
: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).

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).

<c>
#include <avr/io.h>
#include <avr/sleep.h>

int main(void)
{
...

while (1) {
...
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

// Code hier wird erst nach Auftreten eines entsprechenden
// "Aufwach-Interrupts" verarbeitet
...
}
}
</c>

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():

<c>
#include <avr/io.h>
...
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren
SMCR = (3<<SM0) | (1<<SE);
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h
...
</c>

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.

= Speicherzugriffe =

Atmel AVR-Controller verfügen typisch über drei Speicher:

* [[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.

* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.

* [[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.

Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"
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.

== RAM ==

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.

Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "allozieren" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.

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).

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.

Beispiel zur Verwendung von malloc():
<c>
#include <stdlib.h>

void foo(void) {
// neuen speicherbereich anlegen,
// platz für 10 uint16
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));

// darauf zugreifen, als wärs ein gewohnter Buffer
pBuffer[2] = 5;

// Speicher (unbedingt!) wieder freigeben
free(pBuffer);
}
</c>

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.

siehe auch:
* http://www.nongnu.org/avr-libc/user-manual/malloc.html

== Programmspeicher (Flash) ==

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.

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.

<c>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

//...

/* Byte */
const uint8_t pgmFooByte PROGMEM = 123;

/* Wort */
const uint16_t pgmFooWort PROGMEM = 12345;

/* Byte-Feld */
const uint8_t pgmFooByteArray1[] PROGMEM = { 18, 3 ,70 };
const uint8_t pgmFooByteArray2[] PROGMEM = { 30, 7 ,79 };

/* Zeiger */
const uint8_t *pgmPointerToArray1 PROGMEM = pgmFooByteArray1;
const uint8_t *pgmPointerArray[] PROGMEM = { pgmFooByteArray1, pgmFooByteArray2 };
//...

void foo(void)
{
static /*const*/ uint8_t pgmTestByteLocal PROGMEM = 0x55;
static /*const*/ char pgmTestStringLocal[] PROGMEM = "im Flash";
// so nicht (static fehlt): char pgmTestStringLocalFalsch [] PROGMEM = "so nicht";

// ...

}
</c>

=== Byte lesen ===

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.

<c>
const uint8_t pgmFooByte PROGMEM = 123;
const uint8_t pgmFooByteArray1[] PROGMEM = { 18, 3 ,70 };

// Wert der Ram-Variablen myByte auf den Wert von pgmFooByte setzen:
uint8_t myByte;

myByte = pgm_read_byte(&pgmFooByte);
// myByte hat nun den Wert 123

//...

// Schleife ueber ein Array aus Byte-Werten im Flash
uint8_t i;

for (i=0;i<3;i++) {
myByte = pgm_read_byte(&pgmFooByteArray1[i]);
// mach' was mit myByte....
}
</c>

=== Wort lesen ===

Für "einfache" 16-bit breite Variablen erfolgt der Zugriff analog zum Byte-Beispiel, jedoch mit der Funktion pgm_read_word.

<c>
const uint16_t pgmFooWort PROGMEM = 12345;

uint16_t myWord;

myWord = pgm_read_word(&pgmFooWort);
</c>

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. 

<c>
uint8_t *ptrToArray;

ptrToArray = (uint8_t*)(pgm_read_word(&pgmPointerToArray1));
// ptrToArray enthält nun die Startadresse des Byte-Arrays pgmFooByteArray1
// Allerdings würde ein direkter Zugriff mit diesem Pointer (z.B. temp=*ptrToArray)
// '''nicht''' den Inhalt von pgmFooByteArray1[0] liefern, sondern von einer Speicherstelle
// im '''RAM''', die die gleiche Adresse hat wie pgmFooByteArray1[0]
// Daher muss nun die Funktion pgm_read_byte() benutzt werden, die die in ptrToArray
// enthaltene Adresse benutzt und auf das Flash zugreift.

for (i=0;i<3;i++) {
myByte = pgm_read_byte(ptrToArray+i);
// mach' was mit myByte... (18, 3, 70)
}

ptrToArray = (uint8_t*)(pgm_read_word(&pgmPointerArray[1]));

// ptrToArray enthält nun die Adresse des ersten Elements des Byte-Arrays pgmFooByteArray2
// da im zweiten Element des Pointer-Arrays pgmPointerArray die Adresse
// von pgmFooByteArray2 abgelegt ist

for (i=0;i<3;i++) {
myByte = pgm_read_byte(ptrToArray+i);
// mach' was mit myByte... (30, 7, 79)
}
</c>

=== Floats und Structs lesen ===

Um komplexe Datentypen (structs), nicht-integer Datentypen (floats) aus dem Flash auszulesen, sind Hilfsfunktionen erforderlich. Einige Beispiele:

<c>
/* Beispiel float aus Flash */

float pgmFloatArray[3] PROGMEM = {1.1, 2.2, 3.3};
//...

/* liest float von Flash-Addresse addr und gibt diese als return-value zurueck */
inline float pgm_read_float(const float *addr)
{
union
{
uint16_t i[2]; // 2 16-bit-Worte
float f;
} u;

u.i[0]=pgm_read_word((PGM_P)addr);
u.i[1]=pgm_read_word((PGM_P)addr+2);

return u.f;
}
...

void egal(void)
{
int i;
float f;

for (i=0;i<3;i++) {
f = pgm_read_float(&pgmFloatArray[i]); // entspr. "f = pgmFloatArray[i];"
// mach' was mit f
}
}
</c>

TODO: Beispiele fuer structs und pointer aus flash auf struct im flash (menues, state-machines etc.)

=== Array aus Zeichenketten im Flash-Speicher ===

Felder aus Zeichenketten im Flash-Speicher werden in zwei Schritten angelegt: Zuerst die einzelnen Elemente des Arrays und im Anschluss ein Array, in dem die Addressen der Zeichenketten 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 (die Zeichenkette) selbst zuzugreifen.

<c>
#include <stdint.h>
#include <avr/pgmspace.h>

const char str1[] PROGMEM = "first_A";
const char str2[] PROGMEM = "second_A";
const char str3[] PROGMEM = "third_A";

const char *strarray1[] PROGMEM = {
str1,
str2,
str3
};

int main(void)
{
int i, j, l;
const char *pstrflash;
char work[20], work2[20];
// fuer Simulation: per volatile Optimierung verhindern,
// da c nicht genutzt
volatile char c;

for ( i = 0; i < (sizeof(strarray1)/sizeof(strarray1[0]) ); i++ ) {

// setze Pointer auf die Addresse des i-ten Elements des
// "Flash-Arrays" (str1, str2, ...)
pstrflash = (const char*)( pgm_read_word( &(strarray1[i]) ) );

// kopiere den Inhalt der Zeichenkette von der
// in pstrflash abgelegten Adresse in das work-Array
// analog zu strcpy( work, strarray1[i]) wenn alles im RAM
strcpy_P( work, pstrflash );
// verkuerzt:
strcpy_P( work2, (const char*)( pgm_read_word( &(strarray1[i]) ) ) );

// Zeichen-fuer-Zeichen
l = strlen_P( pstrflash );
for ( j=0; j < l; j++ ) {
// analog zu c=strarray[i][j] wenn alles im RAM
c = (char)( pgm_read_byte( pstrflash++ ) );
}
}

while (1) { ; }
}
</c>

Siehe dazu auch die avr-libc FAQ: "How do I put an array of strings completely in ROM?"

=== Vereinfachung für Zeichenketten (Strings) im Flash ===

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.

<c>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <string.h>

#define MAXLEN 30

char StringImFlash[] PROGMEM = "Erwin Lindemann"; // im "Flash"
char StringImRam[MAXLEN];

//...
strcpy(StringImRam, "Mueller-Luedenscheidt");

if (!strncmp_P(StringImRam, StringImFlash, 5)) {
// mach' was, wenn die ersten 5 Zeichen identisch - hier nicht
}
else {
// der Code hier wuerde ausgefuehrt
}

if (!strncmp_P(StringImRam, PSTR("Mueller-Schmitt"), 5)) {
// der Code hier wuerde ausgefuehrt, die ersten 5 Zeichen stimmen ueberein
}
else {
// wuerde bei nicht-Uebereinstimmung ausgefuehrt
}
//...
</c>

Aber Vorsicht: Ersetzt man zum Beispiel
<c>
const char textImFlashOK[] PROGMEM = "mit[]";
// = Daten im "Flash", textImFlashOK* zeigt auf Flashadresse
</c>
durch
<c>
const char* textImFlashProblem PROGMEM = "mit*";
// Konflikt: Daten im BSS (lies: RAM), textImFlashFAIL* zeigt auf Flashadresse
</c>
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.

Ü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.

Eine Funktion, die einen im Flash abgelegten String z.B. an eine UART ausgibt, würde dann so aussehen:

<c>
void uart_puts_p(const char *text)
{
char Zeichen;

while (Zeichen = pgm_read_byte(text))
{ /* so lange, wie mittels pgm_read_byte ein Zeichen vom Flash gelesen
werden konnte, welches nicht das "String-Endezeichen" darstellt */

/* Das gelesene Zeichen über die normalen Kanäle verschicken */
uart_putc(Zeichen);
text++;
}
}
</c>

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:

<c>
// Ausschnitt aus dem Header-File lcd.h der "Fleury-LCD-Lib."
//...
extern void lcd_puts_p(const char *progmem_s);
#define lcd_puts_P(__s) lcd_puts_p(PSTR(__s))
//...

// in einer Anwendung (wieauchimmmer.c)
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <string.h>
#include "lcd.h"

char StringImFlash[] PROGMEM = "Erwin Lindemann"; // im "Flash"

//...
lcd_puts_p(StringImFlash);
lcd_puts_P("Dr. Kloebner");
// daraus wird wg. #define lcd_put_P...: lcd_puts_p( PSTR("Dr. Kloebner") );
//...
</c>

=== Flash in der Anwendung schreiben ===

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.

=== Warum so kompliziert? ===

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.
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.

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.

* 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

== EEPROM ==

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.
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.

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.

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.

Bei der Deklaration einer Variable im EEPROM, ist das Attribut für die Section ".eeprom" zu ergänzen. Siehe dazu folgendes Beispiel:

<c>
#include <avr/io.h>
#include <avr/eeprom.h>
#include <avr/interrupt.h>
#include <inttypes.h> // wird in aktuellen Versionen der avr-lib mit xx.h eingebunden

// EEMEM wird bei aktuellen Versionen der avr-lib in eeprom.h definiert
// hier: definiere falls noch nicht bekannt ("alte" avr-libc)
#ifndef EEMEM
// alle Textstellen EEMEM im Quellcode durch __attribute__ ... ersetzen
#define EEMEM __attribute__ ((section (".eeprom")))
#endif

//...

/* Byte */
uint8_t eeFooByte EEMEM = 123;

/* Wort */
uint16_t eeFooWord EEMEM = 12345;

/* float */
float eeFooFloat EEMEM;

/* Byte-Feld */
uint8_t eeFooByteArray1[] EEMEM = { 18, 3 ,70 };
uint8_t eeFooByteArray2[] EEMEM = { 30, 7 ,79 };

/* 16-bit unsigned short feld */
uint16_t eeFooWordArray1[4] EEMEM;
//...
</c>

=== Bytes lesen/schreiben ===

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:

<c>
//...
uint8_t myByte;

myByte = eeprom_read_byte(&eeFooByte); // lesen
// myByte hat nun den Wert 123
//...
myByte = 99;
eeprom_write_byte(&eeFooByte, myByte); // schreiben
// der Wert 99 wird im EEPROM an die Adresse der
// 'Variablen' eeFooByte geschrieben
//...
myByte = eeprom_read_byte(&eeFooByteArray1[1]);
// myByte hat nun den Wert 3
//...

// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"
// (z.B. wenn die .eep-Datei nach Programmierung einer neuen Version
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE
// deaktiviert ist (unprogrammed/1)
//
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.

#define EEPROM_DEF 0xFF
uint8_t fooByteDefault = 222;
if ( ( myByte = eeprom_read_byte(&eeFooByte) ) == EEPROM_DEF ) {
myByte = fooByteDefault;
}

</c>

=== Wort lesen/schreiben ===

Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:

<c>
//...
uint16_t myWord;

myWord = eeprom_read_word(&eeFooWord); // lesen
// myWord hat nun den Wert 12345
//...
myWord = 2222;
eeprom_write_word(&eeFooWord, myWord); // schreiben
//...
</c>

=== Block lesen/schreiben ===

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).

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.

<c>
//...
uint8_t myByteBuffer[3];
uint16_t myWordBuffer[4];

/* Datenblock aus EEPROM LESEN */

/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse
in das RAM-Array myByteBuffer */
eeprom_read_block(myByteBuffer,eeFooByteArray1,3);

/* dito etwas anschaulicher aber "unnütze Tipparbeit": */
eeprom_read_block(&myByteBuffer[0],&eeFooByteArray[0],3);

/* dito mit etwas Absicherung betr. der Länge */
eeprom_read_block(myByteBuffer,eeFooByteArray1,sizeof(myByteBuffer));

/* und nun mit "16bit" */
eeprom_read_block(myWordBuffer,eeFooWordArray1,sizeof(myWordBuffer));

/* Datenlock in EEPROM SCHREIBEN */
eeprom_write_block(eeFooByteArray1,myByteBuffer,sizeof(myByteBuffer));
eeprom_write_block(eeFooWordArray1,myWordBuffer,sizeof(myWordBuffer));
//...
</c>

"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.

<c>
//...
float myFloat = 12.34;

union {
float r;
uint8_t i[sizeof(float)];
} u;

u.r = myFloat;

/* float in EEPROM */
eeprom_write_block(&eeFooFloat,&(u.i),sizeof(float));

/* float aus EEPROM */
eeprom_read_block(&(u.i),&eeFooFloat,sizeof(float));
/* u.r wieder 12.34 */
//...
</c>

Auch zusammengesetzte Typen lassen sich mit den Block-Routinen verarbeiten.

<c>
//...
typedef struct {
uint8_t label[8];
uint8_t rom_code[8];
} tMyStruct;

#define MAXSENSORS 3
tMyStruct eeMyStruct[MAXSENSORS] EEMEM;

//...

void egal(void)
{
tMyStruct work;

strcpy(work.label,"Flur");
GetRomCode(work.rom_code); // Dummy zur Veranschaulichung - setzt rom-code

/* Sichern von "work" im EEPROM */
eeprom_write_block(&eeMyStruct[0],&work,sizeof(tMyStruct)); // f. Index 0
strcpy(work.label,"Bad");
GetRomCode(work.rom_code);
eeprom_write_block(&eeMyStruct[1],&work,sizeof(tMyStruct)); // f. Index 1
//...
/* Lesen der Daten EEPROM Index 0 in "work" */
eeprom_read_block(&work,&eeMyStruct[0],sizeof(tMyStruct));
// work.label hat nun den Inhalt "Flur"
//...
}
//...
</c>

=== EEPROM-Speicherabbild in .eep-Datei ===

Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklaration abgeleiteten 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.



=== EEPROM-Variable auf feste Adressen legen ===

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
der EEPROM-Variablen durch den Compiler etwas in den Griff bekommen kann.

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.

Im folgenden nun zwei Sourcelistings mit einem Beispiel:

<c>
/////////////////////////////////////////////////
// Datei "eeprom.h" eines eigenen Projektes
/////////////////////////////////////////////////

#inlcude <avr/eeprom.h> // Die EEPROM-Definitionen/Macros der avr-libc einbinden

#define EESIZE 512 // Maximale Größe des EEPROMS

#define EE_DUMMY 0x000 // Dummyelement (Adresse 0 sollte nicht genutzt werden)
#define EE_VALUE1 0x001 // Eine Bytevariable
#define EE_WORD1L 0x002 // Eine Wordvariable (Lowbyte)
#define EE_WORD1H 0x003 // Eine Wordvariable (Highbyte)
#define EE_VALUE2 0x004 // Eine weitere Bytevariable
</c>

Mit den Macros '''#define EE_VALUE1''' legt man den Namen und die Adresse der
'Variablen' fest.

<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.

<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.

<c>
/////////////////////////////////////////////////
// Datei "eeprom.c" eines eigenen Projektes
/////////////////////////////////////////////////

#include "eeprom.h" // Eigene EEPROM-Headerdatei einbinden

uint8_t ee_mem[EESIZE] EEMEM =
{
[EE_DUMMY] = 0x00,
[EE_VALUE1] = 0x05,
[EE_WORD1L] = 0x01,
[EE_WORD1H] = 0x00,
[EE_VALUE2] = 0xFF
};

</c>

Durch die Verwendung eines Array, welches das gesammte EEPROM umfasst, bleibt
dem Compiler nicht anderes übrig, als das Array so zu platzieren, dass Element 0
des Arrays der Adresse 0 des EEPROMs entspricht. (''Ich hoffe nur, dass die Compilerbauer daran nichts ändern!'')

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
definiert werden. Benötigt man keine Initialisierung durch das Programm (was der Normalfall sein dürfte), dann kann man das auch so machen:

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:

<c>
#define EE_DUMMY 0x000
#define EE_WERT ( 0x000 + sizeof( uint8_t ) )
#define EE_ANZAHL ( EE_WERT + sizeof( uint8_t ) )
#define EE_NAME ( EE_ANZAHL + sizeof( uint16_t ) )
#define EE_WERTIGKEIT ( EE_NAME + 10 * sizeof( uint8_t ) )
#define EE_LAST ( EE_WERTIGKEIT + sizeof( uint8_t ) )
</c>

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
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.

<c>
#define EE_DUMMY 0x000
#define EE_WERT ( 0x000 + sizeof( uint8_t ) )
#define EE_ANZAHL ( EE_WERT + sizeof( uint8_t ) )
#define EE_NAME ( EE_ANZAHL + sizeof( uint16_t ) )
#define EE_WERTIGKEIT ( EE_NAME + 10 * sizeof( uint8_t ) )
#define EE_PROZENT ( EE_WERTIGKEIT + sizeof( uint8_t ) )
#define EE_LAST ( EE_WERTIGKEIT + sizeof( double ) )
</c>

EE_PROZENT legt die Startadresse für eine neue 'Variable' des Datentyps double fest.

Der Zugriff auf die EEPROM Werte kann dann z.B.so erfolgen:
<c>
uint8_t temp1;
uint16_t temp2;

temp1 = eeprom_read_byte(EE_VALUE1);
temp2 = eeprom_read_word(EE_WORD1L);
</c>

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
bauen, welche die spezifischen Anforderungen (Interrupt - Atom Problem, etc.)
erfüllen.

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
auf beliebige Adressen zu legen oder Adressen zu ändern. Die Andere Möglichkeit besteht darin, die EEPROM-Werte wie folgt zu belegen:

<c>
/////////////////////////////////////////////////
// Datei "eeprom.c" eines eigenen Projektes
/////////////////////////////////////////////////

#include "eeprom.h" // Eigene EEPROM-Headerdatei einbinden

uint8_t ee_mem[EESIZE] EEMEM =
{
0x00, // ee_dummy
0x05, // ee_value1
0x01, // ee_word1L
0x00, // (ee_word1H)
0xFF // ee_value2
};
</c>

Hierbei kann man Variablen, die größer sind als 1 Byte einfacher definieren und
man muss nur die Highbyte- oder Lowbyte-Adresse in der "eeprom.h" definieren.
Allerdings muss man hier höllisch aufpassen, dass man nicht um eine oder mehrere
Positionen verrutscht!

Welche der beiden Möglichkeiten man einsetzt, hängt vor allem davon ab, wieviele
Byte, Word und sonstige Variablen man benutzt. Gewöhnen sollte man sich an beide Varianten können ;)

Kleine Schlussbemerkung:

* Der avr-gcc unterstützt die Variante 1 und die Variante 2
* Der icc-avr Compiler unterstützt nur die Variante 2!

=== Bekannte Probleme bei den EEPROM-Funktionen ===

Vorsicht: Bei alten Versionen der avr-libc wurden nicht alle AVR Controller untersü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.

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).

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/EEPROM handling

=== EEPROM Register ===
Um das EEPROM anzusteuern sind drei Register von Bedeutung.<BR>
<LI> 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><BR>
<LI> EEDR Hier werden die Daten eingetragen die geschrieben werden sollen bzw. es enthält die gelesenen Daten
<BR><BR>
<LI> 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>

<TABLE BORDER=1>
<TR>
<TD>Bit</TD>
<TD> </TD>
<TD>     7     </TD>
<TD>     6     </TD>
<TD>     5     </TD>
<TD>     4     </TD>
<TD>     3     </TD>
<TD>     2     </TD>
<TD>     1     </TD>
<TD>     0     </TD>
</TR>
<TR>
<TD>Name</TD>
<TD> </TD>
<TD>-</TD>
<TD>-</TD>
<TD>-</TD>
<TD>-</TD>
<TD>EERIE</TD>
<TD>EEMWE</TD>
<TD>EEWE</TD>
<TD>EERE</TD>
</TR>
<TR>
<TD>Read/Write</TD>
<TD></TD>
<TD>R</TD>
<TD>R</TD>
<TD>R</TD>
<TD>R</TD>
<TD>R/W</TD>
<TD>R/W</TD>
<TD>R/W</TD>
<TD>R/W</TD>
</TR>
<TR>
<TD>Init Value</TD>
<TD></TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
<TD>0</TD>
</TR>

</TABLE>
<BR><BR>

<U>Bedeutung der Bits:</U><BR>
Bit 4-7 nicht belegt.<BR><BR>

<U>Bit 3 (EERIE) - EEPROM Ready Interrupt Enable:</U> 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>

<U>Bit 2(EEMWE) - EEPROM Master Write Enable:</U> 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>

<U>Bit 1 (EEWE) - EEPROM Write Enable:</U> 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. <BR>
Ein Schreibvorgang sieht typischerweise wie folgt aus:<BR>
1. EEPROM Bereitschaft abwarten (EEWE=0)
2. Adresse übergeben an EEAR<BR>
3. Daten übergeben an EEDR<BR>
4. Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1 <BR>
5. (Optinal) Warten bis Schreibvorgang abgeschlossen ist.<BR>
<BR><BR>
<U>Bit 0 EERE – EEPROM Read Enable:</U> 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.<BR>
Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<BR>
1. Bereitschaft zum lesen prüfen (EEWE=0)<BR>
2. Adresse übergeben an EEAR<BR>
3. Lesezyklus auslösen mit EERE = 1<BR>
4. Warten bis Lesevorgang abgeschlossen EERE = 0<BR>
5. Daten abholen aus EEDR<BR>
<BR><BR>

= Die Nutzung von printf =

Um komfortabel Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bietet sich printf/sprintf an.
<c>
#include <stdio.h>
#include <stdint.h>

// ...
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)
// ...

uint16_t counter;

void uart_puti( uint16_t value )
{
uint8_t s[20];

sprintf( s, "Zählerstand: %d", value );
uart_puts( s );
}

int main()
{
counter = 5;

uart_puti( counter );
uart_puti( 42 );
}
</c>

Eine weitere elegante Möglichkeit besteht darin, die Ausgabe stdout auf eigene Ausgabefunktionen umzuleiten. Dazu wird dem Ausgabemechanismus eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben (wie auch immer die Ausgabe stattfindet). Alle anderen, höheren, Funktionen greifen letztendlich auf diese eine Ausgabefunktion zurück, die die Ausgabe eines einzelnen Zeichens vornimmt.

<c>
#include <avr/io.h>
#include <stdio.h>

void uart_init(void);
int uart_putchar(char c, FILE *stream);

static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );

void uart_init(void)
{
/* hier µC spezifischen Code zur Initialisierung */
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */

// Beispiel:
//
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz
// 9600 Baud 8N1

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)

UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
}

int uart_putchar( char c, FILE *stream )
{
if( c == '\n' )
uart_putchar( '\r', stream );

loop_until_bit_is_set( UCSRA, UDRE );
UDR = c;
return 0;
}

int main(void)
{
uart_init();
stdout = &mystdout;
printf( "Hello, world!\n" );
return 0;
}

// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74
// + Ergänzungen
</c>

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.

Der Nachteil aller printf-Varianten: Sie sind recht speicherintensiv.

= Assembler und Inline-Assembler =

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.

Die "gnu-Toolchain" bietet dazu zwei Möglichkeiten:

* Inline-Assembler: Die Assembleranweisungen werden direkt in den C-Code integriert. Eine Quellcode-Datei enthält somit C- und Assembleranweisungen
* 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).

== Inline-Assembler ==

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.

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.

<c>
...
/* Verzögern der weiteren Programmausführung um
genau 3 Taktzyklen */
asm volatile ("nop");
asm volatile ("nop");
asm volatile ("nop");
...
</c>

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.

<c>
...
uint16_t i;

/* leere Schleife - wird bei eingeschalteter Compiler-Optimierung wegoptimiert */
for (i = 0; i < 1000; i++)
;

...

/* Schleife erzwingen (keine Optimierung): "NOP-Methode" */
for (i = 0; i < 1000; i++)
asm volatile("NOP");

...

/* alternative Methode (keine Optimierung): */
volatile uint16_t j;
for (j = 0; j < 1000; j++)
;
</c>

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).

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.

<c>
static inline void delayloop16 (uint16_t count)
{
asm volatile ("cp %A0, __zero_reg__ \n\t"
"cpc %B0, __zero_reg__ \n\t"
"breq 2f \n\t"
"1: \n\t"
"sbiw %0,1 \n\t"
"brne 1b \n\t"
"2: "
: "=w" (count)
: "0" (count)
);
}
</c>

* Jede Anweisung wird mit '''\n\t''' abgeschlossen. Der Zeilenumbruch teilt dem Assembler mit, dass ein neuer Befehl beginnt.
* 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 ausffindbaren Label.

Das Resultat zeigt ein Blick in die Assembler-Datei, die der Compiler mit der option <tt>-save-temps</tt> nicht löscht:

<avrasm>
cp r24, __zero_reg__ ; count
cpc r25, __zero_reg__ ; count
breq 2f
1:
sbiw r24,1 ; count
brne 1b
2:
</avrasm>

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].

Siehe auch:
* [http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf AVR Assembler-Anweisungsliste]
* [http://www.roboternetz.de/wissen/index.php/Inline-Assembler_in_avr-gcc Deutsche Einführung in Inline-Assembler]

== Assembler-Dateien ==

Assembler-Dateien erhalten die Endung .S (''grosses'' S) und werden im makefile nach WinAVR/mfile-Vorlage hinter ''ASRC='' durch Leerzeichen getrennt aufgelistet.

Wenn man mit dem AVR Studio arbeitet, kann alternativ auch das standardmäßig erstellte Makefile bearbeitet und folgende Zeilen eingefügt werden:

<div class="code"><pre>
## Objects that must be built in order to link
OBJECTS = (alte Dateien...) useful.o

## Compile
## Hier folgt eine Liste der gelinkten Dateien, darunter einfügen:
useful.o: ../useful.S
$(CC) $(INCLUDES) $(ASMFLAGS) -c $<

</pre></div>
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.

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.

Zuerst der Assembler-Code. Der Dateiname sei useful.S:

<avrasm>
#include "avr/io.h"

//; Arbeitsregister (ohne "r")
workreg = 16
workreg2 = 17

//; Konstante:
ALLOUT = 0xff

//; ** Setze alle Pins von PortD auf Ausgang **
//; keine Parameter, keine Rückgabe
.global superFunc
.func superFunc
superFunc:
push workreg
ldi workreg, ALLOUT
out _SFR_IO_ADDR(DDRD), workreg // beachte: _SFR_IO_ADDR()
pop workreg
ret
.endfunc

//; ** Setze PORTD auf übergebenen Wert **
//; Parameter in r24 (LSB immer bei "graden" Nummern)
.global ultraFunc
.func ultraFunc
ultraFunc:
out _SFR_IO_ADDR(PORTD), 24
ret
.endfunc

//; ** Zustand von PINA zurückgeben **
//; Rückgabewerte in r24:r25 (LSB:MSB), hier nur LSB genutzt
.global gigaFunc
.func gigaFunc
gigaFunc:
in 24, _SFR_IO_ADDR(PINA)
ret
.endfunc

//; ** Zwei Bytes addieren und 16-bit-Wort zurückgeben **
//; Parameter in r24 (Summand1) und r22 (Summand2) -
//; Parameter sind Word-"aligned" d.h. LSB immer auf "graden"
//; Registernummern. Bei 8-Bit und 16-Bit Paramtern somit
//; beginnend bei r24 dann r22 dann r20 etc.
//; Rückgabewert in r24:r25
.global addFunc
.func addFunc
addFunc:
push workreg
push workreg2
clr workreg2
mov workreg, 22
add workreg, 24
adc workreg2, 1 // r1 - assumed to be always zero ...
movw r24, workreg
pop workreg2
pop workreg
ret
.endfunc

//; oh je - sorry - Mein AVR-Assembler ist eingerostet, hoffe das stimmt so...

.end
</avrasm>

Im Makefile ist der Name der Assembler-Quellcodedatei einzutragen:

<div class="code"><pre>
ASRC = useful.S
</pre></div>

Der Aufruf erfolgt dann im C-Code so:

<c>
extern void superFunc(void);
extern void ultraFunc(uint8_t setVal);
extern uint8_t gigaFunc(void);
extern uint16_t addFunc(uint8_t w1, uint8_t w2);

int main(void)
{
[...]
superFunc();

ultraFunc(0x55);

PORTD = gigaFunc();

PORTA = (addFunc(0xF0, 0x11) & 0xff);
PORTB = (addFunc(0xF0, 0x11) >> 8);
[...]
}
</c>

Das Ergebnis wird wieder in der lss-Datei ersichtlich:

<div class="code"><pre>
[...]
superFunc();
148: 0e 94 f6 00 call 0x1ec

ultraFunc(0x55);
14c: 85 e5 ldi r24, 0x55 ; 85
14e: 0e 94 fb 00 call 0x1f6

PORTD = gigaFunc();
152: 0e 94 fd 00 call 0x1fa
156: 82 bb out 0x12, r24 ; 18

PORTA = (addFunc(0xF0, 0x11) & 0xff);
158: 61 e1 ldi r22, 0x11 ; 17
15a: 80 ef ldi r24, 0xF0 ; 240
15c: 0e 94 ff 00 call 0x1fe
160: 8b bb out 0x1b, r24 ; 27
PORTB = (addFunc(0xF0, 0x11) >> 8);
162: 61 e1 ldi r22, 0x11 ; 17
164: 80 ef ldi r24, 0xF0 ; 240
166: 0e 94 fc 00 call 0x1f8
16a: 89 2f mov r24, r25
16c: 99 27 eor r25, r25
16e: 88 bb out 0x18, r24 ; 24

[...]
000001ec <superFunc>:
// setze alle Pins von PortD auf Ausgang
.global superFunc
.func superFunc
superFunc:
push workreg
1ec: 0f 93 push r16
ldi workreg, ALLOUT
1ee: 0f ef ldi r16, 0xFF ; 255
out _SFR_IO_ADDR(DDRD), workreg
1f0: 01 bb out 0x11, r16 ; 17
pop workreg
1f2: 0f 91 pop r16
ret
1f4: 08 95 ret

000001f6 <ultraFunc>:
.endfunc

// setze PORTD auf übergebenen Wert
.global ultraFunc
.func ultraFunc
ultraFunc:
out _SFR_IO_ADDR(PORTD), 24
1f6: 82 bb out 0x12, r24 ; 18
ret
1f8: 08 95 ret

000001fa <gigaFunc>:
.endfunc

// Zustand von PINA zurückgeben
.global gigaFunc
.func gigaFunc
gigaFunc:
in 24, _SFR_IO_ADDR(PINA)
1fa: 89 b3 in r24, 0x19 ; 25
ret
1fc: 08 95 ret

000001fe <addFunc>:
.endfunc

// zwei Bytes addieren und 16-bit-Wort zurückgeben
.global addFunc
.func addFunc
addFunc:
push workreg
1fe: 0f 93 push r16
push workreg2
200: 1f 93 push r17
clr workreg2
202: 11 27 eor r17, r17
mov workreg, 22
204: 06 2f mov r16, r22
add workreg, 24
206: 08 0f add r16, r24
adc workreg2, 1 // r1 - assumed to be always zero ...
208: 11 1d adc r17, r1
movw r24, workreg
20a: c8 01 movw r24, r16
pop workreg2
20c: 1f 91 pop r17
pop workreg
20e: 0f 91 pop r16
ret
210: 08 95 ret

[...]
</pre></div>

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.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/assembler.html avr-libc-Dokumentation: Related Pages/avr-libc and assembler programs]
* [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?"]

== Globale Variablen für Datenaustausch ==

Oftmals kommt man um globale Variablen nicht herum, z.B. um den Datenaustausch zwischen Hauptprogramm und Interrupt-Routinen zu realisieren.
Hierzu muss man im Assembler wissen, wo genau die Variable vom C-Compiler abgespeichert wird.

Hierzu muss die Variable, hier "zaehler" genannt, zuerst im C-Code als Global definiert werden, z.B. so:

<c>
#include <avr/io.h>

volatile uint8_t zaehler;

int16_t main (void)
{
// irgendein Code, in dem zaehler benutzt werden kann

}
</c>

Im foldenden 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.

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).

<avrasm>
#include "avr/io.h"

temp = 16

.extern zaehler

.global INT0_vect
INT0_vect:

push temp //; wichtig: Benutzte Register und das
in temp,_SFR_IO_ADDR(SREG) //; Status-Register (SREG) sichern!
push temp

lds temp,zaehler //; Wert aus dem Speicher lesen
inc temp //; bearbeiten
sts zaehler,temp //; und wieder zurückschreiben

pop temp //; die benutzten Register wiederherstellen
out _SFR_IO_ADDR(SREG),temp
pop temp
reti

.end
</avrasm>

=== Globale Variablen im Assemblerfile anlegen ===

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.

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.

'''zaehl_asm.S'''
<avrasm>
#include "avr/io.h"

temp = 16

//; 1 Byte im RAM für den Zähler reservieren
.comm zaehler, 1

.global INT0_vect
INT0_vect:

...
</avrasm>

In der Headerdatei wird dann auf die Variable nur noch verwiesen (Schlüsselwort ''extern''):

'''zaehl_asm.h'''
<c>
#ifndef ZAEHL_ASM_H
#define ZAEHL_ASM_H

extern volatile uint8_t zaehler;

#endif
</c>

Im Gegensatz zu globalen Variablen in C werden so angelegte Variablen nicht automatisch mit dem Wert 0 initialisiert.

=== Variablen größer als 1 Byte ===

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:

<avrasm>
...
// 4 Byte im RAM für den Zähler reservieren
.comm zaehler, 4
...
</avrasm>

Die dazugehörige Deklaration im Headerfile wäre dann:
<c>
...
extern volatile uint32_t zaehler;
...
</c>

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:

<avrasm>
#include "avr/io.h"

temp = 16

// 4 Byte im RAM für den Zähler reservieren
.comm zaehler, 4

.global INT0_vect
INT0_vect:

push temp // wichtig: Benutzte Register und das
in temp,_SFR_IO_ADDR(SREG) // Status-Register (SREG) sichern !
push temp

// 32-Bit-Zähler incrementieren
lds temp, (zaehler + 0) // 0. Byte (niederwertigstes Byte)
inc temp
sts (zaehler + 0), temp
brne RAUS

lds temp, (zaehler + 1) // 1. Byte
inc temp
sts (zaehler + 1), temp
brne RAUS

lds temp, (zaehler + 2) // 2. Byte
inc temp
sts (zaehler + 2), temp
brne RAUS

lds temp, (zaehler + 3) // 3. Byte (höchstwertigstes Byte)
inc temp
sts (zaehler + 3), temp
brne RAUS

RAUS:
pop temp // die benutzten Register wiederherstellen
out _SFR_IO_ADDR(SREG),temp
pop temp
reti

.end
</avrasm>

'''TODO:''' 16-Bit / 32-Bit Variablen, Zugriff auf Arrays (Strings)

= Anhang =

== Besonderheiten bei der Anpassung bestehenden Quellcodes ==

Einige Funktionen, die in frühren Versionen der avr-libc vorhanden waren, 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.

=== Veraltete Funktionen zur Deklaration von Interrupt-Routinen ===

Die Funktionen (eigentlich Makros) ''SIGNAL'' und ''INTERRUPT'' zur Deklaration von Interruptroutinen sollten nicht mehr genutzt werden.

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:

* #include von avr/signal.h entfernen
* SIGNAL duch ISR ersetzen
* Name des Interrupt-Vektors anpassen (SIG_* durch entsprechendes *_vect)

Als Beispiel für die Anpassung zuerst ein "alter" Code:

<c>
#include <avr/interrupt.h>
#include <avr/signal.h>

...

/* Timer2 Output Compare bei einem ATmega8 */
SIGNAL(SIG_OUTPUT_COMPARE2)
{
...
}
</c>

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.

Der neue Code sieht dann so aus:

<c>
#include <avr/interrupt.h>
/* signal.h entfällt */

ISR(TIMER2_COMP_vect)
{
...
}
</c>

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.

<c>
...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */
/* avr/iom8.h - definitions for ATmega8 */

...

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)
...
</c>



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:

<c>
void XXX_vect(void) __attribute__((interrupt));
void XXX_vect(void) {
...
}
</c>

Beispiel:

<c>
/* ** alt ** */
#include <avr/io.h>
#include <avr/interrupt.h>

//...

INTERRUPT(SIG_OVERFLOW0)
{
...
}

/* ** neu: ** */
#include <avr/io.h>

//...

void TIMER0_OVF_vect(void) __attribute__((interrupt));
void TIMER0_OVF_vect(void)
{
...
}
</c>

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.

=== Veraltete Funktionen zum Portzugriff ===

''inp'' und ''outp'' zum Einlesen bzw. Schreiben von Registern sind nicht mehr erforderlich, der Compiler unterstützt dies ohne diesen Umweg.

<c>
unsigned char i, j;

// alt:
i = inp(PINA);
j = 0xff;
outp(PORTB, j);

// neu (nicht mehr wirklich neu...):
i = PINA
j = 0xff;
PORTB = j;
</c>

Will oder kann man den Code nicht portieren, ist zur weiteren Verwendung von inp und outp die Header-Datei '''compat/deprecated.h''' einzubinden.

=== Veraltete Funktionen zum Zugriff auf Bits in Registern ===

''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.

<c>
// alt:
sbi(PORTB, PB2);
cbi(PORTC, PC1);

// neu (auch nicht mehr wirklich neu...):
PORTB |= (1<<PB2);
PORTC &= ~(1<<PC1);
</c>

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:

<c>
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))
#define TOGGLE_BIT(PORT, BITNUM) ((PORT) ^= (1<<(BITNUM)))
</c>

=== Selbstdefinierte (nicht-standardisierte) ganzzahlige Datentypen ===

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.

<c>
typedef unsigned char BYTE; // besser: uint8_t aus <stdint.h>
typedef unsigned short WORD; // besser: uint16_t aus <stdint.h>
typedef unsigned long DWORD; // besser: uint32_t aus <stdint.h>
typedef unsigned long long QWORD; // besser: uint64_t aus <stdint.h>
</c>

; BYTE : Der Datentyp BYTE definiert eine Variable mit 8 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 255.

; WORD : Der Datentyp WORD definiert eine Variable mit 16 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 65535.

; DWORD : Der Datentyp DWORD (gesprochen: Double-Word) definiert eine Variable mit 32 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 4294967295.

; QWORD : Der Datentyp QWORD (gesprochen: Quad-Word) definiert eine Variable mit 64 Bit Breite zur Darstellung von ganzen Zahlen im Bereich zwischen 0 ... 18446744073709551615.

== Zusätzliche Funktionen im Makefile ==

=== Bibliotheken (Libraries/.a-Dateien) hinzufügen ===

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.

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).

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.

Beispiele:

<div class="code"><pre>
# Einbinden von Funktionen aus einer Library efsl (Dateiname libefsl.a)
LDFLAGS += -lefsl
# Einbinden von Funktionen aus einer Library xyz (Dateiname libxyz.a)
LDFLAGS += -lxyz
</pre></div>

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.)

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:

<div class="code"><pre>
superapp2
|
+----- efslsource (darin libefsl.a)
|
+----- xyzsource (darin libxyz.a)
|
+----- firmware (darin Anwendungs-Quellcode und Makefile)
</pre></div>

Daraus folgt, dass im Makefile die Verzeichnis efslsource und xyzsource in den Library-Suchpfad aufzunehmen sind:

<div class="code"><pre>
LDFLAGS += -L../efslsource/ -L../xyzsource/
</pre></div>

=== Fuse-Bits ===

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.

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):

<c>
#---------------- Programming Options (avrdude) ----------------

#...
#Beispiel! f. ATmega16 - nicht einfach uebernehmen! Zahlenwerte anhand
#--------- des Datenblatts nachvollziehen und gegebenenfalls aendern.
#
AVRDUDE_WRITE_LFUSE = -U lfuse:w:0xff:m
AVRDUDE_WRITE_HFUSE = -U hfuse:w:0xd8:m
AVRDUDE_WRITE_LOCK = -U lock:w:0x2f:m
#...
</c>

Damit diese Variablen auch genutzt werden, ist der Aufruf von avrdude im Makefile entsprechend zu ergänzen:

<c>
# Program the device.
program: $(TARGET).hex $(TARGET).eep
# ohne Fuse-/Lock-Einstellungen (nach WinAVR Vorlage Stand 4/2006)
# $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) \
# $(AVRDUDE_WRITE_EEPROM)
# mit Fuse-/Lock-Einstellungen
$(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_LFUSE) \
$(AVRDUDE_WRITE_HFUSE) $(AVRDUDE_WRITE_FLASH) \
$(AVRDUDE_WRITE_EEPROM) $(AVRDUDE_WRITE_LOCK)
</c>

Eine weiter 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:

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.

<c>
// tiny 2313 fuses low byte
#define CKDIV8 7
#define CKOUT 6
#define SUT1 5
#define SUT0 4
#define CKSEL3 3
#define CKSEL2 2
#define CKSEL1 1
#define CKSEL0 0

// tiny2313 fuses high byte
#define DWEN 7
#define EESAVE 6
#define SPIEN 5
#define WDTON 4
#define BODLEVEL2 3
#define BODLEVEL1 2
#define BODLEVEL0 1
#define RSTDISBL 0

// tiny2313 fuses extended byte
#define SELFPRGEN 0

#define LFUSE __attribute__ ((section ("lfuses")))
#define HFUSE __attribute__ ((section ("hfuses")))
#define EFUSE __attribute__ ((section ("efuses")))

// select ext crystal 3-8Mhz
unsigned char lfuse LFUSE =
( (1<<CKDIV8) | (1<<CKOUT) | (1<<CKSEL3) | (1<<CKSEL2) |
(0<<CKSEL1) | (1<<CKSEL0) | (0<<SUT1) | (1<<SUT0) );
unsigned char hfuse HFUSE =
( (1<<DWEN) | (1<<EESAVE) | (0<<SPIEN) | (1<<WDTON) |
(1<<BODLEVEL2) | (1<<BODLEVEL1) | (0<<BODLEVEL0) | (1<<RSTDISBL) );
unsigned char efuse EFUSE =
((0<<SELFPRGEN));
</c>

'''ACHTUNG: Die Bitpositionen wurden nicht vollständig getestet!'''

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).

Das Makefile muss nun noch um folgende Targets erweitert werden (mit Tabulator einrücken - nicht mit Leerzeichen):

<div class="code"><pre>
lfuses: build
-$(OBJCOPY) -j lfuses --change-section-address lfuses=0 \
-O ihex $(TARGET).elf $(TARGET)-lfuse.hex
@if [ -f $(TARGET)-lfuse.hex ]; then \
$(AVRDUDE) $(AVRDUDE_FLAGS) -U lfuse:w:$(TARGET)-lfuse.hex; \
fi;

hfuses: build
-$(OBJCOPY) -j hfuses --change-section-address hfuses=0 \
-O ihex $(TARGET).elf $(TARGET)-hfuse.hex
@if [ -f $(TARGET)-hfuse.hex ]; then \
$(AVRDUDE) $(AVRDUDE_FLAGS) -U hfuse:w:$(TARGET)-hfuse.hex; \
fi;

efuses: build
-$(OBJCOPY) -j efuses --change-section-address efuses=0 \
-O ihex $(TARGET).elf $(TARGET)-efuse.hex
@if [ -f $(TARGET)-efuse.hex ]; then \
$(AVRDUDE) $(AVRDUDE_FLAGS) -U efuse:w:$(TARGET)-efuse.hex;
fi;
</pre></div>

Das Target "clean" muss noch um die Zeilen
<div class="code"><pre>
$(REMOVE) $(TARGET)-lfuse.hex
$(REMOVE) $(TARGET)-hfuse.hex
$(REMOVE) $(TARGET)-efuse.hex
</pre></div>
erweitert werden, wenn auch die Fuse-Dateien gelöscht werden sollen.

Um nun die Fusebits des angeschlossenen Controllers zu programmieren muss lediglichein "make lfuses", "make hfuses" oder "make efuses" gestartet werden.
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 ;-)

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.

Siehe auch: [[AVR_Fuses#Vergleich_der_Fuses_bei_verschiedenen_Programmen|Vergleich der Fuses bei verschiedenen Programmen]]

== Externe Referenzspannung des internen Analog-Digital-Wandlers ==

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.

Meiner  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.

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.)

= TODO =
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR
* stdio.h, malloc()
* Code-Optimierungen ("tricks"), siehe auch Application Note [http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf AVR035: Efficient C Coding for AVR]
* "naked"-Funktionen
* SPI siehe [http://www.uni-koblenz.de/~physik/informatik/MCU/SPI.pdf SPI Bus mit Atmel AVR]
* I²C / TWI Bus [http://www.roboternetz.de/wissen/index.php/TWI]
* Bootloader (bez. auf boot.h)
* CAN-Bus
* Einsatz von einfachen Betriebssystemen auf dem AVR
* Übersicht zu den C bzw. GCC-predefined Makros (__DATE__, __TIME__,...)
[[Category:AVR]]
* ADC ;
* Timer
* USB ; Steuerung mit USB
* Multiplexen Siebensegment

RFM12 Protokoll Stack

2008-11-08T10:39:25Z

Thymythos: /* Typ 0: Management */

[[Bild:RFM12 Stack.svg|right]]

Dieser Artikel beschreibt einen [http://de.wikipedia.org/wiki/ISO/OSI ISO/OSI] Protokoll [http://de.wikipedia.org/wiki/Protokollstack Stack] für den [[RFM12]] Funkchip.<br/>
Einige Hardwarebeispiele finden sich in [[AVR RFM12]].<br/>
Fehler und Anregungen können gerne auf der [[Diskussion:RFM12_Protokoll_Stack|Diskussionsseite]] besprochen werden.

Eine Referenz-Implementierung für den [[AVR]] wird bereitgestellt:
{| style="border:1px dashed green"
|''svn://mikrocontroller.net/rfm12/trunk/RFM12_Stack''
|}

;Implementierungskriterien
* Wo möglich werden [http://de.wikipedia.org/wiki/R%C3%BCckruffunktion Callback]-Funktionen anstatt [http://de.wikipedia.org/wiki/First_In_%E2%80%93_First_Out FIFOs] verwendet um RAM zu sparen.
* Interruptgesteuerter Ablauf des Stacks
* Funktionen sollten nicht blockieren

== Layer 1: Physical ==

[[Bild:RFM12 PHY StateMachine.svg|thumb|320px|Layer1 State Diagram]]

Der Physical-Layer kümmert sich um die direkte Ansteuerung des RFM12. Alle Funktionen des Chips werden als Software-API bereitgestellt.

Folgende Eigenschaften sind bereits vom RFM12 vorgegeben:

* [http://de.wikipedia.org/wiki/ISM-Band 70cm Band (433MHz)]
* [http://de.wikipedia.org/wiki/Frequenzumtastung FSK]-Modulation
* Sync-Erkennung auf ''0x2D 0xD4''

Definiert werden muss jedoch noch:

* Baudrate
* Zuordnung von Frequenzen zu [[#Kanalzuordnung|Kanälen]]
* Bandbreite der Kanäle
* Management der Sendeleistung/Empfangsempfindlichkeit

'''API'''

<c>
void RFM12_PHY_modeTX(void);

void RFM12_PHY_modeRX(void);

bool RFM12_PHY_busy(void);

void RFM12_setBaudrate(uint32_t baud);

void RFM12_setCenterFrequency(uint16_t freq);

void RFM12_setDataFilter(bool autoLock, bool fastMode, bool analog, uint8_t dqdThres);

void RFM12_setReceiverBandwidth(RFM12_VDI_t vdi, RFM12_RxBW_t bandwidth, RFM12_GAIN_t gain, RFM12_RSSI_t drssi);

void RFM12_setPowerManagement(bool enRX, bool enBB, bool startTX, bool enSynth, bool enOSC, bool enBat, bool enWkT, bool clkOff);

void RFM12_setTransmitPower(RFM12_Power_t power, RFM12_TxDev_t deviation);
</c>

== Layer 2: Data Link ==

=== Media Access Control (MAC) ===

Der MAC-Layer ist sehr einfach gehalten und regelt den Zugriff auf das Medium. Hier soll ein [http://de.wikipedia.org/wiki/CSMA-CA CSMA/CA] Verfahren eingesetzt werden.

# Im Grundzustand befindet sich der RFM12 im Empfangsmodus und wartet auf eine SYNC-Sequenz.
# Kommt eine Sendeanforderung, wird so lange gewartet bis das Medium frei ist, dann darf nach Ablauf einer (pseudo) zufälligen Zeitspanne gesendet werden.
# Wurde gerade ein Paket empfangen, darf sofort ein ACK gesendet werden.

Der Frameaufbau ist teilweise vom RFM12 vorgegeben (SYNC-Erkennung). Der Start-Of-Frame (SOF) dient der Synchronisation. Als End-Of-Frame (EOF) wird ebenfalls die Sequenz ''0xAA'' verwendet. Diese darf im Datenteil nicht vorkommen!

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ MAC Frameaufbau
|-
!
! colspan="2" | SOF
! colspan="2" | Sync
! ''n Byte Daten''
! EOF
|----
! Bits
| colspan="2" | 16 || colspan="2" | 16 || 0 - 512 || 8
|----
! Wert
| 0xAA || 0xAA || 0x2D || 0xD4 || ''Daten'' || 0xAA
|}

'''API'''

<c>
void RFM12_MAC_setChannel(uint8_t channel);

bool RFM12_MAC_isReceiving(void);

bool RFM12_MAC_mediaBusy(void);

void RFM12_MAC_startCtrlTransmission(void);

void RFM12_MAC_endCtrlTransmission(void);
</c>

=== Logical Link Control (LLC) ===

Der LLC-Layer kümmert sich um die Sicherung der zu übertragenden Daten.
Außerdem können Geräte direkt mit ihrer Adresse (8-Bit) angesprochen werden.

;[http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur FEC]
:Alle Bytes werden auf eine [[#Hamming-Tabelle|16-Bit Hamming-Sequenz]] erweitert, wodurch die Datenrate halbiert wird.
:Dies erlaubt es einzelne Bitfehler zu korrigieren.
:Bei zu vielen Fehlern können diese jedoch nicht erkannt werden.
:Im Hamming-Code kommt die Sequenz ''0xAA'' nicht vor (siehe MAC-Layer).

;[http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check CRC]
:Der gesamte Frame wird nochmals durch eine Checksumme gesichert. (CRC-8: ''x<sup>8</sup> + x<sup>5</sup> + x<sup>4</sup> + 1'')

Es werden mehrere Frame-Typen zur Verfügung gestellt:

* Broadcast an alle Geräte (immer ohne ACK)
* Nachricht an ein bestimmtes Gerät (mit oder ohne ACK)

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ LLC Frameaufbau
|-
!
! Empfänger
! Sender
! need ACK
! is ACK
!
!
! TypeID
! ''n Byte Daten''
! CRC-8
|----
! Bits
| 8 || 8 || 1 || 1 || 1 || 1 || 4 || 0-480 || 8
|}

''' API '''

<c>
void RFM12_LLC_registerType(RFM12_ProtocolID_t typeID, RFM12_L3_Protocol_t proto);

uint8_t RFM12_LLC_sendFrame(RFM12_ProtocolID_t proto, uint8_t receiver, bool requireACK);
</c>

== Layer 3: Network ==

Für den Network-Layer werden nur einige Beispiele angeführt. Ab hier können beliebige eigene Protokolle eingesetzt werden. Das verwendete Protokoll wird durch die ''TypeID'' im LLC-Layer angegeben. Die Layer-3-Protokolle sollten nach Möglichkeit nur über die LLC-API mit dem Rest des Stacks kommunizieren.

Die ''TypeID''s sind wie folgt definiert:

=== Typ 0: Management ===

Management Protokoll: Beacons etc.

* Sollte ähnliche Funktionen bieten wie das Service Discovery Protocol (SDP) bei Bluetooth

=== Typ 1: Bytestream ===

Die Einteilung in Pakete wird aufgehoben. Daten kommen 1:1 in der Reihenfolge an, wie sie gesendet wurden.

'''API'''

<c>
void RFM12_Serial_setPeer(uint8_t peer);

bool RFM12_Serial_txAvailable(void);

void RFM12_Serial_txData(uint8_t data);

bool RFM12_Serial_rxAvailable(void);

uint8_t RFM12_Serial_rxData(void);
</c>

=== Typ 3: IPv4 ===

z.B. [http://www.sics.se/~adam/uip/index.php/Main_Page uIP TCP/IP Stack] von Adam Dunkels <adam@dunkels.com>

----

== Anhänge ==

=== Sequenzdiagramme ===

Empfang:
[[Bild:RFM12 RX Sequence.svg|center|800px|RX Sequenz]]

Senden:
[[Bild:RFM12 TX Sequence.svg|center|800px|TX Sequenz]]

=== Frames ===

'''Beachte:''' Durch die Hamming-Codierung sind alle Bytes innerhalb des MAC-Layer doppelt so lang wie angegeben!
{|
! bgcolor="#9fffa8" | MAC || bgcolor="#a9f3f2" | LLC || bgcolor="#d28787" | L3
|}

{| border="1" cellspacing="0" cellpadding="5" align="center" style="text-align:center"
|+ Frameaufbau
|-
!
! colspan="2" bgcolor="#9fffa8" | SOF
! colspan="2" bgcolor="#9fffa8" | Sync
! bgcolor="#a9f3f2" | Empfänger
! bgcolor="#a9f3f2" | Sender
! bgcolor="#a9f3f2" | need ACK | is ACK | | | TypeID
! bgcolor="#d28787" | ''n Byte Daten''
! bgcolor="#a9f3f2" | CRC-8
! bgcolor="#9fffa8" | EOF
|----
! Bits
| colspan="2" bgcolor="#9fffa8" | 16 || colspan="2" bgcolor="#9fffa8" | 16
| bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" | 8 || bgcolor="#a9f3f2" |       1     |      1      |1|1|    4   
| bgcolor="#d28787" | 0-480
| bgcolor="#a9f3f2" | 8
| bgcolor="#9fffa8" | 8
|----
! Wert
| bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0xAA || bgcolor="#9fffa8" | 0x2D || bgcolor="#9fffa8" | 0xD4
| bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" | || bgcolor="#a9f3f2" |
| bgcolor="#d28787" |
| bgcolor="#a9f3f2" |
| bgcolor="#9fffa8" | 0xAA
|}

=== Kanalzuordnung ===

{| border="1" cellspacing="0" cellpadding="5" align="center"
|+ 433MHz Band
|-
! Kanal
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || 10 || 11 || 12 || 13 || 14 || 15
|-
! Mittenfrequenz
| 431.0 || 431.5 || 432.0 || 432.5 || 433.0 || 433.5 || 434.0 || 434.5 || 435.0 || 435.5 || 436.0 || 436.5 || 437.0 || 437.5 || 438.0 || 438.5
|}

=== Hamming-Tabelle ===

==== Encodieren ====

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus
! colspan="4" | Beispiel
|-
| 1:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="160" colspan="2" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|-
| 2: || || align="center" bgcolor="lightblue" | 4-7 || align="center" bgcolor="lightblue" | 0-3 || colspan="2" | || align="center" bgcolor="lightgreen" | 1001 || align="center" bgcolor="lightgreen" | 0110 ||
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(4-7)]
| colspan="2" align="center" bgcolor="lightblue" | HammingE[(0-3)]
| colspan="2" align="center" bgcolor="lightgreen" | 0xC7
| colspan="2" align="center" bgcolor="lightgreen" | 0x38
|-
| 4:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 11000111
| colspan="2" align="center" bgcolor="lightgreen" | 00111000
|-
| 5:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 11000111 00111000
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|+ HammingE
|-
! 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
|bgcolor="#ff0000"|0x15||bgcolor="#ff1111"|0x02||bgcolor="#ff2222"|0x49||bgcolor="#ff3333"|0x5E||bgcolor="#ff4444"|0x64||bgcolor="#ff5555"|0x73||bgcolor="#ff6666"|0x38||bgcolor="#ff7777"|0x2F||bgcolor="#ff8888"|0xD0||bgcolor="#ff9999"|0xC7||bgcolor="#ffaaaa"|0x8C||bgcolor="#ffbbbb"|0x9B||bgcolor="#ffcccc"|0xA1||bgcolor="#ffdddd"|0xB6||bgcolor="#ffeeee"|0xFD||bgcolor="#ffffff"|0xEA
|}

Die Einträge in der Tabelle sind so gewählt, dass der Code den maximalen [http://de.wikipedia.org/wiki/Hamming-Abstand#Hamming-Abstand_eines_Codes Hamming-Abstand] von 4 Bit hat.

==== Dekodieren ====

In der Tabelle ''HammingD'' stehen nur 4-Bit breite Werte. Um einen 8-Bit Wert zu erhalten müssen also 2 Einträge aus der Tabelle ausgewählt werden.

Wird nun ein 16-Bit Wert empfangen, bestimmt das High-Byte den ersten Eintrag, das Low-Byte den zweiten.

Es können bis zu zwei gekippte Bits im High- und im Low-Byte korrigiert werden.

{| border="1" cellspacing="0" cellpadding="3" align="center"
|
! colspan="4" | Algorithmus || colspan="4" | Beispiel (mit Bitfehlern)
|-
| 1:
| colspan="4" align="center" bgcolor="lightblue" | 16-Bit Codewort
| colspan="4" align="center" bgcolor="lightgreen" | 110'''1'''0111 001'''0'''100'''1'''
|-
| 2:
| colspan="2" align="center" bgcolor="lightblue" | high
| colspan="2" align="center" bgcolor="lightblue" | low
| colspan="2" align="center" bgcolor="lightgreen" | 110'''1'''0111
| colspan="2" align="center" bgcolor="lightgreen" | 001'''0'''100'''1'''
|-
| 3:
| colspan="2" align="center" bgcolor="lightblue" | HammingD[high]
| colspan="2" align="center" bgcolor="lightblue" | HammingD[low]
| colspan="2" align="center" bgcolor="lightgreen" | 0x09
| colspan="2" align="center" bgcolor="lightgreen" | 0x06
|-
| 4: || || align="center" bgcolor="lightblue" | 4-7
| align="center" bgcolor="lightblue" | 0-3 ||
| || align="center" bgcolor="lightgreen" | 1001
| align="center" bgcolor="lightgreen" | 0110 ||
|-
| 5:
| width="80" |
| width="160" colspan="2" align="center" bgcolor="lightblue" | 8-Bit Wert
| width="80" | || width="80" |
| width="160" colspan="2" align="center" bgcolor="lightgreen" | 10010110
| width="80" |
|}

{| border="1" cellspacing="0" cellpadding="3" align="center"
|-
|+ HammingD
|-
! || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 || A || B || C || D || E || F
|-
! 0
|bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff3333"|0x03||bgcolor="#ffaaAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 1
|bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff0000"|0x00||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff2222"|0x02||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 2
|bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 3
|bgcolor="#ff6666"|0x06||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 4
|bgcolor="#ff0000"|0x00||bgcolor="#ff2222"|0x02||bgcolor="#ff1111"|0x01||bgcolor="#ff1111"|0x01||bgcolor="#ff4444"|0x04||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 5
|bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ff1111"|0x01||bgcolor="#ff5555"|0x05||bgcolor="#ff0000"|0x00||bgcolor="#ff0000"|0x00||bgcolor="#ff3333"|0x03||bgcolor="#ff1111"|0x01||bgcolor="#ff2222"|0x02||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03||bgcolor="#ff2222"|0x02||bgcolor="#ff3333"|0x03||bgcolor="#ff3333"|0x03
|-
! 6
|bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07||bgcolor="#ff4444"|0x04||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff7777"|0x07
|-
! 7
|bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff4444"|0x04||bgcolor="#ff4444"|0x04||bgcolor="#ff5555"|0x05||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ff6666"|0x06||bgcolor="#ff7777"|0x07||bgcolor="#ff5555"|0x05||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ff7777"|0x07
|-
! 8
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ff1111"|0x01||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B
|-
! 9
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff8888"|0x08||bgcolor="#ff0000"|0x00||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B
|-
! A
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ff7777"|0x07
|-
! B
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff6666"|0x06||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffFFFF"|0x0F
|-
! C
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ffAAAA"|0x0A||bgcolor="#ff2222"|0x02||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ff9999"|0x09
|-
! D
|bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ff8888"|0x08||bgcolor="#ff9999"|0x09||bgcolor="#ff9999"|0x09||bgcolor="#ff8888"|0x08||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffBBBB"|0x0B||bgcolor="#ffAAAA"|0x0A||bgcolor="#ffEEEE"|0x0E||bgcolor="#ff3333"|0x03||bgcolor="#ffBBBB"|0x0B
|-
! E
|bgcolor="#ffCCCC"|0x0C||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff4444"|0x04||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff9999"|0x09||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F
|-
! F
|bgcolor="#ff8888"|0x08||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffDDDD"|0x0D||bgcolor="#ff5555"|0x05||bgcolor="#ffCCCC"|0x0C||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffDDDD"|0x0D||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffEEEE"|0x0E||bgcolor="#ffFFFF"|0x0F||bgcolor="#ffEEEE"|0x0E
|-
|}

[[Kategorie:Funk]]
[[Kategorie:Wettbewerb]]

Diskussion:RFM12 Protokoll Stack

2008-11-07T18:37:45Z

Thymythos: /* Beispiel */

== Fehler ==

'''F:''' ''(17.09.2008)'' Im IE haben die Hamming-Tabellen alle einen schwarzen Hintergrund und schwarze Schrift (Im Firefox ist die Darstellung i.o.)<br>
'''A:''' Ich hab die Kurzschreibweise für Farben verwendet (#f12 statt #ff1122), ist aber eigentlich leider nur in CSS erlaubt... (Aber es scheint eine gute Methode zu sein um Inhalte vor IE nutzern zu verstecken *g*)

== Anregungen ==

'''F:''' ''(31.08.2008)'' Ist der Code bereits benutzbar? Falls ja fände ein Beispielprogramm sehr hilfreich.<br>
'''A:''' Im LLC fehlt noch ein bisschen was, aber PHY und MAC sind benutzbar.

== Fragen ==

'''F:''' ''(04.09.2008)'' Warum gibt es auf LLC-Ebene keine Paketlängeninformation? (Jörg Wunsch)<br>
'''A:''' Overhead. Durch das Paketendezeichen ist die Länge definiert. Zugegeben, in manchen Applikationen erscheint es sinnvoll vor dem Empfang des Paketes die Länge zu wissen, aber IP hat z.B. dafür ein eigenes Feld.

'''F:''' ''(07.10.2008)'' Benutzung?
Der Stack auf Layer 3 sieht ja so eigentlich ganz einfach zu verwenden aus. Aber wie genau benutze ich den jetzt?
Die einfachste Methode wäre ja beim Layer 3 ein init und sofort Daten draufschieben. Aber ich sehe im Quellcode keine Verbindung zu beispielsweise RFM12_PHY_init(). Also um welche Funktionen muss ich mich wirklich kümmern, um auf Layer 3 Bytes hin und her zu schicken?
Und ist das bischen was am 31.08.2008 fehlte inzwischen drinne?

[[Benutzer:Malte|Malte]] 19:15, 7. Okt. 2008 (CEST)

'''A:''' So in etwa hab ich mir das API gedacht:
<c>
#include "rfm12_phy.h"
#include "rfm12_mac.h"
#include "rfm12_llc.h"

#define MY_RECEIVER 2
#define MY_PROTOCOL 13
#define BUF_SIZE 16

uint8_t *buffer = "Hello world";
uint8_t pos;

void myrx(uint8_t data) {
// TODO: handle rx data
}

int16_t mytx(void) {
if(pos < sizeof(buffer))
return txBuf[pos++];
return RFM12_L3_EOD;
}

void myack(bool ack) {
printf("Sending ");
if(ack) printf("OK\n");
else printf("failed\n");
}

void main() {
RFM12_L3_Protocol_t proto = {myrx, mytx, myack};

RFM12_PHY_init();
RFM12_MAC_init();
RFM12_MAC_setChannel(1);
RFM12_LLC_registerType(MY_PROTOCOL, proto);

while(1) {
while(RFM12_MAC_mediaBusy());
pos = 0;
RFM12_LLC_sendFrame(MY_PROTOCOL, MY_RECEIVER, false);
}
}
</c>

AVR RFM12

2008-11-07T17:12:56Z

Thymythos: /* USBprogRFM12 */

Schaltungen und Software für AVR und das Funkmodul [[RFM12]].

== SVN ==

svn://mikrocontroller.net/rfm12

Wegen Zugangsdaten bitte bei [http://www.mikrocontroller.net/user/show/andreas Andreas Schwarz] melden.

----

== Software ==

=== Treiber ===

[http://www.mikrocontroller.net/attachment/22473/rfm12_pc.zip Firmware v1.0.0] von Benedikt K.

[http://www.mikrocontroller.net/attachment/23542/RMxx_Driver.tar.bz2 Firmware v2.0.1] von Jürgen Eckert

{| border="1" cellspacing="0"
|+ Funktionalität
|-
! || Beschreibung || Software
|-
!1. Stufe:
| Die Daten von der seriellen Schnittstelle werden über die Funkstrecke auf die serielle Schnittstelle der anderen Seite übertragen. (Wir freuen uns über jedes Byte das ankommt)
| [http://www.mikrocontroller.net/topic/67273#564945 Claude Schwarz], [http://www.mikrocontroller.net/topic/71682#584915 Benedikt K.] oder [http://www.mikrocontroller.net/attachment/36742/RFM12_V3.zip Manuel Stahl]
|-
! 2. Stufe:
| Es findet eine Fehlererkennung (z.B. mit CRC-Summen) statt. Fehlerhafte Daten werden erneut angefordert. Dadurch gehen auf der Funkstrecke keine Daten verloren und es werden keine Daten verfälscht.
| [http://www.mikrocontroller.net/topic/71682#585851 Benedikt K.]
|-
! 3. Stufe:
| Die Datenübertragung wird individualisiert. Dadurch können zwei Funkstrecken, die im gleichen Empfangsbereich liegen nebeneinander arbeiten, ohne sich zu beeinträchtigen.
| [[RFM12_Protokoll_Stack]]
|-
! 4. Stufe:
| Die Datenübertragung wird verschlüsselt und damit abhörsicher.
|
|-
!5. Stufe:
| Neben den Daten der seriellen Schnittstelle werden auch Änderungen der Statusleitungen übertragen. Damit erhält man eine "RS232-Verlängerung" über eine Funkstrecke, die fehlerfrei arbeitet und zu einer Drahtverbindung weitestgehend kompatibel ist.
|
|}

=== RS232 <-> RFM12 ===

TODO

=== USB <-> RFM12 ===

Mit '''[http://www.obdev.at/products/avrusb/index.html avrusb]''' lässt sich ein USB-Slave in Software emulieren.

* '''[http://www.recursion.jp/avrcdc/ AVR-CDC]''' läuft mit Anpassung der USB-Pins. ''(Zumindest unter Windows an einem USB2.0-Port)''

Adapter für '''[http://www.embedded-projects.net/?page_id=135 USBprog]:'''

* Funktionierender Code liegt im oben genannten SVN
* Implementiert die USB-CDC-Klasse (kein Treiber nötig)
* Sicherung der Übertragung durch Hamming-Code
* Work in progress... (Manuel Stahl)

----

== Hardware ==

=== Basismodul V1.0 ===

==== Prozessor ====

ATmega8 TQFP32 (kompatibel ATmega48, ATmega88, ATmega168)

==== Schnittstellen ====

* RS232
* I²C:
* USB
* GPIO

==== Platine ====

[[Bild:AVR RFM12 Schematic.png|200px|ATmega48 + USB]]
[[Bild:AVR RFM12 Board TOP.png|220px|2-lagig top]]
[[Bild:AVR RFM12 Board BOTTOM.png|240px|2-lagig bottom]]

'''Bauteile:'''

Größe: SMD 0603

* R1, R2: 68R (nur USB)
* R3, R4: 10k
* R5: 1k5 (nur USB)
* C1, C2: 22pF
* C3 - C9: 100nF
* Q1: 12Mhz (nur USB)
* D1, D2: beliebig, Minimelf
* IC3: MAX3221CUE

==== Bugs / Erweiterungen ====

* Der 1,5k Widerstand muss direkt an den VCC-Pin angelötet werden (Pad ist nicht verbunden)
* Beim Fertigen wurde das Polygon, welches das VCC-Signal durch die eine Ecke des ATmega48 leitet, unterbrochen. Hier hilft nur eine Drahtbrücke.
* Unter den RFM12 und unter das Quarz am Besten Isolierband kleben!
* Beim Programmieren sollte der SEL des RFM12 (J1 der zweite Pin vom RS232 aus) auf VCC gelegt werden

==== Fertigung ====

Kosten:

* MiniUSB SMD: '''1,25€'''
* HF-Buchse MMCX: '''4,25€'''
* ATmega48: '''2,85€'''
* MAX3221CUE: '''1,10€'''
* Quarz 12Mhz 30ppm: '''1,19€'''
* Kleinkram: '''< 1,10€'''

* habe ein verbindliches Angebot für 24 Stück von http://mme-pcb.de/: '''4,00€ pro Platine'''

[http://www.mikrocontroller.net/attachment/24012/RFM12.brd Board]:

[[Bild:Board bottom bestuecken.png|200px|bottom]]
[[Bild:AVR RFM12 Board top bestuecken.png|200px|top]]

=== USBprogRFM12 ===

Da der USBprog genau das SPI-Interface des ATmega32 zur Verfügung stellt, eignet er sich perfekt als USB-RFM12-Adapter.

[[Bild:USBprogRFM12_schematic.png|200px|USBprogRFM12]] [[Bild:USBprogRFM12_board.png|200px|USBprogRFM12]]

[[Bild:USBprogRFM12.jpg|400px|USBprogRFM12]]

----

== Links ==

* [http://www.mikrocontroller.net/topic/65984 Allgemeine Diskussion]
* [http://www.mikrocontroller.net/topic/71682 bidirektionale RS232 Funkbrücke mit RFM12]
* [http://www.das-labor.org/wiki/Datenfunk_mit_dem_AVR Datenfunk mit dem AVR] bei das-labor.org

[[Kategorie:Projekte]]
[[Kategorie:AVR]]
[[Kategorie:Funk]]

Datei:USBprogRFM12.jpg

2008-11-07T17:12:15Z

Thymythos: USBprog mit RFM12

USBprog mit RFM12

AVR

2008-11-07T16:56:34Z

Thymythos: /* Software */

Die AVR-[[Mikrocontroller]] von [http://www.atmel.com Atmel] sind besonders in Deutschland sehr beliebt, da sie meist in DIL-Gehäusen verfügbar sind, per [[ISP | In-System-Programming]] programmiert werden können, und eine Vielzahl von kostenlosen Programmen zur Softwareentwicklung (Assembler, Compiler) existiert. Diese Eigenschaften machen den AVR zum perfekten Mikrocontroller für Anfänger.

Über die Bedeutung des Namens "AVR" gibt es verschiedene Ansichten; manche meinen er sei eine Abkürzung für '''A'''dvanced '''V'''irtual [[RISC]], andere vermuten dass der Name aus den Anfangsbuchstaben der Namen der Entwickler ('''A'''lf Egin Bogen und '''V'''egard Wollan) zusammengesetzt wurde. Laut Atmel ist der Name bedeutungslos.

==Architektur==

Die Architektur ist eine 8-Bit-[[Harvard-Architektur]], das heißt es gibt getrennte Speicher für Programmcode ([[Speicher#Flash-ROM |Flash-ROM]]) und Daten ([[Speicher#RAM |RAM]]). Bei der Programmierung hat das den Nachteil, dass sich Konstanten aus dem ROM nicht mit dem gleichen Code laden lassen wie Daten aus dem RAM. Abgesehen davon ist der Aufbau des Controllers recht übersichtlich und birgt wenige Fallstricke.

* 32 größtenteils gleichwertige Register
* 3 Pointerregister
* ca. 110 Befehle, die meist 1-2 Taktzyklen dauern
* Taktfrequenz bis 20 MHz
* Betriebsspannung von 1,8-5,5 V
* Speicher
**1-256 kB [[Speicher#Flash-ROM | Flash-ROM]]
**0-4 kB [[Speicher#EEPROM | EEPROM]]
**0-8 kB [[speicher#RAM | RAM]]
* Peripherie: [[AD-Wandler]], [[Timer]], [[SPI]], [[I²C]] (TWI), [[UART]], [[Speicher#Mit_XMEM-Interface | externer SRAM]]
* [[JTAG]] bei den größeren ATmegas

== Software ==

* [[AVR-Studio]]: Kostenlose Enwicklungsumgebung mit Simulator
* [http://sourceforge.net/projects/kontrollerlab/ KontrollerLab]: Kostenlose Entwicklungsumgebung für KDE
* [[AVR Eclipse]]: Plugin-basierte kostenlose Entwicklungsumgebung (Win, Linux, Mac)
* [[AVR-GCC]]: Kostenloser C-Compiler
* [http://www.mcselec.com/bascom-avr.htm Bascom AVR], [http://www.fastavr.com/ FastAVR]: beliebte Basic-Compiler
* [http://www.e-lab.de AVRCo Pascal Compiler]
* [http://amforth.sourceforge.net/ amforth]: interaktives ANS Forth für AVR unter GNU Lizenz (Open Source)

== Boards & Starterkits ==

* [http://shop.mikrocontroller.net/?category_id=10 diverse im Mikrocontroller.net-Shop]
* [[STK200]]
* [[STK500]]
* [[STK600]]
* [[AVR Butterfly]]
* AVR-ISP / AVR-ISP mkII
* AVR-Dragon
* AVR JTAG-ICE
* [http://www.robotikhardware.de RN-Control]
* [http://www.conrad.de C-Control PRO]
* [http://www.myavr.de myAVR Board]
* [http://www.rowalt.de AVR Lehrbuch und -bausatz]
* [http://www.pollin.de preiswerte Starterkits sowie Lösungen für RFID-125kHz und EtherNet]
* [http://www.lochraster.org/rumpus Rumpus von lochraster.org, ist ein günstiges und gut dokumentiertes Starterkit mit Atmega 168]

== Projekte ==
* [[PWM_foxlight]] - LED Lampe mit PWM
* [[Digitaler Funktionsgenerator]]
* [[Midi Rekorder mit MMC/SD-Karte]]
* [[Schrittmotor-Controller (Stepper)]]
* [[Pulsuhrempfänger mit AVR Butterfly]]
* [[DCF77-Funkwecker mit AVR]]
* [[Fahrradcomputer]]
* [[Einfacher und billiger Webserver mit AtMega32]]
* [[AVR RFM12]]

== Tutorials ==
* [[AVR-Tutorial]]
* [[AVR-GCC-Tutorial]]
* http://www.avr-asm-tutorial.net

== Tipps & Hinweise ==
* [[AVR Typen]] - Die verschiedenen Typen (AT90S, ATmega, ATTiny)
* [[AVR Checkliste]] - Liste mit Hinweisen zur Lösung üblicher Probleme
* [[AVR Fuses|Fuse-Bits]] - Das Setzen der Fuse-Bits ist ein berüchtigter Fallstrick bei den AVRs; vor dem Rumspielen damit unbedingt diese Hinweise lesen!
* [[AVR In System Programmer]] - Programmierhardware
* [[Pony-Prog Tutorial]] - Hinweise zur Programmiersoftware PonyProg
* [[AVRDUDE]] - Programmiersoftware für die Kommandozeile
* [[AVR-GCC-Codeoptimierung]] - Wie man mehr aus dem Controller rausholen kann, ohne ein Assembler-Guru sein zu muessen.
* [[AVR Softwarepool]] - Verschiedene Softwaremodule und Codeschnippsel aus der Codesammlung

Weitere Verweise (Links) auf externe Informationen und Projekte finden sich in der '''[[Linksammlung#AVR|Linksammlung]]'''.

[[Category:Mikrocontroller]][[Category:AVR]]
__NOTOC__

Benutzer:Thymythos

2008-11-06T18:41:59Z

Thymythos:

{|
|Name: || Manuel Stahl
|-
|Mail: || mythos_at_tru42.org
|-
|Jabber: || mythos_at_tru42.org
|}

=== Projekte im Wiki ===

* [[AVR RFM12]]
* [[RFM12 Protokoll Stack]]

Diskussion:AVR-GCC-Tutorial

2008-11-06T18:40:26Z

Thymythos: /* Tutorial nach Wikibooks portieren */

== Benutzerfreundlichkeit erhöhen ==

Das Tutorial ist momentan ein prima Nachschlagewerk für erfahrene Benutzer, leider hat seine Qualität als Tutorial etwas nachgelassen. Auch ich habe mit ihm meinen Einstieg in dei Welt der µC gefunden, aber ich glaube ich würde dies nicht mehr schaffen. Werde in den nächsten Wochen das Tutorial ein wenig verbessern, an den Mega16 anpassen und erweitern.
Zusätzlich werde ich ein Tutorial für Digital-Elektronik schreiben.

[[Benutzer:FeeJai|FeeJai]] 20:26, 27. Nov 2006 (CET)

'''Dazu''':

* "...momentan ein prima Nachschlagewerk für erfahrene Benutzer...": Sorry, aber "erfahrene Benutzer" finden dem Tutorial wenig bis garnichts neues. Die Dokumentation der avr-libc ist eher ein gutes Nachschlagewerk. Das Tutorial nicht, vieles wird nicht detailliert erläutert und einiges nicht mal angesprochen. Was genau macht das Tutorial zu einem Nachschlagewerk?
* "Qualität als Tutorial etwas nachgelassen": Da ich wohl die meisten Erweiterungen und Aktualisierungen geschrieben habe, seit der Artikel ins Wiki aufgenommen wurde, nehme ich das mal zum Anlass zu fragen, was mit "Qualität nachlassen" gemeint ist. Hier "Qualität nachlassen" ohne ein wenig Begründung hinzuschreiben ist mir zu platt. Wenn richtig erinnert, habe zumindest ich nichts aus einen "qualitativ" hochwertigeren alten Zustand gelöscht (bis auf Links zu Quellcode, die nicht mehr gültig waren und nur neuen Text dazu geschrieben bzw. veraltete Informationen aktualisiert.
* "...nicht mehr schaffen...": Warum nicht? Was war vorher einfacher "zu schaffen"? Nur weil der Makefile-Exkurs etwas ausgeufert ist? Falls das der einzige Grund war: habe nun versucht, es etwas aufzuspalten. Etwas konkreter dürfte das "nicht mehr schaffen" schon sein. Bisher habe ich diese Meinung genau einmal gelesen (hier), aber vielleicht auch woanders nicht wahrgenommen. Wenn die Verbesserung darin bestand, die Erläuterungen zum Makefiles in den Anhang zu verschieben und dann im Text zu schreiben: "Sollte man noch nie mit Makefiles gearbeitet haben ist es nun an der Zeit sich den Exkurs: makefiles im Anhang A durchzulesen." ist das bestenfalls unglücklich. Der Großteil der Anfänger, die das Tutorial zum Einstieg lesen, wird vorher kaum ein makefile selbst editiert haben. Viele von den, die C mit Borland, MS oder welcher IDE auch immer gelernt haben, werden nicht mal wissen, was ein makefile ist - da hilft auch der Hinweis auf MFile erstmal wenig. Den ganzen Abschnitt nach ganz unten zu verschieben (und dabei Links und Gliederung zu zerschießen) und dann unmittelbar an der ursprünglichen Stelle den wahrscheinlich typischen Anfänger (die eigentliche Zielgruppe) dahin zu verweisen, war für mich keine nachvollziehbare Verbesserung der "Benutzerfreundlichkeit".
* "...in den nächsten Wochen...": Dann aber zumindest den Artikel nach jeder Änderung so hinterlassen, dass die Gliederungsebenen und internen Verlinkungen noch passen - nicht so wie zum Stand 20061128_1900.
* "...an den Mega16...": die Aktualisierung der Tabellen mit Registerbeschreibungen ist eine gute Idee. Aber wenn man sich schon die Mühe macht, dann wäre eine Anpassung an aktuelle AVR (ATmega644, ATmega48/88/168,...) sinnvoller, da die Registernamen bei den neueren von Herstellerseite noch etwas einheitlicher sind und sich wahrscheinlich in Zukunft auch selten jemand die Mühe macht die Beschreibungen zu überarbeiten. ATmega16 ist auch schon etwas betagt. Aber nicht aufhalten lassen, für ATmega16 ist auf jeden Fall schon besser als für abgekündigte AT90S.
* In der neuen Makefile-Seite (Stand 20061128_1900) blind die Vorlage zusammen mit dem Eintrag für CPPSRC ("CPPSRC = main.cpp") reinzukopieren und dann in der "Einführung" darauf zu verweisen, hatte die Benutzerfreundlichkeit eher umkehren.
* Die Ergänzung um eine Schritt-für-Schritt Einführung ist ein gute Idee. War aber meiner Meinung zu knapp, z.B. Begriffe, die ein Microcontroller-Anfänger eher nicht kennt, Erklärungen nicht ganz richtig (aber das sind meine Ergänzungen/Änderungen wahrscheinlich auch nicht alle). Die inkompatible Binärschreibweise (0b00..) war nicht gut (braucht gepatchten gcc - nicht alle nutzen WinAVR). Syntaxfehler (fehlendes ;).

Also: behutsamer Erweitern, mindestens einmal prüfen - im Zweifel den Compiler anwerfen und testen (makefile, Syntaxfehler), größere Änderungen auf dieser Seite zur Diskussion stellen. Gliederung und Verlinkung beachten.

Nun denn, habe ein wenig an dem Tutorial herumgebastelt, einiges übernommen, einiges ergänzt aber an einigen Stellen Änderungen auch rückgängig gemacht. Das soll aber kein Anlass sein, nun keine Änderungen oder Erweiterungen mehr einzubringen. Das Wiki "lebt" davon, dass viele Leute das beitragen, was sie für richtig halten und das Ganze sich auf Dauer durch Ergänzungen und Änderungen stetig verbessert.

Martin Thomas

Hallo! Mich freut es, dass sich jemand für meine Änderungen interessiert und diese auch verbessert. Inzwischen wurden ja noch ein paar kleine Änderungen vorgenommen. Was ich besonders wichtig finde, ist dass der Benutzer ein schnelles Erfolgserlebnis hat und damit nicht mehr so leicht frustriert aufgibt. Deswegen habe ich den Exkurs Makefiles in den Anhang verschoben. Ich fand dass er ansonsten zu abschreckend ist und potentielle Anfänger geradezu erschlägt. Bei meinem Start habe ich ihn übersprungen und das compilieren schlug natürlich fehl. Allerdings hatte ich die LCD samples von U. Radig auf meinem PC und habe sein Makefile beutzt. Daher das sample für Anfänger.
==> Ich wäre dafür den sehr ausführlichen "Exkurs" in den Anhang zu verschieben, Anfänger mit einem bereitgestellten Beispiel beginnen zu lassen und das Makefile-Konzept anhand praktischer Beispiele nach und nach zu erklären. So sind auch die meisten sehr erfolgreichen Computerbücher (z.B. von Michael Kofler) aufgebaut.
Die Sache mit dem Nachschlagewerk für erfahrene Benutzer, hätte ich vielleicht anderst formulieren sollen. Zutreffender ist: Amateure, jedenfalls nutze ich es gerne als Nachschlagewerk.
Das mit Qualität als Tutorial nachgelassen war so von mir nicht richtig. Ich finde es in seiner bestehenden Anordnung und Detailliertheit gerade am Anfang zu umfangreich. Man kann selbst mit Vorkentnissen nicht alles verstehen, geschweige denn behalten.
Den M16 habe ich genommen denn er besitzt nahezu alle in AVRs vorkommenden Funktionen, ist erschwinglich, beliebt, wird mit ziemlicher Sicherheit demnächst nicht abgekündigt und vorallem kenne ich mich gut mit ihm aus.
Die Sache mit der Gliederung tut mir sehr leid, ich werde mich bemühen, dass etwas derartiges nicht mehr vorkommt. Leider habe ich mit derart großen Texten in wikis auch noch nie gearbeitet.
Grüße,

[[Benutzer:FeeJai|FeeJai]] 21:38, 29. Nov 2006 (CET)

Dann bietet es sich doch an, die einzelnen Abschnitte im Tutorial mehr nach Erfahrungslevel (Einsteiger, Kenner, Könner ;-) zu gliedern und auch zu kennzeichnen.

[[Benutzer:Stefan|Stefan]] 00:24, 30. Nov 2006 (CET)

Prinzipiell nichts dagegen. Möchte noch Antowrt von mt abwarten. So ähnlich habe ich es ja auch vor. Da ich glaube dass es oben etwas unverständlich war was ich gerne machen würde, möchte ich es hier nochmals erläutern:
*Konzept: Mir ist das Tutorial bisher zu theoretisch. Ich möchte den Leser nach dem Einführungsbeispiel anhand praktischer Beispiele, die Zeile für Zeile erklärt werden und langsam anspruchsvoller werden die Welt der µC näher bringen. So etwas nennt man schrittweise Hinführung.
*Mit den Makefiles würde ich es gerne ähnlich handhaben: Da man sie immer zum compilieren benötigt, am Anfang ein funktionierendes Makefile bereitstellen, dieses muss der Leser noch nicht verstehen! Wenn die Projekte dann anspruchsvoller werden das Makefile entsprechend erweitern und somit erklären. Eine zusammenfassende alles abdeckende Erklärung ist im Anhang gut aufgehoben, überfordert aber IMHO Anfänger.
*Der Konjunktiv: sehr höflich, wenn man absoluten Anfängern etwas beibringen will aber eher Kontraproduktiv. Beispiel Programmers Notepad. Jemand der noch nie mit µC gearbeitet hat freut sich über eine klare(!) Anweisung, wie zu Verfahren ist und die auch funktioniert. Die Loslösung von den klares Strukturen wenn man bspw. PonyProg nicht verweden will kommt mit dem zunehmenden Verständnis wie von selbst.
Grüße,

[[Benutzer:FeeJai|FeeJai]] 16:19, 30. Nov 2006 (CET)

'''Dazu - und zu den jüngsten Änderungen'''

Vielleicht habe ich mich nicht klar ausgedrückt: wenn man "irgendwann" mal vorhat des Tutorial "Anfängerfreundlicher" zu machen, fängt man nicht damit an vorhandene Erklärungen durch die Gegend zu schieben und fehlerhafte/unvollständige Informationen einzubauen. Meine Meinung abwarten war wohl eher als Witz gemeint. Ich habe den Exkurs "Makefiles" aus dem Anhang teilweise wieder hochgezogen - und das mit Absicht. Jetzt wird er wieder runtergeschoben - soll das irgendwie zur Belustigung beitragen? Mich motiviert sowas nicht - aber auch gar nicht. Wie wäre es damit, in den Unterabschnitten ein paar weiter Erläuterungen zur "Hinführung" zu ergänzen und als neuer Mitarbeiter an dem Wiki die Sache mal langsam angehen zu lassen? Wie wäre es mit den angekündigten Anpassungen der Registerbeschreibungen an ATMega16 - die stehen in weiten Teilen soweit ich das gesehen habe noch aus.

Ausser den nützlichen Anpassungen der Registerbeschreibungen an einer Tabelle wurde bisher nur hin- und hergeschoben ohne entsprechende Umsicht, ein "Anfängerbeispiel" mit Syntaxfehler eingetragen, eine ohne Änderung nicht brauchbare Makefilevorlage reinkopiert, im Beispiel speziellen Compilererweiterungen genutzt, die es nicht fuer jeden avr-gcc gibt und Erklärungen zum Beispiel gegeben, die mehr als knapp sind - teilweise sogar falsch (z.B. ist eine header-Datei keine Bibliothek/Library wie geschrieben stand). Wenn das "Hinführung" sein sollte, dann nur weiter so, keine Ahnung wen das wo hinführen soll. Ich finde so etwas "kontraproduktiv". Ich habe versucht, das etwas auszubügeln, da ich froh bin, wenn jemand etwas zu dem Tutorial beiträgt und die Idee eine kleinen Intros gut finde (ob das nun mit meinen Änderungen besser ist als vorher, muss jemand anderes beurteilen).

Hier zu erklären was man "schrittweise Hinführung" nennt und was "der Anfänger" will oder was "Kontrakproduktiv" ist, ist grosspurig. Erstmal zeigen, dass man selbst kann, bevor man hier belehrend über das urteilt, was andere gemacht haben. (Bisher war der gezeigte Einsteig in die Mitarbeit am Text alles andere als Überzeugend - aber auch das ist natürlich nur eine (meine) Einzelmeinung).

Zum speziellen: Ponyprog ist der Anfang vielen Übels, ich weiss nicht wie viele Fusebits wegen Pronyprog falsch eingestellt wurden (ja, ich habe auch seinerzeit mit PonyProg angefangen, ja ich habe auch einen ATmega16 damit zerfust und war erstmal aufgeschmissen denn zu der Zeit kannte ich das Forum noch nicht und auch keinen der helfen konnte). AVRdude ist im Beispiel-Makefile vorgekaut (aber ja - man will auf Makefiles ja erst im Laufe des Tutorials "Schritt fuer Schritt" eingehen). Nicht jeder, der sich mit avr und gcc beschäftigt nutzt MS-Windows und hat somit auch nicht Programmers-Notepad (Zeit für den Exkurs Programmers-Notepad mit Wine auf Linux...). Etwas mehr über den Tellerrand darf man schon schauen, vor allem wenn man sich anmaßt den Blick für die Bedürfnisse von Anfängern zu haben.

Soweit
mt

Mir gefallen die jüngsten Änderungen nicht. Viele Schreibfehler jucken in den Augen und drängen mich zum Verbessern. Beim Verbessern sehe ich immer mehr ungenaue Formulierungen (''serieller Programmablauf'') und Voraussetzungen (''Hello_World.hex.zip'') und irgendwann bin ich so genervt, dass ich meine Korrektur verwerfe und das Bearbeiten abbreche. Abgesehen davon, dass ich bestimmte strukturelle Änderungen schlecht finde (Verschiebung der Erklärung des interruptgesteuerten Programmablaufs). Die richtige Lösung wäre gewesen, eine alternative Version vorzubereiten und darüber abstimmen zu lassen, statt die bestehende Version so grundlegend zu ändern. Bis es rum ist, lese ich in der [http://www.mikrocontroller.net/wikisoftware/index.php?title=AVR-GCC-Tutorial&oldid=18451 älteren Version].

[[Benutzer:Stefan|Stefan]] 17:16, 1. Dez 2006 (CET)

Hallo Allerseits!

Habe den ersten Beitrag offensichtlich nicht so negativ verstanden wie er gemeint war. Deswegen habe ich den Exkurs nun wieder nach oben geholt, ich dachte zuerst mt willst ihn nur solange oben haben bis im Text besser darauf eingegangen wird. Die Sache mit den Schreibfehlern stimmt natürlich, es war viel in kurzer Zeit was ich geändert habe. Ich würde mich daher auch freuen, wenn jemand hilft, diese zu korrigieren. Sollten mir selbst welche auffallen, werde ich sie selbstverständlich auch beheben. Dass du das Bearbeiten abbrichst finde ich aber wirklic schade.

Die ungenauen Formulierungen rühren leider auch von Unwissenheit meinerseits, die Formulierung serieller Programmablauf, die als Beispiel genannt wird, stammt aber so nicht von mir. Was Stefan an der Hello_World.zip nicht gut findet, kann ich so leider nicht nachvollziehen. Das Projekt habe ich, um für den Endanwender Tipparbeit einzusparen, als zip-Datei Online gestellt. In ihr befindet sich auch ein Makefile und das compilierte Projekt als .hex.

Der Artikel "I/O Grundlagen" in der Hinführung bedarf tatsächlich einer Überarbeitung. Ich werde mir mal durchlesen, wie Andreas das in seinem Tut erledigt hat. Das "Hello World" gefällt mir persönlich gut, wenn es aber in dieser Form nicht erwünscht ist werde ich es auch schlucken, falls die Hinführung gelöscht wird.

Die Probleme mit Ponyprog sind wahr, leider war es als ich damals anfing das einzige Programm welches auf meinem Rechner gut funktionierte - deswegen benutze ich es hauptsächlich. Weitere Vorteile sind IMHO: Benutzerfreundlich durch einfache Bedienbarkeit und dass die meisten Nutzer es bereits kennen, da es oft von PC Zeitschriften genutzt wird. Grüße,

[[Benutzer:FeeJai|FeeJai]] 17:57, 1. Dez 2006 (CET)

PS: Ich finde die Einführung mit deinen Änderungen wesentlich besser. Allerdings habe ich nochmal kleine Details verändert - wenn es dir nicht gefällt hau es einfach raus. Die neuen Beispiele sind alle getestet, auch ich lerne aus Fehlern. Die Sache mit dem 0b war mir so nicht bekannt und ist wahrlich wenig erfreulich.

===Bitte fügt für einen Satz und ein paar Links keine neuen Abschnitte ein (aktuell: TWI)===

Der Artikel ist ein Tutorial, das heißt dem Leser sollen die verschiedenen Aspekte der Programmierung mit AVR-GCC ''erklärt'' werden; ein Abschnitt über TWI mit drei großen Überschriften aber nur einem allgemeinen Satz und ein paar Links passt da nicht gut dazu. Wenn sich jemand die Mühe machen würde das Thema etwas ausführlicher und mit Beispielcode zu erklären wäre das natürlich '''sehr''' willkommen.
[[Benutzer:Andreas|andreas]] 15:15, 2. Dez 2007 (CET)

=== Tutorial nach Wikibooks portieren ===

Was haltet ihr davon das Tutorial nach Wikibooks zu portieren? Die Seite wird immer größer und unübersichtlicher. Die Einteilung in mehrere Seiten, sowie die Möglichkeit weiterführende Hinweise für fortgeschrittene Nutzer in eine Aufklappbox zu schreiben würden dem Tutorial sicher gut tun.
[[Benutzer:Thymythos|Manuel Stahl]] 17:31, 14. Okt. 2008 (CEST)

Ich kann mir nicht recht vorstellen, wie das aussehen würde. Mein Vorschlag probiere es aus und stelle das Ergebnis zur Anschauung und Diskussion vor. Das Bessere ist des Guten Tod. Du kannst dafür die Version auf der [[Spielwiese avr-gcc Tutorial]] benutzen. Ich würde nach Möglichkeit die Umwandlung etc. mit Skripten o.ä. automatisieren, damit künftige Änderungen im jetzigen Text (siehe die grosse ToDo-Liste) rasch und automatisch ins Wikibook übertragen werden können. [[Benutzer:Stefan|Stefan]] 12:57, 15. Okt. 2008 (CEST)

Hier mal ein erster Versuch: http://de.wikibooks.org/wiki/C-Programmierung_mit_AVR-GCC --[[Benutzer:Thymythos|Thymythos]] 19:40, 6. Nov. 2008 (CET)

== Veraltete Register ==

Hi. Leider sind in dem Tutorial viele Register und Einstellungen auf inzwischen veraltete und viele verschiedene AVRs bezogen. Ich wäre dafür alles auf den ATMega16 anzupassen, da dieser alle Funktionen hat und trotzdem bezahlbar ist. Habe heute mit dem ADC angefangen und so viel Arbeit ist es nicht. Werde, falls es erwünscht ist nach und nach alles an den Mega16 anpassen.

[[Benutzer:FeeJai|FeeJai]] 18:13, 26. Nov 2006 (CET)

==Frage zum Codebsp.==

Warum hier im Codebsp. die Frequenz gesetzt wenn man im Einfache Wandlung (Single Conversion)-modus ist?

ADCSRA = (1<<ADEN) | (1<<ADPS1) | (1<<ADPS0); // Frequenzvorteile setzen auf 8 (1)

Weil man immer den Vorteiler entsprechend der Quarzfrequenz setzen mu�? um den ADC nicht mit einem zu hohen Takt zu versorgen. --[[Benutzer:Matthias|Matthias]] 19:58, 21. Sep 2004 (CEST)

Ich benutze folgenden code der funktioniert. Es wird kein vorteiler gesetzt!!

sbi(ADCSR,ADEN); //ADC An
sbi(ADMUX,MUX0); //kanal wählen
for (;;) { /* loop forever */
sbi(ADCSR,ADSC); //wandlung starten
while(bit_is_set(ADCSR,ADSC)); //warten bis wandlung fertig
num = ADCW;

--- schnipp ---

Der Vorteiler hat nichts mit "funktionieren" oder "nicht funktionieren" zu tun. Man sollte sich eher Gedanken um die Genauigkeit und einzuhaltende Maximalfrequenzen bei der Wandlung machen. Der Abschnitt "ADC/Prescaling and Conversion Time" im Datenblatt gibt eigentlich erschoepfend Auskunft darueber. Das "sbi" in dem Beispielcode oben in einem Diskussionsbeitrag zum gcc-tutorial noch auftaucht ist mir schleierhaft, da kann ich mir die Aktualisierung auch sparen. Falls das im Artikel gezeigte Beispiel nachweislich falsch sein sollte: bitte aendern.
MfG M. Thomas

Butterfly schoen und gut, aber diese beiden Hinweise in letzter Zeit mit der Preisangabe "30Eur"... Ist das irgendwo ein Lager "zu voll" und wird hier versucht "etwas Werbung" zu machen? Der Preis ist "normal" aber wenn man sich umschaut und/oder sich mit ein paar Leuten für eine Sammelbestellung zusammentut gibt es die Teile deutlich guenstiger.

==Links korrigiert==
Einige der Links im Kapitel 11.1.1 (Messen eines Widerstandes) funktionieren nicht. Dies wären:
* http://www.mypage.bluewin.ch/ch_schifferle/AtmelC/Uebungen/Allgemein/UartPrintF.c
* http://www.mypage.bluewin.ch/ch_schifferle/AtmelC/Uebungen/Allgemein/UartPrintF.h
* http://www.mypage.bluewin.ch/ch_schifferle/AtmelC/Uebungen/Poti/makefile

--[[Benutzer:Oxygene|Oxygene]] 12:05, 12. Nov 2004 (CET)

==Tabellen==
Habe die Tabellen übersichtlicher gemacht, überflüssige Tabellen durch gewöhnliche Einrückungen ersetzt und recht viele Kommafehler bei Konditionalsätzen berichtigt (so um die 762 *g*). Inhaltlich ist alles gleich geblieben.
--[[Benutzer:Oxygene|Oxygene]] 15:01, 12. Nov 2004 (CET)

==Inhaltliches==

Danke fuer die Korrekturen, einige der Fehler sind sicher "auf meinem Mist gewachsen". Die Links zu "Messen eines Widerstands" sollten ganz raus, entweder ein aktualisiertes Beispiel direkt im Text oder in einem anderen Wiki-Artikel oder ersatzlos streichen. Schlussendlich ist es ein avr-gcc Tutorial die Beispiele sollten avr-gcc-Spezifisches erläutern und den manchmal etwas "trockenen" Text auflockern. Wie man einzelne Komponenten des AVR ansteuert hat nur in seltenen Fällen mit der Impementierungssprache zu tun. Hier vor allem dann, wenn die avr-libc entsprechende "APIs" zur Verfügung stellt. Alles Andere gehört eigentlich in ein "sprachunabhängiges" AVR-Tutorial. Das avr-gcc Tutorial "schleppt" mein Meinung in dieser Hinsicht noch einige Altlasten mit. [[Benutzer:mthomas]]

Also ich habe das Tut durchgearbeitet und alle mir auffallenden Fehler korrigiert. Man hat da sofort bemerkt, von wo an die Texte von dir geschrieben wurden, da die Kommafehler schlagartig aufhörten ;)
Da sind auch ein paar Formulierungen, die ich persönlich nicht so passend finde ("voll krass"), die wollte ich aber nicht ändern, da das hier eher dein Baby ist, es sei denn, du hast nichts dagegen, dass man da etwas rumbastelt. Will dir hier nicht dazwischenpfuschen und deine Pläne durcheinander bringen.
--[[Benutzer:Oxygene|Oxygene]] 02:21, 15. Nov 2004 (CET)

Habe in naechster Zeit nicht vor, an dem Tut. weiterzuarbeiten. Vielleicht dann am ehesten im Abschnitt "Assembler/C mixed-language". Mach' was du fuer richtig haellst.
Go ahead. Wird sich schon alles "ergeben". --mt

==Aufteilung in Kapitel==
Ich habe das Tutorial mal auf kleinere Unterkapitel aufgeteilt. Das ist IMHO
* übersichtlicher
* modemfreundlicher
* einladender (ein Monsterartikel schreckt ab)
Einziger Nachteil: Das Inhaltsverzeichnis muss manuell auf dem neuesten Stand gehalten werden.

Vorhin im Chat wurde mir geraten, vorher zu fragen. Daran hab ich leider nicht gedacht, also hole ich das jetzt nach. ;-)
--[[Benutzer:84.167.145.172|Chris]] (unregistriert) 17:42, 23. Apr 2005 (CEST)

Prima, das ";-)". Ist man mal einen Tag nicht in dem Chat, schon wird gefuhrwerkt. Kurz: dagegen. Lang: Es gab vorher schon ein uebersichtliches Inhaltsverzeichnis. Modemfreundlicher - na ja, ich bin von zu Hause auch ueber Modem/ISDN "drin", so gross ist der Text nun auch wieder nicht, ich habe von zu Hause gelegentlich Kleinigkeiten korrigiert ohne das mich die Geschwindigkeit gestoert hat. De facto wird "Seite speichern" auf die lokale Platte und danach offline durchlesen fuer Modemnutzer (non-flatrater) ohnehin die uebliche Vorgehensweise gewesen sein. Gelesen wird der Artikel um ein vielfaches mehr als bearbeitet. Nun heisst es, x-mal "Seite speichern" und danach durch die gespeicherten html-Seiten wurschteln. Einladend: mag sein, ist subjektiv. Es war fuer mich einfacher, ueber den ganzen Artikel drueberzuschauen, eventuell zu verweisen, zu verschieben oder eine neues Kapitel dazuzwischenzuschieben. Die abschnittweise Bearbeitung war ebenfalls zumindest fuer mich gut genug. Ein Kapitel einzufuegen heisst jetzt auch, die Verlinkung ordentlich wieder zusammenzubauen und an den angeblich "einzigen Nachteil" zu denken. Der schnelle pdf-Export fuer 'Korrekturabzuege' wird jetzt zur Qual. Nun denn, entweder wieder ein langer Artikel oder ich werde mein Engagement fuer dieses Tutorial deutlich einschraenken, bzw. einen 'Fork' weiterpflegen. Aber es gibt ja noch andere Wiki-Nutzer, die Inhalt beizusteuern. Vieleicht fuehrt ja das zerrissene Tutorial dazu, dass deren Anzahl steigt.
Martin Thomas (mthomas/131.246.51.xx)

Nicht so resignierend. Erstens steht in dem Wiki, dass jeder mitmachen kann (da steht nix von vorher nachfragen), zweitens kann man Aenderungen ja jederzeit rueckgaengig machen. Also, nicht (gleich?) entmutigen lassen :)
Ich persoenlich finde die aufgeteilte Version praktischer. Ich kann mir einfach eine Adresse aufschreiben, wo ich gerade war - ohne dann ewig lang dort hin scrollen zu muessen, wo ich wirklich war. Ich denke auch, dass die armen Modem-Benutzer und/oder die, die nicht staendig die Moeglichkeit haben, online zu sein/gehen, immer weniger werden und man deshalb - so grob es klingen mag - auch weniger Ruecksicht auf sie zu nehmen braucht (kann man jetzt als Argument sowohl fuer als auch gegen die Aufteilung sehen..)
--[[Benutzer:80.108.115.184|80.108.115.184]] 00:27, 24. Apr 2005 (CEST) sym

Ich find die zusammenhängende version auch besser.
Zar kann jeder am wiki mitarbeiten, aber wenn es um so gro�?e umstellungen geht, sollte man zufor nachfragen, sonst kann die arbeit schnell umsonst gewesen sein.
Ich winn für eine widerherstellung der zusammenhängenden Version. --[[Benutzer:84.57.135.238|84.57.135.238]] 11:51, 24. Apr 2005 (CEST) scout

Die �?nderung wurde jetzt also reverted, ohne ein Meinungsbild abzuwarten. Nagut. Dann bitte ich hiermit um eine offizielle Abstimmung, um diesen Sachverhalt zu klären, ohne es nach Willkür-Entscheidung (meinerseits oder von anderen) aussehen zu lassen. Ich schlage als Laufzeit 1 Woche vor, Stichtag wäre dann also der 1. Mai 2005 um 12:00.

'''Abstimmung''' über die Frage: Soll das Tutorial in Kapitel aufgeteilt werden? --Chris 12:45, 24. Apr 2005 (CEST)

'''Dafür''':
* Chris

'''Dagegen''':

----
Der Hauptautor dieses Artikels (Martin Thomas) ist dagegen, das ist für mich Grund genug. Ich sehe auch keine gro�?en Vorteile an der Aufteilung, nur viel zusätzliche Arbeit durch das manuelle Anpassen des Inhaltsverzeichnisses. Die vor/zurück/hoch-Links erhöhen das Rauschen und tragen auch nicht gerade zur �?bersicht bei. -[[Benutzer:Andreas|Andreas]] 15:24, 24. Apr 2005 (CEST)

Ohne jetzt zu Aufteilung/Nichtaufteilung Stellunge nehmen zu wollen und mthomas' Arbeit in Ehren, aber _das_ sehe ich nicht als Argument. Von mir sind auch schon Artikel entfernt/geloescht/etc. worden, ohne mich zu fragen. So lauft's in einem offenen wiki! --15:30, 24. Apr 2005 (CEST)sym

Man sollte sich von der Vorstellung freimachen, dass jedes Wiki nur weil es ein Wiki ist automatisch per Mehrheitsentscheidung verwaltet werden muss. Wenn jemand in einen Artikel so viel Arbeit reingesteckt hat wie Martin, dann hat seine Stimme nun mal mehr Gewicht. -[[Benutzer:Andreas|Andreas]] 15:50, 24. Apr 2005 (CEST)

Von Mehrheitsentscheidung hab ich gar nicht gesprochen.
Aus der Sicht als (potentieller) "Konsument" des Tutorials: Ich hab erstmals zu lesen angefangen, als es unterteilt war. Und mit der Zurueck-Umstellung auf die endlos lange Seite hab ich wieder das Interesse daran verloren. Schade - danke aber trotzdem fuer die Muehe. --[[Benutzer:80.108.115.184|80.108.115.184]] 21:36, 24. Apr 2005 (CEST)sym

==Frage 2 zum Codebsp.==

Hallo zusammen,
ich nutze beruflich (ab und an) den IAR-Compiler für die AVRs.
Nun steige ich privat in den AVR-GCC ein. Donglefrei halt 8-).
Euer Tutorial ist eine echte Hilfe dabei! Super, wie die ganze
Seite. Ich würde gerne auch mithelfen, will aber nicht einfach so
rumeditieren. Daher erst einmal nachgefragt:

'''zu 16.2.2. (Programmspeicher) Wort lesen.'''

ptrToArray = (uint8_t*)(pgm_read_word(&pgmPointerToArray1)); <br/>
// ptrToArray zeigt nun auf das erste Element des Byte-Arrays pgmPointerToArray1

1. Das Byte Array, auf das gezeigt werden soll, ist doch eigentlich pgmFooByteArray1[]. pgmPointerToArray1 ist ein Pointer. Könnte gerade Anfänger verwirren<br/>
2. ptrToArray ist eine Pointervariable, die im SRAM liegt und die
in das SRAM zeigt. Sie zeigt damit NICHT auf pgmFooByteArray1[].<br/>

Mit ARV-GCC compiliert und in AVRStudio geladen, ergibt sich folgendes, wenn man die entsprechenden Variablen ins Watchfenster holt:<br/>

pgmFooByteArray1<br/>
Value [...] / Type const unsigned char[3] / Location 0x001A [FLASH]<br/>
[0] 18 / Type const unsigned char / Location 0x001A [FLASH]<br/>
[0] 3 / Type const unsigned char / Location 0x001B [FLASH]<br/>
[0] 70 / Type const unsigned char / Location 0x001C [FLASH]<br/>

pgmPointerToArray1<br/>
Value 0x001A / Type const unsigned char * const / Location 0x0018 [FLASH]<br/>-> Value 18 / Type const unsigned char / Location 0x001A [FLASH]<br/>

ptrToArray<br/>
Value 0x001A / Type unsigned char * / Location 0x0060 [SRAM]<br/>
-> Value 98 / Type unsigned char / Location 0x001A [SRAM]<br/>

Man kann mit pgm_read_byte(ptrToArray+i) natürlich pgmFooByteArray1[] lesen, da nur der Wert von ptrToArray interessiert, da er im Macro wieder auf unit16_t umgecastet wird. Es wäre aber einfacher, wenn man das Resultat von pgm_read_word(&pgmPointerToArray1) in eine uint16_t einliest und diese dann an pgm_read_byte() übergibt.

Das Beispiel hat (zumindest mir am Anfang) suggeriert, dass es wirklich möglich ist, einen Pointer zu deklarieren, über den man direkt, also ohne Macros aus pgmspace.h, aus dem Flash lesen kann. "...ptrToArray zeigt nun auf das erste Element des Byte-Arrays... "

Vielleicht sollte man das etwas klarer machen. Zum Beispiel mit dem expliziten Hinweis, dass es einen solchen Pointer nicht gibt und immer Code bemüht werden mu�?, um das Flash zu lesen. Vielleicht kann man das Beispiel ja auch mit einer unit16_t Variablen, statt mit einer uint8_t * Variablen machen.

Falls erwünscht, schreibe ich es gerne um.
--[[Benutzer:EdeC|EdeC]] 19:39, 2. Sep 2005 (CEST)

Glaube, dieser Textabschnitt ist noch relativ unveraendert von mir, sorry, falls es zu unklar ist. Sinn des ganzen Abschnitts und er Beispiele ist es, zu verdeutlichen dass eben diese "direkten" Pointer (noch) nicht im funktionieren. Ja, Programmspeicherzugriff ist beim IAR-Compiler anders und v.a. einfacher. Aber das Grundprinzip und die Problematik ist wenn recht erinnert schon erlaeutert (explizit und mit etwas "Plappertext"). Vermute, die Verwirrung kommt eher durch die IAR-"Vorbelastung". Falls die Beispiele also tatsaechlich suggerieren, dass es diese Funktionalitaet gibt, bitte Aenderungsvorschlag einfach einbauen. Code aber bitte nur aendern, wenn die Beispiele falsch sind, ansonsten einfach /*Kommentare*/ und/oder ein paar zusaetzliche Beispiele einbauen. Ich habe absichtlich einige nicht-triviale Beispiele eingetragen, die "einfachen Sachen" stehen ja auch da und in vielen anderen Beispielen/Tutorials ebenfalls.

Martin Thomas

Ich finde, der Abschnitt erklärt sehr gut und verständlich!
Lediglich bei dem Code-Beispiel waren IMHO ein paar Unsauberkeiten,
die mich zuerst in die Wüste geschickt haben. Das hatte allerdings
den positiven Effekt, da�? ich mich ziemlich drin verbissen und dadurch
etliches dazu gelernt habe 8-) .

--[[Benutzer:EdeC|EdeC]] 13:54, 10. Sep 2005 (CEST)

----

Fuse-Bits
Ich hage mal gehört der atmega habe soetwas. Wovor schützt das genau? hann ich sie auch wieder löschen??

Stelle solche Fragen lieber im Forum. Hier ist es a) Zufall, wenn mal jemand über deine Frage stolpert und b) zerfretzelt es das Wiki. Also zu den [[AVR Fuses]] gibt es einen eigenen Artikel. Grundsätzlich dienen die Fuses dazu eine bestimmte Hardwarekonfiguration des AVR einzurichten. Wenn man dabei einen Fehler macht, ist der AVR u.U. Schrott. Daher gilt besonders bei Thema Fuses: '''Datenblatt sorgfältig lesen'''.

--[[Benutzer:Stefan|Stefan]] 17:58, 28. Aug 2006 (CEST)

== Baudraten Macros mit UL ==

Die Baudraten-Macros aus dem Tutorial scheinen recht populär zu sein, ich habe sie schon in mehreren Projekten gesehen. Leider funktionieren sie nur, wenn F_CPU als signed Long definiert ist. Sowohl Mfile, AVR Studio als auch mein AVR Eclipse Plugin definieren F_CPU aber als UL.

Wenn man die Formel minimal ändert, dann funktioniert es auch mit UL:

<c>
/* UART-Init beim AT90S2313 */

#ifndef F_CPU
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann
F_CPU im Makefile definiert werden, eine nochmalige Definition
hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
#ifndef/#endif

Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio
verwendet wird und dort eine andere, nicht zur Hardware passende
Taktrate eingestellt ist: Dann wird die folgende Definition
nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?)
von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
noch nicht definiert: */
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
#define F_CPU 4000000UL // Systemtakt in Hz
#endif

#define BAUD 9600UL // Baudrate

// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif
</c>

Irgendwelche Einwände wenn ich das im Tutorial ändere?

Thomas