Unterschiede zwischen ARM und ATmega in der Programmierung

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.

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?

> 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.

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

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

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 :)

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..

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.

>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

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?

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.

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.

>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.

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.

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.

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.

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.

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.

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().

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.

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 :)

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.

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?

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. ;)

> Bei ARM gibt es aber eine C++-Standardlib, oder?

Ja, die heißt aber newlib oder newlib-nano.

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.).

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...

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.

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.

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.