Manchmal will man wissen, was auf dem I2C Bus eigentlich los ist.
Anbei ein einfacher I2C-Sniffer.
Benutzt wird ein ATtiny85.

Die Ausgabe erfolgt als Text über die UART mit 255 Byte FIFO. Nach jedem
Stop erfolgt ein Zeilenvorschub.

Die ATmega kann man nicht benutzen, da die nicht passiv mitlauschen und
auch nur eine einzige Adresse erkennen können.
Es muß daher schon ein AVR mit USI sein und das können nur die ATTiny.


Peter

> Es muß daher schon ein AVR mit USI sein und das können nur die ATTiny.

Danke, dass du das schreibst. Ich dachte schon ich wäre nur zu blöd.

Hallo,

Vielen Dank für den Code.
Gibt es seitens der Geschwindigkeit des I2C-Bus irgendwelche
Einschränkungen?
Sind f(SCL)=400Khz möglich?

MfG Hias

hi,

0..100kBit/s LowSpeed  (veraltet)
 ..400kBit/s FastSpeed (üblich)
 ..3,3MBit/s HighSpeed (selten)

Falls das für einen Sniffer zu schnell ist:
Der Sniffer könnte auch problemlos durch "Clock-Sync" (siehe I2C Spec)
den Bus-Master bis auf 0Bit/s "runterbremsen".
Dazu hält der Sniffer einfach SCL solange auf 0 (Low)
wie er es gerade braucht, der Master muss solange warten.
(wenn das denn korrekt implementiert ist...)

gruß, sniffy

Für das USI sind auch 1MHz keine Problem.

Der Flaschenhals ist aber die UART. Wenn der Puffer voll ist, wird SCL
durch das USI auf low gehalten, bis das nächste Byte gesendet werden
kann.

Man könnte den Puffer noch auf ~480 Byte erhöhen. Auf nem I2C wird ja
nie ständig übertragen, die MCs sollen ja auch noch was anderes machen.

Man kann auch den Attiny2313 nehmen. Der hat zwar weniger SRAM aber eine
HW-UART und dann kann man mit 921,6kBaud senden.
Damit sind selbst dauerhafte 400kHz I2C ungebremst.

Ich hatte grad keinen ATtiny2313 da.
Und mit den ATtiny85 kann man den kompletten Sniffer im D-Sub9 Gehäuse
unterbringen.


Peter

Hallo Peter,

vielen Dank für den Code, der kommt mir gerade recht ;-) Auch wenn er
wieder so ausgefuchst ist, das man sämtliche Datenblätter braucht um das
halbwegs nachzuvollziehen... g

Ich habe ihn heute mal ausprobiert und leider ein paar kleine
Problemchen mit der Terminalausgabe. Komischerweise werden einzelne
Character immer wieder mal falsch angezeigt. Eine Gegenprobe mit dem
LogicPort zeigt aber, das der Tiny85 mit 115200 Baud die korrekten Werte
sendet. Jedenfalls kann der Logicport die Werte richtig interpretieren.

Das passiert auch bei kleineren Sequenzen. Welche Terminalemulation
benutzt Du? Bei mir gibt es die Fehler sowohl mit Hyperterm als auch mit
Bray, Superterm und auch HTerm. Einzig das in CodeVision eingebaute
Terminal funktioniert einigermaßen. Oder ist nur mein Rechner zu
langsam?

Im Anhang der Screenshot.

Um längere Sequenzen zu sniffen wird es sich wohl lohnen auf einen
Tiny861 zu portieren, oder meinst Du das ist Overkill?

Vielen Dank für einen Tipp.

Grüße,
Klaus

Klaus Leidinger wrote:

> Das passiert auch bei kleineren Sequenzen. Welche Terminalemulation
> benutzt Du? Bei mir gibt es die Fehler sowohl mit Hyperterm als auch mit
> Bray, Superterm und auch HTerm.

Ich hatte mit Hyperterm auch öfters falsche Anzeigen. Wenn man aber in
eine Datei gelesen hat, klappte es. Mit HTerm hatte ich keine Probleme.


> Um längere Sequenzen zu sniffen wird es sich wohl lohnen auf einen
> Tiny861 zu portieren, oder meinst Du das ist Overkill?

Wozu?
Der hat doch auch nur 512 Byte SRAM.

Ich hatte aber den ATtiny84 überlegt, um ein paar Triggerausgänge bei
bestimmten Datenpaketen zu erzeugen.


