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 <spudan...@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 <t...@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? >>>
