Mikrocontroller.net - Benutzerbeiträge [de]

BMA020

2013-07-03T08:59:24Z

Muebau: /* 10 Bitwerte */ spelling

Der BMA020 ist ein 3-Achsen-Beschleunigungssensor von Bosch der über I2C oder ISP ausgelesen und konfiguriert werden kann.

=BMA020=
==Bauteilseite==
[http://www.mikrocontroller.net/part/BMA020 Zur Bauteilseite des BMA020]

==Bezugsquellen==
===ELV===
http://www.elv.de/3-Achsen-Beschleunigungssensor-3D-BS,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_28515
===Farnell===
http://de.farnell.com/bosch/bma020-0330sb000b/daughter-board/dp/1795593?Ntt=BMA020

==Speicheraufteilung==
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Speicher'''
|-
! Adresse
! Bit 7
! Bit 6
! Bit 5
! Bit 4
! Bit 3
! Bit 2
! Bit 1
! Bit 0
! Typ
! Axis
|-
| 16h - 7Fh
|colspan="8"| -
| reserved
|rowspan="15"|
|-
| 15h
| SPI4E (4 wire SPI enable) (default: 1)
| EAI (enable advanced interrupt)
| NDI (new data interrupt)
| LI (latch interrupt)
|[[#Shadow disable|SD (shadow disable / read MSB only)]]
|colspan="2"| WUP (wake up pause)
| WU (wake up)
| control
|-
| 14h
|colspan="3"| - !!! - (NEVER ever change this registers)
|colspan="2"|[[#Range|range (+/-2/4/8g)]]
|colspan="3"|[[#Bandwith|bandwith (25...1500 Hz)]]
| control
|-
| 13h
|colspan="8" rowspan="2"| customer reserved (can be used as memory)
| status
|-
| 12h
| status
|-
| 11h
|colspan="2"| AMD (any motion duration)
|colspan="3"| HGH (high gravitation hysteresis)
|colspan="3"| LGH (low gravitation hysteresis)
| settings
|-
| 10h
|colspan="8"| AMT (any motion threshold)
| settings
|-
| 0Fh
|colspan="8"| HGD (high gravitation duration)
| settings
|-
| 0Eh
|colspan="8"| HGT (high gravitation threshold)
| settings
|-
| 0Dh
|colspan="8"| LGD (low gravitation duration)
| settings
|-
| 0Ch
|colspan="8"| LGT (high gravitation threshold)
| settings
|-
| 0Bh
| alert
| AM (any motion)
|colspan="2"| HGC (high gravitation counter)
|colspan="2"| LGC (low gravitation counter)
| HGE (high gravitation enable)
| LGE (low gravitation enable)
| control
|-
| 0Ah
| -
| reset INT
| -
| -
| self test 1
| self test 2
| soft reset
| sleep
| control
|-
| 09h
| STR (self test result)
|colspan="2"| -
| alert phase
| LG latched
| HG latched
| HGS (high gravitation status)
| LGS (low gravitation status)
| status
|-
| 08h
|colspan="8"| -
| data
|-
| 07h
| Z [9]
| Z [8]
| Z [7]
| Z [6]
| Z [5]
| Z [4]
| Z [3]
| Z [2]
| data
|rowspan="2"| Z
|-
| 06h
| Z [1]
| Z [0]
|colspan="5"| -
| NDZ (new data Z)
| data
|-
| 05h
| Y [9]
| Y [8]
| Y [7]
| Y [6]
| Y [5]
| Y [4]
| Y [3]
| Y [2]
| data
|rowspan="2"| Y
|-
| 04h
| Y [1]
| Y [0]
|colspan="5"| -
| NDY (new data Y)
| data
|-
| 03h
| X [9]
| X [8]
| X [7]
| X [6]
| X [5]
| X [4]
| X [3]
| X [2]
| data
|rowspan="2"| X
|-
| 02h
| X [1]
| X [0]
|colspan="5"| -
| NDX (new data X)
| data
|-
| 01h
|colspan="4"| al version
|colspan="4"| ml version
| data
|rowspan="2"|
|-
| 00h
|colspan="5"| -
|colspan="3"| chip ID
| data
|}

==Register==
===Shadow disable===
Ist diese Bit gesetzt ist es möglich die MSBs der Beschleunigungswerte (03h, 05h, 07h) zu lesen ohne vorher die LSBs (02h, 04h, 06h) gelesen zu haben.
===Range===
Es sind 3 verschiedene Bereiche einstellbar:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Range'''
|-
!colspan="2"| 14h
!
|-
! Bit 4
! Bit 3
! Bereich
|-
| 0
| 0
| +/- 2g (default)
|-
| 0
| 1
| +/- 4g
|-
| 1
| 0
| +/- 8g
|-
| 1
| 1
| -
|}
===Bandwith===
Folgende Aktualisierungsraten sind möglich:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Bandwith'''
|-
!colspan="3"| 14h
!colspan="2"|
|-
! Bit 2
! Bit 1
! Bit 0
! Rate
! reale Rate
|-
| 0
| 0
| 0
| 25 Hz (default)
| 23 Hz
|-
| 0
| 0
| 1
| 50 Hz
| 47 Hz
|-
| 0
| 1
| 0
| 100 Hz
| 94 Hz
|-
| 0
| 1
| 1
| 190 Hz
| 188 Hz
|-
| 1
| 0
| 0
| 375 Hz
| 375 Hz
|-
| 1
| 0
| 1
| 750 Hz
| 750 Hz
|-
| 1
| 1
| 0
| 1500 Hz
| 1500 Hz
|-
| 1
| 1
| 1
| -
| -
|}

==Konfiguration==

==I2C==
===Adresse===
{| class="wikitable"
|+ '''I2C Adresse'''
|-
! Bit 7 || Bit 6 || Bit 5 || Bit 4 || Bit 3 || Bit 2 || Bit 1 || R/W
|-
| 0 || 1 || 1 || 1 || 0 || 0 || 0 || x
|}
====7 Bit Sichtweise====
Gemeint ist hierbei Bit 7 - 1.
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Hexadezimal || Dezimal
|-
| 0x38 || 56
|}
Zum lesen muss das 0. Bit gesetzt werden.

====8 Bit Sichtweise====
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Richtung || Hexadezimal || Dezimal
|-
| schreiben || 0x70 || 112
|-
| lesen || 0x71 || 113
|}

===Beschleunigungsdaten lesen===

Um Daten zu lesen muss erst der Offset gesendet werden ab dem Daten gelesen werden sollen. Die Beschleunigungsdaten liegen ab Adresse 0x02h.

{| class="wikitable"
|+ '''Offset senden'''
|-
! Richtung || Adresse || Daten
|-
| schreiben || 0x70 || 0x02
|}

Die Beschleunigungsdaten sind pro Achse (X, Y, Z) 10 Bit lang. Diese liegen in 6 Bytes ab Adresse 0x02h (0x02h - 0x08h). Siehe dazu den Abschnitt [[#Speicheraufteilung|Speicheraufteilung]].
Um an die Daten zu kommen muessen 6 Byte von der Adresse des BMA020 gelesen werden:
{| class="wikitable"
|+ ''' Beschleunigungsdaten lesen'''
|-
! Richtung || Adresse || Byte 1 || Byte 2 || Byte 3 || Byte 4 || Byte 5 || Byte 6
|-
| lesen || 0x71 || LSB_x || MSB_x || LSB_y || MSB_y || LSB_z || MSB_z
|}
==Berechnung==
===8 Bitwerte===
Sind die Beschleunigungswerte ausgelesen geht es nun an die Interpretation. Reicht eine Genauigkeit von 8 Bit so kann man nur den MSB-Teil der Werte nehmen.
Achtung: Es müssen dennoch die LSBs eingelesen werden, da die MSBs und LSBs solange blockiert bleiben bis beide eingelesen wurden.
Um dies zu verhindern muss das [[#Shadow disable|Shadow disable Bit]] gesetzt werden (15h, Bit 3; siehe [[#Speicheraufteilung|Speicheraufteilung]]).

===10 Bitwerte===
Hat man die Werte ausgelesen gilt es diese zusammen zu fügen. Im folgenden Beispiel wird angenommen das die Werte in der Variable <syntaxhighlight lang="c">values[]</syntaxhighlight> liegen. Die Variable enthält die 6 Bytes für X, Y und Z.

Als Beispiel wird hier X erzeugt (zusammengefügt).
<syntaxhighlight lang="c">
uint values[6];
int x;

//X MSB (02h) um zwei Stellen nach links schieben um Platz für die beiden unteren Bits zu schaffen.
x = values[0] << 2;

//X LSB (03h) um sechs Stellen nach rechts schieben um die zwei obersten Bits an den richtigen Platz für das Zusammenfügen zu bringen.
x = x | (values[1] >> 6);
</syntaxhighlight>

Selbiges muss für Y und Z getan werden.

===Gravitationsvektor===
Der Gravitationsvektor ergibt sich aus:
<math>\vec g = \begin{pmatrix} x \\ y \\ z \end{pmatrix}</math>
====Gravitation berechnen====
Die Gravitation ist gleich der Länge des Gravitationsvektors:
<math>g = \sqrt{x^2+y^2+z^2}</math>

[[Kategorie:Sensorik]]

RFID Antenne

2012-07-27T10:00:17Z

Muebau: /* Runde Antenne */

Hier eine Formalsammlung zu RFID-Antennen; aus dem Forum zusammengetragen.

== Runde Antenne ==

Die Induktivität der Antenne in µH:

<math>L [\mu H]=\frac{0.31\cdot(a\cdot N)^2}{6a+9h+10b}</math>

<math>a</math> = Antenneradius

<math>b</math> = Dicke der Wicklung

<math>h</math> = Höhe der Wicklung

<math>N</math> = Anzahl Wicklungen

Die Dicke und Höhe der Wicklung (b und h) sind unkritisch. Bei ca. 100 Windungen ist 0.5 ein guter Wert.

=== Antennengüte (Q) ===

Je höher die Güte einer Antenne ist, umso grösser ist der zu erwartende Strom.

Bei hoher Güte muss die Frequenz jedoch auch genauer stimmen. Mit 109 kHz wird man bei einer Güte von 30 im Normalfall keine Chance haben 125 kHz Tags auszulesen. Die Bandbreite des Signalempfangs ist direkt abhängig von der Güte.

<math>Q=\frac{2\pi\cdot f\cdot L}{R_\text{d}}</math>

<math>R_\text{d}</math> = Drahtwiderstand der Antenne

<math>f</math> = Resonanzfrequenz (hier 125kHz)

<math>L</math> = Induktivität in Henry (H)

=== Drahtwiderstand Rd ===

<math>R_\text{d}=2a/100 \cdot\pi \cdot N \cdot \frac \varrho{A_\text{d}}</math>

<math>a</math> = Antennenradius in cm

<math>N</math> = Windungen

<math>\varrho</math> = Spezifischer Widerstand (bei Kupferdraht <math>\varrho</math> ≈ 0.017 Ω·m)

<math>A_\text{d}</math>= Draht-Querschnittsfläche in mm2:
<math>A_\text{d}= \tfrac{d^2}4\pi</math>

<math>d</math> = Drahtdurchmesser in mm

=== Serienwiderstand ===

Durch den Serienwiderstand wird das <math>Q_\text{ges}</math> deutlich kleiner.

<math>Q_\text{ges} = \frac{2\pi\cdot f\cdot L}{R_\text{d}+R_\text{s}+2R_\text{ad}}</math>

<math>R_\text{d}</math> = Drahtwiderstand der Antenne

<math>R_\text{s}</math> = Seriewiderstand zur Antenne

<math>R_\text{ad}</math> = Antennentreiber-Widerstand (Beim EM4095 Rad ≈ 3Ω)

===Antennendurchmesser===

<math>r_\text{Antenne} = d_\text{max}\cdot \sqrt{2}</math>

<math>r_\text{Antenne}</math> = Radius der Antenne

<math>d_\text{max}</math> = maximaler Leseabstand von Tag und Antennenspule

Der optimale Radius der Sendeantenne entspricht dem Wuzel(2)-fachen Wert des maximal gewünschten Leseabstandes. Dabei ist aber zu beachten, dass das maximale Feld (ist immer im Zentrum der Antenne) dadurch proportional immer kleiner wird. Hier muss also irgendwo die optimale Mitte gefunden werden. Ideal wäre es wenn man die minimal nötige Ansprechfeldstärke des Transponders wüsste, welche aber leider meist nicht angegeben ist.

== Bandbreite ==

Die Bandbreite des Signalempfangs ist direkt abhängig von der Güte. Für
die Empfangsbandbreite eines LC-Glieds gilt:

<math>B=\frac{f}{Q}</math>

<math>f</math> = Resonanzfrequenz (hier 125kHz)

<math>Q</math> = Antennengüte

=== Rechnung ===

Bei <math>Q=40</math> und <math>f=125</math> kHz bekommt man

: <math>B=3.125</math> kHz

Dies bedeutet, dass man bei einer Frequenzabweichung von ±1.56kHz zu 125kHz bereits nur noch –3db (die Hälfte) des maximal möglichen Signals "empfangen" würde.

== Links ==

* http://www.spulen.com/shop/product_info.php?products_id=925

[[Kategorie:RFID]]

RFID Antenne

2012-07-25T15:58:46Z

Muebau:

Hier mal die gesammelte Mathematik zu RFID Antennen aus dem Forum zusammen getragen.

=Runde Antenne=
Die Antenne in (micro) Henry:

<math>L( \mu H)=\frac{0.31*(a*N)^2}{6*a+9*h+10*b}</math>

<math>a</math> = Antenneradius in cm

<math>b</math> = Dicke der Wicklung in cm

<math>h</math> = Höhe der Wicklung in cm

<math>N</math> = Anzahl Wicklungen

Die Dicke und Höhe der Wicklung (b und h) sind unkritisch. Bei ca. 100 Windungen sind 0.5 ein guter Wert.

=Antennengüte (Q)=
Je höher die Güte einer Antenne ist, umso grösser ist der zu erwartende Strom.

Bei hoher Güte muss die Frequenz jedoch auch genauer stimmen. Mit 109kHz wird man bei einer Güte von 30 im Normalfall keine Chance haben 125kHz Tags auszulesen. Die Bandbreite des Signalempfangs ist direkt abhängig von der Güte.

<math>Q=\frac{2*\pi*f*L}{R_\text{d}}</math>

<math>R_\text{d}</math> = Drahtwiderstand der Antenne

<math>f</math> = Resonanzfrequenz (hier 125kHz)

<math>L</math> = Induktivität in Henry (H)

==Drahtwiderstand <math>R_\text{d}</math>==
<math>R_\text{d}=2*a/100*\pi*N*p/(Ad(mm))</math>

<math>a</math> = Antennenradius in cm

<math>N</math> = Windungen

<math>p</math> = spezifischer Widerstand (bei Kupferdraht p = 0.017)

<math>A_\text{d}</math>= Draht Querschnittsfläche in mm
===Querschnittsfläche <math>A_\text{d}</math>===
<math>A_\text{d}= (\frac{d}{2})^2*\pi</math>

<math>d</math> = Drahtdurchmesser in mm
==Serienwiderstand==
Durch den Serienwiderstand wird das <math>Q_\text{ges}</math> deutlich kleiner.

<math>Q_\text{ges} = \frac{2*\pi*f*L}{R_\text{d}+R_\text{s}+2*R_\text{ad}}</math>

<math>R_\text{d}</math> = Drahtwiderstand der Antenne

<math>R_\text{s}</math> = Seriewiderstand zur Antenne

<math>R_\text{ad}</math> = Antennentreiber-Widerstand (Beim EM4095 Rad = ca. 3)

=Bandbreite=
Die Bandbreite des Signalempfangs ist direkt abhängig von der Güte. Für
die Empfangsbandbreite eines LC-Glieds gilt:

<math>B=\frac{f}{Q}</math>

<math>f</math> = Resonanzfrequenz (hier 125kHz)

<math>Q</math> = Antennengüte

==Rechnung==

Bei

<math>Q=40</math>

<math>f=125 kHz</math>

bekommt man

<math>B=3.125kHz</math>

Dies bedeutet, dass man bei einer Frequenzabweichung von +/- 1.56kHz zu 125kHz bereits nur noch -3db (die Hälfte) des maximal möglichen Signals "empfangen" würde.

=Links=
http://www.spulen.com/shop/product_info.php?products_id=925

RFID Antenne

2012-07-25T15:56:00Z

Muebau:

RFID Antenne

2012-07-25T15:52:37Z

Muebau: /* RFID Antenne */

Hier mal die gesammelte Mathematik zu RFID Antennen aus dem Forum zusammen getragen.

=Runde Antenne=
Die Antenne in (micro) Henry:

<math>L( \mu H)=\frac{0.31*(a*N)^2}{6*a+9*h+10*b}</math>

<math>a</math> = Antenneradius in cm

<math>b</math> = Dicke der Wicklung in cm

<math>h</math> = Höhe der Wicklung in cm

<math>N</math> = Anzahl Wicklungen

Die Dicke und Höhe der Wicklung (b und h) sind unkritisch. Bei ca. 100 Windungen sind 0.5 ein guter Wert.

=Antennengüte (Q)=
Je höher die Güte einer Antenne ist, umso grösser ist der zu erwartende Strom.

Bei hoher Güte muss die Frequenz jedoch auch genauer stimmen. Mit 109kHz wird man bei einer Güte von 30 im Normalfall keine Chance haben 125kHz Tags auszulesen. Die Bandbreite des Signalempfangs ist direkt abhängig von der Güte.

<math>Q=\frac{2*\pi*f*L}{Rd}</math>

<math>R_\text{d}</math> = Drahtwiderstand der Antenne

<math>f</math> = Resonanzfrequenz (hier 125kHz)

<math>L</math> = Induktivität in Henry (H)

==Drahtwiderstand <math>R_\text{d}</math>==
<math>R_\text{d}=2*a/100*\pi*N*p/(Ad(mm))</math>

<math>a</math> = Antennenradius in cm

<math>N</math> = Windungen

<math>p</math> = spezifischer Widerstand (bei Kupferdraht p = 0.017)

<math>A_\text{d}</math>= Draht Querschnittsfläche in mm
===Querschnittsfläche <math>A_\text{d}</math>===
<math>A_\text{d}= (d/2)^2*\pi</math>

<math>d</math> = Drahtdurchmesser in mm
==Serienwiderstand==
Durch den Serienwiderstand wird das <math>Q_\text{ges}</math> deutlich kleiner.

<math>Q_\text{ges} = \frac{2*\pi*f*L}{R_\text{d}+R_\text{s}+2*R_\text{ad}}</math>

<math>R_\text{d}</math> = Drahtwiderstand der Antenne

<math>R_\text{s}</math> = Seriewiderstand zur Antenne

<math>R_\text{ad}</math> = Antennentreiber-Widerstand (Beim EM4095 Rad = ca. 3)

=Bandbreite=
Die Bandbreite des Signalempfangs ist direkt abhängig von der Güte. Für
die Empfangsbandbreite eines LC-Glieds gilt:

<math>B=\frac{f}{Q}</math>

<math>f</math> = Resonanzfrequenz (hier 125kHz)

<math>Q</math> = Antennengüte

==Rechnung==

Bei

<math>Q=40</math>

<math>f=125 kHz</math>

bekommt man

<math>B=3.125kHz</math>

Dies bedeutet, dass man bei einer Frequenzabweichung von +/- 1.56kHz zu 125kHz bereits nur noch -3db (die Hälfte) des maximal möglichen Signals "empfangen" würde.

<math>g = \sqrt{x^2+y^2+z^2}</math>

RFID Antenne

2012-07-25T15:51:32Z

Muebau: Die Seite wurde neu angelegt: „=RFID Antenne= Hier mal die gesammelte Mathematik zu RFID Antennen aus dem Forum zusammen getragen. ==Runde Antenne== Die Antenne in (micro) Henry: <math>L( \mu…“

=RFID Antenne=
Hier mal die gesammelte Mathematik zu RFID Antennen aus dem Forum zusammen getragen.

==Runde Antenne==
Die Antenne in (micro) Henry:

<math>L( \mu H)=\frac{0.31*(a*N)^2}{6*a+9*h+10*b}</math>

<math>a</math> = Antenneradius in cm

<math>b</math> = Dicke der Wicklung in cm

<math>h</math> = Höhe der Wicklung in cm

<math>N</math> = Anzahl Wicklungen

Die Dicke und Höhe der Wicklung (b und h) sind unkritisch. Bei ca. 100 Windungen sind 0.5 ein guter Wert.

==Antennengüte (Q)==
Je höher die Güte einer Antenne ist, umso grösser ist der zu erwartende Strom.

Bei hoher Güte muss die Frequenz jedoch auch genauer stimmen. Mit 109kHz wird man bei einer Güte von 30 im Normalfall keine Chance haben 125kHz Tags auszulesen. Die Bandbreite des Signalempfangs ist direkt abhängig von der Güte.

<math>Q=\frac{2*\pi*f*L}{Rd}</math>

<math>R_\text{d}</math> = Drahtwiderstand der Antenne

<math>f</math> = Resonanzfrequenz (hier 125kHz)

<math>L</math> = Induktivität in Henry (H)

===Drahtwiderstand <math>R_\text{d}</math>===
<math>R_\text{d}=2*a/100*\pi*N*p/(Ad(mm))</math>

<math>a</math> = Antennenradius in cm

<math>N</math> = Windungen

<math>p</math> = spezifischer Widerstand (bei Kupferdraht p = 0.017)

<math>A_\text{d}</math>= Draht Querschnittsfläche in mm
====Querschnittsfläche <math>A_\text{d}</math>====
<math>A_\text{d}= (d/2)^2*\pi</math>

<math>d</math> = Drahtdurchmesser in mm
===Serienwiderstand===
Durch den Serienwiderstand wird das <math>Q_\text{ges}</math> deutlich kleiner.

<math>Q_\text{ges} = \frac{2*\pi*f*L}{R_\text{d}+R_\text{s}+2*R_\text{ad}}</math>

<math>R_\text{d}</math> = Drahtwiderstand der Antenne

<math>R_\text{s}</math> = Seriewiderstand zur Antenne

<math>R_\text{ad}</math> = Antennentreiber-Widerstand (Beim EM4095 Rad = ca. 3)

==Bandbreite==
Die Bandbreite des Signalempfangs ist direkt abhängig von der Güte. Für
die Empfangsbandbreite eines LC-Glieds gilt:

<math>B=\frac{f}{Q}</math>

<math>f</math> = Resonanzfrequenz (hier 125kHz)

<math>Q</math> = Antennengüte

===Rechnung===

Bei

<math>Q=40</math>

<math>f=125 kHz</math>

bekommt man

<math>B=3.125kHz</math>

Dies bedeutet, dass man bei einer Frequenzabweichung von +/- 1.56kHz zu 125kHz bereits nur noch -3db (die Hälfte) des maximal möglichen Signals "empfangen" würde.

<math>g = \sqrt{x^2+y^2+z^2}</math>

IRMP

2012-05-28T10:06:50Z

Muebau: /* Einleitung */

Von '''Frank M. ([http://www.mikrocontroller.net/user/show/ukw ukw])'''

= IRMP - Infrarot-Multiprotokoll-Decoder =

[[Datei:irmp-title.png| |Scan eines NEC-kompatiblen Fernbedienungssignals]]

== Einleitung ==

[[Datei:IRMP-TSOP1736.png|miniatur|Anschluß eines IR-Empfängers an µC]]

Da RC5 nicht nur veraltet, sondern mittlerweile obsolet ist und immer mehr die elektronischen Geräte der fernöstlichen Unterhaltungsindustrie in unseren Haushalten Einzug finden, ist es an der Zeit, einen IR-Decoder zu entwickeln, der ca. 90% aller bei uns im täglichen Leben zu findenden IR-Fernbedienungen "versteht".

IRMP ist lauffähig auf folgenden AVR µCs:

* ATtiny45, ATtiny85
* ATtiny84
* ATmega8, ATmega16, ATmega32
* ATmega162
* ATmega164, ATmega324, ATmega644, ATmega644P, ATmega1284
* ATmega88, ATmega88P, ATmega168, ATmega168P, ATmega328P

Es gibt aber auch Portierungen auf diverse PIC µCs - für den CCS- und C18-Compiler. Auch ist IRMP mittlerweile auf ARM STM32 lauffähig.

IRMP - der Infrarot-Fernbedienungsdecoder, der mehrere Protokolle auf einmal decodieren kann, beherrscht folgende Protokolle:

{| class="wikitable"
! Protokoll || Hersteller
|-
| SIRCS || Sony
|-
| NEC || NEC, Yamaha, Canon, Tevion, Harman/Kardon, Hitachi, JVC, Pioneer, Toshiba, Xoro, Orion, NoName und viele weitere japanische Hersteller.
|-
| SAMSUNG || Samsung
|-
| SAMSUNG32 || Samsung
|-
| MATSUSHITA || Matsushita
|-
| KASEIKYO || Panasonic, Technics, Denon und andere japanische Hersteller, welche Mitglied der "Japan's Association for Electric Home Application" sind.
|-
| RECS80 || Philips, Nokia, Thomson, Nordmende, Telefunken, Saba
|-
| RECS80EXT || Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
|-
| RC5 || Philips und andere europäische Hersteller
|-
| DENON || Denon, Sharp
|-
| RC6 || Philips und andere europäische Hersteller
|-
| RC6A || Philips, Kathrein und andere Hersteller, z.B. XBOX
|-
| APPLE || Apple
|-
| NUBERT || Nubert, z.B. Subwoofer System
|-
| B&O || Bang & Olufsen
|-
| GRUNDIG || Grundig
|-
| NOKIA || Nokia, z.B. D-Box
|-
| SIEMENS || Siemens, z.B. Gigaset M740AV (ab ~15kHz, siehe Bemerkungen zu F_INTERRUPTS)
|-
| FDC || FDC Keyboard (ab ~15kHz)
|-
| RCCAR || RC Car: IR Fernbedienung für Modellfahrzeuge
|-
| JVC || JVC
|-
| NIKON || NIKON
|-
| RUWIDO || RUWIDO (z.B. T-Home-Mediareceiver, MERLIN-Tastatur (Pollin))
|-
| KATHREIN || KATHREIN
|-
| NEC16 || JVC
|-
| NEC42 || JVC
|-
| LEGO || Lego
|-
| THOMSON || Thomson
|}

Jedes dieser Protokolle ist einzeln aktivierbar. Wer möchte, kann alle Protokolle aktivieren. Wer nur ein Protokoll braucht, kann alle anderen deaktivieren. Es wird nur das vom Compiler übersetzt, was auch benötigt wird.

Der auf AVR- und PIC-µCs einsetzbare Source zu IRMP entstand im Rahmen des [[Word Clock]] Projektes.

'''Anlass für einen eigenen IRMP-Artikel ist folgender Thread in der Codesammlung: [http://www.mikrocontroller.net/topic/162119 Beitrag: IRMP - Infrared Multi Protocol Decoder]'''

== Protokolle ==

[[Datei:nec-protocol.png|miniatur|NEC-Protokoll, Reichelt RGB-LED-Fernbedienung, T->A: 9,14ms, A->B: 4,42ms, B->C: 660us]]

Einige Hersteller verwenden ihr eigenes Protokoll, dazu gehören u.a. Sony, Samsung und Matsushita. Philips hat RC5 entwickelt und natürlich auch selbst benutzt. RC5 galt damals in Europa als ''das'' Standard-IR-Protokoll, welches von vielen europäischen Herstellern übernommen wurde. Mittlerweile ist RC5 fast gar nicht mehr anzutreffen - man kann es eigentlich als "ausgestorben" abhaken.

Auch die japanischen Hersteller haben versucht, einen eigenen Standard zu etablieren, nämlich das sog. Kaseikyo- (oder auch "Japan-") Protokoll. Dieses ist mit einer Bitlänge von 48 sehr universell und allgemein verwendbar. Richtig durchgesetzt hat es sich aber bis heute nicht. Ich selbst habe jedenfalls noch keine einzige Fernbedienung gesehen, die das Kaseikyo-Protokoll nutzt.

Heutzutage wird vornehmlich das NEC-Protokoll verwendet - und zwar von den unterschiedlichsten (Marken- und auch Noname-)Herstellern. Ich schätze den "Marktanteil" auf ca. 80% beim NEC-Protokoll. Fast alle Fernbedienungen im alltäglichen Einsatz verwenden bei mir den NEC-IR-Code. Das fängt beim Fernseher an, geht über vom DVD-Player zur Notebook-Fernbedienung und reicht bis zur Noname-MultiMedia-Festplatte - um nur einige Beispiele zu nennen.

Die von IRMP decodierten Protokolle haben etwas gemeinsames: Sie weisen alle ein Start-Bit auf, welches vom Timing her ausgezeichnet, d.h. einmalig ist.

Anhand dieses Start-Bit-Timings werden die verschiedenen Protokolle unterschieden. IRMP misst also das Timing des Start-Bits und stellt dann "on-thy-fly" seine Timingtabellen auf das erkannte Protokoll um, damit die nach dem Start-Bit gesandten Daten in einem Rutsch eingelesen werden können, ohne das komplette Telegramm (Frame) erst speichern zu müssen.

IRMP unterstützt folgende IR-Codings:

* '''Pulse Distance''', typ. Beispiel: NEC, Sony
* '''Bi-Phase''' (Manchester), typ. Beispiel: RC5, RC6
* '''Serial''' (ab 1.9.5), typ. Beispiel: Netbox

Ein '''Puls-Distance-Protokoll''' erkennt man an folgenden Regeln:

* es gibt nur '''eine Pulslänge''' und '''zwei verschiedene Pausenlängen''' oder

* es gibt '''zwei verschiedene Pulslängen''' und nur '''eine Pausenlänge'''

Ein '''Bi-Phase-Protokoll''' erkennt man an:

* es kommen genau '''eine''' Pausen- und eine Pulslänge, sowie jeweils die '''doppelten''' Puls-/Pausenlängen vor

Typisches Kriterium für ein '''bitserielles Protokoll''' ist:

* es kommen '''Vielfache''' einer Grund-Puls-/Pausenlänge vor

'''Eine tabellarische Aufstellung der verschiedenen IR-Protokolle findet man hier: [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Die IR-Protokolle im Detail].'''

Die angegebenen Timingwerte sind Idealwerte. Bei einigen Fernbedienungen in der Praxis weichen sie um bis zu 40% voneinander ab. Deshalb arbeitet IRMP mit Minimum-/Maximumsgrenzen, um bzgl. des Zeitverhaltens tolerabel zu sein.

== Download ==

Version 2.2.0, Stand vom 23.05.2012

Download Release-Version: [http://www.mikrocontroller.net/wikifiles/7/79/Irmp.zip Irmp.zip]

IRMP & IRSND sind nun auch über SVN abrufbar: [http://www.mikrocontroller.net/svnbrowser/irmp/ IRMP im SVN], Download [http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar Tarball]

'''Achtung:'''

Die Version im SVN kann eine Zwischen- oder Test-Version sein, die nicht den hier dokumentierten Stand widerspiegelt! Im Zweifel verwendet man besser den obigen Download-Link auf Irmp.zip.

'''Die Software-Änderungen kann man sich hier anschauen: [http://www.mikrocontroller.net/articles/IRMP#Software-Historie_IRMP Software-Historie IRMP]'''

== Source-Code ==

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man unter Windows die Projekt-Datei irmp.aps in das AVR Studio 4 lädt.

Für andere Entwicklungsumgebungen ist leicht ein Projekt bzw. Makefile angelegt. Zum Source gehören:

* irmp.c - Der eigentliche IR-Decoder
* irmpprotocols.h - Sämtliche Definitionen zu den IR-Protokollen
* irmpsystem.h - Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32
* irmp.h - Include-Datei für die Applikation
* irmpconfig.h - Anzupassende Konfigurationsdatei

'''WICHTIG'''

'''Im Applikations-Source sollte nur irmp.h per include eingefügt werden, also lediglich:'''

<c>
#include "irmp.h"
</c>

Alle anderen Include-Dateien werden automatisch über irmp.h "eingefügt". Siehe dazu auch die Beispieldatei main.c.

Auch auf PIC-Prozessoren ist IRMP lauffähig. Für den PIC-CCS-Compiler sind entsprechende Preprocessor-Konstanten bereits gesetzt, so dass man irmp.c direkt in der CCS-Entwicklungsumgebung verwenden kann. Lediglich eine kleine Interrupt-Routine wie

<c>
void TIMER2_isr(void)
{
irmp_ISR ();
}
</c>

ist hinzuzufügen, wobei man den Interrupt auf 66µs (also 15kHz) stellt.

Für AVR-Prozessoren ist ein Beispiel für die Anwendung von IRMP in main.c zu finden - im wesentlichen geht es da um die Timer-Initialisierung und den Abruf der empfangenen IR-Telegramme.

Ebenso läuft IRMP mittlerweile auf STM32-Mikroprozessoren.

Die Konfiguration von IRMP wird über Parameter in irmpconfig.h vorgenommen, nämlich:

* Anzahl Interrupts pro Sekunde
* Unterstützte IR-Protokolle
* Hardware-Pin zum IR-Empfänger
* IR-Logging

=== Einstellungen in irmpconfig.h ===

IRMP decodiert sämtliche oben aufgelisteten Protokolle in einer ISR, siehe irmpconfig.h. Dafür sind einige Angaben nötig. Diese werden in irmpconfig.h eingestellt.

'''F_INTERRUPTS'''

Anzahl der Interrupts pro Sekunde. Der Wert kann zwischen 10000 und 20000 eingestellt werden.

Standardwert:
<c>
#define F_INTERRUPTS 15000 // interrupts per second
</c>

'''IRMP_SUPPORT_xxx_PROTOCOL'''

Hier lässt sich einstellen, welche Protokolle von IRMP unterstützt werden sollen. Die Standardprotokolle sind bereits aktiv. Möchte man weitere Protokolle einschalten bzw. einige aus Speicherplatzgründen deaktivieren, sind die entsprechenden Werte in irmpconfig.h anzupassen.

<c>
// typical protocols, disable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 ~150 bytes
#define IRMP_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 ~300 bytes
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 ~300 bytes
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 ~50 bytes
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 ~250 bytes
#define IRMP_SUPPORT_DENON_PROTOCOL 1 // DENON, Sharp >= 10000 ~250 bytes

// more protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_RC5_PROTOCOL 0 // RC5 >= 10000 ~250 bytes
#define IRMP_SUPPORT_RC6_PROTOCOL 0 // RC6 & RC6A >= 10000 ~250 bytes
#define IRMP_SUPPORT_JVC_PROTOCOL 0 // JVC >= 10000 ~150 bytes
#define IRMP_SUPPORT_NEC16_PROTOCOL 0 // NEC16 >= 10000 ~100 bytes
#define IRMP_SUPPORT_NEC42_PROTOCOL 0 // NEC42 >= 10000 ~300 bytes
#define IRMP_SUPPORT_IR60_PROTOCOL 0 // IR60 (SDA2008) >= 10000 ~300 bytes
#define IRMP_SUPPORT_GRUNDIG_PROTOCOL 0 // Grundig >= 10000 ~300 bytes
#define IRMP_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens Gigaset >= 15000 ~550 bytes
#define IRMP_SUPPORT_NOKIA_PROTOCOL 0 // Nokia >= 10000 ~300 bytes

// exotic protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_KATHREIN_PROTOCOL 0 // Kathrein >= 10000 ~200 bytes
#define IRMP_SUPPORT_NUBERT_PROTOCOL 0 // NUBERT >= 10000 ~50 bytes
#define IRMP_SUPPORT_BANG_OLUFSEN_PROTOCOL 0 // Bang & Olufsen >= 10000 ~200 bytes
#define IRMP_SUPPORT_RECS80_PROTOCOL 0 // RECS80 (SAA3004) >= 15000 ~50 bytes
#define IRMP_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT (SAA3008) >= 15000 ~50 bytes
#define IRMP_SUPPORT_THOMSON_PROTOCOL 0 // Thomson >= 10000 ~250 bytes
#define IRMP_SUPPORT_NIKON_PROTOCOL 0 // NIKON camera >= 10000 ~250 bytes
#define IRMP_SUPPORT_NETBOX_PROTOCOL 0 // Netbox keyboard >= 10000 ~400 bytes (PROTOTYPE!)
#define IRMP_SUPPORT_FDC_PROTOCOL 0 // FDC3402 keyboard >= 10000 (better 15000) ~150 bytes (~400 in combination with RC5)
#define IRMP_SUPPORT_RCCAR_PROTOCOL 0 // RC Car >= 10000 (better 15000) ~150 bytes (~500 in combination with RC5)
#define IRMP_SUPPORT_RUWIDO_PROTOCOL 0 // RUWIDO, T-Home >= 15000 ~550 bytes
#define IRMP_SUPPORT_LEGO_PROTOCOL 0 // LEGO Power RC >= 20000 ~150 bytes
</c>

Jedes von IRMP unterstützte IR-Protokoll "verbrät" ungefähr den oben angegebenen Speicher an Code. Hier kann man Optimierungen vornehmen: Zum Beispiel ist die Modulationsfrequenz von 455kHz beim B&O-Protokoll weitab von den Frequenzen, die von den anderen Protokollen verwendet werden. Hier braucht man evtl. andere IR-Empfänger, anderenfalls kann man diese Protokolle einfach deaktiveren. Zum Beispiel kann man mit einem TSOP1738 kein B&O-Protokoll (455kHz) mehr empfangen.

Ausserdem werden die Protokolle SIEMENS/FDC/RCCAR erst ab einer Scan-Frequenz von ca. 15kHz zuverlässig erkannt. Bei RECS80/REC80EXT sind es sogar 20kHz. Wenn man also diese Protokolle nutzen will, muss man F_INTERRUPTS entsprechend anpassen, sonst erscheint beim Übersetzen eine entsprechende Warnung und die entsprechenden Protokolle werden dann automatisch abgeschaltet.

'''IRMP_PORT_LETTER''' 
'''IRMP_BIT_NUMBER''' 

Über diese Konstanten wird der Pin am µC beschrieben, an welchem der IR-Empfänger angeschlossen ist.

Standardwert ist PORT B6:
<c>
/*---------------------------------------------------------------------------
* Change hardware pin here for ATMEL AVR
*---------------------------------------------------------------------------
*/
#if defined (ATMEL_AVR) // use PB6 as IR input on AVR
# define IRMP_PORT_LETTER B
# define IRMP_BIT_NUMBER 6
</c>

Diese beiden Werte sind an den tatsächlichen Hardware-Pin des µCs anzupassen.

Dies gilt ebenso für die STM32-µCs:

<c>
/*----------------------------------------------------------------------------
* Change hardware pin here for ARM STM32
*----------------------------------------------------------------------------
*/
#elif defined (ARM_STM32) // use C13 as IR input on STM32
# define IRMP_PORT_LETTER C
# define IRMP_BIT_NUMBER 13
</c>

Bei den PIC-Prozessoren gibt es lediglich die anzupassende Konstante '''IRMP_PIN''' - je nach Compiler:

<c>
/*----------------------------------------------------------------------------
* Change hardware pin here for PIC C18 compiler
*----------------------------------------------------------------------------
*/
#elif defined (PIC_C18) // use RB4 as IR input on PIC
# define IRMP_PIN PORTBbits.RB4

/*----------------------------------------------------------------------------
* Change hardware pin here for PIC CCS compiler
*----------------------------------------------------------------------------
*/
#elif defined (PIC_CCS) // use PB4 as IR input on PIC
# define IRMP_PIN PIN_B4
</c>

=== Anwendung von IRMP ===

Die von IRMP unterstützten Protokolle weisen Bitlängen - teilweise variabel, teilweise fest - von 12 bis 48 Bit auf. Diese werden über Preprocessor-Defines beschrieben.

IRMP trennt diese IR-Telegramme prinzipiell in 3 Bereiche:

1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando

Mittels der Funktion

irmp_get_data (IRMP_DATA * irmp_data_p)

kann man ein decodiertes Telegramm abrufen. Der Return-Wert ist 1, wenn ein Telegramm eingelesen wurde, sonst 0. Im ersten Fall werden die Struct-Members

<c>
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
irmp_data_p->flags
</c>

gefüllt.

Das heisst: am Ende bekommt man dann über irmp_get_data() einfach drei
Werte (Protokoll, Adresse und Kommando-Code), die man über ein if oder switch checken kann, z. B. hier eine Routine, welche die Tasten 1-9 auf einer Fernbedienung auswertet:

<c>
IRMP_DATA irmp_data;

if (irmp_get_data (&irmp_data))
{
if (irmp_data.protocol == IRMP_NEC_PROTOCOL && // NEC-Protokoll
irmp_data.address == 0x1234) // Adresse 0x1234
{
switch (irmp_data.command)
{
case 0x0001: key1_pressed(); break; // Taste 1
case 0x0002: key2_pressed(); break; // Taste 2
...
case 0x0009: key9_pressed(); break; // Taste 9
}
}
}
</c>

Hier die möglichen Werte für irmp_data.protocol, siehe auch irmp.h:

<c>
#define IRMP_SIRCS_PROTOCOL 1 // Sony
#define IRMP_NEC_PROTOCOL 2 // NEC, Pioneer, JVC, Toshiba, NoName etc.
#define IRMP_SAMSUNG_PROTOCOL 3 // Samsung
#define IRMP_MATSUSHITA_PROTOCOL 4 // Matsushita
#define IRMP_KASEIKYO_PROTOCOL 5 // Kaseikyo (Panasonic etc)
#define IRMP_RECS80_PROTOCOL 6 // Philips, Thomson, Nordmende, Telefunken, Saba
#define IRMP_RC5_PROTOCOL 7 // Philips etc
#define IRMP_DENON_PROTOCOL 8 // Denon, Sharp
#define IRMP_RC6_PROTOCOL 9 // Philips etc
#define IRMP_SAMSUNG32_PROTOCOL 10 // Samsung32: no sync pulse at bit 16, length 32 instead of 37
#define IRMP_APPLE_PROTOCOL 11 // Apple, very similar to NEC
#define IRMP_RECS80EXT_PROTOCOL 12 // Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
#define IRMP_NUBERT_PROTOCOL 13 // Nubert
#define IRMP_BANG_OLUFSEN_PROTOCOL 14 // Bang & Olufsen
#define IRMP_GRUNDIG_PROTOCOL 15 // Grundig
#define IRMP_NOKIA_PROTOCOL 16 // Nokia
#define IRMP_SIEMENS_PROTOCOL 17 // Siemens, e.g. Gigaset
#define IRMP_FDC_PROTOCOL 18 // FDC keyboard
#define IRMP_RCCAR_PROTOCOL 19 // RC Car
#define IRMP_JVC_PROTOCOL 20 // JVC (NEC with 16 bits)
#define IRMP_RC6A_PROTOCOL 21 // RC6A, e.g. Kathrein, XBOX
#define IRMP_NIKON_PROTOCOL 22 // Nikon
#define IRMP_RUWIDO_PROTOCOL 23 // Ruwido, e.g. T-Home Mediareceiver
#define IRMP_IR60_PROTOCOL 24 // IR60 (SDA2008)
#define IRMP_KATHREIN_PROTOCOL 25 // Kathrein
#define IRMP_NETBOX_PROTOCOL 26 // Netbox keyboard (bitserial)
#define IRMP_NEC16_PROTOCOL 27 // NEC with 16 bits (incl. sync)
#define IRMP_NEC42_PROTOCOL 28 // NEC with 42 bits
#define IRMP_LEGO_PROTOCOL 29 // LEGO Power Functions RC
#define IRMP_THOMSON_PROTOCOL 30 // Thomson
</c>

Die Werte für die Adresse und das Kommando muss man natürlich einmal für eine unbekannte Fernbedienung auslesen und dann über ein UART oder LC-Display ausgeben, um sie dann im Programm hart zu kodieren. Oder man hat eine kleine Anlernroutine, wo man einmal die gewünschten Tasten drücken muss, um sie anschließend im EEPROM abzuspeichern. Ein Beispiel dazu findet man im Artikel [http://www.mikrocontroller.net/articles/DIY_Lernfähige_Fernbedienung_mit_IRMP Lernfähige IR-Fernbedienung mit IRMP].

Eine weitere Beispiel-Main-Funktion ist im Zip-File enthalten, da sieht man dann auch die Initialisierung des Timers.

=== "Entprellen" von Tasten ===

Um zu unterscheiden, ob eine Taste lange gedrückt wurde oder lediglich einzeln, dient das Bit IRMP_FLAG_REPETITION. Dieses wird im Struct-Member '''flags''' gesetzt, wenn eine Taste auf der Fernbedienung längere Zeit gedrückt wurde und dadurch immer wieder dasselbe Kommando innerhalb kurzer Zeitabstände ausgesandt wird.

Beispiel:

<c>
if (irmp_data.flags & IRMP_FLAG_REPETITION)
{
// Benutzer hält die Taste länger runter
// entweder:
// ich ignoriere die (Wiederholungs-)Taste
// oder:
// ich benutze diese Info, um einen Repeat-Effekt zu nutzen
}
else
{
// Es handelt sich um eine neue Taste
}
</c>

Dies kann zum Beispiel dafür genutzt werden, um die Tasten 0-9 zu "entprellen", indem man Kommandos mit gesetztem Bit IRMP_FLAG_REPETITION ignoriert. Bei dem Drücken auf die Tasten VOLUME+ oder VOLUME- kann die wiederholte Auswertung ein und desselben Kommandos aber durchaus gewünscht sein - zum Beispiel, um LEDs zu faden.

Wenn man nur Einzeltasten auswerten will, kann man obigen IF-Block reduzieren auf:

<c>
if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
{
// Es handelt sich um eine neue Taste
// ACTION!
}
</c>

== Arbeitsweise ==

Das "Working Horse" von IRMP ist die Interrupt Service Routine irmp_ISR() welche 15.000 mal pro Sekunde aufgerufen werden sollte. Weicht dieser Wert ab, muss die Preprocessor-Konstante F_INTERRUPTS in irmpconfig.h angepasst werden. Der Wert kann zwischen 10kHz und 20kHz eingestellt werden.

irmp_ISR detektiert zunächst die Länge und die Form des/der Startbits und ermittelt daraus das verwendete Protokoll. Sobald das Protokoll erkannt wurde, werden die weiter einzulesenden Bits parametrisiert, um dann möglichst effektiv in den weiteren Aufrufen das komplette IR-Telegramm einzulesen.

Um direkt Kritikern den Wind aus den Segeln zu nehmen:

Ich weiss, die ISR ist ziemlich groß. Aber da sie sich wie eine State Machine verhält, ist der tatsächlich ausgeführte Code pro Durchlauf relativ gering. Solange es "dunkel" ist (und das ist es ja die meiste Zeit ;-)) ist die aufgewendete Zeit sogar verschwindend gering. Im WordClock-Projekt werden mit ein- und demselben Timer 8 ISRs aufgerufen, davon ist die irmp_ISR() nur eine unter vielen. Bei mindestens 8 MHz CPU-Takt traten bisher keine Timing-Probleme auf. Daher sehe ich bei der Länge von irmp_ISR überhaupt kein Problem.

Ein Quarz ist nicht unbedingt notwendig, es funktioniert auch mit dem internen Oszillator des AVRs, wenn man die Prescaler-Fuse entsprechend gesetzt hat, dass die CPU auch mit 8MHz rennt ... Die Fuse-Werte für einen ATMEGA88 findet man in main.c.

== Scannen von unbekannten Protokollen ==

Stellt man in irmpconfig.h in der Zeile

<c>
#define IRMP_LOGGING 0 // 1: log IR signal (scan), 0: do not (default)
</c>

den Wert für IRMP_LOGGING auf 1, wird in IRMP eine Protokollierung eingeschaltet: Es werden dann die Hell- und Dunkelphase auf dem UART des Microntrollers mit 9600Bd ausgegeben: 1=Dunkel, 0=Hell. Eventuell müssen dann die Konstanten in den Funktionen uart_init() und uart_putc() angepasst werden; das kommt auf den verwendeten AVR-µC an.

'''Hinweis: Die IRMP-Logging-Funktion (insb. die Ausgabe über UART) ist nicht für PIC-Prozessoren angepasst. Wer immer dies tun möchte, kann sich gerne bei mir (Benutzer [http://www.mikrocontroller.net/user/show/ukw ukw]) per PN melden.

Nimmt man diese Protokoll-Scans mit einem Terminal-Emulationsprogramm auf und speichert sie dann als normale Datei ab, kann man diese Scan-Dateien zur Analyse verwenden, um damit IRMP an das unbekannte Protokoll anzupassen - siehe nächstes Kapitel.

Wer eine Fernbedienung hat, die nicht von IRMP unterstützt wird, kann mir ([http://www.mikrocontroller.net/user/show/ukw ukw]) gern die Scan-Dateien zuschicken. Ich schaue dann, ob das Protokoll in das IRMP-Konzept passt und passe gegebenenfalls den Source an.

== IRMP unter Linux und Windows ==

irmp.c lässt sich auch unter Linux direkt kompilieren, um damit Infrarot-Scans, welche in Dateien gespeichert sind, direkt zu testen. Im Unterordner IR-Data finden sich solche Dateien, die man dem IRMP direkt zum "Fraß" vorwerfen kann.

Das Übersetzen von IRMP geht folgendermaßen:

make -f makefile.lnx

Dabei werden 3 IRMP-Versionen erzeugt:

* irmp: Version für 10kHz Scans
* irmp-15kHz: Version für 15kHz Scans
* irmp-20kHz: Version für 20kHz Scans

Der Aufruf geschieht dann über:

./irmp [-l|-p|-a|-v] < scan-file

Die angegebenen Optionen schließen sich aus, das heisst, es kann jeweils nur eine Option zu einer Zeit angegeben werden:

Option:

-l List gibt eine Liste der Pulse und Pausen aus
-a analyze analysiert die Puls-/Pausen und schreibt ein "Spektrum" in ASCII-Form
-v verbose ausführliche Ausgabe
-p Print Timings gibt für alle Protokolle eine Timing-Tabelle aus

Beispiele:

'''Normale Ausgabe:'''

./irmp < IR-Data/orion_vcr_07660BM070.txt

<c>
-------------------------------------------------------------------------
# Taste 1
00000001110111101000000001111111 p = 2, a = 0x7b80, c = 0x0001, f = 0x00
-------------------------------------------------------------------------
# Taste 2
00000001110111100100000010111111 p = 2, a = 0x7b80, c = 0x0002, f = 0x00
-------------------------------------------------------------------------
# Taste 3
00000001110111101100000000111111 p = 2, a = 0x7b80, c = 0x0003, f = 0x00
-------------------------------------------------------------------------
# Taste 4
00000001110111100010000011011111 p = 2, a = 0x7b80, c = 0x0004, f = 0x00
-------------------------------------------------------------------------
...
</c>

'''Listen-Ausgabe:'''

./irmp -l < IR-Data/orion_vcr_07660BM070.txt

<c>
# Taste 1
pulse: 91 pause: 44
pulse: 6 pause: 5
pulse: 6 pause: 6
pulse: 6 pause: 5
pulse: 6 pause: 5
pulse: 6 pause: 5
pulse: 6 pause: 6
pulse: 6 pause: 5
pulse: 6 pause: 16
...
</c>

'''Analyse:'''

./irmp -a < IR-Data/orion_vcr_07660BM070.txt

<c>
-------------------------------------------------------------------------------
START PULSES:
90 o 1
91 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 33
92 ooo 2
pulse avg: 91.0=9102.8 us, min: 90=9000.0 us, max: 92=9200.0 us, tol: 1.1%
-------------------------------------------------------------------------------
START PAUSES:
43 oo 1
44 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 25
45 oooooooooooooooooooooooo 10
pause avg: 44.2=4425.0 us, min: 43=4300.0 us, max: 45=4500.0 us, tol: 2.8%
-------------------------------------------------------------------------------
PULSES:
5 o 17
6 ooooooooooooooooooooooooooooooooooooooooooooooooooooooo 562
7 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 609
pulse avg: 6.5= 649.8 us, min: 5= 500.0 us, max: 7= 700.0 us, tol: 23.1%
-------------------------------------------------------------------------------
PAUSES:
4 ooooooooooooooooooooooo 169
5 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 412
6 oooo 31
pause avg: 4.8= 477.5 us, min: 4= 400.0 us, max: 6= 600.0 us, tol: 25.7%
15 oooooo 43
16 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 425
17 oooooooooo 72
pause avg: 16.1=1605.4 us, min: 15=1500.0 us, max: 17=1700.0 us, tol: 6.6%
-------------------------------------------------------------------------------
</c>

Hier sieht man die gemessenen Zeiten aller Pulse und Pausen als (liegende) Glockenkurven, welche natürlich wegen der ASCII-Darstellung nicht gerade einer Idealkurve entsprechen. Je schmaler die gemessenen Kanäle, desto besser ist das Timing der Fernbedienung.

Aus obigem Output kann man herauslesen:

* Das Start-Bit hat eine Pulslänge zwischen 9000 und 9200 usec, im Mittel sind es 9102 usec. Die Abweichung von diesem Mittelwert liegt bei 1,1 Prozent.

* Das Start-Bit hat eine Pausenlänge zwischen 4300 usec und 4500 usec, der Mittelwert beträgt 4424 usec. Der Fehler liegt bei 2,8 Prozent.

* Die Pulslänge eines Datenbits liegt zwischen 500 usec und 700 usec, im Mittel sind es 650 usec, der Fehler liegt bei (stolzen) 23,1 Prozent!

Desweiteren gibt es noch 2 verschieden lange Pausen (für die Bits 0 und 1), das Ablesen der Werte überlasse ich dem geneigten Leser ;-)

'''Ausführliche Ausgabe:'''

./irmp -v < IR-Data/orion_vcr_07660BM070.txt

<c>
-------------------------------------------------------------------------------
# Taste 1
26084 [starting pulse]
start-bit: pulse = 91, pause = 44
protocol = NEC, start bit timings: pulse: 53 - 127, pause: 26 - 64
pulse_1: 2 - 9
pause_1: 9 - 25
pulse_0: 2 - 9
pause_0: 2 - 9
command_offset: 16
command_len: 16
complete_len: 32
stop_bit: 1
26230 [bit 0: pulse = 6, pause = 5] 0
26242 [bit 1: pulse = 6, pause = 6] 0
26253 [bit 2: pulse = 6, pause = 5] 0
26264 [bit 3: pulse = 6, pause = 5] 0
...
26749 [bit 31: pulse = 6, pause = 17] 1
stop bit detected
code detected, length = 32
p = 2, a = 0x7b80, c = 0x0001, f = 0x00
-------------------------------------------------------------------------------
</c>

'''Timing-Tabelle:'''

./irmp -p

<c>
IRMP_TIMEOUT_LEN: 165
IRMP_KEY_REPETITION_LEN 1500

PROTOCOL S S-PULSE S-PAUSE PULSE-0 PAUSE-0 PULSE-1 PAUSE-1
====================================================================================
SIRCS 1 21 - 27 4 - 7 4 - 8 4 - 8 10 - 14 4 - 8
NEC 1 53 - 127 26 - 64 2 - 9 2 - 9 2 - 9 9 - 25
NEC (rep) 1 53 - 127 13 - 32 2 - 9 2 - 9 2 - 9 9 - 25
SAMSUNG 1 40 - 51 40 - 51 3 - 8 2 - 7 3 - 8 9 - 20
MATSUSHITA 1 27 - 43 27 - 43 4 - 13 4 - 13 4 - 13 15 - 38
KASEIKYO 1 29 - 38 14 - 20 1 - 8 1 - 7 1 - 8 5 - 20
RECS80 1 1 - 3 66 - 83 0 - 3 43 - 55 0 - 3 66 - 83
RC5 1 7 - 11 7 - 11 7 - 11
DENON 1 1 - 4 1 - 4 6 - 10 1 - 4 16 - 22
RC6 1 23 - 30 7 - 11 3 - 6
RECS80EXT 1 1 - 3 34 - 39 0 - 3 43 - 55 0 - 3 66 - 83
NUBERT 1 10 - 17 2 - 5 3 - 7 9 - 17 10 - 17 2 - 5
BANG_OLUFSEN 1 1 - 3 27 - 35
BANG_OLUFSEN 2 1 - 3 27 - 35
BANG_OLUFSEN 3 1 - 3 140 - 165
BANG_OLUFSEN 4 1 - 3 27 - 35
BANG_OLUFSEN - 1 - 3 27 - 35 1 - 3 83 - 104
GRUNDIG/NOKIA 1 3 - 7 22 - 33 3 - 7
SIEMENS 1 2 - 4 2 - 4 2 - 4
FDC 1 18 - 24 8 - 12 1 - 5 1 - 3 1 - 5 5 - 10
RCCAR 1 17 - 23 17 - 23 4 - 8 5 - 13 4 - 8 2 - 7
</c>

Bei längeren Ausgaben sollte man das Programm "less" verwenden, um seitenweise zu blättern, z.B.:

./irmp -v < IR-Data/Samsung_DVD_Rec_00062C.txt | less

Diese Scan-Dateien halfen mir nicht nur bei der Entwicklung des IRMP, sondern können auch bei der Anpassung des Sources an neue IR-Protokolle sehr hilfreich sein.

Mittlerweile kann man IRMP auch unter Windows nutzen, nämlich folgendermaßen:

* Eingabeaufforderung starten
* In das Verzeichnis irmp wechseln
* Aufruf von:
irmp.exe < IR-Data\rc5x.txt

Da manche Ausgaben sehr lang werden, empfiehlt es sich auch hier, die Ausgabe in eine Datei zu lenken oder in den more weiterzuleiten, damit man seitenweise blättern kann:

irmp.exe < IR-Data\rc5x.txt | more

Auch hier gelten dieselben Optionen wie für die Linux-Version.

Zusatz:

Der Decoder für das RECS80- und RECS80-Extended-Protokoll ist ungetestet, wurde anhand von Dokumentationen im Internet erstellt und lediglich mittels
künstlich erzeugten Scan-Dateien getestet... daher: keine Gewähr!

== Fernbedienungen ==

{| class="wikitable"
! Protokoll || Bezeichnung || Gerät || Device Address
|-
| NEC || Toshiba CT-9859 || Fernseher || 24384
|-
| || Toshiba VT-728G || V-728G Videorekorder || 23364
|-
| || Elta 8848 MP 4 || DVD-Player || 32512
|-
| || AS-218 || Askey TV-View CHP03X (TV-Karte) || 15238
|-
| || Cyberhome ??? || Cyberhome DVD Player || 28018
|-
| || WD TV Life || Western Digital Multimediaplayer || 7984
|-
| NEC16 || Daewoo || Videorekorder || 21
|-
| KASEIKYO || Technics EUR646497 || AV Receiver SA-AX 730 || 8194
|-
| RC5 || Loewe Assist/RC3/RC4 || Fernseher (FB auf TV-Mode) || 0
|-
| RC6 || Philips Television || Fernseher (FB auf TV-Mode) || 0
|-
| SIRCS || Sony RM-816 || Fernseher (FB auf TV-Mode) || 0 (siehe Beschreibung)
|-
| DENON || DENON RC970 || AVR3805 (Verstärker) || 8
|-
| || DENON RC970 || DVD/CD-Player || 2
|-
| || DENON RC970 || Tuner || 6
|-
| SAMSUNG32 || Samsung AA59-00484A || LE40D550 Fernseher || 1799
|-
|}

----

== IR-Tastaturen ==

[[Datei:irmp-fdc3402.jpg|miniatur|FDC-3402-Tastatur]]

IRMP unterstützt ab Version 1.7.0 auch IR-Tastaturen, nämlich die Infrarot-Tastatur FDC-3402 - erhältlich bei Pollin (Art. 711 056) für weniger als 2 EUR.

Beim Erkennen einer Taste gibt IRMP folgende Daten zurück:

Protokoll-Nummer (irmp_data.protocol): 18
Addresse (irmp_data.address): 0x003F

Als Kommando (irmp_data.command) werden folgende Werte zurückgeliefert:

{| class="wikitable"
! Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste
|-
| 0x0000 || || 0x0010 || TAB || 0x0020 || 's' || 0x0030 || 'c' || 0x0040 || || 0x0050 || HOME || 0x0060 || || 0x0070 || MENUE
|-
| 0x0001 || '^' || 0x0011 || 'q' || 0x0021 || 'd' || 0x0031 || 'v' || 0x0041 || || 0x0051 || END || 0x0061 || || 0x0071 || BACK
|-
| 0x0002 || '1' || 0x0012 || 'w' || 0x0022 || 'f' || 0x0032 || 'b' || 0x0042 || || 0x0052 || || 0x0062 || || 0x0072 || FORWARD
|-
| 0x0003 || '2' || 0x0013 || 'e' || 0x0023 || 'g' || 0x0033 || 'n' || 0x0043 || || 0x0053 || UP || 0x0063 || || 0x0073 || ADDRESS
|-
| 0x0004 || '3' || 0x0014 || 'r' || 0x0024 || 'h' || 0x0034 || 'm' || 0x0044 || || 0x0054 || DOWN || 0x0064 || || 0x0074 || WINDOW
|-
| 0x0005 || '4' || 0x0015 || 't' || 0x0025 || 'j' || 0x0035 || ',' || 0x0045 || || 0x0055 || PAGE_UP || 0x0065 || || 0x0075 || 1ST_PAGE
|-
| 0x0006 || '5' || 0x0016 || 'z' || 0x0026 || 'k' || 0x0036 || '.' || 0x0046 || || 0x0056 || PAGE_DOWN || 0x0066 || || 0x0076 || STOP
|-
| 0x0007 || '6' || 0x0017 || 'u' || 0x0027 || 'l' || 0x0037 || '-' || 0x0047 || || 0x0057 || || 0x0067 || || 0x0077 || MAIL
|-
| 0x0008 || '7' || 0x0018 || 'i' || 0x0028 || 'ö' || 0x0038 || || 0x0048 || || 0x0058 || || 0x0068 || || 0x0078 || FAVORITES
|-
| 0x0009 || '8' || 0x0019 || 'o' || 0x0029 || 'ä' || 0x0039 || SHIFT_RIGHT || 0x0049 || || 0x0059 || RIGHT || 0x0069 || || 0x0079 || NEW_PAGE
|-
| 0x000A || '9' || 0x001A || 'p' || 0x002A || '#' || 0x003A || CTRL || 0x004A || || 0x005A || || 0x006A || || 0x007A || SETUP
|-
| 0x000B || '0' || 0x001B || 'ü' || 0x002B || CR || 0x003B || || 0x004B || INSERT || 0x005B || || 0x006B || || 0x007B || FONT
|-
| 0x000C || 'ß' || 0x001C || '+' || 0x002C || SHIFT_LEFT || 0x003C || ALT_LEFT || 0x004C || DELETE || 0x005C || || 0x006C || || 0x007C || PRINT
|-
| 0x000D || '´' || 0x001D || || 0x002D || '<' || 0x003D || SPACE || 0x004D || || 0x005D || || 0x006D || || 0x007D ||
|-
| 0x000E || || 0x001E || CAPSLOCK || 0x002E || 'y' || 0x003E || ALT_RIGHT || 0x004E || || 0x005E || || 0x006E || ESCAPE || 0x007E || ON_OFF
|-
| 0x000F || BACKSPACE || 0x001F || 'a' || 0x002F || 'x' || 0x003F || || 0x004F || LEFT || 0x005F || || 0x006F || || 0x007F ||
|-
|}

Zusatztasten links:

{| class="wikitable"
! Code || Taste
|-
|-
| 0x0400 || KEY_MOUSE_1
|-
| 0x0800 || KEY_MOUSE_2
|}

Dabei gelten die obigen Werte für das Drücken einer Taste. Wird die Taste wieder losgelassen, setzt IRMP zusätzlich das 8. Bit im Kommando.

Beispiel:

Taste 'a' drücken: 0x001F
Taste 'a' loslassen: 0x009F

Ausnahme ist die EIN/AUS-Taste: Diese sendet nur beim Drücken einen Code, nicht beim Loslassen.

Wird eine Taste länger gedrückt, wird das in irmp_data.flag angezeigt.

Beispiel:

command flag
Taste 'a' drücken: 0x001F 0x00
Taste 'a' drücken: 0x001F 0x01
Taste 'a' drücken: 0x001F 0x01
Taste 'a' drücken: 0x001F 0x01
....
Taste 'a' loslassen: 0x009F 0x00

Werden Tastenkombinationen (zum Beispiel für ein großes 'A') gedrückt, dann sind die Rückgabewerte von IRMP in folgendem Ablauf zu sehen:

Linke SHIFT-Taste drücken: 0x0002
Taste 'a' drücken: 0x001F
Taste 'a' loslassen: 0x009F
Linke SHIFT-Taste loslassen: 0x0082

In irmp.c findet man für die LINUX-Version eine Funktion get_fdc_key(), welche als Vorlage dienen mag, die Keycodes einer FDC-Tastatur in die entsprechenden ASCII-Codes umzuwandeln. Diese Funktion kann man entweder lokal auf dem µC nutzen, um die Keycodes zu decodieren, oder auf einem Hostsystem (z.B. PC), an welches die IRMP-Data-Struktur gesandt wird. Dafür sollte man die Funktion incl. der dazugehörenden Preprozessor-Konstanten in seinen Applikations-Quelltext kopieren.

Hier der entsprechende Auszug:
<c>
#define STATE_LEFT_SHIFT 0x01
#define STATE_RIGHT_SHIFT 0x02
#define STATE_LEFT_CTRL 0x04
#define STATE_LEFT_ALT 0x08
#define STATE_RIGHT_ALT 0x10

#define KEY_ESCAPE 0x1B // keycode = 0x006e
#define KEY_MENUE 0x80 // keycode = 0x0070
#define KEY_BACK 0x81 // keycode = 0x0071
#define KEY_FORWARD 0x82 // keycode = 0x0072
#define KEY_ADDRESS 0x83 // keycode = 0x0073
#define KEY_WINDOW 0x84 // keycode = 0x0074
#define KEY_1ST_PAGE 0x85 // keycode = 0x0075
#define KEY_STOP 0x86 // keycode = 0x0076
#define KEY_MAIL 0x87 // keycode = 0x0077
#define KEY_FAVORITES 0x88 // keycode = 0x0078
#define KEY_NEW_PAGE 0x89 // keycode = 0x0079
#define KEY_SETUP 0x8A // keycode = 0x007a
#define KEY_FONT 0x8B // keycode = 0x007b
#define KEY_PRINT 0x8C // keycode = 0x007c
#define KEY_ON_OFF 0x8E // keycode = 0x007c

#define KEY_INSERT 0x90 // keycode = 0x004b
#define KEY_DELETE 0x91 // keycode = 0x004c
#define KEY_LEFT 0x92 // keycode = 0x004f
#define KEY_HOME 0x93 // keycode = 0x0050
#define KEY_END 0x94 // keycode = 0x0051
#define KEY_UP 0x95 // keycode = 0x0053
#define KEY_DOWN 0x96 // keycode = 0x0054
#define KEY_PAGE_UP 0x97 // keycode = 0x0055
#define KEY_PAGE_DOWN 0x98 // keycode = 0x0056
#define KEY_RIGHT 0x99 // keycode = 0x0059
#define KEY_MOUSE_1 0x9E // keycode = 0x0400
#define KEY_MOUSE_2 0x9F // keycode = 0x0800

static uint8_t
get_fdc_key (uint16_t cmd)
{
static uint8_t key_table[128] =
{
// 0 1 2 3 4 5 6 7 8 9 A B C D E F
0, '^', '1', '2', '3', '4', '5', '6', '7', '8', '9', '0', 'ß', '´', 0, '\b',
'\t','q', 'w', 'e', 'r', 't', 'z', 'u', 'i', 'o', 'p', 'ü', '+', 0, 0, 'a',
's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'ö', 'ä', '#', '\r', 0, '<', 'y', 'x',
'c', 'v', 'b', 'n', 'm', ',', '.', '-', 0, 0, 0, 0, 0, ' ', 0, 0,

0, '°', '!', '"', '§', '$', '%', '&', '/', '(', ')', '=', '?', '`', 0, '\b',
'\t','Q', 'W', 'E', 'R', 'T', 'Z', 'U', 'I', 'O', 'P', 'Ü', '*', 0, 0, 'A',
'S', 'D', 'F', 'G', 'H', 'J', 'K', 'L', 'Ö', 'Ä', '\'','\r', 0, '>', 'Y', 'X',
'C', 'V', 'B', 'N', 'M', ';', ':', '_', 0, 0, 0, 0, 0, ' ', 0, 0
};
static uint8_t state;

uint8_t key = 0;

switch (cmd)
{
case 0x002C: state |= STATE_LEFT_SHIFT; break; // pressed left shift
case 0x00AC: state &= ~STATE_LEFT_SHIFT; break; // released left shift
case 0x0039: state |= STATE_RIGHT_SHIFT; break; // pressed right shift
case 0x00B9: state &= ~STATE_RIGHT_SHIFT; break; // released right shift
case 0x003A: state |= STATE_LEFT_CTRL; break; // pressed left ctrl
case 0x00BA: state &= ~STATE_LEFT_CTRL; break; // released left ctrl
case 0x003C: state |= STATE_LEFT_ALT; break; // pressed left alt
case 0x00BC: state &= ~STATE_LEFT_ALT; break; // released left alt
case 0x003E: state |= STATE_RIGHT_ALT; break; // pressed left alt
case 0x00BE: state &= ~STATE_RIGHT_ALT; break; // released left alt

case 0x006e: key = KEY_ESCAPE; break;
case 0x004b: key = KEY_INSERT; break;
case 0x004c: key = KEY_DELETE; break;
case 0x004f: key = KEY_LEFT; break;
case 0x0050: key = KEY_HOME; break;
case 0x0051: key = KEY_END; break;
case 0x0053: key = KEY_UP; break;
case 0x0054: key = KEY_DOWN; break;
case 0x0055: key = KEY_PAGE_UP; break;
case 0x0056: key = KEY_PAGE_DOWN; break;
case 0x0059: key = KEY_RIGHT; break;
case 0x0400: key = KEY_MOUSE_1; break;
case 0x0800: key = KEY_MOUSE_2; break;

default:
{
if (!(cmd & 0x80)) // pressed key
{
if (cmd >= 0x70 && cmd <= 0x7F) // function keys
{
key = cmd + 0x10; // 7x -> 8x
}
else if (cmd < 64) // key listed in key_table
{
if (state & (STATE_LEFT_ALT | STATE_RIGHT_ALT))
{
switch (cmd)
{
case 0x0003: key = '²'; break;
case 0x0008: key = '{'; break;
case 0x0009: key = '['; break;
case 0x000A: key = ']'; break;
case 0x000B: key = '}'; break;
case 0x000C: key = '\\'; break;
case 0x001C: key = '~'; break;
case 0x002D: key = '|'; break;
case 0x0034: key = 'µ'; break;
}
}
else if (state & (STATE_LEFT_CTRL))
{
if (key_table[cmd] >= 'a' && key_table[cmd] <= 'z')
{
key = key_table[cmd] - 'a' + 1;
}
else
{
key = key_table[cmd];
}
}
else
{
int idx = cmd + ((state & (STATE_LEFT_SHIFT | STATE_RIGHT_SHIFT)) ? 64 : 0);

if (key_table[idx])
{
key = key_table[idx];
}
}
}
}
break;
}
}

return (key);
}
</c>

Als letztes noch ein Beispiel einer Anwendung der Funktion get_fdc_key():

<c>
if (irmp_get_data (&irmp_data))
{
uint8_t key;

if (irmp_data.protocol == IRMP_FDC_PROTOCOL &&
(key = get_fdc_key (irmp_data.command)) != 0)
{
if ((key >= 0x20 && key < 0x7F) || key >= 0xA0) // show only printable characters
{
printf ("ascii-code = 0x%02x, character = '%c'\n", key, key);
}
else // it's a non-printable key
{
printf ("ascii-code = 0x%02x\n", key);
}
}
}
</c>

Alle nicht-druckbaren Zeichen werden dabei folgendermaßen codiert:

{| class="wikitable"
! Taste || Konstante || Wert
|-
| ESC || KEY_ESCAPE || 0x1B
|-
| Menü || KEY_MENUE || 0x80
|-
| Zurück || KEY_BACK || 0x81
|-
| Vorw. || KEY_FORWARD || 0x82
|-
| Adresse || KEY_ADDRESS || 0x83
|-
| Fenster || KEY_WINDOW || 0x84
|-
| 1. Seite || KEY_1ST_PAGE || 0x85
|-
| Stop || KEY_STOP || 0x86
|-
| Mail || KEY_MAIL || 0x87
|-
| Fav. || KEY_FAVORITES || 0x88
|-
| Neue Seite || KEY_NEW_PAGE || 0x89
|-
| Setup || KEY_SETUP || 0x8A
|-
| Schrift || KEY_FONT || 0x8B
|-
| Druck || KEY_PRINT || 0x8C
|-
| Ein/Aus || KEY_ON_OFF || 0x8E
|-
| Backspace || '\b' || 0x08
|-
| CR/ENTER || '\r' || 0x0C
|-
| TAB || '\t' || 0x09
|-
| Einfg || KEY_INSERT || 0x90
|-
| Entf || KEY_DELETE || 0x91
|-
| Cursor links || KEY_LEFT || 0x92
|-
| Pos1 || KEY_HOME || 0x93
|-
| Ende || KEY_END || 0x94
|-
| Cursor rechts || KEY_UP || 0x95
|-
| Cursor runter || KEY_DOWN || 0x96
|-
| Bild hoch || KEY_PAGE_UP || 0x97
|-
| Bild runter || KEY_PAGE_DOWN || 0x98
|-
| Cursor links || KEY_RIGHT || 0x99
|-
| Linke Maustaste || KEY_MOUSE_1 || 0x9E
|-
| Rechte Maustaste || KEY_MOUSE_2 || 0x9F
|-
|}

Die Funktion get_fdc_key berücksichtigt das Gedrückthalten der Shift-, Strg- und ALT-Tasten. Damit funktioniert nicht nur das Schreiben von Großbuchstaben, sondern auch das Auswählen der Sonderzeichen mit der Tastenkombination ALT + Taste, z.B. ALT + m = µ oder ALT + q = @. Ebenso kann man mit der Strg-Taste die Control-Zeichen CTRL-A bis CTRL-Z senden. Die CapsLock-Taste wird ignoriert, da ich sie sowieso für die überflüssigste Taste überhaupt halte ;-)

----

= IRSND - Infrarot-Multiprotokoll-Encoder =

[[Datei:irmp-title.png| |Scan eines NEC-kompatiblen Fernbedienungssignals]]

== Einleitung IRSND ==

[[Datei:ir-sender.png|miniatur|Anschluß eines einfachen IR-Senders an µC]]

IRSND ist das Gegenstück zu IRMP: es reproduziert aus den Daten, die mit IRMP empfangen wurden, wieder den Original Frame, der dann über eine Infrarot-Diode ausgegeben werden kann.

IRSND ist lauffähig auf folgenden AVR µCs:

* ATtiny45, ATtiny85
* ATtiny84
* ATmega8, ATmega16, ATmega32
* ATmega162
* ATmega164, ATmega324, ATmega644, ATmega644P, ATmega1284
* ATmega88, ATmega88P, ATmega168, ATmega168P, ATmega328P

IRSND unterstützt die folgenden Protokolle:

* SIRCS
* NEC
* SAMSUNG
* SAMSUNG32
* MATSUSHITA
* RC5
* KASEIKYO
* DENON
* JVC
* APPLE
* NUBERT
* BANG_OLUFSEN
* GRUNDIG
* NOKIA
* SIEMENS (bei mind. ~15kHz)
* FDC (bei mind. ~15kHz)
* RCCAR (bei mind. ~15kHz)
* RECS80 (bei mind. ~20kHz)
* RECS80EXT (bei mind. ~20kHz)
* NIKON
* RC6
* RC6A
* THOMSON
* NEC16
* NEC42
* LEGO
* IR60 ('''NEU''')

== Download IRSND ==

Version 2.2.0, Stand vom 23.05.2012

Download Release-Version: [http://www.mikrocontroller.net/wikifiles/c/c7/Irsnd.zip Irsnd.zip]

IRMP & IRSND sind nun auch über SVN abrufbar: [http://www.mikrocontroller.net/svnbrowser/irmp/ IRMP im SVN]

'''Achtung:'''

Die Version im SVN kann eine Zwischen- oder Test-Version sein, die nicht den hier dokumentierten Stand widerspiegelt! Im Zweifel verwendet man besser den obigen Download auf Irsnd.zip.

'''Die Software-Änderungen kann man sich hier anschauen: [http://www.mikrocontroller.net/articles/IRMP#Software-Historie_IRSND Software-Historie IRSND]'''

== Source-Code IRSND ==

Der Source-Code lässt sich einfach übersetzen, indem man unter Windows die Projekt-Datei irsnd.aps in das AVRStudio 4 lädt.

Auch für andere Entwicklungsumgebungen lässt sich leicht ein Projekt bzw. Makefile zusammenstellen. Zum IRSND-Source gehören folgende Dateien:

* irsnd.c - Der eigentliche IR-Encoder
* irmpprotocols.h - Sämtliche Definitionen zu den IR-Protokollen
* irmpsystem.h - Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32
* irsnd.h - Include-Datei für die Applikation
* irsndconfig.h - Anzupassende Konfigurationsdatei

'''WICHTIG:'''

'''Im Applikations-Source sollte nur irsnd.h per include eingefügt werden, also lediglich:'''

<c>
#include "irsnd.h"
</c>

Alle anderen Include-Dateien werden automatisch über irsnd.h "eingefügt". Siehe dazu auch die Beispieldatei irsndmain.c.

IRSND encodiert sämtliche oben aufgelisteten Protokolle in einer ISR, siehe irsnd.c.

=== Einstellungen in irsndconfig.h ===

'''F_INTERRUPTS'''

Anzahl der Interrupts pro Sekunde. Der Wert kann zwischen 10000 und 20000 eingestellt werden.

Standardwert:
<c>
#define F_INTERRUPTS 15000 // interrupts per second
</c>

'''IRSND_SUPPORT_xxx_PROTOCOL'''

Hier lässt sich einstellen, welche Protokolle von IRSND unterstützt werden sollen. Die Standardprotokolle sind bereits aktiv. Möchte man weitere Protokolle einschalten bzw. einige aus Speicherplatzgründen deaktivieren, sind die entsprechenden Werte in irsndconfig.h anzupassen.

<c>
// typical protocols, disable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 ~150 bytes
#define IRSND_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 ~100 bytes
#define IRSND_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 ~300 bytes
#define IRSND_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 ~200 bytes
#define IRSND_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 ~150 bytes
#define IRSND_SUPPORT_DENON_PROTOCOL 1 // DENON, Sharp >= 10000 ~200 bytes

// more protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_RC5_PROTOCOL 0 // RC5 >= 10000 ~150 bytes
#define IRSND_SUPPORT_RC6_PROTOCOL 0 // RC6 >= 10000 ~250 bytes
#define IRSND_SUPPORT_RC6A_PROTOCOL 0 // RC6A >= 10000 ~250 bytes
#define IRSND_SUPPORT_JVC_PROTOCOL 0 // JVC >= 10000 ~150 bytes
#define IRSND_SUPPORT_NEC16_PROTOCOL 0 // NEC16 >= 10000 ~150 bytes
#define IRSND_SUPPORT_NEC42_PROTOCOL 0 // NEC42 >= 10000 ~150 bytes
#define IRSND_SUPPORT_IR60_PROTOCOL 0 // IR60 (SDA2008) >= 10000 DON'T CHANGE, NOT SUPPORTED YET!
#define IRSND_SUPPORT_GRUNDIG_PROTOCOL 0 // Grundig >= 10000 ~300 bytes
#define IRSND_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens, Gigaset >= 15000 ~150 bytes
#define IRSND_SUPPORT_NOKIA_PROTOCOL 0 // Nokia >= 10000 ~400 bytes

// exotic protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_KATHREIN_PROTOCOL 0 // Kathrein >= 10000 DON'T CHANGE, NOT SUPPORTED YET!
#define IRSND_SUPPORT_NUBERT_PROTOCOL 0 // NUBERT >= 10000 ~100 bytes
#define IRSND_SUPPORT_BANG_OLUFSEN_PROTOCOL 0 // Bang&Olufsen >= 10000 ~250 bytes
#define IRSND_SUPPORT_RECS80_PROTOCOL 0 // RECS80 >= 20000 ~100 bytes
#define IRSND_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT >= 20000 ~100 bytes
#define IRSND_SUPPORT_THOMSON_PROTOCOL 0 // Thomson >= 10000 ~250 bytes
#define IRSND_SUPPORT_NIKON_PROTOCOL 0 // NIKON >= 10000 ~150 bytes
#define IRSND_SUPPORT_NETBOX_PROTOCOL 0 // Netbox keyboard >= 10000 DON'T CHANGE, NOT SUPPORTED YET!
#define IRSND_SUPPORT_FDC_PROTOCOL 0 // FDC IR keyboard >= 10000 (better 15000) ~150 bytes
#define IRSND_SUPPORT_RCCAR_PROTOCOL 0 // RC CAR >= 10000 (better 15000) ~150 bytes
#define IRSND_SUPPORT_RUWIDO_PROTOCOL 0 // RUWIDO, T-Home >= 15000 DON'T CHANGE, NOT SUPPORTED YET!
#define IRSND_SUPPORT_LEGO_PROTOCOL 0 // LEGO Power RC >= 20000 ~150 bytes
</c>

Mit Setzen auf 0 wird das Protokoll deaktiviert, mit Setzen auf 1 wird es aktiviert. Die deaktivierten Protokolle werden dann nicht mitübersetzt. Das spart Speicherplatz im Flash, siehe Angaben in obigen Kommentaren. Wenn man unbedingt Speicherplatz sparen muss, gelten natürlich hier dieselben Tipps wie für IRMP.

Um das APPLE-Protokoll zu unterstützen, ist IRSND_SUPPORT_NEC_PROTOCOL auf 1 zu setzen, da es sich hier lediglich um einen Spezialfall vom NEC-Protokoll handelt.

'''IRSND_OCx'''

Für das Senden der IR-Signale benötigt IRSND einen PWM-fähigen Output-Pin, da das Signal moduliert werden muss. Möglich sind eine der folgenden Einstellungen:

<c>
#define IRSND_OCx IRSND_OC2 // OC2 on ATmegas supporting OC2, e.g. ATmega8
#define IRSND_OCx IRSND_OC2A // OC2A on ATmegas supporting OC2A, e.g. ATmega88
#define IRSND_OCx IRSND_OC2B // OC2B on ATmegas supporting OC2B, e.g. ATmega88
#define IRSND_OCx IRSND_OC0 // OC0 on ATmegas supporting OC0, e.g. ATmega162
#define IRSND_OCx IRSND_OC0A // OC0A on ATmegas/ATtinys supporting OC0A, e.g. ATtiny84, ATtiny85
#define IRSND_OCx IRSND_OC0B // OC0B on ATmegas/ATtinys supporting OC0B, e.g. ATtiny84, ATtiny85
</c>

Standardwert:
<c>
#define IRSND_OCx IRSND_OC2B
</c>

Für die PIC- und STM32-µCs sind entsprechende Werte anzupassen, siehe Kommentare in irsndconfig.h.

IRSND baut den zu sendenden Frame "on-the-fly" aus der IRMP-Datenstruktur wieder zusammen. Dazu zählen:

1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando

Mittels der Funktion

irsnd_send_data (IRMP_DATA * irmp_data_p)

kann man ein zu encodierendes Telegramm versenden. Der Return-Wert ist 1, wenn das Telegramm versendet werden kann, sonst 0. Im ersten Fall werden die Struct-Members

<c>
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
irmp_data_p->flags
</c>

ausgelesen und dann als Frame im jeweils gewünschten Protokoll gesendet.

'''NEU ab Version 1.5.0:'''

irmp_data_p->flags gibt die Anzahl der Wiederholungen an, z.B.

irmp_data_p->flags = 0: Verhalten wie bisher
irmp_data_p->flags = 1: 1 Wiederholung
irmp_data_p->flags = 2: 2 Wiederholungen
usw.

'''Zu beachten: Da bisher irmp_data_p->flags von IRSND nicht ausgewertet wurde, ist unbedingt ab Version 1.5.0 darauf zu achten, dass irmp_data_p->flags vor dem Aufruf von irsnd_send_data() einen definierten Wert hat!'''

Hier ein Beispiel:

<c>
IRMP_DATA irmp_data;

irmp_data.protocol = IRMP_NEC_PROTOCOL; // sende im NEC-Protokoll
irmp_data.address = 0x00FF; // verwende Adresse 0x00FF
irmp_data.command = 0x0001; // sende Kommando 0001
irmp_data.flags = 0; // keine Wiederholung!

(void) irsnd_send_data (&irmp_data); // versende ohne Prüfung
</c>

Der Frame wird asynchron über die Interrupt-Routine irsnd_ISR() verschickt, so dass die Funktion irsnd_send_data() sofort zurückkommt.

Sind Wiederholungen angegeben, wird entweder der Frame nach einer Pause (protokollabhängig) neu ausgegeben oder ein protokollspezifischer Wiederholungsframe (z.B. für NEC) gesendet.

Wird erneut irsnd_send_data() aufgerufen, wartet diese, bis der vorhergenhende Frame vollständig verschickt wurde. Man kann aber auch selbst prüfen, ob IRSND gerade "busy" ist oder nicht:

<c>
while (irsnd_is_busy ())
{
; // selber warten oder was anderes tun...
}
(void) irsnd_send_data (&irmp_data); // versende ohne Prüfung

</c>

Im Beispiel-Source irsndmain.c findet man neben der Verwendung von irsnd_send_data() auch den Timer-Aufruf:

<c>
ISR(TIMER1_COMPA_vect)
{
irsnd_ISR()) // call irsnd ISR
// call other timer interrupt routines...
}
</c>

=== Paralleles Betreiben von IRMP und IRSND ===

Möchte man IRMP und IRSND parallel verwenden (also als Sender und Empfänger) schreibt man die ISR folgendermaßen:

<c>
ISR(TIMER1_COMPA_vect)
{
if (! irsnd_ISR()) // call irsnd ISR
{ // if not busy...
irmp_ISR(); // call irmp ISR
}
// call other timer interrupt routines...
}
</c>

Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR des Empfängers auf. Damit ist der Empfänger solange abgeschaltet, während irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine ist für IRMP und IRSND dann natürlich dieselbe.

Eine gemeinsame main-Funktion könnte dann zum Beispiel folgendermaßen aussehen:

<c>
int
main (void)
{
IRMP_DATA irmp_data;

irmp_init(); // initialize irmp
irsnd_init(); // initialize irsnd
timer_init(); // initialize timer
sei (); // enable interrupts

for (;;)
{
if (irmp_get_data (&irmp_data))
{
irmp_data.flags = 0; // reset flags!
irsnd_send_data (&irmp_data);
}
}
}
</c>

Die Funktion des obigen Sources ist offensichtlich: Ein empfangenes Telegramm wird nach vollständiger Decodierung wieder encodiert und dann wieder über die IR-Diode ausgesandt. Somit können dann zum Beispiel Signale "um die Ecke" oder streckenweise drahtgebunden übertragen werden.

Desweiteren könnte man auch Protokolle transformieren, zum Beispiel NEC-Telegramme in RC5 umwandeln, wenn man seine Original-RC5-FB zu seinem Philips-Gerät verlegt hat...

Der Rest bleibt der Phantasie des geneigten Lesers überlassen ;-)

Hier noch die möglichen Werte für irmp_data.protocol, siehe auch irmp.h:

<c>
#define IRMP_SIRCS_PROTOCOL 1 // Sony
#define IRMP_NEC_PROTOCOL 2 // NEC, Pioneer, JVC, Toshiba, NoName etc.
#define IRMP_SAMSUNG_PROTOCOL 3 // Samsung
#define IRMP_MATSUSHITA_PROTOCOL 4 // Matsushita
#define IRMP_KASEIKYO_PROTOCOL 5 // Kaseikyo (Panasonic etc)
#define IRMP_RECS80_PROTOCOL 6 // Philips, Thomson, Nordmende, Telefunken, Saba
#define IRMP_RC5_PROTOCOL 7 // Philips etc
#define IRMP_DENON_PROTOCOL 8 // Denon, Sharp
#define IRMP_RC6_PROTOCOL 9 // Philips etc
#define IRMP_SAMSUNG32_PROTOCOL 10 // Samsung32: no sync pulse at bit 16, length 32 instead of 37
#define IRMP_APPLE_PROTOCOL 11 // Apple, very similar to NEC
#define IRMP_RECS80EXT_PROTOCOL 12 // Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
#define IRMP_NUBERT_PROTOCOL 13 // Nubert
#define IRMP_BANG_OLUFSEN_PROTOCOL 14 // Bang & Olufsen
#define IRMP_GRUNDIG_PROTOCOL 15 // Grundig
#define IRMP_NOKIA_PROTOCOL 16 // Nokia
#define IRMP_SIEMENS_PROTOCOL 17 // Siemens, e.g. Gigaset
#define IRMP_FDC_PROTOCOL 18 // FDC keyboard
#define IRMP_RCCAR_PROTOCOL 19 // RC Car
#define IRMP_JVC_PROTOCOL 20 // JVC (NEC with 16 bits)
#define IRMP_RC6A_PROTOCOL 21 // RC6A, e.g. Kathrein, XBOX
#define IRMP_NIKON_PROTOCOL 22 // Nikon
#define IRMP_RUWIDO_PROTOCOL 23 // Ruwido, e.g. T-Home Mediareceiver
#define IRMP_IR60_PROTOCOL 24 // IR60 (SDA2008)
#define IRMP_KATHREIN_PROTOCOL 25 // Kathrein
#define IRMP_NETBOX_PROTOCOL 26 // Netbox keyboard (bitserial)
#define IRMP_NEC16_PROTOCOL 27 // NEC with 16 bits (incl. sync)
#define IRMP_NEC42_PROTOCOL 28 // NEC with 42 bits
#define IRMP_LEGO_PROTOCOL 29 // LEGO Power Functions RC
#define IRMP_THOMSON_PROTOCOL 30 // Thomson
</c>

Die Daten für die Adresse und das Kommando ermittelt man am besten über IRMP, siehe weiter oben ;-)

== IRSND unter Linux und Windows ==

irsnd.c lässt sich auch unter Linux direkt kompilieren, um damit Telegramme in Form von IRMP-Scan-Dateien zu erzeugen. Das geht folgendermaßen:

cc irsnd.c -o irsnd # IRSND compilieren

Der Aufruf geht dann folgendermaßen:

./irsnd protocol-number hex-address hex-command [repeat] > filename.txt

also zum Beispiel für das NEC-Protokoll, Adresse 0x00FF, Kommando 0x0001

./irsnd 2 00FF 0001 > nec.txt # irsnd ausführen

IRSND kann man auch unter Windows nutzen, nämlich folgendermaßen:

* Eingabeaufforderung starten
* In das Verzeichnis von irsnd wechseln
* Aufruf von:

irsnd.exe 2 00FF 0001 > nec.txt

Nun kann man direkt mit IRMP anschließend testen, ob das erzeugte Telegramm auch korrekt ist:

./irmp < nec.txt

bzw. unter Windows:

irmp.exe < nec.txt

Das Ganze geht auch ohne Zwischendatei, nämlich:

./irsnd 2 00FF 0001 | ./irmp

bzw. unter Windows:

irsnd.exe 2 00FF 0001 | irmp.exe

IRMP gibt dann als Ergebnis folgendes aus:

11111111000000001000000001111111 p = 2, a = 0x00ff, c = 0x0001, f = 0x00

IRMP konnte also aus dem von IRSND generierten Frame wieder das Protokoll 2, Adresse 0x00FF und Kommando 0x0001 decodieren.

Bitte beachten: Je nach benutztem Protokoll sind die Bit-Breiten der Adressen bzw. Kommandos verschieden, siehe obige Tabelle [http://www.mikrocontroller.net/articles/IRMP#Protokolle].

Man kann also nicht mit jedem IR-Protokoll komplett 16-Bit breite Adressen oder Kommandos transparent übertragen.

----

= Anhang =

== Die IR-Protokolle im Detail ==

=== Pulse-Distance Protokolle ===

{| class="wikitable"
! '''SIRCS''' || Wert
|-
| Frequenz || 40 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 12-20 Daten-Bits, kein Stop-Bit
|-
| Daten || 7 Kommando-Bits + 5 Adress-Bits + bis zu 8 zusätzliche Bits
|-
| Start-Bit || 2400µs Puls, 600µs Pause
|-
| 0-Bit || 600µs Puls, 600µs Pause
|-
| 1-Bit || 1200µs Puls, 600µs Pause
|-
| Wiederholung || zweimalig nach ca. 25ms, d.h. 2. und 3. Frame
|-
| Tasten-Wiederholung || ab dem 4. identischen Frame, Abstand ca. 25ms
|-
| Bit-Order || LSB first
|-
! '''NEC + extended NEC''' || Wert
|-
| Frequenz || 36 kHz / 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten NEC || 8 Adress-Bits + 8 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Daten ext. NEC || 16 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || 9000µs Puls, 2250µs Pause, 560µs Puls, ~100ms Pause
|-
| Bit-Order || LSB first
|-
! '''JVC''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten-Bits + 1 Stop-Bit
|-
| Daten || 4 Adress-Bits + 12 Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause, 6000µs Pause bei Tasten-Wiederholung
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 25ms
|-
| Bit-Order || LSB first
|-
! '''NEC16''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 8 Adress-Bits + 1 Sync-Bit + 8 Daten-Bits + 1 Stop-Bit
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| Sync-Bit || 560µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine/eine/zwei nach 25ms?
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 25ms?
|-
| Bit-Order || LSB first
|-
! '''NEC42''' || Wert
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 42 Daten-Bits + 1 Stop-Bit
|-
| Daten || 13 Adress-Bits + 13 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || (unbekannt)
|-
| Bit-Order || LSB first
|-
! '''SAMSUNG''' || Wert
|-
| Frequenz || ?? kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten(1)-Bits + 1 Sync-Bit + 20 Daten(2)-Bits + 1 Stop-Bit
|-
| Daten(1) || 16 Adress-Bits
|-
| Daten(2) || 4 ID-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 4500µs Puls, 4500µs Pause
|-
| 0-Bit || 550µs Puls, 550µs Pause
|-
| 1-Bit || 550µs Puls, 1650µs Pause
|-
| Sync-Bit || 550µs Puls, 4500µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first
|-
! '''SAMSUNG32''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Adress-Bits + 16 Kommando-Bits
|-
| Start-Bit || 4500µs Puls, 4500µs Pause
|-
| 0-Bit || 550µs Puls, 550µs Pause
|-
| 1-Bit || 550µs Puls, 1650µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || LSB first
|-
! '''MATSUSHITA''' || Wert
|-
| Frequenz || 36 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 24 Daten-Bits + 1 Stop-Bit
|-
| Daten || 6 Hersteller-Bits + 6 Kommando-Bits + 12 Adress-Bits
|-
| Start-Bit || 3488µs Puls, 3488µs Pause
|-
| 0-Bit || 872µs Puls, 872µs Pause
|-
| 1-Bit || 872µs Puls, 2616µs Pause
|-
| Stop-Bit || 872µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first?
|-
! '''KASEIKYO''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 48 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Hersteller-Bits + 4 Parity-Bits + 4 Genre1-Bits + 4 Genre2-Bits + 10 Kommando-Bits + 2 ID-Bits + 8 Parity-Bits
|-
| Start-Bit || 3380µs Puls, 1690µs Pause
|-
| 0-Bit || 423µs Puls, 423µs Pause
|-
| 1-Bit || 423µs Puls, 1269µs Pause
|-
| Stop-Bit || 423µs Puls
|-
| Wiederholung || einmalig nach 74ms
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 74ms
|-
| Bit-Order || LSB first?
|-
! '''RECS80''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bits + 10 Daten-Bits + 1 Stop-Bit
|-
| Daten || 1 Toggle-Bit + 3 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 158µs Puls, 7432µs Pause
|-
| 0-Bit || 158µs Puls, 4902µs Pause
|-
| 1-Bit || 158µs Puls, 7432µs Pause
|-
| Stop-Bit || 158µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''RECS80EXT''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 2 Start-Bits + 11 Daten-Bits + 1 Stop-Bit
|-
| Daten || 1 Toggle-Bit + 4 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 158µs Puls, 3637µs Pause
|-
| 0-Bit || 158µs Puls, 4902µs Pause
|-
| 1-Bit || 158µs Puls, 7432µs Pause
|-
| Stop-Bit || 158µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''DENON''' || Wert
|-
| Frequenz || 38 kHz (in der Praxis, lt. Dokumentation: 32 kHz)
|-
| Kodierung || Pulse Distance
|-
| Frame || 0 Start-Bits + 15 Daten-Bits + 1 Stop-Bit
|-
| Daten || 5 Address-Bits + 10 Kommando-Bits
|-
| Start-Bit || kein Start-Bit
|-
| 0-Bit || 310µs Puls, 745µs Pause (in der Praxis, lt. Doku: 275µs Puls, 775µs Pause)
|-
| 1-Bit || 310µs Puls, 1780µs Pause (in der Praxis, lt. Doku: 275µs Puls, 1900µs Pause)
|-
| Stop-Bit || 310µs Puls (310µs Puls, 745µs Pause (in der Praxis, lt. Doku: 275µs Puls)
|-
| Wiederholung || Nach 65ms Wiederholung des Frames mit invertieren Kommando-Bits
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''APPLE''' || Wert
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Adress-Bits + 11100000 + 8 Kommando-Bits
|-
| Start-Bit || siehe NEC
|-
| 0-Bit || siehe NEC
|-
| 1-Bit || siehe NEC
|-
| Stop-Bit || siehe NEC
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first
|-
! '''NUBERT''' || Wert
|-
| Frequenz || 36 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 10 Kommando-Bits ?
|-
| Start-Bit || 1340µs Puls, 340µs Pause
|-
| 0-Bit || 500µs Puls, 1300µs Pause
|-
| 1-Bit || 1340µs Puls, 340µs Pause
|-
| Stop-Bit || 500µs Puls
|-
| Wiederholung || einmalig nach 35ms
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || MSB first?
|-
! '''B&O''' || Wert
|-
| Frequenz || 455 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 4 Start-Bits + 16 Daten-Bits + 1 Trailer-Bit + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 16 Kommando-Bits
|-
| Start-Bit 1 || 200µs Puls, 2925µs Pause
|-
| Start-Bit 2 || 200µs Puls, 2925µs Pause
|-
| Start-Bit 3 || 200µs Puls, 15425µs Pause
|-
| Start-Bit 4 || 200µs Puls, 2925µs Pause
|-
| 0-Bit || 200µs Puls, 2925µs Pause
|-
| 1-Bit || 200µs Puls, 9175µs Pause
|-
| R-Bit || 200µs Puls, 6050µs Pause, wiederholt das letzte Bit (repetition)
|-
| Trailer-Bit || 200µs Puls, 12300µs Pause
|-
| Stop-Bit || 200µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''FDC''' || Wert
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 40 Daten-Bits + 1 Stop-Bit
|-
| Daten || 8 Adress-Bits + 12 x 0-Bits + 4 Press/Release-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 2085µs Puls, 966µs Pause
|-
| 0-Bit || 300µs Puls, 220µs Pause
|-
| 1-Bit || 300µs Puls, 715µs Pause
|-
| Stop-Bit || 300µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Drücken || Press/Release-Bits = 0000
|-
| Tasten-Loslassen || Press/Release-Bits = 1111
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 60ms
|-
| Bit-Order || LSB first
|-
! '''RCCAR''' || Wert
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 13 Daten-Bits + 1 Stop-Bit
|-
| Daten || C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V
|-
| Start-Bit || 2000µs Puls, 2000µs Pause
|-
| 0-Bit || 600µs Puls, 900µs Pause
|-
| 1-Bit || 600µs Puls, 450µs Pause
|-
| Stop-Bit || 600µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || keine?
|-
| Bit-Order || LSB first
|-
|}

=== Bi-Phase Protokolle ===

{| class="wikitable"
! '''RC5 + RC5X''' || Wert
|-
| Frequenz || 36 kHz
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Frame RC5 || 2 Start-Bits + 12 Daten-Bits + 0 Stop-Bits
|-
| Daten RC5 || 1 Toggle-Bit + 5 Adress-Bits + 6 Kommando-Bits
|-
| Frame RC5X || 1 Start-Bit + 13 Daten-Bits + 0 Stop-Bit
|-
| Daten RC5X || 1 invertiertes Kommando-Bit + 1 Toggle-Bit + 5 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 889µs Pause, 889µs Puls
|-
| 0-Bit || 889µs Puls, 889µs Pause
|-
| 1-Bit || 889µs Pause, 889µs Puls
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''RC6''' + '''RC6A''' || Wert
|-
| Frequenz || 36 kHz
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Frame RC6 || 1 Start-Bit + 1 Bit "1" + 3 Mode-Bits (000) + 1 Toggle-Bit + 16 Daten-Bits + 2666µs pause
|-
| Frame RC6A || 1 Start-Bit + 1 Bit "1" + 3 Mode-Bits (110) + 1 Toggle-Bit + 31 Daten-Bits + 2666µs pause
|-
| Daten RC6 || 8 Adress-Bits + 8 Kommando Bits
|-
| Daten RC6A || "1" + 14 Hersteller-Bits + 8 System-Bits + 8 Kommando-Bits
|-
| Start-Bit || 2666µs Puls, 889µs Pause
|-
| Toggle 0-Bit || 889µs Pause, 889µs Puls
|-
| Toggle 1-Bit || 889µs Puls, 889µs Pause
|-
| 0-Bit || 444µs Pause, 444µs Puls
|-
| 1-Bit || 444µs Puls, 444µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
! '''GRUNDIG + NOKIA''' || Wert
|-
| Frequenz || 38 kHz (?)
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Frame-Paket || 1 Start-Frame + 19,968ms Pause + N Info-Frames + 117,76ms Pause + 1 Stop-Frame
|-
| Start-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits (alle 1) + 0 Stop-Bits
|-
| Info-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits + 0 Stop-Bits
|-
| Stop-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits (alle 1) + 0 Stop-Bits
|-
| Daten Grundig || 9 Kommando-Bits + 0 Adress-Bits
|-
| Daten Nokia || 8 Kommando-Bits + 8 Adress-Bits
|-
| Pre-Bit || 528µs Puls, 2639µs Pause
|-
| Start-Bit || 528µs Puls, 528µs Pause
|-
| 0-Bit || 528µs Pause, 528µs Puls
|-
| 1-Bit || 528µs Puls, 528µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Info-Frames mit einem Pausenabstand von 117,76ms
|-
| Bit-Order || LSB first
|-
! '''IR60 (SDA2008)''' || Wert
|-
| Frequenz || 30 kHz
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Start Frame || 1 Start-Bit + 101111 + 0 Stop-Bits + 22ms Pause
|-
| Daten Frame || 1 Start-Bit + 7 Daten-Bits + 0 Stop-Bits
|-
| Daten || 0 Adress-Bits + 7 Kommando-Bits
|-
| Start-Bit || 528µs Puls, 2639µs Pause
|-
| 0-Bit || 528µs Pause, 528µs Puls
|-
| 1-Bit || 528µs Puls, 528µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Info-Frames mit einem Pausenabstand von 117,76ms
|-
| Bit-Order || LSB first
|-
! '''SIEMENS + RUWIDO''' || Wert
|-
| Frequenz || 36 kHz?
|-
| Kodierung || Bi-Phase (Manchester)
|-
| Frame Siemens || 1 Start-Bit + 22 Daten-Bits + 0 Stop-Bits
|-
| Frame Ruwido || 1 Start-Bit + 17 Daten-Bits + 0 Stop-Bits
|-
| Daten Siemens || 11 Adress-Bits + 10 Kommando-Bits + 1 invertiertes Bit (letztes Bit davor nochmal invertiert)
|-
| Daten Ruwido || 9 Adress-Bits + 7 Kommando-Bits + 1 invertiertes Bit (letztes Bit davor nochmal invertiert)
|-
| Start-Bit || 275µs Puls, 275µs Pause
|-
| 0-Bit || 275µs Pause, 275µs Puls
|-
| 1-Bit || 275µs Puls, 275µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || 1-malige Wiederholung mit gesetztem Repeat-Bit (?)
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms (?)
|-
| Bit-Order || MSB first
|-
|}

=== Serial Protokolle ===

{| class="wikitable"
! '''NETBOX''' || Wert
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Serial
|-
| Frame || 1 Start-Bit + 16 Daten-Bits, kein Stop-Bit
|-
| Daten || 3 Adress-Bits + 13 Kommando-Bits
|-
| Start-Bit || 2400µs Puls, 800µs Pause
|-
| Bitlänge || 800µs
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || Abstand ca. 35ms?
|-
| Bit-Order || LSB first
|-
|}

== Software-Historie IRMP ==

Änderungen IRMP:

Version 2.2.0:
* 23.05.2012: Portierung auf ARM STM32
* 23.05.2012: Bugfix Frame-Erkennung beim Denon-Protokoll

Ältere Versionen:

* 27.02.2012: Bug in IR60-Decoder behoben
* 27.02.2012: Bug in CRC-Berechnung von Kaseikyo-Frames behoben
* 27.02.2012: Portierung auf C18 Compiler für PIC-Mikroprozessoren
* 13.02.2012: Bugfix: oberstes Bit in Adresse falsch bei NEC-Protokoll, wenn auch NEC42-Protokoll eingeschaltet ist.
* 13.02.2012: Timing von SAMSUNG- und SAMSUNG32-Protokoll korrigiert
* 13.02.2012: Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
* 20.09.2011: '''Neues Protokoll''': KATHREIN
* 20.09.2011: '''Neues Protokoll''': RUWIDO
* 20.09.2011: '''Neues Protokoll''': THOMSON
* 20.09.2011: '''Neues Protokoll''': IR60
* 20.09.2011: '''Neues Protokoll''': LEGO
* 20.09.2011: '''Neues Protokoll''': NEC16
* 20.09.2011: '''Neues Protokoll''': NEC42
* 20.09.2011: '''Neues Protokoll''': NETBOX
* 20.09.2011: Portierung auf ATtiny84 und ATtiny85
* 20.09.2011: Verbesserung von Tastenwiederholungen bei RC5
* 20.09.2011: Verbessertes Decodieren von Bi-Phase-Protokollen
* 20.09.2011: Korrekturen am RECS80-Decoder
* 20.09.2011: Korrekturen beim Erkennen von zusätzlichen Bits im SIRCS-Protocol
* 18.01.2011: Korrekturen für Siemens-Protokoll
* 18.01.2011: '''Neues Protokoll''': NIKON
* 18.01.2011: Speichern der zusätzlichen Bits (>12) im SIRCS-Protokoll in der Adresse
* 18.01.2011: Timing-Korrekturen für Denon-Protokoll

* 04.09.2010: Bugfix für F_INTERRUPTS >= 16000

* 02.09.2010: '''Neues Protokoll''': RC6A

* 29.08.2010: '''Neues Protokoll''': JVC
* 29.08.2010: Kaseikyo-Protokoll: Berücksichtigung der Genre-Bits. '''ACHTUNG: dadurch neue Command-Codes!'''
* 29.08.2010: Kaseikyo-Protokoll: Verbesserte Behandlung von Wiederholungs-Frames
* 29.08.2010: Verbesserte Unterstützung des APPLE-Protokolls. '''ACHTUNG: dadurch neue Adress-Codes!'''

* 01.07.2010: Bugfix: Einführen eines Timeouts für NEC-Repetition-Frames, um "Geisterkommandos" zu verhindern.

* 26.06.2010: Bugfix: Deaktivieren von RECS80, RECS80EXT & SIEMENS bei geringer Interrupt-Rate

* 25.06.2010: '''Neues Protokoll''': RCCAR
* 25.06.2010: Tastenerkennung für FDC-Protokoll (IR-keyboard) erweitert
* 25.06.2010: Interrupt-Frequenz nun bis zu 20kHz möglich

* 09.06.2010: '''Neues Protokoll''': FDC (IR-keyboard)
* 09.06.2010: Timing für DENON-Protokoll korrigiert

* 02.06.2010: '''Neues Protokoll''': Siemens (Gigaset)

* 26.05.2010: '''Neues Protokoll''': Nokia
* 26.05.2010: Bugfix Auswertung von langen Tastendrücken bei Grundig-Protokoll

* 17.05.2010: Bugfix SAMSUNG32-Protokoll: Kommando-Bit-Maske korrigiert

* 16.05.2010: '''Neues Protokoll''': Grundig
* 16.05.2010: Behandlung von automatischen Frame-Wiederholungen beim SIRCS-, SAMSUNG32- und NUBERT-Protokoll verbessert.

* 28.04.2010: Nur einige kosmetische Code-Optimierungen

* 16.04.2010: Sämtliche Timing-Toleranzen angepasst/optimiert

* 12.04.2010: '''Neues Protokoll''': Bang & Olufsen

* 29.03.2010: Bugfix beim Erkennen von mehrfachen NEC-Repetition-Frames
* 29.03.2010: Konfiguration in irmpconfig.h ausgelagert
* 29.03.2010: Einführung einer Programmversion in README.txt: Version 1.0

* 17.03.2010: '''Neues Protokoll''': Nubert

* 16.03.2010: Korrektur der RECS80-Startbit-Timings
* 16.03.2010: '''Neues Protokoll''': RECS80 Extended

* 15.03.2010: Codeoptimierung

* 14.03.2010: Portierung auf PIC

* 11.03.2010: Anpassungen an verschiedene ATMega-Typen durchgeführt

* 07.03.2010: Bugfix: Zurücksetzen der Statemachine nach einem unvollständigen RC5-Frame

* 05.03.2010: '''Neues Protokoll''': Apple
* 05.03.2010: Die Daten irmp_data.addr + irmp_data.command werden nun in der jeweiligen Bit-Order des verwendeten Protokolls gespeichert

* 04.03.2010: '''Neues Protokoll''': SAMSUNG32 (Mix aus SAMSUNG & NEC-Protokoll)
* 04.03.2010: Änderung der SIRCS- und Kaseikyo-Toleranzen

* 02.03.2010: SIRCS: Korrekte Erkennung und Unterdrückung von automatischen Frame-Wiederholungen
* 02.03.2010: SIRCS: Device-ID-Bits werden nun in irmp_data.command und nicht mehr in irmp_data.address gespeichert
* 02.03.2010: Vergrößerung des Scan Buffers (zwecks Protokollierung)

* 24.02.2010: Neue Variable flags in IRMP_DATA zur Erkennung von langen Tastendrücken

* 20.02.2010: Bugfix Denon-Protokoll: Wiederholungsframe grundsätzlich invertiert

* 19.02.2010: Erkennung von NEC-Protokoll-Varianten, z. B. Apple-Fernbedienung
* 19.02.2010: Erkennung von RC6- und Denon-Protokoll
* 19.02.2010: Verbesserung des RC5-Decoders (Bugfixes)

* 13.02.2010: Bugfix: Puls/Pausen-Counter um 1 zu niedrig, nun bessere Erkennung bei Protokollen mit sehr kurzen Pulszeiten
* 13.02.2010: Erkennung der NEC-Wiederholungssequenz

* 12.02.2010: RC5-Protokoll-Decoder hinzugefügt

* 05.02.2010: Konflikt zwischen Samsung- und Matsushita-Protokoll beseitigt

* 07.01.2010: Erste Version

== Software-Historie IRSND ==

Änderungen IRSND:

Version 2.2.0:
* 23.05.2012: Portierung auf ARM STM32 (ungetestet!)
* 23.05.2012: Bugfix Timing für 2. Frame beim Denon-Protokoll

Ältere Versionen:

* 27.02.2012: '''Neues Protokoll''': IR60
* 27.02.2012: Bug beim Senden von Bi-Phase-Frames (Manchester) behoben
* 27.02.2012: Portierung auf C18 Compiler für PIC-Mikroprozessoren
* 15.02.2012: Bugfix: Nur der 1. Frame wurde gesendet
* 13.02.2012: Timing von SAMSUNG- und SAMSUNG32-Protokoll korrigiert
* 13.02.2012: Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
* 13.02.2012: Zusätzliche Pause nach dem Senden des letzten Frames
* 20.09.2011: '''Neues Protokoll''': THOMSON
* 20.09.2011: '''Neues Protokoll''': LEGO
* 20.09.2011: '''Neues Protokoll''': NEC16
* 20.09.2011: '''Neues Protokoll''': NEC42
* 20.09.2011: Portierung auf ATtiny84 und ATtiny85
* 20.09.2011: Korrektur von Pausenlängen
* 20.09.2011: Korrekturen von irsnd_stop()
* 20.09.2011: Korrektur des SIEMENS-Timings
* 20.09.2011: Umstellung auf 36kHz Modulationsfrequenz für DENON-Protokoll
* 20.09.2011: Korrektur Behandlung zusätzlicher Bits im SIRCS Protokoll
* 18.01.2011: '''Neues Protokoll''': RC6A
* 18.01.2011: '''Neues Protokoll''': RC6
* 18.01.2011: '''Neues Protokoll''': NIKON
* 18.01.2011: Beachten der zusätzlichen Bits (>12) im SIRCS-Protokoll
* 18.01.2011: Korrektur der Pausenlängen
* 18.01.2011: Timing-Korrekturen für Denon-Protokoll

* 02.09.2010: Neues Protokoll: JVC
* 02.09.2010: Anpassung des APPLE-Encoders an IRMP-Version 1.7.3.

* 29.08.2010: Neues Protokoll: Kaseikyo (Panasonic u.a.)

* 01.07.2010: Bugfix: Deaktivieren von RECS80, RECS80EXT & SIEMENS bei geringer Interrupt-Rate

* 25.06.2010: Neues Protokoll: RCCAR

* 09.06.2010: Neues Protokoll: FDC (IR-keyboard)
* 09.06.2010: Timing für DENON-Protokoll korrigiert

* 02.06.2010: Neues Protokoll: Siemens (Gigaset)
* 02.06.2010: Simulation von langen Tastendrücken

* 26.05.2010: Neues Protokoll: Nokia

* 17.05.2010: Neues Protokoll: Grundig
* 17.05.2010: Behandlung von Frame-Wiederholungen für SIRCS, SAMSUNG32 und NUBERT korrigiert

* 28.04.2010: Unterstützung des APPLE-Protokolls
* 28.04.2010: Konfiguration über irmpconfig.h

* 16.04.2010: Sämtliche Timing-Toleranzen angepasst/optimiert

* 14.04.2010: Neues Protokoll: Bang & Olufsen

* 17.03.2010: Neues Protokoll: Nubert
* 17.03.2010: Korrektur der Pausen zwischen Frame-Wiederholungen

* 16.03.2010: Korrektur des Timer-Registers TCCR2
* 16.03.2010: Korrektur der RECS80-Startbit-Timings
* 16.03.2010: Neues Protokoll: RECS80 Extended

* 11.03.2010: Anpassungen an verschiedene ATMega-Typen durchgeführt

* 07.03.2010: Alpha-Version

== Literatur ==

''' IR-Übersicht ''':

* http://www.epanorama.net/links/irremote.html
* http://www.elektor.de/jahrgang/2008/juni/cc2-avr-projekt-%283%29-unsichtbare-kommandos.497184.lynkx?tab=4 (IR Übersicht & RC5)

'''SIRCS-Protokoll''':

* http://www.sbprojects.com/knowledge/ir/sirc.htm
* http://www.ustr.net/infrared/sony.shtml
* http://users.telenet.be/davshomepage/sony.htm
* http://picprojects.org.uk/projects/sirc/

'''NEC-Protokoll:'''

* http://www.sbprojects.com/knowledge/ir/nec.htm
* http://www.ustr.net/infrared/nec.shtml
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf

'''NEC16-Protokoll (JVC):'''

* http://www.ustr.net/infrared/jvc.shtml

'''SAMSUNG-Protokoll:'''

(wurde aus diversen Protokollen (Daewoo u.ä.) zusammengereimt, daher kein direkter Link auf irgendwelche SAMSUNG-Dokumentation verfügbar)

Hier ein Link zum Daewoo-Protokoll, welches dasselbe Prinzip des Sync-Bits in der Mitte eines Frames nutzt, jedoch mit anderen Timing-Werten arbeitet:

* http://users.telenet.be/davshomepage/daewoo.htm

'''MATSUHITA-Protokoll:'''

* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf

'''KASEIKYO-Protokoll (auch "Japan-Protokoll"):'''

* http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf
* http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf

'''RECS80- und RECS80-Extended-Protokoll:'''

* http://www.sbprojects.com/knowledge/ir/recs80.htm

'''RC5- und RC5x-Protokoll:'''

* http://www.sbprojects.com/knowledge/ir/rc5.htm
* http://users.telenet.be/davshomepage/rc5.htm

'''Denon-Protokoll:'''

* http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON

'''RC6 und RC6A-Protokoll:'''

* http://www.sbprojects.com/knowledge/ir/rc6.htm
* http://slycontrol.ru/scr/kb/rc6.htm
* http://www.picbasic.nl/info_rc6_uk.htm

'''Bang & Olufsen:'''

* http://www.mikrocontroller.net/attachment/33137/datalink.pdf

'''Grundig'''

* http://www.mikrocontroller.net/attachment/77507/Grundig_10bit.pdf

'''Nokia'''

* http://www.sbprojects.com/knowledge/ir/nrc17.htm

'''IR60 (SDA2008 bzw. MC14497P)'''

* http://www.datasheetarchive.com/dl/Datasheets-24/DSA-478524.pdf
* http://www.datasheetcatalog.org/datasheet/motorola/MC14497P.pdf

'''Diverse Protokolle:'''

* http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf
* http://www.opendcc.de/info/rc5/rc5.html
* http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf

== Hardware / IRMP-Projekte ==

Eine Implementierung auf Basis IRMP und IRSND als Multiprotokoll Dekoder mit LCD
von Klaus Leidinger:
* http://www.mikrocontroller-projekte.de/Mikrocontroller/index.html

Ähnliche Implementierung wie von Klaus Leidinger für Pollin AVR-NET-IO mit Pollin ADD-ON Board:
* http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=703

USB IR Remote Receiver von Hugo Portisch:
* http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver

Servo-gesteuerter IR Sender mit Anlernfunktion von Stefan Pendsa:
* http://forum.mikrokopter.de/topic-21060.html
* (SVN) http://svn.mikrokopter.de/listing.php?repname=Projects&path=%2FServo-Controlled+IR-Transmitter%2F&#Ad2417800d6aa14bf08c571a896e9def7

Lernfähige IR-Fernbedienung von Robert und Frank M.
* http://www.mikrocontroller.net/articles/DIY_Lernfähige_Fernbedienung_mit_IRMP

== Danksagung ==

Ganz herzlich bedanken möchte ich mich bei Vlad Tepesch, Klaus Leidinger und Peter K., die mich mit Scan-Dateien ihrer Infrarot-Fernbedienungen versorgt haben. Dank auch an Klaus für seine nächtelangen Tests von IRMP & IRSND.

Ebenso bedanken möchte ich mich bei Christian F. für seine Tipps zur PIC-Portierung. Vielen Dank auch an gera für die Portierung auf den PIC-C18 Compiler.

Für die Portierung auf ARM STM32 bedanke ich mich herzlich bei kichi (Michael K.).

== Diskussion ==

Meinungen, Verbesserungsvorschläge, harsche Kritik und ähnliches kann im [http://www.mikrocontroller.net/topic/162119 Beitrag: Infrared Multi Protocol Decoder] geäussert werden.

Viel Spaß mit IRMP!

[[Kategorie:Infrarot]]
[[Kategorie:AVR-Projekte]]

USB IR Remote Receiver

2012-05-21T18:38:49Z

Muebau: /* Hardware / Projekte */

Ein Infrarot-Multiprotokoll-Decoder in Kombination mit [[IRMP]] von Frank M. und [http://www.obdev.at/products/vusb/index-de.html V-USB] für die USB Schnittstelle

== Einleitung ==
Motivation für das Projekt war der veraltete Igor-IR Empfänger. Auch wie Frank M. in seinem Artikel beschreibt ist das RC5 Protokoll veraltet und findet in neuen Geräten fast keine Anwendung mehr. Auch habe ich mich für die USB Lösung entschieden, da heutzutage nicht mehr jedes PC-Mainboard über eine RS-232 Schnittstelle verfügt.
Durch Irmp - der Infrarot-Fernbedienungsdecoder der mehrere Protokolle auf einmal decodieren kann, ist es möglich folgende Protokolle zu empfangen und auszuwerten:

{| class="wikitable"
! Protokoll || Hersteller
|-
| SIRCS || Sony
|-
| NEC || NEC, Yamaha, Canon, Tevion, Harman/Kardon, Hitachi, JVC, Pioneer, Toshiba, Xoro, Orion, NoName und viele weitere japanische Hersteller.
|-
| SAMSUNG || Samsung
|-
| SAMSUNG32 || Samsung
|-
| MATSUSHITA || Matsushita
|-
| KASEIKYO || Panasonic, Technics, Denon und andere japanische Hersteller, welche Mitglied der "Japan's Association for Electric Home Application" sind.
|-
| RECS80 || Philips, Nokia, Thomson, Nordmende, Telefunken, Saba
|-
| RECS80EXT || Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
|-
| RC5 || Philips und andere europäische Hersteller
|-
| DENON || Denon, Sharp
|-
| RC6 || Philips und andere europäische Hersteller
|-
| RC6A || Philips, Kathrein und andere Hersteller, z.B. XBOX
|-
| APPLE || Apple
|-
| NUBERT || Nubert, z.B. Subwoofer System
|-
| B&O || Bang & Olufsen
|-
| GRUNDIG || Grundig
|-
| NOKIA || Nokia, z.B. D-Box
|-
| SIEMENS || Siemens, z.B. Gigaset M740AV (ab ~15kHz, siehe Bemerkungen zu F_INTERRUPTS)
|-
| FDC || FDC Keyboard (ab ~15kHz)
|-
| RCCAR || RC Car: IR Fernbedienung für Modellfahrzeuge
|-
| JVC || JVC
|-
| NIKON || NIKON
|-
| RUWIDO || RUWIDO (z.B. T-Home-Mediareceiver)
|-
| KATHREIN || KATHREIN
|-
| NEC16 || JVC
|-
| NEC42 || JVC
|-
| LEGO || Lego
|-
| THOMSON || Thomson
|}

== Funktionen/Vorteile gegenüber anderen IR Empfängern ==
* Der AVR-Source ist für fast alle Mikrochips einsetzbar
* Bei vorhandenen modifizierten [[#bootloadHID]] kann schnell und einfach ein Firmware Update des Mikrochips über die USB Schnittstelle durchgeführt werden
* Der Empfänger hat eine PowerOn Funktion um den Host per Fernbedienung ein/aus-schalten zu können (deaktivierbar)
* Es sind keine speziellen Treiber notwendig, egal ob Windows XP oder Windows 7
* Tastenentprellung im Mikrochip selber (einstellbar)
* Durch die Verwendung der [[#USB IR Remote Receiver DLL]] hat der Benutzer leicht die Möglichkeit die dekodierten IR-Codes auszuwerten.

== Arbeitsweise ==
Durch V-USB wird eine rein Softwaremässige USB Schnittstelle geschaffen. Somit können auch Mikrokontroller ohne USB-Schnittstelle wie z.B. der Atmega8-16 eingesetzt werden. Durch V-USB arbeitet der AVR als Low Speed USB 1.1 HID Gerät. Durch die Benutzung von Standard HID-Funktionen wird kein spezieller USB Treiber benötigt.

Wenn ein IR-Code dekodiert wurde wird dieser per USB Interrupt Transfer vom Gerät an den Host gesendet. Die Auswertung des IR-Codes übernimmt der Host.

Die PowerOn Funktion speichert den ersten empfangenen IR-Code im EEPROM. Wird dieser erneut empfangen wird der definierte Ausgang für die PowerOn Funktion für ~250ms auf +VCC geschaltet. Dieser IR-Code wird dann nicht mehr zum Host weiter gesendet. Die PowerOn Funktion lässt sich über den Settings/Optionen Dialog deaktivieren.

Durch Irmp lässt sich auch die Fernbedienung bereits im Gerät entprellen. Die Entprellung ist über den Settings/Optionen Dialog einstellbar.

== Download ==

Stand vom 02.01.2012

Download des kompletten Paketes:
[[http://www.mikrocontroller.net/wikifiles/e/e5/USB_IR_Remote_Receiver_Complete.zip USB IR Remote Receiver Complete]]

Dieser Download beinhaltet:
* Release der USB IR Remote Receiver DLL

* Sourcecode AVR USB IR Remote Receiver
* Release AVR USB IR Remote Receiver für Atmega8 und Atmega168p
* Sourcecode & Release AVR modifizierter bootloadHID v1.1 für Atmega8
* Sourcecode & Release AVR modifizierter bootloadHID v1.1 für Atmega168p

* Sourcecode & Release Visual Studio 2008 Demo Konsole Anwendung
* Sourcecode & Release Delphi 2010 Demo Anwendung
* Sourcecode & Release Visual Studio 2008 C# Demo Anwendung (Danke an Michael Kipp)

* Plugin für EventGhost

* Beschreibung in Englisch als Html

Änderungen:

{| class="wikitable"
! Datum || Änderung
|-
| 02.01.2012 || DLL:
* v1.0.0.14, IR Polling entfernt, IRMP Logging per USB hinzugefügt
AVR:
* v1.8, IR Polling entfernt, IRMP Logging per USB hinzugefügt. Source für AVR Studio v5 konvertiert.
|-
| 26.10.2011 || DLL:
* v1.0.0.13, Neue Irmp Protokolle in die Standard Liste aufgenommen
AVR:
* v1.7, IRMP Update auf 20.09.2011, neues Protokoll RUWIDO, KATHREIN, NEC16, NEC42, LEGO und THOMSON.
|-
| 14.07.2011 || DLL:
* v1.0.0.12, Problem mit EventGhost behoben
|-
| 28.02.2011 || Demo:
* neuen Demo Source für Visual Studio 2008 C# aufgenommen. Danke an Michael Kipp für seine Arbeit
|-
| 27.02.2011 || DLL:
* v1.0.0.11, Problem mit EventGhost behoben, Problem mit InitNative/InitPAnsiChar behoben
|-
| 04.02.2011 || AVR:
* v1.6, Source und Release für Atmega8/Atmega168p.
* bootLoadHID v1.1 Source und Release für Atmega8/Atmega168p.
|-
| 27.01.2011 || DLL:
* v1.0.0.10, Neue Irmp Protokolle in die Standard Liste aufgenommen.
AVR:
* v1.5, IRMP Update auf 18.01.2011, neues Protokoll RC6A, JVC und NIKON.
|-
| 28.06.2010 || DLL:
* v1.0.0.9, Neue Irmp Protokolle in die Standard Liste aufgenommen.
AVR:
* v1.4, IRMP Update auf 26.06.2010, neues Protokoll FDC und RCCAR.
|-
| 06.06.2010 || DLL:
* v1.0.0.8, Protokolle die in der INI Datei fehlen werden nun automatisch eingetragen. Neue Irmp Protokolle in die Standard Liste aufgenommen.
AVR:
* v1.3, IRMP Update auf 02.06.2010, neues Protokoll NOKIA und SIEMENS
|-
| 18.05.2010 || DLL:
* v1.0.0.7, Grundig Protokoll für INI-Datei aufgenommen. Bei fehlender INI-Datei werden die Protokolle automatisch eingetragen. Beim manuellen Einfügen von "GRUNDIG=15" kann auch die alte v1.0.0.6 weiter verwendet werden. Siehe INI Beschreibung.
AVR:
* v1.2, IRMP Update auf 17.05.2010, neues Protokoll GRUNDIG, Bugfix SAMSUNG32
|-
| 09.05.2010 || DLL:
* v1.0.0.6, Bugfix für Standby - die Verbindung zum Gerät wurde nicht richtig getrennt
Sonstiges:
* Plugin für EventGhost wurde hinzugefügt
* Dokumentation überarbeitet
|-
| 02.05.2010 || Dokumentation überarbeitet, PonyProg2000 im Schaltplan aufgenommen.
|-
| 28.04.2010 || DLL:
* v1.0.0.5, Möglichkeit um die Firmware über den Settings/Optionen Dialog auf den Mikrochip programmieren zu können hinzugefügt.

AVR:
* Bugfix der Entprellung
* Irmp Version Update auf 28.04.2010
* modifizierter bootloadHID um über den Settings/Optionen Dialog eine neue Firmware aufspielen zu können
|-
| 23.04.2010 || DLL:
* v1.0.0.4, Tasten Unterdrückung für träge Host Anwendung hinzugefügt
* Bugfix für Settings/Optionen Dialog und DVBViewer

AVR:
* Bugfix der Entprellung wenn die Taste länger als 255 Wiederholungen gedrückt war
* Erkennung/Auswertung des PowerOn IR-Code optimiert
|-
| 16.04.2010 || DLL:
* v1.0.0.3, InitNative, InitPAnsiChar und Girder Unterstützung hinzugefügt

AVR:
* Irmp Version Update auf 16.04.2010
|-
| 12.04.2010 || AVR:
* Irmp Version Update auf 12.04.2010, neues Protokoll B&Q
|}

=== AVR Source ===

Der Source kann mit [http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=2725 AVR-Studio] und [http://winavr.sourceforge.net WinAVR] kompiliert werden.
Ab AVR v1.8 wird nun AVR Studio v5 benutzt und somit ist kein extra WinAVR mehr notwendig.

'''Achtung IRMP ab 26.06.2010'''

Mittlerweile sind die unterstützen Protokolle von Irmp so viel geworden, dass nicht mehr alle in den Flash des Atmega8 mit dem Bootloader passen.

Als Alternative kann der Atmega168p verwendet werden.

Man sollte also für seine eigene Verwendung die Protokolle in der '''irmpconfig.h''' aktivieren die man benötigt und den AVR Source neu kompilieren!

Es ist eine fertige Version mit im Paket die auf den Atmega8 passt und diese Protokolle unterstützt:

<c>
// typical protocols, disable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 ~150 bytes
#define IRMP_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 ~300 bytes
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 ~300 bytes
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 ~50 bytes
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 ~250 bytes
#define IRMP_SUPPORT_DENON_PROTOCOL 1 // DENON, Sharp >= 10000 ~250 bytes

// more protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_RC5_PROTOCOL 0 // RC5 >= 10000 ~250 bytes
#define IRMP_SUPPORT_RC6_PROTOCOL 0 // RC6 & RC6A >= 10000 ~250 bytes
#define IRMP_SUPPORT_JVC_PROTOCOL 0 // JVC >= 10000 ~150 bytes
#define IRMP_SUPPORT_NEC16_PROTOCOL 0 // NEC16 >= 10000 ~100 bytes
#define IRMP_SUPPORT_NEC42_PROTOCOL 0 // NEC42 >= 10000 ~300 bytes
#define IRMP_SUPPORT_IR60_PROTOCOL 0 // IR60 (SAB2008) >= 10000 ~300 bytes
#define IRMP_SUPPORT_GRUNDIG_PROTOCOL 0 // Grundig >= 10000 ~300 bytes
#define IRMP_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens Gigaset >= 15000 ~550 bytes
#define IRMP_SUPPORT_NOKIA_PROTOCOL 0 // Nokia >= 10000 ~300 bytes

// exotic protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_KATHREIN_PROTOCOL 0 // Kathrein >= 10000 ~200 bytes
#define IRMP_SUPPORT_NUBERT_PROTOCOL 0 // NUBERT >= 10000 ~50 bytes
#define IRMP_SUPPORT_BANG_OLUFSEN_PROTOCOL 0 // Bang & Olufsen >= 10000 ~200 bytes
#define IRMP_SUPPORT_RECS80_PROTOCOL 0 // RECS80 (SAA3004) >= 15000 ~50 bytes
#define IRMP_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT (SAA3008) >= 15000 ~50 bytes
#define IRMP_SUPPORT_THOMSON_PROTOCOL 0 // Thomson >= 10000 ~250 bytes
#define IRMP_SUPPORT_NIKON_PROTOCOL 0 // NIKON camera >= 10000 ~250 bytes
#define IRMP_SUPPORT_NETBOX_PROTOCOL 0 // Netbox keyboard >= 10000 ~400 bytes (PROTOTYPE!)
#define IRMP_SUPPORT_FDC_PROTOCOL 0 // FDC3402 keyboard >= 10000 (better 15000) ~150 bytes (~400 in combination with RC5)
#define IRMP_SUPPORT_RCCAR_PROTOCOL 0 // RC Car >= 10000 (better 15000) ~150 bytes (~500 in combination with RC5)
#define IRMP_SUPPORT_RUWIDO_PROTOCOL 0 // RUWIDO, T-Home >= 15000 ~550 bytes
#define IRMP_SUPPORT_LEGO_PROTOCOL 0 // LEGO Power RC >= 20000 ~150 bytes
</c>

'''Konfigurationen AVR Source bootloadHID'''

Auch die modifizierte Version des bootloadHID kann mit AVR-Studio und WinAVR kompiliert werden. Je nach Mikrochip muss die Bootloader Adresse in AVR-Studio eingestellt werden. Der Bootloader benötigt 2048 Bytes.

In der Menüleiste unter ''Project''->''Configuration Options''->''Custom Options''->''[Linker Options]'' die Zeile

Atmega8:
<c>-Wl,--section-start=.text=0x1800</c>

Atmega168p:
<c>-Wl,--section-start=.text=0x3800</c>

auf die richtige Bootloader Adresse ändern.

= Schaltplan des USB IR Remote Receiver =
[[Datei:USB_IR_Remote_Receiver_schematic.jpg|1000px]]

'''Erläuterung'''

Die Z-Dioden ZD1 und ZD2 werden benötigt, um dem USB Standard zu entsprechen.

Es können folgende IR Empfänger Dioden eingesetzt werden:

Vishay TSOP 1738, Vishay TSOP 1838, Vishay TSOP 11xx series, Siemens SFH 5110, Radio Shack 276-0137, Mitsumi IR Preamp KEY-COOSV (0924G),
Toshiba TK19 444 TFMS 5360, Temic TFMS 5380 by Telefunken Semiconductors, Sharp IS1U60, Everlight IRM-8601S, Sony SBX 1620-12, Sharp GP1U271R

Optional: R6 und OK1: diese Bauteile werden für die PowerOn Funktion benötigt um den Host PC über den Power Schalter ein/ausschalten zu können.

Optional: J1: wird nur für den nicht modifizierten bootloadHID Bootloader benötigt.

Optional: CN2, R8 und R9: werden nur benötigt falls man keinen Programmer hat und den Mikrochip mit PonyProg2000 über den LPT Port programmieren will.

== Foto eines aufgebauten USB IR Remote Receiver ==
[[Datei:avr_hardware_front.jpg|300px]][[Datei:avr_hardware_back.jpg|300px]]

[[Datei:USB_IR_Remote_Receiver_Top.jpg|300px]][[Datei:USB_IR_Remote_Receiver_Bot.jpg|300px]]

[[Datei:Plot USBIRRR Page 1.jpg|300px]]
[[Datei:Plot USBIRRR Page 2.jpg|300px]]

'''Aufbau als Stick'''

[[Datei:USBIRRR Stick Bottom.jpg|320px]]
[[Datei:USBIRRR Stick Top.jpg|300px]]
[[Datei:USBIRRR Stick Case.jpg|300px]]

= USB IR Remote Receiver DLL =

Die inkludierte '''USB_IR_Remote_Receiver.dll''' übernimmt für den Anwender die Kommunikation des Host PCs mit der Hardware. Somit braucht sich der Anwender nicht um die Geräte Verbindung zu kümmern. Empfangene IR-Codes werden von der DLL an die Host-Anwendung per CallBack Funktion weiter gereicht.

'''Die DLL Unterstützt folgende Host-Anwendungen:'''
* [http://www.dvbviewer.com DVBViewer] als Input-Plugin: Die DLL muss sich im DVBViewer\Plugins Ordner befinden
* [http://www.promixis.com Girder] als Input-Plugin: Die DLL muss sich im Girder\Plugins Ordner befinden, es wird Girder ab Version 3.2.9 unterstüzt.
* [http://www.eventghost.org EventGhost] als Input-Plugin: Die DLL und die '__init__.py' muss sich im EventGhost\plugins\USBIRRemoteReceiver Ordner befinden
* Native: mit den Funktionen ''InitNative'' und ''InitPAnsiChar'' kann die DLL kann auch für selbst geschriebene Anwendungen verwendet werden

== Settings/Optionen Dialog ==

[[Datei:MainScreen.jpg]]

{| class="wikitable"
|+ '''Settings/Optionen Dialog'''
|-
! Objekt || Beschreibung
|-
| Device Connected || Wenn das Gerät verbunden ist erscheint ein grünes Icon. auch wird die beinhaltete Irmp Version angezeigt. Auch die USB IR Remote Receiver Mikrochip Version wird angezeigt.
|-
| PowerOn Function Status || Wenn die PowerOn Funktion im Gerät aktiviert ist erscheint das grüne Icon. Mit dem Button kann man die Funktion im Gerät aktivieren/deaktivieren.
|-
| Disable PowerOn when initialized || Ist diese Option aktiviert, wird beim initialisieren des Gerätes durch die Host Anwendung die PowerOn Funktion deaktiviert. Beim Entladen der DLL oder bei Standby/Ruhezustand des Hosts-PCs wird die PowerOn Funktion wieder aktiviert um den PC wieder einschalten zu können. Somit kann die gleiche Taste auf einer Fernbedienung zum Einschalten des PC und in der Software für eine andere Funktion verwendet werden.
|-
| Received IR Code || Hier wird der zuletzt empfangene IR-Code angezeigt. Wenn der Settings/Optionen Dialog sichtbar ist wird der IR-Code nicht zur Host Anwendung weiter gerreicht und man kann verschiedene Tasten der Fernbedienung ausprobieren ohne in der Host Anwendung etwas auszulösen.
|-
| Trained IR Code || Hier wird der gespeicherte IR-Code, der für die PowerOn Funktion verwendet wird, angezeigt.
|-
| Read Trained IR Code || Hier kann der aktuelle gespeicherte IR-Code für die PowerOn Funktion aus dem EEPROM ausgelesen werden.
|-
| Clear Trained IR Code || Hier kann der aktuelle gespeicherte IR-Code für die PowerOn Funktion im EEPROM gelöscht werden. Bei nicht vorhanden sein eines IR-Codes im EEPROM wird automatisch der nächste empfangene IR-Code wieder abgespeichert. Dieser wird dann wieder für die PowerOn Funktion verwendet.
|-
| Enable IRMP Logging || Wenn die Fernbedinung von IRMP nicht erkannt wird kann man mit dieser Option die rohen IR Signale loggen. Der AVR Source muss dazu mit IRMP_LOGGING=1 kompiliert sein.
|-
| Minimum of Repeats || Hier kann die Entprellung der Fernbedienung eingestellt werden. Je höher dieser Wert ist um so mehr Wiederholungen des IR-Codes müssen vorkommen bis sie wieder ohne Einschränkungen zur Host Anwendung durchgelassen werden. Ein Wert von 0 bedeutet keine Entprellung. (Default 5)
|-
| Flash/Update Firmware || Diese Funktion ist ab USB IR Remote Receiver v1.1 oder wenn sich das Gerät im Bootloader Modus befindet verfügbar. Es wird ein neuer Dialog geöffnet wo es möglich ist eine Intel-HEX Datei auszuwählen und die Firmware des Gerätes zu erneuern.
|}

== IRMP Logging ==
Ist auf dem AVR eine Firmware mit der Kompileroption IRMP_LOGGING = 1 können die Rohdaten des IR Signales aufgezeichnet werden.

Dazu muss im Optionen Dialog die Option "Enable IRMP Logging" aktiviert werden. Nun wird bei empfangenen Rohdaten eine Beschreibung der zuletzt gedrückten Taste auf der Fernbedienung verlangt. Die Rohdaten werden danach in das Textfile "IRMP_Log.txt" im selben Ordner wo sich die DLL befindet geschrieben.

Dieses Textfile kann zur Analyse der IR Signale verwendet werden. Auch können die Rohdaten direkt mit der "irmp.exe" analysiert werden:

<c>C:\Program Files (x86)\DVBViewer\Plugins>irmp.exe <IRMP_Log.txt
-------------------------------------------------------------------
# 1
-------------------------------------------------------------------
# 02.01.12 17:18:32
00000010111111011000000001111111 p = 2, a = 0xbf40, c = 0x0001, f = 0x00
p = 2, a = 0xbf40, c = 0x0001, f = 0x01</c>

== Flash/Update Firmware Dialog ==

[[Datei:FlashScreen.jpg]]

{| class="wikitable"
|+ '''Flash/Update Firmware Dialog'''
|-
! Objekt || Beschreibung
|-
| Load Intel HEX File|| Hier kann die USB IR Remote Receiver Firmware einfach in das Gerät eingespielt werden. Die Firmware ist auf die Größe des verwendeten Mikrochips Flashes minus der Bootloader Größe (2048 Bytes) beschränkt. Beim Atmega8 sind es dann z.B. maximal Flash 8192 Bytes - Bootloader 2048 Bytes = 6144 Bytes. Beim Atmega168p sind es dann z.B. maximal Flash 16384 Bytes - Bootloader 2048 Bytes = 14336 Bytes.
Wenn das Gerät sich im Normal Betrieb befindet wird zuerst das Gerät neu gestartet um es in den Bootloader Modus zu versetzen. Danach wird die neue Firmware automatisch eingespielt. Nach dem Einspielen wird das Gerät neu gestartet und es sollte dann die neue Firmware automatisch gestartet werden.

Um die volle Funktion des Einspielen einer neuen Firmware zu haben sollte die modifizierte Version von [[#bootloadHID]] verwendet werden.
|}

== USB IR Remote Receiver INI ==
Beim ersten mal Initialisieren der DLL wird eine ''USB_IR_Remote_Receiver.ini'' im gleichen Ordner wo sich die DLL befindet erzeugt.

{| class="wikitable"
|+ '''USB_IR_Remote_Receiver.ini'''
|-
! Sektion || Beschreibung
|-
| [IRMP Protocols] || Hier wird die Liste der unterstützen Protokolle von Irmp eingetragen. Sollte ein neues Protokoll hinzukommen kann dies einfach hier ergänzt werden ohne das es nötig ist die DLL zu erneuern.

Format:
''Name_des_Protokolls''=''Irmp_ID''

z.B.:
''NEC''=''2''
|-
| [Settings] || '''Gerätverbindung Startverzögerung'''
Um der Host Anwendung genug Zeit zu lassen kann eine Startverzögerung zwischen Initialisieren und verbinden mit dem Gerät eingestellt werden.

Format:
''StartUpDelay''=''gewünschter_Wert_in_Millisekunden''

z.B.:
''StartUpDelay''=''2000''

Default: 2000ms

'''Tasten Unterdrückung'''
Sollte die verwendete Host Anwendung eher träge reagieren - d.h. nicht schnell genug sein um die empfangenen IR-Codes umzusetzen kann eine Tasten Unterdrückung zusätzlich aktiviert werden.

Format:
''Key Suppression''=''gewünschter_Wert_in_Millisekunden''

z.B.:
''Key Suppression''=''200''

Default: 0ms - deaktiviert

'''Debug LOG'''
Um das Debug Logmemo im Settings/Optionen Dialog anzuzeigen kann dieser Wert eingetragen werden:

Format:
''Debug''=''0/1''

z.B.:
''Debug''=''0''

Default: 0 - deaktiviert
|}

= bootloadHID =

Um einfach in das Gerät eine neue Firmware einspielen zu können wurde das Projekt [http://www.obdev.at/products/vusb/prjdetail.php?pid=32 bootloadHID] etwas verändert.

Es kann nun aus der eigentlichen Firmware das Gerät in den Bootloader Modus gebracht werden ohne den Jumper setzen oder das Gerät aus/einstecken zu müssen.

Das Gerät kann nun in den Bootloader Modus gebracht werden wenn:
* der Jumper gesetzt ist
* keine USB IR Remote Receiver Firmware im Flash ist
* die USB IR Remote Receiver Firmware den Bootloader Modus startet

Bei einem leeren Gerät sollte zuerst mit einem Programmer oder mit PonyProg2000 über den LPT Port der Bootloader aufgespielt werden. Die USB IR Remote Receiver Firmware selber kann danach einfach über den Settings/Optionen Dialog eingespielt werden.

'''Fuses'''

Beim Bootloader ist es wichtig die Fuse Bits richtig zu setzten, denn ansonsten kann es nach dem ersten Update der Firmware vorkommen dass der Bootloader gelöscht wird. Wenn ein anderer Mikrochip als der Atmega8 verwendet wird muss gegebenfalls auch die Adresse des Bootloader angepasst werden.

<c>###############################################################################
# Configure the following variables according to your AVR. The example below
# is for an ATMega8. Program the device with
# make fuse # to set the clock generator, boot section size etc.
# make flash # to load the boot loader into flash
# make lock # to protect the boot loader from overwriting

DEVICE = atmega8
BOOTLOADER_ADDRESS = 1800
F_CPU = 12000000
FUSEH = 0xc0
FUSEL = 0x9f

# Fuse high byte:
# 0xc0 = 1 1 0 0 0 0 0 0 <-- BOOTRST (boot reset vector at 0x1800)
# ^ ^ ^ ^ ^ ^ ^------ BOOTSZ0
# | | | | | +-------- BOOTSZ1
# | | | | + --------- EESAVE (preserve EEPROM over chip erase)
# | | | +-------------- CKOPT (full output swing)
# | | +---------------- SPIEN (allow serial programming)
# | +------------------ WDTON (WDT not always on)
# +-------------------- RSTDISBL (reset pin is enabled)
# Fuse low byte:
# 0x9f = 1 0 0 1 1 1 1 1
# ^ ^ \ / \--+--/
# | | | +------- CKSEL 3..0 (external >8M crystal)
# | | +--------------- SUT 1..0 (crystal osc, BOD enabled)
# | +------------------ BODEN (BrownOut Detector enabled)
# +-------------------- BODLEVEL (2.7V)
###############################################################################</c>

== Programmieren des Mikrochips mit PonyProg2000 über den LPT Port ==
Der Schaltplan enthält die Bauteile R8, R9 und CN2. Diese werden nur benötigt, wenn man über keinen Mikrochip Programmer verfügt. Ansonsten kann mit diesen 3 zusätzlichen Bauteilen der Mikrochip mit PonyProg2000 über den LPT Port eines PCs programmiert werden.

'''Beispiel eines LPT Kabels im Selberbau'''

[[Datei:LPT_cable.jpg]]

Nach dem Download und Installieren von PonyProg2000 muss dies zuerst Kalibriert werden. Dazu in der Menüleiste auf ''Setup''->''Calibration'' gehen und ausführen.

Danach kann der Mikrochip eingestellt werden. Für Atmega8 in der Menüleiste ''Device''->''AVR micro''->''ATmega8'' auswählen.

Dann kann das LPT Kabel mit dem Host PC Verbunden werden. Auch muss die USB Verbindung vorhanden sein, da der Mikrochip von dem USB-Port versorgt wird. Nun kann man die Verbindung mit dem Mikrochip mit ''Probe'' überprüfen.
[[Datei:I_O.JPG]]

Sollten hier Probleme auftreten kann es helfen in der ''PONYPROG2000.INI'' den Wert ''AutoDetectPorts=YES'' auf ''NO'' umzustellen. Eventuell muss dann noch bei ''LPTPorts'' die LPT Port Adresse eingetragen werden.

Wenn der Test OK verläuft kann nun die ''bootloadHID.hex'' Datei in der Menüleiste ''File''->''Open Device File...'' geöffnet werden. Es sollten nun lauter FF zu sehen sein. Der Bootloader startet beim Atmega8 erst ab Adresse 0x1800!

Nun sollten die Fuse Bits über die Menüleiste ''Command''->''Security and Configuration Bits...'' eingestellt werden:

[[Datei:fuses.JPG]]

Dannach auf ''Write'' drücken um die Fuses auf dem Mikrochip zu setzten. Danach kann das Fuses-Fenster geschlossen werden.

Nun in der Menüleiste über ''Command''->''Write All'' die zuvor geöffnete bootloadHID.hex auf den Mikrochip programmieren. Wenn dieser Vorgang abgeschlossen wurde zuerst PonyProg2000 beenden, USB Verbindung trennen und dann das LPT Kabel entfernen. Wenn keine Probleme auftreten wird das LPT-Kabel und PonyProg2000 nun jetzt nicht mehr gebraucht.

Nun kann der USB IR Remote Receiver über USB angeschlossen werden und es sollte sich ein USB Gerät Namens ''HIDBoot'' anmelden. Nun kann über den Settings/Optionen Dialog eine USB IR Remote Receiver Firmware aufgespielt werden.

= Weblinks =
'''V-USB''':
* http://www.obdev.at/products/vusb/index-de.html

'''PonyProg2000''':
* http://www.lancos.com/prog.html

== Hardware / Projekte ==

'''IRMP - Infrarot-Multiprotokoll-Decoder''':
* [[IRMP]]

'''Version auf Basis vom USBasp'''

Enthält auch ein Linux Kommandozeilen Tool:
* [[http://www.easyvdr-forum.de/forum/index.php?topic=13723.msg117780#msg117780 USBASP Einschalter]]

= Danksagung =
Vielen Dank an das Forum + Community für deren Unterstützung!

Auch speziellen Dank an Frank M. für sein Irmp.

= Diskussion =

Meinungen, Verbesserungsvorschläge oder Kritik kann im [http://www.mikrocontroller.net/topic/171111 Beitrag: USB IR Remote Receiver (V-USB + IRMP)] geäussert werden.

Viel Spaß mit dem USB IR Remote Receiver!

[[Kategorie:USB]]
[[Kategorie:Infrarot]]
[[Kategorie:AVR-Projekte]]

BMA020

2012-01-08T14:01:36Z

Muebau: /* Bezugsquellen */

Der BMA020 ist ein 3-Achsen-Beschleunigungssensor von Bosch der über I2C oder ISP ausgelesen und konfiguriert werden kann.

=BMA020=
==Bauteilseite==
[http://www.mikrocontroller.net/part/BMA020 Zur Bauteilseite des BMA020]

==Bezugsquellen==
===ELV===
http://www.elv.de/3-Achsen-Beschleunigungssensor-3D-BS,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_28515
===Farnell===
http://de.farnell.com/bosch/bma020-0330sb000b/daughter-board/dp/1795593?Ntt=BMA020

==Speicheraufteilung==
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Speicher'''
|-
! Adresse
! Bit 7
! Bit 6
! Bit 5
! Bit 4
! Bit 3
! Bit 2
! Bit 1
! Bit 0
! Typ
! Axis
|-
| 16h - 7Fh
|colspan="8"| -
| reserved
|rowspan="15"|
|-
| 15h
| SPI4E (4 wire SPI enable) (default: 1)
| EAI (enable advanced interrupt)
| NDI (new data interrupt)
| LI (latch interrupt)
|[[#Shadow disable|SD (shadow disable / read MSB only)]]
|colspan="2"| WUP (wake up pause)
| WU (wake up)
| control
|-
| 14h
|colspan="3"| - !!! - (NEVER ever change this registers)
|colspan="2"|[[#Range|range (+/-2/4/8g)]]
|colspan="3"|[[#Bandwith|bandwith (25...1500 Hz)]]
| control
|-
| 13h
|colspan="8" rowspan="2"| customer reserved (can be used as memory)
| status
|-
| 12h
| status
|-
| 11h
|colspan="2"| AMD (any motion duration)
|colspan="3"| HGH (high gravitation hysteresis)
|colspan="3"| LGH (low gravitation hysteresis)
| settings
|-
| 10h
|colspan="8"| AMT (any motion threshold)
| settings
|-
| 0Fh
|colspan="8"| HGD (high gravitation duration)
| settings
|-
| 0Eh
|colspan="8"| HGT (high gravitation threshold)
| settings
|-
| 0Dh
|colspan="8"| LGD (low gravitation duration)
| settings
|-
| 0Ch
|colspan="8"| LGT (high gravitation threshold)
| settings
|-
| 0Bh
| alert
| AM (any motion)
|colspan="2"| HGC (high gravitation counter)
|colspan="2"| LGC (low gravitation counter)
| HGE (high gravitation enable)
| LGE (low gravitation enable)
| control
|-
| 0Ah
| -
| reset INT
| -
| -
| self test 1
| self test 2
| soft reset
| sleep
| control
|-
| 09h
| STR (self test result)
|colspan="2"| -
| alert phase
| LG latched
| HG latched
| HGS (high gravitation status)
| LGS (low gravitation status)
| status
|-
| 08h
|colspan="8"| -
| data
|-
| 07h
| Z [9]
| Z [8]
| Z [7]
| Z [6]
| Z [5]
| Z [4]
| Z [3]
| Z [2]
| data
|rowspan="2"| Z
|-
| 06h
| Z [1]
| Z [0]
|colspan="5"| -
| NDZ (new data Z)
| data
|-
| 05h
| Y [9]
| Y [8]
| Y [7]
| Y [6]
| Y [5]
| Y [4]
| Y [3]
| Y [2]
| data
|rowspan="2"| Y
|-
| 04h
| Y [1]
| Y [0]
|colspan="5"| -
| NDY (new data Y)
| data
|-
| 03h
| X [9]
| X [8]
| X [7]
| X [6]
| X [5]
| X [4]
| X [3]
| X [2]
| data
|rowspan="2"| X
|-
| 02h
| X [1]
| X [0]
|colspan="5"| -
| NDX (new data X)
| data
|-
| 01h
|colspan="4"| al version
|colspan="4"| ml version
| data
|rowspan="2"|
|-
| 00h
|colspan="5"| -
|colspan="3"| chip ID
| data
|}

==Register==
===Shadow disable===
Ist diese Bit gesetzt ist es möglich die MSBs der Beschleunigungswerte (03h, 05h, 07h) zu lesen ohne vorher die LSBs (02h, 04h, 06h) gelesen zu haben.
===Range===
Es sind 3 verschiedene Bereiche einstellbar:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Range'''
|-
!colspan="2"| 14h
!
|-
! Bit 4
! Bit 3
! Bereich
|-
| 0
| 0
| +/- 2g (default)
|-
| 0
| 1
| +/- 4g
|-
| 1
| 0
| +/- 8g
|-
| 1
| 1
| -
|}
===Bandwith===
Folgende Aktualisierungsraten sind möglich:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Bandwith'''
|-
!colspan="3"| 14h
!colspan="2"|
|-
! Bit 2
! Bit 1
! Bit 0
! Rate
! reale Rate
|-
| 0
| 0
| 0
| 25 Hz (default)
| 23 Hz
|-
| 0
| 0
| 1
| 50 Hz
| 47 Hz
|-
| 0
| 1
| 0
| 100 Hz
| 94 Hz
|-
| 0
| 1
| 1
| 190 Hz
| 188 Hz
|-
| 1
| 0
| 0
| 375 Hz
| 375 Hz
|-
| 1
| 0
| 1
| 750 Hz
| 750 Hz
|-
| 1
| 1
| 0
| 1500 Hz
| 1500 Hz
|-
| 1
| 1
| 1
| -
| -
|}

==Konfiguration==

==I2C==
===Adresse===
{| class="wikitable"
|+ '''I2C Adresse'''
|-
! Bit 7 || Bit 6 || Bit 5 || Bit 4 || Bit 3 || Bit 2 || Bit 1 || R/W
|-
| 0 || 1 || 1 || 1 || 0 || 0 || 0 || x
|}
====7 Bit Sichtweise====
Gemeint ist hierbei Bit 7 - 1.
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Hexadezimal || Dezimal
|-
| 0x38 || 56
|}
Zum lesen muss das 0. Bit gesetzt werden.

====8 Bit Sichtweise====
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Richtung || Hexadezimal || Dezimal
|-
| schreiben || 0x70 || 112
|-
| lesen || 0x71 || 113
|}

===Beschleunigungsdaten lesen===

Um Daten zu lesen muss erst der Offset gesendet werden ab dem Daten gelesen werden sollen. Die Beschleunigungsdaten liegen ab Adresse 0x02h.

{| class="wikitable"
|+ '''Offset senden'''
|-
! Richtung || Adresse || Daten
|-
| schreiben || 0x70 || 0x02
|}

Die Beschleunigungsdaten sind pro Achse (X, Y, Z) 10 Bit lang. Diese liegen in 6 Bytes ab Adresse 0x02h (0x02h - 0x08h). Siehe dazu den Abschnitt [[#Speicheraufteilung|Speicheraufteilung]].
Um an die Daten zu kommen muessen 6 Byte von der Adresse des BMA020 gelesen werden:
{| class="wikitable"
|+ ''' Beschleunigungsdaten lesen'''
|-
! Richtung || Adresse || Byte 1 || Byte 2 || Byte 3 || Byte 4 || Byte 5 || Byte 6
|-
| lesen || 0x71 || LSB_x || MSB_x || LSB_y || MSB_y || LSB_z || MSB_z
|}
==Berechnung==
===8 Bitwerte===
Sind die Beschleunigungswerte ausgelesen geht es nun an die Interpretation. Reicht eine Genauigkeit von 8 Bit so kann man nur den MSB-Teil der Werte nehmen.
Achtung: Es müssen dennoch die LSBs eingelesen werden, da die MSBs und LSBs solange blockiert bleiben bis beide eingelesen wurden.
Um dies zu verhindern muss das [[#Shadow disable|Shadow disable Bit]] gesetzt werden (15h, Bit 3; siehe [[#Speicheraufteilung|Speicheraufteilung]]).

===10 Bitwerte===
Hat man die Werte ausgelesen gilt es diese zusammen zu fügen. Im folgenden Beispiel wird angenommen das die Werte in der variable <c>values[]</c> liegen. Die Variable enthält die 6 Bytes für X, Y und Z.

Als Beispiel wird hier X erzeugt (zusammengefügt).
<c>
uint values[6];
int x;

//X MSB (02h) um zwei nach links schieben um Platz für die beiden unteren Bits zu schaffen.
x = values[0] << 2;

//X LSB (03h) um sechs nach rechts schieben um die zwei obersten Bits an den richtigen Platz das zusammenfügen zu bringen.
x = x | (values[1] >> 6);
</c>

Selbiges muss für Y und Z getan werden.

===Gravitationsvektor===
Der Gravitationsvektor ergibt sich aus:
<math>\vec g = \begin{pmatrix} x \\ y \\ z \end{pmatrix}</math>
====Gravitation berechnen====
Die Gravitation ist gleich der Länge des Gravitationsvektors:
<math>g = \sqrt{x^2+y^2+z^2}</math>

[[Kategorie:Sensorik]]

BMA020

2012-01-08T13:59:47Z

Muebau: Eine korrekte Zusammenfassung erstellt.

Der BMA020 ist ein 3-Achsen-Beschleunigungssensor von Bosch der über I2C oder ISP ausgelesen und konfiguriert werden kann.

=BMA020=
==Bauteilseite==
[http://www.mikrocontroller.net/part/BMA020 Zur Bauteilseite des BMA020]

==Bezugsquellen==
===ELV===
http://www.elv.de/3-Achsen-Beschleunigungssensor-3D-BS,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_28515

==Speicheraufteilung==
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Speicher'''
|-
! Adresse
! Bit 7
! Bit 6
! Bit 5
! Bit 4
! Bit 3
! Bit 2
! Bit 1
! Bit 0
! Typ
! Axis
|-
| 16h - 7Fh
|colspan="8"| -
| reserved
|rowspan="15"|
|-
| 15h
| SPI4E (4 wire SPI enable) (default: 1)
| EAI (enable advanced interrupt)
| NDI (new data interrupt)
| LI (latch interrupt)
|[[#Shadow disable|SD (shadow disable / read MSB only)]]
|colspan="2"| WUP (wake up pause)
| WU (wake up)
| control
|-
| 14h
|colspan="3"| - !!! - (NEVER ever change this registers)
|colspan="2"|[[#Range|range (+/-2/4/8g)]]
|colspan="3"|[[#Bandwith|bandwith (25...1500 Hz)]]
| control
|-
| 13h
|colspan="8" rowspan="2"| customer reserved (can be used as memory)
| status
|-
| 12h
| status
|-
| 11h
|colspan="2"| AMD (any motion duration)
|colspan="3"| HGH (high gravitation hysteresis)
|colspan="3"| LGH (low gravitation hysteresis)
| settings
|-
| 10h
|colspan="8"| AMT (any motion threshold)
| settings
|-
| 0Fh
|colspan="8"| HGD (high gravitation duration)
| settings
|-
| 0Eh
|colspan="8"| HGT (high gravitation threshold)
| settings
|-
| 0Dh
|colspan="8"| LGD (low gravitation duration)
| settings
|-
| 0Ch
|colspan="8"| LGT (high gravitation threshold)
| settings
|-
| 0Bh
| alert
| AM (any motion)
|colspan="2"| HGC (high gravitation counter)
|colspan="2"| LGC (low gravitation counter)
| HGE (high gravitation enable)
| LGE (low gravitation enable)
| control
|-
| 0Ah
| -
| reset INT
| -
| -
| self test 1
| self test 2
| soft reset
| sleep
| control
|-
| 09h
| STR (self test result)
|colspan="2"| -
| alert phase
| LG latched
| HG latched
| HGS (high gravitation status)
| LGS (low gravitation status)
| status
|-
| 08h
|colspan="8"| -
| data
|-
| 07h
| Z [9]
| Z [8]
| Z [7]
| Z [6]
| Z [5]
| Z [4]
| Z [3]
| Z [2]
| data
|rowspan="2"| Z
|-
| 06h
| Z [1]
| Z [0]
|colspan="5"| -
| NDZ (new data Z)
| data
|-
| 05h
| Y [9]
| Y [8]
| Y [7]
| Y [6]
| Y [5]
| Y [4]
| Y [3]
| Y [2]
| data
|rowspan="2"| Y
|-
| 04h
| Y [1]
| Y [0]
|colspan="5"| -
| NDY (new data Y)
| data
|-
| 03h
| X [9]
| X [8]
| X [7]
| X [6]
| X [5]
| X [4]
| X [3]
| X [2]
| data
|rowspan="2"| X
|-
| 02h
| X [1]
| X [0]
|colspan="5"| -
| NDX (new data X)
| data
|-
| 01h
|colspan="4"| al version
|colspan="4"| ml version
| data
|rowspan="2"|
|-
| 00h
|colspan="5"| -
|colspan="3"| chip ID
| data
|}

==Register==
===Shadow disable===
Ist diese Bit gesetzt ist es möglich die MSBs der Beschleunigungswerte (03h, 05h, 07h) zu lesen ohne vorher die LSBs (02h, 04h, 06h) gelesen zu haben.
===Range===
Es sind 3 verschiedene Bereiche einstellbar:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Range'''
|-
!colspan="2"| 14h
!
|-
! Bit 4
! Bit 3
! Bereich
|-
| 0
| 0
| +/- 2g (default)
|-
| 0
| 1
| +/- 4g
|-
| 1
| 0
| +/- 8g
|-
| 1
| 1
| -
|}
===Bandwith===
Folgende Aktualisierungsraten sind möglich:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Bandwith'''
|-
!colspan="3"| 14h
!colspan="2"|
|-
! Bit 2
! Bit 1
! Bit 0
! Rate
! reale Rate
|-
| 0
| 0
| 0
| 25 Hz (default)
| 23 Hz
|-
| 0
| 0
| 1
| 50 Hz
| 47 Hz
|-
| 0
| 1
| 0
| 100 Hz
| 94 Hz
|-
| 0
| 1
| 1
| 190 Hz
| 188 Hz
|-
| 1
| 0
| 0
| 375 Hz
| 375 Hz
|-
| 1
| 0
| 1
| 750 Hz
| 750 Hz
|-
| 1
| 1
| 0
| 1500 Hz
| 1500 Hz
|-
| 1
| 1
| 1
| -
| -
|}

==Konfiguration==

==I2C==
===Adresse===
{| class="wikitable"
|+ '''I2C Adresse'''
|-
! Bit 7 || Bit 6 || Bit 5 || Bit 4 || Bit 3 || Bit 2 || Bit 1 || R/W
|-
| 0 || 1 || 1 || 1 || 0 || 0 || 0 || x
|}
====7 Bit Sichtweise====
Gemeint ist hierbei Bit 7 - 1.
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Hexadezimal || Dezimal
|-
| 0x38 || 56
|}
Zum lesen muss das 0. Bit gesetzt werden.

====8 Bit Sichtweise====
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Richtung || Hexadezimal || Dezimal
|-
| schreiben || 0x70 || 112
|-
| lesen || 0x71 || 113
|}

===Beschleunigungsdaten lesen===

Um Daten zu lesen muss erst der Offset gesendet werden ab dem Daten gelesen werden sollen. Die Beschleunigungsdaten liegen ab Adresse 0x02h.

{| class="wikitable"
|+ '''Offset senden'''
|-
! Richtung || Adresse || Daten
|-
| schreiben || 0x70 || 0x02
|}

Die Beschleunigungsdaten sind pro Achse (X, Y, Z) 10 Bit lang. Diese liegen in 6 Bytes ab Adresse 0x02h (0x02h - 0x08h). Siehe dazu den Abschnitt [[#Speicheraufteilung|Speicheraufteilung]].
Um an die Daten zu kommen muessen 6 Byte von der Adresse des BMA020 gelesen werden:
{| class="wikitable"
|+ ''' Beschleunigungsdaten lesen'''
|-
! Richtung || Adresse || Byte 1 || Byte 2 || Byte 3 || Byte 4 || Byte 5 || Byte 6
|-
| lesen || 0x71 || LSB_x || MSB_x || LSB_y || MSB_y || LSB_z || MSB_z
|}
==Berechnung==
===8 Bitwerte===
Sind die Beschleunigungswerte ausgelesen geht es nun an die Interpretation. Reicht eine Genauigkeit von 8 Bit so kann man nur den MSB-Teil der Werte nehmen.
Achtung: Es müssen dennoch die LSBs eingelesen werden, da die MSBs und LSBs solange blockiert bleiben bis beide eingelesen wurden.
Um dies zu verhindern muss das [[#Shadow disable|Shadow disable Bit]] gesetzt werden (15h, Bit 3; siehe [[#Speicheraufteilung|Speicheraufteilung]]).

===10 Bitwerte===
Hat man die Werte ausgelesen gilt es diese zusammen zu fügen. Im folgenden Beispiel wird angenommen das die Werte in der variable <c>values[]</c> liegen. Die Variable enthält die 6 Bytes für X, Y und Z.

Als Beispiel wird hier X erzeugt (zusammengefügt).
<c>
uint values[6];
int x;

//X MSB (02h) um zwei nach links schieben um Platz für die beiden unteren Bits zu schaffen.
x = values[0] << 2;

//X LSB (03h) um sechs nach rechts schieben um die zwei obersten Bits an den richtigen Platz das zusammenfügen zu bringen.
x = x | (values[1] >> 6);
</c>

Selbiges muss für Y und Z getan werden.

===Gravitationsvektor===
Der Gravitationsvektor ergibt sich aus:
<math>\vec g = \begin{pmatrix} x \\ y \\ z \end{pmatrix}</math>
====Gravitation berechnen====
Die Gravitation ist gleich der Länge des Gravitationsvektors:
<math>g = \sqrt{x^2+y^2+z^2}</math>

[[Kategorie:Sensorik]]

BMA020

2012-01-02T16:01:50Z

Muebau: /* 8 Bitwerte */

=BMA020=
==Bauteilseite==
[http://www.mikrocontroller.net/part/BMA020 Zur Bauteilseite des BMA020]

==Bezugsquellen==
===ELV===
http://www.elv.de/3-Achsen-Beschleunigungssensor-3D-BS,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_28515

==Speicheraufteilung==
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Speicher'''
|-
! Adresse
! Bit 7
! Bit 6
! Bit 5
! Bit 4
! Bit 3
! Bit 2
! Bit 1
! Bit 0
! Typ
! Axis
|-
| 16h - 7Fh
|colspan="8"| -
| reserved
|rowspan="15"|
|-
| 15h
| SPI4E (4 wire SPI enable) (default: 1)
| EAI (enable advanced interrupt)
| NDI (new data interrupt)
| LI (latch interrupt)
|[[#Shadow disable|SD (shadow disable / read MSB only)]]
|colspan="2"| WUP (wake up pause)
| WU (wake up)
| control
|-
| 14h
|colspan="3"| - !!! - (NEVER ever change this registers)
|colspan="2"|[[#Range|range (+/-2/4/8g)]]
|colspan="3"|[[#Bandwith|bandwith (25...1500 Hz)]]
| control
|-
| 13h
|colspan="8" rowspan="2"| customer reserved (can be used as memory)
| status
|-
| 12h
| status
|-
| 11h
|colspan="2"| AMD (any motion duration)
|colspan="3"| HGH (high gravitation hysteresis)
|colspan="3"| LGH (low gravitation hysteresis)
| settings
|-
| 10h
|colspan="8"| AMT (any motion threshold)
| settings
|-
| 0Fh
|colspan="8"| HGD (high gravitation duration)
| settings
|-
| 0Eh
|colspan="8"| HGT (high gravitation threshold)
| settings
|-
| 0Dh
|colspan="8"| LGD (low gravitation duration)
| settings
|-
| 0Ch
|colspan="8"| LGT (high gravitation threshold)
| settings
|-
| 0Bh
| alert
| AM (any motion)
|colspan="2"| HGC (high gravitation counter)
|colspan="2"| LGC (low gravitation counter)
| HGE (high gravitation enable)
| LGE (low gravitation enable)
| control
|-
| 0Ah
| -
| reset INT
| -
| -
| self test 1
| self test 2
| soft reset
| sleep
| control
|-
| 09h
| STR (self test result)
|colspan="2"| -
| alert phase
| LG latched
| HG latched
| HGS (high gravitation status)
| LGS (low gravitation status)
| status
|-
| 08h
|colspan="8"| -
| data
|-
| 07h
| Z [9]
| Z [8]
| Z [7]
| Z [6]
| Z [5]
| Z [4]
| Z [3]
| Z [2]
| data
|rowspan="2"| Z
|-
| 06h
| Z [1]
| Z [0]
|colspan="5"| -
| NDZ (new data Z)
| data
|-
| 05h
| Y [9]
| Y [8]
| Y [7]
| Y [6]
| Y [5]
| Y [4]
| Y [3]
| Y [2]
| data
|rowspan="2"| Y
|-
| 04h
| Y [1]
| Y [0]
|colspan="5"| -
| NDY (new data Y)
| data
|-
| 03h
| X [9]
| X [8]
| X [7]
| X [6]
| X [5]
| X [4]
| X [3]
| X [2]
| data
|rowspan="2"| X
|-
| 02h
| X [1]
| X [0]
|colspan="5"| -
| NDX (new data X)
| data
|-
| 01h
|colspan="4"| al version
|colspan="4"| ml version
| data
|rowspan="2"|
|-
| 00h
|colspan="5"| -
|colspan="3"| chip ID
| data
|}

==Register==
===Shadow disable===
Ist diese Bit gesetzt ist es möglich die MSBs der Beschleunigungswerte (03h, 05h, 07h) zu lesen ohne vorher die LSBs (02h, 04h, 06h) gelesen zu haben.
===Range===
Es sind 3 verschiedene Bereiche einstellbar:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Range'''
|-
!colspan="2"| 14h
!
|-
! Bit 4
! Bit 3
! Bereich
|-
| 0
| 0
| +/- 2g (default)
|-
| 0
| 1
| +/- 4g
|-
| 1
| 0
| +/- 8g
|-
| 1
| 1
| -
|}
===Bandwith===
Folgende Aktualisierungsraten sind möglich:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Bandwith'''
|-
!colspan="4"| 14h
!
|-
! Bit 2
! Bit 1
! Bit 0
! Rate
! reale Rate
|-
| 0
| 0
| 0
| 25 Hz (default)
| 23 Hz
|-
| 0
| 0
| 1
| 50 Hz
| 47 Hz
|-
| 0
| 1
| 0
| 100 Hz
| 94 Hz
|-
| 0
| 1
| 1
| 190 Hz
| 188 Hz
|-
| 1
| 0
| 0
| 375 Hz
| 375 Hz
|-
| 1
| 0
| 1
| 750 Hz
| 750 Hz
|-
| 1
| 1
| 0
| 1500 Hz
| 1500 Hz
|-
| 1
| 1
| 1
| -
| -
|}

==Konfiguration==

==I2C==
===Adresse===
{| class="wikitable"
|+ '''I2C Adresse'''
|-
! Bit 7 || Bit 6 || Bit 5 || Bit 4 || Bit 3 || Bit 2 || Bit 1 || R/W
|-
| 0 || 1 || 1 || 1 || 0 || 0 || 0 || x
|}
====7 Bit Sichtweise====
Gemeint ist hierbei Bit 7 - 1.
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Hexadezimal || Dezimal
|-
| 0x38 || 56
|}
Zum lesen muss das 0. Bit gesetzt werden.

====8 Bit Sichtweise====
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Richtung || Hexadezimal || Dezimal
|-
| schreiben || 0x70 || 112
|-
| lesen || 0x71 || 113
|}

===Beschleunigungsdaten lesen===

Um Daten zu lesen muss erst der Offset gesendet werden ab dem Daten gelesen werden sollen. Die Beschleunigungsdaten liegen ab Adresse 0x02h.

{| class="wikitable"
|+ '''Offset senden'''
|-
! Richtung || Adresse || Daten
|-
| schreiben || 0x70 || 0x02
|}

Die Beschleunigungsdaten sind pro Achse (X, Y, Z) 10 Bit lang. Diese liegen in 6 Bytes ab Adresse 0x02h (0x02h - 0x08h). Siehe dazu den Abschnitt [[#Speicheraufteilung|Speicheraufteilung]].
Um an die Daten zu kommen muessen 6 Byte von der Adresse des BMA020 gelesen werden:
{| class="wikitable"
|+ ''' Beschleunigungsdaten lesen'''
|-
! Richtung || Adresse || Byte 1 || Byte 2 || Byte 3 || Byte 4 || Byte 5 || Byte 6
|-
| lesen || 0x71 || LSB_x || MSB_x || LSB_y || MSB_y || LSB_z || MSB_z
|}
==Berechnung==
===8 Bitwerte===
Sind die Beschleunigungswerte ausgelesen geht es nun an die Interpretation. Reicht eine Genauigkeit von 8 Bit so kann man nur den MSB-Teil der Werte nehmen.
Achtung: Es müssen dennoch die LSBs eingelesen werden, da die MSBs und LSBs solange blockiert bleiben bis beide eingelesen wurden.
Um dies zu verhindern muss das [[#Shadow disable|Shadow disable Bit]] gesetzt werden (15h, Bit 3; siehe [[#Speicheraufteilung|Speicheraufteilung]]).

===10 Bitwerte===
Hat man die Werte ausgelesen gilt es diese zusammen zu fügen. Im folgenden Beispiel wird angenommen das die Werte in der variable <c>values[]</c> liegen. Die Variable enthält die 6 Bytes für X, Y und Z.
<c>
uint values[6];
int x;

//X MSB (02h) um zwei nach links schieben um Platz für die beiden unteren Bits zu schaffen.
x = values[0] << 2;

//X LSB (03h) um sechs nach rechts schieben um die zwei obersten Bits an den richtigen Platz das zusammenfügen zu bringen.
x = x | (values[1] >> 6);
</c>

Selbiges muss für Y und Z getan werden.

===Gravitationsvektor===
Der Gravitationsvektor ergibt sich aus:
<math>\vec g = \begin{pmatrix} x \\ y \\ z \end{pmatrix}</math>
====Gravitation berechnen====
Die Gravitation ist gleich der Länge des Gravitationsvektors:
<math>g = \sqrt{x^2+y^2+z^2}</math>

BMA020

2012-01-02T16:00:58Z

Muebau: /* Berechnung */

=BMA020=
==Bauteilseite==
[http://www.mikrocontroller.net/part/BMA020 Zur Bauteilseite des BMA020]

==Bezugsquellen==
===ELV===
http://www.elv.de/3-Achsen-Beschleunigungssensor-3D-BS,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_28515

==Speicheraufteilung==
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Speicher'''
|-
! Adresse
! Bit 7
! Bit 6
! Bit 5
! Bit 4
! Bit 3
! Bit 2
! Bit 1
! Bit 0
! Typ
! Axis
|-
| 16h - 7Fh
|colspan="8"| -
| reserved
|rowspan="15"|
|-
| 15h
| SPI4E (4 wire SPI enable) (default: 1)
| EAI (enable advanced interrupt)
| NDI (new data interrupt)
| LI (latch interrupt)
|[[#Shadow disable|SD (shadow disable / read MSB only)]]
|colspan="2"| WUP (wake up pause)
| WU (wake up)
| control
|-
| 14h
|colspan="3"| - !!! - (NEVER ever change this registers)
|colspan="2"|[[#Range|range (+/-2/4/8g)]]
|colspan="3"|[[#Bandwith|bandwith (25...1500 Hz)]]
| control
|-
| 13h
|colspan="8" rowspan="2"| customer reserved (can be used as memory)
| status
|-
| 12h
| status
|-
| 11h
|colspan="2"| AMD (any motion duration)
|colspan="3"| HGH (high gravitation hysteresis)
|colspan="3"| LGH (low gravitation hysteresis)
| settings
|-
| 10h
|colspan="8"| AMT (any motion threshold)
| settings
|-
| 0Fh
|colspan="8"| HGD (high gravitation duration)
| settings
|-
| 0Eh
|colspan="8"| HGT (high gravitation threshold)
| settings
|-
| 0Dh
|colspan="8"| LGD (low gravitation duration)
| settings
|-
| 0Ch
|colspan="8"| LGT (high gravitation threshold)
| settings
|-
| 0Bh
| alert
| AM (any motion)
|colspan="2"| HGC (high gravitation counter)
|colspan="2"| LGC (low gravitation counter)
| HGE (high gravitation enable)
| LGE (low gravitation enable)
| control
|-
| 0Ah
| -
| reset INT
| -
| -
| self test 1
| self test 2
| soft reset
| sleep
| control
|-
| 09h
| STR (self test result)
|colspan="2"| -
| alert phase
| LG latched
| HG latched
| HGS (high gravitation status)
| LGS (low gravitation status)
| status
|-
| 08h
|colspan="8"| -
| data
|-
| 07h
| Z [9]
| Z [8]
| Z [7]
| Z [6]
| Z [5]
| Z [4]
| Z [3]
| Z [2]
| data
|rowspan="2"| Z
|-
| 06h
| Z [1]
| Z [0]
|colspan="5"| -
| NDZ (new data Z)
| data
|-
| 05h
| Y [9]
| Y [8]
| Y [7]
| Y [6]
| Y [5]
| Y [4]
| Y [3]
| Y [2]
| data
|rowspan="2"| Y
|-
| 04h
| Y [1]
| Y [0]
|colspan="5"| -
| NDY (new data Y)
| data
|-
| 03h
| X [9]
| X [8]
| X [7]
| X [6]
| X [5]
| X [4]
| X [3]
| X [2]
| data
|rowspan="2"| X
|-
| 02h
| X [1]
| X [0]
|colspan="5"| -
| NDX (new data X)
| data
|-
| 01h
|colspan="4"| al version
|colspan="4"| ml version
| data
|rowspan="2"|
|-
| 00h
|colspan="5"| -
|colspan="3"| chip ID
| data
|}

==Register==
===Shadow disable===
Ist diese Bit gesetzt ist es möglich die MSBs der Beschleunigungswerte (03h, 05h, 07h) zu lesen ohne vorher die LSBs (02h, 04h, 06h) gelesen zu haben.
===Range===
Es sind 3 verschiedene Bereiche einstellbar:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Range'''
|-
!colspan="2"| 14h
!
|-
! Bit 4
! Bit 3
! Bereich
|-
| 0
| 0
| +/- 2g (default)
|-
| 0
| 1
| +/- 4g
|-
| 1
| 0
| +/- 8g
|-
| 1
| 1
| -
|}
===Bandwith===
Folgende Aktualisierungsraten sind möglich:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Bandwith'''
|-
!colspan="4"| 14h
!
|-
! Bit 2
! Bit 1
! Bit 0
! Rate
! reale Rate
|-
| 0
| 0
| 0
| 25 Hz (default)
| 23 Hz
|-
| 0
| 0
| 1
| 50 Hz
| 47 Hz
|-
| 0
| 1
| 0
| 100 Hz
| 94 Hz
|-
| 0
| 1
| 1
| 190 Hz
| 188 Hz
|-
| 1
| 0
| 0
| 375 Hz
| 375 Hz
|-
| 1
| 0
| 1
| 750 Hz
| 750 Hz
|-
| 1
| 1
| 0
| 1500 Hz
| 1500 Hz
|-
| 1
| 1
| 1
| -
| -
|}

==Konfiguration==

==I2C==
===Adresse===
{| class="wikitable"
|+ '''I2C Adresse'''
|-
! Bit 7 || Bit 6 || Bit 5 || Bit 4 || Bit 3 || Bit 2 || Bit 1 || R/W
|-
| 0 || 1 || 1 || 1 || 0 || 0 || 0 || x
|}
====7 Bit Sichtweise====
Gemeint ist hierbei Bit 7 - 1.
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Hexadezimal || Dezimal
|-
| 0x38 || 56
|}
Zum lesen muss das 0. Bit gesetzt werden.

====8 Bit Sichtweise====
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Richtung || Hexadezimal || Dezimal
|-
| schreiben || 0x70 || 112
|-
| lesen || 0x71 || 113
|}

===Beschleunigungsdaten lesen===

Um Daten zu lesen muss erst der Offset gesendet werden ab dem Daten gelesen werden sollen. Die Beschleunigungsdaten liegen ab Adresse 0x02h.

{| class="wikitable"
|+ '''Offset senden'''
|-
! Richtung || Adresse || Daten
|-
| schreiben || 0x70 || 0x02
|}

Die Beschleunigungsdaten sind pro Achse (X, Y, Z) 10 Bit lang. Diese liegen in 6 Bytes ab Adresse 0x02h (0x02h - 0x08h). Siehe dazu den Abschnitt [[#Speicheraufteilung|Speicheraufteilung]].
Um an die Daten zu kommen muessen 6 Byte von der Adresse des BMA020 gelesen werden:
{| class="wikitable"
|+ ''' Beschleunigungsdaten lesen'''
|-
! Richtung || Adresse || Byte 1 || Byte 2 || Byte 3 || Byte 4 || Byte 5 || Byte 6
|-
| lesen || 0x71 || LSB_x || MSB_x || LSB_y || MSB_y || LSB_z || MSB_z
|}
==Berechnung==
===8 Bitwerte===
Sind die Beschleunigungswerte ausgelesen geht es nun an die Interpretation. Reicht eine Genauigkeit von 8 Bit so kann man nur den MSB-Teil der Werte nehmen.
Achtung: Es müssen dennoch die LSBs eingelesen werden, da die MSBs und LSBs solange blockiert bleiben bis beide eingelesen wurden.
Um dies zu verhindern muss das [[#Shadow disable|Shadow disable Bit]] gesetzt werden (15h, Bit 3; siehe [[#Speicherbelegung|Speicherbelegung]]).
===10 Bitwerte===
Hat man die Werte ausgelesen gilt es diese zusammen zu fügen. Im folgenden Beispiel wird angenommen das die Werte in der variable <c>values[]</c> liegen. Die Variable enthält die 6 Bytes für X, Y und Z.
<c>
uint values[6];
int x;

//X MSB (02h) um zwei nach links schieben um Platz für die beiden unteren Bits zu schaffen.
x = values[0] << 2;

//X LSB (03h) um sechs nach rechts schieben um die zwei obersten Bits an den richtigen Platz das zusammenfügen zu bringen.
x = x | (values[1] >> 6);
</c>

Selbiges muss für Y und Z getan werden.

===Gravitationsvektor===
Der Gravitationsvektor ergibt sich aus:
<math>\vec g = \begin{pmatrix} x \\ y \\ z \end{pmatrix}</math>
====Gravitation berechnen====
Die Gravitation ist gleich der Länge des Gravitationsvektors:
<math>g = \sqrt{x^2+y^2+z^2}</math>

BMA020

2012-01-02T15:57:31Z

Muebau: /* Beschleunigungsdaten lesen */

=BMA020=
==Bauteilseite==
[http://www.mikrocontroller.net/part/BMA020 Zur Bauteilseite des BMA020]

==Bezugsquellen==
===ELV===
http://www.elv.de/3-Achsen-Beschleunigungssensor-3D-BS,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_28515

==Speicheraufteilung==
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Speicher'''
|-
! Adresse
! Bit 7
! Bit 6
! Bit 5
! Bit 4
! Bit 3
! Bit 2
! Bit 1
! Bit 0
! Typ
! Axis
|-
| 16h - 7Fh
|colspan="8"| -
| reserved
|rowspan="15"|
|-
| 15h
| SPI4E (4 wire SPI enable) (default: 1)
| EAI (enable advanced interrupt)
| NDI (new data interrupt)
| LI (latch interrupt)
|[[#Shadow disable|SD (shadow disable / read MSB only)]]
|colspan="2"| WUP (wake up pause)
| WU (wake up)
| control
|-
| 14h
|colspan="3"| - !!! - (NEVER ever change this registers)
|colspan="2"|[[#Range|range (+/-2/4/8g)]]
|colspan="3"|[[#Bandwith|bandwith (25...1500 Hz)]]
| control
|-
| 13h
|colspan="8" rowspan="2"| customer reserved (can be used as memory)
| status
|-
| 12h
| status
|-
| 11h
|colspan="2"| AMD (any motion duration)
|colspan="3"| HGH (high gravitation hysteresis)
|colspan="3"| LGH (low gravitation hysteresis)
| settings
|-
| 10h
|colspan="8"| AMT (any motion threshold)
| settings
|-
| 0Fh
|colspan="8"| HGD (high gravitation duration)
| settings
|-
| 0Eh
|colspan="8"| HGT (high gravitation threshold)
| settings
|-
| 0Dh
|colspan="8"| LGD (low gravitation duration)
| settings
|-
| 0Ch
|colspan="8"| LGT (high gravitation threshold)
| settings
|-
| 0Bh
| alert
| AM (any motion)
|colspan="2"| HGC (high gravitation counter)
|colspan="2"| LGC (low gravitation counter)
| HGE (high gravitation enable)
| LGE (low gravitation enable)
| control
|-
| 0Ah
| -
| reset INT
| -
| -
| self test 1
| self test 2
| soft reset
| sleep
| control
|-
| 09h
| STR (self test result)
|colspan="2"| -
| alert phase
| LG latched
| HG latched
| HGS (high gravitation status)
| LGS (low gravitation status)
| status
|-
| 08h
|colspan="8"| -
| data
|-
| 07h
| Z [9]
| Z [8]
| Z [7]
| Z [6]
| Z [5]
| Z [4]
| Z [3]
| Z [2]
| data
|rowspan="2"| Z
|-
| 06h
| Z [1]
| Z [0]
|colspan="5"| -
| NDZ (new data Z)
| data
|-
| 05h
| Y [9]
| Y [8]
| Y [7]
| Y [6]
| Y [5]
| Y [4]
| Y [3]
| Y [2]
| data
|rowspan="2"| Y
|-
| 04h
| Y [1]
| Y [0]
|colspan="5"| -
| NDY (new data Y)
| data
|-
| 03h
| X [9]
| X [8]
| X [7]
| X [6]
| X [5]
| X [4]
| X [3]
| X [2]
| data
|rowspan="2"| X
|-
| 02h
| X [1]
| X [0]
|colspan="5"| -
| NDX (new data X)
| data
|-
| 01h
|colspan="4"| al version
|colspan="4"| ml version
| data
|rowspan="2"|
|-
| 00h
|colspan="5"| -
|colspan="3"| chip ID
| data
|}

==Register==
===Shadow disable===
Ist diese Bit gesetzt ist es möglich die MSBs der Beschleunigungswerte (03h, 05h, 07h) zu lesen ohne vorher die LSBs (02h, 04h, 06h) gelesen zu haben.
===Range===
Es sind 3 verschiedene Bereiche einstellbar:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Range'''
|-
!colspan="2"| 14h
!
|-
! Bit 4
! Bit 3
! Bereich
|-
| 0
| 0
| +/- 2g (default)
|-
| 0
| 1
| +/- 4g
|-
| 1
| 0
| +/- 8g
|-
| 1
| 1
| -
|}
===Bandwith===
Folgende Aktualisierungsraten sind möglich:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Bandwith'''
|-
!colspan="4"| 14h
!
|-
! Bit 2
! Bit 1
! Bit 0
! Rate
! reale Rate
|-
| 0
| 0
| 0
| 25 Hz (default)
| 23 Hz
|-
| 0
| 0
| 1
| 50 Hz
| 47 Hz
|-
| 0
| 1
| 0
| 100 Hz
| 94 Hz
|-
| 0
| 1
| 1
| 190 Hz
| 188 Hz
|-
| 1
| 0
| 0
| 375 Hz
| 375 Hz
|-
| 1
| 0
| 1
| 750 Hz
| 750 Hz
|-
| 1
| 1
| 0
| 1500 Hz
| 1500 Hz
|-
| 1
| 1
| 1
| -
| -
|}

==Konfiguration==

==I2C==
===Adresse===
{| class="wikitable"
|+ '''I2C Adresse'''
|-
! Bit 7 || Bit 6 || Bit 5 || Bit 4 || Bit 3 || Bit 2 || Bit 1 || R/W
|-
| 0 || 1 || 1 || 1 || 0 || 0 || 0 || x
|}
====7 Bit Sichtweise====
Gemeint ist hierbei Bit 7 - 1.
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Hexadezimal || Dezimal
|-
| 0x38 || 56
|}
Zum lesen muss das 0. Bit gesetzt werden.

====8 Bit Sichtweise====
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Richtung || Hexadezimal || Dezimal
|-
| schreiben || 0x70 || 112
|-
| lesen || 0x71 || 113
|}

===Beschleunigungsdaten lesen===

Um Daten zu lesen muss erst der Offset gesendet werden ab dem Daten gelesen werden sollen. Die Beschleunigungsdaten liegen ab Adresse 0x02h.

{| class="wikitable"
|+ '''Offset senden'''
|-
! Richtung || Adresse || Daten
|-
| schreiben || 0x70 || 0x02
|}

Die Beschleunigungsdaten sind pro Achse (X, Y, Z) 10 Bit lang. Diese liegen in 6 Bytes ab Adresse 0x02h (0x02h - 0x08h). Siehe dazu den Abschnitt [[#Speicheraufteilung|Speicheraufteilung]].
Um an die Daten zu kommen muessen 6 Byte von der Adresse des BMA020 gelesen werden:
{| class="wikitable"
|+ ''' Beschleunigungsdaten lesen'''
|-
! Richtung || Adresse || Byte 1 || Byte 2 || Byte 3 || Byte 4 || Byte 5 || Byte 6
|-
| lesen || 0x71 || LSB_x || MSB_x || LSB_y || MSB_y || LSB_z || MSB_z
|}
==Berechnung==
===8 Bitwerte===
Sind die Beschleunigungswerte ausgelesen geht es nun an die Interpretation. Reicht eine Genauigkeit von 8 Bit so kann man nur den MSB-Teil der Werte nehmen.
Achtung: Es müssen dennoch die LSBs eingelesen werden, da die MSBs und LSBs solange blockiert bleiben bis beide eingelesen wurden.
Um dies zu verhindern muss das [[Shadow disable|Shadow disable Bit]] gesetzt werden (15h, Bit 3; siehe [[Speicherbelegung]]).
===10 Bitwerte===
Hat man die Werte ausgelesen gilt es diese zusammen zu fügen. Im folgenden Beispiel wird angenommen das die Werte in der variable [c]values[][/c] liegen. Die Variable enthält die 6 Bytes für X, Y und Z.
[c]
uint values[6];
int x;

//X MSB (02h) um zwei nach links schieben um Platz für die beiden unteren Bits zu schaffen.
x = values[0] << 2;

//X LSB (03h) um sechs nach rechts schieben um die zwei obersten Bits an den richtigen Platz das zusammenfügen zu bringen.
x = x | (values[1] >> 6);
[/c]

Selbiges muss für Y und Z getan werden.

===Gravitationsvektor===
Der Gravitationsvektor ergibt sich aus:
<math>\vec g = \begin{pmatrix} x \\ y \\ z \end{pmatrix}</math>
====Gravitation berechnen====
Die Gravitation ist gleich der Länge des Gravitationsvektors:
<math>g = \sqrt{x^2+y^2+z^2}</math>

BMA020

2012-01-02T15:16:33Z

Muebau: /* Speicheraufteilung */ add links

BMA020

2012-01-02T15:12:53Z

Muebau: /* Register */ add 'shadow disable' and 'bandwith'

=BMA020=
==Bauteilseite==
[http://www.mikrocontroller.net/part/BMA020 Zur Bauteilseite des BMA020]

==Bezugsquellen==
===ELV===
http://www.elv.de/3-Achsen-Beschleunigungssensor-3D-BS,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_28515

==Speicheraufteilung==
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Speicher'''
|-
! Adresse
! Bit 7
! Bit 6
! Bit 5
! Bit 4
! Bit 3
! Bit 2
! Bit 1
! Bit 0
! Typ
! Axis
|-
| 16h - 7Fh
|colspan="8"| -
| reserved
|rowspan="15"|
|-
| 15h
| SPI4E (4 wire SPI enable) (default: 1)
| EAI (enable advanced interrupt)
| NDI (new data interrupt)
| LI (latch interrupt)
| SD (shadow disable / read MSB only)
|colspan="2"| WUP (wake up pause)
| WU (wake up)
| control
|-
| 14h
|colspan="3"| - !!! - (NEVER ever change this registers)
|colspan="2"|[[#Range|range (+/-2/4/8g)]]
|colspan="3"| bandwith (25...1500 Hz)
| control
|-
| 13h
|colspan="8" rowspan="2"| customer reserved (can be used as memory)
| status
|-
| 12h
| status
|-
| 11h
|colspan="2"| AMD (any motion duration)
|colspan="3"| HGH (high gravitation hysteresis)
|colspan="3"| LGH (low gravitation hysteresis)
| settings
|-
| 10h
|colspan="8"| AMT (any motion threshold)
| settings
|-
| 0Fh
|colspan="8"| HGD (high gravitation duration)
| settings
|-
| 0Eh
|colspan="8"| HGT (high gravitation threshold)
| settings
|-
| 0Dh
|colspan="8"| LGD (low gravitation duration)
| settings
|-
| 0Ch
|colspan="8"| LGT (high gravitation threshold)
| settings
|-
| 0Bh
| alert
| AM (any motion)
|colspan="2"| HGC (high gravitation counter)
|colspan="2"| LGC (low gravitation counter)
| HGE (high gravitation enable)
| LGE (low gravitation enable)
| control
|-
| 0Ah
| -
| reset INT
| -
| -
| self test 1
| self test 2
| soft reset
| sleep
| control
|-
| 09h
| STR (self test result)
|colspan="2"| -
| alert phase
| LG latched
| HG latched
| HGS (high gravitation status)
| LGS (low gravitation status)
| status
|-
| 08h
|colspan="8"| -
| data
|-
| 07h
| Z [9]
| Z [8]
| Z [7]
| Z [6]
| Z [5]
| Z [4]
| Z [3]
| Z [2]
| data
|rowspan="2"| Z
|-
| 06h
| Z [1]
| Z [0]
|colspan="5"| -
| NDZ (new data Z)
| data
|-
| 05h
| Y [9]
| Y [8]
| Y [7]
| Y [6]
| Y [5]
| Y [4]
| Y [3]
| Y [2]
| data
|rowspan="2"| Y
|-
| 04h
| Y [1]
| Y [0]
|colspan="5"| -
| NDY (new data Y)
| data
|-
| 03h
| X [9]
| X [8]
| X [7]
| X [6]
| X [5]
| X [4]
| X [3]
| X [2]
| data
|rowspan="2"| X
|-
| 02h
| X [1]
| X [0]
|colspan="5"| -
| NDX (new data X)
| data
|-
| 01h
|colspan="4"| al version
|colspan="4"| ml version
| data
|rowspan="2"|
|-
| 00h
|colspan="5"| -
|colspan="3"| chip ID
| data
|}

==Register==
===Shadow disable===
Ist diese Bit gesetzt ist es möglich die MSBs der Beschleunigungswerte (03h, 05h, 07h) zu lesen ohne vorher die LSBs (02h, 04h, 06h) gelesen zu haben.
===Range===
Es sind 3 verschiedene Bereiche einstellbar:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Range'''
|-
!colspan="2"| 14h
!
|-
! Bit 4
! Bit 3
! Bereich
|-
| 0
| 0
| +/- 2g (default)
|-
| 0
| 1
| +/- 4g
|-
| 1
| 0
| +/- 8g
|-
| 1
| 1
| -
|}
===Bandwith===
Folgende Aktualisierungsraten sind möglich:
{| class="wikitable" style="text-align:center"
|+ '''BMA020 Bandwith'''
|-
!colspan="4"| 14h
!
|-
! Bit 2
! Bit 1
! Bit 0
! Rate
! reale Rate
|-
| 0
| 0
| 0
| 25 Hz (default)
| 23 Hz
|-
| 0
| 0
| 1
| 50 Hz
| 47 Hz
|-
| 0
| 1
| 0
| 100 Hz
| 94 Hz
|-
| 0
| 1
| 1
| 190 Hz
| 188 Hz
|-
| 1
| 0
| 0
| 375 Hz
| 375 Hz
|-
| 1
| 0
| 1
| 750 Hz
| 750 Hz
|-
| 1
| 1
| 0
| 1500 Hz
| 1500 Hz
|-
| 1
| 1
| 1
| -
| -
|}

==Konfiguration==

==I2C==
===Adresse===
{| class="wikitable"
|+ '''I2C Adresse'''
|-
! Bit 7 || Bit 6 || Bit 5 || Bit 4 || Bit 3 || Bit 2 || Bit 1 || R/W
|-
| 0 || 1 || 1 || 1 || 0 || 0 || 0 || x
|}
====7 Bit Sichtweise====
Gemeint ist hierbei Bit 7 - 1.
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Hexadezimal || Dezimal
|-
| 0x38 || 56
|}
Zum lesen muss das 0. Bit gesetzt werden.

====8 Bit Sichtweise====
{| class="wikitable"
|+ '''I2C Adressen'''
|-
! Richtung || Hexadezimal || Dezimal
|-
| schreiben || 0x70 || 112
|-
| lesen || 0x71 || 113
|}

===Beschleunigungsdaten lesen===

Um Daten zu lesen muss erst der Offset gesendet werden ab dem Daten gelesen werden sollen. Die Beschleunigungsdaten liegen ab Adresse 0x02h.

{| class="wikitable"
|+ '''Offset senden'''
|-
! Richtung || Adresse || Daten
|-
| schreiben || 0x70 || 0x02
|}

Die Beschleunigungsdaten sind pro Achse (X, Y, Z) 10 Bit lang. Diese liegen in 6 Bytes ab Adresse 0x02h (0x02h - 0x08h). Siehe dazu den Abschnitt [[#Speicheraufteilung|Speicheraufteilung]].
Um an die Daten zu kommen muessen 6 Byte von der Adresse des BMA020 gelesen werden:
{| class="wikitable"
|+ ''' Beschleunigungsdaten lesen'''
|-
! Richtung || Adresse || Byte 1 || Byte 2 || Byte 3 || Byte 4 || Byte 5 || Byte 6
|-
| lesen || 0x71 || LSB_x || MSB_x || LSB_y || MSB_y || LSB_z || MSB_z
|}

BMA020

2012-01-02T14:45:45Z

Muebau: /* Speicheraufteilung */ add link

BMA020

2012-01-02T14:43:18Z

Muebau: /* Register */ add range

BMA020

2012-01-02T14:34:11Z

Muebau: /* Speicheraufteilung */

BMA020

2012-01-02T14:21:52Z

Muebau: /* Speicheraufteilung */

BMA020

2012-01-02T14:20:05Z

Muebau: /* Speicheraufteilung */

BMA020

2012-01-02T10:14:08Z

Muebau: /* Speicheraufteilung */

BMA020

2012-01-02T00:25:55Z

Muebau: /* Beschleunigungsdaten lesen */

BMA020

2012-01-02T00:17:18Z

Muebau: Beschleunigungsensor BMA020

I²C

2012-01-01T23:18:14Z

Muebau: /* Bausteine */

'''I²C''' ist ein synchroner serieller Zweidraht-[[Bus]] (eine Daten- und eine Taktleitung), der für die Kommunikation zwischen [[IC]]s über kleine Distanzen geeignet ist. Entwickelt wurde er Anfang der 80er Jahre von Philips.
Gesprochen "I quadrat C" steht für IIC = Inter [[IC]] Bus. Aus Lizenzgründen heißt der I²C Bus bei manchen Herstellern auch '''TWI''', two wire interface.

== I2C ==
In einem I²C-Bus gibt es mindestens einen Master mit bis zu 127 Slaves und einen Broadcast Kanal. Ein I²C-Bus mit mehreren Mastern wird als "Multi-Master-Bus" bezeichnet.
Der (oder die) Master sprechen die Slaves an; ein Slave kann NIE selbstständig Daten senden. Dazu übernimmt der Master, der Daten senden oder empfangen möchte, den Bus und gibt die (7-bit- bzw. 10-bit-)Adresse des Slaves aus, mit dem er kommunizieren möchte. Nach der Adresse teilt der Master dem entsprechenden Slave mit, ob er Daten senden oder empfangen möchte. Danach werden die eigentlichen Daten (entweder vom Master oder Slave) auf den Bus gelegt. Hat der Master den Lese- oder Schreibvorgang abgeschlossen, so gibt er den Bus wieder frei.
Sofern mehrere Master vorhanden sind, stellt ein Protokoll sicher, dass sich diese nicht gegenseitig stören.

=== I2C - Übertragungsraten ===
Die Übertragungsrate beträgt beim standard mode bis zu 100 kbit/s, beim fast mode bis zu 400 kbit/s und beim high-speed mode bis zu 3,4 MBit/s. Falls die Taktrate für einen Slave zu hoch ist, kann er die Clock-Leitung auf Null ziehen und die Übertragung damit verlangsamen (sog. Clock Stretching). Dies ist auf Bit- wie auf Byte-Ebene möglich; ersteres allerdings nicht im high-speed mode.
Um längere Übertragungswege zu realisieren, kann man die Taktrate fast beliebig vermindern (einige Bausteine erzeugen aber irgendwann ein Time-Out). Mit einer Taktfrequenz von nur 5 kbit/s können dann durchaus mehrere Meter überbrückt werden.

Im PC wird ein dem I²C-Bus sehr ähnliches System benutzt, um z. B. die Daten eines [[SDRAM]]-Modules auszulesen. Dieser nennt sich [[SMBus]] (System Management Bus).

Erfahrungen mit den Atmegas (gemessene I2C-Taktfrequenzen):
* 16,000MHz - schafft sauber bis zu 700KHz
* 18,432MHz - schafft sauber bis zu 950KHz

Selbst unter schlechten Bedingungen wie...
* 50cm 6-adriges Spiralkabel, frei schwingend verbaut in einem Rennwagen als Verbindung zwischen Lenkraddisplay und Amaturenbrett
* Nähe zu nicht geschirmten Leitungen mit 12V, GND und 5V PWM zum Dimmen von LEDs
* grausamen Umgebungsbedingungen, Fahrten im Regen, Schnee oder bei glühender Sonne und gefühlten 100° C ;-) auf der Rennstrecke.
hat der Bus ohne Probleme funktioniert.

=== Bausteine ===

Neben Mikrocontrollern gibt es eine Reihe von Peripheriebausteinen, die per I²C angeschlossen werden können. Eine gute Anlaufstelle bei der Suche ist die unten angegebene Seite des "Erfinders" Philips, heute als [http://www.nxp.com NXP] bekannt.

*serielle [[Speicher#EEPROM | EEPROM]]s
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=24C01&action=Search 24Cxx]
** [http://ics.nxp.com/products/pcf/seeproms/ PCF85xx von NXP, 256-2048 Byte]

*I/O-Portexpander
** [[I2C-Schaltmodul|PCF8574]]
** [http://www.mikrocontroller.net/part/MCP23008 MCP23008] (8-bit) von Microchip
** [http://www.mikrocontroller.net/part/MCP23017 MCP23017](16-bit) von Microchip

* I2C MUX, zum Anschluss von ICs mit gleicher, fester Adresse
** [http://www.datasheetcatalog.org/cgi-bin/helo.pl?field=Nume&type=C&text=PCA9545A&producedby=&action=Search PCA9545A]

* [[AD-Wandler]]
** [http://www.mikrocontroller.net/topic/182614 12x12 Bit ADC MAX1238]
** [http://www.mikrocontroller.net/topic/182614 12x10 Bit ADC MAX1138]
** [http://www.maxim-ic.com/datasheet/index.mvp/id/1890 MAX127 und MAX128 von Maxim, 12bit x8, PDIP24+SSOP28]
** [http://www.jtronics.de/platinen.html 12x8 Bit ADC MAX1038]

* [[DA-Wandler]]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=TDA8444&producedby=&action=Search TDA8444, 8x6Bit]

* Uhrenbausteine
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=PCF8583&producedby=&action=Search PCF8583, mit 256 Bytes RAM]
** DS1307

* [[LCD]]-Treiber
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=PCF8577&producedby=&action=Search PCF8577, 2x32 Segmente]

* [[Temperatursensor|Temperatursensoren]]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=DS1621&action=Search DS1621]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=lm75&action=Search LM75]
** [http://www.sensirion.com/en/pdf/product_information/Datasheet-humidity-sensor-SHT21.pdf SHT21]
** TMP101 von TexasInstruments
** TMP175 von TI (mehr als 8 Bausteine im gleichen Bus möglich)

* Drucksensoren
** SMD500
** BMP085

* Beschleunigungssensor
** [http://www.mikrocontroller.net/articles/BMA020 BMA020]

=== Galvanische Trennung ===
* http://www.analog.com/static/imported-files/application_notes/AN_913.pdf
* http://www.analog.com/en/interface/digital-isolators/products/index.html#Isolated_I2C_Isolators
* http://www.mikrocontroller.net/attachment/5670/Galvanische_Trennung_fuer_I2C-Bus.pdf
* http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/i2c-bus/frequently-asked-questions/i2c-faq.html
* http://www.mikrocontroller.net/topic/17425#125464

== Siehe auch ==
* [[AT91-TWI]]
* [[AVR TWI]]
* [[I2C als Hausbus]]
* Beitrag zu [http://www.mikrocontroller.net/topic/181115#1748880 I2C-Adressen] im Forum

== Weblinks ==
* [http://ics.nxp.com/interface/ NXP (ehemals Philips) Produktseite]
* [http://www.nxp.com/acrobat/usermanuals/UM10204_3.pdf I2C Spezifikation 3.0]
* [http://www.i2c-bus.org I²C FAQ, Einführung, Hintergrundinformationen]
* [http://www.robotikhardware.de/download/rn_pc_i2c.pdf robotikhardware.de]

=== Bibliotheken ===
* [http://www.jtronics.de/elektronik-avr/lib-i2ctwi-avr.html AVR TWI Slave]
* [http://www.mikrocontroller.net/topic/235733#2398750 TWI MASTER in ASM]

===I²C-Interface===
* [http://www.mikrocontroller.net/topic/155136#1462320 Beitrag "i2c usb interface"] (Linux)
* [http://sprut.de/electronic/pic/projekte/usb4all/usb4all.htm USB4ALL bei sprut.de] universeller USB-Baustein, auch für I2C

===I²C-Monitor===
*http://realterm.sourceforge.net/#I2C%20Bus
*http://www.avrfreaks.net/index.php?module=FreaksTools&func=viewItem&item_id=411
* [http://www.telos.info/ConniiMM20 Connii MM 2.0 - I²C Monitor with USB Interface]
* [http://www.telos.info/traciixl20 Tracii XL - High-End I²C Monitor]
*http://i2cchip.com/
* [http://www.ullihome.de/index.php/Hauptseite#USB_AVR-Lab I2C Logger Firmware für USB AVR-ISP]
* [http://www.mikrocontroller.net/topic/41535 I2C Monitor mit Mega8 (Firmware)]
* [http://warmcat.com/milksop/cheapi2c.html Cheapi2c] by Numbnut (Andy Green) uses your PC CPU (Linux only!) and printer port to perform realtime snooping of a standard 100kHz I2C bus with 100% capture.
* [http://www.mikrocontroller.net/topic/103600#905495 I2C (TWI) Sniffer]. Basierend auf einem ATtiny85 mit Ausgabe auf RS232 (C und ASM).
* [http://en.radzio.dxp.pl/i2c-sniffer/ I2C/TWI bus sniffer/analyzer] (ATTiny2313 @ 20 MHz und USB über FTDI FT245RL oder UM245R)
* [http://www.i2cchip.com/start_bit_detector1.jpg I2C Startbit-Detector] auf [http://www.i2cchip.com/ www.i2cchip.com]
* [http://www.harbaum.org/till/i2c_tiny_usb/index.shtml i2c-tiny-usb open source/open hardware zum Auslesen mit einem PC]

[[Category:I2C| ]]

I²C

2012-01-01T22:13:42Z

Muebau: /* Bausteine */

'''I²C''' ist ein synchroner serieller Zweidraht-[[Bus]] (eine Daten- und eine Taktleitung), der für die Kommunikation zwischen [[IC]]s über kleine Distanzen geeignet ist. Entwickelt wurde er Anfang der 80er Jahre von Philips.
Gesprochen "I quadrat C" steht für IIC = Inter [[IC]] Bus. Aus Lizenzgründen heißt der I²C Bus bei manchen Herstellern auch '''TWI''', two wire interface.

== I2C ==
In einem I²C-Bus gibt es mindestens einen Master mit bis zu 127 Slaves und einen Broadcast Kanal. Ein I²C-Bus mit mehreren Mastern wird als "Multi-Master-Bus" bezeichnet.
Der (oder die) Master sprechen die Slaves an; ein Slave kann NIE selbstständig Daten senden. Dazu übernimmt der Master, der Daten senden oder empfangen möchte, den Bus und gibt die (7-bit- bzw. 10-bit-)Adresse des Slaves aus, mit dem er kommunizieren möchte. Nach der Adresse teilt der Master dem entsprechenden Slave mit, ob er Daten senden oder empfangen möchte. Danach werden die eigentlichen Daten (entweder vom Master oder Slave) auf den Bus gelegt. Hat der Master den Lese- oder Schreibvorgang abgeschlossen, so gibt er den Bus wieder frei.
Sofern mehrere Master vorhanden sind, stellt ein Protokoll sicher, dass sich diese nicht gegenseitig stören.

=== I2C - Übertragungsraten ===
Die Übertragungsrate beträgt beim standard mode bis zu 100 kbit/s, beim fast mode bis zu 400 kbit/s und beim high-speed mode bis zu 3,4 MBit/s. Falls die Taktrate für einen Slave zu hoch ist, kann er die Clock-Leitung auf Null ziehen und die Übertragung damit verlangsamen (sog. Clock Stretching). Dies ist auf Bit- wie auf Byte-Ebene möglich; ersteres allerdings nicht im high-speed mode.
Um längere Übertragungswege zu realisieren, kann man die Taktrate fast beliebig vermindern (einige Bausteine erzeugen aber irgendwann ein Time-Out). Mit einer Taktfrequenz von nur 5 kbit/s können dann durchaus mehrere Meter überbrückt werden.

Im PC wird ein dem I²C-Bus sehr ähnliches System benutzt, um z. B. die Daten eines [[SDRAM]]-Modules auszulesen. Dieser nennt sich [[SMBus]] (System Management Bus).

Erfahrungen mit den Atmegas (gemessene I2C-Taktfrequenzen):
* 16,000MHz - schafft sauber bis zu 700KHz
* 18,432MHz - schafft sauber bis zu 950KHz

Selbst unter schlechten Bedingungen wie...
* 50cm 6-adriges Spiralkabel, frei schwingend verbaut in einem Rennwagen als Verbindung zwischen Lenkraddisplay und Amaturenbrett
* Nähe zu nicht geschirmten Leitungen mit 12V, GND und 5V PWM zum Dimmen von LEDs
* grausamen Umgebungsbedingungen, Fahrten im Regen, Schnee oder bei glühender Sonne und gefühlten 100° C ;-) auf der Rennstrecke.
hat der Bus ohne Probleme funktioniert.

=== Bausteine ===

Neben Mikrocontrollern gibt es eine Reihe von Peripheriebausteinen, die per I²C angeschlossen werden können. Eine gute Anlaufstelle bei der Suche ist die unten angegebene Seite des "Erfinders" Philips, heute als [http://www.nxp.com NXP] bekannt.

*serielle [[Speicher#EEPROM | EEPROM]]s
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=24C01&action=Search 24Cxx]
** [http://ics.nxp.com/products/pcf/seeproms/ PCF85xx von NXP, 256-2048 Byte]

*I/O-Portexpander
** [[I2C-Schaltmodul|PCF8574]]
** [http://www.mikrocontroller.net/part/MCP23008 MCP23008] (8-bit) von Microchip
** [http://www.mikrocontroller.net/part/MCP23017 MCP23017](16-bit) von Microchip

* I2C MUX, zum Anschluss von ICs mit gleicher, fester Adresse
** [http://www.datasheetcatalog.org/cgi-bin/helo.pl?field=Nume&type=C&text=PCA9545A&producedby=&action=Search PCA9545A]

* [[AD-Wandler]]
** [http://www.mikrocontroller.net/topic/182614 12x12 Bit ADC MAX1238]
** [http://www.mikrocontroller.net/topic/182614 12x10 Bit ADC MAX1138]
** [http://www.maxim-ic.com/datasheet/index.mvp/id/1890 MAX127 und MAX128 von Maxim, 12bit x8, PDIP24+SSOP28]
** [http://www.jtronics.de/platinen.html 12x8 Bit ADC MAX1038]

* [[DA-Wandler]]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=TDA8444&producedby=&action=Search TDA8444, 8x6Bit]

* Uhrenbausteine
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=PCF8583&producedby=&action=Search PCF8583, mit 256 Bytes RAM]
** DS1307

* [[LCD]]-Treiber
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=PCF8577&producedby=&action=Search PCF8577, 2x32 Segmente]

* [[Temperatursensor|Temperatursensoren]]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=DS1621&action=Search DS1621]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=lm75&action=Search LM75]
** [http://www.sensirion.com/en/pdf/product_information/Datasheet-humidity-sensor-SHT21.pdf SHT21]
** TMP101 von TexasInstruments
** TMP175 von TI (mehr als 8 Bausteine im gleichen Bus möglich)

* Drucksensoren
** SMD500
** BMP085

* Beschleunigungssensor
** [http://www.mikrocontroller.net/part/BMA020 BMA020]

=== Galvanische Trennung ===
* http://www.analog.com/static/imported-files/application_notes/AN_913.pdf
* http://www.analog.com/en/interface/digital-isolators/products/index.html#Isolated_I2C_Isolators
* http://www.mikrocontroller.net/attachment/5670/Galvanische_Trennung_fuer_I2C-Bus.pdf
* http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/i2c-bus/frequently-asked-questions/i2c-faq.html
* http://www.mikrocontroller.net/topic/17425#125464

== Siehe auch ==
* [[AT91-TWI]]
* [[AVR TWI]]
* [[I2C als Hausbus]]
* Beitrag zu [http://www.mikrocontroller.net/topic/181115#1748880 I2C-Adressen] im Forum

== Weblinks ==
* [http://ics.nxp.com/interface/ NXP (ehemals Philips) Produktseite]
* [http://www.nxp.com/acrobat/usermanuals/UM10204_3.pdf I2C Spezifikation 3.0]
* [http://www.i2c-bus.org I²C FAQ, Einführung, Hintergrundinformationen]
* [http://www.robotikhardware.de/download/rn_pc_i2c.pdf robotikhardware.de]

=== Bibliotheken ===
* [http://www.jtronics.de/elektronik-avr/lib-i2ctwi-avr.html AVR TWI Slave]
* [http://www.mikrocontroller.net/topic/235733#2398750 TWI MASTER in ASM]

===I²C-Interface===
* [http://www.mikrocontroller.net/topic/155136#1462320 Beitrag "i2c usb interface"] (Linux)
* [http://sprut.de/electronic/pic/projekte/usb4all/usb4all.htm USB4ALL bei sprut.de] universeller USB-Baustein, auch für I2C

===I²C-Monitor===
*http://realterm.sourceforge.net/#I2C%20Bus
*http://www.avrfreaks.net/index.php?module=FreaksTools&func=viewItem&item_id=411
* [http://www.telos.info/ConniiMM20 Connii MM 2.0 - I²C Monitor with USB Interface]
* [http://www.telos.info/traciixl20 Tracii XL - High-End I²C Monitor]
*http://i2cchip.com/
* [http://www.ullihome.de/index.php/Hauptseite#USB_AVR-Lab I2C Logger Firmware für USB AVR-ISP]
* [http://www.mikrocontroller.net/topic/41535 I2C Monitor mit Mega8 (Firmware)]
* [http://warmcat.com/milksop/cheapi2c.html Cheapi2c] by Numbnut (Andy Green) uses your PC CPU (Linux only!) and printer port to perform realtime snooping of a standard 100kHz I2C bus with 100% capture.
* [http://www.mikrocontroller.net/topic/103600#905495 I2C (TWI) Sniffer]. Basierend auf einem ATtiny85 mit Ausgabe auf RS232 (C und ASM).
* [http://en.radzio.dxp.pl/i2c-sniffer/ I2C/TWI bus sniffer/analyzer] (ATTiny2313 @ 20 MHz und USB über FTDI FT245RL oder UM245R)
* [http://www.i2cchip.com/start_bit_detector1.jpg I2C Startbit-Detector] auf [http://www.i2cchip.com/ www.i2cchip.com]
* [http://www.harbaum.org/till/i2c_tiny_usb/index.shtml i2c-tiny-usb open source/open hardware zum Auslesen mit einem PC]

[[Category:I2C| ]]

AVR Eclipse

2010-06-28T09:50:15Z

Muebau: /* Schritt für Schritt */

Dieser Artikel beschreibt erste Erfahrungen mit Eclipse und der AVR-Toolchain.

== Allgemeines zu Eclipse ==
Eclipse ist eine IDE, die sich alleine nicht zur Programmierung von C/C++ eignet. Dafür gibt es dann das Eclipse-Plugin CDT (auch von ECLIPSE.ORG). Die CDT erweitert Eclipse mit der Möglichkeit, C/C++ zu programmieren. Das aber erstmal nur mit dem GCC. Um jetzt die Toolchain AVR-GCC (WINAVR) einzubinden, benötigt man noch ein weiteres Plugin (CDT AVRGCC oder auch CDT AVR Plugin). Es ist auch möglich, ohne die beiden letzt genannten Plugins zu arbeiten, dann sind die Einstellungen für den GCC an AVR-GCC anzupassen (unkomfortabler).

== Allgemeines zu dem AVR Eclipse Plugin ==

Da dieser Artikel nicht immer auf dem neuesten Stand ist, bekommt man weitere Informationen auf der englischen [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR Eclipse Plugin WIKI] Seite

=== Eclipse Plugin Tutorials ===

* Kurzanleitung zur Installation des [http://winavr.scienceprog.com/other-valuable-tools/using-eclipse-as-ide-for-winavr-compiler.html Plugins] (englisch).

== Installation unter Windows ==

=== Was wird benötigt? ===
==== Compiler ====
* [http://winavr.sourceforge.net/ WINAVR] AVR-GCC Compiler Toolchain, siehe auch Artikel [[WinAVR]]

==== IDE ====
Eclipse braucht eine JAVA Runtime Enviroment, falls diese noch nicht installiert ist muss das auch noch heruntergeladen werden
* [http://java.sun.com/javase/downloads/index.jsp JDK 6 Update 10]

Am einfachsten geht es, wenn man die Version mit dem integrierten CDT-Plugin verwendet.
Unter diesem Link die Aktuellste '''Eclipse IDE for C/C++ Developers''' downloaden
* [http://www.eclipse.org/downloads/ Eclipse IDE]

Das zusätzliche AVR Plugin ist notwendig zum Einbinden des AVR-GCC. Kann hier heruntergeladen werden. Oder, besser, in einer installierten Eclipse Umgebung eingebunden werden.
* [http://sourceforge.net/projects/avr-eclipse CDT AVRGCC Plugin]

==== Programmer / Debugger ====
Zum Programmieren und Debuggen kann man eingentlich jedes beliebige Programm verwenden. Zum Debuggen kommt unter anderem AVaRICE zum Einsatz, mit dem man auch programmieren kann (JTAG).
Wahlweise ist auch AVRDUDE zum programmieren zu verwenden. Das kann man machen,
wie man möchte. Beide Programme sind in WINAVR (siehe oben unter Compiler) enthalten.

=== Wie Installieren ===
WinAVR sollte auf dem System installiert sein. Siehe [[AVR_Eclipse#Compiler|oben]].
==== JAVA ====

Java Runtime installieren.

==== IDE ====
Eclipse ist in einem Zip Archiv, das an einen beliebigen Ort entpackt werden kann. Gestartet wird das Programm mit der Datei eclipse.exe. Meldet Eclipse beim Start einen Fehler, ist wahrscheinlich keine oder eine unpassende JAVA Runtime Enviroment installiert.

==== Plugin ====
Es gibt zwei Möglichkeiten, wobei die [[AVR_Eclipse#.C3.9Cber_Updatesite:|erste]] empfohlen wird:

===== Über Updatesite: =====

* Eclipse starten. Zum Software Update Dialog gehen (Help > Install New Software ...)

* In der Zeile Work with ... http://avr-eclipse.sourceforge.net/updatesite eintragen.
*Button Add anklicken. Einen Namen vergeben z.B. AVR-Eclipse.
*Neuste Version von AVR-Eclipse auswählen und installieren.

===== Direkt installieren: =====
Das Plugin ist ebenfalls eine ZIP-Datei die entpackt werden muss. Alle Dateien und Ordner im features Ordner müssen in den features Ordner von Eclipse kopiert werden. Alle Dateien und Ordner im Verzeichnis plugins müssen in den plugins Ordner von Eclipse kopiert werden.

== Installation unter Linux ==

===openSuSE===
Eclipse läßt sich einfach via zypper oder yast installieren:

zypper install eclipse

Crosscompiler, avr-libc und avrdude:

zypper install avr-libc

=== Gentoo ===
==== Eclipse-IDE ====
* [http://www.eclipse.org/downloads/index.php Eclipse-IDE] Version 3.1.0
* [http://www.eclipse.org/cdt/ Eclipse-CDT-Plugin] Version 3.0.0
* [http://sf.net/projects/avr-eclipse Eclipse-CDT-Addon for AVR] Version 20070404

==== Compiler ====
crossdev emergen:
* emerge crossdev
Stabile Version der avr-toolchain inkl. g++ kompilieren:
* USE="-nocxx" crossdev -s4 -S -t avr

==== Programmer ====
* emerge uisp

=== Debian ===
==== Eclipse-IDE ====
* [http://www.eclipse.org/downloads/index.php Eclipse-IDE] Version 3.1.0
* [http://www.eclipse.org/cdt/ Eclipse-CDT-Plugin] Version 3.0.0
* [http://sf.net/projects/avr-eclipse Eclipse-CDT-Addon for AVR] Version 20070404

==== Compiler ====
* binutils-avr 2.15-3
* gcc-avr 1:3.4.3-2
* avr-libc 1:1.2.3-3

==== Debugger ====
* simulavr 0.1.2.2-1
* gdb-avr 6.3-2
* ? avra 0.7-1

==== Programmer ====
* AVRDUDE und die GUI [http://avr8-burn-o-mat.aaabbb.de/ avr8-burn-o-mat]
* uisp 20050207
* ? avrp
* ? avrprog

=== Ubuntu 8.10 (Zum ersten) ===
==== Eclipse-IDE ====
* [http://www.eclipse.org/downloads Eclipse IDE for C/C++ Developers] Version 3.3, CDT Version 4.0
* [http://sourceforge.net/projects/avr-eclipse AVR-Eclipse-Plugin] Version 2.2.0

==== Compiler ====
* binutils-avr: 2.18-3
* gcc-avr: 1:4.3.0-2
* avr-libc: 1:1.6.2-1

==== Debugger ====
* [ftp://ftp.gnu.org/gnu/gdb/gdb-6.6.tar.bz2 avr-gdb]: 6.6; '''In den Repositories ist 6.4.90!'''
* avarice: 2.7-2
* simulavr: 0.1.2.2-6.1 (nicht getestet, sollte aber genauso funktionieren)

==== Programmer ====
* avrdude: 5.5-3 und GUI [http://avr8-burn-o-mat.aaabbb.de/ avr8-burn-o-mat]

==== Zusätzliche notwendige Programme/Libraries ====
* gcc
* binutils-avr
* build-essential
* ncurses-dev

=== Ubuntu (Zum zweiten) ===
==== AVR-Toolchain ====
Leider ist in den Repositories nur eine veraltete Version von avr-gdb (bzw. gdb-avr) enthalten. Diese Version hat bei mir zu Fehlern geführt. Deshalb wird die aktuelle Releaseversion 6.6 verwendet.

==== Schritt für Schritt ====
Als erstes werden die notwendigen Programme aus den Repositories installiert:

<pre>sudo apt-get install gcc gcc-avr avr-libc avrdude binutils-avr avarice build-essential ncurses-dev</pre>

Ubuntu 6.10:
<pre>sudo apt-get install gcc gcc-avr avr-libc avrdude binutils-avr avarice build-essential libncurses5-dev</pre>

Zusätzlich können auch noch folgende Packages interessant sein:
* Simulavr: Ein Simulator für die AVR-Reihe
* uisp: Alternativer Downloader

<pre>sudo apt-get install simulavr uisp</pre>

Jetzt kann man bereits das AVR-Target ansprechen, um z. B. die Fuses auszulesen:

<pre>avarice -j /dev/ttyUSB0 -P atmega128 -r</pre>
* -j: Gibt das Gerät an, mit dem das Target verbunden ist.
* -P: Zielarchitektur
* -r: Read Fuses

Dazu ist die Manpage von avarice zu empfehlen:
<pre>man avarice</pre>

Als nächstes muss gdb-avr heruntergeladen und dann kompiliert werden:

<pre>wget ftp://ftp.gnu.org/gnu/gdb/gdb-6.6.tar.bz2
tar jxf gdb-6.6.tar.bz2
cd gdb-6.6
./configure --target=avr --prefix=/usr/local/avr
make
sudo make install
cd ..
rm -rf gdb-6.6</pre>

Dies installiert die aktuelle Version von gdb-avr unter /usr/local/avr. Diesen Pfad könnte man zur PATH-Variable hinzufügen, dies ist allerdings nicht zwingend notwendig.

Unter Ubuntu 8.10 kommt es bei der Installation zu Problemen.
Hier gibt es Abhilfe:
http://www.mikrocontroller.net/topic/76404#1198507

'''Zitat:'''

Die Fehlermeldung lautet ja:
<pre>
avr-dis.c:xxx: error: format not a string literal and no format arguments
</pre>
und Zeile xxx in dieser Datei lautet: <c>sprintf (buf, xyz);</c> Wenn man das in <c>strcpy(buf, xyz);</c> ändert, sollte es funktionieren.

== Einrichten von Eclipse unter Windows ==
Beim ersten Start muss man einen Workspace angeben, dazu kann das vorgeschlagene Standardverzeichnis verwendet werden, wenn nur ein Benutzer diesen Workspace verwendet, ansonsten sollte man einen Ort auswählen, auf den alle Zugriff haben. Danach sollte das Bild so aussehen. Klicke auf Workbench.

[[Bild:EclipseStart.png]]

== Einrichten von Eclipse unter Linux ==

=== Alternative 1 ===

Das AVR-Eclipse Plugin kann über die Update-Site http://avr-eclipse.sourceforge.net/updatesite/ installiert werden. (Help->Software Updates...)

Zum Schluss muss noch, die avr-objsplit.bat-Datei, wie folgt, umgeschrieben, nach /usr/bin/avr-objsplit kopiert und ausführbar gemacht werden.

<pre>
#!/bin/bash

avr-objcopy -j .text -j .data -O ihex *.elf flash.hex
avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O ihex *.elf eeprom.hex
if [ ! -f eeprom.hex ]; then
echo ":00000001FF" > eeprom.hex
fi
</pre>

Ändern der Rechte:
<pre>
chmod +x avr-objsplit
</pre>

==== Einstellungen ====
Jetzt müssen noch gewisse Einstellungen in Eclipse angepasst werden:
Unter Window->Preferences->AVR->AVRdude:

* Programmer auswählen
* Programmerport auswählen
* Target MCU Type auswählen

==== Projekteinstellungen ====
Jetzt kann ein neues C-Project angelegt werden, wobei als Projekttyp "AVR Cross-Target Project" ausgewählt werden muss. Im "New Project Wizard" kann der MCU-Typ und die Quarzfrequenz eingestellt werden. Weitere Compiler-Optionen sind in den Projekteinstellungen unter "C/C++ Build->Settings" möglich.

=== Alternative 2 ===

Dabei werden die Projekteinstellungen eines Standard-C-Projekts so verändert, dass die AVR-Toolchain verwendet wird.

Mein erster erfolgreicher Versuch lief mit einen "managed C Projekt". Ich hoffe in der folgenden Beschreibung fehlt kein Schritt:
* File / New / Managed Make C Project
** Project Name '''"test2" [Next]'''
** Project Type '''"Executable (GNU)" [Next]'''
** C/C++ Indexer '''"full ..." [Finish]''' (hab ich später geändert siehe unten)

==== Projekteinstellungen ====
* File / New / SourceFile
** '''[Browse] "test2" [OK]'''
** Source File: '''"test2.c" [Finish]'''
* Project / Properties
** C/C++ Build / ToolSettings
*** GCC-C-Compiler
**** Command: '''gcc''' ändern auf '''avr-gcc -mmcu=atmega16 -c'''
**** Das '''-c''' ist wichtig, damit nur kompliert aber nicht gelinkt wird.
**** Directorys Eintrag '''/usr/avr/include''' einfügen
**** Debugging gewünschten Wert einstellen (z. B. -g)
*** GCC-C-Linker
**** Command: '''gcc''' auch ändern auf '''avr-gcc -mmcu=atmega16 '''
**** Libraries: Library Search Path= '''/usr/avr'''
**** Miscellaneous: Linker Flags = '''-Wl,-Map,avr.map'''
*** GCC Assembler
**** Command: '''as''' ändern auf ''avr-as''
** C/C++ Build / Build Steps
*** Post-Build-Step
**** Command: '''avr-objcopy -j .text -j .data -O ihex test2 test2.hex'''
** C/C++ Indexer
*** Available Indexers = '''CTags Indexer (declarations only)'''
*** Include Files: Index Include paths ''' einschalten'''

==== später eingefügt: ====
* Project / Properties
** C/C++ Build / Build Steps
*** Pre-Build-Step
**** Command: '''uisp -dprog=dasa2 -dserial=/dev/ttyS0 -dpart=atmega16 --erase'''
* Project / Properties
** C/C++ Build / Build Steps
*** Post-Build-Step
**** Command: '''avr_upload'''
* Project / Properties
** C/C++ Build / Build Settings
*** Build Output
**** Artifact Name: '''avr_main'''

avr_upload ist eine kleine Batchdatei im Verzeichniss '''/usr/bin ''', die ich neu angelegt hab:
<pre>
#!/bin/sh
# .lst-Datei erzeugen (optional)
# avr-objdump -h -S avr_main > avr.lst
# Datei in Intel-hex erzeugen
avr-objcopy -j .text -j .data -O ihex avr_main avr.hex
# Intel-hex-Datei uploaden
#uisp -dprog=dasa2 -dserial=/dev/ttyS0 -dpart=atmega16 --upload if=avr.hex
# Intel-hex Datei uploaden und verifizieren.
uisp -dprog=dasa2 -dserial=/dev/ttyS0 -dpart=atmega16 --upload if=avr.hex --verify
</pre>

==== Eclipse Plugin ====

Im Forum gibt es ein Plugin für Eclipse, das einen Großteil dieser Einstellungen bereits beinhaltet. Der Thread steht unter:

http://www.mikrocontroller.net/forum/read-2-229419.html#new

Das Plugin wird dort zum Download angeboten. Aber es ist sicher hilfreich die dortige Anleitung zu beachten.

http://www.mikrocontroller.net/attachment.php/285349/org.eclipse.cdt.avrgcc_1.0.16.zip

'''HINWEIS:''' Bitte die aktuelle Version benutzen. Folgende Warnung bezieht sich auf die älteren Versionen (vor Version 1.0.14).
'''WARNUNG:''' Bei mir funktionierten Timer-Interrupts mit dem Plugin nicht (die jedoch tadellos mit der WinAVR Makefile funktionierten). Vielleicht habe ich nur eine Option übersehen, seid aber auf der Hut. Wenn ihr Unregelmäßigkeiten bei IRQs feststellt, versucht's erstmal ohne das Eclipse-Plugin (bevor ihr stundenlang an eurem Code und euch selbst zweifelt :-) ).

== Projekt erstellen ==
[[Bild:NewProject.png]]

Wichtig ist, dass man '''AVR Cross Target Application''' auswählt

[[Bild:CreateProject.png]]

Beim nächsten Schritt kann man auswählen, was für Konfigurationen man will. In den meisten Fällen reicht es aus, wenn man nur '''Release''' auswählt.

[[Bild:SelectConfigurations.png]]

In diesem Schritt wählt man den Prozessor und die Taktfrequenz aus, wobei die Taktfrequenz in Hz angegeben werden muss

[[Bild:TargetHardwareProperties.png]]

== Erster Test ==
Die jeweiligen Alternativen beziehen sich auf die oben genannten verschiedenen Möglichkeiten.

=== Aufbau ===
Die folgenden Angaben beziehen sich auf ein sehr einfaches Entwicklungsboard von Pollin, welches aber auch einfach nachgebaut werden kann. Den Schaltplan gibt's [http://www.pollin.de/shop/downloads/D810022B.PDF als PDF hier].

==== Programm eintippen ====
(oder einfach von hier kopieren)
<pre>
#include <avr/io.h>

#define running 1

// Unterprogramm mit Zeitschleife fuer ATMega16 ohne Quarz
void delay_ms( unsigned int ms )
{
unsigned int i;
unsigned int j;

for ( i = ms; i; i-- )
{
for ( j = 51; j; j-- )
{
}
}
}

int main( void )
{
// PortD6 als Output konfigurieren
DDRD |= _BV(PD6);

// Hauptschleife des Programms
while ( running )
{
// LED einschalten, und dann warten
PORTD |= _BV(PD6);
delay_ms( 1000 );

// LED ausschalten, und dann warten
PORTD &= ~_BV(PD6);
delay_ms( 29000 );
}
}
</pre>

Um dass Programm zu kompilieren muss links im '''Project Explorer''' der Projektordner angeklickt werden.

[[Bild:MakeTarget.png]]

Eine Konfiguration fügt man mit '''Add''' hinzu. In neuen Fenster gibt man als '''Target Name''' einen Namen ein. Der Name wird später unter anderem für den Dateinamen der HEX-Datei verwendet.

[[Bild:MakeTargetOptions.png]]

Die Einstellungen mit '''Create''' bestätigen und das andere Fenster mit '''Cancel''' schliessen. Ändert man nun eine Datei und speichert sie ab, wird das Projekt automatisch kompiliert. Das kann übrigens über '''Project''' --> '''Build Automatically''' geändert werden, da es bei grossen Projekten nachteilig ist, wenn der da die ganze Zeit kompiliert. Ob das ganze funktioniert hat kann man überprüfen, indem man auf '''Console''' klickt. Wenn das Kompilieren erfolgreich war, sollte die Ausgabe etwa so aussehen:

<pre>
**** Build of configuration Release for project AVRTest ****

make
Building target: AVRTest.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,AVRTest.map -mmcu=atmega8 -o"AVRTest.elf" ./main.o
Finished building target: AVRTest.elf

Invoking: AVR Create Extended Listing
avr-objdump -h -S AVRTest.elf >"AVRTest.lss"
Finished building: AVRTest.lss

Create Flash image (ihex format)
avr-objcopy -R .eeprom -O ihex AVRTest.elf "AVRTest.hex"
Finished building: AVRTest.hex

Create eeprom image (ihex format)
avr-objcopy -j .eeprom --no-change-warnings --change-section-lma .eeprom=0 -O ihex AVRTest.elf "AVRTest.eep"
Finished building: AVRTest.eep

Invoking: Print Size
avr-size --format=avr --mcu=atmega8 AVRTest.elf
AVR Memory Usage
----------------
Device: atmega8

Program: 108 bytes (1.3% Full)
(.text + .data + .bootloader)

Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)

Finished building: sizedummy
</pre>

== Projekteinstellungen ==
=== Allgemein ===
Die Einstellungen können unter '''Project''' --> '''Properties''' --> '''C/C++ Build''' --> '''Settings''' vorgenommen werden. Auch hier muss man zuerst das Projekt im '''Project Explorer''' erstmal anklicken.

[[Bild:ProjectProperties.png]]

=== Prozessor / Taktfrequenz ===
Den Prozessor oder die Taktfrequenz kann man hier verändern
'''Project''' --> '''Properties''' --> '''AVR''' --> '''Target Hardware'''

== Prozessor brennen ==
=== AVRDude ===
Den Prozessor kann man mit dem '''AVR''' Button in der Symbolleiste direkt aus Eclipse heraus mit AVRDude programmieren, dafür muss man aber gewisse Einstellungen vornehmen.

=== Programmierhardware auswählen ===
'''Project''' --> '''Properties''' --> '''AVR''' --> '''Target Hardware''' Danach klickt man auf den Tab '''Programmer''' und dann auf '''New'''. In der Liste wählt man einen Programmer aus und nimmt gegebenen falls zusätzliche Einstellungen vor.

=== HEX-Datei auswählen ===
'''Project''' --> '''Properties''' --> '''AVR''' --> '''Target Hardware''' Danach klickt man auf den Tab Flash/EEPROM. Eigentlich reicht es aus, '''from Build''' auszuwählen.

=== Fuse- / Lockbits ===
Zu den Fuse- bzw. Lockbits gibt es in den jeweiligen Tabs diverse Einstellmöglichkeiten.

== Debugging ==

Debuggen funktioniert mit Eclipse entweder mit '''avarice''' oder '''simulavr''', wobei ersteres zum OnDeviceDebugging dient und zweiteres einen Simulator darstellt. Zusätzlich ist '''avr-gdb''' notwendig, welches wie unter '''Installation unter Ubuntu''' beschrieben, installiert werden kann.
Einen Link zu einer Anleitung für das Debuggen mit Eclipse unter Windows findet ihr unten bei den [http://www.mikrocontroller.net/articles/AVR_Eclipse#Links Links].

=== simulavr ===
<pre>simulavr -g -p 1212 -d atmega16 -P simulavr-disp</pre>
startet den Simulator.

=== avarice ===
<pre>avarice -j /dev/ttyS0 -P atmega128 :1212</pre>
startet einen Server, der auf Port 1212 lauscht und das OnDeviceDebugging übernimmt.

=== Eclipseeinstellungen ===
Unter Eclipse muss ein neues Debug-Target erzeugt werden, was in den Projekteinstellungen unter ''Run/Debug-Settings'' funktioniert. Es muss ''C/C++ application'' ausgewählt werden und folgende Einstellungen müssen geändert werden:
* Debugger
** gdbserver auswählen
** GDB debugger: Pfad zu avr-gdb (/usr/local/avr/bin/avr-gdb)
** ''verbose console mode'' einschalten
* Connection
** TCP, localhost, port 1212 (siehe simulavr/avarice-Aufruf).

Unter Debugger muss für die Verwendung des Simulators Command-Datei mit folgendem Inhalt angegeben und daher auch erstellt werden:
<pre>
file link.elf
targ rem :1212
load
</pre>
link.elf ist die Datei, welche durch den Build erstellt wird. Dies muss daher angepasst werden.

Beim On Device Debugging muss keine Command-Datei angegeben werden.

=== Auslesen von IO-Registern ===
Wenn ''verbose console mode'' eingeschaltet ist, kann in diesem Konsolenfenster direkt mit avr-gdb kommuniziert werden. Dadurch können unter anderem die Register ausgelesen werden:
<pre>p/x *(char *)Adresse</pre>
gibt den Wert der Adresse als char aus.
<pre>p/t *(char *)Adresse</pre>
returniert den Binärwert.

Die Adresse setzt sich aus einer Startadresse und einem Offset zusammen, wobei diese sich im entsprechenden io-Header der Architektur befindet. Beispielweise setzt sich die Adresse für das UCSR0B-Register eines Atmega128 aus der Startadresse 0x800020 und dem Offset 0x0A zusammen.

Für oft verwendete Register empfiehlt es sich, diesen mittels
<pre>set $name=(char *)Adresse</pre>
einen Namen zuzuweisen. Diese könnte man in einer Datei speichern und diese als command-Datei beim Debugger angeben, wodurch man sich diese händischen Eingaben spart und mittels
<pre>p/x *$name</pre> bzw. <pre>display *$name</pre>
zugegreifen kann.

=== AVR Studio ===

Hinweise zum Debuggen mit [[AVR Studio]] (Windows) in einem Eclipse-Projekt gibt Marcel K. in http://www.mikrocontroller.net/topic/152059#1428733

= Links =
[http://www.torsten-horn.de/techdocs/java-eclipse.htm Erste Schritte mit Eclipse]

[http://avr-eclipse.sourceforge.net/wiki/index.php/Debugging Anleitung zum Debuggen mit Eclipse unter Windows]

[http://www.wiki.elektronik-projekt.de/mikrocontroller/avr/avr_tutorials 3 Tuts für Eclipse mit AVRs]

= Weiteres =
Bei Problemen kann dieser [http://www.mikrocontroller.net/topic/79965#667525 Thread] verwendet werden, in den ich, wann immer es sich bei mir ausgeht, schauen werde.

Jeder ist aufgerufen hier weiterzumachen, wenn er mehr weiss, oder es besser gestalten kann.

[[Kategorie:AVR ]]

Compact Plus Blutzuckermessgerät-Hardware

2010-01-20T23:33:24Z

Muebau: aufraeumen

== Hardware ==
=== Übersicht Hardware ===
* OLED Display 102×80 Pixel incl. 16 Helligkeitsstufen pro Pixel / SSD1325 /43x36 mm gesamt
* Atmega168PA
* DC/DC-Wandler (Regler und Drosseln)
* IR-Sender/Empfänger
* 3 Tasten (4 wenn man den Schließer der Klappe mitzählt)
* 2 Elektromotoren
* kleine Lichtschranke/Barcodescanner
* kleines Spektrometer (2 * LEDs rot, IR(?)-LED, Fotodiode)
* Betriebsspannung 3V (2*AAA)
* SMD Piezo-Summer

=== Gerät als Ganzes ===
[[Bild:compact_plus.jpg|400px]]

Das unzerlegte Gerät. Ganz links ist die Stechhilfe.

=== Gerät zerlegen ===
Das Gehäuse besteht aus drei ineinander einrastenden Teilen (keine Schrauben). Relativ schadlose Demontage durch vorsichtiges Aufhebeln möglich.
Erst das Seitenteil (links) ganz oben und 2 cm von unten ausrasten.
Von unten anfangen die Gehäusehälften zu lösen, bis man sie über die Oberkante aufklappen kann.

Die Platine selbst ist mit 2 Schrauben und ein paar Clipsen befestigt. Vor dem Entnehmen ist der untere Folienstecker abzuziehen.

[[Bild:compact_plus_open.jpg|250px]]

Das geöffnete Gerät ohne Platine.
Gut zu erkennen (im unverkleinertem Bild) sind die zwei Motoren und die Mechanik die dafür sorgen, dass die Aufbewarungstrommel gedreht und die Messstreifen herausgefahren werden können.

=== Komponenten ===

==== Board ====
Hochauflösende Scans beider Platinenseiten.
Die Bauteile sind nach bestem Wissen und Gewissen bezeichnet (für spätere Schaltpläne). Speziell bei den Widerständen und Kondensatoren ist noch eine Kontrolle notwendig. Ich habe dabei alle blauen und schwarzen Bauteile als Widerstände und alles graue und weiße als Kondensatoren gedeutet.

Änderungen bitte mir (Netzwanze) melden.

[[Bild:AccuCheckL1.jpg|300px]][[Bild:AccuCheckL6.jpg|300px]]

==== Stromversorgung ====
Die zwei AAA Zellen sind in Serie geschaltet.
Ein Schaltregler [IC7] erzeugt daraus 3.3 V.
Ein Schaltregler [IC6] erzeugt daraus 12 V für das OLED.

==== Bauteilliste ====

Nach bestem Wissen und Gewissen bestimmt durch Kombination aus Schaltplänen und Messungen. Bei Komponenten mit "(?)" bin ich mir nicht sicher.

{| class="wikitable"
|-
! Bauteil || Größe
|-
| R1 || 820 kOhm
|-
| R35 || Temperaturfühler; NTC 10 kOhm bei 20°C (?)
|-
| R43 || 100 kOhm
|-
| R44 || 100 Ohm
|-
| R45 || 39 kOhm
|-
| R46 || 1 MOhm
|-
| C24 || 22 uF (?)
|-
| C38 || 4,7 uF
|-
| C39 || 4,7 uF
|-
| C44 || 100 nF
|-
| C45 || 470 nF (?)
|-
| C46 || 10 pF
|-
| L2 || 100 uH
|-
| IC1 || ASIC
|-
| IC2 || ATmega168A
|-
| IC3 || Atmel AT25640A SPI EEPROM
|-
| IC4 || NC7NP14 ULP Triple Inverter with Schmitt Trigger Input
|-
| IC5 || 74LVC1G86GV (Markierung V68)
|-
| IC6 || TPS61080 Step-up 12 V
|-
| IC7 || AS1329, Step-up 3,3 V
|-
| IC8 || BIG 01 A825MFL ????
|-
| IC9 || [[#IC9 (IR)|IR (TFDU2201)]]
|-
| Buzzer || [[#Buzzer|Piezo Schallwandler]]
|-
| D1 || BAT54W
|-
| XTAL1 || 32 Khz
|-
| XTAL2 || 4 Mhz
|}

==== Pinbelegung Mega168 ====

Wie oben mittles Messungen ermittelt. Ohne Garantie auf Vollständigkeit und Richtigkeit.

{| class="wikitable"
|-
! Pin || Port || Funktionen || Verwendung
|-
| 1 || PD3 || (PCINT19/OC2B/INT1) || Taste Mitte (S2)
|-
| 2 || PD4 || (PCINT20/XCK/T0) || Display SCLK (XCLK)
|-
| 3 || GND || || GND
|-
| 4 || VCC || || VCC
|-
| 5 || GND || || GND
|-
| 6 || VCC || || VCC
|-
| 7 || PB6 || (PCINT6/XTAL1/TOSC1) || An 32,768(?)kHz Oszillator. Taktsignal auch ohne ASIC vorhanden.
|-
| 8 || PB7 || (PCINT7/XTAL2/TOSC2) || enable 3.3V step-up
|-
| 9 || PD5 || (PCINT21/OC0B/T1) || VCC enable (12 V step-up)
|-
| 10 || PD6 || (PCINT22/OC0A/AIN0) ||
|-
| 11 || PD7 || (PCINT23/AIN1) ||
|-
| 12 || PB0 || (PCINT0/CLKO/ICP1) || an Transistor T1 (schaltet 12 V über 100 Ohm gegen GND als Grundlast bzw. zum Entladen)
|-
| 13 || PB1 || (PCINT1/OC1A) || Display /CS
|-
| 14 || PB2 || (PCINT2/SS/OC1B) || Anschluss des [[#Buzzer|Buzzers]] möglich
|-
| 15 || PB3 || (PCINT3/OC2A/MOSI) || ISP MOSI
|-
| 16 || PB4 || (PCINT4/MISO) || ISP MISO
|-
| 17 || PB5 || (SCK/PCINT5) || ISP SCK
|-
| 18 || AVCC || || mit Beschaltung an VCC
|-
| 19 || ADC6 || || Batteriespannung (3.3Volt StepUp dafür abschalten)
|-
| 20 || AREF || || mit Beschaltung an VCC (REFS1=0, REFS0=1)
|-
| 21 || GND || || GND
|-
| 22 || ADC7 || || Ausgang des 3,3V step-up über Spannungsteiler. Mit Step-Up wird 707 gemessen, ohne ca. 637.
|-
| 23 || PC0 || (ADC0/PCINT8) || Batteriespannung über Spannungsteiler, bei voller Batterie ca. 638
|-
| 24 || PC1 || (ADC1/PCINT9) || Display D/C
|-
| 25 || PC2 || (ADC2/PCINT10) || Display RESET
|-
| 26 || PC3 || (ADC3/PCINT11) ||
|-
| 27 || PC4 || (ADC4/SDA/PCINT12) || Taste Links (S1)
|-
| 28 || PC5 || (ADC5/SCL/PCINT13) || Taste rechts (S3)
|-
| 29 || PC6 || (RESET/PCINT14) || ISP Reset
|-
| 30 || PD0 || (RXD/PCINT16) ||
|-
| 31 || PD1 || (TXD/PCINT17) || Display SDIN. Achtung, ist auch TxD (UART-SPI möglich)
|-
| 32 || PD2 || (INT0/PCINT18) ||
|}

==== Unbekanntes IC1 ====

Hier mal der Dekodierte Barcode des noch Unbekannten IC1.
Der decodierte Text ist:

25SLEATM 8R4222 084420179+2P00+PLCMC

[[Bild:AccuCheckDecodedMatrixCode.png|500px]]

==== IC9 (IR) ====

Ist wohl ein TFDU2201 ([http://www.vishay.com/docs/82539/tfdu2201.pdf Datenblatt]).

[[Bild:Accu chek combo ir.png|320px]] [[Bild:AccuCheckIRDA(TFDU2201)Pinout.png|320px]]

==== Buzzer ====

Ist ein Piezo Schallwandler. Es ist möglich eine ihn mit PB2 des [[#Pinbelegung Mega168|mega168]] zu verbinden. Im Bereich "Kurzzeitwecker mit 7-Segment-Anzeige" auf adriano6's [[#Websites|Webseite]].

==== Display ====
[[Bild:display.JPG|300px]]

Das Display basiert auf OLED - Technologie und besitzt eine Auflösung von 102×80 Pixel, von denen jedes 16 Helligkeitsstufen darstellen kann.
Displaycontroller ist SSD1325.

Detailierte Informationen zum Display gibts auf adriano6's [[#Websites|Webseite ]]

===== Inbetriebnahme auf dem Board =====

Es ist möglich das Display auf dem Board in Betrieb zu nehmen, wenn alle Komponenten bis auf:
R1, R43, R44, R45, R46, C24, C38, C39, C44, C45, C46, L2, IC6 und D1
entfernt werden.
T1 und R11 sind vermutlich als Grundlast zum Start des 12 V Step-up und zum Entladen des OLED beim Abschalten.
Die folgende Tabelle enthält die Pads des Atmega168 Footprints und die entsprechenden Pins am Display.

{| class="wikitable"
|-
! Pad am Atmega168 || Pin am Display
|-
| PD1 || SDIN
|-
| PD4 || SCLK
|-
| PC1 || D/C
|-
| PC2 || RESET
|-
| PB1 || /CS
|}

===== Grafikbeschleunigung mit dem SSD1325 =====

Mit dem im SSD1325 vorhandenen Befehlen Copy, DrawRectangle und HorizontalScolling kann man ein paar nette Animationen machen, bzw. dem ATmega eine Menge Arbeit abnehmen (Details zu Controller und Display stehen im Datenblatt und [[#Websites|hier ]]).

Der Displaycontroller verfügt über ein 64x80 Bytes großes RAM, von dem das Display aber nur 51x80 Bytes (102x80 Pixel) darstellt, beginnend von Spalte 7 bis Spalte 57:

{| class="wikitable" style="text-align:center; width:60em"
! colspan=2 style="width:6em" | Col0
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col6
! colspan=2 style="width:6em; background:#c0c0c0" | Col7
! colspan=2 style="width:6em; background:#c0c0c0" | ...
! colspan=2 style="width:6em; background:#c0c0c0" | Col56
! colspan=2 style="width:6em; background:#c0c0c0" | Col57
! colspan=2 style="width:6em" | Col58
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col63
|- style="width:3em"
| D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0
|}

Schaltet man im Controller nun Wraparound für das Scrolling- und Copy-Commando ein, hängen Ende und Anfang der jeweiligen Zeile hintereinander:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col0 || style="width:6em" | ... || style="width:6em" | Col6
|}

Aus Sicht des Copy- und DrawRectangle-Kommandos kann man jetzt folgendermaßen auf den nicht sichtbaren Bereich des Display-RAM zugreifen:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col64 || style="width:6em" | ... || style="width:6em" | Col70
|}

Um Daten in diesen Bereich zu bekommen, könnte man einen entsprechenden Bildschirmausschnitt definieren und die Daten einfach sequentiell da rein schreiben. Praktisch hat das aber nicht einwandfrei funktioniert. Besser schreibt man zuerst in den sichtbaren Bereich und kopiert dann den Block in den Bereich ab Spalte 58.
Statt jetzt Grafiken byteweise über die Schnittstelle in das RAM zu schreiben braucht man sie nur noch durch den Controller vom unsichtbaren Bereich (maximal 26x80 Pixel) in den sichtbaren kopieren zu lassen.

Ich habe [http://www.mikrocontroller.net/topic/109648#1419368 eine kleine Demo] geschrieben, die mit dem Copy-Befehl 8 Sprites (sich drehende Bälle) fliegen läßt und bei jeder Randberührung eines Sprites einen Zähler erhöht. Im Hintergrund laufen je eine horizontale und vertikale Linie (Rechteck) durch.
Das Ganze verbraucht mit Software-SPI ca. 20% Rechenzeit des ATmega, bei Hardware-SPI sind es ca. 6%.

Um auch in horizontaler Richtung eine pixelgenaue Bewegung zu erreichen, erstellt man für jedes Sprite zwei um jeweils ein Pixel verschobene Versionen, und kopiert diese nacheinander auf die selbe Spaltenposition.

Das Timing ist etwas kritisch, da vom Controller keine Rückmeldung möglich ist, man muß ggf. die Wartezeit nach einem Kommando versuchsweise ermitteln. Schickt man das nächste Kommando zu früh ab, wird das gerade laufende abgebrochen, was nicht immer schön aussieht oder sogar den Controller zum Abstürzen bringt.

Bei Ansteuerung mit Hardware-SPI muß man außerdem ca. 2us warten, bevor das CS-Signal deaktiviert werden kann.

==== Spektrometer ====
[[Bild:Accu-Check_CompactPlus_BZ_Sensor.jpg|200px]]

Im Grunde genommen, handelt es sich um eine Reflexlichtschranke mit zwei roten LEDs, einer vermutlich infraroten LED, sowie einer Fotodiode.

[[Bild:Accu-Check_CompactPlus_Photometer.jpg|200px]]

== Software ==
=== Programmierung ===
==== AVRdude ====
Auslesen der Fuses
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -v

avrdude: Device signature = 0x1e940b
avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: safemode: lfuse reads as 42
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 1

==== Flashen mit AVRdude ====
Da die IDs von ATmega168 und ATmega168A abweichen, muss die Option -F mit avrdude verwendet werden.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -u -U flash:w:Oled-Demo.hex

==== Fuses mit AVRdude ====
Der ATmega168A hat die Fuse CLKDIV8 eingeschaltet.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -U lfuse:w:0xC2:m

=== Programme ===
==== µC ====
* GPS http://www.mikrocontroller.net/topic/109648#1385554
** http://www.mikrocontroller.net/topic/109648#1397017

* Grafikdemo: http://www.mikrocontroller.net/topic/109648#1419368
** Video: http://vimeo.com/6609124

* Kurzzeitwecker: http://www.mikrocontroller.net/topic/109648#1412841
** http://www.mikrocontroller.net/topic/109648#1427502

* serielle Displaysteuerung: http://www.mikrocontroller.net/topic/109648#1487494

==== PC ====
* [http://www.mikrocontroller.net/topic/109648#1352701 gibt als Header gespeicherte Bilder auf std aus]
* [http://www.mikrocontroller.net/topic/109648#1353067 Erweiterter (ungetesteter) Konvertierer für Bilder in Format für Display]

== Links ==

=== Technische Dokumente ===
* [http://www.crystalfontz.com/controllers/SSD1325_2.1.pdf Datenblatt für Display-Controller]
* [http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega168PA AVR Produktseite ATmega168PA mit Datasheets ]
* [http://www.freshpatents.com/Device-for-analysis-of-a-sample-on-a-test-element-dt20081113ptan20080277280.php Patentschrift zu Gerät ]

=== Websites ===
* [http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html Oled-Recycling Seite von adriano6]

=== Diskussions Threads ===

* [http://www.mikrocontroller.net/topic/109648 Hauptdiskussionsthread im Mikrocontrollernet ]
* [http://bascom-forum.de/index.php/topic,2754.0.html Umsetzung in Bascom (wer's mag) im Bascom-Forum]
* [http://www.mikrocontroller.net/topic/143806 Vorschlag für Display-Adapter-Platine]

[[Category:AVR-Projekte]]

Compact Plus Blutzuckermessgerät-Hardware

2010-01-20T23:16:24Z

Muebau: /* IC9 (IR) */

== Hardware ==
== Übersicht Hardware ==
* OLED Display 102×80 Pixel incl. 16 Helligkeitsstufen pro Pixel / SSD1325 /43x36 mm gesamt
* Atmega168PA
* DC/DC-Wandler (Regler und Drosseln)
* IR-Sender/Empfänger
* 3 Tasten (4 wenn man den Schließer der Klappe mitzählt)
* 2 Elektromotoren
* kleine Lichtschranke/Barcodescanner
* kleines Spektrometer (2 * LEDs rot, IR(?)-LED, Fotodiode)
* Betriebsspannung 3V (2*AAA)
* SMD Piezo-Summer

== Gerät als Ganzes ==
[[Bild:compact_plus.jpg|400px]]

Das unzerlegte Gerät. Ganz links ist die Stechhilfe.

== Gerät zerlegen ==
Das Gehäuse besteht aus drei ineinander einrastenden Teilen (keine Schrauben). Relativ schadlose Demontage durch vorsichtiges Aufhebeln möglich.
Erst das Seitenteil (links) ganz oben und 2 cm von unten ausrasten.
Von unten anfangen die Gehäusehälften zu lösen, bis man sie über die Oberkante aufklappen kann.

Die Platine selbst ist mit 2 Schrauben und ein paar Clipsen befestigt. Vor dem Entnehmen ist der untere Folienstecker abzuziehen.

[[Bild:compact_plus_open.jpg|250px]]

Das geöffnete Gerät ohne Platine.
Gut zu erkennen (im unverkleinertem Bild) sind die zwei Motoren und die Mechanik die dafür sorgen, dass die Aufbewarungstrommel gedreht und die Messstreifen herausgefahren werden können.

== Komponenten ==

=== Board ===
Hochauflösende Scans beider Platinenseiten.
Die Bauteile sind nach bestem Wissen und Gewissen bezeichnet (für spätere Schaltpläne). Speziell bei den Widerständen und Kondensatoren ist noch eine Kontrolle notwendig. Ich habe dabei alle blauen und schwarzen Bauteile als Widerstände und alles graue und weiße als Kondensatoren gedeutet.

Änderungen bitte mir (Netzwanze) melden.

[[Bild:AccuCheckL1.jpg|300px]][[Bild:AccuCheckL6.jpg|300px]]

=== Stromversorgung ===
Die zwei AAA Zellen sind in Serie geschaltet.
Ein Schaltregler [IC7] erzeugt daraus 3.3 V.
Ein Schaltregler [IC6] erzeugt daraus 12 V für das OLED.

=== Komponenten ===

Nach bestem Wissen und Gewissen bestimmt durch Kombination aus Schaltplänen und Messungen. Bei Komponenten mit "(?)" bin ich mir nicht sicher.

{| class="wikitable"
|-
! Bauteil || Größe
|-
| R1 || 820 kOhm
|-
| R35 || Temperaturfühler; NTC 10 kOhm bei 20°C (?)
|-
| R43 || 100 kOhm
|-
| R44 || 100 Ohm
|-
| R45 || 39 kOhm
|-
| R46 || 1 MOhm
|-
| C24 || 22 uF (?)
|-
| C38 || 4,7 uF
|-
| C39 || 4,7 uF
|-
| C44 || 100 nF
|-
| C45 || 470 nF (?)
|-
| C46 || 10 pF
|-
| L2 || 100 uH
|-
| IC1 || ASIC
|-
| IC2 || ATmega168A
|-
| IC3 || Atmel AT25640A SPI EEPROM
|-
| IC4 || NC7NP14 ULP Triple Inverter with Schmitt Trigger Input
|-
| IC5 || 74LVC1G86GV (Markierung V68)
|-
| IC6 || TPS61080 Step-up 12 V
|-
| IC7 || AS1329, Step-up 3,3 V
|-
| IC8 || BIG 01 A825MFL ????
|-
| IC9 || [[#IC9 (IR)|IR (TFDU2201)]]
|-
| Buzzer || [[#Buzzer|Piezo Schallwandler]]
|-
| D1 || BAT54W
|-
| XTAL1 || 32 Khz
|-
| XTAL2 || 4 Mhz
|}

=== Unbekanntes IC1 ===

Hier mal der Dekodierte Barcode des noch Unbekannten IC1.
Der decodierte Text ist:

25SLEATM 8R4222 084420179+2P00+PLCMC

[[Bild:AccuCheckDecodedMatrixCode.png|500px]]

=== Pinbelegung Mega168 ===

Wie oben mittles Messungen ermittelt. Ohne Garantie auf Vollständigkeit und Richtigkeit.

{| class="wikitable"
|-
! Pin || Port || Funktionen || Verwendung
|-
| 1 || PD3 || (PCINT19/OC2B/INT1) || Taste Mitte (S2)
|-
| 2 || PD4 || (PCINT20/XCK/T0) || Display SCLK (XCLK)
|-
| 3 || GND || || GND
|-
| 4 || VCC || || VCC
|-
| 5 || GND || || GND
|-
| 6 || VCC || || VCC
|-
| 7 || PB6 || (PCINT6/XTAL1/TOSC1) || An 32,768(?)kHz Oszillator. Taktsignal auch ohne ASIC vorhanden.
|-
| 8 || PB7 || (PCINT7/XTAL2/TOSC2) || enable 3.3V step-up
|-
| 9 || PD5 || (PCINT21/OC0B/T1) || VCC enable (12 V step-up)
|-
| 10 || PD6 || (PCINT22/OC0A/AIN0) ||
|-
| 11 || PD7 || (PCINT23/AIN1) ||
|-
| 12 || PB0 || (PCINT0/CLKO/ICP1) || an Transistor T1 (schaltet 12 V über 100 Ohm gegen GND als Grundlast bzw. zum Entladen)
|-
| 13 || PB1 || (PCINT1/OC1A) || Display /CS
|-
| 14 || PB2 || (PCINT2/SS/OC1B) || Anschluss des [[#Buzzer|Buzzers]] möglich
|-
| 15 || PB3 || (PCINT3/OC2A/MOSI) || ISP MOSI
|-
| 16 || PB4 || (PCINT4/MISO) || ISP MISO
|-
| 17 || PB5 || (SCK/PCINT5) || ISP SCK
|-
| 18 || AVCC || || mit Beschaltung an VCC
|-
| 19 || ADC6 || || Batteriespannung (3.3Volt StepUp dafür abschalten)
|-
| 20 || AREF || || mit Beschaltung an VCC (REFS1=0, REFS0=1)
|-
| 21 || GND || || GND
|-
| 22 || ADC7 || || Ausgang des 3,3V step-up über Spannungsteiler. Mit Step-Up wird 707 gemessen, ohne ca. 637.
|-
| 23 || PC0 || (ADC0/PCINT8) || Batteriespannung über Spannungsteiler, bei voller Batterie ca. 638
|-
| 24 || PC1 || (ADC1/PCINT9) || Display D/C
|-
| 25 || PC2 || (ADC2/PCINT10) || Display RESET
|-
| 26 || PC3 || (ADC3/PCINT11) ||
|-
| 27 || PC4 || (ADC4/SDA/PCINT12) || Taste Links (S1)
|-
| 28 || PC5 || (ADC5/SCL/PCINT13) || Taste rechts (S3)
|-
| 29 || PC6 || (RESET/PCINT14) || ISP Reset
|-
| 30 || PD0 || (RXD/PCINT16) ||
|-
| 31 || PD1 || (TXD/PCINT17) || Display SDIN. Achtung, ist auch TxD (UART-SPI möglich)
|-
| 32 || PD2 || (INT0/PCINT18) ||
|}

=== IC9 (IR) ===

Ist wohl ein TFDU2201 ([http://www.vishay.com/docs/82539/tfdu2201.pdf Datenblatt]).

[[Bild:Accu chek combo ir.png|320px]] [[Bild:AccuCheckIRDA(TFDU2201)Pinout.png|320px]]

=== Buzzer ===

Ist ein Piezo Schallwandler. Es ist möglich eine ihn mit PB2 des [[#Pinbelegung Mega168|mega168]] zu verbinden. Im Bereich "Kurzzeitwecker mit 7-Segment-Anzeige" auf adriano6's [[#Websites|Webseite]].

==== AVRdude ====
Auslesen der Fuses
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -v

avrdude: Device signature = 0x1e940b
avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: safemode: lfuse reads as 42
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 1

==== Flashen mit AVRdude ====
Da die IDs von ATmega168 und ATmega168A abweichen, muss die Option -F mit avrdude verwendet werden.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -u -U flash:w:Oled-Demo.hex

==== Fuses mit AVRdude ====
Der ATmega168A hat die Fuse CLKDIV8 eingeschaltet.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -U lfuse:w:0xC2:m

=== Display ===
[[Bild:display.JPG|300px]]

Das Display basiert auf OLED - Technologie und besitzt eine Auflösung von 102×80 Pixel, von denen jedes 16 Helligkeitsstufen darstellen kann.
Displaycontroller ist SSD1325.

Detailierte Informationen zum Display gibts auf adriano6's [[#Websites|Webseite ]]

==== Inbetriebnahme auf dem Board ====

Es ist möglich das Display auf dem Board in Betrieb zu nehmen, wenn alle Komponenten bis auf:
R1, R43, R44, R45, R46, C24, C38, C39, C44, C45, C46, L2, IC6 und D1
entfernt werden.
T1 und R11 sind vermutlich als Grundlast zum Start des 12 V Step-up und zum Entladen des OLED beim Abschalten.
Die folgende Tabelle enthält die Pads des Atmega168 Footprints und die entsprechenden Pins am Display.

{| class="wikitable"
|-
! Pad am Atmega168 || Pin am Display
|-
| PD1 || SDIN
|-
| PD4 || SCLK
|-
| PC1 || D/C
|-
| PC2 || RESET
|-
| PB1 || /CS
|}

=== Grafikbeschleunigung mit dem SSD1325 ===

Mit dem im SSD1325 vorhandenen Befehlen Copy, DrawRectangle und HorizontalScolling kann man ein paar nette Animationen machen, bzw. dem ATmega eine Menge Arbeit abnehmen (Details zu Controller und Display stehen im Datenblatt und [[#Websites|hier ]]).

Der Displaycontroller verfügt über ein 64x80 Bytes großes RAM, von dem das Display aber nur 51x80 Bytes (102x80 Pixel) darstellt, beginnend von Spalte 7 bis Spalte 57:

{| class="wikitable" style="text-align:center; width:60em"
! colspan=2 style="width:6em" | Col0
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col6
! colspan=2 style="width:6em; background:#c0c0c0" | Col7
! colspan=2 style="width:6em; background:#c0c0c0" | ...
! colspan=2 style="width:6em; background:#c0c0c0" | Col56
! colspan=2 style="width:6em; background:#c0c0c0" | Col57
! colspan=2 style="width:6em" | Col58
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col63
|- style="width:3em"
| D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0
|}

Schaltet man im Controller nun Wraparound für das Scrolling- und Copy-Commando ein, hängen Ende und Anfang der jeweiligen Zeile hintereinander:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col0 || style="width:6em" | ... || style="width:6em" | Col6
|}

Aus Sicht des Copy- und DrawRectangle-Kommandos kann man jetzt folgendermaßen auf den nicht sichtbaren Bereich des Display-RAM zugreifen:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col64 || style="width:6em" | ... || style="width:6em" | Col70
|}

Um Daten in diesen Bereich zu bekommen, könnte man einen entsprechenden Bildschirmausschnitt definieren und die Daten einfach sequentiell da rein schreiben. Praktisch hat das aber nicht einwandfrei funktioniert. Besser schreibt man zuerst in den sichtbaren Bereich und kopiert dann den Block in den Bereich ab Spalte 58.
Statt jetzt Grafiken byteweise über die Schnittstelle in das RAM zu schreiben braucht man sie nur noch durch den Controller vom unsichtbaren Bereich (maximal 26x80 Pixel) in den sichtbaren kopieren zu lassen.

Ich habe [http://www.mikrocontroller.net/topic/109648#1419368 eine kleine Demo] geschrieben, die mit dem Copy-Befehl 8 Sprites (sich drehende Bälle) fliegen läßt und bei jeder Randberührung eines Sprites einen Zähler erhöht. Im Hintergrund laufen je eine horizontale und vertikale Linie (Rechteck) durch.
Das Ganze verbraucht mit Software-SPI ca. 20% Rechenzeit des ATmega, bei Hardware-SPI sind es ca. 6%.

Um auch in horizontaler Richtung eine pixelgenaue Bewegung zu erreichen, erstellt man für jedes Sprite zwei um jeweils ein Pixel verschobene Versionen, und kopiert diese nacheinander auf die selbe Spaltenposition.

Das Timing ist etwas kritisch, da vom Controller keine Rückmeldung möglich ist, man muß ggf. die Wartezeit nach einem Kommando versuchsweise ermitteln. Schickt man das nächste Kommando zu früh ab, wird das gerade laufende abgebrochen, was nicht immer schön aussieht oder sogar den Controller zum Abstürzen bringt.

Bei Ansteuerung mit Hardware-SPI muß man außerdem ca. 2us warten, bevor das CS-Signal deaktiviert werden kann.

=== Spektrometer ===
[[Bild:Accu-Check_CompactPlus_BZ_Sensor.jpg|200px]]

Im Grunde genommen, handelt es sich um eine Reflexlichtschranke mit zwei roten LEDs, einer vermutlich infraroten LED, sowie einer Fotodiode.

[[Bild:Accu-Check_CompactPlus_Photometer.jpg|200px]]

== Programme ==
=== µC ===
* GPS http://www.mikrocontroller.net/topic/109648#1385554
** http://www.mikrocontroller.net/topic/109648#1397017

* Grafikdemo: http://www.mikrocontroller.net/topic/109648#1419368
** Video: http://vimeo.com/6609124

* Kurzzeitwecker: http://www.mikrocontroller.net/topic/109648#1412841
** http://www.mikrocontroller.net/topic/109648#1427502

* serielle Displaysteuerung: http://www.mikrocontroller.net/topic/109648#1487494

=== PC ===
* [http://www.mikrocontroller.net/topic/109648#1352701 gibt als Header gespeicherte Bilder auf std aus]
* [http://www.mikrocontroller.net/topic/109648#1353067 Erweiterter (ungetesteter) Konvertierer für Bilder in Format für Display]

== Links ==

=== Technische Dokumente ===
* [http://www.crystalfontz.com/controllers/SSD1325_2.1.pdf Datenblatt für Display-Controller]
* [http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega168PA AVR Produktseite ATmega168PA mit Datasheets ]
* [http://www.freshpatents.com/Device-for-analysis-of-a-sample-on-a-test-element-dt20081113ptan20080277280.php Patentschrift zu Gerät ]

=== Websites ===
* [http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html Oled-Recycling Seite von adriano6]

=== Diskussions Threads ===

* [http://www.mikrocontroller.net/topic/109648 Hauptdiskussionsthread im Mikrocontrollernet ]
* [http://bascom-forum.de/index.php/topic,2754.0.html Umsetzung in Bascom (wer's mag) im Bascom-Forum]
* [http://www.mikrocontroller.net/topic/143806 Vorschlag für Display-Adapter-Platine]

[[Category:AVR-Projekte]]

Datei:AccuCheckIRDA(TFDU2201)Pinout.png

2010-01-20T23:15:38Z

Muebau:

Compact Plus Blutzuckermessgerät-Hardware

2010-01-16T12:47:41Z

Muebau: /* Komponenten */

== Hardware ==
== Übersicht Hardware ==
* OLED Display 102×80 Pixel incl. 16 Helligkeitsstufen pro Pixel / SSD1325 /43x36 mm gesamt
* Atmega168PA
* DC/DC-Wandler (Regler und Drosseln)
* IR-Sender/Empfänger
* 3 Tasten (4 wenn man den Schließer der Klappe mitzählt)
* 2 Elektromotoren
* kleine Lichtschranke/Barcodescanner
* kleines Spektrometer (2 * LEDs rot, IR(?)-LED, Fotodiode)
* Betriebsspannung 3V (2*AAA)
* SMD Piezo-Summer

== Gerät als Ganzes ==
[[Bild:compact_plus.jpg|400px]]

Das unzerlegte Gerät. Ganz links ist die Stechhilfe.

== Gerät zerlegen ==
Das Gehäuse besteht aus drei ineinander einrastenden Teilen (keine Schrauben). Relativ schadlose Demontage durch vorsichtiges Aufhebeln möglich.
Erst das Seitenteil (links) ganz oben und 2 cm von unten ausrasten.
Von unten anfangen die Gehäusehälften zu lösen, bis man sie über die Oberkante aufklappen kann.

Die Platine selbst ist mit 2 Schrauben und ein paar Clipsen befestigt. Vor dem Entnehmen ist der untere Folienstecker abzuziehen.

[[Bild:compact_plus_open.jpg|250px]]

Das geöffnete Gerät ohne Platine.
Gut zu erkennen (im unverkleinertem Bild) sind die zwei Motoren und die Mechanik die dafür sorgen, dass die Aufbewarungstrommel gedreht und die Messstreifen herausgefahren werden können.

== Komponenten ==

=== Board ===
Hochauflösende Scans beider Platinenseiten.
Die Bauteile sind nach bestem Wissen und Gewissen bezeichnet (für spätere Schaltpläne). Speziell bei den Widerständen und Kondensatoren ist noch eine Kontrolle notwendig. Ich habe dabei alle blauen und schwarzen Bauteile als Widerstände und alles graue und weiße als Kondensatoren gedeutet.

Änderungen bitte mir (Netzwanze) melden.

[[Bild:AccuCheckL1.jpg|300px]][[Bild:AccuCheckL6.jpg|300px]]

=== Stromversorgung ===
Die zwei AAA Zellen sind in Serie geschaltet.
Ein Schaltregler [IC7] erzeugt daraus 3.3 V.
Ein Schaltregler [IC6] erzeugt daraus 12 V für das OLED.

=== Komponenten ===

Nach bestem Wissen und Gewissen bestimmt durch Kombination aus Schaltplänen und Messungen. Bei Komponenten mit "(?)" bin ich mir nicht sicher.

{| class="wikitable"
|-
! Bauteil || Größe
|-
| R1 || 820 kOhm
|-
| R35 || Temperaturfühler; NTC 10 kOhm bei 20°C (?)
|-
| R43 || 100 kOhm
|-
| R44 || 100 Ohm
|-
| R45 || 39 kOhm
|-
| R46 || 1 MOhm
|-
| C24 || 22 uF (?)
|-
| C38 || 4,7 uF
|-
| C39 || 4,7 uF
|-
| C44 || 100 nF
|-
| C45 || 470 nF (?)
|-
| C46 || 10 pF
|-
| L2 || 100 uH
|-
| IC1 || ASIC
|-
| IC2 || ATmega168A
|-
| IC3 || Atmel AT25640A SPI EEPROM
|-
| IC4 || NC7NP14 ULP Triple Inverter with Schmitt Trigger Input
|-
| IC5 || 74LVC1G86GV (Markierung V68)
|-
| IC6 || TPS61080 Step-up 12 V
|-
| IC7 || AS1329, Step-up 3,3 V
|-
| IC8 || BIG 01 A825MFL ????
|-
| IC9 || [[#IC9 (IR)|IR (TFDU2201)]]
|-
| Buzzer || [[#Buzzer|Piezo Schallwandler]]
|-
| D1 || BAT54W
|-
| XTAL1 || 32 Khz
|-
| XTAL2 || 4 Mhz
|}

=== Unbekanntes IC1 ===

Hier mal der Dekodierte Barcode des noch Unbekannten IC1.
Der decodierte Text ist:

25SLEATM 8R4222 084420179+2P00+PLCMC

[[Bild:AccuCheckDecodedMatrixCode.png|500px]]

=== Pinbelegung Mega168 ===

Wie oben mittles Messungen ermittelt. Ohne Garantie auf Vollständigkeit und Richtigkeit.

{| class="wikitable"
|-
! Pin || Port || Funktionen || Verwendung
|-
| 1 || PD3 || (PCINT19/OC2B/INT1) || Taste Mitte (S2)
|-
| 2 || PD4 || (PCINT20/XCK/T0) || Display SCLK (XCLK)
|-
| 3 || GND || || GND
|-
| 4 || VCC || || VCC
|-
| 5 || GND || || GND
|-
| 6 || VCC || || VCC
|-
| 7 || PB6 || (PCINT6/XTAL1/TOSC1) || An 32,768(?)kHz Oszillator. Taktsignal auch ohne ASIC vorhanden.
|-
| 8 || PB7 || (PCINT7/XTAL2/TOSC2) || enable 3.3V step-up
|-
| 9 || PD5 || (PCINT21/OC0B/T1) || VCC enable (12 V step-up)
|-
| 10 || PD6 || (PCINT22/OC0A/AIN0) ||
|-
| 11 || PD7 || (PCINT23/AIN1) ||
|-
| 12 || PB0 || (PCINT0/CLKO/ICP1) || an Transistor T1 (schaltet 12 V über 100 Ohm gegen GND als Grundlast bzw. zum Entladen)
|-
| 13 || PB1 || (PCINT1/OC1A) || Display /CS
|-
| 14 || PB2 || (PCINT2/SS/OC1B) || Anschluss des [[#Buzzer|Buzzers]] möglich
|-
| 15 || PB3 || (PCINT3/OC2A/MOSI) || ISP MOSI
|-
| 16 || PB4 || (PCINT4/MISO) || ISP MISO
|-
| 17 || PB5 || (SCK/PCINT5) || ISP SCK
|-
| 18 || AVCC || || mit Beschaltung an VCC
|-
| 19 || ADC6 || || Batteriespannung (3.3Volt StepUp dafür abschalten)
|-
| 20 || AREF || || mit Beschaltung an VCC (REFS1=0, REFS0=1)
|-
| 21 || GND || || GND
|-
| 22 || ADC7 || || Ausgang des 3,3V step-up über Spannungsteiler. Mit Step-Up wird 707 gemessen, ohne ca. 637.
|-
| 23 || PC0 || (ADC0/PCINT8) || Batteriespannung über Spannungsteiler, bei voller Batterie ca. 638
|-
| 24 || PC1 || (ADC1/PCINT9) || Display D/C
|-
| 25 || PC2 || (ADC2/PCINT10) || Display RESET
|-
| 26 || PC3 || (ADC3/PCINT11) ||
|-
| 27 || PC4 || (ADC4/SDA/PCINT12) || Taste Links (S1)
|-
| 28 || PC5 || (ADC5/SCL/PCINT13) || Taste rechts (S3)
|-
| 29 || PC6 || (RESET/PCINT14) || ISP Reset
|-
| 30 || PD0 || (RXD/PCINT16) ||
|-
| 31 || PD1 || (TXD/PCINT17) || Display SDIN. Achtung, ist auch TxD (UART-SPI möglich)
|-
| 32 || PD2 || (INT0/PCINT18) ||
|}

=== IC9 (IR) ===

Ist wohl ein TFDU2201 ([http://www.vishay.com/docs/82539/tfdu2201.pdf Datenblatt]).

[[Bild:Accu chek combo ir.png|320px]]

=== Buzzer ===

Ist ein Piezo Schallwandler. Es ist möglich eine ihn mit PB2 des [[#Pinbelegung Mega168|mega168]] zu verbinden. Im Bereich "Kurzzeitwecker mit 7-Segment-Anzeige" auf adriano6's [[#Websites|Webseite]].

==== AVRdude ====
Auslesen der Fuses
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -v

avrdude: Device signature = 0x1e940b
avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: safemode: lfuse reads as 42
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 1

==== Flashen mit AVRdude ====
Da die IDs von ATmega168 und ATmega168A abweichen, muss die Option -F mit avrdude verwendet werden.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -u -U flash:w:Oled-Demo.hex

==== Fuses mit AVRdude ====
Der ATmega168A hat die Fuse CLKDIV8 eingeschaltet.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -U lfuse:w:0xC2:m

=== Display ===
[[Bild:display.JPG|300px]]

Das Display basiert auf OLED - Technologie und besitzt eine Auflösung von 102×80 Pixel, von denen jedes 16 Helligkeitsstufen darstellen kann.
Displaycontroller ist SSD1325.

Detailierte Informationen zum Display gibts auf adriano6's [[#Websites|Webseite ]]

==== Inbetriebnahme auf dem Board ====

Es ist möglich das Display auf dem Board in Betrieb zu nehmen, wenn alle Komponenten bis auf:
R1, R43, R44, R45, R46, C24, C38, C39, C44, C45, C46, L2, IC6 und D1
entfernt werden.
T1 und R11 sind vermutlich als Grundlast zum Start des 12 V Step-up und zum Entladen des OLED beim Abschalten.
Die folgende Tabelle enthält die Pads des Atmega168 Footprints und die entsprechenden Pins am Display.

{| class="wikitable"
|-
! Pad am Atmega168 || Pin am Display
|-
| PD1 || SDIN
|-
| PD4 || SCLK
|-
| PC1 || D/C
|-
| PC2 || RESET
|-
| PB1 || /CS
|}

=== Grafikbeschleunigung mit dem SSD1325 ===

Mit dem im SSD1325 vorhandenen Befehlen Copy, DrawRectangle und HorizontalScolling kann man ein paar nette Animationen machen, bzw. dem ATmega eine Menge Arbeit abnehmen (Details zu Controller und Display stehen im Datenblatt und [[#Websites|hier ]]).

Der Displaycontroller verfügt über ein 64x80 Bytes großes RAM, von dem das Display aber nur 51x80 Bytes (102x80 Pixel) darstellt, beginnend von Spalte 7 bis Spalte 57:

{| class="wikitable" style="text-align:center; width:60em"
! colspan=2 style="width:6em" | Col0
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col6
! colspan=2 style="width:6em; background:#c0c0c0" | Col7
! colspan=2 style="width:6em; background:#c0c0c0" | ...
! colspan=2 style="width:6em; background:#c0c0c0" | Col56
! colspan=2 style="width:6em; background:#c0c0c0" | Col57
! colspan=2 style="width:6em" | Col58
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col63
|- style="width:3em"
| D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0
|}

Schaltet man im Controller nun Wraparound für das Scrolling- und Copy-Commando ein, hängen Ende und Anfang der jeweiligen Zeile hintereinander:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col0 || style="width:6em" | ... || style="width:6em" | Col6
|}

Aus Sicht des Copy- und DrawRectangle-Kommandos kann man jetzt folgendermaßen auf den nicht sichtbaren Bereich des Display-RAM zugreifen:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col64 || style="width:6em" | ... || style="width:6em" | Col70
|}

Um Daten in diesen Bereich zu bekommen, könnte man einen entsprechenden Bildschirmausschnitt definieren und die Daten einfach sequentiell da rein schreiben. Praktisch hat das aber nicht einwandfrei funktioniert. Besser schreibt man zuerst in den sichtbaren Bereich und kopiert dann den Block in den Bereich ab Spalte 58.
Statt jetzt Grafiken byteweise über die Schnittstelle in das RAM zu schreiben braucht man sie nur noch durch den Controller vom unsichtbaren Bereich (maximal 26x80 Pixel) in den sichtbaren kopieren zu lassen.

Ich habe [http://www.mikrocontroller.net/topic/109648#1419368 eine kleine Demo] geschrieben, die mit dem Copy-Befehl 8 Sprites (sich drehende Bälle) fliegen läßt und bei jeder Randberührung eines Sprites einen Zähler erhöht. Im Hintergrund laufen je eine horizontale und vertikale Linie (Rechteck) durch.
Das Ganze verbraucht mit Software-SPI ca. 20% Rechenzeit des ATmega, bei Hardware-SPI sind es ca. 6%.

Um auch in horizontaler Richtung eine pixelgenaue Bewegung zu erreichen, erstellt man für jedes Sprite zwei um jeweils ein Pixel verschobene Versionen, und kopiert diese nacheinander auf die selbe Spaltenposition.

Das Timing ist etwas kritisch, da vom Controller keine Rückmeldung möglich ist, man muß ggf. die Wartezeit nach einem Kommando versuchsweise ermitteln. Schickt man das nächste Kommando zu früh ab, wird das gerade laufende abgebrochen, was nicht immer schön aussieht oder sogar den Controller zum Abstürzen bringt.

Bei Ansteuerung mit Hardware-SPI muß man außerdem ca. 2us warten, bevor das CS-Signal deaktiviert werden kann.

=== Spektrometer ===
[[Bild:Accu-Check_CompactPlus_BZ_Sensor.jpg|200px]]

Im Grunde genommen, handelt es sich um eine Reflexlichtschranke mit zwei roten LEDs, einer vermutlich infraroten LED, sowie einer Fotodiode.

[[Bild:Accu-Check_CompactPlus_Photometer.jpg|200px]]

== Programme ==
=== µC ===
* GPS http://www.mikrocontroller.net/topic/109648#1385554
** http://www.mikrocontroller.net/topic/109648#1397017

* Grafikdemo: http://www.mikrocontroller.net/topic/109648#1419368
** Video: http://vimeo.com/6609124

* Kurzzeitwecker: http://www.mikrocontroller.net/topic/109648#1412841
** http://www.mikrocontroller.net/topic/109648#1427502

* serielle Displaysteuerung: http://www.mikrocontroller.net/topic/109648#1487494

=== PC ===
* [http://www.mikrocontroller.net/topic/109648#1352701 gibt als Header gespeicherte Bilder auf std aus]
* [http://www.mikrocontroller.net/topic/109648#1353067 Erweiterter (ungetesteter) Konvertierer für Bilder in Format für Display]

== Links ==

=== Technische Dokumente ===
* [http://www.crystalfontz.com/controllers/SSD1325_2.1.pdf Datenblatt für Display-Controller]
* [http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega168PA AVR Produktseite ATmega168PA mit Datasheets ]
* [http://www.freshpatents.com/Device-for-analysis-of-a-sample-on-a-test-element-dt20081113ptan20080277280.php Patentschrift zu Gerät ]

=== Websites ===
* [http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html Oled-Recycling Seite von adriano6]

=== Diskussions Threads ===

* [http://www.mikrocontroller.net/topic/109648 Hauptdiskussionsthread im Mikrocontrollernet ]
* [http://bascom-forum.de/index.php/topic,2754.0.html Umsetzung in Bascom (wer's mag) im Bascom-Forum]
* [http://www.mikrocontroller.net/topic/143806 Vorschlag für Display-Adapter-Platine]

[[Category:AVR-Projekte]]

Compact Plus Blutzuckermessgerät-Hardware

2010-01-16T12:06:39Z

Muebau: /* Komponenten */

== Hardware ==
== Übersicht Hardware ==
* OLED Display 102×80 Pixel incl. 16 Helligkeitsstufen pro Pixel / SSD1325 /43x36 mm gesamt
* Atmega168PA
* DC/DC-Wandler (Regler und Drosseln)
* IR-Sender/Empfänger
* 3 Tasten (4 wenn man den Schließer der Klappe mitzählt)
* 2 Elektromotoren
* kleine Lichtschranke/Barcodescanner
* kleines Spektrometer (2 * LEDs rot, IR(?)-LED, Fotodiode)
* Betriebsspannung 3V (2*AAA)
* SMD Piezo-Summer

== Gerät als Ganzes ==
[[Bild:compact_plus.jpg|400px]]

Das unzerlegte Gerät. Ganz links ist die Stechhilfe.

== Gerät zerlegen ==
Das Gehäuse besteht aus drei ineinander einrastenden Teilen (keine Schrauben). Relativ schadlose Demontage durch vorsichtiges Aufhebeln möglich.
Erst das Seitenteil (links) ganz oben und 2 cm von unten ausrasten.
Von unten anfangen die Gehäusehälften zu lösen, bis man sie über die Oberkante aufklappen kann.

Die Platine selbst ist mit 2 Schrauben und ein paar Clipsen befestigt. Vor dem Entnehmen ist der untere Folienstecker abzuziehen.

[[Bild:compact_plus_open.jpg|250px]]

Das geöffnete Gerät ohne Platine.
Gut zu erkennen (im unverkleinertem Bild) sind die zwei Motoren und die Mechanik die dafür sorgen, dass die Aufbewarungstrommel gedreht und die Messstreifen herausgefahren werden können.

== Komponenten ==

=== Board ===
Hochauflösende Scans beider Platinenseiten.
Die Bauteile sind nach bestem Wissen und Gewissen bezeichnet (für spätere Schaltpläne). Speziell bei den Widerständen und Kondensatoren ist noch eine Kontrolle notwendig. Ich habe dabei alle blauen und schwarzen Bauteile als Widerstände und alles graue und weiße als Kondensatoren gedeutet.

Änderungen bitte mir (Netzwanze) melden.

[[Bild:AccuCheckL1.jpg|300px]][[Bild:AccuCheckL6.jpg|300px]]

=== Stromversorgung ===
Die zwei AAA Zellen sind in Serie geschaltet.
Ein Schaltregler [IC7] erzeugt daraus 3.3 V.
Ein Schaltregler [IC6] erzeugt daraus 12 V für das OLED.

=== Komponenten ===

Nach bestem Wissen und Gewissen bestimmt durch Kombination aus Schaltplänen und Messungen. Bei Komponenten mit "(?)" bin ich mir nicht sicher.

{| class="wikitable"
|-
! Bauteil || Größe
|-
| R1 || 820 kOhm
|-
| R35 || Temperaturfühler; NTC 10 kOhm bei 20°C (?)
|-
| R43 || 100 kOhm
|-
| R44 || 100 Ohm
|-
| R45 || 39 kOhm
|-
| R46 || 1 MOhm
|-
| C24 || 22 uF (?)
|-
| C38 || 4,7 uF
|-
| C39 || 4,7 uF
|-
| C44 || 100 nF
|-
| C45 || 470 nF (?)
|-
| C46 || 10 pF
|-
| L2 || 100 uH
|-
| IC1 || ASIC
|-
| IC2 || ATmega168A
|-
| IC3 || Atmel AT25640A SPI EEPROM
|-
| IC4 || NC7NP14 ULP Triple Inverter with Schmitt Trigger Input
|-
| IC5 || 74LVC1G86GV (Markierung V68)
|-
| IC6 || TPS61080 Step-up 12 V
|-
| IC7 || AS1329, Step-up 3,3 V
|-
| IC8 || BIG 01 A825MFL ????
|-
| IC9 || [[#IC9 (IR)|IR (TFDU2201)]]
|-
| D1 || BAT54W
|-
| XTAL1 || 32 Khz
|-
| XTAL2 || 4 Mhz
|}

=== Unbekanntes IC1 ===

Hier mal der Dekodierte Barcode des noch Unbekannten IC1.
Der decodierte Text ist:

25SLEATM 8R4222 084420179+2P00+PLCMC

[[Bild:AccuCheckDecodedMatrixCode.png|500px]]

=== Pinbelegung Mega168 ===

Wie oben mittles Messungen ermittelt. Ohne Garantie auf Vollständigkeit und Richtigkeit.

{| class="wikitable"
|-
! Pin || Port || Funktionen || Verwendung
|-
| 1 || PD3 || (PCINT19/OC2B/INT1) || Taste Mitte (S2)
|-
| 2 || PD4 || (PCINT20/XCK/T0) || Display SCLK (XCLK)
|-
| 3 || GND || || GND
|-
| 4 || VCC || || VCC
|-
| 5 || GND || || GND
|-
| 6 || VCC || || VCC
|-
| 7 || PB6 || (PCINT6/XTAL1/TOSC1) || An 32,768(?)kHz Oszillator. Taktsignal auch ohne ASIC vorhanden.
|-
| 8 || PB7 || (PCINT7/XTAL2/TOSC2) || enable 3.3V step-up
|-
| 9 || PD5 || (PCINT21/OC0B/T1) || VCC enable (12 V step-up)
|-
| 10 || PD6 || (PCINT22/OC0A/AIN0) ||
|-
| 11 || PD7 || (PCINT23/AIN1) ||
|-
| 12 || PB0 || (PCINT0/CLKO/ICP1) || an Transistor T1 (schaltet 12 V über 100 Ohm gegen GND als Grundlast bzw. zum Entladen)
|-
| 13 || PB1 || (PCINT1/OC1A) || Display /CS
|-
| 14 || PB2 || (PCINT2/SS/OC1B) ||
|-
| 15 || PB3 || (PCINT3/OC2A/MOSI) || ISP MOSI
|-
| 16 || PB4 || (PCINT4/MISO) || ISP MISO
|-
| 17 || PB5 || (SCK/PCINT5) || ISP SCK
|-
| 18 || AVCC || || mit Beschaltung an VCC
|-
| 19 || ADC6 || || Batteriespannung (3.3Volt StepUp dafür abschalten)
|-
| 20 || AREF || || mit Beschaltung an VCC (REFS1=0, REFS0=1)
|-
| 21 || GND || || GND
|-
| 22 || ADC7 || || Ausgang des 3,3V step-up über Spannungsteiler. Mit Step-Up wird 707 gemessen, ohne ca. 637.
|-
| 23 || PC0 || (ADC0/PCINT8) || Batteriespannung über Spannungsteiler, bei voller Batterie ca. 638
|-
| 24 || PC1 || (ADC1/PCINT9) || Display D/C
|-
| 25 || PC2 || (ADC2/PCINT10) || Display RESET
|-
| 26 || PC3 || (ADC3/PCINT11) ||
|-
| 27 || PC4 || (ADC4/SDA/PCINT12) || Taste Links (S1)
|-
| 28 || PC5 || (ADC5/SCL/PCINT13) || Taste rechts (S3)
|-
| 29 || PC6 || (RESET/PCINT14) || ISP Reset
|-
| 30 || PD0 || (RXD/PCINT16) ||
|-
| 31 || PD1 || (TXD/PCINT17) || Display SDIN. Achtung, ist auch TxD (UART-SPI möglich)
|-
| 32 || PD2 || (INT0/PCINT18) ||
|}

=== IC9 (IR) ===

Ist wohl ein TFDU2201 ([http://www.vishay.com/docs/82539/tfdu2201.pdf Datenblatt]).

[[Bild:Accu chek combo ir.png|320px]]

==== AVRdude ====
Auslesen der Fuses
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -v

avrdude: Device signature = 0x1e940b
avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: safemode: lfuse reads as 42
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 1

==== Flashen mit AVRdude ====
Da die IDs von ATmega168 und ATmega168A abweichen, muss die Option -F mit avrdude verwendet werden.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -u -U flash:w:Oled-Demo.hex

==== Fuses mit AVRdude ====
Der ATmega168A hat die Fuse CLKDIV8 eingeschaltet.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -U lfuse:w:0xC2:m

=== Display ===
[[Bild:display.JPG|300px]]

Das Display basiert auf OLED - Technologie und besitzt eine Auflösung von 102×80 Pixel, von denen jedes 16 Helligkeitsstufen darstellen kann.
Displaycontroller ist SSD1325.

Detailierte Informationen zum Display gibts auf adriano6's [[#Websites|Webseite ]]

==== Inbetriebnahme auf dem Board ====

Es ist möglich das Display auf dem Board in Betrieb zu nehmen, wenn alle Komponenten bis auf:
R1, R43, R44, R45, R46, C24, C38, C39, C44, C45, C46, L2, IC6 und D1
entfernt werden.
T1 und R11 sind vermutlich als Grundlast zum Start des 12 V Step-up und zum Entladen des OLED beim Abschalten.
Die folgende Tabelle enthält die Pads des Atmega168 Footprints und die entsprechenden Pins am Display.

{| class="wikitable"
|-
! Pad am Atmega168 || Pin am Display
|-
| PD1 || SDIN
|-
| PD4 || SCLK
|-
| PC1 || D/C
|-
| PC2 || RESET
|-
| PB1 || /CS
|}

=== Grafikbeschleunigung mit dem SSD1325 ===

Mit dem im SSD1325 vorhandenen Befehlen Copy, DrawRectangle und HorizontalScolling kann man ein paar nette Animationen machen, bzw. dem ATmega eine Menge Arbeit abnehmen (Details zu Controller und Display stehen im Datenblatt und [[#Websites|hier ]]).

Der Displaycontroller verfügt über ein 64x80 Bytes großes RAM, von dem das Display aber nur 51x80 Bytes (102x80 Pixel) darstellt, beginnend von Spalte 7 bis Spalte 57:

{| class="wikitable" style="text-align:center; width:60em"
! colspan=2 style="width:6em" | Col0
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col6
! colspan=2 style="width:6em; background:#c0c0c0" | Col7
! colspan=2 style="width:6em; background:#c0c0c0" | ...
! colspan=2 style="width:6em; background:#c0c0c0" | Col56
! colspan=2 style="width:6em; background:#c0c0c0" | Col57
! colspan=2 style="width:6em" | Col58
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col63
|- style="width:3em"
| D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0
|}

Schaltet man im Controller nun Wraparound für das Scrolling- und Copy-Commando ein, hängen Ende und Anfang der jeweiligen Zeile hintereinander:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col0 || style="width:6em" | ... || style="width:6em" | Col6
|}

Aus Sicht des Copy- und DrawRectangle-Kommandos kann man jetzt folgendermaßen auf den nicht sichtbaren Bereich des Display-RAM zugreifen:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col64 || style="width:6em" | ... || style="width:6em" | Col70
|}

Um Daten in diesen Bereich zu bekommen, könnte man einen entsprechenden Bildschirmausschnitt definieren und die Daten einfach sequentiell da rein schreiben. Praktisch hat das aber nicht einwandfrei funktioniert. Besser schreibt man zuerst in den sichtbaren Bereich und kopiert dann den Block in den Bereich ab Spalte 58.
Statt jetzt Grafiken byteweise über die Schnittstelle in das RAM zu schreiben braucht man sie nur noch durch den Controller vom unsichtbaren Bereich (maximal 26x80 Pixel) in den sichtbaren kopieren zu lassen.

Ich habe [http://www.mikrocontroller.net/topic/109648#1419368 eine kleine Demo] geschrieben, die mit dem Copy-Befehl 8 Sprites (sich drehende Bälle) fliegen läßt und bei jeder Randberührung eines Sprites einen Zähler erhöht. Im Hintergrund laufen je eine horizontale und vertikale Linie (Rechteck) durch.
Das Ganze verbraucht mit Software-SPI ca. 20% Rechenzeit des ATmega, bei Hardware-SPI sind es ca. 6%.

Um auch in horizontaler Richtung eine pixelgenaue Bewegung zu erreichen, erstellt man für jedes Sprite zwei um jeweils ein Pixel verschobene Versionen, und kopiert diese nacheinander auf die selbe Spaltenposition.

Das Timing ist etwas kritisch, da vom Controller keine Rückmeldung möglich ist, man muß ggf. die Wartezeit nach einem Kommando versuchsweise ermitteln. Schickt man das nächste Kommando zu früh ab, wird das gerade laufende abgebrochen, was nicht immer schön aussieht oder sogar den Controller zum Abstürzen bringt.

Bei Ansteuerung mit Hardware-SPI muß man außerdem ca. 2us warten, bevor das CS-Signal deaktiviert werden kann.

=== Spektrometer ===
[[Bild:Accu-Check_CompactPlus_BZ_Sensor.jpg|200px]]

Im Grunde genommen, handelt es sich um eine Reflexlichtschranke mit zwei roten LEDs, einer vermutlich infraroten LED, sowie einer Fotodiode.

[[Bild:Accu-Check_CompactPlus_Photometer.jpg|200px]]

== Programme ==
=== µC ===
* GPS http://www.mikrocontroller.net/topic/109648#1385554
** http://www.mikrocontroller.net/topic/109648#1397017

* Grafikdemo: http://www.mikrocontroller.net/topic/109648#1419368
** Video: http://vimeo.com/6609124

* Kurzzeitwecker: http://www.mikrocontroller.net/topic/109648#1412841
** http://www.mikrocontroller.net/topic/109648#1427502

* serielle Displaysteuerung: http://www.mikrocontroller.net/topic/109648#1487494

=== PC ===
* [http://www.mikrocontroller.net/topic/109648#1352701 gibt als Header gespeicherte Bilder auf std aus]
* [http://www.mikrocontroller.net/topic/109648#1353067 Erweiterter (ungetesteter) Konvertierer für Bilder in Format für Display]

== Links ==

=== Technische Dokumente ===
* [http://www.crystalfontz.com/controllers/SSD1325_2.1.pdf Datenblatt für Display-Controller]
* [http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega168PA AVR Produktseite ATmega168PA mit Datasheets ]
* [http://www.freshpatents.com/Device-for-analysis-of-a-sample-on-a-test-element-dt20081113ptan20080277280.php Patentschrift zu Gerät ]

=== Websites ===
* [http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html Oled-Recycling Seite von adriano6]

=== Diskussions Threads ===

* [http://www.mikrocontroller.net/topic/109648 Hauptdiskussionsthread im Mikrocontrollernet ]
* [http://bascom-forum.de/index.php/topic,2754.0.html Umsetzung in Bascom (wer's mag) im Bascom-Forum]
* [http://www.mikrocontroller.net/topic/143806 Vorschlag für Display-Adapter-Platine]

[[Category:AVR-Projekte]]

Datei:Accu chek combo ir.png

2010-01-16T11:39:49Z

Muebau: tfdu2201

tfdu2201

Compact Plus Blutzuckermessgerät-Hardware

2010-01-07T16:43:16Z

Muebau: /* Komponenten */

== Hardware ==
== Übersicht Hardware ==
* OLED Display 102×80 Pixel incl. 16 Helligkeitsstufen pro Pixel / SSD1325 /43x36 mm gesamt
* Atmega168PA
* DC/DC-Wandler (Regler und Drosseln)
* IR-Sender/Empfänger
* 3 Tasten (4 wenn man den Schließer der Klappe mitzählt)
* 2 Elektromotoren
* kleine Lichtschranke/Barcodescanner
* kleines Spektrometer (2 * LEDs rot, IR(?)-LED, Fotodiode)
* Betriebsspannung 3V (2*AAA)
* SMD Piezo-Summer

== Gerät als Ganzes ==
[[Bild:compact_plus.jpg|400px]]

Das unzerlegte Gerät. Ganz links ist die Stechhilfe.

== Gerät zerlegen ==
Das Gehäuse besteht aus drei ineinander einrastenden Teilen (keine Schrauben). Relativ schadlose Demontage durch vorsichtiges Aufhebeln möglich.
Erst das Seitenteil (links) ganz oben und 2 cm von unten ausrasten.
Von unten anfangen die Gehäusehälften zu lösen, bis man sie über die Oberkante aufklappen kann.

Die Platine selbst ist mit 2 Schrauben und ein paar Clipsen befestigt. Vor dem Entnehmen ist der untere Folienstecker abzuziehen.

[[Bild:compact_plus_open.jpg|250px]]

Das geöffnete Gerät ohne Platine.
Gut zu erkennen (im unverkleinertem Bild) sind die zwei Motoren und die Mechanik die dafür sorgen, dass die Aufbewarungstrommel gedreht und die Messstreifen herausgefahren werden können.

== Komponenten ==

=== Board ===
Hochauflösende Scans beider Platinenseiten.
Die Bauteile sind nach bestem Wissen und Gewissen bezeichnet (für spätere Schaltpläne). Speziell bei den Widerständen und Kondensatoren ist noch eine Kontrolle notwendig. Ich habe dabei alle blauen und schwarzen Bauteile als Widerstände und alles graue und weiße als Kondensatoren gedeutet.

Änderungen bitte mir (Netzwanze) melden.

[[Bild:AccuCheckL1.jpg|300px]][[Bild:AccuCheckL6.jpg|300px]]

=== Stromversorgung ===
Die zwei AAA Zellen sind in Serie geschaltet.
Ein Schaltregler [IC7] erzeugt daraus 3.3 V.
Ein Schaltregler [IC6] erzeugt daraus 12 V für das OLED.

=== Komponenten ===

Nach bestem Wissen und Gewissen bestimmt durch Kombination aus Schaltplänen und Messungen. Bei Komponenten mit "(?)" bin ich mir nicht sicher.

{| class="wikitable"
|-
! Bauteil || Größe
|-
| R1 || 820 kOhm
|-
| R35 || Temperaturfühler; NTC 10 kOhm bei 20°C (?)
|-
| R43 || 100 kOhm
|-
| R44 || 100 Ohm
|-
| R45 || 39 kOhm
|-
| R46 || 1 MOhm
|-
| C24 || 22 uF (?)
|-
| C38 || 4,7 uF
|-
| C39 || 4,7 uF
|-
| C44 || 100 nF
|-
| C45 || 470 nF (?)
|-
| C46 || 10 pF
|-
| L2 || 100 uH
|-
| IC1 || ASIC
|-
| IC2 || ATmega168A
|-
| IC3 || Atmel AT25640A SPI EEPROM
|-
| IC4 || NC7NP14 ULP Triple Inverter with Schmitt Trigger Input
|-
| IC5 || 74LVC1G86GV (Markierung V68)
|-
| IC6 || TPS61080 Step-up 12 V
|-
| IC7 || AS1329, Step-up 3,3 V
|-
| IC8 || BIG 01 A825MFL ????
|-
| D1 || BAT54W
|-
| XTAL1 || 32 Khz
|-
| XTAL2 || 4 Mhz
|}

=== Unbekanntes IC1 ===

Hier mal der Dekodierte Barcode des noch Unbekannten IC1.
Der decodierte Text ist:

25SLEATM 8R4222 084420179+2P00+PLCMC

[[Bild:AccuCheckDecodedMatrixCode.png|500px]]

=== Pinbelegung Mega168 ===

Wie oben mittles Messungen ermittelt. Ohne Garantie auf Vollständigkeit und Richtigkeit.

{| class="wikitable"
|-
! Pin || Port || Funktionen || Verwendung
|-
| 1 || PD3 || (PCINT19/OC2B/INT1) || Taste Mitte (S2)
|-
| 2 || PD4 || (PCINT20/XCK/T0) || Display SCLK (XCLK)
|-
| 3 || GND || || GND
|-
| 4 || VCC || || VCC
|-
| 5 || GND || || GND
|-
| 6 || VCC || || VCC
|-
| 7 || PB6 || (PCINT6/XTAL1/TOSC1) ||
|-
| 8 || PB7 || (PCINT7/XTAL2/TOSC2) || enable 3.3V step-up
|-
| 9 || PD5 || (PCINT21/OC0B/T1) || VCC enable (12 V step-up)
|-
| 10 || PD6 || (PCINT22/OC0A/AIN0) ||
|-
| 11 || PD7 || (PCINT23/AIN1) ||
|-
| 12 || PB0 || (PCINT0/CLKO/ICP1) || an Transistor T1 (schaltet 12 V über 100 Ohm gegen GND als Grundlast bzw. zum Entladen)
|-
| 13 || PB1 || (PCINT1/OC1A) || Display /CS
|-
| 14 || PB2 || (PCINT2/SS/OC1B) ||
|-
| 15 || PB3 || (PCINT3/OC2A/MOSI) || ISP MOSI
|-
| 16 || PB4 || (PCINT4/MISO) || ISP MISO
|-
| 17 || PB5 || (SCK/PCINT5) || ISP SCK
|-
| 18 || AVCC || || mit Beschaltung an VCC
|-
| 19 || ADC6 || || Batteriespannung (3.3Volt StepUp dafür abschalten)
|-
| 20 || AREF || || mit Beschaltung an VCC (REFS1=0, REFS0=1)
|-
| 21 || GND || || GND
|-
| 22 || ADC7 || ||
|-
| 23 || PC0 || (ADC0/PCINT8) ||
|-
| 24 || PC1 || (ADC1/PCINT9) || Display D/C
|-
| 25 || PC2 || (ADC2/PCINT10) || Display RESET
|-
| 26 || PC3 || (ADC3/PCINT11) ||
|-
| 27 || PC4 || (ADC4/SDA/PCINT12) || Taste Links (S1)
|-
| 28 || PC5 || (ADC5/SCL/PCINT13) || Taste rechts (S3)
|-
| 29 || PC6 || (RESET/PCINT14) || ISP Reset
|-
| 30 || PD0 || (RXD/PCINT16) ||
|-
| 31 || PD1 || (TXD/PCINT17) || Display SDIN. Achtung, ist auch TxD (UART-SPI möglich)
|-
| 32 || PD2 || (INT0/PCINT18) ||
|}

==== AVRdude ====
Auslesen der Fuses
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -v

avrdude: Device signature = 0x1e940b
avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: safemode: lfuse reads as 42
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 1

==== Flashen mit AVRdude ====
Da die IDs von ATmega168 und ATmega168A abweichen, muss die Option -F mit avrdude verwendet werden.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -u -U flash:w:Oled-Demo.hex

==== Fuses mit AVRdude ====
Der ATmega168A hat die Fuse CLKDIV8 eingeschaltet.
avrdude -p m168 -P /dev/ttyUSB0 -c avrispv2 -F -U lfuse:w:0xC2:m

=== Display ===
[[Bild:display.JPG|300px]]

Das Display basiert auf OLED - Technologie und besitzt eine Auflösung von 102×80 Pixel, von denen jedes 16 Helligkeitsstufen darstellen kann.
Displaycontroller ist SSD1325.

Detailierte Informationen zum Display gibts auf adriano6's [[#Websites|Webseite ]]

==== Inbetriebnahme auf dem Board ====

Es ist möglich das Display auf dem Board in Betrieb zu nehmen, wenn alle Komponenten bis auf:
R1, R43, R44, R45, R46, C24, C38, C39, C44, C45, C46, L2, IC6 und D1
entfernt werden.
T1 und R11 sind vermutlich als Grundlast zum Start des 12 V Step-up und zum Entladen des OLED beim Abschalten.
Die folgende Tabelle enthält die Pads des Atmega168 Footprints und die entsprechenden Pins am Display.

{| class="wikitable"
|-
! Pad am Atmega168 || Pin am Display
|-
| PD1 || SDIN
|-
| PD4 || SCLK
|-
| PC1 || D/C
|-
| PC2 || RESET
|-
| PB1 || /CS
|}

=== Grafikbeschleunigung mit dem SSD1325 ===

Mit dem im SSD1325 vorhandenen Befehlen Copy, DrawRectangle und HorizontalScolling kann man ein paar nette Animationen machen, bzw. dem ATmega eine Menge Arbeit abnehmen (Details zu Controller und Display stehen im Datenblatt und [[#Websites|hier ]]).

Der Displaycontroller verfügt über ein 64x80 Bytes großes RAM, von dem das Display aber nur 51x80 Bytes (102x80 Pixel) darstellt, beginnend von Spalte 7 bis Spalte 57:

{| class="wikitable" style="text-align:center; width:60em"
! colspan=2 style="width:6em" | Col0
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col6
! colspan=2 style="width:6em; background:#c0c0c0" | Col7
! colspan=2 style="width:6em; background:#c0c0c0" | ...
! colspan=2 style="width:6em; background:#c0c0c0" | Col56
! colspan=2 style="width:6em; background:#c0c0c0" | Col57
! colspan=2 style="width:6em" | Col58
! colspan=2 style="width:6em" | ...
! colspan=2 style="width:6em" | Col63
|- style="width:3em"
| D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0 || D7-4 || D3-0 || D7-4 || D3-0 || ... || ... || D7-4 || D3-0
|}

Schaltet man im Controller nun Wraparound für das Scrolling- und Copy-Commando ein, hängen Ende und Anfang der jeweiligen Zeile hintereinander:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col0 || style="width:6em" | ... || style="width:6em" | Col6
|}

Aus Sicht des Copy- und DrawRectangle-Kommandos kann man jetzt folgendermaßen auf den nicht sichtbaren Bereich des Display-RAM zugreifen:

{| class="wikitable" style="text-align:center; width:36em"
|-
| style="width:6em" | Col58 || style="width:6em" | ... || style="width:6em" | Col63 || style="width:6em" | Col64 || style="width:6em" | ... || style="width:6em" | Col70
|}

Um Daten in diesen Bereich zu bekommen, könnte man einen entsprechenden Bildschirmausschnitt definieren und die Daten einfach sequentiell da rein schreiben. Praktisch hat das aber nicht einwandfrei funktioniert. Besser schreibt man zuerst in den sichtbaren Bereich und kopiert dann den Block in den Bereich ab Spalte 58.
Statt jetzt Grafiken byteweise über die Schnittstelle in das RAM zu schreiben braucht man sie nur noch durch den Controller vom unsichtbaren Bereich (maximal 26x80 Pixel) in den sichtbaren kopieren zu lassen.

Ich habe [http://www.mikrocontroller.net/topic/109648#1419368 eine kleine Demo] geschrieben, die mit dem Copy-Befehl 8 Sprites (sich drehende Bälle) fliegen läßt und bei jeder Randberührung eines Sprites einen Zähler erhöht. Im Hintergrund laufen je eine horizontale und vertikale Linie (Rechteck) durch.
Das Ganze verbraucht mit Software-SPI ca. 20% Rechenzeit des ATmega, bei Hardware-SPI sind es ca. 6%.

Um auch in horizontaler Richtung eine pixelgenaue Bewegung zu erreichen, erstellt man für jedes Sprite zwei um jeweils ein Pixel verschobene Versionen, und kopiert diese nacheinander auf die selbe Spaltenposition.

Das Timing ist etwas kritisch, da vom Controller keine Rückmeldung möglich ist, man muß ggf. die Wartezeit nach einem Kommando versuchsweise ermitteln. Schickt man das nächste Kommando zu früh ab, wird das gerade laufende abgebrochen, was nicht immer schön aussieht oder sogar den Controller zum Abstürzen bringt.

Bei Ansteuerung mit Hardware-SPI muß man außerdem ca. 2us warten, bevor das CS-Signal deaktiviert werden kann.

=== Spektrometer ===
[[Bild:Accu-Check_CompactPlus_BZ_Sensor.jpg|200px]]

Im Grunde genommen, handelt es sich um eine Reflexlichtschranke mit zwei roten LEDs, einer vermutlich infraroten LED, sowie einer Fotodiode.

[[Bild:Accu-Check_CompactPlus_Photometer.jpg|200px]]

== Programme ==
=== µC ===
* GPS http://www.mikrocontroller.net/topic/109648#1385554
** http://www.mikrocontroller.net/topic/109648#1397017

* Grafikdemo: http://www.mikrocontroller.net/topic/109648#1419368
** Video: http://vimeo.com/6609124

* Kurzzeitwecker: http://www.mikrocontroller.net/topic/109648#1412841
** http://www.mikrocontroller.net/topic/109648#1427502

* serielle Displaysteuerung: http://www.mikrocontroller.net/topic/109648#1487494

=== PC ===
* [http://www.mikrocontroller.net/topic/109648#1352701 gibt als Header gespeicherte Bilder auf std aus]
* [http://www.mikrocontroller.net/topic/109648#1353067 Erweiterter (ungetesteter) Konvertierer für Bilder in Format für Display]

== Links ==

=== Technische Dokumente ===
* [http://www.crystalfontz.com/controllers/SSD1325_2.1.pdf Datenblatt für Display-Controller]
* [http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega168PA AVR Produktseite ATmega168PA mit Datasheets ]
* [http://www.freshpatents.com/Device-for-analysis-of-a-sample-on-a-test-element-dt20081113ptan20080277280.php Patentschrift zu Gerät ]

=== Websites ===
* [http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html Oled-Recycling Seite von adriano6]

=== Diskussions Threads ===

* [http://www.mikrocontroller.net/topic/109648 Hauptdiskussionsthread im Mikrocontrollernet ]
* [http://bascom-forum.de/index.php/topic,2754.0.html Umsetzung in Bascom (wer's mag) im Bascom-Forum]
* [http://www.mikrocontroller.net/topic/143806 Vorschlag für Display-Adapter-Platine]

[[Category:AVR-Projekte]]

Datei:AccuCheckDecodedMatrixCode.png

2010-01-07T16:37:45Z

Muebau: Decoded data: 25SLEATM 8R4222 084420179+2P00+PLCMC

Decoded data:
25SLEATM 8R4222 084420179+2P00+PLCMC