Guten Morgen Futaba!

[lxh]

Du wirst sicher selbst schnell merken wo die Grenzen sind. Du musst die Laufzeiten deiner Plug-Ins kennen, um zu wissen, ob du es jeweils schaffst, die neue Servoposition rechtzeitig zu berechnen. Bei deinen Soundgeschichten ist es ziemlich wurscht, wenn die Musik dann plötzlich 5 Tasks später ausgegeben wird, weil jemand ein weiteres Plugin geladen hat. Aber wenn das Servo einfach mal 20ms später losläuft, nur weil ein neues Plug-In geladen ist, dann fände ich das echt ****!

Hi Pike,

also wenn du einem Musiker, der in Echtzeit einen Software-Synth o.ä. in ein bestehendes komplexes Projekt einspielt, solche Verzögerungen aufbrummst, würde er das System vermutlich auch sofort kübeln. Da gebe ich dir vollkommen recht.

Ich habe dieses Beispiel angeführt um zu veranschaulichen mit welcher Daten-FLUT heutige Microprozessoren zurecht kommen können. Die buchstäbliche "Hand voll" Daten einer Sendereingabe incl. aller Mischer (die sich ohnehin quasi nur addieren) sind im Vergleich dazu verschwindend gering. Ein Chip, der spielend 1000 mal mehr Leistung bringt als der Sender erfordert, kann sich folglich auch 999 Takte Zeit nehmen um gemütlich alles abzuarbeiten und beim tausendsten Takt das Ergebnis an das HF-Modul weitergeben.

Glaubst du, dass es derzeit im Sender anders aussieht? Was ich Plugins oder Module nenne, ist nichts anderes als es momentane Funktionen sind. Ich bezweifle ernsthaft, dass die Systemarchitektur rein prozedural aufgebaut ist. Die Plugins würden ja auch entsprechend Compiliert und als solche Systemfunktionen im Hintergrund wieder einfließen. Also wo ist der Unterschied?

Ich habe nie behauptet, dass es die Systementwickler damit leicht haben werden ... für unmöglich halte ich es jedoch nicht.

Gruß, Alex

[Pike]

Wenn du natürlich einen Prozessor verwenden würdest, der 1000 mal mehr Rechenleistung bietet, dann hat der im Prinzip aber auch 1000 mal mehr Leistungsaufnahme und der Kühlkörper muss die 1000 fache Leistung abführen können und der Senderakku bräuchte die 1000 fache Kapazität! Meiner Meinung nach ist die T14 schon ein Unding, weil da viel Rechenleistung in zwei Prozessoren den kleinen Senderakku schon recht schnell leersaugt, was du da planst wäre aber noch extremer.

Ansonsten sind in unseren Sendern keine Prozessoren, sondern Mikrocontroller. Da sie für sog. embedded Systeme ausgelegt sind, haben sie den Vorteil, dass sie die nötige Peripherie wie Flash- und RAM-Speicher, AD-Wandler und Digitalports und vieles mehr bereits auf dem Chip enthalten. Der Nachteil ist, dass ihr Befehlssatz auf absolute Adressen abgestimmt ist. Nach dem Compilieren muss man die Objektdateien noch linken, dabei wird dann Binärcode erzeugt, der nur ab einer bestimmten absoluten Speicheradresse ausgeführt werden kann. Für ein offenes Konzept sind die also unbrauchbar, aber einen richtigen Prozessor nehmen, der dann viele Bauteile um sich rum braucht, das wäre wohl für die Senderbauer erheblich aufwändiger und da wird keiner mitmachen.

[lxh]

Hmmm ... interessante Argumentation. Nur wie kann es sein, dass das Notebook meiner Frau kleiner ist als die T14, länger mit einer Akkuladung läuft, weiter funkt und gleichzeitig noch den Aerofly samt seiner ganzen Flugphysik und Grafikdarstellung (das Modell zugeladen und komplett gemischt) in Echtzeit durchzieht? Erzählst du mir jetzt was geht oder geht es dir hier um eristische Dialektik?

[Pike]

