USB Host Ethernet Driver

@All - I have been testing the ASIX driver with MSC this weekend and they are not playing nice together. There is a conflict between the two when disk writes are performed. Disk reads are ok except when enabling TeensyThreads then the disk reads slow way down. If I use the StarTech USB2SATA adapter then when a disk write is done the the green and yellow lights on the ASIX turn off and the T4 locks up. I think the problem might be who's claiming who possibly. Disk writes to thumb drives or USB SD card reader are ok if not enabling TeensyThreads. If I plug in he StarTech USB2SATA adapter without it being attached to a hard drive then the joystick controller claims it and shows 'jtype = 0'.
Code:
Device Descriptor:
  12 01 00 02 00 00 00 40 2D 15 38 23 00 01 01 02 05 01 

    Class/Subclass/Protocol = 0 / 0 / 0
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: JMicron
enumeration:
Product: USB to ATA/ATAPI Bridge
enumeration:
Serial Number: 152D203380B6
enumeration:
Config data length = 32
enumeration:
Configuration Descriptor:
  09 02 20 00 01 01 04 C0 01 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 02 08 06 50 06 
    Interface = 0
    Number of endpoints = 2
    Class/Subclass/Protocol = 8(Mass Storage) / 6(SCSI) / 80(Bulk Only)
  07 05 81 02 00 02 00 
    Endpoint = 1 IN
    Type = Bulk
    Max Size = 512
    Polling Interval = 0
  07 05 02 02 00 02 00 
    Endpoint = 2 OUT
    Type = Bulk
    Max Size = 512
    Polling Interval = 0
enumeration:
JoystickController claim this=200123E0
KeyboardController claim this=20012900
HIDParser claim this=20013340
HIDParser claim this=20012BA0
USBHub memory usage = 960
USBHub claim_device this=20014820
USBHub memory usage = 960
USBHub claim_device this=20014BE0
USBHub memory usage = 960
USBHub claim_device this=200140A0
msController claim this=20027A80
msController claim this=20027E00
msController claim this=20028180
Descriptor 4 = INTERFACE
JoystickController claim this=200123E0
09 04 00 00 02 08 06 50 06 07 05 81 02 00 02 00 07 05 02 02 00 02 00 
jtype=0
KeyboardController claim this=20012900
HIDParser claim this=20013340
HIDParser claim this=20012BA0
msController claim this=20027A80
09 04 00 00 02 08 06 50 06 07 05 81 02 00 02 00 07 05 02 02 00 02 00 
numendpoint=2
endpointIn=81
endpointOut=2
packet size in (msController) = 512
packet size out (msController) = 512
polling intervalIn = 0
polling intervalOut = 0
new_Pipe
new_Pipe
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT

I think I need to refine the way MSC is claming devices.
 
Are you calling read and write functions from the main thread or the usb thread? If you are calling it from the main thread then that could be an issue if the USBHost library/driver is not thread safe.
 
Are you calling read and write functions from the main thread or the usb thread? If you are calling it from the main thread then that could be an issue if the USBHost library/driver is not thread safe.

I am using the disk reads and writes through uSDFS to MSC's disk read and write functions. I am only initializing ASIX driver using the init routine in the setup section of 'ASIXEthernet_test.ino'.
I can ping the T4 with my laptop and it works right. If I comment out this line:
Code:
//  threads.addThread(usbthread);
Then I can read and write to to thumb drives but not to the StarTech USB2SATA hard drive adapter.
I am not sure if this is proper way to disable TeensyTreads call to the usbthread() callback. And of course pingging the T4 won't work. I was hoping to polling when using the ASIX adapter.
I now very little about TeensyThreads:)
 
Do you mind sharing the code you're working with?

Not at all. I will have to put it into a zip file as this is to big to post all of the code.

The whole operating system is several MB's of code so I will have post what I think is relavent to this issue.
Basically it the IO system, a structured basic interpreter, my modified version of the KILO editor that is available on line and my file manager all of which use uSDFS and MSC.

I will post it when it's ready.

EDIT: Changed my mind. I think it's better if I write a sketch that just uses your ASIX library, uSDFS and MSC libraries to test with.
Then I will post the code with the results. This will eliminate all of the other code and narrow it down to the issues at hand.
 
Last edited:
Sounds reasonable, right now I'm working on making sure FNET is thread safe. The way it's configured now is fine for multi-thread as long as it's only called by one thread, true multi-thread will work across multiple threads simultaneously which may or may not be useful to some but at least it will be there for those who find it useful.
 
Sounds reasonable, right now I'm working on making sure FNET is thread safe. The way it's configured now is fine for multi-thread as long as it's only called by one thread, true multi-thread will work across multiple threads simultaneously which may or may not be useful to some but at least it will be there for those who find it useful.

