On 9/25/26 6:17 PM, Patrice CHOTARD wrote:
On 9/17/26 16:26, Marek Vasut wrote:
On 9/17/26 10:58 AM, Patrice Chotard wrote:
On STM32MP157C-DK2, when aborting the command "ums" using CTRL-C
it may take a while to get the control back on the console,
sometimes around 1 second.
By removing the if (k == 10) test, it increases the CTRL+C responsiveness.
Tested on STM32MP157C-DK board.
I still have two questions:
First, do you have actual timing figures here -- how long did it take from one
ctrl_c() invocation to the next ctrl_c() invocation. Use e.g. get_timer_us() to
time this.
Second, does this increase in break condition checking impact throughput of the
UMS ?
Hi Marek
Time between 2 ctrl_c() invocation is around 100us, way to fast in my opinion.
UMS throughput is slightly impacted :
before : 7.35 MB/s
after : 7.17 MB/s
A better balance can be obtained with the following update :
static int sleep_thread(struct fsg_common *common)
{
int rc = 0;
- int i = 0, k = 0;
+ int i = 0;
/* Wait until a signal arrives or we are woken up */
for (;;) {
if (common->thread_wakeup_needed)
break;
if (++i == 20000) {
busy_indicator();
i = 0;
- k++;
- }
- if (k == 10) {
/* Handle START-STOP UNIT */
if (common->eject)
return -EPIPE;
/* Handle CTRL+C */
if (ctrlc())
return -EPIPE;
/* Check cable connection */
if (!g_dnl_board_usb_cable_connected())
return -EIO;
-
- k = 0;
If k is not reset here, then the ++i==20000 above triggers only once ?
}
schedule();
dm_usb_gadget_handle_interrupts(udcdev);
}
Time between 2 ctrl_c() invocation is around 28ms.
UMS throughput is not impacted (still around 7.35 MB/s)
I will send a v2.
Patrice
--
Best regards,
Marek Vasut
