Atmega32 und MAX7219

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.

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

Maxim B. schrieb:

Du machst ~CS nach jedem Byte wieder hoch.

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

S. L. schrieb:

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

Mehr ist doch immer besser als weniger.

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.

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.

Und aus der 9 eine 8 machen.

Das steht aber schon beides in vorhergehenden Beiträgen.

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.

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

Vielen Dank für die Alle,es hat geklappt

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.

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.