 | Demand Peripherals Robotics and Automation Made Easy |
|
|
|
Demand Peripherals makes it easy to build robots or other automation. There are several reasons for this. The first reason is that our system is complete. That is, it includes the hardware, the firmware, and all of the API software to let your application control the peripherals. No more buying cards from SparkFun or Adafruit and having to write all of the software layers up to your application. The second reason the DPI system makes things easier is that our system is FPGA based. This lets YOU decide which peripherals to include in the system. No more limiting yourself to the peripherals accessible on an Arduino or trying to figure out how to tie together a handfull of microcontroller. The third reason is that we have full Linux support for all of our peripherals. The interface uses ASCII commands over a TCP connection. Using ASCII commands make building and debugging your application much easier, and using TCP lets you use any programming language for your application. Our system is divide into two parts. Daughter cards contain the electronic components needed. The daughter card might contain the IMU chip, the H-Bridge FETs, or the headers to conect to servo motors. Each daughter card connects to the FPGA card over an eight-wire IDC cable. The cable has power lines and four pins from the FPGA. Open the menu to the left to a list of daughter cards. Each description contains the schematic and meaning of each pin that connects to the FPGA. Note the the daughter card designs are all open source so you can combine all the cards needed for your project onto one PCB card if and when you want. Peripherals are implemented in the FPGA and in the host computer. The FPGA part of peripherals have the timing and logic needed to drive the four pins to each daughter card. For example, the FPGA part of the dc2 peripheral does the timing for the H-bridges that control two different DC motors. The FPGA has an internal address and data bus and each peripheral has a set of 8-bit registers which configure the peripheral. For example, the FPGA peripheral part of dc2 has an 8-bit register that set the mode (brake, coast, forward, or reverse) of the motors. Other registers set the duty cycle of the H-bridge FETs and configure the watchdog timer. The address of a peripheral is set at FPGA compile time and must match the connector where the daughter card connects.The advantage of an FPGA is that you get to choose which peripherals to include in the system. The Baseboard4 FPGA card supports up to eight user selected peripherals and daughter cards. The FPGA connects to the host computer over a USB link. It is the job of the dpserver daemon to multiplex the the commands and data to and from the logically separate peripheral registers in the FPGA. Drivers are loadable modules that provide the API between your application and the registers in the FPGA peripherals. Drivers hide the complexity and detail of the peripheral register and give your application a high-level language to control the system. The following diagram shows the relationship between daughter cards, the FPGA card, dpserver, and your application. (The FPGA card supports eight daughter cards although this diagram shows only three.) 
The API to dpserver consists of newline terminated ASCII commands over a TCP connection. If you have multiple FPGA cards you can run different instances of dpserver with each listening on a unique TCP port.
The command to write a configuration value is dpset.
The command to read a value is dpget, and the
command to start a stream of sensor data is dpcat.
We use the term resource to refer to a configuration
parameter or sensor reading. For example, the command to
set the PWM frequency to 20 KHz on the dual DC motor controller
would be: Sensor readings are reported as space separate values terminated by a newline. Values may be given as either decimal or hex depending on the peripheral. You can start a stream of sensor reading over the TCP connection using the dpcat command. To stop the stream of sensor readings just close the TCP connection. In most appliations you'll find that you have one TCP connection for each sensor stream and one more connection for sending configuration commands. One of the nice things about dpserver is that sensor streams work with select() and epoll(). That is, you don't have to poll for data yourself, the data will come to you. This feature makes it easier to build event driven applications.
Having an ASCII over TCP API lets you write your high
level application in any language. You can even use
the shell as your programming language since we've written
TCP wrappers around all of the commands. For example,
you can set the LEDs on the FPGA card by opening a TCP
connection (default is port 8887) and writing the following
down the connection:
A list of the peripherals and links to their datasheets can be found here. A list of daughter cards can be found here.
|