On Device Programming: C vs Python

[borg]

Es gibt JVMs die klein genug sind für die Bricks, z.B. http://www.rtjcom.com/main.php?p=ovr

 

Absolut ausgeschlossen ist java also nicht. Diese JVM braucht aber z.B. einen ClassLinker der vorher auf dem PC die Klassen "zusammenhämmert", um sich da das dynamische laden zu sparen.

 

Dieser ist natürlich nur für Windows verfügbar...

 

Die JVM benötigt von Hardware Seite aus eine Timer mit 5-20ms Intervall, was dann 50-200 Nachrichten pro Sekunde bedeuten würde...

 

Ich befürchte das zu integrieren wäre eine Katastrophe. Ich denke es läuft auf zwei Möglichkeiten hinaus: Eine einfache interpretierte Sprache (die sich vernünftig in unser System integrieren lässt) oder C.

 

Ersteres könnte der schon angesprochene Mini-Python-Interpreter sein oder vielleicht sogar ein kleines auf die Bricks abgestimmtes BASIC. Das könnte dann direkt ein Keyword für die Callbacks haben und für das hinzufügen von Callbacks usw.

 

 

@The_Real_Black: Wir haben in Summe in allen Firmwares zusammen vielleicht 15 Zeilen Assembler geschrieben. Du brauchst definitiv kein Assembler um die Bricks zu programmieren. Ich würde auch bezweifeln, dass du ab einer gewissen Codegröße auch nur annähernd so gut optimieren kannst wie ein moderner C Compiler .

[FabianB]

Ich fasse die Problematik zur Übersicht nochmal aus meiner Sicht zusammen.

Ich denke, die für uns wichtigen Aspekte bei der On-Device-Programmierung sind:

• Kein PC muss angeschlossen sein
  
• Höhere Genauigkeit und geringere Verzögerung in den Programmen möglich
  

Diese beiden Ziele sollen erreicht werden unter Einhaltung dieser Bedingungen:

• Extrem leichte Verwendbarkeit/Programmierbarkeit
  
• Keine/Geringe Zusatzkosten für Extra-Hardware
  
• Kompatibilität zu anderen bekannten Techniken (außerdem soll das Rad nicht neu erfunden werden)
  

Die Lösungsvorschläge:

• Hochsprache wie Java etc. (Vorteil: Einfach anzuwenden, Kompatibilität; Nachteile: Wahrscheinlich Hardwarekosten, z.T ungenauer bzw. langsamer als C)
  
• Verbesserte API in C: (Nachteil: Schwieriger umzusetzen für Einsteiger; Vorteile: Keine Zusatzkosten, Sonst sind alle weiteren Zielsetzungen erfüllt)
  
• ...?
  

Welche Lösungen/Vor- oder Nachteile habe ich vergessen? Bitte ergänzen.

 

 

 

 

Wenn ich mir den Stand der Dinge so ansehe komme ich wieder zur These eines meiner älteren Posts: Man sollte versuchen, die Vorteile von C zu nutzen und den Nachteil der schwierigeren Anwendbarkeit durch eine geeignete Umsetzung ausmerzen.

 

Für mich sähe diese Umsetzung so aus:

Man bekommt eine API bzw. eine Art Framework in C, dass dem Programmierer die bekannten Funktionen in der Einfachheit der Hochsprachen-APIs zur Verfügung stellt. Der Benutzer soll nur noch auf Hochsprachen-Niveau programmieren müssen und sich nicht mehr im geringsten mit Hardware-naher Programmierung befassen müssen. Die notwendigen Implementierungen sind bereits alle in der Firmware enthalten. Der Programmierer programmiert nur noch im Stile der Arduino-Sprache, die Benutzungsprinzipien von Objektorientierung sollen erhalten bleiben.

 

Das fertige Programm kann man per Copy-Paste in eine markierte Stelle in der Firmware kopieren und flasht diese auf ein Brick. DIeser Vorgang könnte durch eine eigens angefertigte Software von TF stark vereinfach werden, sodass man nur noch seinen Quellcode in ein Textfeld kopiert und diese Software alles weitere übernimmt, sodass man nur noch den fertig lauffähigen Stack vom Rechner abziehen muss und der loslegen kann. Diese Software kann einen auch beim Eintragen der notwendigen UIDs unterstützen etc.

