Xv-tft60d 3.3v

[Sany1984]

Hallo,

Habe mir ein XV-TFT60D Display gekauft und möchte das mit einem AtXmega128A1 im 3.3v modus betreiben, nun habe ich im Datenblatt gelesen für den 3.3V betrieb muss ich 2 Lötbrücken schließen und Widerstände auslöten?

Ist das richtig?

Grüße
Sany.

 

[Dirk]

Hallo Sany,

ja genau.

R1, R2 und R3 (0Ohm Widerstände) entfernen und
SJ1 und SJ2 zulöten.

Dirk

 

[Sany1984]

Hallo Dirk,

Danke für die fixe antwort
Dann reicht es ja eigtl. die Brücken mit zwei SMD brücken zu bestücken

Das ganze sollte dann falls man es mit 5V betreibt wieder Rückgängig gemacht werden?


Grüße,
Daniel

 

[Dirk]

Hallo Daniel,

du kannst für SJ1 und SJ2 natürlich SMD-Brücken (0Ohm-Widerstände) nehmen. Einfacher geht es aber, wenn du die Pads einfach kurz zulötest. Die 0Ohm-Widerstände bei R1, R2 und R3 musst du aber entfernen. Dann kannst du das Displaymodul mit 3,3V am XmegaA1 betreiben. Dann aber bitte nicht mehr mit VCC 5V betreiben

Den Blog-Bereich von mir zu den Displays kennst du wahrscheinlich schon

Zu den Displays findest du Beispielsoftware (auch für Xmega) in meinem Blog (C Atmel Studio, Cpp Arduino beides von mir, Lösungen mit BascomAVR gibt es auch), dies hast du aber bestimmt schon gesehen.

Dirk

 

[Sany1984]

Hallo Dirk,

Danke, läuft alles Prima.

Vielleicht hast du ja aber evtl. noch ein Tipp bezüglich einem Gehäuse für das Display?

Grüße,
Daniel

 

[Dirk]

Hallo Daniel,

bezüglich einem Gehäuse kann ich dir leider keinen Tipp geben. Für das 5,7" TFT wird es eher etwas fertiges geben, da diese Größe oft in der Industrie eingesetzt wird, bei den anderen Größen ist es sicher etwas schwieriger.

Wir hatten uns auch schon überlegt, ein schönes Standard-Gehäuse (zum Beispiel von Bopla) im Shop aufzunehmen und dafür jeweils für eine Displaygröße eine passende Frontblende. Aber die muss ja auch erst mal gezeichnet und gefertigt werden

Dirk

 

[dino03]

Hallo,

Wir hatten uns auch schon überlegt, ein schönes Standard-Gehäuse (zum Beispiel von Bopla) im Shop aufzunehmen und dafür jeweils für eine Displaygröße eine passende Frontblende. Aber die muss ja auch erst mal gezeichnet und gefertigt werden

wenn man solche Frontblenden als Spritzguß machen lassen will, dann kann man die bei Stückzahlen um 100Stk pro Größe auch gleich aus Gold fräsen So eine Spritzgußform kostet auch ne ganze Menge Da kann man eher was aus nem Kunststoffklotz fräsen. Wenn man aber die Fräsdauer und Maschinenkosten, Einrichtkosten, ... rechnet, dann bringt das auch wieder nix. Also ist es wohl am wirtschaftlichsten wenn man Blenden findet die bereits die richtige Größe haben. Oder man nimmt ein Gehäuse und schnitzt sich selber den benötigten Ausschnitt da rein (so wie ich).

Gruß
Dino

 

[Sany1984]

Hallo ;-)

Ich dachte da auch vornehmlich an ein Plastikgehäuse

So nun hab ich aber ein Problem, ich weiß nicht ob es ein Software Problem ist oder ein Hardware Problem...

Und zwar ich habe den aktuellen Xmega Code auf einem 128A1-AU laufen im Hardware SPI, Internem Osc. 32 Mhz und DISPLAY_SPI_SPEED_FCPU_DIV 16
Soweit so gut, nun stelle Ich fest, das wenn ich den Xmega per Software oder über JTAG resette, zwar das Displ. initialisiert wird, aber nach anschalten des Backlights taucht das was zuvor auf dem Display Stand wieder auf oder wird teilweise nicht überschrieben.

Was mir auch noch aufgefallen ist, ab und an Zeigt das Display nichts mehr an außer einem weißen Hintergrund... nach trennen der Versorgungsspannung funktioniert das ganze wieder, oder das Display bleibt einfach schwarz oder zeigt nur den halben Text an, obwohl der ans Display übertragen wird...?


Danke
Grüße, Daniel

 

[Dirk]

Hallo Daniel,

hmmm, also das Display wird in meinen Beispielprojekten nicht initialisiert (den Bereich SoftwareReset habe ich auskommentiert, damit die Demo ohne Unterbrechung läuft). Das Display initialisiert sich nach Poweron, dafür benötigt es etwa 300ms. Das erste was ich nach Reset mache ist, Initialisierung abwarten und Backlight anschalten. Da ja kein SoftwareReset ausgeführt oder der Bildschirm manuell "gelöscht" wird, bleibt der Inhalt natürlich bestehen. Ein JTAG-Reset bekommt das Display nicht mit.

Aufpassen muss man, wenn nicht gewährlsitet werden kann, dass Signale definierte Zustände haben. Das kann während der Programmierung des Mikrocontrollers vorkommen. Bei AVR Mega kann es dann Probleme geben kann, wenn ISP-Programmierung auch über SPI läuft (MISO/MOSI = PDI/PDO). In diesem Fall muss man dann am CS\ Signal einen Pullup-Widerstand vorsehen, damit das Display nicht während der Programmierung (CS\ vom AVR ist hochohmig, Input und nicht definiert) selektiert wird. Eventuell könntest du das bei dem Xmega auch mal probieren. Ansonsten noch die SPI-Leitungen nicht zu lang wählen. Mehr fällt mir im Moment leider nicht ein.

Dirk

 

[Sany1984]

Hallo Dirk,

Danke für deine Antwort!
Leider lässt sich mein Problem nicht wirklich identifizieren.
Nach dem einschalten bleibt das Display schwarz, aber die SPI Ports funktionieren da das RFM70 Modul korrekt sendet und empfängt.

Hab nun nach dem Display init schon ein Delay von 1 Sek. drin...

Aber mal was anderes, mich ärgert es gerade wenn ich ein Hintergrund Bild lade, darüber einen Text mittels DisplayText drüber setzten möchte, das um den Text ein weißer Kasten ist, was bei Hintergründen mit Farbverlauf ziemlich doof kommt... Gibt's ne Möglichkeit das abzustellen ?!?


Grüße,
Daniel

 

[Dirk]

Hallo Sany,

Leider lässt sich mein Problem nicht wirklich identifizieren.
Nach dem einschalten bleibt das Display schwarz, aber die SPI Ports funktionieren da das RFM70 Modul korrekt sendet und empfängt.

Hab nun nach dem Display init schon ein Delay von 1 Sek. drin...

ich weiß nun nicht genau wann das Problem auftritt. Nach der Programmierung über JTAG, oder grundsätzlich nach dem Einschalten (power on)?
Hast du meinen Rat befolgt, im CS\ Signal einen Pullup-Widerstand einzubauen, damit das Signal bei der Programmierung definiert high ist und nicht hochohmig und ggf. low wird.

Hast du F_CPU global definert? Werden Warnings angezeigt?

Du schreibst "nach dem Display init". Führst du Display_SoftwareReset() aus? Das Display initialisiert sich nach PowerOn selber. Du musst das Kommando eigentlich garnicht ausführen. Du führst es dann aus, wenn du Konfigurationseinstellungen wie PenColor, BrushColor, Displaymode usw. mit einem Kommando auf Standartwerte setzen möchtest. Wenn du nach Reset des Xmega keine Grafik von zuvor auf dem Displa haben möchtest, reicht ein Display_FillScreen_.

Aber mal was anderes, mich ärgert es gerade wenn ich ein Hintergrund Bild lade, darüber einen Text mittels DisplayText drüber setzten möchte, das um den Text ein weißer Kasten ist, was bei Hintergründen mit Farbverlauf ziemlich doof kommt... Gibt's ne Möglichkeit das abzustellen ?!?

Wir haben hier PenColor und BrushColor. PenColor ist die Schriftfarbe, BrushColor ist die Hintergrundfarbe des Textes. BrushColor "durchsichtig" zu wählen, geht nicht. (Dies wird es sicherlich in der nächten Generation geben, da läuft dann vielleicht auch Android auf dem Display.) Wähle vielleicht am besten für BrushColor eine möglichst ähnliche Farbe, die auch das Hintergrundbild hat, oder überdenke, ob ein Hintergrundbild überhaupt notwendig ist.

Dirk

 

[Sany1984]

Hallo Sany,


ich weiß nun nicht genau wann das Problem auftritt. Nach der Programmierung über JTAG, oder grundsätzlich nach dem Einschalten (power on)?
Hast du meinen Rat befolgt, im CS\ Signal einen Pullup-Widerstand einzubauen, damit das Signal bei der Programmierung definiert high ist und nicht hochohmig und ggf. low wird.

Hast du F_CPU global definert? Werden Warnings angezeigt?

