Anfängerfrage USART (easy)

[Markus F. (Gast)]

Hallo zusammen ich habe versucht mit einem ATMega32L (3V3) und einem 
kleinen
FT3232-Board die Kommunikation zwischen meinem µC und PC zu probieren...
Dazu habe ich aus dem Datenblatt die Codeexamples kopiert,
um zu testen ob ich ein einfaches Zeichen an den PC (COM1) senden 
kann...

Leider kommt am PC im HTerm immer nur ein und dasselbe Zeichen an.
Es wird immer nur \0 empfangen, obwohl ich versuche
ein 'H' und andere Sachen zu senden...

Im Anhang findet ihr den Source-Code und den Schaltplan des FT3232 
Boards...

Habe schon versucht durch andere Beiträge den Fehler zu finden....
Die Leitungen TxD und RxD vom ATMega32L gehen auf die Eingänge vom
FT3232 und die Kreuzung der beiden Leitungen habe ich zwischen FT3232 
und PC vorgenommen....
Soweit ich das alles erkennen kann ist es auch richtig angeschlossen, 
oder ??


Wäre super dankbar für etwas Help !

[Markus F. (Gast)]

Und hier noch der Schaltplan als .PNG

[Karl H. (kbuchegg)]

?
Im Schaltplan ist das aber ein MAX232 und kein FT3232

Zum Programm:
Schau dir nochmal im Tutorial die Initialisierung der UART
an. Insbesondere die Berechnung der UBRR Werte für die
Baudrate. Tip: In die Berechnung geht die tatsächlich benutzte
Prozessortaktfrequenz ein.

Weiter hab ich dann nicht mehr geschaut, da in praktisch allen
Fällen von 'meine UART funktioniert nicht', die Schuld bei der
fehlerhaften Einstellung dieses Wertes liegt. In den meisten
Fällen wird allerdings eine falsche Prozessortaktfrequenz
angegeben. Keine Umrechnung der Werte hab ich allerdings noch
nie gesehen :-)

In den dann noch verbleibenden Fällen von 'geht nicht' ist es
dann meist die 'Kreuzung' des Kabels, die nicht stimmt. Da du
allerdings im PC zumindest irgendwas empfängst, dürfte diese
stimmen.

[Johannes M. (johnny-m)]

Wenn Du ins Baudratenregister einfach die Baudrate reinschreibst, kann 
das auch nicht funktionieren. Die Baudrate hängt von der Taktfrequenz 
ab, mit der der Controller läuft. Wirf mal einen Blick ins Datenblatt. 
Am Ende des USART-Kapitels ist ein Abschnitt "Examples of Baud Rate 
Settings" oder so ähnlich. Da sind Tabellen, in denen aufgeführt ist, 
welcher Wert für welche Baudrate bei welchem CPU-Takt ins UBRR 
reinkommt.

[Karl H. (kbuchegg)]

Johannes M. wrote:
> Settings" oder so ähnlich. Da sind Tabellen, in denen aufgeführt ist,
> welcher Wert für welche Baudrate bei welchem CPU-Takt ins UBRR
> reinkommt.

Und dann vergiss die Tabellen gleich wieder und benutzte
die im Tutorial angegebene Formel.

[Johannes M. (johnny-m)]

@Karl heinz:
Hast ja Recht. Aber trotzdem sollte der OP wenigstens mal im Datenblatt 
nachgesehen haben und verstehen, wie das mit dem UBRR funktioniert (was 
bisher ja anscheinend nicht der Fall ist)...

[Karl H. (kbuchegg)]

Apropos Tutorial.
Eine hilfreiche Seele hat die Baudratenberechnung etwas
erweitert, so dass auch der Fehler berücksichtigt wird.
Gut so.

Aber er hat auch dies hier hinterlassen:

#define BAUD 9600L          // Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!

Nun kann ich mir aber keinen Fall vorstellen, bei dem es mit einem
UL zu Problemen kommen würde, die durch L vermieden würden.
Irgendwelche Kommentare dazu?

[Markus F. (Gast)]

Hi nochmal,

ja habe mir das im DB und im Tut schon durchgelesen...
habe das auch so versucht, doch leider ohne erfolg.....

Beim Kompilieren kommt immer folgende Fehlermeldungen:
> "make.exe" all

