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.

RE: NXView

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) > Subject: RE: NXView >

RE: [EXT] Re: NuttX Wiki Porting Guide SocketCAN addition

That document is in the repository at incubator-nuttx/Documents/NuttxPrtingGuide.html.  You change via PR.  After the PR checks complete, the massaged document will be available as build artifacts and can be placed in Confluence.Sent from Samsung tablet. Original message From: P

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 cal

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 c

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 created PR 1256 with the commit in your name

nrf51822 and BLE

Hi, I'm picking up a project based on a NRF51822 module and I'm currently trying out Zephyr due to the available BLE support. However, I'm having some issues with it and, while I guess it is a matter of learning more about Zephyr to solve them, I was wondering about what is the state now for Nut

RE: nrf51822 and BLE

Why not use the BLE provided by NuttX?Sent from Samsung tablet. Original message From: "Matias N." Date: 6/16/20 6:42 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: nrf51822 and BLE Hi,I'm picking up a project based on a NRF51822 module and I'm currently trying out Zephyr d

Re: nrf51822 and BLE

AFAIK NuttX supports the Host level API and at most HCI UART interface. I'm referring to the link-level code which interfaces directly with NRF51822 so that you can run NuttX in the board itself (and not as an external module via UART). On Tue, Jun 16, 2020, at 22:04, spudaneco wrote: > Why no

Re: nrf51822 and BLE

AFAIK NuttX supports the Host level API and at most HCI UART interface. I'm referring to the link-level code which interfaces directly with NRF51822 so that you can run NuttX in the board itself (and not as an external module via UART). It supports both host and slave and uses a driver defin

Re: nrf51822 and BLE

Not sure what you mean by "slave" in this case. What I'm referring to is the access to the low-level Bluetooth hardware (register based access to radio peripheral). I didn't meant NuttX's BLE stack would only support HCI UART, I mean that there's no support for NRF radio (link-level layer) on Nu

RE: NXView

> I did that. I created PR 1256 with the commit in your name Thank you! I want to mainline the feature by issuing the additional PRs for the remaining part. As you pointed out, the codes are based on the existing sched note logic. The reason of preparing another files is the changes for this fe

Re: NXView

Some comments: 1. I don't think that there should be two implementations that are so similar.  There should be only one.  But I am open to extending/merging that one, common implementation. 2.  nsh is not an appropriate place for the application side code.  That should go in apps/system.  Pe

Re: NXView

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.

RE: NXView

Thanks for valuable comments. I have no objection to your advice that overlapping the similar implementation should be avoided. Let me make change the current implementation into the extension of the existing codes, and if there are any problems in extending, please let me discuss again. Regardi