Habe in der letzten Zeit immer Tcl/Tk benutzt, um meine Mikrocontroller über den ComPort anzusprechen. Das war zwar bequem, bei etwas anspruchsvolleren Operationen gabs aber Überraschungen. So hat die Umwandlung von Characters in 2stellige Hexadezimalzahlen im oberen Bereich >127 über 10 Zeichen falsch umcodiert, so daß ich das mit einem externen C-Programm abfangen mußte. Ich bin deshalb auf der Suche nach einer Programmiersprache, die ähnlich komfortabel das Ansprechen des ComPorts erlaubt, aber weniger Fehler macht. Meine erste Idee war zwar, Python zu nehmen, aber meine Versuche damit sind (wie früher schon) nicht besonders glücklich ausgegangen. Mit dem Python-Download (23 MB!) war das wohl unvermeidliche "import serial" gar nicht zu machen, der nächste Versuch mit Thonny portable (29 MB!) ergab damit immerhin keinen Fehler mehr, aber ein kleiner Test mir "import numpy" zeigte schnell, daß es wohl doch noch bei mir an ziemlich viel Wissen mangelt. Offensichtlich nutzt man mit Python trotz des Umfangs nur eine Art Basismodell, das aber erst mit Insiderwissen nützlich wird, wovon aber in den per Google zahlreich auftauchenden Tutorials leider nichts enthalten ist. Und der Schnellkurs in pip, den ich gefunden habe, wirkte ziemlich abschreckend. Da kann ich auch in FASM programmieren, das schreckt weniger. Gibt es überhaupt so etwas, wie einfach, komfortabel und gut für die ComPorts oder bin ich zu anspruchsvoll? Mit freundlichen Grüßen Klaus (der soundsovielte)
Klaus S. schrieb: > Gibt es überhaupt so etwas, wie einfach, komfortabel und gut für die > ComPorts oder bin ich zu anspruchsvoll? Du gehst falsch an das Problem heran. Anstatt etwas zu suchen, dass ohne Lernaufwand dein Problem löst, solltest du erst lernen, wie du es mit den dir zur Verfügung stehenden Mitteln lernen kannst. Das ist ähnlich wie eine Schraube, die du versucht linksherum reinzudrehen. Nachdem das bei zig Versuchen nicht geklappt hast, fragst du, welcher Hammer am besten ist, um eine Schraube einzuschlagen...
Klaus S. schrieb: > Mit > dem Python-Download (23 MB!) war das wohl unvermeidliche "import serial" > gar nicht zu machen https://pypi.org/project/pyserial/
Klaus S. schrieb: > Habe in der letzten Zeit immer Tcl/Tk benutzt, um meine Mikrocontroller > über den ComPort anzusprechen. Das war zwar bequem, bei etwas > anspruchsvolleren Operationen gabs aber Überraschungen. So hat die > Umwandlung von Characters in 2stellige Hexadezimalzahlen im oberen > Bereich >127 über 10 Zeichen falsch umcodiert, so daß ich das mit einem > externen C-Programm abfangen mußte. Das das falsch umcodiert wurde ist aber nicht eine Frage der Programmiersprache an sich, sondern eine Frage der Logik die letztendlich hinter der Umcodierung steckt. Überhaupt dürfte es nicht von der Programmiersprache abhängig sein wie komfortabel man den COM-Port anspricht. Das Umwandeln der Zeichen von Char in Hexadezimal hat auch nichts mit dem COM-Port oder dessen Routinen zu tun, das ist eine andere Baustelle. Du hast da wohl einfach irgendwas, in dem Fall von Tcl/Tk, übenommen, ohne Dir wirklich Gedanken zu machen, was da im Hintergrund passiert und wie die Übertragung abläuft. Den COM-Port kann man z.B. sehr komfortabel mit Objektpascal ansprechen. Da gibt es für Delphi etliche Komponenten, die einem dabei viel Arbeit abnehmen. Es funktioniert aber genauso gut auch mit C oder Basic. Im Endeffekt dürfte jede Programmiersprache funktionieren. Selbst in der Bash sollte es problemlos funktionieren den Port über das Gerätedevice anzusprechen. Die Daten zur Übertragung muß man natürlich passend aufbereiten, aber das wird einem bei keiner Programmiersprache abgenommen.
Klaus S. schrieb: > So hat die Umwandlung von Characters in 2stellige Hexadezimalzahlen im > oberen Bereich >127 über 10 Zeichen falsch umcodiert, so daß ich das mit > einem externen C-Programm abfangen mußte. Tcl war eine der ersten Programmiersprachen mit guter Unicode-Unterstützung. Wenn du für die obige Aufgabe ein externes C-Programm bemühen musstest, dann sind dir, so vermute ich, einige encoding-Feinheiten in Tcl entgangen. Python ist diesbezüglich auch recht sauber. Man muss halt systematisch und strikt Bytes und Glyphen auseinanderhalten, wenn man den ASCII-Bereich verlässt. LG, Sebastian
Sebastian schrieb: > Wenn du für die obige Aufgabe ein externes > C-Programm bemühen musstest, ... dann kann dieses die serielle Schnittstelle auch gleich selbst abfragen.
Klaus S. schrieb: > So hat die > Umwandlung von Characters in 2stellige Hexadezimalzahlen im oberen > Bereich >127 über 10 Zeichen falsch umcodiert, so daß ich das mit einem > externen C-Programm abfangen mußte. Das kann ich nicht glauben. Die Umrechnung von Bytes in Hexadezimale Schreibweise ein eine ganz simple Basis-Operation. Niemand würde eine Programmiersprache veröffentlichen, die das nicht kann. Hasst du eventuell Zeichensätze durcheinander gebracht?
Stefan F. schrieb: > Hasst du eventuell Zeichensätze durcheinander gebracht? Das ist sehr wahrscheinlich. Wer ASCII kennt (oder annimmt, zu kennen) und unvorbereitet auf UTF-8 stößt, der kann lustige Effekte erleben.
Klaus S. schrieb: > Offensichtlich nutzt man mit Python trotz des > Umfangs nur eine Art Basismodell, das aber erst mit Insiderwissen > nützlich wird, wovon aber in den per Google zahlreich auftauchenden Python ist modular aufgebaut und viel Funktionalität steckt in Packages, die erst installiert werden müssen. Unter Linux meist per Paketmanager, unter Windows ab besten mit pip:
1 | python -m pip install pyserial |
Ich empfehle Dir Visual-Code mit Python Erweiterung als Editor...
> ... dann kann dieses die serielle Schnittstelle auch gleich selbst > abfragen. So sehe ich das auch. Gibt ein nettes Executable und man braucht den ganzen grossen vollen Rucksack eines Interpreters nicht mehr mit herumtragen. Die Ausnahme waere, man kann aus dem Rucksack etwas wirklich gebrauchen und moechte sich die Arbeit dafuer nicht machen... Wenn es z.B. exotische Hardware ist, wo der Hersteller einen Pythoninterpreter mit Interfacefunktionen dafuer schon liefert. Ansonsten kann man fuer serielle Schnittstellen ja auch Matlab bemuehen. Das kann das auch. :)
Spontan faellt mir auch noch "MMBasic" ein. Davon gibt es einen PC-Port der mit der basicartigen "Leichtigkeit" mit seriellen Schnittstellen, Zeichen und Zeichenketten umgehen kann. Das koennte man dann auch gewissermassen stand-alone auf einem Maximite oder einem seiner vielen Derivate laufen lassen. Und braucht dann keinen ganzen PC mehr dafuer.
schau dircerstmal das encoding von Tcl/Tk an. Das kann man für jeden Stream extra - auch nachträglich - einstellen. Evtl. spielt ja schon die -translation Option eine Rolle.
:
Bearbeitet durch User
Ja, statt hektisch nach anderen Programmiersprachen zu suchen, würde ich versuchen, das eigentliche Verständnisproblem bei der ansonsten ja wohl beherrschten Programmiersprache zu lösen. Du könntest beschreiben, welche Zeichen auf welche Weise "falsch" codiert wurden und was Du stattdessen erwartet hast.
Danke für alle Zuschriften. Wenn ich aber gewußt hätte, daß mein nur als Beispiel gemeintes Problem mit Tcl soviel Aufmerksamkeit findet, hätte ich etwas mehr dazu geschrieben. Es ging ganz einfach darum, ein Hexfile von einem freien 8051-Assembler in einen 89S51 zu verfrachten. Da ich einen ganzen Tag damit verbracht hatte, das mit PonyProg oder avrdude/AVRISP zu bewerkstelligen und dabei kläglich gescheitert war, hatte ich dementsprechend schlechte Laune und habe notgedrungen ein eigenes Programm geschrieben. Dabei war eben das Hexfile im Wege, einen Interpreter des Intel-Hex-Formats zu schreiben war mir zu aufwändig und so habe ich mit Hexe2Bin.exe das Ganze auf binär umformatiert. Und damit begannen dann die Probleme mit Tcl. Im Endeffekt habe ich die ganze Binärdatei in C in einem Rutsch in Hexadezimalschreibweise umformatiert, das hat die Datei einen Faktor 2 aufgeblasen, war aber in 10 Minuten erledigt und ich konnte mit ASCI-Zeichen weitermachen und einen Arduino mit Komandos füttern, der dann die Bytes in den 89S51 klopfte. Natürlich muß das kein Fehler von Tcl gewesen sein, sondern eher meine Dummheit. Aber ich empfand damals (ca 3 Jhre her) die Dokumentation über die Behandlung binärer Daten in Tcl als ausgesprochen schlecht, das ist heute erheblich besser geworden (oder ich im Dokufinden :-). Wie Dirk B. schrieb, ist vermutlich der Unterschied von "-translating binary" und "-encoding binary" der Schlüssel zum Verständnis. Ich werde dazulernen. Den Tipp mit MMBasic habe ich mir gemerkt. Allerdings habe ich damals, als der Maximite erschien, bereits bedauert, daß Geoff nicht den 725er eingesetzt hat, der mit Ethernet ausgestattet ist. Insofern befürchte ich, daß MMBasic nicht einmal UDP kann, von TCP gar nicht zu reden. Aber erneut anschauen werde ich es mir auf jeden Fall. Zu MS-DOS-Zeiten war GWBasic der Effizienzchampion für den ComPort, viel Effekt mit wenigen Zeilen Code. Da ich im Moment wegen Corona zur Isolation verdonnert bin, habe ich Zeit zum Experimentieren und werde mir die Vorschläge der Reihe nach vornehmen. Fast könnte ich sagen: Schön, daß nach 7 Tagen der Schnelltest immer noch zwei dicke Striche anzeigt. Gruß Klaus (der soundsovielte) P.S. Tcl hat aus meiner Sicht 3 Schwachpunkte: UDP fehlt mir, Behandlung binärer Daten ist extrem ausbaufähig und der Aufruf externer DLLs ist (zumindest aus meiner Sicht) unterirdisch. Daß es degegen schnarchlangsam ist, macht es mir eher sympathisch :-)
Beitrag #7298750 wurde von einem Moderator gelöscht.
DerEinzigeBernd schrieb: > Ja, statt hektisch nach anderen Programmiersprachen zu suchen, würde ich > versuchen, das eigentliche Verständnisproblem bei der ansonsten ja wohl > beherrschten Programmiersprache zu lösen. Ich frage mich warum es überhaupt nötig ist da eine Programmiersprache zu bemühen. Das Ansprechen eines µC's klappt ja schon mit einem simplen Terminalprogramm. Unter Linux funktioniert das Ganze sogar mit einem Bash-Script. Selbst unter Windows sollte es mit CMD-Befehlen (mode, echo etc.) funktionieren. Einen Interpreter an dieser Stelle zu bemühen der auf dem Standardsystem, zumindest unter Windows, nicht verfügbar ist, halte ich für suboptimal. Aber alles egal, es scheint eh nicht so wichtig zu sein, denn der TO hat sich seit dem Eröffnungspost nie wieder gemeldet.
Update: Oh der TO hat sich gemeldet, während ich hier getippt habe.
Klaus S. schrieb: > P.S. Tcl hat aus meiner Sicht 3 Schwachpunkte: > UDP fehlt mir Hilft vielleicht das hier? https://wiki.tcl-lang.org/page/TclUDP
Beitrag #7298812 wurde von einem Moderator gelöscht.
Beitrag #7298831 wurde von einem Moderator gelöscht.
Zeno schrieb: > Ich frage mich warum es überhaupt nötig ist da eine Programmiersprache > zu bemühen. Nötig nicht, aber praktisch. Das 2,5 KByte große Maschinenprogramm für den 89S51 über ein Terminalprogramm in den Arduino zu tippen, der es dann über SPI weiterleitet, wäre mir zu aufwändig gewesen. Möglich wärs natürlich gewesen. Wie man mit Windows Bordmitteln die Synchronisation hinbekommt, um den Arduino bei seiner Arbeit nicht zu überfordern (nicht genug RAM, um den Job im Ganzen zu speichern, die ersten Zeichen nach Öffnen des ComPorts werden vom UNO gnadenlos verschluckt) ist mir allerdings unklar. Da wäre ich für Erleuchtung dankbar. Gruß Klaus (der soundsovielte)
DerEinzigeBernd schrieb: > Hilft vielleicht das hier? > https://wiki.tcl-lang.org/page/TclUDP Danke für den Hinweis. Sieht aber im ersten Durchsehen so aus, als bräuchte ich 3 Tage, um das zum Laufen zu bekommen und außerdem ist wohl nur eine 32-bit-Version für Windows vorhanden. Meine Lösung ist typischerweise eine Pipe zu einem kleinen C-Programm, das dann den UDP-Verkehr abwickelt. Pipes oder TCP-Kanäle zu anderen Programmen funktionieren in Tcl ganz hervorragend und sind auch meine Umstandslösung für das DLL-Problem. Ist zwar weniger elegant, aber schneller fertig. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Sieht aber im ersten Durchsehen so aus, als bräuchte ich 3 Tage, um das > zum Laufen zu bekommen Aha. > und außerdem ist wohl nur eine 32-bit-Version für > Windows vorhanden. Und, wo ist das Problem? Brauchst Du zwingend 64-Bit-Programme? Ansonsten liegt der Kram im Sourcecode vor, mit VS sollte es möglich sein, daraus auch eine 64-Bit-DLL zu machen. Hier https://core.tcl-lang.org/tcludp/dir?ci=tip wird beschrieben, wie man das übersetzt; wenn man sich mit VS auskennt, sollte ein 64-Bit-Build keine Raketenwissenschaft sein. Aber vielleicht findest Du ja hier was anderes: https://wiki.tcl-lang.org/page/UDP+for+Tcl
DerEinzigeBernd schrieb: > Hier https://core.tcl-lang.org/tcludp/dir?ci=tip wird beschrieben, wie > man das übersetzt; wenn man sich mit VS auskennt, sollte ein > 64-Bit-Build keine Raketenwissenschaft sein. Danke für die Hinweise und Deine gute Meinung über mich. Ich bin aber vermutlich nicht einmal halb so gut im Programmieren, wie Du denkst. Ich beherrsche nicht einmal make und schon gar nicht VS, ich programmiere zu Fuß, immer eine Datei nach der Anderen. Wenn ich wüßte, wie man Tcl mit einem C-Programm erweitert, hätte ich längst eine eigene UDP-Erweiterung geschriebe. In C die Sytemlibrary mit dem Socketinterface aufzurufen mache ich ja, das funktioniert einwandfrei (mit Borland-C und TCC). Ein in Tcl geschriebenes Unterprogramm für UDP würd ich wohl eingebaut bekommen, zu mehr langts bei mir aber nicht, weil es einfach zuviele andere interessante Projekte gibt und mir langsam die Lebenszeit davonrennt. Gruß Klaus (der soundsovielte)
Da du schon mit C vertraut bist, könntest du dein PC Programm ebenfalls in C oder vielleicht C++ schreiben. Für beide gibt es GUI Bibliotheken.
Ich habe viel Erfahrung mit Tcl, aber wenig mit Tcl unter Windows. Eine kurze Recherche hat aber ergeben, dass es durchaus Tcl-Distributionen für 64Bit-Windows gibt, die TclUDP enthalten, z.B. ActiveTcl (kostenlos aber man muss einen Account anlegen) oder Magicsplat. https://www.activestate.com/products/tcl/ https://www.magicsplat.com/tcl-installer/index.html ActiveState hat bis vor einigen Jahren die Tcl-Entwicklung unterstützt, aber die aktiven (Wortspiel nicht beabsichtigt) Tcl-Leute sind da inzwischen weg und es scheint in der Firma nur noch ein Nischendarsein zu fristen. Magicsplat wird von einem sehr aktiven Mitglied der Tcl-Community gepflegt.
Stefan F. schrieb: > Für beide gibt es GUI Bibliotheken. Ja, aber so bequem wie Tcl/Tk sind die bei weitem nicht. Es hat ja einen Grund, warum Python Tk importiert. Wenn ich mich recht erinnere, war die einzige bequeme GUI-Anwendung für C ein Programmpaket namens XVT, das hatte aber seinen Preis und rechnet sich bei mir leider nicht. Genutzt hätte ich es gerne :-( Just my 2 cents
Klaus S. schrieb: > Es hat ja einen Grund, warum Python Tk importiert. Du könntest natürlich Tk auch aus C heraus nutzen.
R. M. schrieb: > Eine > kurze Recherche hat aber ergeben, dass es durchaus Tcl-Distributionen > für 64Bit-Windows gibt, die TclUDP enthalten, z.B. ActiveTcl (kostenlos > aber man muss einen Account anlegen) oder Magicsplat. Das klingt interessant, danke. Allerdings kommt Magicsplat erstmal 5 Minuten nicht auf die Hufe und durchsucht stattdessen die gesamte Festplatte. Das habe ich vorsichtshalber mal abgebrochen, das kommt erstmal auf eine Spielwiese. Gruß Klaus (der soundsovielte)
DerEinzigeBernd schrieb: > Du könntest natürlich Tk auch aus C heraus nutzen. Eigentlich war ja die Vorstellung von John Osterhout, daß sich die Tcl-Nutzer ihre Basisfunktionen in C selber schreiben und dazulinken. Das hat aber wohl nur so wenige verleitet, es auch zu machen, daß ich nirgendwo eine auch mir verständliche Anleitung dazu gefunden habe. Gehört eben wieder in das Kapitel mit den zu hoch hängenden Früchten ... Gruß Klaus (der soundsovielte)
Ousterhout natürlich. Soviel Rechtschreibung sollte sein.
Klaus S. schrieb: > Gehört eben wieder in das Kapitel mit den zu hoch hängenden Früchten ... Eigentlich hängt das nicht allzu hoch. Falls Du schonmal ein Kommandozeilenprogramm in C geschrieben hast (argc, argv), dann kannst Du im Grunde auch ein Tcl-Kommando mit der ursprünglichen String-API implementieren. Schau' Dir mal die Doku zu den API-Funktionen Tcl_CreateCommand() und Tcl_SetResult an, und/oder wirf mal einen Blick in die Implementierung einer kleinen C-Extension für Tcl (z.B. TclUDP. ;) ).
Das hier könnte auch weiterhelfen, allerdings wird da für die Kommandos die modernere Objekt-API genutzt (hat nichts mit objektorientierter Programmierung zu tun, sondern damit, wie Tcl intern mit den Daten umgeht): https://wiki.tcl-lang.org/page/Hello+World+as+a+C+extension
R. M. schrieb: > Das hier könnte auch weiterhelfen Du machst mich neugierig, ich fühle mich angefixt. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Das 2,5 KByte große Maschinenprogramm für > den 89S51 über ein Terminalprogramm in den Arduino zu tippen, der es > dann über SPI weiterleitet, wäre mir zu aufwändig gewesen Da muß man nichts eintippen. Windows Hyperterminal (zumindest bis Win7 Standardbordmittel) kann auch ganze Dateien sowohl Text als auch Binär senden. Unter Windows 10 gibt es Hyperterminal nicht mehr, allerdings gibt es jede Menge Alternativen die das auch können. Mit Putty sollte es auch funktionieren. Klaus S. schrieb: > Wie man mit Windows Bordmitteln die Synchronisation > hinbekommt, um den Arduino bei seiner Arbeit nicht zu überfordern (nicht > genug RAM, um den Job im Ganzen zu speichern, die ersten Zeichen nach > Öffnen des ComPorts werden vom UNO gnadenlos verschluckt) ist mir > allerdings unklar. Wenn der Arduino Zeichen verschluckt, dann kann aber der PC bzw. das Terminalprogramm nichts dazu. Dann wird es höchste Zeit die Software auf dem Arduino zu untersuchen bzw. zu optimieren. Ich habe auch schon mit einem "kommerziellen" Terminalprogramm und einem eigenen Programm mit diversen µC's kommuniziert, aber Daten werden da keine verschluckt. Das sollte eigentlich auch nicht passieren, wenn auf beiden Geräten die gleichen Übertragungsparameter eingestellt werden.
> und einen Arduino mit Komandos füttern, der > dann die Bytes in den 89S51 klopfte Letztes war also das Kernproblem? Vermutlich waere es einfacher gewesen, den "Arduino" wegzulassen. Und einen guten alten Kandadongle an den hoffentlich vorhandenen Parallelport zu stecken. Wenn es fuer den 89S51 da nicht sogar schon fertige Software gibt... Haette man das bisschen Bitwackelei mit Hilfe des Dongle, moeglicherweise auch schon ohne, schneller hinbekommen. Ich kann mich an einen sehr rudimentaeren JTAG-Adapter fuer in Netzwerkprodukten verbaute 8 bit CPUs erinnern. Der bestand eigentlich nur aus einem DB-25 Stecker und einem 4 MHz Oszillator damit der Contoller einen Takt bekam...
Klaus S. schrieb: > Ja, aber so bequem wie Tcl/Tk sind die bei weitem nicht. Es hat ja einen > Grund, warum Python Tk importiert. Wenn ich mich recht erinnere, war die > einzige bequeme GUI-Anwendung für C ein Programmpaket namens XVT, Naja, "angenehme GUI-Bibliothek" ist IMHO ein Widerspruch in sich. Aber der Grund, warum Pythons mitgelieferte Standardbibliothek seit jeher Tk ist, ist simpel: es war verfügbar, plattformunabhängig, und einfach anzubinden. Sonderlich hübsch war es allerdings nie und ist es bis heute nicht, deshalb gibt es heutzutage natürlich auch Python-Libraries für andere gebräuchliche Libraries wie Qt, wxWidgets und GTK. Die Python-Entwickler in meinem Umfeld und auch ich selbst bauen aber nicht mehr so oft Fatclient-Software mit GUI-Bibliotheken, sondern lieber was mit leichtgewichtigen Webapplikationen. Die muß man nur einmal zentral pflegen, kann viel Rechen- und Grafikaufwand auf die Clients verlagern (poor man's distributed computing quasi), und viele Dinge werden deutlich einfacher.
Klaus S. schrieb: > R. M. schrieb: >> Das hier könnte auch weiterhelfen > > Du machst mich neugierig, ich fühle mich angefixt. Neue Tcl-Befehle in C hinzuzufügen ist wirklich nicht schwer - dasselbe gilt übrigens auch für neue Tk-Widgets. Dein ursprüngliches Problem sollte sich auch in reinem Tcl lösen lassen - ich halte es für wenig zielführend, das in einer anderen Sprache zu tun. Einfach mal in Ruhe die Beschreibung des Encodings etc. für Tcl durchlesen. Sehr empfehlenswert sind übrigens auch Bücher, unter anderem das sehr gute "Practical Programming in Tcl and Tk" von Welsh. Karl Käfer schrieb: > Sonderlich hübsch war es allerdings nie und ist es bis heute nicht, Was aber nicht an Tk liegt sondern daran, dass viele offenbar bei Motif und dem ersten Widget-Set von Tk stehengeblieben sind. TTk und Styles gibt es nun wirklich schon einige Zeit, genauer seit Anfang der 2000er (da steckt sogar noch Code von mir drin :-) > deshalb gibt es heutzutage natürlich auch Python-Libraries für andere > gebräuchliche Libraries wie Qt, wxWidgets und GTK. Welche sich vom Aussehen her übrigens problemlos mit ttk nachempfinden lassen. Karl Käfer schrieb: > Die Python-Entwickler in meinem Umfeld und auch ich selbst bauen aber > nicht mehr so oft Fatclient-Software mit GUI-Bibliotheken, sondern > lieber was mit leichtgewichtigen Webapplikationen. Die muß man nur > einmal zentral pflegen, kann viel Rechen- und Grafikaufwand auf die > Clients verlagern (poor man's distributed computing quasi), und viele > Dinge werden deutlich einfacher. Es hängt immer davon ab, was man machen möchte. Für viele Dinge sind Webapplikationen eine tolle Sache - für andere nicht. Wir arbeiten hier bspw. bei Maschinen-/Gerätesteuerungen schon lange auf einfachen Controllern (früher AVR, jetzt STM32) unter NuttX mit einem angepassten Tcl-Interpreter und angepasster Tk-Bibliothek. D.h. dass 99% des Nutzer-Codes tatsächlich als Tcl-Code vorliegt und wir nur einige wenige Dinge (RT-Komponenten etc.) in C coden. Apropos "Fat-Client-Libs": nach dem finalen Aufräumen (Code für nicht benötigte Widgets etc. rauswerfen etc.) steckt das komplette RTOS samt Tk-Oberfläche, Interpreter und User-Tcl-Code in unter 192k Flash und läuft bereits auf einem Atmega2560 mit 10"-Touch flüssig. Ein weiterer Vorteil (kennt heute ja kaum noch jemand): ich schalte das Gerät ein und nach 0,5s ist die Oberfläche da und das Ding betriebsbereit - in welchem Style (Aqua, GTK, Qt, Motif etc.) auch immer ;-) Man kann also durchaus die Größe deutlich eindampfen, ohne Programmierkomfort zu verlieren: ich schreibe die Oberflächen genau so einfach in Tcl/Tk, wie ich es für den PC tue - wenn gewünscht sogar zur Laufzeit. Wobei Steuerungen dieser Art natürlich den Vorteil haben, dass Bildschirmgröße etc. üblicherweise unveränderlich sind, man also gut mit dem Placer arbeiten kann.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Dein ursprüngliches Problem sollte sich auch in reinem Tcl lösen lassen Ja. seit Dirks Hinweis auf "fconfigure $filehandle -translation binary" kann ich in Tcl mit binären Daten genauso elegant umgehen wie mit Characterfeldern beliebiger Normierung. Die Umwandlung in Hexzahlen funktioniert jetzt auch einwandfrei. Damals habe ich mir einen Wolf gesucht im Internet, um was über binäre Daten in Tcl zu finden. Heute gibts ne ganze Webseite dazu mit allen Informationen, die mir damals gefehlt haben. Da waren die 10 Minuten für das C-Programm gut angelegte Zeit, ich hatte schon genug Zeit mit den angeblich funktionierenden Programmen Ponyprog und avrdude verballert. Manchmal hat man einfach die Schnauze voll und pfeift auf akademische Sortenreinheit. Gruß Klaus (der soundsovielte) P.S. Meine beiden Tcl-Bücher von John Ousterhout und Mark Harrison/Michael McLennan schweigen sich über Binärdaten aus, hinter "Bildschirm" kommt im Stichwortberzeichnis gleich "bind".
... schrieb: > Und einen guten alten Kandadongle an den hoffentlich vorhandenen > Parallelport zu stecken. > Wenn es fuer den 89S51 da nicht sogar schon fertige Software gibt... Hatte ich oben beschrieben, daß ich das schon gemacht hatte. Oder ist Dir PonyProg unbekannt? Gruß Klaus (der soundsovielte)
Karl Käfer schrieb: > Naja, "angenehme GUI-Bibliothek" ist IMHO ein Widerspruch in sich. XVT schon einmal angeschaut? Gruß Klaus (der soundsovielte)
Chris D. schrieb: > Apropos "Fat-Client-Libs": nach dem finalen Aufräumen (Code für nicht > benötigte Widgets etc. rauswerfen etc.) steckt das komplette RTOS samt > Tk-Oberfläche, Interpreter und User-Tcl-Code in unter 192k Flash und > läuft bereits auf einem Atmega2560 mit 10"-Touch flüssig. Klingt saumäßig interessant. Wenn ich nicht gerade (wie im Moment) eine Halcon-Bildverarbeitung brauchen würde, täte sowas für einige meiner Maschinen auch gut passen. Gibts dazu mehr Info oder ist das confidential? Gruß Klaus (der soundsovielte)
Chris D. schrieb: > Karl Käfer schrieb: >> Sonderlich hübsch war es allerdings nie und ist es bis heute nicht, > > Was aber nicht an Tk liegt sondern daran, dass viele offenbar bei Motif > und dem ersten Widget-Set von Tk stehengeblieben sind. Ach, das war halt Motif. War noch nie besonders hübsch, tat aber immer sang- und klanglos seinen Dienst. > TTk und Styles > gibt es nun wirklich schon einige Zeit, genauer seit Anfang der 2000er > (da steckt sogar noch Code von mir drin :-) Vielen Dank für Deinen Beitrag dazu! >> deshalb gibt es heutzutage natürlich auch Python-Libraries für andere >> gebräuchliche Libraries wie Qt, wxWidgets und GTK. > > Welche sich vom Aussehen her übrigens problemlos mit ttk nachempfinden > lassen. Den Absprung zu Themed-Tk habe ich leider irgendwie verpaßt, aber ich habe schon einige sehr hübsch gestaltete Oberflächen damit gesehen. Vielleicht sollte ich mir das doch noch einmal anschauen. > Karl Käfer schrieb: >> Die Python-Entwickler in meinem Umfeld und auch ich selbst bauen aber >> nicht mehr so oft Fatclient-Software mit GUI-Bibliotheken, sondern >> lieber was mit leichtgewichtigen Webapplikationen. Die muß man nur >> einmal zentral pflegen, kann viel Rechen- und Grafikaufwand auf die >> Clients verlagern (poor man's distributed computing quasi), und viele >> Dinge werden deutlich einfacher. > > Es hängt immer davon ab, was man machen möchte. Für viele Dinge sind > Webapplikationen eine tolle Sache - für andere nicht. > > Wir arbeiten hier bspw. bei Maschinen-/Gerätesteuerungen schon lange auf > einfachen Controllern (früher AVR, jetzt STM32) unter NuttX mit einem > angepassten Tcl-Interpreter und angepasster Tk-Bibliothek. D.h. dass 99% > des Nutzer-Codes tatsächlich als Tcl-Code vorliegt und wir nur einige > wenige Dinge (RT-Komponenten etc.) in C coden. Das ist natürlich ein anderer Anwendungsfall. Aber beim TO geht es ja um einen PC-Client, und da bietet sich das von mir beschriebene Vorgehen IMHO durchaus an. Das machen ja auch schon einige so, das neue PgAdmin4 ist zum Beispiel eine Flask-Webapplikation. Wenn das lokal aufgerufen wird, dann wird sie in einem lokalen Minimal-Browser ausgeführt, aber man kann diese Webapplikation eben auch ganz einfach im Servermodus betreiben und dann netzwerkweit nutzen, ohne etwas auf die Clients ausrollen zu müssen.
Klaus S. schrieb: > Karl Käfer schrieb: >> Naja, "angenehme GUI-Bibliothek" ist IMHO ein Widerspruch in sich. > > XVT schon einmal angeschaut? Das habe ich mir vor vielen Jahren einmal angesehen, ebenso wie einige andere GUI-Designer, aber wirklich überzeugt hat mich keines davon. Das Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA, da beißt die Maus keinen Faden ab und auch Softwaretools helfen allenfalls dabei, diesen Schmerz ein wenig zu lindern. Auch das ist ein Grund warum ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende lokal auf einem Fatclient laufen sollen.
Karl Käfer schrieb: > Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA Dann wäre doch die beste Methode, das Anderen zu überlassen :-) Karl Käfer schrieb: > Auch das ist ein Grund warum > ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende > lokal auf einem Fatclient laufen sollen. Welches Tool hilft Dir denn dabei, den/die "PITA" ignorieren zu können? Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Karl Käfer schrieb: >> Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA > > Dann wäre doch die beste Methode, das Anderen zu überlassen :-) Nichts(!) lieber als das! :) > Karl Käfer schrieb: >> Auch das ist ein Grund warum >> ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende >> lokal auf einem Fatclient laufen sollen. > > Welches Tool hilft Dir denn dabei, den/die "PITA" ignorieren zu können? Ein Webbrowser, der nur ein einziges, vollflächiges HTML-Widget hat, ist mit einem GUI-Toolkit wie wxWidgets oder Qt schnell gebaut. Für das Backend verwende ich Python, in einfachen Fällen mit Flask oder für größere Webapps auch gerne mal mit Django. Ach so, ja, und natürlich Python: das ist flott, ultrastabil, sehr angenehm beim Coden, dazu gibt es eine geradezu unendlich große Vielfalt an mitgelieferten, und erst Recht an externen Bibliotheken. Und in den allerdings ziemlich seltenen Fällen, daß etwas mal nicht schnell genug oder gar nicht erst verfügbar ist, läßt sich Python ganz leicht mit C- und / oder C++ erweitern.
Klaus S. schrieb: > Chris D. schrieb: >> Apropos "Fat-Client-Libs": nach dem finalen Aufräumen (Code für nicht >> benötigte Widgets etc. rauswerfen etc.) steckt das komplette RTOS samt >> Tk-Oberfläche, Interpreter und User-Tcl-Code in unter 192k Flash und >> läuft bereits auf einem Atmega2560 mit 10"-Touch flüssig. > > Klingt saumäßig interessant. Wenn ich nicht gerade (wie im Moment) eine > Halcon-Bildverarbeitung brauchen würde, täte sowas für einige meiner > Maschinen auch gut passen. Gibts dazu mehr Info oder ist das > confidential? Ja, das ist leider nur zum "internen Gebrauch" ;-) Da hab ich/bzw. wir einfach über die Jahre viel Zeit und Arbeit reingesteckt, die wir uns jetzt natürlich vergüten lassen. Karl Käfer schrieb: > Das habe ich mir vor vielen Jahren einmal angesehen, ebenso wie einige > andere GUI-Designer, aber wirklich überzeugt hat mich keines davon. Das > Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA, da > beißt die Maus keinen Faden ab und auch Softwaretools helfen allenfalls > dabei, diesen Schmerz ein wenig zu lindern. Auch das ist ein Grund warum > ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende > lokal auf einem Fatclient laufen sollen. Hehe, da ist was dran. Es ist auch weniger die Positionierung der Elemente als eine vernünftige Bedienbarkeit - ist gerade bei Maschinensteuerungen nicht einfach, je nachdem, wer später davorsteht (Profi, Facharbeiter, Angelernter usw.). Die ganzen Gui-Designer, die ich mir angeschaut habe (durchaus nicht nur für Tk) helfen einfach nicht wirklich, weil man letztendlich doch jedes Widget mit entsprechenden Attributen usw. versehen muss und das dann in Klickorgien ausartet. Da kann man es auch direkt im Editor coden, da ist man deutlich schneller. Wenn man natürlich alle halbe Jahre mal einer Oberfläche baut, dann kann das interessant sein, weil man schlicht viele Optionen etc. vergisst. Ich handhabe das hier mit der Positionierung so, dass ich mir anfangs per Code alle nötigen Widgets erstelle und dann die Oberfläche starte. Ein Skript läuft den ganzen Widgetbaum dann ab und ergänzt die Widgets durch passende Bindings für Mausziehen + gehaltene Zusatztaste. Damit kann ich dann die Widgets einzeln dorthin schieben, wo ich sie haben möchte. Dann nochmal eine Tastenkombi und die Positionen werden als Tcl-Paket für den Placer geliefert. Dann nur noch reinkopieren und die Widgest sitzen schon mal dort, wo sie sein sollen. Also so ähnlich wie bei PCB-Programmen, wo die Gehäuse erstmal alle auf einem Haufen liegen und man sie dann nach und nach dorthin zieht, wo es einem günstig erscheint. Das funktioniert natürlich nur beim Placer, aber wie gesagt: Maschinensteuerungen haben eher selten veränderliche Bildschirmgrößen :-) Das ist über die Jahre ein wirklich nützliches "Tool" geworden, obwohl ich das mal an einem Vormittag programmiert habe. Aber ich mache generell viele Anpassungen zur Laufzeit. geht einfach am schnellsten. Karl Käfer schrieb: > Den Absprung zu Themed-Tk habe ich leider irgendwie verpaßt, aber ich > habe schon einige sehr hübsch gestaltete Oberflächen damit gesehen. > Vielleicht sollte ich mir das doch noch einmal anschauen. Ist eine schöne Sache - aber wenn Du mit Deinen anderen Widgetsets zufrieden bist, dann lohnt das wohl kaum. Letztendlich tut es jedes Set. Man nimmt das, was man aus dem FF kennt.
Chris D. schrieb: > Die ganzen Gui-Designer, die ich mir angeschaut habe (durchaus nicht nur > für Tk) helfen einfach nicht wirklich, weil man letztendlich doch jedes > Widget mit entsprechenden Attributen usw. versehen muss und das dann in > Klickorgien ausartet. Ja klar muss man jedem Widget/Control sagen, wie es sich verhalten soll. Das tut aber jeder Normaldenkende doch lieber mit einer überschaubaren Zahl Mausklicks als mit einer Flut von Programmzeilen. > Da kann man es auch direkt im Editor coden, da ist > man deutlich schneller Definitiv: NEIN. Nicht einmal näherungsweise. > Letztendlich tut es jedes Set. Man nimmt das, was man aus dem FF kennt. Klar, wenn man die Widgets/Controls kennt, ist das natürlich überaus hilfreich. Und zwar ganz unabhängig davon, ob man sie mittels Mausklicks oder mittels Quelltextzeilen parametriert.
Chris D. schrieb: > Karl Käfer schrieb: >> Das habe ich mir vor vielen Jahren einmal angesehen, ebenso wie einige >> andere GUI-Designer, aber wirklich überzeugt hat mich keines davon. Das >> Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA, da >> beißt die Maus keinen Faden ab und auch Softwaretools helfen allenfalls >> dabei, diesen Schmerz ein wenig zu lindern. Auch das ist ein Grund warum >> ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende >> lokal auf einem Fatclient laufen sollen. > > Hehe, da ist was dran. Es ist auch weniger die Positionierung der > Elemente als eine vernünftige Bedienbarkeit - ist gerade bei > Maschinensteuerungen nicht einfach, je nachdem, wer später davorsteht > (Profi, Facharbeiter, Angelernter usw.). Natürlich, bitte versteh' mich nicht falsch: ich kenne die Vorzüge von guten Mensch-Maschine-Schnittstellen und will deren Notwendigkeit gerade für Menschen, die keine hauptberuflichen Computerbenutzer sind, niemals abstreiten. Und genau deswegen sind solche GUI-Designer auch IMHO sehr sinnvoll, gerade in der Kommunikation und Zusammenarbeit mit Menschen, die sich vornehmlich mit User Interface Design und Usability beschäftigen oder die aus der fachlichen Umfeld kommen. Die können mir nämlich mit so einem GUI-Designer gleich eine fertige Oberfläche liefern und ich muß die nur noch mit dem benötigten Code ergänzen. Das kommt meiner Eigenschaft als bekennender Faulpelz natürlich sehr entgegen. > Die ganzen Gui-Designer, die ich mir angeschaut habe (durchaus nicht nur > für Tk) helfen einfach nicht wirklich, weil man letztendlich doch jedes > Widget mit entsprechenden Attributen usw. versehen muss und das dann in > Klickorgien ausartet. Da kann man es auch direkt im Editor coden, da ist > man deutlich schneller. Wenn man natürlich alle halbe Jahre mal einer > Oberfläche baut, dann kann das interessant sein, weil man schlicht viele > Optionen etc. vergisst. Das ist (finde ich) einer der schönen Punkte an HTML: es gibt relativ wenige Elemente und um die Positionierung und Ausrichtung kann sich der Webbrowser kümmern, der das regelmäßig besser hinbekommt als viele der Layout-Manager, die wir von GUI-Toolkits und -Frameworks kennen. Und dank CSS habe ich damit auch recht große, flexible gestalterische Spielräume. Erschwerend kommt in meinem Fall hinzu, daß ich ohnehin regelmäßig Sachen mit HTML mache, insofern ich das zu 99,9 % aus dem Kopf schreibe. Bei den GUI-Toolkits und -Frameworks dagegen muß ich ständig in die Dokumentation schauen, die ich dieses oder jenes Verhalten umsetzen kann. Andererseits kann man mit GUI-Toolkits und -Frameworks viel einfacher eine Interaktivität in die GUI einbauen, das ist bei HTML "dank" ECMA-Skript ja manchmal auch kein reines Vergnügen. > Ich handhabe das hier mit der Positionierung so, dass ich mir anfangs > per Code alle nötigen Widgets erstelle und dann die Oberfläche starte. > Ein Skript läuft den ganzen Widgetbaum dann ab und ergänzt die Widgets > durch passende Bindings für Mausziehen + gehaltene Zusatztaste. Damit > kann ich dann die Widgets einzeln dorthin schieben, wo ich sie haben > möchte. Dann nochmal eine Tastenkombi und die Positionen werden als > Tcl-Paket für den Placer geliefert. Dann nur noch reinkopieren und die > Widgest sitzen schon mal dort, wo sie sein sollen. Das hört sich spannend an und erspart einem natürlich viel von der bösen Boilerplate-Arbeit, die GUI-Entwicklung so nervig macht. > Karl Käfer schrieb: >> Den Absprung zu Themed-Tk habe ich leider irgendwie verpaßt, aber ich >> habe schon einige sehr hübsch gestaltete Oberflächen damit gesehen. >> Vielleicht sollte ich mir das doch noch einmal anschauen. > > Ist eine schöne Sache - aber wenn Du mit Deinen anderen Widgetsets > zufrieden bist, dann lohnt das wohl kaum. Naja, ehrlich gesagt baue ich mir GUI heute im Grunde nur noch, wenn ich große Datensätze fürs Supervised Learning labeln will. Dann hat das echte Vorteile: Datensatz laden und darstellen, ein Tastendruck, schon ist der Datensatz mit dem gewünschten Label versehen und die Veranstaltung fängt wieder von vorne an. Für sowas reicht dann auch Plain-Tkinter, aber wie gesagt, Themed-Tk schaue ich mir vielleicht doch nochmal an. Immerhin hat die Wissenschaft mittlerweile in mehreren Studien festgestellt, daß die Benutzer einer hübschen Software mehr vertrauen, und dann auch Störungen und Fehler weniger negativ wahrnehmen. Unter dem Gesichtspunkt wäre ttk also ein Dienst an den Leuten, die meine Datensätze labeln. :) Außerdem hat Tkinter unter Python natürlich den gewaltigen Vorteil, daß es schon in der Standarddistribution integriert und darum überall vorhanden ist, wo Python installiert ist. Das vereinfacht das Deployment enorm. Ach so, in den neueren Versionen (seit Python3, glaube ich) setzt Tkinter auch eher auf Tix, insofern sieht das mittlerweile schon deutlich besser als als unter Python 2.x. Aber ttk scheint ja nach allem, was ich in den letzten Stunden gesehen habe, ein überschaubarer Aufwand zu sein. Lieben Dank für Deinen Hinweis! > Letztendlich tut es jedes Set. Man nimmt das, was man aus dem FF kennt. Ja, keine Frage!
c-hater schrieb: > Chris D. schrieb: > Ja klar muss man jedem Widget/Control sagen, wie es sich verhalten soll. > Das tut aber jeder Normaldenkende doch lieber mit einer überschaubaren > Zahl Mausklicks als mit einer Flut von Programmzeilen. Ich habe keine Ahnung, was Du benutzt, aber die "Flut von Programmzeilen" beschränkt sich bei Tk-Widgets auf praktisch immer nur eine, nicht allzu lange. >> Da kann man es auch direkt im Editor coden, da ist >> man deutlich schneller > > Definitiv: NEIN. Nicht einmal näherungsweise. Hier definitv "Doch" - und ziemlich deutlich. Ich hab beides getestet und insbesondere, wenn man mit automatischer Code-Ergänzung (hat eigentlich jede IDE) arbeitet und sowieso Eingaben per Tastatur (Name, Bindings etc.) vornehmen muss. Der Wechsel zwischen Maus und Tastatur und scrollen durch Menüs ist einfach sehr zeitraubend. Allerdings sollte man da sein Widget-Set auch wirklich gut kennen. Wenn man die entsprechenden Optionen erst nachschauen muss, dann ist ein GUI-Editor besser. Das ist ähnlich wie mit der Shell/Kommandozeile und Dateimanagern oder LibreOffice und LaTeX. Wer nur ab und zu etwas macht, nimmt GUIs, wer ständig damit arbeitet, nimmt das direkte Werkzeug.
Karl Käfer schrieb: Das ist (finde ich) einer der schönen Punkte an HTML: es gibt relativ > wenige Elemente und um die Positionierung und Ausrichtung kann sich der > Webbrowser kümmern, der das regelmäßig besser hinbekommt als viele der > Layout-Manager, die wir von GUI-Toolkits und -Frameworks kennen. Und > dank CSS habe ich damit auch recht große, flexible gestalterische > Spielräume. Auf jeden Fall :-) > Erschwerend kommt in meinem Fall hinzu, daß ich ohnehin regelmäßig > Sachen mit HTML mache, insofern ich das zu 99,9 % aus dem Kopf schreibe. > Bei den GUI-Toolkits und -Frameworks dagegen muß ich ständig in die > Dokumentation schauen, die ich dieses oder jenes Verhalten umsetzen > kann. Exakt das meinte ich. Wenn ich etwas beherrsche, dann wäre es unsinnig, da etwas anderes (und sei es auch nur ein Hilfstool für GUIs) zu verwenden. Ich bin da einfach schneller, wenn ich es direkt so runterschreibe. > Ach so, in den neueren Versionen (seit Python3, glaube ich) setzt > Tkinter auch eher auf Tix, insofern sieht das mittlerweile schon > deutlich besser als als unter Python 2.x. Aber ttk scheint ja nach > allem, was ich in den letzten Stunden gesehen habe, ein überschaubarer > Aufwand zu sein. Lieben Dank für Deinen Hinweis! Gern :-)
Chris D. schrieb: > Ich habe keine Ahnung, was Du benutzt Meist VS. Kenne auch vieles andere, aber der Komfort des VS (insbesondere für Windows.Forms) ist unerreicht. > aber die "Flut von > Programmzeilen" beschränkt sich bei Tk-Widgets auf praktisch immer nur > eine, nicht allzu lange. Dann können sie nicht sehr mächtig sein. Punkt. Nehmen wir mal zwei Beispiele aus Windows.Forms, das DataGridView und das TableLayoutPanel. Durch was würdest du das in Tk ersetzen? Ich sage dir dann, was der Tk-Kram alles NICHT kann...
Klaus S. schrieb: > Ich bin deshalb auf der Suche nach einer Programmiersprache, die ähnlich > komfortabel das Ansprechen des ComPorts erlaubt, aber weniger Fehler > macht Ich weiß nicht ob du direkt GUI support haben möchtest, aber wenn du C nehmen würdest, könntest du das hier nutzen: Läuft unter Windows und Linux. https://www.teuniz.net/RS-232/ Die benötigten Funktionsaufrufe sind echt überschaubar.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.