Forum: Mikrocontroller und Digitale Elektronik ARM ist die Zukunft?


von Stefan K. (oxid)


Lesenswert?

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

von Gelangweilter (Gast)


Lesenswert?

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

von duddelsack (Gast)


Lesenswert?

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

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


Lesenswert?

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

von sebastian (Gast)


Lesenswert?

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

von spess53 (Gast)


Lesenswert?

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

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von Frank K. (fchk)


Lesenswert?

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

von user (Gast)


Lesenswert?

ARM ist doch allgegenwärtig!
Das Hauptproblem für mich ist momentan das auflöten der Chips.

von Sam P. (Gast)


Lesenswert?

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.

von 123 (Gast)


Lesenswert?

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.

von sebastian (Gast)


Lesenswert?

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

von Launchpadfrage (Gast)


Lesenswert?

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.

von Launchpadfrage (Gast)


Lesenswert?

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.

von H.Joachim S. (crazyhorse)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von Sam P. (Gast)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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.

von Michael S. (rbs_phoenix)


Lesenswert?

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

von Uwe (Gast)


Lesenswert?

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.

von UR-Schmitt (Gast)


Lesenswert?

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.

von Random .. (thorstendb) Benutzerseite


Lesenswert?

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

von Strubi (Gast)


Lesenswert?

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.

von Hale (Gast)


Lesenswert?

sebastian schrieb:
> Ein wenig BWL sollte ein Ingenieur auch, oder gerade als Chef, schon
>
> haben.

Ist das eine Krankheit oder meinst du einen BMW?

von Peter D. (peda)


Lesenswert?

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

von Birne (Gast)


Lesenswert?

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.

von Ralph (Gast)


Lesenswert?

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.

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


Lesenswert?

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.

von Jorgen (Gast)


Lesenswert?

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

von Lötspitze (Gast)


Lesenswert?

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

von Birne (Gast)


Lesenswert?

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 ?

von stefan (Gast)


Lesenswert?

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

von Konrad S. (maybee)


Lesenswert?


von stefan (Gast)


Lesenswert?

Sorry hab es mit deutsch etwas schwer, in usa sind ja billionen die 
milliarden, es soll naturlich 4milliarden heissen

von Arc N. (arc)


Lesenswert?

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

von Michael S. (rbs_phoenix)


Lesenswert?

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.

von Lötspitze (Gast)


Lesenswert?

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.

von Fer T. (fer_t)


Lesenswert?

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

von Lötspitze (Gast)


Lesenswert?

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.

von Jörg S. (joerg-s)


Lesenswert?

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

von Paul Baumann (Gast)


Lesenswert?

ARM ist die Zukunft?

Das sage ich Dir -vor Allem, wenn man von der ARGE abhängig ist.

MfG Paul

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


Lesenswert?

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

von Rainer S. (rsonline)


Lesenswert?

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.

von Konrad S. (maybee)


Lesenswert?

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

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


Lesenswert?

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.

von Christian K. (Firma: Atelier Klippel) (mamalala)


Lesenswert?

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

von friedrich (Gast)


Lesenswert?

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

von Konrad S. (maybee)


Lesenswert?

Werden denn in der professionellen Entwicklung noch µCs im DIP-Gehäuse 
verwendet, z.B. für Prototypen, Klein(st)serien usw.?

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


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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

von Konrad S. (maybee)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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.

von friedrich (Gast)


Lesenswert?

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

von Detlev T. (detlevt)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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.

von friedrich (Gast)


Lesenswert?

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

von B. L. (b8limer)


Lesenswert?

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

von friedrich (Gast)


Lesenswert?

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

von Michael S. (rbs_phoenix)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von friedrich (Gast)


Lesenswert?

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

von Axel L. (axel_5)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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