Bug in RealRandom.Spin

Heater.

I just downloaded RealRandom.spin from the OBEX (Version 1.1) and noticed an error in the start method:

Basically it has a line of code after "return" that is never executed. This could result in some applications not getting random numbers for a while immediately after starting RealRandom.

I guess for most it would not notice or matter but I wanted to start RealRandom for a very short time, get some values for an initial seed of a PRNG with a very long period and then shut down RealRandom. Rather than dedicating a COG to random numbers.

PUB start : okay

'' Start real random driver - starts a cog
'' returns false if no cog available

  'Reset driver
  stop                                                    

  'Launch real random cog
  return cog := cognew(@entry, @random_value) + 1

  'allow 5ms to launch and randomize
  waitcnt(clkfreq / 200 + cnt)

Phil Pilgrim (PhiPi)

Perhaps the waitcnt is merely vestigial code that Chip neglected to remove after he discovered that it was unnecessary. The fact that there's also an unused return variable (okay), which would have been used to span the waitcnt before returning, bolsters this hypothesis.

-Phil

Heater.

I think you are right Phil. However there is a potential problem. If you use RealRandom as so:

    raddr := rr.random_ptr
    rr.start
    repeat 30
        console.hex(long[raddr], 8)
        console.tx($0d)
        console.tx($0a)

The first random number returned is always zero.
So if I use it as a seed for my long period PRNG it is not so good! So the delay to let things start up has to be placed some where.

Further experiment shows that this:

    raddr := rr.random_ptr
    rr.start
    a := long[raddr]
    b := long[raddr]
    c := long[raddr]
    d := long[raddr]
    e := long[raddr]
    f := long[raddr]
    g := long[raddr]
    h := long[raddr]
    i := long[raddr]
    j := long[raddr]
    k := long[raddr]
    l := long[raddr]
    m := long[raddr]
    n := long[raddr]
    o := long[raddr]

Gets "random rumbers" of zero all the way up to l.

Rayman

Maybe that start routine should just wait for [raddr] to be non-zero before returning...