DB48X: HP48-like RPL implementation for DM42

[c3d]

(06-28-2024 11:45 PM)c3d Wrote:  

Quote:Concerning, the state saving function, I observed that I am not able to save the calculator state under a new name (useful if a want to communicate the precise configuration of a given problem). Doing Setup>State>Save state, leads to <New Files>; I then correctly enter a new Filename, but the calculator then prompts with - [R/S] to Confirm. And there I am stuck because the [R/S] key is inaccessible since the DM32 key template is gone. I tried any key (including [=]) with no success. One indirect way to circumvent this is to create copies of given states in the computer and upload them afterwards into the calculator. And then save my new states under these pre-existing named ones.

Thanks for your help.

Weird. This is indeed a bug, and indeed, the = key is the one you should use. But I can confirm it does not work, whether on DM42 or DM32. This is a regression, I'm pretty sure it used to work. I filed an issue.

Thanks for reporting!

It seems to only occur on DM32, not DM42. On the DM42, you finish entry using the ENTER key, not R/S. I tried that on the DM32, but it does not work either.

I'm reflashing with the stock DM32 firmware to see how that works there.

[c3d]

(06-29-2024 12:47 PM)c3d Wrote:  

(06-28-2024 11:45 PM)c3d Wrote:  Weird. This is indeed a bug, and indeed, the = key is the one you should use. But I can confirm it does not work, whether on DM42 or DM32. This is a regression, I'm pretty sure it used to work. I filed an issue.

Thanks for reporting!

It seems to only occur on DM32, not DM42. On the DM42, you finish entry using the ENTER key, not R/S. I tried that on the DM32, but it does not work either.

I'm reflashing with the stock DM32 firmware to see how that works there.

On DM32, the ENTER key emits the M key. So that's why file entry was moved to R/S. Hmm. Need to dig a bit deeper on how to address that.

[c3d]

A new minor release 0.7.9 is out.

This release includes a number of bug fixes, facilitates build from scratch by third-parties, and delivers a WASM-based simulator that runs on the https://48calc.org web site.

Features

menu: Add Purge to the ClearThingsMenu
purge: Add support for lists
units: Accept units for sqrt, cbrt and xroot
wasm: Add variant for 48calc.org
wasm: Implement WASM support

Bug fixes

complex: Give Syntax error for phasor without an angle
dms/hms: Parse empty numbers in DMS entry
dms/hms: Protect display against bad input
editor: Make sure we reposition after shift-up and shift-down
parser: Parse degrees as an angle unit in phasors
simulator: Avoid high CPU usage when a timer is active
simulator: Use the correct color for firmware text
ui: Compute the correct refresh rate even when nothing is displayed
ui: Create a non-empty dirty rectangle when clearing annunciators
ui: Do not refresh beyond LCD size
ui: Ensure we redraw the shift region to clear busy
units: Disable simplification during unit definition evaluation

Improvements

build: Fix the clean build
object: Remove defaults for as_uint32 and similar
parser: Cache parser::length when possible
parser: Merge the parser::end and parser::length fields
parser: Optimize integer parsing early exit
simulator: Avoid Cancel in file save dialog
simulator: Use https as a protocol for git submodules
tests: Add support for degrees sign
tests: Add test for polar angle conversion.
units: Add factoring variable to limit simplifications
wasm: Add link to deployed WASM simulator in the README
wasm: Add script to add COOP / COEP headers
wasm: Run the RPL thread in a separate thread

[spiff72]

Simple procedural question for the updates...

Is it good practice to replace the various config files with each update? I have customized my units.csv file, so I typically don't update it, but I have been grabbing the other ones from the release assets (like characters, equations, library, constants, etc).

Is this necessary?

[c3d]

(07-01-2024 06:51 PM)spiff72 Wrote:  Simple procedural question for the updates...

