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
On 6/12/2020 6:02 PM, Gregory Nutt wrote:
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 state
of the OS. This would be conceptually similar to Segger SystemView or
Wind River WindView: A host basic graphical tool that exposes the
internal behavior of tasks and threads within the OS in a "logic
analyzer format":
1. Horizontal rows would be indicate the state of each task, running
or block (and if blocked why/)
2. Each arranged vertically by task/thread priority so that the
highest priority task is the first row and the lowest priority
task is the bottom row.
3. Annotation to indicated events: Interrupts, semaphore operations,
spinlock operations, etc.
4. This display should be realtime (with a lag, of course) and should
scroll to the right as time elapses. It should be possible to
capture and save the event data for subsequent offline analysis.
Additional analytic displays could be considered in the future.
The hardware I am thinking to accomplish this would be an inexpensive
FT245RL board which connects to the target via an 8-bit parallel
interface and to the host via a USB 2.0 interface. The target side is
essentially a FIFO: OS events would be written to the FT245RL FIFO
and transferred to the host via USB 2.0.
The OS instrumentation is already in place to accomplish this. This is
controlled by CONFIG_SCHED_INSTRUMENTATION and related configuration
options that you can see in sched/Kconfig. The target side effort is
then:
1. Configure the parallel interface to the FT245RL's FIFO. This would
likely be FSMC for an initial STM32 implementation.
2. Develop the simple logic to encode the instrumented events and to
pass them to host visa that FIFO.
Drivers and configuration tools for the host side are already
available from the FTDI website. Becoming familiar with these tools
and integrating the host-side interface would be another task.
The final task, the one that is the most daunting to me, is the
development of the substantial host-side graphics application that
would receive the OS instrumentation data and produce the graphic
presentation. I would think that such an application would be a C++
development and would be usable both on Windows and Linux.
I believe that such a tool would be a valuable addition to the NuttX
ecology. I think that such a tool would move NuttX from a basic,
primitive open source OS project and into full competition with
commercial products (in terms of features and usage... we are not
actually in competition with anyone).
Is this something that would be interesting to anyone? Does anyone
have any input or advice? If there is any interest I think that we
should create a small development team to make this happen. If that
team is small enough, I would be happy to provide common development
hardware (STM32 and FT245RL boards from China, or course).
What say ye?
Greg
