Hello,

I need to increase the portTICK_RATE_HZ. This should be okay because I am using a LPC2292, which runs at 58.982.400Hz. I need a portTICK_RATE_HZ of at least 600.000 Hz but for convenience I used 1.000.000Hz. In order to achieve this I changed or added the following defines:

#define portTICK_RATE_HZ( ( portTickType ) 1000000 )

#define portTICK_RATE_MICROS( ( portTickType ) 1000000 / portTICK_RATE_HZ )
#define portTICK_RATE_MS( portTickType )( portTICK_RATE_MICROS * 1000 )

However having done this, FreeRTOS doesn't run. Can anyone give some assistance?

Thank you in advance!

Kind regards,
Teun van de Berg

I don't think it would be possible to have a 1MHz tick with a 60MHz clock. This would only allow 60 clock cycles per tick.

Why do you want the tick rate so high, what function are you performing? Maybe there is another way of achieving your objectives?

I'm sorry. I included a 0 to many. It should have been 60.000. But for convinience I set the tickrate to 100.000. We need this to be able toll a pin faster than 30kHz and still have (block) time for calculations.

60K is still very fast. I'm not sure if it is possible. You presumable have to process each polled input and react somehow to changes.

portTICK_RATE_MS would be less than 1 - and as this is a integral variable this cannot be. However, this would not really matter as the constant is not used by the kernel - only the demo program as a convenient way of generating time values.

If setting 30KHz was possible you would then have to modify the kernel slightly to ensure that the poll task was woken every tick, and ensure that the poll task had completed and blocked again before the next tick. This could be done with a semaphore and a tick hook.

Alternatively, would it be possible to:

+ Have the input you are monitoring on an external interrupt so you need only process it when it's state changes.

+ If these are the only function then maybe if you don't use a kernel, have your calculation running in a continuous loop, and have the pin being polled in a simple timer ISR (if this can be done at 30KHz which is also a bit doubtfull).

+ Use an FPGA instead of a microcontroller.

+ Have a lower priority task poll the input - and have it preempted by the calculation?

+ Have the poll take place as a tick switch hook?

Regards,
Richard.

Thank you for your reply. To answer your questions:


It is not possible to attach it to a external interrupt because the layout for the board has already been made.

We cannot use an FPGA as this doesn’t suit our requirements.

The polling task must have the highest priority, as this is the most important task on our system.

The last option might be possible. I'll keep it in mind.


As I am currently experiencing problems with an increased tick rate I'll try to use timer 1 to generate an interrupts for a polling mechanism.

Kind Regards,
Teun van de Berg

Is it correct that freeRTOS will not run with standard setup and a portTICK_RATE_HZ of 1 kHz, meaning a resolution of 1 ms??

This is definitely not true - all the demo applications use a tick rate of 1KHz.

portTICK_RATE_HZ is port specific right?? Using SAM7 this is set to 250 Hz/4 ms, my apps runs without any problems under 1 KHz but above that nothing happens, why is that? I actually need it to run under 2 KHz in order to synchronize sampling... Is this possible or do I get to much overhead already above 1 KHz?

//MB

portTICK_RATE_HZ is actually application specific – in that each application will want to change the value. V3.0.0 has therefore renamed the constant to configTICK_RATE_HZ and moved the definition out of portmacro.h.

2KHz should not be a problem for the SAM7 assuming it is running at a high clock frequency. The high tick rate will however decrease efficiency as the kernel will be using more CPU time.


portTICK_RATE_MS is defined as (1000/portTICK_RATE_HZ) so will therefore give 0 (integer) for a portTICK_RATE_HZ of 2000. This will be causing you the problem.

portTICK_RATE_MS is not a required definition and is really only included for the purpose of making the demo application a little more readable. It is just the number of ticks that occur in a millisecond. It is used by the demo application to calculate delay times in ticks (required by the API) rather than ms. It is not used by the kernel itself ***BUT IS USED BY THE SAM7 PORT TO CALCULATE THE portPIT_COUNTER_VALUE CONSTANT***. portPIT_COUNTER_VALUE is used within port.c to setup the timer interrupt to generate ticks at the required frequency. If the portTICK_RATE_HZ is greater than 1000 then the timer will not get set up – hence your problem.

You will have to replace all occurrences of portTICK_RATE_MS with the correct value. The only place you definitely have to change is in port.c – but if your application makes use of portTICK_RATE_MS or makes used of demo application files that use the definition – then these too will need changing.

Regards.

OK! I get it, changed it and now it runs... Very good!

I have to say that the response time on this forum is exceptionally good, it really helps! Thanks!