www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wirklich arm, der ARM


Autor: Lari Fari (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich im Zuge einer Neuentwicklung mit ARM-Prozessoren befasst 
und mir wurde von Kollegen innerhalb - aber auch aussehalb - öfters 
gesagt, der ARM (LPC ...) habe einige Bugs, vor allem im Umfeld des 
Cancontrollers.

Nun meine Frage: Gilt das für alle ARMs ? Kann mir jemand eine Type 
nennen, die einen stabilen CAN-controller hat ?

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ist kein ARM aber ist ein 32Bit Mikrocontroller mit SRAM 
Interface. DMA Mode usw. M32C/87.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ARM-Core hat gewisse Designfehler, aber von Bugs ist wenig bekannt.

Was du meinst, sind wohl die vielen Bugs in den Periphiere drum herum. 
Besonders Philips/NXP hat sich da unvergesslichen Ruhm erworben.

Fairerweise muss man zugestehen, dass die Anzahl Bugs mit der 
Komplexität der µController wächst. Und ARMs sind üblicherweise deutlich 
komplexer als AVRs.

Dass auch bei 8bittern gelingen kann, hochinteressante Buglisten zu 
produzieren, hat beispielsweise Microchip mit den PIC18Fxx8 bewiesen.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Grad CAN scheint sich eher zum "cannot" zu mausern. Was 
Microcontroller mit ebendiesem angeht. Bei o.A. PIC ist es nämlich 
wiederum der CAN-Controller, der für Ärger sorgt.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo

Nimm den TMS 470 von TI;
Dieser wird sehr oft in der Automotive Industrie eingesetzt.

Ralph

Autor: P.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der ARM-Core hat gewisse Designfehler, aber von Bugs ist wenig bekannt.

Hast Du Beispiele dafür?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(a) Interrupts werden am Anfang eines Befehls ausgewertet, aber erst 
danach ausgeführt. War das ein Befehl, der alle Interrupts abschaltet, 
wird die Interrupt-Routine mit abgeschalteten Interrupts ausgeführt und 
die FIQ-Latenzzeit explodiert unerwartet ("surprise interrupt"). 
Möglicherweise abhängig von der Version des Cores, weil kein 
prinzipieller Fehler.

(b) Der PC des unterbrochenen Programms wird im Linkregister des 
Interrupt-Kontext gespeichert. Verschachtelte Interrupts können den 
Interrupt-Kontext folglich nur temporär nutzen und müssen in einen 
anderen Kontext wechseln. Komplexität und Laufzeit von 
Interrupt-Routinen wächst dadurch signifikant an.

(c) Das ist jetzt einen Marotte von mir und wird den meisten wohl am A. 
vorbei gehen: Die dynamischen Shift-Operationen sind saudumm konstruiert 
und führen zu wesentlich komplexerer Registerfile- und Zyklussteuerung 
als nötig gewesen wäre.

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, auf Philips/NXP sind wir mittlerweile auch ziemlich sauer.
Man sehe sich nur den LPC2378 an: EMI funktioniert nicht richtig.
Selbst wenn die nen Studenten für 8Euro die Stunde die Teile hätten 
testen lassen, hätten die das gemerkt.
Aber NXP setzt mittlerweile voll auf die Microsoft-/Bananawarestrategie.
Als Kunde ist man da der Blöde.

Wir schauen uns jedenfalls nach seriöseren Herstellern um.

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich will ja nicht unbedingt NXP in Schutz nehmen (wie käme ich dazu ... 
;-) ), aber schaut euch doch mal die Bug-Listen von anderen Prozessoren 
an, insbesondere von solchen, die erst sein 1 - 3 Jahren auf dem Markt 
und noch heftig in der Entwicklung sind. Ich kann da z.B. TriCore 
empfehlen ... :-) Freescale hat da auch einige nette Bugs im Angebot.

Solche Prozessoren, resp. deren Buglists, mit ausentwickelten, wie z.B. 
AVR zu vergleichen ist schon ein bischen, wie Äpfel und Birnen zu 
vergleichen.

Schönen Tag noch,
Thomas

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man sehe sich nur den LPC2378

Microcontroller muss man reifen lassen, d.h. sich nicht gleich auf die 
neusten Modelle stürzen. Nicht weil die Chips besser werden, sondern 
weil die anfangs eher leeren Buglisten aussagekräftiger werden.

Aber stimmt schon, in die Tricore-Liste hatte ich auch mal reingesehen, 
die ist wirklich imposant.

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber schaut euch doch mal die Bug-Listen von anderen Prozessoren
> an,

Um das Kind beim Namen zu nennen, Atmel und Microchip sind da ganz vorne 
mit dabei. Das heftigste, was ich bisher gesehen habe, waren die Erratas 
zum ENC28J60 von Microchip.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann mich noch gut an die ersten AT90S1200 erinnern, die waren total 
unbrauchbar.
Etwa bei jedem 10. Einschalten standen sie und kein externes Reset half.
Da hatte sich irgendwas intern total verhakt, erst VCC=0V half.

Im Datenblatt stand 20MHz, aufgedruckt waren 16MHz und der Bugbereinigte 
konnte dann aber nur noch 12MHz.

Und daß die EEPROM-Adresse 0 bei allen Klassik-AVRs generell unbrauchbar 
war, weiß inzwischen auch jeder.

Bis dahin war ich von Atmel eigentlich anderes gewöhnt, der AT89C51 von 
1993 war von Anfang an bugfrei.


Aber heutzutage ist es wohl normal, daß neue Chips ernsthafte Bugs 
haben.


Peter

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich kann mich noch gut an die ersten AT90S1200 erinnern, die waren total
>unbrauchbar.

Mein IR-Dekoder mit einem 1200er funktioniert immer noch ganz prächtig.

>der AT89C51 von 1993 war von Anfang an bugfrei.

Wirklich? Oder gab's das Erratasheet nur unter NDA oder evtl. gar nicht?

Die ICs werden immer komplexer, klar das sich da irgendwo immer Fehler
einschleichen.  Ab einem gewissen Komplexitätsgrad sind Fehler einfach
unvermeidlich. Es würde ewig dauern das komplett durchzutesten.
Mich wundert es eher warum das ganze Zeug überhaupt funktioniert...

Autor: OlFi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Software Entwicklung wird gesagt, das man 80% des Projektes in 
10% der vorgesehenen Zeit schafft.
Der Rest der Zeit wird für Änderungen und Fehlersuche gebraucht.

Ich denke das es bei der Hardware Entwicklung sehr ähnlich abläuft. 
Fehlersuche ist dann auch wirklich ein Problem, da es sehr schwer ist 
für solche komplexen Chips Testläufe zu entwickeln die wirklich JEDE 
Funktion abklopfen.

Natürlich ist es in nicht der richtige Weg den Kunden die Fehler für den 
Hersteller finden zu lassen, aber manchmal lässt sich das wohl nicht 
vermeiden.

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sind nicht die Sampel-Phasen dazu da das kunden die letzten bugs finden?

Autor: Rollpeter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter, das könnten Latchups gewesen sein. MAn kann das bremsen, wenn man 
die Spannungsversorgung leicht hochfährt.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rollpeter wrote:
> Peter, das könnten Latchups gewesen sein. MAn kann das bremsen, wenn man
> die Spannungsversorgung leicht hochfährt.


