Flashplatzbedarf 32Bit zu 8Bit Microcontroller

Gleiche Aufgabenstellung für drei MC Familien war ein BLDC Controller 
mit SVM/Sinus/FOC Modulation. Leider habe ich im Moment nur die Grösse 
der Hex Files parat:

STM32F103 (VL Dicovery) - 44kByte
XMega128D3  - 22kByte
Mega88/328  - 21kByte

Gleiche Funktionalität inkl. serieller Konsole, es wurden allerdings die 
jeweiligen Hardware Besonderheiten ausgenutzt, also z.B. AWEX beim XMega 
oder Advanced Timer beim STM32.

Ein 32Bitter braucht in der Regel mehr Flash, Und er braucht auch mehr 
RAM, da Call, Push usw. immer 32Bit sichern müssen.

Mit den kleinen 32-ern mit 8 oder 16kB Flash sollte man daher garnicht 
erst anfangen, das ist gerade so die Blink-LED Klasse.
128kB Flash und 16kB RAM sollten es mindestens sein.

Peter D. schrieb:
> Ein 32Bitter braucht in der Regel mehr Flash, Und er braucht auch mehr
> RAM, da Call, Push usw. immer 32Bit sichern müssen.

Im Prinzip ja. Andererseits kann ein 32-Bitter auch etliche Operationen 
in einem Befehl ausführen, für die ein 8-Bitter mehrere braucht, so daß 
sich das auch wieder etwas relativieren kann.

Es kommt also, wie so oft, immer auf den Einzelfall an.

DerDan schrieb:
> Die Frage ist ja auch warum du von einem 8Bitter auf einen 32Bitter
> umsteigen willst.
> Das macht man doch nur, wenn die Ressourcen des 8Bitter nicht mehr
> ausstreichen.

Sobald man mit ADCs herum spielt und viel Rechnen muss, um dessen Werte 
wieder in passende PWM Werte umzurechnen, ist z.B. ein AVR mit seiner 
limitierten 16-bit Fähigkeiten nur noch ein guter Kompromiss.

Ein STM32Fxx hat statt 10-bit schon 12bit ADC Auflösung und kann dann 
einen 16..32bit Wert in wenigen Befehlen bei kompletter Breite 
verarbeiten.

Arbeitet man viel mit Protokollen in denen einzelne Bits maskiert, 
geshiftet und geschrieben werden müssen, ist die üblichen 8-Bitter auch 
im Nachteil, weil sie oft nur 1-bit Shift oder Rotate unterstützen. Um 
ein Bit n-mal zu verschieben, gibt es dann ellenlange shr oder shl 
Ketten im Listing.

Arbeitet man mit parallelen I/Os deren Bits möglichst synchron 
umgeschaltet werden müssen, haben moderne Cortex M SOCs extrem elegante 
Features, da sie über masken-Register in gleichen Zugriff IOs setzen, 
löschen oder unverändert lassen können.

Bei STM32Fxxx kann man zudem über die Bitbending Option alle Bits im RAM 
und der Peripherie setzen, löschen, abfragen.

> Nun ist es so, dass man bei einem 32Bitter großzugig
> ausgestatte Modelle auswählen kann und auch nicht gleich den kleinsten
> nehmen sollte. Meiner Erfahrung nach kommen mit der Zeit neue
> Anforderungen an die Software. Da ist es schon ganz gut, wenn man noch
> ein wenig Reserve hat.

Gerade bei den STM32 ist es so, dass man deutlich mehr SOC bekommt als 
für den gleichen Preis beim AVR.

> Das mit den kleinst möglichen Variablen:
>
> 7856ujtzuitzu schrieb:
>> bei variablen sollte man schauen das man nur den benötigten platz
>> beansprucht. ( uint8/uint16 ... )
>> und structs mit __attribute(packed) zusammenhält
>
> Stimmt nur wen es globale Variablen sind. Lokale Variablen sollte man
> hingegen immer an der Kontroller Bit breite anlehnen. Ein 32Bitter tut
> sich viel schwerer ein 8Bit Schleifenzähler zu benutzen als gleich ein
> 32Bit Zähler usw. Das liegt daran, das intern immer mit den 32 Bit
> Registern gerechnet wird und Datentypen, die kleiner sind dauernd auf 32
> Bit erweitert werden müssen bzw. von 32Bit wieder auf den kleineren Typ
> gekürzt werden.

Das stimmt alles nur teilweise. Die Cortex M3 können (anders als alte 
ARMv5) unaligned-offset, d.h. man kann 8-bit Variablen auch als solche 
deklarieren und sie belegen dann auch nur ein byte. 
__attribute__((packed)) ist eigentlich nicht erforderlich.

Ebenso benötigt beim ARMv7 ein unaligned-access keinen zusätzlichen 
Code, da die SOCs shift-  rotate-  mask-while-read / -write können. 
Also 32-bit laden und 8-bit daraus maskieren und nach unten schieben ist 
ein einem Befehl erledigt.

