Unless you have documentation about the RNG interface that states that it's using a cryptographic PRNG seeded by an entropy source, use it only as a seed to a PRNG. (Seed initially, and re-seed from time to time as directed by the PRNG algorithm and possibly by certification requirements. Since you're using an existing PRNG library, just pass it the seed function and let it manage when it seeds.)
A hardware RNG always has biases. Those biases may be negligible or not depending on conditions, for example it may perform poorly at certain temperatures or if the power supply is not optimal. A cryptographic PRNG removes observable correlations from the RNG. Even if the seed is not perfectly uniform, the PRNG hides the biases: either the attacker manages to guess the whole seed (i.e. the whole HRNG output), in which case all is lost anyway, or the attacker only manages a partial observation (e.g. after a 1 bit, there's a 50.1% chance that the next bit is also 1) and the PRNG makes that observation useless on its own.
An ideal system uses a HRNG that's unconditioned, i.e. that has no mechanism to eliminate biases, and runs some basic tests about its output based on the known failure modes (e.g. a particular sensor might return all-bits-0 if not properly initialized). The output is then used to seed a PRNG. When that process is hidden in a black box labeled “RNG”, it's hard to verify that the entropy source is operating correctly.