Forum Rule: Always post complete source code & details to reproduce any issue!
Page 12 of 12 FirstFirst ... 2 10 11 12
Results 276 to 291 of 291

Thread: USB Host Ethernet Driver

  1. #276
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    429
    Ok I spent a couple hours trying to figure out the multicast filter crc algorithm, I finally got it cracked down so it actually works now, I've been testing MDNS and it wasn't working correctly since the filter wasn't set right, but now I can confirm they both work correctly.

  2. #277
    Junior Member
    Join Date
    Sep 2019
    Posts
    14
    Finally got it to work on my AmazonBasics USB adapter- has the vendor ID 0x0b95 rather than 0x0895, though. Gets a DHCP address and is pingable.

    Also, it only seems to work when USBHOST_PRINT_DEBUG is enabled. No idea what is causing the failure without the print() and println() enabled but i'm thinking it's a missing delay or race condition.

    Finally, portscanning the device with nmap causes it to hang quite nicely.

  3. #278
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    429
    The vendor id you have is correct, it is programmed for 0x0B95 however it may be a different chipset, from my understanding most usb to Ethernet adapters share a common driver after they are configured, but depending on the chipset they have to be configured differently and right now it is only setup to configure the AX88772B chipset correctly. What is the product id of your adapter?

  4. #279
    Junior Member
    Join Date
    Sep 2019
    Posts
    14
    VID 0x0b95 PID 0x772b

    Claims to be an AX88772B

    The version of TeensyAsixEthernet i pulled from GitHub had VID set to 0x0895 in claim()

  5. #280
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,110
    I got a second unit not too long ago - may be a different batch from the first one, but I have not connected to Teensy yet - and it now MIA … though I did just find three T_3.6's …

    Found it - new one works - both are reporting this same info and the first in used since this thread started:
    Code:
        VendorID = 0B95, ProductID = 772B, Version = 0001
    Manufacturer: ASIX Elec. Corp.
    enumeration:
    Product: AX88772B

  6. #281
    Junior Member
    Join Date
    Sep 2019
    Posts
    14
    My mistake- the vendor ID is 0x0B95 not 0x0895 in the source code I have. I read 0x0895 for 0x0B95. I think i need better eyes...

    However, i definitely can't get it to start up unless debug is enabled in USBHost_t36.h.

  7. #282
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,110
    Quote Originally Posted by dirkenstein View Post
    My mistake- the vendor ID is 0x0B95 not 0x0895 in the source code I have. I read 0x0895 for 0x0B95. I think i need better eyes...

    However, i definitely can't get it to start up unless debug is enabled in USBHost_t36.h.
    Seems the DEBUG REQUIRED may have been around before? My debug is on now - have to wait to try it off.

    @KurtE or @mjs513 might have a note if you can say what IDE and TeensyDuino versions are in use? It should work with the USBHost_t36 code with TD 1.48, in case there is an older copy in sketchbook\libraries?

    I did just post that the github/cores current dropped on my 1.8.9 IDE fails with error noted there in TeensyThreads and it works on IDE 1.8.10 with just TD 1.48.

  8. #283
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    429
    Also yes there was an issue a while ago where the small delay that was added from printing debug information allowed it to work, but that was fixed. I’ve done my fair share of testing with it on and off to make sure most things work and I haven’t run into that issue again to my knowledge.

    The only issue I’m seeing now is that my TCP socket is messing up after being open for a long time, if I leave it connected it will eventually report that the TCP buffer is full and it never gets freed back up. It’s not frozen and it’s still connected since the computer is still pinging the TCP port to see if the buffer is free, but every time it asks it says the buffer is full. That’s the current issue I’m looking into I just don’t know where the problem lies yet.

  9. #284
    Junior Member
    Join Date
    Sep 2019
    Posts
    14
    Teensy4 600MHz 1.48 , IDE 1.8.10, compile mode is debug.

    How do I tell if the version I have has the debug information issue? I assume the version that fixed this was pushed to GitHub?

  10. #285
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    429
    Yeah it was pushed to GitHub a while ago, I don't remember which version had the issue but I know there have been several more commits since that issue was fixed.

  11. #286
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,110
    in IDE 1.8.10 install with TD 1.48 in : arduino_1.8.10\hardware\teensy\avr\libraries\USBHo st_t36\USBHost_t36.h
    Removed this to a comment:: //#define USBHOST_PRINT_DEBUG

    Compiled again and it still works here running :: "...\libraries\FNET\examples\ASIXEthernet_Test\ASI XEthernet_Test.ino"

  12. #287
    Junior Member
    Join Date
    Sep 2019
    Posts
    14
    I definitely pulled the latest versions from GitHub - but I'm only getting results when USBHOST_PRINT_DEBUG is set in USBHost_t36.h .

    benchtx is reporting about 13Mbit on TCP.

  13. #288
    Junior Member
    Join Date
    Sep 2019
    Posts
    14
    OK totally confused- this is related to compiler optimisation- it stops working when set to 'debug'.

  14. #289
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    429
    Interesting, I wonder what changes are being made with debug that stops it from working.

  15. #290
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    429
    I added a function to turn on promiscuous mode so all ethernet messages come through instead of just the matching MAC address or broadcast messages. This does come at the cost of increased USB bandwidth so it's probably not good for anything but a private network directly connected to a computer with a very specific use case. I need this for a specific use case where I have to be able to respond to multiple MAC addresses at a very low level before a TCP/IP stack so I have not tested it with FNET, another interface would have to be added to FNET in order for it to respond to multiple MAC addresses, but I don't plan on doing that since this is for a separate project.

    This should be called before the usb to Ethernet device is initialized so it's best to call it before myusb.begin() so it's ready by the time it's detected as connected.

  16. #291
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,110
    Quote Originally Posted by vjmuzik View Post
    Interesting, I wonder what changes are being made with debug that stops it from working.
    Hard to say - during beta since Jan 2019 I stuck with making sure the default build working - few attempts at LTO or other could hit an issue. And I didn't see any attempt to push or test beyond that by others with all the core issues.

    Just did a T4 DEBUG compile at 600 MHz and it failed to connect at 100BASE. Recompiled at 396 MHz and it works with DEBUG compile …
    Code:
    IPAddress: 192.168.0.27
    SubnetMask: 255.255.255.0
    Gateway: 192.168.0.1
    DHCPServer: 192.168.0.1
    State: 5
    
    
    Looped: 5236636  LoopedUSB: 1911  FNETMemFree: 130200  LinkSpeed: 100BASE
    
     F_CPU=396000000	deg  C=35
    Looped: 5127862  LoopedUSB: 1911  FNETMemFree: 130200  LinkSpeed: 100BASE
    
     F_CPU=396000000	deg  C=35
    Looped: 5125475  LoopedUSB: 1911  FNETMemFree: 130200  LinkSpeed: 100BASE
    First guess is not 'optimizing' the code results cleaner faster order? Perhaps a dramatic change?

    Another guess was the 'HACKED' code in the 'Functions.ino' code that works with TeensyThreads gets unbalanced as that was a symptom of that not going 100BASE and connecting. Though I changed the 20 to 40 and 60 and removed the #define HACKED and it still failed.

    More crazy yet since it worked under 600 is that going OVER 600 to 816 also works - and one fBench shows 23Mbps TCP transfer.:
    Code:
     F_CPU=816000000	deg  C=44
    Megabytes: 0.127200  Seconds: 0.0440  KBits/Sec: 23127.2727
    Looped: 10682212  LoopedUSB: 1911  FNETMemFree: 130200  LinkSpeed: 100BASE
    I've run this sample from 150 MHz to over 900 MHz with default Compile setting and had it work on at least 2 or 3 T4's.

    So why it fails to connects at 600 MHZ with DEBUG compile is a puzzle ...

    **Note: Fans and heatsinks help cool the T4 - fans maybe more so even a low CFM box fan I just got. I was starting a new build and no heat sink yet - and AFAIK left the IDE OC'd at 900 MHz with no cooling and burned it up.

Posting Permissions

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