kawal547 / open9x

Automatically exported from code.google.com/p/open9x
0 stars 0 forks source link

DBLKEYS=YES does not appear to work at all (r1375 V4 board) #133

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. svn up
2. make PCB=V$ ... DBLKEYS=YES ...
3. flash
4. Use of +/- or +/dwn etc doesn't do anything (other than what it would have 
before the DBLKEYS feature was added.)

I should note that I've never tested this before, because I didn't realise what 
it was (I thought it meant double-click or something). So I don't know if it 
ever was working (on the V4 board).

Original issue reported on code.google.com by gru...@gmail.com on 9 Sep 2012 at 10:27

GoogleCodeExporter commented 8 years ago
That should have read, "make PCB=V4", of course.

Original comment by gru...@gmail.com on 9 Sep 2012 at 10:28

GoogleCodeExporter commented 8 years ago
Are you in EDIT mode when doing this? 

Original comment by bson...@gmail.com on 18 Sep 2012 at 9:47

GoogleCodeExporter commented 8 years ago
Yes.

Oddly, a test I just did on r1365 has some of the DBLKEYS stuff working, namely 
the [LEFT][RIGHT]=invert part. But the max, min and default still do not.

Could it be due to the different port connections on the G(X v4 board? I 
confess, I've not even tried to find where the code for this is.

BTW, I am going only by comments found in Makefile, thus ...

# Double keys support (+/- means invert, +/up means max, -/dwn means min, 
up/down means reset to default)
# Values = YES, NO 
DBLKEYS = NO

Original comment by gru...@gmail.com on 19 Sep 2012 at 12:24

GoogleCodeExporter commented 8 years ago
Would you check around this line:
open9x.h:250
Thanks!

Original comment by bson...@gmail.com on 19 Sep 2012 at 6:45

GoogleCodeExporter commented 8 years ago
Yeah, that's where the problem is alright. The variable in has its bits 
rearranged ...

  in = (tin & 0x0f) << 3;
  in |= (tin & 0x30) >> 3;

... but the DBLKEYS_PRESSED_* macros check the original bit positions. This 
latter part is not the problem. The short-cut I took with the bit shifting is 
the problem. My bad.

Also, the variable names were incorrect. Should be all INP_L*, not INP_P. My 
bad also, I'm sure. I've corrected them all and committed the changes (r1405). 

But I haven't figured out how to get rid of the bit-rearrangements, as noted 
above. Can you point me in the right direction for the code to do with that? We 
need to make the event detection work with the actual hardware bit positions on 
PORTL for the G9X board, rather than shifting them about to be compatible with 
the original PCB=STD code and bit positions, as I have lazily done here.

... unless you have a better idea. :-D

Thanks.

Original comment by gru...@gmail.com on 19 Sep 2012 at 7:13

GoogleCodeExporter commented 8 years ago
Do you mean that changing the KEY_PRESSED() function in open9x.h:241 to this 
only line would solve our problem?

#define KEYS_PRESSED() (~PINL)

Original comment by bson...@gmail.com on 19 Sep 2012 at 7:49

GoogleCodeExporter commented 8 years ago
I am not sure. If this KEYS_PRESSED macro is only used for detecting double 
keys, then I guess your suggestion will be OK. Oh ... OK. I just ran grep a few 
times. Before, I thought the macro must be used elsewhere. But now, I think 
not, because I just found the original code still present here ... 
board_gruvin9x.cpp line 284.

So I will try your suggestion now. I think it should work. Will report back 
here soon.

Original comment by gru...@gmail.com on 19 Sep 2012 at 9:03

GoogleCodeExporter commented 8 years ago
Yes, that works well. So easy, in the end! :-D All other key functions appear 
to be still working OK. Whew! :-D 

Committed the changes in r1406.

Thanks for your help.

Original comment by gru...@gmail.com on 19 Sep 2012 at 9:13