Re: imxrt interrupt locking
On Thu, May 4, 2023 at 8:08 AM Jernej Turnsek wrote: > > Hi, > thanks. Will take a look. > > On Thu, May 4, 2023 at 1:25 PM Nathan Hartman > wrote: (snip) > > I found it in the old wiki: > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts > > > > I don't see it in the repo Documentation. This is an important thing that > > should be in the repo. Just following up... I just opened PR #9302 [1] to bring this documentation into the repo. Once merged and processed by CI, it will also appear in the nuttx.apache.org site and therefore will be easier for users to find. [1] https://github.com/apache/nuttx/pull/9302 Cheers, Nathan
Re: imxrt interrupt locking
Hi, thanks. Will take a look. On Thu, May 4, 2023 at 1:25 PM Nathan Hartman wrote: > On Thu, May 4, 2023 at 7:11 AM Nathan Hartman > wrote: > > > On Thu, May 4, 2023 at 5:46 AM Jernej Turnsek > > wrote: > > > >> I am developing a driver which is processing peripheral interrupts every > >> 6.4 microseconds and every 16th interrupt calling notify function from > HP > >> work queue. But scheduling workqueue does lock interrupts (through > >> critical > >> section) up to 20us sometimes, causing my peripheral missing interrupts. > >> The same thing occurs if calling the notify function with nxsem_post > >> directly from ISR. DMA is not an option. I am working with the NXP > RT1064 > >> board. How can I wake the read function without locking interrupts? > >> Thanks. > >> > > That chip is Arm Cortex M7. I think zero-latency interrupts are supported > > on that. If so, you could try to use that to service the 6.4us interrupt. > > > > Zero-latency interrupts cannot use OS services because they exist outside > > the OS. Therefore, to rendezvous with the hp queue, each 16th interrupt, > > trigger an otherwise unused interrupt vector, which will be serviced by a > > "normal" ISR, which can in turn hand off the data to the hp queue. > > > > There's a page about this somewhere... > > > > > I found it in the old wiki: > > > https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts > > I don't see it in the repo Documentation. This is an important thing that > should be in the repo. > > Cheers > Nathan >
Re: imxrt interrupt locking
On Thu, May 4, 2023 at 7:11 AM Nathan Hartman wrote: > On Thu, May 4, 2023 at 5:46 AM Jernej Turnsek > wrote: > >> I am developing a driver which is processing peripheral interrupts every >> 6.4 microseconds and every 16th interrupt calling notify function from HP >> work queue. But scheduling workqueue does lock interrupts (through >> critical >> section) up to 20us sometimes, causing my peripheral missing interrupts. >> The same thing occurs if calling the notify function with nxsem_post >> directly from ISR. DMA is not an option. I am working with the NXP RT1064 >> board. How can I wake the read function without locking interrupts? >> Thanks. >> > That chip is Arm Cortex M7. I think zero-latency interrupts are supported > on that. If so, you could try to use that to service the 6.4us interrupt. > > Zero-latency interrupts cannot use OS services because they exist outside > the OS. Therefore, to rendezvous with the hp queue, each 16th interrupt, > trigger an otherwise unused interrupt vector, which will be serviced by a > "normal" ISR, which can in turn hand off the data to the hp queue. > > There's a page about this somewhere... > I found it in the old wiki: https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts I don't see it in the repo Documentation. This is an important thing that should be in the repo. Cheers Nathan
Re: imxrt interrupt locking
On Thu, May 4, 2023 at 5:46 AM Jernej Turnsek wrote: > I am developing a driver which is processing peripheral interrupts every > 6.4 microseconds and every 16th interrupt calling notify function from HP > work queue. But scheduling workqueue does lock interrupts (through critical > section) up to 20us sometimes, causing my peripheral missing interrupts. > The same thing occurs if calling the notify function with nxsem_post > directly from ISR. DMA is not an option. I am working with the NXP RT1064 > board. How can I wake the read function without locking interrupts? Thanks. > That chip is Arm Cortex M7. I think zero-latency interrupts are supported on that. If so, you could try to use that to service the 6.4us interrupt. Zero-latency interrupts cannot use OS services because they exist outside the OS. Therefore, to rendezvous with the hp queue, each 16th interrupt, trigger an otherwise unused interrupt vector, which will be serviced by a "normal" ISR, which can in turn hand off the data to the hp queue. There's a page about this somewhere... Nathan
imxrt interrupt locking
I am developing a driver which is processing peripheral interrupts every 6.4 microseconds and every 16th interrupt calling notify function from HP work queue. But scheduling workqueue does lock interrupts (through critical section) up to 20us sometimes, causing my peripheral missing interrupts. The same thing occurs if calling the notify function with nxsem_post directly from ISR. DMA is not an option. I am working with the NXP RT1064 board. How can I wake the read function without locking interrupts? Thanks.
