Martin schrieb:> Ich hoffe auf Tipps und gute Ratschläge.
Selbst wenn dein Display hell (weiss?) ist muss es nicht
eingeschaltet sein, da die Hintergrund-LEDs immer leuchten.
Ein einfaches Off-Kommando muss also nichts bewirken.
Versuche dich erst mal an einer korrekten Initialisierungs-
Sequenz und danach ein wechselweises Ein- und Aussschalten,
dann wirst du (bei korrekter Ansteuerung) einen leichten
Helligkeits-Wechsel im Leuchtschimmern erkennen können.
M. schrieb:> Die Belegung.
Die Pins abzuzählen bin ich zu faul. Es ist nicht klar wo Pin 1 ist.
Bei dir fehlt offensichtlich die Bedienung des CS (Chip Select)
Pins, allerdings kann ich mich täuschen da nicht alle Bezeichnungen
auf deinen Foto mit denen im Programmcode übereinstimmen.
Bringe mal die Pin-Bezeichnungen mit dem Programmcode zusammen
und zeige nochmals einen Update.
Arduinoquäler schrieb:> Versuche dich erst mal an einer korrekten Initialisierungs-> Sequenz und danach ein wechselweises Ein- und Aussschalten,> dann wirst du (bei korrekter Ansteuerung) einen leichten> Helligkeits-Wechsel im Leuchtschimmern erkennen können.
Was ist denn die richtige Initialisierungssequenz? Im DS konnte ich nur
entdecken, dass der Resetpin einmal auf Low und dann wieder high gezogen
werden soll. Gibts da irgendwo ein Kapitel was nicht gerade Init..
heißt?
Arduinoquäler schrieb:> Die> _delay_ms(2);>> solltest du zu _delay_us machen sonst wirst du irgendwann ewig warten.>> Diese kurzen Delays sind für das Display durchaus ausreichend.
Ist bewusst länger um auf jeden Fall die richtigen Pegel anliegend zu
haben, wenn es dann richtig benutzt wird werden aus den ms auch us
Arduinoquäler schrieb:> M. schrieb:>> Die Belegung.>> Die Pins abzuzählen bin ich zu faul. Es ist nicht klar wo Pin 1 ist.>> Bei dir fehlt offensichtlich die Bedienung des CS (Chip Select)> Pins, allerdings kann ich mich täuschen da nicht alle Bezeichnungen> auf deinen Foto mit denen im Programmcode übereinstimmen.>> Bringe mal die Pin-Bezeichnungen mit dem Programmcode zusammen> und zeige nochmals einen Update.
Unten nochmal mit den kommentierten Pins, ich habe mich in der SW an die
Bezeichnungen aus dem DS gehalten. (Steht jetzt hinter den Defines
dabei) der Chipselect wird gesetzt. Die Pinbezeichnung steht im Define
(PG0, PG1, PG2, PD7 und die kompletten A und C Ports.
Martin schrieb:> Unten nochmal mit den kommentierten Pins, ich habe mich in der SW an die> Bezeichnungen aus dem DS gehalten. (Steht jetzt hinter den Defines> dabei) der Chipselect wird gesetzt. Die Pinbezeichnung steht im Define> (PG0, PG1, PG2, PD7 und die kompletten A und C Ports.Martin schrieb:> #define RDX PD7 //RS
Es gibt bei deinem Modul kein Read-Signal, das Modul ist nur
beschreibbar (das was dein Foto an Information hergibt).
In diesem Define ist das Signal C/D (Command/Data), hier auch
RS (Register Select) versteckt (wir mal so, mal so bezeichnet).
Dieses RS musst du bei Command und Data Write Vorgängen korrekt
bedienen, zusätzlich zum CS-Signal.
Ich sehe das RDX bei dir allerdings benutzt um zu lesen.
Martin schrieb:> Was ist denn die richtige Initialisierungssequenz?
Das ist ein Schlauch von Kommando- und Datenbytes wie er
an verschiedenen Stellen im Internet zu finden ist.
Arduinoquäler schrieb:> Das ist ein Schlauch von Kommando- und Datenbytes wie er> an verschiedenen Stellen im Internet zu finden ist.
So wie im Anhang z.B. ....
Arduinoquäler schrieb:> Martin schrieb:>> Was ist denn die richtige Initialisierungssequenz?>> Das ist ein Schlauch von Kommando- und Datenbytes wie er> an verschiedenen Stellen im Internet zu finden ist.
Ich finde keinen, kannst gerne einen Link hier rein stellen, du scheinst
ja zu wissen wo es die gibt?
Arduinoquäler schrieb:> Martin schrieb:>> Also demnach ist meine Pinbelegung richtig.>> Aber das RS Handling nicht!
Woran machst du das fest? Laut DS S. 27 ist bei write befehlen RS high.
Ich setze vor der While alle Signale auf High. In der void writecmd und
void writePar wird daher RS garnicht erst angefasst. Nach verlassen der
voids sind immer alle Pegel wieder auf high.
Martin schrieb:> Woran machst du das fest?
Solange du dich weigerst in deiner Source die Pin-Bezeichnungen
deines Modules zu verwendet reden wir aneinander vorbei.
Ich halte daran fest dass du RS (Register Select) und/oder
CS (Chip Select) nicht richtig bedienst.
Register Select unterscheidet Command und Data.
Chip Select beginnt einen Schreib-Zylklus und beendet ihn.
Martin schrieb:> Ich finde keinen,
[ ] Du liest alle meine Beiträge
[ ] Dir ist egal was ich sonst schreibe
Wenn man eine Suchmaschine bemüht findet man jede Menge
"ili9486 init sequence"
Arduinoquäler schrieb:> Martin schrieb:>> Woran machst du das fest?>> Solange du dich weigerst in deiner Source die Pin-Bezeichnungen> deines Modules zu verwendet reden wir aneinander vorbei.>> Ich halte daran fest dass du RS (Register Select) und/oder> CS (Chip Select) nicht richtig bedienst.>> Register Select unterscheidet Command und Data.> Chip Select beginnt einen Schreib-Zylklus und beendet ihn.>> Martin schrieb:>> Ich finde keinen,>> [ ] Du liest alle meine Beiträge> [ ] Dir ist egal was ich sonst schreibe>> Wenn man eine Suchmaschine bemüht findet man jede Menge> "ili9486 init sequence"
Ich hab dir jetzt nochmals das Signal umbenannt, in CSX. Also wie im DS.
1
#define WRX PG2 //WR <- Bezeichnung Platine
2
#define RDX PD7 //RS <- Bezeichnung Platine
3
#define RST PG0 //RST <- Bezeichnung Platine
4
#define CSX PG1 //CS <- Bezeichnung Platine
Hier siehst du auch wie sie auf der Platine genannt sind und wie sie eig
heißen sollten laut Datenblatt.
und die Voids dazu:
1
voidwriteCmd(uint16_tData){
2
//WRX steigende Flanke, RDX High, CSX low
3
PORTG&=~(1<<CSX);
4
PORTG&=~(1<<WRX);
5
setData(Data);
6
_delay_us(2);
7
PORTG|=(1<<WRX);
8
_delay_us(2);
9
PORTG|=(1<<CSX);
10
}
11
voidreadInternal(uint16_tData){
12
//WRX high, RDX steigende Flanke, CSX high
13
PORTD&=~(1<<RDX);
14
setData(Data);
15
_delay_us(2);
16
PORTD|=(1<<RDX);
17
_delay_us(2);
18
}
19
voidwritePar(uint16_tData){
20
//WRX steigende Flanke, RDX high, CSX high
21
PORTG&=~(1<<WRX);
22
setData(Data);
23
_delay_us(2);
24
PORTG|=(1<<WRX);
25
_delay_us(2);
26
}
27
voidreadPar(uint16_tData){
28
//WRX High, RDX steigende Flanke, CSX high
29
PORTD&=~(1<<RDX);
30
setData(Data);
31
_delay_us(2);
32
PORTD|=(1<<RDX);
33
_delay_us(2);
34
}
35
36
voidsetData(uint16_tData){
37
PORTC=(Data&0xff);
38
PORTA=((Data>>8)&0xff);
39
}
Außerdem habe ich nochmal den DS angehängt, ich würde weiterhin sagen,
dass dort kein Fehler ist.
Die Pegel von RST, RDX, CSX, WRX werden vor dem ersten Aufruf auf High
gesetzt.
Ich habe jetzt 2 Initalisierungsabläufe ausprobiert (die sich sehr
unterscheiden), funktionieren beide nicht.
Andreas S. schrieb:> Dann nimm doch die Sourcen als Beispiele und schau Dir dort> an wie es gemacht wird.> Man muss das Rad nicht zweimal erfinden.
Ich finde dort leider keine Initialisierung. Alles mögliche zum Zeichnen
aber keine Init. Kannst du mir bitte einen genaueren Ort nennen?
Martin schrieb:> Ich finde dort leider keine Initialisierung. Alles mögliche zum Zeichnen> aber keine Init. Kannst du mir bitte einen genaueren Ort nennen?
Appnote mit initialisierung:
https://www.jameco.com/Jameco/Products/ProdDS/2278271.pdf
Im Forum müssten für dich relevannte Threats vorhanden sein.
Arduinoquäler schrieb:> Die> _delay_ms(2);>> solltest du zu _delay_us machen sonst wirst du irgendwann ewig warten.>> Diese kurzen Delays sind für das Display durchaus ausreichend.
Ich kann zwar nur zum ILI9341 (sind alle ähnlich) eine Aussage machen,
aber der kommt bei mir mit einem Atmega328@20MHz, wenn man von der
Initialisierung absieht, sogar ganz ohne delays zurecht.
Martin schrieb:> Woran machst du das fest? Laut DS S. 27 ist bei write befehlen RS high.
Ich rate dir eher zu den detailierteren Grafiken, wie zum Beispiel auf
S.28/29.
Martin schrieb:> Ich finde dort leider keine Initialisierung. Alles mögliche zum Zeichnen> aber keine Init. Kannst du mir bitte einen genaueren Ort nennen?
Es ist wirklich unglaublich was da abgeht. Entweder bist du blind
oder völlig beratunsgresistent.
Arduinoquäler schrieb:> So wie im Anhang z.B. ....
-----------------------------------------------------------------
Martin schrieb:> Woran machst du das fest? Laut DS S. 27 ist bei write befehlen RS high.
Das ist auch so eine beratunsgresistente Darstellung, und sie
ist auch falsch. Ein einzelnes nacktes Kommando wird mit RS=1
geschrieben. Wenn das Kommando jedoch noch Daten als Folge-
parameter braucht dann wird danach noch RS=0 zum Schreiben
von Daten verlangt!
Ich schlage vor du schreibst nach deinem Gusto genau zwei
Funktionen WriteCmd() und WriteData() in denen du explizit die
Signale CS, WR, und RS korrekt in Abfolge setzt und diese beiden
Funktionen dann in einer Initialisierung verwendest.
Ich jedenfalls sehe in deinen Darstellungen von Sourcen keinerlei
Veränderung am Signal RS wenn du eine Abfolge von Kommando und
wechselweise Daten schreiben willst/sollst.
Deine readPar und writePar Funktionen löschst du einfach mal ganz.
Und lasse endlich das RDX weg, dieses Signal gibt es bei deinem
Display nicht.
Oh my god!
Hallo,
vielleicht mal allgemein: diese Displaycontroller sind sich ziemlich
ähnlich,was die Ansteuerung betriftt. Datenpins, 8 oder 16, die 16Bit
können auch oft im 8Bit-Mode betrieben werden, um Pins zu sparen.
CS als ChipSelect, manchmal auch CE ChipEnable zur Aktivierung des
Controllers, fall mehrere am Bus hängen. mUß fast immer bedient werden,
weil der Displaycontroller mit inaktiv werden von CS/CE erst die
Abarbeitung macht. RS (RegisterSelect), auch C/D für Command/Daten
Auswahl, ob ein Command- oder Datenbyte anliegt. Rd, WR oder RD/WR kann
einzeln oder kombiniert oder garnicht vorhanden sein, Wenn der
Controllertyp nicht gelesen werden kann, gibt es das auch nicht, ob RW
unbd WR einzeln oder kombiniert hängt davon ab, on der alte 8080 oder
der 6800 Bus Pate gestanden hat.
Für die genaue Abfolge gibt es in den Datenblättern immer
Timingdiagramme, für das ILI9486L in meinem Datenblatt z.B. auf Seite
212 für das 18/16/9( Bit Timing im 8080 Mode.
D/C richtig setzen, CS auf Low, Daten anlegen, WR auf Low, WR auf H (ab
hier werden die Daten übernommen), CS auf H Zyklus Ende.
Lesezyklus ist auch angeben.
Zeiten beachten, besonders der Lesezyklus ist recht langsam.
Der ILI9486L kann auch SPI, spart Pins, hängt aber davon ab, ob man das
Display als Board hat und alles Pins entsprechend beschalten kann oder
ob es z.B. ein Arduino Shiled ist, wo der Hersteller schon vorverdrahtet
hat und man die Betriebsart nehmen muß, die er gern wollte.
Parallelbeteieb macht an den kleinen AVR Sinn, damit es halbwegs schnell
bedient werden kann, an einen ESP8266/ESP32 nehme ich generell nur SPI,
das kann da schnell genug.
Der Kommandosatz ist im Datenblatt beschrieben, hilft aber nur bedingt,
weil es viele Abhängigkeiten der Einstellung gibt, um es überhautpt
erstmal in einen sinnvollen Zusatand zu bringen.
Irgendwo hat der Hersteller normalerweise auch Applikations-Dokus, mit
Beispielen, sind teilweise schwer zu finden, so das man meist auf das
zurückgreift, was ein anderer schon gemacht hat.
Ich habe mich vor Ewigleiten mal durch den T6963C gewühlt, weil es für
die AVR noch nicht viel dafür gab. Vorteil für mich ist: ich finde mich
heute relativ schnell durch ein Controller-Datenblatt durch, um was
bestimmtes zu finden.
Freiwillig nochmal würde ich das aber bei einem Controller wie dem
ILI9486L heutzutage nicht mehr machen, was kleines wie die einfarbigen
OLED ja, aber das kostet auch schon mehr Zeit als mir lieb ist.
Gruß aus Berlin
Michael
A. M. schrieb:> Martin schrieb:> Ich finde dort leider keine Initialisierung. Alles mögliche zum Zeichnen> aber keine Init. Kannst du mir bitte einen genaueren Ort nennen?>> Appnote mit initialisierung:> https://www.jameco.com/Jameco/Products/ProdDS/2278271.pdf>> Das ist auch so eine beratunsgresistente Darstellung, und sie> ist auch falsch. Ein einzelnes nacktes Kommando wird mit RS=1> geschrieben. Wenn das Kommando jedoch noch Daten als Folge-> parameter braucht dann wird danach noch RS=0 zum Schreiben> von Daten verlangt!
Das steht doch auch beides in der Grafik die aus dem Datenblatt stammt!
Da ist einmal Commando und Parameter. Wo sich RDX unterscheidet.
> Ich schlage vor du schreibst nach deinem Gusto genau zwei> Funktionen WriteCmd() und WriteData() in denen du explizit die> Signale CS, WR, und RS korrekt in Abfolge setzt und diese beiden> Funktionen dann in einer Initialisierung verwendest.>> Ich jedenfalls sehe in deinen Darstellungen von Sourcen keinerlei> Veränderung am Signal RS wenn du eine Abfolge von Kommando und> wechselweise Daten schreiben willst/sollst.>> Deine readPar und writePar Funktionen löschst du einfach mal ganz.> Und lasse endlich das RDX weg, dieses Signal gibt es bei deinem> Display nicht.>> Oh my god!
Natürlich gibt es RDX, es gibt kein RS, das hat sich irgendwer
ausgedacht, der die Platine beschriftet hat. Im Datenblatt ist immer von
RDX die Rede, daher wird es auch weiterhin so in der SW heißen. RS gibt
es nicht, ob my god! Lass es doch bitte einfach hier zu schreiben,
bisher warst du 0 hilfreich.
A. M. schrieb:> Martin schrieb:> Ich finde dort leider keine Initialisierung. Alles mögliche zum Zeichnen> aber keine Init. Kannst du mir bitte einen genaueren Ort nennen?>> Appnote mit initialisierung:> https://www.jameco.com/Jameco/Products/ProdDS/2278271.pdf>
Danke, der Link sieht hilfreich und offiziell aus. Merkwürdig dass zum
Beispiel F2 nicht im Datenblatt als Kommando auftritt.
Martin schrieb:> Natürlich gibt es RDX, es gibt kein RS, das hat sich irgendwer> ausgedacht, der die Platine beschriftet hat.
Oh my god!
Martin schrieb:> Natürlich gibt es RDX
Ein RDX Signal (das ist der Lese-Strobe) ist auf deinem Board
nicht nach aussen geführt da du das Display nicht lesen kannst.
Die Buffer auf dem Board haben keine Richtungsumschaltung für
die Datenleitungen.
Martin schrieb:> es gibt kein RS
Ein RS Signal (das ist der Data/Command Selector) brauchst du damit
du beim Schreiben in die Display-Register zwischen Daten und
Kommando unterscheiden kannst. Dieses Signal ist auch vorhanden.
Martin schrieb:> Lass es doch bitte einfach hier zu schreiben,
Den Gefallen tu ich dir gerne.
Bei soviel Starrsinn und Beratungsresistenz bin ich dann mal weg.
Das hab ich schon lang nicht mehr erlebt.
Moin,
ich hab mich gerade nochmal rangesetzt und nun auch meinen Fehler
gemerkt. Sorry für die harschen Worte vorher @Arduinoquäler, mir gehts
momentan nicht so mega gut.
Ich hab nun verstanden das RSX ungleich RS und der RS im DS als DCX
benannt ist. Ich habe nun die beiden write funktionen angepasst, laut
http://www.lcdwiki.com/3.5inch_Arduino_Display-Mega2560 ist der RS/ DCX
invertiert gegenüber dem Datenblatt. Ich habe beide Richtungen probiert,
da passiert leider garnichts.
Folgend der aktuelle Stand, ich erwarte eigentlich 2000 farbige Pixel,
davon ist leider nichts zu sehen. Auf den Signalleitungen ist allerdings
viel traffic, die Timingzeiten überschreite ich auch bei weitem.
Als Initsequenz habe ich die erste aus der Appnote
https://www.jameco.com/Jameco/Products/ProdDS/2278271.pdf übernommen.
Testweise auch die 2. für den Treiber, macht aber bisweilen keinen
Unterschied.
1
#define F_CPU 16000000
2
#define DB0 PC0
3
#define DB1 PC1
4
#define DB2 PC2
5
#define DB3 PC3
6
#define DB4 PC4
7
#define DB5 PC5
8
#define DB6 PC6
9
#define DB7 PC7
10
#define DB8 PA0
11
#define DB9 PA1
12
#define DB10 PA2
13
#define DB11 PA3
14
#define DB12 PA4
15
#define DB13 PA4
16
#define DB14 PA5
17
#define DB15 PA6
18
#define WRX PG2 //WR <- Bezeichnung Platine
19
#define DCX PD7 //RS <- Bezeichnung Platine invertiert zum DS
Martin schrieb:> #define DB12 PA4> #define DB13 PA4
Aha. Listen und Schleifen verwenden ist wohl zu viel Aufwand. Dann schon
lieber einfache C&P-Fehler.
leo