ADDR pin high oder low? 0x2B versucht? Manche verstehen den RW bit auch inklusive adresse manche nicht. Mal versuchen 0x2A oder 0x2B durch 2 teilen.

Schematic posten wird auch helfen.

Keine Prosa schreiben. Das versteht man nicht. die Sprache der Elektronik ist der SCHALTPLAN!

Andras H. schrieb:

Mal versuchen 0x2A oder 0x2B durch 2 teilen.

Wenn ich das DaBla lese, eher mal 2 nehmen!

Andras H. schrieb:

Mal versuchen 0x2A oder 0x2B durch 2 teilen.

nicht doch besser *2?

PULL am SCL ?

Pull-ups an SDA und SCL vorhanden und sinnvoll dimensioniert..?

Wie sehen die Signale am Oszi aus? -> der LSA ist Imho erst der zweite Schritt, nachdem klar ist dass die Flanken schön sauber sind, Anstiegszeit passt etc.

Helmut -. schrieb:

mal 2 nehmen!

Genau. Der LA zeigt nur 0x15 als 7-Bit-Adresse. Das ist falsch.

Ich verstehe nicht ganz, was das Problem ist. Soll ich statt 2a jetzt 54 als adresse senden? Falls ja, wieso zeigt der logic analyzer eine falsche bzw. halbierte Adresse an?

Edit: Ich habe jetzt die Adresse um ein bit geshiftet und auch die einstellung gefunden um es richtig anzeigen zu lassen. Mit 54 als Adresse also 2a um 1 geshiftet bekomme ich aber immernoch NACK.

Ein ganzes Betriebssystem um einen Sensor zu lesen. Boaaahh...

Zeige bloss nicht den Sourcecode des Programms, der könnte die Leser und potentiellen Helfer verwirren.

Jonatan schrieb:

Soll ich statt 2a jetzt 54 als adresse senden?

Nein, du sollst 0x2A als Adresse senden.

Da die Adresse in den oberen 7 Bit des ersten Byte steckt, hat das erste Byte den Wert 0x54. Aber nur beim Lesen. Bei Schreibzugriffen hat das erste Byte den Wert 0x55.

Mit 54 als Adresse also 2a um 1 geshiftet bekomme ich aber immernoch NACK.

Dann lasse einen Port-Scanner laufen. Bei Arduino ist das ein der Beispiel-Sketche.

Du könntest auch einen PC mit I²C Adapter dran hängen und damit scannen. Das ist besonders einfach unter Linux mit den i2c-tools und einem ATtiny85 als Adapter. Siehe angehängte Firmware.

Im Layout ist das routing für SCL (pin 1) und SDA (pin 2) nicht besonders optimal, das sollte man auf jedenfall mal mit einen Oszi statt LA schauen wie die signal integrity ausschaut.

BTW: Layout mit eingeblendeten Pin-nummern wäre sehr hilfreich wenn ein Fremder da ein Review machen soll, Schaltplan ohnehin. Und für meinen Geschmack sollte man floatende Pins im layout vermeiden, auch wenn das Datenblatt es gestattet, z.Z. zähle ich zwei Pins ohne Beschaltung.

Das mit der device-adresse wird je nach Hersteller unterschiedlich beschrieben, mal zählt man das RnW-bit mit rein, mal nicht, da ist es besser man sucht sich im Datenblatt die konkrete Waveform raus und vergleicht diese ab startbit von links nach rechts. (siehe Anhang).

Die Darstellung des LA mit Datenwechsel genau zur aktiven Flanke des SCL ist IMHO verwirrend. Auch da checken, was das Scope zeigt und ebentuell tatsächlich mal Hold und setup-Zeiten ermitteln.

Jonatan schrieb:

Logic_Analyzer.png

Im Datenblatt steht zur I2C-Adresse: "I2C Address selection pin: when ADDR=L, I2C address = 0x2A, when ADDR=H, I2C address = 0x2B."

Wie hast du den Address selection pin (ADDR) beschaltet und warum verwendest du für die Abfrage die Adresse 0b0010101, also 0x15. Das kann nicht funktionieren. Die I2C-Adressen besitzen in Einklang mit der I2C-Spezifikation 7 Bit (Figure 11 im DB).

Sonst hilft ein I2C-Scanner.

Andras H. schrieb:

Manche verstehen den RW bit auch inklusive adresse manche nicht.

Bei TI umfasst die Adresse A6..A0. Das sind 7 Bit entsprechend der I2C-Spezifikation. Das RW-Bit hat nichts mit der Adresse zu tun, außer dass es im gleichen Byte wie die Adresse zum I2C-Slave übertragen wird (s. die bereits genannte Figure 11 im DB).

Rainer W. schrieb:

Wie hast du den Address selection pin (ADDR) beschaltet

Kann man aus seinem Schaltplan entnehmen.

Wie hast du den Address selection pin (ADDR) beschaltet

Kann man aus seinem Schaltplan entnehmen.

Hab's mal als Ersatz für den TO zusammengestückelt; ADDR liegt an GND.

Dann muss es so aussehen wie im Anhang.

BTW: was ist denn aus dem Problem aus dem Beitrag "Unerwartetes Signal einer 40Mhz Clock" geworden?

Moin,

Der ADDR pin ist auf Ground, wie man in meinem Schaltplan lesen kann.

Ich habe jetzt nach dem angehängten Schema alle Adresssen, also von 00 bis 7F durchprobiert und bei keiner einen ACK bekommen.

Somit muss der Fehler, wenn ich das richtig sehe, an anderer Stelle liegen.

Ich benutze ein Betriebssystem um es zu lernen, nicht weil es nötig ist und dementsprechend macht es wenig Sinn meinen Code hier zu posten, weil das Signal ja das richtige ist und der Mikrocontroller nunmal nichts macht, außer das Signal zu generieren.

Schaltplan habe ich auch noch mal engehängt, falls der im Thread untergeangen ist.

Ich habe auch mit dem Oszi die Flanken überprüft, die sind nicht optimal aber im Toleranzbereich des LDC. Ich werde die Widerstände ersetzen aber glaube nicht, dass das Problem hierdurch behoben wird.

Lothar M. schrieb:

BTW: was ist denn aus dem Problem aus dem Beitrag "Unerwartetes Signal einer 40Mhz Clock" geworden?

Ich habe herrausgefunden, dass die Clock nicht das Problem ist und das unerwartet Signal nur an der zu niedrigen Auflösung meines Oszis lag, wie in Beitrag "Re: Unerwartetes Signal einer 40Mhz Clock" beschrieben.

Jonatan schrieb:

Es lässt sich nicht ganz ausschließen, dass der LDC tatsächlich richtig kontaktiert

Wenn der SDA-Pin am LDC nicht angelötet ist, dann siehst du allein wegen des Pullups auch ein NAK, obwohl der LDC gar keines "sendet". Oder andersrum: dieses Oszi-Bild siehst du auch ganz ohne LDC.

Ich würde da mal an VCC, GND, CLK und die I2C-Pins 5 Fädeldrähte dranlöten (eine gute Lupe tut da Wunder) und schauen, ob das Ding dann kommuniziert.

Jonatan schrieb:

Ich habe herrausgefunden, dass die Clock nicht das Problem ist

Das dort "an anderer Stelle" zu suchende Problem ist also dieses hier mit der I2C-Kommunikation?

Jonatan schrieb:

Ich habe jetzt nach dem angehängten Schema alle Adresssen, also von 00 bis 7F durchprobiert und bei keiner einen ACK bekommen.

Dann würde ich doch mal die Adressen 0x80 bis 0xFF durchprobieren.

Bis jetzt hat niemand einen relevanten Sourcode von dir gesehen. Wer weiss was da drin passiert.

Überlege grundsätzlich deine Schreibweise von Adressen. Was du schreibst sind "Dezimalzahlen", was du möglicherweise meinst sind Hexadezimazahlen. ABer so genau weiss das niemand.

Lothar M. schrieb:

Ich würde da mal an VCC, GND, CLK und die I2C-Pins 5 Fädeldrähte dranlöten (eine gute Lupe tut da Wunder) und schauen, ob das Ding dann kommuniziert.

Das habe ich bereits versucht, aber um diese größe Drähte an den Chip dran zu löten reichen meine Lötfähigkeiten nicht aus. Ich werde es nochmal probieren, bezweifle aber das ich damit auf einen grünen Zweig komme.

