Rockbox Development > New Ports
Cowon D2
aidy:
hi,
does having usb working have any practical features yet?
shotofadds:
There won't be much benefit for users at this point (it's basically the same as the Cowon firmware's MSC mode, but read-only). But it will be a really helpful debugging aid to help me fix the remaining issues with the NAND driver...
isanggon:
I found "2 lines from top on bottom" problem on lcd.
My device is dmb/dab model and I fixed this problem by editing line 80 of lcd-cowond2.c, as you said.
FREQ>>23 and 22 works fine but 24 caused bottom line problem.
I think FREQ>>23 is better choice for dmb/dab model.
shotofadds:
I don't think there should be any difference between DMB/non-DMB models, since they use the same LCD. The problem is getting the correct timing when sending initialization commands to the LCD controller. If the delay is too long or too short, some of the commands do not seem to be registered, which causes this problem.
Since the CPU can either operate at 48MHz (normal) or 192MHz (boosted), the number of loops in the delay counter has to be adjusted for the CPU speed. FREQ>>23 (etc) is an attempt to scale the delay to the current CPU speed, but it's obviously still not quite correct.
Maybe something like (FREQ>>24)+2 would work? You could also try adding an extra DELAY; at the very end of the for() loop in ltv250qv_write(). Feel free to adjust any of these values and report back...
I really would much prefer to find a solution that works for everyone... :)
FranzD2:
--- Quote from: shotofadds on December 01, 2008, 09:45:08 AM ---I don't think there should be any difference between DMB/non-DMB models, since they use the same LCD. The problem is getting the correct timing when sending initialization commands to the LCD controller. If the delay is too long or too short, some of the commands do not seem to be registered, which causes this problem.
Since the CPU can either operate at 48MHz (normal) or 192MHz (boosted), the number of loops in the delay counter has to be adjusted for the CPU speed. FREQ>>23 (etc) is an attempt to scale the delay to the current CPU speed, but it's obviously still not quite correct.
Maybe something like (FREQ>>24)+2 would work? You could also try adding an extra DELAY; at the very end of the for() loop in ltv250qv_write(). Feel free to adjust any of these values and report back...
I really would much prefer to find a solution that works for everyone... :)
--- End quote ---
The last value you suggested to me worked fine but since i modified the touchscreen driver this value doesn't work anymore, i now often see the two lines.
I don't know if this is due to some other mod but it seems to me that a mod in other files causes the problem in the lcd driver to reappear. How is it possible?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version