|
|
|
|
|
|
by _Adam
4602 days ago
|
|
|
No, not really. The actual answer is more complex. Camera: The high data rate required for imaging module means that it doesn't run on a shared bus. There's a number of standards, some proprietary and others loosely defined, but they all use direct connections to the image processor (which is in many cases part of the SoC). Microphone: Probably not going to access this one, because microphone wouldn't be on any sort of bus. They'll have a direct connection to a ADC, which would have a direct connection to an audio signal processor in the SoC. Other sensors: This depends on the implementation. If they use I2C, there's a good chance they'll be on a shared bus on which the baseband processor is also located. However, accessing that data requires details about the specific sensor. If a particular model of phone is being targeted, this isn't too hard. For example, I know the iPhone 4 uses the LIS331DLH Accelerometer. I can find the datasheet for that part, and then write a simple driver to access it's data.
If they use SPI, which isn't a bus-based protocol, there's little chance of accessing the information directly. SPI devices can be daisy chained or separately selected to put more than one on a single port, but in such a configuration there's only ever one master (which would be the CPU). |
|
|
Essentially, most of the pins on the SoC are re-programmable to have different functions or connect to different logical blocks within the SoC.
Along these lines there's also bit-banging SPI or I2C, which should work fine for infrequent updates from an accel or compass (and now things like pedometers being added to devices.)
As for microphone, if it's being read by the audio DSP, it's certainly accessible from the baseband, at least on Qualcomm . If nothing else you can load a DSP module that allows access to the raw PCM (or vocoder) data.
Same is probably true for the camera, which is usually on an HSIF or similar bus connected to the DSP.