Forum: Mikrocontroller und Digitale Elektronik STM32 für Einsteiger - der Artikel zum Krieg (µC Wahl)


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


Lesenswert?

Hallo,

Es ist Weihnachten und hier kommen derzeit fast Täglich neue Fragen mit 
"Welcher Prozessor ist für mich geeignet".

Wie ja jeder weiß bin ich STM32 Lastig. also habe ich entsprechend 
einen Artikel geschrieben um einen STM32 auch für Einsteiger 
schmackhaft zu machen:

STM32 für Einsteiger

Es soll schlussendlich aufzeigen, dass es zwischen den einzelnen 
Varianten (STM32/AVR/PIC/MSP430/...) doch kein großer Unterschied gibt 
und es eigentlich (bis auf wenige Ausnahmen) kaum Gründe gibt warum man 
nicht mit einem STM32 anfangen sollte.

Ein paar Zitate habe ich aus dem Forum dort mit rein geschrieben und das 
ganze etwas zusammengefasst.

Der Artikel ist natürlich noch nicht komplett, also jeder der was dazu 
beitragen will darf gerne etwas schreiben.

: Bearbeitet durch User
von Dr. Sommer (Gast)


Lesenswert?

Hab mal ein bisschen was dazu geschrieben.

Markus Müller schrieb:
> Es soll schlussendlich aufzeigen, dass es zwischen den einzelnen
> Varianten (STM32/AVR/PIC/MSP430/...) doch kein großer Unterschied gibt
Naja... man braucht nicht zu verstecken, dass die 32bit-Architektur viel 
mächtiger als zB AVR ist, was sich in beqeuemerer Programmierung 
manifestiert...

von Marcus W. (marcusaw)


Lesenswert?

Dein Engagement in ehren, aber ich finde es viel zu einseitig 
beschrieben. Gerade die Vorteile gegenüber dem "AVR" bzw. dem Arduino 
sind heutzutage nichtmehr zutreffend. Viele I/Os, komplexes Timing und 
die Stromsparfunktionien sind auch auf AVRs bzw den damit verstrickten 
Arduinos vorhanden. Als Beispiele würde ich die ATxMega und den 
32Bit-SAM3X8E der sowohl in der AVR- als auch der 32-Bit Welt zuhause 
ist. Außerdem sind beide inzwischen als "Arduinos" verfügbar - es gibt 
entweder den Bootloader oder es gibt die möglichkeit, die entsprechenden 
Klassen bzw. dauch die Arduino-IDE für diese Chipsätze zu benutzen.

Ich liebe den STM32 - der beste µC auf dem Markt, meiner Meinung nach - 
aber man sollte nicht vergessen: Audi baut schöne Autos, Mercedes baut 
schöne Autos - aber auch Opel baut schöne Autos. Und Autos bauen sie 
alle. Egal, welcher der beste Microcontroller für dich ist - jeder hat 
seine vorlieben. Ob einem Arduino-Kenntnisse in der Industrie 
weiterhelfen, wage ich zu bezwifeln - aber niemand würde das behaupten.

von Moby (Gast)


Lesenswert?

Für mindestens 2/3 der Projekte hier reichen 8 Bit / AVR. Für die wär 
was stärkeres nur unnötiger 
Lernaufwand/Einarbeitungszeit/Hard&Softwarekomplexität/ 
Stromverbrauch/Platzbedarf und und und

von Dr. Sommer (Gast)


Lesenswert?

Marcus W. schrieb:
> Dein Engagement in ehren, aber ich finde es viel zu einseitig
> beschrieben. Gerade die Vorteile gegenüber dem "AVR" bzw. dem Arduino
> sind heutzutage nichtmehr zutreffend. Viele I/Os, komplexes Timing und
> die Stromsparfunktionien sind auch auf AVRs bzw den damit verstrickten
> Arduinos vorhanden.
Stromspar bei AVR ja, nichts anderes steht im Artikel. Bei Arduino nur 
dann, wenn man ihn als normalen AVR behandelt... Und die STM32 haben 
mehr und mächtigere Timer.
> Als Beispiele würde ich die ATxMega und den
> 32Bit-SAM3X8E der sowohl in der AVR- als auch der 32-Bit Welt zuhause
> ist.
Xmega und SAM3X8E sind nun mal ganz verschiedene Dinge. Der SAM3X8E ist 
wohl den STM32 ähnlich, aber den AVR (wie Xmega) nun eher nicht.

Dies ist nun mal ein Artikel über STM32, zu den AVR gibts schon jede 
Menge, und wenn du zu Xmega oder SAM3X8E was schreiben willst... nur 
zu...

von Marcus W. (marcusaw)


Lesenswert?

Dann muss ich wohl doch kompletten den Artikel auseinander nehmen. Punkt 
für Punkt:

Eigene Fähigkeiten und Wünsche

Bereits in der Schule Mikrocontroller programmiert: Was, wenn ich in der 
Schule Arduino programmieren lerne?

Neueinsteiger, kaum Elektronikkenntnisse, noch nie programmiert: komm 
ich dann mit der algemeinen Syntax einer Programmiersprache - die ich in 
jedem Fall brauche - klar?

Wunsch ist SD-Card oder Grafik-Display: Beides problemlos im normalen 
Rahmen mit jedem der vier möglich.

Wunsch ist TCP/IP Netzwerk oder Kamera: Ebenfalls möglich - die 
zusatzbeschaltung lassen wir mal Außen vor.

Möchte die Erkenntnisse beruflich nutzen: Muss ich alle vier kennen - 
Oder ich such mir nen Betrieb, der ausschließlich STM32 benutzt.

Extrem stromsparende Mini-Anwendung: Gibt es ebenfalls bei allen vieren.

Experimentieren mit Multithreading, RTOS, Schedulern: Mag sein, dass der 
STM32 da mächtiger ist - heißt aber nicht, dass die anderen es nicht 
auch beherrschen würden.

Große, komplex strukturierte Programme: kann ich sogar mit dem Arduino 
erreichen - Bullshit.

Viel I/O, PWM, komplexes Timing: schafft man ebenfalls mit allen.



Unwichtige Randbedingungen
Spannungsversorgung 3,3V / 5V : Davon weiß kein Anfänger - schau mal in 
den Foren nach, wieso die verschiedenen "Shields" nicht einfach 
funktionieren können.

8 (z.B. AVR), 16 (z.B. MSP430) oder 32 (z.B. STM32) Bit: Interessiert 
keinen Anfänger - 2/3 der Arduino-Jünger wissen noch nicht mal wieviel 
Bits Adressbus die LED zum leuchten bringen.

Interrupt System mit mehr oder weniger Features: Mag ein Grund sein - 
aber ein Anfänger entscheidet nicht nach Anzahl Interrupts. Interrupts 
haben alle.

Programmiersprache (Assembler, Basic, C, C++, Pascal): ASM und 
C-Compiler gibt es auf allen vieren.

Assembler verstehen (Sollte nur theoretisch verstanden werden, ein 
Programm sollte in einer Hochsprache geschrieben sein): Muss niemand 
mehr können - siehe letzte Frage.

DIL Gehäuse - steckbretttauglich (STM32-Prozessoren gibt es auch fertig 
gelötet auf einem steckbretttauglichen Board): Das Internet ist voll von 
Breakout-Boards für alle Typen - willst du DIL, bekommst du es.

Programmieradapter: Als Anfänger einer Plattform fange ich mit nem 
Eval-Board an - Programmieradapter inbegrifen.


Kosten
Demo-Board: Also eval-Board: Ein Arduino z.B. ist nichts anderes. Gibt 
es als Klon (ist ja OS) ab etwa 3,50€ in ebay.

Steckbrettaugliches Board: sind die wenigsten. Kein grund.

Programmieradapter mit Debugger: Debugger ist sehr fein - würde auch 
vielen Anfängern helfen. Gibts aber nicht von der Stange - jeder der 
sich erstmal reingefuchst hat, weiß, was er suchen muss...


Programmierumgebungen
CooCox
Atmel-Studio
MPLab
??
arduino 1.0.5

Ist das wirklich alles, was du kennst? jeder kann sich seine Toolchain 
selbst aussuchen - dassind lediglich die Programme, die mkitgeliefert 
oder empfohlen werden.




Soll ich weiter machen?

: Bearbeitet durch User
von WsucraM (Gast)


Lesenswert?

Marcus W. schrieb:
> Soll ich weiter machen?

Ja, schreibe deinen eigenen Artikel.

von Marcus W. (marcusaw)


Lesenswert?

@ Dr. Sommer: der SAM3X8E unterstützt allerdings den gesammten 
AVR-Befehlssatz. Kann also alles des AVRs und noch mehr.


Nochmal :
Ich will nicht die Leistung und das Engagement vom TO schmälern - ich 
finde es gut, dass sich jemand die Mühe macht. Allerdings sollte man 
keine falschen Fakten als Wahrheit präsentieren - gerade dann, wenn die 
wiederlegten Informationen u.A. auf genau der Selben Seite zu finden 
sind.

Was soll man als Fachfremder denn denken? Ist der STM32 jetzt der 
bessere Arduino oder nicht? Kann ein PIC überhaupt in irgendwas gegen 
den STM anstinken? etc.etc.

Objektivität ist das Stichwort.

: Bearbeitet durch User
von halli (Gast)


Lesenswert?

Also ich bin ausgesprochener STM32-Fan, aber den Artikel finde ich 
schlecht. Eigentlich bin ich auch dagegen zu löschen, aber dieser 
Artikel sollte besser so nicht bestehen bleiben. Wenigstens sollte die 
Überschrift geändert werden.

Nimm einfach mal die ganzen unsachlichen, teilweise emotionalen Passagen 
aus dem Text und schau bitte dann, was dann noch an Informationsgehalt 
übrig bleibt. Eigentlich nur eine Gegenüberstellung.

Die Überschrift des Artikels lässt einem zunächst glauben, dass ein 
Einstieg in die STM32-Welt behandelt wird.

Nichts für ungut.

von ST32Anwender (Gast)


Lesenswert?

ATMEL (insbes. AVR und XMEGA) ist in größeren Firmen nicht gerne gesehen 
Preis/Leistung ist bescheiden. STM32 mit 64kB Flash gibt es zu 40% des 
Preises eines AVRs mit 16kB Flash (hohe Stückzahlen >100k/Jahr)

Von fehlendem DMA, CRC-Einheit, mächtigeren Timern und 32 Bit mal ganz 
abgesehen!

Ich weis nicht wie lange sich ATMEl auf dem Markt noch halten kann. 
Irgendwann werden die ganzen alten Firmenprodukte auslaufen und dieser 
Markt wird wegbrechen. Von den par Bastlern werden die sich nicht lange 
halten können.

Geht daher lieber gleich auf den Industriestandard. Wenn es ST mal 
schlecht gehen sollte wird halt Samsung, NXP, freescale,... genommen. 
Durch CMSIS und den gleichen Tools/Core werden die Rechner besser 
austauschbar und verständlich was sich dann halt auch im Preis 
niedergeschlagen hat.
Ich persönlich finde ST hat sehr gute Peripherie zu einem ordentlichen 
Preis (und ist dabei noch ein europäisches Unternehmen!).

von Carsten S. (dg3ycs)


Lesenswert?

ST32Anwender schrieb:

Praktisch NUR Schwachsinn!!!


> ATMEL (insbes. AVR und XMEGA) ist in größeren Firmen nicht gerne gesehen
> Preis/Leistung ist bescheiden. STM32 mit 64kB Flash gibt es zu 40% des
> Preises eines AVRs mit 16kB Flash (hohe Stückzahlen >100k/Jahr)

Das ATEML in größeren Firmen nicht gerne gesehen ist halte ich mal für 
ein Gerücht. Atmel ist nach der aktuellsten mir bekannten Liste (OK, 
etwas über ein Jahr alt...) ja auch nur der drittgrößte 
Microcontrollerhersteller nach Renesas und Freescale.
(Microchip ist hauchdünn hinter Atmel auf Platz vier)

STM kommt noch HINTER NXP (Platz 8) erst auf Platz 9.
Wie gesagt in Marktanteilen der µC Sparte des Konzerns Weltweit.
Wenn man Automative und Smartcards herausrechnet sind Atmel und 
Microchip sogar auf Platz 2 & 3, Freescale rutscht auf Platz vier und 
NXP verschwindet sogar aus den Top 10.

Den Unterschied machen bestimmt nicht nur ein paar Bastler und 
ALtprodukte, zumal der Umsatz von Atmel, Microchip usw. zuletzt 
GESTIEGEN ist während die ach so fortschrittlichen Firmen wie STM, NXP 
im trotz Weltweitem Wachstum im 32Bit Microcontrollersegment sogar 
VERLUSTE hinnehmen musst. Wenn man die Automotive Industrie 
herausklammert hat STM sogar einen Umsatzeinbruch in der µC Sparte von 
mal kurz 16% hinnehmen müssen.
(Vielleicht der Grund für eine neue Strategie: Guerilla marketing in 
Foren? Die Bastler sollen es nun reissen?)

> Von fehlendem DMA, CRC-Einheit, mächtigeren Timern und 32 Bit mal ganz
> abgesehen!
Das bieten aber so gut wie alle 32Bit Controller... Nicht nur die ARM 
und schon gar nicht nur die STM32.
Aber das ist auch nur relevant wenn man die Leistung braucht. Und wenn 
ich die Leistung brauche nehme ich halt einen µC mit dieser Leistung.

> Ich weis nicht wie lange sich ATMEl auf dem Markt noch halten kann.
> Irgendwann werden die ganzen alten Firmenprodukte auslaufen und dieser
> Markt wird wegbrechen. Von den par Bastlern werden die sich nicht lange
> halten können.
GENAU - der Trend ist klar... Die MArktanteile wachsen, da müssen die 
doch eingehen... Besser wie die STM Mikrocontrollersparte "Schrumpfen!". 
Das ist gesund ;-)

> Geht daher lieber gleich auf den Industriestandard. Wenn es ST mal
> schlecht gehen sollte wird halt Samsung, NXP, freescale,...
JA: Freescale kann man durchaus als Industriestandard sehen... Platz 2 
in der Gesamtliste. Für Hobbyisten aber auf grund der eher schlechten 
Informations- und Versorgungslage eher weniger geeignet.
Den Biggest Player hast du aber mal kurz unterschlagen mit ungefähr so 
viel MArktanteil wie Platz zwei und drei Zusammen: RENESAS.
Renesas ist mit Abstand der Umsatzmäßig gröte Hersteller, wenn man nur 
auf das Argument "Industriestandard" setzt müsste man sich dessen µC 
ansehen.
Viele derer Produkte kann man sogar problemlos auch als Hobbyist in 
ausreichender Auswahl beziehen und günstige Einstiegskits gibt es aus.
Das einzige Problem ist das Renesas derart viele grundverschiedene µC 
serien hat das es "Den RENESAS Controller" nicht gibt.
Und dann sind wir auch schon bei Atmel und Microchip wo von STM noch 
nicht mal was in der Ferne zu sehen ist... So viel zu 
"Industriestandard"!

Aber die oben gemachte Aufzählung zeigt schon das hinter der Wortmeldung 
nicht viel Wissen Steckt.

Nicht falsch verstehen:
STM baut schöne µC die ich auch regelmäßig verwende!
Wenn immer ich mehr Leistung brauche wird bei mir das Rennen zwischen 
TI, STM32 und PIC ausgetragen, Je nachdem welcher mir für das konkrete 
Projekt die beste Mischung aus Preis, benötigter Peripherie und für das 
Projekt geeigneter, kommerziell frei verwendbarer Libs bietet.
Aber was hier einige für eine Bullshit abliefern kann man einfach nicht 
unkommentiert stehen lassen. Die STM32 Fanboys werden ja schon schlimmer 
als die AVR Fanatiker!!!

Gruß
Carsten

P.S.:
Hier noch die Quelle:
http://www.elektroniknet.de/halbleiter/sonstiges/artikel/86934/
Nur falls das oben mit den Zahlen jemand nicht verstanden hat.
Das sind die Umsätze der REINEN µC Sparte. STM oder NXP sind 
beispielsweise ja noch viel viel größer als "Nur" der µC Bereich. In der 
Halbleiterherstellung insgesamt sind das beide ganz dicke Fische. Aber 
in der µC Welt spielen die noch deutlich hinter Atmel und Microchip nur 
die dritte Geige.

von Antimedial (Gast)


Lesenswert?

Ich halte es für sehr lobenswert, einen solchen Artikel zu schreiben, 
aber der jetzige Artikel hat nichts mit "STM32 für Einsteiger zu tun". 
So ist es im Moment nur eine Meinungsbekundung und dürfte für einen 
Einsteiger gar nichts bringen.

von knabbet (Gast)


Lesenswert?

@Markus.
Hast Du schon mal mit dem Arduino was gemacht ?
Weil der da mit in der Tabelle steht.

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


Lesenswert?

knabbet schrieb:
> @Markus.
> Hast Du schon mal mit dem Arduino was gemacht ?
> Weil der da mit in der Tabelle steht.

Z80, 68HC11, 8051, AVR, PIC16, PIC18, PIC24, DsPIC33, M16C, LPC2000, ein 
Atmel ARM9, STM32 - aber Arduino noch nicht, werde ich wohl auch nicht.

: Bearbeitet durch User
von knabbet (Gast)


Lesenswert?

>Z80, 68HC11, 8051, AVR, PIC16, PIC18, PIC24, DsPIC33, M16C, LPC2000, ein
>Atmel ARM9, STM32
MOS8501, 68HC11, 8031, AVR, PIC10, PIC12, PIC18, PIC24, dsPIC33, S12X, 
H8, 68HC08, S7, S8, STM32, National, MSP430, NIOS, Arduino

> aber Arduino noch nicht, werde ich wohl auch nicht.
Dachte ich mir. Weil Du den so schlecht darstellst. Wenn man aber was 
vergleicht, sollte man das kennen, was man vergleicht.

von F. F. (foldi)


Lesenswert?

Nur mal so:
Atmel Corporation – Worldwide leader in the design and manufacture of 
microcontrollers, capacitive touch solutions, advanced logic, 
mixed-signal, nonvolatile memory and radio frequency (RF) components.
Hier gefunden:
http://electronicsnewsline.com/457/list-of-top-microcontroller-companies-in-the-world.html

Auch wenn ich nicht alles glaube was irgendwo geschrieben steht, so wird 
das mehr Wahreitsgehalt haben, als einige Aussagen hier. Das vermute ich 
zumindest.

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


Lesenswert?

knabbet schrieb:
>> aber Arduino noch nicht, werde ich wohl auch nicht.
> Dachte ich mir. Weil Du den so schlecht darstellst. Wenn man aber was
> vergleicht, sollte man das kennen, was man vergleicht.

Da Du den Arduino also kennst gleich mal eine Frage. Kann man mit 
"Arduino" den Atmel Chip debuggen? Oder geht nur programmieren?

Ansonsten darf jeder den Artikel erweitern, denn komplett ist das ganze 
sicher noch nicht.

von knabbet (Gast)


Lesenswert?

>Da Du den Arduino also kennst gleich mal eine Frage. Kann man mit
>"Arduino" den Atmel Chip debuggen? Oder geht nur programmieren?
Geht. Man muss DebugWire aktivieren.

>der Artikel zum Krieg (µC Wahl)
Krieg entsteht dann, wenn man den anderen nicht kennt. Deswegen haben 
sich Deutsche und Franzosen jahrhundertelang die Köpfe eingeschlagen. 
Heute gibt's den nicht mehr und ich fahr nachher nach Strasbourg in'n 
IKEA.

von (prx) A. K. (prx)


Lesenswert?

knabbet schrieb:
> Krieg entsteht dann, wenn man den anderen nicht kennt.

Du hast offenbar noch keine Scheidung erlebt. ;-)

: Bearbeitet durch User
von Helmut L. (helmi1)


Lesenswert?

knabbet schrieb:
>>Z80, 68HC11, 8051, AVR, PIC16, PIC18, PIC24, DsPIC33, M16C, LPC2000, ein
>>Atmel ARM9, STM32
> MOS8501, 68HC11, 8031, AVR, PIC10, PIC12, PIC18, PIC24, dsPIC33, S12X,
> H8, 68HC08, S7, S8, STM32, National, MSP430, NIOS, Arduino
>
>> aber Arduino noch nicht, werde ich wohl auch nicht.
> Dachte ich mir. Weil Du den so schlecht darstellst. Wenn man aber was
> vergleicht, sollte man das kennen, was man vergleicht.

Was hat jetzt Arduino in einer Reihe mit uC zu tun?

8051,68HC11,Z80 etc. sind Controllerfamilien, Arduino nicht. Oder gibt 
es jetzt einen Arduinochip vonm Halbleiterhersteller 
Arduinosemiconductor?

von knabbet (Gast)


Lesenswert?

>Was hat jetzt Arduino in einer Reihe mit uC zu tun?
Weil
MOS8501-System, 68HC11-System, 8031-System, AVR-System, PIC10-System, 
PIC12-System, PIC18-System, PIC24-System, dsPIC33-System, S12X-System, 
H8-System, 68HC08-System, S7-System, S8-System, STM32-System, 
National-System, MSP430-System, NIOS-System, Arduino
mir zu lange war. Hat aber nix mit der Diskussion zu tun.

Hier wurde ein Artikel geschrieben "STM32 für Einsteiger - der Artikel 
zum Krieg (µC Wahl)" und die Motivation hätte sein sollen, Frieden zu 
stiften, und genau das wurde nicht getan. Das stört mich daran!

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


Lesenswert?

Ich habe aus dem Artikel den "Programmieradaper mit Debugger" "USBasp 
2-5€" entfernt, da der (lt. deren Homepage) nur programmieren und nicht 
debuggen kann.

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


Lesenswert?

knabbet schrieb:
> die Motivation hätte sein sollen, Frieden zu stiften

Bei "Geschmackssachen" wird es niemals Frieden geben ;-)

Ich habe das akzeptiert und da ich es mir Leid bin jedes mal bei der 
gleichen Frage immer wieder das gleiche zu schreiben habe ich einen 
Artikel geschrieben - für STM32 natürlich, da ich den meistens empfehle 
- aber nicht immer! Siehe hier:
Beitrag "Re: Mit was in die Mikrokontrollerwelt einsteigen?"

von Frank M. (frank_m35)


Lesenswert?

Aller Mühe in Ehre, der Artikel ist schlicht Schwachsinn.

Ich spreche mal einfach nur den Vergleich PIC mit STM32 an, vor allem in 
Bezug zu Einsteiger:

Neueinsteiger, kaum Elektronikkenntnisse, noch nie programmiert:
Ja, das STM32 Discovery ist günstig, aber nutzlos wenn man ein eigenes 
Projekt aufbauen will, da es für die meisten Zwecke einfach zu groß ist. 
Denn dann muss man einen isolierten STM32 kaufen der für Einsteiger 
sicherlich alles andere als optimal ist (QFN). D.h. man bruacht 
eigentlich immer eine geäzte Leiterplatte oder muss einen auf einer 
Adapterplatine kaufen. Ein AVR oder PIC18/18/24/32 gibt's fertig und 
günstig in DIL, in jeder erdenklichen Größe, und ein Aufbau auf einem 
Steckbrett oder Laborkarte ist leicht möglich.

Wunsch ist SD-Card oder Grafik-Display:
Du gibst an PIC24 oder dsPIC verwendet zu haben, behauptest aber ein 
PIC24 sei zu klein für SD-Karten oder Grafik-Anwendungen. Es gibt PIC24 
Varianten die sogar einen eingebauten TFT Controller haben. Es gibt 
fertige LCD Libraries, FAT-Libraries, ... die alle nur einen Bruchteil 
des Speichers belegen.

Wunsch ist TCP/IP Netzwerk oder Kamera:
Es gibt fertige TCP/IP Libraries von Microchip für den PIC. Sorry, aber 
deine Behauptung ist schlichtweg falsch. Ich sehe da kein Problem.

Möchte die Erkenntnisse beruflich nutzen:
Ich bin in keiner Firma, aber wie man an der zuvor genannten 
Produktvielfalt, der Produktlaufzeit und auch dem Marktanteil sehen 
kann, ist deine Behauptung in der Tabelle wieder einmal schlichtweg 
falsch.

Extrem stromsparende Mini-Anwendung:
Es gibt PIC Varianten die nur dafür gemacht wurden und in direkter 
Konkurrenz zum MSP430 seitens Microchip beworben werden.

Experimentieren mit Multithreading, RTOS, Schedulern:
Du scheinst den Begriff PIC auf die veraltete PIC16 Familie zu 
reduzieren. Denn ansonsten wüsstest du, dass es genug RTOS für PIC24 und 
32 gibt.

Große, komplex strukturierte Programme:
Was hat das mit dem uC zu tun. Du programmierst in C oder Assembler. Und 
egal welchen uC du verwendest kannst du komplexe Programme schreiben.

Viel I/O, PWM, komplexes Timing:
Ausstattungstechnisch ist da kein Unterschied, sobald du eben auch 
Vergleichbare Varianten vergleichst und nicht einen STM32 mit einem 
PIC16, sondern eben einem PIC32.

Die Frage die sich ein Einsteiger aber immer Stellen sollte ist: WAS ZUM 
TEUFEL BRAUCHT ER.
Was glaubst du wohl warum es so viele unterschiedliche Varianten der 
selben Architektur gibt? Weil es unterschiedliche Anforderungen gibt.

Und dein Totschlagargument:
"zu 90% reicht doch ein kleiner Prozessor (AVR/PIC) - und für die 
restlichen kann man immer noch einen großen nehmen. Warum also nicht 
gleich einen großen nehmen?"
Kann ich leicht kontern und sagen: Wozu sich mit einem mikrigen STM32 
abgeben, wenn man gleich zu einem RPI gehen kann, oder warum denn nicht 
gleich ein Samsung Exynos QuadCore?

Du hast eine einseitige Sichtweise, gehst überhaupt nicht auf einen 
EINSTEIGER ein und reduzierst Produkte anderer Hersteller auf die 
älteste Hardware. Es tut mir leid, du hast keine Ahnung von PICs und 
wohl noch nie einen neueren verwendet.

Solche Artikel führen doch nur zu Glaubenskriegen, da Dinge unterstellt 
werden, die einfach nicht stimmen.

von lusi (Gast)


Lesenswert?

Ich fände einen Artikel besser, der für sich selbst spricht:

also zum Beispiel: "stm32 programmieren lernen in 1 Stunde" oder so.

Und dann auf 2 DinA4 Seiten zeigen wie simpel Coocox zu installieren ist 
und wie einfach die ersten Programme zum Laufen zu bringen sind (fast 
genauso einfach wie Arduino). Das wäre einfach etwas, was direkt dazu 
einläd sich ein stm32Discovery zu kaufen und loszulegen.

Denn das will man ja: Möglichst schnell die Macht besitzen selber ein 
Mikrocontrollerprojekt zu realisieren. Das erzeugt die Belohnungsgefühle 
im Hirn und begeistert für zeitgemäße Technik :-)

;)

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


Lesenswert?

Habe ich auch noch vor.

von lusi (Gast)


Lesenswert?

finde ich klasse. :)

von Markus W. (Firma: guloshop.de) (m-w)


Lesenswert?

lusi schrieb:
> Ich fände einen Artikel besser, der für sich selbst spricht:
>
> also zum Beispiel: "stm32 programmieren lernen in 1 Stunde" oder so.

Fänd ich auch besser und zielführender. Du willst ja Leute für den STM32 
begeistern, dann tu auch genau das.

Grade die Vergleiche, warum STM32 gut und die anderen 
Mikrocontroller-Architekturen eher schlecht sind, halte ich für fehl am 
Platz, das führt letztlich nur zu einem Edit-War, weil jeder so seine 
Ansichten hat.

Wenn man so etwas wirklich ins Wiki bringen will, dann auf eine andere, 
auf eine neutrale Seite und nicht in den STM32-Seite. Außerdem sollten 
dort dann nur Fakten (Zahlen) stehen, die man im Datenblatt nachlesen 
kann und keine allgemeinen Einschätzungen.

von Frank M. (frank_m35)


Lesenswert?

Markus Weber schrieb:
> Grade die Vergleiche, warum STM32 gut und die anderen
> Mikrocontroller-Architekturen eher schlecht sind, halte ich für fehl am
> Platz, das führt letztlich nur zu einem Edit-War, weil jeder so seine
> Ansichten hat.
Dem stimme ich zu, aber dennoch haben mich ein paar Bemerkungen zu sehr 
gestört, sodass ich sie korrigiert habe (Nur PIC bezogen, die anderen 
kenne ich zu wenig um darüber urteilen zu können). Und dabei habe ich 
versucht neutral zu bleiben und nicht einen Vergleich zum Rest zu 
machen, sondern einfach die Tatsachen dargelegt. Ob das der Leser nun 
als Vor- oder Nachteil auffasst, dass soll dem Leser bitte selbst 
überlassen bleiben. Man muss in so einem Artikel nicht vorgefertige 
Vergleiche machen.

Die "Unwichtige Randbedingungen" sind dennoch falsch und fehl am Platz. 
Was wichtig und unwichtig ist, das überlasse bitte dem Leser.

: Bearbeitet durch User
von Markus W. (Firma: guloshop.de) (m-w)


Lesenswert?

Frank M. schrieb:
> Dem stimme ich zu, aber dennoch haben mich ein paar Bemerkungen zu sehr
> gestört, sodass ich sie korrigiert habe (Nur PIC bezogen, die anderen
> kenne ich zu wenig um darüber urteilen zu können).

Unsere Edits haben sich überschnitten, ich hoffe, ich hab nichts von dir 
überschrieben. :-( Bitte schau nochmal nach.

von Helmut S. (helmuts)


Lesenswert?

Hat jemand das Teil schon mal ausprobiert?
Auf jeden Fall hätte man da schon mal alle Schnittstellen die man sich 
so wünschen kann.
http://arduino.cc/en/ArduinoCertified/IntelGalileo

von Antimedial (Gast)


Lesenswert?

Helmut S. schrieb:
> Hat jemand das Teil schon mal ausprobiert?

Ja, die Jungs von Golem: 
http://www.golem.de/news/test-intels-galileo-board-1312-103167.html

Fazit war wohl: Interessant, aber noch nicht ausgereift 
(softwareseitig).

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


Lesenswert?

bis auf CAN ...  mein Hausbaus läuft mit CAN.

von DerAnfänger (Gast)


Lesenswert?

Ich finde den Artikel von Markus Müller gar nicht so schlecht, weil man 
aus ihm folgende Dinge entnehmen kann:

1) "Super-Anfänger" : Dieser Typus hat absolut keine Kenntnisse 
bezüglich zu Programmiersprachen C(++)/(ASM)/etc. und Möglichkeiten 
eines Microcontrollers. Daher wird es sein Ziel sein, diese in Erfahrung 
zu bringen. Foglich fängt er mit kleinen uC an.

2) "Anfänger" : Diese Gattung beherrscht das Programmieren in C und kann 
sich voll und ganz auf den uC konzentrieren. Jetzt muss sich dieser 
entscheiden, welchen Pfad er nehmen möchte:

    2a) Pfad der Erkenntnis : Er fängt mit dem kleinen uC an und lernt 
deren Funktionsweise (Timer, Clock, GPIO, ADC, UART, I2C, SPI, EEPROM, 
IRQ, etc.) kennen. Anschließend erfreut er sich mit kleinen Projekten 
wie LCD 44780, Tastenentprellung, Texte über UART-USB mit dem PC, 
Ausprobieren von Sensoren Druck, Temp, Feuchte, Beschleunigung- und 
Gyros-Sensoren, etc. Fazit:
Dieser Typus hat VIEL Zeit und legt auch für ein paar Monate Pausen ein 
und möchte insbesondere Spass am Hobby haben.

    2b) Pfad des Turbolernens: Aus zukunftperspektivischen Gründen 
(Studium, Beruf) wird er sich gleich mit dem Großen (STM32F4xx) 
beschäftigen wollen. Oder arbeitswütige Hobbyisten, die einfach nur das 
Größe und Beste haben möchten.

von MartinS. (Gast)


Lesenswert?

ST32Anwender schrieb:
> ATMEL (insbes. AVR und XMEGA) ist in größeren Firmen nicht gerne gesehen
> Preis/Leistung ist bescheiden. STM32 mit 64kB Flash gibt es zu 40% des
> Preises eines AVRs mit 16kB Flash (hohe Stückzahlen >100k/Jahr)

wie definierst du eine "größere Firma"?

Philips hat den ATmega256RFR2 für seine neuen Philips HUE LED Serie 
eingebaut
http://atmelcorporation.wordpress.com/2013/12/04/11-interview-with-magnus-pedersen-product-marketing-director-for-mcu-wireless-solutions/

Interessant ist dass Philips weder einen Industriestandard Core wie ARM 
gewählt hat, noch einen Arm SOC wie den STM32W noch seiner ehemaligen 
Chipsparte (heute NXP) vertraut...

Microsoft verwendet den AVR32 für seine Tablets:
http://atmelcorporation.wordpress.com/2013/12/02/two-atmel-chips-in-the-new-microsoft-surface-2-tablet/

Auch wieder interessant dass der UC3L (obwohl viel teurer da in älteren 
Prozessen gefertigt) selbst den 32Bit für 32Cent Werbeslogans (von ST) 
standhält.

dasselbe sieht man im samsung galaxy :
http://ir.atmel.com/releasedetail.cfm?ReleaseID=723073

Auch wieder einem nicht-ARM Core den Vorzug gegeben

Gründe?
Ich tippe mal: Low Power,  bessere Peripherie

von Frank M. (frank_m35)


Lesenswert?

Markus Weber schrieb:
> Unsere Edits haben sich überschnitten, ich hoffe, ich hab nichts von dir
> überschrieben. :-( Bitte schau nochmal nach.

passt, und mit deinen Änderungen kann ich teils leben :-)
Die Zeile mit der Schule kann man sich wohl schenken.

Da AVR normalerweise 8-Bit ist denke ich nicht, dass
- Experimentieren mit Multithreading, RTOS, Schedulern
- Große, komplex strukturierte Programme
- Sehr viel PWM mit komplexem Timing
eingeschränkt empfohlen werden kann, wenn der MSP430, ein 16-Bit 
Prozessor RTOS bspw. auch nicht kann oder Arduino der ebenfalls 8-Bit 
ist.
Beim PIC ist es problematisch, da die PIC24 und PIC32 es sehr wohl 
können, PIC12/16/18 genauso wie AVR wohl weniger. Daher passt hier die 
Empfehlung mit Einschränkung.

Ich habe es mal angepasst, wem es nicht passt darf es gerne wieder 
ändern, aber konsequent bleiben und begründen. Und wenn, wie in der 
Schule Zeile, keine Unterschiede mehr ersichtlich sind, kann man es sich 
gleich sparen und die ganze Zeile killen.

von stm32 Einsteiger (Gast)


Lesenswert?

Mir als frischer Hobby STM32 Einsteiger fehlt etwas ganz Anderes.
Tutorials, wie das AVR auf dieser Seite, die Module erklären bzw. 
Beispiele aufzeigen.
Imsbesondere der Verweis auf Bibliotheken oder Erklärungen zur LCD 
Ansteuerung, UART mit Buffer, Tastenentprellung, Timer...

Das ist für einen AVR Umsteiger eher schwierig. AVR's aind im Hobby 
Bereich so interessant, weil eben saubere Libs für Standardfunktionen 
vorhanden sind.
Siehe Peter Dannegers oder Fleury Libs.

Ein paar LED's auf dem Dsicovery togglen ist ja nicht das Problem, aber 
ist mir persönlich der AVR Einstieg leichter gefallen obwohl es mein 
erster Controller war.

Viel wichtiger sind da solche Artikel

http://www.mikrocontroller.net/articles/STM32F10x_Standard_Peripherals_Library

Steckt doch eure Arbeit lieber in so etwas. Das würde uns Hobbyisten 
sehr freuen!

Gruß

von F. F. (foldi)


Lesenswert?

Für mich, und das ist nur mein ganz persönlicher Weg, ist es wichtig 
erstmal mit einem System und sogar vorwiegend mit einer Gruppe 
anzufangen, dabei zu bleiben und mit wenig viel schaffen. Das ist mein 
persönliches Lernziel.
Erst wenn ich aus dem letzten Bit nichts mehr raus quetschen kann, die 
Architektur völlig verstanden habe, alle Codeoptimierungen nichts mehr 
bringen, dann will ich was größeres machen.
Wenn man sich mal die vielen verschiedenen Sachen anschaut, die Leute 
mit nem Tiny13 so gemacht haben, dann sehe ich noch lange keinen STM32.
Aber dazu, ja ich habe auch ein paar von den Dingern hier liegen und die 
Leds habe ich auch zum blinken bekommen, auch das Originalprogramm ist 
wieder drauf.
Warum ich nicht weiter damit gemacht habe? Ganz einfach, wie kriege ich 
den auf ein Streifenraster?
Und ja, ich kann auch schon Platinen ätzen, aber will man das immer, für 
eine kleine Sache?

Da ich jetzt auf SMD umsteige, hab ich den Tiny10 zum spielen genommen 
(geht noch so gerade auf die 1,27 Lochraster, hier aus dem Forum).
Und ich bin noch ein ziemlich blutiger Anfänger.
Erst wenn ich da alles mit kann, dann gucke ich, aber auch nur 
vielleicht, nach anderen µC's.
Ich habe hier Arduinos ohne Ende, MSP430, Discoverys nur keinen PIC, 
letztlich bleibe ich erstmal bei den AVR's.
Hatte gerade eine Schaltung gebaut, da brauche ich eigentlich nur zwei 
Pins, einen dritten Pin habe ich dann zur Signalisierung genommen (Led)
Natürlich kann man da noch ein Display dran hängen und anzeigen lassen, 
"Jetzt ist der Schaltkreis aus (oder ein)", aber wozu?
Nicht mal die Led wäre für mich nötig, denn ich weiß doch was ich 
programmiert habe und was das Teil tun soll. Und bei mir sollen die 
Schaltungen das gut tun, aber möglichst unauffällig.
Klickibunt hab ich auf dem Laptop.

von Stefan F. (Gast)


Lesenswert?

> Klickibunt hab ich auf dem Laptop.
Jawohl.

Seit 3 Jahren schleiche ich gedanklich um diese 32bit Evaluation Boards 
herum. Sie sind teilweise enorm preisgünstig, verglichen mit dem 
Funktionsumfang. Aber mir fällt kein Anwendungsfall dafür ein, der in 
meinem Haushalt auch nur ansatzweise Sinn ergäbe. Das Dilemma ist:

- Kleine Schaltungen möchte ich auf Lochraster löten können. Dafür sind 
die 32bit Controller samt Adapter zu teuer und zu klobig. Bislang hatte 
ich noch niemals das Problem, keinen passenden 8bit Controller zu 
finden, der ausreichend Leistung und Features hat.

- Große Schaltungen verlangen zumindest in meiner Vorstellungskraft auch 
stets nach einem richtigen Bildschirm und Tastatur oder Touch-Screen 
sowie Netzwerk-Kommunikation. Da sind handelsübliche Tablets oder 
Netbooks preisgünstiger, als ein Raspberry Pi order gar ein STM32 mit 
dem ganzen Zubehör drumherum. Und falls ich mal etwas verkaufe, dann 
muss ich dem Kunden auch versprechen, das Ding 10 Jahre lang reparieren 
zu können.

Sobald ich auf billige nicht standarisierte Module von Ebay setze, 
müsste ich die Module mehrfach kaufen und als Ersatzteil lagern. Also 
doch lieber einen Laptop oder Tablet nehmen.

Solange ich keinen konkreten Anwendungsfall habe, schaffe ich mir keine 
32bit Set an. Bis es soweit ist, ist dieser ganze ARM Hype vielleicht 
schon wieder Schnee von gestern und etwas ganz anderes angesagt. In der 
8bit Welt ist mir das schon mehrmals passiert. Oder hat noch jemand 
Interesse an 1-Chip Floppy-Controller - um nur ein Beispiel zu nennen.

Ganz ehrlich: Die Idee, sich EINE Controller-Familie ausgucken zu wollen 
um sich darauf zu spezialisieren ist dumm. Man nimmt, was man jetzt 
braucht. Wie es in 3 Jahren aussehen wird, weiß sowieso niemand. Und 
wenn Du in 5 Jahren herum erzählst, dass Du absoluter STM32 Crack bist, 
dann wird man Dich auslachen. Dann stehst Du genau wie ich mit meinem 
ollen Z80 auf dem Abstellgleis.

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


Lesenswert?

lusi schrieb:
> finde ich klasse. :)

Nun gibt es einen neuen Artikel

STM32 CooCox Installation

Und damit kann nun jeder Einsteiger innerhalb kürzester Zeit sich die 
kostenlose CooCox IDE für den STM32 einrichten und mittels 
SMT32F4DISCOVERY debuggen.

Ich hatte gerade einen frischen jungfreulichen PC hier rumstehen und 
damit habe ich das gemcht, also jeden Schritt aufgeschrieben der nötig 
war, incl. USB Treiberinstallation für den ST-LINK.

Damit sollte auch die letzte Lücke für einen erfolgreichen Start mit 
einem STM32F4DISCOVERY Board  für Neuanfänger geschlossen sein.

: Bearbeitet durch User
von Tintenfisch (Gast)


Lesenswert?

Also wenn ein AVR wirklich mal multimediamässig oder zum Anschluß ans 
Netz zu schwach wird dann nimmt man eben eins der spezialisierten 
Zusatzmodule die man seriell ansteuern kann. Und zentrale Steuerungen 
mit hohem Leistungsbedarf kommen sowieso aus der Mode, dezentrale 
Informationsverarbeitung über ein (drahtloses) Netz zusammengeschaltet 
ist die Zukunft! Und dafür langen schon 4 Bit :-)

von technikus (Gast)


Lesenswert?

Markus Müller schrieb:
> er Einsteiger innerhalb kürzester Zeit sich die
> kostenlose CooCox IDE für den STM32 einrichten und mittels
> SMT32F4DISCOVERY debuggen.
>
> Ich hatte gerade einen frischen jungfreulichen PC hier rumstehen und
> damit habe ich das gemcht, also jeden Schritt aufgeschrieben der nötig
> war, incl. USB Treiberinstallation für den ST-LINK.
>
> Damit sollte auch die letzte Lücke für einen erfolgreichen Start mit
> einem STM32F4DISCOVERY Board  für Neuanfänger geschlossen sein.

SUPER!

von lusi (Gast)


Lesenswert?

Markus Müller schrieb:
> lusi schrieb:
>> finde ich klasse. :)
>
> Nun gibt es einen neuen Artikel
>
> STM32 CooCox Installation
>
> Und damit kann nun jeder Einsteiger innerhalb kürzester Zeit sich die
> kostenlose CooCox IDE für den STM32 einrichten und mittels
> SMT32F4DISCOVERY debuggen.
>
> Ich hatte gerade einen frischen jungfreulichen PC hier rumstehen und
> damit habe ich das gemcht, also jeden Schritt aufgeschrieben der nötig
> war, incl. USB Treiberinstallation für den ST-LINK.
>
> Damit sollte auch die letzte Lücke für einen erfolgreichen Start mit
> einem STM32F4DISCOVERY Board  für Neuanfänger geschlossen sein.

Sehr gut!

Ich überlege grade ob es nicht gut wäre auch gleich die Schritte zu 
erklären mit denen man den Clock auf 168MHz stellen kann (PLL). Das wäre 
ja zu Beginn der Main nur ein SystemInit(), das Einbinden der "#include 
"stm32f4xx_rcc.h"" und das Eintragen von PLL_M = 8 in der 
system_stm32f4xx.c und HSE_VALUE = 8000000 in  stm32f4xx.h.

Und schon läuft der Prozessor mit 168MHz. Das ist ja sehr einfach und 
nicht kompliziert. :))

von max (Gast)


Lesenswert?

Schön wäre vielleicht auch noch eine Gegenüberstellung der IDE's z.B. 
CooCox und eclipse+Plugins.
Welche Vorteile und Nachteile beide bieten.

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


Angehängte Dateien:

Lesenswert?

Das eine Programm würde ich so lassen, ist kurz und absolut 
verständlich.

Diese Erweietrung könnte man in dem Artikel weiter unten anfügen als 
"erste Ausbaustufe" usw. und dann fortgesetzt werden.

Im Anhang mal das BlinkLED-Projekt (STM32F4xx).

von lusi (Gast)


Lesenswert?

max schrieb:
> Schön wäre vielleicht auch noch eine Gegenüberstellung der IDE's
> z.B.
> CooCox und eclipse+Plugins.
> Welche Vorteile und Nachteile beide bieten.

Das wäre gut! Ich würde das aber in einem extra Artikel machen, denn 
hier geht es ja darum möglichst kompakt, einfach und schnell einen 
Einstieg zu bekommen. Also auch irgendwie der Anspruch, dass der Text 
nicht länger wird als wenige Seiten und der Anfänger mit möglichst 
wenigen Infos belastet wird. Also wirklich nur das ganz Wesentliche.

von W.S. (Gast)


Lesenswert?

