STM32 für Einsteiger - der Artikel zum Krieg (µC Wahl)

Ja @ Markus Müller, wie wir gelernt haben

> Die LPC800 natürlich ... sind explizit 8-bit-Ersatz, während die
> STM32F4 High-End sind.

werden es auch die STM32 kaum zum würdigen Ersatz der guten AVRs bringen 
und lediglich weiter die Nische leistungshungriger Apps besetzen. Dabei 
handelt es sich ja meist um irgendeine Anwendung für Medien mit größeren 
Grafikdisplays- die gibts aber oft billiger im Laden :-) Die große Masse 
der Anwendungen ist nun mal MSR- und dafür sind die 8 Bitter dermaßen 
was von prädestiniert... Wenn aber dafür dann diversen LPCs 
Grundfunktionalitäten wie ADCs abgehen und ich auch sonst keine 
schlagenden Argumente in Beitrag "LPC800 existiert (fast) nicht in diesem Forum" 
finden kann dann sollte man seinen AVR Vorrat weiter pflegen- ein paar 
Cents hin oder her. Den Xmega habe ich trotz ein paar Cents mehr deshalb 
gewählt weil er auch dank vieler innovativer Features so ziemlich für 
alles zu gebrauchen ist was mit MSR zu tun hat und ich mich vor allem so 
auf genau einen Typ beschränken kann.

Embedded schrieb:

> Als Bastler kann man immer das nehmen, was man gerade bei Reichelt
> bekommt.

Wiegesagt man nimmt das was man wirklich  braucht und nicht das was 
einem irgendein Anbieter gerade über den Preis aufschwatzen will.

> Aber dann sollte man sich mit so absoluten Urteilen von
> Tauglichkeit von Prozessorfamilien einmal sehr zurückhalten.

Das werde ich ganz sicher nicht, egal ob man Controller XY nun in die 
Hand bekommt oder nicht. Das Netz & dieses Forum enthalten genug Infos 
um sich ein eigenen Urteil zu bilden. Das sollte sich hier niemand von 
einem "Profi" diktieren lassen!

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

Die Rede war von der Komplexität des Controllers an sich.

> Und da liegst du falsch. Komplexität wird durch Kapselung reduziert. Man
> schreibt genau einmal eine Bibliotheksfunktion und nutzt sie dann in zig
> verschiedenen Designs...

Die Rede war von der Komplexität des Controllers an sich.

> Außerdem: Was ist jetzt, wenn der Bastler nur den STM32F4 kennt?

Dann wird er in der Reihenfolge der Prioritäten seinem STM32 den Vorzug 
geben.
Wieviele Bastler aber mögen das sein? Sobald einmal erkannt ist daß es 8 
bittig einfacher, oft kleiner, stromsparender und günstiger zu lösen 
ist... na ich weiß nicht ;)

Markus Müller schrieb:
> C) trifft schon mal für den XMega nicht zu
>
> Wenn die ganzen AVR nur 1/4 kosten würde, dann wären die günstig und
> auch für die Zukunft in der Industrie interessant.
> Aber so werden die weiterhin Marktanteile verlieren und wohl wird Atmel
> den ein oder anderen Typ nicht mehr herstellen.
> Auch sollte Atmel endlich mal Debugger verkaufen, die Preislich um die
> 20..30 Euro kosten (und wenigstens ein PVC Gehäuse zum Schutz haben).
> Wenn Atmel nicht bald reagiert sind die ganz schnell weg. Atmel/AVR ist
> einfach viel zu teuer für das was die leisten. Das war vor 10 Jahren
> noch anders, aber die Konkurrenz schläft nicht. Daher ist es jetzt an
> der Zeit AVR Goodbye zu sagen - zumindest für neue Desings.
>
> Für dich, Moby, hoffe ich dass du einen 30-Jährigen Vorrat an AVR's
> hast, incl Ersatz Debugger falls deiner abraucht.

Warum soll der debugger denn 30 euro kosten und nich 10 oder 50? Mal 
sehen was es zur embedded neues gibt aber ich sehe keinen grund dem avr 
noch pic goodbye zu sagen. Weder kann irgendeine firma die 
produktpalette von atmel odr mchip abdecken. Wobei atmel die einzige 
firma ist welche die zwei populaersten cores besitzt. Und es wird nicht 
nur in cortex sondern auch weiterhin in avr investiert wie den tiny841 
oder xmegae. Es soll sogar neue atmega und xmega geben (quelle:ineltek).
Zurueck zum debugger:jede firma die eine vernuenftige projektplanung 
hat, hat auch entsprechendes budget fuer tools. Ob fuer compiler, stacks 
oder hardware. Dann ist es egal ob der debugger 100$kostet oder man 
2500$ fuer lauterbach braucht.
Und avr zu 1/4: die preisgestaltung bei reichelt oder digikey macht 
nicht atmel. Der tiny88 kostet bei atmel ueber normalen disti bei 
lediglich 1000st unter 30cent! Und das im qfn package. Farnell verlangt 
bei dieser abnahmemenge 4x soviel waehrend mouser nur 25% draufschlaegt. 
Und jetzt willst du behaupten atmel sei teuer? Ich wuerde sagen der 
distributor, aber ich wuerde es nicht uebel nehmen. Offensichtlich kann 
farnell diesen preis halten aus bestimmten gruenden. Kein hersteller 
schreibt einem haendler vor wieviel der chip kosten soll, denn in der 
preisgestaltung ist der disti allein. Uebrigens waere es anders, stuende 
es mit dem eu recht in konflikt.

Moby schrieb:
> Sobald einmal erkannt ist daß es 8 bittig einfacher

Genau, mit 16-bit Adressbus, mehrere 8-bit Register pro Port für die 
Funktionswahl und interne Pulls, 10-bit ADC mit 8-bit High/Low 
Registern. Und der Xmega toppt das noch.

> Wieviele Bastler aber mögen das sein? Sobald einmal erkannt ist daß es 8
> bittig einfacher, oft kleiner, stromsparender und günstiger zu lösen
> ist... na ich weiß nicht ;)

Das mit dem "einfacher" ist so eine Sache. Ich habe mal ein und dieselbe 
Anwendung programmiert. Einmal auf einem AVR und einmal auf einem stm32.

Auf dem AVR musste ich Handstände machen um das Timing einzuhalten. Ich 
musste jede Division in Bitshifts umwandeln und kompliziert 
herumwursteln. Das war ein Kraftakt, denn für jede simple Berechnung 
brauchte der AVR hunderte Takte.

Beim stm32 konnte ich dank FPU und 32 Bit die zu berechnende Formel 
einfach hinschreiben (ohne mich um das Timing kümmern zu müssen). Ich 
konnte sie 1:1 aus dem Tabellenbuch entnehmen! Bei dem AVR undenkbar. 
Der war viel zu langsam. In diesem Fall war also der stm32 eine echte 
Vereinfachung. Gradezu ein Traum.

Was den Preis betrifft: Das stm32-Board hat ich 12 Euro gekostet. Der 
AVR-Programmer (ohne Debuggingfunktion) über 30 euro... und dazu dann 
nochmal die AVR-Platine hmmmm....

Also ich bin danach komplett umgestiegen.

Moby schrieb:
> Die Rede war von der Komplexität des Controllers an sich.

Die Komplexität des Controllers an sich interessiert niemanden. Bestes 
Beispiel:

Lusi-Flusi-Popusi schrieb:
> Beim stm32 konnte ich dank FPU und 32 Bit die zu berechnende Formel
> einfach hinschreiben (ohne mich um das Timing kümmern zu müssen). Ich
> konnte sie 1:1 aus dem Tabellenbuch entnehmen! Bei dem AVR undenkbar.
> Der war viel zu langsam. In diesem Fall war also der stm32 eine echte
> Vereinfachung. Gradezu ein Traum.

Eine FPU macht den Controller an sich natürlich viel komplexer. Die 
Anwendung wird aber plötzlich um ein vielfaches einfacher, weil man sich 
Fixed-Point-Operationen mit umständlicher Bitschieberei spart.

Gleiches gilt für die Peripheriematrix. Der Controller wird natürlich 
komplexer, aber die Anwendung wird viel, viel einfacher, weil man sich 
keine Gedanken mehr um Doppelbelegung und die Verschaltung der Pins 
kümmern muss. Und ich kann das Boardlayout optimieren, weil ich ja die 
Pins frei verteilen kann. Das senkt auch noch einmal die Komplexität.

Gleiches gilt für Bibliotheksfunktionen. Die machen das Programm an sich 
auch erst einmal komplexer (mehr LOC). Aber die Anwendung wird viel, 
viel einfacher.

Weitere Beispiele: Debugging. Eine Debugeinheit macht den Controller 
komplexer. Aber man kann die internen Abläufe seines Programms besser 
nachvollziehen. Ergo: Die Entwicklung mit dem Prozessor wird um ein 
vielfaches einfacher und schneller.

Moby schrieb:
> Das werde ich ganz sicher nicht, egal ob man Controller XY nun in die
> Hand bekommt oder nicht. Das Netz & dieses Forum enthalten genug Infos
> um sich ein eigenen Urteil zu bilden. Das sollte sich hier niemand von
> einem "Profi" diktieren lassen!

Ich habe dir doch schon gesagt, dass du als Bastler nehmen kannst, was 
du willst. Du liegt aber nur mit deinem Urteil über 8-Bitter und 
32-Bitter einfach falsch, weil in der echten Welt Faktoren zählen, die 
du nicht siehst, nicht verstehst, nicht akzeptierst.

Das ist ein bischen wie bei den PCs. Jede paar Jahre steigt die 
Komplexität an. Das ganze geht sogar exponentiell! Und wird die 
Bedienbarkeit komplizierter? Durch Komplexität auf der unteren Ebene 
werden Abstraktionsebenen möglich, welche die Handhabbarkeit auf höheren 
Ebenen vereinfacht.

Das ist der Weg in die Zukunft! Eine Tages werden Microcontroller ein 
eigenes Bewusstsein entwickeln und wir können uns mit ihnen über unser 
neues angestrebtes Projekt unterhalten.

Dann wirft man nur noch einen Löffel Nanoroboterbrei auf den Tisch und 
das Ganze formt sich von selber zur fertigen Anwendung. :-))

;)

Markus Müller schrieb:
> ATTiny88 @6000 = 0.38932:
> http://www.digikey.de/product-detail/de/ATTINY88-MUR/ATTINY88-MURTR-ND/2357456
>
> STM32 @10000 = 0,423:
> 
http://at.mouser.com/ProductDetail/STMicroelectronics/STM32F030F4P6/?qs=sGAEpiMZZMuoKKEcg8mMKOHkam7XjJnw3SF6NWq8tIw%3d
>
> LPC @10000 = 0,571
> 
http://at.mouser.com/ProductDetail/NXP-Semiconductors/P89LPC912FDH129/?qs=sGAEpiMZZMvu0Nwh4cA1wUhXb1nJ%2ffVjnn%252bGVGFQ7w8%3d
>
> Nur mal so zum Vergleich mit echten Preisen.
> Somit ist der ATTiny88 um VIELES teurer. Man muss dafür extra eine
> zertifizierte IDE kaufe, Extra Produkt evaluieren und Extra Code
> schreiben, das kostet alleine schon minimum 10000€. Und die Differenz
> zum STM32 ist nur 0,03368€. Solange man keine knapp 300000 von den
> ATTiny's verbaut ist der STM32 immer noch am günstigsten - sofern man
> den für alle Applikationen nutzt.
>
> Tschüss AVR - die Sonne ist bereits jetzt schon untergegangen. ;-)

du vergleichst hier ein billiges tssop 20pin package gegen ein QFN 
package/32pin
kein 5V
kein low power
kein eeprom
dein LPC ist übrigens ein 8Bit ;-)

und wie gesagt, die preise bei catalogue distis kannst du nicht 
vergleichen, das ist die alleinige Entscheidung des Händlers für wieviel 
der Chip verkauft werden soll. Offensichtlich kann Farnell noch viel 
teurer verkaufen, selbst über 1euro bei tausend stück kann man den 
tiny88 verkaufen, anscheinend stimmt das Preis Leistungsverhältnis
Du kannst nicht atmel dafür verantwortlich machen dass die Händler einen 
Chip der im Einkauf unter 30cent ($Cent!) zu haben ist für 1.3Euro 
verkaufen. Preisgestaltung ist alleinige Sache des Händlers. Der 
Hersteller darf in EU die Preise nicht diktieren (EU Recht).
Deshalb gibt es eine UVP.

martin schrieb:
> dein LPC ist übrigens ein 8Bit ;-)

Ein 8-bit mit "kein 5V, kein low power, kein eeprom" :-)

Aber der ARM Nachfolger ist in Stückzahlen sogar billiger:

http://at.mouser.com/ProductDetail/NXP/LPC811M001JDH16FP/?qs=%2fha2pyFadughkC6y8Cf7vNIsk%2fhKzqGG0YLiBFrcrl0%3d

5V ist ihhh. Nutze ich schon lange nicht mehr.

Markus Müller schrieb:
> Embedded schrieb:
>> Und ich kann das Boardlayout optimieren, weil ich ja die
>> Pins frei verteilen kann.
>
> - Einfacheres Layout
> - Weniger Kreuzungen der Leiterbahnen
> - EMV-Verträglichkeit (CE) viel leichter einhaltbar
>  >> Kleinere Platine und somit deutlich weniger Kosten!

Na das ist ja schon dermaßen an den Haaren herbeigezogen... Aber sei Dir 
gegönnt.

Moby schrieb:
> Na das ist ja schon dermaßen an den Haaren herbeigezogen... Aber sei Dir
> gegönnt.

Nein, das ist nicht an den Haaren herbeigezogen, es übersteigt nur 
einfach deine Vorstellungskraft. Du hast ganz offensichtlich noch nie 
ein Leiterplattenlayout gemacht.

Oh Wunder hab auch eine Art Hausnetz das schon mehr als 6 Jahre super 
läuft, getrieben noch von einem Mega128. Das steinalte Draht- CAN 
braucht es nicht, geht alles modern via Funk ;)
Ist schon OK daß Du Deinen STM so verteidigst und alles damit machst, 
prinzipiell teile ich ja die Begeisterung für MCs. Aber ich 
wiederspreche vehement wenn mir jemand 32er HighEnd Boliden als 
legitimen Nachfolger der einfachen AVRs verkaufen will.

Embedded schrieb:
> Moby schrieb:
>> Na das ist ja schon dermaßen an den Haaren herbeigezogen... Aber sei Dir
>> gegönnt.
>
> Nein, das ist nicht an den Haaren herbeigezogen, es übersteigt nur
> einfach deine Vorstellungskraft. Du hast ganz offensichtlich noch nie
> ein Leiterplattenlayout gemacht.

8 Pin Designs so eine Wissenschaft? Ich glaub ich krieg gleich nen 
Lachkrampf. Wie schaff ich das bloß mit den TQFP32ern meiner Xmegas ???

Moby schrieb:
> 8 Pin Designs so eine Wissenschaft? Ich glaub ich krieg gleich nen
> Lachkrampf. Wie schaff ich das bloß mit den TQFP32ern meiner Xmegas ???

Sei froh, dass du als simpler Bastler keine EMV-Tests machen musst und 
in herrlich störarmen Umgebungen arbeiten darfst. Wenn dein Zeug in 
einem Industrieschaltschrank laufen muss, wo Leistungselektronik mit 
mehreren 100 Ampere und 10 kV/us neben deinen Signalleitungen 
herumschalten, würdest du vermutlich etwas anders darüber denken.

Chris D. schrieb:
> Aber es wird nichts am Lauf der Dinge ändern. Die Industrie wird bei den
> rasant fallenden Preisen mehr und mehr 32-Bitter einsetzen, eben weil
> man mit so einer Architektur wie ARM alles vom Blinklicht bis zum
> Touchscreen erschlagen kann. Es wird der Zeitpunkt kommen, wo man eben
> einen 32-Bitter für einen Piepser verwendet, einfach weil es preislich
> wurscht ist.

So sieht es aus.

Chris D. schrieb:
> Natürlich interessiert das Hobbybastler nicht - aber andersherum
> interessiert das wiederum die Hersteller nicht.

Bastler sind nur dann interessant, wenn sie potentielle 
Stückzahlenkunden werden. Also Studenten und professionelle 
Hardwareentwickler, die in ihrer Freizeit noch basteln.

Chris D. schrieb:
> Wenn mit 32-Bittern wesentlich mehr Umsatz und vor allem Gewinn zu
> machen ist (und die Margen sind da jetzt schon deutlich höher), dann
> wird der hersteller sich darauf konzentrieren.

Genau. Im Moment geben viele Hersteller die Entwicklung von ihren 
eigenen Kernen auf. Vor allem im Low-Cost-Bereich, in denen sich die 
8-Bitter tummeln, lohnt sich das einfach nicht mehr. Da ist es billiger, 
einen Standard-Kern (eben den M0) zu lizenzieren.

Embedded schrieb:
> Chris D. schrieb:
> Genau. Im Moment geben viele Hersteller die Entwicklung von ihren
> eigenen Kernen auf. Vor allem im Low-Cost-Bereich, in denen sich die
> 8-Bitter tummeln, lohnt sich das einfach nicht mehr. Da ist es billiger,
> einen Standard-Kern (eben den M0) zu lizenzieren.

Sicher. Deshalb führt Atmel mit den Xmegas ja auch eine neue Reihe ein- 
oder gerade jüngst zwei neue Tinys. Man kann hier viel prophezeien. Und 
ich prophezeie, die 8 Bitter behalten ihre Rolle. Todgesagt werden sie 
ja schon lange ;)

Moby schrieb:
> Sicher. Deshalb führt Atmel mit den Xmegas ja auch eine neue Reihe ein-
> oder gerade jüngst zwei neue Tinys. Man kann hier viel prophezeien. Und
> ich prophezeie, die 8 Bitter behalten ihre Rolle. Todgesagt werden sie
> ja schon lange ;)

So etwas fällt unter Modellpflege. Natürlich kann Atmel noch problemlos 
neue Derivate mit bereits vorhandenen Kernen herausbringen, weil es ja 
auch noch viel Legacy-Code gibt, den ihre Kunden in neuen Projekten 
weiterverwenden wollen. Die Preisfrage ist: Welche Bemühungen steckt 
Atmel in die Weiterentwicklung des Kerns? Die XMEGA sind jetzt ja schon 
ein paar Jahre alt, der 32-Bit-Boom hat aber erst vor 1-2 Jahren 
überhaupt angefangen, das war zur XMEGA-Zeit noch gar nicht so 
abzusehen.

Übrigens: Falls es dir entgangen ist, wurde in der gleichen Zeit ein 
neuer M0 und viele M4-Typen eingeführt.

Chris D. schrieb:
> Es wird der Zeitpunkt kommen, wo man eben
> einen 32-Bitter für einen Piepser verwendet, einfach weil es preislich
> wurscht ist.

Genau. Und der erforderliche Code hat dann 20 MB...
Kommen Dir  bei solchen Vorhersagen keine Zweifel?
Soll das der Weisheit letzter Schluß sein?

Moby schrieb:
> Deshalb führt Atmel mit den Xmegas ja auch eine neue Reihe ein-
> oder gerade jüngst zwei neue Tinys.

Deshalb läuft auf http://www.atmel.com/ erst mal Werbung für den M4 - 
und unter Products > Microcontrollers läuft Werbung für den M0+

Wobei allerdings der AVR-Markt am Leben erhalten wird, dadurch dass es 
den kleinsten ATSAMD20 mit 16KB Flash und 2KB RAM erst ab 64er Package 
gibt (bei NXP gibt es M0+ ab 8er Package).

Moby schrieb:
> Und der erforderliche Code hat dann 20 MB...

Es wurde ja hier schon gezeigt, dass M3-Code i.d.R. kleiner als AVR-Code 
ist, und M0-Code etwas größer. Das liegt daran, dass beim M3 alle 
Befehle bedingt ausgeführt werden können, und so kaum Jumps benötigt 
werden, und dass durch Bitbanding direkt auf die Ports zugegriffen 
werden kann (wie beim AVR auch).

Der M0 kann das nicht, und um M0-Code kleiner als AVR-Code zu bekommen 
wurde beim LPC zu einigen Tricks gegriffen: es gibt für die Ports 
Toggle-Register und ROM-Treiber (USART, I2C, USB)

> Und der erforderliche Code hat dann 20 MB...

Stimmt das? Ich hätte jetzt gedacht, dass ich für einen 8bit unter 
Umständen mehr Code brauche. Der muss ja zB. für eine Berechnung viel 
mehr Schritte durchführen als ein 32bit der zB. auch noch ne FPU und DMA 
hat.

Chris D. schrieb:
> Die 32-Bitter werden sich einen Preiskampf liefern und die 8-Bitter
> werden dann zwischen 0 und 1€ (bzw. dann den billigsten 32-Bittern)
> zerdrückt

Na schaun mer mal wer Recht behält. Das Forum gibts ja hoffentlich noch 
ne Weile, dann werd ich Dir in 5 Jahren diese Aussage nochmal unter die 
Nase reiben- äh pupXXX :)

Falk Brunner schrieb:
>>Wenn mit 32-Bittern wesentlich mehr Umsatz und vor allem Gewinn zu
>>machen ist (und die Margen sind da jetzt schon deutlich höher),
>
> Sicher? Ist es nicht eher ein halbleitertypischer, gandenloser
> (Verdrängungs)Preiskampf? Wenn ein Prozess bzw. ein Produkt in großer
> Menge erstmal läuft, wird es gnadenlos ausgesaugt und die Margen gehen
> bis an die Schmerzgrenze runter. Schau dir die aktuellen Preise an!

ack! und dann geht es los: übernahmen, ausgliederungen, entlassungen 
(siehe Renesas). wenn ein hersteller über den preis versucht 
marktanteile zu gewinnen, hat er wohl nichts anderes zu bieten. die 
32bit umsätze sind deswegen so hoch da der asp (average sales price) 
höher liegt als für die 8Bitter. Wenn 8bit günstiger wird, ist doch klar 
dass dann noch viel mehr verkauft werden muß um den level zu halten.
8bit applikationen wie sensorik/steuerungen bleiben 8bit, 32bit für 
TCP/IP, high-end stacks, touchscreens - wobei da ist ein BOM mit einem 
kleinen ARM9 für 4$ (z.b. sam9n12) + sdram und flash deutlich billiger 
als ein stm32f4 tft controller der an seiner Leistungsgrenze liegt. Da 
nimmt man dann gliech ARM9/CortexA + Linux und lässt die High-End MCU 
wie STM32F4 links liegen :>

Falk Brunner schrieb:
> Irgendwann schon, aber nicht sooo bald. Da reden wir vielleicht von
> 10-20 Jahren 8051 lebt auch schon ewig.

Aber auch nur gerade so. Außerdem: Bis vor zwei Jahren gab es auch noch 
keine ernsthafte Konkurrenz zu 8-Bittern im unteren Leistungsbereich.

Falk Brunner schrieb:
> Bisher war es ausreichend, VORHER mal den Kopf
> einuschalten und die Pinbelegung passend zu wählen.

Das hilft aber auch nichts, wenn man dann einen größeren Prozessor 
braucht oder für 10 Designs 5 verschiedene Teile einführen muss.

Moby schrieb:
> Na schaun mer mal wer Recht behält. Das Forum gibts ja hoffentlich noch
> ne Weile, dann werd ich Dir in 5 Jahren diese Aussage nochmal unter die
> Nase reiben- äh pupXXX :)

In fünf Jahren wirst du verzweifelt noch einzelne 8-Bitter suchen, die 
irgendwo noch in Legacy-Produkten eingesetzt werden, nur um dein 
Argument zu gewinnen.

martin schrieb:
> ack! und dann geht es los: übernahmen, ausgliederungen, entlassungen
> (siehe Renesas).

Die Übernahmewelle ist schon in vollen Gange (Luminary->TI, Energy Micro 
-> Silicon Labs, Fujitsu -> Spansion).

martin schrieb:
> 8bit applikationen wie sensorik/steuerungen bleiben 8bit, 32bit für
> TCP/IP, high-end stacks, touchscreens

Nein, typische 8-Bit-Anwendungen werden zunehmend von M0 besetzt.

martin schrieb:
> wobei da ist ein BOM mit einem
> kleinen ARM9 für 4$ (z.b. sam9n12) + sdram und flash deutlich billiger
> als ein stm32f4 tft controller der an seiner Leistungsgrenze liegt. Da
> nimmt man dann gliech ARM9/CortexA + Linux und lässt die High-End MCU
> wie STM32F4 links liegen :>

Mit einem ARM9 kannst du heute niemandem mehr hinter dem Ofen 
hervorlocken. Hoffnungslos veraltet und lahm. Manchmal werden zwar 
300-400 Mhz erreicht und das klingt toll, aber der ARM9 hat eine miese 
IPC, der Befehlssatz ist nicht sehr leisstungsstark und der 
Stromverbrauch ist hoch. Warum ein ARM9 Dinge problemlos schaffen 
sollte, die einen Cortex-M4 an die "Leistungsgrenze" bringen, ist nicht 
schlüssig.

Wenn's ein großes OS wie Linux sein muss, dann ist das wieder ein ganz 
anderes Kaliber und man braucht viel RAM und Flash, kann mir im Leben 
nicht vorstellen, dass das billiger als ein integrierter 
High-End-Mikrocontroller wird. Vor allem steigt die Komplexität ins 
Unermessliche.

martin schrieb:
> wobei da ist ein BOM mit einem
> kleinen ARM9 für 4$ (z.b. sam9n12) + sdram und flash deutlich billiger
> als ein stm32f4 tft controller der an seiner Leistungsgrenze liegt. Da
> nimmt man dann gliech ARM9/CortexA + Linux und lässt die High-End MCU
> wie STM32F4 links liegen :>

Weder die BOM-Kosten dürften zu halten sein, selbst wenn man die 
Platinenfläche ausser Acht lässt, noch die Leistungsaufnahme. Ausserdem 
kommt der STM32F429 kommt bei 180Mhz schon auf die 600 CoreMarks die der 
SAM9N12 bei 400Mhz erst erreicht. Und da ist die DSP-Extension noch 
garnicht berücksichtigt.

Wer sich für die Codesize-Frage interessiert sollte unbedingt folgenden 
Artikel lesen:
http://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_(full).pdf

Embedded schrieb:

> Falk Brunner schrieb:
>> Bisher war es ausreichend, VORHER mal den Kopf
>> einschalten

Dafür würde ich auch plädieren.

> In fünf Jahren wirst du verzweifelt noch einzelne 8-Bitter suchen, die
> irgendwo noch in Legacy-Produkten eingesetzt werden, nur um dein
> Argument zu gewinnen.

Prima. Noch so eine hochfliegende Prophezeiung auf die sich wunderbar 
festnageln lässt. Ich nehme aber an in 5 Jahren bist Du dann nicht mehr 
unter Deinem heutigen Gastnamen erreichbar ;)
Die Protagonisten des aufgehenden 32 Bit Strohfeuers werden sich noch 
wundern: In 5 Jahren zerrieben zwischen ARM/64 High End und 8 Bit für 
die Alltags-MSR...

> Nein, typische 8-Bit-Anwendungen werden zunehmend von M0 besetzt.

Kurz nach Erscheinen nimmt es ja  nicht wunder das damit ein paar 
Prozent des Marktes besetzt werden. Es ist doch sehr die Frage wielang 
der Trend anhält, dazu haben sie gegenüber den Branchengrößen AVR & PIC 
viel zuwenig zu bieten was zum Umstieg motivieren könnte.

Embedded schrieb:
> Weitere Beispiele: Debugging. Eine Debugeinheit macht den Controller
> komplexer. Aber man kann die internen Abläufe seines Programms besser
> nachvollziehen. Ergo: Die Entwicklung mit dem Prozessor wird um ein
> vielfaches einfacher und schneller.

Tja Embedded man sollte schon unterscheiden zwischen Komplexität die 
sich auf die Funktion auswirkt (verkompliziert) und solcher, die quasi 
nur dem "Service" dient.

Moby schrieb:
> Branchengrößen AVR & PIC

In der Bastler-Branche :-)

Laut Microcontroller Market Report hat 8051 immer noch den größten 
Marktanteil nach Stückzahlen, dann kommt ARM und danach PIC. AVR wird 
nur noch unter "Others" geführt ...

Embedded schrieb:
> Debugging. Eine Debugeinheit macht den Controller
> komplexer.

http://dangerousprototypes.com/2014/01/25/pic16f1454-used-as-inexpensive-arm-debugger/

Ist mir wurscht, wer den größten Marktanteil hat. Für mich geht es eher 
darum, möglichst viel ohne Float zu erledigen.
Da sind momentan noch die 32-er am Drücker, die Integer-Arithmetik mit 
den 8-Bittern ist bei den heutigen (Integer!)-Präzisionen der meisten 
Sensoren eh am Ende der Laufbahn angelangt.
So sollte man das sehen, finde ich:
Was an Präzision soll rein, was soll raus. Und das so schnell wie 
möglich. Würde mich auch notfalls in 64-Bitter einarbeiten. Aber aus 
irgendeinem blöden Gefühl heraus möchte ich nicht schneller den eigenen 
Programmcode compilieren können, als das der PC für mich tut :p

Lothar schrieb:
> Moby schrieb:
>> Branchengrößen AVR & PIC
>
> In der Bastler-Branche :-)
>
> Laut Microcontroller Market Report hat 8051 immer noch den größten
> Marktanteil nach Stückzahlen

Wirklich? Na wie oft wurden die erst totgesagt... Anscheinend spielen 
doch noch ein paar Gründe mehr mit im Konzert der Controllerauswahl, als 
es die 32 Bit Fraktion glauben machen möchte :-)

Moby schrieb:
> Lothar schrieb:
>> Moby schrieb:
>>> Branchengrößen AVR & PIC
>>
>> In der Bastler-Branche :-)
>>
>> Laut Microcontroller Market Report hat 8051 immer noch den größten
>> Marktanteil nach Stückzahlen
>
> Wirklich? Na wie oft wurden die erst totgesagt... Anscheinend spielen
> doch noch ein paar Gründe mehr mit im Konzert der Controllerauswahl, als
> es die 32 Bit Fraktion glauben machen möchte :-)

Ja, aber wie lange noch?
Ich als Bastler muß nicht vorausschauen, aber als Profi kann man doch 
nicht vernachlässigen, daß die Gehäusegrößen, die Rechenpower, alles 
Physikalische dafür spricht, in einem Register mehr als 8 Bit 
unterzubringen?

Insofern geht es meiner Meinung nach eher darum, gute Bibliotheken und 
Archive, die sich unter AVR, PIC, MC68HC11, Z80 ;) inzwischen etabliert 
haben, auf die neuen Erfordernisse umzustellen.
Es ist nicht die Frage des WANN?, sondern des Warum NICHT?
Mann kann das irgendwelchen dahergelaufenen BWL-ern überlassen, aber 
warum sollte man das als Ingenieur tun, wenn man das Ende der 8-Bitter 
schon klar sehen ann?

Habe die 8051er vergessen.

Allerdings aus gutem Grund: Irgendwann mal kurz nach'm Krieg kam die 
große Idee, "EZ" mit "easy" abzukürzen. Hoho. War ne gute Idee, ging 
aber bei mir fürchterlich - zumindest bei den kleineren 8-Bittern von 
Cypress (AN2131, 2135, FX2 (klein?)) - in die Hose. Damals hatte ich 
noch Win98, da liefen die Treiber und man konnte die Chips hinreichend 
kontrollieren, um TATSÄCHLICH den momentanen RAM-Inhalt in den PC zu 
transportieren. Es reichte sogar, um DACs und ADCs auf atomarer Ebene zu 
kontrollieren. War fast wie beim ISA-Bus, nur bißchen schneller. Nur, 
unter XP lieferten die Dinger meist nur noch einen Device I/O-error. 
Wahrscheinlich war ich zu blöd, ok.
Aber auch nicht bei jedem Rechner; es hing vom USB-Port ab. Und vom 
Treiber, von denen ca. 4-5 verschiedene kursierten, und der von Cypress 
- original - funktionierte generell nicht mehr unter XP - kein gutes 
Zeichen. Bei "EZ" hatte ich mich auf ein kinderleichtes Zusammenspiel 
von RAM im AN213x und PC verlassen, stattdessen war der Scheiß ein 
Vabanque-Spiel. Mal ging's, mal nicht.

Das hat natürlich nichts mit dem 8051-er Core zu tun.

Außer, daß ich danach auf AVR umgestiegen bin. Und dann eben kürzlich 
auf STM32. Wer sich im Zwischenbereich befindet, also bei 16-Bittern 
oder bei extrem Low-Power-Anwendungen, mag ebendiese Gründe dafür haben, 
die aber auch nicht mehr lange standhalten.

Moby schrieb:
> Es ist doch sehr die Frage wielang
> der Trend anhält, dazu haben sie gegenüber den Branchengrößen AVR & PIC
> viel zuwenig zu bieten was zum Umstieg motivieren könnte.

Klar bieten 32Bitter für dich nichts, weil du in deiner 8-Bit-Welt fest 
hängst und aus deiner kleinen Bastlersicht einfach nicht hinaus kommst.. 
Die Industrie rennt im Moment in Massen zum 32-Bit, weil die kleinen ARM 
fast nur Vorteile haben und dabei billiger sind. Hier wurden ja schon 
tausende Beispiele genannt, aber das alles glaubst du ja nicht.

Moby schrieb:
> Tja Embedded man sollte schon unterscheiden zwischen Komplexität die
> sich auf die Funktion auswirkt (verkompliziert) und solcher, die quasi
> nur dem "Service" dient.

Ach ja, jetzt plötzlich. Vorhin hast du nur gesagt, für dich zählt nur 
die Komplexität des Controllers an sich. Du kannst dir deine Aussagen 
natürlich immer so drehen, wie du willst. Fakt ist, dass folgende 
Einheiten die Komplexität des Controllers erhöhen aber die Anwendung 
vereinfachen:
- Frei konfigurierbare Peripheriematrix (nicht zu verwechseln mit nicht 
frei konfigurierbaren Alternativfunktionen)
- DMA
- Debuggingeinheit
- Floatingpoint-Einheit
- Hardwaremultiplizierer/Hardwaredivider
- Integrierte LCD-Controller und Ethernet-MAC, die dedizierte Chips 
ersetzen

Auf Softwareseite erhöhen Bibliotheken und Betriebssysteme auch die 
Komplexität, können die Anwendung und die Wartung auch einfacher machen, 
wenn sie richtig umgesetzt werden. Auch hier ist der Bastlermarkt aber 
nicht repräsentativ.

Lothar schrieb:
> Laut Microcontroller Market Report hat 8051 immer noch den größten
> Marktanteil nach Stückzahlen, dann kommt ARM und danach PIC. AVR wird
> nur noch unter "Others" geführt ...

Renesas und Freescale sind umsatztechnisch weit vor Microchip und Atmel, 
und zwar mit Prozessoren, die zumindest hierzulande kein Bastler kennt. 
Das sind die wahren Branchengrößen.

8051 sind natürlich noch ganz vorne, weil die früher einfach von jedem 
Hersteller gebaut worden:

http://en.wikipedia.org/wiki/Intel_MCS-51#Derivate_vendors

Außerdem wird der 8051 gerne in IC als Hilfsprozessor verbaut, der 
häufig noch nicht einmal für den Nutzer zugänglich ist, zum Beispiel in 
digitale Schaltregler oder in Bluetoothcontrollern. Der Vorteil des 
Kerns ist, dass man ihn auch in "analogen" Halbleiterprozessen in einer 
vernünftigen Fläche fertigen kann. Und das ist auch der einzige Bereich, 
in denen ich in 5-10 Jahren überhaupt noch 8-Bitter erwarten würde. 
Trotzdem: Inzwischen setzt z.B. TI dort auch ihren MSP430 ein.

Beim M0 liest sich die Liste auch schon ähnlich, und das obwohl es ihn 
erst seit 2 Jahren gibt. Die Liste ist nur kürzer, weil sich der Markt 
inzwischen konsolidiert hat und viele Hersteller auf der 8051-Liste gar 
nicht mehr existieren. Im Prinzip alle großen Hersteller bieten 
inzwischen Cortex M0 µC an (inklusive den echten Branchengrößen wie 
Freescale und Infineon), Ausnahmen sind Renesas und Microchip. Ich würde 
aber mal davon ausgehen, dass erstere sich aus dem Kleinprozessormarkt 
zurückziehen und sich eher auf ihre größeren DSP konzentrieren und 
letztere in den nächsten 2-5 Jahren mit einem ARM-Produkt nachziehen.

Außerdem würde ich erwarten, dass die Chinesen demnächst mit einem 
kleinen 32-Bit-Kern nachziehen, womöglich sogar binärkompatibel zum ARM.

Embedded schrieb:
> Renesas und Freescale sind umsatztechnisch weit vor Microchip und Atmel

Im Gesamtumsatz aber nicht bei uC. Und grade Renesas macht ja keinen 
Gewinn damit und muss jedes Jahr von seinen Automotive-Kunden mit 
Krediten gerettet werden (kein Wunder bei 16 inkompatiblen uC-Kernen, 
die gepflegt werden müssen).

Embedded schrieb:
> Außerdem würde ich erwarten, dass die Chinesen demnächst mit einem
> kleinen 32-Bit-Kern nachziehen, womöglich sogar binärkompatibel zum ARM.

Die scheinen auf MIPS zu setzen ...

Markus Müller schrieb:
> Ich habe Renesas nur deshalb wieder weg geschmissen, weil
> es für mich im Hobby-Bereich den fast nicht zu kaufen gab, vom Chip
> selbst war ich zufrieden.

Das wundert mich jetzt aber. Du redest doch hier von 1000er Stückzahlen 
und schaffst es nicht einmal, ein Einzelstück zu besorgen?
Pantoffelprofi, wa?

Embedded schrieb:
> Fakt ist, dass folgende
> Einheiten die Komplexität des Controllers erhöhen...

Na also. Darauf lässt sich ja schon mal aufbauen.

Embedded schrieb:
> Auf Softwareseite erhöhen Bibliotheken und Betriebssysteme auch die
> Komplexität,

