Difference between revisions of "Talk:10349"

Revision as of 13:08, 30 January 2008

About the plex panel for developer case: why do it transparent ? Is where a special reason ? It's not very good for image quality to have light inside the case. --Polto 11:36, 14 October 2007 (GMT)

Transparent? Why? Is it written anywhere?--Andrey.filippov 16:29, 14 October 2007 (CDT)

Yep, in 10349#Body_of_camera_for_developers --Polto 08:55, 15 October 2007 (GMT)

I looked at the images only, did not read the text. You are right there is no sense to have transparent cover - it will allow stray light to reach the sensor.--Andrey.filippov 03:10, 15 October 2007 (CDT)

No problem, we can use black plex. --dimon 21:11, 16 October 2007 (CDT)

Will the RS323 socket fit in the camera on top of both 10353 & 10349 ? --Polto 03:45, 1 November 2007 (GMT)

Should be yes. I measure distance between PCB of 10349 with 10353 to top of cover on 3D model. This is 11.5 mm. For common socket of RS232 this distance is good.

That is my comment. --dimon 22:17, 31 October 2007 (CDT)

Are these boards available for purchase or testing? --Ekratzer 15:51, 12 November 2007 (CST)

Yes, we just do not have our costs (and so the price) ready yet.

Andrey

I am trying to use CF + DMA on 10353 boards. I have tried many CF cards and they work fine under normal PIO modes, but not with DMA, even when tweaking parameters with hdparm. I have also found that some hard drives work with DMA, and some do not, leading me to believe that maybe there is some CF type that will work. Has anybody successfully use CF + DMA on the 353's ETRAX FS?

--Ekratzer 11:41, 28 January 2008 (CST)

That is very interesting. Can you please provide links to the exact circuit diagrams how you connect CF cards as well as to the source code you are using?--Andrey.filippov 13:08, 28 January 2008 (CST)

Andrey, I have uploaded our circuit diagram to rz_353_cf_interface.pdf As far as source code, we simply have a script that runs as last part of runlevel 3. It disables DMA (/sbin/hdparm -m 0 -c 1 -d 0 /dev/hda) and mounts /dev/hda1 on the filesystem. If we do not disable DMA, then the kernel just endlessly loops on dma timeouts when we try to access the CF. --Ekratzer 17:06, 29 January 2008 (CST)

I see, thank you. By the end of the week I should have all the components for the 10369 board and I will put it together ans start testing with the CF cards (and SATA also). Did you try different brands/models? --Andrey.filippov 17:41, 29 January 2008 (CST)

I have tested with a variety of Transcend and Kingston CF, ranging from 512MB to 8GB, and speed ratings from 45x to 266x. I have also tested 2 hard drives, both Hitachi Travelstar. Model #HTS541040G9AT00 works well with DMA (over 15MB/s sustained write throughput with little CPU load), and model #HTC424020F7AT00 behaves the same as the CF (no DMA.) I have tested all these CF and hard drives on 5 of our CF interface boards, with results being the same for each. Interesting note, the kernel always detects and tries to enable DMA in cris_ide_init(), regardless of "ide=nodma" init option. It times out once after about 8 seconds, and then I can disable DMA and mount normally with PIO modes. --Ekratzer 14:12, 30 January 2008 (CST)

Also, I forgot to mention that I have also tried a couple IBM 4GB CF microdrives, with results being the same (no DMA.) --Ekratzer 14:18, 30 January 2008 (CST)

I see. Hope to have some results with the 10369 next week and see if I'll get the same problem. So far I tried several HDDs (no CF yet) and they worked fine (to be honest I even do not know if the DMA is enabled) - the recording speed for large files was around 15MB/s. With the 10369 I'll get there with the oscilloscope and add some "pritnk()" to the driver - I believe it should work faster.--Andrey.filippov 15:08, 30 January 2008 (CST)