www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bascom, C, C++


Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi an alle,
ich wollte mich mal ein bischen mit AVR´s
beschäftigen. Bei der Hardware sehe ich nicht das Problem.
(Die Elektronik Gundlagen habe ich soweit drauf )
Jedoch habe ich keinen Plan von diveresen Programiersprachen.
Was könnt Ihr mir empfehlen, womit fange ich als
"blutiger Amateur" an.
Gruß Micha

Autor: ThomasB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi micha
man kann das nicht so sagen,welche prog.sprache die bessere ist,
bzw.welche man empfehlen kann.
ich habe mit dem asm.von atmel angefangen,
C ist nicht mein ding,also progr.ich seit einigen jahre mit dem
sehr guten basic-compiler bascom avr.
pascal(e-lab) ist auch sehr guter compiler,aber schweineteuer

am besten du testest mal ein paar compiler ,C,basic oder pascal
wenn dir ein compiler zusagt,bleib dabei.
 demo progr.giebt es ja genug
freie c-compiler auch
demo vom bascom avr codegrösse auf 2 KB beschränkt
demo vom pascal compiler(e-lab) max. 4 KB code.

mfg ThomasB

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du den MC wirklich verstehen willst, dann arbeite dich für den
Anfang in ASM ein. Umsteigen kannst Du dann immer noch aber die
Grundlagen die Du bei der ASM Programmierung lernst versetzen dich erst
in die Lage zu verstehen was der MC wirklich macht und kann.

Meine Meinung ist, wer ASM begriffen hat kommt mit jeder höheren
Programmiersprache klar.

Steffen

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
100% Zustimmung zu Steffens Äußerung!

Gruß, Frank

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von mir ebenfalls 100%-ige Zustimmung zu Assembler !

Thorsten

Autor: A. Arndt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab keinen Nerv, mich in meiner Freizeit mit trockenem ASM
herumzuschlagen, ich nutze FASTAVR (Basic).

Da komme ich ruckzuck zu einer Lösung, z.B. Darstellung LCD in 5 Zeilen
und gut.

Was soll ich Werte in Register schreiben und Verschieben, das soll mir
der Compiler abnehmen, ich kümmere mich den Programmablauf und nicht
was wo für Werte in Register müssen usw.

Wie gesagt, jedem das sein, ich find s so sehr einfach und effektiv,
Basic kann jeder leicht lernen, evtl. C64 oder C-Control gehabt, dann
ist ganz einfach.

Gruss
A. Arndt

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit's wenigstens eine Gegenstimme gibt, von mir keine
Zustimmung. :-)

Lerne Pascal.  Das ist als Lehrsprache konzipiert und erlaubt es, sich
einigermaßen schnell in eine Programmierung hineinzuarbeiten.  Mit
reinrassigem Pascal kann man zwar kaum eine vernünftige Applikation
schreiben, aber zum Lernen ist die Sprache wirklich gut.

Danach kannst Du relativ einfach C lernen, natürlich auch auf einer
Universalmaschine (sprich: PC oder sowas).  Eigentlich mußt Du
,,nur''
Pointer und Arrays noch verstehen sowie das andere IO-Konzept (stdio)
von C.

Dann kannst Du C auf Microcontrollern (MCUs) machen.

Das Verständnis des MCU-Assemblers und der Maschine ist zwar zwingende
Voraussetzung für eine erfolgreiche Programmierung dieser MCUs, aber
es ist deshalb keineswegs notwendig, daß man sich den Masochismus
einer Assemblerprogrammierung als solches antun muß.  Es genügt
vollauf, wenn man den vom Compiler generierten Assemblercode lesen
kann.  Anfangs liest man sich den etwas häufiger durch, dadurch
bekommt man ein Gefühl für den Compiler und den Controller.  Später
liest man sich dann nur noch kritische Stellen durch, da man gelernt
hat, dem Compiler zu vertrauen.

