Prev: Erroneous Help Text in Diff Eq Graphing Window Form 49G/50G
Next: e^(ln(x)*y) -> x^y
From: rpe2101 on 21 Jan 2008 01:36
I think there is a problem with the keyb_isAnyKeyPressed function.
I'm attempting the following c code in hpgcc. I am getting an
unexpected result.
If I run the compiled version of the code attached to the bottom and I
hit the '8' button, I expect.
"8"
on the stack, but I get:
"8"
"8"
"8"
"8"
"8"
....and so on until i hit the "on" button to exit the program.
here is the code:

#include <hpgcc49.h>

unsigned rpl_stack_bias;
keymatrix *keys;

int main()
{
while(1){
//Loop indefinitely adding every key that is pressed to the stack.

rpl_stack_bias = sat_stack_init(); // Initialize RPL stack

//wait until a key is pressed (this is the function that I don't
think is working correctly)
while(!keyb_isAnyKeyPressed());

//initialize an empty variable to store the key matrix
keys = (keymatrix *)calloc(1,sizeof(keymatrix));

//store the key matrix
keyb_getmatrix(keys);

//figure out which keys were pressed
switch((*keys).full){
case KB_MASK64(KB_ON):
sat_stack_exit(rpl_stack_bias); //close program
return 0;
break;
case KB_MASK64(KB_0):
sat_stack_push_int(0);
break;
case KB_MASK64(KB_1):
sat_stack_push_int(1);
break;
case KB_MASK64(KB_2):
sat_stack_push_int(2);
break;
case KB_MASK64(KB_3):
sat_stack_push_int(3);
break;
case KB_MASK64(KB_4):
sat_stack_push_int(4);
break;
case KB_MASK64(KB_5):
sat_stack_push_int(5);
break;
case KB_MASK64(KB_6):
sat_stack_push_int(6);
break;
case KB_MASK64(KB_7):
sat_stack_push_int(7);
break;
case KB_MASK64(KB_8):
sat_stack_push_int(8);
break;
default:
sat_stack_exit(rpl_stack_bias); //close program
return 0;
break;
}
free(keys);

} // wait until ON pressed


}

this being my first post here, I'll also include the compiler output
for good measure:
> "dmake.exe" all
arm-elf-gcc -mtune=arm920t -mcpu=arm920t -mlittle-endian -fomit-frame-
pointer -msoft-float -Wall -Os -I../include -L../lib -mthumb-interwork
-mthumb -c kbtest.c
arm-elf-ld -L../lib -T VCld.script ../lib/crt0.o kbtest.o -lhpg -
lhplib -lgcc -o kbtest.exe
elf2hp kbtest.exe kbtest.hp
rm kbtest.exe kbtest.o

> Process Exit Code: 0
> Time Taken: 00:01
From: bokubob on 21 Jan 2008 02:02
On Jan 21, 12:36 am, "rpe2...(a)gmail.com" <rpe2...(a)gmail.com> wrote:
> //wait until a key is pressed (this is the function that I don't
> think is working correctly)
> while(!keyb_isAnyKeyPressed());

I've found that when working with hardware like this, reading things
like this will take a little time (relative to reading/writeing to
RAM) and trying to read them repeatedly doesn't work so well.
So, usually you'll want to write something like:

while(!whatever_you_are_waiting_for()) {
sleep(.1);
}

An alternate explanation is that the HP 50g is actually a quantum
computer, and you're experiencing the quantum zeno effect. (or the
classical "watched pot" analog) In either case, looking away for a
moment will help, and it lets your cpu take a break which helps with
power consumption.

-Jonathan
From: rpe2101 on 21 Jan 2008 09:39
Thanks for your suggestion. I have now tried using a couple different
sleep commands, at a couple widely differing (within reason) sleep
intervals. However, The result is just the slowing down of the number
of times the key "repeats" in the stack before i exit the program, or
just plain system unresponsiveness.

~Robert

On Jan 21, 2:02 am, bokubob <jei...(a)gmail.com> wrote:
> On Jan 21, 12:36 am, "rpe2...(a)gmail.com" <rpe2...(a)gmail.com> wrote:
>
> > //wait until a key is pressed (this is the function that I don't
> > think is working correctly)
> > while(!keyb_isAnyKeyPressed());
>
> I've found that when working with hardware like this, reading things
> like this will take a little time (relative to reading/writeing to
> RAM) and trying to read them repeatedly doesn't work so well.
> So, usually you'll want to write something like:
>
> while(!whatever_you_are_waiting_for()) {
> sleep(.1);
>
> }
>
> An alternate explanation is that the HP 50g is actually a quantum
> computer, and you're experiencing the quantum zeno effect. (or the
> classical "watched pot" analog) In either case, looking away for a
> moment will help, and it lets your cpu take a break which helps with
> power consumption.
>
> -Jonathan



From: rpe2101 on 21 Jan 2008 11:59
I found a fix. In the beggining of the loop have:
while(keyb_isAnyKeyPressed()){}
This waits until everything appears released for the calculator.

On Jan 21, 9:39 am, "rpe2...(a)gmail.com" <rpe2...(a)gmail.com> wrote:
> Thanks for your suggestion. I have now tried using a couple different
> sleep commands, at a couple widely differing (within reason) sleep
> intervals. However, The result is just the slowing down of the number
> of times the key "repeats" in the stack before i exit the program, or
> just plain system unresponsiveness.
>
> ~Robert
>
> On Jan 21, 2:02 am, bokubob <jei...(a)gmail.com> wrote:
>
> > On Jan 21, 12:36 am, "rpe2...(a)gmail.com" <rpe2...(a)gmail.com> wrote:
>
> > > //wait until a key is pressed (this is the function that I don't
> > > think is working correctly)
> > > while(!keyb_isAnyKeyPressed());
>
> > I've found that when working with hardware like this, reading things
> > like this will take a little time (relative to reading/writeing to
> > RAM) and trying to read them repeatedly doesn't work so well.
> > So, usually you'll want to write something like:
>
> > while(!whatever_you_are_waiting_for()) {
> > sleep(.1);
>
> > }
>
> > An alternate explanation is that the HP 50g is actually a quantum
> > computer, and you're experiencing the quantum zeno effect. (or the
> > classical "watched pot" analog) In either case, looking away for a
> > moment will help, and it lets your cpu take a break which helps with
> > power consumption.
>
> > -Jonathan

 | 
Pages: 1
Prev: Erroneous Help Text in Diff Eq Graphing Window Form 49G/50G
Next: e^(ln(x)*y) -> x^y