www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PC-Tool: float in 4 Bytes (hex) zerlegen


Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich suche ein kleines PC-Programm, dass mir 32-bit float Zahlen in die 4 
Bytes zerlegt, damit ich diese dann über Terminal und serielle 
Schnittstelle an meinen AVR schicken kann.

Sprich:
- ich gebe ein: 12.3456
- und bekomme vom Programm Mantisse und Exponent in 4 Bytes in hex in 
uC-üblichem Format.

Gibt's da was?

Danke & Gruß,
X

Autor: Erol (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es doch online mehrere Tools.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
memcpy(&UnsignedIntVar, &FloatVar, 4)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> - und bekomme vom Programm Mantisse und Exponent in 4 Bytes in hex in
> uC-üblichem Format.
Was ist ein uC-übliches Format?
Und was machst du mit dem Vorzeichen?
Und wie sieht es mit Litte- bzw. Big-Endian (Bytereihenfolge) aus?

> dass mir 32-bit float Zahlen in die 4 Bytes zerlegt, damit ich diese
> dann über Terminal und serielle Schnittstelle an meinen AVR schicken kann.
Sinnvoller ist da eine Übertragung im ASCII-Klartext: 
'1','2','.','3','4','5','6','\n'
Dann kannst du die Daten nämlich ganz einfach mit einem Terminal 
mitlesen.

Autor: Senf-Dazu-Geber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Sinnvoller ist da eine Übertragung im ASCII-Klartext:
>> '1','2','.','3','4','5','6','\n'

Wieso sollte das sinnvoller sein?

So wie er das haben möchte braucht er nur 4 Bytes zu übertragen. Zudem 
kann er sich das "HEX_2_FLOAT" auf dem uC sparen.

Du kennst ja die Applikation dahinter nicht.

Gruss

Autor: Senf-Dazu-Geber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wieso sollte das sinnvoller sein?
Weil es maschinenunabhängig ist.
Weil dann ASCII-Steuerzeichen (STX, ETX,...) verwendet werden können.
Weil man das Ganze dann ganz einfach mit einem Terminal mitlesen kann.
Weil es unabhängig von der Programmiersprache funktionieren wird.

> So wie er das haben möchte braucht er nur 4 Bytes zu übertragen. Zudem
> kann er sich das "HEX_2_FLOAT" auf dem uC sparen.
Hast du schonmal was von little und big endian gehört?
Sind dir die Konsequenzen daraus klar?

> Du kennst ja die Applikation dahinter nicht.
Da geht es mir in etwa wie dir  :-o

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Senf-Dazu-Geber schrieb:

> Du kennst ja die Applikation dahinter nicht.

Prinzipiell richtig.
Wenn es aber schon daran scheitert, sich in 5 Minuten auf dem PC ein 
Programm zu schreiben, welches die Bytes eines float in Hex rausgibt, 
will ich mir die Probleme auf der µC Seite erst gar nicht ausmalen.

Dazu kommt, dass sich Neulinge das gerne so einfach vorstellen: Da 
schick ich die Bytes zum µC und dann passt das schon. Das Erwachen kommt 
dann erst, wenn die Bytes aus dem Bytestrom auseinandersortiert werden 
müssen. Von Protokollfragen haben sie noch nie etwas gehört :-)

Hinweis:
Die Bytes müssen auf µC Seite ja auch wieder zusammengesetzt werden. Und 
das ist prinzipiell einfach nur die Umkehrung der Zerlegung. Kannst du 
sie zusammensetzen, kannst du sie auch zerlegen.

Also: sei nicht so faul und schreib dir das entsprechende Tool selbst. 
Manchmal muss man sich auch einfach nur seine Hilfswerkzeuge selber 
machen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Weil man das Ganze dann ganz einfach mit einem Terminal mitlesen kann.
> http://www.sharewareconnection.com/rs232-monitor.htm
Zählt für mich nicht als Argument.
Denn dieses Programm habe ich garantiert nicht zur Hand, wenn ich es 
unbedingt bräuchte. Einen reinen ASCII-Text kann aber sogar Hyperterm 
mitloggen, jeder beliebiger Editor anzeigen und jedes Comparetool 
vergleichen.

