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.
Ja @ Markus Müller, wie wir gelernt haben > Die LPC800 natürlich ... sind explizit 8-bit-Ersatz, während die > STM32F4 High-End sind. werden es auch die STM32 kaum zum würdigen Ersatz der guten AVRs bringen und lediglich weiter die Nische leistungshungriger Apps besetzen. Dabei handelt es sich ja meist um irgendeine Anwendung für Medien mit größeren Grafikdisplays- die gibts aber oft billiger im Laden :-) Die große Masse der Anwendungen ist nun mal MSR- und dafür sind die 8 Bitter dermaßen was von prädestiniert... Wenn aber dafür dann diversen LPCs Grundfunktionalitäten wie ADCs abgehen und ich auch sonst keine schlagenden Argumente in Beitrag "LPC800 existiert (fast) nicht in diesem Forum" finden kann dann sollte man seinen AVR Vorrat weiter pflegen- ein paar Cents hin oder her. Den Xmega habe ich trotz ein paar Cents mehr deshalb gewählt weil er auch dank vieler innovativer Features so ziemlich für alles zu gebrauchen ist was mit MSR zu tun hat und ich mich vor allem so auf genau einen Typ beschränken kann.
Ich habe viel STM32 im Einsatz und keines hat ein Display. (OK, EA-Dog mit SPI) Die XMegas kann ich alle nicht gebrauchen, denn mein Hausbus läuft mit CAN. Für Nischen wird es wohl noch ein XMega tun, aber dann hört es schnell mal auf. Jedenfalls haben die AVR's zu viele Einschränkungen und sind viel zu teuer, wie ich schon mehrfach in den letzten 200 Threads bewiesen habe. Der LPC800 ist recht neu und NXP wird von dem auch noch weitere Variationen herstellen, sicher auch mit AD-Wandler und mehr Features. Außerdem gibt es die nächste Reihe, die LPC11xx die das kann. Also klebe schön weiter an Deinen AVR's und habe Spaß damit. Ich kann mit dem minderwertigen alten Schrott nichts (mehr) anfangen. Ich kaufe mir lieber STM32 im LQFP64 / LQFP100 Gehäuse, die sind untereinander alle Pinkompatibel und wenn ich mehr Leistung/Speicher benötige nehme ich einfach den nächst größeren, von 24MHz bis 180MHz kann ich alles machen - ohne viel Umprogrammierung (PLL/Clock anpassen). Und die Industrie nimmt gleich einen größeren und dann auch nur einen für alle App's - ist günstiger. Und auch nur die wenigsten Industrie-Anwendungen haben ein komplexes TFT Display - und wenn dann gleich meist ein noch größerer Prozessor als den STM32F4xx. Und wieso soll ich für Low-End nicht auch einen STM32 einsetzen, den ich schon für weniger als 1€ bekomme? Moby, Du verhälst Dich wie ein kleines Kind, das einfach nicht die Schokolade essen will weil es immer denkt das ist Kake.
:
Bearbeitet durch User
Embedded schrieb: > Als Bastler kann man immer das nehmen, was man gerade bei Reichelt > bekommt. Wiegesagt man nimmt das was man wirklich braucht und nicht das was einem irgendein Anbieter gerade über den Preis aufschwatzen will. > Aber dann sollte man sich mit so absoluten Urteilen von > Tauglichkeit von Prozessorfamilien einmal sehr zurückhalten. Das werde ich ganz sicher nicht, egal ob man Controller XY nun in die Hand bekommt oder nicht. Das Netz & dieses Forum enthalten genug Infos um sich ein eigenen Urteil zu bilden. Das sollte sich hier niemand von einem "Profi" diktieren lassen! > Nein, sie senkt die Komplexität und den Aufwand. Die Rede war von der Komplexität des Controllers an sich. > 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... Die Rede war von der Komplexität des Controllers an sich. > Außerdem: Was ist jetzt, wenn der Bastler nur den STM32F4 kennt? Dann wird er in der Reihenfolge der Prioritäten seinem STM32 den Vorzug geben. Wieviele Bastler aber mögen das sein? Sobald einmal erkannt ist daß es 8 bittig einfacher, oft kleiner, stromsparender und günstiger zu lösen ist... na ich weiß nicht ;)
Wieso schwörst Du so auf 8-Bit? Die 4-Bitter sind doch alle noch viel einfacher. Weil die weniger Bits haben brauchen die doch auch viel weniger Strom und sind kleiner und günstiger und überhaupt viel besser geeignet als die komplexen 8-Bitter? Somit sollte jeder Bastler unbedingt sich 4-Bitter heraussuchen.
:
Bearbeitet durch User
Markus Müller schrieb: > 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. Warum soll der debugger denn 30 euro kosten und nich 10 oder 50? Mal sehen was es zur embedded neues gibt aber ich sehe keinen grund dem avr noch pic goodbye zu sagen. Weder kann irgendeine firma die produktpalette von atmel odr mchip abdecken. Wobei atmel die einzige firma ist welche die zwei populaersten cores besitzt. Und es wird nicht nur in cortex sondern auch weiterhin in avr investiert wie den tiny841 oder xmegae. Es soll sogar neue atmega und xmega geben (quelle:ineltek). Zurueck zum debugger:jede firma die eine vernuenftige projektplanung hat, hat auch entsprechendes budget fuer tools. Ob fuer compiler, stacks oder hardware. Dann ist es egal ob der debugger 100$kostet oder man 2500$ fuer lauterbach braucht. Und avr zu 1/4: die preisgestaltung bei reichelt oder digikey macht nicht atmel. Der tiny88 kostet bei atmel ueber normalen disti bei lediglich 1000st unter 30cent! Und das im qfn package. Farnell verlangt bei dieser abnahmemenge 4x soviel waehrend mouser nur 25% draufschlaegt. Und jetzt willst du behaupten atmel sei teuer? Ich wuerde sagen der distributor, aber ich wuerde es nicht uebel nehmen. Offensichtlich kann farnell diesen preis halten aus bestimmten gruenden. Kein hersteller schreibt einem haendler vor wieviel der chip kosten soll, denn in der preisgestaltung ist der disti allein. Uebrigens waere es anders, stuende es mit dem eu recht in konflikt.
Moby schrieb: > Sobald einmal erkannt ist daß es 8 bittig einfacher Genau, mit 16-bit Adressbus, mehrere 8-bit Register pro Port für die Funktionswahl und interne Pulls, 10-bit ADC mit 8-bit High/Low Registern. Und der Xmega toppt das noch.
ATTiny88 @6000 = 0.38932: http://www.digikey.de/product-detail/de/ATTINY88-MUR/ATTINY88-MURTR-ND/2357456 STM32 @10000 = 0,423: http://at.mouser.com/ProductDetail/STMicroelectronics/STM32F030F4P6/?qs=sGAEpiMZZMuoKKEcg8mMKOHkam7XjJnw3SF6NWq8tIw%3d LPC @10000 = 0,571 http://at.mouser.com/ProductDetail/NXP-Semiconductors/P89LPC912FDH129/?qs=sGAEpiMZZMvu0Nwh4cA1wUhXb1nJ%2ffVjnn%252bGVGFQ7w8%3d Nur mal so zum Vergleich mit echten Preisen. Somit ist der ATTiny88 um VIELES teurer. Man muss dafür extra eine zertifizierte IDE kaufe, Extra Produkt evaluieren und Extra Code schreiben, das kostet alleine schon minimum 10000€. Und die Differenz zum STM32 ist nur 0,03368€. Solange man keine knapp 300000 von den ATTiny's verbaut ist der STM32 immer noch am günstigsten - sofern man den für alle Applikationen nutzt. Tschüss AVR - die Sonne ist bereits jetzt schon untergegangen. ;-)
> Wieviele Bastler aber mögen das sein? Sobald einmal erkannt ist daß es 8 > bittig einfacher, oft kleiner, stromsparender und günstiger zu lösen > ist... na ich weiß nicht ;) Das mit dem "einfacher" ist so eine Sache. Ich habe mal ein und dieselbe Anwendung programmiert. Einmal auf einem AVR und einmal auf einem stm32. Auf dem AVR musste ich Handstände machen um das Timing einzuhalten. Ich musste jede Division in Bitshifts umwandeln und kompliziert herumwursteln. Das war ein Kraftakt, denn für jede simple Berechnung brauchte der AVR hunderte Takte. Beim stm32 konnte ich dank FPU und 32 Bit die zu berechnende Formel einfach hinschreiben (ohne mich um das Timing kümmern zu müssen). Ich konnte sie 1:1 aus dem Tabellenbuch entnehmen! Bei dem AVR undenkbar. Der war viel zu langsam. In diesem Fall war also der stm32 eine echte Vereinfachung. Gradezu ein Traum. Was den Preis betrifft: Das stm32-Board hat ich 12 Euro gekostet. Der AVR-Programmer (ohne Debuggingfunktion) über 30 euro... und dazu dann nochmal die AVR-Platine hmmmm.... Also ich bin danach komplett umgestiegen.
Moby schrieb: > Die Rede war von der Komplexität des Controllers an sich. Die Komplexität des Controllers an sich interessiert niemanden. Bestes Beispiel: Lusi-Flusi-Popusi schrieb: > Beim stm32 konnte ich dank FPU und 32 Bit die zu berechnende Formel > einfach hinschreiben (ohne mich um das Timing kümmern zu müssen). Ich > konnte sie 1:1 aus dem Tabellenbuch entnehmen! Bei dem AVR undenkbar. > Der war viel zu langsam. In diesem Fall war also der stm32 eine echte > Vereinfachung. Gradezu ein Traum. Eine FPU macht den Controller an sich natürlich viel komplexer. Die Anwendung wird aber plötzlich um ein vielfaches einfacher, weil man sich Fixed-Point-Operationen mit umständlicher Bitschieberei spart. Gleiches gilt für die Peripheriematrix. Der Controller wird natürlich komplexer, aber die Anwendung wird viel, viel einfacher, weil man sich keine Gedanken mehr um Doppelbelegung und die Verschaltung der Pins kümmern muss. Und ich kann das Boardlayout optimieren, weil ich ja die Pins frei verteilen kann. Das senkt auch noch einmal die Komplexität. Gleiches gilt für Bibliotheksfunktionen. Die machen das Programm an sich auch erst einmal komplexer (mehr LOC). Aber die Anwendung wird viel, viel einfacher.
Weitere Beispiele: Debugging. Eine Debugeinheit macht den Controller komplexer. Aber man kann die internen Abläufe seines Programms besser nachvollziehen. Ergo: Die Entwicklung mit dem Prozessor wird um ein vielfaches einfacher und schneller. Moby schrieb: > Das werde ich ganz sicher nicht, egal ob man Controller XY nun in die > Hand bekommt oder nicht. Das Netz & dieses Forum enthalten genug Infos > um sich ein eigenen Urteil zu bilden. Das sollte sich hier niemand von > einem "Profi" diktieren lassen! Ich habe dir doch schon gesagt, dass du als Bastler nehmen kannst, was du willst. Du liegt aber nur mit deinem Urteil über 8-Bitter und 32-Bitter einfach falsch, weil in der echten Welt Faktoren zählen, die du nicht siehst, nicht verstehst, nicht akzeptierst.
Embedded schrieb: > Und ich kann das Boardlayout optimieren, weil ich ja die > Pins frei verteilen kann. - Einfacheres Layout - Weniger Kreuzungen der Leiterbahnen - EMV-Verträglichkeit (CE) viel leichter einhaltbar >> Kleinere Platine und somit deutlich weniger Kosten!
Das ist ein bischen wie bei den PCs. Jede paar Jahre steigt die Komplexität an. Das ganze geht sogar exponentiell! Und wird die Bedienbarkeit komplizierter? Durch Komplexität auf der unteren Ebene werden Abstraktionsebenen möglich, welche die Handhabbarkeit auf höheren Ebenen vereinfacht. Das ist der Weg in die Zukunft! Eine Tages werden Microcontroller ein eigenes Bewusstsein entwickeln und wir können uns mit ihnen über unser neues angestrebtes Projekt unterhalten. Dann wirft man nur noch einen Löffel Nanoroboterbrei auf den Tisch und das Ganze formt sich von selber zur fertigen Anwendung. :-)) ;)
Markus Müller schrieb: > ATTiny88 @6000 = 0.38932: > http://www.digikey.de/product-detail/de/ATTINY88-MUR/ATTINY88-MURTR-ND/2357456 > > STM32 @10000 = 0,423: > http://at.mouser.com/ProductDetail/STMicroelectronics/STM32F030F4P6/?qs=sGAEpiMZZMuoKKEcg8mMKOHkam7XjJnw3SF6NWq8tIw%3d > > LPC @10000 = 0,571 > http://at.mouser.com/ProductDetail/NXP-Semiconductors/P89LPC912FDH129/?qs=sGAEpiMZZMvu0Nwh4cA1wUhXb1nJ%2ffVjnn%252bGVGFQ7w8%3d > > Nur mal so zum Vergleich mit echten Preisen. > Somit ist der ATTiny88 um VIELES teurer. Man muss dafür extra eine > zertifizierte IDE kaufe, Extra Produkt evaluieren und Extra Code > schreiben, das kostet alleine schon minimum 10000€. Und die Differenz > zum STM32 ist nur 0,03368€. Solange man keine knapp 300000 von den > ATTiny's verbaut ist der STM32 immer noch am günstigsten - sofern man > den für alle Applikationen nutzt. > > Tschüss AVR - die Sonne ist bereits jetzt schon untergegangen. ;-) du vergleichst hier ein billiges tssop 20pin package gegen ein QFN package/32pin kein 5V kein low power kein eeprom dein LPC ist übrigens ein 8Bit ;-) und wie gesagt, die preise bei catalogue distis kannst du nicht vergleichen, das ist die alleinige Entscheidung des Händlers für wieviel der Chip verkauft werden soll. Offensichtlich kann Farnell noch viel teurer verkaufen, selbst über 1euro bei tausend stück kann man den tiny88 verkaufen, anscheinend stimmt das Preis Leistungsverhältnis Du kannst nicht atmel dafür verantwortlich machen dass die Händler einen Chip der im Einkauf unter 30cent ($Cent!) zu haben ist für 1.3Euro verkaufen. Preisgestaltung ist alleinige Sache des Händlers. Der Hersteller darf in EU die Preise nicht diktieren (EU Recht). Deshalb gibt es eine UVP.
martin schrieb: > dein LPC ist übrigens ein 8Bit ;-) Ein 8-bit mit "kein 5V, kein low power, kein eeprom" :-) Aber der ARM Nachfolger ist in Stückzahlen sogar billiger: http://at.mouser.com/ProductDetail/NXP/LPC811M001JDH16FP/?qs=%2fha2pyFadughkC6y8Cf7vNIsk%2fhKzqGG0YLiBFrcrl0%3d
5V ist ihhh. Nutze ich schon lange nicht mehr.
Die Katalogpreise kann man sehr wohl aus Anhaltspunkt nehmen. Wenn da der Tiny für 39ct drin steht und der vom Einkauf für 30 zu haben ist (=9ct günstiger) so gilt das auch für den STM und LPC. Somit gibt es den STM auch für 33,5ct. Und Deine 30ct Rechnung geht damit wieder den Bach runter.
Markus Müller schrieb: > Embedded schrieb: >> Und ich kann das Boardlayout optimieren, weil ich ja die >> Pins frei verteilen kann. > > - Einfacheres Layout > - Weniger Kreuzungen der Leiterbahnen > - EMV-Verträglichkeit (CE) viel leichter einhaltbar > >> Kleinere Platine und somit deutlich weniger Kosten! Na das ist ja schon dermaßen an den Haaren herbeigezogen... Aber sei Dir gegönnt.
Moby schrieb: > Na das ist ja schon dermaßen an den Haaren herbeigezogen... Aber sei Dir > gegönnt. Ja, ja. Gähn. Meine Heizungsteuerung und Hausbus läuft schon seit 4 Jahren ohne Probleme. Nur ein einziges mal ist ein einziger µC abgestürzt und ich musste den neu starten - da hat unmittelbar neben unserem Haus der Blitz eingeschlagen und es waren auch 2 LED-Leuchten (obwohl die zu dem Zeitpunkt aus waren) defekt. Somit ist ein gutes Design samt Überspannungsschutz auch als Hobbybastler nicht zu vernachlässigen!
:
Bearbeitet durch User
Moby schrieb: > Na das ist ja schon dermaßen an den Haaren herbeigezogen... Aber sei Dir > gegönnt. Nein, das ist nicht an den Haaren herbeigezogen, es übersteigt nur einfach deine Vorstellungskraft. Du hast ganz offensichtlich noch nie ein Leiterplattenlayout gemacht.
Oh Wunder hab auch eine Art Hausnetz das schon mehr als 6 Jahre super läuft, getrieben noch von einem Mega128. Das steinalte Draht- CAN braucht es nicht, geht alles modern via Funk ;) Ist schon OK daß Du Deinen STM so verteidigst und alles damit machst, prinzipiell teile ich ja die Begeisterung für MCs. Aber ich wiederspreche vehement wenn mir jemand 32er HighEnd Boliden als legitimen Nachfolger der einfachen AVRs verkaufen will.
Embedded schrieb: > Moby schrieb: >> Na das ist ja schon dermaßen an den Haaren herbeigezogen... Aber sei Dir >> gegönnt. > > Nein, das ist nicht an den Haaren herbeigezogen, es übersteigt nur > einfach deine Vorstellungskraft. Du hast ganz offensichtlich noch nie > ein Leiterplattenlayout gemacht. 8 Pin Designs so eine Wissenschaft? Ich glaub ich krieg gleich nen Lachkrampf. Wie schaff ich das bloß mit den TQFP32ern meiner Xmegas ???
Moby schrieb: > 8 Pin Designs so eine Wissenschaft? Ich glaub ich krieg gleich nen > Lachkrampf. Wie schaff ich das bloß mit den TQFP32ern meiner Xmegas ??? Sei froh, dass du als simpler Bastler keine EMV-Tests machen musst und in herrlich störarmen Umgebungen arbeiten darfst. Wenn dein Zeug in einem Industrieschaltschrank laufen muss, wo Leistungselektronik mit mehreren 100 Ampere und 10 kV/us neben deinen Signalleitungen herumschalten, würdest du vermutlich etwas anders darüber denken.
Moby schrieb: > Aber ich > wiederspreche vehement wenn mir jemand 32er HighEnd Boliden als > legitimen Nachfolger der einfachen AVRs verkaufen will. Das kann man tun. Aber es wird nichts am Lauf der Dinge ändern. Die Industrie wird bei den rasant fallenden Preisen mehr und mehr 32-Bitter einsetzen, eben weil man mit so einer Architektur wie ARM alles vom Blinklicht bis zum Touchscreen erschlagen kann. Es wird der Zeitpunkt kommen, wo man eben einen 32-Bitter für einen Piepser verwendet, einfach weil es preislich wurscht ist. Die Umsätze mit 8-Bittern gehen jetzt schon zurück und irgendwann werden sich die Fertigungslinien nicht mehr lohnen. Natürlich interessiert das Hobbybastler nicht - aber andersherum interessiert das wiederum die Hersteller nicht. Wenn mit 32-Bittern wesentlich mehr Umsatz und vor allem Gewinn zu machen ist (und die Margen sind da jetzt schon deutlich höher), dann wird der hersteller sich darauf konzentrieren. Eine Pinfunktionsmatrix ist übrigens wirklich eine feine Sache - so kann man bspw. Analogeingänge schön dorthin legen, wo die sonstigen Pins relativ "ruhig" sind. Glaub mir, man möchte keinen 1MHz-PWM-Ausgang neben einem ADC-Eingang haben :-)
Chris D. schrieb: > Aber es wird nichts am Lauf der Dinge ändern. Die Industrie wird bei den > rasant fallenden Preisen mehr und mehr 32-Bitter einsetzen, eben weil > man mit so einer Architektur wie ARM alles vom Blinklicht bis zum > Touchscreen erschlagen kann. Es wird der Zeitpunkt kommen, wo man eben > einen 32-Bitter für einen Piepser verwendet, einfach weil es preislich > wurscht ist. So sieht es aus. Chris D. schrieb: > Natürlich interessiert das Hobbybastler nicht - aber andersherum > interessiert das wiederum die Hersteller nicht. Bastler sind nur dann interessant, wenn sie potentielle Stückzahlenkunden werden. Also Studenten und professionelle Hardwareentwickler, die in ihrer Freizeit noch basteln. Chris D. schrieb: > Wenn mit 32-Bittern wesentlich mehr Umsatz und vor allem Gewinn zu > machen ist (und die Margen sind da jetzt schon deutlich höher), dann > wird der hersteller sich darauf konzentrieren. Genau. Im Moment geben viele Hersteller die Entwicklung von ihren eigenen Kernen auf. Vor allem im Low-Cost-Bereich, in denen sich die 8-Bitter tummeln, lohnt sich das einfach nicht mehr. Da ist es billiger, einen Standard-Kern (eben den M0) zu lizenzieren.
Embedded schrieb: > Chris D. schrieb: > Genau. Im Moment geben viele Hersteller die Entwicklung von ihren > eigenen Kernen auf. Vor allem im Low-Cost-Bereich, in denen sich die > 8-Bitter tummeln, lohnt sich das einfach nicht mehr. Da ist es billiger, > einen Standard-Kern (eben den M0) zu lizenzieren. Sicher. Deshalb führt Atmel mit den Xmegas ja auch eine neue Reihe ein- oder gerade jüngst zwei neue Tinys. Man kann hier viel prophezeien. Und ich prophezeie, die 8 Bitter behalten ihre Rolle. Todgesagt werden sie ja schon lange ;)
Moby schrieb: > Sicher. Deshalb führt Atmel mit den Xmegas ja auch eine neue Reihe ein- > oder gerade jüngst zwei neue Tinys. Man kann hier viel prophezeien. Und > ich prophezeie, die 8 Bitter behalten ihre Rolle. Todgesagt werden sie > ja schon lange ;) So etwas fällt unter Modellpflege. Natürlich kann Atmel noch problemlos neue Derivate mit bereits vorhandenen Kernen herausbringen, weil es ja auch noch viel Legacy-Code gibt, den ihre Kunden in neuen Projekten weiterverwenden wollen. Die Preisfrage ist: Welche Bemühungen steckt Atmel in die Weiterentwicklung des Kerns? Die XMEGA sind jetzt ja schon ein paar Jahre alt, der 32-Bit-Boom hat aber erst vor 1-2 Jahren überhaupt angefangen, das war zur XMEGA-Zeit noch gar nicht so abzusehen. Übrigens: Falls es dir entgangen ist, wurde in der gleichen Zeit ein neuer M0 und viele M4-Typen eingeführt.
Chris D. schrieb: > Es wird der Zeitpunkt kommen, wo man eben > einen 32-Bitter für einen Piepser verwendet, einfach weil es preislich > wurscht ist. Genau. Und der erforderliche Code hat dann 20 MB... Kommen Dir bei solchen Vorhersagen keine Zweifel? Soll das der Weisheit letzter Schluß sein?
Moby schrieb: > Deshalb führt Atmel mit den Xmegas ja auch eine neue Reihe ein- > oder gerade jüngst zwei neue Tinys. Deshalb läuft auf http://www.atmel.com/ erst mal Werbung für den M4 - und unter Products > Microcontrollers läuft Werbung für den M0+ Wobei allerdings der AVR-Markt am Leben erhalten wird, dadurch dass es den kleinsten ATSAMD20 mit 16KB Flash und 2KB RAM erst ab 64er Package gibt (bei NXP gibt es M0+ ab 8er Package).
Moby schrieb: > Genau. Und der erforderliche Code hat dann 20 MB... > Kommen Dir bei solchen Vorhersagen keine Zweifel? > Soll das der Weisheit letzter Schluß sein? Wieso soll der Pipser 20MB Code benötigen? Willst Du etwa gleich noch 19,999999MB MP3 Dateien mit dazu linken??? - Dann würde der AVR auch 20MB benötigen g Schreibe doch mal einen C-Code für eine Blink LED für den AVR - dann schauen wir mal wie viel mehr Aufwand es für einen ARM/STM32 effektiv ist. Wenn Du solche haltlose Sprüche klopfst, dann muss Du schon was vorweisen können. Rumpupsen tust Du ja schon genügend - extra damit der Thread oben bleibt und viel Werbung für den STM32 gemacht wird...
:
Bearbeitet durch User
Moby schrieb: > Und der erforderliche Code hat dann 20 MB... Es wurde ja hier schon gezeigt, dass M3-Code i.d.R. kleiner als AVR-Code ist, und M0-Code etwas größer. Das liegt daran, dass beim M3 alle Befehle bedingt ausgeführt werden können, und so kaum Jumps benötigt werden, und dass durch Bitbanding direkt auf die Ports zugegriffen werden kann (wie beim AVR auch). Der M0 kann das nicht, und um M0-Code kleiner als AVR-Code zu bekommen wurde beim LPC zu einigen Tricks gegriffen: es gibt für die Ports Toggle-Register und ROM-Treiber (USART, I2C, USB)
@ Markus Müller (mmvisual) >Wenn Du solche haltlose Sprüche klopfst, dann muss Du schon was >vorweisen können. Rumpupsen tust Du ja schon genügend - extra damit der >Thread oben bleibt und viel Werbung für den STM32 gemacht wird... Das sagt der Richtige . . .
@ Chris D. (myfairtux) (Moderator) Benutzerseite >Aber es wird nichts am Lauf der Dinge ändern. Die Industrie wird bei den >rasant fallenden Preisen mehr und mehr 32-Bitter einsetzen, eben weil >man mit so einer Architektur wie ARM alles vom Blinklicht bis zum >Touchscreen erschlagen kann. Stimmt. > Es wird der Zeitpunkt kommen, wo man eben >einen 32-Bitter für einen Piepser verwendet, einfach weil es preislich >wurscht ist. Kann sein. >Die Umsätze mit 8-Bittern gehen jetzt schon zurück und irgendwann werden >sich die Fertigungslinien nicht mehr lohnen. Irgendwann schon, aber nicht sooo bald. Da reden wir vielleicht von 10-20 Jahren 8051 lebt auch schon ewig. >Wenn mit 32-Bittern wesentlich mehr Umsatz und vor allem Gewinn zu >machen ist (und die Margen sind da jetzt schon deutlich höher), Sicher? Ist es nicht eher ein halbleitertypischer, gandenloser (Verdrängungs)Preiskampf? Wenn ein Prozess bzw. ein Produkt in großer Menge erstmal läuft, wird es gnadenlos ausgesaugt und die Margen gehen bis an die Schmerzgrenze runter. Schau dir die aktuellen Preise an! >Eine Pinfunktionsmatrix ist übrigens wirklich eine feine Sache - so kann >man bspw. Analogeingänge schön dorthin legen, wo die sonstigen Pins >relativ "ruhig" sind. Glaub mir, man möchte keinen 1MHz-PWM-Ausgang >neben einem ADC-Eingang haben :-) Sicher hat so eine Matrix viele nette Vorteile und kann bestimmte Situationen, die mit bisherigen "Festverdrahtungen" nicht möglich waren, jetzt möglich machen. Aber man kann diesen Vorteil auch überbewerten. Bisher war es ausreichend, VORHER mal den Kopf einuschalten und die Pinbelegung passend zu wählen. Heute kann man ggf. so einen Designfehler per Software lösen. Wenn es aber WIRKLICH um die Nachbarschaft sensibler Analogtechnik zu Digitalkram geht, ist so oder so der ENTWICKLER mit Wissen und Erfahrung gefragt, da bringt weder ARM noch AVR allein sonderlich viel.
> Und der erforderliche Code hat dann 20 MB...
Stimmt das? Ich hätte jetzt gedacht, dass ich für einen 8bit unter
Umständen mehr Code brauche. Der muss ja zB. für eine Berechnung viel
mehr Schritte durchführen als ein 32bit der zB. auch noch ne FPU und DMA
hat.
Moby schrieb: > Chris D. schrieb: >> Es wird der Zeitpunkt kommen, wo man eben >> einen 32-Bitter für einen Piepser verwendet, einfach weil es preislich >> wurscht ist. > > Genau. Und der erforderliche Code hat dann 20 MB... Das ist Unsinn. Bei Programmen gleicher Funktionalität ist der Code mit größerer Registerbreite platzmäßig immer im Vorteil. Das fängt ja schon bei einer einfachen 16-Bit-Addition an. > Kommen Dir bei solchen Vorhersagen keine Zweifel? Warum sollten sie? > Soll das der Weisheit letzter Schluß sein? Es wird vermutlich so kommen - das hat mit Weisheit wenig zu tun. Die 32-Bitter werden sich einen Preiskampf liefern und die 8-Bitter werden dann zwischen 0 und 1€ (bzw. dann den billigsten 32-Bittern) zerdrückt werden. @Falk: Der 8051 lebt in Neuentwicklungen fast nur noch in FPGAs. Diejenigen, die damit groß geworden sind (es gab ja nix anderes) sterben langsam aus.
Chris D. schrieb: > Die 32-Bitter werden sich einen Preiskampf liefern und die 8-Bitter > werden dann zwischen 0 und 1€ (bzw. dann den billigsten 32-Bittern) > zerdrückt Na schaun mer mal wer Recht behält. Das Forum gibts ja hoffentlich noch ne Weile, dann werd ich Dir in 5 Jahren diese Aussage nochmal unter die Nase reiben- äh pupXXX :)
Falk Brunner schrieb: >>Wenn mit 32-Bittern wesentlich mehr Umsatz und vor allem Gewinn zu >>machen ist (und die Margen sind da jetzt schon deutlich höher), > > Sicher? Ist es nicht eher ein halbleitertypischer, gandenloser > (Verdrängungs)Preiskampf? Wenn ein Prozess bzw. ein Produkt in großer > Menge erstmal läuft, wird es gnadenlos ausgesaugt und die Margen gehen > bis an die Schmerzgrenze runter. Schau dir die aktuellen Preise an! ack! und dann geht es los: übernahmen, ausgliederungen, entlassungen (siehe Renesas). wenn ein hersteller über den preis versucht marktanteile zu gewinnen, hat er wohl nichts anderes zu bieten. die 32bit umsätze sind deswegen so hoch da der asp (average sales price) höher liegt als für die 8Bitter. Wenn 8bit günstiger wird, ist doch klar dass dann noch viel mehr verkauft werden muß um den level zu halten. 8bit applikationen wie sensorik/steuerungen bleiben 8bit, 32bit für TCP/IP, high-end stacks, touchscreens - wobei da ist ein BOM mit einem kleinen ARM9 für 4$ (z.b. sam9n12) + sdram und flash deutlich billiger als ein stm32f4 tft controller der an seiner Leistungsgrenze liegt. Da nimmt man dann gliech ARM9/CortexA + Linux und lässt die High-End MCU wie STM32F4 links liegen :>
Falk Brunner schrieb: > Irgendwann schon, aber nicht sooo bald. Da reden wir vielleicht von > 10-20 Jahren 8051 lebt auch schon ewig. Aber auch nur gerade so. Außerdem: Bis vor zwei Jahren gab es auch noch keine ernsthafte Konkurrenz zu 8-Bittern im unteren Leistungsbereich. Falk Brunner schrieb: > Bisher war es ausreichend, VORHER mal den Kopf > einuschalten und die Pinbelegung passend zu wählen. Das hilft aber auch nichts, wenn man dann einen größeren Prozessor braucht oder für 10 Designs 5 verschiedene Teile einführen muss. Moby schrieb: > Na schaun mer mal wer Recht behält. Das Forum gibts ja hoffentlich noch > ne Weile, dann werd ich Dir in 5 Jahren diese Aussage nochmal unter die > Nase reiben- äh pupXXX :) In fünf Jahren wirst du verzweifelt noch einzelne 8-Bitter suchen, die irgendwo noch in Legacy-Produkten eingesetzt werden, nur um dein Argument zu gewinnen. martin schrieb: > ack! und dann geht es los: übernahmen, ausgliederungen, entlassungen > (siehe Renesas). Die Übernahmewelle ist schon in vollen Gange (Luminary->TI, Energy Micro -> Silicon Labs, Fujitsu -> Spansion). martin schrieb: > 8bit applikationen wie sensorik/steuerungen bleiben 8bit, 32bit für > TCP/IP, high-end stacks, touchscreens Nein, typische 8-Bit-Anwendungen werden zunehmend von M0 besetzt.
martin schrieb: > wobei da ist ein BOM mit einem > kleinen ARM9 für 4$ (z.b. sam9n12) + sdram und flash deutlich billiger > als ein stm32f4 tft controller der an seiner Leistungsgrenze liegt. Da > nimmt man dann gliech ARM9/CortexA + Linux und lässt die High-End MCU > wie STM32F4 links liegen :> Mit einem ARM9 kannst du heute niemandem mehr hinter dem Ofen hervorlocken. Hoffnungslos veraltet und lahm. Manchmal werden zwar 300-400 Mhz erreicht und das klingt toll, aber der ARM9 hat eine miese IPC, der Befehlssatz ist nicht sehr leisstungsstark und der Stromverbrauch ist hoch. Warum ein ARM9 Dinge problemlos schaffen sollte, die einen Cortex-M4 an die "Leistungsgrenze" bringen, ist nicht schlüssig. Wenn's ein großes OS wie Linux sein muss, dann ist das wieder ein ganz anderes Kaliber und man braucht viel RAM und Flash, kann mir im Leben nicht vorstellen, dass das billiger als ein integrierter High-End-Mikrocontroller wird. Vor allem steigt die Komplexität ins Unermessliche.
martin schrieb: > wobei da ist ein BOM mit einem > kleinen ARM9 für 4$ (z.b. sam9n12) + sdram und flash deutlich billiger > als ein stm32f4 tft controller der an seiner Leistungsgrenze liegt. Da > nimmt man dann gliech ARM9/CortexA + Linux und lässt die High-End MCU > wie STM32F4 links liegen :> Weder die BOM-Kosten dürften zu halten sein, selbst wenn man die Platinenfläche ausser Acht lässt, noch die Leistungsaufnahme. Ausserdem kommt der STM32F429 kommt bei 180Mhz schon auf die 600 CoreMarks die der SAM9N12 bei 400Mhz erst erreicht. Und da ist die DSP-Extension noch garnicht berücksichtigt.
Wer sich für die Codesize-Frage interessiert sollte unbedingt folgenden Artikel lesen: http://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_(full).pdf
Embedded schrieb: > Falk Brunner schrieb: >> Bisher war es ausreichend, VORHER mal den Kopf >> einschalten Dafür würde ich auch plädieren. > In fünf Jahren wirst du verzweifelt noch einzelne 8-Bitter suchen, die > irgendwo noch in Legacy-Produkten eingesetzt werden, nur um dein > Argument zu gewinnen. Prima. Noch so eine hochfliegende Prophezeiung auf die sich wunderbar festnageln lässt. Ich nehme aber an in 5 Jahren bist Du dann nicht mehr unter Deinem heutigen Gastnamen erreichbar ;) Die Protagonisten des aufgehenden 32 Bit Strohfeuers werden sich noch wundern: In 5 Jahren zerrieben zwischen ARM/64 High End und 8 Bit für die Alltags-MSR... > Nein, typische 8-Bit-Anwendungen werden zunehmend von M0 besetzt. Kurz nach Erscheinen nimmt es ja nicht wunder das damit ein paar Prozent des Marktes besetzt werden. Es ist doch sehr die Frage wielang der Trend anhält, dazu haben sie gegenüber den Branchengrößen AVR & PIC viel zuwenig zu bieten was zum Umstieg motivieren könnte.
Embedded schrieb: > Weitere Beispiele: Debugging. Eine Debugeinheit macht den Controller > komplexer. Aber man kann die internen Abläufe seines Programms besser > nachvollziehen. Ergo: Die Entwicklung mit dem Prozessor wird um ein > vielfaches einfacher und schneller. Tja Embedded man sollte schon unterscheiden zwischen Komplexität die sich auf die Funktion auswirkt (verkompliziert) und solcher, die quasi nur dem "Service" dient.
Moby schrieb: > Branchengrößen AVR & PIC In der Bastler-Branche :-) Laut Microcontroller Market Report hat 8051 immer noch den größten Marktanteil nach Stückzahlen, dann kommt ARM und danach PIC. AVR wird nur noch unter "Others" geführt ...
Embedded schrieb: > Debugging. Eine Debugeinheit macht den Controller > komplexer. http://dangerousprototypes.com/2014/01/25/pic16f1454-used-as-inexpensive-arm-debugger/
Ist mir wurscht, wer den größten Marktanteil hat. Für mich geht es eher darum, möglichst viel ohne Float zu erledigen. Da sind momentan noch die 32-er am Drücker, die Integer-Arithmetik mit den 8-Bittern ist bei den heutigen (Integer!)-Präzisionen der meisten Sensoren eh am Ende der Laufbahn angelangt. So sollte man das sehen, finde ich: Was an Präzision soll rein, was soll raus. Und das so schnell wie möglich. Würde mich auch notfalls in 64-Bitter einarbeiten. Aber aus irgendeinem blöden Gefühl heraus möchte ich nicht schneller den eigenen Programmcode compilieren können, als das der PC für mich tut :p
Lothar schrieb: > Moby schrieb: >> Branchengrößen AVR & PIC > > In der Bastler-Branche :-) > > Laut Microcontroller Market Report hat 8051 immer noch den größten > Marktanteil nach Stückzahlen Wirklich? Na wie oft wurden die erst totgesagt... Anscheinend spielen doch noch ein paar Gründe mehr mit im Konzert der Controllerauswahl, als es die 32 Bit Fraktion glauben machen möchte :-)
Moby schrieb: > Lothar schrieb: >> Moby schrieb: >>> Branchengrößen AVR & PIC >> >> In der Bastler-Branche :-) >> >> Laut Microcontroller Market Report hat 8051 immer noch den größten >> Marktanteil nach Stückzahlen > > Wirklich? Na wie oft wurden die erst totgesagt... Anscheinend spielen > doch noch ein paar Gründe mehr mit im Konzert der Controllerauswahl, als > es die 32 Bit Fraktion glauben machen möchte :-) Ja, aber wie lange noch? Ich als Bastler muß nicht vorausschauen, aber als Profi kann man doch nicht vernachlässigen, daß die Gehäusegrößen, die Rechenpower, alles Physikalische dafür spricht, in einem Register mehr als 8 Bit unterzubringen? Insofern geht es meiner Meinung nach eher darum, gute Bibliotheken und Archive, die sich unter AVR, PIC, MC68HC11, Z80 ;) inzwischen etabliert haben, auf die neuen Erfordernisse umzustellen. Es ist nicht die Frage des WANN?, sondern des Warum NICHT? Mann kann das irgendwelchen dahergelaufenen BWL-ern überlassen, aber warum sollte man das als Ingenieur tun, wenn man das Ende der 8-Bitter schon klar sehen ann?
Gibt es so ein ARM-Trainingscenter auch an einer deutschen Hochschule? http://www.prnewswire.com/news-releases/embedded-systems-institute-to-become-arm-approved-training-center-in-china-59992932.html
Habe die 8051er vergessen. Allerdings aus gutem Grund: Irgendwann mal kurz nach'm Krieg kam die große Idee, "EZ" mit "easy" abzukürzen. Hoho. War ne gute Idee, ging aber bei mir fürchterlich - zumindest bei den kleineren 8-Bittern von Cypress (AN2131, 2135, FX2 (klein?)) - in die Hose. Damals hatte ich noch Win98, da liefen die Treiber und man konnte die Chips hinreichend kontrollieren, um TATSÄCHLICH den momentanen RAM-Inhalt in den PC zu transportieren. Es reichte sogar, um DACs und ADCs auf atomarer Ebene zu kontrollieren. War fast wie beim ISA-Bus, nur bißchen schneller. Nur, unter XP lieferten die Dinger meist nur noch einen Device I/O-error. Wahrscheinlich war ich zu blöd, ok. Aber auch nicht bei jedem Rechner; es hing vom USB-Port ab. Und vom Treiber, von denen ca. 4-5 verschiedene kursierten, und der von Cypress - original - funktionierte generell nicht mehr unter XP - kein gutes Zeichen. Bei "EZ" hatte ich mich auf ein kinderleichtes Zusammenspiel von RAM im AN213x und PC verlassen, stattdessen war der Scheiß ein Vabanque-Spiel. Mal ging's, mal nicht. Das hat natürlich nichts mit dem 8051-er Core zu tun. Außer, daß ich danach auf AVR umgestiegen bin. Und dann eben kürzlich auf STM32. Wer sich im Zwischenbereich befindet, also bei 16-Bittern oder bei extrem Low-Power-Anwendungen, mag ebendiese Gründe dafür haben, die aber auch nicht mehr lange standhalten.
Moby schrieb: > Es ist doch sehr die Frage wielang > der Trend anhält, dazu haben sie gegenüber den Branchengrößen AVR & PIC > viel zuwenig zu bieten was zum Umstieg motivieren könnte. Klar bieten 32Bitter für dich nichts, weil du in deiner 8-Bit-Welt fest hängst und aus deiner kleinen Bastlersicht einfach nicht hinaus kommst.. Die Industrie rennt im Moment in Massen zum 32-Bit, weil die kleinen ARM fast nur Vorteile haben und dabei billiger sind. Hier wurden ja schon tausende Beispiele genannt, aber das alles glaubst du ja nicht. Moby schrieb: > Tja Embedded man sollte schon unterscheiden zwischen Komplexität die > sich auf die Funktion auswirkt (verkompliziert) und solcher, die quasi > nur dem "Service" dient. Ach ja, jetzt plötzlich. Vorhin hast du nur gesagt, für dich zählt nur die Komplexität des Controllers an sich. Du kannst dir deine Aussagen natürlich immer so drehen, wie du willst. Fakt ist, dass folgende Einheiten die Komplexität des Controllers erhöhen aber die Anwendung vereinfachen: - Frei konfigurierbare Peripheriematrix (nicht zu verwechseln mit nicht frei konfigurierbaren Alternativfunktionen) - DMA - Debuggingeinheit - Floatingpoint-Einheit - Hardwaremultiplizierer/Hardwaredivider - Integrierte LCD-Controller und Ethernet-MAC, die dedizierte Chips ersetzen Auf Softwareseite erhöhen Bibliotheken und Betriebssysteme auch die Komplexität, können die Anwendung und die Wartung auch einfacher machen, wenn sie richtig umgesetzt werden. Auch hier ist der Bastlermarkt aber nicht repräsentativ. Lothar schrieb: > Laut Microcontroller Market Report hat 8051 immer noch den größten > Marktanteil nach Stückzahlen, dann kommt ARM und danach PIC. AVR wird > nur noch unter "Others" geführt ... Renesas und Freescale sind umsatztechnisch weit vor Microchip und Atmel, und zwar mit Prozessoren, die zumindest hierzulande kein Bastler kennt. Das sind die wahren Branchengrößen. 8051 sind natürlich noch ganz vorne, weil die früher einfach von jedem Hersteller gebaut worden: http://en.wikipedia.org/wiki/Intel_MCS-51#Derivate_vendors Außerdem wird der 8051 gerne in IC als Hilfsprozessor verbaut, der häufig noch nicht einmal für den Nutzer zugänglich ist, zum Beispiel in digitale Schaltregler oder in Bluetoothcontrollern. Der Vorteil des Kerns ist, dass man ihn auch in "analogen" Halbleiterprozessen in einer vernünftigen Fläche fertigen kann. Und das ist auch der einzige Bereich, in denen ich in 5-10 Jahren überhaupt noch 8-Bitter erwarten würde. Trotzdem: Inzwischen setzt z.B. TI dort auch ihren MSP430 ein. Beim M0 liest sich die Liste auch schon ähnlich, und das obwohl es ihn erst seit 2 Jahren gibt. Die Liste ist nur kürzer, weil sich der Markt inzwischen konsolidiert hat und viele Hersteller auf der 8051-Liste gar nicht mehr existieren. Im Prinzip alle großen Hersteller bieten inzwischen Cortex M0 µC an (inklusive den echten Branchengrößen wie Freescale und Infineon), Ausnahmen sind Renesas und Microchip. Ich würde aber mal davon ausgehen, dass erstere sich aus dem Kleinprozessormarkt zurückziehen und sich eher auf ihre größeren DSP konzentrieren und letztere in den nächsten 2-5 Jahren mit einem ARM-Produkt nachziehen. Außerdem würde ich erwarten, dass die Chinesen demnächst mit einem kleinen 32-Bit-Kern nachziehen, womöglich sogar binärkompatibel zum ARM.
Embedded schrieb: > Renesas und Freescale sind umsatztechnisch weit vor Microchip und Atmel Im Gesamtumsatz aber nicht bei uC. Und grade Renesas macht ja keinen Gewinn damit und muss jedes Jahr von seinen Automotive-Kunden mit Krediten gerettet werden (kein Wunder bei 16 inkompatiblen uC-Kernen, die gepflegt werden müssen). Embedded schrieb: > Außerdem würde ich erwarten, dass die Chinesen demnächst mit einem > kleinen 32-Bit-Kern nachziehen, womöglich sogar binärkompatibel zum ARM. Die scheinen auf MIPS zu setzen ...
@ Lothar (Gast) >Krediten gerettet werden (kein Wunder bei 16 inkompatiblen uC-Kernen, >die gepflegt werden müssen). Hätten die mal gleich auf STM32 gesetzt ;-) Naja, man muss halt immer abwägen. "One size fits all" wird zwar immer mal wieder propagiert, funktioniert aber nur sehr eingeschränkt. Keine Architektur hat endlose Skalierbarkeit. Bei STM32 scheint das ja dennoch recht gut zu klappen. Man wird sehen, wie sich die Sache entwickelt und ob in ein paar Jahren vielleicht der STM32 dem AVR den Rang (im Forum?) abgelaufen hat. Verlockend ist er schon ;-) Aber Missionierung nervt!
Falk Brunner schrieb: > Hätten die mal gleich auf STM32 gesetzt ;-) Du meinst wohl eher auf einen Kern von ARM... Denn Renesas macht gute Peripherie, ich hatte den auch schon mal programmiert. Ich habe Renesas nur deshalb wieder weg geschmissen, weil es für mich im Hobby-Bereich den fast nicht zu kaufen gab, vom Chip selbst war ich zufrieden.
Markus Müller schrieb: > Ich habe Renesas nur deshalb wieder weg geschmissen, weil > es für mich im Hobby-Bereich den fast nicht zu kaufen gab, vom Chip > selbst war ich zufrieden. Das wundert mich jetzt aber. Du redest doch hier von 1000er Stückzahlen und schaffst es nicht einmal, ein Einzelstück zu besorgen? Pantoffelprofi, wa?
Embedded schrieb: > Fakt ist, dass folgende > Einheiten die Komplexität des Controllers erhöhen... Na also. Darauf lässt sich ja schon mal aufbauen. Embedded schrieb: > Auf Softwareseite erhöhen Bibliotheken und Betriebssysteme auch die > Komplexität, Deshalb alles konsequent in Asm. Das ist und bleibt das Einfachste. Und dafür sind die ARMs kaum noch konzipiert. Embedded schrieb: > können die Anwendung und die Wartung auch einfacher machen, > wenn sie richtig umgesetzt werden. Na wenn da nicht die oft/meist kompliziertere Programmierung mit dem Zaunpfahl winkt ;) Und selbst wenn es "richtig" umgesetzt wird- hat Dir jemand Dein Wissen darüber unters Kopfkissen gelegt? War wahrscheinlich auch ein langer Weg über Studium usw. Dieses notwendige Wissen geht dann aber auch in die Gesamt-Aufwandsbilanz ein. Ein Aufwand der eben für viele Anwendungen völlig unverhältnismäßig ist.Unter dem Strich jedenfalls ist und bleibt das Gesamtpaket bei 8-Bit das Einfachste- und es ist schlicht lächerlich das abzustreiten. Embedded schrieb: > weil du in deiner 8-Bit-Welt fest > hängst und aus deiner kleinen Bastlersicht einfach nicht hinaus kommst.. Die "kleine Bastlersicht" ermöglicht schlicht das Optimum von Aufwand & Nutzen. Finds ja auch bedauerlich daß der Industrie-Entwickler sehr viel mehr zu beachten hat, z.B. Embedded schrieb: > Sei froh, dass du als simpler Bastler keine EMV-Tests machen musst und > in herrlich störarmen Umgebungen arbeiten darfst. Wenn dein Zeug in > einem Industrieschaltschrank laufen muss, wo Leistungselektronik mit > mehreren 100 Ampere und 10 kV/us neben deinen Signalleitungen > herumschalten, würdest du vermutlich etwas anders darüber denken.
Dennis S. schrieb im Beitrag #3505304: > Deshalb alles konsequent in Asm. Das ist und bleibt das Einfachste. > Und dafür sind die ARMs kaum noch konzipiert. Nein, ASM taugt allenfalls für Kleinstprojekte, selbst für einfachste Sensorikanwendungen taugt es einfach nicht, weil schlecht wartbar und schlecht portierbar. In der Industrie ist Assembler quasi ausgestorben, die µC-Welt spricht C. Und genau das ist ein Grund für die M0, die sich wunderbar in C programmieren lassen. Dennis S. schrieb im Beitrag #3505304: > Ein Aufwand der eben für > viele Anwendungen völlig unverhältnismäßig ist. Wenn an einem Softwareprojekt 5+ Leute arbeiten und der Code auch in 20 Jahren noch verstanden werden soll, ohne großen Einarbeitungsaufwand, dann muss man sich über den Pflegeaufwand Gedanken machen. Ich habe im Beruf schon mehr als einmal gehört: "Das alte Programm war in Assembler, das werden wir noch einmal komplett in C neu schreiben, weil das schneller geht, als sich in den alten Code einzuarbeiten." Und ja, das gilt in erster Linie bei Kleinstprojekten, die man in < 1000 Zeilen C-Code realisieren kann. Dennis S. schrieb im Beitrag #3505304: > Unter dem Strich > jedenfalls ist und bleibt das Gesamtpaket bei 8-Bit das Einfachste- und > es ist schlicht lächerlich das abzustreiten. Es ist aber immer noch falsch. Wieso soll 32 Bit per se komplexer sein? Der C-Code unterscheidet sich erst einmal kein bisschen. Wenn die Peripherie komplexer geworden ist, hat das erst einmal rein gar nichts mit 8, 16 oder 32 Bit zu tun. Wer die Peripherie von einem XC166 gesehen hat, versteht wovon ich rede. Dennis S. schrieb im Beitrag #3505304: > Die "kleine Bastlersicht" ermöglicht schlicht das Optimum von Aufwand & > Nutzen. Finds ja auch bedauerlich daß der Industrie-Entwickler sehr viel > mehr zu beachten hat, z.B. Nur funktioniert die Sicht eben in der Industrie nicht mehr. Da gibt es andere Maßstäbe. Und Stückzahlen werden in der Industrie gemacht. Für die paar Bastler interessiert sich hinterher keiner mehr. Trotzdem gibt es bei Bastlern im Moment den Trend, Anwendungen mit einem Raspberry Pi zu machen, die man auch mit einem Atmega erledigen könnte. Einfach weil man es kann, weil das Raspberry Pi für PC-User viel einfacher anzuwenden ist und weil es billiger ist (kostet so viel wie ein AVR ISP).
Embedded schrieb: > Trotzdem gibt es bei Bastlern im Moment den Trend, Anwendungen mit einem > Raspberry Pi zu machen, die man auch mit einem Atmega erledigen könnte. Ist nur interessant wenn man die eingebaute Linux-Netzwerkfunktionalität nutzen möchte oder ein großes Display anschließen will > Einfach weil man es kann, Ja warum nicht, ist doch interessant, gerade für Internet-ansprechbare Anwendungen oder für Python-Anwender. > weil das Raspberry Pi für PC-User viel einfacher anzuwenden ist ... ist vollkommener Käse. Das Linux bringt da dermaßen Komplexität rein, da sollte man schon ein wenig Knowhow mitbringen. > und weil es billiger ist Nur wenn man wirklich die gebotene Funktionalität nutzt, sonst ist das genauso Quatsch.
Moby schrieb: > Ist nur interessant wenn man die eingebaute Linux-Netzwerkfunktionalität > nutzen möchte oder ein großes Display anschließen will Das geht doch auch mit einem AVR! Moby schrieb: > Nur wenn man wirklich die gebotene Funktionalität nutzt, > sonst ist das genauso Quatsch. Das tun aber viele eben nicht. Erzähl mal das den Bastlern, dass das, was sie da tun, Quatsch ist. Moby schrieb: > ... ist vollkommener Käse. Das Linux bringt da dermaßen Komplexität > rein, da sollte man schon ein wenig Knowhow mitbringen. Nicht wirklich. Es gibt fertige Distributionen mit SD-Karten-Image. Programiert wird dann einfach in Python. Für einen PC-User ist das immer noch einfacher als sich mit uC-Registern herumzuärgern.
Moby schrieb: > Deshalb alles konsequent in Asm. Das ist und bleibt das Einfachste. > Und dafür sind die ARMs kaum noch konzipiert. Da ARM vor AVR entwickelt wurde, auf 6502-Basis, wurde großer Wert darauf gelegt, Assembler einfach, logisch und mächtig zu machen. Dazu mal wieder der größte gemeinsame Teiler: int gcd (int a, int b) { while (a != b) { if (a > b) a = a - b; else b = b - a; } return a; } gcd CMPS R0, R1 SUBGT R0, R0, R1 ; greater than > SUBLE R1, R1, R0 ; less or equal <= BNE gcd Dasselbe in AVR-Assembler, vielleicht auch noch für 16-bit Integer - kann man vergessen. Allerdings will die Mehrheit der Embedded-Entwickler in der Industrie Assembler nicht mehr anfassen, daher wurde der Cortex-M auf C optimiert, selbst der Startup-Code "kann" in C gemacht werden.
Embedded schrieb: > Das tun aber viele eben nicht. Erzähl mal das den Bastlern, dass das, > was sie da tun, Quatsch ist. Na da erkenne ich aber doch ein wenig die Neigung, das Wort im Munde umzudrehen, oder? Quatsch ist natürlich nicht was Bastler tun sondern allein die Aussage der Raspi wäre billiger als eine Avr-Lösung Embedded schrieb: >> Unter dem Strich >> jedenfalls ist und bleibt das Gesamtpaket bei 8-Bit das Einfachste- und >> es ist schlicht lächerlich das abzustreiten. > > Es ist aber immer noch falsch. Wieso soll 32 Bit per se komplexer sein? Irgendwie magst Du nicht recht verstehen was Gesamtpaket meint? Was meinst Du wohl weswegen es soviele AVR/Pic-Entwickler, soviele Arduino-Entwickler usw. gibt? Ich glaube langsam die umfassende Sicht des Profis ist für gewisse Aspekte der Aufwandsbeurteilung und insbesondere das Motto "Keep it simple" blind... Aber gut, es gibt in der Industrie eben andere Prioritäten :)
Moby schrieb: > Quatsch ist natürlich nicht was Bastler tun sondern allein die Aussage > der Raspi wäre billiger als eine Avr-Lösung Doch, das kann durchaus sein, je nachdem was man sich genau anschafft und welche Bezugsquellen man hat. Bei Reichelt kostet ein AVR ISP immerhin 36 Euro, dafür bekomme ich schon ein komplettes Raspberry Pi. Moby schrieb: > Irgendwie magst Du nicht recht verstehen was Gesamtpaket meint? Gesamtpaket heißt bei dir genau das, was dir gerade in den Kram passt. Für professionelle Anwendungen ist der M0 in den allermeisten Fällen das einfachere Gesamtpaket, weil man dort eben nach anderen Maßstäben arbeitet. Dann heißt es von dir "Ja, aber die Bastler". Dann habe ich Bastleranwendungen gezeigt, bei denen ein 32-Bit-System günstiger und einfacher ist. Aber das passt dir nicht in den Kram, deshalb versuchst du das irgendwie weg zu disktutieren.
Nur mal so Erst gab es Windows 3.11 Dann mal Windows 98 Und Windows XP Und auch Windows 8 Wer nutzt denn heute noch Windows 3.11? Ist doch viel kleiner, passt auf nur 30 Disketten usw. Dennoch nutzt das heute niemand mehr. Komisch. Genau so ist es mit 8086 6502 Z80 68HC11 AVR PIC16 die werden auch mit der Zeit - ein durchaus langsamer Prozess - abgelöst durch modernere µC, sei es einer mit MIPS Kern oder Cortex Kern. Und jeder Hobby-Bastler, der auch mal damit richtig Geld verdienen möchte (z.B. Studenten) tut gut daran gleich auf das neu Pferd auf zu springen. Oder wer würde einen Systemadministrator heute einstellen, der nur Windows 3.11 Kenntnisse hat? Als Bastler kann man sich natürlich gerne heute noch mit Windows 3.11 erfreuen. Win3.11 funktioniert genau so, also ist der Wechsel zu was neuerem immer nur Zeitverschwendung. Ganz ungeachtet, dass man mit was neuem vielleicht auch schneller und einfacher arbeiten könnte - aber nein man muss da ja was lernen und Win3.11 kennt man schon auswendig. Wieso wird PC-Einsteigern denn kein Win3.11 empfohlen? - Ist doch viel einfacher und weniger Komplex!
:
Bearbeitet durch User
Markus Müller schrieb: > Oder wer würde einen Systemadministrator heute einstellen, der nur > Windows 3.11 Kenntnisse hat? Sagen wir so: zwischen zwei Bewerbern von denen einer zusätzlich WfW3.11 Kenntnisse hat, würde ich den wählen. Der kann nämlich 1. über den Tellerrand schauen, 2. hat er ein Blick in die historische Entwicklung von Windows - er weiß, warum manche Dinge so sind wie sie sind, weil sie halt so gewachsen sind. Andererseits: Wenn ich mir das Groß der Bewerber anschaue, die sich bei mir als Programmierer bewerben, dann steht bei den meißten nach Java nur noch Html - was auch immer das für eine Programmier sprache sein soll. Zurück zum Thema: die Anwendung und deren Parameter bestimmt die CPU. Punkt. Wenn der Entwickler das nicht einsieht, dann soll die Pfeife sich gefälligst trollen! Ein verzweifeltes Festhalten an 8Bittern ist genauso ein Blödsinn die das "32bit für Blinkenlights". Deshalb kann ich den "Fundamentalisten" hier im Thread nur ans Herz legen: lernt auch das jeweils andere oder ihr seit nur zweitklassige Frickler! (um es mal maßlos zu übertreiben)
> Ein verzweifeltes Festhalten an 8Bittern ist genauso ein Blödsinn die > das "32bit für Blinkenlights". In einem Unternehmen geht es um Profit. Das ist es worum es geht. Wenn 32bit genauso teuer ist wie 8bit, verliert 8bit. So einfach ist das. Ich glaube da muss man gar nicht so kompliziert denken.
> Allerdings will die Mehrheit der Embedded-Entwickler in der Industrie > Assembler nicht mehr anfassen Ich würde noch weiter gehen: Wenn Assembler angefasst wird, läuft irgendwas falsch (Ausnahmen bestätigen die Regel). Wenn in einer Werkstatt Dampfmaschine und Faustbeil ausgepackt wird, stimmt auch irgendwas nicht. So ist es auch mit Assembler. Wir leben im Jahr 2014!! Nächstes Jahr wird schon das Hoverboard erfunden und es werkeln immer noch welche mit Assembler rum!? ohje ohje :-)))
Für das Mini-Blinklicht hat NXP den LPC800 im DIP8 Gehäuse erfunden - nur damit man auch für die kleinen Applikationen auch die gleiche Entwicklungsumgebung verwenden kann. Natürlich könnte das auch ein 8-Bitter machen, denn die Anzahl der Bits ist unerheblich. Es ist nun mal immer eine Kostenfrage - möchte man wirklich zwei verschiedene JTAG-Adapter (als Bastler) kaufen? Und 2 IDE's kennen lernen? Die Ausnahme bildet Microchip, die haben einen Debugger für alle Chips - dafür ist man komplett an Microchip gebunden. Andy P. schrieb: > Zurück zum Thema: die Anwendung und deren Parameter bestimmt die CPU. Ja, genau. Punkt. Und das ist - wie schon mehrfach bewiesen - ist viel leichter realisierbar wenn man sich einen µC mit Cortex-Mx Kern heraus sucht und genau darum geht es in diesem Thread. Eine IDE, ein JTAG Adapter, eine Entwicklungsumgebung für kleine 8-Pinner bis hin zu den dicken BGA's mit 500 Pins. Das ist der Haken bei den 8-Bitter, die können nur das untere Segment abdecken. Und wenn man doch mal etwas größeres machen will, dann schaut man in die Röhre, ist aufgeschmissen und muss dann gezwungenermaßen eine zweite Entwicklungsumgebung aufbauen - was für einen Bastler wiederum Geld kostet.
Kenne den Stm32 jetzt ein Monat. Und seit dem ich weiß das es ein LPC800 gibt kann ich mir auch nicht mehr vorstellen zurück zu den 8Bit Pic zu gehen. Meine erste Anwendung war ein USB HID Device mit einem pic18f4550 in ASM. Damals habe ich hier im Forum auch ordentlich auf die Kappe bekommen, weil ich es gewagt habe ohne Blinky Project einzusteigen. Aber so ein Quark wie Blinklicht oder Taschenlampe interessiert mich nun mal nicht. Das kaufe ich fertig. So etwas ist ja auch keine richtige Anwendung.
dutz schrieb: > In einem Unternehmen geht es um Profit. Das ist es worum es geht. Wenn > 32bit genauso teuer ist wie 8bit, verliert 8bit. So einfach ist das. Ich > glaube da muss man gar nicht so kompliziert denken. jaja der einkäufer nagelt sich an die (immer) noch viel zu teure value line (egal ob stm32 value line die nicht getestet ist oder lpc der kaum peripherie hat). ehrlich gesagt das was ST/NXP einem als value line oder einstiegsmodell verkaufen ist immer noch viel zu teuer, da würd ich mich verar.... vorkommen. der einkäufer drückt dem entwickler die billigst chips auf, und dann muß er ein externes EEPROM an den 8piner hängen (oder stm32) wovon gleich mal 2pins wegfallen. oder einen externen adc. und schon gibt es zwei Bauteile von zwei unterschiedlichen Herstellern, verbraucht mehr platz auf der platine, mehr kosten. und wenn ich mir die value line ansehe, und den vorgeschlagenen stm32f030f4 für 0.42c nehme, und dann später mehr flash brauche, muß ich auf die "vollversion" umsteigen da es keine value line mit 32k flash oder mehr in 20pin gibt. also dann entweder den stm32f031f6 (doof nur dass diesen niemand führt), den stm32f042 auch nicht. dein einkäufer denkt dann: also wenn st mir den 16k flash für 0.4Euro verkauft, zahl ich für 32k flash nur ganz wenig mehr. oft ist es dann mind. das doppelte, da wie gesagt st dann den preis nicht halten kann da sie keine besserausgestattete modele mit mehr flash als value line anbieten. ganz übel, hilft halt nur noch anbieterwechsel, neue peripherie, neue toolchain, neue testsuite... mehr kosten
martin schrieb: > und dann muß er ein externes EEPROM an den 8piner hängen > (oder stm32) wovon gleich mal 2pins wegfallen. oder einen externen adc. Wieso muss man das? Wenn man mit den vorhandenen Peripheriebausteinen nicht klar kommt, nimmt man einen größeren Prozessor, der entsprechend ausgestattet ist. martin schrieb: > und wenn ich mir die value line ansehe, und den vorgeschlagenen > stm32f030f4 für 0.42c nehme, und dann später mehr flash brauche, muß ich > auf die "vollversion" umsteigen da es keine value line mit 32k flash > oder mehr in 20pin gibt. Und das gleiche kann dir bei einem Attiny auch passieren. Es ist nicht die Schuld der Chiphersteller, wenn der Entwickler den Ressourcenaufwand nicht richtig abschätzen kann. martin schrieb: > dein einkäufer denkt dann: also wenn st mir den 16k flash für 0.4Euro > verkauft, zahl ich für 32k flash nur ganz wenig mehr. oft ist es dann > mind. das doppelte, da wie gesagt st dann den preis nicht halten kann da > sie keine besserausgestattete modele mit mehr flash als value line > anbieten. Und auch das kann dir bei Attiny, MSP430, PIC oder sonst wo passieren. Das hat nichts mit ARM, 32 Bit oder sonst etwas zu tun. martin schrieb: > ganz übel, hilft halt nur noch anbieterwechsel, neue peripherie, neue > toolchain, neue testsuite... mehr kosten Und gerade das stimmt nicht. Neue Peripherie ja, aber die Toolchain bleibt die selbe. Bei einem Wechsel von AVR auf PIC geht das nicht.
dutz schrieb: > Wenn in einer Werkstatt Dampfmaschine und Faustbeil ausgepackt wird, > stimmt auch irgendwas nicht. So ist es auch mit Assembler. Wir leben im > Jahr 2014!! Dampfmaschinen (im weiteren Sinne) erzeugen auch im Jahr 2014 den überwiegenden Anteil des elektrischen Stromes...
Steam engine schrieb: > Dampfmaschinen (im weiteren Sinne) erzeugen auch im Jahr 2014 den > überwiegenden Anteil des elektrischen Stromes... Stimmt, sehe die Dampfwolken vom Fenster aus ...
Steam engine schrieb: > Dampfmaschinen (im weiteren Sinne) erzeugen auch im Jahr 2014 den > überwiegenden Anteil des elektrischen Stromes... Und das in einer Werkstatt ... tja Sachen gibts.
martin schrieb: > dann muß er ein externes EEPROM an den 8piner Der LPC800 ist eben für Billig-Anwendungen die kein EEPROM brauchen, dafür gibt es dann den LPC11E00 (mit E wie EEPROM). Andererseits hat der LPC800 ein ROM-API für IAP-Flash-beschreiben, das kann man auch nehmen (der Flash hat zudem 10x mehr Schreibzyklen als das EEPROM).
Lothar schrieb: > Andererseits hat der LPC800 ein ROM-API für IAP-Flash-beschreiben, das > kann man auch nehmen (der Flash hat zudem 10x mehr Schreibzyklen als das > EEPROM). Außerdem sind die Blöcke des Flash-Speichers kompakte 64 Byte groß. Das kann man doch sehr komfortabel als Ersatz für byteweise addressierbaren EEPROM verwenden. Es ist schon deutlich praktischer nutzbar als 256-512 Byte große Blöcke wie bei manch anderen Mikrocontrollern.
greg schrieb: > Außerdem sind die Blöcke des Flash-Speichers kompakte 64 Byte groß. Das > kann man doch sehr komfortabel als Ersatz für byteweise addressierbaren > EEPROM verwenden. Bei den LPC mit EEPROM diese auch in 64 Byte Bänke aufteilt. Man kann zwar 1 Byte einzeln in den 64 Byte Puffer schreiben, es kann aber immer nur der ganze Puffer in eine EEPROM Bank programmiert werden.
dutz schrieb: >> Ein verzweifeltes Festhalten an 8Bittern ist genauso ein Blödsinn die >> das "32bit für Blinkenlights". > > In einem Unternehmen geht es um Profit. Das ist es worum es geht. Wenn > 32bit genauso teuer ist wie 8bit, verliert 8bit. So einfach ist das. Ich > glaube da muss man gar nicht so kompliziert denken. Bei dem Thema, "genau so teuer", will ich mich mal wieder zu Wort melden. Hatte mal ein wenig nach STM32 gegooglet und die Preise für Einzelstücke lagen alle über drei Euro. Für einen uC mag das ja nicht viel sein, bei einem Bastler, aber wenn ich doch nur zwei Pins brauche, dann bin ich mit nem Tiny10 für 50 Cent doch deutlich billiger. Also wozu soll ich dann so einen uC nehmen, solange ich den anderen noch bekommen kann?
F. Fo schrieb: > Hatte mal ein wenig nach STM32 gegooglet und die Preise für Einzelstücke > lagen alle über drei Euro. Z.B. bei Mouser gibt's STM32 ab 1,16 EUR, LPC800 ab 0,97 EUR. Reichelt ist nicht das Maß der Dinge. Bei Aliexpress bekommst du auch die größeren (64-128 KB Flash, haufenweise Peripherie) ARMs teilweise unverschämt billig (< 2 EUR), wenn du ein bisschen auf die Post warten kannst.
Petit Ennui schrieb: > 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? Das würde mich auch interessieren.
Ich habe jetzt mal 20 Sekunden für euch gesucht: http://at.mouser.com/ProductDetail/Texas-Instruments/MSP-EXP430FR5739/?qs=sGAEpiMZZMvJv63gxJzgAmOwSteHFeyc Bei Mouser ist das sogar billiger.
:
Bearbeitet durch User
Bei Mouser kommen aber auch immer noch ~19% drauf also ist das dann nicht mehr ganz so günstig. edit: Markus Müller schrieb: > Ich habe jetzt mal 20 Sekunden für euch gesucht: > http://at.mouser.com/ProductDetail/Texas-Instrumen... > > Bei Mouser ist das sogar billiger. Soll das dieses Dragon sein wo im Artikel erwähnt wird?
:
Bearbeitet durch User
Ja, ich habe die Typ Bezeichnung mal bei Mouser eingegeben. Wenn man andere Boards von TI (und auch andere µC Hersteller) will, wird die vermutlich Mouser, Digikey oder Farnell auch haben. Von hier: http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger#MSP430_-_vom_MSP-EXP430FR5739_Experimentier-Board
:
Bearbeitet durch User
Markus Müller schrieb: > Erst gab es Windows 3.11 > Dann mal Windows 98 > Und Windows XP > Und auch Windows 8 > > Wer nutzt denn heute noch Windows 3.11? > Ist doch viel kleiner, passt auf nur 30 Disketten usw. Dennoch nutzt das > heute niemand mehr. Komisch. > > Genau so ist es mit > 8086 > 6502 > Z80 > 68HC11 > AVR > PIC16 Eigentlich ein klassischer Äpfel mit Birnen Vergleich... Aber ist Dir schon aufgefallen daß immer mehr Leute bei Win7 hängenbleiben weils einfach langt? Ist Dir schon aufgefallen daß der Trend zu immer schnelleren Desktop Prozessoren längst erlahmt ist weil spätestens ein Core Duo den meisten langt? Der Schwerpunkt hat sich inzwischen ganz woanders hin verlagert: Für die geplante Anwendung möglichst einfach, klein, effizient und stromsparend. Genauso wie mit 8 Bittern für Millionen Anwendungen schlicht das Optimum erreicht ist. Was hier zukünftig noch kommt sind eher innovative Features wie großes M/FRAM, eingebaute Echtzeit, selbstverwaltete Kontextwechsel und und und... Meine Wunschliste wär da noch sehr lang. Und der Xmega hat die Marschrichtung gezeigt.
dutz schrieb: > So ist es auch mit Assembler. Wir leben im > Jahr 2014!! Wollte damit jetzt keine zweite "Front" eröffnen, aber sei's drum. Was älter ist muß eben nicht deshalb schlechter sein. Ja, in der Industrie mag der Trend nicht zuletzt der Produktivität wegen längst woanders hingehen. Aber mit Asm bewahrt man sich ein Stück Einfachheit, die Freiheit alles und jedes unmittelbar und maximal effizient zu beeinflussen, nicht zuletzt auch (durch) das unmittelbare Hardware-Verständnis. Das alles geht noch so wunderbar auf den kleinen simplen 8-Bittern, die mit ihrer Leistung Millionen Anwendungen dennoch locker und lockerst auf die Bühne bringen :) Und was mir so geht geht sicher auch anderen so...
Embedded schrieb: > Gesamtpaket heißt bei dir genau das, was dir gerade in den Kram passt. Nein, Du verstehst es nicht, kannst und/oder willst nicht. So lasset die Welt Stück um Stück komplizierter und komplexer werden- bis keiner mehr durchblickt und alles zusammenbricht :)
Andy P. schrieb: > Zurück zum Thema: die Anwendung und deren Parameter bestimmt die CPU. > Punkt. Genau. Wenn die Anwendung 8 bittig realisierbar ist dann am besten so. Andy P. schrieb: > Ein verzweifeltes Festhalten an 8Bittern ist genauso ein Blödsinn die > das "32bit für Blinkenlights". Richtig. Eine Anwendung die 32 Bit erfordern würde hatte ich simpler Bastler noch nicht. Und werd sie vermutlich auch nicht bekommen, wenn ich bei Asm bleiben kann :-)
Moby schrieb: > So lasset die Welt ... und alles zusammenbricht :) Dann freue Dich schon mal drauf, danach wird sich zeigen welche Firmen noch übrig bleiben.
Markus Müller schrieb: > wird sich zeigen welche Firmen > noch übrig bleiben. Genau die die Produkte haben die man möglichst einfach einsetzen kann :)
Oder es setzt sich das System durch, das weitestgehend Herstellerunabhängig ist. (8051, ARM/Cortex) ARM/Cortex werden sicher überleben, weil die auch in den ganzen Handys drin sind.
Moby schrieb: > Genau die die Produkte haben die man möglichst einfach einsetzen kann :) Und genau deshalb werden sich M0 durchsetzen.
Embedded schrieb: > Moby schrieb: >> Genau die die Produkte haben die man möglichst einfach einsetzen kann :) > > Und genau deshalb werden sich M0 durchsetzen. Ja, das artet langsam zur Glaubensfrage aus... Jeder darf seine Meinung haben, weil er zu dieser nicht wie die Jungfrau zum Kind gekommen ist.
Moby schrieb: > Ja, das artet langsam zur Glaubensfrage aus... Jeder darf seine Meinung > haben, weil er zu dieser nicht wie die Jungfrau zum Kind gekommen ist. Das hat nicht viel mit Meinung zu tun, sondern mit harten Tatsachen. Viele Anwendungen sind mit 32 Bit und der moderneren Bustruktur einfacher zu erledigen. M0 sind in Stückzahlen billiger. Ein Standardkern ist für die Hersteller viel einfacher zu warten. Die Tatsache, dass man eine Toolchain für Kleinstanwendungen sowie mittlere Anwendungen einsetzen kann, wird in der Industrie sehr hoch geschätzt. Und deshalb werden sich die ARM-Kerne mittelfristig durchsetzen. An diesen Tatsachen kannst du nichts ändern, egal wie heftig du deine 8-Bitter noch mit deinen ewig schwachen Argumenten (aber... aber, die sind doch viel einfacher?!) verteidigst.
Embedded schrieb: > Viele Anwendungen sind mit 32 Bit und der moderneren Bustruktur > einfacher zu erledigen. Viele, Millionen aber auch nicht weil sie aus breiteren Bussen überhaupt keinen Vorteil ziehen. Hinzu kommt der (Lern-)Aufwand für den Umstieg. Embedded schrieb: > Ein > Standardkern ... wird sich noch heraustellen. Vielleicht auch mehrere Standards. Embedded schrieb: > M0 sind in Stückzahlen billiger. ... da ist ebenfalls das letzte Wort längst nicht gesprochen. Komplexere Controllerstruktur sollte im Prinzip hier im Nachteil sein. Embedded schrieb: > Die > Tatsache, dass man eine Toolchain für Kleinstanwendungen sowie mittlere > Anwendungen einsetzen kann, wird in der Industrie sehr hoch geschätzt. Das ist AVR-Studio + ein Debugger genauso. Alle diese "Tatsachen" beweisen mir: Nichts.
@ Embedded (Gast) >Das hat nicht viel mit Meinung zu tun, sondern mit harten Tatsachen. >Und deshalb werden sich die ARM-Kerne mittelfristig durchsetzen. Die Kombination von "harten Tatsachen" und der Zeitform Futur finde ich gewagt ;-)
Moby schrieb: > Viele, Millionen aber auch nicht weil sie aus breiteren Bussen überhaupt > keinen Vorteil ziehen. Hinzu kommt der (Lern-)Aufwand für den Umstieg. Selbst in einfachen Steuerungen hantiert man öfter mal mit 16 Bit großen Variablen, z.B. um Sensorwerte umzurechnen, und da hat man mit einer 32-Bit-CPU handfeste Vorteile. Ich habe nichts gegen 8-Bit-Mikrocontroller und halte sie auch nicht zwangsweise für veraltet, aber es liegt trotzdem auf der Hand, dass 32 Bit in vielen realistischen Fällen Vorteile haben.
greg schrieb: > Selbst in einfachen Steuerungen hantiert man öfter mal mit 16 Bit großen > Variablen, z.B. um Sensorwerte umzurechnen, und da hat man mit einer > 32-Bit-CPU handfeste Vorteile. Tu ich auch. Und kann ich auch. Aber ich muß zugeben daß einzelne Rechnungen in Asm mühsam werden können und ich dann (kurz) neidisch auf die C-Fraktion schaue. Aber schaun wir genauer auf die Applikation dann sind eben die, die aus einer 32 Bit CPU (z.B. bei umfangreichen Berechnungen) handfeste Vorteile ziehen sowieso solche größeren Ausmaßes, die ich nicht mehr unbedingt zu den "Millionen 8Bit Anwendungen" zählen würde. Wenn ich mich mal kurz in die Welt der C-Programmierer versetze kann ich das Argument für leistungsstärkere Controller bei Berechnungen ja gut verstehen. Aber dort schwenkt eben alles auf 64 Bit um sobald verfügbar, ist ja noch leistungsfähiger usw. So entsteht eine immer größere Lücke zwischen 8 und XY Bit, den beiden Polen der Zweckmäßigkeit für Anwendungen bestimmten Typs. greg schrieb: > Ich habe nichts gegen 8-Bit-Mikrocontroller und halte sie auch nicht > zwangsweise für veraltet, Danke.
Moby schrieb: > ... da ist ebenfalls das letzte Wort längst nicht gesprochen. > Komplexere Controllerstruktur sollte im Prinzip hier im Nachteil sein. Ist sie aber nicht. Moby schrieb: > Das ist AVR-Studio + ein Debugger genauso. Damit ist man aber auch Atmel beschränkt. Moby schrieb: > Alle diese "Tatsachen" beweisen mir: Nichts. Klar, wenn ich mit geschlossenen Augen durch die Welt laufe, beweisen mir Farben auch nichts. Falk Brunner schrieb: > Die Kombination von "harten Tatsachen" und der Zeitform Futur finde ich > gewagt ;-) Wenn du meinen Text ganz zitiert hättest, wäre dir vielleicht aufgefallen, dass erst die Tatsachen kommen und dann ein Schluss, den man aus diesen Tatsachen ziehen kann. Moby schrieb: > Aber schaun wir genauer auf die Applikation dann > sind eben die, die aus einer 32 Bit CPU (z.B. bei umfangreichen > Berechnungen) handfeste Vorteile ziehen sowieso solche größeren > Ausmaßes, die ich nicht mehr unbedingt zu den "Millionen 8Bit > Anwendungen" zählen würde. Wenn du diese Anwendungen nicht zu deinen 8-Bit-Anwendungen zählst, bleibt nicht viel übrig. Da bleiben nämlich nur noch Anwendungen übrig, die man besser mit ein paar Logikgattern oder analog besser erledigen kann. Moby schrieb: > Aber dort schwenkt eben alles auf 64 Bit um sobald verfügbar, Quark. C im Embeddedbereich läuft immer noch zum größten Teil auf 32 Bit.
Falk Brunner schrieb: > Die Kombination von "harten Tatsachen" und der Zeitform Futur finde ich > gewagt ;-) Das ist das Typische an Religionen.
Embedded schrieb: > Wenn du diese Anwendungen nicht zu deinen 8-Bit-Anwendungen zählst, > bleibt nicht viel übrig. Da bleiben nämlich nur noch Anwendungen übrig, > die man besser mit ein paar Logikgattern oder analog besser erledigen > kann. Ich weiß nicht wo Du arbeitest und zu welcher Betriebsblindheit das führt, aber da verschätzt Du Dich gewaltig. Embedded schrieb: > Quark. C im Embeddedbereich läuft immer noch zum größten Teil auf 32 > Bit. Immer noch.
Moby schrieb: > Ich weiß nicht wo Du arbeitest und zu welcher Betriebsblindheit das > führt, aber da verschätzt Du Dich gewaltig. Dann nenne mal eine konkrete und reale Serienanwendung, bei der ein 8-Bitter einem M0 überlegen ist.
Elektrische Zahnbürste, Ampelsteuerung, Zeitschalter... Schade, hab gerade keine Zeit noch Millionen andere aufzuzählen :( In erster Linie fallen mir da natürlich meine eigenen Anwendungen (Haussteuerung) ein. Jedes Bit mehr als 8 sind da Perlen vor die Säue.
Moby schrieb: > Elektrische Zahnbürste, Ampelsteuerung, Zeitschalter... Kann man alle genauso gut oder besser mit einem M0 erledigen. Moby schrieb: > In erster Linie fallen mir da natürlich meine eigenen Anwendungen > (Haussteuerung) ein. Kann man wunderbar mit einem M0 erledigen. Moby schrieb: > Jedes Bit mehr als 8 sind da Perlen vor die Säue. Da stimme ich dir wiederum zu 100% zu. Du kannst damit nämlich ganz offensichtlich nicht umgehen.
Embedded schrieb: > überlegen Ach so, von "Überlegenheit" hat auch keiner gesprochen. Die Rede war doch von Einfachheit", stimmts?
Moby schrieb: > Ach so, von "Überlegenheit" hat auch keiner gesprochen. Die Rede war > doch von Einfachheit", stimmts? Ich kann es nur noch einmal wiederholen: In der Industrie geht es um Wartbarkeit, Preis und Leistung. Ob ich für eine Einfachstanwendung einen oder zwei Tage brauche, spielt dabei keine Rolle.
Embedded schrieb: > Du kannst damit nämlich ganz > offensichtlich nicht umgehen Du hast auch nicht bewiesen daß ich das müsste... Simpler Bastler heißt übrigens einer der die gegebene Aufgabenstellung möglichst simpel umsetzt :-)
Moby schrieb: > Du hast auch nicht bewiesen daß ich das müsste... Du musst es auch nicht. Als Bastler kannst du machen, was du willst. Aber du solltest dich dann mit Behauptungen, was in der Industrie verwendet wird, mal etwas zurückhalten.
Embedded schrieb: > Ob ich für eine Einfachstanwendung > einen oder zwei Tage brauche, spielt dabei keine Rolle. Embedded schrieb: > aber dann hat man eben schon ein paar > unnötige Stunden verblasen. Und in der Industrie sind das gleich ein > paar Tausend Euro.
Leute, ich mach hier mal eine Art Friedensangebot: Orakeln wir doch lieber NICHT über das, was unserer Meinung nach SEIN MUSS, sondern reden lieber über das, was wir uns für die Zukunft wünschen. Ist ein dezenter Unterschied. Gelle? Also, ich hatte zwar schon vor Jahren in unseren billigsten Geräten von einem PIC16 auf einen Arm7TDMI gewechselt - und zwar aus KOSTENGRÜNDEN. Dennoch sehne ich mir NICHT eine Zeit her, wo alle Welt nur noch Cortexe verbaut und es sonst nix gibt. Auch wenn ich selber vermutlich nur noch wenige oder garkeine 8 bitter beruflich verbauen werde. Für den privaten Bastel- und Hobbybedarf mag es sich anders fügen. Kurzum, ich wünsche mir, daß in der µC Hardware eben KEINE Monokultur kommt. So. Und jetzt seid ihr dran (mit Wünsche formulieren). W.S.
Moby schrieb: > Embedded schrieb: >> Ob ich für eine Einfachstanwendung >> einen oder zwei Tage brauche, spielt dabei keine Rolle. > > Embedded schrieb: >> aber dann hat man eben schon ein paar >> unnötige Stunden verblasen. Und in der Industrie sind das gleich ein >> paar Tausend Euro. Ah, du hast es nicht begriffen, das habe ich mir fast gedacht. Nocheinmal, ganz langsam, zum Mitschreiben: Der Pflegeaufwand (und dazu gehört auch die Bauteilauswahl) ist in der Industrie deutlich höher als der Entwicklungsaufwand. Und noch einmal: Der Pflegeaufwand ist entscheidend, nicht der Entwicklungsaufwand. Kapiert?
W.S. schrieb: > So. Und jetzt seid ihr dran (mit Wünsche formulieren). Die PIC's sind OK Die Renesas sind OK Die C166er sind OK Alle Hersteller die einen MIPS oder ARM Core einsetzen sind OK 8051 ist OK Damit ist die Vielfalt ausgiebig gegeben.
Vorschläge: 1) Elektronik Mikrocontroller-Studie 2011 ansehen (fast alle ARM dran): http://www.elektroniknet.de/halbleiter/sonstiges/?_aid=85145&gid=2969&d=true&subPage=0&cp=3 2) Bei der Elektronik Mikrocontroller-Studie 2014 mitmachen und das Ergebnis abwarten (wahrscheinlich alle ARM dran): http://umfragen.weka-fachmedien.de/index.php?sid=33559&lang=de
Lothar schrieb: > 2) Bei der Elektronik Mikrocontroller-Studie 2014 mitmachen und das > Ergebnis abwarten (wahrscheinlich alle ARM dran): Ziemlich sinnlos so eine Studie, bei der man nicht nachvollziehen kann, ob da jetzt ein Bastler mit 5 Stück im Jahr teilnimmt oder ob man Mio Stück abnimmt. Falk Brunner schrieb: > Aber AVR ist diabolisch böse, nicht wahr? ;-) Es geht doch nicht um gut und böse. Die AVR-Architektur ist nicht schlecht, aber sie gehört so langsam zum alten Eisen.
AVR würde ich eher in die Kategorie wie 6502, Z80 oder 68HC11 stecken. Der 8051 ist zwar auch alt, aber der läuft wenigstens noch in FPGA's als freie Alternative zum Cortex-M1. Und der 8051 wird von vielen Firmen angeboten - kein Monopol.
:
Bearbeitet durch User
Das große Finale? ;) @Moby: Du schreibst oft und gerne von Komplexität und Aufwand für den Wechsel auf 32Bit. Kann man natürlich so sehen. Aber: Wie sieht es denn mit einem Wechsel von AVR auf z.B. den PIC18F aus? Ist ja auch 8Bit - mit teils toller Peripherie die man bei AVR nicht findet. Deiner Logik nach dürfte das kein Problem sein, oder?
Stefan schrieb: > Aber: Wie sieht es denn mit einem Wechsel von AVR auf z.B. den PIC18F > aus? Ist ja auch 8Bit - mit teils toller Peripherie die man bei AVR > nicht findet. Wenn man in einer Welt zuhause ist und diese die eigenen Bedürfnisse fast perfekt abdeckt (was ein großer Wert an sich ist) da ist doch ein Wechsel egal wohin nicht sinnvoll. Einer der springenden Punkte ist dabei der Lernaufwand bis man wirklich produktiv ist- an sich nichts schlimmes wenn er denn nicht wertvolle Zeit kosten würde. Die sollte man sich einteilen (für die eigenen Projekte) und nicht unnütz ohne Not zum Wechsel von Plattformen verschwenden. Zugegebenermaßen wäre man in C da flexibler, wenn es denn sein müsste. Ich bin aus der Pic Welt schon lange raus, welche tolle Peripherie lockt denn da?
Markus Müller schrieb: > AVR würde ich eher in die Kategorie wie > 6502, Z80 oder 68HC11 stecken. Um Himmels willen. Wofür ich beim Z80 noch eine Europlatine brauchte passt mit nem guten Mega auf ein Fünftel der Fläche, bei vielfach mehr Speed. Wie kann man das nur in eine Liga stecken? Aber das muß man wohl, damit ein STM32 in besonders hellem Schein leuchtet, was?
Moby schrieb: > Einer der springenden Punkte ist > dabei der Lernaufwand bis man wirklich produktiv ist Moby schrieb: > Zugegebenermaßen wäre man in C da > flexibler Das bringt den Bastlergeist auf den Punkt. Man ist froh, endlich auf einem ATiny seine Lösungen in ASM ans Laufen zu bringen. Nach Jahren kennt man die Peripherie und mit den Interrupts klappts auch irgendwie. Und jetzt kommt einer mit der riesigen Registerbreite daher. Da muss man sich ja fürchten. ;)
@Moby Ich hatte schon angst Du überliest mein Posting...
:
Bearbeitet durch User
Wie sagt die Atmel-Werbung: Bringing AVR Ease-of-Use to Cortex M0+ Microcontrollers http://www.atmel.com/microsite/samd20/ So kann man den Abschied von AVR natürlich auch darstellen :-)
@Markus Du provozierst eben gerne... Kein Problem, Dein STM32 hat auch eine Daseinsberechtigung! no fear schrieb: > Nach Jahren > kennt man die Peripherie und mit den Interrupts klappts auch irgendwie. Unterstellung. no fear schrieb: > Da muss man > sich ja fürchten. Unterstellung. Furcht ist ein schlechter Ratgeber, Vernunft ein guter :-)
Moby schrieb: > Simply AVR. They are SIMPLE to use and used EVERYWHERE... Fragt sich nur in welchem Produkt - bei 3% Marktanteil bei uC Die Webpage wurde wohl auch schon länger nicht mehr geupdated: tinyAVR->megaAVR->AVRXMEGA->AVRUC3 :-) AVRUC3 wurde ja schon beerdigt ...
Lothar schrieb: > AVRUC3 wurde ja schon beerdigt ... so ein schwachsinn, warum wird er dann noch für neue Designs wie z.b. das Microsoft Surface oder Samsung Galaxy verwendet?
andreas schrieb: > warum wird er dann noch für neue Designs wie z.b. > das Microsoft Surface Zitat Atmel: "I know everybody loves ARM chips and we make a whole bunch of ARM architecture chips, including the SAM D20, but UC3 is a pretty sweet little chip itself, as evidenced by Microsoft’s selection of it in this cost-sensitive consumer application." Atmel hat einfach NXP preislich unterboten (obwohl die UC3-Fertigung teurer ist): http://en.wikipedia.org/wiki/Apple_M7 andreas schrieb: > Samsung Galaxy verwendet Das Design ist schon älter vom SGII und wurde dann eben im SGIII und SG4 beibehalten.
>Bringing AVR Ease-of-Use to Cortex M0+ Microcontrollers
Lauter können die Glocken doch kaum noch läuten;)
Embedded schrieb: > Und deshalb werden sich die ARM-Kerne mittelfristig durchsetzen. nicht solange die Industrie versucht uns weißzumachen dass man 32bit schon für 32cent bekommt ^^ es wird nur versucht billigen ramsch unter die leute zu bringen, damit diese dann auf diesen ARM Zug aufspringen. als Bsp des schon öfters zitierten STM32F03 - power supply wurde von 2.0V auf 2.4Vmin erhöht - kein Osc wurde kalibriert/getestet Table 33. HSI oscillator characteristics "2. Guaranteed by design, not tested in production" - so geht es weiter für die interne RC - dasselbe bei Table 37. Flash memory characteristics "1. Guaranteed by design, not tested in production" - Weiterhin Table 41. ESD absolute maximum ratings "1. Data based on characterization results, not tested in production" - Table 44. I/O static characteristics (continued) "1. Data based on design simulation only. Not tested in production" und so geht es die ganze Zeit weiter selbst die 32cent sind zu teuer - Leute was ist aus den Ingenieuren heute geworden die auf so was reinfallen? Früher hatte man ein Datenblatt sehr detailliert gelesen, abgeschätzt was brauche ich denn für meine Aplikation. Heute nimmt man von Haus aus einen Cortex weil er billiger ist und schaut gar nicht mehr auf die Charakteristik. Mit solchen Aussagen wie oben distanziert sich der Hersteller von jeder Produkthaftung. Setze ich so einen Chip ein, und passiert irgendwas dann ist die Hölle los. Ich würde mir kein Produkt kaufen in dem so eine Value Line verbaut ist. Nimmt man die Value line raus, dann sieht es ganz anders aus mit den Cortexen, diese kosten dann vielfaches mehr. Das ist der ganze "wenn ich für 32Bit dasselbe zahle wie für 8Bit" Zauber.
ingolf schrieb: > Ich würde mir kein Produkt kaufen in dem so eine Value Line verbaut ist. Du hast keine USB-WiFi oder USB-Bluetooth Sticks :-) Da sind nämlich Value Line 8051 oder M0 drin. Aber Du meintest wahrscheinlich eine Industriemaschine. Hier kann ich Dir versichern, wir schauen die Datenblätter genau an, und geben wenn nötig auch mehr für einen uC aus. Und wenn Du eine Billig-Kaffeemaschine meinst, solltest Du Dir weniger Sorgen um den uC machen als um das Netzteil.
Bei "Weißer Wahre" kommt es auf den Cent an und wenn da kein getrimmter RC erforderlich ist, dann ist das doch OK. Genau so auch bei den anderen Punkten.
STMicroelectronics: Umsatz soll im laufenden Quartal sinken http://www.elektroniknet.de/halbleiter/sonstiges/artikel/105101/
Lothar schrieb: > Aber Du meintest wahrscheinlich eine Industriemaschine. Hier kann ich > Dir versichern, wir schauen die Datenblätter genau an, und geben wenn > nötig auch mehr für einen uC aus. Jepp, so isses. Bei uns bspw. geht der Preis des Controllers (wie der gesamten Elektronik überhaupt) meist im Rauschen unter. Das ist durchaus angenehm, weil man so qualitativ hochwertige Bauteile einsetzen kann. > Und wenn Du eine Billig-Kaffeemaschine meinst, solltest Du Dir weniger > Sorgen um den uC machen als um das Netzteil. Oder deren Entstörkondensatoren (siehe Senseo-Thread). Moby schrieb: > Die sollte man sich einteilen (für die eigenen Projekte) und nicht > unnütz ohne Not zum Wechsel von Plattformen verschwenden. Ja, das sehe ich auch so. Genau das war für uns der Grund, komplett auf Cortex (STM32) zu wechseln. Da habe ich einfach eine sehr große Bandbreite an Leistung zur Verfügung und muss mich nur mit einem Compiler/Debugger und Eigenarten einer Linie herumschlagen.
RuckiZucki schrieb: > STMicroelectronics: > Umsatz soll im laufenden Quartal sinken > > http://www.elektroniknet.de/halbleiter/sonstiges/artikel/105101/ Dafür ist deren Sparte "Microcontrollers, Memory & Security (MMS)" doch gut gestiegen, auch wenn unterm Strich weniger raus kommt. Zitat: "auf einen Umsatzrückgang mit alten ST-Ericsson-Produkten um mehr als die Hälfte" Daran sieht man schön wie schnell ein ganzer Bereich weg brechen kann wenn ein Produkt nicht mehr interessant ist. Da ST viele Standbeine hat wird ST das auch sicher verkraften. Wenn so etwas z.B. Atmel oder Nuvoton passieren würde wäre ich mir nicht sicher wie es denen ergehen würde. Die wären deutlich stärker mitgenommen. Eine breite Produktpalette bietet den Firmen Sicherheit, und das bieten ST sowie NXP und Microchip.
:
Bearbeitet durch User
> Das bringt den Bastlergeist auf den Punkt. Man ist froh, endlich auf > einem ATiny seine Lösungen in ASM ans Laufen zu bringen. Nach Jahren > kennt man die Peripherie und mit den Interrupts klappts auch irgendwie. > Und jetzt kommt einer mit der riesigen Registerbreite daher. Da muss man > sich ja fürchten. ;) Die Registerbandbreite ist ohne Bedeutung, denn die modernen µC programmiert niemand in Assembler.
> Wenn man in einer Welt zuhause ist und diese die eigenen Bedürfnisse > fast perfekt abdeckt Stillstand ist der Tot. Horizonte erweitern, 32bit nutzen! :P ;)
> So. Und jetzt seid ihr dran (mit Wünsche formulieren).
Ich möchte, dass jeder Hersteller exakt das gleiche Programmierinterface
benutzt (inklusive Protokoll), so dass ich mit einem Programmer alles
programmieren kann.
Ich möchte, dass ein µC mit einem MAC auch einen PHI hat.
ingolf schrieb: > nicht solange die Industrie versucht uns weißzumachen dass man 32bit > schon für 32cent bekommt ^^ es wird nur versucht billigen ramsch unter > die leute zu bringen, damit diese dann auf diesen ARM Zug aufspringen. Also ich bekomme diverse M0 Chips für den Preis. Wo ist das Problem? Ich verstehe sowieso nicht, wieso ich einen 8-Bit-Kern verwenden soll, wenn meine Timer 16-32 Bit haben und der ADC 12 Bit. Ich will einen Kern, der auch direkt den Daten rechnen kann, die er bekommt und nicht die Hälfte seiner Zeit mit Bitüberträgen herumhantiert. Und die Komplexität ist eine Frage der Peripherie. Atmel zeigt doch, dass man auch einfache AVR-like-Peripherie mit einem starken Kern verknüpfen kann, und dabei immer noch günstig ist. Komplexität ist auch subjektiv. Ich finde die STM32M0-Peripherie noch sehr einfach, übersichtlich und gut beschrieben. Ich kann aber auch verstehen, wenn Anfänger oder wenig Talentierte/Geübte damit Probleme bekommen und lieber beim AVR bleiben. Man kann aber davon ausgehen, dass Profis, die jeden Tag damit arbeiten, damit spielend klar kommen.
lolli schrieb: > Ich möchte, dass ein µC mit einem MAC auch einen PHI hat. Den gab es von TI ja mal in Form der Cortex M3 Serie von Luminary. Da war der Phy mit drin. Buchse mit Magnetics daran und das wars schon. Aber leider haben die TI Manager das in einem Fall von geistiger Umnachtung das Ende 2012 alles eingestellt und bis jetzt bei den M4/F4 Serien noch nicht wieder eingebaut.
Der KSZ8031 wirklich einfach zum Anschließen, es hat sich bei den PHYs auch was getan. Beim STM32 könnte man sogar den MCO2 Pin missbrauchen und dort 25MHz raus lassen (I2S PLL, wenn man kein I2S braucht). Somit spart man sich einen zweiten Quarz. Oder man nimmt einen externen Quarz mit 25MHz der per MCO1 denn den PHY Takt bildet.
Markus Müller schrieb: > Der KSZ8031 wirklich einfach zum Anschließen, es hat sich bei den PHYs > auch was getan. Aber warum muessen die Teile extern sein, TI hat doch gezeigt das es auch intern geht.
Ich vermute mal, dass hat was mit der Wärme zu tun. Die µC werden bei voller Leistung leicht warm, die PHYs noch viel mehr. Und die Temperaturen addieren sich so sehr, dass die dann nicht mehr für eine Umgebungstemperatur von 85°C tauglich sind. Wobei der KSZ8031 ist einer der Stromsparendsten.
@ Helmut Lenzen (helmi1) >Aber warum muessen die Teile extern sein, TI hat doch gezeigt das es >auch intern geht. Ein Phy ist ein Pegelwandler und ausserdem die Schnittstelle zur ESD-verseuchten Aussenwelt. Für sowas kann man einen kleinsten Halbleiterstrukturen gebrauchen, da müssen robustere Prozesse her. Weshalb die Integration eines PHY immer Probleme macht und auf Kompromisse rausläuft.
Markus Müller schrieb: > Ich vermute mal, dass hat was mit der Wärme zu tun. TI hat es aber schon mal geschafft, und so warm wurde das Teil nun auch nicht (kleinen Webserver damit gebaut).
Falk Brunner schrieb: > Ein Phy ist ein Pegelwandler und ausserdem die Schnittstelle zur > ESD-verseuchten Aussenwelt. Für sowas kann man einen kleinsten > Halbleiterstrukturen gebrauchen, da müssen robustere Prozesse her. > Weshalb die Integration eines PHY immer Probleme macht und auf > Kompromisse rausläuft. So sieht es aus. Am Ende war der Chip (falls es überhaupt ein Chip war und nicht ein Multi-Die-Package) wahrscheinlich einfach zu teuer.
Falk Brunner schrieb: > Für sowas kann man einen kleinsten > Halbleiterstrukturen gebrauchen, da müssen robustere Prozesse her. Ist klar Falk, aber die externen Ethernet Controller (DM9000,Wiznet,ENC624J600) haben den MAC und den PHY + RAM alles auf dem Chip. Und das sind auch nun keine groben Strukturen.
@ Helmut Lenzen (helmi1) >Ist klar Falk, aber die externen Ethernet Controller >(DM9000,Wiznet,ENC624J600) haben den MAC und den PHY + RAM alles auf dem >Chip. Und das sind auch nun keine groben Strukturen. Woher weißt du das? Kennst du den inneren Aufbau? Muti-Chip Package? Strukturgrößen?
Falk Brunner schrieb: > Kennst du den inneren Aufbau? Leider kein Röntgengerät in meinem Besitzt und kaputt machen will ich jetzt keinen :=)
lolli schrieb: > Ich möchte, dass ein µC mit einem MAC auch einen PHI hat. Ethernet - OnChip vs 2nd Chip http://www.microchip.com/forums/m470161-print.aspx
Helmut Lenzen schrieb: > Ist klar Falk, aber die externen Ethernet Controller > (DM9000,Wiznet,ENC624J600) haben den MAC und den PHY + RAM alles auf dem > Chip. Und das sind auch nun keine groben Strukturen. Eine MAC sind nur ein paar hundert Gatter (siehe FPGA-Mac-IP). Das kriegt man auch locker auf größere Strukturen. Allein der RAM eines modernen Prozessors dürfte ein vielfaches an Chipfläche bei gleicher Strukturbreite kosten.
Ein typisches Beispiel für die glitzernde, ach so einfache Welt von STM32 (und zugehöriger C-Programmierung): Beitrag "STM32 und Keil MDK-ARM Einsteiger Frage" Herrlich, kann man nicht besser beschreiben. Mir würde auch übel werden wenn ich mir so einen Krampf den ganzen Tag antun müsste. Um wieviel kürzer und unkomplizierter tut man sich da mit einem AVR und ASM- aber psssst, nicht weitersagen :)
Moby schrieb: > Ein typisches Beispiel für die glitzernde, ach so einfache Welt Beitrag "AVRISP MKII bricht beim Brennen ab." Beitrag "Atmel AVR USB Bootloader per Software starten - funktioniert nicht" Beitrag "Studio 4.19 - Insstallation - keine Devices angeboten - (2.Anlauf)" ... ... ... und das halbe Forum handelt von Fuse Bits der veralterten AVR Technologie. ;-))) Hast du so ein Auto wie Fred Feuerstein?
Es ist und bleibt lustig anzuschaun, wie hier unnötige Komplexität nicht zur Kenntnis genommen, verharmlost oder gar abgestritten wird- obwohl sie doch nun wirklich auf der Hand liegt. Über das Verfusen kann man doch nur lachen... Also wenn das das größte AVR-Problem sein soll !? Und ja, das Auto von Fred Feuerstein war robust und fährt und fährt und fährt... Einfach. Verlässlich. Den Zweck erfüllend. Aber das sind Fremdworte für Leute, denen Leistung, Bitbreite und konfigurierbare Features das Höchste bedeuten.
Moby schrieb: > Busbreite :-) Warum? Wie breit irgendein Bus ist, hat nichts damit zu tun, mit welcher Datenbreite eine CPU arbeitet. Bitbreite passt schon besser.
greg schrieb: > Datenbreite passt glaub ich am besten. Ein Bit kann ja durchaus unterschiedlich "breit" sein- in zeitlicher Betrachtung.
Helmut Lenzen schrieb: > Markus Müller schrieb: >> Ich vermute mal, dass hat was mit der Wärme zu tun. > > TI hat es aber schon mal geschafft, und so warm wurde das Teil nun auch > nicht (kleinen Webserver damit gebaut). Wir haben in der Firma einen Chip im Einsatz mit Phy auf dem Chip (Hilscher netX). Wir könnten die Leute von Hilscher dafür erschlagen. Bei eingeschalteten Phys wird der Chip so heiß, dass das Kommunikationsinterface, das wir damit gebaut haben, bei einer Umgebungstemperatur von 40°C ausfällt. Wir haben ein weiteres Interface, bei dem ein ähnlicher Prozessor zum Einsatz kommt, nur sitzen da die Phys extern - keine Probleme. Wenn Du die Phys auf physikalisch kleinen ICs integrierst, wirst Du die Wärme nicht los! Industrieller Temperaturbereich oder gar Automotive geht nicht mit integrierten Phys.
Heiner schrieb im Beitrag #3511283:
> es gibt noch 8 Bit Controller.
Alles nur Restposten die sonst keiner haben will 8-)
Klar werden immer noch superschnelle 8051 herausgebracht. Vor allem im Automotive Bereich ist es billiger einen bestehenden 8051 aufzubohren anstatt einen ARM zu zertifizieren. Es sind sogar 8051 im nächsten 14nm Prozess von Intel geplant. Moby schrieb: > Über das Verfusen kann man doch nur lachen... Also wenn das das größte > AVR-Problem sein soll !? Für Einsteiger scheint es ein Problem zu sein. Und warum macht Atmel nicht einfach ein kleines Bootloader-ROM in den AVR, dann gäbe es das Problem nicht. Bei den 8051 LPC war es Standard, und wurde in die ARM LPC übernommen. Wir haben hier noch nie einen LPC gebrickt.
Lothar schrieb: > Es sind sogar 8051 im nächsten 14nm > Prozess von Intel geplant. Na warum soll das nicht auch mit anderen 8-Bittern möglich sein? Heiner schrieb im Beitrag #3511283: > es gibt noch 8 Bit Controller Das Ende der 8 Bitter erlebt hier keiner mehr. Bei Reichelt gibts sogar noch Z80; wie ist das bloß möglich ??? W.S. schrieb: > reden lieber über das, was wir uns für die Zukunft > wünschen Ok, um nicht immer nur auf dem Komplizierter, Komplexer, Umständlicher der heutigen 32 Bitter (IN IHREM EIN/ERSATZ FÜR TYPISCHE 8-BIT APPS) herumzureiten hier mal ein paar Wünsche, deren Erfüllung mich für eine neue Plattform begeistern könnten! Im Interesse einfachstmöglichen Einsatzes mit niedrigen Einstiegshürden, weniger Softwarekomplexität -> weniger Entwicklungs/Pflegeaufwand gehts dabei vor allem um die Begrenzung der Flexibilität! Niemand braucht z.B. ein UART mit hundert Betriebsarten. Beschränkung auf das meist benötigte, lautet die Zauberformel. Vereinheitlichen, vereinfachen wo es nur geht! Und statt grassierender Registerkonfiguritis ein wenig mehr Intelligenz in die Controller! Konkret sollte per default folgendes möglich sein: A-wie ADC: Samplen kann der Controller selbstständig. Jeden verfügbaren Pin in einen einen entsprechenden IO-Bereich. Mit sinnvollem Speed und am besten 16-bittig. B-wie Berechnungen: Bitteschön alles (auch) in ASCII inkl. Komma einer Recheneinheit vorsetzen können und in Hardware berechnen lassen, von der Summe bis zur Wurzel! D-wie DAC: Initial 0 in dem Pin zugeordneter I/O-Location gibt nichts, jeder andere Wert eine entsprechende Spannung aus. I-wie Interrupts können jedem Pin mit jeder Funktion zugeordnet werden, Verwaltung/Registerrettung sind dabei nicht mehr das Problem des Programmierers. Funktionen z.B. Test auf Analogwert, Test auf Change... M-wie Memory ist linear mit gleichfunktionellem Registersatz, I/O und viel nichtflüchtigem Speicher für Programme und Daten. P-wie Pin: Einheitliche Ansprache über Controllertypen und Hochsprachen hinweg von 1 bis x. U-wie UART: Einen Pointer auf einen Datenbereich, ggf. die Anzahl, eine Baudrate im Klartext, ein Flag fürs Übertragungsende und ab geht die Post! 8N1 ist eh Standard. Wie das Ganze dann unabhängig vom Programmablauf vonstatten geht: nicht mein Problem! Andere Schnittstellen können in ähnlich bequemer Weise abgehandelt werden. Wie diese Funktionen über weitere Parameter konfigurierbar gemacht werden darüber kann man sich ja streiten. Also bis das Ganze ein paar Schritte in diese Richtung gegangen ist und die Chipentwickler nicht immer nur mit dem Motto "viele Bits+MHz" Fortschritt definieren bleiben die PICs und AVRs dieser Welt TOP-aktuell. Denn wie schon Embedded schrieb: > Die AVR-Architektur ist nicht > schlecht
A - gibt es schon beim STM32 für sehr viele IO-Pins (ca. 24, Typabhängig, 12/16 Bit) B - Kann jeder programmieren - Wen Du einen Taschenrechner bauen willst. D - hat der STM32 bis zu 3 Stück drin I - kann der STM32 M - Ist Standard bei ARM/Cortex P - Schreibe Dir eine Lib für jede CPU (Die ST Lib macht das für alle STM32) U - Schreibe Dir eine Lib (wie ich mir auch gemacht habe)
Lothar schrieb: > Moby schrieb: >> Über das Verfusen kann man doch nur lachen... Also wenn das das größte >> AVR-Problem sein soll !? > > Für Einsteiger scheint es ein Problem zu sein. Hat sich ja nun sowieso mit dem XMega erledigt. Lothar schrieb: > Und warum macht Atmel > nicht einfach ein kleines Bootloader-ROM in den AVR Das wär mein nächster heißer Tipp für neue AVRs!
Markus Müller schrieb: > A - gibt es schon beim STM32 für sehr viele IO-Pins (ca. 24, > Typabhängig, 12/16 Bit) > B - Kann jeder programmieren - Wen Du einen Taschenrechner bauen willst. > D - hat der STM32 bis zu 3 Stück drin > I - kann der STM32 > M - Ist Standard bei ARM/Cortex > P - Schreibe Dir eine Lib für jede CPU (Die ST Lib macht das für alle > STM32) > U - Schreibe Dir eine Lib (wie ich mir auch gemacht habe) Du hast nix, aber auch gar nix verstanden.
Doch schon. Nur hast Du nix verstanden was über Deinem Tellerrand drüber hinaus bereits existiert.
Wollt ihr beiden nicht mal in den Ring gehen? Ich mach euch auch den Ringrichter.
Moby schrieb: > B-wie Berechnungen: Bitteschön alles (auch) in ASCII inkl. Komma einer > Recheneinheit vorsetzen können und in Hardware berechnen lassen, von der > Summe bis zur Wurzel! Und gibst es doch, die neuen Cortex haben doch eine Fliesskommaeinheit auf dem Chip drauf.
Helmut Lenzen schrieb: > Und gibst es doch, die neuen Cortex haben doch eine Fliesskommaeinheit > auf dem Chip drauf. Das ist aber kein "ASCII" (bzw. BCD?). Wobei ich es für eine relativ bescheuerte Idee halte, in BCD zu rechnen.
Helmut Lenzen schrieb: > Moby schrieb: >> B-wie Berechnungen: Bitteschön alles (auch) in ASCII inkl. Komma einer >> Recheneinheit vorsetzen können und in Hardware berechnen lassen, von der >> Summe bis zur Wurzel! > > Und gibst es doch, die neuen Cortex haben doch eine Fliesskommaeinheit > auf dem Chip drauf. Stimmt, hab gerade noch ne Mail von ST mit diesem Inhalt bekommen. STM32F427 and F429: more performance, memory resources and features The STM32F427 and STM32F429 MCUs, with the CPU frequency increased to 180 MHz, offer DSP and FPU capabilities and achieve a score of 608 CoreMark while executing from Flash. They feature up to 2 Mbytes of dual-bank Flash and 256 Kbytes of SRAM, an SDRAM interface and a software IP protection mechanism. The Chrom ART™, a DMA based graphical accelerator, speeds graphics operations up to two times. The STM32F429 integrates a TFT-LCD controller for resolutions up to SVGA. Coming with a rich feature set, they still ensure power efficiency with 100 µA stop mode consumption.
:
Bearbeitet durch User
Ich muss ja zugeben, interessant sind die schon ...
Ja, die schlug bei mir auch auf - das ist für uns richtig interessant - gerade in Bezug auf die Grafikmöglichkeiten :-) Schöne neue Welt :-)
... du liebe Güte! Hier überzeugt doch keiner Keinen einen anderen Prozessor zu nehmen! Je nach Anforderung und Weltsicht entscheidet man sich - völlig frei je nach Projekt, Aufgabe und Anforderung - bleibt in einer Familie - nimmt immer die gleichen zwei, drei Typen Offenbar verkaufen sich doch alle prima (sogar so ne Exoten wie der Propeller), sonst wären sie sogar schon weg vom Fenster. Also gaaaanz ruhig bleiben!
greg schrieb: > Das ist aber kein "ASCII" (bzw. BCD?). Wobei ich es für eine relativ > bescheuerte Idee halte, in BCD zu rechnen. ASCII braucht so aber auch keiner. Der Standard bei Fliesskomma ist seit ueber 30 Jahren das IEEE 754 Format. Niemand braucht in Hardware eine Umsetzung auf ASCII. ASCII ist nur fuer Menschen gemacht damit sie es lesen koennen, die Maschine braucht sowas nicht. Fuer eine Maschine ist ASCII ein Platzverschwenderisches Format. Jeder 8 Bit Prozessor kann IEEE -> ASCII schneller Umwandeln als jeder Mensch das lesen koennte. Auch sind die ASCII Formate alle unterschiedlich. Mal mit '.' mal mit ',' mal mit Vorzeichen mal ohne, mal mit fuehrenden Nullen mal ohne.
Moby schrieb: >> Es sind sogar 8051 im nächsten 14nm Prozess von Intel geplant. > > Na warum soll das nicht auch mit anderen 8-Bittern möglich sein? Bestimmt nicht, da würden sich Atmel und PIC ihr 32-bit Wasser abgraben, mit dem sie ihren Gewinn machen. Moby schrieb: >> Und warum macht Atmel nicht einfach ein kleines Bootloader-ROM in den AVR > > Das wär mein nächster heißer Tipp für neue AVRs! Atmel verweigert das ja nur schon seit Jahren. Embedded schrieb: > Es geht doch nicht um gut und böse. Die AVR-Architektur ist nicht > schlecht, aber sie gehört so langsam zum alten Eisen. Die "AVR-Architektur" ist ein aufgebohrtes Studentenprojekt, wo durch Tricks diverse 16-bit Fähigkeiten in 8-bit realisiert wurden. ARM wurde lange vor AVR entwickelt und ist konsequent und elegant 32-bit (im Gegensatz übrigens zum damaligen 16/32-bit Murks 80286 und 68000) Zur Kompetenz der AVR-Entwickler (Alf-Egil Bogen) :-) http://alfbogen.com/2013/06/16/risc-versus-cisc/
Moby schrieb: > Ein typisches Beispiel für die glitzernde, ach so einfache Welt von > STM32 (und zugehöriger C-Programmierung): > Beitrag "STM32 und Keil MDK-ARM Einsteiger Frage" Immerhin kann man das Problem schnell eingrenzen. Und man muss nicht die Libs verwenden. Auf Registerebene geht es schneller. Und AVR-Assembler lernen dauert definitiv länger. Moby schrieb: > Im Interesse einfachstmöglichen > Einsatzes mit niedrigen Einstiegshürden, weniger Softwarekomplexität -> > weniger Entwicklungs/Pflegeaufwand gehts dabei vor allem um die > Begrenzung der Flexibilität! Einstiegshürden spielen für professionellen Einsatz keine Rolle. Da hat man eh den Support eines FAE, in der täglichen Arbeit ist es völlige Wumpe ob man 5 oder 10 Tage für die Einarbeitung braucht. Was danach raus kommt ist wichtiger. Der Pflegeaufwand lässt sich durch Standardisierung senken, also gleiche Softwaremodule in vielen Anwendungen. Das geht über die STM32F-Serie ganz gut. Beim STM32 gibt es einige Konzepte, die die Komplexität wesentlich verringern: - Es gibt bei den seriellen Schnittstellen keinen FIFO, beim ADC gibt es genau ein Ergebnis-Register. Man macht alles per DMA. Beim (alten) AVR muss man alles mit Interrupts machen (= komplexer, mehr Softwareaufwand, höherer Energieverbrauch, schnellere Datenraten bei SPI quasi unmöglich). Durch den großen RAM kann ich auch riesige Datenmengen bequem zwischenspeichern (z.B. ein DDS mit 1024 Eckpunkten ohne einen einzigen CPU-Eingriff in ca. 15 Codezeilen). - Der Prescaler bei den Timern macht vieles einfacher, Timererweiterung per Software wird oftmals überflüssig (= weniger Komplexität, weniger Softwareaufwand, weniger Energieverbrauch, mehr Rechenleistung). - FPU bei den größeren STM32 senkt die Softwarekomplexität bei Berechnungen. Und das bei einem Controller für < 3 Euro! (STM32F3) - Sehr schöne und einfach zu bedienende PWM-Einheiten mit üpigen Compareeinheiten. ADC-Trigger auf Compare sind sehr gut umsetzbar. Zugegeben, die neueren XMEGA mögen besser sein als die alten AVR, mit denen ich die STM32 vergleiche. Die XMEGA habe ich aber gleich übersprungen. Ich kann einfach keinen Mehrwert gegenüber dem STM32 erkennen, zumal sie teilweise sehr viel teurer sind, bei schlechterer Performance. Ich bin auf schnelle Schnittstellen und ein wenig Rechenperformance angewiesen und kann heute mit einem < 50 ct uC das machen, wofür ich vor zwei Jahren noch 2 Euro ausgeben musste. Übrigens: Es gibt Leute, die mit einem uC mehr als nur eine LED bedienen! Und davon nicht zu wenig.
Antimedial schrieb: > Übrigens: Es gibt Leute, die mit einem uC mehr als nur eine LED > bedienen! Geht der Trend zur ZweitLED? :=)
Helmut Lenzen schrieb: > Geht der Trend zur ZweitLED? :=) Ich habe allein schon zwei LED zur Statusanzeige drauf :)
Antimedial schrieb: > Ich habe allein schon zwei LED zur Statusanzeige drauf :) Ich nehme dazu immer ein EA-DOG SPI Display, braucht ja nur 4 Pins vom µC. Das Display zeigt nur die Debug-Ausgaben.
:
Bearbeitet durch User
Wenn ihr statt hier rumzutrollen gemeinsam an einem vernünftigen STM-Artikel schreiben würdet, wäre dieser dieses Jahr noch fertig.
Antimedial schrieb: > - Es gibt bei den seriellen Schnittstellen keinen FIFO, beim ADC gibt es > genau ein Ergebnis-Register. Man macht alles per DMA. Was hat ein FIFO mit DMA zu tun? Die LPCxxxx haben beides. Das hat den Vorteil daß man bei kleinen Blöcken (ja, das gibt es) nicht unbedingt den DMA Controller bemühen muß. Low-latency I2S z.B. geht super mit FIFO.
Der STM32 hat zusätzlich 4 "Injected Chanels", habe ich noch nie benutzt. Damit kann man 4 Kanäle direkt zuordnen, wenn ich die Doku richtig verstanden habe.
Offensichtlich meinen hier viele, daß man mit einem 128kHz betriebenen AVR höchstens noch ne LED schalten kann. Unglaublich.
Lothar schrieb: > Moby schrieb: >>> Es sind sogar 8051 im nächsten 14nm Prozess von Intel geplant. >> >> Na warum soll das nicht auch mit anderen 8-Bittern möglich sein? > > Bestimmt nicht, da würden sich Atmel und PIC ihr 32-bit Wasser abgraben, > mit dem sie ihren Gewinn machen. Genau. 8-Bitter würden dann den 32ern das Wasser abgraben ;)
Mal ne Frage an die Hardcore-Spezialisten. Ich habe mir mal die Umgebung der STM32 angeschaut und einige Header bzw. C-Files gefunden, die man doch gerne aus Gründen der Standardisierung direkt einkomplieren könnte. Hat sich da jemand schon mal genau das Copyright durchgelesen und verstanden?
noreply schrieb: > Ich habe mir mal die Umgebung der STM32 angeschaut und einige Header > bzw. C-Files gefunden, die man doch gerne aus Gründen der > Standardisierung direkt einkomplieren könnte. Hat sich da jemand schon > mal genau das Copyright durchgelesen und verstanden? Was meinst du mit direkt einkompilieren? Hab mir mal die Lizenz der StdPeriph angeschaut [1]. Ich glaubte bisher, das sei eine standardmäßige permissive Lizenz. Sieht auf den ersten Blick auch so aus. Aber weit gefehlt: sie ist durch weitreichende Einschränkungen und Klauseln sehr problematisch. Die größten die Praxis betreffenden Einschränkungen sind folgende: * Man darf die Software nur für ST-Mikrocontroller nutzen. * Man darf die Software nicht direkt für kommerzielle Zwecke, egal welcher Art, nutzen. * Bei Verletzung der Lizenzbedingungen kann ST die Lizenz jederzeit zurückziehen. Das ist definitiv kein Open Source mehr! [1] http://www.st.com/st-web-ui/static/active/en/resource/legal/legal_agreement/license_agreement/software_license_agreement_liberty_v2.pdf
> Hab mir mal die Lizenz der StdPeriph angeschaut > * Man darf die Software nicht direkt für kommerzielle Zwecke, > egal welcher Art, nutzen. # Unless otherwise explicitly stated in this Agreement, You may not # sell, assign, sublicense, lease, rent or otherwise distribute # the Licensed Software for commercial purposes, in whole or in part. sieht so aus, aber, im Abschnitt davor: # STMicroelectronics ("ST") grants You a [...] limited license of # the Licensed Software to: # [...] # (iv) make, have made, use, sell, offer to sell, import and export # or otherwise distribute Products also through multiple tiers. Daraus würde ich schließen, dass man die Lib durchaus für alle Entwicklungen benutzen darf, nur darf man die Lib selbst nicht verkaufen, aber wer will das schon? Schwierig wird's natürlich zusammen mit der GPL. Einerseits darf ich die Lib nicht weitergeben, andererseits kann sie sich ja jeder selbst von st.com holen. Also, ohne Anwalt sag' ich nichts. Irgendwie ist das lächerlich, schließlich spart diese Lib nur Schreibarbeit, ich kann ja alles aus dem Datenblatt abtippen.
gnd3 schrieb: > Daraus würde ich schließen, dass man die Lib durchaus für alle > Entwicklungen benutzen darf, nur darf man die Lib selbst nicht > verkaufen, aber wer will das schon? Man darf aber auch keine Derivate der Software verkaufen. Also wenn man die Library in einer eigenen Software verwendet, darf die nicht verkauft werden. Das schließe ich jedenfalls aus dem Text. Die Lizenz widerspricht sich also ein bisschen selbst. Ein "Produkt" das die StdPeriph-Software nutzt, darf man verkaufen. So ein Produkt schließt aber ein Derivat der StdPeriph-Software ein (das erwähnt die Lizenz ausdrücklich). Derivate der StdPeriph-Software darf man aber nicht verkaufen. Das wird zwar ein bisschen entkräftet ("Unless otherwise explicitly stated"), aber juristisch bewerten kann ich das keinesfalls. :) > Irgendwie ist das lächerlich, schließlich spart diese Lib nur > Schreibarbeit, ich kann ja alles aus dem Datenblatt abtippen. In der Tat, ganz schön lächerlich von ST so eine merkwürdige restriktive Lizenz zu verwenden. Verursacht nur Kopfschmerzen bei Entwicklern und hilft ansonsten Niemandem.
greg schrieb: > gnd3 schrieb: >> Daraus würde ich schließen, dass man die Lib durchaus für alle >> Entwicklungen benutzen darf, nur darf man die Lib selbst nicht >> verkaufen, aber wer will das schon? > > Man darf aber auch keine Derivate der Software verkaufen. Also wenn man > die Library in einer eigenen Software verwendet, darf die nicht verkauft > werden. Das schließe ich jedenfalls aus dem Text. Warum? Punkt (iv) ist doch eindeutig. Selbstverständlich darfst Du die Bibliothek in Deine Produkte einbinden und diese verkaufen. Und Du darfst die Bibliothek auch verändern (Punkt (i) und (ii)) > In der Tat, ganz schön lächerlich von ST so eine merkwürdige restriktive > Lizenz zu verwenden. Verursacht nur Kopfschmerzen bei Entwicklern und > hilft ansonsten Niemandem. (i) und (ii) sollen nur verhindern, dass die reine Bibliothek bzw. deren Compilat geändert und verteilt wird. Ich denke, damit will ST Wildwuchs verhindern. Zusammen mit einem Produkt bist Du aber fast komplett frei (bis auf den Lizenzhinweis). GPL geht damit aber in der Tat nicht.
Antimedial schrieb: > Beim STM32 gibt es einige Konzepte, die die Komplexität wesentlich > verringern: Bravo. Feature 922,923,924 machen die vorangegangenen wieder ein Stück weniger komplex. Und wenn erst mal Feature 925 draußen ist, ja dann erst... Da beschleicht einem das Gefühl, es wird immer einfacher! Nix für ungut, wer die Leistung braucht der kann sich ja da einarbeiten. Wer in die vielen Features verliebt ist auch. Alle anderen nehmen 8 Bit. Lothar schrieb: > Und warum macht Atmel > nicht einfach ein kleines Bootloader-ROM in den AVR Da wär noch zu ergänzen das ein entsprechender Speicherbereich ja dafür ab Mega aufwärts vorhanden ist. Vielleicht denkt sich Atmel auch man ist so flexibler, dabei würde auch hier was fixes die Sache vereinfachen.
Marek Walther schrieb: > Wenn ihr statt hier rumzutrollen gemeinsam an einem vernünftigen > STM-Artikel schreiben würdet, wäre dieser dieses Jahr noch fertig. LPC-Artikel ist in Arbeit: - Einstieg ohne alles (Steckbrett, DIP, direkte Register-Zugriffe) - kostenfreie Entwicklungsumgebungen (Eclipse, Keil/IAR mit 32K Limit - mehr haben die kleinen LPC aber ohnehin nicht) - Flashen ohne Programmer/Debugger (Bootloader) - I/O, IRQ, Timer/PWM, Komparator/ADC/DAC, USART, USB - Hersteller-Libraries nutzen (Lizenzbedingungen) - Hersteller-unabhängige Libraries nutzen (CMSIS) - Code-Size Optimierung (für LPC mit <4K Flash) - Projekte (Code für LCDs, TFTs, Touch, Audio, USB-HID) - Vorstellung günstiger Debugger (Bereich 15-50 EUR) - Assembler für Spezialanwendungen (User/Superviser, geschützte Libraries/Kernel, Memory Protection, Multitasking) Und natürlich alles viel einfacher als im AVR-Artikel :-)
Wenn jetzt noch Admin Andreas das kleine Mikrocontroller.net Icon, ich meine den kleinen schwarzen IC, anstatt AVR dort ein ARM rein schreibt, dann hätte er seine Page auch dem aktuellen Lauf der Dinge angepasst ;-)
Markus Müller schrieb: > anstatt AVR dort ein ARM rein schreibt Also so weit müssen wir nicht gehen - ausserdem steht AVR ja auch für Automatic voltage regulator - oder siehe hier :-) http://www.kernfragen.de/kernfragen/lexikon/a/avr.php
Also @ Markus Müller, was muß ich da wieder für Horrorgeschichten lesen: Ersan G. schrieb: > Meiner Meinung nach > hats da ST sowieso übertrieben. > Man muss eine Seite coden damit mal ein Pin aktiviert wird. Schau mal, in AVR-Asm geht das so: sbi DDRA,1 ;schaltet PortA, Pin 1 auf Ausgang sbi PORTA,1 ;setzt den Pin auf High Ganz ohne die Zauberei mit Zusatzlayern & Zusatzlibs ;)
Lothar schrieb: > Und natürlich alles viel einfacher als im AVR-Artikel Wenn Dir das gelingt... Nobelpreis verdächtig! Vergiß aber nicht zu erwähnen was der LPC alles nicht hat!
Könnt Ihr dann langsam wieder aufhören .. bitte? Ich mache sowieso was ich will, ich habe mir gerade einen Z80 EMUF aufgebrezelt um damit zu spielen.. evtl. mache ich heute auch mal die PDP11 an. Auf VAX habe ich keine Lust heute. Atmega16 hatte ich erst heute Vormittag und MSP430 vorgestern. Ein STM32F407 Board mit Phy von Propox zum spielen liegt oben auf dem TEK, nach der Lektüre hier keinem Bock drauf. Gruß, Holm
Moby schrieb: > Schau mal, in AVR-Asm geht das so: > > sbi DDRA,1 ;schaltet PortA, Pin 1 auf Ausgang > sbi PORTA,1 ;setzt den Pin auf High > > Ganz ohne die Zauberei mit Zusatzlayern & Zusatzlibs ;) Und beim STM32 geht das so
1 | RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; // Clock für Port A aktivieren |
2 | GPIOA->MODER |= 0x00000001; // Pin 1 als Ausgang deklarieren |
3 | GPIOA->BSRRL = 0x0001; // setzt den Pin auf High |
Ebenfalls ganz ohne Zauberei, keine Zusatzlayer und keine Libs.
Moby schrieb: > Schau mal, in AVR-Asm geht das so: > > sbi DDRA,1 ;schaltet PortA, Pin 1 auf Ausgang > sbi PORTA,1 ;setzt den Pin auf High > > Ganz ohne die Zauberei mit Zusatzlayern & Zusatzlibs ;) DDRA und PORTA müssen auch erst mal definiert werden. Speicherzugriff ohne Registerbeteiligung ist kein RISC (AVR ist eben keine sauber designte Architektur). Aber bitte: 8051/CISC: SETB P0.0 ; P0.0 Ausgang + High LPC/RISC: MOV R0,#1 STR R0,[SET0] ; P0.0 Ausgang + High Auch hier müssen natürlich P0.0 bzw. SET0 definiert werden (Manual erforderlich).
Stefan schrieb: > Was hat ein FIFO mit DMA zu tun? Die LPCxxxx haben beides. Das hat den > Vorteil daß man bei kleinen Blöcken (ja, das gibt es) nicht unbedingt > den DMA Controller bemühen muß. Low-latency I2S z.B. geht super mit > FIFO. Die haben erst einmal nicht viel miteinander zu tun. Aber beim STM32 hat man offensichtlich bewusst auf FIFO verzichtet, um die Komplexität zu senken. Die DMA ist beim STM32 jedenfalls schneller konfiguriert als ein FIFO bei manch anderen Controllern (z.B. TI Piccolo - ein Horror). Moby schrieb: > Offensichtlich meinen hier viele, daß man mit einem 128kHz > betriebenen > AVR höchstens noch ne LED schalten kann. Unglaublich. Eine SPI mit einer Netto-Datenrate von 1 MBit geht nicht einmal mit 16 MHz, wegen fehlender Puffer. Allein deshalb fliegt der AVR schon aus der Auswahl raus. Wieso soll ich da nicht gleich auf einen besseren und günstigeren uC umsteigen? Nur weil andere nicht mit der Peripherie klar kommen?
> Und ja, das Auto von Fred Feuerstein war robust und fährt und fährt und > fährt... Einfach. Verlässlich. Den Zweck erfüllend. Aber das sind > Fremdworte für Leute, denen Leistung, Bitbreite und konfigurierbare > Features das Höchste bedeuten. Eine weitere Bestätigung, dass Moby Dick mit seinem Bastelclub in der Vergangenheit gefangen ist. Und warum? Na, er hat Angst, dass die Newbees ihn abhängen. Mit viel Mühe hat er sich dem ATiny genähert. Das soll jetzt alles die Katz sein? Die Erde dreht sich weiter, Moby, du hälst sie nicht auf. :-P
Walfänger schrieb: > Die Erde dreht sich weiter, Moby, du hälst sie nicht auf. :-P Na wenn dieser Eindruck entstanden ist- falsch gedacht. Nur bitteschön dann auch in die richtige Richtung: einfacher und effizienter, nicht komplizierter und umständlicher; @Antimedial: Wenn entsprechend Leistung gefragt ist wird niemand einen 8Bitter empfehlen... Dann bleibt heute leider nur der Griff zu ARM & Co, obwohl die ansonsten auch nur mit Wasser kochen. @Markus Müller wenn Du schon das Visual im Namen trägst, dann mach mal ein visuelles Tool um den Konfigurationswahnsinn des STM32 zu bändigen. Würde tausendmal mehr helfen als Dein zweifelhafter Versuch, mit einem Artikel hier diesen Boliden dem Einsteiger für seine Projekte schmackhaft zu machen!
Moby schrieb: > ein visuelles Tool um den Konfigurationswahnsinn des STM32 zu bändigen Switch Matrix Tool for LPC (hier LPC800). Für STM soll es auch etwas geben.
Moby schrieb: > @Markus Müller > wenn Du schon das Visual im Namen trägst, dann mach mal ein visuelles > Tool um den Konfigurationswahnsinn des STM32 zu bändigen. Würde > tausendmal mehr helfen als Dein zweifelhafter Versuch, mit einem Artikel > hier diesen Boliden dem Einsteiger für seine Projekte schmackhaft zu > machen! Am Setzen eines Portpins hat er Dir ja gezeigt, dass sich da AVR und STM32 in der Komplexität nicht unterscheiden. Nicht enttäuscht sein ;-) Oder anders ausgedrückt: ein Anfänger kommt auch mit einem STM32 prima zurecht, wenn man ihm ein passendes Tutorial dafür schreibt.
Chris D. schrieb: > Am Setzen eines Portpins hat er Dir ja gezeigt, dass sich da AVR und > STM32 in der Komplexität nicht unterscheiden. Nicht enttäuscht sein ;-) Lothar schrieb: > DDRA und PORTA müssen auch erst mal definiert werden. Nur macht das AVR Studio spätestens ab V6 selbstständig. Controllertyp im Projekt einstellen, fertig. Keinerlei Includes nötig.
Moby schrieb: > Nur macht das AVR Studio spätestens ab V6 selbstständig. > Controllertyp im Projekt einstellen, fertig. Keinerlei Includes nötig. Dann ist das wieder nicht sauber gelöst. Definitionen gehören in ein Include und nicht in Preprocessor- oder Make-Files. Klar wenn man nur AVR Studio nutzt mag das noch angehen, aber für verschiedene IDEs sollte schon Portierbarkeit gewahrt werden. Aber mal die Frage an den Experten: ich habe hier ein AVR Studio 4 Projekt zum Portieren auf LPC, und dort gibt es: #include <avr/io.h> Das gibt es dann in AVR Studio 6 nicht mehr??
Moby schrieb: > Nur bitteschön dann auch in die richtige Richtung: einfacher und > effizienter, > nicht komplizierter und umständlicher Einfacher und effizienter als der STM32 geht es kaum noch. Atmega und XMEGA sind definitiv nicht eintscheidend einfacher. Das kann täuschen, wenn man eine Plattform gewöhnt ist, Neues wirkt immer schwerer. Moby schrieb: > Antimedial: Wenn entsprechend > Leistung gefragt ist wird niemand einen 8Bitter empfehlen... Dann bleibt > heute leider nur der Griff zu ARM & Co, obwohl die ansonsten auch nur > mit Wasser kochen. Auch wenn die Leistung nicht erforderlich ist, sind die STM32 billiger und einfacher zu handeln, wenn man gleichzeitig auch mit größeren Prozessoren arbeitet, wegen gleicher Toolchain und größtenteils kompatibler Peripherie.
Antimedial schrieb: > Auch wenn die Leistung nicht erforderlich ist, sind die STM32 billiger > und einfacher zu handeln, wenn man gleichzeitig auch mit größeren > Prozessoren arbeitet, wegen gleicher Toolchain und größtenteils > kompatibler Peripherie. Genau das Thema wurde vor nicht mal einer Woche mit "Embedded" durchgekaut - Moby versteht das einfach nicht, weil er das nicht verstehen will. Er ist gefangen in seinem Schuhkarton und denk er lebt in einem riesigen unendlichen Universum. Dabei schaut er nur in Spiegel die den falschen Eindruck verleihen. Moby hat sogar ein STM32 Board rum liegen, er hat nur überhaupt kein Interesse das mal an zu fassen und ein Tutorial durch zu gehen, wie z.B. hier: http://diller-technologies.de/stm32_wide.html Moby ist nur dazu da, dass dieser Thread ständig mit Falschaussagen wieder neu gepusht wird. Und das macht er ja ganz gut ;-)
:
Bearbeitet durch User
Markus Müller schrieb: > Er ist gefangen in seinem Schuhkarton und denk es lebt in einem riesigen > unendlichen Universum. Dabei schaut er nur in Spiegel die den falschen > Eindruck verleihen. Ja, das ist das, was ich vor einigen Posts schon erwähnt habe. Komplexität ist in erster Linie subjektiv. Für 99% der Ingenieure ist ein STM32 genauso einfach wie ein Atmega.
Lothar schrieb: > Dann ist das wieder nicht sauber gelöst. Definitionen gehören Ich höre wohl nicht richtig! Das ist sogar sehr sauber gelöst, im Sinne maximaler Vereinfachung. Wer aber im Denken von Include-, Präprozessor und Make Files gefangen ist... Markus Müller schrieb: > Moby hat sogar ein STM32 Board rum liegen Und keinen denkbaren Einsatz dafür... Aber man möge mir nicht vorwerfen Markus Müller schrieb: > Er ist gefangen in seinem Schuhkarton ... Markus Müller schrieb: > dieser Thread ständig mit Falschaussagen die sagen der Einsatz eines STM32 für 8-Bit Projekte ist falsch, ja genau so. Passt Dir natürlich nicht in den Kram, den Einsatz Deines Controllers nur für die dafür sinnvollen Apps beschränkt zu sehen. Denn Du weißt genau, 90% der Projekte hier kommen ganz gut ohne Deinen STM32 aus. Chris D. schrieb: > Am Setzen eines Portpins hat er Dir ja gezeigt, dass sich da AVR und > STM32 in der Komplexität nicht unterscheiden. Nicht enttäuscht sein ;-) Nein ganz und gar nicht. Denn wie es im Real Life ausschaut hat der oben zitierte Thread einer simplen Blinkschaltung mit STM gezeigt. Erleichtert, daß es noch und für sehr lange Zeit AVRs zu kaufen gibt, trifft es viel eher.
Antimedial schrieb: > Komplexität ist in erster Linie subjektiv. Wieder eine seeehr gewagte Aussage...
Moby schrieb: > Einsatz eines STM32 für 8-Bit Projekte ist falsch Für Mini-Anwendungen habe ich einen LPC800 empfohlen, ab DIP8 gibt es den. Und ich brauche keine zweite IDE und keinen zweites JTAG Interface, falls ich doch mal so ein Mini-Ding brauchen sollte. Als Bastler bin ich da mit einem Segger J-LINK EDU für 50 EUR dabei. Eine einzige Ausgabe für die Entwicklungsumgebung, CooCox ist Freeware. Und ich kann alle Hersteller proggen, ST, NXP, Atmel, TI, Analog, Nuvoton und viele µC mehr, die auch einen ARM oder Cortex Kern haben.
Marcus W. schrieb: > Soll ich weiter machen? Inzwischen wurde alles gesagt hier - sogar mehrfach :-)
Pinwackeln ist langweilig. Wie sieht es denn mit dem ADC aus? Beim AVR schreibe ich ADMUX = kanal | 0x40; // Kanal und Vref vorgeben ADCSRA = 0xc7; // starten while(ADCSRA & 0x40); // warten und das Ergebnis des gewünschten Kanals steht in uint16_t ADC. Beim STM32 ist das sicherlich viel einfacher.
Moby schrieb: > Na wenn dieser Eindruck entstanden ist- falsch gedacht. > Nur bitteschön dann auch in die richtige Richtung Deine Richtung ist rückwärts. Soll man dir folgen? Chris D. schrieb: > m Setzen eines Portpins hat er Dir ja gezeigt, dass sich da AVR und > STM32 in der Komplexität nicht unterscheiden. Na ja, beim ARM ist das schon einfacher. Ein Register zum Setzen und ein Register zum Löschen. Es werden nur die Bits gesetzt, die man beeinflussen will. Es ist also kein vorheriges Lesen des Registers und die boolsche Verknüpfung nötig. Das ist einfacher und der Code ist schneller. Markus Müller schrieb: > Genau das Thema wurde vor nicht mal einer Woche mit "Embedded" > durchgekaut - Moby versteht das einfach nicht, weil er das nicht > verstehen will. Moby kann es nicht verstehen, da er den ARM nur vom Hören-Sagen kennt. Es übersteigt zur Zeit seine Möglichkeiten. Er nur noch nicht verstanden, dass andere pfiffiger sein könnten. ;-) Mensch Moby, gönn' deinen Bastelfreunden die moderne Technik. ;-)
ADCler schrieb: > Pinwackeln ist langweilig. Wie sieht es denn mit dem ADC aus? AD0CR_bit.SEL = 1<<(n); // AD0 channel n AD0CR_bit.START = 1; // start conversion while (!AD0GDR_bit.DONE); // wait for conversion val = AD0GDR_bit.RESULT; // AD0 channel n result Geht natürlich statt Polling auch mit Interrupt oder DMA oder Burst und statt Konvertierung mit 1 Pin und GDR auch n Pins parallel mit DR0 bis DRn
Beim STM32 sind es max. zwei Zeilen mehr. Mit 5 Zeilen mehr hat man dann schon komplette DMA-Unterstützung.
Ich bin Einsteiger und habe diesen Thread schon länger verfolgt. Mittlerweile habe ich mich einigermaßen in die 8-Bit AVRs eingearbeitet und verstehe auch das meiste. Nun habt ihr mich aber doch auf den STM32 heiß gemacht und ich habe mir mal das F0-Discoveryboard besorgt. Bisher habe ich damit nur eine LED blinken lassen und mehr nicht. Auf den ersten Eindruck sieht es komplizierter aus, weil es eben so mega viele Register gibt und man teilweise auch zwei Bits pro Register setzen kann. Z.B. GPIOC ->MODER |= (1<<16); um Pin 8 auf output zu setzen ist doch auf den ersten Blick nicht unbedingt logisch ;-) Ich frage mich gerade, ob ich für ein kleines Projekt nun lieber einen AVR nehme, wo ich die Software in C schon so gut wie fertig habe, oder aber das ganze portiere und lieber einen STM32 nehme. Konkret geht es um eine Steuerung, die über USB Steuersignale empfängt. Weiterhin werden ein bisschen ADC und SPI genutzt und mehr nicht. Würdet ihr gleich einen STM32 nehmen, der eigentlich eher overkill ist oder aber einen AVR? Preislich nimmt es sich ja echt nichts!
Walfänger schrieb: > Unentschiedener schrieb: >> Ich bin ... > > Moby? Nein! Das Moby pro STM32 ist habe ich schon gelesen. Mein Post ist ernst gemeint. Ich bin ein Anfänger, der sich gerade fragt, ob es nicht Sinn macht ganz von den AVRs wegzugehen. Und dass ich mir diese Frage stelle, daran ist diese Diskussion hier schuld ;-)
Unentschiedener schrieb: > Würdet ihr gleich einen STM32 nehmen, der eigentlich eher overkill ist > oder aber einen AVR? Wenn Du den Code für den AVR schon fast fertig hast und nur schnell das Gerät am laufen haben willst, dann nehme/bleibe bei AVR. Wenn Dich hingegen der STM32 reizt und es auf ein paar Tage nicht an kommt und was dazu lernen willst, dann nehme dem STM32. Aber erst mal kleine Brötchen backen: - Clock's - Port-Pins - Alternative Funktionen - Interrupts - (vielleicht noch UART oder Timer oder EA-Dog Display an SPI) durch gehen und dann hast Du die Grundlagen um auch mal sich an USB zu wagen und vor allem auch bis dahin schon einiges an Doku gelesen und verstehst viel besser wie alles zusammen hängt. PS: Bei Fragen im Forum den Threadtitel am besten mit "STM32" beginnen, dann lesen gleich viel mehr darin mit, die den STM32 kennen und man bekommt bessere Antworten.
:
Bearbeitet durch User
@ Markus Müller: Vielen Dank :-) Ich denke da mal in Ruhe drüber nach! Weiß jemand zufällig, wo ich eine Minimalbeschaltung von einem STM32 finden kann? Am besten wäre gleich ein Schaltplan mit JTAG-Anschluss und allen notwendigen Kondensatoren und Quarz usw. drum herum ;-) Google spuckt leider irgendwie nichts aus. Danke :)
Google nach S64DIL Ich kann grad keine Links posten.
Unentschiedener schrieb: > Weiß jemand zufällig, wo ich eine Minimalbeschaltung von einem STM32 > finden kann? Olimex hat verschiedene STM32-Boards mit Schaltplan, das Kleinste hier: https://www.olimex.com/Products/ARM/ST/STM32-H103/ Ich muss die STM32-Freunde aber mal wieder darauf hinweisen, dass die vergleichbaren LPC einfacher zu beschalten sind, hier der Vergleichbare: https://www.olimex.com/Products/ARM/NXP/LPC-H1343/ Zudem gibt es noch die LPC DIPs bei denen es noch einfacher ist z.B.: http://learn.adafruit.com/getting-started-with-the-lpc810/programming-the-lpc810-with-flash-magic http://www.hwhardsoft.de/english/projects/simon-says/
Lothar schrieb: > AD0CR_bit.SEL = 1<<(n); // AD0 channel n > AD0CR_bit.START = 1; // start conversion > while (!AD0GDR_bit.DONE); // wait for conversion > val = AD0GDR_bit.RESULT; // AD0 channel n result Das ist ja toll. Nirgendwo muß man den Takt einschalten, oder mitteilen, welcher Pin als ADC-Eingang dienen soll. Rechts und linksbündige Ausgabe von 12, 10, 8 oder 6 bit kann man auch nicht einstellen. So redet man sich die Welt schön.
> Weiß jemand zufällig, wo ich eine Minimalbeschaltung von einem STM32 finden kann? Am besten wäre gleich ein Schaltplan mit JTAG-Anschluss und allen notwendigen Kondensatoren und Quarz usw. drum herum ;-) Hier kannst du gleich das fertig bestückte Board B0DIL kaufen. Das spart eine menge Arbeit. http://re.reworld.eu/de/produkte/b0dil/index.htm http://re.reworld.eu/common/b0dil/B0DIL_schematic.pdf
ADCler schrieb: > Nirgendwo muß man den Takt einschalten, oder mitteilen, > welcher Pin als ADC-Eingang dienen soll. Muss man das beim AVR nicht? Aber gut: // Power und PCLK für die Logik zum Pinfunktion umschalten SYSAHBCLKCTRL_bit.IOCON = 1; // z.B. beim LPC1100 hat P1.11 als 2. Funktion AD7 IOCON_PIO1_11_bit.FUNC = 1; // interne Pullup/Pulldown Widerstände aus IOCON_PIO1_11_bit.MODE = 0; // mit Analogteil verbinden (Digitalteil ist Default) IOCON_PIO1_11_bit.ADMODE = 0; // Power und PCLK für den ADC SYSAHBCLKCTRL_bit.ADC = 1; // Abtastrate z.B. 3 MHz AD0CR_bit.CLKDIV = ((CLK/(SYSAHBCLKDIV)) / 3000000) - 1;
Markus Müller schrieb: > Google nach S64DIL > Ich kann grad keine Links posten. http://re.reworld.eu/de/produkte/b0dil/index.htm http://re.reworld.eu/common/s64dil/S64DIL-103_Manual.pdf http://re.reworld.eu/common/s64dil/S64DIL-405_Manual.pdf
:
Bearbeitet durch User
Lothar schrieb: > Muss man das beim AVR nicht? Aber gut: > > // Power und PCLK für die Logik zum Pinfunktion umschalten > SYSAHBCLKCTRL_bit.IOCON = 1; > // z.B. beim LPC1100 hat P1.11 als 2. Funktion AD7 > IOCON_PIO1_11_bit.FUNC = 1; > // interne Pullup/Pulldown Widerstände aus > IOCON_PIO1_11_bit.MODE = 0; > // mit Analogteil verbinden (Digitalteil ist Default) > IOCON_PIO1_11_bit.ADMODE = 0; > > // Power und PCLK für den ADC > SYSAHBCLKCTRL_bit.ADC = 1; > // Abtastrate z.B. 3 MHz > AD0CR_bit.CLKDIV = ((CLK/(SYSAHBCLKDIV)) / 3000000) - 1; Und jetzt meine Frage dazu als lernwilliger: Muss man sich diese kryptischen Abkürzungen etwa merken? Träumst du auch nachts von SIOSYSIFUSCPYLWLKJCJ.Depeche/Mode.bit = 0.;-) ....Die sind nicht gehirngerecht. Muss man das aus dem Datenblatt mühsam abtippen? - Kann doch nicht sein!
Tom schrieb: > Muss man das aus dem Datenblatt mühsam abtippen? Der Frager wollte ohne includes und Libraries arbeiten. In #include <nxp/iolpc1xxx.h> sind das unions d.h. der Compiler klappt die Elemente automatisch auf beim Tippen. Und wenn man die CMSIS Library nutzt dann gibt es ADC_Init() dafür. Andere uC mit Power-Saving sind aber auch nicht besser z.B. XMEGA: PRGEN.EBI=1; // power general - external PRPA.ADC=1; // power port A - ADC Und wenn man sich mit dem ARM beschäftigt ist die Namensgebung gar nicht so doof: SYS-AHB-CLK-CTRL für System-Bus-Clock-Control http://de.wikipedia.org/wiki/Advanced_High-performance_Bus
Tom schrieb: > Muss man sich diese kryptischen Abkürzungen etwa merken? Träumst du auch > nachts von SIOSYSIFUSCPYLWLKJCJ.Depeche/Mode.bit = 0.;-) ....Die sind > nicht gehirngerecht. Muss man das aus dem Datenblatt mühsam abtippen? - > Kann doch nicht sein! Das ist der Effekt, wenn man sich in Neues einarbeitet. Die AVR-Bezeichnungen sind nicht weniger kryptisch, die kennst du vielleicht nur besser.
Beim AD-Wandler nehme ich lieber die ST-Lib. - Übersichtlich - Einfach zu konfigurieren, weil schon alle Optionen vorgegeben sind - Sicher - versteht jeder - ich brauche fast nicht in der Doku lesen - Ready to Use - Beispiel für STM32F103 (Incl. Interrupt und DMA):
1 | void AD_InitCH1(u16 iZyklen) |
2 | {
|
3 | // Enable DMA1 IRQChannel
|
4 | NVIC_InitTypeDef NVIC_InitSt; |
5 | NVIC_InitSt.NVIC_IRQChannel = DMA1_Channel1_IRQn; |
6 | NVIC_InitSt.NVIC_IRQChannelPreemptionPriority = 0; // << Höchste Prio |
7 | NVIC_InitSt.NVIC_IRQChannelSubPriority = 0; |
8 | NVIC_InitSt.NVIC_IRQChannelCmd = ENABLE; |
9 | NVIC_Init(&NVIC_InitSt); |
10 | |
11 | ADC_Cmd(ADC1, DISABLE); |
12 | |
13 | // DMA1 channel1 configuration ----------------------------------------------
|
14 | DMA_InitTypeDef DMA_InitSt; |
15 | DMA_DeInit(DMA1_Channel1); |
16 | DMA_InitSt.DMA_PeripheralBaseAddr = (u32)&(ADC1->DR); |
17 | DMA_InitSt.DMA_MemoryBaseAddr = (u32)&iAD1; // Array der Wandlungen |
18 | DMA_InitSt.DMA_DIR = DMA_DIR_PeripheralSRC; |
19 | DMA_InitSt.DMA_BufferSize = sizeof(iAD1) / sizeof(iAD1[0]); // Array-Größe |
20 | DMA_InitSt.DMA_PeripheralInc = DMA_PeripheralInc_Disable; |
21 | DMA_InitSt.DMA_MemoryInc = DMA_MemoryInc_Enable; |
22 | DMA_InitSt.DMA_PeripheralDataSize = DMA_PeripheralDataSize_HalfWord; |
23 | DMA_InitSt.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord; |
24 | DMA_InitSt.DMA_Mode = DMA_Mode_Circular; |
25 | DMA_InitSt.DMA_Priority = DMA_Priority_High; |
26 | DMA_InitSt.DMA_M2M = DMA_M2M_Disable; |
27 | DMA_Init(DMA1_Channel1, &DMA_InitSt); |
28 | DMA_Cmd(DMA1_Channel1, ENABLE); |
29 | DMA_ITConfig(DMA1_Channel1, DMA_IT_TC, ENABLE); |
30 | |
31 | // ADC1 Configuration ------------------------------------------------------
|
32 | ADC_InitTypeDef ADC_InitSt; |
33 | ADC_InitSt.ADC_Mode = ADC_Mode_Independent |
34 | ADC_InitSt.ADC_ScanConvMode = ENABLE; |
35 | ADC_InitSt.ADC_ContinuousConvMode = ENABLE; |
36 | ADC_InitSt.ADC_ExternalTrigConv = ADC_ExternalTrigConv_None; |
37 | ADC_InitSt.ADC_DataAlign = ADC_DataAlign_Right; |
38 | ADC_InitSt.ADC_NbrOfChannel = 1; |
39 | ADC_Init(ADC1, &ADC_InitSt); |
40 | |
41 | // ADC1 regular channel configuration
|
42 | ADC_RegularChannelConfig(ADC1, ADC_Channel_3, 1, ADC_SampleTime_7Cycles5); // ANA Mess Eingang 1 |
43 | |
44 | ADC_DMACmd(ADC1, ENABLE); // Enable ADC1 DMA |
45 | ADC_Cmd(ADC1, ENABLE); // Enable ADC1 |
46 | |
47 | ADC_ResetCalibration(ADC1); // Enable ADC1 reset calibaration register |
48 | while(ADC_GetResetCalibrationStatus(ADC1)); // Check the end of ADC1 reset calibration register |
49 | ADC_StartCalibration(ADC1); // Start ADC1 calibaration |
50 | while(ADC_GetCalibrationStatus(ADC1)); // Check the end of ADC1 calibration |
51 | |
52 | ADC_SoftwareStartConvCmd(ADC1, ENABLE); // Start ADC1 Software Conversion |
53 | }
|
Mich interessiert an der Stelle nicht wie ich jetzt die 5 Register mit einer HEX-Zahl am optimiertesten und kürzesten lade, viel mehr dass der Code lesbar und verständlich bleibt, auch wenn ich den nach Jahren nochmal warten muss. Selbst dann wenn es einen besseren µC als den STM32 geben sollte und ich die Funktionalität des STM32 weitgehend verlernt habe weil ich den nicht mehr einsetze.
:
Bearbeitet durch User
Markus Müller schrieb: > Beim AD-Wandler nehme ich lieber die ST-Lib. > - Übersichtlich > - Einfach zu konfigurieren, weil schon alle Optionen vorgegeben sind > - Sicher > - versteht jeder > - ich brauche fast nicht in der Doku lesen Das sind doch die Eigenschaften der Arduino IDE :-) Tom schrieb: > Muss man sich diese kryptischen Abkürzungen etwa merken? Träumst du auch > nachts von SIOSYSIFUSCPYLWLKJCJ.Depeche/Mode.bit = 0.;-) ....Die sind > nicht gehirngerecht. Muss man das aus dem Datenblatt mühsam abtippen? - > Kann doch nicht sein! Das sind alles Maßnahmen, die der Vereinfachung bei 32 bitlern dienen :-) Lernen mußt du sie spätenstens dann, wenn es nicht funktioniert! Lothar schrieb: > Muss man das beim AVR nicht? Nein, das muß man nicht.
ADCler schrieb: > Das sind doch die Eigenschaften der Arduino IDE :-) Ja, genau. Der STM32 ist so leicht zu handhaben wie ein Arduino.
Markus Müller schrieb: > Ja, genau. Der STM32 ist so leicht zu handhaben wie ein Arduino. Also für Künstler und andere Spinner. Ich verstehe!
Ein 20 EUR Arduino STM32 Board: https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/ Bei dem wenigstens ein bisschen mehr aus nur ein µC drauf ist.
:
Bearbeitet durch User
> ADCler schrieb:
Da schreibt einer, der noch nie über die Grenze seines Stadteils hinaus
gekommen ist. Und das aus Angst sich zu verlaufen.
Er kauft daher immer in den gleichen Läden und wundert sich, was andere
für futuristische Dinge andere haben.
-> Was der Bauer nicht kennt, ...
ADCler schrieb: > Markus Müller schrieb: >> Ja, genau. Der STM32 ist so leicht zu handhaben wie ein Arduino. > > Also für Künstler und andere Spinner. Ich verstehe! Ja, nur ist er dabei so leistungsfähig, dass er auch Profis begeistert.
Walfänger schrieb: > Mensch Moby, gönn' deinen Bastelfreunden die moderne Technik. ;-) Ist pure Mißgunst meinerseits ;) Wenn nun ein paar % mehr Leute eher die Bedürfnisse ihrer App und nicht die Features der Technik- und bei Schwierigkeiten mit STM32 & Co die Möglichkeit, daß es 8-Bittig viel einfacher realisierbar sein könnte im Hinterkopf behalten, dann ist mein Ziel hier erreicht. Lothar schrieb: > Inzwischen wurde alles gesagt hier - sogar mehrfach :-) Stimmt. Hat trotzdem Spaß gemacht.
Moby schrieb: > die > Möglichkeit, daß es 8-Bittig viel einfacher realisierbar sein könnte Das ist aber immer noch eine Lüge.
Antimedial schrieb: > Komplexität ist in erster Linie subjektiv. http://de.wikipedia.org/wiki/Idealismus
So. Drei Jahre sind nun rum und immer noch haben weder TE noch die Mods es geschafft, die Überschrift dem Inhalt anzupassen. Dafür mußte ich mir am Wochenende vorhalten lassen, daß ja der µC-Einstieg laut dem von mir empfohlenen Forum (=mikrocontroller.net) am besten mit nen STM32 passieren sollte. HERZLICHEN DANK! @Mods: MACHT ENDLICH EUREN JOB!
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.