Forum: Mikrocontroller und Digitale Elektronik Attiny25 gleiches Programm geht auf anderem Kontroller nicht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe hier ein recht seltsames Problem mit einem Attiny25. Vor 
einiger Zeit habe ich ein Programm in Assembler erstellt (Damals Atmel 
Studio 6.0) und bin inzwischen auf Studio 7 umgestiegen. Das Programm 
funktioniert noch immer auf 2 verschiedenen Attiny25.
Jetzt versuche ich einen weiteren tiny zu programmieren, gleiches 
Modell, gleiches Programm, jedoch scheint der Kontroller nicht zu 
laufen??

Programmieren tu ich mit dem AVRISP MkII, Fehler bekomm ich keine 
angezeigt. Versucht hab ich das auch schon in AVR Studio 4 und AS6.0.

Die Fuses sind korrekt gesetzt (Nur 8MHz RC Oszi und CKDIV8), keine Lock 
bits.

Die Platine auf die der uC eingesetzt wird ist auch in Ordnung, da ich 
mit einem funktionierenden tiny25 probiert hab.
Wenn ich den funktionierenden uC auslese und diese .hex-Datei auf einen 
neuen schreibe, geht es ebenfalls nicht.

uC wurde ebenfalls gewechselt, habe mit 3-4 anderen tinys versucht aber 
die gehen alle nicht. Nur ein einziges Mal hat es komischerweise 
geklappt, das Programm lief aber nach aus- und wieder anschalten ging es 
schon wieder nicht mehr.

So und jetzt kommt das Lustige, mein Bruder hat das gleiche Problem. Wir 
nehmen beide den gleichen Programmer, doch er hat ein anderes Programm 
(hat ebenfalls vorher gefunzt) und ne andere Platine.

Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich 
wesentlich von der unterscheidet, die ich draufgeschrieben habe. Sollten 
diese i.d.R. nicht identisch oder fast identisch sein?
Mir scheint als gäbe es ein Problem mit dem ISP oder der Kontroller 
verträgt was nicht. Was könnte das sein?


MfG,

Max

