Mikrocontroller.net - Benutzerbeiträge [de]

Reichelt-Wishlist

2012-06-11T21:29:37Z

Sebion7125: /* Controller, FPGA und CPLD */

== Reichelt Wunschliste ==

Auf dieser Seite können Wünsche zur Erweiterung des Reichelt-Lieferprogramms eingetragen werden. Es ist keine offizielle Wunschliste von Reichelt und es ist nicht bekannt, ob Reichelt-Mitarbeiter diese Seite regelmäßig sichten. Reichelt sollte sicherheitshalber regelmäßig angeschrieben werden, damit diese Liste nicht in Vergessenheit gerät.

Damit sich die beliebtesten Artikel herauskristallisieren, macht jeder einfach '''einen''' virtuellen Strich dahinter: | (Windows: ALT-GR Taste und < Taste drücken, Mac OS X: Alt-Taste und 7 Taste drücken). Alle fünf Striche (|||||) bitte immer ein Leerzeichen einfügen. Blöcke von 50 Strichen werden regelmäßig gegen eingefärbte Kolonnen von Ausrufezeichen ausgetauscht, die den Reichelt-Mitarbeitern hoffentlich umso mehr auffallen ;)

Neue Artikel einfügen darf und soll natürlich auch jeder - aber bitte die Liste vorher durchgehen (Tipp: Browser-Suchfunktion nutzen)! Einfach ganz viele Striche auf einmal hinter einem Artikel einzufügen ist zwecklos. Das erkennt man in der History und es gibt viele Leute, die diese Seite überwachen...

'''Nicht sinnvoll''' ist etwas sehr exotisches, wie z. B. einen ganz bestimmten super schnellen AD-Wandler hier aufzulisten! Neue Artikel müssen sich für Reichelt ja auch rentieren und wirtschaftlich "an den Mann bringbar" sein. [Die Entscheidung, ob sich was rentiert und ob es exotisch ist, sollte man vielleicht Reichelt und den eventuellen späteren Strichle-Setzern überlassen, statt im Voraus die Schere im Kopf walten zu lassen.]

= Wunschliste =
== Halbleiter ==
=== Controller, FPGA und CPLD ===

