Intel Edison generic calculator shield photo journal

[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