RE: Future Trademark Issues

ues Taking a quick look at PX4 it looks like it would be an issue, however it's one that easily fixed in a number of ways. It's not urgent to fix now. On Tue, 31 Dec 2019, 09:57 David Sidrane, wrote: > Nope! > > -Original Message- > From: Gregory Nutt [mailto:spu

RE: User Email Account

Hi Justin, I would say we all understand the argument. We do not agree with how the problem is solved. Why are we making everyone drink from the fire hose? Please help make this work for everyone. Clearly, from the responses, it is not. How about we make multiple lists and arrogate them to top

RE: User Email Account

+1 -Original Message- From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] Sent: Monday, December 30, 2019 10:49 PM To: dev@nuttx.apache.org Subject: Re: User Email Account But I think posting so many 'hard to read' emails to the mailing list will hurt user experience and cause users to

RE: Future Trademark Issues

Nope! -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Monday, December 30, 2019 1:43 PM To: dev@nuttx.apache.org Subject: Re: Future Trademark Issues > I was skimming https://www.apache.org/foundation/marks/ and I see > several things that might have impact in

RE: Working Effectively (was Point of Order)

che.org Subject: Re: Working Effectively (was Point of Order) On Mon, Dec 30, 2019 at 11:05 PM David Sidrane wrote: > > >Haitao is preparing a script for style check, the feature include: > >1.Auto build nxstyle > > 2.Improve nxstyle to check the partial file for support

RE: Single Committer

+1 -Original Message- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Monday, December 23, 2019 11:48 PM To: dev@nuttx.apache.org Subject: Re: Single Committer This makes sense giving the circumstances. It will get us going. We can still help reviewing PRs. On

Software release life cycle choices could have implications on workflow (was RE: Single Committer)

>An alternative way could be make master/trunk branch a dev branch and allow >all PRs to checked in, at the same time, maintain a stable branch which you >can cut release (as release manager) and pick up PRs that you carefully >reviewed. - This is the Apache way and I guess can achieve the same

RE:Software release life cycle choices could have implications on workflow (was RE: Single Committer)

Hi Greg, I have tried to answer some of your questions. See below: >-Original Message- >From: Gregory Nutt [mailto:spudan...@gmail.com] >Sent: Tuesday, December 24, 2019 6:48 AM >To: dev@nuttx.apache.org >Subject: Re: Software release life cycle choices could have implications on

RE: Workflow Development

PM Haitao Liu wrote: > > David, my github username liuguo09 liugu...@gmail.com. We could do some > tests to prepare for final workflow. > > David Sidrane 于2019年12月26日周四 下午4:55写道： > > > Hi Haitao, > > > > I can add you as an Admin to this organization > &g

RE: Workflow Development

gt; tests to prepare for final workflow. > > David Sidrane 于2019年12月26日周四 下午4:55写道： > > > Hi Haitao, > > > > I can add you as an Admin to this organization > > https://github.com/nuttx-to-asf it sole purpose is uninhibited > > collaboration > > to feed ups

RE: Workflow Development

Hi Nathan, -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Thursday, December 26, 2019 7:45 AM To: dev@nuttx.apache.org Subject: Re: Workflow Development On Thu, Dec 26, 2019 at 9:48 AM Xiang Xiao wrote: > > I need correct something here: > 1.Haitao don't

RE: Workflow Development

I want to avoid upsetting you. Let me be more direct and ask to you be more direct. Greg are you going to be using language like "abuse of power" if we are creating repos, branches pushing to the github NuttX organization? Yes on No? David -Original Message- From: Gregory Nutt

RE: [PROPOSAL] Collaboration on NuttX Workflow

+1 Give it a go +1 move it -Original Message- From: Anthony Merlino [mailto:anth...@vergeaero.com] Sent: Thursday, December 26, 2019 6:52 AM To: dev@nuttx.apache.org Subject: [PROPOSAL] Collaboration on NuttX Workflow Hi all, I would like to propose a method of collaboration for the

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

