SYS/BIOS & HWI

Thanks.

I know how to deal with with everything in the non-BIOS world, but too much of the SYS/BIOS seems undocumented.

I see nothing in the SYS/BIOS configuration or documentation dealing with, for example, timer interrupts.

I know that SYS/BIOS uses a timer and a hardware interrupt to schedule tasks.

I see where to select a Timer ID for the system clock in ti.sysbios.knl.Clock.timerId, but I do not see where the hardware interrupt is assigned.  We cannot lay out my system design and interrupt mapping scheme without knowing what resources the BIOS is using.

The SYS/BIOS documentation (spruex3g) says for the Timer Module (section 4.3, page 120) to use the documentation in the HAL area (section 6.3).

Sectino 6.3, paragraph 2, says to use this module only if you do not need to do any custom configruation of the timer peripheral.

The note at the start of Section 6.1 says that you have to use the SYS/BIOS HAL Api's when dealing with interrupts, timers, etc.

On the OMAP-L138, C6748, C6746 I have 4 64-bit timers, each of which can be used as two 32-bit timers.

I cannot change any of the settings in the graphical configuration editor under ti.sysbios.timers.timer64.Timer; when I look at them I see that timers 0 and 1 are Mode_UNCHAINED and timers 2&3 are Mode_CHAINED.  A test program which calls Timer_getNumTimers () reports that I have 8 timers; but only timers 1-3 are available; timer 0 is in use (expected, that is what I set for the system clock), and timers 4-7 are also reported as In use.

When I right click on this and select "New Timer", I get an error "Timer device unavailable".

In general we allocate and configure our hardware resources (timers, hwi's, swi's, tasks, etc.) in code rather that in the BIOS configuration file

Peter,

For OMAPL138, The default Hwi vector for Timer0 Low half is 14. Timer0 High half is 4.  Timer1 Low half is 15.  Timer1 high half is 5.  Timer2 low and high is 6.  Timer3 low and high is 7.  If you are creating your own timer its easy to change the default Hwi vector by changing the params.intNum field.  If you are trying to change the Clock's Timer interrupt that requires more work.  Something like the following:

        var Clock = xdc.useModule('ti.sysbios.knl.Clock");
        Clock.tickSource = Clock.TickSource_TIMER;            // this overrides the default Timer settings for the Clock module
        var Timer = xdc.useModule('ti.sysbios.hal.Timer');
        var timerParams = new Timer.Params();
        timerParams.runMode = Timer.RunMode_CONTINUOUS;
        timerParams.startMode = Timer.StartMode_AUTO;
        timerParams.period = Clock.tickPeriod;
        timerParams.periodType = Timer.PeriodType_MICROSECS;
        timerParams.intNum = 10;   // specify your int vector number here
        Timer.create(Clock.timerId, Clock.doTick, timerParams);

 In general, use the ti/sysbios/hal API's if you can.  Those will be the same across different targets/devices/platforms.  If your writing this code for a single device or family of devices (like c64xx) then you can use the specific delegates like for Timer (ti.sysbios.timers.timer64.Timer).

BIOS considers each 32-bit Timer half as a separate Timer...thus the 4 64-bit timers gives you 8 32-bit Timers.  Timer2 and Timer3 on the OMAPL138 is a special case:

                /*
                 *  For Timer2 and Timer3 of OMAPL138 and similar parts
                 *  there is only 1 event Id associated with both halves
                 *  of the timer, therefore set them to 64bit mode
                 */

Judah

Thanks.

I'm OK with the clock having it's own interrupt number as long as I know what it is.

How would I create a timer that does not configure the HWI?

i.e., I want it to generate the timer event but have it handled by the event combiner and my specific interrupt handler.

Is there a supported way to enable or disable the event generation by a timer?  I do not necessarily want to globally enable or disable the HWI  when I start or stop a timer, just enable or disable that specific timers event.

Peter

Peter,

You can create the Timer without specifying the 'tickFxn'.  It will not plug a Hwi in this case.

When you say "enable or disable the event generation by a timer", at whch level do you mean?  There's Hwi_enableIER/Hwi_disableIER which allows you to enable/disable an interrupt line (IER register).  There's also EventCombiner_enableEvent/EventCombiner_disableEvent which allow you to mask a particular event from being combined.

Does that answer your question?

Judah

If I create a timer without specifying the tickFxn does the timer peripheral still generate the Event?  When I create a timer instance through SYS/BIOS I do not have easy access to the chip registers to enable or disable the timer event.

The "enable or disable the event"  refers to the bits in the INTCTLSTAT register in the timer peripheral, i.e. for TIMER2 on a c6748 it is event T64P2_TINTALL, or event # 25.

I know about the Hwi & EventCombiner functions; I"m trying to determine how to match up the hardware description in the peripherals manuals (i.e., SPRUFM5C)  with the SYS/BIOS.

I cannot find any specifics in the SYS/BIOS documentation.

I'm trying to use the peripherals in the supported fashion with SYS/BIOS.

If necessary (and it won't break anything I need in SYS/BIOS) I can just use the SYS/BIOS to create and dispatch the HWI's and configure the various peripherals through the PSP/CSL registers if the SYS/BIOS does not support the functionality I want in the peripherals

Peter

Peter,

SYSBIOS does not have APIs that support the Timer at that level.  It only supports general functions like setPeriod, start, stop, etc...

Judah

So what is the supported way to use the various timers in a SYS/BIOS application?

Just dedicate one timer and it's interrupt as the BIOS clock and do my own configuration of the other timers via the hardware registers?

if I dedicate one timer as the BIOS clock, say Timer 0, does it just use the TIMER12 half leaving TIMER34 available to me, or should I just let it have both halves.

Peter

Thanks.

We're trying to be SYS/BIOS friendly as we migrate our apps to the new chips & BIOS.

Peter