ILI9341 langsam Verbesserungsvorschläge?

[Sascha712 (Gast)]

Hallo, bzw. Guten Morgen :)

Hab grad das ILI9341 Display mit 320x240Pixeln zum anzeigen vorn Farben 
bekommen :) Hab mir die Libs von anderen angesehn und mir vorrerst das 
zusammengestellt und angepasst, was ich haben wollte.

Nun läuft mein Atmega8 grad mit 4 Mhz, weil bei 8 Mhz das flashen 
manchmal Probleme macht, wieso auch immer. Nun, der Bildaufbau, dauert 
relativ lange. etwa 1:25 pro Bild!

Gut, das nen Atmega8 mit 4 Mhz nicht so der Burner ist, ist 
verständlich. Aber das ist doch sehr sehr lange.

Liegt das vielleicht an dem Code? Habt ihr Verbesserungsvorschläge?

#include <avr/io.h>
#include <util/delay.h>

#define DDR_SPI DDRB
#define DD_MOSI DDB3
#define DD_SCK DDB5
#define DDR_CS_RST_DC DDRB
#define DD_CS DDB0
#define DD_RST DDB1 
#define DD_DC DDB2
#define PORT_CS_RST_DC PORTB
#define CS PB0
#define RST PB1
#define DC PB2

//Basic Colors
#define RED    0xf800
#define GREEN  0x07e0
#define BLUE  0x001f
#define BLACK  0x0000
#define YELLOW  0xffe0
#define WHITE  0xffff

//Other Colors
#define CYAN    0x07ff  
#define BRIGHT_RED  0xf810  
#define GRAY1    0x8410  
#define GRAY2    0x4208 

void SPI_Init(void)
{
  // Set MOSI and SCK output, all others input 
  DDR_SPI |= (1<<DD_MOSI)|(1<<DD_SCK);
  DDR_CS_RST_DC |= (1<<DD_CS)|(1<<DD_RST)|(1<<DD_DC);
  // Enable SPI, Master, set clock rate fck/16 
  SPCR |= (1<<SPE)|(1<<MSTR)|(1<<SPI2X);
}
void SPI_Transmit_Data(int Data)
{
  PORT_CS_RST_DC &= ~(1<<CS);
  // Start transmission 
  SPDR = Data;
  // Wait for transmission complete 
  while(!(SPSR & (1<<SPIF)))
  {
    ;
  }
  PORT_CS_RST_DC |= (1<<CS);
}
void SPI_Transmit_Command(int Command)
{
  PORT_CS_RST_DC &= ~(1<<CS);
  PORT_CS_RST_DC &= ~(1<<DC);
  // Start transmission 
  SPDR = Command;
  // Wait for transmission complete 
  while(!(SPSR & (1<<SPIF)))
  {
    ;
  }
  PORT_CS_RST_DC |= (1<<DC);
  PORT_CS_RST_DC |= (1<<CS);
}

void LCD_Init(void)
{
  PORT_CS_RST_DC |= (1<<RST);
  _delay_ms(10);
  PORT_CS_RST_DC &= ~(1<<RST);
  _delay_ms(10);
  PORT_CS_RST_DC |= (1<<RST);
  PORT_CS_RST_DC &= ~(1<<CS);
  _delay_ms(10);
  
  SPI_Transmit_Command(0xCB);
  SPI_Transmit_Data(0x39);
  SPI_Transmit_Data(0x2C);
  SPI_Transmit_Data(0x00);
  SPI_Transmit_Data(0x34);
  SPI_Transmit_Data(0x02);
  
  SPI_Transmit_Command(0xCF);
  SPI_Transmit_Data(0x00);
  SPI_Transmit_Data(0XC1);
  SPI_Transmit_Data(0X30);

  SPI_Transmit_Command(0xE8);
  SPI_Transmit_Data(0x85);
  SPI_Transmit_Data(0x00);
  SPI_Transmit_Data(0x78);

  SPI_Transmit_Command(0xEA);
  SPI_Transmit_Data(0x00);
  SPI_Transmit_Data(0x00);

  SPI_Transmit_Command(0xED);
  SPI_Transmit_Data(0x64);
  SPI_Transmit_Data(0x03);
  SPI_Transmit_Data(0X12);
  SPI_Transmit_Data(0X81);

  SPI_Transmit_Command(0xF7);
  SPI_Transmit_Data(0x20);

  SPI_Transmit_Command(0xC0);  //Power control
  SPI_Transmit_Data(0x23);      //VRH[5:0]

  SPI_Transmit_Command(0xC1);  //Power control
  SPI_Transmit_Data(0x10);      //SAP[2:0];BT[3:0]

  SPI_Transmit_Command(0xC5);  //VCM control
  SPI_Transmit_Data(0x3e);
  SPI_Transmit_Data(0x28);

  SPI_Transmit_Command(0xC7);    //VCM control2
  SPI_Transmit_Data(0x86);

  SPI_Transmit_Command(0x36);    // Memory Access Control
  SPI_Transmit_Data(0x48); //C8

  SPI_Transmit_Command(0x3A);
  SPI_Transmit_Data(0x55);

  SPI_Transmit_Command(0xB1);
  SPI_Transmit_Data(0x00);
  SPI_Transmit_Data(0x18);

  SPI_Transmit_Command(0xB6);    // Display Function Control
  SPI_Transmit_Data(0x08);
  SPI_Transmit_Data(0x82);
  SPI_Transmit_Data(0x27);

  SPI_Transmit_Command(0xF2);    // 3Gamma Function Disable
  SPI_Transmit_Data(0x00);

  SPI_Transmit_Command(0x26);    //Gamma curve selected
  SPI_Transmit_Data(0x01);

  SPI_Transmit_Command(0xE0);    //Set Gamma
  SPI_Transmit_Data(0x0F);
  SPI_Transmit_Data(0x31);
  SPI_Transmit_Data(0x2B);
  SPI_Transmit_Data(0x0C);
  SPI_Transmit_Data(0x0E);
  SPI_Transmit_Data(0x08);
  SPI_Transmit_Data(0x4E);
  SPI_Transmit_Data(0xF1);
  SPI_Transmit_Data(0x37);
  SPI_Transmit_Data(0x07);
  SPI_Transmit_Data(0x10);
  SPI_Transmit_Data(0x03);
  SPI_Transmit_Data(0x0E);
  SPI_Transmit_Data(0x09);
  SPI_Transmit_Data(0x00);

  SPI_Transmit_Command(0XE1);    //Set Gamma
  SPI_Transmit_Data(0x00);
  SPI_Transmit_Data(0x0E);
  SPI_Transmit_Data(0x14);
  SPI_Transmit_Data(0x03);
  SPI_Transmit_Data(0x11);
  SPI_Transmit_Data(0x07);
  SPI_Transmit_Data(0x31);
  SPI_Transmit_Data(0xC1);
  SPI_Transmit_Data(0x48);
  SPI_Transmit_Data(0x08);
  SPI_Transmit_Data(0x0F);
  SPI_Transmit_Data(0x0C);
  SPI_Transmit_Data(0x31);
  SPI_Transmit_Data(0x36);
  SPI_Transmit_Data(0x0F);

  SPI_Transmit_Command(0x11);    //Exit Sleep
  _delay_ms(130);

  SPI_Transmit_Command(0x29);    //Display on
  SPI_Transmit_Command(0x2C);

}

void SetAddress (unsigned x1, unsigned y1, unsigned x2, unsigned y2)
{
  SPI_Transmit_Command(0x2a);
  SPI_Transmit_Data(x1>>8);
  SPI_Transmit_Data(x1);
  SPI_Transmit_Data(x2>>8);
  SPI_Transmit_Data(x2);

  SPI_Transmit_Command(0x2b);
  SPI_Transmit_Data(y1>>8);
  SPI_Transmit_Data(y1);
  SPI_Transmit_Data(y2>>8);
  SPI_Transmit_Data(y2);

  SPI_Transmit_Command(0x2C);
}
void SPI_Transmit_Data16(int data)
{
    int data1 = data>>8;
    int data2 = data&0xff;
    PORT_CS_RST_DC |= (1<<DC);
    PORT_CS_RST_DC &= ~(1<<CS);
    SPI_Transmit_Data(data1);
    SPI_Transmit_Data(data2);
    PORT_CS_RST_DC |= (1<<CS);
}
void SetCol(int StartCol,int EndCol)
{
    SPI_Transmit_Command(0x2A);                                                    
    SPI_Transmit_Data16(StartCol);
    SPI_Transmit_Data16(EndCol);
}
void SetPage(int StartPage,int EndPage)
{
    SPI_Transmit_Command(0x2B);                                                    
    SPI_Transmit_Data16(StartPage);
    SPI_Transmit_Data16(EndPage);
}
void SetXY(int poX,int poY)
{
    SetCol(poX, poX);
    SetPage(poY, poY);
    SPI_Transmit_Command(0x2c);
}
void SetPixel(int poX, int poY,int color)
{
    SetXY(poX, poY);
    SPI_Transmit_Data16(color);
}
void FillScreen(int color)
{
  int i;
  for(i=0;i<=239;i++)          //i->240
  {
    int j;
    for(j=0;j<=319;j++)        //j->320
    {
      SetPixel(i,j,color);
    }
  }
}



int main(void)
{
  SPI_Init();
  LCD_Init();

  while(1)
  {
    FillScreen(RED);
    FillScreen(GREEN);
    FillScreen(BLUE);
    FillScreen(YELLOW);
    FillScreen(CYAN);
    FillScreen(BRIGHT_RED);
    


  }


}

Mit freundlichem Gruß Sascha

[Takao K. (takao_k)]

set clock rate fck/16

Kein Wunder.

2. 320x200 color/ATMega8 4MHz - passt nicht, zu langsam.
Das waer wohl der richtige chip fuer Nokia 5110.

[Sascha712 (Gast)]

Da hab ich das Kommentar nicht geändert.
Ist auf fck/2

Ja, ist ja auch nur um das Prinzip zu verstehen. Mir war ja von 
vornherein klar, das das fürn Atmega8 zuviel wird :)

[Takao K. (takao_k)]

Es gibt da schon Moeglichkeiten.

Da diese controller die X Addresse automatisch erhoehen,
muss sie nicht jedesmal neu gesetzt werden, und die Y Addresse auch 
nicht.