Autor: Senf-Dazu-Geber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lothar Miller
@ Karl heinz Buchegger

Ich bin halt der Meinung, dass man auf Fragen auch direkt antworten kann 
und nicht immer großartig rumdiskutieren muss was besser, schöner, 
toller wäre.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Senf-Dazu-Geber schrieb:
> @ Lothar Miller
> @ Karl heinz Buchegger
>
> Ich bin halt der Meinung, dass man auf Fragen auch direkt antworten kann
> und nicht immer großartig rumdiskutieren muss was besser, schöner,
> toller wäre.

Du bist noch nicht lange im Forum. Stimmts?

Mit der Zeit wirst du merken, dass viele Fragen nach dem Muster sind: 
Ich habe mir da jetzt eine Systematik eingebildet, die ich zwar nicht 
beherrsche und von der ich keine Ahnung habe ob sie sinnvoll ist, die 
ich aber unbedingt aus keinem guten Grund zum Laufen bringen will.

Natürlich kann man auf den Problemkreis eingehen. Aber noch viel öfter 
ist die vernünftigere Antwort die, ganz klar zu sagen:
  Du hast dich da verrannt. Da warten noch Probleme an die du noch
  gar nicht gedacht hast und die (mit deinem jetzigen Kentnisstand)
  alles andere als trivial sind. Wenn du aber deine Systematik
  dahingehend änderst, schiffst du dich um diese ganze Problematik
  elegant drum herum.

  Wenn es also keinen wirklich guten Grund gibt, dann lass dein
  Vorhaben, wie angedacht, fallen und geh über zu Plan B.

Datentransfer auf binärer Bytebene gehört zb in diese Kategorie.
Einzelne Bytes zu übertragen ist nicht weiter schwer. Aber die 
Verallgemeinerung auf ganze Datensätze leider schon, wenn man keine 
dezidierten Bytewerte zur Synchronisation verwenden kann.

Eine ASCII Übertragung vermeidet all das von vorne herein und ist auch 
leichter zu vermitteln. Das eine Eingabe einen Abschluss braucht, kennt 
jeder: An das zeilen-abschliessende 'Return' haben sich alle längst 
gewöhnt und das man sich zwischen 2 Werte irgendein Trennzeichen 
reinmacht (Komma oder dergleichen) ist auch kein Hexenwerk.
Empfangsseitig unterscheidet sich das in nicht viel. Einen 
Empfangsbuffer zum Zwischenspeichern benötigt man in jedem Fall und ob 
der jetzt ein paar Bytes länger ist, spielt auch nicht so die große 
Rolle. Einzig die Umwandlung von ASCII zum eigentlichen Datentyp muss 
man machen. Aber da gibt es ja fertige Funktionen. Und es schadet 
keineswegs, wenn man mit diesen umgehen kann.

Autor: Senf-Dazu-Geber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl heinz Buchegger

Auch wenn ich mich wiederhole:
Du kennst die Applikation dahinter nicht. Daher halte ich es für müssig 
dem Fragensteller Antworten auf nicht gestellte Fragen zu geben. Aber 
das ist nur meine ganz persönliche Meinung.

Gruss

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Senf-Dazu-Geber schrieb:
> @ Karl heinz Buchegger
>
> Auch wenn ich mich wiederhole:
> Du kennst die Applikation dahinter nicht.

Und auch wenn ich mich wiederhole:
Prinzipiell richtig.

Wer allerdings solche Fragen stellen muss, weiß noch gar nicht worauf er 
sich einlässt.
Und diejenigen, die wissen worauf das hinausläuft, müssen konkret diese 
Frage nicht stellen.

Woher ich das weiß:
Aus ein paar zehntausend Anfragen in den letzten Jahren hier im Forum.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist ja was los!

