5us timer interrupt

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

5us timer interrupt

Jump to solution
4,134 Views
firmware_design
Contributor II

I am trying to get a timer interrupt going. I am able to get something like 50us with the follow code

setittimer(ITIMER_REAL, &timer, NULL);

it will go to the handler every ~50us seems to be the fastest I am drive it. I am trying to toggle an IO at the speed to enable the conversion of my ADC IC.

Any help would be appreciated.

Samuel

1 Solution
1,888 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Samuel

     Do you use linux OS?

     Based on my understanding, the timer can NOT guarantee your handler can be called in 5us, and due to linux's interrupt handle flow, I don't think regular irq can meet your 5us request, as I have ever tried FIQ, it normally needs about 2us, which I copy the code to the high address vector. So, in you case, can you try using polling? If you want to use interrupt, then I think you can try to use hrtimer.

View solution in original post

0 Kudos
12 Replies
1,888 Views
erickang
Contributor II

Hi YH,
I'm finding the FIQ applying method into i.MX25.

The GPT/EPIT interrupt was not operating normally.
But the GPT/EPIT interrupt driver was operated normally in the i.MX25 3Stack EVM board.
So I think my board have some problem, but I couldn't find the reason.

I want to apply other interrupt method as work-around.
One of the work-around is FIQ.

I saw you had ever tried FIQ in the upper post.
Could you tell me how to apply FIQ?

My development envionment is like below.
- CPU : i.MX257
- OS : Linux 2.6.31

Best Regards,
Eric.

0 Kudos
1,888 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Eric

     I think the best way is to dig out the root cause of the GPT/EPIT.

     If you really want to try FIQ, you can search the kernel for FIQ implement, and you also need to enable the fiq mode of dedicated interrupt you want, the config should be in i.MX25's interrupt controller.

     Sorry that I only enable FIQ on v3.0.35, I don't know how v2.6.31. I looked through v2.6.31, I think you can refer to i.MX28, it has FIQ enabled, drivers/power/mxs/linux.c mxs_bat_init(). Basically, you need to get_fiq_regs, set_fiq_handler, mxs_set_irq_fiq etc...

0 Kudos
1,888 Views
sunyu
Contributor II

Dear Mr Huang!

     I see you saw "I think the best way is to dig out the root cause of the GPT/EPIT." in the upper post.

     I was a beginner, can you indecate an idea for me? or give me some information? because i feel unable to start.

     sabresd (i.MX6Q linux3.0.35)

Best Regards

Sunyu

0 Kudos
1,888 Views
erickang
Contributor II

Hi YH,

Then could you give me the reference code for Linux 3.0.35?

I want to refer to the code for Linux 2.6.31.

Best Regards,

Eric.

0 Kudos
1,888 Views
AnsonHuang
NXP Employee
NXP Employee

Hi,

Please see attached FIQ implement on v3.0.35, EPIT using FIQ. Please be aware of the difference of interrupt controller, our i.MX6 use GIC.

Best Regards.

Anson huang 黄勇才

Freescale Semiconductor Shanghai

上海浦东新区亮景路192号A座2楼

201203

Tel:021-28937058

0 Kudos
1,888 Views
erickang
Contributor II

Dear Yongcai Huang,

We decided to apply the GPIO Interrupt for i.MX257 Interrupt.

We confirmed the normal operation on the customer board.

So I'm holding the FIQ application.

But I'll try to apply the FIQ in the i.MX257 later.

Thanks for your advice.

Best Regards,

Eric.

0 Kudos
1,888 Views
erickang
Contributor II

Hi Yongcai Huang,

Thanks for your response.

I'll refer to your patch for i.MX257 FIQ.

Best Regards,

Eric.


0 Kudos
1,888 Views
firmware_design
Contributor II

irq_interrupt() seems to require a parameter, I have tried irq_interrupt(9), it doesnt seem to help.

Regarding the hrtimer, I am thinking if it might be possible to use that for my 5us timer and run the SPI read. (I need to do a GPIO toggle before reading SPI). However if each read takes about 20us and the interrupt keeps nesting at every 5us interval it might not be right. I am really stuck here. What is the function to disable the irq in order to get the usleep to work at 5us?

0 Kudos
1,888 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Raj

     I think you should use udelay instead of usleep, udelay is a busy loop based on CPU freq, and it should be accurate. And you can use local_irq_save and local_irq_restored if you want to disable irq during this delay.

0 Kudos
1,889 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Samuel

     Do you use linux OS?

     Based on my understanding, the timer can NOT guarantee your handler can be called in 5us, and due to linux's interrupt handle flow, I don't think regular irq can meet your 5us request, as I have ever tried FIQ, it normally needs about 2us, which I copy the code to the high address vector. So, in you case, can you try using polling? If you want to use interrupt, then I think you can try to use hrtimer.

0 Kudos
1,888 Views
firmware_design
Contributor II

Hi YH,

I am trying usleep(5) and it give me >18us instead in delay. I tried toggling GPIO4_29 this is using the iMX53 ubuntu linux. The IO is toggling at 500ns interval. Low to high. I am not sure why usleep() need >18us ... This happens when using the SPI if I read single bytes instead of a buffer even clocking at 25MHz is does the function and has a 20us idle between reads. Like to solve this...

0 Kudos
1,888 Views
AnsonHuang
NXP Employee
NXP Employee

HI, Samuel

       If udelay is not accurate, then I think this is a big issue, can we first make sure udelay is accurate? How did you get the 18us when you only delay for 5us? By measuring the GPIO using a scope? Such as Before udelay 5us, we set a GPIO from high to low, then do the delay, then set the GPIO from low to high,now we can get the actual delay it goes from scope. Keep in mind that we need to disable IRQ when doing this test.

        The udelay based on CPU loop, there is a global variable called loops_per_jiffies, every time CPU freq changelooping variable need to be updated. I think udelay should be accurate, otherwise, there shoul be big issue in kernel.

         Can you please try to make sure udelay is accurate first? Try what I describe upper, disable IRQ, pull down/up a GPIO and  using scope to measure the GPIO, then read the time from scope to see whether the interval of the GPIO status change is same as the delay time we set.

          If udelay is accurate enough, then we can go on your case.

0 Kudos