 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Double precision Math
| Author | Message | ||||
boss Senior Member  Joined: 19/08/2011 Location: CanadaPosts: 268 |
Hi and good morning from Vancouver, is there any (even future) chance to get double precission or at least int32 math in MM Basic? For serious work with the DDS chip (and other) is needed at least Integer 32bit variable but some chips use have finest resolution. The "big numbers" solution written in MM Basic is slow. Regards |
||||
bigmik Guru  Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Hi Boss, An option `might' be to use an external Math Co-Pro... along these lines Micromega or PAK-II The first is ISP or i2C the second is TTL-RS232.. Both are about $20 ea. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
Hi Mick, thank you very much. The Micromega's 32bit integer should be a solution for me right now. But I'm tempted to ask if Micromega is not a cheap 8bit Microchip microcontroller? I think PIC32 with 32bit registers and embedded HW support can do the same with much higher efficience. O.K. for now the problem solved and will see what happen in future. The double precision is highly desired. Regards Bo |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
I have done some work on implementing 32 bit integer and it may be a possibility for the future. Double precision floating point will be a lot harder so the chances of that are remote. Geoff Geoff Graham - http://geoffg.net |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
It probably is, but most of the time taken to do the calculation will be taken up by the I2C or RS232 data transfer not the actual calculation itself. You will still need to send/receive the same number of bytes regardless of whether the co-pro an 8 bit or a 32 bit device. I started to build an 8 bit i2c math co-pro years ago but only got as far as some 8 bit mult/div. I found plenty of math routines to put in the PIC but my need for it diminished so didn't proceed further. It is fairly easy to "grow" your own blank i2c slave and put in your own math or other functions, but at the price of a "bought'n" one why bother. David M. |
||||
| boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
Than you Geoff, 32bit integer math will solve the most my problems with the number accuracy. In my case I'm working with 60Mhz DDS signal generator and tunning step is 4Hz which is acceptable. But next project will use SI570 XO up to 1.1GHz and step 80Hz is to coarse. And I realize that there is great progress with the programming language confort just in one year and I think the MM platform is mature enough for the industrial use. Regards boss |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Geoff, Lua does it differently i heard so i don't know the details. It sounded interesting. (Please check it because i have not checked it personally). What they did is that before compilation you choose which variable type is used. So you have compiled versions for each different type. It is declared only on one place so it is easy to do. (Ain't everything easy when you know it. :) ) You would then have different hex files for: 32 bit integer and string float and string. double precision and string 16 bit integer and string etc.. Of course being able to use all of them is the ideal, but if that is really hard this might be an option. Microblocks. Build with logic. |
||||
| boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
Hi Geoff, Lua (or eLua) is open source I think. The source files is on Github. Why not to take double precission source files or at least the algorithm there? I personally tested STM32F4-Discovery chip and I was impressed with performance. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
The main problem with double precision floats is that they use 8 bytes to store a number while single precision, 32 bit integers and strings all use 4 bytes (strings are stored as a pointer to memory). The routines for variable management all assume that the space required for a variable is 4 bytes - so, a major rewrite of the variable management would be required just to support double precision. Not impossible but still a big job. My main concern would be to not introduce a new set of bugs. Geoff Geoff Graham - http://geoffg.net |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
And the next thing will be running short of RAM sooner. (e)Lua's unlikely to help as I guess you figured. John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think 32 bit integers will be the most useful. Especially for games and manipulating hardware ports it will give a performance boost. I am not sure if 64 bit double precision is really needed a maximite would be a good choice. There are a few solutions to compensate for the precision errors, like the Kahan summation. This helps eliminating errors when multiple values have to be added. Good for calculating averages. Luckily there is a wiki explaining it, i would not be able to explain it that detailed. :) https://en.wikipedia.org/wiki/Kahan_summation_algorithm When you have 32 bit integers you could have a fixed decimal point, it can have 8 decimals precision, just 1 more then a float but it is enough for things like GPS coordinates. If you are really in need of more precision, this is something to chew on: http://andrewthall.org/papers/df64_qf128.pdf If there would be a vote, i would vote for 32 bit integers. Microblocks. Build with logic. |
||||
| boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
Hi, I have to agree that 32bit integer math will cover 98% of all needs, especially if there will be signed and unsigned types of 32bit variables. But a few of the latest chips are using a 40bit word. In such a case, we can simply get the 40bit integer from double precision. The objection that we would run out of memory is wrong because the code is stored in flash and usualy we use a limited number of variables. What is really consuming RAM are the strings (255bytes each). Regards |
||||
 Print this page |
