Cool! It's a great idea to generate the trace compatible with Linux ftrace format. How about mainline your work?
> -----Original Message----- > From: Nakamura, Yuuichi (Sony) <yuuichi.a.nakam...@sony.com> > Sent: Tuesday, June 16, 2020 3:49 PM > To: dev@nuttx.apache.org > Cc: Nakamura, Yuuichi (Sony) <yuuichi.a.nakam...@sony.com> > Subject: RE: NXView > > Hi, Greg. > > I am developing the feature to collect the NuttX internal task events and > dump the data in Linux ftrace format. > The dumped data can be displayed graphically by using "TraceCompass". > It extends the NuttX sched note APIs to get enter/leave event of the > interrupt handler and system calls. > > The detail is described at : > https://github.com/YuuichiNakamura/nuttx-task-tracer-doc > > And the latest implementation is available at : > https://github.com/YuuichiNakamura/incubator-nuttx > https://github.com/YuuichiNakamura/incubator-nuttx-apps > in "feature/task-tracer" branch. > > I'm glad if this is helpful to your ideas. > > Thanks, > Yuuichi Nakamura > > > -----Original Message----- > > From: Gregory Nutt <spudan...@gmail.com> > > Sent: Saturday, June 13, 2020 9:03 AM > > To: dev@nuttx.apache.org > > Subject: NXView > > > > 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
