0
Cube/dice tray holder
Posted by Chris
on
Friday, October 09, 2009
After discussing the idea through with Ben Ten we've decided that the cube tray/holder should be big enough to hold just a single cube. The idea is that the trays are "chainable". Each tray has two input and two output pins which talk to the next and previous trays in the "chain" (the idea was based on a chain-linked list, a commonly used data structure in programming and something we've successfully implemented in Robot Steve's Robot Studio software).
All trays set and keep RA4 (prev out) and RC2 (next out) high.
These pins are used to send a signal to adjacent trays in the chain, to tell those trays that another tray exists "previous" or "after" it.
Pin RC2 (next out) on one tray is connected to RA2 (has previous) on the next tray in the chain. The first tray in the chain has RA2 (has previous) pulled low via the pull-down resistor, so that it knows if it's the first in the list. If a tray has a high input on RA2, it knows that there's a tray earlier on in the chain. Each tray starts its dice-reading sequence either when RA2 is low or, if RA2 is high, when it receives a signal on RA0.
The tray starts its dice-reading routine, activating each pin of RB0-RB3 in sequence, and checking for a response on the serial pin. If a response is received when any of the RB0-3 pins are high, the response is deemed to have come from the dice in the tray. When a response is received, the tray sends the message back to the previous tray in the list (via pin TX) if it's part of a chain, or drops the message onto the USB buffer if RA2 is low. So a tray can receive messages either from a dice in its holder (message comes in while one of the pins RB0-5 are high) or from a tray further up the chain (the receiving tray will have finished its dice checks and pins RB0-3 are all low).
If a tray decides that the message has come from the dice, it appends it's own tray ID to the message and either sends it to the previous tray in the chain, or drops the entire message onto the USB buffer.
After completing the dice-reading routine, the tray sends pin RC0 (to next) high.
RC0 from one tray is connected to RA0 on the next tray in the chain. (RA0 is the trigger pin to start a tray off on it's own dice-reading routine).
The mcu then enters a "wait" state, monitoring RC1 (from next) for a high input.
RA1 (to previous) on one tray is connected to RC1 (from next) on the next in the chain. So when a high signal is received on RC1, this tells the tray that all other trays up the chain have completed their checks.
If RA3 is low (there is no tray next in the chain), the tray immediately sends RA1 (to previous) high.
When a tray receives a signal on RC1 (from next) it exits its wait state, and goes into "wait for signal to start" state - either waiting for a high on RA0 (from previous) or RA2 to go low (when "has previous" is low, it means there's no tray earlier in the chain).
This way, we've built a "collapsable" signal and each tray in the chain knows whether
In theory it sounds ok. It make take some time to make up four or five prototype devices to test the whole message-up-and-down-a-chain idea fully!
All trays set and keep RA4 (prev out) and RC2 (next out) high.
These pins are used to send a signal to adjacent trays in the chain, to tell those trays that another tray exists "previous" or "after" it.
Pin RC2 (next out) on one tray is connected to RA2 (has previous) on the next tray in the chain. The first tray in the chain has RA2 (has previous) pulled low via the pull-down resistor, so that it knows if it's the first in the list. If a tray has a high input on RA2, it knows that there's a tray earlier on in the chain. Each tray starts its dice-reading sequence either when RA2 is low or, if RA2 is high, when it receives a signal on RA0.
The tray starts its dice-reading routine, activating each pin of RB0-RB3 in sequence, and checking for a response on the serial pin. If a response is received when any of the RB0-3 pins are high, the response is deemed to have come from the dice in the tray. When a response is received, the tray sends the message back to the previous tray in the list (via pin TX) if it's part of a chain, or drops the message onto the USB buffer if RA2 is low. So a tray can receive messages either from a dice in its holder (message comes in while one of the pins RB0-5 are high) or from a tray further up the chain (the receiving tray will have finished its dice checks and pins RB0-3 are all low).
If a tray decides that the message has come from the dice, it appends it's own tray ID to the message and either sends it to the previous tray in the chain, or drops the entire message onto the USB buffer.
After completing the dice-reading routine, the tray sends pin RC0 (to next) high.
RC0 from one tray is connected to RA0 on the next tray in the chain. (RA0 is the trigger pin to start a tray off on it's own dice-reading routine).
The mcu then enters a "wait" state, monitoring RC1 (from next) for a high input.
RA1 (to previous) on one tray is connected to RC1 (from next) on the next in the chain. So when a high signal is received on RC1, this tells the tray that all other trays up the chain have completed their checks.
If RA3 is low (there is no tray next in the chain), the tray immediately sends RA1 (to previous) high.
When a tray receives a signal on RC1 (from next) it exits its wait state, and goes into "wait for signal to start" state - either waiting for a high on RA0 (from previous) or RA2 to go low (when "has previous" is low, it means there's no tray earlier in the chain).
This way, we've built a "collapsable" signal and each tray in the chain knows whether
- it's waiting for a tray earlier in the chain to complete
- needs to perform a dice-reading routine
- or that it's completed its checks and is waiting for trays later in the chain to complete
In theory it sounds ok. It make take some time to make up four or five prototype devices to test the whole message-up-and-down-a-chain idea fully!
Posts
Post a Comment