Hallo zusammen Ich lese via (Hardware-)SPI Daten von einer SD-Karte. Das Lesen erfolgt im Hauptprogramm in einem ATmega32. Zusätzlich möchte ich jetzt in einer Interrupt-Routine Daten an ein anderes IC über den selben SPI senden. Deshalb folgende Frage: Ist es möglich, die Kommunikation mit der SD-Karte (durch ein HIGH-Pegel auf CS) zu einem beliebigen, nicht vorhersehbaren Zeitpunkt zu unterbrechen? Kann der Lesevorgang nachher an der selben Stelle fortgesetzt werden? Beim Schreiben scheint das offenbar nicht zu gehen, siehe: Beitrag "SD-Karte: kann ich einen Schreibzugriff unterbrechen?" aber wie ist's beim Lesen? Ich verwende übrigens zur Ansteuerung die Lib von Ulrich Radig: Beitrag "SourceCode MMC die Zweite" Software-SPI ist aus Performance-Gründen keine Option. Im Voraus Danke für alle Antworten.
Sobald man CS\ der Karte deaktiviert, muss man nochmal von vorne mit dem Sektor anfangen. Falls der Speicher nicht allzugroß sein muss, dann gibt es für diesen Zweck spezielle Flash EPROMs (z.B. M25Pxx) die einen Hold Eingang haben. Solange Hold aktiv ist, kann man zu einem beliebigen Zeitpunkt (sogar mitten in einem Byte) unterbrechen und etwas anderes über den Bus schicken.
Danke für die klare Antwort: >Sobald man CS\ der Karte deaktiviert, muss man nochmal von vorne mit dem >Sektor anfangen. Das ist leider nicht möglich, da die Datenrate sowieso schon ziemlich knapp ist. Die Lösung mit diesem "Flash-Buffer" (falls man so sagen darf) tönt interessant. Gibt dazu irgendwo genauere Informationen?
Matthias wrote: > Die Lösung mit diesem "Flash-Buffer" (falls man so sagen darf) tönt > interessant. Gibt dazu irgendwo genauere Informationen? http://www.st.com/stonline/books/pdf/docs/7737.pdf
Hab mir das Datenblatt mal kurz angesehen, wirklich gut dokumentiert. Allerdings zweifle ich daran, ob der Flash einen dauernden Schreibzugriff lange übersteht. Gibt's vielleicht was vergleichbares mit SRAM statt Flash? Ein anderer Ansatz: Kann ich vielleicht an den AVR extern ein zweites SPI-Interface anbauen (AVR haben ja glaube ich alle nur eines)? Gibts dazu spezielle Bausteine? (Oder realisiert man sowas einfach mit einem PISO-Shift-Register?)
- Du kannst SPI per Software machen. - Einige neuere AVRs können den UART als SPI verwenden - Du kannst auf die neuen ATxmega warten, die haben 4 SPI Interfaces (oder sogar noch mehr)
Den Takt der SD-Karte mit einem AND-Gatter unterbrechen ohne CS auf High zu setzen. Dann das andere Teil bedienen und danach wieder den Takt durch das AND-Gatter zur SD-Karte leiten.
Dann sollte man die Datenleitung aber auch auf tristate schalten.
> Zusätzlich möchte ich jetzt in einer > Interrupt-Routine Daten an ein anderes IC über den selben SPI senden. grundsätzlich ist es kein problem den spi-bus zu sharen. allerdings sollte eine aktion immer erst abgeschlossen werden, bevor ein anderer spi-slave angesprochen wird. d.h. während du gerade einen sektor der sd-karte liest/schreibst, sollte kein anderer den bus benutzen. erst danach wieder.
Das Problem ist nur, wenn z.B. ein DAC seine Daten mit 22kHz haben will. Es klingt ziemlich merkwürdig, wenn bei jedem gelesenen Sektor eine Pause von ein paar ms eingebaut wird...
Der Vorschlag von "Gast" tönt nicht schlecht. Ich frage mich aber, ob das tatsächlich zuverlässig funktioniert. Das Unterbrechen der Taktleitung bedeutet ja in einem gewissen Sinn den Wechsel dar Taktfrequenz von ein paar Megaherz auf null auf einen Schlag. Nicht jede Logik verkraftet das. (Bei den AVRs darf sich der Qurztakt z.B. nur um wenige Prozent innerhalb einer Periode ändern.) Unterdessen habt ihr offenbar auch mein Projekt erraten. Es geht darum WAVE-Files von der SD-Karte zu lesen und dann per SPI (als I2S-Emulation) an einen Audio-DAC zu senden.
> Das Problem ist nur, wenn z.B. ein DAC seine Daten mit 22kHz haben will. > Es klingt ziemlich merkwürdig, wenn bei jedem gelesenen Sektor eine > Pause von ein paar ms eingebaut wird... wie lange braucht denn ein sector read/write bei dir? vielleicht ist es ja schnell genug, so dass du die den DAC noch ungebremst an gleichen bus mit 22kHz bedienen kannst. SD-karten lassen sich ja locker mit 20...25 MHz SPI clock ansteuern bei der taktfrequenz dauert ein sector-R/W von 512bytes nicht all zu lange.
>SD-karten lassen sich ja locker mit 20...25 >MHz SPI clock ansteuern bei der taktfrequenz dauert ein sector-R/W von >512bytes nicht all zu lange. Man kann Daten mit einigen MHz in SD Karten reintakten oder auslesen. Das blöde ist nur das man beim lesen und ganz besonders beim schreiben erstmal warten muss bis die Karte diese Daten auch liefert/annimmt. Wenn nur die SPI Frequenz ausschlaggebend wäre, müssten ALLE SD Karten GLEICH schnell sein. Sind sie aber nicht :(
Peter wrote: > wie lange braucht denn ein sector read/write bei dir? vielleicht ist es > ja schnell genug, so dass du die den DAC noch ungebremst an gleichen bus > mit 22kHz bedienen kannst. SD-karten lassen sich ja locker mit 20...25 > MHz SPI clock ansteuern bei der taktfrequenz dauert ein sector-R/W von > 512bytes nicht all zu lange. Rechnen wir mal: Maximal läuft ein mega32 mit 16MHz, macht 8MHz SPI Clock. Bestenfalls sind also 512µs drin. Falls der mega32 mit 3,3V läuft, sind nur 4MHz drin, also >1ms für einen Sektor. Es ist aber auf jedenfall zuviel. @ Matthias Du könntest den mega324 nehmen. Der hat 2 UARTs, und denen man einen als SPI nutzen könnte. Damit hättest du 2 SPI Ports und alle Probleme wären gelöst. Ich habe vor einiger zeit ähnliches gemacht: Ein Tastatur mit 32 Tasten, ein 2 Kanal DAC und ein M25P40 512kByte Flash Speicher. Auf Tastendruck wird die entsprechende Wave Datei abgespielt. Eigentlich wollte ich dafür eine SD Karte verwenden, aber eben genau wegen dem Problem habe ich den M25P mit dem Hold Eingang verwendet. Damals gabe es noch keine AVRs die den USART als SPI nutzen konnten. Heute würde ich einen mega48/88/168 nehmen.
> Wenn nur die SPI Frequenz ausschlaggebend wäre, müssten ALLE SD Karten > GLEICH schnell sein. Sind sie aber nicht das ist richtig. im schnitt schaffen sie aber alle an die 200...300 kB/s beim lesen, also etwa (grob geschätzt) 500 sector-read operationen pro sekunde. sollte das nicht ausreichen? ich würde es mal durchrechnen bzw. ausmessen, bevor ich irgendwelche verrenkungen anstelle, die vielleicht gar nicht nötig sind.
Genau, ich werde wohl auf den mega324 oder mega644 migrieren. Deren Hardware-Ausstattung tönt sehr verlockend: 2 USART und 1 SPI. Ich kann also ein USART als SPI nutzen, sodass ich davon zwei habe, und das andere als RS232-Verbindung für Debugging etc. Super! Wenn ich das Datenblatt des mega324 beim ersten Durchschauen richtig verstanden habe, ist die einzige Einschränkung bei der Verwendung des USART als SPI im Vergleich zum "richtigen" SPI, dass es nur im Master-Modus verwendet werden kann, was aber für meine Anwendung komplett egal ist. Sonst ist nur die Ansteuerung (Registernamen etc.) etwas anders. Stimmt das so, oder gibt es noch andere Unterschiede?
Benedikt hat Recht mit den Tristates. Ich hatte genau das gleiche Problem und habe das hier gefunden: http://www.shop.display3000.com/pi8/pi14/pd102.html Dort gibt es eine fertiges Kartemodul mit Tristate Ausgängen. Habe ich mir selber vor einer Woche bestellt und gestern bekommen. Das ist meines Erachtens der einzige Weg um mehrere Geräte am SPI Bus zu betreiben denn sonst werden die sich immer gegenseitig stören. Oli
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.