Thread.Sleep() and microsecond-scale delays

I’m wanting to set up delays of less than a millisecond in a project I’m working on. I can’t use Thread.Sleep() because that will sleep my thread for AT LEAST one millisecond.

I’ve seen techniques like this used before:

var ticks_per_micro = TimeSpan.TicksPerMillisecond * 1000;
var ticks_to_wait   = ticks_per_micro * microseconds_to_wait;
var ticks_then      = Utility.GetMachineTime().Ticks + ticks_to_wait;

while( Utility.GetMachineTime().Ticks < ticks_then )

// done waiting...

… but it strikes me that that method is a bit brute-force. Is there something better? Could something be worked out with RLP?

RLP is the best thing to go with if you want to achieve good timings. Could you give us a description why you need this delay ? If you need this to toggle a pin than no RLP will be needed -> just look at OutputCompare class

Tell us what you are trying to do and we will give you the best way to do it

Gralin guessed right, this is for high-speed pin toggling. OutputCompare does indeed seem like a much better method for that, but the question still applies in general.

It’s entirely possible that the answer is, “if you need sub-millisecond delays, you’re probably doing it wrong…”

Note necessary wrong but we may have something better… like OutputCompare :slight_smile:

Right. Also, if your using threads, directly or indirectly, in the app, then no gaureentees either. Other thread(s) could be running for 20ms (or more), before scheduler gets back to your .25ms blocking thread. For that matter, is OutputCompare gaureenteed to return before scheduler runs something else? Not sure.

Also don’t forget about usig a PWM to toggle a pin.

Delegate hard real-time stuff to an Arduino board :slight_smile:

I need sub-millisecond delays too for a software UART. Even at 9600 bps, a bit duration is roughly 100 us.

Interestingly, there is a software I2C controller, but no software UART in the NETMF… How about adding one using native code?


That is a very old thread.

We don’t have a software UART, because, generally we have lots of hardware UARTs available :slight_smile:

it’s an old thread… So what? :wink:

Yes, my Cerbuino Bee has many serial ports. Unfortunately, none of them map with the serial pins of the shield I’m trying to interface with the Cerb. Ah well, so much for a software workaround: I’ll use my soldering iron and patch wires instead. :stuck_out_tongue:

Ok, ok! :slight_smile:

By the way you can use Extender or Breakout module to connect shield to a socket without plugging it into cerbuino.

What kind of shield by the way?

I’m connecting a Liquidware Geoshield (compass, accelerometer + GPS all in one shield). Yup, I could wire it as a Gadgeteer module but it fits nicely on top of my Cerbuino. when plugged in as an Arduino shield. That leaves the Gadgeteer ports available for other modules such as a SPI LCD display module. I’ve interfaced with the compass and the accelerometer. The GPS is the last part left to connect with.

The Geoshield is a solid piece of epoxy with Arduino pins sticking out of it so it’s not possible to hack it. However, I can wrap tiny patch wires from its serial I/O pins to the nearest Cerb’ UART pins. nice and easy!


[quote=“godefroi”]It’s entirely possible that the answer is, “if you need sub-millisecond delays, you’re probably doing it wrong…”
I know this is an old thread, but here’s an example on where one would need sub-millisecond delays : interfacing a nRF24L01+ module.

The data sheet shows that there are delays of about 130 microseconds before the module is ready for transmit or receive. One might need to implement such delays to communicate with the module.

One way around it is to use interrupts, but on simple designs, the delay can be easier.

@ stefanu - on SPI bus? If so then there are arguments to handle just that.

Not exactly. SPI bus is working just fine with available settings.
Here’s a diagram with states and transitions for the nRF24. You can see that once you powerup the module for RX, it will only be able to receive packets about 130 us later. Same for TX, once data is available, actual transmit is some 130 us later.

Am I interpreting the diagram wrong ?

On the other hand, on the original post, the first line of code should read

instead of 

```cpp]var ticks_per_micro = TimeSpan.TicksPerMillisecond * 1000;[/code

Right ?

Dividing by 1000 will give you ticks per second, the original calculation is correct.

Ticks are processor clock ticks, right ?

So if I have, say, 10’000 ticks per millisecond, then there are 10 ticks per microsecond, not 10’000’000.

@ stefanu - You are absolutely correct, not sure what I was thinking…

I’m so stuck in a nRF24L01+ problem that I thought I can’t do simple math anymore :wall:
… not to add it’s about 2AM and the ofee-effect is starting to wear out :open_mouth: