Intel Edison generic calculator shield photo journal

[MarkHaysHarris777]

(03-23-2015 08:29 PM)matthiaspaul Wrote:  The Edison provides a compound processor with three cores, two Atoms running at 500 MHz and one Quark running at 100 MHz. One of them would be enough to accomplish the task.

Actually, there are two Atoms running @ 500 Mhz. The Quark, presumably 'running' @ 100 Mhz, is not active for anyone, yet. This is not a show-stopper, but it does represent a 'wrinkle'.

The RTOS (real time operating system) from Wind River (subsidiary of Intel) was supposed to be ready year-end 2014... it is called ViperOS and is apparently not ready even now. I've been active on the Intel site today and still don't have an answer; and I'm not the only one (as you might imagine) who is painfully interested.

We are noticing that there are several devices showing up /dev/ttymcu0, /dev/ttymcu1, /dev/ttymcu2 and who knows what that means exactly... but they're apparently getting ready. Why is this important? Glad you asked. Hardware timiing 'in real time' requires an MCU (similar to Arduino, Atmega328) which is *very* precise. A process running in the gnu/linux user space is NOT precise enough. Sketches running in the Intel Edison all run as a process in the normal user address space in yocto linux. For certain hardware related timing considerations this is not cool, and requires interrupt tricks to work out. Certainly, I'm a bit disappointed at this development. I am encouraged, however, that the MCU availability is coming... sometime.

On a more positive note, my Intel Edison (dual core Atom 500 Mhz) computed PI today accurate to 10,000+ digits ( using python3, pdeclib.py, pilib.py, and Decimal ) in one minute twenty-five seconds (1m25s). For comparison, my Raspberry PI b+ (single core Arm 400 Mhz) came in @ one minute fifty-eight seconds (1m58s), and my Raspberry PI 2B (quad core Arm 700 Mhz) came in @ one Minute twelve seconds (1m12s). So, the little Edison compute module is holding its own; not bad.

The Edison is also quite stable (has been running on the network uninterrupted for more than a week clicking away on its 'sketch' ) keeping yocto linux alive; so far doing very well, and better than I really expected from such a platform. Its impressive. Now, if I could just use its MCU !

Cheers,
marcus

[Paul Dale]

I completely fail to understand why real time is critical in a calculator. Wait for a button press, run as fast as is reasonable to get a result. The only timing based parts are power saving and the pause command and neither of these could be considered critical enough to warrant real time support. Perhaps the display and keyboard are timing based, but again they aren't critical -- nobody is going to notice a few hundredths of a second skew occasionally.

Sure device drivers need moderately accurate timing but the Linux kernel supplies this. If you are driving raw timing critical hardware in a user application, then I rather suspect you are doing something very wrong.

My experience with embedded Linux on a variety of platforms, much slower than the Edison, is that user programs have perfectly reasonable timing characteristics for most purposes. Not hard real time but usually good enough.


- Pauli

[MarkHaysHarris777]

(04-02-2015 04:11 AM)Paul Dale Wrote:  I completely fail to understand why real time is critical in a calculator. . . .

My experience with embedded Linux on a variety of platforms, much slower than the Edison, is that user programs have perfectly reasonable timing characteristics for most purposes. Not hard real time but usually good enough.

