ARM: kompliziert?

Hauptsächlich die Hardware rund um den ARM.  Die ist bei jedem 
Mikrocontroller anders, und scheint meist haarsträubend umständlich zu 
sein.

Dann werden ARM Controller auch noch meistens in C programmiert, was 
bedeutet, dass Du Dich erst mal mit Dingen wie Linker-Skripten 
auseinandersetzen musst, falls das noch nicht jemand für den konkreten 
Controller gemacht hat.

Wenn Du wirklich Rechenleistung brauchst, nimm einen Raspberry Pi oder 
so was, und mach hardwarenahe Sachen in einem extra Controller den Du 
per UART ansteuerst. Das ist einfacher, wenn Du schon Erfahrung mit 
unixoiden Systemen hast.

Christian Berger schrieb:
> Dann werden ARM Controller auch noch meistens in C programmiert, was
> bedeutet, dass Du Dich erst mal mit Dingen wie Linker-Skripten
> auseinandersetzen musst, falls das noch nicht jemand für den konkreten
> Controller gemacht hat.

Und andere Controller werden nicht in C programmiert? ^^

Wenn du es einfach haben willst nimm einen mbed. Einfacher kann man es 
nicht haben. Ansonsten ist die NXP Entwicklungsumgebung auch nicht 
kompliziert. Installieren, programmieren, flashen. Da gibts dann z.B. 
die LPCXpresso Boards für kleines Geld.

Sind sie doch gar nicht.

Ich musste mich letztes Semester mit CAN beschäftigen. Da hat sich die 
Frage gestellt, welchen Controller ich nehme, um mit CAN etwas 
herumzuexperimentieren. Erst wollte ich das Board von Olimex mit AT90CAN 
drauf nehmen. Dann bin ich auf das STM32F4 DISCOVERY board gestoßen.

Das Board kostete weniger und hatte sogar ein Beschleunigungssensor 
drauf, also hab ich es genommen. Nach einer  zweitägigen Suchen nach 
einer guten IDE, habe ich die von CooCox genommen (CoIDE ist perfekt, 
mittlerweile gibt es sogar die kompletten Libs auch für Cortex M4 
integriert) Nach einem Einarbeitungstag habe ich bereites UART und CAN 
am Laufen, zwar nicht Interrupt gesteuert, aber immer hin.

Ich finde, dass man mit den fertigen Libs von STM sehr gut arbeiten kann 
und man kommt auch schnell zu einem Ergebnis.

Christian Berger schrieb:
> Hauptsächlich die Hardware rund um den ARM.  Die ist bei jedem
> Mikrocontroller anders, und scheint meist haarsträubend umständlich zu
> sein.
>
> Dann werden ARM Controller auch noch meistens in C programmiert, was
> bedeutet, dass Du Dich erst mal mit Dingen wie Linker-Skripten
> auseinandersetzen musst, falls das noch nicht jemand für den konkreten
> Controller gemacht hat.
>
> Wenn Du wirklich Rechenleistung brauchst, nimm einen Raspberry Pi oder
> so was, und mach hardwarenahe Sachen in einem extra Controller den Du
> per UART ansteuerst. Das ist einfacher, wenn Du schon Erfahrung mit
> unixoiden Systemen hast.

Selten so einen Bullshit gelesen.

Piet schrieb:
> Hallo,
>
> bei der Suche nach einer leistungsfähigeren Alternative zu AVR ATMegas
> bin ich oft auf die Aussage gestossen, dass ARM prozessoren
> "kompliziert" seinen und "für Anfänger ungeeignet".
>
> Was macht ARMs denn so kompliziert?
>
> Grüsse
> Piet

Wenn man sich wirklich von Anfang an mit Startup und Linkerscripten 
beschäftigt, dauert es lange bis wirklich alles läuft. Verwendet man 
dagegen fertige Pakete (Ich habe mit LPCXpresso angefangen) kommt man 
mit den modernen Cortex MUCs min. genauso schnell wie mit dem AVR ans 
Ziel. Die Perepherie habe ich schnell gelernt in dem ich die 
mitgelieferten Libs und das User Manual studiert habe. Wenn man alles 
halbwegs beherrscht, dann kann man immer noch anfangen Startup und 
Linkerscripte anzupassen.

Großer Vorteil ist halt das mit den LPCXpressos und den 
STMDiscoveryboards und evtl. auch mit dem neuen TI Launchpad, gleich 
einen ordentlichen Debugger mitkommt. Das vereinfacht imho den start 
enorm.

MCUA schrieb:
> Der ARM-Befehlssatz wurde zwar immer etwas verbessert,
> ist aber im Grunde schon uralt, und veraltet.

Stimmt, der native ARM-Mode hat ein paar Fehler. Aber ist das für 
C-Programme soo wichtig? Zumal man heute eher die Cortex-M Geräte in 
ihrem Thumb2-Mode anpeilt, und für die gilt das nicht.

Nimm dir n Cortex-M3, und schau dir CMSIS an. Dort wird dafür gesorgt, 
dass du bei main() anfangen kannst, zu programmieren, wie du das vom AVR 
her gewohnt bist.

Wichtig ist nur, dass du die Peripherals (UART zB) vorher einschaltest 
(bei STM war das glaub ich APB2ENR), sonst werden die aus 
Stromspargründen nicht geclockt und du landest ggf. im Hard Fault.

Die CMSIS hilft dir auch bei der config des Interrupt Controllers 
(NVIC), siehe dazu core_cm3.h

Willst du einen vernünftigen JTAG/SW Debugger, mit dem du flexibel bist, 
dann kaufe dir von Segger den JLink Edu (rund 50,-), dann kannst du mit 
sämtlichen GNU's, Keil MDK, IAR und sonstigen spielen.

Meine persönlichen Lieblinge sind der STM32F103ZE (Keil MCBSTM32E) und 
der LPC1768 (Keil MCB1700), mit MDK/RL-ARM und ULINK pro :-)


VG,
/th.

Lothar schrieb:
> ARM ist sogar einfacher als AVR :-)

Das sagt doch keiner!!! Ich meine aber, dass man nach auch mit einem ARM 
- anfangen könnte, weil es nicht so viel komplizierter ist.

Man hat ja wie gesagt, gut aufbereitete Bibliotheken zur Ansteuerung der 
Peripherie. Man muss nur die Dokus der Bib's sich gut anschauen und dann 
geht es.

Wo ich letztes Semester mit ARM anfing, haben mich die Bib's irgend wie 
an Arduino Zeugs erinnert.

Ach ja genau, wenn wir schon von einem sehr einfachen einstieg reden, 
dann sind die Arduinos meiner Meinung nach eine sehr gute Wahl.

Die sind in Deutschland zwar etwas teuer, aber wenn man über 
www.aliexpress.com/ aus China bestellt, dann nicht mehr. Da gibt es auch 
viel dazu passende Sensoren, Displays und so weiter.

Ich war bis vor einen Jahr noch gelegentlicher Bascom Programmierer und 
beschäftige mich nun schon lange mit ARM, speziell mit STM32F4.

Was das umsteigen wirklich "schwer" macht ist:

1. Die Frage womit Programmieren. Denn die Beispiele von ST sind 
ausschließlich nur mit sehr teuren IDE sofort lauffähig. Es sei denn man 
benutzt eine Kickstart Version die auf 32K beschränkt ist.

2. Die Libs sind sehr aufgebläht und man braucht lange um da überhaupt 
mal durch zu blicken.

3. Es gibt kein wirklich gutes Buch was einen Schritt für Schritt da 
heran führt. Schon gar nicht in Deutsch.

Aber was es WIRKLICH schwer macht.

Man will am Anfang immer viel zu viel.

Mein Fazit. Fange nicht mit ARM an weil du eine Lösung suchst, sonder 
einfach nur um ARM zu lernen.

Ich würde mir an deiner Stelle ein STM32F4Discovery besorgen. Kostet 
keine 20 Euro. Wenn du danach googlest wirst du vieles dazu finden.

Dann als IDE die Cocoox IDE herunter laden und damit anfangen.Braucht 
nicht erst umständlich eingerichtet werden wie Eclipse. Kostet nichts, 
wird weiter entwickelt. Unterstützt viele Hersteller.


Gruß

Jörg

.

Jörg B. schrieb:
>
> Mein Fazit. Fange nicht mit ARM an weil du eine Lösung suchst, sonder
> einfach nur um ARM zu lernen.
>
> Ich würde mir an deiner Stelle ein STM32F4Discovery besorgen. Kostet
> keine 20 Euro. Wenn du danach googlest wirst du vieles dazu finden.
>
> Dann als IDE die Cocoox IDE herunter laden und damit anfangen.Braucht
> nicht erst umständlich eingerichtet werden wie Eclipse. Kostet nichts,
> wird weiter entwickelt. Unterstützt viele Hersteller.


Das ist mal eine richtig gute Empfehlung!!!Würde ich so sofort 
unterschreiben!!

Genau Suberversionskontrolle ist genau das was ein Anfänger braucht. 
Genauso wie WIFI 3D-ADCs usw. :D

Atmel Studio ist zwar eine prima Sache. Sehr Modern und komfortabel weil 
es auf Visual Studio aufsetzt. ABER man ist dann wieder auf einen 
Hersteller festgelegt.

@ OP: Dieselbe Frage stellte ich mir vor ein paar Monaten auch :-)

Ich habe mir damals auch das STM32F4DISCOVERY gekauft und mir Eclipse 
passend eingerichtet (wir verwenden hier ausschließlich Linux). Dafür 
gibt es auch passende Tutorien.

