Holger W?chtler wrote: > > Am 18.06.2005 um 18:11 schrieb Manu Abraham: > >> Manu Abraham wrote: >> >>> Hi , >>> I was looking at a concept where a driver can distinguish between a >>> scan and a zap.. Suggestions would be greatly appreciated .. >>> >> >> I will make my question a bit more specific .. >> >> While doing a scan, do we require to know the signal strength.. The >> driver in question is the dst .. If we do not need to know the signal >> strength the dst will tune a bit more faster, since instead of 2 >> messages that are sentto the MCU/ASIC, only one need to be sent. >> >> >> Hence tuning will be faster, as i2c communication also takes a while >> to happen, and to retrieve the signal strength on a frequency that >> does not exist, it takes really a while to return back and can be a >> cause for irritation .. >> >> So i was thinking about removing the get_signal() call itself during a >> scan .. > > at 400kHz i2c clock the time required to transmit a 2-byte-message > should be negligible, not? > * The first point is we are running at I2CRATE=0 (99.2khz) rather than I2CRATE=1 (396.8kHz).. We cannot make it go at I2CRATE=1 since the internal i2c bus is f/w based rather than h/w based.. for example we can write software on a Microcontroller to have i2c functions which are s/w based for the Microntroller, but as a end-user sees it it is H/W , the way we see it through the Fusion 878.. compared to the hardware based SCL/SDA pins directly present on a Microcontroller.. * Even 99.2kHz is quite fast for 20 bytes to be transferred ( Each command is 10 bytes, each in one direction, that makes 40 bytes totally, the communicated commands in the case of 2 commands issued to the MCU) * Even at 99.2khz, the MCU/ASIC has to query 2 times from the frontend for this to be done.. In practice the query time is much greater than the communication time taken.. * The MCU uses one H/W based i2c communication with the frontend and F/W driven i2c at MCU level which interfaces to the Fusion 878.. When we use such a device in conjunction with a CI module, the MCU spends most of it's time when communicating to the CI module, So the probability of i2c error happening here is much higher.. If this happens continuously, we see kind of errors that we do not understand at all .. Many a times this can be considered as a MCU crash.. * When an i2c error happens, the command is retried after a resetting a state machine in the MCU/ASIC firmware, and after a significant delay.. So to sum it up the delay taken and all do account for the time taken for the command to be successful.. When this scenario is doubled (ie 2 messages) the delay is also doubled.. This can be seen as a quite long waiting period.. People who have i2c communication errors, would have possibly noticed that their tuning also is significantly delayed. This is the very same cause .. I hope the scenario is sufficiently clear .. Manu
