USB to DDR2 trough PIC

Status
Not open for further replies.

jhanus

New Member
Hello,

I just bought a USB drive and although I'm satisfied with it's performance 33MB/s read and 16MB/s write, I just had an idea, since DDR2 is very cheap now and DDR3 soon will replace DDR2, to build a bridge between DDR2 and USB with PIC.

Point of this would be to max out USB 2.0 High Speed standard of 480Mb/s(60MB/s) and future USB 3.0, 4.8 Gbit/s (600 MB/s) with DDR2.
Maxing out could be easily done even with DDR1, but since it's out of production and DDR2 is more cheap it is a obvious choice.

Device could use different memory brands because it will be under clocked anyway(frequency and latency).

DDR1
Code:
Standard name 	Memory clock 	Cycle time 	I/O Bus clock 	Data transfers per second 	JEDEC standard VDDQ voltage 	Peak transfer rate
DDR-200 	100 MHz 	10 ns [1] 	100 MHz 	200 Million 			2.5v +/- 0.2v 	PC-1600 	1600MB/s
DDR-266 	133 MHz 	7.5 ns 		133 MHz 	266 Million 			2.5v +/- 0.2v 	PC-2100 	2100 MB/s
DDR-333 	166 MHz 	6 ns 		166 MHz 	333 Million 			2.5v +/- 0.2v 	PC-2700 	2700 MB/s
DDR-400 	200 MHz 	5 ns 		200 MHz 	400 Million 			2.6v +/- 0.1v 	PC-3200 	3200 MB/s


DDR2
Code:
Standard name 	Memory clock 	Cycle time 	I/O Bus clock 	Data transfers per second 	Peak transfer rate
DDR2-400 	100 MHz 	10 ns 		200 MHz 	400 Million 	PC2-3200 	3200 MB/s
DDR2-533 	133 MHz 	7.5 ns 		266 MHz 	533 Million 	PC2-4200	4266 MB/s
DDR2-667 	166 MHz 	6 ns 		333 MHz 	667 Million 	PC2-5300 	5333 MB/s
DDR2-800 	200 MHz 	5 ns 		400 MHz 	800 Million 	PC2-6400 	6400 MB/s
DDR2-1066 	266 MHz 	3.75 ns 	533 MHz 	1066 Million 	PC2-8500	8533 MB/s



And since USB drives use FLASH memory which is 'good' for sequential write/read it totally fails in random access, which will only get more noticeable in larger capacities, when data is segmented.


Projects:
- NEGATIVE:
A negative side would be it needs a battery/accumulator.

- POSITIVE:
Fast as interface allows it, 'theoretically no limits'.
Longer life cycle, FLASH is based on EEPROM, and it's write cycle limited.




Obviously PIC(at least 16F/18F) doesn't have the power to transport so much information but a memory controller for DDR2 should exist, but I can't find any, so help me to find one(more)!
A similar 'project', built around Xilinx Spartan 3.
What are your opinions?
 
bahhhh i find it useless when sd is much cheaper and non volatile. I would throw that idea away. Im sure they could have done it with one of those new 16GB sd cards and had less of a issue.

And a battery on board lol... sux

Wait ... i think it would be great for hackers and illegal use! when FBI comes just remove battery and your clean! lol Never have to worry! just my opinion.
 
Last edited:
bahhhh i find it useless when sd is much cheaper and non volatile. I would throw that idea away. Im sure they could have done it with one of those new 16GB sd cards and had less of a issue.

And a battery on board lol... sux

Well, everything what you said is right, SD is much cheaper, it doesn't need power source, but even 'new' sdhc can't exceed theoretical 30MB/s.
Exactly here this system steps in, speed is unlimited(limited with bus specifications), it has all characteristics phenomenal, expect it needs a power source.



Wait ... i think it would be great for hackers and illegal use! when FBI comes just remove battery and your clean! lol Never have to worry! just my opinion.
ohhhhh, good idea, one more reason to develop this
 
Sounds like a bad idea:
The battery charges while the system is plugged in, and according to Gigabyte, it can keep four 1GB DIMMs powered for more than ten hours. Battery life will vary depending on the i-RAM's memory module configuration, though.
So if the power goes out for more than 10 hours, then your data is lost!
In the olden days of computing, people installed a driver which gave them a RAM Drive for scratch pad use by windows for temporary files if they had enough RAM available.
 
I see a few practical problems with this project as it is right now.

The first problem I see is that native USB is very difficult to work with. MOst of the USB I see (including where I worked) used a virtual COM port to make the USB appear like an serial port. Obviously this won't work for a USB key. Native USB that has interfaces with Windows directly is very difficult to work with and pull off. I don't think I've ever seen anyone do it yet. Maybe you can find an FPGA IP core made for USB keys that already does this for you. THat would be gold.

