Re: Ethernet cable (network interface availability) detection

[Flavio Castro Alves Filho]

Gregory,

Thank you for your support. I will work on this.

Best regards.

Flavio

Em qua., 14 de abr. de 2021 11:09, Gregory Nutt 
escreveu:

> You board must provide CONFIG_ARCH_PHY_INTERRUPT:
>
> $ find boards/ -name Kconfig | xargs grep ARCH_PHY_INTERRUPT
> boards/Kconfig: select ARCH_PHY_INTERRUPT
> boards/Kconfig: select ARCH_PHY_INTERRUPT if SAMA5_EMACA ||
> SAMA5_EMAC0 || SAMA5_EMAC1 || SAMA5_GMAC
> boards/Kconfig: select ARCH_PHY_INTERRUPT
> boards/Kconfig: select ARCH_PHY_INTERRUPT
> boards/Kconfig: select ARCH_PHY_INTERRUPT
> boards/Kconfig: select ARCH_PHY_INTERRUPT
> boards/Kconfig: select ARCH_PHY_INTERRUPT
>
> and you must implement PHY interrupt handling as documented in
> include/nuttx/arch.h:
>
>
> /
>   * Name: arch_phy_irq
>   *
>   * Description:
>   *   This function may be called to register an interrupt handler
> that will
>   *   be called when a PHY interrupt occurs.  This function both
> attaches
>   *   the interrupt handler and enables the interrupt if 'handler'
> is non-
>   *   NULL.  If handler is NULL, then the interrupt is detached and
> disabled
>   *   instead.
>   *
>   *   The PHY interrupt is always disabled upon return.  The caller
> must
>   *   call back through the enable function point to control the
> state of
>   *   the interrupt.
>   *
>   *   This interrupt may or may not be available on a given platform
> depending
>   *   on how the network hardware architecture is implemented. In a
> typical
>   *   case, the PHY interrupt is provided to board-level logic as a
> GPIO
>   *   interrupt (in which case this is a board-specific interface
> and really
>   *   should be called board_phy_irq()); In other cases, the PHY
> interrupt
>   *   may be cause by the chip's MAC logic (in which case
> arch_phy_irq()) is
>   *   an appropriate name.  Other other boards, there may be no PHY
> interrupts
>   *   available at all.  If client attachable PHY interrupts are
> available
>   *   from the board or from the chip, then
> CONFIG_ARCH_PHY_INTERRUPT should
>   *   be defined to indicate that fact.
>   *
>   *   Typical usage:
>   *   a. OS service logic (not application logic*) attaches to the PHY
>   *  PHY interrupt and enables the PHY interrupt.
>   *   b. When the PHY interrupt occurs:  (1) the interrupt should be
>   *  disabled and () work should be scheduled on the worker
> thread (or
>   *  perhaps a dedicated application thread).
>   *   c. That worker thread should use the SIOCGMIIPHY, SIOCGMIIREG,
>   *  and SIOCSMIIREG ioctl calls** to communicate with the PHY,
>   *  determine what network event took place (Link Up/Down?), and
>   *  take the appropriate actions.
>   *   d. It should then interact the PHY to clear any pending
>   *  interrupts, then re-enable the PHY interrupt.
>   *
>   ** This is an OS internal interface and should not be used from
>   *  application space.  Rather applications should use the
> SIOCMIISIG
>   *  ioctl to receive a signal when a PHY event occurs.
>   *   ** This interrupt is really of no use if the Ethernet MAC driver
>   *  does not support these ioctl calls.
>   *
>   * Input Parameters:
>   *   intf- Identifies the network interface.  For example
> "eth0".  Only
>   * useful on platforms that support multiple Ethernet
> interfaces
>   * and, hence, multiple PHYs and PHY interrupts.
>   *   handler - The client interrupt handler to be invoked when the PHY
>   * asserts an interrupt.  Must reside in OS space, but can
>   * signal tasks in user space.  A value of NULL can be
> passed
>   * in order to detach and disable the PHY interrupt.
>   *   arg - The argument that will accompany the interrupt
>   *   enable  - A function pointer that be unused to enable or
> disable the
>   * PHY interrupt.
>   *
>   * Returned Value:
>   *   Zero (OK) returned on success; a negated errno value is
> returned on
>   *   failure.
>   *
>
>   
> /
>
> #ifdef CONFIG_ARCH_PHY_INTERRUPT
> int arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg,
>   phy_enable_t *enable);
> #endif
>
>
> Lots of examples.  Note that it already exists for STM32F4 Discovery:
>
> $ find boards/ -name "*.c" | xargs grep arch_phy_irq
> boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c: * Name:
> arch_phy_irq
> boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c: *   may be
> cause by 