Am besten ist es, wenn du eine Funktion verwendest die 16 Pixel X 
ausgibt,
kannst du dann auch die Unterfunktionsaufrufe sparen.

[Sascha712 (Gast)]

void FillScreen(int color)
{
  int i;
  SetXY(0, 0);
  for(i=0;i<76800;i++)  //320*240=76800
  {
    SPI_Transmit_Data16(color);
  }
}

scheint nicht zu funktionieren.

[Takao K. (takao_k)]

ILI9341 Datenblatt?

[Takao K. (takao_k)]

Seite 114. Sollte es aber. Was passiert denn?
http://www.newhavendisplay.com/app_notes/ILI9341.pdf

[Sascha712 (Gast)]

Nur der erste Pixel auf Position 0, 0 wurde verändert.

[Takao K. (takao_k)]

Schau dir mal CASET and PASET an.
Als 2. Parameter musst du hier den max. Wert angeben, also 319 und 239.

Ist in den sog. "libs" durchgehend falsch.

[Sascha712 (Gast)]

wenn ich SetXY(0, 0); auskommentiere, dann funktionierts.

Wenn aber bei der for schleife als abfrage i größer als ~25000 sein 
soll, dann beschreibt er das ganze display aber führt die restlichen 
befehle wie linien zeichnen nicht aus.

[Takao K. (takao_k)]

Geht als int nicht, musst du unsigned long verwenden, langsam auf 8 bit 
controller. Oder teil es halt auf so dass du nur 8bit variablen brauchst 
(unsigned char), sogar int ist auf 8bit chips viel langsamer.

CASET und RASET muessen schon korrekt gesetzt werden.

[Sascha712 (Gast)]

void FillScreen(int color)
{
  int i;
  SetXY(0, 0);
  for(i=0;i<=319;i++)
  {
    int j;
    SetXY(0,i);
    for(j=0;j<=239;j++)
    {  
      SPI_Transmit_Data16(color);
    }
  }
}

So, jetz setze ich ja nur jeweils an den anfang der zeile. bloß anstatt 
die Zeile von links nach rechts zu füllen, nimmt er sich bei jeder Zeile 
nur den ersten Pixel. somit hab ich ne Linie von oben nach unten mit 1 
Pixel breite gezeichnet.

Also irgendwie scheint er unter bestimmten "bedingungen" nicht selber zu 
inkrementieren.

[Takao K. (takao_k)]

void SetXY(int poX,int poY)
{
    SetCol(poX, poX);
    SetPage(poY, poY);
    SPI_Transmit_Command(0x2c);
}

ist halt nicht richtig.
Solltest SetCol in jeder Zeile verwenden, und den 2. Parameter NICHT auf 
0 setzen.
Und dann Setpage mit der neuen Zeilennummer.

Ich hoffer du bekommst es hin, und int ist halt -32767 bis 32768 und ist 
viel langsamer.

Wenn du den 2. Parameter fuer SetCol und Setpage richtig setzt, sollte 
der Kontroller Col und Page automatisch inkrementieren.

[Sascha712 (Gast)]

void FillScreen(int color)
{
  SetCol(0,239);
  SetPage(0,319);
  SPI_Transmit_Command(0x2c);
  SPI_Transmit_Data16(color);

}

so besser? :) Tut sich auch nichts mit. obwohl ich ja laut Datenblatt 
start und endpunkt wählen kann.
So könnte man ja auch prima Rechtecke und so zeichnen.

Was soll ich statt int benutzen?

[Sascha712 (Gast)]

so funktionierts ohne probleme und ist auch viel viel schneller, als 
setzen einzelner bits.

void FillScreen(int color)
{
  SetCol(0,239);
  SetPage(0,319);
  SPI_Transmit_Command(0x2c);  
  int k;
  for(k=0;k<2;k++)
  {
    unsigned int i;
    for(i=0;i<38400;i++)
    {
      SPI_Transmit_Data16(color);
    }
  }
  
}

[leluno (Gast)]

mit einem atmega1284 / 8 mhz ili9320 dauert das Füllen des screens ca. 2 
secunden.

void lcd_clear(uint16_t Color){
  uint32_t index=0;
  lcd_setcursor(0,0);
  lcd_write_index(0x0022);

   cs_lcd_off;
  LCD_Write_Data_Start();
  for( index = 0; index < ((uint32_t)lcd_max_width*lcd_min_width); index++ )  {
    lcd_write_data_only(Color);
  }
  cs_lcd_on;
}

Das kann bei einem ili9341 nicht viel langsamer sein.
Du sparst Zeit, wenn du cs_low/cs_high nicht bei jedem einzelnen Pixel 
setzt.

[Davis (Gast)]

 ...

 while(!(SPSR & (1<<SPIF)))
  {
    ;
  }

 ...

Vergeudete Zeit. Entweder rausnehmen, wenn dein System langsam genug 
ist, oder die Abfrage vor dem Schreiben des Register durchführen.

Wenn möglich bzw. sinnvoll INLINE-Code verwenden.

Schaue dir auch die "PORT_CS" Befehle an, ob die jedes mal gesetzt und 
zurückgesetzt werden müssen. Das sind ganz hübsche Zeiten, die da 
zusammenkommen.

[Jojo S. (Gast)]

Und eine ganz einfache frage: ist die Compiler Optimierung 
eingeschaltet?

[Sascha712 (Gast)]

Bei welcher Frequenz solls zwei sekunden dauern?
Habs aufm Video mit 8MHz laufen.
http://www.youtube.com/watch?v=6NGYy940XCU

[Sascha712 (Gast)]

Compiler optimierung? Noch nie gehört, was ist das?

Ich nutze WinAVR letzte Version

[leluno (Gast)]

Sascha712 schrieb:
> Youtube-Video "Ili9341 @atmega8 8MHz"
so wie in dem video läuft das auf meinem 8Hhz Atmega auch.

[Takao K. (takao_k)]

Davis schrieb:
>

> 
>  ...
> 
>  while(!(SPSR & (1<<SPIF)))
>   {
>     ;
>   }
> 
>  ...
> 
>

>
> Vergeudete Zeit. Entweder rausnehmen, wenn dein System langsam genug
> ist, oder die Abfrage vor dem Schreiben des Register durchführen.
>
> Wenn möglich bzw. sinnvoll INLINE-Code verwenden.
>
> Schaue dir auch die "PORT_CS" Befehle an, ob die jedes mal gesetzt und
> zurückgesetzt werden müssen. Das sind ganz hübsche Zeiten, die da
> zusammenkommen.

ja die koennen alle raus wenn du viele Pixel nacheinander setzen willst.

int kann max. 32768 sein. unsigned int bis zu 65536.
Wenn du int auf 38000 setzt ist dass nicht so gut.

Wie ist denn jetzt die Ausfuerungszeit?
Mit und ohne PORT_CS?

einfach rausnehmen und nur einmal richtig setzen.

[Sascha712 (Gast)]

Bei 1 Mhz Takt:

mit CS Low/High -> 7,73 sekunden
ohne CS dauerhauf auf Low -> 5,27 sekunden

Deutlicher Unterschied. :)

Hat jemand vllt nen Tipp oder nen Link, wie ich ne Funktion aufbaue, die 
Fonts auf mein display bringt? bzw. allgemein Infos dazu? Ich blick um 
ehrlich zu sein nicht durch die "fertigen" Funktionen zum Buchstaben 
setzen nicht durch.

Danke schonmal! :)

[Takao K. (takao_k)]

z.B. hier: 
http://aranna.altervista.org/dragonsnest/microcontroller-projects/glcd-128x64-font-string-print-function/

Wenn du die innere Schleife nur mit unsigned char machst, sollte es 
nochmal ein bisschen schneller sein.

Oder mehr als ein pixel per durchlauf ausgeben, nochmal ein bisschen 
schneler weil es Zeit kostet die Schleife zu verwalten.

Weiss ich nicht ob du den font im FLASH unterbringen kannst.

Kannst ja mal meinen Proportional font versuchen:
http://aranna.altervista.org/dragonsnest/microcontroller-projects/led-dot-matrix-scrolling-message-14x5-source-code/

z.B. auf doppelte groesse strecken...

Brauchste viel weniger FLASH, ist halt nur Grossbuchstaben und Zahlen 
und die auch mit weniger bytes.

[Sascha712 (Gast)]

Also ich hab jetz durch setzen von einzelnen Pixeln zwar zwei Buchstaben 
hinbekommen. Aber das ist ja keine Funktion.

So recht will sich mir auch der Code aus dem Link nicht offenbaren :D

Ich weis, das ich ne Array habe. da liegen dann die Buchstaben quasi auf 
Pixel zerhackt drin.
1 -> bit/pixel gesetzt
0 -> bit/pixel nicht gesetzt
Also eine Schwarz/weiß Information, wenn mans so nimmt.

Mein Problem, das ich nicht weis, wie ich mir aus dieser Array die Bits 
einzeln rauspicke...etc.
Dann muss ich ja nur mit SetXY zum passendem Pixel gehen und setzen oder 
halt auch nicht.

Am besten wäre es wohl, wenn ich auch ne Hintergrundfarbe nutze? weil, 
wenn 0 dann hintergrundfarbe?

[Takao K. (takao_k)]

Die bits kannst du in einer Schleife erhalten:

shl_val=0x01;
for(i=0;i++;i<8)
{if(databyte & shl_val)SETPIXEL(); else CLEARPIXEL();
 shl_val<<=1;
}

Am besten alles einzeln ausschreiben, also keine Schleife verwenden.

Porportional font ist nicht ganz so einfach, da ein pointer array 
verwendet wird. Jeder buchstabe ist mit einer unterschiedlichen Anzahl 
von bytes definiert.

im ersten byte, in den oberen 3 bits, ist diese information kodiert.

Ansonsten sieht 5 pixel font nicht gut aus aber proportional eben schon, 
und es spart Speicher.

Der Ascii code muss auch noch umgerechnet werden (vollstaendige Tabelle 
braucht viel mehr Speicher).

Hab ich mal fuer eine 16F57 laufschrift verwendent (der hat nur 2K 
FLASH).

Fuer die Textausgabe kannst du Setpixel verwenden, ist aber langsam, 
also besser direkt setzen.

[leluno (Gast)]

