[WP 34S] Enhanced Y register display: fractions, bugfixes etc.

[Bit]

(02-06-2014 06:10 PM)Jeff O. Wrote:  I like the way you display a y at the beginning of the 2nd line display after a Polar to Rectangular conversion, and the angle symbol after a Rectangular to Polar to conversion. This is remarkably similar to a two-line display mode developed by our friend Nigel Dowrick (see this old Forum thread).

It's similar because my work is based on the original Y register display.

(02-06-2014 06:10 PM)Jeff O. Wrote:  Or maybe indicate by lighting both of those at the same time - the cognitive dissonance evoked by having both lit might be a better reminder than having both unlit.

It'd certainly be a very noticeable reminder, but I don't like the idea of creating cognitive dissonance. If there's demand for it, I don't mind making it a compile time option and releasing a binary in which it's enabled, but I wouldn't use it myself.

(02-06-2014 06:10 PM)Jeff O. Wrote:  The only other comment I have is, is it my imagination, or is response to keystrokes a little sluggish? When entering a multi-digit value, it seems like the numbers appear in the display relatively slowly, especially if I am using both thumbs to key in the value. Not a big deal, just wondering if it is really there.

It's not your imagination. I consider it a bug: a regression like that is unacceptable. I'll look into it once I have the time.

[Bit]

(02-06-2014 02:39 AM)Bit Wrote:  I've found the problem, applied a quick fix and uploaded a new binary (which doesn't display the question marks) into the original post.

I assumed that non-const objects with static storage duration that have an initializer end up in the data section and will be copied to the volatile RAM every time the device wakes up from sleep. That's apparently not the case. Those question marks were placeholders for various indicators in the templates I introduced, but they stayed in the flash and were thus read-only.

Rather than trying to change how this is handled, I changed the code so it no longer needs such modifiable objects. I've updated the patch in the first post.

[Paul Dale]

Everything in the volatile memory disappears between keystrokes. Nothing there should ever be considered initialised.

There are a small number of state variables that are preserved between keystrokes (by stealing the LCD buffer memory) and you might be able to reuse some of these for some purposes -- you won't be able to grab any of the permanently however.

- Pauli

[Marcus von Cube]

(02-07-2014 03:20 AM)Bit Wrote:  I assumed that non-const objects with static storage duration that have an initializer end up in the data section and will be copied to the volatile RAM every time the device wakes up from sleep.

I've removed most of the standard C startup code to save flash space. Details are in the linker control file and the ARM assembly startup module.

Volatile RAM is lost after each single keystroke. To save state between keystrokes you will need to put the information in non volatile RAM. As Pauli indicated, the LCD buffer is used to save some state while the calculator is idle but not turned off. The block is named StateWhileOn. I'm pretty sure it is exhausted.

[Bit]

(02-07-2014 01:58 AM)Bit Wrote:  

(02-06-2014 06:10 PM)Jeff O. Wrote:  The only other comment I have is, is it my imagination, or is response to keystrokes a little sluggish? When entering a multi-digit value, it seems like the numbers appear in the display relatively slowly, especially if I am using both thumbs to key in the value. Not a big deal, just wondering if it is really there.

It's not your imagination. I consider it a bug: a regression like that is unacceptable. I'll look into it once I have the time.

