Subroutinen und "folding editor"

[Uwe!]

ich glaube. dass ein Teil Deines Verständnisses auch von der HS Welt geprägt wird. Es gibt beim eibpc nicht "verschiedene" Stellen.

Ich denke diese oder ähnliche Probleme haben Viele! Ich hab auch gebraucht, bis ich die Idee hinter der Programmierlogik so einigermaßen verstanden hatte. Im Handbuch habt ihr es an eine Stelle zwar knapp, aber eigentlich recht gut beschrieben. Weiß die genaue Wortwahl jetzt nicht, aber so sinngemäß dass der EibPC ein "Zustandsspeicher" ist und bei jeder Änderung darauf reagiert.
Den HS kenn ich nicht, da kann ich es nicht vergleichen, aber ein "normales" Programm hat erst mal einen Anfang und (wenn ich keine Schleife einbaue) ein Ende.
Ein Programm im EibPC ist eigentlich automatisch eine große Schleife die ständig durchlaufen wird und wo nur an den "relevanten" Stellen (dank des "Zustandsspeichers") Befehle ausgeführt werden.
Meine allerersten Gedanken beim Überfliegen der Befehle war daher auch "da fehlt ja ein DO....WHILE oder ähnliches", aber das brauchts bei diesem Konzept eigentlich nicht.
Aber man muss es erst mal verinnerlicht haben, sonst geht man mit völlig falschen Ansätzen an die Programmierung.

Uwe

PS: Budget ist jetzt gesichert, sobald IP funktioniert, geht die Bestellung raus!
PPS: warum heißt der EibPc eigentlich nicht KNX-PC?

[MatthiasS]

Die "große Schleife" macht auch der HS und quasi jede SPS.


Eingänge lesen, mit dem Zustand vorher vergleichen, Logik ausführen, Ausgänge setzen. Neuer Zyklus....

Die Zykluszeit ist die Zeit, die das Gerät braucht, bei maximaler Auslastung alle möglichen Tasks abzuarbeiten. Deswegen sind im HS Zeiten kleiner als 1 Sekunde nicht empfohlen.

Hardwarenahe Geräte wie eine SPS arbeiten mit Zykluszeiten im ms-Bereich.

[enertegus]

Die "große Schleife" macht auch der HS und quasi jede SPS.
Die Zykluszeit ist die Zeit, die das Gerät braucht, bei maximaler Auslastung alle möglichen Tasks abzuarbeiten. Deswegen sind im HS Zeiten kleiner als 1 Sekunde nicht empfohlen.
Hardwarenahe Geräte wie eine SPS arbeiten mit Zykluszeiten im ms-Bereich.

... wie auch der eibpc im ms-Bereich arbeitet.

Wir arbeiten an einem optimierten Scheduler für diese Schleife, dann sollte wir die Performance nochmals erheblich steigern können, um so den Webserver (mit seinen 100 Seiten oder wieviel das dann auch immer werden) mehr Luft zu verschaffen. Mein erklärtes Ziel ist es, die lästigen Refresh in den 50...200 ms bereich zu drücken, quasi eine Art Echtzeitwebserver.

Aber das ist noch nicht fertig ...

[Uwe!]

Die "große Schleife" macht auch der HS und quasi jede SPS.

OK
Drum sagte ich ja, mit dem HS hab ich keine Erfahrung.

Meine Programmiererfahrung ist eher (in zeitlicher Reihenfolge) Assembler, Basic, Pascal, VB, ABAP.

Und diese Welt hat schon eine ganz andere Logik als ein EibPC (oder eben ein HS)

[enertegus]

Und diese Welt hat schon eine ganz andere Logik als ein EibPC (oder eben ein HS)

Ich denke der wichtigste Unterschied ist die Schleife. Quasi wie wenn um das ganze Programm eine
while(1)
{
}
programmiert wäre.

[bmx]

Hi Michael,

ich hätte da noch ein paar Fragen:

Wann werden denn die Ausgänge/Variablen gesetzt? Direkt nach der Auswertung oder erst im nächsten Zyklus?