Sascha712 schrieb:
> Mein Problem, das ich nicht weis, wie ich mir aus dieser Array die Bits
> einzeln rauspicke...etc.

schau dir mal ein einzelnes Zeichen als Bitmuster an:
...
0b111,
0b001,
0b010,
0b100,
0b100,//7
...
Das muss jetzt mit zwei for-Schleifen zeilen- und spaltenweise 
abgelaufen werden.
Für eine 1 zeichnet setPixel dann die frontcolor für eine 0 die 
backcolor

[avus (Gast)]

So langsam finde ich das ILI gar nicht.

Ich hab das ILI9341 vom STM32F429 Discovery runtergelötet und einen Test 
gemacht:
1.) ILI mit SPI, 4wire (IM = 0b1110)
2.) ILI mit 8bit parallel (IM = 0b0000)

Das Ganze von einem ATMega 1284p und 14,7456 MHz bei 3.0V befeuert. 
Identischer Grafiktreiber, der das TFT befüllt. Vollständiges 
Beschreiben, Auslesen von Icons aus dem Flash, Zeichnen simpler Grafik 
(Rechtecke, Kreise), Schreiben von Text (Font aus dem Flash).

Der Grund für den Test ist, daß ich eventuell noch einen MP3-Decoder und 
weitere Peripherie an die SPI anschließen will, und für MP3 einerseits 
und TFT etc. andrerseits gerne getrennte Schnittstellen hätte (auch wenn 
die SPI wahrscheinlich alles schaffen würde).


Abgesehen vom unterschiedlichen Aufsetzen der Ports ist der einzige 
Unterschied, der zur Laufzeit auftritt, die serielle bzw. parallele 
Ansteuerung

#if defined ILI_SPI4
// ########################
// ILI9341, SPI 4 Wire
// ########################
//-------------------------------------------------------------------------------------------------------
void TFT_Write_CMD(uint8_t cmd)
{
  ILI_CTR_PORT &= ~(1<<ILI_CD);  //cmd = 0
  //_delay_us(100);
  ILI_CTR_PORT &= ~(1<<ILI_CS);  //CS = 0
  SPDR = cmd;
  while(!(SPSR & (1 << SPIF)));
  ILI_CTR_PORT |= (1<<ILI_CS);  //CS = 1
}
//-------------------------------------------------------------------------------------------------------
void TFT_Write_DAT(uint8_t data)
{
  ILI_CTR_PORT |= (1<<ILI_CD);  //cmd = 1
  //_delay_us(100);
  ILI_CTR_PORT &= ~(1<<ILI_CS);  //CS = 0
  SPDR = data;
  while(!(SPSR & (1 << SPIF)));
  ILI_CTR_PORT |= (1<<ILI_CS);  //CS = 1
}
#elif defined ILI_PAR8
// ########################
// ILI9341, 8bit parallel
// ########################
//-------------------------------------------------------------------------------------------------------
void TFT_Write_CMD(uint8_t cmd)
{
  ILI_CTR_PORT &= ~(1<<ILI_CD);  //cmd = 0
  //_delay_us(100);
  ILI_CTR_PORT &= ~(1<<ILI_CS);  //CS = 0
  ILI_CTR_PORT &= ~(1<<ILI_WR);  //WR = 0  
  ILI_DATA_PORT = cmd;
  ILI_CTR_PORT |= (1<<ILI_WR);  //WR = 1  
  ILI_CTR_PORT |= (1<<ILI_CS);  //CS = 1
}
//-------------------------------------------------------------------------------------------------------
void TFT_Write_DAT(uint8_t data)
{
  ILI_CTR_PORT |= (1<<ILI_CD);  //cmd = 1
  //_delay_us(100);
  ILI_CTR_PORT &= ~(1<<ILI_CS);  //CS = 0
  ILI_CTR_PORT &= ~(1<<ILI_WR);  //WR = 0
  ILI_DATA_PORT = data;
  ILI_CTR_PORT |= (1<<ILI_WR);  //WR = 1  
  ILI_CTR_PORT |= (1<<ILI_CS);  //CS = 1
}
#endif

Auf das Chipselect könnte man hier oder da verzichten, und klar, man 
könnte auch die beiden Routinen für CMD und DATA zusammenfassen, was 
aber nur Speicher einspart, nicht am Timing.


Fazit:
Alles in allem lohnt es sich kaum bei dem beschriebenen Testablauf - der 
einen halbwegs realistischen Anwendungsfall skizziert - das 
8bit-Interface zu nehmen. Beim Löschen des TFTs sieht man den 
Geschwindigkeitsvorteil am deutlichsten, da geht es mit 8bit (~100ms) 
ca. doppelt so schnell wie mit SPI (~200ms).
Aber sobald Daten aus dem Flash geschaufelt werden, egalisiert sich 
dieser Vorteil ziemlich. Was aber nicht bedeutet, daß der Grafik-Treiber 
schlecht ist ;)

[René K. (cyprius)]

Ich habe das Display mal per SPI an einen 20Mhz-ATmega 328 
angeschlossen, mein Code sieht im Prinzip so aus wie der von avus.

Geschwindigkeitsrekorde kann man da nicht erwarten, zumindest nicht wenn 
der komplette Bildschirm befüllt wird.
Was gut funktioniert ist, einen kleinen Ausschnitt zu definieren und 
dort eine Zeile Text oder ein kleines Bitmap reinzupumpen. Das kann man 
dann auch durchaus als flüssig bezeichnen.
Gebremst wird das aber definitiv durch den ATmega.

Der ILI9341 ist aber prinzpiell schnell genug. Ich habe den mal an den 
TM4C1294 angeschlossen (Tiva C Devboard) und befülle jetzt per DMA aus 
dem Ram, das ist schon richtig schnell. Mit fliegender Verdrahtung komme 
ich z.Z. auf 44Hz, ordentlich geroutet sollten da locker 60Hz und mehr 
drin sein.

[avus (Gast)]

60 Hz und mehr, via DMA, das ist natürlich eine andere Klasse ;)

BTW:
Mit der Geschwindigkeit und AVR muß ich nochmal korrigieren:
Inzwischen möchte ich von dem 8-bit Parallelmodus für das ILI nicht mehr 
abweichen. Momentan habe ich den Atmega1284P noch mit JPG und ID3-tags 
von einer SD-Karte vollgestopft, das Ergebnis ist für heute abend nicht 
berauschend:

Size after:
AVR Memory Usage
----------------
Device: atmega1284p

Program:  107332 bytes (81.9% Full)
(.text + .data + .bootloader)

Data:      23360 bytes (142.6% Full)
(.data + .bss + .noinit)

Abgesehen von dem ähm merkwürdigen Ram-Overhead (den man sicher noch 
reduzieren kann, das Inhaltsverzeichnis frisst halt mit meiner dämlichen 
Methode soviel RAM, und irgendwo steckt da noch ein Wurm. Die 
JPG-Berechnung frißt auf dem STM32F4 weniger RAM) ist es ziemlich klar, 
daß es schwierig wird, allein die SPI Schnittstelle mit SD-Card, Ili und 
den AVR selbst mit allerhand anderen Berechnungen zu belasten.

Um's mal zu konkretisieren: Mit 320x240 Displays und reiner 
Touchpanel-Abfrage macht der AVR ATMega @14~MHz und 3V noch sehr gut 
mit, das läuft sehr flott und macht richtig Spaß.
Aber ein paar komplexere Aufgaben dazu, und dann ist Schluß mit der 
Kiste.

[Frank K. (fchk)]

avus schrieb:

> Mit der Geschwindigkeit und AVR muß ich nochmal korrigieren:
> Inzwischen möchte ich von dem 8-bit Parallelmodus für das ILI nicht mehr
> abweichen.

Die schnellste Möglichkeit, ein solches Display mit einem AVR 
anzusteuern, ist die Verwendung des External Bus Interfaces an einem 
Mega 64/128/... Da werden die Steuerleitungen !CS, !RD, !WR 
hardwaremäßig vom EBI bedient und brauchen keinen Programmcode mehr. Das 
ist dann maximal schnell und von mir auch in kommerziellen Projekten so 
eingesetzt worden.

fchk

[avus (Gast)]

Frank K. schrieb:
> Die schnellste Möglichkeit, ein solches Display mit einem AVR
> anzusteuern, ist die Verwendung des External Bus Interfaces an einem
> Mega 64/128/...
Ja, klar. Und dann hat man auch die Möglichkeit, genügend XMEM 
anzuschließen. Aber man muß halt mehr verdrahten :(

Obwohl der 1284p ja nun stolze 16kB hat, reicht das (mit den von mir 
umgeschriebenen Routinen vom STM32) nicht für JPG -> Projekt ILI+AVR+JPG 
gestorben ;)

[Frank K. (fchk)]

avus schrieb:
> Frank K. schrieb:
>> Die schnellste Möglichkeit, ein solches Display mit einem AVR
>> anzusteuern, ist die Verwendung des External Bus Interfaces an einem
>> Mega 64/128/...
> Ja, klar. Und dann hat man auch die Möglichkeit, genügend XMEM
> anzuschließen. Aber man muß halt mehr verdrahten :(

Bei einem TQFP64 verDRAHTest Du ohnehin nicht mehr. Ein professionell 
gefertigte Leiterplatte, und das Thema ist erledigt.

fchk

[Frank X. (matrixx200x)]

Hi,

ich hole das Thema mal wieder hoch.

Hat jemand da jetzt eine laufen Lib für das Display & ATmegaxx?

Oder ein laufendes Programm?

Würde mich über Antworten oder Lib freuen.

Gruss

Floh

[Gerhard G. (g_g)]

Hallo,

hier hast du eine professionelle Version:

https://github.com/mueschel/lcdlib
Beitrag "Re: Library für EA-DOGM Grafikdisplays inkl. Font-Generator"


verwende die beiden Dateien:

LCD with an ILI9341 driver in 16 Bit color mode using 4-wire SPI

lcd-color-graphic.c
lcd-color-graphic.h


Gruß G.G

[Frank X. (matrixx200x)]

Gerhard vielen dank aber damit bekomme ich das Ding nicht zum laufen.

aber ich habe jetzt was gefunden

http://www.avrfreaks.net/projects/ili9341-library-drive-22-tft-displayderived-adafruit-tft-library-ili9340-type-controller?skey=ILI9341

Läuft super. :-)

