USBHost_t36 USB Mass Storage Driver Experiments

@WMXZ
Think I have the basic MSC structure setup in Github now. Need to add a readme and then learn how to use the repository properly. Lots of info available on the web.
Any advice to a novice Github user from you guys is very welcomed.

@Kurte
I saw your PR and merged it. This max LUN thing really has me bugged. I know it is not right. In the usbmassbulk10.pdf page 7 section 3.2 it shows this command.
bmRequestType bRequest wValue wIndex wLength Data
10100001b 11111110b 0000h Interface 0001h 1 byte

I have wLength set to 0000h and it always returns 0 in report[0]. If I set wLength to 1 as stated in the manual, I get this followup error.
Code:
control CallbackIn (msController)
00 00 00 00 00 00 00 00 
ERROR Followup
    remove from followup list
    remove from followup list
  qtd: B0C0, token=7083788B, next=7003780B

The manual also states that
Devices that do not support multiple LUNs may STALL this command.
At this point I am trying to figure out how to detect a pipe stall with USBHost_t36.
Other information I have seen states that the Get Max LUN command can cause flakey results.

LUN's are numbered from 0 to 15 so setting LUN in the Command Block Wrapper to 0 is always working.

Not working this weekend. Hope to have time to work with this.
 
Just posted this on another thread {I see WMXZ found it too} - testing with a T_3.6 at 256MHZ - this code works there and I see the same speeds as on T$ for USB writes to my HDD:

Here is the timing writing 1,000 blocks of 64 KB:
Code:
(6329964 - 10.353297 MB/s)
 (open: 164960 us; close: 44999 us; write: min,max: 5705 11741 us)

I think that says 6.329 seconds for the group with block write max/min details.

Dropping to 32KB RAM buffer to write results in:
Code:
(5363964 - 6.108915 MB/s)
 (open: 29964 us; close: 17999 us; write: min,max: 4833 17869 us)

Open/Close and Min/Max values not ideal with re-running same test on the ROOT directory and FAT maintenance probably factoring in.
 
OT - but it seems this group is Windows and could be using Compile.cmd from editor? And maybe TyCommander.

For T$ post on 15s Restore image I took TyCommander out of IDE to use TeensyLoader.

Then I went back to SublimeText and Frank_B Compile.cmd/TSet and with the build platform change it brought up TeensyLoader, and it works with Button press!

Still using TyComm for SerMon and IDE closed - but it is good to know the Arduino Build process without TyComm - and button press auto disconnects TyComm to complete upload and then reconnects.

T$ starts into setup() in 300 ms and TyComm Serial online in about 400 ms!

In fact with UART power on T$ pins - the USB is often able to be online in under 340 ms.
 
@Kurte
I saw your PR and merged it. This max LUN thing really has me bugged. I know it is not right. In the usbmassbulk10.pdf page 7 section 3.2 it shows this command.


I have wLength set to 0000h and it always returns 0 in report[0]. If I set wLength to 1 as stated in the manual, I get this followup error.
Code:
control CallbackIn (msController)
00 00 00 00 00 00 00 00 
ERROR Followup
    remove from followup list
    remove from followup list
  qtd: B0C0, token=7083788B, next=7003780B

The manual also states that
At this point I am trying to figure out how to detect a pipe stall with USBHost_t36.
Other information I have seen states that the Get Max LUN command can cause flakey results.

LUN's are numbered from 0 to 15 so setting LUN in the Command Block Wrapper to 0 is always working.

Not working this weekend. Hope to have time to work with this.

You will sometimes get errors like this, if you do output a request and don't wait for the response and issue a new request. The hack I put in was to wait for the response to come back, at which time you have your actual data and then return the value.

With other device classes we had sort of state machines that we would issue request and then return and when we received the response, we would then process it... But setting the flag and waiting is not bad here as we are not processing the data in interrupt.

Will try to play around some more with some of this stuff soon. Still recovering.
 
