Umstieg 8->32Bit: Codergröße

Hi

Gerd schrieb:
> (32/8)*5500Byte=22K rechne

So kannst du nicht rechnen da dein Cortex M3 ja Thumb2 ausführt was 
soviel heißt wie 16 Bit breite Opcodes. Und dein AVR besitzt auch 16 Bit 
Opcodes. Also wäre die Rechnung (16/16)*5500Byte=5500Byte. Das passt 
aber auch nicht da dein ARM trotz allem noch mit breiteren Adressen 
arbeiten wird und üblicherweise auch einen voluminöseren Startupcode 
braucht. Ohne den Code zu kennen würde ich aus der Hüfte geschossen aber 
sagen das das reinpassen wird.

Matthias

Bei 32-Bittern ist je nach verwendeter Library ein deutlich grösserer 
Grundaufwand einzurechnen. So findet in manchen GCC-Umgebungen die 
Newlib Verwendung und allein die knabbert schon an deinen 16KB. Man kann 
die zwar vermeiden, hat aber dann kein fertiges printf.

Proprietäre Umgebungen sind zwar sehr viel sparsamer, aber auch hier 
sind für den gesamten Startupcode einschliesslich Initialisierung und 
die Interrupt-Verarbeitung ein paar unproduktive KB einzurechnen.

Obacht bei den STM32: Die von ST zur Verfügung gestellte und im Forum 
häufig verwendet Library ist ebenfalls kein Platzwunder, weil aufgrund 
der groben Stückelung sehr viel uberflüssiger Ballast mitkommt.

Ein 32-Bit Controller mit 16KB ist als Entwicklungssystem nicht 
sinnvoll. So ein Modell verwendet man, wenn man am Schluss der 
Enwicklung basierend auf einem besser ausgestatteten Modell der gleichen 
Serie feststellt, dass das letztlich in 16KB Produkt reinpasst, und die 
Stückzahl gross genug ist, um den Preisunterschied bedeutend werden zu 
lassen.

Andererseits kann es leicht passieren, dass ein Programm, das grad so in 
einen Mega128 reinpasst, beim 32-Bitter deutlich kleiner ausfällt. Denn 
obwohl die grossen Jungs bei der direkten I/O deutlich mehr Code fressen 
als die kleinen, macht das bei viel Code nur einen kleinen Teil aus, und 
viele darüber hinaus gehenden Aufgaben löst ein Grosser kompakter als 
ein Kleiner.

Obacht was das RAM angeht: In deinem Fall ist das unproblematisch, aber 
im Gegensatz zum ROM wächst der RAM-Verbrauch grundsätzlich recht 
deutlich. Die dort gespeicherten Sachen sind auch bei sparsamer 
Programmierung unvermeidlich breiter (Stack(s), Pointer).

Anja schrieb:
> - In der Regel brauchst du bei höher integrierten Prozessoren erheblich
> mehr Code für den Boot-Vorgang. (PLL-Lock in, Taktumschaltung usw.).

... und das Setup des Interrupt-Controllers. Das war's dann aber auch 
schon.

Für CM4 stm32f407 in Summe knapp 500 Byte für Clocks und NVIC-Setup (7 
Interrupts).

Für CM3 stm32f103 mit selbstgeschriebenem SystemInit()-Ersatz: ca. 350 
Byte für das gleiche. In beiden Fällen wurde für NVIC-Setup die Library 
verwendet.

Zum Vergleich einen lpc1769, mit eigenem Clock-Setup, ohne NVIC-Setup: 
ca. 150 Byte für die Umstellung auf 120 MHz. Wenn in diesem Fall der 
Standard-Takt reicht, dann sind es 0 Byte.

Bitte nenn' mal CPU und Compiler, wo diese Dinge "erheblich" mehr 
benötigen.


Μαtthias W. schrieb:
> Das passt
> aber auch nicht da dein ARM trotz allem noch mit breiteren Adressen
> arbeiten wird und üblicherweise auch einen voluminöseren Startupcode
> braucht.

Der Startup-Code in Form des "Reset_Handler" belegt bei mir stramme 54 
Byte auf CM4 stm32f407 - inkl. FPU-Initialisierung (Assembler). Mein 
selbstgeschriebener Startup für CM3 stm32f100 mit C belegt 80 Byte.

