ok, the problem with the new interrupt setup code is, that xintc_l.c, XIntc_DeviceInterruptHandler() is the real new interrupt handler which will call the FreeRTOS one, so
XIntc_DeviceInterruptHandler()
1. will do some stuff
2. call __FreeRTOS_interrupt_handler()
3. will do some other stuff
So if I understand it correctly. Instead of jumping from portRESTORE_CONTEXT (rtid/rtsd) directly back to code, freertos would "only" have edit the stack…is that even possible?
> ok, the problem with the new interrupt setup code is, that xintc_l.c,
> XIntc_DeviceInterruptHandler() is the real new interrupt
> handler which will
> call the FreeRTOS one, so
So this is the function installed on the 0x10 vector. It might be possible to replace that prior to the libraries being built, so it calls the FreeRTOS.org handler directly.
> XIntc_DeviceInterruptHandler()
> 1. will do some stuff
> 2. call __FreeRTOS_interrupt_handler()
> 3. will do some other stuff
This sounds like the Microblaze is now more like the Xilinx/PowerPC code, which I suppose would make sense.
I would have to look at what the library code does. If it has the same functionality as the PowerPC interrupt entry code then it will save all the registers for you, which can make things easier. The FreeRTOS handler then just has to save the link register and save the stack pointer into the TCB - nothing else. When the task next runs it loads the stack pointer from the TCB and restores the link register before simply returning to the library code, which then pops off all the registers.
This would mean the portSAVE_CONTEXT and portRESTORE_CONTEXT macros would disappear.
I read this thread with special attention, cuz i ran into the same problems as you encountered. Have you found and solution so far to the FreeRTOS working under the newer IP Cores that came with edk 9.2?
For some reasons it now ticks a few times (led on, led off…) but after after 5 times toggling a led, the return address after vTaskSwitchContext() in the ISR points back to the ISR itself.
Could somebody explain me why, under EDK 7.1, the demo application no longer works when I remove the call to vTaskSwitchContext() in port.c, vTickISR()?
vTaskSwitchContext is a badly named function. It does not switch any context but does select the next task to run. If you remove it from the tick interrupt then you are effectively running the system in cooperative mode. In cooperative mode a switch between tasks will only occur when taskYIELD is called or when an interrupt calls taskEND_SWITCHING_ISR (or whatever the macro is called in the Microblaze demo).
Setting configUSE_PREEMPTION to 0 should have the same effect.
Correct - vTaskDelayUntil() will place the task in the Blocked state, then call yield to switch aware from the (now blocked) task.
The tick interrupt does two things.
+ First it increments the time. When the time has been incremented it checks the Blocked state tasks to see if the new time should cause any tasks to unblock. In the case of a task that was blocked using vTaskDelayUntil() if the time at which the task should unblock has been reached the task will be moved from the Blocked state to the Ready state. It will not be switched in though.
+ Second, if configUSE_PREEMPTION is set to 1, it looks at all the Ready state tasks and selects the highest priority one to enter the running state.
It is the second part that you are removing by deleting te call to vTaskSwitchContext(). Therefore the flash tasks will get unblocked when their delay period expires, but will not be moved from the Ready to the Running state until the currently running task either blocks itself, or calls yield.
If configUSE_PREEMPTION is set to 0 then the idle task will continuously call yield. If configUSE_PREEMPTION is set to 1, AND configIDLE_SHOULD_YIELD is set to 1, then the idle task will also yield if there is a higher priority task that is ready to run. So these two options provide a way for unblocked flash tasks to actually transition to the Running state when vTaskSwitchContext() is not called from the tick interrupt.
I mean, I have a working configuration, but it doesn’t involve the xintc (Interrupt Controller) module, so the timer is the only possible interrupt source.
As soon as I try to do the whole stuff with the xintc module, it fails for various reasons.
Right. I finally got it working. The answer is soo damm simple. Problem is to find the right documentation.
Also found some documentation in my EDK Installation that disagree on each other. Xilinx will get a Mail from me on this.
Richard, do you prefer an unified patch file, or list of items what to change? (Its not that much).