Well i have just been doing some research into the chipsets we can use. as you may knom i mant to use as few manufacturers as posible. the reasoning behind this is two fold, it makes things simpler and if we can get one part in small quantities then it is likly we can get several differnt chips from them in small quantities
now that thats out of the way, i have some corrections for some of the hardware, it has been stated that there is an upper limit on the flash and how much we can have in the system, this is untrue. it turns out we can have more but the interface the requires "glue" or in other words extra circutry. what this means is there is a posibility to use the 32Gbit flash chips that samsung has on thier website
one thing i have looked into is the current situation with the DDR RAM, i have made some intresting discoveries with regards to this and have decided to go back to using mobile DDR RAM only instead of offering the normal ram as well. this puts a cap on the upper limit the design will have, effectivly limiting it to 256MB (4 chips) the reasoning behind this is that the 1Gbit chips were twice the size of 2x 512Mbit chips and consumed more power, the funny thing is that depending on how it was wired up 2x 512Mbit would consume more power, however we would need 8x chips to hit 512MB. this may sound wierd to go to the solution that has the potential to chew more power but with a couple of tricks it can be made to use as much power as the 1Gbit chip
we do this by using 32 bit chips rather than 16 bits, with the 16 bit chips we would have them in parrallel to make a 32 bit bus to keep the performance up. instead we will have the chips one after each other so that unused chips can be put in a low power state. now this iswhere the low power chips are really good, unlike thier PC targeted cousins they can be put into an ultra low power state where they dont refresh thier memorey contents, the power consumption in this state would barley light an LED. unfortunattyl i dont think we will be able to take advantage of tis feature due to linux's cacheing system and how linux allocates memorey (basically we would need to defragment the memorey to try and use as few chips as posible)
the other advantage the mobile chips have is that thier normal power requiremnts for most tasks are lower than normal chips, when not acsessing the contents of one of the chips it can be put into a low power state saving power blah blah ... you get the point.
Now at this point you are all probelly thinkin, "well he is talking about ram and power why didnt he put it in that post about saving power by turning off LED's" well here is where i start talking about the design decisions behind which chips i have selected.
first up is the HDMI chipset. now this is a bit contravesal as it includes encryption but what you porbelly dont know is that its backwards compatible with DVI, however it is most likly compatible with VGA (even with an adaptor) so a second connecter will have to be put somewhere. thu adavantag the HDMI gives us is that it transmits both videa and audio, meaning we will be able to put that 7.1 chipset that has been mentioned to geed use, it also supports SPDIF which has been asked for.
this chip is great for us because it takes a VGA signal and gives out a HDMI compatible signal, it handles the encryption and everything else, as far as i can tell all we need is a key and perhaps not even that (besides you could always "clone" the key from your HDMI DVD player) the funny thing is because we have the chipset bieng fed by a vga signal we can route that to a connector and have good old VGA support. nice and simple no software required.
next we come to bluetooth, part of my "minimum spec". as i have said i wont to use a enhanged data rate chip, the reasoning behind this is that it is lower power. the anoying thing about this is that it needs an RF shield which means more things to manufactuer. the solution, buy a prebuilt module from infeon that has the RF shield built into it. nice and samll and is basically an "attach an antenna" design that also offloads part of the processing (up to HCI it says)
now for another explanation of some of my design decsions. i am trying to use single chip solutions to reduce the cost, both in terms of cash and board space (mostly board space). lukily for us neally ever second generation chipset for every RF protocal you can think of has a single chip solution.
back to where the story left off. i know i am running out of serial ports (async and sync (SPI and ttl rs232)) however does anyone fancy a gps reciver, i have found a single chip solution that looks very nice and also reminded me that phones are supposed to come with GPS so that you can be tracked by "emergency services" [begin silent wisper] or the CIA/NSA [/end silent wispering]. now i would like to be as complient as posible so i might have to include a chipset like this, however we are running linux so i recomend you setit up to tell them you are on the moon . more seroslly thogh it would not be hard to make it report a location under user control if you are that scared about it, and it would nicly round off this design
ok the next one we have is very very nice, infeon also make phone chipsets based on arm up to 250Mhz. not bad at all, the advantage is that this thing has serial ports on it and can help us extend the IO of the iMX3. it can also be used to offload part of the processing of whatever we desire as well as allowing the phone to work without the iMX3. it supports multiple antennas and HSDPA so we can get stupidly high download speeds. We could build a PDA around it if we needed
the problem is that nearly everything is a single chip solution so it will be hard to find a chipset without the ability to hook up a screen and keypad. it does mean that if we needed to we could have 4 SD card slots . i am thinknig that this should be connected to 4 buttons and the mcrophone/speaker as well as a gpio line from the iMX3, when the iMX3 drives the line high the chip knows that the iMX3 should make all the descions otherwise pickup the call when the button is pushed, i would also connect the secondary screen to this processor as it would mean that we could display the incoming number when the iMX3 is unavlabile to do an adress lookup.
this is by no means complete, it still requires alot of thenking on how to design the solution, the actuall problem hasent even been outlined yet (i wiill leave it until we have all the hardware decided)
i am also thinking of micron for the actuall image sensor, how many mega pixels do we want?
flash is flash, i am thinking of using samsung beacuase of the insane denisities they have
anyway hera are the links to the hardware i have been talking about:
http://www.infineon.com/cgi-bin/ifx/portal...ageTypeId=17099http://www.infineon.com/cgi-bin/ifx/portal...ageTypeId=17099http://www.infineon.com/cgi-bin/ifx/portal...ageTypeId=17099http://www.samsung.com/products/semiconduc.../K4X51323PC.htmhttp://www.samsung.com/Products/Semiconduc...Flash/index.htmhttp://www.micron.com/products/cmos/