@cluso99 - that's a good idea about the CRC, in that it can be optimized easily and I like how you have made the complete transfer into one zero-overhead REP loop so that there are no jumps. While this doesn't help much with single sector reads since there is SD latency and other overheads, it should be quite noticeable with large multi-block reads.
@"Peter Jakacki"
I noticed that the latency is reduced when you are reading successive but individual sectors. Might do some more tests while I still have my test harness setup. I find once I move on it takes too long to go back even tho I have my code saved in steps along the way.
Yes, this is true and I have done various tests but it is not always predictable I think. Certainly the SD controller is either buffering a larger block with read-ahead or else it doesn't need any more overhead for that section. I should type in a q&d one-liner and put it through its paces to see how consistent that is and for how far.
btw, I tried installing Visual Studio Code from the package manager on Linux, but it was a dumb flatpak that needed 500MB and for some reason kept using more than that and stalling and cluttering up var/tmp files. So I manually cleared them out and went straight to the VS website and downloaded a 60MB Linux deb install and I was up and running. So far, so good as I am using it and it feels somewhat similar to Atom but better and I even integrate a couple of terminal windows into my workspace, one running minicom. Right now I am modifying the grammer files.
I followed the skipping without problems, but I think I must be missing something else.
To reverse the order of the bits in the byte, isn’t it quicker to use a REV followed by a SHR #24?
I followed the skipping without problems, but I think I must be missing something else.
To reverse the order of the bits in the byte, isn’t it quicker to use a REV followed by a SHR #24?
There’s no reversal. SPI sends msg first. If your just sending 8 bits you just need to shl/rol/rcl #24 first, then rcl #1 wc for each bit.
When receiving, just testp #pin wc and rcl #1. Once all 8 bits received your good to go. Don’t even need to clear upper bits in some cases.
... Unfortunately I cannot do the same trick for reads and of course they are the most prevalent too.
Oh, here I was thinking your code was for read data. Shows how unreadable skipping looks.
Even tho I mentioned it was for write, didn’t you see the 3 instruction loop were only outputs? The skip skips either the first or second mov which is writing clk=0 plus di= 0 or 1. The third instruction is never skipped and just outputs clk=1 without changing di. DI is MOSI output to SD (ie a write).
Read requires the two clk=0 and clk=1 instructions plus it has to test the input pin do (MISO) and accumulate it and that’s another two instructions making the bit loop 4 instructions. No way around this without smart pins, and to make matters worse, the sampling instruction must come ~8 clocks after the output clk=0 instruction!
We needed a combo write/sample/ accumulate instruction
Penny drops! You're looking at the wrong code. That code was just an example of using skipf which proves it (skipf) works, nothing more
This is a snippet of the real code. I haven't posted the whole code that uses the skipf because it has a bug and I've temporarily moved on as it is working good enough without this speedup. I'll revisit it later athough I might just try smartpins when I get a chance.
@Rayman
I'll need to look at the code (same with the OS) - don't have time at the moment so please remind me in a few days in case I forget.
It is failing the initialise sequence although interestingly looks like the card thinks it is initialised correctly as it seems to be correctly returning the CSD and CID data.
Can you try reading a known sector to see if the correct data is being returned at $FC100 ?
What a fantastic driver you have made! It's a thing of beuty when looking through the PASM code; And the mailbox interface works like a charm.
It doesn't work perfectly in my setup though and I don't know what the cause of the problem is. The initializing code locks up when I reupload and restart the code the second time after a cold start. So everything works as expected as long as I do a cold start between each run. It doesn't matter if I eject and then reinsert the card again.
I have debugged where the lock up happens and come to the conlusion that this piece of code will loop forever by jumping back to ".command55"...
What a fantastic driver you have made! It's a thing of beuty when looking through the PASM code; And the mailbox interface works like a charm.
It doesn't work perfectly in my setup though and I don't know what the cause of the problem is. The initializing code locks up when I reupload and restart the code the second time after a cold start. So everything works as expected as long as I do a cold start between each run. It doesn't matter if I eject and then reinsert the card again.
I have debugged where the lock up happens and come to the conlusion that this piece of code will loop forever by jumping back to ".command55"...
Even if the problem is on my end, it probably shouldn't be possible to lock the driver up like this. This is the card...
@Ahle2
Thanks for your kind words.
It shouldn't be possible to lock up the driver. Those calls have a timeout around them and they will return with C and or Z set and cause a jump to _fail to escape.
However, the other day ??? reported a problem with not being able to use the SD card after Flash was used. I did a mod to call init twice, and FLTH the DO pin (should already be an input) and it did fix the problem. So here is V271 to try.
The driver is not finding/validating the directory structure. It's not getting to the part where it searches for the file.
I am presuming the card is formatted as FAT32?
4K blocks are tiny. I use 32K blocks.
Currently cannot recall how to determine if the card is an older style using byte addressing or sector addressing. This driver must use the newer sector addressing cards.
BTW I always recommend SanDisk cards which is a common theme amongst users, even tho I've never had problems with other branded cards.
In the driver, uncomment these two commented lines and change $FC400 to $78000
and in the demo program SD_DEMO_SPIN.spin2 insert the line after the walkDirectory() line
'--------------------------------------------------------------------------------------------------
' walk directory (locates the fat directory table) - (required once before using find file)
walkDirectory()
term.txdump($78000, $78000+32-1) ' display data read
'--------------------------------------------------------------------------------------------------
This will display two dumped lines after the walkDirectory() call. The first byte of the second line will be the last command issued to the sd card where the card failed. Please post a snapshot and I'll see what went wrong and try to fix.
@Cluso99 said:
This will display two dumped lines after the walkDirectory() call. The first byte of the second line will be the last command issued to the sd card where the card failed. Please post a snapshot and I'll see what went wrong and try to fix.
and in the demo program SD_DEMO_SPIN.spin2 insert the line after the walkDirectory() line
'--------------------------------------------------------------------------------------------------
' walk directory (locates the fat directory table) - (required once before using find file)
walkDirectory()
term.txdump($78000, $78000+96-1) ' display data read
'--------------------------------------------------------------------------------------------------
Remember that TAQOZ in ROM is a great hardware diagnostic tool. While it is very basic compared to TAQOZ RELOADED, it is still useful.
You can initialize the card, issue low level commands etc, or just simply MOUNT the FAT32 fs and DIR and DUMP files etc.
Here's a quick console dump: ( text between the TAQOZ# prompt and the --- response are commands )
@"Peter Jakacki" said:
Remember that TAQOZ in ROM is a great hardware diagnostic tool. While it is very basic compared to TAQOZ RELOADED, it is still useful.
You can initialize the card, issue low level commands etc, or just simply MOUNT the FAT32 fs and DIR and DUMP files etc.
Here's a quick console dump: ( text between the TAQOZ# prompt and the --- response are commands )
I reformatted the 64GB Samsung SD card with an older version of "ApplePiBaker", the Raspberry Pi SD format & copy app. And, it now reads without issue. I'll reformat the 16GB SD that I started this posting with, if its no longer needed for examination.
Just to complete the circle on this issue with several SD cards that I have...
I reformatted the Patriot 16GB SD card using a version of ApplePiBaker (1.9.9), which allows formatting an SD card with an MS-Fat partition, normally for the use as a RaspberryPi OS card. I generally use this app because formatting > 32GB SDs to MS-Fat on WIN 10 is not an option. And, formatting the SD card as MS-Fat via macOS DiskUtility appears to not work well with the P2 driver. The app allows MS-Fat formatting without issue.
The SD's directory is able to be read. After copying the _HELP.txt file to the SD card (via macOS), the file can now be read by the driver demo!
TAQOZ reloaded has built in SD and FAT32 test utilities and reports, and also includes a FORMAT command that complies to the SD card association's specification for a reserved area before the start of the first partition. It will also format cards that are larger than 32GB to FAT32 and with the maximum cluster size of 64kB as well. I have formatted 128GB cards as FAT32 and even with 8GB cards I still choose a 64kB cluster size as well. BTW, 64kB is now set by default as well as protecting sector 0 with special system permission (in my "driver").
Sometimes in the past I have overwritten sector 0 accidentally and so I have formatted just the MBR itself as TAQOZ allows access to the individual routines such as FORMAT.MBR FORMAT.ROOT and FORMAT.FAT.
While Windows will format an SD card, it does not reserve memory before the first partition as is recommended, and also while it will format a card larger than 32GB as "FAT", it does so as exFAT, not FAT32.
@"Peter Jakacki" said:
TAQOZ reloaded has built in SD and FAT32 test utilities and reports, and also includes a FORMAT command that complies to the SD card association's specification for a reserved area before the start of the first partition. It will also format cards that are larger than 32GB to FAT32 and with the maximum cluster size of 64kB as well. I have formatted 128GB cards as FAT32 and even with 8GB cards I still choose a 64kB cluster size as well. BTW, 64kB is now set by default as well as protecting sector 0 with special system permission (in my "driver").
I haven't posted an official version because it's not ready/tested for prime time.
My Propeller 2 OS thread has the lastest posted working code in the last post here https://forums.parallax.com/discussion/comment/1519675/#Comment_1519675
It is working better than I remembered but I know there are bugs
I just updated post #3 on this thread with some block diagrams and timing diagrams that will help anyone wanting to either use my driver(s) or write their own.
I did these years ago when writing the P2 SD boot code.
Comments
I noticed that the latency is reduced when you are reading successive but individual sectors. Might do some more tests while I still have my test harness setup. I find once I move on it takes too long to go back even tho I have my code saved in steps along the way.
btw, I tried installing Visual Studio Code from the package manager on Linux, but it was a dumb flatpak that needed 500MB and for some reason kept using more than that and stalling and cluttering up var/tmp files. So I manually cleared them out and went straight to the VS website and downloaded a 60MB Linux deb install and I was up and running. So far, so good as I am using it and it feels somewhat similar to Atom but better and I even integrate a couple of terminal windows into my workspace, one running minicom. Right now I am modifying the grammer files.
Here is the thread I started a while ago. My colors are better now - I'm using the standard Dark theme with the spin and spin2 json file.
https://forums.parallax.com/discussion/170068/visual-studio-code-editor-for-p1-p2-spin-pasm
and here too
https://forums.parallax.com/discussion/comment/1469214/#Comment_1469214
I had this link flagged for later consumption
https://dev.to/ronsoak/i-built-my-own-vs-code-syntax-highlighter-from-scratch-and-here-s-what-i-learned-1h98
To reverse the order of the bits in the byte, isn’t it quicker to use a REV followed by a SHR #24?
When receiving, just testp #pin wc and rcl #1. Once all 8 bits received your good to go. Don’t even need to clear upper bits in some cases. Even tho I mentioned it was for write, didn’t you see the 3 instruction loop were only outputs? The skip skips either the first or second mov which is writing clk=0 plus di= 0 or 1. The third instruction is never skipped and just outputs clk=1 without changing di. DI is MOSI output to SD (ie a write).
Read requires the two clk=0 and clk=1 instructions plus it has to test the input pin do (MISO) and accumulate it and that’s another two instructions making the bit loop 4 instructions. No way around this without smart pins, and to make matters worse, the sampling instruction must come ~8 clocks after the output clk=0 instruction!
We needed a combo write/sample/ accumulate instruction
This is a snippet of the real code. I haven't posted the whole code that uses the skipf because it has a bug and I've temporarily moved on as it is working good enough without this speedup. I'll revisit it later athough I might just try smartpins when I get a chance.
v222 gives similar result...
I'll need to look at the code (same with the OS) - don't have time at the moment so please remind me in a few days in case I forget.
It is failing the initialise sequence although interestingly looks like the card thinks it is initialised correctly as it seems to be correctly returning the CSD and CID data.
Can you try reading a known sector to see if the correct data is being returned at $FC100 ?
Here is my low level SD Driver V2.70 with a spin2 demo. It is using my multiport serial driver as a single UART.
You will need a file "_HELP .TXT" on the SD Card. It is just a text file so anything will do.
Please report any bugs here :)
@Cluso99
What a fantastic driver you have made! It's a thing of beuty when looking through the PASM code; And the mailbox interface works like a charm.
It doesn't work perfectly in my setup though and I don't know what the cause of the problem is. The initializing code locks up when I reupload and restart the code the second time after a cold start. So everything works as expected as long as I do a cold start between each run. It doesn't matter if I eject and then reinsert the card again.
I have debugged where the lock up happens and come to the conlusion that this piece of code will loop forever by jumping back to ".command55"...
Even if the problem is on my end, it probably shouldn't be possible to lock the driver up like this. This is the card...
Can't find the directory or the _HELP.txt file... With MS-Fat formatted SD (4096 sized blocks on a 16GB Patriot Micro HC SD card) executing on P2Eval:
What the SD looks like to WIN 10:
dgately
@Ahle2
Thanks for your kind words.
It shouldn't be possible to lock up the driver. Those calls have a timeout around them and they will return with C and or Z set and cause a jump to _fail to escape.
However, the other day ??? reported a problem with not being able to use the SD card after Flash was used. I did a mod to call init twice, and FLTH the DO pin (should already be an input) and it did fix the problem. So here is V271 to try.
The driver is not finding/validating the directory structure. It's not getting to the part where it searches for the file.
I am presuming the card is formatted as FAT32?
4K blocks are tiny. I use 32K blocks.
Currently cannot recall how to determine if the card is an older style using byte addressing or sector addressing. This driver must use the newer sector addressing cards.
BTW I always recommend SanDisk cards which is a common theme amongst users, even tho I've never had problems with other branded cards.
In the driver, uncomment these two commented lines and change $FC400 to $78000
and in the demo program SD_DEMO_SPIN.spin2 insert the line after the walkDirectory() line
This will display two dumped lines after the walkDirectory() call. The first byte of the second line will be the last command issued to the sd card where the card failed. Please post a snapshot and I'll see what went wrong and try to fix.
I'll test a SanDisk SD card as well... Well, a "Samsung EVO 64GB", And It does read this one! :
It is failing to read the sector, probably the first sector $0.
To confirm this
In the driver, uncomment these two commented lines and change both lines as shown
and in the demo program SD_DEMO_SPIN.spin2 insert the line after the walkDirectory() line
ie 32 changed to 96 (2 places)
Remember that TAQOZ in ROM is a great hardware diagnostic tool. While it is very basic compared to TAQOZ RELOADED, it is still useful.
You can initialize the card, issue low level commands etc, or just simply MOUNT the FAT32 fs and DIR and DUMP files etc.
Here's a quick console dump: ( text between the TAQOZ# prompt and the --- response are commands )
Also, if you do happen to load the full TAQOZ serially you can use .DISK to test and print the disk details.
Thanks for chiming in Peter. I just never remember the TAQOZ one-liners
@Peter Jakacki
TAQOZ is amazing... Soo much punch in that "little" bag and all built in from the start. I have to start using it for diagnostics a little more.
@Cluso99
I reformatted the 64GB Samsung SD card with an older version of "ApplePiBaker", the Raspberry Pi SD format & copy app. And, it now reads without issue. I'll reformat the 16GB SD that I started this posting with, if its no longer needed for examination.
Just to complete the circle on this issue with several SD cards that I have...
I reformatted the Patriot 16GB SD card using a version of ApplePiBaker (1.9.9), which allows formatting an SD card with an MS-Fat partition, normally for the use as a RaspberryPi OS card. I generally use this app because formatting > 32GB SDs to MS-Fat on WIN 10 is not an option. And, formatting the SD card as MS-Fat via macOS DiskUtility appears to not work well with the P2 driver. The app allows MS-Fat formatting without issue.
The SD's directory is able to be read. After copying the _HELP.txt file to the SD card (via macOS), the file can now be read by the driver demo!
TAQOZ reloaded has built in SD and FAT32 test utilities and reports, and also includes a FORMAT command that complies to the SD card association's specification for a reserved area before the start of the first partition. It will also format cards that are larger than 32GB to FAT32 and with the maximum cluster size of 64kB as well. I have formatted 128GB cards as FAT32 and even with 8GB cards I still choose a 64kB cluster size as well. BTW, 64kB is now set by default as well as protecting sector 0 with special system permission (in my "driver").
Sometimes in the past I have overwritten sector 0 accidentally and so I have formatted just the MBR itself as TAQOZ allows access to the individual routines such as FORMAT.MBR FORMAT.ROOT and FORMAT.FAT.
While Windows will format an SD card, it does not reserve memory before the first partition as is recommended, and also while it will format a card larger than 32GB as "FAT", it does so as exFAT, not FAT32.
Excellent... Thank you for the reminder, Peter!
Uhm, maybe I'm, like, blind, but I can't find the files the FAT32 object wants. Where are they?
I haven't posted an official version because it's not ready/tested for prime time.
My Propeller 2 OS thread has the lastest posted working code in the last post here
https://forums.parallax.com/discussion/comment/1519675/#Comment_1519675
It is working better than I remembered but I know there are bugs
I just updated post #3 on this thread with some block diagrams and timing diagrams that will help anyone wanting to either use my driver(s) or write their own.
I did these years ago when writing the P2 SD boot code.