Wie gesagt habe ich es ja auch schon mit den verschiedensten Methoden den Chip mehrfach aufgelötet. Ich habe auch mit einer Lupe nachgesehen und bin mir recht sicher, dass die Pins alle kontaktieren.

Lothar M. schrieb:

Jonatan schrieb:

Ich habe herrausgefunden, dass die Clock nicht das Problem ist

Das dort "an anderer Stelle" zu suchende Problem ist also dieses hier mit der I2C-Kommunikation?

Ja genau. Ich dachte ich hätte das Problem identifiziert mit der scheinbar fehlerhaften Clock und wollte deswegen dieses Problem beheben mit besagtem Thread. Das zugrundeliegende Symptom war aber schon die ganze Zeit der NACK den ich über I2C beobachtet habe. Daher jetzt dieser breiter aufgestellte Thread.

Mir ist nicht ganz klar wie ich die Adressen 0x80 bis 0xFF durchprobieren soll, denn die Adresse hat ja nur 7 bit, wie ich schon korrigiert wurde. Wenn ich die 8 bit inklusive R/W nehme um die Adressen 0x80 bis 0xFF zu probieren erhalte ich auch nur NACK.

Welchen Teil meines Sourcecodes möchtest du denn gern sehen bzw. was möchtest du daraus lesen? Der Code ist wirklich ein ziemliches Schlachtfeld, da ich mich mit embedded C wirklich nicht gut auskenne und auch ein anderes viel komplexeres Projekt zweckentfremdet habe.

Hans W. schrieb:

Da die Adresse in den oberen 7 Bit des ersten Byte steckt, hat das erste Byte den Wert 0x54. Aber nur beim Lesen. Bei Schreibzugriffen hat das erste Byte den Wert 0x55.

Falsch? 0x54 = Schreiben, 0x55 = Lesen. Jedenfalls steht im Datenblatt R-notW.

Ich verstehe nur nicht, warum man über so ein Thema groß diskutieren, einen LA bemühen oder über Signalgüte nachgrübeln muss. Man kann doch in wenigen Sekunden alle Möglichkeiten für das zu sendende Byte ausprobieren. Erst wenn das nicht zum Erfolg führt, sind andere Überlegungen sinnvoll.

Jonatan schrieb:

Mir ist nicht ganz klar wie ich die Adressen 0x80 bis 0xFF durchprobieren soll, denn die Adresse hat ja nur 7 bit, wie ich schon korrigiert wurde. Wenn ich die 8 bit inklusive R/W nehme um die Adressen 0x80 bis 0xFF zu probieren erhalte ich auch nur NACK.

Das hängt ja davon ab wie das im Sourcecode realisiert ist. Genau darauf kommt es an wenn man von I2C-Adressen spricht.

Deswegen möchte "man" gerne sehen wie das bei dir ist. Ist denn bei deinem Controller SDA und SCL auf Open-Drain gesetzt? Alles Unwägbarkeiten da keiner sieht was du wirklich machst.

Nun gut, dann versuch ich mal die relevanten Teile meines Sourcecodes zu präsentieren:

Beim S32k gibt es ein MasterTransmitDataRegistry (MTDR) in welches man bis zu 4 * 10 Bit schreiben kann, die dann nach dem First in First Out Prinzip vom I2C Treiber des Chips in I2C gewandelt und gesendet werden.

Da ich ja aktuell erstmal nur ein erstes ACK erzwingen möchte, schicke ich aktuell nur den Befehl zum schreiben (also die ersten 3 bit als 0x4) und dann die Slave-Adresse an die ich gern schreiben würde (also 0x2A). Da mir, wenn ich das richtig verstanden habe, empfohlen wurde die Adresse um 1 zu shiften um das R/W Bit nicht zu beschreiben, tue ich das auch noch.

Ergibt also folgenden Code:

1

MTDR = (0x4<<8)|(0x2A<<1);

Dieser Code wird ausgeführt, nachdem ich die Clocks und den LPI2C des Mikrocontroller initalisiert habe.

Die Clock wird wie folgt initalisiert, wobei ich hier nur den vorgeschrieben Code benutze, der mit diesem Mikrocontroller schon gelaufen ist.