Es ist wesentlich billiger, einen funktionierenden MC zu benutzen, als 
ein Netzteil mit programmierbarer Hochfahrkennlinie zu kaufen.

Normale Netzteile garantieren nur, daß irgendwann die Spannung stabil 
ist, aber keinerlei definierte Zeitrampen beim Einschalten, Abschalten 
oder Spannungseinbrüchen.


Ich hatte auch mal den ACE1202 probiert, der hatte ähnliche 
Einschaltprobleme.

Wenn nicht mal ein externer Reset-IC hilft, kann man solche Chips nur 
noch in die Tonne kloppen.


Peter

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lari Fari
Moechte auf die urspruengliche Frage zurueckkommen. Die Typen, 
LPC2119/29... haben ein umfangreiches Errata Sheet zum Thema CAN aber 
trotzdem koennen viele Kunden damit arbeiten. Die schlimmsten Errata 
sind die nicht veroeffentlichten, bei NXP versuchen wir die Kunden so 
schnell wie moeglich ueber Fehlfunktionen zu unterrichten, dann laesst 
sich meistens was machen. Welche ARM7, von NXP mit ausgereiftem CAN? der 
LPC2290 flashless, 2364/2366/2368, 2378, LPC2468.

All diese Bausteine haben sehr wohl ein Errata Sheet aber der CAN da 
drin ist sehr sauber.

@ Jochen, sich ueber NXP zu beschweren ist OK, den Fehler mit dem 
externen Bus auf dem LPC2378 als besonders denkwuerdiges Beispiel 
herauszustellen ist auch OK.  NXP als unserioes zu bezeichnen ist nicht 
OK.
Der LPC2468 hat bereits die Busprobleme gefixt und das Redesign fuer den 
LPC2378 ist auch in Fertigung. Mich wuerden deine Erfahrungen mit neuen 
Bausteinen der Anbieter interessieren, die du fuer serioes haelst.

Robert

Autor: Setzei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert:

ein bischen mehr Geld in die Entwicklung und weniger in das Marketing 
würde den entstehenden Mikrocontroller besser tun. Ich meine aber alle 
Hersteller und nicht nur NXP. Mit Werbung wird und werden die Probleme 
nicht besser. Als Entwickler will ich nicht zuerst die Erratas lesen 
sonder das Datenblatt und effektiv entwickeln. Alles andere ist friggeln 
und Apathisches stochern.

Autor: OPVler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert

Wir wuerden hier gerne die LPC24xx wegen des LCD Controllers einsetzen.

Durch das Errata Sheet des LPC23xx war ich doch zuerst einmal geschockt. 
"Wenn der externe Bus schon nicht funktioniert und ein "einfacher" 
Pull-UP Schalter fuers USB "hab ich mir gedacht, was ist dann wohl noch 
alles verborgen.

Die LPC Familie find ich vom Grundkonzept am passensten fuer unsere 
Anwendungen, nur ist es schwer sich fuer diese Controller zu Entscheiden 
und die Entscheidung zu verantworten. Ist nicht einfach seinen Kunden zu 
kommunizieren, dass da wohl der Chip Hersteller undokumentierte Bugs hat 
und das deshalb das Projekt in Verzug ist.

Wie sieht es denn generell mit den LPC23xx und LPC24xx aus.

Wann wird der LPC23xx bearbeitet und ne Revision ohne die Major Bugs 
aufgelegt und wann geht der LPC24xx in Sampling/Serie. Wann ist ein 
Errata fuer den LPC24xx erhaeltlich. Ich habe leider nichts auf der 
Phillips Seite gefunden.

Dank schonmal fuer die Antowrt

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@OPVler
LPC23xx wird gerade ueberarbeitet und ca. Mai ist die neue Version am 
Markt. Externer Bus, USB und die nicht so ueblen aber immerhin 
Unschoenheiten die Im Januar bekannt waren sind behoben.
Die 246x ohne LCD gibts ca. Ende April die mit LCD LPC247x ende Mai, 
Anfang Juni.

@Setzei
ich weiss nicht was fuer Programme du schreibst aber stell dir so einen 
Microcontroller wie den LPC23/2400 einfach mal vor wie ein Programm das 
ca. 1GB Source Code hat und an dem 20-30 verschiedene Leute 
mitgeschrieben haben. Hast schon mal ein Program mit 64k auf Anhieb 
fehlerfrei hinbekommen? Falls ja, dann bist du wohl in den obersten 1-2% 
aller Programmierer, herzlichen Glueckwunsch.
Das soll keine Entschuldigung sein, wir sind schwer am kaempfen die 
ersten Chips besser zu machen aber vielleicht hilft es etwas die 
Komplexitaet zu verstehen.

Gruss, Robert

Autor: OPVler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@robert teufel

NXP schreibt auf der Webseite, dass sie in Nuernberg uCLinux auf dem 
LPC24xx haben laufen lassen. Wird der Port veroeffentlicht???

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lari Fari:

Nimm das Teil, wenn es dir gefällt, denn andere µC haben ebenfalls 
ERRATA.

Du befindest dich hier in einem speziellen ARM-Forum. Das ist eine 
großartige Sache! Es ist das beste deutschsprachige, was ich bisher je 
gesehen habe. Also, du bist hier gut aufgehoben. Bisher konnte ich viele 
Probleme mit Hilfe der Forumsmitglieder beseitigen. Nun, es gibt noch 
ein paar internationale Foren, z.B. das von YAHOO (LPC2000-Group) und 
das von Olimex (Bulgarien). Als "not native english speaker" bevorzuge 
ich dieses hier.

Und letztendlich, stehen Forumsmitglieder und ich hier selbst regelmäßig 
mit Rat und Tat zur Seite.

Natürlich ist es aufwändig, am Markt unter den vielen 1000 µC den 
geeigneten zu finden.

Wir entschieden uns unter anderem für ARM, weil der Core sich in sehr 
vielen µC-Familien immer weiter verbreitet, sozusagen zu einer Art 
Standard wird. So, wie z.B. der 8051-Kern seit mittlerweile 27 Jahren 
Standard ist und erfolgreich weiter existiert. Da lohnt es sich, sich 
damit zu beschäftigen. Immer wieder komplett neue Typen zu evaluieren, 
kostet Zeit und Geld.

Trotz aller Anfangsschwierigkeiten, gehe ich mittlerweile locker mit dem 
ARM um, verwende speziell NXP LPC2129 und LPC2138, experimentiere 
gelegentlich mit einem Phytec-Board und LPC2294 (viel externes ROM und 
RAM), das schnelles (teueres) externes SRAM und Flash verwendet.

>habe einige Bugs, vor allem im Umfeld des
>Cancontrollers.

Der CAN-Controller in den LPC2000 sollte eher CANNOT heißen, denn er hat 
auf Grund von ERRATA die meißten Funktionen eingebüßt. Gewisse 
Grundfunktionalität hat er dennoch, sonst könntest du das Ding 
verbrennen: Dank NXP selbst aus Schadensbegrenzung, und KEIL, gibt es 
jedoch brauchbare Lösungen in vollständigem C-Sourcecode (z.B. 
FullCAN-Beispiel, downloadbar von der Keil Homepage). Jedoch bin ich 
noch voller Hoffnung, daß NXP das lösen wird.

