Hallo Zusammen,
ich hab den ICP1 eines Atmega128 folgendermaßen initialisiert
TCCR1B |= (1 << ICNC1) | (1 << ICES1) | (1 << CS12);
TIMSK |= (1 << TICIE1);
TCNT1 = 0;
An PD4 hängt ein TSOP und der soll ein IR-Signal decodieren.
Die ISR(TIMER1_CAPT_vect) wird auch aufgerufen, allerdings bekomme ich
interrupts, die völlig undefiniert sind und zufällig auftreten.
Erst dachte ich, dass es an dem fehlenden Pullup liegen könnte, doch mit
programmierten Pullups, sowie festem Pullup, bekomme ich die Störungen
nicht weg. Wie könnte man sowas abfangen oder beseitigen? Vielen Dank
schon mal...
Schönen Sonntag
Karl
Matthias Lipinsky schrieb:
> Was sieht denn der TSOP? Vielleicht eine Neonröhre oder sowas?
Infrarot Fernbedienungsempfänger.
Schäm dich, Matthias! ;o)
IR-Empfänger ist richtig. Unabhängig von dem TSOP, ist so ein Verhalten
möglich? Trotz Pullup? Eigentlich ja nur, wenn der TSOP aktiv gegen GND
zieht, oder?
ich finde den Fehler einfach nicht... Oszi habe ich leider nicht da,
sonst hätte ich das als aller erstes getan...
Karl schrieb:
> IR-Empfänger ist richtig. Unabhängig von dem TSOP, ist so ein Verhalten> möglich? Trotz Pullup? Eigentlich ja nur, wenn der TSOP aktiv gegen GND> zieht, oder?> ich finde den Fehler einfach nicht... Oszi habe ich leider nicht da,> sonst hätte ich das als aller erstes getan...
Beim TSOP (ich denke mal das gilt fuer alle) ist ein Pullup eher
hinderlich. Der hat ja schon einen recht starken drin... ;)
Ich verstehe aber immernoch nicht wie der TSOP einen /Timer/interrupt
ausloesen soll..
Volker
@Volker: Danke für die Info. Hab mit grad mal ein soundkarten oszi
gebastelt, der TSOP scheint ok zu sein. Ich habe diverse Projekte mit
einem TSOP gesehen, wo ca 10k Pullup dran hängen.
>Ich verstehe aber immernoch nicht wie der TSOP einen /Timer/interrupt>ausloesen soll..
Der ICP ist ja genau für solche Zwecke geeignet (Frequenzzähler)
Anhand der Timerstände und deinem SystemTakt kannst du dann die Frequenz
errechnen. Ich möchte erstmal nur die TimeTicks zwischen jeweils den
steigenden oder fallenden Flanken ermitteln und über die UART
ausgeben... Aber wie gesagt, wenn der TSOP am µC hängt, dann löst der
einfach so aus. Auf dem Soundoszi sehe ich einiges an Rauschen, aber ich
denke und hoffe, dass das nicht der Realität entspricht.
Gruß Karl
Karl schrieb:
> Auf dem Soundoszi sehe ich einiges an Rauschen, aber ich> denke und hoffe, dass das nicht der Realität entspricht.
Doch, das tut es.
Ist quasi wie bei älteren UKW-Radios ohne Rauschsperre.
Besser ist daher die Abtastung mit einem Timerinterrupt, damit filtert
man kurze Störungen raus.
Und dann muß man noch testen, ob die Pulse dem erwarteten Code
entsprechen.
Peter
Alles brav Entstört ? Elko von Vdd nach GND ? Massenflächen ?
Oder hat's vielleicht den IR-Empf. erwischt ? versuch den doch mal zu
ersetzen.
Viel Glück =)
> Oder hat's vielleicht den IR-Empf. erwischt ? versuch den doch mal zu> ersetzen.
Nö, es ist völlig normal, dass der Spikes ausgibt. Dazu reicht schon
eine ESL. Man muss eben die Software so schreiben, dass sie sich von
Spikes oder Fremdsignalen nicht verarschen lässt.
...
Achja noch was,
ist es eigentlich möglich mehrere TSOPs über Gatter zusammenzuschalten,
um beispielsweise einen "Rundempfänger" zu basteln?
Danke nochmal und Gruß
Karl
Hallo Karl,
wie hast du programmtechnisch die Spikes weggefiltert?
Stehe vor einem ähnlichem Problem, dass ich manchmal Interrupts erhalte,
die da nicht sein sollten...
Hast du ggf. ein Stück Code für mich?
Danke!
Grüße
Stefan
Matthias Lipinsky schrieb:
>>Auf Hannes Tip hin, ...>> Sauerei, ich war eher ;-)
Stimmt... Das hat man wohl für einen Scherz gehalten. 8-P
(Gruß elbaufwärts...)
Ich hatte übrigens mal eine ESL, die hat mir grundsätzlich den
Grundig-TV ausgemacht, selbst aus dem Nachbarzimmer über mehrere
Reflexionen (bei offenen Türen). Ich habe mich dann von dem Ding trennen
müssen.
Der entscheidende Tip für mich war allerdings von Peter (danke):
Beitrag "Re: ICP Interrupt Problem, löst bei Berührung und zufällig aus."
Ich werde meine nächsten IR-Empfänger-Versuche mal auf dieser Basis
machen. Ein paar nicht identifizierte Ein-Euro-Fernbedienungen von
Pollin habe ich ja noch liegen... ;-)
...
Karl schrieb:
> Achja noch was,>> ist es eigentlich möglich mehrere TSOPs über Gatter
Warum Gatter? - Die haben Open-Coll.-Ausgang, die kann man direkt
parallelschalten. In einer Rolladensteuerung für ein Eigenheim wurden
mehrere TSOPs in verschiedenen Räumen parallelgeschaltet und mehrere
Pollin-IR8-Bausätze (mit neuer Firmware) mit diesem Signal angesteuert.
> zusammenzuschalten,> um beispielsweise einen "Rundempfänger" zu basteln?>> Danke nochmal und Gruß> Karl
...
Vielen Dank nochmal an alle, natürlich auch besonders an Matthias ;-)
@Stefan:
Da mein IR-Signal ein Sync-Bit mit bekannter Periodendauer in Ticks vor
und nach jedem Stream sendet, prüfe ich in der InputCapture-ISR, ob die
TimeTick-Differenz zwischen 2 aufeinanderfolgenden Input-Capture-Events
genau der Anzahl an TimeTicks (+-5) von meinem Sync-Signal entspricht.
Wenn ja wird ein zweiter Timer gestartet und alles was danach kommt in
einem Array gepuffert. Wenn dieser Timer überläuft bevor mein zweites
Sync am Ende des Streams kommt, wird das Signal verworfen. Wenn jedoch
ein zweites Sync kommt, bevor der Timer überläuft, wird der Timer wieder
gestoppt und der Stream zwischen den beiden Sync-Signalen mit gültigen
Streams (später ausm EEPROM) verglichen und die dazu jeweils zugeordnete
Funktion aufgerufen, wenn die Streams übereinstimmen...
Im Prinzip mache ich eine kurze Überprüfung der Periodendauer der
Signale (innerhalb der InputCaptureISR), da mein Protokoll aus genau 3
verschiedenen Signalen mit unterschiedlichen Periodendauern besteht.
Klar benötige ich erstmal 2 Timer, aber wie gesagt, da ich mehr
ressourcen zur Verfügung habe, als ich benötige, war das so mein erster
"quickhack", welcher seit gestern Nacht 1A funktioniert.
Gruß Karl
> Klar benötige ich erstmal 2 Timer,
Nööö, der Timer1, der ICP kann, der kann nebenher noch zwei
Compare-Interrupts generieren, mit denen genaue Intervalle erzeugt
werden können. Du musst nur dafür sorgen, dass der Timer frei
durchläuft, also von niemandem (außer dem CPU-Takt) verändert wird. Bei
ICP bildet man die Differenz zum zuvor gemessenen Wert (neu minus alt),
bei den Compares liest man den Compare-Wert aus dem OCR-Register,
addiert das Intervall drauf und schreibt es als neuen Int-Termin ins
OCR-Register zurück. Und ja, man kann auch noch den Überlauf-Int
benutzen, der ist aber nur bedingt brauchbar, weil man ja auf Reload
verzichten muss, denn der Timer muss ungehindert durchlaufen.
...