Peter

Peter Dannegger wrote:

> Ich hatte mit Hyperterm auch öfters falsche Anzeigen. Wenn man aber in
> eine Datei gelesen hat, klappte es. Mit HTerm hatte ich keine Probleme.

OK, danke für Deine Info, hat wohl schon etwas mit der Emulation zu tun.
Komische Sache.

>> Um längere Sequenzen zu sniffen wird es sich wohl lohnen auf einen
>> Tiny861 zu portieren, oder meinst Du das ist Overkill?
>
> Wozu?
> Der hat doch auch nur 512 Byte SRAM.

Ja, da hast Du Recht, der USART kann dort ja nicht gleichzeitig mit dem
USI Interface benutzt werden. Das scheint nur beim Tiny2313 zu gehen. Da
habe ich die Featureübersicht von Atmel falsch interpretiert.

Danke!
Klaus

So, ich hab den Sniffer nochmal gepimt.

Er hat jetzt 501 Byte Sendepuffer und kann max 460800 Baud.
Dafür mußte er in Assembler geschrieben werden (126 Words groß).

Keiner meiner PCs kann 460800 Baud, nur die USB-RS232 Konverter können
es.
Allerding macht einer von den 3 Stück (verschiedene Typen) ab etwa 2kB
Dauerbefeuerung schlapp.

Die Snifferroutine ist die gleiche, wie im C-Code, nur auf Assembler
umgeschrieben.

Die UART-FIFO ist auf Registervariablen (schneller) und Pointer (wegen
FIFO>256) umgeschrieben.
Durch die Registervariablen ist ein atomarer Word-Zugriff möglich und es
muß in putchar keine Interruptsperre erfolgen.

Der Bit-Interrupthandler dauert mit Call und RETI max 23 Zyklen, also
kann eine Interruptrate von 32 Zyklen eingestellt werden:

14,7456MHz / 32 = 460800 Baud


Peter


P.S.:
Ich hab mir mal auf dem STK500 mit dem Oszi die 460800 Baud angesehen.
In den RS232 Treiber geht schönes Rechteck rein und hinten kommt nur
Dreieck raus.

Peter Dannegger wrote:

> P.S.:
> Ich hab mir mal auf dem STK500 mit dem Oszi die 460800 Baud angesehen.
> In den RS232 Treiber geht schönes Rechteck rein und hinten kommt nur
> Dreieck raus.

Der MAX232 ist für 115-125kBaud spezifiziert und hat eine Slewrate von
3V/µs.

Hallo Peter,
Peter Dannegger wrote:
> So, ich hab den Sniffer nochmal gepimt.
>
> Er hat jetzt 501 Byte Sendepuffer und kann max 460800 Baud.
> Dafür mußte er in Assembler geschrieben werden (126 Words groß).

Na endlich mal ein anschauliches Beispiel für die Diskussion: ...für
zeitkritische Anwendungen Assembler nehmen, braucht weniger
Ressourcen...
Doppelt so viel Ram zur Verfügung und 4 fache Geschwindigkeit möglich.

Super Sache!
Der Logicport dekodiert die 460800 Baud jedenfalls einwandfrei,
ebenso ein Tiny2313 (direkt verbunden) der die Daten auf ein LCD
ausgibt.

Im Unterschied zur ungepimpten C Version zeigt mein Display hier auch
keine Übertragungsfehler an. (Ich hatte eher mein LCD Terminal in
Verdacht, das das zu langsam ist)
Möglicherweise hatte die alte Version doch ein paar Jitter im seriellen
Takt. PC kann ich mangels geeignetem Übertrager nicht testen.

Nochmal vielen Dank für den Code, jetzt muß ich nur meinem LCD noch
einen Empfangspuffer einbauen, damit nichts verlorengeht.

Viele Grüße,
Klaus

Klaus Leidinger wrote:

> Möglicherweise hatte die alte Version doch ein paar Jitter im seriellen
> Takt.

Ja, da kannst Du recht haben. Könnte mit der Interruptsperre
zusammenhängen, daß die Freigabe zu ner ungünstigen Zeit kommt.
Im Assemblerprogramm läuft der Interrupthandler durch, auch wenn nichts
zu senden ist.


Peter

@peter

