SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[funman]

It appears we have leftover room in iram, is there a reason not to use it for the stack?

Not really, but is it really helpful (how much speedup) ?

Do we really need the mmu functioning in the bootloader?  It seems to me it overcomplicates things.

Not at all! It's simpler to enable it in the rockbox.sansa loaded from disk

And , of course now that Funman has mp3 and ogg playing so nicely for me(thanks a ton by the way) how do I stay motivated 

Getting FS#10118 and looking for full speed video playback


Some bad news: I broke my Fuze LCD while it was in my pocket (how breakable it is!) and when trying to exchange the LCD screen with the other Fuze I had, I unsoldered the LCD connector :/

saratoga's Fuze was hardware rev 1.2 and mine was 1.41, the 1.41 connector looks much more breakable...

Now I still have the rock solid Clip to develop, but had not much luck with MMU.

I'm looking at understanding the I2C registers to use interrupts and remove the busy loop in ascodec driver; and also to enable headphones detection.

Keep up rocking !

[kugel.]

Not really, but is it really helpful (how much speedup) ?

Tests will show. Putting the lcd framebuffer didn't gave more than 7% (though the Fuze's LCD is utterly slow compared to other targets anway, caching needed?

Some bad news: I broke my Fuze LCD while it was in my pocket (how breakable it is!) and when trying to exchange the LCD screen with the other Fuze I had, I unsoldered the LCD connector :/

saratoga's Fuze was hardware rev 1.2 and mine was 1.41, the 1.41 connector looks much more breakable...

You're kidding, aren't you? Another two broken Fuze's within a few days?

I've had the 1.41 too. The LCD broke too, but the connector is pretty solid still.

Now I still have the rock solid Clip to develop, but had not much luck with MMU.

My clip isn't so rock solid

I'm looking at understanding the I2C registers to use interrupts and remove the busy loop in ascodec driver; and also to enable headphones detection.

Keep up rocking !

Do our Sansas have the capabilities for that? Do you have informations about this?

Keep rockbox too!

[funman]

No I'm not joking, I read that you broke your Fuze too

I gave up studying i2c registers, I think the benefit isn't very high (i2c busy loop delay could be mesured anyway).

About headphones detection I gave up as well since we can detect insertion but not removal it seems, and i2c interrupts are not needed for this. (You can enable the interrupt by IRQ_ENRD_* ascodec registers and check the status manually).

Just look for "headphone detec" in the AS3525 spec and "DET_ON" in as3514.h

@saratoga : except lcd & i2c I didn't see any busy loops without yield() in the middle, so I think the slowness is related to caching being disabled (mmu disabled).

Other stuff : today I looked again at the Clipv2 and now I pass the SD init procedure! Now I'm looking at which registers to modify to get a DMA transfer.

The code is still very hackish, I'm eagerly waiting for a AS3531 spec to see which SD controller is used.
I'll write again to the AMS people I contacted to see if they didn't forget me.


Oh and I noticed that the viewer plugin crashes a lot on my Clip, did someone notice that as well on Clip & other targets?

[Mikerman]

In case further Clips are needed for experimentation, etc.:  1gb refurb'ed Clips at $14.99 with free s/h, at Buy.com.

http://www.buy.com/prod/sandisk-sansa-clip-mp3-player-1gb-recertified/q/loc/111/210490112.html?adid=17654&dcaid=17654

[arez1]

hi,
iam not quite sure what i need to report and whats not relevant but i will give it a try

- Flashing Wheel : instead of turning of, the wheel starts flashing... you might reproduce it by setting your start screen to "last played" and turn your player of/on - then just wait a bit

- Data abort : at 3004FFF0 .. just happened once while i was playing a mp3, watching the playlist and going one step back ( <- )

running an e200 v2 - 8gb

[Hillshum]

- Flashing Wheel : instead of turning of, the wheel starts flashing... you might reproduce it by setting your start screen to "last played" and turn your player of/on - then just wait a bit

If you pay attention, you'll notice it's flashing on disk access

[arez1]

i used rockbox on my e200 v1 and it never flashed so i thought its kind of unwanted... imo its quite annoying so is this a wanted feature of rockbox or just something to make observations easier for development?

[kugel.]

i used rockbox on my e200 v1 and it never flashed so i thought its kind of unwanted... imo its quite annoying so is this a wanted feature of rockbox or just something to make observations easier for development?

No, it's not wanted. But it's not a big deal yet as there are bigger problems. If you can fix it, please do so and post the patch.

[cyclon1978]

hi, i have a question about the lcd driver.

i am trying to modify the code from funman's patch #10118 for the e200v2 and succeded viewing videos in good quality but... they are rendered from upper left corner and so they will not fit.

for e200 i need to rotate it 90 degrees and i tried that with R_ENTRY_MODE_VERT but i fear that dont work in the way i thought (i hoped it would reconfigure the display to interpret the lcd memory "rotated") maybe can someone explain if there is a way to do the rotate without recalculate the image?

i found some comments in mpegplayer about rotating images - should the image be rotated in lcd_blit_yuv or previously?

thanks,

andreas

[funman]

The HORIZ/VERT mode changes the way pixels are stored: i.e from top to bottom or from left to right.

For video to work properly, you must also change the coordinates from where you start drawing.

The assembly helper called by lcd_blit_yuv() draws 2 "lines" at a time in this way:

Code: [Select]

===========> line 1 from left to right (on fuze)
0 3 5 7 9
1 4 6 8 ...
===========> line 2

The number represents the xth pixel written

[cyclon1978]

i drawed only the first line and tried all HORZ/VERT modes:

#define R_ENTRY_MODE_HORZ_NORMAL 0x7030
#define R_ENTRY_MODE_HORZ_FLIPPED 0x7000
#define R_ENTRY_MODE_VERT 0x7038
#define R_ENTRY_MODE_SOLID_VERT  0x1038

but every time i got the same result: two lines from upper left to upper right. i expected i would get two lines from upper left to lower left with VERT modes... so i assume both VERT modes are not working 

[FlynDice]

This snippet from plugin.lds seems to me to pass by as3525 with MEMORYSIZE > 2 or am I missing something?

http://pastie.org/450159

EDIT:  Ah, I guess it gets taken care of for us as a catch all but it makes the code a bit obscure.  Doesn't this set  #define DRAMSIZE for all the targets that follow though?  That could irritate a few people.

[funman]

i drawed only the first line and tried all HORZ/VERT modes:

but every time i got the same result: two lines from upper left to upper right.

That's normal, the pixels are written into the window previously specified with lcd_window_x() & lcd_window_y(), using the orientation you chose with HORZ/VERT mode.
For e200v2 you also have to change these windows (I think 2 pixels wide and 220 pixels high)

@ Flyndice : indeed this is a bit obscure and should be changed to
#elif CONFIG_CPU == AS3525
#if MEMORYSIZE >= 2
..
#else
..
#endif
#else
#   error
#endif

[FlynDice]

I posted FS#10141 to change plugin.lds.  Someone take a look and see what you think.

[sko]

Here is a patch by kugel and me which enables scrollwheel acceleration on e200v2: FS#10151. Maybe someone with an e200v2 can have a look at it.