parallel Ablauf von Programm-Codes

[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

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]

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:

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

Danke.

Gruß Jens

[uwefed]

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:

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]

500ms sind nicht "sehr klein".

[Knippi]

500ms sind nicht "sehr klein".

Das verzögert die RGB-LED-Funktion von Minuten auf Stunden?

[ardubu]

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]

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.

 

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.