Aaaaalso, floats in ASCII-Format über USART ist kein Problem, das 
betreibe ich schon etwas länger.

Meine jetzige Anwendung erfordert aber, dass mein ATmega64 von einem 
anderen uC (den mache nicht ich) single floats byte-weise über die USART 
bekommt.
Und um das zu testen, wollte ich mir ein paar txt-files basteln, wo die 
floats in die 4 Bytes aufgeteilt sind, und diese über einen Terminal 
(Codevision) rausschicken.

Ich suche also nur einen online Rechner, dem ich sage "gib mir mal die 4 
Bytes aus denen der 32-bit float Wert x besteht".
Empfangen und auswerten mit dem uC sollte kein Problem werden (Counter, 
Timer, Zeiger, casten, etc.)

@ Senf-Dazu-Geber: Ich kucke mir mal den RS232-Monitor an, geht schon in 
die Richtung.

Danke,
X

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmmm, der RS232 Monitor ist nicht schlecht, aber ein einfacher Rechner 
wäre noch toller, dann kann ich die float-bytes in mein Protokoll 
einbauen.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also in der Zeit wo du hier rumhampelst hättest du dir so einen 
"Rechner" schon 10x selbstschreiben können. Wo ist den das Problem? Du 
könntest das Senden sogar über einen weiteren uc der ASCII empfängt und 
"Bytes" sendet lösen wenn dir die 5 Zeilen Programmcode so zu wieder 
sind.
Wenn wir dir jetzt einen Rechner nennen würden, dann hätte der doch 
bestimmt wieder das falsche Format oder einen nicht passende 
Hintergrundfarbe oder doch lieber für MacOS10 statt für Linux...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Ich bin halt der Meinung, dass man auf Fragen auch direkt antworten kann
Okokok:
   char *a, i;
   float f = 12.3456;
   a = (char*)&f;
   for (i=0; i<4; i++) putchar(*a+i);

> Ich bin halt der Meinung, dass man auf Fragen auch direkt antworten kann
Da kenn ich noch einen:
Klein Werner ist bei seinem Kumpel Otto. Er sieht, dass Ottos Vater 
einen Kugelschreiber nicht zum Laufen bekommt. Diagnose: Tinte 
eingetrocknet.
Werner sagt: "Mein Vater hat ein Feuerzeug genommen und die Spitze warm 
gemacht."
"Gute Idee", sagt Ottos Vater und heizt die Spitze mit einem Feuerzeug 
auf. Kurz danach: große Sauerei, Hemd und Hose hinüber.
Das sagt Werner: "Das ist meinem Vater auch passiert!"

Substitution:
X-Rocka  = Ottos Vater
Und wer will Werner sein?

> von einem anderen uC (den mache nicht ich)
Little oder Big Endian  ;-)

> Ich suche also nur einen online Rechner
Warum Online? Siehe Anhang...
#include <stdio.h>

int main(int argc, char* argv[])
{
   char *a, i;
   float f = 12.345;
   while (1) {
   printf("\n\nZahl eingeben (Ende mit q): ");
   i = scanf("%f",&f);
   if(i!=1) return 0;
     a = (char*)&f;
   for (i=0; i<4; i++) printf("\n%02x %c",(*(a+i))&0xff, (*(a+i))&0xff);
   }
}


> wollte ich mir ein paar txt-files basteln
Das Problem ist, dass die Bates dann kein Text mehr sind, sondern 
irgendwelche Sonderzeichen, die dann vom jeweiligen Betriebssystem 
unterschiedlich interpretiert werden...
Du wirst also einen Hex-Editor brauchen.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und um das zu testen, wollte ich mir ein paar txt-files basteln, wo die
>floats in die 4 Bytes aufgeteilt sind, und diese über einen Terminal
>(Codevision) rausschicken.

merkst du eigendlich den Widerspruch zwischen Bytes und txt file?
Das wird maximal ein bin file

Thomas

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seufz...

@Läubi: hier Fragen stellen ist also rumhampeln?

