NETMF is made for very small devices so why would anyone need intensive mathematical calculations? What is there is perfect for where NETMF is meant to be used.
Ofcourse you can always make your own functions but those will not be very fast.
What kind of product you are making that is small enough to run NETMF but you still need “very accurate math”?
Just out of curiosity, can you give me an example function that you will need but that function is no implemented in NETMF nor it is available in the exMath library you found?
Are you aware of any library that has everything you need (c/c++/c#)
High resolution as double including pi and conversion from angle to radian. The calculations involve several of the trig functions in a single calculation so round off error needs to be minimized.
The exMath library is OK, it’s the resolution that suffers.
When you say exMath is not very accurate? what do you base that on? how inaccurate is it? and what are the math functions available out of the box with the Microsoft micro framework? thank you.
Well, I ran a test between the exMath and the standard .NET (not uFramework .NET) math library - The result is that the exMath generated errors in divide when certain trig functions were called. The standard .NET library did not generate these errors and provided the correct result.
In some cases the exMath may work well, but in others it does not.
I sent an email to Colin at Microsoft, but his response was they didn’t think a decent math library for uFramework was needed because of limited resources of memory, etc. However, my point is that if the 8 bit PIC microcontrollers with way less resources than the 32 bit ARM, have a decent foating point math library, then so can the ARM running MF.
" they didn’t think a decent math library for uFramework was needed because of limited resources of memory, etc"
That’s a ridiculous answer. Of course a good basic math library is needed, something that customers can select for their projects or not. Whether it’s GPS, motion detection, robot balancing, etc these functions are essential. Your point about 8 bit microcontrollers doing it and not MicroFramework is an excellent one. These Microsoft guys need to listen to their customers and then deliver.
What Microsoft provide is general to everyone. Nothing specific. It is our (GHI) job to customize it to fit our customers needs. I think Microsoft is doing a great job…like VS2010 support is far more important than a math library at this point.
We have already looked into implementing an extended math libraries but not sure of when or how this will be added to our firmware.
Actually, I think Microsoft is just being lazy because they know the current .NET math library is too large for MF and they don’t want to spend the time to reduce it. It could certainly be done. I think there a potentially many MF projects where a decent math library would make the difference between having a great application (software & hardware) vs. one that never gets off the ground!
If we add something in future it will be “float” accurate not “double” I think. It will be nice to be as accurate as possible but then you start reducing the performance to the point that the processor is busy just doing math and nothing else.
If “double” or more is needed then I guess using a math co-processor would be an option.
Adding a fuller math library is a memory issue, for apps that need the functionality. With regard to double vs float, overloaded functions that handle both data types can force the performance pernaly only on apps that require high precision. Again, it boils down to memory .
Supporting double + float means having double the libraries. On an embedded system, the less the better. We could alway use any extra memory here or there.
If we had float or single that worked well, that would allow a lot more flexibility than what exists today.
Ultimately double would provide greater resolution - but the existing MF may have to be beefed up a bit, but it will as technology advances very quickly with microprocessors. Today we have the 72MHz ARM with limited flash and RAM. I suspect we will have the resources doubled in a year making a math library with double precision feasible.
I have looked into a FP coprocessor, but the MF needs a way to send each byte (4) of a 32 bit float as an IEE754 format too.