Is it good practice to replace the various config files with each update? I have customized my units.csv file, so I typically don't update it, but I have been grabbing the other ones from the release assets (like characters, equations, library, constants, etc).

Is this necessary?

It depends if I changed them ;-)

For the last few releases, I have made only few changes to these files. The most recent, IIRC, is changes to the equations library to add units to variables.

I will make a point from now on to indicate in release notes if the configuration files were updated.

[spiff72]

(07-01-2024 07:16 PM)c3d Wrote:  

(07-01-2024 06:51 PM)spiff72 Wrote:  Simple procedural question for the updates...

Is it good practice to replace the various config files with each update? I have customized my units.csv file, so I typically don't update it, but I have been grabbing the other ones from the release assets (like characters, equations, library, constants, etc).

Is this necessary?

It depends if I changed them ;-)

For the last few releases, I have made only few changes to these files. The most recent, IIRC, is changes to the equations library to add units to variables.

I will make a point from now on to indicate in release notes if the configuration files were updated.

Great - that will be very helpful for me, at least!

[spiff72]

I have an possibly odd question.

My DM42 (running DB48x) is showing the low battery warning today for the first time. I figured that this is probably legit because the voltage indicator in the menu bar has been gradually decreasing, and it dropped below 2.6v now.

I am at work but I have a stash of crummy CR2032 batteries here that I thought I could at least install and use until I get home and put a better quality battery in tonight.

However, when I swapped in one of these suspect batteries, I still get the error message and can't use the calc unless it's plugged into USB power.

I did check the battery voltage with a multimeter and it was about 3.1V before I installed it. I just pulled the back off the calc and carefully checked the voltage while it is installed and in the "on" state (currently displaying the low voltage warning). I measure 3.15v despite the voltage level being reported by the calc in the sub-2.6v range.

Could something have changed in the latest FW version that might cause this? It seems like it's not reading the voltage correctly, but I never tried measuring the voltage in-circuit with previous FW versions.

Thanks!

[spiff72]

(07-03-2024 05:53 PM)spiff72 Wrote:  I have an possibly odd question.

My DM42 (running DB48x) is showing the low battery warning today for the first time. I figured that this is probably legit because the voltage indicator in the menu bar has been gradually decreasing, and it dropped below 2.6v now.

I am at work but I have a stash of crummy CR2032 batteries here that I thought I could at least install and use until I get home and put a better quality battery in tonight.

However, when I swapped in one of these suspect batteries, I still get the error message and can't use the calc unless it's plugged into USB power.

I did check the battery voltage with a multimeter and it was about 3.1V before I installed it. I just pulled the back off the calc and carefully checked the voltage while it is installed and in the "on" state (currently displaying the low voltage warning). I measure 3.15v despite the voltage level being reported by the calc in the sub-2.6v range.

Could something have changed in the latest FW version that might cause this? It seems like it's not reading the voltage correctly, but I never tried measuring the voltage in-circuit with previous FW versions.

Thanks!

To add to the above...

I checked the voltage of the battery that I removed, and it is showing about 2.78v (outside the calc - not in circuit).

And to clarify how I am checking the voltage while in-circuit, I am touching the very edge of the big round pad on the PCB that the negative side of the battery touches (very carefully to avoid shorting the probe against both the pad and the edge of the battery), and touching the battery holder to get the + side contact.

EDIT: I also tried reverting to the previous version but that didn't help.

EDIT2: I tried flashing the latest C47 and it appears to report the same voltage with the BATT? command (around 2.49v), but that firmware doesn't pop up a message about replacing the battery. With the DB48x firmware, I can't even turn the calc off to get out of that error state.

It's surprising to me that the voltage value available in the firmware differs from the voltage I can read at the battery. I will swap the battery for a better quality one when I get home tonight.

[mfleming]

Press reset on back to reestablish calculator state?

[spiff72]

(07-03-2024 07:33 PM)mfleming Wrote:  Press reset on back to reestablish calculator state?

I'm not sure if you were replying to me, but I did try resetting the calc with the button on the back to see if the voltage reading changed or not. (It didn't).

Eventually I figured out that if I turned plugged into USB with this "suspect" battery installed, and pressed exit a few times to clear the error message about low battery, I could turn it off, and then unplug it from USB and it stayed off. I swear I did this earlier and it didn't work, but I'm heading home now to replace my battery and see if things go back to "normal"! ;-)

[rprosperi]

As soon as cheap CR2032 batteries get below ~2.9V, they are unreliable. The DMCP is sensing the voltage under load and is attempting to display the actual voltage as seen with a load present, which is why it appears to be lower than the DMM is showing.

In any case, but a good quality CR2302 cell in (Energizer, Panasonic, Toshiba, etc.) and leave the cheap Chinese cells for other less demanding devices and you'll be OK.

[spiff72]

(07-03-2024 11:39 PM)rprosperi Wrote:  As soon as cheap CR2032 batteries get below ~2.9V, they are unreliable. The DMCP is sensing the voltage under load and is attempting to display the actual voltage as seen with a load present, which is why it appears to be lower than the DMM is showing.

In any case, but a good quality CR2302 cell in (Energizer, Panasonic, Toshiba, etc.) and leave the cheap Chinese cells for other less demanding devices and you'll be OK.

I put an energizer in it when I got home and that solved the problem. As I mentioned, the one I used earlier was from a VERY suspect batch that I vowed never to use again because they would go dead so quickly in just about any device. I'm showing a reading above 3v now on the status bar. I didn't check this one with a meter though...

[c3d]

(07-03-2024 05:58 PM)spiff72 Wrote:  EDIT2: I tried flashing the latest C47 and it appears to report the same voltage with the BATT? command (around 2.49v), but that firmware doesn't pop up a message about replacing the battery. With the DB48x firmware, I can't even turn the calc off to get out of that error state.

The error state probably indicates that the calculator is off. It depends on the precise message, but what you seem to indicate is that the voltage was low enough that the firmware selected an "emergency shutdown" to preserve memory content, in which case it might not even draw the off image (because that does consume power).

I tuned the firmware thresholds based on experiments on a DM42 with various medium-quality batteries.That would probably require more experimentation and fine-tuning.

Quote:It's surprising to me that the voltage value available in the firmware differs from the voltage I can read at the battery. I will swap the battery for a better quality one when I get home tonight.

I agree with the explanation that it's the difference between voltage under load and voltage without a load.

[c3d]

Release v0.7.10 is available for download.
Features

stack: Interactive stack and associated menu
functions: Very basic random number generator
demo: Add CountPrimes and RandomPlot examples


Bug fixes

menus: Do not execute if-then-else and similar
expressions: Avoid error testing for zero/one in power operator
condidionals: Avoid infinite loop evaluating condition
menu: Insert iferr-then-else correctly from menu
constants: Skip menu entries


Improvements

menus: Reorganize stack menu to put Dup and Drop on first page
menu: Add error functions to Debug menu

[spiff72]

(07-14-2024 11:31 PM)c3d Wrote:  Release v0.7.10 is available for download.
Features

stack: Interactive stack and associated menu
functions: Very basic random number generator
demo: Add CountPrimes and RandomPlot examples


Bug fixes

menus: Do not execute if-then-else and similar
expressions: Avoid error testing for zero/one in power operator
condidionals: Avoid infinite loop evaluating condition
menu: Insert iferr-then-else correctly from menu
constants: Skip menu entries


Improvements

menus: Reorganize stack menu to put Dup and Drop on first page
menu: Add error functions to Debug menu

No changes to the .csv files, I assume? (Since no mention in the changelog)

[c3d]

(07-15-2024 12:41 AM)spiff72 Wrote:  No changes to the .csv files, I assume? (Since no mention in the changelog)

