mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SD-Card über SPI - manche gehen, manche nicht.


Autor: Markus Schabel (Firma: TU Wien) (comsubvie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grüße!

Ich hab hier ein Projekt, bei dem ich Daten auf eine SD-Karte loggen 
soll/darf/muss.

Bisher habe ich dafür 2 verschiedene Karten benutzt: eine 256MB Karte 
von Lexar sowie eine 1GB Karte von Kingston. Beide funktionieren über 
die 0815-SPI-Initialisierung (CMD0, ACMD41, Read OCR, CID, CSD) 
wunderbar, auch Daten lesen und schreiben funktioniert absolut 
problemlos (FAT32).

Das Problem bei diesen beiden Karten ist jedoch, dass das Schreiben ewig 
braucht - obwohl die Karten theoretische ein paar MB pro Sekunde 
schreiben können sollten, schaffe ich über SPI gerade mal etwa ein 
Kilobyte pro Sekunde. Die SPI-Clock hat auf die Geschwindigkeit keine 
ersichtliche Auswirkung, das dauert bei 1MHz genauso lange wie bei 
20MHz. Irgendeine Idee woran das liegen könnte?

Nun habe ich mir eine SanDisk Ultra II mit 1GB zugelegt, allerdings kann 
ich diese Karte scheinbar nicht richtig initialisieren, die Karte kommt 
nach ACMD41 nie aus dem Idle-State. Wenn ich vor dem Versuch die Karte 
zu initialisieren ein CMD8 sende, bekomme ich 0x7F.FF.FF.FF.FF als 
Antwort zurück (die anderen Karten antworten mit 0x01.00.00.01.AA), und 
auf CMD58 bekomme ich 0x01.00.FF.80.00 zurück (wenn ich CMD8 nicht 
sende, bekomme ich da ebenfalls 0x7F.FF.FF.FF.FF zurück).

Ich verstehe nicht warum die SanDisk nicht mit mir (also mit meinem 
Controller) sprechen will. Bin für alle Hinweise dankbar!

Details am Rande: Betrieben wird die SD-Karte mit CPOL=1 und CPHA=1, die 
Initialisierung läuft mit 400kHz. SCLK und MISO haben einen Pull-Up auf 
3.3V, der Controller ist ein BlackFin BF537 und programmiert wird das 
ganze mit (bitte nicht schlagen, ich hab's mir nicht aussuchen könnten) 
LabView Embedded (welches Visual DSP++ im Hintergrund verwendet).

Bin für alle Hinweise (sehr) dankbar!

Autor: Markus Schabel (Firma: TU Wien) (comsubvie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

1.) Zum Thema Geschwindigkeit: es gibt auch keinen erkennbaren 
Unterschied zwischen Single-Block-Write und Multiple-Block-Write. 
Irgendwie muss man die Karten im SPI-Modus doch zu einer vernünftigen 
Schreibgeschwindigkeit bringen können, im SDIO-Modus funktionieren die 
ja auch sehr flott...

2.) Zum Thema SanDisk: Auf ACMD41 bekomme ich immer 0x3F zurück (d.h. da 
sind quasi alle Error-Flags gesetzt bis auf eine). Auf CMD58 (Read OCR) 
bekomme ich interessanterweise von der SanDisk eine vernünftige Antwort 
(sofern CMD8 zuvor gesendet wurde), da liefert er mir brav "Idle"=1, 
"Card power up status bit"=0 [this bit is set to LOW if the card has not 
finished the power up routine] sowie einen vernünftigen Spannungsbereich 
(3.6-2.7V).

Es ist zwar klar das er sagt "the card has not finished the power up 
routine", aber warum lässt sich diese nicht durchführen (warum bekomme 
ich auf ACMD41 keine sinnvollen Antworten)?

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus,
ich habe ein ähnliches Problem: manche meiner Karten gehen und manche 
nicht. Ich habe eine MMC mit 32 MB, auf der geht alles einwandfrei. 
Dafür kann ich eine SD SanDisk 1GB wohl lesen, beim Schreiben schreibt 
sie aber fast alles mit 0xFF drauf, wird also richtig initialisert. Ein 
TransCend kann ich nichtmal lesen, die lese ich immer einen Code, der so 
nicht stimmt, das kann ich über WinHex sehen. Als Taktfrequenz habe ich 
zur Zeit noch 250kHz für SPI, was sich aber auf 20MHz steigern läßt, wie 
ich jetzt weiß. Für die Hardware habe ich die Schaltung von Ulrich Radig 
genommen.
Alle Karten können über einen Card-Reader einwandfrei gelesen und 
beschrieben werden, sind also wohl nicht kaputt, oder?
Weiß hier jemand einen Rat, warum es bei manchen Karten geht und (bei 
mir) mit manchen Karten gar nicht?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde sagen irgendwelche Pegel oder Timings stimmen nicht. Bei mir 
liefen bisher immer alle Karten.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mich mit dem gleichen Thema sehr lange befasst und auch viele 
Karten getestet, so dass eine Software für PIC entstand mit der alle, 
bis auf eine alte 16MB Karte zusammenarbeiten. Ärgerte mich auch erst, 
dass eine geht und die anderé nicht.

