Teensyduino 1.56 Beta #6

Status
Not open for further replies.
For what it is worth, several of us are in the process of integrating the MSC stuff into USBHost_t36 library. It will not make it into this release of Teensyduino as we had to cut this development cycle to get get a release out for these new Arduino releases.

Lots of details in the thread: https://forum.pjrc.com/threads/68139-Teensyduino-File-System-Integration-including-MTP-and-MSC


As for where: DBG_FAIL_MACRO
is/was defined, I am not sure.
But guessing somewhere within SDFat...

Probably ... SdFat\src\common\DebugMacros.h...

Edit: Note you were using 1.8.15... This was before SD library changed to be thin wrapper of SDFat.
 
Is CDC fixed?

In the PC-to-Teensy direction, a fix for received packet loss on MTP should fix a similar issue which probably has existed for CDC. This bug can only be triggered when the PC transmits much faster than Teensy is able to consume, which is a common case for MTP where speed of the media we're writing is the limiting factor.

In the Teensy-to-PC direction, 3 of the 5 issues present in 1.55 are fixed. The other 2 remain unresolved, and may never be fully solved by anything we can ever do on Teensy.

1: A bug in teensy_serialmon on Windows which could stall upon a very small packet after having already received a large amount of data (regardless of speed) was fixed.

2: Another bug in teensy_serialmon on Windows which could stall upon a very rare timing condition with WIN32 MsgWaitForMultipleObjects after an empty ReadFile was fixed.

3: A bug in teensy_serialmon on Linux which incorrectly tried to use CDC when HID seremu should be used was fixed.

4: All transmit data is intentionally discarded after a 120ms timeout of no response from the PC. Plans to make this timeout configurable did not happen for 1.56. This data discard mode is an intentional but (so far) undocumented feature. This feature can be avoided by use of Serial.availableForWrite() before transmitting, which puts the decision how to handle an unresponsive PC onto your program.

5: The Windows CDC driver buffers an incredible amount of incoming data and behaves very badly when its huge buffer overflows, due to data arriving faster than software on the PC consumes. It seems the only solution will be the throttle transmit speed, but no such speed limiting has been implemented in 1.56. So far, no way has been found to detect the speed software on Windows is actually consuming the data Teensy transmits, so any speed throttle will probably need to be user configurable. CDC's use of USB bulk transfer should do this automatically by the USB ACK-NYET-NAK protocol, and indeed it does at a hardware level between the device controller on Teensy and host controller on the PC, but the software driver on Window is buggy. At this time, the only workaround is to add delays or other timing code to your program to limit the rate is "spews" data Serial.
 
Status
Not open for further replies.
Back
Top