Deshalb alles konsequent in Asm. Das ist und bleibt das Einfachste.
Und dafür sind die ARMs kaum noch konzipiert.

Embedded schrieb:
> können die Anwendung und die Wartung auch einfacher machen,
> wenn sie richtig umgesetzt werden.

Na wenn da nicht die oft/meist kompliziertere Programmierung mit dem
Zaunpfahl winkt ;) Und selbst wenn es "richtig" umgesetzt wird- hat Dir
jemand Dein Wissen darüber unters Kopfkissen gelegt? War wahrscheinlich
auch ein langer Weg über Studium usw. Dieses notwendige Wissen geht dann
aber auch in die Gesamt-Aufwandsbilanz ein. Ein Aufwand der eben für
viele Anwendungen völlig unverhältnismäßig ist.Unter dem Strich
jedenfalls ist und bleibt das Gesamtpaket bei 8-Bit das Einfachste- und
es ist schlicht lächerlich das abzustreiten.

Embedded schrieb:
> weil du in deiner 8-Bit-Welt fest
> hängst und aus deiner kleinen Bastlersicht einfach nicht hinaus kommst..

Die "kleine Bastlersicht" ermöglicht schlicht das Optimum von Aufwand &
Nutzen. Finds ja auch bedauerlich daß der Industrie-Entwickler sehr viel
mehr zu beachten hat, z.B.

Embedded schrieb:
> Sei froh, dass du als simpler Bastler keine EMV-Tests machen musst und
> in herrlich störarmen Umgebungen arbeiten darfst. Wenn dein Zeug in
> einem Industrieschaltschrank laufen muss, wo Leistungselektronik mit
> mehreren 100 Ampere und 10 kV/us neben deinen Signalleitungen
> herumschalten, würdest du vermutlich etwas anders darüber denken.

Dennis S. schrieb im Beitrag #3505304:
> Deshalb alles konsequent in Asm. Das ist und bleibt das Einfachste.
> Und dafür sind die ARMs kaum noch konzipiert.

Nein, ASM taugt allenfalls für Kleinstprojekte, selbst für einfachste 
Sensorikanwendungen taugt es einfach nicht, weil schlecht wartbar und 
schlecht portierbar. In der Industrie ist Assembler quasi ausgestorben, 
die µC-Welt spricht C. Und genau das ist ein Grund für die M0, die sich 
wunderbar in C programmieren lassen.

Dennis S. schrieb im Beitrag #3505304:
> Ein Aufwand der eben für
> viele Anwendungen völlig unverhältnismäßig ist.

Wenn an einem Softwareprojekt 5+ Leute arbeiten und der Code auch in 20 
Jahren noch verstanden werden soll, ohne großen Einarbeitungsaufwand, 
dann muss man sich über den Pflegeaufwand Gedanken machen. Ich habe im 
Beruf schon mehr als einmal gehört: "Das alte Programm war in Assembler, 
das werden wir noch einmal komplett in C neu schreiben, weil das 
schneller geht, als sich in den alten Code einzuarbeiten." Und ja, das 
gilt in erster Linie bei Kleinstprojekten, die man in < 1000 Zeilen 
C-Code realisieren kann.

Dennis S. schrieb im Beitrag #3505304:
> Unter dem Strich
> jedenfalls ist und bleibt das Gesamtpaket bei 8-Bit das Einfachste- und
> es ist schlicht lächerlich das abzustreiten.

Es ist aber immer noch falsch. Wieso soll 32 Bit per se komplexer sein? 
Der C-Code unterscheidet sich erst einmal kein bisschen. Wenn die 
Peripherie komplexer geworden ist, hat das erst einmal rein gar nichts 
mit 8, 16 oder 32 Bit zu tun. Wer die Peripherie von einem XC166 gesehen 
hat, versteht wovon ich rede.

Dennis S. schrieb im Beitrag #3505304:
> Die "kleine Bastlersicht" ermöglicht schlicht das Optimum von Aufwand &
> Nutzen. Finds ja auch bedauerlich daß der Industrie-Entwickler sehr viel
> mehr zu beachten hat, z.B.

Nur funktioniert die Sicht eben in der Industrie nicht mehr. Da gibt es 
andere Maßstäbe. Und Stückzahlen werden in der Industrie gemacht. Für 
die paar Bastler interessiert sich hinterher keiner mehr.

Trotzdem gibt es bei Bastlern im Moment den Trend, Anwendungen mit einem 
Raspberry Pi zu machen, die man auch mit einem Atmega erledigen könnte. 
Einfach weil man es kann, weil das Raspberry Pi für PC-User viel 
einfacher anzuwenden ist und weil es billiger ist (kostet so viel wie 
ein AVR ISP).

Embedded schrieb:
> Trotzdem gibt es bei Bastlern im Moment den Trend, Anwendungen mit einem
> Raspberry Pi zu machen, die man auch mit einem Atmega erledigen könnte.

Ist nur interessant wenn man die eingebaute Linux-Netzwerkfunktionalität 
nutzen möchte oder ein großes Display anschließen will

> Einfach weil man es kann,

Ja warum nicht, ist doch interessant, gerade für Internet-ansprechbare 
Anwendungen oder für Python-Anwender.

> weil das Raspberry Pi für PC-User viel einfacher anzuwenden ist

... ist vollkommener Käse. Das Linux bringt da dermaßen Komplexität 
rein, da sollte man schon ein wenig Knowhow mitbringen.

> und weil es billiger ist

Nur wenn man wirklich die gebotene Funktionalität nutzt,
sonst ist das genauso Quatsch.

Moby schrieb:
> Ist nur interessant wenn man die eingebaute Linux-Netzwerkfunktionalität
> nutzen möchte oder ein großes Display anschließen will

Das geht doch auch mit einem AVR!

Moby schrieb:
> Nur wenn man wirklich die gebotene Funktionalität nutzt,
> sonst ist das genauso Quatsch.

Das tun aber viele eben nicht. Erzähl mal das den Bastlern, dass das, 
was sie da tun, Quatsch ist.

Moby schrieb:
> ... ist vollkommener Käse. Das Linux bringt da dermaßen Komplexität
> rein, da sollte man schon ein wenig Knowhow mitbringen.

Nicht wirklich. Es gibt fertige Distributionen mit SD-Karten-Image. 
Programiert wird dann einfach in Python. Für einen PC-User ist das immer 
noch einfacher als sich mit uC-Registern herumzuärgern.

Moby schrieb:
> Deshalb alles konsequent in Asm. Das ist und bleibt das Einfachste.
> Und dafür sind die ARMs kaum noch konzipiert.

Da ARM vor AVR entwickelt wurde, auf 6502-Basis, wurde großer Wert 
darauf gelegt, Assembler einfach, logisch und mächtig zu machen. Dazu 
mal wieder der größte gemeinsame Teiler:

int gcd (int a, int b)
{ while (a != b)
  { if (a > b) a = a - b; else b = b - a; }
  return a; }

gcd
  CMPS R0, R1
  SUBGT R0, R0, R1  ; greater than >
  SUBLE R1, R1, R0  ; less or equal <=
  BNE gcd

Dasselbe in AVR-Assembler, vielleicht auch noch für 16-bit Integer - 
kann man vergessen.

Allerdings will die Mehrheit der Embedded-Entwickler in der Industrie 
Assembler nicht mehr anfassen, daher wurde der Cortex-M auf C optimiert, 
selbst der Startup-Code "kann" in C gemacht werden.

Embedded schrieb:
> Das tun aber viele eben nicht. Erzähl mal das den Bastlern, dass das,
> was sie da tun, Quatsch ist.

Na da erkenne ich aber doch ein wenig die Neigung, das Wort im Munde 
umzudrehen, oder?

Quatsch ist natürlich nicht was Bastler tun sondern allein die Aussage 
der Raspi wäre billiger als eine Avr-Lösung

Embedded schrieb:
>> Unter dem Strich
>> jedenfalls ist und bleibt das Gesamtpaket bei 8-Bit das Einfachste- und
>> es ist schlicht lächerlich das abzustreiten.
>
> Es ist aber immer noch falsch. Wieso soll 32 Bit per se komplexer sein?

Irgendwie magst Du nicht recht verstehen was Gesamtpaket meint?
Was meinst Du wohl weswegen es soviele AVR/Pic-Entwickler, soviele 
Arduino-Entwickler usw. gibt? Ich glaube langsam die umfassende Sicht 
des Profis ist für gewisse Aspekte der Aufwandsbeurteilung und 
insbesondere das Motto "Keep it simple" blind... Aber gut, es gibt in 
der Industrie eben andere Prioritäten :)

Moby schrieb:
> Quatsch ist natürlich nicht was Bastler tun sondern allein die Aussage
> der Raspi wäre billiger als eine Avr-Lösung

Doch, das kann durchaus sein, je nachdem was man sich genau anschafft 
und welche Bezugsquellen man hat. Bei Reichelt kostet ein AVR ISP 
immerhin 36 Euro, dafür bekomme ich schon ein komplettes Raspberry Pi.

Moby schrieb:
> Irgendwie magst Du nicht recht verstehen was Gesamtpaket meint?

Gesamtpaket heißt bei dir genau das, was dir gerade in den Kram passt.

Für professionelle Anwendungen ist der M0 in den allermeisten Fällen das 
einfachere Gesamtpaket, weil man dort eben nach anderen Maßstäben 
arbeitet. Dann heißt es von dir "Ja, aber die Bastler".

Dann habe ich Bastleranwendungen gezeigt, bei denen ein 32-Bit-System 
günstiger und einfacher ist. Aber das passt dir nicht in den Kram, 
deshalb versuchst du das irgendwie weg zu disktutieren.

> Ein verzweifeltes Festhalten an 8Bittern ist genauso ein Blödsinn die
> das "32bit für Blinkenlights".

In einem Unternehmen geht es um Profit. Das ist es worum es geht. Wenn 
32bit genauso teuer ist wie 8bit, verliert 8bit. So einfach ist das. Ich 
glaube da muss man gar nicht so kompliziert denken.

> Allerdings will die Mehrheit der Embedded-Entwickler in der Industrie
> Assembler nicht mehr anfassen

Ich würde noch weiter gehen: Wenn Assembler angefasst wird, läuft 
irgendwas falsch (Ausnahmen bestätigen die Regel).

Wenn in einer Werkstatt Dampfmaschine und Faustbeil ausgepackt wird, 
stimmt auch irgendwas nicht. So ist es auch mit Assembler. Wir leben im 
Jahr 2014!!

Nächstes Jahr wird schon das Hoverboard erfunden und es werkeln immer 
noch welche mit Assembler rum!?

ohje ohje :-)))

Kenne den Stm32 jetzt ein Monat. Und seit dem ich weiß das es ein LPC800 
gibt kann ich mir auch nicht mehr vorstellen zurück zu den 8Bit Pic zu 
gehen. Meine erste Anwendung war ein USB HID Device mit einem pic18f4550 
in ASM. Damals habe ich hier im Forum auch ordentlich auf die Kappe 
bekommen, weil ich es gewagt habe ohne Blinky Project einzusteigen. Aber 
so ein Quark wie Blinklicht oder Taschenlampe interessiert mich nun mal 
nicht. Das kaufe ich fertig. So etwas ist ja auch keine richtige 
Anwendung.

dutz schrieb:
> In einem Unternehmen geht es um Profit. Das ist es worum es geht. Wenn
> 32bit genauso teuer ist wie 8bit, verliert 8bit. So einfach ist das. Ich
> glaube da muss man gar nicht so kompliziert denken.

jaja der einkäufer nagelt sich an die (immer) noch viel zu teure value 
line
(egal ob stm32 value line die nicht getestet ist oder lpc der kaum 
peripherie hat). ehrlich gesagt das was ST/NXP einem als value line oder 
einstiegsmodell verkaufen ist immer noch viel zu teuer, da würd ich mich 
verar.... vorkommen. der einkäufer drückt dem entwickler die billigst 
chips auf, und dann muß er ein externes EEPROM an den 8piner hängen 
(oder stm32) wovon gleich mal 2pins wegfallen. oder einen externen adc. 
und schon gibt es zwei Bauteile von zwei unterschiedlichen Herstellern, 
verbraucht mehr platz auf der platine, mehr kosten.
und wenn ich mir die value line ansehe, und den vorgeschlagenen 
stm32f030f4 für 0.42c nehme, und dann später mehr flash brauche, muß ich 
auf die "vollversion" umsteigen da es keine value line mit 32k flash 
oder mehr in 20pin gibt. also dann entweder den stm32f031f6  (doof nur 
dass diesen niemand führt), den stm32f042 auch nicht.
dein einkäufer denkt dann: also wenn st mir den 16k flash für 0.4Euro 
verkauft, zahl ich für 32k flash nur ganz wenig mehr. oft ist es dann 
mind. das doppelte, da wie gesagt st dann den preis nicht halten kann da 
sie keine besserausgestattete modele mit mehr flash als value line 
anbieten.
ganz übel, hilft halt nur noch anbieterwechsel, neue peripherie, neue 
toolchain, neue testsuite... mehr kosten

martin schrieb:
> und dann muß er ein externes EEPROM an den 8piner hängen
> (oder stm32) wovon gleich mal 2pins wegfallen. oder einen externen adc.

Wieso muss man das? Wenn man mit den vorhandenen Peripheriebausteinen 
nicht klar kommt, nimmt man einen größeren Prozessor, der entsprechend 
ausgestattet ist.

martin schrieb:
> und wenn ich mir die value line ansehe, und den vorgeschlagenen
> stm32f030f4 für 0.42c nehme, und dann später mehr flash brauche, muß ich
> auf die "vollversion" umsteigen da es keine value line mit 32k flash
> oder mehr in 20pin gibt.

Und das gleiche kann dir bei einem Attiny auch passieren.

Es ist nicht die Schuld der Chiphersteller, wenn der Entwickler den 
Ressourcenaufwand nicht richtig abschätzen kann.

martin schrieb:
> dein einkäufer denkt dann: also wenn st mir den 16k flash für 0.4Euro
> verkauft, zahl ich für 32k flash nur ganz wenig mehr. oft ist es dann
> mind. das doppelte, da wie gesagt st dann den preis nicht halten kann da
> sie keine besserausgestattete modele mit mehr flash als value line
> anbieten.

Und auch das kann dir bei Attiny, MSP430, PIC oder sonst wo passieren. 
Das hat nichts mit ARM, 32 Bit oder sonst etwas zu tun.

martin schrieb:
> ganz übel, hilft halt nur noch anbieterwechsel, neue peripherie, neue
> toolchain, neue testsuite... mehr kosten

Und gerade das stimmt nicht. Neue Peripherie ja, aber die Toolchain 
bleibt die selbe. Bei einem Wechsel von AVR auf PIC geht das nicht.

dutz schrieb:
> Wenn in einer Werkstatt Dampfmaschine und Faustbeil ausgepackt wird,
> stimmt auch irgendwas nicht. So ist es auch mit Assembler. Wir leben im
> Jahr 2014!!

Dampfmaschinen (im weiteren Sinne) erzeugen auch im Jahr 2014 den 
überwiegenden Anteil des elektrischen Stromes...

Steam engine schrieb:
> Dampfmaschinen (im weiteren Sinne) erzeugen auch im Jahr 2014 den
> überwiegenden Anteil des elektrischen Stromes...

Und das in einer Werkstatt ... tja Sachen gibts.

martin schrieb:
> dann muß er ein externes EEPROM an den 8piner

Der LPC800 ist eben für Billig-Anwendungen die kein EEPROM brauchen, 
dafür gibt es dann den LPC11E00 (mit E wie EEPROM).

Andererseits hat der LPC800 ein ROM-API für IAP-Flash-beschreiben, das 
kann man auch nehmen (der Flash hat zudem 10x mehr Schreibzyklen als das 
EEPROM).

Lothar schrieb:
> Andererseits hat der LPC800 ein ROM-API für IAP-Flash-beschreiben, das
> kann man auch nehmen (der Flash hat zudem 10x mehr Schreibzyklen als das
> EEPROM).

Außerdem sind die Blöcke des Flash-Speichers kompakte 64 Byte groß. Das 
kann man doch sehr komfortabel als Ersatz für byteweise addressierbaren 
EEPROM verwenden. Es ist schon deutlich praktischer nutzbar als 256-512 
Byte große Blöcke wie bei manch anderen Mikrocontrollern.

greg schrieb:
> Außerdem sind die Blöcke des Flash-Speichers kompakte 64 Byte groß. Das
> kann man doch sehr komfortabel als Ersatz für byteweise addressierbaren
> EEPROM verwenden.

Bei den LPC mit EEPROM diese auch in 64 Byte Bänke aufteilt. Man kann 
zwar 1 Byte einzeln in den 64 Byte Puffer schreiben, es kann aber immer 
nur der ganze Puffer in eine EEPROM Bank programmiert werden.

F. Fo schrieb:
> Hatte mal ein wenig nach STM32 gegooglet und die Preise für Einzelstücke
> lagen alle über drei Euro.

Z.B. bei Mouser gibt's STM32 ab 1,16 EUR, LPC800 ab 0,97 EUR. Reichelt 
ist nicht das Maß der Dinge. Bei Aliexpress bekommst du auch die 
größeren (64-128 KB Flash, haufenweise Peripherie) ARMs teilweise 
unverschämt billig (< 2 EUR), wenn du ein bisschen auf die Post warten 
kannst.

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

Das würde mich auch interessieren.

Markus Müller schrieb:
> Erst gab es Windows 3.11
> Dann mal Windows 98
> Und Windows XP
> Und auch Windows 8
>
> Wer nutzt denn heute noch Windows 3.11?
> Ist doch viel kleiner, passt auf nur 30 Disketten usw. Dennoch nutzt das
> heute niemand mehr. Komisch.
>
> Genau so ist es mit
> 8086
> 6502
> Z80
> 68HC11
> AVR
> PIC16

Eigentlich ein klassischer Äpfel mit Birnen Vergleich...
Aber ist Dir schon aufgefallen daß immer mehr Leute bei Win7
hängenbleiben weils einfach langt? Ist Dir schon aufgefallen daß der 
Trend zu immer schnelleren Desktop Prozessoren längst erlahmt ist weil 
spätestens ein Core Duo den meisten langt? Der Schwerpunkt hat sich 
inzwischen ganz woanders hin verlagert: Für die geplante Anwendung 
möglichst einfach, klein, effizient und stromsparend. Genauso wie mit 8 
Bittern für Millionen Anwendungen schlicht das Optimum erreicht ist. Was 
hier zukünftig noch kommt sind eher innovative Features wie großes 
M/FRAM, eingebaute Echtzeit, selbstverwaltete Kontextwechsel und und 
und... Meine Wunschliste wär da noch sehr lang. Und der Xmega hat die 
Marschrichtung gezeigt.

dutz schrieb:
> So ist es auch mit Assembler. Wir leben im
> Jahr 2014!!

Wollte damit jetzt keine zweite "Front" eröffnen, aber sei's drum.
Was älter ist muß eben nicht deshalb schlechter sein. Ja, in der 
Industrie mag der Trend nicht zuletzt der Produktivität wegen längst 
woanders hingehen. Aber mit Asm bewahrt man sich ein Stück Einfachheit, 
die Freiheit alles und jedes unmittelbar und maximal effizient zu 
beeinflussen, nicht zuletzt auch (durch) das unmittelbare 
Hardware-Verständnis. Das alles geht noch so wunderbar auf den kleinen 
simplen 8-Bittern, die mit ihrer Leistung Millionen Anwendungen dennoch 
locker und lockerst auf die Bühne bringen :)
Und was mir so geht geht sicher auch anderen so...

Embedded schrieb:
> Gesamtpaket heißt bei dir genau das, was dir gerade in den Kram passt.

Nein, Du verstehst es nicht, kannst und/oder willst nicht.

So lasset die Welt Stück um Stück komplizierter und komplexer werden-
bis keiner mehr durchblickt und alles zusammenbricht :)

Andy P. schrieb:
> Zurück zum Thema: die Anwendung und deren Parameter bestimmt die CPU.
> Punkt.

Genau. Wenn die Anwendung 8 bittig realisierbar ist dann am besten so.

Andy P. schrieb:
> Ein verzweifeltes Festhalten an 8Bittern ist genauso ein Blödsinn die
> das "32bit für Blinkenlights".

Richtig. Eine Anwendung die 32 Bit erfordern würde hatte ich simpler 
Bastler noch nicht. Und werd sie vermutlich auch nicht bekommen, wenn 
ich bei Asm bleiben kann :-)

Markus Müller schrieb:
> wird sich zeigen welche Firmen
> noch übrig bleiben.

Genau die die Produkte haben die man möglichst einfach einsetzen kann :)

Moby schrieb:
> Genau die die Produkte haben die man möglichst einfach einsetzen kann :)

Und genau deshalb werden sich M0 durchsetzen.

Embedded schrieb:
> Moby schrieb:
>> Genau die die Produkte haben die man möglichst einfach einsetzen kann :)
>
> Und genau deshalb werden sich M0 durchsetzen.

Ja, das artet langsam zur Glaubensfrage aus... Jeder darf seine Meinung 
haben, weil er zu dieser nicht wie die Jungfrau zum Kind gekommen ist.

Moby schrieb:
> Ja, das artet langsam zur Glaubensfrage aus... Jeder darf seine Meinung
> haben, weil er zu dieser nicht wie die Jungfrau zum Kind gekommen ist.

Das hat nicht viel mit Meinung zu tun, sondern mit harten Tatsachen. 
Viele Anwendungen sind mit 32 Bit und der moderneren Bustruktur 
einfacher zu erledigen. M0 sind in Stückzahlen billiger. Ein 
Standardkern ist für die Hersteller viel einfacher zu warten. Die 
Tatsache, dass man eine Toolchain für Kleinstanwendungen sowie mittlere 
Anwendungen einsetzen kann, wird in der Industrie sehr hoch geschätzt. 
Und deshalb werden sich die ARM-Kerne mittelfristig durchsetzen.

An diesen Tatsachen kannst du nichts ändern, egal wie heftig du deine 
8-Bitter noch mit deinen ewig schwachen Argumenten (aber... aber, die 
sind doch viel einfacher?!) verteidigst.

Embedded schrieb:
> Viele Anwendungen sind mit 32 Bit und der moderneren Bustruktur
> einfacher zu erledigen.

Viele, Millionen aber auch nicht weil sie aus breiteren Bussen überhaupt 
keinen Vorteil ziehen. Hinzu kommt der (Lern-)Aufwand für den Umstieg.

Embedded schrieb:
> Ein
> Standardkern

... wird sich noch heraustellen. Vielleicht auch mehrere Standards.

Embedded schrieb:
> M0 sind in Stückzahlen billiger.

... da ist ebenfalls das letzte Wort längst nicht gesprochen.
Komplexere Controllerstruktur sollte im Prinzip hier im Nachteil sein.

Embedded schrieb:
> Die
> Tatsache, dass man eine Toolchain für Kleinstanwendungen sowie mittlere
> Anwendungen einsetzen kann, wird in der Industrie sehr hoch geschätzt.

Das ist AVR-Studio + ein Debugger genauso.

Alle diese "Tatsachen" beweisen mir: Nichts.

Moby schrieb:
> Viele, Millionen aber auch nicht weil sie aus breiteren Bussen überhaupt
> keinen Vorteil ziehen. Hinzu kommt der (Lern-)Aufwand für den Umstieg.

Selbst in einfachen Steuerungen hantiert man öfter mal mit 16 Bit großen 
Variablen, z.B. um Sensorwerte umzurechnen, und da hat man mit einer 
32-Bit-CPU handfeste Vorteile.

Ich habe nichts gegen 8-Bit-Mikrocontroller und halte sie auch nicht 
zwangsweise für veraltet, aber es liegt trotzdem auf der Hand, dass 32 
Bit in vielen realistischen Fällen Vorteile haben.

greg schrieb:
> Selbst in einfachen Steuerungen hantiert man öfter mal mit 16 Bit großen
> Variablen, z.B. um Sensorwerte umzurechnen, und da hat man mit einer
> 32-Bit-CPU handfeste Vorteile.

Tu ich auch. Und kann ich auch. Aber ich muß zugeben daß einzelne 
Rechnungen in Asm mühsam werden können und ich dann (kurz) neidisch auf 
die C-Fraktion schaue. Aber schaun wir genauer auf die Applikation dann 
sind eben die, die aus einer 32 Bit CPU (z.B. bei umfangreichen 
Berechnungen) handfeste Vorteile ziehen sowieso solche größeren 
Ausmaßes, die ich nicht mehr unbedingt zu den "Millionen 8Bit 
Anwendungen" zählen würde.

Wenn ich mich mal kurz in die Welt der C-Programmierer versetze kann ich 
das Argument für leistungsstärkere Controller bei Berechnungen ja gut 
verstehen. Aber dort schwenkt eben alles auf 64 Bit um sobald verfügbar, 
ist ja noch leistungsfähiger usw. So entsteht eine immer größere Lücke 
zwischen 8 und XY Bit, den beiden Polen der Zweckmäßigkeit für 
Anwendungen bestimmten Typs.

greg schrieb:
> Ich habe nichts gegen 8-Bit-Mikrocontroller und halte sie auch nicht
> zwangsweise für veraltet,

Danke.

Moby schrieb:
> ... da ist ebenfalls das letzte Wort längst nicht gesprochen.
> Komplexere Controllerstruktur sollte im Prinzip hier im Nachteil sein.

Ist sie aber nicht.

Moby schrieb:
> Das ist AVR-Studio + ein Debugger genauso.

Damit ist man aber auch Atmel beschränkt.

