Kann man während einer PWM noch nebenbei was auf dem Display anzeigen!?

>Optimal wäre natürlich Assembler für den Interrupt.

Lächerlich. Ein schlechtes Assemblerprogramm
ist auch nicht schneller als das was der C Compiler
mit Optimierung rausholt. Wenn man ein bisschen
was drauf hat ist der Unterschied vieleicht 5%.

> Hat jemand in der Richtung schon einmal sowas gemacht oder kann mir
> einen Tipp geben, wie die parallele Abarbeitung (PWM und Display)
> handeln könnte!?

Sicher.

Ob per Interrupt oder beide nacheinander in der Hauptschleife ist 
letztlich egal, so oder so muß der Prozessor die nötigen Instruktionen 
abarbeiten, aber mehere Ereignisse quasi gleichzeitg zu beachten und zu 
bearbeiten ist Standard bei der Microcontrollerprogrammierung, man macht 
es eben schnell zeitverschachtelt.

Wenn jemand auf die Idee kommt, in solchen Jobs längere 
warte-Zeitschleifen durchzuziehen oder auf Ereignisse zu warten, schon 
verloren, längere Tätigkeiten müssen eben in kürzere Einzelaktionen 
unterteilt werden.

holger schrieb:
> Ein schlechtes Assemblerprogramm
> ist auch nicht schneller als das was der C Compiler
> mit Optimierung rausholt. Wenn man ein bisschen
> was drauf hat ist der Unterschied vieleicht 5%.

Träum weiter.

>holger schrieb:
>> Ein schlechtes Assemblerprogramm
>> ist auch nicht schneller als das was der C Compiler
>> mit Optimierung rausholt. Wenn man ein bisschen
>> was drauf hat ist der Unterschied vieleicht 5%.
>
>Träum weiter.

Naja, wenn du meinst. Ich hab da so meine Erfahrungen.

>Naja, normalerweise sind C-Compiler schon sehr gut, nur im Falle einer
>ISR muss der Compiler, will er denn standardkonform sein, beispielsweise
>alle Register sichern, da er nicht wissen kann, welche denn in der ISR
>benötigt werden, etc.

Nö, muss er nicht. Der weiss durchaus welche Register benutzt
werden. Wenn man so dumm ist eine Funktion in einem Interrupt
aufzurufen dann muss er natürlich alle Register sichern.
Das ist aber nicht immer so. Bei den schlappen ATMega vieleicht;)

Das gilt dann aber nicht konsequent für alle C Compiler.
Es kommt auf den Prozessor an den du benutzt. Ein Cortex M3
sichert seine Register in Hardware wenn ein Interrupt
aufgerufen wird. Der Compiler hat da überhaupt nichts mit zu tun.

Alles Ansichtssache.

Hy Leute,

danke erstmal für die mehr oder wenig hilfreichen Kommentare.

Die angehängten Dateien sind nett gemeint, aber ich schreibe in C.

Trotzdem Respekt, das du da nen überblick drinne behältst, da hätte man 
ja auch unterprogramme in die Main einbinden können.

Nochmal zu meinem Problem:

Nachdem alle Parameter:
   - Anzahl der Anzusteuernden Ports (LEDs)
   - Zeit, z.B. 10sek.
eingegeben sind, wird derzeit der/die entsprechenden PIN/s high und es 
wird danach in die Routine "Countdown" gesprungen, welche dann die Zeit 
runter zählt und auf dem Display ausgibt. Hier ein kleiner Auszug davon:

if (LED_Wert_1 == 1)
{
PORTD = 0x01;
fertig_1=Countdown(Zeit_Wert_1);          break;
}
else if (LED_Wert_1 == 2)
{
PORTD = 0x03;
fertig_1=Countdown(Zeit_Wert_1);          break;

Nachdem die Zeit abgelaufen ist und die Countdown beendet ist, wird 
diese verlassen und der/die PIN/s zurückgesetzt.

Meine Frage nun wie kann ich die PWM eventuell in die nachfolgende 
Countdown integrieren!? Kann man das in die Countdown mit rein machen?

char Countdown(int Zeit_Wert_2)
{
char str_8[1];
char str_9[2];
char Ende =0;
char Minuten_1 = Zeit_Wert_2/60;
char Minuten = Minuten_1;
char Sekunden_1 = Zeit_Wert_2-(Minuten*60);
char Sekunden = Sekunden_1;

char Tastenspeicher_8 = PINB;

  while((Tastenspeicher_8 != 0x6F) && (Ende == 0))
  {
  Tastenspeicher_8 = PINB;
  Sekunden = Sekunden-1;
  if((Sekunden == 255) && (Minuten==0))
  {
  Sekunden=0;
  Minuten =0;
  Ende = 1;
  PORTD=0x00;
sprintf(str_8,"%01d",Minuten); lcd_set_cursor (2, 0); lcd_write (str_8);
sprintf(str_9,"%02d",Sekunden); lcd_set_cursor (2, 5); lcd_write 
(str_9);
_delay_ms(1000);
  }
  else if((Sekunden == 255) && (Minuten >=0))
  {
  Sekunden = 59;
  Minuten = Minuten-1;
sprintf(str_8,"%01d",Minuten); lcd_set_cursor (2, 0); lcd_write (str_8);
sprintf(str_9,"%02d",Sekunden); lcd_set_cursor (2, 5); lcd_write 
(str_9);
_delay_ms(1000);
  }
  else
  {
  Sekunden = Sekunden;
  Minuten = Minuten;
sprintf(str_8,"%01d",Minuten); lcd_set_cursor (2, 0); lcd_write (str_8);
sprintf(str_9,"%02d",Sekunden); lcd_set_cursor (2, 5); lcd_write 
(str_9);
  _delay_ms(1000);
  }
}
PORTD=0x00;
return Ende;
}

Ich freue mich auf eure Meinungen.

Mik-X schrieb:
> Die angehängten Dateien sind nett gemeint, aber ich schreibe in C.
Die Hoffnung dabei war wohl, dass du beim Lesen, quasi als passiven 
Wortschatz, über multilinguale Kompetenz verfügst ;-)