Der Sourcecode an sich entschädigt vieles und hat mir den Sprung zur 
Anwendung erst richtig ermöglicht, war ich doch vorher total ahnungslos 
in CAN-Bus.


A.K.:
>Der ARM-Core hat gewisse Designfehler, aber von Bugs ist wenig bekannt.

Der Core ist es weniger, den halte ich für völlig in Ordnung. Die 
Nicht-ARM-Peripherie eines Herstellers von µC hat oft einen Schaden.

>PS: Grad CAN scheint sich eher zum "cannot" zu mausern.

Das ist tatsächlich so, die meisten Funktionalitäten zum CAN-Controller 
schwächeln gewaltig und sind nicht nutzbar. Z.B. die Message Queue und 
Message Speicherung.

Philips/NXP hat jedoch in Zusammenarbeit mit Keil schon vor einiger Zeit 
Beispielsoftware ausgearbeitet, wo auch die ERRATA bedacht sind, 
verfügbar auf der Keil-Homepage (FullCAN- und CANAll- Beispiel). Meine 
Anwendung zum CAN-Bus funktioniert mittlerweile recht gut, habe die 
Demo-Software (FullCAN) als sehr gute Grundlage weit aufgebohrt und auf 
meine Anwendung hingebogen, habe eigene Empfangs- und Sende- FIFOs als 
Schnittstelle zur Anwendung implementiert, das Ding läuft astrein auch 
mit maximaler Bitrate und hohem Traffic.

>"surprise interrupt"

Hatte ein wenig mit eigenem ARM-Assembler geschriebenem Surprise 
Interrupt Handler experimentiert und bin zum Ergebnis gekommen, daß das 
meistens nicht wirklich wichtig ist: Handle ich den Surprise Interrupt, 
so wird zuerst die Anwendung nach der Interruptsperre bearbeitet, z.B. 
eine Watchdog Feed Sequenz. Bleibt er Interrupt durch den Surprise 
Handler unbehandelt, kommt zuerst der Interrupt, und dann die Watchdog 
Feed Sequenz. Das ist in den meisten Anwendungen unbedeutend. Mit einem 
Surprise Interrupt Handler kann man also die Priorität bestimmen, ob 
zuerst der Interrupt oder die Anweisung nach dessen Sperre bearbeitet 
wird, nicht mehr und nicht weniger.

Also: Surprise Interrupt Handler optional. Wenn nicht vorhanden, schadet 
es nicht unbedingt.

Allerdings hat der ARM, im Falle der NXP LPC2000 mitsamt VIC-Controller, 
keine Interruptprioritäten in mehr als den beiden Ebenen IRQ und FIQ, in 
Hardware, die muß man in Software erstellen. Verwendet man dazu die 
Nested Interrupt Technik mit vielen Interruptquellen, so bekommt man 
einen gewaltigen Software-Overhead und immensen Stackbedarf, auch 
Laufzeit.

Bisher kam ich ohne Interruptprioritäten gut aus, FIQ und IRQ, d.h., 2 
Ebenen, genügen, denn eine Priorität, ist sie auch nur sequentiell in 
der Abarbeitungsreihenfolge, bestimmt man mit den IRQ-Slots im 
VIC-Controller eh selbst. Für viele Anwendungen genügt das, und der ARM 
ist ja auch affenartig schnell, wenigstens in den LPC2000.

Jochen:

>Aber NXP setzt mittlerweile voll auf die Microsoft-/Bananawarestrategie.
>Als Kunde ist man da der Blöde.

Alle Bugs der Peripherals, alles was nicht so gut funktionierte, hat 
meinen Chef mittlerweile sicher eine 5-stellige Euro-Summe gekostet, 
alleine für mich. Der weiß es nur konkret nicht.

Steigen jedoch auch andere Teams auf den ARM um, und werden die 
Stückzahlen hoch genug, lohnt es sich wieder, die profitieren dann von 
meiner Evaluierung. Ansonsten ist es Essig.

@tom:
>ich will ja nicht unbedingt NXP in Schutz nehmen (wie käme ich dazu ...
>;-) ), aber schaut euch doch mal die Bug-Listen von anderen Prozessoren
>an, insbesondere von solchen, die erst sein 1 - 3 Jahren auf dem Markt
>und noch heftig in der Entwicklung sind. Ich kann da z.B. TriCore
>empfehlen ... :-) Freescale hat da auch einige nette Bugs im Angebot.

also, da landen wir wieder beim guten alten neuen ARM.


@Robert Teufel:

>trotzdem koennen viele Kunden damit arbeiten. Die schlimmsten Errata
>sind die nicht veroeffentlichten, bei NXP versuchen wir die Kunden so
>schnell wie moeglich ueber Fehlfunktionen zu unterrichten, dann laesst

Welche Kunden sind denn das???

Komme ich im kleinen mittelständischen Unternehmen auch in diesen Genuß?

Mit nicht veröffentlichten Errata beschäftige ich mich zur Zeit auch, 
und zwar mit einen Watchdog Feed Problem: Während Watchdog Feed, darf 
niemals irgendein Interrupt auftreten. Watchdog Feed ist also nicht 
möglich, ohne immer sämtliche Interrupts zu sperren. Das User Manual 
schreibt dazu, daß die Feed Sequenz nicht länger als 2*pclk unterbrochen 
sein soll. Das stimmt mitnichten, habe ich es detailliert getestet. Nur 
ein Interrupt stört.

Da ich keinen Emulator besitze, was die Angelegenheit wieder gigantisch 
verteuern würde, kann ich da nur was vermuten, und die Feed-Sequenz 
stets in einer SWI-Funktion ausführen, um die IRQ auszuschalten, in der 
ich auch den FIQ sperre.

@setzei:

>ein bischen mehr Geld in die Entwicklung und weniger in das Marketing
>würde den entstehenden Mikrocontroller besser tun. Ich meine aber alle
>Hersteller und nicht nur NXP. Mit Werbung wird und werden die Probleme
>nicht besser. Als Entwickler will ich nicht zuerst die Erratas lesen

Es liegt an uns Verbrauchern, Werbung zu filtern oder nicht. Manche 
können es und andere nicht. Natürlich, steckt da Arbeit drin. Wohl dem, 
der über deren Mechanismen im Bilde ist.


Alles in allem: Mittlerweile geht das einigermaßen mit den ARMs. Ist im 
Grunde ein gutes Teil, wenn man mal eingearbeitet ist. Habe z.B. viele 
Errata ausgebügelt, mich für bestimmte Zwecke, z.B. schnelle Interrupt 
Handler, Surprise Interrupt Handler, auch in ARM Assembler und 
Instruction Set eingearbeitet, was bei weitem nicht einfach ist. RISC != 
easy. Demnächst kommt eine Anwendung hinzu, die 2 separate unabhängige 
Programme in einem µC behandeln muß. Da ist schon wieder ein Handler für 
die Exception-Vektoren gefragt, in schnellem ARM-Assembler natürlich.

Das ist eben für NXP ein neueres Konzept, um einen zugekauften Core 
eigene Peripherie drumherum zu implementieren. Es wäre jetzt, nach 
langer Evaluierung, Perlen vor die Säue geworfen, wenn wir da wieder 
Abstand nehmen würden.

Mein Chefingenieur und der Entwicklungsleiter, lassen mir für die 
Spezialitäten ARM und LPC etwas Freiraum, die wissen das. Es ist anders 
geworden nach dem 8051. Aber, wie geht eine Kleinstfirma mit diesen 
Dingen um? Da kann doch alles nur mit heißer Nadel und vielen Bugs 
entstehen.