Ist es korrekt, das pro Zyklus eigentlich max. nur ein event kommen kann?

Gruß,
Bernd

[enertegus]

Wann werden denn die Ausgänge/Variablen gesetzt? Direkt nach der Auswertung oder erst im nächsten Zyklus?

direkt.

Ist es korrekt, das pro Zyklus eigentlich max. nur ein event kommen kann?

nein, beliebig viele, die seit dem letzten Durchlaufstart hereingekommen sind. (Die danach eintreffen werden bis zum nächsten gepuffert).

Michael

[bmx]

Hi Michael,

Ist es korrekt, das pro Zyklus eigentlich max. nur ein event kommen kann?

nein, beliebig viele, die seit dem letzten Durchlaufstart hereingekommen sind. (Die danach eintreffen werden bis zum nächsten gepuffert).

Aber durch die Schnelligkeit des EIBPC ist das wohl eher unwahrscheinlich, das mehrere während eines Zyklus eintreffen, oder?

Gruß,
Bernd

[enertegus]

Aber durch die Schnelligkeit des EIBPC ist das wohl eher unwahrscheinlich, das mehrere während eines Zyklus eintreffen, oder?

Was KNX betrifft, ja. UDP kann ja ggf. schneller sein. Wofür ist das wichtig?

[bmx]

Für das Begreifen, die Einsicht ;-))

Ich habe zwar schon mit Fortran, C, C++, Basic etc zu tun gehabt, aber noch nie mit SPS.

Gruß,
Bernd

[enertegus]

Für das Begreifen, die Einsicht ;-))

Dann passt ja alles.

[enertegus]

Was KNX betrifft, ja. UDP kann ja ggf. schneller sein.

Ergänzend: Timer objekte, Schaltuhren etc. erzeugen ja auch events. Da man als Mensch gerne gerade Zeiten nimmt, ist die Warhscheinlichkeit von mehreren Events auch nun nicht so gering. Aber dem EibPC macht das auch nix.

[JoeHorn]

Subroutinen [im von Dir beschriebenen Sinn] sind derzeit nicht in Planung.

Hm, schade.

Wir wollten auch keine ganz allgemeine Programmiersprache entwicklen, sondern eine einfache Programmierumgebung, die dem Anwender auch nicht zuviel abverlangt.

OK, leider schränkt das die Freiheiten ein und hier im Forum sind wahrscheinlich überproportional viele Leser mit mehr oder weniger viel Erfahrung im Programmieren mit üblichen PC-Sprachen. Kennt man deren Mächtigkeit fühlt man sich hier ein wenig an die Leine gelegt. Ob die dann am Ende doch mehr als lang genug ist, muß sich ja noch zeigen, daher jetzt erst einmal die Sorge, es könnte eben doch nicht alles möglich sein.
Ich würde mir jetzt als Alternative eine Implementierung in "normalem" C wünschen, die um spezielle Bibliotheken für die besonderen Eigenheiten des EibPCs erweitert ist. Wer dann den Aufwand und das Risiko nicht scheut, hat so viel mehr Möglichkeiten. Die von mir beruflich genutzten Tools zur Simulation von und Anbindung an Steuerbusse (LIN, CAN, Flexray...) haben das so realisiert. Hier wurde gar nicht erst versucht, eine neue Sprache zu entwickeln, der Aufwand war den Herstellern zu groß und C ist einfach von Haus aus schon mächtig genug und mußte einfach nur um einige wenige Funktionen für die Bus-Eigenheiten erweitert werden.
Die äußere Schleife ist allerdings auch hier schon vorhanden, der eigene Code wird eventgetriggert aufgerufen.
Ehrlich gesagt war und bin ich auch jetzt noch verwundert, das man es sich für den EibPC zumindest für den Anfang nicht auch so vergleichsweise einfach gemacht hat, sondern gleich eine eigene Sprache entwickelt. In meiner Arbeitsumgebung ist eine solche Vorgehensweise nach kurzer Zeit wieder aufgegeben worden, es war zu arbeitsintensiv und dennoch nie so flexibel geworden wie der heutige Einsatz einer Standard-Sprache (Java, aber mit C wäre es auch möglich gewesen) mit eigenen Erweiterungen.