>
> Was aber wirklich stimmt, ist das man wesentlich angstfreier
> programmieren kann, weil man nicht immer gleich an einen Ressourcen
> Limit stößt.

Das hat aber noch ganz andere Gründe, die hier noch garnicht angeführt 
wurden. Mal Abgesehen von den schon zuvor genannten "Extras" liebt der 
Cortex Pointer. Ein AVR stolpert über Indirekte Indizierung, oder 
vereinfacht ausgedrückt über Vectoren und Tabellen. Es ist im AVR oft 
sinnvoll zwei I2C Interfaces mit zwei mal dem gleichen Code zu 
verarbeiten, als mit Datenpointern und nur einem Treiber zu arbeiten.

Im Cortex legt man eine Datenstruktur an, die alle Puffer und Zähler und 
Stati für jeweils ein Interface beinhaltet und der nur einmal vorhandene 
Code schaltet zwischen den Datenfeldern um.
--> Halber Code, etweas mehr RAM Verbrauch.

Bei einem AVR kostet es Code, wenn man einer Funktion einen komfortablen 
Rückgabewert verpassen möchte. Daher sind viele Semi-professionellen 
Projekte mit Code ohne doppeltem Boden programmiert.
Bei einem ARMv7 wird R1 immer als erster Parameter übergeben und 
beinhaltet den Return-Wert beim Verlassen der Funktion. Es kostet also 
keinen bis minimalen Overhead, wichtigen Funktionen auch vernünftige 
Return-Codes mitzugeben. Das Stacksegement wird dafür nicht extra 
belastet.

Ein Cortex hat einen linearen Adressraum. Alle Befehle, die Daten 
verarbeiten, können auf RAM oder FLASH zugreifen. Die im AVR 
erforderlichen Verrenkungen um Daten aus dem FLASH zu lesen, sind nicht 
erforderlich.

Weiterhin wird Code eingespart, weil der Registersatz des Cortex auf C 
spezifische Mechanismen optimiert wurde. D.h. Code in mehrere Funktionen 
aufzusplitten verursacht kaum "Kosten". Function-Init und Function-Exit 
sind extrem klein geworden. Und im Gegensatz zu ARMv5 und gcc-4.5 oder 
älter ist es ohne Zusatzkosten möglich eine Funktion mit zig "return x" 
zu spicken, wann immer man sie verlassen möchte.
Komplexe goto exit_1 / goto exit_error.... sind überflüssig.

Im Gegensatz zu den meisten älteren Controllern kann man einen Cortex M 
auch ohne eine einzige Zeile Assembler starten. Die meisten Toolchains 
haben nur deswegen eine startup.s, weil Entwickler "faul" sind und sie 
vom ARMv5 kopiert haben und dann darin nur ein paar Dinge entfernt oder 
angepasst haben. Aber technisch gesehen kann man seinen Cortex mit void 
main(void) und einer bare-metal Toolchain los rennen lassen. Man muss 
dann zuerst mal selber das Datensegment löschen und umkopieren.

Was man allerdings beachten muss ist, dass es deutliche Unterschiede im 
Befehlssatz von Cortex M0, M0+ M3, M4 und M4F gibt. Je nach Aufgabe gilt 
es da vorher mal ein wenig zu recherchieren.

Neben der Code-Größe zählen heute aber oft auch ganz andere Dinge. Wenn 
ich eine Aufgabe in einem etwas mächtigeren SOC in sehr viel kürzerer 
Zeit erledigen kann, dann der auch viel schneller wieder Schlafen gehen.

Ach je, es gibt so viele Gründe die für einen CortexM sprechen...
Klar ist das für viele #Neuland aber es lohnt sich und kann viel Spaß 
machen.

Gruß
Ulrich

DerDan schrieb:
> Das macht man doch nur, wenn die Ressourcen des 8Bitter nicht mehr
> ausstreichen

Stimmt. Aber manchmal ist die Ressource einfach die ADC-Samplerate oder 
die Pinzahl, während der Rest des kleinen AVRs locker ausreichte. 
Ersteres war bei meinem Langzeitprojekt der Grund, die MCU-Familie zu 
wechseln. Jetzt habe ich auch wieder jede Menge Pins übrig.

Mart schrieb:
> Ich möchte umsteigen von 8Bit auf 32Bit Mikrorechner. Vielleicht hat
> schon jemand Erfahrung mit dem Flashbedarf.

Er braucht hauptsächlich mehr RAM, da einige Daten unvermeidlich breiter 
sind als bei einem 8-Bitter, insbesondere was Stacks angeht. Weshalb die 
Quote von ROM zu RAM bei den 32-Bittern meist anders ausfällt, d.h. sie 
haben bei gleicher ROM-Grösse oft mehr RAM.

