Difference between revisions of "GPIO"
From RifidiWiki
(New page: Future site of GPIO) |
|||
| Line 1: | Line 1: | ||
| − | + | =Purpose= | |
| + | GPIO is a sort of serial interface that many readers support. Usually, a reader will have a bank of GPI ports and a bank of GPO ports located on it. (see [[http://www.rfidreview.org/index.php?option=com_content&task=view&id=14&Itemid=57&limit=1&limitstart=1| this]] for an a picture of how it looks on the alien reader). They are just like "lines in" and "lines out". | ||
| + | |||
| + | GPIO is commonly used for communication with other devices (such as photo eyes or light stacks) to make the reader smarter. Although the communication between the reader and the device conceivably could be defined by a complex, vendor-defined protocol, it is typically almost trivial; The reader only notices when a GPI line goes high or low (and | ||
| + | thus can be represented by a boolean value), and follows some business logic accordingly. For example, a reader could be configured to start a read when GPI port 1 goes high, or it might turn on GPO port 2 when a timer goes off. | ||
| + | |||
| + | It is important to note the differences between GPI and GPO, and how these differences matter to a reader emulator. GPI lines are incoming lines from a smart device. GPI events can trigger things to happen inside the reader, such as tag reads. GPO is basically just output lines to other smart devices to turn them on, or trigger them in some | ||
| + | way. Therefore, GPO lines are not as important because, from the reader's point of view, they can only be turned off or turned on. They cannot actually trigger anything inside of the reader to happen. | ||
| + | |||
| + | =Class Structure= | ||
| + | ==UML Diagram== | ||
| + | [[Image:GPIO_UML.png|thumb|600px|none|A class diagram representing the new radio]] | ||
| + | ==Components== | ||
| + | #'''GPIOState''' The GPIOState Object stores the state of a single GPI or GPO port. It is only accessed through the GPIOController. Before the state of the GPIOport can be changed, it must be enabled. | ||
| + | #'''GPIOController''' The GPIOController is the main interface to GPIO. It is similar to the [[radio]] in that the radio could be seen as an "antennaConroller". Internally, the Controller has two hashmaps. One is a hashmap of GPIPorts, and one is GPOPorts. It exposes methods that control these ports, and it is in this way that the GPIOController is an interface to the GPIOPorts. It also extends Observable because components in a particular reader should observe the GPIOController to find out when GPI Events or GPO Events happen. When the GPIOController calls its notifyObservers method, it will pass an arraylist of Objects as the additional argument (arg2 in the above diagram). The first item will be a string that is either GPI_EVENT or GPO_EVENT, and the second is the port number that changed. In this way a component in the specific reader can filter out GPIO Events that are not meant for it. | ||
| + | =Integration with Readers= | ||
Revision as of 16:57, 21 November 2007
Purpose
GPIO is a sort of serial interface that many readers support. Usually, a reader will have a bank of GPI ports and a bank of GPO ports located on it. (see [this] for an a picture of how it looks on the alien reader). They are just like "lines in" and "lines out".
GPIO is commonly used for communication with other devices (such as photo eyes or light stacks) to make the reader smarter. Although the communication between the reader and the device conceivably could be defined by a complex, vendor-defined protocol, it is typically almost trivial; The reader only notices when a GPI line goes high or low (and thus can be represented by a boolean value), and follows some business logic accordingly. For example, a reader could be configured to start a read when GPI port 1 goes high, or it might turn on GPO port 2 when a timer goes off.
It is important to note the differences between GPI and GPO, and how these differences matter to a reader emulator. GPI lines are incoming lines from a smart device. GPI events can trigger things to happen inside the reader, such as tag reads. GPO is basically just output lines to other smart devices to turn them on, or trigger them in some way. Therefore, GPO lines are not as important because, from the reader's point of view, they can only be turned off or turned on. They cannot actually trigger anything inside of the reader to happen.
Class Structure
UML Diagram
Components
- GPIOState The GPIOState Object stores the state of a single GPI or GPO port. It is only accessed through the GPIOController. Before the state of the GPIOport can be changed, it must be enabled.
- GPIOController The GPIOController is the main interface to GPIO. It is similar to the radio in that the radio could be seen as an "antennaConroller". Internally, the Controller has two hashmaps. One is a hashmap of GPIPorts, and one is GPOPorts. It exposes methods that control these ports, and it is in this way that the GPIOController is an interface to the GPIOPorts. It also extends Observable because components in a particular reader should observe the GPIOController to find out when GPI Events or GPO Events happen. When the GPIOController calls its notifyObservers method, it will pass an arraylist of Objects as the additional argument (arg2 in the above diagram). The first item will be a string that is either GPI_EVENT or GPO_EVENT, and the second is the port number that changed. In this way a component in the specific reader can filter out GPIO Events that are not meant for it.
