Threaded Mode | Linear Mode

Nigel (UK) · 04-19-2015, 06:22 PM

The latest code is now posted. There are no large changes in the user interface.

Entry and calculation in polar display mode is now consistently rapid.
H.MS display mode now works as I intended it to. In polar display mode, pressing H.MS will change the display format of the angle only, and only if the current angle mode is degrees. Outside of complex lock mode H.MS behaves normally.
Following a suggestion from Pauli the code no longer uses user flags as flags. Instead, two RAM program steps have been sacrificed to provide space for 32 further flags in RAM. (Getting rid of just one step seemed to spoil the alignment of the PersistentRam structure.) These flags are made available by the EXTRA_FLAGS option in features.h which can be used independently of complex lock mode if you extract the relevant parts from the patch file.
Minor bug fixes.
Reduction in code size - calc.bin now shows 3070 steps free in flash, and even calc_ir.bin still has 500 steps free - not many, but at least the number is now positive!

Warning: the change from user flags to extra flags in the persistent RAM memory space means that any programs in your calculator RAM may well be erased when you update. It is also possible that when I did this I introduced major bugs, although I haven't yet found any in the code that I have posted. Proceed with care! (for the next few days, at least.)

To help me reduce code size further it would be useful to know if there are any features described in the documentation that no-one wants. Any suggestions?

Nigel (UK)

emece67 · 04-22-2015, 12:17 AM

(04-19-2015 06:22 PM)Nigel (UK) Wrote: To help me reduce code size further it would be useful to know if there are any features described in the documentation that no-one wants. Any suggestions?

Sorry but I cannot help here. This complex lock mode is superb as it is. Thanks for it!

Paul Dale · 04-22-2015, 04:56 AM

(04-19-2015 06:22 PM)Nigel (UK) Wrote: To help me reduce code size further it would be useful to know if there are any features described in the documentation that no-one wants. Any suggestions?

I doubt you'll find operations no one wants Smile

Better to ask those who use complex numbers heavily what features they don't want. You're much more likely to get some from this group Smile

Pauli

walter b · 04-22-2015, 05:47 AM

The WP 34cpx is a separate branch anyway, so I concur.

d:-)

Nigel (UK) · 04-22-2015, 09:34 AM

(04-22-2015 04:56 AM)Paul Dale Wrote:
(04-19-2015 06:22 PM)Nigel (UK) Wrote: To help me reduce code size further it would be useful to know if there are any features described in the documentation that no-one wants. Any suggestions?

I doubt you'll find operations no one wants

Better to ask those who use complex numbers heavily what features they don't want. You're much more likely to get some from this group

Pauli

I'm a little confused. I thought that I was asking this! To be clear, what I'd like to know is whether any of the people likely to use complex lock mode consider any of its features (as described in the documentation attached to the first post in this thread) to be unnecessary, so that the code could be made smaller.

...or are you suggesting that I ask complex number users what features of the standard WP-34s firmware they would happily wave "good-bye" to? That would be interesting to know as well.

Nigel (UK)

Paul Dale · 04-22-2015, 09:48 AM

(04-22-2015 09:34 AM)Nigel (UK) Wrote: ...or are you suggesting that I ask complex number users what features of the standard WP-34s firmware they would happily wave "good-bye" to? That would be interesting to know as well.

This is exactly what I meant. Flash is full and life is short. There are plenty of functions which the 34S has that are not all that suitable for heavy complex number folks -- orthogonal polynomials, zeta function, statistical distributions, ....

Personally, I'd much prefer to keep and expand these and ditch all the complex support but that wouldn't go down well with our user community Smile

- Pauli

emece67 · (This post was last modified: 04-22-2015 10:47 AM by emece67.)

(04-22-2015 09:48 AM)Paul Dale Wrote: This is exactly what I meant. Flash is full and life is short. There are plenty of functions which the 34S has that are not all that suitable for heavy complex number folks -- orthogonal polynomials, zeta function, statistical distributions, ....

