C-Compiler Programmierpaket FIRMWARE 1.24

[hamlet]

Hallo ft-Team,
Vielen Dank, dass Sie eine neue Version des Yagarto-C-Programierpakets für die Firmware 1.24 veröffentlicht haben. Erfreut habe ich festgestellt, dass auch die mathematische Library libm eingebunden ist und nun die Verwendung von floating point Variablen möglich ist, Klasse!
Auch ohne FPU ist die Verarbeitungsgeschwindigkeit von floats brauchbar: Die Berechnung eine Logarithmus benötigt weniger als 20µs, Grundrechenarten sind Faktoren schneller.

Bei Integer-Arithmetik ist der RoboTX in Knaller! Eine binäre Suche nach einer Zahl in einem Array mit 10000 Einträgen ist in weniger als 5µs erledigt. In RoboPro würde eine solche Suche etwa 40ms benötigen (3 Verzweigungen a 1ms * log2(10000)~13 Schleifendurchläufe). => Hierbei wäre RoboPro um einen Faktor >1000 langsamer als die C-Implementation.

Mehr als hilfreich ist die kleine Auswahl an C-Library-Funktionen, die als Function Pointer über die Hook Table der Transfer Area zur Verfügung gestellt werden. Das ist allerdings kein Ersatz für eine komplette C-Lib bzw. die mit der Yagarto Toolchain gelieferte newlib libc, zumal die sprintf-Funktion der Ft/4NetOS-Firmware unvollständig ist: Eine Ausgabe von Floats ist hiermit nicht möglich.
Spaßeshalber habe ich mal direkt die sprintf-Funktion der newlib-libc probiert. Dazu musste ich lediglich den include path erweitern und einen der in "C-Compiler-RoboTXC-V1-1-24-Jan-2012.zip\C_Compiler_RoboTXC\ftMscCComp_V4.4.1.zip\Demo_C\Bin\GNU\YAGARTO\yagarto_newlib.txt" erwähnten Function-Stubs implementieren. Die Implementation taugt allerdings nur für einfache Tests.
=> Die sprintf-Funtion der newlib stellt floats korrekt dar, und ist nur etwa 25% langsamer als die Ft-Version.

Es wäre klasse wenn Sie auch die newLib-libC einbinden könnten. Ist das möglich?

Zumindest nach Aussage der newlib-Dokumentation soll das nicht sehr aufwendig sein.
Eine Funktion wäre dabei besonders wichtig: fprintf logging über USB/BT auf ein serielles Terminal auf dem PC. Das ersetzt zwar keinen echten Debugger, wäre aber sehr hilfreich um komplexere Programme zum Laufen zu bringen. Die kurzen Popup-Logs auf dem TX-Display taugen da nicht viel.

Vor längerer Zeit hatte ich mal das Thema weitergehender Dokumentation angesprochen:

hamlet hat geschrieben:Besteht evtl. die Möglichkeit, dass die fischertechnik GmbH bzw. seine Partner ihren Kunden Dokumentation des RoboTX Controllers und/oder ein API+Doku des 4NetOS zur Verfügung stellen? [...]

Janosch Kuffner hat geschrieben:Diese Anregung wurde an die entsprechende Stelle weitergeleitet. Momentan können wir aber keine Aussage dazu treffen ob bzw. wann eine entsprechende Veröffentlicheung möglich ist.

Gibt es diesbezüglich evtl. Neuigkeiten?

Beste Grüße,
Helmut

[hamlet]

