T4.x support for Raw HID 512? wonder if it makes sense to add to system?

@PaulStoffregen - @KurtE

Based on the testing so far think this would a good idea to add for the next beta - so basically I second what @KurtE said on getting the PR's incorporated
 
I just pushed up a Play in Progress to my rawhid project.

Where I have updated my PC host code, that I build using Visual Studio 2022 to take to the RAWHID. The code is setup to know if we are using 64 or 512 byte packets.
The program FileTransferTest builds as a console app.

Very rudimentary commands on it.
Simple run:
Code:
found rawhid device
packet size:512
Command list
        dir(or ls) [optional pattern] - show directory files on remote FS
        cd <file pattern> - Change directory on remote FS
        download(or d) <remote file> <localfile spec> - download(Receive) file from From remote
        upload(or u) <local file spec> [remote file spec] - Upload file to remote
        ld [optional pattern] - show directory files on Local FS
        lc <file pattern> - Change directory on local FS
        $ - Reboot remote
: ls
ls
remote_dir called
mtpindex.dat                         C: 04/27/2023 08:11 M: 04/27/2023 08:11 0
j0234696.gif                         C: 06/22/2022 14:51 M: 06/29/2003 06:45 3797
Laiik-is-Tired.bmp                   C: 06/22/2022 14:51 M: 01/16/2022 04:34 230454
Laik-Head.bmp                        C: 06/22/2022 14:51 M: 03/11/2022 07:31 115304
P3090005.JPG                         C: 06/22/2022 14:51 M: 03/05/2000 20:31 1773722
perf_small.png                       C: 06/22/2022 14:51 M: 01/23/2022 06:06 28955
PictureViewOptions.ini               C: 06/22/2022 14:51 M: 01/24/2022 10:45 87
SDTEST1.mp3                          C: 06/22/2022 14:51 M: 12/01/2021 06:24 2791046
SDTEST2.mp3                          C: 06/22/2022 14:51 M: 12/01/2021 06:24 2962926
SDTEST3.mp3                          C: 06/22/2022 14:51 M: 12/01/2021 06:24 2079162
SDTEST4.mp3                          C: 06/22/2022 14:52 M: 12/01/2021 06:24 3135327
Sharon Barn.bmp                      C: 06/22/2022 14:52 M: 07/09/2005 08:41 6754230
Small-Drake.jpg                      C: 06/22/2022 14:52 M: 10/29/2004 07:56 54453
annie2.bmp                           C: 06/22/2022 14:52 M: 01/16/2022 04:33 230454
annie3.bmp                           C: 06/22/2022 14:52 M: 01/16/2022 04:33 230454
Candyman.aac                         C: 06/22/2022 14:52 M: 12/02/2021 06:02 3177823
DSC00040.JPG                         C: 06/22/2022 14:52 M: 01/03/2003 16:44 4101896
DSC00445.jpg                         C: 06/22/2022 14:52 M: 06/12/2003 14:49 52381
DSC01511.JPG                         C: 06/22/2022 14:52 M: 01/08/2005 12:10 2014423
DSC03201.JPG                         C: 06/22/2022 14:52 M: 03/01/2009 15:14 3380794
house.gif                            C: 06/22/2022 14:52 M: 04/11/2005 06:43 206364
annie1.bmp                           C: 04/02/2023 10:54 M: 01/16/2022 04:33 230454
System Volume Information            C: 05/05/2023 08:30 M: 05/05/2023 08:30 <dir>
x.txt                                C: 05/06/2023 16:37 M: 05/10/2023 08:48 32012
coyote.jpg                           C: 01/01/2019 00:13 M: 05/09/2023 12:18 49152
Jake-and-Clare-In-Car.jpg            C: 05/14/2023 06:34 M: 05/14/2023 07:25 75126
halloween.jpg                        C: 05/14/2023 07:03 M: 05/14/2023 07:24 21026
Completed
: d Jake-and-Clare-In-Car.jpg d:\Jake-and-Clare-In-Car.jpg
d
Jake-and-Clare-In-Car.jpg
d:\Jake-and-Clare-In-Car.jpg
Download called
Downloading from:Jake-and-Clare-In-Car.jpg to:d:\Jake-and-Clare-In-Car.jpg
..................
Completed, total byte: 75126 elapsed millis: 16
:

Earlier I uploaded that picture ... And then downloaded it and it works:
Jake-and-Clare-In-Car.jpg

There are still some issues of commands and the like getting out of sync that I need to work on... But more of just getting idea of how well it could upload/download.
Note: in the PC case I kept some things simple, like not trying to buffer up multiple packets of data before I write to disk or read from disk...

Just having some fun
 
I just pushed up a Play in Progress to my rawhid project.

Where I have updated my PC host code, that I build using Visual Studio 2022 to take to the RAWHID. The code is setup to know if we are using 64 or 512 byte packets.
The program FileTransferTest builds as a console app.

Very rudimentary commands on it.
Simple run:
Code:
found rawhid device
packet size:512
Command list
        dir(or ls) [optional pattern] - show directory files on remote FS
        cd <file pattern> - Change directory on remote FS
        download(or d) <remote file> <localfile spec> - download(Receive) file from From remote
        upload(or u) <local file spec> [remote file spec] - Upload file to remote
        ld [optional pattern] - show directory files on Local FS
        lc <file pattern> - Change directory on local FS
        $ - Reboot remote
