Standalone module vs. uC acting as master to module


I have a successful application that has been deployed many times. It is based on an AVR ATMEGA16, and right now I am working in adding remote control and telemetry by using a wireless module. I have concluded in using the Q2687 which is much more powerful that the AVR and in addition will offer the wireless functionality I am seeking for. My current approach and plan is to completely eliminate the AVR and use just the Q2687 to do what the AVR currently does plus the wireless part. So, my questions and discussion topic is this:

In these cases, is it better to use a microcontroller (uC) as a master and use a wireless module just for the communication part, or using just a wireless module can be a perfectly good solution. Sierra Wireless is advocating the the latter, but I have seen several people taking the former approach. Of course, using just the module eliminates parts, some cost, etc. But, I am asking for advantages and disadvantages of one approach vs. the other, and any other point somebody might feel worth while sharing here.

To get the discussion started: one disadvantage of using just the module is that (for the US at least) if I develop all my application in C on the Q2687 then I cannot replace the module with the AirPrime Q26 Elite CDMA in case I want to use Verizon’s network (my understanding is that the Q26 Elite can be controlled just with AT commands, and it cannot be programmed in C). In addition, if I decide to migrate from Sierra’s hardware completely and I have all my application developed in C on the Q26, then using another module from another vendor would mean major rewriting of the software. Otherwise, if I a use a uC to send AT commands to the wireless module, migrating to a different vendor might be easier since the uC code would be maintained, a big part of the AT command scripts could be transferable.



There are pros and cons to both methods, here are some that I have found designing products using both methods:

Module Only - Pros

  • Much easier access to all module functions - don’t have to have a monster AT command parser for the many AT commands you will need to access module features
  • Much easier over-the-air application upgrades - you don’t have to worry about writing another bootloader for your uC and then transferring the upgrade file via serial port
  • Lower BOM count and simpler product - theoretically less can go wrong!
  • Simpler production - only one programmable part, firmware and application versions can be easily controlled

Module Only - Cons

  • No accurate sub-1ms timing and IO control
  • Limited power consumption control

Module + uC Pros

  • Possibility of using different module vendors
  • Possibly simpler changes to application for different modules
  • Accurate sub-1ms timing and IO control
  • Much lower power consumption achievable if you are smart

Module + uC Cons

  • Non-standard AT command set - means there may not be some important AT commands/functionality on certain modules which could lead to major changes in application code.
  • Increases complexity of design - more chance for production errors
  • DOTA more complex, especially if module firmware also requires upgrades with uC firmware
  • Increased production time if firmware download to module is required in addition to uC firmware

We try to stick to only using modules, unless an external uC is required because of timing requirements (unfortunately this is the case more often then not). Generally we use a programmable module and uC and do most of the heavy processing on the module and just use the uC for basic timing and power control for low power applications.


Note it doesn’t have to be “either/or” - it can be advantageous to use both a microcontroller and an “intelligent” module with embedded application; eg,

  • The module can do the “heavy lifting”, allowing you to use a (much) smaller/cheaper/simpler microcontroller;
  • because only a small/simple microcontroller is used it can be very low power; and can turn the module off completely for maximum power saving;
  • etc, etc,…

An example here: