mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM Daten Hilfe


Autor: Stark Arm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mahlzeit zusammen,
Hab da ne Frage weil ich bald von AVR auf ARM umsteigen will. Wieviele 
MIPS hat denn so ein AT91SAM7S256 µC wirklich? Ich lese oft, dass sie 
16/32 Bit Controller sind, heißt das jetzt, dass sie bei einem Clock 
Cycle 32 oder 16 Bit verarbeiten können (so wie die ATMEGAs 8 Bit)? Der 
Leistungsunterschied zu einem AVR muss doch gewaltig sein. Kann mir 
vielleicht jemand über die "Grenzen" dieser Controller sagen?
Dann gibt es da noch die ARM9-er Reihe, die ja 180Mhz haben. Kann man 
sie alle über den gleichen Programmer in diesem Shop proggen??

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schnell so ein ARM im Vergleich zum AVR ist hängt (natürlich)
von der Anwendung ab. Wenn die Aufgabe im Wesentlichen darin
besteht IO-Pins zu toggeln, ist ein ARM nur dann schneller wenn
er seine höhere mögliche Taktfrequenz ausnutzt. Die 32Bit nutzen
ihm da nichts.

Der ARM7 ist ein echter 32Bit Prozessor. Die 16/32Bit beziehen sich
wohl auf die beiden Befehlssätze (Thumb/ARM). Im Thumb-Mode ist
jeder Befehl wie auch beim AVR 16Bit breit. Die CPU arbeitet dann
aber trotzdem mit 32Bit. Die Befehle sind nur etwas weniger
leistungsfähig und man braucht daher oft mehr davon als es bei den
32Bit ARM-Befehlen nötig wäre um eine Operation durchzuführen.
Unterm Strich spart man aber etwas Programmspeicher ein.

Punkten kann ein ARM gegenüber dem AVR wenn viele 16/32/64Bit
Operationen durchgeführt werden oder große Datenmengen von A nach B
geschoben werden sollen.

Zu den Grenzen erstmal eine Gegenfrage: Wo liegen deiner Meinung
nach die Grenzen des dir schon bekannten AVR?
Einen 60MHz ARM7 kann man noch als MP3 Player verwenden. D. h. ohne
externen Dekoder.
Für Linux ist mir der ARM7 etwas zu schwach. Das wird imho erst auf
einem ARM9 mit zusätzlicher MMU interessant. Wegen des schon zwingend
erforderlichen externen Speicher ist auch der Aufwand für einen ARM7
zu groß.

Die JTAG Adapter können afaik alle ARM7/9 programmieren. Ich würde
dir aber empfehlen mit einem ARM7 wie dem SAM oder dem LPC2000 zu
beginnen. Für die Teile gibt es reichlich Beispiele im Netz und
wenn dir die Leistung für irgendetwas nicht reicht kannst du dann
immer noch auf den ARM9 gehen.

Dann ist da noch der 'ARM7 Nachfolger' Cortex-M3. Luminary und ST
bieten Controller mit diesem Kern an. NXP soll angeblich im Laufe
des Jahres folgen. Der M3 hat einige Vorteile gegenüber dem ARM7,
insbesondere beim Interrupt Handling und er kann in Hardware
dividieren. Ich arbeite privat und beruflich seit knapp einem
Jahr mit dem ARM7. Die meiner Meinung nach eher kleinen Vorteile
des M3 rechtfertigen zur Zeit keinen Wechsel. Zumal die neuen Chips
sich ersteinmal bewähren müssen. In diesem Jahr wird das sicher
nichts mehr. Aber da du ja noch nichts mit dem ARM7 zu tun hattest
sind die ja vielleicht etwas für dich?

Wegen dem AT91SAM: Lass dich nicht davon beirren das Atmel
so tolle 8Bit Controller baut. Der SAM ist ein ganz anderes
Kaliber der mit dem AVR nichts zu tun hat. Orientiere dich lieber
an den Datenblättern/Erratas verschiedener Hersteller (v.a. NXP) und
den verfügbaren Beispielprogrammen. Vergleiche die Peripherie
(verfügbare IO Leitungen), überlege dir ob du jede Schaltung mit
dem JTAG Adapter programmieren willst und wie die Alternative aussieht.

Autor: Stark Arm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für deine Antwort. Worin für mich die Grenzen eines AVR liegen ist 
zum beispiel ein sehr einfaches Fernsehbild in s/w oder wiedergabe von 
midi dateien. Er kann einfach zu wenig mit seinen 16 MHz.

