You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Brennan Ashton <ba...@brennanashton.com> on 2020/06/13 00:27:34 UTC
Re: [nuttx] Re: NXView
On Fri, Jun 12, 2020, 5:18 PM Gregory Nutt <sp...@gmail.com> 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
> overrun or or it could alter the real-time behavior of the target.
> Ideally, the instrumentation should involve minimal overhead and the
> behavior the real time system should be the same with or without the
> instrumentation enabled. Otherwise, such a tool would not be a proper
> diagnostic tool.
>
> I considered some PCIe parallel data acquisition devices, but did not see
> a good match. PCIe would be hot, howeer.
>
> I also looked at FTDI FT60xx devices, but these seem so camera focused
> that it was not completely clear to me that these could be usable. But I
> am a mostly a software guy. Perhaps someone out there with better
> knowledge of these devices could help out.
>
> The older FT600x, for example, has a 16-bits wide FIFO (pretty much
> optimal for most MCUs) and has a USB 3.0 interface to the host PC. Using
> such a camera-oriented device is less obvious to me than the more general
> FT245RL. Perhaps that is only because of the camera-oriented language used
> in the data sheets?
>
> If you know something about these options, I would like to hear from you.
>
> Greg
>
If you want high-speed io to USB the FX3 is probably one of the best bets.
You see it frequently used on logic analyser and software defined radio
boards between the USB and the FPGA.
https://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-controller
Somewhat related but have in the past modified the firmware on this for
some custom debugging. https://1bitsquared.com/products/black-magic-probe
--Brennan
>
Re: [nuttx] Re: NXView
Posted by Gregory Nutt <sp...@gmail.com>.
> If you want high-speed io to USB the FX3 is probably one of the best bets.
> You see it frequently used on logic analyser and software defined radio
> boards between the USB and the FPGA.
>
> https://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-controller
There are several EZ-USB FX2LP boards on eBay at $4-6. That is only USB
2.0 but might be a good option -- but I am up to speed with the FT245RL.
I actually think that USB 2.0 full speed at 480 Mbps would be adequate
in most cases. We would probably only realize 300Mbps or so, but I
think even transferring at that rate could impact real time
performance. The FT60x with USB 3.0 will do 54Gbps (actual). I imagine
that the EZ-USB FX3 would be similar. But that rate may not be
necessary. One would have to collect some measurements to really
understand (a) the required throughput, (b) the MCU overhead for making
the transfers, and (c) the effect on real-time performance.
> Why not use the ETM?
The solution should not conceptually depend on any particular
transport. Any transport that can meet the data rate requirements
(whatever those are) and interferes only minimally with CPU performance
could be considered. So I suppose that ETM might also be a possibility
on many ARMs, but not a general solution that I would personally be
interested in.
Re: [nuttx] Re: NXView
Posted by Petr Buchta <cz...@googlemail.com.INVALID>.
My two cents... I would definitely make use of some existing frontend for
tracing visualisation. Something like this in case of lttng -
https://lttng.org/viewers/
Trace Compass seems to be a fairly complete solution for visualisation -
https://www.eclipse.org/tracecompass
Petr
On Sat, Jun 13, 2020, 4:13 AM Brennan Ashton <ba...@brennanashton.com>
wrote:
> On Fri, Jun 12, 2020 at 6:52 PM Brennan Ashton
> <ba...@brennanashton.com> 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/Documentation.html
>
> which is a frontend for ftrace
> https://www.kernel.org/doc/Documentation/trace/ftrace.txt
>
> --Brennan
>
Re: [nuttx] Re: NXView
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Fri, Jun 12, 2020 at 6:52 PM Brennan Ashton
<ba...@brennanashton.com> 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/Documentation.html
which is a frontend for ftrace
https://www.kernel.org/doc/Documentation/trace/ftrace.txt
--Brennan
Re: [nuttx] Re: NXView
Posted by Gregory Nutt <sp...@gmail.com>.
On 6/13/2020 3:25 PM, Brennan Ashton wrote:
> On Sat, Jun 13, 2020 at 1:56 PM Gregory Nutt <sp...@gmail.com> wrote:
>> The problem is that in the context of the OS instrumentation call-outs,
>> we can do no driver operations. With the FT245R, it could do writes to
>> a memory-mapped FIFO. Most of the FX2LP modes are more complex. There
>> is a slave FIFO, but I don't fully understand that yet.
> If you want to just stream data to the FIFO then yes that is probably
> the right way to go.
> This app note shows the basic setup
> https://www.cypress.com/file/44551/download
> You have up-to 16 data lines that map to the fifo
> FLAGA/D show the status of the FIFO so probably can be ignored if you
> are OK with losing data
> SLOE probably can be always asserted
> SLRD/WR can also be fixed value since we won't be reading
> FIFOADDR is just selecting which bank/endpoint you are writing to, so
> once again likely can be hard coded.
>
> I don't think I have a dev board for this anymore, last design I did
> with this was a few years back, but I would be open to tracking one
> down if this is a path you want to go.
>
> --Brennan
The FT232H would be another option.
Greg
Re: [nuttx] Re: NXView
Posted by Gregory Nutt <sp...@gmail.com>.
> You sucked me in. It was only $8 to get one here tomorrow... and I am
> not sure I can find another use for it even if this does not work out.
>
> For those following along, you can find the board I am talking about
> on ebay, amazon, etc.. by looking for "EX-USB FX2LP"
I ordered a couple of those from China too. But I won't get them here
in Costa Rica until August. Looks like you will be the trailblazer.
Re: [nuttx] Re: NXView
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Sat, Jun 13, 2020 at 2:25 PM Brennan Ashton
<ba...@brennanashton.com> wrote:
>
> On Sat, Jun 13, 2020 at 1:56 PM Gregory Nutt <sp...@gmail.com> wrote:
> > The problem is that in the context of the OS instrumentation call-outs,
> > we can do no driver operations. With the FT245R, it could do writes to
> > a memory-mapped FIFO. Most of the FX2LP modes are more complex. There
> > is a slave FIFO, but I don't fully understand that yet.
>
> If you want to just stream data to the FIFO then yes that is probably
> the right way to go.
> This app note shows the basic setup
> https://www.cypress.com/file/44551/download
> You have up-to 16 data lines that map to the fifo
> FLAGA/D show the status of the FIFO so probably can be ignored if you
> are OK with losing data
> SLOE probably can be always asserted
> SLRD/WR can also be fixed value since we won't be reading
> FIFOADDR is just selecting which bank/endpoint you are writing to, so
> once again likely can be hard coded.
>
> I don't think I have a dev board for this anymore, last design I did
> with this was a few years back, but I would be open to tracking one
> down if this is a path you want to go.
>
> --Brennan
You sucked me in. It was only $8 to get one here tomorrow... and I am
not sure I can find another use for it even if this does not work out.
For those following along, you can find the board I am talking about
on ebay, amazon, etc.. by looking for "EX-USB FX2LP"
--Brennan
Re: [nuttx] Re: NXView
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Sat, Jun 13, 2020 at 1:56 PM Gregory Nutt <sp...@gmail.com> wrote:
> The problem is that in the context of the OS instrumentation call-outs,
> we can do no driver operations. With the FT245R, it could do writes to
> a memory-mapped FIFO. Most of the FX2LP modes are more complex. There
> is a slave FIFO, but I don't fully understand that yet.
If you want to just stream data to the FIFO then yes that is probably
the right way to go.
This app note shows the basic setup
https://www.cypress.com/file/44551/download
You have up-to 16 data lines that map to the fifo
FLAGA/D show the status of the FIFO so probably can be ignored if you
are OK with losing data
SLOE probably can be always asserted
SLRD/WR can also be fixed value since we won't be reading
FIFOADDR is just selecting which bank/endpoint you are writing to, so
once again likely can be hard coded.
I don't think I have a dev board for this anymore, last design I did
with this was a few years back, but I would be open to tracking one
down if this is a path you want to go.
--Brennan
Re: [nuttx] Re: NXView
Posted by Gregory Nutt <sp...@gmail.com>.
> Makes total sense if it provides enough bandwidth. There are some
> other options that are based off of the FX2 USB2.0 chip that are
> common in low cost ($10) 8ch 25MHZ logic analyzers as well. As you
> said it's a block with a few input pins, FIFO, and a usb interface, so
> if it works, sounds good.
Well, I just discovered that although the FT246 claims to be USB 2.0, it
does not support high speed. Only 12Mbps (full speed). So that would be
a bad choice.
The problem is that in the context of the OS instrumentation call-outs,
we can do no driver operations. With the FT245R, it could do writes to
a memory-mapped FIFO. Most of the FX2LP modes are more complex. There
is a slave FIFO, but I don't fully understand that yet.
Re: [nuttx] Re: NXView
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Fri, Jun 12, 2020 at 6:22 PM Gregory Nutt <sp...@gmail.com> 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
> scalability, but I think the that the hardware selection is not critical
> for initial development.
>
> I can get the RT245RL board for ~$11 USD on eBay an adequate
> STM32F103/F407 for $10-15 from China. Ready availability, inexpensive
> hardware (albeit low performance) would probably be a better starting
> point.. unless you can point to a competing low cost OTS solution. The
> combined cost is around $20 and meets all of the initial development
> requirements. I would have to have to have strong reason to deviate
> from that. But I could be very easily dissuaded with an alternative OTS
> hardware proposal at similar cost.
>
> Nothing I have said precludes that alternative, higher performance
> implementation. At a block diagram level, it does not matter. It is
> just a matter of drivers on both sides.
>
> Greg
Makes total sense if it provides enough bandwidth. There are some
other options that are based off of the FX2 USB2.0 chip that are
common in low cost ($10) 8ch 25MHZ logic analyzers as well. As you
said it's a block with a few input pins, FIFO, and a usb interface, so
if it works, sounds good.
I am wondering if the host side could be implemented by leveraging
sigrok and pulseview?
https://sigrok.org/wiki/Protocol_decoder_HOWTO
One of the advantages would be the ability to easily overlay other
datasource as you already have some major chunks built?
Had you put much thought into what the target side would look like
from an interface?
Not trying to dissuade from building something new :)
Here is an example using sigrok+pulseview and a $15 logic analyzer
https://learn.sparkfun.com/tutorials/using-the-usb-logic-analyzer-with-sigrok-pulseview/all
--Brennan
Re: [nuttx] Re: NXView
Posted by Gregory Nutt <sp...@gmail.com>.
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 critical
for initial development.
I can get the RT245RL board for ~$11 USD on eBay an adequate
STM32F103/F407 for $10-15 from China. Ready availability, inexpensive
hardware (albeit low performance) would probably be a better starting
point.. unless you can point to a competing low cost OTS solution. The
combined cost is around $20 and meets all of the initial development
requirements. I would have to have to have strong reason to deviate
from that. But I could be very easily dissuaded with an alternative OTS
hardware proposal at similar cost.
Nothing I have said precludes that alternative, higher performance
implementation. At a block diagram level, it does not matter. It is
just a matter of drivers on both sides.
Greg
On 6/12/2020 6:27 PM, Brennan Ashton wrote:
> On Fri, Jun 12, 2020, 5:18 PM Gregory Nutt <sp...@gmail.com> 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
>> overrun or or it could alter the real-time behavior of the target.
>> Ideally, the instrumentation should involve minimal overhead and the
>> behavior the real time system should be the same with or without the
>> instrumentation enabled. Otherwise, such a tool would not be a proper
>> diagnostic tool.
>>
>> I considered some PCIe parallel data acquisition devices, but did not see
>> a good match. PCIe would be hot, howeer.
>>
>> I also looked at FTDI FT60xx devices, but these seem so camera focused
>> that it was not completely clear to me that these could be usable. But I
>> am a mostly a software guy. Perhaps someone out there with better
>> knowledge of these devices could help out.
>>
>> The older FT600x, for example, has a 16-bits wide FIFO (pretty much
>> optimal for most MCUs) and has a USB 3.0 interface to the host PC. Using
>> such a camera-oriented device is less obvious to me than the more general
>> FT245RL. Perhaps that is only because of the camera-oriented language used
>> in the data sheets?
>>
>> If you know something about these options, I would like to hear from you.
>>
>> Greg
>>
> If you want high-speed io to USB the FX3 is probably one of the best bets.
> You see it frequently used on logic analyser and software defined radio
> boards between the USB and the FPGA.
>
> https://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-controller
>
> Somewhat related but have in the past modified the firmware on this for
> some custom debugging. https://1bitsquared.com/products/black-magic-probe
>
> --Brennan
>
Re: [nuttx] Re: NXView
Posted by Gregory Nutt <sp...@gmail.com>.
Thanks, Brennan and Petr, for the recommendations.
At this point, I am only trying to ascertain if there are a few people
interested in participating in such a project. I think it is more that
I can consider to do alone so any further steps would require some
interest in the development itself.
Brennan, you asked about the target side effort. That would be pretty
small because the instrumentation was build into the OS on day one. You
can see this in sched/Kconfigs for the description of
CONFIG_SCHED_INSTRUMENTATION. When that the option is enabled, OS hooks
in the form of call-outs are enabled.
There is some current use of those call-outs now for target-side,
software monitoring of the scheduler.
- There is logic sched/sched/sched_note.c that will buffer the
instrumented data in memory
- There is a character driver at drivers/syslog/note_driver.c that will
export the buffered instrumentation to any application via a character
driver
- There is an application at apps/system/sched_note that will use that
driver to periodically show OS activity
None of this, of course would be used in the proposed host-based
monitoring except for the raw OS call-outs. For this proposal, a modest
amount of new development would be needed:
- Board-specific initialization of the parallel interface (like the
FMC/FSMC in STM32 MCUs) so that writes to a memory mapped address will
add data to the FIFO.
- A new module that would (1) receive the OS instrumentation call-outs,
(2) encode/marshal the scheduler event data into a byte stream, and (3)
transfer the data to the FIFO by writing the byte stream to the memory
mapped address
That is not such a big effort. The other efforts would be to
configuration the host-side USB driver, verify proper transfer of data,
and develop the application to present the data graphically. Those, I
believe, are more effort than the work on the target side.
So, in general, I think the target side is in good shape for this use.
Greg