Die Einarbeitung ist nicht sooo schwer und auch nicht so dramatisch 
anders als bei AVRs.

Wichtig ist, dass man langsam anfängt: also erstmal LED blinken lassen, 
die Fähigkeiten der Ports kennenlernen, dann vielleicht mal einen Timer 
programmieren usw. - und irgendwann mal die "hohen Weihen" DMA etc.

Für mich waren die STM-Libs sehr hilfreich - andere verfluchen sie ;-)

Linkerskripte sind nicht dramatisch - das macht Eclipse automatisch 
(wenn man die Anleitungen befolgt :-), so dass man schnell 
Erfolgserlebnisse hat.

Wenn Du etwas mehr Geld ausgeben möchtest/kannst: wir haben uns dieses 
Set hier für etwa 107 Euro bestellt - da ist ein STM32F4DISCOVERY mit 
dabei, dazu eine Menge Module, um nach Herzenslust zu testen und zu 
basteln:

http://www.wvshare.com/product/Open407V-D-Package-B.htm

Die gibt es übrigens auch bei ebay.

Es gab hier auch neulich einen Thread, wo jemand diese Module benutzte:
Beitrag "STM32F4 overclocken"

Chris D.

Wilhelm Ferkes schrieb:
> Teils 2 Befehle, wofür
> man beim 8051 eine Riesen-Schlange Code generieren muß.

Geht aber auch umgekehrt, z.B. 8051: "MOV P1.3, C".
Lade atomar einen IO-Pin mit dem Carry-Bit.
Das dürfte den ARM ne Menge Befehle kosten.

Es gibt nicht die CPU für alles.
Steueraufgaben lassen sich mit 8Bittern oft erheblich einfacher lösen.


Peter

Tja, also ich hab mich vor Kurzem auch mal in die ARM Richtung begeben.

Ich hab eigentlich von 0 auf fast 100% an einem Tag geschafft.
Benutzt habe ich
* Codesourcery G++ Lite von Mentor
  Hier steckt der ARM-Compiler drin und diverse Tools (heißt alles
  zusammen "Toolchain") drin, die für das Bauen von Binaries für ARM
  Prozessoren notwendig sind. Das heißt hiermit lassen sich Binaries für
  alle üblichen ARM Prozessoren erzeugen.
  Diese Toolchain wird dabei ganz gut von "Mentor" gepflegt und ist sehr
  aktuell

* Eclipse mit CDT Plugin für C/C++ Entwicklung
  Hier hackst du den Code ein, statt Eclipse könnte man theoretisch auch
  einen normalen Texteditor nehmen.

* GNUARM Plugin für Eclipse
  Hier wird Eclipse dann praktisch. Mit dem Plugin kann man gängige ARM
  Toolchains in Eclipse einbinden und hat für Compileroptionen und Co
  dann eine grafische Oberfläche

* OpenOCD als Programmiertool
  Hiermit wird das Binary auf den ARM übertragen.

Das "schwierigste" war Linkerscripts und Startup Code zu schreiben. Hier 
gibts im Gegensatz zu den AVRs nichts fertiges, sondern man muss für 
jedes Projekt ein neues Linkerscript basteln, bzw. ein bestehendes auf 
die Eigenschaften des neuen Prozessors abändern.
Man bekommt jedoch bei den Chipherstellern üblicherweise Pakete mit 
Scripts drin, die man dann als Vorlage nehmen kann.

Ich muss aber auch gleich Vorweg sagen, dass ich nicht vor habe 
irgendwelche Libraries von den Chipherstellern zu benutzen (in meinem 
Falle war das die STM32 StdPeriph Library). Diese sind öfter mal buggy 
und schlecht zu durchschauen.
Ich programmiere lieber mit dem CMSIS Headerfile zu dem entsprechenden 
Chip (Das Pendant zu <avr/io.h>) und dann weiter auf Registerebene nach 
Datenblatt.

Nimm doch lieber ein bekannteres Board..

Und wieder eine Runde RISC-CISC Fight. Ich dachte, das hätte sich in 
mittlerweile 2,5 Jahrzehnten langsam gelegt. ;-)

Wieviele Prozent eines Controller-Programms von beispielsweise 50KB 
(optimierter) Grösse machen komplexe Bit-I/O? Und wird das absolut 
gemessen mehr, wenn das Programm weiter wächst?

Wilhelm Ferkes schrieb:
> Dummerweise hat der ja für
> den Einzelbitprozessor nicht den XRL-Befehl, man mußte die Verknüpfung
> mit ANL und ORL und Negierungen schrittweise machen.

Hab ich noch nie so probiert. Ich machs immer auf die einfache Art ("jnb 
BIT1", "cpl BIT2").

Wilhelm Ferkes schrieb:
> Zur Zeit plage ich mich in Assembler selbst noch mit so einer alten
> Mühle mit 4k EPROM.

Inzwischen haben viele 8051 ja 64kB Flash. Mein größtes C-Programm 
braucht auch nur 40kB (seit 1995 gewachsen). Damals war es ein 80C652 + 
extern EPROM, SRAM, jetzt ist es ein AT89C51RE2.


Was mich am ARM7 stört, sind diese umständlichen SET- und 
CLEAR-Register.
Beim Cortex M3 soll man das ja nicht mehr benötigen, der kann ein oder 
mehrere IO-Bits gleichzeitig ändern.


Peter

Peter Dannegger schrieb:
> Beim Cortex M3 soll man das ja nicht mehr benötigen, der kann ein oder
> mehrere IO-Bits gleichzeitig ändern.

Mit dem ARM Bitbanding des Cortex M3 geht immer nur 1 Bit auf 
einmal. Für mehrere Bits gleichzeitig wirds wieder herstellerspezifisch. 
NXP verwendet ein Maskenregister, ST kombiniert 16 Set- und 16 
Reset-Bits in einem 32-Bit Register, bei den LM3 werden 8 Bits aus der 
Adresse als Maske verwendet. So können mehrere Bits gleichzeitig auf 
beliebige Werte gesetzt werden.

Wilhelm Ferkes schrieb:

> Sowas sollte ich mir echt mal zu Weihnachten gönnen, wenn auch
> Selbstbeschenkung. ;-)

Mach das!
Besorgt Dir ein STM32F4DISCOVERY. RS bietet die für 12,xx netto an.

Wenn Du schon Controller programmiert hast, dann sollte der Einstieg 
nicht allzu schwer fallen.

Häng Dich da rein, Du hast doch die Zeit.

Und dann bietest Du Deine Dienste als STM32-Spezialist an.

Gute Leute in dem Bereich werden gesucht.

Chris D.

Die gibts auch bei Watterott. Ide: CooCox.

Wilhelm Ferkes schrieb:
> A. K. schrieb:
>
>> NXP verwendet ein Maskenregister,
>
> Bei den LPC2000 konnte man wohl IOPIN direkt lesen und beschreiben. Aber
> ich muß das nachschauen, weil länger her.

Klar, aber das bringt nichts ein, weil man nur selten 32 Bits 
gleichzeitig setzen will und für partielle Modifikation getrennte Loaad 
und Store-Befehle braucht - was in Verbindung mit Interrupts arg 
ungünstig ist.

Ausserdem besteht der Sinn dieser Methoden auch darin, beispielsweise 4 
LCD-Bits in einem Rutsch definieren zu können, auch wenn sowohl 0 wie 1 
drin vorkommt.

Wilhelm Ferkes schrieb:

> Danke, Chris. Das Hobby und die Materie kann mir nichts und niemand
> vergällen, und es macht mir wieder Spaß.

Siehste. Mach es wie ich und Dein Hobby zum Beruf :-)

> Ich war ja schon total auf Null
> abgesackt, und fast reif für unter die Erde. Bei augenblicklicher
> Gesundheitsstörungen, wo erwerbsmäßig so gut wie nichts läuft. Ich war
> heute beim Hartz-Amt, und die Beraterin weiß bei allen ungeklärten
> Gesundheitsumständen im Augenblick überhaupt nichts mit mir anzufangen,
> verschob einfach die Dinge auf einen neuen Termin in ein paar Monaten.
> Wenigstens war das Gespräch dort fair und freundlich. Wer weiß? Ich bin
> gerade dabei, zu lernen, daß Zukunftsdenken nicht alles ist, aber noch
> einiges sein kann.

Eben. Man sollte schon auch jetzt leben, aber warum nicht mal zu neuen 
Ufern aufbrechen? So etwas wirkt sich übrigens auch durchaus positiv auf 
die Gesundheit aus.

> Allerdings, bei dem schönen STM32-Board fehlt mir sicher wieder eine
> relativ unlimitierte Entwicklungsumgebung, wenn ich keine Vollversion
> für 3000€ kaufen will.

Wir arbeiten uns gerade unter GNU-GCC-GDB/Eclipse ein - das kostet Dich 
nur das Durchlesen der Tutorien im Netz und Einarbeitung.

Ansonsten benötigst Du wirklich keine finanziellen Mittel.

> Bezahlen kann ich teuere Tools im Augenblick
> nicht. Und: Bekomme ich bei RS was als Privatmann?

Das war nur ein preisliches Beispiel. Es dürfte noch andere Anbieter in 
ähnlicher Preislage geben. Ansonsten hat hier im Markt neulich jemand 
diese Boards günstig verkauft.

Steckbrett und Strippen für eigene Aufbauten wirst Du ja haben.
Ansonsten: Dealextreme - sehr preiswert und passable Verbinder.

> Sonst hatte ich immer mal die Olimex-Boards im Auge, z.B. hier aus dem
> Forums-Shop. Sie sind erheblich günstiger als beispielsweise ein Keil
> MCB2100.

