garyt_npe | 29 May 2012 17:05
Favicon

Running four interval timers on STM32F2 and CAN in blocking mode

 

Hi, The project that I'm working on requires the use of four posix interval timers, like those in OSTEST, running concurrently. The firmware will run as expected with three timers running concurrently; however, when I add the forth, each timer's signal handler will no longer run. I use one of the interval timers to allow enough time for each CAN message to be sent without flooding the CAN write routine. I can eliminate the need for the forth timer if I could use the blocking mode on CAN writes. This doesn't seem to work either as the program hangs in CAN write on the very first message. The CAN driver works in non-blocking mode and correctly returns a -EAGAIN on writes when the TX FIFO's are full. As a work-a-round I'm going to try putting the CAN driver in non-blocking mode and h ave it retry each time a -EAGAIN error is received.

__._,_.___
Recent Activity:
.

__,_._,___
Gregory N | 30 May 2012 00:56
Picon
Favicon
Gravatar

Re: Running four interval timers on STM32F2 and CAN in blocking mode

 

> Hi, The project that I'm working on requires the use of four posix interval timers, like those in OSTEST, running concurrently. The firmware will run as expected with three timers running concurrently; however, when I add the forth, each timer's signal handler will no longer run.

When you create each timer, you have to provide a struct sigevent containing the signal number that you use. What signal numbers are you using for the your timers. Are they all unique? Only one signal action can be associated with a signal.

Notice in include/signal.h that some of the signal numbers (2-4) are used for other things.

You can, of course, use one signal handler for all of the events and just pick of the signal number to determine what timer expired.

Greg

__._,_.___
Recent Activity:
.

__,_._,___
garyt_npe | 30 May 2012 03:42
Favicon

Re: Running four interval timers on STM32F2 and CAN in blocking mode

 

Hi, I'm using 17, 19, 21 and 23 for my signal numbers. I've solved my immediate issue by removing the need of the CAN write delay timer which brings my interval timer requirement down to three. I've set up the CAN device to be non-blocking and I resend the message on any returned write errors up to a maximum error count of three. This is not my final solution but I have to do a release tomorrow. ~Gary

--- In nuttx-hHKSG33TihhbjbujkaE4pw@public.gmane.org, "Gregory N" <spudarnia <at> ...> wrote:
>
> > Hi, The project that I'm working on requires the use of four posix interval timers, like those in OSTEST, running concurrently. The firmware will run as expected with three timers running concurrently; however, when I add the forth, each timer's signal handler will no longer run.
>
> When you create each timer, you have to provide a struct sigevent containing the signal number that you use. What signal numbers are you using for the your timers. Are they all unique? Only one signal action can be associated with a signal.
>
> Notice in include/signal.h that some of the signal numbers (2-4) are used for other things.
>
> You can, of course, use one signal handler for all of the events and just pick of the signal number to determine what timer expired.
>
> Greg
>

__._,_.___
Recent Activity:
.

__,_._,___

Gmane