Hallo,
ich möchte gerne einen AD7142 über einen STM32F103RB auslesen. Das ganze
soll mit SPI geschehen. An dem AD7142 hängen mehrere Touch-Sensoren.
Es scheitert leider schon an der SPI-Verbindung. Ich habe da leider
wenig Erfahrung und würde mich freuen wenn sich das jemand anschauen
könnte. Das ganze bleibt immer in der GetFlagStatus-Schleife hängen.
Nur als TIPP:
ich hatte beim Einlesen des Touchcontroller-Baustein meines Panels auch
zu kämpfen. Bei dem ADx(watweißichnoch) habe ich gesehen, dass die nicht
sofort antworten.
Ich hatte dann zunächst einen Test gemacht, der explizit mit den
Portpins wackelt, ehe ich dann auf die "highsophisticated" STM32-SPI
"ichmacheallesfürdich" - Version umgestiegen bin.
Gruß Thilo.
P.S. Dein Chip - Select weist in deiner Schleife nur einen Spike nach
"H" hin auf. eine kleine Pause wäre gut....
Hängen bleiben tut er nun nicht mehr. Bekomme aber leider nichts vom AD
zurück.
@Thilo: Hat es denn mit der "highsophisticated" STM32-SPI
"ichmacheallesfürdich" - Version geklappt? Eine kleine Pause habe ich
drin.
Ja, hat es!
Allerdings benutze ich ChibiOS. Die haben einen eigenen HAL, der es noch
einfacher machen soll.
Wenn du dich zwei bis drei Stunden geduldest kann ich Dir beide
Varianten hier posten.
Gruß Thilo
Hab den Code noch mal mit meinem funktionierenden SPI-Code verglichen.
Sowohl Initialisierung als auch Ansteuerung sehen korrekt aus.
Ich tippe auf eine falsche Ansteuerung des AD...
sakul schrieb:> siehe PDF
So meinte ich das nicht ;-)
Leitungen scheinen richtig angeschlossen zu sein (hatte mal einen bösen
Fehler, weil die MISO/MOSI Leitung zu einer SD-Karte vertauscht war...).
Ich meinte, dass die Einstellung des SPI vielleicht nicht richtig ist.
A. K. schrieb:> Verwechselst du hier SPI mit I2C? PP ist für SPI richtig.
Nee, denn MISO heißt Master-Input und sollte somit im Regelfall kein
Push-Pull-Ausgang sein. Aber gemäß der Doku zur Library ist das hier
i.O. .
@sakul
Bist du sicher ob alle Leitungen :
1. Im Schaltplan korrekt angeschlossen sind? (bewege ggf. mal die
beiden Bausteine hin und her, dann siehst du das)
2. Im Board geroutet sind? (Layer angezeigt)
Was steht denn im Eingangsbuffer? 0xFFFF, 0x0000?
Gnubbel schrieb:> Nee, denn MISO heißt Master-Input und sollte somit im Regelfall kein> Push-Pull-Ausgang sein.
Nur hattest du oben moniert, dass MOSI OD sein solle, nicht MISO:
Beitrag "Re: STM32 -> SPI -> AD7142"
MISO wiederum sollte m.E. weder PP noch OD sein, sondern ein Eingang.
Du hast auf CS noch immer kaum einen "H" - Zustand.
Mach zwischen Schreiben des Kommandos und dem Einlesen des Ergebnisses
mal eine Pause!
Hast Du ein Oszilloskop ? Regen sich irgendwelche Pins ?
Oder mindestens einen Debugger ? Dann könntest Du auch explizit mit den
Pins wackeln.
Bist Du sicher das das Wort genau so rausgeht ?
Unter ChibiOS wurde DMA genutzt. Dabei waren High und Low vertauscht.
Teste mal 0x17E4....
Gruß Thilo
sakul schrieb:> GPIOSPI1_InitStructure.GPIO_Pin = GPIO_Pin_5 | GPIO_Pin_6 |> GPIO_Pin_7; // 5 = SPI1_SCK, 6 = SPI1_MISO, 7 = SPI1_MOSI> GPIOSPI1_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;> GPIOSPI1_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;> GPIO_Init(GPIOA, &GPIOSPI1_InitStructure);
An der Stelle hat Gnubbel auf falsche Art Recht: Solange der Eingang
MISO ein Ausgang ist wird das sicher nix werden.
Habe den MISO nun als GPIO_Mode_IN_FLOATING. Auf was muss ich
SPI_BaudRatePrescaler stellen?
> Mach zwischen Schreiben des Kommandos und dem Einlesen des Ergebnisses> mal eine Pause!
Wie lange?
Ich weiß das auch nicht - was sage das Datenblatt dazu ?
Ich habe Dir oben den Pintoggle - trivial - code gepostet. Tritt mal
einen Schritt zurück und versuche nicht gleich das Maximum
hinzubekommen. Schön wenn man sofort fertig ist, aber meistens läuft es
nicht so.
Wäre es nicht gut erst mal irgendeine Reaktion von dem Chip zu bekommen
- und sei es nur das der MISO mal auf Low geht ?
Nochmal die Frage - was hast du für Hilfsmittel ?
OSKAR ? DEBUGGER ? Kannst Du sehen ob auf dem MOSI überhaupt was
rausgeht ? Siehst Du denn Clock - Signale ?
Es gibt für SPI keine Baudratenuntergrenze. Du kannst die Zeiten
beliebig groß ziehen - sogar so groß das Du LED's zur Kontrolle
anbringen kannst.
Wenn du mal eine Reaktion des Chips bekommst - dann melde dich wieder!
Wenn wir dann zusammen nach der richtigen SPI - Konfiguration suchen
wissen wir wenigstens das die Hardwaresignale richtig geschaltet sind!
Gruß Thilo
Natürlich meinte ich MISO, aber ich habe nochmal in der Doku zur Library
nachgeschaut, und das Beispiel welches ich gesehen habe hat tatsächlich
den Eingang als AF_PP konfiguriert.
Es kann natürlich auch sein dass in den Beispielen der Library ein
Fehler ist.
IN_FLOATING ist aber auch nicht unbedingt richtig, da es ja eine
alternative Funktion-> AF sein soll, nämlich nicht GPIO sondern SPI.
Ich benutze wie oben angegeben AF_OD und das funktioniert definitiv.
RM0008 S.157: For alternate function inputs, the port must be configured
in Input mode (floating, pull-
up or pull-down) and the input pin must be driven externally.
Gnubbel hat mal wieder Recht,
mindestens drei SPI - Pins müssen auf den Alternate - Mode (5)
geschaltet sein. Sonst rühren die sich nicht. Es sind MOSI, MISO und
CLK...
Trotzdem bleibe ich dabei - Mach erst mal den Toggle - Pin - Test. Wenn
da eine Antwort kommt weiß man mehr....
Gnubbel schrieb:> IN_FLOATING ist aber auch nicht unbedingt richtig, da es ja eine> alternative Funktion-> AF sein soll, nämlich nicht GPIO sondern SPI.>> RM0008 S.157: For alternate function inputs, the port must be configured> in Input mode (floating, pull-up or pull-down) and the input pin must be> driven externally.
Ähm... und in diesen beiden Aussagen siehst du keinen Widerspruch? Du
behauptest, die Programmierung als Input sei nicht unbedingt richtig -
und die Referenz behauptet, es wäre genau richtig.
Es gibt bei den Pins keinen Modus für AF-Input. Der ist auch nicht
erforderlich, weil der Input-Zweig des Pins auch ohne explizite Schalte
zum Funktionsmodul geleitet wird. Nur bei Ausgängen muss man die interne
Signalquelle umschalten. Kann man recht hübsch in Chapter 9 Figure 13
erkennen.
THaala schrieb:> mindestens drei SPI - Pins müssen auf den Alternate - Mode (5)> geschaltet sein. Sonst rühren die sich nicht. Es sind MOSI, MISO und> CLK...
Seltsamerweise funktionierte SPI bei mir auch dann, wenn MISO als
normaler Input geschaltet ist.
Update: Bei SPI besteht für die Pinfunktion die Besonderheit, dass
SCLK/MOSI/MISO durch die Master/Slave-Umschaltung ihre Richtung
wechseln. Es wird also so sein, dass im Fall von SPI auch AF-Output für
den Eingang spezifiziert werden kann und die vom SPI-Modul kommende
AF-Steuerung dafür sorgt, dass der Ausgangstreiber bei Funktion als
Eingang automatisch abgeschaltet wird.
sakul kann also weitersuchen, ob er MISO als Eingang oder Ausgang
konfiguriert ist bei einem reinen SPI-Master egal.
A. K. schrieb:> Es gibt bei den Pins keinen Modus für AF-Input. Der ist auch nicht> erforderlich, weil der Input-Zweig des Pins auch ohne explizite Schalte> zum Funktionsmodul geleitet wird.
Ja OK, da gebe ich mich mal geschlagen.
Bleiben aber immernoch folgende Fragen offen:
Bist du sicher ob alle Leitungen :
1. Im Schaltplan korrekt angeschlossen sind? (bewege ggf. mal die
beiden Bausteine hin und her, dann siehst du das)
2. Im Board geroutet sind? (Layer angezeigt)
Was steht denn im Eingangsbuffer? 0xFFFF, 0x0000?
> 1. Im Schaltplan korrekt angeschlossen sind? (bewege ggf. mal die> beiden Bausteine hin und her, dann siehst du das)> 2. Im Board geroutet sind? (Layer angezeigt)
beides Ok, habe Vcc,Gnd,CS,CLK,Miso,Mosi durchgeklingelt -> passt
> Was steht denn im Eingangsbuffer? 0xFFFF, 0x0000?
0x0000
Ich denke in ein paar stunden weiss ich dank Oszilloskop mehr.
Gruß
Lukas
Wenn es um die generelle Vorgehensweise geht ist ST selbst die beste
Quelle.
z.B die Resource für deren EVAL Board 3210B
http://www.st.com/internet/evalboard/product/176090.jsp
in der Demonstration Firmware findest Du mehr als eine SPI - Config -
Funktion.
Schaust Du hier:
um0435.zip\STM3210B-EVAL_FW_V2.0.0\Project\Demo\src\stm3210b_lcd.c
Funktion LCD_SPIConfig();
oder....
um0435.zip\STM3210B-EVAL_FW_V2.0.0\Project\Demo\src\spi_flash.c
void SPI_FLASH_Init(void);
Gruß Thilo
Ich möchte nochmal betonen... hab den SPI mit den oben beschriebenen
Einstellungen am Laufen. AF-PP ist definitiv die richtige Konfiguration.
Schau dir die Datenübertragung auf dem Oszilloskop an. Ich tippe darauf,
dass das Datenwort bereits gesendet wird während der Chip Select noch
nicht aktiv ist.
Wenn du kein Oszi hast kannst du ja den Eingang mal als
GPIO anlegen und den Pin dann ständig abfragen und die Led einschalten
wenn sich der Pegel ändert.
In den Beispielen die ich ganannt habe wird das Senden immer abgewartet
mit der Prüfung auf _BSY
[c]
SPI_I2S_SendData(SPI2, 0xFF);
while(SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_BSY) != RESET)
{
}
/* One byte of invalid dummy data read after the start byte */
while(SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET)
{
}
SPI_I2S_ReceiveData(SPI2);
}
SPI_I2S_SendData(SPI2, 0xFF);
/* Read upper byte */
while(SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_BSY) != RESET)
{
}
/* Read lower byte */
while(SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET)
{
}
tmp = SPI_I2S_ReceiveData(SPI2);
[/c}
gruß T.
P.S. Vergiss das mit dem Pointer - ich habe mich da vertan!
Ja Moment, aus den Beispielen lese ich, das Du selbst für das Clocking
sorgst, indem Du ein 0xFF (bzw 0xFFFF in deinem Fall) schreibst. Die
Konsequenz:
Clock Zappelt, MOSI beleibt auf 1 und MISO rappelt - oder ?
Gruß T.
sakul schrieb:> Habe nun am Oskar gesehen, dass der Clock nur während des Sendens da> ist. Beim Empfangen ist er Null. Woran kann das liegen?
An der Arbeitsweise von SPI. Es gibt darin kein getrenntes Senden und
Empfangen. Wann immer gesendet wird, wird auch gleichzeitig empfangen.
Wenn man also 16 Bits senden und anschliessend als Antwort 16 Bits
empfangen will, dann werden insgesamt 32 Bits gesendet und 32 Bits
empfangen.