1

void clock_init(void) {

2

3

    //Setup crystal oscillator

4

    SCG->SOSCDIV = SCG_SOSCDIV_SOSCDIV1(1) | SCG_SOSCDIV_SOSCDIV2(1); //SOSCDIV1 = 1, SOSCDIV2 = 1

5

    SCG->SOSCCFG = SCG_SOSCCFG_RANGE(3) | SCG_SOSCCFG_EREFS(1); //High frequency range external crystal

6

    while(SCG->SOSCCSR & SCG_SOSCCSR_LK_MASK); //Ensure SOSCCSR is unlocked

7

    SCG->SOSCCSR = SCG_SOSCCSR_SOSCEN(1);    //Enable oscillator

8

    while(!(SCG->SOSCCSR & SCG_SOSCCSR_SOSCVLD_MASK));  //Wait for the clock to be valid

9

10

    //Setup PLL

11

    while(SCG->SPLLCSR & SCG_SPLLCSR_LK_MASK); //Wait for register to be written

12

    SCG->SPLLCSR &= ~SCG_SPLLCSR_SPLLEN_MASK;  //Disable PLL

13

14

    SCG->SPLLDIV |=   SCG_SPLLDIV_SPLLDIV1(2) | //SPLLDIV1 divide by 2

15

                      SCG_SPLLDIV_SPLLDIV2(4);  // SPLLDIV2 divide by 8

16

17

    SCG->SPLLCFG = SCG_SPLLCFG_MULT(24); //SPLL_CLK = ((8 MHz / 1) * 40) / 2 = 160 MHz

18

19

    SCG->SPLLCSR |= SCG_SPLLCSR_SPLLEN_MASK; //Enable PLL

20

    while(!(SCG->SPLLCSR & SCG_SPLLCSR_SPLLVLD_MASK)); //Wait for PLL to be valid

21

22

    SCG->SIRCDIV = SCG_SIRCDIV_SIRCDIV1(1) | SCG_SIRCDIV_SIRCDIV2(1);

23

24

    //Normal run mode (80 MHz)

25

    SCG->RCCR = SCG_RCCR_SCS(6) | SCG_RCCR_DIVCORE(1) | SCG_RCCR_DIVBUS(1) | SCG_RCCR_DIVSLOW(2);

26

27

    while (((SCG->CSR & SCG_CSR_SCS_MASK) >> SCG_CSR_SCS_SHIFT ) != 6); //Wait for clock source = SPLL

28

29

    SystemCoreClockUpdate();

30

}

Dann wird noch LPI2C initalisiert mit den entsprechenden Clockzyklen um auf eine Geschwindigkeit von 100kHz zu kommen:

1

void LPI2C_init(void)

2

{

3

    PCC->PCCn[PCC_LPI2C0_INDEX] |= PCC_PCCn_PCS(2)        /* Clk src: SIRCDIV2_CLK */

4

                                | PCC_PCCn_CGC_MASK;       /* Enable clock for LPI2C0 */

5

6

7

    LPI2C0->MCFGR1 =   LPI2C_MCFGR1_PRESCALE(2)    /* Prescale = 4*/

8

                       |LPI2C_MCFGR1_IGNACK_MASK;    /* Ignore NACK*/

9

10

  /* SCL_freq = Input_freq / (2^PRESCALER * (CLKLO + CLKHI + 2))*/

11

12

    LPI2C0->MCCR0 = LPI2C_MCCR0_CLKLO(12)

13

                | LPI2C_MCCR0_CLKHI(6)

14

                | LPI2C_MCCR0_SETHOLD(6)

15

                | LPI2C_MCCR0_DATAVD(3);

16

17

18

19

    LPI2C0->MFCR = LPI2C_MFCR_TXWATER(0)  /* Transmitter Water mark set to 0*/

20

                  |LPI2C_MFCR_RXWATER(3);  /* Receiver Water mark set to 3*/

21

22

    LPI2C0->MCR |= LPI2C_MCR_MEN_MASK /* Enable LPI2C as master */

23

            | LPI2C_MCR_DBGEN_MASK;

24

25

}