RE: CAN on STM32H7 platforms under NuttX

[David Sidrane]

Roberto

There is a DRAFT PR https://github.com/apache/incubator-nuttx/pull/2987

David
-Original Message-
From: Roberto Bucher [mailto:roberto.buc...@supsi.ch]
Sent: Wednesday, April 14, 2021 6:18 AM
To: dev@nuttx.apache.org
Subject: CAN on STM32H7 platforms under NuttX

Hi

For a bachelor project with a student, which will start on may 2021, I
have to implement a CAN communication between a STM32H743ZI2 board and 2
STM32F446 boards. I'd like to propose to my student to work with
micro-ROS and NuttX on both platforms.

Basically it seems that the CAN bus files are not yet implemented in the
NuttX tree for the STM32H7 board. Did somebody work on implementation of
CAN bus for the STM32H7 architecture?

Thanks in advance

Roberto

Re: DALI Interface Proposal

[Alan Carvalho de Assis]

Hi Murat,

I think DALI support should be a nice feature to have!

Well, I already search for this protocol some time ago, but I don't
know much about it yet.

The protocol uses Manchester encoding, maybe driver interface should
be implemented using GPIO and freerunning timer. Suggestions are
welcome!

For HW I think we have two options: ST STEVAL-ILM001V1 and Mikroe DALI 2 Click.

It seams there are two protocol version: DALI and DALI 2. Probably
those DALI dimmers on Aliexpress are pretty old DALI protocol.

BR,

Alan

On 4/14/21, murat toloğlu  wrote:
> I would very much like the DALI interface to be in Nuttx and I would like to
> learn your opinions on this issue. My knowledge and experience in Nuttx is
> not enough to do this work alone, but if we get a few people together, I can
> participate in the development work.
>

Re: Ethernet cable (network interface availability) detection

[Gregory Nutt]

You board must provide CONFIG_ARCH_PHY_INTERRUPT:

   $ find boards/ -name Kconfig | xargs grep ARCH_PHY_INTERRUPT
   boards/Kconfig: select ARCH_PHY_INTERRUPT
   boards/Kconfig: select ARCH_PHY_INTERRUPT if SAMA5_EMACA ||
   SAMA5_EMAC0 || SAMA5_EMAC1 || SAMA5_GMAC
   boards/Kconfig: select ARCH_PHY_INTERRUPT
   boards/Kconfig: select ARCH_PHY_INTERRUPT
   boards/Kconfig: select ARCH_PHY_INTERRUPT
   boards/Kconfig: select ARCH_PHY_INTERRUPT
   boards/Kconfig: select ARCH_PHY_INTERRUPT