Abgerundet werden müsste das durch eine knackige Dokumentation.

 

Ich bin der Ansicht, dass das Programmieren in der Arduino-Sprache für jeden Hobby-Programmierer auf Anhieb möglich ist, vor allem, wenn alle Funktionen zum Benutzen der Bricks/Bricklets so gestaltet sind, wie sie z.B. bei Java aussehen. Dieser Lösungsansatz verbinden in meinen Augen alle Vorteile. Keine Extrakosten, einfache Anwendbarkeit, hohe Geschwindigkeit...

 

 

Ist verständlich geworden, wie ich mir das vorstelle? Wie seht ihr das? Was spricht dagegen? Technisch halte ich das für umsetzbar, seht ihr Schwierigkeiten?

 

EDIT:

 

Ich meinte nicht, dass man wirklich die Arduino-Sprache verwenden MUSS. Man kann auch bei C/C++ bleiben. Nur muss dass dann so vereinfacht anzuwenden sein, dass es so leicht ist, wie das Programmieren mit der Arduino-Sprache.

 

 

EDIT 2:

Das könnte auch so gestaltet sein, dass es die aktuelle Firmware ergänzt, man also nicht zwei verschieden Firmwares parallel haben muss. Die Firmware muss beim Starten halt erkennen, ob ein PC mit ihr kommuniziert oder ob sie standalone läuft.

[borg]

Das könnte auch so gestaltet sein, dass es die aktuelle Firmware ergänzt, man also nicht zwei verschieden Firmwares parallel haben muss. Die Firmware muss beim Starten halt erkennen, ob ein PC mit ihr kommuniziert oder ob sie standalone läuft.

Wäre es denn akzeptabel wenn weiterhin nur 1000 Nachrichten/Sekunde durchs System laufen? Weil das würde es bedeuten wenn die normale Firmware verwendet wird.

 

Eine Lösung, die das bestehende System benutzt und wo in C programmiert wird wäre mit Abstand der geringste Aufwand für uns. Da könnte man einfach die C Bindings nehmen, das Backend austauschen durch ein direktes Schreiben in die internen Buffer und fertig .

[FabianB]

Wäre es nicht möglich, die Anzahl der Nachrichten/Sekunde anzuheben, wenn erkannt wird, dass der Stack standalone läuft? Wäre es nicht möglich, den Geschwindigkeitsbeschränkenden Faktor der Firmware redundant auszulegen, so dass jeweils die geeignete Variante (Am PC -> langsam, standalone -> schnell) verwendet wird?

Wenn nicht, hätte dieser Kompromiss einen bitteren Nachgeschmack. Soweit ich das sehe, ist eine höhere Nachrichtenrate vor allem für Implementierungen relevant, die genauer arbeiten sollen (CNC-Fräsen im Eigenbau oder sowas) Da kommt man ab einer gewissen Komplexität des Stacks recht schnell an die 1000N/s.

Es sollte ja gerade einer der Vorteile der On-Device-Programmierung sein, eine höhere Geschwindigkeit/Genauigkeit zu erreichen.

 

 

ICh denke auch, dass diese Variante für euch am schnellsten zu realisieren ist. Allerdings würde ich nicht unterschätzen, dass es da viel Detailaufwand geben dürfte, um das auch wirklich Nutzerfreundlich zu gestalten. MAn muss soweit es irgendwie sinnvoll realisierbar ist jede Auseinandersetzung mit der Hardware vermeiden.

[borg]

Wäre es nicht möglich, die Anzahl der Nachrichten/Sekunde anzuheben, wenn erkannt wird, dass der Stack standalone läuft? Wäre es nicht möglich, den Geschwindigkeitsbeschränkenden Faktor der Firmware redundant auszulegen, so dass jeweils die geeignete Variante (Am PC -> langsam, standalone -> schnell) verwendet wird?

Ohne groß ins Detail zu gehen: Das ist nicht möglich. Mehr Nachrichten im kompletten System = Komplett neue Firmware.

 

Mehr Nachrichten auf dem Brick, der Standalone läuft und 1000 Nachrichten/Sek im Rest des Systems (Stack Kommunikation etc) wäre noch denkbar.

 

ICh denke auch, dass diese Variante für euch am schnellsten zu realisieren ist.

Ist halt die Frage wie weit man das treiben will. Die C API auf den Master Brick zu bringen wie oben angedeutet und zu dokumentieren geht schnell. Aber was ist mit der Entwicklungsumgebung? Welche soll man unter Windows nehmen? Und auf dem Mac? Wie kommt man an den Source Code? Master Brick Firmware und bricklib auf github clonen? Usw usw.

 

Das fällt alles weg wenn wir eine interpretierte Sprache nehmen. Auf dem PC schreiben, auf das Brick laden und dort wirds interpretiert. Fertig .

[benatweb]

Ich unterschreibe FabianB's Ausführungen einfach mal, besser könnt ichs sowieso nicht ausdrücken.

 

Letztendlich geht es bei der OnDevice-API ja schließlich darum, dass man anstatt Tinkerforge am PC nur noch Tinkerforge allein hat. Letztendlich wird man also in den allermeisten Fällen außer sicher ein paar math. Berechnungen beim Programmieren nicht mehr als Tinkerforge-Funktionen brauchen. Und dafür ist es nunmal herzlich egal, was unter der API für eine Programmiersprache liegt, mit der hat man ja dann (bis auf die Syntax) fast nix zu tun. (Ich programmier seit ner Weile Arduinos - mehr als die Arduino-Referenz hab ich dazu nie gebraucht...) Klar ist C keine einsteigerfreundliche Sprache, klar wäre Java auf dem Brick langsam, usw. Aber wenn Tinkerforge darüber eine sinnvoll gebaute, gut dokumentierte und einfach zu benutzende API legt, haben wir mit dem darunter glaube ich nicht viel mehr zu tun als jetzt, wenn wir das nicht wollen.

 

 

Eine Lösung, die das bestehende System benutzt und wo in C programmiert wird wäre mit Abstand der geringste Aufwand für uns. Da könnte man einfach die C Bindings nehmen, das Backend austauschen durch ein direktes Schreiben in die internen Buffer und fertig .

Wäre ich dafür.

 

Edit:

@borg Könntet ihr dafür nicht ein Tool anbieten, das man mit seinem Quellcode (einfach reinkopieren) füttert und das dann den Quellcode mit der Firmware und was sonst noch dazu muss zusammenführt und auf den Brick schreibt. Also quasi analog zur Arduino-IDE. Oder ist das zu viel Aufwand?

[FabianB]

Die "Entwicklungsumgebung" würde ich in den Brick-Viewer einbauen, die muss auch nicht wirklich mehr können als ein Textfeld zur Aufnahme des Quellcodes anbieten, automatisch die aktuellsten Firmware-Quellcodes von euch runterladen, das zusammenpacken und flashen.

Den Quellcode schreiben kann dann jeder in seiner gewohnten IDE, das Ergebnis dann per Copy-Paste in das Textfeld.

 

 

Zur Nachrichtengeschwindigkeit: An die anderen, was stellt ihr euch denn als erstrebenswerte Geschwindigkeit vor?

Eine komplett neue Firmware zu schreiben wäre aufwändig, aber würde sich das unterm Strich nicht lohnen?

[borg]

Die "Entwicklungsumgebung" würde ich in den Brick-Viewer einbauen, die muss auch nicht wirklich mehr können als ein Textfeld zur Aufnahme des Quellcodes anbieten, automatisch die aktuellsten Firmware-Quellcodes von euch runterladen, das zusammenpacken und flashen.

Den Quellcode schreiben kann dann jeder in seiner gewohnten IDE, das Ergebnis dann per Copy-Paste in das Textfeld.

 

