Raspberry PI - something for us?

[Geir Isene]

Could the newly released Raspberry PI be something we could build upon? A quick way for an overpowered HP-41, perhaps?

[Bruce Bergman]

It's cheaper than just about any other platform right now. I got one on the first order group last week, so hopefully it will pan out to be worthwhile! The last thing I did is an RPN calculator for my TV, but it might be fun! :-)

[Geir Isene]

Well - how about hooking it up to a small LCD screen, add a keyboard, battery...

[Eric Smith]

The Raspberry Pi is an interesting device and I'll probably use one for other things, but not for a calculator. It uses too much power to have decent battery life from disposable cells. Even with a rechargeable lithium polymer battery, the battery life will be quite limited.

The DIY4X design that Richard and I have been working on uses electronics that should cost less than the Raspberry Pi, except for the display and keyboard (which obviously the Raspberry Pi does not include). The DIY4X display is by far the most expensive part.

The DIY4X processor is an ARM Cortex-M3 running at up to 48 MHz, but typically 14 MHz. The latest version, which is just being installed on a board today, has 1MB of flash and 128KB of RAM. That's nowhere near as powerful as the Raspberry Pi, which has a 700 MHz ARM11JZFS and 256MB of RAM. However, the DIY4X uses about 30mW vs. the Raspberry Pi uses 3.5W for the currently shipping Model B, and 2.5W for the not-yet-available Model A.

The main disadvantage of the DIY4X compare to Raspberry Pi is that there are exactly 3 DIY4X units in existence today, vs. thousands of Raspberry Pi units, with more on the way soon. However, if anyone is serious about wanting to do calculator development using a DIY4X or DIY5 platform, they should contact us, as we can make more. The cost will be more than $35, but it is (IMNSHO) a much more suitable calculator platform.

[Paul Dale]

I'm tempted :-)

- Pauli

[Marcus von Cube, Germany]

WP (or whatever) 43S? Maybe even 43G?

[Paul Dale]

So we've got to decide between the WP 13S based on the 15cc hardware and the 43S or 43G based on the DIY RPN hardware :-)

- Pauli

[Ángel Martin]

There's no doubt in my mind: use the DIY-based design!!

Please?

[Massimo Gnerucci (Italy)]

43S, 43S, 43S!!!

:-)

[Jeff O.]

Quote:

---

So we've got to decide between the WP 13S based on the 15cc hardware…

---

I presume that the smiley at the end of the sentence means that you are not actually considering development of a "WP 13S", correct? My impression has been that you did not consider the 15c LE (or 12c+) platform to be a viable development platform due to its display limitations.

edit - per Marcus' message, WP 13S would be for the the DM-15cc, not the 15c LE or 12c+.

Edited: 7 Mar 2012, 1:22 p.m. after one or more responses were posted

[Marcus von Cube, Germany]

Jeff, the 15cc mentioned in the previous post is not the LE. Its main advantage: It has a dot matrix display which would allow the 34s menu/catalogue system to be ported over. Programming with key codes is out of question.

[uhmgawa]

Quote:

---

Jeff, the 15cc mentioned in the previous post is not the LE. Its main advantage: It has a dot matrix display which would allow the 34s menu/catalogue system to be ported over.

---

Regrettably the fundamental limitation of the LPC1114 is
that of a 32KB flash. Otherwise it really isn't a bad ARM SoC.
Quiescent power-down current draw when retaining RWM data
is rather high but tolerable. And the 8KB of RWM is a little
tight though not a deal breaker. The dirt cheap cost of
the part (< US$1.39) was likely chosen to help offset these
limitations.

I'd considered pushing non-executable data to a secondary SPI
flash/eeprom. Although the LPC1114 does not provide a DMA
driven SPI, it does have fifos which could provide sufficient
concurrency for a SPI data fetch concurrent with the cpu. I
suspect this could work reasonably well for an emulator (or
keystroke interpreter) application where the next instruction
could be speculatively fetched using the fifos to feed the
outgoing command and receive the incoming instruction read
without cpu intervention during the current emulation cycle.
SPI addressing schemes inflict lowest overhead for sequential
monotonic reads. If short loops of high iteration count are
found to substantially defeat this optimization, it is also
possible to cache data in RWM, tweaking cache size, number,
and indexing scheme relative to the application fetch
behaviour. Interesting experimentation if you have the time
but after a bit I just caved in and switched to a SoC with
a larger flash.

Quote:

---

Programming with key codes is out of question.

---

Yea. Aside from some sort of historical reverence for a
well thought out user interface hammered into 7 segments,
I don't see the reward for suffering with that limitation.