Moby schrieb:
> Alle diese "Tatsachen" beweisen mir: Nichts.

Klar, wenn ich mit geschlossenen Augen durch die Welt laufe, beweisen 
mir Farben auch nichts.

Falk Brunner schrieb:
> Die Kombination von "harten Tatsachen" und der Zeitform Futur finde ich
> gewagt ;-)

Wenn du meinen Text ganz zitiert hättest, wäre dir vielleicht 
aufgefallen, dass erst die Tatsachen kommen und dann ein Schluss, den 
man aus diesen Tatsachen ziehen kann.

Moby schrieb:
> Aber schaun wir genauer auf die Applikation dann
> sind eben die, die aus einer 32 Bit CPU (z.B. bei umfangreichen
> Berechnungen) handfeste Vorteile ziehen sowieso solche größeren
> Ausmaßes, die ich nicht mehr unbedingt zu den "Millionen 8Bit
> Anwendungen" zählen würde.

Wenn du diese Anwendungen nicht zu deinen 8-Bit-Anwendungen zählst, 
bleibt nicht viel übrig. Da bleiben nämlich nur noch Anwendungen übrig, 
die man besser mit ein paar Logikgattern oder analog besser erledigen 
kann.

Moby schrieb:
> Aber dort schwenkt eben alles auf 64 Bit um sobald verfügbar,

Quark. C im Embeddedbereich läuft immer noch zum größten Teil auf 32 
Bit.

Falk Brunner schrieb:
> Die Kombination von "harten Tatsachen" und der Zeitform Futur finde ich
> gewagt ;-)

Das ist das Typische an Religionen.

Embedded schrieb:
> Wenn du diese Anwendungen nicht zu deinen 8-Bit-Anwendungen zählst,
> bleibt nicht viel übrig. Da bleiben nämlich nur noch Anwendungen übrig,
> die man besser mit ein paar Logikgattern oder analog besser erledigen
> kann.

Ich weiß nicht wo Du arbeitest und zu welcher Betriebsblindheit das 
führt, aber da verschätzt Du Dich gewaltig.

Embedded schrieb:
> Quark. C im Embeddedbereich läuft immer noch zum größten Teil auf 32
> Bit.

Immer noch.

Moby schrieb:
> Ich weiß nicht wo Du arbeitest und zu welcher Betriebsblindheit das
> führt, aber da verschätzt Du Dich gewaltig.

Dann nenne mal eine konkrete und reale Serienanwendung, bei der ein 
8-Bitter einem M0 überlegen ist.

Elektrische Zahnbürste, Ampelsteuerung, Zeitschalter...
Schade, hab gerade keine Zeit noch Millionen andere aufzuzählen :(
In erster Linie fallen mir da natürlich meine eigenen Anwendungen
(Haussteuerung) ein. Jedes Bit mehr als 8 sind da Perlen vor die Säue.

Moby schrieb:
> Elektrische Zahnbürste, Ampelsteuerung, Zeitschalter...

Kann man alle genauso gut oder besser mit einem M0 erledigen.

Moby schrieb:
> In erster Linie fallen mir da natürlich meine eigenen Anwendungen
> (Haussteuerung) ein.

Kann man wunderbar mit einem M0 erledigen.

Moby schrieb:
> Jedes Bit mehr als 8 sind da Perlen vor die Säue.

Da stimme ich dir wiederum zu 100% zu. Du kannst damit nämlich ganz 
offensichtlich nicht umgehen.

Embedded schrieb:
> überlegen

Ach so, von "Überlegenheit" hat auch keiner gesprochen. Die Rede war 
doch  von Einfachheit", stimmts?

Moby schrieb:
> Ach so, von "Überlegenheit" hat auch keiner gesprochen. Die Rede war
> doch  von Einfachheit", stimmts?

Ich kann es nur noch einmal wiederholen: In der Industrie geht es um 
Wartbarkeit, Preis und Leistung. Ob ich für eine Einfachstanwendung 
einen oder zwei Tage brauche, spielt dabei keine Rolle.

Embedded schrieb:
> Du kannst damit nämlich ganz
> offensichtlich nicht umgehen

Du hast auch nicht bewiesen daß ich das müsste...
Simpler Bastler heißt übrigens einer der die gegebene Aufgabenstellung 
möglichst simpel umsetzt :-)

Moby schrieb:
> Du hast auch nicht bewiesen daß ich das müsste...

Du musst es auch nicht. Als Bastler kannst du machen, was du willst. 
Aber du solltest dich dann mit Behauptungen, was in der Industrie 
verwendet wird, mal etwas zurückhalten.

Embedded schrieb:
> Ob ich für eine Einfachstanwendung
> einen oder zwei Tage brauche, spielt dabei keine Rolle.

Embedded schrieb:
> aber dann hat man eben schon ein paar
> unnötige Stunden verblasen. Und in der Industrie sind das gleich ein
> paar Tausend Euro.

Leute,

ich mach hier mal eine Art Friedensangebot:

Orakeln wir doch lieber NICHT über das, was unserer Meinung nach SEIN 
MUSS, sondern reden lieber über das, was wir uns für die Zukunft 
wünschen. Ist ein dezenter Unterschied. Gelle?

Also, ich hatte zwar schon vor Jahren in unseren billigsten Geräten von 
einem PIC16 auf einen Arm7TDMI gewechselt - und zwar aus KOSTENGRÜNDEN. 
Dennoch sehne ich mir NICHT eine Zeit her, wo alle Welt nur noch Cortexe 
verbaut und es sonst nix gibt. Auch wenn ich selber vermutlich nur noch 
wenige oder garkeine 8 bitter beruflich verbauen werde. Für den privaten 
Bastel- und Hobbybedarf mag es sich anders fügen.

Kurzum, ich wünsche mir, daß in der µC Hardware eben KEINE Monokultur 
kommt.

So. Und jetzt seid ihr dran (mit Wünsche formulieren).

W.S.

Moby schrieb:
> Embedded schrieb:
>> Ob ich für eine Einfachstanwendung
>> einen oder zwei Tage brauche, spielt dabei keine Rolle.
>
> Embedded schrieb:
>> aber dann hat man eben schon ein paar
>> unnötige Stunden verblasen. Und in der Industrie sind das gleich ein
>> paar Tausend Euro.

Ah, du hast es nicht begriffen, das habe ich mir fast gedacht.

Nocheinmal, ganz langsam, zum Mitschreiben: Der Pflegeaufwand (und dazu 
gehört auch die Bauteilauswahl) ist in der Industrie deutlich höher als 
der Entwicklungsaufwand. Und noch einmal: Der Pflegeaufwand ist 
entscheidend, nicht der Entwicklungsaufwand.

Kapiert?

Vorschläge:

1) Elektronik Mikrocontroller-Studie 2011 ansehen (fast alle ARM dran):

http://www.elektroniknet.de/halbleiter/sonstiges/?_aid=85145&gid=2969&d=true&subPage=0&cp=3

2) Bei der Elektronik Mikrocontroller-Studie 2014 mitmachen und das 
Ergebnis abwarten (wahrscheinlich alle ARM dran):

http://umfragen.weka-fachmedien.de/index.php?sid=33559&lang=de

Lothar schrieb:
> 2) Bei der Elektronik Mikrocontroller-Studie 2014 mitmachen und das
> Ergebnis abwarten (wahrscheinlich alle ARM dran):

Ziemlich sinnlos so eine Studie, bei der man nicht nachvollziehen kann, 
ob da jetzt ein Bastler mit 5 Stück im Jahr teilnimmt oder ob man Mio 
Stück abnimmt.

Falk Brunner schrieb:
> Aber AVR ist diabolisch böse, nicht wahr? ;-)

Es geht doch nicht um gut und böse. Die AVR-Architektur ist nicht 
schlecht, aber sie gehört so langsam zum alten Eisen.

Das große Finale? ;)

@Moby:
Du schreibst oft und gerne von Komplexität und Aufwand für den Wechsel 
auf 32Bit. Kann man natürlich so sehen.
Aber: Wie sieht es denn mit einem Wechsel von AVR auf z.B. den PIC18F 
aus? Ist ja auch 8Bit - mit teils toller Peripherie die man bei AVR 
nicht findet. Deiner Logik nach dürfte das kein Problem sein, oder?

Stefan schrieb:
> Aber: Wie sieht es denn mit einem Wechsel von AVR auf z.B. den PIC18F
> aus? Ist ja auch 8Bit - mit teils toller Peripherie die man bei AVR
> nicht findet.

Wenn man in einer Welt zuhause ist und diese die eigenen Bedürfnisse 
fast perfekt abdeckt (was ein großer Wert an sich ist) da ist doch ein 
Wechsel egal wohin nicht sinnvoll. Einer der springenden Punkte ist 
dabei der Lernaufwand bis man wirklich produktiv ist- an sich nichts 
schlimmes wenn er denn nicht wertvolle Zeit kosten würde. Die sollte man 
sich einteilen (für die eigenen Projekte) und nicht unnütz ohne Not zum 
Wechsel von Plattformen verschwenden. Zugegebenermaßen wäre man in C da 
flexibler, wenn es denn sein müsste. Ich bin aus der Pic Welt schon 
lange raus, welche tolle Peripherie lockt denn da?

Markus Müller schrieb:
> AVR würde ich eher in die Kategorie wie
> 6502, Z80 oder 68HC11 stecken.

Um Himmels willen. Wofür ich beim Z80 noch eine Europlatine brauchte 
passt mit nem guten Mega auf ein Fünftel der Fläche, bei vielfach mehr 
Speed. Wie kann man das nur in eine Liga stecken? Aber das muß man wohl, 
damit ein STM32 in besonders hellem Schein leuchtet, was?

Moby schrieb:
> Einer der springenden Punkte ist
> dabei der Lernaufwand bis man wirklich produktiv ist

Moby schrieb:
> Zugegebenermaßen wäre man in C da
> flexibler

Das bringt den Bastlergeist auf den Punkt. Man ist froh, endlich auf 
einem ATiny seine Lösungen in ASM ans Laufen zu bringen. Nach Jahren 
kennt man die Peripherie und mit den Interrupts klappts auch irgendwie. 
Und jetzt kommt einer mit der riesigen Registerbreite daher. Da muss man 
sich ja fürchten. ;)

Wie sagt die Atmel-Werbung:

Bringing AVR Ease-of-Use to Cortex M0+ Microcontrollers

http://www.atmel.com/microsite/samd20/

So kann man den Abschied von AVR natürlich auch darstellen :-)

@Markus

Du provozierst eben gerne... Kein Problem, Dein STM32 hat auch eine 
Daseinsberechtigung!

no fear schrieb:
> Nach Jahren
> kennt man die Peripherie und mit den Interrupts klappts auch irgendwie.

Unterstellung.

no fear schrieb:
> Da muss man
> sich ja fürchten.

Unterstellung.
Furcht ist ein schlechter Ratgeber, Vernunft ein guter :-)

Wie sagt die Atmel-Werbung:

Simply AVR.
They are SIMPLE to use and used EVERYWHERE...

Moby schrieb:
> Simply AVR. They are SIMPLE to use and used EVERYWHERE...

Fragt sich nur in welchem Produkt - bei 3% Marktanteil bei uC

Die Webpage wurde wohl auch schon länger nicht mehr geupdated:

tinyAVR->megaAVR->AVRXMEGA->AVRUC3 :-)

AVRUC3 wurde ja schon beerdigt ...

Lothar schrieb:
> AVRUC3 wurde ja schon beerdigt ...

so ein schwachsinn, warum wird er dann noch für neue Designs wie z.b. 
das Microsoft Surface oder Samsung Galaxy verwendet?

andreas schrieb:
> warum wird er dann noch für neue Designs wie z.b.
> das Microsoft Surface

Zitat Atmel: "I know everybody loves ARM chips and we make a whole bunch 
of ARM architecture chips, including the SAM D20, but UC3 is a pretty 
sweet little chip itself, as evidenced by Microsoft’s selection of it in 
this cost-sensitive consumer application."

Atmel hat einfach NXP preislich unterboten (obwohl die UC3-Fertigung 
teurer ist):

http://en.wikipedia.org/wiki/Apple_M7

andreas schrieb:
> Samsung Galaxy verwendet

Das Design ist schon älter vom SGII und wurde dann eben im SGIII und SG4 
beibehalten.

>Bringing AVR Ease-of-Use to Cortex M0+ Microcontrollers

Lauter können die Glocken doch kaum noch läuten;)

Embedded schrieb:
> Und deshalb werden sich die ARM-Kerne mittelfristig durchsetzen.

nicht solange die Industrie versucht uns weißzumachen dass man 32bit 
schon für 32cent bekommt ^^ es wird nur versucht billigen ramsch unter 
die leute zu bringen, damit diese dann auf diesen ARM Zug aufspringen.

als Bsp des schon öfters zitierten STM32F03