And those of us that have absolutely no idea how to deal with threads:)

I have a test base started with just the ASIC controller, USDFS and MSC. So far no lockups at all which is good news but using a USB2SATA adapter is problematic. I guess it's not something to pursue even though it is faster than thumb drives. Probably SD cards, SSD drives and thumb drives are more practical. There are other options as @defragster and @KurtE have suggested in the past. I am almost done with the sketch and will post it with explanation when ready to submit.

Gotta get ready for work tomorrow.
 
Alright a couple changes have been added so multithreading should now be properly supported and I fixed DHCP in the example sketch so now you can hot plug the USB and/or ethernet cable at any time. I also fixed the transfer queue because messages were getting lost when it would try to send multiple at once.
 
Cool progress.

Using TeensyThreads to check for thread safe and stable when code interrupted is good.

@wwatson - you could post example with MSC and FNET/ASIX in :: github.com/wwatson4506/MSC/ ?

@vjm - installed both new libs and it seems to be building okay but get this in console:
Code:
Invalid version '4.6.3.2' for library in: T:\tCode\libraries\FNET
Invalid version '4.6.3.2' for library in: T:\tCode\libraries\FNET

And still this line earlier:
Code:
Error while detecting libraries included by T:\tCode\libraries\FNET\src\service\serial\fnet_serial.c
 
Alright I've made a compromise on the version number and a possible fix for the serial error, I haven't seen the serial error myself so I can't tell you if it actually did anything or not.
 
Okay it is working now - will look for update change later.

Noted in p#60 - running the recent code update.

Not seeing loss in a couple hundred - including the FIRST after Upload.

Ran twin 1,000 count PINGS :
> one of 1465 bytes - NO LOSS
> one of 465 bytes - Loss of 1 of 1000
 
Looks pretty good, I want to get some kind of speed going to see if all the effort was worth it or not.
 
Looks pretty good, I want to get some kind of speed going to see if all the effort was worth it or not.

a 'Speed Test' going?

I saw the err fix update - the lib ver warning is gone - but the serial note way up is there?

Also odd? I've not seen this before?
Code:
Using board 'teensy40' from platform in folder: T:\arduino_1.8.10\hardware\teensy\avr
Using core 'teensy4' from platform in folder: T:\arduino_1.8.10\hardware\teensy\avr
Detecting libraries used...
"T:\\arduino_1.8.10\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -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:\\arduino_1.8.10\\hardware\\teensy\\avr\\cores\\teensy4" "T:\\TEMP\\arduino_build_882125\\sketch\\ASIXEthernet_Test.ino.cpp" -o nul
[B]Alternatives for USBHost_t36.h: [USBHost_t36@0.1]
ResolveLibrary(USBHost_t36.h)
  -> candidates: [USBHost_t36@0.1]
[/B]"T:\\arduino_1.8.10\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -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:\\arduino_1.8.10\\hardware\\teensy\\avr\\cores\\teensy4" "-IT:\\arduino_1.8.10\\hardware\\teensy\\avr\\libraries\\USBHost_t36" "T:\\TEMP\\arduino_build_882125\\sketch\\ASIXEthernet_Test.ino.cpp" -o nul
[B]Alternatives for ASIXEthernet.h: [TeensyASIXEthernet]
ResolveLibrary(ASIXEthernet.h)
  -> candidates: [TeensyASIXEthernet]
[/B]"T:\\arduino_1.8.10\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -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:\\arduino_1.8.10\\hardware\\teensy\\avr\\cores\\teensy4" "-IT:\\arduino_1.8.10\\hardware\\teensy\\avr\\libraries\\USBHost_t36" "-IT:\\tCode\\libraries\\TeensyASIXEthernet" "T:\\TEMP\\arduino_build_882125\\sketch\\ASIXEthernet_Test.ino.cpp" -o nul
[B]Alternatives for TeensyThreads.h: [TeensyThreads@1.0 TeensyThreads@1.0]
ResolveLibrary(TeensyThreads.h)
  -> candidates: [TeensyThreads@1.0 TeensyThreads@1.0]
[/B]"T:\\arduino_1.8.10\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -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:\\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" "T:\\TEMP\\arduino_build_882125\\sketch\\ASIXEthernet_Test.ino.cpp" -o nul
[B]Alternatives for fnet.h: [FNET@0.1.2]
ResolveLibrary(fnet.h)
  -> candidates: [FNET@0.1.2][/B]


@PaulStoffregen - if you see this:: the IDE is 1.8.10 - and the ABOVE 'conflicts' is new and odd? Also noted elsewhere but here one lib TeensyThreads is indeed a local copy versus the included TD_1.48.b1. But the other local libraries are NEW and not sure why it is noting 'Multiple libraries' where no 2nd item is noted?
Code:
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

