Hallo, bisher habe ich immer mit den NXP LPC2000 gearbeitet (vor allem der 2468er ist mein Lieblingsprozessor). Ich will mal was neues ausprobieren, und da Cortex-M3 nun ja in aller Munde ist wären die LPC1700-Teile ganz interessant. Daher habe ich mich schon mal mit der Application Note von NXP befasst, "Migrating to the LPC1700 series" und auch den "Insider's Guide to Cortex-M3" gelesen. Ein paar Sachen sind mir aber noch nicht ganz klar. - Es ist eine Harvard-Architektur. Kann ich trotzdem z.B. Programme von einer SD-Karte ins externe Memory laden und dort ausführen, oder während des Debuggens einer Software dies im externe Memory tun, um das Flash zu schonen und das Laden zu beschleunigen? - Im NXP-Manual heisst es, "the Systick timer is intended to generate a Systick Exception every 10 ms". Wieso 10 ms? Da kann ich wohl schon selber wählen, wie viele ms ich haben will, oder? Eine etwas verwirrende Aussage. - Im Insider's Guide heisst es, Cortex M3 unterstütze nur Thumb-2, was in der Performance gleich komme mit dem ARM-Befehlssatz, aber die Codedichte des Thumb-Befehlssatzes erlaube. Nun - ARM sind 32 Bits/Instruktion, bei Thumb sinds 16. Was hat denn der Cortex?
Tobias Plüss schrieb: > - Es ist eine Harvard-Architektur. Kann ich trotzdem z.B. Programme von > einer SD-Karte ins externe Memory laden und dort ausführen, oder während > des Debuggens einer Software dies im externe Memory tun, um das Flash zu > schonen und das Laden zu beschleunigen? Wenn man die Harvard-Architektur an den Busanschlüssen vom Core festmacht, dann landet man bei dieser Frage. Macht man sie an den Adressräumen fest, dann löst sich die Frage in Luft auf. Aber: Das wirst du vermutlich nicht wollen, denn der Zugriff auf externen Speicher ist ohne Cache schnarchlangsam. Auch als primärer Datenspeicher ist externer Speicher deshalb ungeeignet. War bei den LPC2000 mit externem Speicherbus auch nicht anders. > - Im NXP-Manual heisst es, "the Systick timer is intended to generate a > Systick Exception every 10 ms". Wieso 10 ms? Es gibt in der Systick-Definition von ARM eine optionale herstellerspezifische Vorgabe. Die kann man nutzen, soweit überhaupt implementiert, oder völlig eigene Werte verwenden. > - Im Insider's Guide heisst es, Cortex M3 unterstütze nur Thumb-2, was > in der Performance gleich komme mit dem ARM-Befehlssatz, aber die > Codedichte des Thumb-Befehlssatzes erlaube. Nun - ARM sind 32 > Bits/Instruktion, bei Thumb sinds 16. Was hat denn der Cortex? Sowohl als auch. Thumb-2 Befehle sind teils 16 teils 32 Bits breit.
Naja, laut dem Insider's Guide soll das Ding ja angeblich einen Cache haben, oder nicht? Ausserdem ist die Performance zumindest bei den LPC2000ern gar nicht so übel. Damit lässt sich durchaus was anfangen.
Tobias Plüss schrieb: > Naja, laut dem Insider's Guide soll das Ding ja angeblich einen Cache > haben, oder nicht? Schon. Aber wenn das Businterface keinen eigenen Cache mitbringt, dann ist das der sogenannte "Flash Accelerator" und der sitzt zwischen dem internen Flash und dem Bus, ist also nur bei Zugriffen auf das interne Flash wirksam. Bei den (meisten) ARM9/11 und Cortex-A Prozessoren sitzt der dann auch so genannte Cache zwischen dem Core und den Bussen und ist für alle Adressbereiche wirksam, bei denen Caching nicht ausgeschlossen wurde.
[...] > wären die > LPC1700-Teile ganz interessant. [...] > z.B. Programme von > einer SD-Karte ins externe Memory laden und dort ausführen, Pass auf: die LPC175x und LPC176x haben keinen Anschluss für externes RAM. Nur die LPC177x und LPC178x haben das, die sind aber noch ganz neu und nicht in Mengen verfügbar. Außerdem würde ich bei denen noch nen halbes Jahr/Jahr warten bis andere die Bugs gefunden haben und es Errata Sheets gibt... Gruß, Gerd
wenn ich mich hier auch mal einklinken darf. Die LPC17xx sind bei Digikey verfügbar, zwar wohl nicht in rauhen Mengen. Aber ich werde mir demnächst wohl mal ein Testboard mit so einem Teil drauf bauen. Das Erratasheet von NXP hält sich bisher ja noch einigermassen in Grenzen, ausserdem bis ich das Layout fertig habe ist eh schon Rev A draussen ;-) Andere Frage. Ich möchte ein externes SDRAM an den LPC17xx anschliessen und dann aus diesem SDRAM ein Programm ausführen. Bei NXP ist das SDRAM ja ab Adresse 0xA0000000 verfügbar. Der von mir vorgesehene Speicherbereich wird daher 0xA0000000 - 0xA3FFFFFF sein (64 MB). Jetzt habe ich aber eingehend das ARMv7M Architecture Reference Manual gelesen (hab mich extra bei ARM registrieren lassen, um das Dokument beziehen zu können). Und dort habe ich gelesen (und hoffentlich richtig verstanden), dass der Adressbereich 0xA0000000 und höher als "NX", also "no execute", eingestuft wird. Weiter heisst es in dem genannten Architecture Reference Manual: "an instruction fetch from an NX memory region causes an MemManage fault", oder so ähnlich - demnach werde ich also keinen code aus externem Memory ausführen können, oder? Dann muss ich mich doch schon sehr fragen, was denn ein solches externes memory bringen soll. z.B. uClinux funktioniert ja gerade mit einem solchen externen memory. und die Software, die ich hier habe, ist leider zu gross, als dass sie im internen RAM platz fände - aber im externen kann ich sie nicht ausführen. Dann bleibt wohl nur, die Applikation vor jedem Debuggen ins interne Flash runterzuladen, oder? Das ist aber meines erachtens ein Rückschritt. Beim ARM7 (ARMv4) konnte ich direkt ins externe SDRAM die applikation laden und dort dann auch debuggen. So ist der Download einerseits sehr schnell, und andererseits kann ich das Flash schonen. Was sagt ihr dazu?
Ich habe schon ein fertiges selbstgebautes Board mit dem LPC1788 und externem SDRAM hier laufen (2M x32 Bit). Zugriffe auf das RAM funktionieren tadellos. Programmcode daraus auszuführen habe ich jedoch noch nicht getestet, werde ich mal in den nächsten Tagen machen. Erwin
Hi Erwin, das wäre toll, wenn du es testen könntest! was setzt du für ein RAM ein? läuft bei dir die ganze Geschichte auch mit den von NXP versprochenen 120MHz noch gut? wäre es evtl. möglich, dein Board mal zu begutachten? das interessiert mich jetzt wirklich.
NXP gibt für das ext. SDRAM 80MHz als max. Takt an.
Hallo, > ext. SDRAM 80MHz als max. Takt was haben sich die dabei wohl gedacht? Was soll das bringen, wenn die CPU 120 MHz kann, und das externe Memory gerade mal 80? Dann ist so ein externes Memory ja gänzlich sinnlos. Codeausführung geht wohl auch nicht, habe ich auch gerade im ARM Handbuch nachgeschaut. Schade, dann werde ich vorerst wohl beim ARM7 bleiben, der kann das alles.... :(
Tobias Plüss schrieb: > Was soll das bringen, wenn die > CPU 120 MHz kann, und das externe Memory gerade mal 80? Dann ist so ein > externes Memory ja gänzlich sinnlos. Naja. Es gibt ja noch Wait-States und Caches. > Codeausführung geht wohl auch > nicht, habe ich auch gerade im ARM Handbuch nachgeschaut. Eventuell läßt sich der Speicher auch in einem anderen Bereich einblenden? Sonst wäre er wirklich nur als Datenpuffer geeignet. Ich kann mir nicht vorstellen, daß NXP das vertrieft haben sollte. Ansonsten kannst Du ja auch mal den FAE/Support von NXP kontaktieren. Grüße Sven
Hi Sven, > Eventuell läßt sich der Speicher auch in einem anderen Bereich > einblenden? Nein. Der External Memory Controller von NXP blendet dynamische RAMs fest in den Adressbereich 0xA0000000 - 0xDFFFFFF ein. Da gibts nichts zu rütteln, es existiert kein Register, um die Adresse umzumappen. Statische Memories liegen ab 0x80000000, auch dies eine von ARM als "Never Execute" eingestufte Memory-Region, Codeausführung aus SRAM geht also auch nicht. Auch hier keine Möglichkeit, die Adresse zu ändern. > Ansonsten kannst Du ja auch mal den FAE/Support von NXP kontaktieren. Das habe ich mir auch schon überlegt. Aber als Privatmann ist das wohl vergebene Liebesmüh; ich habe die Erfahrung gemacht: je grösser der Konzern, umso unfreundlicher der Support, da wird in der Regel nicht einmal auf Mails geantwortet. Schade eigentlich... > Sonst wäre er wirklich nur als Datenpuffer geeignet Jau. Aber ich kann mir nicht vorstellen, dass jemand so viele MBytes Daten mit einem ARM Cortex M3 verarbeiten will - das ausführen von grossen Programmen erscheint mir da schon realistischer. Da reicht das interne RAM dann nämlich oft nicht. Ich habe hier ein Projekt, wo ich den lwIP im Vollausbau laufen lasse sowie ein kleines RTOS. Das passt jedenfalls beim LPC2468 nicht in das interne RAM, deshalb lasse ich das aus dem externen SDRAM laufen. Download geht natürlich sehr viel schneller als ins Flash, und auch die Performance der Software ist recht gut, der Memory Controller hat irgend eine Art von Puffer oder Cache.
Tobias Plüss schrieb: > Nein. Der External Memory Controller von NXP blendet dynamische RAMs > fest in den Adressbereich 0xA0000000 - 0xDFFFFFF ein. Da gibts nichts zu > rütteln, es existiert kein Register, um die Adresse umzumappen. > Statische Memories liegen ab 0x80000000, auch dies eine von ARM als > "Never Execute" eingestufte Memory-Region, Codeausführung aus SRAM geht > also auch nicht. Auch hier keine Möglichkeit, die Adresse zu ändern. Sieh dir mal die MPU an ( Memora Protection Unit). Eventuell gibt es dort die Möglichkeit die Einstellung "Never Execute" für bestimmte Bereiche umzustellen. Falls das geht wäre die Einstellung von NXP für diesen Bereich nur die Grundeinstellung bei Systemstart. Das heißt dann aber auch das du einen Bootloader im Flash brauchst der die MPU umstellt bevor du den Code im Ram startest.
Zitat user.manual.lpc17xx.pdf, Seite 739: "The Code, SRAM, and external RAM regions can hold programs. However, the most efficient access to programs is from the Code region. This is because the processor has separate buses that enable instruction fetches and data accesses to occur simultaneously." XN ist nur in Device-Adressbereichen aktiv. Ciao, Yagan
Hatte schon jemand Erfolg mit der Codeausführung aus dem externen RAM und kann über seine Erfahrungen berichten? Ich habe einen LPC1788 und schaffe es nicht. Als LCD-Buffer funktioniert das externe RAM wunderbar...
>> Ansonsten kannst Du ja auch mal den FAE/Support von NXP kontaktieren. > >Das habe ich mir auch schon überlegt. Aber als Privatmann ist das wohl >vergebene Liebesmüh; ich habe die Erfahrung gemacht: je grösser der >Konzern, umso unfreundlicher der Support, da wird in der Regel nicht >einmal auf Mails geantwortet. Schade eigentlich... Das stimmt so nicht! Ich habe die Software EleLa geschrieben und da mal angefragt ob ich deren Gehäuse-Zeichnungen in eine Datenbank kopiert veröffentlichen darf. (Beitrag "EleLa - Elektronik Lagerverwaltung") Innerhalb von 5 Minuten hat mit der Support geantwortet und dem zugestimmt!! Und ich bin nur eine Privatperson! Die von NXP sind wirklich unkompliziert.
Hallo, wollte mal nachfragen, ob es zu dem Thema in der Zwischenzeit was neues gibt. Hat das vielleicht jemand mal ausprobiert? Ich hab leider noch immer keine Hardware hier, um es testen zu können. NXP hat bis jetzt geschwiegen... :-/ Ich werde es mit meiner Studi-Emailadresse nochmal versuchen, vielleicht wird man da ernst genommen. Gruss
Hallo Leuts, so, falls es jemanden interessieren sollte, der (wie ich) plant, mal was mit diesem Chip zu machen: Codeausführung aus dem externen Memory geht, trotz dieses sonderbaren "Execute Never", das ARM im "Architecture v7M reference manual" propagiert. Was auch immer dieses sonderbare Flag soll: NXP erklärt, dass die Codeausführung aus externem Memory funktioniert. Habe soeben vom NXP-Support eine Antwort erhalten. "Dear Tobias, Your inquiry is resolved for your case 00004417: Code execution from external SDRAM Solution answer: Of course it's possible to execute code from external SDRAM. "
Wer lesen kann, ist klar im Vorteil.... Die Eigenschaften eines Speicherbereichs lassen sich durch die MPU programmieren. Das kann man auch fuer das SDRAM machen. Und dann laeuft auch Code aus dem SDRAM. Geht natuerlich langsamer als aus dem internen Speicher, aber durch die Buffer in der SDRAM-Schnittstelle immer noch ganz schön flott. Ich bin jedenfalls zufrieden! Allerdings ist MPU programmieren nichts für Weicheier, weil das so fürchterlich schlecht dokumentiert ist. Immerhin stehen ein paar magere, aber absolut notwendige Sätze hinten im User Manual. Wenn man übrigens Code mit dem Emulator ins Zielsystem ins SDRAM laden und ausführen will, muss man die SDRAM-Initialisierung UND die MPU-Initialisierung im Debugger-Script machen. Das kostet dann schnell ein paar Tage... Ich habe jetzt die meisten Schnittstellen vom 1788 durch, und bin echt begeistert - geht eigentlich alles ohne Probleme. Schöner Chip! So sieht der MPU-Code fuer OpenOCD aus:
1 | # Setup the MPU
|
2 | # MPU disablen
|
3 | mww 0xE000ED94 0x00 |
4 | # Flush
|
5 | sleep 1 |
6 | |
7 | # Die Regionen sind mit unterschiedlicher Prioritaet versehen. Region 0 ist
|
8 | # die unterste, d.h. man kann sie gut als Default verwenden. Und wenn man sie so
|
9 | # programmiert, dass alle Zugriffe verboten sind, so kann man damit ungueltige
|
10 | # Speicherzugriffe abfangen und die Software neu starten.
|
11 | |
12 | # Region 0: Default ohne Zugriffsrechte, gesamter Adressbereich
|
13 | mww 0xE000ED9C 0x00000010 |
14 | mww 0xE000EDA0 0x1004003f |
15 | |
16 | # Region 1: internes Flash, internes SRAM, Boot ROM,
|
17 | # Peripheral SRAM, AHB Peripherals
|
18 | # 0x00000000 - 0x3FFFFFFF
|
19 | # Subregions: 0 = Flash, 2 = SRAM, 3 = Boot ROM,
|
20 | # 4 = Peripheral SRAM + AHB Peripherals
|
21 | mww 0xE000ED9C 0x00000011 |
22 | mww 0xE000EDA0 0x0306E23b |
23 | |
24 | # Region 2: Peripheral Devices
|
25 | # 0x40000000 - 0x400FFFFF
|
26 | # 0x42000000 - 0x43FFFFFF Bitband-Alias
|
27 | mww 0xE000ED9C 0x40000012 |
28 | mww 0xE000EDA0 0x13050033 |
29 | |
30 | # Region 3: ext. Chip Selects/Devices
|
31 | # 0x80000000 - 0x9000FFFF
|
32 | mww 0xE000ED9C 0x80000013 |
33 | mww 0xE000EDA0 0x1305001f |
34 | |
35 | # Region 4: SDRAM
|
36 | # 0xA0000000 - 0xA0FFFFFF
|
37 | mww 0xE000ED9C 0xa0000014 |
38 | mww 0xE000EDA0 0x0307002f |
39 | |
40 | # Region 5: Cortex-M3 Private Peripheral Bus
|
41 | # 0xE0000000 - 0xE00FFFFF
|
42 | mww 0xE000ED9C 0xe0000015 |
43 | mww 0xE000EDA0 0x13040027 |
44 | |
45 | # Region 6: not used (immer gut, eine frei zu haben)
|
46 | mww 0xE000ED9C 0xe0000016 |
47 | mww 0xE000EDA0 0x00000000 |
48 | |
49 | # Region 7: Stack check
|
50 | mww 0xE000ED9C 0x1000E017 |
51 | mww 0xE000EDA0 0x10060009 |
52 | |
53 | # MPU (wieder) einschalten
|
54 | mww 0xE000ED94 0x01 |
55 | # Flush
|
56 | sleep 1 |
Super Sache. Besten Dank. Wo hast du den Chip her? ist der mittlerweile brauchbar? ich hab das Erratasheet grade nicht zur Hand, aber als ich es das letzte mal anschaute, hatte es noch ein paar ordentliche Bugs drin. Hast du selber ein Board gebaut, oder ein fertiges gekauft?
Der Chip (LPC1788 im QFP-208) ist mittlerweise ganz normal kaufbar. Ich habe ihn direkt vom Distributor (macht bei uns der Einkauf). Das Errata ist eigentlich unspektakulär. Ich habe eine eigene Schaltung entwickelt. Kernkomponenten sind CPU, 16 MByte SDRAM(16bit), 16 MByte serial Flash, USB Device Port, SD-Port und ein 16bit LCD (480x272).
Hallo Wolfgang, ich hab da mal eine Frage. Du hast ja ganz offensichtlich den Memory Controller erfolgreich in Betrieb gesetzt... Deshalb möchte ich dich hier was fragen, vielleicht kennst du dich damit ja aus? Ich möchte gern ein 32 Bit breites SDRAM an den EMC anschliessen. Dazu habe ich den Chip http://www.issi.com/pdf/42-45S32800D.pdf ausgesucht. Gemäss diesem Datenblatt hat der Chip 4096 Rows und 512 Columns. Gemäss meinem Verständnis müsste man dann im EMCDynamicConfig0-Register beim Address Mapping einstellen: 4 Banks, Row Length = 12, Column Length = 9 sowie 8M x 32. Es gibt aber keinen passenden Eintrag in der Tabelle im User Manual auf S. 179f. Heisst das, ich kann dieses SDRAM nicht nutzen, oder kann ich da einfach eine andere Einstellung wählen, ohne Probleme mit dem Refresh zu kriegen?
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.