I hope you're right; your sentiments are at least encouraging. There are two areas that I'm interested in (one I've actually tested, so far) and the jury is still out. The first is the display.

I have three calculator projects all going at the same time... the Wang 700c replica... my Royal 'resurrection' machine, and the generic calculator shield for Edison | Arduino. In my Royal project (and the Wang project as well) where I'm going to use a dual 16 digit LED register, I want the MCU to refresh the display, as well scan the keyboard. I have already tested this in the Edison and in the Raspberry; and what happens is that as the kernel adjusts the time slices for the various running processes the display refresh 'sketch' process does not get an even-consistent running time---which causes the display to have a 'strobing' or 'throbbing' maybe even 'flickering' effect at times (which is very annoying) especially if the kernel (or other processes) gets very busy. If I can get the MCU to work then the MCU can keep the display refresh consistent as it works with the linux kernel through IPC. Same thing goes for the keyboard scan (although the effect is not nearly as noticeable).

The second activity that requires *very* precise timing is using the 'calculator' (even the generic calculator shield) as a scientific data gathering station. There are some sensors (like the temperature humidity sensor I'm playing with now) that spits its data out on 'one' (1) line. The MCU pulls the line low, then waits 50 ms and then starts 'reading' the data back on the same line at a particular 'baud' shifted rate (if you will) and if the timing is not perfect, well, you lose the data stream coming in from the sensor. An MCU can handle this, the Raspberry PI and Edison not so much (at least not under all conditions). Well, that's why Intel put the Quark on the Edison SoC in the first place! But, they failed to provide the OS with the release of the product... and then hoped nobody would notice... again, no so much.

Sorry for being a little grumpy. I'm gonna get over it by morning, promise.

(talk about a time for mulled wine)

Cheers,
marcus

[Paul Dale]

(04-02-2015 04:43 AM)MarkHaysHarris777 Wrote:  I hope you're right; your sentiments are at least encouraging.

I think you'll be surprised what is possible. As an example, at a previous job, we managed real time decode and playback of two MP3 streams under Linux on a 90MHz ColdFire processor. It consumed about 70% of the CPU but it worked and the audio didn't stutter or glitch. It was a lot of work and there were plenty of rather difficult to track bugs but it was possible. Moreover, the unit had a front panel with menu and was capable of downloading more music over the Internet -- again without glitching the music playback.

Quote:...I want the MCU to refresh the display, as well scan the keyboard. I have already tested this in the Edison and in the Raspberry; and what happens is that as the kernel adjusts the time slices for the various running processes the display refresh 'sketch' process does not get an even-consistent running time---which causes the display to have a 'strobing' or 'throbbing' maybe even 'flickering' effect at times (which is very annoying) especially if the kernel (or other processes) gets very busy.

Two thoughts here:

1. You could run the display refresh process at one of the high batch/real time priorities. These have the nice feature that they completely preempt any lower priority process and their timing is usually pretty good. The down side is if one of these locks up, there is nothing you can do.
2. Why are you using multiple processes in the first place Unix/Linux has good support for event driven programming and a single thread/process is usually better than lots of threads -- not when you want to exploit the parallelism but most of the rest of the time.
   

Quote:The second activity that requires *very* precise timing is using the 'calculator' (even the generic calculator shield) as a scientific data gathering station....

This is very different. This is hard real time. I somewhat suspected you were planning something like this when I responded before


- Pauli

[MarkHaysHarris777]

Greetings, ... still waiting on most of the blocks I ordered from Sparkfun; but the GPIO block came yesterday which has given me the opportunity to experiment with alternate power, and alternate GPIO configuration | access. The GPIO block expects either the battery block, or one of the console block(s) for power, so the GPIO block does not supply its own power:



The Edison requires a funky vSys power supply, because it is designed primarily to operate from a 4.4 volt lithium ion battery (a couple of the blocks have built-in chargers). vSys takes 3.15 to 4.5 (according to the hardware guide) and the mini breakout board takes the 9v down to 4.38v. I threw together a dual supply (7805 5v) and an (LM317T 4.3v); lower left. The GPIO block auto-level-shifts via solder jumper to either 3v3 or vSys... which makes it more like the RPi (at least from a GPIO standpoint); I'm still experimenting with the adafruit leveler.

The Intel SDK is minus Python support for the time being; so the options for development for yocto gnu/linux are C|C++ or Arduino IDE. Python is coming, probably in time for the MCU to be working.

The other option for the Intel Edison and Python is to dump yocto gnu/linux and install emutexlab's Ubilinux (debian variant) which not only supports Python, but also is a nicer all-around gnu/linux with package manager, and a host of other tools and goodies... the downside is that *more than a few* people have bricked their Edison doing the upgrade! (dumb user errors, of course, but I'm capable of those too... ) I think I'll wait on UbiLinux until my number two Edison gets here (I'll have one in each camp, and I can test in parallel that way).

