Forum Rule: Always post complete source code & details to reproduce any issue!
Page 9 of 12 FirstFirst ... 7 8 9 10 11 ... LastLast
Results 201 to 225 of 291

Thread: USB Host Ethernet Driver

  1. #201
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    Could the speed be tied to F_BUS_ACTUAL since that doesn't increase with the CPU speed like in previous versions?

  2. #202
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    In other news, with the new fixes I can now ping up to 8184 bytes which is the max the terminal lets me send so at least that works now.

  3. #203
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by vjmuzik View Post
    Could the speed be tied to F_BUS_ACTUAL since that doesn't increase with the CPU speed like in previous versions?
    Not sure where the other clocks factor in. Especially for USB.

    Just put USB LAN on the last PJRC T4 Beta unit - at 912 it just turned into a heater. At 912 and 960 it printed first 2 'USB...' startup lines, but went cold at 960.

    Running it seems at 816 on PJRC Beta breakout - PING is the same slower result.

  4. #204
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by vjmuzik View Post
    In other news, with the new fixes I can now ping up to 8184 bytes which is the max the terminal lets me send so at least that works now.
    Indeed larger Ping functions:
    Code:
    T:\T_Downloads\PSTools>ping 192.168.0.23 -n 10 -l 8192
    
    Pinging 192.168.0.23 with 8192 bytes of data:
    Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=7ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
    Reply from 192.168.0.23: bytes=8192 time=7ms TTL=64
    It quits somewhere after this size though:
    Code:
    T:\T_Downloads\PSTools>ping 192.168.0.23 -n 2 -l 10210
    
    Pinging 192.168.0.23 with 10210 bytes of data:
    Reply from 192.168.0.23: bytes=10210 time=7ms TTL=64
    Reply from 192.168.0.23: bytes=10210 time=8ms TTL=64

  5. #205
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    I can't tell where latency is being introduced, based on the timestamps in the serial monitor ping replies are being queued at least within the same millisecond as receiving them so something isn't adding up somewhere.
    Code:
    05:25:52.546 -> rx_data(asix): 1520
    05:25:52.546 -> rx_data(asix): 1520
    05:25:52.546 -> rx_data(asix): 1520
    05:25:52.546 -> rx_data(asix): 1520
    05:25:52.546 -> rx_data(asix): 1520
    05:25:52.546 -> tx_data(asix): 1518
    05:25:52.546 -> tx_data(asix): 1518
    05:25:52.546 -> tx_data(asix): 1518
    05:25:52.546 -> tx_data(asix): 1518
    05:25:52.546 -> tx_data(asix): 1518

  6. #206
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by vjmuzik View Post
    I can't tell where latency is being introduced, based on the timestamps in the serial monitor ping replies are being queued at least within the same millisecond as receiving them so something isn't adding up somewhere.
    ...

    Yeah - Averages of .9ms .vs. 1.26 ms reported time doesn't add up?

    At 0.9 it could be doing 11,000 instead of 8900 - so some loss in overhead before.

    But at 1.26 the possible in 10,000 ms would be 7936 - but same PsPing counts under 700? Second T4 with same adapter - from same dos box - gave same under 700 count.

    I don't have the old lib code to compare … in some hours maybe I'll put it on a T_3.6 ...

  7. #207
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    I'm not sure how wwatson's MSC driver is able to wait until the data transfer completes, if I try to do it the same way he did it just locks forever and never frees up. Essentially I will have to have a way to do this because UDP messages get sent so fast that it fills up all my buffers before the first one is even sent, it won't make a difference for TCP, but UDP is losing messages because of it.

  8. #208
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by vjmuzik View Post
    I'm not sure how wwatson's MSC driver is able to wait until the data transfer completes, if I try to do it the same way he did it just locks forever and never frees up. Essentially I will have to have a way to do this because UDP messages get sent so fast that it fills up all my buffers before the first one is even sent, it won't make a difference for TCP, but UDP is losing messages because of it.
    Maybe @wwatson will get back to give your code a look. KurtW and MJS513 also have USBHost background that might help?

  9. #209
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    Ok so like I've said before, bigger buffers = more speed, I've been playing around with the TCP buffer size and the results speak for themselves, but that comes at the increase of RAM usage so there is a tradeoff to be made which would be up to whoever writes their Arduino sketch because the number isn't hardcoded. So with a TCP buffer size of 64k, a transmit buffer size of 64k, and a FNET heap size of 128k to cover the TCP buffer I'm getting these results:
    Code:
    17:03:38.379 -> Starting benchtx...
    17:03:38.379 -> Benchmark client started.
    17:03:38.379 -> Protocol: TCP
    17:03:38.379 -> Remote IP Addr: 192.168.0.55
    17:03:38.379 -> Remote Port: 7007
    17:03:38.379 -> Message Size: 65536
    17:03:38.379 -> Num. of messages: 100
    17:03:38.379 -> 
    17:03:39.512 -> Megabytes: 6.553600  Seconds: 0.9850  KBits/Sec: 53227.2081
    17:03:41.292 -> Starting benchtx...
    17:03:41.292 -> Benchmark client started.
    17:03:41.292 -> Protocol: TCP
    17:03:41.292 -> Remote IP Addr: 192.168.0.55
    17:03:41.292 -> Remote Port: 7007
    17:03:41.292 -> Message Size: 65536
    17:03:41.292 -> Num. of messages: 100
    17:03:41.292 -> 
    17:03:42.345 -> Megabytes: 6.553600  Seconds: 1.0160  KBits/Sec: 51603.1496
    So the speed is there it's just a matter of how much RAM you want to sacrifice for your needs, this used 44% of RAM on the T4.0 and probably won't compile on the T3.6.

  10. #210
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by vjmuzik View Post
    Ok so like I've said before, bigger buffers = more speed
    ...
    Makes sense - can't move a lot of data unless there is room for it to stream into or out of.

    Watching the SD development - it runs at high speed with blocks of 512KB - and for real performance those blocks need to stream in multiples - easy work for a PC with RAM of multi GB's.

  11. #211
    Senior Member
    Join Date
    Aug 2017
    Posts
    146
    Quote Originally Posted by vjmuzik View Post
    I'm not sure how wwatson's MSC driver is able to wait until the data transfer completes, if I try to do it the same way he did it just locks forever and never frees up. Essentially I will have to have a way to do this because UDP messages get sent so fast that it fills up all my buffers before the first one is even sent, it won't make a difference for TCP, but UDP is losing messages because of it.
    Sorry I have been silent so long. I have been down with a severe cold for a week now. Today I continued to work on an example of your ASIX driver with MSC using a modified version of WXMZ's RawWrite sketch and your ASIXEthernet_test.ino sketch. Results so far are not to good but I need more time to play with it. This is the results of the first try:
    Code:
    USB Host InputFunctions example
    USB Ready
    Test logger_RawWrite
    uSDFS_VER:30_Jun_19_07_17
    BUFFSIZE :8192
    Dev Type :2:/
    File System FS_FAT32
    Free Disk Size 1740204 clusters
    Cluster Size 16 sectors
    Sector Size 512 bytes
    
    Change drive
    A_00001.dat
    stat FR_NO_FILE 0
     opened FR_OK 0
    
    Mutex initialized: 0
    Mutex initialized: 1
    TCP/IP stack initialization is done.
    
    SetMACAddress: 0050B6BE8BB4
    MulticastJoin: 333300000001
    MulticastTable: 
    0
    0
    10000000
    0
    0
    0
    0
    0
    MulticastJoin: 3333FFE1815E
    MulticastTable: 
    0
    0
    10000000
    0
    0
    0
    0
    10000
    netif Initialized
    Initializing DHCP
    DHCP initialization done!
    IPAddress: 0.0.0.0
    SubnetMask: 0.0.0.0
    Gateway: 0.0.0.0
    DHCPServer: 0.0.0.0
    State: 2
    
    
    IPAddress: 192.168.0.103
    SubnetMask: 255.255.255.0
    Gateway: 192.168.0.1
    DHCPServer: 192.168.0.1
    State: 5
    
    
    ................................................................
    .................................... (1453501006 - 0.022544 MB/s)
     (open: 290992 us; close: 4096000 us; write: min,max: 11985 10134972 us)
    
    openDir FR_OK
    A_00001.dat 32768000 2019-10-07 14:58:34
    unmount FR_OK
    Ping is working in Linux.

    This is the result with ASIX adapter unplugged:
    Code:
    USB Host InputFunctions example
    Test logger_RawWrite
    uSDFS_VER:30_Jun_19_07_17
    BUFFSIZE :8192
    Dev Type :2:/
    File System FS_FAT32
    Free Disk Size 1736204 clusters
    Cluster Size 16 sectors
    Sector Size 512 bytes
    
    Change drive
    USB Ready
    A_00001.dat
    stat FR_OK 0
     opened FR_OK 0
    
    ................................................................
    .................................... (13234998 - 2.475860 MB/s)
     (open: 361992 us; close: 33000 us; write: min,max: 11979 68980 us)
    
    openDir FR_OK
    A_00001.dat 32768000 2019-10-07 15:14:14
    unmount FR_OK
    I will add the sketch to MSC's examples folder soon.
    Need more time to examine your USB driver for ASIX

  12. #212
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    Yeah that makes sense, not to mention the TCP buffer size let’s it transmit more messages before it stops and waits for an acknowledge message from the computer which is where the speed increase is really coming from in that sense because it’s spending less time waiting. The TCP buffer from the computer is 256k so that’s probably where it would need to be at to get 100Mbit/sec, but that’s not exactly realistic with the amount of RAM we have though. I believe without the overhead of USB we would achieve it without such huge buffers, but as it stands there’s quite a bit of latency if it has to wait for a response a bunch of times which is what you see with the ping tests since it’s responding to every message that’s received.

  13. #213
    Senior Member
    Join Date
    Aug 2017
    Posts
    146

    Not getting anywhere with this

    @all,

    I have been trying to figure out why MSC will not work properly with ASIXEthernet. It's going to take somebody with more Ethernet networking skills than I have. All other host USB interfaces like keyboard, mouse and joysticks work properly. Not sure how to proceed from here.

    Here is the sketch I used to test with:
    test_ASIX_rawWrite.zip

    Upload to T4 or T36. It will go through initialization and the ASIX will show it's connected at stage 5. Then you can ping it showing about 0.6ms as an average. The RawWrite file will open and that's it! Waiting for RawWrite to complete can take up to several minutes complete unless you unplug the ASIX adapter. Then RawWrite completes as normal. Nothing Locks up.It can be very erratic. Sometimes you have to power off the T4 and power on again to even get MSC to do it's thing.

    At his point I am at a loss. I truly believe it's a problem with MSC.

  14. #214
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    I think it’s the way you lock MSC while waiting for the USB transfer to complete, it appears to me like it only triggers if the previous transfer wasn’t complete before it sends the next one out. Which probably works fine with the other host drivers because they aren’t queuing as much data as mine does so the while loop never triggers. I don’t think the while loop works as you intended it to because when I try to implement the same while loop to wait for a transfer to complete the driver locks up and never returns.

  15. #215
    Senior Member
    Join Date
    Aug 2017
    Posts
    146
    Quote Originally Posted by vjmuzik View Post
    I think it’s the way you lock MSC while waiting for the USB transfer to complete, it appears to me like it only triggers if the previous transfer wasn’t complete before it sends the next one out. Which probably works fine with the other host drivers because they aren’t queuing as much data as mine does so the while loop never triggers. I don’t think the while loop works as you intended it to because when I try to implement the same while loop to wait for a transfer to complete the driver locks up and never returns.
    Ok, I see what you are saying. Time for a re-write. First understand the queuing process.

    Thanks

  16. #216
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    Ok so I added an experimental method that seems to kind of work, it only gets called when the all the queue transmit buffers are full but it lets it get stuck in a while loop that just calls myusb.Task() from the arduino sketch so the usb continues to work so it sends out at least 1 queue transfer so another buffer is available. This is mainly for UDP since TCP never overflows my buffer limit, the transfer speeds of this method are dodgy at best, sometimes it's fast and sometimes it's slow but at least the messages aren't lost anymore. This really isn't my ideal solution, because like I said earlier I don't want it to just lock up and wait, but this is just experimental to test if it should be a thing. I also lowered all the buffers to 32k instead of 64k so there is more RAM for other code in the future, placed the FNET heap in DMAMEM, and doubled it's size so that it uses the other half of the T4.0 RAM that isn't normally used so more is available for other code, this didn't seem to impact the performance so I believe it's fine there.

    Sadly I don't know what would speed up the TCP receive speeds, likely bigger queue receive buffers but the bigger buffer always seems to introduce random errors for some reason plus takes up more RAM space.
    Here's my TCP transmit speeds with the 32k buffers and an increasing amount of messages to test stability at high numbers:
    Code:
    00:37:26.214 -> Starting benchtx...
    00:37:26.214 -> Benchmark client started.
    00:37:26.214 -> Protocol: TCP
    00:37:26.214 -> Remote IP Addr: 192.168.0.55
    00:37:26.214 -> Remote Port: 7007
    00:37:26.214 -> Message Size: 32374
    00:37:26.214 -> Num. of messages: 100
    00:37:26.214 -> 
    00:37:27.059 -> Megabytes: 3.237400  Seconds: 0.7860  KBits/Sec: 32950.6361
    00:37:31.553 -> Starting benchtx...
    00:37:31.553 -> Benchmark client started.
    00:37:31.553 -> Protocol: TCP
    00:37:31.553 -> Remote IP Addr: 192.168.0.55
    00:37:31.553 -> Remote Port: 7007
    00:37:31.553 -> Message Size: 32374
    00:37:31.553 -> Num. of messages: 1000
    00:37:31.553 -> 
    00:37:38.341 -> Megabytes: 32.374000  Seconds: 6.7860  KBits/Sec: 38165.6351
    00:37:56.934 -> Starting benchtx...
    00:37:56.934 -> Benchmark client started.
    00:37:56.934 -> Protocol: TCP
    00:37:56.934 -> Remote IP Addr: 192.168.0.55
    00:37:56.934 -> Remote Port: 7007
    00:37:56.934 -> Message Size: 32374
    00:37:56.934 -> Num. of messages: 10000
    00:37:56.934 -> 
    00:39:09.037 -> Megabytes: 323.740000  Seconds: 68.8560  KBits/Sec: 37613.5703

  17. #217
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by vjmuzik View Post
    Ok so I added an experimental method that seems to kind of work,
    ...
    Using code from 4 hours back now - machine and network rebooted - IP addr changed.

    Pings still slow at 600 versus 8900 on fast PSping64. This is with T4 at 600 MHz.

    Seeing this on SerMon for UDP then TCP:
    Code:
    Megabytes: 0.204800  Seconds: 0.1740  KBits/Sec: 9416.0920
    Megabytes: 0.204800  Seconds: 0.1860  KBits/Sec: 8808.6022
    Megabytes: 0.204800  Seconds: 0.1920  KBits/Sec: 8533.3333
    Megabytes: 0.204800  Seconds: 0.1980  KBits/Sec: 8274.7475
    Megabytes: 2.048000  Seconds: 1.7040  KBits/Sec: 9615.0235
    Megabytes: 2.048000  Seconds: 1.7340  KBits/Sec: 9448.6736
    Megabytes: 2.048000  Seconds: 1.7400  KBits/Sec: 9416.0920
    Megabytes: 2.048000  Seconds: 1.7640  KBits/Sec: 9287.9819
    fBench shows:
    Code:
    Udp	192.168.0.5	1.282	2,048,000	12,779.298
    Udp	192.168.0.5	1.290	2,048,000	12,698.626
    Udp	192.168.0.5	1.256	2,048,000	13,044.073
    Udp	192.168.0.5	1.265	2,048,000	12,952.063
    Tcp	192.168.0.5	1.638	2,048,000	10,000.988
    Tcp	192.168.0.5	1.622	2,048,000	10,098.005
    Tcp	192.168.0.5	1.627	2,048,000	10,068.497
    Tcp	192.168.0.5	1.629	2,048,000	10,059.992
    And again no connect at 912 MHz

  18. #218
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    I still don’t know what happened to ping and the transfer speeds are a little skewed when you don’t transfer a lot of data at once because there is a little delay at the start and end of a stream of messages that’s why I test with such high number to try and factor that out. However, at this point I am convinced we are achieving roughly the full 100Mbit/sec transfer speed, but with the overhead of some of the protocols it brings the speed tests down.

  19. #219
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Ping was good before some prior change … never worked the same since

    I got CONNECT at 912 MHz - also works at " F_CPU=816000000":
    Code:
    USB Host InputFunctions example
    USB Ready
    
     F_CPU=912000000	deg  C=54
    Looped: 1  LoopedUSB: 3507  LinkSpeed: 10BASE
    Looped: 1  LoopedUSB: 0  LinkSpeed: 10BASE
    Looped: 6243687  LoopedUSB: 1680  LinkSpeed: 10BASE
    Mutex initialized: 0
    Mutex initialized: 1
    TCP/IP stack initialization is done.
    
    SetMACAddress: 0050B6BE8BB4
    MulticastJoin: 333300000001
    MulticastTable: 
    0
    0
    10000000
    0
    0
    0
    0
    0
    MulticastJoin: 3333FFE225AB
    MulticastTable: 
    0
    0
    10000000
    0
    0
    0
    0
    100000
    netif Initialized
    Initializing DHCP
    DHCP initialization done!
    IPAddress: 0.0.0.0
    SubnetMask: 0.0.0.0
    Gateway: 0.0.0.0
    DHCPServer: 0.0.0.0
    State: 2
    
    
    IPAddress: 192.168.0.8
    SubnetMask: 255.255.255.0
    Gateway: 192.168.0.1
    DHCPServer: 192.168.0.1
    State: 5
    
    
    Looped: 12670374  LoopedUSB: 3507  FNETMemFree: 64656  LinkSpeed: 100BASE
    Looped: 12472042  LoopedUSB: 3486  FNETMemFree: 64656  LinkSpeed: 100BASE
    I changed the END of setup() to this::
    Code:
    setup(){
    …
      setHandleIsConnected(handleIsConnected);
    #if defined(__IMXRT1062__)
      Serial.printf("\n F_CPU=%u", F_CPU_ACTUAL );
      Serial.printf( "\tdeg  C=%u\n" , (uint32_t)tempmonGetTemp() );
    #endif
      delay ( 1000 );
    }
    The loop() polling "It Seems" is too fast as higher speeds to allow 10 base to change to allow connection processing without the other things in the usbthread() processing first!

    delay(2000) does not work for 960 MHz

    I'm working on an alternative direction with the original suggested HACKED values - it works for 912 MHz without the delay(1000) in setup();

  20. #220
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Leaving setup() without post #219's delay(1000);

    This works for connect at 912 MHz - but still not 960 MHz.

    I changed it to use a higher count { 4000 instead of 2000 } and 960 still fails, I added a counter to repeat { of 4 or 2000 times ) the higher count for multiple times at the start - neither worked for 960 MHz.

    AFAIK - guessing - the higher call rates of this loop(){ ... myusb.Task(); asix1.read(); ...} before connection (USB? LAN?} starts without the other things in usbthread() prevent the initial connect?

    But going back to the original HACKED concept of stay longer when usbthread() is first invoked:
    Code:
    void usbthread() {
      uint32_t cc = 0;
      while(1) {
        myusb.Task();
        asix1.read();
        checkLink();
        if(fnet_netif_is_initialized(current_netif)){
          fnet_poll();
          fnet_service_poll();
        }
        #ifdef STATS
        LoopedUSB++;
        #endif
        #ifdef HACKED
        cc++;
        if ( cc > 2000 ) {
          cc=1980;
          threads.yield();
        }
        #endif
      }
    }

  21. #221
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    @vjmuzik - was up too late testing prior posts … then wondering what about delayed start - that is T4 starts with no USB connected ?

    So with post #220 code::
    >>The T4 powered down, USB unplugged to LAN adapter.
    >> Power T4, see a couple 'looped' messages pass
    >> Plug in USB LAN adapter at 912 MHZ - it connects and comes up running.

    So there is something Early in the USB is seems - though this same process at 960 MHz still fails.

    NOTE: to run over 816 MHz an uncooled T4 may not run. A copper heat sink is in use here and internal temp is 67C {152.6 F} at 912 MHz

    ANOTHER ITEM of note::
    > Restarting the 912 MHz T4 it did not come up right away with USB plugged in - even using above code.
    >> Unplug USB {no LAN light blinks present}
    >> Then plug USB and the LAN lights come to life.

  22. #222
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    Likely it’s getting caught up somewhere in the initialization phase when it has to send all the queue controls one after the other, if you turn on the USBHOST_PRINT_DEBUG in the USBHost_t36.h file you can see at what point it fails and that should give some insight. I don’t have any heat sinks or I would test at the higher speeds.

  23. #223
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by vjmuzik View Post
    Likely it’s getting caught up somewhere in the initialization phase when it has to send all the queue controls one after the other, if you turn on the USBHOST_PRINT_DEBUG in the USBHost_t36.h file you can see at what point it fails and that should give some insight. I don’t have any heat sinks or I would test at the higher speeds.

    Enabled debug print at F_CPU=960000000::
    Code:
    USB Host InputFunctions example
    USB2 PLL running
     reset waited 6
    USBHS_ASYNCLISTADDR = 0
    USBHS_PERIODICLISTBASE = 2003B000
    periodictable = 2003B000
    USB Ready
    port change: 10001803
        connect
    
     F_CPU=960000000	deg  C=62
    Looped: 1  LoopedUSB: 0  LinkSpeed: 10BASE	deg  C=62
      begin reset
    port change: 18001205
      port enabled
      end recovery
    new_Device: 480 Mbit/sec
    new_Pipe
    enumeration:
    enumeration:
    enumeration:
    Device Descriptor:
      12 01 00 02 FF FF 00 40 95 0B 2B 77 01 00 01 02 03 01 
        VendorID = 0B95, ProductID = 772B, Version = 0001
        Class/Subclass/Protocol = 255 / 255 / 0
        Number of Configurations = 1
    enumeration:
    enumeration:
    Manufacturer: ASIX Elec. Corp.
    enumeration:
    Product: AX88772B
    enumeration:
    Serial Number: E225AB
    enumeration:
    Config data length = 39
    enumeration:
    Configuration Descriptor:
      09 02 27 00 01 01 04 A0 64 
        NumInterfaces = 1
        ConfigurationValue = 1
      09 04 00 00 03 FF FF 00 07 
        Interface = 0
        Number of endpoints = 3
        Class/Subclass/Protocol = 255 / 255 / 0
      07 05 81 03 08 00 0B 
        Endpoint = 1 IN
        Type = Interrupt
        Max Size = 8
        Polling Interval = 11
      07 05 82 02 00 02 00 
        Endpoint = 2 IN
        Type = Bulk
        Max Size = 512
        Polling Interval = 0
      07 05 03 02 00 02 00 
        Endpoint = 3 OUT
        Type = Bulk
        Max Size = 512
        Polling Interval = 0
    enumeration:
    USBHub memory usage = 960
    USBHub claim_device this=20002E00
    USBHub memory usage = 960
    USBHub claim_device this=20002A20
    Descriptor 4 = INTERFACE
    ASIXEthernet claim this=200031E0
    type=1
    vid=B95, pid=772B, bDeviceClass = 255, bDeviceSubClass = 255, bDeviceProtocol = 0
    numEndpoints=3
          interrupt_size = 8
          interrupt_ep = 129
          interrupt_interval = 11
          rx_size = 512
          rx_ep = 130
          rx_interval = 0
          tx_size = 512
          tx_ep = 3
          tx_interval = 0
    new_Pipe
    new_Pipe
    new_Pipe
    allocate_interrupt_pipe_bandwidth
      ep interval = 11
      interval = 256
     best_bandwidth = 3, at offset = 0
    Control - ASIX...
    Descriptor 5 = ENDPOINT
    Descriptor 5 = ENDPOINT
    Descriptor 5 = ENDPOINT
    Looped: 6661980  LoopedUSB: 3660  LinkSpeed: 10BASE	deg  C=63
    Looped: 12289359  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=64
    Looped: 12289361  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=64
    Looped: 12289409  LoopedUSB: 3486  LinkSpeed: 10BASE	deg  C=64
    Looped: 12289368  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=65
    Looped: 12289361  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=65
    Looped: 12289273  LoopedUSB: 3486  LinkSpeed: 10BASE	deg  C=65
    Looped: 12289363  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=65
    Looped: 12289245  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=65
    Looped: 12289392  LoopedUSB: 3486  LinkSpeed: 10BASE	deg  C=65
    Looped: 12289253  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=66
    Looped: 12289357  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=66
    Moved to 912 MHz - and the HACKED change was no longer enough for connect - had to restore the delay(1000); in setup() and then I get this:
    Code:
    USB Host InputFunctions example
    USB2 PLL running
     reset waited 6
    USBHS_ASYNCLISTADDR = 0
    USBHS_PERIODICLISTBASE = 2003B000
    periodictable = 2003B000
    USB Ready
    port change: 10001803
        connect
    
     F_CPU=912000000	deg  C=57
      begin reset
    port change: 18001205
      port enabled
      end recovery
    new_Device: 480 Mbit/sec
    new_Pipe
    enumeration:
    enumeration:
    enumeration:
    Device Descriptor:
      12 01 00 02 FF FF 00 40 95 0B 2B 77 01 00 01 02 03 01 
        VendorID = 0B95, ProductID = 772B, Version = 0001
        Class/Subclass/Protocol = 255 / 255 / 0
        Number of Configurations = 1
    enumeration:
    enumeration:
    Manufacturer: ASIX Elec. Corp.
    enumeration:
    Product: AX88772B
    enumeration:
    Serial Number: E225AB
    enumeration:
    Config data length = 39
    enumeration:
    Configuration Descriptor:
      09 02 27 00 01 01 04 A0 64 
        NumInterfaces = 1
        ConfigurationValue = 1
      09 04 00 00 03 FF FF 00 07 
        Interface = 0
        Number of endpoints = 3
        Class/Subclass/Protocol = 255 / 255 / 0
      07 05 81 03 08 00 0B 
        Endpoint = 1 IN
        Type = Interrupt
        Max Size = 8
        Polling Interval = 11
      07 05 82 02 00 02 00 
        Endpoint = 2 IN
        Type = Bulk
        Max Size = 512
        Polling Interval = 0
      07 05 03 02 00 02 00 
        Endpoint = 3 OUT
        Type = Bulk
        Max Size = 512
        Polling Interval = 0
    enumeration:
    USBHub memory usage = 960
    USBHub claim_device this=20002E00
    USBHub memory usage = 960
    USBHub claim_device this=20002A20
    Descriptor 4 = INTERFACE
    ASIXEthernet claim this=200031E0
    type=1
    vid=B95, pid=772B, bDeviceClass = 255, bDeviceSubClass = 255, bDeviceProtocol = 0
    numEndpoints=3
          interrupt_size = 8
          interrupt_ep = 129
          interrupt_interval = 11
          rx_size = 512
          rx_ep = 130
          rx_interval = 0
          tx_size = 512
          tx_ep = 3
          tx_interval = 0
    new_Pipe
    new_Pipe
    new_Pipe
    allocate_interrupt_pipe_bandwidth
      ep interval = 11
      interval = 256
     best_bandwidth = 3, at offset = 0
    Control - ASIX...
    Descriptor 5 = ENDPOINT
    Descriptor 5 = ENDPOINT
    Descriptor 5 = ENDPOINT
    control callback (asix) 1
    Done
    control callback (asix) 2
    Done
    control callback (asix) 3
    nodeID: 00 50 B6 E2 25 AB 
    control callback (asix) 4
    Done
    control callback (asix) 5
    Done
    control callback (asix) 6
    Done
    control callback (asix) 7
    Done
    control callback (asix) 8
    Done
    control callback (asix) 9
    Done
    control callback (asix) 10
    Done
    control callback (asix) 11
    Done
    control callback (asix) 12
    Done
    control callback (asix) 13
    Done
    control callback (asix) 14
    Done
    control callback (asix) 15
    Done
    control callback (asix) 16
    Done
    control callback (asix) 17
    Done
    control callback (asix) 18
    Done
    control callback (asix) 19
    Done
    control callback (asix) 20
    Done
    control callback (asix) 21
    Done
    control callback (asix) 22
    Done
    control callback (asix) 23
    Done
    control callback (asix) 24
    Done
    control callback (asix) 25
    Done
    control callback (asix) 26
    Done
    control callback (asix) 27
    Done
    control callback (asix) 28
    Done
    control callback (asix) 29
    Done
    control callback (asix) 30
    Done
    control callback (asix) 31
    Done
    control callback (asix) 32
    Done
    control callback (asix) 33
    Done
    control callback (asix) 34
    Done
    control callback (asix) 35
    Done
    control callback (asix) 36
    Done
    control callback (asix) 37
    Done
    control callback (asix) 38
    Done
    control callback (asix) 39
    Done
    control callback (asix) 40
    Done
    control callback (asix) 41
    Done
    control callback (asix) 42
    Done
    control callback (asix) 43
    Done
    control callback (asix) 44
    Done
    control callback (asix) 45
    Done
    control callback (asix) 46
    Done
    control callback (asix) 47
    Done
    control callback (asix) 255
    Looped: 1  LoopedUSB: 7487  LinkSpeed: 10BASE	deg  C=58
    Looped: 1  LoopedUSB: 0  LinkSpeed: 10BASE	deg  C=58
    Looped: 5602844  LoopedUSB: 1680  LinkSpeed: 10BASE	deg  C=59
    control callback (asix) 49
    Done
    control callback (asix) 50
    Done
    control callback (asix) 51
    Done
    control callback (asix) 52
    Done
    control callback (asix) 53
    Done
    control callback (asix) 54
    Done
    control callback (asix) 55
    Done
    control callback (asix) 56
    Done
    control callback (asix) 57
    Done
    control callback (asix) 58
    Done
    control callback (asix) 59
    Done
    control callback (asix) 60
    Done
    control callback (asix) 61
    Done
    control callback (asix) 62
    Done
    control callback (asix) 63
    Done
    control callback (asix) 64
    Done
    control callback (asix) 65
    Done
    control callback (asix) 254
    Mutex initialized: 0
    Mutex initialized: 1
    TCP/IP stack initialization is done.
    
    SetMACAddress: 0050B6BE8BB4
    MulticastJoin: 333300000001
    MulticastTable: 
    0
    0
    10000000
    0
    0
    0
    0
    0
    MulticastJoin: 3333FFE225AB
    MulticastTable: 
    0
    0
    10000000
    0
    0
    0
    0
    100000
    netif Initialized
    Initializing DHCP
    DHCP initialization done!
    IPAddress: 0.0.0.0
    SubnetMask: 0.0.0.0
    Gateway: 0.0.0.0
    DHCPServer: 0.0.0.0
    State: 2
    
    
    control callback (asix) 254
    control callback (asix) 254
    IPAddress: 192.168.0.12
    SubnetMask: 255.255.255.0
    Gateway: 192.168.0.1
    DHCPServer: 192.168.0.1
    State: 5
    
    
    Looped: 11404940  LoopedUSB: 3507  FNETMemFree: 64656  LinkSpeed: 100BASE	deg  C=60
    Looped: 11224911  LoopedUSB: 3486  FNETMemFree: 64656  LinkSpeed: 100BASE	deg  C=59
    Looped: 11223853  LoopedUSB: 3507  FNETMemFree: 64656  LinkSpeed: 100BASE	deg  C=60
    Looped: 11223976  LoopedUSB: 3507  FNETMemFree: 64656  LinkSpeed: 100BASE	deg  C=60
    EDIT RED where the text diverges
    Last edited by defragster; 10-09-2019 at 07:42 PM. Reason: EDIT RED where the text diverges

  24. #224
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    These are ones just received like the one in use: amazon.com/gp/product/B00637X42A

    I re-ran 960 MHz with setup(){… delay(1000);} and no change.

    Plug and unplug USB and - as above - stops after this as far as USB feeback:
    Code:
     best_bandwidth = 3, at offset = 0
    Control - ASIX...
    Descriptor 5 = ENDPOINT
    Descriptor 5 = ENDPOINT
    Descriptor 5 = ENDPOINT

  25. #225
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    420
    So it looks like the first queue control transfer doesn’t complete so it never goes anywhere, oddly enough the T3.6 would get stuck there sometimes as well when I first uploaded new code without a power cycle and I noticed the T4.0 never got stuck there when I switched to it. Seems like it still happens with the T4.0, but only at higher clock speeds.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •