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.
Seems the DEBUG REQUIRED may have been around before? My debug is on now - have to wait to try it off.Originally Posted by dirkenstein
@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\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"
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.
OK totally confused- this is related to compiler optimisation- it stops working when set to 'debug'.
Interesting, I wonder what changes are being made with debug that stops it from working.
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.
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 …
First guess is not 'optimizing' the code results cleaner faster order? Perhaps a dramatic change?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
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.:
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.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
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
Reply With Quote