Ich bin mir nicht sicher, ob du das wolltest, aber das ist im Prinzip der relevante Code, der für I2C zuständig ist.

Wie der S32 dann weiter mit den Informationen im MTDR umgeht, weiß ich nicht. Ich beobachte nur, dass die Informationen dann gesendet werden.

Jonatan schrieb:

Ich bin mir nicht sicher, ob du das wolltest, aber das ist im Prinzip der relevante Code, der für I2C zuständig ist.

In deinem Kauderwelsch ist wieder kein einziger Hinweis zu erkennen wie du mit den I2C-Adressen umgehst. Schon die Tatsache dass du nicht verstehst was hier gemeint bzw. verlang ist lässt darauf schliessen dass du sehr wenig verstehst.

Dass die Hardware im Prinzip funktioniert haben wir an deinem Analyzer Bild gesehen.

Moin,

Jonatan schrieb:

Ich habe auch mit dem Oszi die Flanken überprüft, die sind nicht optimal aber im Toleranzbereich des LDC.

Bloss nicht herzeigen, die sind streng geheim. Wenn du deinen Loetkuensten am Sensorchip nicht so recht vertraust, kannste ja mal mit Tuedeldraht irgendein anderes, moeglichst popeliges I2C-Device (Irgendein Temperatursensor oder ein kleines Flash)drantuedeln und gucken, ob du mit dem dann I2Cmaessig ueber deine Software quaken kannst...

Gruss WK

Dergute W. schrieb:

Moin,

Jonatan schrieb:

Ich habe auch mit dem Oszi die Flanken überprüft, die sind nicht optimal aber im Toleranzbereich des LDC.

Bloss nicht herzeigen, die sind streng geheim.

Ich werde ein Bild davon machen, sobald unser Oszi wieder frei ist. Ich muss auch erst einen USB stick auftreiben, sonst wird wieder gemault das ich kein Screenshot vom Oszi mache ;)

Wenn du deinen Loetkuensten am Sensorchip nicht so recht vertraust, kannste ja mal mit Tuedeldraht irgendein anderes, moeglichst popeliges I2C-Device (Irgendein Temperatursensor oder ein kleines Flash)drantuedeln und gucken, ob du mit dem dann I2Cmaessig ueber deine Software quaken kannst...

Das ist eine sehr gute Idee, das werde ich gleich mal probieren!

Da mir, wenn ich das richtig verstanden habe, empfohlen wurde die Adresse um 1 zu shiften um das R/W Bit nicht zu beschreiben

Geht nicht: Du kannst gar keine 7 Bit in das MTDR schreiben, man kann in die Register des Controllers nur Vielfache von 8 Bit schreiben. Dein Code beschreibt das Bit 0 immer (egal ob mit oder ohne Shift), nämlich mit null.

Und da haben wir nun den Punkt: Die anderen Poster haben an Daten auf dem I2C-Bus gedacht. Nun verrätst du aber erstmals, dass du gar nicht auf den I2C-Bus schreibst, sondern in Controller-Register. Was letztendlich auf dem I2C-Bus passiert, bestimmt der Controller. Ich bin ziemlich sicher, dass der sich selbst um das R/W-Bit und den ganzen Rest kümmert, dafür hat er ja die CMD-Bits. Jedenfalls sehe ich beim schnellen Überfliegen des Datenblatts null Komma nichts von dem R/W-Bit und für die Adresse heißt es immer nur "address byte" (was ohne gegenteilige Erklärung bedeutet, das die Adresse in Bit 0 bis 6 liegt und Bit 7 null sein muss.)

Rolf schrieb:

Da mir, wenn ich das richtig verstanden habe, empfohlen wurde die Adresse um 1 zu shiften um das R/W Bit nicht zu beschreiben

Geht nicht: Du kannst gar keine 7 Bit in das MTDR schreiben, man kann in die Register des Controllers nur Vielfache von 8 Bit schreiben. Dein Code beschreibt das Bit 0 immer (egal ob mit oder ohne Shift), nämlich mit null.

Das stimmt, daran habe ich nicht gedacht.

Wie dem auch sei, ich kann freudig berichten, dass ich nach dem fix mit der geshifteten Adresse nun einen Profi den Chip habe auflöten lassen und es jetzt funktioniert, ich bekomme ein ACK!

