Hallo! Ich bin Neuling und wie bei fast allen Anfängern und wie in zig Threads hier stellt sich die Frage AVR oder ARM? Es heißt dann immer, der AVR ist wesentlich einfacher für den Einstieg, 100 Seiten Datenblatt statt 1000, etc. Aber wie sieht es aus Sicht eines Programmierers in Hochsprache (z.B. C/C++) aus? Wenn man nicht gerade in Assembler programmiert, dann ist die Komplexität des Prozessors das Problem des Compilers. Ich Programmiere z.B. auf normalen PC's und habe mir noch nie das Datenblatt eines Quadcore x86_64 angesehen. Okay, wenn ich auf unterster Ebene in Assembler mit den Registern spielen möchte, den Prozessor verstehen möchte, dann ist es etwas anderes. Aber wenn ich nur mit einem C-Programm mit Tastern ein paar LEDs zum blinken bringen möchte, ist dies dann auch mit einem ARM wesentlich schwieriger umzusetzen als mit einem AVR? Danke!
Die Komplexität eines Mikrocontrollers ist nicht ein Problem des Compilers, sondern des Programmierers und der Bibliotheken die er verwendet. Da sind ARM-Basierende Mikrocontroller aufgrund ihrer Peripherie und Features deutlich komplizierter, und die vorhandenen Hersteller-Bibliotheken und deren Dokumentation reißen das nur zum Teil raus.
Es kommt hauptsächlich auf die Hardware an. Die ist zumeist viel komplexer bei den ARMs. Also die Timer, IOs, DMA usw. >Wenn man nicht gerade in Assembler programmiert, dann ist die Komplexität >des Prozessors das Problem des Compilers. Ich Programmiere z.B. auf normalen >PC's und habe mir noch nie das Datenblatt eines Quadcore x86_64 angesehen. Der Vergleich mit dem PC hinkt etwas. Zum vergleichen wäre es besser wenn du einfach mal nen Hardwaretreiber auf dem PC schreibst ob in C/C++ oder Assembler ist dabei egal. Da bringen dir deine C/C++ Kenntnisse sehr wenig.
Hallo, wenn du einen AVR 8bit uC mit einem fetten ARM vergleichst, ist das wie bei der Formel 1 mit einem Bobycar da zu stehen... Bei AVR32 ist es ganz anders. Also wovon reden wir?
Die Komplexität des Cores interessiert dich tatsächlich kaum bei Verwendung von C/C++. Deren Mächtigkeit vereinfacht die Programmierung sogar (32bit Arithmetik, ggf. FPU, einheitlicher Adressraum etc.). Viele ARM-Mikrocontroller wie zB die STM32 haben aber auch erheblich komplexere Peripherie, s.d. z.B. LED-Blinken schwieriger ist. Beispiel: Pin auf output setzen bei AVR:
1 | DDRB |= (1 << PB0); |
Pin auf output setzen bei STM32F4:
1 | RCC_AHB1PeriphClockCmd(RCC_AHB1ENR_GPIODEN, ENABLE); |
2 | GPIO_InitTypeDef GPIO_InitStructure; |
3 | GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; |
4 | GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; |
5 | GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP; |
6 | GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; |
7 | GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12; |
8 | GPIO_Init(GPIOD, &GPIO_InitStructure); |
Und genau diese ganzen Parameter zu konfigurieren ist das Problem. Die Doku ist nämlich typischerweise auch nicht so einfach zu lesen.
Wie einfach ist es denn für dich, mit deinem Quadcore mal eben schnell ein paar LEDs zum blinken zu bringen? ARM ist komplizierter als AVR. Das ist mehr drin, der hat mehr Funktionen, die toolchains sind komplexer, usw. Mal eben ein paar LEDs zum blinken zu bringen, ist mit einem AVR auch in Hochspache deutlich einfacher. Mal eben einen Webserver aufzusetzen ist dagegen auf einem ARM, auf dem ein komplettes Linux läuft, wiederum deutlich einfacher. Oliver
Servus, die ARM Toolchain ist nicht nötiger Weise komplexer. Es gibt wunderbar integrierte. Von den freien Toolchains kann ich dir Coocox empfehlen. Wichtig finde ich auch das Thema Debugging. Hier stehen die modernen ARMs meiner Meinung nach besser da als zumindest die Einstiegs Atmegas. Obiges LED Blinke Beispiel hinkt übrigens etwas, da es die Initialisierung komplett zeigt. Ist der Pin konfiguriert, ist das Anschalten der LED auch ein Einzeiler (z.B. GPIOG->BSRRL = GPIO_Pin_10;). LG Jan
>Obiges LED Blinke Beispiel hinkt übrigens etwas, da es die >Initialisierung komplett zeigt. Das ist die KOMPLETTE Initialisierung des Pins beim AVR : >>DDRB |= (1 << PB0);
Manfred Heidener schrieb: > Es heißt dann immer, der AVR ist wesentlich einfacher für den Einstieg, > 100 Seiten Datenblatt statt 1000, etc. Vor einer großen Doku sollte man sich aber nicht scheuen, ganz im Gegenteil: Je umfangreicher sie ist, desto detaillierter ist sie meistens, und man kommt besser damit zurecht. Man muß eine Doku auch nicht vollständig lesen, sie hat oft Kapitel, die einen überhaupt gar nicht betreffen. Man markiert sich darin mit einem Stift oder Marker, was wichtig ist, und schreibt vielleicht noch eigene Notizen hinein. Wenn du einen UART oder CAN-Controller nicht brauchst, laß ihn erst mal links liegen, bis er mal gebraucht wird. "Den" ARM gibts auch gar nicht. Ein Hersteller hat einen ARM-Core gekauft, und setzt diesen in seinen µC ein, die von Hersteller zu Hersteller natürlich unterschiedliche integrierte Peripherie haben. Wenn man möchte, kann man einen ARM auch in Assembler programmieren, und auch LEDs damit blinken lassen. Ich fands für mich gar nicht so schlimm. Ansonsten ist es ja üblich, daß µC-Hersteller und auch Toolchain-Hersteller heute umfangreiche Sammlungen an Codebeispielen frei verfügbar auf ihren Homepages haben. Damit sollte man zurecht kommen können.
Tippgeber schrieb: > die ARM Toolchain ist nicht nötiger Weise komplexer. Doch, da sie eine oft große Anzahlen verschiedener ARM's unterstützen und man erstmal rausfinden muss, wie man den gewünschten einstellt. zB: GCC, AVR, Auswahl des ATmega8: -mmcu=atmega8 GCC, ARM, Auswahl des STM32F4: -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb - nicht gerade intuitiv. > integrierte. Von den freien Toolchains kann ich dir Coocox empfehlen. Coocox ist keine Toolchain, sondern eine IDE. Eine toolchain ist zB GCC. Tippgeber schrieb: > da es die > Initialisierung komplett zeigt. Die fällt aber auch nicht einfach weg, die muss der Programmierer auch hinschreiben, zählt daher zur Komplexität und Bedienungsschwierigkeit hinzu.
Das BeagleBoard oder Raspberry Pi sind ja auch ARM-Boards und da sie angeblich bei Einsteigern so beliebt sind, vermute ich, dass blinkende LEDs dort nicht mit Assembler, auch nicht mit C auf Hardware-Ebene, sondern über darauf laufenden Linux-Programmen gesteuert werden. Ist das so?
Manfred Heidener schrieb: > Ich Programmiere z.B. auf normalen PC's und habe > mir noch nie das Datenblatt eines Quadcore x86_64 angesehen. ein ATMega und ARM wird auch auf einem "normalen PC" programmiert was du wohl eher meinst, ist das dein fertiges Programm auf dem PC ausgeführt wird und auf dem PC läuft ein nicht gerade "kleines" Programm im Hintergrund das dir den kompletten Zugriff auf die im PC verbaute Hardware verdeckt da ist dann egal ob 1Kern, 4Kerne, TFT oder Röhrenmonitor auf den nackten CPUs läuft halt keine WIN-API und es muss alles "selbst" programmiert werden da spielt es dann plötzlich eine Rolle wie komplex die CPU ist aber probier es doch selbst mal aus, dann verstehst du was alle schreiben UB
Dr. Sommer schrieb: > Pin auf output setzen bei AVR:DDRB |= (1 << PB0); Pin 0.0 auf output setzen bei ARM: DIR0 |= 1<<(0); Pin 0.1 auf output setzen bei ARM: DIR0 |= 1<<(1); ...
Stell dir doch mal folgende Frage: Du möchtest in deiner Lieblings-Hochsprache auf dem Bildschirm "Hello World" ausgeben:
1 | #include <stdio.h> |
2 | #include <stdlib.h> |
3 | |
4 | int main(void) { |
5 | puts("Hallo Welt!"); |
6 | }
|
Jetzt nimm einen beliebigen ARM oder AVR und versuch das gleiche. Jetzt fällt bestimmt auch den letzten theoretische-Informatik-Dozenten auf: Die haben gar kein Bildschirm! Die haben in der Regel auch kein Betriebssystem, manchmal nicheinmal eine brauchbare stdio.h! Was tun?! Richtig: Herausfinden, welche Ausgabemöglichkeiten existieren, wie man sie anspricht und welche Bibliotheken es gibt oder schlimmer: noch nicht gibt. Und dafür brauchst du nicht nur "C++ für Manager und andere Dummies", sondern meißt Datenblätter, manchmal sogar Schaltpläne, Registerauszüge etc. (z.B. bei einem 2x16-Zeichen-LCD, das "irgendwie" mit dem ARM oder AVR verbunden ist.) Und wie oben erwähnt: Das Datenblatt des AVR ist dünner, weil weniger Möglichkeiten (zum falschmachen). Dafür ist bei vielen Sachen der ARm bequemer.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.