Prev: ElektronikLaden compod serial protocol
Next: max number of led displays that could be multiplexed
From: brOS on 29 Jan 2010 04:31
Dear all,

I am testing my own kernel for MSP430. I am measuring highest frequency for
square signal that MSP430 with my kernel can repeat on its output.
Square signal is connected to one of the interrupt pins, so on every high
to low or low to high signal edge port interrupt is generated. In port ISR
I am releasing semaphore on which my task is blocked. After task is
unblocked its job is to toggle one pin declared as output. So i want to
found out what is the highest frequency when no pulsed is missed to be
repeated on the output pin.

While i was doing my test I found out that there are frequencies where
stack overflow appears(everz task has its stack where context is saved).
The thing is that when my Scheduler switches context back to idle task,
because interrupt rate is so high, it never have a chance to pop PC.
That part of code looks like this
From: WangoTango on 29 Jan 2010 10:57
In article <lqmdnQZqspt3N__WnZ2dnUVZ_r2dnZ2d(a)giganews.com>,
bogdanrosandic(a)n_o_s_p_a_m.gmail.com says...
> Dear all,
>
> I am testing my own kernel for MSP430. I am measuring highest frequency for
> square signal that MSP430 with my kernel can repeat on its output.
> Square signal is connected to one of the interrupt pins, so on every high
> to low or low to high signal edge port interrupt is generated. In port ISR
> I am releasing semaphore on which my task is blocked. After task is
> unblocked its job is to toggle one pin declared as output. So i want to
> found out what is the highest frequency when no pulsed is missed to be
> repeated on the output pin.
>
> While i was doing my test I found out that there are frequencies where
> stack overflow appears(everz task has its stack where context is saved).
> The thing is that when my Scheduler switches context back to idle task,
> because interrupt rate is so high, it never have a chance to pop PC.
> That part of code looks like this
>
Well, there's your problem......

;)

From: Thad Smith on 31 Jan 2010 17:30
brOS wrote:
> I am testing my own kernel for MSP430. I am measuring highest frequency for
> square signal that MSP430 with my kernel can repeat on its output.
> Square signal is connected to one of the interrupt pins, so on every high
> to low or low to high signal edge port interrupt is generated. In port ISR
> I am releasing semaphore on which my task is blocked. After task is
> unblocked its job is to toggle one pin declared as output. So i want to
> found out what is the highest frequency when no pulsed is missed to be
> repeated on the output pin.
>
> While i was doing my test I found out that there are frequencies where
> stack overflow appears(everz task has its stack where context is saved).
> The thing is that when my Scheduler switches context back to idle task,
> because interrupt rate is so high, it never have a chance to pop PC.
> That part of code looks like this

Some kernel operations need to be done with interrupts disabled. After your
task suspends itself on the semaphore, the kernel should not be interruptable
until the next (idle) task is running. Generally, interrupts are reenabled by
executing a RETI, which restores the status register, including the GIE
interrupt enable bit. At that point your PC has been popped.

--
Thad
From: brOS on 3 Feb 2010 06:43
>brOS wrote:
>> I am testing my own kernel for MSP430. I am measuring highest frequency
for
>> square signal that MSP430 with my kernel can repeat on its output.
>> Square signal is connected to one of the interrupt pins, so on every
high
>> to low or low to high signal edge port interrupt is generated. In port
ISR
>> I am releasing semaphore on which my task is blocked. After task is
>> unblocked its job is to toggle one pin declared as output. So i want to
>> found out what is the highest frequency when no pulsed is missed to be
>> repeated on the output pin.
>>
>> While i was doing my test I found out that there are frequencies where
>> stack overflow appears(everz task has its stack where context is
saved).
>> The thing is that when my Scheduler switches context back to idle task,
>> because interrupt rate is so high, it never have a chance to pop PC.
>> That part of code looks like this
>
>Some kernel operations need to be done with interrupts disabled. After
your
>task suspends itself on the semaphore, the kernel should not be
interruptable
>until the next (idle) task is running. Generally, interrupts are
reenabled by
>executing a RETI, which restores the status register, including the GIE
>interrupt enable bit. At that point your PC has been popped.
>
>--
>Thad
>

But, is the RETI instruction atomic? I think it s not?

---------------------------------------
Posted through http://www.EmbeddedRelated.com
From: Niklas Holsti on 3 Feb 2010 10:05
brOS wrote:
>> brOS wrote:
>>> I am testing my own kernel for MSP430. I am measuring highest frequency
> for
>>> square signal that MSP430 with my kernel can repeat on its output.
>>> Square signal is connected to one of the interrupt pins, so on every
> high
>>> to low or low to high signal edge port interrupt is generated. In port
> ISR
>>> I am releasing semaphore on which my task is blocked. After task is
>>> unblocked its job is to toggle one pin declared as output. So i want to
>>> found out what is the highest frequency when no pulsed is missed to be
>>> repeated on the output pin.
>>>
>>> While i was doing my test I found out that there are frequencies where
>>> stack overflow appears(everz task has its stack where context is
> saved).
>>> The thing is that when my Scheduler switches context back to idle task,
>>> because interrupt rate is so high, it never have a chance to pop PC.
>>> That part of code looks like this
>> Some kernel operations need to be done with interrupts disabled. After
> your
>> task suspends itself on the semaphore, the kernel should not be
> interruptable
>> until the next (idle) task is running. Generally, interrupts are
> reenabled by
>> executing a RETI, which restores the status register, including the GIE
>> interrupt enable bit. At that point your PC has been popped.
>>
>> --
>> Thad
>>
>
> But, is the RETI instruction atomic? I think it s not?

That is what RETI is intended for, so it should be atomic "enough".

Some quotes from the MSP430 description in the "MSP430x4xx Family" (TI
document SLAU056D):

Page 2-9:

"The ACCVIE, NMIIE, and OFIE enable bits should not be set inside of an
NMI interrupt service routine, unless they are set by the last
instruction of the routine before the RETI instruction. Otherwise,
nested NMI interrupts may occur, causing stack overflow and
unpredictable operation"

Page 3-40:

"The instruction following the enable interrupt instruction (EINT) is
always executed, even if an interrupt service request is pending when
the interrupts are enable."

It thus seems to me that the EINT/RETI pair work as is common: after an
interrupt is enabled, the response to a new or pending interrupt request
is delayed until the RETI has completed.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
 |  Next  |  Last
Pages: 1 2 3 4
Prev: ElektronikLaden compod serial protocol
Next: max number of led displays that could be multiplexed