Embedded Networking and Communications
- Design and build a wired and/or wireless network connecting at least two processors
Learning outcomes:
- Demonstrate workflows used in network design and construction
- Implement and interpret networking protocols
More Evidence:
- Described your design and fabrication process using words/images/screenshots
- Explained the programming process/es you used
- Outlined problems and how you fixed them
- Included original design files and code
At this point, the week's work is not complete. I am a high school Physics teacher, and my students are making their final preperations for graduation. Life has been very busy for the past little bit, so time managment has impeeded progress. However, all of this happens with the promise of much more time around the corner, as the school year gives way to summer.
The short version is that I have designed several boards that should be serial bus enabled. I even made my own standards for the bus connector pin arrangement so that a serial bus wire could be neatly implimented. I bought connectors, cable, an LCD screen, and a button matrix keypad to make all of this work... We'll see how it goes. The idea here is that instead of working on the example nodes (which would be more achieveable) these circuits will be of use in my final project. I only had time to get one of these milled, because the mill bed would not sit level with my second model. time restrictions kept me from pursuing this further up to this point.
I also started to work on code to control these nodes as I will want them to work in my final project. This was even more of a slow down. Perhaps the smart move would have been to throw an extra LED on each board to just use the example code. Instead, I needed to design the routine I wanted run, determine how to do that, and fiddle with syntax until it was right. I also decided that my serial bus communication would all consist of single 'char' messages. This means I also started to develop standard messages that will be used in my final project. Overall, exciting progress, but I want to wait to celebrate until I actually see evidence of two ATtiny boards 'networked.'
======================= UPDATE ===============================
For the final project, I heavily relied on networking a collection of small boards, based on the ATtiny44. I had to decide my own circuits, standards for the connections, communication protocols, and execution code for all of the nodes.
Designing the Nodes and Code
I designed the circuit boards for the motors and other objects in my final project, using Eagle. Basically, each of the separate parts of the final project had their own dedicated processor in the presented version. The code for those stepper motor nodes was written in C, and communication was an integral part of that code. I simply used Neil’s bit-banging get_char and put_char functions to drive serial communication along a bus. The communication along the bus was done by sending single char characters along the bus, at 9600 baud. The nodes would recognize the codes sent back and forth and act when appropriate.
In the final project, a few of the nodes were programmed in the Arduino IDE and used the Software Serial library. This is a delightfully simple way to manage serial communication, but it definitely abstracts away the mechanics of how the communication happens.
Hardware Bus Connection
The hardware connection that I designed was based on the 2x3 SMD connectors and conformed to the standards listed below for all nodes:
This allowed me to deliver 12V, 5V, serial connections and two common ground connections. Every connector was designed to be the same, so I could simply make connections to the correct pin numbers in Eagle CAD for my standardized serial connection ports.
Understanding the serial connection is a little more complex than the physical hook-ups. Happily, Sparkfun has written up quite the nice explanation of serial communication. Also, based on the interpretation of Neil's bit-banging routine, it appears these lines stay 'high,' unless they are going to send data. Then they drop low for a bit, send individual pits over an interval cycle and then pause for a part of a second before returning to their default 'high' state.
Problems
A common problem that I ran into was the serial line inversion: I needed to make sure that the TX an RX lines connected appropriately so that all of the nodes could communicate, and this needed to be set in code as well as hardware. I also struggled with actually plugging in the connectors, since they were not asymmetric. In the future, I would like to use IDC connectors, to solve this problem.
I also took a while to realize that the get_char function will delay until a character is received. This is a good plan, so that the processors are free to ‘hear’ the char as it comes in, however an interrupt routine would be better. I made sure to connect my RX pins to the ATtiny’s INT0 pin, but never successfully got this working in the C programs. The communication still worked, but I could not simultaneously run operations and listen for a char.
Conclusion
In the end, I was able to developing a working serial bus that ran my final project. Sending char codes along the bus was enough information, and made the entire thing extensible. In future iterations of the project (after the presented version), I would like to consolidate all of the small boards, and reduce the amount of items on the serial bus but keep my hardware standards the same.
You can see all images (used and unused) from this week's work HERE.
You can see all images from the final project HERE.