Stefan us schrieb:
> Seit 3 Jahren schleiche ich gedanklich um diese 32bit Evaluation Boards
> herum. Sie sind teilweise enorm preisgünstig, verglichen mit dem
> Funktionsumfang. Aber mir fällt kein Anwendungsfall dafür ein, der in
> meinem Haushalt auch nur ansatzweise Sinn ergäbe.

Ganz einfach:
Es gibt in dieser Welt tatsächlich keinen wirklichen Einsatzfall für 
Eval-Boards - und das gilt für ALLE Boards dieser Klasse, egal ob µC 
irgendeiner Machart oder FPGA oder irgendwas anderes.
Eval-Boards sind zum Kennenlernen eines Chips gedacht und eignen sich zu 
nix anderem - jedenfalls wenn daraus ne echte Anwendung werden soll.

Und genau daran hapert es bei dir. Für den Haushalt sehe ich auch keine 
wirkliche Anwendung für nen dicken µC, es sei denn, man hat's halt 
herumliegen. z.B. ne Eieruhr mit Bratenthermometer und s/w-Grafikdisplay 
mit nem LPC2103 drin. Jetzt kreischen gewiß alle anderen Fans auf, aber 
was soll's? Dieser Chip ist spottbillig, also warum NICHT? Nur so als 
Beispiel.

Anwendungen für den Haushalt sind ohnehin zumeist ein einziger Krampf. 
Um ne gute Stereo-Anlage oder nen Fernseher zu bauen, fehlen den meisten 
Programmierern ja sowieso die Kenntnisse. Was sonst? Für ne Abspieldudel 
für die gerippten DVD's auf dem NAS braucht es mehr Rechenleistung als 
es einer der hier üblichen µC aufbringt, also eher ein Fall für nen 
Wohnzimmer-PC. Nun, es gibt auch Chaoten, die vom Klo aus unbedingt das 
Garagentor öffnen können wollen oder einfach nur ihren Hang zum 
Totalverkabeln des Hauses ausleben wollen. Aber wer braucht all das 
wirklich?

Aus meiner Sicht ist das sinnvollste Feld für Eigenentwicklungen die 
Meßtechnik, die man selbst benötigt oder eben im Haushalt gebrauchen 
kann. Aber das setzt voraus, daß man tatsächlich ein Gerät konzipiert - 
und das hat nix zu tun mit all den Basteleien auf Steckbrettern oder 
Lochraster, für die hier Controller im DIL gesucht werden. Sowas wird 
bestenfalls für Voruntersuchungen gebraucht, aber die richtige 
Entwicklung fängt erst mit der ersten echten Leiterplatte an.

W.S.

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


Angehängte Dateien:

Lesenswert?

Ich arbeite mit Eclipse + Plugins.

Coocox:
+ einfache installation
+ makefile wird automatisch generiert
+ Unterstützung der Debugger ohne manuelle Konfiguration
- makefile kann nicht bearbeitet werden (z.B. für eigenen Bootloader im 
Projekt)

Eclipse:
+ Die Ansichten gefallen mir besser, wobei ich mir jetzt nicht sicher 
bin ob man die auch im CooCox so aktivieren kann
+ absolut jede Konfigurationsmöglichkeit da man selbst Linker-Scripte 
und makefile verwalten kann
- man muss wissen wie das geht (makefile/Linker-Script)

Ich habe heute zum ersten mal CooCox installiert, ging erstaunlich easy 
und alles hat sofort funktioniert.
Dennoch gefällt mir Eclipse besser, z.B. wenn ich über eine Funktion die 
Maus bewege, dann sehe ich den Funktionskopf im Hint, mit F2 kann ich 
den direkt komplett zeigen lassen ohne dass ich die andere Seite extra 
öffne.
Das müsste eigentlich auch mit CooCox gehen, denn das hat als Basis auch 
Eclipse.
Rechts sehe ich alle Funktionen und Deklarationen vom Quellcode und 
damit kann man sehr schnell navigieren.
Ich habe mal ein Screenshot angehängt wie das so aussieht.

von lusi (Gast)


Lesenswert?

> aber die richtige
> Entwicklung fängt erst mit der ersten echten Leiterplatte an.

Endet sie damit nicht eher? Anfangen sollte man doch mit einem 
Lastenheft, dann mit dem Schaltplan und bevor man den macht, wird gerne 
mit einem Evaluation-Board evaluiert wie der uc zu verwenden ist. Wenn 
diese ganz wesentlichen Entwicklungsschritte gemacht sind, kommt das 
Layout des Prototyps, dann dessen Test und zum Schluss dann die fertige 
Anwendung.

Das gehört doch alles zur "richtigen" Entwicklung dazu...

lg

von stefan s (Gast)


Lesenswert?

Da sehr ihr mal, an was für simplen Sachen Einsteiger beim STM32 
scheitern:
Beitrag "Allgemeine Fragen zum Stack"

Deswegen würde ich Einsteigern eher die einfacheren 8bit Controller 
empfehlen. Weniger Features = weniger Probleme für Einsteiger.

von stefan s (Gast)


Lesenswert?

Upps, falscher Link. Ich keinte dieses Thema: 
Beitrag "STM32 Anfängerfragen"

von Markus W. (Firma: guloshop.de) (m-w)


Lesenswert?

Was ist denn gemeint mit der Tabellenzeile "Große, komplex strukturierte 
Programme"?

Klar, bei manchen Programmen stößt man an die Speicher-Grenzen der der 
Controller (beim AVR glaub ich sind es etwa 200 k Befehle), aber was hat 
das mit der "Komplexität" zu tun? Das ist doch Sache des Compilers...

Ach so, wie groß ist der Programm-Flash-Speicher des größten STM32?

Klärt mich bitte mal auf.

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


Lesenswert?

>Deswegen würde ich Einsteigern eher die einfacheren 8bit Controller
>empfehlen. Weniger Features = weniger Probleme für Einsteiger.

Wenn man die Register direkt parametriert, dann ist das so leicht wie 
hier gezeigt:
http://www.mikrocontroller.net/articles/STM32_CooCox_Installation#Die_Programmierung

Ich sehe jetzt keine Unterschiede zwischen 8 und 32 Bit.

Wer natürlich mit der ST Bibliothek arbeiten möchte, der muss 
entsprechend auch verstehen (lernen) wie die arbeitet, zusätzlich zu den 
Registern/Features der Peripherie.

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


Lesenswert?

Markus Weber schrieb:
> Was ist denn gemeint mit der Tabellenzeile "Große, komplex strukturierte
> Programme"?
>
> Klar, bei manchen Programmen stößt man an die Speicher-Grenzen der der
> Controller (beim AVR glaub ich sind es etwa 200 k Befehle), aber was hat
> das mit der "Komplexität" zu tun? Das ist doch Sache des Compilers...
>

Gemeint sind z.B. Tabellen mit Konstanten, die im Flash gehalten werden 
(für Grafiken für das Display, Schriftarten). Oder wenn man viel 
Speicherplatz benötigt um z.B. UART Ausgaben zwischen zu speichern (5KB 
oder so).
Ich programmiere alle Teile immer Asynchron, d.h. wenn ein Teil warten 
muss, dann wird die Funktion verlassen und alle anderen Tasks können 
weiter arbeiten. So z.B. wird die UART-Ausgabe immer in einen 
Zwischenbuffer geschrieben und ein anderer Task sendet die Daten wenn 
der UART wieder frei ist. Somit "hängt" die CPU nie an einer 
Programmposition.

> Ach so, wie groß ist der Programm-Flash-Speicher des größten STM32?
>
2048KB (noch)

> Klärt mich bitte mal auf.

Steht im Artikel: STM32  gleich zu Anfang.

: Bearbeitet durch User
von Markus W. (Firma: guloshop.de) (m-w)


Lesenswert?

Markus Müller schrieb:
> Gemeint sind z.B. Tabellen mit Konstanten, die im Flash gehalten werden
> (für Grafiken für das Display, Schriftarten). Oder wenn man viel
> Speicherplatz benötigt um z.B. UART Ausgaben zwischen zu speichern (5KB
> oder so).

Das sind für mich einfach große Programme (viel Speicherplatz), mit 
Komplexität hat das nichts zu tun. Deswegen würde ich gern das Wort 
"komplexe" wieder entfernen.

> Ich programmiere alle Teile immer Asynchron, d.h. wenn ein Teil warten
> muss, dann wird die Funktion verlassen und alle anderen Tasks können
> weiter arbeiten. So z.B. wird die UART-Ausgabe immer in einen
> Zwischenbuffer geschrieben und ein anderer Task sendet die Daten wenn
> der UART wieder frei ist. Somit "hängt" die CPU nie an einer
> Programmposition.

Das ist löblich und sinnvoll. :-)
Lässt sich aber auf jedem µC ausführen, der ein gewisses Mindestmaß an 
Speicher hat, sagen wir mal, ein paar zig kB Flash und ein paar kB SRAM.

>> Ach so, wie groß ist der Programm-Flash-Speicher des größten STM32?
>>
> 2048KB (noch)

Danke! Habs gefunden. 1 Befehl == 32 Bit (normalerweise)?

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


Lesenswert?

Markus Weber schrieb:
> Was ist denn gemeint mit der Tabellenzeile "Große, komplex strukturierte
> Programme"?
>
> Klar, bei manchen Programmen stößt man an die Speicher-Grenzen der der
> Controller (beim AVR glaub ich sind es etwa 200 k Befehle), aber was hat
> das mit der "Komplexität" zu tun? Das ist doch Sache des Compilers...
>

Gemeint ist aber auch die Möglichkeit, dass der Cortex-M3 direkt 6 
HW-Breakpoints unterstützt, was das Debugging erleichtert. Man setzt 
einfach überall mal einen Punkt wo es interessant werden könnte. Das 
geht bei den kleinen nicht.

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


Lesenswert?

Markus Weber schrieb:
> 1 Befehl == 32 Bit (normalerweise)?

Nein. Ein Befehl kann auch weniger Bits haben, z.B. um noch 1 Byte zu 
laden oder relative Sprünge aus zu führen.
Kann aber auch mehr haben wenn noch 32 Bit irgendwo hin geladen werden 
oder gesprungen wird.

Den ARM Assembler Code kenne ich allerdings viel zu wenig um jetzt eine 
detailliertere Aussage zu treffen.

von Markus W. (Firma: guloshop.de) (m-w)


Lesenswert?

Markus Müller schrieb:
> Markus Weber schrieb:
> Gemeint ist aber auch die Möglichkeit, dass der Cortex-M3 direkt 6
> HW-Breakpoints unterstützt, was das Debugging erleichtert. Man setzt
> einfach überall mal einen Punkt wo es interessant werden könnte. Das
> geht bei den kleinen nicht.

Das ist natürlich praktisch, weil es den Programmablauf während des 
Debuggens beschleunigt, aber es hat trotzdem nichts mit der Fähigkeit zu 
tun, "komplexe Programme" auszuführen.

Wenn du die "6 HW-BPs" besonders herausstellen willst (was sicher eine 
gute Idee ist), dann müsste das in eine andere Tabellenzeile oder besser 
irgendwo in den erklärenden Text.

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


Lesenswert?

Stimmt.

Ich habe mal die Breakpoint-Zeile hinzugefügt. Sollte noch jemand drüber 
schauen, der die anderen Prozessoren besser kennt.

: Bearbeitet durch User
von technikus (Gast)


Lesenswert?

stefan s schrieb:
> Da sehr ihr mal, an was für simplen Sachen Einsteiger beim STM32
> scheitern:
> Beitrag "Allgemeine Fragen zum Stack"
>
> Deswegen würde ich Einsteigern eher die einfacheren 8bit Controller
> empfehlen. Weniger Features = weniger Probleme für Einsteiger.

AVR's programmiert der Fragende schon viele Jahre und hat nie über den 
Tellerand geschaut...
Das hat also nichts damit zu tuen...

von Markus W. (Firma: guloshop.de) (m-w)


Lesenswert?

Markus Müller schrieb:
> Ich habe mal die Breakpoint-Zeile hinzugefügt. Sollte noch jemand drüber
> schauen, der die anderen Prozessoren besser kennt.

Find ich gut. Je mehr Zahlen in der Tabelle stehen, desto weniger kann 
man sich drüber streiten, denn Zahlen lassen sich konkret belegen. :-)

Ich würde gerne noch "Große, komplex strukturierte Programme" ersetzen 
durch "Besonders große Programme". Gleichzeitig könntest du die 
schwammige Bezeichnung "große" konkretisieren und z.B. schreiben:

"Große Programme mit mehr als 500.000 Befehlen"

Dann fallen die AVR ganz klar raus, wahrscheinlich auch die PIC, aber da 
hab ich keinen so guten Überblick. Bei der Spalte STM32 könntest du dann 
schreiben "STM32F4".

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


Lesenswert?

Ich habe das mal geändert und die FLASH Größe mit rein geschrieben. bei 
den anderen µC bin ich allerdings nicht auf dem laufenden und zu faul 
das heraus zu suchen. Dafür gibt es sicher genügend Fanboys die das 
gerne nachtragen.

von Frank M. (frank_m35)


Lesenswert?

Markus Müller schrieb:
> Ich habe das mal geändert und die FLASH Größe mit rein geschrieben. bei
> den anderen µC bin ich allerdings nicht auf dem laufenden und zu faul
> das heraus zu suchen. Dafür gibt es sicher genügend Fanboys die das
> gerne nachtragen.

Gerne, die Zahlen erfreuen werden dich sicherlich nicht :-P

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


Lesenswert?

Wir wollen doch alle bei der Wahrheit bleiben ...
Breakpoints mindestens einer und bis zu 10.
Und wenn man so ein Mini-PIC erwischt der der nur einen drin hat, dann 
wird der eine für das durchsteppen benötigt und man kann keinen zweiten 
wo anders sitzen haben. (Ich habe da auch schon geflucht.)

von (prx) A. K. (prx)


Lesenswert?

Markus Müller schrieb:
>> 1 Befehl == 32 Bit (normalerweise)?
>
> Nein. Ein Befehl kann auch weniger Bits haben, z.B. um noch 1 Byte zu
> laden oder relative Sprünge aus zu führen.
> Kann aber auch mehr haben wenn noch 32 Bit irgendwo hin geladen werden
> oder gesprungen wird.

Genau genommen gibt es nur Befehle mit 16 und 32 Bits Länge. Allerdings 
existieren im Assembler Pseudo-Maschinenbefehle, die effektiv aus 2 
echten Maschinenbefehlen bestehen.

Beim Cortex-M0 sind mit einer Ausnahme alle Befehle 16 Bits breit - und 
diese Ausnahme war ursprünglich ebenfalls ein Komposit aus 2 Befehlen.

: Bearbeitet durch User
von Frank M. (frank_m35)


Lesenswert?

Markus Müller schrieb:
> Wir wollen doch alle bei der Wahrheit bleiben ...
> Breakpoints mindestens einer und bis zu 10.
> Und wenn man so ein Mini-PIC erwischt der der nur einen drin hat, dann
> wird der eine für das durchsteppen benötigt und man kann keinen zweiten
> wo anders sitzen haben. (Ich habe da auch schon geflucht.)

Na wenn man so genau ist, dann muss man auch ehrlich beim STM32F0 sein, 
der nur 4 Hardware Breakpoints unterstützt:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0432c/Bcgbfdhc.html
Oder gar nur 2? Genaue Angaben seitens STM fand ich nicht.

: Bearbeitet durch User
von Markus W. (Firma: guloshop.de) (m-w)


Lesenswert?

Markus Müller schrieb:
> Wir wollen doch alle bei der Wahrheit bleiben ...

Genau. Dann gibts auch keinen Streit, weil die Fakten zählen. :-)
Langsam wird die Übersicht wertvoll und könnte einen eigenen Artikel 
schmücken, auf denn dann alle Einsteigerartikel (STM32, AVR, PIC, MSP430 
usw.) verlinken.

Ich hab ein paar Werte nachgetragen, bezieht sich auf die normalen AVR, 
nicht auf den XMEGA, aber im Bezug auf maximale Speichergröße sollte es 
da keinen sowieso Unterschied geben.

A. K. schrieb:
> Genau genommen gibt es nur Befehle mit 16 und 32 Bits Länge. Allerdings
> existieren im Assembler Pseudo-Maschinenbefehle, die effektiv aus 2
> echten Maschinenbefehlen bestehen.
>
> Beim Cortex-M0 sind mit einer Ausnahme alle Befehle 16 Bits breit - und
> diese Ausnahme war ursprünglich ebenfalls ein Komposit aus 2 Befehlen.

OK, dann sind zumindest M0 und AVR in dieser Hinsicht vergleichbar. 
Weiter ins Detail muss die Tabelle auch gar nicht gehen.

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


Lesenswert?

Weiß ich jetzt nicht, ich hatte noch nie einen F0 genutzt bisher nur 
F103, F2xx und F4xx
Ich denke beim F0 ist ein Cotex-M3 drin und der kann somit auch 6 und 
nicht nur 4.

Edit: der kleine STM32F030 hat ein Cortex-M0 drin und der hat nur 4 
Breakpoints.

: Bearbeitet durch User
von Michael S. (rbs_phoenix)


Lesenswert?

Ich finde es immer schön, wenn neue Artikel erstellt werden. Ich finde 
den Titel allerdings nicht treffend. Ich hätte erwartet, dass der 
Artikel für diejenigen ist, die sich bereits für den STM32 entschieden 
haben. Ich hätte vorgeschlagen, den Artikel gewissermaßen zu teilen. 
Einen Artikel, in dem sachlich und zahlentechnisch die gängigen uCs 
verglichen werden und auch ein paar Philosophien genannt werden, wie:
-Lochraster taugliche: Wenn man auf Breadboards ein bisschen spielen 
will (nicht nur uC sondern vielleicht auch in Kombination mit 
Analogtechnik)
-einfach gestrickte: Leicht (vollständig) zu verstehen, sprich 
übersichtliche Innenausstattung/Funktionsweisen.
-Alleskönner: Ein z.B. ARM auch für Anfänger-Projekte wie Lauflicht, 
Uhr, etc, damit man mehr Luft nach oben hat.

Also einfach eine Wahlhilfe. Diesen Artikel kann man dann auch gleich 
als Antwort auf die ganzen "Welcher Mikrocontroller für mich" posten.

Von da aus kann man dann auf weitere Artikel weiterverlinken, die sich 
dann mit der Einführung/Einstieg einer speziellen Mikrocontrollerfamilie 
befasst. In diesen Artikeln sollte bzw darf aus meiner Sicht aber mit 
keinem Wort eine andere uC-Familie erwähnt werden, da es nicht zum Thema 
gehört - nämlich die ersten Schritte nach der Wahl des uCs.

Markus Weber schrieb:
> "Große Programme mit mehr als 500.000 Befehlen"
>
> Dann fallen die AVR ganz klar raus, wahrscheinlich auch die PIC, aber da
> hab ich keinen so guten Überblick. Bei der Spalte STM32 könntest du dann
> schreiben "STM32F4".

Das Problem bei den PICs ist, dass bei den PICs eine große Bandbreite 
von Leistungen/Fähigkeiten vertreten ist. Es gibt schon PICs mit 512k 
ROM, bald auch mit 1 und 2MB ROM. Aber eben nicht bei den 8 bittern. 
Daher ist das aus meiner Sicht auch eher ein Vorteil statt Problem, dass 
man mit gleicher Soft- & Hardware alle uCs von Microchip bedienen kann. 
Doch das ist ja subjektiv.

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


Lesenswert?

Michael Skropski schrieb:
> Das Problem bei den PICs ist, dass bei den PICs eine große Bandbreite
> von Leistungen/Fähigkeiten vertreten ist. Es gibt schon PICs mit 512k
> ROM, bald auch mit 1 und 2MB ROM. Aber eben nicht bei den 8 bittern.
> Daher ist das aus meiner Sicht auch eher ein Vorteil statt Problem, dass
> man mit gleicher Soft- & Hardware alle uCs von Microchip bedienen kann.
> Doch das ist ja subjektiv.

Ich habe einen Zusatz in den Abschnitt "Eigene Fähigkeiten und Wünsche" 
hinzugefügt.

von Dr. Sommer (Gast)


Lesenswert?

Marcus W. schrieb:
> @ Dr. Sommer: der SAM3X8E unterstützt allerdings den gesammten
> AVR-Befehlssatz. Kann also alles des AVRs und noch mehr.
Wie funktioniert das denn? Wenn der Core eine Instruktion "0x08 0x46" 
sieht, woher weiß er ob das eine Thumb2 (Cortex-M3) Instruktion "mov r0, 
r1" oder eine AVR-Instruktion "sbci r16, 0x68" ist? Oder muss man da 
explizit umschalten wie bei Thumb vs. ARM Mode? Und wozu ist das 
überhaupt gut, kann der AVR-Befehlssatz irgendwas was der 
Thumb2-Befehlssatz nicht kann?

von Frank M. (frank_m35)


Lesenswert?

Ich habe mal die Tabelle überarbeitet, wenn man jetzt den ersten, 
dritten, vierten und fünften Abschnitt des Artikels in einen neuen 
einfügt, dann hat man einen schönen Vergleichsartikel gängiger 
Mikrocontroller. Teil 2 kann man meiner Meinung löschen, unnötige 
subjektive Stimmungsmache.

Dann kann man noch ein zwei Sätze zu den stärken der jeweilligen 
Architektur schreib, ohne dabei wieder irgendwas schlecht reden zu 
müssen.

Der Rest ist dann STM spezifisch, was der Artikel eigentlich auch sein 
wollte, mit falschen Vermutungen, Behauptungen und unnützen Vergleichen 
jedoch das Ziel anfangs weit verfehlt hat.

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


Lesenswert?

Ich habe noch ein Punkt 9 hinzugefügt - der darf noch von entsprechenden 
Fanboys erweitert werden.

Punkt 2 würde ich lassen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Marcus W. schrieb:
> @ Dr. Sommer: der SAM3X8E unterstützt allerdings den gesammten
> AVR-Befehlssatz. Kann also alles des AVRs und noch mehr.

Das wär echt mal was Neues. Aber soweit ich erkennen kann haben die 
SAM3X einen ganz gewöhnlichen Cortex-M3 Kern, der mit einem 
AVR-Befehlssatz nichts an Hut hat.

von Moby (Gast)


Lesenswert?

W.S. schrieb:
> Anwendungen für den Haushalt sind ohnehin zumeist ein einziger Krampf.
> Aber wer braucht all das wirklich?

Da fehlt Dir aber arg Fantasie.
Meine Lebenszeit jedenfalls reicht nicht, um noch das alles zu 
entwickeln was mir für den Haushalt so vorschwebt.
Und brauchen tut mans immer dann wenn mans hinterher nicht mehr missen 
möchte. Und natürlich wenn das Entwickeln DAS Hobby ist :-)