@wwatson - put in PR for fix to msInquiry, where the length of data to return was 0 in parameter list. Changed it to actual size...

This appears to fix one of my SD Cards failing issue.
 
@mjs513 - Thanks - still only able to do a little...

But thought I would try a few things... Wondered if these libraries could handle USB plug in CDROM/DVD drives... So plugged one in ;)
I have a memorex ... which when I plug it in cycles between trying to connect and disconnect...

Code:
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 00 00 00 40 18 07 06 40 19 01 01 02 03 01 
    VendorID = 0718, ProductID = 4006, Version = 0119
    Class/Subclass/Protocol = 0 / 0 / 0
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: Memorex
enumeration:
Product: MRX-650LE v4
enumeration:
Serial Number: 20130410023B
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 05 
    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:
msController claim this=20002B40
Descriptor 4 = INTERFACE
msController claim this=20002B40
09 04 00 00 02 08 06 50 05 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
port change: 1C00100A
    disconnect
disconnect_Device:
USBDriver (available_drivers) list: (empty
USBDriver (dev->drivers) list: 20002B40
disconnect driver 20002B40
Device Disconnected...
USBDriver (available_drivers) list: 20002B40
delete_Pipe 20002C20
  remove QH from async schedule
  Free transfers
  Free transfers attached to QH
    * 536884544
* Delete Pipe completed
delete_Pipe 20002BC0
  remove QH from async schedule
  Free transfers
  Free transfers attached to QH
    * 536884352
* Delete Pipe completed
delete_Pipe 20003400
  shut down async schedule
  Free transfers
  Free transfers attached to QH
    * 536884416
* Delete Pipe completed
removed Device_t from devlist
  disable
port change: 10001803
    connect
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 00 00 00 40 18 07 06 40 19 01 01 02 03 01 
    VendorID = 0718, ProductID = 4006, Version = 0119
    Class/Subclass/Protocol = 0 / 0 / 0

The Mac one appears to get farther, although it does not have any media in it...
Code:
USB2 PLL running
 reset waited 6
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 20003000
periodictable = 20003000
port change: 10001803
    connect
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 00 00 00 40 AC 05 00 15 02 02 01 02 03 01 
    VendorID = 05AC, ProductID = 1500, Version = 0202
    Class/Subclass/Protocol = 0 / 0 / 0
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: Apple Inc.
enumeration:
Product: MacBook Air SuperDrive
enumeration:
Serial Number: KQVD5MK2810         
enumeration:
Config data length = 32
enumeration:
Configuration Descriptor:
  09 02 20 00 01 01 04 A0 FA 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 02 08 06 50 00 
    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:
msController claim this=20002B40
Descriptor 4 = INTERFACE
msController claim this=20002B40
09 04 00 00 02 08 06 50 00 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
control CallbackIn (msController)
00 00 00 00 00 00 00 00 
control CallbackIn (msController)
00 00 00 00 00 00 00 00 
msController CallbackOut (static)
transfer->qtd.token = 0
msController dataOut (static)31
55 53 42 43 02 00 00 00 00 00 00 00 80 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 13
55 53 42 53 02 00 00 00 00 00 00 00 01 
** CSWSIGNATURE
Disk initialize Status: 2
msController CallbackOut (static)
transfer->qtd.token = 0
msController dataOut (static)31
55 53 42 43 03 00 00 00 00 00 00 00 80 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 13
55 53 42 53 03 00 00 00 00 00 00 00 01 
** CSWSIGNATURE
msController CallbackOut (static)
transfer->qtd.token = 0
msController dataOut (static)31
55 53 42 43 04 00 00 00 00 02 00 00 80 00 0A 28 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 512
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
** ????
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 13
55 53 42 53 04 00 00 00 00 02 00 00 01 
** CSWSIGNATURE
Disk read Result: 6
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Master Boot Record
  Partition: 0 first Sector: 0 total Sectors: 0
  Partition: 1 first Sector: 0 total Sectors: 0
  Partition: 2 first Sector: 0 total Sectors: 0
  Partition: 3 first Sector: 0 total Sectors: 0
Also don't know how to get the MAC one to accept a disk...
 
@defragster et al

I didn't get the right oricon adapter like you said, but I did get the drive with the 128MB cache, https://www.amazon.com/gp/product/B01LYNQXCP/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1, 1 TB version of the one you got. Results not that impressive
Code:
Test logger_RawWrite
uSDFS_VER:15_MAY_19_08_16
BUFFSIZE :24576
Dev Type :2:/
## mscInit before msgGetMaxLun: 1
## mscInit after msgGetMaxLun: 0
File System FS_EXFAT
Free Disk Size -1 clusters
Cluster Size 512 sectors
Sector Size 512 bytes

Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

 (30996 - 6.343012 MB/s)
 (open: 15039 us; close: 15000 us; write: min,max: 7934 7938 us)

unmount FR_OK
Also could only write 24x1024 buffers other wise it would give me the a write error. And it stops after the first file. No loop so it has to be hanging somewhere This is with @wwatson's latest changes to his library.
 
@defragster et al

I didn't get the right oricon adapter like you said, but I did get the drive with the 128MB cache, https://www.amazon.com/gp/product/B01LYNQXCP/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1, 1 TB version of the one you got. Results not that impressive
Code:
Test logger_RawWrite
… BUFFSIZE :24576
... (30996 - 6.343012 MB/s)
...
Also could only write 24x1024 buffers other wise it would give me the a write error. This is with @wwatson's latest changes to his library.

Bummer - that is not impressive - hopefully mine will somehow be magically better and fully supported … With SSD's larger allows more parallel activity - maybe with HDD smaller will be better :)

I wonder if it is the adapter logic ? Can you try your SSD in that to compare?

With 5400 RPM drive not doing file sys updates to FAT and dir entries will help the cache fill and stream to disk . . . without interrupting to add clusters to FAT chain - and dir entry file size. I suppose that goes with the pre-allocated file use on SD's?

Odd the BUFFSIZE was finicky? I tried a few from 8 to 30 and they all worked IIRC?
 
@defragster
Just did that with the SSD. With the 500Gb SSD I get, with 24,
Code:
Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

 (35996 - 5.461940 MB/s)
 (open: 30034 us; close: 15000 us; write: min,max: 7934 12938 us)

unmount FR_OK
But the funny thing is, if I use a extender cable it drops down to around 4mb/s. Also, funny, 30x1024 works but not 32 :)
 
