Ich programmiere derzeit "ATmega328P"s und "ATmega8A"s in C. Nun habe ich aber schon öfter gelesen, dass im professionellen Umfeld eigentlich fast nur mit ARMs gearbeitet wird. Deshalb überlege ich mir, auf ARMs umzusteigen. Nachteil hierbei ist, dass ich irgendwie zu unfähig bin, SMD ordentlich zu löten, weswegen ich dort wohl nur fertige Boards kaufen würde. Mich würden allerdings einmal die Unterschiede zwischen ATmega und ARM interessieren. Und zwar vor allem bei der Programmierung. Ich habe gelesen, dass ARMs wohl keinen Programmer benötigen. Wie werden die dann programmiert? Haben die immer einen Bootloader vorinstalliert oder wie läuft das? Und: ist das vom Prinzip her gleich wie bei den AVRs, also mit den DDRs, PORTs, etc. oder gibt es da wirklich grundlegende Unterschiede? Danke!
Es ist im Prinzip alles gleich - nur etwas ausführlicher. Die Datenblätter der STM32 sind gut aufgebaut. Für die STM32 gibts z.b. einen programmer, den ST-Link. Die haben aber auch einen internen Bootloader, welcher verschiedene Schnittstellen anbietet. Der interne, unveränderliche Bootloader wird über zwei externe Pins des µC aktiviert. Dies kann man z.B. über Taster oder Lötbrücken machen. Die GPIOs des STM32 sind beispielsweise fast genauso simpel, wie die eines AVRs, nur dass bei den verschiedenen Registern auch mal mehrere Positionen einen GPIO ansprechen. Z.B. kannst GPIOA.0 über in analog, in oder out setzen, pull up und pulldowns setzen, etc. Die Peripherie eines STM32 hat in der Regel ganz einfach viel mehr Funktionen. Wenn du diese aber nicht brauchst und einfach nicht verwendest - dann finde ich diese nicht wesentlich komplizierter als einen Atmega. 1. Clock einstellen 2. Clocks der Peripherien einstellen 3. GPIOs parametrieren 4. Peripherie parametrieren. Einen STM32 kannst du nicht verfusen, sofern du die Reset Leitung von SWD verwendest. Der Programmer kostet 18€ netto. Auf reiner C-Ebene merkst du gar nichts, und programmierst wie gewohnt. Nur, dass du halt viel mehr mögliche Interrupts etc. hast. Auch brauchst du nur die üblichen 100nF kerkos, Filter für AVCC und ggf. noch bisschen weiteres Hühnerfutter. Ich rate dir zur üblichen Registerprogrammierung, dann lernst du den Controller richtig gut kennen. Die meisten hier verwenden aber die HAL- und STDLib von ST. CubeMX generiert dir sogar C-Code mit C-HAL für die Initialisierung. Muss jeder selber entscheiden. Der Umstieg lohnt, wenn du die Rechenpower brauchst - der Stromverbrauch wird wesentlich höher sein, als bei 8bitter.
Nils N. schrieb: > Der Umstieg lohnt, wenn du die Rechenpower brauchst - der Stromverbrauch > wird wesentlich höher sein, als bei 8bitter. Wobei das auch nicht in Stein gemeißelt ist. Es gibt sehr sparsame Cortex-M die diverse Sparmodi bieten. Die nötigen Rechenaufgaben schnell mit viel Leistung zu erledigen und dann fix wieder in den Deep-Sleep zu gehen ist kein ganz doofer Ansatz. Man muss sich ggf. halt ein paar mehr Gedanken machen als bei 8-Bittern. Ansonsten stimm ich dir zu. Andere konkrete Unterschiede in der Programmierung: Auf dem ARM kann man ganz schamlos alle Rechenoperationen benutzen (Divisions-Einheit, Barrel-Shifter, ggf. FPU), große Programme mit viel Speicher benutzen, sich keine Gedanken um "PROGMEM" machen, Zeiger in Flash und RAM einheitlich verwenden, nicht mit Timern knausern. Das finde ich sehr praktisch. Die Datenblätter sind z.B. bei den STM32 aber nicht so gut und übersichtlich wie bei den AVR, da muss man oft mehr lesen, allein schon weil viel mehr Funktionalität geboten wird. Bei der Auswahl der IDE wird man von den Möglichkeiten ggf. etwas erschlagen. Das ist aber alles machbar. Dafür kann man mit der selben Toolchain die Controller vieler Hersteller programmieren, sodass dir ein großes Leistungsspektrum zur Verfügung steht.
Was meinst du mit "üblicher Registerprogrammierung"? ASM? Naja, die Rechenpower der AVRs ist meistens schon ausreichend. Durch den höheren Stromverbrauch werde ich aber wohl bei kabellosen Projekten eher bei AVRs bleiben. Aber da werde ich mich zu gegebener Zeit wohl genauer informaieren und herumrechnen. Ich gehe davon aus, dass diese HAL- und STDLib von ST einfach nur C-Libs sind, die den Standard implementieren sowie die Definitionen für die Register, oder? Oder was machen die? Bei Google habe ich nur etwas darüber gefunden, dass diese Libs ein neues "Abstraktionslayer" hinzufügen, um das Programmieren zu erleichtern. Nils N. schrieb: > CubeMX generiert dir sogar C-Code mit C-HAL für die > Initialisierung. Inwiefern "generiert" der C-Code? Woraus generiert der das? Ich bin mir definitiv nicht zu schade, ein paar Zeilen C-Code zu schreiben. Ich mag C und ziehe es vielen anderen höheren Programmiersprachen eindeutig vor. Allerdings ziehe ich es auch ASM vor, wenn es sein muss, geht aber sonst auch das.
Du kannst den Arduino Zero (Atmel Cortex-M0)benutzen und du wirst keinen Unterschied zum ATmega328 merken. Alles wie gehabt in der Arduino IDE. Oder ein Nucleo-F446RE für den Sprung in die CubeMX/Eclipse Welt. Gruß, dasrotemopped.
Die Register Defines und ein paar Grund-Funktionen kommen von CMSIS. Das ist eine Library, die direkt von ARM kommt. Darauf bauen dann die STDLib bzw HAL auf. Auf STDLib und HAL kannst du gut verzichten, aber CMSIS ist ganz brauchbar. Ein großer Unterschied ist noch, dass du dich mit dem Startup Code und dem Linkerscript beschäftigen musst bzw ein fertiges verwenden musst.
dasrotemopped schrieb: > Du kannst den Arduino Zero (Atmel Cortex-M0)benutzen und du wirst keinen > Unterschied zum ATmega328 merken. Alles wie gehabt in der Arduino IDE. Von Arduino hat der TO hier nix geschrieben. Wie kommst Du darauf, dass er bisher Arduino genutzt hat? atmega-fanboy-;-) schrieb: > Was meinst du mit "üblicher Registerprogrammierung"? ASM? Nein, damit ist Lesen/Schreiben der µC-Register in C (CMSIS-Lib) gemeint - ohne den Umweg über die Abstrahierende CubeMX-Lib zu machen, welches teilweise das Programm doch arg ausbremst.
:
Bearbeitet durch Moderator
CubeMX ist ein grafisches Programm, in dem man die Pins/Timer/Peripherie konfiguriert und sich daraus C Code bzw ein Projekt erstellen lässt.
atmega-fanboy-;-) schrieb: > Mich würden allerdings einmal die Unterschiede zwischen ATmega und ARM > interessieren. Und zwar vor allem bei der Programmierung. > Ich habe gelesen, dass ARMs wohl keinen Programmer benötigen. Wie werden > die dann programmiert? Haben die immer einen Bootloader vorinstalliert > oder wie läuft das? Also erstmal eines: ARM's gab und gibt es viele unterschiedliche. Was du sicherlich meinst, sind die derzeitigen Produkte, die für Bastler interessant sind und das sind Cortex M0 bis Cortex M4F. Ja, manche derartigen Chips haben einen residenten Bootlader an Bord, das sind vornehmlich die LPCxxx von NXP und die STM32Fxxx von ST. Diese kann man mit ner seriellen Strippe programmieren. Es gibt bei den LPCxxx auch Typen, die einen Bootlader an Bord haben, welcher seinerseits per USB funktionieren kann. Das ist mit Abstand die bequemste Art, denn der Bootlader tut so, als sei er ein kleiner USB-Stick. Ranstecken, im Dateimanager auf diesen "Stick" gehen, die Datei "Firmware" löschen und ne neue draufkopieren. Das war's. Alle anderen ARM-Cortexe - also die, welche keinen Bootlader haben - muß man über ein anzuschaffendes Programmiergeschirre namens JTAG/SWD-Adapter programmieren. Das ist zwar die schnellste Art, aber auch die aufwendigste in jedem Sinn: Man braucht den Adapter selbst (und den gibt's nicht wirklich umsonst, wenngleich heutzutage drastisch billiger als vor 10 Jahren), wobei der Segger J-Link sozusagen der Klassenprimus ist und alle anderen eher die popligeren Dinger, die nur für die Chips ihres jeweiligen Herstellers gedacht sind. Man braucht aber auch die PC-Software zum jeweiligen Adapter. Die von Segger ist exzellent, aber eben kommerziell und kostet, anderes Zeugs ist hingegen OpenSource, kostenlos und fummelig, eben nicht exzellent. Dazwischen gibt es ne Grauzone: J-Link's aus China, OnBoard-J-Link's auf diversen Eval-Boards verbaut und ggf. wieder abgebaut, zum J-Link umgeflashte ST-Links oder deren Pendant von NXP, die NuLink's von Nuvoton und weiß der Geier was sonst noch. Wichtig zu wissen ist, daß die Programmierung eines µC mit so einem Adapter immer daraus besteht, daß ein im Adapter (oder in dessen PC-Software) gespeichertes Mini-Programm (quasi ein Bootlader) in den RAM des Ziel-µC's geschleust wird. Diese Mini-Programm erledigt dann die eigentliche Programmierarbeit im µC, wobei der eigentliche Adapter dafür nur das Transportmedium für die Programmierdaten ist. Aber das geht dank USB schneller als per Serieller. Die Kehrseite ist, daß diese Mini-Bootlader chipspezifisch sein müssen. Eigentlich logisch - und man kann deshalb eben nicht erwarten, mit einem grad vorhandenen Adapter alle möglichen Cortexe programmieren zu können. Der Programmieradapter MUSS den betreffenden Chip kennen, sonst wird nix draus. Ansonsten ist der Unterschied der 32 Bit Controller zu den 8 Bit Controllern so, daß man problemlos fast alles in long rechnen kann, denn das geht in einem Wutsch. Alle Klimmzüge zum Sparen von Rechenbreite, die auf einer 8 Bit CPU wichtig waren, sind überflüssig geworden. Auch die Benutzung von Portpins unterscheidet sich zum Teil erheblich - man kann eigentlich immer auf mehrere verschiedene Arten auf Portpins zugreifen. Zumeist mittels W/O-Registern zum Setzen oder Löschen von Portpins. Bei einigen Typen gibt es neben dem traditionellen Zugriff auf die Ports Speicherbereiche, in denen jedes einzelne Portpin als ein 8, 16 oder 32 Bit Boolean ansprechbar ist. Adreßraum ist ja genug vorhanden. W.S.
Am besten probierst du einfach mal einen billigen ARM Controller aus. Meine kleine Anleitung könnte dabei hilfreich sein: http://stefanfrings.de/mikrocontroller_buch2/index.html Ich vermute mal, das du bereits alle nötigen Bauteile und Werkzeuge besitzt, außer halt das µC Modul, und das kostet nur ca. 2 Euro.
> Nachteil hierbei ist, dass ich irgendwie zu unfähig bin, SMD ordentlich > zu löten, weswegen ich dort wohl nur fertige Boards kaufen würde. Dadrauf wird es langfristig wohl ohnehin hinaus laufen, egal welchen modernen µC man verwenden wird. > Unterschiede ... bei der Programmierung. Eigentlich gibt es da keine großen Unterschiede. Die mir bekannten ARM Controller haben mehr Speicher und mehr Funktionen. Daher muss man je nach Anwendung auch mehr Register beschrieben, um eine Schnittstelle zu konfigurieren. Bei STM brauchst du ein Datenblatt wegen der Pinbelegung und zusätzlich ein Reference-Manual für die Beschreibung der Register. Insgesamt viele hundert Seiten. Bei AVR ist der Lesestoff weniger umfangreich. Die STM32 haben zwischen den Peripherie-Funktionen (z.B. Timer) und der CPU einen Interrupt-Controller, der Prioritäten verwalten kann. Für die ersten Schritte ist nur wichtig, dass du Interrupts auch dort erlauben musst, sonst kommt am CPU kern nichts an. Bei STM32 muss man so ziemlich jede Peripherie Modul vor der Benutzung einschalten (= Takt und Prescaler einstellen). > Ich habe gelesen, dass ARMs wohl keinen Programmer benötigen. STM32 kannst du wahlweise über JTAG, SWD und UART programmieren. Manche von den großen können auch CAN und USB. > Haben die immer einen Bootloader vorinstalliert? Ja, für UART, CAN und USB. Der Bootloader wird typischerweise über 1-2 Jumper aktiviert. > ist das vom Prinzip her gleich wie bei den AVRs, also mit den DDRs, > PORTs, etc. oder gibt es da wirklich grundlegende Unterschiede? Abgesehen davon, dass die I/O Ports mehr Features haben würde ich schon sagen, dass es bei STM32 im Prinzip gleich funktioniert. Neben STM32 gibt es natürlich auch andere ARM Controller, aber ich kenne ich mit denen gar nicht aus.
> Ich gehe davon aus, dass diese HAL- und STDLib von ST einfach nur C-Libs > sind, die den Standard implementieren sowie die Definitionen für die > Register, oder? Nein, das wäre die CMSIS, da sind die Register definiert und eine Handvoll Standard Funktionen, die den CPU Kern betreffen. Sowohl HAL als auch Standard-Periheral-Lib (SPL) sind Hardware-Abstraktions Libraries (ähnlich zu Arduino), die beide auf CMSIS aufbauen. Die SPL ist veraltet. Kann man verwenden, muss man aber nicht. Die Standard C Funktionen werden zusammen mit dem C Compiler bereit gestellt. Beim gcc heisst die "newlib" (entsprechend der Dir bekannten avr-libc). > Inwiefern "generiert" CubeMX C-Code? Woraus generiert der das? Probiere es aus. Du stellst in einer grafischen Oberfläche ein, welche Pins du wo für benutzen willst (Eingang, Ausgang, Analog, Pull-Ups, Taktfrequenz, etc) und dann generiert Cube HAL ein komplette Projekt mit dem entsprechenden C-Code der diese Initialisierungen vornimmt. Cube HAL stellt darüber hinaus Libraries für Schnittstellen bereit, zum Beispiel USB. > Ich bin mir definitiv nicht zu schade, ein paar Zeilen C-Code > zu schreiben. Dann rate ich Dir, erstmal nur die CMSIS zu benutzen. Wenn du damit die Grundlagen verstanden hast, wirst du den von Cube HAL erzeugten Code besser verstehen und kannst notfalls auch besser Fehler erkennen und beheben. Apropos Fehler: Mein allererstes LED-Blinker Programm versagte schon, weil Cube-HAL den Takt falsch konfigurierte. So etwas bleibt im Kopf hängen.
Vielen Dank an euch alle, da habt ihr mir auf jeden Fall viel Input gegeben! Wenn ich euch richtig verstanden habe, sollte ich mich aufgrund von größeren Unterschieden auf einen ARM festlegen, richtig? Die Kombination aus einem Board der STM32-family und einem ST-Link Programmer scheint recht vielversprechend zu sein. Vor allem auch preislich. Funktionsumfang müsste ich mir erst noch einmal genauer ansehen. Irgendwelche Meinungen dazu?
Also klar, Geld spielt eine Rolle. Da gibts schon ein Unterschied ob du dich für STM oder Atmel entscheidest. Aber z.B. die Atmel SAM4L oder SAM4S Boards liegen bei ca 40-50€, klar gibts auch die mit den größeren µC (SAM4E) für über 100€. Bei den Boards ist ein Programmer/Debuger verbaut, also ein USB ist zum Programmieren und Debugen, den anderen USB kannst als Device nutzen. Ich bin Berufsbedingt von Hobby AVR Programmierung zum ARM gekommen und wurde so gesehen ins kalte Wasser geworfen und durch Zufall war es ein Atmel, somit bin ich in der Familie geblieben. Es gibt bei STM sowie Atmel Vor- und Nachteile. Ist irgendwie eine Religion für sich, für welche man sich entscheidet :) Hatte früher aber auch mit STM32 zu tun, zwar eher im Application-Layer aber eigentlich tun die sich bedingt durch den ARM Core alle nichts. Kennst einen kennst sie alle :-D Hoffe du teilst uns mit wie du dich entschieden hast.
> Wenn ich euch richtig verstanden habe, sollte ich mich aufgrund von > größeren Unterschieden auf einen ARM festlegen, richtig? Das würde ich nicht sagen. Ich habe mich mit zahlreichen 8bit Controllern und neuerdings auch mit STM32 vertraut gemacht. Dennoch bevorzuge ich die kleineren 8bit Controller (sofern sie denn zur Anwendung passen), denn sie sind einfacher zu programmieren. Ich halte es für einen Fehler, sich festlegen zu wollen. Denn es gibt alle paar Jahre was besseres, billigeres oder interessanteres.
Adam P. schrieb: > Also klar, Geld spielt eine Rolle. Natürlich spielt der Preis auch eine Rolle. Vor allem, da ich eventuell natürlich für mehrere Projekte auch mehrere Boards brauche, wenn die Schaltungen weiterlaufen sollen. 40€ pro Board würde ich da schon eher als Maximum angeben. Aber ich nehme auch nicht das billigste, wenn es etwas mit besserem Preis-/Leistungsverhältnis gibt. Dabei bin ich nur auf euren Rat angewiesen. Adam P. schrieb: > Es gibt bei STM sowie Atmel Vor- und Nachteile. Was sind denn deiner Meinung nach so die Vor-/Nachteile jeweils?
Viele STM32 Controller enthalten zum Beispiel eine batteriegepufferte RTC und USB. Bei AVR gibt es nur wenige Modelle mit USB und soweit ich weiß keine mit RTC. Dafür haben fast alle AVR's ein eingebautes EEprom dessen Zellen sehr viel häufiger Beschreibbar sind, als der Flash Speicher. STM32F1 haben kein EEprom. Die AVR's eignen sich aufgrund ihres weiten Versorgungsspannungs-Bereiches hervorragend für Batteriebetrieb ohne Spannungsregler. Die STM32 sind da nicht ganz so flexibel. Die AVR's liefern bis zu 40mA an ihren I/O Pins, STM32F1 schaffen gerade mal halb so viel. Dafür haben die meisten STM32F1 Chips mehr RAM und Flash als AVR's. Die zahlreichen I/O Features schaust Du Dir am besten mal selbst in einem Referenzhandbuch an. Da bekommst du für vergleichbares Geld wesentlich mehr Features und mehr Menge. Aber mehr ist nicht unbedingt besser - vor allem wenn du dafür keine Anwendung hast.
Nils N. schrieb: > Es ist im Prinzip alles gleich - nur etwas ausführlicher. Die > Datenblätter der STM32 sind gut aufgebaut. Die Datenblätter bringen bloß nicht viel. Zum Programmieren braucht man das jeweilige Reference Manual.
Achso, wenn ich Adam P. richtig verstanden habe, ging es um Atmel oder ST ARM-µC. Atmel hat schließlich auch ARM microcontroller im Angebot. Oder habe ich das falsch verstanden? Trotzdem eine interessante Liste, danke. Noch zwei Fragen: ist die erwähnte Batterie in STMs integriert? Lädt die sich wieder auf oder kann die tatsächlich leer werden? Dadurch, dass ich wenn dann nur ARM-Boards kaufen würde, ist der zweite Nachteil wohl nicht allzu gravierend, da EEPROM wenn dann wohl schon auf dem Board aufgelötet sein wird. Gehen dafür aber I/O-Pins "verloren"? Oder haben die Boards üblicherweise gar keinen EEPROM-Speicher?
Stefan U. schrieb: > Dafür haben fast alle AVR's ein eingebautes EEprom dessen Zellen sehr > viel häufiger Beschreibbar sind, als der Flash Speicher. STM32F1 haben > kein EEprom. Das ist aber nicht so schlimm, schließlich kann man auch den integrierten Flash beschreiben. Ein echtes EEPROM kann zwar ca. 10x häufiger beschrieben werden, dafür ist der Flash der STM32 aber auch viel mehr als 10x größer als der EEPROM der AVR's. Durch cleveres Wear-Leveling kann man das Problem also ausgleichen. Es ist wohl billiger 10kB Flash als 1kB EEPROM zu integrieren, denn einen Flash-Die hat man eh im Controller, aber für EEPROM bräuchte man wohl noch einen weiteren Prozess bei der Herstellung. Ist halt nur von der Programmierung her etwas umständlicher, gibt's aber Bibliotheken für. Das Hauptproblem besteht darin, dass das Programm im Flash während des Schreibens stehen bleibt (es sei denn man hat einen Controller mit 2 Flash-Banken, oder führt aus dem RAM aus). atmega-fanboy-;-) schrieb: > ist die erwähnte Batterie in STMs integriert? Nein. Du brauchst eine externe, z.B. in Form einer Knopfzelle oder Supercap. Eine CR2032 hält da theoretisch 5-10 Jahre, das sollte als Wechsel-Intervall meistens akzeptabel sein. Einen zusätzlichen 32kHz-Quarz braucht's auch, den haben viele Boards aber. atmega-fanboy-;-) schrieb: > da EEPROM wenn dann wohl schon auf > dem Board aufgelötet sein wird. Haben manche, aber nicht alle. Ist aus o.g. Gründen auch nicht nötig. atmega-fanboy-;-) schrieb: > Gehen dafür aber I/O-Pins "verloren"? Für SPI oder I²C zur Ansteuerung eines externen EEPROM braucht man natürlich Pins.
Beitrag #5318857 wurde von einem Moderator gelöscht.
Welche Fragestellung genau lässt dich zu diesem Schluss kommen? Ich möchte nur wissen, was für ein Aufwand es z.B. ist, meine bestehenden Libs umzuschreiben. Das scheint aber wohl nicht allzu umfassende Änderungen zu erfordern. Dass ich es dennoch nicht wöchentlich neu machen will, ist hoffentlich klar, weswegen ich vllt. eine Frage mehr gestellt habe. Dieser Thread hier hat mich aber überzeugt, dass sich ein Umstieg durchaus lohnen kann. Es wird jetzt für den Anfang die nächsten paar Monate erst einmal ein SMT32-Board werden. Vielen Dank für eure Hilfe!
Bei den ARM Cortex-M habe ich eine grössere Spanne zwischen klein (M0, z.B. LPC8xx oder STM32L0xx) und ganz gross (LPC54xxx, LPC4088, STMF4xx, STMF7xx). Dazu viel umfangfreiche Peripherie, LPC sind zB angenehm weil viel 32 Bit Zähler, bei STM finde ich mehr in Richtung Display oder Speicheransteuerung (ja, haben andere auch). Das alles so in den Griff zu kriegen das man 'mal eben' dieses oder jenes realisieren kann kostet schon viel Einarbeitung. Bei den kleinen kann man schön Batteriebetriebene Sachen bauen die sehr stromsparend sind, aber alleine das hat viele Tücken und man muss viel im Datenblatt stöbern. Aber letzendlich ist das alles möglich, genauso wie rasend schnelle Displayansteuerung mit viel Hardwareunterstützung. Wenn man low Level anfangen möchte und mit Datenblättern klarkommt und man für eine Toolchain Installation nicht den Klempner anrufen muss dann kann ich sowas wie LPC812 oder LPC824 empfehlen. Die sind SMD, muss man aber nur einmal auf einen Adapter gelötet bekommen (in YouTube sind in der Suche wohl auf Nr.1 Kussanleitungen, aber man findet auch Hilfe zum SMD löten :-)). Quarz braucht man nicht, nur noch einen USB-seriell Adapter um das Programm per Bootloader in den Chip zu bekommen. Die µC Hobbyanwender mögen gerade besonders die STM µCs weil die von den Chinesen sehr billig in den Briefkasten geliefert werden. BluePill oder Maple Board mit dem F103 ist hier ein Stichwort, aber selbst die F407 Boliden mit 512k oder 1M Flash sind inzwischen für ca. 10€ zu haben. LPC mag ich lieber, aber preislich können die nicht dagegen anstinken. Wenn man die nicht mehr mit EMACS und Datenblatt programieren möchte gibt es hier mittlerweile massig Unterstüztung: Arduino ist nicht mehr auf AVR beschränkt (STM32duino), mbed als Alternative gibt es schon lange, IDEs mit einfacher Installation gibt es mehrere (SW4STM32, MCUXpresso, Eclipse + GnuMCUEclipse, EmBitz, professionelle von Keil oder Segger als Demo uvm). Aber man muss sich damit beschäftigen und viel lesen. Als ich vor ca. 14 Jahren wieder in µCs eingestiegen bin war zB der Standard die Atmel AVR. Da gab es die Grabenkämpfe wenn jemand behauptet hat AVR/PIC/8051 sei besser... Und an Standardfehlern wie 'an PortC funktionieren einige Bits nicht' konnte man sich auch Stunden aufhalten und das Problem wurde hier jede Woche aufs Neue gepostet. Genauso muss man seine 32 Bit Pappenheimer kennenlernen wenn man schnell was zaubern möchte. TL;DR ich weiss... for short: guck dir mbed an :-)
atmega-fanboy-;-) schrieb: > Was meinst du mit "üblicher Registerprogrammierung"? ASM? ARM ASM ist cool :-) Timer Blinky: .timer STMDB SP!, {R0-R1} ; push to stack ADR R1, toggle LDR R0, [R1] RSBS R0, R0, #1 ; toggle = 1 - toggle (and set flags) STR R0, [R1] MOV R0, #1 MOV R0, R0, LSL #21 ; pin 21 ; toggle = 1 LED on = high MOVNE R1, #&1C ; GPSET0 (offset &1C to gpio base address) ; toggle = 0 LED off = low MOVEQ R1, #&28 ; GPCLR0 (offset &28 to gpio base address) STR R0, [R12, R1] ; store GPSET0 or GPCLR0 LDMIA SP!, {R0-R1} ; pop from stack MOV PC, LR ; return
Beitrag #5318898 wurde von einem Moderator gelöscht.
Beitrag #5318901 wurde von einem Moderator gelöscht.
Beitrag #5318907 wurde von einem Moderator gelöscht.
Beitrag #5318911 wurde von einem Moderator gelöscht.
Hier aus Spaß ein vollständiges Beispiel in Assembler für dem STM32F103RB, wie mithilfe eines Timer-Interrupts die LED an PA5 geblinkt werden kann. Durch geschickte Nutzung des BSRR-Registers spart man sich auch die Fallunterscheidung. Geht mit PWM-Modus des Timers natürlich kürzer, aber das wär ja langweilig. Beim AVR sinds vermutlich ein paar Zeilen weniger, weil dessen Peripherie halt einfach weniger Bits hat, die man setzen kann. Aber ist das schlimm? Will man das überhaupt in Assembler programmieren? Zugriff auf Peripherie ist in ARM-Assembler immer etwas umständlicher, weil man die langen Adressen laden muss. Der AVR kann die Adressen teilweise direkt in die Instruktionen kodieren, das ist bei den 32bit-Adressen und 16/32bit-Instruktionen des ARM halt nicht möglich. Dafür kann der ARM auch großen Speicher linear adressieren ohne dass man mit Bank-Umschaltungen und verschiedenen Adressbereichen rumhantieren muss. Das "Problem" welches der ARM aufgrund der langen Adressen hat wirkt sich auf C nicht aus, das Problem welches die AVR aufgrund der kurzen Adressen haben hingegen schon (PROGMEM und Konsorten)!
Oh, es fehlt das ".thumb_func" vor den beiden ISRs. Ohne das geht's kurioserweise mit Debugger dran, aber nicht ohne (vermutlich weil der den Thumb-Mode forciert).
G. B. schrieb im Beitrag #5318901: > Die AVR Variante käme mit der Hälfte des Codes aus 8051 dank Bit-Memory mit einem Viertel. ARM ASM ist trotzdem cool :-) Werden ganze Betriebssysteme mit gemacht: https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/HAL/OMAP5/s/GPIO?rev=1.1.1.1;content-type=text%2Fplain
W.S. schrieb: > und alle anderen eher die popligeren Dinger, die nur für die Chips ihres > jeweiligen Herstellers gedacht sind. Naja, gedacht vielleicht, aber da die Programmier- und Debug-Schnittstellen von ARM genormt sind, sind die Tools letztlich dennoch generisch. Nur die (Convenience-)Software der Hersteller ist es nicht. Als wir mal für einen Kunden einen STM32 statt der sonst bei uns benutzten Atmel-ARMs benutzt haben, habe ich mein Atmel-ICE einfach auf dem Tisch liegen lassen. :) Geht natürlich nur mit herstellerunabhängiger Software, also hier OpenOCD. Diese Teile würde ich keineswegs als „popelige Dinger“ abstempeln, nur weil sie nicht die goldenen (und in der Vollversion entsprechend teuren) Buchstaben „Segger“ haben. (Die alten Segger-ICEs, die Atmel früher benutzt hat, bleiben bei uns eher im Schrank liegen. Die klobigen 20poligen Stecker benutzt eh' niemand mehr hier im Umfeld, und auch die Adapter lässt sich Segger ja vergolden.)
:
Bearbeitet durch Moderator
Ich habe auch den Eindruck, dass kleine Testprogramme auf ARM sehr viel größer sind, insbesondere wegen der Interrupt Vektor Tabelle und dem Initialisierungscode, der noch vor der main() Funktion ausgeführt wird. Ein simpler LED Blinker in C umfasst schon fast 1kB Code (mit HAL noch viel mehr). Außerdem sind alle ARM Befehle mindestens 16bit groß, während der AVR einige 8bit Befehle hat. Auch das führt zu mehr Bedarf an Flash Speicher. Davon ist jedoch reichlich vorhanden und je größer das eigene Programm wird, umso weniger fällt der größere Initialisierungs-Code in Gewicht. Mir ist noch ein ein angenehmer Vorteil von ARM versus AVR eingefallen: Bei Strings muss man als C Programmierer nicht mehr zwischen RAM und Flash unterscheiden, da beide Speicher im selben Adressraum liegen. Dadurch entfällt das bei AVR standardmäßige Kopieren aller Strings ins RAM. Und die bei AVR bekannten Methoden, die das Kopieren verhindern, entfallen ebenfalls: PROGMEM, PSTR, und die ganzen "_P" Funktionen wie printf_P().
> angenehmer Vorteil von ARM versus AVR
Das konnte Mann auch schon mit 16 bit Architekturen haben.
Wenn es denn alles in die 64 kByte gepasst hat.
Gott sei Dank sind kleine 32 Bitter mittlerweile billiger.
Stefan U. schrieb: > Bei Strings muss man als C Programmierer nicht mehr zwischen RAM und > Flash unterscheiden, da beide Speicher im selben Adressraum liegen. Die AVR XMegas sind auch so aufgebaut. > Dadurch entfällt das bei AVR standardmäßige Kopieren aller Strings ins > RAM Warum sollten Strings bei AVR standardmäßig ins RAM kopiert werden müssen? Die können schön im Flash bleiben und lassen sich auch von dort wunderbar verwenden, der RAM ist doch dafür viel zu kostbar. Generell muss man sich bei ARM aber weniger Sorgen um ausgehende Ressourcen machen. Das hat freilich alles seinen Preis.
> Warum sollten Strings bei AVR standardmäßig ins RAM > kopiert werden müssen? Frage das die Entwickler des C-Compilers und dessen Library. Der tut es halt, sofern du nicht ausdrücklich PROGMEM oder PSTR benutzt. Eine mögliche Erklärung: Weil Strings in C normalerweise veränderbar sind. Wenn der Compiler sie normalerweise nicht ins RAM kopieren würde, dann wären sie normalerweise NICHT veränderbar. Vermutlich ist das Standard-Verhalten irgendwo in der Spezifikation der Sprache festgelegt.
Stefan U. schrieb: > Frage das die Entwickler des C-Compilers und dessen Library. Der tut es > halt, sofern du nicht ausdrücklich PROGMEM oder PSTR benutzt. Oh Entschuldigung. Diese Einschränkung des C-Programmierens war mir nicht bewusst. Kannte ich als ein Asm-Programmierer mit allen Freiheiten noch nicht :)
Jörg N schrieb: > Generell > muss man sich bei ARM aber weniger Sorgen um ausgehende Ressourcen > machen. Das hat nichts mit ARM zu tun sondern damit was für einen Typen man sich im Katalog aussucht und bestellt. Es gibt auch AVR mit mehr als genug Flash und RAM und es gibt auch Cortexe im Sub-Euro Bereich mit einstelligen Kilobytes und noch weniger RAM.
Stefan U. schrieb: > Eine mögliche Erklärung: Weil Strings in C normalerweise veränderbar > sind. String Literale normalerweise nicht, es sei denn man initialisiert ein Array damit. Das Problem ist halt, dass man einem Pointer nicht ansieht ob er in den RAM oder Flash zeigt. Daher wird beim Zugriff standardmäßig RAM angenommen. Daher müssen Strings halt auch im RAM sein. Wenn man sie in den Flash packt, muss man das beim Auslesen wissen und die LPM Instruktion statt LD nutzen. Das Problem hat man beim ARM halt nicht, da kann man Flash, RAM, Peripherie Register etc alles über die gleiche LDR Instruktion auslesen. Stefan U. schrieb: > Auch das führt zu mehr Bedarf an Flash Speicher. Macht zum Glück nix weil die ARMs davon einfach mehr haben! Dafür braucht man nur ein printf, und nicht noch eine Version printf_P für Flash Strings... Es kann ja mal jemand eine Timer Blinker Version für AVR oder 8051 Posten zum Vergleich.
Stefan U. schrieb: > Ein simpler LED Blinker in C umfasst schon fast 1kB Code Habe mal nachgesehen: auf dem LPC800 M0 in C 360B und in ASM 230B > kleine Testprogramme auf ARM sehr viel größer sind M0 Programme sind größer als auf AVR aber M3 Programme sind meist ähnlich oder kleiner, wegen bedingter Befehlsausführung. Darf man natürlich nicht die CMSIS dran linken, da ist z.B. bei NXP deutlich mehr drin als der ARM Standard. Die passts auf den kleinsten LPC800 gar nicht drauf :-)
Dr. Sommer schrieb: > Das Problem hat man beim ARM halt nicht, da > kann man Flash, RAM, Peripherie Register etc alles über die gleiche LDR > Instruktion auslesen. Geht bei Xmega auch. > Macht zum Glück nix weil die ARMs davon (Flash) einfach mehr haben! Sag ich doch. Dr. Sommer schrieb: > Es kann ja mal jemand eine Timer Blinker Version für AVR oder 8051 > Posten zum Vergleich. Erstmal bräuchte man überhaupt etwas zum Vergleich- der Code oben scheint mir jedenfalls nicht vollständig weil jegliche Initialisierung fehlt. Beim AVR kann man sofort nen Pin auf Output stellen und den toggeln. Mit ner kleinen Delay-Schleife oder Timereinsatz sind das geschätzt 20 Instruktionen...
Dr. Sommer schrieb: > Timer Blinker Version für ... 8051 ORG 0000H MOV TMOD, #00000010B ; timer 0 repeat mode MOV TH0, -#100 ; 100 Zyklen MOV IE, #10000010B ; timer 0 interrupt enable SETB TR0 ; timer 0 start loop: JMP loop ORG 000BH ; timer 0 interrupt CPL P1.0 ; eine LED am Pin 1.0 toggeln RETI
Jörn N schrieb: > Geht bei Xmega auch. Ok, den hab ich noch nicht benutzt. Jörn N schrieb: > Erstmal bräuchte man überhaupt etwas zum Vergleich- der Code oben > scheint mir jedenfalls nicht vollständig weil jegliche Initialisierung > fehlt. Mein Beispiel ist vollständig: Beitrag "Re: Unterschiede zwischen ARM und ATmega in der Programmierung" Jörn N schrieb: > Beim AVR kann man sofort nen Pin auf Output stellen und den toggeln. Das geht beim ARM auch. Interessanter wirds mit Timer und Interrupts. Lothar schrieb: Ok, das ist tatsächlich viel kürzer. Aber kommt man so da auch auf 1Hz Interrupt-Frequenz oder muss man da per Software zählen? Und Push-Pull-Outputs hat man so auch nicht ;-)
Ich glaube nicht, dass der TO vor hatte, solche kleinen Details zu vergleichen.
Dr. Sommer schrieb: > Ok, das ist tatsächlich viel kürzer. Aber kommt man so da auch auf 1Hz > Interrupt-Frequenz oder muss man da per Software zählen? Und > Push-Pull-Outputs hat man so auch nicht ;-) Gibt ja genügend 8051 derivate, gehe ich jetzt mal von einem z.b silabs 8051aus (Z.b. Efm8BB oder LB), der takt wäre def. 24,5Mhz/8 dann noch der default Teiler von 12 für den Timer und wir sind etwa bei knapp 400us toggle rate. Mit den 8Bit wären keine sec drin. Hab jetzt nicht im kopf ob per default der wtd reset als reset Quelle aktiv ist, der wtd selbst ist es.. Die ports sind open drain, auf gnd ziehen geht. Allerdings finde ich irgendeine Art der Bewertung von mcu's anhand eines blinkys für recht banane..
Jörn N schrieb: > Beim AVR kann man sofort nen Pin auf Output stellen und den toggeln. Bei manchen ARMs auch, Z.B. beim MKE04 von Freescale, das ist GPIO ab Reset schon aktiv und die Benutzung erschreckend simpel: 1-Bit ins PDDR schreiben um ihn als Ausgang zu schalten und dann 1-Bit ins PTOR schreiben um ihn zu toggeln. Der KE04 ist ungefähr so kompliziert oder einfach zu handhaben wie ein ATmega. Ab Reset läuft er mit 24MHz (FLL aus dem internen RC-Oszilator) und mit einem(!) Schreibzugriff ins CLKDIV Register stellt man ihn entweder auf die vollen 48MHz oder macht ihn langsamer wenn man Strom sparen will, keine weiteren Maßnahmen erforderlich (nur den Watchdog muss man bedienen oder kurzerhand ausschalten), GPIO ist ab Reset schon benutzbar (default ist Eingang ohne Pullup), Perpheriegeräte greifen sich den Pin automatisch wenn deren Funktion aktiviert wird, genau wie beim AVR. Und 5V kann er auch. Und kosten tut er weniger als einen Euro, 60Ct in Stückzahlen. Man muss nicht immer die mega-komplizierten STM32 als Referenz für alle Cortexe dieser Welt hernehmen, das ist eine völlig verzerrte Wahrnehmung.
:
Bearbeitet durch User
Stefan U. schrieb: > Ich glaube nicht, dass der TO vor hatte, solche kleinen Details zu > vergleichen Nö, der TO hatte nur vor die ewige Diskussion mal wieder loszutreten und sich Popcorn zu holen ... :-)
Stefan U. schrieb: > Neben STM32 gibt es natürlich auch andere ARM Controller, aber ich kenne > ich mit denen gar nicht aus. Und dann postest du hier wild drauflos? Als ob die Welt der 32 Bitter im Allgemeinen, die Welt der ARM-Controller im Näheren und die Welt der Cortexe M0..4 im Besonderen nur aus STM32 bestünde??? Grrmpf... W.S.
Stefan U. schrieb: > Ich glaube nicht, dass der TO vor hatte, solche kleinen Details zu > vergleichen. Ist durchaus interessant zu lesen. Schaden wird es ja wohl nicht. ;) Eine Frage hätte ich allerdings noch: Wie genau ist der Takt bei ARMs so? Sollte ich da lieber auf Quarze setzen, wenn eine genaue Zeitmessung (+- paar µs) erforderlich ist oder sind die Abweichungen da nicht so groß? Danke auf jeden Fall noch einmal an alle!
Ein paar µS Timerinterrupt Sekunden schafft auch ein AVR relativ genau mit internen Quarz. 8MHz * 0,00002µs = 160 Takte für 20us
atmega-fanboy-;-) schrieb: > Wie genau ist der Takt bei ARMs so? Sollte ich da lieber auf Quarze > setzen, wenn eine genaue Zeitmessung (+- paar µs) erforderlich ist oder > sind die Abweichungen da nicht so groß? Das hängt vom konkreten Modell ab. Die Frage ist, wie lang die Periode ist, auf der du auf µs genau messen willst! Es dürfte aber ähnlich wie bei allen Controllern so sein, dass man meistens doch einen Quarz braucht, insbesondere für Kommunikations-Schnittstellen. Der ist auf den Eval Boards sowieso immer vorhanden. Beispielsweise beim STM32F103 hat der interne RC-Oszillator "HSI" ab Werk eine Toleranz von -2% bis 2.5% bei 8MHz. Nils N. schrieb: > Ein paar µS Timerinterrupt Sekunden schafft auch ein AVR relativ > genau > mit internen Quarz. Es gibt keinen internen Quarz, nur interne RC-Oszillatoren. Und diese Angabe der Auflösung sagt nicht viel aus.
Jörg W. schrieb: > Naja, gedacht vielleicht, aber da die Programmier- und > Debug-Schnittstellen von ARM genormt sind, sind die Tools letztlich > dennoch generisch. Generisch? Was nützt das denn, wenn der Flash-Algorithmus des einen Chips eben nicht mit dem des anderen Chips übereinstimmt? Das einzige Teil, was wirklich generisch war (und brechreizmisearabel dazu) war der originale Wiggler am Druckerport. Ansonsten wegen des Wortes "gedacht": Mir ist klar, daß man aus einem chinesischen Bluepill-Brettl für 1.20€ einen ST-Link und daraus einen J-Link machen kann - wenn man das partout will. Aber das will ich nicht weiter diskutieren und vermutlich auch du nicht, gelle? Ich habe hier nicht umsonst mein kleines STM32-Brennprogramm gepostet, damit auch für die STM32 eine handliche Programmiermöglichkeit via Bootlader existiert. Für die LPC's gibt es ja den FlashMagic. W.S.
Für den STM Bootloader gibt es https://sourceforge.net/p/stm32flash/wiki/Home/ Der Takt vom internen RC-Oszillator ist stark temperaturabhängig, für eine Frequenzmessung sollte man da schon einen Quarz spendieren. Die meisten ARM geben sich da mit günstigen 8...12 MHz Standarttypen zufrieden und man stellt den Takt über PLL+Teiler ein, da sind die alle sehr flexibel bis unübersichtlich. Zum Strom sparen kann man bei den kleinen die PLL abschalten und liegt dann bei wenigen µA Stromverbrauch. Das ist ein Kapitel was man gegenüber den AVR zusätzlich lesen muss, aber es gibt mittlerweile viele Beispiele oder Hilfsmittel um den Takt zu konfigurieren.
Also hier mal "Butter bei die Fische". Die Geschichte von ARM erzählt von der Entwicklerin: https://www.youtube.com/watch?v=jhwwrSaHdh8 Meiner Ansicht nach lohnenswert.
fassen wir mal die Fakten zusammen: AVR 8-bit kann in ASM, C, C++ und diversen anderen Sprachen programmiert werden. Die Programmierschnittstelle zum Flashen benötigt einen proprietären Adapter, den es von China-billig bis Profi-überteuert gibt. Die CPUs gibt es von billig und klein bis groß und teuer. Der CPU Hersteller bietet eine kostenlose IDE an, so wie andere Anbieter kostenlos bis teuer. Die internen Register sind in entsprechenden Header Dateien der IDE bekannt gemacht, nebst nützlicher Zusatzinformationen für den Kompiler zum Generieren von ausführbaren Programmen. Die CPU kann über einen internen Oszillator oder einen externen Quarz betrieben werden. ARM 32-bit kann in ASM, C, C++ und diversen anderen Sprachen programmiert werden. Die Programmierschnittstelle zum Flashen benötigt einen proprietären Adapter, den es von China-billig bis Profi-überteuert gibt. Die CPUs gibt es von billig und klein bis groß und teuer. Die CPU Hersteller bietet eine kostenlose IDE an, so wie andere Anbieter kostenlos bis teuer. Die internen Register sind in entsprechenden Header Dateien der IDE bekannt gemacht, nebst nützlicher Zusatzinformationen für den Kompiler zum Generieren von ausführbaren Programmen. Die CPU kann über einen internen Oszillator oder einen externen Quarz betrieben werden. Bis jetzt noch kein so großer Unterschied. Die wichtigen Unterscheidungsmerkmale sind die Entwickler, die sich entweder nur mit "dem" AVR oder "dem" ARM auskennen. Die stehen sich unversöhnlich gegenüber und reden die jeweils andere Plattform schlecht, meist aus an den Haaren herbeigezogenen Gründen. Die Entwickler, die einfach nur programmieren wollen arbeiten sich in die jeweils passende Entwicklungsumgebung ein und erledigen den Job. Der Neuling muss sich jetzt entscheiden,ob er sich dem Grabenkrieg anschließt oder lieber was entwickeln will. Der Troll weiss, wie die AVR und ARM Fraktion zu triggern ist und lehnt sich mit Popcorn zurück, nachdem er ein paar Reizworte a la "deine CPU ist so fett, ich machs mit meiner schlanken in ASM viel besser" wieder eine Diskussion vom Zaun gebrochen hat.
Es gibt einen gewichtigen Unterschied: Die Dicke der Datenblätter.
chris schrieb: > Es gibt einen gewichtigen Unterschied: Die Dicke der Datenblätter. Jetzt geht das schon wieder los. Eben waren endlich alle Streitpunkte geklärt und beigelegt und jetzt kommst Du und fängst wieder von vorne an!
>Die Dicke der Datenblätter. liest die einer und lernt sie auswendig ? Ich nicht. All die Data sheets, Ref Manuals, AppNotes usw gibt es für jede Hardware in unüberschaubarer Fülle. Die werden erst gelesen, wenn man nicht weiterkommt. Und beim Thema Programmierung steht der Unterschied Delay(1000); für AVR und HAL_Delay(1000); für ARM nicht im Datenblatt.
dasrotemopped schrieb: >>Die Dicke der Datenblätter. > liest die einer und lernt sie auswendig ? Und selbst wenn: Atmega 328: 452 Seiten MKE04Z8xxx4: 611 Seiten Also nicht viel mehr als 30% dicker, dafür hat das vom ATmega viel kleinere Schrift, also Gleichstand. Das mit der größeren Schrift "bei ARM" kommt mir übrigens sehr entgegen. Und überhaupt, was heißt überhaupt "dick"? Wie dick (in mm) ist denn so ein PDF überhaupt? Und was wiegt es?
:
Bearbeitet durch User
@dasrotemopped Absolut alles, was du da zusammen gefasst hast, trifft auf 8bit AVR und auf STM32 Controller zu und vermutlich ebenso auf zahlreiche andere 8 und 32bit Mikrocontroller. Dieser Absatz hilft gar nicht, die Unterschiede zu beschreiben. Deine Behauptung, dass die die anwendenden Entwickler in zwei unversöhnlichen Lagern gegenüber stehen, halte ich für völlig falsch. Allein dieser Thread hier würde zu einer ganz anderen Schlussfolgerung führen, wenn du ihn denn gelesen hättest. > aus an den Haaren herbeigezogenen Gründen. Naja, du hast deine Erkenntnis einfach gar nicht begründet. Ist auch nicht besser. @Bernd K. >> Es gibt einen gewichtigen Unterschied: Die Dicke der Datenblätter. > Jetzt geht das schon wieder los. Das stand schon in den ersten Antworten, du regst Dich zu spät auf. > Die werden erst gelesen, wenn man nicht weiterkommt. Alles klar, rotesmopped. Damit hast du dich hier als die am wenigsten ernst nehmbare Person geoutet.
dasrotemopped schrieb: > ARM 32-bit ... Programmierschnittstelle zum Flashen benötigt > einen proprietären Adapter Falsch. ARM (und 8051) haben echtes ISP und man braucht nur ein USB-seriell-Kabel. AVR (und PIC) haben proprietäres ISP (was eigentlich ICP heissen müsste) und es ist ein Programmer nötig.
Irgend einen Adapter braucht man so oder so, also ist das doch eigentlich ziemlich egal, wenn wir mal ehrlich sind.
>Dieser Absatz hilft gar nicht, die Unterschiede zu beschreiben. Vielleicht wollte ich ja auch klar machen, das die Unterschiede nicht so relevant sind wie einige glauben. >Alles klar, rotesmopped. dasrotemopped, alles ein Wort, bitte nicht kürzen. Ich lass das Stef ja auch nicht einfach weg. >Damit hast du dich hier als die am wenigsten ernst nehmbare Person geoutet. Kein Problem, mache ich ja auch nicht bei anderen. >Naja, du hast deine Erkenntnis einfach gar nicht begründet. Wie hätte ich denn begründen sollen, das gcc C Programmierung für ARM und AVR bietet ? Ein bisschen Vorkenntnisse muss ich schon vorraussetzen. Bin ja nicht die Maus vom Fernsehen. Klingt blöd, is aber so.
dasrotemopped schrieb: > Vielleicht wollte ich ja auch klar machen, das die Unterschiede nicht so > relevant sind wie einige glauben. NAK, was hast du da verglichen? Atmel und Pic können viel kleiner, diese Tinys in 5 oder 6 Pin Gehäuse. Soweit runter gehen Cortex-M nicht, das sehen die sicher auch nicht als ihren Markt. Für Hobby interessieren die mich auch nicht, bei meinen Stückzahlen ist es egal das der kleinste für mich brauchbare µC knapp einen Euro kostet. Bei 10k Stückzahlen macht das vielleicht Sinn. Und am anderen Ende: gibt es AVR mit Ethernet, CAN, USB (FS, HS, OTG, Host), TFT Support, DMA, Floating Point, 2 MByte Flash, 512 kB RAM? Welcher AVR bietet das, habe ich was verpasst? Und gerade da fängt es doch an Spass zu machen. Durch den Community Support ist das alles mittlerweile kostenlos zu nutzen und viele open source Projekte beweisen das. Flashen: für beide gibt es billig Adapter, aber wie sieht es mit dem debuggen aus? Beim Arm kostet das nix extra, es geht mit dem gleichen 2$ Adapter. Welche Alternativen gibt es bei Atmel/Microchip? Stefan U. schrieb: > Irgend einen Adapter braucht man so oder so, also ist das doch > eigentlich ziemlich egal, wenn wir mal ehrlich sind. nicht immer, einige LPC haben sogar USB Bootloader, da reicht ein USB Kabel.
Lothar schrieb: > dasrotemopped schrieb: >> ARM 32-bit ... Programmierschnittstelle zum Flashen benötigt >> einen proprietären Adapter > > Falsch. ARM (und 8051) haben echtes ISP und man braucht nur ein > USB-seriell-Kabel. Das funktioniert aber nur über einen Bootloader, oder? Wie könnte man den denn z.B. ersetzen?
Angehängte Dateien:
Stefan U. schrieb: > Irgend einen Adapter braucht man so oder so, also ist das doch > eigentlich ziemlich egal, wenn wir mal ehrlich sind. Brauch man den? Zum Debuggen ja, aber nicht zwingend zum flashen. Einige (aeltere) ARM von Atmel (z.B. SAM3X) haben von Hause aus einen Bootloader (SAM-BA) im ROM. Und wenn ich das richtig sehe haben die STM32 von Hause aus auch einen DFU Bootloader drauf (siehe Bild, auszug aus dem Ref. Man. RM0090 STM32F4). Ob es zum flashen wirklich einen Adapter braucht, haengt also vom konkreten uC ab. Bernd K. schrieb: > dasrotemopped schrieb: >>>Die Dicke der Datenblätter. >> liest die einer und lernt sie auswendig ? > > Und selbst wenn: > > Atmega 328: 452 Seiten > MKE04Z8xxx4: 611 Seiten Naja, macht fuer mich schon einen Unterschied, ob ich die benoetigten Informationen in 300 bis 600 Seiten (AVR) oder 1700 Seiten (STM32F4 Ref. Man) suchen muss. Ich persoenlich finde die AVR in sofern schoen, weil ich sie einfacher zu konfigurieren finde. Das beginnt beim Takt (beim AVR keine Konfiguration noetig, Quarz ran und fertig) und geht ueber die ganze Peripherie. Die Fuses koennen beim AVR etwas nervig sein, das gebe ich zu. Wenn man von AVR kommt ist es vielleicht etwas ungewohnt, das man auf ARM zur Ansteuerung von Pins evtl. 2 Register hat. set und clear. Das finde ich bei AVR auch einfacher, ist aber auch kein Beinbruch. Was jetzt besser/schlechter/komplexer/komplizierter ist, haengt m.M.n. davon ab, wie man die Sache betrachtet. Betrachte ich das ohne Frameworks/Libs (dazu gehoert fuer mich auch CMSIS), dann ist AVR deutlich einfacher. Nutzt man Frameworks/Libs wie CMSIS, Atmel Software Framework (ASF), CubeMx, etc., dann sind die ARM gar nicht mal sooo kompliziert, solange alles funktioniert. Tritt aber ein Fehler auf, dann kann das ganze schnell zu grauen Haaren und tagelangem Frust fuehren. Aber am Ende finde ich die Diskussion aber eher muessig. Alle Architekturen haben ihre Berechtigung und Einsatzgebiete. atmega-fanboy-;-) schrieb: > Das funktioniert aber nur über einen Bootloader, oder? > Wie könnte man den denn z.B. ersetzen? Den kannst du teilweise gar nicht ersetzen, da der unter Ustaenden fest im uC drin ist, was ich nicht mal schlecht finde. Ob der Bootloader genutzt wird, haengt von der Beschaltung der Pins ab. Heisst auch: Der Bootloader ist nicht immer aktiv, wie bei den Arduinos. Und wenn der Bootloader genutzt wird, dann ist auch nur der Bootloader aktiv. -> Pins beschalten um in den Bootloadermodus zu kommen, Programm flashen, Strom ausschalten, Beschaltung der Pins aendern (z.B. durch einen Jumper), strom an und das Programm laeuft sofort an, ohne durch den Bootloader zu laufen.
atmega-fanboy-;-) schrieb: > Wie könnte man den denn z.B. ersetzen? gar nicht, ist im ROM. Und das ist gut so, damit kommt der µC wieder auf die Füsse wenn man zB im Startup den Takt verkonfiguriert hat oder sofort in einen DeepPowerDown rennt.
Angehängte Dateien:
-
AVR-vs-ARM_Blinky.jpg
190 KB
ihr habt alle das Thema verfehlt. Der TO fragt nach Unterschieden in der Programmierung, nicht nach Hardwarefeatures. Da grade nichts interessantes in der Glotze läuft, hier ein konkretes Beispiel im nicht vorhandenen Unterschied in der Programmierung. Einmal in der AVR Ecke : Arduino Nano V3 Clone in der ARM Ecke : STM32F4-Disco Definitiv ganz andere Gewichtsklassen und Hardwareausstattung, aber selbe arduino 1.8.5 IDE. Hätte auch einen dicken AVR gegen einen kleinen M0 antreten lassen, aber das liegt grade im Schrank. Und damit es ganz genau vergleichbar wird, der selbe Sketch für beide Boards: #define stm32f4-disco //#define arduino-nano #ifdef arduino-nano #define LED_1 1 #define LED_2 13 #endif #ifdef stm32f4-disco #define LED_1 PD14 #define LED_2 PD15 #endif void setup() { // put your setup code here, to run once: pinMode(LED_1, OUTPUT); pinMode(LED_2, OUTPUT); } void loop() { // put your main code here, to run repeatedly: digitalWrite(LED_1, HIGH); digitalWrite(LED_2, HIGH); delay(100); digitalWrite(LED_1, LOW); digitalWrite(LED_2, LOW); delay(100); } 2 LEDs blinken wie gewünscht. Finde den Unterschied in der Programmierung ! Ich muss nur das Target vor dem Kompilieren wechseln und das richtige #define auskommentieren.
dasrotemopped schrieb: > 2 LEDs blinken wie gewünscht. Finde den Unterschied in der > Programmierung ! Die sind in der genutzten Bibliothek, hier Arduino, versteckt. Wenn man ein Hardware-Feature nutzen will, was die nicht bietet, sieht das plötzlich ganz anders aus.
>Wenn man ein Hardware-Feature nutzen will, was die nicht bietet, >sieht das plötzlich ganz anders aus. Bitte ein Beispiel !
dasrotemopped schrieb: > Bitte ein Beispiel ! Alle 3 ADC's im Triple-Interleaved-Modus zusammen schalten um auf 6 Msps zu kommen, getriggert über einen Timer, und das Ergebnis per DMA in den OTG_HS-Puffer schreiben, sodass es an den USB-Host gesendet werden kann.
Natürlich sind die in der Programmierung vom Prinzip her gleich, man
muss nur zur richtigen Zeit den richtigen Wert in das richtige Register
schreiben. Aber was würde so eine Antwort bringen? Der Teufel steckt im
Detail und in der Programmierumgebung und in den Bibliotheken die man
eventuell benutzt. Da ist eher die Frage falsch...
Was ist der Unterschied zwischen einem Storch? Beide Beine sind gleich
lang, besonders das Rechte :-)
>Da grade nichts interessantes in der Glotze läuft,
es läuft DSDS, da hat Mann Zeit mit den µCs zu spielen :)
Johannes S. schrieb: > bung und in den Bibliotheken die man > eventuell benutzt. Da ist eher die Frage falsch... > Was ist der Unterschied zwischen einem Storch? Beide Bein Vielleicht ist Arduino jetzt doch der Stein der Weisen! Meine Güte, ich muss in Zukunft beim Portieren nur noch ein define ändern. Hätte ich das früher gewusst!
Tolles Beispiel. Wie man eigene Libs für die arduino IDE anlegt gibts ein Tutorial unter https://www.arduino.cc/en/Hacking/LibraryTutorial Die gewünschte Funktionalität kann man sich mit CubeMX zusammenclicken, das Rad wurde schon von jemand anders erfunden. Bitte fordere jetzt, das mit dem Nano ebenfalls zu machen.
dasrotemopped schrieb: > Finde den Unterschied in der > Programmierung ! Glueckwunsch. Du hast Zufaellig 2 Plattformen fuer die man dasselbe Framework nutzen kann. Ganz tolles Beispiel. Soll Leute geben, die die Performance brauchen die das Arduinozeug schluckt. Arduino hier als Referenz zu waehlen ist nicht wirklich das gelbe vom Ei. Mach doch mal dasselbe Beispiel ohne das Arduniozeug, also auf Registerebene. Dann zeigt sich der Unterschied naemlich sehr deutlich. Wie ich aber schon schrieb: Kaj G. schrieb: > Was jetzt besser/schlechter/komplexer/komplizierter ist, haengt m.M.n. > davon ab, wie man die Sache betrachtet. > > Betrachte ich das ohne Frameworks/Libs (dazu gehoert fuer mich auch > CMSIS), dann ist AVR deutlich einfacher. Nutzt man Frameworks/Libs wie > CMSIS, Atmel Software Framework (ASF), CubeMx, etc., dann sind die ARM > gar nicht mal sooo kompliziert, solange alles funktioniert. Tritt aber > ein Fehler auf, dann kann das ganze schnell zu grauen Haaren und > tagelangem Frust fuehren.
Beitrag #5319864 wurde von einem Moderator gelöscht.
>Meine Güte, ich muss in Zukunft beim Portieren nur noch ein define ändern.
Vergiss nicht, du musst 4 defines selbst schreiben ! Also nicht so
maßlos untertreiben.
Jetzt muss ich aber unbedingt Steam starten, SkyForce Reloaded wartet.
dasrotemopped schrieb: > Die gewünschte Funktionalität kann man sich mit CubeMX zusammenclicken, > das Rad wurde schon von jemand anders erfunden. Ob wohl 3rd-Parity Middleware wie z.B. der Segger USB Stack auch durch Zusammenklicken in CubeMX geschrieben wurde? Oder ob da nicht doch irgendwie Gehirnschmalz und plattformspezifischer Code drin steckt?
>Soll Leute geben, die die Performance brauchen die das Arduinozeug schluckt.
Wenn man mit einem Nano mit ATmega328P@16MHz wahre Wunder vollbringen
kann, dann bietet der STM32F4@168MHz reichlich Leistung zum Vergeuden,
auch mit der arduino IDE.
Und das die arduino IDE CPU Zyklen vergeutet auf der Zielplattform, das
muss mir erst jemand beweisen. Einfach die Behauptung so in den Raum
werfen war ja uncool habe ich gehört.
>Ob wohl 3rd-Parity Middleware wie z.B. der Segger USB Stack >auch durch Zusammenklicken in CubeMX geschrieben wurde? Ob der Segger USB Stack von STmicro lizensiert wurde und in CubeMX integriert ist ? ST macht auch nicht alles selbst, siehe freeRTOS, IP Stack, FATFS Lib, STemWinLib ... alles im 3rd party Bereich von CubeMX.
dasrotemopped schrieb: > Ob der Segger USB Stack von STmicro lizensiert wurde und in CubeMX > integriert ist ? ST Nein, denn den muss man erstmal kaufen. Selbst wenn, der muss irgendwann mal entwickelt worden sein. Und das ging bestimmt nicht indem der in CubeMX zusammengeklickt wurde. Will sagen, nicht alles kann man durch Zusammenklicken programmieren.
>Arduino hier als Referenz zu waehlen ist nicht wirklich das gelbe vom Ei. >Mach doch mal dasselbe Beispiel ohne das Arduniozeug, also auf Registerebene arduino ist C++, C++ Kompiler sind heute besser als jeder Programmierer. Beispiel für einen 8-bitter effizient programmiert mit C++: https://youtu.be/zBkNBP00wJE Ich versuche jedenfalls nicht, mit Jahrzehnten in Kompilerentwicklung zu konkurieren, bin ja nicht größenwahnsinnig.
>Soll Leute geben, die die Performance brauchen die das Arduinozeug schluckt.
Wieder so ein Ausdruck der in Schriftform gefassten Unwissenheit: Weder
ist Arduino "Zeugs", noch schluckt es Performance die andere System
nicht auch schlucken würden und die man bei Bedarf auch vermeiden kann,
in dem man den "perfomanten" Treiber selber schreibt.
Hier mal die Daten für mein oben getesteten Sketch. Kompiler Output für STM32F4: Der Sketch verwendet 17088 Bytes (1%) des Programmspeicherplatzes. Das Maximum sind 1048576 Bytes. Globale Variablen verwenden 6056 Bytes (4%) des dynamischen Speichers, 125016 Bytes für lokale Variablen verbleiben. Das Maximum sind 131072 Bytes. Kompiler Output für ATmega328P: Der Sketch verwendet 974 Bytes (3%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes. Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers, 2039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes. Ist doch alles geschmeidig, oder ? Der Startup Code für den ARM verbraucht warscheinlich 99% der belegten Ressourcen, das wächst nicht linear mit dem eigenen Code so weiter.
dasrotemopped schrieb: > Der Sketch verwendet 17088 Bytes (1%) des Programmspeicherplatzes. Das > Maximum sind 1048576 Bytes. 17 kB Flash und 6 kB RAM für einen LED-Blinker?! Wie gezeigt geht das auch in 392 Bytes Flash und 32 Bytes RAM (für den Stack bei ISR-Eintritt) ... dasrotemopped schrieb: > Der Startup Code für den ARM > verbraucht warscheinlich 99% der belegten Ressourcen, das wächst nicht > linear mit dem eigenen Code so weiter. Quatsch, der ist ca 100-200 Bytes groß. Sind ja nur 2-3 Kopier-Schleifen. Das ist wohl das Arduino-Gedöns.
Beitrag #5319981 wurde von einem Moderator gelöscht.
Ralfi schrieb im Beitrag #5319981: > Gewaltig. Der AVR Programmierer ist beeindruckt und wird aufgrund dieser > Zahlen sofort umsteigen! Darum ging's nicht.
Ralfi schrieb im Beitrag #5319981: > Der AVR Programmierer ist beeindruckt Hab in der Industrie noch keinen AVR Programmierer getroffen :-) 8051 ist "bewährter Industriestandard", PIC ist billig, ARM ist "modern" (obwohl älter als AVR). Dann gibt es noch einige Renesas und Tricore Anhänger.
Beitrag #5320055 wurde von einem Moderator gelöscht.
Ralfi schrieb im Beitrag #5320055: > 7 Milliarden verkauften Stück allein bis 2015 Wenn das stimmt, warum hat dann Atmel damit keinen Gewinn gemacht? Vergleiche mal die letzte Atmel-Bilanz 2015 vor der Übernahme, mit der 2015 Bilanz von 8051-Silabs. An 8-Bit vs. 32-Bit kann das nicht gelegen haben.
>> Naja, du hast deine Erkenntnis einfach gar nicht begründet. > Wie hätte ich denn begründen sollen, das gcc C Programmierung für > ARM und AVR bietet ? Ich meinte damit den Part, dass die Entwickler sich unversöhnlich in 8bit versus 32bit Lagern gegenüber stehen. Wie du darauf kommst, hast du nicht begründet.
> Hier mal die Daten für mein oben getesteten Sketch. > STM32F4: Der Sketch verwendet 17088 Bytes > ATmega328P:Der Sketch verwendet 974 Bytes Vorsicht, du hast da Äpfel mit Melonen verglichen. Denn im STM32 Fall enthält das Programm auch den gesamten USB Stack und den Bootloader. Beim AVR entfällt das, weil dazu ein zweiter Chip auf der Platine ist - mit seiner eigenen Firmware.
dasrotemopped schrieb: > Wenn man mit einem Nano mit ATmega328P@16MHz wahre Wunder vollbringen > kann, dann bietet der STM32F4@168MHz reichlich Leistung zum Vergeuden, Es soll Leute geben die steigen nicht auf einen größeren µC um weil sie jetzt plötzlich den Drang verspüren exakt das selbe wie zuvor zu machen, nur teurer und mit mehr Vergeudung sondern weil sie die zusätzlichen Ressourcen des größeren µC für die eigentliche Anwendung brauchen. Und es soll Leute geben die müssen mit spitzem Bleistift kalkulieren.
dasrotemopped schrieb: > Hier mal die Daten für mein oben getesteten Sketch. Und hier mal die Daten die sich ergeben wenn man das richtig macht:
1 | $ arm-none-eabi-size build/hello_world.elf |
2 | text data bss dec hex filename |
3 | 724 0 0 724 2d4 build/hello_world.elf |
Hier das vollständige Kompilat im Menschenlesbarer Form:
1 | build/hello_world.elf: file format elf32-littlearm |
2 | |
3 | |
4 | Disassembly of section .text: |
5 | |
6 | 08000000 <__vector_table>: |
7 | 8000000: 00 80 01 20 ef 01 00 08 ed 01 00 08 ed 01 00 08 ... ............ |
8 | 8000010: ed 01 00 08 ed 01 00 08 ed 01 00 08 00 00 00 00 ................ |
9 | ... |
10 | 800002c: ed 01 00 08 ed 01 00 08 00 00 00 00 ed 01 00 08 ................ |
11 | 800003c: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
12 | 800004c: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
13 | 800005c: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
14 | 800006c: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
15 | 800007c: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
16 | ... |
17 | 800009c: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
18 | 80000ac: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
19 | 80000bc: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
20 | 80000cc: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
21 | 80000dc: 00 00 00 00 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
22 | ... |
23 | 80000fc: ed 01 00 08 00 00 00 00 ed 01 00 08 ed 01 00 08 ................ |
24 | 800010c: ed 01 00 08 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
25 | 800011c: 00 00 00 00 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
26 | 800012c: ed 01 00 08 ed 01 00 08 00 00 00 00 00 00 00 00 ................ |
27 | ... |
28 | 800014c: ed 01 00 08 ed 01 00 08 ed 01 00 08 ed 01 00 08 ................ |
29 | 800015c: ed 01 00 08 ed 01 00 08 ed 01 00 08 00 00 00 00 ................ |
30 | ... |
31 | 8000184: ed 01 00 08 00 00 00 00 00 00 00 00 ed 01 00 08 ................ |
32 | |
33 | 08000194 <delay.constprop.0>: |
34 | 8000194: b082 sub sp, #8 |
35 | 8000196: 23c8 movs r3, #200 ; 0xc8 |
36 | 8000198: 2100 movs r1, #0 |
37 | 800019a: f644 601f movw r0, #19999 ; 0x4e1f |
38 | 800019e: 9101 str r1, [sp, #4] |
39 | 80001a0: 9a01 ldr r2, [sp, #4] |
40 | 80001a2: 4282 cmp r2, r0 |
41 | 80001a4: d903 bls.n 80001ae <delay.constprop.0+0x1a> |
42 | 80001a6: 3b01 subs r3, #1 |
43 | 80001a8: d1f9 bne.n 800019e <delay.constprop.0+0xa> |
44 | 80001aa: b002 add sp, #8 |
45 | 80001ac: 4770 bx lr |
46 | 80001ae: 9a01 ldr r2, [sp, #4] |
47 | 80001b0: 3201 adds r2, #1 |
48 | 80001b2: 9201 str r2, [sp, #4] |
49 | 80001b4: e7f4 b.n 80001a0 <delay.constprop.0+0xc> |
50 | ... |
51 | |
52 | 080001b8 <main>: |
53 | 80001b8: 4a0a ldr r2, [pc, #40] ; (80001e4 <main+0x2c>) |
54 | 80001ba: 4c0b ldr r4, [pc, #44] ; (80001e8 <main+0x30>) |
55 | 80001bc: b508 push {r3, lr}
|
56 | 80001be: 6b13 ldr r3, [r2, #48] ; 0x30 |
57 | 80001c0: f043 0301 orr.w r3, r3, #1 |
58 | 80001c4: 6313 str r3, [r2, #48] ; 0x30 |
59 | 80001c6: 6822 ldr r2, [r4, #0] |
60 | 80001c8: f442 6280 orr.w r2, r2, #1024 ; 0x400 |
61 | 80001cc: 6022 str r2, [r4, #0] |
62 | 80001ce: 2620 movs r6, #32 |
63 | 80001d0: f44f 1500 mov.w r5, #2097152 ; 0x200000 |
64 | 80001d4: 61a6 str r6, [r4, #24] |
65 | 80001d6: f7ff ffdd bl 8000194 <delay.constprop.0> |
66 | 80001da: 61a5 str r5, [r4, #24] |
67 | 80001dc: f7ff ffda bl 8000194 <delay.constprop.0> |
68 | 80001e0: e7f8 b.n 80001d4 <main+0x1c> |
69 | 80001e2: bf00 nop |
70 | 80001e4: 40023800 .word 0x40023800 |
71 | 80001e8: 40020000 .word 0x40020000 |
72 | |
73 | 080001ec <ADC_IRQHandler>: |
74 | 80001ec: e7fe b.n 80001ec <ADC_IRQHandler> |
75 | |
76 | 080001ee <Reset_Handler>: |
77 | 80001ee: f000 f805 bl 80001fc <ram_init> |
78 | 80001f2: f000 f821 bl 8000238 <SystemInit> |
79 | 80001f6: f7ff ffdf bl 80001b8 <main> |
80 | 80001fa: e7fe b.n 80001fa <Reset_Handler+0xc> |
81 | |
82 | 080001fc <ram_init>: |
83 | 80001fc: 4b09 ldr r3, [pc, #36] ; (8000224 <ram_init+0x28>) |
84 | 80001fe: 4a0a ldr r2, [pc, #40] ; (8000228 <ram_init+0x2c>) |
85 | 8000200: 2100 movs r1, #0 |
86 | 8000202: 4293 cmp r3, r2 |
87 | 8000204: d305 bcc.n 8000212 <ram_init+0x16> |
88 | 8000206: 4a09 ldr r2, [pc, #36] ; (800022c <ram_init+0x30>) |
89 | 8000208: 4b09 ldr r3, [pc, #36] ; (8000230 <ram_init+0x34>) |
90 | 800020a: 490a ldr r1, [pc, #40] ; (8000234 <ram_init+0x38>) |
91 | 800020c: 428b cmp r3, r1 |
92 | 800020e: d303 bcc.n 8000218 <ram_init+0x1c> |
93 | 8000210: 4770 bx lr |
94 | 8000212: f843 1b04 str.w r1, [r3], #4 |
95 | 8000216: e7f4 b.n 8000202 <ram_init+0x6> |
96 | 8000218: f852 0f04 ldr.w r0, [r2, #4]! |
97 | 800021c: f843 0b04 str.w r0, [r3], #4 |
98 | 8000220: e7f4 b.n 800020c <ram_init+0x10> |
99 | 8000222: bf00 nop |
100 | 8000224: 20000000 .word 0x20000000 |
101 | 8000228: 20000000 .word 0x20000000 |
102 | 800022c: 080002d0 .word 0x080002d0 |
103 | 8000230: 20000000 .word 0x20000000 |
104 | 8000234: 20000000 .word 0x20000000 |
105 | |
106 | 08000238 <SystemInit>: |
107 | 8000238: 4b21 ldr r3, [pc, #132] ; (80002c0 <SystemInit+0x88>) |
108 | 800023a: 6c1a ldr r2, [r3, #64] ; 0x40 |
109 | 800023c: f042 5280 orr.w r2, r2, #268435456 ; 0x10000000 |
110 | 8000240: 641a str r2, [r3, #64] ; 0x40 |
111 | 8000242: 4a20 ldr r2, [pc, #128] ; (80002c4 <SystemInit+0x8c>) |
112 | 8000244: 6811 ldr r1, [r2, #0] |
113 | 8000246: f441 4100 orr.w r1, r1, #32768 ; 0x8000 |
114 | 800024a: 6011 str r1, [r2, #0] |
115 | 800024c: 6819 ldr r1, [r3, #0] |
116 | 800024e: 0789 lsls r1, r1, #30 |
117 | 8000250: d5fc bpl.n 800024c <SystemInit+0x14> |
118 | 8000252: 6811 ldr r1, [r2, #0] |
119 | 8000254: f041 0180 orr.w r1, r1, #128 ; 0x80 |
120 | 8000258: 6011 str r1, [r2, #0] |
121 | 800025a: 681a ldr r2, [r3, #0] |
122 | 800025c: f022 7280 bic.w r2, r2, #16777216 ; 0x1000000 |
123 | 8000260: 601a str r2, [r3, #0] |
124 | 8000262: 4b17 ldr r3, [pc, #92] ; (80002c0 <SystemInit+0x88>) |
125 | 8000264: 461a mov r2, r3 |
126 | 8000266: 6819 ldr r1, [r3, #0] |
127 | 8000268: 0188 lsls r0, r1, #6 |
128 | 800026a: d4fc bmi.n 8000266 <SystemInit+0x2e> |
129 | 800026c: 4916 ldr r1, [pc, #88] ; (80002c8 <SystemInit+0x90>) |
130 | 800026e: 6059 str r1, [r3, #4] |
131 | 8000270: 6819 ldr r1, [r3, #0] |
132 | 8000272: f041 7180 orr.w r1, r1, #16777216 ; 0x1000000 |
133 | 8000276: 6019 str r1, [r3, #0] |
134 | 8000278: 6813 ldr r3, [r2, #0] |
135 | 800027a: 0199 lsls r1, r3, #6 |
136 | 800027c: d5fc bpl.n 8000278 <SystemInit+0x40> |
137 | 800027e: 4913 ldr r1, [pc, #76] ; (80002cc <SystemInit+0x94>) |
138 | 8000280: 680b ldr r3, [r1, #0] |
139 | 8000282: f443 7340 orr.w r3, r3, #768 ; 0x300 |
140 | 8000286: f043 0302 orr.w r3, r3, #2 |
141 | 800028a: 600b str r3, [r1, #0] |
142 | 800028c: 6893 ldr r3, [r2, #8] |
143 | 800028e: f043 0302 orr.w r3, r3, #2 |
144 | 8000292: 6093 str r3, [r2, #8] |
145 | 8000294: 4b0a ldr r3, [pc, #40] ; (80002c0 <SystemInit+0x88>) |
146 | 8000296: 689a ldr r2, [r3, #8] |
147 | 8000298: 0712 lsls r2, r2, #28 |
148 | 800029a: d5fc bpl.n 8000296 <SystemInit+0x5e> |
149 | 800029c: 689a ldr r2, [r3, #8] |
150 | 800029e: f022 02f0 bic.w r2, r2, #240 ; 0xf0 |
151 | 80002a2: 609a str r2, [r3, #8] |
152 | 80002a4: 689a ldr r2, [r3, #8] |
153 | 80002a6: f442 5280 orr.w r2, r2, #4096 ; 0x1000 |
154 | 80002aa: 609a str r2, [r3, #8] |
155 | 80002ac: 689a ldr r2, [r3, #8] |
156 | 80002ae: f422 4260 bic.w r2, r2, #57344 ; 0xe000 |
157 | 80002b2: 609a str r2, [r3, #8] |
158 | 80002b4: 4a06 ldr r2, [pc, #24] ; (80002d0 <SystemInit+0x98>) |
159 | 80002b6: 6853 ldr r3, [r2, #4] |
160 | 80002b8: f043 0307 orr.w r3, r3, #7 |
161 | 80002bc: 6053 str r3, [r2, #4] |
162 | 80002be: 4770 bx lr |
163 | 80002c0: 40023800 .word 0x40023800 |
164 | 80002c4: 40007000 .word 0x40007000 |
165 | 80002c8: 07015410 .word 0x07015410 |
166 | 80002cc: 40023c00 .word 0x40023c00 |
167 | 80002d0: e0042000 .word 0xe0042000 |
(Der Disassembler löst den Default_Handler als ADC_IRQHandler auf weil alle auf den selben leeren Default_Handler zeigen aber A im Alphabet weiter vorne steht und er deshalb diesen Namen wählt) hier der Quellcode:
1 | #include <stm32f401xe.h> |
2 | |
3 | |
4 | /*
|
5 | * The green LED is connected to port A5,
|
6 | * -> see schematic of NUCLEO-F401RE board
|
7 | */
|
8 | #define LED_GPIO GPIOA
|
9 | #define LED_PIN 5
|
10 | |
11 | |
12 | /**
|
13 | * Quick 'n' dirty delay
|
14 | *
|
15 | * @param time the larger it is the longer it will block
|
16 | */
|
17 | static void delay(unsigned time) { |
18 | for (unsigned i=0; i<time; i++) |
19 | for (volatile unsigned j=0; j<20000; j++); |
20 | }
|
21 | |
22 | |
23 | /**
|
24 | * Hello world blinky program
|
25 | *
|
26 | * @return never
|
27 | */
|
28 | int main(void) { |
29 | |
30 | /*
|
31 | * Turn on the GPIOA unit,
|
32 | * -> see section 6.3.9 in the manual
|
33 | */
|
34 | RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; |
35 | |
36 | |
37 | /*
|
38 | * Set LED-Pin as output
|
39 | * Note: For simplicity this assumes the pin was configured
|
40 | * as input before, as it is when it comes out of reset.
|
41 | * -> see section 8.4.1 in the manual
|
42 | */
|
43 | LED_GPIO->MODER |= (0b01 << (LED_PIN << 1)); |
44 | |
45 | |
46 | while(1) { |
47 | |
48 | /*
|
49 | * LED on (drive the pin high)
|
50 | * A GPIO output pin is set to high by writing 1 to the
|
51 | * corresponding bit in the lower half of the BSRR register
|
52 | * -> see section 8.4.7 in the manual
|
53 | */
|
54 | LED_GPIO->BSRR = (1 << LED_PIN); |
55 | |
56 | delay(200); |
57 | |
58 | /*
|
59 | * LED off (drive the pin low)
|
60 | * A GPIO output pin is set to low by writing 1 to the
|
61 | * corresponding bit in the upper half of the BSRR register
|
62 | * -> see section 8.4.7 in the manual
|
63 | */
|
64 | LED_GPIO->BSRR = (1 << (LED_PIN + 16)); |
65 | |
66 | delay(200); |
67 | }
|
68 | }
|
Hier zum selber probieren: https://github.com/prof7bit/bare_metal_stm32f401xe
:
Bearbeitet durch User
Nur um das noch einmal klarzustellen: Es geht definitiv nicht um die Programmierung mit Arduino oder Klicktools. Es geht um reines C. Ich mag C++, programmiere auf dem Desktop fast ausschließlich damit, aber bei µCs bevorzuge ich einfach schlichtes C. Vor allem, weil man das, was C++ eigentlich ausmacht, bei den meisten µCs nicht einmal nutzen kann. Fast alles ab C++11, was C++ modern macht, ist unbenutzbar.
atmega-fanboy-;-) schrieb: > Fast alles ab C++11, was C++ modern macht, ist unbenutzbar. Gewagte These, weil gerade das ist ein Grund auf Cortex-M umzusteigen. Da kosten Devices mit >2kB RAM kaum mehr, Flash gibts auch reichlich und C++ macht definitiv Spass auf diesen Dingern. Hier wurde schon mehrfach wiederlegt das C++ mehr Speicher braucht... Ich hatte vor kurzem aus Spass mal die iostream und ein std::cout << irgendwas mitkompiliert, kostet viel aber es geht. Auf einem ARM, nicht mehr auf AVR.
Ich hab das obige bare metal Beispiel letztes Jahr auch mal in C++ gemacht, es kam ungefähr das gleiche raus, nur weiß ich nicht mehr wo ich den Code hingeschlampt habe, habs auch nicht mehr weiter verfolgt weil ich ansonsten nur in C unterwegs bin. Vieles von den komplexeren Sachen könnte man in C++ wesentlich schöner hinschreiben als in C aber die Trägheit und die berufliche Notwendigkeit halten mich bis auf weiteres bei C.
Dass C++ keineswegs schlechter oder unperformanter ist als C weiß ich. Wie gesagt, ich mag C++ und ziehe es eigentlch jeder anderen Sprache vor. Ich weiß nur, dass eben nicht allzu viel vom C++-Standard auf zumindest AVRs verfügbar ist. Bestes Beispiel ist die STL. Und so ist C++ eben auch nicht viel mehr als C mit einigen netten Extras. Und da nehme ich lieber reines C.
atmega-fanboy-;-) schrieb: > Ich mag C++, programmiere auf dem Desktop fast ausschließlich damit, > aber bei µCs bevorzuge ich einfach schlichtes C. Vor allem, weil man > das, was C++ eigentlich ausmacht, bei den meisten µCs nicht einmal > nutzen kann. Fast alles ab C++11, was C++ modern macht, ist unbenutzbar. M.E. ist es genau anders herum: ganz viele neue Features von C++ erlauben eine Effektivität und Expressivität, die es für µC ganz besonders attraktiv macht.
Beitrag #5320384 wurde von einem Moderator gelöscht.
Beitrag #5320388 wurde von einem Moderator gelöscht.
Ich glaub der einzige fixe Overhead bei der C++ Variante war daß ich im Startup-code noch __libc_init_array aufrufen oder selber implementieren musste damit statische Konstruktoren funktionieren (das iteriert letztlich nur über eine Liste von Funktionszeigern und ruft jeden davon auf, da kommen dann vielleicht nochmal ein paar dutzend bytes zum Startup dazu und da wars dann auch schon.
Wilhelm M. schrieb: > atmega-fanboy-;-) schrieb: > >> Ich mag C++, programmiere auf dem Desktop fast ausschließlich damit, >> aber bei µCs bevorzuge ich einfach schlichtes C. Vor allem, weil man >> das, was C++ eigentlich ausmacht, bei den meisten µCs nicht einmal >> nutzen kann. Fast alles ab C++11, was C++ modern macht, ist unbenutzbar. > > M.E. ist es genau anders herum: ganz viele neue Features von C++ > erlauben eine Effektivität und Expressivität, die es für µC ganz > besonders attraktiv macht. Die Effektivität hat man tatsächlich auch in C - wenn man es richtig macht. Und das ist das Problem. C erlaubt eigentlich fast schon zu viele Fehler. Nehmen wir einmal std::vector. Der std::vector kann nichts schneller als C-Arrays. Das ist einfach auch nicht möglich. Aber er kann es eben (nahezu) genauso schnell und hat dabei viel mehr Möglichkeiten. Beispiel: std::vector::size + Iteratoren und Algorithmen aus <algorithm>. Nachteil: unter AVR quasi nicht einsetzbar, da dabei dynamisch Speicher angefordert wird (im ctor) und meines Wissens große Teile der STL nicht einmal implementiert sind. Für std::map, etc. gilt natürlich das gleiche. Oder stimmt das nicht? Ich glaube, dass ich so etwas auch hier auf mikrocontroller.net in einem Artikel gefunden habe. Lambda ist (soweit ich weiß) ebenfalls auf AVRs nicht nutzbar. Und so geht es eben weiter mit nützlichen Features. Wenn ich C++ nutze, dann auch den kompletten Standard. Alleswisser schrieb im Beitrag #5320388: > atmega-fanboy-;-) schrieb: >> Es geht definitiv nicht um die Programmierung mit Arduino oder >> Klicktools. > > Aber das ist doch genau deine Kragenweite. Ich habe auch durchaus schon mit Programmierung Geld verdient. Und die Kunden waren mit dem Ergebnis selten unzufrieden.
atmega-fanboy-;-) schrieb: > Wilhelm M. schrieb: >> atmega-fanboy-;-) schrieb: >> >>> Ich mag C++, programmiere auf dem Desktop fast ausschließlich damit, >>> aber bei µCs bevorzuge ich einfach schlichtes C. Vor allem, weil man >>> das, was C++ eigentlich ausmacht, bei den meisten µCs nicht einmal >>> nutzen kann. Fast alles ab C++11, was C++ modern macht, ist unbenutzbar. >> >> M.E. ist es genau anders herum: ganz viele neue Features von C++ >> erlauben eine Effektivität und Expressivität, die es für µC ganz >> besonders attraktiv macht. > Nehmen wir einmal std::vector. Ist aber kein neues Feature. Ist auch kein Element der Sprache sondern der stdlib. > Der std::vector kann nichts schneller als > C-Arrays. std::array ist der Ersatz für C-Style-Arrays. > Beispiel: std::vector::size + Iteratoren und Algorithmen aus > <algorithm>. Die kannst Du nutzen. > Nachteil: unter AVR quasi nicht einsetzbar, da dabei dynamisch Speicher > angefordert wird (im ctor) und meines Wissens große Teile der STL nicht > einmal implementiert sind. Für std::map, etc. gilt natürlich das > gleiche. std::map ist auch kein neues feature (s.o.). > Lambda ist (soweit ich weiß) ebenfalls auf AVRs nicht nutzbar. Quatsch, sondern sehr gut und effizient, auch gerade in Zusammenhang mit constexpr (ab c++17 sind Closures implizit constexpr). > Und so geht es eben weiter mit nützlichen Features. Auch Quatsch. > Wenn ich C++ nutze, dann auch den kompletten Standard. Scheint mir nicht so zu sein ...
Den std::vector habe ich auch gerade in meine chart lib eingebaut an der ich bastel, has hat 256 Byte gekostet gegenüber nix. Verglichen mit einer C Implementierung die ich nicht gemacht habe ist also netto noch weniger. Den Speicher sollte man durch zuviel Dynamik nicht fragmentieren, das ist klar, aber das gilt ja auch für malloc().
Beitrag #5320420 wurde von einem Moderator gelöscht.
Die Standardlib gehört zum Standard. Und der Standard definiert die
Sprache.
Somit gehört auch die Klasse std::vector zur Sprache.
Richtig, std::array ist natürlich der genaue Ersatz für C-Arrays. Ist
aber letztendlich abgesehen von der dynamischen Speicheranforderung sehr
ähnlich aufgebaut.
Alles Teil der STL (Teil des C++ Standards, der die Sprache definiert).
Hier auch noch einmal ein Ausschnitt aus dem AVR-Tutorial (Suchmaschine
is your friend):
Nutzbar sind:
Variablendeklaration an beliebigen Stellen
bool-Datentyp
Initialisierung von Strukturen mit Nicht-Konstanten
Klassen mit Einfachvererbung
Überladene Funktionen
Einfache Templates
Statische Konstruktoren
Nicht unbedingt nutzen sollte man (oder man muss nachsehen, wie blöd
sich der Compiler anstellt):
STL (Standard Template Library)
Mehrfachvererbung
Virtuelle Methoden (muss man fallweise entscheiden, zumindest bei
avr-gcc umständlich)
Allzu verrückte oder neue Features wie
Verschachtelte Klassen
Automatische Typerkennung (auto-Schlüsselwort)
Laufzeit-Typprüfung
Anonyme Funktionen (Lambda-Ausdrücke)
new- und delete-Operator (Speicherverwaltung allgemein)
Quelle: AVR-Tutorial
Vermutlich ziemlich veraltet, wenn man sich "verrückte oder neue
Features" so anschaut.
Und auf dem Desktop nutze ich sehr wohl den gesamten C++-Standard. Auf
dem µC nicht, wegen so etwas wie oben zitiert. Das ist nicht die einzige
Quelle, die so etwas aussagt.
Wenn es aber wohl anders ist, dann werde ich liebend gerne auf C++
umsteigen.
Alleswisser schrieb im Beitrag #5320420:
> atmega-fanboy-;-) schrieb:
>> Ich habe auch durchaus schon mit Programmierung Geld verdient
>
> Ja und? Es gibt auch so genannte professionelle Mathlab Programmierer.
> Bunte Bildchen und Geld verdienen schließt sich nicht aus.
C++, ohne GUI. Nix Bildchen.
Und wenn GUI, dann üblicherweise eine möglichst schlichte mit Qt.
ich verstehe es immer noch nicht, atmega-fanboy-;-) schrieb: > Deshalb überlege ich mir, > auf ARMs umzusteigen. also mach einen Reset, vergiss die Vorurteile und probiere es aus. in meinem Code habe ich
1 | // vector anlegen
|
2 | std::vector<PlotArea*> plotAreas; |
3 | |
4 | // vector füllen
|
5 | plotAreas.push_back(p); |
6 | |
7 | // über alle elemente iterieren
|
8 | for(PlotArea *pA: plotAreas) { |
9 | pA->draw(); |
10 | }
|
Wenn die Zeilen raus sind habe ich 256 Byte weniger Code. Das selber durch ein Array zu ersetzen kostet auch ein paar Byte, ich würde sagen der Overhead durch den vector geht gegen Null.
atmega-fanboy-;-) schrieb: > Die Standardlib gehört zum Standard. Und der Standard definiert die > Sprache. > Somit gehört auch die Klasse std::vector zur Sprache. Nein, zum Standard. > Richtig, std::array ist natürlich der genaue Ersatz für C-Arrays. Ist > aber letztendlich abgesehen von der dynamischen Speicheranforderung sehr > ähnlich aufgebaut. Genau, und das ist auch gut so: s.a. Algorithmen ;-) > Alles Teil der STL (Teil des C++ Standards, der die Sprache definiert). Nochmal, die STL gibt es nicht mehr, es ist die Standard-C++-Bibliothel, die ist zwar Bestandteil des Standards, definiert aber nicht die Sprache selbst. > Hier auch noch einmal ein Ausschnitt aus dem AVR-Tutorial (Suchmaschine > is your friend): Und das ist veraltet. > Nicht unbedingt nutzen sollte man (oder man muss nachsehen, wie blöd > sich der Compiler anstellt): > > STL (Standard Template Library) ist auf AVR gar nicht vorhanden > Mehrfachvererbung Wird generell falsch verstanden. > Virtuelle Methoden (muss man fallweise entscheiden, zumindest bei > avr-gcc umständlich) Jein. > Verschachtelte Klassen Quatsch > Automatische Typerkennung (auto-Schlüsselwort) Quatsch > Laufzeit-Typprüfung rtti ist auf avr gar nicht möglich > Anonyme Funktionen (Lambda-Ausdrücke) Quatsch > new- und delete-Operator (Speicherverwaltung allgemein) Auf avr gar nicht realisiert, aber machbar. > Vermutlich ziemlich veraltet, wenn man sich "verrückte oder neue > Features" so anschaut. Genau!
Das ist halt auch Quatsch: atmega-fanboy-;-) schrieb: > STL (Standard Template Library) Was ist an std::max, std::numeric_limits oder std::tuple böse? > Mehrfachvererbung Generell fragwürdig, aber auch gar kein Problem. std::tuple basiert darauf. > Virtuelle Methoden (muss man fallweise entscheiden, zumindest bei > avr-gcc umständlich) Genauso effizient wir Funktions Zeiger. Kein Problem. > Allzu verrückte oder neue Features wie > Verschachtelte Klassen Hat 0 Auswirkung auf Laufzeit Verhalten. Also kein Problem. > Automatische Typerkennung (auto-Schlüsselwort) Dito. > Laufzeit-Typprüfung Das stimmt schon eher. > Anonyme Funktionen (Lambda-Ausdrücke) Genauso effizient wie normale Funktionen. > new- und delete-Operator (Speicherverwaltung allgemein) Genau wie malloc > Quelle: AVR-Tutorial Das hat wohl ein C++ Hater geschrieben :)
Dr. Sommer schrieb: > Das ist halt auch Quatsch: > > atmega-fanboy-;-) schrieb: >> STL (Standard Template Library) > Was ist an std::max, std::numeric_limits oder std::tuple böse? >> Mehrfachvererbung > Generell fragwürdig, aber auch gar kein Problem. std::tuple basiert > darauf. >> Virtuelle Methoden (muss man fallweise entscheiden, zumindest bei >> avr-gcc umständlich) > Genauso effizient wir Funktions Zeiger. Kein Problem. Hier sollte man für AVR allerdings dazu sagen, dass genau das der GCC nicht so optimal macht: die vtable wird ins RAM kopiert. Das macht er aus Performaancegründen, nötige wäre nicht strenggenommen. Man würde sich eine Compiler-Option dafür wünschen, ob die vtable ins flash soll oder nicht. Deswegen habe ich mir eine eigene Variante geschrieben, die das Problem löst. Der Trade-Off ist natürlich, dass mehr flash und etwas Laufzeit verbraucht wird. Man kann es aber mit template-Mechanik machen.
:
Bearbeitet durch User
Mir ist noch ein Unterschied in der Programmierung eingefallen (der hier schon aber nur zwischen den Zeilen genannt wurde): ARM Controller können Code aus dem RAM ausführen (trifft das eigentlich auf alle zu)? Bei ATtiny und ATmega ist das abgesehen von wenigen Ausnahmen nicht der Fall.
Beitrag #5320462 wurde von einem Moderator gelöscht.
Johannes S. schrieb: > ich verstehe es immer noch nicht, > > atmega-fanboy-;-) schrieb: >> Deshalb überlege ich mir, >> auf ARMs umzusteigen. > > also mach einen Reset, vergiss die Vorurteile und probiere es aus. > > in meinem Code habe ich// vector anlegen > std::vector<PlotArea*> plotAreas; > > // vector füllen > plotAreas.push_back(p); > > // über alle elemente iterieren > for(PlotArea *pA: plotAreas) { > pA->draw(); > } > > Wenn die Zeilen raus sind habe ich 256 Byte weniger Code. Das selber > durch ein Array zu ersetzen kostet auch ein paar Byte, ich würde sagen > der Overhead durch den vector geht gegen Null. Ich kenne den (geringen) Overhead. Das ist auch der Grund, warum man niemals C-Arrays in C++ Code verwenden sollte. Ich ging eben nur davon aus, dass es nicht implementiert ist. Dann danke ich euch aber für die Belehrung. Wilhelm M. schrieb: > atmega-fanboy-;-) schrieb: >> Die Standardlib gehört zum Standard. Und der Standard definiert die >> Sprache. >> Somit gehört auch die Klasse std::vector zur Sprache. > > Nein, zum Standard. Ist ja gut. Dann gehören die Klassen meinetwegen zur Standardlib. >> Alles Teil der STL (Teil des C++ Standards, der die Sprache definiert). > > Nochmal, die STL gibt es nicht mehr, es ist die Standard-C++-Bibliothel, > die ist zwar Bestandteil des Standards, definiert aber nicht die Sprache > selbst. Sie wird aber in C++-Kreisen immer noch als STL bezeichnet. Dass es die offiziell nicht mehr gibt stimmt natürlich. >> >> STL (Standard Template Library) > ist auf AVR gar nicht vorhanden Weil sie nicht implementiert ist oder weil es die STL nicht mehr gibt? > >> Mehrfachvererbung > > Wird generell falsch verstanden. Was ist daran falsch zu verstehen? Die Ableitung einer Klasse von mehreren Klassen. >> Virtuelle Methoden (muss man fallweise entscheiden, zumindest bei >> avr-gcc umständlich) > > Jein. Heißt? >> Verschachtelte Klassen > > Quatsch Okay. >> Automatische Typerkennung (auto-Schlüsselwort) > > Quatsch Auch okay. >> Laufzeit-Typprüfung > > rtti ist auf avr gar nicht möglich Warum nicht? >> Anonyme Funktionen (Lambda-Ausdrücke) > > Quatsch Auch okay. Muss man ja nur wissen. >> new- und delete-Operator (Speicherverwaltung allgemein) > > Auf avr gar nicht realisiert, aber machbar. Der gehört aber ja wohl zur Sprache. Dass man den selbst implementieren kann ist klar. >> Vermutlich ziemlich veraltet, wenn man sich "verrückte oder neue >> Features" so anschaut. > > Genau! Kann man das als normaler User bearbeiten? Dr. Sommer schrieb: > Das ist halt auch Quatsch: > > atmega-fanboy-;-) schrieb: >> STL (Standard Template Library) > Was ist an std::max, std::numeric_limits oder std::tuple böse? Meiner Ansicht nach gar nichts. >> Mehrfachvererbung > Generell fragwürdig, aber auch gar kein Problem. std::tuple basiert > darauf. Warum fragwürdig? >> Virtuelle Methoden (muss man fallweise entscheiden, zumindest bei >> avr-gcc umständlich) > Genauso effizient wir Funktions Zeiger. Kein Problem. Warum meinte Wilhelm dann jein? >> Allzu verrückte oder neue Features wie >> Verschachtelte Klassen > Hat 0 Auswirkung auf Laufzeit Verhalten. Also kein Problem. Ich wusste ehrlich gesagt gar nicht, dass das zu neuen Features zählt. >> Automatische Typerkennung (auto-Schlüsselwort) > Dito. Okay. >> Laufzeit-Typprüfung > Das stimmt schon eher. Schon eher heißt? >> Anonyme Funktionen (Lambda-Ausdrücke) > Genauso effizient wie normale Funktionen. Muss nur implementiert sein. >> new- und delete-Operator (Speicherverwaltung allgemein) > Genau wie malloc Ist es nun implementiert oder nicht?
atmega-fanboy-;-) schrieb: > Ich ging eben nur davon aus, dass es nicht implementiert ist. Bei AVR hast Du keine stdlibc++, deswegen ist es dort out-of-the-box nicht nutztbar. Aber mit ein paar Zeilen selbst zu schreiben. > Sie wird aber in C++-Kreisen immer noch als STL bezeichnet. Dass es die > offiziell nicht mehr gibt stimmt natürlich. Ja, manche Begriffe sind unausrottbar ... >>> STL (Standard Template Library) >> ist auf AVR gar nicht vorhanden > > Weil sie nicht implementiert ist oder weil es die STL nicht mehr gibt? Wird vom avr-gcc nicht mitgeliefert meinte ich. >>> Mehrfachvererbung >> >> Wird generell falsch verstanden. > > Was ist daran falsch zu verstehen? Das es generell schlecht sei! >>> Virtuelle Methoden (muss man fallweise entscheiden, zumindest bei >>> avr-gcc umständlich) >> >> Jein. > > Heißt? Habe ich weiter oben in einem Beitrag erläutert. >>> new- und delete-Operator (Speicherverwaltung allgemein) >> >> Auf avr gar nicht realisiert, aber machbar. > > Der gehört aber ja wohl zur Sprache. Ja. > Dass man den selbst implementieren > kann ist klar. Eigentlich ist das nicht klar ;-) >>> Verschachtelte Klassen >> Hat 0 Auswirkung auf Laufzeit Verhalten. Also kein Problem. > > Ich wusste ehrlich gesagt gar nicht, dass das zu neuen Features zählt. Tut es auch gar nicht. >>> Anonyme Funktionen (Lambda-Ausdrücke) >> Genauso effizient wie normale Funktionen. > > Muss nur implementiert sein. Ist immer vorhanden, weil Bestandteil der Sprache. > >>> new- und delete-Operator (Speicherverwaltung allgemein) >> Genau wie malloc > > Ist es nun implementiert oder nicht? Bei AVR nicht.
:
Bearbeitet durch User
Stefan U. schrieb: > ARM Controller können Code aus dem RAM ausführen (trifft das eigentlich > auf alle zu) Nein das kommt auf die Bus-Implementierung an: M3 und höher können das, M0 SAMD21 kann es, M0 LPC800 kann es nicht. Ist beim 8051 übrigens genau so.
Wilhelm M. schrieb: > Ist immer vorhanden, weil Bestandteil der Sprache. Nach der Logik müssten ja nur auch new/delete vorhanden sein. Exceptions dürften dann ja eigentlich auch nicht implementiert sein, da diese die Standardlib benötigen, welche es ja nicht gibt, obwohl sie zur Sprache gehören, oder? Bei ARM gibt es aber eine C++-Standardlib, oder? Danke aber auf jeden Fall noch einmal an euch alle. ;)
Stefan U. schrieb: > Ja, die heißt aber newlib oder newlib-nano. Das ist aber C . Die C++ Standard Library gehört fest zum GCC oder Clang, und ist immer gleich. Nur beim AVR wird sie nicht mit ausgeliefert, obwohl sie zumindest teilweise auch da genutzt werden könnte (s.o.).
Beitrag #5320540 wurde von einem Moderator gelöscht.
Wilhelm M. schrieb: > die vtable wird ins RAM kopiert. Das macht er aus Performaancegründen Nö, meines Wissens macht er das so, weil es nicht ohne grundlegende architekturelle Änderungen am Compiler zu organisieren ist, dass er dafür plattformspezifische Zugriffe auf einen separaten Adressraum einbauen kann. Es gibt irgendwo einen offenen Bugreport dafür, da kannst du die Details nachlesen. Dr. Sommer schrieb: > Die C++ Standard Library gehört fest zum GCC oder Clang, und ist immer > gleich. Nur beim AVR wird sie nicht mit ausgeliefert, obwohl sie > zumindest teilweise auch da genutzt werden könnte Sie ließ sich zumindest lange Zeit gar nicht compilieren, daher wird sie üblicherweise nicht mitgeliefert. Weiß gar nicht, wie das mittlerweile aussieht. Es hatte mal jemand angefangen, da einiges in der avr-libc zu ändern, damit das besser passt, aber ob nun alle Probleme mit der libstdc++ bereits aufgelöst sind, entzieht sich meiner Kenntnis.
Jörg W. schrieb: > Sie ließ sich zumindest lange Zeit gar nicht compilieren, Das ist wirklich blöde... Es wäre enorm praktisch, wenn zumindest Dinge wie std::numeric_limits, std::tuple, std::max, std::enable_if verfügbar wären. Die haben ja auch kein spezielles Laufzeit-Verhalten und müssten theoretisch gehen...
Dr. Sommer schrieb: > Jörg W. schrieb: >> Sie ließ sich zumindest lange Zeit gar nicht compilieren, > Das ist wirklich blöde... Es wäre enorm praktisch, wenn zumindest Dinge > wie std::numeric_limits, std::tuple, std::max, std::enable_if verfügbar > wären. Die haben ja auch kein spezielles Laufzeit-Verhalten und müssten > theoretisch gehen... Das kannst Du doch herausziehen ... (so habe ich es jedenfalls gemacht mit fast allem, was keine dyn. Allokation macht).
Wilhelm M. schrieb: > Das kannst Du doch herausziehen ... Jo. Ist halt lästig in einem Projekt eine Extra-Wurst für den AVR-GCC zu machen.
Dr. Sommer schrieb: > Wilhelm M. schrieb: >> Das kannst Du doch herausziehen ... > > Jo. Ist halt lästig in einem Projekt eine Extra-Wurst für den AVR-GCC zu > machen. Was aber sinnvoll ist. Es fängt bei so einfachen Sachen an, dass der size_type von std::array nicht immer size_t sein sollte bei den AVRs. Sondern besser abhängig von der Größe des Arrays gewählt wird. Und ähnliches gilt für viele andere Dinge auch, die in der stdlibc++ oft mit maximaler Größe gewählt sind, wohin gegen man aber gerade auf den AVRs etwas effizienter haben möchte.
Wilhelm M. schrieb: > Es fängt bei so einfachen Sachen an, dass der size_type von std::array > nicht immer size_t sein sollte bei den AVRs. Dann wäre es aber nicht mehr Standard-Konform. Auf S. 763 des C++14 Standards ist vorgeschrieben, dass std::array<T, N>::size_type gleich size_t sein muss. Würde eine Implementation davon abweichen, würde das wieder Extra-Würste im Code bedeuten.
Dr. Sommer schrieb: > Wilhelm M. schrieb: >> Es fängt bei so einfachen Sachen an, dass der size_type von std::array >> nicht immer size_t sein sollte bei den AVRs. > > Dann wäre es aber nicht mehr Standard-Konform. Auf S. 763 des C++14 > Standards ist vorgeschrieben, dass std::array<T, N>::size_type gleich > size_t sein muss. Würde eine Implementation davon abweichen, würde das > wieder Extra-Würste im Code bedeuten. Genau das wollte ich damit sagen: die stdlibc++ hat derzeit nicht das Ziel, optimal für kleine Plattformen zu sein!
Plattformen die Indices und Pointer nicht effizient verwalten können sind auch komisch ;-)
Die x µA Sleepmodi unterscheiden sich doch recht stark in der Programmierung. Beim STM32F bootet die CPU beim Verlassen des tiefsten Sleepmode immer neu. Nur die 20 Byte .. x kByte der RTC überstehen den Reboot.
Da gibt's aber auch andere Varianten. Ein SAML21 beispielsweise bietet mehrere verschiedene power domains.
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.