Re: Addition of STM32H7 MCU's

[Robert Turner]

Nah not internal cache. The SRAM sizes for H723/5 are different from any of
those defined in arch/arm/include/stm32h7/chip.h
Suspect we need to get these correct as other files use these defs also,
such as stm32_allocateheap.c
Is Jorge's PR the one merged on Jul 12 (8ceff0d)?
Thanks,
Robert

On Thu, Jan 18, 2024 at 2:56 PM Alan C. Assis  wrote:

> Hi Robert,
> Thank you for the explanation! Is it about internal cache?
>
> Looking at
> https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html
> I can see that H723/5 shares mostly everything with H333/5.
> I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added
> support to this few weeks ago).
>
> Please take a look at Jorge's PRs, probably if you fix the memory in the
> linker script and the clock tree for your board NuttX will work fine on it.
>
> BR,
>
> Alan
>
> On Wed, Jan 17, 2024 at 10:25 PM Robert Turner  wrote:
>
> > Apologies, I should have been more specific, I was referring to parts in
> > the family which are not currently covered, such as the STM32H723xx which
> > we use. The RAM sizes definitions in chip.h for
> > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for
> > the  STM32H723xx and  STM32H725xx.
> > BR,
> > Robert
> >
> > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis  wrote:
> >
> > > Robert,
> > > STM32H7 family is already supported.
> > >
> > > Look at arch/arm/src/stm32h7 and equivalent at boards/
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Tuesday, January 16, 2024, Robert Turner  wrote:
> > >
> > > > Did anyone finish supporting the broader STM32H7xx family? If so, is
> it
> > > > close to being mergeable or sendable as a patch?
> > > >
> > > > Thanks,
> > > > Robert
> > > >
> > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl 
> > wrote:
> > > >
> > > > > > You're right, but not entirely) For example, chips of different
> > > > subseries
> > > > > have different interrupt vector tables. Those. The
> stm32h7x3xx_irq.h
> > > file
> > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > > > RM0468. Although
> > > > > some chips from all these series have 7x3 in the name.
> > > > >
> > > > > I think they are the same (not checked, intuition tells me so). But
> > > some
> > > > > peripherals are not available on some chips and then the
> > > > > corresponding interrupt line is marked RESERVED, or its the same
> > > > peripheral
> > > > > but with upgraded functionality (QSPI/OCTOSPI) or
> > > > > for some reason ST changed its name to confuse devs. There should
> be
> > no
> > > > > conflict between IRQ lines.
> > > > >
> > > > > > Even if it duplicates 90% of the file it is better than #ifdefing
> > the
> > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash!
> > > > >
> > > > > One file approach can be done with only one level of #ifdefs, one
> > level
> > > > of
> > > > > #ifdefs doesn't have a negative impact on code quality (but
> > > > > it's probably a matter of individual feelings).
> > > > > For IRQ and memory map (and probably DMAMUX), the approach with
> > > separate
> > > > > files may make sense but for peripheral definitions
> > > > > I don't see any benefit in duplicating files.
> > > > >
> > > > > pt., 8 wrz 2023 o 12:01 
> > > napisał(a):
> > > > >
> > > > > > You're right, but not entirely) For example, chips of different
> > > > subseries
> > > > > > have different interrupt vector tables. Those. The
> > stm32h7x3xx_irq.h
> > > > file
> > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > > > RM0468. Although
> > > > > > some chips from all these series have 7x3 in the name.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > *От:* "raiden00pl" 
> > > > > > *Кому:* "undefined" 
> > > > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52
> > > > > > *Тема:* Re: Addition of STM32H7 MCU's
> > > > > >
> > > > > > From what I'm familiar with STM32H7, all chips use the same
> > registers
> > > > and
> > > > > > bit definitions.
> > > > > > Therefore, keeping definitions for different chips in different
> > files
> > > > > > doesn't make sense in my opinion.
> > > > > > The only problem is that some chips support some peripherals
> while
> > > > others
> > > > > > do not. But this can be
> > > > > > solved using definitions from Kconfig, where we define the
> > supported
> > > > > > peripherals anyway, using
> > > > > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have
> only
> > > one
> > > > > > version of files with hardware
> > > > > > definitions (irq, peripherals) and guard the optional
> > functionalities
> > > > > with
> > > > > > `#ifdef CONFIG_STM32H7_HAVE_xxx`.
> > > > > > Moreover, I think this can be done for all stm32 families, but
> > it's a
> > > > lot
> > > > > > of work that no one has undertaken
> > > > > > so far (I tried, but failed ;) )
> > > > > >
> > > > > > I understand that code duplication is often not bad, but in the
> > case
> > > of
> > > 