Several factors contributed to the slowness of the new Y register display code when running on a 30b (it's impossible to observe it on a PC).

1. The WP 34S firmware stores the two fonts (big and small) in a clever compressed form to save space. In order to find individual characters in the compressed data, it needs a bit offset table. The offset table isn't stored in the firmware (space is tight), instead it's reconstructed (see findlengths()) in RAM every time the dot matrix display is updated. This is quite slow, and the Y register display made it worse: Instead of having to reconstruct just one offset table (either for the big or the small font), it may have to reconstruct offset tables three times for a single display update because it's switching back and forth between the big and small fonts.

This could be improved by reconstructing both offset tables and keeping them in memory (in stack) while the set_status_sized() function is running. I might do that later if I can establish that the increased stack space requirement doesn't conflict with anything else.

2. In order to find out how many digits can be displayed in the dot matrix display and whether to switch to exponent notation, a simple iteration is performed in annunciators(). This is not much of a problem for the original WP 34S as it displays a second number only after complex operations, but with Y register display a more efficient solution is worth the effort. A near constant time algorithm could probably be devised but it'd further increase the size of the firmware. Therefore I only added some simple logic to decrease the number of iterations. My rough estimate is that the typical number of iterations has been reduced by 50% and the worst case by 60%.

3. The original WP 34S updates the entire screen every time a key is pressed and then again every time a key is released. This is too slow with Y register display enabled.

3.1. When a digit is added to or removed from a number currently being entered the new version doesn't touch the dot matrix display and only updates the lower 7-segment line and the RPN annunciator. The rest of the screen wouldn't change anyway.

3.2. The new version doesn't update the screen at all (except for the RPN annunciator) when a data entry key (digits, radix mark, exponent, +/-, Enter or backspace) is released. There is no need to update it again because the screen had already been updated when the key was pressed and it doesn't change afterwards (unless an error message appears).

With these changes the device is faster than even the unmodified WP 34S when entering numbers. Type 123456789 or 1212121212 as fast as you can and you'll see the difference.

I think we're now quite close to having a high quality Y register display implementation. But the code hasn't yet received much testing and while it clearly works well most of the time, there are probably some corner cases I had overlooked. Whether you notice major bugs (something is displayed incorrectly) or non-fatal issues like inadequate speed or have ideas for further improvements, please let me know, any feedback is welcome. I've updated the compiled binary in my earlier post (#13). The source should be in the SVN soon.

[Jeff O.]

(02-11-2014 03:35 AM)Bit Wrote:  With these changes the device is faster than even the unmodified WP 34S when entering numbers. Type 123456789 or 1212121212 as fast as you can and you'll see the difference.

I think we're now quite close to having a high quality Y register display implementation. But the code hasn't yet received much testing and while it clearly works well most of the time, there are probably some corner cases I had overlooked. Whether you notice major bugs (something is displayed incorrectly) or non-fatal issues like inadequate speed or have ideas for further improvements, please let me know, any feedback is welcome. I've updated the compiled binary in my earlier post (#13). The source should be in the SVN soon.

Quite speedy now, thanks for your efforts. I'll keep using and let you know if I find any issues.

[Paul Dale]

(02-11-2014 03:35 AM)Bit Wrote:  2. In order to find out how many digits can be displayed in the dot matrix display and whether to switch to exponent notation, a simple iteration is performed in annunciators(). This is not much of a problem for the original WP 34S as it displays a second number only after complex operations, but with Y register display a more efficient solution is worth the effort. A near constant time algorithm could probably be devised but it'd further increase the size of the firmware. Therefore I only added some simple logic to decrease the number of iterations. My rough estimate is that the typical number of iterations has been reduced by 50% and the worst case by 60%.

I did think about trying to do this faster but so much depends on display modes and the widths of the characters themselves. 11111 takes less pixels than 88888 e.g. The brute force solution seemed easiest and it is very small. A binary search approach might work better, still cover the entire range and require fewer iterations -- start at the mid-point and ask does this fit? If not halve the digit count, if so double it and try again.

Quote:3. The original WP 34S updates the entire screen every time a key is pressed and then again every time a key is released. This is too slow with Y register display enabled.

The press and hold to display the function which then nulls out might confound things here.


- Pauli

[Bit]

(02-11-2014 07:59 PM)Jeff O. Wrote:  Quite speedy now, thanks for your efforts. I'll keep using and let you know if I find any issues.

Thank you.

There's one issue you can disregard: In fraction and HMS mode the minus sign is missing in the Y register display. The fix is trivial and I've had it for a long time, I just forgot to apply it when I compiled the last binary.

[Bit]

(02-11-2014 07:59 PM)Paul Dale Wrote:  I did think about trying to do this faster but so much depends on display modes and the widths of the characters themselves. 11111 takes less pixels than 88888 e.g. The brute force solution seemed easiest and it is very small. A binary search approach might work better, still cover the entire range and require fewer iterations -- start at the mid-point and ask does this fit? If not halve the digit count, if so double it and try again.

The brute force solution was apparently good enough so far. Even with Y register display I don't think this particular issue is the worst bottleneck but it was an obvious one to optimize.

What I did is very simple:
1. If the number of digits actually produced is fewer than requested, the iteration switches to that number instantly because there's no point in trying the intermediate values. There's no need to count anything: set_x_dn() already keeps track of the number of digits used, I just made it return that value to annunciators().
2. The number of requested digits is further reduced in each iteration by a value calculated from the number of pixels by which we went beyond the 43 pixel limit.
The worst case I've seen is 4 iterations (vs. 10 in the original code) and it's usually only 2.

I'll put the code in SVN once a final decision has been made about how to organize it (please see the private message). If you can create a better version using binary search, I'd be interested to see it.

(02-11-2014 07:59 PM)Paul Dale Wrote:  The press and hold to display the function which then nulls out might confound things here.

Those cases should be handled correctly because only data entry operations are affected, functions aren't. I wouldn't be surprised if there were still some problems to sort out as I haven't had much time to test this latest version, so please report the bugs.

[Marcus von Cube]

Bit,

instead of optimizing the code you could have simply increased the processor speed when updating the display. IIRC the processor is run at a relatively moderate speed in data entry mode to conserve battery power.

[Jeff O.]

(02-12-2014 04:51 AM)Bit Wrote:  There's one issue you can disregard: In fraction and HMS mode the minus sign is missing in the Y register display. The fix is trivial and I've had it for a long time, I just forgot to apply it when I compiled the last binary.

If you compile a new version and replace the one in this thread, let us know. I don't use fraction or HMS mode much (if ever), but I would want to have the latest and greatest version.

[Jonathan Cameron]

Now that I have a working programming cable, I applied this patch and burned on an extra 30b here. After playing around with it, I noticed a possible bug with complex numbers. Do this:

• Switch to RAD mode
• Enter a complex number: 2 [Enter] 1 [R->P]
  

The display shows:
< 1.107
2.236

Where I am using '<' for the nice angle symbol on line 2.

Now switch to degree mode. The display remains the same (although there is a different annunciator : instead of <.

However, if you start in degree mode, you see:

< 63.43
2.236

Ideally, switching angle mode would update line 2 to change the angle value appropriately.

-Jonathan

[Paul Dale]

Not a bug and not going to happen.
It is not generally possible to know that Y contains an angle here. It is just a number.


- Pauli

[Bit]

(02-12-2014 09:21 PM)Marcus von Cube Wrote:  Bit,

instead of optimizing the code you could have simply increased the processor speed when updating the display. IIRC the processor is run at a relatively moderate speed in data entry mode to conserve battery power.

Hi Marcus,

That's basically a trade-off between firmware size and battery life.

The increase in firmware size can be easily calculated: currently about 168 bytes with all of the optimizations enabled. I cannot guess how much the battery life would decrease if we increased the speed and kept the smaller but less efficient code. Can you comment on that?

In the meantime I've been working on two things:
1. I've increased the responsiveness a tiny bit more by eliminating some more unnecessary screen updates, specifically when invoking functions. This doesn't produce such a dramatic improvement as we've seen previously but it's worth the effort because once my other optimizations are in place, it barely increases the size of the firmware further.
2. I've folded the niladic(), monadic() etc. functions in xeq.c together, moving their functionality into a universal dispatch function. This reduces firmware size by over 256 bytes, which is not a lot but it helps offset a part of the increase in size that my other changes cause.

I'll post an updated binary as soon as I can, but like most people I have a day job as well as other obligations, so it might take a little while.

[Bit]

(02-17-2014 02:12 AM)Jonathan Cameron Wrote:  Ideally, switching angle mode would update line 2 to change the angle value appropriately.

Pauli is right, the angle indicator is supposed to disappear and the calculator doesn't know it should convert the angle because it doesn't keep track of coordinate conversions across other operations like switching to degree mode.

This could be changed but my guess is it'd cause a rather big increase in firmware size so I'm not sure it'd be worth it.

(The ':' indicator shows the stack size: double, i.e. 8, in your case. A '.' would be shown if you switched to a 4 level stack.)

[Paul Dale]

(02-18-2014 02:40 AM)Bit Wrote:  2. I've folded the niladic(), monadic() etc. functions in xeq.c together, moving their functionality into a universal dispatch function. This reduces firmware size by over 256 bytes, which is not a lot but it helps offset a part of the increase in size that my other changes cause.

I toyed with doing this a couple of times. I'd have gone a step further and merged the function tables too. The 43S firmware would have gone this way -- assuming there is still a big table of functions.


- Pauli

[Paul Dale]

(02-18-2014 02:50 AM)Bit Wrote:  This could be changed but my guess is it'd cause a rather big increase in firmware size so I'm not sure it'd be worth it.

You might have more difficulty locating the free persistent RAM to remember this.


- Pauli

[Marcus von Cube]

(02-18-2014 02:40 AM)Bit Wrote:  That's basically a trade-off between firmware size and battery life.

The increase in firmware size can be easily calculated: currently about 168 bytes with all of the optimizations enabled. I cannot guess how much the battery life would decrease if we increased the speed and kept the smaller but less efficient code. Can you comment on that?

I vote for code optimization over clock speed increase. I have no idea how bad battery life would be affected by increasing the clock frequency. It's still worthwhile to think about the latter if the device gets to sluggy despite all code improvements.

(02-18-2014 02:40 AM)Bit Wrote:  In the meantime I've been working on two things:
1. I've increased the responsiveness a tiny bit more by eliminating some more unnecessary screen updates, specifically when invoking functions. This doesn't produce such a dramatic improvement as we've seen previously but it's worth the effort because once my other optimizations are in place, it barely increases the size of the firmware further.
2. I've folded the niladic(), monadic() etc. functions in xeq.c together, moving their functionality into a universal dispatch function. This reduces firmware size by over 256 bytes, which is not a lot but it helps offset a part of the increase in size that my other changes cause.

Ad 1: You'll need to test if all temporary displays and PSE still work as expected. The whole display update stuff is quite a mess, in parts introduced by me.

Ad 2: Don't forget to update the post processing code which is used during the build to replace 32 bit code addresses by 16 bit tokens. All function tables exist in two variants: The condensed version which goes to flash and the source version which is read by the post processor to update the condensed tables.

Do you think your Y display code can be modified so that it is user selectable instead of a compile time option? We'll need to find a bit to store this. We could use flag Y or add another MODE option, maybe sacrificing some other arcane setting.

[RMollov]

I've installed this and it is BEAUTIFUL! Works perfectly.
Thanks Bit, great job!

[Bit]

(02-18-2014 06:11 AM)Paul Dale Wrote:  

(02-18-2014 02:40 AM)Bit Wrote:  2. I've folded the niladic(), monadic() etc. functions in xeq.c together, moving their functionality into a universal dispatch function. This reduces firmware size by over 256 bytes, which is not a lot but it helps offset a part of the increase in size that my other changes cause.

I toyed with doing this a couple of times. I'd have gone a step further and merged the function tables too. The 43S firmware would have gone this way -- assuming there is still a big table of functions.


- Pauli

Merging the functions was easy, I'm not sure about the function tables, but perhaps that's only because I'm not as familiar with the code as you are. It sounds like a good idea, I might look into it later.