Re: OEMGetRealTime and SoftRTC flag



I'd guess that this is, in fact, what's going on (delayed processing of
tick).

Alex, it's asking too much that there will be some default settings for
every processor and every instruction set that will happen to match what
you're doing, especially given that almost no one uses SoftRTC. Every
processor of every type works differently as far as what has what priority,
whether priorities rotate, etc. It's your job, as the BSP developer, to get
it right for your use of the processor.

Paul T.

"Bruce Eitman [eMVP]" <bruce.eitman.nospam@xxxxxxxxxxxxxxxxxxx> wrote in
message news:%23H4XicfwJHA.1304@xxxxxxxxxxxxxxxxxxxxxxx
You could be correct about the interrupt priorities, but you should check
them and trust that someone else with different requirements wrote the
code to suit your needs.

Don't rule out that the tick count ISR is held off due to processing of an
already running ISR. In this case, the ISR should take into account that
it may have been longer than one millisecond since the last tick
interrupt.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

<alexquisi@xxxxxxxxxxxx> wrote in message
news:7746bdb8-d2b1-4329-87ed-04c0a11bb22d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Paul,

well, I am not sure if I understood you. Of course, if the tables are
there one has the choice to modify them but I would expect a default
"logical" setting, where the Count interrupt source (used normally as
tick source) had the highest priority which seems no to be the case.

Note that I am referring to priorities to handle nested interrupts at
the ISR level, not the priorities assigned to the peripherals via the
ISTs.

Thanks,

Alex



On Apr 20, 9:32 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Setting interrupt priorities is YOUR job, not that of the OS. The OAL
code
decides what "priority" various things have (OEMInterruptEnable,
certainly,
but also how your code in OEMInterruptHandler or whatever, works).

Paul T.

<alexqu...@xxxxxxxxxxxx> wrote in message

news:1577739e-41ff-4b3a-ad40-9d0b82c0e5f7@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi Bruce,

thanks for your reply.

In the meantime I found that the thread calling OEMGetRealTime
(indirectly) every 500 ms was the battery driver. I always thought
that it was Explorer.exe, to update the clock in the lower right
corner.

Anyway, my system is having a strange behavior. When the system runs
without much activity, it looses about 1 second per hour, which I
consider acceptable and expected.

The problem is, when a put under stress the system (video playback, a
couple of application running, etc), it looses about 12 seconds per
hour and it get worse if the activity is higher.

As the system clock depends on the Timer interrupt, which I would
expect that runs at the highest priority, it seems to me that
something does not work as it should.

Toggling a GPIO in the Timer ISR, I could see that, without load, it
is called every 1 ms, but when I put the system under stress, it
fluctuates up to 1.1 ms. (10%)

As I have a MIPS-based system, the priorities are defined in a couple
of arrays:

http://msdn.microsoft.com/en-us/library/ms904428.aspx

I am using all this part of the code for my BSP directly from PB. No
custom changes.

So, I'm wondering if there is a bug in MS code when handling the
priorities of the ISRs for MIPS processors.

Thanks for your feedback,

Alex




.