LeafLabs Garden » Topic: 5V sensors with Maple analog input

LeafLabs Garden » Topic: 5V sensors with Maple analog input http://forums.leaflabs.com/topic.php?id=259 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:15:28 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php larryang on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-2135 Sun, 31 Oct 2010 22:20:45 +0000 larryang 2135@http://forums.leaflabs.com/ Eh, where to start... I'm a DSP programmer, so I'll give my perspective. Instead of decimal, you have to think in binary. You have to know a bit about the hardware, especially how the processor does arithmetic. Check out this useful Q notation: <a href="http://en.wikipedia.org/wiki/Q_(number_format)" rel="nofollow">http://en.wikipedia.org/wiki/Q_(number_format)</a>. In C code, I would keep everything straight via type names, such as uint32_q8. As for implementing delta_t = (1.121*(timeNew-timeOld))/2, regardless of Q format, this how I would do it, a fairly quick fashion. Since 1.121 * 256 ~ 287, so (((timeNew-timeOld)* 287)/256)/2 which simplifies to ((timeNew-timeOld)* 1148)/512. Compiler should take care of converting the divide to arithmetic right shift, but they don't always do that. This stuff isn't that portable, and you'll have to check for saturation/overflow. gbulmer on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-2039 Tue, 26 Oct 2010 14:48:25 +0000 gbulmer 2039@http://forums.leaflabs.com/ poslathian - should we break FixedPoint out into a new thread? In the meantime ... I think one FixedPoint32 class would be fine to start with, and we can flesh it out as we go. I am happy to start with a fixed 16.16 format, or a single common format for all instances of the Fixed32 class, to make it easy to get going. I do think that template classes are the 'right' final solution, but we might find one on the net we can use, and hence avoid ever having to do that ourselves :-) I would like operator overloading. I did a little bit of programming on PowerPC Macs using the AltiVec function wrappers, and it was pretty ugly. To start with, we probably only need a constructor, +, -, * and /, ==, <, >, (etc) and a way to get a text string representation of the number. I assume we are representing the number as an int32, and there are no virtual functions. Is this interesting as a project to other folks? poslathian on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-2018 Mon, 25 Oct 2010 20:41:09 +0000 poslathian 2018@http://forums.leaflabs.com/ I agree with the no templates solution. The macro solution is good, In fact thats what ive been using, but it doesnt support operator overloading, since at the end of the day the type is still just a int32 or whatever. I was thinking we could use a single FixedPoint class, with the width and fractional/interger components as member variables. Give people three flavors, 16, 32, and 64 bit fixed point types, with any breakdown of fractional/integer parts they wish. Then overload the operators for that class. Templates do seem the natural and more efficient way to do it, since technically we are just building a polym. type but..ehh..no. gbulmer on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-2011 Mon, 25 Oct 2010 20:09:31 +0000 gbulmer 2011@http://forums.leaflabs.com/ poslathian - I was thinking of several levels of complexity. At the simplest, it is typedefs and some macros. Next up is operator overloading and some easy constructors, so one approach might be: FixedPoint32 pi(8,24) = FixedPoint32Value(3,1415926); FixedPoint32 radius(8,24) = FixedPoint32Value(1,4142); FixedPoint32 area(8,24) = pi * radius * radius; SerialUSB.print(area); but a way that seems to make more sense (though I do NOT like C++ templates) might be: FixedPoint32<8,24> pi(3,1415926); FixedPoint32<8,24> radius(1,4142); FixedPoint32<8,24> area = pi * radius * radius; SerialUSB.print(area); The 'Rolls Royce' solution might be Fixed<2,24> pi(3,1415926); Fixed<1,37> radius(1,4142); FixedPoint32<15,17> area = pi * radius * radius; I am happy to start off with something simple, and preferably already tested and working :-) poslathian on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-2005 Mon, 25 Oct 2010 19:56:07 +0000 poslathian 2005@http://forums.leaflabs.com/ gbulmer, I've been using my own hacked together implementation, without any checking on overflow or other fancy features. I was thinking of something along the lines of FixedPoint32 x(16,16); or FixedPoint64 x(50,14); and the rest with operator overflow (so you can just do x*y) and no checking for value overflow. This is really just one class (wirish only, since its c++), and minimal adjustments to multiply and divide operations. What did you have in mind that was more complicated? gbulmer on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1996 Mon, 25 Oct 2010 19:29:13 +0000 gbulmer 1996@http://forums.leaflabs.com/ poslathian - have you found a nice fixed point C++ class library that would run okay on Maple? It seems like such a well understood problem, but I haven't found a nice solution. If anyone has a nice library, I'd be interested. My requirements: 1. Reasonably small, i.e. well under 10K for the core, and no huge bloat if its used in several source files 2. Reasonably quick. Within 50% of hand-coded fixed point would be good, but within 4x would be fine 3. Somewhat flexible in number range. I'd like to specify the number of digits (bits) in whole and fractional parts. I'd accept that the whole thing must fit in, e.g. a 32 bit int 4. robust - it doesn't silently blow up if there are errors 5. Easy to use - at worst it should have a well designed API, at best it might look well integrated into the language, using operator overloading and nice constructors 6. Debuggable - it must be possible to understand what is going on 'under the covers' so I can debug my code; this may be no more than some helper functions for print support. 7. Open Source Silntknight - specifying the N would be a nice option, but IMHO it'd be pretty good to be able to say the number of digits in the whole and fractional part, and let it get on with it :-) poslathian on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1995 Mon, 25 Oct 2010 19:28:46 +0000 poslathian 1995@http://forums.leaflabs.com/ Go with the 32 bits unless youre really tight on memory. All the operations happen 32 bits at a time anyway. You need to be careful that if youre using fixed point, your max number goes way down. For example if I have 256.0 * 256.0 in 16,16 fixed point then I end up with 65536.0, which is greater than 2^16-1, and so you have an overflow. Point being, even if all your numbers are under 1000, you still just overflowed a 32 bit number. The solution in the above case is either to avoid multiplying two "big" numbers (so that the result would be greater than 2^16 or whatever) or to use sacrifice some of your fractional bits (do 20 and 12 instead of 16 and 16...). Or, use floating point numbers, and all that that entails. Silntknight on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1987 Mon, 25 Oct 2010 18:48:18 +0000 Silntknight 1987@http://forums.leaflabs.com/ Poslathian, I think that is a good idea. I know the precision I need. What would be nice is if you could also specify the N bits, because I doubt I'd need all 32 (maybe only 16 or 24). poslathian on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1985 Mon, 25 Oct 2010 18:25:33 +0000 poslathian 1985@http://forums.leaflabs.com/ gbulmer's recommended reading about floating point is seconded here. I avoid floating point whenever possible (read - when I roughly know the range of number I'll be dealing with) I usually use fixed point when I need fractional numbers. Ive been toying with the idea of using operator overflow in c++ to add fixed point support to libmaple. What do you think? for those of you curious, fixed point is a scheme is where you take an N bit number (say 32 bits) and you say the high j (say 16) bits and make them integer bits, and the low k bits (say 16) and make them fractional bits. Then for a 32 bits number you have: x = num[31:16] + (1/2^16)*num[15:0] of course you dont have to do 16 and 16, you can get any precision you want. And note that the precision here is fixed at 1/2^16 ... hence fixed point. In this scheme adding and subtracting both occur in the normal way, and multiplying and dividing take one extra operation. For example x*y is actually (x*2^16)*(y*2^16) so you have to then divide by 2^16 on your result Silntknight on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1984 Mon, 25 Oct 2010 18:23:30 +0000 Silntknight 1984@http://forums.leaflabs.com/ <blockquote>Is that what you mean?</blockquote> Yes. I wasn't sure if it used HTML formatting. First, let me start by saying that I actually find all this fun. I haven't had any formal education in programming (except HTML...) so, while it may be confusing, none of it is stuff I wouldn't be willing to try. On to the heart of the matter, I believe anything coming from millis() should be stored as a long. What I might do is break it down into multiple calculations. I would initialize timeNew and timeOld as long's, but their subtraction could easily be parsed as an int. <pre><code>int delta_t = timeNew - timeOld; delta_t = delta_t / 2; float delta_time = 1.121 * delta_t;</code></pre> Hopefully that code would give me a good balance between accuracy and speed. Only the last calculation would involve non-integers (obviously odd numbers divided by 2 give non-integers, but a half-millisecond error is acceptable). For the last calculation, should I have it something like: <pre><code>float c = 1.121; float delta_time = delta_t * c;</code></pre> The previous also removes float division in exchange for integer division. Either way, even 50 clock cycles for all the math is fine. Long story short, I could use a float or recast everything in microseconds. gbulmer on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1979 Mon, 25 Oct 2010 13:13:24 +0000 gbulmer 1979@http://forums.leaflabs.com/ Another interesting paper on floating point <a href="http://docs.sun.com/source/806-3568/ncg_goldberg.html">What Every Computer Scientist Should Know About Floating-Point Arithmetic</a> is worth a skim. It starts off with Rounding Error, so there isn't too much to read before some of the problems with the usual floating point representation becomes apparent. Please don't be scared away from using floating point. But please be aware that it is not as fool proof as it might appear. gbulmer on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1975 Mon, 25 Oct 2010 11:01:33 +0000 gbulmer 1975@http://forums.leaflabs.com/ <blockquote>Also, I am not concerned with speed to the extent that I would sacrifice (much) accuracy. </blockquote> Okay, I think I understand a bit better. <blockquote>What I am really asking for is the most accurate possible answer for the equation. ... <code>delta_t = (1.121*(timeNew-timeOld))/2;</code> </blockquote> Okay, <code>1.121</code> can be stored as a float, or a double. The calculation as shown has only 3 decimal places, and 4 significant digits, which would fit into a float. How many digits are needed to store <code>timeNew</code> and <code>timeOld</code>? A <code>float</code> uses 24 bits (23 bits and an implied extra bit, which is always 1) to store the number part (mantissa), so more than 7 significant decimal digits*. The rest is the exponent which says where the binary point is, and the sign. A <code>double</code> uses 53 bits (52 and an implied 1) for the number. So oodles :-) BUT, remember that some rational numbers don't have precise representations in floating point format, for example 0.1, precision can be exceeded, so it isn't as ideal as it might seem. See <a href="http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems">http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems</a> If you wanted the arithmetic to faithfully carry all possible values within a known number of significant digits, and hence not lose any information, then it would need to be done using fixed point, and implemented as integers, or use a much better analysis of the calculation than I can give. So, if the calculation were done in units 10,000x bigger, it could all be integers. <blockquote>Also, should I do the divisions before, or leave the Maple to do it. I think I should leave the Maple to do it because 1 instruction will add 1/72 of a microsecond (double check my math) to the code and will leave it, hopefully, more accurate. </blockquote> I would try to write the code for the calculation in the way I understand, and if that has a divide, so be it. Having said that I should add that divide is one of the slowest arithmetic operations, and can take anything from 2 to 12 cycles, depending on the values involved, for an integer divide on a Cortex-M3. A floating point divide will be significantly slower. A divide by two shouldn't matter to the accuracy. But, try to do what you understand as you'll likely need to debug this. <blockquote>As far as recasting goes, all I am concerned about is accuracy, so if recasting it into integer operations would be more accurate, which I am hesitant to believe, I will do so. </blockquote> Have a look at <a href="http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems">http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems</a> and see how you feel about floating point vs fixed point integer. <blockquote>Quick aside, "remembering" that the value is 10000 times too large won't be useful because the computer needs it to process the value later. I might as well divide now. </blockquote> If all the math is recast to be in microseconds, or even 1/72,000,000 of a second (i.e. internal processor clock frequency), then the math will be as accurate as the machine can do, and the units will be those required to control the hardware at the greatest precision it can achieve. <blockquote>Thanks Gbulmer, you are *extraordinarily* helpful! </blockquote> Thank you very much for saying so. That is kind, generous and much appreciated. * I think I remember all the correct terminology :-) gbulmer on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1972 Mon, 25 Oct 2010 09:40:06 +0000 gbulmer 1972@http://forums.leaflabs.com/ Do you mean how do I get your text to look different? I use blockquote, in an XML/HTML style, but I can't show exactly because it turns into a blockquote, so I will misspell and write "blockpuote" <blockpuote>some text </blockpuote> turns into <blockquote>some text </blockquote> Is that what you mean? Silntknight on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1968 Sun, 24 Oct 2010 23:09:23 +0000 Silntknight 1968@http://forums.leaflabs.com/ Ok, so first, how do I use quotes (like you do, not these: ")? Also, I am not concerned with speed to the extent that I would sacrifice (much) accuracy. I was just commenting on how I can rewrite the code accurately and make it faster. When I say "store as a decimal," I mean store a number like 1.275. int would give me problems, but I know that double's can store data like that, at least in Java. Your explanation shows why. I guess I should say non-integers, because "decimal" has a specific denotation within computer terminology. What I am really asking for is the most accurate possible answer for the equation. Also, I realized the equation I gave earlier is incorrect. It should be <code>delta_t = (1.121*(timeNew-timeOld))/2;</code> Also, should I do the divisions before, or leave the Maple to do it. I think I should leave the Maple to do it because 1 instruction will add 1/72 of a microsecond (double check my math) to the code and will leave it, hopefully, more accurate. As far as recasting goes, all I am concerned about is accuracy, so if recasting it into integer operations would be more accurate, which I am hesitant to believe, I will do so. I think that is there more for the purpose of speed. Quick aside, "remembering" that the value is 10000 times too large won't be useful because the computer needs it to process the value later. I might as well divide now. Thanks Gbulmer, you are *extraordinarily* helpful! gbulmer on "5V sensors with Maple analog input" http://forums.leaflabs.com/topic.php?id=259&page=2#post-1963 Sun, 24 Oct 2010 19:18:28 +0000 gbulmer 1963@http://forums.leaflabs.com/ <blockquote>... pressure sensor isn't linear over it's domain. It is only linear over .2V to 4.9V. </blockquote> Okay, I get it now. On Maple (ARM) an int is 32-bits, but people traditionally use specific types to force the size to be what they need, so int32 would be unambiguous. I don't use floating point arithmetic much, but it works. I just did a quick check, and the sizeof(float) is 4 bytes, and the sizeof(double) is 8. It's just slower than int's. <blockquote>... If I store it as a double, can I get decimals?</blockquote> Not sure what you mean. A double is only a decimal part, it is represented in (the binary form of) scientific notation, e.g. 1.275 is stored as 0.1275 * 10^1 (but in binary)*. So yes, with some example numbers, and assuming timeNew and timeOld are unsigned long ... double delta_t = 1.275*((timeNew-timeOld)/2); = 1.275 * ((300-199)/2); = 1.275 * (101/2); = 1.275 * (50); // it is integer arithmetic = 63.75; I wouldn't worry about how fast the code goes until you get it giving the correct answers. (I'd also suggest looking at Amdahl's Law.) That calculation can be recast as: double delta_t = 1.275*((timeNew-timeOld)/2); double delta_t = 0.6375*((timeNew-timeOld)); double delta_t = 6375*((timeNew-timeOld))/10000; int delta_t = 6375*((timeNew-timeOld)); // and remember it is 10000 times too big Please try to avoid focusing on how fast it will go until it gives the correct answers because: 1. It is likely that it will be fast enough anyway, 2. It is always difficult to really know which part will be the slow part before it works 3. It might be impossible to make it fast enough, and that is hard to tell until it works As far as I can see, there isn't anything you have described which the Maple can't do easily, if approached in the right way. So get it working with the least amount of effort, and leave plenty of time to improve it if there are any problems. * actually it is sneakier than this, but this is a pretty good way to understand it.