Nightly build?

While working on our board report, I noticed that the nightly build is no longer found at https://s.apache.org/wnv2u Is it still running? If so, where is the new location? Thanks, Nathan

Re: spiffs (in)compatilibity

On Mon, Dec 21, 2020 at 8:11 AM Gregory Nutt wrote: > The version in NuttX is based off an older version of SPIFFS (before all > of the security related changes) and may have incompatibilities with the > current SPIFFS. > > On 12/20/2020 11:26 PM, Takashi Yamamoto wrote: > > hi, > > > > a

Re: [VOTE] Apache NuttX 10.0.0 (incubating) RC0 release

Hi Justin, Did you intend to vote on the IPMC thread? Thanks, Nathan On Wed, Dec 2, 2020 at 9:11 PM Justin Mclean wrote: > Hi, > > +1 (binding) but a lot more needs to be done on the LICENSE and headers > > I checked: > - incubating in name > - DISCLAIMER exists > - a good start have been

Re: [VOTE] Apache NuttX 10.0.0 (incubating) RC0 release

On Thu, Nov 26, 2020 at 3:36 AM Brennan Ashton wrote: > > Hello all, > Apache NuttX (Incubating) 10.0.0 RC0 has been staged under [1] and it's > time to vote on accepting it for release. If approved we will seek > final release approval from the IPMC. Voting will be open for 72hr. Summary: +1 to

Re: Getting stuck in _up_assert()

On Mon, Nov 23, 2020 at 5:18 PM Gregory Nutt wrote: > You can try the section on hardfault debugging here: > https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf That > starts at slide 17: > > /Set a breakpoint on up_hardfault and up_assert//Set the PC equal to > the

Getting stuck in _up_assert()

Some months ago I implemented the basic architectural support for STM32G47xxx and I noticed that occasionally, during startup, I am getting stuck in _up_assert(). It is not happening consistently. It's intermittent. I'm not really sure why. Any ideas what I should look for? Here is the backtrace:

Re: Mistake in comment describing USEC_PER_TICK?

Thanks for confirming. I submitted PR #2378 Cheers, Nathan On Sun, Nov 22, 2020 at 5:15 PM Alan Carvalho de Assis wrote: > You are right, it should be 100Hz instead 100KHz. > > On 11/22/20, Nathan Hartman wrote: > > Is there a mistake in the following comment in includ

Mistake in comment describing USEC_PER_TICK?

