Hi,
Ich versuche einen 7Segment Serial Display über SPI, mit STM32F411VE als
Master und MAX7219 als slave in Betrieb zu nehmen. SPI Master Seite
scheint richtig zu funktionieren, aber bei Slave nicht ich habe alles
richtig initialisiert wie im Datenblatt beschrieben.(siehe Bild)
Irgendwie bekomme ich die Daten nicht angezeigt wie erwartet.
Hat jemand schon mit dem Teil schonmal gearbeitet, und konnte paar Tipps
geben.
Mein Code:
Main routine:
Aa B. schrieb:> Irgendwie bekomme ich die Daten nicht angezeigt wie erwartet.>> Hat jemand schon mit dem Teil schonmal gearbeitet, und konnte paar Tipps> geben.>
Hallo,
wie sieht es aus mit VCC für Mikrocontroller und für Max7219 ?
Meine Vermutung: Max7219 läuft mit 5 Volt und dem reicht Signal von 3
Volt-MK nicht.
Mögliche Abhilfe: MAX7219 kann auch mit 4 Volt laufen, aus meiner
Erfahrung auch sogar von 3,3 Volt. Dann sollte alles stimmen.
Andere Möglichkeit: zwischen Mikrocontroller und Indikator 74HCT14
einschalten, je 2 Ventile nacheinander, da sie invertieren. Das kann man
sehr bequem machen: Pin 1, 2-13, Ausgang 12; Pin 3, 4-11; Ausgang 10;
Pin 5, 6-9, Ausgang 8.
Das habe ich einmal gemacht, um von 3 Volt laufende ATMega mit MAX7219
zu verbinden. Alles war wunderschön.
Hier ist meine Schema von damals, Testplatte für Indikator mit MAX7219.
Gruß,
Vielen Dank für deine Rückmeldung!
Ich dachte es liegt an meine SPI Einstellung auf der Software Seite,
war nicht völlig richtig gewesen, dann habe ich den Code angepasst,
jetzt schickt er die Bytes sauber zum Slave an der MOSI Leitung. (siehe
Anhang)
Maxim B. schrieb:> Hallo,> wie sieht es aus mit VCC für Mikrocontroller und für Max7219 ?>> Meine Vermutung: Max7219 läuft mit 5 Volt und dem reicht Signal von 3> Volt-MK nicht.
Der Teil hat jetzt 4.9V ca, und gestern hatte er auch 4.7V also mehr als
3V. mit 3 V
> Mögliche Abhilfe: MAX7219 kann auch mit 4 Volt laufen, aus meiner> Erfahrung auch sogar von 3,3 Volt. Dann sollte alles stimmen.
mit 3.3 V habe ich auch ausprobiert aber läuft nicht wie erwartet.
Hast Du das exakt gleiche Teil?
Ich spreche zwar nicht C, aber wo steuerst du den CS des MAX? Soweit ich
weiß, muß der CS so lange aktiv bleiben, bis alles übertragen wurde.
Wenn deine Ausgaberoutine den CS selber bedient wird das nix.
Harry schrieb:> Ich spreche zwar nicht C, aber wo steuerst du den CS des MAX? Soweit ich> weiß, muß der CS so lange aktiv bleiben, bis alles übertragen wurde.> Wenn deine Ausgaberoutine den CS selber bedient wird das nix.
CS is mit NSS leitung von SPI2 verbunden also Pin PB12 in mein Fall,
Diese Pin schalte ich manuell in mein Code, wie du im Bild siehst
(Channel3 ENABLE ist /CS), SS leitung ist auf LOW am Anfang des
ByteTransfers, und am Ende geht wieder auf HIGH, also erst wenn er
fertig ist.
Aa B. schrieb:> Der Teil hat jetzt 4.9V ca, und gestern hatte er auch 4.7V also mehr als> 3V. mit 3 V
Auf der Seite von http://www.st.com bzg. STM32F411 steht:
The STM32F411xC/xE operate in the - 40 to + 125 °C temperature range
from a 1.7 (PDR OFF) to 3.6 V power supply.
Wenn du hier 5 V verwendest, ist dein STM32F411 schon lange tot.
MAX7219 hat keine TTL-Eingänge.
Operating Supply Voltage MIN 4.0 MAX 5.5 V
Logic High Input Voltage MIN 3.5 V
Also, überprüfe Signalpegel. Dein Problem kommt bestimmt deshalb, weil
MAX7219 und STM32F411 zu unterschiedlichen Signalpegel haben. Dazu hast
du bei deiner Verbindungsart keine gute Erde, das wirkt auch.
Noch eine Frage: wozu das?
#define delay 40
Delay_ms(delay);
Wozu wartest du nach jedem Befehl 40 ms? denkst du, so wird für MAX
verständlicher? Wenn jemand mit dir redet und nach jedem Wort 2 Stunden
wartet?
Denkst du, das reicht nicht?
while ( ( (SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE) ) != SET))
Ich habe verschiedene Module mit MAX7219 ausprobiert: 7-segm., Matrix.
Und einziges Problem, das ab und zu kam, war: schlechte Erde und
Qualität von Signal selst. Ansonsten sehr gute IC, absolut problemlos.
Man sollte sich viel Muhe geben, um etwas schief zu machen.
Maxim B. schrieb:> Wenn du hier 5 V verwendest, ist dein STM32F411 schon lange tot.
Die meisten (nicht alle) Pins eines STM32 sind 5V-tolerant (im DB als FT
gekennzeichnet).
mfg
Felix F. schrieb:> Die meisten (nicht alle) Pins eines STM32 sind 5V-tolerant (im DB als FT> gekennzeichnet).>> mfg
Auch dann bedeutet das nicht automatisch, daß MAX7219 notwendige
Signalpegel bekommt, wenn MK von 3,3 Volt läuft. Von 5 V kann MK hier
aber nicht laufen, sonst sofort tot. D.h. ohne Problem mit Signalpegel
zu klären, kommen wir hier kaum noch weiter.
Wie schafft Aa Bb, daß MAX7219 von einem 3,3-Volt-MK 5V-Signal bekommt,
schweigt er bisher...
Und noch - ich habe darüber schon geschrieben - Foto zeigt, daß auch ein
Problem mit Erde mehr als wahrscheinlich ist. Indikator hat ca. 300 -
350 mA Verbrauch,und zwar in Impuls. Das alles läuft über GND, und wirkt
auch auf Signal.
Für meine (immer erfolgreiche) Versuche mit MAX7219 habe ich fast immer
eine Platte gemacht, mit Erde und allem. Einmal habe ich eine Matrix mit
4 MAX7219 auf einem Steckbrett ausprobiert - es gab auch komische
Sachen. Auf einer SPI-Geschwindigkeit lief alles gut, wenn ich aber SPI
langsamer (!) schaltete, lief nichts mehr - so etwas kann man nur mit
Signalreflexionen und Erde aus einem dünnen Draht erklären.
Wenn auch bei 5 Volt-Signal Problem kommt, dann sollte man Speisung und
Signal besser voneinander trennen, vielleicht auch serielle Widerstand
für CS, CLK und Data (so ca. 22 Ohm) gegen Reflexionen einlöten. Aber
zuerst Signalpegel.
Aa B. schrieb:> CS is mit NSS leitung von SPI2 verbunden also Pin PB12 in mein Fall,> Diese Pin schalte ich manuell in mein Code, wie du im Bild siehst> (Channel3 ENABLE ist /CS), SS leitung ist auf LOW am Anfang des> ByteTransfers, und am Ende geht wieder auf HIGH, also erst wenn er> fertig ist.
Fig. 192 im RM0383 zeigt klar: dem "Shift register" vorgelagert ist "Tx
Buffer". Das TXE-Flag zeigt an, wann "TX Buffer" leer ist, also die
nächsten Daten da hinein geschrieben werden dürfen. Das heisst aber noch
lange nicht, dass das "Shift register" schon leer ist (die Übertragung
also schon abgeschlossen ist)! Deaktiviert man SS, sobald TXE gesetzt
wird, ist das also u. U. zu früh ...
Auf den folgenden Seiten ist unter "Handling data transmission and
reception" genau beschrieben, wie vorzugehen ist! Kapitel komplett und
sorgfältig lesen, insbesondere die Fallstricke mit dem BSY-Bit!!!
Maxim B. schrieb:> Auch dann bedeutet das nicht automatisch, daß MAX7219 notwendige> Signalpegel bekommt, wenn MK von 3,3 Volt läuft. Von 5 V kann MK hier> aber nicht laufen, sonst sofort tot. D.h. ohne Problem mit Signalpegel> zu klären, kommen wir hier kaum noch weiter.
Les meinen Beitrag nochmal genau durch!
Ich habe lediglich geschrieben, dass die Inputs des STM meist 5V-fähig
sind und der Controller somit nicht automatisch tot ist, wenn ein 5V
Signal anliegt.
Maxim B. schrieb:> MAX7219 hat keine TTL-Eingänge.> Operating Supply Voltage MIN 4.0 MAX 5.5 V> Logic High Input Voltage MIN 3.5 V
Und laut diesen Ausgaben benötigt man für die Ausgänge sowieso einen
Levelshifter.
mfg
Häng sowas dazwischen und alles ist gut:
https://www.adafruit.com/product/395
Hat bei mir von Anfang an funktioniert. Habe aber nicht SPI verwendet,
sondern meine eigenen Bitwackler Routinen vom ATMega128:
Beitrag "Tempertur/Feuchte Display/Logger mit ATMega128 SHT75 SD-Karte"
umgeschrieben auf den STM32F4.
Wie die Vorredner schon geschrieben haben, sind die meisten der Ports
auf den Discovery-Board 5V tolerant, d.h. sie rauchen nicht ab, wenn
sie 5V Pegel bekommen. Selber generieren sie aber niemals 5V Pegel,
sondern nur max. 3.3v, und das reicht dem MAX7219 eben nicht.
Gruss Daniel
Harry schrieb:> Ich spreche zwar nicht C, aber wo steuerst du den CS des MAX? Soweit ich> weiß, muß der CS so lange aktiv bleiben, bis alles übertragen wurde.> Wenn deine Ausgaberoutine den CS selber bedient wird das nix.Aa B. schrieb:> CS is mit NSS leitung von SPI2 verbunden also Pin PB12 in mein Fall,> Diese Pin schalte ich manuell in mein Code, wie du im Bild siehst> (Channel3 ENABLE ist /CS), SS leitung ist auf LOW am Anfang des> ByteTransfers, und am Ende geht wieder auf HIGH, also erst wenn er> fertig ist.
Moin,
so wie ich das lese, will das Ding einen 16bit Transfer, keine 8bit
Transfers. Kann das sein?
"The data is then latched into either the digit or control registers
on the rising edge of LOAD/CS."
Also zumindest in dem Bild ist eindeutig zu erkennen, das CS nach
jedem byte kurz auf high geht.
So kann das doch nicht funktionieren, oder?
Ich habe das aber nur kurz ueberflogen.
Darth Moan schrieb:> Moin,>> so wie ich das lese, will das Ding einen 16bit Transfer, keine 8bit> Transfers. Kann das sein?>> "The data is then latched into either the digit or control registers> on the rising edge of LOAD/CS.">> Also zumindest in dem Bild ist eindeutig zu erkennen, das CS nach> jedem byte kurz auf high geht.> So kann das doch nicht funktionieren, oder?> Ich habe das aber nur kurz ueberflogen.
Jo dat ist richtig, der Slave will 16bit gefuttert bekommen, also der SS
leitung muss danach auf HIGH gesetzt werden, und dass kann der STM32
auch, der Data Register von SPI ist ja 16bit groß, Slave will das aber
nicht verstehen, ich habe festgestellt dass es nicht an der
Programmierung liegt sondern an die Elektronik, der MAX teil ist richtig
instabil.
Wie habe ich das festgestellt ?
In dem dass ich mit eine 8 bit ATMEGA328p als Master gesteuert habe und
habe gesehen dass ich Tausend mal reset machen muss um einige digits auf
dem Display zu sehen.
Anbei mein ATMega Code, und das Bild. Also SPI Register is 8bit gross
bei AVR und ich habe, erst der SS Leitung auf LOW, dann address und
danach data auf der leitung gesendet, und danach der SS Leitung HIGH
gezogen.
Aa B. schrieb:> SPI_InitStruct.SPI_DataSize = SPI_DataSize_8b;
Und dein Logic/Oszi Screenshot zeigt genau 3 8bit Transfers nacheinander
mit CS high nach jedem Byte. Zeigt dein Bild denn genau was tatsaechlich
auf den SPI Pins passiert?
Aa B. schrieb:> Harry schrieb:> Ich spreche zwar nicht C, aber wo steuerst du den CS des MAX? Soweit ich> weiß, muß der CS so lange aktiv bleiben, bis alles übertragen wurde.> Wenn deine Ausgaberoutine den CS selber bedient wird das nix.>> CS is mit NSS leitung von SPI2 verbunden also Pin PB12 in mein Fall,> Diese Pin schalte ich manuell in mein Code, wie du im Bild siehst> (Channel3 ENABLE ist /CS), SS leitung ist auf LOW am Anfang des> ByteTransfers, und am Ende geht wieder auf HIGH, also erst wenn er> fertig ist.
Ich meinte nicht am Ende jedes Bytes, sondern am Ende des gesamten
Tranfers.
Darth Moan schrieb:> Aa B. schrieb:>> SPI_InitStruct.SPI_DataSize = SPI_DataSize_8b;>> Und dein Logic/Oszi Screenshot zeigt genau 3 8bit Transfers nacheinander> mit CS high nach jedem Byte. Zeigt dein Bild denn genau was tatsaechlich> auf den SPI Pins passiert?
Danke, dass war ein guter Tipp. Ich habe den Datasize auf 16b
umgestellt, der Transfer sehe ich auch jetzt im Logicanalyzer, aber
Slave will immer noch nicht verstehen.
was meinst Du ob das Bild wirklich das zeigt?
Aa B. schrieb:> was meinst Du ob das Bild wirklich das zeigt?
Moin,
naja, die Frage ging dahin, ob das CS gelabelte Signal wirklich am Max
gemessen war oder etwas anderes. Weil es mit 16bit vs. 8bit nicht
passte.
Aber das neue Bild scheint mir den Transfer von 0xFF90 zu zeigen.
Ich schaetze aber es sollte 0x09FF sein. Ist jetzt aber eine Vermutung.
Aber das stuetzt diese Vermutung:
Aa B. schrieb:> SPI_InitStruct.SPI_FirstBit = SPI_FirstBit_LSB;
Der Max will aber MSB first.
Dann sollte der SPI Transfer aber laufen wie gewuenscht. Wenn dann der
Max nicht will, koennte es an den Pegeln liegen, da hab ich noch nix
nachgeschaut.
Felix F. schrieb:> Ich habe lediglich geschrieben, dass die Inputs des STM meist 5V-fähig> sind und der Controller somit nicht automatisch tot ist, wenn ein 5V> Signal anliegt.
Leider hilft das TC kaum.
Er glaubt immer noch, das sei nur ein Programmfehler.
Ich denke, es ist absolut falsch, zu behaupten, MAX7219 sei schlecht.
Bei mir laufen sie immer gut, ich muß mich nur an elementaren Regeln
halten. Ich habe schon 30 Stück in Arbeit.
Sie laufen gut mit SPI und auch mit Programm-SPI. Nur mögen sie es
nicht, wenn Erde schlecht ist. Aber wer mag schon schlechte Erde?
Diese chinesische Module - das ist eigentlich falsch, daß sie nur 5 Pin
haben: Vcc, Gnd und drei Signalleitungen. Man sollte Signal-Gnd und
LED-Gnd getrennt verkabeln. Mögliche Abhilfe hier: die Module haben auch
von anderer Seite 5 Pin, auch Vcc und Gnd.
Funktionierender C-Code für Max7219 finden sich im
Projekt DCF77 Uhr in C mit ATtiny26 von Peter Dannegger unter
Beitrag "DCF77 Uhr in C mit ATtiny26"
Eine Variante in C++ ist unter
Beitrag "Re: DCF77 Uhr in C mit ATtiny26"
zu finden.
Der auszugebende Zahlenwert wird in einem array[8] durch das Programm
bereitgestellt und în einem Timer-Interrupt periodisch auf das Display
ausgegeben.
Zum Verständnis wichtig: display_write, display_out.
Als erster Test wichtig: display_init mit Testmode on.
Darth Moan schrieb:> Aber das neue Bild scheint mir den Transfer von 0xFF90 zu zeigen.> Ich schaetze aber es sollte 0x09FF sein. Ist jetzt aber eine Vermutung.> Aber das stuetzt diese Vermutung:>> Aa B. schrieb:>> SPI_InitStruct.SPI_FirstBit = SPI_FirstBit_LSB;>> Der Max will aber MSB first.
Du Hast völlig recht, MAX wollte schon immer den MSB zuerst. Jetzt
läuft.
> Dann sollte der SPI Transfer aber laufen wie gewuenscht. Wenn dann der> Max nicht will, koennte es an den Pegeln liegen, da hab ich noch nix> nachgeschaut.
Jetzt reagiert der Slave, klasse, Danke, Du bist der Beste. :)))
Darth Moan schrieb:> Aber das neue Bild scheint mir den Transfer von 0xFF90 zu zeigen.> Ich schaetze aber es sollte 0x09FF sein. Ist jetzt aber eine Vermutung.> Aber das stuetzt diese Vermutung:>> Aa B. schrieb:>> SPI_InitStruct.SPI_FirstBit = SPI_FirstBit_LSB;> Der Max will aber MSB first.
Du hast völlig recht, MAX wollte schon immer den MSB zuerst. Jetzt
läuft.
> Dann sollte der SPI Transfer aber laufen wie gewuenscht. Wenn dann der> Max nicht will, koennte es an den Pegeln liegen, da hab ich noch nix> nachgeschaut.
Jetzt reagiert der Slave, klasse, Danke, Du bist der Beste. :)))
MitLeserin schrieb:> Funktionierender C-Code für Max7219 finden sich im> Projekt DCF77 Uhr in C mit ATtiny26 von Peter Dannegger unter> Beitrag "DCF77 Uhr in C mit ATtiny26">> Eine Variante in C++ ist unter> Beitrag "Re: DCF77 Uhr in C mit ATtiny26">> zu finden.>> Der auszugebende Zahlenwert wird in einem array[8] durch das Programm> bereitgestellt und în einem Timer-Interrupt periodisch auf das Display> ausgegeben.>> Zum Verständnis wichtig: display_write, display_out.> Als erster Test wichtig: display_init mit Testmode on.
OKay danke, init routine habe ich in mein Program auch drin , hat mit
der Problematik nichts zu tun eigentlich.
Thread beobachten
Seitenaufteilung abschalten