Die Frage auf meine Antwort, ob's irgendwo so einen "Umrechner" gibt, 
heisst also: ihr wisst es nicht. Ist ja okay.

Klar habe ich auch schon dran gedacht, mir das in den uC zu basteln, 
ähnlich wie Lothar Miller (das war zwar nicht die richtige, aber eine 
konstruktive Antwort, danke!) es vorschlägt. Hätte den Vorteil, gleich 
das korrekte uC-Format zu bekommen... vielleicht mache ich es doch so.
Aber ich hatte mir da meinen Workflow etwas anders vorgestellt.
Und natürlich brauche ich einen hex-Editor, den brauche ich auch für 
Test-Files mit ASCII-Sonderzeichen wie STX, CR, etcpp.

Bei meiner nächsten Frage werde ich eine komplette 10-seitige 
Projektbeschreibung liefern, außerdem meinen Lebenslauf und alle 
bisherigen Projekte, so dass ihr wisst wie dämlich ich tatsächlich 
bin... ;-)

Ernsthaft, war die Ausgangsfrage so bescheuert?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X- Rocka schrieb:

> Ernsthaft, war die Ausgangsfrage so bescheuert?


Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten 
selbst schreiben kann ....

Die meisten hier haben das gewünschte Tool fertig, noch ehe dein Browser 
den Eröffnungsbildschirm von mikrocontroller.net anzeigt.

> Aber ich hatte mir da meinen Workflow etwas anders vorgestellt.

Alles klar.
Schönen Tag noch.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nach 1min googeln und über Wikipedia findet man sowas hier:
http://babbage.cs.qc.cuny.edu/IEEE-754/
Die Bytereihenfolge im Speicher hängt dann von der HW ab, aber das 
sollte ja kein Problem sein.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ernsthaft, war die Ausgangsfrage so bescheuert?
Ich wollte dich nicht wie Ottos Vater dastehen sehen... ;-)

> ich suche ein kleines PC-Programm, dass mir 32-bit float Zahlen in die
> 4 Bytes zerlegt, damit ich diese dann über Terminal und serielle
> Schnittstelle an meinen AVR schicken kann.
> Sprich:
> - ich gebe ein: 12.3456
> - und bekomme vom Programm Mantisse und Exponent
Das hast du jetzt ja (incl. float2hex.exe) seit dem 
Beitrag "Re: PC-Tool: float in 4 Bytes (hex) zerlegen"
Diesen Dreizeiler hatte ich übrigens in etwa 5 Minuten hingeklekst...

EDIT:
> Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten
> selbst schreiben kann ....
Ich musste erst noch das VisualStudio hochfahren...  ;-)

Autor: Senf-Dazu-Geber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ernsthaft, war die Ausgangsfrage so bescheuert?

Also ich kann nichts verwerfliches daran finden nach einem PC-Tool zu 
fragen. Ich hab' meine Meinung zu manchen Antworten hier aber auch schon 
kundgetan.


> Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten
> selbst schreiben kann ....

Das setzt aber voraus, dass ich eine PC-Entwicklungsumgebung installiert 
habe ;-)


Gruss

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Senf-Dazu-Geber schrieb:

>> Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten
>> selbst schreiben kann ....
>
> Das setzt aber voraus, dass ich eine PC-Entwicklungsumgebung installiert
> habe ;-)

Genau. Und das habe ich nicht, und der Weg der Float-Zerlegung über nen 
uC und Terminal ist doch etwas umständlicher.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS schrieb:
> nach 1min googeln und über Wikipedia findet man sowas hier:
> http://babbage.cs.qc.cuny.edu/IEEE-754/
> Die Bytereihenfolge im Speicher hängt dann von der HW ab, aber das
> sollte ja kein Problem sein.

Vielen Dank!

Ich gebe zu, ich war zum googeln in diesem Fall zu doof - aber glaube 
mir bitte, ich hab's versucht!

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das AVR Studio hilft da aber auch weiter. Ein Programm wie
#include <float.h>

void main()
{
  float a = 1.234f;
}