Wie auch immer. Hauptsache, Du unternimmst etwas.

Dann schreibst Du ein schönes Tutorium über den STM32, wie man mit dem 
GDB debuggen kann, mit guten Beispielen, erklärst die Takterzeugung, wie 
man die für Timer berechnet, wie DMA funktioniert usw. und baust Dir 
daraus eine ordentliche Homepage.

Dann schreibst Du Abstraktionsbibliotheken z.B. für Grafikerzeugung und 
setzt Dich vielleicht mit einem RTOS auf dem STM32 auseinander.

Dazu dann noch "Wilhelms Programmschnipsel", wo jede Woche irgendeine 
einfache pfiffige Routine angeboten wird.

Irgend so etwas eben.

Und ruckzuck hast Du reichlich Leser, die mit Fragen kommen und Hilfe 
benötigen. Und da sind dann auch schnell mal Firmen dabei.

Du wärst nicht der erste, der so zu Projekten und Arbeit kommt.

Finanzieller Aufwand: gleich Null

Chris D.

Was spricht dann gegen ein komplettes Board für den fast gleichen Preis 
des Einzelcontrollers? z.B. Carambola-Board

Uwe Bonnes schrieb:
> Beim AVR zumindesten sind die Register fuer die Bitmanipulations Befehle
> im OPCODE kodiert. Da ist mit "Math" auch nichts

Lass mal. Für ihn ist alles veraltet, was nicht von Renesas stammt.

Abdul K. schrieb:
> Carambola-Board

Das ist doch 1) überhaupt kein ARM und 2) ein SoC um Linux drauf laufen 
zu lassen. Da ist ein Cortex M3 eher näher an AVRs dran, als an einem 
SoC.

Ich begriff die Anfrage einfach eher in Richtung welche neue Plattform 
für kleine Projekte. Der Preis ist jedenfalls kaum zu schlagen. 
Ethernet-Hausbus z.B.

Reinhard Kern schrieb:
> Kann ich mit dem Discovery auch Hard- und Software für eine Steuerung
> mit einem NXP LPC1769 o.Ä. entwickeln, oder sollte man da besser ein Kit
> speziell mit dem gewünschten Prozessor beschaffen?

Nein, lass es. Beide MCs haben zwar einen ARM Kern, aber bei der 
Peripherie kocht jeder Hersteller sein komplett eigenes Süppchen, so das 
selbst ein simpler GPIO bei NXP anders behandelt wird als z.B. bei ST. 
Von Timern und ADCs mal ganz zu schweigen.
Du brauchst ein Board mit einem NXP, am besten ein dem Original sehr 
ähnlichen. Wenn das ein Super-Selbst-Gebritzeltes Echtzeitsystem ist, 
schau dir mal RTOS an, vermutlich haben die Jungs da gekupfert, bzw. 
ganze Blöcke übernommen.

Wilhelm Ferkes schrieb:
> Zur Zeit plage ich mich in Assembler selbst noch mit so einer alten
> Mühle mit 4k EPROM. Zum Wegwerfen ist das Board aber zu schade, es
> funktioniert ja einwandfrei. Und einiges bekommt man mit Assembler schon
> auch in die 4kB hinein.

Willem, ich hab mir damals(tm), als ich mit den 8051/31 ne Menge gemacht 
habe, als erstes ein Board mit 8k EPROM und 8k Static RAM gebaut, wobei 
im EPROM ein trickiger Monitor war, der Programme per Intel HEX ins RAM 
gespielt hat. Eine verbogene Vektortabelle konnte IRQs im RAM ausführen 
und so war es easy, Programmfetzen und -Blöcke zu testen, bevor man sie 
ins Zielsystem geschossen hat.
Ich hab den Monitor mal angehängt, vllt. kann ja jemand was mit 
anfangen. Die Syntax ist allerdings für einen historischen Assembler 
namens A51.exe

Jörg B. schrieb:
> Die Frage womit Programmieren. Denn die Beispiele von ST sind
> ausschließlich nur mit sehr teuren IDE sofort lauffähig. Es sei denn man
> benutzt eine Kickstart Version die auf 32K beschränkt ist.

32K sind für einen Einsteiger doch erstmal genug.
Vorteil davon : Es läuft wunderbar miteinander. Ich muss nicht erst 1000 
Sachen konfigurieren.

Wenn ich "Monitorprogramm" schon höre, dann bekomme ich die Krise. Haben 
damals in der Schule mit Z80s rumgefummelt, die sowas hatten. Zu der 
Zeit war ich aber schon voll in den AVRs mit In-Circuit 
Programming/Debugging drin.

Ein totaler Rückschritt ;-) Die Leute von "damals" tun mir leid. Damals 
war halt nicht alles besser.

MCUA schrieb:
> Schon alleine, dass eine CPU ein bestimmten IO-Bereich überhaupt hat bzw

Hat ARM nicht. Manche ARM-Cores, und zwar nur die Cortex-M, haben 
innerhalb des einen Adressraums festgelegte Bereiche mit bestimmten 
Eigenschaften. Na und?

> ganz bestimmte Befehle nur auf IO anwendbar sind,

Welche wären das?

Ralph schrieb:
> David P. schrieb:
>> 32K sind für einen Einsteiger doch erstmal genug.
>> Vorteil davon : Es läuft wunderbar miteinander. Ich muss nicht erst 1000
>> Sachen konfigurieren.
>
> Und wenn dann die Anwendung etwas größer wird wirft man alles weg, sucht
> sich ne neue IDE und fängt von vorne an. Oder gibt viel Geld aus.

Quatsch. Es geht doch einfach nur darum am Anfang nicht zu viele 
Baustellen gleichzeitig aufzumachen. Sobald man ein lauffähiges Programm 
hat und etwas Erfahrung hat mit dem ARM, kann man ja auch auf eine 
andere Toolchain/IDE umsteigen.

> David P. schrieb:
>>> Die Frage womit Programmieren. Denn die Beispiele von ST sind
>>> ausschließlich nur mit sehr teuren IDE sofort lauffähig. Es sei denn man
>>> benutzt eine Kickstart Version die auf 32K beschrän
>
> Wenn es nicht gerade ST sein mus.
> Sieh die mal die Stellaris Evalboards LM3Sxxx von TI an.
> Kosten zwischen ~50 und 100 €
> Beim Board gibt es einen Jtag Debugger eine komplette unbegrenzte IDE (
> CodeComposerStudio) und ausführliche Libs. Es ist sogar ein freies RTOS
> für den µC dabei.

Komplett unbegrenzt? Totaler Unsinn.
http://processors.wiki.ti.com/index.php/Licensing_-_CCSv4#Free_Licenses

Es gibt eine EVAL License, die kann man zeitbegrenzt nutzen und eine 
Bundle License:
----
We include a free version of CCS with many of our community boards, DSKs 
and EVM (Evaluation Module) kits.  These kits come with a development 
board, software and CCS.  The CCS will only work with the onboard 
emulation on the board.
----

Ganz toll. Ansonsten das Gleiche wie bei jedem Hersteller: Eine komplett 
unbegrenzte IDE kostet ein paar Tausend Dollars.

Simon K. schrieb:
> Ganz toll. Ansonsten das Gleiche wie bei jedem Hersteller: Eine komplett
> unbegrenzte IDE kostet ein paar Tausend Dollars.

Rowley Crossworks: $1500 kommerziell, $150 nichtkommerziell (kein 
Limit).

Fritz schrieb:
> Welche 32-bit Architektur ist deiner Meinung nach dann nicht veraltet?

Aus vergangenen Diskussionen würde ich mal drauf tippen, dass ihm die 
SuperH Familie von Renesas vorschwebt. Eine Architektur, die für 
Controller-Anwendungen gut konstruiert ist.

Ich teile aber nicht den Eindruck, dass der Rest der Welt deshalb 
einpacken und heimgehen sollte, nur weil die SH-2A über umfangreiche 
Möglichkeiten der Einzelbitmanipulation im Speicher verfügen und mehrere 
Registerbanks existieren.

Simon K. schrieb:
> Ganz toll. Ansonsten das Gleiche wie bei jedem Hersteller: Eine komplett
> unbegrenzte IDE kostet ein paar Tausend Dollars.

CoCoox kostet nichts.

Stefan schrieb:
> Bei Renesas sehe ich nur den RX mit Vorteilen gegenüber M0/M3.

Mag sein, ich merke bloss immer wieder, dass MCUA gegen ARM stänkert und 
gewöhnlich irgendwelche Renesas aufgrund irgendwelcher Details der 
Implementierung in den Himmel lobt, ob nun SHx oder RX oder was auch 
immer. Oft mit zweifelhaften Argumenten - ich hoffe ja noch, dass er mal 
erklärt, was er oben mit seinen angeblichen I/O-Befehlen beim ARM meint 
oder weshalb ein Controller keinen I/O-Bereich im Adressraum haben 
sollte.

