Preise TXT-Smart/4.0

[EstherM]

Hallo zusammen,

- Die Kooperativen möchten eine Zusammenarbeit in beide Richtungen

Das bedeutet praktisch:
- Die Plattform muss so beschaffen sein, dass Erweiterungen durch Dritte (die Community) rechtlich und technisch möglich sind.

Noch einer ist mir eingefallen:
- Die Hardware muss kompatibel mit der älteren Hardware sein.

Gruß
Esther

[MasterOfGizmo]

Evtl. bieten sie ja auch einen RoboPro -> Blockly Übersetzer an?

Der Dirk Fox als großer RoboPro-Fan hat mir mal erklärt, dass einer der Hauptaspekte an RoboPro ist, dass Unterprogramme auf unterschiedlichen Wegen verlassen werden können und die Ausführung dann an unterschiedlichen Stellen im Hauptprogramm weiterläuft. Sowas lässt sich m.E. kaum sinnvoll auf Blockly oder Python abbilden. Von daher dürfte eine automatische Übersetzung kaum möglich sein.

Wer sich mal Blockly-generierten Python-Code angeschaut hat und Python etwas kennt, der hat ggf. gemerkt, dass der so erzeugte Code didaktisch auch häufig wenig wert ist. Hier kann man die Blockly-Code-Erzeugung mal selbst testen:
https://blockly-demo.appspot.com/static ... index.html

Wenn man dort ein paar Variablen anlegt und dann ein paar Funktionen erzeugt, dann wirft Blockly z.B. mit "global"-Statements um sich. Das gibt technisch durchaus Sinn, da in Blockly alle Variablen global sind. Aber in Python würde man das so nicht machen und der erzeugte Python ist zwar korekt, aber didaktisch unbrauchbar und auf keinen Fall als Basis für eigene Programme sinnvoll.

Das ist übrigens der Grund, weshalb Brickly den erzeugten Code komplett verbrigt. Der Brickly-Code ist noch viel hässlicher, da er "magisch" um Code erweitert wird, der während des Programmablaufs Informationen zurück an den Browser sendet, damit dort der jeweils gerade aktive Block während der Ausführung aufleuchtet.

Ich bin gespannt, wie ft diesen Spagat meistern will. Ich würde aber annehmen, dass ihnen das nicht bewusst ist und dass sie das nicht weiter zur Kenntnis nehmen.

Ich bin auch gespannt, ob man beim neuen TXT-4.0 die Code-Ausführung im Browser verfolgen kann. Da sie den Python-Code sichtbar machen denke ich eher nicht, dass sie die entsprechende Instrumentierung vorsehen. Man kann also in Blockly nicht sehen, wie der Code ausgeführt wird, sondern wenn ein Fehler auftritt, dann erhält man stattdessen Python-Fehlermeldungen. Da wird es interessant, wie ft dafür sorgen will, dass man die Verbindung zwischen Python-Fehlermeldung und Blockly-Darstellung findet. Wobei es gar nicht so einfach ist, in Blockly überhaupt fehlerhaften Code zu schreiben ...

Entweder haben die ein paar coole Asse im Ärmel oder es wird noch hier und da noch einen Aufschrei geben.

[MasterOfGizmo]

Das bedeutet praktisch:
- Die Plattform muss so beschaffen sein, dass Erweiterungen durch Dritte (die Community) rechtlich und technisch möglich sind.

Nein, das wäre nach wie vor keine Kooperation. Zur Zeit nimmt ft nur und gibt nichts zurück. Das verbessern sie nicht dadurch, dass sie sich das Nehmen einfacher machen.

Rechtlich möglich ist das sowieso. Da ich sie schon vor Jahren hier öffentlich auf Ihre Lizenzverletzungen aufmerksam gemacht habe und sie das nicht abgestellt haben haben sie per Lizenz eh alle Rechte verloren. Sprich: Wenn wir ft's Code nehmen ist das legal, wenn sie unseren nehmen verletzen sie die Lizenz. Cool, oder