Mik-X schrieb:
> _delay_ms(1000);

Wenn du deinen Prozessor im Hauptprogramm so blockierst, bleibt für PWM 
eine Interruptsteuerung (was sowieso sinnvoll wäre) oder, falls die 
Anzahl der Hardware-PWM-Kanäle vom ATmega16 reicht noch einfacher, die 
direkt Steuerung durch die Hardware.
Wieviel LEDs mußt du denn ggf. steuern?

>  _delay_ms(1000);
> Ich freue mich auf eure Meinungen.

Es wurde bereits gesagt, daß Delay-Schleifen der vollkommen falsche 
Ansatz sind, wenn man mehrere Jobs quasi gleichzeitg nebeneinander 
erledigen will.

Der vollkommen falsche Ansatz.

holger schrieb:
> Lächerlich. Ein schlechtes Assemblerprogramm
> ist auch nicht schneller als das was der C Compiler
> mit Optimierung rausholt. Wenn man ein bisschen
> was drauf hat ist der Unterschied vieleicht 5%.

Und wieder ein sinnloser Kommentar. Daumen hoch!

Diese Funktionen wie "_delay_ms(1000)" gehören verboten.

Nur Ärger damit und keinerlei sinnvollen Nutzen.

1. stimmt die angegebene Zeit nie.
   Schließlich werden ja Interrupts nicht rausgerechnet.
2. Ist der µC für andere sinnvolle Funktionen blockiert


Alternative :
HW Timer nutzen.
1. Macro erstellen das die 1000msec in die systembedingten Timertakte 
umrechnet.  (Abhängik der Timer configuration und SystemTakt)
2. Timer mit diesem Wert starten und Interrupt einschalten.
3. In der Interruptroutine die nächste Anweisung antriggern aber NICHT 
im Interrupt ausführen. zb über ein Flag

Keine Ahnung, welche µC ihr hier für PWM so benutzt. Ich hätte ja 
geglaubt, ein integriertes PWM-Peripheral sei heute Standard.

Selbst in meinen 15 Jahre alten 8051-Derivaten SAB80C517A habe ich eine 
16-bit-PWM-Unit. Sie arbeitet, einmal initialisiert, völlig losgelöst 
von der CPU. Nur bei Änderungen muß man noch mal z.B. ein 
Compare-Register beschreiben. Damit kann man also dann alles andere 
bedienen, ohne die PWM-Unit weiter zu berücksichtigen.

> Keine Ahnung, welche µC ihr hier für PWM so benutzt. Ich hätte ja
> geglaubt, ein integriertes PWM-Peripheral sei heute Standard.

Joo ich wüsste auf Anhieb keinen µC ohne , bis auf minimalste Version 
wie vielleciht die kleinen Tiny's.

ABER diese PWM zu nutzen bedeutet ja Datenblätter zu lesen. Timer zu 
programmieren.
Und auf einmal vielleicht sogar zu denken.

Für viele ist das eindeutig zu viel Anspruch.

Guten Abend,

mir genügen die bei Atmega16 vorhandenn 4 PWM Ausgänge nicht, ich 
benötige 8 PWM Kanäle.

Die Wartezeiten mit der Delayfunktion sind unkritisch. Jedoch 
hinderlich. Werde Sie daher gegen eine Timerfunktion ersetzen.

Werde die Hinweise und Ratschläge beherzigen und ein wenig 
experimentieren.

>Diese Funktionen wie "_delay_ms(1000)" gehören verboten.
Genau. Es sei denn 'delay' wird in einem RTOS so verwendet, dass es 
nicht den Prozessor (mit bekloppten Schleifenbefehlen) blockiert.