von Dr. Sommer (Gast)


Lesenswert?

A. K. schrieb:
> Das wär echt mal was Neues.
Dann aber bitte noch einen 8051 und einen AMD64 Kern, um alle alte 
Software ohne Neukompilierung ausführen zu können!

von moeb (Gast)


Lesenswert?

Wenn jemand hier in die ARM-Welt einführen möchte, warum muss es dann 
ein mordsmäßiger Cortex M4 sein? Da wird der Einsteiger doch erschlagen.

Für "Einsteiger" macht ein Cortex M0 deutlich mehr Sinn. Siehe auch NXP 
LPC11xx-Reihe, gibt es bestimmt auch von STM...

von (prx) A. K. (prx)


Lesenswert?

Ob M0 oder M4 - dieser Unterschied ist dem Einsteiger erst einmal 
schnuppe. Merkt er nicht wirklich viel davon, zumindest nicht an 
Komplexität. Und die Timer oder GPIOs innerhalb der STM32 oder LPC1000 
Familien sind sich verdammt ähnlich. Die grösseren haben hauptsächlich 
mehr davon als die kleinen, und zusätzliche Module, die man erst einmal 
nicht braucht (oder auch nie).

Wenn man von etwas erschlagen wird, dann von der Komplexität 
beispielsweise eines Timers der STM32 im Vergleich zu den viel 
einfacheren der AVRs, und von Kleinigkeiten der Grundkonfiguration wie 
diversen Takten von diversen Bussen und der Notwendigkeit, die 
einzurichten.

: Bearbeitet durch User
von Helmut S. (helmuts)


Lesenswert?

Wie muss sich ich das mit dem GCC entpacken verstehen?

Aus http://www.mikrocontroller.net/articles/STM32_CooCox_Installation

> Die Installation der CoIDE nach z.B. C:\CooCox ausführen.

> Den Ordner C:\CooCox\CoIDE\gcc-arm-none-eabi-4.8 anlegen und die Dateien aus dem 
zweiten Download dort hinein entpacken.


Bedeutet das ich soll den GCC...zip-file auspacken und einfach dort 
entpacken anstatt den den installer GCC...exe richtig zu installieren?

https://launchpad.net/gcc-arm-embedded/+download

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


Lesenswert?

Helmut S. schrieb:
> Wie muss sich ich das mit dem GCC entpacken verstehen?
>
> Aus http://www.mikrocontroller.net/articles/STM32_CooCox_Installation
>
>> Die Installation der CoIDE nach z.B. C:\CooCox ausführen.
>
>> Den Ordner C:\CooCox\CoIDE\gcc-arm-none-eabi-4.8 anlegen und die Dateien aus 
dem
> zweiten Download dort hinein entpacken.
>
>
> Bedeutet das ich soll den GCC...zip-file auspacken und einfach dort
> entpacken anstatt den den installer GCC...exe richtig zu installieren?
>
> https://launchpad.net/gcc-arm-embedded/+download

Ich hatte das ZIP geladen und nicht die EXE. Das ZIP einfach entpacken. 
Ich ergänze das noch im Artikel.
Der GCC macht nichts in extra Windows-Verzeichnisse, auch nichts in der 
Registry, daher reicht ein einfaches Entpacken.

von Helmut S. (helmuts)


Lesenswert?

Hallo Markus,

danke für die Klarstellung und guten Rutsch ins neue Jahr.

Gruß
Helmut

von Harald N. (haraldn)


Lesenswert?

Hab mir gerade den Artikel angesehen. Bezüglich der 
Preisvergleichstabelle:
Wenn man das STM32F4 Discovery-Board nennt, sollte man vlt auch bei 
MSP430 das Launchpad erwähnen, das im Vergleich zum genannten Demoboard 
weniger als $10 (direkt von TI) kostet. Es verfälscht sonst ganz leicht 
die Verhältnisse.

von Falk B. (falk)


Lesenswert?

@ Harald Nagy (haraldn)

>weniger als $10 (direkt von TI) kostet. Es verfälscht sonst ganz leicht
>die Verhältnisse.

Wenn das mal keine Absicht ist ;-)

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


Lesenswert?

Dann schreibe dieses Board incl. Link der Bezugsquelle mit dazu.

von mknoelke (Gast)


Lesenswert?

Markus Müller schrieb:
> Wie ja jeder weiß bin ich STM32 Lastig.
Missionarischer Übereifer trifft es eher.

Markus Müller schrieb:
> Es soll schlussendlich aufzeigen, dass es zwischen den einzelnen
> Varianten (STM32/AVR/PIC/MSP430/...) doch kein großer Unterschied gibt
> und es eigentlich (bis auf wenige Ausnahmen) kaum Gründe gibt warum man
> nicht mit einem STM32 anfangen sollte.

Schönes nicht-Argument.
Es gibt im Umkehrschluss also kaum Gründe warum man nicht etwas anderes 
nehmen sollte wo die Unterschiede doch so klein sind.

Setzt die STM32 Brille mal hin und wieder ab ist schlecht für die Augen 
immer auf den gleichen Fleck zu starren.

Du bist bestimmt fit beim STM32 aber nicht so sehr bei dem Rest und 
vielleicht auch ein wenig einseitig in der Wahrnehmung.
Das ist manchmal informativ, manchmal unterhaltsam und des häufigeren 
einfach etwas nervig.
Das hier ist mikrocontroller.net und nicht stm32.net und das finde ich 
auch ziemlich gut so.

Du schreibst auch gute Beiträge aber wenn Pastor mmvisual wieder von der 
ewigen Verdammnis und den Versuchungen der Teufel AVR und PIC predigt 
klappen die meisten doch schon die Ohren nach innen.

Nichts für ungut, aber manchmal ist das alles ein wenig zu penetrant.
Ein guter Verkäufer muss auch erkennen können wenn es genug ist.

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


Lesenswert?

Ich bin IMMER angemeldet. Ich stehe zu meinem Wort und JEDER kann mir 
ein PN schreiben - wenn er mag.
Und: Einer muss hier ja STM32 lastig sein - nervige und penetrante AVR 
Fanboys gibt es in diesem Forum ja mehr als genügend - die sich meist 
nicht einmal trauen an zu melden.
Und ich kenne viele andere µC weil ich schon über 20 Jahre welche 
programmiere - damals gab es (leider) noch keinen STM32.
Wer hier aufmerksam mit liest, der weiß auch dass ich nicht jedem einen 
STM32 empfehle.

von Petit Ennui (Gast)


Lesenswert?

In der Kosten-Tabelle 
(http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger) 
steht für den MSP430 ein Dragon zum Debugger für 50€. Wo kann ich dieses 
Gerät beziehen?

von Michael K. (Gast)


Lesenswert?

mknoelke = knoelke = Michael Knoelke, Selbstständiger Hard- 
Softwareentwickler, meist zu faul sich anzumelden.

Freut mich Ihre Bekanntschaft zu machen Herr Markus Müller.

Nun sei nicht bockig.
Ich bin weder AVR noch PIC Fanboy, sondern diesen Monat bin ich STM8 
Fanboy bitteschön.
Da es auch hier eine Vielzahl von STM32 Fans gibt sehe ich deinen 
Leidensdruck nicht. Du stichst einfach sehr dabei heraus jeden nur 
möglichen Thread in einen 'der STM32 ist aber besser' Thread zu kapern 
als ob diese Threads nicht schon 25% des Diskussionsvolumens ausmachen 
würden.

Deiner Argumentation folgend das jemand etwas sein muss weil es alle 
anderen nicht sind werde ich wohl anfangen müssen jedem den STM8S003F3 
an die Backe zu quatschen einfach weil den hier kein Mensch benutzt und 
ich den grad so toll finde. (was so nicht stimmt, aber sags keinem)

Warum sollte ich dir eine PN schreiben ?
Ist doch hier im Forum vom Techniker-Facebook viel Lustiger zu sehen wie 
Leute bei den geringsten Widerworten aus dem Leim gehen.

So, jetzt wo wir das geklärt haben sind wieder lieb, ja ?
Ich mach jetzt mal wieder mit dem STM8 rum und Du mit dem STM32.

von Moby (Gast)


Lesenswert?

Markus Müller schrieb:
> nervige und penetrante AVR
> Fanboys

Danke für die Blumen :)
Zwischen Fan und Fakten gibts aber schon einen Unterschied.
Aber prinzipiell finde ich die Leute informierenden Einsatz so wie 
Deinen gut. Egal ob für STM32 oder was anderes. Egal ob nervig oder 
penetrant.

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


Lesenswert?

Ich erinnere mich an Zeiten um 1990 mit meinem Schneider CPC6128 (sogar 
mit Disketten-Laufwerk). Ich habe das Teil programmiert, unter anderem 
einem EPROM Brenner selbst gebaut und auch den Z80 in Assembler 
programmiert weil der Leer-Test mit Basic A*sch-Lahm war. Und so meine 
ersten Z80 Systeme gebaut. Alles musste ich aus Büchern lernen - 
Internet gab es nicht. (Damals war die Hobby-Elektronik in Stuttgart 
wirklich noch Hobby+Elektronik nicht so wie heute Hobby+Chinaschrott.) 
Einkaufen = Fahren in große Städte wie Stuttgart und München.

Mit der Informationsvielfalt wie es die heute gibt wäre ich damals 
sicher viel schneller ans Ziel gekommen. Später bin ich dann umgestiegen 
auf den 68HC11 - und habe den mittels NV-RAM programmiert. Das war 
genial, endlich keine EPROM's mehr löschen...

Aber das alles ist überhaupt kein Vergleich zu den heutigen µC. Und ja, 
ich kenne wirklich viele - auch wie die innen funktionieren weil ich die 
in den Händen hatte.

Der STM32 gefällt mir deshalb am besten, weil der am üppigsten mit 
Peripherie bestückt ist und es aktuell ca. 278 aktive Varianten gibt. 
(Vergleich STM32F4xx <> LPC4xxx)
Ich fühle mich da einfach mit dem STM (endlich) frei, was mir seit 1990 
gefehlt hat.

: Bearbeitet durch User
von Moby (Gast)


Lesenswert?

Die Begeisterung teile ich. Wenn auch für viel weniger Bits = möglichst 
wenig Aufwand bei maximalem Nutzen.

von aloha (Gast)


Lesenswert?

Moby schrieb:
> viel weniger Bits = möglichst
> wenig Aufwand bei maximalem Nutzen

???

Warum verstehe ich das nicht? Warum steht die Bitbreite einer CPU für 
Komplexität und Aufwand?

von Moby (Gast)


Lesenswert?

Weil soviel mehr damit zusammenhängt.  Weitere Details bitte den 
zahlreichen Beiträgen zu diesem Thema entnehmen!
Aber ich habe auch mal eine Frage: Warum finden sich in der Codesammlung 
so sehr viel mehr 8Bit Projekte als alles höherbittige zusammen? Was zum 
Teufel hat das für einen Hintergrund?

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


Lesenswert?

Moby schrieb:
> Aber ich habe auch mal eine Frage: Warum finden sich in der Codesammlung
> so sehr viel mehr 8Bit Projekte als alles höherbittige zusammen? Was zum
> Teufel hat das für einen Hintergrund?

- Weil die 8-Bitter in deren Hersteller-Doku so grottenschlecht 
beschrieben sind, dass man die nochmals mittels Tutorial dokumentieren 
muss?
- Weil die 8-Bit-User alle kein Englisch können?
- Weil es die 8-Bitter schon seit 15 Jahren gibt und daher auch mehr 
Leute Tutorien geschrieben haben?
- Weil die 32-Bitter viel einfacher sind?
- Weil man die 8-Bitter verfusen kann?

<Salz in die Wunde streu...>

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Moby schrieb:

> Aber ich habe auch mal eine Frage: Warum finden sich in der Codesammlung
> so sehr viel mehr 8Bit Projekte als alles höherbittige zusammen? Was zum
> Teufel hat das für einen Hintergrund?

Liegt einfach daran, dass die 8-Bit-Controller deutlichen Vorlauf 
hatten. Als dieses Forum an den Start ging, gab es sehr viel 8-Bitter, 
aber nur sehr wenige, sehr teure 32er.

Aber das ändert sich gerade, wie man an der zunehmenden Anzahl an Fragen 
und den sehr preiswerten Entwicklungsboards zu den 32ern sieht.

von Moby (Gast)


Lesenswert?

Mach Dir doch mit diesen Aussagen nicht unnötig Feinde :)
Eine Wunde gibts nicht, dazu haben die 8-Bitter wirklich in genug 
Anwendungen ihre perfekte Eignung unter Beweis gestellt.

Aber die 32er sind schon was feines. Allein die pure Rechenleistung! 
Macht Eindruck. Und trotzdem verstaubt (auch?) bei mir ein 
Discovery-Board. Finde einfach keinen Einsatzzweck. Aber immerhin, es 
hat nur 15 Euro gekostet.

von m.n. (Gast)


Lesenswert?

Markus Müller schrieb:
> Der STM32 gefällt mir deshalb am besten, weil der am üppigsten mit
> Peripherie bestückt

Quantität ersetzt keine Qualität.

von Moby (Gast)


Lesenswert?

Chris D. schrieb:
> Aber das ändert sich gerade

Nun gut, in 10 Jahren sollte man das nochmal beurteilen. Meine Prognose 
wäre wenn die 32bitter bis dahin nicht mit einfacherer 
Programmierbarkeit und innovativeren Features aufwarten bleibt ihnen bei 
typischen 8-Bit Anwendungen nur eine Außenseiterrolle.

von Pepp (Gast)


Lesenswert?

Moby schrieb:
> wenn die 32bitter bis dahin nicht mit einfacherer
> Programmierbarkeit

Ein STM32 ist einfacher zu programmieren als ein AVR: er hat keine 
Fuses!

von Moby (Gast)


Lesenswert?

Einen Xmega kann man so auch nicht unbrauchbar machen. Verfusen war nun 
auch nicht gerade Schicksal welches einen zwangsläufig ereilen muß!

von Andy P. (bakaroo)


Lesenswert?

Mal was anderes: in dem o.g. Artikel ist dem Vergleich zw den 
Prozessorenfamilien relativ viel Raum eingeräumt. Dafür verhältnismäßig 
wenig dem Thema der eigentlichen Überschrift.
Wäre es nicht sinnvoller, entweder diesen Vergleich in ein extra Artikel 
zu packen oder zu kürzen? Ein Neuling im uC-Bereich, der mit dem STM32 
einsteigen will, könnte hier schnell das Interesse verlieren.

von Lothar (Gast)


Lesenswert?

Moby schrieb:
> dazu haben die 8-Bitter wirklich in genug
> Anwendungen ihre perfekte Eignung unter Beweis gestellt

Das mag schon sein, aber:

MCU-Umsätze laut aktuellem Market Report:

8-bit:   2010:5.545   2013:4.412

32-bit:  2010:5.780   2013:6.916

32-bit ist hier tatsächlich MCU (beinhaltet also nur Cortex-M, nicht 
Cortex-A).

Und der LPC810 DIP-8 wurde nicht für Bastler aufgelegt, sondern für 
Großkunden in China, die ATtiny ersetzen wollen. Siehe auch hier:

This is a bold move towards making 8-bit architectures obsolete - See 
more at: http://www.nxp.com/campaigns/lpc800-go

von Moby (Gast)


Lesenswert?

Wie solche Zahlen richtig einzuschätzen sind vermag ich nicht zu sagen. 
Aber man kann schon den Eindruck gewinnen daß hier ein Krieg der Worte 
und der Preise entbrannt ist um den 8Bittern auf Teufel komm raus 
Marktanteile abzunehmen. Anders kann ich mir den Preis eines Evaluation 
STM32 Discovery oder eines Infineon XMC1000 Boards bei ~10 EUR nicht 
erklären.

von Lothar (Gast)


Lesenswert?

Moby schrieb:
> Aber man kann schon den Eindruck gewinnen daß hier ein Krieg der Worte
> und der Preise entbrannt ist um den 8Bittern auf Teufel komm raus
> Marktanteile abzunehmen.

Das würde wirtschaftlich keinen Sinn machen. Es ist wirklich so, dass 
32-bit inzwischen billiger zu fertigen ist als 8-bit, das liegt einfach 
an der Strukturbreite. Trotzdem werden die 32-bit nicht günstiger 
angeboten, z.B. die vergleichbaren LPC810 und ATtiny25 kosten in 
Stückzahlen beide 40 Cent. Es ist aber davon auszugehen, dass der LPC810 
billiger zu fertigen ist, somit macht NXP Gewinn damit, den ATtiny25 zu 
ersetzen.

Moby schrieb:
> Anders kann ich mir den Preis eines Evaluation
> STM32 Discovery oder eines Infineon XMC1000 Boards bei ~10 EUR nicht
> erklären.

Ein z.B. STM32F407 kostet in Stückzahlen 5 EUR. Auf dem 10 EUR Discovery 
ist sonst ja nicht viel drauf. Ist also nicht subventioniert. Und Atmel 
nimmt für ein vergleichbares SAM4 Board 35 EUR, was vermutlich schlecht 
für die Verbreitung ist.

von Michael K. (Gast)


Lesenswert?

Schneider CPC6128, mein erster.
Ja auch ich habe einen Eprom brenner selbst gebaut, mit dem Heißluftfön 
8085er aus Industrieschrott entlötet um in die wunderbare Welt der 
Prozessoren einzusteigen und musste in den Abteilungen betteln gehen 
damit ich alte Datenbücher bekam.
Der 8051 war meine erste Erlösung, was der alles hatte, ein Wahnsinn.
Ja, hat sich alles ganz gut entwickelt.
Alle haben sich ganz gut entwickelt.

Ich will hier niemandes Leistungen schmälern.
Ich mag nur diese künstlich am Leben erhaltenen Chip Kriege nicht und 
die häufig vertretene Einstellung das gerade Anfänger wie Teufel 
aufpassen müssen sich jetzt ja nicht für einen falschen Chip zu 
entscheiden. Das ist ganz einfach für niemanden hifreich.

Soviel Emotionen um ein Rechenwerk mit Peripherie, Speicher und eine 
individuelle Art das miteinander zu verheiraten.

Markus Müller schrieb:
> - Weil die 8-Bitter in deren Hersteller-Doku so grottenschlecht
> beschrieben sind, dass man die nochmals mittels Tutorial dokumentieren
> muss?
> - Weil die 8-Bit-User alle kein Englisch können?
> - Weil es die 8-Bitter schon seit 15 Jahren gibt und daher auch mehr
> Leute Tutorien geschrieben haben?
> - Weil die 32-Bitter viel einfacher sind?
> - Weil man die 8-Bitter verfusen kann?

Schau mal, genau das meine ich.
Was soll das ?
Du befeuerst den Krieg durch persönliche Beleidigungen und 
Herabsetzungen.
Ich finde das unprofessionel.

Ich könnte unter Anwendung Deiner kleinen Liste hier jetzt einwenden das 
es kein Wunder ist das Du so schlechte Erfahrungen mit 8bittern gemacht 
hast, weil du noch zu schlecht Englisch konntest um das Datenblatt zu 
verstehen.
Da es auch noch keine Tutorien gab hast Du die immer verfused und jetzt 
hasst Du alles was 8bit ist.
Das einzuwenden wäre aber übelster Sarkassmus und davon möchte ich mich 
in aller Form distanzieren.

Relax, Alter.

von F. F. (foldi)


Lesenswert?

Markus Müller schrieb:
> Moby schrieb:
>> Aber ich habe auch mal eine Frage: Warum finden sich in der Codesammlung
>> so sehr viel mehr 8Bit Projekte als alles höherbittige zusammen? Was zum
>> Teufel hat das für einen Hintergrund?
>
> - Weil die 8-Bitter in deren Hersteller-Doku so grottenschlecht
> beschrieben sind, dass man die nochmals mittels Tutorial dokumentieren
> muss?
> - Weil die 8-Bit-User alle kein Englisch können?
> - Weil es die 8-Bitter schon seit 15 Jahren gibt und daher auch mehr
> Leute Tutorien geschrieben haben?
> - Weil die 32-Bitter viel einfacher sind?
> - Weil man die 8-Bitter verfusen kann?
>
> <Salz in die Wunde streu...>

Und wieso gibt es für den STM32 fast ausschließlich chinesische Bücher?

von Michael S. (rbs_phoenix)


Lesenswert?

Markus Müller schrieb:
> Moby schrieb:
>> Aber ich habe auch mal eine Frage: Warum finden sich in der Codesammlung
>> so sehr viel mehr 8Bit Projekte als alles höherbittige zusammen? Was zum
>> Teufel hat das für einen Hintergrund?
>
> - Weil die 8-Bitter in deren Hersteller-Doku so grottenschlecht
> beschrieben sind, dass man die nochmals mittels Tutorial dokumentieren
> muss?
> - Weil die 8-Bit-User alle kein Englisch können?
> - Weil es die 8-Bitter schon seit 15 Jahren gibt und daher auch mehr
> Leute Tutorien geschrieben haben?
> - Weil die 32-Bitter viel einfacher sind?
> - Weil man die 8-Bitter verfusen kann?
>
> <Salz in die Wunde streu...>

Da dort immer Fragezeichen waren, könnte ich die Fragen auch 
beantworten:
Nein, Nein, Joa, kann ich nicht beurteilen, Nein (zumindest weiß ich, 
dass es bei AVRs geht und bei PICs nicht. Von dem Problem bei anderen 
Familien weiß ich nichts)


Pepp schrieb:
> Moby schrieb:
>> wenn die 32bitter bis dahin nicht mit einfacherer
>> Programmierbarkeit
>
> Ein STM32 ist einfacher zu programmieren als ein AVR: er hat keine
> Fuses!

Was fängt man denn mit einem STM32 an, wenn durch (mit ein paar klicks 
oder Zeilen Code) die Fuses setzen das programmieren schon als schwerer 
gilt?? Oo Das Argument ist für mich nicht nachvollziehbar. Wenn ich die 
"Fuses" setze (bei PICs CONFIG-Wörter), dauert das ca 1 Minute. Relativ 
gesehen zum Aufwand und Anspruch der folgenden Programme irrelevant.


Andy P. schrieb:
> Mal was anderes: in dem o.g. Artikel ist dem Vergleich zw den
> Prozessorenfamilien relativ viel Raum eingeräumt. Dafür verhältnismäßig
> wenig dem Thema der eigentlichen Überschrift.
> Wäre es nicht sinnvoller, entweder diesen Vergleich in ein extra Artikel
> zu packen oder zu kürzen? Ein Neuling im uC-Bereich, der mit dem STM32
> einsteigen will, könnte hier schnell das Interesse verlieren.

