Hallo! Nach der Portierung vom PonyProg nach Qt, beschäftige ich mich jetzt mit der Testerei vom Programm. Hat jemand Interesse/Möglickeit das Projekt unter Windows und OSX zu testen? Configurator ist CMake basiert und für andere Systeme muss CMakeLists.txt angepasst/gefixt werden. Ich kann es nur unter Linux testen, da ich auch mit viel anderen Sachen beschäftigt bin. ;) Die Quelltexte werde ich nach dem testen entweder an den Hauptentwickler schicken, oder als separates OpenSource Projekt veröffentlichen, falls Claudio sich nicht meldet. Grüße aus Hannover Eduard
:
Verschoben durch User
Eduard schrieb: > Nach der Portierung vom PonyProg nach Qt, beschäftige ich mich jetzt mit > der Testerei vom Programm. Wie realisierst du den Zugriff auf die Hardware? Druckerport und Serielle wollen fachmännisch angesprochen werden .... Von QT aus doch nicht direkt, oder?
Beim PonyProg ist es bereits implementiert, es gibt keine Notwendigkeit das zu überarbeiten. Wenn schon, dann in Qt5 ist die Klasse QSerialPort vorhanden. Hauptsache man hat die Zugriffsberechtigung. Im Moment ist nur das alte "V C++ GUI" Framework vom 2003 durch Qt ersetzt.
Eduard schrieb: > Im Moment ist nur das alte "V C++ GUI" Framework vom 2003 durch Qt > ersetzt. Und das bringt welche Änderung? Ich meine, außer der Tatsache, dass das Programm dadurch sicherlich deutlich fetter und langsamer geworden ist... Also ist die Frage eigentlich nicht die nach den Änderungen an sich, sondern die nach irgendeiner positiven Änderung. Und zwar positiv aus Sicht des Benutzers...
Ich habe es noch nicht gesehen, denke aber, dass die GUI besser aussieht als die bisherige Klötzchen-Grafik. Und die paar MB hält mein Rechner auch aus. Ich könnte für Mac testen, wenn du noch niemand hast.
Diese Idee finde ich sehr schön: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=169215&p=1087032 Soll auf RasPi laufen und wird einfach per VPN bedient. Damit haben sich auch die LPT oder RS232 Probleme erledigt. Hätte schon fast 11€ für einen RasPi Zero W investiert, aber brauche gerade keinen Programmer.
> sondern die nach irgendeiner positiven Änderung
Wenn es auf einem Raspi läuft, kann man alles, was auf dem Basteltisch
liegt, unbesorgt zusammenstecken. Ein Fehler kostet 15€. Die teuren
Rechner sind über das Wlan geschützt.
Fritz G. schrieb: > Ich habe es noch nicht gesehen, denke aber, dass die GUI besser aussieht > als die bisherige Klötzchen-Grafik. Wen interessiert, wie das GUI eines rein technischen Tools aussieht? Das muss nur funktional und schnell sein, mehr nicht. Alles, was nicht mehr Funktionalität bringt oder gar die Geschwindigkeit der bereits verfügbaren Funktionalität nennenswert senkt, ist für'n Garten, denn es senkt die Produktivität des Werkzeugs. Das ist so nützlich wie 'ne Ballonkette an einem Hubschrauber. Klar, schön bunt, aber der Hubschrauber wird zumindest in seiner Einsatzfähigkeit eingeschränkt und verbraucht mehr Sprit, schlimmstenfalls stürzt er sogar ab. Nur komplette Vollidioten halten sowas für einen Fortschritt!
Das Ziel ist, dass das Programm unter Linux aus den Repos installiert werden kann. Ohne per Hand das Projekt zu kompilieren. Das alte Framework mit viel Krücken ist tot. Und das Ziel ist nicht das schön aussehende Program. Schade, dass einige "Kritiker" es nicht verstehen. ;)
Dann ist sicher die Kombi das Optimale. Ein schickes Programm als Paket auf einem Stand Alone RasPi.
Angehängte Dateien:
c-hater schrieb: > Nur komplette Vollidioten halten sowas für einen Fortschritt! Das kann nicht sein. Ich halte es für einen Fortschritt. Also stimmt diese Aussage schon mal nicht. Ich denke auch nicht, dass seine Version merklich langsam sein wird. Gut, es sollen ja noch Leute am Leben sein, die noch alles in Assembler programmieren. Weil sie C nicht verstehen. Habe ich halt gehört. Ich war vorhin unterwegs und habe mir das erst jetzt mal angesehen: o Für macOS gibt es das gar nicht (deswegen habe ich mir damals anscheinend was anderes gesucht, AVRFuse tut tadellos) Folgendes bezieht sich auf die Original-Webseite http://www.lancos.com/prog.html: o Das Windows-Programm stammt aus 2008, lässt sich auf Win7 64-bit nicht installieren. o Aufgrund des Alters gehe ich davon aus, dass neuere AVRs nicht unterstützt werden Es gibt eine neuere Version 2.08c auf sourceforge, damit lässt es sich auf Win7 64-bit installieren. Aber schön ist es nicht. Es dürften trotzdem einige neuere AVRs fehlen, z.B. die PA, PB Typen. Der gute Mann hat anscheinend die Login-Daten für seine Webseite vergessen oder will sie nicht mehr pflegen. Auf http://ponyprog.sourceforge.net/phorum/list.php?2 tut sich noch etwas. Auf http://sonix.szm.com hat sich auch jemand bemüht. Vielleicht möchte Eduard sich da etwas reinhängen und eine neue, schöne Webseite bauen. Schön wäre es, wenn du die Mac Version auf Macports.com einstellen könntest, da würde man es am ehesten suchen. Sonst halt statisch linken, sofern es Open Source ist, siehe dazu http://stackoverflow.com/questions/12654613/static-linking-qt-with-open-source-version . Es soll dann auch kleiner sein, als wenn man sich das ganze QT-Zeugs installiert.
Fritz G. schrieb: > Der gute Mann hat anscheinend die Login-Daten für seine Webseite > vergessen oder will sie nicht mehr pflegen. Moin! Claudio hat auf meine Email geantwortet, also es wird eine Aktualisierung des Projektes geben. Das freut mich sehr. 64-bit ist auch so ein Problem, nach der Umstellung wird das Problem auch gelöst. Auch die Erkennung von USB wird eingebaut. Den Hauptentwickler kann ich sehr gut verstehen, wenn nur er beim Projekt aktiv ist und keiner so wirklich hilft...
c-hater schrieb: > Das muss nur funktional und schnell sein, mehr nicht. Alles, was nicht > mehr Funktionalität bringt oder gar die Geschwindigkeit der bereits > verfügbaren Funktionalität nennenswert senkt, ist für'n Garten, denn es > senkt die Produktivität des Werkzeugs. Wo hat er denn geschrieben, dass er irgendwas nennensert langsamer gemacht hat? Hast du diese neue Version von PonyProg schon getestet und für zu langsam befunden? Was genau war dir zu langsam im Vergleich zur Originalversion? > Nur komplette Vollidioten halten sowas für einen Fortschritt! Was "komplette Vollidioten" vor allem tun, ist ihr Urteil über Dinge abgeben, die sie gar nicht kennen.
Rolf M. schrieb: > Wo hat er denn geschrieben, dass er irgendwas nennensert langsamer > gemacht hat? Nirgendwo. Genau das ist ja das, was ich kritisiere. > Hast du diese neue Version von PonyProg schon getestet und > für zu langsam befunden? Nein. Aber etliche andere QT-Ports bewährter Windows-Programme. Ausnahmslos alle waren deutlich fühlbar langsamer und ausnahmslos alle waren um ein vielfaches fetter. Und natürlich braucht man das nicht einmal wirklich zu testen. Es genügt vollkommen, sich den qt-Code reinzuziehen. Jeder Nicht-Vollidiot wird ohne jeden weiteren Test aus dem Stand verstehen, dass ein derart fetter Abstraktionslayer nicht ohne den entsprechenden Impact auf Codesize und Performance abgehen kann...
c-hater schrieb: > Jeder Nicht-Vollidiot wird > ohne jeden weiteren Test aus dem Stand verstehen, dass ein derart fetter > Abstraktionslayer nicht ohne den entsprechenden Impact auf Codesize und > Performance abgehen kann... Da hast du völlig recht. In deiner kleinen 8-bit AVR Welt ist das echt eine Performance-Desaster. Kurz getestet: Eine 70000 Zeilen Datei in Kate (ein Qt5-Programm) geöffnet, dauert vielleicht 200ms, da hat man noch nicht einmal an ein Krokodil gedacht, ist die Datei schon offen. Der Speicherverbrauch ist auch enorm: 130MB (unter KDE, was auch Qt ist, daher sind alle Libs schon geladen). Es gibt aber Leute, die haben CPUs mit mehr als 20MHz und genug RAM. Also, auf einen 6 Jahre alten Rechner, noch dazu in einer virtuellen Maschine, ist keinerlei Langsamkeit oder Verzögerung beim Arbeiten mit Qt-Programmen zu sehen. Vielleicht solltest du mal deinen IBM-XT mal durch etwas aus diesem Jahrtausend ersetzen. Den musst du dann nicht mehr in Assembler programmieren.
:
Bearbeitet durch User
c-hater schrieb: > Rolf M. schrieb: > >> Wo hat er denn geschrieben, dass er irgendwas nennensert langsamer >> gemacht hat? > > Nirgendwo. Genau das ist ja das, was ich kritisiere. Du kritisierst, dass es keinen Anhaltspunkt für deine zusammenphantasierte Verlangsamung gibt? >> Hast du diese neue Version von PonyProg schon getestet und >> für zu langsam befunden? > > Nein. Aber etliche andere QT-Ports bewährter Windows-Programme. Na wenn du da mit "etlichen" Erfahrung hast, dann kannst du sicher ein paar Beispiele nennen. > Und natürlich braucht man das nicht einmal wirklich zu testen. Es genügt > vollkommen, sich den qt-Code reinzuziehen. Du hast dir den ganzen Quellcode von Qt angeschaut und daran die Geschwindigkeit erkannt? Hast du denn auch schon mal ein Qt-Programm geschrieben? > Jeder Nicht-Vollidiot wird ohne jeden weiteren Test aus dem Stand > verstehen, dass ein derart fetter Abstraktionslayer nicht ohne den > entsprechenden Impact auf Codesize und Performance abgehen kann... Natürlich gibt es einen Overhead. Der ist aber bei heutigen PCs vernachlässigbar. Selbst auf einem Raspi läuft Qt ausreichend schnell. Dafür gewinnt man einiges an Komfort und Plattformunabhängigkeit. Eine Bohrmaschine kostet auch mehr als eine Kurbel und braucht Strom. Trotzdem bohrt sich heute keiner mehr mit der Kurbel ein Loch in die Wand, wenn ausreichend Strom vorhanden ist und dieser auch nicht nennenswert was kostet.
Rolf M. schrieb: > Hast du denn auch schon mal ein Qt-Programm > geschrieben? Natürlich hat er. In Assembler!
Fritz G. schrieb: > Natürlich hat er. In Assembler! Assembler ist doch für Weicheier! So etwas konnten wir uns damals gar nicht leisten. Da gab's ein Blatt Papier mit Mnemonics und Hex-Werten. Befehle auf der Y-Achse, Adressierungsarten auf der X-Achse. Cut und Paste wurde noch physikalisch mit der Schere und Klebstoff durchgeführt.
Ihr durftet Papier und Bleistift verschwenden? Wir mussten die Programme direkt in weggeworfene Filmstreifen stanzen. Für Copy&Paste hatten wir keinen Klebstoff übrig. Mit dem wertvollen Leim klebten wir die Filmenden zur Hauptschleife zusammen. http://www.deutsches-museum.de/fileadmin/Content/010_DM/020_Ausstellungen/060_Kommunikation/040_Informatik/020_Ausstellung/050_Universalrechner/Z3_Z4/Z3_Lesegeraet_1000b_CD_67989.jpg Weichei!
Angehängte Dateien:
-
pony.png
67 KB
Moin! Wir testen jetzt mit Claudio das portierte Programm. Im Moment ist nur die "alpha" Phase. Vielleicht dauert es so eine bis zwei Wochen, bis die Quelltexte freigegeben werden. Das entscheidet der Maintainer. Folgendes war gemacht: 1. Minimieren der Suche in internen Strukturen, in einigen Programmabschnitten war sie überflüssig. 2. Viele Textoperationen sind durch QString Klasse ersetzt gewesen. 3. Basisbibliothek ist Qt4 oder Qt5, getestet mit Qt 4.8, Qt 5.6 4. Minimieren der Abhängigkeiten ist noch nicht komplett. 5. Minimieren des Speicherverbrauchs, vermeiden von festen Arraygrößen: noch nicht komplett. 6. Der Hexeditor ist das OpenSource Widget QHexEdit Anbei ist das aktuelle Bild des Programms
Sind denn inzwischen die Fuse-Settings vom AVR eindeutig gekennzeichnet? Ich möchte nicht wissen, wie viele verfuste AVR's auf die Rechnung von PonyProg gehen. Ich muß dazu sagen: Aus diesem Grund habe ich PonyProg ca. 2003 zum letzten Mal verwendet... Trotzdem: Ich wünsche viel Erfolg! Norbert
Norbert schrieb: > Trotzdem: Ich wünsche viel Erfolg! Danke! Mit den Quelltexten beschäftige ich mich seit einem Monat, habe ich gesehen, dass die Beschriftungen für Fuse von AVR's eingebaut sind. Nur, ob sie korrekt sind, kann ich nicht sagen. Ich habe nur die PIC und 24x mit dem Programm geflasht. Werde ich aber extra den Punkt prüfen.
Ich wäre daran interessiert ein Bundle für MAC OSX zu testen. Namaste
:
Bearbeitet durch User
Angehängte Dateien:
-
atmega.png
55 KB
Bin gerade am testen vom Fuse Fenster. S. Anhang. Winfried J. schrieb: > Ich wäre daran interessiert ein Bundle für MAC OSX zu testen. Die CMake Dateien habe ich auch für dieses System eingerichtet. Es kann aber sein, dass da welche Fehler sind. Hoffentlich, Claudio kann sie gerade ziehen. Ich habe nur die Möglichkeit, diese Einstellungen für Linux zu testen (Distribution ab dem Jahr 2014 und egal für welchen Prozessor).
Angehängte Dateien:
-
ponyfuse.png
100 KB
Hallo! Die aktuellen Quelltexte befinden sich jetzt im Branch https://github.com/lancos/ponyprog/tree/wip/eduard/patches Claudio wird demnächst meine Patches übernehmen, jetzt ist er sehr beschäftigt. Aber mir kann man die Änderungen zuschicken. Kontaktadresse findet Ihr in der Datei aboutmdlg.cpp :) Unter Windows ist es möglich das Projekt mit Hilfe von QtCreator zu übersetzen, auf Linux ist es möglich mit qmake, oder beliebter IDE zu erledigen. Im Moment versuche ich alles in qmake pro Datei zu integrieren, auch die Erstellung der Installationsdateien, wie deb, rpm. Nur habe ich keine Erfahrung mit, bis jetzt habe ich alles mit cmake gemacht. Hat jemand eine Möglichkeit zu helfen? Vielen Dank! p.s. Auf dem Bild ist das aktuelle Fuse/Lock Fenster zu sehen.
c-hater schrieb: >> Hast du diese neue Version von PonyProg schon getestet und >> für zu langsam befunden? > > Nein. Aber etliche andere QT-Ports bewährter Windows-Programme. > Ausnahmslos alle waren deutlich fühlbar langsamer und ausnahmslos alle > waren um ein vielfaches fetter. Bla bla bla. Was manche Leute immer für Vorbehalte haben ... > Und natürlich braucht man das nicht einmal wirklich zu testen. Es genügt > vollkommen, sich den qt-Code reinzuziehen. Jeder Nicht-Vollidiot wird > ohne jeden weiteren Test aus dem Stand verstehen, dass ein derart fetter > Abstraktionslayer nicht ohne den entsprechenden Impact auf Codesize und > Performance abgehen kann... Ja, das erzählen die Leute über C++ vs. C auch immer. Seit 20 Jahren. Stimmt aber halt nicht. Die Zeit geht bei langsamen Programmen meist für irgendwas dummes drauf, und eigentlich nie dafür dass das Framework drei Funktionsaufrufe braucht und 36 Bytes im Speicher rumscheieben muss um einen Button zu malen statt zwei und 24 Bytes. Das ist einfach Unsinn. Nicht rumjammern, Profiler benutzen und dann irgendwie belastbare Aussagen machen. Tendentiell ist im Prinzip eher das Gegenteil der Fall: mit mehr Abstraktion hat man mehr Zeit und Überblick um da zu optimieren, wo's wirklich was bringt, statt beim Verschieben von 4 Bytes irgendwo. Außerdem heißt das Framework "Qt".
:
Bearbeitet durch User
Eduard schrieb: > p.s. Auf dem Bild ist das aktuelle Fuse/Lock Fenster zu sehen. Hmm, das ist aber immer noch so uneindeutig wie eh und jeh! In der Beschreibung steht 'leeres Kästchen bedeutet...' und abgebildet ist ein Kreis mit Punkt. WTF?!? Außerdem wäre es gut, zur Kontrolle die resultierenden Fusebytes anzugeben. Wenn das nicht besser wird, gehen demnächst alle verfuseten AVRs auf Euro Kappe! Norbert
Eduard schrieb: > Schulde ich jemandem was? Das war so, ist hier so und wird wohl immer so bleiben: Tue Niemand etwas Gutes, so geschieht Dir nichts Böses!
Ja, es stimmt schon. Nur ist das nicht mein erstes Projekt, ich kann schon ein bisschen unterscheiden. Die Guten helfen wirklich, die anderen entweder haben keine Ahnung, aber sie müssen unbedingt ihre Meinung sagen, oder beurteilen anhand der Screenshots in einer Entwicklungsphase. Die letzten zwei werde nie diese Software nutzen. ;-)
Ich finde es toll, das Du dich so reinhängst. Ich kann aber auch die Kritik bezügglich des FUSES verstehen. Wenn man nicht im Kopf hat, was die einzelnen FUSES machen, da kann man sich da ganz schnell einen Bock schießen. In einigen IDEs oder Flashtools, sind die FUSES irgendwie besser beschrieben, sodass die Gefahr seinen Controller unbrauchbar zu machen wesentlich geringer ist. PonyProg ist und wahr mit Sicherheit kein schlechtes Programm, da man aber aus dem AVR-Studio direkt flashen und Fusen kann, habe ich irgendwann nur noch das benutzt.
Hallo Sven! Danke für dein Verständnis! Das Teil sollte Claudio implementieren und prüfen, aber die letzten zwei Wochen ist er sehr beschäftigt. Ich habe die GUI für die Fuses überarbeitet, an dieser Woche habe ich vor, die Bits mit Beschreibungen von dieser Seite http://eleccelerator.com/fusecalc einzubauen. Nur für mich ist es nicht immer klar, da ich mich noch nicht mit AVR's beschäftigt habe. Aber es wird weiter fleßig gearbeitet. :)
Angehängte Dateien:
-
pony-fuse.png
110 KB
Hallo! Das Hilfesystem im Fuse/Lock Fenster wird im Moment getestet, ich glaube, am Wochenende ist es dann fertig, danach folgen Tests mit Hardware. Jetzt sieht das Fenster so aus
Nicht schlecht, Du machst Dir Gedanken und gehst auf Hinweise anderer ein! Was vielleicht auch noch schön wäre, wenn im Fenster unten irgendwo, die gesetzten FUSES oder LOCK-Bits als Hexwert anzeigen würde. In irgend einer IDE war das so, fand ich immer recht praktisch, da konnte man in einem anderem Projekt spicken und schnell den Hexwert eintippen und fertig.
Angehängte Dateien:
-
fuse-neu.png
120 KB
Moin! Hier ist der aktuelle Zustand. Fuse/Lock-Hilfe habe ich nur für im Programm definierte IC's eingebaut. Alle Änderungen von QCheckButtons und QComboBoxes funktionieren in beiden Richtungen. Grüße, Eduard
Moin! Die Quelltexte und Installationsdateien findet man hier: https://sourceforge.net/projects/ponyprog/files/?source=navbar Das Projekt befindet sich auf github: https://github.com/lancos/ponyprog/
Thread beobachten
Seitenaufteilung abschalten
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.