Hallo ft-Team,
Darf ich noch auf eine Antwort hoffen?
Augenblicklich versuche ich einen adaptiven Regler für einen Segway bzw. ein inverses Pendel zu implementieren.
Mit RoboPro funktioniert das nur im Download-Mode, da weder die Geschwindigkeit noch der Jitter der BT-Übertragung eine vernünftige Regelung zulassen, und ein Segway mit USB-Kabel macht auch wenig Sinn. Hierbei stößt man recht schnell an die Grenzen dessen, was man mit RoboPro sinnvoll umsetzen kann. Zunächst einmal musste ich alle Schleifen entrollen und Verzweigungen (1ms Zwangspause) entfernen, damit die Rechenzeit für einen Regelschritt nicht absurd lange im Vergleich zu den 10ms Sampling-Intervall der Messwerte wurde. Das hatte zunächst den Erfolg, dass die Applikation einfach abstürtzte. Vermutlich hatte ich das 500µs Limit weit überschritten.
( Kleine Zwischefrage: Würde das mit Release 3.1.3 noch passieren? Release Notes:- TX Download mode Time Slicing has been enabled. Before the TX did one run through each task per ms Now the TX cycles the task for half a ms each ms. ... hört sich ein wenig nach Preemption an)
Durch Einführung von Wartepunkten im blauen Prozessablauf und blauen, leeren Pseudo-Prozessen (Entry--->Exit, direkt verbunden) in rein orangen Funktionsunterprogrammen, wodurch unnötige Berechnungen verhindert werden, konnte ich das Programm wieder zum Laufen bringen. Der Algorithmus benötigt allerdings immer noch erstaunlich (zu) viel CPU Zeit.
Ich vermute Folgendes:
Mein Programm enthält recht komplexe orange Befehlsnetzwerke mit 48bit floating point Operatoren. (Integerarithmetik mit den lediglich zur Verfügung stehenden 16bit Integers ist recht spaßfrei).
Wäre es möglich in RoboPro 32-bit Integertypen zur Verfügung zu stellen?
Wenn ich das richtig verstanden habe, wird zur Laufzeit ermittelt, ob ein Operator aufgrund einer Änderung am Eingang evaluiert werden muss. Die Berechnungen der Operatoren in einem orangenen Befehls/Operator-Netzwerk erfolgten dann solange bis alle Eingänge/Ausgänge stabil sind. Ohne weitere Optimierungen hinge dabei die Anzahl der Evaluationen allerdings massiv von der Reihenfolge, in der die Operatoren berechnet werden, ab. Wie dem auch sei, falls zur Laufzeit entschieden wird, ob Operatoren noch berechnet werden müssen, könnte das ein Grund für die hohe Laufzeit sein.
Geht Robopro so vor, oder werden schon zur Compile-Zeit Optimierungen angewendet?
Leider kann man in RoboPro nicht nachmessen wie viel Zeit ein bestimmter Programmteil benötigt, da der Zugriff auf die system clock mit ausreichender Genauigkeit (µs oder CPU-ticks)fehlt.
Wäre es möglich in RoboPro eine Möglichkeit zur genauen Zeitmessung zu schaffen?

Der Regler ließe sich natürlich wunderbar in C programmieren. Leider bietet das Framework keine brauchbare Logging-Funktionalität. Ohne die Möglichkeit die Messwerte und die daraus resultierenden Stellgrößen und Zwischenergebnisse z.B. als CSV-Datei auf den PC zu übertragen, ist Realisierung eines funktionierenden Reglers ein ziemlich aussichtsloses Unterfangen.
Wird es in der C-Umgebung ein fprintf logging über USB/BT auf ein serielles Terminal auf dem PC oder etwas Ähnliches geben? (Am besten auch im RoboPro Download-Mode)

Insbesondere für eine Antwort auf meine letzte Frage wäre ich sehr dankbar. Auch ein klares "Nein" ist durchaus willkommen. Dann könnte ich auf eine andere HW (z.B. mbed) umsteigen ohne mich nachher zu ärgern zu müssen, wenn die SW für den TX-Controller doch erweitert wird. Einen Umstieg fände ich sehr schade, aber auch wenn die HW des mbed-Controllers dem TX nicht das Wasser reichen kann, so lassen doch die Dokumentation und die Entwicklungsumgebung einfach viel weniger Wünsche offen.
Mit freundlichen Grüßen,
Helmut

PS: Eine kleine Übersicht geplanter Erweiterungen für RoboPro und die C-Umgebung wäre sehr interessant.

[HartmutKnecht]

Hallo,

den genannten Fragen haben wir inzwischen von unseren Spezialisten folgende Stellungnahmen erhalten:

1. Mail (zur hardwar/C-Programmierung):
a) newlib-libc Funktionen vollständig für Downloadprogramme implementieren
Hie müsste zunächst geprüft werden, ob man nicht die Echtzeitfähigkeit des Gesamtsystems aufs Spiel setzt. Die Download-Programme werden im 1ms-Raster aufgerufen und müssen sich sehr restriktiv daran halten, um eben echtzeitfähig zu bleiben. Da kann nicht alles erlaubt sein, außer man arbeitet wieder mit asynchronen Aufrufen und Callbacks (wie jetzt schon bei den Bluetooth- und I2C-Funktionen, wo es nicht anders geht). Dann kann man Aufrufe über mehrere 1ms-Zeit-Slots verteilt ausführen, allerdings entspricht das auch nicht unbedingt dem Gedanken von Echtzeit, weil es nicht mehr deterministisch ist.