Ja, das hatte ich auch schonmal angemerkt. Ist aber wohl irgendwie 
untergegangen:

Michael Skropski schrieb:
> Ich finde es immer schön, wenn neue Artikel erstellt werden. Ich finde
> den Titel allerdings nicht treffend. Ich hätte erwartet, dass der
> Artikel für diejenigen ist, die sich bereits für den STM32 entschieden
> haben. Ich hätte vorgeschlagen, den Artikel gewissermaßen zu teilen.
> Einen Artikel, in dem sachlich und zahlentechnisch die gängigen uCs
> verglichen werden und auch ein paar Philosophien genannt werden, wie:
> -Lochraster taugliche: Wenn man auf Breadboards ein bisschen spielen
> will (nicht nur uC sondern vielleicht auch in Kombination mit
> Analogtechnik)
> -einfach gestrickte: Leicht (vollständig) zu verstehen, sprich
> übersichtliche Innenausstattung/Funktionsweisen.
> -Alleskönner: Ein z.B. ARM auch für Anfänger-Projekte wie Lauflicht,
> Uhr, etc, damit man mehr Luft nach oben hat.
>
> Also einfach eine Wahlhilfe. Diesen Artikel kann man dann auch gleich
> als Antwort auf die ganzen "Welcher Mikrocontroller für mich" posten.
>
> Von da aus kann man dann auf weitere Artikel weiterverlinken, die sich
> dann mit der Einführung/Einstieg einer speziellen Mikrocontrollerfamilie
> befasst. In diesen Artikeln sollte bzw darf aus meiner Sicht aber mit
> keinem Wort eine andere uC-Familie erwähnt werden, da es nicht zum Thema
> gehört - nämlich die ersten Schritte nach der Wahl des uCs.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Lothar schrieb:
> Moby schrieb:
>> Aber man kann schon den Eindruck gewinnen daß hier ein Krieg der Worte
>> und der Preise entbrannt ist um den 8Bittern auf Teufel komm raus
>> Marktanteile abzunehmen.
>
> Das würde wirtschaftlich keinen Sinn machen. Es ist wirklich so, dass
> 32-bit inzwischen billiger zu fertigen ist als 8-bit, das liegt einfach
> an der Strukturbreite. Trotzdem werden die 32-bit nicht günstiger
> angeboten, z.B. die vergleichbaren LPC810 und ATtiny25 kosten in
> Stückzahlen beide 40 Cent. Es ist aber davon auszugehen, dass der LPC810
> billiger zu fertigen ist, somit macht NXP Gewinn damit, den ATtiny25 zu
> ersetzen.

Ja, ich denke, man muss das auch aus Herstellersicht sehen. Die 
Gewinnmargen im 32-Bit-Segment sind durch die neue Fertigungstechnik 
höher. Gleichzeitig drücken die 32er die 8er preislich natürlich nach 
unten, so dass da wenig Spielraum für höhere Preise bleibt. Gleichzeitig 
tobt bei ARM-Kernen ein übler Kampf, was die 32-Bit-Preise ordentlich 
drückt.

Wenn man bei gleichem Preis die Auswahl zwischen 32- und 8-Bit hat, dann 
wählt man eben das größere. Also muss ein 8er preislich deutlich 
interessanter sein (=deutlich preiswerter). Aber der Platz zwischen 
Gehäuse/Bonding/Vertriebskosten und den ersten 32ern wird eben immer 
enger.
Im Moment können die Hersteller das bei den Stückzahlen und dem Abstand 
noch leisten, aber der Abstand ist in den letzten zwei Jahren deutlich 
geringer geworden und irgendwann wird der Punkt kommen, dass die 
rückläufigen Margen (nicht einmal so sehr die Stückzahlen) die Fertigung 
unrentabel machen.

> Moby schrieb:
>> Anders kann ich mir den Preis eines Evaluation
>> STM32 Discovery oder eines Infineon XMC1000 Boards bei ~10 EUR nicht
>> erklären.
>
> Ein z.B. STM32F407 kostet in Stückzahlen 5 EUR. Auf dem 10 EUR Discovery
> ist sonst ja nicht viel drauf. Ist also nicht subventioniert. Und Atmel
> nimmt für ein vergleichbares SAM4 Board 35 EUR, was vermutlich schlecht
> für die Verbreitung ist.

Davon abgesehen wird ST als Hersteller des Boards sicher keine 5 Euro 
Kosten haben. Klar, Gewinn werden sie daran nicht machen. Aber Verluste 
auch nicht.

Und natürlich dient es der Köderung von Neukunden. Ist auch richtig. Wer 
bekannt werden will, muss an die zukünftigen Entwickler ran. Da sind 
solche Boards wunderbar - zumal mit echter Debuggingmöglichkeit quasi 
für lau - wie beim STM32XX-Discovery.

Andere Hersteller haben von Atmel gelernt, die das ja über lange Zeit 
klug gemacht haben.

von leluno (Gast)


Angehängte Dateien:

Lesenswert?

F. Fo schrieb:
> Warum ich nicht weiter damit gemacht habe? Ganz einfach, wie kriege ich
> den auf ein Streifenraster?
Die Verbindung zum Sreifenraster ist nicht schwierig. Lässt sich ohne 
weteres mit einer 90Watt Lötpistole löten. Über eine einfache 
20Pin-Buchsenleiste lassen sich AVR-Anwendungen 1:1 mit ARM-CPUs 
betreiben.

von hans (Gast)


Lesenswert?

@markus,

in deinem Artikel (übrigens super!) fehlt bei der Einstellung des Clocks 
noch eine wichtige Änderung (sonst laufen die per st Lib initialisierten 
Peripheriemodule wie zb. Usart nicht richtig):

Man muss noch in der stm32f4xx.h folgenden Wert auf den Quarz ändern!

#define HSE_VALUE    ((uint32_t)8000000)

Bitte trag das doch noch im Artikel mit ein.

Danke!
lg
hans

von easy (Gast)


Lesenswert?

hans schrieb:
> Bitte trag das doch noch im Artikel mit ein.

Mach doch selber. ;-P

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


Lesenswert?

Ich habe mal die Zeile hinzugefügt:
http://www.mikrocontroller.net/articles/STM32_CooCox_Installation#Clock_auf_168MHz_einstellen


In diesem Abschnitt möchte ich noch ein paar Worte über die 
Möglichkeiten der AF-Funktionen (Peripheriezuweisung zum GPIO):
http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger#Tipps_und_Tricks_bei_der_Programmierung

Wenn jemand mag, kann er hier im Forum was schreiben, dann übernehme ich 
gerne die Ideen in den Artikel.

: Bearbeitet durch User
von Raul (Gast)


Lesenswert?

Als ich den Thread zum ersten Mal entdeckt habe, war mir klar, dass es 
wieder so einen Krieg gibt. Immer das gleiche entweder PIC oder AVR. 
Jetzt nun STM32 vs (PIC oder AVR).

Ich klär das mal für alle auf. Mikrocontroler ist Mikrocontroller. Im 
Prinzip ist auch ein DSP ein Mikrokontroller. Für jedes Einsatzgebiet 
gibt es eine minimale Anforderung. Danach wird ausgesucht.

Und für die, die da einer Anderer Meinung sind, die Übersetzung:

8-bit ist für Leute die bis 8 zählen können und
32-bit ist für Leute die bis 32 zählen können usw.

von F. F. (foldi)


Lesenswert?

Raul schrieb:
> Als ich den Thread zum ersten Mal entdeckt habe, war mir klar, dass es
> wieder so einen Krieg gibt. Immer das gleiche entweder PIC oder AVR.
> Jetzt nun STM32 vs (PIC oder AVR).
>
> Ich klär das mal für alle auf. Mikrocontroler ist Mikrocontroller. Im
> Prinzip ist auch ein DSP ein Mikrokontroller. Für jedes Einsatzgebiet
> gibt es eine minimale Anforderung. Danach wird ausgesucht.
>
> Und für die, die da einer Anderer Meinung sind, die Übersetzung:
>
> 8-bit ist für Leute die bis 8 zählen können und
> 32-bit ist für Leute die bis 32 zählen können usw.

Endlich mal ne gescheite Erklärung.
32 ist ne ziemlich große Zahl, da werde ich doch erstmal weiter ist 8 
zählen, evtl. bis 16.

von Genervter (Gast)


Lesenswert?

F. Fo schrieb:
> da werde ich doch erstmal weiter ist 8
> zählen, evtl. bis 16.

Das kannst du halten wie ... Andere haben mehr drauf und nutzen aktuelle 
Technik. Das ist zukunfsträchtig, günstiger, mächtiger und nicht 
schwieriger.

Schreib etwas zum Thema oder schluck es runter.

von 8BitForever (Gast)


Lesenswert?

Genervter schrieb:
> F. Fo schrieb:
>> da werde ich doch erstmal weiter ist 8
>> zählen, evtl. bis 16.
>
> Andere haben mehr drauf und nutzen aktuelle
> Technik. Das ist zukunfsträchtig, günstiger, mächtiger und nicht
> schwieriger.

Hey Wahnsinn. 32bittianer haben mehr drauf!  Aber doch wohl nicht im 
Beurteilen von Aufwand und Nutzen? Der Rest der Behauptung gehört auch 
gleich mit in die Tonne.

von RuckiZucki (Gast)


Lesenswert?

Gernervtsein ist doch der erste Schritt hin zur Einsicht, also nicht 
ganz so beschränkt wie mancher Hardliner hier :-)

von Lollipop (Gast)


Lesenswert?

Tipp für alle Einsteiger: Mach Euch das Leben leicht und nehmt 8 Bits. 
Die 32 Bit nimmt man erst wenn es wirklich nötig ist. Das dürfte Euch 
noch nicht betreffen, es sei denn die Anwendung muss auf Biegen und 
Brechen Eindruck schinden.

von F. F. (foldi)


Lesenswert?

Genervter schrieb:

> Das kannst du halten wie ... Andere haben mehr drauf und nutzen aktuelle
> Technik. Das ist zukunfsträchtig, günstiger, mächtiger und nicht
> schwieriger.
>
> Schreib etwas zum Thema oder schluck es runter.

Hast ja recht, aber ich hab schon Schwierigkeiten die 8 Bit runter zu 
schlucken. 32 Bit schaffe ich dann sicher erst recht nicht.
Außerdem trinke ich eigentlich immer Alt.

So, Spaß beiseite!
Ich gehe den ganz anderen Weg und ich lerne ja noch. Ich versuche alles 
Mögliche aus dem Tiny10 raus zu holen. Genau das ist mein Ziel. Mit 
möglichst wenigen Mitteln etwas zu bewerkstelligen.
Am Gashahn drehen kann jeder, aber in den Kurven zeigt sich wer fahren 
kann.
Ich gehöre schon nicht im richtigem Leben irgendeiner Religion an, hier 
werde ich nicht damit anfangen.
Irgendwann mach ich sicher auch was mit nem STM32. Hab ja zwei oder drei 
Discovery's in der Progger Kiste liegen.

von Helmut S. (helmuts)


Lesenswert?

Hallo,
Heute ist es passiert. Ich konnte plötzlich das STM32F4 Discovery Board 
in der CooCox IDE nicht mehr flashen und debuggen. Das on-board ST-Link 
kam immer mit der Fehlermeldung "Connection failed". Hab dann alle 
möglichen Settings für Debugger und Download probiert. Nichts half.
Fest steht damit, dass man mit falschen Config-Befehlen am Port-A sich 
so aussperren kann, dass man in CooCox keinen neuen Code mehr auf den 
Prozessor flashen kann. Ich weiß nicht ob das mit einem echten externen 
ST-Link oder einem Segger J-Link auch so ist, dass man aus CooCox nicht 
mal mehr den "reparierten" Code flashen kann. Hoffentlich nicht.


Eigentlich wollte ich ja nur PA0 (Button-1) als Eingang konfigurieren. 
Hatte dazu einfach alle 16 Eingänge auf Input mode gesetzt.

GPIOA->MODER = GPIOA->MODER & 0x00000000;


Ich habe mich dann erinnert, dass es da noch ein Programmier-Programm 
"STM32 ST-Link Utility" gibt.
http://www.st.com/web/en/catalog/tools/PF258168
Das Flashen ging aber erst auch nicht. Dann habe ich in Settings das 
gewählt:
Target->Settings   Connection Mode: Connect under Reset
Damit konnte ich dann den "guten" Code wieder flashen und ab da klappte 
auch das Flashen und Debuggen in CooCox wieder.

Der bessere Befehl. Mit der Zeile verändere ich nur PA0.

GPIOA->MODER = GPIOA->MODER & 0xfffffffc; // Pin 0 als Eingang 
deklarieren

Wie macht man denn das allgemein besser um einen Eingang zu definieren?

Irgendwie habe ich den Eindruck jeder macht es anders (Bit oder Word) 
bzw. hat andere Libs.

Gruß
Helmut

: Bearbeitet durch User
von Ingo (Gast)


Lesenswert?

Helmut S. schrieb:
> Wie macht man denn das allgemein besser um einen Eingang zu definieren?

Du bist hier im falschen Thread. Hier geht wird nur über 32-bit bzw. 
über 8-bit gelästert.

von Genervter (Gast)


Lesenswert?

F. Fo schrieb:
> Ich versuche alles
> Mögliche aus dem Tiny10 raus zu holen. Genau das ist mein Ziel.

Wenn du damit Geld verdienen musst, hast du andere Ziele.
Mit deinem Amateurgefasel zerstörst du hier einen Thread nach dem 
anderen.

von Ingo (Gast)


Lesenswert?

F. Fo schrieb:
> Ich versuche alles
> Mögliche aus dem Tiny10 raus zu holen.

Bist Du Schwabe? Da wird koi Transischtorle vrschenkt !!

F. Fo schrieb:
> Am Gashahn drehen kann jeder, aber in den Kurven zeigt sich wer fahren
> kann.
Hm. Was heißt das nun? Programmierst Du morphing code auf dem Tiny?

von F. F. (foldi)


Lesenswert?

Genervter schrieb:
> F. Fo schrieb:
>> Ich versuche alles
>> Mögliche aus dem Tiny10 raus zu holen. Genau das ist mein Ziel.
>
> Wenn du damit Geld verdienen musst, hast du andere Ziele.
> Mit deinem Amateurgefasel zerstörst du hier einen Thread nach dem
> anderen.

Ach so, dürfen jetzt nur noch namenlose "Profis" hier was sagen?
Vielleicht nimmst du mal einen anderen Namen, "Humorloser" würde zu dir 
passen.

Wenn du so ein Profi auf diesem Gebiet bist, dann würdest du nicht so 
einen Mist raus hauen.
Gerade wenn du Geld damit verdienen musst und ein Tiny10 diese Aufgabe 
erfüllen kann, die dir gestellt wird, dann wäre die Lösung als Ganzes 
sicher günstiger als mit einem STM32.

Diese unterschwelligen Beleidigungen kannst du auch mal lassen.

: Bearbeitet durch User
von Lothar (Gast)


Lesenswert?

F. Fo schrieb:
> Gerade wenn du Geld damit verdienen musst und ein Tiny10 diese Aufgabe
> erfüllen kann, die dir gestellt wird, dann wäre die Lösung als Ganzes
> sicher günstiger als mit einem STM32.

Im Gegenteil, CM0 ist schon lange Zeit günstiger, nicht umsonst liegt 
der AVR-Marktanteil laut Market Report inzwischen bei < 3% (auch Atmel 
verkauft mittlerweile mehr ARM als AVR).

Lothar schrieb:
> MCU-Umsätze laut aktuellem Market Report:
>
> 8-bit:   2010:5.545   2013:4.412
>
> 32-bit:  2010:5.780   2013:6.916

von RuckiZucki (Gast)


Lesenswert?

@Genervter
Wer stets unter großem Aufwand 32bittig mit Kanonen auf Spatzen schießen 
muß kann schon mal sehr genervt wirken... Irgendwie den Durchblick 
verloren? Klingt doch alles andere als "Profi".

von Tempo (Gast)


Lesenswert?

Genervter schrieb im Beitrag #3495672:
Der Profi muss seine Programme *noch nach Jahren verstehen,
> ändern und erweitern* können.

So so. Das geht also nur in profihaften 32 Bit...

Und da ist er schon etliche Baustellen
> weiter.

Bei Dir gibts wahrscheinlich nur Baustellen...

von Matthias (Gast)


Lesenswert?

Die Frage nach 32-bit-Architekturen stellt sich doch heute ganz anders. 
Statements wie "mit Kanonen auf Spatzen schiessen" sind aus den 90ern. 
Die Vorteile von 8 und 16-bittern fallen zunehmend schneller. Preis und 
Leistungsaufnahme sind bis auf einige seltene Anwendungsfälle keine 
besonders guten Argumente mehr.
Aber ins Auge fallen die Nachteile. Wer viel Speicher braucht (grafische 
Interfaces, grosse Mengen Sensorwerte, etc..), mit modernen 
Kommunikationsprotokollen zu tun hat (USB, Ethernet&TCP/IP, etc..) oder 
einfach nur viel 32-bit+ und float-Arithmetik anwenden muss ist mit 8- 
oder 16-bit im Bereich des Flickschusterwerks. Was "geht" bzw. 
Jahrzehnte gehen musste und was sinnvoll ist sind eben doch zwei 
verschiedene Paar Schuhe.

Die Wirtschaft spiegelt den Trend auch gut wieder: 
http://www.elektroniknet.de/halbleiter/leistungshalbleiter/artikel/103187/1/

Der STM32 ist vielleicht nicht der einzige Vertreter einer neuen 
Generation von MCUs, aber er ist sicher einer der populärsten.
Dass Exoten wie der AVR früher oder später von der Bildfläche 
verschwinden zeichnet sich meiner Meinung nach auch schon langsam ab.

von Moby (Gast)


Lesenswert?

Matthias schrieb:
> Die Frage nach 32-bit-Architekturen stellt sich doch heute ganz
> anders.
> Statements wie "mit Kanonen auf Spatzen schiessen" sind aus den 90ern.
> Die Vorteile von 8 und 16-bittern fallen zunehmend schneller. Preis und
> Leistungsaufnahme sind bis auf einige seltene Anwendungsfälle keine
> besonders guten Argumente mehr.

Selten ist was anderes.

> Aber ins Auge fallen die Nachteile. Wer viel Speicher braucht (grafische
> Interfaces, grosse Mengen Sensorwerte, etc..), mit modernen
> Kommunikationsprotokollen zu tun hat (USB, Ethernet&TCP/IP, etc..) oder
> einfach nur viel 32-bit+ und float-Arithmetik anwenden muss

Rrrrichtig. Und keiner bestreitet das. Denn wir reden hier von den 
Abermillionen 8 Bit Anwendungen bei denen selbst Pic/Avr oft schon 
überdimensioniert sind. Man stelle sich vor, die konnten früher ganze 
Computer betreiben. Haste wohl nicht mehr miterlebt ?

> Dass Exoten wie der AVR früher oder später von der Bildfläche
> verschwinden zeichnet sich meiner Meinung nach auch schon langsam ab.

Exoten. Ja ja, ist schon OK.

von Wilhelm F. (Gast)


Lesenswert?

Helmut S. schrieb:

> Heute ist es passiert. Ich konnte plötzlich das STM32F4 Discovery Board
> in der CooCox IDE nicht mehr flashen und debuggen. Das on-board ST-Link
> kam immer mit der Fehlermeldung "Connection failed". Hab dann alle
> möglichen Settings für Debugger und Download probiert. Nichts half.
> Fest steht damit, dass man mit falschen Config-Befehlen am Port-A sich
> so aussperren kann, dass man in CooCox keinen neuen Code mehr auf den
> Prozessor flashen kann. Ich weiß nicht ob das mit einem echten externen
> ST-Link oder einem Segger J-Link auch so ist, dass man aus CooCox nicht
> mal mehr den "reparierten" Code flashen kann. Hoffentlich nicht.

Sowas gabs mal bei den LPC2000-Boards mit dem Keil Ulink. Wenn man den 
Watchdog benutzte, sperrte man sich damit für immer vom nächsten 
Flash-Vorgang aus. Es stand auch in irgend einem Tutorial. Jedoch gab es 
Abhilfe, es entstand kein Schaden, war aber lästig. Die LPC2000 konnten 
über das Flash-Utility auch neuen Code über den UART laden, welcher dann 
den Watchdog wieder abschaltete.

Haben die STM32 so eine Alternative nicht?

von Tempo (Gast)


Lesenswert?

Moby schrieb:
> Man stelle sich vor, die konnten früher ganze
> Computer betreiben

Wobei man noch ergänzen sollte: die VORGÄNGER der heutigen 8 Bitter wie 
Z80 usw. - und das noch mit ganz wenigen MHz. Man ist ganz leicht 
versucht die Leistung von AVR & Co geringzuschätzen. Wenn Hochsprachen 
allerdings mit Hardwareressourcen herumschleudern das es nur so kracht 
(auch dank ach so "professioneller" Programmierkünste) kann es schon mal 
sein daß da der arme 8Bitter nicht mehr mitkommt. Das sollte man hier 
freimütig zugeben.

von Wilhelm F. (Gast)


Lesenswert?

Tempo schrieb:

> Das sollte man hier
> freimütig zugeben.

Es gibt reichlich Anwendungen, wo ein 8-Bitter mit nur 0,33 MIPS sehr 
gut mit kommt, und sich sogar die meiste Zeit langweilt. Da könnte man 
noch den Takt reduzieren.

Z.B. habe ich so einen 8048 auf einem Steckbrett, der mit nur 1 MHz 
läuft. 200 kHz hätten mir auch gereicht. Programmiert wird er von mir in 
Assembler, ich glaube, dafür gab es auch noch keine 
Hochsprachencompiler.

von Michael S. (rbs_phoenix)


Lesenswert?

Auch mal ne allgemeine Frage: Wieso kann man sich bei einigen (vielen?) 
uCs mit einer falschen Config ausschließen?
Ich benutze bisher nur PICs und dort kann man sich, egal was man setzt 
oder nicht, nicht ausschließen. Man kann ein Leseschutz aktivieren, aber 
dann kann man eben noch löschen und neu schreiben.

von Moby (Gast)


Lesenswert?

Wilhelm F. schrieb:
>  200 kHz hätten mir auch gereicht.

Ja deshalb haben einige AVRs auch 128kHz Clockmodus.
Weil es für nicht wenige Anwendungen schon ausreicht!

> Programmiert wird er von mir in
> Assembler,

Bravo. Programmierung "von gestern" ist eben nicht deshalb schlechter 
weil sie älter ist.

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


Lesenswert?

Michael Skropski schrieb:
> Auch mal ne allgemeine Frage: Wieso kann man sich bei einigen (vielen?)
> uCs mit einer falschen Config ausschließen?

