FPGA <--> pendrive
As already written it does not depend on an operating system (LINUX).However, given that my current ability does not allow me to boot linux on my FPGA (which means FPGA could only be a USB DEVICE), I could only do FPGA <-- pendrive , but not FPGA --> pendrive
Please correct me if wrong.
This is READ and WRITE and has nothing to do with HOST or DEVICE.I could only do FPGA <-- pendrive , but not FPGA --> pendrive
I'm not sure what pull-up and down resistors have to do with bidirectional operation. Different resistor values shall be implemented for down- and up-stream ports, as shown in your post #10. I was suggesting tri-state drivers in case you want to switch resistors, e.g. to signal activation/deactivation of an upstream (device) port or change speed. Otherwise you can use fixed resistor.
Code Verilog - [expand] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 module bidirec (oe, clk, inp, outp, bidir); // Port Declaration input oe; input clk; input [7:0] inp; output [7:0] outp; inout [7:0] bidir; reg [7:0] a; reg [7:0] b; assign bidir = oe ? a : 8'bZ ; assign outp = b; // Always Construct always @ (posedge clk) begin b <= bidir; a <= inp; end endmodule
With Intel FPGA, there's no calibrated series termination that matches the USB FS requirement of 28 - 44 ohm driver impedance. You are probably able to achieve the impedance by choosing a suitable drive strength in uncalibrated mode, but the impedance will be subjected to type and temperature variation. Thus it's probably better to use a low driver impedance along with series resistors.
Because a HOST can not decide the sppeed, this is the job of the DEVICE to show it´s capabilities.As in figure 7-20 at post #10, Why no pullup at D+ line to indicate full-speed mode ?
A HOST does not need software. You may implement all the USB_HOST functions in HW. It´s your decision how to do this.USB_HOST requires software driver (libusb). I do not get why FPGA without any OS support for software driver could ever become a HOST ?
"tri" state means "3" state. Here the three states of a logic output.1) How do tri-state drivers switch resistors ? I believe tri-state outputs are either the input or Z
Yes. I don't think however, that exact driver impedance is a problem for your application. It only matters if you need to utilize the maximum USB cable length of 5 m.I could only choose on-chip termination of 25 ohm (cyclone IV fpga IO allows only 25 ohm or 50 ohm on-chip termination) and add external discrete 10 ohm resistors to both D+ and D- FPGA pins. Do I get this right ?
As already explained by KlausST, this involves implementing the host function to control the pen drive. The required protocol is specified by the MSC (mass storage device class) documents. This is a relative complex specification comprised of several parts and referencing other industry standard storage device protocols like ATAPI and SCSI.What I plan to do at most is writing very small amount of data into a cheap USB pendrive and read the same data back from it.
So, FPGA <--> pendrive
would you be able to suggest another simpler project where I could still experiment with the usbcorev softcore without involving my computer USB port ?
I find a HOST way more difficult than a DEVICE.
See post #15. The exact single ended driver impedance matching the cable would be 45 ohm. There's no reasoning in the USB spec for the 28 - 44 ohm range of the full speed driver. In case of a combined FS/HS driver, the specification is changed to 45 ohm +/- 10%.I wish to know how does this 28 -- 44 ohm driver impedance relate to the typical 90 ohm USB transmission line ?
Technically configuring Tx outputs as tri-stated CMOS3.3 with 6 mA drive strength should give a decent 50-Ohm impedance match, so no resistors might be needed
Passive "deriving" from VBUS has a lot of problems. If the divider has low resistance and "equivalent" pull-up meets the minimum relaxation time of 2.5 us, the device will likely fail the suspend current limit. If the divider has high-value resistors, it may fail either 2.5 us, or 15k pull-downs on host side will lead to invalid pull-up level. I recommend the pull-up to be "controlled" through another GPIO
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?