Sorry, aber das ist einfach keine Lösung. Dafür müsste der Brick Viewer dann die komplette GCC Toolchain mitbringen. Und wie soll das funktionieren? Man braucht ja schließlich ein paar Anläufe bis der C Code kompiliert. Wie bekommt der Nutzer denn die Compilefehler mitgeteilt? Einfach in einem Popup, ohne Syntax Highlighting ohne alles? Das ist doch ein Albtraum. Wer würde sowas benutzen wollen?

[FabianB]

Stimmt, das habe ich nicht bedacht.

Dann muss dieser Vorgang ausgelagert bleiben und jeder verwendet die Software, die er gewohnt ist. Eine entsprechende Doku muss den Vorgang dann erklären.

 

 

Insgesamt bleibe ich aber erstmal bei dem Grundprinzip. :-)

[raphael_vogel]

Wer ist denn schon an die Grenze von über 1000 Nachrichten pro Sekunde gestoßen? Gibt's den Usecase überhaupt oder will man da was bauen das für 99% der Fälle eh nicht relevant ist?

[The_Real_Black]

Zur Nachrichtengeschwindigkeit: An die anderen, was stellt ihr euch denn als erstrebenswerte Geschwindigkeit vor?

Je schneller desto besser. Wenn man auf die Hardware Ebene geht sollte man auch alles aus den Bausteinen hohlen was geht. Besonders in Richtung "bewegte Teile" Fräse oder Roboter ist eine schnellere Verarbeitung immer besser. Wenn ich X mal öfter in der Sekunde eine Kollisions\Positionsprüfung durchführen kann würde ich diese Lösung bevorzugen.

 

Kann man irgendwie "Echtzeitverarbeitung" garantieren?

Mit C/Assembler sollte es möglich sein die maximale Reaktionszeit des Systems zu berechnen.

Ist dies mit einer "interpretierten" Sprache/Java auch möglich?

 

*Echtzeit: im Sinne von "die meiste Zeit" berechenbares Verhalten im ms Bereich.

[benatweb]

Also ich bin auch dafür, hohen Nachrichtendurchsatz zu haben, allerdings meiner Meinung nach nicht auf Kosten der OnDevice-API. Heißt, ich wäre eher dafür zweistufig in naher Zukunft überhaupt eine API zu haben auch wenn sie nicht schneller als jetzt ist und eine neue Firmware erst danach anzugehen. Ich geh ja mal davon aus, die komplette Firmware neu zu schreiben ist für Tinkerforge auch mit einem gewissen Risiko verbunden. (Die Zeit, die das braucht gibt es ja weiterhin keine OnDevice-API und das wird sicher auch sonst Ressourcen abziehen)

[raphael_vogel]

Je schneller desto besser. Wenn man auf die Hardware Ebene geht sollte man auch alles aus den Bausteinen hohlen was geht.

Für mich ist on-device nicht gleichzusetzen mit "auf die Hardware Ebene gehen".  Genau das will ich nicht haben.

 

Was ich jedoch will ist ein Programm ohne PC auf den Bricks direkt laufen zu lassen. 

[AuronX]

@Borg: Ihr müsst natürlich wissen, ob eine neue Firmware nciht aus anderen Gründen nötig/sinnvoll ist. Im Raum steht noch die Frage was mit den 1000 Nachrichten/s ist, wenn ich WiFi oder Ethernet nutze (sollte beides mehr können wenn ich nicht falsch liege), das wäre dann nämlich mehr als "nur" das OnDevice-Programming.

 

@The_Real_Black: Du kannst auch in Java ziemlich zuverlässig bestimmen mit welcher Ausführungszeit du es zu tun haben wirst. Klassischerweise steht dem eher die Hardware oder das Betriebssystem im Weg, ein Interrupt hier, ein Prozesswechsel da... Auf so einem kleinen Brick sollte das Betriebssystem keine Rolle mehr spielen, da ich nicht glaube, dass es hier Präemptives Scheduling (also Unterbrechung deines Codes für einen anderen "Prozess") gibt. Interrupts werden aber vermutlich noch immer für Unterbrechungen sorgen.

 

