SD card problem with two cogs
AP
Posts: 24
This is a copy of PM I sent to Rockiki... perhaps someone else·on here will offer insight... I could not find an answer or discussion on this problem.
I am using fsrw.spin, and it is GREAT... problem is if I mount an SD card in one cog, open a file do some business then pclose that file, I cannot access any files using another cog. It is as if somehow the SD card is locked for only the first cog that mounted and accessed it. I tried toggling the IO states of the 4 pins connected to the SD socket (Sparkfun's micro SD socket) to see if this might somehow "unmount" the card or free it up, and BTW I was wondering why no "unmount" pub method (I perhaps don't know enough, so am asking a naive question). I'm using 20k pullups, and 150 Ohm resistors between the prop and SD card.
I can use said cog#1 to open file A, do some business and close file A, then open file B, C, D, etc.... Problem is just cannot get a 2nd cog to be able to access the SD card. What I desire to do is have cog#1 (arbitrary name assigned to this cog) read in some constants from 2 different .txt files, then later cog#2 periodically reads data from a 3rd file in the background, so as to not disturb activities on cog#1. All of this works great individually, I just cannot implement it all together.
I resist copying lots of code here, or telling which IO pins etc... because the fsrw works well for me except when I try to have a 2nd·cog access the card. BTW, I never have the two cogs·try access simultaneoulsy, I have always closed the open file before trying to get cog #2 using the card.
Am I missing something? I didn't see this sort of thing mentioned on this forum or in the documentation you put with your SD object library.
Thank you,
Dean
Post Edited (AP) : 10/10/2007 7:00:16 AM GMT
I am using fsrw.spin, and it is GREAT... problem is if I mount an SD card in one cog, open a file do some business then pclose that file, I cannot access any files using another cog. It is as if somehow the SD card is locked for only the first cog that mounted and accessed it. I tried toggling the IO states of the 4 pins connected to the SD socket (Sparkfun's micro SD socket) to see if this might somehow "unmount" the card or free it up, and BTW I was wondering why no "unmount" pub method (I perhaps don't know enough, so am asking a naive question). I'm using 20k pullups, and 150 Ohm resistors between the prop and SD card.
I can use said cog#1 to open file A, do some business and close file A, then open file B, C, D, etc.... Problem is just cannot get a 2nd cog to be able to access the SD card. What I desire to do is have cog#1 (arbitrary name assigned to this cog) read in some constants from 2 different .txt files, then later cog#2 periodically reads data from a 3rd file in the background, so as to not disturb activities on cog#1. All of this works great individually, I just cannot implement it all together.
I resist copying lots of code here, or telling which IO pins etc... because the fsrw works well for me except when I try to have a 2nd·cog access the card. BTW, I never have the two cogs·try access simultaneoulsy, I have always closed the open file before trying to get cog #2 using the card.
Am I missing something? I didn't see this sort of thing mentioned on this forum or in the documentation you put with your SD object library.
Thank you,
Dean
Post Edited (AP) : 10/10/2007 7:00:16 AM GMT
Comments
Most of the I/O routines written so far are not designed to be used by more than one cog. That's not to say that it can't be done, but they've not been designed or written for that.
FemtoBasic uses a different set of low level I/O routines that can be "unmounted", then a new mount of the device can be done from another cog (you can't just open a new file ... although the mid level routines could be modified to allow this).
You should be able to use the FemtoBasic routines in place of the version that Rokicki posted to the Object Exchange. Have a look at them.
doesn't lock-up when you start the program without an SD card installed...
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Mike - looking back, i realize that because one of my SD objects is started in a cog, does its thing (upload data from .txt file into RAM array) then a cogstop is issued, the SD card is not locked; I can issue another call of that same object later on and pull other data fro SD card into RAM, etc... The problem is when cog#1 (the "top level" cog if you will) tries to also access the SD card via fsrw first... Sd is locked then when other cog is called upon to run the object to open SD card, issues insue.
Oldbitcollector - that is great to know. I will definately look into the femtobasic version!
Dean
No, AP this has only to do with VARs and DATs in multiply instantiated objects. You can read through the releated threads and can even try to fix this issue, it is not difficult.
Mynet43 has prepared a Q&A article along Float32 about it - ask him by PM if this should not yet been posted somewhere...
On the lockup with no SD card---that should not happen; everything should be timed out appropriately
(even if the timeout is in the seconds). Perhaps somewhere someone is not catching an abort?
The easiest thing to do would be to use a DAT section for the fsrw variables. It's not like you would normally have two SD cards attached to a Propeller and need two instances of the VAR area, one for each.
FemtoBasic avoids the lockup problem by using a different low-level driver
Yes, that was it, I dropped that code assuming that it wasn't needed.. Thanks!
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
1. Stopping/starting the low-level cog (should be straightforward);
2. Sharing the fsrw object itself without replicating the data (or providing an
option on this, for those who want to connect multiple SD cards
concurrently);
3. Synchronizing access between multiple cogs, as needed, for
concurrent access (say, log writes to the same file);
4. Documentation on all of this; what works, what doesn't, how to do
different things, and what specifically to avoid.
For specific single issues, I can review and give an opinion on how to
proceed (such as other people have already stepped in and done,
thanks!).
projects and commitments; generally when I get emails saying "I need this" from several people, well, that's
what gets my time.
I haven't scheduled more work on fsrw yet (that is, I do not plan to work on it this weekend) but knowing
people are using it and breaking it (!) is very useful and will bump it up on my priority list.
Oldbit
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Thanks
-Kit
I tried the Femto versions of fsrw... was basically drop-in except I had to add the start method... was able to have cog#1 read in a couple .txt files, then "unmount" the SD card, then have cog#2 open a third .txt file. Worked like a charm! My multi-week problems are over.
Sincerely,
Dean
The general code was like this:
PUB MAIN | index, temp debug.start(38_400) waitcnt(clkfreq*5 + cnt) sdfat.start(@IoControl) '' Had to add the start method sdfat.mount(24,25,26,27) '' "normal" mount of SD card, my 4 IO pins, 20k pullups, 150 Ohm between Prop and SD pins sdfat.popen(@file1,"r") '' Open file#1 repeat temp := sdfat.pgetc '' get single character from open file on SD card CASE temp -1 : quit '' QUIT the loop if last character reached 10 : NEXT '' if <LF> is encountered don't debug print, because 13 (<CR>) already encountered debug.putc(temp) '' print to debug terminal the current character from open file sdfat.pclose '' close the current file repeat 5 '' generate a few blank lines debug.putc(13) sdfat.popen(@file2,"r") '' open file #2 repeat temp := sdfat.pgetc CASE temp -1 : quit 10 : NEXT debug.putc(temp) sdfat.pclose repeat 5 '' some more blank lines debug.putc(13) sdfat.unmount '' unmount the SD card from cog#1 flag := 0 '' set to FALSE a "done" flag for new object in cog#2 cog2read.start(@var1, 0, 40, 0, @array1, @array2, @var2, 27, 26, 25, 24, @file3, @flag) '' start other SD object in cog#2 repeat until flag '' wait until cog#2 sets flag to TRUE (done) repeat index from 0 to 39 '' debug out the array loaded by cog#2 from 3rd SD file debug.dec(array1[noparse][[/noparse]index*5 + 0]) debug.putc(32) debug.dec(array1[noparse][[/noparse]index*5 + 1]) debug.putc(32) debug.dec(array1[noparse][[/noparse]index*5 + 2]) debug.putc(32) debug.dec(array1[noparse][[/noparse]index*5 + 3]) debug.putc(32) debug.dec(array1[noparse][[/noparse]index*5 + 4]) debug.putc(13)Post Edited (AP) : 10/11/2007 1:48:54 AM GMT
and currently the propeller has no simple ability to only include the bits you actually need. And for *most*
embedded uses, directories are not really needed.
But as usual, I'm happy to listen to the collective wisdom. Adding directory support would not be that hard, but
there's a lot of pieces that are needed (make directory, remove directory, change directory, filename parsing
is different, do you automatically add . and .. (you probably need to), etc. etc.)