My freertos version is 7.0.0 and in header file freeRTOSCofig.h #define configMAX_SYSCALL_INTERRUPT_PRIORITY (0x05 << 4) //priority 5, or 80 as only top four bits are implemented #define configKERNEL_INTERRUPT_PRIORITY (0x0f << 4) // priority 15 , or 255 as only top four bits are implemented
In essence those documents tells that sysclk_interrupt_priority should be higher than kernel_interrupt_priority so task’s interrupts are not delayed or preempted by kernel’s interrupts.
so thats already properly set here… 80 is higher (logically in cortex m) than 255…
What is sysclk_interrupt_priority? If it is the priority used by systick (the tick interrupt) then it must absolutely not be higher than kernel interrupt priority because it is the kernel interrupt. It must be the lowest possible priority.
it says…
configMAX_API_CALL_INTERRUPT_PRIORITY is a new name for configMAX_SYSCALL_INTERRUPT_PRIORITY that is used by newer ports only. The two are equivalent.
from the same html page if you go through the definition of these .
For ports that implement both configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY:
configKERNEL_INTERRUPT_PRIORITY sets the interrupt priority used by the RTOS kernel itself. configMAX_SYSCALL_INTERRUPT_PRIORITY sets the highest interrupt priority from which interrupt safe FreeRTOS API functions can be called.
further…
The RTOS interrupt nesting scheme splits the available interrupt priorities into two groups - those that will get masked by RTOS critical sections, and those that are never masked by RTOS critical sections and are therefore always enabled.
The configMAX_SYSCALL_INTERRUPT_PRIORITY setting in FreeRTOSConfig.h defines the boundary between the two groups. The optimal value for this setting will depend on the number of priority bits implemented in the microcontroller.
my question is…
I am giving my code so that you can see what i am doing.just scan through this text file and tell me what you think.
driver for twim(the driver responds and goes to twim_master_read(), configuring interrupts. no need to look at 10 bit twim as its 7 bit twim. it contains one low power sleep that is called executing infinitely. for proper operation it goes in callback function and there completes the commands for read) http://snk.to/f-ctn8v3fn
i get the answer
i was missing one #define in conf_boards.h for twim channel
if its not there board pins will be taken as gpio pins rather than twi pins…
Has anyone actually tested the USART read to verify it blocks a task? I am using what appears to be the most current FreeRTOS v7.3.0 with ASF, and a call to freertos_usart_write_packet definitely does not block my task.
I am properly configured with USE_TX_ACCESS_SEM, USE_RX_ACCESS_MUTEX, WAIT_TX_COMPLETE, and WAIT_RX_COMPLETE, and am using 10ms of ticks to block (i.e. 10/portTICK_RATE_MS). The status returned is success.
Using a simple GPIO that I set high before the write, and drop low immediately afterwards clearly shows the GPIO low well before the USART transfer completes.
I did review the PDF mentioned above. I see nothing to suggest I’m doing anything wrong here.