Atmega48V+128khz+RC5send?

[Dunuin]

Moin,

Ich habe da gerade ein Problem mit dem RC5send-Befehl am ATMega48V über den integrierten 128KHZ Quarz.
Schaltung und Programm sind eigentlich so aufgebaut, wie ich das schon einmal erfolgreich mit einem Attiny2313 bei 1MHZ gemacht habe, aber der RC5-Code vom Atmega48v wird einfach nicht erkannt.

Hat schon jemand das gleiche versucht? Liegt das vielleicht am Atmega48v oder daran, dass ich nur 128KHZ nutze?

Ich habe das IR-Signal mal am Ozi gemessen und da sieht man schon, dass da etwas Digital gesendet wird. Was genau die Bitfolge war konnte ich allerdings nicht erkennen, da ich mit dem Ozi noch nicht sonderlich umgehen kann.

• $regfile ist m48def.dat
• $crystal ist 128000
• Interrupts sind aktiviert
• Timer1 wird für nichts anderes benutzt
• IR-Empfänger, IR-Diode und PNP-Transistor sind die gleichen wie beim funktionierenden attiny2313
• hängen auch am OC1A

Abgesehen davon, dass vielleicht das Timing nicht richtig passt und die 36khz irgendwie verfehlt werden, fällt mir auch nichts mehr ein. Ein Frequenzzähler zum überprüfen der Taktung habe ich leider auch nicht.

Wäre schon, wenn da noch jemand einen Tipp hat.

MfG

Dunuin

[DanielSan]

Hi,

als ich mich das letzte mal mit IR Fernsteuerungen beschäftigt habe, habe ich das Signal selbst erzeugt. "Quick and Dirty" mit "waitus" ganz wichtig ist, das die einzelnen Signale also ein High als Burst gesendet wird. Ein Burst also eine 1 wird als schnelle folge von "an, aus, an, aus, ..." gesendet. Ein Mensch kann eine Blitzende Lampe besser von anderen unterscheiden. So ist es auch beim IR-Empfänger.

Ich denke mal das deine 128kHz einfach zu gering sind. Versuch es doch mal mit dem gleichen Code, allerdings auf 1Mhz. Wenn es dann geht weisst du warum es nicht mit 128kHz funktioniert.

Ist es denn in deiner Anwendung zwingend nötig, den Atmel so "langsam" zu betreiben?

Gruß Daniel

[Dunuin]

Ja, wäre schon mit 128khz schön gewesen, damit die Batterien möglichst lange halten.
Das hätte außerdem noch den Vorteil, dass ich den Watchdog (auf 4 sek eingestellt) brauche und ich den uC so alle 2 sekunden aus dem PowerDown-Modus aufwecken lassen kann, damit dieser den WDT zurücksetzt, weil der Timer2 (8bit) auch im Energiesparmodus weiterläuft.
Bei 1MHZ müsste der uC dann 4 mal pro Sekunde aufwachen und es dauert ja auch immer etwas, bis die ganzen Quarze wieder angelaufen sind.

Aber ich werde es dann mal 1 MHZ versuchen.

Edit:
Habe eben noch einmal versucht am Ozi zu gucken, was dort ankommt.
Wenn ich "Tal-Berg" als 1 interpretiere und "Berg-Tal" als 0, dann ist der gesendete Code "11010110000001", was ja eigentlich ok aussieht. Die ersten 3 Bits dürften ja passen, da ich mit Togglebit 0 gesendet habe und die folgenden 5 Bits für die Adresse sind auch ok, da ich dort 22 eingestellt habe, was zum "10110" passt. Die letzten 5 Bits könnten auch passen, da der gesendete Befehl irgendwo zwischen 1 und 20 liegen soll, je nach gedrückter Taste.

Was mir allerdings ganz vorne auffiel, das war eine ganz kurze Spitze vor dem 1. Tal von der 0 des 1. Bits. Bringt das vielleicht den Empfänger durcheinander oder ist das so eine Art Markierung um anzudeuten, wo die 14 Bits anfangen und aufhören.

Wenn es hilfreich ist, dann kann ich sonst auch nochmal ein Foto vom Ozi machen.

Edit:
Habe es jetzt noch einmal mit 1MHZ versucht (Int. 8 MHZ und dem Div8-Fuse) und so klappt das Senden fehlerfrei. Da scheint Bascom wirklich Probleme mit den 128khz zu haben.

Dann habe ich jetzt aber wieder das Problem, dass der uC bei 1MHZ eigentlich zu oft aufwacht. Weiß sonst noch jemand Rat, wie man den Atmega48v zuverlässig den Watchdogtimer resetten lassen kann? Timer 2 asynchon laufen lassen würde ich gerne vermeiden, da ich eigentlich keinen externen Quarz anschließen wollte.