Probleme mit "IRSND"

Morpheus1997 schrieb:
> nachdem ich erfolgreich das Projekt 'ICMP' getestet habe,

Das Ding heist IRMP, nicht ICMP.

> Als Mikrocontroller verwende ich einen AtMega1284P mit einem externen
> 16MHz  Quarz.

F_CPU steht auf 16000000 im Projekt? Ich finde es nämlich weder in 
irsnd-avr-main.cproj noch in Debug/Makefile.

> Leider empfange ich auf dem Arduino keine Protokolle ( bei
> anderen, handelsüblichen Fernbedienungen jedoch schon),

Dann ist was falsch konfiguriert. Ich finde in Deinem RAR-Paket auch 
zwei Dateien, nämlich:

   irsnd-avr-main.c
   irsnd-main-avr.c

Welche von beiden Dateien ist denn ins Projekt eingebunden? Bist Du 
sicher, dass Du das richtige Modul mit main-Funktion verwendest? Eine 
von beiden main-Funktionen ist leer, das würde erklären, dass nichts 
ausgegeben wird.

> und man sieht
> auch, wenn man eine Kamera vor der IR-LED hält, kein leuchten.

Laut irsnd-config.h benutzt Du IRSND_OC2B, das wäre PD6. Fragt sich 
jetzt nur, wie Du die LED angeschlossen ist. So wie im Artikel, mit 
einem Transistor, welcher das Signal negiert?

> Durch ein kleines LED-Blink-Programm konnte ich jedoch erkennen, dass
> die IR-LED blinkt, die Schaltung somit funktionstüchtig ist,

Wenn Du die IR-LED direkt angeschlossen hast, funktioniert zwar Dein 
Blink-Programm, aber bestimmt nicht IRSND.

Also: Zeig bitte die Schaltung.

> und auch
> die Fuses gesetzt zu sein scheinen, da die Frequenz etwa passte.

"scheinen"? Bitte schreibe hier die Fuses-Werte konkret rein!

> Daher gehe ich von einem Software-Fehler aus, die Hardware scheint
> funktionstüchtig zu sein.

Ich sehe da erstmal keinen Software-Fehler. Da IRSND tausendfach 
eingesetzt wird, ist auch im IRSND-Teil nicht von einem Fehler 
auszugehen - schon gar nicht, wenn du so etwas simples wie das 
NEC-Protokoll verwendest. Eher scheint etwas mit Deiner 
Konfiguration/Schaltung nicht zu stimmen.

> Die IR-Diode ist am Pin D6 angeschlossen,
> somit wird OCB2 als PWM-Pin verwendet.

Direkt angeschlossen oder über einen Transistor - wie im Artikel 
angegeben? Ersteres wäre falsch.

Morpheus1997 schrieb:
> Ich habe einfach mal den gesamten Projekt-Code vom IR-µC angehangen,
> vielleicht weiß ja einer weiter.

Es gibt nur sehr wenige mutige Seelen, die ein 126kB RAR auf ihren 
Rechner entpacken, um den Teil des Programmes, den du selber geschrieben 
hast, anzuschauen. Da IRMP und IRSND in sich stabil laufen, ist es also 
sinnvoll, nur die Teile des Programmes als Klartext anzuhängen, die du 
selber gemacht hast.
Die Standardfragen sind:

Morpheus1997 schrieb:
> und man sieht
> auch, wenn man eine Kamera vor der IR-LED hält, kein leuchten.

Portpin auch als Ausgang deklariert? Timer ISR auch eingebunden? 
'irsndconfig.h' durchgegangen und alles richtig eingestellt?

Matthias S. schrieb:
> Portpin auch als Ausgang deklariert?

Macht irsnd_init() automatisch.

> Timer ISR auch eingebunden?

Kommt darauf an, ob er

   irsnd-avr-main.c
oder
   irsnd-main-avr.c

ins Projekt eingebunden hat. In einer der beiden Module steckt nämlich 
eine leere main-Funktion. Nein..... die ist nicht von mir! ;-)

Wenn er Pech hat, hat er das falsche .c ins Projekt genommen.

> 'irsndconfig.h' durchgegangen und alles richtig eingestellt?

Die config-Datei im Rar-Archiv sieht jedenfalls korrekt aus, was den 
Output-Pin betrifft. OC2B = PD6

Frank M. schrieb:
> Macht irsnd_init() automatisch.

Gibs zu - das macht die Datei nicht automatisch, da hast du ihr 
beigebracht :-)
Mich irritiert, das der TE nix von der IR LED sieht. Selbst wenn die 
Transistorstufe nicht verbaut ist, müsste man ja, wenn auch invertiert, 
die IR LED sehen.
Wird also vermutlich die fehlende Timer-ISR sein.

> Nein..... die ist nicht von mir! ;-)

Wie ist die denn da reingerutscht?

Matthias S. schrieb:
> Wie ist die denn da reingerutscht?

Die ist wohl vom TO selbst:

1

/*

2

 * irsnd_avr_main.c

3

 *

4

 * Created: 22.08.2016 20:24:10

5

 *  Author: MHunfeld

6

 */ 

7

8

#include <avr/io.h>

9

10

int main(void)

11