Also of NOTE is that each Upload seems to REBUILD a lot of extra stuff? Maybe because of the questionable "ResolveLibrary"'s ?
 
Not sure about rebuilding a lot of stuff, I haven't had anything rebuild unless I change something in one of the files I'm working on, maybe it has to do with the conflicting libraries thing?

Versions I'm using is Teensyduino 1.47 and Arduino 1.8.9 just for reference.
 
Not sure about rebuilding a lot of stuff, I haven't had anything rebuild unless I change something in one of the files I'm working on, maybe it has to do with the conflicting libraries thing?

Versions I'm using is Teensyduino 1.47 and Arduino 1.8.9 just for reference.

I think that explains it - good note to have as I posted link to p#64 notes on the 1.48.b1 thread :: my system is IDE 1.8.10 and the needed TD 1.48.b1. There is something new to IDE 1.8.10 I'm guessing.
> catching the Serial error
> Rebuilding too much
> seeing need to ResolveLibrary
> Oddly triggering 'Multiple libraries' detection Paul added to the IDE.
 
Alright benchmark was successfully added and uses the fbench.exe that was designed for fnet located in the extras folder. Let me know what your guys' results are, mine are less than stellar, but I believe that's due to how I'm running the software.

So the settings you want to use for fbench are TCP, IPv4 Sending, and whatever the IPAddress is that DHCP assigns your Teensy. Message size and number of messages can be whatever you want to test or you can try to leave it at default, I wasn't able to because I have a bottleneck somewhere so 10000 messages wasn't viable for me.

Edit: I think I found a way to increase throughput, so I'm testing it now
 
Last edited:
Updated FNET/ASIX from github.

Still only the single example?

… > don't forget to CLOSE IDE when running Library example code that changes ...
 
I'm not sure, mine connects fine. Try unplugging and replugging the cable while it's already on, that resets the DHCP request.
 
I had a PING of 465 bytes running.

I got this from FBench for 10K messages:
0:2:11.262 Tx Tcp 192.168.0.23 47.913 12,720,000 2,123.869

// Closed PING after stating this run
0:4:43.261 Tx Tcp 192.168.0.23 86.506 25,440,000 2,352.680

FNET_2019-09-30 113539.png

Code:
Benchmark results:
Megabytes: 12
Bytes: 720000
Seconds: 48.0540
Bytes/Sec: 14983.1440
KBytes/Sec: 14.9831

Benchmark results:
Megabytes: 25
Bytes: 440000
Seconds: 86.6400
Bytes/Sec: 5078.4857
KBytes/Sec: 5.0785
 
Was rushing to eat earlier … it is working reliably - except the SerMon values reported come up short - where fBench says 1.4 to 4.1 MB/sec.

Here is a batch of 1,000 msgs at 1024 bytes fBench shows ( secs … bytes … Kb/sec )::
Code:
5.284	2,000,000	3,027.833
3.236	1,024,000	2,531.241
2.752	1,024,000	2,977.083
4.827	1,024,000	1,697.257
2.240	1,024,000	3,656.568
4.357	1,024,000	1,880.299
3.729	1,024,000	2,196.863
2.106	1,024,000	3,888.958
3.711	1,024,000	2,207.542
2.551	1,024,000	3,211.867
3.161	1,024,000	2,591.855
[B][U]13.285[/U]	1,024,000	616.649
[U]2.749[/U]	1,024,000	2,979.512[/B]

Here are the last two of those from SerMon with the times close- note the LoopedUSB number is unchanged:
Code:
Benchmark results:
Megabytes: 1
Bytes: 24000
Seconds: [U]13.4340[/U]
Bytes/Sec: 1786.5118
KBytes/Sec: 1.7865

Looped: 194538141	 LoopedUSB: 3486
Looped: 192963903	 LoopedUSB: 3507
Looped: 193601608	 LoopedUSB: 3507
Benchmark results:
Megabytes: 1
Bytes: 24000
Seconds: [U]2.9340[/U]
Bytes/Sec: 8179.9591
KBytes/Sec: 8.1800

Also Good to note: running two PING ( 1465 and 465 bytes ) at the same time suffer minimal 4% loss on the larger and 2% on the smaller - and the fBench reported throughout is still looking good - except the one:
Code:
3.827	1,024,000	2,140.770
7.773	1,024,000	1,053.946
2.012	1,024,000	4,071.463
3.224	1,024,000	2,540.961
[B]22.984	1,024,000	356.420[/B]
5.594	1,024,000	1,464.405
4.498	1,024,000	1,821.446
3.123	1,024,000	2,623.050
2.034	1,024,000	4,026.955
2.251	1,024,000	3,638.765

And long term after some repeated runs of this - the T4 is stable on Ethernet without restart or problem - it just keeps running!
 
Back
Top