Kein Controller taugt für alles. Manche sind beim Bitgepfriemel besser 
als ARM, darunter auch die "veralteten" Oldtimer der 51er-Klasse. 
Andererseits kann man mit einem einzigen Entwicklungssystem 
(Compiler/IDE) für ARM eine grosse Zahl verschiedener Controller 
verschiedener Hersteller abdecken. Und manchmal sind ARMs einfach 
kleiner und billiger (Renesas RX in SO20? Cortex-M0 wirkt da passender), 
oder auch viel schneller (Cortex-Ax, wer's braucht).

Jörg B. schrieb:
> Simon K. schrieb:
>> Ganz toll. Ansonsten das Gleiche wie bei jedem Hersteller: Eine komplett
>> unbegrenzte IDE kostet ein paar Tausend Dollars.
>
> CoCoox kostet nichts.

Ist aber auch keine IDE, die von einem Hersteller bereitgestellt wird 
und ist demnach nichts "offizielles". Aber ja, die ist echt nicht 
schlecht und unterstützt ganz schön viele Programmiergeräte.

stm schrieb:
> Es gibt sogar eine Funktion zum automatischen Generieren einer
> Filestruktur inklusive Möglichkeit per Klick entsprechende
> Peripherieelemente einzufügen.
Hmm naja, ich halte da nicht so viel von. Mit dem Hinzufügen der 
Peripherieelemente meinst du sicher die STM StdPeriph Library, die ich 
jedoch nicht verwendete.
Kann man eigentlich das Verwenden dieser Library in der IDE 
deaktivieren, oder funktioniert die nicht ohne?

stm schrieb:
>> CoCoox kostet nichts.
>
> und ist darüber hinaus extrem komfortabel und gespickt mit Beispielen.
> Es gibt sogar eine Funktion zum automatischen Generieren einer
> Filestruktur inklusive Möglichkeit per Klick entsprechende
> Peripherieelemente einzufügen.
>
> Ich habe bis heute nicht verstanden, warum offenbar so wenige Leute
> diese Software nutzen.

Das könnte daran liegen, dass die anderen Leute schon viele IDEs haben 
kommen und gehen sehen - viele sterben plötzlich, weil die Jungs keinen 
Bock mehr haben.

Das ist nervig und bspw. für mich ein Grund, nicht mehr auf solche 
Nischen zu setzen. Eclipse ist da einfach "sicherer".

Dazu kommt, dass ich eine IDE nicht nur für Mikrocontroller sondern auch 
andere Dinge (Tcl/Tk, PHP, usw.) einsetzen möchte.

Und es ist natürlich unschön, dass es nur Win unterstützt. Auch das 
können andere besser.

> Die komplette IDE ist in etwa 15 Minuten eingerichtet und nach einer
> halben Stunde blinkt die LED. Nichts mit stundenlanger Konfiguration
> oder so ;)

Die Einrichtungszeit sollte bei der Wahl einer IDE sehr weit hinten 
stehen. Entscheidend ist, wie gut ich später damit zurecht komme.
Da spielt es dann keine Rolle, ob ich 15 Minuten oder zwei Stunden 
benötige.

Chris D.

Chris D. schrieb:
> Das könnte daran liegen, dass die anderen Leute schon viele IDEs haben
> kommen und gehen sehen - viele sterben plötzlich, weil die Jungs keinen
> Bock mehr haben.
Das war mein Argument oben mit "offizieller IDE" vom Hersteller.

> Das ist nervig und bspw. für mich ein Grund, nicht mehr auf solche
> Nischen zu setzen. Eclipse ist da einfach "sicherer".
Auch wenn CooCox (und viele andere IDEs auf Eclipse basieren): Eben. Ein 
selbst hergerichtetes Eclipse kann man immer wieder neu herrichten, 
falls sich mal irgendeine Änderung ergibt. Bei 3rd Party IDEs ist man 
dann auf das Anpassen der IDE durch den Autor angewiesen.

MCUA schrieb:
> das -mehr oder weniger- abgeändert. (Man muss wohl bezweifeln, ob sie
> überaupt einen 6800 oder 8051 kannten)

... die ultimativen Architekturen damaliger Zeit, verkannt oder 
sträflich missachtet von den Schöpfern der ARM Architektur. ;-)

> irgentwie "keine Intension" etwas Neues zu bauen,

... und deshalb eine Art Architektur schufen, die keinen Vorgänger 
hatte, garnicht anders sein konnte als neu. RISCs fielen damals nicht 
grad vom Baum. John Cockes Erkenntnisse waren bei IBM nach wie vor 
Betriebsgeheimnis, nur Berkeley&Co boten eine ähnliche Entwicklung.

Die Zeit, in der ARM entstand, war eine Zeit, in der Architekturen wie 
VAX aktuell waren. Das war ein dominantes Vorbild vieler Designer, die 
Blüte der CISC-Ära, an die auch NatSemi mit der 32000 und NEC mit der 
V70 anknüpfen wollten. Motorola baute in die 68020 jenen Unsinn ein, den 
sie später aus Coldfire wieder ausbauten. Und Intel versuchte recht 
bald, die misratene iAPX 432 möglichst aus der Geschichte zu streichen.

Damals in den 80ern entstanden parallel zu diesen hochkomplexen Designs 
ein paar einfachere, strukturell neue. Basierend auf der Erkenntnis 
mancher, dass diese Komplexität eher behindert als nützt. ARM war eines 
davon. Bei IBM hatte man immer noch Sorge, die eigenen Mainframes damit 
zu bekämpfen. DEC verhob sich im Laufe der 80er derart an der 
Weiterentwicklung der VAX, dass die Firma daran fast zugrunde ging.

Während sich dann z.B. MIPS darauf konzentrierte, das mit den jeweiligen 
Möglichkeiten schnellste Design zu bauen, hatte Acorn/ARM eher vor, eine 
zeitgemässe für den Zweck ausreichende Leistung mit geringem Aufwand zu 
erreichen. Und entwickelte damit ganz nebenbei eine Architektur, die 
aufgrund ebendieser Einfachheit die erste oder eine der ersten 32-Bit 
Architekturen war, die sich problemlos als Core in Custom Chips einbauen 
liess.

Als ich damals dem ARM2 Familie begegnete fiel mir das auch recht bald 
auf. Nämlich dass dieses Design, obzwar konzipiert als Kern für 
Acorn-Rechner, sich eher noch für leistungsfähige embedded Systems 
eignet, für die 8/16-Bitter zu klein und die anderen 32-Bitter zu gross 
und zu teuer sind.

Natürlich hatte man damals Fehler gemacht. Das Interrupt-Design der ARMs 
(ausser den Cortex-Mx) ist Murks sobald man mehr als die zwei 
Prioritäten benötigt, und die dynamischen Shifts stehen wahlweise dem 
Registerfile oder der Pipeline im Weg.

A. K. schrieb:
> Das Interrupt-Design der ARMs
> (ausser den Cortex-Mx) ist Murks

Stimmt, dessen Entwickler müssen wohl richtig getrieft haben.

Ich glaube nicht, daß es noch andere Architekturen gibt, wo man zwingend 
einen Spurious Interrupt Handler aufsetzen muß, damit es überhaupt 
funktioniert.


Peter

m.n. schrieb:
> Das zeigt meines Erachtens, dass die Entwickler eher rechenintensive
> Anwendungen und keine leistungsfähigen Controller im Auge hatten.

Klar. Das Ding war ja quasi als C64 für Anspruchsvolle gebaut worden. 
Die Nutzung als Controller ergab sich ungewollt.

Peter Dannegger schrieb:
> Ich glaube nicht, daß es noch andere Architekturen gibt, wo man zwingend
> einen Spurious Interrupt Handler aufsetzen muß, damit es überhaupt
> funktioniert.

Spurious Interrupts gibts anderswo auch. Bei PCs landen die dann 
technisch bedingt im niedrigst priorisierten IRQ7, dem für die 
Drucker-Schnittstelle. Jedenfalls früher beim ursprünglichen 
Interrupt-Controller, ob heute noch weiss ich nicht.

Die gibts immer dann, wenn (1) die Auslösung von IRQs nicht gleichzeitig 
auch den Vektor definiert, sondern der erst mit dem Vektor-Zugriff 
festgelegt wird und (2) ein Device so gebaut ist, dass es sich 
nachträglich auch anders überlegen und einen IRQ-Request ggf. wieder 
zurückziehen kann (16C550 mit FIFO).

ARM hatte keinen Interrupt-Controller vorgesehen und damit ist bei 
Verwendung eines separates Moduls (1) vorgegeben.

Das eigentliche Problem auf das ich mich beziehe liegt aber woanders: 
Die Verwendung von R14 des IRQ-Kontextes für die Return-Adresse vom 
Interrupt. Weshalb der IRQ-Stack bei schachtelbaren Interrupts nicht als 
IRQ-Stack verwendet werden kann und man im Handler erst umständlich mit 
R14 und Register-Kontexten rumwurschteln muss. Ein MSR für die 
Exception-Return-Adresse, wie das viele andere RISCs machen, wäre 
sinnvoller gewesen.

MCUA schrieb:
> weshalb
> nur LD/ST übrig bleibt, und es deshalb ein grässlicher Flaschenhals ist.

Der Hauptnachteil ist, daß dadurch fast nichts atomar gemacht werden 
kann und man ständig die Interrupts disablen muß.

Man müßte einfach nur ein Bit im Befehlswort reservieren, das einen 
Befehl mit dem folgenden atomar macht. Damit könnten man bequem mehrere 
IO-Bits manipulieren oder mit Interrupts konsistente Daten austauschen.

Statt der Clear-Register wäre das die weitaus bessere Lösung. Es fehlte 
den ARM-Entwicklern wohl die praktische Erfahrung.


Peter

Peter Dannegger schrieb:
> Man müßte einfach nur ein Bit im Befehlswort reservieren, das einen
> Befehl mit dem folgenden atomar macht.

Präfix-Befehl ist eleganter. Zilogs Z8encore hat sowas fest auf 3 
Befehle fixiert und Microchips 16-Bitter PIC24&Co mit wählbarer Anzahl. 
Der Haken ist die dann eigentlich nötige Unterstützung durch den 
Compiler, also sowas wie
   atomic { ... }

