mikrocontroller.net

Forum: PC-Programmierung PonyProg portiert auf Qt


Autor: Eduard (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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 Moderator
Autor: Virtuelles Leben (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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?

Autor: Eduard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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...

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Idee finde ich sehr schön:

https://www.raspberrypi.org/forums/viewtopic.php?f...

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.

Autor: Noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: c-hater (Gast)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
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!

Autor: Eduard (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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. 
;)

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann ist sicher die Kombi das Optimale.

Ein schickes Programm als Paket auf einem Stand Alone RasPi.

Autor: Fritz Ganter (fritzg)
Datum:
Angehängte Dateien:

Bewertung
6 lesenswert
nicht lesenswert
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... 
. Es soll dann auch kleiner sein, als wenn man sich das ganze QT-Zeugs 
installiert.

Autor: Eduard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
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...

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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
Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Hast du denn auch schon mal ein Qt-Programm
> geschrieben?

Natürlich hat er. In Assembler!

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ein echter Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/0...

Weichei!

Autor: Eduard (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Eduard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wäre daran interessiert ein Bundle für MAC OSX zu testen.
Namaste

: Bearbeitet durch User
Autor: Eduard (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Eduard (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Norbert (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Eduard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>WTF?!?
Schulde ich jemandem was?

Autor: Oberlajtnant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Eduard (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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. ;-)

Autor: Sven L. (sven_rvbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Eduard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: Eduard (Gast)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Sven L. (sven_rvbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Eduard (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Eduard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!
Die Quelltexte und Installationsdateien findet man hier:
https://sourceforge.net/projects/ponyprog/files/?s...

Das Projekt befindet sich auf github:
https://github.com/lancos/ponyprog/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.