Beim ROM-Bedarf kommt ein gewisser Overhead hinzu, da die 
Initialisierungsphase deutlich komplexer ist. Bei einem Zwerg mit bisher 
2KB Flash kann dass einen signifikanten Anteil ausmachen.

Beim eigentlichen Programm selbst wird es eher so aussehen, dass grosse 
Programme auf einem jener 32-Bitter mit platzoptimierter Codierung (wie 
Thumb2 oder MIPS16) tendenziell kleiner ausfallen werden als die 
Originale des 8-Bitters. Zumindest wenn man angepasst programmiert wird, 
d.h. nicht so getan wird, als wäre es immer noch ein 8-Bitter. Denn bei 
grossen Programmen ist der grösste Teil des Codes nicht mehr direkt mit 
I/O-Registern verbunden, sondern sitzt auf den I/O-Layern oben drauf, 
und je abstrahierter der Code, desto besser sind oft die 32-Bitter.

Ulrich P. schrieb:
> Das stimmt alles nur teilweise. Die Cortex M3 können (anders als alte
> ARMv5) unaligned-offset, d.h. man kann 8-bit Variablen auch als solche
> deklarieren und sie belegen dann auch nur ein byte.

8-Bit Variablen kann man mit jedem ARM unabhängig vom Alignment 
adressieren. Interessant ist das erst jenseits von 8 Bits.

Man sollte allerdings auf der Rechnung haben, dass die etwas kleineren 
und billigeren Cortex M0 keinen unaligned access beherrschen. Also 
lieber nicht drauf verlassen, wenn man vielleicht mal den Typ wechseln 
will.

A. K. schrieb:
> Mart schrieb:
>> Ich möchte umsteigen von 8Bit auf 32Bit Mikrorechner. Vielleicht hat
>> schon jemand Erfahrung mit dem Flashbedarf.
>
> Er braucht hauptsächlich mehr RAM, da einige Daten unvermeidlich breiter
> sind als bei einem 8-Bitter, insbesondere was Stacks angeht. Weshalb die
> Quote von ROM zu RAM bei den 32-Bittern meist anders ausfällt, d.h. sie
> haben bei gleicher ROM-Grösse oft mehr RAM.

Das ist natürlich korrekt, Heap und Stack operieren natürlich immer 
32-bit breit.

>
> Beim ROM-Bedarf kommt ein gewisser Overhead hinzu, da die
> Initialisierungsphase deutlich komplexer ist. Bei einem Zwerg mit bisher
> 2KB Flash kann dass einen signifikanten Anteil ausmachen.
>

Also das ist nur teilweise korrekt. Durch den linearen Adressraum können 
const Daten gleich im Flash bleiben, es erzeugt keinen Overhead durch 
Spezial-Behandlungen von Daten im Flash wie beim AVR. Es ist in diesem 
Fall aber eine Frage des Anteils von solchen Daten am Projekt, wie weit 
sich das zum Vor- oder Nachteil auswirkt.

Die Initialisierung selbst ist durch die teilweise sehr flexible 
Konfiguration von Spannungen, Clocks und Optionen etwas aufwändiger. Und 
natürlich benötigt man bei einem Chip, der einen GPIO nur zwischen IN 
und OUT umschalten kann weniger code, als bei einem SOC, wo man Drive 
Strength, Pull-Up/-Down, Speed und vieles mehr einstellen kann.

Auf der anderen Seite kann bei einem solchen Chip schon mal einfach 
einen Window-Comparator an einen ADC und diesen an einen Timer 
konfigurieren und schon hat man eine fertige Motor-PWM Stufe, die selber 
keine Zeile Code zur Laufzeit benötigt. Auf einem 8-bitter programmiert 
man ineinander verschachtelte und gegeneinander priorisierte oder 
blockierte Interrupts...

Oder einfacher, mit ein paar Zeilen Code sampelt der STM32Fxxx 20 ADC 
Kanäle in ein Struct aus entsprechend vielen Words oder Longs gleich 
passend aligned. Per DMA und mit Interrupt, wenn alle Samples erfasst 
sind.

Mach das mal auf dem AVR...

> Beim eigentlichen Programm selbst wird es eher so aussehen, dass grosse
> Programme auf einem jener 32-Bitter mit platzoptimierter Codierung (wie
> Thumb2 oder MIPS16) tendenziell kleiner ausfallen werden als die
> Originale des 8-Bitters. Zumindest wenn man angepasst programmiert wird,
> d.h. nicht so getan wird, als wäre es immer noch ein 8-Bitter. Denn bei
> grossen Programmen ist der grösste Teil des Codes nicht mehr direkt mit
> I/O-Registern verbunden, sondern sitzt auf den I/O-Layern oben drauf,
> und je abstrahierter der Code, desto besser sind oft die 32-Bitter.

Da gebe ich Dir völlig recht. Dadurch dass es bei einem Cortex wenig 
kostet zu abstrahieren oder zu modularisieren, kann man seine Software 
deutlich lesbarer gestalten. Dadurch lässt sich auch sehr viel besser im 
Team arbeiten.

Und natürlich kann man immer und bei jeder Architektur und bei jedem 
Compiler Code so schreiben, dass man den Optimizer komplett torpediert. 
Daher sollte man gerade als Ein- oder Umsteiger einfach mal die Listings 
einschalten und sich den generierten Assembler Code ansehen. Dann mal im 
C Code spielen und sehen was im .lst passiert... Man wird Augen machen!

Gruß
Ulrich

Mart schrieb:
> verbraucht da Befehle nun 32Bit lang sind?

Sind sie nicht. Es gibt keinen Zusammenhang zwischen der Breite der 
Codierung der Befehle und der Breite der Daten. Auch wenn die 
ursprünglichen 32-Bit RISCSs mit 32 Bits breiten Befehlen arbeiteten.

Die Befehle der Cortex M0 (Thumb) sind fast ausnahmslos 16 Bits breit. 
Bei den Cortex M3/M4 (Thumb2) ist es eine Mischung aus 16 und 32 Bits.

Die ARMs hatten ursprünglich nur den 32-Bit Befehlssatz. Mit dem 
beliebten ARM7TDMI Core kam ein zweiter alternativ nutzbarer Thumb 
Befehlssatz hinzu, der mit einer kompakteren Codierung Platz spart, aber 
dies ging zu Lasten der Performance. Thumb2 ersetzte diesen bimodalen 
Ansatz durch einen einzigen Befehlssatz, der den Platzbedarf von Thumb 
mit der Leistung des ursprünglichen Befehlssatzes kombiniert.

Bei den PIC32 ist das ähnlich bimodal wie beim ARM7TDMI. Der 
ursprüngliche MIP32 Befehlssatz kennt nur 32 Bits breite Befehle. Aber 
der alternative MIPS16 Befehlssatz codiert kompakter mit 16 Bits breiten 
Befehlen, worunter aber die Mächtigkeit der Befehle leidet.

Ulrich P. schrieb:
> Mach das mal auf dem AVR...

Das ist natürlich richtig.

Die ursprüngliche Frage war freilich, wie es Programmen ergeht, die von 
einem 8-Bitter stammen. Wenn man ein Programm für AVR auf einen STM32 
portieren will, dann wird es sich meist um ein Problem handeln, das mit 
einem AVR einigermassen lösbar ist. ;-)

A. K. schrieb:
> Die ursprüngliche Frage war freilich, wie es Programmen ergeht, die von
> einem 8-Bitter stammen.

Das ist immer die Frage :)

Wenn man vorher die Hardware und die Aufgabe in brauchbarer Weise 
getrennt hatte, kann man die Software fast immer recht zügig übertragen.
Am Anfang werden einem ein wenig die Kniffe und Tricks im Weg stehen, 
die man beim 8-bitter machen wollte oder musste und man wird natürlich 
auch am Anfang einfach den Unterbau des SOC Herstellers drunter setzen, 
damit man Timer und GPIOs einfach ansprechen kann. Der oft sub-optimale 
Code dieser Demo-Projekte (sie sind eher edukativ wie brauchbar) 
zusammen mit einem durch 8-bit Spezialitäten torpedierten Optimizer wird 
sicher deutlich mehr Platz brauchen, aber deutlich weniger als den 
befürchteten Faktor 2.

Es ist fast nicht zu sagen, wie es wirklich 1:1 umgesetzt wäre, denn 
wenn man schon eine neue Platine macht, weil der SOC gewechselt wird, 
dann tauscht man auch dies und jenes noch aus und damit ist der Code und 
die Funktionalität dann doch nicht mehr identisch. Abgesehen davon will 
der Vertrieb oder das Marketing dann auch neue Features...

Aber man kann einen kombinierten Temperatur-/Luftfeuchte-Sensor mit 
Taupunktberechung über einen STM32F103 an einen CAN Bus mit 
Auto-Adressvergabe und vollständig implementierten CANopen Protokoll und 
Bootloader mit Firmware-Update über CANopen in ca 40kB Code 
implementieren. Da beim Fertiger die 128k Version aber billiger war als 
die 64k Version, ist bis heute noch viel Platz in dem Sensor.

Bei einem aktuellen Projekt erwarte ich sogar, dass der Code kleiner 
wird, da in diesem, bisher auf AVR laufend, viel 16-bit Timer 
Berechnungen und viele 16-/32-bit Messwertberechnungen erfolgen und 
darüber hinaus große Tabellen adressiert werden müssen.

Wenn man aber sieht, dass ein STM32L oder STM32F Entwickler-Board 10€ 
bis max. 49€ kostet... Nicht quatschen sondern kaufen, spielen, testen, 
entwickeln.
Niemand kann nun zu 100% sagen, ob Dein Projekt besser in die oder jene 
Struktur passt und niemand kann Dir sagen ob dir die Cortex Architektur 
liegt. Ich mache AVR nur noch, weil es beruflich (noch) nötig ist, 
privat gibt es nur noch Cortex. Und beruflich ab nächstem Jahr auch :)

