A few days ago I noticed that my WP34S has become "slow". I just upgraded it now, but it's still slow. I'm not talking about programs - I haven't checked them - but about "user interface"... If I very quickly type "123456789", when I'm done typing the machine is only displaying "1234", and I can actually see the following digits appearing one by one, at a speed of about 3 per second. Once, while doing this experiment, the machine also locked-up after displaying "123", and I had to reset it.
Has anyone seen this behaviour?

Thank you,
Cristian

I have had something that might be related to this. Sometimes a key stroke is not accepted and insted "NULL" is displayed after a while as if I had held down the key (which I have not). I have seen this a couple of times so far, but haven't found a way to reproduce this behaviour.
Maybe something to do with powersave?

I've seen this too! More than a couple of times. Especially when I push the key very quickly, it seems as if the calculator detects the "key-down" event but not the "key-up", so it thinks the key is being held down.
It happens rarely, and in a non-reproducible way. Both in SLOW and FAST mode.
My BATT level is 2.9...

Cristian

The 'NULL' shouldn't happen. :-(

The slow digit entry has to do with power saving. During data entry, the chip is running at a lame 2 MHz. This is normally fast enough for digit typing but may lead to strange effects as you have noticed. I think I will change it to speed things up if the keyboard buffer starts filling.

Power saving is more of an art than exact science.

Edit: Even if not at home but in a hotel lobby (waiting for Meindert t show up) I tried to fix the speed issue. A new image is committed to SVN. Would you please try (which I can't from here)?

Edited: 1 Mar 2012, 11:33 a.m.

Quote:

---

I have had something that might be related to this. Sometimes a key stroke is not accepted and insted "NULL" is displayed after a while as if I had held down the key (which I have not).

---

I noticed similar behavior with a 30b I bought back in January. At first I thought it was due to being v3, as up to that point I had used v2.2 on a different unit with no problems. So I loaded v2.2 onto the new unit, and got the same behavior. So I put the 30b native software back on it, and found that the same keys did not respond reliably, which led me to the conclusion that my unit (a 4CY factory unit) had a bad keyboard.

Edited: 7 Mar 2012, 1:18 p.m. after one or more responses were posted

Hi Marcus,
The speed issue is much much better! I can still type (in special test scenarios, not real life) faster than the display can update, but now it can "draw" about 9 digits per seconds instead of 3. Thank you! :)

Cristian

Quote:

---

So I put the 30b native software back on it, and found that the same keys did not respond reliably, which led me to the conclusion that my unit (a 4CY factory unit) had a bad keyboard. I called HP support and they are sending a replacement.

---

Mine are 4CY04300429 and 4CY04300430. I have seen this on both machines. Maybe it is a hardware issue?

There is an explanation for this: I still run the processor at 2MB on a key press unless there is another key in the buffer waiting for attention. In this case, speed is increased to 20 MHz. So most of the time, 2MHZ is never exceeded, saving the batteries.

Today I made some more testing of the NULL problem. Seems like I can reproduce it "almost" consistently.
It all has to do with how long the key is kept down. And I have made it happen with many different keys (which by the way usually work very well). To make it happen, I try to "tap" the key as quickly as possible, sort of "bouncing" my finger on it. This test mustn't be too good on the keyboard, but I had to try. I had the NULL problem happen with the +, -, *, /, x<>y keys and a few others.
When I tapped the key really fast, I got the NULL problem maybe one out of six times... more or less.
It really looks like the calc can't detect the "key_up" event if it happens too soon after the "key_down" event...

Cristian

Quote:

---

Today I made some more testing of the NULL problem. Seems like I can reproduce it "almost" consistently.
It all has to do with how long the key is kept down.

...

It really looks like the calc can't detect the "key_up" event if it happens too soon after the "key_down" event...

---

I made the debounce for key down work differently than I used to do it. The reason is the key mechanism (rotate and click) which demands immediate reaction on a key press as soon as the tactile feedback is perceived. So I decided to do the debounce on key-up (need to see the key released in two consecutive scans to allow the next key press to be detected). My key-up detection mechanism wasn't adapted to this change. It should be fixed now but if you encounter any strange behavior, I will have to refine the algorithm further. It might happen that key-up is detected when it shouldn't, especially on a bouncy keyboard.

I tried the latest build (2628) and I couldn't get any NULL problems anymore. I don't know what you mean by "strange" behaviour, but it seems OK here... Maybe the calc is missing a few keystrokes, but only during my "fast-tap" experiments - when entering digits, even at my top typing speed, all presses are detected.

Cristian

I only changed the key-up detection. A thorough look into my code made me confident that no more issues should arise (fingers crossed).

That your keyboard staccato may lead to lost key presses is normal: Somehow a 'bounce' needs to be defined and if your typing behaviour matches the definition the key press is (and needs to be) ignored.

Marcus... Would a repeated total crash be considered "strange behaviour"? :) I had three crashes today, all three only recoverable with the reset button, and all three while entering digits.
I have had a few crashes in the past months, but never three in a day, so I wonder if it might be related to the recent changes...

Cristian

A crash is always undesirable. :-(

I don't think it's directly related to the speed update because this happens in the same way as all other speed updates, somewhere in the main loop and never in an interrupt or such. The key-up changes are not very likely to directly cause a crash either, at least not that I can see it.

Running the device at 20 MHz is obviously something different than at 2 MHz and external influences (ESD) may play a greater role. Are your batteries fresh? Are you typing fast?

If it helps I can revert the speed-up for you to test.

Edit: I've committed a special build for you to test. It does not contain the speed up.

Edited: 3 Mar 2012, 4:54 a.m.

Hi Marcus,
I was not doing anything special, just some money sum/multiplication at work (small numbers). I do type quite fast, but not *really* fast, not nearly as fast as my "tapping tests".
I don't have the calculator with me right now so I can't test it... What build number should I try? I can try it later today.

Oh, my batteries are not new (a few months old) but BATT reads 2.9.

Cristian

The latest SVN revision (2630) does not have the speed-up modification. 2.9V should be OK.

If the problems persist, can you issue the command SLOW which will permanently limit the speed to 20MHz, avoiding the full speed @ 36MHz.