I have a general query about any embedded system. Whenever we use any communication device,(maybe Bluetooth or WiFi or GSM), is it advised to use AT commands to control the device?
PS: I do not wish to use APIs
Thank you in advance.
Not all communication devices need you to program using AT commands.
For example, if you desire a simple wire replacement to connect two microcontrolelrs (MCUs) using two HC-05 Bluetooth modules (BT) then first you may "program" them or "set their parameters" using AT commands. This could mean setting, name, role, password etc. Once you set say- one as a master and other as a slave and set password to a known 4-digit number, you are ready to go.
Take two MCUs and two BT modules , "paired" to each other. Now simply connect BT modules to UART outputs and send data serially to it at 9600 baud. Whatever character you send to BT module, it will be radiated by that to another module which will convert that into bit stream and send it as a character to second MCU. Here you do not have to worry about AT commands.
Using AT commands in programming is not that difficult, though. There are some excellent simple video tutorials on youtube of connecting two MCUs together. You may see tutorials on Arduino and use same commands on ARM MCU as well.
I have used BT, Zigbee and WiFi module ESP8266 and all use a diffiernet AT command set. Best thing is to connect MCU & BT to a PC as the tutorial says, set baud rate, make the device to enter AT command mode and try out manually typing out AT commands and see the device response. Prior to that download AT command set sheet pdf and keep it half open on screen. You will enjoy it thoroughly!
It depends on the resources you have in the embedded device. If you have a Cortex-M0 with little RAM, it will be hard for you to implement, tor example, a TCP/IP stack. In that case, you should let the communications device do it an talk to it in whatever it needs, including AT commands. As bamos stated, this has its limitations, so you will have to weigh in the pros and cons.
Pros: you don't need to provide hardware resources for the communications protocol, neither do you have to program it. You can get it running fairly quick, someone else did the testing for you. You will also probably need an RTOS for the protocol.
Cons: lack of flexibility, you can only do what the programmer of the device's firmware had in mind. Sometimes the documentation isn't very good.