Autor: Stark Arm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit einem ARM könnte ich doch z.B. ein Farbbild erzeugen, einen MP3 
Player auf Software bauen, USB Schnittstelle benützen, etc. etc.

Autor: Stark Arm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal so ganz nebenbei, wo kauft ihr denn eure ARM µCs, in Österreich 
lassen sich die Dinger nicht so gut finden

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die meiner Meinung nach eher kleinen Vorteile des M3
>rechtfertigen zur Zeit keinen Wechsel.


Hmmmm, vernünftiger Interruptcontroller mit fester Latenz von 12 Zyklen 
anstatt Ärger mit spurious Interrupts und variablen Latenzen von 24 - 42 
Zyklen, Bitbanding für schnelles I/O anstatt Load/Store sind also 
"kleine Vorteile"?

Für mich sind das massive Vorteile.
Einziges Argument für den ARM7 ist die Tatsache, daß bei ihm mehr Fehler 
bekannt sind, da er länger auf dem Markt ist.
Für den Umstieg vom AVR auf den ARM ist der Cortex ansonsten sicherlich 
wesentlich besser geeignet.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Support für Thumb2 im GNU Compiler ist noch etwas dünn. Codesourcey 
hat das schon drin, aber GNUARM und WinARM m.W. noch nicht.

Autor: Dominic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thumb2 kommt erst im Mainline erst mit GCC4.3, aktuell ist aber noch 
GCC4.2(.2). In der Codesourcery Toolchain ist der Thumb2 Support 
allerdings schon eine ganze Weile enthalten, und sollte damit auch mehr 
als ausreichend stabil sein.

@ Dieter:
Die Interrupt Latenz dürfte für einen überwältigenden Anteil der User 
ziemlich egal sein, und wer schnelles Bitbanging braucht sollte wohl 
eher einen anderen uC verwenden, der die gewünschte Funktionalität in 
Hardware mitbringt. Der Cortex-M3 ist "nett", in meinen Augen aber v.a. 
eine Möglichkeit für ARM, neue Lizenzen zu verkaufen - ein schlagendes 
Argument, die bewährten ARM7 zugunsten eines Cortex-M3 aufzugeben sehe 
ich bisher nicht.

@Stark Arm
MP3 in Software dürfte einen 50MHz ARM7 ziemlich auslasten (ein 70MHz 
Modell hat dann also noch einige Prozent Reserve). Auf einem ARM9 mit 
180MHz bleibt wohl eine Last von 20-30% übrig. Ein ARM9E mit seinen DSP 
Befehlen schneidet dann nochmal ein Stück besser ab.

"USB Schnittstellen" in Form eines USB Hosts findest du nur bei größeren 
ARMen, z.B. AT91RM9200 (ARM920T), EP93xx (ARM920T) oder AT91SAM926x 
(ARM926EJ-S). Aber auch die sind allesamt Full-Speed, also maximal 12 
Mbps.
Eine Ausnahme bildet da der LPC24xx (ARM7TDMI-S), der einen USB 
Controller mit Device, Host und OTG Funktionalität mitbringt (auch nur 
Full-Speed). Hier bleibt aber die Frage, welche Funktionalität sich 
sinnvoll in dem ARM7 integrieren lässt - USB Speichersticks wären sicher 
möglich.

Ein Farbbild zu generieren ist sicherlich möglich, die Frage ist, worauf 
du das Bild anzeigen möchtest. LCD Displays gibt es mit einer Vielzahl 
unterschiedlicher Interfaces, für VGA wirst du um einen zusätzlichen 
Chip kaum herumkommen. Einige ARM uCs bringen integrierte LCD Display 
Controller, teilweise gehen die aber zu Lasten der Systemperformance 
(StrongARM war da ein unrühmliches Beispiel). Wenn's bewegte Bilder sein 
sollen steigen die Anforderungen nochmals gewaltig an.

Gruß,

Dominic

Autor: Stark Arm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine Hier eigentlich mehr so ein Projekt wie eine kleine PS - schau 
doch mal bei Wiki nach der PS 2 hat nicht mehr als 300 MHz (CPU).

MP3 in Software wurde schon mit verschiedenen ARM mit < 50 realisiert.

Ich kenne mich mit AT90Sam und LPC oder diesen M3 nicht so gut aus. Mir 
geht es vor allem um möglichst viele MIPS, gute und schnelle 
Interruptsteuerung und schnelle IO. Welcher Controllertyp ist da am 
besten von denen geeignet?

