FC project direction

Spacefalcon the Outlaw falcon at ivan.Harhan.ORG
Tue May 26 09:49:10 CEST 2015


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


More information about the Community mailing list