Gefühlte 80% davon sind für das Kopieren der initialisierten Daten vom 
Flash ins RAM und für den "Zero-Fill". Wäre mir nicht bekannt, dass 
andere Startups das nicht machen, sofern diese MCUs mit C programmiert 
werden.

Bitte nenne mal die CPU, wo der Startup wesentlich größer ist.


> - Sparen wirst du bei Mathematik-Bibliotheken sofern verwendet.

Meine Erfahrung: Beim Wechsel auf ARM thumb spart man fast immer. Als 
ich beim atmega328p an die 32k Grenze gestossen bin, war ich überrascht, 
dass das gleiche Programm in den CM3s deutlich weniger Platz im Flash 
belegt hat: Statt 32k waren es ca. 25k (ich verwende immer gcc -Os). Ich 
führe dies generell auf die Effizienz von thumb zurück, allerdings 
spielt bei mir vermutlich auch die fehlende Optimierung von 
PROGMEM-Strings beim atmega ein größere Rolle (aufgrund von vielen 
Log-Ausgaben).

Einen exakten Vergleich kann ich eben nicht durchführen, da die Variante 
für atmega mittels #ifdef bei der Funktionaliät eingefroren wurde. Die 
ARM-Varianten schaffen es mit wesentlich mehr Funktionen immer noch 
unter die 32k Messlatte.

Es gibt ein Paper "32‐Bit Microcontroller Code Size
Analysis", das den Vergleich ARM thumb mit 16-Bit MSP430 durchführt. Es 
kommt zum gleichen Ergebnis (ist allerdings von ARM).

> Obacht bei den STM32: Die von ST zur Verfügung gestellte und im Forum
> häufig verwendet Library ist ebenfalls kein Platzwunder, weil aufgrund
> der groben Stückelung sehr viel uberflüssiger Ballast mitkommt.

Diese "Bugwelle" spürt man im Bereich um die 16k deutlich. Ich schließe 
mich inzwischen der Meinung an, dass sich die Library nicht lohnt, da 
diese zumindest mir beim "Portieren" von stm32f1 auf stm32f4 nicht 
geholfen hat.

Im obigen Beispiel war dennoch die STM32-Variante mit Lib deutlich 
besser als atmega. lpc1769 (ohne jegliche Lib) war allerdings in der Tat 
am besten.

Ich hab's nicht weiter verfolgt, aber 16-Bit MSP430 hatte immer am 
schlechtesten abgeschnitten, sowohl beim RAM-Bedarf als auch im Flash.

Willi schrieb:
> Informiere Dich erst einmal gründlich über den STM32. Das Teuerste bei
> einem Umstieg für kleinere Stückzahlen wird die Arbeitszeit sein.

Wenn es bei diesem einem Projekt bleibt, wird es sich vermutlich nicht 
lohnen.
Die Frage ist, ab welchem Projekt es sich lohnt.

Es eröffnen sich auch neue Möglichkeiten: Für den genannten Einsatzzweck 
würde ich mir übrigens den CM0 lpc11c24 ansehen, der hat nämlich einen 
integrierten CAN-Controller und -Transceiver und belegt 7x7 mm. 
Verglichen mit einem atmega16 dürfte die Platinenfläche etwas 
schrumpfen, sofern externe CAN-Controller und/oder -Transceiver im 
Einsatz sind.

Für lpc gibt es übrigens von NXP die AN10963 "Reducing code size for 
LPC11XX with LPCXpresso", welche sich auf andere CMx übertragen lässt. 
Der Trick mit dem Linker-Script ist ganz nett.

A. K. schrieb:
> Bei 32-Bittern ist je nach verwendeter Library ein deutlich grösserer
> Grundaufwand einzurechnen. So findet in manchen GCC-Umgebungen die
> Newlib Verwendung und allein die knabbert schon an deinen 16KB. Man kann
> die zwar vermeiden, hat aber dann kein fertiges printf.

Für newlib gilt m. E. das gleiche wie z. B. für die STM Library: Man 
braucht sie nicht wirklich. Im Gegensatz zur STM-Lib habe ich die newlib 
inzwischen eliminiert, was aktive Aufrufe angeht. Dann und wann will der 
gcc bei -Os noch ein memset/memcpy, das war's dann.

