mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LCD Timings - SVGA - LPC2478


Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin am testen meines LPC Boards. Da ich am Display Port einen LVDS 
Transmitter habe, habe ich ein 800x600 Display von Unipac angeschlossen.

Prinzipiell habe ich ein Bild, allerdings sieht es aus als würden die 
Back und Front porch Angaben nicht stimmen. (Zittern und zu lange 
Zeilen)

Es handelt sich um ein UB084S01: 
http://www.gblcd.com/datacenter/unipac/UB084S01.pdf

Meine Initialisierung sieht so aus:
PCONP |= (1<<20);  //Enable LCD controller
LCD_CTRL = 0x2A;  //TFT 24 Bit
LCD_CFG = 1;    //Set divider CCLK/2 = 40 MHz 
LCD_POL =  (0x01 << 26)|(799 << 16)|(0x00 << 14)|(0x01 << 13)|(0x01 << 12)|(0x01 << 11);  
//Bypass pixel clock divider | 800 clocks per line | invert: panel clock, h clock, v clock
LCD_TIMH =  (87 << 24)|(39 << 16)|(127 << 8 )|(49 << 2);  
//Back porch = 88 clk | Front porch = 40 clk | Pulse with = 128 clk | Size = (49 + 1)*16 = 800 px
LCD_TIMV = (22 << 24)|(0 << 16)|(3 << 10)|(599);      
//Back porch = 22 px | Front porch = 1 px | Pulse with = 3 px | Size = 600 px
LCD_UPBASE = LCD_VRAM_BASE_ADDR & 0xfffffff8;
LCD_LPBASE = LCD_VRAM_BASE_ADDR & 0xfffffff8;
LCD_CTRL |= 1|(1<<11);    //Enable LCD

Habe ich die porch clocks etc. korrekt umgerechnet und eingesetzt? Oder 
muss ich meinen Fehler wo anders suchen?

Der LPC2478 läuft auf 80 MHz, das macht keine Probleme, auch mit dem 
SDRAM.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt der Zeilenanfang, d.h. ist der Pixel ganz links in einer Zeile da 
wo er sein soll, oder ist er auch schon nach rechts verschoben?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da das Display das DataEnable Signal auswertet, sind die Front und 
Backporchzeiten nicht allzu kritisch.
Wenn ich das Datenblatt des LPC2478 richtig verstehe, ist der CPL Wert 
im LCD_POL Register die gesamten Takte pro Zeile, also 1056 und nicht 
800.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Zeilenanfang stimmt. Das Ändern des CPL Wertes auf 1056 führt dazu, 
dass gar nichts mehr angezeigt wird. Wäre 1056 nicht eh zu groß für 
dieses Register?! (11 Bit in 9 Bit Register?)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Omega G. schrieb:
> Wäre 1056 nicht eh zu groß für
> dieses Register?! (11 Bit in 9 Bit Register?)

Das Register hat 10 bit, aber das ist immer noch zu klein. Der LPC ist 
also etwas beschränkt was die Displaygröße angeht. Stell mal 1023 ein.
Die Summe aus Frontporch + Backporch + Syncimpuls + Pixel auf dem 
Display muss gleich dem CPL Wert sein. Vermutlich musst du daher die 
Front + Backporch Werte reduzieren, damit die Zeile eben maximal 1024 
Pixel lang wird.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieses Zittern und die zu langen Zeilen deuten darauf hin, dass du ein 
übersprechen von Datenleitungen auf die Clock-Leitung hast. Deine 
Aussage, dass der Zeilenanfang stimmt, bestätigt diese Theorie.
Du hast in dener Clock-Leitung einen Widerstand (R20). Löte einmal einen 
18pF oder 22pF Kondensator hinter dem Widerstand gegen Masse, sozusagen 
ein Tiefpass.

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt 10 Bit!

1023 verändert an der anzeige was, aber natürlich bringt es nicht den 
gewünschten Effekt.

Im Anhang das Bild. Es sollen alle 10 Zeilen eine Zeile weiß sein.

Sieht aus, also ob das nichts wird mit diesem LCD, obwohl der Controller 
theoretisch bis 1024x768 unterstützen sollte.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Omega G. schrieb:
> 1023 verändert an der anzeige was, aber natürlich bringt es nicht den
> gewünschten Effekt.

Reduzier mal den Frontporch auf 32, den Backporch auf 80 und die 
Syncbreite auf 112. Das sollte exakt 1024 Pixel pro Zeile ergeben.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Angabe von 799 für CPL stimmt aber!

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erste Zeile stimmt so, die zweite hat etwas rechts von der Mitte aus 
eine Unterbrechung. Wenn ich das richtig sehe, stimmt jede zweite Linie.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai F. schrieb:
> Die Angabe von 799 für CPL stimmt aber!

Sicher? Dann ist das Datenblatt aber falsch:

CPL Clocks per line.
This field specifies the number of actual LCDDCLK clocks to the
LCD panel on each line.

-> gesamte Anzahl an Takten pro Zeile

PPL Pixels-per-line.
The PPL bit field specifies the number of pixels in each line or
row of the screen.

-> aktiver Bildbereich

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Betreibe hier ein 480x272-Display mit dem LPC2478 und da ist 479 
richtig.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit CPL = 799 zeigt das Display gar nichts an, mit den Angaben von 
Benedikt. Wenn ich CPL auf 1023 setze schon.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach mal bitte ein Bild vom Display mit den Settings, die du in deinem 
ersten Post hattest.

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So sah's aus.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls du ein Oszilloskop oder einen Frequenzzähler hast, schau dir mal 
das Signal an DataEnable an oder messe zumindest die Frequenz von HSync.
Daran kann man leicht erkennen, ob der CPL Wert korrekt ist.
Bei 1056 Takten pro Zeile sollte die Frequenz 40MHz/1056=37,88Hz 
betragen, bei 800 dagegen 50kHz.
Ebenso sollte bei den richtigen Einstellungen DataEnable ein 
Tastverhältnis von 800/1056=75,75% haben.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann gleich mal mit einem Oszilloskop ran. Mir kam noch eine andere 
Idee. Wenn ich die CLK Frequenz reduziere, kann ich auch den CPL Wert 
reduzieren?!
Ich bin etwas runter mit dem Takt auf 38 MHz, und habe den CPL Wert auf 
952. Das führt dazu, dass die Unterbrechungen am weiter am Anfang der 
Zeile sind.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Bild steht so aber still?
Was hast du in den Framebuffer geschrieben?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DataEnable:
Frequenz: 37,8 kHz
Duty Cyle: 75,7%

HSync:
Frequenz: 37,8 Khz
Duty Cycle: 87,8%

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Omega G. schrieb:
> Wenn ich die CLK Frequenz reduziere, kann ich auch den CPL Wert
> reduzieren?!

Nein. Der Pixeltakt hat nichts mit den Pixeln pro Zeile zu tun. Die 
Eingangsstufe des Displays ist erstmal rein digital und leitet über 
durch DataEnable und HSync synchronisierte Zähler aus dem Pixeltakt alle 
weiteren internen Signale an. Das Display möchte im Idealfall 1056 Takte 
pro Zeile. Dies kann man durch Verlängern oder Verkürzen der Porch Werte 
etwas verändern. Um wie viel, dazu schweigt das Datenblatt leider und 
aus Erfahrung kann ich sagen, dass sich hier jedes Display anders 
verhält.

> DataEnable:
> Frequenz: 37,8 kHz
> Duty Cyle: 75,7%

Bei welchem CPL Wert?
Der scheint also zu passen.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit den Werten im ersten Post. Also CPL = 799.

Bei keinem der Werte Stand das Bild still. Es zittern die stellen wo die 
Stellen wo Linien doppelt sind bzw. unterbrochen sind.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann hab ich dich in die falsche Richtung gelotst, da die 
Beschreibung im Datenblatt falsch ist...

Liegt das HSync Signal in dem Bereich von DataEnable der Low ist?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn DE low ist, geht auch HSync auf low.

