This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: concurrency issue - eCos 2 (not the latest and greates t version)
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: Kevin Wilson <Kevin dot Wilson at comtrol dot com>
- Cc: "'ecos-discuss at sourceware dot org'" <ecos-discuss at sourceware dot org>
- Date: 13 Dec 2006 10:05:51 +0000
- Subject: Re: [ECOS] concurrency issue - eCos 2 (not the latest and greates t version)
- References: <DD5056872F0E6A4EB8555318C3F8BCB00B6694@exchange-2.comtrol.com>
Kevin Wilson <Kevin.Wilson@comtrol.com> writes:
> >>* What's the platform?
>
> ARM7
>
> >>* Can you show us some suspect output, with comments on what it should
> look like?
>
> well, it is pretty simple. it is just a printf of the calculated millisecond
> value from the supplied clock ticks. The function's diag_printf spews out 3,
> 12, -9 when it should be printing 33000, 35000, 40000. Our clock ticks are
> 10ms each so it is pretty easy to see that returned value is wrong. Also
> real easy to see that the mathematics are correct because the same math calc
> done within the thread task yields the correct value.
I think your calculation is overflowing. The resolution dividend is
usually 1000000000. You only need to multiply that by 3 to make it
overflow a signed 32 bit int. Also, the return value of
cyg_current_time() is a 64 bit integer, so casting it to an int may
lose high order bits. I think if you change the type of the val1
argument to cyg_tick_count_t and add LL to the constant in the
expression, then the calculation should come out correct.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss