You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Tim Hardisty <ti...@hardisty.co.uk> on 2023/01/27 18:00:11 UTC
Pass interrupt status to handler
Think this is an easy one but it's stumped me so far...
I am setting up the USB Overcurrent interrupt and can't find any fully implemented examples.
The interrupt is set to both edges as I want to know when the over current state is first set and later hopefully cleared.
I can obviously read the state of the input pin, but I sort of feel I should be able to pass the state as an arg to the handler (via xcpt_t handler).
Is that possible and, if so, how?
RE: Pass interrupt status to handler
Posted by TimH <ti...@jti.uk.com.INVALID>.
In this case, it's not the low level interrupt handler. It's essentially the "callback" routine that's registered to the generic PIO irq handler. I think!
I had hoped that the actually irq state (edge/level/whatever) existed in a struct/argument/whatever and I just hadn't spotted it.
I should be able to use the usual poll_waiter stuff if I want to let users know via the UI - but the important thing, realistically, is to shut down USB Host power quickly!
>-----Original Message-----
>From: Gregory Nutt <sp...@gmail.com>
>Sent: 27 January 2023 18:47
>To: dev@nuttx.apache.org
>Subject: Re: Pass interrupt status to handler
>
>Typically, if you want to pass a small amount of information from an
>interrupt handler to a task, you would use a normal IPC like sigqueue()
>(https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigqueue.html) which
>allows to send a type union sigval to the task.
>
>The task would have to catch the signal with something like
>sigwaitinfo()
>(https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigwaitinfo.html).
>
>Originally, you could use mq_send() from interrupt handlers to send
>interrupt status to tasks, but unfortunately that feature was lost with
>some recent commits that redesigned the message handler that were
>apparently done without knowledge of that requirement. NOTE that the
>documentation is now wrong, it says that you can still messages from
>interrupt handlers. That is not true.
>
>On 1/27/2023 12:15 PM, Nathan Hartman wrote:
>> Is there a global structure where you retain state information where
>> it would be appropriate to save the most refent known state in a
>> volatile variable?
>>
>> On Fri, Jan 27, 2023 at 1:00 PM Tim Hardisty <ti...@hardisty.co.uk>
>wrote:
>>
>>> Think this is an easy one but it's stumped me so far...
>>>
>>> I am setting up the USB Overcurrent interrupt and can't find any
>>> fully implemented examples.
>>>
>>> The interrupt is set to both edges as I want to know when the over
>>> current state is first set and later hopefully cleared.
>>>
>>> I can obviously read the state of the input pin, but I sort of feel I
>>> should be able to pass the state as an arg to the handler (via xcpt_t
>>> handler).
>>>
>>> Is that possible and, if so, how?
>>>
Re: Pass interrupt status to handler
Posted by Xiang Xiao <xi...@gmail.com>.
On Sat, Jan 28, 2023 at 2:46 AM Gregory Nutt <sp...@gmail.com> wrote:
> Typically, if you want to pass a small amount of information from an
> interrupt handler to a task, you would use a normal IPC like sigqueue()
> (https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigqueue.html) which
> allows to send a type union sigval to the task.
>
> The task would have to catch the signal with something like
> sigwaitinfo()
> (https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigwaitinfo.html).
>
> Originally, you could use mq_send() from interrupt handlers to send
> interrupt status to tasks, but unfortunately that feature was lost with
> some recent commits that redesigned the message handler that were
> apparently done without knowledge of that requirement. NOTE that the
> documentation is now wrong, it says that you can still messages from
> interrupt handlers. That is not true.
>
Yes, with the new design mq_xxx can't be called from interrupt context
since mq is a normal file handle and then needs to hold file lock to do
fd->file conversion.
But, there are new API for kernel user which start with file_mq_xxx, this
set of API can still be called from the interrupt handler context.
>
> On 1/27/2023 12:15 PM, Nathan Hartman wrote:
> > Is there a global structure where you retain state information where it
> > would be appropriate to save the most refent known state in a volatile
> > variable?
> >
> > On Fri, Jan 27, 2023 at 1:00 PM Tim Hardisty <ti...@hardisty.co.uk> wrote:
> >
> >> Think this is an easy one but it's stumped me so far...
> >>
> >> I am setting up the USB Overcurrent interrupt and can't find any fully
> >> implemented examples.
> >>
> >> The interrupt is set to both edges as I want to know when the over
> current
> >> state is first set and later hopefully cleared.
> >>
> >> I can obviously read the state of the input pin, but I sort of feel I
> >> should be able to pass the state as an arg to the handler (via xcpt_t
> >> handler).
> >>
> >> Is that possible and, if so, how?
> >>
>
>
Re: Pass interrupt status to handler
Posted by Gregory Nutt <sp...@gmail.com>.
Typically, if you want to pass a small amount of information from an
interrupt handler to a task, you would use a normal IPC like sigqueue()
(https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigqueue.html) which
allows to send a type union sigval to the task.
The task would have to catch the signal with something like
sigwaitinfo()
(https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigwaitinfo.html).
Originally, you could use mq_send() from interrupt handlers to send
interrupt status to tasks, but unfortunately that feature was lost with
some recent commits that redesigned the message handler that were
apparently done without knowledge of that requirement. NOTE that the
documentation is now wrong, it says that you can still messages from
interrupt handlers. That is not true.
On 1/27/2023 12:15 PM, Nathan Hartman wrote:
> Is there a global structure where you retain state information where it
> would be appropriate to save the most refent known state in a volatile
> variable?
>
> On Fri, Jan 27, 2023 at 1:00 PM Tim Hardisty <ti...@hardisty.co.uk> wrote:
>
>> Think this is an easy one but it's stumped me so far...
>>
>> I am setting up the USB Overcurrent interrupt and can't find any fully
>> implemented examples.
>>
>> The interrupt is set to both edges as I want to know when the over current
>> state is first set and later hopefully cleared.
>>
>> I can obviously read the state of the input pin, but I sort of feel I
>> should be able to pass the state as an arg to the handler (via xcpt_t
>> handler).
>>
>> Is that possible and, if so, how?
>>
Re: Pass interrupt status to handler
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jan 27, 2023 at 1:57 PM Gregory Nutt <sp...@gmail.com> wrote:
> On 1/27/2023 12:15 PM, Nathan Hartman wrote:
> > Is there a global structure where you retain state information where it
> > would be appropriate to save the most refent known state in a volatile
> > variable?
> Good, modular design would discourage the use of global variables in
> such a way.
>
Agreed. I misread and thought we were talking about an interrupt.
Nathan
Re: Pass interrupt status to handler
Posted by Gregory Nutt <sp...@gmail.com>.
On 1/27/2023 12:15 PM, Nathan Hartman wrote:
> Is there a global structure where you retain state information where it
> would be appropriate to save the most refent known state in a volatile
> variable?
Good, modular design would discourage the use of global variables in
such a way.
RE: Pass interrupt status to handler
Posted by Tim Hardisty <ti...@hardisty.co.uk>.
No, not that I've created, although there might be one related to all the PIO I guess. Think I hoped that the basic NuttX interrupt mechanisms might inherently hold the state but couldn't immediately see it (including via debug).
No big deal - reading the PIO status is no issue, and I don't need to retain the state: if the input is low, there's an overcurrent state and if high there's not: kill power or don't, maybe notify any waiters to let the user know, that sort of thing.
>-----Original Message-----
>From: Nathan Hartman <ha...@gmail.com>
>Sent: 27 January 2023 18:15
>To: dev@nuttx.apache.org
>Subject: Re: Pass interrupt status to handler
>
>Is there a global structure where you retain state information where it
>would be appropriate to save the most refent known state in a volatile
>variable?
>
>On Fri, Jan 27, 2023 at 1:00 PM Tim Hardisty <ti...@hardisty.co.uk> wrote:
>
>> Think this is an easy one but it's stumped me so far...
>>
>> I am setting up the USB Overcurrent interrupt and can't find any fully
>> implemented examples.
>>
>> The interrupt is set to both edges as I want to know when the over
>> current state is first set and later hopefully cleared.
>>
>> I can obviously read the state of the input pin, but I sort of feel I
>> should be able to pass the state as an arg to the handler (via xcpt_t
>> handler).
>>
>> Is that possible and, if so, how?
>>
Re: Pass interrupt status to handler
Posted by Nathan Hartman <ha...@gmail.com>.
Is there a global structure where you retain state information where it
would be appropriate to save the most refent known state in a volatile
variable?
On Fri, Jan 27, 2023 at 1:00 PM Tim Hardisty <ti...@hardisty.co.uk> wrote:
> Think this is an easy one but it's stumped me so far...
>
> I am setting up the USB Overcurrent interrupt and can't find any fully
> implemented examples.
>
> The interrupt is set to both edges as I want to know when the over current
> state is first set and later hopefully cleared.
>
> I can obviously read the state of the input pin, but I sort of feel I
> should be able to pass the state as an arg to the handler (via xcpt_t
> handler).
>
> Is that possible and, if so, how?
>