I can't answer all the questions but looking at the C3 version, there is this comment
// modified by Michael Green for C3
// changes include changing SPI selection mechanism in commandSPI and shutdownSPI and removing
// support for write protect and card detect sensing in order to save space in assembly cog.
And so
Do I simply replace the file "SD3.01_FATEngine.spin"
with the C3-version of the file "SD-MMC_FATEngine.spin" ?
Yes I think you do that.
And then whenever you access the SD card, you need to call commandSPI and shutdownSPI. I think that will be
i) at startup when you mount the card, do commandspi then after, do shutdownSPI
ii) whenever you open a file do commandSPI first
iii) whenever you close a file, do shutdownSPI afterwards.
If you only use the SD card and nothing else on the SPI bus, you might be able to do a 'commandSPI' right at the beginning and then leave it permanently connected to the SD card. That might be a useful place to start.
I've used a few different groups. Mainly pins 12-15. Sometimes pins 20-23. It doesn't matter because the great thing about Kye's code is you just change the pin allocations in the CON section at the beginning of the code (or change in the .start).
Here's the link to the thread with the C3 modified SD3.01 FAT 16/32 Driver. As others have noted, it is intended to be used as a drop-in replacement for the standard driver.
@ william chan A year late and a dollar short - but to answer your question... you need to create the file first. Then open it for appending. Do something like this:
result := \fat.newFile(fileName) ' Try...
fat.partitionError ' Clear any errors...
fat.openFile(fileName, "A")
fat.writeString(logMessage)
fat.writeByte(_NEWLINE)
fat.closeFile
Ok I have looked through the file listed on the OBEX shown on the very beginning of this thread and I don't see where it is actually labeled as version 3.01. I'm looking at SD-MMC_FATEngine.spin and in the notes it says v2.0. Am I missing something here? On the OBEX page for file #619 it indicates there was a last update on 12/4/2011 but I don't see where or what file it is.
Sorry for being ignorant here... set me straight please.
The C3 version is an unofficial modification, so it may not be current nor have the various comments in the source code been updated to reflect exactly the history. The modifications were done by me, not Kye. I have no idea whether he's tested them although I've done some simple testing and they work under straightforward circumstances. I haven't tested them when switching back and forth among various SPI devices. There needs to be some care taken in that case because the various device drivers may not expect their device to be unselected. The C3 is a nice board with a handy combination of peripheral devices, but there's no "official" support for the usual SD card drivers (Rokicki's FSRW and Kye's FATEngine) although there are unofficial modified versions of each available.
Mike- The title (to me anyway) does not suggest that the update even pertains to the C3 board but that it is an update to his SD driver object regardless of what it is used on. My point being and I think it was asked earlier in the thread but never answered is where is this version 3.01? It isn't in the OBEX as mentioned at the very beginning. I did happen to find it zipped in a Dr Acula post #25 in this thread under KyeDOS. But is this the same version that Kye modified and the one that should be used?
That's all I'm trying to understand is whether or not to use version 2.0 as posted in OBEX or the 3.01 where ever it resides. This thread is somewhat confusing as whether or not to even use vesrion 2.0 at all. It seems as there isn't any continuity in this thread. And then you and others throw in the C3 conversation and mention that some files for the C3 are updates to version 3.01. But nowhere in those files is any mention of this in the comments. Very confusing.
Don M is right - the link on the first post of this thread goes to the Obex with v 2.0
Kyedos is built on v 3.01 and so the quick and simple answer would be to grab the SD driver object from within kyedos.
Actually, this might explain some strange bugs I had recently where I wanted an SD driver for a new program, and I grabbed it off this thread rather than from kyedos, and there was something that didn't quite work right (I can't recall what, but it was fairly essential).
Hopefully Kye will chime in shortly.
Addit: Now I'm even more confused. The header for v 3.01 says v3.01 and then further down says v 1.7
// SD3.01 File Allocation Table Engine
//
// Author: Kwabena W. Agyeman
// Updated: 1/1/2011
// Designed For: P8X32A
// Version: 1.7
//
// Copyright (c) 2011 Kwabena W. Agyeman
// See end of file for terms of use
Interesting to click on 'properties' of the file and check the creation date as v 3.01 was created after v2.0. But the updates for 3.01 stop at 1.7 in the comments section, but in v2.0 they go up to 2.0.
So, the 3.01 stands for the SD card support functionality - go download the SD card product doc and it will say 3.01 on it. The 3.01 has nothing todo with the full file system driver version.
Use version 2.0. That version is the best one. I removed the 3.01 from the name of the driver because it was confusing people.
Also, this is an old thread. No one left any comments on my version 2.0 status update thread... so that thread has fallen into the midst of the forums now.
Hi Kye, great work on the object. I was using Tomas Rokicki's FSRW object for SD card projects before stumbling upon this gem. Needed the ability to manage directories and such, which your object provides very well. The documentation is very helpful too.
I am having one small problem though. Whenever an SD card is mounted to a system, the MISO pin on the SD card is constantly set high whenever it is idling. This is not a problem if the SD card is the only object on a SPI bus, but if there are other devices who expect the MISO line to idle low it can cause issues, regardless of other CS pins being set high or low.
The simplest soution to all of this is to add a diode to the MISO line where it branches off to the SD card on an SPI bus. I never noticed this issue using the FSRW object and am unsure as to why it is happening with your object. If anyone could explain this to me, I would be very grateful. I'm hoping there is a quick fix to keep the SD card MISO pin idling low in the code within the object. If there is a software fix (I say 'fix' but I don't think there is any issue with your object Kye), it saves me from having to change any hardware on my project.
If I haven't explained myself to your understanding, or you require any further information, please don't hesitate to ask away.
My object does this on purpose. I believe making the MISO pin idle high is the proper think to do for the SPI bus when using SD/MMC cards.
In any case. The newest version of the driver should not do this. http://obex.parallax.com/objects/619/ The one posted in this thread is older. My newer one tri-states all pins when idle. You should use pull up resistors on the SPI bus lines.
Hi Dantes,
My object does this on purpose. I believe making the MISO pin idle high is the proper think to do for the SPI bus when using SD/MMC cards.
In any case. The newest version of the driver should not do this. http://obex.parallax.com/objects/619/ The one posted in this thread is older. My newer one tri-states all pins when idle. You should use pull up resistors on the SPI bus lines.
Thanks,
I'd wager you know ALOT more than me on SD cards and such so I will take your word for it that the MISO pin should be idling high.
Just to avoid any confusion, when I say MISO I mean that the Propeller is the Master while the SD card is the Slave device.
I tested the latest version you posted there and I am still getting a ~3.3V signal from the SD card when it is mounted to the system. When I was using the FSRW object, the same pin idled at ~0.2V and I have configured my whole SPI bus around that.
This is where I get confused, because I had taken for granted that when the SD card (not the Propeller) outputted ~0.2V on the MISO pin using the FSRW object that was just standard. So I take it it must be possible to configure the SD card to operate with different parameters when mounting it to the system? I have very little experience with this so hopefully someone can tell me the difference between Kye's object and the FSRW object in this regard?
If worst comes to worst, I can simply use pull up resistors as you stated Kye, but I am hoping to proceed with my current hardware configuration that worked fine with the FSRW object.
Is there a quick edit I can make to the assembly in your object that will allow the MISO pin to idle low (from the SD card) instead of high?
It does not make sense for MISO to be anything but tri-stated when the card is deselected, whether it is mounted or not. It has to be that way so that the master (Prop) can address multiple SPI devices on the same bus. In the idle state, between commands, but when the card is still selected, I'm pretty sure FSRW idles the MOSI and SCLK asserted low, and I'm also pretty sure that MISO stays asserted low too, rather than high or tri-state. It's been a while since I looked at that though.
Are you talking about the state of MISO when the card is selected but idle? I don't see anything in the SD PHY specs about it one way or another, but the only complete copy I have is version 1.x. The idle state of MISO would be determined by the SD card firmware, not by the Prop.
Please take a look at the ASM code for my driver. Around lines 2611 to 2800 is the code for the low level SPI communication.
I believe the "Shutdown SPI" function and the "Command SPI" functions are what you want to look at.
There is code in the driver to tristate the I/O lines from the prop chip...
---
I'm confused on what is causing your problem. Is MISO line is being attached the "dataOut" pin in my driver? If that's the case the prop chip does not control it. NOTE: "dataOut" is data out from the SD card.
---
Yes, you can edit the ASM code. There's room in the ASM cog image for that. The code is pretty easy to read and modify. Do not touch the flags (z, c), though, in the low level SPI code.
---
Please note that the ASM driver employs write acceleration, e.g. it lets tells the SPIN cog that it has written to the SD card before it actually finishes writing to the SD card.
Only un-mounting the SD card is synchronous. So, you can use the bus for other things or reboot afterwards, etc.
BTW: You can rip out my block driver and put the FSRW block driver in instead. You have to hunt down a few variables and disable a few things. But its not really a lot of work to do.
Look at the "readWriteBlock", "FATEngineStart", and "FATEngineStop" functions. You just have to make those functions work with FSRW's block drivers.
---
NOTE: You won't get much of a speed bump. My driver has a completely different and slower caching system than FSRW.
My driver does a lot of book keeping stuff to follow the FAT16/32 spec very closely. Its not truly needed but my driver still does it.
---
Please search through the code and see how "readWriteBlock" is called. It gets passed "M" for mount, "B" for boot (not supported by FSRW), "R" for read, and "W" for write. It also gets passed "O" for acknowledge (this is what the SPIN and ASM driver to synchronize).
---
DO not test the edited code on an SD card you care about - or you may find your self sad if gets corrupted.
Are you talking about the state of MISO when the card is selected but idle? I don't see anything in the SD PHY specs about it one way or another, but the only complete copy I have is version 1.x. The idle state of MISO would be determined by the SD card firmware, not by the Prop.
I am indeed refering to when the card is selected but idle. I understand that when the SD card is mounted/enabled to the Prop, the SD card itself should control what logic state is on each of its pins...but for some reason the MISO pin is idling at logic low for the FSRW object and then idling high for Kye's object.
How I test this is by mounting a card to the system, begin an endless loop on the prop (so the system idles), disconnect the MISO line and check the voltage on the SD cards MISO pin (or Data Out if you prefer). I get ~3.3V when mounted with Kye's object and ~0.3V when mounted with the FSRW object. This is where my confusion arises because I don't know very much about the SD card physical layer specification but I didn't imagine there could be such a difference in the two objects. I presume it has something to do with how they are mounted? Maybe the commands that are sent to the SD card at start up? I am using the same SD card so I don;t think it has anything to do with the SD card firmware.
Please take a look at the ASM code for my driver. Around lines 2611 to 2800 is the code for the low level SPI communication.
I believe the "Shutdown SPI" function and the "Command SPI" functions are what you want to look at.
There is code in the driver to tristate the I/O lines from the prop chip...
---
I'm confused on what is causing your problem. Is MISO line is being attached the "dataOut" pin in my driver? If that's the case the prop chip does not control it. NOTE: "dataOut" is data out from the SD card.
---
Yes, you can edit the ASM code. There's room in the ASM cog image for that. The code is pretty easy to read and modify. Do not touch the flags (z, c), though, in the low level SPI code.
---
Please note that the ASM driver employs write acceleration, e.g. it lets tells the SPIN cog that it has written to the SD card before it actually finishes writing to the SD card.
Only un-mounting the SD card is synchronous. So, you can use the bus for other things or reboot afterwards, etc.
Yes, the MISO line is connected to the "dataOut" pin of your object. Tri-stating the inputs and outputs of the Prop isn't a problem here. It's the difference between the voltage levels on the DO pin of the SD card. As I mentioned above, I am not that familiar with the physical layer specification of the SD cards, but I presume there is a difference in how your object mounts the SD card and how the FSRW object does it. Has anyone else noticed this at all? Is there an edit I can make in the ASM to tell the SD card to keep its DO pin idling low? Does such a command exist?
I believe what you have found is a problem that I discovered when I shared the pins. D0 is not released (tristated) when cs goes high. What was required is some moe clocks after cs is removed. Kyes code does this. If you search for the ZiCog thread or RamBlade thread you will find source files for fsrw with _rr006 IIRC which is a modified fsrw version to fix this bug. D0 should in fact be hi if there is the pullup fitted.
Hope this helps.
And... I don't know of a solution for you. You can try sending out extra tokens on the SD card bus. Look at how the readSPI function is used in the ASM code.
Its my understanding that the bus should idle high.
---
It may be easier for you to just rip my block driver out and put the FSRW block driver in the code. Please see post #140.
Cluso,
I saw the following wrap-up code and comment in FSRW's safe_spi.spin
{=== these PASM functions get me in and out of multiblock mode ===}
release_DO
' we're already out of multiblock mode, so
' deselect the card and send out some clocks
or outa,maskCS
call #in8
call #in8
' if you are using pull-up resistors, and need all
' lines tristated, then uncomment the following line.
' [COLOR=#ff0000]for Cluso99[/COLOR]
'mov dira,#0
Is that what you are talking about? That would certainly release the pins that are supposed to be outputs from the Prop to the card, but something else must be going on with the DO pin from card to Prop. Are you sure that the above patch released DO? That would imply that safe_spi was asserting a line that should always be an input to the Prop. It should be the card firmware exclusively that asserts and releases that line.
This issue has been on my mind too, for the reason of minimizing current drain. Pins that are left asserted low, with a pullup resistor in place, draw an extra measure of unwanted quiescent current.
Tracy: Yes, that is what I was referring to. Interesting this will not fix the problem. The problem was the card would not release DO (an output from the SD card).
I patched the older drivers. What was required was a number of clock pulses on the spi clk line after cs was released.
My issue is that the spi clk, do & di lines are shared with sram pins on my boards. So it was essential they be released (tristated) after use.
Its when you deactivate the card. I am not sure if this coincides with unmount.
Looks like Kyes code handles this, and I though he handled it too. Certainly Catalina handles it and it uses a derivative of Kyes work. However, Catalina misses either an activate or deactivate somewhere, so I have currently patched my RamBlade3 driver to overcome this problem.
For the older fsrw25 by lonesock, the patches are posted on my RamBlade3 thread at the end.
Drac: Certainly let me know if you find a problem with your hw but I think you will be fine. Sorry to be so vague - I would need to delve into the code to find it.
The SD card specification is quite clear that DO will tri-state within one clock cycle after CS\ goes high. Here is a typical statement from the v1.0 SD spec (and I have no reason to believe that has changed in substance in v2 or v3):
The host may deselect a card (by raising the CS) at any time during the card busy period (refer to the given timing diagram). The card will release the DataOut line one clock after the CS going high. To check if the card is still busy it needs to be reselected by asserting (set to low) the CS signal.
In my own observation (fsrw 2.6 + safe_spi 0.3.0) with a logic analyzer, DO goes hi-Z and is pulled up reliably with a resistor.
Release_DO in the pasm portion of safe_spin can be commanded directly by a release routine in safe_spi spin code and from a pass-thru in fsrw proper, and release is also be called from fsrw when you close a file or unmount the card.
I do wonder why the (mov dira,#0) is commented out in the current version of safe_spi? That is definitely what is needed to put hi-Z DI and SCLK in the hi-Z state. Is there more to it?
Just because a spec says something, you cannot believe it to be so. Many have been caught by absolutely trusting specs.
We found previously that indeed at least a few clocks were required after the cs line was released to force the sd card to release DO (output from the card). All my designs so far share this pin.
Need help for a project for reading & writing at sector-level (not working with any files). I seems to hit a snag for accessing the sectors.
In your driver, the first Sector in Cluster# 0 is at 496. So it means Sector# 0 ~ 495 are hidden? (OS) How can I access them? Or, is there another way? Basically, what I need is to read & write specific sectors.
Comments
I can't answer all the questions but looking at the C3 version, there is this comment
And so
Yes I think you do that.
And then whenever you access the SD card, you need to call commandSPI and shutdownSPI. I think that will be
i) at startup when you mount the card, do commandspi then after, do shutdownSPI
ii) whenever you open a file do commandSPI first
iii) whenever you close a file, do shutdownSPI afterwards.
If you only use the SD card and nothing else on the SPI bus, you might be able to do a 'commandSPI' right at the beginning and then leave it permanently connected to the SD card. That might be a useful place to start.
Hey - I see this is "object of the week" - well done!
I've used a few different groups. Mainly pins 12-15. Sometimes pins 20-23. It doesn't matter because the great thing about Kye's code is you just change the pin allocations in the CON section at the beginning of the code (or change in the .start).
result := \fat.newFile(fileName) ' Try... fat.partitionError ' Clear any errors... fat.openFile(fileName, "A") fat.writeString(logMessage) fat.writeByte(_NEWLINE) fat.closeFileSorry for being ignorant here... set me straight please.
Thanks.
That's all I'm trying to understand is whether or not to use version 2.0 as posted in OBEX or the 3.01 where ever it resides. This thread is somewhat confusing as whether or not to even use vesrion 2.0 at all. It seems as there isn't any continuity in this thread. And then you and others throw in the C3 conversation and mention that some files for the C3 are updates to version 3.01. But nowhere in those files is any mention of this in the comments. Very confusing.
Kyedos is built on v 3.01 and so the quick and simple answer would be to grab the SD driver object from within kyedos.
Actually, this might explain some strange bugs I had recently where I wanted an SD driver for a new program, and I grabbed it off this thread rather than from kyedos, and there was something that didn't quite work right (I can't recall what, but it was fairly essential).
Hopefully Kye will chime in shortly.
Addit: Now I'm even more confused. The header for v 3.01 says v3.01 and then further down says v 1.7
Interesting to click on 'properties' of the file and check the creation date as v 3.01 was created after v2.0. But the updates for 3.01 stop at 1.7 in the comments section, but in v2.0 they go up to 2.0.
Use version 2.0. That version is the best one. I removed the 3.01 from the name of the driver because it was confusing people.
Also, this is an old thread. No one left any comments on my version 2.0 status update thread... so that thread has fallen into the midst of the forums now.
I am having one small problem though. Whenever an SD card is mounted to a system, the MISO pin on the SD card is constantly set high whenever it is idling. This is not a problem if the SD card is the only object on a SPI bus, but if there are other devices who expect the MISO line to idle low it can cause issues, regardless of other CS pins being set high or low.
The simplest soution to all of this is to add a diode to the MISO line where it branches off to the SD card on an SPI bus. I never noticed this issue using the FSRW object and am unsure as to why it is happening with your object. If anyone could explain this to me, I would be very grateful. I'm hoping there is a quick fix to keep the SD card MISO pin idling low in the code within the object. If there is a software fix (I say 'fix' but I don't think there is any issue with your object Kye), it saves me from having to change any hardware on my project.
If I haven't explained myself to your understanding, or you require any further information, please don't hesitate to ask away.
My object does this on purpose. I believe making the MISO pin idle high is the proper think to do for the SPI bus when using SD/MMC cards.
In any case. The newest version of the driver should not do this. http://obex.parallax.com/objects/619/ The one posted in this thread is older. My newer one tri-states all pins when idle. You should use pull up resistors on the SPI bus lines.
Thanks,
Just to avoid any confusion, when I say MISO I mean that the Propeller is the Master while the SD card is the Slave device.
I tested the latest version you posted there and I am still getting a ~3.3V signal from the SD card when it is mounted to the system. When I was using the FSRW object, the same pin idled at ~0.2V and I have configured my whole SPI bus around that.
This is where I get confused, because I had taken for granted that when the SD card (not the Propeller) outputted ~0.2V on the MISO pin using the FSRW object that was just standard. So I take it it must be possible to configure the SD card to operate with different parameters when mounting it to the system? I have very little experience with this so hopefully someone can tell me the difference between Kye's object and the FSRW object in this regard?
If worst comes to worst, I can simply use pull up resistors as you stated Kye, but I am hoping to proceed with my current hardware configuration that worked fine with the FSRW object.
Is there a quick edit I can make to the assembly in your object that will allow the MISO pin to idle low (from the SD card) instead of high?
Are you talking about the state of MISO when the card is selected but idle? I don't see anything in the SD PHY specs about it one way or another, but the only complete copy I have is version 1.x. The idle state of MISO would be determined by the SD card firmware, not by the Prop.
I believe the "Shutdown SPI" function and the "Command SPI" functions are what you want to look at.
There is code in the driver to tristate the I/O lines from the prop chip...
---
I'm confused on what is causing your problem. Is MISO line is being attached the "dataOut" pin in my driver? If that's the case the prop chip does not control it. NOTE: "dataOut" is data out from the SD card.
---
Yes, you can edit the ASM code. There's room in the ASM cog image for that. The code is pretty easy to read and modify. Do not touch the flags (z, c), though, in the low level SPI code.
---
Please note that the ASM driver employs write acceleration, e.g. it lets tells the SPIN cog that it has written to the SD card before it actually finishes writing to the SD card.
Only un-mounting the SD card is synchronous. So, you can use the bus for other things or reboot afterwards, etc.
Look at the "readWriteBlock", "FATEngineStart", and "FATEngineStop" functions. You just have to make those functions work with FSRW's block drivers.
---
NOTE: You won't get much of a speed bump. My driver has a completely different and slower caching system than FSRW.
My driver does a lot of book keeping stuff to follow the FAT16/32 spec very closely. Its not truly needed but my driver still does it.
---
Please search through the code and see how "readWriteBlock" is called. It gets passed "M" for mount, "B" for boot (not supported by FSRW), "R" for read, and "W" for write. It also gets passed "O" for acknowledge (this is what the SPIN and ASM driver to synchronize).
---
DO not test the edited code on an SD card you care about - or you may find your self sad if gets corrupted.
I am indeed refering to when the card is selected but idle. I understand that when the SD card is mounted/enabled to the Prop, the SD card itself should control what logic state is on each of its pins...but for some reason the MISO pin is idling at logic low for the FSRW object and then idling high for Kye's object.
How I test this is by mounting a card to the system, begin an endless loop on the prop (so the system idles), disconnect the MISO line and check the voltage on the SD cards MISO pin (or Data Out if you prefer). I get ~3.3V when mounted with Kye's object and ~0.3V when mounted with the FSRW object. This is where my confusion arises because I don't know very much about the SD card physical layer specification but I didn't imagine there could be such a difference in the two objects. I presume it has something to do with how they are mounted? Maybe the commands that are sent to the SD card at start up? I am using the same SD card so I don;t think it has anything to do with the SD card firmware.
Yes, the MISO line is connected to the "dataOut" pin of your object. Tri-stating the inputs and outputs of the Prop isn't a problem here. It's the difference between the voltage levels on the DO pin of the SD card. As I mentioned above, I am not that familiar with the physical layer specification of the SD cards, but I presume there is a difference in how your object mounts the SD card and how the FSRW object does it. Has anyone else noticed this at all? Is there an edit I can make in the ASM to tell the SD card to keep its DO pin idling low? Does such a command exist?
Hope this helps.
And... I don't know of a solution for you. You can try sending out extra tokens on the SD card bus. Look at how the readSPI function is used in the ASM code.
Its my understanding that the bus should idle high.
---
It may be easier for you to just rip my block driver out and put the FSRW block driver in the code. Please see post #140.
I saw the following wrap-up code and comment in FSRW's safe_spi.spin
{=== these PASM functions get me in and out of multiblock mode ===} release_DO ' we're already out of multiblock mode, so ' deselect the card and send out some clocks or outa,maskCS call #in8 call #in8 ' if you are using pull-up resistors, and need all ' lines tristated, then uncomment the following line. ' [COLOR=#ff0000]for Cluso99[/COLOR] 'mov dira,#0Is that what you are talking about? That would certainly release the pins that are supposed to be outputs from the Prop to the card, but something else must be going on with the DO pin from card to Prop. Are you sure that the above patch released DO? That would imply that safe_spi was asserting a line that should always be an input to the Prop. It should be the card firmware exclusively that asserts and releases that line.
This issue has been on my mind too, for the reason of minimizing current drain. Pins that are left asserted low, with a pullup resistor in place, draw an extra measure of unwanted quiescent current.
I patched the older drivers. What was required was a number of clock pulses on the spi clk line after cs was released.
My issue is that the spi clk, do & di lines are shared with sram pins on my boards. So it was essential they be released (tristated) after use.
I have a new board in front of me that is going to need this patch as well.
Can I ask where you put the patch? Is it when you 'close' the file? Or is it when you 'unmount' the sd card?
Looks like Kyes code handles this, and I though he handled it too. Certainly Catalina handles it and it uses a derivative of Kyes work. However, Catalina misses either an activate or deactivate somewhere, so I have currently patched my RamBlade3 driver to overcome this problem.
For the older fsrw25 by lonesock, the patches are posted on my RamBlade3 thread at the end.
Drac: Certainly let me know if you find a problem with your hw but I think you will be fine. Sorry to be so vague - I would need to delve into the code to find it.
In my own observation (fsrw 2.6 + safe_spi 0.3.0) with a logic analyzer, DO goes hi-Z and is pulled up reliably with a resistor.
Release_DO in the pasm portion of safe_spin can be commanded directly by a release routine in safe_spi spin code and from a pass-thru in fsrw proper, and release is also be called from fsrw when you close a file or unmount the card.
I do wonder why the (mov dira,#0) is commented out in the current version of safe_spi? That is definitely what is needed to put hi-Z DI and SCLK in the hi-Z state. Is there more to it?
Does the user need to do that (a call to another function) or would/should the code do that automatically?
It may be that this issue has never come up before as most users tend to allocate 4 pins exclusively for the SD card??
Which bit of code is that in - I'd like to check the code I have as well. Thanks++ in advance.
We found previously that indeed at least a few clocks were required after the cs line was released to force the sd card to release DO (output from the card). All my designs so far share this pin.
Need help for a project for reading & writing at sector-level (not working with any files). I seems to hit a snag for accessing the sectors.
In your driver, the first Sector in Cluster# 0 is at 496. So it means Sector# 0 ~ 495 are hidden? (OS) How can I access them? Or, is there another way? Basically, what I need is to read & write specific sectors.
Thanks.