Gelb = Data Enabled
Grün = Hsync

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anhang vergessen.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das grundsätzliche Timing sieht gut aus. Daran dürfte es also nicht 
liegen, das kann man jetzt ausschließen.
Du setzt das IPC Bit, um den Pixeltakt zu invertieren. Passt das?
Das Display übernimmt die Daten mit der fallenden Flanke, du gibst die 
Daten ebenfalls mit der fallenden Flanke aus.
Üblicherweise wählt man die steigende Flanke um den damit verbundenen 
Timingproblemen aus dem Weg zu gehen.
Allerdings hängt das auch davon ab, welchen LVDS Encoder du verwendet 
hast. Wenn der auch die Daten an der fallenden Flanke einliest, ist das 
Bit falsch gesetzt.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es macht keinen Unterschied ob ich das IPC Bit setze oder nicht.

Den SDRAM habe ich geprüft, funktioniert.
SN75LVDS84A habe ich als LVDS Transmitter.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der SN75LVDS84A übernimmt die Daten auch mit der fallenden Flanke, das 
IPC Bit sollte also nicht gesetzt sein. Es führt aber "nur" dazu, dass 
das Bild oder einzelne Pixel ab und zu um einen Pixel hin und her 
tanzen.

Lass mal ein Bild ausgeben, dessen linkes viertel rot, dann 1/4 blau, 
dann grün und dann weiß ist und mach davon mal ein Foto.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hast du denn bisher in den Framebuffer geschrieben, d.h. wie sollte 
das Bild eigentlich aussehen? Jede zehnte Zeile weiß, der Rest schwarz? 
Mach mal ein Muster mit vertikalen Linien.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da war wohl einer schneller ... ;-)

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Testweise schreibe ich so in den Framebuffer:
for (x = 0; x < 800; x++){
    for(y = 0; y < 600; y++){
      for (c = 0; c < 3; c++){
        if((x%10==0))
          *(unsigned char*)((unsigned int)&SDRAM_BASE_ADDR+z) = 0xff;
        z+=1;
      }
    }
  }
Das müsste doch alle 10 Zeile eine Linie ergeben, oder denke ich falsch?
for (x = 0; x < 800; x++){
    for(y = 0; y < 600; y++){
      for (c = 0; c < 3; c++){
        if((x%10==0)|(y%10==0))
          *(unsigned char*)((unsigned int)&SDRAM_BASE_ADDR+z) = 0xff;
        z+=1;
      }
    }
  }
Müsste dann eine Karomuster geben?

Stimmt das so, bevor ich mit falschem Ansatz weitermache?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Omega G. schrieb:
> Testweise schreibe ich so in den Framebuffer:
>
> if((x%10==0))
> 
> Das müsste doch alle 10 Zeile eine Linie ergeben, oder denke ich falsch?

Nein, jede 10. Spalte wen du x abfragst. Aber kann es sein, dass du die 
x und y Schleifen vertauscht hast? Im Speicher folgt eine Zeile nach der 
anderen und nicht eine Spalte nach der anderen.


>
>         if((x%10==0)|(y%10==0))
> 
> Müsste dann eine Karomuster geben?

Du wolltest vermutlich anstelle von dem | ein || schreiben (auch wenn es 
hier auf das gleich hinausläuft)?

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso schreibst du nicht gleich 32 Bit?
for (y=0;y<600;y++)
{
  for (x=0;x<800;x++)
  {
    if (((x%10)==0) || ((y%10)==0))
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
    z++;
  }
}

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
for (x = 0; x < 800; x++){
    for(y = 0; y < 600; y++){
      for (c = 0; c < 3; c++){
        if((x%10==0)||(y%10==0))
          *(unsigned char*)((unsigned int)&SDRAM_BASE_ADDR+z) = 0xff;
        z+=1;
      }
    }
  }
