Yes it works now

And I think calc84maniac means the middle of the touchpad which can be "pressed down" like a normal button.

What you describe is a long know error, basically everything works fine but this message.
And I think if ExtendeD knew what the cause is, he would upload a fixed version very quickly
What model of nspire have you between as this error seems to appear never to some people but always to others, so knowing on which hardware the error appears may help to find it (that's what I think at least).




@ExtendeD

Touchpad works fine so far, exept two things.

1) RIGHTDOWN is mapped to LEFTUP
here is the corrected line:
case TPAD_ARROW_RIGHTDOWN:
return report.y <= touchpad_info.height/TPAD_RATIO && report.x >= (touchpad_info.width * (TPAD_RATIO - 1))/TPAD_RATIO;
2) I suppose that since you haven't a Touchpad, you aren't aware of the fact that the touchpad does not only "react" on "touch" but also to "press" on the nine areas.
Actually that's how it is most used in normal OS function, and I think it would be very tiresome to "touch" it when you only want to navigate through a menu etc.
Now the touch will be sure useful in future games but the press is what, as far as I can say, corresponds to the up,down,left etc. keys on the clickpad.
I barely got that line above done so I fear that I can't help there but it would be nice if you add a test for "touchpad pressed".
My proposal is that isKeyPressed() tests for press and a other separate function tests for touch and returns the cords. ( I think that's what touchpad_scan() does but I'm not yet so far in the code)

Yes, that is the idea.
I'm not sure if "pressed" means report->contact = TRUE, or if it corresponds to a special threshold of report->proximity, so I don't know how to update ndless_tpad.tns to test it. For you would the sensibility of ndless_tpad.tns be a touched Touchpad or a pressed Touchpad?

The sensibility there is what I would call "touched",
if I make sure to only "press" it (just pressing it on the edges or in the middle with a pencil) , it doesn't even react.
EDIT: just noticed that the OS doesn't react either in that case...

EDIT2:
I tested a bit and I come to the following conclusion:
the touchpad is one key which can be "pressed", but it makes no difference where you press.
the "touch" is registered separate on the surface of this key, but only if the "key" is not pressed.

I believe that the OS if you press par example down, first registers the location where you touch while your pressure isn't yet high and then as soon as you have pressed it down the OS reacts like pressing the down key on the clickpad.
This would at least explain the following bug: if you press in a menu first down and then press very quickly up the OS reacts still as if you pressed down.(probably since he didn't have time to updated the "touched" location.)

This are now my wild guesses and I may be wrong, so everyone who has a touchpad, feel free to correct me if you think I'm wrong.

the limit seems to correspond to the point where the OS would actually start to display a mouse and not in any way, if "pressed" or not.
If it is good or not, depends directly from where you using it, for "porting" clickpad games it is probably low enough but I can easily think of scenarios where in may need more sensitivity.

But I think I have to take back

the "touch" is registered separate on the surface of this key, but only if the "key" is not pressed.

this misinterpretation origins from my habit to press the touchpad on its borders, where the proximity is much inferior to what it is half a mm more to the middle  (what probably also is the cause why isKeyPressed(***) sometimes didn't seem to work for me )

dividing the threshold by two would make sure that the big majority of "presses" are registered, on the cost that miss-presses would be more likely (but still rare if the user hasn't a dexterity problem).

About the pressed limit: To me it doesn't seem as if "touchpad-pressed" is resolved over "proximity", but is reported separate
and that it is at the software to merge "pressed" and "touched at the left" to "pressed left"

at hackspire proximity is on bit 01,
bit 0A has as description,

1 if touchpad pressed down, 0 if not

could that bit therefore make the difference between touched and pressed?

I've noticed that the keypad_type is not updated when you hot-swap the keypad in an Ndless program.
I'm not saying it's a bug: Ndless is simply returning the type that was detected by the OS, and which is not updated anymore as interrupts are disabled.

But it might be usefull for some programs to be able to hot-swap the keypad while a Ndless program is running.


So, is there a way for a Ndless program to detect the current inserted keypad?

shrear, I have just updated libndls to use the "pressed" field returned by the touchpad controller (and the velocity fields are now also available with touchpad_scan()).
So isKeyPressed() should now react as expected, could you please confirm?

Is there anythng to change in the Makefile or in the headers?

I cannot recompile code which did compile on the previous r369.
Error at linking time:
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none
-eabi/bin/ld.exe: c:/ndless/sdk/bin/../lib\libndls.a(touchpad.o): Unknown mandat
ory EABI object attribute 44
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none
-eabi/bin/ld.exe: failed to merge target specific data of file c:/ndless/sdk/bin
/../lib\libndls.a(touchpad.o)
collect2: ld returned 1 exit status
make: *** [mviewer.tns] Error 1
I didn't modify the code, and I've performed a "make clean"...



Edit: It doesn't seem to come from the makefile or from my code...
I cannot even recompile the samples.
Same kind of errors, which all seem to be related to the new libndls:
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none
-eabi/bin/ld.exe: c:/ndless/sdk/bin/../lib\libndls.a(show_msgbox.o): Unknown man
datory EABI object attribute 44
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none
-eabi/bin/ld.exe: failed to merge target specific data of file c:/ndless/sdk/bin
/../lib\libndls.a(show_msgbox.o)
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none
-eabi/bin/ld.exe: c:/ndless/sdk/bin/../lib\libndls.a(sleep.o): Unknown mandatory
 EABI object attribute 44
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none
-eabi/bin/ld.exe: failed to merge target specific data of file c:/ndless/sdk/bin
/../lib\libndls.a(sleep.o)
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none
-eabi/bin/ld.exe: c:/ndless/sdk/bin/../lib\libndls.a(idle.o): Unknown mandatory
EABI object attribute 44
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none
-eabi/bin/ld.exe: failed to merge target specific data of file c:/ndless/sdk/bin
/../lib\libndls.a(idle.o)
collect2: ld returned 1 exit status
make: *** [particles.tns] Error 1