A couple of addenda to what I wrote earlier: 1. My next short-term action item is to add a mechanism to pass AT commands over RVTMUX in addition to the dedicated modem UART channel, and implement it both in our own fw and in a leo2moko- based TCS211 debug version. (The affected components will be RVT and ACI, both of which are in full source form in our copy of TCS211, so what I seek should be perfectly doable.) In fact, there already seem to exist several different very ugly and poorly designed mechanisms for submitting AT commands to ATI over RVTMUX, but my goal is to implement one that will be a permanently registered command source with ATI, so that when unsolicited notifications need to be sent (incoming calls, SMS, registration status changes etc), they will be sent both to the standard modem UART channel and to our AT-over-RVTMUX channel. The idea is to make this new AT command channel no worse than the standard UART for the purpose of fully exercising all functionality presented by the fw via the AT command interface.
Aside from easing possible future migration of our fw to Compal and Pirelli targets (if we get to do that part at all, see my previous long post), having AT-over-RVTMUX will be helpful in debug sessions on "good" targets (gtamodem and our future dev board) as well: this way all AT commands we send, the responses we get and any unsolicitied notifications will appear in the rvinterf session log together with the debug trace output, so we'll be able to correlate the debug trace activity with what happens at the AT command level - right we have no such correlation, and debugging gets more difficult as a result. 2. In case I wasn't clear, the key advantage of my proposed GSM dev board over existing non-Openmoko devices like Pirelli or Compal will be its ability to run TCS211 in addition to our own fledging fw. Why can't we get TCS211 running on Pirelli or C1xx? Well, getting our own gcc-built fw to run on these diverged-from-TI targets is enough pain already; I really don't relish the idea of trying to do it with the blob-laden, Windows-toolchain-built TCS211 fw. Like it or not, while our own gcc-built fw is the ultimate goal, we are playing catch-up to TCS211, so any developer or anyone aspiring to be a significant contributor will need to be able to run TCS211 as well and poke at it in various ways. 3. When it comes to the UI, it should be fairly obvious that designing a UI that works with any arbitrary screen size is impractical, hence any existing UI code (such as TI's BMI) will be necessarily designed for some specific LCD size or at best a set of several specific sizes. The LCD on TI's higher-end development platforms (D-Sample and later) was 176x220 pix color, but the code is too messy for me to figure out if the BMI implementation actually uses all 176x220 or some smaller subset of the physically available screen real estate. Earlier boards before D-Sample (and for age reference, D-Sample is already older than all of the commercially produced GSM devices we are hacking on) had an 84x48 pix monochrome LCD, but it's too hard to tell if the code that supported this screen size is still there in a usable form or bitrotten beyond usability. This screen size issue is one of the reasons why I like so much the idea of using an emulated LCD (bitmap data sent to a PC over RVTMUX) instead of a real one in the earlier phases of getting ourselves familiarized with TI's reference UI implementation. I don't relish the idea of picking some specific existing target that has an LCD of a given size we can't change, doing a bunch of work to port our fw to that target, only to discover pretty late that adapting the UI design to that screen size would be a royal pita. In contrast, with an emulated LCD we can play with whatever sizes we choose and see how adaptable the UI is to any given size, and then if we do choose to bring our fw up on some pre-existing target with a fixed LCD size, we'll be prepared for what to expect in terms of the UI on that LCD. That's all from me for now, off to bed. SF _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
