From: "Paul D. DeRocco" <pderocco@ix.netcom.com>
To: "eCos Discuss" <ecos-discuss@ecos.sourceware.org>
Subject: RE: [ECOS] Re: In trouble of timer operations
Date: Thu, 05 Jun 2008 17:39:00 -0000 [thread overview]
Message-ID: <PGEAIGBPLOMOJDAPCOJHIEELLAAB.pderocco@ix.netcom.com> (raw)
In-Reply-To: <001301c8c6d3$66400590$1c0110ac@ariga>
> From: ariga masahiro
>
> Thank you,Paul,for valuable suggestion.
> I re_calculated by toggling LED and measured signal's duration on
> osilloscope.
>
> result
> (1) only used cyg_thread_delay(2) -- 20.2millisec
> (2) cyg_thread_delay(1),cyg_thread_delay(2) -- 30.1millisec
> (3) same as (2) except changed cyg_thread_delay(2) to
> yg_thread_delay(20) -- 212millisec
> (4) only used cyg_thread_delay(20) -- 201millisec
>
> I am confirmed in thinking that since
> CYGNUM_HAL_RTC_DENOMINATOR=100, system
> clock is running 100Hz,1 tick perid = 10millisec,and if I wish to
> run system
> clock 200Hz I should change CYGNUM_HAL_RTC_DENOMINATOR to 200.
>
> But according to your mail, it raised another puzzlement.
>
> > However, you won't find it out very easily with diag_printf, because it
> > probably takes longer than 10ms to execute.
>
> At first,I couldn't get it. Because if diag_printf takes over
> 10ms, simply
> calculated results ought be longer,
> but on the contrary it took far shorter than expected.
>
> So I deliberately inserted
> HAL_CLOCK_READ1(&start);
> diag_printf("id=hi 0x%x\n",start);
> in above each test(after led_toggle function) and investigated how it
> affects duration time.
> To my very astonishment as far as looking signals on osilloscope
> there are
> no differences !
> Two functions takes no time at all as far as looking to signals.
Well, then the diag_printf is running fast enough on your system. That
depends upon the bit rate. On a system running at 115200, outputting 18
characters takes about 1.5ms, which is short enough, but running at 9600
takes 19ms, which would cause a problem.
If your loop is running at the right rate according to the scope, but your
diag_printf messages show something different, then it sounds like you've
proven that your HAL hardware clock isn't running at the speed you think it
is.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2008-06-05 17:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-07 23:59 [ECOS] Wrongfully compiled code ariga masahiro
2008-01-08 0:05 ` Gary Thomas
2008-01-08 1:05 ` ariga masahiro
2008-01-17 19:21 ` [ECOS] " Dave Lawrence
2008-01-17 23:50 ` ariga masahiro
2008-01-18 12:16 ` Dave Lawrence
2008-01-18 14:40 ` Gregg Levine
2008-01-18 15:44 ` Dave Lawrence
2008-01-18 15:49 ` Gregg Levine
2008-01-18 16:09 ` Dave Lawrence
2008-01-21 0:34 ` ariga masahiro
2008-02-04 1:49 ` ariga masahiro
2008-02-04 11:38 ` Dave Lawrence
2008-02-12 1:06 ` ariga masahiro
2008-02-12 10:55 ` Dave Lawrence
2008-02-22 4:57 ` [ECOS] How to re-install newly compiled gnutools ariga masahiro
2008-02-22 7:15 ` ariga masahiro
2008-05-16 8:13 ` [ECOS] When or on what condition does "deschedule" happen? ariga masahiro
2008-05-16 15:26 ` Andrew Lunn
2008-05-19 5:32 ` ariga masahiro
2008-05-19 13:18 ` Andrew Lunn
2008-05-19 13:31 ` Gary Thomas
2008-05-20 1:26 ` ariga masahiro
2008-05-20 12:18 ` Andrew Lunn
2008-05-23 7:38 ` ariga masahiro
2008-05-23 9:35 ` Nick Garnett
[not found] ` <000601c8c165$406e0970$1c0110ac@ariga>
2008-05-29 18:23 ` [ECOS] Re: In trouble of timer operations Andrew Lunn
2008-05-30 2:50 ` ariga masahiro
2008-05-30 3:09 ` Paul D. DeRocco
2008-05-30 4:11 ` ariga masahiro
2008-05-30 4:43 ` Paul D. DeRocco
2008-05-30 7:26 ` ariga masahiro
2008-05-30 7:47 ` Paul D. DeRocco
2008-05-30 8:03 ` ariga masahiro
2008-05-30 8:07 ` Andrew Lunn
2008-06-04 5:25 ` ariga masahiro
2008-06-04 10:06 ` Paul D. DeRocco
2008-06-05 6:14 ` ariga masahiro
2008-06-05 17:39 ` Paul D. DeRocco [this message]
2008-05-30 6:35 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PGEAIGBPLOMOJDAPCOJHIEELLAAB.pderocco@ix.netcom.com \
--to=pderocco@ix.netcom.com \
--cc=ecos-discuss@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).