Hallo! Ich bin im Begriff bei einem Projekt aus Preis- und Leistungsgründen auf einen anderen µC umzusteigen. Angelacht habe ich mir die STM32F103 schon lange, aber nachdem ich feststellen musste, dass die sogar im Preis vor den AVR liegen, will ich ein Projekt umstellen. Momentan verwende ich einen (logischerweise mehrere (15++), sonst würde der Umstieg nicht lohnen) ATmega16-16 welche folgendermaßen belegt ist: AVR Memory Usage ---------------- Device: atmega16 Program: 5550 bytes (33.9% Full) (.text + .data + .bootloader) Data: 567 bytes (55.4% Full) (.data + .bss + .noinit) Der Code besteht im wesentlichen aus CAN, Uart, einem Parser für den Uart und noch ein paar kleinere IO-Funktionen die auf Parser und CAN hören. 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? Beim RAM ist klar, der reicht mehr als dicke, aber wenn ich (32/8)*5500Byte=22K rechne, ist er zu knapp bemessen. Lässt sich das überhaupt so dumm pauschal sagen? Klar könnte ich den Code selbst portieren und compilieren, aber so ein Umstieg dauert... Wäre super, wenn ihr eure Erfahrungen aus dem Umsteigerbereich teilen würdet. MfG, Gerd
Gerd schrieb: > aber wenn ich > (32/8)*5500Byte=22K rechne, so kannst Du das auf keinen Fall rechnen. Beim ATMega hat der kleinste Befehl nicht 8 sondern 16 Bit. Ohne jetzt den STM genauer zu kennen: - In der Regel brauchst du bei höher integrierten Prozessoren erheblich mehr Code für den Boot-Vorgang. (PLL-Lock in, Taktumschaltung usw.). - Sparen wirst du bei Mathematik-Bibliotheken sofern verwendet. Gruß Anja
Gerd schrieb: > Lässt sich das überhaupt so dumm pauschal sagen? Nein! Informiere Dich erst einmal gründlich über den STM32. Das Teuerste bei einem Umstieg für kleinere Stückzahlen wird die Arbeitszeit sein.
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) ;-)
Vielen Dank schonmal für eure mitgeteilten Erfahrungen. Wenn ich jetzt grob zusammenfasse, könnte der Platz reichen, wenn ich keine Libs verwende. Nun meine Frage als dummer Umsteiger: Was ich bisher in Beispiel-Code gesehn habe stellen die ST-Libs grundlegende Funktionen wie z.B. Konfiguration von Ein-/Ausgängen zur verfügung. Wie würde ich das ohne Lib veranstalten? Mit sind es wohl vier Funktionsaufrufe. 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. 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. Mal weiter vergleichen, vielleicht kann ich mich noch entscheiden. Schon alleine das Mehr an IO-Pins wäre von Vorteil (Verkaufsargument) Vielen Dank euch auf jeden Fall. MfG, Gerd
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?
Nunja, manchmal hilft Klotzen statt Kleckern. Ich bin jetzt von meiner Idee aus Kostengründen umzusteigen abgekommen. 'Immerhin läuft das jetzige System wunderbar. (bzgl Preis: Mega16+MCP2515=5€ inkl. MwSt., STM32F105R8T6 5€ exkl. MwSt.) Aber verkuckt habe ich mich trotzdem in die STM32, besonders wegen dem Mehr an Möglichkeiten. Ein 32-Bitter mit 72MHz ist nunmal etwas ganz anderes als ein 8-Bitter mit 16MHz... . Von der Umfangreicheren Peripherie mal ganz zu schweigen. Es wird wohl eine neue Produktversion geben mit mehr Möglichkeiten. Audio von USB-Stick/SD-Karte wäre wohl eine davon. Mal informieren was man an den USB OTG noch alles hinbekommt. Ich bedanke mich recht herzlich bei euch. Ich befürchte man liest sich bald wieder, wenn ich bei den STM32 am verzweifeln bin. MfG, Gerd
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.