No, but probably significant changes in the equations next release.

[mahi]

Thank you for the interactive stack, Christophe! I really like it!

Concerning overwriting the *.csv files... Maybe add support for custom *.csv files? For example "units-custom.csv". The custom entries are appended to those of the regular csv. In case of duplicates, the custom files gets preference. This way you can safely overwrite the regular csv files without risk of losing the custom entries.

Just an idea. It might need to be thought out better before implementing.

[c3d]

(07-15-2024 09:23 AM)mahi Wrote:  Thank you for the interactive stack, Christophe! I really like it!

Concerning overwriting the *.csv files... Maybe add support for custom *.csv files? For example "units-custom.csv". The custom entries are appended to those of the regular csv. In case of duplicates, the custom files gets preference. This way you can safely overwrite the regular csv files without risk of losing the custom entries.

Just an idea. It might need to be thought out better before implementing.

The performance is already a concern.

Truth to be told, the CSV file is here to help people understand the format. You don't need any of them, since the values in there are the same as found in the firmware itself (except for units.csv, where I added some transient monetary units and a cycle configuration).

At some point later, as we get near 1.0, these configuration files will be reduced to the bare minimum, and the ShowBuiltinUnits, ShowBuiltinConstants and ShowBuiltinCharacters will be flipped to be true by default. When that happens, the CSV files will only be there for "extra" stuff, not for basic stuff, which is better for performance.

In short, what I am saying is that your idea is good, but that the configuration files are the "custom" part that you are describing, the non-custom part being the builtin ones in the firmware.

Does that make sense?

[spiff72]

(07-15-2024 10:15 AM)c3d Wrote:  

(07-15-2024 09:23 AM)mahi Wrote:  Thank you for the interactive stack, Christophe! I really like it!

Concerning overwriting the *.csv files... Maybe add support for custom *.csv files? For example "units-custom.csv". The custom entries are appended to those of the regular csv. In case of duplicates, the custom files gets preference. This way you can safely overwrite the regular csv files without risk of losing the custom entries.

Just an idea. It might need to be thought out better before implementing.

The performance is already a concern.

Truth to be told, the CSV file is here to help people understand the format. You don't need any of them, since the values in there are the same as found in the firmware itself (except for units.csv, where I added some transient monetary units and a cycle configuration).

At some point later, as we get near 1.0, these configuration files will be reduced to the bare minimum, and the ShowBuiltinUnits, ShowBuiltinConstants and ShowBuiltinCharacters will be flipped to be true by default. When that happens, the CSV files will only be there for "extra" stuff, not for basic stuff, which is better for performance.

In short, what I am saying is that your idea is good, but that the configuration files are the "custom" part that you are describing, the non-custom part being the builtin ones in the firmware.

Does that make sense?

I'm curious about something regarding these .csv files:

Does the calc actually read from the FAT disk during operation, or does it access them once (at startup) to read them in, and then close the FAT disk?

[spiff72]

I just wanted to chime in (for once) without reporting an issue...

Instead, I am reporting SPEED!

I recently heard of the R47 calculator (variant of the C47 with two shift keys), and made an overlay and keylabel set for it. I thought I would give it a try on my DM42 before applying any overlays or labels, and I was immediately struck by the sluggishness of the calculator (on battery power). Just repeatedly pressing the square root of a number over and over has a very noticeable delay/lag. If you do it fast enough and often enough, you can stop and then wait several seconds for the calculator to catch up.

I still remember commenting to c3d a while back when I felt that DB48x was feeling sluggish to me (when dividing 2 numbers with a decimal point (and lots of digits)), and in the next release there was a significant and noticeable difference in speed. (If I recall correctly it was a screen rendering or graphical adjustment.)

There's no way for me to go back to the other projects right now (C47) - they just "feel" too slow to me after using DB48x for many months (maybe a year?). I feel like only the stock DM42 firmware is faster from my experience.