Teensyduino 1.56 Beta #1

Status
Not open for further replies.
Eh, no, that will not help much.. it may reduce the pobability for races (if existing) but will not slow down..
 
Why not have a variable which can be set by the user.

I don't know call it SerialUartSpeed, let's say with a value from 0..255.
At 255 (default) the Serial Usb goes at it's fastest as at the moment.

It is slowed down dependent upon the value of SerialUartSpeed right down to let's say 12mb/s for a value of 0.

Alternatively you could call it SerialUartThrottle, with 0 (default) being the fastest and 255 being the slowest speed.

That was the UNSAID conclusion from last post #271 ... : Some method of explicit baseline behavior control : BITBUCKET or RATELIMIT


Hm. Not tried - does it help to just make the timer slower? (That would be the perfect place to create a variable speed - IF that works)
Tim? Can you test?

edit:
It would be a opportunity to add different timouts, perhaps.. (see the "todo")
Code:
// TODO: should be 2 different timeouts, high speed (480) vs full speed (12)
#define TRANSMIT_FLUSH_TIMEOUT    75   /* in microseconds */

But again, I have no idea if that is enough. I'd try a pretty high value first, to confirm..

@FrankB - quick - look not sure what to do with the current value of 75? That triggers usb_serial_flush_callback() - which does nothing when "if (tx_available == 0) return;"

Quick test with "#define TRANSMIT_FLUSH_TIMEOUT 1575" did no change? Also with 3575?

There must be some better way to wait? I'll give this a try in some few hours. May not be making edit to right CORE file ...


Spent 3 hours yesterday with neighbor and helper getting to a replacement roof on shed to empty that cord of wood into - this morning is the roof completion ... in the rain. Gotta run ...
 
Nothing. If you read the my following post: I said it will not help.

Better get your roof done:) That's more important.

Missed the follow up post - it was on Next Page and I just did a refresh before the reply. So I confirmed it doesn't help :)

Roof Done! Time for cleanup and then after lunch ... a TON of wood to move from the pickup ...
 
I have a couple ideas about possible ways to detect if the USB host is (very likely) Windows. Will explore after I've merged audio stuff, which is after bootloader stuff I'm doing now, and somewhere squeezing in some time to play with MTP / MSC / FS.


And to specifically answer this.

Why not have a variable which can be set by the user.

This is more a matter of design philosophy or human usability than pure engineering. The more ways a thing is configurable, the more complex it is to understand, and to fully document. The value and cost of sorts of things are a matter of opinion more than objective fact. I personally believe extra configuration, especially as user-level APIs, carries a cost in complexity. No single item is extremely expensive, but taken as a whole, too much configurable stuff makes a system difficult to learn & use, so my general preference is (usually) to find a way to avoid extra APIs and settings users need to learn.

This may indeed become a user configurable setting. It might be a define, it might have an API, or it might just be buried in the code without any way to change short of editing the code. Difficult to know at this point...
 
Last edited:
I have a couple ideas about possible ways to detect if the USB host is (very likely) Windows. Will explore after I've merged audio stuff, which is after bootloader stuff I'm doing now, and somewhere squeezing in some time to play with MTP / MSC / FS.

please give the "mtp.disk serial" mode including a recognized PID value a serious consideration.
 
Follow up to p#271.

To the serialtest2.exe added the read and dump bytes loop at the start - hoping to clear mishandled buffers. LOTS of stored data from Windows. Sometimes still gets lots of bad buffer data where newline isn't placed properly after expected character SZ38.

Here is a startup showing how much data can be read and ignored - and still get 'broken lines'
Code:
C:\T_Drive\tCode\pjrc_latency_test\FB_SerTest>SerialTest2 COM7 SZ38
Port: COM7
After start, you'll probably see some garbage. Things will normalize after a few seconds.
[B]Waiting...First discard 115353600 Bytes.        Discarded 230752256 total Bytes.[/B]
Start.

        X_Lines-Delta: 26227 ::52 bytes Received: 3803648, B in, 199358, us = ,152.64, Mbps: 1411FC00
.
Lines-Delta: 100096. Received: 3803648, B in, 130103, us = ,233.89, Mbps: 14138300
        stats: 100K=1 less=0 repeated 0 rmax=2000000
..............
        X_Lines-Delta: 42587 ::40 bytes Received:  14298B5B<6<<<>>>___[[[]]]---{{{}}}___!

        X_Lines-Delta: 57481 ::52 bytes Received: 3803648, B in, 138622, us = ,219.51, Mbps: 142A6C00

Code like this was in before when things went bad - but removed as it didn't help get SYNC:
Code:
unsigned long rr=0;
  do {
    r = read_port(port, buf, sizeof buf);
    rr+=r;
  } while (  r >  sizeof(buf) -1500);
  printf("First discard %lu Bytes.\t", rr );
  do {
    r = read_port(port, buf, sizeof buf);
    rr+=r;
  } while (  r >  sizeof(buf) -100);
  printf("Discarded %lu total Bytes.\n", rr );

Once it gets sync'd - it generally runs fine - but when pending data is backed up - it is really deep ... or at least comes in nearly as fast as it is read as that takes some long time to purge the buffer backlog.

When the EXE starts just as the T_4.1 does - the discard is ZERO - then there is often a large number of misses with "X_Lines..."

Franks started the buffer at 1MB - I bumped to 2MB in the EXE. Dropping that to only 200K is worse:
Code:
Waiting...First discard 22970368 Bytes. Discarded 1623267328 total Bytes.

and 

Waiting...First discard 694393344 Bytes.        Discarded 1192507904 total Bytes.

Discarded 1,192,507,904 total Bytes. is a big number - but it sat a long time in the do(){}while; above - which lets ever more data come in.

Apparently an EXE can't get over 2MB in a buffer - at least not 3 or 4MB.
 
Example sketch on this thread: Jitter-free-square-wave-doubler-with-TeensyTimerTool

Showed no SerMon garbage - but excessive output 2000 or 20K .prints per second ( even made sparse ) ended up dropping loop count and caused interrupt service issues ( just 6 cycles in 600M ) - but that cascaded to more output logging the cycle mismatch.

So no perfect solution - slowing down USB writes to assure it is not corrupted - breaks the sketch function. As fast as the USB output is, it takes time already ...
 
Serialtest incidental update. It was noted that 'unblanking' screens after time away caused broken groups where it is running perfectly fine steady state before and after blanking.

When the PC unblanks the screen Teensy.exe / Verbose logs these events appear showing systemic change of some sort:
Code:
...
00:38:53.165 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
00:38:53.167 (ports 2): nothing new, skipping HID & Ports enum
[U]08:04:32.621[/U] (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:04:32.623 (ports 2): nothing new, skipping HID & Ports enum
08:04:33.387 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:04:33.388 (ports 2): nothing new, skipping HID & Ports enum
08:04:33.497 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:04:33.499 (ports 2): nothing new, skipping HID & Ports enum
08:04:33.791 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:04:33.793 (ports 2): nothing new, skipping HID & Ports enum
08:05:00.568 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:05:00.569 (ports 2): nothing new, skipping HID & Ports enum
08:05:00.899 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:05:00.900 (ports 2): nothing new, skipping HID & Ports enum
08:05:01.229 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:05:01.230 (ports 2): nothing new, skipping HID & Ports enum
08:05:16.283 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:05:16.284 (ports 2): nothing new, skipping HID & Ports enum
[U]08:27:08.070[/U] (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:27:08.072 (ports 2): nothing new, skipping HID & Ports enum
[U]08:43:42.807[/U] (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:43:42.809 (ports 2): nothing new, skipping HID & Ports enum
08:43:43.693 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:43:43.694 (ports 2): nothing new, skipping HID & Ports enum
08:43:43.803 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:43:43.804 (ports 2): nothing new, skipping HID & Ports enum
08:43:43.918 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:43:43.919 (ports 2): nothing new, skipping HID & Ports enum
08:44:26.601 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:44:26.602 (ports 2): nothing new, skipping HID & Ports enum
 
Status
Not open for further replies.
Back
Top