[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: hi i need some help about FAT16 implement on sd
- Date: Wed, 9 Feb 2005 14:53:22 -0500
- From: "Bogdan Vacaliuc" <bvacaliuc at ngit dot com>
- Subject: RE: hi i need some help about FAT16 implement on sd
In my experience, there wasn't any real variation in different SD cards, except that some were more sensitive to timing variations
due to marginal circuit design and coupling between the connector and the CPU/DSP implementing the interface. Basically, the need
to limit the clock rate and the need to handle the likely (7-bit) CRC errors. I wouldn't worry _that_ much about different SD
By far the issue (as I see it) is in supporting the SD interface on a particular CPU/DSP. Each has its own set of registers, DMA
procedures, FIFOS, interrupt controls, options, quirks, etc. I would think that information would be freely available and usable.
Otherwise, the basic command _sequence_ for SD/MMC are the same. There are differences, however in the handling of APP_CMD
(55=0x37), and of the specific response codes. This is to make the command/data state machines cycle correctly.
On Wednesday, February 09, 2005 2:10 PM, Aaron J. Grier wrote:
> On Wed, Feb 09, 2005 at 06:18:40PM +0300, Victor V. Vengerov wrote:
>> One of the problem about this is that Secure Digital specification is
>> closed (you have to purchase it), and it is not clean enough how it
>> can be used with open source projects. From other side, some SD card
>> manufacturers provides detailed data sheets for their parts enough to
>> implement driver which will work with this specific part and, may be,
>> with some other parts.
> couldn't the "secure" part be ignored, and only the generic MMC
> subset implemented?