Gruß
Ulrich

7856ujtzuitzu schrieb:
> das kann gut sein das hier die IDE bzw der compiler blödsinn macht.
> aber ein
>
> struct{
>   uint8_t x;
> }x_t;
> ist hier nicht 8bit groß

Da 32bit Zugriffe schneller und Codegünstiger sind,werden Variable 
häufig an 32bit Grenzen angelegt.

Mancher Code profitiert ziemlich stark von den grösseren Datenbreiten 
und leistungsfähigeren Shiftoperationen bei ARM-CPUs, z.B. FatFs:

1

obj-m1284p/ff.o  :

2

section           size   addr

3

.text            12134      0

4

.data                0      0

5

.bss               519      0

6

.progmem.data       19      0

7

8

9

obj-lpc1768/ff.o  :

10

section            size   addr

11

.text              7012      0

12

.data                 0      0

13

.bss                524      0

14

.rodata              19      0

Also um Missverständnissen vorzubeugen...

Die CortexM haben unterschiedlich große Befehlssätze. Ein M0 kann 
deutlich weniger als ein M4F, was aber sicherlich jedem klar ist.

Beim unaligned addressing ist es so, dass der alte ARMv5 den Umgang mit 
unaligned data nicht kannte. Der Compiler hat das ausgebügelt, teilweise 
mit hohen Kosten in Sachen Code und Rechenzeit.

Die ARMv7 Architektur kann damit umgehen, denn sie kann in einem Befehl 
ein unaligend byte laden. Sie kann ebenso in einem Befehl mehr-byte 
Variablen laden, liegen die aber über eine 32-bit word Grenze, so wird 
natürlich ein 2. Zugriff über den Bus erforderlich. Damit ist die 
Ausführung in diesem Fall langsamer.

Also ARMv7 hebt nicht die Grenzen der Physik auf, vereinfacht aber eine 
ganze Menge. Je nach Projekt kann es durchaus Sinn machen, wenn man sich 
pfiffige structe ausdenkt, um seine Daten zu managen und diese dann mit 
__attribute__((packed)) zu versehen. Legt man nicht wild multi-byte 
Variablen über 32-bit Grenzen darin ab, spart man einem Menge RAM bei 
minimalen Kosten an Code und Performance.

Genereller Ratschlag:
Immer wieder mal schauen, wie das Assembler Listing des eigenen Codes 
aussieht. Das hilft dabei zu verstehen, wie man dem Optimizer ein wenig 
zuarbeiten kann. Und .map Files wurden nicht als Debugging für 
Compiler-Entwickler erfunden...

Wer sich mal mit STM32 oder generell mit Cortex M vertraut machen will, 
sollte auf jeden Fall unbedingt mal die Hitex Guides to Cortex oder 
Hitex Guide to STM32 ergoogeln.

Gruß
Ulrich.

Steffen R. schrieb:
> Da 32bit Zugriffe schneller und Codegünstiger sind,werden Variable
> häufig an 32bit Grenzen angelegt.

8-Bit Zugriffe aufs RAM sind genauso schnell und genauso lang wie 32-Bit 
Zugriffe. Register können jedoch nur komplett verarbeitet werden, 
weshalb es bei lokalen Daten einen Unterschied machen kann. Globale 
und statische Daten sind wenig betroffen, einzig implizites Caching in 
Registern ist da relevant.

Lothar schrieb:
> Da die meisten kleinen ARM zudem ein API-ROM haben

Es gibt welche, aber "die meisten"?

Angesichts des Codes mancher Hersteller-Libs wär ich ausserdem nicht so 
sicher, ob man sich damit nicht ein faules Ei ins Netz legt.

Was mich wundert ist, das bei den 32 Bit ARM die ich bisher gesehen habe 
kaum Pins nebeneinander rausgeführt waren die zusammen gehören.
Also ein Display anzusteuern führt entweder dazu, dass man jeden Pin 
einzeln ansteuert, oder zu einem grösseren Knoten im Layout.

Ich habe vor ein paar Wochen ein Layout mit einem SAM3Eirgenwas gesehen, 
da war ein SPI mit fünf Chips dran und das ergab ein fürchterliches 
Chaos weil alleine schon MISO, MISO und SCK über die ganze Breite einer 
Seite verschmiert waren.
Beim SPI macht das nichts am Code, aber "mal eben" acht Pins zusammen 
setzen zu wollen könnte schwierig werden.

Rudolph R. schrieb:
> Was mich wundert ist, das bei den 32 Bit ARM die ich bisher gesehen habe
> kaum Pins nebeneinander rausgeführt waren die zusammen gehören.

