IRSND mit 1MHz

[flux (Gast)]

Hallo,

ich baue gerade einen IR-Transmitter mit einem ATmega328P auf.
Dieser soll natürlich möglichst stromsparend arbeiten, da er mit 
Batterien betrieben wird.
Nun habe ich es bereits geschafft, einen Sleep-Modus zu integrieren, der 
auch ziemlich gut wirkt (nur 0.11µA Verbrauch).
Während des Sendens ist der Verbrauch allerdings mit 2mA recht hoch.
Ich hatte deswegen auch schon den 128kHz Oszillator aktiviert, was zu 
einer deutlichen Verbesserung geführt hat. Leider kommt IRSND nicht 
damit klar.
Schuld daran ist die Berechnung für die 38kHz-Modulation:
128000/38000/2-1=0.6 -> 0
Nun habe ich dann 1MHz wieder aktiviert.
Jetzt passt alles und alle Timer können entsprechend eingestellt werden.
Nur: die Impulslängen stimmen irgendwie nicht.
So müsste es aussehen (von fertiger NEC-Fernbedienung):
siehe SOLL
Und so sieht es mit 1MHz aus:
siehe IST

Mit 8MHz funktioniert es jedoch einwandfrei und die Impulslängen 
stimmen.
Ich nutze einen 10kHz-Interrupt für irsnd_ISR() und habe das auch 
entsprechend eingestellt.

  /* init IRSND timer */
  TCCR1B = (1 << WGM12) | (1 << CS10);
  OCR1A = (F_CPU / F_INTERRUPTS) - 1;
  TIMSK1 = (1 << OCIE1A);

[Klaus R. (klaus2)]

Das hält doch trotzdem ewig...zumal die IR Led ein vielfaches zieht! 
Wozu also der überflüssige Aufwand?

Klaus.

[flux (Gast)]

Klaus R. schrieb:
> Das hält doch trotzdem ewig...zumal die IR Led ein vielfaches
> zieht!
> Wozu also der überflüssige Aufwand?
>
> Klaus.

Die IR-LED zieht natürlich mehr, aber eben nur sehr kurz und 
impulsweise.
Und außerdem wüsste ich gerne auch, woran das liegt. Weil ich kann 
eigentlich nichts im IRSND-Code entdecken, das das verursachen könnte.

[Klaus R. (klaus2)]

...ach du meinst irsnd zieht immer 2mA auch im sleep oder wie? Das kann 
nicht sein, nutze ich mit 5uA. Vermute eher dein uc schläft nicht 
sauber...

Klaus.

[Joachim B. (jar)]

flux schrieb:
> Nun habe ich dann 1MHz wieder aktiviert.
> Jetzt passt alles und alle Timer können entsprechend eingestellt werden.
> Nur: die Impulslängen stimmen irgendwie nicht.
> So müsste es aussehen (von fertiger NEC-Fernbedienung):
> siehe SOLL
> Und so sieht es mit 1MHz aus:
> siehe IST

frage den Autor: frank (ukw) Moderator hier per mail PN an
https://www.mikrocontroller.net/articles/IRMP

[c-hater (Gast)]

flux schrieb:

> Und außerdem wüsste ich gerne auch, woran das liegt. Weil ich kann
> eigentlich nichts im IRSND-Code entdecken, das das verursachen könnte.

Es gibt zwei Möglichkeiten: der Timer gibt's nicht her oder der Code ist 
schlicht zu langsam. Ich tippe stark auf letzteres.

Überlege doch mal: wenn der Systemtakt 128kHz ist und die ISR mit einer 
Interruptrate von 10kHz ausgeführt wird, bleiben für jede ISR nur exakt 
12,8 Takte. Das reicht für einen minimalen Interrupt-Rahmen (8 Takte) 
zum Sichern und Wiederherstellen eines einzigen Registers (4 Takte). Es 
reicht schon nicht mehr dazu, das Statusregister zu sichern und 
wiederherzustellen und Luft für irgendeinen Nutzcode bleibt natürlich 
gar keine...

