+/*
+ * Times are in milliseconds.
+ * - Delay after transmission was an option during initial development.
+ * Has become obsolete. Support remains because it doesn't harm.
+ * - Delay after flash is essential when writing multiple waveforms to
+ * the device. Not letting more idle time pass after successful write
+ * and reception of the "ok" response, and before the next write, will
+ * result in corrupted waveform storage in the device. The next wave
+ * that is written waveform will start with several hundred samples
+ * of all-one bits.
+ * - Timeout per receive attempt at the physical layer can be short.
+ * Experience suggests that 2ms are a good value. Reception ends when
+ * the response termination was seen. Or when no receive data became
+ * available within that per-attemt timeout, and no higher level total
+ * timeout was specified. Allow some slack for USB FS frame intervals.
+ * - Timeout for identify attempts at the logical level can be short.
+ * Captures of the microcontroller communication suggest that firmware
+ * responds immediately (within 2ms). So 10ms per identify attempt
+ * are plenty for successful communication, yet quick enough to not
+ * stall on missing peripherals.
+ * - Timeout for waveform upload/download needs to be huge. Textual
+ * presentation of 2k samples with 12 significant bits (0..4095 range)
+ * combined with 115200bps UART communication result in a 1s maximum
+ * transfer time per waveform. So 1.2s is a good value.
+ */
+#define DELAY_AFTER_SEND 0