Progress<\/b><\/p>\n
This week I continued working on the Python firmware logic. A few changes occurred with our protocol while I was writing it that slowed down my progress.<\/span><\/p>\n We realized that technically tiles do not need a clock line. Originally, we planned that a tile\u2019s top and left clocks would be driven by their top and left neighbors through two clock lines. Doing so would indicate to the tile when to read from the data line of its sides. But instead, we could have the neighbor tiles\u2019 data lines be always high by default, and then go low for a clock cycle when it\u2019s ready to send data. The main tile would then determine when to read from its neighbors through its internal clock. For example, let\u2019s say that a clock cycle is 1 second. If a tile\u2019s top neighbor goes from low to high, and the tile detects this internally at timestamp 15s, the tile will be prepared to read from the tile at timestamps 16.5s, 17.5s, etc.<\/span><\/p>\n We also realized that we needed to change the order of bits sent in a word. Originally, this order was:<\/span><\/p>\n But we decided to switch the live and sending bits. The reason we did so was that the sending bit\u2019s job was to indicate to the neighbor that it should expect a message to be sent via the next 8 clock cycles. When the sending bit is high, the neighbor knows that whatever series of messages the tile was sending is now complete.<\/span><\/p>\n It\u2019s important that the sending bit be in the beginning of the word, so that for the neighbor\u2019s perspective, if the tile is not in the middle of a message, and suddenly the data line goes low (after being high), it knows that a new message is starting.<\/span><\/p>\n This method is useful for the case that a child is sending a parent the current topology from the child\u2019s perspective in a series of messages. If the parent realizes that one of the messages was corrupted (through checking the parity bit), the parent would need to send a \u201cresend\u201d request message to the child. The child is then expected to start over from the beginning of the series of messages. While the child is processing the resend request, it might still be sending data to the parent in parallel. How would the parent know that the child processed the resend request and has started sending the data from the beginning? If the child sends a high after it finishes a word, the parent knows that the child completed (or interrupted) sending the series of messages. Then when the child is low again, the parent knows that the child has begun resending the series of messages.<\/span><\/p>\n Current progress can be found under \u201ctileFirmware.py\u201d and \u201ctileFirmwareSimulator.py\u201d of our repository: <\/span>https:\/\/github.com\/melodeeli98\/codeblox-capstone<\/span><\/a><\/p>\n Schedule<\/b><\/p>\n Right now, I am scheduled to complete the code by next Monday (2\/24). Because of these protocol changes, I am a little behind schedule. I plan to spend extra time this weekend catching up, and will have the code complete and tested by Monday night.<\/span><\/p>\n According to the Gantt chart, I am scheduled to start working on the C simulator of tiles next week. I hope to be able to start this on time.<\/span><\/p>\n Goals for next week:<\/b><\/p>\n Progress This week I continued working on the Python firmware logic. A few changes occurred with our protocol while I was writing it that slowed down my progress. We realized that technically tiles do not need a clock line. Originally, we planned that a tile\u2019s top and left clocks would be driven by their top and left neighbors through two clock lines. Doing so would indicate to the tile when to read from the data line of its sides. But…<\/p>\n\n
\n