USB Host Ethernet Driver

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.
 
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.
 
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?
 
VID 0x0b95 PID 0x772b

Claims to be an AX88772B

The version of TeensyAsixEthernet i pulled from GitHub had VID set to 0x0895 in claim()
 
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
 
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.
 
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.
 
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.
 
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?
 
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.
 
in IDE 1.8.10 install with TD 1.48 in : arduino_1.8.10\hardware\teensy\avr\libraries\USBHost_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\ASIXEthernet_Test.ino"
 
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.
 
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.
 
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.
 
Wasn't there support in the code for an ethernet wired dongle for wireless WiFi dongle? Any thoughts on extending this to connect that USB to the ethernet code?
 
I believe the support was for an SDIO wifi chip that some dev kits include, but the Ethernet stack is universal so it could work with a USB wifi dongle as long as it has a driver that can do the required connection to a router since I believe that is separate from any TCP/IP stack.
 
The hardest part is finding a dongle that has a reference manual for the usb spec since without it it will be extremely difficult to try and figure out all the commands and what they actually do by using a USB sniffer. I made sure before I picked the USB to Ethernet adapter I did that I could find the manual before I even tried to attempt to get it to work, the only other option is hoping they have open source linux drivers available and study those to piece together a driver.
 
Okay, looking back to find the doc for the 'other' adapter …

I notice your github doesn't have a declared license? One link for FNET showed this?
The FNET is a free, open source, dual TCP/IPv4 and IPv6 Stack (under Apache Version 2.0 license )

It shows this too:
Network Interfaces:
Ethernet (ENET/FEC).
Wi-Fi (QCA4002/4).

Looking for an adapter that uses QCA4002/4 - comes up empty? - but it is qualcomm.com/products/qca4002

<EDIT>: Found this UART/SPI : alibaba.com/product-detail/2-4Ghz-UART-GPIO-Host-Interface
 
That specific chipset doesn't support USB for operation as it's only for manufacturing tests, the most common mode of transport for Wi-Fi chips is SDIO which I believe is the mode that FNET supports by default. FNET itself still has the Apache Version 2.0 license but my driver doesn't have a license, I don't know what the recommended license is for open source Teensy stuff, any suggestions?
 
MIT is Paul's suggested typical if it is to be included:

Link for related libltc info:

https://forum.pjrc.com/threads/5108...for-Teensy-3-2?p=175844&viewfull=1#post175844

I looked briefly at libltc. Unfortunately it's all GPLv3 which means none of it can be used directly in the MIT licensed Teensy Audio library, at least not without encumbering the library with GPL requirements.

Of course you can do this yourself, and any GPL requirements are your own responsibility. Just please do not attempt to contribute any code to the library (like github pull requests) which is copied from GPL sources.


So FrankB wrote code for that thread from scratch and did MIT like here : github.com/FrankBoesing/LinearTimecode-Decoder

As far as chip interface - you got more out of it than my 'wishful' reading. Some chips in the table indicated USB - others didn't, but indeed nothing I saw indeed used that chipset with USB
 
Can you give an old man some hints what to do to get it working?

- I have downloaded vjmuzik/fnet and TeensyASIXEthernet
- the examples compiles, the monitor says:
Code:
USB Host InputFunctions example
USB Ready

Then, nothing. I'm using TD1.50.
Im using an adapter from Amazon, with the AX chipset. The EThernet cable is connected to a switch, which itself is connected to a ethernet <-> wifi gateway

Internet -> router->wlan ... wlan->ethernet->switch->adapter->teensy

The LEDs on the Adapter stays dark. The LEDs on the switch stay dark, too.
Tested the adapter with my PC -> worked out of the box.

I think i'm missing something - what?
Tested on a T3.6 and on a T4.0
 
If the LEDs never light up when plugged in to a network then it’s probably not being claimed by my driver, can you verify which AX chipset your adapter has?
 
Back
Top