Im Sinne deiner Definition (meistens und Millisekunden) sehe ich allerdings keine Probleme.

 

P.S.: Die exakte "Berechnung" der Ausführungszeit ist m.E. nichtmal bei C möglich. Auch dort kann ja der Compiler beliebig optimieren und Assembler schubsen. Selbst bei der Berechnung von Assembler wirds dann schon schwierig, wenn du auf moderne Prozessoren stößt (Google-Stichworte: Pipelining und Branch-Prediction)

 

edit:

Für mich ist on-device nicht gleichzusetzen mit "auf die Hardware Ebene gehen".  Genau das will ich nicht haben.

 

Dito

 

editeditedit: Für mich liegt noch immer die vermutung nahe, dass es hier zwei Zielgruppen gibt:

1. Zielgruppe: Ich will das gleiche machen wie vorher nur ohne PC (-> High-Level)

2. Zielgruppe: Ich will die optimal an mich angepasste Ausführung des Code und einem verwalteten Speicher würde ich lieber nicht trauen (-> C, Assembler... ein wenig Op-Code )

[borg]

@Borg: Ihr müsst natürlich wissen, ob eine neue Firmware nciht aus anderen Gründen nötig/sinnvoll ist. Im Raum steht noch die Frage was mit den 1000 Nachrichten/s ist, wenn ich WiFi oder Ethernet nutze (sollte beides mehr können wenn ich nicht falsch liege), das wäre dann nämlich mehr als "nur" das OnDevice-Programming.

Naja, ein Getter-Aufruf wird immer mindestens so lange brauchen wie die Pingzeit und die wird nie unter 1ms sein (bei Wi-Fi/Ethernet).

 

P.S.: Die exakte "Berechnung" der Ausführungszeit ist m.E. nichtmal bei C möglich. Auch dort kann ja der Compiler beliebig optimieren und Assembler schubsen. Selbst bei der Berechnung von Assembler wirds dann schon schwierig, wenn du auf moderne Prozessoren stößt (Google-Stichworte: Pipelining und Branch-Prediction)

Der Cortex-M3 hat ja einen Thumb2 Befehlssatz, in dem sind alle Befehle 16 Bit groß. Dadurch können immer zwei Befehle gleichzeitig geladen werden und dadurch dauert nahezu alles einen Takt. Auch die Sprungvorhersage. Das macht natürlich das Takte zählen einfach.

 

editeditedit: Für mich liegt noch immer die vermutung nahe, dass es hier zwei Zielgruppen gibt:

1. Zielgruppe: Ich will das gleiche machen wie vorher nur ohne PC (-> High-Level)

2. Zielgruppe: Ich will die optimal an mich angepasste Ausführung des Code und einem verwalteten Speicher würde ich lieber nicht trauen (-> C, Assembler... ein wenig Op-Code )

Jo.

 

 

Ich glaube wir müssen das mal anders angehen: Was wollt ihr denn Standalone mit den Bricks machen?

[FabianB]

Mehr Nachrichten auf dem Brick, der Standalone läuft und 1000 Nachrichten/Sek im Rest des Systems (Stack Kommunikation etc) wäre noch denkbar.

 

 

Die Tendenz scheint mir so langsam doch in Richtung C-API zu gehen. Der zitierte Vorschlag von Borg klingt ja nach einem guten Kompromiss: Nicht super-schnell aber auch nicht so hardware-nah.

C-API schnell realisierbar  für TF, keine extra Hardware, wenn die API gut wird wirds leicht anwendbar, die Umsetzung wird nicht hardwarenah sondern "high-level-on-device", es gibt keine Einschränkungen wie bei der (leicht) eingeschränkten Python-Lösung.

Sehe ich das so richtig?

 

 

