AriCalculator is a home made pocket calculator.

[compsystems]

AriCalculator is a home made pocket calculator.

http://hotwolf.github.io/AriCalculator/



The software for the AriCalculator will be written in Forth. This will make it easier to port it to other platform and to add new features.
https://en.wikipedia.org/wiki/Forth_(pro..._language) RPN

[emece67]

(02-15-2017 05:20 AM)compsystems Wrote:  AriCalculator is a home made pocket calculator.

http://hotwolf.github.io/AriCalculator/



The software for the AriCalculator will be written in Forth. This will make it easier to port it to other platform and to add new features.
https://en.wikipedia.org/wiki/Forth_(pro..._language) RPN

A really nice project. But, sure Forth will make it easier (than, say, C) to port to other platforms?

[Dave Britten]

Very nice. Definitely the sort of thing I'd buy if a through-hole kit were available (I definitely don't have the means to solder those tiny surface-mount components).

[KeithB]

And we complained about the key labels on the Prime!

[everettr]

(02-15-2017 07:35 PM)KeithB Wrote:  And we complained about the key labels on the Prime!

It looks like a good candidate for a backlit keyboard though. :-)

[Maximilian Hohmann]

(02-17-2017 05:41 PM)everettr Wrote:  It looks like a good candidate for a backlit keyboard though. :-)

But I doubt that it will make the labels more readable... And about FORTH: "This will make it easier to port it to other platform and to add new features." I have my strongest doubts. I don't even know if a FORTH interpreter/compiler exists for my PowerBook which can be used to program a microcontroller.

[Dwight Sturrock]

Very nice hardware。 I would think C would be more of an industry standard, however.

[Jim Horn]

Why FORTH? If his microprocessor (an NXP unit) doesn't have a good C compiler / debugger package available for free and he's adept with FORTH, why not? Porting FORTH to a new CPU architecture is a matter of hours for those who have done it, especially since the vast majority of the language is written in itself. Only a small amount is in assembly. So it's easy to bootstrap a development system very quickly. And with modern versions, they can be quite powerful.

That's why I chose FORTH as the development language for the 65F12 (6502 variant) used for the engine monitor system for the Voyager World Flight - I wanted a higher level language than raw assembly and wanted it to be self hosted so I could debug on the actual unit. In 1985 that left me with only one choice.

Yes, it's an odd language to those new to it. But it has done quite a bit (many of the production programs for a major aerospace imaging company were written in FORTH, not by me but I got to support them).

[Eddie W. Shore]

Very nice.

[hotwolf]

Hello,
I'm the designer of AriCalculator and I've been asked to join this conversation.

The calculator is a hobby project of mine, which has been inspired by HP's handheld products. The hardware is based on a NXP S12G240 microcontroller with 11k of RAM and 240k of flash space. It has a 128x64 pixel graphics display, 38 keys, a USB virtual COM port (FTDI) that servers as a user programming interface, and a general purpose SPI port for hardware extensions. The hardware is in it's third iteration and I would consider it as mature.

The calculator will run on my own ANS Forth implementation which is currently undergoing it's third complete rewrite. And that is currently the focus of my hobby time.

I choose Forth as a base for the firmware, because it's lightweight, efficient, portable to other platforms, and it provides a great programming interface for user extensions. It's my substitute for HP's RPL.

So my software development lacks a bit behind, mostly because I've been tinkering with my Forth too much and because it has so far only been a one mane show. But, recently I joint efforts with the developer of the 8051 RPN calculator. So the AriCalculator R&D team has just grown by 100%.

I'd like to respond to some of the previous posts:

@Dave Britten: Integrated circuits are just not produced in through hole packages anymore. I'm happy when a chip comes in a package with outward bent pins, so it can be hand soldered at all. But, there is no need to be afraid of SMD work. I think the key to soldering small and close-pitch components is having a decent soldering microscope. Once you can see what you're doing you are able to work very accurately with your hands.

@KeithB: The laser engraved labels are better readable once they have been colored with acrylic paint.

@everettr: The calculator already supports backlit displays. It can be equipped with a second boost converter to power some LED. Maybe it would be a good idea to add some further LED to light up the acrylic front panel.