jetzt muss ich es nur noch schaffen andere Schrift reinzubekommen.

[Frank X. (matrixx200x)]

hallo an alle,

ich habe da mal eine frage.

Ich definiere in meiner font.h folgendes

 struct FontDescriptor
{
  uint8_t  width;    // width in bits
  uint8_t  height;   // char height in bits
  uint16_t offset;  // offset of char into char array
};
extern const struct FontDescriptor ComicDescriptors[];

d.h.
ich kann mit ComicDescriptors[x],width oder height oder offset abrufen.

Das läuft auch super.

Ich will jetzt aber in einer void Funktion im Main file eine Zuweisung 
machen das

fontDesc = ComicDescriptors ist.

d.h. das ich dann mit fontDesc[x],width oder height oder offset abrufen 
kann.

Hintergrund hierfür ist die Schriften Auswahl.

Kann mir jemand dabei helfen wie ich das hinbekomme. :-)

danke im voraus.

Floh

[Frank X. (matrixx200x)]

Hat sich erledigt habs hin bekommen.. :-))

[Peter (Gast)]

Hallo,
ich bin am verzweifeln... Habe eine Libary gefunden und bekomme sie 
einfach nicht zu laufen.

Belegung ist:

Atmega1284P

MISO  =  PORTB  PIN6
MOSI  =  PORTB  PIN5
SCK  =  PORTB  PIN7
DC  =  PORTB  PIN0
CS  =  PORTB  PIN1
RESET  =  PORTB  PIN2

Jemand ne Idee?

Schonmal Danke

[Jens (Gast)]

Was für Messgeräte hast Du? (Multimeter?, Oszi?)
Als erstes würde ich gucken, ob an den Pins vernünftige Signale 
anliegen.
Was für ein Display verwendest Du? Passt die Initialisierung zu Deinem 
Displaytyp?

Jens

[Peter (Gast)]

Hab mit einem Oszi gemessen. Signale kommen vernüftige raus...

240x320 2.4" SPI TFT LCD Touch Panel Serial Port Module with PBC ILI9341 
5V/3.3V

hab ich bei Ebay bestellt.

[Frank X. (matrixx200x)]

DDRB |=(1<<1)|(1<<2)|(1<<5)|(1<<7);//CS,SS,MOSI,SCK as output(although 
SS will be unused throughout the program)

ss ist falsch ss ist dc


muss so aussehn

  DDRB |=(1<<1)|(1<<0)|(1<<5)|(1<<7);//CS,SS,MOSI,SCK as output(although 
SS will be unused throughout the program)

bei mir sieht das so aus

#define DDR_SPI DDRB
#define DD_CS DDB0    //PB0
#define DD_RST DDB1    //PB1
#define DD_DC DDB4    //PB4
#define DD_MOSI DDB5  //PB5
#define DD_MISO DDB6  //PB6
#define DD_SCK DDB7    //PB7



DDR_SPI  = (1 << DD_RST) | (1 << DD_DC) | (1 << DD_MOSI) | (1 << DD_SCK) 
| (1 << DD_CS) | (0 << DD_MISO);

[Arduinoquäler (Gast)]

Peter schrieb:
> Jemand ne Idee?

Habe keine.

Aber ich habe gerade mal spasseshalber das ganze auf meinem
Mega644 Testboard zum Laufen gebracht, mit folgender
Änderung (bezogen auf meine Konfiguration):

#define controlport PORTC   //  fuer Mega644 Controller Testboard
#define controlddr  DDRC
#define controlpin  PINC

#define rstport     PORTC
#define rstddr      DDRC
#define rstpin      PINC
#define dc          5       //  controlport
#define cs          6       //  controlport
#define rst         7       //  rstport

Ansonste den Code nur etwas aufgehübscht.

Beim LCD muss man aufpasen dass es evtl keine 5V verträgt
Ich habe mir dazu nochmal eine Pufferschaltung gebaut die
5V aushält und nur 3.3V auf die LCD Schnittstelle gibt.

In meinen Anfängen mit dem ILI9341 hab ich mir einmal ein
solches LCD getoastet .....

Hängt aber vom Hersteller ab ......

[M. W. (mw73)]

Guten Morgen,

ich habe den Thread wieder ausgegraben, da ich mich zum ersten Mal an 
das besagte ILI9341 LCD ranmache.

Leider habe ich die oben angeführte Lib bis jetzt noch nicht zum laufen 
bekommen.

http://www.avrfreaks.net/projects/ili9341-library-drive-22-tft-displayderived-adafruit-tft-library-ili9340-type-controller?skey=ILI9341

Getestet habe ich unter Atmel Studio 7 auf einem Mega2560 und auf einem 
Mega8

Hier ist meine Verdrahtung:

CS.........PC1
RST........PC7
D/C........PC0
MOSI.......PC3
SCK........PC5

Im Code ILI9341.h:

#define controlport PORTC   //  fuer Mega2560
#define controlddr  DDRC
#define controlpin  PINC

#define rstport     PORTC
#define rstddr      DDRC
#define rstpin      PINC
#define dc          0       //  controlport
#define cs          1       //  controlport
#define rst         7       //  rstport


Im Code ILI9341.c:

DDRC |=(1<<1)|(1<<0)|(1<<3)|(1<<5);//CS,SS,MOSI,SCK as output(although
SS will be unused throughout the program

Miso wird ja hier wohl nicht benutzt - oder?

Für den Mega8 hab ich alles auf PORTB mit gleicher config.

Für Hilfe wäre ich sehr dankbar.
Der Code ist ansonsten unverändert.

LG Markus

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Hier ist meine Verdrahtung:
>
> CS.........PC1
> RST........PC7
> D/C........PC0
> MOSI.......PC3
> SCK........PC5

Aus meinem Datenblatt kann ich nicht entnehmen dass der Mega2560
ein SPI auf Port C hat. Deshalb dürfte das primär schwierig werden.

Also auch wenn man Sourcen einfach dankend entgegennimmt muss
man ein wenig mitdenken.

Markus W. schrieb:
> Getestet habe ich unter Atmel Studio 7 auf einem Mega2560 und auf einem
> Mega8

[M. W. (mw73)]

Hallo Arduinoquäler,

ach du schande - geb Dir voll recht und hab mir darüber keine Gedanken 
gemacht.

Jetzt überlege ich aber trotzdem, warum es auf dem Mega8 nicht läuft.

.....ich habe aber einen Verdacht und teste den jetzt.

Ich melde mich mit meinen Ergebnissen zurück.

Danke für den Gedankenanstoss

LG
Markus

[Arduinoquäler (Gast)]

void ili9341_hard_init (void)  // init hardware
{
  rstddr = 0xFF;          // output for reset
  rstport |= (1<<rst);    // pull high for normal operation
  controlddr |= (1<<dc);  // D/C as output
}

Dieser Teil ist wohl nicht optimal, denn er (der Schöpfer
dieses Codes) setzt brutal einen gesamten Port auf
Output obwohl er ja nur ein Reset-Bit setzen will.
Kann im Einzelfall schon mal unerwünschte Nebenwirkungen
haben.

[M. W. (mw73)]

Danke für den Hinweis, das werde ich gleich mitändern.


Du hattest ja diesen Code schon am laufen, hast Du damals noch was 
wesentliches geändert?

Köntest Du diesen Code generell empfehlen?

LG
Markus

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Du hattest ja diesen Code schon am laufen, hast Du damals noch was
> wesentliches geändert?

Arduinoquäler schrieb:
> Aber ich habe gerade mal spasseshalber das ganze auf meinem
> Mega644 Testboard zum Laufen gebracht, mit folgender
> Änderung (bezogen auf meine Konfiguration):

Das war alles. Ich wollte ja nur den "Nachweis" erbringen
dass er funktioniert.

Markus W. schrieb:
> Köntest Du diesen Code generell empfehlen?

Kommt darauf an was du erwartest. Er funktioniert ja ganz
vernünftig. Never change a running system.

[M. W. (mw73)]

...funktioniert immer noch nicht?

Mega8, 8mHz interner RC-Osz
Alles auf PortB, wie im orig. Code

Mega8 hat das SPI auf PortB

void ili9341_hard_init (void)  // init hardware
{
  rstddr = 0xFF;          // output for reset
  rstport |= (1<<rst);    // pull high for normal operation
  controlddr |= (1<<dc);  // D/C as output
}

hab ich geändert auf 0x07 wo ja der Reset hängt.

Hättest Du da noch eine Idee?

LG
Markus

[M. W. (mw73)]

...sehr ernüchternd, läuft immer noch nicht.

Welchen Takt hast Du am 644er laufen lassen?

[Arduinoquäler (Gast)]

Markus W. schrieb:
> ...sehr ernüchternd, läuft immer noch nicht.

Poste mal deinen kompletten nichtfunktionierenden Code, ich
teste morgen mal an einem Mega88 ob er funktioniert.
(bin heute nicht mhr im "Labor")

[M. W. (mw73)]

Wow, danke, voll cool
... sitz immer noch dabei, hab aber noch nichts gefunden.

Ich hab den Code mal angehängt.

...und noch einmal die Verdrahtung:

Alles auf PORTB

ILI9341      Mega8
DC           PB0
CS           PB1
MOSI         PB3
MISO         PB4
SCK          PB5
Reset        PB7(XTAL2 ! -> kein externer Quarz)

Mega8
8mHz interner RC-Osz.

[Olli (Gast)]

Wenn ich mir bei so grundlegenden Dingen wie der Verkabelung unsicher 
bin, teste ich die Pins einzeln mit einem Blinky durch:

...
#define set_bit(var, bit)   ((var) |= (1 << (bit)))
#define clear_bit(var, bit) ((var) &= (unsigned)~(1 << (bit)))
#define toggle_bit(var,bit) ((var) ^= (1 << (bit)))
...

int main( void)
{
  set_bit( rstddr, rst);

  while(1)
  {
    toggle_bit( rstport, rst);
    _delay_ms( 500);
  }
}

Je nach vorhandenem Messgerät (Multimeter oder Oszi) passt man sich die 
Blinkfrequenz an.
Dann misst man passenderweise erst am Controllerpin und dann am 
Displaypin, ob alles richtig ist.

Letztens war ich auch partout der Meinung, mein Signal müsse doch auf 
PB2 ausgegeben werden, die Signalleitung war allerdings auf PB3 
verlötet...

