Hallo, Ich möchte umsteigen von 8Bit auf 32Bit Mikrorechner. Vielleicht hat schon jemand Erfahrung mit dem Flashbedarf. wenn ich bei einem 8Bit Microcontroller einen Platzbedarf im Flash von 32KB habe, und dieses Programm portiere in einen 32Bit Microcontroller, wieviel Flashbedarf hat das Programm dann? Wird beim 32Bit µC mehr Flash verbraucht da Befehle nun 32Bit lang sind?
> Wird beim 32Bit µC mehr Flash verbraucht da Befehle nun 32Bit lang sind?
Im Prinzip ja. Allerdings versuchen die Hersteller das zu optimieren. In
der Praxis ist es bedeutungslos weil 32Bit Controller deutlich mehr
Flash haben. Und wenn man dann erstmal einen Controller hat der 128k
Flash oder mehr hat dann wird man feststellen das der eigentliche
Programmcode in den meisten Faellen nur einen kleinen Teil einnimmt. Man
braucht dann eher Platz fuer Daten und die sind unabhaengig von der
Bitbreite.
Da ist es schon wichtiger sein Augenmerk auf den RAM-Verbrauch zu legen
weil es sich anbietet mit groesseren Datentypen zu arbeiten.
Olaf
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.
hi wir haben in der Firma lange Zeit AVRs eingesetzt. nun zu Cortex M0/M3 für neue Produkte gewechselt. es gibt fälle ( floating point rechnungen ) da brauch der 32bitter wirklich mehr flash. in den üblichen fällen jedoch klappt das recht gut und der bedarf ist kaum höher als beim 8bitter. hatte auch schon projekte wo der 32bit code später kleiner war gerade dann wenn der 8bitter doch häufig 16/32bittig rechnen soll. hier kann man gut auf 32bit optimieren gerade beim M3 schau ich kaum noch hin was codegrößen angeht. da wird auch mal mit malloc/calloc/free und verketteten listen gearbeitet ohne das man angst haben muss. bei variablen sollte man schauen das man nur den benötigten platz beansprucht. ( uint8/uint16 ... ) und structs mit __attribute(packed) zusammenhält dann klappt das schon ...
was oft hilft ist die GCC newlib zu nutzen. hier muss man zwar etwas auf die eigenheiten schauen. aber die codegröße reduziert sich enorm. auch -flto ist manchmal eine option
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.
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. 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. 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. Was aber wirklich stimmt, ist das man wesentlich angstfreier programmieren kann, weil man nicht immer gleich an einen Ressourcen Limit stößt. Mfg
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
Ulrich P. schrieb: > Ach je, es gibt so viele Gründe die für einen CortexM sprechen... Selbst für Hobbyisten extrem günstig (Nucleo Boards bei Reichelt < 14 €). Und vor allem: Debugger die quasi nichts kosten und super funktionieren (bei den meisten Boards sowieso onboard).
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.
:
Bearbeitet durch User
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. > __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. hi 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ß ein struct __attribute(packed){ uint8_t x; }x_t; struct __attribute(packed){ unsigned int x :8; }x_t; hingegen schon kann wie gesagt eine eigenart oder falshe einstellung sein
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.
:
Bearbeitet durch User
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. ;-)
:
Bearbeitet durch User
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 |
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. Mouser hat vom LPC810 DIP8 mit 4K Flash >10000 auf Lager, irgendwer wird die also schon kaufen. Passt immerhin ein kompletter MIDI Synthesizer drauf: https://www.adafruit.com/products/2400 Da die meisten kleinen ARM zudem ein API-ROM haben mit Treibern für USART, SPI, I2C braucht es auch gar nicht so viel Flash.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
Moby A. schrieb: > Wenn der AVR die Angelegenheit > bewältigt, ist er auch die ideale Besetzung. Kenne kein Industrieprodukt wo AVR eingesetzt wird. Einfache Steuerungen: 8051, Rechenleistung erforderlich: ARM, Günstigster Preis: PIC
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.
> Kenne kein Industrieprodukt wo AVR eingesetzt wird. Einfache > Steuerungen: 8051, Rechenleistung erforderlich: ARM, Günstigster Preis: > PIC Grosse Stueckzahlen, lange verfuegbarkeit, viel Rechenleistung: Renesas. .-) Olaf
Moby A. schrieb: > 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? Peter schreibt öfters mal so ein generalisiertes Zeugs ohne davon wirklich was zu verstehen. Ich habe z.B. ne Menge Geräte mit LPC2101 (ARM7TDMI) gebaut, 8K Flash, 2K RAM - und es reicht für kleinere Sachen aus, wo man kein Grafikdisplay dran hat, sondern entweder ein Alpha-LCD oder einfach nur eine Handvoll 7Segment-LED-Displays im Multiplex. Man soll ja nicht vergessen, daß man selbst bei älteren ARM7TDMI neben dem 32 bittigen ARM-Code auch den 16 bittigen THUMB code hat UND daß so ein µC für recht viele Operationen deutlich weniger Maschinenbefehle braucht als ein 8 bitiger µC. 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. Dabei geht es - wenn man einigermaßen dezent vorgeht - eben auch mit 8K Flash / 2K RAM - und 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. Also: Wer einen 8 Bitter bisher in C programmiert und dabei keinen vom PC gedankenlos übernommenen Code mit dabei hat, wird keine großartigen Unterschiede bemerken. Wer jedoch seinen 8 Bitter bislang in Assembler programmiert hat, wird hingegen merken, daß dies bei ARM's und Cortexen nur noch für wirklich zeitkritische Teile sinnig ist (DSP-Funktionalität) und er wird sich an deutlich größeren Codeumfang durch C gewöhnen müssen. Trotzdem sind auch kleinere Chips mit weniger als den von Peter so gering geschätzten 32 K durchaus für kleinere Vorhaben - also für Bastlerisches - eine sinnvolle Sache. W.S.
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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!"
:
Bearbeitet durch User
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.
Peter D. schrieb: > 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). Vom LPC11C24 mit nur 32K Flash werden inzwischen scheinbar ähnliche Stückzahlen verkauft wie vom LPC1768
Peter D. schrieb: > Du hast das mißverstanden... ... > Wenn ich nen 32Bit Boliden nehme, dann weil... BOLIDEN Oh nein, ich habe das ganz gut verstanden. 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. Brauchst du nicht, ist unnötig. Du solltest einfach keine Angst vor 32 bittigen Maschinen haben und das ganze lockerer sehen. Die Dinger sind gelegentlich billiger als 8 Bitter und sowas zählt bei mir mehr als irgendwelche eigenen Vorstellungen über Angemessenheit für 4 Bitter, für 8 Bitter, dann 16 Bitter, 32 Bitter usw. 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. Mit nem µC im v.Neumann Stil ist das ganze Gehadere darum einfach weg weg weg... und basta. Ist ne Erleichterung! Auch bei ganz kleinen Anwendungen. Mein Aufhänger war dein Geposte von "mindestens 128K" und so. Das war schlichtweg ne Übertreibung. Es ist zwar logisch, daß man für größere Vorhaben auch größere Speichervolumina braucht, aber die Welt besteht nicht nur aus sowas. Eigentlich alle ARM-Hersteller bieten auch Chips mit 8, 16 und 32 K Flash an - und die sind billig. Ich hatte neulich sowas bei RS gesehen, nen 40 MHz M0+ von Freescale, 8K Flash / 2K RAM und das Ganze für ca. 60..70 Cent. Bei den Regionen, die du angezielt hast (128K/16K oder größer) liegt man dann sofort jenseits von 2.80€ netto. Mich reizt es durchaus, hier mal die Frage an alle zu stellen: Wieviel K Flash brauchen 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. Ich mache hier mal nen Anfang mit nem Griff in die Bastelkiste: Total ROM Size (Code + RO Data + RW Data) 9496 ( 9.27kB) Total ROM Size (Code + RO Data + RW Data) 46840 ( 45.74kB) Total ROM Size (Code + RO Data + RW Data) 16208 ( 15.83kB) Total ROM Size (Code + RO Data + RW Data) 13452 ( 13.14kB) Total ROM Size (Code + RO Data + RW Data) 23392 ( 22.84kB) Total ROM Size (Code + RO Data + RW Data) 55784 ( 54.48kB) Total ROM Size (Code + RO Data + RW Data) 78624 ( 76.78kB) Total ROM Size (Code + RO Data + RW Data) 13444 ( 13.13kB) Total ROM Size (Code + RO Data + RW Data) 12308 ( 12.02kB) Total ROM Size (Code + RO Data + RW Data) 12897 ( 12.59kB) OK, es sind nur Bastelprojekte und es sind keine beruflichen Projekte dabei. Aber dennoch kann man sehen, daß die Mehrzahl eher nicht umfänglich ist. Bei den größeren schlagen die Fonts für's bunte LCD zu Buche. Gerade solche ab 22 Pt tragen da kräftig auf. Hier noch die Lernbetty 0.04 als Beispiel (incl. Fonts und Sound): Total ROM Size (Code + RO Data + RW Data) 46972 ( 45.87kB) W.S.
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.
Moby A. schrieb: > Unter 32K, Du lieber Gott. Unter 3K hätte mehr Eindruck gemacht, aber > vermutlich langt das beim ARM nur zum LED-Blinken ;-( wenn 3K überhaupt reichen. Die ARMs rennen so schnell, wenn man da was blinken sehen will muss man schon mit dem massiven Einfügen von nops rechnen. Und die Mege an nops braucht nur mal ihren Platz im Flash...
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?
:
Bearbeitet durch User
Leute, ihr veranstaltet nur unproduktives Geschwätz. Lommt lieber mal mit handfesten Daten rüber. Mehmet K. schrieb: > W.S., vielleicht zuerst lesen und dann schreiben? Genau DAS gebe ich dir postwendend zurück. Lies mal: 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. > 128kB Flash und 16kB RAM sollten es mindestens sein. Und er darf bei 32 bittern nicht unter 512K oder so anfangen. Das heißt im Klartext: "O heilige 32 Bit ihr seid ja so groß, euch darf ich nur für GANZ GROSSE PROJEKTE überhaupt in Betracht ziehen." Und folgerichtig hat er genau das gepostet, was er sich eingeprägt hat. Aber 8 oder 16 K Flash ist bedeutend mehr als nur Blink-LED Klasse. Wenn man's vernünftig macht. Also, Leute, postet mal was an handfesten Daten und hört mit dem Gesülze auf. W.S.
ASM Fans wie Mobby kommen auch beim 32 Bitter noch mit 4-8 K Flash aus - viel mehr kann man kaum übersehen. Das ist allerdings schon etwas mehr als beim 8 Bitter. Je nach Programm braucht man beim ARM von der Tendenz schon etwas mehr Speicher, insbesondere RAM. So groß ist der Unterschied meist aber nicht - mehr als etwa das doppelte sollte es kaum werden. Vieles kommt eher davon dass man auf dem größeren µC dann zusätzliche Funktionen nutzt wie Libraries für USB, graphisches LCD, einen ausführlichen Selbsttest oder Bootloader mit vielen Optionen und Verschlüsselung. Gerade bei den ARMs ist mehr Speicher aber auch relativ günstig im Vergleich zu den 8 Bits µCs. Für die Entwicklung nutzt man oft auch erst einmal ein Modell mit relativ viel Speicher (z.B. Mega328 (32 kB)) und wählt dann ggf. für das fertige Produkt die Auführung die vom Speicher noch ausreicht (z.B. Mega88(8 kB)). Heute gibt es ja oft pinkomplatible µCs mit verschieden viel Speicher. Wenn man beim 8 Bit µC an das obere Ende der Reihe kommt (etwa AVR mit 128 K und mehr), liegt man da bei der Wahl ohnehin eher falch.
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.
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.