FS#10603 - AMS Sansa: refactor DBOP button reading
Opened by Bertrik Sikken (bertrik) - Saturday, 12 September 2009, 09:26 GMT
Last edited by Rafaël Carré (funman) - Wednesday, 06 January 2010, 23:41 GMT
Some of the AMS Sansas use the same set of pins (DBOP data pins) both for reading buttons and for writing data to the display. This patch updates the way the reads and writes are coordinated and unifies the way the button reads are done for the c200v2, e200v2 and fuze.
* there are now *two* mechanisms for the fuze and e200v2 to read the buttons: 1) doing a DBOP read and 2) doing a GPIO read.
* as far as I can tell, there is no coordination between LCD writing and doing a GPIO read. This is bad because the GPIO read switches the function of the DBOP data pins from DBOP to GPIO while an LCD write is possibly in progress. I think this is the reason for the sporadic "blue bars" on the fuze/e200v2 display.
* the mechanism to prevent contention between DBOP read (buttons) and DBOP write (lcd) is quite primitive: it just skips a DBOP read when a DBOP write is busy, so there is no guarantee how often a DBOP read is actually done.
* the kernel tick interval has been decreased to 5 ms on the fuze and e200v2 presumably to get more DBOP readings for smooth scrollwheel readout, yet a full LCD update takes about 10 ms on fuze/e200v2 and blocks DBOP reads during that time.
* the DBOP read procedure is to first do a "red-pixel" write to the DBOP/LCD then read the DBOP data pin value back. There is a simpler way to read the DBOP data pins, without involving the LCD.
This patch addresses these issues as follows:
A new dbop-as3525.c modules is added with three functions:
* dbop_lock is called by the LCD functions when they want to do an LCD write (e.g. lcd update, which takes up to 10 ms). The dbop_lock function first takes an input sample from the DBOP data pins.
* dbop_unlock is called by the LCD functions when they are done writing for the time being.
* dbop_input is called by the button driver and either reads the DBOP input directly (when not locked) or returns the most recent DBOP input sample taken in dbop_lock. This way it is guaranteed that the sample is never more than 10 ms old (fuze/e200v2), even when the LCD is very busy.
The button code and the lcd code now both refer to this new dbop-as3525 module, so the button code no longer needs to refer to the lcd code.
The dbop_input function reads the DBOP data pins by "pre-charging" the data pins to a defined level and reading them back after a fixed delay to see if they changed (when a button was pressed). This delay (31 PCLKs) is independent of CPU boost status, unlike the GPIO delays currently used. The LCD doesn't "see" this write/read cycle because the LCD write strobe line is temporarily disabled in dbop_input. This mechanism is simpler (and even faster) than the "red-pixel" method. The c200v2 can not even read all buttons with the red-pixel method.
The GPIO method of reading the DBOP data pins is completely removed.
The kernel tick rate is restored to the default 100 Hz.
This code has been tested to work on a c200v2 and e200v2 (briefly), not tested yet on a fuze.
Wednesday, 06 January 2010, 23:41 GMT
Reason for closing: Accepted
Additional comments about closing: r24192