> I don't know of any other way to do that other than with a dedicated > kernal thread and some timer. Wouldn't you have this same issue if you > were implementing this logic in application space? No real difference > other than the form of the APIs.
If this is handled in application, I would use an existing network-related thread, to not waste RAM in a new stack. But all this started as I wanted to add the board-specific logic to the board-specific code. I was hoping that this simple read/write operation to the MIIM would be possible to be done in board_timerhook, in a watchdog, or at least in a worker. It seems that there is no other way, than to move this back to application space. Στις Κυρ, 21 Φεβ 2021 στις 10:10 μ.μ., ο/η Grr <gebbe...@gmail.com> έγραψε: > psock_/file_ API is public API for kernel space component, not internal to > > socket/file subsystem. > > > > I was referring to what Gregory Nutt said, which was > > " It would be best to use the internal OS socket interfaces directly" > > > > SPI peripheral driver(e.g. sensor) should call SPI_SELECT to control the > > chip select, it's the responsibility of SPI bus > driver(spi_dev_s/spi_ops_s) > > to do the real action: > > 1.Control the SPI hardware register to change CS signal > > 2.Or control the GPIO hardware register > > > > The reference to SPI involves a number of implications from a previous > discussion about the SPI subsystem: > > 1-Several peripherals in a bus, which force to use GPIOs as CSs > 2-SPI bus drivers which work independent of peripheral drivers > 3-SPI peripheral drivers which are _not_ limited to one peripheral and > hardwired to one board > 4-In such situation, the need to have a better, more general control for > GPIOs than what ioexpander can offer without practically redoing it anyways > > That list pose a number of fundamental changes to several current systems, > which is what I'm referring to > > > > > > El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<spudan...@gmail.com>) > > > escribió: > > > > > > > > > > > > I suggested using file_open() and file_ioctl() in a previous email. > > > > > That is wrong. file_ioctl() cannot be used to access > > > > > socket_ioctls(). You would have to use psock_ioctl(). > > > > > > > > Because the socket interface goes though the network, there are some > > > > hand shakes and interlocks to prevent network activity while > accessing > > > > the PHY interface. I think using a custom interface would be > > > > problematic. It would be best to use the internal OS socket > > > > interfaces directly. They prototyped and described in > > include/nuttx/net/net.h. > > > > For example, instead of using socket() you would use psock_socket(), > > > > instead of using bind(), you would use psock_bind(), instead of using > > > > ioctl(), you would use psock_ioctl(). > > > > > > > > The APIs are the same as the user space APIs exception that: (1) the > > > > are prefaced with psock_ and (2) the do not use an int socket > > > > descriptor. Rather, they use a pointer to the internal socket > > > > structure struct socket * > > > > > > > > > > > > > > > > > > > > >
