Golem schrieb: > Aber man muß schon den Göttern der Komplexität huldigen > und sich damit abfinden können daß alles komplizierter ist als für die > konkrete Anwendung nötig. Wer sich statt auf Tausend Tools und Treiber > lieber auf eine konkrete Anwendung konzentrieren möchte bleibt beim > Xmega- den kann man in der Tqfp-44 Variante sogar noch selber löten, das > eine Tool (Studio6) ist kostenlos und man hat noch eine Chance > assemblermäßig den Dingen auf den Grund zu gehen! hmmm dann wäre ich wohl auch besser beim meinem Sharp MZ700 mit Z80 CPU geblieben..... neue PC sind einfach zu komplex demnach :D
Jörg B. schrieb: > neue PC sind einfach zu komplex demnach Nö. Mit Windoof ist doch alles ganz einfach... Aber Mann/Frau soll es doch einfach ausprobieren und vergleichen. Muß halt jeder seine Erfahrungen machen.
Jörg B. schrieb: > dann wäre ich wohl auch besser beim meinem Sharp MZ700 mit Z80 CPU Mehr Leistung bedingt nicht zwangsläufig mehr Komplexität in der SW Entwicklung- das ist eindeutig ein Trugschluß.
Golem schrieb: > Wilhelm Ferkes schrieb: >> klingt die Sache mit dem Discovery-Board nach wie vor gut > > ...klingt gut. Aber man muß schon den Göttern der Komplexität huldigen > und sich damit abfinden können daß alles komplizierter ist als für die > konkrete Anwendung nötig. Man muss ja nicht direkt alles einsetzen. Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, durch die STM32 viel komplizierter geworden wären. Durch die von ST mitgelieferten Bibliotheken ist es aber natürlich anders geworden. Aber: man kann damit eben doch noch viel weiter hinaus - wenn man möchte. > Wer sich statt auf Tausend Tools und Treiber Tausend Tools und Treiber? Hier läuft Eclipse und die Toolchain - genauso wie beim AVR. > lieber auf eine konkrete Anwendung konzentrieren möchte bleibt beim > Xmega- den kann man in der Tqfp-44 Variante sogar noch selber löten, Das geht bei den meisten Gehäusen der STM32 auch noch ohne Probleme. > eine Tool (Studio6) ist kostenlos Eclipse, GDB und diverse Werkzeugketten auch. > und man hat noch eine Chance > assemblermäßig den Dingen auf den Grund zu gehen! Das hat man auch weiterhin. > P.S. hab mir aus Neugier auch das Discovery besorgt- und alle schlimmen > Erwartungen s.o. bestätigt gefunden. Das kann ich nicht wirklich nachvollziehen. Einarbeiten musste ich mich beim AVR genauso wie jetzt bei den STMs. Aber komplizierter? Nur, wenn man komplexe Dinge machen möchte. Man muss ja nicht direkt mit dem DSP im STM32F4 beginnen - aber man kann eben, wenn man möchte. Chris D.
Chris D. schrieb: > Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, > durch die STM32 viel komplizierter geworden wären. Ich finde eine solche Aussage wirklich nur noch albern. So gut wie alles ist komplexer, um nicht zu sagen umständlich. Nun gut, mich zwingt zum Glück keiner, war die pure Neugier :-)
Golem schrieb: > Wilhelm Ferkes schrieb: >> klingt die Sache mit dem Discovery-Board nach wie vor gut > > ...klingt gut. Aber man muß schon den Göttern der Komplexität huldigen > und sich damit abfinden können daß alles komplizierter ist als für die > konkrete Anwendung nötig. Wer sich statt auf Tausend Tools und Treiber > lieber auf eine konkrete Anwendung konzentrieren möchte bleibt beim > Xmega- den kann man in der Tqfp-44 Variante sogar noch selber löten, das > eine Tool (Studio6) ist kostenlos und man hat noch eine Chance > assemblermäßig den Dingen auf den Grund zu gehen! > > P.S. hab mir aus Neugier auch das Discovery besorgt- und alle schlimmen > Erwartungen s.o. bestätigt gefunden. Ach, das ist doch schon ganz toll, daß auf den modernen Chips alle möglichen und unmöglichen Peripherals fertig drauf sind. Man muß ja nur eine Teilmenge davon gebrauchen, und freut sich, wenn man später noch was anderes macht, was auf dem Chip auch schon drauf ist. Auch heute kann man auf dem Teil nichts weiter als nur eine LED blinken lassen, wenn man das gerne möchte. Jedenfalls kenne ich die andere Seite, bspw. 8048 und 8085. Beide kann ich nicht direkt an eine RS232 hängen, um z.B. Debug-Ausgaben am Terminal zu machen. Denn sie haben beide noch nicht mal einen UART. Der 8085 hat noch nicht mal einen Timer. Wenn man das alles braucht, muß man externe Bausteine verwenden. Zwar habe ich da als Notlösung so Bitbanging-Codeteile, aber die beanspruchen den Prozessor ja voll, weil sie nicht vollautomatisch laufen. Interessehalber baute ich mir mal ein 8085-Board mit externem Timer und externem I/O (ja, das brauchte der auch!). Leider paßte auf die Europa-Karte kein UART-Baustein mehr, zu wenig Platz. Und ein Mords-Verdrahtungsaufwand. Mit den LPC2000 (ARM7) kam ich hervorragend zurecht. Vermutlich aber eher, weil ich am PC Profi-Tools von Keil hatte, ready to use. Installieren und los legen. Wegen der einfachen Überschaubarkeit möchte ich auch meine 8051-er nicht aufgeben.
Wilhelm Ferkes schrieb: > Jedenfalls kenne ich die andere Seite, bspw. 8048 und 8085. Beide kann > ich nicht direkt an eine RS232 hängen, um z.B. Debug-Ausgaben am > Terminal zu machen. Denn sie haben beide noch nicht mal einen UART. Der > 8085 hat noch nicht mal einen Timer. Wenn man das alles braucht, muß man > externe Bausteine verwenden. Da hängt man doch einen AY-3-1015 dran - um in der Zeit zu bleiben. Toteinfach das Teil, nur den Baudratentakt muss man zuführen. Aber keine komplizierte Initialisierung nötig, funzt einfach.
Golem schrieb: > Chris D. schrieb: >> Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, >> durch die STM32 viel komplizierter geworden wären. > > Ich finde eine solche Aussage wirklich nur noch albern. > So gut wie alles ist komplexer, um nicht zu sagen umständlich. Du hast einfach viel mehr Möglichkeiten. Entsprechend muss man eben auch mal den einen oder anderen Parameter mehr setzen. Aber dafür gibt es ja die ST-Bibliotheken. Das simple Füllen eines Structs sollte einen nicht wirklich überfordern. > Nun gut, mich zwingt zum Glück keiner, war die pure Neugier :-) Eben. Aber mit "Nur mal kurz Reinschnuppern" wird man sich in keine neue Controllerfamilie einarbeiten. Da erscheint dann natürlich alles fremd und umständlich. Man braucht seine Zeit. Deswegen mache ich das jetzt auch ein paar Monate nebenher, bevor wir dann wirklich von AVR auf ARM umsteigen. Chris D.
A. K. schrieb: > Da hängt man doch einen AY-3-1015 dran - um in der Zeit zu bleiben. > Toteinfach das Teil. Keine Initialisierung nötig, funzt einfach. Den kannte ich noch nicht, habe aber das Datenblatt gerade mal schnell überflogen, scheint sowas wie 8250 zu sein. Von dem habe ich noch Reserven, aber die Platine war schon voll. ;-) Für ein paar Spielereien, ich wollte die 8085-Karte ja nur als Retro-Teil mit ein paar blinkenden LEDs am 8255, nicht mehr für eine echte Entwicklung, dafür reicht es.
> Einarbeiten musste ich mich beim AVR genauso wie jetzt bei den STMs. > Aber komplizierter? Nur, wenn man komplexe Dinge machen möchte. Das stimmt nicht. Das grosse Problem der ARMs ist das es sie von verschiedenen Herstellern gibt und es da grosse Unterschiede gibt. Dann gibt es verschiedene Oberflaechen mit denen du arbeiten kannst, du kannst verschiedene Compiler einsetzen. Und zum Abschluss gibt es auch noch verschiedene Debugger. Da gibt es riesige Permutationsmoeglichkeiten, Softwarestaende die nicht zusammenpassen, Beispiele die nicht fehlerfrei sind. Wer bisher nur die Tools eines Hersteller gewohnt ist (Renesas:HEW, AVR:Studio) wo alles an die jeweiligen hauseigenen Bausteine angepasst ist, der wird da schwer ins staunen kommen. Und wenn man sich dann bisher nur als Gelegenheitsprogrammierer durchs leben geschummelt hat der seine Codes nur im Internet zusammengeklaut hat dann wird man erst recht staunen. (z.B wird es ploetzlich wichtig structs zu packen, oder je nach Taktfrequenz und Spannung die Waitstates anzupassen) Andererseits wenn man einmal damit klarkommen ist dann moechte man ganz gewiss niemals mehr einen ollen MCS51 programmieren. Nein danke, wirklich nicht! Olaf
Wilhelm Ferkes schrieb: > Den kannte ich noch nicht, habe aber das Datenblatt gerade mal schnell > überflogen, scheint sowas wie 8250 zu sein. Nein, eben nicht. UART ja, aber konfigurationsfrei. Also was die Software angeht. Alle Parameter wie die Anzahl Bits und die Parity liegen auf Pins. Mit dem Ding kriegst du einen 100% intelligenzfreien Parallel/Seriell-Wandler gebacken. So einen hatte ich vor ein paar Jahren man in einem Retro-Projekt verbraten, als Bootloader für einen ROM-freien RCA 1802: Beitrag "Re: RAM mit Adresslatch gesucht"
A. K. schrieb: > Mit dem Ding kriegst du einen 100% intelligenzfreien > Parallel/Seriell-Wandler gebacken. Das Dings habe ich genau dafür auch mal genutzt, einen parallelen Drucker per Optokoppler über 100m zu übertragen, Wandlerkästchen auf beiden Seiten und dann über Telefonleitung hin und zurück. Ist allerdings 20 Jahre her. Kaufen kannst du den AY-3-1015 nicht mehr, weiss nicht mal, ob GI überhaupt noch ICs herstellt. Thema: Was bei STM wirklich sehr gewöhnungsbedürftig ist, ist die Dokumentation. Das ist ein Hin- und Hergeschiebe zwischen PDFs mit schwierig zu kapierenden Beschreibungen, vor allem wenn es ums eingemachte geht, wie den Advanced Timer, ADC mit mehreren Kanälen und sonstige Spezialitäten. Das mehrere Kanäle beim ADC nur mit DMA gehen, ist z.B. in der Doku nicht klar. Beim XMega blättert man ja auch schon ständig zwischen Family- und Chipdoku hin und her, aber bei STM kommt dazu noch die eigenartige Umschreibung. Hat mich viel Zeit gekostet.
Golem schrieb: > Chris D. schrieb: >> Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, >> durch die STM32 viel komplizierter geworden wären. > > Ich finde eine solche Aussage wirklich nur noch albern. > So gut wie alles ist komplexer, um nicht zu sagen umständlich Ich finde diese Aussage auch nicht in Ordnung. Selbst, wenn man schon eine gewisse Programmiererfahrung hat und genau weiß, was man machen möchte, bedarf es doch einer deutlichen Einarbeitungszeit. Dies anschließend kleinzureden, drückt in meinen Augen Überheblichkeit aus. Beispielsweise finde ich einige Punkte beim STM32 überhaupt nicht anwenderfreundlich. Die Register für die io-Programmierung werden zwar in Strukturen angeordnet, aber diese Strukturen sind unnötiger Weise zusammengequetscht. Nehmen wir die Register-Struktur für den DMA-Controller. Alle acht Kanäle werden in eine Struktur gepackt, wobei in einzelne Registern aber Bits für unterschiedliche Kanäle gepackt werden (zum Beispiel DMA_LISR für Kanäle 0-3). Beim RX wird eine Struktur für einen DMA-Kanal definiert, die für alle Kanäle identisch ist. Das Ansprechen der einzelnen Kanäle unterscheidet sich anschließend nur in der Startadresse. Beim Deguggen ist dies viel transparenter. Schließt man ext. Speicher an einen STM32F4 an, wird man feststellen, dass Adress- und Datenleitungen etwas willkürlich auf die Portpins gewürfelt wurden. Beim RX werden Adressen und Daten 'geordnet' auf die 8 Bit breiten Ports gelegt: Beispiel D0-D7 auf PD0-PD7, D8-D15 auf PE0-PE7, A0-A7 auf PA0-PA7, ... Für mich sind das Gründe, warum der RX angenehmer zu handhaben ist.
Natürlich ist ein Auto komplizierter als ein Seifenkistl. Trotzdem möchte ich auf mein Auto nicht verzichten. In der Praxis bedient man das Auto irgendwann wie im Schlaf. So ist es auch mit den ARM. Zudem baut man doch neue Projekte stets auf alten, bewährten Code auf. Deshalb ist es letztlich wirklich kaum komplizierter als beim AVR. Natürlich gibt es eine Eingewöhnungsphase, wo man halt durch muss ...
m.n. schrieb: > Golem schrieb: >> Chris D. schrieb: >>> Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, >>> durch die STM32 viel komplizierter geworden wären. >> >> Ich finde eine solche Aussage wirklich nur noch albern. >> So gut wie alles ist komplexer, um nicht zu sagen umständlich > > Ich finde diese Aussage auch nicht in Ordnung. Selbst, wenn man schon > eine gewisse Programmiererfahrung hat und genau weiß, was man machen > möchte, bedarf es doch einer deutlichen Einarbeitungszeit. Dies > anschließend kleinzureden, drückt in meinen Augen Überheblichkeit aus. Ich habe da nichts kleingeredet und war ganz sicherlich nicht überheblich. Aber man kann doch nicht ernsthaft erwarten, dass man nach flüchtiger Beschäftigung mit einer neuen Architektur über vielleicht ein bis zwei Wochen dieselben schnellen Ergebnisse erhält wie mit einer, die man schon Jahre (ich mittlerweile über 11) kennt. Man muss sich nun einmal in eine neue Architektur einarbeiten - genau das muss ich auch und das schrieb ich auch so. Zu den verschiedenen Herstellern: Diversität hat Vor- und Nachteile. Ich empfinde es als angenehm, dass ich zwischen verschiedenen IDEs wählen kann und z.B. mit einer einzigen Kombination (Eclipse + GCC/GDB) sowohl für ARM als auch AVR entwickeln kann. Wenn ich zu einem anderen Hersteller gehe, dann wechsele ich im Prinzip nur das HAL aus - der ganze Rest der Entwicklungsumgebung bleibt. Thomas hat das schön beschrieben: wenn ich vom Fahrrad auf ein Auto umsteige, dann muss man das auch erstmal länger lernen, bis alles in Fleisch und Blut übergegangen ist. Aber dafür eröffnen sich auch ganz andere Möglichkeiten. Chris D.
@A.K.: OK, hast gewonnen. Ich kenne die alten Familien gar nicht so. Und in ein paar Minuten bekomme ich das im Detail auch nicht hin. Das einzige, was ich machte, als ich mit 8051 einstieg: Ich beschäftigte mich fast ausschließlich auch mit deren Vorgängern 8048 und 8085, bzw. 8085-Peripheriebausteinen, eben weil die auch zum 8051 passen. Also mit der Intel-Familie. Und da längst auch nicht mit allen. Einfach, um etwas mehr darüber zu erfahren, wie der 8051 zu Stande kam. Irgendwo haben diese Bausteine Intel 8-Bitter ja alle noch Parallelen, Gemeinsamkeiten. Thomas Winkler schrieb: > Zudem baut man doch neue Projekte stets auf alten, bewährten Code auf. Sagen wir es so: Der normale Funktionscode, Algorithmen, was nicht direkt hardwareabhängig ist, kann gelegentlich bleiben, wie er ist. Aber eine kleine Portierung bei den Peripherals ist mindestens schon nötig. Das kann unter Umständen noch etwas stressiger werden. Ich portierte mal 8051 auf einen ARM. Oder, wenn man beim 8051 die eingebauten Interrupt-Prioritäten nutzte, die es beim LPC2000 gar nicht so direkt gibt, da muß man sich was anderes einfallen lassen.
Chris D. schrieb: > ... Ich möchte noch hinzufügen, dass ich alle dargestellten Punkte (seien es Vorteile oder Kompromisse) von Chris teile. Auch der Vergleich mit dem Auto trifft es ganz gut. Das ist eine sehr schöne und objektive Darstellung der Tatsachen.
Damit die "ARM" Anfänger es leichter haben, gibt es im Artikel STM32 hier ein paar Tipps für Umsteiger: http://www.mikrocontroller.net/articles/STM32#Tipps_f.C3.BCr_Umsteiger_von_Atmel.2FPIC.2F8051 Und das sollte doch wirklich für jeden zu lernen sein. Wenn jemand von einem AVR auf einen PIC umsteigt, so wird er auch erst mal ein paar Problemchen zu lösen haben, der Aufwand von AVR zu ARM ist nicht wirklich größer. Nur dass man da etwas mehr lesen muss (Doku, Reference Manual, Datasheet).
Olaf schrieb: > Andererseits wenn man einmal damit klarkommen ist dann moechte man ganz > gewiss niemals mehr einen ollen MCS51 programmieren. Nein danke, > wirklich nicht! Ja doch, wenn man sie in- und auswendig kennt, auch die Toolchain, lange damit arbeitete, und noch Bausteine bzw. Boards hat. Für eine relativ einfachere Sache, wie eine simple Waschmaschinen-"Steuerung", ist der doch gut angebracht. Für einen blinkenden Weihnachtsbaum käme ich nie auf die Idee, ARMs einzusetzen. Wenn man aber in die neuen Dinge mal eingearbeitet ist, und die neuen leistungsfähigeren Bausteine auch nicht mehr teuerer sind, da läßt sich drüber reden, ganz klar. Und bspw. SiLabs haben hoch moderne 8051-Derivate mit Peripherals, das läuft schon fast wieder auf den STM32F4 hinaus.
Wilhelm Ferkes schrieb: > Für einen blinkenden Weihnachtsbaum käme ich nie > auf die Idee, ARMs einzusetzen. Da muss ich entschieden widersprechen. Der STM32 hat bis zu 32 PWM Ausgänge die separat geschaltet werden können, somit kann man die Lichterkette mit bis zu 32 Kanälen wunderschön dimmen und die verschiedensten Muster generieren. Ich glaube Dir fehlt noch etwas der Überblick über die Leistungsfähigkeiten und den daraus resultierenden Möglichkeiten. Steht schön zusammengefasst im Artikel STM32
> Wenn jemand von einem AVR auf einen PIC umsteigt, so wird er auch erst > mal ein paar Problemchen zu lösen haben, der Aufwand von AVR zu ARM ist > nicht wirklich größer. Nur dass man da etwas mehr lesen muss (Doku, > Reference Manual, Datasheet). Nach einigen Beiträgen hier könnte man aber meinen daß ein Umstieg von avr nach RX ohne weiteres Zutun möglich wäre... Ich könnte gerade übrigens einen CAN RX im QFN Gehäuse brauchen. Vorschläge?
Wilhelm Ferkes schrieb: > Sagen wir es so: Der normale Funktionscode, Algorithmen, was nicht > direkt hardwareabhängig ist, kann gelegentlich bleiben, wie er ist. Aber > eine kleine Portierung bei den Peripherals ist mindestens schon nötig. > Das kann unter Umständen noch etwas stressiger werden. Ich portierte mal > 8051 auf einen ARM. Nicht unbedingt. Wenn man die Aufgabe hat, auf mehreren Plattformen tätig zu sein, dann baut man sich eben dafür Tools auf. Man abstrahiert alle gängigen Aufgaben. Man schafft sich seinen Standardcode für Grundaufgaben. Rentiert sich halt nur wenn man viel Software hat die man portieren möchte.
Markus Müller schrieb: > Ich glaube Dir fehlt noch etwas der Überblick über die > Leistungsfähigkeiten und den daraus resultierenden Möglichkeiten. Das stimmt schon. Aber, je mehr, desto besser. Schade finde ich, daß das Discovery-Board ausgerechnet keinen CAN hat, denn genau dafür machte ich anderswo schon mal Software, und sowas könnte ich gebrauchen. > Man abstrahiert alle gängigen Aufgaben. Man schafft sich seinen > Standardcode für Grundaufgaben. Schon klar. In der Kleinklitsche ging es oft darum, schnellstmöglichst die Lösung zu haben. Also wirklich ZZ, ziemlich zügig. Keine Zeit zum Nase bohren. Da konnte man sich oft auch nicht mit ästhetisch schönem Code befassen, geschweige denn mit dem Tools-Setup.
Einen MCP2551 oder PCA82C250 an die entsprechenden Portpins ran löten und schon hat das Discovery auch CAN.
...oder den hier. (Mod.: Anhang pdf entfernt, stattdessen: http://www.ti.com/lit/ds/symlink/sn65hvd230.pdf )
Markus Müller schrieb: > Einen MCP2551 oder PCA82C250 an die entsprechenden Portpins ran löten > und schon hat das Discovery auch CAN. Schon klar. Aber er ist eben nicht integriert.
Wilhelm Ferkes schrieb: > Schon klar. Aber er ist eben nicht integriert. Was erwartest du noch für das Geld????
Oft wird der CAN galvanisch getrennt benötigt, da ist es sogar ein Vorteil, dass der nicht drauf ist. Noch ein ADUM1201 und DCDC Wandler dazwischen und schon hat man das auch.
Markus Müller schrieb: > Oft wird der CAN galvanisch getrennt benötigt, da ist es sogar ein > Vorteil, dass der nicht drauf ist. Noch ein ADUM1201 und DCDC Wandler > dazwischen und schon hat man das auch. Wie schon gesagt: Ich möchte nicht noch mal so anfangen, als man beim 8085 externe Peripherals benötigt.
Viel Spass. Herrje, das ist ein Transceiver, keine Peripherie. Schon mal einen µC mit integrierter 50V/10A Vollbrücke gesehen?
A. K. schrieb: > Viel Spass. Herrje, das ist ein Transceiver, keine Peripherie. Schon mal > einen µC mit integrierter 50V/10A Vollbrücke gesehen? Bei NXP überlegte man, sogar den CAN-Transceiver mit in den µC hinein zu verlegen. Ich verfolgte das aber nicht mehr, in wie weit das inzwischen gediehen oder auch nicht gediehen ist.
Ich weiss, das gibt es vereinzelt. Aber deine Aussage war doch etwas arg fundamentalistisch. Und so ein Transceiver ist nun wirklich kein Monster. Ethernet-PHYs sind weit schlimmer.
Wenn die Stromversorgung des µC doch schon galvanisch getrennt ist, wo ist denn da bei CAN ein Problem?
Wilhelm Ferkes schrieb: > A. K. schrieb: > >> Viel Spass. Herrje, das ist ein Transceiver, keine Peripherie. Schon mal >> einen µC mit integrierter 50V/10A Vollbrücke gesehen? > > Bei NXP überlegte man, sogar den CAN-Transceiver mit in den µC hinein zu > verlegen. Ich verfolgte das aber nicht mehr, in wie weit das inzwischen > gediehen oder auch nicht gediehen ist. Hallo Wilhelm, Ich arbeite mich z. Zt. in den C8051F580 ein und der hat schon alle wichtige Peripherien in ausführlicher Ausstattung. Der eingebaute CAN Bus Controller scheint auch vieles ohne CPU Mitarbeit zu erledigen. Irgendwie finde ich dem MCU ganz gut konzipiert. Auch gibt es nur drei Minor ERRATA. Viele andere MCU haben eher voluminöse ERRATA Buechlein;-) Naja, für mich ist dieser MCU noch ganz neu. Muss mal sehen wie viele Zähne ich mir dabei ausbeissen werde... (Obwohl der Vergleich hinkt, schlimmer als ein STM32 kann der bestimmt nicht sein und mit denen komme ich gut zurecht). mfg, Gerhard
Wilhelm Ferkes schrieb: > Bei NXP überlegte man, sogar den CAN-Transceiver mit in den µC hinein zu > verlegen. Ich verfolgte das aber nicht mehr, in wie weit das inzwischen > gediehen oder auch nicht gediehen ist. Der LPC11c22/24 hat den Transceiver eingebaut.
Gerhard O. schrieb: > Hallo Wilhelm, > > Ich arbeite mich z. Zt. in den C8051F580 ein und der hat schon alle > wichtige Peripherien in ausführlicher Ausstattung. Der eingebaute CAN > Bus Controller scheint auch vieles ohne CPU Mitarbeit zu erledigen. > > Irgendwie finde ich dem MCU ganz gut konzipiert. Auch gibt es nur drei > Minor ERRATA. Viele andere MCU haben eher voluminöse ERRATA Buechlein;-) ERRATA heißen heute auch schon wieder anders, wenn ich das richtig vernahm. > Naja, für mich ist dieser MCU noch ganz neu. Muss mal sehen wie viele > Zähne ich mir dabei ausbeissen werde... (Obwohl der Vergleich hinkt, > schlimmer als ein STM32 kann der bestimmt nicht sein und mit denen komme > ich gut zurecht). > > mfg, > Gerhard Die modernen SiLabs-Derivate haben allerdings mit dem echten 8051 kaum noch was zu tun. Es sind taktreduzierte MCU, die auch noch eine Pipeline haben. Die Zyklen etwas anders, als beim UR-8051. Aber ich wünsche dir viel Erfolg damit. Wir wollen ja nicht alle mit einem µC eine fertige Mondrakete bauen, sondern die Unzahl viel einfacherer Dinge.
Jörg B. schrieb: > Der LPC11c22/24 hat den Transceiver eingebaut. Dann machten sie es also doch. Leider kenne ich nur die LPC2100/2200. Ist schon eine Weile her.
Chris D. schrieb: > Ich habe da nichts kleingeredet und war ganz sicherlich nicht > überheblich. Das war auf die Schnelle etwas direkt formuliert und nicht speziell gegen Dich gerichtet. Aber ausgehend von der Eingangsfrage Umstellung 'AVR->ARM == kompliziert' und der vielfachen "Schönbeterei" kann bei einem Umsteigewilligen die Vorfreude auch schnell in Frust umschlagen. Golem hat sich ja dahingehend geäußert. Ich denke, die meisten Leute hier haben, ebenso wie ich, erst einmal mit einem Discovery-Board und überschaubaren Funktionstests in den STM32F4 hineingeschnuppert. Wenn dann daraus die Meinung abgeleitet wird, nur noch ARM nie wieder AVR, zeigt es, dass garnicht objektiv beurteilt wird: "ARM ist kostenlos bis billig und damit das non plus ultra." Das ist mir (und Olaf sicherlich noch mehr) eine viel zu einseitige Sichtweise. Wer anstatt Fahrrad lieber Auto fahren möchte, der muß auch die Spritpreise akzeptieren.
Ich hab mir diesen (mittlerweile) Monsterthread mal komplett durchgelesen. Und irgendwie find ich es trotzdem immer wieder interessant welche Flame-Wars vom Zaun gerissen werden wenns um die eine oder andere bevorzugte Architektur bzw uC-Familie geht :-) Aber es ist tlw auch sehr lehrreich durch die ganzen Side-Infos. Ich selbst hab mittlerweile auch schon mit einigen uC-Familien gearbeitet (MSP430, AVR, PIC, Renesas), und jede Familie hat ihre tollen Seiten, aber auch ihre Macken. Ich denke so wirklich "die" ultimative Empfehlung wird man nicht geben können, da sind wir uns denke ich alle einig. Es kommt auf den Anwendungsfall an. Und sich hobbymäßig damit zu beschäftigen erfordert eben immer was Zeit um sich in die Familie einzuarbeiten. Am wenigsten Probleme hatte ich bisher mit den PICs (das Eval-Kit lief direkt auf anhieb). Beim AVR wäre es wahrscheinlich genauso schnell gegangen wenn ich mit einem STK 500 angefangen hätte, aber ich hatte anfangs ein wenig Probleme die Eigenheiten der AVRs zu verstehen. Vorher hab ich mit MSP430 gearbeitet, und da war eben linearer Adressraum, einzelne Bytes/Words im Flash lassen sich zur Laufzeit umprogrammieren, die "Fuse-Bits" konnten per SW zur Laufzeit geschrieben werden. Da wirkte der AVR doch eher minimalistisch. Aber dennoch find ich die AVRs recht gut. Gerade für Einsteiger, und bei den Tutorials die es hier auf uC.net gibt ist das mit einm bissl Hirnschmalz kein Problem. Mit den ARMs hab ich schon immer ein bissl auf Kriegsfuß gestanden. Aber weniger wegen der Architektur, sondern eher wegen den div. Toolchains, Startup-Codes und Wiggler bzw Programmer-Problemen. Hab mich an einem LPC2106, einem AT91SAM7 und an einem STM32 probiert. Am besten hat mir die Rowley-IDE gefallen. Da hab ich mit dem AT91 einiges geschafft und war auch recht begeistert. Beim STM32 hatte ich das Primer, war aber ziemlich enttäuscht von der IDE, da viele Demos nicht mal eben liefen, bzw man ein bissl Tricksen musste um das CircleOS abzuschalten. Und das obwohl die reinen Daten des STM32 mich schon überzeugt haben. Ich für meinen Teil werd mich definitiv noch mit den ARMs beschäftigen, aber find es halt was "nervig" das man zig verschiedene Startup-Codes braucht, und das Debugging bzw Programmieren nicht immer so einfach ist wie beispielsweise bei einem PIC oder AVR. Das ist für mich momentan (neben dem Wust an IDE's und Toolchains) das einzige was mich stört. Da wäre eine IDE ähnlich wie die AVR-Studio einfach was feines. Und dann noch mit nem ARM-GCC der eben keine Code-Größen-Beschränkung hat, und "relativ" leicht einzurichten ist. Das wär mal nen echt schönes Paket. Das es solche Pakete gibt weiß ich (Yagarto, aber das lief bei mir nicht wirklich). Daher schwanke ich momentan zwischen dem STM32F4 (weil die Prozis einfach schön viel Flash und RAM haben, aber ich mal schauen muß mit welcher Toolchain und IDE das am einfachsten geht, und ich mal wirklich "eben" loslegen kann) und nem LPCXpresso (wo eben eine Codegrößenbeschränkte, aber komplette IDE dabei ist, und man direkt loshäcken kann :-)). Edit : Hab wohl nicht richtig gelesen als von CooCox und F4 die Rede war. Mmh, ich glaub dann fällt meine nächste "Investition" wohl auf ein STM32F4 Discovery Board und CooCox. Zumal das Board bei RS schon für 12 Euro zu haben ist (wenn ich das nicht auch falsch gelesen hab :-))
Viele loben hier die Coocox-IDE. Ich habe mit den Sachen keine guten Erfahrungen gemacht. Allerdings in Verbindung mit einem LPC1769. Die beiden Stm32 Boards (Discovery) habe ich mal angetestet. Mit den darauf verbauten st-link Adaptern geht das Debuggen ganz gut. Aber beim LPC1769 (auf einem SIMPLECORTEX Board http://www.brc-electronics.nl/) ist es nur noch Krampf. Hier ist der Colinkex jtag/swd Adapter drauf, und das ist noch keine Alternative zu einem j-link z.B. Abstürze, Häger oder geht gar nicht in abwechselder Reihenfolge. Sowohl in der CooCox-IDE als auch als Keil-Plugin. SWD ging garnicht, nur JTAG. Auf der anderen Seite ist die Intergration des j-link in die CooCox-IDE auch nicht besonders. Da wird bei einem Controller-Reset das gesamte j-link Modul neu in die Eclipse-Umgebung eingebunden. Das dauert so lange, dass man einfach keinen Spass daran haben kann. Die IDE zu benutzen um einfach mal eine woanders übersetzte elf-Datei zu debuggen geht auch nur krampfhaft. Und wass bringen mir die vielen Libs die mann dazu klicken kann, wenn die Libs nichts taugen? DS18B20 z.B. ist ausschließlich über delay-Schleifen gemacht. Den ständigen Ntzwerkzugriffen nach China traue ich irgendwie auch nicht über den Weg.
Ich habe manuell Eclipse mit dem CDT Master Plugin installiert, dazu Codesourcery GCC Compiler und den J-Link GDB Server und das klappt sehr gut und ist richtig schnell. Um das Discovery mit dem eingebauten ST-Link zu nutzen muss ich den Atollic GDB Server nutzen, ist deutlich langsamer, aber klappt auch zufriedenstellend. Diese Konfiguration kann ich empfehlen, ich nutze die schon seit mehreren Jahren, und hat keine Codebegrenzung. Coocox gefiel mir nicht so gut, da ich im makefile / Linkerscript nicht so frei war wie ich es wollte. Ich muss für Bootloader usw. einige Speicherbereiche anlegen, das ging damals mit Coocox nicht wirklich. Mit dem GCC/makefile/Linkerscript bin ich sehr zufrieden. Es braucht natürlich auch etwas Zeit da durch zu steigen und zu verstehen, dafür hat man schlussendlich viel mehr Möglichkeiten und hat alles im Griff was wie übersetzt wird.
temp schrieb: > Mit den darauf > verbauten st-link Adaptern geht das Debuggen ganz gut. A Hallo an die Experten in dem Zusammenhang hätte ich mal eine Frage zum Discovery (bin gerade beim ersten Anschluß). Habe die lite-Version von Keil uVision 4.60 und bekomme keine Verbindung zum Board hin! Im Win7 Gerätemanager ist der "ST Micro... STLink dongle" installiert, für den Target-Driver der ST-Link Debugger eingestellt. Nun wollte ich mal das Firmware Update 1.1 machen aber da kommt nur die Meldung "Could not load file ... Debugger aborted". Also ich bin drauf und dran den Kritikern hier recht zu geben, daß da hab ich aber via ISP und PDI beim AVR sehr viel schneller eine Verbindung bekommen :-( Robert
Angehängte Dateien:
-
keil.JPG
110 KB
Wer hat dir denn auch Keil empfohlen? Keil ist da etwas umständlich. Du musst "Programming Algorithm" von Hand hinzufügen. Sie Anhang.
Markus Müller schrieb: > Es braucht > natürlich auch etwas Zeit da durch zu steigen und zu verstehen, dafür > hat man schlussendlich viel mehr Möglichkeiten und hat alles im Griff > was wie übersetzt wird. Braucht man "Viel mehr Möglichkeiten" für Millionen kleinerer Controller-Apps wirklich? Ist die "etwas Zeit da durch zu steigen" wirklich sinnvoll investiert? Machen die "Viel mehr Möglichkeiten" nicht auch alles unnötig kompliziert? Der kleine Tiny der mir die Arbeitsbeleuchtung bei Abwesenheit zeitgesteuert wieder abschaltet zum Beispiel. Kleinst SMD+Transistor+winziges ASM Programm. Das mit ARM,Keil & Co.- eine Gruselvorstellung.
Golem schrieb: > Das mit ARM,Keil & Co.- eine > Gruselvorstellung. So ein Quatsch, mehr fällt mir dazu nicht ein!
Golem schrieb: > Markus Müller schrieb: >> Es braucht >> natürlich auch etwas Zeit da durch zu steigen und zu verstehen, dafür >> hat man schlussendlich viel mehr Möglichkeiten und hat alles im Griff >> was wie übersetzt wird. > > Braucht man "Viel mehr Möglichkeiten" für Millionen kleinerer > Controller-Apps wirklich? Ist die "etwas Zeit da durch zu steigen" > wirklich sinnvoll investiert? Machen die "Viel mehr Möglichkeiten" nicht > auch alles unnötig kompliziert? Wenn Du die AVR-Funktionalität auf den STM32 abbildest, dann steigt die Komplexität eigentlich gar nicht - nur der Overhead ist etwas größer. > Der kleine Tiny der mir die Arbeitsbeleuchtung bei Abwesenheit > zeitgesteuert wieder abschaltet zum Beispiel. Kleinst > SMD+Transistor+winziges ASM Programm. Das mit ARM,Keil & Co.- eine > Gruselvorstellung. Vor vier Monaten hätte ich vermutlich dasselbe geschrieben - am Anfang überwältigen einen die vielfältigen Möglichkeiten einfach. Aber wenn man sich wirklich Schritt für Schritt einarbeitet, ist das alles plötzlich gar nicht mehr so komplex. Heute würde ich sagen: "Komm, mache ich Dir eben." :-) Diese Zeit zur Einarbeitung musst Du Dir geben. Wenn Du mit den AVRs zufrieden bist und sie für Deine Anwendungen reichen: wunderbar! Dann ist es wirklich unnötig, auf ARM umzusteigen. Bei anderen (mir bspw.) reicht die Leistung jetzt eben nicht mehr - und da ich nicht gerne in zwei Architekturen parallel fit sein möchte, setze ich in Zukunft komplett auf STM32. Lieber eine Architektur wirklich verstehen und deren Macken kennen, als vier oder fünf nur halbwegs. Dass man einen STM32 mit einer Zeitsteuerung nicht einmal ansatzweise ausreizt, ist klar. Das ist aber der Lauf der Dinge. 32-Bitter kosten mittlerweile praktisch genauso viel wie die 8-Bitter. Da ist es irgendwann egal, ob der 99% der Zeit die Daumen dreht und man nur 5% der Hardware überhaupt verwendet. Chris D.
>Da ist es irgendwann egal, ob der 99% der Zeit die Daumen dreht und man >nur 5% der Hardware überhaupt verwendet. Daher kann man bei den ARM's die einzelen Peripherie Module schön deaktivieren und spart somit viel Strom. Auch kann man den mit nur wenigen MHz ohne PLL laufen lassen, denn die frisst auch den einen oder anderen mA weniger.
Richtig, Beispiel: [http://www.mikrocontroller.net/articles/EFM32 EFM32] von Energy Micro: Mit Hilfe der CMU (Clock Management Unit) kann man die Peripherie ein oder ausschalten, bzw. mit den Takt versorgen, der benötigt wird. Die ARM CMSIS Libraries helfen die Komplexität auf das Wesentliche zu beschränken. Viele ARM Cortex MCU-Hersteller verwenden diese. Die CPU-nahe Lib ist daher perfekt, wenn man von einem Hersteller zum anderen wechselt. Wenn die Hersteller CMSIS auch für die Peripherie-Lib verwenden, wie die EFM32Lib für den EFM32, dann ist es auch einfacher bzgl. Peripherie zu wechseln. Viel Spaß mit dem nächsten ARM Cortex M Projekt! TK
Wilhelm Ferkes schrieb: > Gerhard O. schrieb: > >> Hallo Wilhelm, >> >> Ich arbeite mich z. Zt. in den C8051F580 ein und der hat schon alle >> wichtige Peripherien in ausführlicher Ausstattung. Der eingebaute CAN >> Bus Controller scheint auch vieles ohne CPU Mitarbeit zu erledigen. >> >> Irgendwie finde ich dem MCU ganz gut konzipiert. Auch gibt es nur drei >> Minor ERRATA. Viele andere MCU haben eher voluminöse ERRATA Buechlein;-) > > ERRATA heißen heute auch schon wieder anders, wenn ich das richtig > vernahm. Das ist mir neu;-) > >> Naja, für mich ist dieser MCU noch ganz neu. Muss mal sehen wie viele >> Zähne ich mir dabei ausbeissen werde... (Obwohl der Vergleich hinkt, >> schlimmer als ein STM32 kann der bestimmt nicht sein und mit denen komme >> ich gut zurecht). >> >> mfg, >> Gerhard > > Die modernen SiLabs-Derivate haben allerdings mit dem echten 8051 kaum > noch was zu tun. Es sind taktreduzierte MCU, die auch noch eine Pipeline > haben. Die Zyklen etwas anders, als beim UR-8051. Wenn man keine Rücksicht auf Legacy nehmen muss, dann macht es bestimmt nichts aus. > > Aber ich wünsche dir viel Erfolg damit. Wir wollen ja nicht alle mit > einem µC eine fertige Mondrakete bauen, sondern die Unzahl viel > einfacherer Dinge. Danke für die guten Wünsche. Bei der Wahl des 8051 Derivates ging es mir hauptsächlich darum eine MCU Ausstattung zu finden die möglichst vergleichbar zu ähnlichen PICs und AVRs war, die ich sonst verwende. Ich möchte ein existierendes PIC Projekt auf den C8051 zu portieren. Deshalb gefällt mir der F58X Zweig sehr gut weil da alles an Peripherien und RAM vorhanden ist, die mein Projekt benötigt. Sonst habe ich noch einen AT89C8051RC2 herumliegen, der sieht auch erfolgversprechend aus. Gerhard
Gerhard O. schrieb: > Ich möchte ein existierendes PIC Projekt auf den C8051 zu portieren. Ich begann mal, ein reines Assembler-Projekt für den Standard-8051 zu beliebigen Plattformen zu portieren. Das ist aber noch eine Baustelle. Der Weg führt vom reinen Assembler zu C, und an einigen kniffligen Stellen mußte ich tatsächlich aus dem Assemblercode von Hand ein Flußdiagramm zeichnen, um es nach C zu überführen. Aber, es geht.
Hier ein kleiner Erfahrungsbericht mit dem STM32 von mir: Ich werkle seit letzten November im Betrieb an einem Projekt mit dem STM32F103. Zum Lernen mit einer Olimex-P103 Bord arbeitete ich anfangs mit der damaligen unbegrenzten Atollic Entwicklungsumgebung und für das Projekt stieg ich später im Betrieb auf IAR-EWARM um weil der in der Firma offiziell verwendet wird. Vorher arbeitete ich hauptsächlich mit 18/24/33er PICs und einigen AVRs. Nach einer etwas gewöhnungsbedürftigen Einarbeitungszeit auf die Besonderheiten der Welt der STM32s finde ich dass man ganz gut damit arbeiten kann. Wenn man mal alles richtig eingestellt hat und möglichst wiederverwendbaren Code schreibt, dann kann man ohne größeren Arbeitsaufwand vieles in neuen Projekte wiederverwenden. Den Startup Code kann man getrost den Einstellungen der Entwicklungsumgebung überlassen und sich auf das übrige konzentrieren. Es ist auch nutzbringend wenn man anfangs mit der CMSIS und ST-Peripheral Library arbeitet. Später kann man sich das alles auf einfachere Art stricken wie man es von anderen MCU Projekten gewöhnt ist. Das einzige was man auf alle Fälle (immer) tun sollte, vor dem H.W. und Bord Design sich die ERRATA gründlich durchlesen damit man nicht später unangenehme Überraschungen hat. Z.B. wenn man beim F103 USART1 die RTS/CTS Funktion braucht muss man wegen eines Fehlers in der MCU Peripherie die CAN Bus Pins remappen. Wenn man also da nicht aufpasst und die Original CAN Bus Pins verwenden will, kriegt man später beim Testen der Schaltung und FW leicht einen roten Kopf;-) Abschließend bin ich der Meinung dass, wen man schon etwas Erfahrung mit anderen Mikros hat, ohne Angst auf die ARM7 Typen umsteigen kann. Man darf sich halt nicht entmutigen lassen wenn man ab und zu die Tücken der neuen Welt kennen lernt. Dann muss man gründlich lernen und lesen und zähe sein. Am Ende geht dann doch alles. Bis jetzt habe ich alles noch zum Laufen gebracht. mfg, Gerhard
Ja ja, die Dinge zum Laufen zu bringen kann auch ein ehrgeiziges Ziel sein :) Schade um die Zeit. Wem dieser Thread noch nicht langt einen Eindruck von der aufgeblasenen Komplexität der ARM SW Entwicklung zu bekommen dem empfehle ich die Lektüre http://www.mikrocontroller.net/articles/STM32F4-Discovery ,die den beschwerlichen Weg anhand konkreter Hardware beschreibt. Abenteuerlich, ein Wahnsinn, welche Umstände es braucht um allein eine LED zum blinken zu bewegen... Nee nee, die 8 Bitter sterben schon so schnell nicht aus!
Je nach Entwicklungsumgebung ist es etwas mehr Aufwand die Dateien alle hin zu bekommen. Unter der Eclipse Umgebung ist in der Tat "Handarbeit". Damit der Einstieg leichter fällt habe ich hier ein Blink-Led DEMO in diesem Artikel: STM32 Eclipse Installation für den STM32F103. EIn Demo für den F4 habe ich auch, aber nicht fertig.
Ist das echt dein Ernst? Bislang kann ich kaum zusätzliche Komplexität sehen. Im Gegenteil zeigt das Beispiel im Artikel, dass die Schritte zum Pinwackeln im Grunde die Gleichen sind, auch wenn die Bezeichner anders gewählt sind. Ich sehe nur viel Argumentation über Geschmäcke. Weswegen der Thread so lang geworden ist. Dass man sich in jede neue uc Familie einarbeiten muss sollte selbstverständlich sein und gilt auch innerhalb des gleichen Herstellers/Technologie. Die Frage hier also ist eher, ist man offen, neugierig lernbereit für Neues, oder reicht einem (pragmatisch) was man kennt.
Golem schrieb: > Ja ja, die Dinge zum Laufen zu bringen kann auch ein ehrgeiziges Ziel > sein :) Schade um die Zeit. Wem dieser Thread noch nicht langt einen > Eindruck von der aufgeblasenen Komplexität der ARM SW Entwicklung zu > bekommen dem empfehle ich die Lektüre > http://www.mikrocontroller.net/articles/STM32F4-Discovery ,die den > beschwerlichen Weg anhand konkreter Hardware beschreibt. 1. zeigt dieser Artikel die Einrichtung der kompletten IDE und hat mit der STM-Programmierung außer dem kleinen Beispiel am Ende praktisch nichts zu tun. 2. habe ich genau mit diesem Artikel in weniger als zwei Stunden die IDE eingerichtet und konnte loslegen. Kompliziert ist nun wirklich anders. > Abenteuerlich, > ein Wahnsinn, welche Umstände es braucht um allein eine LED zum blinken > zu bewegen... Denselben Artikel kannst Du genauso für die Einrichtung von Eclipse für den AVR verwenden. Die "Komplexität" ist praktishc identisch. Denn: komplex ist da nicht der STM32 sondern Eclipse. > Nee nee, die 8 Bitter sterben schon so schnell nicht aus! Wer sie weiter verwenden möchte, darf das gerne tun. Dann aber auch bitte nicht über Dinge reden, die man offenbar selbst nicht kennt und in die man sich nicht einarbeiten möchte. Chris D. Edit: Ich sehe gerade, dass es sich beim letzten Golem-Beitrag mal wieder um eine multiple Persönlichkeit handelt - also Troll. Der Gute hat mit dem Golem weiter oben nichts zu tun. Glückwunsch - bin drauf reingefallen :-) Bitte nicht weiter darauf eingehen.
Chris D. schrieb: > 1. zeigt dieser Artikel die Einrichtung der kompletten IDE und hat mit > der STM-Programmierung außer dem kleinen Beispiel am Ende praktisch > nichts zu tun. > > 2. habe ich genau mit diesem Artikel in weniger als zwei Stunden die IDE > eingerichtet und konnte loslegen. > > Kompliziert ist nun wirklich anders. Chris, auch wenn du jemand anderen ansprachst: Sagtest du nicht mal, du wärst von Haus aus Informatiker? Nicht E-Techniker, wie ich? Ist es da nicht ein wenig einfacher? OK, ich richtete mir ja auch mal den SDCC für den 8051-er ein, der läuft ja auch nicht von selbst los. Nur die nackten Ausführungsprogramme für die Kommandozeile, und Libraries. Man muß sich auch noch irgendwo eine Bedienoberfläche suchen, und ein Batch-File machen, was die Quelldateien assembliert bzw. compiliert. Das klappte aber vorzüglich. Hier gab es mal einen Thread, wo jemand nicht mit dem SDCC klar kam. Da mußte ich mich aber selbst auch viele Tage mit befassen, war gelegentlich etwas säuerlich. Da kann ich aber jetzt selbst hier und da mal einen Rat geben. Von GCC und Make habe ich wiederum überhaupt keine Ahnung. Bei kleineren µC hat man mit sowas auch selten bis gar nicht zu tun. Die Komplexitätsunterschiede zwischen SDCC und den Tools, die ich für das Discovery-Board brauche, kann ich nicht einschätzen. Die Beiträge von Leuten, die es nicht manierlich hin bekamen, schreckten mich aus diesem Grunde aber auch etwas ab. Wenn es so wäre wie beim SDCC, hervorragend, damit könnte ich gut leben. Bestellt habe ich immer noch nicht, aber das kommt jetzt auf einen Tag gar nicht so genau an. Besonders nicht bei mir, der keine Entwicklung mit Termindruck hat. Vor dem STM32F4 selbst habe ich keine Panik, kann auch nicht sehr viel komplexer sein, als ein LPC2000.
Es ist nicht anders wie beim SDCC. Die Toolchain beim 32F4 ist im einfachsten Fall so simpel wie beim SDCC. GCC .. kompiliert .c Datei in Objectfile .o GCC .. linked ein oder mehrere .o Dateien in ein .bin Dazu gibt es ein Tool von ST mit dem man die Datei flashen kann. Das mit dem Makefile ist kein Muss. Es erleichtert nur die Sache wenn man mal viele .c Dateien hat. Weil es guckt halt was sich geändert hat und kompiliert nur was notwendig ist. Aber um all das braucht man sich nicht kümmern wenn man das kostenlose CooCox verwendet. Man sagt einfach EINMAL wo der GCC auf der Festplatte ist. Ab da langt ein Klick und es kompiliert. Ein weiterer klick lädt das Binary in den F4. Es ist sooo simpel! Warum wird hier immer so ein Drama daraus gemacht?
Golem schrieb: > Soooo simpel? Selten soooo gelacht :) Glaube ich nicht. Denn dann müsstest Du ständig lachen :-) Thomas bringt das schon gut auf den Punkt: Die Einrichtung der kompletten Toolchain benötigt keine zwei Stunden. Man hat für die Denkfaulen (wie mich) sogar eine Schritt-für-Schritt-Anleitung geschrieben. Wer schon bei solchen Dingen, bei denen man nicht einmal selbst zu Ergebnissen kommen sondern nur lesen/ausführen muss, scheitert - für den sind neue Controllerfamilien nichts. Der hat von diesen dann aber auch keinerlei Ahnung. Chris D.
Chris D. schrieb: > Wer schon bei solchen Dingen, bei denen man nicht einmal selbst zu > Ergebnissen kommen sondern nur lesen/ausführen muss, scheitert - für den > sind neue Controllerfamilien nichts. Der Meinung bin ich auch. Die Einrichtung einer neuen IDE ist teil der Einarbeitungszeit, die man eben hat beim Umstieg auf neue Prozessoren. Der Witz ist, dass dieser Anteil (die Einrichtung der IDE) nur ein kleiner Teil der gesamten Umstiegsarbeit ist. Wenn man diesen schon nicht überwinden kann, kann man es auch gleich sein lassen.
Hi Chris, erstmal Kompliment daß Ihr ARMen Euch solche Mühe gebt eine Hilfestellung zum Einstieg zu geben! Aber jeder Versuch die ARMs nur als anders und nicht als komplizierter als z.B. unsere lieben AVRs darzustellen sind einfach nur lächerlich. Vermutlich würde ich das nach Monaten der Einarbeitung aber auch nicht zugeben/eingestehen wollen :) Können wir uns nicht darauf einigen, daß man die ARMs erst dann einsetzt wenn deren Leistung/Features WIRKLICH gebraucht werden? Ganz davon abgesehen, daß dem Markt der ARM Programmiertools noch eine Apfelfirma fehlt.
Golem schrieb: > Hi Chris, erstmal Kompliment daß Ihr ARMen Euch solche Mühe gebt eine > Hilfestellung zum Einstieg zu geben! Aber jeder Versuch die ARMs nur als > anders und nicht als komplizierter als z.B. unsere lieben AVRs > darzustellen sind einfach nur lächerlich. Wer tut denn sowas? Natürlich sind die komplexer. Aber das ist doch kein Nachteil sondern eher eine Notwendigkeit, wenn der kleine AVR nicht mehr ausreicht! > Vermutlich würde ich das nach > Monaten der Einarbeitung aber auch nicht zugeben/eingestehen wollen :) > Können wir uns nicht darauf einigen, daß man die ARMs erst dann einsetzt > wenn deren Leistung/Features WIRKLICH gebraucht werden? Ja natürlich. Nur was du übersiehst ist: Zu Leistung/Features zählt auch - bereits gemachte Erfahrungen - Preis - Verfügbarkeit - ... andere nichttechnische Gründe Das heißt, jemand, der viel mit ARMs zu tun hat, wird sich einen Dreck darum scheren einen AVR zu benutzen, nur weil er den ARM nicht auslasten kann mit einer Anwendung. Auf der anderen Seite kann man auch zu den ARMs wechseln, wenn man für ein kommerzielles Produkt einen möglichst niedrigen Preis haben will, obwohl ein AVR den Job auch machen würde. Es ist eben alle eine Abwägungssache und zwar nicht nur aus technischer Sicht! > Ganz davon > abgesehen, daß dem Markt der ARM Programmiertools noch eine Apfelfirma > fehlt. Das glaube ich absolut nicht. Eine schnelle Suche nach OpenOCD + MACOSX gibt ein paar vielversprechende Ergebnisse.
Simon K. schrieb: > Die Einrichtung einer neuen IDE ist teil der > Einarbeitungszeit, die man eben hat beim Umstieg auf neue Prozessoren. > Der Witz ist, dass dieser Anteil (die Einrichtung der IDE) nur ein > kleiner Teil der gesamten Umstiegsarbeit ist. Eigentlich ist das die Hauptarbeit beim Umstieg. Weil was bleibt dann sonst noch übrig? Register lesen und schreiben ? ja gut bei dem einen µC ist es ein Register bei dem nächsten sind es getrennte Register. Ein Blick ins Datenblatt und gut ist es auch schon. Die Peripherie Bausteine aktivieren ? zb Uart oder Interrupthandler?. Auch da ein Blick ins Datenblatt und die Register mit den passenden Werte füllen. und fertig. Der Rest der Programmlogik ? Dem Rest ist es völlig egal auf welchem µC das ganze läuft. Ist der Code auch nur halbwegs gut geschrieben, sind die Änderungen beim Portieren von einem µC zum nächsten minimal bis Null.
Ralph schrieb: > Simon K. schrieb: >> Die Einrichtung einer neuen IDE ist teil der >> Einarbeitungszeit, die man eben hat beim Umstieg auf neue Prozessoren. >> Der Witz ist, dass dieser Anteil (die Einrichtung der IDE) nur ein >> kleiner Teil der gesamten Umstiegsarbeit ist. > > Eigentlich ist das die Hauptarbeit beim Umstieg. Sehe ich nicht so. > Weil was bleibt dann sonst noch übrig? Hast du dir mal die ganzen Peripherals vom ARM in ihrer Komplexität angeschaut? Da gibt es pro Peripheral eine Vielzahl von Funktionsmodi. Bis man da mal durchgeblickt hat, dauert es eben eine Weile. Bis man alle (oder viele) Peripherals durch hat, braucht man sicherlich mehr als ein paar Stunden zur Einrichtung der IDE. > Dem Rest ist es völlig egal auf welchem µC das ganze läuft. > Ist der Code auch nur halbwegs gut geschrieben, sind die Änderungen beim > Portieren von einem µC zum nächsten minimal bis Null. Das ist schlicht und einfach Unsinn, da verschieden Mikrocontroller nicht den gleichen Umfang an Peripherals haben bzw. die Peripherals untereinander nicht kompatibel sind. Da noch eine Abstraktionsebene einfügen zu wollen ist Overkill und nur mit ner Menge Aufwand zu realisieren, wie man an CMSIS und z.B. STM32 StdPeriph Library sieht.
Simon K. schrieb: > Natürlich sind die komplexer. Na also. Mehr wollte ich nicht hören. Komplexer, komplizierter und umständlicher- wenn es nämlich um die Millionen Anwendungen geht die ein 8 Bitter genauso bewältigt. Simon K. schrieb: > Auf der anderen Seite kann man auch zu den ARMs wechseln, wenn man für > ein kommerzielles Produkt einen möglichst niedrigen Preis haben will, Ich hatte doch schon gesagt daß im industrieellen Umfeld die Sache anders aussehen kann.
Simon K. schrieb: > Hast du dir mal die ganzen Peripherals vom ARM in ihrer Komplexität > angeschaut? Da gibt es pro Peripheral eine Vielzahl von Funktionsmodi. Eine in meinen Augen ungute Entwicklung. Die Hersteller wollen mit dieser Flexibilität sicher die Einsatzmöglichkeiten maximieren, machen damit aber auf der anderen Seite die Software unnötig kompliziert und fehleranfällig. Ob das alles immer zielführend ist? Ich denke weniger ist hier oft mehr.
Nö, höhere Flexibilität ist auch für einen Hobbyisten wie mich ein Segen. Weil man sich auf eine Familie einschiessen kann und dann ALLES damit abwickeln. Aber die Diskussion ist jedenfalls müßig, keiner kann den anderen überzeugen. Der einzige Nutzen davon ist für gegenwärtige und künftige Leser des Beitrag. Sonst hätte ich mich von vornherein da raus gehalten. Gegen stures verhalten ist kein Kraut gewachsen. Wenn man sich gegen jede technische Entwicklung sträubt, dann verwenden die vermutlich auch noch einen PC-XT ohne Festplatte mit DOS 2.11.
Golem schrieb: > Simon K. schrieb: >> Hast du dir mal die ganzen Peripherals vom ARM in ihrer Komplexität >> angeschaut? Da gibt es pro Peripheral eine Vielzahl von Funktionsmodi. > > Eine in meinen Augen ungute Entwicklung. Die Hersteller wollen mit > dieser Flexibilität sicher die Einsatzmöglichkeiten maximieren, machen > damit aber auf der anderen Seite die Software unnötig kompliziert und > fehleranfällig. Ob das alles immer zielführend ist? Ich denke weniger > ist hier oft mehr. Empfinde ich nicht so. Die Zeiten ändern sich - heutzutage sind die Chipkosten fast identisch, egal ob da nun drei oder 14 Timer sitzen. Da packt man drauf, was geht. Und der Vorteil ist: man kann einen Typ für fast alles einsetzen, muss sich also nicht durch zwei Dutzend Datenblätter lesen, weil je nach Anwendung der eine oder andere Chip gewählt werden muss. Es zwingt einen ja niemand, bspw. DMA einzusetzen, wenn man das nicht möchte. Bei den STM32 musst Du nur die Module einschalten, die Du auch wirklich benötigst. Und wenn man das so handhabt, dann ist bspw. das Blinken einer LED nicht komplexer als beim AVR. Dazu schaltet man nur ein einziges Modul ein (GPIO), initialisiert genau wie beim AVR die entsprechenden Pins und schaltet diese in einer Zeitschleife an und aus. Der Vorgang ist von der Komplexität der Vorgänge her also genau derselbe. Ich möchte Dir Deine AVRs nicht verleiden - wir arbeiten ja auch noch damit :-) Aber zu uns: wir arbeiten zu wenig mit Mikrocontrollern, als dass wir zwei Linien im Auge behalten könnten. Wenn man bspw. auch mal ein, zwei Monate nichts mit "seinem" Controller macht, dann benötigt man wieder etwas Zeit, um sich einzuarbeiten. Bei zwei Architekturen wäre der Aufwand noch größer - bei keinerlei Zusatznutzen für uns: denn die STM32 können ja alles, was die AVRs können - und eben erheblich mehr. Wenn ich für 50 Cent mehr einen 32-Bitter haben kann, dann fallen die AVRs hier eben hinten runter. Und deswegen werden wir hier eben komplett auf ARM umsteigen und - wenn wir hier soweit fit sind - keine AVRs mehr einsetzen. Das Bessere ist eben der Feind des Guten. Wenn für Dich die AVRs ausreichen, ist das doch ok. Wichtig ist immer nur: löst die Familie die AUfgaben, die ich habe oder nicht? Wenn uns die AVRs reichen würden, würde ich den Teufel tun, auf STM32 umzusteigen. Wobei mir die Verfügbarkeit nur durch Atmel schon gestört hat - bei ARM kann ich zumindest in erträglicher Zeit auf andere Hersteller umsteigen, wenn ich mich an die Bibliotheken halte bzw. wir uns jetzt ein halbwegs brauchbares HAL mit sauberen Schnittstellen aufbauen. Chris D.
Chris D. schrieb: > Wobei mir die Verfügbarkeit nur durch Atmel schon gestört hat - bei ARM > kann ich zumindest in erträglicher Zeit auf andere Hersteller umsteigen, Du willst provozieren? Na gut. In Deiner Schaltung läuft ein STM32F4x7 und dieser ist nicht lieferbar. Auf welchen gleichwertigen Typen eines anderen Herstellers würdest Du denn umsteigen und wie lange wirst Du dafür brauchen? :-) Wenn man sich auf einen µC festgelegt hat, ist man erst einmal von dessen Hersteller abhängig, egal welcher es ist. Das entscheidene daran ist nicht der verwendete Kern (ARM, RX, SH, ...) sondern die Peripherie, ohne die überhaupt nichts läuft! Den C-Quelltext anzupassen ist dagegen eher eine Kleinigkeit.
m.n. schrieb: > Chris D. schrieb: >> Wobei mir die Verfügbarkeit nur durch Atmel schon gestört hat - bei ARM >> kann ich zumindest in erträglicher Zeit auf andere Hersteller umsteigen, > > Du willst provozieren? Na gut. Nicht wirklich ... > In Deiner Schaltung läuft ein STM32F4x7 und dieser ist nicht lieferbar. > Auf welchen gleichwertigen Typen eines anderen Herstellers würdest Du > denn umsteigen und wie lange wirst Du dafür brauchen? :-) Wenn wir unser HAL so aufbauen können, wie ich es mir vorstelle, dann vielleicht ein bis zwei Wochen. > Wenn man sich auf einen µC festgelegt hat, ist man erst einmal von > dessen Hersteller abhängig, egal welcher es ist. Das entscheidene daran > ist nicht der verwendete Kern (ARM, RX, SH, ...) sondern die Peripherie, > ohne die überhaupt nichts läuft! Deswegen schrieb ich ja, dass wir von Anfang an ein HAL aufbauen werden, um die Anpassungen so gering wie möglich zu halten. Beim AVR damals hatte ich das (leider) versäumt. Passiert mir aber nicht nochmal. Mit der ST-Bibliothek hat man mMn schon eine ganz ordentliche Abstraktionsebene, die man nur noch verfeinern muss. Wenn ich mir bspw. die Stellaris M4 von TI ansehe, dann müsste ich unsere Programme bisher nur wenig ändern (sind zugegebenermaßen natürlich noch nicht sooo komplex). Es geht also schon. Bei der integrierten FPU und dem DSP wäre gar keine Änderung notwendig. Dass eine Umstellung ärgerlich und Arbeit ist, ist keine Frage :-) Aber sie ist zumindest in erträglicher Zeit machbar. Chris D. P.S.: Es ist aber auch nicht so, dass wir sofort auf dem Trockenen sitzen würden. Wir haben hier immer so 50 Chips vorrätig, mit denen wir dann schon ein bis zwei Monate hinkommen. Lagerhaltung ist also durchaus sinnvoll :-) Der Preisverfall kratzt uns wenig, da wir (gottseidank) nicht auf den Euro achten müssen. Die Position ist also natürlich komfortabler als bei anderen, die ihr Lager quasi auf der Straße haben. Aber da sag ich dann: selbst schuld.
So eine HAL ist sehr hilfreich, wenn man mal wechseln muss. Benötigt man hohe Stückzahlen, kann die Anpassung auf einen anderen Controller sogar bei voller Verfügbarkeit sinnvoll sein. Einfach eine Kostenfrage. Übrigens Kosten, - die werden bei den AVR explodieren. Weil die Autoindustrie die nicht mehr einsetzt. Private gibt es nicht ausreichend, vorallem wenn die auch abwandern.
Chris D. schrieb: > Wenn wir unser HAL so aufbauen können, wie ich es mir vorstelle, dann > vielleicht ein bis zwei Wochen. Die Sache mit HAL ist eher soetwas wie ein reduziertes "HALLO WELT" auf einem anderen µC anzuzeigen :-) Welcher andere µC inkl. Timer läuft denn mit 168MHz? Und welcher µC hat denn 196kRAM intern? Gleiches Pinout? Und, und, und, ... Oder ganz direkt: es gibt keinen Zweitlieferanten! Oder man beschränkt sich auf Grundfunktionen, die auch ein AVR leisten kann :-) Thomas Winkler schrieb: > Übrigens Kosten, - die werden bei den AVR explodieren. Weil die > Autoindustrie die nicht mehr einsetzt. Dann werden im Gegenzug die RXe wohl spottenbillig werden! Genug gelästert :-)
m.n. schrieb: > Chris D. schrieb: >> Wenn wir unser HAL so aufbauen können, wie ich es mir vorstelle, dann >> vielleicht ein bis zwei Wochen. > > Die Sache mit HAL ist eher soetwas wie ein reduziertes "HALLO WELT" auf > einem anderen µC anzuzeigen :-) Wenn man ein schlechtes HAL hat sicherlich :-) Aber unser wird da schon deutlich mehr können. > Welcher andere µC inkl. Timer läuft denn mit 168MHz? > Und welcher µC hat denn 196kRAM intern? Das reizen wir eh nicht aus, sind da also flexibel. Außerdem ist TI auch schon bei 150MHz. Bis auf Timeranpassungen (für die u.a. unser HAL zuständig sein wird) muss man also nichts unternehmen. > Gleiches Pinout? Das Pinout ist bei einem Familienwechsel mein geringstes Problem, zumal es da durchaus Möglichkeiten gibt, auf den Boards eine "Zwischenlage" mit einzuplanen (was wir auch tun). Also einfach ein kleines zweilagiges "Konvertierungs-PCB", das aufgelötet wird und die Pinbelegung anpasst. Das haben wir sogar schon für einige AVRs gemacht. Ist alles keine große Sache, wenn man da vorher dran denkt. > Oder ganz direkt: es gibt keinen Zweitlieferanten! > Oder man beschränkt sich auf Grundfunktionen, die auch ein AVR leisten > kann :-) Guter Scherz :-) Nein, AVRs, so gerne ich sie hatte, sind bei uns jetzt einfach an ihrer Grenze angekommen und fliegen raus. > Thomas Winkler schrieb: >> Übrigens Kosten, - die werden bei den AVR explodieren. Weil die >> Autoindustrie die nicht mehr einsetzt. > > Dann werden im Gegenzug die RXe wohl spottenbillig werden! > Genug gelästert :-) RX ist eben auch Monopolist. Noch ein Vorteil der ARM-Geschichte - die Preise sinken, weil man Chips mit ähnlicher Ausstattung, Rechenleistung und AUfbau eben auch von anderen Herstellern bekommt. Da kann sich keiner Ausreisser nach oben erlauben. Chris D.
Jeder der sein Hobby zum Beruf machen will (Job in einer entsprechenden Firma), der sollte sich ein wenig mit den ARM's beschäftigen. Da fällt dem zukünftigen Chef die Auswahl der Bewerber dann auch leichter.
Thomas Winkler schrieb: > Nö, höhere Flexibilität ist auch für einen Hobbyisten wie mich ein > Segen. Weil man sich auf eine Familie einschiessen kann und dann ALLES > damit abwickeln. Kann ich mit Xmega auch. Anstatt die Konfigurationsmöglichkeiten wie Unkraut sprießen zu lassen sollte die Entwicklung eher zu mehr Intelligenz in den Peripheriebausteinen gehen! Nehmen wir z.B. I2C. Es würde doch langen dem Baustein die nötigen Daten (Speed, Device Adresse, zu lesende, zu schreibende Bytes aus/in einen internen Bausteinbuffer) zu übergeben. Aber nein, ein extra Treiber wird für die Abwicklung nötig. Thomas Winkler schrieb: > Wenn man sich gegen > jede technische Entwicklung sträubt So ein Blödsinn. Nur sollte man sich nicht nerdmäßig von der ach so tollen Hardware blenden lassen m.n. schrieb: > Welcher andere µC inkl. Timer läuft denn mit 168MHz? ...sondern die realen Anforderungen im Auge behalten. Die Xmegas neuerer Bauart lassen sich übrigens auch schon auf 64 MHz hochtakten- aber diesen Speed werd ich mangels Multimediaanwendungen wohl nie brauchen. Die kauf ich viel billiger im Laden! Ich persönlich würde für einen AVR locker das Dreifache bezahlen wenn die SW-Entwicklung weiter überschaubar bleibt. Und sollte später wirklich mal alles auf ARM umschwenken hoffe ich, daß dann eine Apfelfirma daherkommt und die Hardware-Differenzen / Konfigurationsmöglichkeiten gekonnt in einem einfachen Programmiertool zusammenfaßt. iPadmäßig halt :) Hier wie dort wird es aber weiter Komplexitätsapostel geben die Kompliziertheit als Wert an sich betrachten, und sei es auch nur um sich jahrelang angesammeltes Fachwissen nicht so einfach entwerten zu lassen...
Moby schrieb: > Thomas Winkler schrieb: >> Nö, höhere Flexibilität ist auch für einen Hobbyisten wie mich ein >> Segen. Weil man sich auf eine Familie einschiessen kann und dann ALLES >> damit abwickeln. > > Kann ich mit Xmega auch. Natürlich geht das auch mit dem Xmega - immer im Rahmen der Möglichkeiten des entsprechenden Controllers. Irgendwann reicht es halt nicht mehr und dann muss man wechseln. Und wenn man dann schaut, welche Leistung man für dasselbe Geld erhält, dann spricht auch nichts dagegen, die neue Familie auch in kleineren Projekten einzusetzen. Wie schon weiter oben gesagt: ich würde nur ungern zwei Familien gleichzeitig pflegen. > Anstatt die Konfigurationsmöglichkeiten wie > Unkraut sprießen zu lassen sollte die Entwicklung eher zu mehr > Intelligenz in den Peripheriebausteinen gehen! Nehmen wir z.B. I2C. Es > würde doch langen dem Baustein die nötigen Daten (Speed, Device Adresse, > zu lesende, zu schreibende Bytes aus/in einen internen Bausteinbuffer) > zu übergeben. Aber nein, ein extra Treiber wird für die Abwicklung > nötig. Genau das hast Du bspw. beim STM32 schon fast erreicht. Du sagst der I2C mit einem Struct nur noch, dass sie mit der Adresse X und der Geschwindigkeit Y eine festgelegte Anzahl an Daten senden soll, das man dann auch noch per DMA erledigen lässt. Gleiches gilt für den Empfang: bei richtiger Adresse springt Deine I2S an und Deine DMA schaufelt die Daten dorthin, wo Du möchtest. Das alles geschieht vollautomatisch und ohne weitere Prozessorbelastung. Und am Ende kriegst Du noch Hinweise, ob alles geklappt hat bzw. dass empfangen wurde - wenn man möchte per Interrupt. Einfacher geht es kaum noch. > m.n. schrieb: >> Welcher andere µC inkl. Timer läuft denn mit 168MHz? > > ...sondern die realen Anforderungen im Auge behalten. Die Xmegas neuerer > Bauart lassen sich übrigens auch schon auf 64 MHz hochtakten- aber > diesen Speed werd ich mangels Multimediaanwendungen wohl nie brauchen. > Die kauf ich viel billiger im Laden! Naja, jeder hat andere Anforderungen an die Geschwindigkeit. Und: nicht jede Anwendung kann man im Laden kaufen (insbesondere nicht unsere ;-) Multimediaanwendungen sind nur ein sehr kleiner Teil der speicher- und rechenintensiven Anwendungen. > Ich persönlich würde für einen AVR locker das Dreifache bezahlen wenn > die SW-Entwicklung weiter überschaubar bleibt. Und sollte später > wirklich mal alles auf ARM umschwenken hoffe ich, daß dann eine > Apfelfirma daherkommt und die Hardware-Differenzen / > Konfigurationsmöglichkeiten gekonnt in einem einfachen Programmiertool > zusammenfaßt. iPadmäßig halt :) Das wird dann nur auf deren Produkte passen - eben apfelmäßig. Denn die werden kaum für andere entwickeln ;-) Aber das sind alles ungelegte Eier - lassen wir uns überraschen. Ich finde, ST hat mit der Bibliothek schon einen guten Schritt zur Vereinheitlichung zumindest bei ihren Produkten gemacht. Klar ist auch die nicht perfekt, aber es ist ein Anfang. > Hier wie dort wird es aber weiter > Komplexitätsapostel geben die Kompliziertheit als Wert an sich > betrachten, und sei es auch nur um sich jahrelang angesammeltes > Fachwissen nicht so einfach entwerten zu lassen... Ich bin eher für Einfachheit, daher: lieber nur einen Typ verwenden, den aber richtig. Ob das wie bei uns jetzt ARM wird oder bei Dir AVRs sind, ist ganz egal. Chris D.
Chris D. schrieb: > Ich finde, ST hat mit der Bibliothek schon einen guten Schritt zur > Vereinheitlichung zumindest bei ihren Produkten gemacht. Klar ist auch > die nicht perfekt, aber es ist ein Anfang. Das halte ich für ein Gerücht. Dann müssten ja Programme vom F1 auch auf dem F4 laufen...
Jörg B. schrieb: > Das halte ich für ein Gerücht. Dann müssten ja Programme vom F1 auch auf > dem F4 laufen... Wie ich hier vernahm, können die STM32F4 THUMB oder THUMB2, keinen ARM-Mode. Der LPC 2100/2200 konnte wiederum ARM und THUMB. Das sollte noch geklärt werden.
>Das halte ich für ein Gerücht. Dann müssten ja Programme vom F1 auch auf >dem F4 laufen... Das tun sie natürlich nicht. Programme für XMega laufen aber auch nicht auf ATMEga. Die Bibliotheken für STM32F4 und STM32F1 sind aber zum grössten Teil portabel. Es gibt größere Unterschiede z.B. beim DMA. Aber da ist ja auch die Hardware eine andere. Ein Umstieg von STM32F1 auf STM32F4 geht relativ schmerzfrei.
GPIO und Clock's sind noch anders, da haben die beim STM32F2/4 noch einige nette Erweiterungen hinzugefügt ;-) Der Rest (Timer, I2C, SPI usw.) sollten gleich sein. Dennoch ist die Umstellung recht leicht, habe ich schon einige male gemacht.
Es ist tatsächlich so, dass einige F1 sample codes fast unverändert am F4 laufen. Natürlich muss man sagen, die Pin Belegung ist teilweise anders, das muss man selbstverständlich anpassen. Der F4 hat einiges mehr (SDIO) und anders, solche Hardware abhängigen Sachen muss man immer anpassen. Auch zwischen zwei AVR.
Ich unterbreche die wissenschaftliche Diskusion:"Können Dinge, schwerer als Luft, von sich aus fliegen" nur ungern, dennoch bitte ich die Herrschaften, mal einen Blick aus dem Fenster zu wagen. Dort geht ein Bub' mit seinem Luftballon spazieren ...
Ein paar Zitate aus Goethes Faust: "Der Worte sind genug gewechselt, lasst mich auch endlich Taten sehen." Der Direktor, im Vorspiel auf dem Theater zum "Faust" "Es irrt der Mensch solang er strebt." Gott "Ich bin der Geist der stets verneint." Mephisto "Alles, was entsteht, ist wert, dass es zugrunde geht." Mephisto http://free.pages.at/hojager/wissen/redewendungen_d.htm
Der Chef zum Entwickler: "Der Worte sind genug gewechselt, lasst mich auch endlich Daten sehen." Peter
Golem schrieb: > Na also. Mehr wollte ich nicht hören. Komplexer, komplizierter und > umständlicher- wenn es nämlich um die Millionen Anwendungen geht die ein > 8 Bitter genauso bewältigt. Der Fehler liegt darin Komplexität und Umständlichkeit gleichzusetzen. Das ist nicht der Fall. Vereinachtes Beispiel: Wenn ich nen AVR mit einem Port und 8 IO Pins habe (angenommen in der Ausführung gibt es den) und wechsle auf einen Arm der nun zwei Ports mit je 8 Pins hat. Dann läuft das Orginalprogramm genauso auf dem Neuen. Mein Programm ist also genauso einfach gehalten wie vorher. Der AVR lässt sich genauso einfach/ nicht komplizierter wie vorher ansteuern. Dennoch ist der AVR komplexer (um genau einen Port) Wenn du also von Komplexität sprichst, dann trägt das nur dann zur Umständlichkeit bei, wenn du gezwungen bist diese Dinge zu nutzen. Konstanter Aufwand (Initiales Registersetzen) ist kein Aufwand. O(0) == O(1) Wenn du allerdings sowieso Features brauchst, die die Hardware vor dem Wechsel nicht unterstützt, dann macht eine Hardware, die dies für dich mit Optionen löst dein Problem nicht komplizierter, sondern im Gegenteil gar einfacher, in dem es dich nicht dazu zwingt Hilfsmittel, die nicht zur Programmlogik gehören in Software zu lösen.
Hast Du im Grundsätzlichen sehr schön erklärt, Maxx, wenn nur der verdammte Teufel sich nicht immer im ARM-Detail, der hochflexibel unübersichtlichen Hardware- ,Tool- und Librarylandschaft verstecken würde! Naja, den (in reizvoll neuer Hardware) auszutreiben mag vielleicht elementarer Bestandteil des Programmierspaßes sein. Aber ob es immer die viele Zeit lohnt, wenn es genausogut mit einem Update der alten Hardware geht (Mega->Xmega)? Das ist natürlich auch eine Frage persönlicher Interessen/Vorlieben. In meinen Augen sollte der Plattformwechsel ob des Aufwands schon zwingend sein. Durch mehr und nötige Performance, durch einfachere Programmierbarkeit, durch weitere Gründe. Alles nicht gegeben? Dann warten wir doch auf die übernächste HW Revolution! Die kommt bestimmt! Bis dahin investieren wir unsere kostbare Lebenszeit besser sinnvoller :)
Thomas Winkler schrieb: > Übrigens Kosten, - die werden bei den AVR explodieren. Weil die > Autoindustrie die nicht mehr einsetzt. Private gibt es nicht > ausreichend, vorallem wenn die auch abwandern. So ein Schwachsinn, AVR sind zum Teil bis 150°C spezifiziert und es kamen vor kurzem erst neue Automotive Qualifizierungen auf 125°C raus, zeig mir mal einen Cortex der 150°C Flash Technologie hat... Niedrige Stromaufnahme ist der Schlüssel um in der Automotive Industrie überhaupt als Hersteller in Betracht genommen zu werden, oder meinst Du wirklich jeder Sensor läuft da mit STM32 der >300uA/Mhz verbraucht, und im Sleep Mode nicht unter 1uA kommt... Erst kürzlich hat Atmel neue Tinys vorgestellt die in super-kleinen Package daherkommem, überall wo ein MEMS Sensor eingesetzt wird (hauptsächlich Mobiltelefone) wird ein kleiner Controller benötigt damit man den Baseband nicht mit diesen Dingen "belästigen" muß. In der Hausgerätetechnik werden immer noch Bauteile verwendet die 5.5V unterstützen. Das sind alles Massenmärkte für die AVR und da hat selbst ein 50Cent CortexM0 keinen Platz (zu viel Strom im PowerSave, zu starker Anstieg der Powerconsumption über den TempBereich, keine getrennte Busse, Interrupt Latency zu viele Cycles, langsamer wakeup)... das ist alles nur Marketing Gelaber
mal sehen, wann auch die Letzten bemerken, daß das "Amen" schon längst gesprochen wurde ------;
Mist. Watterott hat ausverkauft, Lagerbestand Null. Sonst hätte ich heute Discovery bestellt. ;-)
Jetzt hast Du zu lange gewartet ;-) Wer zu spät kommt, den bestraft das Leben.
Discovery F4: http://www.ebay.at/itm/STM32F4-Discovery-/251162019805?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3a7a6c47dd
http://de.mouser.com/ProductDetail/STMicroelectronics/STM32F4DISCOVERY/?qs=sGAEpiMZZMutVogd4PRSvEN8XDBeCtgD ab 75 euro Versandkostenfrei - macht doch ne sammelbestellung.
Gibts ja teilweise schon ab 13 Euro... Das kann doch unmöglich kostendeckend sein! Die habens aber nötig, Ihr ARM Zeugs in den Markt zu drücken ?!
Also bei 13€ kann ich mir das noch kostendeckend vorstellen. Was würde denn mehr kosten? Allerdings gibt es noch günstigere Einstiegsboard (Stichwort Launchpad) die dann auch in der Menge fegrenzt sind. Finde das deutet nicht unbedingt auf "nötig haben" hin, sondern ein Bewusstsein für die DiY/Hobbyfraktion. Machen wir uns nichts vor. Einsteiger (Darunter viele Schüler) wollen es hier meist sehr preiswert.
Michael schrieb: > Gibts ja teilweise schon ab 13 Euro... Das kann doch unmöglich > kostendeckend sein! Die habens aber nötig, Ihr ARM Zeugs in den Markt zu > drücken ?! das nennt sich "Buying Marketshare" - das ist doch heute alles was zählt - zu jedem Preis Marktanteile gewinnen, ohne Rücksicht auf Verluste (siehe ST, trotz scheinbar so niedrigen Preise sind die trotzdem nicht in der Lage zu wirtschaften, so dass sie nun gar die Produktion kürzen müssen). Und dann wenn man den Markt mir Ramsch-Preisen aufgekauft hat erhöht man den Preis... im Analogen Bereich hat ST schon die Preise erhöht, von irgendwas muß man ja dann die nächste Innovation finanzieren
Markus schrieb: > Michael schrieb: >> Gibts ja teilweise schon ab 13 Euro... Das kann doch unmöglich >> kostendeckend sein! Die habens aber nötig, Ihr ARM Zeugs in den Markt zu >> drücken ?! Warum sollte das nicht kostendeckend sein? Wenn man sich überlegt, wieviel ST wohl an Produktionskosten für ihre eigenen Chips hat und was so auf dem Board ist, dann sollte das in den Stückzahlen locker für einen 10er machbar sein. Zumal ich nicht denke, dass bspw. Cirrus viel für z.B. den Audio-Codec verlangt. Vermutlich gibt es den sogar umsonst, weil sich Cirrus gar keine bessere Werbung für sich wünschen kann. Und TI springt auf denselben Zug auf :-) > das nennt sich "Buying Marketshare" - das ist doch heute alles was zählt > - zu jedem Preis Marktanteile gewinnen, ohne Rücksicht auf Verluste Ich denke nicht, dass sie damit Verluste machen. Gewinn aber auch nicht. Ich erwarte allerdings von einem Unternehmen, das mir seine Chips schmackhaft machen möchte, dass es die Entwicklungstools dafür entsprechend günstig zur Verfügung stellt und nicht nochmal abkassiert, damit ich überhaupt deren Chips programmieren "darf". ST macht letztendlich nur das, was Atmel erfolgreich praktiziert hat: preiswerte Entwicklungstools (und bei Atmel noch entsprechende Gehäuse) und Einstiegsmöglichkeiten. Das Board werden sich viele Studenten etc leisten - und das sorgt natürlich dafür, dass diese Chips später mit Vorliebe in der Entwicklung genommen werden. Ich würde es nicht anders machen. > (siehe ST, trotz scheinbar so niedrigen Preise sind die trotzdem nicht > in der Lage zu wirtschaften, so dass sie nun gar die Produktion kürzen > müssen). Das ist ein vollkommen normaler Vorgang im zyklischen Geschäft. > Und dann wenn man den Markt mir Ramsch-Preisen aufgekauft hat erhöht man > den Preis... im Analogen Bereich hat ST schon die Preise erhöht, von > irgendwas muß man ja dann die nächste Innovation finanzieren Auch das ist normal, funktioniert bei ARM aber nicht wirklich. Die Hürde für den Umstieg auf andere ARM-Hersteller, die Chips ähnlicher Leistungsklasse anbieten, ist dafür zu gering. Würde der Preis großartig anziehen, wechseln die Leute beim nächsten Projekt eben zu jemand anderem (und nehmen die IDE etc. mit). Chris D.
Hallo, hab zum STM32F4 Discovery gerade das hier entdeckt: http://shop.myavr.de/ARM-Produktlinie/mySTM32-Board-F4D,%20Bausatz.htm?sp=article.sp.php&artID=200075 da komm ich ja mit dem Discovery billiger hin wie bei nem MK2 Bausatz :-o ich glaub da steig ich auch mal von meinem myAVR auf einen myARM um ;-) Gruß
Als ich jetzt einem ein ST Discovery zum Start empfohlen habe, ist mir etwas negatives an dem Tipp aufgefallen. Das ist allerdings nicht die zu hohe Komplexität des ganzen, denn auf dem Teil werden schon fleissig neue kleine Dinge implementiert. Wenn die Person jetzt "nur" Hobbyist wäre, würde ich sagen toll! Das negative an dem ganzen ist, dass gar kein Background in der Basis aufgebaut wird wie man es eigentlich bräuchte meiner Meinung nach, wenn man später mit solchen Geräten Hardware ansteuern soll. Ich selbst habe mir ARM und Assembler noch nicht wirklich angeschaut, aber auf den AVRs ist doch immer wieder mal etwas inline Assembler im Code vorhanden, auch wenn ich das im Gegensatz zu meinem Chef meist noch versuche in C so zu Programmieren das mein wunsch assembling rauskommt, um einfach auch während der ganzen C Programmierung ein Gefühl dafür zu bekommen. In wichtigen Programmteilen schaue ich auch über das Assembler Listing, um uneffiziente Programmierung im Code aufzudecken. Mir als Anfänger passieren doch immer wieder uneffiziente Dinge, welche mir ohne diese Analyse nicht auffallen würden. Wichtig wird so etwas ja auch wenn eine neue Firmware im Vergleich zu dem was mal ursprünglich vorhanden war "riesen" groß geworden ist und man alles geben muss um es noch auf das Board zu bringen. Daher meine Frage: Gibt es ein gutes Assembler Tutorial für das Discovery? Welches so anfängerfreundlich ist wie das AVR Tutorial? Dabei geht es mir nicht darum, dass jemand selbst ohne Probleme ein hocheffizientes Assembler Programm schreiben kann, sondern Assembler eher lesen kann und ein Gefühl hat für die Dauer unterschiedlicher Operationen. Man sollte einfach schon einmal damit konfrontiert worden sein damit und keine scheu haben bei Problemen in diese Richtung zu schauen. Ich finde übrigens den RX (vom mal drüberschauen der Dokumentation) aber auch den AVR32 (kleine Programmcodeanpassungen) definitiv nicht schlecht im vergleich zu ARM, allerdings ist bei letzterem der Einstieg doch günstiger finde ich. Auch wenn gerade der AVR32 vom AVR Studio profitiert.
Ach Golem, nen bockiges Kind haben die meisten von uns hin und wieder daheim. Muss es auch hier sein? Danke für deine Einsicht (Ja ich bin ein Optimist ;-) ) @Tutorial, Die Tutorial beziehen sich ja nicht auf den Kern alleine, sondern Hersteller & Kern. So Findet man auch beim einfachen, weniger komplexen 8051er Tutorials auch eine Menge verscheidener, je nachdem mit welchem 51 man nun loslegen will. Für ARM gilt das Gleiche. Auf den entsprechenden Support-Foren des Herstellers zur Serie finden sich meist ausgezeichnete Tutorials. Sowie auf von privaten betriebenen dem ARM gewidmeten Seiten. Ausgezeichnet für jugendliche / junggeblieben Anfänger eignen sich zum Beispiel die vielen Tutorial zum ARM auf dem GBA inklusive der Peripherie dort. Assembler ist für ARM wirklich simpel. 14 Instruktionen. Splittet man "Data Processing" nochmal eigenständig auf dann sinds 29. Bei Thumb/Thumb2 wirds dann etwas stärker verfeinert, aber nicht schwer.
Der Unwissende schrieb: > Gibt es ein gutes Assembler Tutorial für das Discovery? Du meinst wohl ein Tutorial für ARM-Assembler. Muß mal suchen, nach Plättung meines Rechners wurden auch die Favoriten mit geplättet. Vielleicht hab ichs noch irgendwo. Auf jeden Fall Chinesen und Koreaner.
Falls jemand auf der Suche nach einem deutschen Tutorium ist. Ich finde dieses hier sehr hilfreich. http://diller-technologies.de/stm32_wide.html
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.