Go Down

Topic: parallel Ablauf von Programm-Codes (Read 3775 times) previous topic - next topic

Knippi

Hallo , mal wieder.

Ich Kämpfe gerade an einem Problem, zweier Programm-Codes in einen Code umzusetzen.

Ich habe ein Programmablauf, in dem ich 10 Temperaturfühler auslese und ab einen festgelegten Wert hier
Quote
if(aktuelleTemp >= 50)
  {
    if(fanOut == 1)
50 Grad einen PWM-Ausgang temperaturgesteuert zu erhöhen und abzusenken. Dieser Ausgang steuert eine KSQ, die wiederum 10 Lüfter drehzahlabhängig steuert.

Ich wollte nun beide Codes zusammenführen und in einem Programm ablaufen lassen.

Leider passiert nun folgendes:

Der Farbverlauf des RGB-LED-Strip beginnt in seiner Funktion erst, wenn alle Werte im Display angezeigt wurden und setzt auch erst jedesmal nach einem Displaydurchlauf seine Funktion fort. D.h. es dauert Stunden bis ein kompletter Farbverlauf durchgeführt ist.

Mir ist irgendwie klar, dass der Farblauf durch den Programmablauf der Temp./Display-Anzeige verzögert abläuft, finde aber keine Lösung, dieses zu ändern.

Gibt es eine Möglichkeit und wenn ja welche, die beiden Programmabläufe parallel ablaufen zu lassen oder mache ich nur einen Gedanken/Umsetzungsfehler?

Vielen Dank schon mal. :)

Gruß Jens

Knippi

Hier die Codes:


RudiDL5

Moin,
im Grunde kannst du deine beiden Codes natürlich zusammenführen und als ein Sketch laufen lassen... Aber nur solange die beiden Programme sich nicht gegenseitig behaken und blockieren!

Ein Blick allein in die "Temp_Display" zeigte mir, dass innerhalb "while(u <= 10)" ein allgemein bekanntes und hochgiftiges "delay(500)" drin ist. Das ist absolut niederschmetternd für dein Programm. Hier solltest du deine Sketch-Philosophie evtl. komplett überdenken und vollkommen neu zusammenbauen.

Sorry für diese Antwort, aber ich habe anfangs auch extrem viele Probleme damit gehabt, und dann hatte mir dieses Tutorial die Augen geöffnet, wie man (fast) echte Parallel-Verarbeitung programmiert:

https://www.arduino.cc/en/Tutorial/BlinkWithoutDelay

Gruß, Rudi

ardubu

#3
Mar 15, 2016, 10:12 am Last Edit: Mar 15, 2016, 12:49 pm by ardubu
du aktualisierst dein LCD bei jedem Loopdurchlauf. Es würde reichen, zu aktualisieren, wenn sich etwas ändert.
Edit: z.B. das Datum nur einmal je Tag, dann kannst du dir auch das delay sparen

Helmuth

Ich würde eine HSV Tabelle für den Regenbogen-Farbwechsel benutzen. Z.B. die von FastLED. Diese würde ich mit millis() verknüpfen.

Code: [Select]
CRGB led = CHSV( millis() / 2, 255, 255)

led.r, led.g und led.b kannst Du an 3 Pins via PWM ausgeben.

Vorteil davon: Egal, wie oft und egal wie zeitlich ungleichmäßig (wg. mal LCD schreiben, mal nicht) Du diese Zuweisung machst - der Farbverlauft läuft immer mit konstanter Geschwindigkeit.

Gruß, H.

Knippi

Vielleicht könnte einer der Administratoren einmal die drei Codes in der Code-Box im Thread  zur Anzeige bringen.

Bei mir kam es immer zu einer Fehlermeldung:

Quote
The message exceeds the maximum allowed length (9000 characters).
Danke.

Gruß Jens

uwefed

Quote
Vielleicht könnte einer der Administratoren einmal die drei Codes in der Code-Box im Thread  zur Anzeige bringen.
Nein, kann ich auch nicht.
Grüße Uwe

Knippi

Hallo,

danke für eure Antworten.

@RudiDL5:
Quote
Ein Blick allein in die "Temp_Display" zeigte mir, dass innerhalb "while(u <= 10)" ein allgemein bekanntes und hochgiftiges "delay(500)" drin ist. Das ist absolut niederschmetternd für dein Programm. Hier solltest du deine Sketch-Philosophie evtl. komplett überdenken und vollkommen neu zusammenbauen.
Das ist ja mein Problem. Ich probiere es mittlerweile seit Tagen und zerbreche mir den Kopf und komme zu keinem Ergebnis.

