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
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
>>>> 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,..).
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.
c-hater schrieb im Beitrag #7087987:
> 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 im Beitrag #7087987:
> 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?
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