and you must implement PHY interrupt handling as documented in 
include/nuttx/arch.h:


   /
 * Name: arch_phy_irq
 *
 * Description:
 *   This function may be called to register an interrupt handler
   that will
 *   be called when a PHY interrupt occurs.  This function both
   attaches
 *   the interrupt handler and enables the interrupt if 'handler'
   is non-
 *   NULL.  If handler is NULL, then the interrupt is detached and
   disabled
 *   instead.
 *
 *   The PHY interrupt is always disabled upon return.  The caller must
 *   call back through the enable function point to control the
   state of
 *   the interrupt.
 *
 *   This interrupt may or may not be available on a given platform
   depending
 *   on how the network hardware architecture is implemented. In a
   typical
 *   case, the PHY interrupt is provided to board-level logic as a GPIO
 *   interrupt (in which case this is a board-specific interface
   and really
 *   should be called board_phy_irq()); In other cases, the PHY
   interrupt
 *   may be cause by the chip's MAC logic (in which case
   arch_phy_irq()) is
 *   an appropriate name.  Other other boards, there may be no PHY
   interrupts
 *   available at all.  If client attachable PHY interrupts are
   available
 *   from the board or from the chip, then
   CONFIG_ARCH_PHY_INTERRUPT should
 *   be defined to indicate that fact.
 *
 *   Typical usage:
 *   a. OS service logic (not application logic*) attaches to the PHY
 *  PHY interrupt and enables the PHY interrupt.
 *   b. When the PHY interrupt occurs:  (1) the interrupt should be
 *  disabled and () work should be scheduled on the worker
   thread (or
 *  perhaps a dedicated application thread).
 *   c. That worker thread should use the SIOCGMIIPHY, SIOCGMIIREG,
 *  and SIOCSMIIREG ioctl calls** to communicate with the PHY,
 *  determine what network event took place (Link Up/Down?), and
 *  take the appropriate actions.
 *   d. It should then interact the PHY to clear any pending
 *  interrupts, then re-enable the PHY interrupt.
 *
 *    * This is an OS internal interface and should not be used from
 *  application space.  Rather applications should use the
   SIOCMIISIG
 *  ioctl to receive a signal when a PHY event occurs.
 *   ** This interrupt is really of no use if the Ethernet MAC driver
 *  does not support these ioctl calls.
 *
 * Input Parameters:
 *   intf    - Identifies the network interface.  For example
   "eth0".  Only
 * useful on platforms that support multiple Ethernet
   interfaces
 * and, hence, multiple PHYs and PHY interrupts.
 *   handler - The client interrupt handler to be invoked when the PHY
 * asserts an interrupt.  Must reside in OS space, but can
 * signal tasks in user space.  A value of NULL can be
   passed
 * in order to detach and disable the PHY interrupt.
 *   arg - The argument that will accompany the interrupt
 *   enable  - A function pointer that be unused to enable or
   disable the
 * PHY interrupt.
 *
 * Returned Value:
 *   Zero (OK) returned on success; a negated errno value is
   returned on
 *   failure.
 *
 
/

   #ifdef CONFIG_ARCH_PHY_INTERRUPT
   int arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg,
 phy_enable_t *enable);
   #endif


Lots of examples.  Note that it already exists for STM32F4 Discovery:

   $ find boards/ -name "*.c" | xargs grep arch_phy_irq
   boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c: * Name:
   arch_phy_irq
   boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c: *   may be
   cause by the chip's MAC logic (in which case arch_phy_irq()) is
   boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c:int
   arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg,
   boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c: * Name:
   arch_phy_irq
   boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c: *   may be
   cause by the chip's MAC logic (in which case arch_phy_irq()) is
   boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c:int
   

Re: Ethernet cable (network interface availability) detection

[Matias N.]

Contributing and Glossary should be left at the end. I would put it right 
before Guides.
Maybe one file with subsections is enough for now.

