r5665 - trunk/gta02-core/docs/ecn

rask at docs.openmoko.org rask at docs.openmoko.org
Thu Oct 1 13:46:59 CEST 2009

Author: rask
Date: 2009-10-01 13:46:58 +0200 (Thu, 01 Oct 2009)
New Revision: 5665

- added ECN0041 (for discussion) "Test points and 0R resistors for camera interface"

Modified: trunk/gta02-core/docs/ecn/STATUS
--- trunk/gta02-core/docs/ecn/STATUS	2009-09-24 14:02:51 UTC (rev 5664)
+++ trunk/gta02-core/docs/ecn/STATUS	2009-10-01 11:46:58 UTC (rev 5665)
@@ -40,6 +40,7 @@
 0038    Discuss Loudspeaker EMI filter
 0039	Discuss	Insert 0R resistors into SPI signals
 0040	Discuss	Remove backup battery (BAT1701)
+0041	Discuss	Test points and 0R resistors for camera interface
 Open ECNs
@@ -66,3 +67,4 @@
 0038    AUDIO
 0039	CPU, LCM
 0040	PMU, MODEM
+0041	CPU

Added: trunk/gta02-core/docs/ecn/ecn0041.txt
--- trunk/gta02-core/docs/ecn/ecn0041.txt	                        (rev 0)
+++ trunk/gta02-core/docs/ecn/ecn0041.txt	2009-10-01 11:46:58 UTC (rev 5665)
@@ -0,0 +1,41 @@
+Test points and 0R resistors for camera interface
+We should allow for experimentation with the camera interface. The
+24xx/64xx camera interface would be the obvious choice of interface to
+connect a camera to, but a few details need verification:
+The SC32442B manual specifies a short VSYNC pulse (high) between lines. 
+Several camera modules instead keep VSYNC high during lines. It is not clear
+from the manual if simply inverting VSYNC polarity is enough to make it
+The SC32442B manual isn't quite clear on how to receive e.g. JPEG compressed
+data as offered by some cameras. E.g. will we need a separate VSYNC
+interrupt pin to deal with variable frame data lengths?
+The change is to route unused pins to test points and insert 0R into the
+rest. Current status:
+CAMDATA0/GPJ0	Insert 0R (BT_PIO5).
+CAMDATA1/GPJ1	Add test point.
+CAMDATA6/GPJ6	Add test point.
+CAMPCLK/GPJ8	Add test point.
+CAMVSYNC/GPJ9	Add test point.
+CAMCLKOUT/GPJ11	Has 0R and test point (CHIP_PWD).
+CAMRESET is not really a special function, any GPIO could be used for the
+camera reset signal.
+Would it be better to route the camera signals to the debug connector to save
+PCB space and reduce the need to solder wires to the main PCB?
+Impact: Little if any. The signals currently routed to the camera port are
+less than 1 Hz or not used at all.
+Author: Rask Ingemann Lambertsen <ccc94453 at vip.cybercity.dk>

More information about the commitlog mailing list