Ganz Verwegene können dann auch noch C++ lernen und das auf MCUs
machen...  Es ist keineswegs so, daß C++ per se größeren Code
zwangsläufig erzeugen muß, und von den besseren
Abstraktionsmöglichkeiten können teilweise auch MCU-Programme
profitieren.  Man sollte aber die Feinheiten dieser Programmiersprache
schon sehr gut kennen, bevor man sich herantraut, diese auf MCUs zu
verwenden.  Ein einzelnes vergessenes & kann da heftigen Schaden (in
Form von Codegröße und Laufzeitverhalten) verursachen.

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joerg:
Wie soll man denn die Ergebnisse eines C-Compilers auf Assembler-Ebene
bewerten können, wenn man nie in Assembler programmiert hat? Zugegeben,
auf dem PC arbeite ich mit einer Hochsprache, aber das ist auch eine
völlig andere Welt, in der Lösungen auf einer hohen Ebene gefordert
sind. Auf Microcontrollern werden eher selten
Multiuser-Datenbankanwendungen implementiert, dort schiebt man meist im
wahrsten Sinne des Wortes "Bits und Bytes", wozu die Assemblersprache
ja entwickelt wurde. Außerdem erscheint mir der Weg über Pascal und C
auf dem PC und dann zu C auf dem MC reichlich weit, nur um sich "mal
ein bischen mit AVR´s zu beschäftigen".

Gruß, Frank

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie soll man denn die Ergebnisse eines C-Compilers auf
> Assembler-Ebene bewerten können, wenn man nie in Assembler
> programmiert hat?

Das geht schon.  Ich schrob ja, daß die Kenntnis der entsprechenden
Assemblersprache und der zugrundeliegenden Maschine (Registersatz
etc.) eine unbedingte Voraussetzung für eine erfolgreiche
MCU-Programmierung ist.

Trotzdem habe ich mir nach einer kurzen PIC-Episode mit Assembler
geschworen, mir das nicht wieder freiwillig anzutun, und habe das auch
weitgehend durchgehalten.  OK, ein paar avr-libc Routinen habe ich
auch in Assembler geschrieben oder debuggt :), aber der Compiler nimmt
einem eben all die Schusselfehler ab, die man gerade bei heutigen
Controllern schnell machen kann.  (Muß ich nun den nächsten JMP-Befehl
nicht überspringen, wenn das C-Flag jetzt nicht gesetzt ist, oder wie
oder was?  Achja, wo ist eigentlich der ADCI-Befehl?  Braucht man
nicht, es ist für einen Compiler kein Thema, statt 33525 zu addieren
-33525 zu subtrahieren, und der freiwerdende Opcode wurde für was
besseres benutzt.)  Außerdem optimieren Compiler mit ihrer stupiden
Methode oft mehr, als man sich aus Übersichtlichkeitsgründen in einem
Assemblerprogramm zutrauen würde.

Von Gleitkomma und Assembler schweigen wir dann lieber gleich...  Da
artet das Schreiben eines Assemblerprogramms in stures Assemblieren
der zugehörigen Unterprogrammaufrufe aus.

> Zugegeben, auf dem PC arbeite ich mit einer Hochsprache, aber das
> ist auch eine völlig andere Welt, in der Lösungen auf einer hohen
> Ebene gefordert sind.

Diese Welt ist gar nicht so anders, wie Du denkst.  Auch dort werden
nicht nur megabyteschwere Datenbanken programmiert, sondern auch
simple Tools wie das Kopieren einer Datei oder die Ausgabe der
aktuellen Uhrzeit.  Würde trotzdem keiner in Assembler machen.  Warum
bitte soll ich mir den Masochismus der Assemblerprogrammierung dann
für die MCU antun?  Nein, danke.  Es genügt, wenn ich verstehe, was da
passiert, aber ich muß es nicht selbst können.  (Schlechter Vergleich
zum Auto: es genügt, wenn ich verstehe, wie der Verbrennungsmotor
funktioniert, ich muß ihn nicht selbst konstruieren können.  OK, viele
verstehen ihn nichtmal mehr.)

