KurtE
Senior Member+
@Paul - when I compile sometimes it is done and uploaded in ~5 secs. Other times the File save isn't shown done for 5 secs or 50 seconds to even start the compile. Maybe my SSD is funny? Or could it be T_ports?
I was going to ask when T_ports is queried and realized it is probably just before a connected T_sermon to T4 is set Offline - sure enough watching the title bar the compile doesn't start until T_sermon is [offline].
I think I've seen this sluggish behavior with no code changes - just doing Ctrl+U to get an Upload+Restart - but of course trying 20 Ctrl+U with no file save won't cause it now that I am looking at it - so maybe it is my SSD Teensy Drive. I suppose you'll know what the IDE does before T_ports disables Serial?
Note: I sometimes have found where I have done the start of a compile or upload and sometimes nothing really happens... Then I go back and do it again and it works...
Most of the time I attribute it to I must have done something wrong...
I have seen the if the processor dies and Serial monitor is in bad state, I need to close the window, before the build will happen.
@KurtE - wondering about the resiliency and independence of the systems [ SPI and _isr and Serial1.print and clock change ] of course I thought of something(s) I did before. RESULTS:: no problem.
@KurtE - looking at my Serial# printing under Fault problem (code used posted prior) - is there a reason or way to incorporate a fix for that in the code HardwareSerial? Where the FIFO gets empty but cannot summon an _ISR for normal operation - it would take an extra polling call perhaps a no_ISR_flush( with timeout ) to clear the buffer. As noted - when the buffer fills the current code does force out a char to FIFO to make room in the buffer - but that is not working in the general case to empty the buffer … under Fault. Perhaps the current .flush() code could have the interrupt level check added and when that is the case use code like I did to at least fill the FIFO once each call?
Yes the Hardware Serial code for both Teensy 3 and Teensy 4 for something like: Serial1.flush() will hang if it is running at a higher priority than the Serial port ISR or if interrupts are somehow disabled or ...
They both just do something like: (Serial1 T3.x/LC)
Code:
void serial_flush(void)
{
while (transmitting) yield(); // wait
}
So yest potentially the yield here could detect some of these conditions and do something like what the Serial1.write(x) does when the queue is full and it knows that the ISR will not be called (Note does not check for ISR's disabled....)...