THe second is dynamic RAM controller which I, personally, find to be super scary to work with. Especially when you are implementing it yourself. Most micro processors have one built in to handle all the clocking and refresh and the "dual" part of the RAM. I have doubts a PIC could handle that on it's own. You might need to turn an FPGA into a DDR2 RAM controller (with your own synthesis code or find a free IP core online). Most FPGAs are BGA, but there are some out there that are still QFN packages. THey aren't massive, but I think they are big enough to handle the job. Just plop it in alongside your PIC. Compared to the USB, this part is easy (especially since free IP cores for a RAM controller exist online and you just download them). But realy, I think you should just use a microprocessor like an ARM that has a RAM controller built in and normally uses RAM. THen it would be just like a uC storing stuff in RAM and spitting it out over USB. With the PIC you are developing the RAM interface,, the USB, and the file system (the PIC) to bridge the two together all at the same time. With a uC, you are just developing two: the USB interface and the file system. But reading from the RAM itself should be the most natural thing to do with a uC that is meant to do that constantly during it's operation.

THe third is the components themselves. Unless you plan to use stick of RAM (which you say you will because it's cheaper) you still have the issue of the controller to contend with. If you buy one (if they do exist as discrete ICs rather than part of a uC) it's probably going to be a BGA packages. If you go with RAM ICs, well those are for sure going to be BGA packages.

An obvious one is the battery powering the DDR2 RAM, but you've made up your mind on that so it's a moot point.
 
Last edited:
Buy a SSD they're only a few hundred dollars now.

It's a good choice for data storage(what I need in fact), but it's bad for random reads/writes.
I thought that this was already a well worked out project, well what can I lose, I don't have anything else to do in my life anyways.


Your post is golden, you just gave me a phenomenal idea/solution that would ease my pain, practically I lose every problematic component.
If I use ARM can he directly communicate to standard RAM(DDR2)?
 
One of the key differences between a microcontroller and a microprocessor is that a microcontroller has internal ROM and RAM, while a microprocessor primarily runs off of external ROM and RAM. So not just an ARM, but *any* microprocessor that uses DDR2 RAM, which is most of them.

Microprocessors have expensive development tools. So search for the ones that come in an IC package you can use and have an affordable programmer, and have a free compiler like the GNU compiler. ARMs are among some uP that fits those specs. It would probably be nice if you found an uP that has USB capability too (not sure what that means exactly since I think they are usually talking about the integrated FTDI USB-Virtual COM port hardware which isn't what you need for a USB key. THat's probbaly the hardest part of your project and you should do research into that before going any farther).

It's a moot point if you go with a uP, but looking around a free memory controller IP cores that for FPGAs, most don't support up to Gigabytes of memory.
 
Last edited:
I think he wants to be limited by the speed of the USB port and not the flash memory. I wouldn't store any important data though because...well 10 hours is very short time as charging something that is storing data is concerned.

Personally, I use eSATA harddrives. THey are da bomb.
 
Last edited:
So buy an internal SSD. They use DDR.
It would be a very complex project and based on the OPs previous posts far beyond their current skill level.
 
Or get a USB2.0 external harddrive. THey need no batteries, ar far cheaper, and are limited by the speed of the USB port.

It goes without saying they have far more memory density than any other device so they are smallest for their capacity. But the fact is, they will be the same size, if not smaller than something built at home using DDR2 memory sticks.
 
Last edited:

Thanks, to use a uP seems obvious choice, I didn't expect to move so soon and change platforms. I will research how is USB implemented and if it suits me. If you can recommend a ARM and programmer?(books, tutorials)




You can buy USB flash drives that store many Gigabytes. Why advantge would a DDR solution offer? Why would you need it?

To read 16GB I need 7min and to write 16GB 15min, in best case. If I could top USB2.0 standard for 16GB I would need to read/write with DDR 3.5min or on USB3.0(not yet released) 21sek.
One reason is speed, other is, it looks fun.
 
So buy an internal SSD. They use DDR.
It would be a very complex project and based on the OPs previous posts far beyond their current skill level.

'Cheap' SSD on the market are flash based and not RAM based and are useless in specific operations.
Of course it's beyond my temporary skill level, that's why I'm going to do it.




It's not really the capacity nor speed primary, but it looks like fun project and even if I don't make it I will learn much.
 
I'd forego on the DDR2 part for now. Start out smaller...like just learning the ARM (which is very useful) and getting it to do something...ANYTHING over native USB (not the USB-to-virtual COM port ICs and drivers). THat is likely to keep you very busy for a long time. Like I said, no one at work knew how to do it and we ended up using virtual COM ports instead. From their, it's a stone's throw away from a drive. You could even reuse the same hardware if it had enough RAM to start with...but I wouldn't do that since that means investing a lot of money in a high capacity development board or parts in a project that has a high risk of failure.

A USB drive of any kind and size would be very impressive if you pulled it off (or really a native USB device that did anything, even as little as being recognized by Windows). So just try getting an ARM development board with DDR2 ram on it (don't worry about the size for now) and work with that. Worry about the Gigabytes of DDR2 memory in the form of RAM sticks later on when you've managed to reduce the riskiness of this project.

Something like this.
Development Kits for ARM Embedded Computers
 
Last edited:


Will do, thanks for all information.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…