> ... dort schiebt man meist im wahrsten Sinne des Wortes "Bits und
> Bytes", wozu die Assemblersprache ja entwickelt wurde.

Auch C wurde mit diesem Hinblick entwickelt, schließlich wollte man
ein Betriebssystem damit schreiben.  Was glaubst Du sonst, wofür es
Operatoren wie & ^ | << >> gibt?  Andere Programmiersprachen hatten
diese nicht bzw. nur in ihrem logischen Äquivalent (also && bzw. ||).
Vor der Einführung von C hat jeder, der ein Betriebssystem
implementieren wollte, genauso argumentiert wie Du heute bei den MCUs:
,,Das kann man ja nur in Assembler tun.''  Heute ist es eine völlige
Selbstverständlichkeit, daß man Betriebssysteme zu weit über 90 %
nicht mehr in Assembler schreibt.

Natürlich ist das auch ein Nachteil von C: man muß sich um alles
selbst kümmern, wie beim Assembler.  Errorcode bei Funktionsrückkehr
ignoriert?  Wenn Du Dich nicht selbst kümmerst, bist Du im Fehlerfall
erschossen...

> Außerdem erscheint mir der Weg über Pascal und C auf dem PC und dann
> zu C auf dem MC reichlich weit, nur um sich "mal ein bischen mit
> AVR's zu beschäftigen".

Entsprechend schlecht sehen viele programmierte Applikationen dann
auch aus.  Wie wir schon erfahren durften keineswegs nur die eines
Hobbyisten, sondern selbst professionelle Baggersteuerungen etc...

