Hallo Leute, ist es möglich, den uC mit egal welchem Handy zu verbinden und Daten vom uC auf Handy zu übertragen? Wenn ja, ist das Protokoll standardisiert? Wo kann man diese einsehen? Ich habe eine funktionierende Lösung, die mit einem Handy per Bluetooth verbunden ist und eigene Batterie Stromversorgung hat. Nun möchte ich Bluetooth und Batterien loswerden. Die Stromversorgung und Kommunikation soll jetzt nur über Kabel vom Handy funktionieren. Bisher habe ich nicht viel Information gefunden. Gruß Stefan
stefan schrieb: > ist es möglich, den uC mit egal welchem Handy zu verbinden und Daten vom > uC auf Handy zu übertragen? Nein. Es gibt nämlich verschiedene µC, verschiedene Handys und unterschiedliche mögliche Schnittstellen. > Wenn ja, ist das Protokoll standardisiert? Jain. Es gibt zum einen viele mögliche Protokolle. Die sind dann typisch auch standardisiert. Aber längst nicht jedes Protokoll ist über jede Schnittstelle möglich und längst nicht jedes Protokoll wird von jedem Handy beherrscht. > Bisher habe ich nicht viel Information gefunden. Das wundert mich kein bissel...
Nimm einen USB-Stick. DAS ist standarisiert. Und funktioniert sowohl bei &-roid, als auch bei Apfel. c-hater schrieb: >> Bisher habe ich nicht viel Information gefunden. > > Das wundert mich kein bissel... Mich auch nicht. Wir wissen ja nicht einmal, was für Daten übertragen werden sollen und was das Handy damit anstellen soll. Gruß Jobst
Jobst M. schrieb: > Nimm einen USB-Stick. DAS ist standarisiert. Und funktioniert sowohl bei > &-roid, als auch bei Apfel. Aber noch lange nicht an allen Geräten. An die meisten Smartphones und Tablets kann man keinen USB Speicherstick anschließen. Bei der Unterstützung von seriellen Geräten (CDC) sieht es noch schlechter aus. Früher hätte ich vorgeschlagen, die Klinkenbuchse zu benutzen, aber die verschwindet ja auch bereits. Wahrscheinlich bleibt langfristig nur WLAN übrig, geht also in Richtung ESP8266.
stefan schrieb: > Hallo Leute, > ist es möglich, den uC mit egal welchem Handy zu verbinden und Daten vom > uC auf Handy zu übertragen? Wenn ja, ist das Protokoll standardisiert? > Wo kann man diese einsehen? Wofür brauchst Du das Handy? Wenn Du damit Daten per LTE übertragen willst, ist es einfacher, ein extra LTE-Modem zu verwenden. Vorschlag: https://www.quectel.com/product/lte-ec21-mini-pcie-series Da musst Du nur den Mini-PCIe Stecker löten und kannst das empfindliche Modul dann einstecken. Obwohl das Modem einen Mini-PCIe Stecker hat, kommuniziert es per USB oder per UART. USB können alle diese Modemkarten, UART nicht alle. Das Modem braucht 3.3V und bis zu 2.7A kurzzeitig. Die Hardware-Anbindung ist gut beschrieben und für jemanden mit Ahnung kein Problem. Die AT-Befehle sind weitgehend standardisiert und auch beschrieben. Das ist die Lösung, die in der echten Welt für mobile Daten verwendet wird. Wenn das Handy als Benutzerschnittstelle verwendet werden soll, dann gibt es keinen Standard und keine allgemeine Lösung. fchk
Die allermeisten modernen Android-Handys haben USB-C bzw. USB-OTG. Mit einem entsprechenden handelsüblichen Adapter kann man USB-fähige Mikrocontroller damit verbinden (wenn der Controller z.B. auf einer Platine mit Mini-USB untergebracht ist, wie bei vielen Eval-Boards). Auf Mikrocontroller-Seite braucht man natürlich einen USB-Treiber. Man kann jedes beliebige eigene Protokoll umsetzen und "nativ" über USB übertragen, kein CDC (virtueller Serial-Port) nötig. Auf Android-Seite kann man über das normale Android-API aus eigenen Apps heraus direkt auf USB-Geräte zugreifen (mindestens Android Version 3.1): https://developer.android.com/guide/topics/connectivity/usb/host . Das funktioniert ähnlich zu libusb, ist aber tatsächlich sogar einfacher als auf dem PC! Man braucht keine "Treiber" o.ä. installieren oder externe Libraries einbinden. Der Nutzer muss lediglich den Zugriff auf das Gerät einmal erlauben (ähnlich zu Permissions). Man kann sogar die eigene App automatisch starten lassen wenn man das Gerät anschließt.
Stefan ⛄ F. schrieb: > An die meisten Smartphones und > Tablets kann man keinen USB Speicherstick anschließen. Eigentlich können es mittlerweile die meisten Geräte, nennt sich „USB OTG“, und ist nicht mal nur auf Speichersticks beschränkt, sondern kann etwa auch HIDs und solche Dinge ansprechen. Entsprechend wäre meine Wahl, wenn es denn via Kabel an so ein Gerät gehen sollte, ein μC mit entsprechender USB-Schnittstelle. Wenn das Kabel nicht zwingend sein muss, dann würde ich heute wohl einen Controller oder ein Board mit Bluetooth LE wählen.
Da ein heutiges Telefon nur einen USB Stecker hat, stößt du doch ziemlich schnell auf 2 praktikable Möglichkeiten. USB CDC und USB HID. Und tausende Open Source Projekte, die ein Smartphone als Datenlogger benutzen. Da findest du doch genug Beschreibungen, wie du USB CDC Host auf den verschiedenen Smartphones aktivierst und aus deinem selbst geschriebenen Programm benutzt. Solltest sowieso einen MC benutzen der USB in Hardware unterstützt. Da liefert der Hersteller Libraries und Beispiele mit. Dass du ansonsten nur uralte Protokolle findest, die kein Smartphone mehr unterstützt, legt die Vermutung nahe, es gibt nur diese beiden Möglichkeiten.
Noch ein Kommentar schrieb: > USB CDC und USB HID Es ist gar nicht nötig sich darauf zu beschränken. Gerade bei CDC kann man viele Vorteile von USB nicht nutzen. Unter Android ist es geradezu trivial einfach, ein komplett eigenes Protokoll zu implementieren, daher gibt es wenig Grund das nicht zu tun, denn da spart man sich einige Arbeit und hat mehr Flexibilität und Möglichkeiten. Mit einem Kabel dieser Art kann man die meisten Eval-Boards (Mini-USB) mit USB-C-Handys verbinden: https://www.amazon.de/dp/B08Y7B6W1D
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Aber noch lange nicht an allen Geräten. An die meisten Smartphones und > Tablets kann man keinen USB Speicherstick anschließen. Bei der > Unterstützung von seriellen Geräten (CDC) sieht es noch schlechter aus. Nun hör doch endlich mal auf diese Ammenmärchen herunter zu leiern! Unsere Kunden installieren unsere App z.T. vom USB-Stick und benutzen anschließend CDC-Devices. Bisher gab es da keine Rückfragen. Funktioniert vom billigst-China-Handy bis zu Samsung und Huawei. Bei letzteren hat man ehr das Problem, dass sie aus Energiespagründen die Apps einfach anhalten. (um die in der Werbung versprochene, mit dem kleinen Akku mögliche Betriebszeit zu erreichen) Gruß Jobst
Jobst M. schrieb: > Nun hör doch endlich mal auf diese Ammenmärchen herunter zu leiern! Offenbar liegt hier eine Verwechselung vor.
Stefan ⛄ F. schrieb: > Offenbar liegt hier eine Verwechselung vor. Von meiner Seite nicht! Gruß Jobst
>>>> An die meisten Smartphones und Tablets kann man keinen USB >>>> Speicherstick anschließen. Bei der Unterstützung von seriellen >>>> Geräten (CDC) sieht es noch schlechter aus. >>> Nun hör doch endlich mal auf diese Ammenmärchen herunter zu leiern! >> Offenbar liegt hier eine Verwechselung vor. Jobst M. schrieb: > Von meiner Seite nicht! Na dann zeige mal, worauf du dich beziehst. Wo leiere ich angeblich ständig dieses "Ammenmärchen" herunter?
Das geht nicht! Händies der Marke: "egal welchem" sind so selten, dass sich noch keiner die Arbeit gemacht hat, eine Verbindung zum PehCeh zu schaffen. Vielleicht hast Du mehr Glück bei Handys der Marke „ich weiß welches es ist“.
Jobst M. schrieb: > Stefan ⛄ F. schrieb: > >> Aber noch lange nicht an allen Geräten. An die meisten Smartphones und >> Tablets kann man keinen USB Speicherstick anschließen. Bei der >> Unterstützung von seriellen Geräten (CDC) sieht es noch schlechter aus. > > Nun hör doch endlich mal auf diese Ammenmärchen herunter zu leiern! USB-OTG ist mittlerweile seit Jahren Standard. Massenspeichergeräte, Hid, CDC, selbst Ethernet, etc. Treiber sind weit verbreitet. Android Geräte waren zumindest vor wenigen Jahren vielfältiger als iPhones (kein CDC,..).
Stefan ⛄ F. schrieb: > Na dann zeige mal, worauf du dich beziehst. Wo leiere ich angeblich > ständig dieses "Ammenmärchen" herunter? z.B. hier: Beitrag "Re: Kann man ein Tablet als Display nehmen?" oder hier: Beitrag "Re: Logging App für Android" Ich habe es aber schon häufiger von Dir gelesen - finde ich nun aber nicht, bzw. habe keine Lust weiter zu suchen. Gruß Jobst
Mein altes Fon kann kein USB OTG. Selbst eine Bluetoothtastatur braucht einen extra Treiber. Was für ein Guhgelmurks. > Jobst M. schrieb: > Nun hör doch endlich mal auf diese Ammenmärchen herunter zu leiern! Hat er seine 50000 Beiträge noch nicht erreicht dass er endlich Ruhe gibt?
Sebastian S. schrieb: > Händies der Marke: "egal welchem" sind so selten Apple und Kabel sind wohl auch zwei Welten, die sich zunehmend voneinander entfernen.
Jobst M. schrieb: > z.B. hier: Punkt für dich. Ich erkläre mal, wie ich dazu komme. Vor drei Jahren hatte ich mir einen USB-OTG Adapter gekauft, und damit USB-UART Adapter und USB Speichersticks an sämtlichen Android Geräten in meinem Haushalt, sowie ein Tablet bei den Schwiegereltern versucht. Es hat an keinem der 8 Geräte funktioniert. Bei zwei Smartphones hatte ich genauer hin geschaut und festgestellt, dass der USB-UART Adapter zwar erkannt wird, aber der dazu nötige Kernel Treiber fehlte. Ein Kollege auf der Arbeit hatte ein anderes Tablet, an dem beides funktionierte. Insofern weiß ich, dass es gehen kann und dass der Adapter in Ordnung ist. Nun ist das schon 3 Jahre her. Bei jüngeren Geräten ist die Situation vielleicht anders. Nur wollte der TO, dass die Sache an "egal welchem Handy" funktioniert. Das scheitert an den Geräten in meinem Haushalt, sowie an allen Apple Smartphones. Wie gesagt, inwiefern Android inzwischen generische USB Programmierung unterstützt, weiß ich nicht. Mag sein, dass es da besser wird. Bei Apple wird es aber aufgrund der "gar keine Kabel" Strategie schlechter. Und damit ist die Idee des TO fragwürdig. Ich wollte nicht sagen, dass es nicht geht, jedoch dazu anregen, nochmal drüber nach zu denken.
Stefan ⛄ F. schrieb: > Wie gesagt, inwiefern Android inzwischen generische USB Programmierung > unterstützt, weiß ich nicht. Wie gesagt, seit Android 3.1, also seit schlappen 11 Jahren. Und weil das Teil des API ist, unterstützen das alle Android-Geräte welche OTG können, und damit ist man völlig unabhängig von USB-Seriell-Treibern o.ä. Daher ist das wohl eine bessere weil universellere Möglichkeit...
Niklas G. schrieb: > Daher ist das wohl eine bessere weil universellere Möglichkeit Klingt verlockend. stefan (Gast) wie findest du diesen Ansatz? Traust du dir generische USB Programmierung zu? Spielen Apple Geräte für dich eine Rolle?
Stefan ⛄ F. schrieb: > Traust du dir generische USB Programmierung zu? Ich finde das sogar einfacher als per USB-Serial. Abgeschickte Pakete kommen genau so am Stück an, während der Host-Treiber beim Serialport diese beliebig stückeln/zusammensetzen kann, sodass man einen komplizierten Empfangsalgorithmus braucht (wie das z.B. die Anwendung in diesem Thread nicht macht: Beitrag "Alte .net Apk mag keine USB to RS232 Adapter" ). Flusskontrolle ist inklusive, man braucht sich keine Sorgen machen dass Daten verloren gehen weil man zu langsam abruft. Man kann Daten über mehrere Kanäle (Endpoints) schicken was je nach Anwendung ein Protokoll unnötig machen kann. Auf Host/App Seite kann man eine nutzerfreundliche Auswahl der angeschlossenen Geräte anzeigen, z.B. mit Seriennummer, der User muss sich nicht mit kryptischen Bezeichnungen à la /dev/ttyACM0 rumschlagen. Und weil man eben gerade unter Android gar keine Bibliothek à la libusb braucht sondern der Zugriff direkt über das Android API erfolgt ist die Einstiegshürde extrem niedrig.
Niklas G. schrieb: > Ich finde das sogar einfacher als per USB-Serial. Das dachte ich mir schon. Du hast dazu ja auch das entsprechende Hintergrundwissen. Auf jeden Fall braucht man sich bei der Methode nicht um fehlende Kerne Treiber sorgen. Wenn man Apple mal außen vor lassen kann/will, scheint mir dieses Projekt (wenn es denn meins wäre) ein guter Anlass, sich (endlich mal) mit der generischen USB Programmierung zu befassen. Das ist bestimmt nicht einfach, kein Vergleich zu Arduino Niveau. Aber man hat dann auch später was davon, in künftigen Projekten. Apropos ID Nummern: Ist das immer noch so, dass man sie für viel Geld kaufen muss? Ich nehme an, dass Hobby Entwickler für ihren eigenen Bedarf einfach irgendeine (hoffentlich) freie Nummer verwenden dürfen. Stimmt das? stefan (Gast) was ist denn nun mit Apple Geräten? Sind sie dir egal, oder willst du sicher sein, dass diese (auch künftige Modelle) ebenfalls an dein Kabel passen?
> weil man zu langsam abruft
Von der Geschwindigkeit eines seriellen Kerneltreibers ist das
Javagefrickel ja auch Grössenordnungen entfernt.
Das Leistungsniveau liegt, um es mal in x86 zu übersetzen,
bei einem 286 mit 16 MHz. Das reicht gerafe für ein paar einzelne
Zeichen die mit moderater Geschwindigkeit gesendet werden.
xyzzy schrieb: > Von der Geschwindigkeit eines seriellen Kerneltreibers ist das > Javagefrickel ja auch Grössenordnungen entfernt. Es steht dir frei Android-Anwendungen in Assembler zu schreiben.
> Es steht dir frei Android-Anwendungen in Assembler zu schreiben.
"Es steht dir frei Fehler in [OSSBLABLA] zu finden und dir
[OSSBLABLA] selber zu bauen.
Die typische Denkweise dieser Frickler.
Das ihr Produkt mit allgemeingültigen Massstäben gemessen
eventuell nichts taugt, heute allzumeisst aus Performancegründen,
kommt ihnen überhaupt nicht in den Sinn.
Stattdessen wird der Nutzer aufgefordert, es doch besser zu machen.
In völliger Verkennung, was der eigentliche Zweck ihrer
"Wissenschaft" ist.
Ich wünsche solchen Leuten mal einen Taschenrechner der auf
einer realen Turingmaschine läuft. Mal sehen wie schnell sie
da die Geduld verlieren würden.
xyzzy schrieb: > Stattdessen wird der Nutzer aufgefordert, es doch besser zu machen. Wenn du für die Erfüllung solcher Sonderwünsche entsprechend zahlst, ist es sicher kein Problem das für dich umzusetzen. Aber was hat das nochmal mit USB zu tun?
xyzzy schrieb: > Von der Geschwindigkeit eines seriellen Kerneltreibers ist das > Javagefrickel ja auch Grössenordnungen entfernt. Du meinst, dass die Apps in Java geschrieben würden und daher zu langsam wären? Denn das würde allenfalls belegen, dass du keinerlei Ahnung davon hast, wie Android funktioniert – das läuft da ein wenig anders, als bei Java-Anwendungen, wie sie dir vielleicht gerade vorschweben.
Niklas G. schrieb: > Ich finde das sogar einfacher als per USB-Serial. Ist es aber nicht. > Abgeschickte Pakete > kommen genau so am Stück an, während der Host-Treiber beim Serialport > diese beliebig stückeln/zusammensetzen kann, sodass man einen > komplizierten Empfangsalgorithmus braucht So what? Spätestens wenn man "streaming" benötigt, um kontinuierlich Daten zu transportieren, braucht man sowieso ein vernünftiges Protokoll und kann sich nicht mehr auf irgendwelche Paketierungen tieferer Layer des Protokollstacks verlassen. Und natürlich auch dann nicht, wenn USB nicht der der einzige mögliche Weg sein soll, sondern es genauso z.B. über ein Netzwerk funktionieren soll. Oder anders ausgedrückt: Du hast keine Ahnung von Protokoll-Design und deshalb den scheinbar leichteren Weg gewählt. Krasser (aber natürlich recht typischer) Anfänger-Fehler...
> das läuft da ein wenig anders Ach. Ausser das der verschnurzelte Javabytecode gecached wird, wo wäre denn da das "anders"? Wenn die so tollen Android-Apps ein wenig Performance brauchen, dann bekommen sie eine Library mit ein wenig nativen ARM-Code. Das Javazeug selber reicht ja gerade für Furzapps. Wer mir mit > Es steht dir frei Android-Anwendungen in Assembler zu schreiben. kommt, soll das mal selber tun. Mit dem NDK geht sowas ja.
xyzzy schrieb: > Das Javazeug selber reicht ja gerade für Furzapps. Hm. Du hast dein letztes Android-Gerät vor etwa zehn Jahren in den Händen gehalten, kann das sein? Die ART erlaubt schon eine beeindruckende Performance, solange der Entwickler seinen Kotlin-Code nicht völlig versemmelt hat.
xyzzy schrieb: > Ausser das der verschnurzelte Javabytecode gecached wird, > wo wäre denn da das "anders"? Informiere dich mal über JIT Compiler. https://source.android.com/devices/tech/dalvik/jit-compiler Abgesehen vom Start laufen Java Anwendungen fast gleich schnell wie C++, was etwa halb so schnell wie C ist. Die vom User erlebte Performance hängt überwiegend von anderen Faktoren ab.
Stefan ⛄ F. schrieb: > Abgesehen vom Start laufen Java Anwendungen fast gleich schnell wie C++, > was etwa halb so schnell wie C ist. Die vom User erlebte Performance > hängt überwiegend von anderen Faktoren ab. Dasselbe (wobei man über Details diskutieren könnte, aber von der Tendenz her passt das aber in etwa) gilt übrigens genauso für .Net und auch für "compilierbare Scriptsprachen" wie etwa Python. Da ist nur der "first-start-lag" noch viel extremer als bei den Zwischencode-Sprachen.
c-hater schrieb: > Oder anders ausgedrückt: Du hast keine Ahnung von Protokoll-Design und > deshalb den scheinbar leichteren Weg gewählt. Krasser (aber natürlich > recht typischer) Anfänger-Fehler... Ab wie vielen Jahrzehnten Programmiererfahrung ist man eigentlich kein Anfänger mehr? Offenbar hast du keine Ahnung von USB. Der USB-Protokollstack baut die Pakete, welche man auf Endpoints schickt, nicht um. Das macht höchstens der CDC-Treiber, der aber bei einem eigenen USB-Protokoll natürlich nicht benutzt wird. Wenn man über das Android-API, libusb oder WinUSB ein USB-Paket an einen Endpoint schickt, oder eben auf dem Mikrocontroller eines an die Hardware übergibt, kommt es genau so auf der Gegenseite an. Für einfache Anwendungen braucht man auch ggf. gar kein Protokoll, man kann z.B. Blöcke an ADC-Daten über den einen Endpoint schicken, Blöcke an GPIO-Daten über einen anderen. Übrigens genau das, was CDC auch macht, aber intransparent für die Anwendung. c-hater schrieb: > Und natürlich auch dann nicht, wenn USB nicht der der einzige mögliche > Weg sein soll, sondern es genauso z.B. über ein Netzwerk funktionieren > soll. Davon war nie die Rede. Und ein netzwerkfähiges Protokoll über USB zu führen ist kaum sinnvoll, das macht CDC auch nicht. Kennst du ein USB-Protokoll was das tut? Oder welches die Paketierung von USB nicht nutzt und stattdessen da noch einen Layer drüber legt?
Niklas G. schrieb: > Ab wie vielen Jahrzehnten Programmiererfahrung ist man eigentlich kein > Anfänger mehr? Wenn man keine Anfänger-Fehler mehr macht. > Offenbar hast du keine Ahnung von USB. Das würde ich nicht bestätigen wollen. Nein, ich kennen mich AUCH mit USB recht gut aus. > Der USB-Protokollstack baut die > Pakete, welche man auf Endpoints schickt, nicht um. Das hängt davon ab, auf welcher Ebene des Stacks man ansetzt. Auch bei USB gibt es Streaming und Pakete. Der Datenkanal von Bulk-Endpoints (also z.B. CDC) ist ein Streaming-Endpoint. Eben darauf optimiert, die Daten mit höchstmöglichem Durchsatz (aber auch mit einer gewissen Datensicherheit) zu transportieren. Das ist ziemlich gut vergleichbar mit dem TCP-Protokoll des IP-Networking. Hier werden dieselben Ziele verfolgt. > Davon war nie die Rede. Und ein netzwerkfähiges Protokoll über USB zu > führen ist kaum sinnvoll, das macht CDC auch nicht. Das genau ist, was Dummköpfe wie du nicht begreifen können. Wenn ich ein Protokoll implentiere, was über einen USB-Bulk-Kanal funktioniert, wird es auch über einen TCP-Kanal funktionieren. Und umgekehrt. Capisce?
c-hater schrieb: > Das würde ich nicht bestätigen wollen. Nein, ich kennen mich AUCH mit > USB recht gut aus. Merkt man gar nicht. c-hater schrieb: > Das hängt davon ab, auf welcher Ebene des Stacks man ansetzt. Wie gesagt, auf Endpoint-Ebene. c-hater schrieb: > Der Datenkanal von Bulk-Endpoints > (also z.B. CDC) ist ein Streaming-Endpoint. Falsch. c-hater schrieb: > Das ist ziemlich gut vergleichbar > mit dem TCP-Protokoll des IP-Networking. Falsch. c-hater schrieb: > Hier werden dieselben Ziele > verfolgt. Nein. c-hater schrieb: > Wenn ich ein > Protokoll implentiere, was über einen USB-Bulk-Kanal funktioniert, wird > es auch über einen TCP-Kanal funktionieren. Und umgekehrt. Falsch.
Wie ein Arduino einfach nach Hause telefonieren kann zeigt CCZWEI-TV im aktuellen Video: https://www.youtube.com/watch?v=bBKpP0CEm_I
Niklas G. schrieb: > Merkt man gar nicht. DU merkst das nicht. >> Der Datenkanal von Bulk-Endpoints >> (also z.B. CDC) ist ein Streaming-Endpoint. > > Falsch. Die USB-Doku sagt aber, dass der Bulk-Transfer-Typ genau dafür gedacht ist. Also haben selbst die USB-Designer selber weniger Ahnung von USB als du? Ziemlich vermessen, findest du nicht? > Falsch. > Nein. > Falsch. Du bist ein offensichtlich vollkommen unbelehrbarer Idiot. Was mich betrifft also: EOT.
c-hater schrieb: > Die USB-Doku sagt aber, dass der Bulk-Transfer-Typ genau dafür gedacht > ist. Dann bist du offenbar des Lesens nicht mächtig. Wundert wohl keinen. c-hater schrieb: > Du bist ein offensichtlich vollkommen unbelehrbarer Idiot. Was mich > betrifft also: EOT. Du bist jemand, der statt Argumente Beschimpfungen liefert. Wie nennt man das?
c-hater schrieb:
> Dummköpfe, unbelehrbarer Idiot, Capisce?
Würdest du von jemandem lernen wollen, der dich und andere ständig
beleidigt? Auch ich habe mal einen schlechten Tag, wo ich die
Beherrschung verliere, aber bei dir scheint das ein Dauerzustand zu
sein. Eigentlich schade.
Beim Thema USB kannst du dem Niklas jedenfalls nicht das Wasser reichen.
Halte dich besser aus diesem Thema heraus, bevor es noch peinlicher
wird.
Stefan ⛄ F. schrieb: > Würdest du von jemandem lernen wollen, der dich und andere ständig > beleidigt? Wenn ich erstmal erkannt habe, dass der mehr weiß als ich: NATÜRLICH. Alles andere wäre idiotisch, würde mir nur selber schaden. So habe ich die Schule und das Studium gemeistert. Ich mochte (fast) keine der Lehrkräfte, habe aber immer begriffen, dass die weitaus mehr wissen als ich. Und dass es die beste Strategie für mich ist, dieses Wissen zu akkumulieren. So sehr mich diese Fatzken auch angekotzt haben, hat mich das niemals davon abgehalten, von ihrem Wissen zu profitieren... Nur Vollidioten gehen anders vor und stellen ihre persönlichen Empfindlichkeiten über die Chance zum Gewinn von Wissen. Und außerdem: Vollidioten KANN man GARNICHT beleidigen. Das ist ein Schluss aus der formalen Logik...
Es muss frustrierend sein, wenn man alle Menschen um sich herum nicht leiden kann. Was ist mit einem Hund oder einem Pferd, wäre das eine Alternative für dich?
Pferde zu beleidigen ist schlecht fürs Gebiss. Wenn der Gaul es merkt.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Was ist mit einem Hund oder einem Pferd, wäre das eine > Alternative für dich? c-hater würde ich kein Tier anvertrauen, nicht mal eine Ratte. Bei seinen geistigen und moralischen Defekten wäre das unverantwortliche Tierquälerei. Georg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.