{

12

    while(1)

13

    {

14

        //TODO:: Please write your application code 

15

    }

16

}

Das hier in irsnd-main-avr.c sieht auch nicht koscher aus:

1

#ifndef F_CPU              // Das ist IRSND-Standard

2

#  error F_CPU unknown

3

#endif

4

5

#define F_CPU 16000000UL   // Das ist vom TO

6

#include <util/delay.h>

Wenn F_CPU vom Projekt her nicht definiert wäre, hätte der Compiler oben 
gemeckert - wie von IRSND auch gewünscht. Der TO definiert aber 
danach(!) nochmal F_CPU neu, vielleicht um so F_CPU zu korrigieren?!?

@Morpheus1997: Bekommst Du Compiler-Warnings? Die dürfen NICHT sein.

Der #define muss auf jeden Fall raus!

Das obige wäre ein Indiz, dass F_CPU im Projekt falsch definiert ist, 
was für irsnd.c tödlich wäre.

Bei meinen Versuchen mit NEC und Apple konnte ich immer mal wieder 
feststellen, das es anscheinend nicht möglich ist, die beiden 
voneinander eindeutig zu unterscheiden. Mal sagt mein IRMP Receiver, das 
es sich um Protokoll 2 handelt und manchmal um Protokoll 11 (?).

Wenn du ga nicht weiterkommst und zufällig eine Windows32 Kiste mit 
Soundeingang besitzt, kannst du auch mal den IR Protokoll Analyzer von 
Ondrej Stanek installieren und dir mit einem alten Klinkenkabel und 
Phototransistor einen IR Kopf basteln:

http://www.ostan.cz/IR_protocol_analyzer/

NEC Protokoll ist da mit drin und du kannst mal deinen eigenen Aufbau 
mit dem Programm vergleichen.
Wohlgemerkt, da kommt kein fertiger IR Empfänger zum Einsatz, sondern 
lediglich ein IR Phototransistor.

Morpheus1997 schrieb:
> Wenn ich diese Daten jedoch in der main.c eintrage und versende, so
> empfange ich den Code '87EE AC53'

Apple kann ich Dir nicht empfehlen, da hier die Adresse fix ist. Apple 
ist eigentlich eine NEC-Variante mit fester Geräteadresse. Das heisst: 
IRSND ignoriert Deine Adresse und verwendet die feste von Apple.

Ich empfehle Dir NEC zur Datenübertragung. Hier kannst Du eine 
16-Bit-Adresse auswählen, z.B. FF00 ist hier weit verbreitet. 
Üblicherweise ist das 2. Adressbyte invertiert zum ersten, muss aber 
nicht sein. Wenn nicht, handelt es sich um das "Extended Nec Protocol".

Als Kommando-Code ist der Werte-Bereich bei NEC 0-255, also ein Byte, 
nicht zwei. Das zweite Byte ist im NEC-Code die Invertierung des 
Kommando-Codes und wird von IRSND automatisch selbst generiert.

Teste mal: NEC, Adresse FF00, Kommando 0 bis 255 (0x00 - 0xFF). Diese 
Werte solltest Du mit IRMP 1:1 empfangen können.

Beachte bitte immer die Wertebereiche des jeweiligen Protokolls. Nur die 
wenigstens sind 16-Bit-transparent. Einige bestehen sogar aus Bits 
weniger als ein Byte.

Eine genaue Beschreibung der Protokolle findest Du unter

  IRMP: Die IR-Protokolle im Detail

Morpheus1997 schrieb:
> Alles klar, das werde ich bei Gelegenheit mal ausprobieren, auch wenn es
> immer eine ganz schöne Bastelei ist, den Soundkarteneingang als
> Oszilloskop zu missbrauchen, wie ich es schon einmal gemacht habe, um
> Funk-Steckdosen auszulesen.

Das ist in diesem Fall eine Frage eines alten Klinkenkabels für den 
Mikroeingang des Rechners und zwei Lötstellen, um daran den 
Phototransistor anzulöten. (Emitter an Masse/Abschirmung und Kollektor 
an den Innenleiter)
Die Speisung des Mikroeingangs speist den Phototransistor. Irgendwelche 
anderen Teile braucht man nicht. Das beschreibt Ondrej auch in der Doku.
Geeignete Phototransistoren finden sich z.B. in Videorecordern für 
Bandende und -anfangserkennung.

Morpheus1997 schrieb:
> Danke für den Tip, wenn ich auf Protokoll 11, also dem eigentlich
> angedachten Apple-Protokoll umsteige, dann empfange ich zumindest den
> Adress-code richtig: Ich sende '77E1' und empfange dies auch. Allerdings
> stimmt der Kommando-Code immer noch nicht. Aus 'BA35' wandelt er nun
> 'AC8B'.

Auszug aus https://www.mikrocontroller.net/articles/IRMP#APPLE :

    Daten 16 Adress-Bits + 11100000 + 8 Kommando-Bits

Du kannst nur 8 Bits als Kommando-Code schicken, das obere Byte des 
Kommandos ist fix.

> Mir ist es bisher jedoch leider noch nicht gelungen, den selben Code
> zu empfangen, den ich auch versuche zu senden.

Das ist mir allerdings unverständlich.