If I push the HDD to 30:
Code:
Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

 (32996 - 7.448175 MB/s)
 (open: 22037 us; close: 15000 us; write: min,max: 8918 8923 us)

unmount FR_OK
its a little over 1 Mb/s bump up. Speed limit may be buffer size limited on the larger drives.
 
Wanted to see where the problem was error - seems to just be with 32x1024 (think I remember @WMXZ mentioning that). Anyway managed to push the limits on the buffer size to 52x1024 and got 12mbs transfers:
Code:
Test logger_RawWrite
uSDFS_VER:15_MAY_19_08_16
BUFFSIZE :53248
Dev Type :2:/
## mscInit before msgGetMaxLun: 1
## mscInit after msgGetMaxLun: 0
File System FS_EXFAT
Free Disk Size -1 clusters
Cluster Size 512 sectors
Sector Size 512 bytes

Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

 (33996 - 12.530416 MB/s)
 (open: 15034 us; close: 15000 us; write: min,max: 6862 11867 us)

unmount FR_OK
 
Did you note: uint32_t buffer[BUFFSIZE]; // 4 bytes per BUFFSIZE entry in the buffer

For SSD that isn't super impressive either given the are listed at 500MB or some GB's - of course this is write … - wonder what my oricon unit will do … I didn't go over [30x1024] and saw mid to high 11's on old HDD - and even a 12 MB/s at least once.

I didn't get latest code yet - mine fails at round numbers over 30*1K that I tried. I get 11.7 to 11.9 there and 10.93 avg dropping down to 24*1K.