-------- begin --------
avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=UL -Os -funsigned-char 
-funsigned-bitfields -fpack-struct -fshort-enums -Wall 
-Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP 
-MF .dep/main.o.d main.c -o main.o
main.c:21:7: warning: "UL" is not defined
main.c:21:7: warning: "UL" is not defined
main.c:21:7: error: division by zero in #if
main.c:21:26: warning: "UL" is not defined
main.c:21:26: warning: "UL" is not defined
main.c:21:26: error: division by zero in #if
main.c:22:4: error: #error Systematischer Fehler der Baudrate grösser 1% 
und damit zu hoch!
main.c:29: warning: return type of 'main' is not 'int'
main.c: In function 'main':
main.c:33: error: 'UL' undeclared (first use in this function)
main.c:33: error: (Each undeclared identifier is reported only once
main.c:33: error: for each function it appears in.)
main.c:36: warning: implicit declaration of function 'uart_putc'
main.c: At top level:
main.c:42: error: conflicting types for 'uart_putc'
main.c:42: note: an argument type that has a default promotion can't 
match an empty parameter name list declaration
main.c:36: error: previous implicit declaration of 'uart_putc' was here
make.exe: *** [main.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:01


Leider bekomme ich die Fehler nicht weg....

[Karl H. (kbuchegg)]

Dein makefile hat einen Fehler

-DF_CPU=UL

das muss lauten
-DF_CPU=8000000UL

wenn dein Prozessor zb mit 8Mhz getaktet wird.
Benutzt du einen 16Mhz Quarz, dann lautet der Eintrag:
-DF_CPU=16000000UL

Also immer die tatsächliche Taktfrequenz in Hz.

Aus den Fehlermeldungen ist ersichtlich, dass es noch
ein paar andere Fehler im Code geben muss. Wenn du
damit Hilfe brauchst, dann poste den Code.

[Falk B. (falk)]

@  Karl heinz Buchegger (kbuchegg)

>Eine hilfreiche Seele hat die Baudratenberechnung etwas
>erweitert, so dass auch der Fehler berücksichtigt wird.
>Gut so.

Nicht wahr ;-)

>Aber er hat auch dies hier hinterlassen:

>#define BAUD 9600L          // Baudrate, das L am Ende ist wichtig, NICHT UL 
verwenden!

>Nun kann ich mir aber keinen Fall vorstellen, bei dem es mit einem
>UL zu Problemen kommen würde, die durch L vermieden würden.
>Irgendwelche Kommentare dazu?

Der Geist der Seele spricht. Mit UL ergibt sich hier eine Warnung, die 
nur irritiert und ggf. schief geht.

#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif

warning: the right operand of "<" changes sign when promoted

MfG
Falk, alias der Geist der guten Seele

P.S.

http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART#Senden

Ein Fall für die Ghost Busters? ;-)

[Markus F. (Gast)]

Hallo,
nach dem Anpassen der Makefile ging es zu kompelieren, aber es wird 
immer
noch nur \0 am PC empfangen....
Wenn ich die Verbindung trenne wird auch nichts mehr empfangen, also 
kommen die Datens chon wie es soll vom µC....

Leider aber nicht die richtigen...

Im Anhang nochmal der Code und das Makefile

[Markus F. (Gast)]

So und hier nochmal das Makefile

[Karl H. (kbuchegg)]

Falk Brunner wrote:
>>Aber er hat auch dies hier hinterlassen:
>
>>#define BAUD 9600L          // Baudrate, das L am Ende ist wichtig, NICHT UL
> verwenden!
>
>>Nun kann ich mir aber keinen Fall vorstellen, bei dem es mit einem
>>UL zu Problemen kommen würde, die durch L vermieden würden.
>>Irgendwelche Kommentare dazu?
>
> Der Geist der Seele spricht.

Huch, wie unheimlich :-)

> Mit UL ergibt sich hier eine Warnung, die
> nur irritiert und ggf. schief geht.
>
>

> #if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
>   #error Systematischer Fehler der Baudrate grösser 1% und damit zu
> hoch!
> #endif
>

>
>

> warning: the right operand of "<" changes sign when promoted
>

>

Alles klar.

> Ein Fall für die Ghost Busters? ;-)

dumm dumm dudli di dumm, dumm dumm dudli di dumm
When there's something strange, ...

[Karl H. (kbuchegg)]

Markus F. wrote:
> Hallo,
> nach dem Anpassen der Makefile ging es zu kompelieren, aber es wird
> immer
> noch nur \0 am PC empfangen....
> Wenn ich die Verbindung trenne wird auch nichts mehr empfangen, also
> kommen die Datens chon wie es soll vom µC....
>
> Leider aber nicht die richtigen...
>
> Im Anhang nochmal der Code und das Makefile


Falscher Code?

Du schreibst ja immer noch die Baudrate direkt ohne Umrechnung
in das UBRR Register!

[Markus F. (Gast)]

Ohhh ja richtig...

hier im Anhang der richtige Code



und das hier ist uotput vom kompilieren:

> "make.exe" all

-------- begin --------
avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL -Os 
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall 
-Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP 
-MF .dep/main.o.d main.c -o main.o
main.c:21:40: warning: the right operand of "<" changes sign when 
promoted
main.c:22:4: error: #error Systematischer Fehler der Baudrate grösser 1% 
und damit zu hoch!
main.c:29: warning: return type of 'main' is not 'int'
main.c: In function 'main':
main.c:38: warning: implicit declaration of function 'uart_putc'
main.c: At top level:
main.c:45: error: conflicting types for 'uart_putc'
main.c:45: note: an argument type that has a default promotion can't 
match an empty parameter name list declaration
main.c:38: error: previous implicit declaration of 'uart_putc' was here
make.exe: *** [main.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:00

[Karl H. (kbuchegg)]

Jetzt wirds schwierig:
Läuft dein Mega32 auch wirklich mit 8Mhz?

Beachte: Es reicht nicht, wenn ein Quarz an den Mega32
angeschlossen ist. Der muss auch mit umstellen der Fusebits
aktiviert werden!
Wenn dir also der Begriff Fusebits nichts sagt, oder du da
noch nicht drann warst, dann läuft dein Mega32 wahrscheinlich
immer noch mit 1 Mhz.

http://www.mikrocontroller.net/articles/AVR_Fuses

[Karl H. (kbuchegg)]

Seh gerade, du hast ja noch Fehler vom Compiler!

[Karl H. (kbuchegg)]

> main.c:29: warning: return type of 'main' is not 'int'

Der sollte selbsterklärend sein.

int main()
{
 ....
}

> main.c:38: warning: implicit declaration of function 'uart_putc'
> main.c: At top level:
> main.c:45: error: conflicting types for 'uart_putc'
> main.c:45: note: an argument type that has a default promotion can't
> match an empty parameter name list declaration
> main.c:38: error: previous implicit declaration of 'uart_putc' was here

Das alles dreht sich um 'uart_putc'
Geh mal deinen Code von oben nach unten durch: An welcher Stelle
taucht der Begriff uart_putc das erste mal auf?

Richtig: Bei seiner Verwendung in main(). Hier:

  while(1)
  {
    uart_putc('H');
  }

Da der Compiler den Namen uart_putc bisher noch nicht gesehen hat, 
gelten
Standardannahmen. Allerdings teilt dir der Compiler auch mit, dass
er das macht:

> main.c:38: warning: implicit declaration of function 'uart_putc'

Soll soviel heissen wie: Ich habe bisher noch keine Deklaration
für uart_putc gesehen. Daher bastle ich mir selber eine.
Die C Standardregeln schreiben auch vor, welche Annahmen der
Compiler treffen muss. Er muss davon ausgehen, dass die Funktion
einen Return Typ von int hat und das das Argument als int
ubergeben wird.

Dann gehts weiter im Text: Irgendwann taucht dann plötzlich
die tatsächliche Funktion uart_putc auf:
int uart_putc(unsigned char c)
{
  ...
}

und, oh Mist, die Compiler Annahmen darüber, waren nicht zutreffend:
> main.c:45: error: conflicting types for 'uart_putc'
> main.c:45: note: an argument type that has a default promotion can't
> match an empty parameter name list declaration

Das Argument ist nicht int sondern unsigned char.

Zieh die uart_putc vor die main() und alles ist in Butter.
AUf diese Art sieht der Compiler die Funktion bevor sie
verwendet wird und braucht keine Annahmen treffen:

int uart_putc( unsigned char c )
{
 ...
}

int main()
{
   ...

   uart_putc( 'H' );
}

[Markus F. (Gast)]

Fusebits sind alle richtig gesetzt.
Alle Haken bei CKSEL sind weg --> externe Taktquelle...

So nur bei
SPIEN
BOOTSZ1
BOOTSZ0
SUT0
sind Haken dran....

Was ist denn noch fürn Fehler im Compiler ??

[Markus F. (Gast)]

Fusebits sind alle richtig gesetzt.
Alle Haken bei CKSEL sind weg --> externe Taktquelle...

So nur bei
SPIEN
BOOTSZ1
BOOTSZ0
SUT0
sind Haken dran....

[Johannes M. (johnny-m)]

> #include "avr/iom32.h"
Nie die Device-spezifische Header-Datei direkt includen. Es wird immer 
nur io.h includiert, die Einstellung, welcher µC benutzt wird, gehört 
ins Makefile

> main.c:29: warning: return type of 'main' is not 'int'
> main.c: In function 'main':
GCC-C erwartet

int main(void)
{}

und nicht mit void vorne...

> main.c:38: warning: implicit declaration of function 'uart_putc'
> main.c: At top level:
Eine Funktion muss vor ihrem ersten Aufruf bekannt sein. Deine uart_putc 
wird aber erst weiter unten definiert. Entweder eine Deklaration vor 
main einbauen, oder die ganze Definition vor main verschieben.

> main.c:45: error: conflicting types for 'uart_putc'
...Außerdem ist ein ASCII-Zeichen (wie z.B. 'H') ein (signed) char und 
kein unsigned char...

EDIT:
Upps, die letzte Fehlermeldung bezieht sich natürlich auf die 
Default-Annahmen des Compilers und nicht auf das unsigned. 
Nichtsdestotrotz ist ein ASCII-Zeichen eigentlich nicht unsigned...

[Karl H. (kbuchegg)]

> main.c:29: warning: return type of 'main' is not 'int'

Der sollte selbsterklärend sein.

int main()
{
 ....
}

> main.c:38: warning: implicit declaration of function 'uart_putc'
> main.c: At top level:
> main.c:45: error: conflicting types for 'uart_putc'
> main.c:45: note: an argument type that has a default promotion can't
> match an empty parameter name list declaration
> main.c:38: error: previous implicit declaration of 'uart_putc' was here

Das alles dreht sich um 'uart_putc'
Geh mal deinen Code von oben nach unten durch: An welcher Stelle
taucht der Begriff uart_putc das erste mal auf?

Richtig: Bei seiner Verwendung in main(). Hier:

  while(1)
  {
    uart_putc('H');
  }

Da der Compiler den Namen uart_putc bisher noch nicht gesehen hat, 
gelten
Standardannahmen. Allerdings teilt dir der Compiler auch mit, dass
er das macht:

> main.c:38: warning: implicit declaration of function 'uart_putc'

Soll soviel heissen wie: Ich habe bisher noch keine Deklaration
für uart_putc gesehen. Daher bastle ich mir selber eine.
Die C Standardregeln schreiben auch vor, welche Annahmen der
Compiler treffen muss. Er muss davon ausgehen, dass die Funktion
einen Return Typ von int hat und das das Argument als int
ubergeben wird.

Dann gehts weiter im Text: Irgendwann taucht dann plötzlich
die tatsächliche Funktion uart_putc auf:
int uart_putc(unsigned char c)
{
  ...
}

und, oh Mist, die Compiler Annahmen darüber, waren nicht zutreffend:
> main.c:45: error: conflicting types for 'uart_putc'
> main.c:45: note: an argument type that has a default promotion can't
> match an empty parameter name list declaration

Das Argument ist nicht int sondern unsigned char.

Zieh die uart_putc vor die main() und alles ist in Butter.
AUf diese Art sieht der Compiler die Funktion bevor sie
verwendet wird und braucht keine Annahmen treffen:

int uart_putc( char c )
{
 ...
}

int main()
{
   ...

   uart_putc( 'H' );
}

[Hermann-Josef (Gast)]

Hallo,

meiner Meinung nach sind die Pins R1OUT und R1IN des MAX232 falsch 
beschaltet = verwechselt, aber diese Richtung wird ja gegenwärtig noch 
nicht getestet.

Siehe auch:
http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART

Das Problem mit der falschen Annahme über uart_putc() ließe sich auch 
über eine Vorwärts-Deklaration lösen:

int uart_putc(unsigned char);

int main() {

  // ...

  return 0;
}

int uart_putc(unsigned char c) {

  // ...

  return 0;
}

Von dieser Vorgehensweise aus ist dann evtl. der Übergang zu externen 
Modulen/Bibliotheken verständlicher, dann noch mit 'extern' versehen.

Hermann-Josef

[Markus F. (Gast)]

Also habe eine Prototypen-decla eingefügt und nu bleibt nur noch ein 
Error...


Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL -Os 
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall 
-Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP 
-MF .dep/main.o.d main.c -o main.o
main.c:21:40: warning: the right operand of "<" changes sign when 
promoted
main.c:22:4: error: #error Systematischer Fehler der Baudrate grösser 1% 
und damit zu hoch!
make.exe: *** [main.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:00


Ja über den Schaltplan sollte auch nochmal geschaut werden, bin mir aber 
ziemlich sicher, das das richtig so ist...
Der Baustein ist im übrigen ein MAX3232 !!!

[Bernd M. (Gast)]

Zum Schaltplan:
Der MAX ist nicht richtig angeschlossen: rechts ist RS232 Pegel (PC) und 
links ist uC TTL Pegel (uC)

siehe auch
http://www.elektronik-kompendium.de/public/riederer/max232.htm

Gruss Bernd

[Markus F. (Gast)]

Ja, habe aber einen MAX3232
keinen MAX232 !!!

Und in dem Datenblatt vom MAX 3232 ließt es sich so schön direkt am 
Anfang:

3.0V to 5.5V, Low-Power, up to 1Mbps, True RS-232
Transceivers Using Four 0.1μF External Capacitors

[Christian R. (supachris)]

Trotzdem falsch angeschlossen. An die 12 muss die 3,3V Seite, und an die 
13 die RS232 Seite.

Wenn du Pech hast, ist sowohl der MAX als auch der ATMega jetzt kaputt.

[Markus F. (Gast)]

Ok,
habe das geändert, aber was ist mit dem Programm ??

wieso kommt da immer noch folgender Fehler beim Compilen ??


Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP
-MF .dep/main.o.d main.c -o main.o
main.c:21:40: warning: the right operand of "<" changes sign when
promoted
main.c:22:4: error: #error Systematischer Fehler der Baudrate grösser 1%
und damit zu hoch!
make.exe: *** [main.o] Error 1

[Karl H. (kbuchegg)]

Markus F. wrote:
> Ok,
> habe das geändert, aber was ist mit dem Programm ??
>
> wieso kommt da immer noch folgender Fehler beim Compilen ??

Weil die Berechnung des Baudratenfehlers durch die Verwendung
von UL bei F_CPU eine unsigned Berechnung ist und daher per
Definition nicht negtiv werden kann.
Damit ist dann aber auch der 2. Teil der Abfrage
#if ((BAUD_ERROR > 10) || (BAUD_ERROR < -10))
sinnlos geworden. Der Ausdruck BAUD_ERROR kann nie kleiner
als -10 sein, weil er als unsigned Wert kein Vorzeichen besitzt
und damit immer positiv ist.

Ändere mal das hier

#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000) // Fehler in Promille

so um

#define BAUD_ERROR (((long)(BAUD_REAL*1000))/((long)BAUD)-1000) // Fehler in Promille

damit müsste der Ausduck fuer BAUD_ERROR auf jeden Fall wieder ein
signed Ausdruck sein, und die Abfrage

#if ((BAUD_ERROR > 10) || (BAUD_ERROR < -10))

wieder funktionieren.

Wenn das nicht klappt (habs nicht ausprobiert), dann ändere in
deinem Makefile die Zeile
CDEFS = -DF_CPU=8000000UL
ab zu
CDEFS = -DF_CPU=8000000L

[Markus F. (Gast)]

Habe beides geändert,
aber jetzt kommt immer der folgende Fehler:


Compiling C: main.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000L -Os 
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall 
-Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP 
-MF .dep/main.o.d main.c -o main.o
main.c:22:6: warning: "long" is not defined
main.c:22:6: error: missing binary operator before token "("
make.exe: *** [main.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:01

[Karl H. (kbuchegg)]

Markus F. wrote:
> Habe beides geändert,

Einer der beiden Wege hätte gereicht.

> aber jetzt kommt immer der folgende Fehler:
>
>
> Compiling C: main.c
> avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000L -Os
                                                  ********

Das ist schon korrekt so.
d.h. die Änderung von
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000) // Fehler in Promille
ist überflüssig und kann zurückgenommen werden.


> -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
> -Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP
> -MF .dep/main.o.d main.c -o main.o
> main.c:22:6: warning: "long" is not defined

der ist allerdings interessant.
Wie gesagt, wenn du den #define wieder zurück änderst, löst
sich dieser Fehler in Luft auf. Allerdings muss ich dem jetzt
mal nachgehen, was hier schief läuft. long kann nicht undefined
sein. long ist ein Datentyp. Ob man derartige 'castings' allerdings
mit dem Präprozessor veranstalten kann, bin ich mir jetzt nicht
wirklich sicher.

> main.c:22:6: error: missing binary operator before token "("

Entweder du oder ich haben uns anscheinend bei den Klammerungen
verhaut.