Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
FlynDice:
The debugclocks info is in svn now but the info displayed is static, ie whatever the state of the frequencies was when the page was displayed will not change for current conditions. This patch will turn the info back to "live" info that will change realtime.
kugel.:
--- Quote from: FlynDice on May 19, 2009, 02:24:05 PM ---The debugclocks info is in svn now but the info displayed is static, ie whatever the state of the frequencies was when the page was displayed will not change for current conditions. This patch will turn the info back to "live" info that will change realtime.
--- End quote ---
The usae of while(1) is weird too. Why not just button_get instead (without the timeout part)?
FlynDice:
--- Quote from: kugel. on May 19, 2009, 02:59:43 PM ---
The usae of while(1) is weird too. Why not just button_get instead (without the timeout part)?
--- End quote ---
Don't look to me for pretty or elegant coding solutions :P. I'm sure you can tell by now I pretty much go find out how someone else did whatever I need done and copy it. If it works great, if not I shake it a little and try again! In fact I think that's a part of your code from the debug io ports that I copied for that part... ;D
Please, if you think you have a better way, change it or tell me how and I will.
kugel.:
--- Quote from: FlynDice on May 19, 2009, 03:21:14 PM --- In fact I think that's a part of your code from the debug io ports that I copied for that part... ;D
--- End quote ---
Haha, seems so :)
You can be sure I only copied other code too :P
FlynDice:
I have had a bit of success with the mmu tonight, not enough to say I have it working but enough to focus on what the problem may be and a taste of what may be possible with the mmu working. I am not going to post a patch yet, maybe later tonight if I can make some more progress. I think there are other folks who could make headway faster so I thought I would just post my findings so far in the hopes that they are useful now. I have been playing around today with a clocking setup of PLLA=384, FCLK=192, PCLK=64, with bus synchronous for boosted and fastbus @ 32MHz unboosted(the performance of this setup was quite acceptable I thought also). I tried the mmu setup I had been working on before the clocking issues came up and got the same i2c problems that go along with that. So I added the delays to ascodec.c and tried again and found I could play music just fine, until the first song ended...... Then it was as if playback locked up. I could still navigate the ui but I couldn't get playback to start again without rebooting. Here are the things I noticed: In the buffering thread it was showing about 44MHz average for decoding and was boosted very minimally. On the clocking display you will notice that the sd and msd freqs go to 405khz for disk accesses and then back to an invalid value when the access is over. Well they end up locked at 405 when my music stops playing and the frequency is locked at 192MHz for the player, all while still able to navigate the ui. I'm thinking this points to some type of sd access problem and that's an area I'm not very familiar with yet. Then again I've been know to draw an incorrect conclusion or 2 so what do you folks make of it?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version