Wir fingen mit dem ARM ganz neu an.

Time to Market ein paar Wochen oder Monate früher, wäre uns auch besser 
bekommen.


Mann, waren das noch Zeiten, beim 8085 sprach man nicht über Bug-Listen, 
es gab sicher keine, sondern da waren noch heißbegehrte undokumentierte 
Befehle in.

Und auf 8048 und Standard-8051 konnte man getrost vertrauen.


Gruß

Dietmar

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit den Bugs ist ganz einfach, dass die Prozessoren heute 
entwickelt werden wie Software.

Während früher aufwendige Testszenarien entwickelt und durchsimuliert 
wurden wird heute nur noch ansimuliert, das Ganze in ein FPGA gekippt 
und gesehen, ob es klappt. Wenn dann so ein CAN Controller mit einem 
certifizierten  Gegenüber läuft, ist man am Ziel. Da sieht man dann 
natürlich keine Nebeneffekte mehr, weil man nur noch die Signale 
rausführt und ansieht, die man aktuell bearbeitet.

Ist natürlich ein bischen übertrieben dargestellt, aber den Trend 
beschreibt es schon.

Letztlich ist es aber auch gar nicht anders möglich, schliesslich kann 
es sich heute keine Halbleiterfirma mehr leisten, ein Jahr später zu 
kommen, wenn der Markt weitestgehend verteilt ist und man die Kunden nur 
noch über den Preis zum Wechseln kriegt. Letzlich beschweren sich mehr 
Kunden (und vor allem die wichtigeren Leute bei den Kunden) über eine 
verspätete Auslieferung als über Bugs.

Gruss
Axel

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hält die Opensource-Mentalität Einzug: Veröffentliche früh und lass 
den Anwender die Bugs finden. Tausende Anwender bieten das beste 
Testumfeld mit allen erdenklichen Konstellationen.

Dann sollte man allerdings auch dazu stehen und die Teile dann als BETA 
bezeichnen.

Ich warte auch lieber, wenn immer geht, bis 1-2 Jahre vorbei sind und 
das Produkt sich stabilisiert hat. Gilt heutzutage übrigens für fast 
alle Technik, die man kaufen kann. Ein neues Mainboard würde ich auch 
nicht kaufen.

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dietmar,

bitte schreib mir die Details so gut als moeglich (Beispielprogramm!?) 
ueber dein Watchdog Problem.
Wir muessen das dann unetersuchen, ein Work Around finden, hoffentlich 
ohne alle Ints zu sperren und dann die Sache entweder ins Errata Sheet 
aufnehmen oder die Beschreibung im Users Manual aendern.
Die Updates fuer Users Manuals dauern oft laenger als geplant, von daher 
empfiehlt es sich, die Beschreibungen der Peripherals in neueren Manuals 
zu vergeleichen. So sind manche Bloecke im LPC214x Manual besser 
beschrieben als im LPC213x...

Meine e-mail adresse ist vorname punkt nachname at gmail dot com

Robert Teufel

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
leider wurden einige halbleiter-hersteller von den sog. "heuschrecken" 
entdeckt, also investment-fonds die über wenig eignes geld verfügen, 
gute unternehmen aufkaufen und den kaufpreis dem unternehmen als kredit 
"umhängen". so geschehen bei nxp ( ich glaub da ging es um ca. 1 
milliarde $). und bei freescale gibt es eine ähnliche "bedrohung".
und was glaubt ihr was bei einem unternehmen mit solchen einem 
schuldenberg zählt, außer dem schnellen geld (was wiederum die schnelle 
markteinführung von neuen produkten erwzingt)?

gruss
gerhard

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Gerhard,

die "Heuschrecken" moechten bei uns gerne Sponsoren genannt werde ;-) 
Spass beiseite, das war bisher recht gut fuer die Abteilungen bei NXP, 
die keine roten Zahlen schreiben.

Mit den Werten bist du allerdings etwas daneben. NXP, ca 10 Mia $, der 
Freescale Deal ist seit 3 Monaten ebenfalls abgeschlossen und darin geht 
es um 16 Mia$. Kuerzlich gab es auch solche Geruechte um Infineon worauf 
die Aktie sich sehr freundlich entwickelt hat. Auch bei Infineon wuerde 
ich mit 12-13 Mia rechnen. (engl.) So, get used to it!


Die Sache mit dem Schuldenberg ist jedoch SEHR unterschiedlich. Bei NXP 
sind es weniger als die Haelfte der Schulden von Freescale. Das ist sehr 
wichtig fuer die Moeglichkeiten, die sich den Firmen bieten. Der Anteil 
des Eigenkapitals beim Ankauf ist ein wichtiger Faktor und die 
Verschuldung auch. Auf jeden Fall sthet da NXP ziemlich gut da!

Wer da genaueres wissen moechte muss schon Google bemuehen, bei NXP 
einfach nach "Philips Semiconductors" + "KKR" suchen.

Genug Finanzen, schliesslich ist das hier ein Microcontroller Forum

Robert

Autor: Arvid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert

Ab wann und von wem wird es Eval-Boards für den LPC2468 bzw. LPC2478 
geben?
Die Bausteine wären für uns hochinteressant, da sie für unsere geplanten 
Applikationen genau die richtige Peripherie on-chip haben.
Andernfalls sind wir gezwungen, auf ARM9-Typen von Atmel (AT91SAM9) oder 
ST (STR912) auszuweichen.
Mit den LPC23xx haben wir leider schon schlechte Erfahrungen gemacht 
bzgl. Errata (EMI: sehr ärgerlich, Prozessor quasi unbrauchbar) und 
Lieferbarkeit.

Gruss
Arvid

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie von Werner bereits erwaehnt, die Eval Boards gibts bereits von 
Embedded Artists fuer den LPC2468. Verfuegbarkeit der Boards wird erst 
ende April richtig gut werden.  LPC2478 boards voraussichtlich mitte Mai

Robert
p.s. EMI beim LPC2468 tut :-|

Autor: Michael Bruch (mbruch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde hier werden mal wieder Äpfel mit Birnen verglichen!

Der 8051 ist im Vergleich zu einem AT91SAM7 Controller eine kleine 
Subeinheit die bei der Komplexität noch problemlos zu handhaben ist.
Ich habe mit den AT91 Controllern in 2006 begonnen eine Basis Peripherie 
Treiber Struktur zu schaffen was mich viel Geduld und Nerven gekostet 
hat.
Der AIC ist noch etwas komplexer als der VIC. Jetzt 3 Projekte später 
kann ich nur von einem Erfolg sprechen. Die Basis ist super schnell und 
stabil hat zwar einige kleine Probleme bereitet ist jetzt aber 
Narrensicher.
Mein Hauptproblem lag im TWI Controller und das keine geeigneten 
Beispielcodes zu bekommen waren. Ich frage mich wie kann der Prozessor 
ohne Testprogramme getestet werden?

Mir gefallen die SAM7 Controller von Atmel besser weil das FLASH / RAM 
Verhältnis besser ist und die Peripheriemodule besser / schneller sind.

Gruß
Michael

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

haette mir eine Anwort verkniffen wenn Du den letzten Satz weggelassen 
haettest ;-)

