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
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…”
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.
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.
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…”
[/quote]
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.
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 ?
:-[
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
