Hallo zusammen Ich arbeite jetzt seit 4 Monaten bei einem grösseren Elektronik Hersteller in der Schweiz. Mein erstes Projekt war eine Testfirmware für einen Cortex M3 STM32F107 zu schreiben. Nachdem ich dann erstmal die ST Library einigermassen kapiert habe, bin ich auch relativ schnell zum Ziel gekommen. Mittlerweile habe ich jetzt auch schon ein paar kleinere Projekte mit diesen Controllern realisiert. Immer wieder frage ich mich aber: Muss das wirklich so komplex sein? Mal der Core selber okay, aber die ST Lib ist ja teilweise wirklich zum heulen , defines von defines von defines usw.. Deshalb habe ich jetzt auch angefangen die Library zu entschlacken und ein wenig verständlicher zu gestalten. Jetzt zum eigentlichem Thema: Mein Chef sagt: Die Zukunft gehört den ARM Controllern, alles andere ist veraltet, und wird nicht mehr für neue Projekte verwendet! Ich bin jedoch der Ansicht, das man nicht immer unbedingt mit Kanon auf Spatzen schiessen muss. Für ne einfache Anwendung reicht auch ein einfacherer Controller, ist ja dann auch schneller programmiert, ob Atmel, MSP oder PIC sei mal dahingestellt. Was meint ihr? Werden heute in der Entwicklung wirklich nur noch die ARM Derivate benutzt, oder haben auch die anderen Controller (noch) ihre Daseinsberechtigung. Gruss Steff
Stefan K. schrieb: > Was meint ihr? Werden heute in der Entwicklung wirklich nur noch die ARM > Derivate benutzt, oder haben auch die anderen Controller (noch) ihre > Daseinsberechtigung. die 146875249955te, gggääähhhhnnnnnnnnnn...
Die Sache ist relativ einfach. Billig + bringt die benötigten Resourcen und Leistungen mit = gekauft. Es kommt nicht darauf an die Resourcen optimal aus Sicht eines Ingeneurs bestmöglich auszunutzen sondern die Resource Geld optimal zu nutzen. Sollte euer ARM dann mal etwas an der Leistungsgrenze sein und er aber aus finanzieller Sicht immer noch eine Wahl ist. Dann wirst du hören das du mal besser programmieren sollst... Das ganze Gerede kommt dann natürlich von Leute die davon nicht einen Hauch von Ahnung haben (Guten Tag ihr BWLer und WINGs da draußen!). Aber damit muß man sich halt arrangieren können und sein bestmögliches geben und dem Chef das auch klar und verständlich darlegen (auch einmal im härteren Ton).
>Mein Chef sagt: Die Zukunft gehört den ARM Controllern, alles andere ist >veraltet, und wird nicht mehr für neue Projekte verwendet! §1 Der Chef hat immer recht §2 Sollte der Chef einmal nicht recht haben, dann tritt automatisch immer §1 in kraft. Wieso sollte sich eine Firma die Entwicklungskosten nicht einsparen, wenn ALLE Entwickler nur noch den ARM proggen? Sonst müsste der Chef immer Entwickler für unterschiedliche Umgebungen mit unterschiedlichen Debug-Werkzeugen vorhalten. Mag ja sein, dass für die ein oder andere Mini-Anwenung ein kleiner AVR besser wäre, aber die ganzen Kosten drum herum müssen auch mit kalkuliert werden. Wenn es jetzt nur noch den ARM gibt, dann ist der gesamte firmeninterne Ablauf viel einfacher zu handhaben, jeder arbeitet mit den gleichen Werkzeugen und jeder kann das, bzw. ersetzen bei Urlaub oder Kündigungen.
Hi, Also pauschal zu sagen "Ich nutz nur noch ARM" ist natürlcih etwas Gewagt und muss wohl im zusammenhang mit eurem Produkt(en) gesehen werden? Je höher die Stückzahl desto größer der Kostendruck. Bei kleinen Stückzahlen können Einsparungen z.B. durch: -Nutzung der vorhanden Toolchain -Wiederverwendung von vorh. Code (z.b. Bootloader, HAL,..) -Wiederverwendung von vorh. Hardware designs -keine/geringe Einarbeitungszeit für die Entwickler im vordergrund stehen. Siehe "Fixe Kosten" Bei großen Stückzahlen überwiegen dann aber schnell die "Variablen Kosten" d.h. die Fixkosten (umgelegt auf die Stückzahl) sind nicht mehr relvant. Ein wenig BWL sollte ein Ingenieur auch, oder gerade als Chef, schon haben. Das berechnen eines Break-even sollte aber jedem Ing. unter Anwendung von Grundrechenarten möglich sein. (Vorrausgesetzt er Ist in der Lage zumindest ansatzweise die Fixen und Variablen Kosten zu quantifizieren. gruß Sebastian
Hi Früher oder später wird das nächste Schwein durchs Dorf getrieben und dann werden die ARMs genauso mitleidig belächelt. MfG Spess
ARM ist halt auch extrem weit verbreitet. Jedes popelige Mobiltelefon hat mehrere davon drin. Die IP ist relativ billig zu bekommen, dementsprechend billig sind dann die fertigen Chips. Man schaue sich nur mal die LPC Serie an. Klar, für einige Sachen wäre ein ARM überdimensioniert, aber das ist nicht unbedingt der entscheidende Faktor. Achja, und das man eben auch die IP kaufen kann, anstelle fertiger Chips (die ja eh alle nicht von ARM verkauft werden, die verkaufen eben nur die IP) hat den Vorteil das man, wenn man will, das ganze besser integrieren kann. Man wird also relativ unabhängig von einem einzelnen Hersteller. Grüße, Chris
Stefan K. schrieb: > Mittlerweile habe ich jetzt auch schon ein paar kleinere Projekte mit > diesen Controllern realisiert. Immer wieder frage ich mich aber: Muss > das wirklich so komplex sein? Mal der Core selber okay, aber die ST Lib > ist ja teilweise wirklich zum heulen , defines von defines von defines > usw.. Deshalb habe ich jetzt auch angefangen die Library zu > entschlacken und ein wenig verständlicher zu gestalten. Was bei der ganzen ARM-Diskussion immer übersehen wird, ist die Tatsache, dass nur der reine CPU-Kern standardisiert ist. Solche Sachen wie Interrupthandling (nicht bei Cortex, da machen sie es besser), DMA, Timer, Peripherie ist von Hersteller zu Hersteller völlig unterschiedlich - teilweise ist es einfacher, von AVR32 auf AT91SAM3U zu portieren als von STM32 auf LPC18xx. Man standardisiert die Tools und holt sich Abstraktionsebenen hinein (CMSIS), um die Vielfalt beherrschen zu können. Das ist die Strategie, die dahinter steckt, und man kann das durchaus anders sehen. Es gibt auch Branchen, bei denen bespielsweise die Infineon C16x/XC2xxx Standard sind (z.B. Automotive, da gehts dann um Themen wie funktionale Sicherheit etc). > Mein Chef sagt: Die Zukunft gehört den ARM Controllern, alles andere ist > veraltet, und wird nicht mehr für neue Projekte verwendet! Idee dahinter: Standardisierung der Produktlinien, Wiederverwendung von Code und Know-How, größere Einkaufsmengen. > Ich bin jedoch der Ansicht, das man nicht immer unbedingt mit Kanon auf > Spatzen schiessen muss. Für ne einfache Anwendung reicht auch ein > einfacherer Controller, ist ja dann auch schneller programmiert, ob > Atmel, MSP oder PIC sei mal dahingestellt. Der Preisunterschied zwischen einem ATMega und einem kleineren STM32 ist keiner mehr, und die Entwicklungszeit hängt auch eher davon ab, ob man die Tools beherrscht und ob sie gut sind. > Was meint ihr? Werden heute in der Entwicklung wirklich nur noch die ARM > Derivate benutzt, oder haben auch die anderen Controller (noch) ihre > Daseinsberechtigung. Auch die haben ihre Daseinsberechtigung, aber die Grenzen verschieben sich eben. Was früher mit nem 8-Bitter gemacht wurde, wird heutzutage mit einem 32-bitter schneller und billiger erledigt. Ich denke auch, dass inzwischen die Peripherie eine größere Rolle spielt - der geeignete Mix kann viel Arbeit und/oder Leiterplattenplatz und Kosten einsparen. fchk
spess53 schrieb: > Früher oder später wird das nächste Schwein durchs Dorf getrieben und > dann werden die ARMs genauso mitleidig belächelt. Nur dass ARM keine getriebene Sau ist. In der Preislage der klassischen 8-Bitter ist ARM vielleicht neu, aber die Architektur ist älter als die vom AVR. Und mobil war ARM schon Anfang der 90er. Als die AVR-Erfinder noch ihre Master-Arbeit über eine neue Architektur schrieben, konstruierten Apple-Techniker bereits den Newton mit real existierenden Chips. Das würde ich nicht unbedingt als vergängliche Modeerscheinung werten. Als Entwickler tust du dir auf jeden Fall einen Gefallen, mal mit ARM gearbeitet zu haben.
was heist hier mit koanonen auf spatzen schiesen. wenn ich für die gleiche kole nen M0 bekomme wieso nicht den einsetzen? es gibt nicht nur kosten Faktoren. auch Verfügbarkeit in der Zukunft cortex ist aktueller. der rest ggf hat schon ein paar jahre auf dem buckel. Wie sieht es in 2 jahre aus? abkündigiungen? ersatz? und wie sieht es mit wiederverwendung von code aus? kann man so einfach code von einem pic projekt nach arm übernehmen? und bei Stückzahlen kann ja jeder selber rechen was z.B. 1 Cent je Sütck bei Stückzahl y an kosten einsparen kann bzw wie lange man einen Entwickler dafür schuften lassen kann das doch hin zu bekommen.
123 schrieb: > und wie sieht es mit wiederverwendung von code aus? kann man so einfach > code von einem pic projekt nach arm übernehmen? Das hängt von deiner SW Architektur ab. Ggf. tauschst du "nur" BL und HAL aus und bist fertig...
Auch µC werden immer leistungsfähiger, während die Chipkosten am untersten Nenner kaum noch weiter runter gehen. Daraus folgt also, dass langfristig die 32 Bitter die 8 Bitter ersetzen werden, denn wenn selbst im unteren Bereich beide gleich viel kosten, dann wird man wohl kaum die leistungstechnisch schlechtere Wahl nehmen, zumal mehr Leistung und mehr Speicher ja auch Einsparungen bei der Software-Entwicklung erlaubt. Wer genug Speicher hat, der kann auch großzügiger damit umgehen, das macht die Entwicklung der Software günstiger. Den Prozess sieht man heute schon bei normalen PCs und der wird sich auch bei µC bemerkbar machen, wenn er das nicht jetzt schon tut. Mit mehr Leistung sinken auch die Personalkosten, denn rar gesäte Guru-Programmierer verlieren an Bedeutung, wenn es nicht mehr so wichtig ist, den besten Algorithmus zu verwenden oder den µC am effizientesten zu nutzen, wenn der µC mit der Leistung alles wettmacht. Die Zukunft wird also ein geringerer Bedarf an Optimierungen und die Verwendung von Hochsprachen bis hin zu Hilfslibs und Werkzeugen sein. Insofern, ja, ARM ist als 32 Bit µC eine potentielle und vom aktuellen Status her sinnvolle Zukunft. Ob der AVR32 dagegen halten kann, würde ich bezweifeln, denn die ARM µC werden einfach von zu vielen Chipherstellern in Lizenz gefertigt, daß senkt bei ARM µC die Preise, während die des AVR32 von Atmel berstellerbezogen bleiben. Bestenfalls hat mittelfristig noch der MSP430 eine gute Chance, weil er eben super stromsparend ist und mit seiner 16 Bittigen Architektur und linearem Speichermodell sehr modern ist. Die ganzen 8 Bit µC, von ATMega, ATTiny bis zu PIC werden aber mit ziemlicher Sicherheit drastisch Marktanteile verlieren. IMO sind das Tote Pferde, für neue Projekte würde ich diese nicht mehr nutzen.
Noch etwas. Die 32 Bitter stehen eigentlich nur in einem Punkt schlechter da, nämlich der Anzahl der Pins. Aber es spricht ja nichts dagegen, abgespeckte 32 Bitter mit einer verringerten Pin Anzahl herzustellen und den Kern bei 32 Bit zu belassen. Wer dann nur 4 I/O braucht, der wird dann auch so einen Chip im bswp. 8 Pin Gehäuse erhalten.
Der Chef hat nicht ganz Unrecht, man kann natürlich auch ein kleines Projekt mit nem ARM erledigen, für das ein 8Bitter oder gar ein 4bit-Prozessor völlig reichen würden. Andersherum ist das oft schwieriger bis unmöglich. Und Leute, die sich mit einem Chip richtig gut auskennen, sind Gold wert. Was also liegt näher, sich auf eine Chip-Familie einzuschiessen, die mehr oder weniger fast alles erledigen kann, was in den nächsten Jahren anfällt? Austauschbarkeit der Leute/Verschiebung von Prioritäten bei mehreren parallel laufenden Projekten wird deutlich vereinfacht, kostenmässig spielen die Einzelchipkosten kaum ne Rolle, da mehr oder weniger auf gleichem level. Es gibt am Ende immer Termindruck - gut, wenn man dann noch manpower zuschiessen kann. Hilfe, die dann erst eingearbeitet werden muss, ist eher hinderlich. Umso weniger verstehe ich Atmel mit seinem XMega-Versuch, irgendwie am Ball zu bleiben. Spielzeug, teuer, Totgeburt.
@ Markus Müller (mmvisual) >Wieso sollte sich eine Firma die Entwicklungskosten nicht einsparen, >wenn ALLE Entwickler nur noch den ARM proggen? >Sonst müsste der Chef immer Entwickler für unterschiedliche Umgebungen >mit unterschiedlichen Debug-Werkzeugen vorhalten. Sicher. >Mag ja sein, dass für die ein oder andere Mini-Anwenung ein kleiner AVR >besser wäre, aber die ganzen Kosten drum herum müssen auch mit >kalkuliert werden. Wenn es jetzt nur noch den ARM gibt, dann ist der >gesamte firmeninterne Ablauf viel einfacher zu handhaben, jeder arbeitet >mit den gleichen Werkzeugen und jeder kann das, bzw. ersetzen bei Urlaub >oder Kündigungen. Auch richtig. Aber one size fits all sollte man immer etwas skeptisch sehen. @ duddelsack (Gast) >Es kommt nicht darauf an die Resourcen optimal aus Sicht eines Ingeneurs >bestmöglich auszunutzen sondern die Resource Geld optimal zu nutzen. >Sollte euer ARM dann mal etwas an der Leistungsgrenze sein und er aber >aus finanzieller Sicht immer noch eine Wahl ist. Dann wirst du hören das >du mal besser programmieren sollst... Richtig. Gerade bei kleinen und kleinsten Stückzahlen lohnt sich die maximale Hardwareoptimierung nich, da sind Hardwarekosten klein und die Entwicklungskosten maßgeblich. In extremen Massenmärkten (Automotive, Hausgeräte, Konsumerkram) ist das anders. Aber ARM ist schon recht gut, soweit ich das aus der Entfernung beobachten kann. Von recht klein ala 8 Bit Controller bis Embedded PC-Format gibt es alles, stromsparend, schnell, leistungsfähig. Menn man den einmal hat, lohnt der Abstieg auf einen minimal billigeren 8 Bitter kaum. >diesen Controllern realisiert. Immer wieder frage ich mich aber: Muss >das wirklich so komplex sein? Mal der Core selber okay, aber die ST Lib >ist ja teilweise wirklich zum heulen , defines von defines von defines >usw.. Deshalb habe ich jetzt auch angefangen die Library zu >entschlacken und ein wenig verständlicher zu gestalten. Das ist eher ein spezielles Umsetzungsproblem als ein allgemeines ARM Problem.
Sam P. schrieb: > ... aber die Architektur ist älter als die > vom AVR. Ja, wenngleich es mit dem ursprünglichen Einsatzzweck halt auch nicht so der Volltreffer war, den Acorn sich damit erhofft hätte. ;-) Auch ist die Architektur der heutigen ARMs wohl kaum noch mit der der alten vergleichbar. Im Wesentlichen dürfte es der Thumb-Befehlssatz sein, der ihm zum Durchbruch verholfen hat. Bis dahin waren sie auch nur einer unter vielen (32-bit RISC-CPUs).
Jörg Wunsch schrieb: > Auch ist die Architektur der heutigen ARMs wohl kaum noch mit der der > alten vergleichbar. Im Wesentlichen dürfte es der Thumb-Befehlssatz > sein, der ihm zum Durchbruch verholfen hat. Bis dahin waren sie auch > nur einer unter vielen (32-bit RISC-CPUs). Thumb-1 ist nur eine echte Teilmenge vom ARM-Befehlssatz. Kürzere Instruktionen == reduzierte Wertebereiche. Darum war Thumb-Code auch immer etwas langsamer als ARM-Code, weil man da wieder mit dem gewurschtel anfangen musste, wenn man eine Konstante brauchte, die in Thumb nicht in einer Instruktion vorgesehen war. Thumb-2 soll da besser sein und das beste von beiden Welten vereinigen. Ich glaube daher nicht, dass der Thumb-Befehlssatz der Durchbruch war. Ich sehe da eher die gut durchdachte Architektur, die so stromsparend war, weil die ersten ARMs Mikrocode-frei waren (so wie der altehrwürdige 6502). Aber eigentlich ist es nur das kontinuierliche Weiterentwickeln, was ARM zu dem gemacht hat, was es heute ist. Für den µC-Bereich ist Thumb wirklich wichtig, und da hat ja Atmel lange mit seinem AVR32 gestänkert, dass die mehr Mips/MHz schaffen. Seit Thumb-2 ist das vorbei. Gibt ja auch keine wirkliche Weiterentwicklung bei AVR32 mehr. Und x86 ist einfach zu komplex, nichtmal der Atom wäre eeignet als µC. Der einzige echte Konkurrent ist noch MIPS, wie man ihn im PIC32 findet. Die haben ja das Geschäftsmodell von ARM übernommen, das aber fast 10 Jahre später. Inzwischen baut die Welt eben ARM.
Ich glaube, Dein Chef hat weitgehend Recht. Bei ARM bekommst Du für gleiches Geld einen viel leistungsstärkeren Chip, der weder wesentlich größer ist, noch mehr Strom verbraucht. Da ist es ganz egal, ob du den Chip auslastest, oder nicht. Aber es gibt auch Sachen, die ich nicht mit einem ARM machen würde. Das sind die Anwendungen, wo ich typischerweise einen ATtiny oder einen Atmega8 benutze. Die sind dann doch kleiner und billiger. Aber bei einer Neuentwicklung, die einen "großen" AVR's wie den ATmega2560 oder ATmega128 efordert, würde ich auch inzwischen lieber einen ARM Controller verwenden. I bleibe aber bei AVR, weil ich die Neuanschaffung der nötigen Entwicklungstools scheue. Ich entwickle Einzelstücke, die nie mehr als 2-3x hergestellt werden. Da lohnt sich für mich die Anschaffung neuer Tools und Know-How nicht. Aber irgendwann werde auch ich sicherlich doch noch auf den ARM kommen, alleine schon deswegen, weil ich auf den Chip neugiereig bin. Spätestens, wenn Mbed ein Modul mit on-board Ethernet anbietet wird es wohl soweit sein.
Was ich mich frage ist, ob dadurch, also weil es eben immer schneller und der Speicherplatz immer höher wird, nicht der Programmierstil drunter leidet. Einfach irgendwie hingeklatscht, es läuft ja eh, weil der µC überdimensioniert ist. Irgendwann hat man sich dran gewöhnt und die Leistung bzw der Platz reicht nicht mehr, obwohl es das bei "vernünftiger" Programmierung noch gehen würde. Aber das ist wohl lauf der Dinge. "Die Hausfrau" von heute hat zum Surfen und für Office ja auch einen PC mit 4-8 Kern-Prozessor, mindestens 2-4GB RAM, ne 512MB Grafikkarte und ne 500GB-1000GB Festplatte, damit sie ein paar Rezepte googlen und ausdrucken kann...
Tja wir sind mit 2KByte RAM und ca. 5000 Gatter mit 1MHz auf dem Mond gelandet aber wir brauchen 4Gbyte RAM ca. 1 Milliarden Gatter mit 3GHz um einen Brief zu schreiben.
Uwe schrieb: > Tja wir sind mit 2KByte RAM und ca. 5000 Gatter mit 1MHz auf dem Mond > gelandet aber wir brauchen 4Gbyte RAM ca. 1 Milliarden Gatter mit 3GHz > um einen Brief zu schreiben. ROFL, wohl wahr. Ich habe vor kurzem gelesen, daß der Computer der Mondfähre in Wire Wrap Technologie gemacht worden ist weil das zuverlässiger war als löten. Dann wurde das vergossen.
> Mal der Core selber okay, aber die ST Lib ist > ja teilweise wirklich zum heulen Libraries verwende ich grundsätzlich nicht, die Treiber für die Peripherals sind idR so schnell selbst geschrieben, wie man sich in die Feinheiten der Lib eingearbeitet hat. Ausser USB, ETH, RTX, Flash Filesystem etc. da nehm ich das fertige Zeug (in meinem Fall von Keil). Den Cortex-Core selbst finde ich sehr gelungen. Tricky ist nur, sich erst mal in den jeweiligen Clock Tree einzuarbeiten (wird aber mittlerweile von der CMSIS SystemInit standardmässig übernommen, siehe startup.s File), sowie zu verstehen, welche Peripheral Clock Enables man schalten muss. Schau dir mal die Keil Examples (die sind ohne DriverLib, \Keil\ARM\Boards\Keil\MCBSTM32xxx\) an, sowie die CMSIS Sachen (core_cm3.h). In der core_cm3.h findest du u.a. sehr hilfreiche Funktionen zur Vereinfachung der Zugriffe auf den NVIC. VG, /th.
Moin, die Diskussion ist vielleicht etwas müssig (sorry, habe kein scharfes s). Trotzdem: Der Chef sollte sich klarsein, dass, wo ARM draufsteht, ein grausiger Wildwuchs an Extensions und architekturellen Unterschieden drinsteckt. Mir als eifriger GCC-Nutzer ist insofern fast wieder egal, welche Architektur ich verwende, solange die "board supply packages" und die C-library oder der OS-Support (wie z.B. für Linux) einigermassen fehlerfrei ist, oder genug "open source", um selber die Bugs fixen zu können. Viele scheinen jedoch dem Trugschluss zu erliegen, dass ein ARM einfach durch einen Chip aus "zweiter Quelle" ersetzbar ist, wenn ersterer nach 7 Jahren abgekündigt wird. Insofern kann ich bei ARM nicht erkennen, was daran zukunftsträchtiger sein sollte als bei anderen Architekturen: Auf den Hersteller muss man sich eh fast immer so gut wie festlegen. Wenns um hochoptimierte (assembler-) Aufgaben geht, wo langfristig eine homogene Architektur vonnöten ist, dürften die einheitlichen NISA-Kerne der Blackfins deutlich besser designt sein, haben allerdings auch damit ihre klaren Grenzen (kein Float, kein virtuelles Speichermanagement). Die MIPS-Architektur ist auch ziemlich clever und gleichzeitig simpel. Schade, dass sich MIPS fast nur in kaum dokumentierten China-SOCs wiederfindet. Ja und im Endeffekt ist die Diskussion müssig, weil so gut wie immer die Lösung möglichst kostengünstig erreicht werden muss. Für kleine Stückzahlen zählt dann eher die Entwicklungszeit als die Siliziumkosten, deshalb finde ich es durchaus legitim, mit Kanonen auf Spatzen zu schiessen, wenn die Entwicklungsumgebung was taugt. Aber auch da kann man gewaltig Fehler machen, hatte schon einige abgesoffene ARM-Projekte auf dem Tisch, wo die Kunden tüchtig Geld mit bedingt brauchbaren Tools verballert haben. Fazit: Dein Chef hat nicht pauschal recht, und er sollte sich primär auf den Hersteller, die gut dokumentierten Tools und die Referenzapplikationen fixieren, nicht auf das A, das R, und das M.
sebastian schrieb: > Ein wenig BWL sollte ein Ingenieur auch, oder gerade als Chef, schon > > haben. Ist das eine Krankheit oder meinst du einen BMW?
Hat eigentlich schon jemand EMV-Erfahrungen mit den ARM? Ich hab mal einen LPC2292 verwendet, alle 14 Abblockkondis dran und 4 Lagen. War trotzdem manchmal empfindlich und ist abgestürzt. Dagegen habe ich mit AVRs keinerlei Probleme auf 2 Lagen. Obwohl in den Geräten bis zu 18kV rumgeistern und bei Überschlägen auch hohe Kurzschlußströme fließen. Peter
Launchpadfrage schrieb: > Die 32 Bitter stehen eigentlich nur in einem Punkt schlechter da, > nämlich der Anzahl der Pins. > Aber es spricht ja nichts dagegen, abgespeckte 32 Bitter mit einer > verringerten Pin Anzahl herzustellen und den Kern bei 32 Bit zu > belassen. > > Wer dann nur 4 I/O braucht, der wird dann auch so einen Chip im bswp. 8 > Pin Gehäuse erhalten. Full Ack, und dann noch konfigurierbare Pins.
Stefan schrieb: > Spätestens, wenn Mbed ein Modul mit on-board Ethernet anbietet wird es > wohl soweit sein. Dann sieh dir mal das hier an: http://de.farnell.com/texas-instruments/eks-lm3s6965/kit-eval-lm3s6965-m-code-composer/dp/1812209 Ist alle mit dabei, inklusive einer unbegrenzten Entwicklungsumgebung und JTAG. ( CodeComposerStudio) Die Boards gibt es auch mit Can, Usb und .... Die heißen alle eks-lm3sXXXX Es gibt die auch mit anderen Entwicklungsumgebungen wie zb Keil, die sind dann aber auf Codegröße oder ähnliches limitiert.
Birne schrieb: >> Wer dann nur 4 I/O braucht, der wird dann auch so einen Chip im bswp. 8 >> Pin Gehäuse erhalten. M.E. ist das wirklich das einzige, was fehlt. Die derzeitig günstigen 32er-bitter (LPC,STM32) sind einfach zu unhandlich, um sie in FB-Geber oder Kleinststeuerungen o.ä. einzusetzen, wo ein 8-pin Tiny eben genau das richtige ist. Wenns sowas mit ARM Core gibt und in einer ähnlich Preisklasse wie die AVRs, dann ist das auch für mich das Ende der 8-bit Ära. Und wenn man sich in die Peripherie einmal eingefummelt hat, geht das auch. Schade, das die IDEs entweder teuer oder umständlich sind. Aber ich denke, da wird sich noch was tun.
>Ist alle mit dabei, inklusive einer unbegrenzten Entwicklungsumgebung >und JTAG. ( CodeComposerStudio) Hatte ich für Piccolo mal installiert. Ich muss sagen, es hat erstaunlich gut funktioniert. Allerdings dauerte die Installation gefühlte 2 Tage und hat gefühlte 10TBytes auf meinem Rechner installiert.
Michael Skropski schrieb: > Was ich mich frage ist, ob dadurch, also weil es eben immer schneller > und der Speicherplatz immer höher wird, nicht der Programmierstil > drunter leidet. Einfach irgendwie hingeklatscht, es läuft ja eh, weil > der µC überdimensioniert ist. Irgendwann hat man sich dran gewöhnt und > die Leistung bzw der Platz reicht nicht mehr, obwohl es das bei > "vernünftiger" Programmierung noch gehen würde. Beim PC ist das doch schon der Fall. Es wird beim PC auch nicht mehr so viel in fordernden Hochsprachen wie C und C++ programmiert, wo der Programmierer noch wirklich Hintergrundwissen haben und was können muss, sondern in einfachen Scriptsprachen wie PHP und Python. Selbst Java ist eine Vereinfachung gegenüber C++.
Stefan schrieb: > Spätestens, wenn Mbed ein Modul mit on-board Ethernet anbietet wird es > wohl soweit sein. Sowas: http://mbed.org/handbook/mbed-NXP-LPC1768 ?
Mit ARM fallen viele Chefs auf pures Marketing rein, selbst der CM0 ist von der Anzahl an Gattern eher fUer State machines geeignet als fuer steuerungsaufgaben. Der 8bit markt hab ich irgendwo gelesen ist ca. 4billionen dollar gross und soll auch so bleiben, allerdings wird die anzahl der hersteller deutlich zurueckgehen, ich denke renesas, atmel und microchip werden sich den kuchen teilen. Auf io ebene brauch ich keine 50mhz, ich brauche hohe integration wie schnelle und ganz wichtig genaue adc, schnelle reaktionszeiten und moglichst hohe integratiin zb eeprom. Was nutzt dafuer ein cm0 der scheinbar billig ist, aber kein eeprom hat? Die nxp doku vom cm0 ist grotten schlecht, durftige sammlung von registeraufzaehlung. Da lobe ich die doku von atmel und mchip. Irgendwie haben die jungen entwickler vergessen was mit 8051war, das war auch derselbe core, und wird von atmel bis heute weiterentwickelt, zb die neue at89lp serie. Komisch dass mchip keinen cortex hat, atmel spaet kam aber deutlich aufgeholt hat, und trotzdem haben diese firmen marktanteile deutlich gewonnen, waehrend st trotz super billigen cm3 marktanteile verloren hat und das waehrend die wirtschaft 2011 brummte. Ich glaube um den arm wird viel heisse luft gemacht, und billig heisst nicht unbedingt gut. Bin mal gespannt wenn die ersten hersteller die preise deutlich anziehen auf ihre cortexe, speziell nxp und st. Mit 8051 war es das nicht das erste mal...
stefan schrieb: > 4billionen dollar Das wäre etwa das http://de.wikipedia.org/wiki/Bruttosozialprodukt#Internationaler_Vergleich von Deutschland. Guck mal hier: http://dict.leo.org/ende?search=billion
Sorry hab es mit deutsch etwas schwer, in usa sind ja billionen die milliarden, es soll naturlich 4milliarden heissen
Matthias Sch. schrieb: > Birne schrieb: >>> Wer dann nur 4 I/O braucht, der wird dann auch so einen Chip im bswp. 8 >>> Pin Gehäuse erhalten. > > M.E. ist das wirklich das einzige, was fehlt. Die derzeitig günstigen > 32er-bitter (LPC,STM32) sind einfach zu unhandlich, um sie in FB-Geber > oder Kleinststeuerungen o.ä. einzusetzen, wo ein 8-pin Tiny eben genau > das richtige ist. Wenns sowas mit ARM Core gibt und in einer ähnlich > Preisklasse wie die AVRs, dann ist das auch für mich das Ende der 8-bit > Ära. Und wenn man sich in die Peripherie einmal eingefummelt hat, geht > das auch. EFM32TG108F4 Cortex-M3 24-Pin QFN LPC1102UK Cortex-M0 16-Pin UFBGA (gibt wohl auch einige im TSSOP-20) PIC32MX110F016B MIPSm4k 28-Pin QFN Größe passt schon, Preise dagegen noch nicht. Was auch zukünftig eine Chance für andere/herstellereigene Cores lässt: http://www.eetimes.com/electronics-products/processors/4114549/ARM-raises-royalty-rate-with-Cortex "Score, ... late in 2009, said that in the past ARM had typically charged 1 percent of the chip price for the use of an ARM processor core. Score said the royalty rate had moved up to 1.1 percent to 1.2 percent on cores from the Cortex range." > Schade, das die IDEs entweder teuer oder umständlich sind. Aber ich > denke, da wird sich noch was tun. Schon mal die IDE/Tools von SiLabs angesehen? http://www.silabs.com/products/mcu/Pages/32-bit-mcu-software.aspx
Microchip hat da auf MIPS gebaut und den Kern in die PIC32 eingebaut. Ich meine den PIC32MX220 (oder einen anderen) gibts im DIP28 (sowie SOIC und QFN). Das lob ich mir bei den PICs. Alles, was 40pins nicht überschreitet gibts ansich auch im DIP. Es gibt von JEDER PIC Familie Bausteine im DIP.
Michael Skropski schrieb: > Es gibt von JEDER PIC Familie > Bausteine im DIP. DIP ist IMO nur noch im Hobbybereich von Relevanz. Firmen können mit SMD umgehen und das ist auch vom Preis günstiger. Und 1 bis 3 Mann Betriebe haben sicher auch inzwischen das Werkzeug um SOP & Co zu löten. DIP ist auch allein vom Aufwand her die Löcher zu bohren teurer.
Kann sein das ARM und Co die Zukunft ist, aber für uns als Hobbybastler wird das immer schwerer werden: SMD bis zu einem bestimmten Grad lässt sich noch löten, aber der Spaß hört spätestens beim QFN auf, wenn man nur noch auf Reflow angewiesen ist. Und von mehr als 2 Lagigen Platinen und Folienplatinen will ich lieber gar nicht anfangen... Was die Zukunft an geht: sehr wahrscheinlich das sich ARM durchsetzt, war doch schon immer so, auch für kleine Anwendungen werden größere Systeme eingesetzt weil es Preislich möglich ist. So war früher z.B. ein normales Programm einige kB bis mB groß, heute hat man Glück wenn das Programm einem nicht gleich die halbe Festplatte raubt (mit 10-25GB für 1 (!) Programm)... Beim Arbeitsspeicher sieht es genau so aus. (Führt übrigens auch bei Programmierern dazu faul zu werden und sorglos mit dem RAM umzugehen, gibt ja genug... Denke das wird auch hier passieren, also immo achtet man darauf ja seine paar kB Flash nicht zu überschreiten, mit ARM ist das nicht mehr so wichtig...). MfG
Fer T. schrieb: > (Führt übrigens auch bei Programmierern dazu faul zu werden und sorglos > mit dem RAM umzugehen, gibt ja genug... Bei der Softwareentwicklung liegt es unter anderem auch daran, dass optimierten Code niemand bezahlen will. Die Konsumenten und auch Kunden kaufen das, was günstiger ist. Und wenn die Realisierung der Softwarelösung in PHP deutlich günstiger ist als z.B. in C++, dann wird auch PHP verwendet. Das es bei den einfacheren Scriptsprachen dann noch mehr Programmierer gibt und die Qualität der Programmierer auch schlechter ist bzw. darunter leidet, tut ihr übriges dazu.
Fer T. schrieb: > aber der Spaß hört spätestens beim QFN auf, wenn man nur noch auf Reflow > angewiesen ist. QFN(16) löte ich problemlos mit normalen Lötkolben
Das ist doch einfach ... ein ARM ist doch fast in jedem Handy drin, billiger kann man nicht mehr an einen ARM Prozessor mit viel Speicher kommen ;-)
Launchpadfrage schrieb: > Mit mehr Leistung sinken auch die Personalkosten, denn rar gesäte > Guru-Programmierer verlieren an Bedeutung, wenn es nicht mehr so wichtig > ist, den besten Algorithmus zu verwenden oder den µC am effizientesten > zu nutzen, wenn der µC mit der Leistung alles wettmacht. Im Gegenteil: Mit mehr Leistung steigt der Druck auch diese Leistung auszureizen. Zum Beispiel eine Waschmaschine mit Betriebssystem und Internetanschluss zu haben wenn die Konkurrenz das auch hat.
Rainer S. schrieb: > Im Gegenteil: Mit mehr Leistung steigt der Druck auch diese Leistung > auszureizen. Wenn ich die (Rechen-)Leistung eines C64 einem aktuellen PC gegenüberstelle, dann müsste der PC im Bereich Textverarbeitung die Korrespondenz auch ohne mich abwickeln können. Aber ... > Zum Beispiel eine Waschmaschine mit Betriebssystem und > Internetanschluss zu haben wenn die Konkurrenz das auch hat. ... wenn das die Interpretation von "Leistung" sein soll, dann hast du natürlich recht. :-)
Arc Net schrieb: >> M.E. ist das wirklich das einzige, was fehlt. Die derzeitig günstigen >> 32er-bitter (LPC,STM32) sind einfach zu unhandlich, um sie in FB-Geber >> oder Kleinststeuerungen o.ä. einzusetzen, wo ein 8-pin Tiny eben genau >> das richtige ist. Wenns sowas mit ARM Core gibt und in einer ähnlich >> Preisklasse wie die AVRs, dann ist das auch für mich das Ende der 8-bit >> Ära. Und wenn man sich in die Peripherie einmal eingefummelt hat, geht >> das auch. > > EFM32TG108F4 Cortex-M3 24-Pin QFN > LPC1102UK Cortex-M0 16-Pin UFBGA (gibt wohl auch einige im TSSOP-20) > PIC32MX110F016B MIPSm4k 28-Pin QFN Jo, ist aber immer noch zu fett für die wirklich kleinen Sächelchen, die ich mit den 8-Beinern mache. Ich drücke mich nicht vorm Löten, aber finde, wenns ein 8-Pinner tut, brauch ich keinen grösseren. Arc Net schrieb: > Schon mal die IDE/Tools von SiLabs angesehen? > http://www.silabs.com/products/mcu/Pages/32-bit-mc... Jetzt mal ganz kurz auf deinen Link hin, aber ich find grad nicht, welche Architekturen sie unterstützen. Im Moment fummel ich mit der letzten freien Atollic TS Variante mit unlimitiertem Code, das klappt ganz gut, ist aber natürlich obsolet. stefan schrieb: > Die nxp doku vom cm0 ist grotten schlecht, durftige sammlung > von registeraufzaehlung. > Da lobe ich die doku von atmel und mchip. Microchip kenne ich nicht, aber im Vergleich zu Atmel ist ST eine wilde Ansammlung von wirrem Zeug in der Doku und du musst für den STM32 immer mindestens 2 PDFs offenhaben, plus die Library Sources, um durchzublicken. Und die wichtigen Sachen kriegt man eigentlich nur raus, wenn man 'ne Menge Beispiele durchwühlt. Ich sag nur NVIC oder den kranken STM32 ADC - wer hat sich das ausgedacht und wer hat die Doku dazu geschrieben? Hingegen das Event System und die IRQs im XMega sind gut beschrieben und laufen quasi sofort. Und man kann sagen was man will, der 32 Mhz XMega rennt dem 24 Mhz STM32 locker weg, zumindest in meiner Anwendung.
Markus Müller schrieb: > ein ARM ist doch fast in jedem Handy drin, Fast? So weit ich weiss hat parktisch jeder Baseband/Modem-Chip in heutigen Mobiltelefonen einen ARM Kern drin. Die eigentliche CPU bei einem Handy, OK, die kann (selten) auch mal was anderes als ARM sein. Also müsste es heissen das in jedem Handy mindestens ein ARM drin steckt, meistens mehrere. Gleiches gilt für UMTS Sticks. Auch da findet sich ein ARM Kern. Selbst so "einfache" Sachen wie Interface/Modem-Chips für die gute alte analoge Telefonleitung haben meistens einen ARM Kern. Die Dinger sind heutzutage fast überall. Grüße, Chris
Hallo Stefan, Du schriebst >Mit ARM fallen viele Chefs auf pures Marketing rein, selbst der CM0 ist >von der Anzahl an Gattern eher fUer State machines geeignet als fuer >steuerungsaufgaben. Ich denke da kommen gelich mehrere Probleme zusammen. Eine Architekturentscheidung fällt nicht im stillen Kämmerlein und nicht auf der grünen Wiese. Wenn diese ENtscheidung für ein Unternehmen getroffen werden muss hat diese weitreichende Auswirkunegn (ich denke finanzeiller als auch personeller Art). Eine solche Entscheidung trifft man normalerweise nur sehr selten und hint erfragt sie nicht morgen schon wieder. Manchmal ist es aber nötig solche Entshceidungen zu hinterfragen, das hat verschiedene Gründe (viele unterschiedliche Architekturen in einer Firma, Kosten, Neuaufbau einer ENtwicklungsumgebung, ...). In einem solchen Zuge wird (sollte zumindest) dabei nicht nur der aktuelle Stand des Markets abgebildet werden sondern auch das Entwicklungspotential. Ich selber haben solche Marktforschung lange Jahre durchgeführt. Tatsächlich sehe ich es aus meiner Warte (Ich bin kein Vorgesetzter [mehr]) wie folgt und diese Ansicht hat sehr viele Gesichtspunkte (Kosten, Performace, Verfügbarkeit, FW Unterstützung, Libs, Entwicklungsumgebungen, ....): Für kleine bis mittelere Steueraufgaben (Waschmaschine, Gargentorantrieb, intelligente Sensoren, Telefonanlage...) werden die kleinen ARM-Architekturen die früher noch in Mobiltelefonen alle Aufgaben erledigt haben (Arm7, CortexM3) durchaus zu 100% den 8 Bittern den Rang ablaufen. Grund dafür ist bei den meisten Halbleitererstellern ein durchgängiges Portfolio an Prozessoren die von unetn bis oben den Leitunsgbereich, die Anzahl der verfügbaren Pripherie sowie die verfügbaren Speicherdichten und bauformen abdecken. Zudem wenden sich vorwiegend die namhaften Großen (TI, STM, NXP, ...) dieser Architetur zu. DIe z.B. 8051 ist bei dne großen schon lange raus. DIes hängt auch mit der Möglichkeit zusammen, die Architektur weiterzuentwickeln. Wer von den Halbleiterherstellern mächte schon Peripherie (Spezieller PWM Module, CAN, USB, MAC, ...) entwickeln um dann festzustellen dass die COres nicht weiter entwickelbar sind? Bei ARM schnalle ich die Peripherie hinter die AHB and JEDEN (na ja, fast) kern dran und ich habe einen Neuen Prozessor in der höheren Leistungsklasse. Da muß ich noch nicht mal viel tun, die Kerne entwicklet ARM. Perislich sieht das mit den Cortex M3 inzwischen so gut aus das ich bei 24MHz, 8K Flash bei etwa 1EUR einsteigen kann. Dann kann ich skalieren bis hin zum kompatiblen 176MHz M4 mit 1MB - egal was ich brauche. Klar kostet das dann auch Geld, aber das kosten die anderen Przessoren in etwa auch. Dann ist da noch die Entwicklungsumgebung. Da ha sich schon viel getan und wird sich noch viel tun. Klar gibt es für spezielle Anforderungen auch die supporteten Tools von den namhaften. Wer aber günstig frei einsteigen will kann offene Tools (Eclipse) oder codesizebschränkte Werkezeuge nehmen. Dann hört man immer wieer mal das Argument "Gehäuse". Die Zeit des DIL ist noch nicht vorbei - allerdings vorwiegend auf China (Kosten!) und weisse Ware beschränkt. Die meisten etwas weiterentwickelten Länder und ENtwicklungen setzen auf Kosten - und die resultieren aus LEiterplattenkosten und Produktgehäusegrößen. Aus diesem Grund werden sind die SMD Bauformen bevorzugt. In unseren Regionen wird der DIL bis auf wenieg Ausnahmen sicherlich nur noch vom Bastler verwendet. Im übrigen lässt sich mit etwas Übung auch ein TQFP mit Pitch 0,5mm von Hand löten aber nicht mit dem Dachpfannenbräter des Gasinstallateurs. Wenn du daher mit der ENtscheidung Deiner Vorgesetzen nicht einhergehst bitte diese doch, die Enstcheidung Dir näher zu erläutern damit DU sie besser vertsehen kannst. Wenn euere Firma für sich entschieden hat ARM einzusetzen dann geht da kein Weg daran vorbei. Udn die Gründe dafür sind heute leider meist sehr gut. Wer Rechtschreibfehler gefundne hat - derer sidn viele denn ich tippe im Garten - darf sie behalten. Und Deutschlehrer bitte weglesen. Grüße
Werden denn in der professionellen Entwicklung noch µCs im DIP-Gehäuse verwendet, z.B. für Prototypen, Klein(st)serien usw.?
Eher nein, denn der Aufwand ist größer, da die Platine durch die Welle muss. Wieso für die Kleinserien was anderes nehmen als für die Großserie, wo man schon günstige Bauteile bekommt? Außerdem muss jede Firma anhand dem Gewicht der in Umlauf gebrachte Waren die Abgaben zahlen (Siftung EAR). Da wird alles kleiner und die Platinen immer dünner. Daher nur noch SMD, so klein wie nur irgendwie bestückbar und ausreichend für die Verlustleistung die das Bauteil vertragen können muss.
@ Konrad S. (maybee) >Werden denn in der professionellen Entwicklung noch µCs im DIP-Gehäuse >verwendet, z.B. für Prototypen, Klein(st)serien usw.? Profis können SMD-Löten, auch in Einzelstückzahlen.
Falk Brunner schrieb: > Profis können SMD-Löten, auch in Einzelstückzahlen. Glaub ich dir. Aber wird dafür gleich von Anfang an eine Platine gefertigt oder gibt es vorher einen Test-Aufbau der Schaltung?
Christian Klippel schrieb: > Gleiches gilt für UMTS Sticks. Auch da findet sich ein ARM Kern. Selbst > so "einfache" Sachen wie Interface/Modem-Chips für die gute alte analoge > Telefonleitung haben meistens einen ARM Kern. Die Dinger sind heutzutage > fast überall. Andererseits gibts eine SSD, die statt eines ARMs einen 8051-Core drin hat.
@ Konrad S. (maybee) >> Profis können SMD-Löten, auch in Einzelstückzahlen. >Glaub ich dir. Aber wird dafür gleich von Anfang an eine Platine >gefertigt oder gibt es vorher einen Test-Aufbau der Schaltung? Auch Testaufbauten bestehen meistens aus layouteten Platinen und nur selten aus Lochrasterverhau. Denn es ist deutlich einfacher und billiger, das ggf. per Autorouter schnell zu verdrahten als tonnenweise Fädeldraht zu ziehen. Ab einer bestimmten Komplexität ist Lochraster schlicht Unsinn, und die Grenze liegt ziemlich niedrig.
ich weiß nicht, mit 8051 gabs doch dasselbe, den gleichen Core, ISP usw. und trotzdem hat sich eine proprietaere Architektur damals auf dem markt etablieren koennen (AVR...) - und trotzdem haben Firmen in separate Tools investiert. Das gleche wird ARM passieren, irgendwann ist der Zug wieder abgefahren. Ich hab mich auch gefragt warum ich einen 8bitter nutzen soll wenn ich dafur auch 32Bit bekommen kann. Und trotzdem gibt es beim AVR und MCHP Vorteile fuer 8Bit - solange keine 32Bit Mathematik stark genutzt wird. Ich habe einige fuer meine Steuerung gefunden: - Meistens schlaeft meine Steuerung und ich brauche niedrige Stromaufnahme. CortexM ist dank eines moderneren Prozesses gut in active mode, aber meine Applikation schlaeft die meiste Zeit ueber und fuer mich ist wichtig sleep mode und schnelles aufwachen, genause kurze Interrupt Antwortzeit, damit verschwende ich weniger cpu zyklen, eben fuer echtzeitsteuerung. - fuer meine Steuerung brauche ich echte single cycle IO access - ich brauche 12Bit ADC mit rail-to-rail support und integrierter gain stage Wenn ich mir die LPC11xx mit xmegas vergleiche, die LPC bieten max. 64k flash, verbraten 3uA mit RAM retention und 7ms wakeup vs. 0.6uA und 5us wakeup beim xmega. Der LPC12xx hat gar 30uA sleep mode, wobei ich nicht rausfinden konnte wie schnell er aufwacht. Dazu sind LPCs ADC recht schwach, nur 10Bit und max 400ksps, xmega bietet hier 12Bit mit rail-to rail und gain stage. Hingegen der STM32F0 verbraet mir 4.5ua bei 8us aufwachzeit, hat zwar einen 12bit adc aber die error sind erheblich, da muesste ich einen externen adc dran anschliessen und mein kostenvorteil ist dahin. Nuvoton schneidet von den Cortexen M0 noch am besten ab, 2.5ua bei 7us aufwachzeit, aber trotzdem zuviel wenn ich low power brauche. Selbst beim IO access, ist der CM0 deutlich schlechter als ein handelsublicher avr, der cm0 ist mit 2zyklen spezifiziert, der AVR mit 1zyklus., die interrupt latenz beim cm0 mit 16zyklen, beim avr zwischen 8..12 zyklen, ich brauche super schnelle Reaktion, die ich mit dem xmega in 2 zyklen mache dank event systems, selbst branching kostet den CM0 3zykle, den avr nur 2zykle. Bei meiner Anwendung sind etwa 10-20% Sprungbefehle, wenn ich mir das auf die Laufzeit hochrechne kommt der AVR recht gut weg. Der AVR hat auch getrennte busse, codeaufnahme und zugriff auf die peripherie geht ueber getrennte busse beim avr was weniger bus-konflikte erzeugt. Beim ARM muss ich von CM0 auf CM3 ueber verschiedene Architekturen gehen wenn ich mehr als 128K flash brauche, beim AVR ist der Core bis 384K immer derselbe. Xmegas haben crypto AES/DES engine, die CM0 wieder nicht, xmega hab ich mehr PWM, DMA die den transfer von peripherie zur peripherie ermoeglicht, cm0 kann das nicht. Am interessantesten wird es wenn man die Stromaufnahme nicht nur bei 25° vergleicht. Xmegas schneiden hier sehr gut ab, bei 85°C einige wenige uA, waehrend stm32f0 >15uA nutzt und LPC11xx auf 25uA kommt. NXP hat auch recht schlechte power up schutzschaltung. Auf meine Frage bei NXP support erhielt ich folgende Antwort "when the Vdd is slowly increasing, e.g. power is coming up from a solar-panel, then the controller may not start up in the right way.” Die Konsequenzen daraus wollte mir die Hotline nicht verraten, ich gehe von flash corruptions aus. Manche Cortexe haben auch keinen Analog Comparator, oder DAC. STM32F0 hat wiederum keinen eeprom und max. 64kb flash, auch keinen AC. Nach meiner Analyse ist der CM0 ueberhaupt kein wuerdevoller Nachfolger fuer 8Bit/16Bit, und die Migration auf groessere CM3 ist gar kein Pluspunkt. Zwar kann ich von CM0 auf CM3 wechseln, der Instruction set vom cm0 ist subset vom cm3, aber aus Kompatibilitaetsgruenden duerfte ich die erweiterten CM3 Instructions nicht nutzen - mangels groesserer Flash Speicher und besserer Peripherie aufm CM0 waere ich aber gezwungen auf CM3 zu gehen- nutze aber die neuen Instruktionen nicht da diese mit dem CM0 nicht kompatibel sind, und ich kann dann nicht mehr so geschickt downgraden wie es aufm AVR moeglich ist. Der wechsel vom CM0 auf CM3 geht auch nur dann so einfach, wenn auf denselben identische Peripherie ist. Ist sie aber nicht, da der CM0 einen 10Bit ADC hat, der CM3 wieder 12Bit ADC - die IPs sind also selbst bei denselben Herstellern auf CM0 und CM3 verschieden. CM3/4 fuer mich ja, wenn ich Ethernet, CAN und Graphic nutzen will, ansonsten ist und bleibt ein 8Bit Micro mit sehr guter Peripherie die bessere Wahl.
Hallo Stefan, Du führst viele Argumente für Architekturen an die wohl von der einen als auch anderen Architektur schlechter oder besser unterstützt werden. Wenn ich heute ein sehr kostengetriebenes Projekt in hohen Stückzahlen machen muss dann kann die Entscheidung durchaus heißen: 8-bitter, speicheroptimiert. Dasselbe gilt dafür wenn es um bestimmer Anforderungen im Bereich Zyklenzeit/Zugriffszeit auf Ports geht. Ich sage aber:"KANN". Ein "großer" Elektronikhersteller (c.f. Hersteller heißt auch er will die selbst herstellen, da kommen wichtige Fragen zum Them Supply-Chain hinzu, ansonsten wäre es nur ein großes Entwicklungslabor) wird darauf achten dass er keinen Wildwuchs bekommt. Das lässt sich mit Platformen am einfachsten gestalten. Kunst ist es dann so wenig Platformen wie möglich mit möglichst großer Spannbreite zu wählen. Ich selber arbeite gerade mit der STM32F3 Platform. Da geht es eben schon ab 8kB/1EUR (ca. 1kpcs) mit CM3 los, nach oben offen, alles mehr oder minder gleiche Platform. Darunter wird es aber auch für andere Hersteller preislich schwierig. Eine Modellbahn-Amplelsteuerung (ohne Sicherheitsanforderungen), nur 6 LEDs ein/aus, das ganze mit RC Oszillator für die Geschwindigkeit könnte man sicher auch einfach mit einem kleinen PIC machen. Wenn Du aber dann morgen eine Touch-Applikation machen musst oder übermorgen etwas mit komplexen Bussen wird auch DU dich Fragen: Kann ich auf möglichst vorgefretigte Teile zurückgreifen. Das ist der Vorteil von Platformen. Und wenn dei Ampleprojekt dann auch nur 100-1000 Stcük verkauft wird dann ist die Frage nach den Kosten auich nicht mehr so dringend. Denn die 500EUR (1000 Stcük * 0,5EUR Differenz für einen 8-Bitter gegen einen kleinen ARM) Kosten verbrät ein Entwickler in etwa 2-3 Tagen, das ist der Aufwand den dein Kollege braucht um sich in Deine Gedanken einzuarbeiten wenn Du etwas Propiertätes oder Nicht-Standardplatformiges (huch- welch ein blödes Wort) macht (nein, nicht nur den Code sondern auch die Schaltung, die IDE, die Bilbliothek, ...). Zur Lib. Die von STM ist nicht sonderlich gut dokumentiert und man hört viel Kritik, zumeist auch zu Recht. Aber es lässt sich nach etwas Einarbeit vernünfig damit arbeiten - heisst: Was ich brauche bekomme ich schnell hin. High speed oder wenig Speicher erfordert sicher eine andere Herangehensweise als die Lib. Vorteil: Wenn neue Releases kommen sollte alles kompatibel beleiben. Und alle SW-Entwickler haben die gleiche Grundlage sowie den (etwa) gleichen Kenntnisstand. Welchen Grund hat denn Dein Chef Dir genannt, warum die alten Architekturen nicht mehr verwendet werden sollen. Und welches Produktportfolio bedient Ihr? Ist die Entscheidung nicht auch für Dich ein Vorteil wenn sich der Markt genau in diese Richtung entwickelt und Du in genau diesem Segment fit bist? Grüße
32 Bit bringen bei µC-Anwendungen nicht so große Vorteile wie auf dem PC. 4 GB Speicher muss man eher selten adressieren und man manipuliert häufig nur Bytes. Preislich kommen ARMs nicht an die Klasse ATTiny/PIC10FXX heran. Und das Know-How kann man bis zu den ATMEGAs hinauf nutzen ohne die Werkzeuge wechseln zu müssen. Das ist nicht zu unterschätzen. Ja, mit den Cortex ist ARM sehr interessant geworden. Aber einer für alles ist das für mich wirlich nicht.
Hi Friedrich, naturlich wollen alle nur eine Platform, es waere auch ideal wenn auch wirklich alle Hersteller dieselbe Peripherie anbieten wurden. Dem ist aber auch nicht so und es bleibt ein Wunschdenken. So wie Frank K. in seinem Beitrag schrieb, ist es leichter von AVR32 auf einen SAM3 zu wechseln als von STM32 auf LPC dank standardisierter Peripherie. Die Chefs (und auch der Einkauf) denkt nur in Zahlen, aber nicht praktisch. Wie gesagt wir hatten das ganze mit Standardplatform beim 8051, und trotzdem konnten sich MIPS und AVR cores durchsetzen auf dem Markt. ARM machte einfach sehr gutes Marketing und viele sind auf den Zug aufgesprungen, mal abwarten wenn die Hersteller wieder die Preise anziehen - irgendwann wollen sie auch mal was verdienen selbst mit 1Euro Bausteinen - und ich wette ST macht den Anfang, wenn ich mir deren Position auf dem Weltmarkt ansehe (wieder haben sie Marktanteile verloren, siehe databeans Vergleich) - und das trotz Booms in 2011 und Cortex. Frank K. schrieb: > Was bei der ganzen ARM-Diskussion immer übersehen wird, ist die > Tatsache, dass nur der reine CPU-Kern standardisiert ist. Solche Sachen > wie Interrupthandling (nicht bei Cortex, da machen sie es besser), DMA, > Timer, Peripherie ist von Hersteller zu Hersteller völlig > unterschiedlich - teilweise ist es einfacher, von AVR32 auf AT91SAM3U zu > portieren als von STM32 auf LPC18xx.
Hallo Detlev, einer für alles kann er (es gibt nicht DEN ARM) nicht sein. Dazu der Platformgedanke. Wenn ich denn alle Kostenbereiche von 1EUR Produkten bis >>100EUR bedienen muss dann ist bei großen Stückzahlen (e.g. 100k) es UNBEDINGT notwendig sich unten herum etwas einfaches Billiges auszudenken. Dafür gibt es z.B. einen PIC10F2xx oder Ähnlich. Und oben herum kann ein M4 vielleicht noch nicht genug dafür gibt es A8 und Konsorten. Wer dann aber damit (A8) schon 100k pa damit produziert hat sowieso vernünftige Glaskugelleser und wird sich hier nicht tummeln. Was ich noch versuche zu verstehen: >Mein Chef sagt: Die Zukunft gehört den ARM Controllern, alles andere ist >veraltet, und wird nicht mehr für neue Projekte verwendet! Ich habe bisher Verständnismöglichkeiten und Anregungen zum Nachdenken gegeben. Aber warum die Entscheidung so gefallen wurde :), ob sie so platt gefällt wurde, was an Anforderungen abgedeckt werden muss und wie groß die zu bedienende Infrastruktur ist (Entwickler HW/SW, Fertigunsgvolumen) habe ich in Unkenntnis außer Acht gelassen, dazu schwiegt sich der TO aus. Interessant aber wäre es schon. Das muss jeder, der sich die Frage stellt - ARM oder andere Platform - selbst überlegen. Im Übrigen: Die Antwort auf die Frage heißt sowieso: 42. Grüße
Fer T. schrieb: > Kann sein das ARM und Co die Zukunft ist, aber für uns als Hobbybastler > wird das immer schwerer werden: > SMD bis zu einem bestimmten Grad lässt sich noch löten, aber der Spaß > hört spätestens beim QFN auf, wenn man nur noch auf Reflow angewiesen > ist. > Und von mehr als 2 Lagigen Platinen und Folienplatinen will ich lieber > gar nicht anfangen... Diese Ansicht halte ich für etwas "veraltet". Es liegt in der Natur des Menschen, dass man versucht sich Veränderungen zu ersparen. Wenn man aus heutiger Sicht mal auf das Geschehen blickt, dann sieht man, dass eigentlich das Reflowlöten absolut kein Problem mehr ist. Ich habe mir erst neulich einen Pizzaofen für 22€ gekauft und mit da mit einem PIC (jaja im DIP-Gehäuse) eine kleine Regelung dazu gebaut. Ein N-INV und eine 1N4148 im Glasgehäuse in Flussrichtung. Mit nem ADC die Spannung über der Diode abgegriffen und fertig. Dazu ein Optotriac für 2,20€ von Reichelt, PID drauf, parametrisieren. Kosten alles in allem mit Pizzaofen ~30€. Selbst 128 Ball FBGA (!) CLC5903CISM habe ich vergangenen Woche damit problemlos löten können. Bei Reichelt gibt es für so gut wie jedes SMD-IC-Gehäuse einen Adapter auf 2,54mm Raster. ~0,20€. Wer immernoch Breadboard oder Lochraster machen möchte, der kann sich ja solche Adapter + Stiftleisten nehmen. Man muss also feststellen, dass Hobbyreflowlöten zu einem Preis machbar ist, der den Anschaffungskosten einer etwas teureren Billiglötstation entspricht. Viele Anfänger gerade in anderen Bereichen (Mikrokopter, ...) die steigen von vorn herein mit einem solchen Pizzaofenumbau ein. Für die ist das so normal wie für uns ein Lötkolben. Vielleicht sollte man da auch als eingefleischter Hobbybastler mal nachdenken, ob das nicht vielleicht auch ein Schritt in die richtige Richtung wäre ...
Hallo Stefan, >Die Chefs (und auch der Einkauf) denkt nur in Zahlen, aber nicht praktisch. Schade, gerade in Zahlen und Geld zu denken kann sehr praktisch sein. Ich sehe das immer am Ende des Monats. Spass beiseite: In einer vernünfigen Company ziehen alle an einem Strang, EK und R&D auch. Es hilft ja Nichts wenn ich immer nur Äpfel essen muss weil die billig sind. Und umgekehrt bringt es keine Rendeite wenn die Modelbauampel mit dem PC als Steuerung realisert wird. Also heißt es den RICHTIGEN Mittelweg finden. Preise anziehen: Das geht nicht so einfach. TI mit seine Bausteinen liegt finanziell zu weit daneben und NXP macht dem STM ordentlich Druck. STM ist bekannt dafür dass er billig produzieren kann genauso wie NXP. Diese letzen Eindruck habe ich bei Atmel und Microchip überhaupt nicht. Die haben (ist schon eine Weile her) Mondpreise gemacht und unzuverlässig geliefert. Solche Dinge will ein großer Kunde überhaupt nicht einmal denken. Sicher: ARM wird gut und clever vermarktet. Aber wenn es um einfach, schnell und kostengünstig geht ist das bisher eine gute Rille. Aber wir reden ja hier nicht um die 15 Stück die ein Bastler kauft. Wir reden um große Mengen. und die benötigen Fertigungsinfrastruktur. Und die können sich nur die Großen leisten. Und die müssen dann eben auch Geld an ARM abdrücken udn das muss wieder reinkommen. Billig ist das nie, aber es hat etwas mit dem ertsen Punkt zu tun: Mit Zahlen. Als wird jede Firma es sich guit überlegen wo sie hinrennt. Auch die Deine. Aber gib uns doch mal ein paar Eckdaten - wenn die möglich ist. Grüße
Ich dachte immer, ARM ist gerade deswegen so toll, WEIL man zwischen den Herstellern wechseln kann ohne groß was ändern zu müssen und immer den gleichen Kern usw hat!? Klingt ja hier von einigen nach dem Gegenteil. @B. Limer: Ich kenne das, dass man sich mit Veränderungen schwer tut. Ich finde aber auch, dass es in manchen Bereichen einfach ein "In eine Richtung zwingen" ist. Meist um Geld zu schöffeln und die neuen Produkte verkaufen, da etwas nur noch damit machbar ist (oder es in Zukunft so kommt), obwohl es technisch möglich wäre. Doch bei Hobby-Elektronikern finde ich, dass es schon viele Gründe gibt, bei DIP oder SOIC/TQFP zu bleiben. Ich bohre lieber mal ein paar Löcher mehr für einen DIP (bei Projekten, wo es nicht auf die Größe ankommt), genauso wie für 1/4W Metall-/Kohleschichtwiderstände oder andere Through-Hole-Bauteile, anstatt da auf einer deutlich kleineren, dichter besiedelten und "stressiger" zu lötenden Platine rumzuwerkeln zu müssen. Dazu kommt, dass die Platine meist auch nicht das non-plus-ultra ist. Das heißt oft: Lochraster oder selbstgemachte Platinen (geätzt mit Selbstbaubelichter, bedruckte Folie und Ätzbad oder aber gefräst). Pads für ein TSSOP-Gehäuse zu drucken und danach zu ätzen, dass es hinterher auch noch verwendbar ist, ist aus meiner Erfahrung nicht möglich, es sei denn man hat sehr viel Glück, ist die ganze Zeit vorm Ätzbad um zu beobachten und der Drucker ist vernünftig. Aber auch dann ist bei BGA schluss. Man hat evtl mehr Platz als bei TSSOP aber Leiterbahnen bekommt man da auch nicht mehr unter. Ich hab die Möglichkeit bei mir an der FH Platinen kostenlos zu fräsen. Keine automatische Durchkontaktierung und der kleinste Fräser ist 0,2mm. Damit kann man schon n bisschen machen, jedoch hat man das gleiche Problem bei BGA, wie bei selbstgeätzen Platinen. Und für jedes Projekt eine Platine zu kaufen ist mir a) zu umständlich und b) zu teuer. Vorallem kann ich ja durch Wahl eines anderen Gehäuses mir die Zeit und Kosten sparen, da ich ja die Platine so machen kann. Und da kommt dann wohl von einigen auch oft das "Ich nehm lieber nen 8bitter statt nen ARM, der tuts auch und ist einfacher und schneller zu löten". Da ich aber dennoch mit der Fräse genug fein für TSSOP, TQFP, TQFN o.ä. fräsen kann, wollte ich dich mal Fragen, ob es zum Selfmade-Reflowofen eine Homepage oder Tutorial gibt, das du empfehlen kannst oder gar genutzt hast. Ich mein, wenn man was umbauen muss, muss man ja auch wissen was usw. Interessieren tut mich das schon. Genauso: Was ist, wenn man auf beiden Seiten SMD-Bauteile Löten will? Sprich, wie dreh ich die Platine um, ohne das die Bauteile verrutschen, um die Bauteile auf der Oberseite zu platzieren, geschweige denn, wie mach ich das mit verschieden hohen Bauteilen. Und wie sieht das mit dem Lötzinn aus? Das wird ja sonst als Paste und mit Schablone aufgetragen. Würde mich freuen, wenn du (oder jemand anderes) mir eine PN schicken könntest, um den Thread hier zu schonen.
Konrad S. schrieb: > Glaub ich dir. Aber wird dafür gleich von Anfang an eine Platine > gefertigt oder gibt es vorher einen Test-Aufbau der Schaltung? Ja. Was soll es denn für einen Sinn haben, irgend etwas im fliegenden Aufbau, Lochraster o.ä. zu wurschteln, wenn das angezielte Produkt dann ganz anders aussieht? Ich mache es wie viele andere: Ich entwerfe für diverse Teilprobleme entsprechende kleinere LP, füge die dann zu einem Multinutzen zusammen und kann dann die Schaltungsdetails in ihrer realen Umgebung testen. Wenn das soweit hinhaut, wird die Prototypen-LP gemacht und dann geht es damit weiter. Für Breadboards, DIL-Gehäuse und Konsorten ist da überhaupt kein Platz mehr, denn sowas ist bei moderneren Bauelementen sinnlos. Was will man da testen? Doch wohl nicht die HF- und Störstrahlungseigenschaften - oder??? Und nochwas zum Ausgangsthema: Die Cortex-Architektur ist gut und wird ihren Weg machen. Das finde ich ganz in Ordnung. Aber sie wird auch in Zukunft nicht die einzige sein, denn einerseits gibt es auch künftig noch massenweise Probleme, die man besser mit irgendeinem kleinen 8 Bitter löst und andererseits gibt es Anwendungsbereiche, wo andere Architekturen einfach etabliert und besser sind. Ich denke da an Multimedia-Anwendungen und Automotiv und Sicherheitsrelevant. In ganz vielen DVD-Playern stecken Custom-IC's wie z.B. die von ESS und Nachfolgern, wo so etwa folgendes drin steckt: ein 64 Bit Signalprozessor, ein Hardware-Dekomprimierer als ASIC, eine MIPS-CPU für's ordinäre householding und ein 8051 für niedere Dinge wie Tasten abfragen, Frontseiten-LCD/LED bedienen usw. Wir haben hier im Forum gleich 2 Monster-Threads dazu: --> Pollin MOTOROLA VIP1710 --> Pollin - Receiver-Mainboard mit Twin DVB-[T,C] Tuner, NXP PNX8950EH Das sind typische - wenngleich auch etwas angestaubte - Designs aus der Multimedia-Szene. Dann gibt es aber auch noch die eher automotive Szene, wo Firmen wie Fujitsu mit ihren 32 Bit FR-Controllern eine Rolle spielen. Nebenbei gesagt, finde ich die FR-Architektur angenehmer und besser als die ARM-Architektur. Die Fujitsus haben sich allerdings selber ein Bein gestellt: Da sie ja eine Riege hochkomplexer Grafikprozessoren haben, wollen sie denen keine Konkurrenz machen, indem sie eine billige TFT-Ansteuerung in ihre FR- CPUs einbauen - und genau DAS läßt dann eine Menge Kunden zu NXP abschwenken. Eine der wichtigen Neuerungen beim Cortex ist es jedoch, daß zumindest die "besseren" Cortexe auf unalignete Daten zugreifen können, was ein ganz wichtiges Plus ist und alle älteren Vergleiche diverser Architekturen mit dem ARM7 relativieren. W.S.
Hallo Michael, das mit dem Core hast Du schon richtig verstanden, das bleibt von Hersteller zu Hersteller gleich. Unterschiede dazu wird der Compiler (nahzu) eliminieren. Was jedoch von NXP zu STM zu TI anders sein wird ist die Peripherie da jeder Herstller seine eigene Peripherie strickt. Das kann dazu führen dass Du beim portieren der Applikation von einem zum andere vollständig scheiterst wenn du stark HW-abhängige features in deinem Programm hast (Timer, Busse). Das ist aber auch beim Wechsel von properitaäre zu propritärer Achitektur nicht anders. Innerhalb einer Herstllerplatform (zumindest bei STM, ich denke bei TI auch nicht anders, zu NXP kann ich Nichts sagen) bist DU nahzu kompatibel. Deswegen lohnt sich der Blick VOR der Entscheidung einer Plattform mit allen Beteiligten welche Nachteil man damit in Kauf nimmt. Und ich denke da sind wir uns einig: ARM ist nicht das Allerheilmittel da es DEN ARM nicht gibt. Jeder Anwender ist dafür verantwortlich die Kriterien seiner Applikationen herauszuarbeiten und die dazu passenden Prozessoren oder Platformen dazu zu selektieren. Nur einfach sich eine Antwort zu wünschen ohne die Frage zu kennen ergibt das Ergebnis "42" oder dann eben eine unpassende weil zu teuere oder nicht portable Lösung. Im übrigen (Off Topic): Ich löse die meisten Problemstellungen zum Aufbau/Löten wie folgt: 1. Schritt (Bastler): Evaboards (z.B. Oli...) an die dann bei Bedarf weitere HW angeflanscht wird. Dies gibt dann meist einen ersten Funktionsprototypen. 2. Schritt (Industrie): Danach geht es direkt ins PCB , die Bauteile werden beim Bestücker gesetzt und gelötet da nur so in der realen Umgebung (Formfaktor, Temperatur, EMV, Zuverlässigkeit ) getestet werden kann. Für Bastler halte ich den ersten Schritt für am sinnvollsten (EVAL-Board) da diese ohne Lötprobleme funktionsfähig beschaffbar sind. Und die Kosten halten sich in Grenzen. SMD im Pizzaofen ist für mich klar eine Möglichkeit, die den ersten Schritt noch erweitert. Es muss aber klar sein dass damit auf keinen Fall in irgendeiner Form (Vor-)Serienquanlität getestet werden kann denn die Qualität der Bauteile ist durch den nicht nachvollziehbaren Lötprozess nicht sicherzustellen. Schon in der Vorserie ist bei uns der Serienlieferant des PCB (unbestückt und bestückt) drinnen damit die Qualitätskette beurteilt werden kann. Und der setzt mit Bestückautomaten und lötet im Reflowofen so wie es ich gehört. "Gehört" heißt dass die Temeperaturprofile der Bauteile eingehalten werden, auch das gehört zur Spec genauso wie die Betriebsspannung und die empfohlenen PCB Land-Pattern. Grüße
Ich frage mich auch, ob der Kern tatsächlich so eine grosse Rolle spielt. Ich habe etwas mit den Atmels gemacht, auch mit diversen Renesas Bausteinen und auch mit ARM, aber der Core hat eigentlich beim Wechsel von einem Core zum anderen nie Probleme gemacht. Wurde einfach neu kompiliert und fertig. Probleme hat die Peripherie gemacht, weil alle Timer, ADC, und und und komplett andere Register hatten. Dau zähle ich auch das Interrupthandling, die ja bei ARM auch nicht durchgängig identisch ist. Von daher ist die Einschränkung auf ARM viel zu kurz gesprungen. Viel entscheidender ist eine durchgängige Peripheriestruktur. Gruss Axel
Axel Laufenberg schrieb: > Ich frage mich auch, ob der Kern tatsächlich so eine grosse Rolle > spielt. Bei der Auswahl des Entwicklungssystems. Wenn du im Laufe der Jahre schon den Gegenwert eines Kleinwagens in ein professionelles Entwicklungssystem gesteckt und damit viel Erfahrung hast, dann wechselst du nicht so gern. > Viel entscheidender ist eine durchgängige Peripheriestruktur. Ein zweischneidiges Schwert. Weil es den Hersteller allzu leicht an überkommene Strukturen bindet.
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.