ohne es nachgebaut zu haben, hast du wiedermal ein supergeiles
nützliches projekt/artikel von dir gegeben. weiter so !!
werde das teil sicher brauchen und bau es mir bei gelegenheit nachbauen
(kann nicht lange dauern :-)))
finds echt genial wie codesparend zu deine ideen/projekte so
implementierst.
wie lange programmierst du schon ? seit 20, 30 oder mehr jahren ? :-)
steckt jedenfalls eine menge erfahung in deinen artikeln/codeschnipseln.
allein dein faible für xor spricht schon bände :-))

gruß
rene

Peter hat sicher sehr lange Erfahrung mit seiner Programmierung, aber
während er das letzte Byte aus dem Code quetscht habe andere das 3.
Projekt auf dem Markt. Die Effizienz will heute keiner mehr wissen, weil
Zeit Geld ist und die Controller biller sind als der ganze Aufwand an
der ganzen Codequtscherei. Man kann es auch übertreiben.

>Die Effizienz will heute keiner mehr wissen, weil
>Zeit Geld ist und die Controller biller sind als der ganze Aufwand an
>der ganzen Codequtscherei. Man kann es auch übertreiben.

Sehe ich so nicht. Besonders wo die Recourcen begrenzt sind.
Es hat halt nicht jeder einen Pentium dahinter..

@matthias

sehe ich genauso.
effizienz ist vielleicht nicht mehr sooo marktfähig (zumindest nicht auf
dem pc, sonst hätten diese wahrscheinlich das 100fache an
funktionen/leistung/performance).
aber gerade im mikrocontroller bereich möchte man (bzw. die meist
unwissenden vertriebler) immer mehr mit immer weniger ressourcen
realisieren.
sieht man ja an den switchen bzw. routern bzw. sonstigen gimmicks aus
dem consumerbereich. die dinger sollen immer weniger kosten (größe des
mikrocontrollers bzw. des systems) und immer mehr können.

@sucher

>während er das letzte Byte aus dem Code quetscht habe andere das 3.
>Projekt auf dem Markt.

stimmt nicht ganz. mit dem erfahrungsschatz erkennt man
optimierungsmöglichkeiten viel viel schneller, bzw programmiert
effizienter.
deswegen haben firmen die alle paar jahre ihr personal (bis auf die
geschäftsführer und vertriebler) auswechseln eher probleme als
diejenigen die auf erfahrenes "personal" zurückgreifen können und
"ersetzbarere" leute austauschen statt ihr know-how zu vergraulen.

Hallo Forum,
auf dem Gebiet der AVR bin ich ganz neu, und beginne jetzt mit den
ersten
Gehversuchen.
Als Einstieg wollte ich den I²C Sniffer nachbauen.
Die HW ist kein Problem, die Pinbelegung für Data, Clock und TXD hab ich
aus dem ASM File...

Was ich mir nicht erklären konnte, ist die Einstellung der Fuse.
Kann mir da mal wer auf die Sprünge helfen??
Was mache ich mit "Divide clock by 8 internally" ???


vielen Dank
ein AVR Nixkönner

Hast Du die Fusebeschreibung mal übersetzt?
Möchtest Du einen langsameren Takt als mit dem Baudratenquerz?
Nein? Dann den Haken wegmachen.

HTH,
Klaus

> Hast Du die Fusebeschreibung mal übersetzt?
> Möchtest Du einen langsameren Takt als mit dem Baudratenquerz?
> Nein? Dann den Haken wegmachen.

Hallo Klaus,
da liegt mein Problem! Woher weis ich, ob der Teiler für das Programm
vom Peter aktiv sein muss, oder nicht?? :-)

Vielen Dank
ein AVR Nixkönner...

Genau wie die Pinbelegung auch aus dem asm File:
.equ  XTAL    = 14745600
und um sicherzugehen noch in die UART.INC schauen, ob da was von /8
drinsteht
init_uart:
  ldi  a0, XTAL / BAUD - 1

Und dann zur Sicherheit noch überlegen:
das Programm ist extra als asm geschrieben worden, damit es möglichst
schnell abgearbeitet werden kann. Warum sollte man(n) sich nach dieser
Mühe den Takt achteln?

OK, nicht jede Software die man im Netz findet hat alle relevanten
Informationen im Sourcefile, und es ist klar das das eine oder andere
für einen Einsteiger eine Hürde ist, die spätestens beim dritten Projekt
nicht mehr besteht. Notfalls macht auch ein Versuch kluch ;-)

HTH,
Klaus

AVR Nixkönner wrote:
> Hallo Klaus,
> da liegt mein Problem! Woher weis ich, ob der Teiler für das Programm
> vom Peter aktiv sein muss, oder nicht?? :-)

