RE: cpp cxx help - No thread API

Yes, include setting is done in the recently: commit d32e9c38dfb0659a7f3c0cf586ba1584cd7eb3d6 Author: Xiang Xiao Date: Sat Jul 11 18:37:40 2020 +0800 boards: Move the C/C++ search path to the common place so all boards support uClibc++/libc++ automatically Signed-off-by: X

Build failed in Jenkins: NuttX-Nightly-Build #250

See Changes: -- [...truncated 280.56 KB...] Cleaning... Configuring... Building NuttX... N

RE: Build failed in Jenkins: NuttX-Nightly-Build #250

Note: already fixed by https://github.com/apache/incubator-nuttx/pull/1566 > -Original Message- > From: Apache Jenkins Server > Sent: Wednesday, August 12, 2020 3:59 PM > To: dev@nuttx.apache.org > Subject: Build failed in Jenkins: NuttX-Nightly-Build #250 > > See

Re: Board-specific drivers in NuttX 9.1.0.

> NB: You'll need this patch too: > https://github.com/apache/incubator-nuttx/pull/1480 Oh, I didn't realize that I had to patch v9.1.0 with this. I thought it was already included in the latest releases. After patching, linking of my drivers f

Re: Board-specific drivers in NuttX 9.1.0.

> It's the drivers/Kconfig that defines it (i.e. you add it), you can then enable it from menuconfig. To be clear I meant the "drivers" folder that's linked to "platform" not the toplevel nuttx/drivers. On Wed, Aug 12, 2020 at 12:51 PM Abdelatif Guettouche wrote: > > As far as I can tell it's th

Re: Board-specific drivers in NuttX 9.1.0.

As far as I can tell it's the same, current master[1], 9.1[2], 9.0[3], 8.1[4] I do have some flashes about the necessity of a drivers folder alongside the board folder with custom boards, but I can't remember. That was an issue, it's now resolved. > But the code is not included in the build. I che

Re: Board-specific drivers in NuttX 9.1.0.

Thank you very much. Indeed it now works perfectly. However I would propose a little change on this. Currently board drivers require a specific directory structure, and this non-obvious (for me) config entry. Why not instead handle external drivers exactly like external boards? That is, add CONFI

Re: Board-specific drivers in NuttX 9.1.0.

Note that this common board organisation and these two folders are relatively new and didn't get as much attention as they need. That said, I like the second suggestion. Would you like to prepare a PR and see what others have to say? I could do that if you want. On Wed, Aug 12, 2020 at 12:31 PM

RE: Board-specific drivers in NuttX 9.1.0.

I am volunteering to help test any of these type changes. There were many subtle breakages in the past that tended to slip through. Also once all this settles out, it so needs to be documented. -Original Message- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Wedn

Re: Board-specific drivers in NuttX 9.1.0.

Unfortunately I am not sure whether I can help with a PR. I don't feel that I understand the NuttX build system well enough to proceed with such a change. Could you help on this? Of course I can help with testing too. Στις Τετ, 12 Αυγ 2020 στις 4:29 μ.μ., ο/η David Sidrane < david.sidr...@nscdg.c

Re: Board-specific drivers in NuttX 9.1.0.

I'll provide a PR for review. The change by itself is simple, we just need to add one config option to nuttx/drivers/Kconfig. However we need to update all of Spresense defconfigs (for now only Spresense uses this folder). On Wed, Aug 12, 2020 at 2:33 PM Fotis Panagiotopoulos wrote: > > Unfortuna

Re: Board-specific drivers in NuttX 9.1.0.

It's PR1571, there was no need to update any config as I kept the same name. On Wed, Aug 12, 2020 at 3:51 PM Abdelatif Guettouche wrote: > > I'll provide a PR for review. > The change by itself is simple, we just need to add one config option > to nuttx/drivers/Kconfig. > However we need to updat

Re: Board-specific drivers in NuttX 9.1.0.

Hi, I'm trying to follow the discussion to understand what would the final layout look for board specific drivers now. I was unaware of this CONFIG_SPECIFIC_DRIVERS option. What is the role of drivers/platform? I would expect board specific drivers to be under the board directory. Best, Matias

Re: Pre-check flow

Hi, I am planning to add RX Toolchain for the Renesas architecture (for RX65N board) with reference to the build steps provided in the below URL, https://gcc-renesas.com/wiki/index.php?title=How_to_build_the_RX_Toolchain_under_Ubuntu_14.04 I checked on the local build time for the container when

Re: Board-specific drivers in NuttX 9.1.0.

