This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RTC intr, context switch question
- From: Lars Poeschel <larsi at wh2 dot tu-dresden dot de>
- To: "eCos Discussion" <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 30 Mar 2007 11:00:36 +0200
- Subject: [ECOS] RTC intr, context switch question
Hello!
I am implementing context switch mechanism for fr30 architecture and maybe I
did understand something wrong. My current interrupt handling is as follows:
An interrupt causes a lookup in hal_vsr_table and a jump to the location read
there (normally contains address of __default_interrupt_vsr).
__default_interrupt_vsr then completly saves CPU context, and calls
hal_interrupt_handlers[vector](vector, hal_interrupt_data[vector]).
After that interrupt_end(return_val, hal_interrupt_objects[vector],
regster_state) is called, once this returns, saved CPU state is restored and
return to program happens.
The kernel installs a scheduler_isr into the hal_interrupt _handlers, where
HAL_THREAD_SWITCH_CONTEXT macro is called to switch from current to next
thread. Is it right that HAL_THREAD_SWITCH_CONTEXT again saves CPU context to
current threads stack ? Then I would have 2 contexts on stack and only one
would be restored, because HAL_THREAD_SWITCH_CONTEXT immediately returns to
next thread without using the rest of __default_interrupt_vsr where the
context saved at the beginning of __default_interrupt_vsr is finnally
restored.
I think this is not the way it should work. Please point me to the right
direction.
Thanks,
Lars
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss