FPGA configution IP core for MMC card is as small as 21 PLD MC's (more for SD card) or less than 1Kbyte of code for AVR if using micro as boot processor
Antti
FPGA configution IP core for MMC card is as small as 21 PLD MC's (more for SD card) or less than 1Kbyte of code for AVR if using micro as boot processor
Antti
Certainly, it's easy to read MMC/SD cards in SPI mode, but that offers only 1-bit-wide data. It's possible to start in SPI mode then switch to "native" mode (but you have to power off the card to do that). I prefer to initialise in "native" mode, read the FPGA configuration and any microcontroller update, then switch to 4-bit mode so that the FPGA can read the card at high speed.
Mike
21 MC is NATIVE mode MMC init. native SD mode is just a little more.
I never use SPI mode if possible
Antti
core for MMC card is as small as 21 PLD MC's (more
All this talk of SPI vs Native mode has me curious. SPI mode is fairly well documented online, but Googling indicates that getting specs on how to use native mode requires licensing from the SD Card Assoc, which is apparently quite costly. Is this true? Are there any free resources where one could learn more about using Native mode?
EB
IP core for MMC card is as small as 21 PLD MC's (more
Never mind. Apparently the spec is now freely available here:
A quick skim seems to indicate that all the necessary protocol details are there.
BTW - I assume that all the previous discussions about loading FPGAs from SD/MMC assume that the data on the SD/MMC is _not_ in a standard filesystem, but was written in some raw format. It's difficult to imagine getting a FAT filesystem reader into 21 macrocells.
EB
configution IP core for MMC card is as small as 21 PLD MC's (more
I have done the impossible, but FAT in 21 MC is beyong my limits as well.
however if 1 file is copied to mmc card (the first file after format) then FPGA will configure from that file
I have however developed a 0FAT filesystem that allows access to files in FAT file system without fat parsing, it is compatible to almost any filesystem.
a microcontroller code that support SD native and 0FAT is still below
1 k of codea SD card hard IP-Core could also support 0FAT with very little extra resources
Antti
Well, I'm not going to reveal all my secrets for free, but a fairly simple scheme can be figured out for the SST chips. They need an "instruction" byte serially shifted in to program the memory to read from the beginning. The Xilinx FPGAs all seem to ignore everything before a byte of "FF" which appears right after a short header in the BIT or MCS file. Wiring up a 4-bit counter and a gate chip was the minimum package count scheme I could come up with for that bare minimum. If I needed to program a few bits of the starting address, too, that would probably expand to a 3-chip solution. These SSOP-packaged parts are pretty small.
I also built my own programmer for the SST chips, as none of the device programmers would handle them. It was a one-evening job to get the programmer working. One bit from CPU to PROM, one clock bit, one data bit back from the PROM. Pretty simple, plugs into the parallel port. I wrote it in C for Linux, just my personal choice. The way I am setting it up doesn't allow for on-board programming, I DON'T want to give my customers that option. But, there's no reason that couldn't be provided easily.
Jon
The SD Card Association makes available freely some limited specifications. As I understand it, the full specifications are available if you pay to join the SDA.
For example, the public documents show how to operate the card up to
25MHz but don't show the different timing sequence used when running at 50MHz (although I have seen some documents which describe that and which, I assume, "leaked out").Either way, don't expect well-written specifications. The publicly-available documents are abysmal. I'd be amazed if the full specifications were any better.
The MMC/SD standards seem to be the fruits of a committee on drugs. Certainly, it's difficult to see how a sane person could invent them. This is reflected in the quality of the documents. For example, the document which claims to describe the "physical layer" actually describes just about everything but the physical layer. Also, some products widely sold with the "SD" logo don't meet the specification.
Mike
I've often wondered why these Serial FLASH vendors have missed the REALLY OBVIOUS option, of alias of a 00 or FF opcode to read, so you could simply connect their serial memory, and just clock to stream out data. Would be 100% upward compatible with present usage.
-jg
45LF010 had a 0xFF read opcode, but its eol ...
-Lasse
Yup, that would have made it easier, and probably saved two chips to default to read out one FPGA config. For that case, using the SST chip, I had to generate a couple 1 bits in the first byte and then zeros from then on to get what I wanted.
Jon
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.