On Sep 16, 2010, at 1:12 PM, George Oikonomou wrote:
> Anyhow, the question is, what's the best way to integrate this into contiki
> as transparently as possible? Quick and dirty, I created a file called
> random.c in cpu/cc2430/dev. This file has random_rand and random_init with
> the exact same prototypes as the ones in lib/random.h. I built an image and
> it turns out this file overrides core/lib/random.c. Is this intentional
> (i.e. part of the build system logic) or did I just get lucky?
> I also thought about a RAND_CONF_ARCH-like define in contiki-conf.h and then
> wrapping things in lib/random.c around #ifdef statements but I think this is
> unnecessary complexity. Plus, I dislike modifying the core when I can afford
> not to.
It would probably be a good idea to define a new RNG API to supplement the PRNG API. Platforms which implement an RNG (Either directly with a hardware-based RNG, or by harvesting noise from a suitable entropy source) can implement the proper functions and provide a preprocessor macro to indicate support for a real RNG.
One thing to take into account that while a hardware-based RNG and a software-based RNG (like mine) hopefully generate the same quality of random numbers, the time it takes to generate the numbers is vastly different. For example, my RNG implementation takes non-deterministic amount of time to generate a random number, usually taking on the order of several milliseconds to generate a single 8-bit value. This is only suitable in cases where true random entropy is required. In most cases it is simply overkill.
In some cases though you really do want a PRNG, so replacing that with a HW-based RNG across the board (even though it is fast) may not be the best option. Perhaps what is needed is a set of APIs based on what the user's needs are. ie: What's more important to you: speed, repeatability, or randomness?
In cases where all you want is a random number quickly and a HW-based RNG is available, you probably want to use it. Otherwise, you would probably want to use a PRNG, because it is fast. In this case using my software-based AVR RNG would not be appropriate, because it is anything but quick.
In cases where you need high-quality random numbers, then you would want to avoid the PRNG entirely, using a HW-RNG if it is available and otherwise using a SW-RNG as a fallback.
Just thinking out loud...