On Wed, Apr 14, 2021, at 11:03, Alan Carvalho de Assis wrote:
> Hi Matias,
> 
> I can submit a PR with it.
> 
> Where the FAQ should be added? Is it ok to be after Glossary?
> 
> BR,
> 
> Alan
> 
> On 4/14/21, Matias N. mailto:matias%40imap.cc>> wrote:
> > We do not yet have a "Networking" section under "OS Components" where a lot
> > of network related stuff should
> > be. However, I have thought about a FAQ section for having brief
> > question/answers where this kind of information can be (until a proper
> > section is added). If anyone wants to start this it would be welcome. It
> > should be categorized by topic.
> >
> > Best,
> > Matias
> >
> > On Wed, Apr 14, 2021, at 10:40, Alan Carvalho de Assis wrote:
> >> I think this is kind of question that should be in some FAQ or in our
> >> documentation, it is asked often...
> >>
> >> Is there some only place in our Documentation where we could include it?
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 4/14/21, Gregory Nutt  >> 
> >> > wrote:
> >> > Normally this is done using the PHY driver at
> >> > nuttx/drivers/net/phy_notify.c that provides PHY-related events to
> >> > applications via signals.  It requires board-level support to handle
> >> > PHY
> >> > interrupts.
> >> >
> >> > The network monitor thread at apps/netutils/netinit (see
> >> > CONFIG_NETINIT_MONITOR) will handle taking the network down if the
> >> > cable
> >> > is unplugged and bringing it back up when the cable is restored.
> >> >
> >> > On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:
> >> >> Hello,
> >> >>
> >> >> I am implementing an application using NuttX where I need to detect if
> >> >> the network cable is plugged or not in my board.
> >> >>
> >> >> Today I implemented the function netlib_getifstatus(), which automates
> >> >> the read of SIOCGIFFLAGS, similar to what we have in Linux.
> >> >>
> >> >> But, in my tests, it seems that it is not working correctly.
> >> >>
> >> >> What is the recommended approach to have this feature implemented?
> >> >>
> >> >> Best regards,
> >> >>
> >> >> Flavio
> >> >>
> >> >
> >> >
> >>
> >
> 

Re: Ethernet cable (network interface availability) detection

[Alan Carvalho de Assis]

Hi Matias,

I can submit a PR with it.

Where the FAQ should be added? Is it ok to be after Glossary?

BR,

Alan

On 4/14/21, Matias N.  wrote:
> We do not yet have a "Networking" section under "OS Components" where a lot
> of network related stuff should
> be. However, I have thought about a FAQ section for having brief
> question/answers where this kind of information can be (until a proper
> section is added). If anyone wants to start this it would be welcome. It
> should be categorized by topic.
>
> Best,
> Matias
>
> On Wed, Apr 14, 2021, at 10:40, Alan Carvalho de Assis wrote:
>> I think this is kind of question that should be in some FAQ or in our
>> documentation, it is asked often...
>>
>> Is there some only place in our Documentation where we could include it?
>>
>> BR,
>>
>> Alan
>>
>> On 4/14/21, Gregory Nutt > > wrote:
>> > Normally this is done using the PHY driver at
>> > nuttx/drivers/net/phy_notify.c that provides PHY-related events to
>> > applications via signals.  It requires board-level support to handle
>> > PHY
>> > interrupts.
>> >
>> > The network monitor thread at apps/netutils/netinit (see
>> > CONFIG_NETINIT_MONITOR) will handle taking the network down if the
>> > cable
>> > is unplugged and bringing it back up when the cable is restored.
>> >
>> > On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:
>> >> Hello,
>> >>
>> >> I am implementing an application using NuttX where I need to detect if
>> >> the network cable is plugged or not in my board.
>> >>
>> >> Today I implemented the function netlib_getifstatus(), which automates
>> >> the read of SIOCGIFFLAGS, similar to what we have in Linux.
>> >>
>> >> But, in my tests, it seems that it is not working correctly.
>> >>
>> >> What is the recommended approach to have this feature implemented?
>> >>
>> >> Best regards,
>> >>
>> >> Flavio
>> >>
>> >
>> >
>>
>

Re: Ethernet cable (network interface availability) detection

[Flavio Castro Alves Filho]

The netinit_monitor code is self-explanatory :-/

I could understand what must be done ... and, naturally, it is in
accord with the documents.

In my case, I cannot easily enable it from menuconfig ... as far as I
understood.

Em qua., 14 de abr. de 2021 às 10:49, Gregory Nutt
 escreveu:
>
> This is very out of date, but 90% accurate:
>
> https://cwiki.apache.org/confluence/display/NUTTX/Network+Link+Management
> https://cwiki.apache.org/confluence/display/NUTTX/NSH+Network+Link+Management
>
> This was not updated after the network initialization and network
> monitor were removed from NSH and made a separate feature.  It needs so
> clean-up.
>
> On 4/14/2021 7:40 AM, Alan Carvalho de Assis wrote:
> > I think this is kind of question that should be in some FAQ or in our
> > documentation, it is asked often...
> >
> > Is there some only place in our Documentation where we could include it?
> >
> > BR,
> >
> > Alan
> >
> > On 4/14/21, Gregory Nutt  wrote:
> >> Normally this is done using the PHY driver at
> >> nuttx/drivers/net/phy_notify.c that provides PHY-related events to
> >> applications via signals.  It requires board-level support to handle PHY
> >> interrupts.
> >>
> >> The network monitor thread at apps/netutils/netinit (see
> >> CONFIG_NETINIT_MONITOR) will handle taking the network down if the cable
> >> is unplugged and bringing it back up when the cable is restored.
> >>
> >> On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:
> >>> Hello,
> >>>
> >>> I am implementing an application using NuttX where I need to detect if
> >>> the network cable is plugged or not in my board.
> >>>
> >>> Today I implemented the function netlib_getifstatus(), which automates
> >>> the read of SIOCGIFFLAGS, similar to what we have in Linux.
> >>>
> >>> But, in my tests, it seems that it is not working correctly.
> >>>
> >>> What is the recommended approach to have this feature implemented?
> >>>
> >>> Best regards,
> >>>
> >>> Flavio
> >>>
> >>
>


-- 
Flavio de Castro Alves Filho

flavio.al...@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: Ethernet cable (network interface availability) detection

[Matias N.]

We do not yet have a "Networking" section under "OS Components" where a lot of 
network related stuff should
be. However, I have thought about a FAQ section for having brief 
question/answers where this kind of information can be (until a proper section 
is added). If anyone wants to start this it would be welcome. It should be 
categorized by topic.

Best,
Matias

On Wed, Apr 14, 2021, at 10:40, Alan Carvalho de Assis wrote:
> I think this is kind of question that should be in some FAQ or in our
> documentation, it is asked often...
> 
> Is there some only place in our Documentation where we could include it?
> 
> BR,
> 
> Alan
> 
> On 4/14/21, Gregory Nutt mailto:spudaneco%40gmail.com>> 
> wrote:
> > Normally this is done using the PHY driver at
> > nuttx/drivers/net/phy_notify.c that provides PHY-related events to
> > applications via signals.  It requires board-level support to handle PHY
> > interrupts.
> >
> > The network monitor thread at apps/netutils/netinit (see
> > CONFIG_NETINIT_MONITOR) will handle taking the network down if the cable
> > is unplugged and bringing it back up when the cable is restored.
> >
> > On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:
> >> Hello,
> >>
> >> I am implementing an application using NuttX where I need to detect if
> >> the network cable is plugged or not in my board.
> >>
> >> Today I implemented the function netlib_getifstatus(), which automates
> >> the read of SIOCGIFFLAGS, similar to what we have in Linux.
> >>
> >> But, in my tests, it seems that it is not working correctly.
> >>
> >> What is the recommended approach to have this feature implemented?
> >>
> >> Best regards,
> >>
> >> Flavio
> >>
> >
> >
> 

Re: Ethernet cable (network interface availability) detection

[Gregory Nutt]

This is very out of date, but 90% accurate:

https://cwiki.apache.org/confluence/display/NUTTX/Network+Link+Management
https://cwiki.apache.org/confluence/display/NUTTX/NSH+Network+Link+Management

This was not updated after the network initialization and network 
monitor were removed from NSH and made a separate feature.  It needs so 
clean-up.


On 4/14/2021 7:40 AM, Alan Carvalho de Assis wrote:

I think this is kind of question that should be in some FAQ or in our
documentation, it is asked often...

Is there some only place in our Documentation where we could include it?

BR,

Alan

On 4/14/21, Gregory Nutt  wrote:

Normally this is done using the PHY driver at
nuttx/drivers/net/phy_notify.c that provides PHY-related events to
applications via signals.  It requires board-level support to handle PHY
interrupts.

The network monitor thread at apps/netutils/netinit (see
CONFIG_NETINIT_MONITOR) will handle taking the network down if the cable
is unplugged and bringing it back up when the cable is restored.

On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:

Hello,

I am implementing an application using NuttX where I need to detect if
the network cable is plugged or not in my board.

Today I implemented the function netlib_getifstatus(), which automates
the read of SIOCGIFFLAGS, similar to what we have in Linux.

But, in my tests, it seems that it is not working correctly.

What is the recommended approach to have this feature implemented?

Best regards,

Flavio

Re: Ethernet cable (network interface availability) detection

[Flavio Castro Alves Filho]

Hello,

In my case, there is an additional challenge: the
CONFIG_NETINIT_MONITOR is not supported by STM32F4DISCOVERY.

What should I have to do to enable the feature for the board?

Best regards,

Flavio

Em qua., 14 de abr. de 2021 às 10:41, Alan Carvalho de Assis
 escreveu:
>
> I think this is kind of question that should be in some FAQ or in our
> documentation, it is asked often...
>
> Is there some only place in our Documentation where we could include it?
>
> BR,
>
> Alan
>
> On 4/14/21, Gregory Nutt  wrote:
> > Normally this is done using the PHY driver at
> > nuttx/drivers/net/phy_notify.c that provides PHY-related events to
> > applications via signals.  It requires board-level support to handle PHY
> > interrupts.
> >
> > The network monitor thread at apps/netutils/netinit (see
> > CONFIG_NETINIT_MONITOR) will handle taking the network down if the cable
> > is unplugged and bringing it back up when the cable is restored.
> >
> > On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:
> >> Hello,
> >>
> >> I am implementing an application using NuttX where I need to detect if
> >> the network cable is plugged or not in my board.
> >>
> >> Today I implemented the function netlib_getifstatus(), which automates
> >> the read of SIOCGIFFLAGS, similar to what we have in Linux.
> >>
> >> But, in my tests, it seems that it is not working correctly.
> >>
> >> What is the recommended approach to have this feature implemented?
> >>
> >> Best regards,
> >>
> >> Flavio
> >>
> >
> >



-- 
Flavio de Castro Alves Filho

flavio.al...@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: Ethernet cable (network interface availability) detection

[Alan Carvalho de Assis]

I think this is kind of question that should be in some FAQ or in our
documentation, it is asked often...

Is there some only place in our Documentation where we could include it?

BR,

Alan

On 4/14/21, Gregory Nutt  wrote:
> Normally this is done using the PHY driver at
> nuttx/drivers/net/phy_notify.c that provides PHY-related events to
> applications via signals.  It requires board-level support to handle PHY
> interrupts.
>
> The network monitor thread at apps/netutils/netinit (see
> CONFIG_NETINIT_MONITOR) will handle taking the network down if the cable
> is unplugged and bringing it back up when the cable is restored.
>
> On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:
>> Hello,
>>
>> I am implementing an application using NuttX where I need to detect if
>> the network cable is plugged or not in my board.
>>
>> Today I implemented the function netlib_getifstatus(), which automates
>> the read of SIOCGIFFLAGS, similar to what we have in Linux.
>>
>> But, in my tests, it seems that it is not working correctly.
>>
>> What is the recommended approach to have this feature implemented?
>>
>> Best regards,
>>
>> Flavio
>>
>
>

Re: Ethernet cable (network interface availability) detection

[Flavio Castro Alves Filho]

Hello Gregory,

Got it! The flags are populated by the monitor thread.

I will enable here in my setup, test and report here.

Thank you very much.

Best regards,

Flavio

Em qua., 14 de abr. de 2021 às 10:31, Gregory Nutt
 escreveu:
