The chip is hooked up to an FPGA via gpio. The USB end to connected to a windows machine running, of course the 2104 USB windows driver and putty.
I was able to configure putty to use the USB com port at 40,000,000 baud 8N1 ( yes, 40 Mbaud!) And FPGA side, I saw the the UART signal with bitwidth comparable to 25MHZ clock pulses.
I also managed to implement a verilog module to decode the UART RX , and received the data correctly:
Here's my question: It does seem that the 2104 does NOT transmit the UART bytes in a continuous back-to-back stream. There is a HUGE separation between bytes, effectively cutting down the transfer rate quite a bit. That's a HUGE waste! Anyone has experimented with this chip and saw the same thing? Any way around it?
I am aware that I'm well above the spec. But I'm curious why the chip transmits the bytes so widely spaced? It could be:
- putty on windows is sending 1 byte at a time, and I'm seeing a software delay?
- Inside 2104 is a software controlled transceiver, which process 1 byte at a time? Any Silabs engineer could confirm?
Are you saying so,because in the snapshot of the verilog sim of the UART RX,USB_UART_RXD,the pulses do not appear to be periodic?
PSn my PIC16F877A development board,I have Silabs CP2102 USB-UART controller and....well I did not know of this.
I am also seeing this issue in these drivers for the first time..
Are you saying so,because in the snapshot of the verilog sim of the UART RX,USB_UART_RXD,the pulses do not appear to be periodic?
PSn my PIC16F877A development board,I have Silabs CP2102 USB-UART controller and....well I did not know of this.
I am also seeing this issue in these drivers for the first time..
The RX line should have the ASCII code of whatever sent from putty; its de-serialized value is cumulated in the rxbyte register (bottom right).
I'm saying 'so' because when I sent multiple bytes from host computer (sent a file), I really had to zoom out to see 2 bursts of transfer on UART_RXD line, one byte (10bit time include start and stop bits) per burst, and the bursts are widely spaced from one to another.
Have you ( or anyone else) tried higher datarate, say 2Mbps? What kind of issue are you seeing, is it similar?
Thanks!
- - - Updated - - -
oh, and BTW, just some clarification: it's not verilog sim. It's actual signaltap screenshoot, so the signal seen is real from the 2104 chip.
Have you considered looking at the USB signals and correlate that to the putty transfers? That might prove or disprove that putty is transferring the bytes with the extra spacing.
Have you considered looking at the USB signals and correlate that to the putty transfers? That might prove or disprove that putty is transferring the bytes with the extra spacing.
yeah, we considered using SW USB sniffer to dump USB packets at SW driver level (which I has not ever done); but I'd imagine decoding the packet to find UART content could be difficult.
I also used this RealTerm (realterm.sourceforge.net) to programatically sent data, but it still has spaces; I don't think it's putty problem, but rather host driver, or the chip itself.