Du schreibst "nach dem Display init". Führst du Display_SoftwareReset() aus? Das Display initialisiert sich nach PowerOn selber. Du musst das Kommando eigentlich garnicht ausführen. Du führst es dann aus, wenn du Konfigurationseinstellungen wie PenColor, BrushColor, Displaymode usw. mit einem Kommando auf Standartwerte setzen möchtest. Wenn du nach Reset des Xmega keine Grafik von zuvor auf dem Displa haben möchtest, reicht ein Display_FillScreen_.




Wir haben hier PenColor und BrushColor. PenColor ist die Schriftfarbe, BrushColor ist die Hintergrundfarbe des Textes. BrushColor "durchsichtig" zu wählen, geht nicht. (Dies wird es sicherlich in der nächten Generation geben, da läuft dann vielleicht auch Android auf dem Display.) Wähle vielleicht am besten für BrushColor eine möglichst ähnliche Farbe, die auch das Hintergrundbild hat, oder überdenke, ob ein Hintergrundbild überhaupt notwendig ist.

Dirk

Hallo Dirk,

Also, das Problem stellt sich wie folgt dar, habe dein Rat mit dem Pullup befolgt und ein 10K eingebaut, leider ohne erfolg.

Also nach dem einstecken der Spannungsversorgung blinkt das Display kurz, wird kurz weiß dann wieder dunkel und bleibt dann auch dunkel.
Wenn ich nun mittels Jtag (nutze nichts anderes) den Code im Main stoppe und dann durchlaufen lasse funktioniert das Display...

Daher war meine Vermutung, das evtl. etwas mit dem Internen 32Mhz Takt nicht passt, aber dann habe ich aber gesehen, das auch wenn das Display schwarz ist, der Code selbst läuft, da das RFM70 Ordnungsgemäß Daten sendet und der SPI auch richtig initialisiert wird sowie auch die System Clock.

main.c:

#include <asf.h>
#include <stdio.h>
#define F_CPU 32000000UL

#include <util/delay.h>
#include <avr/interrupt.h>
#include "rfm70/rfm70.h"
#include "display/display.h"

int main (void)
{
	uint16_t buffer[32];
	system_clocks_init();
	sei();
	
	Display_Init();
	_delay_ms(300);
	
	while(DISPLAY_IS_BUSY) {}
	
	uint8_t i = 0;
	do {
		i++;
		Display_SetBacklightIntensity(i);
		_delay_ms(5);
	} while(i < 255);
	
	Begin();
	setMode(1);
	setChannel(9);
	configRfPower(3);
	// Insert application code here, after the board has been initialized.

	while(1)
	{
		if(receivePayload(buffer))
		{
		}
	}
}

void system_clocks_init(void)
{
	unsigned char n,s;
	// Optimize for speed
	#pragma optsize-
	// Save interrupts enabled/disabled state
	s=SREG;
	// Disable interrupts
	cli();

	// Internal 32 kHz RC oscillator initialization
	// Enable the internal 32 kHz RC oscillator
	OSC.CTRL|=OSC_RC32KEN_bm;
	// Wait for the internal 32 kHz RC oscillator to stabilize
	while ((OSC.STATUS & OSC_RC32KRDY_bm)==0);

	// Internal 32 MHz RC oscillator initialization
	// Enable the internal 32 MHz RC oscillator
	OSC.CTRL|=OSC_RC32MEN_bm;

	// System Clock prescaler A division factor: 1
	// System Clock prescalers B & C division factors: B:1, C:1
	// ClkPer4: 32000,000 kHz
	// ClkPer2: 32000,000 kHz
	// ClkPer:  32000,000 kHz
	// ClkCPU:  32000,000 kHz
	n=(CLK.PSCTRL & (~(CLK_PSADIV_gm | CLK_PSBCDIV1_bm | CLK_PSBCDIV0_bm))) |
	CLK_PSADIV_1_gc | CLK_PSBCDIV_1_1_gc;
	CCP=CCP_IOREG_gc;
	CLK.PSCTRL=n;

	// Internal 32 MHz RC osc. calibration reference clock source: 32.768 kHz Internal Osc.
	OSC.DFLLCTRL&= ~(OSC_RC32MCREF1_bm | OSC_RC2MCREF_bm);
	// Enable the autocalibration of the internal 32 MHz RC oscillator
	DFLLRC32M.CTRL|=DFLL_ENABLE_bm;

	// Wait for the internal 32 MHz RC oscillator to stabilize
	while ((OSC.STATUS & OSC_RC32MRDY_bm)==0);

	// Select the system clock source: 32 MHz Internal RC Osc.
	n=(CLK.CTRL & (~CLK_SCLKSEL_gm)) | CLK_SCLKSEL_RC32M_gc;
	CCP=CCP_IOREG_gc;
	CLK.CTRL=n;

	// Disable the unused oscillators: 2 MHz, external clock/crystal oscillator, PLL
	OSC.CTRL&= ~(OSC_RC2MEN_bm | OSC_XOSCEN_bm | OSC_PLLEN_bm);

	// Lock the CLK.CTRL and CLK.PSCTRL registers
	n=CLK.LOCK | CLK_LOCK_bm;
	CCP=CCP_IOREG_gc;
	CLK.LOCK=n;

	// ClkPer output: Disabled bit 7
	PORTCFG.CLKEVOUT=(PORTCFG.CLKEVOUT & (~PORTCFG_CLKOUT_gm)) | PORTCFG_CLKOUT_OFF_gc;

	// Restore interrupts enabled/disabled state
	SREG=s;
	// Restore optimization for size if needed
	#pragma optsize_default
}