Wer programmieren will, soll auch programmieren lernen.  Wer's nicht
will, soll es bleiben lassen.  Es gibt genügend, die es gut gelernt
haben, so daß es nicht schwer sein sollte, sich einen Freund zu
suchen, der einem dabei hilft, sowohl beim Lernen also auch alternativ
dabei, sich einfach gegen ein Glas Bier am Abend mal schnell eine
kleine Applikation programmieren zu lassen.  U. U. kann dabei auch ein
`learning by doing' rauskommen, wenn man sich das hinterher von ihm
erklären läßt, was er da getan hat, und man die Auffassungsgabe hat,
da auch durchzusteigen.

Ach so, ich habe sehr viele verschiedene Assembler programmiert,
teilweise ausgiebig.  Die PDP-11 hatte den schönsten Befehlssatz
bislang, völlig orthogonal, jedes Register konnte gleichermaßen
benutzt werden für jede Adressierung...  Ich weiß schon, worüber ich
spreche.  Ich habe damals den Leiter unseres Rechenzentrums auch nicht
verstanden, als er mir erläutert hat, daß er keinen Assembler mehr
anfassen möchte in seinem Leben.  Die haben damals das
Bibliotheksverwaltungsprogramm der hiesigen TU in Maschinencode
programmiert...  Das hat ihm fürs Leben gereicht.  Inzwischen bin ich
selbst seiner Meinung gefolgt, obwohl ich die vor 20 Jahren noch nicht
verstehen konnte.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi und Danke an alle.
Leider habe bei all den Antworten für mich noch nicht
die richtige gefunden.
Tut mir leid, wenn ich Euch mit meiner Unwissenheit nerve.
Ich müsste eigentlich erst mal wissen, was welche Programiersprache
kann : Wo liegen die Stärken ? Warum gibt es andere ? Was machen die
besser ? ... Ich habe vor in der Holzindustrie einige Anwendungen
zu optimieren z.B. Laserscanner, Trocknungstechnik u.s.w. .
Mir geht es also hauptsächlich um Steuerungen und Überwachung
von Prozessen und/oder Anlagen. Sicher kann man auch gleich
eine Siemens "SPS 7" inkl. Software (oder was auch immer) nehmen. Das
schöne an eigenen Lösungen ist doch aber das Testen neuer Ideen gepaart
mit ein bischen selber gebastelten Systemen.
Ich habe früher auch schon ein bischen rumgelötet. Nun, da ich mir
vorgenommen habe, mir wieder etwas Zeit für Hobbys zu nehmen, möchte
ich gerne "anspruchsvolle" Sachen verwirklichen.
Aber so richtig "sinnvolle" sachen gibt es kaum noch für den
Home-User.
Alle, die mein stuuuuuuuundenlanges Geblubber noch nicht verschreckt
hat, kann ich nur bitten, mir mal direkt zu mailen.
(wenn Ihr lieber alles im Forum lassen wollt, ist es mir auch recht )
Ich beschäftige mich z.Z. unter anderem mit
einer - Mikrowellen-Vakuum-Trockenstrasse für Schnittholz.
Es gibt bereits fertige (wohl kaum ausgereifte )Anlagen für die
Industrie, aber dieses Kapitel ist noch sehr jungfräulich und gibt
allein Stoff genug um einen ganzen Kreis interessierter Bastler
Monate zu beschäftigen. Ein weiteres Kapitel ist z.B. eine
Fehlererkennung von Holzprodukten.
So z.B. folgende Frage: Wie erkenne ich Holzfehler, Äste, faule Stellen
oder Risse usw. in einem Sortierband das mit 2m/sec laufen muß ?
Also, wie schon gesagt, alle die sich gern mit solchen Problemen
rumschlagen möchten, mailt mir.
P.S. Ich betreibe diese Sachen als Hobby. Die gesamte "Forschung"
hat keinen comerziellen Hintergrund.
Mfg. Micha

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man nach oben hin offen sein will, kommt man nicht um C herum.

Größere Anwendungen, die einen ATMega32...256 erfordern habe ich bisher
immer nur in C gesehen.


Aber zum Einstieg empfehle ich auch Assembler. Man muß nämlich erstmal
ein Gefühl dafür entwickeln, was der MC mit links macht bzw. was im die
Schweißperlen auf die Stirn treibt.

Ohne die geringsten Anhaltspunkte über die Laufzeit der verschiedensten
Routinen kann man unmöglich Echtzeitanwendungen programmieren.

Auch ist Assembler ideal, um die Hardwarezugriffe richtig zu kapieren,
angefangen von den Portpins über die Timer, ADC, PWM und sehr wichtig
die Interrupts.


Sehr schön an C ist, daß man alles was nicht direkt auf Hardware
zugreift erstmal am PC, z.B. mit Borland-C austesten kann.
Auch ist Borland-C zu empfehlen, um die ersten Schritte in C zu machen.
Es läßt sich nunmal am PC einfacher debuggen, als auf dem MC.

Und den AVR-Simulatoren ist meistens auch nicht zu trauen. Zumindest
werden hier öfters Fehler gemeldet, die gar keine sind. D.h. der MC
machts schon richtig, nur der Simulator spinnt.


Für Echtzeitanwendungen ist auch besonders wichtig, daß man niemals
Bibliotheksfunktionen als Blackbox verwendet, sondern nur solche, die
auch als Quelltext vorliegen und somit eine Laufzeitabschätzung
erlauben bzw. auch Anpassungen und Debugging fall notwendig.
Z.B. die GCC-Bibliotheken (WINAVR) liegen alle auch als Quelltext vor.

Anders gesagt, Programmiersprachen, die ihre Bibliotheken geheimhalten
sind für zuverlässige und deterministische Echtzeitanwendungen denkbar
ungeeignet.



Peter

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Micha:
Wie Du an der Diskussion siehst, eignen sich im Prinzip alle gängigen
Programmiersprachen, aber an der Frage, welche denn nun die beste
Sprache ist, scheiden sich die Geister. Darauf wirst Du nie eine
eindeutige Antwort bekommen. Ich stimme Joerg aber in mindestens einem
Punkt ganz entschieden zu: Professionelle Ergebnisse ohne
professionelle Herangehensweise sind so wahrscheinlich, wie 'n Sechser
im Lotto.

@Joerg:
Du betonst, daß man Assembler beherrschen muß, wenn man MCUs
programmieren will. Da sind wir uns einig. Und daß eine Hochsprache
viele Vorteile hat, bestreite ich auch nicht. Meine Argumentation ist
halt nur die, daß man als Einsteiger sinnvollerweise die ersten (wohl
meist kleinen und übersichtlichen) Programme auch in Assembler
schreibt, weil das Lernen der Assemblerbefehle und der MC-Eigenheiten
dann effektiver ist, als wenn man nur Datenblätter büffelt. Der
berühmte Unterschied zwischen Theorie und Praxis...
Und weil ich glaube, daß Hochsprachen mit ausgefeilten Bibliotheken
einen Einsteiger dazu verleiten, mal schnell etwas zusammen zu zimmern,
mit den von Dir bereits angesprochenen Auswirkungen.

gruß, Frank

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Frank:

> Meine Argumentation ist halt nur die, daß man als Einsteiger
> sinnvollerweise die ersten (wohl meist kleinen und übersichtlichen)
> Programme auch in Assembler schreibt, weil das Lernen der
> Assemblerbefehle und der MC-Eigenheiten dann effektiver ist, als
> wenn man nur Datenblätter büffelt.

Hierin unterscheiden sich eben unsere Ansichten. ;-)

Ich denke, daß es vollauf genügt, wenn man den vom Compiler
generierten Code anguckt stattdessen, um auf diese Weise mit dem
Assemblercode vertraut zu werden.  Das ist ein himmelweiter
Unterschied zu selbst Assembler programmieren.

Klar, rein vom Datenblatt (bzw. Befehllsatz-Doku) lesen kann man das
so oder so nicht lernen.

Ich halte auch für einen Einsteiger eine ,,höhere'' hüstel
Programmiersprache durchaus geeignet.  Das primitivste avr-libc Demo
ist die per PWM auf- und abschwellende LED und beinhaltet nur paar
Zeilen C.  Der davon generierte Assemblercode ist auch noch
überschaubar...  OK, ich habe auch ein Kapitel über
Assemblerprogrammierung in der avr-libc Doku geschrieben
einschließlich eines Beispiels, für den AT90S1200, da der durch C
sowieso nicht unterstützt wird.  Ist ein simpler Rechteckgenerator
(habe ich mal irgendwann gebraucht), da sieht man aber auch schon, daß
das Assembler-Einsteigerprojekt noch eine Stufe tiefer ist als das in
C...

OK, BASIC würde ich wirklich nur für Dinge empfehlen, bei denen es auf
die Laufzeit nicht ankommt, allerdings kann ich auch nicht
einschätzen, wie gut Bascom wirklich ist.  BASIC hatte allerdings
schon immer die Gefahr in sich, daß man damit alles andere als gut
programmieren lernt. ;-)

@Peter:

Warum soll er sich unbedingt Borland C kaufen?  Den GCC gibt's auch
für den PC, dann hat er sogar gleich dieselbe Umgebung, ziemlich
dieselben Compiler-Optionen usw., und er kostet für den PC genauso
viel oder wenig wie für den AVR.

Du wolltest doch sicher niemanden zum Software-Klau überreden, oder?
:-)

Zustimmung allerdings, daß man die ersten Programmierschritte besser
an einem Universalcomputer macht (das schrieb ich oben schon) und
nicht an einer MCU.  Läßt sich alles viel besser debuggen.  Ach ja,
debuggen will ohnehin auch noch gelernt sein...

Autor: Henning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur vom asm angucken den ein compiler ausgespuckt hat kann man das ganze
sicherlich nicht lernen. andererseits ist es wohl wirklich selten, das
ein anfänger sich auf asm stürzt. das ist wohl doch ein wenig zu
abstrakt. ich persönlich habe mit Turbopascal angefangen, dann delphi
programmiert. zwischendurch auch mal ein wenig asm mit dem 8085) also
bin ich wohl vorbelastet...

ohne viel text meine meinung:
den MC wirklich verstehen lernen: asm anwenden und sich mit den
sprungbefehlen ärgern :) aber umso höher ist die freude, wenn das ganze
dann doch klappt. das wichtige ist die funktionen die der MC bereithält
auch wirklich zu erkennen. ohne dem ist die sache mit der problemlösung
tot umgefallen.
Man muss jedoch schon das "gefühl" zum programmieren bekommen wie man
die sache denn jetz angeht. von daher währe soetwas wie turbopascal
wohl das richtige.

Wo man jetz wirklich richtig aufgehoben ist ist mir selbst
schleierhaft. aber solange ich den asm nicht wirklich kann werde ich
nicht auf hochsprachen umsteigen. Ich will wirklich wissen, was in dem
ding drin steckt. - Wer das nicht will. könnte ja vieleicht doch auf
asm verzichten.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin wie Peter der Meinung, dass man zuerst mal mit Assembler
anfangen sollte um ein "Gefühl" für den Prozessor zu bekommen - was
sind Register, wie ist das mit Programm- und Datenspeicher, usw. Sicher
kann man auch "auf dem trockenen" lernen wie der Controller von innen
aussieht, aber ich bin mir sicher dass sich da Einsteiger deutlich
schwerer tun, als wenn sie es anhand von praktischen Beispielen lernen
können. Und wenn man mal gesehen hat welcher Aufwand für eine
"einfache" Multiplikation nötig ist, dann denkt man vielleicht
zweimal darüber nach ob man jetzt wirklich float verwenden muss oder
doch lieber eine Lösung mit int sucht.

Das (leider immer noch nicht fertige) Tutorial auf dieser Seite kann
man in ein paar Tagen durcharbeiten, ich glaube danach hat man einen
ganz guten Überblick über die Grundlagen und kann problemlos auf C
umsteigen.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich denke, dass es für der Anfang ausreicht, mit C anzufangen, da ich
denke, dass man es am Anfang leichter hat und schneller zu
Erfolgserlebnissen kommt. Ich glaube gerade am Anfang ist es wichtig,
dass man sich nicht gleich mit den ganzen Feinheiten eines Controllers
herumschlagen muss, da dies gerade für Einsteiger schnell langweilig
wird. In C hat man schnell mal was zum laufen gebracht und der Compiler
kümmert sich ums Abfragen der Carry-Flags und was es da sonst noch so
gibt. Zudem hat man am Anfang auch nicht gleich diese hochkomplexen
Echtzeitanwendungen, wo man sich wirklich über jeden Befehl Gedanken
machen muß.
Das man sich den Controller sehr genau ansehen muß, ist natürlich
selbstverständlich, aber ob ich nun in C schreibe Register = Wert oder
in Assembler das gleiche mit mov erledige ist doch egal. Letztendlich
bringt es das gleiche, nur das es am Anfang im C übersichtlicher
erscheint.
Das Verstehen von Assembler kommt nachher von alleine, da man sich ja
sowieso oft die Listings des Compilers ansehen muß (später zumindest).
Andere Sprachen (ausser C und Assembler) spechen mich persönlich nicht
so an, da sie meines Erachtens nach vorrangig mehr im Hobbybereich
eingesetzt werden, wie z.B. Basic. Wenn es dann doch schon etwas
professioneller werden soll, würde ich auch auf die Standards
zurückgreifen.

Viele Grüße,

Ralf

Autor: Andreas Jäger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joerg

> Warum soll er sich unbedingt Borland C kaufen?  Den GCC gibt's auch
> für den PC, dann hat er sogar gleich dieselbe Umgebung, ziemlich
> dieselben Compiler-Optionen usw., und er kostet für den PC genauso
> viel oder wenig wie für den AVR.

> Du wolltest doch sicher niemanden zum Software-Klau überreden, oder?


Der Borland C/C++-Compiler ist 'Free'!

MfG
Andreas Jäger

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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