Pick the right wireless sensor/controller for your connected MCU-based design
WiFi Modules
WiFi modules come in two fundamental architectures. One architecture assumes an MPU with large memory space and a Linux or Windows like operating system with the OS providing many of the features required. The second architecture choice assumes an embedded design with most functionality provided on the module. This later approach is much more suitable for MCUs due to the limitations of performance and security.
Depending on the MCU and operating system, both architectures can be used for embedded designs. The key factors which influence this choice are:
* Required performance (better with more services on the host processor)
* Available memory space (more features on the host processor take more memory)
* Operating system driver availability
If moderate performance is required then the fully embedded solution is lower risk and easier to implement.
WiFi modules often have an on board TCP/UDP stack and may include other higher level application protocols. This may or may not be useful depending on the required features and the implementation of the remainder of the system.
By using these on board protocols the design of the system is less flexible. Requirements for routing are a good example of the limitations of on board TCP/UDP capabilities. It also requires a special driver to provide access to the functions which is module specific and therefore requires extra integration.
Higher performance WiFi modules do not include the protocol stack on the module. These modules have support for lower level WiFi functions and provide an interface to integrate a new network driver into an existing TCP/UDP/IP stack on the host MCU or MPU.
The major additional requirement on the MCU or MPU is an 802.1X supplicant along with some additional configuration routines. This approach offers the best flexibility and integration with the cost of some extra Flash space. Performance and features are far superior to embedded modules.
Bluetooth modules
If your requirement is for a serial profile then the protocol support for a Bluetooth or Bluetooth LE module may be sufficient. One of the significant limitations of Bluetooth modules is the lack of on board profiles. If you are outside the very basic profiles you need to use the HCI interface and add an external Bluetooth stack.
For the on board profiles, interfaces may be less than optimal. They have the same integration issues that WiFi modules have. Vendors offer interface software but this still must be integrated into the MCU and/or MPU environment to provide an integrated environment.
UHF and Proprietary Radios
These modules come without protocols or with proprietary protocols. Although proprietary radios may be a good choice, proprietary protocols can create long term support and maintenance issues.
GPS Modules
GPS modules are generally easy to use and easily integrated. Often these features are included in other modules today, typically GPRS modules.
GSM and GPRS
GSM/GPRS modules may have network specific requirements built in at the protocol level. Implementation using TCP/UDP is required and PPP or SLIP support is mandatory. A separate network server is required for internet connectivity to provide the other end of the serial line and depending on the vendor the integration might not be easy.
Implementation of a TCP/UDP stack with GPRS is a good example of why on board TCP is inflexible. In this case, the TCP stack requires a second network driver to talk to the rest of the system that the GPRS supports. This second driver can’t run on the GPRS module and must run on the external MCU or MPU.
Loading comments... Write a comment