> Statt der Clear-Register wäre das die weitaus bessere Lösung. Es fehlte
> den ARM-Entwicklern wohl die praktische Erfahrung.

Einerseits dies. Es gab damals zwar Systeme mit deutlich höher 
entwickelter Interrupt-Kultur, aber ARM hatte ursprünglich ja auch 
keinen Controller im Auge. Allerdings hätte man das auch später 
hinzufügen können.

Ich habe mir nicht alle Beiträge durchgelesen, also verzeiht bitte wenn 
es schon erwähnt wurde oder am aktuell diskutierten Thema vorbei geht, 
ich nehme nur Bezug auf den Ausgangspost:

Eine 'etwas' leistungsfähigere aber ebenso einfach zu handhabende 
Controllerfamilie sind die MSP430 von TI, das sind 16-bitter die vom 
'feeling' den AVRs in der Entwicklung her sehr ähnlich sind und in der 
Anwendung auch bestimmt nicht komplizierter als die (8-bit) AVRs. Jeder 
der mit einer der beiden Controllerfamilien vertraut ist, sollte sich 
sehr schnell in die jeweils andere einarbeiten können. Für die MSPs gibt 
es, genau wie für die AVRs, eine GCC-Toolchain.
Hardwaretechnisch benötigen sie auch keine kompliziertere Beschaltung 
als die AVRs - einzig zu beachten ist, dass sie mit max. 3.3V laufen, 5V 
ist bei den MSPs nicht. Allerdings benötigen sie auch nur diese eine 
Versorgungsspannung. Achso, und falls das relevant sein sollte: Bis auf 
einige wenige, sehr kleine - was die Ausstattung angeht, Vertreter der 
MSP430-Serie gibt es diese nur in SMD-Gehäusen.
Weiterführende Lektüre und allgemein gute Infos im passenden Artikel:
http://www.mikrocontroller.net/articles/MSP430

Was ansonsten natürlich auch eine leistungsfähigere Version der 
'normalen' AVRs darstellt sind die neuen XMEGA-AVRs und wenn man noch 
mehr Performance benötigt gibt es da noch die AVR32-Serie - doch 
letztere stellen ähnliche Ansprüche an Entwickler und Hardware wie auch 
entsprechende Controller mit ARM-Architektur.

Wenn es allgemein nur um einen Controller eben mit ARM-Architektur geht 
gibt es auch Derivate die in der Entwicklung sehr einfach handzuhaben 
sind; zu nenen sind da wohl an erster Stelle die LPC-Serie von NXP oder 
auch die STM32 von ST (mit letzteren habe ich allerdings keine Erfahrung 
und mit den zu vorletzt erwähnten auch nur begrenzte)

Ich komme aus der AVR Welt und arbeite jetzt seit Mai mit dem STM32F407 
Discovery.

Es gab große Umstiegsschmerzen, aber es hat sich gelohnt. Inzwischen 
arbeitet man mit dem Cortex-M4 genau so einfach und unkompliziert wie 
mit dem AVR.

Die Entwicklungsumgebung CooCox ist free und steht dem AVR-Studio in 
nichts nach. Im Gegenteil, debuggen ist ein Genuss im Gegensatz zum AVR.

Das Discovery F4 kostet 16.77€ und ist günstiger als jedes AVR 
Entwicklerboard. Zudem braucht man da keinen Programmer, weil das 
Discovery alles schon am Board hat. Ein USB Kabel, etwas PC Software und 
gut.


Ich würde niemanden mehr empfehlen mit dem AVR zu beginnen. Der Cortex 
M4 ist wirklich genial!

Thomas Winkler schrieb:
> Ich würde niemanden mehr empfehlen mit dem AVR zu beginnen. Der Cortex
> M4 ist wirklich genial!

Es hängt immer davon ab, was man überhaupt machen will.
Z.B. ein Blinklicht würde ich doch lieber mit nem ATtiny13 machen.

Oftmals will man ne kleine Steuerung aufbauen und hat keine Lust, extra 
für nur ein Stück ein Layout zu entwerfen und eine Platine zu fertigen.
Dann schnell mal eine Uniplatine genommen den ATtiny draufgepappt, 5V 
angelegt und losgeproggt.
Manchmal existiert nichtmal ein Schaltplan. Was an den einzelnen IO-Pins 
dranhängt, ist im h-File beschrieben.

Einen LQFP176 oder UFBGA176+25 möchte ich nicht mehr löten.


Peter

Mal davon abgesehen daß die ARMs millionenfach eingesetzt werden und die
Geräte erstaunlicherweise funktionieren hast du uns immer noch nicht
verraten wer es deiner Meinung nach richtig macht.

Simon K. schrieb:
> Wenn ich "Monitorprogramm" schon höre, dann bekomme ich die Krise. Haben
> damals in der Schule mit Z80s rumgefummelt, die sowas hatten.

Ich redete von 1977-90. Da war noch keine Rede von AVRs oder so. 
State-of-the-Art war der 8048,6502,Z80 und eben der 8051. Und wenn man 
einen Monitor selber schreibt, macht das Spass und du lernst richtig 
was. Eines der genialsten Stückchen Software ist m.E. der in 2kByte 
geschriebene Monitor des Apple ][ von Steve Wozniak. Da können sich 
einige Programmierer mal ne Scheibe von abschneiden, die sowas nicht mal 
in 64 kByte hinkriegen.

überschwenglicher_stm_fan schrieb:
> hier mal ein interessanter Link:
>
> CortexM4-Board von Texas Instruments für 4,7 Euro:
>
> http://de.farnell.com/texas-instruments/ek-lm4f120...
>
> Noch Fragen? ^^

Ich finde es schon interessant.

Weil es günstig ist werden es sich viele kaufen und TI wird es 
sicherlich auf Messen kostenlos verteilen.

Dadurch wird es sicher bald viele nette kleine Anwendungen dafür geben.

Ja, stimmt schon. Habe mir vor kurzem auch ein F1 Discovery Board von 
STM geholt. Bisher immer nur mit AVRs herumgeschustert.

Mittlerweile bin ich über die AVRs auch hinweg. Es gibt einfach zu viele 
Vorteile pro ARM in den Projekten, wo ich sie einsetze.

Mal eine Frage zu den STMs:
Arbeitet man da, wie man es von den AVRs kennt, auf Registerebene mit 
dem Controller oder läuft alles über Libraries des Herstellers?

Sascha W. schrieb:
> Mal eine Frage zu den STMs:
> Arbeitet man da, wie man es von den AVRs kennt, auf Registerebene mit
> dem Controller oder läuft alles über Libraries des Herstellers?

Du kannst natürlich auch direkt auf Registerebene arbeiten (machen auch 
viele). Die vielen Defines in den Headerdateien der Library bilden diese 
nur auf Namen ab, unter denen sich man etwas vorstellen kann :-).

Chris D.

Richtig. Ich habe mit den ST libraries angefangen, da ist alles schön 
überschtlich, verständlich und vorallem portabel (zwischen Cortex M0, 
M1, M3, M4, natürlich nur ST).

Jetzt habe ich ein ziemlich zeitkritisches Projekt und mach es halt 
direkt mit den Registern. Man kann ja ganz einfach in die lib sourcen 
gucken und schauen welche Register verändert werden, wennman zu faul für 
das Datenblatt ist ... ;-)

Die Initialisierung ist ja nicht zeitkritisch, daher mache ich die nach 
wie vor mit den ST libs

Also ich muss sagen, dass ich direkt von Anfang an ohne die StdPeriph 
Lib gearbeitet habe (ist ganz schön schwierig, bis man erstmal raus hat, 
wie man die aus dem Template Projekt "rausoperiert").

Sooo stark vereinfacht die Bibliothek das nun auch nicht. Zeilenmäßig 
wirds zumindest nicht wesentlich weniger im Programm.
Ok, man muss vielleicht nicht mehr so viel ins Datenblatt 
herüberwechseln.

Wie auch immer, kann sich ja zum Glück jeder selbst aussuchen ;-)

Ich habe gerade was zu einer vorkonfigurierten Eclipse Umgebung 
gefunden.

http://forum.chibios.org/phpbb/viewtopic.php?f=13&t=557

Ich verwende CooCox für meinen F4. Bin sehr glücklich damit, und es 
braucht nicht mal 40 Minuten es in Betrieb zu nehmen ...

Schonmal jemand was mit den Nuvoton Cortex M0 gemacht?

Ich hab hier ein NuTiny-SDK-120 rumliegen. Da ist ein Debugger mit dran, 
den kann man abbrechen.

Der Core-Regler ist intern, d.h. man legt nur 2,5 .. 5,5V VDD an.
Die Eingänge vertragen 5V und auch der ADC soll bis UREF = 5V arbeiten 
können.
Im Reset sind die Ports wie beim 8051 weak high, man braucht also keine 
externen Pullups.
Laut Manual werden die Ausgänge von VDD versorgt. Können die wirklich 5V 
liefern?
Das wäre dann ja ein voll 5V fähiger 32Bitter, wow.

Das Atomic-Problem fällt einem auch hier auf die Füße.
Man hat SFRs für einen 16Bit-Port setzen oder nur einen Pin.
Zusätzlich kann man auch ein Maske setzen, um Outputs zu schützen. D.h. 
ein Interrupt kann Pins ändern, und diese Änderungen kann man schützen, 
auch wenn der Interrupt gerade zwischen das Read-Modify-Write zuschlägt.

Mit 128kB Flash und 16kB RAM ist er sehr üppig ausgestattet.
Wie der Verbrauch im Vergleich zu einem 8051 ist, muß ich noch 
ermitteln.

