Post by thread:[PICLIST] Maths Problem

Thanks for that Andy, yes I tried compiling with some different maths functions, the log(x) function uses 599 words and the sqrt(x) function uses 573 words, I will have to think of something else, If I use any maths functions using the 16F84 I won't have much room left for my program!. On Fri, 17 Nov 2000, Andy Jancura wrote: {Quote hidden}> >Hi Folks!, I am trying to use picclite to do a little maths on my pic i/o > >I am using #include <math.h> > > > >then in main float a, b=2, c=2; // simple test > > a=pow(b,c); // > > > >This compiles no trouble but when it links it produces lots of errors > >similar to this:- > > > >::Cant find 0x5B words(0x5B withtotal) for psect text0 in segment CODE > > > >I am using a 16F84 and the default linker settings. > > > >Anybody got any ideas what could be wrong?. > >Is anyone successfully using maths functions on the 16F84? > > Library code for pow() has little bit more than 1024 words. > > Andrej > _________________________________________________________________________ ----- John P. Brown .....J.P.BrownKILLspam@spam@bradford.ac.uk ---- \ --- Witty remark goes here --- / -------------------------------------------------- -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

Hi Scott, the application will be producing a linear o/p from a variety of sensors such LDRs etc. I am considering using a lookup table to do the job. ----- John On Fri, 17 Nov 2000, Scott Dattalo wrote: > On Fri, 17 Nov 2000, JP.BROWN wrote: > > > Thanks for that Andy, yes I tried compiling with some different maths > > functions, the log(x) function uses 599 words and the sqrt(x) function > > uses 573 words, I will have to think of something else, If I use any maths > > functions using the 16F84 I won't have much room left for my program!. > > Well, you could use integer arithmetic instead of floating. What's the > application? -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

