This board allows experimenting with a WIFI link on a general purpose MCU.
To make the experience fit your profile, pick a username and tell us what interests you.
Completing the system required a few details. I needed a few toggle switches for the minimal user interaction, which needed ESD and EMI protection before feeding them into the microcontroller GPIO inputs. A simple board with RC filters for the EMI protection and TVS diodes for the ESD protection was designed and built. This board is buried under the main PCB and not visible in the pictures. The main PCB was designed to use a standard rectangular header to interface to the LCD display. I got a great deal on a box of LCD displays that already have a flat cable attached. Rather than remove the flat cable from the display, I made a small adapter board that goes from the .100 2 row rectangular header to the flat cable. This had the advantage of being a small, inexpensive board to check the new footprint of the flat cable connector. The adapter board is visible in the upper right corner of the box. Power and serial data come into the box on the 4 pin round connector at the bottom. A power fuse was added to protect the host system from possible faults in this box.
In the past, I have used RS232 level shifters and a 9 pin DSub connector for serial connections to projects like this. It seemed like a better idea to just make a small board with a chassis mount USB connector and a USB to serial chip on board. This would allow direct USB connection and skip the RS232 level shifters. Amphenol makes some really nice chassis mount USB connectors that worked perfectly for this. This module will replace the 9 pin DSub in the future on my projects.
An aluminum case was built from 0.030" 5052 aluminum and powder coated. All the boards were installed and the system tested. A couple of quirks in the user interface code needed cleaning up, but it looks good now. A back plate that is not shown will allow mounting the box in the system.
I used a serial interfaced sensor for the initial usage on this board. The sensor code was module tested using a desktop Linux box to get the sensor data parsing running correctly. That code was moved over to the embedded environment for the Atmel MCU and the front end ported to the I/O drivers in this project. Completing this code revealed a shortcoming (OK, bug) in the radio manager code which I fixed. The radio manager code is working well enough to consider for initial deployment on this project.
The next step is to build a case for and install it for real testing.
As is common on projects that run this long, I found that ST has released another version of the WIFI module that has the SMPT code built in. It uses a different footprint, so a board change would be required to run it and some code changes would be required. I think that I am going to work with what I have already for a while before I consider a board revision.
I just finished up a contract gig, so I will be back working on this for a while.
I wrote and did some testing on a real user interface for the system. It is a text based parser. The user interface will be used rarely once the system is deployed, it is for configuration and debugging. More thorough testing on the user interface is in order before calling it done.
There is still some cleanup work to do on the Radio Manager code and the SMTP code, but that should be fairly quick. Then is is time to start working on the sensor code that will trigger the operations.
The SMTP client code is operating enough to send a message through my ISP's server to the outside world.
The SMTP protocol is not very complex, but it has evolved quite a bit in the many years it has been around. Finding documentation specific enough to get the authentication stuff working was the most difficult part.Information is scattered through several RFC documents.
I had a weird problem where the SMTP simulator that I wrote worked OK, and the real server did not. It turned out that I was using \r\n sequences to end the commands to the WIFI module, and it only needed the \r character. When I issued the socket write command (AT+S.sockw) to send a command or data to the SMTP server, I used the \r\n sequence to close the command. The \n character was unnecessary and it got stuck on the front of the SMTP command that I was trying to send. This caused two problems. First, it caused the real SMTP server to send an error message about bad syntax before processing each command. Second, since you must tell the WIFI module how many characters you are going to write to a socket, it resulted in one fewer of the "payload" characters being sent to the socket.
After a lot of poking around with Wireshark, and digging through my TCPIP book, I figured out the problem and corrected it.
The authentication still needs some work. The AUTH LOGIN authentication does not send usernames and passwords in clear text, but it is sending them in a simple BASE64 format that obscures stuff but would still be trivial to snoop. Possible fixes for this are to investigate the CRAM-MD5 protocol or to see if I can just open a secure socket to the SMTP server and let the existing code in the WIFI module deal with the encryption.
I still need to clean up the code, add some error handling and such, but this is a major milestone for this project.
After messing with getting sendmail to run on a fedora 24 box for a week+, I punted it and wrote a simulator that will conduct the network traffic for an SMTP transaction without actually doing anything. Debugging sendmail was making no progress, and that is not my goal anyway. The simulator is very simplistic, but should be sufficient for initial development of the SMTP client code. The simulator was a one afternoon project from some libraries that I already have written and debugged. I verified the sequence of commands and the responses from the server by telneting into my ISP's email server and issuing the command sequence to log in and send the email.
The ST module used on the first board that I built has it's antenna on the module. This will limit the case design for the board, so I built up another board with a slightly different module that has an antenna connector instead of the actual antenna. The board construction and checkout went smoothly and the new board works fine. This way, I can stick the antenna outside the case when the board is put to use.
The socket read and write code is working. I started looking at what would be needed to implement TLS, before I start on the SMTP code.
Using TLS will need a couple of certificate handling commands to be implemented, and needs date and time in the seconds past 1/1/1970 format. The actual open command for a TLS socket just requires adding an s to the AT+S.SOCKON command. At least I will not have to rip up or re-implement a big chunk of code for it.
When I did the first pass on the clock/calendar code, I ignored the Day of Week value. It turns out that the date string in an outgoing email wants the day of the week value, so I wrote code to calculate that. It was pretty similar to the code to calculate the number of seconds since the epoch.
Several additional values were needed to store in the NVM/configuration structure, so those got added to the NVM code.
I have taken a couple of diversions from this project, as it is a significant project, but it is making progress.
The radio manager firmware is progressing pretty well. It is currently tracking/controlling the power-up, connect and socket open/close operations with the ST WIFI module. The next big piece of code to work on is the socket read code.
Debugging this part of the project requires 3 logic level serial streams to be monitored. A "console" port is used for displaying status, error messages and issuing commands for testing. The serial data to and from the WIFI module needs a serial channel each, to be able to see the raw commands and response data to the WIFI module in real time. The alternative would be breaking and examining serial buffers at each step with the JTAG debugger. I built a little 2 channel logic level serial to USB converter with clip leads on the data signals and ground from an old FTDI module.
Once the basic socket communication code is operating, I need to study the SMTP protocol to be able to send an email from this system. Eventually, I would like to get the ability to receive an email running as well, but that is work for another time. In order to test the SMTP code, I need to set up an SMTP server on my test machine. My plan is to install sendmail and configure it as simply as possible. The test machine is running Fedora, and it is only accessible through a dedicated wireless access point, so I don't think I need to go crazy hardening it for security like I would if it were accessible to the wild internet.
The WIFI module is capable of supporting TLS, but I think that I am going to work on implementing that as a later task.
With the WIFI operating and a socket to the test machine open, the whole board is only pulling about 72mA with 12V in. That is feeding the WIFI module, the Atmel MCU, the clock/calendar and the EEPROM. Turning off the radio drops the current to 40mA, and that is with the Atmel processor running at full speed. Some sleep operations on the Atmel should get that much lower. I am pretty happy about the low current consumption, as this thing will probably wind up running on batteries in some future use.
This weeks progress is all firmware related. Using a simple socket driven program running on the PC connected to my test wireless access point, I was able to open a socket and converse with the program via the WIFI module connected to the terminal program with a serial cable. The most significant problem in making this work, was that the Linux firewall was blocking my attempts to connect to port 15000 for testing. After some experimenting and net searching, I found the iptables incantation to make it behave.
I have been working on an architecture for the WIFI module handler software. Because I want the CPU to be able to monitor other things while handling the WIFI stuff, I needed to figure out a non-blocking architecture for the handler. The simplest way to deal with line oriented serial data streams in a non-RTOS environment is by looping on the serial port until there is a complete line of text, then go parse and execute that line. Since I want to do other things in parallel with the WIFI system, that idea does not work. An RTOS would be one option, but brings a significant amount of complexity of it's own. Another option is to monitor the receive buffer periodically, and exit the handler if there is not a complete line of text available. When there is a complete line of text available, fetch it from the buffer, parse it and do whatever is appropriate for that message and the current task being done.
This non-blocking architecture is being implemented as a state machine that accepts serial data from the WIFI module or commands from other code in the system. The state machine makes it fairly inexpensive to get back to the right section of code based on the state of the module and what it is doing at the time. When this project is done, I can come back and decide if it was worth it to use this approach or whether I should have just used an RTOS and picked up the extra complexity at the front of the project.
The interconnection between the ST WIFI module and the microcontroller is via logic level serial signals at 115200 baud. When I designed the board, I assumed that it would be easier to interact with the ST WIFI module in real time from a serial terminal while I was figuring out how to talk to the module and get it to hook up to an access point and such. To support this, I put a 6 pin x 0.100" connector that matches the FTDI serial cable pinout on the board and included jumpers to route the serial data lines to the FTDI connector or the local microcontroller. I got the WIFI module to associate and authenticate with an access point this morning. It is possible to ping the access point or a machine connected to the access point now. This makes me really happy because the WIFI module is the last subsection of the hardware that had not been checked out.
The WIFI module uses a variant of the AT command set for configuration and control. So far, it seems pretty straight forward. I think that I will write all of the configuration and SMTP code on the PC and port it to the embedded environment when it is working. Since the serial port is the primary access, this should be the simplest path.
Become a member to follow this project and never miss any updates