DM-42 and WP-43S

[vido]

The WP-43S homepage mentions that Hardware will be built by SwissMicros.

Since SwissMicros is also currently developing the DM-42, and it takes time (not to blame them, they are doing a fine job and do not rush to production), I was wondering whether the WP-43S will be available as a simple firmware upgrade for the DM-42, or like the landscape DM-XX ones, a separate model based on the same hardware basis (which could explain the extra care to the hardware platform development by SwissMicros).

Does anyone has info about this ?

[Paul Dale]

The plan is a separate model. The hardware is identical, they keyboards not.

So a firmware update would be possible with an overlay.


There has been no progress on the WP-43S software and it isn't looking like there will be any for a while yet.


Pauli

[vido]

(02-15-2017 07:10 AM)Paul Dale Wrote:  There has been no progress on the WP-43S software and it isn't looking like there will be any for a while yet.

Ouch. I hope they haven't abandoned the project. The WP-34S is such a nice thing, its next iteration, the WP-43S, is bound to be fantastic.

[Paul Dale]

Walter is mostly done with the design, Marcus and I are the ones short of time. The 34S firmware took several years to reach fruition and the 43S will be similar -- there is some code that can be reused but a lot needs to be replaced.

- Pauli

[Hsilop]

Is the source code anywhere that contributors might find it and contribute?

I found this sourceforge page, but it seems the only thing there is documentation.

[Paul Dale]

The lot of code will come across from the 34S page. There isn't anything specifically 43S yet.


Pauli

[Hsilop]

Thanks! Any specific recommendations regarding the development process / environment? Which editor do people use?

[Paul Dale]

The development process and environment are important and are still to be defined. The editor people use is a personal choice -- I know Marcus and I use different editors and likely Walter uses a third.

