digital audio to FCDEV3B

[Mychaela Falconia]

Hi Serg,

> It is a good point that DSP code may not support this functionality and
> some preliminary tests will be needed.

"May not support this functionality"?  Given that TI's ARM-side
firmware does include support for their "Bluetooth" mode and reasoning
that it would have been pointless for TI to write ARM-side code to
control a non-existent DSP feature, I reason that the DSP code support
for this "Bluetooth" mode most likely *is* present, whether in the ROM
code or in the downloaded patch that came with TCS211.  But what we
don't know is *how* it works, i.e., how does it configure the MCSI
hardware and whether or not it offers any flexibility in the choice of
this configuration without writing your own DSP patch code.

> I started looking into this and based on C155 service manual schematics
> MCSI is actually exposed on J2 and apparently used for some sort of tests
> (I seen this mentioned in docs), hence I can try to experiment with that
> using another SPI host.

Yes, I know about MCSI accessibility on Mot C1xx phones: they have a
group of 5 plated through holes in their PCBs to which they bring out
the 4 MCSI signals and GND.  The test mentioned in various docs is DAI,
apparently described in GSM spec 11.10, although I haven't read that
one myself yet.  It appears that DAI tests were the first practical
purpose to which the MCSI was put, before Bluetooth, but in any case,
getting to the MCSI+GND connection points on Mot C1xx phones would
require tearing a phone to shreds and soldering in pins or wires,
hence it is an exercise which I leave to other enthusiasts - for
myself, I would rather wait for the FCDEV3B.  Situations like this one
are the very reason why I went on this big journey to design and
produce the FCDEV3B: I am sick and tired of hacking on the existing
crippled phones.

> For my application I would prefer to drive MCSI from the external host and
> use it in multi-chanel mode, which seems to be available based on DSP
> config parameters.

If you mean having the MCSI pins of several FreeCalypso modems all
connected together as a single bus, with MCSI_CLK, MCSI_FSYNCH and
MCSI_RXD to all modems driven with a single source while different
modems drive one single MCSI_TXD line in different timeslots as a
tristate bus, you may have a quite difficult time achieving such a
goal.  For one, I don't know if the Calypso's MCSI_TXD output driver
has tristate capability or not, and two, having different modems use
different channel timeslots on MCSI when they all receive the same
MCSI_FSYNCH input would be such a non-standard configuration that you
would almost certainly have to create your own custom DSP code patch
for it, and the latter would be an extremely daunting task in the
absence of source or symbols for the DSP ROM code.

If the "Bluetooth headset" mode of operation does put the MCSI into
slave mode where MCSI_CLK and MCSI_FSYNCH are inputs, you should be
able to get at least close to your ideal arrangement by feeding the
same MCSI_CLK and MCSI_RXD to all modems, but generating a different
MCSI_FSYNCH signal for each to make them see different parts of the
frame as "theirs", and combining the non-tristate MCSI_TXD outputs
externally.  But how do you plan to handle the clocking?  If you are
going to be generating your own MCSI_CLK and MCSI_FSYNCH, how will you
synchronize to the actual pace of each modem's GSM voice channel?  Or
do you plan on operating plesiochronously and tolerating occasional
frame slips?

For myself, I would prefer to find a way to put the MCSI into master
mode where the Calypso drives MCSI_CLK and MCSI_FSYNCH as outputs: for
ordinary users who are interested in a single modem with a single SIM
operating as a 100% standard GSM MS, it would be a lot nicer for the
digital voice interface to be truly synchronous, rather than
plesiochronous - but we shall see...

M~