Die Hauptunterschiede des M0 zum M3 sind die fehlende Division und MPU.
Also nichts von Bedeutung.

Ich werde erstmal die 32kB Keil-Demo probieren.


Peter

überschwenglicher_stm_fan schrieb:
> hier mal ein interessanter Link:
>
> CortexM4-Board von Texas Instruments für 4,7 Euro:
>
> http://de.farnell.com/texas-instruments/ek-lm4f120...
>
> Noch Fragen? ^^

Ich habe mir davon welche geordert. Sehr ordentliche Boards. Schön 
klein, 2 User Taster und RGB LED USB . Kann von oben und oder unten was 
drauf gesteckt werden. Für das Geld kann man wohl nicht mehr bekommen 
zur Zeit finde ich!

Ich hab mir auch so TI Dinger (ek-lm4f120) besorgt. Da es Cortex-M4 
sind, habe ich gehofft die sind so wie der STM32F407.

Leider haben die kein SDIO und nur 80MHz.

Trotzdem ist dieser Preis im Moment unschlagbar. Sicher kein Schaden 
wenn man davon ein paar auf Lager hat.

CooCox ist eine IDE, Flashtool und Debugger UI.

Dazu benötigt man eine Toolchain seiner Wahl, das ist bei CooCox nicht 
integriert. Und dann muss man natürlich auch sagen, wo diese Toolchain 
auf der Festplatte zu finden ist.


Dafür ist es kostenlos und unbeschränkt. Ich würde auch mit IAR oder 
sonstwas arbeiten, aber die haben halt Preisvorstellungen, die für einen 
Hobbyisten wie mich astronomisch sind. Da lohnt es sich schon, dass man 
ein paar Dinge selbst installieren muss. :-D

Jedenfalls kann man mit CooCox sehr gut arbeiten, wenn es erst mal 
richtig eingerichtet ist. Es ist schnell, komfortabel und schmiert nicht 
ab.

Ian schrieb:
> Thomas Winkler schrieb:
>> Ich verwende CooCox für meinen F4. Bin sehr glücklich damit, und es
>> braucht nicht mal 40 Minuten es in Betrieb zu nehmen ...
>
> Derart inspiriert habe ich es auch versucht. Mein inneres Timeout hat
> mich wieder davon abgebracht.
> "Build" funktioniert nicht. Ich soll eine gcc toolchain anwählen. Aber
> das Fenster "Select Toolchain Path", in dem diese Anwahl erfolgen soll,
> zeigt mir nicht an, was zu wählen wäre. Zu erahnen ist lediglich, daß
> das Fenster zu klein ist und nicht alles anzeigt. Ein beherzter Klick
> auf ok bringt nichts.
>
> Ich liebe solche Weichware.

Wer lesen kann ist klar im Vorteil. auf der Hauptseite der CoIDE ist ein 
link der es beschreibt.



Download:

Note: This version has not integrated GCC compiler. Before using CoIDE, 
you need to set GCC Toolchain first. Click here to see how to set.
http://www.coocox.org/CoIDE/Compiler_Settings.html



Wenn man denn gar nichts tun will sollte man es doch ganz lassen.
Glaub mal nicht, dass du bei Keil ohne welche Einstellungen dein 
Programm in das Flash bekommst

Peter Dannegger schrieb:
> Ich hab hier ein NuTiny-SDK-120 rumliegen. Da ist ein Debugger mit dran,
> den kann man abbrechen.

Uhm, im Sinne von 'kannste knicken'? :-P Oder ist da eine 
Sollbruchstelle im Board und du kannst den Debug Port entfernen?

Ich hab hier den VL Discovery mit der letzten unbeschränkten Vollversion 
von Atollic TS. Ich ärgere mich zwar mittlerweile, das ich nicht gleich 
den STM32F4 Discovery gekauft hab, aber alles in allem ist das schon 
schön schon - installieren, Manual lesen und losprogrammieren ging 
innerhalb eines Nachmittags. Das Atollic keine HEX files für den 
Programmierer erzeugen wollte war ärgerlich, aber einfach zu lösen.

Matthias Sch. schrieb:
> Oder ist da eine
> Sollbruchstelle im Board und du kannst den Debug Port entfernen?

Ja.
Auf beiden Seiten sind dann 10-pol. Steckverbinder vorgesehen.

http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/IndustrialIC/ARMMicrocontroller/ARMCortexTMM0/PublishingImages/NuTiny-SDK-NUC120.jpg


Peter

Der Unwissende schrieb:
> Sorry, aber was ist mit Speicherzugriffe müssen ausgerichtet sein
> gemeint?

Nicht ausgerichtet sind Wortzugriffe auf Daten, deren Adresse nicht 
durch 4 teilbar ist. Meist ist diese Einschränkung von minderer 
Bedeutung, insbesondere wenn man kein Ethernet verwendet.

> Geht es dabei nur darum das jede Byte Variable nun ein doppel Word (bei
> 32-Bit Architektur) belegt?

Tut sie nicht.

> Ist der Speicher dann eigentlich noch
> Byteweise adressierbar?

Ja.

Der Unwissende schrieb:
> Also geht es darum, dass dann kein Datentyp über 2 Felder liegen sollte,
> z.B. bei 32 Bit ein long auf Adresse 2-5 liegt, da dann ersteinmal 0-3
> geladen werden müsste und danach 4-7 um daraus den Datentyp
> zusammenzubasteln?

Yep. Das ist selten vorteilhaft, weil es selbst bei Architekturen, die 
damit umgehen können, stets langsamer ist als korrekt justiert. 
High-Performance Implementierungen wie x86 kommen besonders schlecht 
damit zurecht.

> Das sollte dann doch auch nicht nur bei den schon genannten ethernet
> headern auftreten, sondern auch wenn alle Optimierungen ausgeschaltet
> sind bei ungünstiger Reihenfolge der Variablendeklaration?

Nein, weil kein Compiler sie so packen wird, wie du das dir vorstellst. 
Er wird ggf. Löcher lassen um das zu vermeiden. Es sei denn du verlangst 
es ausdrücklich über irgendeine Spracherweiterung.

m.n. schrieb:
> Die ARMs (M3/M4) sind schnell mit 1,25 DMIPS/MHz, wobei die mir
> vorliegenden Zahlen dem M0 nur 0,9 DMIPS/MHz zubilligen.
> Die RX sind mit 1,56 DMIPS/MHz schneller.

Aber nur auf den MHz gesehen.  RX210 max 50 MHz =78 Mips  F4 168 MHz 
=210 Mips.

Bei Future.

RX210 100 Pin 64 KB Ram 512KB Flash  6,59€
STM32F4 100 Pin 194 KB Ram 512 KB Flash 6,78€

Für 3 mal soviel Ram und mehr als 2 fachen Durchsatz bin ich dann gerne 
bereit 19 Cent mehr zu zahlen.  ;)

Ich bin ja nicht damit angefangen zu vergleichen... Wollte nur deine 
Aussage, dass der RX210 schneller wäre im Vergleich zum F4, nicht so 
stehen lassen.

Warum sollte der F4 keinen externen Ram unterstützen? Ab 144 Pin tut er 
es.

Und die 3,3 V machen ja wohl den Kohl nicht Fett ;)

So genug gesülzt, schönen Abend noch...

Wer 5V braucht ist sicher gut bedient mit dem RX210. Aber wieso steht 
hier jeder auf 5V? Moderne Technik läuft doch sowieso eher mit 3,3V (SD 
Karten, CPLD, FPGA etc.).

Gut wenn man mit Retro Zeugs rum macht (6502, Z80, TTL) sind die 5V 
praktisch. Aber auch die 3,3V Controller sind da einsetzbar mit etwas 
Beschaltung.

m.n. schrieb:
> Natürlich sind die STM32F4 schöne Teile, wenn es aber um
> Controlleraufgaben geht, bleiben bei mir die RX auf Platz 1.

Dank der agressiven Werbung von ARM und der vielen Anbieter, sehe ich 
leider keine Chance, einen anderen MC durchzusetzen.

Den Flaschenhals, daß alles aus 3 Befehlen besteht (Load, Operation, 
Store) und damit nichts atomar ist, kann man einem Laien nur schwer 
verklickern.

Damit die Zuweisungen nicht zu kryptisch werden, werde ich wohl erstmal 
einige atomare Macros schreiben müssen.
Das Gewürge mit den Set- und Clear-Registern will ich auf keinen Fall im 
Quelltext sehen, das muß irgendwie versteckt werden.
Vielleicht hat ja schon jemand sowas gemacht.


Peter

MCUA schrieb:
>>> Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz.
>>Aber in der Praxis ist das eher WürstchenKäse. Alles in allem ist er,
>>wie gesagt, affenschnell :-)
> Ja, wenn man tolerieren kann/darf, dass ein Affe die 1-Mio-EU-teure
> CNC-Maschine gegen die Wand fährt.

Dann hat der Affe schlecht programmiert :-)

MCUA schrieb:
>>>>> Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz.
>>>>Aber in der Praxis ist das eher WürstchenKäse. Alles in allem ist er,
>>>>wie gesagt, affenschnell :-)
>>> Ja, wenn man tolerieren kann/darf, dass ein Affe die 1-Mio-EU-teure
>>> CNC-Maschine gegen die Wand fährt.
>>Dann hat der Affe schlecht programmiert :-)
> Oder den Jitter nicht beachtet.

Was dasselbe ist.

