James,
I was thinking when I was going to sleep last night that Q can use VxWorks for its MSM3000. Here is my reasoning. I have been using the Qualcomm Thin Phone for about 3 months. I have to say that the phone sucks in many way. (Sorry to the Qualcomm faithful.) For example, some times the phone responses to key press with a 1/2 second delay. I assume that Qualcomm is doing polling instead of using an interrupt. Wouldn't an OS that can scan the key pad every 50 mili-seconds be better? I think it would.
Q's problem with the Thin Phone software goes much further than just slow key response. A major bug is that the code may have gone to a new state, but the LCD update is 1 second behind. Like the key pad problem, this happens only once a while. If implemented correctly, VxWorks can help Q greatly at solving these timing problems. (My personal belief is that even without an OS, such problems should NEVER happen.)
If Q wants to be a successful ASIC supplier, its firmware needs to become 1) robust, and 2) customizable. Getting VxWorks on there will not solve the problem, but would be a step to the right direction.
There are also other reasons, such as implementing BlueTooth, that may force Q to redo the MSM3000 firmware architecture. If Q doesn't clean up its firmware, it might find itself loosing Japanese customers such as Kyocera in the not so distant future, despite its lead in ASICs.
Going off topic, it might be a good business idea to rewrite the MSM3000 firmware, and resell it to OEMs. If the business does take off, Q will buy it.
Khan |