Aber das ist nicht die einzige rechtliche Grauzone, in die sie sich völlig unnötig selbst manövriert haben. Es gibt auch NDAs zum Thema "Open-Source-Entwicklung", wo ft sich schriftlich verpflichtet hat, Community-Know-How vertraulich zu behandeln ...

[tintenfisch]

- Die Hardware muss kompatibel mit der älteren Hardware sein.

Das ist m.E. nicht so wichtig, weil das kaum den Endanwender interessiert, da dieser i.d.R. eh nur via Software auf die Geräte schaut. Aus eigenem Interesse ist es natürlich sinnvoll, "alte" ft-Hardware weiterhin zu unterstützen, aber das ist durch etablierte Standards (USB, I2C, Bluetooth) nicht schwer. Genauso hätte ft einen Controller um einen Pi-Zero W herumbauen können, das Ergebnis wäre für den Endanwender das gleiche gewesen (abgesehen davon, dass der Zero mit mehr Rechenleistung und BT etc. von Haus aus kommt).

Viele Grüße
Lars

[EstherM]

- Die Hardware muss kompatibel mit der älteren Hardware sein.

Das ist m.E. nicht so wichtig, weil das kaum den Endanwender interessiert, da dieser i.d.R. eh nur via Software auf die Geräte schaut.