@Maximilian Hohman: The Forth compiler runs on the calculator itself. That's one of the beauties of Forth. You send your source code in ASCII to the calculator and it compiles it into binary as it receives it. And you can pretty much use any ANS Forth running on your PC (e.g. GNU Forth or SwiftForth) to develop your software.

@Jim Horn: The S12G microcontroller has with a proprietary C compiler/IDE (CodeWarrior) and a free GCC port. But as this is a hobby project that I do for fun, I prefer programming in Forth and assembler.

Thank for your interest in the project. Please contact me if you any questions.
Dirk Heisswolf

[d b]

Impressive.

[Alejandro Paz(Germany)]

Very nice and great work !.
I like the acrylic cover as it gives a nice feeling in the hand.

There are now more of us (I presented two of my prototypes at the last Allschwil meeting).

On the processor: there are enough to pick from, I still think it does not play a really big role. For example, for my own calculator prototypes I tried in the last 15 years or so he following:
HC68HC11 (assembler)
SH-1 (assembler/C)
H8/300H (assembler)
AVR (assembler)
AVR32 (C)
LPC1769 (C, current)
PIC32MX (C, current)
i386 (Development machine, C, current)
STM32 (C, current)

On the H8/300H I went as far as having a graphical user interface, all in assembler. Wasted work, I cannot port it. That's why some 10 years ago, I decided to go for C. My current HP-Like code base works on several architectures: x86, MIPS and ARM. It is
portable to the point, I only need a HAL and a recompile (yeah it took so long).

Forth is a good choice, you port your virtual machine and should be ready.

The thing in choosing a language boils down to what do you have to achieve: Do you want something like a HP-48 (what I want) or something more like a HP-41 ? so to say.

I think it is time someone (we) work on a case/keys combination .

[hotwolf]

Alejandro,

Do you have pictures of your homebrew calculator collection online?

I have a certain bias towards MC9S12 microcontrollers. They're MC9HC11 decedents. They have decent memory sizes. They're automotive products, so they will be around for a while. And I know the members of the design team and trust their work . So I've been using S12 devices for almost all of my hobby projects.

The firmware of the AriCalculator is just the beginning of the development, so at this point I would be happy to have HP-41-like functionality implemented. Eventually the RAM will be the limit of what you can do with the device.

I'm curious to see how your keypad designs look like. I choose small buttons, because they are widely available and because they allow me to put all the label on the enclosure. Bigger buttons are more comfortable to use, but the labeling is difficult. Maybe multi-color 3D-printed button caps may be a solution.

[Alejandro Paz(Germany)]

I used switches, like you but I printed a keyboard overlay on a 3D printer. Far from good looking but not as bad as I thought. Sadly the key labeling is not as easy as yours and a good solution is still in the works. I have to do some printed overlays in a nice glossy paper... work to do

[hotwolf]

Alejandro,

your calculator looks pretty good. Is it open hardware?

Regarding the buttons, have you tried printing directly on a glass surface? That would allow you to print keys with glossy surfaces directly (see attachment). You could also try to print the labels as ditches and fill them with paint afterwards.

   

[Alejandro Paz(Germany)]

There is almost no hardware: processor (PIC32MX170) plus display, and keyboard. Not that much to "open".

I printed on aluminum, as a test of principle. I'm surprised on the result but it is far off a nice polished finish. That's what I implied with the case, it needs as much work as the rest of the unit.

I did a small script where I can enter the number of rows and columns and I get a done keyboard, sort of. For portrait keyboards works a treat. One can improve the keys a bit, make them with rounded corners and so on (for openSCAD):

Code:


// all measurements in mm
// fully parametrized
//
nkeys_horiz = 6;
nkeys_vert = 7;

key_width = 8;
key_height = 5;
key_depth = 3; // z-axis
key_binder_width = 5;
key_binder_depth = 0.6;
key_border = 0.6;
keyrow_height = 12.7-1.27-1.27;
keyrow_step = 12.7;

