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:
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?
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?
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.