J.P. Brown wrote: > Thanks for that Andy, yes I tried compiling with some different maths > functions, the log(x) function uses 599 words and the sqrt(x) function > uses 573 words, I will have to think of something else, If I use any maths > functions using the 16F84 I won't have much room left for my program!. This is way too much even for floating point! I know for sure sqrt(x) takes 87 instructions for 24 bit float using PIC16 instruction set. You can easily include that in assembly as a C function, only conversion between Microchip and IEEE floating point representation would be required (it's just three instructions either way). The routine (and conversion) is at http://www.piclist.com BTW, it was debugged recently. And log(x) might take around 200 instructions if implemented using the CORDIC method. If you can tolerate ~0.05% error it can be even smaller and faster with a 16 entries table. For example, take a look at "[PIC]: [MATH] x^y routine implementation" thread in September. Good luck, Nikolai -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Hi to all, Must admit I haven't been on the list for about 18 months now, but therein lies the problem. That is, I get to do some programming of PIC's when there is a need and for the last 18 months there's been plenty else to occupy my time. Anyhow to my problem. I have built a couple of timing units (race type clocks) using 16c64's, with some nice big 5" LED displays and all is (was) working very well. Then some bright spark comes along and says 'well on that one it would be nice to convert the display into the average speed' (in MPH). The distance travelled is easy cos its a fixed distance in Yards, but the time ends up as a value in four bytes i.e. 20h = 2, 21h = 6, 22h = 4, 23h = 7, therefore time = 26.47 seconds. This I now shift into two bytes to output to BCD to 7 segment decoders, thus port b outputs the 2 & 6 and port c outputs the 4 & 7. For the maths, I know that if I take a distance of say 60 yards and divide that by 1760 and then multiply it by 1000 it will give me a nice fixed value of 34 (D). But then I need to take my timing and divide that by 3600 (or 3.6 thus ignoring the need to then multiply by 1000) to create a value that will then be divided into the D value. This will give me the resultant average speed in MPH. I've looked at the list FAQ's and Microchips AN's for maths routines but! Is this 16 or 32 bit maths, and how do I cope with the decimal places? Is this even possible in a PIC? Any help or guidance would be most appreciated as I seem to have gone brain dead on this one. TIA, Philip Martin. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Philip Martin wrote: > For the maths, I know that if I take a distance of say 60 yards and divide > that by 1760 and then multiply it by 1000 it will give me a nice fixed value > of 34 (D). But then I need to take my timing and divide that by 3600 (or 3.6 > thus ignoring the need to then multiply by 1000) to create a value that will > then be divided into the D value. This will give me the resultant average > speed in MPH. > > I've looked at the list FAQ's and Microchips AN's for maths routines but! Is > this 16 or 32 bit maths, and how do I cope with the decimal places? Is this > even possible in a PIC? > > Any help or guidance would be most appreciated as I seem to have gone brain > dead on this one. This may help you understand, or seeing as how I'm not a math wizard, it may confuse you more ;-) 3.6 in decimal = 3 units + 6 tenths of that unit. In hexadecimal, ala PIC world, the units are either bytes/words or larger. 3 fits in a byte nicely, but 0.6 does not. In decimal terms, 0.6 = 6 / 10 In byte terms, 0.6 is saying 6 tenths of a byte Mathematically this would be... 6 X 256 ------- = 153.6 or 99h 10 Thus we can represent 3.6 decimal as 03.99 in hexadecimal. The PIC will not understand 03.99 in hex so the whole value must be made to fit into bytes or words. In this case multiply the entire value by 256. 03.99h X FFh = 0399h High Byte = 03h Low Byte = 99h Now you have a value to work with inside the PIC and you can operate on it any way you like. You also know that the least significant byte of any result is the value after the decimal point. It would be easy to do a BCD conversion on 03h, then a decimal place, then BCD 99h The display would then read 3.15 (ignoring the last digit 153) Ahh, but this is wrong, it should read 3.6 The reason is the value after the decimal place is actually a fraction of a byte value. To convert back to a decimal value, transpose the above formula 99h X 10dec ------------ 256 Or simpler, just do 99h X 10dec and use the high byte of the word result. The result however will be 5, not 6 as we would have liked. The reason is that the 'real' value 153.6 from above was truncated to 153 (99h). Thus there is a small error. The result above is in the low nibble of the high word. You can reduce the error slightly by using a larger conversion number. 99h X 100dec The result in this case will be 3Bh or 60dec in the high word. We know this is a fraction with 1/10ths and 1/100ths so we can display it as such. Now after BCD conversion your display will read 3.60 Also, as you are working with constant values, why not divide them down into simpler terms. Eg 3600 18 ---- = -- 1000 5 Much easier to work with. Try to work out the total math on paper and solve for the final value. Then see if the formula can be simplified, and use that in your code. -- Best regards Tony mICro's http://www.picnpoke.com salesspam_OUTpicnpoke.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Well as Tony Nixon suggested an fixed format is the way to go here. I would suggest an 16.8 or if range is enough 8.8. It's then very easy to scale this by using Nicolai's code generator. For example for 16.8 (binary) to 6.2 ( fixed point with 2 digits after decimalpoint ) you need to scale something like this: 16.8 / 256 is the integer part, but we also want 2 digit from the decimal part and hence we add * 100 and gets: 16.8 * 100 / 256 = 16.8 * 0.390625 Enter this in the code generator ( i.e constant 0.390625 ) input size 24 bits. And all the code you need will be generated. Example ( using your value here ): 26.47 ( decimal ) would be in 16.8 format: Integer-part -> 26 = top two bytes = 0x001A in hexadecimal. Decimal part -> 47 * 2.56 = 120.32 ( this code could also be generated by above code generator ), we cut the decimal part and have 120 left which is 0x78 in hex. We now have the original value in 16.8 format as: 0x001A78 ( which btw is 6776 decimal if treated as 24 bit value ) Run this though the code generated above ( 0x001A78 * 0.390625 ) and you will have: 0x000A56 or 0x000A57 ( depending how you handle rounding ) which is 2646 or 2647 in decimal. Now as we have decided to have an 'fixed' point with two decimals you already know where to set the decimal point. take the 24 bit value run it through the 24->ascii routine found on the piclist site, place the decimal point two digits from the last and there you go. /Tony Tony Kübek, Flintab AB ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² E-mail: @spam@tony.kubekKILLspamflintab.com ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.