Rockbox Development > New Ports

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

<< < (143/386) > >>

kugel.:
Re-read please. He was talking about the AS3536 datasheet. AMS published the AS3525 one.

funman:

--- Quote from: pbxy on March 15, 2009, 09:44:26 AM ---It uses almost exactly the same order of commands (0xd5, 0x10, 0xdb, 0x34, ...) as the clip v1 display driver in rockbox (lcd_init_device() in firmware/target/arm/as3525/sansa-clip/lcd-ssd1303.c).
Only the lcd_write_command(LCD_SET_COM_OUTPUT_SCAN_DIRECTION_INV); (command 0xC8)  is made 4 times instead of 1 in the OF.

--- End quote ---

I think Clipv1 OF also used 4 times this command, but we reduced it to one.

When you have some functional code, you can try remove some bits one by one to exclude useless ones.

Good luck for LCD !

--
Some news about SD:

I received a Fuzev1 from saratoga and a USB cable from gevaerts, but sadly I broke the USB connection the first day by using a custom USB charger !
Luckily I can still charge the battery over USB (only the data connection is broken) and update the code via a microSD card.

The bank switching code is located in the "sd_reload__" module, and is very similar to the code for e200v1/c200v1 :
- send command 6 (switch)
- send command 35 (proprietary command)
- send the bank number on the SD controller FIFO (1 byte set to the bank number, followed by 511 '\0'

Something is still missing because I get DATA TIMEOUT from the SD controller when trying to read from the 2nd bank.

After that we will still have to find how to calculate the total capacity (and number of banks) : maybe by trying switching banks one by one until we can't?

calv:

--- Quote from: funman on March 18, 2009, 09:08:13 AM ---When you have some functional code, you can try remove some bits one by one to exclude useless ones.

[...]

Something is still missing because I get DATA TIMEOUT from the SD controller when trying to read from the 2nd bank.

--- End quote ---

I don't mean to be sarcastic or rude, but couldn't this be because of the previously mentioned technique to remove I/O that you believe is useless? I mean if some I/O is repeated then its mostly for timing reasons. This means it could work in some situtations without repetitions, but sometimes it won't. Just a thought, though...

funman:
This is why I always test code removal bit per bit ^^

I have made significant progress now:

I can read my watermark past the 0x1E9E00th sector.

I needed some initialisation, which enables the access to 0x1E9E00*4 (just like e200v1) sectors on the first bank.

I suppose bank switching works but I can't test rigorously since without USB access I can not modify/dump the whole disk structure of my Fuze. I even ignore if it's a 4 or 8GB.

The OF code seems to handle only 1 or 2 banks (4 or 8GB) : do you know if a 16GB model exists ?

Next step is to find the number of banks dynamically to know the exact size of each model, and also test if it needs bank switching or not (2GB and less models don't).

I attach my current patch, I'd appreciate if you can test it and play with it on e200/Fuze/Clip

--

pbxy : I have compared Clipv2 and Clipv1 OFs and have some results for you:

Keypad matrix scan is identical to Clipv1 except you have to write on GPIO D4 D5 D6 and read on D0 D1 D2
The FM chip I2C uses B6 as SCL and B7 as SDA

I forgot to check the SDRAM setting before leaving for the internet access point but I believe it's 8MB like Fuze & e200v2.

If you need something else just ask !

Hillshum:

--- Quote from: funman on March 18, 2009, 09:08:13 AM ---
I received a Fuzev1 from saratoga and a USB cable from gevaerts, but sadly I broke the USB connection the first day by using a custom USB charger !
Luckily I can still charge the battery over USB (only the data connection is broken) and update the code via a microSD card.



--- End quote ---
is the cable fine?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version