Die SAM3 habe ich nicht im Kopf, aber das Pinout der STM32 ist auch 
etwas verwirrend.

Deren Pinout ist davon geprägt, dass das exakt gleiche Silizium in 
diversen Gehäusen unterschiedlicher Pinanzahl verkauft wird. Da ist also 
im 32-er, 48-er und 64-er Gehäuse der gleiche Chip drin. Vielleicht 
verwendet zudem der nächstgrössere Chip mit 64 bis 100sonstwas Pins 
zwecks Familienähnlichkeit bei 64 Pins das gleiche Pinout und die 
gleiche Funktionszuordnung.

Das Bonding kann die Drähte nicht beliebig kreuz und quer verdrahten und 
es ergibt wenig Sinn, beim SPI einen Pin wegzulassen, oder beim GPIO nur 
ungerade Bits rauszuführen. Da kann es also passieren, dass die Pins im 
kleinsten Gehäuse leidlich passen und sich im grössten Gehäuse einige 
unpassende Pins zwischenrein mogeln.

Ulrich P. schrieb:
> Mach das mal auf dem AVR...

Die Kehrseite von viel mehr potentiellen Möglichkeiten sind viel mehr 
Dinge, die es zu beachten gilt. Deshalb: Wenn der AVR die Angelegenheit 
bewältigt, ist er auch die ideale Besetzung.

Immer wieder Dankeschön für solche Threads die zeigen, welche 
Komplikationen und neuen Herausforderungen mit 32 Bit wirklich 
daherkommen. Da sollten die neuen Möglichkeiten aber schon sowas von 
benötigt werden.

Peter D. schrieb:
> Mit den kleinen 32-ern mit 8 oder 16kB Flash sollte man daher garnicht
> erst anfangen, das ist gerade so die Blink-LED Klasse.

Kann man mehr 32-bittigen Aufwand für die gleiche Funktion (eines 
8-Bitters) besser verdeutlichen?

Lothar schrieb:
> Kenne kein Industrieprodukt wo AVR eingesetzt wird.

Die sind oder waren ohne Ende in Weisser Ware verbaut.
Mein Trockner hat einen Mega32L drin.
Mein letzter Geschirrspüler hatte einen AVR in der Anzeige, einen in der 
Steuerung und einen in der Umwälzpumpe - und war gar nicht so alt, der 
wird immer noch verkauft.

W.S. schrieb:
> da merkt man dann auch, daß sowas wie der Keil selbst in der auf 32K
> begrenzten freien Version dank deutlich besseren Codes viel besser
> abschneidet als der GCC.

Das hängt nicht zuletzt davon ab, welches GCC Paket man nutzt. Sobald 
die Newlib drin ist hat man erst einmal verloren. Rowley beispielsweise 
schneidet demgegenüber wesentlich besser ab.

Ich mag mich nur ungern mit einer 32K Version anfreunden, wenn klar ist, 
dass aufgrund des privaten Budgets jenseits davon definitiv Schluss ist. 
Wenn dann der Code etwas grösser sein sollte - was solls. Wer grosse 
Stückzahlen rauswirft und über gesparte 30ct pro Exemplar die Kosten von 
Keil wieder reinholt, für den ist das natürlich was Anderes.

W.S. schrieb:

> ABER: Die Leute, die mangels Denkvermögen zu allererst sowas wie sprintf
> oder CMSIS oder (bei ST) die berüchtigte ST-Lib zu brauchen meinen,
> haben damit schon kleinere Chips völlig zugestopft und brüllen folglich
> sofort nach mindestens 128 K Flash und 16 K RAM.

Naja. CMSIS (System-Header plus z.B. core_cm3.h) selbst besteht 
eigentlich nur aus den ganzen Registernamen und sonst fast nix. Das 
binde ich grundsätzlich ein, weil es die Treiberentwicklung extrem 
vereinfacht. Zu der ST-Lib: Zustimmung, die ist eher pfui.

Ansonsten habe ich auf jedem Controller, den ich in C programmiere und 
der eine sinnvolle Ausgabemöglichkeit (also z.B. UART oder kleines 
6-Zeichen-LCD) hat, auch eine printf()-Implementation drin. Die 
erleichtert mir das Debuggen ungemein. Die (einmalig!) 2K Flash und 256 
Byte RAM ist es mir wert. Außerdem brauche ich an anderen Stellen die 
Ausgaben nicht zusammenstückeln, was auch ein bisschen Code spart.

Das hat aber nix mit Dummheit zu tun, sondern ist eine bewusste 
Bequemlichkeitsentscheidung.

Ulrich P. schrieb:
> Oder einfacher, mit ein paar Zeilen Code sampelt der STM32Fxxx 20 ADC
> Kanäle in ein Struct aus entsprechend vielen Words oder Longs gleich
> passend aligned. Per DMA und mit Interrupt, wenn alle Samples erfasst
> sind.

