www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SPI: kein SCK bei Receive - Warum?


Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe es mit einem Infineon XC888CM zu tun.
Die Konfiguration (SPI usw.) habe ich größtenteils mit dem Assistenten 
DAvE vorgenommen, der SPI und alles andere schön einstellt. Des weiteren 
habe ich das UserManual schon ausgiebig studiert, habe aber keine Lösung 
(irgendein Bit eines SPI-Registers o.ä.) gefunden.

UserMan: 
http://www.infineon.com/dgdl/XC88xCLM_UM_v1_1.pdf?...
^^Kapitel 12.3 (ab Seite 12-31)

Folgende Situation: der µC als SPI-Master. Die Kommunikation mit dem 
Slave funktioniert prinzipiell, zumindest einseitig, d.h.:

Senden funktioniert einwandfrei, der Slave tut auch nach Senden von 
Befehlen das, was er soll. Problem: Wenn ich dem Slave sage, dass er mir 
was schicken soll, verweigert der µC den SCK weiter zu treiben, damit 
der Slave dann auch seine Daten auf die Leitung legen kann.

Beim Transmit schreibe ich meine Daten ja einfach ins Transferregister 
und schon beginnt der SPI die Daten ordentlich zu senden.
Wenn ich im Gegenzug Daten aus dem Receiveregister lese, sollte ja das 
gleiche passieren: Master generiert den Clock und Slave haut seine Daten 
auf SDO.
Fakt ist aber: Die Leitung bleibt nach dem Senden des Lesekommandos an 
den Slave (Transmit) tot, wo eigentlich etwas zu empfangen sein sollte.

Zur Veranschaulichung noch das Oszi-Bildchen dazu: Oben SCK, unten 
SDI/SDO.

Die Leseabfolge: Ich sende ein Read-Kommando, warte bis der Bus frei ist 
und lese dann das Receiveregister aus.
Eine Abfrage des Receive-Interrupt-Bits
  if (IRCON1 & 0x04)  //  if Receive Interrupt Request
bringt auch keinen Erfolg, denn dahin kommt er gar nicht.

Was kann man da machen?

Vielen Dank für eure Hilfe.


Zum Abschluss: Meine SPI-Konfigs:

  ///  - Port Selection
  SSC_PISEL     =  0x00;    // load SSC Port Input Select Register to
                            // Port A
  /// 
-----------------------------------------------------------------------
  ///  Configuration of the used SSC Port Pins:
  /// 
-----------------------------------------------------------------------
  ///  Pin SCLK (P1.2) is selected for SCLK ouput
  ///  Pin MTSR_0 (P1.3) is selected for Master Transmit Output
  ///  Pin MRST_0 (P1.4) is selected for Master Receive Input
  ///  Pin CSBO (P1.5) is selceted for Master Chip Select Output

  SFR_PAGE(_pp1, noSST);         // switch to page 1 without saving
  P1_PUDSEL |= 0x14;    //P1.4 SDI Pull-up (wird von Slave benötigt)
  P1_PUDEN  |= 0x14;    //Test: P1.2 Clock pull-up
                        //funzt auch ohne CLK-Pull-up nicht.

  SFR_PAGE(_pp2, noSST);         // switch to page 2 without saving
  P1_ALTSEL0      |= 0x1C;              //  set AltSel0
  P1_ALTSEL1      &= ~(ubyte)0x1C;      //  set AltSel1

  SFR_PAGE(_pp0, noSST);         // switch to page 0 without saving
  P1_DIR          |= 0x2D;      //  set OutPut Direction

  SSC_CONH_P &= ~(ubyte)0x80;   //  enable access to control bits

  /// 
-----------------------------------------------------------------------
  ///  Configuration of the SSC Baud Rate Generator:
  /// 
-----------------------------------------------------------------------
  ///  - required baud rate = 500,000 kbaud
  ///  - real baud rate     = 500,000 kbaud
  ///  - deviation          = 0,000 %

  SSC_BRH       =  0x00;    // load SSC baud rate time reload register
                            // high
  SSC_BRL       =  0x17;    // load SSC baud rate time reload register
                            // low

  /// 
-----------------------------------------------------------------------
  ///  Configuration of the SSC Operation Mode:
  /// 