[Marcus von Cube, Germany]

I'm sure, WP 34S will not fit into 32KB of ROM. 8KB of RAM is better than what we have now but the base routines alone easily make up 3/4 of the firmware image. The rest is keystroke programs which might be fetched from an external device without performance issues.

[Paul Dale]

The 15cc is supposed to have pads for a large serial flash device. It should be possible to do the 34S core in 32kb and have lots of keystroke programs for the remaining functionality in the serial flash.

We'd have to move the keyboard decoder and the display code into the serial flash which would be a large undertaking -- these two are a large portion of the firmware. Then the remaining higher maths functions and we might fit.

- Pauli

[uhmgawa]

Quote:

---

The 15cc is supposed to have pads for a large serial flash device. It should be possible to do the 34S core in 32kb and have lots of keystroke programs for the remaining functionality in the serial flash.

---

The concurrent read rate out of SPI flash relative to the
interpretation/emulation cycle is the question. For the
LPC1114 think it should be possible to logically kick off
a 1~3 byte SPI prefetch at the head of the current processing
cycle given the 8 byte fifos for in/out, and have the data
waiting at cycle end if concurrent with under 100 ARM instruction
cycles. The maximum SPI clock rate derives from the system
clock and tops out around 20MHz. There is also a potential
limitation relative to the particular SPI device clock limit with
possible derating relative to lowest anticipated flash VDD. Depending on device density an additional 8 cycle addressing overhead may come into play between a device <= 64KB and
densities beyond. Best case if you can clock the SPI
sufficiently fast it may be possible to parallel a full
random address cycle which would dispense with branching, etc..
breaking an intended burst cycle optimization.

Yet another concern I had was of holding the SPI device in a
suspended burst cycle sequence between accesses in order to
dispense with the full overhead of random re-addressing.
I have some suspicion doing so results in greater idle power
consumption relative to deselecting the device. If a
true problem, caching may eek back in as solution.

Quote:

---

We'd have to move the keyboard decoder and the display code into the serial flash which would be a large undertaking -- these two are a large portion of the firmware. Then the remaining higher maths functions and we might fit.

---

I'd been expecting NXP to drop a more suitable SoC into the
dizzying array of permutations already advertised in the
LPC ARM product matrix. But currently the lpc1114 seems
to be the closest overall semi-fitting candidate as the more
upscale variations introduce so much architectural bloat,
power consumption (active and standby) go through the roof.

[Eric Smith]

I already intend to make some "early access" DIY4X or DIY5 units available to the WP-34s team. I brought it up in this thread in case any other calculator developers want to work on firmware on this platform.

These "early access" units are NOT going to be a general-availability calculator. They are hand-made prototypes. It is our intent to offer an actual product in the not-too-distant future, but we still have a lot of work to do to make that happen.

[Marcus von Cube, Germany]

You can count on me. :-)

[uhmgawa]

Quote:

---

However, the DIY4X uses about 30mW vs. the Raspberry Pi..

---

I don't think a BCM2835 is a serious design-in contender for any
device feeding off primary cells, let alone the usage model of a
drop-and-forget pocket calculator. FWIW the power budget for
the ethernet link status LEDs alone on that board likely exceeds
30mW.

IMHO the real challenge of producing a generic pocket calculator
class platform is that of securing a cost effective display
which functionally and mechanically integrates well with the
intended design. I'd venture as far to say everything else is
largely a footnote -- even the mechanical design and fabrication
can be feasibly addressed on a small scale. The electrical
design barely exceeds the task of pcb layout.

I'd be delighted to find I've overlooked a viable source. But
trying to secure a monochrome full reflective (or equiv.),
of suitable resolution, wide aspect ratio, in a minimal (eg: COG)
footprint, off the shelf hasn't been very productive. I've
found a few possibilities of semi-custom adaptation of
existing designs but NRE hurdles still come into play.

One possibility here may be to pool overall interest and leverage
a single design for the multiple calculator projects underfoot.
I don't know whether sufficient commonality exists but it sure
seems worth consideration.

[Eric Smith]

What vendor makes the display you use in your calculator?

[uhmgawa]

Quote:

---

What vendor makes the display you use in your calculator?

---

It is just a proof of concept grafting of a graphic module into
a prototype KINOMI module. If a suitable off-the-shelf COG
(or even COB though quite unlikely) module existed I would have
laid out a replacement board with an ARM SoC to drop into either
a legacy or sam7 voyager shell.

But to answer your question, the module shown in the graphic
voyager is a nondescript surplus 128x32 transreflective COB
containing a ST7920/ST7921 chipset. This particular controller
isn't a good choice with a 3V rail as it is characterized only
down to 2.7V. But a slew of low(er) voltage designs exist.

I believe for an LCD display COG is about the only economical
choice and mechanically it has by far the most compact envelope.
The asymmetry of the active area and vertical bloat due to the
glass area required for controller & interconnect is a
substantial complication with a compact landscape layout. But
for a profile configuration that bloat can likely be absorbed
without any impact.

[Andrés C. Rodríguez (Argentina)]

COG = Chip On Glass

COB = Chip On Board

(just a little help for those who are not faliliar with these acronymns, and don't want to spend five minutes looking for an explanation elsewhere)

[Hugh Evans]

This is a problem to the point of being ridiculous. Every design I've worked on thus far has ended up requiring a custom display. I toyed with building designs around available glass, but everything I've found has been a mediocre compromise at best.

It would be great to see this community pool its resources and talent in order to produce some great hardware... But I'm not holding my breath. Considering the success demonstrated by WP-34S, I have no question that great hardware will spur fantastic software development.

Regarding Raspberry Pi: as stated before in this thread it's far too power hungry. A similar product better suited to calculators could be produced at a similar price point with little difficulty. My current plans for OpenRPN call for a SoM most likely built on a SODIMM board. Not only does this mean a singe module type could be used for multiple calculator form factors, but the module should be able to sell as a stand alone product too.

[Eric Smith]

Custom LCDs aren't all that expensive to have made, both in terms of NRE and per-unit production cost, if you can use a segmented display. A dot matrix display (glass only, without a controller embedded in the display) is also not too expensive, but not practical for a matrix much larger than 96x32 due to the large number of interconnects needed.

[uhmgawa]

Quote:

---

Custom LCDs aren't all that expensive to have made, both in terms of NRE and per-unit production cost, if you can use a segmented display. A dot matrix display (glass only, without a controller embedded in the display) is also not too expensive, but not practical for a matrix much larger than 96x32 due to the large number of interconnects needed.

---

Contemporary controllers aren't available for even modest
graphic densities outside of COG bumped die or (even less
prevalent) COB bondable die. While prototype usage can
accommodate packages as unwieldy as a 200+ pin lqfp, given no
commercial market for such exists that's another empty set.

Older controllers can be found in SMD packages but their power
consumption and legacy voltage rail, limit their usage to
"bench top" prototypes.

[Eric Smith]

Die bonding is not viable for very-low-volume hand-made products, but even in modest production volumes (250 and up), it is not too expensive.

[Nick_S]

Perhaps the x48 emulator could be ported to the Raspberry Pi as it is already available for the Linux operating system.

Nick

[Egan Ford]

It has already been done. I ported a number of emulators to ARM Linux a long time ago. Port is overstating it a bit, more like "make" with a few patches.

Links:

1. http://sense.net/zc/free42/
   
2. http://sense.net/zc/nonpareil/
   
3. http://sense.net/zc/x48/
   

[Nick_S]

That looks like a good beginning for calculators to run on this device.

Nick

[Oliver Unter Ecker]

One can write calculator software for the Kindle and leverage unbeatable HW at <$100: 256 MB RAM, 1-3 GB flash, 6" 800x600 Eink display.

Versions with and without keyboard exist, latter with or without touch screen.

The display may be a little large for a RPN-style machine but is great for an RPL-style machine (or any grapher). If the Kindle touch would be used and half the screen went away for keys, the 6" screen becomes a 3" screen, which isn't too large for RPN-style either.

I'm not sure about the legality of it, but repurposing a Kindle would be another possible option: the device can be jailbroken/unlocked and used as an ARM Linux machine with a good stack of technologies included.

The outer housing and fiddly keyboard could be replaced with something else (or, maybe the keyboard area only could be reworked).

All of this goes also for the nook, I suppose.

[uhmgawa]

Quote:

---

One can write calculator software for the Kindle and leverage unbeatable HW at <$100: 256 MB RAM, 1-3 GB flash, 6" 800x600 Eink display.

---

It is quite tempting to leverage a commercial product which has
reached high volume economy. The Achilles Heel in that
prospect is you're not in control of the design and even
if
a reasonable means is found to adapt it and
is wildly successful, that potential exists only for the
extremely short product market life of such a consumer device.

So in part developing a new platform is about half getting
exactly what you want in the associated design and about half
having some assurance continued availability approximates the
technology it is based upon vs. the market survival of the
originally intended application.

That aside, a silver lining of sorts is the technology
development frenzy chasing the insane volumes in that mass
market has produced a flood of inexpensive
silicon/peripheral/mechanical
components which can be leveraged in clean slate designs
underfoot here.