I do not know if the calc.bin file linked in this thread supports the stopwatch/time functions and IR printing. In such case they are my first candidates to be removed. (Although, in fact, I suppose that, with some effort, I would be able to compile the firmware with the complex mode lock patches and w/o IR and time).

The next candidates, for me, are: graphic block functions, orthogonal polynomials, Bernouilly & Fibonacci numbers, Lambert's W, Riemman's Z & Gudermann.

But, please, do not remove the statistical distributions.

walter b · 04-22-2015, 03:13 PM

(04-22-2015 09:34 AM)Nigel (UK) Wrote: ... what I'd like to know is whether any of the people likely to use complex lock mode consider any of its features (as described in the documentation attached to the first post in this thread) to be unnecessary, so that the code could be made smaller.

I'm with Nigel in this matter. Basis is that there will be a separate firmware branch for a WP 34CPX for complex users (well, you know what I mean Wink

). I wouldn't put complex lock mode into standard WP 34S firmware since many users won't employ complex functions heavily (or even at all).

d:-)

Nigel (UK) · 04-22-2015, 08:40 PM

(04-22-2015 10:44 AM)emece67 Wrote:
(04-22-2015 09:48 AM)Paul Dale Wrote: This is exactly what I meant. Flash is full and life is short. There are plenty of functions which the 34S has that are not all that suitable for heavy complex number folks -- orthogonal polynomials, zeta function, statistical distributions, ....

I do not know if the calc.bin file linked in this thread supports the stopwatch/time functions and IR printing. In such case they are my first candidates to be removed. (Although, in fact, I suppose that, with some effort, I would be able to compile the firmware with the complex mode lock patches and w/o IR and time).

The next candidates, for me, are: graphic block functions, orthogonal polynomials, Bernouilly & Fibonacci numbers, Lambert's W, Riemman's Z & Gudermann.

But, please, do not remove the statistical distributions.

calc.bin does not contain the code for IR printing or for the stopwatch, which is why it still has a good amount of free flash for program storage. I think that calc.bin is fine as it is. The memory problem is only real for those who do use the IR printing and only have (at present) 500 free program steps in flash memory when complex lock mode is compiled in.

No-one who uses complex lock mode seems to want anything removed from it, so I'll work on optimising the code as it is, without cutting anything out.

For those who want more free flash a series of compile-time options in features.h could allow specific parts of the standard WP-34s firmware to be disabled as they choose. Don't worry - complex lock mode and the statistical distributions (an outstanding feature of this calculator) can continue to co-exist!

Nigel (UK)

Jeff O. · 04-24-2015, 05:44 PM

(04-19-2015 06:22 PM)Nigel (UK) Wrote: The latest code is now posted. There are no large changes in the user interface.

Entry and calculation in polar display mode is now consistently rapid.

I finally loaded the latest version. Polar mode is now quite responsive and totally usable. Nice work!

(04-19-2015 06:22 PM)Nigel (UK) Wrote: Warning: the change from user flags to extra flags in the persistent RAM memory space means that any programs in your calculator RAM may well be erased when you update. It is also possible that when I did this I introduced major bugs, although I haven't yet found any in the code that I have posted. Proceed with care! (for the next few days, at least.)

My Sunrise/Sunset program was still there upon loading the new version. It did suffer the recurring problem of having various commands changed to others or occasionally to "???". It seemed to have more of these problems this time than after previous updates, but it is possible that I did not look for and fix such problems after the last update, so perhaps this was a "double batch".

(04-19-2015 06:22 PM)Nigel (UK) Wrote: To help me reduce code size further it would be useful to know if there are any features described in the documentation that no-one wants. Any suggestions?

I agree with others, if possible, none of the features you have included in your complex mode should be removed.

(04-22-2015 08:40 PM)Nigel (UK) Wrote: calc.bin does not contain the code for IR printing or for the stopwatch, which is why it still has a good amount of free flash for program storage. I think that calc.bin is fine as it is. The memory problem is only real for those who do use the IR printing and only have (at present) 500 free program steps in flash memory when complex lock mode is compiled in.

