NXView

[Gregory Nutt]

Cross-posting to the Gooble group

-------- Forwarded Message --------

Subject:	NXView
Date:	Fri, 12 Jun 2020 18:02:49 -0600
From:	Gregory Nutt <spud...@gmail.com>
To:	d...@nuttx.apache.org

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

[Gregory Nutt]

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