Im Prinzip habe ich das auch schon mit nem xmega gemacht. Der adc lief 
im free running Mode und hat bei jedem Sample per DMA einen 32 Byte 
buffer im ram beschrieben. Wenn 32 Bytes voll waren wurde über das event 
System der spi angetriggert die Daten in den buffer des nrf24l01 zu 
packen. Auf der Gegenseite wurden die Daten dann per dma mit einem Timer 
gesteuerten event mit 44100 Hz in den DAC geschaufelt und schon hatte 
man fast ohne CPU last und wenigen Zeilen code eine audio Übertragung in 
"CD Qualität"
Sicherlich haben die stm32 ihre Vorteile gerade wenn es darum geht 32 
bit Werte zu verarbeiten,aber programmiertechnisch sind sie ein graus. 
Alleine die Ports einzustellen mit den Alternativen e Funktionen und 
dass die" DDR" Register eben nicht Gehirnkompatibel aufgebaut sind (also 
z. B.  Jedes bit ein Port wie bei avr) und man daher zwangsläufig auf 
die std peripheral lib zurückgreifen sollte/muss:

1

  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;

2

  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;

3

  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

4

  GPIO_Init(GPIOC, &GPIO_InitStructure);

5

6

  GPIO_WriteBit(GPIOC, GPIO_Pin_9, Bit_SET)

Nervt einfach. Klar einmal eingestellt läuft es, aber da erstmal 
hinzukommen ist unhandlich.  Avrs und andere 8-Bitter sind da echt 
gehirnkompatibler

Timmo H. schrieb:
> z. B.  Jedes bit ein Port wie bei avr) und man daher zwangsläufig auf
> die std peripheral lib zurückgreifen sollte/muss:

Schaurig daran ist weniger die Portkonfiguration selbst, als vielmehr 
die umständliche Interface-Technik der Library.

Das kann auch so aussehen, indem die häufgsten Porteinstellungen in 
Parametern einer Funktion zusammengefasst werden:

1

gpio_config(GPIOA, 1<<9, GPIO_Mode_Output2MHz | GPIO_AltOut_PushPull);  // UART1

2

gpio_config(GPIOB, 0xFF00, GPIO_Mode_Output2MHz | GPIO_Output_PushPull);  // LEDs

Die Pins über die ST-Funktionen zu kontrollieren ist umständlicher als 
direkt übers BSRR. Ein Register, dass ich deutlich praktischer finde als 
die Portregister der ATmega/tinys.

Beispiel: Wenn man einen Port hat, auf dem sowohl ein Text-LCD hängt, 
als auch sowas wie die Richtungssteuerung eines RS485 Transceivers, dann 
kann die Ansteuerung der LCD Datenpins so aussehen:

1

gpio->BSRR = 0x0F<<16 | data;

AVR ist umständlicher.

W.S. schrieb:
> Peter schreibt öfters mal so ein generalisiertes Zeugs ohne davon
> wirklich was zu verstehen.

Du hast das mißverstanden. Natürlich kann man auf den kleinen Cortex die 
gleichen Sachen laufen lassen, wie auf den 8Bittern, bloß wozu dann 
überhaupt umsteigen? Das ist doch nur unnötiger Aufwand.

Wenn ich nen 32Bit Boliden nehme, dann weil man deutlich mehr machen 
will, als nur Blink-LED Applikationen und dann sind 16kB Flash einfach 
zu wenig.
Die Softwerker würden mir ein 16kB-Board aber sowas von um die Ohren 
hauen.

Zur Zeit ist auf vielen Modulen ein AT90CAN128 mit 128kB Flash drauf. 
Und was die Softwerker einmal an Flash haben, das geben die nicht wieder 
her.
Bei 32Bit darf ich nichts mehr unter 512kB Flash, 64kB RAM designen 
(LPC1768).

Was sagt ein Programmierer auf dem Sterbebett? "Mehr Flash!"

Peter D. schrieb:
> Was sagt ein Programmierer auf dem Sterbebett? "Mehr Flash!"

Ich würde eher sagen "Mehr Pins!" weil obwohl meine Programme oft in 
einen ATtiny13A reinpassen, sind die 5 nutzbaren Pins leider der 
Flaschenhals. Derzeit bastel ich ein Leistungsmessgerät mit 
OLED-Display. Die Flashbelegung liegt bei knapp 850 Bytes, aber mir 
fehlt einfach ein Pin für den externen ADC. Verdammt aber auch.