How much flash for a version with just the stopwatch functions? I ask because it seems to me that while IR printing is a cool feature, adding the crystal provides the benefits of reliable emulator to real calculator communication (in addition to the date, time and stopwatch functions, of course) and so is probably more useful to more people if it could be included by itself without IR printer support.

Is there a correspondence between the available bytes of flash and number program steps that may be stored? In other words, how much flash is required to save 500 lines of programming, 1000 lines, etc.?

(04-22-2015 08:40 PM)Nigel (UK) Wrote: No-one who uses complex lock mode seems to want anything removed from it, so I'll work on optimising the code as it is, without cutting anything out.

So far you are doing great.

(04-22-2015 08:40 PM)Nigel (UK) Wrote: For those who want more free flash a series of compile-time options in features.h could allow specific parts of the standard WP-34s firmware to be disabled as they choose.

One of these days I would like to learn how to do so. I like to think that I have the capability, although that is far from certain. Until then, I must depend on the kindness of people like you. Luckily for me, you are very kind indeed!

Jeff

Nigel (UK) · 04-26-2015, 09:10 PM

(04-24-2015 05:44 PM)Jeff O. Wrote:
(04-22-2015 08:40 PM)Nigel (UK) Wrote: calc.bin does not contain the code for IR printing or for the stopwatch, which is why it still has a good amount of free flash for program storage. I think that calc.bin is fine as it is. The memory problem is only real for those who do use the IR printing and only have (at present) 500 free program steps in flash memory when complex lock mode is compiled in.

How much flash for a version with just the stopwatch functions? I ask because it seems to me that while IR printing is a cool feature, adding the crystal provides the benefits of reliable emulator to real calculator communication (in addition to the date, time and stopwatch functions, of course) and so is probably more useful to more people if it could be included by itself without IR printer support.

Is there a correspondence between the available bytes of flash and number program steps that may be stored? In other words, how much flash is required to save 500 lines of programming, 1000 lines, etc.?

The crystal version (containing the stopwatch code) had space for 1920 program steps in flash. Each program step requires two bytes of flash memory.

(04-24-2015 05:44 PM)Jeff O. Wrote:
(04-22-2015 08:40 PM)Nigel (UK) Wrote: No-one who uses complex lock mode seems to want anything removed from it, so I'll work on optimising the code as it is, without cutting anything out.

So far you are doing great.

Thank you!

(04-24-2015 05:44 PM)Jeff O. Wrote:
(04-22-2015 08:40 PM)Nigel (UK) Wrote: For those who want more free flash a series of compile-time options in features.h could allow specific parts of the standard WP-34s firmware to be disabled as they choose.

One of these days I would like to learn how to do so. I like to think that I have the capability, although that is far from certain. Until then, I must depend on the kindness of people like you. Luckily for me, you are very kind indeed!

Jeff

It isn't nearly as hard as it might seem. I followed other people's instructions and it worked - my experiences are detailed here. The biggest problem is getting versions of the gnu compilers that actually work. Once you have found a version that works, never update it! No programming is needed to change compiler options - just edit one file and recompile.

Nigel (UK)

Jeff O. · 04-29-2015, 12:18 PM

(04-26-2015 09:10 PM)Nigel (UK) Wrote: The crystal version (containing the stopwatch code) had space for 1920 program steps in flash. Each program step requires two bytes of flash memory.

That sounds reasonable. If you get some spare time, could you compile such a version and make it available?

(04-26-2015 09:10 PM)Nigel (UK) Wrote: It isn't nearly as hard as it might seem. I followed other people's instructions and it worked - my experiences are detailed here.

Thanks for the information! I will review it and see if it looks like something I would be capable of doing.

emece67 · 04-29-2015, 02:02 PM

If this complex mode lock will be a separated branch from the trunk, perhaps the CPXYES and CPXNO commands can be removed.

Not a big saving, I suppose.

Regards.

BarryMead · (This post was last modified: 05-03-2015 01:29 AM by BarryMead.)

(04-29-2015 02:02 PM)emece67 Wrote: If this complex mode lock will be a separated branch from the trunk, perhaps the CPXYES and CPXNO commands can be removed.