s RE: Single Committer) David Sidrane 于2019年12月26日周四 下午10:06写道： > >Then why committers have a different workflow comparing to contributors? > > It is the same work flow just different locations and rights. > > >Why not also create branches in your own forked repo? >

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

to create PR branches at the official repo, then how could a contributor other than committer contribute code? He/she just does not have the permission to create a branch. Thanks. David Sidrane 于2019年12月26日周四 下午4:45写道： > Hi Nathan, > > This is very aligned with the Apache way - thank you

RE: Workflow Development

for final workflow. David Sidrane 于2019年12月26日周四 下午4:55写道： > Hi Haitao, > > I can add you as an Admin to this organization > https://github.com/nuttx-to-asf it sole purpose is uninhibited > collaboration > to feed upstream. > > We can collaborate there. We can do a

RE: Workflow Development

It unblocks Haitao Liu. Xiami's tool master. -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, December 26, 2019 6:39 AM To: dev@nuttx.apache.org Subject: Re: Workflow Development > Uh what exactly is going on? Essentially, they are taking the

SGA for the PX4 (was RE: Workflow Development)

I will ask Lorenz for a definitive answer. -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, December 26, 2019 5:43 AM To: dev@nuttx.apache.org Subject: Re: Workflow Development > Will we get an SGA for the PX4 code that will come in? If not, it > cannot

RE: Workflow Development

. Alin, could you associate your apache account with github account? Anthony also need update it. BTW, github.com/nuttx is a good place for the remaining repo until we find some way to put them into apache. Thanks Xiang On Thu, Dec 26, 2019 at 9:40 PM David Sidrane wrote: > > The PPM

RE: Workflow Development

Hi, I feel two things are being blurred together here. There is a How and a What. The What is NuttX: +1 - There (should be) no uninhibited or unfettered NuttX changes. The How - There should uninhibited and unfettered access to the repo and tools to do our parts (jobs) using today's best

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

I think there may be 2 schools of thought on style fixes. Imagine up front creating a commit before changing code in files that fixes ONLY all of the style issues. Essentially this commit should contain only white space changes. If the commit is marked as such. It can be mechanically validated

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

It is OK Look at microsoft/vscode 58,891 commits 360 branches 0 packages 145 releases 1,048 contributors MIT The pr-branches are deleted on merge. The relasease branches foreverever WIP branches are there until merged, or superseded. -Original Message- From: Gregory Nutt

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

I think you have landed on the very motivation behind, and the very benefit that pull requests offer over patches. The submitter(s) is/are the one(s) who know how the pieces fit together. It is they that are responsible for creating something that's mergeabel. A set or PRs with a "No conflicts"

Signal to Noise (was RE: [DISCUSS] Simple Workflow Proposal)

Hi, >-Original Message- >From: Justin Mclean [mailto:jus...@classsoftware.com] >Sent: Monday, December 23, 2019 1:09 AM >To: dev@nuttx.apache.org >Subject: Re: [DISCUSS] Simple Workflow Proposal >Hi, >> I would also suggest you try to slow down the conversation here and think >> a

RE: Simple Workflow Proposal

12/22/2019 7:57 AM, Xiang Xiao wrote: > > > +1. > > > It's impotant to let people start the contribution. > > > The committer could/should do more work to ensure the correction in > > > review process before the automation tool is ready. > > > > > >

RE: [DISCUSS] Simple Workflow Proposal

Well Said! -Original Message- From: Justin Mclean [mailto:jus...@classsoftware.com] Sent: Monday, December 23, 2019 1:02 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Simple Workflow Proposal Hi, Apache has a concept of small reversible steps, if something can move the project

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

cycle choices could have implications on workflow (was RE: Single Committer) Doesn't do any good at social bragging sites like https://codersrank.io/ On 12/25/2019 9:47 AM, David Sidrane wrote: > Even on a squashed merge there is traceability back to the PR and > therefore > ALL th

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) On Wed, Dec 25, 2019 at 2:18 PM David Sidrane wrote: > Github issues and PR work so well together and are cross linked > auto-magically. Justin points out that some people cann

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