Ich kenne keinen SAM7, der irgendein Peripheral hat, das schneller waere 
als z.B. bei einem LPC2148. Kannst mich da mal etwas auf die Spruenge 
bringen?

Welches SRAM / Flash Verhaeltnis besser passt haengt von Deiner 
Anwendung ab und die LPCs haben eben groessere Flash Speicher und sind 
haeufig preisguenstiger.

Gruss, Robert


Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
^ Bei den AT91 muß man immerhin nicht darauf achten ob ein bestimmter
Typ auch fast-GPIOs hat. Beim LPC2134 z.B. habe ich nicht darauf
geachtet das ich einen LPC2134/01 brauche. Super.
Dann sind da bei den Atmels natürlich die DMA Controller für die
Peripherie.

 - Michael

PS: Ich will schaltbare pull-ups !! Elf externe Widerstände mußte
ich in meiner aktuellen Schaltung ins Layout fummeln. Ein interner
Oszillator fehlt auch.
So wird das nichts mit dem Kampf gegen die 8Bitter.

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@let
>PS: Ich will schaltbare pull-ups !! Elf externe Widerstände mußte
>ich in meiner aktuellen Schaltung ins Layout fummeln.
beim at91sam hast du interne, schaltbare pull-ups und du kannst den 
ausgang als open-drain schalten

>Ein interner Oszillator fehlt auch.
leider ist der interne 32khz rc-oszilator im at91sam sehr ungenau.

gruss
gerhard

Autor: Arvid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert:

> LPC2478 boards voraussichtlich mitte Mai
Von welchem Anbieter?
Um was für einen Grafikcontroller handelt es sich bei dem auf dem 
LPC2478 integrierten? Wird es Grafik-Bibliotheken von NXP oder 3rd 
Party-Anbietern zur Ansteuerung für den internen Grafikcontroller des 
LPC2478 geben (oder muss man die komplett selber schreiben)?

Gruss
Arvid

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Robert Teufel, NXP wrote:
> Ich kenne keinen SAM7, der irgendein Peripheral hat, das schneller waere
> als z.B. bei einem LPC2148. Kannst mich da mal etwas auf die Spruenge
> bringen?

Was ich beim LPC2148 vermisse ist der Peripheral DMA Controller des 
SAM7S. Vielleicht kann man sagen dass das die Peripherie indirekt 
"schneller" macht. Bei den neuen Modellen (LPC2478) scheint ja so etwas 
drin zu sein, aber die sind schon eine Stufe größer als SAM7S/LPC2148.

Gruß
Andreas

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich krieg da immer ne Krise, wenn ich das scheiß Webdesign der 
NXP-Seite ansehe, man findet absolut nüscht !!!

Ich suche ja nur ne Selection-Guide, wo alle LPC aufgeführt sind.

Bzw. ganz konkret suche ich nen LPC mit auch 64kB RAM wie der LPC2106, 
aber eben mit den besseren Peripherals und auch mehr Pins.


Peter


P.S.:
Auf diese Seite sollte man sich unbedingt einen Bookmark legen unter dem 
Titel: "Abschreckendes Beispiel, wie eine Webseite nicht aussehen darf".

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

bin ganz neu hier und möchte auch mal meinen Senf dazugeben,
da ich ebenfalls gerade mit ARM bzw. ARM7TDMI entwickle.

Erst mal als Vorwort! Mit dem Hardwaredesign ist es doch ähnlich
wie mit der Software. Die hochgelobte Time to Market Strategie bedeutet
doch nichts anderes als "So schnell wie möglich raus, ohne Rücksicht auf 
Verluste". Beschwert Euch aber nicht nur über die Hardwarebugs. Noch 
schlimmer sieht es bei den Softwareherstellern aus, immer mehr 
HochHochHoch Sprachen. Nehmt es mir nicht übel, aber heute soll wirklich
jeder ohne Erfahrungen einen Baustein HARD und einen SOFT nehmen können,
und schwupp ist die Applikation fertig. Es soll auch Leute geben, die es 
schaffen mit einem Smart 2 Autos zu rammen beim einparken.
Was nützt es, Controller mit 100MIPS einzusetzen und die 
Softwareeffizienz
liegt bei 10% oder drunter. Dann muss man auch nicht wegen steigenden 
Anforderungen ständig den Core wechseln.
Wenn jemand anderer Meinung ist, dann schreibt bitte!

Gruß

Dirk

Autor: Michael Bruch (mbruch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert

Wieviel Taktzyklen braucht das toggeln eines Portpins beim LPC ;-)

AIC Advanced interrupt controller ?

DMA ?

Beim SAM7S256 bekomme ich 256K Flash und 64k RAM ! für 5€ per 1000 
Stück.

Warum ist beim LPC2194 die Taktdistribution so bescheiden das ich noch 
nicht einmal 20Mhz SPI Takt einstellen kann wenn ich meinen JTAG noch 
nutzen möchte?
Wir haben mehrere Devices bereits gelockt!
Die Taktdistribution beim AT91 ist wesentlich variabler einzustellen.
Warum Atmel den RTC als internen RC Oszillator ausgelegt hat bleibt mir 
ein Rätsel.



Gruß
Michael

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peda

Bitte hier starten mit der Suche NXP Microcontrollers
http://www.standardics.nxp.com/microcontrollers/

Das hier waere die Liste aller Produkte:
http://www.standardics.nxp.com/literature/microcon...

Bin leider machtlos ueber den Aufbau der NXP Webseite, deshlab versuche 
ich hier etwas direktere Links vorzustellen :-(

@ Michael
Der LPC214x kann mit bit toggeln 15 MHz erzeugen, das kann kein SAM ;-)
Der LPC2101/2/3 kann sogar 17.5 MHz.

Es ist richtig, dass die frueheren Derivate langsamer waren im Bit 
toggeling als SAM, die jetzigen innerhalb der letzten 2 Jahre sind 
schneller.

AIC versus VIC, der Hauptunterschied ist, dass der AIC Marke Eigenbau 
ist und der VIC eine ARM Primecell ist und damit von viel mehr Tools 
unterstuetzt wird. Geschwindigkeitsunterschiede? Ich wuerde sagen keine 
ausser dass der LPC schneller getaktet ist.

DMA ist bei manchen Anwendungen ein Vorteil, deutlich hoehere Leistung 
vom Flash allerdings noch haeufiger.

Der LPC2194 ist rausgekommen als es noch gar keine SAMs gab und es gibt 
schon ein paar Dinge, die wir inzwischen verbessert haben. SPI 
implementierung auf dem LPC2194 is nicht so prall.

Zum Thema preiswert mal die LPC2300 Typen anschauen. Die gibts bei 1000 
Stueck unter 5 Euro und wenn ich mir so einen LPC2366 mit einem SAM7S256 
vergleiche..  Kannst ja mal machen.
http://www.standardics.nxp.com/products/lpc2000/al...

Vergleich ist unfair aber dann vergleiche mit SAM7X und lass die Preise, 
Peripherals, Anzahl I/O... fuer sich sprechen.
http://catalog.digikey.com/scripts/partsearch.dll?...

@ Arvid,
Anbieter mindestens auch Embedded Artists etwas spaeter dann noch mehr. 
Graphikbibliotheken wirds geben, allerdings nicht sofort verguegbar mit 
dem ersten Board, das dauert etwas. Die werden dann von professionellen 
Anbietern erstellt werden, also so ganz umsonst wirds die nicht geben.

