Shop OBEX P1 Docs P2 Docs Learn Events
Seeking Advice for small SDCard Object for accessing the Spinner based SDcard — Parallax Forums

Seeking Advice for small SDCard Object for accessing the Spinner based SDcard

JohnR2010JohnR2010 Posts: 431
edited 2011-09-01 09:30 in Propeller 1
I’m currently using Kwabena Agyeman’s S35390A FATEngine.SPIN to access the SDCard on my Spinner server and it works great. Too good in fact I hate to let it go. My code is growing and I need more room in RAM for SPINN code. The FATEngine.SPIN is H U G E and I have spent some time looking on the OBEX for an alternative and I thought I would seek the advice of this forum before I just pick one and start basing my code on it. Kwabena’s code is absolutely rock solid and very easy to workwith he did a great job!! I’m looking for the same quality of code but I don’t need all the functionally in his FATEngine.SPIN. I could get by with just accessing the root directory and sticking with a FAT16 no FAT32 to reduce the size.

Any Suggestions?

Thanks

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-08-25 09:19
    The main alternative to Kye's driver is the one written by Rokicki, also in the Object Exchange. It also supports FAT32, but not subdirectories and it's quite a bit smaller. The only other alternative is the SD card driver in Sphinx. It's probably not what you want, but it has the advantage that it gets loaded into 3 cogs during initialization and requires only 1K of hub RAM after that (for buffers).
  • KyeKye Posts: 2,200
    edited 2011-08-26 13:32
    Just comment out any public functions you don't need. If the code still compiles then life is good. ALSO: BST will automatically remove used code that is not needed if you use it to compile.

    Removing the lower level features will just make your device unreliable. So the best approach is todo what I mention above.
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-08-26 13:45
    I agree with Kye. Use bst. Not sure if you have to check the remove unused code option.
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-08-26 13:57
    An alternative is to use the SD as "internal to the prop". This way, you don't even need FAT16, the prop just accesses and manages the disk blocks directly. Its very fast and tiny, as it eliminates all the overhead beyind the SD itself. To get to the SD, you talk to the COG and the cog handles the SD. As long as leave the SD in the prop socket, everything is golden. The only issue is you give up the option of popping the SD out of the prop and into the PC for transfers, but it can be well worth the trade off.

    The propforth SD test in the regression suite shows how this can be done using the spinneret. You can use the forth as an example if you prefer to re-do it in spin.
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-28 07:24
    Kye, Thanks very much for the input!! All I had to do was just compile my code with the BST and it more than doubled the available memory. I haven’t even remarked out the unused code yet. This should do the trick!
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-28 07:26
    Cluso99 wrote: »
    I agree with Kye. Use bst. Not sure if you have to check the remove unused code option.

    Thanks Cluso I did check this option as you suggest and it did the trick!! Great input! I’m back up and going!!
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-28 07:29
    prof_braino wrote: »
    An alternative is to use the SD as "internal to the prop". This way, you don't even need FAT16, the prop just accesses and manages the disk blocks directly. Its very fast and tiny, as it eliminates all the overhead beyind the SD itself. To get to the SD, you talk to the COG and the cog handles the SD. As long as leave the SD in the prop socket, everything is golden. The only issue is you give up the option of popping the SD out of the prop and into the PC for transfers, but it can be well worth the trade off.

    The propforth SD test in the regression suite shows how this can be done using the spinneret. You can use the forth as an example if you prefer to re-do it in spin.

    I like this idea! For this project I need the file access as I’m serving XML and HTML files from the SD Card. This allows me to create web pages on my desktop and copy them to the card for distribution. Thanks I will keep this in mind for a future project!
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-28 07:31
    Thanks Mike I had my eye Rokicki's object and this is my fall back. I got some great input on the BST and going down that route for now. Thanks very much for your time!
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-28 07:37
    Guys this is solved thanks!
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-28 08:23
    I spoke too soon! When I (F11 Compile and Load) my program with the BST it corrupts my program. When it boots up on the Spinner it’s just spewing random hex code. I have never had this happen with the Parallax compiler and I don’t want to spend time troubleshooting someone else’s program. It happens every time I compile either with F10 RAM only or F11. If I unselect “Eliminate unused SPIN methods” it compiles and runs just fine. I knew this was too good to be true. Unless anyone has a suggestion on something I overlooked BST is heading for the Dumpster.
  • Mike GMike G Posts: 2,702
    edited 2011-08-28 08:46
    JohnR2010, that's all I did... Commented out methods in Kye's Fat driver. It works fine. You must have commented too much :)
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-29 05:43
    Mike G wrote: »
    JohnR2010, that's all I did... Commented out methods in Kye's Fat driver. It works fine. You must have commented too much :)

    That’s just it I didn’t comment out anything I just selected the option to remove unused code. It works great when that is not selected. I’m a little concerned about using a non-Parallax compiler I don’t want to interject bugs into my code. Have you had good success with the BST? Is it a proven stable development environment? I’m on Windows 7 if that makes a difference. All the conversations I see on the BST thread seem to be around the Mac version.

    If this has been rock solid for people then I will dig into what the heck is going on in my version. If you see bugs every now and then I don’t want to mess with it. Thanks very much!
  • Mike GMike G Posts: 2,702
    edited 2011-08-29 05:53
    Have you had good success with the BST?
    I've only used the Propeller Tool.
  • kuronekokuroneko Posts: 3,623
    edited 2011-08-29 16:16
    JohnR2010 wrote: »
    I spoke too soon! When I (F11 Compile and Load) my program with the BST it corrupts my program. When it boots up on the Spinner it’s just spewing random hex code. I have never had this happen with the Parallax compiler and I don’t want to spend time troubleshooting someone else’s program. It happens every time I compile either with F10 RAM only or F11. If I unselect “Eliminate unused SPIN methods” it compiles and runs just fine. I knew this was too good to be true. Unless anyone has a suggestion on something I overlooked BST is heading for the Dumpster.
    Just thinking aloud here. I'm not necessarily saying that it isn't BST's fault (personally I had never issues with dead code removal though). What if you have some form of memory corruption which so far was hidden by just eating dead code? Now that this food source is gone it will obviously affect required functionality.
  • localrogerlocalroger Posts: 3,452
    edited 2011-08-29 16:25
    There's another approach to eliminate the FAT16 driver. If you can ensure that all your FAT16 files are contiguous, you can stash pointers and links to them somewhere, such as the first few root DIR entries in conveniently fixed locations, and simply ignore the actual FAT. Windows doesn't give you the tools for arrange a SD card so precisely, but you could write a separate Propeller application to take the possibly non-contiguous files saved by Windows with possibly wrong directory pointers and sort them so that your real application can get to them easily. This could be done in such a way that Windows can still get to the files too.
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-30 05:48
    I like this idea. My fear is if I go down this route I will be spending days digging into the File Allocation Table learning all the ins and outs of good ole DOS and unfortunately i don’t have the time for this project. I want to get this to the testing stage in a week or two. I haven’t worked with DOS enough to be able to pull something like this off. But a slight twist on your idea I could see pulling off. How about just writing and reading data to/from the SD card in my own propriety format and then using another Propeller App with KYE's SD object to rewrite the data onto the SDCard in proper DOS format! This gives me the best of both worlds and keeps my code small and manageable. Thanks for the input!!
  • KyeKye Posts: 2,200
    edited 2011-08-30 05:53
    Far easier just to comment out unused function calls.
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-08-30 06:27
    Kye wrote: »
    Far easier just to comment out unused function calls.
    Kye just to make sure I understand what your suggesting: If I'm using the propeller tool v1.3 I just can’t comment out your public SPINN methods in your SD object I need to go to the ASM code as well and comment it out right? That is the part I’m not comfortable with I hate to admit that but I’m just not comfortable down in the machine language and don’t want to introduce new problems. The second option is to use the BST to compile the code and allow it to take out unused code. I tried that route and the BST won’t compile and run on my Spinner with the option set to take out unused code. Let me know if I'm missing something and thanks!!
  • KyeKye Posts: 2,200
    edited 2011-08-30 11:33
    No, you don't touch the ASM. You only comment out the PUB functions you never call in your code. If the code does not compile uncomment the function the compilier complains about.

    BST only removes unused public functions... nothing else. Touching the ASM or PRI functions will break stuff always.
  • localrogerlocalroger Posts: 3,452
    edited 2011-08-30 11:48
    JohnR2010 wrote: »
    How about just writing and reading data to/from the SD card in my own propriety format and then using another Propeller App with KYE's SD object to rewrite the data onto the SDCard in proper DOS format!

    Here's another idea: If you reformat the SD card so that the whole thing isn't used, you will have a bunch of sectors above the top of the file system which the OS will never touch. All you need to know is where the empty space starts and you can write directly to those sectors with your very simple code, use Kye's SD driver to do the conversion to regular FAT, and put the same card in your PC adapter without messing up the original data.
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-09-01 04:58
    Kye wrote: »
    No, you don't touch the ASM. You only comment out the PUB functions you never call in your code. If the code does not compile uncomment the function the compilier complains about.

    BST only removes unused public functions... nothing else. Touching the ASM or PRI functions will break stuff always.

    Thanks Kye I will comment out the methods i don't use and see how far I get. Sorry i didn't get back to you yesterday I been head deep in HTTP Response formatting and coding the last two days. Thank god for Mike G - Multi-Socket Server!! Thanks again for all your help!!
  • JohnR2010JohnR2010 Posts: 431
    edited 2011-09-01 09:30
    How the heck to you change the status of the this post from unsolved to solved? Man talking about making a guy look stupid i cant find the option.
Sign In or Register to comment.