Hi, On Sun, Nov 23, 2008 at 6:42 PM, Michael 'Mickey' Lauer <[EMAIL PROTECTED]> wrote: > Hi, > >> > Let me add on that -- it is always desirable to have more than just one >> > channel for usual AT commands, that way you can drastically simplify the >> > gsm server logic. I would prefer three independent homogenous command >> > channels, if we can have them, one for call control, one for unsolicited >> > responses, and one for everything else. >> >> Why does it simplify gsm server logic?
Is the gsm server logic fso here? > Example: > If you have one channel where you always retrieve unsolicited responses, you > can > a) disable unsolicited responses on the other channels and use them solely in > request/response mode, and > b) retrieve unsolicited responses while the other channels are busy (e.g. > during dialing the ATD command hangs and blocks any other commands or > unsolicited messages coming in) My knowledge of the AT communications is poor, so I guess I can't judge whether or not it will be worth creating all this extra abstraction for the msm7*. Still I would like to understand it. What is the benefit in the a) case? In the b) case, how would ATD hang? In case it would, how would the unsolicited-only channel win over the normal serial device method? If you mean by hanging, the modem chokes, I don't see how some higher lever abstraction could save it... >> What do you mean by independent and homogenous? > > Independent: They keep their own state, e.g. if you enable +CREG on channel A, > it would not get sent on channel B. > > Homogenous: Channels are equal, e.g. you the same set of commands work equally > on channel A and B. > >> If you want to change the way you access the modem in the msm7*, you >> must modify the AMSS. It is the software which provides us with the >> shared memory fifos where the serial nodes run on. The kernel driver >> is only a thing that manages the data flow on them and provides the >> devices. So that would be very hard. If I got this wrong and you want >> to make userspace software that "sorts" different commands it's >> something else. But I don't understand the reason. Does it work like >> that on the mokos? > > On the TI Calypso, we have soft-multiplexing (done in userland) giving us 4 > independent, homogenous channels. This is a quite nice base for any gsm > server. If this will require any modification of the arm9 (modem) code like modifying the AT communication behaviour, we can't do the multiplex stuff. In msm7* we have nothing like ti tools luxury you have for the calypso. Where can the sources to this soft-multiplexing mechanism used for the calypso modem be found? Could you be more specific and name things so in future I can have a look at the sources right away? > On the Freescale Neptune, we have hard-multiplexing (done in hardware+kernel) > giving us 8 channels, however they're not independent nor homogenous. Still > they have something like a dedicated channel for several types of commands > (i.e. unsolicited), so that's nice as well. > > Don't get me wrong, we can use a singleline modem fine as well, but you will > have to live with certain limitations. What are these limitations? You mean if we use the single present msm AT channel (/dev/smd0) only, we can't recycle as much of the calypso modem code in fso for use with msm7* as we could with the soft-multiplexing? Or are these limitations on a higher level of abstraction than fso? Assuming I'm brave and I would want to run fso on my kaiser's /dev/smd0, which (single line) modem type would I want to pick? Calypso? Could you comment on the AT debug logs I sent? Kind regards, Lukas _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
