Great harware, VERY Poor firmware
Posted: Sat Dec 06, 2014 3:45 pmThis module is spoilt by poor firmware.
I have a number of these from different sources. The first module I plugged in look promising, defaulted to 115200 baud and mostly worked. Subsequenct modules have been branded with the url "www-ai-thinker.com" and have firmware 0018000902.
Whoever wrote this firmware has decided that twenty years of convention should be blown away because they happen to use hyperterm or some such crapfest. They have decided all lines should be CRLF not CR terminated. This is dreadful idea, DOS text was never the convention for serial, on minicom/linux I now have to remember to hit ^J after every line.
Where do I start with the bugs !
Bugs:
1) Listens on UDP and TCP port at the same time - poor idea, other than both being "numbers" higher value UDP and TCP port share nothing in common
2) UDP receive randomly stops, sending commands even just "AT" may wake it up, may not .....
3) Cant code UDP discovery, cant UDP broadcast on anything wider than a class C address
4) Cant read MAC address via AT commands
5) Send AT+CIPSEND, module replies > to show it is reay, take some bytes THEN decides busy ... WTF ! Could it not decide before the > prompt like any coded by sane people
6) Cant socket listen on more than one socket properly, erratic results
7) Unreliable.
So I now need to tell my customer I cant code UDP discovery for them, that the module cant handle the protocols they want to use and PS it is a bit slow and not very reliable........
I have a number of these from different sources. The first module I plugged in look promising, defaulted to 115200 baud and mostly worked. Subsequenct modules have been branded with the url "www-ai-thinker.com" and have firmware 0018000902.
Whoever wrote this firmware has decided that twenty years of convention should be blown away because they happen to use hyperterm or some such crapfest. They have decided all lines should be CRLF not CR terminated. This is dreadful idea, DOS text was never the convention for serial, on minicom/linux I now have to remember to hit ^J after every line.
Where do I start with the bugs !
Bugs:
1) Listens on UDP and TCP port at the same time - poor idea, other than both being "numbers" higher value UDP and TCP port share nothing in common
2) UDP receive randomly stops, sending commands even just "AT" may wake it up, may not .....
3) Cant code UDP discovery, cant UDP broadcast on anything wider than a class C address
4) Cant read MAC address via AT commands
5) Send AT+CIPSEND, module replies > to show it is reay, take some bytes THEN decides busy ... WTF ! Could it not decide before the > prompt like any coded by sane people
6) Cant socket listen on more than one socket properly, erratic results
7) Unreliable.
So I now need to tell my customer I cant code UDP discovery for them, that the module cant handle the protocols they want to use and PS it is a bit slow and not very reliable........