Forum: Mikrocontroller und Digitale Elektronik ARM: kompliziert?


von Jörg B. (joerg-sh)


Lesenswert?

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

von Golem (Gast)


Lesenswert?

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.

von Papa ante portas (Gast)


Lesenswert?

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ß.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Golem (Gast)


Lesenswert?

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 :-)

von Wilhelm F. (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Wilhelm F. (Gast)


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von (prx) A. K. (prx)


Lesenswert?

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"

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Thomas W. (diddl)


Lesenswert?

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 ...

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Wilhelm F. (Gast)


Lesenswert?

@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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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).

von Wilhelm F. (Gast)


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

> 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?

von Thomas W. (diddl)


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Von ST gäbe es des STM32F103Tx in VFQFPN36 Gehäuse 6x6mm. Ist kein RX.

von Wilhelm F. (Gast)


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Einen MCP2551 oder PCA82C250 an die entsprechenden Portpins ran löten 
und schon hat das Discovery auch CAN.

von Thomas R. (Gast)


Lesenswert?

...oder den hier.

(Mod.: Anhang pdf entfernt, stattdessen: 
http://www.ti.com/lit/ds/symlink/sn65hvd230.pdf )

von Wilhelm F. (Gast)


Lesenswert?

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.

von Jörg B. (joerg-sh)


Lesenswert?

Wilhelm Ferkes schrieb:
> Schon klar. Aber er ist eben nicht integriert.

Was erwartest du noch für das Geld????

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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.

von Wilhelm F. (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Viel Spass. Herrje, das ist ein Transceiver, keine Peripherie. Schon mal 
einen µC mit integrierter 50V/10A Vollbrücke gesehen?

von Wilhelm F. (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Wilhelm F. (Gast)


Lesenswert?

Wenn die Stromversorgung des µC doch schon galvanisch getrennt ist, wo 
ist denn da bei CAN ein Problem?

von Gerhard O. (gerhard_)


Lesenswert?

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

von Jörg B. (joerg-sh)


Lesenswert?

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.

von Wilhelm F. (Gast)


Lesenswert?

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.

von Wilhelm F. (Gast)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Rene B. (themason) Benutzerseite


Lesenswert?

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 :-))

von temp (Gast)


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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.

von Robert (Gast)


Lesenswert?

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

von Jörg B. (joerg-sh)


Angehängte Dateien:

Lesenswert?

Wer hat dir denn auch Keil empfohlen? Keil ist da etwas umständlich.

Du musst "Programming Algorithm" von Hand hinzufügen. Sie Anhang.

von Jörg B. (joerg-sh)


Lesenswert?

und wichtig, auf SWD einstellen. JTAG unterstützt der Debugger auf dem 
Discovery nicht.

von Golem (Gast)


Lesenswert?

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.

von Jörg B. (joerg-sh)


Lesenswert?

Golem schrieb:
> Das mit ARM,Keil & Co.- eine
> Gruselvorstellung.

So ein Quatsch, mehr fällt mir dazu nicht ein!

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

>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.

von Tante Käthe (Gast)


Lesenswert?

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

von Gerhard O. (gerhard_)


Lesenswert?

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

von Wilhelm F. (Gast)


Lesenswert?

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.

von Gerhard O. (gerhard_)


Lesenswert?

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

von Golem (Gast)


Lesenswert?

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!

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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.

von Maxx (Gast)


Lesenswert?

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.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Wilhelm F. (Gast)


Lesenswert?

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.

von Thomas W. (diddl)


Lesenswert?

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?

von Golem (Gast)


Lesenswert?

Soooo simpel? Selten soooo gelacht :)

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Golem (Gast)


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Ralph (Gast)


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Golem (Gast)


Lesenswert?

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.

von Golem (Gast)


Lesenswert?

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.

von Thomas W. (diddl)


Lesenswert?

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.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Thomas W. (diddl)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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 :-)

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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.

von Moby (Gast)


Lesenswert?

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...

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg B. (joerg-sh)


Lesenswert?

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...

von Wilhelm F. (Gast)


Lesenswert?

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.

von holger (Gast)


Lesenswert?

>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.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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.

von Thomas W. (diddl)


Lesenswert?

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.

von bösewicht (Gast)


Lesenswert?

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 ...

von bösewicht (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

Der Chef zum Entwickler:
"Der Worte sind genug gewechselt, lasst mich auch endlich Daten sehen."

Peter

von bösewicht (Gast)


Lesenswert?

;-)

von Maxx (Gast)


Lesenswert?

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.

von Maxx (Gast)


Lesenswert?

Es sollte im Beispiel beide male AVR heißen. Ich glaub ich muss mich mal 
anmelden ;-)

von Golem (Gast)


Lesenswert?

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 :)

von Stefan (Gast)


Lesenswert?

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

von bösewicht (Gast)


Lesenswert?

mal sehen, wann auch die Letzten bemerken, daß das "Amen" schon längst 
gesprochen wurde ------;

von Pittiplatsch der Achte (Gast)


Lesenswert?

Nee, noch nicht.

ARM: kompliziert? Ja, denn es ginge natürlich auch viel einfacher...

Jetzt aber!

von Wilhelm F. (Gast)


Lesenswert?

Mist. Watterott hat ausverkauft, Lagerbestand Null. Sonst hätte ich 
heute Discovery bestellt. ;-)

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Jetzt hast Du zu lange gewartet ;-)
Wer zu spät kommt, den bestraft das Leben.

von Thomas W. (diddl)


Lesenswert?

MyAVR.de verkauft die zum selben Preis bei günstigerem Versand. ;-)

von Thomas W. (diddl)


Lesenswert?


von stm (Gast)


Lesenswert?


von Michael (Gast)


Lesenswert?

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 ?!

von Maxx (Gast)


Lesenswert?

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.

von Markus (Gast)


Lesenswert?

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

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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.

von Jahat I. (jaib)


Lesenswert?

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ß

von Der Unwissende (Gast)


Lesenswert?

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.

von Maxx (Gast)


Lesenswert?

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.

von Wilhelm F. (Gast)


Lesenswert?

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.

von Jörg B. (joerg-sh)


Lesenswert?

Falls jemand auf der Suche nach einem deutschen Tutorium ist.

Ich finde dieses hier sehr hilfreich.

http://diller-technologies.de/stm32_wide.html

Bitte 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
Noch kein Account? Hier anmelden.