-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
Hi Joerg - >> We have a choice about basing on S3C2443 or S3C6400. A lot of the info >> is confidential but not these high level things which are public domain >> on Samsung's site. > > On Samsung's site I see a registration form to get access to user-manual etc. > So if everybody may register to get this "confidential" data which is Out of scope for me, but this is something we can ask about shortly. I was pleased that they had the overview out there at least. >> S3C6400 is 90nm and has 480Mbps USB2 OTG, 667MHz max clock, some 2D >> acceleration > > plus H263/H264 coding and decoding and LCD-interface. This means we get rid > of > glamo, no? In this design scenario the CPU can handle everything. >> - Focus on SD Card rootfs rather than internal memory > > As long as we get a second media slot, preferably one that's accessable from > outside, 'hotswap', that's not adding to the footprint of the case as e.g a > USB-stick does. This is possible to consider, 6400 has 3 x SD channels, if one goes on WLAN, one for "rootfs" SD inside, we have one to burn. >> - Add a small lowpower MPU like TI MPS430 to manage everything >> seamlessly when main CPU is down. Stuff like motion sensors, wake >> sources, battery management, maybe touchscreen, leds so there is an >> always-on "guiding hand" in the phone that is consistent and reliable > > Well sure a useful gadget, but hard to interface with the main cpu in a way > that's not a bottleneck. Should G-meters be accessed by main cpu via this > MPU, or shall there be concurrent access. The first sacrifices flexibility > (If MPU can't do it, it can't be done), the second adds complexity to both hw > & sw. > I'd prefer to have a main CPU, that's up to reasonable power and back to > suspend in a few milliseconds, plus a nice timer to periodically wake the > CPU, and all needed interupt lines well done, and intelligent peripherials. > Alas i fear that's not easy to design. Well that is kind of seeking to reduce the dead time (which will be hard), the MPU method eliminates the dead time and any inconsistency in behaviours. For the motion sensors, I imagine the MPU manages them fully and we communicate with the MPU over SPI at 100sps if we really wanted or more likely a lower rate. Raw motion sensor traffic is only 600 bytes / sec (2 x XYZ bytes x 100sps) so this is fine -- currently motion sensors are quite expensive at 2 x 100Hz CPU interrupts and same rate event handling. The MPU can do "integration" of motion for 100% of the samples over time as well even while the CPU is asleep, so it can approximate (not mega accurately, but the order of magnitude anyway) how far you moved and in what direction overall for arbitrary periods without the CPU. (Similarly it can accurately profile sleep current consumption over HDQ without the CPU, something we would love). We can do things like wake the CPU because you have been still for a while after traveling, or force airplane mode even if the CPU sleeps if it detects accelerations that only happen in airplanes, etc. If the MPU can do gesture estimation, it means also that we can wake the CPU with a fully captured gesture handed to it when it wakes a second or two later... things should just have less discontiguities depending on the CPU state. The CPU is then more like an expensive asset that we leave asleep until we already determined something important happened than the hassled thing that has to wake before any little thing can be achieved. >> To be clear though -- GTA02 is soon going to actually exist, and this is >> just future talk right now. But because of that, if you have any ideas >> about future arch, now is the time to throw them in and they will at >> least get the time of day. > > Open up existing bonus functions like camera IF, video out..., don't spoil > them by using 3 of the 15 GPIOs for other tasks, but instead route them to > free pins of some (debug?) connector, or testpoints at least. Yes that one is sold already :-) Idea there currently is to provide SIL pads on the PCB with rich IO, maybe behind the LCM, thanks for reminding! - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH4Q4iOjLpvpq7dMoRAhYGAJ9euPTdqIDBedW3maeq7iE6dPp8yACaAmRv UDMX9TqNY3skZh8NlXXSt4A= =u6GF -----END PGP SIGNATURE-----