Happy Easter Everyone!

Cheers,
marcus

[pito]

Nice heatsinks there at the voltage regulators
In case you would need more computational power (and bigger heatsinks):

[MarkHaysHarris777]

(04-03-2015 04:17 PM)pito Wrote:  Nice heatsinks there at the voltage regulators
In case you would need more computational power (and bigger heatsinks):

Yeah, unfortunately, without heat sinks I could fry a good voltage regulator. Well, the LM317T is only really designed to handle 500 mA. It will do 1.5 amp, with a large heat sink and a fan... not very efficient. As it is, the Edison is pulling 100-200 mA all the time and the 317 gets quite warm... my little aluminum fins keep things quite cool.

I saw the pic on-line (at Intel, I think)... very nice. I could not believe the author (you?) actually soldered directly to the Hirose connector(s)! Those will never plug into anything again. :-)) I liked the pic though... world's smallest Beowulf cluster !

marcus

PS I must report that my Edison started crashing this morning not long after updating my latest 'sketch' and also not long after I plugged 'er into the Sparkfun GPIO block. (rats)... about every 5 or ten minutes; afraid of corrupting the flash (if not already). So, I pulled it apart and found a fleck of dust in the Hirose connector! Blew it out with an air can, and reassembled it... been running ever since; couple of hours now. That Hirose connector is going to be the Achilles heel on this entire project, and on the entire Intel Edison venture, I'm afraid.

PPS I'm going to be experimenting with making my own breakout board, in preparation for making the generic calculator shield board... and I'm going to have to reflow a micro miniature 70pin Hirose connector to that board without any solder bridges and without an breaks and without any dust! Geeze.
I have a scope on order. I've never needed one before, because I'm extremely myopic; My own eyes at 10 cm is like most of you looking through a scope... But even I cannot see that Hirose connector without a scope.

Cheers,
marcus

[MarkHaysHarris777]

Greetings, my edison 'blocks' came from Sparkfun yesterday; so, I am finally able to read my 'highly unorthodox' analog keyboard with the Intel Edison. This came with several hours of investigation &research into the TI ADS1015 differential analog to digital converter employed on the Sparkfun ADC block. I am helping Danny in Tokyo setup this block, so I'm going to refer him to this site (photos explanation) from the Sparkfun forum as well; welcome Danny.

First, it is hopeless to attempt an analog read of the ADS1015 without understanding the datasheet particularly page(s) 15-16. It is also necessary to understand I2C protocol and Sparkfun has one of the best tutorials; see the link. First my hi-res pics, then comment as usual; Danny, click the pic to get a larger view:



Tonight I'm powering the Edison from the console block; as well communicating through the console block, from my Raspberry PI if you must know. The GPIO block is the base, and the ADC block is directly beneath the Edison. I mounted a header on my ADC, and have supplied a rainbow ribbon out to breadboard from the ADC block. I am going to use the ADC block to 'read' the analog keyboard (simple resistor voltage divider) select-able via push-button. The ADC block can be configured (see pages 15-16) to continuously scan (or just once) and to scan four analog inputs, or two analog differential inputs. Four boards may be stacked because each board has a soldered address (the default is 0x48). I am going to read Ain1; however, by changing the configuration register I can easily read any of the four inputs Ain0, Ain1, Ain2, or Ain3.

(Danny, you need not make my keyboard; just use a pot between 3v3 and gnd, attaching the wiper to Ain1, and 'read' the pot)
Also, I'm going to do everything from the terminal using gnu/linux tools on-board in the Edison, no need to install anything, and NO programming till you get things working: i2cdetect, i2cdump, i2cget, & i2cset.

