RFID Fridge

While being able to quickly check the inventory of your refrigerator while outside of it can lead to some interesting applications, more useful is the ability to remotely access it from elsewhere (from the grocery store, a friend's house, etc). Because of this, we decided that running a HTTP server off the device would be both a "cool" and extremely practical feature.

To do this, we needed implemented lower levels of the OSI network model (PHY, MAC) as well as higher levels (TCP/IP, HTTP). On the lower level, the SmartFusion MSS MAC provided us with drivers which gave us a relatively simple ethernet interface. As writing our own TCP/IP stack would have been out of the scope of our project, we decided to go with an open-source TCP/IP stack named uIP. uIP is an extremely low overhead stack which interfaced well with FreeRTOS, allowing us to add HTTP functionality to our project.

We were very successful in using uIP to implement a HTTP server. Without going into the internals of uIP, it provided an interface to respond to TCP/IP events. For example, when a new connection was established, it allowed us to send a HTTP response with a basic webpage containing our refrigerator data (inventory, temperature).

After implementing the HTTP server, we moved to implement the HTTP client, used for looking up UPCs from an (unofficial) database online. This proved harder than expected. It became apparent that while possible, it was difficult to operate uIP in both a server and a client context at the same time. Because uIP nicely separates network application code, and lower level functionality (where MSS MAC functions are called), it was possible to have two "applications" running on uIP. However, because we were initiating requests now, we could no longer just block and wait for requests to come in. Setting a proper timeout on the MAC receive function proved difficult, and our HTTP lookups timed out most of the time. While we were able to get lookups working *some* of the time, we decided to leave them out of the final demonstrated project, as they didn't work consistently as we wanted.

Unexpectedly, getting the SmartFusion MSS MAC working was one of the most difficult aspects of adding network connectivity. The reason was that although demo projects and references were provided, none made it obvious how to provide the PHY (the chip that connects the MAC link-layer to the physical cable) with the correct clock. Without this clock, the MAC was unable to communicate with the PHY over the MDIO bus (in the MAC driver, probing for the PHY failed). After troubleshooting for many hours, we determined that we needed to manually route our GLC clock to pin F2 (the documentation mentioned X1 but not F2, X1 is apparently the physical PHY pin). After doing so, the MAC was successfully able to initialize, finding the PHY (additionally, the ethernet port link lights finally came on).