Zum Aufblähen:
1. Unsere Testinstallation, an der ich so ziemlich viel unter "normalen" Bedingungen (d.h. bewohnt) teste hat Beschattung, Heizung, Lichter, Doppelclick, Webserver, UDP Telegramme. Dieses Programm erzeugt gerade mal 5.98% der möglichen Objekte.

Nun ja, Winzigweich dachte seinerzeit auch, 64kByte wäre für alle Zeit genug Speicher. Heute wissen wir, der Speicher-wird-knapp-Moment kommt immer schneller als einem lieb ist. Da möchte man ihn wenigstens möglichst weit hinauszögern können.

2. Wenn die Optimierung (Firmware-Scheduler) fertig ist, wird er Compiler automatisch doppelte Ausdrücke entfernen. Es spielt dann absolut keinen Unterschied, ob man 100x oder 1x ein bestimmtes Codefragment aufruft. Im Prinzip funktioniert ja auch die Subroutinengeschichte so.

OK, wenn es dann wirklich funktioniert, kann man damit wohl leben.

Ehrlich gesagt, hätten wir
1. das nicht vermutet, dass dies jemand ernsthaft machen will.
2. das Handbuch, das ja für "jedermann" gedacht ist, nicht mit zu schweren Ballast füllen wollen.
3. Wenn jemand das so machen will, unterstütze ich ihn von hier soweit möglich.

1. Doch, wenn man das als lebendes Projekt betrachtet, das ständig angepasst werden wird, dann wird man schon gerne eine ausgewachsene Umgebung nutzen wollen. In meiner Arbeitsumgebung verdrängt Eclipse gerade alle anderen bislang genutzten Entwicklungsumgebungen.
2. Vielleicht sollte man es trennen in einen Teil für eilige Anfänger, für normale Anwender und für Experten. Die ersten beiden Teile existieren ja im Prinzip schon, in den letzten kommen dann jene Infos, die für den normalen Anwender nur Ballast darstellen würden, den engagierten aber die Freiheiten geben, die sie bislang vermissen.
3. Das bitte einfach auch schriftlich fixieren, dann ist Teil 3 auch bald fertig.

... wie auch der eibpc im ms-Bereich arbeitet.

Wir arbeiten an einem optimierten Scheduler für diese Schleife, dann sollte wir die Performance nochmals erheblich steigern können, um so den Webserver (mit seinen 100 Seiten oder wieviel das dann auch immer werden) mehr Luft zu verschaffen. Mein erklärtes Ziel ist es, die lästigen Refresh in den 50...200 ms bereich zu drücken, quasi eine Art Echtzeitwebserver.

Aber das ist noch nicht fertig ...

Die fehlenden Schleifen und Sprungbefehle haben mich auch zunächst gewundert. Die äußere kann einiges ersetzen, ob aber verschachtelte Konzepte sich so immer umsetzen lassen muß sich noch zeigen. Andererseits muß man die Laufzeit der äußeren im Auge behalten, da können innere Schleifen und wilde Sprung-Orgien (Spaghetti-Code) schnell Ärger bereiten.
Hier sollte der Entwickler etwas mehr Einfluß nehmen können, wie er die Rechenzeit auf konkurrierende Jobs verteilen möchte. Falls das für Otto-Normal-Nutzer zu kompliziert erscheint, könnte man dafür ja einen Experten-Modus schaffen. Der erfordert dann mehr Einarbeitung und schafft mehr Fehlerquellen, bietet aber auch mehr Freiheit. Viele PC-Tools arbeiten ja auch so.
Ein einziger großer Task ist sicher nicht immer optimal, da Teile des Codes ggf. noch häufiger aufgerufen werden sollten (die, die unmittelbar auf Nutzereingaben reagieren), andere sich dagegen vergleichsweise viel Zeit lassen dürfen (z.B. FBH-Steuerung). Ggf. sind auch Prioritäten hilfreich, damit der Entwickler angeben kann, was ihm im Falle einer "Überlast" am Wichtigsten ist und was dann auch mal länger warten kann. Bislang hat ja wohl alles die gleiche Prio und ggf. läuft dann alles etwas langsamer. Bei entsprechender Auslastung ist das aber wohl nicht mehr wünschenswert.
Auch wenn in bisherigen Tests die Auslastung nur bei 6% lag und die Schleife gerade mal 1ms benötigt, kann sich das schnell ändern, wenn Anwender erst einmal ihre Fantasie angekurbelt haben. Es wäre gut, wenn dann Konzepte vorhanden wären, die das dann flexibel handhaben können. Sicher, die erfordern u.U. mal etwas mehr Mitdenken des Entwicklers, führen dann aber auch zu praxistauglicheren Ergebnissen.
Und wie gesagt, es soll ja nur möglich sein, wer es nicht braucht und bequem haben möchte kann ja bei einer Task mit einer Prio und schwankenden Laufzeiten bleiben.