The last time I tried to check out the entire source tree with the command:
svn checkout svn://svn.code.sf.net/p/wp34s/code wp34s
I did not see a separate wp-34i or wp-34cpx branch. When will this new branch of the source tree be part of the official svn repository? The reason I am asking this question is because I created separate icons on my desktop for the Normal, and Complex WP-34s QT emulators and the way it works now the QT emulator under Linux uses the same $HOME/.config/WP-34s/ directory to store the wp34s.dat memory file for the complex emulator as it does for the normal emulator, and they are not compatible with each other. So after I run the Complex QT emulator I have to clear memory and reconfigure the display modes to switch back to the normal QT emulator and visa versa. It would be nice if the complex QT emulator had it's own $HOME/.config/WP-34CPX directory to store it's memory file to so that switching from the normal to complex QT emulators would not corrupt the memory file. If I run the non-QT emulator this is not an issue, because the wp34s.dat file for the non-QT emulator is stored in the same directory as the executable, so you can avoid cross-corruption by placing the normal and complex non-QT emulators in separate executable directories. For many reasons I prefer to run the QT emulator. The save directory doesn't seem to be changeable anywhere in the standard source. I think it is a function of the complicated Makefile and build system, but I am not sure. I was hoping that a new memory file save directory would
be automatic as a consequence of the new branch. It worked that way for the WP-31s. If not can anyone advise me as to how/where to make such a change?

BarryMead · (This post was last modified: 05-03-2015 01:57 AM by BarryMead.)

I just tried to apply the latest version of cmode.patch to the latest source tree svn revision 3782, and the Qt Emulator will no-longer compile. The calc.bin REALBUILD image compiles, but the Qt Emulator does not. After applying the "svn patch cmode.patch" command from the primary checkout directory then changing to the trunk/QtGui directory and typing make, I get the following errors:

Code:

ED -o Linux_qt/obj/stopwatch.o stopwatch.c

In file included from stopwatch.c:22:0:

keys.h:64:13: error: ‘finish_cpx_entry’ declared ‘static’ but never defined [-Werror=unused-function]

keys.h:66:12: error: ‘process_cmplx’ declared ‘static’ but never defined [-Werror=unused-function]

keys.h:67:13: error: ‘stack_restore’ declared ‘static’ but never defined [-Werror=unused-function]

cc1: all warnings being treated as errors

make[2]: *** [Linux_qt/obj/stopwatch.o] Error 1

make[2]: Leaving directory `/home/barry/wp34s-3782-Comp/trunk'

make[1]: *** [qt_gui] Error 2

make[1]: Leaving directory `/home/barry/wp34s-3782-Comp/trunk'

make: *** [all] Error 2

I tried recompiling with make clean and make after commenting out the #define INCLUDE STOPWATCH in the features.h and it still would not compile. Do you see the same result when trying to compile the Qt emulator after applying the latest cmode.patch to the latest svn 3782 release ? The previous version of cmode.patch applied to either the 3769 or 3782 release of the source tree has no trouble compiling the Qt emulator. Something in the new cmode.patch broke the Qt emulator's ability to compile.

Nigel (UK) · 05-03-2015, 09:43 PM

(05-03-2015 12:53 AM)BarryMead Wrote: I just tried to apply the latest version of cmode.patch to the latest source tree svn revision 3782, and the Qt Emulator will no-longer compile. The calc.bin REALBUILD image compiles, but the Qt Emulator does not. After applying the "svn patch cmode.patch" command from the primary checkout directory then changing to the trunk/QtGui directory and typing make, I get the following errors:

Code:

ED -o Linux_qt/obj/stopwatch.o stopwatch.c In file included from stopwatch.c:22:0: keys.h:64:13: error: ‘finish_cpx_entry’ declared ‘static’ but never defined [-Werror=unused-function] keys.h:66:12: error: ‘process_cmplx’ declared ‘static’ but never defined [-Werror=unused-function] keys.h:67:13: error: ‘stack_restore’ declared ‘static’ but never defined [-Werror=unused-function] cc1: all warnings being treated as errors make[2]: *** [Linux_qt/obj/stopwatch.o] Error 1 make[2]: Leaving directory `/home/barry/wp34s-3782-Comp/trunk' make[1]: *** [qt_gui] Error 2 make[1]: Leaving directory `/home/barry/wp34s-3782-Comp/trunk' make: *** [all] Error 2

