SD mode is a little different. Only the block read/write commands need a card-busy check before being issued. Other commands can be issued while the card is still busy.
EDIT: There is a separate CMD-ready check for all commands though. Can't issue a start bit if the CMD pin is already low before starting.
@Wuerfel_21 said:
EDIT: So what you're saying is, the busy check should not be at the end of a write, but before issuing a command? Because the audio driver does have a ready check after a block write.
I didn't analyse if that was a vital config but pretty much yes. I've copied how sdmm.cc command sequence does it. That is the more efficient solution anyway since it exits from the driver while the card is known to be in a busy state. Only checking in if more action is requested.
There is a second busy check after CMD24, but before any block data is sent, as well.
The point I was asking about is wether doing it that way is actually a bug? (and given I don't have a lot of time to re-verify right now, what the least invasive fix would be)
@Wuerfel_21 said:
The point I was asking about is wether doing it that way is actually a bug? (and given I don't have a lot of time to re-verify right now, what the least invasive fix would be)
sdmm.cc has always been that way. I would imagine it has a proven track record well beyond the Propellers. I only sped up the bit rate when I modified sdmm.cc.
PS: And why I mention the SD mode driver, sdsd.cc, is because I've implemented it in a similar fashion as well - Only check the card status when the driver really needs to know.
@Wuerfel_21 said:
The point I was asking about is wether doing it that way is actually a bug? (and given I don't have a lot of time to re-verify right now, what the least invasive fix would be)
sdmm.cc has always been that way. I would imagine it has a proven track record well beyond the Propellers. I only sped up the bit rate when I modified sdmm.cc.
No, I mean wether the audio driver needs to be fixed
Yep. You should be able to remove the leading call #read_byte in do_sdcmd routine. The busy check now performs that duty.
And also should be able to remove the post-write call #sd_busy as well since every command is now effectively checking for that.
@evanh said:
Yep. You should be able to remove the leading call #read_byte in do_sdcmd routine. The busy check now performs that duty.
And also should be able to remove the post-write call #sd_busy as well since every command is now effectively checking for that.
Yeah, but I don't want to change it too much, don't have time to test it on many configurations right now
Oh, yep, you've done better than I thought too. I had imagined a card-busy check was done before each raw block read as well as written but that's not so in sdmm.cc. All good.
EDIT: In hindsight, duh. It is looking for the start token rather than a busy check.
@"Stephen Moraco" I have a special use case for a potential feature request (if such a feature does not already exist).
The Ask: Is it possible to have an option where a file that is written to/created by this object, is defragmented after it is closed?
The Why: The P2s in my project boot from SD. They upgrade themselves via ethernet. They boot using the "_BOOT_P2.BIX" filesystem method. If this file is fragmented, the P2 will not boot. I have validated that the driver will fragment these files as it writes them. Defragmenting the _BOOT_P2.BIX file allows it to boot.
I hope this is not too much of an ask. If there is defrag functionality that already exists, that would perfect.
I'd convert to booting from the Flash EEPROM instead. And have it loaded with a full FAT32 filesystem that handles fragmented files correctly. Also allows better error reporting when the SD card isn't working.
@Rayman said:
@ke4pjw wondering if copying the file would do that automatically…
Well, I am doing a sd.moveFile. I suspect it just updates the dir entry without actually copying the file. You may be on to something there. This is the only file that I care about being contiguous. Another work around is 512K cluster sizes, LOL! But that's ridiculous.
@evanh I want people to just be able to place files on the SD card and it boot. Another workaround, would be to use the MBR and build a 2nd stage bootloader that can deal with fragmented boot files. I would much rather do that, as the end user would just need to run a program to make the SD card bootable by the P2, rather than having to get propplug hardware and figure out how to load the bootloader.
Comments
SD mode is a little different. Only the block read/write commands need a card-busy check before being issued. Other commands can be issued while the card is still busy.
EDIT: There is a separate CMD-ready check for all commands though. Can't issue a start bit if the CMD pin is already low before starting.
The point I was asking about is wether doing it that way is actually a bug? (and given I don't have a lot of time to re-verify right now, what the least invasive fix would be)
sdmm.cc has always been that way. I would imagine it has a proven track record well beyond the Propellers. I only sped up the bit rate when I modified sdmm.cc.
PS: And why I mention the SD mode driver, sdsd.cc, is because I've implemented it in a similar fashion as well - Only check the card status when the driver really needs to know.
No, I mean wether the audio driver needs to be fixed
Ya, the double card-busy check on block transfers seems to be important. One before command issue and another before each raw data block.
Like this?
(Also flexsplorp broke my game
, so had to fix that, too)
Yep. You should be able to remove the leading
call #read_byteindo_sdcmdroutine. The busy check now performs that duty.And also should be able to remove the post-write
call #sd_busyas well since every command is now effectively checking for that.Yeah, but I don't want to change it too much, don't have time to test it on many configurations right now
Oh, yep, you've done better than I thought too. I had imagined a card-busy check was done before each raw block read as well as written but that's not so in sdmm.cc. All good.
EDIT: In hindsight, duh. It is looking for the start token rather than a busy check.
NEWS
I just released v1.4.0
Here's what's new/fixed:
Visit the P2 microSD FAT32 Filesystem repository for full documentation, including a driver tutorial, theory of operations, and card catalog.
The release package can be downloaded from the Releases page. Download the sd-card-driver-{version}.zip
file.
If you find issues, please file them at the Issues page.
What's next? Quickly address any reported issues. Likely conditional compile for LFN support.
Enjoy!
Stephen
@"Stephen Moraco" I have a special use case for a potential feature request (if such a feature does not already exist).
The Ask: Is it possible to have an option where a file that is written to/created by this object, is defragmented after it is closed?
The Why: The P2s in my project boot from SD. They upgrade themselves via ethernet. They boot using the "_BOOT_P2.BIX" filesystem method. If this file is fragmented, the P2 will not boot. I have validated that the driver will fragment these files as it writes them. Defragmenting the _BOOT_P2.BIX file allows it to boot.
I hope this is not too much of an ask. If there is defrag functionality that already exists, that would perfect.
Thank you for a wonderful driver!
--Terry
@ke4pjw wondering if copying the file would do that automatically…
I'd convert to booting from the Flash EEPROM instead. And have it loaded with a full FAT32 filesystem that handles fragmented files correctly. Also allows better error reporting when the SD card isn't working.
Well, I am doing a sd.moveFile. I suspect it just updates the dir entry without actually copying the file. You may be on to something there. This is the only file that I care about being contiguous. Another work around is 512K cluster sizes, LOL! But that's ridiculous.
@evanh I want people to just be able to place files on the SD card and it boot. Another workaround, would be to use the MBR and build a 2nd stage bootloader that can deal with fragmented boot files. I would much rather do that, as the end user would just need to run a program to make the SD card bootable by the P2, rather than having to get propplug hardware and figure out how to load the bootloader.
If you copy to different filename might work?