Hallo, ich sitze gerade vor einer Leiterplatte mit einem LPC2468 drauf. Ich will die beiden SDRAM ansteuern, welche auf dem Board verbaut sind: IS42S16160B (http://www.issi.com/pdf/42S83200B-16160B.pdf). Ich habe nun gemäss LPC2468-Handbuch alle Register des EMC initialisiert; doch ich stelle 2 Probleme fest: 1. Es funktioniert nicht; 2. Manche Pins werden nicht richtig auf Masse gezogen. Namentlich DQM0..DQM3. Diese haben zwar einen ordentlichen High-Pegel von +3.3V, aber sie kommen nie auf Masse runter (Oszi-Bild folgt noch). Im PINMODE habe ich die Pullups aber ausgeschaltet (weder Pullup noch Pulldown sind aktiv). Hier noch mein Code: #include "targets/LPC2468.h" int main(void) { int i; int j; int* x = 0xA0000000; /* base addr of the sdram */ /* setup pll */ MAMCR = 2; MAMTIM = 7; IRCTRIM = 0xe0; PLLCON &= 0xFFFFFFFD; PLLFEED = 0xAA; PLLFEED = 0x55; PLLCON &= 0xFFFFFFFE; PLLFEED = 0xAA; PLLFEED = 0x55; CCLKCFG = 0; PLLCFG = 0x000700FC; PLLFEED = 0xAA; PLLFEED = 0x55; PLLCON |= 0x00000001; PLLFEED = 0xAA; PLLFEED = 0x55; CCLKCFG = 3; while(!(PLLSTAT & (1 << 26))); PLLCON |= 0x00000002; PLLFEED = 0xAA; PLLFEED = 0x55; // 40 MHz /* for test only */ PINSEL1 = 0; PINSEL1 |= (1 << 21); PCLKSEL1 |= 4; PINSEL2 = 0; PINMODE2 = 0; FIO1DIR = 0x10; FIO1MASK = 0; PCLKSEL0 = 4; /* setup emc */ PCONP |= (1 << 11); PINSEL5 = 0x55010115; PINMODE5 = 0xAA02022A; PINSEL6 = 0x55555555; PINMODE6 = 0xAAAAAAAA; PINSEL7 = 0x55555555; PINMODE7 = 0xAAAAAAAA; PINSEL8 = 0x15555555; PINMODE8 = 0x2AAAAAAA; PINSEL9 = (1 << 18); PINMODE9 = 0x80000; EMCControl = 1; EMCDynamicReadConfig = 1; EMCDynamicRasCas0 = 0x203; EMCDynamictRP = 0; EMCDynamictRAS = 1; EMCDynamictSREX = 2; EMCDynamictAPR = 1; // ?? EMCDynamictDAL = 2; EMCDynamictWR = 1; // ?? EMCDynamictRC = 2; EMCDynamictRFC = 2; EMCDynamictXSR = 2; EMCDynamictRRD = 0; EMCDynamictMRD = 0; EMCDynamicConfig0 = ((1 << 14) | (1 << 12) | (1 << 10) | (1 << 9) | (1 << 7)); for(i = 0; i < 100; i++); EMCDynamicControl = 0x181; // nop for(i = 0; i < 100; i++); EMCDynamicControl = 0x101; // pall EMCDynamicRefresh = 1; // ?? for(i = 0; i < 100; i++); EMCDynamicRefresh = 19; EMCDynamicControl = 0x081; j = (*(volatile int*)0xA0000023); // 8 burst 2 cas EMCDynamicControl = 0; while(1) { if(x < 0xFFFFFFF) { *x = 0; x++; } FIO1SET = 0x10; FIO1CLR = 0x10; } return 0; } interessant ist auch, dass der Code nur bis zur Zeile *x = 0; läuft (auch im single-step Modus). Ist das Programm bei dieser Zeile angekommen, und man will den nächsten Befehl ausführen, dann 'hängt' sich die CPU auf und der Debugger meldet "cannot stop target", was man jeweils nur durch aus- und wieder einschalten des LPC beheben kann. Ah ja: als Takt benutze ich vorläufig noch den internen RC-Oszillator, da die Quarzoszillatoren, die ich bestellt habe, noch nicht da sind. Mittels PLL wird aber ein Takt von ca. 40 MHz (genau 39.39 oder sowas) erzeugt, was auch funktioniert. Wer kann helfen?
Angehängte Dateien:
-
clk.GIF
15 KB
So zum Beispiel sieht der Clock aus.... Verbindungen habe ich aber schon mit dem Ohmmeter geprüft, die sind IO.
Hey, also der Clock ist wirklich hässlich, ja. Der Tastkopf vom Oszi ist abgeglichen und sollte lt. Hersteller bis 1 GHz funktionieren. Daran wird es also nicht liegen. Ich kann mir auch nicht erklären, warum der Clock so scheisse ist! ein Kondensator hängt bestimmt nicht dran. Was aber interessant ist: Unterbreche ich die Verbindung vom Clock zu den RAMs, dann sieht er relativ 'normal' aus (in der Verbindung habe ich 2 Pads vorgesehen, um ggf. einen Terminierungswiderstand einfügen zu können - der ist momentan mit 0 Ohm überbrückt). Ich poste mal ein Bild...
Angehängte Dateien:
-
clk0.GIF
16 KB
So, also: Verbindung uC -> RAM ist jetzt unterbrochen; DIREKT am Pin des Controllers kommt angehängtes Signal raus. Die Leiterbahn ist 4 mm lang, dann kommt ein Pad wo sonst der Terminierungswiderstand drauf ist -> der ist entlötet.
Hallo Tobias, also deine Timings sehen mir etwas optimistisch aus, aber das könnte mit deinem relativ langsamen Takt passen. Auf jeden Fall wird das Mode-Register definitiv falsch geschrieben und du hast den Puffer auch nicht aktiviert. Probier mal folgendes aus:
1 | ...
|
2 | j = (*(volatile int*)(0xA0000000 | (0x22 << 13))); // 4 burst 2 cas |
3 | EMCDynamicControl = 0; |
4 | EMCDynamicConfig0 |= 0x80000; |
5 | ...
|
evtl. mal noch diese Zeile ändern:
1 | EMCDynamicConfig0 = ((1 << 14) | (1 << 12) | (1 << 10) | (1 << 9) | (1 << 7)); |
2 | {/c] |
3 | in
|
4 | [c] |
5 | EMCDynamicConfig0 = ((1 << 14) | (1 << 10) | (1 << 9) | (1 << 7)); |
Gruß, Kai
Bist du sicher, dass dein Schaltplan, bzw. dein Layout hinhaut? Evtl. den SD-Ram um 180° verdreht?
Hallo Kai, ich werde das gleich ausprobieren. Danke! Kannst du mir vielleicht auch erklären, warum der Clock vom uC so hässlich aussieht? Ich mein, es sind doch nur 40 MHz. Der Controller geht aber bis 72! und in dem Bild, das ich vorhin angehangen habe, ist der Clock _unbelastet_, nur mit ner 4 mm langen Leiterbahn.
Hallo Tobias, ja richtig, ich habe das Layout für eine Serienterminierung vorgesehen. Beim ersten Oszibild, das ich postete, war eine Brücke anstatt des Widerstands drin, und beim zweiten war gar nichts bestückt. Ich wollte eigentlich erst testen, ob es ohne Terminierungswiderstand geht (deshalb die Brücke) und falls nicht ggf. den richtigen Wert durch probieren herausfinden. Im Anhang mein Schema. Die SDRAMs sind auch definitiv richtig herum bestückt! Mit den im Schema gezeichneten Abblock Cs.
Also das mit der Clock kann ich dir leider nicht so recht beantworten. Meine Platine läuft hier ohne Murren mit 72MHz. Selbst bei testweise aktivierten 96MHz lief die Kiste noch ohne Probleme. Leider kann ich mir die Clock-Leitung z.Z. nicht anschauen, da mein Scope nur 30MHz macht. Hast du auf dem Pin 67 (P2.19) eine Funktion drauf? Wenn nicht, dann könntest du den probeweise auch mal ClockOut konfigurieren und sehen wie das Signal dort aussieht.
Also ich habe bei mir einen 33R Serienwiderstand direkt am Controller und einen 18pF Kondensator nach Masse am Speicher. Funktioniert prima. Aber über die Signalqualität kann ich im Moment keine Aussage treffen.
Hey Kai, hast du das nur an den Clock- und Steuerleitungen (also CS, WE und so weiter) oder auch an allen Datenleitungen? nur so aus Neugier. Gruss
Die Leiterplatte hat 4 Lagen: Signale GND VCC (3.3V) Signale So, und die Clock-Leitung hat eine Länge von ca. 5 cm. Breite 6 mils. Gruss PS: habe mal am Pin 67 ebenfalls CLKOUT eingeschaltet. Signal ist ebenfalls hässlich, aber nicht ganz so hässlich wie das erste.
Angehängte Dateien:
-
clk1.GIF
19 KB
So sieht der Clock am CLKOUT1 aus. Übrigens funktioniert das SDRAM jetzt; aber nur bis ca. 50 MHz. nachher ist sense.
Also auf dem aktuellen Layout ist nur in der Clockleitung der Serienwiderstand und der Kondensator gegen Masse. Für das Redesign habe ich aber zusätzlich einen Serienwiderstand in den Steuerleitungen vorgesehen, also RAS, CAS, DYCS0, CKE0, DQM3-1 und WE. Layout ist auch ein 4-lagiges, allerdings durchgehend 8mil Leiterbahnbreite. Länge der Clock-Leitung ca. 3,5cm.
Hast du mal probiert einen 18pF am Clock-Pin des Speichers zu platzieren?
Hast du das SDRAM auch 32 Bit breit angebunden? Übrigens war wohl vorhin mit meiner Lötbrücke was nicht in Ordnung, dass der Clock am CLKOUT0 so schlecht war. Er sieht jetzt einigermassen annehmbar aus; aber mit 72 MHz funktioniert das SDRAM dennoch nicht. Hast du irgend einen Clock-Treiber noch eingebaut?
Was bringt der 18pF denn? ich denke der verlangsamt doch die Flanken, weil der immer umgeladen werden muss? :o
Ja, ich habe auf zwei 16-Bit breite SD-RAMs (Micron) zu 32 Bit zusammengeschaltet. Einen Treiber habe ich nicht angeschlossen. Den 18pF hatte ich ursprünglich nur aufgrund eines Hinweises von EmbeddedArtists vorgesehen, da bei einigen Boards mit Samsung SDRAM die mögliche Taktfrequenz auf 48MHz beschränkt war. Durch den Einsatz des 18pF am SDRAM können die betreffenden Boards auch mit 72MHz laufen. Der 18pF bringt auf jeden Fall eine Verbesserung in Sachen Crosstalk durch steile Flanken auf benachbarten Leitungen. Ich weiß nicht, wie dein Layout aussieht. Evtl. ist das ja bei dir auch ein Problem.
Crosstalk wäre möglich; die Leitungen sind sehr nahe beieinander. Ich versuch das dann auch mal; aber die genannten 48 MHz passen ja recht gut! Obwohl ich zwar kein Samsung SDRAM habe. Schön wärs, wenn die Erklärung so einfach wäre :-) Ich muss das dann wie gesagt ausprobieren. Was ist übrigens mit unserem Digikey Kram? erinnerst du dich an die Mail? Gruss
Angehängte Dateien:
-
blubb.GIF
19 KB
@Kai also es eilt bei mir nicht! ich habe nur gefragt, weil ich dachte du hast es vielleicht vergessen ;-) @Tobias So hab jetzt ein bisschen gespielt mit Widerständen etc. So sieht jetzt der Clock am SDRAM aus! ist das akzeptabel?
Also ich hab jetzt den Terminierungswiderstand rein gepfriemelt. Den braucht es offensichtlich wirklich hier. Jaa, und der Grund, warum ganz am Anfang der Takt so mies war, war eine nicht so dolle Lötstelle. Nach dem nachlöten jedenfalls war das Zeug besser. Die Frage ist jetzt eigentlich nur noch, wie ich es auch auf 72 MHz schaffe, wie Kai ;-) @Kai du sagtest weiter oben, dass mein Timing etwas "optimistisch" sei. Warum meinst du denn? Ich habe nämlich jetzt mal ein kleines RAM-Test Programm geschrieben, und festgestellt, dass das SDRAM nicht so ganz zuverlässig funktioniert. Gelegentlich kippt mal ein Bit. Ich schiebe die Schuld jetzt einfach mal auf das optimistische Timing ;-) denn der Rest passt ja jetzt, denke ich?
Verändere mal deine Timings auf folgende Werte:
1 | EMCDynamictRP = 3; |
2 | EMCDynamictRAS = 5; |
3 | EMCDynamictSREX = 2; |
4 | EMCDynamictAPR = 2; |
5 | EMCDynamictDAL = 5; |
6 | EMCDynamictWR = 3; |
7 | EMCDynamictRC = 6; |
8 | EMCDynamictRFC = 6; |
9 | EMCDynamictXSR = 2; |
10 | EMCDynamictRRD = 3; |
11 | EMCDynamictMRD = 3; |
Und fast am Ende wird EMCDynamicRefresh bei dir auf 19 gesetzt. Mach dort mal eine 0x23, also 35 dezimal. Das sind zumindest die Werte, die ich bei meinen Microns bei 72MHz nutze. Man müsste nochmal ins Datenblatt der ISSI-Chips schauen und deren Werte umrechnen. (Im Datenblatt stehen immer ns-Werte. Der Controller will aber Taktwerte haben.) Jetzt sollte es eigentlich besser aussehen.
Also, es sieht jetzt schon etwas besser aus; aber ich hab immer noch ein Bit, das kippt. Schreibe ich irgendwo 0xA0000000 rein, dann lese ich einige Zeit später 0xA0000800 wieder raus. Und es ist IMMER dasselbe Bit, welches sich ändert!
Sind deine Leitungslängen stark unterschiedlich? Ist D11 wesentlich länger als CLK0? Evtl. sollte man doch nochmal die Timings des ISSI durchrechnen.
Die Leitungslängen sind zwar unterschiedlich, aber CLK ist definitiv am längsten von allen. Timing werde ich mir nochmal genau überlegen...
Ach ja, @Kai könntest du bei Gelegenheit einmal noch ein Bild machen vom Clock? Am Controller-Pin und am SDRAM-Pin. Das wär super! Gruss & schönen Abend
Kann ich generell machen, nur leider im Moment mangels passendem Scope nicht. Versuch du einfach mal die Timings noch etwas zu erhöhen (evtl. auch mit Maximalwerten) und so die Fehlerursache einzugrenzen. Viel Erfolg & schönen Abend!
Noch eine ganz dumme Frage. Der Baustein ist nicht zufaellig ein recht alter mit rev "-" ? Die sind naemlich unter Umstaenden nur bis 48 MHz gelaufen. Rev "B" laeuft allerdings meines Wissens nach LOCKER bei 72 MHz Gruss, Robert
Hi Robert, nee es ist eine Rev "B" die ich hier habe. Andere Frage: ich bin ein bisschen skeptisch, was den Treiber im Chip angeht. Der muss ja bei 72 MHz ganz ordentlich Dampf haben, wenn er die Clock-Leitung, die ja schon einiges an Länge haben kann, so schnell umschalten muss! und die Flanken müssen dabei immer noch ordentlich sein. Kannst du mir vielleicht sagen, warum die bei mir so schlecht sind? Sie sind ja sogar am CLKOUT1-Pin, der ja gar keine angeschlossene Last hat, schlecht! Wäre es vielleicht eine gute Idee, bei einem Redesign dort einen externen Buffer vorzusehen? respektive zwei, einen pro SDRAM-Chip. @Kai also, ich werde die Timings mal erhöhen, aber ich muss ehrlich sagen: ich bin enttäuscht, wie schlecht das funktioniert. Eigentlich habe ich das Datenblatt vom ISSI durchgelesen, und die Timings so berechnet, dass es klappen sollte. Angenommen, ich fahre 40 MHz ergibt das eine Periodendauer von 25 ns. Dann habe ich einfach alle Zeiten, die im DB aufgeführt sind durch diese 25 ns geteilt und aufgerundet. Das ergibt dann die Werte, die ich in die Register rein schreiben muss. Richtig? Dann MUSS es doch einfach funktionieren. Langsam bin ich mit meinem Latein am Ende :-(
Wie sieht bei dir die Versorgung des Controllers aus. Ist das Layout dieser schlecht, kann durchaus auch hier der Grund für die unsauberen Pegel bzw. Flanken liegen. Die Sache mit den Buffern würde ich nicht in Betracht ziehen. Die verlängern deine Signallaufzeit des Takts zu den restlichen Signalen. Da musst du erst kucken wieviel Spiel du hast.
Hi Tobias, Also die Versorgung habe ich mit Planes gemacht. Einen Layer mit 3.3V und einen mit GND. Durchgehend, nirgends unterbrochen. Und dann halt bei jedem Pin mit einem kurzen Stück Leiterbahn (so ca. 3 mm) rausgefahren und dort ein Via platziert, welches den Pin entsprechend mit GND oder VCC verbindet. Das ist doch schon richtig so oder? Jaa, und dann die Abblock-Cs. Die habe ich vorgesehen, aber noch nicht alle bestückt, weil ich nicht mehr genug da hatte :-( Die SDRAMs sind aber beide vollständig abgeblockt, der Controller leider nur teilweise. Meinst du das macht so viel aus?
Hallo Tobias, ich habe mir gerade nochmal deinen Schaltplan angeschaut. Du hast deine Abblockkondensatoren alle nur mit 10nF ausgelegt. Ich habe hier überall 100nF. Am Controller habe ich 13x 100nF in 0402. Du hast hier nur 11x 10nF. An den SD-RAMs habe ich jeweils 7x 100nF in 0603. Du hast hier nur 3. Vermutlich nur an den VDD-Pins, nicht an den VDDQ. Könnte natürlich eine Erklärung sein. Vielleicht kannst du in diese Richtung noch etwas probieren. Zu den Timings: Prinzipiell ist dein Vorgehen richtig. Wenn du den Controller aber mit 72MHz betreibst, dann hast du nurnoch eine Periodendauer von 13,88ns.
Ich bin jetzt mal so frei und wage es mich festzulegen. Deine Probleme kommen zu 99% von den fehlenden C´s
Und etwas größer sollten die auch sein wie Kai schon schrieb ..
Hallo Kai, also das mit den 10 nF liegt an folgendem: ich habe mit meinem Chef vor einiger Zeit eine lange Diskussion darüber geführt, ob man 100 nF Kondensatoren oder irgend etwas anderes braucht. Er ist aber DER EMV-Guru; er meinte bei einer Leiterplatte >= 4 Lagen sind 10 nF besser als 100, deshalb habe ich 10 verbaut. Ob es wirklich so ist, kann ich nicht beurteilen, aber ich besorge mir heute Nachmittag ein paar 10 nF unfd versuche es damit mal. Vielleicht hat er ja Recht ;-) > Wenn du den Controller aber mit 72MHz betreibst, dann hast du nurnoch eine > Periodendauer von 13,88ns. Jaaa, schon, aber bei dir läuft er ja auch noch mit 96 MHz ?! ich frage mich aber vor allem, wieso die Pegel nicht sauber auf 0 runter kommen....
Kommt auch drauf an ob du von einem zentralen Massepunkt aus die Messung durchführst oder zwischen deinem Takteingang und dem lokalen GND des SRAM bzw. deinem Taktausgang und dem GND des uC ...
Und das haben Chefs leider so an sich. Meiner denkt auch er wäre der EMV Guru höchst persönlich. Allerdings durfte das Redesign des letzten 8 Layers ich machen, nachdem die ersten Protos floppten ...
@Tobias Hehe, jaaa.... meinst du 10 nF sind Quatsch? Ein bekannter von mir arbeitet in einer Firma, welche irgendwelche Sachen mit High-Speed digital Zeugs machen, so mit Frequenzen im GHz-Bereich. Der sagt sogar, an jedem VCC-Pin muss 1 x 10pF, 1 x 1 nF und 1 x 10 nF sein, und dann verteilt auf der Platine 100 nF und Elkos mit 1 u. Was sagst du denn dazu?
Ich will deinem Chef jetzt echt nix unterstellen, aber diese Aussage kommt mir etwas überholt vor. Ich kann es mir nur so vorstellen: Früher, als die Kondensatortechnologie, d.h. die Keramiken, noch nicht so gut waren, hatte man das Problem, dass die größeren Kondensatoren schlechtere Keramiken und somit ein schlechteres Ansprechverhalten hatten. Heutige Kondensatoren bis hin zu 10uF und sogar noch höher bestehen selbst in 0805 aus X5R oder X7R. Damit sollte sich das marginal schlechtere Ansprechverhalten eines 100nF gegenüber 10nF durch die höhere Kapazität locker ausgleichen. Mein "Lehrmeister" setzt auch überall 100nF als Abblockkondensator ein. Wenn es etwas kritischer ist, dann kommt noch ein 1nF dahinter. Und wenn es ganz ordentlich sein muß, dann kommt davor noch eine Ferritperle und ein Kondensator.
@Kai okay, deine Erklärung hat auch was für sich. Nun gut, notfalls könnte ich ja immernoch 100 nF einlöten statt der 10 nF. Btw.: ist dein Board eigentlich auch ein selbst gemachtes? hast du das professionell bestücken lassen oder wie? du sagst du hast 0402 drauf. Da braucht man ja ein Mikroskop ;-)
In der Beziehung scheiden sich die Geister. Auf der einen Seite möchte man über ein möglichst breites Spektrum einen niedrigen Impedanzverlauf erzielen. Deswegen setzt man gerne unterschiedlich große Cs ein. Das ist jedoch ein Fehler der sich seit Jahren in der Schaltungstechnik fortpflanzt. Das Problem liegt darin, dass unterschiedliche C-Werte genommen werden die Baugröße jedoch gleich bleibt. Allerdings wird die parasitäre Induktivität der Cs durch die Geometrie und damit der Bauform bestimmt, nicht durch den Wert des Kondensators. Auf der anderen Seite kann eine "unglückliche" Wahl deiner C-Werte zu einem sauberen Parallelschwingkreis führen. Ich blocke deswegen grundsätzlich nur mit einem C-Wert ab. Wenn du Zeit hast, lies dir mal diesen Artikel durch. http://www.eue24.net/pi/index.php?forward=downloadPdf.php&p=mJ3rC2nsGxWFBanjU.jGmQF3Ccl_ExFxccClnMfiMg3pRUO0SLjfEtfros@@G@I0PVRxmd8uaJOnQULfAxj_HXyzBcTor_ZxV_NXHQBuqthscYWqAh.vEg.GYEO9
Also das Board wurde von mir entwickelt. Bisher gibt es zwei Prototypen, die ich beide per Hand bestückt habe. Insgesamt sind da jeweils gut 300 Bauteile drauf. Die passiven Bauteile sind fast ausschließlich in 0603. Die Abblockkondensatoren am LPC sind in 0402 und ein paar größere Cs (1µF-10µF) sind in 0805. Ansonsten noch ein paar größere Elkos. Die Serie wird noch einmal ein wenig überarbeitet und dann professionell bestückt. Also ich muß sagen, dass sich 0402 noch ganz bequem bestücken lässt. Da sehe ich keinen großen Unterschied mehr zu 0603 (das richtige Werkzeug vorausgesetzt). Ab 0201 macht es dann aber auch keinen rechten Spaß mehr. Aber das setzte ich nur in der größten Not und bisher auch nur privat ein.
@Tobias danke für den Link. Der Artikel sieht recht interessant aus. Ich habe mir jetzt auch auf die schnelle ein paar 10 nF besorgt (mein PDA musste dran glauben.... da waren tatsächlich noch ein paar 0603 drin). Und ich kann es kaum glauben, aber!!! die SDRAM scheinen jetzt tatsächlich zu funktionieren. Es kippt kein Bit mehr, die Flanken sind nochmal etwas besser geworden. Ich habe nochmal ein RAM-Test Programm geschrieben. Erst wird alles mit 0 überschrieben, danach mit 0xAAAAAAAA und dann mit 0x55555555. Nach jedem Überschreiben wird alles überprüft. Nach 10 Durchläufen kein Fehler. Dann wird in jede Speicherzelle die Adresse der jeweiligen rein geschrieben. Hier bis jetzt nach 5 Durchläufen kein Fehler. Scheint also tatsächlich an den blöden Kondensatoren gelegen zu haben!
@Kai darf man fragen, was denn sonst noch so auf dem Board ist ausser dem LPC und SDRAM?
Hast du jetzt nur die Kondensatoren am LPC vervollständigt, oder auch an den SDRAMs?
Job getan, Wochenende gerettet. Denkst du schon es läuft nichtmehr, kommt irgendwo ein Tobias her :-)
An den SDRAMs waren schon alle Kondensatoren dran (wie du richtig vermutet hast an VDD, VDDQ habe ich als nicht so heikel erachtet.... so kann man sich täuschen). Am LPC sind jetzt auch alle dran.
@Tobias jaaa, genau :-) aber das Wochenende ist dadurch nicht gerettet, da SDRAM ja jetzt funktioniert kann ich mich den übrigen Teilen der Schaltung widmen :P
Zonk :-) Meinen Proto hab ich heute morgen fertig getestet. Da war "nur" Gate und Source eines Mosfets vertauscht ... scheis library
Was wars denn für ein Proto? hehe, ich hab auch an einer Stelle einen falschen Footprint. Tja, ich hätte die Reihenfolge bei der Pinnummerierung kontrollieren sollen.... Auf jeden Fall sind da jetzt 2 Pads über Kreuz verdreht. Mit ein bisschen Wrap-Draht lässt sich das allerdings recht gut retten ;-)
Also auf dem Board werkelt ein LPC2478 im LQFP208 mit zwei Micron SDRAMs (MT48LC16M16A2P), ein MicroSD-Kartenhalter, ein Touchscreen-Controller (TSC2046), ein Atmel Dataflash (AT45DB161D) und ein 4,3"-TFT mit Touchscreen von Sharp (LQ043T1DG02) sowie ein DAC8551 + LM386 für Sound-Ausgabe. Der Rest der Schaltung (Analogteil) ist Applikationsspezifisch und dazu will ich hier nicht mehr ausführen, da es sich dabei um ein kommerzielles Produkt handelt. Privat bin ich aber im Moment noch über einem recht universell gehaltenen Board mit LPC2478, 64MB SD-RAM, USB-Host/Device, Ethernet, SD-Karte, NAND-Flash, VS1053 und ein paar anderen Kleinigkeiten. Der EMC wird 16-Bit breit und gepuffert über einen Steckverbinder verfügbar sein, sodass man noch Memory-Mapped-Devices anbinden kann. Außerdem gibt es einen Steckverbinder für die ganzen LCD-Signale und einen weiteren Steckverbinden für sonstige IO-Pins, die noch nicht genutzt sind, bzw. die man mehrfach nutzen kann. Das Board ist 110x100mm² groß und die Stecker (USB-Device, USB-Host, Power, Ethernet, Audio, ...) sind auf einer Seite (100mm lang) herausgeführt, sodass das Board recht einfach in einem Gehäuse verbaut werden kann.
Der Gute blau WireWrap Draht, ohne den würde mal gar nichts gehen :) Ist eine Messkarte mit ca. 700 Bauteilen und 2478 Pads. Die Evaluierung hat auch ca 2 Wochen gedauert.
@Kai wow, coole Sache! Das mit dem LCD klint auch interessant. Ich möchte dann, wenn ich alles getestet hab, und es funktioniert, auch was ähnliches machen. Halbe Europakarte, also 100 x 80, und da drauf sollen SD-Karten, irgend ein Flash mit paar 100 MB sowie natürlich SDRAM und Etherne. Ein kleiner FPGA soll dann als Memory-Mapped IO-Controller fungieren; er könnte dann vielfältige I/O Aufgaben übernehmen.... Jaa, irgend sowas bin ich am planen. Deshalb habe ich erstmal diesen Prototypen hier gebastelt, um alles testen zu können (jetzt sehe ich z.B. wie heikel SDRAM ist!).
Kai, ich glaube wir sollten uns mal austauschen. Plane gerade ein Projekt mit dem LPC2478, Sharp 4,3" TFT, einem Cyclone 2 der am EBI hängt und 2 x 1 Giga Sample ADC´s.
Irgendwie gehen wir drei alle in die selbe Richtung :-)
@Tobias jaaa, zumindest was den FPGA angeht ;-) Als Display habe ich aber eher sowas vorgesehen: http://www.marelcom.ch/news.php?id=60 "5.7 Zoll TFT mit UART-Schnittstelle" denn, ich habe keine LPC2478 hier und wüsste auch nicht wo man ein geeignetes TFT beziehen könnte. Dieses UART-Teil hier bekomme ich günstig von meiner Firma.
Ja, klingt fast so. Vielleicht kann man das ja irgendwie verbinden. Evtl. kann man mein Board als Basis nutzen und den Cyclone 2 und die ADCs als Applikationsboard draufstecken.
Was soll das mit den ADCs denn werden? Kai, wie "erzeugst" du denn den Sound, den du ausgeben willst? MP3-decodierung in Software? Oder was?
Also eine Grafikausgabe über UART ist aber bestimmt recht langsam. Wenn du kein Touchscreen brauchst, dann bekommst du solche 4,3" Displays in der eBucht bereits für 20-30€.
Ja, in der Richtung bin ich mir immer noch unschlüssig. Wollte anfangs alles auf ein Board schmeisen. Allerdings bin ich in den letzten Tagen immer mehr zum modularen Aufbau abgedriftet und wollte sowohl auf dem uC Board einen FPGA und dann auf den Modulen wieder jeweils einen FPGA verwenden um eine möglichst hohe Datenrate zu gewährleisten.
Kai, Jaa mag sein dass das nicht ultraschnell ist, aber ich will ja auch nicht zocken damit ;-)
Auf dem aktuellen Board ist es wirklich nur als Sound-Ausgabe gedacht, d.h. die kurzen Wave-Samples werde von der SD-Karte in den SD-RAM geladen und bei Bedarf an den DAC8551 gesendet.
@Tobias ah ja du baust ein Oszi? wow. Okay. Nicht schlecht! woher hast du dennn die Gigasample ADCs? Ist das ein kommerzielles Projekt oder ne private Bastelei?
Das wird rein privat laufen. Die ADCs bekomme ich von National gesponsort. Falls ihr welche braucht würde sich da sicher auch was machen lassen.
@Tobias welches Modell ist es denn? und wieso bekommst du die "gesponsert" ? Sind es etwa Muster oder wie? Ich will auch was gesponsert bekommen! ;-))))) Also, wenn du einen oder zwei über hast .... :-D Was zum Basteln ist imme gut.
There we go: 1GS http://www.national.com/pf/AD/ADC081000.html bzw. 0,5GS http://www.national.com/pf/AD/ADC08500.html Bin mir noch nicht 100%ig sicher welchen ich jetzt nehmen werde. Eigentlich würden 500MSPS auch reichen.
Naja, zocken will ich damit auch nicht, aber wenn du ein Display mit VGA-Auflösung (640x480) über den UART mit 500kBaud mit Pixeldaten füllen willst, dann braucht das immerhin gut 12s. Ich denke mal, dass das Display irgendwelche Zeichenoperationen (Punkt, Linie, Rechteck, Kreis, ...) unterstützt, aber für alles was darüber hinausgeht, ist es doch sehr langsam. Da kann man nur hoffen, dass es Double-Buffering unterstützt. Nee, aber mal ehrlich: Für einfache Visualisierungen mag es gut sein, aber wenn du eh schon den LPC2468 einsetzt, dann kannst du eigentlich auch gleich den LPC2478 nehmen und ein LCD dranhängen. Ich muß aber ehrlich zugeben, dass sich das Layout doch um einiger verkompliziert, aber es ist auf 4 Lagen durchaus möglich. (Das Display ist bei mir übrigens 24 Bit-breit angeschlossen.) Wenn ich den erwische, der das Pinout des LPC24xx verzapft hat, dann ... ;-)
Eigentlich wären mir die ASICs von Agilent lieber, allerdings wollen die mir nix geben :)
Wow, cooles Teil! Aber sag mal, wie kommst du denn dazu, dass die dir was sponsern? Hehe, jaa Agilent hat natürlich auch gute Teile im Angebot ;-) das wird aber wirklich schwieriger.... ausser ich schlachte mein Oszi und verhökere die Teile hier. Wird sich aber kaum lohnen :p
Tobias, über Vitamin-B redet man nicht sondern nutzt es gnadenlos aus. Hat dir das noch niemand verraten :-) ?
Also, der ADC ist wirklich toll. Was aber ein bisschen schade ist: dass die Ausgänge als LVDS ausgeführt sind. Damit habe ich keinerlei Erfahrung. Da braucht man spezielle Treiber für, nicht?
AFAIK besitzt der Cyclone 2 doch LVDS-fähige IOs. Edit: Hab' grad nochmal geschaut, er hat! http://www.altera.com/products/devices/cyclone2/features/io_capabilities/cy2-io_capabilities.html Der Punkt ist einfach, dass du über TTL diese hohen Datenraten nicht mehr wirklich drüber bekommst.
Aaah, ja dann ist das ja kein Problem ;-) Sag mal Kai, noch ne Frage wegen des Datenbusses der SDRAM. Sollte man den auch terminieren? Und wie sollte die Terminierung beim Clock aussehen? Tobias meinte ja, dass man eine Serieterminierung eigentlich nur bei Punkt-zu-Punkt Verbindungen machen sollte. Wie siehst du das? Ich habe mir nur grade überlege - wenn dann noch der FPGA am Datenbus hängen soll, dann wird es ja immer schwieriger eine gescheite Terminierung zu machen.....
Das ist doch gerade das schöne an den Ausgängen. Mit den LVDS Ausgängen kann man beim Routing nichtmehr so viel falsch machen :-)
Zum Routing: Deswegen wollte ich auf einen FPGA auf dem uC Board und jeweils einen FPGA auf den erweiterungs Modulen gehen. Da wird einfach ein LVDS Crosspoint genommen und die ganze Terminierungskacke ist Geschichte.
Aaaaha. Jaa... Hmm diese LVDS-Geschichte muss ich mir später noch genauer ansehen. Aber wie der FPGA mit dem uC verbunden wird, das Problem bleibt! Wo soll denn da die Terminierung sitzen? Zumindest beim FPGA braucht es ganz sicher eine, schon bei einem Cyclone II sind die IOs sauschnell (500 ps rise time, wenn ich mich recht erinnere? stand irgendwo so was im Datenblatt....).
Also von einer Terminierung des Datenbusses würde ich bei so kurzen Verbindungen absehen. Das absolut wichtigste ist, dass die Clock-Leitung recht sauber ist. Ich versuche bei sowas auch irgendwelche Sternverbindungen bzw. Abzweigungen zu vermeiden. Wenn man den FPGA an den Datenbus hängt, dann ist es schon eine Frage der Platzierung, relativ zum Speicher und zum Controller. Kann man den SDRAM sauber zwischen den Controller und den FPGA routen und sind die beiden (µC und FPGA) nicht zu weit voneinander entfernt, so würde ich darauf versichten. Lediglich den Steuerleitungen würde ich eine Serienterminierung gönnen. Ist der FPGA noch weiter entfernt, oder hängen noch mehr Teilnehmer am Bus, so würde ich hinter den SDRAMs auch einen Bustreiber vorsehen, so wie ich es jetzt auch bei dem oben genannten Board mache.
Könnte man den Bustreiber auch direkt an den LPC schalten? Ich bin mir nur nicht ganz sicher, mit welchem Signal man dem Bustreiber die Richtung vorgeben kann. Verwendet man SRAM, dann ist das klar: das Signal \OE legt fest, ob der Bustreiber in die eine oder in die andere Richtung treiben soll. Bei SDRAM gibts aber kein \OE.....
Jungs, ich bin erstaut - mein LPC läuft jetzt auch mit 80 MHz, ohne dass die SDRAMs fehler produzieren. RAM-Test läuft jetzt schon ne Ewigkeit, und kein Bit ist gekippt. Faszinierend ;-)
Die Bustreiber werden direkt an den LPC geschalten. Der /OE der LPC schaltet dann die Richtung.
Ja, es ist schon ein sehr erhebendes Gefühl, wenn die Kiste das Fliegen lernt! ;-)
> Der /OE der LPC schaltet dann die Richtung.
??
sicher? Beim SDRAM ist das OE ja aber gar nicht beschalten.
Der SDRAM hängt ja vor dem Bustreiber und der ist beim Zugriff auf den FPGA (als statisches Device) sowieso deaktiviert (DYCSx inaktiv).
Könnte man das SDRAM aber auch NACH den Bustreiber schaten? Das war ja eigentlich meine Frage ;-) Dass es funktioniert, wenn die SDRAMs vor dem Treiber sind, ist klar. Der FPGA wird dann so programmiert, dass er sich wie ein SRAM verhält, oder? Also dass du per Adressbus ein Register auswählen kannst und per \WE wird was reingeschrieben und mit \OE raus gelesen. Richtig?
Aber wieso sollte man den SDRAM hinter die Bustreiber hängen? Evtl. könnte man per Logik aus dem WE und den DQMx-Leitungen die Richtung ableiten, aber das finde ich unnötig kompliziert.
Na, ich dachte nur - wenn man schon Bustreiber hat könnte man die SDRAMs ja auch direkt mit denen Treiben. Meinst du man braucht schon einen Treiber, wenn man nur noch den FPGA mit drauf hat?
Zum FPGA: Richtig, er wird als Memory-Mapped-Device implementiert. Man kann das mit direktem oder indirektem Bus-Interace machen. Direkt ist halt schneller, braucht aber auch die ganzen Adressleitungen.
> Direkt ist halt schneller, braucht aber auch die ganzen Adressleitungen. Wie viele Adressen man braucht hängt ja auch davon ab, wie viele Register im FPGA adressiert werden sollen oder. Was schwebt dir da vor? Routest du den ganzen Adressbus des LPC zum FPGA? Das wird ja ein riesen Aufwand! Ich persönlich würde wahrscheinlich nicht mehr als 10 Adressleitungen zum FPGA führen. Den Datenbus dafür 32 Bit breit, so kann man doch immerhin 1024 Register zu 32 Bits ansprechen. Was wohl reichen sollte, oder nicht?
Tobias, denke immer an das KISS-Prinzip. Du scheinst noch im Studium zu sein, sehe ich das richtig ? Du wirst noch einige schmerzliche Erfahrungen machen müssen. Keep it simple, stupid kann dir aber bei 99% aller Probleme den Hals retten :)
Zum FPGA, alle Adressleitungen wird man nicht brauchen. kommt drauf an in welchem Bereich der Map man die Daten sehen möchte. Wir sollten uns wirklich mal genauer austauschen. Über dieses vertrollte Forum hier gehen leicht Sachen unter. So hat ein offensichtlich überforderter Mod meine ersten Posts gelöscht ....
Naja, man muß die ganzen Samples des ADC ja auch irgendwo puffern, d.h. er hat selbst auch noch einen Speicher. Nun gäbe es halt die Möglichkeit diesen Samplepuffer direkt auf den Bus zu mappen, d.h. der LPC könnte sich dann jedes beliebige Sample aus dem Speicher des FPGA holen, ohne vorher in einem Register sagen zu müssen, welchen er denn gerne haben würde. Das heist natürlich nicht, dass der Speicher des FPGAs direkt am LPC hängt, sondern nur, dass der FPGA direkt auf die Anfordung am Adressbus reagiert und den Wert am Datenbus anlegt.
@Tobias nee, Studium habe ich noch nicht angefangen. Das kommt aber im Herbst! Was meinst du, was ich nicht "simple" zu halten versuche?
Das war auf die Sache mit dem SRAM und dem Bustreibern bezogen. Was noch nicht im Studium ? Scheinst aber dafür schon recht weit zu sein was die Elektronik angeht ...
Vielleicht sollte man eine kleine Mailing-Liste einrichten. Im einfachsten Fall eine geschlossene Yahoo-Group.
@Kai also, ich habe mir eigentlich überlegt, dass es doch eine 'Verschwendung' von Platz wäre, wenn man alle Adressleitungen verbinden würde. Stattdessen sieht man im FPGA ein "Datenregister" vor. Liest man aus diesem, dann holt sich der FPGA immer das letzte Sample vom ADC. So muss man nur von einer Adresse lesen, kann aber trotzdem alle Samples des ADCs holen. Mit dem DMA des LPC kann man das sogar auch einstellen, dass er Daten immer von der selben Adresse holt. Ich weiss im Moment aber nicht auswendig, ob der DMA auch auf den EMC zugreifen kann....
Die Idee mit der Yahoo user Group klingt nicht schlecht. Ich werde mich morgen mal darum kümmern.
@Tobias naja, ich habe erst eine abgeschlossene Berufslehre. Aber ich befasse mich, wie du merkst, privat sehr viel mit Elektronik ;-) Aber sonst eher Leistungs-Sachen, also Motorsteuerungen, Schaltnetzteile... meine praktische Abschlussarbeit war ein 1 kW Frequenzumformer. @Kai wir können ja Email Adressen austauschen. Deine hab ich ja ;-)
Der DMA des LPC kann auf den EMC und den USB-RAM zugreifen, d.h. er könnte immer Daten vom FPGA holen und im 16kByte USB-RAM ablegen. Dann wieder von dort in den SD-RAM. Also alle 24 Adressleitungen würde ich NIE verbinden. Das ist absoluter Overkill. Ich hätte an max. 16 gedacht. Evtl. reicht es ja auch den Datenbus 16 Bit breit anzubinden. Der ADC hat ja eh "bloß" 8 Bit. So könnte man bei zwei Kanälen auch ein Sample von beiden Kanälen einlesen, aber darüber kann man sich ja noch Gedanken machen. Ich würde es nur vermeiden, das Ding komplett indirekt anzubinden.
Ich denke du hast da schon ne recht konkrete Vorstellung Kai, gefällt mir bisher sehr gut.
Ich werde, mit eurem Einverständnis, jetzt mal eine Yahoo-Group einrichten: Was haltet ihr von 'TTKprojects'?
Warum nicht, würde gut passen. Es wurmt mich nur, dass ich mir schon eine Stunde lang (wohlgemerkt auf der Arbeit) einen Namen für mein Projekt habe einfallen lassen. e-TOval Naja, eigentlich egal, der Inhalt muss stimmen :)
Ach schnick schnack, ich stimme dem TTKprojects zu. Tobias (hubertus) ist damit quasi schon überstimmt :) So muss eine Demokratie laufen ... ich klinke mich jetzt mal für die nächsten Stunden aus und melde mich dann heute abend in der bis dahin hoffentlich schon vorhandenen yahoo group. Meine E-Mail: Sepu2k@gmx.net
Hey Leute, sorry dass ich mich erst jetzt wieder melde. War kurz weg, mit paar Freunden ein Bier trinken ;-) @Tobias TTKprojects ist schon in Ordnung; aber ich kann mir grade keinen Reim drauf machen, was es bedeutet. Wenn du mich vielleicht aufklären möchtest ;-)
Wieso fehlen hier eigentlich die ganzen alten Beiträge von Tobias (nicht hubertus) ???
Schau dir mal deinen Post von 09.07.2009 18:53 an. Dort antwortest du an Tobias, aber von ihm ist vorher kein Post vorhanden. Genauso hatte irgendwer nach HildeK geschrien. Dieser Post ist auch weg!?
Tatsächlich! :o komisch.... da hat wohl wer an der Löschfunktion rumgebastelt? ;-)
Das kann nur ein Mod gewesen sein, aber wieso? Das würde ich doch gerne genauer wissen!
Jaa, das würde mich auch interessieren... BTW, ist dir aufgefallen dass solche "Lücken" in vielen Threads auftauchen??
Ja, teilweise werden die ganzen Trollposts entfernt, was ja auch der Lesbarkeit der Threads dient, aber hier waren keine Trolle am Werk!?
Ja Tobias scheint wirklich kein Troll zu sein ;-) vielleicht weiss Andreas etwas?
Der Troll ist wieder da :) War wohl weil ich gestern in einem der vielen Troll Threats einen etwas fieseren Seitenhieb ausgeteilt habe ... Ich denke dass alle Posts die an diesem Tag unter meiner IP gemacht wurden einfach deleted wurden. Nun zur User Group. Wie siehts aus Kai ?
Jetzt wieder. Die Mail hab ich bekommen, jetzt muss ich nur wieder meine Yahoo ID finden. Grübel
Oh mach dir keine Sorgen, ich war wohl nur einer von vielen die da gestern ihren Beitrag geleistet haben wenn man das so sagen kann. Eigentlich hatte ich gehofft dadurch etwas silence zu erwirken ... war ehr das gegenteil :)
Hmm.... ich blick ehrlich gesagt grade nicht mehr ganz durch. Hast du Mail bekommen von mir oder so?
Eine Mail? Nee, nur deine Annahme der Einladung, die ich dann zugelassen habe. Dann habe ich noch eine Nachricht über die Group gepostet.
Also 1) Nein ich bin kein Troll ... 2) Bitte etwas gedult, ich suche nach meiner Yahoo ID -.-
@Kai okee, dann ist alles i.O. :-) @Tobias guck ma: http://keepass.info/ das Programm ist sehr empfehlenswert. Bis ich das hatte, habe ich auch ständig Logins, IDs und Passwörter vergessen....
Kai,
> Ich bin begeistert! :-)
wovon? von unserer Group oder von dem Link den ich gepostet hab? ;-)
Oh man, ich hab schon ganz vergessen wie lahm die User Groups sind :)
Tobias Plüss schrieb: > Kai, > >> Ich bin begeistert! :-) > > wovon? von unserer Group oder von dem Link den ich gepostet hab? ;-) Eigentlich davon, dass wir es nun alle in die Group geschafft haben. @Tobias: Ja, so sehr schnell sind die Yahoo Groups leider nicht. Aber ich denke, dass wir damit leben können?!
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.