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 ?
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.
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.
hallo Nimm den TMS 470 von TI; Dieser wird sehr oft in der Automotive Industrie eingesetzt. Ralph
(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.
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.
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
> 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.
> 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.
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
>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...
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.
Peter, das könnten Latchups gewesen sein. MAn kann das bremsen, wenn man die Spannungsversorgung leicht hochfährt.
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
@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
@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.
@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
@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
@robert teufel NXP schreibt auf der Webseite, dass sie in Nuernberg uCLinux auf dem LPC24xx haben laufen lassen. Wird der Port veroeffentlicht???
@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
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
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.
@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
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
@ 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
@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
LPC2468 -> http://www.embeddedartists.com/products/uclinux/oem_lpc2468.php?PHPSESSID=4dcfacad604fd5a32de80154a16a238f
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 :-|
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
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
^ 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.
@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
@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
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
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".
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
@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
@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/microcontrollers/?search=selection 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/all/~LPC2366/#LPC2366 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?Detail?name=568-3996-ND @ 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
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...
@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
>@ 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
@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
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
> Maxim 1-Wire
Gibt's den mittlerweile auch mit Turbo? Mein letzter Stand dazu sind
~15kbps und das schafft nun wirklich jeder.
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.
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
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.
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.
> 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...
@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... ;)
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...
> 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.
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 ;-)
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?
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.
Ach ja: EMI = External Memory Interface. Anschluss von externem Speicher und/oder Peripherie.
> EMI nur lesen, nicht schreiben, weil die Write-Leitung nicht funktioniert.
Das ist ja oberheftig!
@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!
>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.
Gibt es auch einen NXP Flash Controller, bei dem das IMI nicht funktioniert ? Gruß Dirk
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
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
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
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
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
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
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
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.
1 | //..
|
2 | unsigned t; |
3 | PINSEL0 &= ~(3<<14); /* clear Bits 15,14--> P0[7] as GPIO */ |
4 | PINMODE0 &= ~(3<<14); /* enable pull-up resistor for P0[7] */ |
5 | /* 00 - pull-up resistor enabled
|
6 | 10 - weder pull-down noch pull-up
|
7 | 11 - pull-down resistor enabled */
|
8 | |
9 | |
10 | // activate port pins
|
11 | PINSEL1 &= ~(0x3f<<14); /* Bits 19..14 clear */ |
12 | PINSEL1 |= (0x2a<<14); /* P0.23 I2SRX_CLK pin 13 |
13 | P0.24 I2SRX_WS pin 11
|
14 | P0.25 I2SRX_SDA pin 10
|
15 | */
|
16 | // Input register
|
17 | I2S_DAI = 0x7eb; /* Input register |
18 | 1:0 - 11 32 bit
|
19 | 2 - 0 Stereo
|
20 | 3 - 1 Stop
|
21 | 4 - 0 no reset
|
22 | 5 - 1 ws_sel, Slave Mode
|
23 | 14:6 1fh = 31 ws_halfperiod (64/2-1)
|
24 | 15 - 0 unused
|
25 | */
|
26 | |
27 | t=I2S_DAI; /* --> t= 0x7e1 |
28 | 1:0 - 01 16 bit data !!!!!!!!!!!!!!!
|
29 | 2 - 0 Stereo
|
30 | 3 - 0 no Stop
|
31 | 4 - 0 no reset
|
32 | 5 - 1 ws_sel, Slave Mode !!!!!!!!!!!!!
|
33 | 14:6 1fh = 31 ws_halfperiod (64/2-1)
|
34 | 15 - 0 unused
|
35 | */
|
36 | //...
|
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
>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?
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.