@Borg: Könntest du uns eine Vorstellung davon geben, wie viele Nachrichten/Sekunde "Grundrauschen" sind? Gibts überhaupt welches? Damit meine ich, wie viele Nachrichten bei einem vollen Stack (8 Master, 32 Bricklets) bei hergestellter Verbindung aber ohne ausgeführten weiteren Code pro Sekunde laufen. Damit man eine Einschätzung hat, wie viele Nachrichten man pro Sekunde noch "frei" hat. Das wäre unabhängig von dieser Diskussion interessant.

 

 

 

 

In der Zwischenzeit kam das hier rein:

Ich glaube wir müssen das mal anders angehen: Was wollt ihr denn Standalone mit den Bricks machen?

Guter Vorschlag.

Ich würde damit gerne mal eine CNC-Fräse selber bauen. Einziger Grund für mich das on-device zu regeln wäre, dass ich mir davon eine höhere Genauigkeit verspreche.

Ursprünglich hatte ich mal vor, einen Quadrocopter selber zu bauen. Da wäre es auch gut, auf einen PC verzichten zu können. Dafür sollten allerdings die 1000 N/s noch so gerade ausreichen (weiß ich aber nicht so genau).

 

 

Für alle anderen Anwendungen wie KLimaüberwachung mit Temperature, Humidity LCD etc. wäre standalone auch super, weil man sich einfach den PC sparen kann und das mobiler ist. Für solche Sachen reichen aber die 1000N/s locker aus. Dafür wäre die leichte Anwendbarkeit das wichtigste Kriterium.

Die Frage ist, welcher Anwendungstyp häufiger genutzt wird. Ich vermute, unterm Strich werden die einfachen Sachen häufiger umgesetzt.

[ArcaneDraconum]

Was wollen wir machen?

Ich sehe es auch als Raumthermometer mit LCD-Anzeige und Relais, um bei Erreichen bestimmter Werte etwas zu schalten. Event. ersatzweise ein IO4, damit könnte man ja schon 4 Betriebszustände via LED anzeigen.

Eine Ausbaustufe höher wäre, wenn dieser Stack via WLAN Extension die Aussenstation abfragen könnte.....

[raphael_vogel]

@FabianB: Warum braucht man den mehr als 1000 Nachrichten/s für eine CNC Fräse?

Das Argument "je mehr desto besser" zieht ja immer. Ich hätte gerne mal ein wirklich stichhaltiges Argument für mehr als 1000 Nachrichten/s.

Hab mich mit dem Thema CNC noch nicht befaßt, aber ich denke dass hier eher mechanische Faktoren (das Spiel der Spindel?) eine Rolle für die Genauigkeit spielen.

Und für einen Raumthermometer mit LCD Anzeige und Relais + WLAN oder Ethernet braucht man sicherlich nicht mehr als 1000 Messungen/s.

 

Sicherlich gibt es Projekte wo man mehr als 1000 Nachtichten brauchen könnte, aber ich denke das sind deutlich weniger als 5% der Leute hier.

 

@TF: Ihr solltet euch genau überlegen ob der ROI (return on invest) bei so einer Aktion mit komplett neuer Firmware hoch genug ist. Wieviel neue Kunden bekommt ihr, wenn mit hohem Aufwand eine komplett neue Firmware entwickelt wird um dann für 10 Leute mehr als 1000 Nachrichten/s zu ermöglichen ?

Wäre die Zeit (Manpower) nicht sinnvoller in andere Bereiche investiert die mehr zur Verbreitung und den Umsatz von TF sorgen ?

 

Edit:

Naja, ein Getter-Aufruf wird immer mindestens so lange brauchen wie die Pingzeit und die wird nie unter 1ms sein (bei Wi-Fi/Ethernet).

Und wenn man das noch in Betracht zieht, dann relativiert sich die Forderung nach mehr als 1000 Nachrichten/s noch mehr. Ich denke dass relativ viele Projekte Wifi/Ethernet verwenden werden.

[rifmetroid]

Moin,

kurze Nachfrage zu der WIFI/Ethernet Diskussion.

Warum sollte ich die nutzen, wenn ich das Programm OnDevice laufen lassen kann?

Die einzige Sache, die mir dazu einfällt, wäre es Sachen zu visualisieren, aber da ist wohl klar, dass man dafür keine 1000 Nachrichten pro Sekunde benötigt.

