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).
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 einemSTM32
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!
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.
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 ...
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
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!
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.
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...
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.
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.
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.
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_tj=0;j<6000000;j++)
2
{
3
asmvolatile("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 gleichzeitigAVR'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!
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.
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
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).
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"?
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. ;-)
> 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.
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 ?
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
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)
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.
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!
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
> 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.
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.
>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.
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...).
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.
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.
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).
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.
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.
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.
