Ucom/Uftdi Thru-put

[Hans Petter Selasky]

On Tuesday 30 August 2005 19:51, User Tomdean wrote:
> Sorry this is long, I have attached the code at the bottom.
> ucom_read.c is the FreeBSD code.  UMP2_send.c is the AVR code.
>
> # kldload ucom
> # kldload uftdi
> power up UMP2 and AVR
> In dmesg, I see
>   ucom0: FTDI USB HS Serial Converter, rev 1.10/2.00, addr 2
>
> With a scope, on the USB_DATA+ line, I see groups of 3 uSec activity,
> every 1 mSec.  Within the groups, I see 100 nSec pulses, or a 10 mBit
> rate.
>
> # ./ucom_read
>
> With a scope, on the USB_DATA+ line, I see activity every 1 mSec.
> But, the AVR has groups of activity every 2 mSEC!  Just before the 52
> uSec of activity caused by the AVR, I see a 3 uSec group of activity.
> So, the USB bus has its normal 3 uSec activity every 1 mSec overlayed
> by 52 uSec of AVR activity every 2 mSec.  So, ucom_read only gets the
> USB bus every 2 msec.
>
> The AVR send loop takes 0.9 to 1.1 uSec.  These happen in bursts of 74
> uSec every 2 mSec.  The AVR waits for the UMP2 TX ready signal most of
> the time.
>
> >From looking at the USB_DATA+ line and the UMP2 *TXE signal, the *TXE
>
> signal is not true until the buffer is empty.  The doc states 'If this
> signal is log.1, the buffer is full'.
>
> 10 mSec --+---------+---------+---------+---------
> USB     --1---------123-------1---------123------
> *TXE    ---------------4-------------------4-----
>
>
> 1 - 3  uSec USB activity from FreeBSD
> 2 - 10 uSec gap
> 3 - 52 uSec USB activity from the UMP2
> 4 - 72 uSec activity on the *TXE line, high otherwise.
>
> The nominal return from the FreeBSD read is 62 bytes.  The UMP2 has a
> FT8U245BM chip, which has a 384 byte transmit buffer.
>
> The output from ucom_read,
>
>    Read 1000060 bytes in 32.242824 seconds in chuncks of 62 bytes
>
> This is a thruput of 31017 bytes/second.
>
> Does FreeBSD only request 64 bytes from the UMP2????

cat /sys/dev/usb/uftdi.c | more

...

#define UFTDIIBUFSIZE 64
                      ^^^ 64 bytes every 2 ms = 32000bytes/second

Maybe you can increase this value, but I am not sure if the driver supports 
it.

--HPS