mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik lpc1700 - ARM Cortex M3 von NXP: Endlich!


Autor: NXPler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: NXPler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: LPCler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Otto (tarzanwiejane)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-)

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@robert:
atmel hat schon reagiert:
http://www.atmel.com/dyn/products/view_detail.asp?...


gruss
gerhard

Autor: Thomas Otto (tarzanwiejane)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der grosse Vorteil von ST und Luminary ist das man die jetzt schon in 
allen Variationen kaufen kann.

Autor: LPCler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Otto (tarzanwiejane)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;-)

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: T. E. (Firma: STMicroelectronics) (stm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.e...

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

Autor: viel neues (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!!

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@viel neues:

Tausch mal Deine Tastatur, die Ausrufezeichen-Taste ist defekt.

Ansonsten klingt Dein Beitrag wie Guerilla-Marketing. Arbeitest Du für 
ST?

Autor: viel neues (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein. Ich arbeite für mich, www.mmvisual.de.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Erwin Reuss (er-tronik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

weiss jemand ob es stimmt das ST den STM32 in 90nm Tech fertigt ?
Gruss

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: T. E. (Firma: STMicroelectronics) (stm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;-)!

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: T. E. (Firma: STMicroelectronics) (stm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
> ;-)!

Autor: Karsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ NXPler

> eigentlich schade, daß die Infos von NXP immer zuerst auf russischen
Seiten auftauchen

Ist ja eine interessante Seite! Danke für den Tipp.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Reinhold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!)

Autor: omnix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
You can try this. Very good for the price. I'll order one soon surely.
http://beagleboard.org/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.