Wie funktioniert das bei ST, wenn die Funktion nur ein uint8_t* entgegen nimmt? HAL_StatusTypeDef HAL_USART_Transmit(USART_HandleTypeDef *husart, uint8_t *pTxData, uint16_t Size, uint32_t Timeout)
:
Gesperrt durch User
foobar schrieb: > uint8_t c = 'a'; > > HAL_USART_Transmit(husart, &c, 1, timeout); Ja, aber ich möchte aber ein int8_t schicken, nicht uint8_t
klaus schrieb: > ich möchte aber ein int8_t schicken, nicht uint8_t Das ist dem UART herzlich egal, das sieht nur 8 Bits und schiebt die raus. Was sich hinter den Bits verbirgt, musst nur du wissen.
klaus schrieb: > Ja, aber ich möchte aber ein int8_t schicken, nicht uint8_t Dann hast du noch viele Dinge nicht verstanden.
Georg G. schrieb: > klaus schrieb: >> ich möchte aber ein int8_t schicken, nicht uint8_t > > Das ist dem UART herzlich egal, das sieht nur 8 Bits und schiebt die > raus. Was sich hinter den Bits verbirgt, musst nur du wissen. Achso, ok, also ich muss bei zB -80 prüfen ob kleiner 0, dann ein - in Asci raus schicken, und zwei uint8_t's.. danke vielmals. Alles muss man selber machen... nix kann die UART :D
Beitrag #5710091 wurde von einem Moderator gelöscht.
Beitrag #5710092 wurde von einem Moderator gelöscht.
klaus schrieb: > Achso, ok, also ich muss bei zB -80 prüfen ob kleiner 0, dann ein - in > Asci raus schicken, und zwei uint8_t's.. Nein, denn: Zäh Leera schrieb: > Dann hast du noch viele Dinge nicht verstanden.
Moment mal: Willst du ein Byte senden, oder einen Text, der den numerischen Wert des Bytes (z.B. in dezimaler Schreibweise) darstellt? Klaus und Georg sind von ersterem ausgegangen. Die Umwandlung des Bytes in Text kannst du zum Beispiel mit sprintf() erledigen.
Wenn du nur ein Byte schicken willst, dann besteht das aus 8 Bits. ein int8 kann negative Zahlen repräsentieren, indem diese im Zweierkomplement in den 8 Bit gespeichert wird. Das MSB sagt dir dann das Vorzeichen (1 für negativ). Wenn du ein uint8 verschickst, dann kannst du auch das MSB verwenden, um Zahlen zu speichern. Dem UART ist es egal, was von dem beiden du verschickst. Wichtig ist, dass dein Empfänger weiss, ob er ein uint oder ein int empfangen soll, damit er es richtig interpretieren kann.
klaus schrieb: > Achso, ok, also ich muss bei zB -80 prüfen ob kleiner 0, dann ein - in > Asci raus schicken, und zwei uint8_t's.. > danke vielmals. > > Alles muss man selber machen... nix kann die UART :D Willst du ASCII-kodierten Text schicken oder uint8_t?
Georg G. schrieb: > klaus schrieb: >> ich möchte aber ein int8_t schicken, nicht uint8_t > > Das ist dem UART herzlich egal, das sieht nur 8 Bits und schiebt die > raus. Was sich hinter den Bits verbirgt, musst nur du wissen.
klaus schrieb: > Achso, ok, also ich muss bei zB -80 prüfen ob kleiner 0, dann ein - in > Asci raus schicken, und zwei uint8_t's.. > danke vielmals. Bitte sag dass dasein Scherz ist.
Bondu schrieb im Beitrag #5710092: > Ich bin immer wieder tief beeindruckt von Menschen, > die keinerlei Hilfe sind... Ich bin immer wieder tief beeindruckt von Menschen die sich so leicht von Trollen verarschen lassen.
klaus schrieb: > Achso, ok, also ich muss bei zB -80 prüfen ob kleiner 0, dann ein - in > Asci raus schicken, und zwei uint8_t's.. > danke vielmals. > > > Alles muss man selber machen... nix kann die UART :D Nein. 8 Bit sind 8 Bit. Man kann diese als signed oder als unsigned interpretieren, da ist man völlig wahlfrei. Die Interpretation der Daten ist der Schnittstelle komplett egal. Erst der Empfänger muss die Daten wiederum so interpretieren, dass das gewünschte Ergebnis herauskommt.
klaus schrieb: > Wie funktioniert das bei ST, wenn die Funktion nur ein uint8_t* entgegen > nimmt? > > HAL_StatusTypeDef HAL_USART_Transmit(USART_HandleTypeDef *husart, > uint8_t *pTxData, uint16_t Size, uint32_t Timeout) Was ist das denn für ein Ober-Bockmist: "uint8_t *pTxData", den ST da offenbar gebaut hat? Also, in8_t un uint8_t sind Integer-Rechengrößen - aber keine send- oder empfanbaren Zeichen. Für sowas ist noch immer der Grundtyp "char" zuständig! Als ich die Überschrift des Threads las, dachte ich an eine Ausgabe-Konvertierung etwa in der Art: int8_t --> int --> IntToString oder etwas vergleichbares --> Zeichenkette --> und hier zum UART hinaus. W.S.
W.S. schrieb: > Also, in8_t un uint8_t sind Integer-Rechengrößen - aber keine send- > oder empfanbaren Zeichen. Für sowas ist noch immer der Grundtyp "char" > zuständig! Wer sagt denn, dass die UART Schnittstelle nur Zeichen übertragen kann? Meine konnten schon immer und auch weiterhin durchaus Bytes übertragen.
W.S. schrieb: > Für sowas ist noch immer der Grundtyp "char" > zuständig! Stimmt! 8 Bit sind nun mal was ganz Anderes als 8 Bit. Besonders bei Maschinen. Die sind da gaaanz empfindlich!
W.S. schrieb: > Was ist das denn für ein Ober-Bockmist: "uint8_t *pTxData", den ST da > offenbar gebaut hat? Keiner. Würde dort "char *" verwendet, implizierte das, daß es um darstellbaren Text geht, aber über UARTs möchte man auch sehr gerne reine Binärdaten versenden, um z.B. Protokolle wie Modbus oder was auch immer zu betreiben. Da aber zusätzlich eine Längenangabe vorhanden ist, ist offensichtlich, daß es nicht nur um die Textübertragung geht.
Rufus Τ. F. schrieb: > Keiner. Würde dort "char *" verwendet, implizierte das, daß es um > darstellbaren Text geht, Char ist grundsätzlich NICHT auf darstellbaren Text beschränkt, sondern eben nichts anderes als Zeichen. Auch sowas wie STX und ETX, RS, BS und Konsorten gehören zu den Zeichen, obwohl sie nicht darstellbar sind. Aber alle Integer-Typen sind zum Rechnen da und nicht zum Versenden über Datenströme. Deswegen auch die Unterscheidung bzgl. Vorzeichen. Nochmal für dich: Eine Anzahl zu versendender Zeichen mit "uint8_t" zu typisieren, IST ausgemachter Bockmist. In diesem Falle wohl von ST verzapft. W.S.
W.S. schrieb: > Nochmal für dich: Eine Anzahl zu versendender Zeichen mit "uint8_t" zu > typisieren, IST ausgemachter Bockmist. Das ist Deine sehr spezifische Sichtweise. Wieso sollte eine UART dafür da sein, nur "Zeichen" zu versenden?
W.S. schrieb: > Eine Anzahl zu versendender Zeichen mit "uint8_t" zu > typisieren, IST ausgemachter Bockmist. Guck mal wie Wikipedia die UART Schnittstelle beschreibt: https://de.wikipedia.org/wiki/Universal_Asynchronous_Receiver_Transmitter Das Wort "Zeichen" kommt in dem gesamten Artikel kein einziges mal vor, dafür aber immer wieder "Daten" und "Bits". Schauen wir mal ins Datenblatt des 16550, der UART Chip aus den PC's mit denen ich aufgewachsen bin: http://www.ti.com/lit/ds/symlink/pc16550d.pdf Dort heisst es mehrmals, daß "Characters" übertragen werden. Ganz links oben steht sogar, dass die Characters 5 bis 8 Bits groß sein können. Das hat mich ein bisschen überrascht. Das Datenblatt verwendet aber auch oft den Begriff "Bytes". So ganz klar ist die Sache wohl nicht einmal der Firma TI. Können wir uns darauf einigen, dass "Zeichen" und "Bytes" bei der UART beide richtig sein können? Auf jeden Fall beschränkt die Schnittstelle sich nicht nur auf Text-Zeichen oder ASCII, da stimmst du W.S. mir sicher auch zu, oder?
Stefanus F. schrieb: > Auf jeden Fall beschränkt die Schnittstelle > sich nicht nur auf Text-Zeichen oder ASCII Eben, die UART kennt keine Typen. Sie kann keinen Quelltext lesen, sondern bekommt am Ende ein Stück Maschinencode. Sie will nur Bytes sehen, egal ob int8_t oder uint8_t oder char im Quelltext steht.
Rufus Τ. F. schrieb: > Wieso sollte eine UART dafür da sein, nur "Zeichen" zu versenden? Herrje - weil ein UART kein Rechenwerk ist, überträgt er eben nur Zeichen. Was du da für Bedeutungen in diese Zeichen legst, ist dem UART völlig egal. Integer-Größen sind nur für Rechenwerke da, die damit irgend etwas machen, was man unter Rechnen, Abzählen, Indexieren und so einordnen kann. Ein UART ist zum Transferieren von DATEN gedacht. Egal, ob das nun 8 oder 7 oder 6 Bit breite Daten sind, ebenso auch egal, ob das nun ASCII oder TTY oder sonstwas ist. Die 5..8 Bit sind ein Container, für dessen inhaltliche Dinge (Vorzeichen usw.) sich ein UART einen Dreck schert. Natürlich könnte man auch eine double oder einen 12 Bit umfassenden ADC-Wert per UART verschicken, wenn man ihn einfach in passende Stücke zerhackt. Lerne doch endlich einmal, zu unterscheiden zwischen numerischen Größen wie integer, float usw. auf der einen Seite und nichtnumerischen Größen wie Textzeichen und allgemeinen Daten (z.B. ein Pixel auf deinem Display) auf der anderen Seite. Stefanus F. schrieb: > Können wir uns darauf einigen, dass "Zeichen" und "Bytes" bei der UART > beide richtig sein können? Nein, eigentlich NICHT. Denn wie ich das bisher vergeblich dem Rufus klarzumachen versucht habe, transportiert ein UART eben Daten und das völlig ungeachtet deren inhaltlicher Bedeutung. Und der Grundtyp für Daten ist in C eben der char. Natürlich kann ein UART 8 Bit breite Zeichen übertragen und damit auch Bytes als solche übertragen. Man kann damit auch double übertragen, siehe oben. Aber zu sagen, man überträgt damit per UART ein double, ist grundfalsch. Es sind bloß 8 Bit breite Zeichen, deren Bedeutung man nur dann kennt, wenn man die zuvorige Zerlegung kennt. Aber das ist nicht Sache des UART's. Also nochmal: ein char ist ein allgemeiner Datentyp, eben ein Zeichen - in was für einem Alphabet oder Codetafel oder Bedeutung auch immer. Ein Byte hingegen ist ein numerischer Typ zum Durchführen von Berechnungen. Das ist ein Unterschied. W.S.
W.S. schrieb: > Lerne doch endlich einmal, zu unterscheiden zwischen numerischen Größen > wie integer, float usw. auf der einen Seite und nichtnumerischen Größen > wie Textzeichen und allgemeinen Daten Du solltest mit gutem Beispiel vorangehen, denn genau das tust Du nicht, Du vermengst munter Zeichen und "allgemeine Daten". > Es sind bloß 8 Bit breite Zeichen, deren Bedeutung man nur dann kennt, > wenn man die zuvorige Zerlegung kennt. Aber das ist nicht Sache des > UART's. Keine "Zeichen". Bytes. Und deswegen eben nicht "char", sondern uint8_t. Die Diskussion können wir allerdings abbrechen, ich weiß, daß es komplett sinnlos ist, zu versuchen, mit Dir hier zu einem Ergebnis zu kommen, zumal Du bekanntlich auch die C99-Datentypen à la "uint8_t" etc. ablehnst.
W.S. schrieb: > Nochmal für dich: Eine Anzahl zu versendender Zeichen mit "uint8_t" zu > typisieren, IST ausgemachter Bockmist. Einem UART ist es völlig schnuppe, welchen Datentyp dein Compiler dem Byte zuordnet. Der UART sendet das Byte so, wie du es ihm anreichst.
Zeichen sind für mich Buchstaben, Ziffern, Satzzeichen und evtl. Steuerzeichen. Also eine Untermenge von Daten. Die Zeichen sind in Zeichensätzen definiert. Da steht zum Beispiel, daß das Byte 0x20 ein Leerzeichen ist. Ein Beispiel für häufig übertragene Daten wäre z.B ein digitaler Schlüssel. Den kann man nicht auf einem Drucker ausgeben, weil er eben nicht aus Textzeichen besteht. Ein anderes Beispiel sind die Daten, die mein Oszilloskop an den PC sendet. Auch diese lassen sich sich nicht direkt als Text darstellen, weil es Ansammlungen von Bytes sind - nämlich ganz banal die Messwerte des ADC. Zeichensätze spielen bei diesen Daten keine Rolle. Ohne Zeichensatz sind es keine Zeichen, sondern anders codierte Daten.
@W.S. schade, daß du irgendwann aufgehört hast zu lernen. char ist nicht mehr eindeutig, da es inzwischen bereits UTF-16 gibt, und da ist ein char eben nicht mehr nur 8bit breit. uint8_t trifft es viel eher, da ein Byte nunmal kein Vorzeichen kennt. Seit C99 ist unint8_t einem char immer vorzuziehen. Daß char im stdlib weiter genutzt wird dient nur der Kompatibilität mit altem Code. Würde man das heute ändern könnte man tausende von älteren Programen nicht mehr fehlerfrei bauen.
Bondu schrieb: > > Eben, die UART kennt keine Typen. Sie kann keinen Quelltext lesen, > sondern bekommt am Ende ein Stück Maschinencode. Sie will nur Bytes > sehen, egal ob int8_t oder uint8_t oder char im Quelltext steht. Yep. Außer daß bei char nicht gerantiert ist, daß das 8 Bit sind. Der Standard schreibt nur vor, daß es mindestens 8 Bit sein müssen. Es gibt aber Plattformen, bei denen ist ein char 16 Bits und sogar welche da ist ein char 32 Bits lang. Leider, leider haben K&R die Grunddatentypen von C nur sehr schwammig festgelegt. Int als "natürliche" Zahlengröße ... da kann man buchstäblich alles beliebige rein interpretieren. Andererseits ist es mindestens 16 Bit lang, was auf 8-Bit Architekturen alles andere als "natürlich" ist. Es hat 27 Jahre gedauert, bis mit C99 die Datentypen mit genau definierter Breite standardisiert wurden. Und jetzt, nachdem wir diese Typen endlich haben, werden wir einen Teufel tun und W.S. fragen, ob wir sie an einer Stelle, wo sie perfekt passen, auch verwenden dürfen. Altersstarrsinn ist nicht lustig. OK, vielleicht wenn man ihn selber hat. Kann ich (hoffentlich? noch) nichts zu sagen. Ich werde mich selber weiter beobachten und berichten.
:
Bearbeitet durch User
Ich hab so den Eindruck, ihr diskutiert am Problem des TO vorbei. Er hat Daten mit dem Typ int8_t und seine vorhandene UART-Funktion will den Typ uint8_t. Zugegeben, ich weiß nicht, ob dabei der Compiler nur eine Warnung ausgibt oder ob mehr passiert. Er will wohl nur wissen, wie er das sauber löst.
HildeK schrieb: > Ich hab so den Eindruck, ihr diskutiert am Problem des TO vorbei. > Er hat Daten mit dem Typ int8_t und seine vorhandene UART-Funktion will > den Typ uint8_t. > Zugegeben, ich weiß nicht, ob dabei der Compiler nur eine Warnung > ausgibt oder ob mehr passiert. Er will wohl nur wissen, wie er das > sauber löst. Nur eine Warnung...
Beitrag #5710447 wurde von einem Moderator gelöscht.
Du laberst Stuss und machst dir das leben unnötig schwer. Im Hterm wirst du -4 nicht eingeben, da es dafür gar keine Tasten-Kombination gibt - wozu auch? Ansonsten ist das alles vollkommen transparent. Dem UART ist es vollkommen egal, ob deine 0c11111011 als -4, 0xfb oder 251 interpretiert werden. Der sendet genau das 8bit-Wort, das du ihm verordnest. Dein Problem scheint mir eher C und der Umgang mit Typen und deren Konvertierung zu sein.
HildeK schrieb: > Ich hab so den Eindruck, ihr diskutiert am Problem des TO vorbei. > Er hat Daten mit dem Typ int8_t und seine vorhandene UART-Funktion will > den Typ uint8_t. > Zugegeben, ich weiß nicht, ob dabei der Compiler nur eine Warnung > ausgibt oder ob mehr passiert. Er will wohl nur wissen, wie er das > sauber löst. Man kann alles zurecht casten. Dafür sind Type Casts da. :-)
klaus schrieb im Beitrag #5710447: > Das erkenne ich auch am MSB. > Dass es eine neg Zahl ist. > Wenn ich die int8_t Zahl -4 die kommt einfach der uart fkt uebergeben > koennte waere das ja kein Problem. > Aber das kann ich ja nicht. Doch, kannst Du. Mit einem Cast. Zum Beispiel so:
1 | int8_t zahl = -1; |
2 | |
3 | HAL_USART_Transmit(husart, (uint8_t*)&zahl, 1, timeout); |
klaus schrieb im Beitrag #5710447: > Im HTerm kann ich ja auch nicht einstellen dass ich int8_t schicke. Aber du kannst dir das in Hex und auch Binär anzeigen lassen. > Und > alles von binaer auf dez umrechnen hab ich auch keine lust Dann schreib für den PC ein eigenes Programm dafür. Dazu reicht eine Scripsprache deiner Wahl.
HildeK schrieb: > ich weiß nicht, ob dabei der Compiler nur eine Warnung > ausgibt oder ob mehr passiert. Harry L. schrieb: > Nur eine Warnung... Wenn überhaupt. Arduino unterdrückt zum Beispiel alle Warnungen per Default - was dort von zahlreichen Libraries (schamlos) ausgenutzt wird. klaus schrieb im Beitrag #5710447: > Im HTerm kann ich ja auch nicht einstellen dass ich int8_t schicke Links vom Eingabefeld ist die entsprechende Select-Box. Wenn du da zum Beispiel DEC einstellt, kannst du Dezimalzahlen senden. Und über dem Ausgabefenster kannst du die Darstellung von empfangenen Daten einstellen. Dort ist "Ascii" (also Text) die Vorgabe, kannst du aber auch gerne auf "Dec" umstellen. Allerdings sind das alles unsigned Zahlen. Die Umrechnung von signed zu unsigned müsstest du manuell machen. Das ist aber keine Einschränkung der Schnittstelle, sondern eine Frage der Darstellung im Hterm. Der Autor hätte Support für "signed" Typen durchaus hinzufügen können. Vermutlich hat er das selbst noch nicht gebraucht und daher nicht implementiert.
Mark B. schrieb: > Man kann alles zurecht casten. Dafür sind Type Casts da. :-) Was macht ein Cast von int8 (z.B. beim Wert -10) auf uint8 aus diesen -10? 0xF6 und gut? Und beim Empfänger muss er aus den 0xF6 wieder casten auf int8. Sind das dann auch wieder die -10? Wenn ja, dann ist es gut! Meines Erachtens sind das die Fragen, die er beantwortet haben will. Ich kann es nicht sicher sagen, ich vermeide Casts, wo immer es geht.
HildeK schrieb: > Was macht ein Cast von int8 (z.B. beim Wert -10) auf uint8 aus diesen > -10? 0xF6 und gut? Ja genau. Kann man hier gut ausprobieren: http://www.binaryconvert.com/result_signed_char.html?decimal=045056 > Und beim Empfänger muss er aus den 0xF6 wieder casten auf int8. > Sind das dann auch wieder die -10? So ist es. > Wenn ja, dann ist es gut! Du siehst, dass die Schnittstelle einfach nur die 8 Bits überträgt, egal wie sie interpretiert und dargestellt werden.
HildeK schrieb: > Was macht ein Cast von int8 (z.B. beim Wert -10) auf uint8 aus diesen > -10? 0xF6 und gut? Dieser Cast ändert nichts am Bitmuster sondern sagt dem Compiler nur, dass du weißt, das da eine Typänderung ist Bei anderen Casts wird auch umgewandelt. > Und beim Empfänger muss er aus den 0xF6 wieder casten auf int8. Sind das > dann auch wieder die -10? Wenn ja, dann ist es gut! Wenn der Empfänger dasselbe Zahlenformat benutz, ja. Allerdings ist bei deinem Problem ein Cast von int8_t* auf uint8-t* (Das sind Pointer) Da wird garnichts umgewandelt.
Beitrag #5710702 wurde von einem Moderator gelöscht.
klaus schrieb im Beitrag #5710702: > Das sind Zahlen, die der uC ausliest im Bereich von -400 bis +400. Diese > Zahlen möchte ich in einem Diagramm auswerten, also eine Grafik > erstellen. > Die Zahlen kommen zB aus einem Kanal á la > 0 > -4 > -10 > 80 > -11 > 220 > 300 > 380 > 0 > -20 > 300 > 0 > 400 > > Ich weiss also nicht, was gerade gelesen wird, nur dass es Werte sind > zwischen -400 und 400. Nicht darunter, nicht darüber. Demnach brauche > ich also sogar ein int16_t statt int8_t. > Jetzt geht es mir darum, diese Zahlen der Reihe nach über die Uart and > eine USB Schnittstelle zu schicken, sodass ich sie an einem COM Port > lesen kann. Es gibt keinen Empfänger, der die Zahlen richtig > interpretiert! Mit Verlaub, aber Du widersprichst Dir selbst. Natürlich gibt es einen Empfänger, der diese gesendeten Zahlenwerte richtig interpretieren muss: Nämlich der Code bzw. das Programm, welches die Zahlenwerte grafisch darstellen soll. > Meine Fresse ist das mühsam mit den Leuten... Dieses Kompliment können wir freilich an Dich zurückgeben. Die Aufgabenstellung richtig und anständig zu beschreiben ist Deine Aufgabe, nicht unsere.
Mark B. schrieb: > > Mit Verlaub, aber Du widersprichst Dir selbst. > > Natürlich gibt es einen Empfänger, der diese gesendeten Zahlenwerte > richtig interpretieren muss: Nämlich der Code bzw. das Programm, welches > die Zahlenwerte grafisch darstellen soll. > >> Meine Fresse ist das mühsam mit den Leuten... > > Dieses Kompliment können wir freilich an Dich zurückgeben. Die > Aufgabenstellung richtig und anständig zu beschreiben ist Deine > Aufgabe, nicht unsere. Nach HTerm kommt nichts mehr, ich habe da kein weiteres Programm, das die Zahlen weiterverarbeitet. Ich kopiere mir dann die Zahlen direkt aus dem HTerm per STRG+C und füge sie im Excel ein. Bei 4000 Werten hab ich dann keine Zeit, noch zu überprüfen, wo jetzt binär immer eine 1 im MSB steht und dann im Excel an der entsprechenden Stelle ein - hinzuzufügen.
klaus schrieb im Beitrag #5710702:
> Meine Fresse ist das mühsam mit den Leuten...
Den Eindruck habe ich auch.
Du verwechselst nach wie vor druckbare Zeichen, die dir HTerm zeigen
kann und Zahlen in Binärdarstellung.
Du musst einen Puffer deklarieren, der für deine größte Zahl in
druckbarer Form groß genug ist.
char buffer[5]; wäre ausreichend für Vorzeichen, drei Stellen und das
Stringende-Zeichen. Besser wäre, auf Sicherheit zu gehen und für 5
Stellen Platz zu machen. Die paar Bytes hast du über. Also buffer[17]
(warum 17? weil itoa() laut Handbuch maximal so viel Platz braucht.
Eigentlich sollten 7 reichen. Druckfehler? Länger schadet aber nicht).
Als nächstes wandelst du deine Zahl von binär nach ASCII.
itoa(zahl, buffer, 10);
In Buffer steht nun zahl in einer lesbaren Form und kann mit deiner UART
Funktion verschickt werden. Als Länge musst du aber hier nicht 1 angeben
sondern strlen(buffer).
Dann musst du dir ein Protokoll überlegen. Das einfachste wird sein, die Daten als menschenlesbar zu senden. -4 wären dann die Zeichen'-' und'4'. Dazu kommt noch ein Trennzeichen. Das kann ein Komma, Semikolon oder auch '\n' sein. Du kannst auch die Kanalnummer davor setzen. 1:-4 2:20 3:10 5:80 1:99
Aja, jetzt kommen wir der Sache schon näher. Was du brauchst ist ein Übertragungsprotokoll, dass die Daten der Quellen zusammen führt (Multiplext) in einen Strom von Bytes (oder Zeichen) umwandelt und auf der Empfängerseite wieder auseinander dröselt (Demultiplext). Eine gängige Variante wäre die Umwandlung in ein CSV Format. Wenn deine 5 Kanäle jeweils wiederholt die Zahlen 100 bis 500 liefern würden, könnte der Strom von Zeichen so aussehen:
1 | 100,200,300,400,500\n |
2 | 100,200,300,400,500\n |
3 | 100,200,300,400,500\n |
4 | 100,200,300,400,500\n |
Jede Reihe enthält 5 Werte von den 5 Sensoren. Die Umwandlung von Zahlen in dieses Protokoll machst du mit printf:
1 | char buffer[100]; |
2 | |
3 | for (;;) // repeat forever |
4 | {
|
5 | int16_t a=read_sensor(1); |
6 | int16_t b=read_sensor(2); |
7 | int16_t c=read_sensor(3); |
8 | int16_t d=read_sensor(4); |
9 | int16_t e=read_sensor(5); |
10 | |
11 | int len=sprintf(buffer,"%i,%i,%i,%i,%i\n",a,b,c,d,e); |
12 | HAL_USART_Transmit(husart, buffer, len, timeout); |
13 | |
14 | HAL_DELAY(1000); |
15 | }
|
Auf der Empfängerseite musst du diesen Datenstrom Zeilenweise einlesen und Parsen. Dazu könnte die Funktion scanf() hilfreich sein. Jetzt hast du Stichworte zum googeln: Multiplexen, Demultiplexen, Übertragungsprotzokoll, CSV, sprintf, scanf
Beitrag #5710752 wurde von einem Moderator gelöscht.
Eine andere Möglichkeit wäre binäre Übertragung. Im einfachsten Fall trennst du die Pakete durch eine Pause:
1 | int16_t paket[5]; |
2 | |
3 | for (;;) // repeat forever |
4 | {
|
5 | paket[0]=read_sensor(1); |
6 | paket[1]=read_sensor(2); |
7 | paket[2]=read_sensor(3); |
8 | paket[3]=read_sensor(4); |
9 | paket[4]=read_sensor(5); |
10 | |
11 | HAL_USART_Transmit(husart, (uint8_t*) &paket, 10, timeout); |
12 | |
13 | HAL_DELAY(1000); |
14 | }
|
Das kannst du in einem Terminalprogramm aber nicht mehr einfach so mitlesen, weil es eben kein Textbasiertes Format ist.
Georg G. schrieb: > klaus schrieb: >> Meine Fresse ist das mühsam mit den Leuten... > > Den Eindruck habe ich auch. > Du verwechselst nach wie vor druckbare Zeichen, die dir HTerm zeigen > kann und Zahlen in Binärdarstellung. > > Du musst einen Puffer deklarieren, der für deine größte Zahl in > druckbarer Form groß genug ist. > char buffer[5]; wäre ausreichend für Vorzeichen, drei Stellen und das > Stringende-Zeichen. Besser wäre, auf Sicherheit zu gehen und für 5 > Stellen Platz zu machen. Die paar Bytes hast du über. Also buffer[17] > (warum 17? weil itoa() laut Handbuch maximal so viel Platz braucht. > Eigentlich sollten 7 reichen. Druckfehler? Länger schadet aber nicht). > > Als nächstes wandelst du deine Zahl von binär nach ASCII. > itoa(zahl, buffer, 10); > > In Buffer steht nun zahl in einer lesbaren Form und kann mit deiner UART > Funktion verschickt werden. Als Länge musst du aber hier nicht 1 angeben > sondern strlen(buffer). Hallo Georg, Danke für deinen Tipp. Ich hätte jetzt eine Funktion gemacht, der ich als Parameter einen int16_t übergebe. Bei 0 eine 0 schicken (1 Zeichen) Bei positiver Zahl -> nur zerhacken in einzelne Zeichen und schicken. Bei negativer Zahl-> Überprüfung mit dem Negativen gemacht und und die Zahl so zerhackt, dass ich die einzelnen Ziffern bekomme. Alles hätte ich dann in ein char Array gegeben und mit der HAL Uart herausgeschickt. Aber deinen Ansatz finde ich noch effizienter. Ich versuche den Ansatz von dir gleich mal am Montag umzusetzen. Vielen Dank
klaus schrieb: > int16_t übergebe. > Bei 0 eine 0 schicken (1 Zeichen) > Bei positiver Zahl -> nur zerhacken in einzelne Zeichen und schicken. > Bei negativer Zahl-> Überprüfung mit dem Negativen gemacht und und die > Zahl so zerhackt, dass ich die einzelnen Ziffern bekomme. > Alles hätte ich dann in ein char Array gegeben und mit der HAL Uart > herausgeschickt. Das macht ja schon printf. bzw sprintf. Seitdem es C gibt.
Beitrag #5710787 wurde von einem Moderator gelöscht.
Beitrag #5710818 wurde von einem Moderator gelöscht.
Beitrag #5710843 wurde von einem Moderator gelöscht.
Beitrag #5710878 wurde von einem Moderator gelöscht.
klaus schrieb: > Wie funktioniert das bei ST, wenn die Funktion nur ein uint8_t* entgegen > nimmt? > > HAL_StatusTypeDef HAL_USART_Transmit(USART_HandleTypeDef *husart, > uint8_t *pTxData, uint16_t Size, uint32_t Timeout) Dein eigentliches Problem ist doch: Wie kann ich einen vorzeichenbehafteten 16 Bit Wert mit der o.g. Funktion senden, so dass ich ihn als Mensch (im Terminal) lesen kann? wann hast du diese Frage gestellt? Wir haben deine gestellte Frage beantwortet. Die Glaskugeln um das eigentliche Problem zu sehen, gibt es nicht.
:
Bearbeitet durch User
Mir fällt gerade was auf:
> Übertragungsprotzokoll
Was ist das denn?
@ Klaus Es scheint mir wichtig auf Folgendes hinzuweisen: Man kann in C einen Datentyp gar nicht anders als mit irgendeinem der vordefinierten oder davon abgeleiteten Typen beschreiben. Sprich: Irgendwas MUSS man da hin schreiben. Es gibt keinen generischen Typ, der zwar Bits im Speicher umfasst, aber keiner Interpretation unterliegt. Das einzige was halbwegs in die Nähe dieser Eigenschaften kommt, ist der Typ 'void'. Aber Variablen oder Rückgaben dieses Typs haben keinen Wert und nehmen keinen Speicherplatz ein; lassen sich nicht als Operanden irgendeiner Operation im engeren Sinn verwenden. (In C ist der Begriff "Operation" weiter gefasst und umfasst, grob gesagt, auch mathematische Operationen; aber nicht nur). Jedenfalls muss man irgendwas hinschreiben, wenn man einen Wert an eine Funktion übergibt. Das ist für eine Übertragung nicht von Bedeutung. (Das wurde ja hier auch schon gesagt). Aber warum ist das nicht von Bedeutung, wie läuft das im Detail praktisch ab? Der Vorgang, oder besser, der Modus, einen eigentlich als vom Typ int8_t beschriebenen Wert, als uint8_t "anzusehen" kann in C auf zwei Arten ausgedrückt werden, wobei nur eine Art die Daten, - als Bitmuster -, und in Bezug auf die Operationen tatsächlich verändert. (Es gibt da mehrere Varianten, allem voran der Umwandlungsoperator "()", siehe auch "Integer-Erweiterung", "implizite Umwandlungen"; lies das mal selbst nach, bitte). Wichtig ist hier: Die Umwandlungen von Zeigern zwischen Zeigern auf verschiedene Typen, sind die Methode die Interpretation zu ändern ohne dabei die Daten, das Bitmuster, zu ändern. Das Bitmuster, dass vom Typ int8_t ist, und auf das man einen Zeiger hat (also int8_t *), wird bei der Umwandlung in einen Zeiger auf uint8_t nicht verändert! Es ist klar, dass der neu interpretierte Wert, bei der Anwendung von Operationen, anders aussieht. Z.B. werden Summen, Produkte etc. von diesem Wert andere Ergebnisse haben, vergleicht man sie mit den Summen, Produkten etc. bei denen der Wert auf die ursprüngliche Weise interpretiert wird. Aber das ist, wie schon erwähnt, bei der Übertragung unwesentlich, weil bei der Übertragung das Bitmuster nicht interpretiert wird. Es wird einfach nur Bit für Bit übertragen, egal was die Bits bedeuten mögen. Auf der Empfängerseite muss die ursprüngliche Interpretation wieder hergestellt werden. Sendet man ein int8_t durch Umwandlung mittels einer Funktion die uint8_t Zeiger erwartet, dann muss auf der Empfängerseite, der als uint8_t interpretierte Wert wieder als int8_t interpretiert werden, was seinerseits wieder eine Interpration als int8_t erlaubt - also die ursprüngliche Interpretation auf Senderseite. Was auf Senderseite das Vorzeichenbit ist, wird zwar durch die Uminterpretation als Zeiger auf uint8_t zu einem Bit, dass einen quantitativen Wert hat (nämlich 2^8 = 128), aber in dieser Eigenschaft wird es beim Sendevorgang (auch innerhalb des Sende- oder Empfangsfunktion) selbst überhaupt nicht betrachtet und auch nicht verändert. Zur Verdeutlichung skizzierte ich hier den Code auf der Sender- und Empfängerseite: Sender
1 | sende (uint8_t * data); |
2 | |
3 | int8_t ZuSenden; |
4 | |
5 | sende ((uint8_t *) & ZuSenden); |
Empfänger:
1 | uint8_t empfange (); |
2 | |
3 | int8_t Empfangen; |
4 | |
5 | Empfangen = * ((int8_t *) Empfangen ()); |
Eine Umwandlung einer vorzeichenbehafteten Zahl in die Repräsentation als ASCII-Zeichen ist also nicht notwendig. (Es gibt andere Zusammenhänge, speziell bei der Übertragung von Daten, in denen das sinnvoll ist, aber jedenfalls liegt der Grund dafür nicht in einem Unterschied der Typen). Ich hoffe, das hilft Dir etwas weiter. Viel Erfolg.
Theor schrieb: > Es gibt keinen generischen Typ, der zwar Bits im Speicher umfasst, aber > keiner Interpretation unterliegt. > Das einzige was halbwegs in die Nähe dieser Eigenschaften kommt, ist > der Typ 'void'. Aber Variablen oder Rückgaben dieses Typs haben keinen > Wert und nehmen keinen Speicherplatz ein; lassen sich nicht als > Operanden irgendeiner Operation im engeren Sinn verwenden. Glücklicherweise wird der Funktion aber nicht ein Wert, sondern ein Zeiger und eine Anzahl an Bytes übergeben, und einen Zeiger auf void kann man durchaus genau in der Art verwenden, wie es z.B. memcpy() oder frwrite() ja auch machen. Ein void* ist genau dafür da: Ein generischer Zeiger auf Daten, die an dieser nicht interpretiert werden sollen. Warum ST hier stattdessen einen uint8_t* verwendet, ist nicht so ganz klar.
Dirk B. schrieb: > Allerdings ist bei deinem Problem ein Cast von int8_t* auf uint8-t* (Das > sind Pointer) Ich hatte keine Pointer, ich bin auch nicht der TO. Nur war mir nicht ganz klar, ob die Casterei von einem uint8 in einen int8 und zurück keine Probleme macht. Offenbar nicht, das entnehme ich den Antworten und war mein Lernerfolg hier ... klaus schrieb im Beitrag #5710702: > Du bist meiner Meinung nach der Einzige hier im Forum, der nicht irgend > ein Stuss von sich gibt und der Einzige, der etwas versteht. Nein, das ist sicher so nicht richtig. > Ich danke dir übrigens für deine Erklärung, aber es ist nicht das > Problem. Ok. Dann habe ich dein Problem einfach nicht verstanden und sollte mich eigentlich raus halten. :-) > Das sind Zahlen, die der uC ausliest im Bereich von -400 bis +400. Diese > Zahlen möchte ich in einem Diagramm auswerten, also eine Grafik > erstellen. Vielleicht habe ich es übersehen, aber 'int16' war mir bisher nicht aufgefallen. Eine Möglichkeit, die ich in dem Fall mir überlegen würde: eine 'union' aus dem int16 und einem 2 Byte char-String. Dann kann man einfach die beiden char-Zeichen des Strings einzeln nacheinander senden. Beim Empfänger wieder eine 'union' und da die empfangenen 'chars' reinschreiben und den int16 weiterverarbeiten. Da wäre der Empfänger aber z.B. ein zweiter µC, kein Terminal. Zu weiter oben: Wenn nur ein Terminal Empfänger ist und z.B. -4 anzeigen soll, dann musst du ihm zwei Zeichen schicken, ein '-' und eine '4'. Das geht mit jedem. Also, der Vorschlag, den int8- oder int16-Inhalt vorher in ASCII umzuwandeln, also z.B. die 400 in drei Zeichen '4', '0', '0' ist dann der einzige Weg, der imho bleibt. itoa oder sprintf fallen mir dazu ein.
HildeK schrieb: >> Das sind Zahlen, die der uC ausliest im Bereich von -400 bis +400. Diese >> Zahlen möchte ich in einem Diagramm auswerten, also eine Grafik >> erstellen. > > Vielleicht habe ich es übersehen, aber 'int16' war mir bisher nicht > aufgefallen. Ja, das ist mal wieder eine dieser Fragen, wo der Fragesteller erstmal nach was ganz anderem fragt, als er will, um dann langsam schrittweise zu verraten, nach was er in Wirklichkeit sucht.
<seufz> Was für ein Mörder-Thread für so einen Trottel. Jeder, der schon mal auch nur halbwegs damit zu tun hatte, weiß daß man über eine UART Verbindung tunlichst formatierte (Text)daten schickt und keine rohen int16_t oder ähnliches. Erst recht wenn der Empfänger (sic!) ein Terminalprogramm ist. Die genannten je 5 Datenwerte aus dem Bereich -400 .. +400 würde man zweckmäßigerweise in dezimale Strings konvertieren und dann geschickt eingerückt (notfalls mit Tabulator getrennt) zeilenweile über den UART an den PC schicken. Zeilenweise heißt, daß man nach jedem Datensatz ein CR (\r) und LF (\n) schickt. Und die Zahlen konvertiert man nicht per cast, sondern mit den Konvertierungsfunktionen der libc (sprintf(), itoa() etc.) Derart formatierte Daten sind dann nicht nur menschenlesbar, auch Programme könn(t)en damit etwas anfangen. Und durch die zeilenweise Struktur findet man den Einstieg auch dann, wenn man den Anfang verpaßt haben sollte.
HildeK schrieb: > Eine Möglichkeit, die ich in dem Fall mir überlegen würde: eine 'union' > aus dem int16 und einem 2 Byte char-String. Dann kann man einfach die > beiden char-Zeichen des Strings einzeln nacheinander senden. Keine union. Das kannst du einfach mit shiften und maskiern machen. Der Compiler optimiert das schon (wenn er darf) Das ist portabel und man braucht auch nicht auf die Endianes vom System achten. (man muss nur wissen, welches Byte zuers5 gesendet wird)
Stefanus F. schrieb: > Mir fällt gerade was auf: >> Übertragungsprotzokoll > > Was ist das denn? Eine Vereinbarung, wie die Daten zu übertragen, bzw. die empfangenen Daten zu interpretieren sind. Z.B ein Datensatz wird mit '\n' abgesclossen. innerhalb eines Satzes werden die Daten mit ',' getrennt.
Rolf M. schrieb: > Theor schrieb: >> Es gibt keinen generischen Typ, [...] > > Glücklicherweise wird [...] Ich habe Respekt vor Deinen menschlichen und fachlichen Qualitäten, Rolf, wie ich sie hier im Forum meine erkennen zu können: Ich denke aber, Du hast meinen inhaltlichen und didaktischen Ansatz nicht verstanden und machst deswegen diese Einwendung. Als Einwendung meine ich Deinen Text jedenfalls verstehen zu sollen. --- An sich hat void * etwas für sich und ist in verschiedener Hinsicht überlegenswert. Allerdings wird man dann doch irgendwann auf den Punkt kommen, dass man dem Senderegister einen konkreten Wert übergeben muss. Und den kann man nicht ausschliesslich mit '*' dereferenzieren, wenn der Zeiger auf void zeigt. Da wird dann doch ein uint8_t oder etwas ähnliches stehen müssen! Eben weil void keinen Wert hat. Dein Vorschlag begreift das Problem, meine ich, in diesem Licht zwar auch als eines der Interpretation von Werten, aber er beschreibt die Lösung vornehmlich als eine Variante des Programmtextes, - also wo im Quellcode man die Umwandlung in konkrete Werte macht -, (was Du aber nicht zu Ende ausführst, wie ich im vorherigen Absatz dargelegt habe) -, während ich, meiner Ansicht nach, den TO dort abhole wo er ist, - in dem die Umwandlung eben genau in dem zitierten Programmtext stattfindet -, und der dazu formulierten Frage. Ich denke, man sollte den TO in diesem Fall nicht erklären, dass "man" das sowieso nicht so macht. Jedenfalls nicht, falls es sich nicht direkt aus der Frage ergibt. (So ganz unstrittig ist das, meiner Ansicht nach, sowieso nicht, wenn man die oben erwähnte "letzte Zuweisung an das Datenregister" bedenkt). Das Stichwort "void" gibt ihm einen Ansatzpunkt zum selber weiter forschen; die Erklärung dazu wird jemanden mit etwas Phantasie auf die Idee bringen, die Du skizziert hast. Ich werde den Durstigen zeigen wie Wasser aussieht und lehren wie man es findet, aber ihn nicht zu jeder Pfütze einzeln führen - vor allem wenn das Wasser möglicherweise von bedenklicher Qualität ist. :-)
@ Rolf @ Klaus Naja. Wobei sich ja inzwischen herausstellt, dass das Ausgangsproblem ja eigentlich ein Anderes ist. Dann hat sich das ja von selbst erledigt. :-)
klaus schrieb: > wenn die Funktion nur ein uint8_t* klaus schrieb im Beitrag #5710702: > Was für Idioten zum Teil hier sind ist beachtlich. stimmt, einer will int8_t und viel später soll klaus schrieb im Beitrag #5710702: > 220 > 300 > 380 reinpassen, 1. weiss man das vorher dann nimmt man nicht int8_t 2. kann man per ASCII übertragen im Klartext klaus schrieb im Beitrag #5710702: > Ich weiss also nicht, was gerade gelesen wird, nur dass es Werte sind > zwischen -400 und 400. Nicht darunter, nicht darüber. Demnach brauche > ich also sogar ein int16_t statt int8_t. und wenn du statt int irgendwas Klartext überträgst weiss es jeder. Rolf M. schrieb: > Ja, das ist mal wieder eine dieser Fragen, wo der Fragesteller erstmal > nach was ganz anderem fragt, als er will, um dann langsam schrittweise > zu verraten, nach was er in Wirklichkeit sucht. so siehts aus, entweder Troll oder ungeeignet für die Aufgabe.
Joachim B. schrieb: > so siehts aus, entweder Troll oder ungeeignet für die Aufgabe. Bingo. Wobei jeder als Programmieranfänger erst mal ungeeignet ist. Dann arbeitet man eben ein entsprechendes Buch und/oder Tutorial über die Grundlagen durch. Sonst stochert man ja doch nur im Nebel herum.
Beitrag #5711503 wurde von einem Moderator gelöscht.
Beitrag #5711516 wurde von einem Moderator gelöscht.
Beitrag #5711519 wurde von einem Moderator gelöscht.
Hey, hey, ich glaub, ich werd' noch 'n Fan von dir! ( Daniel, Frank, Klaus....)
Beitrag #5711528 wurde von einem Moderator gelöscht.
Beitrag #5711542 wurde von einem Moderator gelöscht.
Beitrag #5711563 wurde von einem Moderator gelöscht.
Beitrag #5711582 wurde von einem Moderator gelöscht.
Beitrag #5711586 wurde von einem Moderator gelöscht.
Beitrag #5711623 wurde von einem Moderator gelöscht.
Ach, ihr seid zwar inzwischen ja doch bei der menschlich lesbaren
Zeichenkette ("char"acters) angekommen, aber ihr diskutiert immer noch?
Tja, ich hab's euch ja ganz weit oben bereits gesagt:
int8_t --> Zeichenkette --> und raus zum UART.
Geht auch mit allen anderen numerischen Größen.
Axel S. schrieb:
> Jeder, der schon mal
> auch nur halbwegs damit zu tun hatte, weiß daß man über eine UART
> Verbindung tunlichst formatierte (Text)daten schickt und keine rohen
> int16_t oder ähnliches.
Du sprichst mir aus dem Herzen. Aber der Rest dieses Threads will
offenbar diskutieren - und da ist jedes Mittel recht.
Gut Nacht, euch allen!
W.S.
Max B. schrieb im Beitrag #5711586:
> Ist das Frank M. Daniel D. Ing. ?
Das kam mir Anfangs auch kurz in den Sinn, aber der Programmiert mit
Arduino. Hier geht es um Ausgabe mit Cube HAL.
Wozu gibt es hier eigentlich Moderatoren, dass sich die sehr hilfreichen und inhaltlich kompetenten User von klaus(gast) dermaßen oft beleidigen lassen dürfen?
Route 6. schrieb: > die sehr hilfreichen > und inhaltlich kompetenten User haben klaus auch als Idiot bezeichnt. Sie haben das nur besser umschrieben.
Beitrag #5711970 wurde von einem Moderator gelöscht.
Beitrag #5711972 wurde von einem Moderator gelöscht.
Beitrag #5711979 wurde von einem Moderator gelöscht.
Dirk B. schrieb: > haben klaus auch als Idiot bezeichnt. > Sie haben das nur besser umschrieben. ach? von mir war es nur ein Beitrag und der zu Recht und ohne Beleidigung Beitrag "Re: int8_t mittels uart schicken" aber Stefanus F. schrieb im Beitrag #5711979: > klaus schrieb: >> Trottel >> Pisser >> Vollpfeifen >> Arsch >> Nichtsnutzen Beitrag "int8_t mittels uart schicken" Beitrag "int8_t mittels uart schicken" Route 6. schrieb: > Wozu gibt es hier eigentlich Moderatoren, dass sich die sehr hilfreichen > und inhaltlich kompetenten User von klaus(gast) dermaßen oft beleidigen > lassen dürfen? gute Frage!
klaus schrieb im Beitrag #5711972: > Richtig, und ich bin nun mal direkt und rede nicht um den heissen Brei > herum. Außer bei Problembeschreibungen.
Beitrag #5712028 wurde von einem Moderator gelöscht.
Ich wäre dafür, den Thread dicht zu machen. Ist eh unwahrscheinlich, dass noch nützliche Antworten kommen, nachdem der TE sich so aufgeführt hat.
Joachim B. schrieb: > Route 6. schrieb: >> Wozu gibt es hier eigentlich Moderatoren, dass sich die sehr hilfreichen >> und inhaltlich kompetenten User von klaus(gast) dermaßen oft beleidigen >> lassen dürfen? > > gute Frage! Einfach Antwort: ignorieren. Den Thread sowieso und am besten auch den Nutzer (was bei anonymen Postern leider nicht so einfach ist). Der Thread ist aber ein schönes Beispiel, warum man nochmal darüber nachdenken sollte ob man das Forum wirklich für anonyme Poster offen lassen will.
Beitrag #5712198 wurde von einem Moderator gelöscht.
Beitrag #5712216 wurde von einem Moderator gelöscht.
Beitrag #5712230 wurde von einem Moderator gelöscht.
Beitrag #5712300 wurde von einem Moderator gelöscht.
Beitrag #5712324 wurde von einem Moderator gelöscht.
Beitrag #5712336 wurde von einem Moderator gelöscht.
Beitrag #5712341 wurde von einem Moderator gelöscht.
Beitrag #5712343 wurde von einem Moderator gelöscht.
klaus schrieb im Beitrag #5712336: > dass es um int7_t zahlen geht von -700 bis > 70500. Ich verzeihe Dir gerne den Tippfehler, aber für Werte bis 70500 brauchst du 32 Bit. > dass ich die Daten doch ueber I2C schicke > anstatt UART... Hat jemand einen Rat? Auch I²C ist Byte-orientiert. Packe das wie gezeigt alles in einen puffer und sende diesen. Wahlweise Binär oder als Text - geht auch dort beides. > und die Regelung schnell erfolgen muss. I²C ist nicht schneller als UART. > Ausserdem habe ich dann nicht mehr das Problem mit den 8 bits > und kann gleich ein ganzes Byte schicken anstatt 8 bits. 8 Bits sind ein Byte, also ganz gewiss kein Problem. Wie ich Dir gezeigt habe, lassen sich auch grössere Integer Typen sowie Text völlig unkompliziert senden. Und jetzt bitte ich um eine Ehrliche Antwort: Trollst du uns?
Beitrag #5712351 wurde von einem Moderator gelöscht.
Beitrag #5712354 wurde von einem Moderator gelöscht.
Beitrag #5712358 wurde von einem Moderator gelöscht.
Klaus, ich frage dich erneut: Trollst du uns? Ich erwarte eine klare Antwort. Oder bist du neben deiner anderen unangenehmen Eigenschaft zudem noch ein Feigling?
Thread beobachten
Seitenaufteilung abschalten