[M. W. (mw73)]

Danke Olli für Deinen Beitrag,
ich werde künftig auch solche Techniken anwenden um die Beschaltung
zu testen. Allerdings hab ich die Verkabelung mehrmals überprüft und 
diese stimmt zumindest von der Belegung mal.

Markus

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Ich hab den Code mal angehängt.

Gib mal noch den Ausschnit aus der ILI9341.h an der
bei deinem Mega2560 zutreffen würde.

Ich fange mal mit dem Mega2560 an da ich den Mega88
gerade nicht greifbar habe ...

[Arduinoquäler (Gast)]

Markus W. schrieb:
> ... sitz immer noch dabei, hab aber noch nichts gefunden.

Was macht das Display nach dem Einschalten? Brennen
wenigstens die LEDs für die Hintergrundbeleuchtung?

[M. W. (mw73)]

Die Hintergrundbeleuchtung geht nach dem Einschalten an, und das wars 
dann aber auch.

ili9341.h

#define controlport PORTB
#define controlddr DDRB
#define controlpin PINB
#define rstport PORTB
#define rstddr DDRB
#define rstpin PINB

#define dc 6
#define cs 0
#define rst 7

#define ILI9341_TFTHEIGHT 240 
#define ILI9341_TFTWIDTH 320

Auch beim Mega hätte ich alles auf PORTB verlegt, da ja hier das SPI 
ist.

Wenn es für Dich leichter wäre, hätte ich auch einen Mega 644 oder 1284 
zur Verfügung.

Wie hast Du das damals mit dem 644 gemacht, da Du ja CS,D/C und RST auf 
PORTC gelegt hast aber der 644 SPI auch auf PORTB hat?
Könntest Du mir vielleicht diesen lauffähigen Testcode zur Verfügung 
stellen?

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Wenn es für Dich leichter wäre, hätte ich auch einen Mega 644 oder 1284
> zur Verfügung.

Nur Geduld. Mein Nick ist jetzt Programm. Mega2560 ....

[Arduinoquäler (Gast)]

So jetzt ....

(ich hasse diese Dupont-Steckverbinderei, viel zu fehler-
anfällig, aber für dieses eine Mal, ein Quick Hack ...)

Der "Trick" des Autors ist dass manche Dinge (Bits) im
SPI Treiber hartverdrahtet sind sodass nur genau seine
Konfiguration funktioniert und Änderungen in der Pin-/Port-
Belegung nicht durchgängig korrekt greifen.

Ja ja so sind sie, die "Maker" ....

Ich hab das Ganze mal für den Mega2560 konfiguriert und
damit zum Laufen gebracht.

Nur Geduld, die Sourcen kommen gleich.

[Arduinoquäler (Gast)]

Wichtig bliebe noch zu sagen:

- F_CPU nicht in der Quelldatei definieren sondern
im Projekt.

- Beim Compilieren alle Warnings einschalten und diese
auch beachten und ausmerzen.

Markus W. schrieb:
> ... sitz immer noch dabei, hab aber noch nichts gefunden.

Für den Mega8 sollte es jetzt für dich ein Leichtes sein
das Display selbst in Betrieb zu nehmen.

[M. W. (mw73)]

Wow, voll cool, Danke!!!!!!!
Ich werde es gleich in Betrieb nehmen und melde mich dann nochmals 
zurück.

[M. W. (mw73)]

soooo,
melde mich zurück.

Vielen Vielen Dank noch einmal für Deine Bemühungen.
Ich hab dadurch wieder viel dazu gelernt, hätte das aber alleine nicht
hin bekommen.

In wie fern ist da ein Unterschied, wo ich den CPU-Takt festlege?
Ich hab das bis jetzt immer nur in der main gemacht.

Was ich auf die schnelle jetzt noch nicht geschnallt habe, warum Du in 
der Config die 0 und 1 Abfrage gemacht hast (config für anderen 
controller?) bzw. wo diese abgefragt wird. Ich hätte vermutet, dass man 
bei der init eine 0 oder 1 übergeben muss, je nach controllertyp, dem 
war aber nicht so.

Könntest Du mir das noch kurz erklären.

LG
Markus

[Arduinoquäler (Gast)]

Markus W. schrieb:
> soooo,
> melde mich zurück.

Ja und?

Markus W. schrieb:
> Vielen Vielen Dank noch einmal für Deine Bemühungen.

Du hast nicht geschrieben ob du jetzt in der Lage bist
dein Display anzusteuern.

Markus W. schrieb:
> Könntest Du mir das noch kurz erklären.

Den Kleinkram musst du dir selbst zusammenreimen.
Vielleicht findet sich ein anderer Mitleser für Erklärungen.

[M. W. (mw73)]

Sorry, das Display kann ich jetzt ansteuern und es funktioniert sehr 
gut.
Ich werde es noch auf anderen Controllern testen und darüber hinaus noch 
versuchen mir diverse Unklarheiten zu erarbeiten.

Wie gesagt, recht herzlichen Dank für Deine Hilfe!!!!

LG
Markus

[Arduinoquäler (Gast)]

Hier zu diesem Projekt

Beitrag "Re: ILI9341 langsam Verbesserungsvorschläge?"

noch eine für höhere Geschwindigkeit optimierte Source
des ILI9341 Treibers.

Für ein paar Bytes mehr Code bekommt man eine deutlich
lebhaftere Darstellung.

Besonders das Löschen oder Füllen des ganzen Displays oder
eines Rechtecks funktioniert damit deutlich schneller. Aber
auch bei häufig wechselnder Textdarstellung findet man den
Bildaufbau nicht so träge.

[M. W. (mw73)]

Danke!

Ich freue mich schon aufs Testen.
Obwohl ich sagen muss, im Vergleich zu Textdisplays, mit denen ich bis 
jetzt gearbeitet habe kommt mir das Aktualisieren einzelner Werte 
ziemlich flüssig vor.

... Aja, habs gelesen, die Optimierung bezieht sich auf das ganze 
Display bzw. Rechtecke.

Hast Du die Optimierung jetzt gemacht?

Ich werds heut noch testen und meld mich.

LG
Markus

[M. W. (mw73)]

So jetzt hab ich mal den Mega8 getestet
...läuft nicht - hab auch keinen Plan warum.
Naja, weiter testen

[M. W. (mw73)]

mmm,tja, es will auf dem Mega8 nicht gehen.
Hast Du da noch eine Idee?
Ich hab die Config so gesetzt wie der Maker, der diese
Lib ja auch für den Mega8 geschrieben hat.

Könnte die CPU-Speed zu gering sein mit 8mHz?

meine Config:

DDRB  |= (1<<cs)|(1<<2)|(1<<3)|(1<<5);  //CS,SS,MOSI,SCK as 
output(although SS will be unused throughout the program)

#define dc   0    /*  Data/Command  */
#define cs   1    /*  Chip Select   */
#define rst  7    /*  Reset         */

Naja ich werde noch ein wenig mit dem Mega8 testen und dann steck
ich einen 644 auf

[Arduinoquäler (Gast)]

Markus W. schrieb:
> mmm,tja, es will auf dem Mega8 nicht gehen.
> Hast Du da noch eine Idee?

- Testen ob du eine Minimal-Blinky Applikation funktioniert
- Speziell PB7 testen ob er frei ist (Blinky)
Denn PB7 ist nur frei wenn die Fuses für den Oszillator
richtig gesetzt sind.

oder (warum denn unbedingt PB7 verwenden?)

- Vermeide PB7 indem du CS auf auf SS legst, SS ist ja
eigentlich dafür gedacht.

Wenn Blinky funktioniert, dann also

#define dc   0    /*  PB0 Data/Command       */
#define rst  1    /*  PB1 Reset              */
#define cs   2    /*  PB2 Chip Select (=SS)  */

DDRB  = 0;
DDRB |= (1<<3)|(1<<5);  // MOSI, SCK  as output
DDRB |= (1<<dc)|(1<<rst)|(1<<cs);  // dc, rst, cs  as output

Damit bist du immer noch komplett auf Port B und es kann
eigentlich gar nichts schiefgehen.

Entsprechend der Programmierung hier musst du natürlich
deine Pins richtig verdrahten.

[M. W. (mw73)]

naja, am 644 läufts auch nicht
ich geh jetzt schlafen

[M. W. (mw73)]

ah, danke für die Tipps,
werds mir gleich morgen ansehen.

[M. W. (mw73)]

> - Testen ob du eine Minimal-Blinky Applikation funktioniert
> - Speziell PB7 testen ob er frei ist (Blinky)
> Denn PB7 ist nur frei wenn die Fuses für den Oszillator
> richtig gesetzt sind.

Blinky funkioniert


> #define dc   0    /*  Data/Command  */
> #define cs   2    /*  Chip Select   */
> #define rst  1    /*  Reset         */


wurde durchgeführt


> DDRB  = 0;
> DDRB |= (1<<3)|(1<<5);  // MOSI, SCK  as output
> DDRB |= (1<<dc)|(1<<rst)|(1<<cs);  // dc, rst, cs  as output

ebenfalls durchgeführt

> Entsprechend der Programmierung hier musst du natürlich
> deine Pins richtig verdrahten.

hab ich auch


> Damit bist du immer noch komplett auf Port B und es kann
> eigentlich gar nichts schiefgehen.

ist es aber, es geht nach wie vor nichts.
Der Rest vom Code ist unberührt.

[Arduinoquäler (Gast)]

Markus W. schrieb:
> es geht nach wie vor nichts.

Na gut. Soweit so schlecht. Es wird Zeit dass du deinen
Schaltplan und deinen Aufbau zeigst.

Wenn sich dieser als vernünftig erweist werde ich mir
die Mühe machen einen eigenen Aufbau zu machen und nach
einem potentiellen Fehler in der Software zu suchen.
(M)einen nakten ATMega88 habe ich inzwischen gefunden.

[M. W. (mw73)]

Alles klar,
ich bereite das auf.

[Arduinoquäler (Gast)]

Kleine Bastelstunde am Dienstag Abend ....

Also bei mir funktioniert das auf Anhieb.

- mit einem ATMega88,
- 8 MHz interner Oszillaor,
- 3.3V Betriebsspannung