border_width = 6;
border_height = 5;
border_depth = 1;
// horizontal key separator
sep_width = keyrow_step - 2 * key_border - key_width;
// double-length key
module enter_key()
{
    translate ([key_border, key_border, 0]) 
    {
        cube ([ key_width+keyrow_step, key_height, key_depth]);
        translate ([(key_width-key_binder_width) / 2, -key_border, 0]) cube ([ key_binder_width+keyrow_step, key_border, key_binder_depth]);
    }
}

module key()
{
    translate ([key_border, key_border, 0]) 
    {
        cube ([ key_width, key_height, key_depth]);
        translate ([(key_width-key_binder_width) / 2, -key_border, 0]) cube ([ key_binder_width, key_border, key_binder_depth]);
    }
}

module keyrow()
{
    //sep_width = keyrow_step - 2 * key_border - key_width;
    translate ([0, keyrow_height - 2 * key_border-key_height, 0])
    {
        for (x = [0:nkeys_horiz-1])
            translate ([x*keyrow_step, 0, 0]) key();
        if (nkeys_horiz > 1)
        for (x = [0:nkeys_horiz-2])
            translate ([x*keyrow_step + 2 * key_border + key_width, 0, 0]) cube ([sep_width, 2*key_border+key_height, border_depth]);
    }
    cube ([(nkeys_horiz-1)*keyrow_step+key_width+2*key_border, keyrow_height-key_height-2*key_border, border_depth]);
}

module enter_keyrow()
{
    //sep_width = keyrow_step - 2 * key_border - key_width;
    translate ([0, keyrow_height - 2 * key_border-key_height, 0])
    {
        for (x = [0:nkeys_horiz-1])
            if (x == 0)
                translate ([x*keyrow_step, 0, 0]) enter_key();
            else
                if (x != 1)
                    translate ([x*keyrow_step, 0, 0]) key();
        if (nkeys_horiz > 1)
        for (x = [0:nkeys_horiz-2])
            if (x != 0)
                translate ([x*keyrow_step + 2 * key_border + key_width, 0, 0]) cube ([sep_width, 2*key_border+key_height, border_depth]);
    }
    cube ([(nkeys_horiz-1)*keyrow_step+key_width+2*key_border, keyrow_height-key_height-2*key_border, border_depth]);
}

// keys 7x6
translate ([1*border_width, 0, 0])
{
    // keys from bottom to top, row 5 is always enter key row
    for (y = [0:nkeys_vert-1])
        if (y == 4)
            translate ([0, keyrow_height*y, 0]) enter_keyrow();
        else
            translate ([0, keyrow_height*y, 0]) keyrow();
    // left side
    translate ([-border_width, 0, 0]) cube ([border_width, nkeys_vert*keyrow_height+border_height, border_depth]);
    // right side
    translate ([nkeys_horiz*keyrow_step-sep_width, 0, 0]) cube ([border_width, nkeys_vert*keyrow_height+border_height, border_depth]);
    // top
    translate ([-border_width, keyrow_height*nkeys_vert, 0]) cube ([border_width+nkeys_horiz*keyrow_step-sep_width, border_height, border_depth]);
    // display area
}

[hotwolf]

Alejandro,

now I see that that your keys are attached to the enclosure. I couldn't tell from the earlier photo. To achieve smooth surfaces, you would need to print the button caps and the case separately (upside down).

Here is my attempt at printing a button cap. The top one is a plain enter key, the bottom one is labelled "ENTER". As you can see, my FDM printer is can't do such fine print (at 0.1mm layer height). I guess idea of printing labels right into the button caps doesn't work.

   

[Alejandro Paz(Germany)]

At first I was really happy about the possibilities of 3D printers, the reality looks as you also saw, a bit different

I also tried with acrylic tops with glued bottoms but that proved also to be a mess.

[EugeneNine]

I built my own "calculator" back in the 90's while we were learning 8085 in college.
Its not really modeled after the HP other than I decided to make mine styled after a calculator which was my 48SX.

I dug it out of a box a while back an found the board cracked and LCD missing, it had a 2 line x 16 character display.

Lets see if this works

[hotwolf]

EugeneNine,

that is a well optimized placement of components. What does the back side look like?