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