[enertegus]

Die von mir beruflich genutzten Tools zur Simulation von und Anbindung an Steuerbusse (LIN, CAN, Flexray...) haben das so realisiert. Hier wurde gar nicht erst versucht, eine neue Sprache zu entwickeln, der Aufwand war den Herstellern zu groß und C ist einfach von Haus aus schon mächtig genug und mußte einfach nur um einige wenige Funktionen für die Bus-Eigenheiten erweitert werden.

Da kann ich nur sagen: Wenn's danach geht, hätten wir auch nen Crosscompiler zur verfügung stellen können und jeder hätte selber kompilieren können, zu was er lustig ist.
Das ist konzeptionell einfach was ganz anderes. Wir haben die Ottonormalkunden im Visier. Ggf. gibt es für das von Dir gewünschte Konzept sowas wie misterhouse etc.

Die äußere Schleife ist allerdings auch hier schon vorhanden, der eigene Code wird eventgetriggert aufgerufen.
3. Das bitte einfach auch schriftlich fixieren, dann ist Teil 3 auch bald fertig.

Dazu muss man konkrete Fragen stellen. Ich sehe das überhaupt nur als Unterstützung für Experten an. Also gibt es kein Handbuch. Die Tools haben eine Kommandozeilenausgabe der Funktionen und mit dem EibStudio zusammen sieht man eigentlich, wie das ganze zu bedienen ist.

Hier sollte der Entwickler etwas mehr Einfluß nehmen können, wie er die

Der Entwickler macht das ja, nur sind das wir.

Ggf. sind auch Prioritäten hilfreich, damit der Entwickler angeben kann, was ihm im Falle einer "Überlast" am Wichtigsten ist und was dann auch mal länger warten kann. Bislang hat ja wohl alles die gleiche Prio und ggf. läuft dann alles etwas langsamer. Bei entsprechender Auslastung ist das aber wohl nicht mehr wünschenswert.

Der KNX Zugriff hat Priorität. Ich habe mal mein System auf 50% Auslastung gehieft- da war kein Problem vorhanden. Klar, der Webserver wurde etwas zäh (4 Sekunden für Refresh).

Es wäre gut, wenn dann Konzepte vorhanden wären, die das dann flexibel handhaben können.

Das ist der Scheduler. Er wird mehr als nur ein Rezept, er ist die Medizin für etwas was bisher überhaupt nicht problematisch war: Performance. Er ist die Droge, welcher den EibPC sehr schnell machen wird im Hinblick auf den neuen Webserver (dazu heut abend beim Stammtisch Franken mehr).

Michael

[Uwe!]

Da kann ich nur sagen: Wenn's danach geht, hätten wir auch nen Crosscompiler zur verfügung stellen können und jeder hätte selber kompilieren können, zu was er lustig ist.
Das ist konzeptionell einfach was ganz anderes. Wir haben die Ottonormalkunden im Visier.

Zum Glück! Wenn es nicht so simple in der Bedienung wäre, wäre es für mich sicher nicht so interessant. Dann Hätte ich vermutlich auch eher die Zeit genutzt mich in Misterhouse, eibd und wie das alles heißt einzupfriemeln. Ich finde das von euch gewählte Konzept perefekt!