Der Akku des Laptops läuft vermutlich nur dann länger, wenn der Prozessor wenig zu tun hat. Bei voll ausgelastetem Prozessor nimmt er mehr Leistung auf und die Akkulaufzeit sinkt unter die der T14. Und das, obwohl der Akku deutlich mehr Energie enthält, Laptops haben eine höhere Spannung und erheblich mehr Kapazität als die T14. Und kein PC mit Windows-Betriebssystem ist echtzeitfähig. Echtzeitfähig heißt, dass zu einem bestimmten Zeitpunkt eine Berechnung fertig sein muss, es heißt nicht dass das besonders schnell sein muss, aber dass es stets zu einem vorhersehbaren Zeitpunkt fertig ist. Windows und nahezu alle offenen Systeme können das nicht, weil ein fremder Prozess immer einen unvorhergesehenen Teil der Rechenleistung für sich beansprucht. Wenn man alle Prozesse, deren Verhalten und die Rechenleistung kennt, dann kann man abschätzen, aber im offenen System hat man einfach einige unbekannte in der Gleichung.

Wenn der Laptop deiner Frau plötzlich weniger Frames pro Sekunde beim Flugsimulator ausgibt, weil zum Beispiel ein anderes Programm im Hintergrund aktiv wird, dann ist das nicht mehr echtzeitfähig, und unter dem Strich braucht man halt einfach ein vielfaches an Rechenleistung um sagen zu können, in den meisten Fällen wird der Wert schon rechtzeitig das ein, als wenn man die Berechnungen in einer sinnvollen Reihenfolge macht.

Warum glaubst du, haben einige Sender keine freie Zuordnung der Servokanäle? Das liegt daran, dass bei langsamen CPUs während ein AD-Kanal eingelesen wird bereits die ersten Berechnungen des zuvor eingelesenen Kanals durchgeführt werden, und synchron dazu werden die Kanäle nacheinander an das HF-Modul gesendet. Nur wenn man eine sehr viel schnellere CPU einsetzt, dann kann man so schnell sein, dass man alles auf einmal rechnen kann, dann die Kanäle umsortieren kann und schließlich ans HF-Modul geben kann. Die Erfassung der Knüppelpositionen erfolgt aber trotzdem noch nacheinander, aber in der Reihenfolge, wie sie die Geberzuordnung es erfordert.

Dass ein moderner Futaba Sender nach spätestens 14ms nachdem der Knüppel bewegt wurde sein Servo in Gang setzt, das ist ein Ergebnis einer in sich durchdachten und echtzeitfähigen Software. Durch nicht echtzeitfähige Plug-In Lösungen würde das aber unterlaufen werden.

[lxh]

Schau Pike,

eigentlich würde es für den Anfang schon mal reichen, wenn man am bestehenden System die ach so komplizierten Lösungen der vielen Programmierprobleme nicht als Modell, sondern als neue Funktion benennen, speichern, tauschen und wieder zu einem Modell importieren kann. Eventuell noch eine kleine Eingabemaske dazu, um die vielen Untermenüs dieser "Zusammenfassung" zu vermeiden. Das wäre lediglich eine neu angeordnete Abfolge von Boardmitteln. Nenne es Modul, Funktion od. Plugin ... völlig egal. Ich will ja nicht das Betriebsystem 'on the fly' umschreiben.

Ließe sich das Deiner Meinung nach machen?

LG, Alex

[Pike]

Wenn man alle Funktionen, Module bzw. Plug-Ins in eine bestehende Software integrieren würde, und dann die verbergen würde, die nicht aktiv sind ja, also der der die Sourcen hat kann das dann, wir nicht, solange wir nicht eine eigene Software für den Sender komplett aufsetzen würden, was aber auch ein dickes Brett wäre.

Wenn du aber eine beliebige Anzahl verschiedener Funktionen, Module bzw. Plug-Ins von verschiedenen Herstellern miteinander verwenden willst, dann wird es nicht gehen, oder du musst noch bis zur über,- über-, übernächsten Sendergeneration warten, den Rechenleistung braucht heute halt immer noch viel elektrische Leistung! Und mit dem was du vor hast must du Rechenleistung im passenden Moment für viele Module vorhalten.

[lxh]

Also könnte ein System wie die T14, ausgestattet mit einem ganzen Haufen guter Grundfunktionen so aufgebaut sein, dass eine interpretierbare Abfolge dieser Funktionen als neues Modul zugeladen und von jedermann verwendet werden kann. Das ist weder unrealistisch noch würde es die Echtzeitfähigkeit des Systems untergraben. Mittels 'Pseudo'-SDK könnte es vielleicht sogar möglich sein diese Funktionsfolgen zu verlinken und mit Eingabemasken zu versehen. Kannst Du das bestätigen?

[Pike]

Wenn man genügend Zeit investiert, könnte man eine Software schaffen, die anstelle der Futaba-Software dort läuft, und die man über die Speicherkarte hochlädt. Das Windows CE allein handelt aber die Softwarefunktionen nicht, sondern nur die Dateneingabe. Der Aufwand wäre aber immens, insofern sollte man es einfach lassen.