config.h:

#define DISPLAY_MODULE_WIDTH 272
#define DISPLAY_MODULE_HEIGHT 480

#define DISPLAY_USE_TOUCHPANEL	true
#define DISPLAY_SPI_MODE_HARDWARESPI true

#define DISPLAY_SPI_PORT         PORTF
#define DISPLAY_SPI_MODULE       SPIF	      // Hardware SPI module
#define DISPLAY_SPI_MISO         PIN6
#define DISPLAY_SPI_MOSI         PIN5
#define DISPLAY_SPI_SCK          PIN7

#define DISPLAY_SPI_SPEED_FCPU_DIV 32

#define DISPLAY_CONTROL_PORT     PORTF
#define DISPLAY_SIGNAL_BUSY      PIN0
#define DISPLAY_PINCTRL_BUSY     PIN0CTRL
#define DISPLAY_SIGNAL_CS        PIN4
#define DISPLAY_SIGNAL_TINT      PIN1
#define DISPLAY_PINCTRL_TINT     PIN1CTRL

Grüße Daniel.

 

[Dirk]

Hallo Sany,

mach doch bitte mal testweise folgendes (vielleicht eins nach dem anderen), vielleicht läßt sich die Ursache so eher eingrenzen:

(1) Ich gehe davon aus, deine Systemclock-Initialisierung wird schon richtig sein (da müsste ich nun auch länger nachschauen, um das zu prüfen), aber testweise kommentiere doch einmal system_clock_init() aus. Der Microcontroller läuft dann mit 2MHz. (musst nur berücksichten dass nun _delay_ms(300) viel länger läuft, korrigiere hier vielleicht F_CPU. Definiere auch mal F_CPU global, also in den Projekteinstellungen, F_CPU wird auch in display.c und display.h benötigt).

(2) Vor Begin() füge eine while(1) Schleife ein, damit der folgende Code nicht ausgeführt wird. Und schaue, ob das Backlight nun an bleibt. Du kannst auch mal sei() auskommentieren, Interrupts benötigst du nicht.

(3) Prüfe auch einmal die Betriebsspannung, wenn das Backlight eingeschaltet wird, steigt sprunghaft der Strom. Eventuell gibts hier einen zu starken "Einbruch" der Spannung, das Display könnte hier einen PowerOn Reset ausführen, der Xmega wird sicher weiterlaufen (er läuft ja auch bei 1,6V), es sei denn, du hast BOD (Fusebits) ziemlich hoch eingestellt. Prüfe auch gleich mal, ob beide VCC und beide GND Leitungen angeschlossen sind. Überprüfe auch, ob dein Spannungsregler für den Strom des Displays ausgelegt ist.

(4) Teste auch einmal ohne angeschlossenen JTAG-Programmer.


Dirk

 

[dino03]

Hallo,

(3) Prüfe auch einmal die Betriebsspannung, wenn das Backlight eingeschaltet wird, steigt sprunghaft der Strom. Eventuell gibts hier einen zu starken "Einbruch" der Spannung, das Display könnte hier einen PowerOn Reset ausführen, der Xmega wird sicher weiterlaufen (er läuft ja auch bei 1,6V), es sei denn, du hast BOD (Fusebits) ziemlich hoch eingestellt. Prüfe auch gleich mal, ob beide VCC und beide GND Leitungen angeschlossen sind. Überprüfe auch, ob dein Spannungsregler für den Strom des Displays ausgelegt ist.

das ist mir auch so eingefallen. Meißt sind bei solchen "komischen" Fehler irgendwo die Abblock-Kondensatoren nicht vorhanden. Sind am Anschluß zum Display so 100-220µF dran und noch ein Keramik mit 100nF (bei mir ist noch nen Keramik mit 1µF dran)? Je nachdem wie du den XMega betreibst (Modul, eigene Platine, ...) sollte er auch ein paar Kondensatoren haben. Wegen kleinerem Strom muß es aber kein 100µF sein. Da würden 22µF reichen. Eventuell bekommt das Display durch fehlende Siebung/Abblockung Probleme mit Spannungseinbrüchen.

Gruß
Dino