USB Host Ethernet Driver

I think quite a few things might have to be changed for CPU stuff to be supported correctly because the way I believe it’s setup originally it would overwrite or change some of registers and stuff that Teensyduino does because it has its drivers for serial and writing to flash memory that we probably don’t want happening at the same time.
 
Technically speaking, the way I have FNET setup it just transfers raw Ethernet frames, so if you have existing code the already initializes the PHY and sets it up you can just point the Ethernet frames to the FNET library and point the FNET library output to the MAC hardware and it should be good to go.
 
The T_3.6 and T4 USBHost second usb are the same hardware - I wonder if that applies to the T4 Ethernet and T_3.6 as well? If so then the new T4.x using the 1062 could work like the T_3.6 - though any needed MCU diffs may get ported to 1062 if not already?

There are a few of those T_3.6 adapters out there - not sure I have time/background to pull that over.

@manitou IIRC did baseline testing of the T_3.6 hardware before.
 
I’m sure any needed differences would be easy to get setup, the only lacking software support for the T3.6 adapters would be the TCP/IP stack and since FNET is a full stack that should bridge the gap.
 
@defragster There's a new version of the usb driver available and I want to know if you get the same fbench speeds as before. They should be the same, but I want to see if it slowed down on the T4, so the only change is I found out what an undocumented control command does based on looking through the linux driver. So I already had the command there but I didn't know what it did so the value was just the same as what MacOS set it to, so looking through the linux driver I actually found out that the command is to set the usb buffer queue size of the ASIX. In the new update it's set to the smallest buffer size that it can be ,which is set for 2k buffers and that's the new queue size I'm shooting for. My tests appear to sustain the same 5.3Mbit/sec as before, but now it's using less ram and that should also completely fix the header not found errors, I haven't seen any yet and I know they only appeared when I started trying to queue for a bigger buffer so the 2k should solve that.
 
Pulled both down and reopend fresh IDE after restart.

I get this with notice of IP addr?
Code: 
USB Host InputFunctions example
USB Ready
Mutex initialized: 0
Mutex initialized: 1
TCP/IP stack initialization is done.

SetMACAddress: 0050B6BE8BB4
MulticastJoin: 333300000001
MulticastJoin: 3333FF000000
netif Initialized
Looped: 1  LoopedUSB: 0  FNETMemFree: 48808  LinkSpeed: 10BASE
Looped: 6382926  LoopedUSB: 1680  FNETMemFree: 48808  LinkSpeed: 10BASE
Looped: 7431337  LoopedUSB: 3507  FNETMemFree: 48808  LinkSpeed: 100BASE
Looped: 7431344  LoopedUSB: 3507  FNETMemFree: 48808  LinkSpeed: 100BASE
Looped: 7431679  LoopedUSB: 3486  FNETMemFree: 48808  LinkSpeed: 100BASE
...

fBench not working - wondering if I have a new IP address?
 
It should show you the IP address if the DHCP connected correctly, try unplugging the Teensy and plugging it back in, sometimes after uploading the ASIX needs powered cycled to reset itself.
 
Opps - I had the USB<>LAN on my powered HUB - it backfeeds power when T4 unplugged so was keeping T4 alive even after it was unplugged.

After moving back to direct plug and repowering - the results seem similar to p#129:
Code: 
0.015	10,240	5,459.404
0.034	10,240	2,440.652
0.008	10,240	9,732.337
0.009	10,240	8,906.284
0.007	10,240	11,373.513
0.006	10,240	12,932.967
0.007	10,240	11,284.990
0.007	10,240	11,465.681
0.006	10,240	13,253.090
0.007	10,240	11,336.839

Here is a fresh restart after Upload - then repeat fBench 10*1024B*10::
Code: 
USB Host InputFunctions example
USB Ready
Mutex initialized: 0
Mutex initialized: 1
TCP/IP stack initialization is done.

SetMACAddress: 0050B6BE8BB4
MulticastJoin: 333300000001
MulticastJoin: 3333FF000000
netif Initialized
Looped: 1  LoopedUSB: 0  FNETMemFree: 48808  LinkSpeed: 10BASE
Looped: 6164859  LoopedUSB: 1680  FNETMemFree: 48808  LinkSpeed: 10BASE
Looped: 10621375  LoopedUSB: 3507  FNETMemFree: 48808  LinkSpeed: 10BASE
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.23
SubnetMask: 255.255.255.0
Gateway: 192.168.0.1
DHCPServer: 192.168.0.1
State: 5


Looped: 10343588  LoopedUSB: 3507  FNETMemFree: 48280  LinkSpeed: 100BASE
Looped: 10105520  LoopedUSB: 3486  FNETMemFree: 48280  LinkSpeed: 100BASE
Benchmark results:
Megabytes: 0.10240
Seconds: 0.0120
Bytes/Sec: 853333.3333
KBytes/Sec: 853.3333
KBits/Sec: 6826.6667