[lxh]

Tja, du hast es erfasst. Ich habe aber auch nicht Dich, sondern Futaba um diese Möglichkeit gebeten. Obwohl arg wärs schon ...

[Pike]

Futaba hat ja bereits eine Software geliefert, nämlich die, die auf den Sendern derzeit läuft. Sie ist zwar in unseren Augen unvollständig, Futaba meint aber, sie wäre genau so umfangreich, dass sie die Bedürfnisse des anspruchvollsten Modellfliegers abdeckt. Was willst du also von Futaba noch erwarten, wenn wir Glück haben, kommt in den nächsten Jahren noch das eine oder andere hilfreiche Softwareupdate, aber mehr würde ich nicht erwarten.

[lxh]

Gut möglich, dass sie es für T12 u. T14 nicht mehr machen. Aber angedacht sollte die Möglichkeit zur Simplifizierung komplexer Methoden meiner Meinung nach schon werden. Denn je mehr der Sender kann, umso unübersichtlicher und komplizierter stellt es sich dem Anwender bei derzeitiger System-Philosophie dar. Für meinen Geschmack - wie Du sicher weißt - ist dieser Funktionsumfang noch weiter ausbaubar, für viele wäre das aber eine erdrückende Flut von Einstellmöglichkeiten, die - wie wir es jetzt auch schon nennen - ans "Programmieren" grenzt.

Warum soll jetzt jemand, der mit Knöpfedrücken nix am Hut hat, nicht auch in den Genuß diverser Neuerungen kommen können? Ganz nach dem mittlerweile alten Softwareprinzip: Einer machts - tausende nutzen es.

Ich frage Dich: Was ist schlecht daran, und was unmöglich? Dafür gibt es sogar einen Ausdruck: "Userfreundlich"

[Pike]

Also im Prinzip ist es doch schon userfreundlich. Wenn ich eingebe, dass ich zum Beispiel nur ein Segelflugmodell mit einem Querruderservo habe, dann wird mir keine Querruderdiffernzierung angezeigt, kein Butterfly angeboten und keine Wölbklappen. Wenn ich dann halt sage ich habe einen Vierklappensegler, dann will ich aber auch alles dazu einstellen können. Wo ist jetzt der Vorteil, wenn ich den Butterfly und die Wölbklappen im Vierklappensegler noch separat freischalten oder laden müsste?

[lxh]

Im Prinzip ist das ja schon der richtige Ansatz - da hast du völlig recht. Nun gibt es aber unter den Modellfliegern mehr und mehr Ideen für Funktionen, die eben NICHT als solche namentlich im Sender zu finden sind und nur über einen Haufen Mischer, Kurven, Finetrimmer und daraus resultierender Querverbindungen zu bewerkstelligen sind. Für die meisten ist sowas der Overkill. Also was spricht dagegen, wenn man den Usern die Möglichkeit gibt solche Funktionsabläufe zusammenzufassen und den Sender auf Wunsch damit zu 'erweitern'?

[Pike]

Weil die derzeit verwendeten Mikrocontroller und die Echtzeitbedingungen keine "planlose" Erweiterung zulassen. Also muss der Ersteller der Software alle möglichen Funktionen vorhersehen. Aber wir drehen uns ab jetzt im Kreis, ein Loch ist im Eimer ...

[lxh]

Nicht ganz. Ich würde sogar behaupten der Kreis schließt sich endlich, denn die Idee ist alles andere als "planlos", sondern buchstäblich "wasserdicht":

Es gibt eine gewisse Anzahl freier Mischer, richtig? Wenn wir jetzt eine Kombination von sagen wir mal drei solcher Mischer zu einer einzigen Funktion zusammenfassen, so wird diese eben drei Mischer-Slots belegen. Warum drehst du dich mit dieser Vorstellung im Kreis?

Klar ... wenn einer zuviele solcher Funktionen zu einem Modell hinzulädt ist irgendwann natürlich Ende der Fahnenstange. Aber alles andere wird reibungslos und im Rahmen der Systemmöglichkeiten in Echtzeit laufen.

Darum bin ich auch unter Anderem so bedacht darauf, dass alles auf Modulbasis laufen soll. Kommt jetzt einer beispielsweise auf den Plan mittels Mischerkombinationen einen neuen und verbesserten Butterfly-Mischer zu entwickeln, wäre es resourcenschohnender und letztlich auch übersichtlicher, den Standard Butterfly-Mischer garnicht erst mitzuschleppen.

Hast mich jetzt?