ugh! That did the trick. I told you it was simple and yes I am embarrassed, I feel like a DAR (Dumb Ass Rookie).
Thanks for the 411 Nick, I appreciate it. -----Original Message----- From: Nick Garnett [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 13, 2006 04:06 To: Kevin Wilson Cc: '[EMAIL PROTECTED]' Subject: Re: [ECOS] concurrency issue - eCos 2 (not the latest and greates t version) Kevin Wilson <[EMAIL PROTECTED]> 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
