You are not logged in.
I would like to implement a query functionality by broadcasting conitinuously hello messages to detect nodes in range. Therefore I need a second timer to send these packets, let's say every 500ms.
There are 4 independent warp_timers I think. Can I use one of these for this purpose or is it neccessary to implement a new timer core. The adaption shouldn't be a problem. I just would like to know if it makes sense to use one of these timers for this purpose. The warp_timers are specified as independent. What does this exactly mean? What happens if two timers expire at the same time? Could this lead to a problem?
When the timer expires the timer_int_handler() is called. This handler then calls the user function. At this moment, only one timer is used and only one user function exists. If I use the second timer, I need to know which timer caused the interrupt and call the corresponding user function. How can I retrieve the timer that caused the interrupt?
Thanks,
Last edited by domenique (2009-Jan-19 13:15:34)
Offline
You can definitely use one of the four timers in the warp_timer core. Two are used by default in the OFDM reference design- one for timeouts, the other for backoffs. You'll need to use the timer control functions in warpphy.c to exercise the third and fourth timers. Every timer expiry calls the same interrupt service routine (timer_int_handler). The handler already checks to see whether a TIMEOUT or BACKOFF timer expired; you can extend this to check for your custom timer.
Offline
This is how I understand it:
The function warpmac_startTimer allways starts timer nr 0 (warpmac_startTimer(0)). BACKOFF and TIMEOUT are only two different types of this timer with different timer values. BACKOFF and TIMEOUT cannot be set at the same time, because it is the same timer (0). But there are 4 different timers in total.
I would like to use let's say timer nr 1. But the function timer_int_handler() is only designed for one timer. There is no query, which timer caused the interrupt. There is only a query which type (BACKOFF or TIMEOUT) is running, assuming that only one timer is used.
Adding an other type won't be sufficient, since the types cannot be active simultaneously.
Offline
I had a closer look at the timer core. There are actually 4 different timers designed.
There are two functions which should return which timer caused the interrupt: warp_timer_getStatuses() and warp_timer_getInterrupts(). But I'm not sure how to use the value returned by these functions.
Offline
warp_timer_getStatuses() returns the value of the timer_status register from the warp_timer core. This register contains a 12-bit value, consisting of four 3-bit status values (one per timer) for the timer statuses: [interrupt active paused].
warp_timer_getInterrupts() reads the same register but extracts just the interrupt bits.
See warpphy.c for the source of each function.
Offline
Thank you.
Looking at the source of the functions it seems that the register XPAR_WARP_TIMER_PLBW_0_MEMMAP_TIMER_STATUS is a 32 bit register with the following layout in bits ( i = interrupt, a = active, p= paused => 2a = active status of timer 2) :
0000 0 3p 3a 3i | 0000 0 2p 2a 2i | 0000 0 1p 1a 1i | 0000 0 0p 0a 0i
The functions warp_timer_getStatus(timer), warp_timer_isExpired(timer), warp_timer_isActive(timer), warp_timer_isPaused(timer) and warp_timer_getInterrupts() seem to consider this layout.
But the function warp_timer_getStatuses() that should return the whole register content seems not to consider this structure. It returns an unsigned int ( = 2Bytes) instead of an unsigned long (= 4Bytes). Therefore I think it does not return the right value.
What do you think?
Offline
In XPS, the int type is 32-bits (at least in the current version of GCC for the PPC405; it's been this way for as long as we've used the EDK).
Offline