Is this a bug or a feature in mktime?

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Is this a bug or a feature in mktime?

Dave-11
Hi everyone,
   I'm not sure if this is a bug or a feature. I've been playing around
with the mktime function, and I noticed that if set the date to a time
of the year, so that it is opposite of how tm_isdst is currently set,
then my time will be ahead or behind by one hour.

   For example, if the tm_isdst flag is clear, and I enter todays date
with a time of 6:00, it will set the tm_isdst flag, and put my time at
7:00. If the tm_isdst flag is set, and I set the date to December and
the time to 6:00, then it will clear the tm_isdst flag, and set the time
to 5:00.

   Is it supposed to work this way? In my eyes it is a bug, but that may
be the way it is supposed to work. I'm sure I can 'fix' it, but I don't
want to break something else if it is supposed to work this way. Can
someone let me know before I try to fix something that may not be
broken?

-Dave

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Is this a bug or a feature in mktime?

Dave-11
On Thu, 2005-06-09 at 06:51 -0400, Dave wrote:

> Hi everyone,
>    I'm not sure if this is a bug or a feature. I've been playing around
> with the mktime function, and I noticed that if set the date to a time
> of the year, so that it is opposite of how tm_isdst is currently set,
> then my time will be ahead or behind by one hour.
>
>    For example, if the tm_isdst flag is clear, and I enter todays date
> with a time of 6:00, it will set the tm_isdst flag, and put my time at
> 7:00. If the tm_isdst flag is set, and I set the date to December and
> the time to 6:00, then it will clear the tm_isdst flag, and set the time
> to 5:00.
>
>    Is it supposed to work this way? In my eyes it is a bug, but that may
> be the way it is supposed to work. I'm sure I can 'fix' it, but I don't
> want to break something else if it is supposed to work this way. Can
> someone let me know before I try to fix something that may not be
> broken?
>
> -Dave


I got it figured out. It is not documented 100% in the Nut/OS docs, but
it appears that it is supposed to work this way, and if I simply set the
tm_isdst flag to -1 it will automagically set the tm_isdst flag for me,
and set the time as expected.

-Dave

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Is this a bug or a feature in mktime?

Harald Kipp
In reply to this post by Dave-11
Dave,

according to ChangeLog, Oliver Schulz contributed this part.
He is quite busy in his job and may not respond immediately.

I'm assuming, you are much deeper in this topic than me. So
I won't mind any modification as long as SNTP provides
my correct local time. But I guess that your suggested fix
won't have any impact on SNTP and localtime() anyway, will it?

Unless no one else shouts "Stop!", go ahead.

Harald

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Is this a bug or a feature in mktime?

Harald Kipp
In reply to this post by Dave-11
Whatever there may be stated in the Nut/OS docs, I'd vote for
compatibility with Unix man pages, which follow ISO C and Posix.

Harald


>I got it figured out. It is not documented 100% in the Nut/OS docs, but
>it appears that it is supposed to work this way, and if I simply set the
>tm_isdst flag to -1 it will automagically set the tm_isdst flag for me,
>and set the time as expected.
>
>-Dave

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Low level timer functions

Harald Kipp
Hi,

I'll start cleaning up all that crap, which had been
collected over the time in os/time.c and related
files.

If anybody else is working on this, please let me know.

Harald

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Is this a bug or a feature in mktime?

Dave-11
In reply to this post by Harald Kipp
On Thu, 2005-06-09 at 13:29 +0200, Harald Kipp wrote:
> Whatever there may be stated in the Nut/OS docs, I'd vote for
> compatibility with Unix man pages, which follow ISO C and Posix.
>
> Harald

Hi Harald,
   I agree with you 100% on that. I keep forgetting to check other
source of documentation since so much in Nut/OS is based on standard
unix functions. I keep finding little things missing, like this, all
over the documentation, which is annoying since it slows me down at what
I'm doing. I guess I should start fixing the docs where I see something
is wrong or missing like this.

-Dave

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Low level timer functions

Ole Reinhardt
In reply to this post by Harald Kipp
Hi Harald,