In jedem Steuerungssystem ist das genauso, der schnell laufende Steuerungsprozess läuft auf der Hardware direkt und stellt nur ein Prozessabbild nach außen dar, damit das Ganze auch angezeigt werden kann und dabei ist es relativ egal, ob ich 1000 oder 500 Nachrichten pro Sekunde habe, so schnell bekommt der bedienende Mensch das gar nicht mit.

 

Von daher finde ich diese Diskussion zu WIFI/Ethernet etwas überflüssig. Ich würde gerne meinen Stack OnDevice füttern und Steuerungsprozesse unter 1ms ablaufen lassen, freunde mich aber erstmal auch gerne mit der maximalen 1ms an, wenn es denn erstmal überhaupt geht. Dann möchte ich das Ganze aber auch von außen bedienen können, da ist mir aber die Geschwindigkeit nicht so wichtig, es muss halt nur bedienbar sein (WIFI, USB, Ethernet).

 

Oder habe ich da jetzt falsch gedacht oder etwas übersehen?

 

Gruß

rif

 

EDIT:

Warum ich 1000 Nachrichten oder mehr pro Sekunde benötige? Ich nutze  Tinkerforge um Echtzeitsteuerungssysteme zu testen (TF ist da etwas leichter als 300T Stahl). Ich bastel mir aus TF einen Simulator der einfach elektrische Signale generiert, die dann aber zeitlich ungefähr dem entsprechen sollten, was der echte Stahlkoloss produziert und da sind wir leider schon im Bereich von unter 1ms. Aber jetzt geht es auch mit 1ms schon recht gut. Das ganze noch OnDevice und dann einfach mit nem Handy und der WIFI-Extension bedienbar, das wäre der Knaller.

[ArcaneDraconum]

@Raphael_Vogel: Ich habe NIE erwähnt, dass ich 1000 und mehr Nachrichten pro Sekunde benötige. Mir ging es um eine Anwendung für On_Device_Programmierung. Für mich persönlich würde eine Nachricht pro Sekunde locker reichen. So stürmissch geht es in meinem Wohnzimmer nicht zu, dass sich die Messwerte derart dramatisch ändern würden. Auch eine Heizung benötigt einige Zeit, bis sich die warme Luft im Raum verteilt hat. Wenn ich da minütlich alle Sensoren abfrage ist das eigentlich schon overkill.

[FabianB]

Ich hätte gerne mal ein wirklich stichhaltiges Argument für mehr als 1000 Nachrichten/s.

[...]

Und für einen Raumthermometer mit LCD Anzeige und Relais + WLAN oder Ethernet braucht man sicherlich nicht mehr als 1000 Messungen/s.

Sicherlich gibt es Projekte wo man mehr als 1000 Nachtichten brauchen könnte, aber ich denke das sind deutlich weniger als 5% der Leute hier.

 

 

 

Das erste haben die anderen schon beantwortet. Den Rest deiner Aussage sehe ich ebenso und hatte das ja auch schon angedeutet:

Für alle anderen Anwendungen wie KLimaüberwachung mit Temperature, Humidity LCD etc. wäre standalone auch super, weil man sich einfach den PC sparen kann und das mobiler ist. Für solche Sachen reichen aber die 1000N/s locker aus. Dafür wäre die leichte Anwendbarkeit das wichtigste Kriterium.

Die Frage ist, welcher Anwendungstyp häufiger genutzt wird. Ich vermute, unterm Strich werden die einfachen Sachen häufiger umgesetzt.

 

 

Ich bin auch der Meinung, dass man zuerst die Mehrheit bedienen sollte. Es ist in der Summe halt nur eine Niesche, in der man was schnelleres braucht. Deswegen bin ich halt dafür, eine einfache C-API zu machen:

 

 

C-API schnell realisierbar  für TF, keine extra Hardware, wenn die API gut wird wirds leicht anwendbar, die Umsetzung wird nicht hardwarenah sondern "high-level-on-device", es gibt keine Einschränkungen wie bei der (leicht) eingeschränkten Python-Lösung.

