Hi, Leute, eigentlich schade, daß die Infos von NXP immer zuerst auf russischen Seiten auftauchen, aber anbei eine Präsentation, in der Details zur kommenden LPC1700-Familie von NXP mit Cortex-M3-Kern genannt werden. So wie es aussieht, kann sich ST dann warm anziehen, Luminary in Teilbereichen auch. Einige Features: - Cortex M3 Core Rev 2 (mit stark verbesserten Stromsparfeatures, insbesonder Wake-Up Interrupt) - natürlich Memory Accelerator Module für den Flash - Ethernet, USB und CAN auf einem Chip - DMA - etc. Fürs Erste sind Varianten mit bis zu 256K Flash und 64K SRAM geplant. Bedauerlicherweise gibt es erste Samples Q4/08 und erst Q1/09 geht es los. Die LPC1000-Familie mit 44Pin Packages kommt leider erst Q4/09, was ich sehr schade finde. Zumindest im Hobbybereich dürfte ARM7 damit tot sein.
Dann wird wohl ST keine neuen Kunden mehr gewinnen :) Denn beim STM32F103 kann USB und CAN nicht gleichzeitig benutzt werden ... da sind schon viele Leute auf die Nase gefallen! Der 12-Bit AD den neuen LPC17xx ist auch super.
naja als Einstieg ein Gehaeuse mit 80Pin ist ganz weit weg von Hobby. Bis 32/48/64 Pinner mal erscheinen fliesst noch viel Wasser die Elbe runter. Und wenn die Jungens bei NXP das nicht endlich mal auf die Reihe bekommen zumindest die JTAG Pins nebeneinander an den Chip zu bekommen wie STM32 und Luminary Stellaris, dann wird NXP auch noch lange zuschauen koennen, wie sich immer mehr Hobbyisten die keinen Bock haben auf total verknotete 2-seitige Platinen, der Konkurrenz zuwenden. Diese wunderschoenen Libraries zum Einsteigen finde ich auch ganz toll. Ich habe mich jedenfalls nach dem Routing-Deseaster mit dem LPC2138 zu ST begeben und einen Stellaris M3 habe ich mir auch schon bestellt. Aber immerhin der gute Wille mit 12-Bit ADC ist zu sehen. Wenn die nen 44pinner mit 0,8er Pitch rausbringen oder wenigstens 0,65er nehme ich alles zurueck. 8-)
@LPCler, und warum sollte ST keine Kunden mehr gewinnen? Ich bin gewiss freundlich gegenueber NXP eingestellt aber die STM32 sind ersten auf dem Markt, zweitens erscheinen sie relativ stabil und drittens mal sehen wann der dritte im Bunde (ich meine Atmel) zuschlaegt. Es wuerde mich wundern, wenn die noch lange zusehen. Auf jeden Fall wird das interessant und insgesamt sicher zum Nutzen der Anwender. Ach ja, 80-pin und all die Peripherals, da kann auch nicht alles parallel genuetzt werden, denn das wuerde ca. 140+ pins benoetigen. Z.B. war letztes Jahr die Fuehrung bei NXP noch der Meinung, dass USB und CAN sowieso keiner zusammen benutzen wird. Pins, bzw. die internen pads sind teuer, da wird wieder stark gemultiplexed. Aber vielleicht kommt ja jetzt was ganz tolles!? Gruss, Robert
@robert: atmel hat schon reagiert: http://www.atmel.com/dyn/products/view_detail.asp?FileName=ARMCortexLicense_6_24.html&family_id=605 gruss gerhard
der grosse Vorteil von ST und Luminary ist das man die jetzt schon in allen Variationen kaufen kann.
Also meine Applikation soll über CAN mit anderen Systemen kommunizieren können, aber parametrieren / diagnostizieren mit USB. Wenn man beides nicht gemeinsam nutzen kann, dann ist der Chip nicht brauchbar.
@LPCler was soll ich sagen... niemand sagt das die Chips eierlegende Wollmilchsaeue sind. Da heist es dann entweder USB oder CAN extern anbinden, oder halt warten bis die bis dato schlafende Konkurrenz aufgewacht ist. Bei LPCs ist da dann aber mit einzukalkulieren das sie die CAN Funktionalitaet auch schon das eine oder andere mal mit Bugs totgelegt haben. cu Tarzanwiejane
Naja ich bin kein Experte für ARM's aber ich sag nur mal eins wenn auch kurz mal NXP vor ist wirds nicht lange dauern bis die konkurrenz was gleichwertiges oder sogar besseres auf den Markt wird. Also die Wahl ist dann eher von kleinen Details abhängig oder einfach der Entwicklungsumgebung und nicht wirklich von der Architektur oder Aufbau. Wie heißt es Konkurrents belebt das Geschäfft und wie schon gesagt kann nur Vorteile bringen, außer der nutzer wird als Betatester benutzt! Was ich eher für unwahrscheinlich finde und jeder Chip hat seine Weh Wehchen ;-)
> Pins, bzw. die internen pads sind teuer, da wird wieder stark > gemultiplexed. Beim M16C kann man einige wenige Leitungen der RS232 auf verschiedene Pins umkonfigurieren. Ich finde das Konzept ist ausbaufaehig. Warum kann man also nicht fuer die wichtigsten Funktionen in einem Register festlegen an welcher STelle man sie haben will? Olaf
Silabs 8051er gibt es auch mit Crossbar Switch. Ist eine feine Sache, sowas sollte es auch in den ARMs geben. Was NXP angeht, so denke ich, daß sie sich ähnlich wie mit den LPC2000ern im Markt schon stark festsetzen werden. Alleine das Memory Accelerator Module dürfte die NXP-Teile in der Geschwindigkeit von den anderen absetzen. Kommen halt ein bißchen spät. NXP wollte sich den LPC2000er Markt nicht kaputtmachen. Die Frage ist nur, ob sie nicht ein bißchen arg lange gewartet haben.
Ich habe vor einigen Wochen auf einer russischen Seite (wo auch sonst...) gelesen das NXP erst auf den überarbeiteten M3 Kern warten wollte. Der Kern den ST und Luminary verbauen hat ja offenbar noch einige Bugs. Aber wenn von Q1/09 die Rede ist wird das wohl er Mitte '09 bis die Teile tatsächlich verfügbar sind. Mit Verfügbar meine ich den Zeitpunkt an dem ich so ein Ding bei mir auf dem Tisch liegen kann. Kaufleute definieren das manchmal etwas anders.
>Ich habe vor einigen Wochen auf einer russischen Seite (wo auch >sonst...) gelesen das NXP erst auf den überarbeiteten M3 Kern >warten wollte. Der Kern den ST und Luminary verbauen hat ja offenbar >noch einige Bugs. Jeder Kern hat Bugs... Und NXPler hat doch geschrieben, daß NXP die neue Rev2 vom M3 nutzt. Interessant ist bei dem vor allem der schnelle WakeUp Interrupt. Allerdings werden Luminary und ST den auch schnell in eigenen MCs einsetzen. Mit Mitte 09 gebe ich Dir Recht, was die Verfügbarkeit für uns "Hobbybastler" angeht. Vorher wird der Reichelt und Co. sicherlich nicht auftauchen, was ich sehr schade finde.
> Also meine Applikation soll über CAN mit anderen Systemen kommunizieren > können, aber parametrieren / diagnostizieren mit USB. > Wenn man beides nicht gemeinsam nutzen kann, dann ist der Chip nicht > brauchbar. Die CAN Pins (und auch einige andere Pins) lassen sich auf andere Ports remappen. Such mal im Reference Manual nach can_remap. Gruß, Stefan
sorry, habe gerade im Manual gefunden: zwar lassen sich die CAN-Pins remappen, ABER: sowohl CAN als auch USB verwenden denselben 512 Byte Puffer. Deshalb kann man beide Schnittstellen nicht gleichzeitig im System verwenden. Es ist aber möglich, beide Schnittstellen-Ports anzuschliessen und in der Firmware zwischen USB und CAN umzuschalten (ich kann mir aber keine Applikation vorstellen, der das weiterhelfen würde). Gruß, Stefan
Hallo Allen, herzlichen Willkommen an der neuen LPC1000 NXP Familie auch von STM Seite ;-)! Wir sind auch der Meinung von Robert und Patrick; am Endeffekt ist es nur von Vorteil für die Anwender sich mit dem CortexM3 zu beschäfftigen wenn ein grösseren Wahl von Anbieter gibt... sonst bindet mann sich wieder an einer proprietär-Lösung. Zum Thema, gleichzeitige Kommunikation von CAN & USB, ja müssen wir zugeben, dass wir da ein bischen zu viel optimiert haben. Die kommende Generation werden es berücksichtigen. Zum Thema Core Revision, es stimmt schon dass manche Firma versuchen die im STM32 eingesetze Version schlecht zu reden. Am besten Ihr entscheidet mal selbst auf die Basis vom ARM offiziel errata: http://infocenter.arm.com/help/topic/com.arm.doc.eat0420a/Cortex-M3-Errata-r1p1-v0.2.pdf Der STM32 basiert sich auf die "r1p1-01rel0". Die 3 Erratas sind minor eingestuff (cat3), die dritte trifft der STM32 sogar gar nicht da er kein MPU hat (463769). Zum Thema 12-bit ADC.... der STM32 bietet schon 2 und sogar 3 Stück davon. Die Messqualität ist auch meine Meinung nach sehr interessant 1.3-2 LSB Typische Total-Error (siehe Datenblatt). 12-bit DACs sind auch dabei. Heute stehen mehr als 40 verschiedene STM32 Produte zur Verfügung. Von 32kB Flash in QFN36 bis 512kB in QFP144, pin-to-pin Kompatible per Package. Alle version sind voll-qualifiziert (kein ersten buggy silicon), die Limitierung sind bekannt und auf dem Web verfügbar. Bitte bediennt Euch ;-)! Viele neue Derivaten sind auch in dem Pipe.... Ihr bekommt auch bald eine andere alternative zum "CortexM3 mit Ethernet + OTG".... schau ma-mal! Grüss, Thomas PS: Ich finde selber toll dass europaischen Firmen wie ARM, ST, NXP und ATMEL (ARM Entwicklung ist in Sud-Frankreich), innovative MCUs am Markt bringen; und dass wir nicht aus fernost Anbieter abhängig sind. Persönnlich sehe ich mehr die ARM Welt als eine Community, mit dem Ziel endlich einen guten MCU-Industry standard zu setzen. Die ganz oben gelinkte Präsentation enthält viel fragwürdiger Argumente, ich wünschte mir ein bischen mehr Fair-Play, Fakten und weniger BS....
Das wichtigste an einem Käfer mit vielen Füssen ist für mich - Preis - unterschiedliche Gehäuseformen - umfangreiche Pheripherie und vor allem Bugfrei - ein paar K RAM zum mal was zu Buffern (UART usw.) - Pheriepherie einfach zu benutzen mit kleinen überschaubaren Demos zu jeder Funktion die es gibt - günstige Entwicklungsumgebungen - Betriebssicher / EMV Das unwichtigste ist eigentlich die CPU solange sie - schnell genug ist - der Anforderung nicht zu viel Strom zieht - am besten kein Bauteil drum herum benötigt STM32 erfüllt bis auf sehr wenige Abstriche (USB/CAN, MAC) all diese Anforderungen. Alles andere ist ausdrücklich LOBENSWERT !!! Weiter so. Bis ich NXP so loben kann, muss ich erstaml noch warten...Ausser die LPC23xx die sind ebenfalls SUPER!!! Ich werde in der Zukunft nur noch CPUs aus der ARM und Cortex Welt nutzen. Ich habe einen STM32 Cortex mit 48 Pins im Einsatz. Die Hardware habe ich anhand des Datasheets und dem Errata designt. Ergebnis: Alles funktioniert!!!
@viel neues: Tausch mal Deine Tastatur, die Ausrufezeichen-Taste ist defekt. Ansonsten klingt Dein Beitrag wie Guerilla-Marketing. Arbeitest Du für ST?
@thomas von ST Hallo Thomas, freut mich sehr, dass noch ein Firmenvertreter mit einem offiziellen Beitrag gestartet hat. Mir hat das manchmal Aerger gebracht, hoffe Dir geht das besser. Zwar bin ich nicht mehr bei NXP, doch werde ich weiterhin der ARM-Welt sehr verbunden sein. Auf gute Diskussionen hier im Forum. Robert
Hi Ich hab mit dem ARM Cortex M3 von ST meine ersten Gehversuche in der ARM Welt gemacht zu einen Zeitpunkt als noch jeder davon abgeraten hat allerdings war des kein Fehler gerade bei der menge an Material die man bekommen konnte da blieben eigentlich keine wünsche übrig, das einzige ärgerliche sind die Schweine teuren Entwiklungs tools aber so wie ich gesehen habe gibs mittlerweile auch einige Opensource sachen.
Ich find es toll, wenn sich Mitarbeiter der Firmen hier zu Wort melden, auch Deine Beiträge Robert habe ich immer gerne gelesen, auch wenn ich selber bisher noch nicht viel mit Controllern von NXP gemacht hab. Ich werde sie mir aber sicher auch mal anschauen, sobald die LPC1700-Familie auf dem Markt ist. Derzeit arbeite ich auch mit den STM32-Controllern, bin da wie viele Andere aber enttäuscht, daß USB und CAN nicht gleichzeitig funktionieren. Für ein paar hundert Byte mehr RAM hat es bei der Entwicklung dieser tollen Controller nicht gereicht, schade. Nochmal hier an alle Entwickler von Microcontrollern: Es ist gar nicht so selten, daß man USB und CAN-Bus gleichzeitig bei einem Controller braucht. Und kleine Bauformen sind auch gefragter denn je, die STM32 im 48-poligen LQFP-Gehäuse sind absolute Klasse (wenn USB und CAN gleichzeitig funktionieren würden, sogar Superklasse). Bit die ersten Cortex-M3 Controller von NXP und von ATMEL erhältlich sein werden, wird aber wohl noch einige Zeit vergehen und ST wird sicher in dieser Zeit auch nicht untätig sein. Mein Wunsch wäre noch ein STM32 mit Ethernet MAC und PHY (wie bei den Controllern von Luminary Micro). Erwin
@ Robert, schön wieder was von Dir zu hören (besser gesagt lesen) und dass du noch was mit ARM zu tun hast. Wie hier schon beschrieben sehe ich ARM auch als eine community und man hat immer wieder was miteinander zu tun. Melde Dich doch mal. Gruss Kurt
Torben wrote: > Jeder Kern hat Bugs... So ist es. > Und NXPler hat doch geschrieben, daß NXP die neue Rev2 vom M3 nutzt. > Interessant ist bei dem vor allem der schnelle WakeUp Interrupt. Der WakeUp Interrupt Controller (WIC) der Rev2 hat gewiss viele Vorteile, schneller als ein Rev1 NVIC ist er jedoch nicht. Bestenfalls gleich schnell. Typisch eher geringfügig langsamer, da der WIC die Information erst an den NVIC weiterleiten muss. Gruß Marcus
STM32 in 90 nm!? Extrem unwahrscheinlich. Ich kenne mich mit Prozessen ziemlich gut aus und der 90nm Flash Prozess ist 1. noch in einem sehr fruehen Stadium und 2. noch schweineteuer. 3. Sind die Werte fuer Leakage in 90nm so hoch, dass der STM32 in der Naehe von 1mA Ruhestrom haette, ohne Takt ohne irgendetwas aktiv. Bisher kenn ich nur wenige MCUs in 90nm und das sind viel komplexere Teile als der STM32. Falls die Frage heisst ob ST dem STM32 in Zukunft in 90nm fertigen kann, dann ist die Antwort, wahrscheinlich schon, evtl. mit ein paar Aenderungen in der Spec.
Na, Robert, so gut kennst Du Dich dann doch nicht aus. Natürlich hat ST auch 90er M3s im Angebot. Das sind allerdings nicht die LowCost STM32, sondern die ST32 und ST33er. Die sind primär für SmartCards oder Simcards gedacht. Andere 90nm MCs sind zum Beispiel der SuperH von Renesas (SH72546RFCC, war die erste 90nm Flash MCU), der LPC3180 von NXP, SPC56x (Power-basiert) von ST. Die Technik wird also beherrscht. Interessanterweise wird eine 300er Fab von NXP, Freescale und LPC für den 90er Flash Prozess gemeinsam betrieben...
@ Dirk, Kann schon sein, dass ich einfach vorausgesetzt habe, dass jeder weiss was ein STM32 ist, das ist naemlich der Name der general purpose microcontroller von ST. Der Renesas spielt in einer anderen Liga. Der Preis, der 2007 angekuendigt war ist $980 ;-) Der LPC3180 ist in 90nm gefertigt aber definitiv kein Flash. Koennte es sein, dass sich Deine Info von einer gemeinsamen Fertigungslinie NXP und Freescale auf Grolles bezieht? Falls ja, diese Zusammenarbeit wurde vor fast 2 Jahren aufgekuendigt, allerdings sind die ersten LPC3180 tatsaechlich noch in dieser 90nm Fab gelaufen. Der SPC56x ist ein Gemeinschaftsprodukt von Freescale und ST und es wuerde mich sehr interessieren ob Du schon mal was von Mustern gehoert hast, nicht fuer den breiten Markt, sondern fuer die ersten Automotive Key Accounts. Im uebrigen stehe ich zu allen Aussagen, sehr frueh, schweinteuer und high leakage. Die ST32 und ST33 waren allerdings eine Ueberraschung, das gebe ich gerne zu. Zwar sind das (aus meiner Sicht) keine Microcontroller in dem eigentlichen Sinn, sondern ASICs, aber sie sind doch sehr nahe der niedrigen Komplexitaet des STM32, wenn auch mit dem secure core. Chipcard und ASICs benuetzen neuere Prozesse als Standard Microcontroller. Der STM32 ist ein Standard microcontroller. Danke fuer die Info. Robert
T. E. wrote: > Heute stehen mehr als 40 verschiedene STM32 Produte zur Verfügung. Von > 32kB Flash in QFN36 bis 512kB in QFP144, pin-to-pin Kompatible per > Package. Alle version sind voll-qualifiziert (kein ersten buggy > silicon), die Limitierung sind bekannt und auf dem Web verfügbar. Bitte > bediennt Euch ;-)! Kein "buggy silicon"? Bin vor einiger Zeit über folgendes gestolpert: http://www.st.com/stonline/products/literature/es/14574.pdf (2.6) http://www.st.com/mcu/forums-cat-7336-23.html&start=30 Rev B und Z sind wohl als "limitiert" aber nicht "buggy" eingestuft. Habe bisher nur wenig mit STM32 gespielt aber die Informationen unter o.g. Links erscheinen mir sehr beachtenswert. Wenn richtig verstanden insbesondere für diejenigen, die Geräte mit STM32 REV!=Y verkauft haben und gelegentlich Firmware-Updates für Endkunden bereitstellen.
Wow, vor allem die Compiler-Geschichte ist ja krass. Da blitzen ja wieder die guten alten Tugenden aus der STR9 Zeit wieder auf... Nene, da bleib ich lieber bei Luminary, die sind da schon verlässlicher und seriöser als ST und NXP.
Hallo Martin, der STM32 ist im Markt in November 07 mit der Revision Z eingeführt. Das heisst die Versionen A und B sind nicht in Markt verbreitet worden, bis auf ein paar Alpha-Kunde und die erste Batch von Tools von unserem third-Parties. Aber absolut keine Serie-Produktion. Daher bin ich immer noch der Meinung, dass ST die Zeit genommen haben und keinen "ersten Buggy Sillicon" im Markt eingeführt hat, bitte der "ersten" von meinen Beitrag nicht beim Cut&Paste vergessen ;-)! Für die wenige Kunde die Samples oder Tools mit der B Version erhalten haben, haben wir extra die B Version im Errata-Sheet aufgenommen. Seit der offiziellen Produkteinführung im Nov 2007 mit der Z Version ist diese neue Limitierung entdeckt worden (Errata 2.6). Dazu kommt dass diese Limitierung nur nach der Einführung von bestimmten Compiler Optimierung entdeckt werden konnte. Diese Optimierung ist nur im Summer 08 von IAR und GCC entwickelt & implementiert worden, d.h. nur ab dann könnte man die Schweirgkeite sehen (ca 8 Monate nach Produkteinführung!). Was betrifft Kunde die Projekte haben, und mit der Z Version gestartet haben (wie oben geschrieben, B ist kaum gesampelt worden) hast Du Recht mann söllte für on-site Update aufpassen. In dem Fall söllte man mit der IAR version <5.2 oder GNU <4.2.3 weiterhin diese Update compilieren. Ich gebe zu es zwar nicht schön, hoffen wir aber nicht zu beeinträchtigend. ST liefert seit Ende Sommer 2008 keine Bauteil mehr, die diese Limitierung hat. Es betraff nur die 64kb, 128Kb und teilweise die 32kB (ohne A am Ende). Für alle anderen konnten wir es noch rechtzeitig vor Einführung korrigieren. Ich hoffe es hilft die Lage und Hintergründe zu klären. Mit freundlichen Grüssen, T.E. PS: Robert, mit dem 1mA in standby für den STM32 in 90nm bist Du schon gemein mit unserem Designers. Soooo schlecht sind Sie wirklich nicht ;-)!
@T.E. Na dann bin ich mal gespannt auf einen 90 nm Flash Chip, der bei 85C im Datenblatt unter 1mA spezifiziert ist. "Typisch bei Raumtemperatur" das kann schon sein aber garantiert bei 85C wird Leakage extrem hoch im 90 nm. Man kann natuerlich die interfaces in groesseren Geometrien bauen und Teile dann komplett abschalten aber das steckt doch noch etwas in der Erprobungsphase. Ich war lange genug im Design solcher Chips unf freue mich, dass Du Dich hier als Mitarbeiter von ST zu erkennen gibst. Dadurch werden Dich zwar mal wieder einige angreifen aber insgesamt bringt es mehr Glaubwuerdigkeit fuer den Chiphersteller sich hier dem Forum zu stellen. Danke und Gruss, Robert
@ Robert: Was sagt eigentlich die Glaskugel bezüglich Atmel? Die ersten Hinweise auf einen Cortex-Controller gibts ja sogar schon auf http://www.atmel.com/products/at91/default.asp Weiß man da schon genaueres wann es losgeht? Jens
@Robert > aber garantiert bei 85C wird Leakage extrem hoch im 90nm Ich gebe Dir natürlich Recht: 90nm & Leakage beim höherer Temperature bleibt ein Challenge... und zwar für alle Siliziumhersteller ;-). Aber wie Du auch weisst, das ist genau der Punkt wo die Hersteller sich differenzieren können, insbesondere die, die noch selber Ihre Prozess selber entwickeln und für bestimmte Zweck optimieren können. Naja schau ma mal... wie oben von Dirk erwähnt sind unsere Automotive & Chipkarten schon dabei am Erfarung zu sammeln. > Dadurch werden Dich zwar mal wieder einige angreifen Das gehört dazu, wenn die Hersteller optimal & 100% Bugfree Produkte immer liefern würden, dann würden wir die auch nur Lob ernten.... Ist leider nicht die gangige Realität. Ich kann verstehen das manche Kommentaren "leicht bissig" werden können, insbesondere wenn sie von einem Bug betroffen sind. Aber seien wir auch ehrlich, es gibt wenig SW-Entwickler die selber 100% Bugfree code schreiben ;-)! Laut eine Studie von IBM in den achtziger, gab es im Schnitt 1 Bug pro 1.5kB geschriebene Code, und zwar ziemlich konstant vs Application oder Entwicklern. Wenn wir die SW's kB in SW's kGate umwandeln würden, dann söllten die MCU's errata ein paar Tausende Seite dick sein... ist glücklicherweise nicht den Fall... aber die Silizium Hersteller sind immer wieder die Bösen ;-)! Schönen Abend, Thomas Alias T.E.
@ Jens, ein M3 derivat ist definitiv in Entwicklung bei den Kollegen von Atmel. Genaueres weiss ich allerdings auch nicht. Habe mitte des Jahres mit ATML Marketing gesprochen und da war eine Andeutung zum Jahresende (08), glaube ich jetzt allerdings nicht mehr, da waeren schon mehr Details bekannt. Auf jeden Fall erwarte ich eine Spezifikation und early samples in der ersten Haelfte '09, so richtig auf dem Markt dann wohl eher 2. Haelfte. Wie du schon gesagt hast, da ist die Kristallkugel maechtig im Spiel und der bekannte Zugzwang jetzt mit einem M3 derivat auf den Markt zu kommen. Happy Thanksgiving! Robert
T. E. wrote: diesmal ohne cut&paste... > Hallo Martin, > > der STM32 ist im Markt in November 07 mit der Revision Z eingeführt. Das > heisst die Versionen A und B sind nicht in Markt verbreitet worden, bis > auf ein paar Alpha-Kunde und die erste Batch von Tools von unserem > third-Parties. Aber absolut keine Serie-Produktion. > > Daher bin ich immer noch der Meinung, dass ST die Zeit genommen haben > und keinen "ersten Buggy Sillicon" im Markt eingeführt hat, bitte der > "ersten" von meinen Beitrag nicht beim Cut&Paste vergessen ;-)! Und ich bin der Meinung, dass dies Ansichtssache ist. Ich stimme dieser pauschalen Meinung nicht zu. Wenn es kein erstes (zweites oder drittes) "buggy silicon" wäre, gäbe es kein Errata. Oder was unterscheidet "buggy" von erratum? Meine Meinung ist aber auch unerheblich, da ich derzeit genau einen STM32 (Rev Z wenn richtig erinnert) auf einem Eval-Board gelegentlich (gelegentlich, da sehr ungewöhnliches integriertes JTAG-Interface) im Einsatz habe und somit das krasse Gegenteil von einem wichtigen Kunden bin. Nichts desto trotz dient dieses Forum dem Austausch von Informationen und mein Beitrag oben war die Information die ich auch als nicht-STM32-Großanwender nach "kein erstes buggy sillicon" geben wollte, da das Optimierungsproblem im Codesourcery Forum erwähnt wurde und ich ich so auf das ST-Forum und Abschnitt 2.6 des Errata Sheets gestoßen bin. > Für die wenige Kunde die Samples oder Tools mit der B Version erhalten > haben, haben wir extra die B Version im Errata-Sheet aufgenommen. > > Seit der offiziellen Produkteinführung im Nov 2007 mit der Z Version ist > diese neue Limitierung entdeckt worden (Errata 2.6). > > Dazu kommt dass diese Limitierung nur nach der Einführung von bestimmten > Compiler Optimierung entdeckt werden konnte. Diese Optimierung ist nur > im Summer 08 von IAR und GCC entwickelt & implementiert worden, d.h. nur > ab dann könnte man die Schweirgkeite sehen (ca 8 Monate nach > Produkteinführung!). Sowas in der Art gibt/gab es bei anderen Controllern/Herstellern auch. Ist ja erstmal nicht dramatisch, wenn man weiß wonach man suchen muss. Mit dem Errata kann man allerdings nicht so sehr viel anfangen. Es sei dann man ist IAR-Anwender und gibt sich mit der Versionsnummer für <= : 'gut' > : 'nicht gut' zufrieden. Nur ein paar Vorschläge/Gedanken dazu: (1) Es gibt es keinen GCC 4.2 aus Originalquellen (gcc.gnu.org) mit ARMv7/Cortex-M3/thumb2-Unterstützung. Dafür wurden die GCC 4.2 Quellen durch Erweiterungen von Codesourcery angepasst, die nicht in den offiziellen Quellcode (gnu.org) der 4.2er-Serie eingeflossen sind. GCC im Hintergrund von Crossworks und SARM ist meines Wissens auch nur ein 'Recompilat' der Codesourcery-Quellen. Anwender, die GNU compiler <4.2.3 brauchen, dürften gut daran tun, möglichst zügig ein Paket mit einer alten Version zu besorgen, bevor diese im digitalen Nirwana verschwinden. Im Archiv von gnu.org wird man nicht fündig. (2) "Diese Optimierungen" und Errata-pdf lässt diverse Interpretationsmöglichkeiten zu. Kenne IAR EWARM kaum aber bei GCC kann man viele viele Optimierungsoptinen wählen. Welche nun kritisch ist, bleibt bis dato offen. Ist sicher, das es keine Kombination für CS g++ <4.2.3 ein "unsupported sequence" erzeugt? (3) Nutze selbst zwar RealView (im MDK-ARM) nur selten zum Spielen, aber nur aus Interesse frage ich mich, warum RealView nicht im Errata genannt wird. Warum gibt es darin die problematische Optimierung nicht? Weiß ARM mehr und hat geschickt um das Problem herumgearbeitet? Oder heißt das einfach nur, dass von RV schlechter optimierter Code erzeugt wird, was für Rev Y dann ja dann eher ungünstig ist? (4) Die neueren Compiler optimieren wohl nicht ohne Grund so. Es gibt scheinbar Codesequenzen, die zwar nach Meinung der Compilerbauer optimal sind, aber in den alten Chip-Revisionen zu Problemen führen. Viel besser wäre es, wenn man diese Sequenz(en) nennt oder zumindest etwas mehr Details gibt. Noch besser wäre es, wenn ST eine Software bereitstellen würde, die ein load-image (bin/hex) einliest und Alarm schlägt, wenn darin Problemstellen enthalten sind. Da das Errata aber recht oberflächlich bleibt, kann man allerdings auch nicht abschätzen, ob so etwas überhaupt möglich ist. Hatte vor einiger Zeit einen solchen Kritische-Stellen-Sucher einem anderen Hersteller vorgeschlagen, da es dort bei inzwischen wohl ebenfalls renovierten Controllern ähnliche Probleme gab. Wurde leider nicht aufgegriffen. Jedes mal, wenn der Controller bei Tests während der Entwicklung dann "komisch" reagiert hat, hatte ich die Erratas im Hinterkopf und wusste nicht, ob ich selbst Mist gebaut hatte (sehr wahrscheinlich) oder ob man 'Glück' hatte und der Compiler grade die kritische Codesequenz erzeugt hat (unwahrscheinlich aber auch nicht unmöglich). > Was betrifft Kunde die Projekte haben, und mit der Z Version gestartet > haben (wie oben geschrieben, B ist kaum gesampelt worden) hast Du Recht > mann söllte für on-site Update aufpassen. In dem Fall söllte man mit der > IAR version <5.2 oder GNU <4.2.3 weiterhin diese Update compilieren. Ich > gebe zu es zwar nicht schön, hoffen wir aber nicht zu beeinträchtigend. Betr. GCC 4.2.x siehe oben. Aber klar, besser diese Information als gar keine. > ST liefert seit Ende Sommer 2008 keine Bauteil mehr, die diese > Limitierung hat. Die Groß- und Einzelhändler auch nicht? Scheint nicht ganz einfach zu sein, vorher zu klären, welche Revision geliefert wird, zumindest wird das in einigen Beiträgen im oben genannten Thread aus dem ST-Forum behauptet. > Es betraff nur die 64kb, 128Kb und teilweise die 32kB > (ohne A am Ende). Für alle anderen konnten wir es noch rechtzeitig vor > Einführung korrigieren. Also ein Problem bei Zugriff auf den Flash-Speicher? > Ich hoffe es hilft die Lage und Hintergründe zu klären. Für mich nur etwas aber ist für mich auch nicht so wichtig. Wenn denn "hier" mal ein kommerzielles Projekt mit STM32 ansteht, werden wohl Rev Y oder neuer zum Einsatz kommen. Hintergründe dienen aber sicher der Erhellung 'alter' STM32-Anwendern. > > Mit freundlichen Grüssen, > > T.E. Mit ebenso freundlichen Grüßen mt > > PS: Robert, mit dem 1mA in standby für den STM32 in 90nm bist Du schon > gemein mit unserem Designers. Soooo schlecht sind Sie wirklich nicht > ;-)!
Offen gesagt kann ich den "M3-Hype" nicht ganz verstehen. Das sind sicherlich ganz tolle Controller. Aber die ARM7 Controller sind jetzt schon eine ganze Weile auf dem Markt und die Neuerungen des M3 sind nicht gerade gravierend. Trotzdem soll der M3 nun das schaffen was der ARM7 bisher nicht erreicht hat: Die Ablösung der 8Bitter. Was ist beim "Cortex M3" denn so toll? 50% kleinere Programme mit Thumb2 anstelle von ARM Code? Schön. Aber bei den heutigen Flash-Preisen nicht gerade beeindruckend. Der sagenhafte NVIC bietet verschachtelte Interrupts und kurze Latenzen. Das liest sich sehr gut im Whitepaper. Aber wer braucht das wirklich? Mehr als 2% der Entwickler? Nun gibt es natürlich Leute die sagen der ARM7 sei zu kompliziert und der M3 sei deshalb genau das Richtige. Ich glaube das diese Leute sehr bald von der Realität eingeholt werden. Denn im wirklichen Leben setzt man 32Bit Controller dort ein wo sie gebraucht werden. Und die Probleme die damit gelöst werden sollen sind um einiges schwieriger als ein Startupfile von Hand im Makefile einzutragen weil der Compiler kein eigenes hat. Der LPC17xx mag ja ganz toll sein. Solange er nicht lieferbar ist, bringt der niemanden etwas. STM32 ist auch nicht schlecht. Ohne Ethernet kann er aber in der heutigen Zeit in einem beträchtlichen Teil der Anwendungen nicht sinnvoll verwendet werden. Ethernet ist wichtiger als CAN. Und Luminary entwickelt komplett am Markt vorbei. Das sind keine echten 32Bitter, sondern komplizierte 8Bitter. Auf die ARM7 oder auch ARM9 Controller muß man nicht warten. Da gibt es kein "ist geplant, kommt bestimmt bald". Die sind lieferbar und die Fehler sind bekannt. Es gibt sie von 48 bis 320 Pins, mit und ohne DMA, I2S, CAN, Ethernet, MMU, GPU, ... Ich gehe jetzt erstmal fernsehen. Das hat mich früher zwar nie interessiert aber SAT1 hat jetzt ein tolles neues Logo...
@karsten: aus meiner sicht ist der "m3 hype" wie du es nennst sehr wohl berechtigt da dieser core nahezu alle probleme/schwächen des arm7 behebt. und wenn du mal versucht hast zeitkritische anwendungen mit dem arm7 zu realisieren wirst du dich nach einem cortex m3 sehnen. aus meiner sicht haben die chiphersteller (atmel, nxp, st) einfach zu lange mit dem einstieg in die m3 welt gewartet. den core selbst gibt es ja schon einige zeit aber erst luminary hat offensichtlich die grossen hersteller wachgerüttelt und nun bekommen sie alle den stress und werfen produkte auf den markt die gerade mal das alpha stadium erreicht haben. @jens betreffend dem atmel at91sam3: ankündigungen gibt es schon einige zeit, bisher habe ich von den distis allerdings nur schöne powerpoint shows gesehen. aus meiner leidvollen erfahrung mit atmel würde ich von einem design mit dem at91sam3 abraten, ausser du hast zeit bis mind. ende 09. gruss gerhard
@Karsten + Gerhard, irgendwo habt ihr beide recht. Fuer die meisten Anwender sind die Verbesserungen des M3 Evolution, keine Revolution, andererseits sind tatsaechlich die grossen Schwachpunkte des ARM7 adressiert und stark verbessert. Der Hauptgrund der spaeten Annahme durch die genannten Firmen war zum einen, keiner wollte Alpha-Tester sein, der ARM7 brauchte mehrere Jahre bis er ganz stabil war und zum anderen die Tatsache, dass es die ARM Lizenzvereinbarungen recht kostspielig machten mit M3 anzufangen. Der M3 ist der einfachste 32-bit Core den ich kenne und somit kann er am meisten den Anspruch der 8-bit Abloesung erheben. Es ist auch klar, dass 8-bit noch VIELE Jahre da sein wird aber neue Entwicklungen, die ein Potential haben zu wachsen sollten den M3 mindestens in Erwaegung ziehen. Viel Spass noch mit der M3 Diskussion Robert
gerhard wrote: > aus meiner sicht haben die chiphersteller (atmel, nxp, st) einfach zu > lange mit dem einstieg in die m3 welt gewartet. den core selbst gibt es > ja schon einige zeit aber erst luminary hat offensichtlich die grossen > hersteller wachgerüttelt und nun bekommen sie alle den stress und werfen > produkte auf den markt die gerade mal das alpha stadium erreicht haben. Wurde LuminaryMicro nicht von ARM gegründet? MfG Thomas Pototschnig
@ NXPler
> eigentlich schade, daß die Infos von NXP immer zuerst auf russischen
Seiten auftauchen
Ist ja eine interessante Seite! Danke für den Tipp.
gerhard wrote: > aber erst luminary hat offensichtlich die grossen hersteller wachgerüttelt > und nun bekommen sie alle den stress und werfen produkte auf den markt > die gerade mal das alpha stadium erreicht haben. Zufall oder Strategie? Verschwörungstheoretiker finden es durchaus bemerkenswert, dass ein Startup innerhalb kürzester Zeit mit einer derartigen Produktpalette rauskommt. Stichwort "pipe cleaner". Das ist ganz normal in der Industrie. @karsten Weitere Vorteile sind einfache Fertigung. ARM7 ist vor allem so billig zu haben, weil die Lizenzkosten so gering sind. C-M3 wurde auch in Hinsicht auf die Fertigungskosten optimiert. Was nested interrupts angeht, beißt sich ja die Katze in den Schwanz. Warum werden sie auf ARM Prozessoren kaum eingesetzt? -- Weil sie kompliziert aufzusetzen sind. Der set-up code ist zum Teil länger als die eigentliche Routine. Man hat sich daran gewöhnt, mit workarounds zu leben. Gruß Marcus http://www.doulos.com/arm/
Der Cortex-M3 Hype entstand einfach durch seine gute Performance. Für Sensorik ist der STM32F einfach perfekt, da man die zwei 1M Sample 12BIT ADC simultan betreiben kann. Durch die "Hardware division" schaffe ich schließlich eine 16bit arctan Berechnung in 36 Takten. Für einen Controller in der Preisklasse schon gewaltig.
Marcus Harnisch wrote: > Was nested interrupts angeht, beißt sich ja die Katze in den Schwanz. > Warum werden sie auf ARM Prozessoren kaum eingesetzt? -- Weil sie > kompliziert aufzusetzen sind. Der set-up code ist zum Teil länger als > die eigentliche Routine. Man hat sich daran gewöhnt, mit workarounds zu > leben. Wenn du mit set-up code das Retten der Register usw meinst, dann gibts das nicht mehr beim M3. Der rettet alle Register beim Sprung in die ISR selbstständig auf irgendeinen Hardware-Stack. Das interessante ist dann, dass es deterministisch und immer konstant (ich glaube) 12 Taktzyklen braucht, bis er den ISR-Code ausführt. Wenn dann noch ein Interrupt kommt, dann braucht er immer zusätzliche 6 Taktzyklen, bis der ausgeführt wird. Ich finde das Konzept schon ganz interessant. Vorallem der Interrupt-Kram war bei den normalen ARM7 abschreckend ... MfG Thomas Pototschnig
Thomas Pototschnig wrote: > Wenn du mit set-up code das Retten der Register usw meinst, Ggf. mode change usw. Schon klar. > dann gibts das nicht mehr beim M3. Der rettet alle Register beim Sprung > in die ISR selbstständig auf irgendeinen Hardware-Stack. Zum Glück nicht auf "irgendeinen", sondern auf den Stack der aktiv war als der Interrupt aufgetreten ist :-) Mein Argument war ja gerade, dass sich die ARM user daran gewöhnt haben, nested interrupts am besten zu vermeiden. Deshalb sehen sie das nicht unbedingt als Vorteil des Cortex-M3. Das tail-chaining (hast Du schon angedeutet) ist ebenfalls eine Verbesserung, und unterbrechbare multi-cycle Befehle wurden in diesem Zusammenhang noch gar nicht genannt. > Ich finde das Konzept schon ganz interessant. Vorallem der > Interrupt-Kram war bei den normalen ARM7 abschreckend ... Genau. Ein weiterer wesentlicher Vorteil des CM3 ist die Debug Architektur. Gruß Marcus http://www.doulos.com/arm/
@Thomas Luminary wurde nicht von ARM gegruendet aber ARM hat einen ordentlichen Teil der Finanzierung in dieser Startup gemacht. Weil keiner der grossen auf M3 eingestiegen ist, wurde eine Startup dazu "ermuntert / enabled". Der ARM Marketing Manager fuer M3 hat NXP, Atmel und ST hochfrequent gepollt und um Beteiligung gebeten ;-) Zum Thema warum der Hype? ein grosser Grund sind die mehrfachen Millionen die ARM in die Marketingkampagne gesteckt hat. Auch sind die Vergleiche von ARM selbst zwischen ARM7 und M3 etwas manipuliert, z.B. Algorithmen mit vielen DIV Befehlen, die es beim ARM7 nicht gibt aber beim M3 wohl ergeben einen unrealistischen Performance Vorteil des M3. Ich stehe au der Aussage, dass ein guter Programmierer aus einem ARM7 bei derselben Frequenz und derselben Bandbreite aus dem Speicher sehr aehnliche Performance rausholen kann, weniger als 10 Prozent Unterschied, sofern die zeitkritischen Programmteile im ARM Mode und die unkritischen im Thumbmode geschrieben werden. Auch der Unterschied in der Programmgroesse ist minimal. Das Problem ist, es braucht einen guten Programmierer, zusaetzliche Zeit zu qualifizieren, was ist zeitkritisch, was nicht und die Implementierung ist deutlich komplexer. Der langen Rede kurzer Sinn, beim ARM7 "steckt der Teufel im Detail ;-)" Laengere Entwicklungszeiten, Huerden beim Debuggen, die duerftige Interruptstruktur sind alles Argumente, die ein M3 wegraeumen kann. Also was bringt der M3: ======================= - Performance Steigerung: wenig - Debug Verbesserung: deutlich mehr - Kleiner Core: vernachlaessigbar in neuen Technologien (<1 cent Vorteil) - Weniger Power: bisher noch nicht so sichtbar, es gibt lower Power ARM7 aber vom Konzept her richtig - Interrupt: Starke Verbesserung (ziemlich aehnlich dem 18 Jahre alten C166) - Reduzierung in der Komplexitaet: ne ganze Menge - Gesamtpaket: deutliche Verbesserung weil Schwachstellen gezielt angegangen wurden Robert
Ich nutze in einer Messtechnik Schaltung auch den STM32F103. Ich habe zwar ein problem mit dem AD-Wandler, da ich recht komplexe AD Wandlungen machen wollte und die Injected-Chanel Konfiguration nicht klappte, aber das ist was anderes. Ich konnte das ganze doch noch so umprogrammieren, dass es ohne Injected auch ging. Meine Aufgabe war ein Spitzenwertgleichrichter, der mit 20KHz sampelt pünktlich im Null-Durchgang für x us zu entladen. Dabei ist das Timing enorm wichtig, AD-Messung, Entladen, alles vor dem nächsten Lade-Impuls. Und das läuft ohne Probleme mit diesem Prozessor, sogar ist auch noch USB im Hintergrund aktiv! und noch viele andere Berechnungen. Hier halfen mir die vielen HW-Breaktpoints (6 Stück!) natürlich auch weiter, und ich habe mir in echtzeit Variablenwerte als PWM-Ausgang ausgegeben, damit konnte ich online am Oszi sehen welche Werte die Variablen hatten. Ein wirklich starkes Stück, der STM32. Ich werde wohl nie wieder freiwillig 8-Bitter einsetzen. PS: Das Projekt sollte ursprünglich mit einem dsPIC30 realisiert werden, dann konnte ich meinen Chef doch noch von einem Redesign überzeugen. Der war für diese Aufgabe viel zu schwach, abgesehen davon dass ich eine zweite CPU für USB benötigt hätte. @NXP: Wenn der LPC1768 mal kommen sollte, dann doch bitte mit MMC-Interface. Bitte, bitte, bitte... (wie beim LPC2368, das brauche ich nämlich) Vorteile der 8-Bitter: - Keine, ausser DIL-Gehäuse. Wenn jemand eine kleine Quellcode-Lib aufbaut, dann ist es immer mit Aufwand verbunden den an eine andere CPU anzupassen. Also ist es auch für das Hobby ideal eine kleine Anwendung mit einem Cortex M3 zu machen, auch wenn der nur Bits schiebt. Es geht darum Code wieder verwenden zu können. Wenn man mehr braucht, dann hat man das gleich zur Hand, ohne erst eine völlig neue CPU kennen lernen zu müssen. Und SOOOO viel overhead gibt es bei Cortex und ARM auch wieder nicht. Eigentlich nur, dass man Clock und Power der einzelnen Pheriperie-Module noch aktivieren muss. Und ST hat eine Super FW-Lib und Demos die diese eine Lib nutzen, also es gibt nur eine einzige Lib. Nicht wie bei anderen Firmen eine Menge App-Notes die zueinander nicht passen. Für LED Ansteuern ist ein STM32 oversized ? -- Niemals. Ich habe gerade eine neue Schaltung, da habe ich 12 LED's an der CPU dran. Nicht nur irgendwo dran, sondern nutze 12 PWM Ausgänge von 3 Timer-Modulen und ich kann nach belieben die Helligkeit einzeln ansteuern. Der vierte Timer macht das PWM für die Hupe (2 Ausgänge im gegentakt). Man hat die Möglichkeit - man nutzt die Möglichkeit - man hat mehr freude am Ergebnis. Nachteile der 32-Bitter (alle die 8-Bitter nutzen): - Neuer Prozessor - Neue Doku - Neue Programmierumgebung (z.B. Eclipse) - Neues JTAG-Interface (kostet Geld) - 3-6 Wochen Einarbeitungszeit (Blinkled ca. 1-2 Tage) Nachteile der 32-Bitter (alle die neu einsteigen) - keine, nur Vorteile. Demo-Boards gibts für die 32-Bitter auch schon für kleines Geld. (Ab ca. 30 EUR!)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.