Üblicher Weise findet man in Programmen solche Definitionen wie "F_CPU"
oder "XTAL".
Damit wollen die Programmierer den Arbeitstakt definieren, um dann im
Programm Baudraten, Delays usw. automatisch berechnen zu lassen.

Ob man diesen Arbeitstakt nun mit oder ohne Vorteiler einstellt, ist
dabei wurscht.
14,7456MHz dürften aber nur ohne Vorteiler erreichbar sein.


Peter

Danke für die Antworten...

Wenn ich die Argumente so höre, hätte ich auch selbst drauf kommen
können! Ich habe was dazu gelernt :-)

ein AVR Nixkönner

AVR Nixkönner wrote:

> .... Ich habe was dazu gelernt :-)
Super, das war der Sinn der Sache.

> ein AVR Nixkönner
Deinen Nicknamen kannst Du dann auch gleich ändern ;-)

Klaus

sucher wrote:
> Peter hat sicher sehr lange Erfahrung mit seiner Programmierung, aber
> während er das letzte Byte aus dem Code quetscht habe andere das 3.
> Projekt auf dem Markt.

Ich sehe nicht, wo ich da was gequetscht hätte.
Ich habs nur auf Assembler umgeschrieben und das ging schneller, als das
C-Programm zu entwickeln.


> Die Effizienz will heute keiner mehr wissen, weil
> Zeit Geld ist und die Controller biller sind als der ganze Aufwand an
> der ganzen Codequtscherei. Man kann es auch übertreiben.

Bloß die Effizienz ist es nicht allein. Das Durchdenken eines Problems
gibt daneben auch kürzeren, fehlerfreieren und besser wartbaren Code.

Die Zeit, die man zu Beginn des Projekts durch schludrigen Spaghetticode
vermeintlich spart, gibt man später bei der Wartung, Fehlerbehebung,
Erweiterung und Nachnutzung 100-fach wieder zu.

Als Beispiel möchte ich mal meinen Tastenentprellcode nehmen. Nach
dessen Entwicklung habe ich nie wieder eine Sekunde mit Tastenproblemen
vergeudet, der Code wird reingepappt und läuft.

Ich versuche immer, der Lesbarkeit den absoluten Vorrang zu geben.
Denn das zahlt sich am meisten aus, wenn man weiter programmieren will.

Ein Code muß nicht nur funktionieren, sondern auch gut aussehen.
Denn dann ist es sicherer, daß er nicht nur vermeintlich "funktioniert".

Daß durchdachter und modularer Code oft auch schneller und kleiner ist,
ist nur ein schöner Nebeneffekt.


Peter

ja Peter, man sollte nicht immer den Controller im Hintergrund haben und
alles was geht in Software implementieren. Diesen I2C-Schnüffler habe
ich schon vor Jahren mit nur 4 TTL-IC's und natürlich einen Controller
deiner Wahl gebaut. Die 4 TTL-IC's kosten weniger als 0,50 EUR und bei
dem Controller kann man nehmen was man will, da man auch nur die RS232
und ein bischen Port braucht. Die Geschwindigkeit für den I2C-Schnüffler
geht natürlich erheblich höher als bei Deiner Variante. Die heutige Norm
bis über 1MHz ist also ohne Probleme möglich. Das ganze geht auch nur in
einen PLD. Das ist für mich Effizienz.

sucher wrote:
> ja Peter, man sollte nicht immer den Controller im Hintergrund haben und
> alles was geht in Software implementieren.

Warum denn nicht?
Was ist falsch daran?

Wann immer ich 2 TTLs durch einen MC ersetzen kann, dann mache ich das
auch.
Ein paar Zeilen getippt ist viel einfacher und schneller als ne Platine
layoutet und gefertigt.


> Diesen I2C-Schnüffler habe
> ich schon vor Jahren mit nur 4 TTL-IC's und natürlich einen Controller
> deiner Wahl gebaut. Die 4 TTL-IC's kosten weniger als 0,50 EUR und bei
> dem Controller kann man nehmen was man will, da man auch nur die RS232
> und ein bischen Port braucht.

Das sind ja mindestens schon 5 Chips und die passen dann nicht mehr in
ein D-Sub9 Gehäuse.
Ich mag 1-Chip Lösungen, dann ist das Layout viel einfacher.
Mit 1,20€ ist der Attiny25 ja auch kein Kostenfaktor.