b) sprintf für floating-point-Zahlen erweiteren
Die Floating-Point-Darstellung ist in der Tat zeitaufwendig. Wurde bisher aus Performance-Gründen nicht implementiert. Ob es hier eine echtzeitfähige Möglichkeit gibt, müsste nochmals geprüft werden. Ist auf jeden Fall nicht „mal eben so“ realisiert.
c) Serial Logging (Debug-Ausgaben) über USB/Bluetooth
Implementierung grundsätzlich denkbar, genaue Prüfung über Aufwand erforderlich
d) Zugriff auf 4NetOS von Download-Programmen aus
Antwort: vieles, was theoretisch denkbar wäre (z.B. Zugriff auf das 4NetOS-Dateisystem, pixelweises Schreiben auf das Display usw.) verbietet sich schon aus der Forderung nach der Echtzeitfähigkeit der Download-Programme. Deswegen „dürfen“ Download-Programme eben nicht alles (siehe auch Punkt a). Die Download-Programme sind ein wenig so wie Java-Applets, die auf dem PC im Webbrowser ablaufen. Die dürfen auch lange nicht alles, was theoretisch denkbar wäre (auf dem PC allerdings in erster Linie aus Gründen der Sicherheit). Eine vollständige Offenlegung von 4NetOS ist derzet aus Lizenzgründen nicht möglich.

2. Mail vom 22.4:
Über geplante Softwarefeatures können wir derzeit leider keine verbindlichen Aussagen treffen.
Zu den ROBO-Fragen folgt eine separate Stellungnahme.

Freundliche Grüße
fischertechnik
Hartmut Knecht

[hamlet]

Hallo Herr Knecht,
Vielen Dank für Ihre Antwort!
... und: Oh weh! Nach über zwei Monaten hört sich das ja nicht sehr vielversprechend an:
So viele Konjunktive, und die schon beim "prüfen". Auch kann ich die schon in früheren Beiträgen wiederholt vorgebrachte "Echtzeit/Determinismus"-Begründung Ihrer Spezialisten für das Fehlen von Funktionalität nicht nachvollziehen. Falls es da wirklich technische Hindernisse geben sollte, sind die evtl. eher in der verbesserungsfähigen SW-Architektur der TX-Firmware zu suchen (siehe auch Fords obiger Beitrag zur Kernfunktionalität eines Echtzeitbetriebssystems). Eine C-Library gehört zu einer Entwicklungsumgebung dazu, wie zum Beispiel bei Wind Rivers VxWorks RTOS oder der mbed Umgebung.
Natürlich kann ich nachvollziehen, dass Entwicklung, Wartung und Kundenbetreuung bei RoboPro und der C-Entwicklungsumgebung einen nicht unerheblichen Aufwand darstellen. Vielleicht ließe sich die augenblickliche Situation verbessern, wenn ft in Zukunft mit der Open Source Gemeinde oder einem kommerziellen Partner zusammenarbeitete.
Mit freundlichen Grüßen,
Helmut

PS:

• Serial Logging über USB ist das zweite "Hello World"-Tutorial (nach den blinkenden LEDs) im "Getting Started"-Teil des mbed -Handbooks (http://mbed.org/handbook/Homepage).
• Dort gibt auch noch viele weitere interessante Links: mbed RTOS API, InterruptIn, Memory Model, SPI, ... und erst das Suchergebnis für "camera"!
• Meine erste Frage bezüglich eines mbed Problems wurde innerhalb weniger Stunden samt Bugfix der mbed-Library beantwortet.

[Dirk Haizmann ft]

Hallo,

also ich finde die Antwort von Hartmut Knecht vollkommen in Ordnung und möchte mich auch herzlich dafür bedanken.

Selbstverständlich sind wir jederzeit für Anregungen zur Verbesserung unserer Produkte interessiert und versuchen diese
Wünsche auch stets zu berücksichtigen. Hierbei muss allerdings auch diverse Rahmenbedingungen berücksichtigt werden
die es einfach mit sich bringen, dass wir nicht alles sofort umsetzten können.

Soviel von mir....

ft

[hamlet]

Hallo FT-Team,
für den in meinem letzen Beitrag angeschlagenen arroganten Ton möchte ich um Entschuldigung bitten. Ich war nun mal von der Antwort entäuscht, da ich sie so interpretierte, dass keine der gewünschten Funktionalitäten in absehbarer Zeit zur Verfügung stehen wird. Vielleicht habe ich Sie da auch falsch verstanden.
Ich versuch es nochmal ein wenig konstruktiver:

a) newlib-libc Funktionen vollständig für Downloadprogramme implementieren
Hie müsste zunächst geprüft werden, ob man nicht die Echtzeitfähigkeit des Gesamtsystems aufs Spiel setzt. Die Download-Programme werden im 1ms-Raster aufgerufen und müssen sich sehr restriktiv daran halten, um eben echtzeitfähig zu bleiben. Da kann nicht alles erlaubt sein, außer man arbeitet wieder mit asynchronen Aufrufen und Callbacks (wie jetzt schon bei den Bluetooth- und I2C-Funktionen, wo es nicht anders geht). Dann kann man Aufrufe über mehrere 1ms-Zeit-Slots verteilt ausführen, allerdings entspricht das auch nicht unbedingt dem Gedanken von Echtzeit, weil es nicht mehr deterministisch ist.

Es muss ja nicht vollständig sein: Dateisystemzugriffe, mallocs u.ä. verbieten sich natürlich in dem 500µs slot. Aber einige Funktionalität aus stdlib.h, stdio.h und string.h wären schon sinnvoll: rand, srand, bsearch, qsort, abs, div, sscanf, ...

b) sprintf für floating-point-Zahlen erweiteren
Die Floating-Point-Darstellung ist in der Tat zeitaufwendig. Wurde bisher aus Performance-Gründen nicht implementiert. Ob es hier eine echtzeitfähige Möglichkeit gibt, müsste nochmals geprüft werden. Ist auf jeden Fall nicht „mal eben so“ realisiert.

OK, das ist auch nicht sooo wichtig. Meist kennt man den Wertebereich und kann die floats vor der Darsellung in integer konvertieren. Anbei ein paar Zeiten für die Ausgabe jeweils eines floats bzw. integers:

• integer sprintf (FT firmware, Aufruf über hooktable function pointer): 13µs
• integer sprintf (newlib): 5µs
• float sprintf (newlib): 40µs

c) Serial Logging (Debug-Ausgaben) über USB/Bluetooth
Implementierung grundsätzlich denkbar, genaue Prüfung über Aufwand erforderlich

Nu ja, ich halte das für absolut notwendig.

d) Zugriff auf 4NetOS von Download-Programmen aus
Antwort: vieles, was theoretisch denkbar wäre (z.B. Zugriff auf das 4NetOS-Dateisystem, pixelweises Schreiben auf das Display usw.) verbietet sich schon aus der Forderung nach der Echtzeitfähigkeit der Download-Programme. Deswegen „dürfen“ Download-Programme eben nicht alles (siehe auch Punkt a). Die Download-Programme sind ein wenig so wie Java-Applets, die auf dem PC im Webbrowser ablaufen. Die dürfen auch lange nicht alles, was theoretisch denkbar wäre (auf dem PC allerdings in erster Linie aus Gründen der Sicherheit). Eine vollständige Offenlegung von 4NetOS ist derzet aus Lizenzgründen nicht möglich.

Es muss ja keine vollständige Offenlegung sein:
Die Echtzeit-Probleme könnten umgangen werden wenn man dem Anwender die Möglichkeit gibt, sein Programm auf tasks niedriger Priorität zu verteilen und die Firmware mit harten Echtzeitanforderungen wie gehabt millisekündlich auf tasks hoher Priorität oder auf Interupt Service Level laufen lässt. Das ist natürlich keine kleine Änderung des Designs.
Das "pixelweises Schreiben auf das Display" ist schon jetzt über die TransferArea der firmware möglich.

Über geplante Softwarefeatures können wir derzeit leider keine verbindlichen Aussagen treffen.

Schade! Vielleicht sind ja ein paar unverbindliche Andeutungen möglich?
Mit freundlichen Grüßen,
Helmut

[Dirk Haizmann ft]

Hallo,

ich kann mich leider nur wiederholen: wir arbeiten an diesem Thema!

Mehr kann ich hierzu zum momentanen Zeitpunkt leider nicht sagen.

Schaun mer mal...

ft