S65 an USART-SPI beim ATmega644P

[elral (Gast)]

Hallo zusammen,

seit wenigen Wochen beschäftige ich mich der interessanten Welt der 
AVR's, bin also ziemlich neu in dem Gebiet. Programmieren versuche ich 
mittels C, Restwissen von Basic aus Commondore/Zinclair Zeiten sind 
vorhanden, Assembler aus den Zeiten davor eigentlich nicht mehr. Also 
alles in allem recht blutiger Anfänger.
Nun stehe ich vor einem "Problem", bei dem ich doch nicht weiter komme.

Für ein Projekt wollen wir ggf. das S65 Display als Anzeige benutzen, 
dazu habe ich mir auch schon reichlich Informationen hier anlesen 
können. In einem ersten Schritt habe ich das S65 am SPI angeschlossen, 
wie ich es bisher auch immer gesehen habe. Nach anfänglichen 
Schwierigkeiten (Modifikation der SW von Marc Seiffert, Juergen Eckert, 
Christian Kranz) läuft es stabil.

Da wir aber den AVR als SPI-Slave ansteuern wollen um den Hauptprozessor 
zu entlasten, habe ich in einem nächsten Schritt das S65 am USART als 
SPI des ATmega644P angeschlossen.
Dazu ist die USART folgendermassen initialisiert:

UBRR1 = 0;        //must be zero berfore initialization, see also ApNote317
OUTPUT(LCD_SCK);  //set XCK1/SCK as output to enable Master Mode
UCSR1C = (1<<UMSEL11) | (1<<UMSEL10);  //set MSPI mode of operation and SPI data mode 0
UCSR1B= (1<<TXEN1); //Enable transmitter, RX1 can be used as normal I/O
UBRR1= 7;        //sets baud to 16Mhz/(2*(1+UBRR1) = 16MHz / 8 = 1MHz

Die Daten werden folgendermassen ausgegeben:

CLR(LCD_CS);        //select Display
SET(LCD_RS);        //Daten sind Befehle
for(uint8_t i=0; i<size; i++){
  UDR1 = (data[i]>>8);
  SPI_Wait();
  UDR1 = (data[i]);
  SPI_Wait();
}
while (!(UCSR1A & (1<<TXC1)));    //wait for transmission complete, as USART in SPI mode uses the buffer!
CLR(LCD_RS);        //First RS to Low, then
SET(LCD_CS);        //CS to H for processing of commands

Mit dem Befehl UBBR1=7 bekomme ich das Display nicht ans laufen, 
ebenfalls bei UBBR1=1, was einer SPI Frequenz von 4MHz entsprechen 
würde. Eigentlich immer wenn UBBR1 > 0 gesetzt wird. Nur mit UBBR1=0 
läuft es einwandfrei.
Testweise habe ich den ATmega auf 8MHz intern umgestellt (entspricht ja 
dann UBBR1=1 bei 16MHz), auch hier der gleiche Effekt, nur bei UBBR1=0 
läuft das Display. An der Taktfrequenz der SPI kann es also nicht 
liegen. Beim Anschluss an die "richtige" SPI kann ich auch die Taktrate 
deutlich nach unten setzen, ohne dass es Probleme mit dem Display gibt.

Hat jemand da eine Idee, woran das liegen könnte? Das Timing der SPI 
düfte doch eigentlich nicht von der Einstellung von UBBR1 abhängig sein.
Oder initialisiere ich die USART als SPI mit UBBR1=1...7 als letzten 
Befehl doch falsch?

Über Hinweise würde ich mich freuen.

Grüße

Ralf

[Thomas Schattat (Gast)]

Hallo,
ich habe das S65 mit einem Atmega8 am SPI am Laufen. In der Anlage hab 
ich mal ein paar Funktionen aus meinem Code zusammengestellt, das sieht 
man wie der SPI initialisiert werden muss und wie man Daten und 
Kommandos zum LCD schickt.
Taktfrequenz ist 18MHz, als recht zügig.

Hoffe das hilft,
Gruss

Thomas

[Thomas Schattat (Gast)]

Oh, da fehlte etwas, hoffe es ist nun vollständig.

[spess53 (Gast)]

Hi

Ich kenne das Display nicht direkt. Wird das nur über SPI gesteuert, 
oder gibt es noch zusätzliche Steuerleitungen?

MfG Spess

[Thomas Schattat (Gast)]

Siehe hier:

http://superkranz.de/christian/S65_Display/DisplayIndex.html

Der Christian hat das genau dokumentiert.
Ich nutze übrigens das SHARP LCD, die anderen sind anders..

Gruss

Thomas

[elral (Gast)]

Hallo Thomas,

danke für die Hinweise, genau so initialisiere ich das Display ja auch. 
Es funktioniert auch am "USART-SPI", wenn ich die maximale 
Geschwindigleit mittels UBBR1=0 einstelle. Wähle ich aber eine geringere 
Geschwindigkeit mittels UBBR1>0 (also =1, =2, ...), dann kann ich es 
nicht mehr ansprechen. Die Frage ist also eher auf die Initialiseirung 
der "USART-SPI" bezogen (mehr Interesse halber, aber man weiss ja nie 
wofür man das brauchen kann). Die "richtige" SPI kann ich nicht 
benutzen, da der ATmega darüber als Slave Grafikbefehle empfangen soll. 
Dieser ist Teil eines größeren Projektes um den Hauptprozessor zu 
entlasten.

Danke und Grüße

Ralf