> Die Geschwindigkeit für den I2C-Schnüffler
> geht natürlich erheblich höher als bei Deiner Variante. Die heutige Norm
> bis über 1MHz ist also ohne Probleme möglich.

Lies doch erstmal, was ich geschrieben hatte.
Der Flaschenhals ist nicht das I2C, das kann bis 7MHz (XTAL/2), sondern
die UART.
Und mit dem größeren (20Pin) ATtiny2313 kann man die UART leicht auf
2,5MBaud setzen.


> Das ganze geht auch nur in
> einen PLD. Das ist für mich Effizienz.

PLDs sind schöne Stromfresser, schön groß und schön teuer, das ist für
mich Ineffizienz.


Peter

P.S.:
Ich hatte auch mal darüber nachgedacht, HW-I2C mit nem PLD zu
realisieren, aber es dann als zu aufwendig verworfen.

Der 22V10 kann ja gerademal das 9Bit-Schieberegister fassen dann isser
dicht. Es müßte also schon ein großer, teurer, stromfressender PLCC-44
Flatschen mit mindestens 32 Macrozellen sein.

Das Lesen des ATtiny Datenblattes hat dann aber den nötigen Kick
gebracht.
Ein ATtiny mit USI ist dafür einfach das Optimum bezogen auf
Geschwindigkeit, Entwicklungsaufwand, Aufbau und Preis.

Mit den 500 Byte Sendepuffer kann man ja mindestens 160 I2C-Byte ohne
Clock-Stretching bei >1MHz mitlesen.
Und bei vollem Puffer wird dann ein bischen abgebremst, verloren gehen
Daten aber auf keinem Fall.


Peter

Es gibt EPLD's ( mit PLD hatte ich mich verschrieben )die sehr wenig
Strom benötigen, aber das wird hier von wenig Interesse sein. Ich hatte
in dem EPLD noch die START, STOP, ACK und NACK - Erkennung eingebaut.
Der EPLD hat mich damals 0,30 EUR gekostet.
Im übrigen sind es bei Dir nicht nur 3 Zeilen.
Wenn Du es mit Deinem ATtiny besser machen kannst, ist das OK, aber
meine Version ist mit jedem billigen Prozessor machbar. Nicht jeder will
die AVR's.

@sucher

aber du musst zugeben das eine mehr-chip lösung aufwendiger ist als eine
ein-chip lösung (layout, pld-programm,uc-programm), oder ?
ich versteh nicht was es gegen diesen sniffer einzuwenden gibt. jede
mehrchip lösung ist anfälliger und aufwendiger als diese lösung. und die
idee das ganze in ein sub-d gehäuse unterzubringen ist genial (und wäre
bei einer mehrchip lösung auch nicht möglich).
also ich finds genial.

nun Peter ist ein Typ, der andere Design nicht gelten lässt. Das habe
ich in anderen Beiträgen schon mitbekommen.
Ich habe nichts gegen seine Lösung, wie ich aber schon geschrieben habe
gibt es nicht nur Entwickler, die AVR möchten.
Peter kann sich von mir aus einen DIE auf die Leiterplatte Bügeln, nur
um noch kleiner und viel viel besser als ander zu sein. Für mich ist
dieses Projekt zu einseitig und spricht einen kleinen Teil an. Mehr
wollte ich nicht schreiben.

sucher wrote:
> nun Peter ist ein Typ, der andere Design nicht gelten lässt.

Na aber hallo, umgekehrt wird ein Schuh draus.

Du hast doch gemeckert, daß man es nicht in Software machen soll.
Und auf die Frage warum, hast Du nur geschwiegen.

Du hast einfach ins blaue hinein behauptet, daß meine Version keinen
1MHz-I2C könnte, der AVR kann es aber.
Nicht jeder andere MC ist schnell genug, selbst mit TTL- oder
EPLD-Unterstützung.

Und Deine Variante hast Du auch nicht vorgestellt, also wie soll man
dann einschätzen, was sie kann oder nicht kann.


Dein einziges Argument ist, daß Du keine AVRs magst.
Das ist natürlich ein absolut stichhaltiges und objektives Argument. Vor
soviel Ignoranz kann man nur noch den Kopf schütteln.


Peter

