hi friends
i want to interface SD card using spi.i have no idea on this topic e.g how to initialize,how to work .please help completely about spi SD card interfacing
Thanks
The MMC card and the SD card are flash memory storage based devices, and are physically very similar. Both card types support proprietary data transfer protocols using four data bits, and are compatible though having different initialisation. The major difference is that the SD card is designed to provide optional security by allowing encryption of the device contents. The MMC card supports additional bus widths (up to 8 bits). The SD card also supports several modes that are not present in the MMC card, including SDIO (secure digital input/output) that can be used as an external communications interface using the standard SD card format.
Both card types also support a basic SPI type interface for simple connection to embedded devices. The SD card specifications state a maximum clock frequency of 25MHz, and the MMC specifications state a maximum clock frequency of 52MHz depending on the device. Figure 1 shows the MMC/SD card connections when configured for SPI mode operation.
Here are some useful links on SPI:
Wikipedia help page
Detect SD Card, Read/Write to Card, in VB 2005
writing data to sd card
A pdf on Theories of SD and SPI together
SD Card Specification Details
Related
I am interfacing SD cards (1/2GB SD cards and 4GB SDHC cards from different manufactures) to a custom board in SPI mode and I am using a FATfs file system from elm-chan.
I am able to write files and read files on the SD card. However I would like to know where can I get the information on the maximum clock frequency (I can drive my SPI bus) for the given SD card.
I have seen that for some SD cards maximum speed was about 1.33MHz and for some 20MHz.
I assumed this speed was in the CSD register (TAAC value, as the TRAN_SPEED was the same on all the cards set at 25Mhz). However I realized its not true. I would really appreciate if someone can share their knowledge on this. Thanks!
Without a clear part number of the SD card, it is not feasible to find it. The probability of getting a correct answer is high only if you can share the exact details. I suggest you to check the specification thoroughly of the respective SD card for a quick answer. Can you confirm whether the observation done by you is different from the information provided in the specification ?
Does anybody know if it's possible to emulate UART (simple serial transmit and receive) over USB? How would this be accomplished?
I found this link on the Microchip website, but it's not very forthcoming.
http://www.microchip.com/forums/m522571-print.aspx
Any ideas? Thanks.
You need to implement the device stack as a CDC ACM device (also known as Virtual COM port or VCP). Most vendors of microcontrollers with USB support have example code or app notes.
Given that, your device will look like a COM port as far as Windows is concerned. At the device end, you will get raw blocks of data transferred. An appropriate abstraction layer can be implemented for both UART and USB interfaces to give then the same interface if necessary.
One gotcha is that USB devices require a Vendor ID allocated by the USB Implementer's Forum, at a $5000 fee(correct 23 JUly 2016). If you are going to release your device in the wild, you really will need one if your device is to be recognised and behave correctly with other devices. Some microcontroller vendors will allow you to use their vendor ID for a subset of product IDs for free or a smaller fee, but they might only do that if you were purchasing significant quantities of devices from them.
Another issue is that while on OSX or Linux a CDC/ACM is recognised without any additional drivers, Windows is more fussy and required an INF file to associate the specific USB Vendor and Product ID to the usbser.sys driver. Then you get into the whole world of driver signing, which is essential if using Windows Vista 64, or any version of Windows 7. A code-signing signature will also cost you money. If your vendor has provided example VCP code, they will also probably provide a signed driver. STMicroelectronios's STM32 VCP example is even WHQL certified so can be acquired automatically via Windows Update.
So the upshot is that for experimentation you can do it if your vendor already provides code and a signed driver (or you are not using Windows), but to deploy a product you will need an Vendor ID and a code-signing certificate. It is a bit of a minefield to be honest.
A simpler approach is to use an FTDI USB<->Serial chip. This is especially useful for a microcontroller without a USB controller of its own, but the data transfer rate will be limited by the micro's and/or the FTDI's UART interface rather than USB speed. An FTDI chip can be used as-is using FTDI's VID/PID or you can customise it with your own VID/PID. Customising puts you back into needing to acquire a VID and a signing certificate, but allows your device to be identified uniquely rather than as a generic serial port.
Basically you have two options to emulate UART over USB:
Use an existing product. The company FTDI provides well known and solid UART-USB bridge chips, e.g. FT230X. Pro: You don't need any detailed knowledge about USB. Cons: Expensive if used in mass production. Additional hardware, needs additional power.
Implement the USB device class "Communication Device Class" (CDC). The specification of CDC is available from the USB.org, see here. Pro: Cheap in mass production (if your Microcontroller has USB on board). Con: You need detailed knowledge about USB.
I am working on Xilinx Spartan 3E platform, using this development board:
http://www.xilinx.com/products/boards-and-kits/HW-SPAR3E-SK-US-G.htm
My program operates on certain data and then provides output. I wish to transfer the input signals externally. The input data is a stream of 8-bit signals.
So, how do I send the input signals from my laptop to the FPGA via USB? Does Xilinx support this or is there standard software to do this?
Thanks.
It sounds like you are describing a uart more than a native USB interface. You can get a USB to logic level serial adapter that will let you easily transfer data to and from a Pc at up to 921.6k baud. A uart/serial port is easy to implement in the Fpga and PCs are easy to use with serial ports.
Here is the cable:
http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm
If you have a development card it is very possible this type of interface is present.
On the software side you can use your programming language of choice as if it was interfacing with a seal port or use a terminal program like hyper terminal or Download teraterm http://ttssh2.sourceforge.jp/
Updated response:
100Hz is not a hard interface to make. At that rate you should use the serial interface if at all possible. The board you referenced has 2 full RS-232 connections. At that point you only need a way to connect that to your computer. If you have a PC with RS-232 connectors you only need a cable if you have a newer computer without you need a RS-232 to USB translator cable (like this one: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=768-1014-ND or google rs232 usb). This will give you a virtual com port on the pc to interface with the previously mentioned terminal programs or your custom software.
Update 2:
on the resource tab of the development board page you linked to there are several UART based fpga designs that you should be able to use as a starting point.
i.e. the "PicoBlaze Processor SPI Flash Programmer".
That board doesn't provide easy access to the USB interface from the FPGA as far as I can tell. It's just for configuration and debug.
Some of the newer boards and tools do allow something called hardware-in-the-loop testing where the simulator can upload data to the FPGA, wait it to calculate the results and then pull the data back. This is relatively common when using Xilinx's System Generator product as the simulations can be really long.
But I think with that board you'd be better off using the on board RS232 port to get data to and from the board. You will have to build the infrastructure to do it yourself though.
This may also give you some ideas:
http://www.1pin-interface.com/
This question is a bit vague, and I apologzie for that, but a fairly vague answer will do :)
How do people typically access memory adresses of external devices (say, connected to a PC through USB, or even just say, a multipurpose microcontroller)? I'm wondering how software is able to find address to write to registers or EEPROM space.
For example if I want to write a value to register 0x1234, does software just send this information (the register and the value to be written) to some sort of driver that "talks" to the device and takes care of the value change through hardware?
Is implementation of this functionality mostly a hardware endeavor?
Thanks!
Let's use as an example a fairly common USB peripheral controller that is based on an 8-bit 8051 microcontroller core. One side of it attaches to the USB host controller on a desktop computer. The other end goes to a USB device controller that presents itself as a FIFO endpoint to the host.
Some 8051 firmware will be required to initialize the device side. A class driver will be required on the host side. Once those are in place, the application developer will have a device name on the host side which may be opened for read/write. Sometimes a vendor will provide a library to perform device specific tasks and isolate the user from the raw device. Often a Windows DLL is available to hide the low level I/O and present device operations as function calls.
Additional 8051 firmware monitors the FIFO from device end and interprets messages sent from the host application or DLL then takes actions. These actions may be low level such as read/write from a memory location or register. They may be high level such as setting the PWM value of a programmable counter array.
So your hypothetical description of a write to register 0x1234 is not far from how it is often implemented.
Variations of MIFARE Ultralight cards are becoming quite widespread. For example, huge transport companies employ them as payment cards.
As I get from MIFARE site and Wikipedia there's a full-blown microcomputer inside the card - with a processor, memory, etc. When I move the card close to the reader its field induces current in the card antenna, the card computer turns on and runs some complicated protocol to communicate with the reader.
That's all cool but could I write my own program that would run on such a card and do something useful a card doesn't do by default? What are simple examples of what such program could do?
The microprocessor based contactless cards are easy to work with, our company has had good success with the the NXP JCOP product line with wireless capability (this wireless capability is provided via MIFARE technology, but these are microprocessor cards and not MIFARE Ultralight cards.) The JCOP cards let you install your own Global Platform or Javacard cardlet apps on the card and commmunicate with them wirelessly using the ISO 14443 A protocol.
MIFARE Ultralight cards just store data - you can't write a program to run on the card. The MIFARe Classic and Plus variants are similar. MIFARE ProX, SmartMX & DESFire Cards are all microprocessor based cards.
The memory only cards are easy to work with - readers and cheap & easy to obtain via eBay or similar. I'm not sure how you develop with the microprocessor based cards because we've never used them.
I think you need to talk to MIFARE about that. My guess is that have some sort of software development kit as well as a special programmer for the card for potential developers. I haven't fully perused their site, so they may not allow individual developers to work on it, but do the work themselves as a service.