USB Host Ethernet Driver

Good LAN switches will direct traffic only to the right port that it needs to to increase performance so it could be a possibility, I know FNET does advertise to switches to tell it it’s there’s. Luckily I know my router doesn’t do that so all traffic is being sent to my wireshark.
 
vjmuzik said:
Good LAN switches will direct traffic only to the right port that it needs to to increase performance so it could be a possibility, I know FNET does advertise to switches to tell it it’s there’s. Luckily I know my router doesn’t do that so all traffic is being sent to my wireshark.
Click to expand...

Indeed - stopped WShark monitoring as it was not seeing the incoming message - but see another 24 sets of this triggering with no intended activity - the Router does ping this machine:
Message Recieve Error, searching for next header
Error: No new header found
Click to expand...

vjmuzik said:
Yeah the value seems inconsistent at best, I’ve hit around the same number a couple of times but it’s definitely an anomaly. Most of my tests come back ranging from 5-10Mbit/sec so it’s still an improvement over a w5500, but not quite as much as I was hoping for.
Click to expand...

What speed does the w5500 give? Nice that it exceeds that already - and seems to be low impact on Teensy … based on loop counts at least.
 
I believe Paul said 1-2 Mbits max over SPI, and I know I was running into problems before with TCP speeds slowing everything down for the program I was trying to run. So I believe even though the benchmark isn’t showing the speeds that I would like it to that we are most likely achieving full transfer speeds, but with the overhead of usb it’s causing the time to get skewed so the reported speed is lower. I can safely say that running at the current speed it does that my previous TCP program would have no problems because on the w5500 it was struggling with roughly a couple transfers of 2000 bytes a second for screen buffers because of the SPI speeds. So even hypothetically if we were getting 1-2 Mbits/sec on our speed test it would still be faster because the usb transfer speeds are just so much higher than SPI.
 
Ick - never tried one of those adapters - that isn't very high throughput - especially when 2K bytes causes the MCU to struggle.

Wow - fBench shows 102,400 bytes as :: 0.027 sec 102,400 Bytes 30,390.153 Kbits/sec


Here 10K bytes is 10 ms as measured by fBench { 10 msg of 1024 bytes repeat 10 times } ::
Code: 
0.017	10,240	4,831.613
0.011	10,240	7,467.163
0.007	10,240	11,743.793
0.007	10,240	11,748.845
0.007	10,240	11,724.296
0.007	10,240	11,685.663
0.010	10,240	7,882.683
0.008	10,240	10,267.980
0.009	10,240	9,126.458
0.006	10,240	13,690.068

And the last 5 from SerMon - 10K Bytes is ~120 ms:
Code: 
Benchmark results:
Megabytes: 0.10240
Seconds: 0.1080
Bytes/Sec: 94814.8148
KBytes/Sec: 94.8148
KBits/Sec: 758.5185

Benchmark results:
Megabytes: 0.10240
Seconds: 0.1260
Bytes/Sec: 81269.8413
KBytes/Sec: 81.2698
KBits/Sec: 650.1587

Benchmark results:
Megabytes: 0.10240
Seconds: 0.1080
Bytes/Sec: 94814.8148
KBytes/Sec: 94.8148
KBits/Sec: 758.5185

Benchmark results:
Megabytes: 0.10240
Seconds: 0.1140
Bytes/Sec: 89824.5614
KBytes/Sec: 89.8246
KBits/Sec: 718.5965

Benchmark results:
Megabytes: 0.10240
Seconds: 0.1080
Bytes/Sec: 94814.8148
KBytes/Sec: 94.8148
KBits/Sec: 758.5185
 
I wish I could speed it up more, but as it is I’m out of ideas on what could make it be faster.
 
vjmuzik said:
I wish I could speed it up more, but as it is I’m out of ideas on what could make it be faster.
Click to expand...

That isn't slow already - compared to the SPI alternative. So getting it working and stable with any missing features is best path. Nice it is low overhead and hopefully 'deterministic' where it is efficient and done without hanging for parts of a ms here or there.

... fired up a HDD and remind myself of the speed for that …