* Ajile aj-100 (Java Real-Time Prozessor) ||||
* ALTERA CPLD EPM30xx - Familie |||
* ALTERA CPLD EPM70xx - Familie ||||| ||||| ||||| ||||| |||
* ALTERA Cyclone2 - Familie ||||| ||||| ||||| ||||| ||||
* ALTERA Cyclone3 - Familie ||||| ||
* ALTERA Flex10K - Familie ||||
* ALTERA MAX-II (CPLDs) ||||| ||||| ||||| ||||
* ALTERA MAX-V CPLDs |
* ARM: Cortex M3 Nachfolger für die LPC2x
* Atmel AT89LP4052 PDIP ||||| ||||| ||||
* Atmel AT89S2051/4051 |||||
* Atmel AT90PWM3B (µC für Servosteuerungen und z.b. Motorsteuerungen) ||||| ||||| ||||| ||||| ||||| |
* Atmel ATA6612/13 (LIN-Bus SoC) ||
* Atmel ATmega 1284P PDIP |||
* Atmel ATmega 168PA, 88PA, etc. ||||| ||||
* Atmel ATmega 16A und 32A in TQFP und PDIP ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||
* Atmel ATmega 16L und 32L in TQFP (wäre ATmega 16/32L8 TQ) ||||| ||
* Atmel ATmega16M1 in TQFP ||
* Atmel ATmega324P in TQFP und PDIP ||||| ||||| ||||| |
* Atmel ATmega324PV in TQFP und PDIP ||
* Atmel ATmega328P in TQFP und PDIP {{Reichelt50|FF0000}} ||||| ||||
* Atmel ATmega48P in TQFP und PDIP ||||
* Atmel ATmega644p(a) / ATmega1284p(a) in TQFP und PDIP ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||
* Atmel ATtiny2313V in SO und PDIP |||||
* Atmel ATtiny4313 ||
* Atmel ATtiny261 (auch 461 und 861; bevorzugt DIP) ||||| ||||| ||||| ||
* Atmel AVR Controller mit Funkanbindung z. B. AT86RF230, AT86RF211, AT86RF401, dazu passende Quarze (evtl. SMD) 18,080 MHz (Crystek P/N 016758), Spulen 39nH. {{Reichelt50|FF0000}}{{Reichelt50|00FF00}}||||| ||||| ||||| ||||| ||||| ||
* Atmel AVR mit USB: AT90USB82 und ATmega32u4 {{Reichelt50|FF0000}} ||
* Atmel AVR32 im TQFP ||||| ||||| ||||| ||||| ||||
* Atmel Cortex M3 SAM3S im QFN/LQFP Gehäuse |
* Atmel Dream Sound Synthesizer Chips, z. B. ATSAM3103 und ATSAM3308 ||||| ||||
* Axis Etrax 100LX Risc Processor (kostenloses Linux-System vorhanden) ||||| ||||
* Bessere Auswahl: statt MSP430F147, F148, F149 wenigstens einen mit DAC -> MSP430F16x
* CY7C68013A-56PVXC (Cypress EZ-USB FX2LP) ||||| ||
* Cypress PSoC Mikrocontroller ||||| ||||| ||||| ||
* Freescale DSP56F801 ||||
* Freescale HCS12 Controller ||||| ||||| ||||| ||||| ||||
* Freescale MC9S08QD4 ||
* Freescale MC9S08QEx |
* Freescale MC9S08QG8 (DIP 16) ||||| ||||| ||||| ||
* Freescale Prozessoren (Coldfire) (16 + 32 Bit) ||||| ||
* Infineon XC866 ||||| ||||| ||||| ||||| |||
* Lattice GAL 26V12 |
* Lattice ispMACH 4032C / 4064C / 4128C |||||
* Luminarymicro Stellaris Serie (Cortex-M3) ||||| ||
* Maxim/Dallas DS89C450 |
* Mehr FPGAs (v.a aktuellere) von Xilinx, z. B. Spartan III , ALTERA CYCLONE II (v.a. auch größere Typen, die noch im TQFP-Gehäuse zu haben sind wie z. B. XC3S400 oder XC3S500E (PQFP208)) {{Reichelt50|FF0000}}{{Reichelt50|00FF00}}{{Reichelt50|0000FF}}{{Reichelt50|00FFFF}}||||| ||||| | ||||| ||||| |||||
* Microchip dsPIC33FJ128GP802 ||||
* Microchip PIC12F1822 |
* NXP LPC1114 |
* NXP LPC1313 |
* NXP LPC1343 |
* NXP LPC1751 ||
* NXP LPC1754 ||
* NXP LPC214x-Serie ARM7-Controller ||||| ||||| |||||
* NXP LPC23xx/24xx ||||| ||
* NXP SAA5281 Videotextinterface ||||| ||||
* Parallax Propeller CPU, 8 Cogs - DIP 40 ||||| ||||| ||||| ||||| ||||| ||||| ||||| |
* PICAXE von Revolution Education Ltd ||
* Renesas M16C ||||| ||||
* Silabs C8051F320 USB Mikrocontroller ||
* Silabs C8051F340 USB Mikrocontroller ||
* Silabs Si4735 im SSOP-Gehäuse (AM/FM-Empfänger) |||
* SSV DIL/NetPCs [http://www.dilnetpc.com]http://www.dilnetpc.com ||||| ||||| ||||
* ST ST7MC... (µC für Servosteuerungen, und vor allem Brushless-Motoren) ||||| |||||
* ST STM32 Serie (Cortex-M3) {{Reichelt50|FF0000}}||||| ||||| |||
* ST STR7 Serie (ARM7TDMI) ||
* TI MSP430F167, TI MSP430F168 ||||
* TI MSP430F2001/2/3 etc. im RSA-Gehäuse (=QFN) ||||| ||
* TI MSP430F2618 |||
* TI MSP430FG4618 |
* TI TMS470 Arm7 ||||| ||||| ||||| ||||| |
* TI TUSB3210 ||||| ||
* Ubicom SX20 SX28 IP2022 ||
* Western Design Center 65c816 |||
* XC3S 400 TQ144 |||
* Zilog Z8 Encore-Microcontroller (bis 64k Flash, I²C, SPI, 2xUART, ADC, on-Chip Debugger ...) [http://www.zilog.com/products/family.asp?fam=225]www.zilog.com ||||| |
* Zilog ZNEO-Microcontroller (Z16Fxxx, bis 128k Flash, 4k RAM, bis zu 76 I/Os, 3 Timer, 10-bit A/D, externer Daten-/Adressbus, on-Chip Debugger) [http://www.zilog.com/products/family.asp?fam=236] www.zilog.com |

=== Speicher ===

* 24LC256 oder 24AA256 oder 24LC512 oder 24AA512 ||||| |||||
* 24AA02E48 (EEPROM mit einprogrammierter MAC-Adresse) |
* 3.3V async SRAM ab 16KByte ||||| |||
* 3.3V DRAM ||||| |
* Atmel DataFlash, z. B. AT45DB081B (8 MBit Flash-Speicher an seriellen Bus im 8poligen Gehäuse) {{Reichelt50|FF0000}}{{Reichelt50|00FF00}}||||| |
* EEPROM mit SPI Schnittstelle 25XX Serien ||||| ||||
* F-RAM mit SPI von RAMTRON ||||| ||||
* FM25L16 o. FM25L256 SPI-FRAM |
* FPGA Konfigurations-EEPROMS AT17LV256, AT17C65/128/256.../XCF04S/... ||||| ||||| ||||| ||||
* NexFlash spiFlash NX25P16 (16MBit serial Flash im SO8-Gehäuse) ||||| ||||| ||||| |||
* RAMs (SRAM oder DRAM) mit ordentlicher Kapazität (z. B. HY57V641620HG oder besser) ||||| ||||| ||||| ||||
* Schnelles statisches RAM 128kB (10, 12, 15 oder 20ns, z. B. Samsung K6R1008C1D-UI10 oder CY7C1019D-10ZSXI) (5V/3,3V) {{Reichelt50|FF0000}}||||| ||||| ||||
* Serielle SRAMs (Microchip 23K256) ||

=== Einzeltransistoren, Op-Amps, MOSFET-Treiber ===

* OPA134, OPA2134, OPA4134 low noise audio OpAmps |
* 2SC1971 Transistor mit hoher Frequenz und viel Leistung für Endstufen ||
* AD623 Single Supply,Rail-Rail, InstrOpamp ||||| |
* AD628 InstrOpAmp, high voltage inputs |
* AD8601 Rail to Rail Opamp |
* BSH205 P-Channel 1.5V(GS), 0.75A, 12V D-S |||
* BUF420AW Schaltnetzteil Transistor von STM |||||
* Digitaltransistoren (BCR*), auch als Pärchen NPN/PNP (BCR10, BCR08pn) ||||| ||||
* IPS5451S intelligenter Leistungsschalter 50 V, 35 A, 25 mΩ |
* IPW60R045CS Infineon MOSFET 600V 45mOhm Rdson 30ns tr+tf (niedrigster Rdson in der Klasse) |
* IR2011 MOSFET Treiber |||
* IR21844 DIL (High-Speed IGBT-Driver) |||
* IR3313 o.ä. Intelligenter Leistungsschalter 32V/90A, einstellbare Strombegrenzung |||
* IRC540 (HEXFET) | (kann ggf. durch bereits vorhandenen IRCZ 44 ersetzt werden)
* IRF7503/IRF7506 Dual MOSFET SMD ||||| |||||
* IRFI4212H-117P Doppel-MOSFET (f. Klasse D-Verstärker) |
* J-FET BF545 A,B,C (entspricht BF245 in SMD ) |
* Leistungs-OP LM675 von National ||
* LM397, LM321 o.ä. single op-amp in SOT23-5 5-30V supply {{Reichelt50|FF0000}}||||| ||||| ||||| ||||| ||||| ||||
* MAX4420 MOSFET Driver ||
* MAX4429 MOSFET Driver ||
* MC 34152 D-SMD SO8 Dual MOSFET Driver |
* Mehr FET-Treiber (TI UCC3372x, HIPxxx , die neueren Brückentreiber von Maxim ||||| |||
* mehr FETs und IGBTs (nicht nur IRF, sehr gut IXYS <- und sauteuer!) ||||| ||||
* MJD31C NPN Transistor SMD DPAK 3
* Niederohm-FETs in SO8, N und P ||||| ||||| ||
* Philips PDTD113E/123E und PDTB113E/123E (PNP und NPN im sot23 mit internen Widerständen für Basis und PullUp/Down ||
* Schnellere und gleichzeitig günstige OpAmps; Beispiel AD8055 ||
* Si4562DY N- and P-Channel 2.5-V (G-S) MOSFET SMD ||||| ||||| ||
* SPP20N60C3 Infineon MOSFET 600V 190mOhm Rdson <10ns tr+tf (Schnellste Schaltzeit in der Klasse) ||||| |
* TLC2264 (Quad Rail-to-Rail Operational Amplifier) ||
* TLV2782 (1,8V Rail-to-Rail OP) '''unklar: War "TLV27(2"''' |||||
* TLC3702 Komparator |
* TLV2382ID Rail-Rail-OP von TI |
* Sehr schnelle Op-Amps wie LMH6733 o.a in single und trible |

=== Schaltregler (Buck, Boost, DC/DC,...) ===

* 5,2V Lowdrop Längsregler LF52 im TO252AA von STM |||||
* generell Spannungsregler, LOW-DROP, SMD (DPAK, D2PAK)
* Größere Auswahl an Step-up Reglern ||||| ||||| ||||| ||||| ||||| |||||
* L4941 Spannungsregler 5V/1A in SMD-Ausführung (DPAK) ||||| |||||
* L5970 o. L5972 1 bzw. 2A, 250kHz Schaltregler im SO8 |
* L5973D 2,5A, 250kHz, Schaltregler im SO8 (ca. 1€) |||||
* LF50ABDT Spannungsregler SMD DPAK 5.0V very low drop |
* LM1084-ADJ (low dropout voltage positive regulator) |
* LM1117 (low dropout voltage regulator) - 1,8V ||
* LM1117MPX-1.8 und LM1117MPX-3.3 (SMD-Spannungsregler SOT-223) ||||| ||||| |||||
* LM2734 Schaltregler |||
* LM317EMP oder LM317AEMP SMD-Spannungsregler einstellbar (SMD TO-223 Gehäuse) ||||| ||||| ||||
* Maxim MAX629, MAX1795, MAX1703 (Aufwärtsregler / Step-Up-Konverter) ||||| ||||| |||||
* MAX 8865 Dual, Low-Dropout, 100mA Linear Regulator |
* MC78LCxx Serie - Ultra Low Drop Spannungsregler 3-5 Volt mit 1 Mikro-Ampere Ruhestrom ||||| ||
* MIC29300/29301 Spannungsregler 5,0V 3A im TO263(SMD) Gehäuse ||
* NCP3063: 1.5 A, BUCK _&_ BOOST Inverting Switching Regulator DIP8/SOIC8 (MC34063 upgrade) (0,32$) |
* R-523.3PA Schaltregler 4V - 18V Eingang, variabler Ausgang (Nominalspannung 3.3 V) mit nur 2-4 externen Bauteilen bei > 90% Effizienz
* R-723.3P Schaltregler 4V - 28V Eingang, variabler Ausgang (Nominalspannung 3.3 V) mit nur 2-4 externen Bauteilen bei > 90% Effizienz |
* R-783.3-0.5 Schaltregler 4,75V - ca. 18V Eingang; 3,3V Ausgang (Hersteller Recom) ||||| ||||
* R-785.0-0.5 Schaltregler 6,5V - 30V Eingang; 5,0V Ausgang (Hersteller Recom) ||||| |||
* R-785.0-1.0 Schaltregler, Ausgang 5,0V, 1A ||||
* Spannungsregler SMD in DPAK ||||| ||||| ||||| ||||| ||||
* ST1S10 günstiger "Monolithic synchronous step-down regulator" bis zu 3A Ausgang |
* TI TPS61070 3.3V-75mA-aus-einer-NiMH-Zelle (+ passende SMD-Induktivität) |
* ViPER Schaltregler von ST ||
* ViPER 12A |
* LM3578 sehr universeller, weil in allen Konfigurationen einsetzbarer Schaltregler (DIP8) von NS mit 1.25V Vref |

=== Konstantstromquellen (LED, Akkus) ===

* CCS-Akkulade-IC (z. B. CCS9620SL) (siehe [[http://bticcs.com/]]) |||||
* HV9910 Schaltregler für die Hochleistungs-LEDs Ub=8-450V; I beliebig; Eff. besser 90% ||||| ||||| ||||| ||||| ||||| ||||| |||
* LM340x High Power LED-Treiber von National ||||
* LTC3490 (350mA-Konstantstromquelle) ||||| |||||
* Max1555 - LiPo Lade IC |||||
* MAX7313 16 LED-PWM-Dimmer (Im Gegensatz zu den Philips-ICs ist jede einzelne LED-Dimmbar, dafür nur in 16 Schritten) ||||| ||||| |
* PCA9685 16Kanal 12Bit PWM LED Controller ||||| |||
* STP08CL596B1 DIP16 STM, LOW VOLTAGE 8-BIT CONSTANT CURRENT LED SINK DRIVER ||
* STP08CL596M SO16 STM, LOW VOLTAGE 8-BIT CONSTANT CURRENT LED SINK DRIVER ||||
* STP16CL596B1R DIP24 STM, LOW VOLTAGE 16-BIT CONSTANT CURRENT LED SINK DRIVER ||
* STP16CL596M SO24 STM, LOW VOLTAGE 8-BIT CONSTANT CURRENT LED SINK DRIVER |||
* TLC5940 16 Kanal PWM LED-Treiber ||||| |||
* UDN 2987 LW (Source Driver UDN2987 in SMD-Bauform) ||

=== Ethernet, I²C (2Wire), SPI und andere Interfaces ===

* CLC020 und CLC021 (National Semiconductor) Parallel Component nach SDI-Converter |||||
* CP2120 single-chip SPI to I2C bridge and GPIO port expander |
* CS8900A Ethernet-Controller ||||| |||
* CY7C67300 (Cypress) dual role USB controller mit OTG ||||| ||||| ||||| ||||| |||
* DP83848C (Ethernet Physical Layer Transceiver/PHY, MII/RMII-Schnittstelle, passend zu AT91SAM7X) |||
* Ethernet Magnetics (Auch POE) ||||| |||||
* Fast Ethernet-Controller (DE9000A/B/E, AX88796B, ...) |
* FTDI High Speed Chips, z. B. FT2232H (USB - UART/FIFO IC)||||| |
* Generell mehr 1-Wire-ICs ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||
* Generell mehr I²C-ICs {{Reichelt50|FF0000}}||||| ||||| ||
* Generell mehr SPI IC ||||| ||||| ||||| ||||| ||||
* IP101 PHY von IC+ (Distri für DE [http://www.topas.de/tt/cfs/icp_cfs_mai05.htm Topas]) ||
* ISD 5116 (Sprachaufnahme bis 16min & I2C-Interface) ||||| ||||| ||||| |
* LTC1694-1 (I2C/SMBus Accelerator) ||||| |
* MAX6650 I²C-Lüftermonitor ||
* MAX6958 / MAX6959 (I²C 4-Digit, 9-Segment LED Display Drivers with Keyscan) ||||| ||||| ||
* MAX7311AWG 2Wire Interface von Maxim ||||
* MCP23008 8Bit I2C I/O Expander |||
* MCP23016 16Bit I²C I/O Expander ||||| ||||| ||| (verfügbar)
* MCP23S08 8BIT SPI I/O Expander |
* MCP23S17 16Bit SPI I/O Expander (aber ohne Schmidt-triggerd Eingänge wie der 23x16) ||
* P82B86 (I2C Dual Bi-Directional Bus Buffer) ||
* Philips PCA82C252 oder TJA1054A oder vergleichbar ("Fault-Tolerant" CAN Transceiver, 11898-3) ||||| |||||
* Power over Ethernet Bausteine z. B. LM5070 |||
* RS485 isoliert: z. B. Burr-Brown ISO485 o.ä. ||||| |||
* sn65hvd230/231/232 (CAN-Transceiver) in SO8 |||
* TH3122 K-Line Interface von Melexis ||||| ||||
* TH8080 LIN Transceiver von Melexis (oder vergleichbare) ||
* TI ISO1050 (Isolierter CAN-Transceiver) |||
* SC18IM700 o.ä. I2C to UART-Converter ||

=== ADC, DAC und PWM ===

* 16-bit A/D-Wandler (waren von Maxim schon im Programm, sind aber wieder herausgeflogen?) ||||| ||
* AD7524 8-Bit DAC in SMD ||||| ||||| ||||
* ADS8320 ADC 16 Bit seriell ||||| ||||| ||||| ||||| ||||| ||||| |
* CS5641 von Cirrus...The CS5461 incl. two delta-sigma A/D converters.... ||
* D/A Wandler mit 4 oder mehr Ausgängen, z. B. TLC5620/TLV5629/AD5325 ||||| ||||| |||
* DAC7612 DAC 12 Bit seriell ||||| ||||| ||||| ||||| |||
* DAC8830 IDT (16Bit-DAC,ser. Input) ||||| |
* Generell mehr DAC's (auch die teureren) von TI ||||| |
* Generell mehr I2C IC (ADC, DAC, DSP, u.a. Crystal, BurrBrown etc.) |||||
* Generell mehr PWM-SIC's |||||
* LTC 1655(L) N8 16 Bit DAC interne Ref 2.048/1.25V(L Type) SPI Interface ||
* LTC24xx (24-Bit Delta-Sigma ADC) ||||
* MAX127/128 8-Kanal 12bit ADC mit I2C-Interface |||
* MAX528 8-fach 8Bit DAC mit Output Buffer seriell |
* MCP4725A0 und MCP4725A1 D/A-Wandler 12 Bit I²C ||
* Philips TDA1543 - 2x16-Bit DAC |
* TI PCM1804 Audio-ADC||||
* TI PCM2707 USB-Audio-DAC ||
* Video-AD-Wandler z. B. LTC2208 (16 Bit 130 MS/s) für FPGA und SDR |
* IR Class-D Amplifier IRS2092 ||

=== Sensoren und Aktoren ===

* 4Hz Supersense µblox LEA-4S GPS module (Importer pointis.de) + Passende Passives Patch antenna (zB. von inpaq.com) ||||| ||||
* Allegro Stromsensoren (z. B. ACS713, ACS756) ||||| ||||| ||||| ||
* Allgemein mehr Sensoren ||||| ||||| ||||| ||||| ||||| |||
* Anemometer ||||| ||
* BLDC-Motoren ||||
* Durchflussmesser (z. B. wie Conrad Nr.155374) ||||| ||||| ||||| |||
* Flexinol / Nitinol (Nickel-Titanium) / NanoMuscle Aktuatoren ||||| ||||| ||||| ||||| |||
* Freescale/Motorola Drucksensoren, besonders die gängigen aber noch fehlenden MPX4100AP, MPX4200AP, MPX4250AP mit der robusten Automotive Spezifikation und Stutzen für Schlauchanschluss = CASE 867B-04 ||||| ||||| ||||| ||||| ||||| ||||| ||
* FSRs (Force Sensing Resistor) von Interlink Electronics ||||| ||||| ||||
* Getriebemotoren wie RB35 oder RB40 ||||| ||||| |||||
* günstige Temp. Sensoren TC77 ||||| ||||| ||||
* Gyro Sensoren MURATA, ENC-03J A/B ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |
* Gyro, Drehwinkelgeber, Kreiselsensoren ähnl. Tokin CG-L43 {{Reichelt50|FF0000}} |
* Hall-Sensor(analog) Allegro A1301, A1302 |
* Hall-Sensor UGN3503, KMZ51 ||||| ||||| ||||| |||
* Hall-Sensoren ähnlich TLE4905, aber mit Vcc 3,3V, z. B. CYD1102G (TLE 4905L Hallsensor, 3,8-24V ist lieferbar seit 20.12.11) ||
* I²C-Bus Temperatursensor DS1631Z ||||| ||||| ||||| ||||| ||
* iMEMs Acceleration Sensors ADXL Series von Analog Devices ||||| ||||| ||||| ||||| |
* Induktions-Stromsensoren Coilcraft #J9199-A o.ä. ||||| |||
* IS471 Selbstmodulierende IR-Lichtschranke ||||| ||||| ||||| ||||| ||||| ||
* kleine Feuchtigkeitssensoren zur 'on-board-Montage' ||||| ||||| ||||| ||||| |||||
* LEM Stromsensoren (Transducer) der HAIS-Serie, speziell HAIS 50-P und 100-P ||||| ||||| ||||| ||||
* Luftdruck-/ Temperatur Sensor Intersema MS5534 (mit SPI- Interface) ||||| ||||
* Magnetfeld-Sensor (Kompass-Anwendung) KMZ52 ||||| ||||| |||
* Modellbau-Servos ||
* Piezo Minimotoren/Linearaktoren von Elliptec/Siemens einzeln und günstig ||||| |||||
* PIR Bewegungsmelder ||
* QT160 6-fach Touch Sensor IC ||||| ||
* Sensirion SHT11/SHT71 (oder auch SHT15/SHT75) {{Reichelt50|FF0000}}||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |
* Summer mit 20mA@5V ähnlich Conrad Nr.751553 (TDB05 kann mit 30mA@5V nicht von allen Controllern direkt getrieben werden) ||||| ||||| |||||
* Temperatur IC TC1047 |||
* Temperatursensor mit SPI-Interface LM74 ||||| ||
* Thermoelement Typ-K (MAX6675)/ Typ-J mit Steckverbinder und SPI ||||| ||||| ||||| ||||| ||||| ||||| |||
* Sensoren zur Umweltanalyse (Sauerstoffgehalt der Luft, pH-Wert, etc.) ||

=== Funk und Signalsynthese ===

* Clock generator IC's, z. B. PCK20?? von Philips |
* DDS-IC (Waveform-Generator) von Analog wie AD9833, AD9835 ||||| ||||| ||||| ||||| ||||| ||||| |||
* EM4095 (RFID) ||||
* LMX2306/LMX2316/LMX2326 PLL Synthesizer von National ||||| ||
* LTC5540 (RF-Mixer) |
* PLL Schaltkreise für Frequenzerzeugung. z. B. MC / ML145170 (SOIC16) / TSA5060A ||||| ||||| ||||| |||
* SI4735 Silicon Labs Radio ICs ||||
* TEA5757 FM-Tuner IC von Philips |||
* TEA5768HL FM-Tuner IC von Philips |||||
* TPS79318 1,8V 200mA LDO in (bestens für z. B. LPC210x µC) ||

=== sonstige ===

* 74HCxxxx komplette Serie ||||
* 74VHC-Serie komplettieren (z. B. 74VHC125D) ||||| ||
* 74ASxxx |
* 74ACTxxx |
* A3982 Motortreiber/Controller (1,5A, 2APeak, u.A. für RepRap's) ||
* Automotiv ICs z. B. LM1815, LM1915, LM1949, LM9011, LM9040, LM9044, LMD18400... ||||| |
* Bosch CJ125 (Lambdasonden-IC) ||||| ||||
* DS1616 von Dallas Datalogger-IC ||
* DTMF-Dekoder-Enkoder (8870, 8880) ||||| ||||| ||||| ||||| ||||| |||||
* HCT-Logik in SMD {{Reichelt50|FF0000}}||||| ||||| ||||| |||
* High Side Current Sense ICs wie MAX4172 ||||| |
* IRS2092 Class-D Audio Driver IC |||
* ISD 2560 -> SOIC Gehäuse (Sprachaufnahme IC) ||||| |
* ITS4141N o. BTS4141N Smart High-Side Power Switch (z. B. bestens für 24V geeignet!) ||
* Kleinere SMD-Bauformen (bes. bei ICs) ||||| ||||| ||||| ||
* L6205 Motortreiber (2Kanal, 2,8A, DMOS)|||||
* L6206N Motortreiber (Wird für OpenDCC benötigt, und ist derzeit nur SEHR schlecht erhältlich) ||
* LM3886 (68W Audioverstärker) ||||| |
* LMD18200 (H-Bridge) |
* LT-1117-CST-5 als Sot223 (adj und 3.3 gibts schon, 5 fehlt noch) |
* LTC 4411 ideale Diode 2,6 bis 5,5V max. 2,6A im SOT-23 Gehäuse
* LTZ1000ACH#PBF Linear Technology Präzisions-Referenz (Ersatz für LM399H) ||||
* Maxim Switched Capacitor Tiefpass-Filter (z. B. MAX297, MAX7410) ||||| |
* mehr Familien von Logik-ICs, z. B. AC, ACT, LVC (in SMD) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||
* mehr SMD Bauteile {{Reichelt50|FF0000}} {{Reichelt50|00FF00}} |||||
* MIC6315 von Micrel (3,3/5V Reset Baustein mit manual Reset) ||
* Motortreiber TLE 4205 ||||
* PGA2311 (Stereo Audio Volume Control) |
* SDT06S60 Infineon SiC 600V 6A Silizium-Carbid Schottky-Diode (kein trr, daher keine Schaltverluste) ||||
* SMD Doppeldiode Schottky 12A 60V im TO252AA z. B. 12CWQ06FN von IOR ||||| ||||| ||||| ||
* TLV320AIC23B Audio-Codec ||
* TPIC6B595 (oder ähnliche 74xx595 high current (150 mA) shift register) ||||| ||||
* uC supervisor chips + watchdog z. B.: MAX6864 ist z.Z. der beste (0.2uA!) ||||
* VN808 Low Treshold Octal High Side Driver 0,7A ||
* VS1000 Ogg Decoder von VLSI |
* VS1053 MP3/AAC/WMA/Ogg Decoder von VLSI ||||| ||||| ||
* Zarlink MT8841 Calling Number Identification Circuit |
* ZHB6718 (H-Bridge für 1,5V - 20V Motoren) ||||| ||||
* ZRA250F005 Referenzspannungsquelle 2,5V 0.5% SOT23-Gehäuse ||||| ||||| ||
* TXB0108 8-Bit Bidirectional Voltage-Level Translator with Auto Direction Sensing |

== Baugruppen ==

* Atmel ATNGW100 von [http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=AVR32NGKit_3_26.html Atmel] = billiges Linux Board ($69=51.69€) --> [http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/NGW100_Hardware_reference Dokumentation] ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||
* Atmel ATSTK1000 von [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918 Atmel] ||||| ||||| ||||| ||||
* Axis Etrax 100LX MCM (Multi Chip Module) A full Linux computer on a single chip! ||||| |||||
* Bluetooth Funkmodul {{Reichelt50|FF0000}}{{Reichelt50|00FF00}}|||||
* Bluetooth Mini-Module (RS232-Bluetooth-"Wandler"-Platinchen) z. B. BTM222 ||||| ||
* CentiPad/DevKit Embedded Linux Modul ([http://www.centipad.de www.centipad.com]) ||||| ||
* DS9490R USB zu 1-Wire Dongle (auch mit Linux Treiber) ||||| |||||
* Easy-Radio Module zur seriellen Datenübertragung (ER400 RS/TS/RTS) ||||| ||||| ||||| ||||
* Foxboard = Betriebsfertiges Micro Linux System mit Axis Etrax 100LX MCM 66mm x 72mm ||||| ||||| ||||| ||||| ||||
* FoxVHDL = FPGA Erweiterungskarte für das ACME Foxboard ||||
* FPGA, low-cost Experimentierplatinen ||||| ||||| ||||| ||||| ||||
* Hope RF Module 433 u. 868 MHz, http://www.hoperf.com/pdf/RF12.pdf ||||| ||||| |
* Hope RF Module 2,4GHz, RFM70 |||||
* kostengünstige Funkempfänger/Funksender 433 & 868 Mhz ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||
* kostengünstige Funkschaltmodule (TLP/RLP) ||||| ||||| ||||| ||||| |||
* Lantronix XPort Direct |||
* Lantronix XPort Embedded Device Server ([http://www.lantronix.com www.lantronix.com]) ||||| ||||| ||
* Microchip PICkit 2 ||||| |||
* Microchip PICkit 2 (PG164120) ohne Demoplatine |
* Mini-WLan Module (RS232 zu WLan) ||||| ||||| ||||| ||||| ||||
* MT1390 FM Tuner-Modul von Microtune |||
* NetDCU8 von F & S Elektronik Systeme GmbH (http://www.fs-net.de) - Linux-Computerplatine mit 400MHz Samsung-ARM mit 32MB RAM, 16MB Flash und SD/Ethernet/CAN/USB/TFT/RS232 für ca. 100 Euro ||||| ||||| ||
* OM5610 FM Tuner-Matchbox von Philips |||
* ST Primer 2 (Experimentierboard fuer ARM Einsteiger) ||
* STM STM3210C-EVAL für <=214,79€ netto (wie bei Future Elektronik, Stand 18.3.2011) |
* TI - MSP430 Wireless Development Tool (AEC13895U) |
* TI eZ430-Chronos |
* UM232 FTDI USB - RS232 Modul für DIL sockel |||||
* Raspberry Pi |||

== Passive Bauteile ==

=== Spulen und Trafos ===

* Die Micrometals Pulverkerne (-18 und -26) auch in größer ||||| ||
* Fastron 0805 AS Serie vervollständigen ||
* Funk-Entstördrosseln 16A, div. Werte ||||| ||||| ||||| |||
* Funk-Entstördrosseln 330µH / 3A |
* Funk-Entstördrosseln 47µH |||
* Magnetics CoolMu Ringkerne ||||| ||||| ||
* Magnetics MPP Ringkerne ||||| ||||| ||
* Ordentliche Trafospulen + Kerne, z.b. ETD-Serie, oder RM10 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||
* Passende Ferrite dazu: N27,N41,N67,N87,N97 ||||| ||||| ||||| ||||| ||||| ||
* Ringkertrafos >500VA mit höherer Spannung als 30V (Verstärkerbau) |||
* SEPIC-Speicherdrosseln von Würth WE-DD (Größe M u. L) ||||
* Übertrager für Schaltregler z. B. Epcos Typ B78304 ||||| |||||
* Würth Induktivitäten ||||| ||||| ||||| ||||| ||||
* Würth Sortimentskästen Induktivitäten ||||| |

=== Kondensatoren ===

* Drehkondensatoren 20-500pf ||||| |||||
* Generell SMD-Kerkos im Wert > 100nF {{Reichelt50|FF0000}} {{Reichelt50|00FF00}} |
* Günstige hochkapazitive Doppelschichtkondensatoren (z. B. Maxfarad MES2245 220F 2,3V) ||||| |||
* Keramikkond. SMD 0603/0805/1206: mehr Zwischenwerte (56p, 82p, 560p) ||||| ||||
* Kleine Niedervolt-Polyproplyenkondis mit mehr Kapazität ||||
* Low-ESR Elkos (definiertes Fabrikat/Typ, und nicht einfach irgendwelche! (Rubycon?)) {{Reichelt50|FF0000}}||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||
* Low-ESR Elkos RM 3,5mm 1.000µF 6,3V (Mainboardaustausch Elko) ||||
* Low-ESR SMD Tantal-Elkos (definiertes Fabrikat/Typ, und nicht einfach irgendwelche! (AVX?, Epcos?)) ||||| ||||| ||||| ||||| ||||| |
* Sanyo OS-Con bedrahtet und SMD |||
* Wima FKP02 |
* Wima FKP2 |
* Wima MKP3-X2 (~275V, klein und ideal für Kondensatornetzteile) ||
* Wima MKP4 |||||
* Zum MAX232 so20 passende SMD-Kerkos im Wert 1µF (0805,0603, 1206) ||||| ||||| ||||| ||||| |||

=== Widerstände und Potis ===

* 25/50/100W Hochlast-Widerstände (~20/50Ω auch weniger) ||||| ||||| ||||| ||||
* Digitalpoti AD5160 mit SPI in SOT23 ||
* Digital-Potentiometer (z. B. 2-Wire MAX546x, AD526x, X9C10x) ||||| ||||| ||||| ||||| ||||| ||||| |
* Durchsteck-Widerstände in kleiner Bauform 0204. ||||| ||||| |||
* Endlospotis als Motorgeber ||
* Erneut die 10k-Ohm SMD-Potis |||||
* Größere Auswahl an (Stereo-)Schiebepotis in log und lin, insbesondere jenseits 100K ||
* Hochlast NTC, z. B. 80-220Ω/1-4A (EPCOS, Ametherm) ||
* Hochspannuns-Widerstände (z. B. 330M/10kV) ||
* iPod-Wheel z.B. QT511-ISSG ||||| ||||| |||||
* Kleine Ein-Gang-Trimmer unterhalb 250Ω |
* Leitplastikpotis im Servogehäuse |
* Linear- und 360° Soft-Pots (iPod-Wheel) wie von spectrasymbol ||||| |||
* Niederohm-Widerstände (Shunts ab 1mOhm im guten Gehäuse z. B. TO220) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||
* Null-Ohm Widerstände (Drahtbrücken) Baugröße wie 1/4W ||||| ||||| |||
* Präzisions-Spannungsteilernetzwerke ||||| ||||| |
* Präzisionsspannungsteiler 1:10, 1:100, 1:1000 (10MOhm Gesamtwiderstand) |||
* Präzisionswiderstände 0,05% und besser, ev. drahtgewickelt ||||| ||||| ||||| ||
* R2R-Widerstandsnetzwerke (z. B. 10/20kOhm für DA-Wandler an Microcontrollern) ||||| ||||| ||||| ||||| ||||| ||||| ||||| |
* SMD-Präzisionswiderstände (0,1% TC10ppm/K =>0,1W indukt.arm) ||||| ||||| ||||| ||||
* SMD-Widerstände 0805 auch aus der E24-Reihe ||||| ||||| ||||| ||||
* SMD-Widerstände 0805 und 1206 auch unterhalb von 1Ω ||||| ||||| ||||| ||||| ||||| ||||| |||||
* SMD-Widerstände unterhalb 1Ω, andere Gehäuse als 0805/1206 (leichter erfüllbarer Wunsch) ||||| ||||| ||||| ||
* statt Radiohm-Potis bitte Prehostat oder Alphastat 16 63256-026xx ||||| ||||| ||||||
* Widerstände > 10MOhm (möglichst bis 100GOhm) ||||
* Widerstandsnetzwerke 11-Pin (für 10er Bargraphanzeige) |||

=== Quarze, Quarzoszillatoren und Resonatoren ===

* 13,5600 MHz Quarz (benötigt für RFID) (SMD+bedrahtet) ||||| ||||| ||||| ||||
* 24,0000 MHz Standardquarz Grundton ('''kein 3. Oberton!!!'''), benötigt für USB-DMX-Interface (SMD-Grundtonquarz unter 24,0000-MA505 verfügbar) ||||| ||||| |
* 25,0000 MHz '''Grundton'''-Quarz, wird benötigt für Microchip TCP/IP Controller ENC28J60) (als Keramik-SMD-Quarz 25,000000-MJ verfügbar) {{Reichelt50|FF0000}}{{Reichelt50|00FF00}}||||| ||||| ||||| ||||| ||||| ||||| ||||| ||
* Allgemein mehr Grundtonquarze bei höheren Frequenzen ||||| |
* Murata Keramik-Resonator CSTLS16M0X, CSTLS20M0X (obwohl 3. OW, direkt mit µC verwendbar) |
* Quarze 6,500000 MHz (HF-Anwendung) ||
* Quarze 32 MHz 10ppm Oscillatorfrequenz 0 bis +70°C |
* Quarz mit 3,200 MHz ||
* Quarzoszillator 9,8304 MHz |||
* SMD Quarze/ Oszillatoren in flachen, kleinen SMD Gehäusen (SMX-A/-B) |||||
* SMD-Quarze mit Standardgehäuse (z. B. HC49/US & HC49/UP) ||||| ||||
* 32,768 kHz Quarz mit 12,5 pF ||

=== Sonstiges ===

* Lötfähige (SMD-) Kühlkörper (Fischer) ||||| ||||| ||||| ||
* Metallbrückengleichrichter für 50A ||||
* Netzfilter FFP Reihe Schurter ||
* Suppressordioden mit Spannungsbereich zwischen 15V und 30V |||
* Übertrager FB2022 oder 20F-001N (passend zu RTL8019AS)||
* Übertrager passend zu ENC28J60 |
* Varistoren 14V auch als bedrahtetes Bauteil (für KFZ-Bordnetz)-> 1,5KE 18CA ||||| ||||| ||

== HF-Baumaterialien ==

* Durchführungskondensatoren 1nF/160V (waren Ende '06 noch im Programm) ||||
* Filter SFE10.7MA19 360khz SZP2026 |
* H155 (HF-Kabel) |||||
* HF-Litze(n) |
* Keramik / Teflon Leiterplatinen |
* Keramische Filter CFM455... ganzes Sortiment |||||
* MC68160FB
* MC68EN302PV20
* MICRF002/022, MICRF102/103 von Micrel ||||| |
* MMICs und Ringmischer von Mini-Circuits
* MT48LC4M32B2TG-7
* PLL ICs z. B. von NXP und National für HF-UHF ||
* S3C4510B
* Transistoren MRFG35010 |
* U.FL bzw. IPEX Steckbuchsen zum Selbstkonfektionieren von HF-Kabeln ||
* ZF-Quarzfilter für versch. Frequenzen (10, 20, 40 MHz) ||
* Zirkulatoren ALD4302SB statt LM239
* µP Compatible CTCSS Encoder,Decoder FX 365

== Optoelektronik und Leuchtmittel ==

=== Einzel-LEDs ===

* Acriche 230V~ LEDs
* Edison Opto LEDs: pinkompatibel mit diversen abgekündigten LEDs von Luxeon und Co, aber deutlich günstiger im Preis und leuchtstärker da u.A. Cree LED DIEs verwendet werden
** Edison Opto ARC / Edixeon LEDs (da ja Luxeons abgekündigt sind) ||||
** Edison Opto Federal (Luxeon Rebel artig) ||||
** Edison Opto KLC8 (Luxeon Bauform mit Cree Die) ||||
** Edison S Serie -> Lumiled kompatibles Gehäuse aber viel leuchtstärker |||
** Edison Exixeon Serie -> Lumiled kompatibles Gehäuse aber viel leuchtstärker ||
** Edison Edixeon RGB |||
* Everlight SMD-RGB (fullcolor) 19-337/R6GHBHC-A01/2T |||||
* Generell: Z-Power LEDs von Seoul (günstiger und heller als Luxeon) ||||| ||
* IR-Diode mit viel Power ttp://www.lc-led.com/Catalog/department/36/category/49/1 ||
* Kühlerplatinen für Power-LEDs im Star-Format oder vergleichbar |
* Low Current SMD-LEDs (z. B. Osram LG T679 - Anm.: hier gleich die neuen Varianten Lx T67K bestellen, nicht die alten 9er) ||||| ||||| ||||| |||||
* Luxeon Rebel weiß (180 lm) auf Star-, Mini- oder normaler Platine ||
* OSRAM Hyper TOPLEDS gelb LY T676-S1T1-26 ||
* OSRAM Hyper TOPLEDS weiss LW T67C-T2U2-5K8L ||
* Reflektoren für 10mm LEDs ||
* Samsung SLS RGB W815 TS (PLCC6 RGB-LED)|
* Seoul Z-LED RGB auf Platine ||
* Seoul Zled P4 (100lm bei 350mA, 240lm bei 1A!) ||||| |||||
* SMD-IR-LEDs in 0603/0805/SOT23 + dazu passende IR-Fotodioden in gleicher Größe |
* SMD-LED Bauform 0402 rot/gelb/grün/blau/weiss ||||| ||||| ||||| ||||| ||
* Superflux RGB-LED ||||
* warmweiße LED ||||| ||||| ||||| ||||
* weiße SMD-LED Bauform 0603 ||||| ||||| |||||

=== Anzeigen und Displays ===

* 4-Stellige Dot-Matrix LED-Anzeigen Siemens SLG 2016 oder von HP oder ähnliches ||||| |
* 7-Segment-Anzeige 4 DIGIT mit und ohne Doppelpunkt ||||| |
* 7-Segment-Anzeige, allgemein Low-Current bzw. High Efficiency Versionen anbieten ||||| ||||| ||
* 7-Segment-Anzeige, weiss, gem. Anode ||||| ||||| ||||| ||||| ||||| ||||| ||||| |
* 7-Segment-Anzeige, weiss, gem. Kathode ||||| ||||| ||||| ||||| ||||| ||||| |
* Generell alle 7-Segment-Anzeigen auch in Blau und bis zu 100mm Höhe ||
* Kingbright PSC Serie (16 Segment LED-Display, insbesondere PSC08 und PSC12) |
* LED Punktmatrix Anzeigen 8x8 superrot 3mm (z. B. Everlight ELM-1883SRWA) ||
* LED Punktmatrix bicolor 1.9mm (z.b. Betlux BL-M 07A881SG-XX )
* TFT/OLED Farb-Displays, wie die bereits abgekündigten OSRAM OLEDs ||||
* Vakuum-Fluoreszenz-Displays (Dot Matrix mit Standardcontroller, z. B. Futaba "LCD Emulators") ||||| ||||| |||

=== andere Leuchtmittel ===

* OSRAM Halogen Decostar 51 12V 20W GU5,3 statt des billigen NoName Zeugs ||

=== sonstige Optoelektronik ===

* BPW 34 F / FS (aus dem Sortiment gefallen, PIN-Fotodiode) |
* IL207AT (SMD Optokoppler von Infineon) ||||| |||
* ILD256T (SMD AC-Optokoppler) ||||| |||||
* ILD620 (DIP Optokoppler) ||||| ||||| ||||| |||||
* IrDA-Tranceiver TFDS4500 (oder TFDU4100) wieder anbieten - war im 07/2005er Katalog noch drin) ||||| ||||
* PC923 (Opto MOSFET Gate Treiber auch für High Side) |
* SFH6106, SFH6206 4 Pin Optokoppler SMD ||||| |
* TLP 3617 Photo-Triac
* TLP113 (SMD Optokoppler) |||||
* TLP250 (Opto MOSFET Gate Treiber auch für High Side)||||
* TORX 178 Fiberoptik-Receiver
* TOTX177PL und TORX177PL (Fiberoptik-Transmitter) als Ersatz für TOTX173 und TORX173 (zwar anderes Footprint, aber dafür auch kleiner und günstiger)
* TSOP 1140 Infrarot-Receiver (oder andere 40 kHz IR-Empfänger) ||
* TSOP 1730 Infrarot-Receiver [Achtung! TSOP17xx sind Auslaufmodelle bei Vishay] ||
* TSOP98200 (Breitband IR-Empfangsmodul 20-455 KHz) ||||
* TSOP98260 (Breitband IR-Empfangsmodul 20-60 kHz) |||||
* Vactrol Optokoppler (mit Fotowiderstand zur Analogsignalregelung) |||||

== Mechanisches ==

=== Schalter/Taster/Eingabegeräte, Relais ===

* bistabile Relais mit 2 Wicklungen ||||| ||||| |||||
* Drehimpulsgeber DDM Hopt+Schuler 427 SMD (evt auch normal, stehend & liegend) ||||| ||||| ||||| ||||| ||||| |||||
* Drehschalter Serie DS in allen Versionen nur vom Hersteller C&K; auch brückende Versionen anbieten ||||| |||||
* Drucktastenfeld Matrix 3x4 ||||| ||||| ||||| ||||| ||||
* Folientastaturen {{Reichelt50|FF0000}}||||| ||||| |||||
* Grayhill Series 60A Joysticks mit USB-Adapter |
* Hohlwellen-Drehgeber (z. B. EC35B-Serie von Alps) ||
* kleiner Joystick wie beim Atmel Butterfly ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||
* mehrpolige Fußschalter, FS 35 bitte bei Druckschalter einordnen ||||
* Miniaturkippschalter mit Verriegelung ||||
* möglichst kleine und flache Druckschalter rastend! |||||
* passende Touchpanels für die coolen Blue-Line-Grafikdisplays ||||| ||||| ||
* Relais mit hohen Wirkungsgrad (daher nur geringer Spulenstrom nötig) ||
* SMD-Schiebeschalter |||||
* Taster Radiohm ST-1034 in rot, grün, gelb, blau, grau und schwarz |
* Taster und Kappen aus der Multimec-Reihe |||
* Taster, Schalter und LED-Fassungen aus der Mentor FEL-Reihe ||||
* Tastköpfe für Taster9308, wie zb Omron B32-2000 oder B32-2010 ||
* PhotoMOS Relay (z. B. AQV257 von Panasonic |

=== (Steck-) Verbindungen PC- und Audiotechnik ===

* 2.5mm-Stereo-Klinkenbuchsen (3-polig) SMD ||||
* Adapter 3,5mm-Klinkenbuchse auf 3,5mm-Klinkenbuchse ||
* Cablesharing Adapter 2x RJ45-Buchsen(1x Ethernet 1x ISDN)1xStecker |http://www.btr-netcom.com/Products/upload/ATCH-002661.pdf
* Floppy-Stromversorgungstecker 3,5" Printausführung ||||| ||
* Günstigere SD/MMC-Steckverbinder z. B.SDBMF-00915B0T2 von MULTICOMP(selbst bei Farnell für 1,80 Euro) ||||| ||
* Hochwertigere 1/4"-Klinkenbuchsen, z. B. von Rean oder Cliff |||||
* Höherwertige 3,5mm-Klinkenbuchsen / -stecker (statt "EBS35" oder "KK(S/M) ..") ||||| ||||| |||
* Höherwertige Adapter für Klinke (die bisherigen 3,5 auf 6,3mm-Adapter sind nach ~2 mal Stecken völlig ausgeleiert) |
* Micro-USB-Steckverbinder ||||| ||||
* Micro-USB 2.0-Buchsen (Printmontage und SMD-Montage) ||
* microSD / Transflash Sockel mit Push-Push-Technik (ist nervig die immer für teuren versand aus amiland kommen zu lassen) ||||| ||||| ||||| ||||| ||||| ||||| |
* MiniSD Card-Connector mit Auswurffunktion für Oberflächenmontage ||||| |
* Modulare Buchse RJ45 mit Übertrager und LEDs für Ethernet 10/100, z. B. SI-40138 MagJack von BEL-STEWART oder Taimag RJLBC-060TC1 {{Reichelt50|FF0000}}||||
* Modulare Buchse RJ45 ohne Übertrager mit LEDs (oder Lichtleiter für SMD-LEDs) ||||| |||
* Molex Steckerreihe Minifit Jr 4,2mm Rastermaß (verwendet als Stromstecker in Computern, Mainboard, PCI-E, P4/EPS ...) |
* Ordentliche Lautsprecherbuchsen "Strich-Punkt" (Print oder Wand) (die Stecker sind OK) |
* RJ45-Stecker 90° nach unten oder zur Seite gewinkelt ||
* SATA-Stromstecker/ -Buchsen für Kabel/ Printmontage ||||
* USB3-, e-SATA-, eSATAp (Power e-SATA)-Stecker in Printausführung (gerade und gewinkelt) [die gibts aber inzwischen, z.b. USB3 AEB] ||||
* vernünftige Koax-Stecker und -Kupplungen z. Bsp. von Hirschmann
* WOL-Verbindungskabel / -Stecker / -Print-Connectoren: ||||| |

=== (Steck-) Verbindungen Platinen und ICs ===
* Buchsenleiste Fischer BL5 |
* Buchsenleisten zum Crimpen (allseitig anreihbar!, 1x1, 1x2, z. B. [http://www.newproduct.molex.com/datasheet.aspx?ProductID=92125 Molex 2081 ?] oder Harwin M20 ) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||
* Carrier-IC-Sockel
* Die PSK-Kontakte in anderen Packungen als 20/10k.100Stk. wäre z.B. gut.1k auch. ||||| |
* Einpolige Steckerleiste 2.54 ||||| |||
* gängige Platinenverbinder einreihig RM 2mm mit 2-15 Kontakten (in vielen Geräten verwendet, z. B. [http://www.newproduct.molex.com/datasheet.aspx?ProductID=19945 Molex 51004, 53015]): ||||| Molex 71226 |||
* mehrpolige, hochwertige Miniatursteckverbinder (z. B. http://www.binder-connector.de/pdfs/serien/711.pdf) |||
* Molex C-Grid SL einreihig 2 bis >6 polig: Stecker, Buchsen, Buchsen-SMD, Crimp-Werkzeug |
* Nullkraftsockel (TEXTOOL, ARIES, Yamaichi,..) für 6-Pin SOT23 (SOT23-6) |||||
* Nullkraftsockel (TEXTOOL, ARIES, Yamaichi,..) für DIL20 ||||| |||||
* Nullkraftsockel (TEXTOOL, ARIES, Yamaichi,..) für DIL28 ||
* Nullkraftsockel (TEXTOOL, ARIES, Yamaichi,..) für PLCC-44 ||||| ||||| |||||
* Nullkraftsockel (TEXTOOL, ARIES, Yamaichi,..) für andere SO- oder TQFP-Gehäuse ||||| ||||| ||||| |||
* Platinensteckverbinder für Rastermass 2,00mm ||||
* Stapelleiste AMP 2–0827730–0, 20polig, A 24,2 mm |
* Stiftleisten im Rastermaß 1 mm (z. B.: Samtec FTMH-120-03-F-DV-ES) |
* Wannenstecker 2,54mm Raster auch als SMD ||||| ||||| ||
* Wannenstecker 6-Pol. gewinkelt, gibt nur gerade (WSL 6W, aber derzeit nicht lieferbar) ||||
* Wannenstecker (gerade) + Pfostensteckverbinder 6-Pol. (Pfostenbuchsen gibt es 6-Pol.) ( z. B. Harting SEK 18 Serie http://www.harting.com/en/en/de/sol/verbtech/prod/ios/description/03005/index.de.html) ||||| ||||| ||||| ||||| ||||| ||||| ||||

=== (Steck-) Verbindungen sonstige ===
* Adapterprogramm SMA auf SMB ausbauen ||
* BNC-Stecker (wie UG 88U, Lötmontage) aber für RG174-Kabel ||||| |
* Chipkartenkontaktiereinrichtung, die die Kontakte anhebt (keine Schleifkontakte) ||||| ||||| |
* E10-Schraubsockel, wie sie Glühbirnen haben, mit Lötstiften (Achtung es ist nicht die Fassung gemeint) |||||
* Euro-Einbausteckdose (230V~, gab's früher mal) ||||| |||
* Foliensteckverbinder (FFC) RM1,25 (z. B. 9pol, 11pol ...) |||||
* Für LC-Displays: Adapterplatine mit Anschlüssen im Raster 2,54mm (EA 9907-DIP) siehe http://www.lcd-module.de/ ||||| ||||| ||||| ||||| ||||| ||||| |||
* Hohlstecker für Laptops 1,7 x 4,75mm gelb |||
* Hohlstecker für Acer-Laptops 1,7 x 5,5mm |
* Hohlstecker-Buchsen, ganz kleine, passend zu Handy-Netzteilen z.B.von Nokia |
* JST HR-Steckverbinder |||
* Lüsterklemmen kleiner LÜK 2,5, also z.B. LÜK 1,5: ||||
* Mini-Schraubklemmen Phoenix Contact MPT-Reihe RM2,54, z.B. MPT0,5/12-2,54 f. 12polig |||
* OBD-Stecker. |||||
* Polklemmen Hirschmann PKNI 10B (max. 63A), zumindest Schwarz und Weiß ||
* preiswerte! Hochspannungssteckverbinder >2kV ||||
* RP-SMA-Buchse/-Stecker (gewinkelt/gerade) ||||
* Schuko-Einbausteckdose (Maschinensteckdose) (mit oder ohne Klappdeckel); Flanschmaß möglichst klein (50mmx50mm); div. Farben (sw,grau,...) ||||| ||||| |||
* Steckverbinder für PICTIVA OLED-Display-Folienkabel |||||
* Triaxstecker /-buchse (Coax mit 2. Schirm als 3. Kontakt) ||
* Deutsche Stecker für PKW, LKW, LoF ||

=== Kabel, Drähte etc. ===

* angebotene Schaltlitze (H05VK, H07VK) um weitere Farben erweitern ||||| |
* das qualitativ mangelhafte 4mm Laborsteckerprogramm rausnehmen und nur noch Hirschmann anbieten ||||| ||||| ||||| ||||| ||
* dickere Mantel(Feuchtraum)leitungen, z. B. NYM J5x10 |
* Distanzbolzen mit 2 M2,5-Innengewinden versch. Längen ||
* Dünner Schaltdraht (< 1mm Durchmesser, isoliert mit Tefzel oder Kynar) {{Reichelt50|FF0000}}||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||
* Stinknormaler dünner Schaltdraht 0,3, 0,5 und/oder 0,75mm in verschiedenen Farben ||||
* Flachbandkabel im 1,00mm-Raster, passend für Pfostenverbinder PL 2X25G 2,00 . Wird für Notebookplatten benötigt. Ohne das ist die gesamte 2,0mm-Wannensteckerproduktgruppe sinnlos. ||||| |||
* Flachbandkabel im 1,27 mm-Raster, 6-polig |||
* Flachbandkabel im 2,54mm-Raster und dazu passende Aufpressstecker und -buchsen ||||| ||||| ||||| ||||| ||||| ||||
* Flexible Einzellitze, 0,5² in verschiedenen Farben ||||| ||||| ||||| ||||| ||||| |||||
* Folienflachkabel (FFC) RM 0,8 (z. B. 30pol., Länge 125mm) für 8" TFT-Monitor
* Folienflachkabel (FFC) RM1,25 (z. B. 9pol, 11pol ... /Länge 20cm) ||
* Heizdraht zB.: Kanthal A1 ||||| ||
* hochwertige MicroUSB-Kabel (AK 676-AB rupft einem fast die Buchse aus dem Handy) ||
* Kupferlackdraht auf Spulen statt lose (Artikelbild ist irreführend!) |||||
* kurze (10cm, 30cm, 50cm)-Kabel zB.: USB A->B, A->Bmini, A->Bmicro; Klinke/Cinchkabel |||
* Litze, LiY 0,25mm^2, diverse Farben (beispielsweise von Lapp Kabel) |
* Low-Loss-Kabel (evtl. aus diesem Programm http://www.elspec.de/hf-kabel-technologie/download-hf-technik/hf-lowloss-kabel.html)
* LYIF-Litze (verschiedene Farben) ||||| |
* PATCHKABEL xx WS: Cat5 Patchkabel SF/UTP auch in weiß (deutlich dünner, flexibler und auch günstiger als die Cat6 PiMF) |
* RG214 |
* Schnepp "Laborkabel"-Messleitungen ||||| |
* versilberten Kupferdraht auch < 0,6mm und alle Stärken in grösserer VPE (z. B. 500g-Rolle) ||||| ||||| ||||| |
* Zwillingslitze 2x0.14mm, z. B. Artikel: ZL214SWW-10M Kessler Elektronik ||||| |||||

=== Gehäuse und Gehäusetechnik ===

* Batteriehalter für 18650er Lithiumzellen (ähnlich dealextreme sku 100996/100997/100999) ||||
* Batteriehalter für 4 Mignonzellen mit Lötfahne (statt Druckknopf) ||
* Bopla ABP oder ABPH 800-100 (10cm) Aluprofil Gehäuse |||
* Distanzbolzen M2,5 (SW4) in verschiedenen Längen aus Messing ||
* Distanzhülsen/-bolzen M3 in verschiedenen Längen aus Kunststoff |
* mehr und v.a. kleine (Hand-) Gehäuse {{Reichelt50|FF0000}}||||| ||||| |||
* Muttern M2 |||
* Preiswertere Alu Druckgussgehäuse, wie z. B. von Hammond Manufacturing ||||| ||||| ||||| |||
* Stopmuttern M2 |
* Strangpreßprofilgehäuse von Fischer |
* USB-Leergehäuse (z. B. wie USB-Stick, WLAN-Dongle, o.ä.) ||||| ||||| ||||| ||||| |
* Zylinderkopfschrauben M2,5 x 12mm |||||
* Zylinderkopfschrauben M2,5 x 20mm |||||
* Zylinderkopfschrauben M2,5 x 30mm |||||
* Zylinderkopfschrauben M3 x 25mm ||||| |

== Prototypenbau, Platinen und Chemie ==

* Adapter QSOP (versch. Pinzahlen) auf DIL/QIL ||||| ||||| |||
* Adapter TQFP (versch. Pinzahlen) auf DIL/QIL ||||| ||||| ||||| ||||| ||||| | ||||| ||||| ||||| |
* Arbeitsschalen zum Entwickeln und Ätzen von Platinen(*)(ist im Starterkit enthalten) ||||| ||||| ||||| ||||| ||
* Ballistol Universalöl ||||| ||||
* Bungard Green Coat ||
* Bungard Sur-Tin ||
* Bungard-Fotoplatinen auch in 80x100mm (halbes Euroformat), nicht nur 75x100mm ||||| ||||| ||||| |||||
* Bungard-Fotoplatinen BLAU div. Formate ||||| ||||| ||||| ||||||
* Bungard-Fotoplatinen SCHWARZ div. Formate |
* Cadsoft Eagle ||||| ||||| ||
* chemisches Zinnbad ||||| ||||| ||||| |||||
* Entwickler NaOH-Frei von Bungard (SENO 4007 Universalentwickler) ||
* Fotoplatinen aus Hartpapier von Markenhersteller ||
* Fotoplatinen, zweiseitig, Hartpapier(!) |||||
* Hohlkehlenlötspitzen (Ersa 0832HD) ||||| |
* Hohlkehlenlötspitzen f. Weller MLR21 ||||| |||||
* Kapton-Baender, evtl auch mit Kupferbeschichtung (Flex-PCB) |||||
* Lötstopplaminat ||||| ||||| ||||| ||||| ||||| ||||| |||
* LPKF Durchkontaktierungspaste |||
* Messingblech/Kupferblech 0.1mm (wenn möglich Photobeschichtet) |||||
* Natriumpersulfat 2 kg Packung ||||| ||
* PCI-Express x1 Laborkarte (wie RE 430EP) ||
* PIC_BASIC_II || Programm mit HardwareKey [z. B. für Azubi's]
* SMD Testplatine (3x3 Felder) wie bei Conrad |||
* SOIC auf PDIP Gehäuse-Adapter zwecks Prototypen-Bau ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||||
* Spitzenhülsen WSP-/MPR 80 (Weller) ||
* Steckplatinen (Breadboards) ohne Grundplatte und ohne Versorgungsleiste (wie Conrad 526827; STECKBOARD 1K2V hat beidseitig Leisten und ist daher nicht anreihbar / ist anreihbar, aber danach sind die beiden Leisten jeweils übrig) |
* Steckplatinenen (STECKBOARDS) im 84 x 54 Format (gibts bei Conrad ist da aber viel zu teuer) |||
* Target 3001 V15 Autorouter verschiedene Lizenzen |
* Tonerverdichter (www.Huber-Troisdorf.com) ||||| ||||| ||||| ||||| ||||| |||
* www.schmartboard.com hat super einfach zu lötende SMD-Adapter in allen Größen, nur leider keinen Vertriebspartner in Deutschland (doch: ELV (wo?)). Wie wäre es mit Reichelt? ||||| ||||| ||||| ||||| ||||| ||||| |||||
* Blanko Katalogseiten "weiß" für die Toner direkt Methode (oder 2-3 Seiten im Katalog leer lassen) ||

== Werkzeug und Zubehör ==

* einzelne Hartmetallbohrer in diversen Grössen (z. B. 0,8 1,0 1,3 1,5) {{Reichelt50|FF0000}}||||| ||||| |
* ESD-Erdungspunkte 4mm/10mm für Schuko, wie Vermason J6100 (alt) / 231125 (neu) ||
* Gewindebohrer M2 und M2,5 ||||| ||||| ||
* hochwertige 9mm Abbrechklingen ||
* Konturenfräser/Gravurstichel, etc. zum Fräsen von Platinenprototypen (z. B. Bungard G60N/G30N) ||||| ||||| ||
* M2 Gewindebohrer und Senker |||
* robuste Allzweck- und Teppichmesser ||||| ||||
* Sortimentskasten H1 und evtl. H2-Serie ||
* Tri-Wing Schraubendreher ||||
* Torx tamper resistant/tamper proof (die mit Loch) als Set und in Aufbewahrungsbox |
* zöllische Gewindeschneider g1/4" und g 1/8" insbesondere interessant für Wasserkühlungen ||||| ||||

== Messgeräte, Diagnose und Stromversorgung ==

* FS300 Messgerät Antennenanalyzer Massenpreis 50000 Stück ||
* Günstigere Oszilloskope z. B. Multimetrix oder Grundig ||||| ||||| |
* LiPoly-Zellen (aufladbare Lithiumakkus, "Suppentüten" oder prismatische Zellen) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||
* Neuere, bessere NiMH-Akkus (z.b. GP1100 2/3A, GP2000 AF, GP2200 4/5SubC) ||||| ||||| ||
* OBD2 Kabel auf RJ45 Stecker |||||
* Smart Tweezer (SMD-Pinzette mit Komponentenmessung) siehe [http://www.trgcomponents.de/TrgDE/Internet/ProductShow.aspx?ItemID=680&CategoryID=2426] ||||
* Tektronix TDS Series Osziloskope |||
* Vorschaltgeräte mit G23 Fassung (zum Bau von UV-Belichtern geeigent)|||

== Auswahl, Bestellung und Versand ==

* bei über 10kg Gewicht nicht gleich die Versandkosten verdoppeln, sondern geringerer oder keinen Aufschlag ||||
* der Reichelt Katalog auf CD/DVD (durch pdf-download überflüssig:) |||||
* Filialen in Österreich und der Schweiz :-) {{Reichelt50|FF0000}}||||| (man beachte das ":-)", es gibt auch in D keine "Filialen" - mt)|
* Günstige Versandkonditionen für die EU ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |
* In Bereichen wie Multimedia etc. (z. B. Spielekonsolen) ein aktuelleres Angebot, und nicht wie z. B. bei der PS2 erst wenn schon fast das Nachfolgemodell draussen ist (Multimedia ist hier nur ein Beispiel, einfach mal an der Konkurrenz orientieren (Zum beispiel am grossen C) |
* Kein Mindestbestellwert (ich bezahle eh' Porto) ||||| ||||| ||||| |||| ||||
* Kundenkarte so wie bei ELV (Grundgebühr für ein Jahr, keine Versandkosten, evtl kleiner Rabatt) {{Reichelt50|FF0000}}{{Reichelt50|00FF00}}||||| ||||| ||||
* mehr Verpackungsmaterial z. B. kleine Schachteln oder die Plastik IC-"Schienen" einzeln (und unzerschnitten) verkaufen ||||| ||||| |
* Möglichkeit für Selbstabholen eine Bestellung unter 10 Euro abzuliefern. |
* Nicht so viele Tackerklammern/Gummibänder/Tesafilm/Beutel in die Verpackungstüten machen, das nervt beim Auspacken (die kaputten Tüten kann dann auch keiner mehr brauchen, die wenigen nicht kaputt getackerten hebe ich aber gerne auf! Aber bitte weiterhin alles getrennt verpacken... oder wenigstens nicht den Zip-Verschluss tackern) {{Reichelt50|FF0000}}||||| ||
* nicht wie die Konkurrenz jetzt schon im April den Juli-Katalog rausbringen ||||| ||||| ||||| |||
* Parametrische Suche aller Elektronikartikel, speziell erstmal Halbleiter, so wie bei Maxim-ic.com ||||
* Reichelt Katalog als PDF zum Download (siehe [[Reichelt PDF Katalog]] ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||
* Reichelt-Gutscheine sollten bei Online-Bestellung einlösbar sein (wie bei z. B. Amazon) ||||| ||||| |||||
* Selbstabholer-Option bei der Bestellung. Vergisst man es unter "Bemerkung" kommt es per Post :( |||| (für Plz 26xxx kommt eine Option für Abholer, Tip: falsche Plz eintragen)
* Skalierbarer Warenkorb für mehrfachen Aufbau gleicher Platinen |||
* Sortieren und Spezifizieren der Angebotsliste in Transistoren / FET (bessere Übersicht) ||||| ||||| ||||| ||||| || z. B. 400V/6A würde schonmal ganz grob helfen und senkt außerdem unnötigen Traffic, weil nicht extra jedes Datenblatt angeschaut wird
* Versand von Kleinteilen als Maxibrief, zwecks niedrigerem Versand {{Reichelt50|FF0000}}||||| ||||| ||||| ||||
* Warenkorb immer in gleicher Reihenfolge sortiert, nicht bei jedem Aufruf anders ||||| ||||| ||||
*Vergleichen von Ergebnissen einer Suchanfrage möglich machen |

== Unsortiert/Unspezifisch ==

* mehr, aber als solche gekennzeichnete billig-Alternativprodukte, nicht nur High-End ||||| |
* Modellbau und Zubehör ||||| ||||| ||||| ||| (Wird immer mehr, man sieht, Reichelt hört dankenswerterweise auf diese Wishlist!!)
* Toner für Laserdrucker Kyocera FS-1010 TK17 ||||| | ist ja eigentlich der gängigste Kyocera Toner
* Toner für Kyocera FS800-S |
* Speicherkarten-Adapter von SD auf CF (bzw. CFII) |||||
* ein Abendessen mit Angela :-) (hier dürfte wohl Angelika gemeint sein) ||| bzw. mit der Blondine von der Katalogseite mit den Servicenummern |||
* Beamer Casio YC-400 |
* PCMCIA Wlan-Karten (Linux kompatibel) mit externem Antennenanschluss |
* Reichelt T-Shirt ||||| ||||| ||
* Röhrensortiment mit den wichtigsten Typen wie z.B. EL34; KT88 einführen + Sockel |||
* Produktmanager, die des Deutschen mächtig sind. Die Rechtschreibung / Grammatik der Produktbeschreibungen ist eine Katastrophe. ||||

= Bereits im Sortiment =

* Laser-Folien für die Druckformerstellung(Zweckform 3491) ||||| ||||| ||||| ||||| ||||| ||||
* Atmel AT91SAM7S32 53x gewünscht (=> Best.: AT 91SAM7S64-AU)
* Atmel AT91R40008 (32bit controller 256KB-RAM 100-lead TQFP) ||||| ||||| | (=> Best.: AT 91R40008)
* LCD: auch ein- und dreizeilige Variante der DOG-Serie (EA DOGM081 & 163) |||||
* Platinen Basismaterial, einseitig Cu-beschichtet, 0,5..1 mm dick ||||| ||||| ||| -->0,8mm: BEL 160x100-1-8
* Atmel ATtiny45 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| => ATTINY 45-20PU, ATTINY 45-20SU, ATTINY 45V-10PU, ATTINY 45V-10SU
* Atmel ATMEGA48 TQFP ||||| |||| => ATMEGA 48-20 AU
* Atmel ATMEGA 88 || => ATMEGA 88-20 AU, ATMEGA 88-20 PU, ATMEGA 88V-10 AU, ATMEGA 88V-10 PU
* Atmel ATMEGA644 ||||| ||||| ||||| ||||| => ATMEGA 644-20 AU, ATMEGA 644-20 PU, ATMEGA 644V-10AU, ATMEGA 644V-10MU, ATMEGA 644V-10PU
* Atmel ATMEGA2560 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| || => ATMEGA 2560-16AU, ATMEGA 2560V-8AU
* Atmel ATMEGA2561 ||||| | => ATMEGA 2561-16AU, ATMEGA 2561V-8AU
* Philips LPC2000-Serie ARM7-Controller (LPC214x, LPC213X, LPC21xx und LPC22xx) 57x gewünscht => Bauelemente, aktiv / Controller, Speicher / Controller, Prozessoren / Philips-Controller 80C51 / 87LPC.. / 89C51
* TI MSP430F2xxx (Typen mit 16 MIPS) ||||| ||||| | => Bauelemente, aktiv / Controller, Speicher / Controller, Prozessoren / Texas MSP430 Controller
* Breadboards/"Steckbretter" 115x gewünscht => STECKBOARD 1K2V, STECKBOARD 2K1V, STECKBOARD 2K4V, STECKBOARD 3K5V, STECKBOARD 4K7V (zu finden unter 'Diverses/Spielwaren' :)
* RS485 ESD fest: MAX3086E oder 75180 oder ISL83086E ||||| || =>MAX485ECPA
* Microchip PIC 18F2550 || => PIC 18F2550-I/P
* Microchip PIC 16F88 ||||| | => PIC 16F88-I/P
* Microchip dsPIC ||||| ||||| ||||| ||||| | => PIC 30F2010-30 SP/SO
* Logicanalyzer | => ME ANT 8 und ME ANT 16
* Atmel ATMEGA8 TQFP |||| => ATMEGA 8-16 TQ
* 3,3V Laengsregler (LT1086-Serie z. B.) ||||| => vgl z. B. [http://reichelt.de/?ARTIKEL=LT%201086%20CM3%2C3 LT 1086 CM3,3] (SMD) oder [http://reichelt.de/?ARTIKEL=LT%201086%20CT3%2C3 LT 1086 CT3,3] (TO-220) bei Reichelt
* Flexible Messleitungen: Wie gesagt Reichelt bietet ja die ganze Palette an Bananen/Laborsteckern, Krokodilklemmen usw. an, nur die Leitungen dazu fehlen im Programm. (Sind schon im Sortiment. Fertig konfektionierte z. B.: ML 100 SW, Meterware z. B.: MESSLEITUNG 10SW)
* FTDI USB Chips ||||| ||||| ||||| ||||| ||||| ||| => Best-Nr. FT232BL, FT232RL (sehr interessant), FT245BM und FT2232BM (2xUART auf USB)(noch nicht unter USB einsortiert)
* CAN-Bus Controller MCP2515 |||||
* VLSI MP3 Decoder ||||| ||||| ||||| | z.Zt. unter CAN-Bus(!) einsortiert. Bitte auch die neuen Gehäuse (ROHS) und Typen mit ins Angebot nehmen.
* Atmel AT90CAN128 ||||| |
* MMC / SDC slot 50x gewünscht ==> Bestell-Nr.: CONNECTOR MMC 11, CONNECTOR MMC 12, CONNECTOR SD 21 und CONNECTOR SD 22
* lineare Potentiometer als Schiebepoti ||||| | - Bestell-Nr. PSM-LIN* ("mono") PSS-LIN* ("stereo")
* Echtzeituhr DALAS DS1307 (auch SMD) ||||| || - Bestell-Nr. DS1307/DS1307Z
* Konkret: Neuer PIC ... und PIC18F2550 ||||| |||
* MSP430F1232 |
* Fädelstift, Draht und Kämme ||||| ||| - Bestell-Nr. Fädelstift/Fädeldraht/Fädelkamm (Warum sind diese Stifte ùnd der Draht nur so "erschreckend" teuer? => immerhin billiger als bei C...) (vielleicht weil jeder die nur 1x kauft und dann mit Draht aus anderen Quellen selber neu bewickelt?? ;-)
* Mini-GPS-Module ||||| ||||| ||||| ||||| ||| - Bestell-Nr. GPS ET 102/GPS ET 202/GPS EM 401
* Atmel ATmega48, ATmega168, ATtiny13 ||||| ||||| ||||| | (im neuen katalog und online verfügbar!)
* CompactFlash Stecker ||||| ||||| ||||| || - Bestell-Nr. connector CF 01/ Connector CF 02
* DCF77 Empfangsmodule 60x gewünscht (DCF77 Modul) (4.5.2005 ist jetzt verfügbar unter DCF77 MODUL, aber leider 50% teurer als bei der Konkurenz, störempfindlicher, grotesk schwache Ausgangstreiber)
* Microchip PIC 12F683 (8pin PIC mit PWM !) => Bereits im Sortiment: Best. Nr PIC 12F683-I/P bzw. PIC 12F683-I/SN
* MSP430F135 ||||| ||||| ||||| | (MSP430F135 im Programm Bestellnr.: MSP430F135 IPM)
* SMD 0Ω in Bauform 0805 |||| -> SMD-0805 0,00
* Shunt-Widerstände ||||| ||||| ||||| ||||| | (neu im Sortiment: Widerstandsdraht, Best.-Nr. "RD100/x,xx", Leider nur in teuren 100g Spulen)
* dünner isolierter Draht, wie Klingeldraht nur dünner, vielleicht 0.2-0.3mm zum Fädeln von Platinen |||| => Fädeldraht nun im Sortiment
* dünner Silberdraht zur Verdrahtung auf Lochrasterplatinen ||||| | (mögl. bereits im Sortiment "SILBER 0,6MM" ???)Kupferlackdraht geht nicht?
* Hartmetallbohrer in mehr verschiedenen Größen (z. B. 0,6mm 0,8mm 1,1mm 1,2mm etc.) ||||| |||| => Gibt es beides Bestellnummern: "Bohrerset" oder für einzelne Bohrer "Bohrer + Größe in mm" Bsp: "Bohrer 0,6" => die kosten aber einiges, eine etwas preiswertere Alternative wäre auch nicht schlecht...
* 68HC908GP32 |
* überhaupt: Freescale 68HC908- und vor allem 68HCS08-Mikrocontroller fehlen total im Sortiment!
* RJ45-Buchse ||| - schon im Sortiment: MEBP 8-8''x'' unter Modular-Stecker bei TK
* Elektromotoren ||||| |||| (Suche: Gleichstommotor)
* Microchip ICD2 || => Bestell-Nr.: DV 164005 <= Fehlt im Papierkatalog
* 14,7456 MHz Quarze ||||| ||||| ||||| ||||| ||| (Bst: 14,7456-HC18)
* SMD Widerstande in Bauform 1206 (SMD 1/4W...)
* Atmel Atmega 128 in TQFP || (ATMEGA 128-16 TQ)
* Atmel Atmega 169 in TQFP || (ATMEGA 169-16 TQ)
* Atmel ATMEGA1280 ||||| ||||| ||||| |||| (ATMEGA 1280-16AU, ATMEGA 1280V-8AU)
* Atmel ATMEGA8515 | (ATMEGA 8515-*)
* Atmel ATtiny24/44 ||||| ||||| (ATTINY 24-*, ATTINY 44-*)
* Atmel ATtiny25/85 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| | (ATTINY-25-*, ATTINY-85-* gelistet aber erst verfuegbar ab II/07)
* Atmel AT91SAM7S64, AT91SAM7S256 ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||| (suche AT91*)
* Atmel AT91SAM7X64-256 ||||| ||| (suche AT91*)
* TI MSP430F1611 (10k RAM, 48k Flash) ||||| ||||| ||||| ||||| ||||| ||||| || (MSP430F1611 IPM)
* PCA9306 Dual Bi-Directional I2C-Bus and SMBus Voltage Level-Translator ||
* PCA9531D 8Bit I2C_BUS LED-Dimmer ||||| |||||
* PCA9551D 8Bit I2C-BUS LED-Blinker ||||| ||||
* PCA9530D 2Bit I2C_BUS LED-Dimmer ||||| |
* PCA9532D 16Bit I2C_BUS LED-Dimmer ||||| |||||
* PCA9533D 4Bit I2C_BUS LED-Dimmer ||||| ||||
* PCA9550D 2Bit I2C-BUS LED-Blinker ||||| |
* PCA9553D 4Bit I2C-BUS LED-Blinker ||||| ||
* PCA9552D 16Bit I2C-BUS LED-Blinker ||||| |||
* Microchip PIC 18F2550 (USB, 32 KBytes Flash) | (bereits im Sortiment)
* Microchip PIC 16F628A (weil: besser als 16F628) ||||
* Microchip PIC 16F648 (weil mehr Programmspeicher, als 16F628) |||||
* Microchip PIC 16F684 |||||
* Microchip PIC 16F688 ||||| ||
* Microchip PIC 16F690 ||||| ||||| |||
* Atmel ATtiny84 ||||| ||||| |||| (gelistet aber erst verfuegbar ab II/07)
* TI MSP430F169 |
* FT245RL (alt bekannte FTDI Chips in neuer und besserer Version, FT232RL bereits vorhanden) ||||| ||
* 3,3V Längsregler SMD Ultra Low drop |||| (-> Zetex)
* Schiebepotis mit passenden Knöpfen | (Bestell-Nr. PSM-LIN* ("mono") PSS-LIN* ("stereo") nicht passed?) |
* OLED-Displays (zum Beispiel: [http://www.litearray.com/products-oled.php]) || (Reichelt hat jetzt Osram Pictiva Oleds im Programm. Nach "Pictiva" suchen)
* OSRAM "Golden Dragon" LEDs (http://www.osram-os.com/goldendragon) ||||
* Microcontroller mit USB-Anschluss (von Cypress oder Atmel in PDIP z. B. AT89C5131, AT43USB355, CY7C637xx) ||||| ||||| ||||| ||||| ||||| ->Bereits im Sortiment: Cypress EZ-USB TQFP-44 Best. Nr AN2131 SC, Atmel AT89C5131 SO-28/PLCC-52
* Renesas R8C
* zu Schaltreglern LM257x u.a. passende Speicherspulen mit hohem L , niedrigem R und großer Strombelastbarkeit (zB. Würth WE-PD4) (keine "Entstörspulen") 96x gewünscht (suche L-PIS*)
* IL300 (linear Optokoppler z. B. von Vishay egal ob DIP oder SMD) ||||| ||||
* IL300H (linear Optokoppler von Siemens als DIP) - andere IL300 Varianten im Programm |||
* "optische" Drehgeber Fabrikat Grayhill sind lieferbar (Bst. ENC 62P22-*)
* mechanische Drehimpulsgeber von Alps im Programm (suche STEC*)
** Drehimpulsgeber (konkreter Vorschlag von O.R.: PEC16-4220F-S0024 von Bourns) 173x gewünscht
** Drehimpulsgeber- weiterer Vorschlag: ALPS Encoder ST EC 11B 64x gewünscht Im Programm (STEC11B01)
* PCA9633D16 4-bit I2C-bus LED driver ||
* I²C-Bus to 1-Wire DALLAS DS2482-100 bzw. DS2482-800 ||||| ||||| ||||| ||||| ||||| ||||
* Step-Down-Konverter in SMD Bauform (z.b. MC 34063): ||||| (->Artikel-Nr: MC 34063 AD)
* Preiswerte Kontaktierungen für SD/MMC ||| (Bereits im Programm: Bestell-Nummern: CONNECTOR MMC 11 / CONNECTOR MMC 12 / CONNECTOR SD 21 / CONNECTOR SD 22) // ~9 EUR sind wohl kaum preiswert!
* Eisen(III)-Chlorid 115x gewünscht
* EA DOG-M128 128x64 Grafikdisplay aufbau ähnlich EA DOGM162 |||||
* 3,3V-Längsregler SMD zu vernünfitgen Preisen (Bsp: LF33 --> Best.Nr.: LF 33 CV, Preis: 0,76€)(der LT1086 kostet 4 Euro) ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| || -> LT1117 CST-3.3V für 1.55 €
* Spannungsregler in SMD-Version (7805 etc., nicht nur der 78L05) ||||| ||||| ||||| ||||| ||||| ||||| ||| -> LT1117-ADJ für 1.55€
* TSic Temperatursensoren von ZMD ||| -> TSIC
* Leiterplattenbuchse Hirschmann 4mm auch in *rot* (gab es schonmal als "PB 4 RT) || -> wieder als PB 4 RT erhältlich, letzte Woche 3 Stück geliefert bekommen; Stückpreis 1,25€
* MCP25050 CAN-Bus Input/Output Expander ||||| |||| (MCP 25050-I/*)
* Ethernet-Controller RTL8019AS 337x gewünscht (erhältlich: RTL 8019AS)
* SPI-Ethernet-Controller ENC28J60 (erhältlich: ENC 28J60-I/*)
* Microchip PIC 18F4550 (PIC mit USB) ||||| ||||| ||||| ||||| ||||| ||||| |||
* Microchip PIC 18F2585 ||||
* gleicher Mindestbestellwert in Österreich und in der Schweiz wie in Deutschland ''' Seit 1.12.10 umgesetzt''' ||
* gleicher Mindestbestellwert in den Niederlanden wie in Deutschland | (mittlerweile überall 10€)
* Versand nach Österreich über GLS oder sonstigen Paketdienst & auf Rechnung, damit die Spesen halbwegs im Rahmen bleiben (bei der letzten Bestellung ca. EUR 40) ||||| ||||| ||||| ||||| ||||| ||||| ||| '''Anm.: Versand nach AT inzwischen ab 9,90'''
* Pakete nach Österreich in EINER Lieferung schicken, und nicht aus "logistischen Gründen" trennen. Würde zumindest die Hälfte der Verandkosten sparen (letztes mal fast 70€ pro Paket (!) ||
* Digitale Speicherosziloskope für PC ||||| ||||| || (Picoscope, PC-Oszilloskop)
* Hameg HM2008 Oziloscope || ( ist möglich über Service -> Produktservice -> neue Artikel anfragen)
* Microchip dsPIC30F ||||| ||||| |||
* Microchip PIC 16F883 und 16F886 |||
* Microchip PIC 18F4523 (12/2007: PIC mit 12-Bit A/D-Wandler) ||
* Microchip PIC 18F6585 |
* Microchip PIC 18F6720 |
* Microchip PIC 18F8720 |
* Microchip PIC 24FJ64GB002-I/SP (USB-OTG im DIP28 Gehäuse) |
* Atmel XMega-Typen, z.B. ATXMega64A4, ATXMega128A1 ||||| ||
* 7-Segment-Anzeige, blau, gem. Kathode ||||| ||||| ||||| ||||| ||||| ||||| || (SC 52-11 BL)
* 7-Segment-Anzeige, blau, gem. Anode ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| ||||| |||| (SA 52-11 BL, SA 56-11 BL)
* EA DOG-L128 128x64 Grafikdisplay zzgl Touch-Folie und Beleuchtung | --> ist ab Katalog 06/2009 drinn
* LTC 1661 N8 10 Bit Dual Dac mit SPI Interface | (LT C1661 CMS8)
* Microchip PIC 10F2xx (+ Programmiergerät) ||||| ||||| ||||| ||| (einige Varianten erhältlich, Programmiergerät nicht sicher)
* Microchip PIC 24 ||||| ||||| ||||| ||||| ||
* Microchip PIC32 (MIPS) ||||| ||||| ||||| |||
* Microchip dsPIC33 ||||| ||||| ||||
* WAGO 215-4mm-Stecker (Bananenstecker mit Käfigzugklemme) zur schnellen Montage bei Versuchsaufbauten ||||| ||||| ||||| ||||| ||| (dieser Wunsch wurde erhört, Hurraa! Best.-Nr. Wago 215-x11, Vielen Dank an Reichelt.)
* Philips PCA9555 (I2C IO, 16 Bit par. I/O, c't Project Soundcheck II) |||||
* ADuM 1201 o. ADuM1401, bzw. andere ADuMxxxx oder ISOxxxx - Digitale Übertrager mit galvanischer Trennung |||
* LM2675 SimpleSwitcher Step-Down-Konverter in SO-8 Bauform
* Sharp Entfernungssensoren (zb den GP2D120 oder den GP2D12) 51x gewünscht---- siehe Reichelt Artikel : GP2-0430 und GP2-1080
* TSOP31238 (Besserer Ersatz (2,5-5,5V) für den nicht mehr Lieferbaren TSOP1738) || --- Artikel-Nr. "TSOP 31238"
* ERSA Lötspitzen der Serie 842 (besonders die feinen) Reichelt führt bis jetzt nur 832, die feinen davon sind aber recht unbrauchbar |||| --- sind nach einer freundlichen Mail in den Katalog aufgenommen worden. Artikel-Nr. "SPITZE 842"
* Atmel ATSTK600 von [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4254 Atmel] |||| (AVR STK 600)
* Atmel AVR Dragon von [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 Atmel] ||||| ||||| ||||| ||||| ||| (AT AVR DRAGON)
* Option zum anklicken beim Versand, "nichtverfügbare Artikel automatisch streichen", wenn man das ins Kommentarfeld schreibt wirds nicht beachtet, oder bis das jemand liest dauert es wieder mehrere tage. (In der Zwischenzeit realisiert!!) ||||| ||||| ||||| || (oder klare Anzeige wie viel noch vorhanden ist)
* AVR mit USB: AT90USB1287 (AT 90USB1287 TQ, TQFP64), dazu passendes Demoboard AT 90USB KEY; AT90USB162TQ (AT 90USB162 TQ, TQFP32), AT90USB646 (AT 90USB646 TQ, TQFP64), AT90USB1286QFN (AT 90USB1286 QFN, QFN64), ATmega32u2 (ATMEGA 32-U2 TQ, TQFP44)
* Buchsenleisten 2.54mm (z. B. BL 1X...G 2,54) TEILBAR, *zum Auseinanderbrechen* (laut Anfrage vom 26.10.2009 nicht im Sortiment) (SPL 64?) {{Reichelt50|FF0000}}||||| ||||| ||||| ||||| ||||| ||||| ||||| |
*TLE 4905L :: Hallsensor, 3,8-24V ist lieferbar (20.12.11)

= Sonstiges =

== zur Webseite ==

In "Neu in unserem Shop"/Neue Artikel werden unter Bauelemente u.a. Computerkabel und PC-Speicher angezeigt (Anlass Stand 5/2010, ist aber schon früher aufgefallen). Diese Teile würden zumindest etwas besser in PC-Technik passen. (...und die Freude des Elektronikbastlers über eine Anzahl neuer Bauelemente würde auch nach Auswahl der Details anhalten, wenn es nicht "nur" so etwas wie USB-Kabel sind.)

----

myReichelt ermöglicht:
* Warenkorbspeicherung
* öffentlicher Warenkorb
* CSV-Import, -Export

zu myReichelt siehe auch http://www.mikrocontroller.net/topic/62628

Eine Webseite ohne Frames ist eigentlich heute Stand der Technik. Oder vielleicht ist es das auch nicht mehr - ich weiss es nicht aber nach meiner Auffassung sollte es Stand der Technik sein. Denn dann hat man für jedes Produkt auch einen eindeutigen Link und kann ggf. auch in Beiträgen, Mails und Anfragen darauf verlinken.

Anmerkung dazu:
Verlinken auf Artikel geht schon, und zwar in der Form:
http://www.reichelt.de/?ARTIKEL=ATMEGA%208-16%20DIP
bzw.
http://www.reichelt.de/index.html?ARTIKEL=ATMEGA%208-16%20DIP

Neu zu lesen unter "Info zum Shop":
Zitat:
"Frames
In vielen Votings wurden wir auf die Verwendung von Frames hingewiesen und dass diese Technik nicht mehr -State Of The Art- sei. Dieser Meinung schliessen wir uns in vollem Umfang an. In unserem neuen Shop werden KEINE FRAMES verwendet."

Reichelt selbst macht das in seinen PDF-Prospekten auch so. Das Problem liegt nur darin, die URL jedesmal von Hand zusammenzubauen (und dabei auf die Ersetzung der Leerzeichen durch %20 zu achten) oder von einer kopierten URL alles überflüssige zu entfernen.

Einfach mal einen "Permalink" button neben "Artikel empfehlen" ? Oder zurück mit der früheren Druckansicht.

Hinweis: Viele Browser ersetzen Leerzeichen im Adressfeld automatisch durch %20.

----

Ferner sollte es möglich sein, Bestellungen, welche noch nicht bearbeitet werden zu verändern, also z. B. was hinzuzufügen oder zu entfernen. Bei einer Wartezeit von ca. 3 Tagen bis zum Versand fällt einem doch noch was ein :-)

Das wird bereits gemacht! Einfach E-Mail an service@reichelt.de mit den Bauteilen, die man noch haben will. I-Net-Nummer nicht vergessen.

Andere Möglichkeit ist anrufen, das mache ich eh immer, um eventuell nicht lieferbare Dinge zu streichen oder zu ersetzen. Geht immer, es sei denn Lieferung wird schon verpackt.
----

Shopprogramm: Wäre es nicht komfortabel, ein Programm auf dem heimischen Rechner zu haben, welches das aktuelle Sortiment mit den aktuellen Preisen führt, wo dann auch offline Bestellungen zusammengestellt und hochgeladen werden können? So ließen sich die Merklisten auch besser verwalten.

Ja, das fände ich auch sehr toll, sollte man mal drüber nachdenken.

----

Passwortschutz: Die derzeitige Lösung der Anmeldung im Shop ist für den heutigen Stand der Dinge recht unsicher. Ein zur Kundennummer gehörendes Passwort sollte schon sein. Was soll schon passieren, die Versandadresse ist ja bekannt, und wenn jemand anderes auf meinen Namen bestellt. lässt er sich über die Versandadresse herrausfinden, außerdem weiß ja auch nicht jeder meine Kundennummer.

----

Eine Art Lagerbestand im Onlineshop wäre sinnvoll. Es ist mehr als ärgerlich, wenn bei einer Bestellung z. B. Kleinteile wie Kondensatoren oder Schalter fehlen, weil sie nicht auf Lager waren. Dabei gibt es gerade bei solchen Teilen genug Alternativen, sei es Farbe, Bauart oder Wert, auf die man umsteigen könnte, damit die Bestellung vollständig ist. Es würde ja vollkommen ausreichen den Bestand in Form einer Ampel, wie bei anderen Shops, mit grün, gelb und rot zu realisieren.

Im Warenkorb werden Artikel, die nicht auf Lager sind, mittlerweile auch so gekennzeichnet.

----

Früher würden neue Artikel mit einem gelben "NEU" gekennzeichnet, jetzt ist das nicht mehr so. Hätte gerne wieder einen Überblick, was neu hinzugekommen ist ohne jede Artikelgruppe aufrufen zu müssen. ||

----

Artikelsuche: Bitte standardmäßig in der Liste alle Suchergebnisse anzeigen, nicht nur 16 Stück (oder wenigstens eine vernünftige Anzahl). Die Zeiten der 56k-Modems sind vorbei. ||

----

Nummerierung der Bauteile: Warum wird der Warenkorb nicht nummeriert. Ich hasse es wenn ich manuell mit Hand zählen muss! Das ist auch nervig wenn man manuell per Hand vergleichen will!!

----

Virtuelle Bauteilekisten (vbox): Wer bei Reichelt bestellt, ordert oft viele viele Kleinteile. Wenn man nun ein Gerät zum wiederholten mal baut, muss man alle Teile erneut eingeben. Könnte ich nun neben dem Warenkorb auch noch virtuelle Bauteilekisten füllen, würde das neue Bestellungen sehr beschleunigen. Der Kunde als Wiederholungstäter sozusagen.

Konkret:
Ich habe vier verschiedene Elektronikprojekte entwickelt.Für jedes dieser Projekte lege ich bei Reichelt.de eine virtuelle Bauteilekiste mit eigenem Namen an. Die Zusammenstellung der Artikel funktioniert wie beim normalen Warenkorb. Wenn ich nun ein Projekt erneut bauen möchte, kopiere ich einfach den Inhalt der virtuellen Bauteilekiste per Knopfdruck in meinen Warenkorb. Wenn ich Projekt2 also dreimal nachbauen möchte kopiere ich die virtuelle Bauteilebox "Projekt2" dreifach in den Warenkorb.
Schön wäre es auch die virtuellen Bauteilekisten mit Schaltplan und ev. Eagle - Dateien veröffentlichen zu können.

Und wieso ist der Login, den es früher mal gab weg? Da konnte man zumindest den aktuellen Warenkorb speichern soweit ich mich erinnern kann, aber seit der neuen Website gibt's den Login nicht mehr. Ausserdem muss ich jetzt jedesmal meine Kundennummer rauskramen um meine Bestellung abzusenden - Conrad löst das beispielsweise besser. (dafür haben die aber auch ne besch...eidene Suchfunktion und nen unübersichtlichen Shop)

Nebenanregung:
Damit die "Bauteilekisten" nicht unmengen Platz beim Anbieter verschwenden könnte man diese auslagern.
Also Nach erstellen Download als einfaches File und bei Bedarf einfach bei Bestellung übertragen.
So könnte sie jeder in Ruhe offline vorbereiten und verwalten.

IDEE: Offenlegung der Datenbank: Offenlegung der Datenbank oder zumindest Export für die User. Somit koennten die Datenbank in eine Art Datenbank gespeichert werden. Als Katalogprogramm koennte dann soetwas ähnliches wie das von Segor zum Einsatz kommen. Gibt es einen Standard dann koennten Reichelt, Conrad, Segor, etc. mit einem Programm genutzt und verglichen werden:
siehe auch http://www.mikrocontroller.net/forum/read-7-363596.html
Programmierunterstuetzung findet sich bestimmt. Abgesehen davon haben die Distributoren den Vorteil die Katalogdaten übers Internet upzudaten.

Zum offenlegen der Datenbank: Wie wäre es mit einem Webservice, mit dem man über SOAP auf die Datenbank zugreifen kann? Ähnlich wie bei Amazon oder auch Google.

Lösung in HTML: 
Ich hatte für das Projekt [http://www.mikrocontroller.net/topic/82127 "Webserver ATmega32/644DIP ENC28J60"] ein Bestellformular ([http://www.mikrocontroller.net/attachment/29451/reichelt.htm reichelt.htm] [Version vom 22.12.2007]) gebastelt um schnell alle nötigen teile in den Reichelt – Warenkorb zulegen. Mit etwas HTML-Kenntnis dürfte eine Anpassung nicht das Problem darstellen. 
In JavaScript, des '''reichelt.htm''' Bestellformulars, die Funktion <code>'''send()''' ''Zeile 42:'' var maxElements = 40;</code> die '''40''' durch die Anzahl der unterschiedlichen Bauteile Anpassen.

== zu Artikeln ==

* Spitze fände ich eine verbesserte Suche für Gehäuse. Oft stehe ich vor dem Problem, meine Baugruppe ist so-und-so groß und ich brauche ein Gehäuse, in das diese Baugruppe hineinpasst. Zur Zeit muss ich mich manuell durch alle Gehäusegrößen "durchwühlen", bis ich ein passendes gefunden habe. Die Suche stelle ich mir so vor: Ich gebe die Maße ein, die das Gehäuse mindestens haben ''muss'', und bekomme alle Gehäuse angezeigt, die genau so groß oder etwas größer sind als meine Vorgaben.

== Abwicklung ==

* Sammelbestellung: Wenn ich etwas bei Reichelt bestelle, bestelle ich für meine Kollegen auch immer etwas mit. Wenn dann das Päckchen kommt, heisst es sortieren. Wer hatte von was, wie viel? Danach kommt das rechnen dran. Ein besonderes Highlight, sind die Nettopreise. Und auch das Verteilen der Versandkosten ist nicht ohne. Währe es nicht möglich, im Bestellvorgang eine Zuordnung zu Personen oder Projekten zu realisieren, und die Zwischensummen der Personen oder Projekte auf der Rechnung oder per Mail anzugeben. Ein Schmankerl wäre die Angabe der Bruttopreise inklusive der anteiligen Versandkosten.
** Wahrscheinlich nicht möglich, siehe AGB-Klausel zu Massenbestellungen. "Garantieberechtigt" ist auch immer nur der ursprüngliche Besteller.
** Welche Klausel? Mir fällt nur 13.3 ins Auge...

* Abpackgrößen bei SMD-Bauteilen auf 5- oder 10er-Schritte beschränken. Die meisten sind eh im Cent-Bereich und es dürfte logistisch einfacher/schneller sein, feste Stückzahlen vorzuhalten, was man preislich sicher an die Kunden weitergeben kann ;)

== zu dieser Wunschliste ==

(gehört eigentlich in Diskussion)

* Wäre es möglich ein Script zu bauen, welches man ab und zu über diesen Artikel jagt und das die Einträge nach Anzahl der Striche ordnet? => Formatierung als Tabelle (1. Spalte: das Teil, 2. Spalte: die Striche) würde auch schon helfen.
** Das geht kaum, weil | ein SOnderzeichen in Vorlagen ist.

* Dass hier jeder immer nur einen Strich macht, glaube ich nicht! Ein Script was pro IP nur einen Strich zulässt wäre gut. -> Naja, alle 24h spätestens gibt es eigendlich eine neue IP... Antwort: Lässt sich sehr leicht überprüfen mit Artikel -> Versionen

* Warum macht der 5te nicht anstelle |||| ein V :-) und anstelle vom nächsten V kommt dann ein X ....Daniel [[Benutzer:84.179.17.164|84.179.17.164]] 20:11, 4. Feb 2006 (CET)
::Sehr clever. Das würde es Reichelt bestimmt enorm erleichtern, stark nachgefragte Artikel schnell zu erkennen. *facepalm* ;-)

* Wenn Reichelt was aus der Liste neu ins Programm aufnimmt wäre eine Benachrichtigung per Newsletter oder RSS nett. Oder zumindest eine Rubrik "Seit XX.XX.200X neu im Programm".

== Logbuch ==

20.03.2012: Sensorik Aktorik: Merge und alphabetische Sortierung

19.03.2012: Aufräumarbeiten (>50 eingefärbt, Blöcke >5 getrennt)
Dachte dafür gibts hier einen Bot, der dann auch am besten gleich nach Wunschhäufigkeit sortieren könnte...derweil habe ich den Bio-Bot gemacht...hoffe das geht OK, oder gibts da FESTE Zuständigkeiten?

07.10.2011: Reichelt über Facebook drauf aufmerksam gemacht - man schaue sich die Liste regelmäßig durch :)

01.10.2011: Umfangreiche Neuordnung der gesamten Wishlist: Neue Unterkategorien, alphabetische Sortierung, Zusammenführung gleicher Wünsche aus verschiedenen Kategorien, Fix diverse Falsch-Einsortierungen, Update inzwischen erhältlicher Teile, Ausbau einzelner Einträge für bessere Sortierung und mehr Info beim Lesen (nicht nur IC-Namen), etc. Vielleicht hat ja noch jemand nen Einfall für die Sichtbarmachung besonders nachgefragter Einträge, Fett- und Kursivdruck der '''''|||||'''''-Blöcke funktioniert ja leider nicht...

...bei Ausrufezeichen funktionierts aber. Meinungen zur Farbe und der Auslagerung in eine Vorlage?--[[Benutzer:Bzzz|Bzzz]] 14:49, 1. Okt. 2011 (UTC)

03.03.2011: E-Mail wurde an Reichelt-Verwaltung geschrieben.

8.4.2010: Mail an Reichelt geschickt und an die Liste erinnert.

2.10.2009: REVERT auf die Version vor dem 20.Jul.2009 12:47. Da der Artikel von 193.200.150.82 "verdoppelt" wurde. D.h. alles war doppelt vorhanden und die Einleitung gelöscht

19.06.2009: Hab mal den Kram unter der Rubrik "Webseite" entfernt/zusammengefasst der schon realisiert wurde. -- Tobias

12.03.2009: Da haben wir ja alle verpennt, Reichelt in 2008 mal wieder an die Liste zu erinnern. Ich hab das jetzt mal nachgeholt und eine Mail an Reichelt geschickt. -- [http://www.reintechnisch.de Winfried Mueller]

03.08.2007: Das Feld für "neue Artikel" scheint aus dem Reichelt Shop entfernt worden zu sein, schade da man so schnell schauen konnte was neu im Programm ist, nun ist wieder Katalogblättern angesagt. - Nicht nachvollziehbar. siehe Startseite->Service->Neu in unserem Shop

18.05.2007: Habe Reichelt an diese Liste erinnert. -- Robin Tönniges

14.11.2006 Ich lese mir gerade euer Wishlist durch. Finde ich gut! Aber wie ihr
hier (Logbuch) über Reichelt kritisiert finde ich nicht fair! Die haben genug zu arbeiten! Bitte keine Vorurteile! Um das gehts mir hauptsächlich!
Macht weiter nur nicht so!
P.S. Schöne inforeiche Site
Steven

6.8.2006 Habe eine umfassende Kritik zu Reichelts neuem Webshop geschrieben und dabei auf unsere Wünsche bzl. Webseite, insbesondere "Virtuelle Bauteilebox" und "Gehäusesuche" hingewiesen. Verlinkung auf diese Seite ist auch erwähnt worden.

5.8.2006 Hurra, Reichelt bietet endlich den ATtiny13V an! Jetzt können wir Batteriebetriebene Geräte (2,4-3V) bauen. By the way: Gibt es blaue LED's, die dazu passen?

14.7.2006 Reichelt antwortete: (Zu lang, deshalb hier nur der Inhalt:) Wir haben ihre mail zur Kenntnis genommen (Forum wird angeblich ab und zu immer wieder kontrolliert). Entscheidender Satz (Original eines Mitarbeiters:)....Ich denke jedoch, dass die meisten und
wichtigsten Wünsche zum Herbstkatalog eingelistet werden.

14.7.2006 Reichelt erneut auf diesen Beitrag aufmerksam gemacht, erwarte Antwort.

3.7.2006: beitz-online.de eine verlinkung gemailt. Ich hoffe das ist erlaubt.

5.3.2006: Verlinkung gemailt

12.10.2005: Verlinkung gemailt und gebeten sich darum zu kümmern

07.10.2005: Reichelt eine Verlinkung gemailt und speziell auf LOW ESR Elkos und 433 Mhz Funkmodule hingewiesen. Mal sehen was die Antworten.

08.07.2005: Reichelt bescheid gegeben, man möge mal wieder hier rein schauen -- Thomas O.

13.05.2005: Antwort von Reichelt: der Versand ins Ausland bleibt leider bei 150 Eur -- nurmi

09.05.2005: Reichelt bescheid gegeben, man möge mal wieder hier rein schauen -- nurmi

08.05.2005: Pflege der Liste hier: Wenn ihr was in der Liste seht, was bereits schon im Angebot ist, löscht es bitte! Sonst ist das hier bald ein unüberschaubares Chaos. -- [http://www.reintechnisch.de Winfried Mueller]

08.02.2005: Positives Feedback von Reichelt. Freuen sich über diese Form der Anregung. In der 2. Märzhälfte sollen weitere Produkte in den neuen Katalog einfließen. -- [http://www.reintechnisch.de Winfried Mueller]

07.02.2005: Reichelt bescheid gegeben, man möge mal wieder hier rein schauen -- [http://www.reintechnisch.de Winfried Mueller]

[[Kategorie:Bauteile]]
[[Kategorie:Lieferanten]]

AVR Bootloader in C - eine einfache Anleitung

2011-12-19T23:16:58Z

Sebion7125: /* Schritt 3 - Programmieren der Anwendung */

Dieser Artikel soll dazu dienen, das Thema [[Bootloader]] im AVR etwas zu demystifizieren.

Es gibt schon einige Artikel und Codebeispiele für verschiedene Bootloader in Assembler oder C (bzw. gemischt), aber kein Artikel beleuchtet das Thema von einer einfachen Seite aus Anwendungssicht. In diese Lücke zielt dieses Tutorial.
Es soll anhand von Beispielen einen möglichst einfachen, verständlichen und nachvollziehbaren Weg zeigen, sich mit Hilfe der Hochsprache C in das Thema einzuarbeiten (dabei soll weder Assembler noch Inline-Assembler verwendet werden).

Vielleicht werden einige meinen dass es nicht möglich ist das Thema ohne tieferen Einblick in die Hardware und die AVR-Register zu beleuchten, ich möchte es aber trotzdem versuchen.

Der Artikel wird sich auf das notwendige Wissen beschränken, um mit Booloadern arbeiten zu können. Es wird ein genereller Weg gezeigt, der sich leicht auf andere AVR-Devices (mit Bootloader Sektion) übertragen lässt.
Die Codebeispiele wurden für den ATmega88 kompiliert und getestet.

== Einleitung ==

Zu Beginn soll das notwendige Wissen über die Bootloaderunterstützung im AVR vermittelt werden, um eine Arbeitsgrundlage zu schaffen.

Im weiteren Verlauf des Artikels werden insgesamt drei Anwendungen programmiert: Zuerst ein einfacher Bootloader, welcher in der Bootloadersektion des Flashs ausgeführt wird, aber noch keine eigentliche Bootloader-Funktion hat, sozusagen ein "Hallo Welt"-Bootloader. Danach soll eine kleine Applikation programmiert werden, welche der spätere ''echte'' Bootloader ins Flash programmieren soll. Als großes Finale soll dann ein Bootloader entstehen, welcher in der Lage ist, Intel-HEX-Dateien über die serielle Schnittstelle zu laden, ins Flash zu programmieren und zu starten.

Der Leser sollte bereits Erfahrungen im Umgang mit dem AVR Studio und der Programmiersprache C gemacht haben und schon Anwendungen geschrieben haben. Für absolute Einsteiger ist der Artikel ungeeignet.

Den Thread zum Artikel gibt es hier: http://www.mikrocontroller.net/topic/195102

== Software ==

Für den Artikel werden folgende Software-Pakete benötigt:

* aktuelles [http://http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] (hier verwendet: AVR Studio v4.18)
* aktuelles [http://sourceforge.net/projects/winavr/files/ WinAVR] (hier verwendet: WinAVR20100110)
* [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY] als serielle Konsole (Version v0.6)

Des weiteren wurde auf der AVR-Seite für die serielle Kommunikation mit dem PC auf die beliebte UART-Library von [http://www.jump.to/fleury Peter Fleury] zurückgegriffen, damit wir uns nicht um die gepufferte UART-Kommunikation kümmern müssen.

== Hardware ==

Für den Artikel wurde eine kleine Hardware bestehend aus einem [http://www.atmel.com/dyn/products/product_card.asp?part_id=3302 Atmega88] und einem [http://www.ftdichip.com/Products/ICs/FT232R.htm FT232] als USB-Seriell-Wandler erstellt. Dies soll als Basis für die Experimente dienen. Der USB-Seriell-Wandler ist nicht zwingend notwendig und kann auch durch den üblichen Pegelwandler vom Typ [http://www.maxim-ic.com/datasheet/index.mvp/id/1798/ln/en MAX232] ersetzt werden, wenn der PC noch eine serielle Schnittstelle besitzt. Entscheidend ist nur die Möglichkeit der seriellen Kommunikation mit dem Rechner.

[[Bild:Schaltplan-ATmega88-USB.png|800px|Schaltplan]]

Für die ISP-Programmierung wurde der [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3808 AVRISPmkII-In-System-Programmer] von Atmel verwendet. Es kann natürlich auch ein anderer Programmer (z.B. [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735 STK500]) verwendet werden, welcher mit dem AVR Studio zusammenarbeitet. Prinzipiell kann natürlich auch ein selbstgebastelter Parallel-Programmer verwendet werden, dann kann aber nicht via AVR Studio programmiert werden, sondern mit [http://www.nongnu.org/avrdude/ AVRDude] oder [http://www.lancos.com/prog.html PonyProg] o.ä. Der Artikel beschränkt sich auf die Verwendung vom AVR Studio.

Für das Verständis der Hardware und der seriellen Kommunikation sind folgende Artikel empfehlenswert:

* [[AVR-Tutorial: UART]]
* [[RS-232]]

= Grundlagen =

[[Bild:AVR-Memory.png|400px|thumb|Flash Speicher Aufteilung]]

Was ist eigentlich ein Bootloader und was macht er? Wofür sollte ich so etwas brauchen? Ist das nicht viel zu kompliziert? Ich bin eingefleischter AVR Studio-Benutzer, muss ich mich jetzt mit makefiles beschäftigen? Kann man im AVR Studio mit C überhaupt einen Bootloader schreiben? Vielleicht hat sich der eine oder andere schon einmal diese oder ähnliche Fragen gestellt.

Der Programmcode des AVR steht in seinem Flashspeicher und wird von dort ausgeführt. Normalerweise kann während der Ausführung des Programms nicht auf den Flashspeicher geschrieben werden. Dies ist auch einleuchtend da sich das Programm ja sonst selbst überschreiben oder löschen könnte. Das Beschreiben des Flashs erfolgt beim AVR üblicherweise über die ISP-Schnittstelle, dabei befindet sich der Controller im Reset und es wird kein Programm ausgeführt. Dies ist für Prototyping und kleine Anwendungen hinnehmbar. Ist der Controller allerdings in einem größeren System oder in größerer räumlicher Entfernung verbaut und die ISP-Schnittstelle nicht mehr zugänglich, ist ein Update der Firmware nicht mehr ohne Weiteres möglich oder sehr teuer und aufwendig. Hier kann ein Bootloader Abhilfe schaffen, in dem er das Anwendungsprogramm auf einer definierten Schnittstelle entgegennimmt (UART, I2C, Wireless) und ins Flash transferiert. Ein Bootloader ist also in erster Linie ein kleines Programm, welches in einem besonderem Teil des Flash steht - der '''Boot Loader Section'''. Durch die Lokalisierung des Bootloader-Programms in dieser besonderen Sektion des AVR ist es dem Programm möglich, auf Teile des Flashs - der sogenannten '''Application Flash Section''' - zu schreiben. Die eigentliche Anwendung wird ausschließlich in der '''Application Flash Section''' ausgeführt. Wenn man so will, können im Flash des AVR also zwei unabhängige Programme stehen. Der Flash ist in zwei Bereiche mit unterschiedlichen Merkmalen aufgeteilt (siehe Bild). Auf die RWW bzw. NRWW-Sektion möchte ich an dieser Stelle (noch) nicht eingehen.

Wie man unschwer erkennen kann, liegt der Bootloader-Bereich am Ende des Flash-Speichers. Normalerweise startet der Controller die Abarbeitung seiner Programmierung an der Stelle 0x0000. Ein Bootloader soll ja aber '''vor''' der Abarbeitung der eigentlichen Applikation ausgeführt werden. Woher weiß also der AVR-Controller nach dem Reset, dass er nicht von Adresse 0x0000 sondern einer anderen Adresse starten soll? Diese Konfiguration ist wie alle wichtigen und grundlegenden Konfigurationen über die Fuses des AVRs geregelt. Wir beginnen mit der folgende Tabelle, welche die Speicheraufteilung des Programmspeichers veranschaulicht.

{| border="1" class="wikitable"
|+ Boot Size Konfiguration, Tabelle 26-6 im Atmega88-Datenblatt S.280
|-
! BOOTSZ1 || BOOTSZ0 || Boot Size || Pages || Application Flash Section || Boot Loader Flash Section || End Application Section || Boot Reset (Start Boot Loader Section)
|-
| 1 || 1 || 128 words || 4 || 0x000 - 0xF7F || 0xF80 - 0xFFF || 0xF7F || 0xF80
|-
| 1 || 0 || 256 words || 8 || 0x000 - 0xEFF || 0xF00 - 0xFFF || 0xEFF || 0xF00
|-
| 0 || 1 || 512 words || 16 || 0x000 - 0xDFF || 0xE00 - 0xFFF || 0xDFF || 0xE00
|-
| 0 || 0 || 1024 words || 32 || 0x000 - 0xBFF || 0xC00 - 0xFFF || 0xBFF || 0xC00
|}

Um die Tabelle zu verstehen muss man wissen, dass der Flash-Speicher intern in sogenannten ''Pages'' (Seiten) organisiert ist. Die Multiplikation der ''Page''-Größe mit der Anzahl der ''Pages'' ergibt die Speichergröße. Die Größe einer ''Page'' steht im Datenblatt und ist in ''Words'' - also Datenworte - angegeben. Ein Datenwort entspricht zwei Bytes. '''''Hier offenbart sich eine Tücke des Datenblatts: Alle Speicherbezüge und Adressen sind in Datenworten (also immer 2 Bytes) angegeben!'''''
Aus der Tabelle erfahren wir auch, dass man mit den beiden Fuses '''BOOTSZ0''' und '''BOOTSZ1''' die Größe des Bootloaderbereichs einstellen kann. Eine weitere Tabelle aus dem Atmega88-Datenblatt gibt Auskunft über die Aufteilung der Pages und die Anzahl der Datenworte einer Page.

{| border="1" class="wikitable"
|+ No.of Words in a Page and No.of Pages in Flash, Tabelle 27-9 im Atmega88-Datenblatt S.288
|-
! Device || Flash Size || Page Size || PCWORD || No. of Pages || PCPAGE || PCMSB
|-
| Atmega88 || 4K words (8 Kbytes) || 32 words || PC[4:0] || 128 || PC[11:5] || 11
|}

Aus der Tabelle ergibt sich, dass die Größe einer ''Page'' des verwendeten Atmega88 32 ''Words'' - also 64 Byte sind. Insgesamt gibt es 128 ''Pages'', damit ergibt sich nach Adam Riese 128 * 64 = 8192 Byte, also 8 Kbytes. In unserem späteren Codebeispiel soll die Größe des Bootloaderbereichs auf 1024 ''words'' - also 2048 Bytes gestellt werden ('''BOOTSZ0=0''' und '''BOOTSZ1=0'''). Nun können wir ausrechnen, in welcher Flash-''Page'' bzw. an welcher Flash-Adresse der Bootloaderbereich beginnt: Er beginnt in der 96 ''Page'' (128 - 32) an ''Word''-Adresse 0xC00, also Byteadresse 0xC00 * 2 = 0x1800. Dies ist die exakte Startadresse unseres Bootloaderbereiches.

Weiter oben wurde die Frage gestellt, woher der AVR weiß, an welcher Stelle (entweder 0x0000 oder in unserem Fall 0x1800) er nach dem Reset starten soll. Um dem AVR dies mitzuteilen, ist eine weitere Fuse nötig - die '''BOOTRST'''-Fuse. Eine weitere Tabelle aus dem Atmega88-Datenblatt gibt Auskunft über diese Fuse.

{| border="1" class="wikitable"
|+ Reset and Interrupt Vectors Placement in Atmega88, Tabelle 11-3 im Atmega88-Datenblatt S.58
|-
! BOOTRST|| IVSEL || Reset Adress || Interrupt Vectors Start Adress
|-
| 1 || 0 || 0x000 || 0x001
|-
| 1 || 1 || 0x000 || Boot Reset Address + 0x001
|-
| 0 || 0 || Boot Reset Address || 0x001
|-
| 0 || 1 || Boot Reset Address || Boot Reset Address + 0x001
|}

Mit der '''BOOTRST'''-Fuse wird festgelegt, dass der AVR nach dem Reset an die Startadresse der Bootloader Sektion im Flash springt. Auf das '''IVSEL'''-Bit (keine Fuse) möchte ich erst an späterer Stelle - wenn es um Interrupts geht - zurückkommen.

'''Noch ein wichtiger Hinweis für die Werte der Fuses im Datenblatt:''' '''''Der Wert "0" bedeutet, dass die Fuse programmiert ist, es entspicht dem Häkchen im AVR Studio!'''''

= Der "Hallo Welt" - Bootloader =

Wie oben erwähnt, wird für die Erstellung des Codes die kostenlose IDE von Atmel - das AVRStudio - benutzt. Ergänzt wird es durch C-Compiler und Tools des WinAVR Projektes. Des weiteren wird zur seriellen Kommunikation das Terminalprogramm benötigt. Im Tutorial wird PuTTY verwendet und sollte installiert sein. Die Hardware ist aufgebaut und via AVRISPmkII-Programmer an den PC angeschlossen - nun kann es losgehen!

Zu Beginn wird ein neues AVRStudio-Projekt erstellt. Danach werden folgende Schritte abgearbeitet:

== Schritt 1 - Konfiguration der Projekteinstellungen ==
[[Bild:Bootloader-Projekt.png|200px|thumb|Erstellen des Projekts]]
[[Bild:Bootloader-Config-General.PNG|200px|thumb|Generelle Optionen - setzten der Taktfrequenz]]
[[Bild:Bootloader-Config-Linker.png|200px|thumb|Linker Option eingeben]]

Als erstes öffnen wir die Projekteinstellungen (Menü ''Project/Configuration Options'') und tragen die richtige Taktfrequenz ein (Im Beispiel nutzen wir den internen Oszillator mit 8 Mhz). Danach gehen wir zum Reiter '''Custom Options'''. Dort klicken wir auf '''Linker Options''' und geben dann im Textfeld daneben '''-Ttext=0x1800''' ein. Danach drücken wir auf '''Add'''.

Was bewirkt dieser Linker-Parameter? Dafür muß wieder etwas weiter ausgeholt werden. Nach dem Kompilieren der Programmquellen ''linkt'' der Linker den Programmcode an bestimmte Stellen in den drei verschiedenen Speichern Flash, EEPROM und SRAM des AVR. In der vom Compiler verwendeten [http://www.nongnu.org/avr-libc/user-manual/mem_sections.html AVR Libc] ist der Speicher in verschiedene Sektionen aufgeteilt. Dem Linker muss mitgeteilt werden, in welche Speicher er den Programmcode linken soll. Die Lokalisierung des Speichers sind die Sektionen. Die Sektion ''.text'' ist dem ausführbaren Programmcode - also den Befehlen - vorbehalten und liegt im Flash des AVR, des weiteren gibt es auch noch die Sektionen ''.data'' und ''.bss'' für die statischen und dynamischen Variablen im SRAM und eine Sektion ''.eeprom'' für den EEPROM und noch ein paar spezielle (Flash-)Sektionen.

Nun gibt es verschiedene Methoden, dem Linker mitzuteilen, dass man den Programmcode an die Stelle des Bootloaderbereichs haben möchte. Eine sehr einfache Methode ist '''die Verschiebung der Sektion ''' '''''.text''''', welche normalerweise ab Adresse 0x0000 beginnt. Eben dies geschieht mit dem Linker Parameter '''-Ttext=0x1800'''. Die Adresse des Beginns der ''.text'' Sektion wird auf die (Byte-)Adresse 0x1800 gesetzt.

== Schritt 2 - Einbinden der UART Library von Peter Fleury ==

Wie bereits erwähnt, wird für die serielle Kommunikation auf der AVR-Seite die UART-Library von [http://www.jump.to/fleury Peter Fleury] verwendet. Nach dem Download werden die uart.c und uart.h in das Projekt eingebunden (für die uart.c im AVR Studio rechte Maustaste auf ''Source Files'' und dann ''Add Existing Source File(s)...'' und für die uart.h die rechte Maustaste auf ''Header Files'' und dann ''Add Existing Header File(s)...'')

== Schritt 3 - Programmieren des Bootloaders ==

[[Bild:Bootloader-Config-Linker-ok.PNG|200px|thumb|Linker Option nach Add]]
[[Bild:Bootloader-AVRStudio.PNG|200px|thumb|Kompilieren des Bootloaders]]

Nun soll eine kleine Applikation geschrieben werden. Keine Angst, unser erstes Ziel ist es, eine kleine Anwendung in dem Bootloaderbereich zu positionieren, welche serielle Ein-und Ausgaben behandelt. Die eigentliche Bootloaderfunktionalität kommt später dazu. Also schreiben wir die Datei ''main.c'' wie folgt:

<c>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/boot.h>
#include <util/delay.h>
#include "uart.h"

#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */

int main()
{
unsigned int c=0; /* Empfangenes Zeichen + Statuscode */
unsigned char temp, /* Variable */
flag=1, /* Flag zum steuern der Endlosschleife */
p_mode=0; /* Flag zum steuern des Programmiermodus */
void (*start)( void ) = 0x0000; /* Funktionspointer auf 0x0000 */

/* Interrupt Vektoren verbiegen */

char sregtemp = SREG;
cli();
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);
SREG = sregtemp;

/* Einstellen der Baudrate und aktivieren der Interrupts */
uart_init( UART_BAUD_SELECT(BOOT_UART_BAUD_RATE,F_CPU) );
sei();

uart_puts("Hallo hier ist der Bootloader\n\r");
_delay_ms(1000);

do
{
c = uart_getc();
if( !(c & UART_NO_DATA) )
{
switch((unsigned char)c)
{
case 'q':
flag=0;
uart_puts("Verlasse den Bootloader!\n\r");
break;
default:
uart_puts("Du hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
uart_puts("\n\r");
break;
}
}
}
while(flag);

uart_puts("Springe zur Adresse 0x0000!\n\r");
_delay_ms(1000);

/* vor Rücksprung eventuell benutzte Hardware deaktivieren
und Interrupts global deaktivieren, da kein "echter" Reset erfolgt */

/* Interrupt Vektoren wieder gerade biegen */
cli();
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp & ~(1<<IVSEL);

/* Rücksprung zur Adresse 0x0000 */
start();
return 0;
}
</c>

'''''Erklärung des Codes'''''

Beginnen wir mit den Defines: Die Baudrate erklärt sich von selbst. Die Defines XON und XOFF werden später, wenn die Bootloader-Funktionalität dazukommt, zur Flusssteuerung gebraucht. Wir werden also die XON/XOFF-Flussteuerung nutzen (merken für die Einstellung von PuTTY).

Bei den Variablen ist nur eine interessant: Der Funktionspointer <pre>void (*start)( void ) = 0x0000;</pre> ist ein einfacher Trick, um mit dem Programmcounter (PC) zur Adresse 0x0000 zu springen. Wir definieren einfach eine (fiktive) Funktion an der Stelle 0x0000. Beim Aufruf der Funktion mit <pre>start();</pre> springt der Programmcounter und damit das Programm an Adresse 0x0000 und das Anwendungsprogramm - wenn es eins gibt - kann starten.

Nun folgt ein sehr wichtiger Teil, auf den ich noch eingehen muss - die Interrupt-Vektoren. Interrupt-Vektoren sind Einsprungpunkte der Interrupts, welche normalerweise fest ab Adresse 0x0001 im Flash liegen. Wird ein Interrupt ausgelöst, springt der AVR automatisch zu der festen Flash-Adresse. Von dort aus - wenn eine ISR programmiert ist - springt der Controller zur ISR ('''I'''nterrupt '''S'''ervice '''R'''outine). Nun haben wir folgendes Problem: Wenn wir den Bootloadercode ab der Adresse 0x1800 ausführen, nützt es uns gar nichts, wenn der AVR nach Auslösen eines Interrupts an die Stelle 0x0001 + X springt, da dieser Speicherbereich ja im Zweifelsfalle sogar von uns überschrieben wird. Unser Code soll nur ab Adresse 0x1800 stehen! Wir müssen also die Sprungtabelle "verbiegen", d.h. den AVR veranlassen, bei Auslösung eines Interrupts an Adresse 0x1801 + X zu springen und dann zur ISR. Das Verbiegen der Sprungtabelle passiert mit dem Setzen des '''IVSEL'''-Bits im '''MCUCR''' (ACHTUNG: beim Atmega8 '''GICR'''), also

beim Atmega88:
<pre>
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);
</pre>

bzw. beim Atmega8:
<pre>
temp = GICR;
GICR = temp | (1<<IVCE);
GICR = temp | (1<<IVSEL);
</pre>

Das '''IVCE'''-Bit wird nur benötigt, um dem Mikrocontroller zu sagen, dass wir als nächstes den Parameter '''IVSEL''' setzen wollen, das Bit wird nachher vom Controller wieder gelöscht. Um versehentliches verstellen der Interrupttabelle zu vermeiden muss das setzen von '''IVCE''' und '''IVSEL''' innerhalb von 4 Taktzyklen erfolgen. Um dies zu gewährleisten müssen alle interrupts während des Setzens deaktiviert sein. ACHTUNG Stolperfalle: Die Variable temp wird benötigt, da beim Setzen von '''IVSEL''' gleichzeitig '''IVCE''' gelöscht werden muss:

bei Atmega8/16:
<pre>
GICR |= (1<<IVCE); // noch richtig. IVCE wird gesetzt
GICR |= (1<<IVSEL); // falsch! IVSEL wird zwar gesetzt,
IVCE bleibt jedoch in diesem Prozessortakt gesetzt.
</pre>

In der Hauptschleife wird lediglich gepollt, ob ein neues Zeichen von der Konsole kommt. Nach dem Empfang eines Zeichens wird es ausgewertet (switch). Nach dem Drücken von ''"q"'' verlässt der Bootloader die Hauptschleife, setzt die Interrupt-Vektoren wieder zurück und startet die Hauptanwendung - wenn eine da ist.

Nach dem Kompilieren sagt uns der Linker, dass 754 Byte Programmspeicher und 265 Byte Datenspeicher verbraucht wurde. 754 Byte ist weit unter den 2048 Byte, welche uns ab der Adresse 0x1800 zur Verfügung stehen, wir haben also alles richtig gemacht.

Nun kontrollieren wir noch schnell, ob das Programm an der richtigen Stelle im Flash steht. Mit dem Hex-File (Bootloader.hex) wird auch ein List-File (Bootloader.lss) erzeugt. Im List-File findet sich das disassemblierte Programm und die Speicherzuordnungen. Hier ein Auszug der Datei:

<pre>
Bootloader.elf: file format elf32-avr

Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000080 00800100 00001a68 000002fc 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 00000268 00001800 00001800 00000094 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 00000085 00800180 00800180 0000037c 2**0
ALLOC
3 .debug_aranges 00000040 00000000 00000000 0000037c 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_pubnames 00000095 00000000 00000000 000003bc 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_info 00000459 00000000 00000000 00000451 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_abbrev 00000238 00000000 00000000 000008aa 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_line 000003eb 00000000 00000000 00000ae2 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_frame 000000a0 00000000 00000000 00000ed0 2**2
CONTENTS, READONLY, DEBUGGING
9 .debug_str 000001cf 00000000 00000000 00000f70 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_loc 0000024a 00000000 00000000 0000113f 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_ranges 00000048 00000000 00000000 00001389 2**0
CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00001800 <__vectors>:
1800: 19 c0 rjmp .+50 ; 0x1834 <__ctors_end>
1802: 33 c0 rjmp .+102 ; 0x186a <__bad_interrupt>
1804: 32 c0 rjmp .+100 ; 0x186a <__bad_interrupt>
1806: 31 c0 rjmp .+98 ; 0x186a <__bad_interrupt>
1808: 30 c0 rjmp .+96 ; 0x186a <__bad_interrupt>
180a: 2f c0 rjmp .+94 ; 0x186a <__bad_interrupt>
180c: 2e c0 rjmp .+92 ; 0x186a

...
(viele Zeilen)
...

0000186c <main>:
#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */

int main()
{
186c: cf 93 push r28
186e: df 93 push r29
unsigned char temp, /* Variable */
flag=1; /* Flag zum steuern der Endlosschleife */
void (*start)( void ) = 0x0000; /* Funktionspointer auf 0x0000 */

/* Interrupt Vektoren verbiegen */
temp = MCUCR;
1870: 85 b7 in r24, 0x35 ; 53
MCUCR = temp | (1<<IVCE);
1872: 98 2f mov r25, r24
1874: 91 60 ori r25, 0x01 ; 1
1876: 95 bf out 0x35, r25 ; 53
MCUCR = temp | (1<<IVSEL);
1878: 82 60 ori r24, 0x02 ; 2
187a: 85 bf out 0x35, r24 ; 53

...
(noch mehr Zeilen)
</pre>

Wir erkennen, dass die Sektion ''.text'' ab der Adresse (VMA) 0x1800 beginnt. Weiter sehen wir im Disassembly der Sektion ''.text'', dass unser Programm mit der Interrupt-Einsprungstabelle ab Adresse 0x1800 beginnt. Unsere ''main()'' beginnt ab Adresse 0x186C. Super. Das hat geklappt. Aber nun schnell zu Schritt 4 - dem Flashen und Ausprobieren des Programms...

== Schritt 4 - Flashen und Ausprobieren des Bootloaders ==

[[Bild:Bootloader-AVRStudio-Fuses.png|200px|thumb|Setzen der Fuses]]
[[Bild:PuTTY-Serconfig.png|200px|thumb|Serielle Konfiguration von PuTTY]]
[[Bild:PuTTY-Serconfig-xon.png|200px|thumb|Serielle Konfiguration von PuTTY]]

Nach dem Start des AVRISPmkII-In-System-Programmers aus dem AVRStudio werden zunächst die Einstellungen geprüft. Die Signatur des AVRs muss stimmen und die ISP-Frequenz. Im Reiter Program muss unter ''Flash'' die richtige Datei angegeben sein (''Bootloader.hex''). Danach können wir uns an das setzen der Fuses machen. '''CKDIV8''' sollte ausgeschalten werden, der interne Takt von 8 Mhz sollte genutzt werden ('''SUT_CKSEL''') und ''BOOTSZ'' auf 1024 words gestellt werden. Zusätzlich muß die '''BOOTRST'''-Fuse gesetzt werden, damit der Bootloader an der richtigen Adresse anfängt. Für alle, die einen anderen Programmer benutzen (z.B. avrdude), hier die exakten Werte der Fuses:
* Low Fuse: '''0xE2'''
* High Fuse: '''0xD2'''
* Extended Fuse: '''0xF8'''

Jetzt kann PuTTY gestartet und konfiguriert werden. Der ''Connection type'' muss auf '''Serial''' gestellt werden. Die Baudrate beträgt 9600 Baud. Unter ''Connection/Serial'' muss der ''Flow control'' auf '''XON/XOFF''' gestellt werden. Nach dem Konfigurieren kann die Konsole mit ''Open'' geöffnet werden.

Jetzt kann wieder in das AVR Studio gewechselt werden. Mit einem beherztem Druck auf ''Program'' wird das Flash im ATmega88 programmiert. Nach dem Wechsel auf die Konsole erscheint folgendes Bild:

[[Bild:PuTTY-Bootloader-start.png|600px|Bootloader in PuTTY]]

Nach dem Drücken von ein paar Tasten erscheint folgendes:

[[Bild:PuTTY-Bootloader-taste.png|600px|Bootloader nach Tastendruck in PuTTY]]

Nach dem Drücken von '''q''' erscheint folgendes Bild:

[[Bild:PuTTY-Bootloader-restart.png|600px|Bootloader nach Tastendruck in PuTTY]]

Der Bootloader versucht, zur Adresse 0x0000 zu springen, wo er allerdings keinen Programmcode findet. Wie auch? Wir haben ja den ganzen Flash des AVR gerade gelöscht und mit dem Bootloader gefüllt. Nun muss man wissen, dass in einem gelöschten Flash ''0xFF'' in jeder Speicherzelle steht. ''0xFF'' ist für den AVR kein gültiger Opcode. Der Programmzähler zählt nur um eins nach oben. Damit hopst er sozusagen durch den gesamten Flash bis er wieder beim Bootloader landet.

'''''[http://de.wikipedia.org/wiki/Heureka Heureka]''''' wir haben es geschafft! Ein Programm wird im Bootloaderbereich des Flashs ausgeführt! Es ''bootet'' zwar schon schön, aber es ''loadet'' noch nichts in den Flash. Aber die halbe Miete haben wir damit schon. Nun schreiben wir erst einmal eine kleine Anwendung, welche wir nach der Erweiterung unseres Bootloaders in den Flash-Speicher laden.

= Die Test-Anwendung =

[[Bild:Anwendung-AVRStudio.png|200px|thumb|Erstellen des Projektes]]
[[Bild:Anwendung-AVRStudio-Code.png|200px|thumb|Sourcecode im AVRStudio]]

Die Kategorie Anwendung möchte ich möglichst kurz halten. Ziel ist es, eine kleine Anwendung zu schreiben, welche dann mit dem (echten) Bootloader ins Flash gespeichert wird.

== Schritt 1 - Erstellen des Projektes ==

Nach dem Erstellen eines neuen Projektes muss in den Projekt-Einstellungen des AVR Studios nur die Taktfrequenz eingetragen werden. Die Linker-Optionen werden nicht verändert, also bleibt wie es ist.

== Schritt 2 - Einbinden der UART Library ==

Dieser Schritt kann vom Bootloader übernommen werden. Es wird wieder die UART-Bibliothek von Peter Fleury verwendet.

== Schritt 3 - Programmieren der Anwendung ==

Wir starten also ein neues AVR Studio und legen ein neues Projekt an, konfigurieren die Taktfrequenz (8 MHz) und laden die ''uart.c'' und ''uart.h'' dazu. Nun schreiben wir in die ''main.c'' folgende Zeilen:

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

#define UART_BAUD_RATE 9600

int main()
{
unsigned int c;
void (*bootloader)( void ) = 0x0C00; // Achtung Falle: Hier Word-Adresse

uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
sei();

uart_puts_P("\n\rHier ist das Anwendungsprogramm...");

for(;;)
{
c = uart_getc();
if(!(c & UART_NO_DATA))
{
switch( (unsigned char)c)
{
case 'b':
uart_puts("\n\rSpringe zum Bootloader...");
_delay_ms(1000);
bootloader();
break;
default:
uart_puts("\n\rDu hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
break;
}
}
}
return 0;
}

</c>
'''''Erklärung des Codes'''''

Viel interessantes ist nicht an diesem Code. Es gibt wie immer die berühmte Endlosschleife. Wir definieren wieder einen fiktiven Funktionspointer auf die Word-Adresse(Hier verhält sich der AVR-GCC leider etwas inkonsistent, da sonst bei Flash-Adressen mit Bytes gearbeitet wird. Gibt man hier versehentlich die Byteadresse an, kann es sein, dass der Sprung in den Bootloader klappt, es muss aber nicht funktionieren, da das Sprungziel undefiniert ist. Verwendet man stattdessen einen JMP befehl im Inline-Assembler, so ist die Byte-Adresse für das Sprungziel anzugeben) des Bootloaders<pre>void (*bootloader)( void ) = 0x0C00;</pre> Nach drücken der Taste '''b''' soll das Programm wieder zum Bootloader springen.

Nach dem Kompilieren des Programms sehen wir, dass der Programmspeicher mit 686 Byte belegt ist, der Datenspeicher mit 201 Bytes.

== Schritt 4 - Ausprobieren der Anwendung ==

Wer möchte kann die Anwendung auf den AVR flashen und ausprobieren. Die Funktion sollte sich von selbst erschließen.

'''Achtung:''' Es muss darauf geachtet werden, dass beim flashen der Anwendung nicht der Bootloader überschrieben wird. Bei Verwendung von avrdude muss dazu die Option "-D" angegeben werden.

Nun wollen wir uns der Erweiterung des Bootloaders widmen.

= Der "echte" Bootloader =
[[Bild:Real-Bootloader-AVRStudio.png|200px|thumb|Programmieren des Bootloaders]]

Zum Erstellen des Bootloaders wird wieder Schrittweise vorgegangen. Folgende Schritte sind zu befolgen:

== Schritt 1 und 2 - siehe "Hallo Welt" Bootloader ==
Schritt 1 und 2 können vom "Hallo Welt" Bootloader übernommen werden. Es sind wieder die korrekte Taktfrequenz und die Verschiebung der Sektion '''.text''' auf die Bootresetadresse einzustellen.

== Schritt 3 - Programmieren des Bootloaders ==

Nun soll der Bootloader erweitert werden. Nach dem Kompilieren des Anwendungsprogramms erhalten wir eine Datei ''Anwendung.hex'' im [http://de.wikipedia.org/wiki/Intel_HEX Intel-HEX-Format]. Da wir im Bootloader diese Daten auswerten müssen, wollen wir uns kurz mit dem Format beschäftigen. Das Intel-HEX-Format ist geschaffen worden, um Binärdaten als ASCII-Daten zu übertragen. Jedes Byte ist in Form von zwei ASCII-Zeichen gespeichert, d.h. aus der Zahl ''0x4A'' wird die ASCII-Zeichenfolge ''"4A"''. Das bedeutet aber auch, dass aus den Binärdaten die doppelte Anzahl von Zeichen wird, welche übertragen werden müssen, hinzu kommen noch Steuerzeichen und Zusatzinformationen. Jede Zeile in der Intel-HEX-Datei folgt einem bestimmten Schema, in dem u.a. die Anzahl der Bytes, die Zieladresse und Checksumme stehen.

Für weiterführende Erklärungen zum Thema HEX-Datei-Format empfehle ich folgende Lektüre:
* [http://en.wikipedia.org/wiki/Intel_HEX Wikipedia Artikel über HEX-Files]
* [http://www.rn-wissen.de/index.php/HEX-Datei RN-Wissen-Artikel über HEX-Files]
* [http://www.schulz-koengen.de/biblio/intelhex.htm Artikel von Wolfgang R.Schulz]

Unser Bootloader muss in der Lage sein, dieses Format zu interpretieren. Wir müssen also einen Parser schreiben. ''Oje'' werden manche denken, das ist ja wieder ein Thema für sich. Das stimmt prinzipiell auch. Allerdings kommt uns hier das einfache Format der Intel-Hex-Datei zugute, welches den Aufwand in Grenzen hält.

Also erstes brauchen wir also Funktionen, um die ASCII-Zeichenfolgen wieder in Binärdaten umzuwandeln. Normalerweise könnte man dafür die C-Funktion [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html#gaf8ce3b8dae3d45c34c3b172de503f7b3 strtol] aus der stdlib.h nehmen. Allerdings würde das Benutzen dieses Befehls das Linken der Standardbibliothek nach sich ziehen und damit den Code unnötig aufblähen. Daher werden wir uns eine einfache eigene Funktion schreiben, um die Zeichenfolgen umzuwandeln. In der HEX-Datei kommen 2 Byte und 4 Byte Hex-Zahlen im ASCII-Format vor. Wir brauchen also eine Funktion, welche die ASCII-Zeichenfolgen in Zahlen umwandelt, hier ist sie:
<c>
static uint16_t hex2num(const uint8_t * ascii, uint8_t num)
{
uint8_t i;
uint16_t val = 0;

for (i=0; i<num; i++)
{
uint8_t c = ascii[i];

/* Hex-Ziffer auf ihren Wert abbilden */
if (c >= '0' && c <= '9') c -= '0';
else if (c >= 'A' && c <= 'F') c -= 'A' - 10;
else if (c >= 'a' && c <= 'f') c -= 'a' - 10;

val = 16 * val + c;
}

return val;
}
</c>
Wir benutzen hier einen sehr einfachen Ansatz, um die Zahlen zu generieren. Die Funktionen wandeln die ASCII-Zeichen entsprechend ihrer Wertigkeit in Zahlen um. Soll z.B. das ASCII-Zeichen '1' umgewandelt werden, wird vom ASCII-Code '1', also dezimal 49, 48='0' abgezogen: 49 - 48 = 1, somit haben wir ein ASCII-Zeichen in eine Zahl umgewandelt. Wenn das ASCII-Zeichen 'C' ist (Dezimal: 67), werden 'A' - 10 = 65 -10 = 55 abgezogen, um 12 zu erhalten, den Wert der hex-Ziffer C. Näher möchte an dieser Stelle nicht darauf eingehen, wir wollen schnell weiter zum Beschreiben des Flashs kommen.

Um in den Flash zu schreiben, werden wir Makros aus der ''[http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html boot.h]'' der avr-libc verwenden. Hier findet man alle Werkzeuge, die wir brauchen. Dabei sollte vor allen das ''API Usage Example'' in der [http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html Online Doku] näher betrachtet werden. Dieses Beispiel soll weitestgehend übernommen werden, da es die nötige Funktionalität beinhaltet. Hier ist die Funktion:
<c>
void boot_program_page (uint32_t page, uint8_t *buf)
{
uint16_t i;
uint8_t sreg;

/* Disable interrupts.*/
sreg = SREG;
cli();

eeprom_busy_wait ();

boot_page_erase (page);
boot_spm_busy_wait (); /* Wait until the memory is erased. */

for (i=0; i<SPM_PAGESIZE; i+=2)
{
/* Set up little-endian word. */
uint16_t w = *buf++;
w += (*buf++) << 8;

boot_page_fill (page + i, w);
}
boot_page_write (page); /* Store buffer in flash page. */
boot_spm_busy_wait(); /* Wait until the memory is written.*/

/* Reenable RWW-section again. We need this if we want to jump back */
/* to the application after bootloading. */
boot_rww_enable ();

/* Re-enable interrupts (if they were ever enabled). */
SREG = sreg;
}
</c>
Als erstes fällt auf, dass man der Funktion die ''Page''-Adresse übergibt. Es wird also immer seitenweise geschrieben. Dies ist eine Spezialität des Flash-Speichers. Es '''muss''' immer die gesamte Seite geschrieben werden, dafür gibt es einen ''Page''-Puffer, welcher die Daten enthält, welche mit der nächsten Schreiboperation in die entsprechende Page geschrieben werden. Dabei werden die Daten Wortweise in den ''Page''-Puffer geschrieben. Die wesentlichen Funktionen der Routine sind ''boot_page_erase(page)'', ''boot_page_fill(page + i, w)'' und ''boot_page_write(page)''. Nicht zu vergessen auch ''boot_spm_busy_wait()''. Die Bedeutung der Funktionen (naja es sind eher Makros) findet man in der Dokumentation der AVR Libc. Im wesentlichen läuft das Schreiben einer ''Page'' so ab:
* ''Page'' löschen
* ''Page''-Puffer befüllen (aus der Variable ''buf'')
* ''Page'' schreiben
So einfach, so gut. Für den Bootloader bedeutet das, dass er die Daten sammeln muß, bis er genügend Daten für eine ''Page'' hat. Dann wird eine ''Page'' geschrieben und der Spaß fängt von vorn an.

Mit diesen beiden Funktionen sind wir nun in der Lage, den Parser zu schreiben. Die ''main.c'' sieht folgt aus:
<c>
#include <string.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/boot.h>
#include <util/delay.h>
#include "uart.h"

#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */
#define START_SIGN ':' /* Hex-Datei Zeilenstartzeichen */

/* Zustände des Bootloader-Programms */
#define BOOT_STATE_EXIT 0
#define BOOT_STATE_PARSER 1

/* Zustände des Hex-File-Parsers */
#define PARSER_STATE_START 0
#define PARSER_STATE_SIZE 1
#define PARSER_STATE_ADDRESS 2
#define PARSER_STATE_TYPE 3
#define PARSER_STATE_DATA 4
#define PARSER_STATE_CHECKSUM 5
#define PARSER_STATE_ERROR 6

void program_page (uint32_t page, uint8_t *buf)
{
uint16_t i;
uint8_t sreg;

/* Disable interrupts */
sreg = SREG;
cli();

eeprom_busy_wait ();

boot_page_erase (page);
boot_spm_busy_wait (); /* Wait until the memory is erased. */

for (i=0; i<SPM_PAGESIZE; i+=2)
{
/* Set up little-endian word. */
uint16_t w = *buf++;
w += (*buf++) << 8;

boot_page_fill (page + i, w);
}

boot_page_write (page); /* Store buffer in flash page. */
boot_spm_busy_wait(); /* Wait until the memory is written.*/

/* Reenable RWW-section again. We need this if we want to jump back */
/* to the application after bootloading. */
boot_rww_enable ();

/* Re-enable interrupts (if they were ever enabled). */
SREG = sreg;
}

static uint16_t hex2num (const uint8_t * ascii, uint8_t num)
{
uint8_t i;
uint16_t val = 0;

for (i=0; i<num; i++)
{
uint8_t c = ascii[i];

/* Hex-Ziffer auf ihren Wert abbilden */
if (c >= '0' && c <= '9') c -= '0';
else if (c >= 'A' && c <= 'F') c -= 'A' - 10;
else if (c >= 'a' && c <= 'f') c -= 'a' - 10;

val = 16 * val + c;
}

return val;
}

int main()
{
/* Empfangenes Zeichen + Statuscode */
uint16_t c = 0,
/* Intel-HEX Zieladresse */
hex_addr = 0,
/* Zu schreibende Flash-Page */
flash_page = 0,
/* Intel-HEX Checksumme zum Überprüfen des Daten */
hex_check = 0,
/* Positions zum Schreiben in der Datenpuffer */
flash_cnt = 0;
/* temporäre Variable */
uint8_t temp,
/* Flag zum steuern des Programmiermodus */
boot_state = BOOT_STATE_EXIT,
/* Empfangszustandssteuerung */
parser_state = PARSER_STATE_START,
/* Flag zum ermitteln einer neuen Flash-Page */
flash_page_flag = 1,
/* Datenpuffer für die Hexdaten*/
flash_data[SPM_PAGESIZE],
/* Position zum Schreiben in den HEX-Puffer */
hex_cnt = 0,
/* Puffer für die Umwandlung der ASCII in Binärdaten */
hex_buffer[5],
/* Intel-HEX Datenlänge */
hex_size = 0,
/* Zähler für die empfangenen HEX-Daten einer Zeile */
hex_data_cnt = 0,
/* Intel-HEX Recordtype */
hex_type = 0,
/* empfangene HEX-Checksumme */
hex_checksum=0;
/* Funktionspointer auf 0x0000 */
void (*start)( void ) = 0x0000;

/* Füllen der Puffer mit definierten Werten */
memset(hex_buffer, 0x00, sizeof(hex_buffer));
memset(flash_data, 0xFF, sizeof(flash_data));

/* Interrupt Vektoren verbiegen */
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);

/* Einstellen der Baudrate und aktivieren der Interrupts */
uart_init( UART_BAUD_SELECT(BOOT_UART_BAUD_RATE,F_CPU) );
sei();

uart_puts("Hallo hier ist der echte Bootloader\n\r");
_delay_ms(2000);

do
{
c = uart_getc();
if( !(c & UART_NO_DATA) )
{
/* Programmzustand: Parser */
if(boot_state == BOOT_STATE_PARSER)
{
switch(parser_state)
{
/* Warte auf Zeilen-Startzeichen */
case PARSER_STATE_START:
if((uint8_t)c == START_SIGN)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_SIZE;
hex_cnt = 0;
hex_check = 0;
uart_putc(XON);
}
break;
/* Parse Datengröße */
case PARSER_STATE_SIZE:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_ADDRESS;
hex_cnt = 0;
hex_size = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_size;
uart_putc(XON);
}
break;
/* Parse Zieladresse */
case PARSER_STATE_ADDRESS:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 4)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_TYPE;
hex_cnt = 0;
hex_addr = hex2num(hex_buffer, 4);
hex_check += (uint8_t) hex_addr;
hex_check += (uint8_t) (hex_addr >> 8);
if(flash_page_flag)
{
flash_page = hex_addr - hex_addr % SPM_PAGESIZE;
flash_page_flag = 0;
}
uart_putc(XON);
}
break;
/* Parse Zeilentyp */
case PARSER_STATE_TYPE:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
hex_cnt = 0;
hex_data_cnt = 0;
hex_type = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_type;
switch(hex_type)
{
case 0: parser_state = PARSER_STATE_DATA; break;
case 1: parser_state = PARSER_STATE_CHECKSUM; break;
default: parser_state = PARSER_STATE_DATA; break;
}
uart_putc(XON);
}
break;
/* Parse Flash-Daten */
case PARSER_STATE_DATA:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
uart_putc('.');
hex_cnt = 0;
flash_data[flash_cnt] = (uint8_t)hex2num(hex_buffer, 2);
hex_check += flash_data[flash_cnt];
flash_cnt++;
hex_data_cnt++;
if(hex_data_cnt == hex_size)
{
parser_state = PARSER_STATE_CHECKSUM;
hex_data_cnt=0;
hex_cnt = 0;
}
/* Puffer voll -> schreibe Page */
if(flash_cnt == SPM_PAGESIZE)
{
uart_puts("P\n\r");
_delay_ms(100);
program_page((uint16_t)flash_page, flash_data);
memset(flash_data, 0xFF, sizeof(flash_data));
flash_cnt = 0;
flash_page_flag = 1;
}
uart_putc(XON);
}
break;
/* Parse Checksumme */
case PARSER_STATE_CHECKSUM:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
hex_checksum = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_checksum;
hex_check &= 0x00FF;
/* Dateiende -> schreibe Restdaten */
if(hex_type == 1)
{
uart_puts("P\n\r");
_delay_ms(100);
program_page((uint16_t)flash_page, flash_data);
boot_state = BOOT_STATE_EXIT;
}
/* Überprüfe Checksumme -> muss '0' sein */
if(hex_check == 0) parser_state = PARSER_STATE_START;
else parser_state = PARSER_STATE_ERROR;
uart_putc(XON);
}
break;
/* Parserfehler (falsche Checksumme) */
case PARSER_STATE_ERROR:
uart_putc('#');
break;
default:
break;
}
}
/* Programmzustand: UART Kommunikation */
else if(boot_state != BOOT_STATE_PARSER)
{
switch((uint8_t)c)
{
case 'p':
boot_state = BOOT_STATE_PARSER;
uart_puts("Programmiere den Flash!\n\r");
uart_puts("Kopiere die Hex-Datei und füge sie"
" hier ein (rechte Maustaste)\n\r");
break;
case 'q':
boot_state = BOOT_STATE_EXIT;
uart_puts("Verlasse den Bootloader!\n\r");
break;
default:
uart_puts("Du hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
uart_puts("\n\r");
break;
}
}
}
}
while(boot_state!=BOOT_STATE_EXIT);

uart_puts("Reset AVR!\n\r");
_delay_ms(1000);

/* Interrupt Vektoren wieder gerade biegen */
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp & ~(1<<IVSEL);

/* Reset */
start();

return 0;
}

</c>
'''''Erklärung des Codes'''''

Der Bootloader wird als ''Zustandsmaschine'' programmiert. Die Variable ''boot_state'' beinhaltet den aktuelle Programmzustand. Für den Parser gibt es eine eigene Zustandsvariable ''parser_state'', welche die einzelne Zustände des Parsers hält. Mit jeder HEX-Datei-Zeile läuft der Parser einmal durch alle Zustände. Nach Abarbeiten des aktuellen Zustands und Auswertung der empfangenen Daten wird der nächste Zustand aktiviert usw. Für das Verarbeiten der Datei wird jedes Mal die Kommunikation angehalten und ein ''XOFF'' gesendet. Nach Abarbeitung der Daten gibt der Parser den seriellen Empfang wieder frei (''XON''). '''''Es ist also wichtig, dass in PuTTY die XON/XOFF-Flußkontrolle aktiviert wird!''''' Durch den interruptgesteuerten Empfang mit einem 32 Byte tiefen Empfangspuffer geht kein Byte verloren. Am Ende einer HEX-Datei-Zeile wird die Checksumme ausgewertet. Bei falscher Checksumme springt der Parser in den ''PARSER_STATE_ERROR'', aus dem er nicht mehr rauskommt. Somit wird kein weiteres Byte in den Flash geschrieben. Zusätzlich könnte man noch implementieren, dass der Flash wieder gelöscht wird, wenn falsche Daten empfangen wurden, damit kein unvollständiges Programm im Flash steht.
Einschränkend muss noch festgehalten werden, das der Bootloader in dieser Fassung einen Adressraum bis 64K unterstützt (HEX-Zeilentyp 1). Die erweiterten Adressräume (HEX-Zeilentyp 2 bis 5) werden noch nicht unterstützt. Für ATmega-Devices mit > 64K Flash muss der Bootloader noch erweitert werden.

Nach dem Kompilieren beträgt die Größe des Bootloaders 1796 Byte, wir sind also unterhalb der 2048 Byte die wir "verbraten" können. Der Datenspeicher wird mit 283 Byte belastet.

Die Funktion des Bootloaders sieht wie folgt aus: Nach dem Reset wartet der Bootloader 2 Sekunden auf Eingaben (''_delay_ms(2000);''). Falls keine Eingaben von der Konsole kommen, springt der Bootloader zur Anwendung. Damit ist gewährleiset, dass die Anwendung später automatisch startet, auch wenn wir keine Taste drücken. Wird ein ''p'' gedrückt, springt der Bootloader in den ''BOOT_STATE_PARSER'' und erwartet eine HEX-Datei auf der Konsole. Dies ist der Zeitpunkt, die HEX-Datei der Anwendung mit Copy & Paste in die Konsole zu schreiben. Zum Einfügen von Daten aus dem Zwischenspeicher in die Konsole wird bei PuTTY die rechte Maustaste verwendet.

'''''WICHTIGER HINWEIS: ''''' Es hat sich gezeigt, das die Flußkontrolle durch XON/XOFF nicht immer funktioniert, da es eine Software-Flußsteuerung ist und u.U. der (UART-Sende-)Interrupt zu spät (oder gar nicht) ausgeführt wird. Bei Problemen beim Übertragen des HEX-Files sollte man als erstes versuchen die Baudrate zu senken (oder die Taktrate des Controllers erhöhen) um dem Controller mehr Zeit zum Verarbeiten und schnellerem Reagieren auf Interrupts zu geben.

== Schritt 4 - Flashen und Ausprobieren des Bootloaders ==
Nach dem Flashen via AVRISPmkII startet der Bootloader in der Konsole. Da noch kein Anwendungsprogramm im Flash liegt, startet der Bootloader nach 2 Sekunden immer wieder neu. Nach Drücken der Taste ''p'' erwartet der Bootlader die HEX-Datei der Anwendung. Nach dem Einfügen der Datei in Konsole erscheint für jedes empfangene Byte ein Punkt ("."). Das Beschreiben einer Flash-''Page'' kenzeichnet ein ''P''. Nach dem erfolgreichen Flashen startet die Anwendung automatisch.

Nach erfolgreichem Flashen des Bootloaders via AVRISPmkII erscheint nach dem Reset folgendes Bild:

[[Bild:PuTTY-Real-Bootloader-start.png|PuTTY: Bootloader nach dem Reset]]

Drückt man die Taste '''p''', springt ist der Bootloader bereit zum Empfang der HEX-Datei:

[[Bild:PuTTY-Real-Bootloader-wait.png|PuTTY: Warten auf die HEX-Datei "Anwendung.hex"]]

Nach Kopieren & Einfügen der HEX-Datei der vorher kompilierten Anwendung, hier die Intel-HEX-Datei "Anwendung.hex":
<pre>
:100000002CC046C045C044C043C042C041C040C0EF
:100010003FC03EC03DC03CC03BC03AC039C038C004
:1000200037C036C064C08FC033C032C031C030C0AA
:100030002FC02EC048696572206973742064617393
:1000400020416E77656E64756E677370726F67724C
:10005000616D6D2E2E2E0D0A000011241FBECFEFF4
:10006000D4E0DEBFCDBF11E0A0E0B1E0EAE6F2E00F
:1000700002C005900D92A434B107D9F711E0A4E4B1
:10008000B1E001C01D92A938B107E1F702D0EBC081
:10009000B7CFEF92FF920F931F93CF93DF9383E33A
:1000A00090E07BD0789484E390E0D0D088ECE82E88
:1000B000F12C00E018E18BD0EC0190FDFCCF8236F2
:1000C00069F480E091E0B6D080E197E2F7013197E2
:1000D000F1F70197D9F7F8010995EDCF8CE191E09F
:1000E000A9D08C2F91D081E491E0A4D0E4CF1F92CD
:1000F0000F920FB60F9211242F938F939F93EF932C
:10010000FF939091C0002091C600E0918601EF5FBF
:10011000EF7180918701E81711F482E008C0892F00
:100120008871E0938601F0E0EC59FE4F20838093C4
:100130008801FF91EF919F918F912F910F900FBEAA
:100140000F901F9018951F920F920FB60F921124C7
:100150008F939F93EF93FF939091840180918501FA
:10016000981769F0E0918501EF5FEF71E0938501E9
:10017000F0E0EC5BFE4F80818093C60005C080916B
:10018000C1008F7D8093C100FF91EF919F918F916E
:100190000F900FBE0F901F9018959C011092840134
:1001A00010928501109286011092870197FF04C07A
:1001B00082E08093C0003F773093C5002093C40055
:1001C00088E98093C10086E08093C20008959091F1
:1001D000860180918701981719F420E031E012C060
:1001E000E0918701EF5FEF71E0938701F0E0EC5958
:1001F000FE4F308120918801922F80E0AC01430FA7
:10020000511D9A01C9010895282F909184019F5F83
:100210009F71809185019817E1F3E92FF0E0EC5B85
:10022000FE4F2083909384018091C100806280936F
:10023000C1000895CF93DF93EC0102C02196E4DF63
:1002400088818823D9F7DF91CF910895CF93DF93E9
:10025000EC0101C0D9DFFE01219684918823D1F7FA
:0A026000DF91CF910895F894FFCFCD
:10026A00537072696E6765207A756D20426F6F747C
:10027A006C6F616465722E2E2E0D0A00447520681B
:10028A0061737420666F6C67656E646573205A6566
:10029A00696368656E20676573656E6465743A2084
:0402AA00000A0D0039
:00000001FF
</pre>
erscheinen folgende Ausgaben in PuTTY:

[[Bild:PuTTY-Real-Bootloader-prog.png|PuTTY: Flashen der HEX-Datei "Anwendung.hex"]]

Nach erfolgreichem Flashen startet die Anwendung und meldet sich mit der Zeile
<pre>
Hier ist das Anwendungsprogramm...
</pre>
Jetzt können nach belieben Tasten gedrückt werden, was die Anwendung jedesmal quittiert:

[[Bild:PuTTY-Real-Bootloader-anwend.png|PuTTY: Ausprobieren der Anwendung]]

Nach Drücken der Taste '''b''' springt die Anwendung wieder zur Startadresse des Bootloaders, also zur Adresse ''0x1800'' im Flash-Speicher. Nun hat man wieder 2 Sekunden Zeit, um die Taste '''p''' zu drücken, sonst startet die Anwendung wieder:

[[Bild:PuTTY-Real-Bootloader-reset.png|PuTTY: Rücksprung zum Bootloader auf Adresse 0x1800]]

Damit ist das Tutorial abgeschlossen.

'''''Viel Spass beim Ausprobieren und Weiterentwickeln!'''''

= Zusammenfassung =

Wer den Artikel bis hier hin nachvollzogen hat, ist jetzt in der Lage einen Bootloader selbst zu schreiben. Dabei kann der Bootloader an jede in Frage kommende ATmega-Plattform angepaßt werden. Dazu muss
* die Linkereinstellung für das Verschieben der Sektion ''.text'' angepasst werden und ('''-Ttext = 0xXXXX''')
* evtl. der virtuelle Funktionspointer in der Anwendung geändert werden (falls ein Rücksprung zum Bootloader gewünscht ist '''void (*bootloader)(void) = 0xXXXX''').

Um dies zu erleichtern, habe ich hier die Sprungadressen für ausgewählte AVRs tabellarisch zusammengetragen. Dabei wurde immer die maximale Größe des Bootloader betrachtet, also '''BOOTSZ0=0''' und '''BOOTSZ1=0''':

{| border="1" class="wikitable"
|+ Größe und Startadresse der Bootloader Sektion für ausgewählte AVR-Devices
|-
! Device || Flash-Größe für Applikation || Flash-Größe des Bootloaders || Startadresse des Bootloaders (Byteadresse)
|-
| ATmega8/88 || 6144 Byte || 2048 Byte || 0x1800
|-
| ATmega16/164/168 || 14336 Byte || 2048 Byte || 0x3800
|-
| ATmega32/324/328 || 28672 Byte || 4096 Byte || 0x7000
|-
| ATmega64/644/640 || 57344 Byte || 8192 Byte || 0xE000
|-
| ATmega128/1284/1280/1281 || 122880 Byte || 8192 Byte || 0x1E000
|-
| ATmega2560/2561 || 253952 Byte || 8192 Byte || 0x3E000
|}

Damit kann jeder den Bootloader nach seinen Wünschen anpassen. Eine gängige Praxis ist auch, ein kleines PC-Programm zu schreiben, welches dem Bootloader die Flash-Daten gleich Binär übergibt. Das geht schneller und spart das aufwendige interpretieren der Daten (Parsen). Eine weitere Idee ist es, den Bootloader so anzupassen, das er sich wie ein STK500 an der seriellen Schnittstelle verhält. Dazu muss man die [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735 AP068] von Atmel umsetzen. Auch dies sollte nach dem Studium des Tutorial kein Problem mehr sein :)

[http://www.mikrocontroller.net/user/show/mario Nachricht an den Autor]

= FAQ =

== Wie kann man Bootloader und Anwendungsprogramm gemeinsam flashen? ==

Es ist in C ohne weiteres nicht möglich ein gemeinsames Hexfile aus Bootloader und Anwendungsprogramm zu kompilieren. Aber man kann das getrennt erstellte Hexfile des Bootloaders und das getrennt erstellte Hexfile des Anwendungsprogramms zusammenfügen und so gemeinsam mit ISP flashen. Dazu die letzte Zeile des 1. Hexfiles entfernen und dahinter das 2. Hexfile anfügen [http://www.mikrocontroller.net/topic/199241#1955092], [http://www.mikrocontroller.net/topic/198428#1949164].

[[Kategorie:AVR-Programmer und -Bootloader|B]]

AVR Bootloader in C - eine einfache Anleitung

2011-05-20T11:09:12Z

Sebion7125: /* Schritt 3 - Programmieren des Bootloaders */

Dieser Artikel soll dazu dienen, das Thema [[Bootloader]] im AVR etwas zu demystifizieren.

Es gibt schon einige Artikel und Codebeispiele für verschiedene Bootloader in Assembler oder C (bzw. gemischt), aber kein Artikel beleuchtet das Thema von einer einfachen Seite aus Anwendungssicht. In diese Lücke zielt dieses Tutorial.
Es soll anhand von Beispielen einen möglichst einfachen, verständlichen und nachvollziehbaren Weg zeigen, sich mit Hilfe der Hochsprache C in das Thema einzuarbeiten (dabei soll weder Assembler noch Inline-Assembler verwendet werden).

Vielleicht werden einige meinen dass es nicht möglich ist das Thema ohne tieferen Einblick in die Hardware und die AVR-Register zu beleuchten, ich möchte es aber trotzdem versuchen.

Der Artikel wird sich auf das notwendige Wissen beschränken, um mit Booloadern arbeiten zu können. Es wird ein genereller Weg gezeigt, der sich leicht auf andere AVR-Devices (mit Bootloader Sektion) übertragen lässt.
Die Codebeispiele wurden für den ATmega88 kompiliert und getestet.

== Einleitung ==

Zu Beginn soll das notwendige Wissen über die Bootloaderunterstützung im AVR vermittelt werden, um eine Arbeitsgrundlage zu schaffen.

Im weiteren Verlauf des Artikels werden insgesamt drei Anwendungen programmiert: Zuerst ein einfacher Bootloader, welcher in der Bootloadersektion des Flashs ausgeführt wird, aber noch keine eigentliche Bootloader-Funktion hat, sozusagen ein "Hallo Welt"-Bootloader. Danach soll eine kleine Applikation programmiert werden, welche der spätere ''echte'' Bootloader ins Flash programmieren soll. Als großes Finale soll dann ein Bootloader entstehen, welcher in der Lage ist, Intel-HEX-Dateien über die serielle Schnittstelle zu laden, ins Flash zu programmieren und zu starten.

Der Leser sollte bereits Erfahrungen im Umgang mit dem AVR Studio und der Programmiersprache C gemacht haben und schon Anwendungen geschrieben haben. Für absolute Einsteiger ist der Artikel ungeeignet.

Den Thread zum Artikel gibt es hier: http://www.mikrocontroller.net/topic/195102

== Software ==

Für den Artikel werden folgende Software-Pakete benötigt:

* aktuelles [http://http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] (hier verwendet: AVR Studio v4.18)
* aktuelles [http://sourceforge.net/projects/winavr/files/ WinAVR] (hier verwendet: WinAVR20100110)
* [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY] als serielle Konsole (Version v0.6)

Des weiteren wurde auf der AVR-Seite für die serielle Kommunikation mit dem PC auf die beliebte UART-Library von [http://www.jump.to/fleury Peter Fleury] zurückgegriffen, damit wir uns nicht um die gepufferte UART-Kommunikation kümmern müssen.

== Hardware ==

Für den Artikel wurde eine kleine Hardware bestehend aus einem [http://www.atmel.com/dyn/products/product_card.asp?part_id=3302 Atmega88] und einem [http://www.ftdichip.com/Products/ICs/FT232R.htm FT232] als USB-Seriell-Wandler erstellt. Dies soll als Basis für die Experimente dienen. Der USB-Seriell-Wandler ist nicht zwingend notwendig und kann auch durch den üblichen Pegelwandler vom Typ [http://www.maxim-ic.com/datasheet/index.mvp/id/1798/ln/en MAX232] ersetzt werden, wenn der PC noch eine serielle Schnittstelle besitzt. Entscheidend ist nur die Möglichkeit der seriellen Kommunikation mit dem Rechner.

[[Bild:Schaltplan-ATmega88-USB.png|800px|Schaltplan]]

Für die ISP-Programmierung wurde der [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3808 AVRISPmkII-In-System-Programmer] von Atmel verwendet. Es kann natürlich auch ein anderer Programmer (z.B. [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735 STK500]) verwendet werden, welcher mit dem AVR Studio zusammenarbeitet. Prinzipiell kann natürlich auch ein selbstgebastelter Parallel-Programmer verwendet werden, dann kann aber nicht via AVR Studio programmiert werden, sondern mit [http://www.nongnu.org/avrdude/ AVRDude] oder [http://www.lancos.com/prog.html PonyProg] o.ä. Der Artikel beschränkt sich auf die Verwendung vom AVR Studio.

Für das Verständis der Hardware und der seriellen Kommunikation sind folgende Artikel empfehlenswert:

* [[AVR-Tutorial: UART]]
* [[RS-232]]

= Grundlagen =

[[Bild:AVR-Memory.png|400px|thumb|Flash Speicher Aufteilung]]

Was ist eigentlich ein Bootloader und was macht er? Wofür sollte ich so etwas brauchen? Ist das nicht viel zu kompliziert? Ich bin eingefleischter AVR Studio-Benutzer, muss ich mich jetzt mit makefiles beschäftigen? Kann man im AVR Studio mit C überhaupt einen Bootloader schreiben? Vielleicht hat sich der eine oder andere schon einmal diese oder ähnliche Fragen gestellt.

Der Programmcode des AVR steht in seinem Flashspeicher und wird von dort ausgeführt. Normalerweise kann während der Ausführung des Programms nicht auf den Flashspreicher geschrieben werden. Dies ist auch einleuchtend da sich das Programm ja sonst selbst überschreiben oder löschen könnte. Das Beschreiben des Flashs erfolgt beim AVR üblicherweise über die ISP-Schnittstelle, dabei befindet sich der Controller im Reset und es wird kein Programm ausgeführt. Dies ist für Prototyping und kleine Anwendungen hinnehmbar. Ist der Controller allerdings in einem größeren System oder in größerer räumlicher Entfernung verbaut und die ISP-Schnittstelle nicht mehr zugänglich, ist ein Update der Firmware nicht mehr ohne Weiteres möglich oder sehr teuer und aufwendig. Hier kann ein Bootloader Abhilfe schaffen, in dem er das Anwendungsprogramm auf einer definierten Schnittstelle entgegennimmt (UART, I2C, Wireless) und ins Flash transferiert. Ein Bootloader ist also in erster Linie ein kleines Programm, welches in einem besonderem Teil des Flash steht - der '''Boot Loader Section'''. Durch die Lokalisierung des Bootloader-Programms in dieser besonderen Sektion des AVR ist es dem Programm möglich, auf Teile des Flashs - der sogenannten '''Application Flash Section''' - zu schreiben. Die eigentliche Anwendung wird ausschließlich in der '''Application Flash Section''' ausgeführt. Wenn man so will, können im Flash des AVR also zwei unabhängige Programme stehen. Der Flash ist in zwei Bereiche mit unterschiedlichen Merkmalen aufgeteilt (siehe Bild). Auf die RWW bzw. NRWW-Sektion möchte ich an dieser Stelle (noch) nicht eingehen.

Wie man unschwer erkennen kann, liegt der Bootloader-Bereich am Ende des Flash-Speichers. Normalerweise startet der Controller die Abarbeitung seiner Programmierung an der Stelle 0x0000. Ein Bootloader soll ja aber '''vor''' der Abarbeitung der eigentlichen Applikation ausgeführt werden. Woher weiß also der AVR-Controller nach dem Reset, dass er nicht von Adresse 0x0000 sondern einer anderen Adresse starten soll? Diese Konfiguration ist wie alle wichtigen und grundlegenden Konfigurationen über die Fuses des AVRs geregelt. Wir beginnen mit der folgende Tabelle, welche die Speicheraufteilung des Programmspeichers veranschaulicht.

{| border="1" class="wikitable"
|+ Boot Size Konfiguration, Tabelle 26-6 im Atmega88-Datenblatt S.280
|-
! BOOTSZ1 || BOOTSZ0 || Boot Size || Pages || Application Flash Section || Boot Loader Flash Section || End Application Section || Boot Reset (Start Boot Loader Section)
|-
| 1 || 1 || 128 words || 4 || 0x000 - 0xF7F || 0xF80 - 0xFFF || 0xF7F || 0xF80
|-
| 1 || 0 || 256 words || 8 || 0x000 - 0xEFF || 0xF00 - 0xFFF || 0xEFF || 0xF00
|-
| 0 || 1 || 512 words || 16 || 0x000 - 0xDFF || 0xE00 - 0xFFF || 0xDFF || 0xE00
|-
| 0 || 0 || 1024 words || 32 || 0x000 - 0xBFF || 0xC00 - 0xFFF || 0xBFF || 0xC00
|}

Um die Tabelle zu verstehen muss man wissen, dass der Flash-Speicher intern in sogenannten ''Pages'' (Seiten) organisiert ist. Die Multiplikation der ''Page''-Größe mit der Anzahl der ''Pages'' ergibt die Speichergröße. Die Größe einer ''Page'' steht im Datenblatt und ist in ''Words'' - also Datenworte - angegeben. Ein Datenwort entspricht zwei Bytes. '''''Hier offenbart sich eine Tücke des Datenblatts: Alle Speicherbezüge und Adressen sind in Datenworten (also immer 2 Bytes) angegeben!'''''
Aus der Tabelle erfahren wir auch, dass man mit den beiden Fuses '''BOOTSZ0''' und '''BOOTSZ1''' die Größe des Bootloaderbereichs einstellen kann. Eine weitere Tabelle aus dem Atmega88-Datenblatt gibt Auskunft über die Aufteilung der Pages und die Anzahl der Datenworte einer Page.

{| border="1" class="wikitable"
|+ No.of Words in a Page and No.of Pages in Flash, Tabelle 27-9 im Atmega88-Datenblatt S.288
|-
! Device || Flash Size || Page Size || PCWORD || No. of Pages || PCPAGE || PCMSB
|-
| Atmega88 || 4K words (8 Kbytes) || 32 words || PC[4:0] || 128 || PC[11:5] || 11
|}

Aus der Tabelle ergibt sich, dass die Größe einer ''Page'' des verwendeten Atmega88 32 ''Words'' - also 64 Byte sind. Insgesamt gibt es 128 ''Pages'', damit ergibt sich nach Adam Riese 128 * 64 = 8192 Byte, also 8 Kbytes. In unserem späteren Codebeispiel soll die Größe des Bootloaderbereichs auf 1024 ''words'' - also 2048 Bytes gestellt werden ('''BOOTSZ0=0''' und '''BOOTSZ1=0'''). Nun können wir ausrechnen, in welcher Flash-''Page'' bzw. an welcher Flash-Adresse der Bootloaderbereich beginnt: Er beginnt in der 96 ''Page'' (128 - 32) an ''Word''-Adresse 0xC00, also Byteadresse 0xC00 * 2 = 0x1800. Dies ist die exakte Startadresse unseres Bootloaderbereiches.

Weiter oben wurde die Frage gestellt, woher der AVR weiß, an welcher Stelle (entweder 0x0000 oder in unserem Fall 0x1800) er nach dem Reset starten soll. Um dem AVR dies mitzuteilen, ist eine weitere Fuse nötig - die '''BOOTRST'''-Fuse. Eine weitere Tabelle aus dem Atmega88-Datenblatt gibt Auskunft über diese Fuse.

{| border="1" class="wikitable"
|+ Reset and Interrupt Vectors Placement in Atmega88, Tabelle 11-3 im Atmega88-Datenblatt S.58
|-
! BOOTRST|| IVSEL || Reset Adress || Interrupt Vectors Start Adress
|-
| 1 || 0 || 0x000 || 0x001
|-
| 1 || 1 || 0x000 || Boot Reset Address + 0x001
|-
| 0 || 0 || Boot Reset Address || 0x001
|-
| 0 || 1 || Boot Reset Address || Boot Reset Address + 0x001
|}

Mit der '''BOOTRST'''-Fuse wird festgelegt, dass der AVR nach dem Reset an die Startadresse der Bootloader Sektion im Flash springt. Auf das '''IVSEL'''-Bit (keine Fuse) möchte ich erst an späterer Stelle - wenn es um Interrupts geht - zurückkommen.

'''Noch ein wichtiger Hinweis für die Werte der Fuses im Datenblatt:''' '''''Der Wert "0" bedeutet, dass die Fuse programmiert ist, es entspicht dem Häkchen im AVR Studio!'''''

= Der "Hallo Welt" - Bootloader =

Wie oben erwähnt, wird für die Erstellung des Codes die kostenlose IDE von Atmel - das AVRStudio - benutzt. Ergänzt wird es durch C-Compiler und Tools des WinAVR Projektes. Des weiteren wird zur seriellen Kommunikation das Terminalprogramm benötigt. Im Tutorial wird PuTTY verwendet und sollte installiert sein. Die Hardware ist aufgebaut und via AVRISPmkII-Programmer an den PC angeschlossen - nun kann es losgehen!

Zu Beginn wird ein neues AVRStudio-Projekt erstellt. Danach werden folgende Schritte abgearbeitet:

== Schritt 1 - Konfiguration der Projekteinstellungen ==
[[Bild:Bootloader-Projekt.png|200px|thumb|Erstellen des Projekts]]
[[Bild:Bootloader-Config-General.PNG|200px|thumb|Generelle Optionen - setzten der Taktfrequenz]]
[[Bild:Bootloader-Config-Linker.png|200px|thumb|Linker Option eingeben]]

Als erstes öffnen wir die Projekteinstellungen (Menü ''Project/Configuration Options'') und tragen die richtige Taktfrequenz ein (Im Beispiel nutzen wir den internen Oszillator mit 8 Mhz). Danach gehen wir zum Reiter '''Custom Options'''. Dort klicken wir auf '''Linker Options''' und geben dann im Textfeld daneben '''-Ttext=0x1800''' ein. Danach drücken wir auf '''Add'''.

Was bewirkt dieser Linker-Parameter? Dafür muß wieder etwas weiter ausgeholt werden. Nach dem Kompilieren der Programmquellen ''linkt'' der Linker den Programmcode an bestimmte Stellen in den drei verschiedenen Speichern Flash, EEPROM und SRAM des AVR. In der vom Compiler verwendeten [http://www.nongnu.org/avr-libc/user-manual/mem__sections.html AVR Libc] ist der Speicher in verschiedene Sektionen aufgeteilt. Dem Linker muss mitgeteilt werden, in welche Speicher er den Programmcode linken soll. Die Lokalisierung des Speichers sind die Sektionen. Die Sektion ''.text'' ist dem ausführbaren Programmcode - also den Befehlen - vorbehalten und liegt im Flash des AVR, des weiteren gibt es auch noch die Sektionen ''.data'' und ''.bss'' für die statischen und dynamischen Variablen im SRAM und eine Sektion ''.eeprom'' für den EEPROM und noch ein paar spezielle (Flash-)Sektionen.

Nun gibt es verschiedene Methoden, dem Linker mitzuteilen, dass man den Programmcode an die Stelle des Bootloaderbereichs haben möchte. Eine sehr einfache Methode ist '''die Verschiebung der Sektion ''' '''''.text''''', welche normalerweise ab Adresse 0x0000 beginnt. Eben dies geschieht mit dem Linker Parameter '''-Ttext=0x1800'''. Die Adresse des Beginns der ''.text'' Sektion wird auf die (Byte-)Adresse 0x1800 gesetzt.

== Schritt 2 - Einbinden der UART Library von Peter Fleury ==

Wie bereits erwähnt, wird für die serielle Kommunikation auf der AVR-Seite die UART-Library von [http://www.jump.to/fleury Peter Fleury] verwendet. Nach dem Download werden die uart.c und uart.h in das Projekt eingebunden (für die uart.c im AVR Studio rechte Maustaste auf ''Source Files'' und dann ''Add Existing Source File(s)...'' und für die uart.h die rechte Maustaste auf ''Header Files'' und dann ''Add Existing Header File(s)...'')

== Schritt 3 - Programmieren des Bootloaders ==

[[Bild:Bootloader-Config-Linker-ok.PNG|200px|thumb|Linker Option nach Add]]
[[Bild:Bootloader-AVRStudio.PNG|200px|thumb|Kompilieren des Bootloaders]]

Nun soll eine kleine Applikation geschrieben werden. Keine Angst, unser erstes Ziel ist es, eine kleine Anwendung in dem Bootloaderbereich zu positionieren, welche serielle Ein-und Ausgaben behandelt. Die eigentliche Bootloaderfunktionalität kommt später dazu. Also schreiben wir die Datei ''main.c'' wie folgt:

<c>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/boot.h>
#include <util/delay.h>
#include "uart.h"

#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */

int main()
{
unsigned int c=0; /* Empfangenes Zeichen + Statuscode */
unsigned char temp, /* Variable */
flag=1, /* Flag zum steuern der Endlosschleife */
p_mode=0; /* Flag zum steuern des Programmiermodus */
void (*start)( void ) = 0x0000; /* Funktionspointer auf 0x0000 */

/* Interrupt Vektoren verbiegen */

char sregtemp = SREG;
cli();
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);
SREG = sregtemp;

/* Einstellen der Baudrate und aktivieren der Interrupts */
uart_init( UART_BAUD_SELECT(BOOT_UART_BAUD_RATE,F_CPU) );
sei();

uart_puts("Hallo hier ist der Bootloader\n\r");
_delay_ms(1000);

do
{
c = uart_getc();
if( !(c & UART_NO_DATA) )
{
switch((unsigned char)c)
{
case 'q':
flag=0;
uart_puts("Verlasse den Bootloader!\n\r");
break;
default:
uart_puts("Du hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
uart_puts("\n\r");
break;
}
}
}
while(flag);

uart_puts("Springe zur Adresse 0x0000!\n\r");
_delay_ms(1000);

/* vor Rücksprung eventuell benutzte Hardware deaktivieren
und Interrupts global deaktivieren, da kein "echter" Reset erfolgt */

/* Interrupt Vektoren wieder gerade biegen */
cli();
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp & ~(1<<IVSEL);

/* Rücksprung zur Adresse 0x0000 */
start();
return 0;
}
</c>

'''''Erklärung des Codes'''''

Beginnen wir mit den Defines: Die Baudrate erklärt sich von selbst. Die Defines XON und XOFF werden später, wenn die Bootloader-Funktionalität dazukommt, zur Flusssteuerung gebraucht. Wir werden also die XON/XOFF-Flussteuerung nutzen (merken für die Einstellung von PuTTY).

Bei den Variablen ist nur eine interessant: Der Funktionspointer <pre>void (*start)( void ) = 0x0000;</pre> ist ein einfacher Trick, um mit dem Programmcounter (PC) zur Adresse 0x0000 zu springen. Wir definieren einfach eine (fiktive) Funktion an der Stelle 0x0000. Beim Aufruf der Funktion mit <pre>start();</pre> springt der Programmcounter und damit das Programm an Adresse 0x0000 und das Anwendungsprogramm - wenn es eins gibt - kann starten.

Nun folgt ein sehr wichtiger Teil, auf den ich noch eingehen muss - die Interrupt-Vektoren. Interrupt-Vektoren sind Einsprungpunkte der Interrupts, welche normalerweise fest ab Adresse 0x0001 im Flash liegen. Wird ein Interrupt ausgelöst, springt der AVR automatisch zu der festen Flash-Adresse. Von dort aus - wenn eine ISR programmiert ist - springt der Controller zur ISR ('''I'''nterrupt '''S'''ervice '''R'''outine). Nun haben wir folgendes Problem: Wenn wir den Bootloadercode ab der Adresse 0x1800 ausführen, nützt es uns gar nichts, wenn der AVR nach Auslösen eines Interrupts an die Stelle 0x0001 + X springt, da dieser Speicherbereich ja im Zweifelsfalle sogar von uns überschrieben wird. Unser Code soll nur ab Adresse 0x1800 stehen! Wir müssen also die Sprungtabelle "verbiegen", d.h. den AVR veranlassen, bei Auslösung eines Interrupts an Adresse 0x1801 + X zu springen und dann zur ISR. Das Verbiegen der Sprungtabelle passiert mit dem Setzen des '''IVSEL'''-Bits im '''MCUCR''' (ACHTUNG: beim Atmega8 '''GICR'''), also

beim Atmega88:
<pre>
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);
</pre>

bzw. beim Atmega8:
<pre>
temp = GICR;
GICR = temp | (1<<IVCE);
GICR = temp | (1<<IVSEL);
</pre>

Das '''IVCE'''-Bit wird nur benötigt, um dem Mikrocontroller zu sagen, dass wir als nächstes den Parameter '''IVSEL''' setzen wollen, das Bit wird nachher vom Controller wieder gelöscht. Um versehentliches verstellen der Interrupttabelle zu vermeiden muss das setzen von '''IVCE''' und '''IVSEL''' innerhalb von 4 Taktzyklen erfolgen. Um dies zu gewährleisten müssen alle interrupts während des Setzens deaktiviert sein. ACHTUNG Stolperfalle: Die Variable temp wird benötigt, da beim Setzen von '''IVSEL''' gleichzeitig '''IVCE''' gelöscht werden muss:

bei Atmega8/16:
<pre>
GICR |= (1<<IVCE); // noch richtig. IVCE wird gesetzt
GICR |= (1<<IVSEL); // falsch! IVSEL wird zwar gesetzt,
IVCE bleibt jedoch in diesem Prozessortakt gesetzt.
</pre>

In der Hauptschleife wird lediglich gepollt, ob ein neues Zeichen von der Konsole kommt. Nach dem Empfang eines Zeichens wird es ausgewertet (switch). Nach dem Drücken von ''"q"'' verlässt der Bootloader die Hauptschleife, setzt die Interrupt-Vektoren wieder zurück und startet die Hauptanwendung - wenn eine da ist.

Nach dem Kompilieren sagt uns der Linker, dass 754 Byte Programmspeicher und 265 Byte Datenspeicher verbraucht wurde. 754 Byte ist weit unter den 2048 Byte, welche uns ab der Adresse 0x1800 zur Verfügung stehen, wir haben also alles richtig gemacht.

Nun kontrollieren wir noch schnell, ob das Programm an der richtigen Stelle im Flash steht. Mit dem Hex-File (Bootloader.hex) wird auch ein List-File (Bootloader.lss) erzeugt. Im List-File findet sich das disassemblierte Programm und die Speicherzuordnungen. Hier ein Auszug der Datei:

<pre>
Bootloader.elf: file format elf32-avr

Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000080 00800100 00001a68 000002fc 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 00000268 00001800 00001800 00000094 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 00000085 00800180 00800180 0000037c 2**0
ALLOC
3 .debug_aranges 00000040 00000000 00000000 0000037c 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_pubnames 00000095 00000000 00000000 000003bc 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_info 00000459 00000000 00000000 00000451 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_abbrev 00000238 00000000 00000000 000008aa 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_line 000003eb 00000000 00000000 00000ae2 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_frame 000000a0 00000000 00000000 00000ed0 2**2
CONTENTS, READONLY, DEBUGGING
9 .debug_str 000001cf 00000000 00000000 00000f70 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_loc 0000024a 00000000 00000000 0000113f 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_ranges 00000048 00000000 00000000 00001389 2**0
CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00001800 <__vectors>:
1800: 19 c0 rjmp .+50 ; 0x1834 <__ctors_end>
1802: 33 c0 rjmp .+102 ; 0x186a <__bad_interrupt>
1804: 32 c0 rjmp .+100 ; 0x186a <__bad_interrupt>
1806: 31 c0 rjmp .+98 ; 0x186a <__bad_interrupt>
1808: 30 c0 rjmp .+96 ; 0x186a <__bad_interrupt>
180a: 2f c0 rjmp .+94 ; 0x186a <__bad_interrupt>
180c: 2e c0 rjmp .+92 ; 0x186a

...
(viele Zeilen)
...

0000186c <main>:
#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */

int main()
{
186c: cf 93 push r28
186e: df 93 push r29
unsigned char temp, /* Variable */
flag=1; /* Flag zum steuern der Endlosschleife */
void (*start)( void ) = 0x0000; /* Funktionspointer auf 0x0000 */

/* Interrupt Vektoren verbiegen */
temp = MCUCR;
1870: 85 b7 in r24, 0x35 ; 53
MCUCR = temp | (1<<IVCE);
1872: 98 2f mov r25, r24
1874: 91 60 ori r25, 0x01 ; 1
1876: 95 bf out 0x35, r25 ; 53
MCUCR = temp | (1<<IVSEL);
1878: 82 60 ori r24, 0x02 ; 2
187a: 85 bf out 0x35, r24 ; 53

...
(noch mehr Zeilen)
</pre>

Wir erkennen, dass die Sektion ''.text'' ab der Adresse (VMA) 0x1800 beginnt. Weiter sehen wir im Disassembly der Sektion ''.text'', dass unser Programm mit der Interrupt-Einsprungstabelle ab Adresse 0x1800 beginnt. Unsere ''main()'' beginnt ab Adresse 0x186C. Super. Das hat geklappt. Aber nun schnell zu Schritt 4 - dem Flashen und Ausprobieren des Programms...

== Schritt 4 - Flashen und Ausprobieren des Bootloaders ==

[[Bild:Bootloader-AVRStudio-Fuses.png|200px|thumb|Setzen der Fuses]]
[[Bild:PuTTY-Serconfig.png|200px|thumb|Serielle Konfiguration von PuTTY]]
[[Bild:PuTTY-Serconfig-xon.png|200px|thumb|Serielle Konfiguration von PuTTY]]

Nach dem Start des AVRISPmkII-In-System-Programmers aus dem AVRStudio werden zunächst die Einstellungen geprüft. Die Signatur des AVRs muss stimmen und die ISP-Frequenz. Im Reiter Program muss unter ''Flash'' die richtige Datei angegeben sein (''Bootloader.hex''). Danach können wir uns an das setzen der Fuses machen. '''CKDIV8''' sollte ausgeschalten werden, der interne Takt von 8 Mhz sollte genutzt werden ('''SUT_CKSEL''') und ''BOOTSZ'' auf 1024 words gestellt werden. Zusätzlich muß die '''BOOTRST'''-Fuse gesetzt werden, damit der Bootloader an der richtigen Adresse anfängt. Für alle, die einen anderen Programmer benutzen (z.B. avrdude), hier die exakten Werte der Fuses:
* Low Fuse: '''0xE2'''
* High Fuse: '''0xD2'''
* Extended Fuse: '''0xF8'''

Jetzt kann PuTTY gestartet und konfiguriert werden. Der ''Connection type'' muss auf '''Serial''' gestellt werden. Die Baudrate beträgt 9600 Baud. Unter ''Connection/Serial'' muss der ''Flow control'' auf '''XON/XOFF''' gestellt werden. Nach dem Konfigurieren kann die Konsole mit ''Open'' geöffnet werden.

Jetzt kann wieder in das AVR Studio gewechselt werden. Mit einem beherztem Druck auf ''Program'' wird das Flash im ATmega88 programmiert. Nach dem Wechsel auf die Konsole erscheint folgendes Bild:

[[Bild:PuTTY-Bootloader-start.png|600px|Bootloader in PuTTY]]

Nach dem Drücken von ein paar Tasten erscheint folgendes:

[[Bild:PuTTY-Bootloader-taste.png|600px|Bootloader nach Tastendruck in PuTTY]]

Nach dem Drücken von '''q''' erscheint folgendes Bild:

[[Bild:PuTTY-Bootloader-restart.png|600px|Bootloader nach Tastendruck in PuTTY]]

Der Bootloader versucht, zur Adresse 0x0000 zu springen, wo er allerdings keinen Programmcode findet. Wie auch? Wir haben ja den ganzen Flash des AVR gerade gelöscht und mit dem Bootloader gefüllt. Nun muss man wissen, dass in einem gelöschten Flash ''0xFF'' in jeder Speicherzelle steht. ''0xFF'' ist für den AVR kein gültiger Opcode. Der Programmzähler zählt nur um eins nach oben. Damit hopst er sozusagen durch den gesamten Flash bis er wieder beim Bootloader landet.

'''''[http://de.wikipedia.org/wiki/Heureka Heureka]''''' wir haben es geschafft! Ein Programm wird im Bootloaderbereich des Flashs ausgeführt! Es ''bootet'' zwar schon schön, aber es ''loadet'' noch nichts in den Flash. Aber die halbe Miete haben wir damit schon. Nun schreiben wir erst einmal eine kleine Anwendung, welche wir nach der Erweiterung unseres Bootloaders in den Flash-Speicher laden.

= Die Test-Anwendung =

[[Bild:Anwendung-AVRStudio.png|200px|thumb|Erstellen des Projektes]]
[[Bild:Anwendung-AVRStudio-Code.png|200px|thumb|Sourcecode im AVRStudio]]

Die Kategorie Anwendung möchte ich möglichst kurz halten. Ziel ist es, eine kleine Anwendung zu schreiben, welche dann mit dem (echten) Bootloader ins Flash gespeichert wird.

== Schritt 1 - Erstellen des Projektes ==

Nach dem Erstellen eines neuen Projektes muss in den Projekt-Einstellungen des AVR Studios nur die Taktfrequenz eingetragen werden. Die Linker-Optionen werden nicht verändert, also bleibt wie es ist.

== Schritt 2 - Einbinden der UART Library ==

Dieser Schritt kann vom Bootloader übernommen werden. Es wird wieder die UART-Bibliothek von Peter Fleury verwendet.

== Schritt 3 - Programmieren der Anwendung ==

Wir starten also ein neues AVR Studio und legen ein neues Projekt an, konfigurieren die Taktfrequenz (8 MHz) und laden die ''uart.c'' und ''uart.h'' dazu. Nun schreiben wir in die ''main.c'' folgende Zeilen:

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

#define UART_BAUD_RATE 9600

int main()
{
unsigned int c;
void (*bootloader)( void ) = 0x1800;

uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
sei();

uart_puts_P("\n\rHier ist das Anwendungsprogramm...");

for(;;)
{
c = uart_getc();
if(!(c & UART_NO_DATA))
{
switch( (unsigned char)c)
{
case 'b':
uart_puts("\n\rSpringe zum Bootloader...");
_delay_ms(1000);
bootloader();
break;
default:
uart_puts("\n\rDu hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
break;
}
}
}
return 0;
}

</c>
'''''Erklärung des Codes'''''

Viel interessantes ist nicht an diesem Code. Es gibt wie immer die berühmte Endlosschleife. Wir definieren wieder einen fiktiven Funktionspointer<pre>void (*bootloader)( void ) = 0x1800;</pre> Nach drücken der Taste '''b''' soll das Programm wieder zum Bootloader springen.

Nach dem Kompilieren des Programms sehen wir, dass der Programmspeicher mit 686 Byte belegt ist, der Datenspeicher mit 201 Bytes.

== Schritt 4 - Ausprobieren der Anwendung ==

Wer möchte kann die Anwendung auf den AVR flashen und ausprobieren. Die Funktion sollte sich von selbst erschließen. Nun wollen wir uns der
Erweiterung des Bootloaders widmen.

= Der "echte" Bootloader =
[[Bild:Real-Bootloader-AVRStudio.png|200px|thumb|Programmieren des Bootloaders]]

Zum Erstellen des Bootloaders wird wieder Schrittweise vorgegangen. Folgende Schritte sind zu befolgen:

== Schritt 1 und 2 - siehe "Hallo Welt" Bootloader ==
Schritt 1 und 2 können vom "Hallo Welt" Bootloader übernommen werden. Es sind wieder die korrekte Taktfrequenz und die Verschiebung der Sektion '''.text''' auf die Bootresetadresse einzustellen.

== Schritt 3 - Programmieren des Bootloaders ==

Nun soll der Bootloader erweitert werden. Nach dem Kompilieren des Anwendungsprogramms erhalten wir eine Datei ''Anwendung.hex'' im [http://de.wikipedia.org/wiki/Intel_HEX Intel-HEX-Format]. Da wir im Bootloader diese Daten auswerten müssen, wollen wir uns kurz mit dem Format beschäftigen. Das Intel-HEX-Format ist geschaffen worden, um Binärdaten als ASCII-Daten zu übertragen. Jedes Byte ist in Form von zwei ASCII-Zeichen gespeichert, d.h. aus der Zahl ''0x4A'' wird die ASCII-Zeichenfolge ''"4A"''. Das bedeutet aber auch, dass aus den Binärdaten die doppelte Anzahl von Zeichen wird, welche übertragen werden müssen, hinzu kommen noch Steuerzeichen und Zusatzinformationen. Jede Zeile in der Intel-HEX-Datei folgt einem bestimmten Schema, in dem u.a. die Anzahl der Bytes, die Zieladresse und Checksumme stehen.

Für weiterführende Erklärungen zum Thema HEX-Datei-Format empfehle ich folgende Lektüre:
* [http://en.wikipedia.org/wiki/Intel_HEX Wikipedia Artikel über HEX-Files]
* [http://www.rn-wissen.de/index.php/HEX-Datei RN-Wissen-Artikel über HEX-Files]
* [http://www.schulz-koengen.de/biblio/intelhex.htm Artikel von Wolfgang R.Schulz]

Unser Bootloader muss in der Lage sein, dieses Format zu interpretieren. Wir müssen also einen Parser schreiben. ''Oje'' werden manche denken, das ist ja wieder ein Thema für sich. Das stimmt prinzipiell auch. Allerdings kommt uns hier das einfache Format der Intel-Hex-Datei zugute, welches den Aufwand in Grenzen hält.

Also erstes brauchen wir also Funktionen, um die ASCII-Zeichenfolgen wieder in Binärdaten umzuwandeln. Normalerweise könnte man dafür die C-Funktion [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html#gaf8ce3b8dae3d45c34c3b172de503f7b3 strtol] aus der stdlib.h nehmen. Allerdings würde das Benutzen dieses Befehls das Linken der Standardbibliothek nach sich ziehen und damit den Code unnötig aufblähen. Daher werden wir uns eine einfache eigene Funktion schreiben, um die Zeichenfolgen umzuwandeln. In der HEX-Datei kommen 2 Byte und 4 Byte Hex-Zahlen im ASCII-Format vor. Wir brauchen also eine Funktion, welche die ASCII-Zeichenfolgen in Zahlen umwandelt, hier ist sie:
<c>
static uint16_t hex2num(const uint8_t * ascii, uint8_t num)
{
uint8_t i;
uint16_t val = 0;

for (i=0; i<num; i++)
{
uint8_t c = ascii[i];

/* Hex-Ziffer auf ihren Wert abbilden */
if (c >= '0' && c <= '9') c -= '0';
else if (c >= 'A' && c <= 'F') c -= 'A' - 10;
else if (c >= 'a' && c <= 'f') c -= 'a' - 10;

val = 16 * val + c;
}

return val;
}
</c>
Wir benutzen hier einen sehr einfachen Ansatz, um die Zahlen zu generieren. Die Funktionen wandeln die ASCII-Zeichen entsprechend ihrer Wertigkeit in Zahlen um. Soll z.B. das ASCII-Zeichen '1' umgewandelt werden, wird vom ASCII-Code '1', also dezimal 49, 48='0' abgezogen: 49 - 48 = 1, somit haben wir ein ASCII-Zeichen in eine Zahl umgewandelt. Wen das ASCII-Zeichen 'C' ist (Dezimal: 67), werden 'A' - 10 = 65 -10 = 55 abgezogen, um 12 zu erhalten, den Wert der hex-Ziffer C. Näher möchte an dieser Stelle nicht darauf eingehen, wir wollen schnell weiter zum Beschreiben des Flashs kommen.

Um in den Flash zu schreiben, werden wir Makros aus der ''[http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html boot.h]'' der avr-libc verwenden. Hier findet man alle Werkzeuge, die wir brauchen. Dabei sollte vor allen das ''API Usage Example'' in der [http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html Online Doku] näher betrachtet werden. Dieses Beispiel soll weitestgehend übernommen werden, da es die nötige Funktionalität beinhaltet. Hier ist die Funktion:
<c>
void boot_program_page (uint32_t page, uint8_t *buf)
{
uint16_t i;
uint8_t sreg;

/* Disable interrupts.*/
sreg = SREG;
cli();

eeprom_busy_wait ();

boot_page_erase (page);
boot_spm_busy_wait (); /* Wait until the memory is erased. */

for (i=0; i<SPM_PAGESIZE; i+=2)
{
/* Set up little-endian word. */
uint16_t w = *buf++;
w += (*buf++) << 8;

boot_page_fill (page + i, w);
}
boot_page_write (page); /* Store buffer in flash page. */
boot_spm_busy_wait(); /* Wait until the memory is written.*/

/* Reenable RWW-section again. We need this if we want to jump back */
/* to the application after bootloading. */
boot_rww_enable ();

/* Re-enable interrupts (if they were ever enabled). */
SREG = sreg;
}
</c>
Als erstes fällt auf, dass man der Funktion die ''Page''-Adresse übergibt. Es wird also immer seitenweise geschrieben. Dies ist eine Spezialität des Flash-Speichers. Es '''muss''' immer die gesamte Seite geschrieben werden, dafür gibt es einen ''Page''-Puffer, welcher die Daten enthält, welche mit der nächsten Schreiboperation in die entsprechende Page geschrieben werden. Dabei werden die Daten Wortweise in den ''Page''-Puffer geschrieben. Die wesentlichen Funktionen der Routine sind ''boot_page_erase(page)'', ''boot_page_fill(page + i, w)'' und ''boot_page_write(page)''. Nicht zu vergessen auch ''boot_spm_busy_wait()''. Die Bedeutung der Funktionen (naja es sind eher Makros) findet man in der Dokumentation der AVR Libc. Im wesentlichen läuft das Schreiben einer ''Page'' so ab:
* ''Page'' löschen
* ''Page''-Puffer befüllen (aus der Variable ''buf'')
* ''Page'' schreiben
So einfach, so gut. Für den Bootloader bedeutet das, dass er die Daten sammeln muß, bis er genügend Daten für eine ''Page'' hat. Dann wird eine ''Page'' geschrieben und der Spaß fängt von vorn an.

Mit diesen beiden Funktionen sind wir nun in der Lage, den Parser zu schreiben. Die ''main.c'' sieht folgt aus:
<c>
#include <string.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/boot.h>
#include <util/delay.h>
#include "uart.h"

#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */
#define START_SIGN ':' /* Hex-Datei Zeilenstartzeichen */

/* Zustände des Bootloader-Programms */
#define BOOT_STATE_EXIT 0
#define BOOT_STATE_PARSER 1

/* Zustände des Hex-File-Parsers */
#define PARSER_STATE_START 0
#define PARSER_STATE_SIZE 1
#define PARSER_STATE_ADDRESS 2
#define PARSER_STATE_TYPE 3
#define PARSER_STATE_DATA 4
#define PARSER_STATE_CHECKSUM 5
#define PARSER_STATE_ERROR 6

void program_page (uint32_t page, uint8_t *buf)
{
uint16_t i;
uint8_t sreg;

/* Disable interrupts */
sreg = SREG;
cli();

eeprom_busy_wait ();

boot_page_erase (page);
boot_spm_busy_wait (); /* Wait until the memory is erased. */

for (i=0; i<SPM_PAGESIZE; i+=2)
{
/* Set up little-endian word. */
uint16_t w = *buf++;
w += (*buf++) << 8;

boot_page_fill (page + i, w);
}

boot_page_write (page); /* Store buffer in flash page. */
boot_spm_busy_wait(); /* Wait until the memory is written.*/

/* Reenable RWW-section again. We need this if we want to jump back */
/* to the application after bootloading. */
boot_rww_enable ();

/* Re-enable interrupts (if they were ever enabled). */
SREG = sreg;
}

static uint16_t hex2num (const uint8_t * ascii, uint8_t num)
{
uint8_t i;
uint16_t val = 0;

for (i=0; i<num; i++)
{
uint8_t c = ascii[i];

/* Hex-Ziffer auf ihren Wert abbilden */
if (c >= '0' && c <= '9') c -= '0';
else if (c >= 'A' && c <= 'F') c -= 'A' - 10;
else if (c >= 'a' && c <= 'f') c -= 'a' - 10;

val = 16 * val + c;
}

return val;
}

int main()
{
/* Empfangenes Zeichen + Statuscode */
uint16_t c = 0,
/* Intel-HEX Zieladresse */
hex_addr = 0,
/* Zu schreibende Flash-Page */
flash_page = 0,
/* Intel-HEX Checksumme zum Überprüfen des Daten */
hex_check = 0,
/* Positions zum Schreiben in der Datenpuffer */
flash_cnt = 0;
/* temporäre Variable */
uint8_t temp,
/* Flag zum steuern des Programmiermodus */
boot_state = BOOT_STATE_EXIT,
/* Empfangszustandssteuerung */
parser_state = PARSER_STATE_START,
/* Flag zum ermitteln einer neuen Flash-Page */
flash_page_flag = 1,
/* Datenpuffer für die Hexdaten*/
flash_data[SPM_PAGESIZE],
/* Position zum Schreiben in den HEX-Puffer */
hex_cnt = 0,
/* Puffer für die Umwandlung der ASCII in Binärdaten */
hex_buffer[5],
/* Intel-HEX Datenlänge */
hex_size = 0,
/* Zähler für die empfangenen HEX-Daten einer Zeile */
hex_data_cnt = 0,
/* Intel-HEX Recordtype */
hex_type = 0,
/* empfangene HEX-Checksumme */
hex_checksum=0;
/* Funktionspointer auf 0x0000 */
void (*start)( void ) = 0x0000;

/* Füllen der Puffer mit definierten Werten */
memset(hex_buffer, 0x00, sizeof(hex_buffer));
memset(flash_data, 0xFF, sizeof(flash_data));

/* Interrupt Vektoren verbiegen */
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);

/* Einstellen der Baudrate und aktivieren der Interrupts */
uart_init( UART_BAUD_SELECT(BOOT_UART_BAUD_RATE,F_CPU) );
sei();

uart_puts("Hallo hier ist der echte Bootloader\n\r");
_delay_ms(2000);

do
{
c = uart_getc();
if( !(c & UART_NO_DATA) )
{
/* Programmzustand: Parser */
if(boot_state == BOOT_STATE_PARSER)
{
switch(parser_state)
{
/* Warte auf Zeilen-Startzeichen */
case PARSER_STATE_START:
if((uint8_t)c == START_SIGN)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_SIZE;
hex_cnt = 0;
hex_check = 0;
uart_putc(XON);
}
break;
/* Parse Datengröße */
case PARSER_STATE_SIZE:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_ADDRESS;
hex_cnt = 0;
hex_size = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_size;
uart_putc(XON);
}
break;
/* Parse Zieladresse */
case PARSER_STATE_ADDRESS:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 4)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_TYPE;
hex_cnt = 0;
hex_addr = hex2num(hex_buffer, 4);
hex_check += (uint8_t) hex_addr;
hex_check += (uint8_t) (hex_addr >> 8);
if(flash_page_flag)
{
flash_page = hex_addr - hex_addr % SPM_PAGESIZE;
flash_page_flag = 0;
}
uart_putc(XON);
}
break;
/* Parse Zeilentyp */
case PARSER_STATE_TYPE:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
hex_cnt = 0;
hex_data_cnt = 0;
hex_type = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_type;
switch(hex_type)
{
case 0: parser_state = PARSER_STATE_DATA; break;
case 1: parser_state = PARSER_STATE_CHECKSUM; break;
default: parser_state = PARSER_STATE_DATA; break;
}
uart_putc(XON);
}
break;
/* Parse Flash-Daten */
case PARSER_STATE_DATA:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
uart_putc('.');
hex_cnt = 0;
flash_data[flash_cnt] = (uint8_t)hex2num(hex_buffer, 2);
hex_check += flash_data[flash_cnt];
flash_cnt++;
hex_data_cnt++;
if(hex_data_cnt == hex_size)
{
parser_state = PARSER_STATE_CHECKSUM;
hex_data_cnt=0;
hex_cnt = 0;
}
/* Puffer voll -> schreibe Page */
if(flash_cnt == SPM_PAGESIZE)
{
uart_puts("P\n\r");
_delay_ms(100);
program_page((uint16_t)flash_page, flash_data);
memset(flash_data, 0xFF, sizeof(flash_data));
flash_cnt = 0;
flash_page_flag = 1;
}
uart_putc(XON);
}
break;
/* Parse Checksumme */
case PARSER_STATE_CHECKSUM:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
hex_checksum = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_checksum;
hex_check &= 0x00FF;
/* Dateiende -> schreibe Restdaten */
if(hex_type == 1)
{
uart_puts("P\n\r");
_delay_ms(100);
program_page((uint16_t)flash_page, flash_data);
boot_state = BOOT_STATE_EXIT;
}
/* Überprüfe Checksumme -> muss '0' sein */
if(hex_check == 0) parser_state = PARSER_STATE_START;
else parser_state = PARSER_STATE_ERROR;
uart_putc(XON);
}
break;
/* Parserfehler (falsche Checksumme) */
case PARSER_STATE_ERROR:
uart_putc('#');
break;
default:
break;
}
}
/* Programmzustand: UART Kommunikation */
else if(boot_state != BOOT_STATE_PARSER)
{
switch((uint8_t)c)
{
case 'p':
boot_state = BOOT_STATE_PARSER;
uart_puts("Programmiere den Flash!\n\r");
uart_puts("Kopiere die Hex-Datei und füge sie"
" hier ein (rechte Maustaste)\n\r");
break;
case 'q':
boot_state = BOOT_STATE_EXIT;
uart_puts("Verlasse den Bootloader!\n\r");
break;
default:
uart_puts("Du hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
uart_puts("\n\r");
break;
}
}
}
}
while(boot_state!=BOOT_STATE_EXIT);

uart_puts("Reset AVR!\n\r");
_delay_ms(1000);

/* Interrupt Vektoren wieder gerade biegen */
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp & ~(1<<IVSEL);

/* Reset */
start();

return 0;
}

</c>
'''''Erklärung des Codes'''''

Der Bootloader wird als ''Zustandsmaschine'' programmiert. Die Variable ''boot_state'' beinhaltet den aktuelle Programmzustand. Für den Parser gibt es eine eigene Zustandsvariable ''parser_state'', welche die einzelne Zustände des Parsers hält. Mit jeder HEX-Datei-Zeile läuft der Parser einmal durch alle Zustände. Nach Abarbeiten des aktuellen Zustands und Auswertung der empfangenen Daten wird der nächste Zustand aktiviert usw. Für das Verarbeiten der Datei wird jedes Mal die Kommunikation angehalten und ein ''XOFF'' gesendet. Nach Abarbeitung der Daten gibt der Parser den seriellen Empfang wieder frei (''XON''). '''''Es ist also wichtig, dass in PuTTY die XON/XOFF-Flußkontrolle aktiviert wird!''''' Durch den interruptgesteuerten Empfang mit einem 32 Byte tiefen Empfangspuffer geht kein Byte verloren. Am Ende einer HEX-Datei-Zeile wird die Checksumme ausgewertet. Bei falscher Checksumme springt der Parser in den ''PARSER_STATE_ERROR'', aus dem er nicht mehr rauskommt. Somit wird kein weiteres Byte in den Flash geschrieben. Zusätzlich könnte man noch implementieren, dass der Flash wieder gelöscht wird, wenn falsche Daten empfangen wurden, damit kein unvollständiges Programm im Flash steht.
Einschränkend muss noch festgehalten werden, das der Bootloader in dieser Fassung einen Adressraum bis 64K unterstützt (HEX-Zeilentyp 1). Die erweiterten Adressräume (HEX-Zeilentyp 2 bis 5) werden noch nicht unterstützt. Für ATmega-Devices mit > 64K Flash muss der Bootloader noch erweitert werden.

Nach dem Kompilieren beträgt die Größe des Bootloaders 1796 Byte, wir sind also unterhalb der 2048 Byte die wird "verbraten" können. Der Datenspeicher wird mit 283 Byte belastet.

Die Funktion des Bootloaders sieht wie folgt aus: Nach dem Reset wartet der Bootloader 2 Sekunden auf Eingaben (''_delay_ms(2000);''). Falls keine Eingaben von der Konsole kommen, springt der Bootloader zur Anwendung. Damit ist gewährleiset, dass die Anwendung später automatisch startet, auch wenn wir keine Taste drücken. Wird ein ''p'' gedrückt, springt der Bootloader in den ''BOOT_STATE_PARSER'' und erwartet eine HEX-Datei auf der Konsole. Dies ist der Zeitpunkt, die HEX-Datei der Anwendung mit Copy & Paste in die Konsole zu schreiben. Zum Einfügen von Daten aus dem Zwischenspeicher in die Konsole wird bei PuTTY die rechte Maustaste verwendet.

== Schritt 4 - Flashen und Ausprobieren des Bootloaders ==
Nach dem Flashen via AVRISPmkII startet der Bootloader in der Konsole. Da noch kein Anwendungsprogramm im Flash liegt, startet der Bootloader nach 2 Sekunden immer wieder neu. Nach Drücken der Taste ''p'' erwartet der Bootlader die HEX-Datei der Anwendung. Nach dem Einfügen der Datei in Konsole erscheint für jedes empfangene Byte ein Punkt ("."). Das Beschreiben einer Flash-''Page'' kenzeichnet ein ''P''. Nach dem erfolgreichen Flashen startet die Anwendung automatisch.

Nach erfolgreichem Flashen des Bootloaders via AVRISPmkII erscheint nach dem Reset folgendes Bild:

[[Bild:PuTTY-Real-Bootloader-start.png|PuTTY: Bootloader nach dem Reset]]

Drückt man die Taste '''p''', springt ist der Bootloader bereit zum Empfang der HEX-Datei:

[[Bild:PuTTY-Real-Bootloader-wait.png|PuTTY: Warten auf die HEX-Datei "Anwendung.hex"]]

Nach Kopieren & Einfügen der HEX-Datei der vorher kompilierten Anwendung, hier die Intel-HEX-Datei "Anwendung.hex":
<pre>
:100000002CC046C045C044C043C042C041C040C0EF
:100010003FC03EC03DC03CC03BC03AC039C038C004
:1000200037C036C064C08FC033C032C031C030C0AA
:100030002FC02EC048696572206973742064617393
:1000400020416E77656E64756E677370726F67724C
:10005000616D6D2E2E2E0D0A000011241FBECFEFF4
:10006000D4E0DEBFCDBF11E0A0E0B1E0EAE6F2E00F
:1000700002C005900D92A434B107D9F711E0A4E4B1
:10008000B1E001C01D92A938B107E1F702D0EBC081
:10009000B7CFEF92FF920F931F93CF93DF9383E33A
:1000A00090E07BD0789484E390E0D0D088ECE82E88
:1000B000F12C00E018E18BD0EC0190FDFCCF8236F2
:1000C00069F480E091E0B6D080E197E2F7013197E2
:1000D000F1F70197D9F7F8010995EDCF8CE191E09F
:1000E000A9D08C2F91D081E491E0A4D0E4CF1F92CD
:1000F0000F920FB60F9211242F938F939F93EF932C
:10010000FF939091C0002091C600E0918601EF5FBF
:10011000EF7180918701E81711F482E008C0892F00
:100120008871E0938601F0E0EC59FE4F20838093C4
:100130008801FF91EF919F918F912F910F900FBEAA
:100140000F901F9018951F920F920FB60F921124C7
:100150008F939F93EF93FF939091840180918501FA
:10016000981769F0E0918501EF5FEF71E0938501E9
:10017000F0E0EC5BFE4F80818093C60005C080916B
:10018000C1008F7D8093C100FF91EF919F918F916E
:100190000F900FBE0F901F9018959C011092840134
:1001A00010928501109286011092870197FF04C07A
:1001B00082E08093C0003F773093C5002093C40055
:1001C00088E98093C10086E08093C20008959091F1
:1001D000860180918701981719F420E031E012C060
:1001E000E0918701EF5FEF71E0938701F0E0EC5958
:1001F000FE4F308120918801922F80E0AC01430FA7
:10020000511D9A01C9010895282F909184019F5F83
:100210009F71809185019817E1F3E92FF0E0EC5B85
:10022000FE4F2083909384018091C100806280936F
:10023000C1000895CF93DF93EC0102C02196E4DF63
:1002400088818823D9F7DF91CF910895CF93DF93E9
:10025000EC0101C0D9DFFE01219684918823D1F7FA
:0A026000DF91CF910895F894FFCFCD
:10026A00537072696E6765207A756D20426F6F747C
:10027A006C6F616465722E2E2E0D0A00447520681B
:10028A0061737420666F6C67656E646573205A6566
:10029A00696368656E20676573656E6465743A2084
:0402AA00000A0D0039
:00000001FF
</pre>
erscheinen folgende Ausgaben in PuTTY:

[[Bild:PuTTY-Real-Bootloader-prog.png|PuTTY: Flashen der HEX-Datei "Anwendung.hex"]]

Nach erfolgreichem Flashen startet die Anwendung und meldet sich mit der Zeile
<pre>
Hier ist das Anwendungsprogramm...
</pre>
Jetzt können nach belieben Tasten gedrückt werden, was die Anwendung jedesmal quittiert:

[[Bild:PuTTY-Real-Bootloader-anwend.png|PuTTY: Ausprobieren der Anwendung]]

Nach Drücken der Taste '''b''' springt die Anwendung wieder zur Startadresse des Bootloaders, also zur Adresse ''0x1800'' im Flash-Speicher. Nun hat man wieder 2 Sekunden Zeit, um die Taste '''p''' zu drücken, sonst startet die Anwendung wieder:

[[Bild:PuTTY-Real-Bootloader-reset.png|PuTTY: Rücksprung zum Bootloader auf Adresse 0x1800]]

Damit ist das Tutorial abgeschlossen.

'''''Viel Spass beim Ausprobieren und Weiterentwickeln!'''''

= Zusammenfassung =

Wer den Artikel bis hier hin nachvollzogen hat, ist jetzt in der Lage einen Bootloader selbst zu schreiben. Dabei kann der Bootloader an jede in Frage kommenden ATmega-Plattform angepaßt werden. Dazu muss
* die Linkereinstellung für das Verschieben der Sektion ''.text'' angepasst werden und ('''-Ttext = 0xXXXX''')
* evtl. der virtuelle Funktionspointer in der Anwendung geändert werden (falls ein Rücksprung zum Bootloader gewünscht ist '''void (*bootloader)(void) = 0xXXXX''').

Um dies zu erleichtern, habe ich hier die Sprungadressen für ausgewählte AVRs tabellarisch zusammengetragen. Dabei wurde immer die maximale Größe des Bootloader betrachtet, also '''BOOTSZ0=0''' und '''BOOTSZ1=0''':

{| border="1" class="wikitable"
|+ Größe und Startadresse der Bootloader Sektion für ausgewählte AVR-Devices
|-
! Device || Flash-Größe für Applikation || Flash-Größe des Bootloaders || Startadresse des Bootloaders (Byteadresse)
|-
| ATmega8/88 || 6144 Byte || 2048 Byte || 0x1800
|-
| ATmega16/164/168 || 14336 Byte || 2048 Byte || 0x3800
|-
| ATmega32/324/328 || 28672 Byte || 4096 Byte || 0x7000
|-
| ATmega64/644/640 || 57344 Byte || 8192 Byte || 0xE000
|-
| ATmega128/1284/1280/1281 || 122880 Byte || 8192 Byte || 0x1E000
|-
| ATmega2560/2561 || 253952 Byte || 8192 Byte || 0x3E000
|}

Damit kann jeder den Bootloader nach seinen Wünschen anpassen. Eine gängige Praxis ist auch, ein kleines PC-Programm zu schreiben, welches dem Bootloader die Flash-Daten gleich Binär übergibt. Das geht schneller und spart das aufwendige Parsen. Eine weitere Idee ist es, den Bootloader so anzupassen, das er sich wie ein STK500 an der seriellen Schnittstelle verhält. Dazu muss man die [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735 AP068] von Atmel umsetzen. Auch dies sollte nach dem Studium des Tutorial kein Problem mehr sein :)

[http://www.mikrocontroller.net/user/show/mario Nachricht an den Autor]

= FAQ =

== Wie kann man Bootloader und Anwendungsprogramm gemeinsam flashen? ==

Es ist in C ohne weiteres nicht möglich ein gemeinsames Hexfile aus Bootloader und Anwendungsprogramm zu kompilieren. Aber man kann das getrennt erstellte Hexfile des Bootloaders und das getrennt erstellte Hexfile des Anwendungsprogramms zusammenfügen und so gemeinsam mit ISP flashen. Dazu die letzte Zeile des 1. Hexfiles entfernen und dahinter das 2. Hexfile anfügen [http://www.mikrocontroller.net/topic/199241#1955092], [http://www.mikrocontroller.net/topic/198428#1949164].

[[Kategorie:AVR-Programmer und -Bootloader|B]]

AVR TWI

2010-11-05T18:58:36Z

Sebion7125:

''von Alexander Starke''

== Grundlagen ==

Das TWI (Two Wire Interface) ist begründet durch seinen Aufbau ideal auf typische Mikrocontroller Applikationen zugeschnitten. Durch seinen 7 Bit breiten Adressraum können bis zu 128 (27 = 128) Geräte miteinander verschaltet werden. Im Gegensatz zum SPI ([[Serial Peripheral Interface]]) werden nur zwei Busleitungen benötigt. Eine dient der Bereitstellung des Taktes (SCL) und die andere dem Datentransport (SDA). Die einzige zusätzlich benötigt Hardware besteht aus zwei Pull-Up Widerständen, welche von jeweils einer Busleitung gegen Vcc (5V) geschalten werden. Da alle Bustreiber mit offenem Kollektor bzw. Drain am Bus anliegen, ergibt sich eine logische UND-Verknüpfung. D.h., sobald irgendein Gerät auf einer der Busleitungen Low-Pegel anlegt, liegt automatisch die gesamte Busleitung auf Low. Der BUS hat nur High-Pegel, wenn alle angeschlossenen Geräte auch High-Pegel an ihrer entsprechenden Schnittstelle haben.

Genau wie beim SPI initiiert auch beim TWI der Master den Datentransfer und beendet selbigen auch wieder. Gestartet wird eine Transmission durch eine Start-Bedingung und entsprechend beendet durch eine Stop-Bedingung. Während einer Transmission gilt der Bus als "busy" (beschäftigt) und kein anderer Master darf versuchen, Kontrolle über ihn zu erlangen. Einzige Ausnahme bildet hier der Fall, dass vor einer Stop-Bedingung durch den gerade aktiven Master noch eine zusätzliche Start-Bedingung auf den Bus gegeben wird. Dieser Fall tritt normalerweise dann ein, wenn der Master noch weitere Daten zu versenden hat und nicht die Kontrolle über den Bus verlieren möchte. Nach solch einem wiederholten Start (Repeated Start) ist der Bus wieder beschäftigt, bis zum nächsten Stop.
Start- und Stop-Bedingungen werden signalisiert, indem der Pegel der SDA-Leitung wechselt, während SCL High-Pegel hat.

Alle Adresspakete auf dem TWI Bus haben eine Länge von 9 Bit. Davon beinhalten 7 Bit wie bereits eingangs erwähnt die Adresse der angesprochenen Komponente. Zusätzlich gibt es noch ein Bit, dass darüber bestimmt, ob ein Lese- oder ein Schreibzugriff durchgeführt werden soll (R/W=1 -> Lesen; RW=0 -> Schreiben). Das 9 Bit dient der Bestätigung. Wenn ein Slave bemerkt, dass er angesprochen wird, so bestätigt er dies, indem er mit dem 9. Taktzyklus (ACK) von SCL SDA auf Low-Pegel legt. Sollte der angesprochene Slave aus irgendwelchen Gründen nicht antworten können, so sollte SDA auf H-Pegel bleiben. Der Master hat dann die Wahl, ob er ein Stop sendet oder einen wiederholten Start durchführt.

* SLA +R --> Adresspaket mit einer Slave-Adresse und einem Lese-Bit
* SLA +W --> Adresspaket mit einer Slave-Adresse und einem Schreib-Bit

Das höchstwertige Bit wird prinzipiell zuerst übertragen (MSB Most Significant Bit). Die Slave-Adressen können durch den Anwender frei gewählt werden, nur 0000 000 ist reserviert, hiermit werden alle Slaves angesprochen. Wird ein solcher Zugriff durchgeführt, so sollten alle Slaves im ACK-Zyklus SDA auf L-Pegel legen.
Benutzt wird diese Aktion, wenn der Master die selben Daten an mehrere Slaves senden möchte. Sinn macht die Verwendung nur in Verbindung mit dem Schreib-Bit. Ein Setzen des Lese-Bits hätte zur Folge, dass verschiedene Slaves ja verschiedene Daten auf den Bus stellen könnten, was zu einem Durcheinander führen würde. Wird das Schreib-Bit gesetzt, so setzen im ACK-Zyklus alle Slaves SDA auf L-Pegel, welche den allgemeinen Adressaufruf erhalten und ausgewertet haben (also die nicht beschäftigt waren). Die folgenden Datenpakete werden dann von allen Slaves empfangen, welche SDA auf L-Pegel gelegt hatten.

Alle Datenpakete auf dem TWI-Bus haben analog zu den Adresspaketen 9 Bit. Hiervon sind 8 Datenbits. Das 9. dient der Bestätigung. Während einer Datenübertragung ist es Aufgabe des Masters, den Takt, das Start- und das Stopzeichen bereitzustellen. Aufgabe des Empfängers ist die Bestätigung der erhaltenen Daten, indem er die SDA-Leitung während des 9. SCL-Zyklus auf L-Pegel legt. Dieses wird als ACK bezeichnet (Acknowledge). Bleibt SDA auf H-Pegel, so wird dem Sender signalisiert, dass die gesendeten Daten nicht empfangen wurden (NACK). Das MSB wird zuerst übertragen.

Wenn man nun Adress- und Datenpakete kombiniert, hat man schon eine fertige Transmission. Diese besteht aus:

* START --> SLA R/W --> ein oder mehr Datenpakete --> STOP

Ein START gefolgt von einem STOP ist nicht zulässig. Wenn der Takt des Masters für den Slave zu schnell ist oder er noch mehr Zeit zur Bearbeitung braucht, so kann er SCL einfach länger auf L-Pegel halten. Die Verlängerung der L-Phase von SCL hat allerdings keinen Einfluss auf die Länge der H-Phase, da diese vom Master zur Verfügung gestellt wird. Dadurch kann es allerdings zu einer Reduzierung des Datentransfers kommen.

== Multi-Master-Bussysteme ==

Das TWI-Bussystem erlaubt den Multi-Master Betrieb. Es wurden spezielle Vorkehrungen getroffen, so dass auch wenn mehrere Master zur selben Zeit eine Transmission beginnen wollen keine Probleme auftreten und der Bus normal funktioniert. Nur die zwei folgenden Probleme sollten beachtet werden:

# Es ist Sache des Anwenders, seine Algorithmen so auszulegen, dass in diesem Fall nur ein Master seine Transmission fortsetzt. Alle anderen Master sollten ihre Transmission sofort abbrechen. Diesen Auswahlprozess zwischen den Mastern nennt man Arbitrierung (Entscheidung). Wenn ein Master bemerkt, dass er den Entscheidungsprozess (die Arbitrierung) verloren hat, sollte er sofort in den Slave-Modus gehen, da es sein kann, dass der Master welcher den Prozess gewonnen hat ihn adressieren will. Die Tatsache, dass mehrere Master versucht hatten, eine Übertragung zu starten, sollte für die Slaves nicht feststellbar sein, die Daten auf dem Bus dürfen nicht beschädigt sein.
# Da verschiedene Master mit verschiedenen Taktfrequenzen auf dem Bus arbeiten könnten, ist eine Festlegung zu treffen, wie man diese synchronisiert. Dieses erleichtert auch den Arbitrierungsprozess.

Diese Lösung dieses Problems stellt die schon oben angesprochene UND-Verknüpfung aller Komponenten auf dem Bus dar. So werden alle seriellen Taktraten der einzelnen Master UND verknüpft. Somit ergibt sich ein High-Pegel entsprechend dem des Masters mit dem kürzesten H-Pegel, der Low-Pegel ist durch den Master mit der geringsten Taktrate gegeben.

Da der Multi-Master Betrieb für meine Anwendung keinen Belang hat, werde ich hier nicht näher darauf eingehen.

==Aufbau des TWI==

Der SCL- und der SDA-Pin stellen die Schnittstelle des einzelnen MC mit dem Bus dar. Zusätzlich ist intern vorgesehen, dass Spannungsspitzen, welche kürzer als 50ns sind, herausgefiltert werden. Es besteht bei manchen Konfigurationen die Möglichkeit, die internen Pull-Up Widerstände zu verwenden, dies kann die Verwendung der externen überflüssig machen.

Zusätzlich verfügt der ATmega über einen Bitraten-Generator, welcher im Masterbetrieb das entsprechende Signal auf SCL gibt. Die Taktrate wird durch das TWBR (TWI Bit Rate Register) und TWSR (TWI Status Register) festgelegt. Zu beachten ist, dass die interne Taktfrequenz der einzelnen Slaves mindestens 16 mal höher als die Taktrate des Bus ist. Diese ergibt sich nach folgender Formel:

http://www.mikrocontroller.net/mc-project/Pages/AVR/TWI/twi_formel.gif

* TWBR - TWI Bit Rate Register
* TWPS - TWI Prescaler Bits im TWI Status Register

Des weiteren verfügt der MC über je ein Daten- und Adressschieberegister, einen START/STOP Controller und die Arbitrierungslogik. Das TWDR (TWI Data Register) beinhaltet entweder die Adresse und Daten welche gesendet werden sollen oder die empfangene Adresse samt Daten. Zusätzlich existiert noch ein Register, welches das (N)ACK-Bit enthält, das aber nicht direkt zugänglich ist. Jedoch kann es im Empfangsmodus durch verändern von TWCR (TWI Control Register) bzw. im Empfangsmodus durch verändern von TWSR manipuliert werden.

Der START/STOP Controller ist wie sein Name bereits sagt, dafür verantwortlich, den anderen Teilnehmern am Bus mitzuteilen, dass der entsprechende Master eine Übertragung plant bzw. beendet. Zusätzlich führt er auch den bereits erwähnten REPEATED START durch. Eine Besonderheit ist, dass er solche START/STOP-Zeichen auf dem Bus sogar detektieren kann, wenn sich der Controller in einem der Sleep-Modi befindet. Er kann somit "aufgeweckt" werden, wenn er von einem Master adressiert wird.

Ein weiterer Bestandteil des TWI ist die "Adress Match Unit". Diese überwacht, ob die empfangenen Adress-Bytes mit denen im TWAR (TWI Adress Register) übereinstimmen. Wenn TWGCE (TWI General Call Recognition Enable) in TWAR gesetzt ist, werden alle eingehenden Adress-Bytes zusätzlich noch daraufhin überprüft, ob eine allgemeine Ruf (0000 000) vorliegt. Sollte eine Übereinstimmung vorliegen, wird die Kontrolleinheit informiert, eventuelle Korrekturmaßnahmen können durchgeführt werden. Die TWI-Logik kann nun die Anforderung bestätigen, je nach dem welche Einstellungen in TWCR getroffen wurden. Wie bereits oben angesprochen wurde, arbeitet die Adress-Vergleichs-Logik sogar, wenn sich der MC in einem der Sleep-Modi befindet. Man kann den MC somit per TWI reaktivieren. Einzige Ausnahme bildet der Fall, dass der Controller zuvor durch einen anderen Interrupt reaktiviert wurde. Danach geht die TWI-Logik sofort in den Leerlauf. Sollte das bei der vorgesehenen Problemstellung zu Problemen führen, bleibt nur der Ausweg sämtliche anderen Interrupts in der Hinsicht zu sperren, dass sie den Controller nicht mehr reaktivieren können.

Die Kontrolleinheit des TWI beobachtet ständig den Bus und antwortet auf Anfragen entsprechend den Einstellungen in TWCR. Tritt ein Ereignis ein, auf welches die angesprochene Einheit reagieren soll, so wird automatisch TWINT (TWI Interrupt Flag) gesetzt. Im nächsten Taktzyklus wird dann TWSR aktualisiert, in ihm steht jetzt ein Code mit welchem das Ereignis spezifiziert werden kann. TWSR beinhaltet nur relevante Informationen, wenn TWINT gesetzt wird, andernfalls beinhaltet es bloß einen Statuscode, welcher aussagt, dass keine relevanten Informationen vorliegen. Solange TWINT gesetzt ist, wird SCL auf Low Pegel belassen. Dies gibt dem angesprochenen MC die Chance, alle Anwendungen erst zu beenden, bevor er sich der Transmission widmet. TWINT wird gesetzt wenn:

* wenn das TWI START/REPEATED START gesendet hat
* wenn das TWI SLA +R/W gesendet hat
* wenn das TWI ein Adress-Byte gesendet hat
* wenn das TWI seine "Vormacht" auf dem Bus verloren hat
* wenn das TWI durch seine eigene Slave-Adresse bzw. einen allgemeinen Ruf (general call) adressiert wurde
* wenn das TWI ein Datenbyte empfangen hat
* wenn ein STOP oder REPEATED START empfangen wurde, während es immer noch als Slave angesprochen ist
* wenn ein Busfehler durch einen illegalen START bzw. STOP aufgetreten ist

== Benutzung des TWI ==

Das TWI ist wie bereits ausführlich dargestellt wurde, byte- bzw. interruptbasiert. Dadurch ist es der Anwendersoftware möglich, parallel zum Datenversand bzw. -empfang auf dem TWI Bus noch weitere Anwendungen (Operationen) auszuführen. Die Ausführung einer ISR ist allein durch das Setzen von TWIE (TWI Interrupt Enable) in TWCR bedingt (die Interrupts müssen natürlich auch global freigegeben sein). Es ist Sache des Anwenders, ob das Setzen von TWINT einen Interrupt verursachen soll. Ist TWIE nicht gesetzt, so ist es dem Programm selbst überlassen, ständig TWINT zu prüfen, um sämtliche Ereignisse auf dem Bus mit zu bekommen.

Bei jedem Setzen von TWINT ist eine Operation auf dem Bus abgeschlossen worden und es wird eine Antwort erwartet. In diesem Fall beinhaltet TWSR einen Wert, welcher ein direktes Maß für den aktuellen Status des Bus ist. Die Software legt nun fest, welche Aktion mit dem nächsten Buszyklus durchgeführt werden soll, indem sie TWCR und TWDR entsprechend verändert. Im folgenden wird schrittweise ein Beispiel für den Ablauf einer Übertragung gegeben.

Um die entsprechenden Statusmakros (''TW_*'') verwenden zu können wird die entsprechende Headerdatei eingebunden.

<c>
#include <util/twi.h>
</c>

Zuerst muss vom Master ein START-Signal auf den Bus gegeben werden. Dies erfolgt durch Schreiben eines speziellen Wertes in TWCR. Nach Abschluss der Operation wird TWINT gesetzt. Die Logik wartet nun so lange, bis durch den Anwender das Flag wieder gelöscht wurde (durch Schreiben einer '1'). Unmittelbar nach dem Löschen von TWINT beginnt die Logik damit das START-Signal zu senden.

<c>
TWCR = _BV(TWINT) | _BV(TWSTA) | _BV(TWEN); //TWSTA = TWI START Condition Bit
</c>

Nach dem Senden des START wird sofort wieder TWINT in TWCR gesetzt. Zusätzlich beinhaltet TWSR jetzt den entsprechenden Status Code, welcher mitteilt, dass START erfolgreich gesendet wurde.

<c>
while (!(TWCR & (1<<TWINT)));
</c>

Nachdem durch die Applikation TWSR daraufhin überprüft wurde, dass START erfolgreich gesendet wurde, kann es nun weitergehen. Im Fehlerfall könnte beispielsweise eine vom Anwender definierte Fehlerroutine greifen.

Nun muss SLA_W in TWDR geladen werden. Ist dies abgeschlossen, muss wiederum ein spezieller Wert in TWCR geschrieben werden, um der TWI-Logik mitzuteilen, dass die Adresse und der Schreibbefehl aus TWDR gesendet werden können. Unmittelbar nachdem durch den Anwender dann TWINT in TWCR gelöscht wurde (Schreiben einer '1') sendet das TWI das Adresspaket.

<c>
if ((TWSR & 0xF8) != TW_START)
ERROR(); //Fehlerbehandlung
TWDR = SLA_W;
TWCR = (1<<TWINT) | (1<<TWEN);
</c>

Nach Abschluss der Sendung wird wiederum TWINT gesetzt in TWSR steht der entsprechende Statuscode, welcher über Erfolg bzw. Misserfolg der Sendung urteilt. In ihm ist auch das ACK-Bit des angesprochenen Slaves enthalten (oder auch nicht, was dann einen Fehler bedeuten würde).

<c>
while (!(TWCR & (1<<TWINT)));
</c>

Nach der Prüfung von TWSR ob bei der Sendung keine Fehler aufgetreten sind, kann das Datenpaket in TWDR geladen werden. Erneut muss ein spezieller Wert in TWCR geschrieben werden, welcher der Logik sagt, dass ein Datenpaket aus TWDR versendet werden soll. Nach dem Löschen von TWINT wird dieses automatisch versendet.

<c>
if ((TWSR & 0xF8) != TW_MT_SLA_ACK)
ERROR();
TWDR = DATA;
TWCR = (1<<TWINT) | (1<<TWEN);
</c>

Nachdem TWINT gesetzt wurde kann mit Hilfe von TWSR überprüft werden, ob das Datenpaket erfolgreich gesendet und vom angesprochenen Slave angenommen wurde (ACK-Bit).

<c>
while (!(TWCR & (1<<TWINT)));
</c>

Nachdem bis hierhin alles funktioniert hat (angenommen), muss nun nur noch ein STOP gesendet werden. Dies erfolgt analog zu den obigen Ausführungen durch Schreiben eines speziellen Wertes in TWCR. Nach dem Löschen von TWINT wird dieses gesendet. Allerdings wird danach TWINT nicht automatisch wieder gesetzt, wie es zuvor immer der Fall war.

<c>
if ((TWSR & 0xF8) != TW_MT_DATA_ACK)
ERROR();
TWCR = (1<<TWINT)|(1<<TWEN)|
(1<<TWSTO);
</c>

Anmerkung: Selbstverständlich muss zuvor beim anzusprechenden Slave in TWAR (TWI Adress Register) eine Adresse festgelegt werden, damit er auch gezielt angesprochen werden kann.

== Übertragungsmodi ==

Das TWI kann prinzipiell in vier verschiedenen Modi arbeiten: Master Transmitter (MT), Master Receiver (MR), Slave Transmitter (ST), Slave Receiver (SR). Diese können natürlich alle in einer Anwendung verwendet werden, je nachdem, wie sie es erfordert.

=== Master Transmitter Mode ===

Im MTM wird eine Abfolge von Bytes (Daten) an einen SR gesendet. Um ihn zu benutzen, muss das Adresspaket nach dem gesendeten START eine bestimmte Form aufweisen. Wird SLA+W gesendet, liegt der MTM vor, für SLA+R wäre es der MRM.
Das Senden eines START gestaltet sich wie folgt (TWCR):

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

* TWEN: Aktivierung des TWI
* TWSTA: Senden des START
* TWINT: um TWINT zu löschen

Das TWI wartet nun solange, bis der Bus frei ist und sendet dann START. Danach wird TWINT wieder gesetzt und TWSR aktualisiert. Es sollte jetzt 0x08 enthalten. Beim Auslesen des Status-Code müssen die Prescaler-Bits mit Null maskiert werden. Um den MTM zu benutzen, muss SLA+W in TWDR geschrieben werden. Nachdem TWINT gelöscht wurde, wird dies gesendet. TWCR muss dazu die folgende Form haben:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |0 |0 |X |1 |0 |X
}}

Nachdem SLA+W gesendet und das ACK-Bit empfangen wurde, wird TWINT erneut gesetzt. Der Statuscode in TWSR kann nun unter anderem folgende Formen haben: 0x18, 0x20, 0x38.

Nachdem bis hierhin alles erfolgreich funktioniert hat, kann jetzt ein Datenpaket versendet werden. Dies erfolgt durch Schreiben der Daten in TWDR. TWDR kann nur aktualisiert werden, wenn TWINT gesetzt ist, andernfalls kommt es zu einem Fehler, TWWC (TWI Write Collision Bit) wird gesetzt. Um die Daten zu senden, muss TWINT erneut gelöscht werden. TWCR sollte so aussehen:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

Dieses Schema wiederholt sich nun solange, bis alle Daten versendet wurden und ein STOP gesendet werden kann. Dies erfolgt folgendermaßen:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |0 |1 |X |1 |0 |X
}}

Ein erneuter Start (REPEATED START) erfolgt durch Schreiben der folgenden Werte in TWCR:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

Nach einem REPEATED START kann der Master denselben Slave erneut kontaktieren oder auch einen anderen, ohne ein STOP zu senden. Der REPEATED START erlaubt dem Master das Wechseln zwischen Slaves, MTM und MRM ohne die Kontrolle über den Bus zu verlieren.

Eine Tabelle mit sämtlichen Status-Codes und den zugehörigen Ereignissen ist dem Datenblatt S.176 zu entnehmen.

=== Master Receiver Mode ===

Im MRM empfängt der Master Daten von einem ST. Zunächst muss wieder START gesendet werden. Das folgende Adresspaket sollte dann SLA+R enthalten.

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

* TWEN: Aktivierung des TWI
* TWSTA: Senden des START
* TWINT: um TWINT zu löschen

Das TWI wartet nun solange, bis der Bus frei ist und sendet dann START. Danach wird TWINT wieder gesetzt und TWSR aktualisiert. Es sollte jetzt 0x08 enthalten. Beim Auslesen des Status-Code müssen die Prescaler-Bits mit Null maskiert werden. Um den MTM zu benutzen, muss SLA+R in TWDR geschrieben werden. Nachdem TWINT gelöscht wurde, wird dies gesendet. TWCR muss dazu die folgende Form haben:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |0 |0 |X |1 |0 |X
}}

Nachdem SLA+R gesendet und das ACK-Bit empfangen wurde, wird TWINT erneut gesetzt. Der Statuscode in TWSR kann nun unter anderem folgende Formen haben: 0x38, 0x40, 0x48.
Die empfangenen Daten können aus TWDR gelesen werden, so denn TWINT gesetzt ist. Dieses Schema kann sich bis zum Empfang des letzten Bytes immer wieder wiederholen. Nachdem das letzte Byte empfangen wurde, kann der Master dem Slave durch senden von NACK klar machen, dass keine Daten mehr erwartet werden. Beendet wird der Transfer durch senden von STOP oder REPEATED START.
Für STOP muss folgendes in TWCR geschrieben werden:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |0 |1 |X |1 |0 |X
}}

Für einen REPEATED START muss folgendes in TWCR geschrieben werden:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

Nach einem REPEATED START kann der Master denselben Slave erneut kontaktieren oder auch einen anderen, ohne ein STOP zu senden. Der REPEATED START erlaubt dem Master das Wechseln zwischen Slaves, MTM und MRM ohne die Kontrolle über den Bus zu verlieren.

Eine Tabelle mit sämtlichen Status-Codes und den zugehörigen Ereignissen ist dem Datenblatt S.179 zu entnehmen.

=== Slave Receiver Mode ===

Im SRM werden Daten vom MT empfangen. Um einen Atmega8 im SRM zu betreiben, müssen TWAR und TWCR die folgende Form haben:

TWAR:
Die oberen 7 Bit stellen die Adress dar, an die das TWI antwortet, wenn es von einem Master angesprochen wird. Wenn das LSB (Least Significant Bit) in Form von TWGCE gesetzt ist, antwortet der Slave auch auf allgemeine Rufe (general calls), andernfalls natürlich nicht.

{{ByteWithValues|
|TWA6|TWA5|TWA4|TWA3|TWA2|TWA1|TWA0|TWGCE
|Hier|steht|dann|die|Adresse|des|Slave!|X
}}

TWCR:
TWEN muss zum aktivieren des TWI gesetzt werden. TWEA muss gesetzt werden, damit der Slave antwortet, falls er von einem Master oder gegeben falls durch einen general call angesprochen wird. TWSTA und TWSTO müssen auf Null gesetzt werden.

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|0 |1 |0 |0 |0 |1 |0 |X
}}

Wenn TWAR und TWCR initialisiert wurden, wartet der Slave ab, bis er mit seiner Adresse bzw. gegebenen falls durch einen generall call angesprochen wird gefolgt von einem Datenrichtungs-Bit. Hierbei steht eine '0' für Schreiben (SR) und eine '1' für Lesen (ST).
Nachdem die Logik ihre eigene Adresse und ein Schreib-Bit erhalten hat, wird TWINT gesetzt und TWSR beinhaltet den entsprechenden Statuscode. Mit seiner Hilfe kann die Software dann eine sinnvolle Reaktion einleiten. Der Eintritt in den SRM kann auch erfolgen, wenn ein Master sein Vorrecht auf dem Bus verloren hat (0x68, 0x78).

Wenn TWEA während eines Transfers zurückgesetzt wird, wird das TWI ein NACK (Not Acknowledge) auf den Bus nach Empfang des nächsten Bytes geben. Dies kann verwendet werden, wenn der Slave nicht mehr in der Lage ist, mehr Bytes zu empfangen. Solange TWEA '0' ist, reagiert das TWI nicht mehr auf seine eigene Slave-Adresse. Jedoch wird der Bus weiterhin beobachtet und das TWI ist nach dem Setzen von TWEA sofort wieder einsatzbereit. Somit kann dieses Feature verwendet werden, um einen Baustein für eine bestimmte Zeitspanne vom Bus zu nehmen.

In sämtlichen Sleep-Modi (außer Idle Mode) ist der Systemtakt des TWI inaktiv. Dessen zu trotz kann das TWI durch setzen von TWEA allein mit Hilfe des Bustaktes erfassen, wenn es mit seiner Adresse bzw. durch einen general call angesprochen wird. Somit kann das TWI den Controller aufwecken. Während der Aufweck-Phase kann SCL auf L-Pegel gehalten werden wenn TWINT gelöscht ist (Schreiben einer '1'). Der Datenempfang kann wieder im Normalbetrieb stattfinden. Zu beachten ist, dass solange SCL auf L-Pegel ist keine anderen Transmissionen stattfinden können. Wichtig ist, dass TWDR nach dem Aufwecken nicht mehr das letzte Byte, welches auf dem Bus war, enthält.

Eine Tabelle mit sämtlichen Status-Codes und den zugehörigen Ereignissen ist dem Datenblatt S.182 zu entnehmen.

=== Slave Transmitter Mode ===

Im STM werden Daten an einen MR gesendet. Um den Controller im STM zu betreiben, müssen TWAR und TWCR wie folgt initialisiert werden.

TWAR:
Die oberen 7 Bit stellen die Adress dar, an die das TWI antwortet, wenn es von einem Master angesprochen wird. Wenn das LSB (Least Significant Bit) in Form von TWGCE gesetzt ist, antwortet der Slave auch auf allgemeine Rufe (general calls), andernfalls natürlich nicht.

{{ByteWithValues|
|TWA6|TWA5|TWA4|TWA3|TWA2|TWA1|TWA0|TWGCE
|Hier|steht|dann|die|Adresse|des|Slave!|X
}}

TWCR:
TWEN muss zum aktivieren des TWI gesetzt werden. TWEA muss gesetzt werden, damit der Slave antwortet, falls er von einem Master oder gegeben falls durch einen general call angesprochen wird. TWSTA und TWSTO müssen auf Null gesetzt werden.

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|0 |1 |0 |0 |0 |1 |0 |X
}}

Nach der Initialisierung wartet das TWI auf eine Anfrage gefolgt von einem Datenrichtungsbit. Wird das TWI angesprochen wird TWINT gesetzt und TWSR beinhaltet den Statuscode. Mit seiner Hilfe kann das weitere Vorgehen festgelegt werden. Ein Controller kann auch in den STM gelangen, wenn er die Hoheit auf dem Bus an einen anderen Master verliert (0xB0).

Wird TWEA während eines Transfers gesetzt, wird das aktuelle Byte noch fertig gesendet und Status 0xC0 oder 0xC8 tritt ein, je nachdem ob der Master ACK oder NACK nach dem letzten Byte gesendet hatte. Das TWI wird in einen Blockierzustand gehen, unabhängig davon, ob der Master den Transfer fortsetzt. So erhält der Master nur noch '1' auf dem seriellen Bus. Status 0xC8 tritt ein, wenn der Master weitere Daten fordert (durch Senden von ACK), obwohl der Slave bereits das letzte Byte gesendet hat (TWEA '0' und erwartet NACK).

Trotz des Blockierzustandes wird der Bus weiter beobachtet und das TWI kann durch setzen von TWEA jederzeit wieder daran teilnehmen. Somit kann der Slave mit Hilfe von TWEA kurzzeitig vom Bus isoliert werden.

In sämtlichen Sleep-Modi (außer Idle Mode) ist der Systemtakt des TWI inaktiv. Dessen zu trotz kann das TWI durch setzen von TWEA allein mit Hilfe des Bustaktes erfassen, wenn es mit seiner Adresse bzw. durch einen general call angesprochen wird. Somit kann das TWI den Controller aufwecken. Während der Aufweck-Phase kann SCL auf L-Pegel gehalten werden wenn TWINT gelöscht ist (Schreiben einer '1'). Der Datenversand kann wieder im Normalbetrieb stattfinden. Zu beachten ist, dass solange SCL auf L-Pegel ist keine anderen Transmissionen stattfinden können. Wichtig ist, dass TWDR nach dem Aufwecken nicht mehr das letzte Byte, welches auf dem Bus war, enthält.

Eine Tabelle mit sämtlichen Status-Codes und den zugehörigen Ereignissen ist dem Datenblatt S.185 zu entnehmen.

Zusätzlich zu den Betriebsart bezogenen Statuscodes gibt es noch zwei, welche davon unabhängig sind.
Status 0xF8 bedeutet, dass keine relevanten Informationen vorhanden sind, da TWINT nicht gesetzt ist. Dieser Fall tritt bei einem Statuswechsel ein oder wenn TWI im Moment nicht am Bus beteiligt ist.

Status 0x00 steht für einen Busfehler während einer Übertragung. Ursache kann das Senden von START oder STOP zu einem nicht zulässigem Zeitpunkt sein. Bei solch einem Fehler wird TWINT automatisch gesetzt. Um die Fehlerroutine zu verlassen, muss TWSTO gesetzt und TWINT gelöscht werden. Dieses führt dazu, dass das TWI in den nicht adressierten Slave-Modus geht und SDA und SCL wieder freigegeben werden. Es wird kein STOP gesendet.



== Weblinks ==

=== Application notes ===

* [http://www.atmel.com/dyn/resources/prod_documents/doc2565.pdf AVR311: Using the TWI module as I2C slave]

* [http://www.atmel.com/dyn/resources/prod_documents/doc2564.pdf AVR315: Using the TWI module as I2C master]

=== Bibliotheken ===

* [http://jump.to/fleury Peter Fleury's AVR I2C Library]

* http://www.mikrocontroller.net/topic/87597

* [http://www.jtronics.de/elektronik-avr/lib-i2ctwi-avr.html AVR TWI Slave]

[[Category:AVR]]
[[Category:Mc-project.de]]
[[Category:I2C]]