Forum: Mikrocontroller und Digitale Elektronik int8_t mittels uart schicken


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von klaus (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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 Moderator
von foobar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
1
   uint8_t c = 'a';
2
3
   HAL_USART_Transmit(husart, &c, 1, timeout);

von klaus (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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

von Georg G. (df2au)


Bewertung
4 lesenswert
nicht lesenswert
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.

von Zäh Leera (Gast)


Bewertung
3 lesenswert
nicht lesenswert
klaus schrieb:
> Ja, aber ich möchte aber ein int8_t schicken, nicht uint8_t

Dann hast du noch viele Dinge nicht verstanden.

von klaus (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
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.
von Zäh Leera (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Silvano C. (silch12)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Wolfgang (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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?

von Wilma Streit (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Wilma Streit (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Zäh Leera (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Zäh Leera (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
Bei char* würde ich einen C-String erwarten.

Warum nicht void*

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Bondu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
@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.

von Axel S. (a-za-z0-9)


Bewertung
1 lesenswert
nicht lesenswert
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
von HildeK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Harry L. (mysth)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
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. :-)

von Mark B. (markbrandis)


Bewertung
-1 lesenswert
nicht lesenswert
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);

von Dirk B. (dirkb2)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von HildeK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Mark B. (markbrandis)


Bewertung
1 lesenswert
nicht lesenswert
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.

von klaus (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Georg G. (df2au)


Bewertung
2 lesenswert
nicht lesenswert
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).

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Beitrag #5710752 wurde von einem Moderator gelöscht.
von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von klaus (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Ignorierst du mich?

von Dirk B. (dirkb2)


Bewertung
3 lesenswert
nicht lesenswert
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.
von Dirk B. (dirkb2)


Bewertung
3 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Mir fällt gerade was auf:
> Übertragungsprotzokoll

Was ist das denn?

von Theor (Gast)


Bewertung
3 lesenswert
nicht lesenswert
@ 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.

von Rolf M. (rmagnus)


Bewertung
2 lesenswert
nicht lesenswert
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.

von HildeK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Axel S. (a-za-z0-9)


Bewertung
2 lesenswert
nicht lesenswert
<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.

von Dirk B. (dirkb2)


Bewertung
1 lesenswert
nicht lesenswert
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)

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. :-)

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Rolf
@ Klaus

Naja. Wobei sich ja inzwischen herausstellt, dass das Ausgangsproblem ja 
eigentlich ein Anderes ist. Dann hat sich das ja von selbst erledigt. 
:-)

von Joachim B. (jar)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Mark B. (markbrandis)


Bewertung
1 lesenswert
nicht lesenswert
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.
von Volker S. (vloki)


Bewertung
1 lesenswert
nicht lesenswert
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.
von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Route_66 H. (route_66)


Bewertung
4 lesenswert
nicht lesenswert
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?

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Joachim B. (jar)


Bewertung
4 lesenswert
nicht lesenswert
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!

von Dirk B. (dirkb2)


Bewertung
5 lesenswert
nicht lesenswert
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.
von Rolf M. (rmagnus)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
Die Lösung wurde ja auch gefunden.

von Axel S. (a-za-z0-9)


Bewertung
2 lesenswert
nicht lesenswert
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.
von Stefan ⛄ F. (stefanus)


Bewertung
-3 lesenswert
nicht lesenswert
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.
von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Ich wäre dafür, den Thread dicht zu machen.

Ja.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.