Using a Timer as a timestamp

Judah,

Thank you for your answer.

I don't see the utility of the "prescalar" field but it doesn't really matter anyway.

a) With the config you suggested (no tick, period 0xFFFFFFFF, ...) does it mean that the Timer runs at CPU frequency ?

b) About adding new functions.
1)Do you mean hacking TI's source code directly (adding the functions to timer64.c and somehow rebuilt sysbios with it) ?
or 2)do you mean writing our own Timer module (a real RTSC module) based on timer64 (it would 90% the same)
or 3)there is a way to write a classic function that'd get an handle to the timer object and access its tickcount.

I'd look into 3) first but I'm not sure it's possible.

Clement

Judah,

I had completely forgotten the Timer64 user guide (http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf).
It's a great help.

A - From the excerpt below, it seems like I have to first stop the timer before writing to CNTLO/CNTHI.

Writing to Registers of an Active Timer 

Writes from the configuration bus to the timer registers are not allowed when the timer
is active, except for stopping or resetting the timers. In the 64-bit and dual 32-bit timer
modes, registers that are protected by hardware include CNTLO, CNTHI, PRDLO, PRDHI, TGCR (except the TIMLORS and TIMHIRS bits), and TCR (except the ENAMODE bits). 

 Ok for the Timer address in Timer.xs, it'll work fine for the workaround.

B- I'm still looking for a more portable solution. Basically I would need to be able to do :
(TimerRegs *)Timer_module->device[obj->id].baseAddr)->cnt from outside the module.

C- In your first post you said "32-bit chained", I understand why you said 'chained' over 'unchained'.
Why not 64-bit mode ? any particular reason ? As we plan to use it as a timestamp for the Log module, 64-bit would be a natural fit.

D- For C6678 it is very unclear in cdoc which module I should use :
ti.sysbios.timers.timer64.Timer (I think I should use this one)
or ti.sysbios.family.c64.Timer

E- It seems like ti.sysbios.family.c64.Timer doesn't have the choice of the mode (chained-unchained-64bit) compared to ti.sysbios.timers.timer64.Timer.

Thank you for your time,

Clement

Clement,

Maybe have your own table since the mapping is always fixed?

Timer64 doesn't support 64-bit mode...that's the only reason why I suggest 32-bit chained.  If you use the Timer outside SYSBIOS, yes I would use 64-bit mode.

You should use timers.timer64.Timer.  The other one is for old c64 chips.

Judah

Judah,

Ok the fixed address thing is fine (we discussed it internally).

I'm a bit surprised about the 64-bit timer that cannot be used as a 64-bit timer with SYS/BIOS.

Nothing personnal towards you but what's the reason behind this limitation ?

Clement

Clement,

Its been years ago so I don't recall all the logistics of why 64bit more was not supported but I can give some reasons.

1.  32-bit unchained and 64-bit mode are in a way very similar.  The major difference being 32-bit unchained supports interrupts so from our perspectives its easier to support just one of those modes.

2.  Timer64 from BIOS perspective is for supporting an interrupt driven timer.  There is already a BIOS COUNTER (TSCL/TSCH) for supporting a counter so having 64-bit mode is sort of duplication.  Also TSCL/TSCH runs a cpu freq while the 64-bit timer runs at cpu/6.

Anyways, its been like this from the beginning and we've only had a couple of people asking about 64bit mode but I don't think it will be added since that will require a huge revamp of the code.

Judah

Judah,

Ok got it, I understand the reasons.

We reached our contacts at TI, we'll see what they say about it.

For now, I'll mark the thread as closed/verified.
Maybe we'll consider other solutions than this one.

Thanks for your help,

Clement