Autor: Stark Arm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
< 50 MIPS meine ich

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dieter:
Das sind alles Gründe den M3 anstelle eines 8Bit µCs einzusetzen.
Derzeit besteht ja noch eine beachtliche Kluft zwischen den 8Bittern
und dem ARM7. Einen ARM nimmt man ja üblicherweise dort wo viele
Daten bewegt werden müssen oder man eine relativ hohe Komplexität in
der Software hat (z.B. Maschinensteuerung mit RTOS). Latenzen und
primitive IO werden da immer unbedeutender.
Sicher wird es dünn für den ARM7: Von unten kommt der M3 (obwohl der ja
an sich nicht auf einfache Anwendungen beschränkt ist) und von oben der
ARM9. Wer allerdings bereits den ARM7 einsetzt kann Stand heute aber
dabei bleiben. Zunächst sind es Microchip, Atmel und die diversen 8051
Hersteller die den M3 fürchten müssen.

@Stark Arm:
Prinzipiell ist der M3 dem ARM7 gerade in diesem Bereichen überlegen.
Schau dir aber die Datenblätter von den Controllern an und Vergleiche
die Peripherie. Der Kern ist nicht alles.
Für den Einstieg in die M3 Welt finde ich das LM3S6965 Eval-Board
von Luminary recht interessant. Dieser STM32-Primer ist auch witzig.
Doch ich habe auch so schon genug zu tun ;)

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stark Arm wrote:
> Ich meine Hier eigentlich mehr so ein Projekt wie eine kleine PS - schau
> doch mal bei Wiki nach der PS 2 hat nicht mehr als 300 MHz (CPU).

Hast du dir schon mal die Technical Specifications der Emotion Engine 
angesehen? Da kann kein ARM auch nur Ansatzweise mithalten:

- 64 bit Main CPU
- FPU
- zwei Vektor-Units mit je 9 Floating-Point Multiplizierern
- zusammen 6.2 GFLOPs

Dazu kommt dann noch der graphics synthesizer, ein "einfacher" 3D Grafik 
Chip, der die von der Emotion Engine aufbereitete Geometrie rendert und 
das Video-Signal generiert.

Für I/O gibt's einen eigenen I/O Prozessor (ein ~30MHz MIPS Kern, der 
als Hauptprozessor in der PS1 zu finden war), und ein Sound-Prozessor 
kommt auch noch dazu.

> MP3 in Software wurde schon mit verschiedenen ARM mit < 50 MIPS realisiert.

Eben - ein 50MHz ARM7 kommt niemals auf 50 MIPS. Und wenn du dich nicht 
auf niedrige Bitraten beschränken willst wirst du etwas in dieser 
Größenordnung brauchen. Klar kann es sein, dass 40 MHz ausreichen, viel 
weniger darf's aber nicht sei.

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stark Arm: ARM7 Controller von ATMEL bekommst bei Farnell

Autor: Stark Arm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die vielen Infos, ich weiß noch immer nicht wirklich mit 
welchen ARM ich weitermachen soll. Am liebsten würde ich bei ATMEL 
bleiben, weil ich auch viel mit AVR gemacht habe und ATMEL Produkte gut 
kenne. Reizen würde mich aber die LPC Reihe.

@Dominic R.: Ich weiß, mit einem ARM9 wird man niemals eine PS2 machen 
können. Das Beispiel war mehr als Vergleich gedacht. Schau dir mal den 
Sprung von PS1 zu PS2 und den Unterschied zwichen PS2 und 3 an. Da ist 
das zweitere schon viel gewaltiger. Aber sowas wie eine PS1 sollte schon 
drin sein, auch wenn man einen zusätzlichen Farbsignal IC verwenden muss

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Empfehlung:
ARM7: LPC214x (NXP, Philips),
ARM7: AT91SAM7X (Atmel),
Cortex-M3: STM32 (STMicro).

Angefangen mit ARMs habe ich mit dem MCB2140 (LPC2148) von Keil. Ein 
sehr schön zu programmierender Proz. Gut nach Datenblatt programmierbar, 
mit kleinen Hürden, wenn man aus der AVR-Welt kommt. Ansonsten sehr 
leistungsfähig, und nach etwas Einarbeitung auch nicht schwer zu 
programmieren.

Als Cortex hat mich der STM32F103 von STM sehr überzeugt. Ich arbeite 
mit dem MCBSTM32 (Keil). Sehr einfach zu programmieren, wenn man eine 
Kleinigkeit, die hier beim GPIO anders gemacht wird, erst mal raushat 
(Hab da nen schönen Beitrag an anderer Stelle hier im Forum 
geschrieben). Ansonsten ähnlich einfach wie AVR, programmierung frei 
nach Datenblatt.
Sehr schön: Debug-Modul und Core sind voneinander entkoppelt, so dass 
man durch verprogrammieren z.B. des Clocking nicht so leicht auf die 
Schnauze fallen kann. Weiterhin sehr leistungsfähig (Cortex-M3), sehr 
schnelles INT-Verhalten durch direkte Kopplung von NVIC und Core (der 
ist im CM3 Bestandteil des Core wenn man so will).
Nettes Feature sind AntiTamper sowie eine Clock-Sicherung, die beim 
Ausfall der externen Clock auf die interne umschaltet, und die externe 
Clock auch automatisch wiederaufnehmen kann. Ohne dass der Core 
abschmiert.
Super sind auch die von STM mitgelieferten structs für die Register. 
Programmierung a'la GPIOA->DATA=0xff;

AT91SAM7X (Atmel SAM7X-Board) bin ich noch am Anfang (gerade erst 
bekommen, und da arbeite ich privat dran :-). Wie immer bei Atmel ein 
sehr schönes Datenblatt :-)
GPIO etwas anders als AVR, aber auch simpel zu programmieren. Mehr hab 
ich noch nicht gemacht, doch ein Blick ins Datenblatt verrät, dass auch 
die Peripherals nicht schwer zu proggen sind.
Auch beim Atmel finden sich diese schönen structs, die das Proggen 
erleichtern und die Register in Gruppen zusammenfassen.


Alle diese Controller bringen einiges an Flash und RAM mit, was grössere 
Projekte oder einiges an zusätzlicher Software als eine Art OS neben der 
eigentlichen Firmware erlaubt (bei mir war es (m)eine Shell).


The other Side:
Beim LPC hab ich mich einmal ausgesperrt, hab versehentlich den 
JTAG-Port als GPIO konfiguriert. Nachdem ich bei Philips auf der Seite 
ein Flash Tool gefunden hatte, welches den Proz per serieller 
Schnittstelle programmiert, war das schnell wieder behoben.

Beim STM war ich Anfangs etwas über die GPIO-Conf am Fluchen. Man setzt 
hier kein Pullup-Register, Data Dorection Register, Alternate Function 
Register, sondern alles in einem Rutsch in einem Register.
Hat den Sinn, dass es beim Portumschalten keine Spikes gibt!

Beim Atmel SAM7X hab ich mich erst mal dusselig gesucht nach einem 
Register, mit welchem man '1'en und '0'en gemeinsam auf ein Portregister 
schreiben kann. Der Port muss hierfür ein klein wenig anders 
konfiguriert werden. Kleinigkeit. Verwirrend am DEV-Kit ist nur, dass 
die LEDs bei '0' leuchten :-)


VG,
/r.

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stark Arm wrote:
> Danke für die vielen Infos, ich weiß noch immer nicht wirklich mit
> welchen ARM ich weitermachen soll. Am liebsten würde ich bei ATMEL
> bleiben, weil ich auch viel mit AVR gemacht habe und ATMEL Produkte gut
> kenne. Reizen würde mich aber die LPC Reihe.
>
> @Dominic R.: Ich weiß, mit einem ARM9 wird man niemals eine PS2 machen
> können. Das Beispiel war mehr als Vergleich gedacht. Schau dir mal den
> Sprung von PS1 zu PS2 und den Unterschied zwichen PS2 und 3 an. Da ist
> das zweitere schon viel gewaltiger. Aber sowas wie eine PS1 sollte schon
> drin sein, auch wenn man einen zusätzlichen Farbsignal IC verwenden muss

Mit einem ARM7 wie LPC2000 oder AT91SAM7 wirst du auch die 
Leistungsfähigkeit einer PS1 kaum erreichen, selbst wenn du einen 
zusätzlichen IC für das Videosignal einsetzt.