Die Hersteller bauen Sicherheiten ein, damit der Chip von den Chinesen 
nicht kopiert werden kann. Und wenn man diese Sperren aktiviert, so 
kommt man auch selbst nicht mehr ran.

Beispiel STM32F4xx:
Level 0 - Read-Out Protection 0xAA - Chip ungeschützt.
Level 1 - Wert !=0xAA &&  != 0xCC - Chip geschützt vor Auslesen, kann 
jedoch per Mass-Erase wieder verwendet werden
Level 2 - Chip protect 0xCC - damit ist der Chip nicht mehr bespielbar 
und man hat sich und die Chinesen komplett ausgesperrt. Kein JTAG und 
kein Bootloader

Ist alles im Flash Programming Manual beschrieben.

von Genervter (Gast)


Lesenswert?

F. Fo schrieb:
> Diese unterschwelligen Beleidigungen kannst du auch mal lassen.
F. Fo schrieb im Beitrag #3495687:
> Leider bist du nur ein dummer Schwätzer

Wenn man im Glashaus sitzt, ...

F. Fo schrieb im Beitrag #3495687:
> aber genau für so was ist so ein kleiner Tiny gedacht

Wofür Atmel die Dinger konzipiert hat, werden wir nicht wissen. Aber 
wenn ich eine Aufgabe mit dem Typ A und Typ B erstellen kann, die Dinger 
das Gleiche kosten, nehme ich den, der einfacher für mich ist. Heute ist 
das ein STM32 oder einer seiner Cortex Freunde.
Auch wenn du als Bastler mit dem AVR stehen bleibst, dreht sich die Welt 
trotzdem weiter.

Lies einmal den Titel: STM32 für Einsteiger ...
Du willst nicht beim STM32 einsteigen? Dann steig in deisem Thread aus. 
;)

von Michael S. (rbs_phoenix)


Lesenswert?

Markus Müller schrieb:
> Michael Skropski schrieb:
>> Auch mal ne allgemeine Frage: Wieso kann man sich bei einigen (vielen?)
>> uCs mit einer falschen Config ausschließen?
>
> Die Hersteller bauen Sicherheiten ein, damit der Chip von den Chinesen
> nicht kopiert werden kann. Und wenn man diese Sperren aktiviert, so
> kommt man auch selbst nicht mehr ran.
>
> Beispiel STM32F4xx:
> Level 0 - Read-Out Protection 0xAA - Chip ungeschützt.
> Level 1 - Wert !=0xAA &&  != 0xCC - Chip geschützt vor Auslesen, kann
> jedoch per Mass-Erase wieder verwendet werden
> Level 2 - Chip protect 0xCC - damit ist der Chip nicht mehr bespielbar
> und man hat sich und die Chinesen komplett ausgesperrt. Kein JTAG und
> kein Bootloader
>
> Ist alles im Flash Programming Manual beschrieben.

Aber für den Kopierschutz muss man doch das auslesen verhindern, sprich 
Level 0.
Sollen "die Chinesen" doch den Chip überschreiben, ist ja das Gleiche, 
wie nen neuen, gleichen Chip reinsetzen und neu programmieren.

von Tempo (Gast)


Lesenswert?

Scheint so der Genervte fragt gar nicht erst was er da entwickelt. 
Hauptsache 32 Bit. Und soll er mal die Überschrift lesen: Beitrag zum 
Krieg. Den führt er jedenfalls mit allen Mitteln :)

von Gibts N. (schneeblau)


Lesenswert?

Ich weiß ja nicht wer hier was persönlich nimmt...wohl eher du wenn man 
den Beitrag so liest...

von F. F. (foldi)


Lesenswert?

Gibts Ne schrieb:
> Ich weiß ja nicht wer hier was persönlich nimmt...wohl eher du wenn man
> den Beitrag so liest...

Wie du meinst. :-)

von Carsten S. (dg3ycs)


Lesenswert?

Hi,

Michael Skropski schrieb:
> Aber für den Kopierschutz muss man doch das auslesen verhindern, sprich
> Level 0.
> Sollen "die Chinesen" doch den Chip überschreiben, ist ja das Gleiche,
> wie nen neuen, gleichen Chip reinsetzen und neu programmieren.

Naja, die Komplettabschaltung der Programmierschnittstelle könnte schon 
ein Sicherheitsgewinn darstellen. Es gibt ja durchaus einige 
Angriffsmethoden mit denen es bei einzelnen Controllern möglich ist 
trotz gesetztem FuseBit den Programmspeicher erfolgreich auszulesen. (In 
dem auf Unterspannungen, unzulässige Taktsignale oder schnelle 
änderungen der Versorgungsspannung gesetzt wird. NAtürlich auch 
Kombinationen davon)

Zwar werden hier die Gegenmaßnahmen der Controllerhersteller auch immer 
ausgefeilter, aber wenn der Controller erst gar nicht mehr auf die 
Programmierschnittstelle zugreifen kann würde das schon einen 
Sicherheitsgewinn bedeuten.

Ich meine übrigends das ich eine ähnliche Funktion bei den höherbittigen 
PICs auch gesehen habe. Müsste noch einmal nachsehen, da noch nie 
verwendet.

Allerdings muss man hier wohl das von mir oben angesprochene bewusste 
Aussperren und das unbeabsichtigte Aussperren wie beim Verfusen 
Unterscheiden.
Beim beabsichtigten Aussperren wird ja bewusst die HArdware komplett 
abgeschaltet - sofern die entsprechenden Befehle in der 
Entwicklungsumgebung nicht so hinterlegt sind das ein kleiner 
Flüchtigkeitsfehler bereits dafür ausreicht finde ich diese Option 
durchaus richtig.

Das Verfusen (wie beim AVR) ist hingegen das unbeabsichtigte Aussperren, 
in dem der Eingang auf einen Modus geschaltet wird bei dem der Zugriff 
mit entsprechender Hardware noch möglich wäre, aber derjenige nicht über 
die nötige HArdware verfügt.
BEim AVR ist das ein echtes Problem da man aus versehen schnell beim 
Oszillator etwas falsch einstellen kann, der ORIGINAL Programmieradapter 
den die meisten Einsteiger verwenden aber zwingend einen 
funktionierenden µC Oszillator vorraussetzt. Eine wirklich ungünstige 
Kombination!
(Und ehrlich gesagt finde ich es höchst peinlich von Atmel das der 
immerhin 40 Euro teure Adapter nicht über den HV-Programmiermodus 
verfügt)

Bei den PIC kann das beispielsweise NICHT passieren da hier der 
Programmer den Takt mitliefert. Zudem ist beim PIC Programmer nicht am 
Aufwärts-Spannungswandler gespart worden so das damit die HV 
Programmierung praktisch zum Standard gehört, während der etwa gleich 
teure AVR ISP von der Hardware im Prinzip kaum mehr ist als ein 
einfacher USB-SPI Wandler...

Dennoch ist das "Verfusen" als "echtes Problem" und Argument gegen die 
8Bitter anzuführen eigendlich ein Armutszeugniss für den jeweiligen 
Schreiber. Es ist ein Ärgerniss, sicher, aber wen jemand allen ernstes 
behauptet das sei für ihn eine echte Verständnisshürde gewesen, so muss 
man sich doch wohl fragen ob der überhaupt in der Lage ist vernünftig 
Programmieren zu lernen oder ob es bei dem nicht eher immer beim 
Abschreiben und zusammenkopieren bleiben wird.

Und zum Rest der Diskussion:
ICh habe ja schon oben ettliche Beiträge weiter oben geschrieben bei 
echten Produkten entscheidet die Anwendung über die richtige 
Prozessorwahl. Das ist abhängig von Stückzahl und vorhandenen 
Vorleistungen. Sowie natürlich von den Anforderungen.

Und JA: Es ist auch absolut Unprofessionell in einem kommerziellen 
Produkt unnötig viel Energie darauf zu verschwenden den Code dermaßen 
kompakt zu halten das man wirklich den kleinsten verfügbaren µC nehmen 
könnte, wenn die größeren genau dasselbe kosten.

Aber hier geht es ja gar nicht um professionelle Entwicklungen sondern 
um den Einstieg! Und im gegensatz zur kommerziellen Produktentwicklung 
geht es hier doch für die meisten darum möglichst viel zu lernen.
Und JA: ICh bin der festen Überzeugung das durchaus richtig ist ZU 
LERNZWECKEN tatsächlich zu versuchen den Code so kompakt wie möglich zu 
halten. Hier ist begrenzte Ressource durchaus von vorteil da es neben 
dem für den Einsteiger besseren Überblick auch gleichzeitig ein größeres 
Bewustsein für die Auswirkungen des eigenen Programmierstils auf die 
Leistung des Ergebnisses schafft.

Und wer es einmal richtig gelernt hat wie man aus einem 8Bitter das 
maximale rausholt kann dann ohne Mehraufwand auch auf anderen 
Plattformen sehr effiziennte Programme schreiben. So jemand holt dann 
halt aus aus einem heute mitttelmäßigen CORTEX M3 Dinge heraus von denen 
so manch Ressourcenverschwender ("Ich habe es ja") selbst mit einem ARM9 
oder PIC32MZ nur träumen könnte. Und das vermutlich in einer Zeit wo die 
Codehinklatscher gerade mal die erste Struktur im Programm sehen...

Gruß
Carsten

von Lothar (Gast)


Lesenswert?

F. Fo schrieb im Beitrag #3497001:
> Selbst der F0 braucht insgesamt mehr Platz, was dann für so eine
> Taschenlampe schon eng wird.

LPC1101LVUK WLCSP25 2.2mm Package :-)

von F. F. (foldi)


Lesenswert?

Lothar schrieb:
> F. Fo schrieb im Beitrag #3497001:
>> Selbst der F0 braucht insgesamt mehr Platz, was dann für so eine
>> Taschenlampe schon eng wird.
>
> LPC1101LVUK WLCSP25 2.2mm Package :-)

Ok, ist ein Argument, wenn auch ein Reflowofen vorhanden sein sollte, 
aber gut, gebe ich mich in diesem Punkt geschlagen.  Kosten?

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


Lesenswert?

Wenn jemand einen Tiny mit einem Cortex vergleichen will, dafür ist wohl 
eher dieser Thread geeignet:
Beitrag "LPC800 existiert (fast) nicht in diesem Forum"

Der LPC800
- kostet gleich oder weniger
- hat grob die gleiche Anzahl Doku Seiten: 
(Beitrag "Re: LPC800 existiert (fast) nicht in diesem Forum")
- ist auch gleich einfach, da deutlich weniger Peripherie drin ist
- Hat auch relativ wenig Speicher - wenn jemand mit knappen Ressourcen 
umgehen möchte

Damit kann man mit einer Entwicklungsumgebung (IDE, JTAG-Adapter, 
gewonnene Erfahrung) von den super kleinen Mini-Anwendungen bin hin zu 
den aufwendigen alles erschlagen.
Wenn man als Einsteiger noch nichts gekauft hat, und gleich einen SEGGER 
J-Link EDU sich anschafft, kann man damit nicht nur die STM32 sondern 
auch LPC800, LPC1xxx, LPC4xxx und auch die anderen Hersteller (Atmel, 
Freescale, Nuvoton, usw.) mit ARM- oder Cortex-Kern nicht nur laden 
sondern auch debuggen. Man ist mit einer einzigen Geldausgabe viel 
Flexibler, als wie wenn man sich auf einen AVR einschießt - zumal der 
AVR JTAG Adapter auch Geld kostet und das nicht zu knapp.

: Bearbeitet durch User
von greg (Gast)


Lesenswert?

Nochmal zurück zu ultra low power: einzig die EFM32 scheinen da 
ordentlich zu sein.

"Full RAM and CPU retention + POR + BOD + RTC while using only 0.9 μA 
(Energy Mode 2)" ist doch mal eine Ansage! STM32L1 ist dagegen ein Witz, 
der braucht bei ähnlich konfigurierten Sleep-Modi deutlichst mehr. Was 
bringt superniedriger Verbrauch, wenn man dafür ALLES ausschalten muss? 
Den Schwachsinn will uns Microchip auch schon mit dem NanoWatt-Zeugs 
verkaufen.

von Lothar (Gast)


Lesenswert?

F. Fo schrieb:
>> LPC1101LVUK WLCSP25 2.2mm Package :-)
>
> Ok, ist ein Argument, wenn auch ein Reflowofen vorhanden sein sollte,
> aber gut, gebe ich mich in diesem Punkt geschlagen. Kosten?

Das war nicht ganz ernst gemeint, WLCSP ist nichts für Bastler, das 
bekommt man auch mit Reflowofen wohl nicht hin.

Der schon genannte LPC810 ist in Stückzahlen für 40 Cent zu haben und 
ist damit gegen etwas größere ATtiny z.B. 25 positioniert. Wie schon 
erwähnt sind die 40 Cent eigentlich überteuert, aber NXP will ja Gewinn 
machen, und solange Atmel die Preise nicht senkt, können sie es ja 
machen.

von F. F. (foldi)


Lesenswert?

Lothar schrieb:
> F. Fo schrieb:
>>> LPC1101LVUK WLCSP25 2.2mm Package :-)
>>
>> Ok, ist ein Argument, wenn auch ein Reflowofen vorhanden sein sollte,
>> aber gut, gebe ich mich in diesem Punkt geschlagen. Kosten?
>
> Das war nicht ganz ernst gemeint, WLCSP ist nichts für Bastler, das
> bekommt man auch mit Reflowofen wohl nicht hin.
>
> Der schon genannte LPC810 ist in Stückzahlen für 40 Cent zu haben und
> ist damit gegen etwas größere ATtiny z.B. 25 positioniert. Wie schon
> erwähnt sind die 40 Cent eigentlich überteuert, aber NXP will ja Gewinn
> machen, und solange Atmel die Preise nicht senkt, können sie es ja
> machen.

Vielen Dank, das war sehr aufschlussreich und ich werde das mal im 
Hinterkopf behalten.

von hans (Gast)


Lesenswert?

> WLCSP ist nichts für Bastler

Mit einer Heizplatte geht das schon. Ich habe da schon 676 Pin BGAs mit 
gelötet. Ging erstaunlich einfach und hat gleich beim ersten Versuch 
geklappt.

von Uli.R (Gast)


Lesenswert?

Um den Krieg noch ein bisschen anzuheizen... ich progge seit einiger 
Zeit meine STM32 mit diesem Sisi und UML ... wenn man sich erst mal dran 
gewöhnt hat geht das richtig fluffig und wirklich cool kommt das rüber 
wenn man mit seinem STM32 und einem Grafik-Display eine GUI zusammenbaut 
... guckst du hier:

http://www.myUGL.de

Uli

von chris_ (Gast)


Lesenswert?

> ...mit diesem Sisi und UML

SISy

http://www.sisy.de/index.php?id=97

Bin auch schon die ganze Zeit am Überlegen, ob ich das verwenden soll. 
Wie flüssig ist die Handhabung?

von Uli.R (Gast)


Lesenswert?

im ersten Moment ein Kulturschock :-o hab einen Kollegen der kommt da 
gar nicht ran aber es hat auch damit zu tun, dass es eben die UML in den 
Mittelpunkt stellt und der allseits geliebte Quelltexteditor eher nur 
ein Eingabefeld für den Code einer Methode ist... in der ersten zeit 
wollte ich immer zu den Ganzen Quelltext sehen und hab mir den alle paar 
Minuten anzeigen lassen jetzt schau ich in den kompletten Quelltext nur 
noch wenn ich einen kniffeligen Fehler suche... man muss sich aber ein 
bisschen für UML und C++ öffnen sonst hat man keine Freude an dem 
Tool... beim Debuggen müssen die in Sisy aber noch etwas nachlegen, man 
kann zwar auf Code und auf Modellebene debuggen aber das setzen von 
Unterbrechungspunkten und Überwachungsvariablen ist zum beispiel noch 
suboptimal. zieh dir doch einfach die DEMO und spiel ein bisschen mit 
rum ;-)

Uli

von W.S. (Gast)


Lesenswert?

Also, ich hab mir mal eines der Videos dort angeschaut. Das sieht mir 
doch sehr aus wie dieses "Easy Code" oder so ähnlich, was man seit 
Jahren auf der Embedded als Demo-Scheibe mitnehmen kann - wenn man denn 
will. Also in einer Art IDE irgendwelche Bauklötzchen (Taster, LCD, usw) 
plazieren und mit Strichen verbinden. Ich halte von solchen 
Pseudo-Vereinfachungen eigentlich nichts. Für welchen Einsatz-Zweck soll 
sowas gut sein? Obendrein wird dieses "Tool" ja nur am Rande für 
Mikroprozessor-Anwendungen propagiert und es wird als eine Art 
Allheilmittel angepriesen.

Ich zitiere mal:
"SiSy ist die Abkürzung für Simple System. Simple steht für eine 
einfache Vorgehensweise und übersichtliche Darstellung. System 
beschreibt dagegen eine strukturierte und methodische Konstruktion mit 
standardisierten Darstellungsmitteln. Die Größe der Systeme spielt dabei 
keine Rolle. Mit Hilfe von SiSy werden die Darstellungsmittel, welche 
zur Konstruktion eines Systems dienen, individuell und 
aufgabenspezifisch abgebildet."

So also, grafische Abbildung von Darstellungsmitteln von allgemeinen 
Systemen...  Ich hab da sehr heftige Zweifel, ob sowas DAS sein könnte, 
wonach mir der Sinn steht. Zuletzt hab ich vor rund 20 Jahren mit 
Söhnchen Bauklötze gespielt.

W.S.

von Boris O. (bohnsorg) Benutzerseite


Lesenswert?

Profis tun sich oft schwer, Einsteigerartikel zu schreiben, da 
wesentliche und grundlegende Erkenntnisse hinter der Menge an Fachwissen 
verborgen sind. Wenn du dir (@TO) das Arduino-Buch zum großen Set [1] 
durchliest, dann ist die Zielgruppe eine ganz andere. Da geht es weder 
um kleinsten Code noch um absonderliche Stromsparmodi oder ob nun eine 
Arithmetikfunktion vom Prozessor oder einer gelinkten Bibliothek 
erledigt wird (ATTiny vs. ATMEGA). Gleichzeitig halte ich es für 
fragwürdig, ob jemand die Transistorfunktion einzig durch Studium der 
physikalischen Hintergründe erlernte. Vielmehr hat man wohl etwas von 
Stromverstärkung gehört, ein paar Vorstufen und Schalter konstruiert und 
später stieg man um auf Kurvenscharen mit Abhängigkeiten zwischen 
Temperatur und Kollektorstromänderung als Emitterfolger. Gleichzeitig 
verstehe ich auch nicht, warum für das Einschalten einer LED 32bit 
besser sind als 8bit.

Beim Arduino darf man auch nicht außer Acht lassen, dass es sich um eine 
fertige Platine handelt, d.h. ich brauche keine Bastelkiste mit 
Abblockkondensatoren, Quarzen und Spannungsreglern. Etwas später stellt 
man dann u.U. fest, dass sich ein AVR auch ohne Quarz betreiben lässt 
und die Minimalbeschaltung für eine blinkende LED vollkommen ausreicht. 
Es reicht aber auch einen Multivibrator aus 2 Transistoren, 
Kondensatoren und Widerständen aufzubauen. Es ist auch nicht sonderlich 
viel Hexenwerk, eine Bibliothek in ein Programm einzubinden, um eine 
SD-Karte auszulesen. (Abschweifthema SiSy: Software through pictures – 
auch tot.)

Grande finale: Betamax war auch das bessere Videoaufzeichnungsverfahren 
und ich besuche auch niemanden, der nicht mindestens eine Laserdisc sein 
eigen nennt und abspielen kann. Mikrocontroller hingegen sind Werkzeuge, 
keine Unterhaltungselektronik.

[1] http://arduino.cc/de/Main/ArduinoStarterKit

von Embedded (Gast)


Lesenswert?

Lothar schrieb:
> Der schon genannte LPC810 ist in Stückzahlen für 40 Cent zu haben und
> ist damit gegen etwas größere ATtiny z.B. 25 positioniert. Wie schon
> erwähnt sind die 40 Cent eigentlich überteuert, aber NXP will ja Gewinn
> machen, und solange Atmel die Preise nicht senkt, können sie es ja
> machen.

Dazu kommt noch, dass der LPC800 eine echt tolle Peripheriematrix hat. 
Jede Peripherie auf jeden beliebigen Pin. Echt genial. Damit kann man 
wahnsinnig viele Einschränkungen umgehen und den kleinen Prozessor für 
Aufgaben einsetzen, für den man bei unflexibleren Chips schon viel 
größere uC verwenden muss.

von greg (Gast)


Lesenswert?

Uli.R schrieb:
> Um den Krieg noch ein bisschen anzuheizen... ich progge seit einiger
> Zeit meine STM32 mit diesem Sisi und UML ... wenn man sich erst mal dran
> gewöhnt hat geht das richtig fluffig und wirklich cool kommt das rüber
> wenn man mit seinem STM32 und einem Grafik-Display eine GUI zusammenbaut
> ... guckst du hier:

Naja, diese Tools haben massive (praktische) Probleme. Verstehe nicht 
wie man das freiwillig verwenden kann. Alle Jahre wieder wird ja gerne 
prophezeit, dass Programmieren ohne Code zu schreiben kommen wird... ich 
glaub da nicht so schnell dran. :) Es spricht ja nichts dagegen, 
UML-Tools zum Diagramme malen zu verwenden, aber wenn die einem 
versprechen, Code schreiben abzunehmen, wird es unseriös.

Ganz konkret: was ist z.B. mit Versionskontrolle und arbeiten im Team?

von Chris (Gast)


Lesenswert?

"Alle Jahre wieder wird ja gerne prophezeit, dass Programmieren ohne 
Code zu schreiben kommen wird... ich glaub da nicht so schnell dran. :)"

gibts doch schon ewig bei den SPSn
da zeichnest dafür funktionspläne :D

von greg (Gast)


Lesenswert?

Chris schrieb:
> "Alle Jahre wieder wird ja gerne prophezeit, dass Programmieren
> ohne
> Code zu schreiben kommen wird... ich glaub da nicht so schnell dran. :)"
>
> gibts doch schon ewig bei den SPSn
> da zeichnest dafür funktionspläne :D

Nicht zwangsweise. AWL und neuerdings SCL sind erstaunlich populär... 
warum wohl? AWL kann mehr und Klickorgien sind anstrengend und 
unübersichtlich. AWL ist arg low-level und doch häufig einfacher zu 
handhaben als FUP/KOP.

Naja, ich empfinde die typischen SPS-Programmiersprachen sowieso recht 
fremdartig und altbacken. Warum nicht sowas wie VHDL? :)

von Moby (Gast)


Lesenswert?

Embedded schrieb:
> Dazu kommt noch, dass der LPC800 eine echt tolle Peripheriematrix hat.
> Jede Peripherie auf jeden beliebigen Pin. Echt genial. Damit kann man
> wahnsinnig viele Einschränkungen umgehen

> und den kleinen Prozessor für
> Aufgaben einsetzen, für den man bei unflexibleren Chips schon viel
> größere uC verwenden muss.

Embedded schrieb:
> Lothar schrieb:
>> Der schon genannte LPC810 ist in Stückzahlen für 40 Cent zu haben...

Na bitte wo denn? Vielleicht für Industriekunden. Pic/AVRs gibts an 
jeder Ecke

> Dazu kommt noch, dass der LPC800 eine echt tolle Peripheriematrix hat.
> Jede Peripherie auf jeden beliebigen Pin. Echt genial. Damit kann man
> wahnsinnig viele Einschränkungen umgehen

Wieso das denn? Eine Anwendung wird mit der Hardware i.d.R.  für fixe 
Funktionen
designt. Die "echt tolle" Peripheriematrix ist ein schönes Beispiel wie 
mehr Flexibilität unnötig Komplexität rein bringt. Eine Fehlerquelle 
mehr wenn dann was nicht so funktioniert wie es soll.

> und den kleinen Prozessor für
> Aufgaben einsetzen, für den man bei unflexibleren Chips schon viel
> größere uC verwenden muss.

Also diese Behauptung ist nun wirklich sehr erklärungsbedürftig!

von greg (Gast)


Lesenswert?

Moby schrieb:
>>> Der schon genannte LPC810 ist in Stückzahlen für 40 Cent zu haben...
>
> Na bitte wo denn? Vielleicht für Industriekunden. Pic/AVRs gibts an
> jeder Ecke


Z.B. Mouser, da kannst du auch privat bestellen. Könnte aber besser 
sein, stimmt.

Moby schrieb:
>> und den kleinen Prozessor für
>> Aufgaben einsetzen, für den man bei unflexibleren Chips schon viel
>> größere uC verwenden muss.
>
> Also diese Behauptung ist nun wirklich sehr erklärungsbedürftig!

Kleinere Controller haben oft wenige Pins, und die sind dann oft doppelt 
und dreifach belegt. Man kann aber jeweils nur eine Funktion pro Pin 
nutzen. Mit der Switch Matrix gibt's das Problem nicht. Außer man hat 
keine Pins mehr übrig. ;)

von Moby (Gast)


Lesenswert?

Boris Ohnsorg schrieb:
> Profis tun sich oft schwer, Einsteigerartikel zu schreiben...

Echte & selbsternannte tun sich insbesondere schwer das Verhältnis von 
Aufwand und Nutzen richtig zu bewerten- wenn man zum Aufwand den 
Einarbeitungs/Lernaufwand hinzurechnet. Denn das Wissen habe sie ja 
schon und sie  können so auf mehr Auswahl zurückgreifen. Das können dann 
durchaus auch komplexere Typen wie ARM Derivate sein. Wenn es ein 
wohlbekannter einfacher 8Bit Typ ( in den meisten Fällen)  tut ist es 
einfach unsinnig sein 8 bittiges Biotop zu verlassen.

von Michael S. (rbs_phoenix)


Lesenswert?

Moby schrieb:
>> Dazu kommt noch, dass der LPC800 eine echt tolle Peripheriematrix hat.
>> Jede Peripherie auf jeden beliebigen Pin. Echt genial. Damit kann man
>> wahnsinnig viele Einschränkungen umgehen
>
> Wieso das denn? Eine Anwendung wird mit der Hardware i.d.R.  für fixe
> Funktionen
> designt. Die "echt tolle" Peripheriematrix ist ein schönes Beispiel wie
> mehr Flexibilität unnötig Komplexität rein bringt. Eine Fehlerquelle
> mehr wenn dann was nicht so funktioniert wie es soll.

Ich habe den Vorzug bei dem letzten Projekt von mir gemerkt (dsPIC). 
Alle Pins bis auf 2 belegt und ich war froh, dass ich die Pins aussuchen 
konnte bzgl Leiterplattenlayout.

von Moby (Gast)


Lesenswert?

greg schrieb:
> Moby schrieb:
>>>> Der schon genannte LPC810 ist in Stückzahlen für 40 Cent zu haben...
>>
>> Na bitte wo denn? Vielleicht für Industriekunden. Pic/AVRs gibts an
>> jeder Ecke
>
> Z.B. Mouser, da kannst du auch privat bestellen.

Ok, aber erst ab 10000. Und ich muß schon wieder die Frage stellen warum 
ich eine Anwendung die mit 88er Tiny zum Preis von weniger als 40 Cent 
für nur 100 Stück realisiert werden kann nun ausgerechnet auf eine neue 
Architektur umsteigen soll.

> Kleinere Controller haben oft wenige Pins

Ja wenn die Pinzahl nicht langt nehme ich einen mit mehr-  wo ist das 
Problem?

von spess53 (Gast)


Lesenswert?

Hi

>Kleinere Controller haben oft wenige Pins, und die sind dann oft doppelt
>und dreifach belegt. Man kann aber jeweils nur eine Funktion pro Pin
>nutzen. Mit der Switch Matrix gibt's das Problem nicht.

Da kann man dann mehrere Funktionen pro Pin benutzen? Oder ist das eher 
geeignet ein verkorkstes Layout zu korrigieren?

Ehrlich gesagt finde ich diese Diskussion teilweise recht praxisfremd. 
Wen interessieren ein paar Cent mehr oder weniger für den Controller 
wenn eine Frontplatte 100 +- x € kostet oder 1000µ/400V Elkos plötzlich 
mal das doppelte kosten.

MfG Spess

von greg (Gast)


Lesenswert?

spess53 schrieb:
>>Kleinere Controller haben oft wenige Pins, und die sind dann oft doppelt
>>und dreifach belegt. Man kann aber jeweils nur eine Funktion pro Pin
>>nutzen. Mit der Switch Matrix gibt's das Problem nicht.
>
> Da kann man dann mehrere Funktionen pro Pin benutzen? Oder ist das eher
> geeignet ein verkorkstes Layout zu korrigieren?
>

Ist das so schwer zu verstehen ober ich das falsch erklärt? :)

Beim erwähnten Tiny88 hat man z.B. auf einem Pin SS und OC1B. Wenn man 
SPI nutzt, hat man Pech gehabt und kann kein Output Compare nutzen. Mit 
der Switch Matrix gibt es diese Probleme nicht.

> Ehrlich gesagt finde ich diese Diskussion teilweise recht praxisfremd.
> Wen interessieren ein paar Cent mehr oder weniger für den Controller
> wenn eine Frontplatte 100 +- x € kostet oder 1000µ/400V Elkos plötzlich
> mal das doppelte kosten.

Ja, das finde ich allerdings auch. Die Preisdiskussion ist ziemlich 
sinnfrei.

von Moby (Gast)


Lesenswert?

greg schrieb:
> Beim erwähnten Tiny88 hat man z.B. auf einem Pin SS und OC1B. Wenn man
> SPI nutzt, hat man Pech gehabt und kann kein Output Compare nutzen. Mit
> der Switch Matrix gibt es diese Probleme nicht.

Ok, begriffen. Aber warum hatte ich ein solches Problem noch nicht? 
Vielleicht weil ich statt dessen einfach nur einen passenden Typ 
ausgesucht habe?

von spess53 (Gast)


Lesenswert?

Hi

>Ist das so schwer zu verstehen ober ich das falsch erklärt? :)

>Beim erwähnten Tiny88 hat man z.B. auf einem Pin SS und OC1B. Wenn man
>SPI nutzt, hat man Pech gehabt und kann kein Output Compare nutzen.

Wo steht das im Datenblatt?

MfG Spess

von Moby (Gast)


Lesenswert?

spess53 schrieb:
> Hi
>
>>Ist das so schwer zu verstehen ober ich das falsch erklärt? :)
>
>>Beim erwähnten Tiny88 hat man z.B. auf einem Pin SS und OC1B. Wenn man
>>SPI nutzt, hat man Pech gehabt und kann kein Output Compare nutzen.
>
> Wo steht das im Datenblatt?
>
> MfG Spess

Wobei ja nicht mal gesagt ist daß für SPI der SS Pin immer unbedingt 
erforderlich ist :-)

von F. F. (foldi)


Lesenswert?

Chris schrieb:
> "Alle Jahre wieder wird ja gerne prophezeit, dass Programmieren ohne
> Code zu schreiben kommen wird... ich glaub da nicht so schnell dran. :)"
>
> gibts doch schon ewig bei den SPSn
> da zeichnest dafür funktionspläne :D

Das gleiche sagte man auch über Spracheingabe, aber Siri und Konsorten 
werden auch immer besser und auch immer häufiger genommen.
Und wie sagt man so schön: Ein Bild sagt mehr als tausend Worte.
Denke schon, dass das auch mehr kommen wird. Ich allerdings, möchte doch 
erstmal richtig C können und würde dann auch nicht mehr so schnell 
abweichen.

von Lothar (Gast)


Lesenswert?

Moby schrieb:
> Und ich muß schon wieder die Frage stellen warum
> ich eine Anwendung die mit 88er Tiny zum Preis von weniger als 40 Cent
> für nur 100 Stück realisiert werden kann nun ausgerechnet auf eine neue
> Architektur umsteigen soll.

Viele "ARM-Anhänger" wie ich sind eben direkt vom 8051 auf ARM 
umgestiegen, und haben nie was mit AVR gemacht.  Dazu kommt dass bei NXP 
und STM die ARM-Peripherie zunächst vom 8051 kam, und somit die 
"Lernkurve" gering war.

Und wenn Du ein Produkt mit nur 100 Stück machst, dann ist der Preis vom 
uC praktisch egal.

Übrigens ist AVR (1994) gegenüber ARM (1986) die "neuere Architektur" 
:-)

von greg (Gast)


Lesenswert?

Lothar schrieb:
> Übrigens ist AVR (1994) gegenüber ARM (1986) die "neuere Architektur"
> :-)

Da kann man eigentlich nur erwidern, dass ARM Thumb ja eigentlich eine 
ganze neue Architektur ist, und von wann ist die? Genau: 1994. ;)

von Uli.R (Gast)


Lesenswert?

greg schrieb:
> Es spricht ja nichts dagegen,
> UML-Tools zum Diagramme malen zu verwenden, aber wenn die einem
> versprechen, Code schreiben abzunehmen, wird es unseriös.

dann sollte man sich vielleicht mal etwas näher mit dem UML Tool 
beschäftigen ;-) zum einen verspricht SiSy nicht dem Anwender das 
codieren abzunehmen man muss den Code für eine Funktion schon selber 
schreiben. Sisy generiert den teil des C++ Codes der um die Funktionen 
herum sonst mehr oder weniger von Hand aufgebaut werden muss, die 
Klassenrahmen/Systemstruktur. Und das durchaus effektiv denn von Hand 
muss man praktisch das selbe hinschreiben was auch der Generator 
produziert. Dabei belieben Visualisierung und Code immer synchron und 
das ist die einzigst seriöse variante UML zu betreiben. Unserieös ist es 
eine Konstruktionszeichnung zu malen die irgendwann mit dem 
tatsächlichen code nicht mehr übereinstimmt kein elektrotechniker würde 
sich waren einen Schaltplan abzugeben der nicht mit der tatsächlichen 
Schaltung übereinstimmt LOL

Was tatsächlich ein Streitpunkt ist wäre nicht UML oder nicht UML 
sondern ob C++ auf einem Mikrocontroller sinn macht ... Krieg die 2. :-o

Uli

von greg (Gast)


Lesenswert?

Uli.R schrieb:

> dann sollte man sich vielleicht mal etwas näher mit dem UML Tool
> beschäftigen ;-) zum einen verspricht SiSy nicht dem Anwender das
> codieren abzunehmen man muss den Code für eine Funktion schon selber
> schreiben.

Na das hört sich laut Website aber ganz anders an: "Quellcode komplett 
generieren, übersetzen, ausführen, debuggen".

> Sisy generiert den teil des C++ Codes der um die Funktionen
> herum sonst mehr oder weniger von Hand aufgebaut werden muss, die
> Klassenrahmen/Systemstruktur. Und das durchaus effektiv denn von Hand
> muss man praktisch das selbe hinschreiben was auch der Generator
> produziert.

Was ist der Mehrwert? Die Prototypen von Klassen und Funktionen kann ich 
selbst hinschreiben. Mit einer IDE geht das auch sehr schnell. Wenn der 
Zeitaufwand für das Code hinschreiben ein tatsächliches Problem ist, 
macht man etwas falsch oder schreibt nur Hello-World-Progrämmchen.

> Dabei belieben Visualisierung und Code immer synchron und
> das ist die einzigst seriöse variante UML zu betreiben. Unserieös ist es
> eine Konstruktionszeichnung zu malen die irgendwann mit dem
> tatsächlichen code nicht mehr übereinstimmt kein elektrotechniker würde
> sich waren einen Schaltplan abzugeben der nicht mit der tatsächlichen
> Schaltung übereinstimmt LOL
>

Ganz im Gegenteil: Modellierung und Implementierung gehören strikt 
getrennt. Die Modellierung beschreibt einen Soll-Zustand, die 
Implementierung den Ist-Zustand. Das Modell ist abstrakt und kann daher 
prinzipbedingt nicht der Implementierung entsprechen. In der Regel 
sollte man deshalb einen sich wiederholenden Prozess anstreben, der mit 
der Modellierung startet und mit der Verifikation der Implementierung 
endet. Modell und Implementierung zu vermengen sorgt da nur für Chaos, 
da kann man keinen ordentliche Prozess hinbekommen.

> Was tatsächlich ein Streitpunkt ist wäre nicht UML oder nicht UML

Es ist durchaus umstritten, ob UML für Softwaremodellierung gut geeignet 
ist. Objektorientierung ist nicht das einzig wahre Paradigma.

von Uli.R (Gast)


Lesenswert?

greg schrieb:
> Modellierung und Implementierung gehören strikt
> getrennt.

oh das ist aber der Wissenstand von vor 30 Jahren :( Das Problem bei der 
Trennung von Modell und Code liegt eher darin, dass die UML-Tools 
bestimmte aspekte einer IDE wie Syntaxcoloring und Codevervollständigung 
nicht so gut im Griff haben aber hier verschwimmen die grenzen wie man 
an SiSy recht gut sieht... wenn man es bei SiSy auf das wesentliche 
reduziert ist der ganze Unterschied der, dass man in einer klassischen 
IDE den kompletten Quelltext einer Datei bearbeitet während in der UML 
immer nur der Teil des Codes gezeigt wird der zu einer Methode gehört. 
Das Modell visualisiert lediglich die zusammenhänge zwischen den 
Bausteinen die man aus der Codeperspektive so nur schwer sieht. Meine 
Erfahrung zeigt, wie bei meinem Kollegen, dass die Ablehung der 
Modellebene speziell der UML daraus reduziert, dass dieser nicht mit der 
UML auf dieser Ebene denken will da er die UML nicht als Sprache 
anerkennt, sie nicht benutzt weil er es nich kann und er kann es nicht 
weil er sie nicht benutzt also bleibt er bei dem was er sich einbildet 
zu können und zu kennen ;-)

Uli

von Uli.R (Gast)


Lesenswert?

greg schrieb:
> Es ist durchaus umstritten, ob UML für Softwaremodellierung gut geeignet
> ist. Objektorientierung ist nicht das einzig wahre Paradigma.

das ist wohl wahr :) deshalb postulieren die bei sisy ja auch, dass 
nicht nur aus uml sondern auch aus anderen modellen code generieren LOL 
... nur das ist in dem Tool leider bei weitem nicht so gut ausgebaut wie 
die UMl Fähigkeiten.. ich würde gern die SA/DT benutzen wenn die 
flüssiger funzen würde.

Uli

von greg (Gast)


Lesenswert?

Uli.R schrieb:
> oh das ist aber der Wissenstand von vor 30 Jahren :(

Finde ich gar nicht. Trennung von Modell und konkreter Implementierung 
bedeutet ja nicht, dass man ein krasses Wasserfallprinzip fährt.

von Uli.R (Gast)


Lesenswert?

bei der Elektronik trennst du doch auch nicht Modell von 
Implementation... das heißt somit nur dass das Engineering in der 
Elektrotechnik viel weiter entwickelt ist als in der Software übrigens 
auch im Maschinenbau da trennt auch keine ernst zu nehmender Ingenieur 
das Modell von der Realisierung... zugegeben es gibt Modelle 
verschiedener Granularität und auch unterschiedlicher Entwicklungsstände 
aber kein Elektrotechniker käme auf die Idee dass der Schaltplan ja nur 
ein Sollmodell ist und deshalb nicht mehr der  Realisierung entsprechen 
muss ... be allem bleibt nur als Schlussfolgerung übrig, dass die so 
schlauen Softwareentwickler gut und gerne um dekaden hinter der 
Ingenieurskunst zum Beispiel der Elektrotechniker her hinken

Uli

von Uli.R (Gast)


Lesenswert?

PS: macht mir richtig Spaß mit euch zu diskutieren freu

von m.n. (Gast)


Lesenswert?

Uli.R schrieb:
> PS: macht mir richtig Spaß mit euch zu diskutieren freu

Worum geht es hier denn eigentlich?
Oder freust Du Dich darüber, dass Du noch keinen Krieg erleben mußtest?

Dann fände ich es gut, wenn das unsinnige Thema hier weiter demontiert 
wird.

von Embedded (Gast)


Lesenswert?

Moby schrieb:
> Na bitte wo denn? Vielleicht für Industriekunden. Pic/AVRs gibts an
> jeder Ecke

Bei Mouser und Digikey kann man auch als Privatkunde bestellen.

> Wieso das denn? Eine Anwendung wird mit der Hardware i.d.R.  für fixe
> Funktionen
> designt. Die "echt tolle" Peripheriematrix ist ein schönes Beispiel wie
> mehr Flexibilität unnötig Komplexität rein bringt. Eine Fehlerquelle
> mehr wenn dann was nicht so funktioniert wie es soll.

Es bringt aber nicht mehr Komplexität, ganz im Gegenteil. Ich muss mir 
beim Hardwaredesign keine Gedanken mehr über eventuelle Doppelbelegungen 
oder Abhängigkeiten machen. Ich kann tatsächlich jede Peripherie an 
jedem Pin nutzen. Das spart eine Menge Arbeit. Konfiguriert wird die 
Matrix sowieso per grafischen Tool, da steckt keine Komplexität drin.

>> und den kleinen Prozessor für
>> Aufgaben einsetzen, für den man bei unflexibleren Chips schon viel
>> größere uC verwenden muss.
>
> Also diese Behauptung ist nun wirklich sehr erklärungsbedürftig!

Was ist daran bitte erklärungsbedürftig? Wenn auf dem gleichen Pin zwei 
verschiedene Funktionen liegen, kann ich diese nicht gleichzeitig 
nutzen. Also muss ich den nächst größeren µC nehmen, der die Funktion 
auf zwei Pins hat. Beim LPC800 muss ich das definitiv nicht.

spess53 schrieb:
> Ehrlich gesagt finde ich diese Diskussion teilweise recht praxisfremd.
> Wen interessieren ein paar Cent mehr oder weniger für den Controller
> wenn eine Frontplatte 100 +- x € kostet oder 1000µ/400V Elkos plötzlich
> mal das doppelte kosten.

Glaub mir, ab gewissen Stückzahlen interessiert das irgend wen.

Außerdem sind die Teile doch völlig unabhängig. Wieso sollst du nicht 10 
Cent beim Controller sparen dürfen (bei mehr Leistung!), nur weil dein 
Gerät etwas teurer ist? Natürlich spielen dann andere Faktoren eine 
größere Rolle (Verfügbarkeit, Zuverlässigkeit, Wartbarkeit), aber in 
alle dem haben 32-Bitter erst einmal keine Nachteile oder sogar 
Vorteile.

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


Lesenswert?

Embedded schrieb:
> Dazu kommt noch, dass der LPC800 eine echt tolle Peripheriematrix hat.
> Jede Peripherie auf jeden beliebigen Pin. Echt genial.

Aber was, bitte schön, hat sich NXP denn bei dieser Pinbelegung des 
LPC810 und diesen Eckdaten gedacht? Die Versorgung liegt mal wieder 
völlig anders als bei den Mitbewerbern von Microchip und Atmel, er hat 
keinen AD Wandler und verträgt keine 5V sondern nur 4,6(!) absolute 
Maximum als Vcc.

Nix mit Drop-In Ersatz.

von Embedded (Gast)


Lesenswert?

Wer sagt denn, dass jeder einen Drop-In-Ersatz für Atmel-Controller 
entwickeln muss? Das interessiert 99,9% der Elektronikwelt nicht. Und 5V 
braucht 90-99% auch nicht mehr.

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


Lesenswert?

Embedded schrieb:
> jeder einen Drop-In-Ersatz für Atmel-Controller

So wurde es ein Stück weiter oben behauptet - um in China Atmel den 
Markt abzugraben. Aber mit den PIC passts ja auch nicht. Also auch kein 
Drop-In für Microchip.

: Bearbeitet durch User
von Embedded (Gast)


Lesenswert?

Matthias Sch. schrieb:
> So wurde es ein Stück weiter oben behauptet - um in China Atmel den
> Markt abzugraben. Aber mit den PIC passts ja auch nicht. Also auch kein
> Drop-In für Microchip.

Um den Markt abzugraben braucht man doch kein Drop-In-Replacement.

von Moby (Gast)


Lesenswert?

Embedded schrieb:
> Es bringt aber nicht mehr Komplexität, ganz im Gegenteil. Ich muss mir
> beim Hardwaredesign keine Gedanken mehr über eventuelle Doppelbelegungen
> oder Abhängigkeiten machen. Ich kann tatsächlich jede Peripherie an
> jedem Pin nutzen. Das spart eine Menge Arbeit. Konfiguriert wird die
> Matrix sowieso per grafischen Tool, da steckt keine Komplexität drin.

Das Problem das hier konstruiert wird kann ich beim besten Willen nicht 
erkennen.
Wenn ich weiß welche Funktionen ich brauche setze ich einen entsprechend 
passenden Controller mit den benötigten Funktionen an verschiedenen Pins 
ein und gestalte entsprechend mein Leiterplatten-Layout. Was für eine 
zusätzliche Arbeit soll denn das sein?

> Wenn auf dem gleichen Pin zwei
> verschiedene Funktionen liegen, kann ich diese nicht gleichzeitig
> nutzen. Also muss ich den nächst größeren µC nehmen, der die Funktion
> auf zwei Pins hat. Beim LPC800 muss ich das definitiv nicht.

Dann nimmt man wie schon gesagt einen anderen Typ der passt! Der muss 
doch nicht zwangsläufig größer sein ?!

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


Angehängte Dateien:

Lesenswert?

@Moby
Vielen Dank dass Du immer wieder von neuem diesen Thread hoch holst ;-)
Ich glaube Dir gefallen die STM's sehr...

