On Fri, Aug 08, 2008 at 03:02:13PM +0200, Stefan Reinauer wrote:
Peter Stuge wrote:
- By far the most important one: Use a more intelligent USB chip
- Possibly, in connection with this, use SRAM or DRAM to store or
cache the images transferred from the host side. I think writing the flash takes about as long as transferring it over serial port,
Each 128K block erase+write takes at least 1.8s. Look for a flash part with better performance for the next generation.
so using a faster USB (network instead of serial) chip would only move the bottle neck.
Exactly how a fast USB interface should work is a great question. Making the device a CDC Ethernet device like the GALEP-5 would be nice because it will be easy to interface with, but it would also require the FPGA to run a full IP stack, which I don't think we want.
I would look for other device class specs but possibly the best solution would simply be a vendor specific device with two (IN+OUT) bulk endpoints and an efficient protocol. As long as documentation is provided, I don't think there's any shame in vendor specific devices. (And with the dongle there's source.)
- One habit of the dongle is very ugly; the need to reset it after
loading it. I think it would be a good idea to have the dongle reset itself (or, the lpc part of itself) after the write process is complete.
Great point. It should not need a reset at all. Hopefully this does not go beyond the VHDL.
- 0x3f8 serial port logging support on lpc. (Sorry, I never looked
into this)
Great idea, also VHDL. Besides Stefan's points I have another VHDL request;
* Don't require explicit enable for full memory decode.
- A couple of jumper pins could be preconfigured as host side
software programmable GPIOs for tasks like triggering a reset on the target system.
Yes, some open collector outputs should be cheap to add.
//Peter