USB Communication


#41

The intention is to gain access to the USB port in regular designs for GPIO and other needs. It seemed so sad to not be able to use the USB port in this way…

The resulting port is only a USB 1.0 Full Speed port, if I understand correctly, so 1.5MB/s is the theoretical limit. I have yet to push it really hard, but the bootloader (upon which the serial code is based) is pretty quick and reports 145kB/s - and it has other stuff to do beyond just transferring.

One other thing to know, is that it has been working in other weird clock setups. For example, one of my examples seems to run well when I set the (solitary) PLL to 96 or 192MHz and just divider the clock down to 48MHz. This gives some flexibility to do data acquisition at the higher frequency, as long as you’re quick.

@lawrie.griffiths, the original adapter of the bootloader to the USB SERIAL context may have other thoughts too.


#42

Full speed is actually 12mbit/second. That’s the speed the USB bootloader operates at. It is actually limited by the write speed of the SPI flash itself. Using the USB core without the SPI interface should be able to get good performance.


#43

I have a board design with a parallel ADC interface that pushes data out at a rate of 70mbit/s. I can divorce this board from it’s DSP companion to capture raw data in alternative ways. I like the idea of trying the tinyBX to do this because it is small and lightweight. Is the BX hardware capable of USB2.0 ‘high speed’ or a limit between ‘full speed’ and high? If it is capable of higher speed, then would a solution be possible with a python interface? I understand that python isn’t optimal for this type of application but I would only need 10~100ms blocks of data at a time.


#44

I think 12Mbps (1.5MBps) is likely to be the upper limit for the USB system on the board as it is.

If you can do some processing on the board that results in less data you might be OK. Is there some filtering needed? Could you do a 1bit-style adaptation?

You could strap on one of the USB 2.0 FTDI modules in FIFO mode (480Mbps) but then, maybe you’d be better off connecting the FTDI and the ADC directly.


#45

it’s 40bit parallel interface from three ADCs all synchronized to one ADC clock and then framed into 4k size packets that are synchronized to a framing clock. Which brings us back to hooking the ADC interface to an FPGA then hooking the FPGA to a USB PHY.


#46

I am wondering how hard it could be to interface as a low-speed USB HID to the PC. Basically I am wondering if I can build a “smart keyboard” (when plugged in it is a keyboard, otherwise a mobile computer) with the TinyFPGA at its main soul.

It seems to be doable as there are AVRs that do it completely in software, but trying to read the USB HID docs is quite challenging at first sight for a beginner.

I figure that it seems not that hard to implement a PS/2 even as a beginner and maybe use a cheap 1eur converter, but if there is already an USB plug why not use that? It seems to take more time of course and maybe for no gain as even the bootloader would need to be rewritten to use some switch to indicate if it is flashing mode or keyboard mode…


#47

I think it should be possible, but is doesn’t look easy. One thing you would need to do is to change the device, endpoint and other descriptors to those for a HID keyboard. The descriptors for the CDC device currently used are in https://github.com/tinyfpga/TinyFPGA-Bootloader/blob/master/common/usb_serial_ctrl_ep.v.

I believe you also need to support different types of transfer. Hid devices need to support asynchronous transfers and you need to return a report for a keypress in the correct report format.

There is some information on this in in https://wiki.osdev.org/USB_Human_Interface_Devices and https://www.beyondlogic.org/usbnutshell/usb4.shtml#Interrupt


#48

There is a new version of the USB - Serial Pipeline code at https://github.com/davidthings/tinyfpga_bx_usbserial

This version cleans up the IN Endpoint quite a bit, fixing a couple of bugs, adding lots of comments. Most notably, it would hang if ever overrun from the device to the host. Definitely grab the update if you’re sending large amounts of data from the FPGA back to the host. Or if you send data when the host is not yet open.