I'll try to experiment with this, but as I mentioned I'm not sure if it will be
useful for this
case since I need to interact with the OS.
You would perform the time critical portion in the interrupt handler
then schedule the OS interaction via PendSV.
We might want to look at the docs and see if what Greg just explained a few
minutes ago is documented there.
Also worth remembering that this is only an ARMv7-M and ARMv8-M feature
because it depends on (1) having true prioritized interrupts (ARMv6-M
does not) and (2) the ability to execute
On Wed, Oct 28, 2020 at 1:10 PM Matias N. wrote:
> I'm okay with ns jitter. I need to satisfy a 150uS timing response, so
> that is OK.
>
> Outside the context of RTOSs, isn't this just defining your own interrupt
> handler? Maybe
> it should be called "custom interrupt handler"?
>
Well I think
I'm okay with ns jitter. I need to satisfy a 150uS timing response, so that is
OK.
Outside the context of RTOSs, isn't this just defining your own interrupt
handler? Maybe
it should be called "custom interrupt handler"?
I'll try to experiment with this, but as I mentioned I'm not sure if it wil
On 10/28/2020 10:41 AM, Nathan Hartman wrote:
On Tue, Oct 27, 2020 at 10:21 AM Alan Carvalho de Assis
wrote:
Hi Nathan,
I totally agree! Zero Jitter Interrupt is a better name.
We don't have zero latency, we have zero jitter.
BR,
Alan
The latency is pretty close to zero too, because it
On Tue, Oct 27, 2020 at 10:21 AM Alan Carvalho de Assis
wrote:
> Hi Nathan,
>
> I totally agree! Zero Jitter Interrupt is a better name.
>
> We don't have zero latency, we have zero jitter.
>
> BR,
>
> Alan
The latency is pretty close to zero too, because it interrupts whatever
else is happenin
Hi Nathan,
I totally agree! Zero Jitter Interrupt is a better name.
We don't have zero latency, we have zero jitter.
BR,
Alan
On 10/27/20, Nathan Hartman wrote:
> On Tue, Oct 27, 2020 at 10:03 AM Matias N. wrote:
>
>> Hi Nathan,
>> as I mentioned in my previous email, this isn't about overhe
And I just wrote this questions while you were writing the answers =)
Thanks, I understand a bit better that this indeed interrupts other ISRs.
On Tue, Oct 27, 2020, at 11:12, Nathan Hartman wrote:
> On Tue, Oct 27, 2020 at 10:03 AM Matias N. wrote:
>
> > Hi Nathan,
> > as I mentioned in my pre
errupt priorities imply nested interrupts? It isn't clear
> >> > > > to
> >> > me if
> >> > > > priorities only mean which ISR will get served first when they are
> >> > pending
> >> > > > together or if it also implies that a
On Tue, Oct 27, 2020 at 10:03 AM Matias N. wrote:
> Hi Nathan,
> as I mentioned in my previous email, this isn't about overhead, is about
> other ISRs delaying mine.
I didn't see your reply until after, but Zero Latency Interrupts should
more aptly be called Zero Jitter Interrupt, because jitte
t;> > > > happens
>> > > automatically, you have to enable the interrupt manually after the
>> > critical
>> > > CPU register and OS state is saved.
>> > >
>> > > My recollection is it depends on the priority assigned to the
>> >
Hi Nathan,
as I mentioned in my previous email, this isn't about overhead, is about other
ISRs delaying mine.
This happens only so often if I'm unlucky, so it isn't like it breaks the
communication completely.
But I would like to trust the communication more and know that if I start
processing I
On Tue, Oct 27, 2020 at 4:09 AM Xiang Xiao
wrote:
> On Tue, Oct 27, 2020 at 7:43 AM Matias N. wrote:
>
> > As Greg mentioned in the corresponding open issue, TizenRT took Greg's
> > snippets from the Wiki page and mostly implemented that. Couldn't really
> > find more changes than that, so I'm n
;
> > > My recollection is it depends on the priority assigned to the interrupt
> > and
> > > the fence level used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The
> > system
> > > will crash due to reentrancy on the common vector, if the values, and
&
t; the fence level used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The
> system
> > will crash due to reentrancy on the common vector, if the values, and
> vector
> > are not managed properly.
> >
> >
> > -Original Message-
> > From: Xiang Xiao
used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The system
> will crash due to reentrancy on the common vector, if the values, and vector
> are not managed properly.
>
>
> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Sunday, October 2
.apache.org
Subject: Re: interrupt priorities on nRF52
On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote:
> Hi,
> while working on nRF52 BLE link-layer I experienced some problems due to
> delayed ISRs. This can be quite problematic
> for handling all the tight timings required by the
On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote:
> Hi,
> while working on nRF52 BLE link-layer I experienced some problems due to
> delayed ISRs. This can be quite problematic
> for handling all the tight timings required by the standard. I eventually
> reached an implementation that can deal wit
te: 10/25/20 4:35 PM (GMT-06:00) To:
> dev@nuttx.apache.org Subject: Re: interrupt priorities on nRF52 Nuttx does
> not support nested iteruups. In fact if you enableprioritization, you will
> get random crashes due to the reentrace to thecommon isr.On Sun, Oct 25,
> 2020, 1:52 P
priorities on nRF52 Nuttx does not support nested iteruups. In fact
if you enableprioritization, you will get random crashes due to the reentrace
to thecommon isr.On Sun, Oct 25, 2020, 1:52 PM Matias N.
wrote:> Hi,> while working on nRF52 BLE link-layer I experienced some problems
Nuttx does not support nested iteruups. In fact if you enable
prioritization, you will get random crashes due to the reentrace to the
common isr.
On Sun, Oct 25, 2020, 1:52 PM Matias N. wrote:
> Hi,
> while working on nRF52 BLE link-layer I experienced some problems due to
> delayed ISRs. This c
Hi,
while working on nRF52 BLE link-layer I experienced some problems due to
delayed ISRs. This can be quite problematic
for handling all the tight timings required by the standard. I eventually
reached an implementation that can deal with this relatively well (BLE standard
gives some leeway for
22 matches
Mail list logo