Scheinbar war eine Kombination von vorherigen Fehlern in Kombination mit einem schlechten auflöten des Chips Ursache des Problems.

Damit hat sich das Problem gelöst, danke für die Hilfe!

Lg, Jonatan

Wastl schrieb:

Kann man aus seinem Schaltplan entnehmen.

Stimmt - jetzt wo du das sagst, sehe ich, dass der TO den auch irgendwo im Verlauf des Threads angehängt hat. Also wird sich der Sensor wohl auf der I2C Adresse 0x2A angesprochen fühlen.

Rolf schrieb:

Man kann doch in wenigen Sekunden alle Möglichkeiten für das zu sendende Byte ausprobieren.

Nichts anderes macht ein I2C-Scanner. Allerdings wird der für 127 mögliche Adressen nicht mehrere Sekunden brauchen ;-)

Wastl schrieb:

Dann würde ich doch mal die Adressen 0x80 bis 0xFF durchprobieren.

I2C-Adressen 0x80 bis 0xFF gibt es nach I2C-Spezifikation und nach Auffassung von TI nicht. Außerdem sagt der Logikanalysator doch eindeutig, was der Master als erstes Byte auf den Bus legt, so dass sich jede Diskussion und Glaskugelleserei darüber erübrigt.

Wastl schrieb:

Dass die Hardware im Prinzip funktioniert haben wir an deinem Analyzer Bild gesehen.

Falscher Schluss - offensichtlich hat nur der Master die richtigen Signale auf den Bus gelegt und es LAG es an der Hardware, genauer an der Löterei. Für das Verständnis wäre es natürlich förderlich zu wissen, welcher Pin verhindert hat, dass der Slave ordnungsgemäß arbeitet.

Dass die Hardware im Prinzip funktioniert haben wir an deinem Analyzer Bild gesehen.

Falscher Schluss - offensichtlich hat nur der Master die richtigen Signale auf den Bus gelegt und es LAG es an der Hardware, genauer an der Löterei.

Yup.

Für das Verständnis wäre es natürlich förderlich zu wissen, welcher Pin verhindert hat, dass der Slave ordnungsgemäß arbeitet.

Welcher Pin ist wurscht, man kann hier nur eine Aussage über den Slave an sich machen. Und die Gehäusezeichnung sieht arg nach "keine Pins sondern lediglich Pads an der Unterseite" aus: WSON-12 ... "Small Outline No Lead (SON)" (siehe Anhang). Pin-abstand: 1.27 mm. Also reflow-löten, Heissluft von oben; board von unten heizen könnte helfen, ist aber IMHO bei dem kleinen Fliegendreck eher verzichtbar.

Wenn der Master wie der LA sagt korrekt sendet, aber keinerlei Antwort vom Slave kommt, dann zeigt das lediglich das der Slave als Kommunikationspartner nicht vorhanden ist. Kann sein das SDA nicht korrekt verbunden ist, oder SCL. Oder der Slave nicht korrekt gepowert wird oder im Reset festhängt.

Da kann man versuchen direkt mit spitzen Messspitzen durchzuklingeln, falls vorhanden JTAG-Boundary-scan nutzen, die Stromaufnahme zu beobachten, mal den Chip runterlöten und schauen, ob sich was vom Verhalten ändert etc. pp..

Bradward B. schrieb:

Dass die Hardware im Prinzip funktioniert haben wir an deinem ...

Es nervt, dass du es dir nicht abgewöhnen kannst, als Einziger (?) hier die von der Forensoftware erzeugte Quellenangabe (Autorennick und Link auf den betreffenden Beitrag) zu unterschlagen.

Beim Zitieren gehört es sich, die Quelle anzugeben.

offtopic

Es nervt, dass du es dir nicht abgewöhnen kannst, als Einziger (?) hier die von der Forensoftware erzeugte Quellenangabe (Autorennick und Link auf den betreffenden Beitrag) zu unterschlagen.

„Gott, gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann, den Mut, Dinge zu ändern, die ich ändern kann, und die Weisheit, das eine vom anderen zu unterscheiden.“

Beim Zitieren gehört es sich, die Quelle anzugeben.