A. K. schrieb:
> Obacht was das RAM angeht: In deinem Fall ist das unproblematisch, aber
> im Gegensatz zum ROM wächst der RAM-Verbrauch grundsätzlich recht
> deutlich. Die dort gespeicherten Sachen sind auch bei sparsamer
> Programmierung unvermeidlich breiter (Stack(s), Pointer).

Auch die structs belegen i. d. R. mehr, wenn man auf die Vorteile des 
"Alignments" nicht verzichten mag. Man kann die aber auch "packen", 
wodurch sich "8-Bit feeling" einstellt, im Guten wie im Schlechten ;-)

Deshalb haben die ARMs bei gleicher nomineller Flash-Größe i. d. R. mehr 
RAM.

Meiner Erfahrung nach sind die 6k RAM des STM32F103R4T6A "mehr" wert als 
die 1k des atmega16, da es immer ein paar byte/char-Felder gibt (wie z. 
B. Puffer für Stringverarbeitung oder 512 Byte Puffer für 
SD-Karten-Zugriff), die letztlich einen wesentlichen Eingriff in den RAM 
eines atmegas bedeuten.

Gerd schrieb:
> Angelacht habe ich mir den STM32F103R4T6A, welcher mit 16K Flash und 6K
> RAM für den Preis eine echte Konkurrenz ist. Aber denkt ihr der Flash
> reicht?

Ohne Lib reicht das m. A. nach.

Ich habe für stm32f407 und lpc1769 eine CAN-App, die etwas ähnliches 
macht, zumindest gemäß Deiner Beschreibung. Belegt 11k bzw. 10k Flash 
und 1500 Byte bzw. 900 Byte RAM. Im Einsatz sind jeweils beide 
CAN-Controller, UART-Parser, etwas GPIO und sehr viel Log-Ausgaben. Im 
Falle des stm32f407 mit STM Library, im Falle von lpc "Register direkt".

Wer es belastbarer haben will, muss es halt prüfen (lassen) ;-)

Gerd schrieb:
> Wie würde ich das ohne Lib veranstalten? Mit sind es wohl vier
> Funktionsaufrufe.

Es gibt viele Wege. Ich bin den folgenden gegangen:

- Die Peripherie, z. B. GPIO, mit der Library in Betrieb nehmen
- Parallel zur Library ins Datenblatt schauen, und das nötige in eigene 
Makros/Funktionen//Klassen übernehmen.

Gerd schrieb:
> Ich habe mein Vorhaben nun etwas weiter gesponnen und mir noch einige
> weitere aus der STM32 Reihe angesehen. Die f105 wären natürlich auch
> etwas, durch gleichzeitige Nutzbarkeit von CAN und USB würde ich mir
> hier und da USB-Seriell-Wandler sparen.

Aha, beim Essen kommt der Appetit :-) Das meinte ich mit, "dass sich 
neue Möglichkeiten eröffnen".

Aufpassen beim 103, der kann CAN und USB nicht gleichzeitig.

Gerd schrieb:
> Andererseits wäre der
> Preisvorteil hin. 3,65+1,50€ für Mega16 und MCP2515 ist nicht zu
> unterbieten, ein STM32F105R8T6 z.B. liegt bei 5€+Steuer.

Die Rechnung verstehe ich nicht. Wenn alles netto-Preise sind, dann ist 
der stm günstiger und hat USB. Die "8" steht doch für 64 kb Flash? Dann 
hätte er auch noch mehr Flash. MHz sowieso und restliche Peripherie 
auch.

Gerd schrieb:
> Schon alleine das Mehr an IO-Pins wäre von Vorteil

... und mehr Pins hat er auch noch. Was willst Du noch alles ;-)

Schon mal nach den lpc11c22/lpc11c24 geforscht? Vermutlich nicht viel 
günstiger, aber sehr kompakt. Wie viel spart die wegfallende 
Platinenfläche?

Wenn's um den Preis geht:

http://de.futureelectronics.com/de/technologies/semiconductors/microcontrollers/32-bit/Seiten/5006541-LPC11C24FBD48-301,.aspx?IM=0

LPC11C24 1,78€ bei 1 Stück da ist der Hardwaretreiber auch schon mit 
drin.