Re: Addition of STM32H7 MCU's

[Alan C. Assis]

Hi Robert,
Thank you for the explanation! Is it about internal cache?

Looking at
https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html
I can see that H723/5 shares mostly everything with H333/5.
I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added
support to this few weeks ago).

Please take a look at Jorge's PRs, probably if you fix the memory in the
linker script and the clock tree for your board NuttX will work fine on it.

BR,

Alan

On Wed, Jan 17, 2024 at 10:25 PM Robert Turner  wrote:

> Apologies, I should have been more specific, I was referring to parts in
> the family which are not currently covered, such as the STM32H723xx which
> we use. The RAM sizes definitions in chip.h for
> CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for
> the  STM32H723xx and  STM32H725xx.
> BR,
> Robert
>
> On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis  wrote:
>
> > Robert,
> > STM32H7 family is already supported.
> >
> > Look at arch/arm/src/stm32h7 and equivalent at boards/
> >
> > BR,
> >
> > Alan
> >
> > On Tuesday, January 16, 2024, Robert Turner  wrote:
> >
> > > Did anyone finish supporting the broader STM32H7xx family? If so, is it
> > > close to being mergeable or sendable as a patch?
> > >
> > > Thanks,
> > > Robert
> > >
> > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl 
> wrote:
> > >
> > > > > You're right, but not entirely) For example, chips of different
> > > subseries
> > > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h
> > file
> > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > > RM0468. Although
> > > > some chips from all these series have 7x3 in the name.
> > > >
> > > > I think they are the same (not checked, intuition tells me so). But
> > some
> > > > peripherals are not available on some chips and then the
> > > > corresponding interrupt line is marked RESERVED, or its the same
> > > peripheral
> > > > but with upgraded functionality (QSPI/OCTOSPI) or
> > > > for some reason ST changed its name to confuse devs. There should be
> no
> > > > conflict between IRQ lines.
> > > >
> > > > > Even if it duplicates 90% of the file it is better than #ifdefing
> the
> > > > > stm32h7x3xx_irq.h file. AKA ifdef rash!
> > > >
> > > > One file approach can be done with only one level of #ifdefs, one
> level
> > > of
> > > > #ifdefs doesn't have a negative impact on code quality (but
> > > > it's probably a matter of individual feelings).
> > > > For IRQ and memory map (and probably DMAMUX), the approach with
> > separate
> > > > files may make sense but for peripheral definitions
> > > > I don't see any benefit in duplicating files.
> > > >
> > > > pt., 8 wrz 2023 o 12:01 
> > napisał(a):
> > > >
> > > > > You're right, but not entirely) For example, chips of different
> > > subseries
> > > > > have different interrupt vector tables. Those. The
> stm32h7x3xx_irq.h
> > > file
> > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > > RM0468. Although
> > > > > some chips from all these series have 7x3 in the name.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *От:* "raiden00pl" 
> > > > > *Кому:* "undefined" 
> > > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52
> > > > > *Тема:* Re: Addition of STM32H7 MCU's
> > > > >
> > > > > From what I'm familiar with STM32H7, all chips use the same
> registers
> > > and
> > > > > bit definitions.
> > > > > Therefore, keeping definitions for different chips in different
> files
> > > > > doesn't make sense in my opinion.
> > > > > The only problem is that some chips support some peripherals while
> > > others
> > > > > do not. But this can be
> > > > > solved using definitions from Kconfig, where we define the
> supported
> > > > > peripherals anyway, using
> > > > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only
> > one
> > > > > version of files with hardware
> > > > > definitions (irq, peripherals) and guard the optional
> functionalities
> > > > with
> > > > > `#ifdef CONFIG_STM32H7_HAVE_xxx`.
> > > > > Moreover, I think this can be done for all stm32 families, but
> it's a
> > > lot
> > > > > of work that no one has undertaken
> > > > > so far (I tried, but failed ;) )
> > > > >
> > > > > I understand that code duplication is often not bad, but in the
> case
> > of
> > > > > stm32 it is a bit too high. It's partly ST's fault
> > > > > because of how they release their manuals. The user must spend a
> lot
> > of
> > > > > time to come to the conclusion
> > > > > that the only thing that changes in the other version of the chip
> is
> > > the
> > > > > chip code number in the reference manual :)
> > > > >
> > > > >
> > > > > pt., 8 wrz 2023 o 11:11 napisał(a):
> > > > >
> > > > > > Hi, all
> > > > > >
> > > > > > I would like to start working on developing support for STM32H735
> > > > > > microcontrollers in NuttX OS, but I found some strange things in
> > the
> > > > > 

