is there a tool to check how much data has already been written to a SD card? Or a way to check how many times a certain memory location has already been written to estimate the lifetime of the SD card? Like SMART tools for SSDs...
Related
I am using MicroSD cards as the storage on an embedded system running WinCe. Recently I have found Cards made by the same manufacturer in different parts of the world have differences and cause us issues.
I read at the SD Association about the formatting issues that windows formatters produce so I downloaded their SD Memory Card Formatter. That is good but we run our SD cards in WinCe as TexFat. So what I now do is format the card with a FAT32 partition so the PC will put the software onto the card. Then the WinCE system will format the other partition to TexFat and copy the software onto that on the first boot with the new card.
The question is what is the correct way to format a SD card as TexFat for WinCE from a PC? Any suggestions?
After lots of head scratching I found the answer is simple. The winCE partition has to be formatted TexFAT on the winCE system which was not a problem, the bit I did not know is that I needed to change the clusters. Once I changed the 8GB to have 4k clusters the time to write to the card decreased a lot. I have since tried other sizes and find that you need to play with the cluster size to get the optimum out of the card.
I'm new to using VHDL and have run into an issue with my project. I'm trying to make an FPGA to converts from one communication protocol to a different one, and for this purpose it would be useful to be able to store (hopefully multiple) packets before converting.
Before I tried to store this data in arrays, but it became quickly apparent that this takes up far too much space on the FPGA. Therefore, I have been searching for a way to store the data on the DDR3 ram on the SP605 board (http://www.xilinx.com/support/documentation/boards_and_kits/xtp067_sp605_schematics.pdf, page 9). I however cannot find instructions on how to write or read data from this. I'm trying to store one 8bit std_logic_vector per clock cycle to later be accessed.
Can anyone advise me on how to proceed?
Xilinx offers an IP Core generator. This IP catalog contains a Memory Interface Generator (MIG) which generates an IP Core to access different memory types. Configure this core for DDR3.
Writing a DDR3 controller in VHDL is not a project for a beginner not even for an experienced designer.
The state machine is simple and well known, but the calibration logic is very costly.
You should consider a caching or burst read/write technique, because DDR memory can not be accessed in every cycle.
I'm trying to implement a method to write data to an SD card from a dsPIC33F. I currently can transmit the data via UART to Bluetooth and USB, but I can't find anything online in regards to writing to an SD card via UART; it all seems to be SPI.
I would use SPI, but I'm already using I2C and it seems to be difficult to use both SPI and I2C on the same PIC, due to them sharing pins.
So, can anyone suggest any information on writing data to an SD card via UART, or maybe a way to use both SPI and I2C concurrently?
All I want is some form of storage method, so if someone can suggest another method, maybe EEPROM or USB flash drive, then I'm all ears. I will need at least 2GB of storage, the more the better.
Most SD cards natively support SPI communication but not UART so a direct UART connection isn't possible. I would recommend against the USB flash drive as there is a lot of overhead there that complicates things. And EEPROM is likely to use SPI or I2C so you're still left with the problem of having the one set of peripheral pins already in use.
Your best option given the chip you are using is to use the Peripheral Pin Select feature to map some available pins to be the 4 SPI pins you need. Section 11.6 of the datasheet has a good explanation of how to remap pin functions. That is probably the easiest solution.
One other approach you could possibly use is to use the UART to communicate with another PIC that has the SPI pins available but that, too, introduces a lot of extra overhead and complexity.
SD cards can work with SDIO or SPI.
In order to eliminate the SPI / I2C pin sharing problem, I would:
1) check if the sensor can be replaced with an SPI one
2) if not, I would implement an Software SPI using other pins (the MCU is Master, thus this is much easier)
I was wondering how this was done?
There's a very simple solution. ROM was invented first.
From wikipedia: "The simplest type of solid state ROM is as old as semiconductor technology itself."
Computers as early as the ENIAC used ROM to store functionality. The concept of BIOS - more simply, a bootloader - wasn't necessary until computers became publicly available, by which point ROM had been around for decades.
Eproms existed before magnetic media as far as I know, and eproms were what BIOS was stored in. And still are in more sophisticated form.
In the earliest computers, there was a front panel with toggle switches to enter machine code to get it up and running so it could talk to the magnetic tape or punch cards.
http://en.wikipedia.org/wiki/Front_panel
My and my fellow students are deciding on a choosing a simple microcontroller to do very basic image processing. We are basically trying to implement template matching to find a set of objects in specific portions of the image. We'd like to use a connect a webcam to the microcontroller to do the job take the pictures and look for the objects. We also require basic wireless communication (e.g. bluetooth or wifi).
I don't think we will have the luxury of using state-of-the-art microcontroller, but something thats been around for a while (due to budget and stuff). Could anyone please advise on which specs of the microcontrolelr would be the most relevant for the above task (e.g. CPU, MIPS, etc).
Thanks a lot!
For this kind of a task, I would say the amount of RAM is the most relevant spec.
A microcontroller with an external memory interface allows you to extend the data space with additional SRAM to hold your image data.
Also note, that memory is needed for any protocol stacks you need to implement (Bluetooth, TCP/IP even more so).
You probably want to have total RAM in tens of kilobytes, preferably 100+ kB.
It is also nice to have plenty of program memory available when learning and experimenting. Later on you can try to optimize and squeeze your code into a more confined device.
As for the architecture, choose something you can easily find development tools and examples for.ARM, AVR and PIC are all good candidates among others.
Also find out what interfaces you need to use to
control the camera (e.g. I2C or SPI)
read pixel data (e.g. parallel or analog)
Connecting directly to a webcam's USB interface would not be a straightforward task, as the microcontroller would need to act as a USB host.
Good luck with your project!
You may need a microcontroller with following features:
USB 2.0 Host controller
1.2MB of memory for buffer 640*480*2(bytes per pixel)*2(double buffer)
(you may use lower resolution if there are not enough memory)
Wifi controller
CPU power strong enough for your task
Ready open source code
It seems that broadcom controllers may be useful here.
Also, you can by off-the-shell Wifi router with usb port and use it for your project
(i.e. Linksys E3000 )