Is there a mistake in the following comment in include/nuttx/clock.h? [[[ /* If CONFIG_SCHED_TICKLESS is not defined, then the interrupt interval of * the system timer is given by USEC_PER_TICK. This is the expected number * of microseconds between calls from the processor-specific logic to *

Re: IP Clearance

On Wed, Oct 14, 2020 at 9:54 AM Matias N. wrote: > > The scripts are still in a draft PR, they were not merged. I was waiting for > confirmation for others to test. > The remaining issue was about the ability to deal with files in submodules. > Right now it just errors out. > I will see I can

STM32G4 DAC support

For STM32 family, DAC register mappings are defined in arch/arm/src/stm32/hardware/stm32_dac.h. In STM32Gx parts, the DAC has additional features and registers not in STM32Fx and STM32Lx parts. I propose to handle this as follows: * Rename stm32_dac.h to stm32fx_dac.h * Create a

Re: interrupt priorities on nRF52

On Wed, Oct 28, 2020 at 1:10 PM Matias N. wrote: > I'm okay with ns jitter. I need to satisfy a 150uS timing response, so > that is OK. > > Outside the context of RTOSs, isn't this just defining your own interrupt > handler? Maybe > it should be called "custom interrupt handler"? > Well I think

Re: interrupt priorities on nRF52

On Tue, Oct 27, 2020 at 10:21 AM Alan Carvalho de Assis wrote: > Hi Nathan, > > I totally agree! Zero Jitter Interrupt is a better name. > > We don't have zero latency, we have zero jitter. > > BR, > > Alan The latency is pretty close to zero too, because it interrupts whatever else is

Re: interrupt priorities on nRF52

On Tue, Oct 27, 2020 at 10:03 AM Matias N. wrote: > Hi Nathan, > as I mentioned in my previous email, this isn't about overhead, is about > other ISRs delaying mine. I didn't see your reply until after, but Zero Latency Interrupts should more aptly be called Zero Jitter Interrupt, because

Re: interrupt priorities on nRF52

On Tue, Oct 27, 2020 at 4:09 AM Xiang Xiao wrote: > On Tue, Oct 27, 2020 at 7:43 AM Matias N. wrote: > > > As Greg mentioned in the corresponding open issue, TizenRT took Greg's > > snippets from the Wiki page and mostly implemented that. Couldn't really > > find more changes than that, so I'm

Re: [OT] Support to Sparkfun MicroMod

On Fri, Oct 23, 2020 at 12:20 PM Alan Carvalho de Assis wrote: > Hi Everyone, > > Sparkfun just created an interesting board ecosystem that could let > people to replace the MCU module and still having access to the base > board features: > > https://www.sparkfun.com/micromoddev > >

Re: NuttX and continuous ADC conversion

On Wed, Oct 21, 2020 at 2:26 PM wrote: > Thats correct... so I have to start the conversion every time over > again... and het the value after that conversion I have seen continuous > conversions ADC on an STM32... > > I will try to find a plausible solution. > Zero latency ISR to read ADC

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

On Fri, Oct 16, 2020 at 1:28 PM Eduard Niesner wrote: > I attached it as .txt. > > *Please note:* I made the code build and the SPI seems to work > as expected - I am communicating with an at45db flash over SPI and mounted > smartFS on it and the communication seems to work. I am not sure if >

Re: IP Clearance

On Wed, Oct 7, 2020 at 12:11 PM Matias N. wrote: > I think that for any non-coding/boring task the best bet (barring a paid > employee) > is to crowdsource the effort. You could compare this to the task of enforcing > code style: > it would be a huge task to convert all NuttX files to follow

Re: IP Clearance

On Thu, Oct 8, 2020 at 11:22 PM Matias N. wrote: > > > We need all of the above: > > > > 1. Integrate license clearing with ongoing work like we are already doing > > for nxstyle, *AND* > > I've created the following issue to remind ourselves of this: > >

Re: IP Clearance

On Wed, Oct 7, 2020 at 12:11 PM Matias N. wrote: > Hi, > I think that for any non-coding/boring task the best bet (barring a paid > employee) > is to crowdsource the effort. You could compare this to the task of > enforcing code style: > it would be a huge task to convert all NuttX files to

Re: Implicit declaration warning in RX65N due to ARCH_NOINTC configuration in arch/Kconfig

On Wed, Sep 30, 2020 at 2:44 AM Anjana wrote: > Hello Team, > > In arch/Kconfig, for Renesas architecture, the configuration ARCH_NOINTC > is selected as mentioned below : > > config ARCH_RENESAS > bool "Renesas" > select ARCH_NOINTC > select ARCH_HAVE_INTERRUPTSTACK > ---help--- > Renesas

Re: Nuttx for Nucleo-F429ZI

> On Mon, Sep 21, 2020, at 13:34, Nathan Hartman wrote: > > Need to mount procfs for ifconfig to work. On Wed, Sep 23, 2020 at 10:48 AM Matias N. wrote: > It would be really helpful if the "procfs" word appeared in that error. That > error is really cryptic. Agreed.

Re: [DISCUSS] NuttX 10.0.0 Release schedule

On Wed, Sep 23, 2020 at 9:55 AM Matias N. wrote: > > Ok, I created the "future" milestone for this. We should try to get all PRs > issues in either > of these two milestones during that week. > > Also, I'm not sure how you're finding all PRs for this release to build > release notes, but one

Re: Podling Nuttx Report Reminder - October 2020

On Sat, Sep 19, 2020 at 9:07 PM wrote: > The report for your podling will form a part of the Incubator PMC > report. The Incubator PMC requires your report to be submitted 2 weeks > before the board meeting, to allow sufficient time for review and > submission (Wed, October 07). > > Please submit

Re: [DISCUSS] NuttX 10.0.0 Release schedule

On Wed, Sep 23, 2020 at 9:33 AM Matias N. wrote: > also sounds good. During that week we could take all issues and PRs with > unassigned > milestone in GH and assign them to 10.0 or to an "untargeted" or "future" > release. > Those with 10.0 milestone should be merged/addressed to include in

Re: Fwd: Re: [nuttx] nuttx.org going away

On Tue, Sep 22, 2020 at 10:29 AM Abdelatif Guettouche wrote: > > > The question is: what do we have to do to move this forward? > > I suggest we start by creating a new thread with a clear title, > something like "Move GPL licensed repos "Buildroot, kconfig-front-ends > and tools" under Apache" >

Re: Fwd: Re: [nuttx] nuttx.org going away

ake the initiative and try to move forward with this. > > On Mon, Sep 21, 2020 at 8:25 PM Nathan Hartman > wrote: > > I am wondering what happened to the discussion that happened very > > early, before the incubator voted to accept our podling, when we were > > tol

Re: Fwd: Re: [nuttx] nuttx.org going away

On Mon, Sep 21, 2020 at 1:47 PM Gregory Nutt wrote: > >> I will also remove the Bitbucket mirrors of the Apache repositories. > > What is the "official" new location of the tools, buildroot, and > > uclibc repositories? > > They are still at https://bitbucket.org/nuttx/ but are not getting much >

Re: Fwd: Re: [nuttx] nuttx.org going away

On Wed, Sep 16, 2020 at 12:33 PM patacongo wrote: > I will also remove the Bitbucket mirrors of the Apache repositories. What is the "official" new location of the tools, buildroot, and uclibc repositories?

Re: Nuttx for Nucleo-F429ZI

On Sat, Sep 19, 2020 at 7:36 AM Flavio Castro Alves Filho wrote: > The problem that I am facing now is that is that the network interface > is not initializing: > > nsh> ifconfig > nsh: ifconfig: opendir failed: 20 Need to mount procfs for ifconfig to work. nsh> mount -t procfs /proc Nathan

Re: Nuttx for Nucleo-F429ZI

On Fri, Sep 18, 2020 at 3:17 PM Flavio Castro Alves Filho wrote: > I am studying NuttX for a new project. I am using Nucleo-F429ZI as > reference, which is quite a complete board and has a large memory for > testing. > > I followed some instructions from the internet (mostly from NuttX > website)

Re: Help with Apache Github Invite

Hi folks, Can we get this sorted out please: On Thu, Sep 17, 2020 at 10:25 AM Anthony Merlino wrote: > > FYI: I STILL do not have access to the Github organization. > > I have tried changing my email everywhere in apache to match my primary > email on Github. I've tried re-adding my Github

Re: PR's without adequate information

On Thu, Sep 17, 2020 at 10:02 AM Gregory Nutt wrote: > > > That's why we have committers. It's been said, but I'll repeat: As > > committers, I know it's mundane, but we really need to make sure the > commit > > and PR messages will be helpful to someone who looks at them in the > future. > >

Re: PR's without adequate information

On Thu, Sep 17, 2020 at 9:26 AM Gregory Nutt wrote: > > > An alternative is to use a workflow. For example this action does > something in that line: > https://github.com/marketplace/actions/pull-request-ticket-check-action > > > I think including the a PR comment check in the PR checks is a

Re: Next release?

On Sun, Sep 13, 2020 at 6:40 PM Gregory Nutt wrote: > Going from 8.x to 9.0 did not follow these rules. There was not > particular incompatibility at all. The major number changed only > because it was the first Apache release. Other people have suggested > boosting the major number to

Re: Next release?

On Sun, Sep 13, 2020 at 6:40 PM Gregory Nutt wrote: > > > I've been assiging various PRs from both repos to 10.0 milestone. > > Please also see if you think not assigned ones are to be surely included > > and assign them. I've not done this with issues as many are old ones > > for which no PR

Next release?

Hi folks, There have been many big changes since the last release including work focused on reducing memory footprint, a major overhaul of the documentation, and countless other things. We should get the next release started sometime soon. Is there anything in particular that we should wait on

Re: Porting NuttX to STM32L431

On Wed, Sep 9, 2020 at 5:50 PM Daniel Mesham wrote: > I am attempting to port NuttX to the STM32L431CC on a custom board. I have > done so by copying the config for the Nucleo-L432KC board, using pretty much > the same procedure as described here: >

Re: Warnings in Renesas common files

On Fri, Sep 4, 2020 at 9:40 AM Bhindhiya Raja wrote: > > Hello Nathan, > > Thank you for your response. We have submitted 2 separate PRs as recommended > by you to resolve warnings 6 (#1695) and 8 (#1702). > > About warnings 1 to 4, we understand that casting away the 'volatile' type >

Re: stm32 uart init bug?

On Fri, Sep 4, 2020 at 11:30 AM David Sidrane wrote: > 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

Re: stm32 uart init bug?

On Fri, Sep 4, 2020 at 9:46 AM Gregory Nutt wrote: > > > 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

Re: stm32 uart init bug?

On Thu, Sep 3, 2020 at 7:38 PM Gregory Nutt wrote: > Perhaps: > > Bit 10PCE: Parity control enableThis bit selects the hardware parity > control (generation and detection). When the parity control is enabled, > the computedparity is inserted at the MSB position (9th bit if M=1; 8th > bit if M=0)

stm32 uart init bug?

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 used a bootloader to flash and run NuttX on the arm/stm32/b-g474e-dpow1 board. The bootloader configs the UART for 115200 baud

Re: Warnings in Renesas common files

On Tue, Sep 1, 2020 at 8:12 AM Bhindhiya Raja wrote: > Hello Team, > > We are working on adding pre-check support for Renesas RX65N MCU. We are > getting the below warnings in the common files used across the Renesas MCUs > (M16, SH1 and RX65N). > > > 1.

Re: Cygwin Build Broken?

On Sun, Aug 30, 2020 at 2:04 PM Gregory Nutt wrote: > But look what happens under Cygwin: > > $ arm-none-eabi-gcc --print-file-name=libgcc.a > c:/program files (x86)/gnu tools arm embedded/9 > 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/libgcc.a > > $ dir `arm-none-eabi-gcc

Re: new documentation

On Mon, Aug 17, 2020 at 4:28 PM Matias N. wrote: > Hi everyone, > > just wanted to let you know in case it was lost in the sea of github > notification emails that today I undraft the > "new documentation" PR so that you can start reviewing it. Please have a > look at the PR description to get a

Re: 10.0 Release?

On Fri, Aug 14, 2020 at 2:51 PM Gregory Nutt wrote: > > > Nathan started this here: > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2 > > > > I would say let's fill that out, we can change it to 10.0 later. I > > will kick off getting the tracking board and the PR changes going in

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

Re: Board-specific drivers in NuttX 9.1.0.

On Tue, Aug 11, 2020 at 1:14 PM Fotis Panagiotopoulos wrote: The structure proposed by Xiang Xiao is not working for me. > > By looking in the Makefiles, I did understand that the structure has > changed a bit. > Now my structure is: > > ├── CustomBoard > │ ├── defconfig > │ ├── include > │

Re: STM32 IO Compensation Cell bug

On Sun, Aug 9, 2020 at 9:57 AM Fotis Panagiotopoulos wrote: > I just tried the following patch, and the code runs normally. > Shall I make a PR? Thank you for finding this. Yes, I think you should make a PR. Nathan

Re: Some questions related PR#1478

On Fri, Jul 31, 2020 at 10:55 AM Gregory Nutt wrote: > > Hmmm... I don't agree. > > > > The Coding Standard encourages empty "while loops": > > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#while > > Why should this not applicable for "for loops"? I think there are many > >

Re: Some questions related PR#1478

On Fri, Jul 31, 2020 at 9:46 AM Schock, Johannes - NIVUS GmbH < johannes.sch...@nivus.com> wrote: > Hello, > I have two questions related PR#1478 ( > https://github.com/apache/incubator-nuttx/pull/1478): > > 1. I think there's a configuration error with "Build / macOS (sim)" since > it is using

Re: AMD64 arch

On Wed, Jul 29, 2020 at 2:35 PM Robert Faron wrote: > > Once I an get the system to boot I will need to be able to run a compiled > program. I assume I will have to rewrite my little linux test program using > nuttx. At it's simplest the test program can be hard programed to the > correct bar

Re: Can we implement ctype functions through table?

Macros that evaluate their parameters more than once are dangerous for a variety of reasons. On Wed, Jul 29, 2020 at 11:32 AM David Sidrane wrote: > K warns against using macros in loops. Experienced programmers (especially > embedded) know not to write code like shown in the "reason" for

Re: deprecating old list?

On Tue, Jul 28, 2020 at 2:58 PM Matias N. wrote: > wouldn't it be best to disable posting and subscription to the old google > groups and add an auto-reply message which indicates that they should > subscribe to the new group? > > Here are a few indications on how that can be done: >

Re: AMD64 arch

On Tue, Jul 28, 2020 at 11:32 AM Robert Faron wrote: > I am looking for a RTOS to replace the current RTOS we use. We are currently > using FreeDOS, however since it is 16bit it have found it almost impossible > to access a new device, PCIe mmio. While searching the web for a RTOS I > found

Re: Integrating Nuttx to a firmware project.

On Fri, Jul 24, 2020 at 3:49 PM Adam Feuer wrote: > > On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt wrote: > > > a dumb script like that one Abdelatif demonstrated > > will multiple calls to kconfig-tweak can be used to turn on all of the > > configuration options that you need. > > > > Cool! I

Re: Integrating Nuttx to a firmware project.

On Fri, Jul 24, 2020 at 12:26 PM Fotis Panagiotopoulos wrote: > Hello, > > So, I have set up my workspace now, and I have NuttX running properly on my > custom board. > I have another question though, regarding how to set things up for > development. > > Usually I have at least 2 build

Re: Markdown READMEs?

On Mon, Jul 20, 2020 at 7:07 PM Gregory Nutt wrote: > For those really opposed to HTML, another option is to simply use the > Confluence versions of the documents here: > https://cwiki.apache.org/confluence/display/NUTTX/Documentation > > These are the same documents that are currently in

Re: [RESULT] [VOTE] Release Apache NuttX (Incubating) 9.1.0 [RC2]

On Tue, Jul 14, 2020 at 11:53 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > I had this concern as well, but then went to [1] and checked [2]. > Everything seems good. > > 1. https://lists.apache.org/list.html?gene...@incubator.apache.org > 2. >

Re: [RESULT] [VOTE] Release Apache NuttX (Incubating) 9.1.0 [RC2]

On Sun, Jul 12, 2020 at 8:14 PM Brennan Ashton wrote: > > The vote closes now as over 72hr have passed. The vote PASSES with > > 6 (+6 non-binding) votes from the PPMC, 0 (+1 binding) vote from the > > IPMC, > > 0 (+0 non-binding) votes from the developer community, > > 0 (+1 non-binding) vote

Re: Integrating Nuttx to a firmware project.

On Tue, Jul 14, 2020 at 7:48 AM Fotis Panagiotopoulos wrote: > Another thing that I was thinking is about NuttX configuration. The file > .config is included in the .gitignore file. So the actual NuttX > configuration is not tracked. > How do you usually handle this? I manually save that file

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC2 release

On Tue, Jul 7, 2020 at 8:40 PM Brennan Ashton wrote: > Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time > to vote on accepting it for release. If approved we will seek final > release approval from the IPMC. Voting will be open for 72hr. > > This RC replaces RC1 which was

Re: UART driver without tx empty interrupt

On Mon, Jul 6, 2020 at 9:48 PM Brennan Ashton wrote: > The EOS S3 SOC unfortunately seems to have very limited interrupt > support for the UART peripheral. The TX interrupt is limited to when > the tx fifo reaches certain levels of full and does not seem to have a > FIFO "empty" interrupt which

Re: close() socket called in second thread combined with reconnect kills eth (stm32h743zi)

Ping... this question seemed to be waiting on our mailing list for several days: On Tue, Jun 30, 2020 at 4:58 AM Reto Gähwiler wrote: > I am facing the following problem working with nuttx and ethernet > connections. A TCP socket is setup as blocking and connected to the server. > The connection

Re: [OT] WebAssembly Micro Runtime

On Sun, Jul 5, 2020 at 8:48 AM Alan Carvalho de Assis wrote: > Please let me know if someone here knows something about it: > > https://github.com/bytecodealliance/wasm-micro-runtime (snip) > Linux, Zephyr, MacOS, VxWorks, AliOS-Things, Intel Software Guard > Extention (Linux), Android > >

Re: Help with Apache Github Invite

On Thu, Jul 2, 2020 at 1:16 PM Anthony Merlino wrote: > Is there an infra email address I should use to get help with this? Hi Anthony, It sounds to me like something fell through a crack somewhere. I think you should email us...@infra.apache.org. Sorry you're having all these issues...

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

On Thu, Jul 2, 2020 at 1:12 PM Nathan Hartman wrote: > Summary: > +1 to release > > Development system: Linux > > Verified: > * Signatures (note GPG reports the key is expired) Correction, follow-up: I re-imported the key. GPG no longer reports the key as expired. My vot

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

On Tue, Jun 30, 2020 at 1:58 AM Brennan Ashton wrote: > Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time > to vote on accepting it for release. If approved we will seek final > release approval from the IPMC. Voting will be open for 72hr. This RC > replaces RC0 which was

Re: Board report due by July 1st

On Wed, Jul 1, 2020 at 7:23 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > Hi, > > I filled in some blanks. The report is due today but we still have > some time for last minute changes. Thanks, the changes look good. I'm away from my computer today; could you submit the

Re: [DISCUSS] NuttX 9.1 RC1

On Mon, Jun 29, 2020 at 6:04 PM Brennan Ashton wrote: > I held off on cutting the release yesterday since not everything had > been backported yet and I had not heard of any other testing. > > There is one remaining PR for a backport which I just opened >

Fwd: Announcing ApacheCon @Home 2020

Perhaps this is an opportunity to present some of the materials that would have been presented at the NuttX conference that was canceled due to the virus? Forwarded message below... -- Forwarded message - From: Rich Bowen Date: Mon, Jun 29, 2020 at 11:19 AM Subject: Announcing

Re: [DISCUSS] NuttX 9.1 RC1

On Fri, Jun 26, 2020 at 1:48 PM Brennan Ashton wrote: > Hey everyone, > There were several bugs found on the RC0 so we will not be moving forward > with that release candidate and will be creating RC1. I had suggested a > few days ago creating the release today, but as we merged some changes >

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

On Fri, Jun 26, 2020 at 9:35 AM Jerpelea, Alin wrote: > Hi Justin, > > I can confirm that the latest branch looks good > We should create RC1 wih the fixes included to start the testing and > voting for RC1 What about the bug report about mm_realloc() reported by a user on 24 Jun:

Re: Creating 9.1.0-RC0

On Mon, Jun 22, 2020 at 10:13 PM Brennan Ashton wrote: > On Mon, Jun 22, 2020, 5:38 PM Nathan Hartman > wrote: > > > On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche > > wrote: > > > I created a PR copying the release notes from Confluence to ReleaseNote

Re: Creating 9.1.0-RC0

On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche wrote: > I created a PR copying the release notes from Confluence to ReleaseNote file. > I did not copy the "Compatibility Concerns" part, that's valuable > information but I don't think it belongs to that file, just because > there is a lot of

Board report due by July 1st

We are scheduled to submit our board report by July 1st. I have created a Confluence page [1] with some initial content. Please review and make any additions/changes/corrections. [1] https://cwiki.apache.org/confluence/display/NUTTX/July+2020 Cheers, Nathan

Re: Creating 9.1.0-RC0

On Mon, Jun 22, 2020 at 10:35 AM Gregory Nutt wrote: > I created PR 1277 to add that to documentation: > > > > https://github.com/apache/incubator-nuttx/pull/1277 > The Confluence landing page needs to be updated too (usually not more > than half dozen words). > Done. Thanks for the reminder.

Re: Creating 9.1.0-RC0

On Mon, Jun 22, 2020 at 7:01 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > With regards to bringing the release notes to the repo, that needs to > go to master then backported to the release branch. Are we all on the > same page with this? +1 We also need to update a

Re: The new Apache NuttX Logo

On Fri, Jun 19, 2020 at 9:47 AM Nathan Hartman wrote: > On Fri, Jun 19, 2020 at 9:25 AM Gregory Nutt wrote: > > NuttX was created in Costa Rica so an animal from Costa Rica does not > > seem in appropriate. Here the most beloved animals are (1) the > > rainforest frog

Re: The new Apache NuttX Logo

On Fri, Jun 19, 2020 at 9:25 AM Gregory Nutt wrote: > NuttX was created in Costa Rica so an animal from Costa Rica does not > seem in appropriate. Here the most beloved animals are (1) the > rainforest frogs, the red-eyed rain forest frog in particular: In addition to real animals, we could

Re: The new Apache NuttX Logo

On Thu, Jun 18, 2020 at 7:43 AM Erdem MEYDANLI wrote: > I wanted to revive this discussion. As I stated before, I and a friend of > mine (a graphical artist.) will start working on this. But, > > - What's the deadline for this? (A deadline is a powerful force for > motivation.) Feel free to

Re: SAMA5D27 SDMMC support branch

On Wed, Jun 17, 2020 at 5:49 PM Adam Feuer wrote: > SDMMC write is working now too. So the driver can do the following: > >- Non-DMA read and write >- DMA read and write in SDMA mode >- 1 bit bus >- 4 bit bus (widebus) >- up to 25Mhz > > I'm going to work on cleanup,

Re: release branches/tags

On Mon, Jun 15, 2020 at 3:41 PM Matias N. wrote: > Functionally, yes. But git has troubles recognizing that the cherry-picked > commits are the same on master and generates conflicts. The merge would > solve this in theory, since the release branch tip would end up matching a > commit on master.

Re: Release 9.1

On Mon, Jun 15, 2020 at 8:58 AM Abdelatif Guettouche wrote: > Hi all, > > D-Day; I'll go ahead and create the branches. Thank you! I went ahead and created a blank release notes wiki for the *next* release, 9.2, here: https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2 If there's

Re: Hold off merging PRs

On Sun, Jun 14, 2020 at 11:04 PM spudaneco wrote: > I see a few new PRs coming in. I want to remind everyone that tomorrow we > plan the branch for release/9.1. If committers could hold off merging > until that branch is in place, the I think we have a chance for a good > release

Re: MSYS2 build slow

On Sun, May 31, 2020 at 12:41 PM Nathan Hartman wrote: > FWIW the build has become noticeably faster for me with latest master: > 1m21s now. Before, the build consistently took about 1m50s. So that's > 30 seconds saved. I build on Linux. I just wanted to follow up on this and say that a

Re: SAMA5D27 SDMMC support branch

On Thu, Jun 11, 2020 at 5:26 PM Adam Feuer wrote: > This module does have a 50Mhz SDIO interface, so if it can use 4 bit mode, > it could work. However, the ATWIL3000 Linux driver on Github > does not appear to have an open > license– all the code is marked

Re: New Wiki Page

On Thu, Jun 11, 2020 at 10:07 AM Gregory Nutt wrote: > Why Can't Kernel Threads Have pthreads? > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158862687 Thank you! Nathan

Re: Organising Release Notes for 9.1

On Sun, Jun 7, 2020 at 9:42 PM Brennan Ashton wrote: > Just a quick update, all of the OS PRs have been gone through (352). > Thanks Abdelatif for helping out just now, it was nice to see that > this workflow seemed to actually work quite well even with both of us > editing the board and wiki

Re: [DISCUSS] requirements for commit messages and PRs

On Thu, Jun 4, 2020 at 7:19 PM Jukka Laitinen wrote: > But the template in the commit... please, no. I have had enough of those > in big companies and in the end they are just harmful. I agree with that!! We should not be too rigid and complicated. The more I think about it, the more I like

Re: [DISCUSS] requirements for commit messages and PRs

On Thu, Jun 4, 2020 at 1:19 PM Gregory Nutt wrote: > Why don't we require that the reviewer fill in those sections. The main > reason that they are not filled in now is language barrier issues, not > willingness to contribute. Forcing someone who has marginal English > skills to write prose to

Re: [DISCUSS] requirements for commit messages and PRs

On Thu, Jun 4, 2020 at 12:32 PM Gregory Nutt wrote: > Yes. Simplicity is single most important thing. The entire template > should fit entirely within the PR comment window. It should not be a > punishment to contributors to the project. We will get a better > response if it is simple and

Re: [DISCUSS] requirements for commit messages and PRs

On Thu, Jun 4, 2020 at 11:54 AM Gregory Nutt wrote: > >> See > >> https://github.com/nuttx-to-asf/incubator-nuttx/commit/b496ee7ff9adeaa9020e7b07efed8198d4e8e623 > >> > > > > The is HORRIBLE!!! God help us. > Full disclosure: I am the guy with the "lack of working project > experience

Re: Organising Release Notes for 9.1

On Thu, Jun 4, 2020 at 10:07 AM David Sidrane wrote: > I had this in the original PR I submitted for the templates. That got > changed due to lack of working project experience and vision. The Apache way > is not being followed here: the PMC is not voting on things we should be. > > Can we work

Re: Release 9.1

On Wed, Jun 3, 2020 at 5:36 PM Adam Feuer wrote: > I got stuck, and switched to Linux. But I will give macOS a try again in > the next few days, and update the instructions if I succeed. I built a recent master on macOS and it worked. All I had to do was: * Install gcc-arm-none-eabi using

Re: Organising Release Notes for 9.1

On Thu, Jun 4, 2020 at 7:58 AM David Sidrane wrote: > I think _Every PR_ needs a description do begin to be a responsible and > professional contribution. The small extra level of effort will keep the > team informed and provide the documentation for the release process. We > should not have to

Re: Organising Release Notes for 9.1

On Thu, Jun 4, 2020 at 2:07 AM Brennan Ashton wrote: > So Nathan has done an awesome job getting a start on the release notes for > 9.1, but so far he has done all of the work and it is a little hard to see > where we have left off and to work together adding the content. >

Re: MSYS2 build slow

On Sun, May 31, 2020 at 12:44 PM Gregory Nutt wrote: > > > FWIW the build has become noticeably faster for me with latest master: > > 1m21s now. Before, the build consistently took about 1m50s. So that's > > 30 seconds saved. I build on Linux. > yes I have seen improvements of 25-30% on all

Re: MSYS2 build slow

On Wed, May 27, 2020 at 8:06 PM Nathan Hartman wrote: > I build on Linux and those build times seem fast to me (20-30 seconds, 45-60 > seconds). I don't know if I've ever had builds that fast, but it might be my > configurations, or my machine. I'll build one now... > > Latest

<    1   2   3   4   5   6   7   8   9   >