Re: Addition of STM32H7 MCU's

[Robert Turner]

Apologies, I should have been more specific, I was referring to parts in
the family which are not currently covered, such as the STM32H723xx which
we use. The RAM sizes definitions in chip.h for
CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for
the  STM32H723xx and  STM32H725xx.
BR,
Robert

On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis  wrote:

> Robert,
> STM32H7 family is already supported.
>
> Look at arch/arm/src/stm32h7 and equivalent at boards/
>
> BR,
>
> Alan
>
> On Tuesday, January 16, 2024, Robert Turner  wrote:
>
> > Did anyone finish supporting the broader STM32H7xx family? If so, is it
> > close to being mergeable or sendable as a patch?
> >
> > Thanks,
> > Robert
> >
> > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl  wrote:
> >
> > > > You're right, but not entirely) For example, chips of different
> > subseries
> > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h
> file
> > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > RM0468. Although
> > > some chips from all these series have 7x3 in the name.
> > >
> > > I think they are the same (not checked, intuition tells me so). But
> some
> > > peripherals are not available on some chips and then the
> > > corresponding interrupt line is marked RESERVED, or its the same
> > peripheral
> > > but with upgraded functionality (QSPI/OCTOSPI) or
> > > for some reason ST changed its name to confuse devs. There should be no
> > > conflict between IRQ lines.
> > >
> > > > Even if it duplicates 90% of the file it is better than #ifdefing the
> > > > stm32h7x3xx_irq.h file. AKA ifdef rash!
> > >
> > > One file approach can be done with only one level of #ifdefs, one level
> > of
> > > #ifdefs doesn't have a negative impact on code quality (but
> > > it's probably a matter of individual feelings).
> > > For IRQ and memory map (and probably DMAMUX), the approach with
> separate
> > > files may make sense but for peripheral definitions
> > > I don't see any benefit in duplicating files.
> > >
> > > pt., 8 wrz 2023 o 12:01 
> napisał(a):
> > >
> > > > You're right, but not entirely) For example, chips of different
> > subseries
> > > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h
> > file
> > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > RM0468. Although
> > > > some chips from all these series have 7x3 in the name.
> > > >
> > > >
> > > >
> > > > --
> > > > *От:* "raiden00pl" 
> > > > *Кому:* "undefined" 
> > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52
> > > > *Тема:* Re: Addition of STM32H7 MCU's
> > > >
> > > > From what I'm familiar with STM32H7, all chips use the same registers
> > and
> > > > bit definitions.
> > > > Therefore, keeping definitions for different chips in different files
> > > > doesn't make sense in my opinion.
> > > > The only problem is that some chips support some peripherals while
> > others
> > > > do not. But this can be
> > > > solved using definitions from Kconfig, where we define the supported
> > > > peripherals anyway, using
> > > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only
> one
> > > > version of files with hardware
> > > > definitions (irq, peripherals) and guard the optional functionalities
> > > with
> > > > `#ifdef CONFIG_STM32H7_HAVE_xxx`.
> > > > Moreover, I think this can be done for all stm32 families, but it's a
> > lot
> > > > of work that no one has undertaken
> > > > so far (I tried, but failed ;) )
> > > >
> > > > I understand that code duplication is often not bad, but in the case
> of
> > > > stm32 it is a bit too high. It's partly ST's fault
> > > > because of how they release their manuals. The user must spend a lot
> of
> > > > time to come to the conclusion
> > > > that the only thing that changes in the other version of the chip is
> > the
> > > > chip code number in the reference manual :)
> > > >
> > > >
> > > > pt., 8 wrz 2023 o 11:11 napisał(a):
> > > >
> > > > > Hi, all
> > > > >
> > > > > I would like to start working on developing support for STM32H735
> > > > > microcontrollers in NuttX OS, but I found some strange things in
> the
> > > > > principle of configuring this series of microcontrollers.
> > > > >
> > > > > Microcontrollers of the H7 series are divided into several
> subseries,
> > > > each
> > > > > united by one reference manual:
> > > > > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468)
> > > > > - STM32H745/755 and STM32H747/757 (RM0399)
> > > > > - STM32H742, STM32H743/753 and STM32H750 (RM0433)
> > > > > - STM32H7A3/7B3 and STM32H7B0 (RM0455)
> > > > >
> > > > > But some header files in arch/arm/include/stm32h7 are designated as
> > > > > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for
> > the
> > > > H743
> > > > > or H745 series respectively, not for H723 or H735. And such a
> > > > discrepancy
> > > > > is also present in other source code files that belong to the H7
> > > 

Re: Addition of STM32H7 MCU's

[Alan C. Assis]

Robert,
STM32H7 family is already supported.

Look at arch/arm/src/stm32h7 and equivalent at boards/

BR,

Alan

On Tuesday, January 16, 2024, Robert Turner  wrote:

> Did anyone finish supporting the broader STM32H7xx family? If so, is it
> close to being mergeable or sendable as a patch?
>
> Thanks,
> Robert
>
> On Fri, Sep 8, 2023 at 10:33 PM raiden00pl  wrote:
>
> > > You're right, but not entirely) For example, chips of different
> subseries
> > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file
> > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > RM0468. Although
> > some chips from all these series have 7x3 in the name.
> >
> > I think they are the same (not checked, intuition tells me so). But some
> > peripherals are not available on some chips and then the
> > corresponding interrupt line is marked RESERVED, or its the same
> peripheral
> > but with upgraded functionality (QSPI/OCTOSPI) or
> > for some reason ST changed its name to confuse devs. There should be no
> > conflict between IRQ lines.
> >
> > > Even if it duplicates 90% of the file it is better than #ifdefing the
> > > stm32h7x3xx_irq.h file. AKA ifdef rash!
> >
> > One file approach can be done with only one level of #ifdefs, one level
> of
> > #ifdefs doesn't have a negative impact on code quality (but
> > it's probably a matter of individual feelings).
> > For IRQ and memory map (and probably DMAMUX), the approach with separate
> > files may make sense but for peripheral definitions
> > I don't see any benefit in duplicating files.
> >
> > pt., 8 wrz 2023 o 12:01  napisał(a):
> >
> > > You're right, but not entirely) For example, chips of different
> subseries
> > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h
> file
> > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > RM0468. Although
> > > some chips from all these series have 7x3 in the name.
> > >
> > >
> > >
> > > --
> > > *От:* "raiden00pl" 
> > > *Кому:* "undefined" 
> > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52
> > > *Тема:* Re: Addition of STM32H7 MCU's
> > >
> > > From what I'm familiar with STM32H7, all chips use the same registers
> and
> > > bit definitions.
> > > Therefore, keeping definitions for different chips in different files
> > > doesn't make sense in my opinion.
> > > The only problem is that some chips support some peripherals while
> others
> > > do not. But this can be
> > > solved using definitions from Kconfig, where we define the supported
> > > peripherals anyway, using
> > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only one
> > > version of files with hardware
> > > definitions (irq, peripherals) and guard the optional functionalities
> > with
> > > `#ifdef CONFIG_STM32H7_HAVE_xxx`.
> > > Moreover, I think this can be done for all stm32 families, but it's a
> lot
> > > of work that no one has undertaken
> > > so far (I tried, but failed ;) )
> > >
> > > I understand that code duplication is often not bad, but in the case of
> > > stm32 it is a bit too high. It's partly ST's fault
> > > because of how they release their manuals. The user must spend a lot of
> > > time to come to the conclusion
> > > that the only thing that changes in the other version of the chip is
> the
> > > chip code number in the reference manual :)
> > >
> > >
> > > pt., 8 wrz 2023 o 11:11 napisał(a):
> > >
> > > > Hi, all
> > > >
> > > > I would like to start working on developing support for STM32H735
> > > > microcontrollers in NuttX OS, but I found some strange things in the
> > > > principle of configuring this series of microcontrollers.
> > > >
> > > > Microcontrollers of the H7 series are divided into several subseries,
> > > each
> > > > united by one reference manual:
> > > > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468)
> > > > - STM32H745/755 and STM32H747/757 (RM0399)
> > > > - STM32H742, STM32H743/753 and STM32H750 (RM0433)
> > > > - STM32H7A3/7B3 and STM32H7B0 (RM0455)
> > > >
> > > > But some header files in arch/arm/include/stm32h7 are designated as
> > > > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for
> the
> > > H743
> > > > or H745 series respectively, not for H723 or H735. And such a
> > > discrepancy
> > > > is also present in other source code files that belong to the H7
> > series.
> > > >
> > > > Maybe it's worth fixing this somehow? Will this break anything
> > > important?
> > > >
> > > >
> > > > Oleg Svezhinskiy
> > > >
> > >
> >
>