meckern und Kritik ist ein Unterschied, den Du anscheinend nicht
bemerken kannst. Deine selbstherlliche Einstellung ist für mich einfach
zum kotzen. Ich habe über Dein Projekt nicht gemeckert, sondern nur
bemerkt, das es sehr einseitig ist. Ob ich nun AVR mag oder nicht spielt
hier keine Rolle. Du kannst Kritik nicht ab und das ist eine Tatsache.
Sonst kommt hier nur Lobhudelei und selbstherrliches gedudel. Bleibe bei
deinem gefriggel und Deiner 3 Zeilen Software, die Dich in Deinem Leben
noch so richtig weiter bringen wird.
Ich soll in Deinem Beitrag mein Projekt vorstellen. Nö, das ist Dein Tag
und Dein Projekt. Im übrigen gibt es mein Projekt schon seit Jahren im
Netz.
Wer zu spät kommt, den bestraft das Leben.

@Sucher:

Ich glaube Du hast echt Frust. Deine Satzkonstruktionen sind nicht mehr
sachlich. Da Du keinen Namen oder Link gepostet hat ist es schon nett
gewesen auf Deine Argumente versuchsweise einzugehen.

Mein Fazit:

Ich werde mir für meine Projekte nochmal genau überlegen ob ich sie
veröffentliche, wenn man solche Diskussionen führen muss und dann noch
unter anonymen Namen.

Gruß Sven

@sucher

nu komm mal runter ... peter ist ein sehr guter (bin geneigt genialer zu
sagen) programmierer und bin auch schon über einige seiner äußerungen
gestolpert (bei meinem parser z.b.). aber wenn sein code effizenter,
kleiner (vielleicht nicht immer einfacher zu verstehender, sage nur
^&?&^ ) und wartbarer ist kann man schon angeben und das tut peter nun
bei weitem nicht.
arrogant ist peter sicher nicht. er prahlt nicht damit das er alle
anderen programmierer in grund und boden coded oder ?!
profilierungsgehabe zeugt eher von arroganz und die könnte man dir bei
deinen äußerungen eher zusprechen -> gefriggel, sei stolz auf deine 3
zeilen, mein projekt schon seit jahren ...
pack dir bitte mal an deine eigene nase.
peter ist vllt nicht immer ganz einfach, aber wenn man von seiner sache
überzeugt ist und das sachlich darstellen kann ist doch ok, oder ?!
ich hab mich damit abgefunden das mein parser eben nur 2.wahl ist (und
das angesichts der alternativen vllt auch zu recht), aber dafür ist es
MEINER und das kann mir keiner nehmen. also, was soll das theater ?!
um mal eins draufzusetzen : wenn man schon mehr-chip lösungen
präsentiert dann solls sich auch lohnen : siehe das audio-projekt. da
ist nicht an 1-chip zu denken. aber es kann (soll können) auch
entsprechend mehr. motto : wenn schon aufwand, dann soll er sich auch
lohnen. 5 chips zu einem i2c sniffer zusammenzubraten kann jeder. das
ganze in 1 chip mit entsprechenden features und vor allem OFFEN, ist
schon geil.

Don't feed the trolls.

zu spät ... sry

sucher wrote:
> meckern und Kritik ist ein Unterschied, den Du anscheinend nicht
> bemerken kannst.

Doch kann ich. Kritik bezieht sich konkret auf die Sache.
Was Du aber machst, ist nur hohle Frasen dreschen:
> ja Peter, man sollte nicht immer den Controller im Hintergrund haben und
> alles was geht in Software implementieren.
Auf die Sache erfolgt nirgends ein Bezug.


> Deine selbstherlliche Einstellung ist für mich einfach
> zum kotzen.

Ich habe ein Projekt vorgestellt und etwas zu seiner Funktion gesagt.
Genau dazu ist ja die Codesammlung da.
Was ist denn daran selbstherrlich?


> Du kannst Kritik nicht ab und das ist eine Tatsache.

Ganz im Gegenteil, ich mag Kritik, nur so kann man lernen und dazu ist
ja die Codesammlung da.
Bitte kritisiere doch endlich mal mein Projekt (nicht irgendwelche
vermeintlichen persönlichen Eigenschaften, die Du mir zuschreibst).


> Sonst kommt hier nur Lobhudelei und selbstherrliches gedudel.

Daß anderen mein Projekt gefällt, werden diese doch wohl äußern dürfen,
das ist ein freies Land.


> Bleibe bei
> deinem gefriggel und Deiner 3 Zeilen Software

Wie kommst Du auf 3 Zeilen?
Schau doch endlich mal rein, das sind mehr als 3 Zeilen.
Deine TTLs sind bestimmt auch mit mehr als 3 Drähten verbunden.
Mit 3 Zeilen oder 3 Drähten kommt man nicht weit.