Aber zum Thema.
ST bietet mit dem STM32F4xx je Port-Pin eine alternative Funktionsmatrix 
mit der bis zu 16 Peripheriefunktionen umgeschaltet werden können.
Ja nach dem welche Funktionen man nutzen möchte, kann man dafür eine 
andere Peripheriefunktion nicht nutzen, da der Prozessor meist nicht für 
jede Funktion einen Pin bereit stellt.
ST baut extra viel Peripherie rein, damit man je nach Anwendungsfall 
auch alles was man benötigt verfügbar hat.

Anbei ein Schaubild des ST Tools
"MicroXplorer MCU graphical configuration tool "

Das kann man als Eclipse-Plugin Laden:
http://www.st.com/web/en/catalog/tools/PF251717

Anbei ein Screenshot wie so etwas aussieht.

von holger (Gast)


Lesenswert?

>ST baut extra viel Peripherie rein, damit man je nach Anwendungsfall
>auch alles was man benötigt verfügbar hat.

Da nehmen wir doch gleich mal das STM32F429 Discovery als
Beispiel. Das LCD und das SDRAM blockieren 90% aller
anderen vorhandenen Peripherie. Da bleibt kaum noch was über.

Ethernet tot.
SDIO fast tot, könnte man nur noch im 1Bit Mode nutzen.
CAN tot.

Irgendwie bleiben da noch zwei UARTs, zwei mal SPI, einmal
USB, zwei ADC Eingänge und ein I2C über. Super Ausbeute.

Wenn die Jungs von ST mal eine komplett frei programmierbare
Switchmatrix für Peripherie einbauen würden könnte man
damit vieleicht sogar mal was anfangen.

von Michi (Gast)


Lesenswert?

holger schrieb:
>>ST baut extra viel Peripherie rein, damit man je nach Anwendungsfall
>>auch alles was man benötigt verfügbar hat.
>
> Da nehmen wir doch gleich mal das STM32F429 Discovery

Du verwechselst Eval Board und MCU.

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


Lesenswert?

holger schrieb:
> Irgendwie bleiben da noch zwei UARTs, zwei mal SPI, einmal
> USB, zwei ADC Eingänge und ein I2C über. Super Ausbeute.
>
> Wenn die Jungs von ST mal eine komplett frei programmierbare
> Switchmatrix für Peripherie einbauen würden könnte man
> damit vielleicht sogar mal was anfangen.

Man kann nun mal nicht alles haben.
Eine Matrix über alle Pins und alle Funktionen ist schon sehr aufwändig 
bei diesen vielen Peripheriefunktionen.

Ich gehe mal davon aus, dass das ein Kompromiss zwischen Stromverbrauch 
und EMV-Verträglichkeit ist. Denn die USB Leitungen können sicher nicht 
quer durch den halben Chip gelegt werden. (Fast) alle Leitungen die für 
eine hohe Datentransferrate ausgelegt sind haben keinen alternativen 
PortPin (USB/RAM/Ethernet).

Wenn einem die Konfiguration von ST nicht gefällt, so schaut man eben 
bei NXP oder sonst wo die auch einen Cortex-Mx Kern bieten. Und man 
braucht die IDE/JTAG-IF nicht wechseln.

von Moby (Gast)


Lesenswert?

Markus Müller schrieb:
> @Moby
> Vielen Dank dass Du immer wieder von neuem diesen Thread hoch holst ;-)
> Ich glaube Dir gefallen die STM's sehr...

Och hab nicht gesagt daß es langweilige Teile wären... Nur eben maßlos 
überdimensioniert und mit einer ungünstigen Aufwand/Nutzen Relation für 
Millionen 8-Bit Projekte :-)

> Aber zum Thema.
> ST bietet mit dem STM32F4xx je Port-Pin eine alternative Funktionsmatrix
> mit der bis zu 16 Peripheriefunktionen umgeschaltet werden können.
> Ja nach dem welche Funktionen man nutzen möchte, kann man dafür eine
> andere Peripheriefunktion nicht nutzen, da der Prozessor meist nicht für
> jede Funktion einen Pin bereit stellt.
> ST baut extra viel Peripherie rein, damit man je nach Anwendungsfall
> auch alles was man benötigt verfügbar hat.

Na schön, in dieser Konstellation macht diese Matrix wohl Sinn- und ist 
gleichzeitig Teil der höheren Komplexität dieser 32 Bitter. Flexibler 
aber komplizierter. Beides ist unnötig.

von holger (Gast)


Lesenswert?

>Man kann nun mal nicht alles haben.

Das ist mir schon klar. Ich wollte ja nur mal andeuten
das man sehr vorsichtig sein muss wenn man behauptet
das der uC so ziemlich alles an Peripherie hat was das Herz
begehrt. Da kommt ganz schnell das böse Erwachen bei raus.

>(Fast) alle Leitungen die für
>eine hohe Datentransferrate ausgelegt sind haben keinen alternativen
>PortPin (USB/RAM/Ethernet).

Auch das ist mir klar. Da frag ich mich dann nur wieso
zum Beispiel LCD und Ethernet sich ausschliessen. Wenn ich Ethernet
haben will kann ich das LCD nicht nutzen, wenn ich LCD will
kann ich Ethernet nicht nutzen. Da der grosse Werbehype bei den
STM32F429 nun mal auf LCD liegt, wieso baut man dann Ethernet ein?
Ist doch Schwachsinn oder nicht? Beim älteren STM32F4 Discovery
kann man SDIO nicht nutzen wenn man I2S verwendet. Noch so ein
Schwachsinn. Audiodaten könnte man doch super von SD Karte lesen.

Und für die langsamere Peripherie wie UARTS, SPI, CAN, I2C, ADC
würde die Switchmatrix kein Problem darstellen.

Also immer vorsichtig wenn jemand mit acht UARTS wirbt.
Sechs davon kann man sowieso nicht nutzen. Aber man bezahlt sie.

von Moby (Gast)


Lesenswert?

holger schrieb:
> Also immer vorsichtig wenn jemand mit acht UARTS wirbt.
> Sechs davon kann man sowieso nicht nutzen. Aber man bezahlt sie.

Beim Xmega kann man sie nutzen wenn man denn wirklich acht UARTs 
braucht- und dafür Einschränkungen bei anderen Funktionen in Kauf nimmt.

von holger (Gast)


Lesenswert?

>Beim Xmega kann man sie nutzen wenn man denn wirklich acht UARTs
>braucht- und dafür Einschränkungen bei anderen Funktionen in Kauf nimmt.

Und wo ist da jetzt der Unterschied zum ARM? Wenn ich SDRAM und LCD
nicht nutze hab ich die auch.

von Moby (Gast)


Lesenswert?

holger schrieb:
>>Beim Xmega kann man sie nutzen wenn man denn wirklich acht UARTs
>>braucht- und dafür Einschränkungen bei anderen Funktionen in Kauf nimmt.
>
> Und wo ist da jetzt der Unterschied zum ARM? Wenn ich SDRAM und LCD
> nicht nutze hab ich die auch.

Ja gut, hab ich mißverstanden. Interessant nur daß selbst die 
hochgelobte Matrix hier keine Abhilfe schafft.

von Lothar (Gast)


Lesenswert?

Moby schrieb:
> Interessant nur daß selbst die
> hochgelobte Matrix hier keine Abhilfe schafft.

Nur bei den STM32F4, die LPC4300 haben eine vollflexible Switchmatrix.

Die LPC800 natürlich auch, aber hier wird ohnehin schon viel 
durcheinander geworfen, den die sind explizit 8-bit-Ersatz, während die 
STM32F4 High-End sind.

Und ja es macht Sinn wie NXP oder STM ARM-Kerne für alle Anwendungen 
anzubieten, anstatt wie Atmel inkompatible AVR, AVR32 und ARM, oder 
Microchip mit PIC und PIC32/MIPS

von Embedded (Gast)


Lesenswert?

Moby schrieb:
> Das Problem das hier konstruiert wird kann ich beim besten Willen nicht
> erkennen.

Ja, weil du ganz offensichtlich keine Ahnung von Elektronikentwicklung 
hast. Mach mal ein paar Designs, dann weißt du, wovon wir hier reden. 
Dazu musst du aber erst einmal das Trollen aufhören.

Moby schrieb:
> Wenn ich weiß welche Funktionen ich brauche setze ich einen entsprechend
> passenden Controller mit den benötigten Funktionen an verschiedenen Pins
> ein und gestalte entsprechend mein Leiterplatten-Layout. Was für eine
> zusätzliche Arbeit soll denn das sein?

Bei den kleinen Controllern muss man eben oft mit den Pins jonglieren 
oder dann doch einen größeren Controller einsetzen, weil man gerade 
feststellt, dass ein Pin doppelt belegt ist oder man ihn gerade so nicht 
raus führen kann. Das kostet einfach Zeit und erhöht die Komplexität. 
Und ist ärgerlich, weil man dann Stückzahlen aufteilen muss. So kann ich 
einen Controller für zig verschiedene Designs einsetzen und komme dann 
ziemlich schnell auf 6/7-Stellige Stückzahlen, und das freut meinen 
Einkäufer.

Moby schrieb:
> Dann nimmt man wie schon gesagt einen anderen Typ der passt! Der muss
> doch nicht zwangsläufig größer sein ?!

Nicht zwangsläufig, meistens aber schon. Und selbst wenn nicht hat man 
immer noch das Einkaufsproblem.

Moby schrieb:
> Och hab nicht gesagt daß es langweilige Teile wären... Nur eben maßlos
> überdimensioniert und mit einer ungünstigen Aufwand/Nutzen Relation für
> Millionen 8-Bit Projekte :-)

Aufwand geringer. Nutzen gleich oder höher. Kosten geringer. Was stimmt 
an der Relation nicht?
Für einen Bastler mag das nicht relevant sein, der nimmt was ihm Spaß 
macht, aber für einen Profi zählen die oben genannten Faktoren. Da ist 
es schon vorteilhaft, dass man seine Zigtausend-Euro 
Safety-zertifizierte Toolchain für alle Projekte verwenden kann.

Lothar schrieb:
> Die LPC800 natürlich auch, aber hier wird ohnehin schon viel
> durcheinander geworfen, den die sind explizit 8-bit-Ersatz, während die
> STM32F4 High-End sind.

Eben. Bei den kleineren Controllern geht es um etwas ganz anderes. Bei 
einem 8-Pinner ist man viel stärker eingeschränkt. Und die frei 
konfigurierbare Matrix macht das Design wesentlich weniger komplex, 
während die Alternate Functions beim ST durchaus etwas Komplexität 
einbringen.

von Moby (Gast)


Lesenswert?

Embedded schrieb:

> Ja, weil du ganz offensichtlich keine Ahnung von Elektronikentwicklung
> hast. Mach mal ein paar Designs, dann weißt du, wovon wir hier reden.
> Dazu musst du aber erst einmal das Trollen aufhören.

Davon sind in über einem Dutzend Hobby-Jahre mehr als genug 
zusammengekommen.

> Bei den kleinen Controllern muss man eben oft mit den Pins jonglieren
> oder dann doch einen größeren Controller einsetzen, weil man gerade
> feststellt, dass ein Pin doppelt belegt ist oder man ihn gerade so nicht
> raus führen kann...

Du meine Güte. Was ist denn das für eine unüberlegte Planung?
Sowas hab ich noch nie im nachhinein festgestellt, weil vorher klar
ist was rauskommen soll!

> Moby schrieb:
>> Dann nimmt man wie schon gesagt einen anderen Typ der passt! Der muss
>> doch nicht zwangsläufig größer sein ?!
>
> Nicht zwangsläufig, meistens aber schon. Und selbst wenn nicht hat man
> immer noch das Einkaufsproblem.

Bei den AVRs und genauso den  Pics findet sich eigentlich immer ein Typ 
der passt-
jedenfalls für die im Schnitt hardwaremäßig weniger aufwändigen 8-Bit 
Projekte.

> Moby schrieb:
>> Och hab nicht gesagt daß es langweilige Teile wären... Nur eben maßlos
>> überdimensioniert und mit einer ungünstigen Aufwand/Nutzen Relation für
>> Millionen 8-Bit Projekte :-)

> Da ist es schon vorteilhaft, dass man seine Zigtausend-Euro
> Safety-zertifizierte Toolchain für alle Projekte verwenden kann.

Schön. Das kann man ja noch nachvollziehen.
Meine 8-Bit Toolchain war im wesentlchen kostenlos: AVR Studio + Jtag 
Ice3 aus einem Atmel Kurs :-) Soviel mal zur Kostenfrage für 8-Bit 
Projekte.

> Lothar schrieb:
>> Die LPC800 natürlich auch, aber hier wird ohnehin schon viel
>> durcheinander geworfen, den die sind explizit 8-bit-Ersatz, während die
>> STM32F4 High-End sind.

> Bei einem 8-Pinner ist man viel stärker eingeschränkt...

Nee, nicht wenn man den richtige Typ nehmen kann...

Leute Leute, wie wird in der Industrie nur gearbeitet?
Da lob ich mir die Freiheit die es offensichtlich nur in der 
Elektronikentwicklung-Hobbyversion gibt :-)

von Embedded (Gast)


Lesenswert?

Moby schrieb:
> Du meine Güte. Was ist denn das für eine unüberlegte Planung?
> Sowas hab ich noch nie im nachhinein festgestellt, weil vorher klar
> ist was rauskommen soll!

Ich habe doch nichts von Nachhinein geschrieben. Das stellt man 
natürlich in der Designphase fest, aber dann hat man eben schon ein paar 
unnötige Stunden verblasen. Und in der Industrie sind das gleich ein 
paar Tausend Euro.

Moby schrieb:
> Bei den AVRs und genauso den  Pics findet sich eigentlich immer ein Typ
> der passt-
> jedenfalls für die im Schnitt hardwaremäßig weniger aufwändigen 8-Bit
> Projekte.

Ich kann aber trotzdem nicht in mehreren Designs den gleichen Typ 
einsetzen. Und das mag der Einkauf nicht.

Moby schrieb:
> Schön. Das kann man ja noch nachvollziehen.
> Meine 8-Bit Toolchain war im wesentlchen kostenlos: AVR Studio + Jtag
> Ice3 aus einem Atmel Kurs :-) Soviel mal zur Kostenfrage für 8-Bit
> Projekte.

Für ARM gibt es auch kostenlose Toolchains. Wenn ich aber Safety 
entwickeln muss, kann ich nicht unbedingt auf die kostenlose Toolchain 
setzen, oder ich muss sie zumindest ausgiebig selbst getestet haben. 
Wenn ich dem TÜV erzählen kann, dass ich die gleiche Toolchain in zig 
Designs einsetze, dann ist der schon einmal beruhigt und kann einen 
Haken dran machen.

Moby schrieb:
> Nee, nicht wenn man den richtige Typ nehmen kann...

Ja, ist aber ziemlich nervig, wenn ich dann für 10 Designs 5 
verschiedene Typen pflegen muss. Wenn dann eine Reihe abgekündigt wird, 
muss ich wieder 5 neue suchen. Eine echt tolle Lösung.

Moby schrieb:
> Leute Leute, wie wird in der Industrie nur gearbeitet?
> Da lob ich mir die Freiheit die es offensichtlich nur in der
> Elektronikentwicklung-Hobbyversion gibt :-)

In der Industrie muss Geld verdient werden. Da muss man eben auf Kosten 
und Wartbarkeit achten und kann nicht einfach das nehmen, was man gerade 
beim Reichelt billig bekommt.

von Moby (Gast)


Lesenswert?

Embedded schrieb:
> Das stellt man
> natürlich in der Designphase fest, aber dann hat man eben schon ein paar
> unnötige Stunden verblasen. Und in der Industrie sind das gleich ein
> paar Tausend Euro.

Bei besagtem 8-Pinner sollte das eigentlich schneller erledigt sein!
Aber gut, ist jetzt alles ein bischen Rumstochern im Nebel wenn man die 
konkrete Applikation nicht kennt.

> Für ARM gibt es auch kostenlose Toolchains. Wenn ich aber Safety
> entwickeln muss, kann ich nicht unbedingt auf die kostenlose Toolchain
> setzen, oder ich muss sie zumindest ausgiebig selbst getestet haben.
> Wenn ich dem TÜV erzählen kann, dass ich die gleiche Toolchain in zig
> Designs einsetze, dann ist der schon einmal beruhigt und kann einen
> Haken dran machen.

Da bin ich aber froh solche Haken nicht setzen zu müssen :)

> Ja, ist aber ziemlich nervig, wenn ich dann für 10 Designs 5
> verschiedene Typen pflegen muss.

Also es läuft darauf hinaus möglichst wenige Typen möglichst flexibel 
einsetzen zu können-
und dabei hilft die Peripheriematrix. Und sie verkompliziert den 
Controller wieder ein Stück.
Industriell geforderte Flexibilität als Treiber der Komplexität, das 
lässt sich ja an vielen Stellen beobachten (z.B. die erweiterten UARTs 
der Xmega- gegenüber den älteren AVR Mega Typen). Wenn aber mit der 
Komplexität der Schulungs/Lernaufwand immer weiter ansteigt glaube ich, 
daß letzlich doch der einfachere Typ die Oberhand behält, wenn er denn 
die Aufgabenstellung zu lösen imstande ist.

> In der Industrie muss Geld verdient werden. Da muss man eben auf Kosten
> und Wartbarkeit achten und kann nicht einfach das nehmen, was man gerade
> beim Reichelt billig bekommt.

Für die schnelle und einfachste Problemlösung im Hobby nimmt man 
jedenfalls was a) bekannt, b) die Anforderungen erfüllt und c) dann am 
günstigsten ist. Erst wenn die Anforderungen nicht mehr erfüllt werden 
können muß zugelernt werden. Ich bin einigermaßen sicher daß mir das mit 
dem Xmega nicht mehr passiert :)

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


Lesenswert?

C) trifft schon mal für den XMega nicht zu

Wenn die ganzen AVR nur 1/4 kosten würde, dann wären die günstig und 
auch für die Zukunft in der Industrie interessant.
Aber so werden die weiterhin Marktanteile verlieren und wohl wird Atmel 
den ein oder anderen Typ nicht mehr herstellen.
Auch sollte Atmel endlich mal Debugger verkaufen, die Preislich um die 
20..30 Euro kosten (und wenigstens ein PVC Gehäuse zum Schutz haben).
Wenn Atmel nicht bald reagiert sind die ganz schnell weg. Atmel/AVR ist 
einfach viel zu teuer für das was die leisten. Das war vor 10 Jahren 
noch anders, aber die Konkurrenz schläft nicht. Daher ist es jetzt an 
der Zeit AVR Goodbye zu sagen - zumindest für neue Desings.

Für dich, Moby, hoffe ich dass du einen 30-Jährigen Vorrat an AVR's 
hast, incl Ersatz Debugger falls deiner abraucht.

: Bearbeitet durch User
von Embedded (Gast)


Lesenswert?

Moby schrieb:
> Bei besagtem 8-Pinner sollte das eigentlich schneller erledigt sein!
> Aber gut, ist jetzt alles ein bischen Rumstochern im Nebel wenn man die
> konkrete Applikation nicht kennt.

Relativ. Ein paar Stunden gehen schon drauf, schließlich muss man sich 
zumindest mal ein Angebot einholen (da ist der Einkauf involviert), die 
Datenblätter ausführlich auf Eignung für die Applikation checken, und so 
weiter. Bei einem Stundensatz von 100 Euro kommen da schon ein paar 
Tausend Euro zusammen.

Moby schrieb:
> Da bin ich aber froh solche Haken nicht setzen zu müssen :)

Als Bastler kann man immer das nehmen, was man gerade bei Reichelt 
bekommt. Aber dann sollte man sich mit so absoluten Urteilen von 
Tauglichkeit von Prozessorfamilien einmal sehr zurückhalten.

Moby schrieb:
> Also es läuft darauf hinaus möglichst wenige Typen möglichst flexibel
> einsetzen zu können-
> und dabei hilft die Peripheriematrix. Und sie verkompliziert den
> Controller wieder ein Stück.

Nein, sie senkt die Komplexität und den Aufwand.

Moby schrieb:
> Industriell geforderte Flexibilität als Treiber der Komplexität, das
> lässt sich ja an vielen Stellen beobachten (z.B. die erweiterten UARTs
> der Xmega- gegenüber den älteren AVR Mega Typen). Wenn aber mit der
> Komplexität der Schulungs/Lernaufwand immer weiter ansteigt glaube ich,
> daß letzlich doch der einfachere Typ die Oberhand behält, wenn er denn
> die Aufgabenstellung zu lösen imstande ist.

Und da liegst du falsch. Komplexität wird durch Kapselung reduziert. Man 
schreibt genau einmal eine Bibliotheksfunktion und nutzt sie dann in zig 
verschiedenen Designs. Das geht nicht so einfach, wenn man verschiedene 
Prozessoren verwendet, die womöglich auch noch inkompatible 
Peripherieeinheiten haben (soweit ich weiß lässt sich die UART in einem 
Tiny nicht genauso nutzen wie in einem Atmega oder XMEGA). Der 
Lern-/Schulungsaufwand ist weitaus geringer als der Pflegeaufwand.

Moby schrieb:
> Für die schnelle und einfachste Problemlösung im Hobby nimmt man
> jedenfalls was a) bekannt, b) die Anforderungen erfüllt und c) dann am
> günstigsten ist. Erst wenn die Anforderungen nicht mehr erfüllt werden
> können muß zugelernt werden. Ich bin einigermaßen sicher daß mir das mit
> dem Xmega nicht mehr passiert :)

Für den Bastler mag das stimmen. Aber wen interessieren schon die paar 
Bastler? Allenfalls die Entwickler von Arduino, aber die haben ja auch 
aus diesem Grund ihre eigenen Bibliotheksfunktionen entwickelt.

Außerdem: Was ist jetzt, wenn der Bastler nur den STM32F4 kennt? Der 
erfüllt auch in der Regel die Anforderungen, für eine Anwendung, in der 
man einen Tiny einsetzen kann. Damit wären a und b erfüllt. Und wenn 
Bausteine oder ein Entwicklungskit vorhanden sind, trifft auch C zu, 
denn die Debughardware für einen STM32F4 ist günstiger als für einen 
Tiny.

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.