Re: GPIO drivers

[Lwazi Dube]

Hi Stewart,

Take this with a grain of salt. I have never used the ioexpander ... took a
quick look after seeing your email.
You need to populate ioexpander_ops_s within your board specific files.
IOEXP_WRITEPIN is the "virtual function" that calls your board specific
write_pin function (which calls stm32l4_gpiowrite?). Take a look at
ioexpander.h and one of the following files to see how ioexpander_ops_s is
initialized. Your board calls relay_gpio_register passing a pointer to the
initialized ioexpander_dev_s.

(ioexpander_ops_s is part of ioexpander_dev_s)

/drivers/analog/lmp92001.c
./drivers/ioexpander/skeleton.c
./drivers/ioexpander/mcp23x17.c
./drivers/ioexpander/ioe_rpmsg.c
./drivers/ioexpander/pcf8575.c
./drivers/ioexpander/pca9555.c
./drivers/ioexpander/iso1h812g.c
./drivers/ioexpander/pca9538.c
./drivers/ioexpander/sx1509.c
./drivers/ioexpander/iso1i813t.c
./drivers/ioexpander/pcf8574.c
./drivers/ioexpander/tca64xx.c
./drivers/ioexpander/ioe_dummy.c
./drivers/ioexpander/mcp23x08.c

On Wed, 17 Jan 2024 at 07:50, Stewart Charnell 
wrote:

> Hello Bowen,
>
> Thank you for you help. I am not sure if this question is for you or is
> more architecture specific?
>
> I am looking at implementing the the relay ops (set()/get()) functions
> within the drivers/power/relay/relay.c file. I can see how to implement
> this based on the drivers/power/relay/relay_gpio.c file. However I think
> that for control of a processor GPIO (rather than a GPIO controlled by
> an IO expander) I will need to use the gpiowrite & gpioread functions
> (rather than the IOEXP_WRITEPIN & IOEXP_READPIN functions used by the
> relay_gpio.c file). Do you think this is correct, or am I missing
> something?
>
> If the relay.c file is modified to implement the relay ops (set()/get())
> functions and uses the gpiowrite & gpioread functions then it becomes
> board/processor specific (e.g. will need the stm32l4_gpiowrite &
> stm32l4_gpioread functions for the nucleo-l432kc board I am working
> with). For my relay driver that doesn't matter (if I don't export it
> back to github as a patch), but to make the relay driver more generic
> does this mean the relay.c file should be within the
> arch/arm/src/ directory?
>
> Kind regards
>
> Stewart
>
>

Re: GPIO drivers

[Stewart Charnell]