Ein ATMega8 (statt ATMega88) steht mir nicht zur Verfügung,
sollte aber genau so funktionieren. Ich kann keine
Unterschiede erkennen die das verhindern könnten.

[M. W. (mw73)]

hmm, ich hab gestern extra noch mal den 2560 getestet, da läufts auf 
Anhieb.
Ich hänge jetzt noch einmal die Software an.
Das einzige was ich raus genommen habe ist die If-Abfrage aber das 
sollte ja nicht stören, macht ja dem 2560 auch nichts.

Vielleicht kannst Du ja noch mal drüber schauen.

Die CPU-Speed ist in der Toolchain definiert.

ansonsten
-Mega8, 5V
-8mHz interner Oszillator
-5V Betriebsspannung

Bilder vom Aufbau sind im Anhang.
Ich hoffe dass ich den Schaltplan heute noch schaffe.

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Ich hänge jetzt noch einmal die Software an.
> Das einzige was ich raus genommen habe ist die If-Abfrage aber das
> sollte ja nicht stören, macht ja dem 2560 auch nichts.
>
> Vielleicht kannst Du ja noch mal drüber schauen.

Soeben getestet.

Deine Sourcen aus dem RAR Archiv einfach in ein neues AVR
Studio (v4.18) Projekt hineinkopiert und auf Mega88 übersetzt.

Funktoniert einwandfrei ohne Änderungen.

Vermutungen:

- dein Steckbrett-Aufbau ist verdammt unsicher und
unübersichtlich, damit fehleranfällig
- dein ATMEL Studio Projekt ist irgendwo falsch eingestellt.

Verwende doch wenn möglich AVR Studio 4.18, das ist für
die AVRs völlig ausreichend und wesentlich einfacher, im
ATMEL Studio kannst du sehr viel einstellen und damit
auch viel falsch machen. Aus den verschiedensten Gründen
verwende ich ATMEL Studio sehr ungern.

Ich hänge mal ein von mir erzeugtes Hex File für "unsere"
Konfiguration für den ATMega8 an, damit kannst du ja mal
deinen Aufbau testen. Wenn das nicht funktioniert dürfte
an deinem Aufbau was faul sein.

[M. W. (mw73)]

so, aber jetzt,

nach langem intensiven testen und Umbauen von einem Steckbrett zum 
anderen und nach verschiedenen Mega8 changes geht es endlich.

Das war aber nur reiner Zufall dass ich dahinter gekommen bin.
Am Netzteil die Spannung auf 3V3 runter gedreht und auf einmal gings.

Verstehe ich zwar nicht denn der Chinesenmann sagt dass es auch für 
5Volt geeignet ist und macht sogar hinten die Lötbrücke J1 rein (5V open 
oder 3V3 close).

Aber warum gings dann beim 2560, den hab ich ja auch mit 5V gespeist.
Kannst Du Dir das erklären, bzw. hast Du Dein Display schon mal mit 5V 
getestet?

Hast Du auch die Lötbrücke J1 auf der Rückseite?

Wenn es wirklich nur mit 3V3 geht und ich den AVR mit 5V betreiben 
will/muss, würde da ein Levelshifter Abhilfe schaffen?

Auf jeden Fall danke ich Dir recht herzlich für Deine Bemühungen und 
Hilfestellungen. Du hast Da wirklich eine Menge Arbeit auf Dich genommen 
und mir sehr geholfen.


Ich möchte jetzt die Lib noch auf einen 644/1284 migrieren was mein 
eigentliches Ziel wäre. Ich versuche auch hier auf PORTB zu bleiben, wo 
sich eben auch SPI befindet und hoffe dass das soweit funktioniert.

Könntest Du vielleicht noch ein paar Tage mitlesen, ob das auch auf den 
anderen Megas funktioniert.

Ich hab mir noch zwei neue Displays bestellt und bin schon gespannt wie 
diese funktionieren. Ich hoffe, dass ich das 5V Problem noch irgendwie 
in den Griff bekomme.

LG
Markus

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Aber warum gings dann beim 2560, den hab ich ja auch mit 5V gespeist.
> Kannst Du Dir das erklären, bzw. hast Du Dein Display schon mal mit 5V
> getestet?

Solange du keine verlässlichen Schaltpläne zeigst und Fotos vom
Aufbau auf denen man wirklich was erkennen kann (mindestens
800x600 und scharf) ist das ein Stochern im Nebel.

Bei solchen nebulösen Aktionen bin ich jetzt dann ganz still.

Um nur ein Beispiel zu nennen:

Markus W. schrieb:
> nach langem intensiven testen und Umbauen von einem Steckbrett zum
> anderen und nach verschiedenen Mega8 changes geht es endlich.

Unter anderem: was sind "verschiedene Mega8 changes"?

[M. W. (mw73)]

> Unter anderem: was sind "verschiedene Mega8 changes"?

damit war gemeint, dass ich den ganzen Controller getauscht habe.

Schaltplan folgt noch

[M. W. (mw73)]

Im Anhang befinden sich jetzt der Schaltplan, der dem realen 
Schaltungsaufbau entspricht sowie einige Bilder.
Ich hab mir eine andere Kammera geliehen aber schärfer geht es nicht 
mehr.

[Arduinoquäler (Gast)]

Ok, schaut sooo schlecht nicht aus. Lobenswerter Weise hast
du Abblock-Cs nicht vergessen. Ein Elko für die ganze
Schaltung würde allerdings reichen, ganz nahe an den Pins
bringt das nichts mehr und verschlechtert die Übersicht.

Gut, den 5-poligen ISP Stecker hab ich noch nirgends gesehen,
und üblicherweise brauchen Original-Programmer dazu die
Betriebssspanung als Monitor Pin, den finde ich nicht.

Was mir nicht gefällt und ich für gefährlich halte ist die
Versorgung der Background LEDs mit 5V. Ich denke das ist
nicht zulässig und könnte a) das Display bzw die LEDs
zerstören und es könnte b) sehr viel Strom fliessen der
die Schaltung unsicher macht (Spannungseinbruch). Das ist
allerdings aus der Ferne schwer einschätzbar und hängt vom
Netzteil (und von den Kontakten des Steckbrett) ab.
Jedenfalls ist die von dir erwähnte Jumperung für 5V
Betrieb nicht geeignet die LEDs korrekt zu versorgen. Die
bekommen einfach das was am Pin von aussen anliegt. Da ist
auf dem Touch-Display ein 3.9Ohm Widerstand drauf der die
LEDs schützen sollte, aber ob das auf Dauer für 5V
ausreicht kann ich nicht beurteilen. Beim Display ohne
Touch sehe ich diesen Widerstand nicht (er könnte auf der
Rückseite sein) und ich würde auf jeden Fall die 5V
vermeiden (weiteren Vorwiderstand von aussen hinzufügen).
Womöglich schüzt der Übergangswiderstand der Steckbrett-
Kontake davor dass die LEDs getoastet werden. Bei mir
liegen die LED Pins immer an maximal 3.3V in Reihe mit
zusätzlichen Schutzwiderstand von ein paar wenigen Ohm.

[Arduinoquäler (Gast)]

Arduinoquäler schrieb:
> Was mir nicht gefällt .....

Anders und in Kurzform ausgedrückt: darin könnte der Hund
für die (frühere) Fehlfunktion des Displays begraben sein.

[Arduinoquäler (Gast)]

Arduinoquäler schrieb:
> Da ist
> auf dem Touch-Display ein 3.9Ohm Widerstand drauf der die
> LEDs schützen sollte

Du wirst feststellen können dass der Widerstand spürbar heiss wird.

[M. W. (mw73)]

> Gut, den 5-poligen ISP Stecker hab ich noch nirgends gesehen,
> und üblicherweise brauchen Original-Programmer dazu die
> Betriebssspanung als Monitor Pin, den finde ich nicht.

Im Schaltplan rechts oben und am ersten Bild ganz rechts sind die 
Leitungen aufgesteckt. Für den Programmer habe ich mir eine Platine 
gemacht, die ich dann wieder abstecken kann. Jetzt ist sie an den 
Bildern nicht aufgesteckt.
Mein Programmer braucht lt. Betriebsanleitung keine eigene Versorgung, 
kann diese aber zuschalten. Es ist aber nicht der Original-Programer.

> Was mir nicht gefällt und ich für gefährlich halte ist die
> Versorgung der Background LEDs mit 5V.

Ja, stimmt, den hab ich wirklich nicht berücksichtigt. Das werd ich 
gleich noch nachholen. Ich mach heute noch ein Bild von der Rückseite 
des Displays.

[Thomas F. (igel)]

Markus W. schrieb:
> Im Anhang befinden sich jetzt der Schaltplan, der dem realen
> Schaltungsaufbau entspricht sowie einige Bilder.

Der CS-Leitung des Displays würde ich noch einen Pull-up Widerstand 
verpassen damit beim Flashen des Atmega hier ein definierter High-Pegel 
anliegt.

[M. W. (mw73)]

> Du wirst feststellen können dass der Widerstand spürbar heiss wird.
hab ich!

Ich habe heute einen 10 Ohm Widerstand in Serie zur Backlight-Versorgung 
eingebaut. Die Stromaufnahme ist zwar merkbar gesunken (bei 3v3 von 70mA 
auf 40mA lt. Netzteil) jedoch ist ein Betrieb unter 5V nach wie vor 
nicht möglich.

Ich werde beim 2560 noch die Pegel messen worauf ich eigentlich auch 
schon neugierig bin. Wenn sich dabei nichts ergibt werde ich 
wahrscheinlich einen bidirektionalen Pegelwandler ordern.

Anbei hab ich noch ein Bild meines Displays und eines mit dem 
Programmieradapter für den Diamex Programmer angehängt.

[M. W. (mw73)]

Danke auch Dir Thomas für Deinen Hinweis, bei der endgültigen Variante 
werde ich dieses Berücksichtigen.

[M. W. (mw73)]

so, jetzt hab ich noch ein Geheimnis gelüftet, an dessen Ursache ich 
auch selber schuld bin. Ich weis jetzt weshalb es mit dem 2560 
funktioniert hat. Ich hab den nämlich nicht über die Buchse versorgt 
sondern mit 5V über den Vin-Pin und dabei nicht an den Spannungsregler 
gedacht. Da hab ich gerade mal 3,7V Pegel. Das ist noch dazu in etwa der 
obere Grenzpegel für das Display denn bei ca. 3,8V funktioniert es nicht 
mehr.