Ergibt das Bild im Anhang.
for (x = 0; x < 800; x++){
    for(y = 0; y < 600; y++){
      //for (c = 0; c < 3; c++){
        if((x%10==0)||(y%10==0))
          *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
        z+=1;
      //}
  
Ergibt nur ein Bild in der oberen Hälfte?!

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du mußt in der äußeren Schleife y inkrementieren und in der inneren x!

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry:
z+=4;

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sieht so aus.

Genau wie wenn ich x und y vertausche.

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
z+=4 sieht so aus.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Poste mal den Code der dieses Bild erzeugt hat.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
  for (y=0;y<600;y++)
{
  for (x=0;x<800;x++)
  {
    if (((x%10)==0) || ((y%10)==0))
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
    z+=4;
  }
}

erzeugt dieses Bild. Das Muster im Hintergrund sollten auch Linien 
sein...

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wie sieht der Code jetzt komplett aus?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier mal das aus:
  for (y=0;y<600;y++)
{
  for (x=0;x<800;x++)
  {
    if (x<200)
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ff0000;
    else if (x<400)
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x0000ff00;
    else if (x<600)
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x000000ff;
    else
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
    z+=4;
  }
}

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der Code von Benedikt erzeugt dieses Bild.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr seltsam.
Ich sehe weder rot noch grün, nur blau.
Ersetze mal die letze Zeile in der weiß ausgegeben wird durch rot. Wenn 
dann die Streifen rot/blau sind, dann stammen immerhin alle Daten aus 
dem Speicher und nicht sonst wo her.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unsigned int TestFunc(void)
{
unsigned int x;
unsigned int y;
unsigned int z;
z=0;
for (y=0;y<600;y++)
{
  for (x=0;x<800;x++)
  {
    if (x<200)
      if (*(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) != 0x00ff0000)
      {
        return z;
      }
    else if (x<400)
      if (*(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) != 0x0000ff00)
      {
        return z;
      }
    else if (x<600)
      if (*(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) != 0x000000ff)
      {
        return z;
      }
    else
      if (*(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) != 0x00ffffff)
      {
        return z;
      }
    z+=4;
  }
}
return 0xffffffff;
}

Ruf mal diese Testfunktion nach dem beschreiben des Framebuffers auf und 
werte den Rückgabewert aus.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da bekomme ich 0 zurück. Sieht aus als ob doch was mit dem RAM nicht 
stimmt. Zumindest im 32 Bit Betrieb.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Testroutine:
for (i = 0; i < 0x100000; i+=sizeof(unsigned int))
  {
    *(unsigned int*)((unsigned int)&SDRAM_BASE_ADDR+i) = i;
  }

  for (i = 0; i < 0x100000; i+=sizeof(unsigned int))
  {
  temp = *(unsigned int*)((unsigned int)&SDRAM_BASE_ADDR+i);
    if (temp != i)
    {
    sendint8_uart0(i);
    send_uart0(' ');
    sendint8_uart0(temp);
    send_uart0(10);
    send_uart0(13);
    }
  }
  return(1);

gibt 1 zurück und sendet nichts über UART.

Ich bin momentan ratlos.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeig mal bitte deine SDRAM Initialisierung.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PCONP|=(1<<11);
  //  EnableRAMPower();
  PINSEL5 = 0x55010115;
  PINMODE5 = 0xAAaaaaaA;
  PINSEL6 = 0x55555555;
  PINMODE6 = 0xAAAAAAAA;
  PINSEL7 = 0x55555555;
  PINMODE7 = 0xAAAAAAAA;
  PINSEL8 = 0x05555555;
  PINMODE8 = 0x0AAAAAAA;
  PINSEL9 = (1 << 18);
  PINMODE9 = 0x80000;
 
  

  EMC_CTRL=1; // enable EMC
  EMC_DYN_RD_CFG=1;//Configures the dynamic memory read strategy(Command delayed strategy)
  EMC_DYN_RASCAS0|=0x303;
  EMC_DYN_RP= 4;//RP
  EMC_DYN_RAS = 8;//RAS
  EMC_DYN_SREX = 5;// SREX, XSR not found
  EMC_DYN_APR = 2; //APR not found
  EMC_DYN_DAL = 5; //DAL, APW not found
  EMC_DYN_WR = 3; //WR, DPL, RWL, RDL
  EMC_DYN_RC = 11;//
  EMC_DYN_RFC = 11; //rfc rc
  EMC_DYN_XSR = 5;//txsr not found
  EMC_DYN_RRD = 3;//RRD
  EMC_DYN_MRD = 8;//RAS
  EMC_DYN_CFG0 = (1<<14)|(3<<9)|(1<<8)|(1<<12);//8,9,14
  
  for(i = 0; i < 100; i++);
  EMC_DYN_CTRL = 0x0183; // NOP
  for(i = 0; i < 100; i++);
  EMC_DYN_CTRL=0x101; 
  EMC_DYN_RFSH = 1;
  for(i = 0; i < 100; i++);
  EMC_DYN_RFSH = 19;

  EMC_DYN_CTRL=0x81; 
  i = (*(volatile int*)(0xA0000000 | (0x32<<12)));
  EMC_DYN_CTRL = 0;

  EMC_DYN_CFG0|=0x80000;  

Ich habe einen K4S643232E-TC70 drinnen. Ich hoffe nächste Woche bekomme 
ich 128 Mbit RAMs.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin noch nicht durch, aber das ist mir schon mal aufgefallen:

Du schreibst:
EMC_DYN_CFG0 = (1<<14)|(3<<9)|(1<<8)|(1<<12);//8,9,14
Wenn man diesen Wert im User Manual anschaut, dann müsstest du einen 
"256 MB (8Mx32), 4 banks, row length = 13, column length = 8" 
angeschlossen haben.

Du hast aber lt. deiner Bauteilbezeichnung einen "64 MB (2Mx32), 4 
banks, row length = 11, column length = 8" -> 0x5300
Also müsste deine Zeile lauten:
EMC_DYN_CFG0 = (1<<14)|(1<<12)|(1<<9)|(2<<7);
Du kannst die (1<<12) auch weglassen, dann wird das Ding als High 
Performance angesprochen.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das funktioniert nur, wenn ich Bit 12 setze. Genau wie meine Funktion.

Noch Ideen, ansonsten warte ich auf das vorgesehene RAM.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du Bit 12 nicht setzt, dann kommt garnichts?
Hast du mal die Zeile so, wie ich sie oben geschrieben habe ausprobiert?
Verändert sich das Bild, oder das Ergebnis des Speichertest dadurch?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich Bit 12 nicht setze, dann habe ich nur Speicherfehler mit deiner 
Zeile.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn du es setzt?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann habe ich laut meiner Testroutine keine Speicherfehler. Aber die 
Funktion zum Balken aufs Display schreiben und lesen, bringt immer noch 
0 zurück, also Fehler an Adresse 0.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Versuch:
Laß die Zeile
EMC_DYN_CFG0 = (1<<14)|(1<<12)|(1<<9)|(2<<7);

und ändere weiter unten die Zeile so ab:
i = (*(volatile int*)(0xA0000000 | (0x32<<10)));
(aus 12 mach 10)

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
wenn ich mich auch mal einmischen darf:
Ich glaube, deine SDRAM-Initialisierung ist nicht ganz korrekt.
Ich muss nachher schnell meinen eigenen Code raussuchen, dann kann ich 
dir den mal hier rein stellen.
Sicher - die Timings wirst du anpassen müssen (stimmen wirklich alle?), 
aber ich glaube meine Initialisierung sieht auch sonst noch ein bisschen 
anders aus....

Andere Frage:
hast du zum Vereinfachen des Layouts Adressleitungen oder Datenleitungen 
getauscht, verdraht, oder sonst wie anders angeschlossen?
DQMx-Signale richtig herum? DQM0 => D0..7, DQM1 => D8..15 usw.
Wie sieht der Clock aus - am Pin vom LPC sowie am Pins vom SDRAM? -> 
mach doch mal schnell ein Bild.
Wenn es dir was bringt, mache ich nachher auch schnell ein paar Bilder 
von meinen Signalen, dann kannst du vergleichen, ob bei dir irgendwas 
anders aussieht.

Ach ja: sind CLK und CKE mindestens gleich lang oder länger als die 
Adressleitungen? Ich meine mal gelesen zu haben, dass das evtl. noch 
eine Rolle spielen /könnte.

Und, noch etwas OT:
Hast du das MCI oder Ethernet schon ausprobieren können? ;-)

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unverändert:
Mit Bit 12: RAM test ok, Bild fehlerhaft
Ohne Bit 12: RAM test fehlerhaft, Bild fehlerhaft

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, was mir auffält:
weiter oben hast du gesagt, du hättest keine Speicherfehler mehr, wenn 
du Bit 12 setzt.
Das würde dann ja bedeuten, dass dein SDRAM korrekt funktioniert. 
Dummerwise macht dann aber deine "Balken-aufs-Display-zeichen-Funktion" 
einen Fehler - welche Funktion ist das nochmal?

Stack richtig initialisiert? (gross genug, an einer gültigen 
Speicheradresse).

Ich finde, wenn dein Ram-Test fehlerfrei durch läuft, dann kann der 
Fehler auch nicht beim SDRAM liegen - das lässt sich ja dann 
offensichtlich beschreiben und lesen....

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CLK und CKE sind länger als die Adressleitungen. DQM0 vom LPC geht an 
DQMOUT0 vom Controller etc.

Kann es sein, dass es daran liegt, das mein Layout für 128 Mbit augelegt 
ist, aber 64 Mbit drinnen sind? (BA0 und BA1 vom RAM an A12 und A13 
geplant, allerdings ist A11 bei mir ja unbelegt...)

Würde es vielleicht was bringen die Serienwiderstände von 22 auf 33 Ohm 
zu vergrößern? (Mein Prototyp hat scheinbar 33 Ohm gehabt, hier sind 22 
Ohm drinnen)

Ich mache gleich Aufnahmen von den CKE und CLK Signalen.

Ethernet und MCI habe ich noch nicht getestet.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
 for (y=0;y<600;y++)
{
  for (x=0;x<800;x++)
  {
    if (x<200)
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ff0000;
    else if (x<400)
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x0000ff00;
    else if (x<600)
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x000000ff;
    else
      *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
    z+=4;
  }
}
erzeugt Balken
unsigned int TestFunc(void)
{
unsigned int x;
unsigned int y;
unsigned int z;
z=0;
for (y=0;y<600;y++)
{
  for (x=0;x<800;x++)
  {
    if (x<200)
      if (*(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) != 0x00ff0000)
      {
        return z;
      }
    else if (x<400)
      if (*(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) != 0x0000ff00)
      {
        return z;
      }
    else if (x<600)
      if (*(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) != 0x000000ff)
      {
        return z;
      }
    else
      if (*(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) != 0x00ffffff)
      {
        return z;
      }
    z+=4;
  }
}
return 0xffffffff;
}
Prüft diese Balken

Autor: Tobias Plüss (hubertus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Kann es sein, dass es daran liegt, das mein Layout für 128 Mbit augelegt
> ist, aber 64 Mbit drinnen sind? (BA0 und BA1 vom RAM an A12 und A13
> geplant, allerdings ist A11 bei mir ja unbelegt...)


Uuuh, das könnte der Grund sein - BAx sollten an A13 und A14 liegen, so 
viel ich weiss....
Schau dir vielleich mal angehängtes PDF an; ab Seite 32 wirds für dich 
interessant ;-)

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine auf BA0 muß A13 und auf BA1 muß A14, auch für den 128Mbit 
SDRAM.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich meine auf BA0 muß A13 und auf BA1 muß A14, auch für den 128Mbit
> SDRAM.

Sach ich doch ;-)

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja klar, ich war aber (wieder einmal) zu langsam!

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)

Ich glaube, es geht aus dem Datenblatt des 2478 auch nicht wirklich klar 
hervor, dass A13 und A14 mit BA0 und BA1 verbunden werden müssen. Dass 
ich das bei meinem ersten Testboard so gemacht hatte, hat sich auch eher 
durch Zufall ergeben, weil mein RAM genau 13 Adressleitungen (A0 bis 
A12) braucht - dann kommen A13 und 14 automatisch auf BAx.
Aber wie gesagt - auch wenn das RAM nur 10 Adressen oder so braucht - 
trotzdem muss man A13 und 14 mit BA verbinden (oder Kai? Das steht 
jedenfalls irgendwo in oben angehängtem Dokument).

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, das ist schlecht. Schade, das es keiner gesehen hat im Schaltplan 
von mir.

