On Sun, May 31, 2020 at 12:41 PM Nathan Hartman
wrote:
> FWIW the build has become noticeably faster for me with latest master:
> 1m21s now. Before, the build consistently took about 1m50s. So that's
> 30 seconds saved. I build on Linux.
I just wanted to follow up on this and say that apparently
I just noticed that this conversation was occurring on
nu...@googlegroups.com. Not sure how we got there. Moving back to
dev@nuttx.apache.org where I thought we were all along.
There is one big difference. I have spoken (via email) with all of
the authors and copyright holders and each has
I got the SDMMC write to work as well. This is in non-DMA mode. I'm going
to work on the DMA mode next.
-adam
--
Adam Feuer
Hi, List,
I have been contemplating a NuttX-based Open Source project today and I
am interested in seeing if anyone is willing to participate or, even if
not, if anyone has any insights or recommendations that could be useful.
Basically, I am thinking of a NuttX tool to monitor the internal s
Hi, again,
I suppose the first question should be, "Is the FT245RL the correct
choice?" After all, it is only 8-bits wide and only USB 2.0. That
could limit the amount of instrumentation data passed to the host
because of data overrun or or it could alter the real-time behavior of
the targe
On Fri, Jun 12, 2020, 5:18 PM Gregory Nutt wrote:
> Hi, again,
>
> I suppose the first question should be, "Is the FT245RL the correct
> choice?" After all, it is only 8-bits wide and only USB 2.0. That could
> limit the amount of instrumentation data passed to the host because of data
> overru
Hi, Brennan,
I am inclined to stick with the FT245RL because the boards are cheap and
readily available. Conceptually, the basic solution does not depend on
the selection of hardware. The hardware does effect performance and
scalability, but I think the that the hardware selection is not crit
On Fri, Jun 12, 2020 at 6:22 PM Gregory Nutt wrote:
>
> Hi, Brennan,
>
> I am inclined to stick with the FT245RL because the boards are cheap and
> readily available. Conceptually, the basic solution does not depend on
> the selection of hardware. The hardware does effect performance and
> scalab
On Fri, Jun 12, 2020 at 6:52 PM Brennan Ashton
wrote:
> I am wondering if the host side could be implemented by leveraging
> sigrok and pulseview?
> https://sigrok.org/wiki/Protocol_decoder_HOWTO
>
Another source of inspiration (or integration?) could be kernelshark
https://kernelshark.org/Documen