Hello Bowen,

Thank you for you help. I am not sure if this question is for you or is 
more architecture specific?


I am looking at implementing the the relay ops (set()/get()) functions 
within the drivers/power/relay/relay.c file. I can see how to implement 
this based on the drivers/power/relay/relay_gpio.c file. However I think 
that for control of a processor GPIO (rather than a GPIO controlled by 
an IO expander) I will need to use the gpiowrite & gpioread functions 
(rather than the IOEXP_WRITEPIN & IOEXP_READPIN functions used by the 
relay_gpio.c file). Do you think this is correct, or am I missing something?


If the relay.c file is modified to implement the relay ops (set()/get()) 
functions and uses the gpiowrite & gpioread functions then it becomes 
board/processor specific (e.g. will need the stm32l4_gpiowrite & 
stm32l4_gpioread functions for the nucleo-l432kc board I am working 
with). For my relay driver that doesn't matter (if I don't export it 
back to github as a patch), but to make the relay driver more generic 
does this mean the relay.c file should be within the 
arch/arm/src/ directory?


Kind regards

Stewart

On 17/01/2024 06:49, Stewart Charnell wrote:

Hello Bowen,

Thank you for responding to my question. Yes I think the relay 
framework will do what I want, I will try it out.


Kind regards

Stewart Charnell

On 17/01/2024 03:23, 汪博文 wrote:

Hello,

I'm Bowen Wang and nice to answer your question. Please correct me If 
I understand wrong.


I think you want to use the relay framework 
in nuttx/drivers/power/relay/relay.c and relay_gpio.c,
which are added by me in PR: power/relay: add relay driver framework 
for NuttX by CV-Bowen · Pull Request #7954 · apache/nuttx 
(github.com) .


The realy framework has two part:

1. The first part is relay.c, relay.c did a very simple thing: 
convert user ioctl(RELAYIOC_SET/GET) to the relay driver implemented 
dev->ops->set()/get(),

and you can follow the following steps to implement a relay driver:
a. implement the relay ops (set()/get());
b. call relay_register() to register your relay driver (just like 
relay_gpio.c does);


2. The second part is relay_gpio.c, relay_gpio.c base on the *alreay 
implemented* gpio driver (ioexpander) to resigter a relay driver, so 
if you has implemented
a ioexpander driver, you can enable config: CONFIG_RELAY_GPIO and 
then call relay_gpio_register() to register a driver, a simple 
example in sim is:


```c
diff --git a/boards/sim/sim/sim/src/sim_ioexpander.c 
b/boards/sim/sim/sim/src/sim_ioexpander.c

index 599ac68743..9397967a24 100644
--- a/boards/sim/sim/sim/src/sim_ioexpander.c
+++ b/boards/sim/sim/sim/src/sim_ioexpander.c
@@ -29,6 +29,7 @@
 #include 
 #include 
+#include 
 #include "sim.h"
@@ -76,6 +77,11 @@ int sim_gpio_initialize(void)
   IOEXP_SETOPTION(ioe, 1, IOEXPANDER_OPTION_INTCFG,
                   (void *)IOEXPANDER_VAL_DISABLE);
   gpio_lower_half(ioe, 1, GPIO_OUTPUT_PIN, 1);
+  int ret = relay_gpio_register(ioe, 1, false, "/dev/relay0");
+  if (ret < 0)
+    {
+      _err("relay register error\n");
+    }
   /* Pin 2: an non-inverted, edge interrupting pin */
```

And I'm sorry that I missed the docs and examples about the new added 
relay framework, I will add this later.


Kind regards
Bowen Wang



Bowen Wang, wangbow...@xiaomi.com

    *From:* Stewart Charnell 
    *Date:* 2024-01-17 04:33
    *To:* dev@nuttx.apache.org
    *Subject:* [External Mail][Quarantine]GPIO drivers

    Hello,
    I have a processor board with GPIO ports which I would like to 
use to

    control such things as relays and PSU enable pins.
    Do I need to write a GPIO driver? There is an I/O expander 
driver. Is

    the I/O expander driver specific to expanders or can it be used
    for GPIO
    control?
    Kind regards
    Stewart Charnell

