Hallo!
Ist es bei einem ATmega128 möglich unabhängig von einem Hauptprogramm
z.B. eine LED blinken zu lassen.
Dabei sollte aber das Hauptprogramm z.B. nicht durch einen
Timer-interrupt unterbrochen werden.
Danke für Eure Antworten!
Gruß
Furo
Ja, das ist möglich. LED an Pin OC1A anschließen, T/C1 im CTC-Mode
laufen lassen (Prescaler und Compare Match-Wert der Wunsch-Blinkfrequenz
entsprechend wählen), Output Compare Mode auf "Toggle on Compare Match"
setzen (COM1A1 = 0, COM1A0 = 1). Das Togglen des OC1A-Pins erfolgt
völlig autonom durch die Timerhardware.
>Dabei sollte aber das Hauptprogramm z.B. nicht durch einen>Timer-interrupt unterbrochen werden.
Ich dachte immer, dass gerade das Hauptprogramm durch Interrupts
unterbrochen werden können sollte (weil wenn nicht das, was sonst?)
AVRFan wrote:
> Ich dachte immer, dass gerade das Hauptprogramm durch Interrupts> unterbrochen werden können sollte (weil wenn nicht das, was sonst?)
Ja, genau so isses.
Wer auf Interrupts verzichtet, der verzichtet auf 99% der
Programmiermöglichkeiten.
Insbesondere auf dem großen ATmega128 Boliden kann ich mir keine
Anwendung ohne Interrupts vorstellen (auf nem kleinen ATiny13 vielleicht
mit viel Mühe).
Peter
PWM ist eine schöne Idee, aber leider ist der Port schon belegt..
Das ist ja nicht so, dass ich Interrupts generell nicht will.
ich brauche Sie sogar sehr. Nur wollte ich den µC nicht zusäzlich mit
einer Interrupt belasten, um ein paar Ausgänge zu toggeln.
Da hat die neue Xmega-Serie Vorteile. ;)
Aber ich bin ja erst bei der Ressourcen-Planung. Ich programmier es dann
mal mit Timern. Und mach es über eine Interrupt-Routine. Mal schauen, ob
es irgendwelche Probleme gibt.
Hängt von der Software ab, man könnte Zb an den Uart Port hängen und mit
ganz niedriger Baudrate ab und zu mal (Je nach Programm) Was ausgeben.
-> die LED Blinkt.
Furo wrote:
> PWM ist eine schöne Idee, aber leider ist der Port schon belegt..>> Das ist ja nicht so, dass ich Interrupts generell nicht will.> ich brauche Sie sogar sehr. Nur wollte ich den µC nicht zusäzlich mit> einer Interrupt belasten, um ein paar Ausgänge zu toggeln.
Ein Timer-Interrupt kann mehrere Dinge verwalten. Das bissel LED-Toggeln
(oder gar morsen) macht eine State-machine im Timer-Int nebenbei.
>> Da hat die neue Xmega-Serie Vorteile. ;)
Reize doch erstmal die vorhandenen Systeme aus, ehe Du nach Neuen rufst.
> Aber ich bin ja erst bei der Ressourcen-Planung. Ich programmier es dann> mal mit Timern. Und mach es über eine Interrupt-Routine. Mal schauen, ob> es irgendwelche Probleme gibt.
...
>Der Atmega hat nur noch einen freien Pin: PB0>Der Rest ist belegt.
Und das, was zum Anschluss an PB1 geplant ist, ist bei Deinem aparten
Projekt auch nicht auf PB0 umlegbar, damit PB1 mit der Sonderfunktion
OC1A für die BlinkLED freiwird?
Bist du vielleicht der Meinung, dass man jeden Timer nur für eine
Funktion nutzen kann? Was spricht denn dagegen, den Systemtimer der
meinetwegen in ms zählt zu nehmen und die LED per modulo division
toggeln läßt.
so ala
@AVRFan:
Leider nein. SPI wird genutzt.
@Werner A.:
Ehrlich gesagt kann ich deinem Code nicht ganz Folgen.
Der Systemtimer ist doch auch nichts anders als ein Timer, der bei jedem
Tick den Systemtimer um eins erhöht, oder?
>Der Systemtimer ist doch auch nichts anders als ein Timer, der bei jedem
Tick den Systemtimer um eins erhöht, oder?
Also:
>Der Systemtimer ist .. ein Timer, der ... den Systemtimer ... erhöht
Duck und wech!
>Leider nein. SPI wird genutzt.
Muss mich korrigieren, weil ATmega8 im Kopf gehabt. Berichtigung: OC1A
liegt beim ATmega128 auf PB5. Leg also das, was derzeit an PB5 hängt,
um auf den noch freien PB0. BlinkLED dann an PB5 und über OC1A blinken
lassen.
Problem gelöst :-)
Du schreibst doch dass du die Systemtimer sogar sehr brauchst.
Was machst du denn mit den Timerinterrupts? Eine Variable jede ms eins
hochzählen lassen kostet nicht viel. Die LED-Routine kannst du dann ja
ins Hauptprogramm auslagern.
@Werner A. :
Ich glaub ich steh grad auf dem Schlauch, was versteht man nochmal unter
einem Systemtimer?
@AVRFan:
Vergiss bitte umlöten. Das Layout steht.
Also wenn du den Timer nicht zu schnell Taktest vergehen für den AVR
Tage bis der nächste Interrupt kommt. Da das Blinken wohl für den Mensch
als Signalisierung gedacht ist (daher die Blinkfrequenz soll erkennbar
sein) brauchst du den ja gar nicht so hoch Takten. Wenn dir der größte
Teiler immernoch nicht reicht, schließe nen Uhrenquartz an den
Timer/Counter Oscillator Pins an. Dann bekommst du auch die Interrupts
auf Wunsch auch sekundenweise.
Furo wrote:
> @Werner A. :> Ich glaub ich steh grad auf dem Schlauch,
das glaub ich auch...
>Das ist ja nicht so, dass ich Interrupts generell nicht will.>ich brauche Sie sogar sehr. Nur wollte ich den µC nicht zusäzlich mit>einer Interrupt belasten, um ein paar Ausgänge zu toggeln.
dann erzähl einfach mal was im Moment mit denen machst... wird auch
einer in regelmäßigen Abständen ausgelöst (Timer) oder reagierst du
damit nur auf externe Ereignisse?
Ich reagiere primär auf externe Ereignisse, auf die der Atmega reagiert
und entsprechend "aggiert". Im Moment habe ich noch keine Zeile Code
geschrieben, sondern mach mir grad so ein paar "grundlegende" Gedanken.
Einige Interrupt-Ereignisse, erfordern eine Kommunikation mit einem
weiterem Basutein, gefolgt von einigen Algorithmen.
Mein Gedanke ist, dass ich soviele Algorithmen im µC selbst durchführe,
bevor ich sie weiter schicke. Aus diesem Grund wollte ich soviel
Ressourcen freihalten, wie es geht. Im extrem Fall, kann ich auch die
Berechungen auf ein Minimum reduzieren und alle Komplexen "extern"
Berechnen lassen.
>Vergiss bitte umlöten. Das Layout steht.
Wenn das so ist und Du auch keinen Timerinterrupt verwenden willst,
bleibt als Lösungsmöglichkeit übrig, die BlinkLED-Funktionalität in den
bestehenden Code "einzuflechten" (d. h. ohne einen Interrupt zu
bemühen). Irgendein zeitliches Verhalten wird Deine Software aufweisen;
davon gälte es dann, die Blinkfrequenz durch einen Zähler abzuleiten.
Ob das in Deinem Fall geht, kann Dir allerdings niemand sagen, der den
Code nicht kennt. Das darfst Du Dir also selbst überlegen.
Systemtimer ist nur ein Timer des System...
Benutzt du in deiner bisherigen Software Timer0 Timer1 Timer2 (wenns
den bei dem Prozessor gibt)?
Wenn ja wofür?
"normalerweise" wird ein Timer benutzt, der in einem festen
Zeitintervall aufgerufen wird. Wenn man da noch eine globale Variable
incrementiert ist die Systemzeit schon fertig. Damit kann man dann an
verschiedensten Stellen Sachen zu festen Zeitpunkten machen. Z.b. Tasten
alle 10 ms abfragen, Display alle 100 ms aktualisieren oder halt eben
auch deine LED blinken lassen.
Stell doch einfach mal dein Programm online. Dann wirds glaub ich
einfacher.
(zur Not beschreib mal was das Programm eigentlich macht)
Furo wrote:
> Aus diesem Grund wollte ich soviel> Ressourcen freihalten, wie es geht.
Das ist grundsätzlich falsch.
Nur die Prozesse, die auch merkbare Auslastung bewirken, muß man im Auge
behalten.
Eine Task mit CPU-Auslastung <0,1% muß man nicht wegrationalisieren, die
kehrt man unter den Teppich und gut is.
Eine LED blinken alle 2.000.000 CPU Zyklen ist so eine nicht merkbare
Task.
Peter
1. "Vergiss bitte umlöten. Das Layout steht."
2. "Im Moment habe ich noch keine Zeile Code
geschrieben, sondern mach mir grad so ein paar "grundlegende" Gedanken."
Das scheint mir ein gewagtes Vorgehen ...