Bei 1MHz sieht das schon deutlich besser aus, da hast du dann 100 Takte 
pro ISR. Aber: C ist tierisch ineffizient in ISRs, es würde mich kein 
bissel wundern, wenn auch diese 100 Takte nicht genügen für den Code von 
irsnd. Letzte Sicherheit liefert das Assemblerlisting der ISR, da kannst 
du die benötigten Takte zählen. Wenn es mehr als 97 sind, kann die Sache 
nicht funktionieren.

Asm rules! Damit kann man ganz sicher einen universellen IR-Sender bei 
1Mhz realisieren. Wenn man nur einen ganz speziellen umsetzen möchte, 
kann man mit dem Takt auch noch deutlich weiter runtergehen, muss ihn 
dann aber möglichst "passend" wählen, idealerweise ein ganzzahliges 
Vielfaches sowohl der Modulationsfrequenz als auch der Trägerfrequenz.

[flux (Gast)]

Moment...
Mir ist gerade aufgefallen, dass SOLL und IST gleich sind.
Das liegt daran, dass ich den gerade auf 8MHz laufen habe.
Ich liefere gleich einmal richtige Ergebnisse.

[flux (Gast)]

Gestern war die Abweichung irgendwie größer, trotzdem hier einmal mit 
1MHz. Gestern hatte ich z.B. beim ersten HIGH noch 12000. Jetzt mit 9500 
wird es zwar manchmal erkannt, aber doch recht unzuverlässig.

Es stimmt aber tatsächlich, dass es daran liegen kann, dass die Zeit für 
den µC nicht ausreicht, um die ISR ordentlich auszuführen. Aber dann 
dürften doch gar keine Ergebnisse oder zumindest nicht so sinnvolle nur 
ein wenig verlängerte Ergebnisse herauskommen, oder?

[flux (Gast)]

Zum Stromverbrauch noch:
ich habe jetzt noch einmal nachgemessen. Irgendwie habe ich es heute 
nicht mit Zahlen.
FREQ: Active/Sleep
1MHz: 0.5mA/12µA
8MHz: 2mA/20µA
Irgendwie hatte ich den Sleepverbrauch deutlich geringer in Erinnerung. 
Aber ich denke, dass da die Selbstentladung der Batterien vermutlich 
höher ist.
Dann werde ich nun einfach 8MHz nehmen und den höheren Stromverbrauch in 
Kauf nehmen.

[flux (Gast)]

Ich weiß jetzt (glaube ich), warum es gestern schlimmer war.
Da habe ich nicht die Option -flto (wie im Wiki empfohlen) genutzt.
Das legt nahe, dass bei 1MHz die ISR tatsächlich zu oft aufgerufen wird 
und deswegen die Impulse nicht ordentlich erzeugen kann.
Es bleibt jetzt dann wohl bei den 8MHz, danke euch.

[Frank M. (ukw) (Moderator)]

flux schrieb:
> Da habe ich nicht die Option -flto (wie im Wiki empfohlen) genutzt.

Ja, diese Option optimiert unter anderem den externen Funktionsaufruf in 
der ISR weg, so dass da nicht noch einmal alle Register gesichert werden 
müssen.

> Das legt nahe, dass bei 1MHz die ISR tatsächlich zu oft aufgerufen wird

Ja, dem ist so.

> und deswegen die Impulse nicht ordentlich erzeugen kann.

Deshalb steht im IRMP-Artikel auch:

  "der Prozessor sollte also zumindest mit 8 MHz laufen."

Leider wurde von mir diese Bemerkung nicht in den IRSND-Artikel mit 
übernommen, als die Dokumentation wegen ihrer Länge auf zwei Artikel 
(IRMP und IRSND) aufgeteilt wurde.