Thanks for detailed comment. I'll study streams.h to apply it for the note data
interface.
> -Original Message-
> From: Gregory Nutt
> Sent: Thursday, July 2, 2020 11:05 AM
> To: dev@nuttx.apache.org
> Subject: Re: NXView
>
>
> > It's a reasonabl
> To: dev@nuttx.apache.org
> Subject: Re: NXView
>
>
> > It's a reasonable function partitioning. How about we define an interface
> > like syslog_channel_s between note and driver? So we can
> plug in the different transport like syslog.
>
> The correct way to
It's a reasonable function partitioning. How about we define an interface like
syslog_channel_s between note and driver? So we can plug in the different
transport like syslog.
The correct way to redirect streams within the OS is to use NuttX stream
interfaces. Forget about systlog channels
Thanks for your comment.
Then it may be better to separate the buffer management logic into another file
like sched_note_buffer.c.
I'll try it.
> -Original Message-
> From: Xiang Xiao
> Sent: Wednesday, July 1, 2020 10:54 PM
> To: dev@nuttx.apache.org
> Subject: RE
1 PM
> To: dev@nuttx.apache.org
> Cc: Nakamura, Yuuichi (Sony)
> Subject: RE: NXView
>
> Hi all,
>
> After merging my syscall instrumentation patch into
> feature/syscall-instrumentation branch, I had considered how to incorporate my
> task trace support into the mainline.
implementation.
-Original Message-
From: Gregory Nutt
Sent: Wednesday, June 17, 2020 10:13 AM
To: dev@nuttx.apache.org
Subject: Re: NXView
> The major differences are:
>
> - Different trace data format between the accumulated data in the memory and
> /dev/tracer output
&
ura
> -Original Message-
> From: Gregory Nutt
> Sent: Wednesday, June 17, 2020 11:13 AM
> To: dev@nuttx.apache.org
> Subject: Re: NXView
>
>
> > The major differences are:
> >
> > - Different trace data format between the accumulated data in the memory
The major differences are:
- Different trace data format between the accumulated data in the memory and
/dev/tracer output
It is because to reduce the trace data size in the memory. The accumulated
data contains packed (not aligned) values and
task is recorded by its PID, not the name.
June 16, 2020 11:11 PM
To: dev@nuttx.apache.org
Subject: Re: NXView
eg
Regardless of that decision, it would be nice if you could at least
upstream the interrupt and system call instrumentation. That will be
needed in any event and we should re-use that logic, not re-invent it.
I did that. I cr
,
Yuuichi Nakamura
> -Original Message-
> From: Gregory Nutt
> Sent: Tuesday, June 16, 2020 11:11 PM
> To: dev@nuttx.apache.org
> Subject: Re: NXView
>
> eg
> >
> > Regardless of that decision, it would be nice if you could at least
> > upstream the
eg
Regardless of that decision, it would be nice if you could at least
upstream the interrupt and system call instrumentation. That will be
needed in any event and we should re-use that logic, not re-invent it.
I did that. I created PR 1256 with the commit in your name
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 c
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 cal
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)
> Sent: Tuesday, June 16, 2020 3:49 PM
> To: dev@nuttx.apache.org
> Cc: Nakamura, Yuuichi (Sony)
&
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.
Hi Alan,
Thanks for sharing this. Indeed, I haven't been aware of such a tool. I'll
try it out.
BR,
Erdem
Alan Carvalho de Assis , 14 Haz 2020 Paz, 21:56
tarihinde şunu yazdı:
> Hi Erdem,
>
> Right, I understood your idea!
>
> In fact Maciej already created it, see:
>
> https://hackaday.io/proj
Hi Erdem,
Right, I understood your idea!
In fact Maciej already created it, see:
https://hackaday.io/project/94372-upm-nuttx-project-manager
https://gitlab.com/w8jcik/upm
Did you try it?
BR,
Alan
On 6/14/20, Erdem MEYDANLI wrote:
> Hi Alan,
>
>
> You are right. NuttX has a more comprehensi
Hi Alan,
You are right. NuttX has a more comprehensive scope. For sure, what I
proposed requires a lot of work.
With or without OpenOCD, what I meant by SDK was a combination of (actively
maintained) buildroot and a meta-tool like *West *in Zephyr.
Those who haven't heard of Zephyr's meta-too
In the past NuttX used to have a Buildroot that was able to generate
the toolchain, etc. It is still around, some time ago David Alessio
fixed it.
It generates more than that. It generates most of the tools that you
need including kconfig-frontends, genromfs, etc. And it is easily
extende
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 fro
Hi Erdem,
On 6/14/20, Erdem MEYDANLI wrote:
sic
>
> I do agree. That would be such an invaluable tool. BTW, speaking of
> particular hardware like FT245 gives me an idea. Well, this might sound a
> little bit irrelevant, but what about taking it a step further and
> developing a mini-SDK (NX-SDK)
>
I would think that such an application would be a C++ development and would
be usable both on Windows and Linux.
<<
Would it be nice to have an application that utilizes HTML5 and CSS3 for
the UI, communicates with the low-level parts of the app via WebSockets?
(Lesser C++, but additiona
On 6/13/2020 3:25 PM, Brennan Ashton wrote:
On Sat, Jun 13, 2020 at 1:56 PM Gregory Nutt 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
On Sat, Jun 13, 2020 at 2:25 PM Brennan Ashton
wrote:
>
> On Sat, Jun 13, 2020 at 1:56 PM Gregory Nutt 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
On Sat, Jun 13, 2020 at 1:56 PM Gregory Nutt 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
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
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
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 itsel
Why not use the ETM?
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, June 12, 2020 5:03 PM
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 will
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, 20
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
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
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, 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, 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
35 matches
Mail list logo