Ich trau mir aber jetzt zu behaupten, dass das Display nur mit 3V3-Pegel 
arbeitet.

Sollte Dir noch was anderes einfallen bitte ich um Deine Meinung, 
ansonsten werde ich morgen einen Pegelwandler ordern.

[M. W. (mw73)]

> Ich hab den nämlich nicht über die Buchse versorgt sondern mit 5V über den > 
Vin-Pin

wundert mich ja, dass das überhaupt funktioniert. Sollte doch mindestens 
6V sein, oder?

[M. W. (mw73)]

Jetzt hab ich noch den 644er erfolgreich in Betrieb genommen --> 3V3

[Arduinoquäler (Gast)]

Nach einem erfolgreichen Toast-Versuch habe ich mich nicht
wieder getraut ein solches Display mit ILI9341 an 5 Volt
anzuschliessen. In den Datenblättern die ich dazu gelesen
habe war von 5V nicht die Rede (siehe auch meine Bemerkungen
zu den 5V an der Hintergrundbeleuchtung).

Um mit 5 Volt-AVRs arbeiten zu können habe ich für meine
Tests mir eine Trägerplatte mit Pegelwandler gebaut. Sie
bestehet aus einem 3.3V Low-Drop-Spannungregler (LM1117) und
einem 74LVT244 Bus Driver der an 3.3V betrieben wird. Der
Buffer 74LVT244 ist 5V-tolerant und bringt auf der 5V-Seite
ausreichend Logik-Pegel um einen AVR mit 5V zu "befriedigen".
Das Display sieht dann nur 3.3V Logik-Pegel und ist auch
zuverlässig mit 3.3V versorgt.

Hat man dann einen 3.3V Controller dann kann man das Display
genau so ohne Änderungen weiter mit dem Interface betreiben.

(Im Anhang nochmal ein Bild vom Adapter der schon hier
Beitrag "Re: ILI9341 langsam Verbesserungsvorschläge?"
mit Display - angehängt an einen Arduino Mega2560 -
dargestellt ist)

Wie immer gilt: your mileage may vary.

[M. W. (mw73)]

Die Platine mit dem 74LVT244 hast Du aber gekauft, oder?

Arbeitest Du eigentlich nur mit Lochrasterplatinen?

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Die Platine mit dem 74LVT244 hast Du aber gekauft, oder?

Nein, die nackten Plättchen gab es mal "irgendwo", die
Bestückung macht man selbst.

Markus W. schrieb:
> Arbeitest Du eigentlich nur mit Lochrasterplatinen?

Solange es nichts Fertiges gibt, ja. Diese Methode ist
langjährig bewährt - ergibt einfach die zuverlässigsten
Ergebnisse. Da wackelt kein Draht, da reisst nichts ab.

Aber dazu braucht man nun mal Wire-Wrap-Draht und einen
entsprechend passenden Abisolierer, sonst scheitert man
kläglich. Ach ja, ein bisschen Geduld und Musse braucht
man auch, so schnell mal wie ein Steckbrett zusammen-
geschustert geht nicht. Aber der Erfolg belohnt ....
... wenn man weiss was man tut.

[M. W. (mw73)]

Kannst Du mir noch erklären, wofür die beiden Widerstände rechts 
oberhalb der 244er Platine sind?
Ist einer davon für das Backlight?
Könntest Du mir für dein 244er noch eine Bezugsquelle nennen?

Ich werde mir dafür wahrscheinlich eine Platine ätzen.

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Kannst Du mir noch erklären, wofür die beiden Widerstände rechts
> oberhalb der 244er Platine sind?

Spannungsteiler für den einstellbaren Spannungsregler.

Markus W. schrieb:
> Ist einer davon für das Backlight?

Nein der ist auf der Rückseite.

Markus W. schrieb:
> Könntest Du mir für dein 244er noch eine Bezugsquelle nennen?

https://www.ebay.de/itm/10x-74LVT244APW-74LVT244-3-3-V-octal-buffer-line-driver-Leitungstreiber-SMD-SO20/381981128284?hash=item58efd9765c:g:Bt0AAOSw4A5YsXLf

Es darf auch ein 74LVT245 sein. Oder mehrere 74LVT1G125.

Aber die Sache ist für dich vermutlich einacher wenn du
so etwas vorgefertigtes mit BSS138 nimmst.

https://www.ebay.de/sch/i.html?_from=R40&_sacat=0&_nkw=level+shifter+arduino&rt=nc&LH_PrefLoc=1

Man kann die BSS138 auch separat kaufen und selbst verdrahten.
Das Prinzip ist überall erklärt (z.B. Datenblatt).

[M. W. (mw73)]

Danke für die tollen Tipps,

ich überlege ob ich hierfür ein Layout mache und eine kleine Platine 
ätze.

[Felix (Gast)]

Hallo zusammen,

ich hole den Thread nochmal hoch. Ich haben den Code von Arduinoquäler 
(AVRStudioProject_Test_ILI9341_Mega2560.zip) verwendet und versuche 
diesen auf einem Arduino Due (Mega2560) zum laufen zu bringen. Die 
Verkabelung (entnommen aus dem Code) sieht folgendermassen aus:

CS  PB0
SCK  PB1
MOSI  PB2
MISO  PB3
D/C  PB6
RESET  PB7

Ich hoffe ich habe es richtig gemacht !? Wie dem auch sei, auf dem 
Display passiert nichts, keine Initialisierung, LCD bleibt weiss.

Das Board ist ein originales Arduino Board, CPU Takt 16 MHz und 
vielleicht ist es ja auch ein Timinig Problem ?

Hoffe ihr könnt mir weiterhelfen.

Besten Dank

[Arduinoquäler (Gast)]

Felix schrieb:
> Ich hoffe ich habe es richtig gemacht !? Wie dem auch sei, auf dem
> Display passiert nichts, keine Initialisierung, LCD bleibt weiss.

Aus dem Verlauf des Threads ist zu entnehmen dass Markus W.
das Diplay nicht zum funktionieren brachte weil die Betriebs-
Spannung des Prozessors zu hoch war. Wie auch immer, du kannst
aus dem Thread auch entnehmen dass ich eine strenge Trennung
der Signalpegel beibehalte und nicht einfach ein 5V Teil an
ein 3.3V Teil anschliesse. Ich habe das auch nie ausprobiert
(bis auf einmal bei dem ich die Display Beleuchtung getoastet
habe), will das auch nicht tun. Wenn der Schaltungsaufwand
minimal sein soll dann betreibe ich eben den Prozessor auch
mit 3.3V, siehe auch dortige Versucxhsschaltung.

Wie immer, im Zweifelsfall deine Schaltung sauber überprüfen
und vielleicht auch mal einen Aufbau zeigen. Das Display
ist aber schon vom Controller ein ILI9341?

[Arduinoquäler (Gast)]

Felix schrieb:
> und versuche diesen auf einem Arduino Due (Mega2560)

Nein das geht nicht.

Auf einem Arduino Due ist kein Mega2560 drauf. Du musst
dich schon entscheiden ....

[Felix (Gast)]

Also das Board ist definitiv ein Arduino Mega 2560 R3.

Bei den Pegeln gebe ich dir recht aber zumindestens sagt der Hersteller 
es sei 5V kompatibel. Ich habe das Display mit 3.3V versorgt. Ich könnte 
noch Widerstände in die Leitungen schalten, sollte als Pegelwandlung ok 
sein.

Stimmt den die Pinbelegung ?
CS    PB0
SCK   PB1
MOSI  PB2
MISO  PB3
D/C   PB6
RESET PB7

[Arduinoquäler (Gast)]

Felix schrieb:
> Stimmt den die Pinbelegung ?

Arduinoquäler schrieb:
> Das Display
> ist aber schon vom Controller ein ILI9341?

[Felix (Gast)]

Aufbau im Anhang.

[Felix (Gast)]

> Das Display
> ist aber schon vom Controller ein ILI9341?
yep

[Arduinoquäler (Gast)]

Felix schrieb:
> Also das Board ist definitiv ein Arduino Mega 2560 R3.

Manche Leute die hier um Hilfe bitten entschuldigen sich
wenn sie falsche Angaben gemacht haben.

Felix schrieb:
> er zumindestens sagt der Hersteller
> es sei 5V kompatibel.

Hier wurden aber offensichtlich andere Erfahrungen gemacht.

Felix schrieb:
> Ich könnte
> noch Widerstände in die Leitungen schalten, sollte als Pegelwandlung ok
> sein.

Wenn du meinst dass es so funktioniert dann bist du ja fertig
und brauchst hier keine weitere Hilfe. Wie bereits erwähnt
habe ich deine Konfiguration 5V <--> 3.3V nie ausprobiert.

[Felix (Gast)]

Also ich versuche es nochmal. Die Pegel werde ich schon anpassen aber 
kannst du mir mal die Pinbelegung bestätigen ?

Ich habe folgende Fragen zu deinem Code...
Pinbelegung ?
Würde der Code auch mit 16 MHz laufen ?

Der Code ist auf jeden Fall nicht der welcher auf dem Photo dargestellt 
ist, verwirrt zusätzlich.

Na, entschuldigen kann ich mich auch wenn ich falsche Informationen 
gebe. Bin mit dem Arduino Zeugs nicht so vertraut.

Wäre nett wenn du auf die Fragen eingehst.

Danke.

[Arduinoquäler (Gast)]

Felix schrieb:
> Ich habe folgende Fragen zu deinem Code...
> Pinbelegung ?

Stimmt.

> Würde der Code auch mit 16 MHz laufen ?

Tut er ja. Meine Demo läuft auf dem Mega256 auf dem Arduino-
Board, und dessen Taktfrequenz kann man von aussen nicht
beeinflussen. Im Projektfile für das AVR Studio ist auch 16 MHz
eingestellt, also alles gut.

Felix schrieb:
> Der Code ist auf jeden Fall nicht der welcher auf dem Photo dargestellt
> ist, verwirrt zusätzlich.

Das verstehe ich nicht.

Konntest du denn erfolgreich das richtige Hex-File in den
Controller flashen? Wie hast du das gemacht?

[Felix (Gast)]