Take a look under boards/arm/cxd56xx/drivers for an idea of what that folder might contain. During dirlink that folder is linked to drivers/platform if it's not present a dummy folder is linked. I understand that Spresense has some special mechanisms to access on board drivers (the sequencer?) and

Re: Board-specific drivers in NuttX 9.1.0.

Hi Matias, Within nuttx/drivers lie high-level drivers, that do not depend directly on any board. As I get it the purpose of nuttx/drivers/platform is to extend NuttX drivers out-of-tree, exactly as CONFIG_ARCH_BOARD_CUSTOM does for custom boards. Within board/src lie drivers specific to the sele

Re: Board-specific drivers in NuttX 9.1.0.

As a matter of fact, the exact driver that I am working on now, is for an out-of-board device. It uses a UART and an SPI to create a high-level interface towards an external, physically separated device. It does not require anything special from the board, other than an UART and SPI. And in fact w

Re: Board-specific drivers in NuttX 9.1.0.

> How I actually plan to use it. > I want to make various "driver packs" as different repositories. When you > start a new project you get the desired "packs" as git submodules, creating > a collection of only the needed drivers. Each one is developed and > versioned separately. As I mentioned in

Re: Roadmap?

Hello! I definitely agree with all the words written below and I would like to add few wishes. I am interested in industrial devices communicating by fieldbuses. I use the NuttX port of FreeModbus stack and I would like to see more port of communication stacks like this. I prefer CANopen and Prof

Re: Board-specific drivers in NuttX 9.1.0.

Right, so what I was trying to get at is that there are two separate topics here: a) board-common drivers (ie: they depend on a given board family such as stm32) and b) board-independent drivers (they use only nuttx generic interfaces). a) is already supported (although only for stm32 and cxd65

Re: Roadmap?

I am interested in industrial devices communicating by fieldbuses. I use the NuttX port of FreeModbus stack and I would like to see more port of communication stacks like this. I prefer CANopen and Profinet, There are several open source communication stack for these protocols. Where would we

Re: Roadmap?

Should we start creating issues for these ideas and start assigning them to milestones? The initial milestone could be "future" so that we can later decide on a given version to target. On Wed, Aug 12, 2020, at 13:03, Matous Pokorny wrote: > Hello! > > I definitely agree with all the words writ

Re: Board-specific drivers in NuttX 9.1.0.

Yes I am aware of your Workspace Manager. It helped me a lot to set up my workspace. I am grateful for this contribution. But I just don't like to use external tools, or rely on "hacks" for such a common thing. Maybe for more "exotic" modifications to the kernel... Indeed we have A). Through board

RE: Roadmap?

Github project boards or confluence? -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Wednesday, August 12, 2020 9:07 AM To: dev@nuttx.apache.org Subject: Re: Roadmap? > I am interested in industrial devices communicating by fieldbuses. I use > the NuttX port of F

Re: Roadmap?

> Where would we document a roadmap? How/who would prioritize and > schedule implementation of roadmap items? How could accomplish any of > this with only a volunteer organization and no project management with > any authority? We can loosely define a release cycle, e.g. 3 months. At the start o

Re: Roadmap?

If we create issues as a first step, we can identify who will be responsible for driving that effort forward. The issue can then be assigned to that person and the issue updated to reflect progress. The issue can be assigned a GitHub milestone (a way to group issues together, with an optional t

Re: Board-specific drivers in NuttX 9.1.0.

I'd also prefer to have this on NuttX directly. Regarding drivers/platform, I understand it is merely a way for the build system to link your directory to drivers/platform, right? If so, your suggestion to make the target of this link configurable would mostly handles this. On Wed, Aug 12, 202

Re: Roadmap?

Hi Matous, Did you see this CANopen implementation: https://github.com/rscada/libcanopen Now it should be easy to use because NuttX supports SocketCAN. BR, Alan On 8/12/20, Matous Pokorny wrote: > Hello! > > I definitely agree with all the words written below and I would like to add > few wi

Re: Roadmap?

Folks, I made a wiki page with the raw list of things that people are asking for in this thread: https://cwiki.apache.org/confluence/display/NUTTX/Roadmap Check it out, add anything I missed, and correct errors I made. Maybe the next step would be to try to complete this list, then maybe priori

Re: Roadmap?

On Wed, Aug 12, 2020, 10:40 AM Adam Feuer wrote: > Folks, > > I made a wiki page with the raw list of things that people are asking for > in this thread: > > https://cwiki.apache.org/confluence/display/NUTTX/Roadmap I am thinking this might be easier to manage as GH tickets with a label, and th

RE: Roadmap?

+1 (I know it is not a vote, I am just agreeing) -Original Message- From: Brennan Ashton [mailto:bash...@brennanashton.com] Sent: Wednesday, August 12, 2020 10:54 AM To: dev@nuttx.apache.org Subject: Re: Roadmap? On Wed, Aug 12, 2020, 10:40 AM Adam Feuer wrote: > Folks, > > I made a wik

Re: Roadmap?

Brennan, Re: needing an Apache CWiki account, ok, I get it. So something like this? Github's public roadmap: https://github.com/github/roadmap/projects/1 Seems doable. Does anyone have any objections to me creating a board like this for NuttX? -adam On Wed, Aug 12, 2020 at 10:54 AM Brennan Ash

Re: Roadmap?

I made a wiki page with the raw list of things that people are asking for in this thread: https://cwiki.apache.org/confluence/display/NUTTX/Roadmap Check it out, add anything I missed, and correct errors I made. Maybe the next step would be to try to complete this list, then maybe prioritize

Re: Roadmap?

These are projects which gives you a different view from issues. But there's also a "milestone": https://docs.github.com/en/github/managing-your-work-on-github/creating-and-editing-milestones-for-issues-and-pull-requests https://docs.github.com/en/github/managing-your-work-on-github/associating-

Re: Roadmap?

On Wed, Aug 12, 2020 at 11:04 AM Gregory Nutt wrote: > We probably should also include all Github Issues that are listed as > enhancements. > If we use a Github Project Board like Brennan suggested this would be pretty easy to link them there. -adam -- Adam Feuer

Re: Roadmap?

> Seems doable. Does anyone have any objections to me creating a board like this for NuttX? Not from me, I think with Github's projects (or milestones) and consistent labeling of issues and PRs people would have a better overview. Anyone can then follow the development of the feature of interest.

Re: Roadmap?

Well I just made a board for us: https://github.com/orgs/apache/projects/13 If we don't like it we can delete it. I added the items from the wiki list as cards in Future, we should really convert them to issues and add more description to them. We can add the issues that we're working on to the c

Re: Roadmap?

Jira is another option available to us.

Re: Roadmap?

> Well I just made a board for us: Was it intentional to create it in Apache's and not here: https://github.com/apache/incubator-nuttx/projects? On Wed, Aug 12, 2020 at 7:39 PM Gregory Nutt wrote: > > Jira is another option available to us. > >

Re: Roadmap?

On Wed, Aug 12, 2020 at 11:40 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > Was it intentional to create it in Apache's and not here: > https://github.com/apache/incubator-nuttx/projects? Oops. No. :) I'll move it or recreate it there. -adam

Re: Roadmap?

We probably should also include all Github Issues that are listed as enhancements. If we use a Github Project Board like Brennan suggested this would be pretty easy to link them there. Jira will link to github issues as well, as I recall.  We went through all of this in the early days of t

Re: Roadmap?

Thanks for catching that Abdelatif. I moved the NuttX project board here: https://github.com/apache/incubator-nuttx/projects/2 We can delete it if we don't like it. -adam On Wed, Aug 12, 2020 at 11:43 AM Adam Feuer wrote: > On Wed, Aug 12, 2020 at 11:40 AM Abdelatif Guettouche < > abdelatif.

Re: Roadmap?

On Wed, Aug 12, 2020 at 12:07 PM Gregory Nutt wrote: > > How/who would prioritize and > schedule implementation of roadmap items? How could accomplish any of > this with only a volunteer organization and no project management with > any authority? Open source tends to be driven by people scrat

Re: cpp cxx help - No thread API

Xiang and Marc, thank you very much for your quick responses. That did get me further, I'm getting an error around "at_quick_exit" now. Based on my googles it's regarding std11 or std17 options not being defined. I did try adding -std=c++11 to the Make.defs but it didn't have any effect. I'm usi

Re: cpp cxx help - No thread API

I should add that I also tried Marc's original answer (multiple lines to Make.defs) with the same result. On Wed, Aug 12, 2020 at 6:38 PM Matt DeWall wrote: > Xiang and Marc, thank you very much for your quick responses. > > That did get me further, I'm getting an error around "at_quick_exit" no

RE: cpp cxx help - No thread API

Matt, please try the attached workaround. I will provide the real implementation later. > -Original Message- > From: Matt DeWall > Sent: Thursday, August 13, 2020 9:48 AM > To: dev@nuttx.apache.org > Subject: Re: cpp cxx help - No thread API > > I should add that I also tried Marc's ori