Als erstes: Die Hardware von Ulrich Radig funktioniert nicht richtig, 
die Flanken verschleifen. Man muss nur mit dem Finger an einen Pin 
kommen oder nur den tastkopf des Oszi dranhalten und schon stürzt die 
Karte ab. Nimm echte 3.3V Treiber (74LVP....)  oder eine 3.3V CPU und 
dann geht das auch. In Ulrichs Programmen habe ich auch kleine Fehler 
entdeckt, bzw. sind nicht alle Fehler abgefangen. Lies die Spec wirklich 
buchstabengetreu durch und mache es genauso wie es da steht, jeder 
Fehler muss abgefangen werden.

Falls der AVR Schmitt Trigger Eingänge an der SPI hat: Treiber 
vorschalten! Schmitt triger sind nicht kompatibel mit 3.3V Logik.

Beachte, dass bei alten Karten der Schreibzyklus bis 50ms lang ist !! 
Löschzyklen sind ebenfalls locker bis 10s (!!!) lang. Da laufen ein paar 
Timeout über.

Manche Karten kehren kurze Zeit nach jedem Zugriff in den Idle Mode 
zurück und müssen explizit wieder aufgeweckt werden durch den CMD0 
Befehl.

Die Karten müssen mit kleiner Taktrate aufgeweckt werden (< 1MHz), erst 
danach kann man hochdrehen.

Manche Karten wachen erst auf, wenn ich ihnen ein paar Mal den Strom 
einschalte mit einem P-Kanal FET, der den 3.3V steuert. Keine Ahnung 
warum.

Meine Software macht nur Einzelblockzugriffe, weil etwas anderes mit 
einer FAT auch wenig Sinn macht und vor jedem Lesen und Schreiben sendet 
Sie eine Wake Up Sequenz. Das verlangsamt die Sache aber machtr sie 
sicherer.

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle,
ich stelle hier meinen Code als Dateianhang mal zur Verfügung - auch 
ohne Fehler abzufangen - bislang. Damit kann ich Blocks lesen und 
schreiben, wie gesagt aber nur auf meiner MMC-Karte 32 MB groß.
Den Tips von Christian werde ich jetzt mal nachgehen.
Vielen Dank erst mal.

Autor: Christian J. (elektroniker1968)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

anbei mal mein Code, aber auch nur für 128/256 MB Karten, da ich die 
Kartenparameter nicht auswerte bzw. bislang zu faul war die auszulesen.
Ich müsste mal das ganze "universalisieren" :-) Aber da fehlt einfach 
die Zeit zudem der ARM7 ja jetzt dran ist.

Ist für PIC mit CCS in einem Multi-Slave System für SPI aber sollte die 
wesentlichen Sachen verdeutlichen. PS: Ich arbeite mit 32MB Banken, weil 
16 Bit für den CCS noch gut zu handeln sind und mein Projekt mehrere 
Banken braucht.

Mit einer FAT haperts leider, gibt da nichts für PICs und eine von AVR 
umschreiben... nee, die Codes sind immer so schrecklich unkommentiert.

