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
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
> 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
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
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ó:
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
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
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
> 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
> 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_
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
> 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
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
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
> 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
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
>
> 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
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
> -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
> >
Hi Grr,
Could you please test your driver with the following application:
/
* hello_main
/
int main(int argc, FAR char *argv[])
{
char name[
>
> 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 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
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.
>
>
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
Yes, but it was really low level logging and didn't understand much. I'll try
again later and paste it here.
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.
I actually delete gitbox messages on arrival. I find GitHub notifications much
more usable.
Best,
Matias
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
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
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
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
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
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
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?
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
35 matches
Mail list logo