Gibt es dafür irgendeine Möglichkeit das Problem softwaremäßig zu lösen?

Oder muss ich Drähte ziehen?

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Omega,
tja ich habe mir deinen Schaltplan leider gar nicht angeschaut, sonst 
hätte ich es gesehen :-( Ich war mehr am Layout interessiert....

Aber gut, deine Leiterplatte lässt sich trotzdem noch retten - mittels 
dünnen Wrapdraht und einem Skalpell.
Softwaremässig wirst du die Bankselects nicht verbieben können, die sind 
m.W. hart verdrahtet (im LPC2478 innen drin).
Aber die fehlerhaften beiden Leiterbahnen sind ja schnell abgetrennt und 
mittels einer kleinen Drahtbrücke an den richtigen Pins angeschlossen...
Mir ist bei meinem ersten Testboard was ähnliches passiert - Ich hatte 
an den DQMx-Pins einen Layoutfehler; DQM0 und 1 waren vertauscht. 
Wrapdraht hilft da wunder; jetzt läuft das Board (auch mit 72 MHz).

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darf BA0 und 1 vertauscht werden?

Dann müsste ich nur eine Leitung legen^^

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau. Die meisten Beispielschaltungen verwenden SDRAMs, die A0-A12, BA0 
und BA1 verwenden.
Das User Manual zum LPC2478 schweigt sich zur Belegung leider aus.

Richtig ist aber mit ziemlicher Sicherheit, dass BA0 immer an A13 und 
BA1 an A14 kommt. Die oberen Adressleitungen (A12, A11) werden bei 
fehlenden Bedarf freigelassen.
Tobias hat also vollkommen recht.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich bin nicht DER SDRAM-Experte, aber wenn man sich diese 
Datenblätter so anguckt: das sieht so aus, als wären in einem Chip 
eigentlich 4 identische SDRAMs drinnen (eben die 4 Banks), die von BA0 
und BA1 ausgewählt werden. Von daher würde ich sagen: könnte gehen! 
Allerdings bin ich mir nicht 100%ig sicher; evtl. könnte es ja Ärger mit 
dem Refresh geben? Da weiss Kai sicher noch besser Bescheid.

Übrigens, @Kai:
Was ist los mit unserem Projekt? ;-)

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wüsste jetzt nicht, was dagegen sprechen würde. -> Ausprobieren!

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tobias: Das alte Problem: Zu viel zu tun und zu wenig Zeit, aber ich 
melde mich in den nächsten Tagen wieder!

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So. A14 geht auf BA0 und A13 auf BA1.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und, funktioniert's?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unverändert?! Aber ich habe noch eine Idee, Stichwort PINSEL.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, wart mal. Ich suche jetzt meinen Notebook hervor; dort drauf habe 
ich einen funktionierenden Code, den ich nachher hier hochladen werde.
Moment...

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, sieht schon besser aus. Bit 12 ist nun Wurscht.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt, die relevanten Stellen in der Initialisierung des SDRAM sind 
diese beiden Zeilen:
EMC_DYN_CFG0 = (1<<14)|(1<<12)|(1<<9)|(2<<7);
...
i = (*(volatile int*)(0xA0000000 | (0x32<<10)));

Die Initialisierung des Displays haben wir ja schon durch. ;-)

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, mein SDRAM-Code sieht wie folgt aus:
/*===========================================================================*/
void fLowLevelInit(void)
/*-----------------------------------------------------------------------------
  Function:
  performs a low-level hardware initialization function; called directly
  after reset.
  in:  none
  out: none
=============================================================================*/
{
#ifdef DEBUG
  MEMMAP = 2; /* map interrupt vectors to internal RAM (debug in RAM) */
#else
  MEMMAP = 1; /* no remapping of interrupt vectors */
#endif

  /* initialize the pll */
#if CLOCKSOURCE == CLK_MAIN /* check if the main osc is the clk source */
  SCS |= OSCRANGE; /* first select an oscillator range */
  SCS |= OSCEN; /* then enable the main oscillator */
  while(!(SCS & OSCSTAT)); /* wait until the main osc is ready */
#endif
  PLLCON &= ~PLLC; /* disconnect the pll */
  PLLFEED = 0xAA;
  PLLFEED = 0x55;
  PLLCON &= ~PLLE; /* disable the pll */
  PLLFEED = 0xAA;
  PLLFEED = 0x55;
  CCLKCFG = 0; /* disable cpu clock divider to speed up pll configuration */
  CLKSRCSEL = CLOCKSOURCE; /* select the desired clock source */

  /* set the N and M values */
  PLLCFG = (((NSEL - 1) & 0xFF) << 16) | ((MSEL - 1) & 0xFFFF);
  PLLFEED = 0xAA;
  PLLFEED = 0x55;
  PLLCON |= PLLE; /* enable the pll */
  PLLFEED = 0xAA;
  PLLFEED = 0x55;
  CCLKCFG = CCLK_DIV; /* select cpu clock divider */
  while(!(PLLSTAT & PLOCK)); /* wait for the pll to lock */
  PLLCON |= PLLC; /* connect the pll */
  PLLFEED = 0xAA;
  PLLFEED = 0x55;

  VICIntEnClr = 0xFFFFFFFF; /* initialize the vic by clearing any interrupts */
  VICAddress = 0; /* reset vic address register */
  VICIntSelect = 0; /* switch all interrupts to irq mode */

  MAMTIM = 3; /* initialize the memory accelerator module */
  MAMCR = 2;

#ifdef HI_SPEED_GPIO
  SCS |= BIT_00; /* select all gpios as fio instead of legacy */
#else
  SCS &= ~BIT_00; /* select legacy io ports */
#endif

  tDWord dwDelay;
  PCONP |= BIT_11; /* enable power for the emc */
  PINSEL5 = 0x55010115; /* enable emc pins */
  PINMODE5 = 0xAA02022A;
  PINSEL6 = 0x55555555;
  PINMODE6 = 0xAAAAAAAA;
  PINSEL7 = 0x55555555;
  PINMODE7 = 0xAAAAAAAA;
  PINSEL8 = 0x15555555;
  PINMODE8 = 0x2AAAAAAA;
  PINSEL9 = (1 << 18);
  PINMODE9 = 0x80000;
  EMCControl = 1; /* setup the emc and the timings for sdram */
  EMCDynamicReadConfig = 1; /* select command delayed read strategy */
  EMCDynamicRasCas0 = 0x203; /* cas latency 2, ras latency 3 */
  EMCDynamictRP = 3; /* setup all the other timings for the sdram */
  EMCDynamictRAS = 5; /* see the sdram calculation sheet */
  EMCDynamictSREX = 2;
  EMCDynamictAPR = 2;
  EMCDynamictDAL = 5;
  EMCDynamictWR = 3;
  EMCDynamictRC = 6;
  EMCDynamictRFC = 6;
  EMCDynamictXSR = 2;
  EMCDynamictRRD = 3;
  EMCDynamictMRD = 3;
  EMCDynamicConfig0 = (BIT_14 | BIT_10 | BIT_09 | BIT_07);
  for(dwDelay = 0; dwDelay < 100; dwDelay++);
  EMCDynamicControl = 0x181; /* issue nop command */
  for(dwDelay = 0; dwDelay < 100; dwDelay++);
  EMCDynamicControl = 0x101; /* issue precharge all command */
  EMCDynamicRefresh = 1; /* start the refresh timer */
  for(dwDelay = 0; dwDelay < 100; dwDelay++);
  EMCDynamicRefresh = 19; /* set up the refresh timer */
  EMCDynamicControl = 0x081; /* issue sdram mode command */
  dwDelay = (*(tpDWord)(0xA0000000 | (0x22 << 13))); /* burst length 4, 2 cas */
  EMCDynamicControl = BIT_01; /* clkout runs continuously */
  EMCDynamicConfig0 |= 0x80000; /* enable the buffer */
} /* end fLowLevelInit */