As for code, most of the mathematical code exists from the 34S project, a few of these functions could do with a rewrite but this is relatively minor (okay it isn't really). This comes to about a third of the 34S firmware, most of the rest needs doing for the 43S. This includes:

• C++ wrapper around the decimal library.
• Hardware support (which needs hardware, so will have to wait but this can be abstracted).
• Display driver (abstracted from the hardware)
• Emulator framework, possibly based on existing code from other projects (KML scripts).
• New assembler, NOT written in Perl but in C/C++ (which would allow embedding in the emulator).
• User code debugger.
• Build system (marvin?). We've made horrible decisions in the past. If you manage to set up the build environment for WP-34S on Windows or Linux you know what I mean.
• Typed registers (int, real, complex, string, ...)
• User interface (keyboard handling and screen display, ideally table driven)
• Internal function opcodes need a complete rework
• Better error handling
• Memory management
• OP code design that supports variable length instructions
• User code SST+BST
• Dispatcher for user code
• Instruction display for screen and printer.
  

And of course items will have been missed.

Marcus and I have reasonable ideas as to how some of this will need to work.


Pauli

[Hsilop]

Looks like a fair bit of work, and also work which requires some direction ...

I should confess that I consider myself an experienced programmer, although from a different background. Some of these tasks are not for me, but I'd like to take this as a learning experience and contribute in ways I can.

For starters, I'd need to figure out to work with this code. I'll try to work it out, but any pointers & references that could be helpful are of course welcome.

[Paul Dale]

It will be a lot of work.

I'll have to think about pointers into the existing code. Any specific items that looked appealing?


- Pauli

[Hsilop]

I am thinking that the build system needs to be understood at least, in order to get anywhere at all.

So if there is work to be done there, it seems that the answer is given?

[Paul Dale]

The build systems were Marcus's area originally -- I made the command line build makefile, Marcus created the 30b target build and one of the emulator builds. Later ports modified these I believe.

Needless to say, the build system is a bit of a mess. Target builds can only happen under Windows with a specific version of a specific ARM compiler, the other compilers we've tried generate broken code.


- Pauli

[emece67]

(02-25-2017 05:01 AM)Paul Dale Wrote:  Needless to say, the build system is a bit of a mess. Target builds can only happen under Windows with a specific version of a specific ARM compiler, the other compilers we've tried generate broken code.

Yagarto 4.6.0. I learnt it the hard way.

[efroymson]

I would argue that fixing the build system is the single most important job. For one thing, it would allow end users of the calculator to program it in native code. Given the really beautiful multiline display, and the dedicated row of blank keys at the top, the customization possibilities would be fantastic, even without changing the keyboard on the DM-42 at all.

I suppose that some programming of calculators is done "on the fly", but I suspect most of it is done in advance, for a particular purpose. The advantage of a programmable calculator is more its portability and customizability than its programmability per se.

The work done on the WP34S would not be at all wasted, as much of the code could become part of a great library of routines to be included or not as desired by the end user.

I suppose that to really make this work, the codebase would have to be merged with that of Free42, which is maybe impractical. And perhaps I'm suggesting too much overloading of the "Custom" menu (and the "setup" menu, the purpose of which is not clear to me now, except that Top.Fcn is redundant).

Possibly some people who have actual use cases for their calculator should chime in here. I was an embedded systems engineer for several years, so the idea of coding, building, and downloading custom firmware is quite natural to me. Others may not like the idea of having to use an IDE to program their calculator -- though again, this would only augment, not replace, the ability to do classic keystroke programming.

Just my 2 cents ...

(02-26-2017 12:33 AM)emece67 Wrote:  

(02-25-2017 05:01 AM)Paul Dale Wrote:  Needless to say, the build system is a bit of a mess. Target builds can only happen under Windows with a specific version of a specific ARM compiler, the other compilers we've tried generate broken code.

Yagarto 4.6.0. I learnt it the hard way.

[Hsilop]

@efroymson, I agree that until it is fixed, fixing the build system is the single most important job.

Every developer should be able to build, at will, with absolute confidence. Everybody should have confidence in anybody else's build.

There should be unit (and other) tests that can be executed as part of the build, and there should be build scripts which can be run on a build server.

I notice that Yagarto (http://yagarto.org/) is a toolchain, where Eclipse is mentioned as one part of that chain. Of course any text editor of choice could be used for editing text, but it would certainly not hurt if it also is possible to use the entire toolchain as intended by its creators.

Perhaps this question goes to @emece67: When you mentioned "Yagarto 4.6.0" - did you refer to the entire package including Eclipse, or only parts of it?

[emece67]

I think that such question should be answered by the core developers. I'm only an aficionado that managed to build the wp34s from information gathered from various sources (mainly this forum) and my own effort.

Not sure if my build system is the canonical one, but I use Yagarto 4.6.0 as a bare C cross compiler for ARM. The other components of the system are MinGW (with the development toolkit and curses libraries), Active Perl, MS Visual C++ Studio 2010 and TortoiseSVN. Incidentally, I needed sometime to add the Qt SDK to the previous mix (cannot remember the reason, perhaps something related to the serial communications in the emulator), but it is no longer in my HD. The firmware is build thru a "traditional" makefile based approach. I'm not sure who manages the emulator build.

IMHO, the yagarto+MinGW combo is used to build the firmware inside the wp34s (and the console emulator?), whereas MS Visual C++ Studio 2010 (plus Qt?) is used to build the emulator. Perl is used in both builds.

As a plain-vanilla user of this build system, I find MS Visual C++ 2010 a PITA. Difficult to install, to manage and colliding with other build systems in my computer (to be precise, colliding with Atmel Studio and Texas Instruments Composer Studio, fortunately I stopped developing with TI chips time ago and switched from Atmel Studio to Keil uVision for ARM months ago). The wp34s is the only reason forcing me not to uninstall the MS Visual thing.

On the other side, the MinGW environment and Active Perl do their job both diligently and silently. In my experience, anything depending on Perl or Python does work effortlessly. Sure the core developers have good reasons for it, but substituting Perl with anything related to a C compiler ring alarms in my head. Evenmore if such C compiler is a huge beast as the MS Visual tool.

As you see, no sign of Eclipse here. At my work there are many hardcore users of Eclipse, but I find it too complex for casual users and, again, hard to install and maintain (although better than MS Visual...).

Time ago I attempted to switch from the Yagarto compiler to the ARM toolchain. Although the system apparently worked (it produced the expected .bin files without errors) such files did not work properly on the wp34s. Sadly I was forced to switch back to Yagarto. Yagarto does the job, but I feel not very comfortable needing a tool built and managed by a single person (is Yagarto currently active at all?). Much more when there is another toolchain (the ARM one), actively maintained and documented, and used by many, many people without problems.

Hope this helps, regards.

Edit. After many hours studying the wp34s code, I have a good knowledge of the huge effort it took to the developers and also that such developers are really capable ones thus, although some decisions they took may seem arguable now, I'm sure they were the right decisions when they were taken.

[emece67]

Is it known what is the processor inside the dm42/wp43?

[Paul Dale]

Marcus set up the firmware build system -- I believe this was built on top of HP's example code but I'm not certain. We never figured out why the Yagarto 4.6.0 compiler worked and others didn't. The image was produced looked fine but it never quite worked. We would have preferred a firmware build under Linux using free/open tools.

The console version of the 34S was designed for Unix like systems using the curses library -- I used it under Linux or MacOS X, I don't know if it even builds under Windows. I doubt many other people other than myself ever bothered with it -- it is arcane and difficult to use. Still it served its purpose well enough.

The reason to replace Perl with C is so that the assembler can be hosted on the device. I think this is a reasonable suggestion, it does make keystroke programming easier but would require some text edit capabilities.

I can't locate the precise processor being used in the DM-42 at the moment It is a decently resourced ARM core.

Rather than rebuilding from the source code to make modifications, perhaps an embedded scripting language (Lua or Python?) could be included. These are much safer & easier to write programs for but are a major step away from the keystroke programming of traditional calculators.


Pauli

[emece67]

(03-01-2017 11:38 AM)Paul Dale Wrote:  The console version of the 34S was designed for Unix like systems using the curses library -- I used it under Linux or MacOS X, I don't know if it even builds under Windows. I doubt many other people other than myself ever bothered with it -- it is arcane and difficult to use. Still it served its purpose well enough.

It does compile on Windows:
   

After your comment, I wonder if I am the only person in the World having compiled it under windows ;-)

[Steve Simpkin]

(03-01-2017 11:38 AM)Paul Dale Wrote:  I can't locate the precise processor being used in the DM-42 at the moment It is a decently resourced ARM core.
Pauli

From previous discussions, I believe the DM-42 is using a variation of a Cortex-M4 type controller. The NXP LPC54102 Cortex-M4 controller (as an example) has 512KB of Flash and 104KB of RAM.