>
> Examples:
>
> $ find boards/ -name defconfig | xargs grep CONFIG_NETINIT_MONITOR
> 
> boards/arm/samv7/same70-xplained/configs/netnsh/defconfig:CONFIG_NETINIT_MONITOR=y
> 
> boards/arm/samv7/samv71-xult/configs/netnsh/defconfig:CONFIG_NETINIT_MONITOR=y
> 
> boards/arm/tiva/dk-tm4c129x/configs/ipv6/defconfig:CONFIG_NETINIT_MONITOR=y
> boards/arm/tiva/dk-tm4c129x/configs/nsh/defconfig:CONFIG_NETINIT_MONITOR=y
> 
> boards/arm/tiva/tm4c1294-launchpad/configs/ipv6/defconfig:CONFIG_NETINIT_MONITOR=y
> 
> boards/arm/tiva/tm4c1294-launchpad/configs/nsh/defconfig:CONFIG_NETINIT_MONITOR=y
>
> On 4/14/2021 7:29 AM, Gregory Nutt wrote:
> > Normally this is done using the PHY driver at
> > nuttx/drivers/net/phy_notify.c that provides PHY-related events to
> > applications via signals.  It requires board-level support to handle
> > PHY interrupts.
> >
> > The network monitor thread at apps/netutils/netinit (see
> > CONFIG_NETINIT_MONITOR) will handle taking the network down if the
> > cable is unplugged and bringing it back up when the cable is restored.
> >
> > On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:
> >> Hello,
> >>
> >> I am implementing an application using NuttX where I need to detect if
> >> the network cable is plugged or not in my board.
> >>
> >> Today I implemented the function netlib_getifstatus(), which automates
> >> the read of SIOCGIFFLAGS, similar to what we have in Linux.
> >>
> >> But, in my tests, it seems that it is not working correctly.
> >>
> >> What is the recommended approach to have this feature implemented?
> >>
> >> Best regards,
> >>
> >> Flavio
> >>
> >
>


-- 
Flavio de Castro Alves Filho

flavio.al...@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: Ethernet cable (network interface availability) detection

[Gregory Nutt]

Examples:

   $ find boards/ -name defconfig | xargs grep CONFIG_NETINIT_MONITOR
   
boards/arm/samv7/same70-xplained/configs/netnsh/defconfig:CONFIG_NETINIT_MONITOR=y
   
boards/arm/samv7/samv71-xult/configs/netnsh/defconfig:CONFIG_NETINIT_MONITOR=y
   boards/arm/tiva/dk-tm4c129x/configs/ipv6/defconfig:CONFIG_NETINIT_MONITOR=y
   boards/arm/tiva/dk-tm4c129x/configs/nsh/defconfig:CONFIG_NETINIT_MONITOR=y
   
boards/arm/tiva/tm4c1294-launchpad/configs/ipv6/defconfig:CONFIG_NETINIT_MONITOR=y
   
boards/arm/tiva/tm4c1294-launchpad/configs/nsh/defconfig:CONFIG_NETINIT_MONITOR=y

On 4/14/2021 7:29 AM, Gregory Nutt wrote:
Normally this is done using the PHY driver at 
nuttx/drivers/net/phy_notify.c that provides PHY-related events to 
applications via signals.  It requires board-level support to handle 
PHY interrupts.


The network monitor thread at apps/netutils/netinit (see 
CONFIG_NETINIT_MONITOR) will handle taking the network down if the 
cable is unplugged and bringing it back up when the cable is restored.


On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:

Hello,

I am implementing an application using NuttX where I need to detect if
the network cable is plugged or not in my board.

Today I implemented the function netlib_getifstatus(), which automates
the read of SIOCGIFFLAGS, similar to what we have in Linux.

But, in my tests, it seems that it is not working correctly.

What is the recommended approach to have this feature implemented?

Best regards,

Flavio

Re: Ethernet cable (network interface availability) detection

[Gregory Nutt]