I haven't looked at the code with my jumping around … are these writes blocking or async possible?
 
For more fun, I thought I would try out an older disk, I had sitting around, an older Toshiba drive that supports ESATA, was used on our older Directv box when their internal drive failed...

It fails on the first READ10 call:
Code:
Test uSDFS
2:/
USB2 PLL running
 reset waited 6
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 20005000
periodictable = 20005000
port change: 10001803
    connect
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 00 00 00 40 39 09 13 0B 00 01 01 02 03 01 
    VendorID = 0939, ProductID = 0B13, Version = 0100
    Class/Subclass/Protocol = 0 / 0 / 0
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: TOSHIBA 
enumeration:
Product: External HDD    
enumeration:
Serial Number: 0010101A402E78AF0
enumeration:
Config data length = 32
enumeration:
Configuration Descriptor:
  09 02 20 00 01 01 00 C0 01 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 02 08 06 50 00 
    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:
msController claim this=20004340
Descriptor 4 = INTERFACE
msController claim this=20004340
09 04 00 00 02 08 06 50 00 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
control CallbackIn (msController)
00 00 00 00 00 00 00 00 
control CallbackIn (msController)
01 00 00 00 00 00 00 00 
## mscInit after msgGetMaxLun: 1
msController CallbackOut (static)
transfer->qtd.token = 0
msController dataOut (static)31
55 53 42 43 02 00 00 00 00 00 00 00 80 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 13
55 53 42 53 02 00 00 00 00 00 00 00 00 
** CSWSIGNATURE
msController CallbackOut (static)
transfer->qtd.token = 0
msController dataOut (static)31
55 53 42 43 03 00 00 00 24 00 00 00 80 00 06 12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 36
05 80 00 21 1F 00 00 00 54 4F 53 48 49 42 41 20 56 69 72 74 75 61 6C 20 43 64 72 6F 6D 20 20 20 
** ????
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 13
55 53 42 53 03 00 00 00 00 00 00 00 00 
** CSWSIGNATURE
## mscInit msDeviceInquiry call: 0
BYTE      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
---------------------------------------------------------
0000      05 80 00 21 1f 00 00 00 54 4f 53 48 49 42 41 20   ...!....TOSHIBA 
0010      56 69 72 74 75 61 6c 20 43 64 72 6f 6d 20 20 20   Virtual Cdrom   
0020      31 2e 30 30 00 00 00 00 00 00 00 00 00 00 00 00   1.00............
msController CallbackOut (static)
transfer->qtd.token = 0
msController dataOut (static)31
55 53 42 43 04 00 00 00 08 00 00 00 80 00 0A 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 8
00 01 F3 FF 00 00 08 00 
** ????
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 13
55 53 42 53 04 00 00 00 00 00 00 00 00 
** CSWSIGNATURE
## mscInit completed: 0
msController CallbackOut (static)
transfer->qtd.token = 0
msController dataOut (static)31
55 53 42 43 05 00 00 00 00 00 00 00 80 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
msController CallbackIn (static)
transfer->qtd.token = 0
msController dataIn (static): 13
55 53 42 53 05 00 00 00 00 00 00 00 00 
** CSWSIGNATURE
msController CallbackOut (static)
transfer->qtd.token = 0
msController dataOut (static)31
55 53 42 43 06 00 00 00 00 02 00 00 80 00 0A 28 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 
msController CallbackIn (static)
transfer->qtd.token = 64
msController dataIn (static): 0
ERROR Followup
The interesting thing is that this drive sort of acts like Virtual Cdrom... Notice the information from device inquiry above.
The first byte 05, looking at the spec shows device type 5 -CD/DVD device

Looking at one of my USB sticks.
Code:
## mscInit msDeviceInquiry call: 0
BYTE      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
---------------------------------------------------------
0000      00 80 04 02 1f 73 6d 69 53 4d 49 20 20 20 20 20   .....smiSMI     
0010      55 53 42 20 44 49 53 4b 20 20 20 20 20 20 20 20   USB DISK        
0020      31 31 30 30 00 00 00 00 00 00 00 00 00 00 00 00   1100............
First byte 0 - Direct access block device (e.g., magnetic disk)

My guess is their communication protocols are different...
 
@all

I have been experimenting with sd_msc.cpp and found that if I comment out WaitDriveReady() that the speed of writing almost doubles.
Code:
	int MSC_disk_read(BYTE *buff, DWORD sector, UINT count) 
	{	//WaitDriveReady();
		return readSectors((BYTE *)buff, sector, count);
	}

	int MSC_disk_write(const BYTE *buff, DWORD sector, UINT count) 
	{	//WaitDriveReady();
		return writeSectors((BYTE *)buff, sector, count);
	}

In logger_RawWrite_FS.ino, I had to downsize buffersize for T36 to (3 * 1024) for the hard drives to keep it from locking up. For flash sticks I had to downsize to (3 * 1024) for best performance. I have the T36 set at 240MHZ and optimize set at fastest.

This is the output of a WD hardrive buffer size (3 * 1024):
Code:
Test logger_RawWrite
2019-05-18 16:23:51
BUFFSIZE :3072
Dev Type :2
Using uSDFS
uSDFS_VER:15_MAY_19_08_16
## mscInit before msgGetMaxLun: 1
## mscInit after msgGetMaxLun: 0
File System FS_FAT32
Free Disk Size 1881014 clusters
Cluster Size 64 sectors
Sector Size 512 bytes

Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

................................................................
.................................... (3929987 - 3.126728 MB/s)
 (open: 76899 us; close: 14935 us; write: min,max: 2928 27933 us)

A_00002.dat
stat FR_OK 1dd4
 opened FR_OK 0

................................................................
.................................... (3968987 - 3.096004 MB/s)
 (open: 99932 us; close: 14935 us; write: min,max: 2928 34933 us)

A_00003.dat
stat FR_OK b6f
 opened FR_OK 0

................................................................
.................................... (3983987 - 3.084347 MB/s)
 (open: 78939 us; close: 18935 us; write: min,max: 2928 55934 us)

A_00004.dat
stat FR_OK bec
 opened FR_OK 0

................................................................
.................................... (4005987 - 3.067409 MB/s)
 (open: 79938 us; close: 23935 us; write: min,max: 2928 57934 us)

A_00005.dat
stat FR_OK c7b
 opened FR_OK 0

................................................................
.................................... (3982987 - 3.085122 MB/s)
 (open: 85940 us; close: 14935 us; write: min,max: 2928 81933 us)

A_00006.dat
stat FR_OK cf8
 opened FR_OK 0

................................................................
.................................... (3952983 - 3.108539 MB/s)
 (open: 23943 us; close: 29935 us; write: min,max: 2928 46934 us)

A_00007.dat
stat FR_OK 1728
 opened FR_OK 0

................................................................
.................................... (4059987 - 3.026611 MB/s)
 (open: 101939 us; close: 14935 us; write: min,max: 2928 54934 us)

A_00008.dat
stat FR_OK e29
 opened FR_OK 0

................................................................
.................................... (4020987 - 3.055966 MB/s)
 (open: 103939 us; close: 15935 us; write: min,max: 2928 56934 us)

A_00009.dat
stat FR_OK ea6
 opened FR_OK 0

................................................................
.................................... (4000987 - 3.071242 MB/s)
 (open: 109938 us; close: 14935 us; write: min,max: 2928 52933 us)

A_00010.dat
stat FR_OK f23
 opened FR_OK 0

................................................................
.................................... (4096986 - 2.999278 MB/s)
 (open: 113938 us; close: 14934 us; write: min,max: 2928 62934 us)

unmount FR_OK

For a Kingston flash drive with (3 * 1024) I get this:
Code:
Test logger_RawWrite
2019-05-18 16:44:16
BUFFSIZE :2048
Dev Type :2
Using uSDFS
uSDFS_VER:15_MAY_19_08_16
## mscInit before msgGetMaxLun: 1
## mscInit after msgGetMaxLun: 0
File System FS_FAT32
Free Disk Size 1874875 clusters
Cluster Size 32 sectors
Sector Size 512 bytes

Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

................................................................
.................................... (3773987 - 2.170649 MB/s)
 (open: 538921 us; close: 40956 us; write: min,max: 2949 295955 us)

A_00002.dat
stat FR_OK 3736
 opened FR_OK 0

................................................................
.................................... (5270987 - 1.554168 MB/s)
 (open: 168930 us; close: 625956 us; write: min,max: 2949 743955 us)

A_00003.dat
stat FR_OK f90
 opened FR_OK 0

................................................................
.................................... (4578984 - 1.789043 MB/s)
 (open: 23938 us; close: 52956 us; write: min,max: 2949 566955 us)

A_00004.dat
stat FR_OK 2501
 opened FR_OK 0

................................................................
.................................... (4795987 - 1.708095 MB/s)
 (open: 170938 us; close: 53956 us; write: min,max: 2949 533955 us)

A_00005.dat
stat FR_OK 1809
 opened FR_OK 0

................................................................
.................................... (4669986 - 1.754181 MB/s)
 (open: 715938 us; close: 49956 us; write: min,max: 2950 625955 us)

A_00006.dat
stat FR_OK 2c78
 opened FR_OK 0

................................................................
.................................... (4110983 - 1.992711 MB/s)
 (open: 23942 us; close: 43956 us; write: min,max: 2949 91955 us)

A_00007.dat
stat FR_OK 30fc
 opened FR_OK 0

................................................................
.................................... (5190987 - 1.578120 MB/s)
 (open: 91939 us; close: 42956 us; write: min,max: 2950 606955 us)

A_00008.dat
stat FR_OK 25a2
 opened FR_OK 0

................................................................
.................................... (4004987 - 2.045450 MB/s)
 (open: 77938 us; close: 40956 us; write: min,max: 2950 127955 us)

A_00009.dat
stat FR_OK 269c
 opened FR_OK 0

................................................................
.................................... (5303987 - 1.544499 MB/s)
 (open: 80938 us; close: 46956 us; write: min,max: 2950 663955 us)

A_00010.dat
stat FR_OK 2796
 opened FR_OK 0

................................................................
.................................... (4193987 - 1.953273 MB/s)
 (open: 94938 us; close: 52956 us; write: min,max: 2949 141954 us)

unmount FR_OK

Is there a way to eliminate the dot printing? Would this change the speed of the writes?
Results may vary...

It seems to really depend on the response times of the device with buffer size.
 
@wwatson
Interesting I have been using logger_write not logger_write_fs. If I use the SSD with Buffer at 30*1024 I get about 10.1Mb/s vs the 5.5 using the logger_write sketch:
Code:
A_00003.dat
stat FR_OK 2035
 opened FR_OK 0

................................................................
.................................... (12159992 - 10.105269 MB/s)
 (open: 39994 us; close: 104923 us; write: min,max: 7921 22923 us)

unmount FR_OK
Ok time to retest the HDD.

@defragster - which sketch did you fix to get the correct speeds?
 
