AuronX

Erster Draft: https://github.com/Tinkerforge/brickv/pull/7 Habe es noch nciht ausprobiert, könnte also auch noch vom Interpreter abgelehnt werden. Ich muss zunächst noch die requirements installieren und es dann wirklich ausprobieren ^^

Did you check these answers http://www.tinkerforge.com/en/doc/FAQ.html#one-of-my-bricklets-doesn-t-show-up-in-the-brick-viewer ? (especially re-flashing and setting UID)

@Loeti: Es muss ja nicht SSH sein. Du musst halt irgendwie aus der Ferne dieses Tool aufrufen und ihm die passende Datei liefern. Das bringt auf jeden Fall schonmal neue Möglichkeiten, auch wenn es noch nicht vollkommen von TF bequem angeboten wird. Beim Drücken des Knopfes bin ich allerdings auch überfragt ^^ Aber ich vermute mal jemand Lötfreudiges wie du kann doch sicherlich "mal eben" nen IO4 mit dem Reset-Taster verbinden oder? Dann kannst du mit dem IO4 nen Brick-Suizid begehen... Dass es den Commandline-Wunsch schonmal gab ist mir übrigens glatt entgangen ^^ @borg: Wenn ich die samba-lib modifiziere und Unsinn mache kann mein Brick trotzdem nicht gebrickt werden oder? ^^

Hallo, so wie ich das sehe, kann ich mein Brick doch bisher nur über den Brickv flashen, richtig? Es wäre großartig, wenn dieser Teil auch über ein Commandline-Interface (neues Tool) verfügbar wäre. So in der Art: SHELL> flash-tool COM1 myImage.img Das würde eine Integration in eine beliebige IDE, CI usw ermöglichen.

Das könnte man lesen als: "Es sollte ein Commandline-Tool geben, um das flashen durchzuführen". Das würde ich sofort unterschreiben, es sollte auch ohne Brickv gehen. Allerdings komme ich damit glaube ich auch auf ein neues Thema. Ich eröffne mal einen zweiten Thread.

Die Anzahl der Nutzer die keinen PC haben, nicht programmieren wollen ABER TF nutzen halte ich für vernachlässigbar. Was ist das für eine Zielgruppe? Nichts programmieren oder selbst anpassen aber ne Basterlösung wählen? Gibt es das? Glaube so jemand würde sich einfach ne fertige Wetterstation kaufen. Eine die villt sogar wasserdicht ist. P.S.: Das beschreiben einer SD-Karte, so dass sie danach bootbar ist ist übrigens auch gar nicht soo trivial... da kann man merh falsch amchen als beim flashen

Davon abgesehen, dass ich ein RAM-Brick für technisch nicht möglich halte, bitte ich auch folgendes zu bedenken: Jede Anforderung schlägt sich am Ende im Preis nieder. Wenn sich jetzt herausstellt, dass das Ganze am Ende teurer wird als ein Raspberry Pi, aber aufgrund der Größe noch immer nicht so viel kann, dann werden sich einige sicherlich überlegen, ob es überhaupt Sinn macht dieses Super-Brick zu kaufen. RAM ist m.E. nur in den typischen Größen nicht teuer, aber ich würde glatt behaupten, dass von den (massenhaft und billig) auf DIMMs und grafikkarten verbauten Chips schon ein einzelner kaum auf ein Brick passen würde.

1. Hardware-Diskussionen bitte woanders fortführen, die Python/C-Diskussion ist so schon komplex genug. Ich finde alle Wünsche toll, aber nicht in diesem Thread. Beitrag wurde verschoben, hier gehört die HW-Diskussion hin ^^ 2. Dass OnDevice sinnvoll ist wissen hier genügend Leute, sieh es mal so: Für deine Anwendungsfälle ist der Stromverbrauch egal genug, dass du dir um die 1-3 Watt des Raspberry Pi keine Sorgen machen musst. Da bin ich froh, dass es dir so geht. Andere hier müssen dadurch größere (schwerere) Akkus in ihre Rucksäcke stecken oder doppelt so oft in die Wildnis fahren um Batterien zu tauschen (oder doppelt so große Solar-Panels besorgen). Wenn OnDevice für dich kein Thema ist, dann ist das gut, aber es ist definitiv kein "Fliegen auf Mist"-Thema, sondern eine echte Anforderung. Ich verstehe deine Hardware-Wünsche auch noch nicht, aber deswegen behaupte ich nicht, dass sie unsinn sind und ich lasse mich (in einem anderen Thread) gerne erleuchten.

