Hi,
yes, I think the code duplication should not be that bad. Having separate drivers sam_spi.c for classic SPI, sam_qspi.c for QSPI in serial memory mode (current implementation) and sam_qspi_spi.c or something like that for SPI over QSPI would be an option then. Thanks. Best regards, Michal Lenc ---------- Původní e-mail ---------- Od: Gregory Nutt <spudan...@gmail.com> Komu: dev@nuttx.apache.org Datum: 15. 10. 2021 0:01:34 Předmět: Re: Implementing QSPI driver in SPI mode "> > The QSPI would need to support the SPI interface defined in struct spi_dev_s > in order to ensure compatibility with existing applications and drivers (LCD > displays for example) which use SPI. The option would be to add this > structure next to qspi_dev_s in arch specific drivers (in SAM case here > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam > _qspi.c#L159) and implements the specific SPI operations (send, exchange, > command/data etc.) in that file. The driver would then access either qspi_ > dev_s structure or spi_dev_s structure based on the configuration option for > the chip and would operate with that structure. Would this be a suitable > option or were there some other plans regarding implementing SPI functions > to QSPI? Thanks I would be inclined to implement this as a separate SPI driver rather that to try to make the QSPI driver to both roles. That would be cleaner and much less complex. I think that the amount of code duplication would not be very much since there is not a lot of overlap in data structures, interface functions, etc. INVIOLABLES.md: "Sometimes Code Duplication is OK" "
