Eigentlich mag ich dieses Thema nicht, weil es immer zu endlosen Diskussionen führt, die im Kreis laufen. Mangels Erfahrung, hatte ich mich dabei bisher weitgehend zurück gehalten. Aber jetzt möchte ich auch mal meinen Senf dazu geben, denn ich habe seit ein paar Tagen ein ARM Kit auf dem Tisch liegen und spiele damit herum. Als Hauptargument für ARM wird hier oft angegeben, daß man für gleiches Geld und Stromaufnahme viel mehr Leistung bekommen würde. Dem kann ich nicht zustimmen. Und zwar darum: Wenn ich von einem ATmega328P ausgehend auf einen STM32F103CB wechsele, dann bleibe ich ungefähr in der gleichen Preisklasse (jedenfalls was Endverbraucher die bei Conrad/Reichelt einkaufen angeht) und die Stromaufnahme ist ähnlich. Dafür erhalte ich 4x soviel Flash Speicher. Aber meine Programme sind auch locker doppelt so groß. Laut Marketing Geschwätz erhalte ich 72 Mhz, aber effektiv kommen da wegen der nötigen Waitstates nur 24 Mhz heraus - was kaum mehr ist, als meine geliebten AVR's können. Natürlich gibt es auch viel größere ARM's, die wären dann allerdings nicht mehr wirklich mit AVR's zu vergleichen, da sie in jeder Hinsicht in einer anderen Liga spielen. Ich muss schon zustimmen, dass man bei ARM Controllern etwas mehr fürs gleiche Geld bekommt. Aber es ist IMHO nicht so viel mehr, wie hier meistens gesagt wird. ARM Architektur zu erlernen erscheint mir dennoch sinnvoll, eben weil man da mehr Luft nach oben hat. Wenn ich mit einem Atmega1284 nicht mehr auskomme, wird es eng. Bei ARM könnte ich relativ schmerzfrei den nächst größeren verwenden - bis in den Gigahertz und Gigabyte Bereich. Xmegas würde ich zum Lernen nicht empfehlen. Das sind meiner Meinung nach halbgare Produkte, die den Befehlssatz von AVR mit der besseren I/O Hardware von ARM zu kombinieren versuchen. Damit wird meiner Meinung nach eine Lücke gefüllt, von der mir gar nicht bewusst war, dass sie existiert. Ich brauche sie jedenfalls nicht. Einsteigern, die gerade mal wissen, wie eine LED Funktioniert, würde ich nach wie vor raten, mit AVR Controllern anzufangen - weil sie einfacher sind. Aber erstmal die Finger von den Fuses lassen. Taktfrequenzen kann man bei den halbwegs aktuellen Modellen auch per Software ändern. Mein erstes AVR Programm hatte ich mitsamt Installation der nötigen Entwicklungstools schon am ersten Abend am Laufen. Für das erste ARM Programm brauchte ich 3 Tage - trotz der Vorkenntnisse. Das sagt doch eigentlich schon alles. Entweder habe ich mich saublöde angestellt, oder ich habe Recht (das ARM viel Komplexer sind).
:
Gesperrt durch Moderator
Ich habe ARMs von anderen Herstellern (TI, NXP). Auf denen hatte auch innerhalb einer Stunde ein "Hallo Welt" laufen. Da liegt es wohl eher an der mitgelieferten Entwicklungsumgebung, dass man 3 Tage braucht. Warum hier alle auf STM stehen, kann ich nicht nachvollziehen. Ich fand deren Tools am kompliziertesten von allen bisher ausprobierten.
Stefan U. schrieb: > Eigentlich mag ich dieses Thema nicht, weil es immer zu endlosen > Diskussionen führt, die im Kreis laufen. Mangels Erfahrung, hatte ich > mich dabei bisher weitgehend zurück gehalten. > > Aber jetzt möchte ich auch mal meinen Senf dazu geben, denn ich habe > seit ein paar Tagen ein ARM Kit auf dem Tisch liegen und spiele damit > herum. Schade. Wäre besser gewesen, solchen Unsinn nicht zu schreiben. > Als Hauptargument für ARM wird hier oft angegeben, daß man für gleiches > Geld und Stromaufnahme viel mehr Leistung bekommen würde. Wer behauptet das? > Wenn ich von einem ATmega328P ausgehend auf einen STM32F103CB wechsele, > dann bleibe ich ungefähr in der gleichen Preisklasse (jedenfalls was > Endverbraucher die bei Conrad/Reichelt einkaufen angeht) und die > Stromaufnahme ist ähnlich. Ahja, Du vergleichst hier einen (mindestens) 64-Pinner mit komplexer Peripherie mit einem simplen AVR... > Laut Marketing Geschwätz erhalte ich 72 Mhz, aber effektiv kommen da > wegen der nötigen Waitstates nur 24 Mhz heraus - was kaum mehr ist, als > meine geliebten AVR's können. Erstens kann der mit 72MHz innerhalb der Spec betrieben werden, zum anderen hat der Controller Prefetchbuffer, die einiges abfangen. > Natürlich gibt es auch viel größere ARM's, die wären dann allerdings > nicht mehr wirklich mit AVR's zu vergleichen, da sie in jeder Hinsicht > in einer anderen Liga spielen. Tut der kleine STM32 auch schon. > Ich muss schon zustimmen, dass man bei ARM Controllern etwas mehr fürs > gleiche Geld bekommt. Aber es ist IMHO nicht so viel mehr, wie hier > meistens gesagt wird. Na dann schau mal die Doku an. Alleine der DMA ist den Sprung schon wert. Display-Refresh oder ADC-Auslesen macht der STM ohne CPU-Beteiligung im Hintergrund, während der AVR mühsam nach Luft schnappt vor lauter Interrupts. > ARM Architektur zu erlernen erscheint mir dennoch sinnvoll, eben weil > man da mehr Luft nach oben hat. Wenn ich mit einem Atmega1284 nicht mehr > auskomme, wird es eng. Bei ARM könnte ich relativ schmerzfrei den nächst > größeren verwenden - bis in den Gigahertz und Gigabyte Bereich. Das sind dann aber viele verschiedene Architekturen. ARM-M geht bisher nur bis 400MHz, darüber gibt es keine Mikrocontroller mehr, das sind dann die Cortex-A-Typen. > Mein erstes AVR Programm hatte ich mitsamt Installation der nötigen > Entwicklungstools schon am ersten Abend am Laufen. Für das erste ARM > Programm brauchte ich 3 Tage - trotz der Vorkenntnisse. Das sagt doch > eigentlich schon alles. Entweder habe ich mich saublöde angestellt, oder > ich habe Recht (das ARM viel Komplexer sind). Es ist Ersteres, glaub mir...
Stefan U. schrieb: > Aber jetzt möchte ich auch mal meinen Senf dazu geben, denn ich habe > seit ein paar Tagen ein ARM Kit auf dem Tisch liegen und spiele damit > herum. Wie lange hast Du Dich zuvor mit den diversen AVRs beschäftigt? Wieso maßt Du Dir also nach ein paar Tagen Spielerei mit einem STM32 ein Urteil an?
Stefan U. schrieb: > Dafür erhalte ich 4x soviel Flash Speicher. Aber meine Programme sind > auch locker doppelt so groß. Das gilt vielleicht für trivialste 8-Bit Programme. Sowohl AVR als auch ARMV7-M benutzen 16-bittige Instruktionen, letzteres kennt auch 32-Bittige Instruktionen. Bei 16- und 32- bittigen Berechnungen ist der Erwartungswert der Codegröße für den STM deutlich kleiner, da der AVR diese nicht mehr in einem Schritt abhandeln kann. Bei trivialen Programmen zählt auch die Größe der LibC und der Intialisierungen, die sind bei STM und ARM-GCC(+newlib) deutlich größer als bei AVR. Dafür hat der STM aber mehr Flash eingebaut. Stefan U. schrieb: > Bei ARM könnte ich relativ schmerzfrei den nächst > größeren verwenden - bis in den Gigahertz und Gigabyte Bereich. Da müsstest Du aber i.d.R. die Plattform / den Hersteller wechseln. Das macht fast genausoviel Aua wie Wechsel von AVR zu ARM - nur der Core ist gleicht, die ganze angehängte Peripherie aber von Hersteller zu Hersteller total verschieden. Stefan U. schrieb: > Einsteigern, die gerade mal wissen, wie eine LED Funktioniert, würde ich > nach wie vor raten, mit AVR Controllern anzufangen - weil sie einfacher > sind. LOL. Ich sage nur: Fuses. Es gibt auch sehr einfache ARM, auf einem Nordicsemi NRF51 z.B. muss man zum LED Leuchten nur den GPIO auf Output und High (oder Low) setzen, fertich. Der ist in vielen Teilen einfacher als ein AVR aufgebaut IMHO. Die hier im Forum oft erwähnten STM32 gehören aber zu den komplizierteren Varianten.
Soviel Blödsinn an so einem schönen sonnigen Sonntag. :'( > Einsteigern, die gerade mal wissen, wie eine LED Funktioniert, würde ich > nach wie vor raten, mit AVR Controllern anzufangen - weil sie einfacher > sind. Aber erstmal die Finger von den Fuses lassen. Taktfrequenzen kann > man bei den halbwegs aktuellen Modellen auch per Software ändern. Bitte nicht. Wenn man neu einsteigt, darf es ruhig s o t a sein. Heute also Cortex.
Stefan U. schrieb: > Dafür erhalte ich 4x soviel Flash Speicher. Aber meine Programme sind > auch locker doppelt so groß. Halt ich für ein Gerücht. Lass mich raten: Du hast den STMCube oder die Standard Peripheral Libray benutzt? Und gleichzeitig programmierst du den AVR mit den Standard IO Funktionen per Hand. Und dann mit einem einfachen Hallo Welt? Der Startup Code eines ARMs ist rießig im Vergleich zum AVR... Bei Hallo Welt zählt der Startup Code schon etwas mehr als bei einem wirklich komplexen Programm. Arbeite mal an einem großen Projekt damit, dann wirst du's verstehen!
Sorry guys, was bitte schön sind 8-Bit Programme? Seit ihr schon wach und wieder nüchtern?
STMler schrieb: > nur bis 400MHz, musste Schmunzeln. Habs mir nochmal durchgelesen. "Nur" bis 400MHz hehe.
Stefan U. schrieb: > Ich muss schon zustimmen, dass man bei ARM Controllern etwas mehr fürs > gleiche Geld bekommt. Aber es ist IMHO nicht so viel mehr, wie hier > meistens gesagt wird. O doch. Alleine schon DMA die man an fast alles dranhängen kann... Timer, mehrere I2C, mehrere SPI... Mehrere USART-Ports mit CAN, IrDa, LIN, SmartCard... > Dafür erhalte ich 4x soviel Flash Speicher. Aber meine Programme sind > auch locker doppelt so groß. Selbst wenn es stimmt - es ist immerhin doppelt so viel... Nur ist der ARM ein 32-bitter, da muss er ganz einfach bei normalen Programmen und Berechnungen kürzeren und schnelleren Code erzeugen. Und die benötigten Library Routinen werden selbstverständlich nur einmal geladen - danach ist es bloß ein Aufruf. Deswegen steht dein Vergleich (aber auch nur vielleicht) nur bei ganz kurzen und einfachen Programmen, bei komplexen Programmen und Berechnungen stimmt das nie und nimmer. > Laut Marketing Geschwätz erhalte ich 72 Mhz, aber effektiv kommen da > wegen der nötigen Waitstates nur 24 Mhz heraus - was kaum mehr ist, als > meine geliebten AVR's können. Das stimmt schon mal nicht.
:
Bearbeitet durch User
PittyJ schrieb: > Warum hier alle auf STM stehen, kann ich nicht nachvollziehen. ST macht eben den größten Hype, bei allen anderen wie TI, NXP, Nordic etc gibt es lange nicht so viel geschenkt oder Eval-Boards zu Preisen als ob die den Händlern geschenkt werden würden.
Stefan U. schrieb: > Laut Marketing Geschwätz erhalte ich 72 Mhz, aber effektiv kommen da > wegen der nötigen Waitstates nur 24 Mhz heraus - was kaum mehr ist, als > meine geliebten AVR's können. Du kannst Code in den RAM auslagern, dann läuft der auch mit 72Mhz ohne Wait-States. Bzgl Rechenleistung man bei 8Bit vs 32Bit nicht diskutieren ... Stefan U. schrieb: > Aber es ist IMHO nicht so viel mehr, wie hier > meistens gesagt wird. Schau dir alleine mal die Timer mit PWM an ... USB hat selbst ein F103 schon. Stefan U. schrieb: > Aber jetzt möchte ich auch mal meinen Senf dazu geben, denn ich habe > seit ein paar Tagen ein ARM Kit auf dem Tisch liegen und spiele damit > herum. Dann beschäftige dich noch etwas damit, bis du fundierte Kenntnisse hast. Nach deiner Anfänger-Meinung hatte hier eigentlich niemand gefragt, weshalb ich mich über so einen Thread wundere ...
:
Bearbeitet durch User
Wegen Speicherverbrauch: Es ist so, dass der konstante Overhead größer ist als bei AVR (allein die Interruptvektoren). Sprich, bei sehr kleinen Programmen mag dein Vorwurf stimmen, dass das Programm doppelt so viel Flash belegt. Je größer dein Projekt wird, desto deutlicher lässt sich deine Theorie des doppelten Speicherbedarfs widerlegen: Es steigt nicht weiter mit Faktor 2!
STMler schrieb: > mit einem simplen AVR Damit ist doch alles gesagt. AVR ist simpel. In jeder Beziehung. Und reicht doch für die große Mehrzahl an Projekten.
Hier mal ein kleiner Benchmark zwischen Arduino-Uno und STM32F103: Beitrag "Re: STM32 Arduino" Es ergibt sich das selbe Bild wie schon früher: Der ARM ist ca. 4x schneller.
Hi Naja, bei 72MHz zu 16MHz sollte schon 'ungefähr 4x so schnell' drin sein. ... weshalb halt alle Nase ein SUV vorbeigeschoben kommt, weil das Ding, mit einem Fiat Panda verglichen, halt auch viiieeel mehr Platz bietet und viel mehr Beschleunigung entwickeln kann - ok, dafür frisst der SUV halt ne Kleinigkeit mehr ... aber ist halt viiieeel mehr und toll und in Bunt ist Der auch. MfG PS: Äpfel und Birnen, aber immerhin, ein Vergleich.
Cortex schrieb: > Sorry guys, was bitte schön sind 8-Bit Programme? Programme für 8-Bit-Prozessoren wie den in Atmels AVR-Reihe verbauten Prozessorkern. Auch wenn der Programmspeicher (das Flash) mit 16 Bit angesprochen wird, ist der AVR-Kern ein 8-Bit-Kern.
Patrick J. schrieb: > Hi > > Naja, bei 72MHz zu 16MHz sollte schon 'ungefähr 4x so schnell' drin > sein. > > ... weshalb halt alle Nase ein SUV vorbeigeschoben kommt, weil das Ding, > mit einem Fiat Panda verglichen, halt auch viiieeel mehr Platz bietet > und viel mehr Beschleunigung entwickeln kann - ok, dafür frisst der SUV > halt ne Kleinigkeit mehr ... aber ist halt viiieeel mehr und toll und in > Bunt ist Der auch. > > MfG > > PS: Äpfel und Birnen, aber immerhin, ein Vergleich. Der ARM verbraucht aber nicht mehr als AVR. Nix Äpfel mit Birnen, sondern schöner saftiger großer Cortex vs kleinem schrumpeligen AVR.
Rufus Τ. F. schrieb: > Cortex schrieb: > Sorry guys, was bitte schön sind 8-Bit Programme? > > Programme für 8-Bit-Prozessoren wie den in Atmels AVR-Reihe verbauten > Prozessorkern. > > Auch wenn der Programmspeicher (das Flash) mit 16 Bit angesprochen wird, > ist der AVR-Kern ein 8-Bit-Kern. Hä? Das Programm wird nicht in 8-Bit geschrieben, sondern durch einen Compiler (oder ASM) für das Target übersetzt. Es ist also kein 8-Bit Prpgramm und bestimmt kein typisches.
Hi Bei 4-facher Taktrate darf ich doch davon ausgehen, daß die 4-fache Menge an Befehlen durchgespult werden kann, trotz schrumpelig und so. Soll mich aber auch eher weniger interessieren, wie die heutigen Schwanzprothesen aussehen ;) Daß 32bit viel cooler als die 8bit sind, ist aber hier egal, oder? MfG
Nix Schwanzvergleich, nur Korrektur vom Eingangspost. Da schreibt einer Sch... und das muss nicht sein.
Mal sehen ob ich auf meiner von mir fallengelassenen Bananenschale selber ausrutsche;-) Zum Thema passt sicherlich "Jedem Tierchen sein Pläsierchen" Für reine Steueraufgaben ohne nennenswerte Fließkommarechnungsnotwendigkeit reichen die meisten 8-Bitter allemal. Wenn allerdings viel gerechnet werden soll, finde ich, findet der ARM besser seine Daseinsberechtigung. Auch wenn TCP/IP gemacht werden muß sind gewisse ARM Modelle damit vorteilhafter hardwaremäßig. Sonst ist es eigentlich wurscht. Alles was der 8-Bitter kann, kann auch der ARM. Ob jetzt die Ports 8-Bit breit sind oder 16-Bit, kann man in den meisten Fällen als Jacke mit Hose sein lassen. An die Komplexität und Anwendung der Peripherien gewöhnt man sich. War ich damals froh, daß der RTC Zähler beim F103 als 32-Bit Zähler ausgeführt war. Zeitabstände ließen sich damit unkompliziert messen. Mach das mit BCD Zeitformat der meisten RTCs. Auch der SYSTICK Timer ist sehr angenehm. Was halt beim ARM angenehm ist, ist z.B. die Verfügbarkeit von DMA. Es ist doch angenehm wenn der ADC vollkommen im Hintergrund lebendige Meßwerte produziert. Relativ zu typischen 8-Bittern sind auch bei keinen ARMs die FLASH und RAM Resourcen proportional. Auch wenn der Overhead etwas größer beim ARM ist, gleicht sich das später wieder aus. Ich sehe das eher locker. Nichts auf der Welt ist perfekt. Trotzdem kann man viele Probleme erfolgreich lösen. Obwohl ich immer noch gerne mit 8-Bittern herumspiele, zögere ich nicht einen ARM zu verwenden wenn es mir die Lösung des Problems erleichtert. In meinem Universum ist Platz für alle guten technischen Lösungen. Wenn ich mich allerdings entscheiden müßte, dann fällt meine Wahl ohne überlegen zu müssen auf ARM. Allerdings würde ich es gerne sehen wenn man mal mit den dokumentierten Errata aufräumen würde. Die haben ja wahre Erratabücher... Schönen Sonntag noch!
:
Bearbeitet durch User
Mampf F. schrieb: > Stefan U. schrieb: >> Laut Marketing Geschwätz erhalte ich 72 Mhz, aber effektiv kommen da >> wegen der nötigen Waitstates nur 24 Mhz heraus - was kaum mehr ist, als >> meine geliebten AVR's können. > > Du kannst Code in den RAM auslagern, dann läuft der auch mit 72Mhz ohne > Wait-States. Bzgl Rechenleistung man bei 8Bit vs 32Bit nicht diskutieren > ... > Flash kann man nicht beliebig schnell machen aber die Datenbreite erhöhen. Dein AVR liest 8 Bit und der Arm mindestens 32 Bit gleichzeitig Beim STM32F446 sind es sogar 128 Bit + Prefetch und Cachelines. Das ist einfache eine andere Welt ...
Mit einem F103 mußte ich mal ein Thermocouple (K,T,E,J) linearisieren. Ohne Tabellen schaffte der F103 mit Horner's Methode(9.Ordnung) in nur 14us bei 36MHz (!) in Fließkommarechnungsformat. Mit einem 8-bitter tut man sich hier schon schwerer. In anderen Worten, beim ARM kann man sich auch solche Lösungen ohne Gewissensbisse erlauben. seitenweise Tabellen haben zu müssen, konnte ich jede benötigte Thermocouple Type nach NIST linearisieren.
:
Bearbeitet durch User
Jobst M. schrieb: > Stefan U. schrieb: >> meine geliebten AVR's > > Liebe macht blind. > Das wird es wohl sein ... > > Gruß > > Jobst Warum sich entscheiden zu müssen? Die Welt ist groß genug für alle!
Ich verstehe eigentlich nicht recht warum immer Striche in den Sand gezogen werden müssen. Die Industrie offeriert uns heutzutage doch so vele Lösungsmöglichkeiten, sprich es gibt einen uC optimiert für nahezu jeden erdenkbaren Anwendungsbereich. Es gilt dann doch nur, sich genug zu informieren welche Lösung optimal für die jeweiligen Anforderungen ist und den Zugang zu den Entwicklungstools. Mit den heutig gebräuchlichen uC Entwicklungssprachen sind die Unterschiede sowieso nicht mehr so gravierend und eher fließend sobald man mit dem Gebrauch der Peripherien vertraut ist. Abgesehen davon, gibt es genug Verpackungen (CUBE, CMIS, StdLIB) so man will. Ich könnte mir als Hobbyist heutzutage keine bessere Zeit zum Spielen vorstellen. Nutzt es doch anstatt so oft so viel zu meckern;-) Freut Euch über das was ihr schon habt. In den 80er Jahren war das eine ganz andere Geschichte. Alles mußte hart erarbeitet werden. Duck und weg...
:
Bearbeitet durch User
Gerhard O. schrieb: > Freut Euch über das was ihr schon habt. In den 80er Jahren war das eine > ganz andere Geschichte. Alles mußte hart erarbeitet werden. Sei froh, daß Du die 70er nicht mitmachen mußtest ;-)
Gerhard O. schrieb: > Für reine Steueraufgaben ohne nennenswerte > Fließkommarechnungsnotwendigkeit reichen die meisten 8-Bitter allemal. Bei meinem letzten Projekt hab ich meine "Toolbox" um STM32F103 erweitert - sonst fast nur AVR und manchmal FPGA (wenn es angebracht war)-, weil der Battery-Backed RTC und Backup-Register einfach ein super Feature sind :) Alles andere hätte der AVR auch direkt können - ach wobei, ich wollte USB ja auch noch. Das geht zwar software-mäßig mit vUSB, aber wenn man Timer laufen hat (Dot-Matrix Multiplexing + IRMP), kriegt der vUSB massive Probleme.
:
Bearbeitet durch User
Ich finde, das alle ihre Berechtigung haben. Als Versuch habe ich damals ein mittel-komplexes Projekt mal mit Mega, XMega und STM32F100 aufgebaut und dabei deren Peripherie, soweit sie das Projekt betraf, voll ausgenutzt. Beim Mega also alles zu Fuss, beim XMega die AWEX Unit und beim STM32 den Advanced Timer, um die BLDC Steuerung zu realisieren. Der Löwenanteil der Software wurde zuerst auf dem Mega gemacht und dann auf die grösseren MC portiert und angepasst. Alle haben den Job erfüllt, es gab keinen klaren Sieger, allerdings war der kleine Mega fast 100% beschäftigt und der XMega war recht teuer. Das einzige, was wirklich ein Hindernis war, war die Suche nach einer vernünftigen IDE für den STM32. Da lief am besten Atollic, bevor sie dann Geld haben wollten, Eclipse war ein Monster, das auf meinem Quadcore extrem träge war, EM:Bits(?) wollte nicht, Coocox gibts nicht mehr. D.h, das ich vermutlich, wenn ich es wieder brauche, zurück zu Atollic gehen werde oder mit dem alten Coocox 1.7 weitermache.
:
Bearbeitet durch User
m.n. schrieb: > Gerhard O. schrieb: >> Freut Euch über das was ihr schon habt. In den 80er Jahren war das eine >> ganz andere Geschichte. Alles mußte hart erarbeitet werden. > > Sei froh, daß Du die 70er nicht mitmachen mußtest ;-) Das hätte vielleicht einen falschen Eindruck gegeben...
Matthias S. schrieb: > ?.. Da lief am besten Atollic, bevor sie > dann Geld haben wollten, Eclipse war ein Monster, das auf meinem > Quadcore extrem träge war, EM:Bits(?) wollte nicht, Coocox gibts nicht > mehr. D.h, das ich vermutlich, wenn ich es wieder brauche, zurück zu > Atollic gehen werde oder mit dem alten Coocox 1.7 weitermache. Atollic ist wieder frei, als LITE Version ohne Code Size Einschränkungen zu haben, erhältlich. Versuch's mal wieder.
Noch mal zur Geschwindigkeit: mein TI-ARM ist ein Keystone 2: - 4 Kerne mit 1.4 GHz - USB-3 - 10 GBit Ethernet Alles das brauche ich auch bei den Videoanwendungen. Mit einem AVR würde ich da nicht weit kommen. Es gibt also nicht 'Den ARM' und die STMs sind mehr Low-End. So wie ein 8086 zur Core-I7 Linie.
Stefan U. schrieb: > Mein erstes AVR Programm hatte ich mitsamt Installation der nötigen > Entwicklungstools schon am ersten Abend am Laufen. Für das erste ARM > Programm brauchte ich 3 Tage - trotz der Vorkenntnisse. Das sagt doch > eigentlich schon alles. Entweder habe ich mich saublöde angestellt, oder > ich habe Recht (das ARM viel Komplexer sind). Die Frage ist doch auf was für Hilfestellungen du zurückgreifen konntest. Wenn ich auf dieser Seite mal den Artikel https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial mit dem Artikel https://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger vergleiche, dann würde ich wohl auch eher mit einem AVR anfangen wollen. Auf der einen Seite eine wirklich erstklassige Einführung in den AVR, mit selbst für Anfänger verständlichen Erklärungen wie man Register benutzt, wofür Interrupts gut sind und mit Links zu weiterführenden Themen wie UART, Timern, usw. Auf der anderen Seite (STM32 für Einsteiger) bekomme ich in der ersten Tabelle die Information wie viele Hardware-Breakpoints ein PIC18 hat, in der zweiten Tabelle die Information das ich einen AVR mit Arduino-IDE unter Windows, Linux und MacOS programmieren kann und im Abschnitt "Übersicht CPU-Funktionalitäten" folgt ein Blockdiagramm von einem MSP430FR5739 neben dem Bild eines MSP430 Development Boards. Im Hauptartikel "STM 32" gibt es neben der Auflistung von IDEs und Libraries (welche jeweils zum Teil nicht mehr weiterentwickelt werden) noch eine Auflistung der Vorteile der Cortex-M gegenüber ARM7 und die Information das ein LPC1100 ab 0,65$ verfügbar ist. Der Hauptartikel über ARM hat die selben Probleme. Das beste daran ist wohl der Hinweis, auf "The Definitive Guide to ARM Cortex M3", wobei nicht jeder Anfänger geneigt ist für einen dicken Schinken 42€ auszugeben bzw. nicht jeder Zugang zum Online-Portal von Elsevier hat und man außerdem auch eigentlich keine 800 Seiten durchlesen müsste um an die Information zu kommen, dass jeder Cortex-M im Flash als erstes Wort den Stack-Pointer und als zweites Wort den Reset-Vector erwartet und ab da dann mit der internen Clock (noch ohne irgendwelche PLL-Konfiguration) ab dem Reset-Handler loswerkelt und Befehle abarbeitet. Kurzum, was diesem Forum fehlt ist ein vernünftiges ARM-Tutorial, wo ganz allgemeine Dinge drin stehen, z.B. wie man ohne irgendeine IDE und egal unter welchem OS ein lauffähiges Programm erstellt, wofür der Startup-Code gut ist und warum man ein Linker-Script benötigt. Man muss das Linker-Script ja nicht einmal selber schreiben, nur wissen warum man es braucht und das es mit dem Startup-Code eng verbandelt ist. Außerdem noch wie man dieses Programm dann mittels irgendeinem GDB-Server (OpenOCD, JLink, etc.) und irgendeinem Hardware-Debugger (ST-Link, JLink, etc.) auf seinen Controller bekommt (ebenfalls ohne IDE). Das grundsätzliche Prozedere ist doch bei allen Cortexen gleich und wenn man einen kennt, kennt man alle. Darauf aufbauend kann man sich dann mit der eigentlichen Hardware beschäftigen. Ob das dann ein STM32, NRF51 oder ein LPC wird muss dann jeder für sich selber wissen bzw. nach seinen Anforderungen oder Neigungen entscheiden. Für ein einfaches Blinky sollte jedenfalls jeweils der CMSIS-Header und ein kurzer Blick ins Handbuch reichen. Wer möchte kann natürlich auch irgendwelche Libraries nutzen. Vom Ansatz her gefällt mir das im Beitrag "Artikel LPC-Tutorial: Kritik und Anregungen" erwähnte LPC-Tutorial sehr gut und ich werde mal versuchen den Autor zu kontaktieren damit man eventuell gemeinsam so etwas entwickeln kann. Grundlagen für Cortex-M gleich und darauf aufbauend Tutorials über die spezifische Hardware von LPC, STM32, usw. Es gab mal eine Zeit da war es wirklich schwierig allein eine funktionierende Toolchain für einen ARM zu bekommen. Die Zeiten sind jedoch glücklicherweise vorbei und man kann sich für jedes OS einen funktionierenden GCC bei https://launchpad.net/gcc-arm-embedded herunterladen. OpenOCD kennt so gut wie jeden Hardware-Debugger und falls nicht gibt es ja noch den J-Link und in der EDU-Version echt bezahlbar. Das waren mal wirkliche Hürden für einen Einstieg in ARM. Das was es heute (meiner Meinung nach) so unglaublich kompliziert macht ist der unglaubliche Wust an IDEs und Libraries. Die meisten Leute sehen da (verständlicherweise) den Wald vor lauter Bäumen nicht mehr. Bei dem AVR-GCC-Tutorial hingegen hat man sich noch auf das wesentliche konzentriert, weshalb der AVR deutlich weniger komplex erscheint. Ja, man muss bei den STM32 zusätzlich jeden Pin erstmal konkret als Ausgang konfigurieren damit eine LED zuckt und ja, dass Reference Manual ist viel Umfangreicher als bei einem ATMega aber man sollte sich von der Anzahl der Möglichkeiten nicht abschrecken lassen. Man muss ja nicht alles nutzen. Die Möglichkeiten zu haben finde ich dagegen sehr nett und auch wenn es vielleicht insgesamt einen ticken komplizierter sein sollte ist es der Zugewinn an Möglichkeiten allemal wert. Stefan U. schrieb: > Ich muss schon zustimmen, dass man bei ARM Controllern etwas mehr fürs > gleiche Geld bekommt. Aber es ist IMHO nicht so viel mehr, wie hier > meistens gesagt wird. Neben dem bereits erwähnten DMA finde ich z.B. die Möglichkeit ohne großes Brimborium debuggen zu können schon durchaus einen echten Mehrwert und eine FPU kann durchaus auch sehr wertvoll sein. Stellt man seinen Code von Festkomma auf Gleitkommaarithmetik um wird der eventuell viel einfacher, auch wenn die Hardware vielleicht etwas komplexer wird.
Wenn ich dieses Thread sehe, dann komme mir der Gedanke, dass hier jeden Tag der 1. April ist - außer gestern natürlich.
Wie ich sehe, ist der übliche emotionsgeladene Sturm wieder ausgebrochen. Das hat schon fast religiöse Züge hier. Aber was meckere ich, ich hatte es ja erwartet. Ihr dürft mich jetzt Troll nennen, ich hätte meine Klappe halten sollen. > Da liegt es wohl eher an der mitgelieferten > Entwicklungsumgebung, dass man 3 Tage braucht. Nein, eher daran, dass ich mir die falschen Tutorials herausgesucht habe. Die SW4STM32 IDE funktionierte out-of-the Box. Die wollte ich aber anfangs nicht verwenden, weil sie nur STM32 unterstützt und mit einem Registrierungs-Zwang verbunden ist. Aber ich verwende sie jetzt doch. Sie basiert auf dem gcc, der ja auch alle (?) anderen ARM Controller unterstützt. Und mit dem gcc bin ich schon lange vertraut. Eclipse ist nicht mein Favorit, aber ich kann mich mit ihr auch anfreunden. Jedenfalls ging ein Tag schon auf Vergleich und Auswahl der Software. > Du vergleichst hier einen (mindestens) 64-Pinner mit > komplexer Peripherie mit einem simplen AVR. Ich vergleiche einen 48 Pin ARM mit einem 32 Pin AVR. Beide gibt es auch in größer, das ist mir bewusst. > zum anderen hat der Controller Prefetchbuffer, die einiges abfangen. Ich habe noch nicht herausgefunden, welche Programme/Befehle von dem Buffer profitieren. Mein erster LED Blinker läuft jedenfalls effektiv nur mit 24Mhz, obwohl der Systemtakt 72Mhz ist und die Buffer aktiviert sind. Ich vermute, dass es auf die konkreten Operationen ankommt, die man verwendet. > Alleine der DMA ist den Sprung schon wert. Das ist für mich auf jeden Fall ein interessantes Thema. Meine letzte Erfahrung mit DMA stammt aus den 90er Jahren, als ich Soundkarten und Disketten-Controller unter DOS programmierte. Bei µC ist mir der Nutzen noch nicht so klar, aber das wird sicher kommen, sobald ich es mal ausprobiere. Deswegen beschäftige ich mich ja jetzt mit ARM, obwohl ich keine konkrete Anwendung habe. Ich will lernen, was die tolles können. >> Entweder habe ich mich saublöde angestellt, oder >> ich habe Recht (das ARM viel Komplexer sind). > Es ist Ersteres, glaub mir... Mag sein. Mein LED Blinkprogramm enthält auf dem ARM jedenfalls nur wenige Zeilen mehr als bei AVR (weil ich keinen delay_ms() Befehl gefunden habe. Aber egal, in ernsthaften Anwendungen sind solche Delays ohnehin nur sehr begrenzt nützlich. > Wie lange hast Du Dich zuvor mit den diversen AVRs beschäftigt? Ca 10 Jahre. > Wieso maßt Du Dir also nach ein paar Tagen Spielerei mit einem STM32 > ein Urteil an? Hmm, das sollte kein Urteil sein. Ich wollte nur meine Meinung als Anfänger kundtun. Mir kommen sie komplizierter vor. Andere Meinungen sind ebenfalls willkommen. > Bei trivialen Programmen zählt auch die Größe der LibC und der > Intialisierungen Die habe ich nicht mitgezählt. ich habe sogar ins Assembler Listing geschaut. > LOL. Ich sage nur: Fuses. Ja schön, die habe ich auch als Knackpunkt genannt. Allerdings kann ich Dich beruhigen, ich habe in 10 Jahren nur zwei Chips verfused. Aus Fehlern lernt man. > auf einem Nordicsemi NRF51 z.B. muss man zum LED Leuchten nur > den GPIO auf Output und High (oder Low) setzen, fertich. Das ist bei STM32F1 nicht anders. >> Aber meine Programme sind auch locker doppelt so groß. > Lass mich raten: Du hast den STMCube oder die > Standard Peripheral Libray benutzt? Nein, ich bin zwar noch Anfänger in Sachen STM32, aber so blöde nun doch nicht. Ich habe ein Programm dass nur Definitionen verwendet verglichen. Keine HAL, keine Library. Und die Größe der Initialisierungsroutine habe ich nicht mitgezählt. > Arbeite mal an einem großen Projekt damit, > dann wirst du's verstehen! Mach ich. >> Laut Marketing Geschwätz erhalte ich 72 Mhz, aber effektiv kommen da >> wegen der nötigen Waitstates nur 24 Mhz heraus - was kaum mehr ist, als >> meine geliebten AVR's können. > Das stimmt schon mal nicht. Was sagst du zu folgender Schleife?:
1 | for (uint32_t j=0; j<6000000; j++) |
2 | {
|
3 | asm volatile ("nop"); |
4 | }
|
Bei 8Mhz dauert diese Schleife 3 Sekunden. Bie 64Mhz dauert sie 1 Sekunde. Also läuft dieser Programmteil nur 3x schneller, obwohl die Taktfrequenz 8x so hoch ist. > du kannst Code in den RAM auslagern, dann läuft der > auch mit 72Mhz ohne Wait-States. Vielen Dank für diesen hilfreichen Tip! > Hier mal ein kleiner Benchmark Sorry, aber Benchmarks sind nur hilfreich, wenn sie dem konkreten Anwendungsfall entsprechen. Zu meiner delay Schleife passt er jedenfalls nicht. > ok, dafür frisst der SUV halt ne Kleinigkeit mehr Ich hatte die Stromaufnahme vom ATmega328P mit dem STM32F103RB verglichen. Der scheint bei gleicher Taktfrequenz nicht nennenswert mehr zu "fressen". > Äpfel und Birnen, aber immerhin, ein Vergleich. Genau. Beide Früchte sind Ok. > Bei 4-facher Taktrate darf ich doch davon ausgehen, daß die 4-fache > Menge an Befehlen durchgespult werden kann, trotz schrumpelig und so. Willkommen im Club der irregeführten. Dem ist nämlich nicht so, weil der Flash Speicher maximal 24Mhz schafft (jedenfalls beim STM32F1). > Daß 32bit viel cooler als die 8bit sind, ist aber hier egal, oder? Das ist mir wirklich völlig egal. Denn auch meine ollen AVR's können in C alle Operationen bis 64bit wie vom PC gewohnt ausführen. Es dauert dann halt ein paar Takte mehr. > Korrektur vom Eingangspost. Da schreibt einer > Sch... und das muss nicht sein. Du hast Recht, falsche Annahmen sollte man korrigieren. Deswegen mag ich dieses Forum hier ja auch. Hier lässt man niemanden dumm sterben. > Dein AVR liest 8 Bit und der Arm mindestens 32 Bit gleichzeitig AVR's lesen 16bit Gleichzeitig, aber egal, deine Aussage bleibt trotzdem richtig. > Eclipse war ein Monster, das auf meinem Quadcore extrem träge war Mein letzter Laptop war ein Dual-Core Pentium M 1,3Ghz. Der reichte für alle Sachen prima aus, nur nicht für größere Eclipse Prohekte in Java. Jetzt habe ich einen neuenQuad Core, der schafft das. Das ist übrigens einer der Gründe, weswegen ich zuerst Netbeans versucht habe. Aber da habe ich weiderholt den Debugger nicht als Laufen bekommen. An nder Kommandozeile lief er, aber in der IDE nicht. Das selbe Problem hatte ich schon vor ein paar Jahren mit AVR's. Die Eclipse basierte Umgebung SW4STM32 hatte jedoch gleich auf Anhieb funktioniert. So ungerne ich Eclipse verwende und eine IDE, die nur STM32 kann - das ist dennoch ein dickes Plus. Wenn ich aus dem Anfänger Stadium heraus bin, werde ich es nochmal mit Netbeans versuchen.
Stefan U. schrieb: > Nein, eher daran, dass ich mir die falschen Tutorials herausgesucht > habe. Die SW4STM32 IDE funktionierte out-of-the Box. Die wollte ich aber > anfangs nicht verwenden, weil sie nur STM32 unterstützt und mit einem > Registrierungs-Zwang verbunden ist. Genau, da du dich mit avr studio nicht bindest und den avr jeden x-beliebigen Herstellers programmieren kannst. :-( Stefan U. schrieb: > Ihr dürft mich jetzt Troll nennen Ja, du bist ein Troll!
Rufus Τ. F. schrieb: > Willst Du trollen? Lies deinen Beitrag noch einmal. Wer von uns ist wohl hier der Troll?
Gerhard O. schrieb: > Für reine Steueraufgaben ohne nennenswerte > Fließkommarechnungsnotwendigkeit reichen die meisten 8-Bitter allemal. Reichen ja, aber warum den 10 Jahre alten Polo nehmen, wenn es fürs gleiche Geld einen neuen Passat gibt. Mehr Komfort, mehr Leistung bei gleichem Verbrauch. Warum willst du dich selbst quälen? ;-)
Gerhard O. schrieb: > zurück zu >> Atollic gehen werde oder mit dem alten Coocox 1.7 weitermache. > > Atollic ist wieder frei Ja, deswegen hatte ich auch überlegt, dann wieder zurück zu Atollic zu gehen, war damals angenehm, man musste nur einen Stub (wimre war das die ELF->HEX Umwandlung) durch was richtiges ersetzen, dann klappte alles. Allerdings ist man dann erstmal wieder auf STM32 begrenzt und die Betty mit ihrem alten LPC2200 bleibt aussen vor. Aber das ist nicht tragisch.
Cortex schrieb: > Gerhard O. schrieb: >> Für reine Steueraufgaben ohne nennenswerte >> Fließkommarechnungsnotwendigkeit reichen die meisten 8-Bitter allemal. > > Reichen ja, aber warum den 10 Jahre alten Polo nehmen, wenn es fürs > gleiche Geld einen neuen Passat gibt. Mehr Komfort, mehr Leistung bei > gleichem Verbrauch. Warum willst du dich selbst quälen? ;-) Kommt auf die Umstände an. In der Firma nehmen wir für die meisten Steueraufgaben nur noch ARM/CORTEX. Wenn man effizient sein will, ist es besser einen uC wirklich gut zu kennen anstatt Vieles nur mittelmäßig. Wenn man einen ARM gut kennt kommt man auch mit den Paralleltypen gut zurecht. Das Debuggen ist mit JTAG viel besser und geht schneller. Im Hobbybereich verwende ich immer noch gerne 8-Bitter: weil ich gerne damit arbeite weil ich vielen alten Code wiederverwenden kann und viele Projekte somit in kürzester Zeit aus dem Boden gestampft werden können weil vieles schon Jahre an Zuverlässigkeit bewiesen hat. weil meine Bastelkiste noch voll mit AVRs,PICs, AT89LP51 ist. weil ich gerne meine eigenen Platinen fertige und dann lieber mit THT arbeite weil ich manchmal lieber mit 5V arbeiten will weil ich mit den Tools gut zurechtkomme Ist halt Geschmackssache. Neuere Selbstbauprojekte mache ich heutzutage, wenn angebracht, auch mit ARM. Speziell, wenn viel Rechenarbeit angesagt ist, da tut man sich mit 32-bit viel weniger an.
@Gerhard O. Im ersten Post gibg es mal wieder darum, Einsteigern den ARM madig zu machen. Unter dem Gesichtspunkt betrachte ich deinen post. Gerhard O. schrieb: > weil ich gerne damit arbeite das hilft dem Einsteiger aber sehr. ;-( > weil ich vielen alten Code wiederverwenden kann und viele Projekte somit > in kürzester Zeit aus dem Boden gestampft werden können weil vieles > schon Jahre an Zuverlässigkeit bewiesen hat. auch wichtig für Einsteiger. ;-( > weil meine Bastelkiste noch voll mit AVRs,PICs, AT89LP51 ist. der Einsteiger hat eine leere Kiste. ;-( > weil ich gerne meine eigenen Platinen fertige und dann lieber mit THT > arbeite ich, ich, ich, ... und wo bleibt der Einsteiger? ;-( > weil ich manchmal lieber mit 5V arbeiten will du machst bestimmt noch andere Dinge gern, die andere aber ablehnen. ;-) > weil ich mit den Tools gut zurechtkomme mit meinem C64 kam ich auch sehr gut zurecht, nutze ich ihn heute noch? ;-(
Stefan U. schrieb: > So ungerne ich Eclipse verwende und eine IDE, die nur > STM32 kann Stimmt so nicht. Man kann SW4STM genau wie jedes Plugin in Eclipse zusätzlich installieren. Ich nutz mein Eclipse für AVR, RPi, STM32, Linux, php, bash.....etc.
An dem Punkt wo du 3 Tage für das erste Programm brauchst war doch schon alles gelaufen, entweder ist das ST Zeugs totaler Müll oder du hast gerade dein 2tes Programm geschrieben. Ich persönlich nehme für kleine Sachen das TIVA C Series Launchpad, kostet 12€ hat en Debugger darauf und hat einfach gute Librarys und jede Menge Beispiel Programme an Board.
Beitrag #4960755 wurde vom Autor gelöscht.
> Genau, da du dich mit avr studio nicht bindest Ich habe nicht geschrieben, dass ich AVR Studio verwende. Tue ich übrigens auch nicht.
PittyJ schrieb: > Warum hier alle auf STM stehen, kann ich nicht nachvollziehen. Ich fand > deren Tools am kompliziertesten von allen bisher ausprobierten. Ja, auch andere haben schöne 32-Bit-Controller. Wie Atmel, Microchip, NXP, Freescale (schon wieder NXP), Silabs, Cypress. Warum sich alle ausgerechnet zwanghaft den STM32 antun, ist mir so auch nicht eingängig. Das ist wieder mal Hype und sonst nichts. Für mich sind die Peripheral-Lib oder Cube-MX ein KO-Kriterium für die STM32.
> Warum sich alle ausgerechnet zwanghaft den STM32 antun, Man bekommt sie so billig: http://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino-/201529768817
Markus schrieb: >> Warum sich alle ausgerechnet zwanghaft den STM32 antun, > > Man bekommt sie so billig: > Ebay-Artikel Nr. 201529768817 So teuer sind die anderen auch nicht: http://www.ebay.de/itm/CYPRESS-CY8CKIT-145-40XX-PSoC-4000S-Prototyping-Kit-/182492911882?hash=item2a7d6cd90a:g:cLcAAOSw4A5Yy-jv http://www.ebay.de/itm/NXP-LPC1343-QuickStart-Board-Embedded-Artists-Art-No-EA-QSB-012-Cortex-M3-/292074161488?hash=item4400fa0550:g:nxoAAOSw7s5XhM5B Wer um 10€ zu sparen mit CubeMX herumtut, der tut mir leid. Für den Preis eines Mittagessens quäle ich mich nicht Jahrelang mit Cube-MX herum. Wer es trotzdem tut, hat keinerlei Wertschätzung für seine eigene Arbeitszeit...
> Warum sich alle ausgerechnet zwanghaft den STM32 antun Ich tue es mir freiwillig an, weil a) die Evaluation Kits mitsamt Debugger sehr preisgünstig sind b) ich die Chips als Endverbraucher bei Conrad und Reichelt kaufen kann c) ich einige STM Controller auf Breakout Board kaufen kann (für Steckbrett und Lochraster) Sicher gibt es auch andere Controller, die diese Anforderungen erfüllen. Zu STM32 habe ich schneller Infos und Empfehlungen gefunden, deswegen maxchen die nun bei mir das Rennen. Irgendwo hat jeder Controller seine Macken oder ungünstiges Design. Es steht Dir frei, deinen eige Markus-Architektur zu entwicklen. Bis dahin nehme ich, was schon verfügbar ist. > Wer um 10€ zu sparen mit CubeMX herumtut, der tut mir leid. STM32 kann man auch ohne CubeMX benutzen, und das ist nicht einmal sonderlich schwierig, nachdem man das mittelmäßig komplexe CLOCK System verstanden hat.
Mampf schrieb: > Das ist wieder mal Hype und sonst nichts. Für mich sind > die Peripheral-Lib oder Cube-MX ein KO-Kriterium für die STM32. Ja, finde ich auch ... Aber ich verwende gerne irgendwas, das /alle anderen/ auch verwenden, da ist dann der Support einfacher^^
> Für mich sind die Peripheral-Lib oder Cube-MX > ein KO-Kriterium für die STM32. Du musst sie ja nicht benutzen, so wie du bei AVR auf Arduino verzichten darfst.
Stefan U. schrieb: >> Für mich sind die Peripheral-Lib oder Cube-MX >> ein KO-Kriterium für die STM32. > > Du musst sie ja nicht benutzen, so wie du bei AVR auf Arduino verzichten > darfst. Man kann die STM32 bare-metal programmieren, stimmt. Dazu wie geschaffen sind sie aber nicht wirklich. Spätestens wenn man I2C mit DMA, Ethernet oder USB braucht, macht das keinen Spass mehr. Die Sache mit Cube und der Peripheral Lib ist FÜR MICH ein KO, das heißt nicht, dass andere das nicht anders sehen dürfen :-) Ist aber Offtopic. Ich wollte ohnehin nur drauf hinweisen, dass es viel schönere Bastelprozessoren gibt als STM32. Beispielsweise die PSOCs, die so schön flexibel sind.
Mampf schrieb: > Warum sich alle ausgerechnet zwanghaft den STM32 antun, ist mir so auch > nicht eingängig. Die "Maker"-Karawane ist weitergezogen, STM32 ist jezt der neue ATmega8, Cube/HAL ist das neue Arduino.
Markus M. schrieb: > Oh wieder mal eine ARM/AVR Diskussion. Da muss ich auch gleich noch > meinen Senf dazu geben... > > Senf! Viel zu teuer! Der muß aus China kommen und darf höchstens 5 ct das Glas kosten. Für den Start mit einem neuen µC hole ich mir zumeist eine Kickstart-Version von IAR. Da hat man für diverse µCs immer die gleiche IDE. Die Code-Beschänkung der Demoversion stört dabei überhaupt nicht. Damit kann man schon Einiges machen. Der Start ist sehr einfach und z.B. die Funktion "live-watch" beim ARM sorgt für hohe Transparenz beim Kennenlernen.
Christopher J. schrieb: > Neben dem bereits erwähnten DMA Dazu wäre noch zu erwähnen, daß DMA durchaus kein ARM-Privileg ist (haben die AVR-Xmegas auch). Als großen Vorteil der vielen einfachen AVRs wiederum empfinde ich ihre bis 5V Tauglichkeit. Damit ist man doch gleich um Welten flexibler (ja ich weiß, gibts vereinzelt bei ARM auch).
Um Irritation zu vermeiden: Xmega vertragen maximal 3,6V VCC und auch an den I/O Pins.
Beitrag #4960928 wurde von einem Moderator gelöscht.
Lars schrieb im Beitrag #4960928: > Naja eine ganze Stunde schon für ein simples "Hallo Welt" ist jetzt > keine Empfehlung. > > Sich als Anfänger [...] Wie lange braucht ein Anfänger auf einem AVR für ein "Hallo Welt"?
1 | AVR: |
2 | <------------ ausreichend C lernen, Tools, IDE, Debugger -------------><- µC generell verstehen -><- AVR verstehen -> |
3 | ARM: |
4 | <------------ ausreichend C lernen, Tools, IDE, Debugger -------------><- µC generell verstehen -><------ ARM verstehen ------> |
Ich seh da jetzt nicht so den dramatischen Unterschied.
Beitrag #4960968 wurde von einem Moderator gelöscht.
Beitrag #4960978 wurde von einem Moderator gelöscht.
Stefan U. schrieb: > Also läuft dieser Programmteil nur 3x schneller, obwohl die > Taktfrequenz 8x so hoch ist. Das zeigt nur, dass in der eingerichteten Konfiguration der AVR relativ zu seiner Taktfrequenz schneller springt, weil er langsamer taktet. Da die STM32F1xx bei Flash-Zugriffen zwar einfaches Prefetching durchführen, aber kein Caching, hängt das direkt mit den Waitstates vom Flash zusammen. Takte den STM32 soweit runter, bis er keine Waitstates mehr benötigt, und er wird pro Takt schneller. ;-)
:
Bearbeitet durch User
> Ich seh da jetzt nicht so den dramatischen Unterschied. Mehr Lesestoff, und ich hatte mehr Zeitaufwand bei der Auswahl der Arbeitsmittel (Software). Das C Programm ist quasi identisch, da stime ich Dir zu. > einfaches Prefetching durchführen, aber kein Caching, > hängt das direkt mit den Waitstates vom Flash zusammen. Das habe ich an dieser delay Schleife auch erkannt. Das Prefetching ist an dieser Stelle vollkommen nutzlos. An anderen Stellen wird es helfen, sonst hätte man dieses Feature nicht eingebaut.
Mampf schrieb: > Stefan U. schrieb: >>> Für mich sind die Peripheral-Lib oder Cube-MX >>> ein KO-Kriterium für die STM32. >> >> Du musst sie ja nicht benutzen, so wie du bei AVR auf Arduino verzichten >> darfst. > > Man kann die STM32 bare-metal programmieren, stimmt. > Dazu wie geschaffen sind sie aber nicht wirklich. Diese Aussage ergibt überhaupt keinen Sinn. Wie sollte deiner Meinung nach ein µC denn aussehen, um "wirklich dafür geschaffen zu sein" bare-matal programmiert zu werden? > Spätestens wenn man I2C mit DMA, Ethernet oder USB braucht, macht das > keinen Spass mehr. Auch das ist Unsinn. Was man will, ist Abstraktion. Daß ST es nicht hinbekommt, benutzbare Abstraktionslayer für ihre Chips auszuliefern, heißt ja nicht daß es niemand hinbekommt. Und ganz besonders heißt das nicht, daß du keinen dir genehmen Abstraktionslayer bauen könntest. > Die Sache mit Cube und der Peripheral Lib ist FÜR MICH ein KO Es gibt 3rd Party Abstraktionslayer, die nicht nur schöner als SPL und HAL sind, sondern sogar plattformübergreifend funktionieren. Ich mag bspw. libopencm3.
Beitrag #4961021 wurde von einem Moderator gelöscht.
Stefan U. schrieb: >> Bei 4-facher Taktrate darf ich doch davon ausgehen, daß die 4-fache >> Menge an Befehlen durchgespult werden kann, trotz schrumpelig und so. > > Willkommen im Club der irregeführten. Dem ist nämlich nicht so, weil der > Flash Speicher maximal 24Mhz schafft (jedenfalls beim STM32F1). Das Flash-Interface der STM32F1 ist sehr einfach und schmalbandig gestrickt, Flash-Waitstates schlagen bei nichtsequentiellem Code voll durch. Bei sequentiellem Code sieht es deutlich besser aus, kann aber bei ausgiebiger Verwendung von mit 32 Bits codierten Befehlen ebenfalls etwa verhungern. Das Problem mit Flash-Waitstates teilen viele Microcontroller, wenn deren Taktfrequenz höher als das Tempo der verwendeten Flash-Technologie ist. Weshalb da mitunter auch etwas mehr Aufwand getrieben wird als bei den recht einfachen STM32F1, beispielsweise um ein paar Schleifenanfänge puffern zu können.
>Bei sequentiellem Code sieht es deutlich besser aus, kann aber >bei ausgiebiger Verwendung von mit 32 Bits codierten Befehlen ebenfalls >etwa verhungern. https://de.wikipedia.org/wiki/ARM_Cortex-M3 : "Zum Laden eines Befehls werden nur 16 Bit benötigt, das Speicherinterface ist aber 32 Bit breit, und es werden immer zwei Befehle gleichzeitig geladen (fetch). Ein Befehl wird jeweils zwischengespeichert" Wäre das nicht 72Mhz / 3Waitstates * 2 ?
Beitrag #4961033 wurde von einem Moderator gelöscht.
Axel S. schrieb: > Diese Aussage ergibt überhaupt keinen Sinn. Wie sollte deiner Meinung > nach ein µC denn aussehen, um "wirklich dafür geschaffen zu sein" > bare-matal programmiert zu werden? Eine harte Grenze gibts da nicht. Wenn man ohne weitere Abstraktion (wie du so schön geschrieben hast) arbeiten will, dann wird es halt ab einer bestimmten Komplexität wenig praktikabel. Und das ist bei vielen STM32 schon zumindest schon teilweise so. Ich habs probiert, sowohl mit Peripheral Lib als auch ohne. Warm geworden bin ich persönlich (!!!) damit nicht. Axel S. schrieb: > Auch das ist Unsinn. Was man will, ist Abstraktion. Daß ST es nicht > hinbekommt, benutzbare Abstraktionslayer für ihre Chips auszuliefern, > heißt ja nicht daß es niemand hinbekommt. Und ganz besonders heißt das > nicht, daß du keinen dir genehmen Abstraktionslayer bauen könntest. Ich glaube, wir reden vom selben Thema. Man KANN sich ein solches Abstraktionslayer bauen, aber mal ehrlich, wer will das schon in seiner Freizeit machen? Für den Professionellen Einsatz ist das anders. Axel S. schrieb: > Es gibt 3rd Party Abstraktionslayer, die nicht nur schöner als SPL und > HAL sind, sondern sogar plattformübergreifend funktionieren. Ich mag > bspw. libopencm3. Danke für den Tipp. Das könnte einen Blick wert sein.
Axel S. schrieb: > Ich mag > bspw. libopencm3. Danke für den Tipp! A. K. schrieb: > Das Problem mit Flash-Waitstates teilen viele Microcontroller, wenn > deren Taktfrequenz höher als das Tempo der verwendeten Flash-Technologie > ist. Man kann ja Code, der performant und ohne Wait-States laufen soll per
1 | __attribute__( ( section(".data") ) ) |
ins RAM auslagern :)
Mampf F. schrieb: > A. K. schrieb: >> Das Problem mit Flash-Waitstates teilen viele Microcontroller, wenn >> deren Taktfrequenz höher als das Tempo der verwendeten Flash-Technologie >> ist. > > Man kann ja Code, der performant und ohne Wait-States laufen soll per > __attribute__( ( section(".data") ) ) > > ins RAM auslagern :) Oder gleich in den Core-Coupled-Memory (CCM), falls der Chip sowas hat. Das ist einer der Hauptnachteile von AVR: Er kann nur In-Place Execution. Das ist bei den aktuellen STM32 besser gelöst. Auch das Gejammere "der Chip braucht aber 2 Wait-States bei 72 MHz" ist zu kurz gegriffen. Hier muss man sich gedanklich vom "simplen" AVR trennen. Bei STM32 gibt es prefetch buffer und ggf. auch caches. Effektiv ist es sogar nochmal ein Stück besser, da der Flash üblicherweise 32 Bit breit angesprochen wird, die meisten ARM Thumb instructions aber nur 16 bit Breite haben. => Pro Fetch zwei Instructions. Zahlreiche Befehle sind auch nicht single-instruction sondern brauchen 2 oder mehr Zyklen (ähnlich wie bei AVR beispielsweise load und store). D.h. dass nicht zwingend der Flash hierbei der Flaschenhals ist. Falls doch: Code mit großem Performancebedarf kommt bei mir in den RAM/CCM. Allgemein bin ich privat und in der Arbeit von AVR auf ARM umgestiegen. Schon gegen einen STM32F0 wirkt jeder AVR eher wie Spielzeug... Das Gehampel mit 8 bit breiten Registern und winzigem 16 bit Adressbereich... (ja es gibt Anwendungen für Microcontroller wo man auch mal 128kByte adressieren will.) Da hab ich lieber FPU, 32-bit Register, 32-bit Adressen auf nem ARM. AVR haben schon noch hier und da ihre Daseinsberechtigung. Primär setze ich aktuell aber auf STM32 bzw. ARM und komme damit besser zurecht. Und um nochmal Öl ins Feuer zu gießen, meine Anwendungen sind: - Ohne HAL/Cube/etc. - Bare Metal :-) (also kein Arduino-ähnliches Gefrickel sondern anständige Entwicklung)
chris schrieb: > "Zum Laden eines Befehls werden nur 16 Bit benötigt, Bei den Cortex M3 sind Befehle nicht selten 2 Halbworte lang.
Axel S. schrieb: > Es gibt 3rd Party Abstraktionslayer, die nicht nur schöner als SPL und > HAL sind, sondern sogar plattformübergreifend funktionieren. Ich mag > bspw. libopencm3. Habe ich mir gerade mal angeguckt .... Ob man jetzt Parameter einzeln an eine Funktion übergibt oder wie die HAL in Strukturen verpackt ... über Schönheit kann man trefflich streiten ;-) Und die STM32F4 RCC Funktionen passen für den F446 überhaupt nicht. Eine Herstellerunabhängige (lowlevel) Abstraktionsschicht halte ich für utopisch und auch nicht unbedingt für wünschenswert. Da reicht mir die CMSIS. Eine Abstraktionsschicht müsste auf Anwendungsebene sein. Ich habe Arm7, 9 Erfahrung, in der CortexM Ecke bin ich neu und verwende CubeMx und die HAL zum hineinschnuppern. Aber langfristig werde ich C++ und Templates verwenden.
meckerziege schrieb: > Oder gleich in den Core-Coupled-Memory (CCM), falls der Chip sowas hat. Hatten wir gerade: zumindest der STM32 kann daraus keinen Code ausführen. Musste ich mich auch eines besseren belehren lassen. So schön RAM-Funktionen ansonsten sind, sie schlucken natürlich von der Ressource, die typischerweise bei einem Controller am ehesten zur Neige geht. Insofern sind sie kein Universal-Totschlagargument dagegen, dass der Flash eben doch nur einen Bruchteil der Taktfrequenz schafft, die der Core kann. Dafür braucht natürlich die höhere Taktfrequenz auch dann Strom, wenn der Prozessor gerade in Waitstates vor sich hin idlet. (Prinzipiell wäre es auch beim AVR kein Thema gewesen, den Core selbst schneller auszulegen, aber da er ohnehin nur aus dem Flash und nicht aus dem RAM ausführen kann, wäre es dort gänzlich unsinnig.) meckerziege schrieb: > wo man auch mal 128kByte adressieren will.) 128 KiB gehen beim AVR noch, da er den Code wortweise adressiert und man bei einem 128er Controller selten mehr als die Hälfte davon für Daten benötigt, aber jenseits der 128 KiB ist es wirklich lästig, einem AVR das abzuquälen. > Da hab ich lieber FPU Naja, die findest du aber beim Cortex-M auch eher am oberen Ende der Fahnenstange, und selbst dann ist sie leider nur 32bittig. Sie im gleichen Absatz wie einen STM32F0 aufzuführen, vermischt schon einiges.
Jörg W. schrieb: > meckerziege schrieb: >> Oder gleich in den Core-Coupled-Memory (CCM), falls der Chip sowas hat. > > Hatten wir gerade: zumindest der STM32 kann daraus keinen Code > ausführen. Musste ich mich auch eines besseren belehren lassen. > > Naja, die findest du aber beim Cortex-M auch eher am oberen Ende der > Fahnenstange, und selbst dann ist sie leider nur 32bittig. Sie im > gleichen Absatz wie einen STM32F0 aufzuführen, vermischt schon einiges. Man darf hier nicht alle STM32 über einen Kamm scheren. Es gibt schon Exemplare, bei denen ein Teil oder gar das ganze SRAM am Instruction-Bus hängt. Leider ist die Namensgebung hier sehr verwirrend, da es meines Wissens nach sogar in ein und der selben Familie (z.B. STM32F4) Chips gibt die eine entpsrechende Bus-Anbindung haben... und welche dies eben nicht haben. Und die FPU gibts mittlerweile auch auf Double-Breite...
Vincent H. schrieb: > Man darf hier nicht alle STM32 über einen Kamm scheren. Es gibt schon > Exemplare, bei denen ein Teil oder gar das ganze SRAM am Instruction-Bus > hängt. Es ging nicht um SRAM allgemein, sondern um CCM. Der hängt eben nur am D-Bus des Cores. > Und die FPU gibts mittlerweile auch auf Double-Breite... OK, sind mir leider noch nicht übern Weg gelaufen. Allerdings bräuchte man dann sinnvollerweise auch die CMSIS-DSP-Lib für 64 Bit.
@Mampf F. > Man kann ja Code, der performant und ohne Wait-States laufen soll per > ... ins RAM auslagern :) Danke, du hast mir gerade einen Punkt aus meiner TODO Liste abgenommen. Jetzt weiss ich, wie man das macht. Ob ich's benutzen werde...mal sehen.
Jörg W. schrieb: > Vincent H. schrieb: > >> Man darf hier nicht alle STM32 über einen Kamm scheren. Es gibt schon >> Exemplare, bei denen ein Teil oder gar das ganze SRAM am Instruction-Bus >> hängt. > > Es ging nicht um SRAM allgemein, sondern um CCM. Hier für einen STM32F303 und dessen Derivate: http://www.st.com/content/ccc/resource/technical/document/application_note/bb/09/ca/83/14/e9/44/c5/DM00083249.pdf/files/DM00083249.pdf/jcr:content/translations/en.DM00083249.pdf "Executing a simple code from CCM RAM"
Angehängte Dateien:
-
stm32f1x-busmatrix.png
40 KB
Vincent H. schrieb: > Hier für einen STM32F303 und dessen Derivate: Tja, dann wird die Sache einfach noch unübersichtlicher: offenbar kocht da jeder STM32 sein eigenes Süppchen. Die Bustmatrix bei STM32F41xx und STM32F42xx zeigt den CCM wirklich direkt am Core (nur so hat der Name ja auch wirklich Sinn), und dann eben nur am D-Bus, siehe Bild. Ist der 303 vielleicht neuer? Eventuell hat man ja da erkannt, dass es sinnvoll ist, ihn auch für den I-Bus zur Verfügung zu haben.
Hallo, ich kann nur aus meiner subjektiven Sicht heraus berichten, da ich ebenfalls von AVR nach Cortex M3 umgestiegen bin. Ich muss sagen, dass dazwischen schon Welten liegen. Ich habe für einen Quadrokopter das Design von AVR nach stm32F103 portiert. Mit dem AVR musste ich teilweise Handstände machen, weil die Division von 32bit Werten extrem langen Code im AVR erzeugt hat. Da habe ich mir dann mit Bitshift-Kniffen aushelfen müssen. Das war überhaupt kein Thema beim M3. Da konnte ich regelrecht verschwenderisch sein. Dann der ganz entscheidende Vorteil, der das M3 System wesentlich performanter machte: Die DMA. Viele Sachen laufen komplett im hintergrund, ohne das die CPU einen Finger rühren müsste. Die geschickte Anwendung von DMA erleichtert vieles wesentlich. Das ist schon richtig cool!
nips schrieb: > für einen Quadrokopter Das ist eine Anwendung, bei der ich wohl auch nicht erst über einen AVR nachdenken würde.
Jörg W. schrieb: > nips schrieb: > für einen Quadrokopter > > Das ist eine Anwendung, bei der ich wohl auch nicht erst über einen AVR > nachdenken würde. Bei den ersten Coptern damals war der AVR aber ausschließlich im Einsatz, und es ging auch ;-) schwerlich, aber es ging.
Jörg W. schrieb: > Ist der 303 vielleicht neuer? Eventuell hat man ja da erkannt, dass > es sinnvoll ist, ihn auch für den I-Bus zur Verfügung zu haben. Vielleicht meinten sie beim F4 einfach, daß das Ablegen von Code im CCM-RAM nicht wirklich sinnvoll ist, weil dort der Flash-Zugriff 128 Bit breit ist und 64 dieser 128-Lines gecached werden. Viele Grüße, Stefan
Beitrag #4961471 wurde von einem Moderator gelöscht.
Beitrag #4961487 wurde von einem Moderator gelöscht.
Beitrag #4961504 wurde von einem Moderator gelöscht.
> Leute, muß ich hier wirklich noch mal den Z80 in Erinnerung rufen, Ja damals ... Wenn Du das gleiche machst wie damals, ist auch ein Prozessor von damals ausreichend. Ich mache meistens Signalverarbeitung, digitale Filter, Soundgeneratoren. Dafür ist ein Z80 viel zu schwach und ein AVR von heute auch.
Beitrag #4961536 wurde von einem Moderator gelöscht.
ich schreib meine Programme so, dass sie auf ARMs und AVRs laufen. Der ARM ist nicht viel anders als der AVR - nur muss man halt die GPIO-Peripherie zusätzlich einschalten und die Einstellung des Taktes ist etwas komplexer, womit man sich aber nicht zwingend befassen muss. Beides ist gut. Der ARM besticht durch die Debug-Möglichkeiten, Der AVR ist mit winAVR etwas schneller programmiert. Für Aufgaben, die der AVR erledigen kann verwende ich eher den AVR als den ARM, weil es -etwas- schneller geht.
chris schrieb: > Dafür ist ein Z80 viel zu schwach und ein AVR von > heute auch. Erzähle das mal ChaN :-D Der würde müde darüber lächeln!
>Erzähle das mal ChaN :-D Der würde müde darüber lächeln! Nein, er ist ein Profi, der das Maximum aus der minimalsten Hardware heraus holt. Ich tue das auch manchmal auf den Attinys. Würde er einen ARM verwenden würde er noch mehr heraus holen. Meiner Ansicht nach ist er der perfekteste Elektroniker der Welt. Aber es bleibt auf die Art ein Hobby, den es ist was anderes ob man ein Modellflugzeug in Perfektion baut oder als Hardware einen Eurofighter zur Verfügung hat.
grundschüler schrieb: > nur muss man halt die > GPIO-Peripherie zusätzlich einschalten Und das auch nur bei manchen ARMs.
Beitrag #4961611 wurde von einem Moderator gelöscht.
Beitrag #4961615 wurde von einem Moderator gelöscht.
Beitrag #4961618 wurde von einem Moderator gelöscht.
Beitrag #4961635 wurde von einem Moderator gelöscht.
Beitrag #4961637 wurde von einem Moderator gelöscht.
Beitrag #4961640 wurde von einem Moderator gelöscht.
Beitrag #4961642 wurde von einem Moderator gelöscht.
Beitrag #4961643 wurde von einem Moderator gelöscht.
Beitrag #4961659 wurde von einem Moderator gelöscht.
Beitrag #4961668 wurde von einem Moderator gelöscht.
Beitrag #4961687 wurde von einem Moderator gelöscht.
Beitrag #4961694 wurde von einem Moderator gelöscht.
Beitrag #4961708 wurde von einem Moderator gelöscht.
Beitrag #4961710 wurde von einem Moderator gelöscht.
Es wurde wie immer schon alles gesagt. Und zwar mehrfach, mit anderen Worten usw.. Für mich bleiben die Cortex M im Vorteil (u.a. das zigtausendfach erwähnte Debugging, DMA und Code aus dem RAM ausführen). Letzteres ist die Voraussetzung für IAP (In Application Programming). Ohne dem könnte ich kein Update z.B. über CAN machen. Wobei die STM32-Reihe aber nicht mein Fall ist (ich sie aber aus Preisgründen gerade nutze). Die LPC1xxx gefallen mir da besser, da "echte" 32 bit neu geschaffen (und keine aufgebohrten 16-bitter). Besonders die hammermäßige pin switch matrix z.B. bei den LPC81x und LPC15xx ist ein moderner Traum. Der einen aber auch zur Nachlässigkeit bei der Planung führen kann (wie ABS und Airbag teilweise beim Auto...).
Beitrag #4961752 wurde von einem Moderator gelöscht.
Beitrag #4961759 wurde von einem Moderator gelöscht.
Beitrag #4961780 wurde von einem Moderator gelöscht.
Beitrag #4961782 wurde von einem Moderator gelöscht.
Beitrag #4961783 wurde von einem Moderator gelöscht.
Antoine de Saint-Exupery ist bekannt für viele seiner Sprüche. Ich habe mir angemaßt diesen Spruch auf uC hinzubiegen (was sehr viel Mühe gekostet hat) und um dieses Thema (nach Möglichkeit) zu Ende zu bringen: "Ein Elektronik Entwickler weiß letztlich dann, dass er (fast) Perfektion erreicht hat, wenn die von ihm gewählte Techniklösung alle Anforderungen seines Projekts ausreichend erfüllt ohne irgendwelche wichtige Wünsche offen zulassen und nicht mehr als notwendig (Zeit) Ressourcen verschwendet." Gerhard;-) "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away" Antoine de Saint-Exupery P.S. Ich werde Euch nicht mehr traktieren - Ich verspreche es;-)
> Code aus dem RAM ausführen). Letzteres ist > die Voraussetzung für IAP (In Application Programming). Das verstehe ich nicht. Die meisten AVR's können doch auch im laufenden Betrieb aktualisiert werden - durch die Applikation selbst. jeder Bootloader funktioniert dort so.
Beitrag #4961832 wurde von einem Moderator gelöscht.
Beitrag #4961840 wurde von einem Moderator gelöscht.
Stefan U. schrieb: >> Code aus dem RAM ausführen). Letzteres ist >> die Voraussetzung für IAP (In Application Programming). > > Das verstehe ich nicht. Die meisten AVR's können doch auch im laufenden > Betrieb aktualisiert werden - durch die Applikation selbst. jeder > Bootloader funktioniert dort so. Auch einige ARMs (oder viele? Zumindest schon der zweite der mir je in die Finger fiel) können das Flash beschreiben von einem Programm aus das ebenfalls im Flash liegt. Die Ausführung pausiert dann einfach sobald die nächste Instruktion aus dem Flash geholt werden würde, so lange bis das Schreiben beendet ist. Wenn man in einem simplen Bootloader eh nur blockierend auf das Ende des Schreibens wartet fällt das gar nicht auf. Aber man könnte natürlich mit Hilfe von Code im RAM währenddessen anderes tun, evtl sogar Interrupts wenn man die ebenfalls ins RAM schieben würde.
Beitrag #4961885 wurde von einem Moderator gelöscht.
Beitrag #4961888 wurde von einem Moderator gelöscht.
Beitrag #4961890 wurde von einem Moderator gelöscht.
Hm, ich werd mich doch nicht etwa vertun? Ein Bootloader ist doch eher ISP. Und wenn ich ein Programm aus dem Flash ausführe und ins Flash schreibe, überschreibe ich doch mein Programm und Schluß ist. So vergleichbar wie den Ast absägen, auf dem man sitzt. Ich rede jetzt nicht davon, Flash als EEPROM zu nutzen und einzelne freie sections oder pages dafür zu verwenden, sondern ein komplett neues Programm auf den Chip zu übertragen. Da müssen zumindest bei den LPC1xxx alle relevanten Funktionen aus dem RAM aufgerufen werden, um dann an z.B. 0x00000000 ins Flash zu schreiben (inkl. Vektortabelle, sofern dafür nicht die Interrupts deaktiviert wurden).
Beitrag #4961985 wurde von einem Moderator gelöscht.
Beitrag #4961987 wurde von einem Moderator gelöscht.
Beitrag #4961989 wurde von einem Moderator gelöscht.
Beitrag #4962015 wurde von einem Moderator gelöscht.
Beitrag #4962016 wurde von einem Moderator gelöscht.
Lutz schrieb: > Und wenn ich ein Programm aus dem Flash ausführe und ins Flash schreibe, > überschreibe ich doch mein Programm und Schluß ist. Natürlich darf sich das Stückchen, welches den Schreibvorgang abwickelt, nicht selbst überschreiben. Das ist ja aber auch nicht nötig. Der Teil, der das Neuschreiben durchführt, wird üblicherweise Bootloader genannt, und man reserviert dafür ein Stück Flash ganz am Anfang oder am Ende des Flash-Speichers (beim AVR ist es immer am Ende, da es dort von der Hardware so vorgegeben ist – Beschreiben des Flashs ist dort aus Sicherheitgründen nicht von überall her zugelassen). Du kannst sowieso nicht einfach den Code aus dem Flash in den RAM kopieren und dann dort ausführen – er müsste in diesem Fall speziell auf die Adressen des RAMs gelinkt worden sein. Code ist beim ARM (normalerweise) nicht positionsunabhängig.
Beitrag #4962033 wurde von einem Moderator gelöscht.
Beitrag #4962036 wurde von einem Moderator gelöscht.
Beitrag #4962047 wurde von einem Moderator gelöscht.
Beitrag #4962049 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Du kannst sowieso nicht einfach den Code aus dem Flash in den RAM > kopieren und dann dort ausführen – er müsste in diesem Fall speziell > auf die Adressen des RAMs gelinkt worden sein. Code ist beim ARM > (normalerweise) nicht positionsunabhängig. Das (zumindest...) ist mir schon klar. Bei den LPC1xxx wird das (mit LPCOpen als "HAL") mit Makros gelöst. __RAMFUNC(RAM) vor einer Funktion sorgt z.B. dafür, daß die Funktion ins RAM gelinkt wird. Und das Ganze wird natürlich im Flash gespeichert, um zur Laufzeit überhaupt ins RAM geladen werden zu können (woher soll das Programm auch sonst kommen; nur um Mißverständnissen vorzubeugen). Aber das mit dem Bootloader werde ich mir morgen noch mal (auf LPC-Basis) anschauen. Ich habe irgendwo abgespeichert, daß die Dinger beim Reset das Flash mit einer Prüfsumme "abgrasen" und entscheiden, ob ein gültigee Programm vorliegt. Wenn nicht, wird der Bootloader anhand einiger gesampelter Pins gestartet. Aber so ganz bekomme ich es gerade nicht mehr zusammen.
Robert schrieb im Beitrag #4961987: > Sich als Anfänger in die umfangreiche ARM Materie reinzuknien macht > meiner Meinung nach nur Sinn wenn... Ach nö. Wenn man erstmal mit einem 32 Bitter zu Potte gekommen ist, will man nicht wirklich mehr zurück zu 16 oder gar 8 Bittern. Von den Problemen ganz abzusehen, die eine Harvard-Architektur bei C macht wegen der Prinzip-Unterschiede zwischen Pointern auf const und nicht-const. Die Schwierigkeiten beim Einstieg, die es angeblich bei den ARM-Cortex gibt, sind im Grunde nur böse Erfahrungen mit aufgeblähten IDE's, noch aufgeblähteren Hersteller-Bibliotheken und schlecht geschriebenen Dokumentationen. An den Chips liegt es nicht, denn die Cortex-M sind dramatisch bastlerfreundlicher verstehbar als zuvor die ARM7TDMI- und ARM9-Architektur. Muß man mal wirklich so deutlich sagen. Dazu kommt allerdings noch eine auf 8 Bit Architekturen ausgerichtete Denkweise bei Umsteigern, die oft genug zu ausgesprochen "ungünstigen" Lösungen führt, gerade weil eben der Schreiber gemeint hat, etwas zur Effektivtät selber beitragen zu wollen. Richtig heftig sieht man das bei der Verwendung von LC-Displays. Alpha-Displays machen ja bei Achtbittern keine Probleme, doch schon bei kleinen Grafikdisplays hört's auf. Da fehlen den Achtbittern fast immer die Adreßräume oder schlichtweg der eingebaute RAM. Das führt dann zu Krampflösungen, die bei einem 32 Bitter einfach gegenstandslos werden. Auch Dinge wie digitale Signalverarbeitung sind für Achtbitter ne Nummer zu groß, da sollte man dann schon auf einen Cortex M4F orientieren, wenn man sich einen dedizierten DSP nicht leisten will oder kann. Kurzum: wer bereit ist, ein wenig dazu zu lernen, wird schon nach kurzer Zeit nicht wieder zurück zu Achtbittern wollen - es sei denn, die anstehende Aufgabe ist prädestiniert dazu. Das Leuchtturm-Beispiel dazu ist der Mini-Frequenzzähler mit einem PIC16Fxxx, weil diese Chips wenig Strom schlucken und eben einen dafür bestens geeigneten Asynchron-Prescaler haben, den man woanders nicht so leicht findet. W.S.
Lutz schrieb: > Ich habe irgendwo abgespeichert, daß die Dinger beim Reset das Flash mit > einer Prüfsumme "abgrasen" und entscheiden, ob ein gültigee Programm > vorliegt. In diesem Falle müsstest du wohl sicherstellen, dass du diese Prüfsumme beim Aktualisieren der Firmware korrekt mit nachziehst.
Beitrag #4962120 wurde von einem Moderator gelöscht.
Beitrag #4962123 wurde von einem Moderator gelöscht.
Beitrag #4962126 wurde von einem Moderator gelöscht.
Beitrag #4962136 wurde von einem Moderator gelöscht.
Beitrag #4962153 wurde von einem Moderator gelöscht.
Beitrag #4962164 wurde von einem Moderator gelöscht.
Obwohl der Thread wieder sehr lang geworden ist möchte ich mich bei euch für die große Menge konstruktiver Beiträge bedanken. Ihr habt falsche Annahmen meinerseits korrigiert und auf einige wichtige Sachen hingewiesen, die ich als Anfänger wissen sollte und auf die von alleine vermutlich nicht so schnell gekommen wäre. Schade finde ich, dass der Moderator mal wieder alle Hände voll zu tun hatte, unangemessene Beiträge zu löschen. Wie dem auch sei, mir war es wichtig, mich bei euch zu bedanken. Bitte hier nicht weiterdiskutieren, das Thema ist beendet.
Thread beobachten
Seitenaufteilung abschalten