HIVE-Project

Hi Leute,
ich habe folgendes Problem, bedingt durch meinen Hardwareaufbau und sehe mittlerweile den Wald vor Bäumen nicht mehr:
Ich habe über ne CPLD, die im konkreten Zusammenhang als Multiplexer fungiert, an den gleichen Propeller-Pins sowohl eine SD-Card
zu hängen und quasi gleichzeitig unter Mitverwendung der Pins einen anderen Prozessorbus, auf den ich von SD gelesene Daten byteweise rüberschubsen möchte.
Das geht im Prinzip schon soweit, das ich die SD-Karte starte, File öffne und in einen Puffer (1k) einlese, dann Karte stoppe und auf den anderen Bus den Puffer schreibe.
Aber was mache ich bei mehr als Puffergröße?! Benanntes Spielchen einfach mehrfach hintereinander kann ich nicht, weil ja die DAtei immer wieder geschlossen und neu geöffnet wird. Und ich weiß nicht, ob und wie ich einen Zeiger benutzen kann, um gezielt Bytes ab einer bestimmten Stelle der Datei in den Puffer einzulesen. Gibt es da schon vorhandene Möglichkeiten in den Routinen? Also sowas wie read_file_ab adr?
Ich nutze ne fsrw-spin v1.6. Muss ich da vielleicht was anderes nehmen?

Grüße Uwe

Fährst Du nur SPI über die gemeinsamen Pins?

Die Karte hat einen ChipSelect und solange sie darüber nicht selektiert ist, soll sie alles ignorieren, was auf MISO/MOSI/CLK für andere Nachbarn passiert. Ob während sie deselektiert ist überhaupt SPI über die anderen Pins gefahren wird, ist ihr vermutlich auch total egal.

...oder erzähl mal etwas mehr über das Verhalten des Muttiplexers...

Wie yeti schon schreibt: Musst Du die Datei wirklich schließen und die Karte unmounten? Wenn Du nur liest und Dich darauf verlassen kannst, dass zwischen Weg- und wieder Zuschalten der SD-Card keine Datei geändert wird, ist es doch eine Sache der Variablen im Dateisystemtreiber, festzulegen, welche Datei gerade an welcher Position im Zugriff ist. Guck Dir mal fsrwx.spin aus Spinix an. Dort wird zwischen geöffneten Dateien hin und her geschaltet, indem dem eingentlich dazu unfähigen Treiber seine globalen Variablen unterm Allerwertesten getauscht werden.

Und wenn das alles nicht hilft, musst Du beim Wiederöffnen der Datei seek() benutzen. Das findest Du hoffentlich in der Version deines fsrw, ansonsten siehe Spinix.

Viele Grüße,
u-held

Hallo Leute,
danke für die Antworten. Ich hatte gerade eine ellenlange Hardwarebeschreibung hier eingetippt, wurde aber scheinbar zwischendurch rausgeschmissen. jetzt ist der lange Text futsch und heute habe ich keine Lust mehr von vorne anzufangen.
Das mit dem seek() könnte ne Lösung sein. Habe das aber noch nie benutzt. Setzt das einen Zeiger auf eine Adresse/Stelle in der geöffneten Datei?

Grüße Uwe

PS. Morgen tippe ich die Beschreibung meiner Hardware und was das leisten soll nochmal ein.

Ich binn mir zwar nicht sicher aber war seek nicht dafür da gezielt Sectoren von der Karte anzusprechen?
Eine weitere frage ist ob da mehrere COGs auf die gleichen Pins zugreifen.
Wen Ja so könnte man in kartentreiber ein art Control und Status Byte einrichten.

Jawoll!! seek(adresse des ersten zulesenden Bytes in der Datei) das isses!
Das löst auf einfache Weise mein Problem.
Pic hat vollkommen recht mit der Doppelbenutzung der IO-Leitungen durch mehrere (genau 2) Cogs. Darin, und in der Tatsache, dass sich auf den gemeinsam genutzten Leitungen (bei mir also zwischen einer CPLD und dem Prop) sowohl SPI-Daten, als auch andere Daten mit anderer Datenflussrichtung auf den Leitungen, tummeln liegt das eigentliche Problem. Und deshalb funzt es immer dann, wenn ich stur nacheinander SD-Karte öffne, Datei lese, dann SD-Karte schließe, gelesene Daten wegschreibe und dann da capo al fine mache.
@ Pic: Die Variante von mit dem temporärem Wegschalten der io's in der sdspi-routine hat nicht so sauber gefunzt.

