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