- Mon Jan 12, 2015 6:44 pm
#7145
Hi Edocecrous,
It looks like you and I have been heading down parallel paths. I too am an old assembly language programmer hobbyist just starting to play with these ESP radio modules. I initially learned 8080 assembly language programming running on the CP/M operating system. It was a tough move for me going to DOS from CP/M but now but DOS is my friend. I keep hearing about this Linux thing but I don’t think it’s here to stay!
I have an existing network of microprocessor devices in my house hooked together via RS-485 in a hub and spoke network. I would like to replace the hardwire RS-485 connections with ESPs.
Like you, I picked up a few ESP-01 modules and began trying to figure out how they work by talking to them directly using TeraTerm through FTDI serial modules. It’s been an arduous process. Before I started modifying my microprocessor assembly code I wanted to get a feel for how these radios work and what happens when things are working and then something fails or reboots. What will I need to do to detect the failure and what does it take to restart the connections on the fly? I want to initially start with a standalone AP with 3 STA nodes connected. I’ll share my experience:
My modules came preloaded with V0.9.2.2. After making sure the modules worked the next thing I did was try to burn new code into my modules. Like you I downloaded the ESP8266_flasher.exe downloader software. I too had the issue that my FTDI modules were assigned COM ports > 10. I was able to Google and find out how to manually go in and edit the registry to swap around COM number assignments in order to get these four FTDI modules to be assigned to COM < 10.
I then discovered that more than one file had to be burned into the ESP and the files had to be located at specific addresses. The downloader loaded the first file at 0x00000 just fine. Wow, that was easy. Cool! I went to load the next file and the software wouldn’t load it. I could only load files with the file location set to 0x00000. So, I used my handy dandy hex file editor and manually pasted the two files together at the appropriate memory locations then filled the locations between the two data locations with 0xFF. That worked. But wait, there’s more! I found there was a third location that needed to be blanked with 0xFF so I once again turned to the hex editor to solve the problem. I was able to successfully burn this single file image into the ESP. Hey, when the only tool you have is a hammer, make all your problems look like a nail.
OK, now I have working modules with the latest greatest software revision. I figured out pretty quickly that I had to use AT+CIPMUX=1. I thought I could set one radio as an AP using AT+CWMODE=2 and the other radios as STA using AT+CWMODE=1. I could get the radios to connect, IP addresses got assigned but I was never able to get the CIPSTART command on the AP to succeed when trying to connect to the STA nodes. I can only get CIPSTART to work if both radios are in CWMODE=3. This bugs me because I don’t want to see ( and I’d prefer all my neighbors not see) every module when I use CWLAP. I really only want to see the single hub AP. But I digress…
Moving forward… Setting each radio to CWMODE=3, I can get them connected and successfully perform AT+CWSTART from the hub radio (this node being the AP if mode 2 would work) to the other two nodes (which would be in mode 1 if I could get them to work that way).
Let me digress again ( I’m a pro at that). Actually I have two tools, a hammer and a pry bar! I would be remiss not to give credit here. I got tired of typing, retyping, mistyping AT commands. I discovered Peter Scargill created a neat terminal program that I have used for running these tests. His terminal software allows me to quickly issue/re-issue commands manually to the radio modules for testing. You only have to type a command once then you can select and re-send any previously typed commands. (See his blog for more information). Great tool! Thanks Peter! I have noticed however when using his tool that after sending an AT+CIPSEND command, the radio never returns a “>” prompt . I have verified that Peter’s terminal is sending the command out properly to the radio. I found that once I get the radios to connect I have to switch back over to TeraTerm in order to send the CIPSEND commands. I think the radio needs a time delay between the end of the text of the CIPSEND command and the CR/LF. As I said, I have verified that Pete’s code is sending the command with CRLF just as TeraTerm. It seems to me the only difference is the time factor of a human typing the CIPSEND command with the inevitable delay between characters as they are manually typed into TeraTerm. Peter’s code is probably blasting the data out with no (or little) inter-character delay. When you crank his terminal up you can specify a delay between lines of data that get sent which I have found that useful. But that is the only user defineable delay.
On to the next hurdle. It turns out the problem using Peter’s terminal led me to finding the next issue. If for any reason I get a disconnect between the Hub and a Spoke, I would think I could do a CIPCLOSE=x on the two affected radios then perform the appropriate CIPSTART and restart the affected connection. Nope, Nill, Nada. So I tried resetting the affected STA module using AT+RST. I still can’t get AT+CIPSTART to reestablish the connection. I tried resetting both radios via the AT+RST command. Nope. The only way that I have been able to successfully restart a failed connection is to pull a hardware reset on the hub radio and the spoke radio which also means resetting the other spokes since their connections get blown away when I reset the hub.
Sorry, I didn’t mean to write a thesis. Anyway, that’s my experience. I’ve learned a lot as I’ve gone through this exercise, most of which I don’t really understand. Maybe this will help you and/or others. I know next to nothing about wifi, AP’s, Stations, Clients, Servers, etc. so I’m sure there are some things I’m probably not doing right. Maybe others can shed some light on what we might do differently in order to make this work in a cleaner fashion.
BB