Timmo H. schrieb:
> Sicherlich haben die stm32 ihre Vorteile gerade wenn es darum geht 32
> bit Werte zu verarbeiten,aber programmiertechnisch sind sie ein graus.
> Alleine die Ports einzustellen mit den Alternativen e Funktionen und
> dass die" DDR" Register eben nicht Gehirnkompatibel aufgebaut sind (also
> z. B.  Jedes bit ein Port wie bei avr) und man daher zwangsläufig auf
> die std peripheral lib zurückgreifen sollte/muss:
>   GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
>   GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;
>   GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
>   GPIO_Init(GPIOC, &GPIO_InitStructure);
>
>   GPIO_WriteBit(GPIOC, GPIO_Pin_9, Bit_SET)
> Nervt einfach. Klar einmal eingestellt läuft es, aber da erstmal
> hinzukommen ist unhandlich.  Avrs und andere 8-Bitter sind da echt
> gehirnkompatibler

Das ist ein großes Ärgernis dieser STM-Libraries. Wie ich zuvor schon 
schrieb ist dieser Code eher edukativ, wie sinnvoll...

Im damaligen Port von NutO/S war das quasi das erste, was da raus 
geflogen ist… Mit ein paar kleinen Kniffen und etwas Gehirnschmalz kann 
man eine Pointer / Tabellen getriebene API für die GPIOs schreiben und 
der user muss nur noch gpio_init( port, pin, options); machen und basta. 
Der Code ist 1/10 so groß und die API ist eingänglicher...

In Deinem Beispiel wäre das dann
gpio_init( &GPIOC, GPIO_PIN9, GPIO_OUTPUT_PP | GPIO_SPEED_50M);

Das war jetzt frei aus dem Kopf, aber so ähnlich wurde das damals 
implementiert. Werde in den nächsten Wochen wieder ein neues Projekt 
starten und es wird wieder auf NutO/S basieren, denke ich.

W.S. schrieb:
> eure letzten 10 Bastel-Projekte, die ihr mit
> nem ARM/Cortex gemacht habt?
> Ich vermute mal, daß außer bei einigen Angebern bei recht vielen ne Zahl
> herauskommt, die unter 32K liegt.

Unter 32K, Du lieber Gott. Unter 3K hätte mehr Eindruck gemacht, aber 
vermutlich langt das beim ARM nur zum LED-Blinken ;-(

W.S. schrieb:
> Griff in die Bastelkiste:
> Total ROM Size (Code + RO Data + RW Data)       9496 (   9.27kB)
> ...
> Total ROM Size (Code + RO Data + RW Data)      12897 (  12.59kB)

Dann hoffe ich mal daß das meiste davon Mediadaten enthält ...

W.S. schrieb:
> Bedenke doch mal, was es für unsäglicher Umstände bei den AVR's macht,
> Zeiger an ne Funktion zu übergeben, je nachdem ob selbiger auf RAM oder
> ROM zeigt.

Daten liegen im Flash oder RAM- entsprechend werden in Asm die Pointer 
in der richtigen Weise beladen- Funktionen dafür sind einfach nur 
unterschiedlich. Was ist daran unsäglich? Die getrennten Adressbereiche 
bringen schließlich auch Vorteile mit sich wenn zum Beispiel Befehle- 
und Daten gleichzeitig geladen werden können.

W.S. schrieb:
> Du klebst z.T. deshalb auf
> den AVR's, weil du eine aus meiner Sicht völlig unbegründete haushohe
> Ehrfurcht vor 32 bittigen µC entwickelt hast.

... oder bei geeigneten Apps einfach nur Einsicht in das Nötige und 
Sinnvolle? Und soweit ich mich erinnere entwickelt Peter D. auch mit 
Cortex M.

Peter D. schrieb:
> Bei 32Bit darf ich nichts mehr unter 512kB Flash, 64kB RAM designen
> (LPC1768).

W.S. schrieb:
> Du klebst z.T. deshalb auf den AVR's, weil du eine aus meiner Sicht
>völlig unbegründete haushohe Ehrfurcht vor 32 bittigen µC entwickelt hast.

W.S., vielleicht zuerst lesen und dann schreiben?

Ich glaube nicht, dass meine diesbezügliche Meinung sehr massgebend sein 
kann, weil ich meine Brötchen hauptsaechlich mit Desktop-Software 
verdiene und nur hin und wieder mal den Lötkolben anwerfe.

Aber auch ich halte es wie Peter: Bei grösseren Projekten greife ich zu 
32-Bittern. Einen banalen Sensor mal an ein RS485-Bus anschliessen, also 
dafür nehme ich immer noch AVR's.
Die letzten 2 abgeschlossene Projekte:
- ca. 150kB
- ca. 300kB + 16kB Bootloader
Aktuelles Projekt: 75kB, dürfe aber so mit 400kB enden

Das Mischen der MCUs hat für mich auch den angenehmen Nebeneffekt, dass 
ich diese gleichzeitig debuggen kann.

Mein letztes Projekt (migriert von ATmega644 auf STM32F103 wegen 
schnelleren ADCs):

AVR: 88kB (Hex)
ARM: 127kB (Hex)

Das Programm ist bei beiden weitestgehend identisch, der STM32 hat nur 
ein paar Routinen für ein externes I2C-EEPROM dazubekommen.