You are measuring two delays here:
- first, when the two timers are started by your code, there will be a small delay between them (the time needed to execute the _Start() call)
- second, you measure the time your ISR takes to execute. Remember, only one can be active at any time, so when you are about to set P1 high, you cannot handle P2 at the same time
So if you want to do stuff with critical timing, do it in hardware. Just route the output pin from the time to your digital output pin.
There are some different properties you have to consider:
1st The frequency of the Internal Main Oscillator (IMO). The precision is given in the datasheet and can be improved by using an external oscillator.
2nd: the synchronous start of the two timers which cannot be archieved in software directly but may induced by a control-register.
3rd: The response-time to the interrups which is not zero and the priority each interrupt has got may prevent (for a short time) the handling of the second interrupt. Better will be to connect the outputs of the timer (TC or Interrupt) directly to a pin to prove the stability of the timers.
4th: The time spent in the interrupt handler can spoil some of your required stability and synchronization. Again I would suggest you to put most of your progect into hardware.
When you tell us a bit more what you try to perform we probably could give you some advices.
Yeah, I just managed to come up with a condensed version of what you wrote :)
Thanks @hli and @Bob Marlowe for your comments, I did expected the delay as only one will be active at a time, But I was trying to achieve some sort of consistancy here.
Let me explain the project : I am working towards establishing a PSI5 protocol. I want to handle two sensors with minimum latency using single micro. PSI5 => Data packets to be sent out at desired frequency and in a specific time slot. Say period is 500 us, 250 or anything less than 500 us. Data latency limit is 2.1 us, and I am way off that tolerance level.
As correctly mentioned above, ISR execution time is spoiling the required stability. ISR execution time currently is quite high, close to 8us. I am thinking that I'll just set Flags in the ISR and process these flags in seperate timer.
Is timer block the only way for performing periodic tasks ?
There is a SysTick timer inherent to ARM m3, but this can only be handled with an interrupt, and is not able to get connected to an internal signal.
Since we do not know whether your design will allow for that (although it can be MADE to), did you already consider using DMA for data transfer which will run in hardware, no interrupt needed, no CPU needed, just setup and fire...
So, what does your direct interface look like? what data do you need to transfer?? what is the datarate???
I initially did considered DMA, But it doesn't help the cause for following reasons.
I am using SPIM block to transmit manchester encoded data, and this data has to be sent every 500us. Lets say I trigger the DMA using a clock at desired freq. I have to Tx a huge chunk of data(10 K bytes for instance). Each data is 16 bits.
Burst -2bytes per request , TD chaining => TD 0- load 2bytes in SPI FIFO. Now i don't have enough resources to load 10 K of data, SO i need to implement rolling buffer or else 2 buffers( 1 being loaded and second being used for TX) . I am unable to achieve it via DMA. ( Moreover two such devices means double the RAM, i'll run short of RAM).
Moreover 16 bit DMA transfer to SPIM FIFO induce more complexity, The data o/p need to be formatted.
I fogot to mention data rate - 125 KHz / 189 Khz (configurable option)
if I understand you right the SPIM is the limiting function within your system. there is no need to collect data faster than you can send them. So to have room for your tight timing it seems best to collect a new set of data while the actual one is transmitted. maintaining a short(!!!) circular buffer could be of some help, alarge buffer (10K as you suggested) does not improve the performance when you continuously send the collected data.
SPIM data (as you already did) should be transmitted using DMA and of course you may use two (small) buffers.
You did not tell where your transmitted data is generated from, SAR? ADC?? Other sensors??? Does the data collection use (much) CPU MIPS?
Data to be transmitted is read from SD card using emfile component, I am yet to work on this part. I am in initial phase of the project. So I need to read data from SD card and push it to the buffers. I'll work it out in coming days and update you on this. I am hoping that i'll be able to meet the timings somehow.
If you collect data faster than you can transmit consider averaging as it
increases effective resolution, reduces noise contribution. Oversampling
does have its benefits.
Look at the AppNotes for DMA: http://www.cypress.com/?rID=37793 , http://www.cypress.com/?docID=44514 and http://www.cypress.com/?rID=44335 . What you need is called "ping-pong DMA", Basically its that the DMA automatically switches between two buffers (in the DMA intro, its chapter 5 and called TD chaining).
That way you just need the notification about the switch, to fill the unused buffer with new data. The buffers can be small (e.g. 512 bytes == 256 words).
Does your SPI need to assert the SS signal for each word separately? The SPI component can do that automatically, so you might get away with 8 bit transfers.