Forum: Mikrocontroller und Digitale Elektronik Atmega32 und MAX7219


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Fadel (fadelsikh)


Angehängte Dateien:

Lesenswert?

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

Beitrag #7620140 wurde vom Autor gelöscht.
von Maxim B. (max182)


Lesenswert?

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.

: Bearbeitet durch User
von S. L. (sldt)


Lesenswert?

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

Beitrag #7620313 wurde vom Autor gelöscht.
von S. L. (sldt)


Angehängte Dateien:

Lesenswert?

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

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

von Wastl (hartundweichware)


Lesenswert?

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

Mehr ist doch immer besser als weniger.

von Veit D. (devil-elec)


Lesenswert?

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.

von Gregor J. (Firma: Jasinski) (gregor_jasinski)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Reinhard R. (reirawb)


Angehängte Dateien:

Lesenswert?

Und aus der 9 eine 8 machen.

Das steht aber schon beides in vorhergehenden Beiträgen.

: Bearbeitet durch User
von Fadel (fadelsikh)


Lesenswert?

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.

Beitrag #7620599 wurde vom Autor gelöscht.
von Gregor J. (Firma: Jasinski) (gregor_jasinski)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Fadel (fadelsikh)


Angehängte Dateien:

Lesenswert?

Vielen Dank für die Alle,es hat geklappt

von Gregor J. (Firma: Jasinski) (gregor_jasinski)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Fadel (fadelsikh)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.