Mumpitz, die Wiedergabe einer zeitlich vorhergehenden Aussage ist lediglich eine Brücke im Gedankenfluß. Schau dir bspw. die erste "Lebenshälfte" dieses Forums ans oder die Wikipedia an, da wird nicht der Lese-fluß durch komplett unnötiges "Auch Hinz und Kunz hat dazu einen rausgeknallt ..." unterbrochen.

offtopic off

Bradward B. schrieb:

Schau dir bspw. die erste "Lebenshälfte" dieses Forums ans oder die Wikipedia an, da wird nicht der Lese-fluß durch komplett unnötiges "Auch Hinz und Kunz hat dazu einen rausgeknallt ..." unterbrochen.

Schau dir die erste Lebenshälfte der Menscheit an. Da haben wir Felle toter Tiere um uns gewickelt, haben in Höhlen gehaust und sind mit 30 Jahren gestorben. Dann haben wir uns weiterentwickelt. Und was die Weiterentwicklung angeht müsste man von einem, der sich einen Nick aus einer Raumfahrtserie angeeignet hat, doch einiges erwarten können. Aber vermutlich ist dessen Raumschiff mit dem Faustkeil geschnitzt worden.

Schau dir bspw. ... die Wikipedia an

Nicht alles, was hinkt, ist ein Vergleich. Im Wikipedia könnte z.B. jeder beliebige andere User deinen Kommentaren die fehlenden Links hinzufügen.

Rainer W. schrieb:

Es nervt, dass du es dir nicht abgewöhnen kannst, als Einziger (?) hier die von der Forensoftware erzeugte Quellenangabe (Autorennick und Link auf den betreffenden Beitrag) zu unterschlagen.

Es gibt noch mindestens einen ähnlich hartnäckig ignoranten User. Lustigerweise kann der Lieutenant Junior Grade die Zitatfunktion verwenden, wenn es in seinem Interesse ist, wie der Beitrag "Re: [V] Bei Kleinanzeigen gefunden: Oszilloskop Hameg 312 für 20 EUR" zeigt. In diesem Thread findet man dann auch noch den anderen zitatmäßig faustkeilschwingenden Höhlenbewohner.

[/ot]

Schau dir die erste Lebenshälfte der Menscheit an. Da haben wir Felle toter Tiere um uns gewickelt, haben in Höhlen gehaust und sind mit 30 Jahren gestorben. Dann haben wir uns weiterentwickelt. Und was die Weiterentwicklung angeht müsste man von einem, der sich einen Nick aus einer Raumfahrtserie angeeignet hat, doch einiges erwarten können. Aber vermutlich ist dessen Raumschiff mit dem Faustkeil geschnitzt worden.

Schau dir bspw. ... die Wikipedia an

Nicht alles, was hinkt, ist ein Vergleich.

Ja eben.

Es geht hier nicht um das Verfassen einer Dissertation nach den Vorgaben einer Prüfungskommision, es geht hier um die Wiedergabe eine persönlichen Aussage eines freien Autors. Und wenn der das Herumgereite auf der inflationäre Wiedergabe von Nicknames in den allermeisten Fällen als unnötig und sogar störend empfindet ist das eben so. Als Konsequenz folgt daraus das Weglassens des unnötigen Zierates.

Hogwh!

PS: Over and out (Ihr findet sicher einen anderen, der Euch geduldig erklärt wie man Bauteile mit "No lead package) elektrisch fehlerfrei bestückt. (falls daran überhaupt Interesse besteht))

Bradward B. schrieb:

Und wenn der das Herumgereite auf der inflationäre Wiedergabe von Nicknames in den allermeisten Fällen als unnötig und sogar störend empfindet ist das eben so.

Du hast immer noch nicht verstanden, dass es sich eben nicht nur um die "inflationäre Wiedergabe von Nicknames" handelt, sondern auch um einen Link auf die Quelle (Ort in Form der URL und damit auch Kontext) des zitierten Beitrags.

==================================== Ich untersage dir hiermit ausdrücklich, in diesem Forum Beiträge von mir oder Teile daraus ohne Quellenangabe im Sinne des Forums (Nickname mit Link zum Originalbeitrag) in deine Beiträge zu übernehmen.

ES REICHT