Benchmark results:
Megabytes: 0.10240
Seconds: 0.0900
Bytes/Sec: 113777.7778
KBytes/Sec: 113.7778
KBits/Sec: 910.2222

When done it looks to have lost some 500+ bytes from FNETMemFree: 48808?
Code: 
Looped: 10089960  LoopedUSB: 3507  FNETMemFree: 48280  LinkSpeed: 100BASE
Benchmark results:
Megabytes: 0.10240
Seconds: 0.1260
Bytes/Sec: 81269.8413
KBytes/Sec: 81.2698
KBits/Sec: 650.1587

Looped: 10102496  LoopedUSB: 3486  FNETMemFree: 48280  LinkSpeed: 100BASE
 
Yes I put that there so I can see how much memory I need to allocate to FNET, the default was 30k and that kept causing a lockup because not enough was free while doing my large TCP tests. So I increased it to 48k and it hasn't locked up on me yet, but that lets me know how low the memory is so I can tell if I have to increase it anymore.
 
The 500 bytes that is lost is most likely being taken up by the DHCP service, which only gets started when the Ethernet cable is detected as plugged in. So the way FNET works is you allocate a stack of memory that each service then takes from to allocate any variables they need, so they give you a way to tell how much of the memory you allocated is free so while you add new services to your Ethernet application you don't use too much and cause a lockup because you exceeded how much you allocated for the stack.
 
Very good. Wanted to assume it was an initial allocation for something.

Not seeing any hangs or other issues indicated letting it run for hours into days - always responsive and works with the general Ping/fBench tests I've sent.

Saw in the web_doc the LIB has a WRITE test to spit data out to fBench to Receive - is that implemented or easy to do?

Would be interesting to see a typical example - like get timeserver time or something?
 
It would be a little more to setup, but it is possible. Basically it's just the inverse of what fbench is doing now, so the Teensy will be sending the data instead. In order to do this correctly it would have to be done using a serial message, so you don't have to reprogram the Teensy to change message size, repeats, IP address and such, but it's entirely possible.
 
Ok new version on GitHub and it adds the benchmark client which can be started from the serial monitor. The syntax is the same as the one on the demo page they have for fbench:
Code: 
benchtx -a <remote ip> [tcp|udp] [-m <message size>] [-mn <number of messages>]
The only things required are the benchtx and -a <remote ip>, it defaults to TCP, 1272 bytes, 10000 messages. I wasn't able to test TCP myself because I have my fbench running through parallels and it didn't want to start the connection for some reason. However running mine through UDP which has no kind of detection if anyone is listening so it just sends the messages straight out with no regards for anyone I was able to achieve a max of 128Mbit/sec, which may sound ridiculous at first but the speed being measured there is just how fast it's sending over the USB bus. So based on that test we are achieving the full 100Mbit/sec of the usb to ethernet adapter and I couldn't be more happy.
 
