random delay .!!

Are we expected to submit some random lines of code?

You have to realize that you can't implement a random function unless you have any data somewhere to randomize from. You (!) have to figure out where that data can come from (# of received serial characters, time stamps when they where received, ...).

We can't do such things - we don't even know your platform...

As soon as you have figured out where you can get something random to base the delay on, then it should be trivial for you to implement the actual delay. Once more: Implementing a delay requires knowledge about the platform. We don't know what timers are available, or how fast the processor is if the delay should busy-loop...

Note that 'C' (or any other High-Level Language, for that matter) is not suitable for writing busy-loop delays for any specific duration as you have absolutely no control whatsoever over what specific instructions the compiler might choose to implement the loop - nor, in fact, whether that choice might change on subsequent compilations...

"Are we expected to submit some random lines of code?"

even if we did, it wouldn't give you a random delay - as Per says, every time you ran them, you would get the same delay!

the first thought would be to use rand() to get a value and then delay based on it.

This reminds me of an episode that show the diffrence between pseudorandom and random.

The J1708 standard specifies that after a bus collision you insert a random delay before trying again. Two units collided and since they both used the Keil rand() they kepr inserting identical delays and collided forever.

The cure was to read a free running timer whenever the operator pressed a key. This gave a real random value

Erik

Two units collided and since they both used the Keil rand() they kepr inserting identical delays and collided forever.

That's what any pseudorandom number generator will do, not just the one from Keils library. Same seed - same sequence of "random" numbers. For that reason, an at least somewhat random number should be picked as the seed - hard-coding the seed is one of the best ways to get the same sequence of known numbers after each reset.

The free-running timer is one way to generate such a "somewhat" random number.

The above problem was why I didn't mention rand(), but instead mentioned "# of received serial characters, time stamps when they where received, ..."

Even if a semirandom event is used to initialize a pseudorandom generator, you can be unlucky enough to get the same seed and then get into a permanent deadlock. A solution that the whole time looks for new randomizing events have a lot less probability of deadlocks (as long as there are devices or events that can be used/abused for randomness).

Even if a semirandom event is used to initialize a pseudorandom generator, you can be unlucky enough to get the same seed and then get into a permanent deadlock.
yes, in one case of 65536 squared (if you use all the bits). Anyhow why would you seed the pseudo, I just use the value read from the timer.

A solution that the whole time looks for new randomizing events have a lot less probability of deadlocks (as long as there are devices or events that can be used/abused for randomness).
I had the same thought and am doing it that way. Now discussing it, I doubt it will make any difference whether you read it once or repeatedly.

Erik

A pseudorandom generator should always be seeded before first use (unless maybe if the output is used for regression testing).

If you have 100 units that gets power at the same time, several of them may read the same timer value and use as seed. So, all would generate the same sequence of random numbers, and may get into very long sequences of deadlock with each other.

That is why I prefer to not use any pseudorandom number generator for breaking ties. Not using a pseudorandom number generator means that there are no need for one intiial seed. Each and every request for random data will instead be based on continuously generated randomnes. Reading a highspeed timer is one way of doing this. Mixing the current timer value with timestamps and data values from received serial, USB and/or Ethernet data is a more complicated (but hopefully better) way of doing it.