We get away / GTA04 GSM module mux driver

Andy Green andy at openmoko.com
Fri May 2 10:59:51 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(changed it to hardware list)

Somebody in the thread at some point said:
| Am Fr  2. Mai 2008 schrieb Andy Green:
|> Somebody in the thread at some point said:
|>
|> | Siemens stating their module can support full speed datarate via UART.
|> | So we got to check whether we need further info (beyond the xxMB of
|> ds) to
|> | implement a linux-demux-driver (kernel or userland) 1), and whether
|> 6400 can
|> | handle the high datarate on it's UART 2). Best solution - no USB at
|> all :-)
|> | If something doesn't match there, I'll report...
|> |
|> | 1) joerg looks at zillions of datasheet pages for MC75i, talks to
|> | sw-engineering
|> | 2) joerg is going to ask Werner/Andy, maybe looks at ds of 6400 to
check
|>
|> 6400 can do funky baud rates, but not from normal division action.
|> Instead you have to either provide external clock on a pin, or divide
|> EPLL or MPLL:
|>
|> ''4) EXT_UCLK0 clock is external clock.(XpwmECLK PAD input)
|> EXT_UCLK1 clock is generated clock by SYSCON. SYSCON generates EXT_UCLK1
|> for dividing EPLL or MPLL output.''
|>
|> X54 ds p982.  This is preferable to USB of course :-)
|
| Thanks Andy!
|
| look at this:
| from:
| Siemens WM/MC75i(v00031)/mc75i_atc_v00031.pdf
|
| <<p15>>
| MUXn: Is the AT command usable on the Multiplexer channels MUX1, MUX2,
MUX3?
|       +      Yes
|       -      No
|       ±      AT command is usable, but under the restrictions
specified in the
| section related to the command.

Better confirm nothing important is marked up as "-" there :-)

| Refer to [5] which provides a detailed description of the multiplex
| architecture and step-by-step instructions of
| how to install and configure the multiplex mode. The WinMUX2k driver
and its
| source files can be supplied on
| request. Please contact your local distributor to obtain the latest
| installation software and user's guide.

This creates the need to tag outgoing "packets" as being on one
subchannel or another, but I think this is basically a userspace /
serialized access issue.  "packets" coming back have to be sent to the
right place too but again the code for it is probably fairly simple and
in userspace.

All being well it seems we just hook up ASC1 at the highest baud rate
the module can handle, and take care about generating that rate on the
6400 and we're good.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkga2AcACgkQOjLpvpq7dMpJTgCgkg+iP450WbqZl3i/u4jhL9WV
TRsAn1h85v4t8wWElAFxBttXnLB+BaI7
=HGev
-----END PGP SIGNATURE-----




More information about the hardware mailing list