[\quote]

[borg]

@Borg: Könntest du uns eine Vorstellung davon geben, wie viele Nachrichten/Sekunde "Grundrauschen" sind? Gibts überhaupt welches? Damit meine ich, wie viele Nachrichten bei einem vollen Stack (8 Master, 32 Bricklets) bei hergestellter Verbindung aber ohne ausgeführten weiteren Code pro Sekunde laufen. Damit man eine Einschätzung hat, wie viele Nachrichten man pro Sekunde noch "frei" hat. Das wäre unabhängig von dieser Diskussion interessant.

Da gibt es kein Grundrauschen. Das ist eigentlich auch ganz einfach: Es gibt Empfangsbuffer für die Schnittstellen (z.B. USB) und die werden alle einmal pro ms geleert.

 

Und diese Taktrate von 1ms ist das Maximum was wir mit FreeRTOS sinnvoll erreichen können. D.h. wenn wir niedriger wollten müssten wir das Scheduling von FreeRTOS rauswerfen, dann müssten neue Firmwares her.

 

Wir benutzen im Moment ein "echtes" Scheduling, d.h. Funktionen werden inkl. lokaler Variablen auf den Stack gepackt und später wieder geholt usw. Das Scheduling ist lediglich nicht preemptive, damit wir uns die ganzen mutexes sparen können. Ich könnte das durch Umsetzen einer Konstante preemptive machen.

 

Wenn wir jetzt Dinge mit einer höheren Taktrate als 1KHz haben wollen, können wir einfach kein "echtes" Scheduling mehr verwenden (Der Verwaltungsaufwand wäre dann zu hoch). D.h. Anstatt einen Scheduler zu haben, hätte man eine Main-Loop die nacheinander alle benötigten Funktionen aufruft. Dadurch hat man dann den Scheduling Overhead nicht mehr. Gleichzeitig hat man dann aber im Prinzip keine lokalen Variablen mehr, die werden ja nicht mehr gesichert. D.h. man müsste ein Speichermanagement einbauen mit dem man dynamisch speicher allokieren/freigeben kann. Im ganzen heißt das, wir brauchen eine neue Firmware und der interne Aufbau muss anders sein.

 

Ich hoffe das Erklärt grob warum es diese 1000 Nachrichten/Sek Grenze gibt und warum wir viel Arbeit haben wenn es mehr seien sollen.

[FabianB]

Danke für die Erklärung, das war sehr hilfreich.

Ich habe noch keine Meinung dazu, ob das Scheduling geändert werden sollte. Aber ich bin immer überzeugter davon, dass ihr bei dieser Firmware bleiben solltet. Das Verkauf/Leistung Verhältnis würde einen hohen Aufwand nicht rechtfertigen.

Holt einfach das Beste und einfachste aus den gegebenen Möglichkeiten raus. Der Knackpunkt für den Erfolg der OnDevice API ist eh, ob sie einfach zu verwenden ist.

[rifmetroid]

Ich würde auch definitiv sagen die 1000 Nachrichten pro Sekunde sind momentan genug. Viel wichtiger ist das man erstmal überhaupt die Möglichkeit bekommt, OnDevice zu programmieren (dann aber schon die 1000 Nachrichten ausreizen sollen könnte -> C-API).

Falls es dann wirklich mal Anwendungen gibt, die eine höhere Auflösung erfordern, kann man immer noch daran arbeiten. Wobei ich denke, dass solche Anforderungen hauptsächlich aus der Industrie kommen werden und die dann evtl. auch ein bißchen Geld dafür locker machen würden.

[Nic]

Die JVM benötigt von Hardware Seite aus eine Timer mit 5-20ms Intervall, was dann 50-200 Nachrichten pro Sekunde bedeuten würde...

Für eine integr. JVM im Brick wurden max. realistische 200 N/s genannt.

 

Ist der Benchmark von max 1000 N/s nur über eine C-basierte OnDev-API gewährleistet oder auch durch den Phyton-Interpr. im Brick machbar?