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

[Abdelatif Guettouche]

Sorry, dropped the dev list..


> > 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"
> I believe Greg did this before but we only had a discussion, we didn't
> reach an agreement.
> This time, it's more of a heads up, unless someone has an objection.
>


On Mon, Sep 21, 2020 at 11:08 PM Nathan Hartman 
wrote:

> On Mon, Sep 21, 2020 at 3:51 PM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
>> We also had the discussion after entering the incubator and if I'm not
>> mistaken mentors have said that it's possible to bring those
>> repositories under Apache.
>> Maybe we should take 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
>> > told that sometimes exceptions are made allowing projects to host
>> > well-known 3rd party code. Because the NuttX buildroot, mirror of
>> > Kconfig-frontends, and other tools, are pretty important for this
>> > project.
>
>
>
> That is my recollection as well.
>
> The question is: what do we have to do to move this forward?
>
> Nathan
>
> --
> This group has moved to the Apache Foundation:
> http://nuttx.incubator.apache.org/community/
> ---
> You received this message because you are subscribed to the Google Groups
> "NuttX" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nuttx+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/nuttx/CAJT2EHqndX-2AhEF_pY8BN_6nb0Uvtv4gPO9CbeJd6RwWU3yEw%40mail.gmail.com
> 
> .
>

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

[Abdelatif Guettouche]

I'm clicking the send button too fast... I meant we wait for some time (72
hours?) If no one has an objection we go ahead and create the new repos.


On Tue, Sep 22, 2020, 16:26 Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> Sorry, dropped the dev list..
>
>
>> > 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"
>> I believe Greg did this before but we only had a discussion, we didn't
>> reach an agreement.
>> This time, it's more of a heads up, unless someone has an objection.
>>
>
>
> On Mon, Sep 21, 2020 at 11:08 PM Nathan Hartman 
> wrote:
>
>> On Mon, Sep 21, 2020 at 3:51 PM Abdelatif Guettouche <
>> abdelatif.guettou...@gmail.com> wrote:
>>
>>> We also had the discussion after entering the incubator and if I'm not
>>> mistaken mentors have said that it's possible to bring those
>>> repositories under Apache.
>>> Maybe we should take 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
>>> > told that sometimes exceptions are made allowing projects to host
>>> > well-known 3rd party code. Because the NuttX buildroot, mirror of
>>> > Kconfig-frontends, and other tools, are pretty important for this
>>> > project.
>>
>>
>>
>> That is my recollection as well.
>>
>> The question is: what do we have to do to move this forward?
>>
>> Nathan
>>
>> --
>> This group has moved to the Apache Foundation:
>> http://nuttx.incubator.apache.org/community/
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "NuttX" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nuttx+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/nuttx/CAJT2EHqndX-2AhEF_pY8BN_6nb0Uvtv4gPO9CbeJd6RwWU3yEw%40mail.gmail.com
>> 
>> .
>>
>

RE: i.MX RT 1060 ADC

[Thomas Axelsson]

Hi,

I have now created a PR for a simple IMXRT ADC driver. ( 
https://github.com/apache/incubator-nuttx/pull/1868 )

The names of register bit values for ADC_CFG:ADSTS do not match between IMXRT 
1020 and 1050/1060.
This PR changes them to match for 1050/1060, but I guess it should be split 
into two files - or possibly have an ifdef for the chip? Please provide advise 
on this issue.
https://github.com/apache/incubator-nuttx/pull/1868/files#diff-d732b4fa83e7f3fbf6ac34c1203cef60

BR
Thomas

-Original Message-
From: Thomas Axelsson  
Sent: den 16 september 2020 09:05
To: dev@nuttx.apache.org
Subject: RE: i.MX RT 1060 ADC

Thank you, David,

It's good to have a working example.

Regarding the existing ADC code, I realized that I had only diffed over the 
various LPCxxx drivers. My current starting point is the LPC driver with things 
picked from the STM32. The LPC driver is simpler (STM32 handles many variants), 
while the STM32 driver has a clearer multi-ADC and multi-channel structure 
(although I just realized that mask in the LPC driver might be the channel 
selector). Just writing this here in case someone wants to point me in another 
direction.

BR
Thomas

-Original Message-
From: David Sidrane  
Sent: den 15 september 2020 12:15
To: dev@nuttx.apache.org
Subject: 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 meat, but you will have to do it in nuttx style using the
{get|set}reg32 calls.

David

-Original Message-
From: Thomas Axelsson [mailto:thomas.axels...@actia.se]
Sent: Tuesday, September 15, 2020 2:55 AM
To: dev@nuttx.apache.org
Subject: i.MX RT 1060 ADC

Hi,

I'm looking into using the ADC on IMXRT 1060. I have found imxrt_adc.h and some 
examples in nuttx-apps using /dev/adcXX. However, it seems that the actual 
functionality is not yet implemented for IMXRT.

So I'm looking into implementing this driver, based on e.g. lpc17_40_adc.c 
(diffing all *_adc.c files turned up almost no differences). I tried grepping 
for some register names to see if the IP block is already implemented for 
another chip, but without luck.

I'm sending this e-mail to see if someone else is already working on the same 
thing. I did see that imxrt_adc.h has gotten some updates.

Thomas Axelsson
SW Developer
ACTIA Nordic AB (part of ACTIA Group)

Mail: thomas.axels...@actia.se
Web: www.actia.se

[DISCUSS] NuttX 10.0.0 Release schedule

[Brennan Ashton]

Hey all, we have talked in loose terms about this release, but I think
it is time we committed, it has been probably too long since our last
release.

Here is what I would propose for a release schedule:

  09/28/20 -- Master Stability Window (keep the merging of risky PRs
to a minimum this week)
  10/03/20 -- Create the 10.0 release branch
  10/04/20 - 10/12/20 -- Stabilize / test / release notes
 Additionally in this window we need to make a couple CI tweeks to
handle the new docs off of the release branch (I expect this won't be
much work, but will be easier with the branch in place)
  10/12/20 -- Tag RC0 and call for PPMC / Community Vote
  10/15/20 (or when we have the votes) Call for IPMC Vote  or create a
new RC if needed to address issues
  10/23/20 (Pending votes and RC0 issues) --  Release RC0
  10/24/20 -- Update site and announce (we have to wait for download
mirrors to sync).

I know that is almost a month, but that is usually about how long it
takes for the whole process, but realistically there is only a week or
so where we are aiming to slow down and stabilize the master branch.
The rest of it is testing, documenting, voting, and waiting time.

I can be the release manager again for this one. But it would be great
if someone else jumps in for the release after and I will try to
document things a bit more to make the process easier.  We will need
to have more than one release manage to graduate, there are other
projects that have run into this.

--Brennan