 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 : uMiteII and uM-FPU64 CoProcessor
Page 1 of 2   |
|||||
| Author | Message | ||||
redrok Senior Member  Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi All; Is there any example code for operating the uM-FPU Math CoProcessor by MicroMega? redrok |
||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
If you look at the pinouts it is just a PIC32MX1xx processor but then using the double precision datatype. It will not be fast as a real FPU. Their claim for precise GPS is also a bit much. Single precision and even 32 bit integers are sufficient if you are not measuring in centimeters. Most GPS modules are only precise up to the fifth decimal place anyway so 7 digits precision in a single precision float is good enough in most cases. With the uMite now supporting 64 bit integers you could just scale all numbers by 1.000.000 or more to get enough precision. It has some extra capabilities that can be useful but in my opinion nothing spectacular. Microblocks. Build with logic. |
||||
| redrok Senior Member Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi TZAdvantage; I'm well aware of this. My interests are in the IEEE-754 64 bit floating point trigonometric functions they claim to have. I guess I will see. I'm want high precision astronomy calculations that implement the full "Solar Equation of Time" equations. The end result is finding the AZimuth and ALTitude of the sun over many years, at least for a century or so. These calculations are quite involved and need more precision than the single precision our MMBasic has. (Oh if we had the double precision that was in the old GWBasic.) I want to drive a solar heliostat that can send light at least 100' and keep it on target to an inch or so. Here is an example of what I want to do:QBASIC program by Keith Burnett And even higher precision codes:Astronomical Almanac by Stephen L. Moshier These equations take into account the several variations in the Earth's orbit around the sun. Orbital Magnitude, length of the year. Orbital Elongation, change of solar distance at apogee and perigee. Orbital Precession, movement of the celestial pole. And others. Some of these motions are small and move slowly, but some are surprisingly large. I understand fully. After the main calculation is done, simple single precision trig does nicely for moving the mechanics. I started to work on CORDIC algorithms for the trig functions. However, that is probably well beyond my feeble software capabilities. Anyway, I am just looking for someone that has driven the uM-FPU64 through the I2C bus. I have it mounted on my plug board. First thing is to get the serial monitor/programmer running, then the I2C commands from the uMite. redrok |
||||
| cdeagle Senior Member Joined: 22/06/2014 Location: United StatesPosts: 261 |
The following is the link to my website which demonstrates the types of calculations and algorithms required for precision astronomical work. There are programs in QuickBASIC, Fortran and MATLAB, including classic algorithms such as Simon Newcomb's ephemeris, and more modern algorithms like the JPL Development Ephemeris. Orbital and Celestial Mechanics Website |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
I am a bit puzzled, the pinouts are the same but they claim a 12-bit A/D (?). The pic32's all have 10-bit a/ds I think. Heres a thought - use elctride via serial .. currently the serial is running at 115kbaud without errors. |
||||
| redrok Senior Member Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi cronic; Actually the uM-FPU64 uses the PIC24HJ64GP202 which has 12bit A/D.What's an "elctride"? redrok |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
an interesting idea would be to use 64-bit integers purely as '8-byte containers' to hold 8-byte reals, with a set of custom functions written to manipulate the contents. cordic and similar algorithms are well documented these days, and if someone were keen could be translated into a usable form. custom functions could be written to add, subtract, multiply, divide, perform transcendentals and inverses, etc. lastly, have a couple of functions that performed string -> 8-byte and 8-byte -> string. with a comprehensive set of scientific functions available, a micromite could also be used to create a pretty neat pocket scientific calculator. now that would be a killer application! cheers, rob :-) |
||||
| redrok Senior Member Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi Robert;Or, That container could hold 16 decimal nibbles. redrok |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
I typo'd !! The earlier version of electride : (a doc complete with writing errors) http://www.thebackshed.com/forum/forumposts.asp?TID=7276&KW=electride My apologies for a fairly basic writeup though. The newer version is better and has exponent notation- Send me a pm if you are interested further. WRT to using containers, that is roughly how most interpreters work already. The effort involved in recreating maths libraries is recreating the wheel in a massive way...you would be better to rewrite MMbasic to use datatypes the standard way, and that would open the way to use the basic programs used world wide. My I,pression is, the mmbasic users do not want extensive accuracy anyway. "Scientific" calculators are a few dollars each ... Maybe use the NOAA site to generate a table and use that ? |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
most professionals who want a good scientific calculator have never heard of mmbasic - being surveyors, scientists, engineers. for may of these people they want quite a specific instrument (a scientific tool) who's precision and quality goes well beyond what most existing calculators provide. hence the popularity of the likes of the HP-15C and similar tools of that era, where the algorithms inside are engineered to a standard that well exceeds that of the average C compiler. it is just a suggestion. mmbasic would provide an ideal software platform to build the user interface on, allowing for a good degree of customization. a set of C functions, well written, would provide the backing algorithms. and the micromite hardware would allow for a good compromise of power-consumption for a handheld device using 2x AAA cells. UI would be through a simple matrix keyboard and off-the-shelf LCD module. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
Not meaning to cause offence but you ought not to say things about C without knowing about it. That statement is just plain wrong. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
which part do you believe is wrong? that HP calculator division numeric algorithms of the 80's were highly engineered to what many regard as a superior standard? that scientists want a quality that exceeds the average calculator? that many C compilers have subtle/latent bugs that may degrade numeric performance? bearing in mind that we are talking about compilers that implement their own algorithms, as opposed to just making use of an intel numeric coprocessor. on the modern PC platform one is pretty much guaranteed to have access to such a coprocessor. but then a PC makes a poor pocket calculator unless you have really big pockets. i did a quick google search on microchip's C32 and numeric precision to see what odds and ends there were. there were plenty of odds and ends that raised an eyebrow, and few hard facts regarding the quality of numeric results. rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
The HP had 10 digits precision I think and almost every C compiler has as many or more available - and they generally do work. C32 from Mchp might be an exception although I actually doubt it. Most reports of bugs are themselves a failure to know C. OTOH, Mchp is a pretty useless company in so many ways that I'd be happy to believe they can't get C right either. If they'd stick to what they ARE good at and stop spreading themselves too thin and doing stuff they're bad at, all their customers would benefit. I've used a LOT of C compilers over many years and had very few problems with properly-written C. I've also used a lot of uC chips and had far MORE problems with bad datasheets, bugs in silicon and so on. Gimme a C compiler any day! I've certainly met compilers from silicon makers who simply do not understand that C is defined with certain features and have created a so-called C compiler that doesn't conform to any standard and the best to do is dump such a compiler and use another. This hasn't for me been an actual problem in practice as I commonly use Linux, before that UNIX, and their C compilers are pretty good. I use them as cross-compilers all the time. It would help of course if silicon makers took standards seriously not just for C compilers but also for floating point. Using IEEE754 would be OK I think. In the case of MMBasic Geoff apparently decided against using doubles, I guess for speed & size issues and bearing in mind what he thought would be the usage of MMBasic, so you get only what single precision floats provide. Anyone wanting more might perhaps get the code and change it to use double rather than float. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
the number of digits is a rather peripheral issue. the trick is ensuring that for every single possible input value to a function, every single digit in the output is exactly correct - right down to the very last digit. ensuring this level of precision in the algorithms is surprisingly difficult to do, but is nonetheless quite essential for a scientific instrument. an added level of complexity - i am talking about decimal digits above, not binary digits. http://en.wikipedia.org/wiki/Hewlett-Packard_Voyager_series i do suspect you many be missing my point: that to create something that is able to be used as a 'calculator constructor kit', it may be necessary to implement one's own mathematical algorithms in order to have sufficient control over the quality of the numeric results. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
It's an odd point and no I didn't realise that was what you meant. I can't see why you pointed to C. Fortran or Basic or python or whatever - they would all be awkward for your specific statement. C would be better than all except maybe Fortran but if you wanted to get 10 digits in all cases you'd be wise to choose a CPU which helps. If you were to choose a typical low end uC it would be a fairly silly thing to do that and use any language - you'd be choosing to make life hard by using that low end uC. However, choosing a decent floating point implementation, such as IEEE754 as done by Intel, C ought to be OK even for what you apparently meant. In my experience too many people misused HP and other calculators because they've done no error analysis and/or have relied on the apparent number of digits, not realising that the number of junk ones grows - sometimes rapidly. Even the HP calculators are hamstrung by the inherent behaviour of floating point and I have been disappointed to find almost no scientists and engineers have any clue about that. (On asking, some recall error analysis but have not used it. I've yet to ask & find someone who understands floating point.) The good news is that most of the time C is good enough and so are calculators. John --- To flesh the low end uC part out for any interested: In essence C tends to get whatever the chip(s) provide, or else some libraries emulating floating point - and if done by emulation it's slow so the implementors tend to go for about the least precision etc they can (i.e. as allowed by the C standards) so that it's merely very slow and big memory needs rather than excruciatingly slow and huge memory needs. None of this is any detriment to C. It's just reality that choosing a cheap low end chip has knock on consequences. Those apply to all languages, worse to some. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
i'd strongly disagree. while early calculators used processors that were designed to work in BCD directly, that was a necessity of the limited resources available at the time. today's MX170 (for example) runs at approaching 1000x the speed of the early calculator chips, so can afford to implement a BCD format in software. similarly, memory is plentiful and current consumption is small, further removing historic constraints. IEEE754 provides a number of formats, 'decimal64' seems an obvious choice provided the overhead of packing and unpacking is not too excessive. however, choice of format is an arbitrary decision in may regards, that should be driven by ease of implementing the required set of functions (primarily, the transcendentals). after all, the code does not need to be highly transportable, just transparent and open to audit. as for error analysis of whole calculations - that is an operator problem, not something that the tool needs to be concerned with. lack of analysis (ie, lack of operator care) is no excuse for suggesting the provision of a suboptimal tool as some sort of punishment. HP calculators have been popular through the decades because of the algorithms inside. this is why an original HP-15C (or HP-42S) can sell for up to us$500 to someone who is a non-collector. my original point was that the micromite, with some well-designed custom functions added to handle the manipulation of BCD FP data (carried in 8-byte integer 'containers') would make a mightily fine 'calculator constructor kit'. this would be a new and novel application of a micromite that i believe has not been considered thus far. an application to which the micromite is well suited. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
That reads like you think BCD FP doesn't have the same problems! John |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Surely laptops, tablets, even mobile phone apps have supplanted calculators in general ? Sure creating a calculator construction kit would be a thorough exercise but the chances are that for portable calculating, a generic device running software will be used rather than a calculator. Epson scientific calculator at Office works - : $21 Now that JavaScript uses double precision : Google Pendo 7 inch tablet , touchscreen, wifi, usb : $39 (Coles) Sure the tablets etc will be slow as they are bogged down with interface etc but the point is they will be used as front ends to remote servers. You see where things are going. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
there are those who believe that the smart phone (or similar device) is the ultimate device/solution and will replace all other similar-sized devices. your smart phone will turn on the ignition of your car, unlock the front door of your house, control your TV, etc, etc. in the future the only thing people will carry with them is their smart phone. but there are also those folks who believe that the above is excessively simplistic - that dedicated tools may provide a superior solution in specific situations. a piece of milled metal (a key) provides a superior way to control access to your car and home, a box with dozens of rubber buttons serves as a better solution to controlling your TV. they believe that while a smart phone (or similar device) can do many things, the general-purpose nature of the device means that it does many things poorly. in the end it comes down to personal preference. there are certainly many millions of people out there in professional positions who prefer their calculators to have nice clicky keys, a non-colour non-backlit LCD, and batteries that last for a long long time. while millions of others are happy with 'virtual buttons' on a smart phone. personally, as an engineer, i like my calculators to be clicky, a hardware solution that designed for the specific job. cheers, rob :-) |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
At the risk of restarting the fire !! I collect "vintage" HP calculators, the Voyager series, the RPN only ones and as a piece of kit they have a really lovely feel and solidity about them. The batteries last for years and years, and yes JohnS, they display 10 digits with an 11th guard digit I understand. I've got an example of every vintage Voyager produced by the old HP in my collection. I also have a HP35s which displays to 12 digits with I guess a 13th guard digit. Great bits of nostalgia, but then again I also collect Cold War era communications receivers, eg Racal RA1792, Collins HF2050, so maybe I just like good old fashioned heavy duty money-was-no-object design 
I must admit that for everyday use I just fire up Excel or Calc.exe on Windows Excel seems to give about 16 digits ! and one has to assume that given how important Excel is in all kinds of fields especially money/bonds/equities, scientific work, statistics and so on, the algorithms must be truly top class (Intel's expertise really) or Intel would have been laughed out of court a long time ago - so I tend to assume that the Intel FPU (and there are probably more Intel FPUs in the wild than anybody elses) is probably the gold standard against which others should be measured. Being involved with the ARM port of MMBasic, and given just how much Flash memory the ST ARM chips have, eg the STM32F4Discovery board for about GBP 12-75 has 1 Mbyte of Flash and h/w Single FPU, it's obviously tempting to introduce Doubles into MMBasic - No issue for the ST ARM chips, bags of space, very high clock rates, but then we'd be in danger of ending up with another version of MMBasic which causes support problems. Personally for just about all embedded applications 64 bit signed integers (18~19 digits) should be more than adequate given the cost/power/size/performance trade-offs. I understand that for astronomical applications, there is a need for really high precision calculations, but I would venture to suggest that the embedded astronomical application space is not a major target for MCUs, and perhaps low-end mini-ITX/pico-itx boards running i386 CPUs under LINUX/Windows might be a better fit - or of course a Raspberry PI 2 running Linux with GCC compiler etc !! JohnS over to you especially on that last point re RasPI+GCC in particular ! BTW, JohnS was the person a long time ago - back in MMBasic 4.5 land who helped me understand how floating point algorithms were implemented helping me to create the arbitrary precision (up to 252 digit integer) maths library for MMBasic 4.5, http://www.g8jcf.dyndns.org/mmbasic/index.html so I would always bow to his superior experience and knowledge in this area. It might be interesting to rewrite that library using V4.6 64 bit integers for even greater precision and speed - incidentally, if I recall, that lib was basically a BCD lib using single floating point vars as containers - seems like an age ago. Peter The only Konstant is Change |
||||
| Page 1 of 2 |
|||||
 Print this page |
