How large a dynamic range do you have to do the humidity correction over? It may well be possible to devise a scaled integer implementation for the correction provided that you only want say 0.1% accuracy.
Rational polynomials will get you quite good approximations to arbitrary functions which in the case of humidity corrections I suspect is fairly close to exp(x) or log(1+x) depending on how you have cast the problem.
-- Regards, Martin Brown
Lasse Langwadt Christensen wrote in news: snipped-for-privacy@googlegroups.com:
Less performance and memory than a pi? Wachutalkinbout, dingledorf?
You on drugs?
Oh and lets not even notice the interfaces on it.
I'd bet the MTBF is a couple orders of magnitude better too.
Winfield Hill wrote in news: snipped-for-privacy@drn.newsguy.com:
But that is not the only component.
My RIS-788 beehive monitor is a complex instrument: more than 250 parts on its mobo, many more on plug-in boards. It had more than 75 sensors in total. More than $150 in parts costs, $100 of machine-assembly costs, plus $100 of engineer/technician final-assembly costs.** Controller expenditure was in the noise level. The plug-in Feather, with its program, $18, ended up being a huge convenience. The low cost of the ATSAMD21G18 was an important aspect.
** Total quantity made: 30 pieces. Total bees monitored, about 1 million. About $0.01 per bee. But they worked their asses off, that's worth 1 cent. Well, OK, maybe for scientific purposes, too expensive for commercial purposes. For that the cost/bee has to be well under 0.05 cent.
--
Thanks,
- Win
more clock speed, more ram, faster USB, half the price.
-- When I tried casting out nines I made a hash of it.
There are a few things that make floating point libraries lower compared to integer implementations. One is the adherence to IEEE "oddities", such as NaNs, infinities, non-normalized small values etc.
In a small system, in which the majority of operations are done with integers (or fixed points) and only some library functions such as log(x) is called, you first have to convert the argument to floating point and the result back to integer. These conversions are nasty, which requires normalization and denormalization, which is quite slow, if no hardware support is available. Floating addition and subtraction also suffer from the same problem.
Floating multiplication and division are simpler which are no worse than integer mul/div.
In a floating point implementation, these functions are typically implemented by first normalizing the value between 0.5 to 1.0 and a
3rd or 4th order polynomial is used to approximate the result to 6 or 7 significant digits. Of course a floating point argument has already been normalized in the floating point format.It should be noted that doing the polynomial in a floating point library, multiple slowish floating point adds are also required.
Doing for instance log2(x) entirely in integers first requires checking the input range and flagging "impossible" values before going further, thus no need for infinities.
The argument is then normalized, requiring 4-5 instructions/bit. The polynomials are then done with integer multiplications and additions, (with possible shifts when fixed point values are used). There are only one normalization compare to several when floating point libraries are used.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.