> Ich soll in Deinem Beitrag mein Projekt vorstellen.

Nö, ein Link reicht.
Auch dazu ist ja die Codesammlung da, daß man auf ähnliche Projekte
verweisen kann.


> Im übrigen gibt es mein Projekt schon seit Jahren im
> Netz.

Aha, wenn also einmal was entwickelt worden ist, dann ist es verboten,
es weiterzuentwickeln.
Auch ne verquere Einstellung, die ich nicht teilen mag.


> Wer zu spät kommt, den bestraft das Leben.

Das häufigste Zitat, wenn einem nichts zur Sache einfällt.
Ich mag solche leeren Worthülsen nicht.


Peter

@peter

Lass dich nicht ärgern!

ich finde den sniffer 1a und selbst 1 mhz schaft er ein einem gerät
mitzulesen ohne probleme!
zudem muß ich als sonst nur Bascom anwender sagen das man deinen code
sehr gut lesen ,umsetzen und verstehen kann und das ist viel wichtiger
als programiergeschwindigkeit bei der erstellung. benutze immer wieder
gerne codeschnipsel von dir für eigene projekte.

Deshalb einfach

DANKE

sven

das ist doch erstaunlich. Man setzt den Leuten fertigen Quellcode
kostenlos vor und es finden sich trotzdem einpaar, die rummeckern. Das
beste noch, der "Spender" muss sich auch noch rechtfertigen. Da kann ich
nur sagen, wenn ihr heiße Luft ablassen wollt und nichts Konstruktives
vorzutragen habt, dann machts doch in einem anderen Forum.

@andi:

du solltest mal sehr sehr sehr aufmerksam lesen, was ich kritisiert
habe. Der Quellcode von unseren Sonnenschein Herrn Dannegger geht mir
sowas von vorbei. Ich habe daran absolut kein Interesse. Ich habe nur
bemerkt, das dieses Projekt ( und seine vielen anderen Schnipsel ) zu
einseitig sind. Es sollte eigentlich als Anregung dienen, beim nächsten
mal etwas Konstruktiver zu sein. Es ist ja hier im Forum allgemein
bekannt, das man sofort ein TROLL ist, wenn eine Kritik kommt. Nun das
wird mich nicht davon abhalten, weiterhin Kritik zu üben.

sucher wrote:
> du solltest mal sehr sehr sehr aufmerksam lesen, was ich kritisiert
> habe.

Noch besser wäre aber, Du liest erstmal durch, was Du da so
rumpalaverst.


> Der Quellcode von unseren Sonnenschein Herrn Dannegger geht mir
> sowas von vorbei. Ich habe daran absolut kein Interesse.

Wenn Du Dich nicht zu dem Projekt äußern willst, dann sind Deine
Beiträge total fehl am Platze. Nur zum heiße Luft ablassen ist ja extra
das Forum Offtopic da.


> Ich habe nur
> bemerkt, das dieses Projekt ( und seine vielen anderen Schnipsel ) zu
> einseitig sind.

Was meinst Du mit einseitig?
Es sind Lösungen für eine bestimmte Aufgabe. Genau das ist der Sinn der
Codesammlung. Und es wird nirgends behauptet, daß es die einzigste
Lösung für diese Aufgabe wäre.

Das hier ist keine Lehrveranstaltung, wo jemand verschiedene Lösungen
für eine Aufgabe vergleichen muß. Es reicht genau eine Lösung völlig
aus.
Man kann natürlich trotzdem andere Lösungen bezogen auf die vorgestellte
Lösung vergleichend bewerten.


> Es sollte eigentlich als Anregung dienen, beim nächsten
> mal etwas Konstruktiver zu sein.

Sei doch erstmal selber konstruktiv. Bisher war ja von Dir absolut
nichts in dieser Richtung zu vernehmen.


> Es ist ja hier im Forum allgemein
> bekannt, das man sofort ein TROLL ist, wenn eine Kritik kommt.

Nö, das ist mir bisher noch nie aufgefallen. Sachbezogene Kritik wird
immer gerne gesehen und ernst genommen.


> Nun das
> wird mich nicht davon abhalten, weiterhin Kritik zu üben.

Wenn Du aber keine konstruktive Kritik üben willst, dann laß Dein
Gesülzte doch besser im Offtopic ab, da paßt es hin.


Peter

