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
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...
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.
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
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...
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
@ 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
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.
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!).
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.
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.
@Markus. Hast Du schon mal mit dem Arduino was gemacht ? Weil der da mit in der Tabelle steht.
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
>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.
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.
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.
>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.
knabbet schrieb: > Krieg entsteht dann, wenn man den anderen nicht kennt. Du hast offenbar noch keine Scheidung erlebt. ;-)
:
Bearbeitet durch User
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?
>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!
Ich habe aus dem Artikel den "Programmieradaper mit Debugger" "USBasp 2-5€" entfernt, da der (lt. deren Homepage) nur programmieren und nicht debuggen kann.
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?"
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.
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 :-) ;)
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.
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
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.
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
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).
bis auf CAN ... mein Hausbaus läuft mit CAN.
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.
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
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.
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ß
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.
> 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.
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
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 :-)
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!
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. :))
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 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).
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.
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.
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.
> 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
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.
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.
>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.
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
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)?
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.
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.
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.
Stimmt. Ich habe mal die Breakpoint-Zeile hinzugefügt. Sollte noch jemand drüber schauen, der die anderen Prozessoren besser kennt.
:
Bearbeitet durch User
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...
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".
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.
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
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.)
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
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
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.
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
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.
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.
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?
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
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
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.
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 :-)
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!
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...
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
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
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.
Hallo Markus, danke für die Klarstellung und guten Rutsch ins neue Jahr. Gruß Helmut
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.
@ 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 ;-)
Dann schreibe dieses Board incl. Link der Bezugsquelle mit dazu.
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.
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.
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?
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.
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.
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
Die Begeisterung teile ich. Wenn auch für viel weniger Bits = möglichst wenig Aufwand bei maximalem Nutzen.
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?
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?
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...>
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.
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.
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.
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.
Moby schrieb: > wenn die 32bitter bis dahin nicht mit einfacherer > Programmierbarkeit Ein STM32 ist einfacher zu programmieren als ein AVR: er hat keine Fuses!
Einen Xmega kann man so auch nicht unbrauchbar machen. Verfusen war nun auch nicht gerade Schicksal welches einen zwangsläufig ereilen muß!
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.
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
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.
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.
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.
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?
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.
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.
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.
@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
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
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.
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.
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.
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.
Gernervtsein ist doch der erste Schritt hin zur Einsicht, also nicht ganz so beschränkt wie mancher Hardliner hier :-)
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.
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.
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
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.
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.
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?
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
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
@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".
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...
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.
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.
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?
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.
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.
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.
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.
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.
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. ;)
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.
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 :)
Ich weiß ja nicht wer hier was persönlich nimmt...wohl eher du wenn man den Beitrag so liest...
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. :-)
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
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 :-)
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?
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
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.
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.
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.
> 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.
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
> ...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?
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
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.
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
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.
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?
"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
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? :)
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!
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. ;)
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.
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.
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?
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
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.
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?
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
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 :-)
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.
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" :-)
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. ;)
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
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.
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
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
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.
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
PS: macht mir richtig Spaß mit euch zu diskutieren freu
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.
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.
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.
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.
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
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.
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 ?!
@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.
>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.
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.
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.
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.
>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.
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.
>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.
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.
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
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.
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 :-)
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.
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 :)
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.