Warum ist die  "while(u <= 10)" Funktion mit dem sehr kleinen delay-Wert von (500) so ein Problem?

Die Anzeigen des Datum und die Temperaturen, sollen schon 1-1,5 sec. im Display ablesbar bleiben. Nur wie kann denn die RGB-LED-Stripe Funktion parallel ablaufen, bzw. wie müssen die Display-Anzeigefunktionen umgeschrieben werden, dass die RGB-LED-Stripe Funktion trotzdem ablaufen kann.

Gruß Jens

Serenifly


Knippi

Quote
500ms sind nicht "sehr klein".
Das verzögert die RGB-LED-Funktion von Minuten auf Stunden?


ardubu

Quote
Die Anzeigen des Datum und die Temperaturen, sollen schon 1-1,5 sec. im Display ablesbar bleiben.
solange du sie nicht löscht oder überschreibst bleiben sie lesbar

Knippi

Es ist ja eine Routine, die nach einem Durchlauf wieder von vorne startet und die Werte mit neuen Werten zur Anzeige gebracht wird.


RudiDL5

#12
Mar 15, 2016, 03:10 pm Last Edit: Mar 15, 2016, 03:23 pm by RudiDL5
Quote
500ms sind nicht "sehr klein".
    .
    .
    .
    Das verzögert die RGB-LED-Funktion von Minuten auf Stunden?
Ohne deinen Code jetzt "genau" analysiert zu haben behaupte ich dennoch einfach mal : JAA!!!

Denn:
Im 2. Sketch "Fade_RGB_ ..." ist eine wunderbare Routine, die das Faden mittels millis() regelt. Keine Ahnung wie die "fadeZeit" dort gesetzt ist. Aber das Programm geht an dieser Stelle mit einer "affenartigen" Geschwindigkeit drüber und nur alle paar Millisekunden (je nach fadeZeit) wird eine andere Aktion ausgelöst. Es setzt also an DER Stelle vorraus, dass die Haupt-loop mit ca. 2 Mhz darüber jagt.

Nun machst du aber bei JEDEM einzelnen Fade-Schritt im oberen Teil 1 - 1,5 Sekunden Pause... DORT liegt doch dann der Hase im Pfeffer.

Dreh doch den Spieß einfach um: Lass die "Fade-Geschichte" mit ihrer HighSpeed durch den µC rauschen und aktualisiere das Display ebenfalls in einer eigenen "millis"-Routine. Dort kannst du dann alle paar Sekunden bei z.B. "negativer Flanke" einer "BetriebsLED" kurz das Display ansprechen.

Ich mache das immer nach folgendem Muster:

Code: [Select]

void loop()
{
  if( millis() - mS >= 1000 )
    {
      mS = millis();                        // mS = irgendwo oben unsigned long
      digitalWrite( 13, !digitalRead(13) ); // 13 ist meine "BetriebsLED"
      if( !digitalRead(13) )
        { /* aktualisiere Display (z.B.) */ }
    }
  // Hier dann alles andere...
}



das is nur meine bescheidene Meinung
Rudi


RudiDL5

*Nachbrüller*
Ich selbst "zwinge" mich generell (!) zu dieser "BetriebsLED". Dadurch erkenne ich sofort, ob alles rund läuft oder ob der µC irgendwo in den Streik getreten ist...
 ;)


Noch einer... Ich sehe gerade, dass "fadeZeiten" durch "zeiten[]" gesteuert wird. Dort sind Werte mit 1000 und so. Multipliziere mal diese Zeiten mit deinen Display-Delays ...


Knippi

Dann kann ja nur das Problem mit der Datum/Uhrzeit-Anzeige zusammen hängen, da nur dort "while(u <= 10)" + 'delay(500)' verknüpft ist.

 
Quote
led.r, led.g und led.b kannst Du an 3 Pins via PWM ausgeben.
Der RGB-LED-Driver, der die LED-Stripe steuert hat einen eigenen Sketch (siehe oben) LedStripDriverLibrariesforArduino1.0+.zip

Dort wird nicht direkt mit 3 Pins die drei Grundfarben gesteuert, sondern durch zwei (CIN+DIN) Eingänge.
Deshalb würde auch der FastLED-Sketch nicht funktionieren.

Go Up