Ok with the HDD used in previous tests and a 30x1024 buffer (can't go over 31) in both cases:
Code:
30x1024

A_00004.dat
stat FR_NO_FILE 3b3
 opened FR_OK 0
................................................................
.................................... (10853991 - 11.321181 MB/s)
 (open: 44996 us; close: 26923 us; write: min,max: 8921 18990 us)
unmount FR_OK
 
Please note the tests in the previous 2 posts are with a T$ with the modification noted in post #165

Mike
 
@mjs513
Is this with the T4 or the T36. I Only have a T36 to test with. Did commenting out the WaitDriveReady() in sd_msc.cpp read and write functions improve the throughput speed? Or am I missing something. I Have the latest uSDFS.
 
@mjs513
Is this with the T4 or the T36. I Only have a T36 to test with. Did commenting out the WaitDriveReady() in sd_msc.cpp read and write functions improve the throughput speed?

I tried logger_RawWrite.ino. With the T36, can't go over 3 * 1024 with the T36.
 
It was in : T:\tCode\libraries\uSDFS\examples\logger_RawWrite\logger_RawWrite.ino

I don't have a copy of the logger_RawWrite_FS.ino - maybe next pull from Github?

Did you guys put in my QUIT code?

Code:
  if (ifn > MXFN) { blink(500); return; }

 [COLOR="#FF0000"] while (Serial.available() > 0) { if ('q' == Serial.read() ) { count=0; ifn = MXFN+1; } }[/COLOR]

  if (!count)
  {
    // close file
    if (isFileOpen)
    { dtc = micros();
      //close file
      if ((rc = f_close(&fil))) die("close", rc);
      //
      isFileOpen = 0;
      t1 = micros();
      dtc = t1 - dtc;
      [B][U]float MBs = (MXRC * BUFFSIZE * 4.0f) / (1.0f * (t1 - t0));[/U][/B]
      Serial.printf(" (%d - %f MB/s)\n (open: %d us; close: %d us; write: min,max: %d %d us)\n\r",
                    t1 - t0, MBs, dto, dtc, dtwmin, dtwmax);
      dtwmin = 1 << 31; dtwmax = 0;
    }
  }

I don't think Serial.print slows much down. As a BUSY work sketch I calc the primes up to 65K, there are 6542 of them.

It takes 19.5 ms to calc them on T4, and 8.1 ms to print them - ten per line is 654 full lines and they pop on TyComm without even bothering to scroll - would be a bit slower on T_3.6 - but it is only one dot printed per each TEN buffers.
 
@defragster
I can see the quit code in my version of libraries\uSDFS\examples\logger_RawWrite\ logger_RawWrite.ino.
Thanks for the info on Serial.print. In the past it was kind of an issue.

You guys amaze me with your level of programming talent and skills. I can't wait for the release of the T4.
 
It was in : T:\tCode\libraries\uSDFS\examples\logger_RawWrite\logger_RawWrite.ino

I don't have a copy of the logger_RawWrite_FS.ino - maybe next pull from Github?

Did you guys put in my QUIT code?

the QUIT code is in GitHub code

logger_RawWrite_FS.ino is rather new and should stimulate testing the different FS used with Teensy
 
Cool - I thought the Quit was a good way to make sure there wasn't corruption caused when quit would shutdown cleanly - before upload or other planned shutdown - or if a long test was started and a clean end was due.

I didn't get the new code yet - been distracted with PJRC package - and just finished soldering a board in there - and desoldering b2 5V<>VUSB just to see if it runs as expected with external 5V - runs USB logger.

Also most of today and yesterday were also (other) hobby day …
 
@mjs513
Is this with the T4 or the T36. I Only have a T36 to test with. Did commenting out the WaitDriveReady() in sd_msc.cpp read and write functions improve the throughput speed?

I tried logger_RawWrite.ino. With the T36, can't go over 3 * 1024 with the T36.

@wwatson
Testing was done with a T4 and I left in the WaitDriveReady(). I just retested with those lines commented out and saw about a 4 Mb/s boost:
Code:
[B]SSD:[/B]
A_00003.dat
stat FR_NO_FILE 2ee2
 opened FR_OK 0

................................................................
.................................... (8335991 - 14.740899 MB/s)
 (open: 26996 us; close: 8923 us; write: min,max: 5921 12923 us)

unmount FR_OK

[B]HDD:[/B]
A_00003.dat
stat FR_OK 1de
 opened FR_OK 0

................................................................
.................................... (7963996 - 15.429440 MB/s)
 (open: 30991 us; close: 21923 us; write: min,max: 6921 13923 us)

unmount FR_OK
 
Back
Top