- power supply wurde von 2.0V auf 2.4Vmin erhöht
- kein Osc wurde kalibriert/getestet
Table 33. HSI oscillator characteristics
"2. Guaranteed by design, not tested in production"
- so geht es weiter für die interne RC
- dasselbe bei Table 37. Flash memory characteristics
"1. Guaranteed by design, not tested in production"
- Weiterhin Table 41. ESD absolute maximum ratings
"1. Data based on characterization results, not tested in production"
- Table 44. I/O static characteristics (continued)
"1. Data based on design simulation only. Not tested in production"

und so geht es die ganze Zeit weiter

selbst die 32cent sind zu teuer - Leute was ist aus den Ingenieuren 
heute geworden die auf so was reinfallen? Früher hatte man ein 
Datenblatt sehr detailliert gelesen, abgeschätzt was brauche ich denn 
für meine Aplikation. Heute nimmt man von Haus aus einen Cortex weil er 
billiger ist
und schaut gar nicht mehr auf die Charakteristik. Mit solchen Aussagen 
wie oben distanziert sich der Hersteller von jeder Produkthaftung. Setze 
ich so einen Chip ein, und passiert irgendwas dann ist die Hölle los. 
Ich würde mir kein Produkt kaufen in dem so eine Value Line verbaut ist.
Nimmt man die Value line raus, dann sieht es ganz anders aus mit den 
Cortexen, diese kosten dann vielfaches mehr. Das ist der ganze "wenn ich 
für 32Bit dasselbe zahle wie für 8Bit" Zauber.

ingolf schrieb:
> Ich würde mir kein Produkt kaufen in dem so eine Value Line verbaut ist.

Du hast keine USB-WiFi oder USB-Bluetooth Sticks :-) Da sind nämlich 
Value Line 8051 oder M0 drin.

Aber Du meintest wahrscheinlich eine Industriemaschine. Hier kann ich 
Dir versichern, wir schauen die Datenblätter genau an, und geben wenn 
nötig auch mehr für einen uC aus.

Und wenn Du eine Billig-Kaffeemaschine meinst, solltest Du Dir weniger 
Sorgen um den uC machen als um das Netzteil.

STMicroelectronics:
Umsatz soll im laufenden Quartal sinken

http://www.elektroniknet.de/halbleiter/sonstiges/artikel/105101/

> Das bringt den Bastlergeist auf den Punkt. Man ist froh, endlich auf
> einem ATiny seine Lösungen in ASM ans Laufen zu bringen. Nach Jahren
> kennt man die Peripherie und mit den Interrupts klappts auch irgendwie.
> Und jetzt kommt einer mit der riesigen Registerbreite daher. Da muss man
> sich ja fürchten. ;)

Die Registerbandbreite ist ohne Bedeutung, denn die modernen µC 
programmiert niemand in Assembler.

> Wenn man in einer Welt zuhause ist und diese die eigenen Bedürfnisse
> fast perfekt abdeckt

Stillstand ist der Tot. Horizonte erweitern, 32bit nutzen!

:P
;)

> So. Und jetzt seid ihr dran (mit Wünsche formulieren).

Ich möchte, dass jeder Hersteller exakt das gleiche Programmierinterface 
benutzt (inklusive Protokoll), so dass ich mit einem Programmer alles 
programmieren kann.

Ich möchte, dass ein µC mit einem MAC auch einen PHI hat.

ingolf schrieb:
> nicht solange die Industrie versucht uns weißzumachen dass man 32bit
> schon für 32cent bekommt ^^ es wird nur versucht billigen ramsch unter
> die leute zu bringen, damit diese dann auf diesen ARM Zug aufspringen.

Also ich bekomme diverse M0 Chips für den Preis. Wo ist das Problem?

Ich verstehe sowieso nicht, wieso ich einen 8-Bit-Kern verwenden soll, 
wenn meine Timer 16-32 Bit haben und der ADC 12 Bit. Ich will einen 
Kern, der auch direkt den Daten rechnen kann, die er bekommt und nicht 
die Hälfte seiner Zeit mit Bitüberträgen herumhantiert.

Und die Komplexität ist eine Frage der Peripherie. Atmel zeigt doch, 
dass man auch einfache AVR-like-Peripherie mit einem starken Kern 
verknüpfen kann, und dabei immer noch günstig ist.

Komplexität ist auch subjektiv. Ich finde die STM32M0-Peripherie noch 
sehr einfach, übersichtlich und gut beschrieben. Ich kann aber auch 
verstehen, wenn Anfänger oder wenig Talentierte/Geübte damit Probleme 
bekommen und lieber beim AVR bleiben. Man kann aber davon ausgehen, dass 
Profis, die jeden Tag damit arbeiten, damit spielend klar kommen.

Falk Brunner schrieb:
> Ein Phy ist ein Pegelwandler und ausserdem die Schnittstelle zur
> ESD-verseuchten Aussenwelt. Für sowas kann man einen kleinsten
> Halbleiterstrukturen gebrauchen, da müssen robustere Prozesse her.
> Weshalb die Integration eines PHY immer Probleme macht und auf
> Kompromisse rausläuft.

So sieht es aus. Am Ende war der Chip (falls es überhaupt ein Chip war 
und nicht ein Multi-Die-Package) wahrscheinlich einfach zu teuer.

lolli schrieb:
> Ich möchte, dass ein µC mit einem MAC auch einen PHI hat.

Ethernet - OnChip vs 2nd Chip

http://www.microchip.com/forums/m470161-print.aspx

Helmut Lenzen schrieb:
> Ist klar Falk, aber die externen Ethernet Controller
> (DM9000,Wiznet,ENC624J600) haben den MAC und den PHY + RAM alles auf dem
> Chip. Und das sind auch nun keine groben Strukturen.

Eine MAC sind nur ein paar hundert Gatter (siehe FPGA-Mac-IP). Das 
kriegt man auch locker auf größere Strukturen. Allein der RAM eines 
modernen Prozessors dürfte ein vielfaches an Chipfläche bei gleicher 
Strukturbreite kosten.

Ein typisches Beispiel für die glitzernde, ach so einfache Welt von 
STM32 (und zugehöriger C-Programmierung): 
Beitrag "STM32 und Keil MDK-ARM Einsteiger Frage"
Herrlich, kann man nicht besser beschreiben. Mir würde auch übel werden 
wenn ich mir so einen Krampf den ganzen Tag antun müsste. Um wieviel 
kürzer und unkomplizierter tut man sich da mit einem AVR und ASM- aber 
psssst, nicht weitersagen :)

Moby schrieb:
> Ein typisches Beispiel für die glitzernde, ach so einfache Welt

Beitrag "AVRISP MKII bricht beim Brennen ab."
Beitrag "Atmel AVR USB Bootloader per Software starten - funktioniert nicht"
Beitrag "Studio 4.19 - Insstallation - keine Devices angeboten - (2.Anlauf)"
...
...
...

und das halbe Forum handelt von Fuse Bits der veralterten AVR 
Technologie. ;-)))

Hast du so ein Auto wie Fred Feuerstein?

Es ist und bleibt lustig anzuschaun, wie hier unnötige Komplexität nicht 
zur Kenntnis genommen, verharmlost oder gar abgestritten wird- obwohl 
sie doch nun wirklich auf der Hand liegt.

Über das Verfusen kann man doch nur lachen... Also wenn das das größte 
AVR-Problem sein soll !?

Und ja, das Auto von Fred Feuerstein war robust und fährt und fährt und 
fährt... Einfach. Verlässlich. Den Zweck erfüllend. Aber das sind 
Fremdworte für Leute, denen Leistung, Bitbreite und konfigurierbare 
Features das Höchste bedeuten.

Moby schrieb:
> Bitbreite

Busbreite :-)

Moby schrieb:
> Busbreite :-)

Warum? Wie breit irgendein Bus ist, hat nichts damit zu tun, mit welcher 
Datenbreite eine CPU arbeitet. Bitbreite passt schon besser.

greg schrieb:
> Datenbreite

passt glaub ich am besten. Ein Bit kann ja durchaus unterschiedlich 
"breit" sein- in zeitlicher Betrachtung.

Helmut Lenzen schrieb:
> Markus Müller schrieb:
>> Ich vermute mal, dass hat was mit der Wärme zu tun.
>
> TI hat es aber schon mal geschafft, und so warm wurde das Teil nun auch
> nicht (kleinen Webserver damit gebaut).

Wir haben in der Firma einen Chip im Einsatz mit Phy auf dem Chip 
(Hilscher netX).

Wir könnten die Leute von Hilscher dafür erschlagen.
Bei eingeschalteten Phys wird der Chip so heiß, dass das 
Kommunikationsinterface, das wir damit gebaut haben, bei einer 
Umgebungstemperatur von 40°C ausfällt.
Wir haben ein weiteres Interface, bei dem ein ähnlicher Prozessor zum 
Einsatz kommt, nur sitzen da die Phys extern - keine Probleme.

Wenn Du die Phys auf physikalisch kleinen ICs integrierst, wirst Du die 
Wärme nicht los!
Industrieller Temperaturbereich oder gar Automotive geht nicht mit 
integrierten Phys.

Klar werden immer noch superschnelle 8051 herausgebracht. Vor allem im 
Automotive Bereich ist es billiger einen bestehenden 8051 aufzubohren 
anstatt einen ARM zu zertifizieren. Es sind sogar 8051 im nächsten 14nm 
Prozess von Intel geplant.

Moby schrieb:
> Über das Verfusen kann man doch nur lachen... Also wenn das das größte
> AVR-Problem sein soll !?

Für Einsteiger scheint es ein Problem zu sein. Und warum macht Atmel 
nicht einfach ein kleines Bootloader-ROM in den AVR, dann gäbe es das 
Problem nicht. Bei den 8051 LPC war es Standard, und wurde in die ARM 
LPC übernommen. Wir haben hier noch nie einen LPC gebrickt.

Lothar schrieb:
> Es sind sogar 8051 im nächsten 14nm
> Prozess von Intel geplant.

Na warum soll das nicht auch mit anderen 8-Bittern möglich sein?

Heiner schrieb im Beitrag #3511283:
> es gibt noch 8 Bit Controller

Das Ende der 8 Bitter erlebt hier keiner mehr.
Bei Reichelt gibts sogar noch Z80; wie ist das bloß möglich ???

W.S. schrieb:
> reden lieber über das, was wir uns für die Zukunft
> wünschen

Ok, um nicht immer nur auf dem Komplizierter, Komplexer, Umständlicher 
der heutigen 32 Bitter (IN IHREM EIN/ERSATZ FÜR TYPISCHE 8-BIT APPS) 
herumzureiten hier mal ein paar Wünsche, deren Erfüllung mich für eine 
neue Plattform begeistern könnten! Im Interesse einfachstmöglichen 
Einsatzes mit niedrigen Einstiegshürden, weniger Softwarekomplexität -> 
weniger Entwicklungs/Pflegeaufwand gehts dabei vor allem um die 
Begrenzung der Flexibilität! Niemand braucht z.B. ein UART mit hundert 
Betriebsarten. Beschränkung auf das meist benötigte, lautet die 
Zauberformel. Vereinheitlichen, vereinfachen wo es nur geht! Und statt 
grassierender Registerkonfiguritis ein wenig mehr Intelligenz in die 
Controller! Konkret sollte per default folgendes möglich sein:

A-wie ADC: Samplen kann der Controller selbstständig. Jeden verfügbaren 
Pin in einen einen entsprechenden IO-Bereich. Mit sinnvollem Speed und 
am besten 16-bittig.

B-wie Berechnungen: Bitteschön alles (auch) in ASCII inkl. Komma  einer 
Recheneinheit vorsetzen können und in Hardware berechnen lassen, von der 
Summe bis zur Wurzel!

D-wie DAC: Initial 0 in dem Pin zugeordneter I/O-Location gibt nichts, 
jeder andere Wert eine entsprechende Spannung aus.

I-wie Interrupts können jedem Pin mit jeder Funktion zugeordnet werden, 
Verwaltung/Registerrettung sind dabei nicht mehr das Problem des 
Programmierers. Funktionen z.B. Test auf Analogwert, Test auf Change...

M-wie Memory ist linear mit gleichfunktionellem Registersatz, I/O und 
viel nichtflüchtigem Speicher für Programme und Daten.

P-wie Pin: Einheitliche Ansprache über Controllertypen und Hochsprachen 
hinweg von 1 bis x.

U-wie UART: Einen Pointer auf einen Datenbereich, ggf. die Anzahl, eine 
Baudrate im Klartext, ein Flag fürs Übertragungsende und ab geht die 
Post! 8N1 ist eh Standard. Wie das Ganze dann unabhängig vom 
Programmablauf vonstatten geht: nicht mein Problem! Andere 
Schnittstellen können in ähnlich bequemer Weise abgehandelt werden.

Wie diese Funktionen über weitere Parameter konfigurierbar gemacht 
werden darüber kann man sich ja streiten.