Autor: Markus Schabel (Firma: TU Wien) (comsubvie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grüße!

Das Geschwindigkeitsproblem konnte ich inzwischen lokalisieren - das 
scheint ein Problem des "System Services and Device Drivers Framework" 
des BlackFin bzw. des VisualDSP++ Kernels zu sein, da gibt's 2 
Funktionen die ich bei jedem Transfer mindestens einmal aufrufen muss 
(SPI Aktivieren, Warten bis der Lese-Buffer voll ist), wobei das 
Aktivieren schon mal 9ms braucht, und das muss ich aber vor jedem 
Transfer machen (da muss ich mich mal mit Analog kurzschließen ob die 
eine bessere Lösung haben).

Warum ich die SanDisk nicht ansprechen kann ist mir jedoch weiterhin 
schleierhaft.

@Christian: so schwierig kann die Portierung eines FAT-Treibers von AVR 
auf den PIC nicht sein, das einzige was sich da unterscheidet sind die 
SPI-Zugriffe, alles andere sollte man 1:1 übernehmen können.

Ich hab's da ein bisschen schwieriger gehabt - oder kennt jemand wen der 
einen FAT-Treiber in LabVIEW [Embedded] ge"zeichnet" hat? Werde den Code 
aber an geeigneter Stelle veröffentlichen wenn er stabil genug ist (und 
ich das Performance-Problem in Griff bekommen habe), auch wenn ich 
vermute das das Interesse an einer derart speziellen Lösung gegen 0 
gehen dürfte.

Bin für SanDisk-Hinweise weiterhin dankbar!

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

Bewertung
0 lesenswert
nicht lesenswert
@Christian,
habe die Schaltung jetzt mit Treibern aufgebaut und die Leitungen 
erheblich verkürzt. Im Prinzip ist aber alles wie vorher, obwohl ich 
diese Schaltung mit Treibern natürlich für sicherer halte.
Die SanDisk kann nach wie vor lesen. Meine TransCend 1GB liest immer nur 
Nullen aus. Sie tut also so, als ob alles in Ordnung wäre, keine 
Fehlermeldungen oder so. Init erfolgreich, oder? Ist sie wieder im 
idle-mode? Wenn ja, hätte doch wohl eine Fehlermeldung in Form eines 
timout kommen müssen...
Meine Schaltung SD-an-PIC in JPG füge ich mal bei, wen es interessiert. 
Hier sind aber nur die relevaten Leitungen angeschlossen. Als 5V nach 
3,3V Pegelwandler habe ich einen 74LVX125 in SMD benutzt. Als 3,3V nach 
5V Pegelwandler habe ich ein nicht benutztes Ein-Ausgangspaar des MAX232 
verwendet. Man kann aber auch einen 74HCT125 nehmen.

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm,
ich muss Benedikt zustimmen, bei mir liefen bisher auch alle Karten.
Bennutze auch keinen Pegelwandler, irgendwas ist in eurem Code oder 
Timing faul. Versuchts vielleicht mal in Assembler .
Gruss

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Walter,

Frage 1: Kannst Du mir mal die Eagle Lib zuschicken mit dem SD 
Kartenhalter?

Die andere Sache: Mit dem Treiber kann man bis 20 Mhz fahren, statt nur 
1 Mhz mit Widerständen. Sporadische Fehler werden vermieden, die hatte 
ich mit Widerständen immer.

Das andere.... ich habe eine 16MB Karte, die will ums Verrecken nicht. 
Irgendwann gibt man auf, wenn 99% der anderen es ja tun. Spiel mal mit 
der Initsequenz herum, lasse sie öfter und länger laufen. Da man ja die 
Karte nicht debuggen kann hilft hier nur Trial & Error.

Überprüfe auch mal, ob die 3,3V -> 5V wirklich funktionierern, der PIC 
verträgt keine 3.3v an seinen SPI Pins.

Bei der Portierung von AVR Code habe ich aufgehöprt, der CCS Compiler 
ist total anders, hat viele Einschränkungen. Daher wohl auch so billig.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fubu1000 wrote:
> Hmm,
> ich muss Benedikt zustimmen, bei mir liefen bisher auch alle Karten.
> Bennutze auch keinen Pegelwandler, irgendwas ist in eurem Code oder
> Timing faul. Versuchts vielleicht mal in Assembler .

Assembler muss nicht unbedingt sein. Ich hatte einmal eine HDD mit einem 
8051 inkl FAT usw. angesteuert. Das würde ich mir heute nie wieder 
machen.

Ich denke mal es gibt 2 Fehlerquellen:
- Pegelwandler (benutze ich nie, sondern ich lasse den uC immer mit 3,3V 
laufen, daher kann ich dazu nicht viel sagen, außer dass dies wirklich 
eine schöne Fehlerquelle ist).
- Software, insbesondere Wartezeiten und SPI Timing (auch im 
Zusammenhang mit dem Pegelwandler), und der SPI Geschwindigkeit bei der 
Initialisierung.
Eigentlich ist der SPI Modus der SD Karten nämlich nicht kompatibel zu 
den 4 SPI Modes, die die meisten uC können, denn afaik sampled die Karte 
auf der gleichen Flanke, auf der auch die Daten ausgegeben werden. 
Dadurch ist schnell mal ein Bit um eine stelle verschoben.
Bei der Initialisierung der SD Karte darf der Takt nur einige 100kHz 
betragen. Das berücksichtigt nicht jede Software.
Weiterhin sind die Wartezeiten bei der Initialisierung oft falsch. Da 
musste ich bei einigen Softwarversionen ein wenig anpassen.

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,
wo soll ich die LIB denn hinschicken?

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

Bewertung
0 lesenswert
nicht lesenswert
Ich häng` sie jetzt einfach mal an. Sie ist von mir selber erstellt und 
läuft unter Eagle 4.03

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eigentlich ist der SPI Modus der SD Karten nämlich nicht kompatibel zu
> den 4 SPI Modes, die die meisten uC können, denn afaik sampled die Karte
> auf der gleichen Flanke, auf der auch die Daten ausgegeben werden.

Ich hoffe sehr jeder hier hat obigen Satz mindestens dreimal gelesen!

Das ist naemlich ein grosses Problem das dafuer sorgen kann das
manche Karte funktionieren und andere nicht. Und gelegentlich glaubt
man vielleicht auch das es an Widerstaenden oder an der Kabellaenge,
oder am Takt liegt weil die vielleicht die entscheidende ns an
der Flanke hinbiegen damit es mit der einen Karte nun laeuft!

Momentan verzichte ich auf Hardware-SPI bei MMC/SD. Bei Gelegenheit
wollte ich nochmal ausprobieren wie es ist wenn ich in einer der 
Leitungen
noch eine extra Gatterlaufzeit einfuege.

Olaf

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt: Bei der Arbeit nutzen wir auch nur C++, da iss Assembler mal 
ne schöne Abwechslung.

"Assembler muss nicht unbedingt sein. Ich hatte einmal eine HDD mit 
einem
8051 inkl FAT usw. angesteuert. Das würde ich mir heute nie wieder
machen."

Ich hab nen Mp3Player mit SD in Fat, Grafik LCD mit Zeit und ID3-Tag 
Anzeige alles in Assembler programmiert, das war nen Spass würde ich 
wieder machen.^^

Gruss

Autor: wostri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
entschuldigung, wenn ich mich hier so laienhaft einmische. Ich kann 
nirgendwo Hilfe bekommen und in diesem Forum scheinen Leute mit Ahnung 
zu sein: Meine Speicherkarte hat mit allen wertvollen Fotos drauf den 
Geist aufgegeben, es handelt sich um eine SanDisk 1 GB. Rettungssoftware 
bringt nichts, weil sie gar nicht erst als Laufwerk bzw. Datenträger 
erkannt wird. Auch der Trick über formatieren in der Kamera und dann 
wieder die Daten wiederherstellen geht nicht, auch die Kamera meldet 
einen Datenfehler. Wahrscheinlich entleerte sich beim Speichern einer 
Aufnahme der Akku der Kamera. Die Daten sind doch noch drauf, hat 
vielleicht irgendwer eine Idee, wie man sie restaurieren könnte? Vielen 
Dank erstmal und nochmal sorry für die Störung.. 
stricker@gesundheitsseiten.de

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon mal hiermit probiert:
http://www.cgsecurity.org/wiki/PhotoRec_DE

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eigentlich ist der SPI Modus der SD Karten nämlich nicht kompatibel zu
> den 4 SPI Modes, die die meisten uC können, denn afaik sampled die Karte
> auf der gleichen Flanke, auf der auch die Daten ausgegeben werden.

So? Interessant.
In der mir vorliegenden Spezifikation von Sandisk übernimmt die SD-Karte 
ihre Daten mit der steigenden Flanke von CLK, und gibt ihre Daten mit 
der fallenden Flanke von CLK von sich.

Ich habe bisher bei KEINER Karte Probleme gehabt. Man muss nur die 
Spezifikation GENAU einhalten - und das ist manchmal nicht einfach.

Einige Karten haben z.B. vom Kommando zur Antwort eine Anzahl an bits, 
die nicht durch 8 teilbar ist. Da muss man sich dann auf das erste Bit 
der Antwort synchronisieren. Einige mögen auch nicht, wenn man zwischen 
Kommando und Daten das ChipSelect wegnimmt.

Es gibt sehr wohl einen Unterschied zwischen Transfers mit einem Sektor 
und mit mehreren, besonders beim Schreiben. Man sollte mindestens 2 
KByte am Stück transferieren, wo das möglich ist. Dann muß der 
Controller in der SD-Karte nicht mit physikalischen Teilblöcken 
arbeiten.

Autor: Frank Götze (embedded-os)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ein Link zu meinem MMC/SD Projekt. Nach etlichen Rückfragen bei 
diversen Herstellern habe ich derzeit keine "unsupported card" - aber 
man weiß bei den Karten ja nie...

http://www.embedded-os.de/index.html?pcfat_port.htm

Dieses Projekt kann mit MMC-/MMCplus-/HD-MMC-/SD- und SDHC- Karten 
umgehen, bei Verwendung eines SPI-Interfaces.

PS: Wer einfach nur Widerstände als Spannungsteiler verwendet (5V/3.3V), 
bekommt eine unangenehme Signalverscheifung, die bei höheren 
Übertragungs-Geschwindigkeiten zu Problemen führen kann.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wostri: SD Karte aufmachen, darin findest Du einen oder mehrere NAND 
flash chips. Die kannst Du z.B. mit einem USB-xD Kartenleser auslesen:

http://www.uchobby.com/index.php/2007/05/05/read-e...

Autor: Volker Mehrdorn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibt es ein paar interessante Oszilloskop-Bilder zu den 
Widerstands- und Transistorlösungen als Pegelwandler. Das könnte auch 
etliche der Probleme erklären.
Link anklicken und nach unten scrollen: 
http://www.shop.display3000.com/pi8/pi14/pd102.html

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hier gibt es ein paar interessante Oszilloskop-Bilder zu den

Ich fand ja vor allem den Preis und das schamhafte verschweigen
des eingesetzten Pegelwandlers interessant. :-)

Olaf

Autor: JÜrgen Grieshofer (Firma: 4CKnowLedge) (psicom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Volker Mehrdorn wrote:
> Hier gibt es ein paar interessante Oszilloskop-Bilder zu den
> Widerstands- und Transistorlösungen als Pegelwandler. Das könnte auch
> etliche der Probleme erklären.
> Link anklicken und nach unten scrollen:
> http://www.shop.display3000.com/pi8/pi14/pd102.html

F***, ich glaub ich werd da jetzt selber mal nachmessen... sieht ja 
fürchterlich aus...

Autor: wostri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1000 Dank für die Linktipps bezügl defekter SD Card. Es hat geklappt, 
die Bilder sind wieder da. Mit OnBelay von CompuApps wurde die Karte 
ausgelesen. Anschliessend Daten auf eine neue Karte schreiben lassen, 
muss dann in der Kamera formatiert werden. Daten wiederherstellen hat 
mit smart recovery von convar pcinspector geklappt. Prima! Luftsprünge 
mach! Freu freu! Vielen Dank an alle!

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Bilder unter dem Link sehen mir aber arg gestellt aus. Ich habe bei 
meinen Widerstands-pegelwandlern immer 1,8k + 3,3k genommen und 
anschließend nur ein kleines Stück Leiterbahn bis zur SD Karte und ich 
kann mich nicht daran erinnern, dass es dermaßen aussah.

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade mal an einem R-Pegelwandler mit 1k zu 2k2 nachgemessen.
Etwas übertrieben sind die Bilder von Display 3000 ja schon. Oder es 
liegt an dem Rigol...

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

Bewertung
0 lesenswert
nicht lesenswert
also ich habe mir bei Display3000 vorletzte Woche ein SD Kartenmodul 
gekauft und bin nun am langen Wochenende endlich dazu gekommen es 
auszuprobieren. Und man glaubt es kaum: alle meine Karten funktionieren 
mit diesem Modul (einige gingen vorher nicht und ich habe da wirklich 
alles mögliche probiert) ausserdem erlauben sie mir maximale 
Datenfrequenz, was ich vorher so auch nicht hinbekam. Die Doku ist auch 
sehr ausführlich und gut gemacht.

Dann zu den Bildern - auf den ersten Blick sieht das schon seltsam aus 
aber mann muss natürlich schon die gleiche Skalierung wählen, sonst 
vergleicht man Äpfel und Birnen. Ich habe mal das Bild von Display3000 
künstlich so gestaucht und mit Copy&Paste vervielfacht so das es der 
gleichen Skalierung wie beim LeCroy Bild entspricht: dann ist der 
Unterschied vernachlässigbar (oben LeCroy, unten Display3000 
Originalbild) und eher Probe- und/oder Widerstandsabhängig.
Oli

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.