Ich habe mit deinen Dateien ein Atmel Studio Projekt gebaut und dann 
compiliert. Das Board hat einen Bootloader und geflasht habe ich mit 
avrdude.

Compiler ist AVR/GNU C Compiler : 5.4.0. Optimizer steht auf -Os

Kannst du bitte mal dein Hex File anhängen ? das ist leider nicht im Zip 
enthalten. Wer weiss was ich falsch mache.

[Arduinoquäler (Gast)]

Felix schrieb:
> Kannst du bitte mal dein Hex File anhängen ?

Hier, soeben generiert und getestet auf Mega2560.

Felix schrieb:
> Ich habe mit deinen Dateien ein Atmel Studio Projekt gebaut

Dann hast du vielleicht beim Bauen was falsch gemacht.

Es hat schon seinen Sinn dass ich ein komplettes Projekt
gepostet hatte.

[Felix (Gast)]

Sollte vielleicht noch erwähnen das ich deine "optimized" Version gebaut 
habe. Also gleich die Ili9341.c und h genommen habe.

[Arduinoquäler (Gast)]

Felix schrieb:
> Ich haben den Code von Arduinoquäler
> (AVRStudioProject_Test_ILI9341_Mega2560.zip) verwendet

Felix schrieb:
> Sollte vielleicht noch erwähnen das ich deine "optimized" Version gebaut
> habe. Also gleich die Ili9341.c und h genommen habe.

Arduinoquäler schrieb:
> Es hat schon seinen Sinn dass ich ein komplettes Projekt
> gepostet hatte.

[Felix (Gast)]

Vielen Dank für das Hex File, damit geht es auch nicht aber es beseitigt 
somit alle Zweifel an meinem Compilat. Ich werde jetzt mal die Pegel 
anpassen. Vielmehr bleibt da auch nicht als Fehlerursache.

[M. W. (mw73)]

Hallo Felix,

Ich hatte anfangs auch Probleme das Display zum Laufen zu bekommen.
Es funktioniert definitiv nur per Pegelanpassung. Wenn Du ein regelbares 
Labornetzteil hast, kannst Du versuchen den Mega 2560 am Vin Pin mit 5V 
zu speisen. Durch den Spannungsabfall am internen Spannungsregler sollte 
sich eine Spannung einstellen, mit der das Display gerade noch läuft. 
Das ist aber wirklich nur zum Testen.

@Arduinoquäler

Ich habe jetzt zwei verschiedene fertig aufgebaute Levelshifter getestet 
und mit denen funktioniert das ganze auch mit 5V. Ich habe mir aber auch 
die Bausteine bestellt um eine eigene Platine zu fertigen (mit Stecker 
usw.). Das Display läuft sehr zufriedenstellend. Eventuell werde ich die 
Lib noch etwas abändern, dass sich je nach verwendetem Controller die 
Config voreingestellt ist.

LG
Markus

[Arduinoquäler (Gast)]

Markus W. schrieb:
> Ich habe jetzt zwei verschiedene fertig aufgebaute Levelshifter getestet
> und mit denen funktioniert das ganze auch mit 5V.

Danke für deine Rückmeldung wie es ausgegangen ist. Das ist
für Mitlesende und Ratsuchende ein sehr wertvoller Bestandteil
eines Threads.

Vielleicht kannst du deine Erfolgsmeldung für die Ratsuchenden
noch etwas "visuell" untermalen (Bilder, Schaltplan ...)?

[Felix (Gast)]

Danke auch von mir für die Rückmeldung. Das hilft, ich werde am 
Wochenende auch eine kleine Adapterplatine bauen. Wäre dennoch gut wenn 
du deinen Schaltplan hier veröffentlichen würdest.

Danke nochmal.

[Äxl (geloescht) (Gast)]

moins,

Arduinoquäler schrieb:
> Verwende doch wenn möglich AVR Studio 4.18, das ist für
> die AVRs völlig ausreichend und wesentlich einfacher, im
> ATMEL Studio kannst du sehr viel einstellen und damit
> auch viel falsch machen. Aus den verschiedensten Gründen
> verwende ich ATMEL Studio sehr ungern.

Ich musste mich auch überwinden und mich "seinerzeit" mit dem makefile, 
dem Linkerscript und dem ganzen anderen "gedöns" (WINAVR<->AVR-Studio) 
auseinandersetzen.
Peinlich wird es, wenn selbst im professionellen Bereich SDK's mit 
uralten WINAvr-Distributionen ausgeliefert werden, weil sonst die 
Projekte angeblich nicht zu compilieren gehen.
Ich gebe unumwunden zu und nehme mich da nicht aus: auch ich bin froh, 
wenn ich auf einem ATMega168 oä. "arbeiten" darf und mich nicht mit den 
Startup-Files eines STM32xyz herumschlagen muss.
Viel Spaß noch!
Läuft's denn mittlerweile? (Ich kann jetzt unmöglich alles lesen)
Äxl

[M. W. (mw73)]

> Vielleicht kannst du deine Erfolgsmeldung für die Ratsuchenden
> noch etwas "visuell" untermalen (Bilder, Schaltplan ...)?

Ich werde am Wochenende einen Schaltplan sowie einige Bilder einstellen.

> Läuft's denn mittlerweile? (Ich kann jetzt unmöglich alles lesen)
> Äxl

Der Code von AQ hat immer funktioniert. Das Problem ist dass das besagte 
Modul nur mit 3V3 Pegel läuft.

Markus

[M. W. (mw73)]

Wie versprochen kommmen noch einige Bilder sowie ein Schaltplan. Ich 
habe meine bisherige Schaltung um folgende Komponenten erweitert um die 
gesamte Schaltung mit 5V betreiben zu können. Da es sich in erster Linie 
nur um einen Test handelt habe ich auf fertige Module zurück gegriffen.

1) Spannungsregler 5V->3V3

https://www.ebay.de/itm/Spannungsregler-AMS1117-3-3V-DC-DC-Step-Down-SpannungsWandler-Modul-Strom-49/121902459206?hash=item1c61f3e946:m:mVqOBrzSWQSKeGjjA8Dn9BA

2) bidirektionales Levelshiftermodul basierend auf TX0108

https://www.ebay.de/itm/Logic-Level-shifter-Converter-Konverter-5-0-3-3V-Bidirektional-8-chan-Arduino/222080420936?hash=item33b5064c48:g:qgsAAOSw8RJXCPco

Zum Schaltplan:
Dieser zeigt aktuell einen Mega8. Es ist aber ein Mega644 verbaut. Da 
ich wie erwähnt fertig aufgebaute Module verwendet habe, sind im 
Schaltplan keine Kondensatoren vorgesehen. Bei diskretem Aufbau müssten 
diese noch berücksichtigt werden.

Achtung: Da ich das Display jetzt auch mit 3V3 versorge, habe ich die 
Lötbrücke J1 auf der Rückseite des Displays geschlossen!

Alternativ könnte man aber das Display weiterhin mit 5V versorgen und 
die Brücke J1 offen lassen. Da ich ohnehin für die Versorgung des 
Levelshifters 3V3 benötige habe ich das Display auch gleich mit 3V3 
gespeist.

Die Bilder der Schaltung sind leider nicht sehr aufschlussreich, da die 
vielen Kabel am Steckbrett unübersichtlich sind. Der Schaltplan sollte 
dafür klar sein.

Auf Bild 7705 ist mein zweiter Aufbau mit dem Mega8 und einem anderen 
Levelshifter zu sehen.

Bei weiteren Fragen einfach schreiben.

[Spannungsteiler (Gast)]

Hallo,

Markus W. schrieb:
> Alternativ könnte man aber das Display weiterhin mit 5V versorgen und
> die Brücke J1 offen lassen. Da ich ohnehin für die Versorgung des
> Levelshifters 3V3 benötige habe ich das Display auch gleich mit 3V3
> gespeist.

Markus W. schrieb:
> Ich hatte anfangs auch Probleme das Display zum Laufen zu bekommen.
> Es funktioniert definitiv nur per Pegelanpassung

ein kurzer Erfahrungsbericht über TFT_SPI2´2 Display in Verbindung
mit Arduino (µC 328).
Ich nutze für verschiedene Projekte mit Vorliebe dieses kleine süße 
Display. Da ich kein Programmierer bin, musste ich von Anfang an nach
stabilen und schnellen Librarys suchen, und tagelang experimentieren, um 
die geeignete Hardware zusammenzukriegen.

Mein eiwandfrei funktionierendes Ergebnis möchte ich euch hier 
weitergeben.

Aus dem Schaltplan kann man alle relevante Infos und Daten entnehmen.
Meinen ersten Testaufbau habe ich damals fotografiert, die poste ich 
auch.

Mittlerweile habe ich auf Github gesehen, dass es schon neuere schnelle
Libs für dieses Display gibt. Ich denke, dies ist aber für euch 
zweitrangig.
Vielmehr möchte ich die 5V-->3V3 Signalanpassung mit CD5050 zeigen,
da diese Lösung stabil lauft und fast nichts kostet!

Viele liebe Grüße!

[Markus (Gast)]

Hier noch ein paar ILI-Beispiele:
Beitrag "Re: 2.2'TFT ILI9340 und Arduino"

[M. W. (mw73)]

@Spannungsteiler

Danke auch für Deinen Beitrag!
Ohne jetzt einen Blick ins Datenblatt geworfen zu haben, ist der CD5050 
ausreichend schnell?

@Markus
Danke auch für Deinen Beitrag!

Ich finde den (alten) Thread mittlerweile sehr gut und sinnvoll
für alle, die sich mit diesem Display beschäfigen. Ich habe mir 
mittlerweile
auch ein paar davon bestellt und möchte sie vermehrt in meine Projekte 
einsetzen.

@Arduinoquäler
Ich warte noch auf die Bauteile (LVT244A und ASM1117-3V3) um mir eine 
eigene Platine zu fertigen. Bis die teile hier sind werde ich mal den 
Schaltplan zeichnen und diesen dann Posten.

[Felix (Gast)]

Bestend Dank auch von meiner Seite. Der CD5050 ist ein CD4050, denke das 
ist ein Schreibfehler. Den TXB0108 kannte ich noch nicht. Auf jeden Fall 
wertvolle Tips.

Ich werde in den kommenden Tagen dann mal einen Versuch mit dem 74HC4050 
machen und berichten.