Wilhelm Ferkes schrieb:
> Matze, soll ich die Bestellung des STM32F4DISCOVERY jetzt doch besser
> bleiben lassen? Ich werde da nach Lesen der Threads allmählich diffuser.
>
> Wollte den eigentlich morgen bestellen. Es sollte nur mit Tools
> funktionieren, die ich nicht kaufen muß. Sonst trete ich das wieder in
> die Tonne.

Lass Dich mal nicht verrückt machen. Das ist eine solide Familie, die 
gerade mit dem F4 eine Menge an Möglichkeiten bietet.
Die "schlimmen" Einschränkungen sind eigentlich keine, wenn man sich 
halbwegs geschickt anstellt.
Gerade mit dem STM32 hab ich bisher gelernt, dass man 99% der 
zeitkritischen Dinge von Timern und DMA erledigen lassen kann, ohne den 
Kern in irgendeiner Weise zu belasten. Interrupts brauche ich fast gar 
nicht mehr (im Gegensatz zum AVR bspw.)

Wichtig ist: Schritt für Schritt einarbeiten - sonst wirst Du erschlagen 
:-)
Chris D.

MCUA schrieb:
> Klar, brauchst für harte Echtzeit-Fähigkeit ja 'nur' den ganzen
> betreffenden Code auf unlineare ASM-Befehle hin abzuklopfen

Wo fangen bei dir harte Echtzeit-Fähigkeiten an? Taktgenaues Timing von 
Pingewackel ist am extremen Ende davon und meistens keine Forderung.

Harte Echtzeit-Bedingungen lassen sich quantifizieren und das muss man 
dann auch in jedem Einzelfall tun. Und folglich in jedem Einzelfall 
entscheiden, welche Lösung die sinnvollere ist. Wer jeden allerkleinsten 
Jitter vermeiden muss, der ist in dieser Controller-Klasse falsch und 
mit CPLDs/FPGAs besser dran (oder beispielsweise XMOS).

Was sind eigentlich nichtlineare Befehle? Wenn du damit alle Befehle 
meinst, deren Laufzeit nicht unverrückbar z.B. 2 Takte beträgt: Je höher 
die Leistungsfähigkeit einer CPU oder eines Controllers, desto variabler 
werden die Befehle. Allein DMA verhagelt schon die exakte 
Reproduzierbarkeit.

Peter Dannegger schrieb:
> Das Gewürge mit den Set- und Clear-Registern will ich auf keinen Fall im
> Quelltext sehen, das muß irgendwie versteckt werden.

Gegen saubere Modularisierung und Layering der Software sprich ja nun 
wirklich nichts. Wer bei nichttrivialen Programmen explizites 
Pingewackel quer durch den ganzen Quelltext streut, der hat meist etwas 
falsch gemacht.

Ich kann allerdings diese Verteufelung solcher Register nicht so recht 
nachvollziehen. Klar, es kann ungewohnt sein. Aber es kann auch 
Möglichkeiten bieten, für die man per Befehlssatz schon hochkomplexe 
Bitfeld-Befehle benötigen würde. Wenn man mehrere Bits eines Ports, aber 
nicht alle, gleichzeitig auf einen beliebigen Wert setzen will.

A. K. schrieb:
> Was sind eigentlich nichtlineare Befehle? Wenn du damit alle Befehle
> meinst, deren Laufzeit nicht unverrückbar z.B. 2 Takte beträgt: Je höher
> die Leistungsfähigkeit einer CPU oder eines Controllers, desto variabler
> werden die Befehle.

PS: So trifft das ebenfalls auf Renesas RX zu.

A. K. schrieb:
> MCUA schrieb:
>> Klar, brauchst für harte Echtzeit-Fähigkeit ja 'nur' den ganzen
>> betreffenden Code auf unlineare ASM-Befehle hin abzuklopfen

Harte Echtzeitfähigkeit heisst erstmal nur, dass etwas definitiv 
innerhalb einer gewissen Zeitspanne reagieren muss - mehr nicht.

> Wo fangen bei dir harte Echtzeit-Fähigkeiten an? Taktgenaues Timing von
> Pingewackel ist am extremen Ende davon und meistens keine Forderung.

So sehe ich das auch. Wenn ich es taktgenau und schnell benötige, dann 
wird das bspw. über Timer erledigt.

> Harte Echtzeit-Bedingungen lassen sich quantifizieren und das muss man
> dann auch in jedem Einzelfall tun. Und folglich in jedem Einzelfall
> entscheiden, welche Lösung die sinnvollere ist. Wer jeden allerkleinsten
> Jitter vermeiden muss, der ist in dieser Controller-Klasse falsch und
> mit CPLDs/FPGAs besser dran (oder beispielsweise XMOS).

Genau so sehe ich das auch. Und gerade bei 1 Mio. teuren Maschinen kommt 
es auf die paar Euro wirklich nicht an. Da wird man kaum einen 
Controller einsetzen, der so hart an seiner Leistungsgrenze eingesetzt 
wird, dass man die Befehle einzeln aussortieren muss.

Dann nimmt man einen FPGA und jemanden, der sich damit auskennt (ich 
nicht) aber sicher keinen Controller, den man totoptimieren muss.
Schon die Arbeitszeit, die man dort reinsteckt, macht das sonst 
unwirtschaftlich.

> Was sind eigentlich nichtlineare Befehle? Wenn du damit alle Befehle
> meinst, deren Laufzeit nicht unverrückbar z.B. 2 Takte beträgt: Je höher
> die Leistungsfähigkeit einer CPU oder eines Controllers, desto variabler
> werden die Befehle. Allein DMA verhagelt schon die exakte
> Reproduzierbarkeit.

Und in 99% der Fälle ist die auch nicht nötig. Wenn sie nötig ist, gibt 
es bessere Lösungen (Timer, FPGA, etc.)

Chris D.

Lass dir das F4 Discovery nicht vermiesen! Der STM32F4 ist einfach nur 
genial. Wenn man aus der AVR Welt kommt, eröffnet sich mit dem F4 eine 
völlig neue, faszinierende Welt!

Richtig, und das discovery passt auch auf das Steckbrett oder 
Lochraster.


Sicher, wenn man vom AVR umsteigt auf den ARM muss man zeit investieren. 
Das ist wohl bei jedem Plattformwechsel so.

Aber ich wage jetzt zu behaupten: sobald man sich die Grundbasis an Code 
geschaffen hat, ist man mit dem F4 Discovery genauso schnell wie mit dem 
AVR. Das gilt natürlich auch für den Renesas oder diesem TI Cortex-M4.


Ich würde jedenfalls nicht mehr auf AVR zurückgehen. Selbst wenn es nur 
eine blinkende LED sein soll, seit es dieses 5€ Board von TI gibt.

Wilhelm Ferkes schrieb:
> Haben die Cortex-M4 eigentlich auch noch diese ARM- und THUMB-Modes mit
> Umschaltung und gemischter Verwendung im Code, wie im LPC2000?

Nein. Nur Thumb. Bei M0 nur Thumb, bei M3 und M4 als Thumb-2, was viele 
Möglichkeiten von ARM zu Thumb hinzufügt und damit den 
Performance-Nachteil aufhebt.

Wilhelm Ferkes schrieb:
> Was bedeutet das jetzt konkret für mich? Keinen 32-bit-Code?

Thumb ist 32-Bit Code, codiert in 16 Bit breiten Befehlen. In Thumb-2 
dürfen sie wieder etwas länger sein, d.h. einige sind in 32 Bits 
codiert. Beipielsweise 3-Adress Operationen mit integriertem Shift und 
die Möglichkeit, in 2 Befehlen eine 32-Bit Konstante zu laden. Auch die 
bedingte Ausführung, ein Alleinstellungsmerkmal der ARM Architektur, ist 
wieder da. Aber diesmal nicht als Teil jedes Befehls, sondern 
codierungmässig günstiger als Präfix, der die Bedingungen von bis zu 4 
Folgebefehlen definiert.

Wilhelm Ferkes schrieb:
> ARM und THUMB hatten doch im ARM7TDMI-S einen Grund, oder? ARM-Code
> direkt in 32 bit geholt ist etwas schneller, und THUMB spart etwas
> Codelänge?

Richtig. Und Thumb-2 ist die Synthese aus beidem. Performance wie ARM, 
Länge wie Thumb. Wenn man ARMs Benchmarks ernst nimmt, dann sogar 
schneller als ARM, weil nach Jahren der Divisionsabstinenz ARM plötzlich 
festgestellt hat, wie wichtig die nur in Thumb-2 existierenden 
Divisionoperationen sind. Und die deshalb viel häufiger als früher in 
den Benchmarks auftauchen. ;-)

ARM7TDMI wurde 1994 definiert, da war interner Flash-Speicher noch nicht 
sonderlich verbreitet. Es gibt allerdings ARM7TDMI Implementierungen, 
deren Flash-Bandbreite für nativen ARM Code nicht ausrecht (Analog 
Devices, Atmel). Bei den LPC2000 war das kein Problem.

Wilhelm Ferkes schrieb:
> Ich kenne es noch anders. Das ist aber schon 5 Jahre her, quasi
> Mittelalter. Thumb erreichte (jetzt grob geschätzt) z.B. um die 70-80%
> Speed gegenüber ARM, dafür brauchte THUMB nur 70-80% Codespeicher
> gegenüber ARM.

Das bezieht sich auf Thumb, ich mich aber auf Thumb-2.

Wilhelm Ferkes schrieb:
> Der Anfänger sollte sich auch erst mal besser mit 8051, PIC, AVR o.ä.
> amüsieren, bis er kein völliger Laie mehr ist.

