Printable View
Hi all,
During sysHwInit() my driver needs to perform some delays in order to insert
100us gaps in between hardware accesses. I have attempted to use
nanosleep() which results in a machine reset.
How can I delay execution with the least number of dependencies?
Thanks, Chris
"Chris Doré" wrote:
[color=blue]
>Hi all,
>
>During sysHwInit() my driver needs to perform some delays in order to insert
>100us gaps in between hardware accesses. I have attempted to use
>nanosleep() which results in a machine reset.
>
>How can I delay execution with the least number of dependencies?[/color]
[url]http://www.xs4all.nl/~borkhuis/vxworks/delayLib.h[/url]
[url]http://www.xs4all.nl/~borkhuis/vxworks/delayLib.c[/url]
--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mrkesti at comcast dot net | - The Who, Bargain
"Michael R. Kesti" <mrkesti@nospam.net> wrote:[color=blue]
> [url]http://www.xs4all.nl/~borkhuis/vxworks/delayLib.h[/url]
> [url]http://www.xs4all.nl/~borkhuis/vxworks/delayLib.c[/url][/color]
Michael,
Thanks for your suggestion. After some digging I unfortunately have figured
out that the system clock is not functional until after sysHwInit2(). So
using tickGet() before sysHwInit2() (even during) will always return 0.
Thanks again, Chris
"Michael R. Kesti" <mrkesti@nospam.net> wrote:[color=blue][color=green]
>> [url]http://www.xs4all.nl/~borkhuis/vxworks/delayLib.h[/url]
>> [url]http://www.xs4all.nl/~borkhuis/vxworks/delayLib.c[/url][/color][/color]
On 16 Aug 2005, cdore.connecttech.com wrote:
[color=blue]
> Michael,[/color]
[color=blue]
> Thanks for your suggestion. After some digging I unfortunately have
> figured out that the system clock is not functional until after
> sysHwInit2(). So using tickGet() before sysHwInit2() (even during)
> will always return 0.[/color]
I read your initial question and Michael's response. I knew that
tickGet() wouldn't work. However, I forgot that delayLib() uses it to
calibrate.
You didn't mention your platform? You have the source to delayLib(),
so you can modify it to use the PPC decrementer, etc. Extra work and
hw specific.
You can also boot the system and run delayLib initialization and
inspect the value of the count. Then you can hard code this count in
your own routine. No extra work, but hw and CPU clock specific.
The third alternative is to wait for sysHwInit2(). However, since you
know about this, I assume that have already thought of that? The
interrupts should be running in sysHwInit2(). Whether the timer is
functional will depend on the BSP [which you didn't mention].
Can you explain why you need to run the code in sysHwInit()? Usually
this is just to put hw in a quiescent state so that there are no
interrupts when they are enable. You can definitely structure the BSP
so that some timer function are active [maybe not tickGet()] such as
sysTimeStamp(), etc. This will depend on what the BSP offers.
I understand that hw can be complex some time. However, I have almost
always been able to delay this. Fortunately, my "BSP" was usually for
custom hardware so I had no problem inserting a constant value (as in
the 2nd solution above). If this is compile time, it is also possible
that the CPU clock speed is already available as a pre-processor
variable and the delay loop constant can be calculated at compile
time. If it is not available at compile time, then you can calculate
the constant (for particular CPU/compiler) mathematically with very
little error.
Sounds like jiffies and bogo-mips to me ;-).
hth
Bill Pringlemeir.
--
Unfortunately, since the TCP and IP protocols were not designed by a
committee, all these header fields serve some useful purpose and its
not possible to simply omit some in the name of efficiency. - Van
Jacobson, RFC 1144.
vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
"Bill Pringlemeir" <spam_account@sympatico.ca> wrote:[color=blue]
>
> You didn't mention your platform? You have the source to delayLib(),
> so you can modify it to use the PPC decrementer, etc. Extra work and
> hw specific.[/color]
The driver I am developing is not for any specific platform. It all depends
on where a customer is using our products. We only develop VxWorks support
for our products, we are not actually using the VxWorks OS in any of our
products. I am doing my development on a Pentium III (pcPentium3 BSP).
[color=blue]
> The third alternative is to wait for sysHwInit2(). However, since you
> know about this, I assume that have already thought of that? The
> interrupts should be running in sysHwInit2(). Whether the timer is
> functional will depend on the BSP [which you didn't mention].
>
> Can you explain why you need to run the code in sysHwInit()? Usually
> this is just to put hw in a quiescent state so that there are no
> interrupts when they are enable. You can definitely structure the BSP
> so that some timer function are active [maybe not tickGet()] such as
> sysTimeStamp(), etc. This will depend on what the BSP offers.[/color]
I need to delay in order to clock access to a serial EEPROM. The EEPROM
contains configuration data about the device. At the very latest I need the
configuration data during sysHwInit2() (sysHwInit() was simply my first
logical choice, until I ran into the delay problem). Since I need to be as
platform, and BSP, indepentent as possible I am left with few options.
What I think will work out well, is allow the delay function to be defined
at compile time. Thus each individual customer can customize the delay to
whatever works. In my case, I based my defined delay function on the
pcPentium3 BSP's sysDelay() routine which simply performs an I/O port read
to an unused address (takes approx. 720ns). In addition, I am going to move
the retrieval of the configuration data into sysHwInit2() to maximize the
possibility of a customer being able to provide a delay function.
Thanks for all your suggestions,
Chris