25, 2019 6:37 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) David Sidrane 于2019年12月25日周三 下午9:55写道： > Hi Xiang, > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > Yes, I agree that we should

Re: ILI9341 port to STM32F4

Hi Ben, Below is a link to the same presentation I did in the Netherlands. There are links within that presentation to the tools. There's also a video online showing how to use it. Google PX4 hard fault debugging

Are you familiar with the HAM story? (Was Are you failure with the HAM Story?)

If I could only spell and see my errors. dyslexics untie[1] 1 http://www.specialcompass.ca/shakiras-blog/2017/10/23/dyslexic-untie On 2019/12/20 21:09:17, David Sidrane wrote: > All, > > This is one of my favorite Lessons that I learned... reposted from Private > >

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

Hi Greg, I have used Bit bucket and Github and others SCM. I have had more positive Github experiences For me Github has always been a better tool except for the killer feature on BB of meld like diff. I am not working against anyone. I am trying to share what I know about GH, the mistakes I

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

Nathan, I am not sure if this is a terminology issue or just being new to github. (I feel you. We have all been there!) Where do they submit the PR from? https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo The only other option is to email patches. I

RE: 404 on site (Project status Nuttx)

-Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Friday, December 27, 2019 5:27 AM To: dev@nuttx.apache.org Subject: Re: 404 on site (Project status Nuttx) > You.can try the generated pages here: > https://apache-nuttx-website.github.io/ > How would you

RE: 404 on site (Project status Nuttx)

> Confused Yes - I was too - this is the website not wiki. Look here https://whimsy.apache.org/roster/ppmc/nuttx under Naming that is the 404 This is the link that works https://apache-nuttx-website.github.io/ > The Confluence database is separate, correct? If we were to make Yes. >

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

h from email. Obviously most people will just use git and GitHub but providing another way is also fine? I do not fully get what is the point of your story as I'm not good at reading English stories but if you mean that people should move on to new things, think of Amish. Thanks. David Sidrane 于20

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

-Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Friday, December 27, 2019 6:01 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) On Fri, Dec 27, 2019 at 8:26 AM David

RE: Issue Reporting

+1 for using github I have used both - I am more failure with github then Jira capabilities. Jira for me was very slow. So if there is a Jira PRO on the team and they can automate Github PR/Issue tracking and syncing/closing into Jira that would be the way to go. The benefit is that

FW: [Bitbucket] nuttx/nuttx has been forked

How do we stop this from happening? It is not fare to our "Customers" This certainly is of NO HELP Roman Zhukov [nore...@bitbucket.org] How can we warn him? Greg, Can you see hi email and warn him? David *From:* Roman Zhukov [mailto:nore...@bitbucket.org] *Sent:* Monday, December

RE: Issue Reporting

Hi Brenan, See Below. -Original Message- From: Brennan Ashton [mailto:bash...@brennanashton.com] Sent: Monday, December 30, 2019 8:52 AM To: dev@nuttx.apache.org Subject: Re: Issue Reporting Can people who are advocating for GitHub address the two main points that I had made. The

RE: Working Effectively (was Point of Order)

+1 Adding a tool that promotes violating the INVIOLABLES.txt on several aspect (expedience and non conformant code into the repo) feels like a very bad choice. How is this being justified? David -Original Message- From: Alin Jerpelea [mailto:jerpe...@gmail.com] Sent: Tuesday, January

RE: 404 on site (Project status Nuttx)

What is in the way of fixing the 404? -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Friday, December 27, 2019 3:59 AM To: dev@nuttx.apache.org Subject: Re: 404 on site (Project status Nuttx) No, this git just has the website content. The git contain both

RE: 404 on site (Project status Nuttx)

The [GitHub] tab lands on one repo. Do you need a landing page or repo? That lists all the other repos? -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Friday, December 27, 2019 4:03 AM To: dev@nuttx.apache.org Subject: Re: 404 on site (Project status Nuttx)

RE: Should we relax precheck a little bit?

On Wed, Mar 11, 2020 at 8:13 AM David Sidrane > wrote: > > > First, I have to say that I value the NuttX coding standard - it make > > for > > the most readable code I have EVERY worked on. I want it preserved. > > > > But in light of the below discussion: I am c