Wenn man bei Nuviton (ehem. Winbond) nachschaut, wird man erstaunt 
feststellen, daß die nicht nur Cortex M0, sondern auch neue 8051-er im 
Programm haben.
Angefangen vom 12T Klassiker über 6T (Philips), 4T (Dallas) bis zum 
schnellen 1T (Atmel).
Es muß also noch ein bedeutender Markt für die 8051-er existieren.


Peter

Wilhelm Ferkes schrieb:
> Matze, soll ich die Bestellung des STM32F4DISCOVERY jetzt doch besser
> bleiben lassen? Ich werde da nach Lesen der Threads allmählich diffuser.

Nee, nee, das ist schon das richtige. Die VL Dicovery haben den 
STM32F103RB, und der ist im Vergleich zu einem XMega nicht wirklich der 
Bringer, es gab sie halt um die Ecke hier bei Segor, und den STM32F4 
Discovery nicht. Dieser ist deutlich schneller und hat die neuere 
Architektur, und kostet nur ein paar Mäuse mehr. Es lohnt sich also, den 
STM32F4 Discovery zu holen und nicht den VL Discovery (ValueLine).
Mit der Toolchain ist das so eine Sache. Ich hatte vor ein paar Monaten 
noch die Atollic Jungs genommen, weil da alles fertig konfiguriert war 
und sie keine Codebeschränkung hatten. Nun wollen sie Geld und sind 
nicht besser als die anderen. Demnächst muss ich also mal mit CooCox 
oder Eclipse auseinandersetzen, wobei Eclipse wohl die eierlegende 
Wollmilchsau ist und verschiedenste Architekturen und Prozessoren 
unterstützt. Die Konfiguration dauert aber - Internet und eine Menge 
Zeit wird man wohl brauchen. Coocox muss  ich mir mal anschauen, davon 
hab ich null Ahnung.

MCUA schrieb:
> Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz.
> Der schnellste RX (nä. Jahr) mit 200MHz. Ist das jetzt 8 x schneller?
> Nein eher 8..20x schneller, wegen effizienterem OP-Code.

Das ist natürlich kompletter Unsinn. Würde man auf PCs deine 
Interpretationskünste anwenden, dann wären sie heute kaum schneller als 
vor 20 Jahren. Weil demzufolge jeder Befehl 100 oder 200 Takte benötigen 
würde.

Richtig ist nur, dass die Pipeline der RX CPUs effizienter ist als die 
sehr simple Pipeline der ARM7/Cortex-M Cores.

Wilhelm Ferkes schrieb:
> Wegen des schmalen Cores sind die ARM auch energiesparsam. Manch einer
> zieht das ernsthaft als Kriterium heran, ich einst auch mal.

Da wirds etwas komplizierter. Ein kleiner Core frisst weniger Strom. Die 
Frage ist dann, ob man mit einem pro Takt schnelleren Core bei deshalb 
niedrigerem benötigten Takt mehr oder weniger Strom benötigt. Und die RX 
sind unstrittig pro Takt schneller als die Cortex-M.

Die Antwort auf diese Frage hängt nicht zuletzt mit dem verwendeten 
Herstellungsprozess und dessen Designrules zusammen.

Beispiel: Nvidias Tegra 3 hat sichtbar 4 Cores, technisch aber 5. Einer 
davon ist mit low-power Designrules gebaut, mit entsprechend niedriger 
Taktgrenze, die anderen sind auf Performance optimiert. Ist wenig los, 
dann wird auf den low-power Core gewechselt und den anderen 4 wird der 
Strom gekappt. Ohne diesen low-power Core wäre es möglicherweise 
sinnvoller, den Job schneller abzuarbeiten um sich früher wieder 
schlafen legen zu können (Intels Empfehlung für Atom).

Der krasseste Fall war Intels Pentium 4. Dessen Designrules waren so 
sehr auf Performance getrimmt, dass er aufgrund der Leckströme auch 
völlig ohne Takt schon eine aktive Kühlung benötigte.

Wilhelm Ferkes schrieb:
> Chris D. schrieb:
>> Gerade mit dem STM32 hab ich bisher gelernt, dass man 99% der
>> zeitkritischen Dinge von Timern und DMA erledigen lassen kann, ohne den
>> Kern in irgendeiner Weise zu belasten. Interrupts brauche ich fast gar
>> nicht mehr (im Gegensatz zum AVR bspw.)
>
> Oha, sowas ist mir neu. Wie kommt man ohne Interrupts aus? Wenigstens
> Timer betreibt man doch nur im Interrupt. Kannst du das näher erläutern?

Prinzipiell hat man natürlich dieselben Möglichkeiten wie bei den AVRs, 
aber z.B. durch DMA noch deutlich mehr.
Ein Beispiel, welches ich im Moment teste (ich arbeite mich ja selbst 
noch ein :-)

Zwei Audiosignale werden per externem ADC mit je 16 Bit gewandelt und 
per I2S an den STM32F4 geschickt. Gleichzeitig erzeuge ich per Timer 
einen 100ns-Takt, der zwei DMA-Kanäle "befeuert". Der erste Kanal liest 
die gewandelten Werte und speichert sie in je einem Ringpuffer. Der 
zweite Kanal liest an anderer Stelle im Puffer die Daten wieder aus und 
schiebt diese in die internen DACs (die allerdings nur mit 12 Bit 
wandeln). Je nach "Abstand" der schreibenden und lesendenn DMA-Zeiger 
ergibt sich dann eine entsprechende Verzögerung und zwar mit 100ns 
Auflösung.

Das alles funktioniert nach Initialisierung der Module (I2S, DMA, DAC) 
ohne ein Programm im Hintergrund. Der STM32F4 dreht also quasi Daumen 
;-)

So kann man im STM32F4 intern viele "Strippen ziehen": wenn ein Text per 
ausgegeben werden soll, lässt man den UART einfach nach Ende der 
Zeichenübertragung an die DMA senden, dass sie gefälligst das nächste 
schicken soll. Diese macht das und der UART sendet vollautomatisch das 
nächste Zeichen.

Das alles geht komplett ohne Interrupts - und erheblich schneller: 
wie gesagt: der obige Ringpuffer wird mit 10MHz befüllt und gelesen!

Chris D.

@A.K.:
Sehr interessant, Deine Einlassungen zu den Architekturen - lese ich 
immer gerne und mit großem Interesse. Ich spreche sicher auch für 
andere: Bitte mehr :-)

Chris D. schrieb:
> Zwei Audiosignale werden per externem ADC mit je 16 Bit gewandelt und
> per I2S an den STM32F4 geschickt. Gleichzeitig erzeuge ich per Timer
> einen 100ns-Takt, der zwei DMA-Kanäle "befeuert".

Es gibt ja so manche Audiophile, aber mir war bisher noch keiner 
begegnet, der deswegen Audiodaten mit 10MHz abtastet. Selbst bei 
Fledermäusen wär das noch eine Grössenordnung zu schnell. :-)

DMA-Anfänger schrieb:
> Ich habe neulich überlegt ob es möglich wäre einen GPIO-Port per DMA zu
> setzen. Allerdings konnte ich im Datenblatt im entsprechenden
> Request-Mapping keinen GPIO-Port finden.

Der DMA-Kanal wird nicht auf den Port sondern auf den Timer gemappt. 
Weil es dabei um die Auslösung geht. Worauf der Kanal dann konkret 
zugreift, das ist per Adresse frei wählbar, darf also auch ein Port 
sein.

Fast korrekt. Du musst schon die exakte Registeradresse angeben, nicht 
die Basisadresse vom GPIO Registerblock. Also beispielsweise die Adresse 
vom BSRR.

MCUA wird das aber bestimmt nicht imponieren, denn auch DMA ist nicht 
gänzlich frei von Jitter. ;-)

DMA-Anfänger schrieb:
>> MCUA wird das aber bestimmt nicht imponieren, denn auch DMA ist nicht
>> gänzlich frei von Jitter. ;-)
>
> Kannst du das noch ein wenig näher erläutern?

Die Zeit zwischen Ablauf des Timers, also Auslösung des DMA-Kanals, und 
dem Zugriff des Kanals auf das Portregister ist nicht notwendigerweise 
konstant. Je nachdem was zu dem Zeitpunkt der Auslösung grad auf dem Bus 
passiert kann es sich paar Takte verzögern.

Chris D. schrieb:
> Wie auch immer. Hauptsache, Du unternimmst etwas.
>
> Dann schreibst Du ein schönes Tutorium über den STM32, wie man mit dem
> GDB debuggen kann, mit guten Beispielen, erklärst die Takterzeugung, wie
> man die für Timer berechnet, wie DMA funktioniert usw. und baust Dir
> daraus eine ordentliche Homepage.
>
> Dann schreibst Du Abstraktionsbibliotheken z.B. für Grafikerzeugung und
> setzt Dich vielleicht mit einem RTOS auf dem STM32 auseinander.
>
> Dazu dann noch "Wilhelms Programmschnipsel", wo jede Woche irgendeine
> einfache pfiffige Routine angeboten wird.
>
> Irgend so etwas eben.
>
> Und ruckzuck hast Du reichlich Leser, die mit Fragen kommen und Hilfe
> benötigen. Und da sind dann auch schnell mal Firmen dabei.
>
> Du wärst nicht der erste, der so zu Projekten und Arbeit kommt.

Ich melde mich jetzt schon als potentieller Leser an ;-)
Habe mir eben das STM32F4DISCOVERY bestellt und möchte da versuchen 
damit klar zu kommen. Es wird sicher holprig werden der Weg, aber 
machbar ist es auf jedenfall.