#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 
This e-mail and its attachments contain confidential information from 
XIAOMI, which is intended only for the person or entity whose address 
is listed above. Any use of the information contained herein in any 
way (including, but not limited to, total or partial disclosure, 
reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, 
please notify the sender by phone or email immediately and delete 
it!**/# 

Re: TUN device (PPP) issue?

[Kian Karas (KK)]

Hi Zhe

I am working on tag nuttx-12.2.1.

Your referenced commit did indeed fix the issue.

My apologies for not trying on master. I mistakenly though the error was in the 
TUN device driver, which I noticed had not changed since nuttx-12.2.1.

Thanks a lot!
Kian

From: Zhe Weng 翁�� 
Sent: 17 January 2024 04:55
To: Kian Karas (KK) 
Cc: dev@nuttx.apache.org 
Subject: Re: TUN device (PPP) issue?


Hi Kian,


Which version of NuttX are you working on? It behaves like a problem I've met 
before. Do you have this commit in your code? If not, maybe you could have a 
try: 
https://github.com/apache/nuttx/commit/e2c9aa65883780747ca00625a1452dddc6f8a138


Best regards

Zhe



From: Kian Karas (KK) 
Sent: Tuesday, January 16, 2024 11:53:06 PM
To: dev@nuttx.apache.org
Subject: TUN device (PPP) issue?

Hi community

I am experiencing an issue with PPP/TUN and reception of packets. The network 
stack reports different decoding errors in the received packets e.g.:
[   24.56] [  WARN] ppp: ipv4_in: WARNING: IP packet shorter than length in 
IP header

I can reproduce the issue by sending a number of packets (from my PC over PPP 
to the TUN device in NuttX),  which are all larger than can fit into one IOB 
*and* which are ignored (e.g. unsupported protocol or IP destination) - i.e. 
*not* triggering a response / TX packet. I then send a correct ICMP echo 
request from my PC to NuttX, which causes the above error to be reported.

The following PC commands will trigger the error message. My PC has IP 
172.29.4.1 and the NuttX ppp interface has 172.29.4.2. Note the first command 
sends to the *wrong* IP address so that NuttX ignores the ICMP messages. The 
second commands uses the IP of NuttX and should result in a response. I run the 
test after a fresh boot and with no other network traffic to/from NuttX.

$ ping -I ppp0 -W 0.2 -i 0.2 -c 13 172.29.4.3 -s 156
$ ping -I ppp0 -W 0.2 -c 1 172.29.4.2 -s 0

If I skip the first command, ping works fine.

I think the issue is caused by the IOB management in the TUN device driver 
(drivers/net/tun.c). I am new to NuttX, so I don't quite understand the correct 
use of IOB, so I am just guessing here. I think that when a packet is received 
by tun_write() and too large to fit into a single IOB *and* the packet is 
ignored, the IOB chain "lingers" and is not freed. Subsequent packets received 
by tun_write() does not end up in the beginning of the first IOB and the 
IP/TCP/UDP header may then be split across IOB boundary. The network stack 
assumes the protocol headers are not split across IOB boundaries, so the 
network stack ends up reading outside the IOB io_data[] array boundaries 
resulting in undefined behavior.

With CONFIG_IOB_DEBUG enabled, notice how the "avail" value decrease for each 
ignored packet until the final/correct ICMP request (at time 24.54) is 
copied to the second IOB in the chain.

[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 
len=184 next=0
[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 182 
bytes new len=182
[   10.07] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 added to the 
chain
[   10.07] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=0 len=2 
next=0
[   10.08] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 2 bytes 
new len=2
[   10.08] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.08] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   10.26] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.26] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=168 
len=184 next=0x24002a50
[   10.27] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 168 
bytes new len=168
[   10.27] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=2 
len=16 next=0
[   10.28] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 16 bytes 
new len=16
[   10.28] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.28] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   10.46] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.47] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=154 
len=184 next=0x24002a50
[   10.47] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 154 
bytes new len=154
[   10.48] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=16 
len=30 next=0
[   10.48] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 30 bytes 
new len=30
[   10.48] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.49] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
...
[   12.50] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   12.51] [