> I'll start cleaning up all that crap, which had been
> collected over the time in os/time.c and related
> files.
>
> If anybody else is working on this, please let me know.

No, I'm not working on it, but I have a little request for features.

Could you perhaps add some function for the not yet used Timers? Some
kind of API for Timer settings, Counter, PWM and so on? This would be
realy cool!

Bye,

Ole

PS: The las days I was thinking about my ideas for a new driver model.
I'll write this together tonight or tomorrow and let you know.


--
kernel concepts    Tel: +49-271-771091-14
Dreisbachstr. 24   Fax: +49-271-771091-19
D-57250 Netphen    E+ : +49-177-7420433
--


_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

AW: Is this a bug or a feature in mktime?

Oliver Schulz
In reply to this post by Dave-11
Hi Dave,

This behaviour is indeed by intention. If you call mktime, then the time
stored in the parameter timeptr is first adjusted to contain a valid time
information.
That means, if you provide for example 6am on June 9th with tm_isdst flag
set to zero (which means no DST time), then the time is corrected to 7am
because the 9.6.05 is a date within daylight saving. The same for a date in
december with tm_isdst set to positive value.

And you are right, following the ANSI C definitions you can switch of this
DST correction by setting the tm_isdst member of timeptr to a negative
value, but the tm_isdst is set to the correct value according to the date in
timeptr.

Cheers,
Oliver.
 

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von Dave
Gesendet: Donnerstag, 9. Juni 2005 13:07
An: Ethernut User Chat (English)
Betreff: Re: [En-Nut-Discussion] Is this a bug or a feature in mktime?

On Thu, 2005-06-09 at 06:51 -0400, Dave wrote:

> Hi everyone,
>    I'm not sure if this is a bug or a feature. I've been playing
> around with the mktime function, and I noticed that if set the date to
> a time of the year, so that it is opposite of how tm_isdst is
> currently set, then my time will be ahead or behind by one hour.
>
>    For example, if the tm_isdst flag is clear, and I enter todays date
> with a time of 6:00, it will set the tm_isdst flag, and put my time at
> 7:00. If the tm_isdst flag is set, and I set the date to December and
> the time to 6:00, then it will clear the tm_isdst flag, and set the
> time to 5:00.
>
>    Is it supposed to work this way? In my eyes it is a bug, but that
> may be the way it is supposed to work. I'm sure I can 'fix' it, but I
> don't want to break something else if it is supposed to work this way.
> Can someone let me know before I try to fix something that may not be
> broken?
>
> -Dave


I got it figured out. It is not documented 100% in the Nut/OS docs, but it
appears that it is supposed to work this way, and if I simply set the
tm_isdst flag to -1 it will automagically set the tm_isdst flag for me, and
set the time as expected.

-Dave

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Low level timer functions

Harald Kipp
In reply to this post by Ole Reinhardt
Hi Ole,

How do we say in Germany? "Offer him a little finger and he will
pull off your arm." :-)

My problem with additional timer/counter functions is, that
it seems to be no easy solution for a hardware independent
layer. But I'd agree that even some AVR specific functions
will be helpful.

In the meantime I think I have a nice solution for the
crystal frequency detection, which no longer depends on
wait states of external RAM. 'counter' is an u_long and
just needs to be multiplied by 128 the get the frequency
in Hz.