Also bis das Ganze ein paar Schritte in diese Richtung gegangen ist und 
die Chipentwickler nicht immer nur mit dem Motto "viele Bits+MHz" 
Fortschritt definieren bleiben die PICs und AVRs dieser Welt 
TOP-aktuell.  Denn wie schon

Embedded schrieb:
> Die AVR-Architektur ist nicht
> schlecht

Lothar schrieb:
> Moby schrieb:
>> Über das Verfusen kann man doch nur lachen... Also wenn das das größte
>> AVR-Problem sein soll !?
>
> Für Einsteiger scheint es ein Problem zu sein.

Hat sich ja nun sowieso mit dem XMega erledigt.

Lothar schrieb:
> Und warum macht Atmel
> nicht einfach ein kleines Bootloader-ROM in den AVR

Das wär mein nächster heißer Tipp für neue AVRs!

Markus Müller schrieb:
> A - gibt es schon beim STM32 für sehr viele IO-Pins (ca. 24,
> Typabhängig, 12/16 Bit)
> B - Kann jeder programmieren - Wen Du einen Taschenrechner bauen willst.
> D - hat der STM32 bis zu 3 Stück drin
> I - kann der STM32
> M - Ist Standard bei ARM/Cortex
> P - Schreibe Dir eine Lib für jede CPU (Die ST Lib macht das für alle
> STM32)
> U - Schreibe Dir eine Lib (wie ich mir auch gemacht habe)

Du hast nix, aber auch gar nix verstanden.

Helmut Lenzen schrieb:
> Und gibst es doch, die neuen Cortex haben doch eine Fliesskommaeinheit
> auf dem Chip drauf.

Das ist aber kein "ASCII" (bzw. BCD?). Wobei ich es für eine relativ 
bescheuerte Idee halte, in BCD zu rechnen.

... du liebe Güte!

Hier überzeugt doch keiner Keinen einen anderen Prozessor zu nehmen!

Je nach Anforderung und Weltsicht entscheidet man sich

- völlig frei je nach Projekt, Aufgabe und Anforderung
- bleibt in einer Familie
- nimmt immer die gleichen zwei, drei Typen

Offenbar verkaufen sich doch alle prima (sogar so ne Exoten wie der 
Propeller), sonst wären sie sogar schon weg vom Fenster.

Also gaaaanz ruhig bleiben!

Moby schrieb:
>> Es sind sogar 8051 im nächsten 14nm Prozess von Intel geplant.
>
> Na warum soll das nicht auch mit anderen 8-Bittern möglich sein?

Bestimmt nicht, da würden sich Atmel und PIC ihr 32-bit Wasser abgraben, 
mit dem sie ihren Gewinn machen.

Moby schrieb:
>> Und warum macht Atmel nicht einfach ein kleines Bootloader-ROM in den AVR
>
> Das wär mein nächster heißer Tipp für neue AVRs!

Atmel verweigert das ja nur schon seit Jahren.

Embedded schrieb:
> Es geht doch nicht um gut und böse. Die AVR-Architektur ist nicht
> schlecht, aber sie gehört so langsam zum alten Eisen.

Die "AVR-Architektur" ist ein aufgebohrtes Studentenprojekt, wo durch 
Tricks diverse 16-bit Fähigkeiten in 8-bit realisiert wurden. ARM wurde 
lange vor AVR entwickelt und ist konsequent und elegant 32-bit (im 
Gegensatz übrigens zum damaligen 16/32-bit Murks 80286 und 68000)

Zur Kompetenz der AVR-Entwickler (Alf-Egil Bogen) :-)

http://alfbogen.com/2013/06/16/risc-versus-cisc/

Moby schrieb:
> Ein typisches Beispiel für die glitzernde, ach so einfache Welt von
> STM32 (und zugehöriger C-Programmierung):
> Beitrag "STM32 und Keil MDK-ARM Einsteiger Frage"

Immerhin kann man das Problem schnell eingrenzen. Und man muss nicht die 
Libs verwenden. Auf Registerebene geht es schneller. Und AVR-Assembler 
lernen dauert definitiv länger.

Moby schrieb:
> Im Interesse einfachstmöglichen
> Einsatzes mit niedrigen Einstiegshürden, weniger Softwarekomplexität ->
> weniger Entwicklungs/Pflegeaufwand gehts dabei vor allem um die
> Begrenzung der Flexibilität!

Einstiegshürden spielen für professionellen Einsatz keine Rolle. Da hat 
man eh den Support eines FAE, in der täglichen Arbeit ist es völlige 
Wumpe ob man 5 oder 10 Tage für die Einarbeitung braucht. Was danach 
raus kommt ist wichtiger. Der Pflegeaufwand lässt sich durch 
Standardisierung senken, also gleiche Softwaremodule in vielen 
Anwendungen. Das geht über die STM32F-Serie ganz gut.

Beim STM32 gibt es einige Konzepte, die die Komplexität wesentlich 
verringern:

- Es gibt bei den seriellen Schnittstellen keinen FIFO, beim ADC gibt es 
genau ein Ergebnis-Register. Man macht alles per DMA. Beim (alten) AVR 
muss man alles mit Interrupts machen (= komplexer, mehr Softwareaufwand, 
höherer Energieverbrauch, schnellere Datenraten bei SPI quasi 
unmöglich). Durch den großen RAM kann ich auch riesige Datenmengen 
bequem zwischenspeichern (z.B. ein DDS mit 1024 Eckpunkten ohne einen 
einzigen CPU-Eingriff in ca. 15 Codezeilen).

- Der Prescaler bei den Timern macht vieles einfacher, Timererweiterung 
per Software wird oftmals überflüssig (= weniger Komplexität, weniger 
Softwareaufwand, weniger Energieverbrauch, mehr Rechenleistung).

- FPU bei den größeren STM32 senkt die Softwarekomplexität bei 
Berechnungen. Und das bei einem Controller für < 3 Euro! (STM32F3)

- Sehr schöne und einfach zu bedienende PWM-Einheiten mit üpigen 
Compareeinheiten. ADC-Trigger auf Compare sind sehr gut umsetzbar.

Zugegeben, die neueren XMEGA mögen besser sein als die alten AVR, mit 
denen ich die STM32 vergleiche. Die XMEGA habe ich aber gleich 
übersprungen. Ich kann einfach keinen Mehrwert gegenüber dem STM32 
erkennen, zumal sie teilweise sehr viel teurer sind, bei schlechterer 
Performance. Ich bin auf schnelle Schnittstellen und ein wenig 
Rechenperformance angewiesen und kann heute mit einem < 50 ct uC das 
machen, wofür ich vor zwei Jahren noch 2 Euro ausgeben musste.

Übrigens: Es gibt Leute, die mit einem uC mehr als nur eine LED 
bedienen! Und davon nicht zu wenig.

Helmut Lenzen schrieb:
> Geht der Trend zur ZweitLED? :=)

Ich habe allein schon zwei LED zur Statusanzeige drauf :)

Antimedial schrieb:
> - Es gibt bei den seriellen Schnittstellen keinen FIFO, beim ADC gibt es
> genau ein Ergebnis-Register. Man macht alles per DMA.

Was hat ein FIFO mit DMA zu tun? Die LPCxxxx haben beides. Das hat den 
Vorteil daß man bei kleinen Blöcken (ja, das gibt es) nicht unbedingt 
den DMA Controller bemühen muß. Low-latency I2S z.B. geht super mit 
FIFO.

Offensichtlich meinen hier viele, daß man mit einem 128kHz betriebenen 
AVR höchstens noch ne LED schalten kann. Unglaublich.

Lothar schrieb:
> Moby schrieb:
>>> Es sind sogar 8051 im nächsten 14nm Prozess von Intel geplant.
>>
>> Na warum soll das nicht auch mit anderen 8-Bittern möglich sein?
>
> Bestimmt nicht, da würden sich Atmel und PIC ihr 32-bit Wasser abgraben,
> mit dem sie ihren Gewinn machen.

Genau. 8-Bitter würden dann den 32ern das Wasser abgraben ;)

Mal ne Frage an die Hardcore-Spezialisten.

Ich habe mir mal die Umgebung der STM32 angeschaut und einige Header 
bzw. C-Files gefunden, die man doch gerne aus Gründen der 
Standardisierung direkt einkomplieren könnte. Hat sich da jemand schon 
mal genau das Copyright durchgelesen und verstanden?

noreply schrieb:
> Ich habe mir mal die Umgebung der STM32 angeschaut und einige Header
> bzw. C-Files gefunden, die man doch gerne aus Gründen der
> Standardisierung direkt einkomplieren könnte. Hat sich da jemand schon
> mal genau das Copyright durchgelesen und verstanden?

Was meinst du mit direkt einkompilieren?

Hab mir mal die Lizenz der StdPeriph angeschaut [1]. Ich glaubte bisher, 
das sei eine standardmäßige permissive Lizenz. Sieht auf den ersten 
Blick auch so aus. Aber weit gefehlt: sie ist durch weitreichende 
Einschränkungen und Klauseln sehr problematisch. Die größten die Praxis 
betreffenden Einschränkungen sind folgende:

* Man darf die Software nur für ST-Mikrocontroller nutzen.
* Man darf die Software nicht direkt für kommerzielle Zwecke, egal 
welcher Art, nutzen.
* Bei Verletzung der Lizenzbedingungen kann ST die Lizenz jederzeit 
zurückziehen.

Das ist definitiv kein Open Source mehr!

[1] 
http://www.st.com/st-web-ui/static/active/en/resource/legal/legal_agreement/license_agreement/software_license_agreement_liberty_v2.pdf

> Hab mir mal die Lizenz der StdPeriph angeschaut
> * Man darf die Software nicht direkt für kommerzielle Zwecke,
> egal welcher Art, nutzen.

# Unless otherwise explicitly stated in this Agreement, You may not
# sell, assign, sublicense, lease, rent or otherwise distribute
# the Licensed Software for commercial purposes, in whole or in part.

sieht so aus, aber, im Abschnitt davor:

# STMicroelectronics ("ST") grants You a [...] limited license of
# the Licensed Software to:
# [...]
# (iv) make, have made, use, sell, offer to sell, import and export
# or otherwise distribute Products also through multiple tiers.

Daraus würde ich schließen, dass man die Lib durchaus für alle 
Entwicklungen benutzen darf, nur darf man die Lib selbst nicht 
verkaufen, aber wer will das schon?

Schwierig wird's natürlich zusammen mit der GPL. Einerseits darf ich die 
Lib nicht weitergeben, andererseits kann sie sich ja jeder selbst von 
st.com holen. Also, ohne Anwalt sag' ich nichts.

Irgendwie ist das lächerlich, schließlich spart diese Lib nur 
Schreibarbeit, ich kann ja alles aus dem Datenblatt abtippen.

gnd3 schrieb:
> Daraus würde ich schließen, dass man die Lib durchaus für alle
> Entwicklungen benutzen darf, nur darf man die Lib selbst nicht
> verkaufen, aber wer will das schon?

Man darf aber auch keine Derivate der Software verkaufen. Also wenn man 
die Library in einer eigenen Software verwendet, darf die nicht verkauft 
werden. Das schließe ich jedenfalls aus dem Text.

Die Lizenz widerspricht sich also ein bisschen selbst. Ein "Produkt" das 
die StdPeriph-Software nutzt, darf man verkaufen. So ein Produkt 
schließt aber ein Derivat der StdPeriph-Software ein (das erwähnt die 
Lizenz ausdrücklich). Derivate der StdPeriph-Software darf man aber 
nicht verkaufen.

Das wird zwar ein bisschen entkräftet ("Unless otherwise explicitly 
stated"), aber juristisch bewerten kann ich das keinesfalls. :)

> Irgendwie ist das lächerlich, schließlich spart diese Lib nur
> Schreibarbeit, ich kann ja alles aus dem Datenblatt abtippen.

In der Tat, ganz schön lächerlich von ST so eine merkwürdige restriktive 
Lizenz zu verwenden. Verursacht nur Kopfschmerzen bei Entwicklern und 
hilft ansonsten Niemandem.

Antimedial schrieb:
> Beim STM32 gibt es einige Konzepte, die die Komplexität wesentlich
> verringern:

Bravo. Feature 922,923,924 machen die vorangegangenen wieder ein Stück 
weniger komplex. Und wenn erst mal Feature 925 draußen ist, ja dann 
erst...
Da beschleicht einem das Gefühl, es wird immer einfacher!

Nix für ungut, wer die Leistung braucht der kann sich ja da einarbeiten.
Wer in die vielen Features verliebt ist auch. Alle anderen nehmen 8 Bit.

Lothar schrieb:
> Und warum macht Atmel
> nicht einfach ein kleines Bootloader-ROM in den AVR

Da wär noch zu ergänzen das ein entsprechender Speicherbereich ja dafür 
ab Mega aufwärts vorhanden ist. Vielleicht denkt sich Atmel auch man ist 
so flexibler, dabei würde auch hier was fixes die Sache vereinfachen.