This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Mobile 2G/3G/4G modem manager or RIL (Radio Interface Layer) for UART and USB CDC modem interfaces?

Hi all,

I'm looking for any open source modem manager or RIL (Radio Interface Layer) which abstracts AT-based 2G/3G modems which are connected to a C2000 microcontroller and which sits on top of a physical interface using either a UART/SCI driver or else USB CDC driver (USB modem with virtual serial port). 

I'm working on a project where I want to connect from a F28069-based custom PCB to a Sierra Wireless, Telit, Maestro or Cinterion GPRS/EDGE modem. I'm not running an RTOS on the F28069, just a pre-emptive nano-kernel or cyclic executive scheduler.  There seems to be lots of SCI and example serial code available, but very few examples or ports of higher-level communications middleware stacks for C2000 available. I don't need to support a TCP/UDP/IP stack over PPP, but rather just need to abstract the wireless telephony call control (AT-based call setup and teardown) alongside support for basic serial console i/o (SCI) and Zmodem file/transfer.

So I am considering a port of the Linux/FreeDesktop ModemManager (http://www.freedesktop.org/wiki/Software/ModemManager/).  I think that porting a subset of the Android RIL (http://www.kandroid.org/online-pdk/guide/telephony.html), or oFono (https://ofono.org/) may be overkill or too complex for a C2000-based device, particularly when I want to avoid dynamic memory allocation and don't have the support for Linux DBus style inter-process communications interfaces, nor the requirement for TCP/IP over PPP.

Does anybody have any other suggestions for an alternative open source implementation of a device-independent AT-dialer / interpreter API or abstract interface for wireless modems?

Cheers,

Gord Finlay

P.S. I realize that a Concerto type hardware architecture might be a better hardware architecture (dual core Arm Cortex M0 + C2000). It would facilitate partitioning the communications related tasks (on Arm) from the signal-related and DSP algos running on the C2000. However, we are stuck with the single core F28069 C2000 MCU for the time being.