Hi,
Wondering if someone could detail the pro and cons of using a programmable Wifi module VS a AT command controlled one.
I never was a big fan of AT commands and strings for m2m communication but if it’s really much more work to program those devices directly, I may have to.
Any relevant experience would be helpful here.
Thanks
Well without more information on the intended use, this is a broad question. There's almost never a one size fits all solution.
From a purely generic standpoint, one advantage of the programmable module is that it can be a all-in-one solution if you needs fit within the capabilities of the module. Most of the programmable modules have some I/O such as GPIOs, and can even have on system ADC, SPI etc. So if the on module I/O is sufficient then everything can be done on the module.
The AT command set modules require additional processing to be done on some other processor. That could be a big-iron PC or a small embedded SOC/MCU. At command set modules are generally designed for a specific purpose, say like zigbee. While a programmable zigbee module can and may give you access to the 802.15 layer directly. This can be useful when you need to do something that doesn't quite fit into say the zigbee protocol be can be accomplish using the underlying 802.15 layer. Of course this assumes you are in control of the both ends of the communications chain. This is not to say there are not any AT command set modules that can't do that as well, just not as many.
I've used zigbee as an example, but the same can follow with other wifi protocols as well. Each of these modules have their place and the correct one depends highly on the application. Another consideration is access to developers. If you already have PC programmers and the AT command set modules can meet the requirements, then connecting a AT command set module to a big-iron PC lets one take advantage of the developer resources you already have. Programmable modules require a learning curve for not only the programming of the module but also the tools and environment, but generally provide more flexibility/capability.
So it really depends on the module choices and application
Echo what 'hodgec' stated.
I've used both in multiple projects. The AT commands can be OK, but there are always limitations and depends upon what application functionality the vendor exposed via the "AT" commands. You need to know your requirements and carefully make sure everything needed is accessible via the module's AT commands. For example, I have one customer transitioning an existing product from an AT style Wifi module to a more direct controlled Wifi module, because of the need for additional functionality not accessible via the AT controlled module. The functionality was identified after product launch, so exploring your requirements in advance is an important part of this decision.
Matthew
Well to get started, if your not into programming and you are familiar with AT CMD structures(lines) and you have a hosting software your transmitting too. And their all simply commands of trx RCX or possibly FTP. you should be good to go on that, if everything your doing stays simple.
But if you doing wi-fi, if your talking to wifi you have to transmit to wifi, This is a different protocol stack then the ATcmd structures.
Now let me be blunt their are MANY already existing protocol stacks out there based on STM and Wifi protocols as they all use 802.xx stacks. These exist and can be used right now, and most have already been written, your not plagiarizing any thing here as their open sourced already. I scream FREE CODE THAT WORKS alleluia(time saver LOL).
NOTE: I AM NOT a representative of any of these companies thank god i have my own to worry about.
Examples: Cyprix(just bought out) but supported fully, full libraries also, arduino(most code is open sourced, may have to write some of your own libraries.) These are just 2 there are over 20 of these types of boards out there. Some have only 4 GPIOS some have 15 GPIOs. these are the pros and cons you really have to look at for functionality and potential use. Be careful of the boards that say how many GPIOs and then find out that half of them have been assigned to SPI protocol stacks. which means you cannot use them for any IO input or output for any other stack, as their are already used for WIFI protocol transmission purposes.
I could go on and on about these boards, but being a wireless engineer and software engineer, believe you have a cornucopia of possibilities. If you have money to burn I would recommend buying 4 different vendors boards and try them out. The one that is going to take a lot of work is TI as you will have to write your own stacks and libraries on a lot of it(time not your friend here), BUT you have total flexibility with their board platforms for wifi and bluetooth , their support is not as good as cyprix by any chance though.
Keep in mind that tech support is king if your developing and product from scratch.
Well my horse is tired and so am I hoped this helped.
Good luck brother in Tech :) :) :)
For more robust systems (gateways, infotainment etc) you can use u-blox HOST-BASED modules.
With the advantage of using standard linux commands, you run the stack and applications on an external host processor.
Almost no radio specific learning curve. Once the radio is configured (only standard linux commands are needed), the radio interface will be available to be used as any other device.
In case you really need stand-alone radio check here: u-blox stand-alone.
Thank you, for your awnsers, We are probably going to go with an ESP32 module.