Weil RAM viiiiiiiel schneller reagiern muss und breiter angebunden wird. @Wozu: Stromverbrauch

Hey Franz, ja das hast du ziemlich richtig mitbekommen. Es soll aber eigentlich direkt auf der existierenden Hardware laufen (möglicherweise mit einem anderen Firmware-Image). Ob es nur ein Problem der Toolchain ist, ist noch die große Frage. C auf dem Brick auszuführen geht erstmal recht simpel, wenn du Python ausführen willst gibt es verschiedene Optionen: 1. Es geht gar nicht (zumindest nciht für TF bezahlbar) 2. Es geht, Python-Skripte werden nativ auf dem Brick ausgeführt (dann geht villt keine C-API mehr weil zu wenig Speicher auf dem brick vorhanden ist für alles gleichzeitig) 3. Es geht, Python-Skripte können mit passenden Tools kompiliert und aufs Brick geladen werden (C läuft nativ); hier wäre es nur eine Frage der Tools Das ist mein aktueller Irrtumsstand, die Frage ist jetzt was braucht man und was kann TF leisten.

Das war das hier: http://code.google.com/p/python-on-a-chip/ Da kam dann die berechtigte Frage warum die latest News von September 2011 sind. Die Commits sind ähnlich alt, das Projekt sieht also tot aus...

Ich frage mich nach meiner 20-Minütigen Recherche inzwischen, ob nicht C und Python möglich sind. Habe ja vorhin die RPython-Toolchain von PyPy hier im Thread verlinkt. Dabei handelt es sich um Tools die aus Python-Code C-Code machen und kompilieren. Ich habe das noch nicht selbst genutzt, es wäre also weitere Forschung nötig, aber grundsätzlich könnte es möglich sein, dass auf diese Weise sowohl C (nativ) als auch Python (durch die RPython-Toolchain) supported werden könnte. Ein großes Fragezeichen, aufgrund der aktuellen Diskussion aber möglicherweise die Forschung wert.

Für Performance-Fanatiker: Sprachen sind nicht per se langsam, sie werden potenziell langsam ausgeführt. Es ist möglich Python (genauer ein Subset von Python) zu C-Code oder Maschinen-Code zu kompilieren. Aber das sind alles Technologiefragen. Das heißt man könnte einen Chip nehmen (wie die Java-Geschichte), man könnte auf dem aktuellen ARM einen Python-Interpreter implementieren oder man könnte es unterstützen den Python-Code zu kompilieren und das auszuführen. Mehr Detail: PyPy

Also: Python ist eine moderne objekt-orientierte Sprache. C ist alt, erfordert viel unnützes Detail-wissen und ist Fehleranfällig (manuelle Speicherverwaltung!!!!) So, das war jetzt ein wenig polemisch aber im Wesentlichen spiegelt es meine Sicht der Programmierwelt wider. Oft wird bei C ein Performance-Argument gebracht, ohne dass jemand Zahlen dazu hat. Sprachen sind von Hause aus eh nicht schnell oder langsam, deren Ausführung in der Praxis vielleicht. Also Pro-Python: leichter erlernbar (wenn man vorher nichts kennt) weniger Fehleranfällig objekt-orientiert Und jetzt nochmal ein großes ABER: TinkerBASIC?? Da bin ich tatsächlich auch nicht so sehr von überzeugt. Ich würde definitiv dafür plädieren etwas existierendes, mit bestehender Community zu verwenden. Wenn ihr jetzt eine eigene Sprache nehmt, dann kann man gar keine existierende Software portieren und niemand hat Vorwissen. Also meine persönliche Reihenfolge: [*]Python [*]C [*]Tinker

@Doc: Du hast vergessen das Relais der IPConnection hinzuzufügen. Das war auch der Punkt wo ich mir nciht mehr sicher war, wie das in C++ hübsch gelöst wird. Idealerweise willst du entweder IPConnection oder gleich das Bricklet im Callback referenzieren können (anlegen vorher in der main), aber wie geht das (sauber)? Globale variable?

