Hello everyone, I need some clarification on how fast the USB-A port is on the Arduino Giga R1. When transferring a text file to a plugged in USB drive of about 10KB from the Giga it takes minutes, which to me indicates slow transfer, beyond the delay taken to allocate the write area on the USB drive. Looking in the Arduino library for USB "Arduino_USBHostMbed5" they list in software a baud rate of 9600 bits/second with a circular buffer of only 128 bytes. This is unacceptably slow, considering the port is rated at 480,000,000 baud and the STM32H747 MCU has HARDWARE support for USB transfers, as well as MBED OS has the drivers to do so as well. What is going on here? How do I get the real USB 2.0 speed of the port? (I also talked to stm32 engineers and they are also in agreement that there is no reason Arduino cant crank the speed of the port to its normal transfer rate)
USB speed is ALWAYS a function of the host computer, not the slave that is your Arduino. The transfer rate of USB has no relation to the DATA rate your host computer is using. Something is slowing the program on your PC. Perhaps storing into a complex data base?
Further thoughts: Does you PC have more than a single USB controller? Is the received data also being written back to a USB device?
-
I’m referring to the library from Arduino have a slow data rate
-
I’m talking about the write speed from the Arduino giga into a usb flash drive, no PC required
no, the giga has a full blown USB-A port, with the hardware in the STM32H747Xi microcontroller to facilitate usb mass storage host capabilities. The issue is arduino in software set a baud rate of 9600 bits per second to the port insteads of the rated 480,000,000 baud in the microcontroller documentation (and the usb 2.0 spec). The offending lines are in USBHostSerial.cpp here: (230 and 249) Arduino_USBHostMbed5/src/USBHostSerial/USBHostSerial.cpp at main · arduino-libraries/Arduino_USBHostMbed5 (github.com)
So, change that and test again.
What I'm looking for is for someone from arduino to elaborate on what the capabilities of their board is, there seems to be a lot of confusion on the github and a pile of people talking about crashing (yes mbed os on the giga can have a full blown kernel panic) and instability with the usb port. That is why I'm guessing they limited it to the slowest possible serial speed on USB. Just looking for some info/insight from the people who maintain it/built it/anyone who managed to get actual usb speeds from it. Thanks for your suggestion though. 
Hey community, I'm going to spend the next couple days and make my own port of the mbed5 usb drivers, most importantly it will have 2 objectives:
- as high of a usb transfer rate as possible
- non blocking reads and writes so it doesn't lock up the microcontroller while you are doing data logging, hit it with a large binary chunk of data and as long as its smaller than some buffer size ill let you set then it will keep marching on in hardware with a callback when its complete.
Wish me luck!
Sorry I am not from Arduino, and I just started to play with the board yesterday, so I for sure do not know the ins and outs of this board. So, take some of this with a grain of salt.
I tried running the List Files example for the USB Drive stuff and my thumb drive is 8GB and formatted as FAT32 as I understand is required. I copied several files on it, and when I try that sketch, the MBED fails with the red blinking...
As for the Speed to write to a USB storage device. I am pretty sure that the USB Serial speed setting of 9600 has nothing to do with it.
That is, USB will always write at USB speed. For USB 2 devices that could be at Low speed (1.5mbs), Full Speed (12MBS) or High Speed (480Mbs). Note: If I remember correctly from this processors specs, the USB Device port (the one that plugs into your host) is a Full speed device, whereas the USB Host port can run at High speed.
For most devices/boards I have worked with, The LS and FS USB Transfers are up to 64 bytes, where the HS is up to 512 bytes per transfer.
Where does the USB Serial speed, format, ... come into effect. If a device plugs into the Host that supports the Serial Interface (CDC ACM....), A control message will be sent over to the device that you plugged into your host with this information. For some devices it is mostly ignored.
For example if you plug in an Arduino UNO R4 Minima, for the most part it could care less, although a sketch can query it and use it...
For some devices this is very important. For example, if you plug in an Arduino UNO R4 WiFI - this information is passed to the ESP32-S3 chip that is controlling the USB and then it configures it's hardware UART that talks to the RA4M1 processor with this information. And your sketch running on this board needs it's Serial.begin(baud) to match.
What might be making the USB Drive writes (or reads) to be slow? As I have not tried it on this board, yet I am only throwing out darts:
a) Maybe they are not communicating at High speed. Or maybe not using 512 byte transfers.
b) Maybe lots of overhead on the different layers of code.
c) Maybe not being used in an optimal way. On many boards when you write (or read) from SD cards using something like the SdFat library the performance improves a lot if your Reads and writes are done with the count of bytes transferred being a multiple of the Sector (or cluster) size. Often times 512 byte sectors.
I don't know when you do writes to the file object, does it send each write as you do it, over USB or does it try to pack the data into full 512 byte USB packets.
Not sure if this helps or not.
Thank you for your insights, ill do some investigating into this!
Hi, I have the same problem. Have you found any solution?
not at all, we ended up spending weeks porting all 100K+ lines of code we had to run on platform io on the teensy 4.1, everything on the teensy runs at full speed with no issues
I know some of us have played with it some.
@wwatson @Merlin513 - I am trying to remember if we found any real major speed improvements.
My recollection is maybe some, but it is still many times slower than Teensy?
Side note: @wwatson has also ported a version of the ext4 FS to the GIGIA. Need to look again to see how the speeds compare.
@KurtE - I did post a comparison of speeds for GIGAext4FS as opposed to FAT32. I used a modified version of the SdFat bench.ino. Here is the link staring a post #9:
https://forum.arduino.cc/t/lets-discuss-the-arduino-giga-vs-the-teensy-4-1/1209984/9
The write speeds for ext4 are about twice as fast as FAT32. The test were done with multisector reads/writes instead of single sector read/writes at a time. It also explains the modifications I made to USBHostMSD.h.
Post moved
Are talking about an SD card or a USB thumb drive? As far as I know SdFat is not for a USB drive on a GIGA.
Yep - they have their own implementation of FAT, that if I remember correctly does not support ExFat. Was not sure if we had ported over our Teensy version or not...
What I really don't understand is that the GIGA version.
#include <FATFileSystem.h>
AFAIK is not derived at all from the MBED file system stuff.
But instead, you end up using C functions from STDIO to access the files.
Not sure if maybe the MBED stuff is buried somewhere within the setup?
There is layer after layer of files in the core. LittleFS and FatFs are buried in the GIGA core lib and the source is only available after recompiling the the core (Mbed OS). the whole thing in Linux winds up in "/tmp/mbed-os-program/mbed-os/storage". You will find several directories including "CHaN" which has the FatFs file system in the "fat" directory. In the "storage/fat" directory you will also find the FATFileSystem.cpp and FATFileSystem.h files plus other goodies.
At one point I found the wapper for the stdio C lib but I cannot remember where 
FATFileSysytem.cpp and .h contain the c++ wapper for FatFs calls.
Anyway that is a far as I have gotten with it. The result is GIGAEXT4V1. ExtFat was not enabled because of fear of copyright problems according to a post I cannot find again. I was able to enable it in the core lib but it did not work...
Sorry I have post in the wrong thread, I will move the post