CURRENT ISSUE
Contests
Feature Article
|
|
Issue #204 July 2007
Pyxos Power
by Tom Cantrell
Start | LAN-In-the-Box |Down to the Wire | Variable Interest | Hook 'Em Danno |Build it and they will come | Match point | Sources and PDF
BUILD IT AND THEY WILL COME
The final piece of the puzzle is the “Pyxos FT Interface Developer” program. It’s largely a point-and-click affair by which you define overall network options and specify the network variables associated with each Point. The tool uses the completed network specification to automatically generate header and include files that are combined with the source for the API and your application to create the final code.
Beyond the obvious, such as the number of points in the network, Photo 3 shows other options that can be selected. The default configuration assigns a timeslot for each Point in the network, but it’s possible to override that by reserving additional timeslots. That allows Points to be added to the network without having to change the overall frame timing (i.e., Point bandwidth and latency remains fixed). Other options allow the Pilot to monitor the health of the network (e.g., error statistics) or take advantage of a protocol analyzer feature that enables logging all network activity. If you don’t have a use for the Pyxos FT chip 10-MHz clock output pin, here’s where you can disable it to reduce power consumption and noise.
 |
| Photo 3—Another step in creating a Pyxos FT project is defining the basic characteristics of the network (e.g., the number of Points and timeslots), as well as embellishments, such as statistics gathering (e.g., for dynamic error recovery) and a protocol analyzer feature (i.e., network logging) for debugging. |
Once the overall network and Pilot options are defined, it’s time to move onto the Points themselves (see Photo 4). Point-specific characteristics include those mentioned above (e.g., statistics gathering, clock output disable) as well as defining a Points registration method at startup. Registration options include automatic (the Point and Pilot negotiate for a free timeslot), hardwired (the Point uses a specific reserved timeslot), and manual (an external event, such as pressing a switch, triggers registration). Note that manual registration is the only option for an unhosted Point.
 |
| Photo 4—A Pyxos FT Project starts with the big picture representing each of the Points on the network. In turn, each Point is defined by the standard network variable types (SNVT) associated with its particular application. |
The next step for configuring a Point depends on whether it is hosted or unhosted. For the latter, it’s simply a matter of specifying the direction for each of the five I/O pins on the Pyxos FT chip. Note that four of them can be defined as either input or output, but the fifth pin is input only.
Hosted points are defined in terms of their network variables, which are the inputs a Point receives from the network and outputs it delivers to the network. As described earlier, network variables can be chosen from a list of existing standard types or, using another utility (resource editor), you can define your own.
Once everything (i.e., network, Pilot, Point) is specified, the Interface Builder program automatically generates the header and includes files that are combined with the API and each device’s own application code. Run that through all the compilers involved (i.e., for the Pilot and hosted Point MCUs) to generate the different binaries and you’re in business.
|