: ls
ls
remote_dir called
mtpindex.dat                         C: 04/27/2023 08:11 M: 04/27/2023 08:11 0
j0234696.gif                         C: 06/22/2022 14:51 M: 06/29/2003 06:45 3797
Laiik-is-Tired.bmp                   C: 06/22/2022 14:51 M: 01/16/2022 04:34 230454
Laik-Head.bmp                        C: 06/22/2022 14:51 M: 03/11/2022 07:31 115304
P3090005.JPG                         C: 06/22/2022 14:51 M: 03/05/2000 20:31 1773722
perf_small.png                       C: 06/22/2022 14:51 M: 01/23/2022 06:06 28955
PictureViewOptions.ini               C: 06/22/2022 14:51 M: 01/24/2022 10:45 87
SDTEST1.mp3                          C: 06/22/2022 14:51 M: 12/01/2021 06:24 2791046
SDTEST2.mp3                          C: 06/22/2022 14:51 M: 12/01/2021 06:24 2962926
SDTEST3.mp3                          C: 06/22/2022 14:51 M: 12/01/2021 06:24 2079162
SDTEST4.mp3                          C: 06/22/2022 14:52 M: 12/01/2021 06:24 3135327
Sharon Barn.bmp                      C: 06/22/2022 14:52 M: 07/09/2005 08:41 6754230
Small-Drake.jpg                      C: 06/22/2022 14:52 M: 10/29/2004 07:56 54453
annie2.bmp                           C: 06/22/2022 14:52 M: 01/16/2022 04:33 230454
annie3.bmp                           C: 06/22/2022 14:52 M: 01/16/2022 04:33 230454
Candyman.aac                         C: 06/22/2022 14:52 M: 12/02/2021 06:02 3177823
DSC00040.JPG                         C: 06/22/2022 14:52 M: 01/03/2003 16:44 4101896
DSC00445.jpg                         C: 06/22/2022 14:52 M: 06/12/2003 14:49 52381
DSC01511.JPG                         C: 06/22/2022 14:52 M: 01/08/2005 12:10 2014423
DSC03201.JPG                         C: 06/22/2022 14:52 M: 03/01/2009 15:14 3380794
house.gif                            C: 06/22/2022 14:52 M: 04/11/2005 06:43 206364
annie1.bmp                           C: 04/02/2023 10:54 M: 01/16/2022 04:33 230454
System Volume Information            C: 05/05/2023 08:30 M: 05/05/2023 08:30 <dir>
x.txt                                C: 05/06/2023 16:37 M: 05/10/2023 08:48 32012
coyote.jpg                           C: 01/01/2019 00:13 M: 05/09/2023 12:18 49152
Jake-and-Clare-In-Car.jpg            C: 05/14/2023 06:34 M: 05/14/2023 07:25 75126
halloween.jpg                        C: 05/14/2023 07:03 M: 05/14/2023 07:24 21026
Completed
: d Jake-and-Clare-In-Car.jpg d:\Jake-and-Clare-In-Car.jpg
d
Jake-and-Clare-In-Car.jpg
d:\Jake-and-Clare-In-Car.jpg
Download called
Downloading from:Jake-and-Clare-In-Car.jpg to:d:\Jake-and-Clare-In-Car.jpg
..................
Completed, total byte: 75126 elapsed millis: 16
:

Earlier I uploaded that picture ... And then downloaded it and it works:
View attachment 31102

There are still some issues of commands and the like getting out of sync that I need to work on... But more of just getting idea of how well it could upload/download.
Note: in the PC case I kept some things simple, like not trying to buffer up multiple packets of data before I write to disk or read from disk...

Just having some fun

Nice @KurtE - looks like you got almost 100% working :)
 
It is not working too bad. hacked in a few more things, like to rescan for rawhid device if it was not there ... command to tell the teensy to reset, quick and dirty command input parsing code now handles " around names with blanks. It is pretty primitive, but that part works.

I still need to work on modify date/time stuff.. but
Did upload a bitmap file that is 6754230 bytes long which took about 1.7 seconds
and then downloaded it back to different location and it took also about 1.7 seconds.

Probably done for today!
 
Just a quick update.

I have been playing some more with this, doing file transfers and the like.
The PC sketch I have now has several different commands, all somewhat primitive, but includes things lik:
cd, pwd, dir or ls, upload, download, mkdir, rmdir, del or rm

I normally have this built using Visual Studio, which requires several things to be installed. I sort of outlined this in the readme file.

I have also setup a makefile for the program, that I allows me to build it for linux. I just ran it on my 22.04 machine.

My PC level coding is not the greatest. I have not used some of this stuff in a long time (some never). Like best way to setup a quick and dirty thread, to
monitor the RAWHID, while the code is waiting for a command line. At first was using Windows specific API, but now using std::thread

Also switched from windows only thing to compute elapsed time to use <chrono>

Currently I am only updating or retrieving the modify date/time on windows. Not sure yet of linux ways.

Also have not touched MAC yet on this. Not sure I will yet...

As not sure if this is going anywhere, except for my own amusement.

Kurt
 
Fun stuff @KurtE! I keep watching - but still working on my mower deck as grass grows. Too much rust and too thin to weld beyond the reinforced important parts - now waiting for JB Weld to harden to paint.

Would be great to see this RawHID_512 in TD Beta as it seems to provide good fast utility option! Seems built it here in past months early version but not had time to collect WIP pieces and follow this time.

Is the net throughput to Host any diff in speed than USB Serial - like for sending log data (@mjs513 did some streaming sends)? Could it (with your app) stream a wav file to play with Audio Lib? Just asking for friends that might see value in such things using the PC for data.
 
@KurtE - This is starting to look like MTP. Wonder if it could be as fast or faster with a smaller footprint:)
 
@KurtE - This is starting to look like MTP. Wonder if it could be as fast or faster with a smaller footprint:)

good question. I am just sort of playing. Will be curious to see how well they perform. As I mentioned, just experimenting...

Was trying to see if I could actually build for my old MAC, but the makefile and the like appear to have issues.
Starting with my SDK is different version and location...

Wondering has anyone used the RAWHID stuff on Mac?
Especially looking at the code that has somments like,:
No matter what I tried this never actually sends an output
report and output_callback never gets called...
 
I am probably mostly done playing here... It has been fun and trying some different things.

Like today I wondered if I could also receive the SEREMU rawhid stream as well from the Teensy (in my current case a T4.1).
So my scan function to look for rawhid:
Code:
bool scan_for_rawhid_device() {
    int r;

    // C-based example is 16C0:0480:FFAB:0200
    //r = rawhid_open(1, 0x16C0, 0x0480, 0xFFAB, 0x0200);
    // This one is setup for Teensy based one built as rawhid
    //if (r <= 0) {
    // Arduino-based example is 16C0:0486:FFAB:0200
    //r = rawhid_open(1, 0x16C0, 0x0486, 0xFFAB, 0x0200);
    r = rawhid_open(2, 0x16C0, 0x0486, -1, -1);
    if (r <= 0) {
        printf("no rawhid device found\n");
        return false;
    }
    //}
    printf("found rawhid %d devices\n", r);
    g_rawhid_index = -1;
    seremu_end(); // make sure we are not running one now. 
    for (int i = 0; i < r; i++) {
        printf("\t(%x, %x):", rawhid_usage_page(i), rawhid_usage(i));
        if ((rawhid_usage_page(i) == 0xFFAB) && (rawhid_usage(i) == 0x0200)) {
            // found the rawhid one
            g_rawhid_index = i;
                g_rawhid_rx_tx_size = rawhid_txSize(i);
                printf("Rawhid index %d packet size:%u\n", i, g_rawhid_rx_tx_size);
        }
        else if ((rawhid_usage_page(i) == 0xffc9) && (rawhid_usage(i) == 0x4)) {
            // SEREMU
            g_rawhid_sereum_index = i;  //which rawhid index to use
            uint16_t g_seremu_rx_size = rawhid_rxSize(i);
            printf("SEREMU index % d packet size : % u\n", i, g_seremu_rx_size);
            seremu_begin(i);
        }
        else {
            printf("???\n");
        }
    }

    return true;

}

My seremu_begin() method, creates a thread, that calls off to:
Code:
        int cb = rawhid_recv(s_seremu_index, packet_buf, sizeof(packet_buf), 50);
If I receive a packet, a stash it away and have some other code that then prints out the contents to stdout...
It sort of works, but when I try to do something like a: dir command, which on the Teensy will generate several rawhid packets (actually 1 per file right now)
And now the code crawls, at least on windows.

Figured out why... The rawhid_recv function (in hid_windows.c) does:
Code:
int rawhid_recv(int num, void *buf, int len, int timeout)
{
	hid_t *hid;
	unsigned char tmpbuf[516];
	OVERLAPPED ov;
	DWORD n, r;

	if (sizeof(tmpbuf) < len + 1) return -1;
	hid = get_hid(num);
	if (!hid || !hid->open) return -1;
	EnterCriticalSection(&rx_mutex);
	ResetEvent(&rx_event);
	memset(&ov, 0, sizeof(ov));
	ov.hEvent = rx_event;
	if (!ReadFile(hid->handle, tmpbuf, len + 1, NULL, &ov)) {
		if (GetLastError() != ERROR_IO_PENDING) goto return_error;
		r = WaitForSingleObject(rx_event, timeout);
		if (r == WAIT_TIMEOUT) goto return_timeout;
		if (r != WAIT_OBJECT_0) goto return_error;
	}
	if (!GetOverlappedResult(hid->handle, &ov, &n, FALSE)) goto return_error;
	LeaveCriticalSection(&rx_mutex);
	if (n <= 0) return -1;
	n--;
	if (n > (DWORD)len) n = len;
	memcpy(buf, tmpbuf + 1, n);
	return n;
return_timeout:
	CancelIo(hid->handle);
	LeaveCriticalSection(&rx_mutex);
	return 0;
return_error:
	print_win32_err();
	LeaveCriticalSection(&rx_mutex);
	return -1;
}

So while my SEREMU is waiting for a message it will typically timeout after 50ms, and only then will the main call for rawhid_recv to retrieve the next files information will be allowed to continue.
This is the only place the rx_mutex is used and I believe the reason is, that the rx_event object is a global variable...

My next experiment is to try to move:
Code:
static HANDLE rx_event=NULL;
static HANDLE tx_event=NULL;
static CRITICAL_SECTION rx_mutex;
static CRITICAL_SECTION tx_mutex;

To be members of the hid_struct. So hopefully the critical section will only block other threads that are trying to also read from the same rawhid... Likewise for write.
If anyone is looking, does this make sense?

Edit: So far it appears to be working...
 
Last edited:
Quick update:

As I mentioned in the update to the last post, moving the events and critical sections to the struct associated with each rawhid connection, appears to work. I have it setup that each one
is trying to recv messages on different std::thread threads. The code is setup as I mentioned for the SEREMU data packets that I receive, I allocate some memory and copy the contents and size to the structure... And when the current command is done, I check to see if I have any pending data to output and if so do a writef of the data to stdout. The linking in and unlinking of these structures is
protected using std::mutex.

So then tried building and running it on Linux, in my case Ubuntu 22.04. Appears to work fine when I disable the SEREMU stuff. But when I enable the SEREMU, the commands don't complete and it feels like the Teensy is locked up...

The linux read function, is pretty simple:
Code:
int rawhid_recv(int num, void *buf, int len, int timeout)
{
	hid_t *hid;
	int r;

	hid = get_hid(num);
	if (!hid || !hid->open) return -1;
	r = usb_interrupt_read(hid->usb, hid->ep_in, buf, len, timeout);
	if (r >= 0) return r;
	if (r == -110) return 0;  // timeout
	return -1;
}
Wondering if usb_interrupt_read is thread safe...
Looks like another rabbit hole!

Update with more information:
I connected up a T3.5 instead of T4.1, such that I am running at full speed and not high speed. Such that I could capture the USB with Saleae LA... My updated USB capture and HLA capture, I was able to verify that it looks like the T3.5 responded to my DIR/LS command with a full file list.
Code:
name	type	start_time	duration	pid	addr	endpoint	data	text
USB Data Packets HLA	USB	6.04612275	4.6602e-05	IN	0x16	0x01	 0xa 0xa 0x55 0x53 0x42 0x20 0x48 0x6f 0x73 0x74 0x20 0x52 0x61 0x77 0x48 0x69 0x64 0x20 0x46 0x69 0x6c 0x65 0x20 0x54 0x72 0x61 0x6e 0x73 0x66 0x65 0x72 0x73 0x20 0x52 0x65 0x6d 0x6f 0x74 0x65 0x28 0x73 0x6c 0x61 0x76 0x65 0x29 0x20 0x73 0x69 0x64 0x65 0xa 0x54 0x72 0x61 0x6e 0x73 0x66 0x65 0x72 0x20 0x73 0x69 0x7a	
USB Data Packets HLA	USB	6.0471227	4.66e-05	IN	0x16	0x01	 0x65 0x3a 0x20 0x36 0x34 0xa 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	11.4921018	4.6746e-05	OUT	0x16	0x04	 0xa 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	11.4931018	4.6596e-05	IN	0x16	0x03	 0xb 0x0 0x15 0x0 0xc 0x7d 0x0 0x0 0x1a 0x26 0x97 0x61 0x20 0xd4 0x66 0x61 0x0 0x78 0x2e 0x74 0x78 0x74 0x0 0x1f 0xd1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	11.4941018	4.6596e-05	IN	0x16	0x03	 0xb 0x0 0x14 0x0 0x1c 0x22 0x0 0x0 0x20 0x26 0x97 0x61 0x44 0xdf 0x59 0x61 0x0 0x46 0x53 0x2e 0x68 0x0 0x0 0x1f 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.4980979	4.676e-05	IN	0x16	0x03	 0xb 0x0 0x2a 0x0 0xf4 0xeb 0x4f 0x1 0xac 0xeb 0x9d 0x61 0x30 0xdb 0x84 0x61 0x0 0x54 0x34 0x4c 0x61 0x72 0x67 0x65 0x49 0x6e 0x64 0x65 0x78 0x65 0x64 0x54 0x65 0x73 0x74 0x66 0x69 0x6c 0x65 0x2e 0x74 0x78 0x74 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.4990979	4.676e-05	IN	0x16	0x03	 0xb 0x0 0x19 0x0 0x15 0x0 0x0 0x0 0x8 0x68 0xe3 0x77 0x8 0x68 0xe3 0x77 0x0 0x74 0x65 0x73 0x74 0x31 0x2e 0x74 0x78 0x74 0x0 0x65 0x78 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5000979	4.6588e-05	IN	0x16	0x03	 0xb 0x0 0x1c 0x0 0x0 0x0 0x0 0x0 0x9a 0xc7 0xe 0x64 0x0 0x0 0x0 0x0 0x0 0x6d 0x74 0x70 0x69 0x6e 0x64 0x65 0x78 0x2e 0x64 0x61 0x74 0x0 0x64 0x54 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5010979	4.661e-05	IN	0x16	0x03	 0xb 0x0 0x13 0x0 0x0 0x0 0x0 0x0 0x66 0x2a 0x97 0x61 0x66 0x2a 0x97 0x61 0x1 0x66 0x6f 0x6f 0x0 0x6e 0x64 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5020979	4.6608e-05	IN	0x16	0x03	 0xb 0x0 0x13 0x0 0x0 0x0 0x0 0x0 0x58 0x14 0xdb 0x61 0x58 0x14 0xdb 0x61 0x1 0x33 0x33 0x33 0x0 0x6e 0x64 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5030979	4.6606e-05	IN	0x16	0x03	 0xb 0x0 0x13 0x0 0x0 0x0 0x0 0x0 0x58 0x14 0xdb 0x61 0x58 0x14 0xdb 0x61 0x1 0x31 0x31 0x31 0x0 0x6e 0x64 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5040979	4.6604e-05	IN	0x16	0x03	 0xb 0x0 0x1d 0x0 0x0 0x0 0x0 0x0 0xda 0xad 0x2a 0x5c 0xda 0xad 0x2a 0x5c 0x1 0x53 0x6f 0x6d 0x65 0x5f 0x50 0x69 0x63 0x74 0x75 0x72 0x65 0x73 0x0 0x54 0x65 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5050978	4.6604e-05	IN	0x16	0x03	 0xb 0x0 0x21 0x0 0x36 0x84 0x3 0x0 0x18 0xc8 0xe 0x64 0x2e 0xa0 0xe3 0x61 0x0 0x61 0x6e 0x6e 0x69 0x65 0x33 0x20 0x2d 0x20 0x43 0x6f 0x70 0x79 0x2e 0x62 0x6d 0x70 0x0 0x66 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5060979	4.6602e-05	IN	0x16	0x03	 0xb 0x0 0x1a 0x0 0x36 0x84 0x3 0x0 0x18 0xc8 0xe 0x64 0x2e 0xa0 0xe3 0x61 0x0 0x61 0x6e 0x6e 0x69 0x65 0x33 0x2e 0x62 0x6d 0x70 0x0 0x70 0x79 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5070979	4.6602e-05	IN	0x16	0x03	 0xb 0x0 0x29 0x0 0x0 0x0 0x0 0x0 0xea 0x35 0xa8 0x62 0xec 0x35 0xa8 0x62 0x1 0x53 0x79 0x73 0x74 0x65 0x6d 0x20 0x56 0x6f 0x6c 0x75 0x6d 0x65 0x20 0x49 0x6e 0x66 0x6f 0x72 0x6d 0x61 0x74 0x69 0x6f 0x6e 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5080978	4.66e-05	IN	0x16	0x03	 0xb 0x0 0x23 0x0 0x8 0x97 0x3e 0x0 0x18 0xc8 0xe 0x64 0x6 0xbe 0x15 0x3e 0x0 0x44 0x53 0x43 0x30 0x30 0x30 0x34 0x30 0x20 0x2d 0x20 0x43 0x6f 0x70 0x79 0x2e 0x4a 0x50 0x47 0x0 0x61 0x74 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5090979	4.66e-05	IN	0x16	0x03	 0xb 0x0 0x1c 0x0 0x8 0x97 0x3e 0x0 0x1a 0xc8 0xe 0x64 0x6 0xbe 0x15 0x3e 0x0 0x44 0x53 0x43 0x30 0x30 0x30 0x34 0x30 0x2e 0x4a 0x50 0x47 0x0 0x70 0x79 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5100978	4.6596e-05	IN	0x16	0x03	 0xb 0x0 0x1c 0x0 0x9d 0xcc 0x0 0x0 0x1a 0xc8 0xe 0x64 0xee 0x92 0xe8 0x3e 0x0 0x44 0x53 0x43 0x30 0x30 0x34 0x34 0x35 0x2e 0x6a 0x70 0x67 0x0 0x70 0x79 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5110979	4.6596e-05	IN	0x16	0x03	 0xb 0x0 0x19 0x0 0x34 0x26 0x3 0x0 0x1a 0xc8 0xe 0x64 0x22 0xae 0x2a 0x5c 0x0 0x68 0x6f 0x75 0x73 0x65 0x2e 0x67 0x69 0x66 0x0 0x70 0x67 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5120978	4.6594e-05	IN	0x16	0x03	 0xb 0x0 0x21 0x0 0x36 0x84 0x3 0x0 0x1a 0xc8 0xe 0x64 0x2e 0xa0 0xe3 0x61 0x0 0x61 0x6e 0x6e 0x69 0x65 0x31 0x20 0x2d 0x20 0x43 0x6f 0x70 0x79 0x2e 0x62 0x6d 0x70 0x0 0x47 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5130978	4.6676e-05	IN	0x16	0x03	 0xb 0x0 0x1a 0x0 0x5a 0xfc 0x1 0x0 0x72 0xd 0x59 0x64 0x28 0xd 0x59 0x64 0x0 0x63 0x6f 0x79 0x6f 0x74 0x65 0x2e 0x6a 0x70 0x67 0x0 0x70 0x79 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5140979	4.659e-05	IN	0x16	0x03	 0xb 0x0 0x21 0x0 0x36 0x84 0x3 0x0 0x1a 0xc8 0xe 0x64 0x2e 0xa0 0xe3 0x61 0x0 0x61 0x6e 0x6e 0x69 0x65 0x32 0x20 0x2d 0x20 0x43 0x6f 0x70 0x79 0x2e 0x62 0x6d 0x70 0x0 0x47 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5150978	4.6612e-05	IN	0x16	0x03	 0xb 0x0 0x1a 0x0 0x8c 0x82 0x3 0x0 0x1a 0xc8 0xe 0x64 0x3e 0x47 0x53 0x64 0x0 0x61 0x6e 0x6e 0x69 0x65 0x32 0x2e 0x62 0x6d 0x70 0x0 0x70 0x79 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5160979	4.6608e-05	IN	0x16	0x03	 0xb 0x0 0x22 0x0 0x36 0x84 0x3 0x0 0x46 0xc8 0xe 0x64 0x5a 0xa0 0xe3 0x61 0x0 0x4c 0x61 0x69 0x69 0x6b 0x2d 0x69 0x73 0x2d 0x54 0x69 0x72 0x65 0x64 0x2e 0x62 0x6d 0x70 0x0 0x0 0x61 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5170978	4.6608e-05	IN	0x16	0x03	 0xb 0x0 0x1e 0x0 0x36 0x64 0x3 0x0 0x74 0xae 0x2a 0x5c 0x2e 0xa0 0xe3 0x61 0x0 0x61 0x6e 0x6e 0x69 0x65 0x31 0x5f 0x62 0x61 0x64 0x2e 0x62 0x6d 0x70 0x0 0x62 0x6d 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5180978	4.6606e-05	IN	0x16	0x03	 0xb 0x0 0x1c 0x0 0x9a 0x10 0x1b 0x0 0x48 0xc8 0xe 0x64 0x14 0xc4 0xc2 0x38 0x0 0x50 0x33 0x30 0x39 0x30 0x30 0x30 0x35 0x2e 0x4a 0x50 0x47 0x0 0x70 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5190978	4.6772e-05	IN	0x16	0x03	 0xb 0x0 0x23 0x0 0xd5 0xe 0x0 0x0 0x4a 0xc8 0xe 0x64 0xfc 0x8a 0xfe 0x3e 0x0 0x6a 0x30 0x32 0x33 0x34 0x36 0x39 0x36 0x20 0x2d 0x20 0x43 0x6f 0x70 0x79 0x2e 0x67 0x69 0x66 0x0 0x61 0x74 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.520098	4.677e-05	IN	0x16	0x03	 0xb 0x0 0x1c 0x0 0xd5 0xe 0x0 0x0 0x4a 0xc8 0xe 0x64 0xfc 0x8a 0xfe 0x3e 0x0 0x6a 0x30 0x32 0x33 0x34 0x36 0x39 0x36 0x2e 0x67 0x69 0x66 0x0 0x70 0x79 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5210978	4.6686e-05	IN	0x16	0x03	 0xb 0x0 0x1c 0x0 0xd7 0xbc 0x1e 0x0 0x5e 0xc8 0xe 0x64 0x9c 0xcd 0xdf 0x41 0x0 0x44 0x53 0x43 0x30 0x31 0x35 0x31 0x31 0x2e 0x4a 0x50 0x47 0x0 0x70 0x79 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5220978	4.66e-05	IN	0x16	0x03	 0xb 0x0 0x26 0x0 0x57 0x0 0x0 0x0 0xac 0x9c 0x54 0x64 0x14 0xbc 0x54 0x64 0x0 0x70 0x69 0x63 0x74 0x75 0x72 0x65 0x76 0x69 0x65 0x77 0x6f 0x70 0x74 0x69 0x6f 0x6e 0x73 0x2e 0x69 0x6e 0x69 0x0 0x6f 0x6e 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5230978	4.66e-05	IN	0x16	0x03	 0xb 0x0 0x1f 0x0 0xb6 0xf 0x67 0x0 0x74 0xc8 0xe 0x64 0xc4 0x8d 0xcf 0x42 0x0 0x53 0x68 0x61 0x72 0x6f 0x6e 0x20 0x42 0x61 0x72 0x6e 0x2e 0x62 0x6d 0x70 0x0 0x6e 0x73 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5240978	4.6598e-05	IN	0x16	0x03	 0xb 0x0 0x1f 0x0 0xb5 0xd4 0x0 0x0 0xe8 0xbe 0x54 0x64 0x9e 0xad 0x2a 0x5c 0x0 0x53 0x6d 0x61 0x6c 0x6c 0x2d 0x44 0x72 0x61 0x6b 0x65 0x2e 0x6a 0x70 0x67 0x0 0x6e 0x73 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5250979	4.6596e-05	IN	0x16	0x03	 0xb 0x0 0x19 0x0 0x0 0x0 0x0 0x0 0x7a 0xeb 0x55 0x64 0x7a 0xeb 0x55 0x64 0x1 0x46 0x4f 0x55 0x4e 0x44 0x2e 0x30 0x30 0x30 0x0 0x65 0x2e 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5260978	4.6594e-05	IN	0x16	0x03	 0xb 0x0 0x1a 0x0 0x36 0x84 0x3 0x0 0x88 0xf4 0x55 0x64 0x2e 0xa0 0xe3 0x61 0x0 0x41 0x6e 0x6e 0x69 0x65 0x31 0x2e 0x62 0x6d 0x70 0x0 0x2e 0x6a 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5270978	4.6594e-05	IN	0x16	0x03	 0xb 0x0 0x14 0x0 0x0 0x0 0x0 0x0 0x88 0x2b 0x67 0x64 0x88 0x2b 0x67 0x64 0x1 0x74 0x65 0x73 0x74 0x0 0x31 0x2e 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0	
USB Data Packets HLA	USB	12.5280977	4.6592e-05	IN	0x16	0x03	 0x7 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

The first ones I showed here to endpoint 1 are the output to SEREMU... The OUT to endpoint 4 is my command from Ubuntu to Teensy to give me a file list then lots of messages to end point 3, where the first byte 0x0b is information for a file... Then last one 0x07 is the response message which says, there are no more...

But the CMD window on Ubuntu shows error of timeout...
Code:
kurte@kurte-750-435st:~/github/RawHID/VS/RawHid/FileTransferTest/build_with_make$ ./FileTransferTest 
rawhid_open, max=2
device: vid=16C0, pic=0486, with 2 iface
  type 3, 0, 0
    IN endpoint 3 max: 64 attr: 3
    OUT endpoint 4 max: 64 attr: 3
  hid interface (generic)
  in use by driver "usbhid"
  descriptor, len=28
  tag: 4, val FFAB
  tag: 8, val 200
  type 3, 0, 0
    IN endpoint 1 max: 64 attr: 3
    OUT endpoint 2 max: 32 attr: 3
  hid interface (generic)
  in use by driver "usbhid"
  descriptor, len=33
  tag: 4, val FFC9
  tag: 8, val 4
found rawhid 2 devices
	(ffab, 200):Rawhid index 0 packet size:64
	(ffc9, 4):SEREMU index 1 packet size : 64
Command list
	dir(or ls) [optional pattern] - show directory files on remote FS
	cd <file pattern> - Change directory on remote FS
	pwd - Print remote working directory
	mkdir <name> - Create a directory on remote FS
	rmdir <name> - Remove a directory on remote FS
	del(rm) <name> - delete a file on FS
	download(or d) <remote file> <localfile spec> - download(Receive) file from From remote
	upload(or u) <local file spec> [remote file spec] - Upload file to remote
	reset - reboots the remote teensy
	scan - run the rawhid scan again
	exit - end the program
: <<<SEREMU >>>> [



USB Host RawHid File Transfers Remote(slave) side
Transfer size: 64
dir
]<<<< <SEREMU >>>>

>>> Thread Exit <<<
remote_dir called
x.txt                                C: 11/19/2021 04:20 M: 10/13/2021 12:42 32012
Receive *** failed ***
: (11, 42) FILEINFO
: (11, 26) FILEINFO
: (11, 33) FILEINFO
There was a pretty good gap of time, and then a few messages came through on my clear out the rawhid thread after the command failed
 
Last edited:
Very cool games you play @KurtE - reading when I get a chance. Finally got mower deck painted and running to finish that from 10 days ago and past time to start over ...

Was glad to see the found need and purpose for MUTEX to exclude overlap/collisions on processing to make progress.
 
Very cool games you play @KurtE - reading when I get a chance. Finally got mower deck painted and running to finish that from 10 days ago and past time to start over ...

Was glad to see the found need and purpose for MUTEX to exclude overlap/collisions on processing to make progress.
Good that you finished your mowing deck. I took the easy way out a couple of years ago and purchased a replacement deck. Still want to take the other one back in and have the whell welded back on.
It is a little fun to move around. I believe the deck weighs about 250 pounds.

Sort of done for now playing with the RAWHID stuff. The newer stuff works well with the PC. As for Ubunu, It does not appear to work to have two threads communicating with two different rawhids. There are notes in the linux hid code about it is still using libusb 0.1 and there are other solutions that are probably better. But I don't feel like figuring out those other USB libraries, as I don't use Ubuntu except for the occasional test session.
 
Yes, grass was getting ahead! Deck is 25 years old and parts half rusted away (note to self clean and repaint sooner than 25 years). Welder new to me and got the two needed brackets secured - one was off the other missing some contact. 9 ounces of JB Weld filled the swiss cheese of holes in the thinned top. Only 38" 2 blades but plenty heavy (prob not 100#?) and bulky and awkward to flip a dozen or so times :) At 25 years old new mower easier to find than replacement deck - and the rest of the thing is running fine - and I expect better than new for the abuse I give it :)

Glad the RawHid work showed promise for a 'fun' task. Would like to have played along but weeks behind on groundskeeping etc.

Nice if the CORES get any needed Beta trial update. Typing prior post #61 I wondered about using UDP on T_4.1 ethernet for sending out SPAM SPEW Debug messages to another Teensy - similar to last I was playing with here with QNEtherent Chat example ... not sure about getting 'round to try something with that - but might be fun to if so. Might be able to change your stream to RAM to xfer to UDP - unless I'm missing something? But quick test showed it can only do about 110K udp per second - seems less than USB Serial - and not sure of the overhead in that ...
 