Robert

Autor: kk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum ist der LPC2138 bei Digikey eigentlich teurer als ein LPC2368?

Insbesondere die /01 version - naja der normale kostet sogar fast das 
gleiche.
Verdammt sogar ein LPC2134 kostet mehr!

Find ich irgentvie seltsam...

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk Hofmann (besser arm-dran als arm-ab):

>Nehmt es mir nicht übel, aber heute soll wirklich
>jeder ohne Erfahrungen einen Baustein HARD und einen SOFT nehmen können,
>und schwupp ist die Applikation fertig.

Wie, ist das bei dir auch so???

Gruß

Dietmar

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@ Michael
>Der LPC214x kann mit bit toggeln 15 MHz erzeugen, das kann kein SAM ;-)
>Der LPC2101/2/3 kann sogar 17.5 MHz.

Für welche Anwendungen sind eigentlich diese schnell toggelnden I/O-Pins 
wichtig? Ich bin interessiert.

Und, wie toggelt man mit der Software gezielt die Pins so schnell?

Stehe ich jetzt auf dem Schlauch???

Für uns, ist die hohe Interrupt-Frequenz in der Größenordnung 100 kHz 
interessant, z.B. Capture mit Timer, und die spielt einwandfrei.

Dietmar

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dietmar,

schnelles Bit-toggeln ist z.B. wichtig wenn Du per Software eine 
serielle Schnittstelle emulieren moechtest. In vielen der USB-> JTAG 
emulatoren sind solche micros drin, die mit bit-toggeln den JTAG Teil 
nachbilden.

Ehrlich gesagt waren wir sehr erstaunt, als diese Anforderung hochkam, 
nachdem die ersten LPC2000 auf dem Markt waren. Naja, schliesslich 
wollten wir ja auch die 8-bit Anwendungen adressieren und da werden 
viele Bits manipuliert.

Wir haben draus gelernt und aus dem langsamten "Bit-Toggler" wurde der 
schnellste.

@kk

warum der LPC2300 soguenstig ist??  Ehrlich gesagt ich war auch etwas 
erstaunt als ich von unserem Marketing die Preise gehoert hab aber wir 
verkaufen sie natuerlich auch teurer wenn Du unbedingst mehr bezahlen 
moechtest ;-)

Robert

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dietmar wrote:

> Für welche Anwendungen sind eigentlich diese schnell toggelnden I/O-Pins
> wichtig? Ich bin interessiert.

Ja, die gibt es tonnenweise:

- Ich hab z.B. 4 serielle DACs, die gleichzeitig gestzt werden müssen, 
also 1*SCK und 4*MOSI, geht nicht mit HW-SPI.

- Viele serielle Bausteien haben nen bidirektionalen Datenpin, geht auch 
nicht mit HW-SPI

- Maxim 1-Wire


Auch Single-Master I2C mache ich lieber in SW (weniger Code, einfacher).
HW-I2C kann sich durch Störungen auf dem Bus verschlucken (unerwarteten 
Zustand einnehmen), wenn man da keine Fehlerbehandlungen (Timeout) 
einbaut,  ist das erheblich unzuverlässiger.

Auch ist SW-I2C total MC-unabhängig, ich habs auf 8051 entwickelt und 
unverändert im AVR / ARM laufen.
Man muß nur die Macros fürs Pin setzen, Pin testen und Delay anpassen, 
mehr nicht.


Peter

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Maxim 1-Wire

Gibt's den mittlerweile auch mit Turbo? Mein letzter Stand dazu sind 
~15kbps und das schafft nun wirklich jeder.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, den Turbo gibt es, damit ist die kürzeste notwendige Pulsdauer nun 
0,85µs statt bisher 12µs. Standard-1-Wire hätte auch mein alter AIM65 
noch per Software hinbekommen. Aber auch der Overdrive-Modus dürfte 
keinen Controller der letzten Jahre vor Probleme stellen.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Ja, die gibt es tonnenweise:
>
> - Ich hab z.B. 4 serielle DACs, die gleichzeitig gestzt werden müssen,
> also 1*SCK und 4*MOSI, geht nicht mit HW-SPI.
>
> - Viele serielle Bausteien haben nen bidirektionalen Datenpin, geht auch
> nicht mit HW-SPI
>
> - Maxim 1-Wire
>
>
> Auch Single-Master I2C mache ich lieber in SW (weniger Code, einfacher).
> HW-I2C kann sich durch Störungen auf dem Bus verschlucken (unerwarteten
> Zustand einnehmen), wenn man da keine Fehlerbehandlungen (Timeout)
> einbaut,  ist das erheblich unzuverlässiger.
>
> Auch ist SW-I2C total MC-unabhängig, ich habs auf 8051 entwickelt und
> unverändert im AVR / ARM laufen.
> Man muß nur die Macros fürs Pin setzen, Pin testen und Delay anpassen,
> mehr nicht.

Hallo Peter,

welche Programmiersprache verwendest Du dann für die Softwaretogglerei ?

Gruß

Dirk

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos Bitbanging auf Controllern grösseren Kalibers: Grad wenn's um 
exakte Timings von solchen Portoperationen geht, wird mit bei ARM7/9-ern 
eher mulmig. Pinsteuerungen mit definiertem Zeitverhalten im 
Submikrosekundenbereich sind damit zwar möglich, aber aufgrund des viel 
komplexeren und schwer durchschaubaren Zeitverhaltens von CPU und 
I/O-Bussen auch immer schwieriger realisierbar.

Insofern scheint mir das schnelle Bitbanging ohenhin eher eine Domäne 
der kleineren Controller zu sein, wo es mit dem Abzählen von 
Befehlslaufzeiten getan ist.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Teufel wrote:
> schnelles Bit-toggeln ist z.B. wichtig wenn Du per Software eine
> serielle Schnittstelle emulieren moechtest. In vielen der USB-> JTAG
> emulatoren sind solche micros drin, die mit bit-toggeln den JTAG Teil
> nachbilden.

Gibt es eigentlich irgendwo eine kostenlose Firmware für einen LPC2xxx, 
um so einen USB->JTAG Emulator kostengünstig bauen zu können? Dürfte für 
die Hobbybastler bestimmt interessant sein.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> um so einen USB->JTAG Emulator kostengünstig bauen zu können?

So immens teuer ist der FT2232 nun auch wieder nicht. Wenn du natürlich 
proprietäre JTAGs nachstricken willst...

Autor: kk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert:

> warum der LPC2300 soguenstig ist??  Ehrlich gesagt ich war auch etwas
> erstaunt als ich von unserem Marketing die Preise gehoert hab aber wir
> verkaufen sie natuerlich auch teurer wenn Du unbedingst mehr bezahlen
> moechtest ;-)

hehe - natürlich nicht ;)

Was ich damit eigentlich rausfinden wollte - falls Du das weisst:

Ist das nur ein spezial Einführungspreis oder bleibt
der auf dem Preisniveau?
Wenns so bleibt, dann würde ich mein neues Projekt evtl. mit dem LPC2368 
anfangen... ;)

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich würde mal interessieren, ob eigentlich schon mal irgendjemandem 
aufgefallen ist, dass der LPC2378 einen (u. U.) ziemlich bösen Fast IO 
Bug hat. Steht im Register R0 die Adresse des FIO0DIR-Registers, und 
wird in diesem Zustand im Debugger ein Single-Step durchgeführt (z. B. 
ein NOP), geht die FIO-Konfig. verloren (z. B. wird ein eigentlich als 
Ausgang konfiguriertes Pin floatend). Allerdings lässt sich das nicht 
weiter nachvollziehen aufgrund eines weiteren FastIO-Problems: Die 
Register lassen sich nicht im Debugger anzeigen. Wird ein 
FastIO-Register über JTAG ausgelesen, werden ebenfalls die 
Register-Inhalte zerstört. Ich habe das nachvollziehen können im 
Crossworks Studio von Rowley. Wenn dort die FIO-Registergruppe 
ausgewählt wird, schalten die IOs!

Konsequenz 1: Codeteile, die mit Fast IO arbeiten, können oder sollten 
nicht im Single-Step ausgeführt werden (der Debugger ist für diese 
Codeteile gestorben).

Konsequenz 2: Wenn durch Zufall beim Debuggen mal der Wert 0x3FFFC000 im 
Register R0 landet, braucht man auf den Rest der Debug-Sitzung nichts 
mehr geben. U. U. ist sogar mit Hardwareschäden zu rechnen (weiß ja 
nicht, was genau mit den FIO-Registern geschieht, da ich die ja wie oben 
angemerkt nicht anschauen kann).

Mit GPIO habe ich diese Probleme nicht, aber da ich ein externes 
Speicherinterface betreibe, wäre Fast IO natürlich nicht von Übelkeit. 
Und sog. "legacy" IO gibts nur für die Ports 0 und 1.

Mir ist auch klar, dass derartig komplexe Chips nicht von Anfang an 
fehlerfrei sind. Aber ab einem bestimmten Punkt ist es einfach nur 
abschreckend. Und da nützt es mir auch nichts, dass ich pro Chip 2 Euro 
50 spare, wenn ich dafür mit der Entwicklung nicht fertig werde, weil 
ein IO nicht wackelt oder weil zufällig die FIO-Register versehentlich 
im Debugger angezeigt werden und das Pin gar nicht wackelt, obowohl ich 
das vermute, weil ich das bereits getestet habe...

NXP selbst gibt darauf keine Antwort (Webseite). Vielleicht gibt's von 
Robert ne Aussage zu dem Thema?

PS: Im Übrigen habe ich auch ein mulmiges Gefühl, wenn ich mir den 
PLL-Bug im Errata ansehe. Von dem ursprünglich definierten Bereich von 
275 MHz bis 550 Mhz PLL-Frequenz bleiben gerade mal noch 15 MHz übrig...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> NXP selbst gibt darauf keine Antwort (Webseite). Vielleicht gibt's von
> Robert ne Aussage zu dem Thema?

Vermutlich nicht, nachdem er in den letzten Tagen hier wohl erfolgreich 
rausgeekelt wurde:
Beitrag "Re: Suche LPC SSP  Ext Memory  USB"

Ich finde das gelinde gesagt zum Kotzen.

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade. Vielleicht jemand anderes das gleiche Problem (mit Lösung??)? 
Muss doch noch jemanden geben außer mir, der Fast IOs und gleichzeitig 
nen Debugger benutzt ;-)

Autor: Kurt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

was ist eigentlich mit EMI gemeint?
("LPC2378 an: EMI funktioniert nicht richtig")

habe weder im Datenblatt noch Errata Sheet was dazu gefunden.
Falls damit elektromagnetische Verträglichkeit gemeint ist,
was genau funktioniert dabei nicht?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich mich ans Erratasheet erinnere kann man mit dem real 
existierenden EMI nur lesen, nicht schreiben, weil die Write-Leitung 
nicht funktioniert. Oder sowas in der Art.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja: EMI = External Memory Interface. Anschluss von externem Speicher 
und/oder Peripherie.

Autor: G. Nicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> EMI nur lesen, nicht schreiben, weil die Write-Leitung nicht funktioniert.

Das ist ja oberheftig!

