Atmega32 und MAX7219

[Fadel (fadelsikh)]

Hallo,

ich habe leider ein problem mit dem Programieren meines MAX7219 über
einen Atmega32.

Die Ports lassen sich allesammt beschalten, also auf 0 oder 1 setzen
(nachgemessen).


Achja angeschlossen sind je 8 7-Segmentanzeigen, die ich auch schon
einzeln (mit einem max verbaut) ansprechen konnte.

Vielleicht kann mir jemand von euch helfen.
viel Grüße

[Maxim B. (max182)]

Ich glaube, dein Problem ist in "serial_write". Du machst ~CS nach jedem 
Byte wieder hoch. Du solltest zwei Bytes mit ~CS=0 übertragen und erst 
danach ~CS=1.

Allerdings ist viel bequemer und auch schneller MAX7219 über SPI zu 
schalten.

[S. L. (sldt)]

Wie wäre es, wenn Sie erstmal eine Rückmeldung zum TM1637 gäben?

[S. L. (sldt)]

Maxim B. schrieb:
> Du machst ~CS nach jedem Byte wieder hoch.

Nicht nur das: bei Fadel besteht ein Byte aus 9 Bits.

[Wastl (hartundweichware)]

S. L. schrieb:
> Nicht nur das: bei Fadel besteht ein Byte aus 9 Bits.

Mehr ist doch immer besser als weniger.

[Veit D. (devil-elec)]

Maxim B. schrieb:
> Ich glaube, dein Problem ist in "serial_write". Du machst ~CS nach jedem
> Byte wieder hoch. Du solltest zwei Bytes mit ~CS=0 übertragen und erst
> danach ~CS=1.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Das Setzen von CS-Signal scheint doppelt gemoppelt zu sein und wird so 
nicht funktionieren – im Anhang ein Screenshot diesbezüglich. Am besten 
auch wie dafür vorgesehen die SPI-Schnittstelle benutzen und keine 
Softwarenachbauten inszenieren, sofern eine verfügbar ist, denn da kann 
man sich beim Codeschreiben auch zusätzliche Fehler einbauen.

[Reinhard R. (reirawb)]

Und aus der 9 eine 8 machen.

Das steht aber schon beides in vorhergehenden Beiträgen.

[Fadel (fadelsikh)]

S. L. schrieb:
> Wie wäre es, wenn Sie erstmal eine Rückmeldung zum TM1637 gäben?

Ich entschuldige mich ich habe keine Nachrichte Bekommen.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Und am Ende den 'clkpin' wieder auf Low setzen, damit das 
selbstgebastelte SPI-Protokoll auch einigermaßen konsistent bleibt.

[Fadel (fadelsikh)]

Vielen Dank für die Alle,es hat geklappt

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Durch das 1µs-Delay, das durch die Schleife auch noch wiederholt und 
somit multipliziert wird, wird unnötig extrem viel Rechenleistung eines 
AVRs verschenkt/vergeudet – bei 16MHz sind es 16 einfache Befehle bei 
jedem Schleifendurchlauf, die hier immer unnötig ausgeführt werden. 
Selbst wenn der µC mit seinen maximalen 20MHz laufen, der CLK-Pin ganz 
normal mit einem Push-Pull-Ausgang über normale Distanz (bis 20cm) 
gesteuert und man cbi/sbi-Befehle direkt hintereinander für das Setzen 
und Löschen des Pins verwenden würde, wäre das Timing – max. 10MHz – als 
Clockfrequenz für den CLK-Pin des MAX7219 gewahrt, denn ein sbi- oder 
cbi-Befehl dauert bei 20MHz genau mindestens 50ns, bei 16MHz sind es 
sogar schon 62,5ns. Man kann das Delay durch ein 'asm volatile ("nop");' 
ersetzen, wenn man auf Nummer sicher gehen möchte, aber durch den 
Schiebe- und Sprungbefehl innnerhalb der For-Schleife im Code werden 
bereits weitere Takte zwischen 'max_port |=(1<<clkpin);' und 'max_port 
&=~(1<<clkpin);' eingelegt, so dass hier normalerweise überhaupt keine 
zusätzliche Verzögerung dazwischen nötig sein dürfte.

Den vom Compiler an dieser Stelle generierten Assemblercode in der 
.lss-Datei kann man (oder sollte man) sich aber dazu anschauen und sich 
selbst davon überzeugen, ob und wie es tatsächlich auf der 
Assemblerebene taktmäßig aussieht, sofern man überhaupt in der Lage ist, 
ihn zu verstehen, ansonsten macht es natürlich überhaupt keinen Sinn, 
diese Datei zu öffnen; auch mal direkt am MAX7219-CLK-Pin die Sonde 
eines Oszilloskops anschließen und den Signalverlauf mit seinen Flanken 
anschauen ist immer sinnvoll, um sich zu vergewissern, dass das Signal 
am Ende der Leitung sauber ankommt – sollte der MAX sehr weit vom µC 
entfernt (z.B. 2m) und somit die Steuerleitungen extrem lang sein, 
könnte man es mit einem 27 bis 47Ω-Widerstand als Terminierung versuchen 
zu kompensieren und zu verbessern, was bei kurzen Distanzen bis 20cm 
aber normalerweise nicht nötig ist.

Das ist nur als Optimierung für „Profis” gedacht und hat mit dem 
Funktionieren des Codes selbstverständlich nichts zu tun. Es gibt hier 
im Codeaufbau bestimmt noch mehr Optimierungspotenzial, aber ich belasse 
es nur bei dieser wichtigsten Delay-Zeile, denn eine weitere, 
tiefergehende Analyse wird deutlich mehr Zeit in Anspruch nehmen und 
Zeit ist bekanntermaßen nicht nur für einen µController kostbar.

[Fadel (fadelsikh)]

Vielen Dank für Ihre wertvolle Tipps.Das muss ich auch lernen damit 
alles kontrolliert sein. Da ich Anfänger bin, fehlen mir diese Tipps 
bzw. Verbesserungen.