View Full Version : looking for a good gpio board

05-30-2014, 05:14 PM
is there something better than this:


It has 40 mega byte per second two way communication from pc to module. Module can read
whatever digital byte that show up on its gpio at the same rate.
Ethernet ok if there is a Linux api for two way communication between pc and board.
Analog to digital would be nice. The Bitwise module does not have his.
Teensy only has 1 mega byte per second, both ways, communication between pc and board.

Thanks for any help

05-30-2014, 06:20 PM
The specifications for QuickUSB say:

speeds of at least 20MB/sec with modern chipset based USB host controllers

Also, you should separate "latency" from "throughput." What is it you actually need the bandwidth for?

05-30-2014, 07:23 PM
to read a lot of skin pixels, encoder positions. and to write to power values to electric motors

05-30-2014, 10:36 PM
It has 40 mega byte per second two way communication from pc to module. Module can read
whatever digital byte that show up on its gpio at the same rate.
No, it doesn't. USB1.1/2.0 is half-duplex differential signaling, so data transmission is only one-direction at a time in bursts of packets at 12/480 megabaud. And USB does not actually achieve a sustained 12/480 megabit/second of user data because of protocol overhead. Only Isochronous endpoints have a portion of the bus' bandwidth allocated solely to that device, but even those endpoints still transmit in bursts; devices only transmit upon request from the host, and must stop transmitting to permit the host to send command/request/data packets to other devices on the bus and then wait for those device responses.

Although the transceiver in the QuickUSB's microcontroller may be able to get 96Mbit of data transmitted or received in one second by using multiple bursts at high-speed (480 Mbps), that data rate is limited to the use of the 16-bit FIFO interface with an external device (the FIFIO interface runs up to 96 Mbps). The modified 8051 core with 48MHz clock (maximum) limits the ability of the on-board processor to do much at high speeds (4 clock cycles per instruction) and the CY7C68013A reference manual confirms the high-speed transceiver is primarily for easily giving a non-USB device access to USB capabilities through the FIFO interface.

The BeagleBoneBlack might be useful, but it runs at 3.3V with a 1.8V ADC (7-channels available) and software support is not as well developed as the RaspberryPi. It also has a tendency to become sold-out quite quickly since production is not as large-scale as the RaspberryPi. It has a 1GHz ARM Cortex-A8 with 512MB RAM, lots of GPIO (only 3.3V I/O levels; 5V will kill it), USB host and device interfaces, and a 10/100 Ethernet port.

05-30-2014, 10:54 PM
You don't get good control of timing of output signals through a typical USB interface. It sounds to me as if you want to use an embedded controller that knows about sequencing and timing of the control you want to do, and then send higher-level control commands to that device and receive partially-processed data.

I'd look at some options like the Raspberry Pi, the BeagleBone Black, or the OpenCM 9.04. The RPi and BB also come with Ethernet, although at least on the RPi that's a USB device and thus has the same throughput limitations that plain USB does.

05-31-2014, 03:24 PM
Thank you for your help jwatte and ticain. I will look into Raspherry Pi, and OpenCM 9.04.
The information i needed for teensy and bitwise information and software was easy to obtain.
I will check out RPI again to see if there technology has matured.
BB and Texas Instruments stuff is a wast of time. I could never find the information i wanted. And it has only a 3 mHz gpio.
TI stuff well only work if i knew some one in my neighborhood that uses it.

Thanks again for the help,


05-31-2014, 08:12 PM
I definitely agree that support/documentation for the BBBk is still in need of improvement, but gpio is only limited to 3MHz if using ARM/linux (http://chiragnagpal.com/examples.html) instead of using the two PRU (http://elinux.org/Ti_AM33XX_PRUSSv2) (15ns cycle GPIO using PRU (http://hipstercircuits.com/pypruss-one-library-to-rule-them-all/)).

The OpenCM-904 is similar to the Teensy3.1, but uses an ARM Cortex-M3 from a different manufacturer and has only 3.3V-compatible GPIO and ADC. Using a PC with an OS is not a good idea for trying to control real-time systems like motors, and USB is even less suited because it requires the host to initiate all data transactions (so the device cannot immediately notify the host of a pin change as it must wait to be polled). Cheapest answer is: perform the real-time control/processing with an inexpensive embedded system, and then use USB/ethernet to update the PC on status and receive new commands at much slower speeds than required for the real-time system. More expensive would be using an FPGA dev-board as GPIO board to try to perform all control algorithms from a PC and hope the ethernet/USB can achieve near real-time communications between the PC and FPGA.

05-31-2014, 08:32 PM
If you want 100 MHz GPIO, try the Papilio One.

06-03-2014, 01:10 PM
I have been watching Papilio for a while. The have this new Duo Papilio board:


Papilio web page: