Hi,
I'd like to raise a topic here for discussion as I believe there may be a
more fundamental architectural issue in our utilisation of Nuttx for 4-wire
eMMC on a risc-based core and would like to get some help from the experts
:) NOTE: some initial discussions on this topic are captured here:
h
On Tue, May 30, 2023 at 8:07 PM Radek Pesina
wrote:
(snip)
*Configurations Tested:*
>
> For eMMC, I've tried optimising the menuconfig settings to improve it,
> including options such as below. However, the performance remains
> lacking:
>
>- Turning on CONFIG_MEMCPY_VIK gave slight impro
Hi Nathan,
Thanks for the reply. The round-robin interval was set to 200ms and
reducing it down to 10 marginally improved the transfer speed. Our current
code base and dev board is running a slightly quicker clock than what I
used when I measured 75KiB/s, and the current setup is transferring at
On Wed, May 31, 2023 at 3:11 AM Radek Pesina
wrote:
> Hi Nathan,
>
> Thanks for the reply. The round-robin interval was set to 200ms and
> reducing it down to 10 marginally improved the transfer speed. Our current
> code base and dev board is running a slightly quicker clock than what I
> used
, May 31, 2023 3:11 AM
To: dev@nuttx.apache.org
Subject: Re: SD and eMMC performance in Nuttx
Hi Nathan,
Thanks for the reply. The round-robin interval was set to 200ms and
reducing it down to 10 marginally improved the transfer speed. Our current
code base and dev board is running a slightly
This may be way off base but, have you tried reverting
https://github.com/apache/nuttx/commit/7312a553bbc40f3771c5d53ccded89bed7391f2a
It release the CPU but traded that for potentially quantized large delays
Yes, I would expect the up_udelay to be in error by about about 0.5 uS
(provided t
On Thu, Jun 1, 2023 at 12:35 PM Gregory Nutt wrote:
>
> > This may be way off base but, have you tried reverting
> >
> https://github.com/apache/nuttx/commit/7312a553bbc40f3771c5d53ccded89bed7391f2a
> >
> > It release the CPU but traded that for potentially quantized large delays
>
> Yes, I would
That would help when tickless mode is used. But what about tickful mode? I
guess the intent of 7312a553b was to avoid wasting processor cycles on busy
waiting, but if tickless isn't being used, perhaps busy waiting is
necessary here? It could choose between the two wait types at compile time
ba
Hi,
I've been busy on other tasks therefore haven't obtained a oscilloscope
trace yet, but one of my peers have performed some profiling on a different
micro and non-secure core, with the mxrt1064-evk:nsh configuration +
tickless and 100us tick rate:
nsh> dd if=/dev/zero of=/dev/null bs=4096 coun
