usbMIDI transmission error

I found something !


If I set the "Optimize" tool to "Fast" in Arduino, no transmission errors occur.
But if I set it to "Faster" or "Fastest" transmission errors occur.
CPU Speed is 528 MHz.

Can anybody confirm this ? Thanks :)

I was able to shorten the waiting time between the SysEx blocks without transmission errors :)
Wait time.jpg

Arduino: 528MHz, Optimize Fast, unmodified USB.c , no transmission errors in Win10
[FONT=&quot]Arduino: 720MHz, Optimize Fast, unmodified USB.c , no transmission errors in Win10
[/FONT][FONT=&quot]Arduino: 816MHz, Optimize Fast, unmodified USB.c , no transmission errors in Win10[/FONT]
 
Last edited:
Rolfdegen said:
I found something !


If I set the "Optimize" tool to "Fast" in Arduino, no transmission errors occur.
But if I set it to "Faster" or "Fastest" transmission errors occur.
CPU Speed is 528 MHz.

Can anybody confirm this ? Thanks :)

I was able to shorten the waiting time between the SysEx blocks without transmission errors :)
View attachment 31353

Arduino: 528MHz, Optimize Fast, unmodified USB.c , no transmission errors in Win10
[FONT=&quot]Arduino: 720MHz, Optimize Fast, unmodified USB.c , no transmission errors in Win10
[/FONT][FONT=&quot]Arduino: 816MHz, Optimize Fast, unmodified USB.c , no transmission errors in Win10[/FONT]
Click to expand...

No matter what clock speed (including 528Mhz) or compiler speed optimization I select, I don't seem to be getting errors. And even with delays reduced form 130 to 2ms. All with unmodified teensyduino 1.58 usb.c.
 
Arduino behavior is very strange :confused:

Regardless of the speed setting, I switched Optimize from "Fast" to "Faster" and immediately noticed transmission errors.
Please test again carefully. Completely uninstall and reinstall Arduino and Teensyduino.
 
Fast, faster, and fastest makes no difference for me, I see no errors. This is with a fresh uninstall/reinstall done a few days ago, and no changes to the T4 core files since. As I mentioned, I did install Arduino V2.1 initially before updating teensyduino from 1.56 to 1.58, but couldn't get it to work with my project, so I uninstalled it and installed 1.8.19. I think I do remember seeing a notice during the V2.1 install about a USB driver being updated, but can't be sure.
 
Using unmodified Arduino 1.8.19/Teensyduino 1.58/Windows 10.
Teensy 4.0 @ 600MHz, USBtype: "Serial + MIDI" & USBtype: "MIDI".
Compiler options: fast, faster, & fastest.
Code from message #100.
6000 messages for each combination of USB type and compiler option, so 36000 messages sent.
Result: no errors.

Paul
 
Last edited:
OK. The test result with unmodified Arduino 1.8.19 / Teensyduino 1.58 / Windows 10 very nice. No error :eek::eek::eek:

To everyone who helped. Thanks very much. Special thanks to Paul for his great support.

Greetings from germany. Rolf
 
Well, that leaves us with the issue for the Teensy 3.2.
However, by changing the compiler option from the default Optimize: "Faster" to Optimize: "Fast", I did not see any error with 24K messages sent!
For reference: Arduino 1.8.19/Teensyduino 1.58/Windows 10. Teensy 3.2 @ 96MHz, USBtype: "Serial + MIDI". Code from message #100.

By the way, useful setting in SendSX for quickly checking whether all messages are received correctly:

Untitled.png

Paul
 
Here a screendump with the default Optimize: "Faster" setting:

Untitled.png

1 to 5 messages truncated 3 bytes short with every 600 messages sent.

Paul
 
Last edited:
While searching for a clue about the difference between the "Fast" and "Faster" compiler options, I noticed that when I changed the MESSAGESIZE from 212 to 512 or 1024, the "Faster" option did not give errors [while MESSAGESIZE 212 still does at "Faster"].
Using the "Fast" option, all 3 message sizes worked fine.

Untitled.png Untitled.png Untitled.png

I'm a bit lost and do not really know where to search from here.

Paul
 
PaulS said:
While searching for a clue about the difference between the "Fast" and "Faster" compiler options, I noticed that when I changed the MESSAGESIZE from 212 to 512 or 1024, the "Faster" option did not give errors [while MESSAGESIZE 212 still does at "Faster"].
Using the "Fast" option, all 3 message sizes worked fine.

View attachment 31360 View attachment 31362 View attachment 31361

I'm a bit lost and do not really know where to search from here.

Paul
Click to expand...

Maybe try the version of usb_midi.c that I listed in message #51 instead of the T3 core file? No need to add any code in the user program.
 

Attachments

  • usb_midi.c
    15.6 KB · Views: 136