trying this (saving here so I don't have to retype) : benchtx -a 192.168.0.22 -m 1024 -mn 10

But on BUILD I get - missing github update to ASIX? ::
Code: 
"T:\\arduino_1.8.10\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=148 -DARDUINO=10810 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_716327/pch" "-IT:\\arduino_1.8.10\\hardware\\teensy\\avr\\cores\\teensy4" "-IT:\\arduino_1.8.10\\hardware\\teensy\\avr\\libraries\\USBHost_t36" "-IT:\\tCode\\libraries\\TeensyASIXEthernet" "-IT:\\tCode\\libraries\\TeensyThreads" "-IT:\\tCode\\libraries\\FNET\\src" "T:\\TEMP\\arduino_build_716327\\sketch\\ASIXEthernet_Test.ino.cpp" -o "T:\\TEMP\\arduino_build_716327\\sketch\\ASIXEthernet_Test.ino.cpp.o"
Functions: In function 'void handleMulticastJoin(fnet_netif_t*, fnet_uint8_t*)':
Functions:298: error: 'class ASIXEthernet' has no member named 'setMulticast'
   asix1.setMulticast((uint8_t*)&mcHashTable);

         ^

Functions: In function 'void handleMulticastLeave(fnet_netif_t*, fnet_uint8_t*)':
Functions:316: error: 'class ASIXEthernet' has no member named 'setMulticast'
   asix1.setMulticast((uint8_t*)&mcHashTable);

         ^

Multiple libraries were found for "USBHost_t36.h"
 Used: T:\arduino_1.8.10\hardware\teensy\avr\libraries\USBHost_t36
Multiple libraries were found for "ASIXEthernet.h"
 Used: T:\tCode\libraries\TeensyASIXEthernet
Multiple libraries were found for "TeensyThreads.h"
 Used: T:\tCode\libraries\TeensyThreads
 Not used: T:\arduino_1.8.10\hardware\teensy\avr\libraries\TeensyThreads
Multiple libraries were found for "fnet.h"
 Used: T:\tCode\libraries\FNET
Using library USBHost_t36 at version 0.1 in folder: T:\arduino_1.8.10\hardware\teensy\avr\libraries\USBHost_t36 
Using library TeensyASIXEthernet in folder: T:\tCode\libraries\TeensyASIXEthernet (legacy)
Using library TeensyThreads at version 1.0 in folder: T:\tCode\libraries\TeensyThreads 
Using library FNET at version 0.1.2 in folder: T:\tCode\libraries\FNET 
'class ASIXEthernet' has no member named 'setMulticast'
 
Now my internet is acting up, you’ll just have to comment those out for now until my internet decides to work.
Lines 298 and 316 in functions.ino
 
Lines commented.

It worked once :
Code: 
3.003	10,240	27.277

Then I get : "Invalid command"

Uploaded again - doesn't seem to like -m of 10240 as a size?
Code: 
Starting benchtx...
Benchmark client failed to start.
Starting benchtx...
Benchmark client failed to start.
Starting benchtx...
Bad parameter: -mn10
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 1024
Num. of messages: 10


Takes some odd coordination to start - ran again … slowly: "4.458 10,240 18.376"
 
Yeah I don't know what the max size is, but it doesn't go as high as fbench does, TCP seems to run dreadfully slow I figured that out in parallels so now I can get that to run. But I guess that's the tradeoff for the reliability that TCP has compared to UDP which doesn't care?
 
Problem was github - first couple of downloads showed 18 minutes old - but would not come down … Got it now and restored those lines in sketch functions

Got a couple to work - last was : benchtx -a 192.168.0.22 -m 4096 -mn 10:
Code: 
2.938	10,240	27.880
1.397	10,240	58.651
1.205	10,240	67.975
1.493	10,240	54.856
0.000	1,024	NA
1.187	10,240	69.002
12.670	40,960	25.864

And Sermon :
Code: 
IPAddress: 192.168.0.23
SubnetMask: 255.255.255.0
Gateway: 192.168.0.1
DHCPServer: 192.168.0.1
State: 5


Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 1024
Num. of messages: 10

Megabytes: 0.010240  Seconds: 0.0840  KBits/Sec: 975.2381
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 1024
Num. of messages: 10

Megabytes: 0.010240  Seconds: 0.0840  KBits/Sec: 975.2381
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 1024
Num. of messages: 10

Megabytes: 0.010240  Seconds: 0.0840  KBits/Sec: 975.2381
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 1024
Num. of messages: 10

Megabytes: 0.010240  Seconds: 0.0840  KBits/Sec: 975.2381
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 1024
Num. of messages: 1

Megabytes: 0.001024  Seconds: 0.0000  KBits/Sec: inf
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 1024
Num. of messages: 10

Megabytes: 0.010240  Seconds: 0.0840  KBits/Sec: 975.2381
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 4096
Num. of messages: 10

Megabytes: 0.040960  Seconds: 11.6640  KBits/Sec: 28.0933
 
And for :: benchtx -a 192.168.0.22 -m 8092 -mn 10

fBench:: 14.596 80,920 44.352

Sermon:
Code: 
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8092
Num. of messages: 10

Megabytes: 0.080920  Seconds: 12.0780  KBits/Sec: 53.5983
 
I wonder what's making TCP so much slower than UDP, I wouldn't think the little latency from confirming the messages are received would add up to that much of a difference.
 
That is a big diff!

Original fBench Send test still works - much faster:
9.509 12,720,000 10,701.754
0.027 102,400 30,575.835
0.029 102,400 28,223.556
Click to expand...

And SerMon:
Code: 
Megabytes: 12.720000  Seconds: 9.5640  KBits/Sec: 10639.8996
Megabytes: 0.102400  Seconds: 0.0780  KBits/Sec: 10502.5641
Megabytes: 0.102400  Seconds: 0.1200  KBits/Sec: 6826.6667
 
About Double?

for benchtx -a 192.168.0.22 -m 8092 -mn 2 ( two @ -mn 2 then one @ -mn20 ):
Code: 
2.205	16,184	58.711
2.274	16,184	56.935
12.126	161,840	106.774

SerMon:
Code: 
Megabytes: 0.016184  Seconds: 1.2000  KBits/Sec: 107.8933
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8092
Num. of messages: 2

Megabytes: 0.016184  Seconds: 1.3140  KBits/Sec: 98.5327
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8092
Num. of messages: 20

Megabytes: 0.161840  Seconds: 10.6320  KBits/Sec: 121.7758

And two smaller 512 B : benchtx -a 192.168.0.22 -m 512 -mn 2 ::
Code: 
0.040	1,024	203.841
0.040	1,024	202.859

SerMon ('inf' is a bit of an overstatement perhaps):
Code: 
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 512
Num. of messages: 2

Megabytes: 0.001024  Seconds: 0.0000  KBits/Sec: inf
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 512
Num. of messages: 2

Megabytes: 0.001024  Seconds: 0.0000  KBits/Sec: inf
 
You must log in or register to reply here.
Back
Top