CTC- Falsche Berechnung

[Spurius]

Hallo,
nachdem ich das mitm dem CTC mittlerweile einigermassen im Griff zu haben glaubte, stehe ich nun vor dem Problem, dass meine errechnete Frequenz nicht mit der tatsächlichen übereinstimmt.
Hier wieder der Code:

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/signal.h>

volatile uint8_t count = 0;
volatile uint8_t serv1 = 0;
volatile uint8_t serv2 = 0;
volatile uint8_t pos = 0;


int main(void)
{
TCCR2 = (1<<COM20) | (1<<WGM21) | (1<<CS20);
OCR2 = 221;
DDRB = (1<<PB3);
while(1) {};

}

Mit dem Digitalmultimeter gemessen kommen da 93khz anstatt von 36khz heraus - Wo liegt der Fehler? F_CPU sind 16MHZ.

Gruss
Spurius

[fhs]

Hallo Spurius,

Du verrätst nicht, welchen Prozessor Du programmierst, was die Fehlersuche sehr erschwert. Für den ATmega32 bei 16MHz wäre die TC2-Initialisierung OK für 36kHz; aber ich weiß gerade nicht, bei welchem der AVRs der OC2-Ausgang an PB3 liegt. Kann es sein, dass Du ein falsches Signal abgreifst?

Gruß

Fred

[Spurius]

Sorry, verwende den ATMega8, der Pin sollte (diesmal) der Richtige sein!

[fhs]

Hallo Spurius,

ich wundere mich mit Dir, dass das Signal nicht bei 36kHz liegt! Deine Initialisierung ist korrekt für Mode 2 (CTC) und bei 16MHz F_CPU sollten 36kHz an OC2 anliegen.

Ich habe es mir zur Regel gemacht, das CompareMatch Register zu schreiben, bevor ich den Timer starte, wenn das irgendwie möglich ist. Das hat aber nur Einfluss auf den ersten Zyklus.

Gruß

Fred

[Spurius]

Hallo,

ich habe jetzt etwas herumprobiert und mit diesem Code bekomme ich 36 khz, allerdings ergeben meine Berechnungen etwas VÖLLIG anderes!

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/signal.h>

volatile uint8_t count = 0;
volatile uint8_t serv1 = 0;
volatile uint8_t serv2 = 0;
volatile uint8_t pos = 0;


int main(void)
{
TCCR2 |= (1<<COM20) | (1<<WGM21) | (1<<CS21);
OCR2 = 71;
DDRB = (1<<PB3);
while(1) {};

}
Der Vorteiler ist hierbei 8... ICh muss aber unbedingt herausfinden, was da nicht stimmt.

[izaseba]

Bist Du Dir sicher, daß Dein Multimeter richtig funktioniert ?

Bei Deiner Konfiguration müßte in der Tat irgendwas mit 36 kHz rauskommen.

Kommtst Du an einen Osci ? oder Frequenzzähler dran ?

Gruß Sebastian

[Spurius]

Hallo,
Korrektur - Habe bisher immer den einen Messfühler beim MEssen auf MAsse gelegt, wenn ich den freilasse messe ich 36khz - :)
Das Problem ist jetzt, dass das hier dennoch nicht funktioniert, ich verwende einen TSOP1736:
http://www.robotmaker.de/fernbed.html
Und will dann halt auf Empfägerseite zumindest erstmal sehen, wann ein Interrupt ausgelöst wird.

[fhs]

Hallo Spurius,

ich weiß ja nicht, was für ein Signal Du sendest -- die TSOP1736-IR-Demodulatoren unterdrücken jedenfalls kontinuierliche 36kHz-Signale! Du musst das Signal schon modulieren (Bursts senden).

TSOP17xx-Datenblatt (http://www.datasheetcatalog.org/datasheets/208/301092_DS.pdf).

Gruß

Fred

[Spurius]

Hallo,
also da wird eigentlich schon dauergesendet, aber so wird das in der Schaltung ja auch beschrieben, wobei halt mit 2khz "dauergesendet" wird. ICh wollte jetzt einfach mal so einen Interrupt auslösen, indem ich den INT0 mit dem OUTPin des TSOP verbinde, aber wenn ich da 36khz draufhalte tut sich nichts, ebensowenig wie bei einer RC5-Fernbedienung - eigentlich müsste da schonmal ein Pegelwechsel stattfinden oder?

[fhs]

Hi,


....wobei halt mit 2khz "dauergesendet" wird. ICh wollte jetzt einfach mal so einen Interrupt auslösen, indem ich den INT0 mit dem OUTPin des TSOP verbinde, aber wenn ich da 36khz draufhalte tut sich nichts, ebensowenig wie bei einer RC5-Fernbedienung
1. Wie steuerst Du die IR-LED an?
2. Die 36kHz sind also mit 2kHz amplitudenmoduliert??

Gruß

Fred

[Spurius]

Die LED wird mit 36khz getaktet, und der Baustein aus der Schaltung packt da seine Daten rein soweit ich weiss. Ich werde jetzt aber versuchen, das mit RC5 zu lösen, erscheint mir irgendwie einfacher & universeller.