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~ _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