von batman (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der guade avrdude hat für sowas eine verify-Funktion.

von Jim M. (turboj)


Bewertung
-2 lesenswert
nicht lesenswert
Max schrieb:
> Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich
> wesentlich von der unterscheidet, die ich draufgeschrieben habe. Sollten
> diese i.d.R. nicht identisch oder fast identisch sein?

Definiere "wesentlich".
Ein ausgelesenes Hex File wird praktisch immer Unterschiede aufweisen - 
beispielsweise am Ende wo das Original einfach aufhört.

Intel Hex als textbasiertes Format könnte auch anders formatiert sein, 
IIRC ist z.B. die Zeilenlänge nicht fest vorgegeben.

von Abel H. (abel)


Bewertung
2 lesenswert
nicht lesenswert
Jim M. schrieb:
> Ein ausgelesenes Hex File wird praktisch immer Unterschiede aufweisen -
> beispielsweise am Ende wo das Original einfach aufhört.

Nein. Wenn es Unterschiede zwischen dem gerade gebrannten und wieder 
ausgelesenem Inhalt gibt, ist das natürlich ein Fehler. Dafür gibt es ja 
die "Verify"-Funktion.

Abel.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max schrieb:
> Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich
> wesentlich von der unterscheidet, die ich draufgeschrieben habe.

Die Daten und die Adressen müssen gleich sein. Hast du die Dateien von 
der Bedeutung oder von den ASCII-Zeichen her verglichen?

von Edi R. (edi_r)


Bewertung
-1 lesenswert
nicht lesenswert
Nur sicherheitshalber: Liegt zwischen VCC und GND möglichst nahe am IC 
ein keramischer Kondensator 100 nF? Und ich hoffe, am Reset-Pin liegt 
kein Kondensator von wesentlicher Größe.

von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Max schrieb:
>> Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich
>> wesentlich von der unterscheidet, die ich draufgeschrieben habe. Sollten
>> diese i.d.R. nicht identisch oder fast identisch sein?
>
> Definiere "wesentlich".
> Ein ausgelesenes Hex File wird praktisch immer Unterschiede aufweisen -
> beispielsweise am Ende wo das Original einfach aufhört.
>
> Intel Hex als textbasiertes Format könnte auch anders formatiert sein,
> IIRC ist z.B. die Zeilenlänge nicht fest vorgegeben.

Ich meine damit, dass von Anfang bis Ende Unterschiede auftreten. Es 
lassen sich nur manchmal mehrere aufeinanderfolgende Bytes finden die 
gleich sind. Auch die Adressen am linken Rand sind nicht 1:1 gleich. 
Sobald es geht werde ich den uC nochmal auslesen und die Resultate hier 
posten damit ihr seht was ich meine.


Wolfgang schrieb:
> Max schrieb:
>> Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich
>> wesentlich von der unterscheidet, die ich draufgeschrieben habe.
>
> Die Daten und die Adressen müssen gleich sein. Hast du die Dateien von
> der Bedeutung oder von den ASCII-Zeichen her verglichen?

Ich habe die Dateien mit Notepad geöffnet und so Zeile für Zeile 
verglichen.
Das Komische ist, dass im AS die verify-Funktion nach dem flashen keine 
Fehler anzeigt. Es muss etwas geschehen nachdem ich das Board vom Strom 
trenne, die Frage ist nur was. Ab dem Punkt bin ich am Ende mit meinem 
Latein.

von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Edi R. schrieb:
> Nur sicherheitshalber: Liegt zwischen VCC und GND möglichst nahe
> am IC
> ein keramischer Kondensator 100 nF? Und ich hoffe, am Reset-Pin liegt
> kein Kondensator von wesentlicher Größe.

100nF-Kondensator ist drauf und Reset-Pin ist nicht angeschlossen.
An der Platine liegts ja eh nicht weil andere uC drauf laufen ohne 
Probleme.

von Edi R. (edi_r)


Bewertung
0 lesenswert
nicht lesenswert
Max schrieb:
> An der Platine liegts ja eh nicht weil andere uC drauf laufen ohne
> Probleme.

Ohne richtiger Beschaltung kann es mal funktionieren, und mal nicht. 
Deshalb meine Frage.

von Endzeit (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Max schrieb:
> An der Platine liegts ja eh nicht weil andere uC drauf laufen ohne
> Probleme.

Dann gibt es nur noch eine Möglichkeit. Das sind Fakes aus China und es 
gibt keine Möglichkeit das Problem zu beheben, weil heute alles aus 
China kommt :-(

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Das Komische ist, dass im AS die verify-Funktion nach dem flashen
> keine Fehler anzeigt.

Dann ist da auch kein Fehler. Du kannst nicht einfach zwei hex Dateien 
miteinander vergleichen, die auf unterschiedliche Weise erstellt wurden. 
Beschäftige Dich mal mit dem Dateiformat, dann wirst du sehen, warum das 
so ist.

Zeige und den Schaltplan, detaillierte Fotos von Aufbau und das 
Programm. Es ist recht warscheinlich, dass Hardware oder Software einen 
Fehler enthalten.

> Das sind Fakes aus China
Ich hatte mit Fake Produkten aus China noch nie solche Grundsätzlichen 
Probleme. Funktioniert haben sie immer. Wenn aber irgend etwas außerhalb 
der Spezifikation betrieben wird, dann kann es durchaus sein, dass ein 
Fake oder gar ein Original aus einer anderen Serie empfindlich reagiert.

: Bearbeitet durch User
von Frank D. (Firma: Spezialeinheit) (feuerstein7)


Bewertung
-1 lesenswert
nicht lesenswert
Mal ne blöde Idee, hast du das richtige herfiel gewählt? Das AVR Studio 
öffnet den zuletzt geöffneten Ordner, nicht den, der aktuell in 
Bearbeitung ist.
Zumindest ist das bei der alten Version der Fall (4.19 oder so).

von npn (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Fred F. schrieb:
> das richtige herfiel

Was meinen?

von Erbsenzähler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
npn schrieb:
> Was meinen?

Nur zwei Fehler innerhalb eines Wortes mit sieben Buchstaben - stell 
dich nicht so an ;-)

von Frank D. (Firma: Spezialeinheit) (feuerstein7)


Bewertung
-1 lesenswert
nicht lesenswert
Am Tablet getippt, die Tastatur und ich wir haben 
Kompatibilitätsprobleme. Soll natürlich Hexfile sein.

von fxjkcyxmk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max schrieb:
> und Reset-Pin ist nicht angeschlossen.

Dann sollte das Programmieren gar nicht funktionieren, das kann SO also 
nicht sein - wie so oft: Schaltplan zeigen!


fxjkcyxmk

von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
fxjkcyxmk schrieb:
> Max schrieb:
>> und Reset-Pin ist nicht angeschlossen.
>
> Dann sollte das Programmieren gar nicht funktionieren, das kann SO also
> nicht sein - wie so oft: Schaltplan zeigen!
>
> fxjkcyxmk

Ich war wohl nicht klar genug, auf dem Programmierboard ist der 
natürlich dran, nur auf dem Anwendungsboard nicht. Nen Schaltplan von 
dem Programmierboard hab ich nicht aber das hatte nie Probleme, wir 
haben damit Dutzende Controller geflasht.

Fred F. schrieb:
> Mal ne blöde Idee, hast du das richtige herfiel gewählt? Das AVR
> Studio
> öffnet den zuletzt geöffneten Ordner, nicht den, der aktuell in
> Bearbeitung ist.
> Zumindest ist das bei der alten Version der Fall (4.19 oder so).

Das überprüfe ich jedesmal und ist das richtige file (in meinem Fall im 
Projektverzeichnis -> Debug)

Stefan U. schrieb:
> Dann ist da auch kein Fehler. Du kannst nicht einfach zwei hex Dateien
> miteinander vergleichen, die auf unterschiedliche Weise erstellt wurden.
> Beschäftige Dich mal mit dem Dateiformat, dann wirst du sehen, warum das
> so ist.

Hier sind Beispielzeilen (Anfang der Datei) von einem einfachen 
Programm:

vom Studio erstelltes hex-file:

:020000020000FC
:020000000EC030
:02000800D3C063
:10001E000FED0DBF00E00ABD03BF0FE000BF00E013
:10002E000CBD04E009BFBA9AB998B89A789450E01A
:10003E0060E0B19BFDCFF894639523E100000000D2
:10004E002A95E1F70000B199F7CF789453955B307C

ausgelesenes hex-file:

:100000000EC0FFFFFFFFFFFFD3C0FFFFFFFFFFFF9B
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFF0FEDF2
:100020000DBF00E00ABD03BF0FE000BF00E00CBD44
:1000300004E009BFBA9AB998B89A789450E060E0A1
:10004000B19BFDCFF894639523E1000000002A9551
:10005000E1F70000B199F7CF789453955B3079F7C9

Der Anfang mit der :02-Datenlänge ist ja sicher normal, aber dass der 
Rest so unterschiedlich ist versteh ich nicht. Es gibt da ja nur 1 
Format und zwar das von Intel. Diese Unterschiede sind vielleicht auch 
normal, hab nie so drauf geachtet und kenn mich da nicht wirklich aus 
aber deswegen frag ich ja ob das ein Problem sein könnte.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mach das mal mit einem Format wo manvernünftig vergleichen kann, also 
z.B. .bin und dann hexdump vergleichen.

Denkbar wäre dass durch fehlenden Brwon-Out der Controller mist macht 
und irgendwelche Code-Sequenzen durchnudelt die den Flash shreddern.

von Heinz V. (heinz_v)


Bewertung
0 lesenswert
nicht lesenswert
nicht jeder Texteditor ist geeignet hex-Files zu öffnen.
Beispielsweise wird das CR-LF wie es zu DOS Zeiten üblich war in ein LF 
umgewandelt oder TAB wird in eine Folge Blancs gewandelt, 
ärgerlicherweise speichern manche Editoren die Änderungen ungefragt.

Besser Hex Editor verwenden.

von Georg G. (df2au)


Bewertung
0 lesenswert
nicht lesenswert
Max schrieb:
> dass der
> Rest so unterschiedlich ist versteh ich nicht

Dann lies bitte die Definition für Intel-Hex Code.

Der Studio Code enthält die Bytes in der Reihenfolge und an den 
Adressen, wie der Compiler sie ausgespuckt hat. Das muss nicht linear 
sein und nicht bei 0 anfangen. Die Ladeadressen müssen nicht stetig 
ansteigen. Löcher sind auch zulässig.
Der ausgelesene Code fängt immer bei 0 an und ist "in einem Stück".

Ein Vergleich im Editor ist aufwändig und fehlerträchtig. Aber, wie 
schon von Johann geschrieben, gibt es dafür Werkzeuge.

von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Antworten.
Ich habe jetzt wie Johann beschrieben hat die hex files in .bin 
umgewandelt und dann mit einem online hexdump tool verglichen. Sie sind 
in der Tat 100% identisch und damit meine ich die Datei, die vom Studio 
generiert wird, die ausgelesene .hex vom uC der funktioniert und von 
einem der nicht funktioniert. Alle sind gleich.

Hardware ist auch i.O. da mein alter tiny (der übrigens von der selben 
Serie stammt) ja läuft. Ist ja schon fast wie Hexerei..

von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zur Info, ich habe einen MD5 Hash Generator benutzt und die Resultate so 
verglichen.

von Ich_eben (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Beschaltet den reset doch wie im Datenblatt angegeben

von Hubert G. (hubertg)


Bewertung
0 lesenswert
nicht lesenswert
Die Fuses schon mal ausgelesen und verglichen?

von Der Nuller (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und dann sollte man noch die Registeradressen im Datenblatt vergleichen. 
Nicht alle Register lassen sich per LDI, SBI, JBS und dergleichen 
ansprechen. Auf einem anderen Controllermuss dasselbe Regsiter per LDS, 
STS, STD und dergleichen ansprechen. Der ASM zeigt keinen Fehler, es 
geht einfach nicht.
Die Immediate Register muessen unterhalb 32 oder so sein. Oberhalb kann 
LDI und dergleichen nicht zugreifen.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was macht der Code denn?

Der interne RC-Oszillator ist relativ ungenau, ein kritisches Timing 
kann da beim einen Chip noch passen, beim anderen nicht.

von Hugo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der Nuller schrieb:
> Und dann sollte man noch die Registeradressen im Datenblatt vergleichen.
> Nicht alle Register lassen sich per LDI, SBI, JBS und dergleichen
> ansprechen. Auf einem anderen Controllermuss dasselbe Regsiter per LDS,
> STS, STD und dergleichen ansprechen. Der ASM zeigt keinen Fehler, es
> geht einfach nicht.

Sind die Registeradressen tatsächlich bei zwei gleichen
ATtiny25 verschieden?
Muss man wirklich die Files des einen ATtiny25 mit dem
anderen ATtiny25 vergleichen?

Der TO schrieb:
Max schrieb:
> Das Programm
> funktioniert noch immer auf 2 verschiedenen Attiny25.
> Jetzt versuche ich einen weiteren tiny zu programmieren, gleiches
> Modell, gleiches Programm, jedoch scheint der Kontroller nicht zu
> laufen??

von S. Landolt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mal ganz abgesehen davon, dass beim ATtiny25 die Registeradressen bei 
0x3F enden.

von Peter (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ich würde ein Minimalprogramm schreiben, dass zum Beispiel eine LED 
toggelt. Dieses in den funktionierenden und den nicht funktionierenden 
Controller brennen.
Falls eines nicht geht => Controller defekt / Fake.
Falls beide gehen => Programm benötigt kleinere Toleranzen als der 
Controller hergibt (zum Beispiel des RC-Oszillators).

von Sebastian S. (amateur)


Bewertung
0 lesenswert
nicht lesenswert
Wie Jim schon schrieb, gibt es oft Unterschiede im Hex-File, zwischen 
rein und raus. Und das nur durch die unterschiedliche Formatierung.

Ein zweiter Pferdefuß ist der, dass das Leseprogramm keine Ahnung hat, 
wie lang das Programm ist. Also wird meist der ganze Speicher 
ausgelesen. Also stimmt schon mal die Länge nicht.

Wurde vor dem Schreiben nicht - unnötigerweise - der gesamte Speicher 
gelöscht, so findest Du "hinter" Deinem Programm noch Reste, der 
vorherigen Versuche. So diese zwischenzeitlich mehr Platz benötigten.

: Bearbeitet durch User
von Da D. (dieter)


Bewertung
-1 lesenswert
nicht lesenswert
Fred F. schrieb:
> Am Tablet getippt, die Tastatur und ich wir haben
> Kompatibilitätsprobleme.

Ach, und auf deinem Tablet kannst du nicht lesen was du schreibst? Das 
wäre mir neu, dass Tablets so funktionieren.

von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hubert G. schrieb:
> Die Fuses schon mal ausgelesen und verglichen?

Ja.

Hmmm schrieb:
> Was macht der Code denn?
>
> Der interne RC-Oszillator ist relativ ungenau, ein kritisches Timing
> kann da beim einen Chip noch passen, beim anderen nicht.

Der Code soll ein Soundmodul ansteuern und gibt einen Takt sowie die 
abzuspielende Adresse an das Modul nachdem man die gewünschte Audiodatei 
mit ein paar Schalter ausgewählt hat.
An den RC Oszillator hatte ich auch schon gedacht weil der Code zufällig 
schon mal funktioniert hat. Ein paar ms beim Takt können genügen um das 
Programm aus der Bahn zu werfen, allerdings bei +-10% Abweichung und 
1MHz wäre das gerade mal 0,1us/Befehlszyklus und bei ausschließlich 
8-bit timer macht das auch noch nicht viel aus.

Ich werde trotzdem mal versuchen den Oszi zu kalibrieren um zu sehen ob 
es nen Unterschied macht für den Fall dass ich mich irre.


Sebastian S. schrieb:
> Wie Jim schon schrieb, gibt es oft Unterschiede im Hex-File,
> zwischen
> rein und raus. Und das nur durch die unterschiedliche Formatierung.
>
> Ein zweiter Pferdefuß ist der, dass das Leseprogramm keine Ahnung hat,
> wie lang das Programm ist. Also wird meist der ganze Speicher
> ausgelesen. Also stimmt schon mal die Länge nicht.
>
> Wurde vor dem Schreiben nicht - unnötigerweise - der gesamte Speicher
> gelöscht, so findest Du "hinter" Deinem Programm noch Reste, der
> vorherigen Versuche. So diese zwischenzeitlich mehr Platz benötigten.

Die Unterschiede kann ich ausschließen da ich mit der Methode wie vorhin 
beschrieben die files verglichen habe und nix gefunden habe was Probleme 
macht.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Hardware ist auch i.O. da mein alter tiny (der übrigens von der selben
> Serie stammt) ja läuft.

Als erste grobe Annahme ist das Ok, aber da du Probleme hast, sollte man 
etwas weiter denken.

Wenn der Controller irgendwo im Grenzbereich (außerhalb der Specs) 
betrieben wird, können winzige Unterschiede im Chip durchaus 
ausschlaggebend für geht/geht nicht ausschlaggebend sein.

Zum Beispiel könnte es druchaus sein, dass der alte Chip 2,5V als High 
Pegel interpretiert, während der neue dies als Low auswertet.

von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
>> Hardware ist auch i.O. da mein alter tiny (der übrigens von der
> selben
>> Serie stammt) ja läuft.
>
> Als erste grobe Annahme ist das Ok, aber da du Probleme hast, sollte man
> etwas weiter denken.
>
> Wenn der Controller irgendwo im Grenzbereich (außerhalb der Specs)
> betrieben wird, können winzige Unterschiede im Chip durchaus
> ausschlaggebend für geht/geht nicht ausschlaggebend sein.
>
> Zum Beispiel könnte es druchaus sein, dass der alte Chip 2,5V als High
> Pegel interpretiert, während der neue dies als Low auswertet.

Das ist es ja, die Specs wurden alle berücksichtigt. Betrieben wird er 
mit 3,3V bei Zimmertemperatur und ist vorschriftsgemäß mit 100nF direkt 
an VCC und GND entstört.
Geflasht wird er bei 5,5V (ist eig. ne Batterie mit 4,8V aber 
vollgeladen hat die 5,5). Das stellt doch kein Problem dar oder? Um 
sicherzugehen hatte ich schon mal ne Si-Diode zwischen Batterie und uC 
gehangen, hat aber nichts gebracht.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Vier NiMh Zellen haben frisch geladen sogar fast 6V. Ich habe AVR's in 
Experimenten schon oft mit 5,8V betrieben, so daß ich davon ausgehe, daß 
deine 5,5V nicht die Problemursache sind.

von S. Landolt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> ... gibt einen Takt sowie die abzuspielende Adresse ...
Klingt doch recht überschaubar, könnte man das vielleicht mal sehen?

von Karl M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

irgendwie fehlt das doch etwas.
Ich sehe keinen Schaltplan und keine detail Bilder vom Aufbau.

Hier wird das Problem zu finden sein.

Der gesamte Prosatext beschreibt nicht die Realität !

von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zur Info, der Code läuft wieder. Wie es scheint hat mein AVR ISP sich 
was eingefangen denn nachdem ich mir einen neuen ISP bestellt und mit 
dem geflasht hab geht wieder alles, auch der Code von meinem Bruder.

Blieb ja nichts anderes mehr übrig aber was für ein Mist ist das dass 
der ISP nach fast 10 Jahren auf einmal sowas macht?

von Dietrich L. (dietrichl)


Bewertung
0 lesenswert
nicht lesenswert
Max schrieb:
> Blieb ja nichts anderes mehr übrig aber was für ein Mist ist das dass
> der ISP nach fast 10 Jahren auf einmal sowas macht?

So ist das im realen Leben: nichts lebt/hält ewig...

Da fällt mir der "tiefsinnige" Spruch ein:
Was soll denn da kaputt sein? Gestern gings doch noch!  ;-)

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]
  • [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.