PDA

View Full Version : 2 x Prop1 sharing 1 uSD



MacTuxLin
11-17-2011, 08:46 AM
Has anyone successfully access a single uSD card using either FSRW or Kye's SD-MMC_FATEngine with dual Prop1? I reckon only a single Prop1 can access the uSD card at anyone time?

Duane Degn
11-17-2011, 09:17 AM
I've actually wired up several different pairs of Props to share a single SD card but I never got as far a coding a way for them to share. Something always made me change my mind about sharing the SD card.

I planned to have the Props signal each other so they would know which Prop could access the card when. I think you'd want to make sure all shared pins on one Prop were inputs while the other Prop used the SD card.

I agree with your view that two Props could share a SD card as long as they weren't both trying to access it at the same time.

I might try this tomorrow.

MacTuxLin
11-17-2011, 09:30 AM
Thanks Duane. Yes, I've setup a communication protocol between the 2 Prop1s which also includes signaling who gets to access which shared devices. I'll design in at first but will proto-type this sharing next week too.

Ale
11-17-2011, 10:32 AM
If you have a nice and fast (say 4 bit) comm port between props, I really do not see the advantage of two props sharing the card. Specially with the overhead involved...

MacTuxLin
11-17-2011, 12:06 PM
Thanks Ale. You have your point but the usage is rather different in this case.

prof_braino
11-17-2011, 12:50 PM
Has anyone successfully access a single uSD card using either FSRW or Kye's SD-MMC_FATEngine with dual Prop1? I reckon only a single Prop1 can access the uSD card at anyone time?

Not with FSRW or Kye's SD-MMC_FATEngine, but propforth uses a scheme where one cog does the driver for the SD, and the other cogs just send commands and recieve data.
The prop-to-prop interface is the high speed synchronous serial, so talking to a cog on a different prop appears the same as a cog on the local chip.
The parts are there, but it hasn't been built into a good example application yet, so there is still some work to do.
And of course its in forth.

Kye
11-17-2011, 01:45 PM
You could try it. I designed my file system driver to relase all the I/O pins once it's done communicating. It should actually work as long as neither fights.

MacTuxLin
11-17-2011, 01:51 PM
The prop-to-prop interface is the high speed synchronous serial, so talking to a cog on a different prop appears the same as a cog on the local chip.
The parts are there, but it hasn't been built into a good example application yet, so there is still some work to do.
And of course its in forth.

Hmm, might be a good time to try PropForth. The only time I've tried Forth was on a Mac. Thanks.

MacTuxLin
11-17-2011, 01:54 PM
You could try it. I designed my file system driver to relase all the I/O pins once it's done communicating. It should actually work as long as neither fights.

Thanks Kye. Yeap, I'll make sure only 1 of them gets to access it at any one time.

Kye
11-17-2011, 06:14 PM
I would check the I/O lines on the scope and read through the ASM code in the driver before doing this. It will pay to make sure everything will work first before trying.

Maybe also have some 100 ohm resistors in line with the SCLK, and DI lines. DO is driven by the card and CS is open drained by my driver.

MacTuxLin
11-18-2011, 12:13 AM
Got it. Thanks!

frank freedman
11-18-2011, 05:00 AM
I would check the I/O lines on the scope and read through the ASM code in the driver before doing this. It will pay to make sure everything will work first before trying.

Maybe also have some 100 ohm resistors in line with the SCLK, and DI lines. DO is driven by the card and CS is open drained by my driver.

If you do get 2 props sharing the SD card, your logic will need a way of knowing that it is not clobbering the area in use by the other prop (a feature known as mad brain in HA systems where the backup processor on a shared disk array would think the main unit failed while the main unit is still functioning and they begin scrambling the shared disk space) even though your hardware could guarantee that they both do not try simultaneous access.

Good luck,

Frank

MacTuxLin
11-18-2011, 06:36 AM
Thanks Frank. In this setup, I won't be going that far but a simple comm between the two e.g.:

P2: "I need to use, are you using?"
P1: "I'm using, you wait" ...
P1: "OK, I'm done, you still want it?"
... Something along that line ...

Hello Kye,
I'll scope it next week but I've briefly read thru the ASM. I have a question & please correct me if I'm wrong:

Assuming P1 is waiting (CIDCompareLoop), I should check for any cardErrorFlag before passing control to P2, right?

Kye
11-18-2011, 01:47 PM
Um, no...

Just make sure to check the "partitionError" function to see if any command failed after being called.

Note: that my driver has write acceleration (meaning some functions return before the write has completed which will happen in the background)... so if you want to ensure that the block driver has released the card always unmount (by calling the "unmount" function) after using the card.

If you need directory support doing this then just use the path name feature (instead of "open("file")" do "open("folder/folder/file")"). This is because the current directory will get reset back to the root after each umount.

MacTuxLin
11-18-2011, 02:02 PM
Oh, thank you very much Kye. That might have saved me potential hours of pain ......