Hello,
> So why did Technologic choose
> to use a 10ms jiffie in ts-linux? Is the ARM (ot specifically the TS
> board) hardware not capable of using the 1ms setting?
The default kernel source Technologic Systems used had a system tick
rate of 100Hz. If you need a higher resolution tick you can modify the
tick rate. The tick rate is only a limitation of the default kernel,
there are no hardware limitations.
> comments
> explaining the hardware's timing requirements (or lack thereof) would
> seem to be quite appropriate.
You are making the assumption the 10ms tick rate is a hardware
limitation. This assumption is incorrect, it is a limitation of the
default shipping kernel. I believe if you read the usleep man page you
will find the documentation you are suggesting including in a user space
program.
e.g.
"The usleep() function suspends execution of the calling process for
(at least) usec microseconds. The sleep may be lengthened slightly by
any system activity or by the time spent processing the call or by the
granularity of system timers."
> Especially since usleep() is called with
> two apparently very different values (1 and 100), the code is very
> misleading as it is because it indicates that the short time may be
> necessary for part of the conversation, when that is not generally true.
As you said we can agree to disagree. In my opinion the proper place for
documenting the functionality of usleep, is in the usleep man page not
in a userspace program.
>> Interesting, this is the first report I've heard of such a failure.
> Can
>> you provide more information on how to reproduce this problem?
>
> Um, we used a brand new TS-7800 (ts7800ctl says it was 'born' on Jun 6,
> 2008), booted into the full linux that came on the board, downloaded
> ts7800ctl from the web site and ran it a number of times. When we
> started getting empty results (i.e. just a new command prompt) we tried
> using the VERBOSE option and saw it saying that it couldn't send a start
> signal or that the slave didn't ACK data.
Can you point me to the location of the ts7800ctl code/binary you
downloaded? Were you able to reproduce these problems with the current
shipping ts7800ctl utility? Did you make any changes to the source?
> Lastly, has anyone else's TS-7800
> been running (use the ts-7800ctl odometer) for under -16,000,000 hours?
There is a known bug in the odometer functionality in the ts7800ctl
program(it interprets the odometer value as a 16 bit entity instead of a
12 bit entity). If you need this functionality please let me know and I
can send you a patch. I'm interested in any bug reports/problems you
have with the ts7800ctl program as I am in the process of testing the
code, as we will have new release shortly.
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16610 East Laser Drive Suite 10 | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|