@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: 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 )

Mehraufwand auf der Seite von TF: ja Mehraufwand auf der Seite des Kunden: im Gegenteil, das Entwickeln ist C ist einfach mal schwerer und macht weniger Spaß (aber das könnte auch Geschmacksfrage sein). Wenn du aber eh mit dem Gedanken spielst in Assembler zu entwickeln eine andere Frage: Welche Vorteile/Features erhoffst du dir von einer anderen API als der die bereits verfügbar ist? (Da ich wirklich keine Ahnung habe ist die Frage ernstgemeint ) Ich würde intuitiv denken, dass es dir reicht deine (vollständig) eigene Firmware aufs Brick zu bügeln.

Ich glaube ich möchte mcih doch deutlicher als bisher positionieren: Warum soll C notwendig sein? In C auf den Bricks programmieren kann man schon heute. Also wo soll da am Ende der Unterschied zum Status quo sein? Eine schönere API? Vermutlich nicht, es ist ja trotzdem C. Ein immer wiederkehrender Wunsch im Forum war es aber sich "einfach" den Host-Rechner zu sparen. Oft auch in Verbindung mit einem Thread-ersteller, der vermutlich einfach besser kein C schreiben sollte/möchte. Wenn man schon den Komfort für das programmieren auf dem Brick verbessern will, dann sollte man auch den konsequenten Schritt zu einer hohen Sprache gehen. @Real_Black: Warum ist C einfacher? Hast du wirklich vor das zu tun? @Java: Das geht schon, braucht aber extra Hardware.

Definitiv funktioniert der Monoflop auch ohne, dass der Host-PC "denkt". Ich halte es halt für gefährlich einfach so den Strom zu trennen, aber da wir ja vom schlimmsten anzunehmenden Fall ausgehen (alles hängt) wäre es angebracht. Allerdings würde ich zu bedenken geben, dass sich Rechner nicht einfach so aufhängen und es dafür Ursachen gibt die erforscht werden sollten. Insofern solltest du solche Dinge definitiv monitoren und falls es jemals passiert untersuchen. Die Bedenken von cfranz mit den false positives würde ich auch ernst nehmen: - Monoflop-Timeout großzügig wählen - auf Software-Ebene den Prozess überwachen der deinen Stack steuern sollte - Prozess bei Fehlern neustarten (und natürlich loggen/dich als Admin benachrichtigen) Das Timing sollte so sein, dass falls sich nur deine Software aufhängt die Zeit reicht um: 1. zu bemerken dass deine Software hängt 2. deine Software zu killen 3. deine Software neuzustarten und (wieder durch die Software) den Monoflop wieder zu resetten

Deutlich besser als vorher, der Doku hat das neue Tabellendesign echt gut getan.

Für alle die es interessiert: https://github.com/Tinkerforge/generators/pull/37 Habe mal einen Vorschlag gemacht wie man die Sache mit den DeviceIds elegant in die C#-Bindings (und in der Form auch für Java und Co) einbringen könnte.

Habe ich mich gerade verzählt oder ist das in gut einem Monat? Dafür, dass das was du gerade geschrieben hast nach ziemlich fiesen Problemen klinngt halte ich das für einen straffen Zeitplan... Aber Ahnung hab ich natürlich keine. Hoffe nur der arme Gunter muss dann nach Ostern nicht traurig sein... Wird das Encoder-Bricklet auch stand-alone nutzbar sein um Umdrehungen zu zählen?

Ohne auf deine Frage zu antworten: Zwischen Bricklet und Sensor befinden sich nur 3 Kabel. Möglicherweise lässt sich dadurch ein kleinerer Ring nutzen?

Ach stimmt da war ja was... Jetzt wo so langsam meine Erinnerung zurück kommt: Ja, in der Ruby-Welt sind gems der übliche Weg seine Anwendung zu erweitern. Mir ist nur vorher nie aufgefallen, dass der Content aus Git-repositories geliefert wird ^^ Ich werde dazu auch mal meine Ruby-Experten befragen

Wollte nicht sagen, dass du das tun solltest ^^ War mehr als Erklärung gedacht warum dir bei den Testbildern schwindelig werden könnte