HDD writes look to be faster than the LAN's 10 - 30 Kbits/sec - but the lag for the I/O goes up dramatically:
8.139112 MB/s
(open: 17995 us; close: 26000 us; write: min,max: 3964 3972 us)
Click to expand...
 
Last edited:
It’s at least more than sufficient for my purpose so I’ll count this as a success. One more bug I have to find is it’s still hanging after sending a lot of TCP tests and I don’t think it has to do with the error messages like last time since that should be handled. I’ll just have to start placing debug messages everywhere again and see what’s triggered.
 
I’ll have to compare my driver code and see if something could be done there, I don’t think the FNET stack is slowing it down at least from what it looks like in their demo code it seems to at least be able to hit 47Mbit/sec with the native Ethernet. It’s either that or copying back and forth between buffers that could be slowing something down, maybe I can get rid of a buffer or two so there doesn’t need to be send and receive buffers in the Arduino code and just the usb buffers.
 
So that integration of the ASIX and FNET code gives full Ethernet capability - as noted on github diagram? I didn't look beyond sketch as usual - just popping in to run the example.

>> I did try malloc/new/DMAMEM alloc of the rx and tx buffer - and it failed to start :( Put those buffer[]'s as a public pointer in the 'class ASIXEthernet : public USBDriver' and set then assigned in setup() - it worked when I did a global sketch alloc of the "?x_buffer[512*bufSize]" and assigned to the pointer - but not when it came from the upper memory block with 2nd 32KB cache? Not sure if there is something funny in how it is used? Don't see it doing DMA which would break it.

Are there other samples out there using that "ASIX and FNET" LAN combo? Following your github links I see manual and info:
fnet.sourceforge.net/manual/index.html


Still seeing the "Message Recieve Error, searching for next header Error: No new header found"
Is that just the response for an unhandled query?
 
It’s just used to used to catch error messages, I wouldn’t worry about it if it doesn’t find a new header. It just means no information is being lost. As far as other samples, I don’t think anyone else has tried usb Ethernet with a microcontroller period, I remember looking for examples to see if it could be done and I don’t believe I found any. There’s nothing funny going on as far as I know with the buffers, I haven’t done anything special with them.
 
So as far as I can tell there shouldn't be a limit to the amount of data that you are able to queue, however there seems to be some kind of fault in the ehci.cpp code. Reason why I say this is because while looking through the queue_Data_Transfer function I can see that messages larger than 16384 are supposed to get split up into multiple messages, but being that the limit that I can queue seems to only work up to 16384 and breaks precisely at 16385 I'm inclined to say it's bugged. Sometimes messages that come through over that limit are read correctly, but more often than not it gets slammed with dummy data that just constantly gives me errors because it's not real data.
 
Alright I've pushed new versions to GitHub, it seems pretty stable and I've minimized one cause of the errors that would happen sometimes, they are still there but should be overall less so I commented out the print lines for it. So my tests seem to be averaging around 5.3Mbit/sec pretty much every time so I'm going to say that's what my speed is maxing at out more or less. I'm not sure about the lockup bug that I experience, it seems like fbench screws up if you send a bunch of tiny messages, but a bunch of large ones are fine. Basically what seems to happen is the small messages are sent too fast so fbench doesn't catch the message that the TCP buffer is full and it's most likely overflowing into something it shouldn't, so it crashes.
 
As far as those messages - just mysterious noise - I didn't look at the source and determination to spit them out. Just wondered what happens if those things happen during transfers and could be recognized reported better. They must be 'valid' "pings" of some sort - would be nice to have enough info to add code to handle them into either silence or function.

Odd diff in fBench message size 10240 versus 20480 does quadruple - not double the time - and so double the throughput:
Code: 
TIME 	BYTES  	Kbits/sec
0.097	204,800	16,871.624
0.096	204,800	17,015.797
0.023	102,400	35,711.328
0.025	102,400	32,496.073

VERY cool to have working ethernet - that code base suggests WiFi supported as well - not sure what adapter that is and if it can go there too?

EDIT>> I see we CrossPosted
I've not triggered a lockup yet? Wonder if the T4 speed circumvents that? Maybe the T_3.6 needs more than '#=20' in the loop Hack?

ALSO - Maybe those 'removed err messages' could be under 'DEBUG_ME' or something so there is a way to trace back to unhandled or erroneous messages?
 
Last edited:
No I tried increasing the loop count and determined it didn’t change anything and yes if someone can get a driver going for a WiFi adapter it can easily be used with FNET as well. That’s why I added it as it’s own library so it could be used independently from my usb driver.
 
It’s probably just the latency in my network making fbench see the message to stop sending too late.
 
Also it does search through the error message to see if there is any hidden message located within, but they are all coming up as 0’s now so I didn’t find it imperative to notify anymore. I literally mean 1000’s of bytes of zeros and nothing else.
 
vjmuzik said:
Also it does search through the error message to see if there is any hidden message located within, but they are all coming up as 0’s now so I didn’t find it imperative to notify anymore. I literally mean 1000’s of bytes of zeros and nothing else.
Click to expand...

That is weird! I wonder if there is something on my network spewing kraap? Maybe I have a cheaper switch that won't isolate the PC from the Teensy and I can see the broadcast messages?

I have seen fBench on occasion show one of th ecolumns as incomplete as if it didn't get/like the response - but the benchmark code dropped a note and there was no error and re-running was fine
 
I know it’s not on the network side that’s sending out messages with nothing but zeros because the ASIX would filter them out if it was so something fishy is going on with the usb code. Maybe there’s noise or something that it’s mistaking for data? I know that my Mac queues the ASIX for 24,576 bytes of data so it’s safe to say it should work up to that and I didn’t see any messy data like what I’m seeing on the Teensy happen on my Mac. Maybe there’s a typo somewhere in the USB host code that hasn’t been caught yet because we haven’t ever needed to queue this much data before?
 
Ahm,

not sure if this is a stupid question....how do i connect this USB2Ethernet adapter to a Teensy? Just plug it into the USB connector of it?

Thank you

Torsten
 
If you have a Teensy 3.6 you’ll need something like this: https://www.amazon.com/dp/B000IV6S9S/ref=cm_sw_r_cp_api_i_59rLDbN4DFT1G

Or you can cut up a cable if you have one like it and make one yourself and it connects to the inner pins on the T3.6 labeled USB Host port. If you have the T4.0 it’s best to use an adapter board to hook it because you need some external circuitry to fully support it correctly, but the T3.6 has the circuitry built in already.
 
@vjmuzik - Teensy sitting ignored since last post and SerMon shows this - twice between the repeating other lines. I've seen it before - does it mean something is restarting that it posts the IP address again?
Code: 
Message Recieve Error, searching for next header
Error: No new header found
[B][U]IPAddress: 192.168.0.23
SubnetMask: 255.255.255.0
Gateway: 192.168.0.1
DHCPServer: 192.168.0.1
State: 5
[/U][/B]

Message Recieve Error, searching for next header
Error: No new header found
 
No nothing is restarting, occasionally your router will request some kind of update to the DHCP and the callback is setup to be called anytime there is an update to the DHCP and not just a new IP address, typical updates include checking the lease time to tell your router you still want the IP address so it updates with a new lease time and the callback is called.
 
vjmuzik said:
No nothing is restarting, occasionally your router will request some kind of update to the DHCP and the callback is setup to be called anytime there is an update to the DHCP and not just a new IP address, typical updates include checking the lease time to tell your router you still want the IP address so it updates with a new lease time and the callback is called.
Click to expand...

Very good - makes sense. It keeps working - that is just the only long run thing I've seen reported.

Was it your note about the T_3.6 Beta hardware with the PJRC Ethernet shield working? I have one of those -what would it take to switch from USB to the MCU pins to run this test?
 
Yes the original FNET library supports the k66 and several other processors, I don’t have one myself to test if anything has to be changed to work with Arduino, but my version on GitHub has all the processors deleted. The processors were located in the port folder of the original library, some config options would need to be changed to tell it to compile for the processor and for the right Ethernet interface, but it should be compatible.
 
You must log in or register to reply here.
Back
Top