Ich denke, ich patche lieber nicht in den fast als Standard geltenden fsrw-Routinen rum, sondern mache es ganz klassisch. Mit dem seek() kann ich dann ja immer an der richtigen Stelle der Datei das Lesen sozusagen fortsetzen.

Grüße und ein nicht so heißes WE wünscht

Uwe

yeti hat geschrieben:............ Ob während sie deselektiert ist überhaupt SPI über die anderen Pins gefahren wird, ist ihr vermutlich auch total egal..........

So ist es ........fast....... Bei meinem C3-ähnlichen SPI-Bus mit dauerverdrahteten SPI-Flash- und RAM-Chips läuft RX/TX/Reset zu SD-Modulen (statt SD-Karte) wie CP/Mchen und Arduinchen allerdings über einen 74(A)HC125 auf dem Modul als Torwächter. Der Torwächter sperrt den Bus auf dem Modul gegenüber dem Elderberry wenn auf die Flash und RAM-Chips mit SPI zugegriffen werden soll. Der 74(A)HC125 schaltet die Ausgänge (MISO/RX (zum Prop)) auf high-impedance während der Zustand der Eingänge (H/L) der Gatter (MOSI/TX(zum Modul) und SCLK/Reset) egal ist. Bei den SPI-Flash- und RAM-Chips wird bei Deselection auch die (MI)SO-Leitung(en) auf high impedance geschaltet. Die Eingangsleitung(en) (MO)SI und SCLK stört ein Signal in akzeptabler Höhe (max Level) nicht.
I2C sollte auch gehen aber dazu bedarf es einen I2C-tauglichen Torwächter, z.B. I2C Leitungsverlängerer mit CS-Eingang.
Noch eine kleine Anmerkung :
Ich bevorzuge die SD-MMC_FATEngine von KYE, da er seine Programme vorbildlich dokumentiert und diverse zusätzliche Funktionen gegenüber fsrw bereitstellt. Der größte Vorteil ist jedoch die Verwendung von Subdirectories.
Gruß
TuxFan

TuxFan,

kannst Du die SD-MMC_FATEngine von KYE hier mal anhängen?

PIC18F2550 hat geschrieben:kannst Du die SD-MMC_FATEngine von KYE hier mal anhängen?

[OBEX] FAT16/32 Full File System Driver
By: Kwabena W. Agyeman, created: 2013-03-27 | updated: 2013-05-07
...könnt's wohl sein.
Im Forum fand ich nicht schnell genug Besseres.
TuxFan hat vielleicht Neuereres aus irgendeinem Thread geangelt und/oder bessere Bookmarks?

So schluderig wie Parallax mit Software umgeht, sollten wir langsam mal ein eigenes Archiv anlegen...
Da isser wieder, mein Parallax-Blues!

——————————
Edit... was schreib ich?
Der in der OBEX angegebene Link auf AN006 zeigt ins Digiwana!
Das hab ich aber irGÄHNdwo lokal gebunkert...
Moooment...

Also besser hurtigst alles Gefundene hier anbäppen!

Good evening!
Der Treiber, den Yeti angehängt hat, ist auch der von mir derzeit benutzte. Einen neueren hab ich bisher nicht gefunden. Ich hab nur ein paar Durchreichfunktionen eingefügt um auf die RTC auch vom Hauptprogramm aus zugreifen zu können. Ich hab noch keine Funktion gefunden, um auf ein Objekt zwei Etagen tiefer zuzugreifen. Falls jemand etwas darüber weiß, bitte melden.Bin für jeden Tipp dankbar.
Ich bin derzeit dabei meinen Propeller getriebenen Webserver (WebProp), nach Jahren mit Großbaustelle ohne Programmieren, endlich fertig zu stellen. Dabei hab ich auch das Programm von ehemals fsrw auf SD-MMC_FATEngine umgestellt. Läuft bisher bestens.
Gruß
TuxFan