Hi,
I saw a new option for merging in GH Auto merge when CI completes.
What is the group's opinion on having this enabled?
David
We set it manually right?
I mean after reviewing we can set the PR to be merged when the CI
checks are done?
On Fri, Feb 5, 2021 at 10:53 AM David Sidrane wrote:
>
> Hi,
>
> I saw a new option for merging in GH Auto merge when CI completes.
>
> What is the group's opinion on having this enabled?
Yes.
But that feature needs to be enabled for us by infra.
-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Friday, February 05, 2021 2:04 AM
To: dev@nuttx.apache.org
Subject: Re: I saw a new option for merging in GH: Auto merge when CI
completes
Is anything printed? Are the IP addresses set correctly? You can
change all that, and enable DHCP if need be, from Apps -> Network
Utilities -> Network Initialization
On Fri, Feb 5, 2021 at 12:12 AM Matias N. wrote:
>
> Thanks, I was looking at the DevKitC readme which does not have these
> in
Anyone else getting repeated emails from the GitBox?
-Original Message-
From: GitBox [mailto:g...@apache.org]
Sent: Friday, February 05, 2021 2:29 AM
To: comm...@nuttx.apache.org
Subject: [GitHub] [incubator-nuttx] xiaoxiang781216 merged pull request
#2805: imxrt1060 iperf
xiaoxiang781
All of Gitbox emails are now going to commits@ which you can filter
out or simply unsubscribe.
On Fri, Feb 5, 2021 at 11:40 AM David Sidrane wrote:
>
> Anyone else getting repeated emails from the GitBox?
>
>
>
> -Original Message-
> From: GitBox [mailto:g...@apache.org]
> Sent: Friday, F
Are you getting duplicate same email a day later?
-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Friday, February 05, 2021 2:47 AM
To: dev@nuttx.apache.org
Subject: Re: Anyone else getting repeated emails from the GitBox?
All of Gitbox emails a
No, it's been a while since I got a Gitbox email. I set Gmail to auto
archive them.
BTW, it's seems that we can redirect those emails ourselves, we used
to go through a JIRA issue for infra:
https://github.com/apache/hadoop/blob/trunk/.asf.yaml#L21-L25
On Fri, Feb 5, 2021 at 11:50 AM David Sidra
I actually delete gitbox messages on arrival. I find GitHub notifications much
more usable.
Best,
Matias
Yes this would be a useful feature.
Assuming that the trigger disarms if there's a new push in between, which may
require new review.
Yes, but it was really low level logging and didn't understand much. I'll try
again later and paste it here.
Best,
Matias
I totally agree, I was always concerned that commits to the Apache directly
would get missed. So I had it on.
I could not even unsubscribe
Hi! This is the ezmlm program. I'm managing the comm...@nuttx.apache.org
mailing list.
Acknowledgment: The address
david.sidr...@nscdg.com
was not on t
On Fri, Feb 5, 2021 at 8:32 AM David Sidrane
wrote:
> I totally agree, I was always concerned that commits to the Apache directly
> would get missed. So I had it on.
>
>
> I could not even unsubscribe
>
> Hi! This is the ezmlm program. I'm managing the comm...@nuttx.apache.org
> mailing list.
>
>
Hi all,
I am thinking of using the STM32H747XI for a project I'm working on. This
particular chip has a CortexM7 and a Cortex M4. The chips access the same
memory map and can access and even share the same peripherals.
Part of the problem, however, is that NuttX resets many
registers/peripherals
>
> We achieve this by:
>
>1. Chip driver implement io expander driver to encapsulate the gpio
>hardware
>2. Generic driver control the gpio through the io expander driver
>directly e.g.:
>
>
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L72
Hi Grr,
Could you please test your driver with the following application:
/
* hello_main
/
int main(int argc, FAR char *argv[])
{
char name[
> -Original Message-
> From: Grr
> Sent: Friday, February 5, 2021 11:56 PM
> To: dev@nuttx.apache.org
> Subject: Re: Proper handling of arch header files
>
> >
>
> > We achieve this by:
> >
> >1. Chip driver implement io expander driver to encapsulate the gpio
> >hardware
> >
On Wed, Feb 3, 2021 at 3:50 PM bryan costanich
wrote:
> Our interests align, maybe we can help? Ping me. :)
>
This looks interesting. Very interesting. I have not heard of MCUBoot
before. Apache2 license (that's what it says on the GitHub) so I suppose
we're compatible on that aspect. Also works
>
> Yes, we need an additional struct for port number:
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L49-L57
> struct lcd_ili9486_config_s
> {
> uint8_t power_gpio;
> uint8_t rst_gpio;
> uint8_t spi_cs_num;
> uint8_t spi_rs_gpio;
> uint32_t spi_fre
You cannot include arch specific headers in board.h like that! That will
break a lot of things.
The expectation is that you pass the interfaces that you need into the
drivers. If you have a particular "module" which contains multiple devices
that you want to support across different boards then
> You cannot include arch specific headers in board.h like that! That will
> break a lot of things.
>
board.h is arch specific
> The expectation is that you pass the interfaces that you need into the
> drivers. If you have a particular "module" which contains multiple devices
> that you want t
On Fri, Feb 5, 2021, 4:40 PM Grr wrote:
> > You cannot include arch specific headers in board.h like that! That will
> > break a lot of things.
> >
>
> board.h is arch specific
> It absolutely is not including arch headers will break things.
board.h:
https://www.github.com/apache/incubator-nu
Is this helpful?
https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
On 2/5/2021 7:34 PM, Brennan Ashton wrote:
On Fri, Feb 5, 2021, 4:40 PM Grr wrote:
You cannot include arch specific headers in board.h like that! That will
break a lot of things.
board.h is arch
> It absolutely is not including arch headers will break things.
>
> board.h:
>
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Finclude%2Fboard.h
>
> And the arch specific board configuration:
>
> https://www.github.com/apache/incubator-nuttx/tr
On Fri, Feb 5, 2021, 5:55 PM Grr wrote:
> > It absolutely is not including arch headers will break things.
> >
> > board.h:
> >
> >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Finclude%2Fboard.h
> >
> > And the arch specific board configura
> Is this helpful?
>
> https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
Maybe but I think it would obscure things. I explain:
Per my idea, exporting available GPIOs is done from board.h like this:
#ifdef CONFIG_GPIO_1
# if defined(CONFIG_GPIO_1_OUT)
# define GPIO_1_
> But there is a problem with it, which is why it's hard to do this. Please
> read the wiki page Greg posted which explains why you cannot include chip
> specific headers in board.h
>
> What is it that must go in there?
>
All this comes from my idea of solving driver balkanization. It's illogical
I'm not entirely following the problem, but it sounds like you could decouple
your arch-independent driver logic in an upper-half and then have a lower-half
per-arch, using board-common drivers (ie. boards/stm32/drivers). The lower-half
would then be able to use stm32 internal headers. In this s
Per arch is better but not enough if the goal is to keep header files in
src/ instead of include/, where every interested party would access them
easily
El vie, 5 feb 2021 a las 20:21, Matias N. () escribió:
> I'm not entirely following the problem, but it sounds like you could
> decouple your ar
A good modular design should strive to hide information behind
interfaces and not expose that information globally. Global anything is
the path to spaghetti code:
Google for "information hiding in modular design"
* https://john.cs.olemiss.edu/~hcc/csci450/notes/ModularDesign.html
* https://e
If board.h defining a bunch of macros is violating modularity principle,
then pretty much all NuttX header files are living in sin
What I proposed is _not_ violating modularity more than
stm32f40xxx_memorymap.h defining STM32_GPIOE_BASE
El vie, 5 feb 2021 a las 21:05, Gregory Nutt ()
escribió:
On Fri, Feb 5, 2021, 7:32 PM Grr wrote:
> If board.h defining a bunch of macros is violating modularity principle,
> then pretty much all NuttX header files are living in sin
>
> What I proposed is _not_ violating modularity more than
> stm32f40xxx_memorymap.h defining STM32_GPIOE_BASE
>
I'm ver
> What you could do is expose GPIO to a driver via an arch agnostic
> interface.
That's exactly what I'm doing: board.h exposes (or exports) GPIO parameters
and the arch agnostic interface populates corresponding struct gpiodev_s,
accessible via struct gpioops_s functions, just like many other Nu
Just a final explanation:
"why you want to expose the base address for a GPIO perf
of a _chip_ everywhere"
It's _not_ everywhere, just the code that includes board.h, just like _any_
other header file
And I want gpiodev_s to store specific arch information (the _more_
specific, the better) becau
On Fri, Feb 5, 2021, 8:43 PM Grr wrote:
> Just a final explanation:
>
> "why you want to expose the base address for a GPIO perf
> of a _chip_ everywhere"
>
> It's _not_ everywhere, just the code that includes board.h, just like _any_
> other header file
> gpio_setpin()
Arch specific ones are
35 matches
Mail list logo
