FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [December 2014 Threads] M14K port questionPosted by os21doug on December 10, 2014 Hi,
I am looking at using the MIPS M14K port for a product. I notice that the only FreeRTOS port for the M14K does not make use (take advantage of) the shadow registers. On interrupt entry it saves task context straight away before servicing the interrupt. I can see why this is done - it puts everything in a consistent state, ready for any context switch that the ISR may cause. I suppose that if you take the view that any ISR that is doing 'real work' is likely to post a semaphore or send a message, and that a context switch out of ISR is the typical case, then this makes sense. (I did the same in an RTOS I once wrote). However, there may be cases where we have interrupts that we need to service very quickly, even without the need to communicate with a task, and the speed advantage of the shadow registers is highly desirable. Has anyone looked at the possibility of tweaking the port to do this? Or am I on my own on this?
A related side question, which is more architectural: I notice that FreeRTOS does not have a proper scheduler lock (disable pre-emption mode). Rather it relies heavily on disabling/enabling interrupts for critical sections. Has anyone attempted to address this in any of the ports? It should be simple enough to add a soft lock to the scheduler, so you prevent (actually defer) thread switches during critical sections, without affecting interrupt latency? Quite happy to hack this in myself, but if someone has already done it....
Cheers,
Doug
M14K port questionPosted by os21doug on December 10, 2014 Answering my own question on the 2nd point, it looks like vTaskSuspendAll() and xTaskResumeAll() are what I want (provided I don't block in between the two calls!).
Doug
M14K port questionPosted by rtel on December 10, 2014 The M4K hardware the port was created on didn't implement the shadow registers (from memory) so they were never used. There is no reason not to make use of them, and if you are not using any kernel functionality in the interrupts then you could do that outside of the kernel code. You would probably want to ensure the priority of the interrupts was above configMAXSYSCALLINTERRUPT_PRIORITY though.
Regards.
M14K port questionPosted by rtel on December 10, 2014 You may also be interested in this contribution, although we can't support it directly:
http://interactive.freertos.org/entries/67933519-FreeRTOS-8-1-2-for-MIPS32-processor-cores
Regards.
M14K port questionPosted by os21doug on December 10, 2014 Great! Understood. Thanks for the tips!
Cheers,
Doug
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|