Shop Learn P1 Docs P2 Docs
The actually functional Spin2 SD Driver (I hope) (KyeFAT+ sdspi_with_audio) - Page 2 — Parallax Forums

The actually functional Spin2 SD Driver (I hope) (KyeFAT+ sdspi_with_audio)

2»

Comments

  • RaymanRayman Posts: 12,734

    I see what you mean about FSRW port... Dug it up yesterday while resurrecting some hyperram code (in hopes of converting to 8-bit PSRAM).
    It doesn't work with Prop Tool at all. Seems we were using an old version of PNut, last time used it.

    This code here looks like a port of Kye's P1 sd code for the top level with an assembly low level code from FSRW with some audio stuff mixed in.
    This is all good.

    Think I'll try to fix FSRW though. A quick archeological look seems to point to the new Spin2 dialect being the problem.
    Might just be that things like sign extension need fixing. Hope it's easy, or I'll be coming back here for this code. Would be nice to have version that didn't need a cog...

    FSRW, when it worked, had two low level options, one that used a cog and one that didn't.
    Could the code here work with the FSRW low level driver that didn't need a cog?

  • Wuerfel_21Wuerfel_21 Posts: 3,038
    edited 2022-07-11 14:18

    I think it just calls into the block driver to read/write blocks. So I guess yea.

    FSRW is just bad IMO (the FAT layer, as it were). No directory support and consequently lets you do stupid things like creating a file with slashes in the name.

  • RaymanRayman Posts: 12,734
    edited 2022-07-12 13:58

    Trying to figure out Kye's code (never used it before), noticed something:

    If you do FATEngineStart() with readOnly==false and then try to create a new file, it goes off the rails.
    Not sure exactly what it does, but it's bad...

    Obviously, that's user error, but still...

  • RaymanRayman Posts: 12,734

    Playing around some more, noticed some things...

    FATEngineStart() claims to return false if it fails, but if I test with no SD installed at first and then install SD, it just hangs.

    Also claims "Returns true on success or false. ", but actually returns some kind of cogid if it works, not "true".

  • @Rayman said:
    Also claims "Returns true on success or false. ", but actually returns some kind of cogid if it works, not "true".

    Any non-zero value is truthy, so that holds. I think.

  • RaymanRayman Posts: 12,734

    Spin2, like Spin, is a little strange with True/False...
    I think in C, zero is false and anything else is true.

    In Spin, zero is also false, but true is -1 only.
    This function returns true (-1) if it fails, which is the opposite of what it says.
    Also, doesn't return the Spin true if it succeeds ...

    Doesn't really matter, except for figuring out how to use the code.

    1080 x 177 - 12K
  • In C (stdbool.h), true actually means 1.

    But in both, any non-zero value is truthy, i.e. satisfies an IF condition

  • JonnyMacJonnyMac Posts: 8,163

    In Spin1 and Spin2, the system constant true is defined as -1, but as Ada points out, any non-zero value will evaluate as true in an expression. This is why you see the start() method of most objects add one to the cog number returned by the system; if there's no cog (-1) available, this will get changed to 0 which always evaluates as false. If successful, the cog id returned to the caller will be promoted to 1..8 which will evaluate as true in expressions.

      if (cog)
        ' object launch was successful
    
  • RaymanRayman Posts: 12,734

    The pitfall with Spin (and I guess C too) is that if you do something like:

    If (Something == true)
       DoThis()
    

    It won't work as expected unless "Something" has the actual value for true.

    All that aside, I was just commenting that the text notes at the start of the FATEngineStart() are just plain wrong.
    Also, in my opinion, if documentation for a Spin function says it will return "true", it should return -1.

  • Wuerfel_21Wuerfel_21 Posts: 3,038
    edited 2022-07-13 16:26

    @Rayman said:
    The pitfall with Spin (and I guess C too) is that if you do something like:

    If (Something == true)
       DoThis()
    

    This is something you should never do to begin with

  • JonnyMacJonnyMac Posts: 8,163
    edited 2022-07-13 16:47

    I agree with Ada on that implementation, but understand that everybody has their preferred style. You could do this because false only has one value in Spin.

      if (something <> false)
        do_this()
    

    Also, in my opinion, if documentation for a Spin function says it will return "true", it should return -1.

    I try to do this with my own code -- but what you're going through suggests we need to be careful. Treating true as not false tends to keep things in line.

  • @JonnyMac said:
    I agree with Ada on that implementation, but understand that everybody has their preferred style.

    Assuming one is using the PNut/Proptool compiler, extraneous operators in a condition will generate worse code.
    Flexspin doesn't mind it.

  • RaymanRayman Posts: 12,734
    edited 2022-07-13 22:54

    Here's a program to do basic tests of the driver posted in top post.

    Tested with latest Prop Tool.

  • hinvhinv Posts: 1,149

    @Wuerfel_21 said:
    Yeah, the other SD driver options basically are

    • buggy FSRW port. buggy and jank.
    • Cluso's KyeFAT port, though when I posted this I think the block driver wasn't published or something. Still doesn't support SDSC cards, I think.
    • Flexspin's thingie. Good features, but slow. Doesn't use a cog.
    • ROM SD thing. Read-only.

    That's why I threw together this one, because I needed something to put in Spin Hexagon that, well, actually worked. Hence why the block driver has audio streaming features (BTW, there's 2K of RAM being wasted if you don't use the audio. You can just set their sizes to zero near the bottom of the block driver file and it shouldn't explode)

    Does your driver support the under 2GB cards that have byte addressing instead of block addressing? How much extra space does that part take up? What is needed is an interface that uses all of the pins for much higher speeds.

  • It should work with small cards, but I don't think I have any 2GB microSD cards laying around.

    The overhead from supporting them is less than 100 bytes of code overall and one instruction to leftshift the block number in every issued command.

  • evanhevanh Posts: 13,424
    edited 2022-07-15 07:24

    Hinv,
    That quote is dated. Flexspin ain't slow any longer. I revamped the block transfer routines, for Prop2, a few months back - As of version 5.9.10.

  • hinvhinv Posts: 1,149

    @evanh said:
    Hinv,
    That quote is dated. Flexspin ain't slow any longer. I revamped the block transfer routines, for Prop2, a few months back - As of version 5.9.10.

    Sorry about that. It's hard to keep up with all you guys are developing. Keep up the good work.

  • JRetSapDoogJRetSapDoog Posts: 954
    edited 2022-07-21 18:13

    I always had trouble wrapping my mind around the return values for FATEngineStart() and harmonizing them with the code comments. I figured that it was just me.

    Also, last fall when I was working on a project and wanted to test if an SD card was inserted in the SD slot, my test kept hanging, though I don't recall the exact details. But as a kludge, what I ended up doing was automatically showing an error screen first thing that instructed the user to insert an SD card (even if one was already inserted). Then I'd try to read a card (you know, if present), and if I could read the card okay, I'd quickly overwrite that error screen with the next desired screen. This all happened so fast that, if a card was properly inserted and readable, the user would never see the error screen, despite the fact that it was always automatically shown first thing upon turning on the system. I don't recall for sure if things were hung if no card was inserted (though probably), but it didn't matter because the system couldn't really work without an SD card, so just showing the error screen was enough (then the user could power down and insert a card and try again).

    Again, it was a kludge or a work around (to prevent the driver from hanging), but it worked. But other than needing to do that, I had no problems reading hundreds and hundreds of pages of text over and over again using the Kye-Wuerfel_21 driver. It seemed to be quite reliable. However, I didn't need to write to the card, just read from it. So I don't know about the write reliability. Update: And no, trying to trap the error didn't avoid the problem, at least from what I recall.

  • Wuerfel_21Wuerfel_21 Posts: 3,038
    edited 2022-07-21 18:19

    Yea, mount failure might actually just hang. don't remember where you'd fix that off the top of my head. Writes in P2 Spin Hexagon are reliable, but it only writes 512 bytes of highscore data so idk. Very rarely it fails to start playing music for some reason, but that may be specific to Spin Hexagon and/or the audio component in general.

  • RaymanRayman Posts: 12,734

    Does your version of the driver work with drives <= 2 GB?
    Seems the one I have has provisions for shifting sectors, but it's not implemented.

    The cogless version I have does work though on small cards...

  • IIRC i never actually tried it.

  • RaymanRayman Posts: 12,734

    Think I have a version of the assembly driver that now works with both FSRW and @Wuerfel_21's Kye code.

    Only real difference is the way they start. FSRW combines starting and mounting in one operation whereas split in two parts in Kye code.

    Have to make two small changes to FSRW's mount_explicit() to support combined low level assembly driver:
    comment out "unmount()" as that sends a command to driver that hasn't started yet and so hangs. Not clear what side effects that may have.
    Call new "sdspi.mountCard()" after "sdspi.start_explicit".

    In this way, old code that used FSRW still works.
    Going to see if can do the same with the cogless version.

  • RaymanRayman Posts: 12,734
    edited 2022-07-30 20:57

    Figured out the cogless version didn't work at 297 MHz, needed an extra wait.
    Think its good now, and there 3 versions of low level driver that work with this test code:

    sdspi_with_audio --> @Wuerfel_21 version with audio functions added
    sdspi_asm_mb2 --> Version I just made using ideas from the above
    sdspi_bashed2 --> cogless version

    Now, need to circle back to FSRW to make sure they all work there too...

    Note: Uploaded new version after realizing prop tool did not archive some files properly because weren't saved first...

  • RaymanRayman Posts: 12,734

    All three versions of low level driver appear to be working now with this slightly modified version of FSRW.

Sign In or Register to comment.