Harald

     /* Disable timer 0 interrupts. */
     cbi(TIMSK, TOIE0);
     cbi(TIMSK, OCIE0);

     /* Select oscillator 1 (32.768 kHz). */
     sbi(ASSR, AS0);

     /* Reset counter register. */
     outb(TCNT0, 0);

     /* Set prescaler to 8. Overflow will occur every 62.5 ms. */
     outb(TCCR0, _BV(CS01));

     /* Wait for asynchronous busy clear. */
     while ((inb(ASSR) & (_BV(TCN0UB) | _BV(OCR0UB) | _BV(TCR0UB))) != 0);

     /* Clear interrupt flags. */
     outb(TIFR, _BV(OCF0) | _BV(TOV0));

     counter = 1;
     NutEnterCritical();
     __asm__ __volatile__("firstovf:              \n\t"
                          "in %D0,%1              \n\t"
                          "andi %D0,1             \n\t"
                          "breq firstovf          \n\t"
                          "out %1,%D0             \n\n"
                          /* This loop has 8 cycles. */
                          "nextovf:               \n\t"
                          "sec                    \n\t"
                          "adc %A0,__zero_reg__   \n\t"
                          "adc %B0,__zero_reg__   \n\t"
                          "adc %C0,__zero_reg__   \n\t"
                          "in %D0,%1              \n\t"
                          "andi %D0,1             \n\t"
                          "breq nextovf           \n\t"
                          "clr %D0                    "
                          :"=d"(counter) /* Output */
                          :"I"(_SFR_IO_ADDR(TIFR)), "0"(counter) /* Input */
         );
     NutExitCritical();

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Low level timer functions

Ole Reinhardt
Hi Harald,

> How do we say in Germany? "Offer him a little finger and he will
> pull off your arm." :-)

Right. I'm realy used to do so :-)

> My problem with additional timer/counter functions is, that
> it seems to be no easy solution for a hardware independent
> layer. But I'd agree that even some AVR specific functions
> will be helpful.

Yes, there won't be a real hardware independend solution, but we could
create an API for let's say the minimum common set of operating modes.
Will say, some simple timer / counter nearly every MCU has. So we could
create an api where we could ask the features of the current hardware
and then register one / two or more timers. But you'r right, this will
be hard to implement.

On the other hand hardwarespecific implementations for every plattform
would be ok to. One could try to design the api as commom as possible.

> In the meantime I think I have a nice solution for the
> crystal frequency detection, which no longer depends on
> wait states of external RAM. 'counter' is an u_long and
> just needs to be multiplied by 128 the get the frequency
> in Hz.

This one looks quite nice.

If you'r just working on the timers. I have not realy understood, why
the minimum timer resolution of the current NutOS is 62.5 ms. Could'nt
this be speeded up? Do we need the external crystal to clock timer 0 or
woul'nt it be ok to only calculate the crystal frequency and let our
clock run with only internal clocked timer0. Or even: Could'nt we run
the system timer on timer1 for example to gain a more fine granular
timer? I just was in need of shorter timeouts for several times.

Bye,

Ole

--
kernel concepts    Tel: +49-271-771091-14
Dreisbachstr. 24   Fax: +49-271-771091-19
D-57250 Netphen    E+ : +49-177-7420433
--


_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Low level timer functions

Vesa Jääskeläinen
Ole Reinhardt wrote:
> If you'r just working on the timers. I have not realy understood, why
> the minimum timer resolution of the current NutOS is 62.5 ms. Could'nt
> this be speeded up? Do we need the external crystal to clock timer 0 or
> woul'nt it be ok to only calculate the crystal frequency and let our
> clock run with only internal clocked timer0. Or even: Could'nt we run
> the system timer on timer1 for example to gain a more fine granular
> timer? I just was in need of shorter timeouts for several times.

I don't exactly know where in the code depends on 62.5ms, but I would
also like to this be configurable. I have one project where it would be
a good idea to have /2 for it, but I didn't try to modify it back then
as I wasn't sure what would be broken by changing it.

Does anyone know are there any code pieces in Nut/OS depending on this
one?...

Thanks,
Vesa J??skel?inen
_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Low level timer functions

Harald Kipp
Vesa,

as long as the main crystal is used, 1 ms is the standard setting.
With the 32 kHz clock crystal, there are not so many option.
0.9765625 ms (32 cycles) seems to be a good choice. I'm not
sure at the moment, how to make it generally configurable.

For timeouts (NutEventWait), the deviation is not critical.
The calculation of the number of seconds since system start
should be as accurate as possible, though. The above value is
exactly 1/1024 seconds, which is fine for date/time calculations.

High timer resolution is nice for some applications, but bad
for general system performance. Furthermore, the ATmega is
able to wake up from a special low power sleep mode (main
crystal osc. switched off). Waking up the chip too often
will consume more energy. Initially Nut/OS had been running
on a 3.6864 MHz ATmega103 and 62.5 ms was OK for the timer.
IMHO, we can change the default to about 1 ms now.

If higher resolution are required, the application should
not use the system timer.

I want to remove all these counters from the interrupt routine.
Just one plain tick counter should be kept. All other routines
could do there own calculations based on this counter. The
goal is to reduce the interrupt processing to a bare minimum.

Harald

At 16:33 10.06.2005 +0300, you wrote:

>I don't exactly know where in the code depends on 62.5ms, but I would also
>like to this be configurable. I have one project where it would be a good
>idea to have /2 for it, but I didn't try to modify it back then as I
>wasn't sure what would be broken by changing it.
>
>Does anyone know are there any code pieces in Nut/OS depending on this one?...

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Low level timer functions

Matthias Ringwald

On 10.06.2005, at 16:09, Harald Kipp wrote:

> I want to remove all these counters from the interrupt routine.
> Just one plain tick counter should be kept. All other routines
> could do there own calculations based on this counter. The
> goal is to reduce the interrupt processing to a bare minimum.
>

Hi Harald,
  good, you didn't forget about the Timer IRQ issue..
I might help out here, as we're still far away from what we need to
get reasonable Bluetooth communication rates. If helpful, we can
discuss issues on the phone.

Matthias


_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

RFC - Redesigning Timer Interrupt Processing

Harald Kipp
In reply to this post by Harald Kipp
Hi all,

This is based on a long phone call I had with Matthias Ringwald
a few months ago and on several emails with him and other people.

The current situation (Nut/OS 3.9.7):
-------------------------------------

The timer interrupt routine processes the nutTimerList, a linked
list of NUTTIMERINFO structures. This list is sorted by
the time at which the timers will elapse, with the shortest
time on top. Let's assume we have three timers, two of them
will elapse after 5 ticks, the third after 7 ticks. Then
the list will contain:

Timer-1: 5 Ticks
Timer-2: 0 Ticks
Timer-3: 2 Ticks

As we can see, each timer is entered with the remaining
period, the number of ticks left after all timers, which
are in front, will have been elapsed.

This way, only the top entry needs to be decremented.
If its counter value reaches zero, it is removed from the
list. If the next entry is zero too, it will also be removed...
and so on. This removal is non-deterministic, as it depends
on the number of timers, which will elapse at the same time.

The removal itself is even worse. Each timer is associated
to a callback function, which is called during removal.
For example, if an application directly or indirectly calls
NutEventWait() with a time out value, then a new entry is
added to the timer list with NutEventTimeout() as the callback.
The processing of this function depends on the number of
threads and the priority of the thread, which called
NutEventWait(). Furthermore, the application can provide its
own callback, in which case the required processing is out of
control for Nut/OS.

So far we looked to one-shot timers. Periodic timers are
re-inserted after they elapsed. Re-inserting timers is,
you guessed it, non-deterministic regarding processing time.

And all this happens in interrupt context, blocking any other
interrupt.

Finally, NUTTIMERINFO structures are allocated from heap. Thus,
the interrupt routine is not allowed to free it. Instead,
one-shot timers are added to a second list, named nutTimerPool.
These structures will be re-used, when a new timer is created.

Bored? OK, let's turn to the interesting stuff.


Proposal for new timer handling:
--------------------------------

Instead of removing all elapsed timers, only the first one will be
removed. If all timers in the list with equal life periods are
sorted by priority, this is just fine. However, the NUTTIMERINFO
doesn't contain the priority of the thread.

When a timer elapses, one has to walk to the list of threads to
find the one that is currently associated to this timer.

Adding a pointer to the NUTTHREADINFO structure will help in both
function.

Instead of calling the callback and instead of re-inserting periodic
timers, the NUTTIMERINFO structure will be removed from the list
and added to nutTimerPool only. Because of cooperative multithreading,
all other required processing can be delayed until the currently
active thread is willing to give up the CPU. This way, all
non-deterministic functions are moved away from interrupt context
to NutThreadResume().

The final timer interrupt routine will look like

static void NutTimerIntr(void *arg)
{
     nut_ticks++;
     if (nutTimerList) {
         if (nutTimerList->tn_ticks_left) {
             nutTimerList->tn_ticks_left--;
         }
         if (nutTimerList->tn_ticks_left == 0) {
             NUTTIMERINFO *tnp = nutTimerList;
             nutTimerList = nutTimerList->tn_next;
             tnp->tn_next = nutTimerPool;
             nutTimerPool = tnp;
         }
     }
}

Note too, that just one tick counter is used (see my previous
post). Now it is possible to simply calculate the worst case
processing time of the timer interrupt handler.

Now the bad part. Since its first release, Nut/OS provides
NutTimerStart() and offers the capability to specify custom
callback functions. For example, os/msg.c uses this and it can
be assumed, that several applications are using it. Removing
the callback from interrupt processing may break these applications.

One option may be to make this a configurable preprocessor macro
and optionally compile Nut/OS with or without callbacks in interrupt
context. I'd like to avoid this. It adds complexity to release
testing.

Another option is, to create a completely new set of functions
for exclusive use by the kernel. In this case the old NutTimerStart()
may set an additional flag in NUTTIMERINFO, which the new one,
e.g. NutSysTimerStart() won't. For all flagged timers, interrupt
processing is passed to the old (slightly modified) interrupt
handler. This way deterministic interrupt handling is maintained
for applications, which do not call NutTimerStart() themselves.

May be it is even possible to enhance the old style timer routines
towards a more general timer API, like Ole suggested.

That's it for today,
Harald




_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Low level timer functions

Harald Kipp
In reply to this post by Matthias Ringwald
Matthias,

How can I forget this? Hope my Timer Re-design RFC provides,
what you expected.

;-)
Harald

At 18:37 10.06.2005 +0200, you wrote:

>Hi Harald,
>  good, you didn't forget about the Timer IRQ issue..
>I might help out here, as we're still far away from what we need to
>get reasonable Bluetooth communication rates. If helpful, we can
>discuss issues on the phone.
>
>Matthias

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: RFC - Redesigning Timer Interrupt Processing

Matthias Ringwald
In reply to this post by Harald Kipp
Hi Harald,

thanks for showing your ideas.
I really like your new NutTimerIntr handler. Its short enough. :)
Processing only one Timer is a good idea.

Some thoughts I had on compatibility. I was wondering, what would change
to older apps. What could an application expect if it is using  
NutTimerStart?
Because of the rough granularity (62.5ms) of the system timer is  
quite inaccurate.
If there are no threads which computation takes ages, the timer  
callback is still
called on time. To me, the only problematic case would be an app that  
uses a
timer to signal a running thread  which does endless processsing by  
writing
to a global variable. then, because there are no thread switches,
the callback is not called and the thread never gets the important  
signal.

BUT.. I guess this is quite pathologic, and I prefer cutting old knots (
at least there's a saying in german.. "alte Zöpfe abschneiden.." :)
and try to help convince people that this is the right way to go on.

Are there people, who really need callbacks from IRQ context with
low resolution ? For specific stuff, like high-accurate dealing
with external hardware, I guess using one of the other timers
and writing an IRQ handler should be better anyway.

Matthias

P.S. I will continue hunting long CriticalSections..

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: RFC - Redesigning Timer Interrupt Processing

Harald Kipp
At 20:55 10.06.2005 +0200, Matthias Ringwald wrote:

>Because of the rough granularity (62.5ms) of the system timer is
>quite inaccurate.

If NUT_CPU_FREQ is defined, the granularity is 1 ms.

For short periodic tasks a timer callback is much less
overhead compared to a thread with NutSleep().

Ole stated, that there is a need for a timer/counter API.
After reading all this complex AVR timer handling in the
data sheet again, I can confirm, that such an API would
be helpful. If this API could be "married" with the old
calls...

/* Our beloved grandpa, using the system timer. */
/* Warning! This may turn our fine RTOS to a lousy OS. */
NutTimerStart(...);

/* Brand new, using a selectable timer. */
NutExtraTimerStart(tc, ...);

...nothing needs to be changed outside the kernel.
And it will add just one tiny if() to the new handler.
At least this is what I expect, but "Der Teufel steckt
im Detail".

If it fails, no problem. Version jump 3 to 4 allows
some kind of incompatibility. Which reminds me, that
I should add a CVS branch before moving on. As far as
I can say, the current CVS HEAD looks rock solid.

Harald

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

AW: RFC - Redesigning Timer Interrupt Processing

ernstst
Hi Harald!

In my opinion, a new set of API calls is the best solution because it
- provides good separation of "old" and "new"
- minimizes the risk of breaking existing code (i.e. apps)
- allows a clean implementation of the new API ...
- whose inner woking might be changing in future ....

regards
ernst

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] Im Auftrag von Harald Kipp
Gesendet: Freitag, 10. Juni 2005 21:27
An: Ethernut User Chat (English)
Betreff: Re: [En-Nut-Discussion] RFC - Redesigning Timer Interrupt
Processing