übersetzen (mit -O0, sonst wird es wegoptimiert) und im Simulator 
starten. Das Watchfenster verrät wo ein Variable liegt und das 
Memoryfenster zeigt die Bytes an.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS schrieb:
> das AVR Studio hilft da aber auch weiter. Ein Programm wie
>
>
> #include <float.h>
> 
> void main()
> {
>   float a = 1.234f;
> }
> 
>
> übersetzen (mit -O0, sonst wird es wegoptimiert) und im Simulator
> starten. Das Watchfenster verrät wo ein Variable liegt und das
> Memoryfenster zeigt die Bytes an.

Gute Idee. Ich muss mich irgendwann wohl doch mal ins AVR studio 
einarbeiten. Nutze es nur zum flashen, weil das Tool dafür in Codevision 
nicht so doll ist.

Autor: Maxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Das hast du jetzt ja (incl. float2hex.exe) seit dem
> Beitrag "Re: PC-Tool: float in 4 Bytes (hex) zerlegen"
> Diesen Dreizeiler hatte ich übrigens in etwa 5 Minuten hingeklekst...
>
> EDIT:
>> Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten
>> selbst schreiben kann ....
> Ich musste erst noch das VisualStudio hochfahren...  ;-)

Hindernis erkannt und trotzdem genau drauf zugehalten.
Dein 3 Zeiler für sich allein liefert kein definiertes Ergebnis.

Hätte dein Programm nicht wesentlich vergrößert, hättest du es mathm. 
und nicht per Zeiger gelöst, um dich damit von Big/Little-Endianess des 
Hosts unabhängig zu machen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dein 3 Zeiler für sich allein liefert kein definiertes Ergebnis.
Schon klar, ich bin doch der, der dauernd auf die Bytereihenfolge 
abzielt. Und ich meine, genau 2 Zeilen vor dem Code nochmal darauf 
hingewiesen zu haben. Mehr kann ich nicht tun. Wenn ich sage: die Kurve 
verträgt nicht mehr als 80, dann bin ich doch nicht Schuld, wenn einer 
mit 100 rausfliegt.

> Hätte dein Programm nicht wesentlich vergrößert, hättest du es mathm.
> und nicht per Zeiger gelöst, um dich damit von Big/Little-Endianess des
> Hosts unabhängig zu machen.
Die Worte hör ich wohl, allein mir fehlt der Glaube.  :-)
Und zudem wäre ich nicht so schnell fertig gewesen...

> um dich damit von Big/Little-Endianess des Hosts unabhängig zu machen.
Nur: was ist mit dem Target/Client?
Wie bekomme ich die Abhängigkeit bei dem raus?

Autor: Maxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Ziel ist es das Gleiche.
Auch hier gilt: Zeigeroperationen sind systemabhängig (Betrifft nicht 
nur LE/BE, sondern auch Alignment, Busbreiten, etc), vorzeichenlose 
Arithmetik ist systemunabhängig. (die Einschränkung vorzeichenlos ist 
hier OBdA. wichtig jedoch um nicht in die 1er/2er Komplement Falle zu 
tappen)

Teilen (Shiften) und Modulo(verunden) bei der Zerlegung.
Multiplizieren (Shiften) und Addieren(verodern) bei der Rekonstruktion.
Der Kompiler kümmert sich dann um den Rest, dass die physiche Umsetzung 
auch der Operation folgt.

Die Ordnung ist dann nur noch für die Übertragung von Relevanz, das ist 
dann Aufgabe des Protokols sich auf eine (beliebige) Permutation zu 
einigen.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS schrieb:
> nach 1min googeln und über Wikipedia findet man sowas hier:
> http://babbage.cs.qc.cuny.edu/IEEE-754/
> Die Bytereihenfolge im Speicher hängt dann von der HW ab, aber das
> sollte ja kein Problem sein.

Nochmals danke!
Habe es jetzt getestet, funktioniert wunderbar.

X

Autor: Kalle (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier ist auch etwas

http://www.new-hex-editor.com

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.