Es geht hier darum, dass die (bei den Fans reichlich vorhandenen) Aktoren und Sensoren rein physikalisch auch mit den neuen Controllern funktionieren. Das heißt: die Spannung passt und Aktoren und Sensoren lassen sich über konfektionierbare Kabel und Flachstecker (z.B. https://ft-datenbank.de/ft-article/1739) mit den Controllern verbinden.
Die Alternative wären proprietäre Stecker, die bestimmt auch ihre Vorteile haben, z.B. verpolungssicher sein können.

Gruß
Esther

[tintenfisch]

[...]
Es geht hier darum, dass die (bei den Fans reichlich vorhandenen) Aktoren und Sensoren rein physikalisch auch mit den neuen Controllern funktionieren. Das heißt: die Spannung passt und Aktoren und Sensoren lassen sich über konfektionierbare Kabel und Flachstecker (z.B. https://ft-datenbank.de/ft-article/1739) mit den Controllern verbinden.

Das habe ich vorausgesetzt. Es wäre ja ein starkes Stück, wenn ft die eigenen Standards fallen ließe. Wir sind hier ja nicht bei Lego.

[MasterOfGizmo]

Es geht hier darum, dass die (bei den Fans reichlich vorhandenen) Aktoren und Sensoren rein physikalisch auch mit den neuen Controllern funktionieren.

Das bekommen sie ja in der Regel problemlos hin. Fraglich ist nur, was aus den vorhandenen Bewegungs- und Umweltsensoren wird. Die passen zumindest mal mechanisch nicht mehr direkt an den neuen TXT. Ob es da Adapterkabel geben wird oder gleich neue Sensoren weiss erstmal keiner. Vielleicht bauen sie auch einfach Björns Extender nach ...

[Bjoern]

So in 3 Monaten rum werden sich dann so langsam die Geheimnisse lüften.....

Lassen wir uns überraschen.

Und naja, der ft-Extender kann sich ja jetzt nicht unbedingt dafür rühmen das wir jetzt ein Schaltungswunder aus dem Ärmel gezaubert haben.

Aber interessant ist halt schon die Frage wie die einzelnen Community Projekte daran angepasst werden könnten.

Unser ftPwrDrive hat eine RoboPro Anbindung. Für den ftDuino gibt es eine RoboPro Erweiterung, um diesen als Erweiterung zum TXT nutzen zu können.
Und dann haben wir ja noch die riesige Sammlung von RoboPro Bibliotheken für alle möglichen Sensoren.

Wie ist dann das Handling im Blockly wenn du einen Ausgang am 5ten Sub-Controller schalten willst?

Es wäre natürlich schön wenn das fischertechnik Team hierzu vielleicht mal ein paar Worte verlieren würde. Vermutlich lesen die doch ab und zu mal mit.

Grüße
Björn

[EstherM]

Hallo zusammen,

Da ich sie schon vor Jahren hier öffentlich auf Ihre Lizenzverletzungen aufmerksam gemacht habe und sie das nicht abgestellt haben haben sie per Lizenz eh alle Rechte verloren

Eigentlich sollte man voraussetzen können, dass jeder die Lizenzbestimmungen kennt und sich auch daran hält. Es ist extrem bedauerlich, dass ft das anders handhabt.

- Die Plattform muss so beschaffen sein, dass Erweiterungen durch Dritte (die Community) rechtlich und technisch möglich sind.

Nein, das wäre nach wie vor keine Kooperation. Zur Zeit nimmt ft nur und gibt nichts zurück. Das verbessern sie nicht dadurch, dass sie sich das Nehmen einfacher machen.

Die Plattform könnte ja proprietär sein, so dass Erweiterungen die Rechte von irgendwem verletzen würden. Außerdem könnte es so sein, dass Erweiterungen nur durch Reverse-Engineering überhaupt möglich wären. Da fände ich die Bereitstellung einer offenen und freien Plattform schon einen Fortschritt. Was würdest Du Dir denn unter einer Kooperation vorstellen? Was wäre Dein Wunsch?

Gruß
Esther

[Lars]

Hallo zusammen,

Da ich sie schon vor Jahren hier öffentlich auf Ihre Lizenzverletzungen aufmerksam gemacht habe und sie das nicht abgestellt haben haben sie per Lizenz eh alle Rechte verloren

Eigentlich sollte man voraussetzen können, dass jeder die Lizenzbestimmungen kennt und sich auch daran hält. Es ist extrem bedauerlich, dass ft das anders handhabt.

Lizenzbestimmungen können dicke Wälzer sein, die für die meisten Menschen undurchschaubar bleiben.

- Die Plattform muss so beschaffen sein, dass Erweiterungen durch Dritte (die Community) rechtlich und technisch möglich sind.

Nein, das wäre nach wie vor keine Kooperation. Zur Zeit nimmt ft nur und gibt nichts zurück. Das verbessern sie nicht dadurch, dass sie sich das Nehmen einfacher machen.

Du kannst Dich doch eigentlich nicht über ft beklagen: Du hast ein Zusatzprodukt entwickelt, das man als Erweiterung, aber auch als Konkurrenzprodukt zum eigenen Controller betrachten kann, für das sie aber dennoch ein wenig Reklame gemacht haben. Es war auch aus ihrer Sicht klug, das zu tun und ich würde deshalb jetzt nicht von einem selbstlosen Akt der Nächstenliebe sprechen wollen. Aber auf deren Website erfährt nun sicherlich eine vielfache Anzahl von ft-Nutzern von der Existenz des ftDuino. Und Dein Engagement und wohl auch das der Community, Modellbauservos für ft nutzbar zu machen, haben doch Früchte getragen - oder wie soll man die drei Servoausgänge an den neuen TXTs deuten?

Die Plattform könnte ja proprietär sein, so dass Erweiterungen die Rechte von irgendwem verletzen würden.

Es fragt sich, ob sie dann überhaupt Gegenstand von Entwicklungsaufwand sein sollte. MS Office beispielsweise war und ist Closed Source, der Code also ein Betriebsgeheimnis von Microsoft. Trotzdem haben in den 1990er bis in die 2000er Jahre viele Menschen davon leben können, Erweiterungen oder auf der Basis von MS Access ganze Datenbankanwendungen zu entwickeln und zu vertreiben. Sie laufen BTW teilweise noch heute und erreichen damit Lebensdauern, die an Großrechnerprodukte oder Nutzfahrzeuge erinnern.

Wenn man es nicht gerade aus Spaß an der Freud' macht, sondern auch wirtschaftlich sein muß, sind die App Stores bei Android oder iOS unumgänglich und man ist damit an inhaltliche Restriktionen von Google oder Apple gebunden, von denen bei Microsoft all die Jahre kein Gedanke war. Und da unterscheidet sich Google nicht so sehr von Apple, obwohl Google der Welt ja auch unheimlich viel Code "vermacht" hat, wo bei Apple trotz unixoider Basis Closed Source vorherrscht.

Mit freundlichen Grüßen
Lars

[jodeka]

Liebe Community,

es freut mich, dass die Diskussion so richtig angesprungen ist.

Ich möchte noch weitere Argumente aufführen, warum ich den Preis für diesen Kasten
für zu teuer halte.

Erstens, wie viele von Euch schon geschrieben haben, es kommt eine "neue" Programmiersprache,
die sehr ähnlich zu "Blockly" erscheint. Generell sind solche Programmiersprachen einfach zu handhaben
und lernen unseren Jüngsten von Anfang an "objektorientiert" zu denken. z.B. Scratch, wo man
in den Sprites die Befehle und Tasks hinterlegt. Solche Sprachen gibt es viele, wie z.B. MakeCode, Ardublock,
Snap, usw. Warum Fischertechnik jetzt eine eigene Sprache "entwickelt", verstehe ich nicht.

Zweitens beim TXT 4.0 kann man als Modell einen Malroboter bauen. Die Idee ist prinzipiell nicht schlecht.
Aber weil die neuen Super-Räder nicht "wirklich" rund sind, malt der Roboter eine Linie gezackt. Das sieht man
sogar im Produktvideo. Mein alter Fischertechnik-Plotter kann gerade Linien problemlos zeichnen. Der ist
mindestens 30 Jahre alt. Ist das ist jetzt der "technische Fortschritt" ?

Drittens mir ist gestern mein alter IC-Digital-Pratikum Kasten in die Hände gefallen. In der Anleitung gab es
WIRKLICH eine Beschreibung (Seite 89 ff), wie ich die "alten" Silberlinge mit dem neuen Baukasten kombinieren
kann. Fischertechnik hat sich damals überlegt, wie du Deine alten Fischertechnikkästen weiter verwenden kannst.
Heute kann ich nicht einmal den TXT irgendwie mit dem TXT 4.0. koppeln oder mit einer gemeinsamen
Programmiersprache ansprechen.

Viertens weil ich die Silberlinge erwähnte, das hätte ich mal eine Produktidee. Liebe Fischertechnik, macht doch
einen "Retro"-Kasten, mit einen (elektronischen) Baustein) , der ein paar Eingänge hat, wie beim Grundstein (mit Operationsverstärker)
und ein paar Ausgänge, wie beim Relaisbaustein. In der Software oder in einem Browser, verbinde ich dann
die unterschiedlichen Silberlinge (AND, FF, Mono-F, usw.) miteinander und kann so meine Schaltung basteln.
Die Funktion wird dann im elektronischen Baustein abgearbeitet. Das wäre mal ein Kasten !
Der kann auch 500 € oder mehr kosten, weil den kauft sich der Papa, für sich selbst !!!

Zum Schluss, einer hat es schon erwähnt, Fischertechnik sollte sich nicht den dänischen Klötzchenbauer als Vorbild
nehmen. Dort kippt nämlich die Stimmung in der Community. Alleine die Geschichte rund um den "Held der Steine"
treibt die Emotionen hoch. So was will ich hier nicht erleben !

Im diesem Sinne

jode

[Karl]

Hallo,

In der Software oder in einem Browser, verbinde ich dann
die unterschiedlichen Silberlinge (AND, FF, Mono-F, usw.) miteinander und kann so meine Schaltung basteln.
Die Funktion wird dann im elektronischen Baustein abgearbeitet.

Da sind diejenigen mit dem Robo-Interface fein raus.
In Verbindung mit der Software Profi-Lab und Digital-Lab von Abacom werden das Robo-Interface samt Extensions
super unterstützt. Die Hardware als I / O und auf dem PC die Logik usw.
In der Profi-Version können die "selbstgebauten" Schaltungen auch compiliert werden.
Allerdings ist nur "online-Betrieb" möglcih. Hardware als I / O und die Intelligenz "im PC".
Über USB funktioniert es gut, über RS 232 habe ich noch nie ausprobiert.

https://www.electronic-software-shop.co ... rt-40.html

Hatte mal vor Jahren mal bei Abacom nachgefragt ob eine Unterstützung ab Fischertechnik TX auch geplant sei.
Wurde von Abacom verneint, aus welchem Grunde auch immer.

[tintenfisch]

Erstens, wie viele von Euch schon geschrieben haben, es kommt eine "neue" Programmiersprache,
die sehr ähnlich zu "Blockly" erscheint. [...]
Warum Fischertechnik jetzt eine eigene Sprache "entwickelt", verstehe ich nicht.

Das erscheint nicht nur ähnlich zu Blockly, das wird Blockly sein, somit keine neue "Progammiersprache". Blockly erzeugt ein Py-Script, welches dann ausgeführt wird. Wie bereits geschrieben, m.E. ein grundsätzlich sinnvoller Schritt. In diesem Punkt verstehe ich auch die Kritik an ft nicht, Lego oder die Community kopiert zu haben. Blockly scheint mir eine logische Konsequenz zu sein, wenn man plattformunabhängig eine einfache Umgebung bieten möchte, mit der jüngere oder unerfahrene Anwender in die Programmierung einsteigen können.

Aus der Sicht von jemandem, der Python mag, teile ich die Bedenken von MoG bzgl. des didaktischen Vorbildcharakters des erzeugten Codes, wie bereits in viewtopic.php?f=4&t=6605&start=60#p49895 erwähnt, aber dazu hat das fite-Team bereits geschrieben, dass es sich um einen Prototypen handelt. Somit bleibt zu hoffen, dass u.a. from viele.namespaces.hier.und.mit.Groß.und.kleinschreibung.vermixt import EineKlasse noch abgestellt wird.

Viele Grüße
Lars

[MasterOfGizmo]

Du kannst Dich doch eigentlich nicht über ft beklagen:

Es geht mir dabei nicht um mich oder andere konkrete User. Es geht um das Vorgehen an sich. Bis zum TX hat ft m.E. die klassische kommerzielle Lösung gefahren: "Was ich verkaufe muss ich vorher selbst gekauft haben". Das ist super. Mit dem TXT haben sie dann festgestellt, dass es da was kostenloses gibt. Und das nehmen sie sich. Und das war's dann.

Wenn das alle so handhaben würden wäre Open-Source längst gescheitert. Das lebt von Nehmen und Geben. Selbst Konzerne wie Microsoft oder Intel halten sich daran. Das meine ich. wenn ich sage, dass Kooperation nicht bedeutet, dass ft der Community erlaubt, Lücken zu füllen. Das ist auch tatsächlich nichts, dass sie jemandem erlauben müssten. Wer Code unter GPL-Lizenz nutzt ist verpflichtet, das zu ermöglichen. Genau das ist die eine zentrale Bedingung, die viele Open-Source-Lizenzen stellen: Wenn Du unsere Arbeit nutzt muss Du anderen die Möglichkeit geben, auf Deiner darauf aufgebauten Arbeit wiederum aufzubauen.

[MasterOfGizmo]

In diesem Punkt verstehe ich auch die Kritik an ft nicht, Lego oder die Community kopiert zu haben. Blockly scheint mir eine logische Konsequenz zu sein, wenn man plattformunabhängig eine einfache Umgebung bieten möchte, mit der jüngere oder unerfahrene Anwender in die Programmierung einsteigen können.

Wenn es tatsächlich nur diesen einen Weg gibt zum modernen Kinder-Robotik-Produkt gibt, dann hast Du Recht. Aber dann musst Du dem Kunden das ziemlich geschickt verkaufen, dass er nicht merkt, dass es das gleiche Produkt wie bei der Konkurrenz ist.

Was wäre denn m.E. geschickter? Wenn sie z.B. sagen "Hey, wir wollen Dir ja nicht nur ein fertiges Produkt verkaufen, wie all die anderen. Nein, wir ermöglichen Dir mit diesem Schritt bewusst, unsere vorgegebenen Grenzen zu verlassen. Wir nutzen das freie Know-How bewusst, damit Du das auch kannst. Schau, hier ist alles dokumentiert, hier sind die Schnittstellen und APIs dokumentiert. Und jetzt hast Du die Wahl: Nutze unser Produkt einfach wie jedes andere. Oder verwirkliche Deine eigenen Vorstellungen, wie Du es nur mit unserem Produkt kannst, denn dass Du das machen kannst ist uns wichtig und wir geben Dir alles, was Du dafür brauchst." Und auf einmal bist Du nicht derjenige, der einfach kopiert weil's billiger ist, nein, Du bist derjenige, der das total großherzig macht, weil er Dir was Gutes damit tun will.

Vielleicht ist das sogar das, was Esther meinte. Aber das darf eben nicht primär auf den Hintergedanken abzielen, dass die Community dann bitte mal Produktpflege betreibt.

[Lars]

Hallo Lars,

Blockly scheint mir eine logische Konsequenz zu sein, wenn man plattformunabhängig eine einfache Umgebung bieten möchte, mit der jüngere oder unerfahrene Anwender in die Programmierung einsteigen können.

... und die man als Open Source nur einkompilieren und nicht erst neu entwickeln will.

Blockly wird IMHO noch sehr viel schneller unübersichtlich als es ROBOPro sein müßte. Dessen Bedienung kann sicherlich noch stark verbessert und beispielsweise auch die Verarbeitung operationeller Ausdrücke ermöglicht werden. Am besten erlaubt man noch den Aufruf fremden (Python-)Codes oder erlaubt den Aufruf von ROBOPro-Programmen aus Python heraus.

Mit freundlichen Grüßen
Lars

[Karl]

Hallo,
entwickelt und / oder baut die Fa. Fischertechnik die Elektroniken selbst ?
Irgendwas war doch damals mit der Fa. Knobloch, sollen sich doch getrrennt haben.

[EstherM]

Hallo zusammen,

Vielleicht ist das sogar das, was Esther meinte.

Genau das. Till, Du kennst mich gut!

Partizipation ist das Zauberwort. Und wenn jemand nicht beitragen will, dann muss es möglich sein, einfach nur zu konsumieren, ohne schlechtes Gewissen. Dafür hat man dann bezahlt.

Proprietäte Plattformen, auf denen praktisch keine Eigenentwicklung möglich ist, gibt es sehr wohl. Meines Wissens funktionieren die ganzen Spielekonsolen so.

Schau, hier ist alles dokumentiert, hier sind die Schnittstellen und APIs dokumentiert.

Das ist einer der Knackpunkte. Die Dokumentation macht fast niemand freiwillig gerne, die muss mit dem Produkt kommen.

Schaun wir mal, was im Juli tatsächlich geliefert wird.

Gruß
Esther

[Lars]

Hallo Till,

Bis zum TX hat ft m.E. die klassische kommerzielle Lösung gefahren: "Was ich verkaufe muss ich vorher selbst gekauft haben". Das ist super. Mit dem TXT haben sie dann festgestellt, dass es da was kostenloses gibt. Und das nehmen sie sich. Und das war's dann.

ich vermute eher, daß sie zur Zeit der bisherigen TX und TXT die Controllertechnik eher als Beiwerk zu den mechanischen Qualitäten angesehen haben, wenn auch vielleicht nicht mal willentlich. "Industrie 4.0" und Digitalisierung war ja schon damals in aller Munde, aber vielen Unternehmen war nicht so wirklich klar, was das konkret für ihre Produkte und ihre Produktion bedeutet, obwohl gerade ft als Produkt seit ca. 1985 - früher als alle anderen - digital bewußt ist. Zum einen will man Beiwerk instinktiv finanziell nicht zur Hauptbelastung werden lassen und zum anderen benötigt der erforderliche Kompetenzaufbau auch viel Zeit, wenn man es selber machen möchte. Und da versucht der Unternehmer dann lieber die zeitliche Belastung in eine finanziell begrenzte Investition zu transformieren.

Du dagegen bist hinsichtlich ft als Hobbyist (wieder)eingestiegen und hast auch als Hobbyist ohne zeitliche oder finanzielle Zwänge entwickelt. Auf einmal hattest Du ein vermarktbares Produkt und bist erst in diesem Stadium vertragliche Verpflichtungen eingegangen. ft hatte aber die ganze Zeit schon beispielsweise die Verpflichtung, Löhne und Gehälter zu zahlen. Deshalb habe ich ein gewisses Verständnis für eine andere Herangehensweise.

Mit freundlichen Grüßen
Lars

[MasterOfGizmo]

...
Und da versucht der Unternehmer dann lieber die zeitliche Belastung in eine finanziell begrenzte Investition zu transformieren.

Du dagegen bist hinsichtlich ft als Hobbyist (wieder)eingestiegen und hast auch als Hobbyist ohne zeitliche oder finanzielle Zwänge entwickelt.

Ich verstehe, was Du meinst. Und tatsächlich riskiere ich nichts. Ich investierte da ca. 1/10 FTE und ein paar hundert Euro in Entwicklung pro Jahr (Serienproduktion mal außen vor gelassen). Und ich kann problemlos technische Risiken eingehen. Zum Beispiel ist https://www.youtube.com/watch?v=9zsAbTVxjMw für den ESP32 Neuland. Das ist ein ftDuino32-Prototyp, der "Remote-Desktop" via Browser lernt. Die Technik dahinter ist recht frisch, so dass ich an den Basistechnologien manchmal Bug-Fixing machen muss wie hier: https://github.com/micropython/micropython/pull/5613. Das hat den Charme, dass es wenn es klappt Python, Blockly, Webserver und Co via WLAN/BT auf einer $2-CPU vereint. Da ist ft mit dem TXT-4.0 bei CPU und BT/WLAN bei $40 ... Sicher gehen auf dem TXT-4.0 Dinge, die man dem ESP32 auf keinen Fall beibringen kann. Aber der 20-fache Preis ist mal eine Hausnummer und dass ft den TXT-4.0 technisch ausnutzen wird widerspäche der Erfahrung.

Aber dass sich ft das nicht auch selbst leisten kann sehe ich nicht so. 1/10 FTE und ein paar-hundert Euro haben die sicher für R&D übrig. Und dass Dinge teurer und langwieriger werden, wenn sie abgelenkte Mitarbeiter machen statt motivierte Hobbyisten ist auch klar. Trotzdem ist das eine reine Organisationsfrage. Leistet sich eine Firma nicht den Luxus einer entspannten kleinen R&D-Ecke, dann verzögert sich die Entwicklung durch das übliche "jetzt gerade sehr wichtige" operative Geschäft immer wieder. Das endet dann damit, dass man sechs Monate vor Verkaufsstart nur eine aus dem Internet runtergeladene Fake-Produktdemo hat wie https://www.youtube.com/watch?v=f4S9_Efk7Ss. Das lässt natürlich keinen Raum für ein ausgereiftes Produkt. Verzögerungen dürfen dann nicht mehr passieren, Forschung kann man auch keine mehr machen und man steht unter dem Zwang irgendwie das in die Realität umsetzen zu müssen, was man vorher angetäuscht hat. Das endet dann leider auch mit Produkten, die technisch aus nur halbwegs passenden und zur Sicherheit völlig überdimensionierten Off-the-Shelf-Soft- und Hardwarekomponenten bestehen und daher am Ende viel teurer sind als sie sein müssten. Da weint dann der Ingenieur in mir immer ...

Aber das hat seine Ursache allein im Management. Das sind keine fundamentalen Beschränkungen, denen ft da unterliegt. Eine halbe R&D-Stelle und etwas Forschungsbudget haben sie selbst dann noch, wenn sie inzwischen vom Lego-Umsatz um einen Faktor 200 entfernt sind.