Hello Kurt and co.
I'm currently using standard RawHid with Teensy 4.1, along with libusb on Windows, to drive a display with what seems like ~1fps. Exciting stuff.
I would like to try out RawHid512 as this would enabled full video streaming (PC side is complete), but it isn't quite clear what needs to be changed within Teensydunio. Which rawhid 512 files should I download and where should they go?
 
I again should mention that it is unclear if these changes will ever be pulled in. Most of the stuff was done about a year and a half ago. But keeping fingers crossed.

The 4 files I changed are shown in the one commit in the open Pull request:
https://github.com/PaulStoffregen/cores/pull/629
https://github.com/PaulStoffregen/cores/pull/629/commits/fc686eb08de5467e0dbcba9c3e5c43e90e64adae

Mine also is setup to have changes to boards.txt or boards.local.txt as mentioned in the readme of my rawhid project.
https://github.com/KurtE/RawHid


You might be able to do it. By simply hacking the definition of RAWHID within usb_desc.h As sort of mentioned on the RAWHID page.
https://www.pjrc.com/teensy/rawhid.html
Code:
#define RAWHID_TX_SIZE          64      // transmit packet size
#define RAWHID_TX_INTERVAL      2       // max # of ms between transmit packets
#define RAWHID_RX_SIZE          64      // receive packet size
#define RAWHID_RX_INTERVAL      8       // max # of ms between receive packets

By changing the TX and RX sizes to 512. But at least in some cases, this could fail. That is it will then try to configure both the High Speed descriptor for 512 byte packages as well s the Low speed packets to not sure what, That is it tries to set it to the RAWHID_TX_SIZE as one byte. Which probably truncates to 0... So for example if your Teensy hooks up through something that causes it to run in FULL SPEED (12mbs), it will likely fail.
 
I again should mention that it is unclear if these changes will ever be pulled in. Most of the stuff was done about a year and a half ago. But keeping fingers crossed.
...

Thank you for this! This absolutely works brilliantly and first time without any modification, too. Display is now responding in realtime.

This is the WIP but fully functioning code: https://github.com/MichaelMCE/TeensyRawHidDisplay
Caveat: It's using libusb0 to connect to the Teensy, not the HID API.
 
Something probably worth mentioning. In usb_desc.h there is the comment next to RAWHID_R/TX_INTERVAL (bInterval): "TODO: is this ok for 480 Mbit speed". My observation of this is that of all the Highspeed (480) devices that I have, they report a max packet size of 512 with a bInterval of 0.
I can report that with my setup, using a RAWHID_RX_INTERVAL of 0 with my RawHiDisplay, everything functions just as it would as if it were 1. Ie; it runs great, if a little smoother.
 
For those interested, I've managed to double the throughput by changing packet size to 1024 (RAWHID_RTX_SIZE_480), and increasing RX_NUM to 64 helps greatly. Throughput is now around 10MB per second. It's still along way off what should be possible for 480Mb HighSpeed USB, but it's getting there.

To clarify, that's from Host PC to Teensy 4.1 using usb_interrupt_write() as per the hint I found here.
 
May I make a suggestion for an additional method to the RawHid API? The purpose of this is to save an unnecessary memcpy() call. Instead of passing a buffer with which the received data is copied on to, supply an address pointer which the address of the received buffer is returned (to the user).

usb_rawhid.c :
Code:
int usb_rawhid_recv2 (void **buffer, uint32_t timeout)
{
	if (!usb_configuration)
		return -1; // usb not enumerated by host
	
	uint32_t wait_begin_at = systick_millis_count;
	uint32_t tail = rx_tail;
	
	while (1) {
		if (!usb_configuration) return -1; // usb not enumerated by host
		if (tail != rx_head) break;
		if ((systick_millis_count - wait_begin_at > timeout) || !timeout) {
			return 0;
		}
		yield();
	}

	if (++tail > RX_NUM) tail = 0;
	uint32_t i = rx_list[tail];
	rx_tail = tail;


	//memcpy(buffer,  rx_buffer + i * RAWHID_RX_SIZE_480, rx_packet_size);
	*buffer = (void*)(rx_buffer + (RAWHID_RX_SIZE_480 * i));
	
	rx_queue_transfer(i);
	return rx_packet_size;
}

And to the usb_rawhid_class definition:
usb_rawhid.h
Code:
public:
    ...

    int recv2 (void **buffer, uint16_t timeout) { return usb_rawhid_recv2(buffer, timeout); }

The addition of this method can save around 60k memcpy() calls, which equates to around ~30-32MByte of memory bandwidth p/s, with the USB port at full saturation.

Example; Consider transferring 800x480x2 frames at 40fps from Desktop to Teensy. That is 768,000 * 40 = 30MB per second, which is then 768,000 * 40 / 512 = 60k memcpy()'s (p/s) with packet length 512bytes. This is a considerable saving.

Thoughts?
 
I'm also interested in increasing the report size, in my case 128 bytes is enough, but a step-by-step guide on how to do it would be useful. And can I be sure it will work well?
 
Any success on MacOS
Sorry, I am not really setup to do Mac host development. My only Mac is a 12+ year old iMac.

Also, as this thread and corresponding pull request is something like three years old and has not been merged, my assumption is that it probably won’t be. Even though it sped up communication by something like 16 fold.
 
Back
Top