I tried recompiling with make clean and make after commenting out the #define INCLUDE STOPWATCH in the features.h and it still would not compile. Do you see the same result when trying to compile the Qt emulator after applying the latest cmode.patch to the latest svn 3782 release ? The previous version of cmode.patch applied to either the 3769 or 3782 release of the source tree has no trouble compiling the Qt emulator. Something in the new cmode.patch broke the Qt emulator's ability to compile.

Thank you for pointing this out; the latest patch file (I hope) corrects it. I have to confess that I do not have the qt tools installed on my system but with the latest patch the errors I receive are related to missing tools (qmake, etc) rather than the errors about unused static functions that you report above.

I'm sorry about the delay in the separate branch; I have to confess that I wasn't sure how to go about this, but reading the svn documentation has given me the confidence to try. It should happen real soon now! (I'm aiming for tomorrow.)

Nigel (UK)

BarryMead · 05-03-2015, 10:30 PM

(05-03-2015 09:43 PM)Nigel (UK) Wrote: Thank you for pointing this out; the latest patch file (I hope) corrects it.

Thanks Nigel, I can confirm that the latest patch does indeed correct the problem. The Qt emulator now compiles without incident using the latest cmode.patch file.

Nigel (UK) · 05-04-2015, 10:59 PM

(05-03-2015 10:30 PM)BarryMead Wrote:
(05-03-2015 09:43 PM)Nigel (UK) Wrote: Thank you for pointing this out; the latest patch file (I hope) corrects it.
Thanks Nigel, I can confirm that the latest patch does indeed correct the problem. The Qt emulator now compiles without incident using the latest cmode.patch file.

The complex mode branch is now in place. I've changed the compilation options slightly:

Pixel plotting commands disabled
Bit's "Universal Dispatch" code enabled; although still labelled experimental, it seems to work fine
Gudermannian function disabled

...which gives a little more flash space.

The calculator firmware files live in branches/complex_mode/realbuild. calc.bin, calc_xtal.bin, and calc_ir.bin all fit in memory with space to spare.

If this works for people, the patch files can soon be a thing of the past!

Nigel (UK)

emece67 · 05-05-2015, 06:21 PM

Thanks a lot Nigel. It worked for me.

But I'm having a little trouble when compiling it myself. It compiles w/o error and the generated calc.bin works, except for the entry for STOPW being missed in the X.FCN catalog. The calc.bin file downloaded from SVN does have it, but the one I generate shows ??? in that position. I need to #define INCLUDE_STOPWATCH in features.h to have it filled.

The emulator, instead, shows it correctly.

I'm new compiling the wp34, so surely the error is mine. Any help will be welcome.

Nigel (UK) · 05-05-2015, 09:18 PM

(05-05-2015 06:21 PM)emece67 Wrote: Thanks a lot Nigel. It worked for me.

But I'm having a little trouble when compiling it myself. It compiles w/o error and the generated calc.bin works, except for the entry for STOPW being missed in the X.FCN catalog. The calc.bin file downloaded from SVN does have it, but the one I generate shows ??? in that position. I need to #define INCLUDE_STOPWATCH in features.h to have it filled.

The emulator, instead, shows it correctly.

I'm new compiling the wp34, so surely the error is mine. Any help will be welcome.

I don't think it's your fault; I had the same problem myself a few months ago. In the end I got rid of it by changing to an earlier version of the gcc compiler - see this post and the relevant preceding posts in that thread.

The bug was in gcc 4.8.1 and it wasn't in gcc 4.5.2; I don't know about the status of compiler versions between these two. Note that this is the "ordinary" compiler that is used to generate catalogue and constant listings, not the arm cross-compiler.

I hope this helps.

Nigel (UK)