Die 4KB On-Chip ICache sind um einiges effizienter sein als der branch 
buffer der LPCs, die AT91SAM7 Linie verfügt garnicht erst über etwas 
Vergleichbares, und müssen für single-cycle operation im Thumb-Modus 
laufen, was den Code um ~30% aufbläst (und damit ähnlich viel 
Performance kostet, gegenüber einem System, das ARM Code ohne 
wait-states ausführen könnte). Insgesamt 3,5 MB RAM und 512 KB ROM 
verlangen nach einem AT91SAM7SE oder LPC22xx/24xx mit externem Speicher, 
was mangels Caches zu Performance Engpässen führen wird.

Zu den 30 MIPS der CPU kommen dann nochmal 66 MIPS der Vektor-Einheit, 
eine Data-Decompression-Engine die es auf 80 MIPS bringt, ein 
Grafik-Chip der zumindest 2D Beschleunigung bietet, und ein 
Sound-Prozessor. Die PS1 kann hier dank hoher Parallelität einiges an 
Performance wettmachen, da Spiele wie fast alle Multimediainhalte sich 
naturgemäß gut zur Parallelisierung eignen.

Ich würde mindestens zu einem ARM9 mit ~200MHz greifen, dazu noch ein 
Grafik-Chip, der zumindest häufige 2D Funktionen (Blitter, Sprites) in 
Hardware beherrscht.

Gruß,

Dominic

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
z.B. ein ARM926: EP9315 von Cirrus Logic.
Läuft bei rund 200MHz, hat Caches und MMU on Board, sowie eine 
Grafikkarte, Sound, USB, Netzwerk, ... mit auf dem Chip. Ist für 
SetTopBoxen usw. entwickelt.

Greetz,
/r.

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich meine Hier eigentlich mehr so ein Projekt wie eine kleine PS - schau
> doch mal bei Wiki nach der PS 2 hat nicht mehr als 300 MHz (CPU).

Man kann Prozessoren nicht einfach nach der Taktrate beurteilen, denn es 
spielt eine große Rolle, was der Prozessor pro Takt erledigt.
Bei der Emotion Engine der PS2 handelt es sich um einen MIPS R5900 Kern 
(sowas ähnliches wurde früher in Workstations eingebaut und hat mit 
Embedded nicht allzuviel zu tun) mit FPU und zusätzlichen 
Vektoreinheiten, wie Dominic schon erwähnt hat. Die CPU ist also 
hochgradig superskalar, was ein Embedded-Prozessor von der Stange 
üblicherweise nicht ist.
Dazu kommt, daß die CPU bei aktuellen Spielekonsolen sich ohnehin nur um 
den generellen Ablauf, Künstliche Intelligenz und einen Teil der 
Berechnungen kümmert (bei der PS2 mehr als bei anderen). Die PS2 hat für 
die Grafik noch den sog. Graphics Synthesizer, bei dem das VRAM über 
eine 2560-Bit Bus (kein Tippfehler!) angebunden ist.

Auch die alte Playstation hat mit einem 30 MHz MIPS R3000A nicht gerade 
die schnellste CPU, aber sie muß überwiegend die ganzen Spezialchips 
steuern:
- SPU kümmert sich um den Ton
- GTE macht geometrische Berechnungen
- GPU rendert und schickt das ganze an den Fernseher

Ohne solche Spezialchips bekommst du bestenfalls Grafik in der Art vom 
alten Pac-Man, Spaceinvaders oder Atari VCS. Selbst der C64 konnte nur 
über den (für damalige Verhältnisse) sehr guten VIC-II bessere Grafik 
darstellen.

Autor: Stark Arm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr interessant, solche Dinge wusste ich gar nicht. Woher denn, wenn 
man die ganze Zeit nur mit 8 Bit bei 16 Mhz beschäftigt ist.

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Random ... wrote:
> z.B. ein ARM926: EP9315 von Cirrus Logic.
> Läuft bei rund 200MHz, hat Caches und MMU on Board, sowie eine
> Grafikkarte, Sound, USB, Netzwerk, ... mit auf dem Chip. Ist für
> SetTopBoxen usw. entwickelt.

Der EP9315 ist, wie alle EP93xx, ein ARM920T, d.h. ARMv4T, und kein 
ARM926EJ-S, der ARMv5(TE) implementieren würde. Vorteil von ARM926EJ-S 
wäre unter anderem eine Reihe von DSP Befehlen, die Multimedia-lastige 
Anwendungen beschleunigen.

Aber klar, generell wäre der EP9315 eine Möglichkeit, wobei ich leider 
nicht weiss, wie gut/schlecht dessen Graphics Accelerator ist. Vorteil 
wäre hier die vermutlich gute Anbindung an den ARM920T.

Gruß,

Dominic

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.