Autor: Roberta (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rufus:
"Vermutlich nicht, nachdem er in den letzten Tagen hier wohl erfolgreich
rausgeekelt wurde:
Beitrag "Re: Suche LPC SSP  Ext Memory  USB"

Ich finde das gelinde gesagt zum Kotzen."


Ich finde die penetrante NXP-Werbung und Konkurrentenschlechtmache durch 
Robert gelinde gesagt zum Kotzen (Und Dein - verzeih die Wortwahl - 
andauerndes Rumgeschleime und Anbiedern an Robert).

NXP hat offensichtlich nicht ein einziges Mal das EMI des LPC2378 vor 
der Produktion getestet und auch noch an Kunden ausgeliefert. Noch 
Fragen?
(Oder haben sie es gar getestet und wollten dann nicht zigtausende von 
Controllern wegschmeißen, weil der Test sich mit der Produktion 
überschnitten hat?)

Kunden kostet sowas ein Schweinegeld. NXP sollte Leute wie Robert lieber 
in die Testabteilung schicken und die lausigen Designs vor Auslieferung 
testen lassen. Da hätten alle Beteiligten mehr von!

Autor: G. Nicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich finde die penetrante NXP-Werbung und Konkurrentenschlechtmache durch
>Robert gelinde gesagt zum Kotzen (Und Dein - verzeih die Wortwahl -
>andauerndes Rumgeschleime und Anbiedern an Robert).

Kann diesem Text nicht zustimmen. Robert könnte sich ja auch unter 
irgendeiner anderen Identität hier zur Wort melden; macht er aber nicht!
Daß Rufus schleimt oder anbiedert, ist an den Haaren herbeigezogen.

Den Ärger über solche Macken finde ich sehr verständlich. Aber sich 
feminin zu geben, ist wohl ein Trick, um nicht verhauen zu werden, 
Roberta.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es auch einen NXP Flash Controller, bei dem das IMI nicht 
funktioniert ?

Gruß

Dirk

Autor: Elektrikser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm, hier kommt mal mein Senf dazu:

Das Robert die Konkurrenz mies gemacht hat, kann ich nicht bestätigen. 
Er hat sogar auf andere Produkte, wie z.B. von Atmel verwiesen. Werbung 
hat er gemacht, aber diese war erkennbar und damit fair. Andere haben 
hier schon schlimmer geworben und das unter falschen Namen! Ich finde es 
schade, dass hier immer wieder herumgenörgelt wird und dazu ein anderer 
Nickname als sonst verwendet wird.
Warum kann es hier nicht ein wenig toleranter sein? Robert hat hier 
nicht nur geworben, sondern auch zu helfen versucht. Aber was soll's? Es 
wird irgendwann so weit sein, dass in diesem Forum nur gemault wird, 
weil es keinen kompetenten gibt, der hier posten will. Schade 
eigentlich...

Gruß Elektrikser

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass Robert hier unter seinem realen Namen und unter Angabe seines 
Brötchengebers auftritt finde ich jetzt nicht gerade bemerkenswert, das 
würde ich eigentlich von jedem in dieser Situation erwarten (die 
"offene" Struktur dieses Forums stört mich hier ein wenig, aber egal, 
darum geht's hier ja nicht). Auf jeden Fall hat er nie einen Hehl daraus 
gemacht, wer er ist.

Wenn ich nun aber weiss, wer Robert ist, und wofür er steht, dann sollte 
doch jeder in der Lage sein, seine Antworten in genau diesem Kontext zu 
bewerten - und dann sind seine Beiträge - verglichen mit üblichem 
Marketing Müll - relativ neutral.

Dazu kommt, dass Robert hier als deutschsprachiger Insider für all die 
User zur Verfügung steht (stand?), die sich im englischen nicht so 
sicher fühlen, und daher in der LPC2000 Yahoogroup eher nicht aktiv 
waren.

Die Sache mit dem LPC23xx würde ich nicht so hochspielen - zum einen 
sind nur die LPC237x betroffen, der LPC236x verfügt garnicht über den 
externen Bus, zum anderen wurde das Errata am 16. November herausgegeben 
- zu dem Zeitpunkt war der Chip noch im Sampling. Klar ist es ein 
haarsträubender Fehler, der nicht durch die Tests hätte fallen dürfen, 
aber Fehler passieren leider, andere Hersteller haben mindestens genau 
so viele Probleme, und Robert kann wohl kaum etwas dafür - ihn 
persönlich angreifen ist dann allerdings unterste Schublade...

Gruss,

Dominic

Autor: ARM-Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dominic: Full Ack!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manoman,

anstatt froh zu sein, endlich mal nen kompetenten Gesprächspartner zu 
haben, wird hier nur rumgemotzt.


Werbung ist ja nun was völlig anderes (Null Information !) und da sollte 
ja schon jeder resistent sein, der einen Fernseher zu Hause hat.


Peter

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominic R. wrote:
> Dazu kommt, dass Robert hier als deutschsprachiger Insider für all die
> User zur Verfügung steht (stand?), die sich im englischen nicht so
> sicher fühlen, und daher in der LPC2000 Yahoogroup eher nicht aktiv
> waren.

Hallo Dominic,

hab nur eine Frage zu dem was Du geschrieben hast, wo mir etwas 
aufstösst.
Wie ist es heutzutage möglich in der Elektronik und Programmierung ohne 
ein schon gewisses Mindestmaß an Englisch auszukommen. Finde, wann man 
das nicht beherrscht, kann man es auch sein lassen.

Sogar deutsche Hersteller (soweit es noch welche gibt) schreiben ihre 
Specs in englisch.
Das ist für mich jetzt kein Grund.

Gruß
Dirk

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dirk,

das ist einfach mein Eindruck aufgrund von einigen Beiträgen hier im 
Forum. In der Suche einfach mal "uC & Elektronik" anwählen und 
"englisch" als Suchbegriff eingeben - ein kurzes Überfliegen der 
Ergebnisse hat diesen Eindruck bestätigt.

Klar bin ich der Meinung, dass jemand ohne ausreichende 
Englischkenntnisse seinen PC bestenfalls als Schreibmaschine benutzen 
sollte - es gibt aber wohl Leute, die trotzdem mit uCs arbeiten wollen.

Gruss,

Dominic

Autor: wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

Hört doch jetzt mal auf mit Grundsatz-Reden und kommt auf das Sachthema 
zurück. Naja, ein bissel Gemecker und Frust ablassen gehört dazu, soweit 
ist das klar. Denn: wenn alles glatt läuft, dann fühlt man sich wohl 
nicht bemüßigt, ein Diskussionsforum aufzusuchen. Das macht man nur, 
wenn einem der Kittel brennt.

Also: Der ARM als solcher hat definitiv seine ekligen Seiten, als da 
wären der verschwenderische und nicht hübsche 32 Bit Code, solche Dinge 
wie das Linkregister anstelle einer Stackoperation, das "zu Fuß" 
auseinanderfuddeln von Interrupts (der gute alte Z80 hatte ja 
vorgemacht, wie man Dutzende von Interruptvektoren besser verwaltet...) 
und so weiter. Aber andere Softcore-Anbieter wie MIPS können es auch 
nicht besser.

Was mich interessiert, ist die neue Linie bei Arm namens Cortex. Ich 
schätze, das wird sich in den nächsten Jahren als echter Durchbruch zu 
neuen Ufern erweisen, denn da sind einige der ollen Hakeligkeiten 
endlich beseitigt.

Gruß
Wolfgang

Autor: Juergen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wolfgang,

bin auch an dem neuen Cortex sehr interessiert. Ich sehe aber noch 
wenige Produkte am Markt (Stellaris von Luminary, andere?).

Vielleicht plan auch NXP ein LPCxxxx in der Richtung?

Gruss,

Thomas

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

kann mir jemand sagen, warum es mir nicht gelingt das I2S-Peripheral des 
LPC2378 zu programmieren?
Genauer: Ich will in das I2S_DAI-Register schreiben, aber wenn ich 
danach den  Wert auslese in eine Variable, steht da nur der Default-Wert 
drin, der schon nach dem Reset drin stand (0x7e1).
In den Errata steht nur, daß I2S nicht mit DMA funktioniert. (Im User- 
Manual-Update vom 5.10.07 ist das allerdings noch nicht angekommen.)

Ich stelle hier mal den (sehr kurzen) Sourcecode rein. Die letzen beiden 
Befehle sind von Interesse.
//..
 unsigned t;
 PINSEL0 &= ~(3<<14);  /* clear Bits 15,14--> P0[7] as GPIO */
 PINMODE0 &= ~(3<<14);  /* enable pull-up resistor for P0[7] */
      /* 00 - pull-up resistor enabled
         10 - weder pull-down noch pull-up 
           11 - pull-down resistor enabled */


// activate port pins
 PINSEL1  &= ~(0x3f<<14);  /* Bits 19..14 clear  */
 PINSEL1  |= (0x2a<<14);  /* P0.23   I2SRX_CLK pin 13
           P0.24  I2SRX_WS  pin 11
           P0.25  I2SRX_SDA pin 10
*/
// Input register
 I2S_DAI = 0x7eb;    /* Input register
             1:0 - 11 32 bit
            2   -  0 Stereo
            3   -  1 Stop 
                                   4   -  0 no reset
                                   5   -  1 ws_sel, Slave Mode
                                14:6  1fh = 31  ws_halfperiod (64/2-1)
                                  15  -  0  unused
                               */   

 t=I2S_DAI;      /*  --> t= 0x7e1
                       1:0 - 01  16 bit data  !!!!!!!!!!!!!!!
                       2 -  0 Stereo
                       3 -  0 no Stop 
                       4 -  0 no reset
                       5 -  1 ws_sel, Slave Mode !!!!!!!!!!!!!
                     14:6  1fh = 31  ws_halfperiod (64/2-1)
                      15  -  0 unused
                    */
//...


Eigenlich wollte ich (bei vorherigen Versuchen) den Master-Mode 
aktivieren (mit 0x7cb), aber letztendlich stand immer 0x7e1 drin, also 
Slave-Mode mit 16 Bit Daten.
Hat jemand eine Idee?

Henry

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>kann mir jemand sagen, warum es mir nicht gelingt das I2S-Peripheral des
>LPC2378 zu programmieren?

Kannst Du mir sagen, wieso Du dafür einen sechs Monate alten Thread 
hijacken musst?

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Habe den Fehler inzwischen gefunden:
I2S ist nach dem Reset im Gegensatz zu einigen anderen Peripherals nicht 
automatisch enabled.
Mit
 PCONP |= (1<<27);
funktioniert es jetzt.

Henry

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.