First detect your board: (this is on i2c bus 1 (one) not 6 (not six)
i2cdetect -r -y 1
(it should show up on 0x48, if not something is wrong with your stack)
Next set the configuration register:
i2cset -y 1 0x48 1 0x8352 w
(I2C uses little-endian, so the config is really bits 0x5283, just be aware)
Now it is time to 'read' the Ain1 value, also little-endian:
i2cget -y 1 0x48 0 w
(I got back 0xe017, which is really 0x17e0)

The config value 0x5283 means continuous, 4v max, Ain1, non latching, no comparator... see datasheet

Ain0 = 0x4283
Ain1 = 0x5283
Ain2 = 0x6283
Ain3 = 0x7283

The second pic shows some sample reads from the analog keyboard on Ain1. There is very nice resolution, and with the I2C interface I can easily read 16 x four 35 button keyboards, if necessary.

I am still playing with both options (digital vs analog). The ADS1015 chip will make the analog reads easy, for instrumentation if for nothing else; else the analog keyboard is on the table again boys and girls!

Ps Danny, et al, I would make sure your ADC setup works from the terminal first, THEN move to coding this up in C|C++... words to the wise.

PPS Be VERY CAREFUL with the commands i2cset, i2cdump, i2cget, and i2cdetect. These commands are potentially VERY dangerous... read the man pages and double check your values.


Cheers,
marcus

[MarkHaysHarris777]

Greetings, this post is just an Edison development pointer; and update from a software engineering standpoint as it comes to developing for the Intel Edison... what I've learned, and how it might help you.

Everyone (and I do mean everyone) is miserably confused initially (and it does not depend on the board you're using) how to 'know' which GPIO pins match the real hardware physical pins and how those physical pins match the MRAA board pin assignments, and then finally what 'your particular board' decided to call those gpIO pins logically. Trust me, its a fit, and there are long lists of mapping tables to help everyone keep it all straight. The Edison makes this *all* even more confusing because the Edison has "four" (count them) breakout configurations which are *all* different! 1) mini breakout board from Intel, 2) Arduino breakout board with love from Italy, 3) the Intel Edison Hirose connector pin assignments, and finally 4) the Sparkfun GPIO 'block' breakout board.

It is very tempting, especially if you're an Arduino fanatic like me, to go to what 'you know' and work with the Edison in the Arduino IDE expanded in v1.6 to include the Edison board. Here's my first tip: drop the Arduino IDE, grow up and use a real development kit or compile your MRAA projects directly on the Edison (yes, you can do that!). The reason is simple: you will simplify the mraa mapping and you will be able to use the full compliment of 56 GPIO pins of the Edison including both I2C buses. Some of the Edison pins are not available within the Arduino IDE, and some of them require that you use the Arduino breakout board (which, as in my calculator use case, is often not possible).

Just to give some of you interested parties in an idea through a coding example I am providing a 'binary counter blinker' example tarball 'blinker.tar' which is a multi-file MRAA GPIO sample that is stand-alone, fully functional, and cleanly demarcates the mraa mapping stuff from the main logic, giving the bare minimum required to turn leds (or anything else) on and off.

The code is written for the Edison plugged into the Sparkfun GPIO 'block' and uses the eight gpIO lines on the north side of the card, gp44, gp45, gp46, gp47, gp48, gp49, gp15, & gp14. I have logically numbered them pin8 - pin1 respectively in my code, and I'm using pin1 and pin2 (which must be tied to HIGH via pullup resistors) as inputs, and pin3 - pin8 as binary register output pins.

The code is fairly straight-forward; its a binary counter. It updates its counter every 200 milliseconds and displays the counter on the binary register LEDs. The two inputs are in preparation for my interrupt driven keyboard, but are not really functional that way yet... one of them causes the counter to 'pause' for five seconds, and the other one (if read at the top of the count) causes the routine to blow out and exit.

I am running the example as a 'sketch,' as root, and I have built the code entirely ON the Edison itself; nothing extra, no other installation packages, and no other tools... just gcc at the command line. I have included a 'build' text file (rather than make) that can be used to call gcc; otherwise it will give you an idea of what is required; for instance remembering to pass the linker -lmraa or the thing won't compile ever!

My I2C sample will be coming shortly. The GPIO and I2C samples are the minimum for the Edison becoming a calculator with LCD display capabilities and analog keyboard and data-gathering capabilities.

One thing I've noticed, in closing, is that the IDE environments (Arduino and Intel's SDK on Eclipse Kepler) is that their builds are enormous, often initially close to or exceeding 100K, even for hello world complexity. The command line builds (whether on the PC or on the Edison directly) are much smaller, tighter, and faster. This sample compiles in just over 10K at the Edison command line.

Cheers,
marcus

[MarkHaysHarris777]

Greetings, I was surprised to find many of the development tools included on the embedded gnu/linux yocto system on the Intel Edison, including automake, libtool, ncurses5dev, make, and others... I was able to download the htop sources from github and complete a flawless build ON the Edison itself. For those not in the know, htop is 'top' on steroids! Once you use it, you'll be crippled without it; its easily installed from repositories on the Raspberry PI, but on the Edison most everything needs to be built from sources; worked like a champ!

Cheers,
marcus

[MarkHaysHarris777]

Greetings, I have the analog keyboard running well on the Edison with some minor mods to the keyboard design to make the keyboard hardware more reliable, and to make the interrupt routine simpler (taking Matthias' comments to heart, it worked well). You can see the Fritzing of the bread-board on the Generic blog|forum.
Here I am going to high-light what's going on with the Edison; gpio is solid, and now the reads from the ADC (analog) block via i2c are working flawlessly. The big change to the keyboard design was the addition of a 555 one-shot timer circuit, to smooth out the contact bounce on the interrupt line which also vastly simplifies the interrupt handler; I've attached the new codes below which have all the i2c stuff in place. keep in mind the codes are just proof of concept and not intended to represent anything finished.



I moved the setup() routine to the main blinker.c file. Most of what is interesting from an i2c standpoint is there... the rest is in the interrupt handler.
The i2c part of the MRAA library is a mess... no disparagement, just fact. Most of the API is still missing... the routines mraa_i2c_read_word_data() and others similar. You have to write to the register (like 0) before you can read from it... the mraa_i2c_read() reads from the LAST register written to... uhg. The endianess of i2c is confusing (and its backwards from the command line tools). Needless to say, it took a while to get what I thought I understood about i2c to actually work on the Edison ADC in C... but, yesssss, its now working (and it works very well, thank you).

All four keyboard analog lines share the same LM339 chip (four comparators one for each line) and the comparators are wired OR to pin 2 of the 555 timer one-shot. The 555 produces a very nice clean sharp hysteresis for the Edison's interrupt system... the rising edge works very well... and the keyboard is flawless... even with wires laying loose all over the desk, as you can see.

I thought I would have the Due actually calculating first, but clearly the Edison is going to win out there, for sure. The first pcb design is under way, and as always I have parts on order.

Cheers,
marcus

[MarkHaysHarris777]

(03-27-2015 09:39 AM)JKB Wrote:  Have you tried to build RPL/2 ? I have seen that it runs fine on raspberry PI and some other SoC but I don't have any Edison SoC to test.

I have not been able to get the 'configure' tool to complete successfully; and I don't have an answer yet from RPL/2. I'm getting that bogus error that 'C compiler cannot create executables' from 'configure' for several tools like gnuplot, ncurses, etc. Everything is there and 'should' work, but it doesn't. So, I'm going to post a query on RPL/2 mailing list.

The good news is that I built the entire gcc compiler (enabling c, c++, gfortran) with MPFR, MPC, and GMP in eight hours forty minutes-- ON the Edison! I used the 'SD Card' Spark block (8 gig SD) and partitioned it for /opt, /usr/local, and /home. (works great) I've tested the compiler, and built several of the gnu tools from sources with it (no errors) but... I cannot get the RPL/2 sources to configure. rats.

I'm not giving up; but I'm not putting a real high priority on it either. I need to keep focused on the real project which is producing a collaborative calculator from an postage sized embedded gnu/linux system on a Spark block!

I'll keep you posted on whether the RPL/2 folks have any input on my compile errors. On the other hand, as much of a mess as RPL/2 is, we can probably write our own and make it actually work faster. I am noticing that there are lots of build problems on the net regarding RPL/2; so it may end up being a dead stick.

Cheers,
marcus

[BarryMead]

Mark: I was wondering if you have attempted to build any of the decNumber library stuff on the Edison?
Since it is at the very core of the WP-34s and other open source calculator offerings, I assume that you plan on building your Edison Calculator around these floating point number libraries. You could, of course, use other
floating point libraries, but they may not be as code size compact as the decNumber libraries. What are your thoughts on number handling and libraries in your design?

[Thomas Klemm]

(03-27-2015 09:39 AM)JKB Wrote:  Have you tried to build RPL/2 ? I have seen that it runs fine on raspberry PI (...)

Instructions for installing RPL/2 on the Raspberry Pi


Kind regards
Thomas

[MarkHaysHarris777]

(04-12-2015 03:31 AM)Thomas Klemm Wrote:  
Instructions for installing RPL/2 on the Raspberry Pi

Thanks Thomas! I am actually doing almost precisely what you have detailed with a couple of exceptions; I was trying to install 4.1.20... and at some point they went to autogen.sh to create configure. Hence:
./autogen.sh
.configure <with options>
make
make install <as root>
I have all of the prereqs you listed except libxt/ I have bison (yacc), flex, gfortran &c. Of course the Intel Edison does not have an X11 interface (hoping to use ncurses, since its supported) and the most frustrating thing is that before it tells me the compiler does not work it uses the compiler extensively to check out the compiler functions!
What I suspect is that there is a setting (I've already checked -m32 and -m64) that is forcing the compiler to generate cross compilation for a toolchain not on the Edison; I just can't find it if its there. The 'configure' runs forever (looking great by the way) and just before its almost done it throws up its hands with 'C compiler cannot create executables' for tools/gnuplot! What is really hilarious about that is that I actually used the 'same' compiler to build gnuplot from sources without any errors earlier today AND I've told the configure program to --disable-embedded-gnuplot!

<sigh>
PS ... I mean, it may be that if the X stuff is not there, its not going to run; which would be short sighted for the RPL/2 people to assume that RPL needs an X11 interface! Of course, there is no reason we cannot give the Edison an X11 'virtual' interface and access it via VNC! ... aah more things to add to the list;

Cheers,
marcus

[MarkHaysHarris777]

(04-12-2015 03:20 AM)BarryMead Wrote:  Mark: I was wondering if you have attempted to build any of the decNumber library stuff on the Edison?
Since it is at the very core of the WP-34s and other open source calculator offerings . . .

hi Barry, not yet. There are several really good packages (MPFR, MPC, and GMP some of the best) on the front burner... not to mention Python's Decimal. I am planning on comparing the decNumber <sp?> library with the others, of course. What I'm interested in primarily is fast (very fast, say Fast Fourier Transform, FFT) for multiplication at least, but I'm also very interested in arbitrary precision. I want the user to be able to 'select' the intermediate precision register(s) length! --similar to WP34s Double, but without limits (within practical reason). You ought to be able (for whatever reason you dream up) to work a calculation like sqrt(2) to 500 decimal places and scroll left and right on the result; even though no calculator at this time does that... well, except our PCs of course, and my phone!

Cheers,
marcus

[koendv]

I can understand you being excited about the Intel Edison, but for a calculator I would want something somewhat smaller. Have you taken a look at micropython? It's a small Arm microcontroller which runs Python (Duh). Take a look at this video or go to http://micropython.org and play with a real, live board. You could even download the micropython source, and compile it on your Edison.

[MarkHaysHarris777]

(04-12-2015 06:33 PM)koendv Wrote:  . . . for a calculator I would want something somewhat smaller. Have you taken a look at micropython?

Yes. Its on my back-burner, so to speak, and I don't have one yet to evaluate. It will not handle what I have planned for the Edison, I'm afraid; however, it is particularly suited as a science-station peripheral controller. I am particularly impressed with its ADC / DAC and the work that has gone into the Python classes to control the real-world connections. The timers are fabulous, and the board has a small form factor; however, by the time you add headers its really not as small as it first appears.
My calculator 'board' is going to have the keybuttons surface mounted (along with support chips and LCD) front side, and the Edison Hirose connector and lithium bats backside. It should all fit in a case the size of the HP35s maybe slightly larger (but not much).
The next edition of the Edison firmware will support the MCU on-board, and its Linux SoC is truly an OS with dual core 500Mhz / pretty unbeatable ; I have not seen anything yet that tops it.
I think the Py-Board is going to give the Arduino folks a run for their money for sure... and I am going to consider using it as a peripheral controller.

Cheers,
marcus

[Claudio L.]

(04-12-2015 06:01 AM)MarkHaysHarris777 Wrote:  There are several really good packages (MPFR, MPC, and GMP some of the best) on the front burner... not to mention Python's Decimal. I am planning on comparing the decNumber <sp?> library with the others, of course. What I'm interested in primarily is fast (very fast, say Fast Fourier Transform, FFT) for multiplication at least, but I'm also very interested in arbitrary precision. I want the user to be able to 'select' the intermediate precision register(s) length! --similar to WP34s Double, but without limits (within practical reason). You ought to be able (for whatever reason you dream up) to work a calculation like sqrt(2) to 500 decimal places and scroll left and right on the result; even though no calculator at this time does that... well, except our PCs of course, and my phone!

It seems you are going through the same path I walked last year, so here are a few things that I found out:
* MPFR, MPC and GMP: These are all binary, not decimal floating point (you may or may not care about the difference). They are FAST, and huge. But that's the fastest you'll ever find.
* Python's Decimal (the new implementation for Python 3, which was released as an independent library: search for libmpdec) was the best choice for my project. It's very small compared to others. Much faster than decNumber (or so they claim, I haven't tested it), but some of the advanced algorithms suffer in performance (like LN, POW), since they are not based on tables, they can become slow at higher precisions. It's the price to pay for the smaller footprint. If you are interested in multiplication mainly, it's a good contender and small enough.
* Intel Decimal library: This one is x86 only, so it wasn't a choice for my project (some people manage to make it work on ARM, but I don't think it passes all tests). Since it's optimized for x86, porting to ARM you can be sure that any speed advantages will vanish. It has some large tables, so it's also big. Supposed to be very fast but I didn't test it. EDIT: Forgot to mention this one is not true variable precision, only 32,64 and 128 bits, unlike all others.
* decNumber: good old standards compliant. Probably not as quick as others but reliable, portable and small.

On the Edison, you can probably afford GMP and family, or the Intel library and that should be your first choice for speed (you have plenty of ram, so footprint on the Edison is not a concern).
But if you are planning on other projects with more humble processors too, I'd go for libmpdec, it's more portable (as a consequence of not being so highly optimized) and smaller footprint.

Claudio

[Paul Dale]

(04-12-2015 09:48 PM)Claudio L. Wrote:  Intel Decimal library: This one is x86 only, so it wasn't a choice for my project (some people manage to make it work on ARM, but I don't think it passes all tests). Since it's optimized for x86, porting to ARM you can be sure that any speed advantages will vanish. It has some large tables, so it's also big. Supposed to be very fast but I didn't test it. EDIT: Forgot to mention this one is not true variable precision, only 32,64 and 128 bits, unlike all others.

This one also requires a binary floating point library to be present as well. It uses binary functions to provide initial estimates for the decimal versions in places.

This would be my pick for a device that wasn't arbitrary precision and based on the x86 architecture.


For ARM there is another choice which would be worthy of serious consideration: mathematica. It's free for the Raspberry Pi, does arbitrary precision, does algebraic manipulations and supports the widest range of functions you could imagine all accurately and usually quickly.


Pauli