Normally this is done using the PHY driver at 
nuttx/drivers/net/phy_notify.c that provides PHY-related events to 
applications via signals.  It requires board-level support to handle PHY 
interrupts.


The network monitor thread at apps/netutils/netinit (see 
CONFIG_NETINIT_MONITOR) will handle taking the network down if the cable 
is unplugged and bringing it back up when the cable is restored.


On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote:

Hello,

I am implementing an application using NuttX where I need to detect if
the network cable is plugged or not in my board.

Today I implemented the function netlib_getifstatus(), which automates
the read of SIOCGIFFLAGS, similar to what we have in Linux.

But, in my tests, it seems that it is not working correctly.

What is the recommended approach to have this feature implemented?

Best regards,

Flavio

Ethernet cable (network interface availability) detection

[Flavio Castro Alves Filho]

Hello,

I am implementing an application using NuttX where I need to detect if
the network cable is plugged or not in my board.

Today I implemented the function netlib_getifstatus(), which automates
the read of SIOCGIFFLAGS, similar to what we have in Linux.

But, in my tests, it seems that it is not working correctly.

What is the recommended approach to have this feature implemented?

Best regards,

Flavio

-- 
Flavio de Castro Alves Filho

flavio.al...@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

CAN on STM32H7 platforms under NuttX

[Roberto Bucher]

Hi

For a bachelor project with a student, which will start on may 2021, I 
have to implement a CAN communication between a STM32H743ZI2 board and 2 
STM32F446 boards. I'd like to propose to my student to work with 
micro-ROS and NuttX on both platforms.


Basically it seems that the CAN bus files are not yet implemented in the 
NuttX tree for the STM32H7 board. Did somebody work on implementation of 
CAN bus for the STM32H7 architecture?


Thanks in advance

Roberto

RE: NuttX-10.1

[Alin.Jerpelea]

Hi Nathan,

Today I managed to log in to confluence without issues and work on some release 
notes

Thanks 
Alin


-Original Message-
From: Nathan Hartman  
Sent: den 13 april 2021 21:34
To: dev@nuttx.apache.org
Subject: Re: NuttX-10.1

On Tue, Apr 13, 2021 at 1:43 PM Nathan Hartman  wrote:
>
> On Tue, Apr 13, 2021 at 11:12 AM  wrote:
>>
>> Hi Berenan,
>>
>> Since I did not manage to access confluence I finished sorting all 
>> PRs from the project board Please take a look and if possible 
>> transfer them to confluence
>>
>> Thanks
>> Alin
>
>
> Hi,
>
> I'm sorry to hear that. I don't know why the page won't load for you. Maybe 
> the URL in the email got messed up somehow? Could you try to access the NuttX 
> cwiki and navigate to the page using the navigation menu on the left? I think 
> release notes (current and older) are under Project Administration or one of 
> those subheadings toward the end.
>
> There shouldn't be any access restrictions on any of the cwiki pages.
>
> Unfortunately I am away from my machine today so I can't check what's going 
> on with the page. If all else fails, feel free to create a new page and later 
> I will manually merge the contents from the old one.

I looked into it, and AFAICT you should be able to navigate to the cwiki page 
by going to the top page and using the navigation tree sidebar to go to:

Project Administration -> Releases -> Release Notes -> NuttX 10.1

or access the page at this link, (assuming it doesn't get messed up going 
through email):

https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NUTTX/NuttX*10.1__;Kw!!JmoZiZGBv3RvKRSx!t1RTzXhLk5oX1B0dfJE2ChLvrVsVvsUCniHn8kGXYlkvHzvu8-xR3ruNq3-Eas0Mbw$
 

I have just accessed this page without logging in, as an unauthenticated user, 
and from a different web browser than I normally use, to ensure there isn't 
some restriction on it.

Please retry; if you have problems, check the URL (there is a '+'
(plus) sign there and also a '.' (period); maybe that's causing
problems?) and perhaps try clearing any stale browsing history... Let me know 
if the page is still inaccessible.

Thanks,
Nathan