RE: Should we relax precheck a little bit?

First, I have to say that I value the NuttX coding standard - it make for the most readable code I have EVERY worked on. I want it preserved. But in light of the below discussion: I am changing my position that the "rule" CI is to just check ONLY the changes to a file AND if the only CI failure

RE: squashing commits or not

I think you are over-reading this. If we do not have a clear list of instructions we are not helping, we are confusing our would be committers (Additional Committers email). If you do not think of them as Rules but more of sharing your "best engineering judgment" to educate the group, you know,

RE: squashing commits or not

How about clear to the point work steps? Do we have the interim workflow listed anywhere that it can be read, without the diatribes? -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, March 05, 2020 8:00 AM To: dev@nuttx.apache.org Subject: Re: squashing

RE: squashing commits or not

t 5:37 PM David Sidrane wrote: > > I think you are over-reading this. If we do not have a clear list of > instructions we are not helping, we are confusing our would be committers > (Additional Committers email). If you do not think of them as Rules but > more > of sharing your &q

RE: squashing commits or not

Isn't that is just more noise? -Original Message- From: Miguel Ángel Herranz [mailto:mig...@midokura.com.INVALID] Sent: Thursday, March 05, 2020 8:16 AM To: dev@nuttx.apache.org Subject: Re: squashing commits or not Why not just leave all the commits and generate on master a single merge

RE: squashing commits or not

If you have clear work steps for a rebase work flow (prior to review). Contributors can and will do PR hygiene. -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, March 05, 2020 9:20 AM To: dev@nuttx.apache.org Subject: Re: squashing commits or not > If

RE: squashing commits or not

Why would you merge it to branch it is not ready? This is not hard. The PR will not pass CI if it fails Style check. Period! That is a simple check. We should have that by now. Also add it to the commit hooks locally. (document the work flow and add the script to download it - or put it in the

irony

irony *https://github.com/apache/incubator-nuttx/runs/491066405#step:5:11*

FW: Should we relax precheck a little bit?

ack to Clang. I'll try your idea about combining all the files under sched into a set. When you said you got 95% of the way there, do you have a .clang-format file that I could use as a starting point? If so that would help me start where you left off. cheers adam On Sun, Mar 8, 2020 at 3:40 AM Da

RE: Should we relax precheck a little bit?

I agree with Alin. -1 -Original Message- From: Alin Jerpelea [mailto:jerpe...@gmail.com] Sent: Monday, March 09, 2020 5:36 AM To: dev@nuttx.apache.org Subject: Re: Should we relax precheck a little bit? -1 I thin that as a long term goal we should aim to have it enabled and leave each

RE: Should we relax precheck a little bit?

-1 It is Not inline with long term goal and a violation of the Inviolable o Expediency is not a justification for violating the coding standard. -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Saturday, March 07, 2020 10:11 AM To: dev@nuttx.apache.org

Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

hat. Maybe a post-processing script that only looked at > > these macros would work. Or a contribution to clang-format. I'll think > > about it some more. > > > > -adam > > > > On Sun, Mar 8, 2020 at 3:40 AM David Sidrane > > wrote: > > > > >

RE: Github Issue on Build Failure

> It looks like there is a Jenkins plugin that allows the Github issue to be created relatively easily. I'd be happy to try and get this working if everyone agrees. +1 -Original Message- From: Anthony Merlino [mailto:anth...@vergeaero.com] Sent: Tuesday, March 10, 2020 9:57 AM To:

RE: Adding support for STM32G474RET6

Hi Nathan, I have not looked at the G part yet so I cannot say for certain, but I can share this: We learned many lessons from the coupling in the stm32 dirs. The take away was Avoid it! The F7 model is much better - the goal is to not have ifdef rash. Layered includes bring it the correct

Re: Adding support for STM32G474RET6

How does the RCC (clock tree) compare? On Wed, Apr 15, 2020, 5:11 PM Nathan Hartman wrote: > On Wed, Apr 15, 2020 at 4:08 PM Gregory Nutt wrote: > > This document address migration from F1 to F3 and addresses all major > > differences between F1 and F3: AN4228, Application note, Migrating

RE: Adding support for STM32G474RET6

Nathan, If you look at the Kinetis, https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 You can see the gist of that approach. It idea was as developers on the outside of the MFG, we only see the deltas in datasheets. We do not know, the feature

RE: Adding support for STM32G474RET6

To: dev@nuttx.apache.org Subject: Re: Adding support for STM32G474RET6 On Thu, Apr 16, 2020 at 1:00 PM David Sidrane wrote: > If you look at the Kinetis, > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 > > You can see the gist of t

RE: The new Apache NuttX Logo

+1 -Original Message- From: David Alessio [mailto:david.s.ales...@gmail.com] Sent: Saturday, April 18, 2020 1:30 PM To: dev@nuttx.apache.org Cc: palomino...@gmail.com; 李骁; nand...@xiaomi.com; Hans Subject: Re: The new Apache NuttX Logo I feel strongly about this. "NuttX" preserves the

RE: Adding support for STM32G474RET6

How about in the commit hooks? -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Thursday, April 16, 2020 7:47 PM To: dev@nuttx.apache.org Subject: Re: Adding support for STM32G474RET6 On Fri, Apr 17, 2020 at 5:54 AM David Sidrane wrote: > > Tha

RE: Question of PR Etiquette

Helping someone is not a bad thing. Consider the effect on the community and the code. What use to happen with patches: patches were emailed, ***modified*** and committed. Submitted != Committed - Was that BAD Etiquette? What use to happen with a PR: PR were submitted, 1-N more commits were

RE: Should we relax precheck a little bit?

Yeah I thought about the too But think of the can of worm on the commit history: Every PR touches the cfg file. Rebase HELL! Yuch! Fix or replace the tool! -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Sunday, March 15, 2020 6:08 AM To:

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

T_REQUIRE_VERSION TabWidth:8 UseTab: Never ... On Sat, Mar 14, 2020 at 1:29 AM David Sidrane wrote: Hi Adam and Maciej, Thank you for spending you time on this. It will be a huge win for everyone! The way I have been looking at this is like in transfer-function with an offse

RE: STM32H7 support

Hi John, >Is there a working document or set of notes detailing ongoing/needed work for STM32H7 support? Not really - a diff to the F7 file usually will show the holes but there is also the datasheet diff view. We used SDMMC2 in all H7 designs and that choice gave us the ability to bring out

RE: Fail checks no new warnings?

Hi Greg, I was able to do this once before: #if !defined(TODO) # if !defined(NO_PRINT_TODOS) # define DO_PRAGMA(x) _Pragma (#x) # define TODO(x) DO_PRAGMA(message ("TODO - " #x)) # else # define TODO(x) # endif #endif IIRC it allowed me to print compiler output that was not treated as

RE: Direct commits to repository

Way back when, I added a no_push to prevent any direct pushing. This may help others. git remote set-url --push origin no_push *From:* Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] *Sent:* Monday, April 27, 2020 10:26 PM *To:* dev@nuttx.apache.org *Subject:* Re: Direct

RE: [NOMINATION] Self nominate to be a mentor of Apache NuttX

Hi Dou, Welcome! Thank you for offering to help! David -Original Message- From: Duo Zhang [mailto:zhang...@apache.org] Sent: Monday, May 11, 2020 6:11 PM To: dev@nuttx.apache.org Cc: gene...@incubator.apache.org; 俊平堵 Subject: [NOMINATION] Self nominate to be a mentor of Apache NuttX

RE: Adding support for STM32G474RET6

3 or 4 volunteers who can perform the review: David Sidrane? Mateusz Szafoni? Matias N.? Alan? Others? My personal preference would be stand out of the way and let a team of experts do the review and merge. I get overwhelmed with large changes that I don't understand and usually just commit them b

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

uch greater. David *From:* Adam Feuer [mailto:a...@starcat.io] *Sent:* Monday, March 16, 2020 3:35 PM *To:* David Sidrane; dev@nuttx.apache.org *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?] Here's a Github compare with .clang-format f

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Hi Adam, See inline… *From:* Adam Feuer [mailto:a...@starcat.io] *Sent:* Tuesday, March 17, 2020 12:10 PM *To:* David Sidrane *Cc:* dev@nuttx.apache.org *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?] David, Yes, I agree that it would

PR and issue Templates

:* Abdelatif Guettouche [mailto:notificati...@github.com] *Sent:* Friday, March 20, 2020 4:42 AM *To:* apache/incubator-nuttx *Cc:* David Sidrane; Mention *Subject:* Re: [apache/incubator-nuttx] Support for Litex VexRiscV (#595) @aenrbs New files need to have an Apache license. Kconfig, README and auto

RE: PR and issue Templates

uest, etc. On Fri, Mar 20, 2020 at 12:48 PM David Sidrane wrote: > Hi, > > > > We spend a lot of time on PRs repeating ourselves on format, license. > > > > Giving directed links and examples will not challenge contributors with > having to ferret this out on their own.

RE: Build errors with inline functions

> the error will crop back up if MPU support is enabled without also > performing a protected build since up_mpu.c is only included in a > protected build. Just a heads up there are some case on some HW (imxrt, maybe the K66 for the DMA) were the MPU is needed to enable the proper access but not

Re: Should we relax precheck a little bit?

that works and can format the codebase. But we are where we are. So why don't you call a vote? On 2020/03/08 04:13:11, Xiang Xiao wrote: > On Sun, Mar 8, 2020 at 2:46 AM David Sidrane wrote: > > > > -1 It is Not inline with long term goal and a violation of the Inviolable > >

RE: Should we relax precheck a little bit?

Hi Adam, Have a look at https://github.com/mikr/whatstyle I got furthest with clang-format and it. It may be we get a 95% of the way there with it and we can add a backend secondary scripts. I was unable to convince Greg to create a master template so my approach was to combine all the files

RE: Jenkins build is back to normal : NuttX-Nightly-Build #159

Thank you Haitao Liu, Takashi Yamamoto and Masayuki Ishikawa for this! -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Wednesday, May 20, 2020 6:17 AM To: dev@nuttx.apache.org Subject: Re: Jenkins build is back to normal : NuttX-Nightly-Build #159 Hi all, We

RE: nxstyle warnings: Fail precheck?

The rule use to be: long lines were ok in arch header files. When I made nxstyle output error parsable output, that was a warning not an error. Then we got to make it fit below the ruler. Then we got to it better conform. So now I guess they are all errors. David -Original Message-

RE: SPI slave interface discussion

Hi Jukka, Would you mind opening a Draft PR for this disscussion. (See the Drop down on github [Create pull request] ) David *From:* Laitinen, Jukka [mailto:jukka.laiti...@intel.com] *Sent:* Thursday, May 21, 2020 11:23 PM *To:* dev@nuttx.apache.org *Subject:* RE: SPI slave

RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

This is super confusing to me. The todo list says. Status: Open Priority:Low. Things are working OK the way they are. But the design could be improved and made a little more efficient with this change. So it sounds like no

Re: stm32 uart init bug?

Some IP blocks need to be disabled to modify some registers. David On Thu, Sep 3, 2020, 3:45 PM Nathan Hartman wrote: > I ran into a strange issue with serial init for STM32. If the UART is > already enabled/configured, our configuration does not seem to apply. > > I discovered this because I

RE: i.MX RT 1060 ADC

Hi Thomas, If you structure the driver like any of the other ADC drivers in tree you should be able to reference px4_arch_adc_init and px4_arch_adc_sample from https://github.com/PX4/Firmware/blob/master/platforms/nuttx/src/px4/nxp/im xrt/adc/adc.cpp to get the required logic. To fill in the

RE: stm32 uart init bug?

Nathan, Sometimes the best results (on small systems) are obtained if boot loader leaves the CPU as it found it out of reset. If you think in terms of an OOD life cycle: The "Destructor" for each block reset the HW to the reset state. With this approach, the SoC out of reset, and executing at

RE: stm32 uart init bug?

I was not suggesting the fix should be in the boot loader, I was just commenting on what the right way to do a boot loader. I am sure the F4/F7 serial drivers deal with the PE bits. It has many test cases in the RC lib of PX4, it the low level stuff that most likely does not work correctly And

RE: Stack overflow during system init.

Hi Fotis, >NuttX is not able to boot at all with this option selected. I stepped >through the code and it seems that nxsig_initialize actually causes a stack >overflow that is detected by the above check. >Is this a bug, or I should configure something in a different way? Have you seen

RE: nuttx\arch\arm\src\stm32h7\stm32_spi.c uses txresult even when SPI_DMA is not defined

Hi Edi, You would fork https://github.com/apache/incubator-nuttx and submit a PR from your fork. I will have a look at the PR on Monday when I back at the computer. David *From:* Eduard Niesner [mailto:niesneredu...@gmail.com] *Sent:* Friday, October 16, 2020 10:28 AM *To:*

RE: Is the only option for using the network monitor....

, Sep 17, 2020 at 4:02 PM Gregory Nutt wrote: > On 9/17/2020 1:59 PM, David Sidrane wrote: > > Is the only option for using the network monitor > > > > Hi, > > > > My goal is to have a run time option to use a static IP or DHCP. > (Curretly > > it is

RE: Stack size alignment on arm

Hi Johannes & Jukka, Thank you for looking into this, I just wanted to mention something, so it does not get over looked, if it is still appropriate: In the past (9 or so years ago) there was an issue with floating point that required the stack to be 8 byte aligned. It was too long ago, so I do

Is the only option for using the network monitor....

Is the only option for using the network monitor Hi, My goal is to have a run time option to use a static IP or DHCP. (Curretly it is compile time) If either are used I want to "auto up" the eth0. Once the interface comes up , if configured for DHCP it should make start the DHCP request

RE: Is the only option for using the network monitor....

Hi Greg, Thank you responding. Then I will I will test it. -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, September 17, 2020 1:03 PM To: dev@nuttx.apache.org Subject: Re: Is the only option for using the network monitor On 9/17/2020 1:59 PM, David

PR's without adequate information

PR's without adequate information We are getting a slew of PR's without adequate information to consider merging them. Some of the Titles are incomplete or misleading. I am also concerned about bloat and the loss of one of NuttX major advantages: Scalability. I have no doubt, there is a great

RE: [OT] Linux now using 100 char lines as default

Let's one up them and keep it binary at the same time 128! :) -Original Message- From: Alan Carvalho de Assis [mailto:acas...@gmail.com] Sent: Monday, June 01, 2020 4:22 AM To: dev Subject: [OT] Linux now using 100 char lines as default Interesting:

RE: NuttX config browser

Hi Maciej, Could you have an option to upload a defconfig to see the settings based on it? David -Original Message- From: Maciej Wójcik [mailto:w8j...@gmail.com] Sent: Sunday, May 31, 2020 8:23 PM To: dev@nuttx.apache.org Subject: Re: NuttX config browser Hello Alan, A suggestion:

Re: interrupt priorities on nRF52

Nuttx does not support nested iteruups. In fact if you enable prioritization, you will get random crashes due to the reentrace to the common isr. On Sun, Oct 25, 2020, 1:52 PM Matias N. wrote: > Hi, > while working on nRF52 BLE link-layer I experienced some problems due to > delayed ISRs. This

RE: interrupt priorities on nRF52

> But the priority difference doesn't imply that the nested interrupt > happens automatically, you have to enable the interrupt manually after the critical CPU register and OS state is saved. My recollection is it depends on the priority assigned to the interrupt and the fence level used

RE: stm32f7 CONFIG_RAM understanding

) and sometimes fails advertising uorb topics (also heap allocation problem as I see). While I'm investigating this I notice this difference with RAM size config and ask this question (of course it may not be related to my issue). вт, 4 авг. 2020 г. в 22:49, David Sidrane : Both are not used

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:

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

<    1   2   3   4   >