Die Timings musst du halt noch anpassen, aber wenigstens kannst du 
vielleicht mal schauen, in welcher Reihenfolge ich was wo initialisiert 
habe, und was nicht.
die Pinsel und Pinmode sind jedenfalls für 32 Bit externes SDRAM 
konfiguriert, passen so also zu deinem Design.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorsicht! Tobias verwendet einen anderen SDRAM!
Die Zeilen
EMCDynamicConfig0 = (BIT_14 | BIT_10 | BIT_09 | BIT_07);
...
dwDelay = (*(tpDWord)(0xA0000000 | (0x22 << 13))); /* burst length 4, 2 cas */
treffen für dich nicht zu!

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, sorry das hatte ich natürlich vergessen zu erwähnen!

Aber vielleicht bringt der Code ja trotzdem was, ich selber bin 
jedenfalls immer froh wenn ich eine Vorlage habe...

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
void init_ram_high(void){
  int i;

  PCONP|=(1<<11);
  //  EnableRAMPower();
  PINSEL5 = 0x55010115;
  PINMODE5 = 0xAAaaaaaA;
  PINSEL6 = 0x55555555;
  PINMODE6 = 0xAAAAAAAA;
  PINSEL7 = 0x55555555;
  PINMODE7 = 0xAAAAAAAA;
  PINSEL8 = 0x15555555;
  PINMODE8 = 0x1AAAAAAA;
  PINSEL9 = (1 << 18);
  PINMODE9 = 0x80000;
 
  

  EMC_CTRL=1; // enable EMC
  EMC_DYN_RD_CFG=1;//Configures the dynamic memory read strategy(Command delayed strategy)
  EMC_DYN_RASCAS0|=0x303;
  EMC_DYN_RP= 4;//RP
  EMC_DYN_RAS = 8;//RAS
  EMC_DYN_SREX = 5;// SREX, XSR not found
  EMC_DYN_APR = 2; //APR not found
  EMC_DYN_DAL = 5; //DAL, APW not found
  EMC_DYN_WR = 3; //WR, DPL, RWL, RDL
  EMC_DYN_RC = 11;//
  EMC_DYN_RFC = 11; //rfc rc
  EMC_DYN_XSR = 5;//txsr not found
  EMC_DYN_RRD = 3;//RRD
  EMC_DYN_MRD = 8;//RAS
  EMC_DYN_CFG0 = (1<<14)|(1<<9)|(2<<7);//8,9,14
  
  for(i = 0; i < 100; i++);
  EMC_DYN_CTRL = 0x0181; // NOP
  for(i = 0; i < 100; i++);
  EMC_DYN_CTRL=0x101; 
  EMC_DYN_RFSH = 1;
  for(i = 0; i < 100; i++);
  EMC_DYN_RFSH = 19;

  EMC_DYN_CTRL=0x81; 
  i = (*(volatile int*)(0xA0000000 | (0x32<<12)));
  EMC_DYN_CTRL = 1;

  EMC_DYN_CFG0|=0x80000;  
}

Sieht jemand noch Fehler? So läuft mein RAM test durch, allerdings die 
Balkensache sieht immernoch unverändert aus.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der RAM-Test so durch läuft, dann wird das RAM ja wohl jetzt 
funktionieren. Dann kann es nur noch an der Initialisierung des LCDs 
liegen...

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte man denken...

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Etwa nicht? :-)
Ich meine - wenn das SDRAM sich beschreiben und lesen lässt, dann sollte 
der LCD-Controller das ja auch tun können.
Leider habe ich mich noch nicht mit dem LCD-Controller der 2478 befasst, 
aber wenn du deinen Code mal postest, kann dir vielleicht Kai helfen. 
Vom LCD habe ich leider nur wenig Ahnung :-(

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht das Bild auf dem TFT immer noch exakt so aus wie vorher, jetzt da 
der SDRAM geht?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja -.-

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du vielleicht ein anderes Display, das du mal testen könntest? Wenn 
das RAM funktioniert und der LCD-Controller richtig initialisiert ist, 
kanns nur noch am Display liegen. Oder gar am LVDS-Chip? Bist du dir 
sicher, dass dieser LVDS75... oder wie der auch schon wieder hiess, 
kompatibel ist zum LPC2478 LCD Controller?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht das Bild aus, wenn du z.B. komplett alles rot machst?
Ist dann alles einheitlich gefärbt?
Da der Controller vermutlich nur während des aktiven Bildbereiches Daten 
ausgibt, müssten die Datenleitungen für rot dann ein ähnliches Signal 
beinhalten wie DataEnable.

Tobias Plüss schrieb:
> Oder gar am LVDS-Chip? Bist du dir
> sicher, dass dieser LVDS75... oder wie der auch schon wieder hiess,
> kompatibel ist zum LPC2478 LCD Controller?

Der LVDS Encoder ist nichts anderes wie ein parallel -> Seriell Wandler, 
und der Dekoder macht das ganze umgekehrt. Das einzige was inkompatibel 
sein kann, ist die Flanke, aber deren Auswirkungen sind gering.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0x00ff0000 = Alles Blau
0x0000ff00 = Alles Grün
0x000000ff = Alles Rot

Also als Leuchtfläche Funktioniert es. Ich hoffe der LVDS Transmitter 
läuft mit dem Controller.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, also - als Leuchtfläche geht schon mal. Rein aus Neugier: Kannst du 
mit

0xffff00,
0xff00ff,
0x00ffff

alles Cyan, Magenta und Gelb färben? (wird sicher gehen; wie gesagt 
reine Neugier).

Dann: sind die Flächen "schön", oder sehen sie auch so zerhackstückelt 
aus wie die Bilder oben? Was passiert, wenn du abwechslungsweise z.B. 
0x0000ff und 0xff0000 in das RAM schreibst? dann müsste das Bild ja eine 
Art Schachbrettmuster geben, wo jeder Pixel abwechslungsweise rot und 
dann wieder blau ist.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, die Farben passen schonmal.
Daraus kann man schließen, dass LVDS mäßig alles passt, ansonsten würde 
nämlich garnichts funktionieren, da die Farbdaten sowie Timingsignale 
gemultiplexed übertragen werden.

Jetzt versuch mal herauszufinden was passiert wenn du z.B. nur den 
halben Speicher beschreibst usw.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, das zittern ist weg!
void TFT_init(){
//Set up 24 bit mode etc.

PINSEL0 |= 0x00055500;
PINSEL3 |= 0x05555500;
PINSEL4 |= 0x050FFFFF;
PINSEL9 |= 0x0A000000;
PINSEL11 |= 0x0000000F;

PCONP |= (1<<20);  //Enable LCD controller
LCD_CTRL = 0x2A;  //TFT 24 Bit
LCD_CFG = 1;    //Set divider CCLK/2 = 40 MHz 
LCD_POL =  (0x01 << 26)|(799 << 16)|(0x00 << 14)|(0x00 << 13)|(0x01 << 12)|(0x01 << 11);  
//Bypass pixel clock divider | 800 clocks per line | invert: panel clock, h clock, v clock
LCD_TIMH =  (87 << 24)|(39 << 16)|(127 << 8 )|(49 << 2);  
//Back porch = 88 clk | Front porch = 40 clk | Pulse with = 128 clk | Size = (49 + 1)*16 = 800 px
LCD_TIMV = (22 << 24)|(1 << 16)|(3 << 10)|(599);      
//Back porch = 22 px | Front porch = 1 px | Pulse with = 3 px | Size = 600 px
LCD_UPBASE = LCD_VRAM_BASE_ADDR & 0xfffffff8;
LCD_LPBASE = LCD_VRAM_BASE_ADDR & 0xfffffff8;
LCD_CTRL |= 1|(1<<11);    //Enable LCD

}

Wenn ich in
 for (y=0;y<600;y++)
 {
   for (x=0;x<800;x++)
   {
     if ((x<200)==0)
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x0000ff00;
     else if (x<400)
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ff0000;
     else if (x<600)
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x000000ff;
     else
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
     z+=4;
   }
 }

y nur bis 100 laufen lasse ich nur ein Teil des TFTs gefüllt, der Rest 
schwarz.
for (y=0;y<600;y++)
 {
   for (x=0;x<800;x++)
   {
     if (((x==y)))
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
     z+=4;
   }
 }

Sollte doch einen schräge Linie anzeigen. Es zeigt mir verteilte weiße 
Punkte an, aber Standbild!

Sieht aus, als ob ich den Framebuffer entweder in x oder y 
vergrößern/verkleinern müsste.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das Farbmuster mit den 4 Farbbereichen ok? Also siehst du alle 4 
Farben so wie es sein sollte? Falls ja, passt die Bildbreite, sonst 
wären die Zeilen versetzt.

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Balkencode so abgeändert:
for (y=0;y<600;y++)
 {
   for (x=0;x<800;x++)
   {
     if (x<200)
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x0000ff00;
     else if ((x<400)&&(x>200))
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ff0000;
     else if ((x<600)&&(x>400))
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x000000ff;
     else
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
     z+=4;
   }
 }

Bild 94 zeigt das Bild in Betrieb, Bild 93, wenn man das Display nicht 
mehr ansteuert.
Es sind alle Farben vorhanden.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anstelle der 200 Pixel breiten Farbbalken erscheinen also diese nur 
wenige Pixel breiten, verzerrten Streifen?

Bist du sicher, dass das SDRAM Timing passt? Eventuell funktioniert z.B. 
der Burst Read nicht, der eventuell für den LCD Controller verwendet 
wird?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Exakt.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach sieht das so aus, als ob da irgendwie Zeilen und 
Spalten irgendwie vertauscht wären - wenn du den ganzen SDRAM ja mit 
0xff0000 füllst ist ja alles schön blau, bei 0x0000ff ist alles rot - 
soweit okay. Aber das sagt nichts darüber aus, wie die einzelnen 32 Bit 
Wörter im Memory zu den Pixeln korrelieren. Vielleicht ist da ja 
irgendwas vertauscht?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit der TestFunc weiter oben kann ich nachweisen, das die Daten im RAM 
stimmen. Es muss also entweder an der Init des Controllers liegen, dem 
Aufbau des Framebuffers oder der Palette des Controllers, der ich 
momentan nicht ein Byte würdige.

Vielleicht kann mir jemand sagen, wie wichtig die Palette ist? Ich werde 
an der Stelle aus dem Datenblatt echt nicht schlau.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Palette ist üblicherweise für den 24bit Modus uninteressant, da man 
hier schon alle Farben darstellen kann. Siehe dazu Abschnitt 8. TFT 
panels: Nur bei 8bpp und kleiner wird die Palette verwendet.

Wie sieht das Bild aus, wenn du im obigen Code anstelle von den 4 
vertikalen Balken 4 horizontale anzeigst?

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
 for (y=0;y<600;y++)
 {
   for (x=0;x<400;x++)
   {
     if (y<150)
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x0000ff00;
     else if ((y<300)&&(y>150))
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ff0000;
     else if ((y<450)&&(y>300))
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x000000ff;
     else if (y>450)
       *(unsigned int *)((unsigned int )&SDRAM_BASE_ADDR+z) = 0x00ffffff;
     z+=4;
   }
 }


Ich habe etwas experimentiert: Mit dem obigen Code erhalte ich dieses 
Bild.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass die Daten im RAM stimmen, bezweifelt ja niemand. Was ich eigentlich 
meinte mit meinem vorherigen Post war eher folgendes:
Logischerweise Gehört das erste 32 Bit Wort im LCD-Puffer zum Pixel Nr. 
0, also links oben. Zu welchem Pixel gehört dann das nächste Wort? Wenn 
diese Zuordnung Speicherinhalt -> Pixel nicht stimmt, kommt Murks auf 
dem Display raus.
Deshalb meinte ich auch: Füll mal deinen Speicher abwechslungsweise mit 
0 und 0xffffff (als Beispiel). Was kommt dann raus? Oder füll den ganzen 
Speicher mit 0, und nur das aller erste Wort mit 0xffffff.
So würde ich jedenfalls versuchen, das zu debuggen - immer nur Schritt 
für Schritt. Wenn du gleich auf einen Schlag das mit den 4 farbigen 
Bereichen machen willst, birgt das doch zu viele Fehlerquellen. Irgend 
ein Fehler im Code, Alignment nicht richtig im SDRAM, was weiss ich.
Ach ja, was mir grade einfällt, was du noch versuchen könntest:
Füll den Speicher derart, dass das erste Wort 0 ist, und jedes weitere 
dann um eins inkrementiert wird. Dann müsste irgend ein 
"Regenbogenmuster" auf dem Display erscheinen (meine ich).

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sieht für mich so aus, als wenn er mit schnellen Wechseln der 
Bilddaten Probleme hätte. Für lange Zeit die gleichen Daten sind dagegen 
absolut problemlos.
Bau mal einen Code ein, der einfach sinnlos in einen anderen 
Speicherbereich 0en schreibt und lass diesen Code ununterbrochen laufen, 
so dass die Daten auf dem Datenbus vom SDRAM mit 0en unterbrochen 
werden.
Ich hatte man ein ähnliches Phänomen was sich am Ende als Timingproblem 
beim SDRAM rausstellte.

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbst auf 24 MHz CPU und RAM Takt sieht es unverändert aus. Auch wenn 
ich zwischendurch immer auf irgendwas zugreife.

Möglicherweise stimmen meine RAM Timings nicht ganz, oder dieser RAM ist 
einfach defekt. (Auf Grund von Ungeduldigikeit von einer Grafikkarte 
ausgelötet, von der ich nicht weiß ob die noch funktionierte!)

Was mich aber wundert: warum läuft der Speichertest durch ohne Fehler?!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um sicherzugehen, dass der RAM Test wirklich funktioniert (auch wenn es 
sehr unwahrscheinlich ist dass er es nicht tut): Veränder doch mal 
irgendein Byte nach dem Beschreiben. Dann müsste der RAM Test den Fehler 
anzeigen.

Irgendwo müssen die Daten durcheinander kommen.
Da die horizontalen Balken passen, kann man das Display sowie dessen 
Ansteuerung als Fehler ausschließen. Auch scheinen zumindest ab und zu 
die Daten zu passen.

Kannst du mal prüfen ob eventuell ein FIFO Underflow eintritt? Bei 80MHz 
SDRAM Takt und 40MHz Displaytakt dürfte das eigentlich nicht vorkommen, 
aber man weiß ja nie...

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also RAM Test, ich habe einfach mal ein Byte nach dem beschreiben 
verändert. Wurde korrekt gemeldet.

Ja, die Daten müssen irgendwo durcheinander kommen, und ich bin etwas 
ratlos wo das passiert.

Display timings:
Dann dürfte sich ja nichts verändern wenn man nicht im Framebuffer 
rumpfuscht. Ich habe ja ein Standbild. Also kann man den LVDS 
Hochfrequenzteil auch ausschließen.

SDRAM: RAM Test funktioniert, da werden die Daten auch schnell 
hintereinander beschrieben, und das erfolgreich.

Wie prüfe ich auf einen FIFO underflow?

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach mal einen Test:
1. Alles schwarz füllen, nur einen einzigen Punkt weiß.
2. Einen zweiten Punkt links neben dem ersten abwechselnd (vielleich 1 
Hz) in weiß und schwarz zeichnen, den Rest so lassen.

Frage: Verändert sich die Position des ersten Punktes auf dem 
Bildschirm?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Omega G. schrieb:
> Also RAM Test, ich habe einfach mal ein Byte nach dem beschreiben
> verändert. Wurde korrekt gemeldet.

Also kann man den auch ausschließen.
Der Fehler muss also irgendwo im Bereich des internen LCD Controllers 
liegen.

> Display timings:
> Dann dürfte sich ja nichts verändern wenn man nicht im Framebuffer
> rumpfuscht. Ich habe ja ein Standbild. Also kann man den LVDS
> Hochfrequenzteil auch ausschließen.

Ja.
Was du mal probieren könntest: Den Pixeltakt halbieren, den Rest lassen 
(also den CPU und SDRAM Takt).
Ist dann zwar außerhalb der Specs, aber es sollte dennoch gehen.

> Wie prüfe ich auf einen FIFO underflow?

Laut Datenblatt wird dann im LCD_INTRAW Register ein Bit gesetzt.

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Funktioniert!

Woran lag's:
Benedikt hatte (wie so oft in Sachen Displays) die zündende Idee: 
Display Clock zu hoch. Scheinbar kam das SDRAM einfach nicht hinterher.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wunderbar!
Das wundert mich aber dennoch, denn eigentlich läuft der SDRAM doppelt 
so schnell wie die Daten benötigt werden. Allerdings hatte ich mit einem 
LCD Controller schon ähnliche Erfahrungen gemacht, daher auch die Frage 
nach der zusätzlichen Schleife die Daten ins SDRAM schreibt um das 
zusätzlich zu belasten.
Die SDRAM Controller scheinen also nicht perfekt zu sein.
Als Ausweg könntest du entweder das SDRAM Timing verbessern indem du ein 
schnelleres SDRAM verwendest (und somit z.B. eine geringere CAS Latency 
einstellen kannst, ob das allerdings ausreicht ist zu bezweifeln), oder 
aber indem du nur 16bit Farbtiefe verwendest.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau! Habe grad mal den LCD-BusLoadCalculator durchlaufen lassen: Bei 
60Hz sind's 153% Buslast auf dem Speicher!

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich ist eh ein anderes RAM vorgesehen, dann optimiere ich das ein 
wenig, mal sehen was machbar ist! Vielen Dank für die Hilfe!!!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Offtopic:
Hat jemand ein Erklärung dafür, warum gerade mal 85MByte/s Datenrate zur 
Verfügung stehen, obwohl das SDRAM eigentlich 80MHz*32bit=320MByte/s 
könnte?
Klar, es gibt einen Overhead bei der Ansteuerung, aber die erklärt 
keinen Unterschied von fast Faktor 4.

Und vor allem: Warum sich bei einem 16bit SDRAM die Datenrate gerade mal 
auf 67,4Mbyte/s reduziert und nicht halbiert. Das sind gerade mal 26% 
Unterschied in der Datenrate.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yeah, cool dass es jetzt funktioniert!
Geht denn nun auch wirklich alles zuverlässig?

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es scheint soweit zuverlässig zu sein. Ich habe ein Weile eine Plasma 
Animation laufen lassen. Ruckt zwar ziemlich, aber macht viele 
Speicheroperationen.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läuft das TFT immer noch mit 20MHz?
Für den richtigen Betrieb würde ich auch 16bpp runtergehen, denn 20MHz 
ist weit außerhalb der Specs. Ob das langfristig negative Auswirkungen 
auf das TFT hat, kann man daher nicht sagen.

Ich denke ich habe die Ursache für den langsamen SDRAM gefunden:
Der LPC liest dem BusLoadCalculator nach immer 16Bytes auf einmal. Dazu 
benötigt er bei einem 32bit SDRAM 15 Takte! Der SDRAM Controller ist 
also dumm, da er nichtmal eine bereits geöffnete Bank berücksichtigt 
wenn ich das richtig sehe. Das hätte man deutlich besser machen können. 
Das würde die Zeit pro Burst auf 11 Takte reduzieren wenn die Bank 
gleich ist, was rund 25% mehr Datenrate bedeuten würde.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es hätte auch schon viel gebracht, wenn er mit 32bit SDRAMs 8er Bursts 
unterstützen und somit gleich 32 Bytes lesen würde.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein 8er Burst wurde 19 Takte dauern, dafür aber die Datenrate 
verdoppeln, macht 134,7MByte/s statt 85,3MByte/s. Rund 58% 
Geschwindigkeitssteigerung.
Das noch kombiniert mit dem intelligenteren Controller (da es ein LCD 
Controller ist, kann man wohl davon ausgehen dass viele Daten 
sequentiell gelesen werden so dass dies Sinn macht, und so aufwendig ist 
das auch nicht) wären das 32Bytes in 15 Takten, also 170,7MByte/s, eine 
Steigerung um satte 100%.
Anscheinend haben die das Problem erkannt, denn der LPC32x0 liest immer 
64Bytes auf einmal, was immerhin 80% der theoretisch maximalen Datenrate 
erlaubt (ok, der spielt auch in einer anderen Liga, das ist klar). Der 
LPC2478 kommt gerade mal auf schlappe 21,3%.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der LCD-Controller im LPC2478 und in den LPC32x0 ist ja der gleiche und 
stammt ursprünglich von Sharps LH7-Controllern, die NXP aufgekauft hat.
Das Problem ist halt der Speichercontroller, der in den LPC32x0 halt ein 
anderer und besserer ist.

Wenn es beim LPC2478 etwas knapp wird mit der Bandbreite kann man den 
AHB von Round-Robin auf eine Priorisierung einzelner Peripheriemodule 
umstellen. So kann man, auch wenn die Last des Speichercontrollers gegen 
100% geht, das Display trotzdem noch flüssig laufen lassen. Näheres im 
Usermanual: AHBCFG1 und AHBCFG2.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kai,

du schnell eine Frage wegen der SDRAMs!
Ich hatta ja seinerzeit, bei der Inbetriebnahme meines Testboards, etwas 
Ärger mit denen, du hast mir dann freundlicherweise einen kleinen 
Initialisierungscode gebastelt, den ich bis heute so benutze (weil er 
absolut einwandfrei funktioniert ;-).
Mittlerweile verstehe ich den mehr oder weniger, nur eines ist mir heute 
aufgefallen, und zwar die Zeile:

dwDelay = (*(tpDWord)(0xA0000000 | (0x22 << 13))); /* burst length 4, 2 
cas */


Was bewirkt diese? rein vom Kommentar her würde ich mal drauf tippen, 
dass sie das Mode Register initialisiert. Aber das kann nicht sein, da 
das Mode Register nur 14 Bits umfasst, und wenn die Konstante 0x22 um 13 
nach links geschoben wird, wäre diese ja grösser als das Mode 
Register... Ausserdem sind die Bits zum Einstellen der Burstlänge und 
der CAS-Latency die Bits 0..2 und 3..4 (oder irgendwie so). Warum muss 
da noch um 13 geschoben werden?
Ich benutze übrigens immernoch meine ominösen IS42S16160B.

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Mode-Register wird ja über die Adressleitung geschrieben, d.h. diese 
Zeile ist ja ein (spezieller) Lesezugriff auf eine bestimmte Adresse. 
Jetzt ist es aber so, dass die Adressierung bei einem SDRAM nicht in 
einem Schritt passiert, sondern in drei (Row, Column und dann in der 
Seite). Schau mal in das Dokument, das du oben verlinkt hast.
Das knifflige an den SDRAMS und deren Initialisierung ist dann halt den 
Shift-Wert (in den Fall 13) richtig zu bestimmen, dass die Bits auch an 
der richtigen Stelle im Mode-Register landen.
Burst-Length steht in Bit[2:0], CAS-Latency in Bit[6:4].
Mit der 13 werden nun diese Bits so verschoben, dass sie in der 
Row-Adresse stehen. Wenn ich mich richtig erinnere: Column-Breite + 
Bus-Breite (1 für 16 Bit; 2 für 32 Bit) + 2 (für Bänke) -> 9+2+2 = 13.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Kai,
danke! Das erklärt so einiges.
Noch eine Frage:
Es gibt die beiden Register EMCDynamictXSR und EMCDynamictSREX. Diese 
beiden Zeiten findet man in den wenigsten SDRAM-Datenblättern; ausserdem 
lautet im User's Manual die Beschreibung zu beiden Registern "Dynamic 
Memory Self-Refresh exit time", sie bewirken also (rein von der 
Beschreibung her) dasselbe. Ist das ein Fehler im Manual, oder sind 
diese Register wirklich redundant? Wenn ja - was ergibt das für einen 
Sinn?
Und - was tun, wenn man tXSR bzw. tSREX nicht findet in dem Datenblatt 
des gewünschten SDRAM?
Und - wie kritisch ist das Timing? Ich habe mir ein Excel-Sheet gebaut, 
bei welchem man die Timings des SDRAM-Chips direkt aus dem Datenblatt 
eingeben kann, sowie die CPU-Frequenz, und die Werte aller Register 
werden dann selbsträndig berechnet.
So komme ich auf leicht andere Werte, als die, die du mir damals 
angegeben hast (teilweise bekomme ich mehr, teilweise weniger). Die 
ganze Sache scheint mir eine nicht ganz so exakte Wissenschaft zu sein; 
kannst du dazu auch was sagen?
Ich könnte mir ausserdem gut vorstellen, dass bei falsch oder ungünstig 
eingestellten Timings das SDRAM zwar funktioniert, aber eben nicht 
zuverlässig bzw. dass die Burst-Zugriffe oder ähnliches nicht korrekt 
funktioniert. Wie kann man dies einigermassen zuverlässig testen?
Ich habe jetzt, da ich die Timings von meinem SDRAM zu optimieren 
versucht habe, einen Memory Test implementiert, der jedes einzelne Bit 
des SDRAMs testet. Der Test läuft jetzt schon 15 Minuten ohne Fehler in 
einer Endlosschleife durch, aber Burstzugriffe oder dergleichen werden 
so natürlich nicht wirklich getestet....

Falls übrigens bei jemandem Interesse bestehen sollte, kann ich mein 
Excel-Sheet hier hochladen. Es berechnet die Werte für den Refresh 
Timer, sowie die anderen Timing-Register; das einzige was man machen 
muss ist, die Daten aus dem SDRAM-DB ins Excelsheet zu übertragen und 
CPU-Frequenz angeben. Der nächste Schritt ist dann die automatische 
Generierung eines Initialisierungscodes.... ;-)

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darf ich das Excel Sheet haben? Ich habe meine Werte von Hand 
ausgerechnet. Bzw. teils von anderen Implementationen übernommen weil 
Angaben fehlten.

Übrigens läuft das Display momentan mit 16 MHz. Mehr geht noch nicht. 
(Ich habe seit gestern Abend keine Zeit mehr gehabt was zu machen.) Ich 
würde gerne versuchen den RAM schneller laufen zu lassen (Also an den 
Timings drehen) und dann versuchen auf 20 MHz zu gehen.

Autor: Tobias Plüss (hubertus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Na klar kannst du es haben - siehe Anhang :-)
Ich habe jetzt meine Timings gemäss dem Sheet berechnet, und das SDRAM 
scheint zuverlässig zu laufen. Von daher denke ich sollten die 
Berechnungen stimmen.
Eine weiteres Sheet für den Static Memory Controller werde ich auch noch 
machen (der Static Memory Controller lässt sich wunderbar missbrauchen, 
um am externen Bus irgendwelche Memory Mapped IOs anzuschliessen; ich 
habe mal einen Haufen Flipflops ['HC273] angeschlossen, das ergibt 
wunderbare 8 Bit Ports....).
Bei Interesse lade ich das dann auch noch hoch.

Allerdings hat auch das Excel Sheet einen Mangel:
Wenn gewisse Angaben im Datenblatt fehlen (z.B. tSREX), dann können 
diese damit natürlich auch nicht berechnet werden :-( da habe ich auch 
teils ausprobieren müssen oder einfach geraten.

Übrigens: wer Freude an solchen Excel Sheets hat....
ich hab einige hier, allerdings nicht nur zu LPC24xx Controllern, 
sondern auch zur Schaltnetzteilberechnung.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,
mal noch eine Frage wegen des SDRAM-Interface.
Ich habe festgestellt, dass der CLKOUT recht verschliffene Flanken hat, 
wenn er mehrere SDRAMs treiben soll.
Auf meinem Testboard sieht er schon fast sinusförmig aus! Natürlich, es 
funktioniert, ist aber hässlich. Ich habe jetzt aus ein paar alten 
Mainboards Clock-Treiber ausgelötet - sogenannte "Zero Delay Clock 
Buffers". Es handelt sich dabei um TI CDCVF2505PWR - ein Clock-Input, 4 
Clock Outputs.
Diesen möchte ich jetzt einsetzen als Clock Buffer; er schafft diese 
Frequenz natürlich locker (geht bis 200 MHz).
In den Kennlinien kann man jedoch erkennen, dass der Duty Cycle nicht 
50% ist - etwas weniger; daher frage ich mich: kann man den dennoch als 
Clock Buffer benutzen für den LPC2468? Denn ich möchte noch einen 
kleinen FPGA mit dem Clock versorgen und noch weitere ICs, deshalb denke 
ich ist ein Clock Buffer schon nötig.
Was meint ihr dazu?

@Omega:
noch eine kleine Frage; kann man deinen Source Code zum Ethernet mal 
kriegen? Im Thread Beitrag "Re: NXP verschenkt ARM-Chips" 
schreibst du ja, dass das bei dir bereits läuft.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias Plüss schrieb:
> In den Kennlinien kann man jedoch erkennen, dass der Duty Cycle nicht
> 50% ist - etwas weniger; daher frage ich mich: kann man den dennoch als
> Clock Buffer benutzen für den LPC2468?

Solange die steigende Flanke an der selben Stelle bleibt geht das (und 
genau das macht das IC). Ob 48 oder 50% Duty macht keinen wirklichen 
Unterschied.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Benedikt,
cool danke!
Ja ich glaube, die steigende Flanke sollte wirklich an der selben Stelle 
bleiben. Der Skeq ist im ps-Bereich... Sonst wäre ja die Bezeichnung 
"Zero Delay Buffer" nicht korrekt ;-)

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Ethernet Treiber macht momentan noch nicht viel, da mir unter der 
Woche auf Grund von Studium die Zeit doch etwas knapp ist. Aber trotzdem 
hier meinen Anfang
int MAC_init(){
  int tout,i;
  PCONP |= (1<<30);
  PINSEL2 |= 0x50150105;
  PINSEL3 |= 0x5;
  
  //Reset MAC
  MAC_MAC1 = 0x00000100 | 0x000002009 | 0x00000400 | 0x00000800 | 0x00004000 | 0x00008000;
  MAC_COMMAND = (1<<3) | (1<<4) | (1<<5);
  
  
  for (tout = 0; tout<10000; tout++);
  MAC_MAC1 = 0x00000002;
  MAC_MAC2 = 0x00000010 | 0x00000020;
  MAC_MAXF = 1522;
  MAC_CLRT = 0x0000370F;
  MAC_IPGR = 0x00000012;
  
  /* Enable Reduced MII interface. */
  MAC_COMMAND = 0x00000200 | 0x00000040;
  
  write_PHY (0, 0x8000); //send reset command
  while(read_PHY(0) & 0x8000); //wait until reset is complete
  
  MAC_MCFG = (0x06 << 2) | 0x00008000;  
  for ( i = 0; i < 0x40; i++ );
  MAC_MCFG &= (~0x00008000);  /* Clear the reset */
  MAC_MCMD = 0;

  write_PHY (0, 0x1100); //Setup auto-negotiation, full duplex
  
  //tout = 0;
  //while(!(read_PHY(1) & 4) & (tout < 500000))  //check and wait until ethernet is up
  //  tout++;
  //  
  MAC_SA0 = (MYMAC_1 << 8) | MYMAC_2;
  MAC_SA1 = (MYMAC_3 << 8) | MYMAC_4;
  MAC_SA2 = (MYMAC_5 << 8) | MYMAC_6;
  
  MAC_RXDESCRIPTOR = 0x7FE00000;
  
  return read_PHY(1);  
}
Ich werde sämtliche Treiber die ich schreibe auch auf meine Homepage 
stellen. Dort protokolliere ich auch gefundene Fehler und zeige wie sie 
umgeht. Die 50 MHz Clock von der PHY sehen übrigens sehr schön aus. 
Soweit ich das mit einem 200 MHz Oszilloskop beurteilen kann.

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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