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. Regarding to another issue, the place of the application side code, it is because I have wanted to implement trace cmd "" It gets the trace while executing the specified command line like "time" command of nsh. It requires nsh_parse() nshlib internal API. Thanks, Yuuichi Nakamura > -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 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. The correspondence between PID > and task name string is hold in the separated task name buffer. > >On the other hand, the output from /dev/tracer contains aligned words and > contains the task name string for each trace entries. > >It is because easy to handle the data by the application code (nsh trace > command). > > That is a trivial difference and there are some misconceptions. > > The structures can be packed by simply adding the packed attribute to the > structures. That does not justify a redesign. > > The current implementation does *not* use the task name, it uses the pid. The > task name is provided only when the task is created. The provides the > associated between pid and name. Thereafter only the pid is uses. > > Your implementation has two much overlap and should not come upstream as a > separate implementation. Extensions and improvements to the existing > implementation are welcome, however. > > Greg
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. The correspondence between PID and task name string is hold in the separated task name buffer. On the other hand, the output from /dev/tracer contains aligned words and contains the task name string for each trace entries. It is because easy to handle the data by the application code (nsh trace command). That is a trivial difference and there are some misconceptions. The structures can be packed by simply adding the packed attribute to the structures. That does not justify a redesign. The current implementation does *not* use the task name, it uses the pid. The task name is provided only when the task is created. The provides the associated between pid and name. Thereafter only the pid is uses. Your implementation has two much overlap and should not come upstream as a separate implementation. Extensions and improvements to the existing implementation are welcome, however. Greg
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. Perhaps not in apps/system/sched_note; perhaps a unique application for your purpose. It is not an appropriate command to reside within the shell, however. Greg On 6/16/2020 8:03 PM, Nakamura, Yuuichi (Sony) wrote: 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 feature affects the existing logic. Of course, the code duplication should be avoided. So if needed I want to change it to modification of the existing codes. Please let me keep discussion in ML or new PR to make the code acceptable into the maineline. Are there other functional differences? Should these related implementations be merged in some way? 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. The correspondence between PID and task name string is hold in the separated task name buffer. On the other hand, the output from /dev/tracer contains aligned words and contains the task name string for each trace entries. It is because easy to handle the data by the application code (nsh trace command). - Additional ioctl functions in /dev/tracer driver There are many features which can be controlled by the application such as system call trace filters. So the driver has ioctl handlers for it. Of course, sched_tracer.c has the code to handle the filters. I feel that the code should be separate into the different PRs: - remaining system call trace support code which requires the modification to the build system - sched tracer and device driver which uses new sched note APIs (needs more discussion) Thanks, 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 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
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 feature affects the existing logic. Of course, the code duplication should be avoided. So if needed I want to change it to modification of the existing codes. Please let me keep discussion in ML or new PR to make the code acceptable into the maineline. > Are there other functional differences? Should these related implementations > be merged in some way? 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. The correspondence between PID and task name string is hold in the separated task name buffer. On the other hand, the output from /dev/tracer contains aligned words and contains the task name string for each trace entries. It is because easy to handle the data by the application code (nsh trace command). - Additional ioctl functions in /dev/tracer driver There are many features which can be controlled by the application such as system call trace filters. So the driver has ioctl handlers for it. Of course, sched_tracer.c has the code to handle the filters. I feel that the code should be separate into the different PRs: - remaining system call trace support code which requires the modification to the build system - sched tracer and device driver which uses new sched note APIs (needs more discussion) Thanks, 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 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
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 NuttX yet. In other words, using Zephyr figures from their docs, the idea would be to support this scenario (replace Zephyr with NuttX): https://docs.zephyrproject.org/latest/_images/ble_cfg_single.png Whereas NuttX currently supports the scenario on the left of this figure: https://docs.zephyrproject.org/latest/_images/ble_cfg_dual.png As you mention, this requires code which interfaces the upper bluetooth stack with the low-level radio hardware. This is the code that is available un Zephyr under Apache 2.0 license. Best, Matias On Tue, Jun 16, 2020, at 22:24, Gregory Nutt wrote: > > > 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 defined by and > interface. HCI UART is *not* assumed or required. I don't know that it > is compatible with the NRF. I imagine you would have to use the NRF stack. >
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 defined by and interface. HCI UART is *not* assumed or required. I don't know that it is compatible with the NRF. I imagine you would have to use the NRF stack.
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 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 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 NuttX > and support for BLE on NRF5. I revisited old NuttX e-mail threads and at the > time it was mentioned that Alan asked Nordic about the BLE stack which is on > Zephyr to be released as BSD to be included in NuttX [1] (to which there was > no response). From my understanding this code is part of Zephyr which is > licensed under Apache 2.0. Since NuttX is also licensed the same way, maybe > now there's a better chance of integrating support for this?I really don't > know much about Bluetooth Classic/BLE internals but in case someone with more > knowledge is able to work on that part I think i could try to get basic > support for NRF51822 into NuttX. In any case, I see there's already NRF52x > support so that is not really an issue. But at least I could help test > it.What do you think? Would this be possible now? Was it just the licensing > issue or were there other technical impediments? Or maybe now there's still a > licensing issue (I hope not).Best,Matias[1] > https://groups.google.com/d/msg/nuttx/pmIJEOLWfHA/a4HWcxMEAwAJ
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 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 NuttX and support for BLE on NRF5. I revisited old NuttX e-mail threads and at the time it was mentioned that Alan asked Nordic about the BLE stack which is on Zephyr to be released as BSD to be included in NuttX [1] (to which there was no response). From my understanding this code is part of Zephyr which is licensed under Apache 2.0. Since NuttX is also licensed the same way, maybe now there's a better chance of integrating support for this?I really don't know much about Bluetooth Classic/BLE internals but in case someone with more knowledge is able to work on that part I think i could try to get basic support for NRF51822 into NuttX. In any case, I see there's already NRF52x support so that is not really an issue. But at least I could help test it.What do you think? Would this be possible now? Was it just the licensing issue or were there other technical impediments? Or maybe now there's still a licensing issue (I hope not).Best,Matias[1] https://groups.google.com/d/msg/nuttx/pmIJEOLWfHA/a4HWcxMEAwAJ
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 NuttX and support for BLE on NRF5. I revisited old NuttX e-mail threads and at the time it was mentioned that Alan asked Nordic about the BLE stack which is on Zephyr to be released as BSD to be included in NuttX [1] (to which there was no response). From my understanding this code is part of Zephyr which is licensed under Apache 2.0. Since NuttX is also licensed the same way, maybe now there's a better chance of integrating support for this? I really don't know much about Bluetooth Classic/BLE internals but in case someone with more knowledge is able to work on that part I think i could try to get basic support for NRF51822 into NuttX. In any case, I see there's already NRF52x support so that is not really an issue. But at least I could help test it. What do you think? Would this be possible now? Was it just the licensing issue or were there other technical impediments? Or maybe now there's still a licensing issue (I hope not). Best, Matias [1] https://groups.google.com/d/msg/nuttx/pmIJEOLWfHA/a4HWcxMEAwAJ
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
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 Nice work. This seems to replicate a lot of existing logic at least at the level of the block diagram: 1. sched/sched_tracer.c seems to be functionally like sched/sched/sched_note.c with CONFIG_SCHED_INSTRUMENTATION_BUFFER selected. 2. dev/tracer looks a lot like dev/misc/not_driver.c 3. The change to apps/nshlib seem to be a lot like apps/system/sched_note. One difference is the ftrace output format. apps/system/sched_note just outputs like debug info to the syslog. Are there other functional differences? Should these related implementations be merged in some way? Greg 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. Thanks, Greg
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 Nice work. This seems to replicate a lot of existing logic at least at the level of the block diagram: 1. sched/sched_tracer.c seems to be functionally like sched/sched/sched_note.c with CONFIG_SCHED_INSTRUMENTATION_BUFFER selected. 2. dev/tracer looks a lot like dev/misc/not_driver.c 3. The change to apps/nshlib seem to be a lot like apps/system/sched_note. One difference is the ftrace output format. apps/system/sched_note just outputs like debug info to the syslog. Are there other functional differences? Should these related implementations be merged in some way? Greg
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: Peter Van Der Perk Date: 6/16/20 12:40 AM (GMT-06:00) To: dev@nuttx.apache.org Subject: RE: [EXT] Re: NuttX Wiki Porting Guide SocketCAN addition I've now got an approved account however it seems that the NuttX porting guide page is a read-only html page. Can this page be converted to Confluence/Wiki markup or is there a way for me to access this html file?Yours sincerely,Peter van der perkpeter.vanderp...@nxp.com -Original Message-From: Brennan Ashton Sent: 15 June, 2020 20:15To: dev@nuttx.apache.orgSubject: [EXT] Re: NuttX Wiki Porting Guide SocketCAN additionCaution: EXT EmailOn Mon, Jun 15, 2020 at 10:40 AM Peter Van Der Perk wrote:>> Thanks to the feedback of Gregory Nutt and Alan Carvalho de Assis today we finally merged the SocketCAN code into NuttX. I've already made a porting guide in the past https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpetervanderperk.nl%2Fnuttx_socketcan_porting_guide.pdf&data=02%7C01%7Cpeter.vanderperk%40nxp.com%7C900955770b694ac507e908d81158122d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637278417237452545&sdata=mxeyU2FjpP91XeHrd4JIBv4iidok%2B31aCfPZOLvn%2BO0%3D&reserved=0 what's the procedure to get this documentation into the NuttX wiki Porting guide?Peter,Thanks for all the work getting this feature in. As for the porting guide/wiki if you can send me your apache ID from registering on the wiki, I will happily approve your account for write access to the wiki. The extra step is just to keep the spam under control.https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Flogin.action%3Fos_destination%3D%252Fdisplay%252FNUTTX%252FNuttx&data=02%7C01%7Cpeter.vanderperk%40nxp.com%7C900955770b694ac507e908d81158122d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637278417237452545&sdata=scc9iY%2B7MwXR1fzsMjmMkCXQvU41WWyV9zQsze0vdbY%3D&reserved=0--Brennan
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 > > 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 > > 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
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 > 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
