Hallo, ein TFT hat SDCard-SPI,XPT2046 und SPIFlash alle auf die gleichen SPI-Leitungen gelegt. Prinzipiell kann man sich auch noch einen RFM12 vorstellen, der da dranhängt. Es wird kein DMA genutzt. SPIFlash kann mit 80MHz+ laufen, der XPT (10MHz glaube ich) wird langsamer und für die ADC-Wandlung noch langsamer getaktet und die SD-Karten laufen mit 400kHz/20MHz. Ein RFM12 mit 2.5MHz. Derzeit mache ich es so, daß ich in allen Subs, die auf SPI zugreifen, jeweils die Geschwindigkeit (bzw. das zugehörige Register) beim Eintritt speichere, auf die jeweils angemessene Geschwindigkeit umschalte, und bei Verlassen wieder den Wert zurückschreibe, der beim Eintritt gegeben war. Kostet halt etwas Zeit. Es stört mich nicht, es läuft gut, aber die Frage nach der Geschwindigkeit könnte bei anderen ja auch aufgetaucht sein. Kann man das besser machen? Grüße Sauer
Sauer schrieb: > Derzeit mache ich es so, daß ich in allen Subs, die auf SPI zugreifen, > jeweils die Geschwindigkeit (bzw. das zugehörige Register) beim Eintritt > speichere, auf die jeweils angemessene Geschwindigkeit umschalte, und > bei Verlassen wieder den Wert zurückschreibe Das Setzen beim Eintritt reicht völlig. Der Rest ist überflüssig.
Peter D. schrieb: > Das Setzen beim Eintritt reicht völlig. Und das Setzen nur dann wirklich ausführen wenn neue Speed ungleich der alten ist.
Sauer schrieb: > der XPT (10MHz glaube ich) Nein, der XPT2046 nur 2 MHz. Haben sich schon manche Leute gewundert dass der Touch "nicht funktioniert".
mitlesa schrieb: > Und das Setzen nur dann wirklich ausführen wenn neue > Speed ungleich der alten ist. Da rattert aber die Bartwickelmaschine im Keller.
Peter D. schrieb: > Da rattert aber die Bartwickelmaschine im Keller. In deinem Keller mag das schon so sein, bei den Schilderungen des TO schaut das aber anders aus.
mitlesa schrieb: > Peter D. schrieb: >> Das Setzen beim Eintritt reicht völlig. > > Und das Setzen nur dann wirklich ausführen wenn neue > Speed ungleich der alten ist. Das muß man ausprobieren, es kann sehr gut sein daß man mit der Prüfung mehr Zeit vertrödelt als man einsparen könnte.
Wie benehmen sich Chips die an den Inputs überfordert (Takt zu hoch) werden?
Sauer schrieb: > Derzeit mache ich es so, daß ... Kann es bei dir vorkommen, dass laufende SPI-Kommunikationen/Tansfers unterbrochen werden? Nur dann würde es Sinn machen, einen "aktuellen" Wert zu speichern und nach Gebruach des SPI-Interface wieder herzustellen. Weil solche Unterbrechungen aber überaus unüblich sind und garantiert lustige Nebeneffekte mit sich bringen können. Hat jede Subroutine das SPI-Interface für sich, muss es pssend für sich einrichten und kann hinterher das Aufräumen einfach sein lassen. Weiß ja eh' keiner, wer als Nächster den SPI verwenden will. > jeweils die Geschwindigkeit (bzw. das zugehörige Register) beim Eintritt > speichere Da hast du aber Glück, dass alle den selben SPI-Modus verwenden... NichtWichtig schrieb: > Wie benehmen sich Chips die an den Inputs überfordert (Takt zu hoch) > werden? Solange sie per inaktivem SS# deselektiert sind juckt die das nichts.
:
Bearbeitet durch Moderator
Wühlhase schrieb: > Das muß man ausprobieren, es kann sehr gut sein daß man mit der Prüfung > mehr Zeit vertrödelt als man einsparen könnte. Ja, kommt auf den Controller an. Ein aktuell betroffener wurde nicht genannt.
Peter D. schrieb: > Das Setzen beim Eintritt reicht völlig. Der Rest ist überflüssig. Hm. Vielleicht muß ich dann den Programmierstil ändern (s.u.). Aber genau darauf zielt auch die Eingangsfrage ab. Lothar M. schrieb: > Sauer schrieb: >> Derzeit mache ich es so, daß ... > Kann es bei dir vorkommen, dass laufende SPI-Kommunikationen/Tansfers > unterbrochen werden? Nur dann würde es Sinn machen, einen "aktuellen" > Wert zu speichern und nach Gebruach des SPI-Interface wieder > herzustellen. Ja, ich glaube, das kann passieren. Aber genau weiß ich das nicht - tatsächlich muß ich nochmal genauer drüber nachdenken. Wenn ein RFM dranhängt, kann der natürlich was empfangen, interruptet, holt sich im Interrupt das Statusword mit der Interruptquelle und stellt damit auf das langsames SPI um. Dann setzt er ein Flag und verläßt den Interrupt. Wenn da gerade von SPIFlash ein Block gelesen wird, wenn der Interrupt kommt, kehrt er zurück in diese Flash-Routine - dann aber halt mit langsamerer SPI-Geschwindigkeit. Da wäre das zurückschreiben am Ende des Interrupts (bzw. in der SPI-Leseroutine) schon sinnvoll. Oder könnte ich auch nur ein Flag setzen und dann auch das Statusregister erst in der mainloop lesen, aber da war irgendwas Zeitkritisches beim RFM mit dem kleinen FiFo. > Da hast du aber Glück, dass alle den selben SPI-Modus verwenden... Ist so, tatsächlich. mitlesa schrieb: > Nein, der XPT2046 nur 2 MHz. Stimmt, hab nachgeschaut. Im Treiber läuft er auf ~650kHz beim Wandeln und auf 2MHz beim rausschieben.
Sauer schrieb: > Wenn da gerade von SPIFlash ein Block gelesen wird, wenn der Interrupt > kommt, kehrt er zurück in diese Flash-Routine - dann aber halt mit > langsamerer SPI-Geschwindigkeit. Davon würde ich abraten, Instanzen von SPI im Main und im Interrupt laufen zu lassen. Das geht beliebig in die Hose. Das SPI ist nicht reentrant, wie ja UART oder I2C auch. Mehrere Instanzen muß man daher gegeneinander verriegeln, z.B. mittels fopen, fclose.
Sauer schrieb: >> Kann es bei dir vorkommen, dass laufende SPI-Kommunikationen/Tansfers >> unterbrochen werden? Nur dann würde es Sinn machen, einen "aktuellen" >> Wert zu speichern und nach Gebruach des SPI-Interface wieder >> herzustellen. > Ja, ich glaube, das kann passieren. Das sollte aber nicht passieren, denn SPI ist ohne ERHEBLICHE Klimmzüge NICHT doppelt nutzbar, sprich NICHT reentrant! Es muss immer erst ein SPI-Zugriff beendet werden, eher ein neuer erfolgen kann, egal wer das macht. > Aber genau weiß ich das nicht - tatsächlich muß ich nochmal genauer > drüber nachdenken. Wenn ein RFM dranhängt, kann der natürlich was > empfangen, interruptet, AUA! Es UNTERBRICHT! > holt sich im Interrupt das Statusword mit der > Interruptquelle und stellt damit auf das langsames SPI um. Und was macht dein toller Interupt, wenn gerade eine SPI-Übertragung läuft? > Dann setzt > er ein Flag und verläßt den Interrupt. > Wenn da gerade von SPIFlash ein Block gelesen wird, wenn der Interrupt > kommt, kehrt er zurück in diese Flash-Routine - dann aber halt mit > langsamerer SPI-Geschwindigkeit. Nö, das geht so nicht, denn dein Flash ist ja gerade aktiviert worden, CS ist LOW und du bist mitten in der Befehlssequenz. > Da wäre das zurückschreiben am Ende des Interrupts (bzw. in der > SPI-Leseroutine) schon sinnvoll. Nö, es geht PRINZIPIELL nicht so! > Oder könnte ich auch nur ein Flag > setzen und dann auch das Statusregister erst in der mainloop lesen, Das wäre eine Möglichkeit. > aber > da war irgendwas Zeitkritisches beim RFM mit dem kleinen FiFo. Mag sein, aber deine oben beschriebene Lösung funktioniert so NICHT!
Eine mögliche Lösung wäre, per Flag ein Zeitfenster freizugeben, indem garantiert KEINE Interrupt vom RFM12 Modul ausgelöst werden (weil sie gesperrt sind). Das kann man u.a. dadurch erreichen, indem man VOR einem SPI-Zugriff auf andere Module erstmal das RFM12 auf kritischen FIFO-Stand prüft. Dazu braucht es nicht mal einen Interrupt. Danach hat man x ms Zeit, andere Sachen mit dem SPI zu machen.
Wenn es zeitkritsch ist, benutzt man besser mehrere SPI. Z.B. der ATmega2560 kann bis zu 5 SPI-Master bereitstellen.
Falk B. schrieb: > Nö, das geht so nicht, denn dein Flash ist ja gerade aktiviert worden, > CS ist LOW und du bist mitten in der Befehlssequenz. Ok, DAS ist tatsächlich wahr. Dann knallt es sogar hardwaremässig an den MISOs, die dann beide nicht tristaten. Böse. > Mag sein, aber deine oben beschriebene Lösung funktioniert so NICHT! Sagen wir so: Das Zeug läuft seit Jahren so, aber ich hatte mit diesen TFTs Ärger beim Programmieren bis sie gut liefen (ein RFM12 hing da nicht dran). Tatsächlich habe ich nicht an die CS-Leitung gedacht, da war Dein Beispiel sehr einleuchtend. Peter D. schrieb: > Wenn es zeitkritsch ist, benutzt man besser mehrere SPI. Z.B. der > ATmega2560 kann bis zu 5 SPI-Master bereitstellen. Das war auch mein neuer Ansatz und deshalb bin ich auf STM32 mit 6 SPIs umgestiegen, von denen ich bisher maximal 5 benutzt habe. Die 'alten' F407 benutze ich dann für solche Zwecke besser nicht mehr. Eine zeitlang hatte ich auch die Routinen gelockt mit einem busyflag, was erst die SPI freigab, wenn eine Aktion komplett abschgeschlossen war, aber das geht schlecht bei zeitkritischen Sachen. Danke für euren Input. Die SD-Card und das Flash von diesen Displays mache ich beim nächsten Mal separat an andere SPIs, der Touch darf bleiben :-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.