Time sensitive process

[rd...@iinet.net.au]

Hi,

 

I have a need to execute a section of code at a consistent time interval, for instance every 10ms +/- a few hundred us. The code will take only a few us to execute. I was thinking of executing this code in the rt_timer_handler interrupt handler prior to calling rt_tick_increase. Or should I use another hardware timer for this?

 

Any other ideas?

 

Regards,

Rob

 

[bernard]

Hi Rob,
Using a hardware timer would be more accurate.

BTW,
Please notice that RT-Thread development repo was moved to github:
https://github.com/RT-Thread/rt-thread

2013/1/18 <rd...@iinet.net.au>

 

--
You received this message because you are subscribed to the Google
Groups "rt-thread-users" group.
To post to this group, send email to rt-thre...@googlegroups.com
To unsubscribe from this group, send email to
rt-thread-use...@googlegroups.com

[rd...@iinet.net.au]

RT-Thread version:  1.0.2

BSP: Mini2440

 

I probably should have mentioned in my last post is that I need to send and receive ethernet packets at a fixed rate (ie. every 2ms). I have implemented this using a hardware timer (Timer 3 of the S3C2440) but as soon as the timer generates an interrupt and the routine attempts to send and receive a packet I get an exception (thread dump). I have verified that the timer is generating interrupts at the specified rate. The functions being called to send/receive the packet work fine outside of the interrupt routine.

 

I am able to start a thread that calls the send/receive functions and then waits for the remainder of 2ms and it works, however it is not consistent enough as other threads get executed. As soon as I call these functions from an ISR it crashes.

 

Any ideas what I'm missing?

 

Regards,

Rob

[prife]

please  note that,  those apis which may suspend the current thread could not be called in isr!

that is,  rt_sem_take/rt_malloc  can not be useg in isr,  while  rt_sem_release can..

[rd...@iinet.net.au]

 

I didn't think there were any calls to such APIs but it's possible.

 

I'm thinking maybe I can create a high priority thread and use the timer to resume the thread, the thread can then do what it needs to do and suspend itself. The ISR will return immediately one it resumes the thread. The thread will need to be of lower priority than the network interface threads but higher than any others.

 

Anyone see any problems with this?

 

Regards,

Rob

[bernard]

there are some functions should not be called in isr.

Yes, you can define a thread with a highest priority level to hand the rest things, that is, half bottom handling for ISR in Linux.