sergiotarxz/nuttx
sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

This is based on a patch by Taras Drozdovsky. Basically, the delay that was added during the integration of the CDC/ACM host driver was interfering with streaming audio. That delay was put there to prevent build endpoints from hogging the system bandwidth. So what do we do? Do we hog the bandwidth or do we insert arbitrarity delays. I think both ideas such.

Browse Source
This commit is contained in:
Gregory Nutt 2017-05-21 14:28:29 -06:00
parent 4ab2a3661e
commit 7ffbb704d6
3 changed files with 48 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
arch/arm/src/stm32/stm32_otgfshost.c
View File

@ -1952,14 +1952,25 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx,
delay = 1000; delay = 1000;
} }
/* Wait for the next polling interval. /* Wait for the next polling interval. For interrupt and
* isochronous endpoints, this is necessaryto assure the
* polling interval. It is used in other cases only to
* prevent the polling from consuming too much CPU bandwith.
* *
* REVISIT: This delay could require more resolution than * Small delays could require more resolution than is provided
* is provided by the system timer. In that case, the * by the system timer. For example, if the system timer
* delay could be significantly longer than required. * resolution is 10MS, then usleep(1000) will actually request
* a delay 20MS (due to both quantization and rounding).
*
* REVISIT: So which is better? To ignore tiny delays and
* hog the system bandwidth? Or to wait for an excessive
* amount and destroy system throughput?
*/ */
usleep(delay); if (delay > CONFIG_USEC_PER_TICK)
{
usleep(delay - CONFIG_USEC_PER_TICK);
}
} }
} }
else else

21
arch/arm/src/stm32/stm32_otghshost.c
View File

@ -1957,14 +1957,25 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx,
delay = 1000; delay = 1000;
} }
/* Wait for the next polling interval. /* Wait for the next polling interval. For interrupt and
* isochronous endpoints, this is necessaryto assure the
* polling interval. It is used in other cases only to
* prevent the polling from consuming too much CPU bandwith.
* *
* REVISIT: This delay could require more resolution than * Small delays could require more resolution than is provided
* is provided by the system timer. In that case, the * by the system timer. For example, if the system timer
* delay could be significantly longer than required. * resolution is 10MS, then usleep(1000) will actually request
* a delay 20MS (due to both quantization and rounding).
*
* REVISIT: So which is better? To ignore tiny delays and
* hog the system bandwidth? Or to wait for an excessive
* amount and destroy system throughput?
*/ */
usleep(delay); if (delay > CONFIG_USEC_PER_TICK)
{
usleep(delay - CONFIG_USEC_PER_TICK);
}
} }
} }
else else

21
arch/arm/src/stm32f7/stm32_otghost.c
View File

@ -1951,14 +1951,25 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx,
delay = 1000; delay = 1000;
} }
/* Wait for the next polling interval. /* Wait for the next polling interval. For interrupt and
* isochronous endpoints, this is necessaryto assure the
* polling interval. It is used in other cases only to
* prevent the polling from consuming too much CPU bandwith.
* *
* REVISIT: This delay could require more resolution than * Small delays could require more resolution than is provided
* is provided by the system timer. In that case, the * by the system timer. For example, if the system timer
* delay could be significantly longer than required. * resolution is 10MS, then usleep(1000) will actually request
* a delay 20MS (due to both quantization and rounding).
*
* REVISIT: So which is better? To ignore tiny delays and
* hog the system bandwidth? Or to wait for an excessive
* amount and destroy system throughput?
*/ */
usleep(delay); if (delay > CONFIG_USEC_PER_TICK)
{
usleep(delay - CONFIG_USEC_PER_TICK);
}
} }
} }
else else