SPI Verbindung Display

Frank schrieb:
> Beim Atmega16 habe ich SS nie in der Software gesetzt, also muss das
> automatisch geschehen? Im Datenblatt steht dann nochmal ein
> Codebeispiel, wo SS auch nicht gesetzt wird.

Aber sicherlich hat irgendein anderer Pin dafür gesorgt dass
der Slave ein CS bekommen hat. Es muss ja nicht der SS sein.

Frank schrieb:
> Eine weitere Änderung ist, dass ich das Display jetzt an einen 2m langen
> abgeschirmeten Kabel angeschlossen habe.

Das wird nur mit viel Glück funktionieren.

Dann noch: Wenn dein Controller mit 5V versorgt wird, prüfe ob
dein Display das auch verträgt (Vcc und LED).

> jetzt an einen 2m langen abgeschirmeten Kabel

Zumindest das Problem kommt mit bekannt vor. Mit langsamen Bitbang SPI 
und Tiefpass vor den Eingängen bekommt man es zum laufen.

Erster Schritt: Eine der beiden Änderungen rückgängig machen. Langes 
Kabel an der alten Mega16 Platine oder kurze Drähte an der neuen 
Platine.

AVCC und AGND müssen angeschlossen werden:

AVCC is the supply voltage pin for the A/D Converter, PC3:0, and ADC7:6. 
It should be externally connected to VCC,
even if the ADC is not used.

Wieso geht MISO vom Display nicht an MISO vom Atmega?

holger schrieb:
> Wieso geht MISO vom Display nicht an MISO vom Atmega?

Weil das Display nichts sendet.  Dein Programm liest nie Daten aus dem 
Display zurück, dann braucht es auch nie die Datenrichtung 
Slave->Master.

Frank schrieb:

> Den Microcontroller über SPI programmieren kann ich

Nein, kannst du nicht. Wenn, dann über ISP. Nur mehr oder weniger 
zufällig werden die Pins bei vielen AVRs zwischen ISP und SPI geshared. 
Es hat aber ansonsten rein garnix miteinander zu tun.

> Beim Atmega16 habe ich SS nie in der Software gesetzt, also muss das
> automatisch geschehen?

Ganz sicher nicht. Auch nicht beim Mega16. Bezüglich der SPI-Hardware 
gibt es praktisch keine funktionalen Unterschiede zwischen den 
verschiedenen ATmegas. Nur die Pin-Zuordnungen und die Registeraddressen 
variieren. Bei keinem ATmega passiert mehr automatisch bezüglich des 
SS-Pins als im Datenblatt beschrieben. Bei der Anwendung als Master also 
exakt garnix, höchstens, dass die SPI-Hardware aus der Master-Rolle 
rausgeschossen wird, wenn der Pin als Eingang konfiguriert ist und ein 
Low zu sehen bekommt...

> Im Datenblatt steht dann nochmal ein
> Codebeispiel, wo SS auch nicht gesetzt wird.

Lies' das DB (zumindest den Abschnitt SPI) vollständig und du verstehst, 
was der Beispielcode tut und was er eben nicht tut (insbesondere das 
Handling von SS). Das steht nämlich wirklich explizit da, im Absatz 
direkt vor dem Beispielcode. Womit du dich als stinkendfauler Nichtleser 
des DB und geoutet hast...

c-hater schrieb:
> Ganz sicher nicht. Auch nicht beim Mega16. Bezüglich der SPI-Hardware
> gibt es praktisch keine funktionalen Unterschiede zwischen den
> verschiedenen ATmegas. Nur die Pin-Zuordnungen und die Registeraddressen
> variieren. Bei keinem ATmega passiert mehr automatisch bezüglich des
> SS-Pins als im Datenblatt beschrieben. Bei der Anwendung als Master also
> exakt garnix, höchstens, dass die SPI-Hardware aus der Master-Rolle
> rausgeschossen wird, wenn der Pin als Eingang konfiguriert ist und ein
> Low zu sehen bekommt...

Was ich meinte ist, dass ich den SS angeschlossen habe und im Register 
als Ausgang festgelegt habe.
Ich habe mich aber nie irgendwo im Programm darum gekümmert, den auf LOW 
zu ziehen, um den Slave anzusprechen. Das wurde bisher immer automatisch 
vorgenommen. Es steht aber im DB, dass bevor die Kommunikation gestartet 
werden soll ich das in der Software realisieren soll. Das habe ich nie 
getan.

"When configured as a Master, the SPI interface has no automatic control
of the SS line. This must be handled by user software before
communication can start. When this is done, writing a byte to the SPI
Data Register starts the SPI clock generator, and the hardware shifts
the eight bits into the Slave. "