ja Perter Dannegger , da haben wir es wieder. Keine Kritik erlaubt. Du
kannst es nicht leiden, wenn andere an Deiner abloluten Großartigkeit
zweifeln. Kritik als absolutes Gesülze abzutun, bestätigt nur, was ich
bisher von Dir hier gehört habe. Wenn man also mal Kritik an einem
Projekt übt, muss man sofort ein besseres nachschieben. So ein
Schwachsinn kann aber nur von unseren Sonnschein kommen.
Es ist mir absolut zuwieder, in den gleichen Huldigungsgesang
einzustimmen, wie alle anderen hier.
Man sieht sich immer zweimal im Leben.

sucher wrote:
> Im übrigen gibt es mein Projekt schon seit Jahren im Netz.

Könntest du dazu mal den Link angeben ?

Ein sehr schönes Beispiel für den großen Nachteil dieser Codesammlung.

Wenn sich jemand in Zukunft für dieses Projekt interessiert, muss er
sich durch diesen ganzen Müll lesen, um evt. wichtige Informationen
mitzubekommen.

Sollte es irgendwann mal ein Update geben, wird es irgendwo zwischem
persönlichem Gepläckel versteckt sein.

Ich könnte sogar verstehen wenn manche Leute keinen Bock mehr hätten
ihre Projekte hier zu veröffentlichen...

Genau, das ist der Punkt.
Hab vor einigen Wochen einen I2C Sniffer mit dem MSP430F2013 gebaut.
Würde ich gerne veröffentlichen, aber .... hab keine Lust auf dummes
Gelaber von irgendwelchen Besserwissern oder notorischen Nörglern.
Trotzdem sollte sich Peter nicht davon abhalten lassen.

Noch einen schönen Tag

Gruß
Siegmar

sucher wrote:
> ja Perter Dannegger , da haben wir es wieder. Keine Kritik erlaubt.

Nö, ich habe Kritik zum Thema ausdrücklich erwünscht.

> Kritik als absolutes Gesülze abzutun, bestätigt nur, was ich
> bisher von Dir hier gehört habe.

Dann sülz nicht weiter rum, sondern fang doch endlich mal an zu
kritisieren.

> Wenn man also mal Kritik an einem
> Projekt übt, muss man sofort ein besseres nachschieben.

Wer hat denn sowas verlangt, ich jedenfalls nicht.

> So ein
> Schwachsinn kann aber nur von unseren Sonnschein kommen.

Der Sonnenschein bist dann ja Du, der sich diesen ganzen Schwachsinn
ausdenkt.

Ich war immer der Meinung, daß ich einigermaßen verständliches Deutsch
schreibe. Was Du Dir da alles zusammen reimst, habe ich nirgends
geschrieben. Ist Deutsch Deine Muttersprache?

> Es ist mir absolut zuwieder, in den gleichen Huldigungsgesang
> einzustimmen, wie alle anderen hier.

Wenn Du meinst, daß ich das von Dir verlangt habe oder daß das hier im
Forum jemand von Dir verlangt, dann hast Du wirklich nen ganz schönen
Dachschaden.

> Man sieht sich immer zweimal im Leben.

Na ich wills ja nicht hoffen, daß ich demnächst eine Nervenklinik
beehre. Woanders halte ich ein Treffen mit Dir für extrem
unwarscheinlich.


Peter

ja da ist er wieder und jetzt rastet er richtig aus. Deine Beleidigungen
sprechen für Deinen überheblichen und größenwahnsinnigen Charakter. Ich
habe Dich in keinem Beitrag beleidigt, aber unser Sonnenschein Herr
Dannegger muss natürlich gleich mit einer Nervenklinik kommen. Es
bstätigt sich das, was ich weiter oben schon geschrieben habe. Ich bin
nicht derjenige, der hier unsachlich andere beschimft.

@sucher:
>was ich bisher von Dir hier gehört habe. (von Peter Dannegger)

Was hast du denn so gehört? Von wem denn?
Von jemanden, der jemanden kennt, der jemanden kennt, der den Peter
kennt?
Oder wie?

@Peter Dannegger:
Sieh es einfach als Neid.
Und wie sagt man so schön:
"Neid ist die höchste Form der Anerkennung."

ich habe ein Thread eröffnet, in der Hoffnung das man ihn sieht:
Beitrag "Diskussion: I2C (TWI) Sniffer"

Könnt ihr dort euren Senf ablassen und zumindest die Codesammlung in
Ruhe lassen.