At 20:55 10.06.2005 +0200, Matthias Ringwald wrote:

>Because of the rough granularity (62.5ms) of the system timer is quite
>inaccurate.

If NUT_CPU_FREQ is defined, the granularity is 1 ms.

For short periodic tasks a timer callback is much less overhead compared to
a thread with NutSleep().

Ole stated, that there is a need for a timer/counter API.
After reading all this complex AVR timer handling in the data sheet again, I
can confirm, that such an API would be helpful. If this API could be
"married" with the old calls...

/* Our beloved grandpa, using the system timer. */
/* Warning! This may turn our fine RTOS to a lousy OS. */
NutTimerStart(...);

/* Brand new, using a selectable timer. */ NutExtraTimerStart(tc, ...);

...nothing needs to be changed outside the kernel.
And it will add just one tiny if() to the new handler.
At least this is what I expect, but "Der Teufel steckt im Detail".

If it fails, no problem. Version jump 3 to 4 allows some kind of
incompatibility. Which reminds me, that I should add a CVS branch before
moving on. As far as I can say, the current CVS HEAD looks rock solid.

Harald

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion



_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: AW: RFC - Redesigning Timer Interrupt Processing

Harald Kipp
Hello Ernst,

In general I agree. The trouble with timers is, that you can
have one interrupt only, which then has to serve both versions.

In detail things are becoming more and more complicated here and
I'm becoming more and more desperate. Possibly I'll reduce the
task to a minor step first, which will at least clean up all the
copy&paste code fragments.

Harald

At 20:02 11.06.2005 +0200, you wrote:

>Hi Harald!
>
>In my opinion, a new set of API calls is the best solution because it
>- provides good separation of "old" and "new"
>- minimizes the risk of breaking existing code (i.e. apps)
>- allows a clean implementation of the new API ...
>- whose inner woking might be changing in future ....
>
>regards
>ernst

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: RFC - Redesigning Timer Interrupt Processing

Ole Reinhardt
In reply to this post by Matthias Ringwald
Hi Matthias, Harald and all theee others...

> Because of the rough granularity (62.5ms) of the system timer is  quite
> inaccurate.

I need a high accuracy of the system timer in some applications. That's
why I mostly don't have an external crystal and define NUT_CPU_FREQ in
the makefiles. This way I gain a timer resolution of 1ms.

I now have some applications where the accuracy need to be 1 to 2 ms or
even better. With the currect approach this works quite fine. If we
remove the ability of NutTimerStart completely or move it out of the
interrupt context I'd need to define my own timer API. Ok, I'd do so if
we could make NutOS faster with this approach. I'd like to have some
kind of timer api where one could define one or more timer that call a
custom callback. But that's what we just thought about some days ago, right?

Bye,

Ole

--
kernel concepts    Tel: +49-271-771091-14
Dreisbachstr. 24   Fax: +49-271-771091-19
D-57250 Netphen    E+ : +49-177-7420433
--

_______________________________________________
En-Nut-Discussion mailing list
[hidden email]
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
12