Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Hillshum:
Take an OF image from wherever, name it c200pt.bin, and load it on sansa. Go to Settings>Diagostic and follow that.
RockRabbit:
--- Quote from: Hillshum on December 19, 2008, 10:28:08 PM ---Take an OF image from wherever, name it c200pt.bin, and load it on sansa. Go to Settings>Diagostic and follow that.
--- End quote ---
thanks
I ran the diagnostics - dram size shows as only 2MB. From version 1 to 2 we seem to have dropped 30 mbytes. Is that a show stopper for some of the more advanced rockbox functionality?
I have a bootloader which tests for a button press in a continuous loop. If i press the button that is being detected in the loop, the loop detects the button press continuously, even after one single press. Somehow the pin is not being reset. However the code appears to do this:
ldr r0, =GPIOA
mov r1, #0
str r1, [r0, #0x400]
ldr r1, [r0, #(1<<5)] /* read pin A3 */
cmp r1, #0
beq tpwr
The third line (str...) as far as i know is the code to reset the pin. Can anyone explain what I am missing or why one press should keep the pin set (low in this case).?
atomikpunk:
Well when you read the GPIO, you do read the state of the pin, not a single button press edge, so yes, this is normal. Every read with a button pressed will do the same. And since the code runs awfully fast compared to the speed of a finger, you'll probably always get multiple button pressed state in your loops... You can do something like "if button is pressed, loop until it is unpressed again before continuing" if that's really what you want... But I'd also put a limit to that waiting in case something goes wrong...
Oh and the third line is to set the pin as an input, not to reset its state :)
RockRabbit:
--- Quote from: atomikpunk on December 20, 2008, 08:17:38 AM ---Well when you read the GPIO, you do read the state of the pin, not a single button press edge, so yes, this is normal. Every read with a button pressed will do the same. And since the code runs awfully fast compared to the speed of a finger, you'll probably always get multiple button pressed state in your loops... You can do something like "if button is pressed, loop until it is unpressed again before continuing" if that's really what you want... But I'd also put a limit to that waiting in case something goes wrong...
Oh and the third line is to set the pin as an input, not to reset its state :)
--- End quote ---
Thanks.
I understand what you are saying, but that does not explain my situation. When I detect the pin signal (low in this case), i execute a subroutine that flashes the button light on and off three times - which takes about 6 seconds. By the time this loop has completed, the button has been released some five seconds ago. The code then resumes the original loop looking at the state of the pin. It immediately detects the pin is low and begins the flashing routine, despite the button being unpressed. In other words the pin state is now "on" and will remain so, presumably till the battery goes flat or I get an epileptic fit watching the flashing button.
Either the pin remains at the button pressed state until "reset" (whatever that means) which seems impossible, or I have a bug in my code - but im damned if I can see it.
Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).
saratoga:
--- Quote from: RockRabbit on December 20, 2008, 03:35:30 PM ---Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).
--- End quote ---
Its somewhat of a problem, see for example the Clip which also has 2MB.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version