-----------------------------------------------------------------------
  ///  - this device is configured as SSC master
  ///  - transfer data width is 8 bit
  ///  - transfer/receive MSB first
  ///  - shift transmit data on the leading clock edge,
  ///    latch on trailing edge
  ///  - idle clock line is low,
  ///    leading clock edge is low-to-high transition
  ///  - check receive error is enabled
  ///  - check phase error is enabled


  SSC_CONH_P    =  0x46;         // load SSC control register

  SSC_CONL_P    =  0xB7;         // load SSC control register

  SSC_CONH_P   |=  0x80;         //  disable access to control bits

  ///  - SSC interrupt is enabled
  IEN1   |= 0x02;          //  Enable SSC interrupt

Autor: ::: (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da der Controller der Master ist macht der Controller den SCK. Wie macht 
man den SCK weiter ? Indem man zB 0xFF sendet, oder sonst was.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieso soll ich was senden, wenn ich empfangen will? Im Vollduplex geht 
das zwar, aber sinnvoll ist das nicht. Oder doch?

Autor: ::: (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein slave wird nie den SCK bewegen. Nur der Master. Send ein 0xFF und 
lies das SPIDR, und gut ist. SPI geht nun mal so.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wieso soll ich was senden, wenn ich empfangen will?

Weil der Slave nichts von alleine sendet.
Der Master muss dazu einen Clock generieren.
Deshalb sendet man 0xFF.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, und wieso generiert der Master keine Clock wenn ich einfach nur das 
Receive-Register lese? Dann weiß der doch, dass ich Daten haben will. 
...

Ok, mehr als Probieren kann ich das mit dem 0xFF senden ja nicht ... 
schaun wir mal.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass der Slave keine clock generiert war mir klar.

Autor: ::: (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SPI sind zwei Schieberegister, eins das rausgeht, eins das reinkommt. 
Und das Schieberegister lesen generiert keinen Clock, sondern laedt nur 
dessen wert

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann hätte ich wohl einfach nur bisschen Grundverständnis von SPI 
mitbringen müssen. Dass beim Lesen da intern wirklich nur das Register 
ausgelesen wird war mit unbekannt.

Ich habs ausprobiert und es funzt in soweit, dass erstmal was aufm Bus 
zu sehen ist. Ob das nun was ordentliches ist muss ich noch prüfen.

Danke für die erste Hilfe.

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hm.. 0xFF gut und schön, aber der µC sendet komischer Weise immer auf 
beiden Kanälen: SDO und SDI. Nun sehe ich zwar Signale auf dem µC-SDI, 
die vom Slave generiert werden, aber der Low-Pegel ist zu hoch, weil ich 
ja 0xFF sende. (siehe Oszi-Screenshot). 1,8V sind bisschen im verbotenen 
Bereich. Was macht man da? Pull-down-R oder sowas?

Danke für eure Hilfe.

Autor: Arne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SDI (MISO) mal mit ein paar Kiloohm (4k7 - 10k) gegen High legen.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon probiert, hilft leider nix.

Autor: ::: (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht mal das SPI diagramm anschauen ? MISO bedeutet 
Master-In-Slave-Out, MOSI bedeutet Master-out-Slave-in. Das Device auf 
der anderen Seite hat auch einen Eingang, ueblicherweise einen SDI, und 
einen ausgang, der SDO. Jetz muss man die Richtigen zusammenschalten. 
Was offensichtlich geschah, sonst waere eh nichts. Wenn nun dieser Pegel 
zu hoch ist, so arbeiten zwei Ausgaenge aufeinander. Koennte es sein, 
dass das Device kein SPI, sondern ein I2C ist, welches die Richtung 
umschaltet ?

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die dinger sind schon richtig zusammengeschaltet. ;)

Der Slave hat definitiv eine SPI-Schnittstelle (kein I²C). Der 
µC-Receive Input (MISO) Pin 1.4 ist wie oben in der Konfig angegeben 
(P1_DIR |= 0x2D //BIT:0=Input,1=Output) als Input gesetzt. Trotzdem will 
der µC dort auch immer gleichzeitig auch Senden (was mir unsinnig 
erscheint, ich aber nicht ergründen konnte warum das so ist, trotz, dass 
ich den Halbduplex, der in der Konfig oben noch fälschlicher Weise 
angegeben ist (SSC_CONL_P = 0xB7 //oberstes Bit: 
0=LoopBack(Halbduplex),1=normal(vollduplex)), wieder rausgenommen habe)

Die Bytes die Übertragen werden scheinen auf den ersten Blick auch i.O. 
zu sein (abzüglich des Low-Offsets von 1,8V). Es liegt also wirklich nur 
am 0xFF welches fälschlicher Weise auch auf dem MISO-Pin (1.4) gesendet 
wird (warum auch immer). Ich habe außerdem schon versucht vor dem Senden 
von 0xFF das MOSI-Pin zu blockieren, indem ich die Richtung auf Input 
änderte (MISO ist ja sowieso Input - klar) - ohne Erfolg. Was mir grad 
noch einfällt wäre, das Pin aus dem SPI-Modus für diese Zeit 
rauszunehmen, sofern das überhaupt geht, denn dann muss ich den 
SPI-Modus generell erstmal ausschalten, dann das Pin in den Normalen 
I/O-Modus setzen, SPI wieder anschalten, Daten senden (wobei ich das 
Receive-Register Lese), SPI ausmachen, MOSI-Pin wieder in SPI-Modus, SPI 
wieder anmachen. Uiui ... Das probiere ich heute nicht mehr - Morgen ist 
auch noch ein Tag. =)

Danke für eure Hilfe.

Aber danke für den Versuch.

Noch jemand einen Rat?

Autor: Marco L. (lehmi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ideen:

1.) du könntest einfach versuchen, eine 0 zu senden (falls nicht schon 
probiert)
2.) prüfen, ober es zwischen MISO und MOSI auf der Platine ein 
niederohmige Verbindung gibt

Grüße

Autor: ::: (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob halbduplex, oder vollduplex ist keine Sache des SPI masters sondern 
des devices. Das device weiss wann es senden muss. gemaess Datenblatt.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Marco:

zu 1.) 0-Byte senden natürlich schon probiert, da zieht der µC die 
Leitung gleich voll auf Low, sodass keine Daten vom Slave durchkommen 
(der zieht ja seinerseits auch nur über den Pull-up vom µC die Leitung 
auf Masse, wenn er ne 0 senden will - von daher kann das ja auch nicht 
funzen).

zu 2.) Ja, eine "niederohmige" Verbindung besteht ab dem Moment, wo ich 
bestimme welche Pins Ausgänge sein sollen (P1_DIR = 0x2D) --> zw. Pin 
1.4 (MISO) und Pin 1.3 (MOSI) sind dann 240 Ohm (vorher 14K) - Kann mir 
das einer erklären? Hängt das u.U. daran, dass MISO am Pull-up (wie vom 
Slave erfordert) und MOSI ein Ausgang ist? warum die aber dann fast 
kurzgeschlossen sind weiß ich nicht zu beantworten. Fakt ist: Beide Pins 
hängen vor und nach P1_DIR an 5V - Es wird also wirklich intern eine 
Verbindung gesetzt. Warum auch immer (LoopBack ist ja wie gesagt aus).

Danke für eure Gedankenimpulse

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also meine Idee von gestern hinkt noch einbisschen: Trotz dass ich den 
SPI-Modus vorher ausschalte (SSC_EN=0), dann jetzt sogar zusätzich schon 
einen anderen Port als MOSI wähle, SPI-Modus wieder einschalte, sendet 
der trotzdem auf dem alten Pin 1.3 Daten. Ich glaub der will mich 
foppen.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch jemand eine Idee dazu?

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das gibts ja nicht! Ich habe jetzt mal aus lauter Verzweiflung mit den 
MISO und MOSI Leitungen rumgespielt. Egal welche Kombination ich 
ausprobiere (1. Nur MOSI, 2. nur MISO, 3. µC-MISO an Slave-MOSI und 
umgekehrt) - Der Slave reagiert immer darauf. (Selbst wenn ich nur die 
MISO-Leitung an die richtigen Pins anlege - Der Slave empfängt also auch 
auf dem Sendepin - so ein Schmarn!)

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist denn das für ein Slave und wie sieht der Schaltplan aus?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für ein IC hängt da als Slave dran?
(Evtl. Datenblatt in den Anhang).

Es gibt ICs denen kann man zum Lesen von Daten nicht irgendwas als 
"Dummybyte/-Wort" senden, sondern es gibt dafür spezielle Bytes (glaub 
ein
CC1100 Chipcon hat dafür ein speielles NOP Kommandobyte).

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Slave ist ein LTC6802. Datenblatt im Anhang. Mit den Kommandos (in 
diesem Fall Read-Kommando) stimmt ja aber alles soweit. Er führt ja das 
aus was er soll, es geht nur um den erhöhten Low-Pegel beim Empfang von 
Daten wie oben geschildert, den ich so nicht akzeptieren möchte.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Setz mal einen Widerstand (ca. 4k7) zwischen SDO und MISO. Dann miss die 
Spannungen an beiden Seiten. Wenn an der SDO Seite die Spannung sauber 
auf
0 runtergeht, dann muss wohl der MISO einen aktiven Ausgangstreiber 
haben.

Alternativ dazu könnte es sein, dass Du dir den LTC irgendwie schon 
abgeschossen hast. Dann hast Du hoffentlich noch ein paar Ersatz ICs
rumliegen.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prüf mal sie Platine, nach den Beschreibungen vermute ich fast das du 
Kurzschlüsse zwischen den einzelnen Pins hast.
Oder das eins/beide der IC's defekt sind.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias: Also auf der LTC-SDO Seite wird mit zusätlichem R zwischen 
µC MISO und LTC-SDO schön auf Masse gezogen. der LTC scheint also OK. 
Beim LTC gibts auch zwischen SDI und SDO nen Megaöhmchen.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann würde ich fast vermuten, dass der MISO als Output konfiguriert ist!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alternativ werden die beiden Chips mit unterschiedlichen Spannungen 
versorgt....?

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der MISO ist eben genau nicht als Output definiert sondern hat lediglich 
einen µC-internen Pull-up (siehe Konfig: P1_PUDSEL=0x10 & P1_DIR=0x2D 
-->Pin 1.4=MISO). Warum aber trotzdem auf der Leitung gesendet wird ist 
mir ja ebenfalls unklar.

Ja die beiden Komponenten haben verschiedene Spannungsquellen, die 
Massen beider habe ich aber verbunden.

Danke für alles Denken.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit welchen Spannungen werden die Teile versorgt?

3,3V und 5V?

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der µC mit 5, der LTC von 10-50V (ja wirklich)

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du eine Pegelanpassung zwischen den beiden IC?

Autor: Felix Bonjour (e-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jürgen (Gast)

wie hast du den Pin 40 (VMode) beschaltet?

Hast du das ganze Datenblatt mal durchgelesen?

Cheers
Felix

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralph: inwiefern Pegelanpassung, außer, dass ich Masse schon verbunden 
habe und der SDO-Pegel auch 5V hat?

@Felix: VMODE ist mit VREG verbunden, also TTL-Pegel. Ja das Datenblatt 
hab ich schon paar mal durch (zumindest den relevanten Teil) ;)

Danke fürs Helfen.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>der µC mit 5, der LTC von 10-50V (ja wirklich)

deshalb die Pegelanpassung

Autor: Felix Bonjour (e-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> deshalb die Pegelanpassung

Ist nicht notwendig, der LTC6802 hat eine internen Regler. Das SPI wird 
ab diesem Regler betrieben.

@Jürgen (Gast)
poste doch mal dein Schema. Das wurde schon von anderen vorgeschlagen.

Cheers

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Warum aber trotzdem auf der Leitung gesendet wird ist
>mir ja ebenfalls unklar.

Weil dort immer etwas gesendet wird wenn ein Clock anliegt.
Dazu muss an SDI nichts angeschlossen sein.
Sonst könnte man die Dinger nicht in Reihe schalten.

Der SDO kann nur 1,2mA sinken. Da der Lowlevel zu
hoch ist liegt die Vermutung nahe daß der Pullup
zu klein ist (oder doch ein Ausgang aktiv, wie auch immer).

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Felix: Hier ein unprofessionelles Aufbauschema. Der µC sitzt ja auf so 
nem StarterKit, daher dort nix weiter dran. Hoffe das reicht euch so. 
Wie gesagt, die Massen noch verbunden.

@Holger: Dass der Pull-up zu klein sein könnte hatte ich auch schon in 
Betracht gezogen, allerdings habe ich daraufhin dann mal einen externen 
5k Pullup versucht - ohne Erfolg - selbes Ding.

Problem ist eben, dass der µC auch auf MISO sendet.
holger (Gast):
>Weil dort immer etwas gesendet wird wenn ein Clock anliegt.
>Dazu muss an SDI nichts angeschlossen sein.
>Sonst könnte man die Dinger nicht in Reihe schalten.

^^könntest du das bitte genauer erläutern?

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sollte mehr Ahnung in E-Technik haben *asche über mein haupt streu*: 
Was ist wenn ich den µC-MISO-Pin als OpenDrain schalte?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>5k Pullup versucht - ohne Erfolg - selbes Ding.

Viel zu klein. Laut Datenblatt ist die Spannung an
SDO bei 500uA bereits bei max. 0.3V. Und mit 5k
ziehst du doppelt so viel.

>Problem ist eben, dass der µC auch auf MISO sendet.

Dann könnte er einfach nur defekt sein.
Normal ist das nicht.

>holger (Gast):
>>Weil dort immer etwas gesendet wird wenn ein Clock anliegt.
>>Dazu muss an SDI nichts angeschlossen sein.
>>Sonst könnte man die Dinger nicht in Reihe schalten.

>^^könntest du das bitte genauer erläutern?

Ich meinte damit den SDO. Dort kann z.B. das zuletzt
gesendete Kommando wieder rauskommen wenn der Slave nichts
zum senden eingefügt hat. SPI besteht nur aus Schieberegistern.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Viel zu klein. Laut Datenblatt ist die Spannung an
>SDO bei 500uA bereits bei max. 0.3V. Und mit 5k
>ziehst du doppelt so viel.

Stimmt, aber selbst bei doppelt so viel kommts noch nicht an das davon 
Dreifache ran, was sich auf meiner Leitung befindet. Schon blöd.

>Dann könnte er einfach nur defekt sein.
>Normal ist das nicht.

defekt wär noch blöder. Komisch eben nur, dass er nach der 
Richtungszuweisung (P1.3 Output, P1.4 Input) da eine Verbindung zwischen 
den Pins schaltet. Das ist wirklich nicht normal aber kann natürlich 
auch noch an irgend einem Register liegen, was ich noch nicht entdeckt 
habe, obwohl das ja mit der Konfiguration über den Assistenten 
einwandfrei laufen sollte. Hach!

>Ich meinte damit den SDO. Dort kann z.B. das zuletzt
>gesendete Kommando wieder rauskommen wenn der Slave nichts
>zum senden eingefügt hat. SPI besteht nur aus Schieberegistern.

^^Achso, ja das ist richtig.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch jemand eine Idee dazu, was man gegen den Offset machen kann?

Autor: Florian H. (arclite)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

hast du schon weitere Erfolge verzeichnen können?

Bei mir tritt der gleiche Effekt auf.
Habe auch das EasyKit XC888-LQFP von Infineon.

Ich habe als Slave einen RFM21b, da ist aber im Prinzip egal, außer das 
dort keine Pull-Up/Down-Rs an den Ltg gebraucht werden.

Mit dem Slave hat das anscheinend nichts zu tun, weil wenn dieser nicht 
angeschlossen, dann passiert das trotzdem.

Das Signal auf SDI und SDO ist immer komplett gleich.

Noch jemand eine Idee?

Viele Grüße
Florian

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm.. ist jetzt schon ein Weilchen her, dass ich mit dem Starterkit 
rumgefummelt habe. Ich glaube, dass ich das dann einfach irgendwann 
aktzeptiert habe, weils trotzdem ging und ich noch andere Sachen zu tun 
hatte. Wie es jetzt auf dem selbst hergestellten Board aussieht könnte 
ich ja mal testen - aber ich glaub da war der Pegel voll ok. Könnte als 
an zu langen SPI-Leitungen zwischen Slave und Master hängen.

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.