Shop OBEX P1 Docs P2 Docs Learn Events
2 x Prop1 sharing 1 uSD — Parallax Forums

2 x Prop1 sharing 1 uSD

MacTuxLinMacTuxLin Posts: 821
edited 2011-11-18 07:02 in Propeller 1
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?

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-11-17 02:17
    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.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2011-11-17 02:30
    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.
  • AleAle Posts: 2,363
    edited 2011-11-17 03:32
    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...
  • MacTuxLinMacTuxLin Posts: 821
    edited 2011-11-17 05:06
    Thanks Ale. You have your point but the usage is rather different in this case.
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-11-17 05:50
    MacTuxLin wrote: »
    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.
  • KyeKye Posts: 2,200
    edited 2011-11-17 06:45
    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.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2011-11-17 06:51
    prof_braino wrote: »
    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.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2011-11-17 06:54
    Kye wrote: »
    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.
  • KyeKye Posts: 2,200
    edited 2011-11-17 11:14
    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.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2011-11-17 17:13
    Got it. Thanks!
  • frank freedmanfrank freedman Posts: 1,983
    edited 2011-11-17 22:00
    Kye wrote: »
    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
  • MacTuxLinMacTuxLin Posts: 821
    edited 2011-11-17 23:36
    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?
  • KyeKye Posts: 2,200
    edited 2011-11-18 06:47
    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.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2011-11-18 07:02
    Oh, thank you very much Kye. That might have saved me potential hours of pain ......
Sign In or Register to comment.