> 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 us
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
On 2/21/2021 1:34 PM, Fotis Panagiotopoulos wrote:
You would not want to use the high priority work queue; that would
interfere with real time behavior. Nor would you want to use the low
priority work queue because that is used by most network drivers and so
would probably result in deadlocks.
> -Original Message-
> From: Grr
> Sent: Sunday, February 21, 2021 3:07 AM
> To: dev@nuttx.apache.org
> Subject: Re: Board-level Ethernet PHY operations in STM32.
>
> When is using internal OS interfaces from another OS subsystem (or an app) OK
> and not mod
> You would not want to use the high priority work queue; that would
> interfere with real time behavior. Nor would you want to use the low
> priority work queue because that is used by most network drivers and so
> would probably result in deadlocks.
Oh, I wouldn't imagine that... That's bad.
>
You would not want to use the high priority work queue; that would
interfere with real time behavior. Nor would you want to use the low
priority work queue because that is used by most network drivers and so
would probably result in deadlocks.
Why no create your own dedicated kernel thread?
Thank you very much!
The interface psock_* seems good.
However, I need it to be called periodically. board_timerhook and watchdogs
cannot call this interface.
I guess, a work queue is my only option for this task?
Στις Σάβ, 20 Φεβ 2021 στις 9:07 μ.μ., ο/η Grr έγραψε:
> When is using internal O
When is using internal OS interfaces from another OS subsystem (or an app)
OK and not modularity rape?
For example (and following my development line), if a SPI peripheral driver
needs to access GPIO data structure in order to control chip select, is it
more problematic than an app talking directl
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
Board should export/expose resources in a general way so drivers can use
them in a common, transparent way. That's the point of a portable OS
If there's not a standard way in NuttX to export R/MII (I haven't looked at
it), maybe you need to create it
The PHY R/MII interface is exported via a
You can call the PHY Ethernet ioctl() commands directly from board
specific code. Many things you can implement application can also be
implemented inside the board-specific logic -- with the caveat that you
have to use some different interfaces.
The PHY driver ioctl commands are in include/n
El sáb, 20 feb 2021 a las 8:16, Fotis Panagiotopoulos ()
escribió:
> Low-level is close to the hardware. Think arch.
> High-level is away from the hardware. Think app.
> This is a standard industry convention, and it is followed in NuttX too.
>
Then we were talking the same from the beginning. I
Low-level is close to the hardware. Think arch.
High-level is away from the hardware. Think app.
This is a standard industry convention, and it is followed in NuttX too.
> I have some old LAN8187 (hopefully I could manage to solder them to an
> adapter) and I could do some testing of your work if
El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos ()
escribió:
> The highest level (and maybe the only available), is the application
> itself.
>
> This is what I want to avoid.
> I don't want the application to mess with the specific peculiarities of
> this hardware.
> It harms the overall ar
The highest level (and maybe the only available), is the application itself.
This is what I want to avoid.
I don't want the application to mess with the specific peculiarities of
this hardware.
It harms the overall architecture I think, makes porting more difficult.
Following this procedure, I wou
I cannot offer you help on the main topic but I'd like to offer an opinion
on the level thing:
The higher the level, the better. If possible, do it at the general level
Why? Because that way, your work is useful to most people and you avoid
increasing NuttX fragmentation. Many drivers are created
Anyone on this?
I am using the LAN8720A Ethernet PHY.
I realized that this IC in some rare cases may get stuck. The Ethernet LEDs
blink erratically, and no Ethernet communication is possible.
The only way to recover from this state is to reset the PHY. (MIIM works in
this case)
To diagnose the is
Hi everybody,
I am trying to perform some reads/writes to my Ethernet PHY (LAN8720A) in
board-level.
I am pretty confused on what is the correct interface to use for this
purpose.
As far as I can tell, it is only possible to perform MII read/writes
through ioctl's in application code.
How can the
18 matches
Mail list logo