> Ein Cortex M3 sichert seine Register in Hardware wenn ein Interrupt
> aufgerufen wird.
Auch CM3 muss die Register auf den Stack legen, was Takte kostet.
Register-File wäre da viel schneller, aber das hat der CM3 nicht.

MCUA schrieb:
> Auch CM3 muss die Register auf den Stack legen, was Takte kostet.
> Register-File wäre da viel schneller, aber das hat der CM3 nicht.

Wenn eine Anwendung diese paar Takte benötigt ist sowieso was 
Grundlegendes falsch gelaufen.

Entweder ist das Software Design sowas von Müll,...

Oder der µC ist vollkommen falsch ausgewählt worden.

Einen Wohnungsumzug macht man ja auch nicht mit einem Smart weil der 
gerade da ist, sondern mit was größerem.

>Wenn eine Anwendung diese paar Takte benötigt ist sowieso was
>Grundlegendes falsch gelaufen.
Von wegen.
Einige uCs brauchen dafür (um in den INT zu schalten) 4 Takte andere 
100...

> Damit wären gar kein registerkopieren mehr nötig.

Doch.

Wen du nämlich 2 geschachtelte Interrupts zulässt,
zulassen musst weil die Anwendung das so erfordert.

Das mit den zweiten Registersatz hatte schon der
ehrwürdige Z80.

Und auf universelleren Maschinen mit genug Registern
hat man einfach in der Interrupt-Routine andere
Register verwendet als im normalen Programm, schon
muß man die nicht mehr retten.

> ABER diese PWM zu nutzen bedeutet ja Datenblätter zu lesen.
> Timer zu programmieren.

Oh Ralph, DIESE PWM zu verwenden bedeute vor allem,
alle <x> LED leider nur gleichhell leuchten lassen zu können,
weil man nämlich für <x> LED eigentlich <x> solcher
Hardware-PWMs bräuchte.

>Eigentlich böte sich an die Register allesamt mit einem
>Schattenregisterstapel zu versehen.
>Jede INT schiebt dann den Registersatz komplett um eine Position nach
>hinten und stellt einen neuen leeren Registersatzbereit um dann zur
>Int_adresse zu springen.
>Bei reti sollte dann alle aktuellen register mit den letzen Eintrag der
>Schattenregiser beschrieben werden.
>Das ist sicher in einem Takt zu erledigen.
Kein Mensch macht einen Schattenregisterstapel!
Entweder man benutzt Schattenregister oder einen Stack.
Schattenregister kommen einem RegisterFile gleich, wobei die Frage immer 
ist, wie viele Registersätze dort aufgenommen werden können. (1...?) 
(Sparc-Prozessoren hatten sehr viele davon) Ein Registersatz-wechsel 
geht sehr schnell, typ 1..2 Takte (im Vergleich zu zig Takten bei 
verschicken auf den Stack).
Reicht das RegisterFile (mit >=1 Registersätzen) nicht aus, muss man 
halt  auf den Stack sichern, aber das dauert.


>Aber ich wette das wird längst so gemacht.
wie gesagt, total falsch.

MCUA schrieb:
>>Wenn eine Anwendung diese paar Takte benötigt ist sowieso was
>>Grundlegendes falsch gelaufen.
> Von wegen.
> Einige uCs brauchen dafür (um in den INT zu schalten) 4 Takte andere
> 100...

Und wenn die IRQ's gerade gesperrt sind wegen..... dauert es noch 
länger.
Und genau deshalb ist ein Design das auf Takte rechnen muss damit es 
funktioniert grundsätzlcih Müll.

Soviel Luft muss bei der Auslegung der Hardware / Software mit 
einkalkuliert werden.

Sonst wird das NIE ein stabiles System.

>Und wenn die IRQ's gerade gesperrt sind wegen..... dauert es noch
>länger.
>Und genau deshalb ist ein Design das auf Takte rechnen muss damit es
>funktioniert grundsätzlcih Müll.
Schonmal was von Echtzeit-Anwendung gehört?

MCUA schrieb:
> Schonmal was von Echtzeit-Anwendung gehört?

Ja klar.
Aber 1. geht es hier nicht um ein Real Time OS
Und 2. Wird ein Real Time OS niemals so aufegabut das es Takte zählen 
muss um zu funktionieren. ==> Damit wäre es kein Real Time Os mehr.

Aber 1. geht es hier nicht um ein Real Time OS
Doch. auch hier ist es Realtime. Denn die PWM ist Realtime-App (wen auch 
recht langsam).

Aber, es gibt HardRealTime-Anwendungen, wo's natürlich auf Takte 
ankommt, und da is nix mit IRQs sperren!
Manche uC's können das erfüllen, manche nicht.
(zB waren die ersten MIPS- u. PowerPC-uCs diesbezügl katastrophal)

>Ruhig Blut du Kochst ja schon vor Aufregung ...
Deswegen? Nein.

>der klug µC würde sich schlafen legen und auf dn nächsten IRQ warten.
wenn das mal nicht zu lange dauert