Delaying execution - VxWorks

This is a discussion on Delaying execution - VxWorks ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Delaying execution

  1. Delaying execution

    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



  2. Re: Delaying execution

    "Chris Doré" wrote:

    >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?


    http://www.xs4all.nl/~borkhuis/vxworks/delayLib.h
    http://www.xs4all.nl/~borkhuis/vxworks/delayLib.c

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at comcast dot net | - The Who, Bargain

  3. Re: Delaying execution

    "Michael R. Kesti" wrote:
    > http://www.xs4all.nl/~borkhuis/vxworks/delayLib.h
    > http://www.xs4all.nl/~borkhuis/vxworks/delayLib.c


    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



  4. Re: Delaying execution


    "Michael R. Kesti" wrote:
    >> http://www.xs4all.nl/~borkhuis/vxworks/delayLib.h
    >> http://www.xs4all.nl/~borkhuis/vxworks/delayLib.c


    On 16 Aug 2005, cdore.connecttech.com wrote:

    > 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.


    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"

  5. Re: Delaying execution

    "Bill Pringlemeir" wrote:
    >
    > 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.


    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).

    > 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 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



+ Reply to Thread