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
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.
;)
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.
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.
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.
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.
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).
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".
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. :)
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.
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