rvh said:
Maybe try the version of usb_midi.c that I listed in message #51 instead of the T3 core file? No need to add any code in the user program.
Click to expand...

I did and there were no more errors with MESSAGESIZE 212 and the "Faster" option.
For sanity, I checked all combinations of messagesizes 212/512/1024 and options Fast/Faster. No errors.

Thanks,
Paul
 
PaulStoffregen said:
I'm really hoping @Defragster and others who use Windows can give this (code in msg #89, details in msg #93) a run with their machines.
Click to expand...

Searching for another post on PSRAM LOOKAHEAD setting - and saw I missed this post.

Is there still an open question for Windows and sendSX? THIS bome.com/products/sendsx ???

I was wondering about the PSRAM read ahead and the current PSRAM clock speed to test against a just posted sketch:
Code: 
EXTMEM Memory Test, 8 Mbyte
 CCM_CBCMR=B5AE8304 ([B]88.0 MHz[/B])
 
Using this posted code on a T_4.1 with IDE 1.8.19 on Win 11 PRO with TD 1.59.b2 NOT ALTERED { on a just built i7-13700K }
Saw that the above linked SendSX was the right one and reading code I saw I needed to GND pin 2 for some action, and set MIDI IN to Teensy.

I see no errors with this code below. or the Post #89 code that has the flush()?

Ran with "#define MESSAGESIZE 212" and bumped to 512 for both pieces and no errors indicated ... for some time then some of these intermittent at 512 with p#89 code:
Code: 
...
F0 00 00 05 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 00 00
F0
F0 00 00 02 0D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 00 00 00 00 00 00 00 00 00 00 00 00 F7
...

Long run of p#89 and code below w/212 - so far nothing missing observed - at least 3 minutes each?

Missed some pages - and posts - if there is more to repro I'll look for follow up ...

rvh said:
Here is the code from #89 again, but with the flush command already commented out, so you can use it as is.

Code: 
#define MESSAGESIZE  212

void setup() {
  pinMode(2, INPUT_PULLUP);
  delay(1); // allow time for pullup to bring pin 2 high
}

void delayMicroseconds_WhileDiscardingInput(unsigned int usec) {
  elapsedMicros t = 0;
  while (t < usec) {
    usbMIDI.read(); // read and ignore incoming USB MIDI
  }
}

void loop() {
  if (!digitalRead(2)) {
    byte patchData[MESSAGESIZE] = {0};
    patchData[0] = 0xF0;
    patchData[MESSAGESIZE-1] = 0xF7;

    for (int P = 0; P < 100; P++) {
      for (int i = 0; i < 6; i++) {
        patchData[3] = i;
        patchData[4] = P;
        usbMIDI.sendSysEx(MESSAGESIZE, patchData, true);
        //usb_midi_flush_output();
        delayMicroseconds_WhileDiscardingInput(5000);   
      }
      delayMicroseconds_WhileDiscardingInput(5000);
    }
  }  
  usbMIDI.read();
}


When I run this on my system (Win10 pro), I get errors in SXsend like this:
...
Click to expand...
 
As far as SendSX - let me know if there is a test I can run with proper params and proper base code TD version and any CORES edits to test on this quick Win 11 i7.

jmarsh said:
PSRAM read-ahead (prefetching) is currently not enabled...
Click to expand...
Thanks - found thread - posted there with test results - good then odd????
 
defragster said:
As far as SendSX - let me know if there is a test I can run with proper params and proper base code TD version and any CORES edits to test on this quick Win 11 i7.
Click to expand...

Updating from Teensyduino 1.56 to 1.58 was the key to fixing this issue for T4.x on Win10. With 1.56 the work around was to modify a core file (as described at the start of this thread) and add a flush command in the user code. With 1.58 this was no longer needed.

As far as I know the issue has not been fixed for T3.x and there is a slightly different workaround that I described. But given T3.x is rapidly becoming unavailable, it may not be worth spending any more time on that.
 
rvh said:
Updating from Teensyduino 1.56 to 1.58 was the key to fixing this issue for T4.x on Win10. With 1.56 the work around was to modify a core file (as described at the start of this thread) and add a flush command in the user code. With 1.58 this was no longer needed.

As far as I know the issue has not been fixed for T3.x and there is a slightly different workaround that I described. But given T3.x is rapidly becoming unavailable, it may not be worth spending any more time on that.
Click to expand...

Good. I scanned some of the posts - but missed the p#97 from Paul - not seeing it was then 2 pages back.
There was the one glitch of messages at 512 - not sure what is to be expected - maybe the one sketch is better for 512 byte messages.

Ideally the nicer T_4.0 && T_4.1 can replace the T_3.2 - though if they ever ship PJRC the chips again they won't be gone forever.
 
You must log in or register to reply here.
Back
Top