Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Getting GPIO out of a PC? Best way?

1,906 views
Skip to first unread message

haitic...@gmail.com

unread,
May 18, 2014, 1:33:09 PM5/18/14
to
GPIO pins, which are just digital high-low pins under SW control, are generally
the simplest output from a CPU IC. Does anyone have an opinion about the best way
to get this functionality out of a generic PC?

For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
6 gB/s. As well, cards exist for a parallel port, though not sure of speed.

Anyone have any ideas about this? High speed is appreciated. Serial best. This
'should' be easy.

jb


Lasse Langwadt Christensen

unread,
May 18, 2014, 2:38:02 PM5/18/14
to
doesn't exist, any micro controller will run circles around a PC when
it come to bit banging output pins

jumping through lots of hoops some CNC software manages to bitbang IO on a parallel port at maybe a few hundred kilohertz but that's it

-Lasse

David Brown

unread,
May 18, 2014, 4:27:01 PM5/18/14
to
The simplest method is to connect an FTDI module by USB. You can do
bitbanging with it, but speed will be a bit limited and there will be a
lot of variation in the timing. You can do better with SPI or UART from
the same sort of modules - you can get several Mbps that way.

k...@attt.bizz

unread,
May 18, 2014, 6:06:04 PM5/18/14
to
On Sun, 18 May 2014 10:33:09 -0700 (PDT), haitic...@gmail.com
wrote:
A uC with the appropriate number of PIO bits and built-in USB? If you
just need onesy-twosy, a dev board of your favorite uC should work
fine. Of course, it's going to be slow and indeterminate latency.


Martin Riddle

unread,
May 18, 2014, 7:05:38 PM5/18/14
to
On Sun, 18 May 2014 10:33:09 -0700 (PDT), haitic...@gmail.com
wrote:

If you need a few, the serial port control pins are easy to use. I
would not call them fast, and you need level translation.
A PPort card would be the best poor mans solution.

Cheers

Maynard A. Philbrook Jr.

unread,
May 18, 2014, 7:41:57 PM5/18/14
to
In article <cffb870c-a1ed-4f15...@googlegroups.com>,
haitic...@gmail.com says...
Get a Parallel printer type port? Just a thought..

Jamie

Joerg

unread,
May 18, 2014, 8:17:15 PM5/18/14
to

Spehro Pefhany

unread,
May 18, 2014, 10:33:24 PM5/18/14
to
On Sun, 18 May 2014 10:33:09 -0700 (PDT), the renowned
haitic...@gmail.com wrote:

>GPIO pins, which are just digital high-low pins under SW control, are generally
>the simplest output from a CPU IC. Does anyone have an opinion about the best way
> to get this functionality out of a generic PC?

I/O is pretty decoupled from the CPU in a modern PC.

>For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
>6 gB/s. As well, cards exist for a parallel port, though not sure of speed.
>
>Anyone have any ideas about this? High speed is appreciated. Serial best. This
>'should' be easy.
>
>jb

Since you say nothing about the speed you need, the simplest would
probably be a printer port card, or the control lines on a serial port
card. Interposing USB in the middle would probably add some additional
latencies but there's going to be plenty of latencies and jitter
anyway.

A lot will depend on what's happening in the drivers, BIOS and what
operating system you are using.

Often it's better to loosly couple a small processor (by USB or
whatever) to the PC and do high-speed stuff with that (perhaps
augmented by an FPGA).


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

Hal Murray

unread,
May 18, 2014, 11:19:07 PM5/18/14
to
In article <cffb870c-a1ed-4f15...@googlegroups.com>,
haitic...@gmail.com writes:
>GPIO pins, which are just digital high-low pins under SW control, are generally
>the simplest output from a CPU IC. Does anyone have an opinion about the best way
> to get this functionality out of a generic PC?
>
>For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
>6 gB/s. As well, cards exist for a parallel port, though not sure of speed.

I don't think they will help much unless you but a gizmo on the other end,
probably something like a FPGA or small micro.

The parallel port on USB will work, but USB is polled, so it's ballpark of
1 ms per clump. So that's 500 Hz if you are toggling a bit. Parallel ports
have a handskake mode that might let you go faster.

>Anyone have any ideas about this? High speed is appreciated. Serial best. This
>'should' be easy.

If you like Linux, look into a Raspberry PI or the various flavors of
BeagleBone. They are ARM SoC type chips with real GPIO pins running
Linux.

--
These are my opinions. I hate spam.

Przemek Klosowski

unread,
May 18, 2014, 11:49:46 PM5/18/14
to
On Sun, 18 May 2014 10:33:09 -0700, haiticare2011 wrote:

> GPIO pins, which are just digital high-low pins under SW control, are
> generally the simplest output from a CPU IC. Does anyone have an opinion
> about the best way to get this functionality out of a generic PC?
>
> For instance, a generic PC (a fast one) these days will have USB 3.0 and
> SATA 3-6 gB/s. As well, cards exist for a parallel port, though not
> sure of speed.

Well, SATA is a pretty specialized protocol, which in addition to
everything else is clocked spread-spectrum so it's not really suitable
for GPIO. Most peripherals on a modern x86 PC are pretty removed from the
CPU control, because wiggling I/O directly from a 3 GHz processor is just
not feasible; it's handled by the motherboard chipset that connects GPIO
across a series of buses, usually starting with PCI.

ARM, on the other hand, traditionally keeps the IO close to the CPU and
doesn't even have motherboard chipsets. TI ARM units, such as the AM335x
on the $45 beaglebone platform, have a pretty cool feature: the CPU is
packaged with two I/O processors called PRU. Each PRU is a 200MHz RISC 32-
bit unit, with access both to the processor bus and to the peripheral
circuits, that run autonomously, and therefore can wiggle the I/O pins at
intervals guaranteed not to be less than 50 ns. In practice, reaching
200MHz is not quite possible, but 50-100 MHz is doable.

The traditional x86 architecture is not even trying to have advanced GPIO.
Intel for instance produced an embedded small form-factor board called
Galileo, as a response to all those embedded ARM and AVR boards. It has
GPIO, but they implemented it as an I2C parallel port, with the speed
limited to 200 Hz---pretty sad.

If you are tied to x86 PC and/or Windows, your best bet would be PCI
parallel ports. Usually the speed will be in the south of 100kHz, and you
can get 8 bits of output and a similar number of input bits per each port.

Jasen Betts

unread,
May 19, 2014, 2:46:09 AM5/19/14
to
On 2014-05-18, haitic...@gmail.com <haitic...@gmail.com> wrote:
> GPIO pins, which are just digital high-low pins under SW control, are generally
> the simplest output from a CPU IC. Does anyone have an opinion about the best way
> to get this functionality out of a generic PC?

a serial port has 3 outputs and 5 inputs
else a PCI or PCIe parallell port or attach
a microcontroller somewhere.




--
umop apisdn


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

haitic...@gmail.com

unread,
May 19, 2014, 6:15:55 AM5/19/14
to
sad. A mcu is OK, but then how to connect it to PC? The reason for PC is to get SSD and high speed SW caoacity, 4 gHz cpu + SSD etc.
Any idea how to connect ARM 2 PC? Thanks for reply. b

haitic...@gmail.com

unread,
May 19, 2014, 6:18:11 AM5/19/14
to
On Sunday, May 18, 2014 6:06:04 PM UTC-4, k...@attt.bizz wrote:
> On Sun, 18 May 2014 10:33:09 -0700 (PDT), zhaitic...@gmail.com
I'm afraid the dev board is not going to have the SW dev environment. Thanks. JB

haitic...@gmail.com

unread,
May 19, 2014, 6:19:05 AM5/19/14
to
On Sunday, May 18, 2014 7:05:38 PM UTC-4, Martin Riddle wrote:
> On Sun, 18 May 2014 10:33:09 -0700 (PDT), xhaitic...@gmail.com
Thanks. Looking for something serial and faster. JB

haitic...@gmail.com

unread,
May 19, 2014, 6:20:02 AM5/19/14
to
On Sunday, May 18, 2014 7:41:57 PM UTC-4, Maynard A. Philbrook Jr. wrote:
> In article <cffb870c-a1ed-4f15...@googlegroups.com>,
>
> ahaiti...@gmail.com says...
Thanks. need faster serial line. jb

haitic...@gmail.com

unread,
May 19, 2014, 6:21:04 AM5/19/14
to
On Sunday, May 18, 2014 8:17:15 PM UTC-4, Joerg wrote:
Thanks. Seems too slow and difficult to implement. jb

haitic...@gmail.com

unread,
May 19, 2014, 6:23:27 AM5/19/14
to

>
> Often it's better to loosly couple a small processor (by USB or
>
> whatever) to the PC and do high-speed stuff with that (perhaps
>
> augmented by an FPGA).
>
>
>
> Best regards,
>
> Spehro Pefhany
>

Thanks, yes, I see that approach. But then how to interface the BBB to the PC? jb

haitic...@gmail.com

unread,
May 19, 2014, 6:25:17 AM5/19/14
to
On Sunday, May 18, 2014 11:19:07 PM UTC-4, Hal Murray wrote:

> >'should' be easy.
>
>
>
> If you like Linux, look into a Raspberry PI or the various flavors of
>
> BeagleBone. They are ARM SoC type chips with real GPIO pins running
>
> Linux.
>
>
Hal Murray

Thanks - then question becomes, how to interface to Pi or BBB board?
jb
"This is deja vu all over again." - YB

haitic...@gmail.com

unread,
May 19, 2014, 6:28:10 AM5/19/14
to

>
> ARM, on the other hand, traditionally keeps the IO close to the CPU and
>
> doesn't even have motherboard chipsets. TI ARM units, such as the AM335x
>
> on the $45 beaglebone platform, have a pretty cool feature: the CPU is
>
> packaged with two I/O processors called PRU. Each PRU is a 200MHz RISC 32-
>
> bit unit, with access both to the processor bus and to the peripheral
>
> circuits, that run autonomously, and therefore can wiggle the I/O pins at
>
> intervals guaranteed not to be less than 50 ns. In practice, reaching
>
> 200MHz is not quite possible, but 50-100 MHz is doable.
>
>
>
> The traditional x86 architecture is not even trying to have advanced GPIO.
>
> Intel for instance produced an embedded small form-factor board called
>
> Galileo, as a response to all those embedded ARM and AVR boards. It has
>
> GPIO, but they implemented it as an I2C parallel port, with the speed
>
> limited to 200 Hz---pretty sad.
>
>
>
> If you are tied to x86 PC and/or Windows, your best bet would be PCI
>
> parallel ports. Usually the speed will be in the south of 100kHz, and you
>
> can get 8 bits of output and a similar number of input bits per each port.

Yes, thanks, I have seen that PRU feature o the BBB, but it's lacking a
compiler now - But overall problem is "How to connect PC to the BBB/Pi board?"
jb
"If you see a fork in the road, take it." - YB

Martin Brown

unread,
May 19, 2014, 6:29:17 AM5/19/14
to
On 19/05/2014 11:18, haitic...@gmail.com wrote:
> On Sunday, May 18, 2014 6:06:04 PM UTC-4, k...@attt.bizz wrote:
>> On Sun, 18 May 2014 10:33:09 -0700 (PDT), zhaitic...@gmail.com
>>
>> wrote:
>>
>>> GPIO pins, which are just digital high-low pins under SW control, are generally
>>> the simplest output from a CPU IC. Does anyone have an opinion about the best way
>>> to get this functionality out of a generic PC?
>>
>>> For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
>>> 6 gB/s. As well, cards exist for a parallel port, though not sure of speed.
>>
>>> Anyone have any ideas about this? High speed is appreciated. Serial best. This
>>> 'should' be easy.

You don't say how fast you need it or how many channels. You can buy
various IO cards for industrial kit for a price but they are a minority
interest and can easily cost more than a generic PC.

>>
>> A uC with the appropriate number of PIO bits and built-in USB? If you
>>
>> just need onesy-twosy, a dev board of your favorite uC should work
>>
>> fine. Of course, it's going to be slow and indeterminate latency.
>
> I'm afraid the dev board is not going to have the SW dev environment. Thanks. JB

STM32M4 Discovery or similar will do it and behave as a USB device for
about �20 or $30. There is a choice of development environments for it.
Learning curve on the ARM CortexM4 is a bit steep at first.

If you described the bandwidth you wanted you might get better answers.

--
Regards,
Martin Brown

haitic...@gmail.com

unread,
May 19, 2014, 6:30:12 AM5/19/14
to
On Monday, May 19, 2014 2:46:09 AM UTC-4, Jasen Betts wrote:
Thanks Attaching the MCU, how? jb

"This is deja u all over again." YB

haitic...@gmail.com

unread,
May 19, 2014, 6:32:07 AM5/19/14
to
On Sunday, May 18, 2014 2:38:02 PM UTC-4, Lasse Langwadt Christensen wrote:
At this point, I am looking for a SPI type fast serial line at fairly high
speeds > serial port. JB

haitic...@gmail.com

unread,
May 19, 2014, 6:32:48 AM5/19/14
to
On Sunday, May 18, 2014 4:27:01 PM UTC-4, David Brown wrote:
SPI from a USB 3.0? Does it exist? Thanks jb

David Brown

unread,
May 19, 2014, 6:36:57 AM5/19/14
to
On 19/05/14 12:32, haitic...@gmail.com wrote:
> On Sunday, May 18, 2014 2:38:02 PM UTC-4, Lasse Langwadt Christensen
> wrote:
>> Den s�ndag den 18. maj 2014 19.33.09 UTC+2 skrev
Use an FTDI module, as I said before. They support fast SPI, connected
to the PC by USB. I've used them for programming SPI flash chips at a
rate of 100+ KBps.

And for connecting your microcontroller to the PC, the easiest way is to
use the serial port (UART) on the microcontroller connect to - wait for
it - an FTDI module. UART speeds of 2 or 3 Mbaud should be fine, if the
microcontroller is fast enough.

Clifford Heath

unread,
May 19, 2014, 7:59:59 AM5/19/14
to
On 19/05/14 20:32, haitic...@gmail.com wrote:
> SPI from a USB 3.0? Does it exist? Thanks jb

Not USB3 (only 2) but look at the FT221X. I have a couple here and
designed a PCB, but haven't yet got organised to build it yet.

haitic...@gmail.com

unread,
May 19, 2014, 8:08:16 AM5/19/14
to
On Monday, May 19, 2014 7:59:59 AM UTC-4, Clifford Heath wrote:
> On 19/05/14 20:32, haiti1c...@gmail.com wrote:
>
> > SPI from a USB 3.0? Does it exist? Thanks jb
>
>
>
> Not USB3 (only 2) but look at the FT221X. I have a couple here and
>
> designed a PCB, but haven't yet got organised to build it yet.

OK. Now look at www.diolan.com DLN-4M board for USB 2 SPI. Waddya think?
jb

haitic...@gmail.com

unread,
May 19, 2014, 8:11:33 AM5/19/14
to
On Sunday, May 18, 2014 1:33:09 PM UTC-4, haitic...@gmail.com wrote:

at risk of boring everyone to death, I reposted the GPIO as an SPI need. (GPIO
always appreciated as add on, of course.)

================

Thank you all for your thoughts on this. I want to clarify my question, since the
issue has become more focused, as I see it.

What I'm looking for s a high speed USB to SPI interface. Thw question becomes:
"How much latency is there in USB 3.0? " Some posters have said USB has a great
deal of latency, which is disturbing.

But if that's not a problem, the high speed boards from www.diolan.com - the
DLN-4M as I recall, does USB 2 SPI at 480 mHz they say.

The reason I am interested in this capability is the following: The PC platform
enjoys high speed engineering design due to a huge market for gamers and general
PC speed requirements. Software-wise, the OSes running on the PC have garnered
the most attention, so compilers, etc. are most advanced there. In sum:
-SSD storage over SATA 3; 6 gB/s. SSD is 10,000x faster than HD.
-4 gHz cpu + up to 32 gB DDR3 RAM
-USB 3.0 fast transfer.
-software platforms mentioned.

So it makes sense to have the "center-of-gravity" near the PC platform. Then the
focus moves to how to interface HW to the PC for fast transfer. The USB 3
interface seems the main serial channel to do this, so naturally I ended looking
at USB 2 SPI interfaces like the www.diolan.com boards.

Any thoughts appreciated.


JB

Spehro Pefhany

unread,
May 19, 2014, 8:19:39 AM5/19/14
to
On Mon, 19 May 2014 03:23:27 -0700 (PDT), the renowned
haitic...@gmail.com wrote:

>
>Thanks, yes, I see that approach. But then how to interface the BBB to the PC? jb

One of the USB modes might work for you. Look at the Labjack devices
for an example.

Clifford Heath

unread,
May 19, 2014, 8:54:20 AM5/19/14
to
If you want to work with someone else's software of unknown quality, and
think it'll save you the extra $$, go for it. Otherwise you can get
almost the exact same hardware functionality from the $15
STM32F4Discovery, as you've already been told (though I think David left
out a letter in the board name). If all you want is SPI to integrate
onto another board, the FT221X might work.

Reinhardt Behm

unread,
May 19, 2014, 10:56:21 AM5/19/14
to
The BBB has an 100Mbit/s Ethernet port. You can also use it's USB port as an
emulated Ethernet.

David Brown

unread,
May 19, 2014, 11:27:33 AM5/19/14
to
No, I didn't mean getting a particular STM board. I meant he should get
an FTDI module, such as the FT4232H from this page:

<http://www.ftdichip.com/Products/Modules/DevelopmentModules.htm>

I hadn't bothered giving links, because I had assumed the OP was capable
of using google to find FTDI's website and then clicking on "products"
and "modules" all by himself.

Following that link gives many other modules, including ones with an
FPGA on board, if the OP wants to go that route. There is little point
in going for an FT221x - that range is primarily aimed at smaller,
cheaper and fewer external components than the FT4232H chip, which does
not matter when you are using a ready-made module.


Regarding USB3, it is pointless. USB2 is more than enough - if you
think you USB3 is the answer to anything other than a harddrive, then
you have asked the wrong question.

Until the OP gives some relevant information about the application, I
don't think there is any point in speculating about a microcontroller -
that just adds more complications that are hopefully not necessary.

So I would get an FT4232H board and start from there. They are easy to
get hold of, and there is lots of support for controlling them both from
FTDI and third parties.

sms

unread,
May 19, 2014, 5:05:18 PM5/19/14
to
On 5/18/2014 10:33 AM, haitic...@gmail.com wrote:
> GPIO pins, which are just digital high-low pins under SW control, are generally
> the simplest output from a CPU IC. Does anyone have an opinion about the best way
> to get this functionality out of a generic PC?
>
> For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
> 6 gB/s. As well, cards exist for a parallel port, though not sure of speed.
>
> Anyone have any ideas about this? High speed is appreciated. Serial best. This
> 'should' be easy.

You can buy a board such as <http://www.icpdas-usa.com/pex_d24.html> if
you need high speed.

For lower speed, buy
<http://www.newegg.com/Product/Product.aspx?Item=N82E16815166031>.

For USB use <http://numato.com/16-channel-usb-gpio-module> or something
similar.




haitic...@gmail.com

unread,
May 19, 2014, 6:47:18 PM5/19/14
to
Say thanks that's great - much appreciated. Have you used any ftdi chips, etc.
to do anything?
More later...jb

haitic...@gmail.com

unread,
May 19, 2014, 6:47:59 PM5/19/14
to
Thanks I will look at asap. JB

josephkk

unread,
May 19, 2014, 10:51:32 PM5/19/14
to
On Sun, 18 May 2014 10:33:09 -0700 (PDT), haitic...@gmail.com wrote:

>GPIO pins, which are just digital high-low pins under SW control, are generally
>the simplest output from a CPU IC. Does anyone have an opinion about the best way
> to get this functionality out of a generic PC?
>
>For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
>6 gB/s. As well, cards exist for a parallel port, though not sure of speed.

Make that Gb/s. (about a 10:1 lower value).
>
>Anyone have any ideas about this? High speed is appreciated. Serial best. This
>'should' be easy.
>
>jb
>

What total transport rate do you want? Can the mainboard handle the DMA
rate? Is the DRAM interface fast enough?

?-)

David Brown

unread,
May 20, 2014, 3:20:31 AM5/20/14
to
We use them regularly as USB-to-UART chips on many of our boards. In
the good old days, an embedded microcontroller card would often have an
RS-232 port for communicating with a PC (to provide a user-friendly
interface after installation, or in use during setup, testing, etc.).
The modern version is an FTDI chip and a USB connection. By using the
FTDI chip, you avoid all complications normally associated with USB -
drivers, setup at the microcontroller end, complicated software at each
end, etc. It just becomes simple and easy UART communication - but
faster than the limits of RS-232. There are FTDI drivers for all
versions of Windows, and Linux has supported them for many years in the
kernel. It is therefore simpler to use than USB ports built into a
microcontroller.

We also use FTDI modules such as the FT4232H with its SPI port for
programming SPI bus flash on cards. I've used the FT2232B to make a
debugger for a Coldfire chip, and most ARM JTAG dongles consist of an
FTDI chip and some buffers.

And I have also used an FT4232H module as a GPIO module with some
switches and LEDs.

I usually use the "pyftdi" library for controlling these using Python,
but I have also used Delphi, and you can get interface libraries for
pretty much any language you want to use.


haitic...@gmail.com

unread,
May 20, 2014, 1:15:24 PM5/20/14
to
On Tuesday, May 20, 2014 3:20:31 AM UTC-4, David Brown wrote:
excellent. Thanks. I am interested in interfacing an ADC chip ti ads8344, to a
PC.
Yes, I know I could use something much slower, even a Labjack, but I am
contemplating some projects to do seti-like information gorging. The ads8344 likes a SPI-like signal to strobe it on and collect the result. The chips can be daisy-chained.
I was experimenting with a microchip cpu "intelligent analog" which boasts very
high ADC rates, but the idea to jump into a particular architecture because it
does ADC fast is putting the cart before horse, imo.

The pointer to use pyftdi is appreciated - I plan to do the project in Python.

I wonder which OS you are running? Windows 7 / Linux?

Also, I noted the USB driver for the ft4232h configures the unit as 4 virtual
com ports - But they also said the driver can access the chip directly
(afaiui).
If that's so, how do you handle that?

Thanks again for pertinent info.

JB




haitic...@gmail.com

unread,
May 20, 2014, 1:18:32 PM5/20/14
to
On Monday, May 19, 2014 10:51:32 PM UTC-4, josephkk wrote:
sorry for delay. :)
Yes, I'd say dram fast enough. I just want all the capacity I can easily get,
since I plant to scan a number of inputs, in an open 'seti-like' fashion.
What have you got up your sleeve?
jb

haitic...@gmail.com

unread,
May 20, 2014, 1:21:52 PM5/20/14
to
On Monday, May 19, 2014 5:05:18 PM UTC-4, sms wrote:
Thanks for that. I'm thinking of Dave Brown's solution, but this looks good.
jb

Hal Murray

unread,
May 20, 2014, 1:53:49 PM5/20/14
to
In article <1a835249-57bc-402e...@googlegroups.com>,
haitic...@gmail.com writes:

>Thanks - then question becomes, how to interface to Pi or BBB board?

You are missing the big picture. The Pi and BBB run Linux. You run
your code directly on them rather than on the PC.

--
These are my opinions. I hate spam.

David Brown

unread,
May 20, 2014, 3:44:14 PM5/20/14
to
(You really should get yourself a newsreader and a newsserver instead of
that crap Google Groups interface that always messes up quotations.)

> excellent. Thanks. I am interested in interfacing an ADC chip ti
> ads8344, to a PC. Yes, I know I could use something much slower,
> even a Labjack, but I am contemplating some projects to do seti-like
> information gorging. The ads8344 likes a SPI-like signal to strobe
> it on and collect the result. The chips can be daisy-chained. I was
> experimenting with a microchip cpu "intelligent analog" which boasts
> very high ADC rates, but the idea to jump into a particular
> architecture because it does ADC fast is putting the cart before
> horse, imo.

Avoid Microchip's microcontrollers if you can. They come in big
packages, which can be nice if you are making a board in your cellar,
but the PIC cpu is hideous (it competes with the 8051 for the worst cpu
ever to become popular). Their non-microcontroller parts are usually good.

The ADS8344 will do a fine job, run with the internal clock (to save you
having an external one). Forget the "busy" signal, it would just
complicate matters. Don't daisy-chain them - they cannot easily
daisy-chain. Instead, connect the devices mostly in parallel but with
separate chip selects to individual IO's on the FTDI device.

>
> The pointer to use pyftdi is appreciated - I plan to do the project
> in Python.
>
> I wonder which OS you are running? Windows 7 / Linux?

Mostly Linux, some Windows (I have an old XP machine, but the end result
usually has to run on XP and Win7). I do most of the development on
Linux, however.

>
> Also, I noted the USB driver for the ft4232h configures the unit as
> 4 virtual com ports - But they also said the driver can access the
> chip directly (afaiui). If that's so, how do you handle that?

You can choose yourself how to configure the chip. By default, it
registers as 4 virtual comms ports, but you can access it with the
library code from FTDI and override the modes. The application notes
from FTDI about using the chip for SPI are definitely worth reading,
even if you use pyftdi instead of FTDI's own libraries.

haitic...@gmail.com

unread,
May 20, 2014, 4:20:49 PM5/20/14
to
On Tuesday, May 20, 2014 1:53:49 PM UTC-4, Hal Murray wrote:
> In article <1a835249-57bc-402e...@googlegroups.com>,
>
> haitics...@gmail.com writes:
>
>
>
> >Thanks - then question becomes, how to interface to Pi or BBB board?
>
>
>
> You are missing the big picture. The Pi and BBB run Linux. You run
>
> your code directly on them rather than on the PC.
>
>
>
> --
>
> These are my opinions. I hate spam.

Thanks Hal, I've rejected that option, since the PC is so much faster.
jb

haitic...@gmail.com

unread,
May 20, 2014, 4:36:46 PM5/20/14
to
On Tuesday, May 20, 2014 3:44:14 PM UTC-4, David Brown wrote:

Say David
Thanks again. Yes, Google groups is hideous. I'll work on T-bird.

Tell me what you think of the pci card that "sms" mentions in this thread? Can
you
compare it?

Thanks in advance. Your advisement on separate pin-outs for ADC appreciated.
JB

-I wonder if I can get a refund on microchip board I bought when dazzled by the
big lights. :)

David Brown

unread,
May 20, 2014, 6:22:23 PM5/20/14
to
On 20/05/14 22:36, haitic...@gmail.com wrote:
> On Tuesday, May 20, 2014 3:44:14 PM UTC-4, David Brown wrote:
>
> Say David Thanks again. Yes, Google groups is hideous. I'll work on
> T-bird.

Thunderbird with news.eternal-september.org is free, and works well.

>
> Tell me what you think of the pci card that "sms" mentions in this
> thread? Can you compare it?
>

If you need the fastest speeds and lowest latencies, then an internal
PCI card is a possibility - it will be high speed, and have direct DMA
access to memory. But if you can avoid that, do so - PCI cards are much
higher risk (if something goes wrong, you can mess up your PC), and a
lot more fuss for drivers and so on. If it matters in your application,
they are also harder to change if something goes wrong, and replacement
parts or similar alternatives are going to be difficult to find in the
future. And inside a PC is the worst place to do any ADC measurements -
it is too electrically noisy.

Thunderbolt, the new fast serial link found in some PC's, is more
interesting - it is effectively PCI Express over an external cable.
That negates many of the disadvantages of an ordinary PCI Express card.
The only problems are that you probably can't find any Thunderbolt
connected ADC cards, and your PC probably doesn't have a Thunderbolt
interface.

David Brown

unread,
May 20, 2014, 6:29:48 PM5/20/14
to
Faster for what purpose? The Pi and the BBB are pretty fast - they
match a mainstream PC from only a few years ago. And there are
alternative embedded Linux boards that are faster, if that's really needed.

But you need to think about what you actually want to do here. You
don't want something "as fast as possible", or "as fast as a PC" - you
want something "as fast as needed for the job at hand". And certainly
if an FTDI USB-to-SPI board is fast enough to get the data in, then the
Pi or the BBB is probably fast enough to handle the data.
Alternatively, it might form part of the solution - collecting the data
then passing it on over the network to a bigger PC.

mike

unread,
May 20, 2014, 6:54:45 PM5/20/14
to
On 5/20/2014 3:29 PM, David Brown wrote:
> On 20/05/14 22:20, haitic...@gmail.com wrote:
>> On Tuesday, May 20, 2014 1:53:49 PM UTC-4, Hal Murray wrote:
>>> In article <1a835249-57bc-402e...@googlegroups.com>,
>>>
>>> haitics...@gmail.com writes:
>>>
>>>
>>>
>>>> Thanks - then question becomes, how to interface to Pi or BBB board?
>>>
>>>
>>>
>>> You are missing the big picture. The Pi and BBB run Linux. You run
>>>
>>> your code directly on them rather than on the PC.
>>>
>>>
>>>
>>> --
>>>
>>> These are my opinions. I hate spam.
>>
>> Thanks Hal, I've rejected that option, since the PC is so much faster.
>> jb
>>
>
> Faster for what purpose? The Pi and the BBB are pretty fast - they
> match a mainstream PC from only a few years ago. And there are
> alternative embedded Linux boards that are faster, if that's really needed.
>
> But you need to think about what you actually want to do here. You
> don't want something "as fast as possible", or "as fast as a PC" - you
> want something "as fast as needed for the job at hand".


YEP, that's the crux of the matter. I've read all the thread and don't
remember
ever seeing what he's trying to do or why.
"Fast as possible" is NOT a specification nor goal nor anything useful.
Making one for your use is a lot different from making them by the
thousand for resale.
A general purpose solution is always more difficult/costly than
one designed for a specific purpose.
Sometimes, a general purpose PC is not the optimal solution.

k...@attt.bizz

unread,
May 20, 2014, 8:06:51 PM5/20/14
to
On Mon, 19 May 2014 03:15:55 -0700 (PDT), haitic...@gmail.com
wrote:

>On Sunday, May 18, 2014 2:38:02 PM UTC-4, Lasse Langwadt Christensen wrote:
>> Den s�ndag den 18. maj 2014 19.33.09 UTC+2 skrev haitic...@gmail.com:
>>
>> > GPIO pins, which are just digital high-low pins under SW control, are generally
>>
>> >
>>
>> > the simplest output from a CPU IC. Does anyone have an opinion about the best way
>>
>> >
>>
>> > to get this functionality out of a generic PC?
>>
>> >
>>
>> >
>>
>> >
>>
>> > For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
>>
>> >
>>
>> > 6 gB/s. As well, cards exist for a parallel port, though not sure of speed.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Anyone have any ideas about this? High speed is appreciated. Serial best. This
>>
>> >
>>
>> > 'should' be easy.
>>
>> >
>>
>> >
>>
>> >
>>
>> > jb
>>
>>
>>
>> doesn't exist, any micro controller will run circles around a PC when
>>
>> it come to bit banging output pins
>>
>>
>>
>> jumping through lots of hoops some CNC software manages to bitbang IO on a parallel port at maybe a few hundred kilohertz but that's it
>>
>>
>>
>> -Lasse
>
>sad. A mcu is OK, but then how to connect it to PC? The reason for PC is to get SSD and high speed SW caoacity, 4 gHz cpu + SSD etc.
>Any idea how to connect ARM 2 PC? Thanks for reply. b

USB. Pick your speed.

k...@attt.bizz

unread,
May 20, 2014, 8:09:16 PM5/20/14
to
On Mon, 19 May 2014 03:32:48 -0700 (PDT), haitic...@gmail.com
wrote:
Sure, in any number of forms from bare uC chips, to development
boards, to something like an Aardvark. There are many, many, options.

k...@attt.bizz

unread,
May 20, 2014, 8:10:29 PM5/20/14
to
On Mon, 19 May 2014 03:18:11 -0700 (PDT), haitic...@gmail.com
wrote:

>On Sunday, May 18, 2014 6:06:04 PM UTC-4, k...@attt.bizz wrote:
>> On Sun, 18 May 2014 10:33:09 -0700 (PDT), zhaitic...@gmail.com
>>
>> wrote:
>>
>>
>>
>> >GPIO pins, which are just digital high-low pins under SW control, are generally
>>
>> >the simplest output from a CPU IC. Does anyone have an opinion about the best way
>>
>> > to get this functionality out of a generic PC?
>>
>> >
>>
>> >For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
>>
>> >6 gB/s. As well, cards exist for a parallel port, though not sure of speed.
>>
>> >
>>
>> >Anyone have any ideas about this? High speed is appreciated. Serial best. This
>>
>> >'should' be easy.
>>
>>
>>
>> A uC with the appropriate number of PIO bits and built-in USB? If you
>>
>> just need onesy-twosy, a dev board of your favorite uC should work
>>
>> fine. Of course, it's going to be slow and indeterminate latency.
>
>I'm afraid the dev board is not going to have the SW dev environment. Thanks. JB

Huh? That's what they're *for*.

josephkk

unread,
May 20, 2014, 10:50:55 PM5/20/14
to
On Tue, 20 May 2014 10:18:32 -0700 (PDT), haitic...@gmail.com wrote:

>
>> Make that Gb/s. (about a 10:1 lower value).
>>
>> >
>>
>> >Anyone have any ideas about this? High speed is appreciated. Serial best. This
>>
>> >'should' be easy.
>>
>> >
>>
>> >jb
>>
>> >
>>
>>
>>
>> What total transport rate do you want? Can the mainboard handle the DMA
>>
>> rate? Is the DRAM interface fast enough?
>>
>>
>>
>> ?-)
>
>sorry for delay. :)
>Yes, I'd say dram fast enough. I just want all the capacity I can easily get,
>since I plant to scan a number of inputs, in an open 'seti-like' fashion.
>What have you got up your sleeve?
>jb

I can't put an appropriate shirt on yet. Way too little info. What is
the immediate input and what is the total input? ADC, lots of individual
data lines, fast parallel bus, fast serial bus, lots of fast ADC or DAC,
complex instrumentation, fast protocol analyzer, digital SA, DSO, what?

The more information you provide the more appropriate clothes i can put on
to have something my sleeve with.

?-)

haitic...@gmail.com

unread,
May 21, 2014, 11:14:59 AM5/21/14
to
On Tuesday, May 20, 2014 6:29:48 PM UTC-4, David Brown wrote:

> > Thanks Hal, I've rejected that option, since the PC is so much faster.
>
> > jb
>
> >
>
>
>
> Faster for what purpose? The Pi and the BBB are pretty fast - they
>
> match a mainstream PC from only a few years ago. And there are
>
> alternative embedded Linux boards that are faster, if that's really needed.
@@@@@@@@@
Faster is desirable for what I do - run pattern recognizers constantly.
Training neural nets can take quite a bit of time.
Another rason for the speed is to run Python-type languages which are higher
level and slower. I've spent WAY too much time coding ASM and C. :)

On the front end, I like to have the speed for fast ADC on a multitude of
sensors, like photodiodes. This is open-ended.

Let me describe an historical event and ask you a question: The IBM PC-AT ran
at 5 mHz, because that was all it took, speed-wise, to run simple spread sheets
and text editors. How could you possibly want any more speed? So do you think,
in an open-ended design, you should limit yourself to only the apps you have
now? With the current gamer PC's, imo putting a Labjack on them is like hooking
a child's red wagon to a Porsche.

In the history of science, instruments and theories tend to leap-frog each other in ways not predictable. When the microscope was invented, they thought life arose by spontaneous generation.

And I'm assuming the extra work to get (fairly) high speed IO here is not going
to be a year.

jb

PS - actually I want a hot rod to play with. :) Ssy David, I'm looking for that app note about SPI. ?

rickman

unread,
May 21, 2014, 2:15:55 PM5/21/14
to
Dude, you really need to learn some things about embedded systems.

--

Rick

haitic...@gmail.com

unread,
May 22, 2014, 9:04:32 AM5/22/14
to
On Wednesday, May 21, 2014 2:15:55 PM UTC-4, rickman wrote:
And you need to learn something about software development. Sure, you
can run emulators that mimic the dev board, but SW tools on the PC platform are
much faster and better than what's on a dev board. In my case, I train
statistical recognizers, and that aint gonna happen in an embedded system,
though the results might go there.

haitic...@gmail.com

unread,
May 22, 2014, 9:17:02 AM5/22/14
to
David Brown
>
> want something "as fast as needed for the job at hand". And certainly
>
> if an FTDI USB-to-SPI board is fast enough to get the data in, then the
>
> Pi or the BBB is probably fast enough to handle the data.
>
> Alternatively, it might form part of the solution - collecting the data
>
> then passing it on over the network to a bigger PC.

Yes, you can get your GPIO on the BBB, but then you have the problem of getting
the data over to the PC in a RT fashion. And suddenly you are programming on
two different platforms, talking with each other, not to mention the physical
compatibilities.
Rather than passing the data through several sets of hands, I'd like to grab
the data directly as possible into the PC program that is running on a
platform 500X faster than a BBB or Pi. particularly since the PC is doing
things which the BBB can't.
Unless the Pi can somehow make things much easier, a distributed system doesn't
make sense, to me.
thanks
jb

upsid...@downunder.com

unread,
May 22, 2014, 9:36:37 AM5/22/14
to
On Sun, 18 May 2014 10:33:09 -0700 (PDT), haitic...@gmail.com
wrote:

>GPIO pins, which are just digital high-low pins under SW control, are generally
>the simplest output from a CPU IC. Does anyone have an opinion about the best way
> to get this functionality out of a generic PC?
>
>For instance, a generic PC (a fast one) these days will have USB 3.0 and SATA 3 -
>6 gB/s. As well, cards exist for a parallel port, though not sure of speed.
>
>Anyone have any ideas about this? High speed is appreciated. Serial best. This
>'should' be easy.

While a PC with a huge computational power is ideal for sending or
receiving a huge amount of data in _one_ direction, it is a lousy
platform for handling anything full duplex or even semi-half duplex
style request/response transactions, it is far too clumsy for doing
this.

With some big OS (such as Windows/Linux) you should expect a few
millisecond latencies for any user mode applications even if well
designed. Writing a kernel mode device driver and you are in the
microsecond ballpark. However, interrupting some big (x86 style) core
means a lot flushing of the processor pipeline and thus a big loss of
performance.

If you need to do some bit level (sub microsecond) request/response
functions, do not even think of inserting a PC into that loop :-).

haitic...@gmail.com

unread,
May 22, 2014, 1:37:38 PM5/22/14
to
On Thursday, May 22, 2014 9:36:37 AM UTC-4, upsid...@downunder.com wrote:
> On Sun, 18 May 2014 10:33:09 -0700 (PDT), thaitai...@gmail.com
So how would you do it? I am currently figuring on using
a FTDI USB dev board - ?
tia
JB

rickman

unread,
May 22, 2014, 1:51:51 PM5/22/14
to
On 5/22/2014 9:04 AM, haitic...@gmail.com wrote:
> On Wednesday, May 21, 2014 2:15:55 PM UTC-4, rickman wrote:
>> On 5/19/2014 6:18 AM, haiticw...@gmail.com wrote:
>>
>>> On Sunday, May 18, 2014 6:06:04 PM UTC-4, k...@attt.bizz wrote:
>>
>>>>
>>
>>>> A uC with the appropriate number of PIO bits and built-in USB? If you
>>>> just need onesy-twosy, a dev board of your favorite uC should work
>>>> fine. Of course, it's going to be slow and indeterminate latency.
>>
>>> I'm afraid the dev board is not going to have the SW dev environment. Thanks. JB
>>
>> Dude, you really need to learn some things about embedded systems.
>>
>> Rick
>
> And you need to learn something about software development. Sure, you
> can run emulators that mimic the dev board, but SW tools on the PC platform are
> much faster and better than what's on a dev board. In my case, I train
> statistical recognizers, and that aint gonna happen in an embedded system,
> though the results might go there.

What is your point? Who said you had to run tools on an embedded target
or run simulators (which is what they are called when you "mimic" the
target)? Like I said, you need to learn about developing embedded
systems. You might try comp.arch.embedded

--

Rick

sms

unread,
May 22, 2014, 3:52:25 PM5/22/14
to
As long as you can accept the latencies inherent in this scheme and
aren't trying to do anything real-time.

If you want to do it right, and cheap, use mbed <https://mbed.org/>
(free) with a $10 (plus tax & shipping) Nucleo board (Google
511-NUCLEO-F401RE).

There's a very low learning curve to use these boards and you do the
code from your PC.

The best way to do all this from a PC is probably with a PCIe GPIO board.

Martin Brown

unread,
May 22, 2014, 4:15:55 PM5/22/14
to
On 22/05/2014 14:04, haitic...@gmail.com wrote:
> On Wednesday, May 21, 2014 2:15:55 PM UTC-4, rickman wrote:
>> On 5/19/2014 6:18 AM, haiticw...@gmail.com wrote:
>>
>>> On Sunday, May 18, 2014 6:06:04 PM UTC-4, k...@attt.bizz wrote:
>>
>>>>
>>
>>>> A uC with the appropriate number of PIO bits and built-in USB? If you
>>>> just need onesy-twosy, a dev board of your favorite uC should work
>>>> fine. Of course, it's going to be slow and indeterminate latency.
>>
>>> I'm afraid the dev board is not going to have the SW dev environment. Thanks. JB
>>
>> Dude, you really need to learn some things about embedded systems.
>
> And you need to learn something about software development. Sure, you
> can run emulators that mimic the dev board, but SW tools on the PC platform are
> much faster and better than what's on a dev board. In my case, I train

The *tools* are almost invariably all on the PC platform but they can
tether an embedded CPU over (in the very old days RS232 or today USB or
ethernet) and run it with breakpoints, stepping or flat out.

> statistical recognizers, and that aint gonna happen in an embedded system,
> though the results might go there.

Why not? You can get some pretty fast embedded processors these days.

Decide how much IO you need and how fast and then you can decide on the
hardware to get it for minimum cost. For a one off the STM32 Discovery
range is hard to beat at about �20 for a lot of CPU and IO pins.

--
Regards,
Martin Brown

haitic...@gmail.com

unread,
May 22, 2014, 4:55:25 PM5/22/14
to
On Thursday, May 22, 2014 4:15:55 PM UTC-4, Martin Brown wrote:
> On 22/05/2014 14:04, haitxic...@gmail.com wrote:
> x
> > On Wednesday, May 21, 2014 2:15:55 PM UTC-4, rickman wrote:
>
> >> On 5/19/2014 6:18 AM, haiticcw...@gmail.com wrote:
>
> >>
>
> >>> On Sunday, May 18, 2014 6:06:04 PM UTC-4, k...@attt.bizz wrote:
>
> >>
>
> >>>>
>
> >>
>
> >>>> A uC with the appropriate number of PIO bits and built-in USB? If you
>
> >>>> just need onesy-twosy, a dev board of your favorite uC should work
>
> >>>> fine. Of course, it's going to be slow and indeterminate latency.
>
> >>
>
> >>> I'm afraid the dev board is not going to have the SW dev environment. Thanks. JB
>
> >>
>
> >> Dude, you really need to learn some things about embedded systems.
>
> >
>
> > And you need to learn something about software development. Sure, you
>
> > can run emulators that mimic the dev board, but SW tools on the PC platform are
>
> > much faster and better than what's on a dev board. In my case, I train
>
>
>
> The *tools* are almost invariably all on the PC platform but they can
>
> tether an embedded CPU over (in the very old days RS232 or today USB or
>
> ethernet) and run it with breakpoints, stepping or flat out.
>
>
>
> > statistical recognizers, and that aint gonna happen in an embedded system,
>
> > though the results might go there.
>
>
>
> Why not? You can get some pretty fast embedded processors these days.
>
>
>
> Decide how much IO you need and how fast and then you can decide on the
>
> hardware to get it for minimum cost. For a one off the STM32 Discovery
>
> range is hard to beat at about �20 for a lot of CPU and IO pins.
>
>
>
> --
>
> Regards,
>
> Martin Brown

OK thanks - any idea how to move data from the stm board to memory, like an SSD
in a RT way? I wonder if a SSD on a usb 2 would be fast enough?
jb

josephkk

unread,
May 22, 2014, 8:52:39 PM5/22/14
to
You just may end up using an PRi or BBB or maybe that zync thing anyway,
because you cannot do realtime on a PC. The busses aren't designed to
support that. Processor speed is just one factor for realtime, and not
often a dominant one.

?-)

rickman

unread,
May 23, 2014, 12:27:58 AM5/23/14
to
On 5/22/2014 4:55 PM, haitic...@gmail.com wrote:
>
> OK thanks - any idea how to move data from the stm board to memory, like an SSD
> in a RT way? I wonder if a SSD on a usb 2 would be fast enough?
> jb

You should keep in mind that the mass storage does not need to work in
"real time". It only needs to keep up with an average throughput as
long as you have enough buffer RAM in the system.

BTW, what was your sample rate and bit width again? I can't seem to
find that post. I seem to recall that you are sampling more than one
channel, no? Will all of this be moving over the same SPI bus? SPI
typically runs at about 10 Mbps. Will your CPU need to control multiple
SPI ports?

--

Rick

sms

unread,
May 23, 2014, 10:44:17 AM5/23/14
to
On 5/22/2014 5:52 PM, josephkk wrote:

> You just may end up using an PRi or BBB or maybe that zync thing anyway,
> because you cannot do realtime on a PC. The busses aren't designed to
> support that. Processor speed is just one factor for realtime, and not
> often a dominant one.

IF he uses a USB to FTDI board he's using an embedded system anyway. It
sounds like real-time is not an issue here.

When I tried using a USB Labjack for GPIO it worked but the latency was
too high and the speeds were too low. A Pi was much cheaper and much faster.



Przemek Klosowski

unread,
May 24, 2014, 12:45:34 PM5/24/14
to
On Mon, 19 May 2014 03:28:10 -0700, haiticare2011 wrote:

> Yes, thanks, I have seen that PRU feature o the BBB, but it's lacking a
> compiler now - But overall problem is "How to connect PC to the BBB/Pi
> board?"

No, it's not lacking: there are two, actually. TI has one and someone
ported GCC to PRU:

http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm
https://github.com/dinuxbg/gnupru

As for connecting BBB to PC, collect a buffer on BBB and send it over via
USB or Ethernet? What bandwidth do you need?

natewes...@gmail.com

unread,
Jun 13, 2020, 10:35:06 PM6/13/20
to
Only six years late, but I too was looking for something like what you described, and I found this.

https://www.adafruit.com/product/2264

Jan Panteltje

unread,
Jun 14, 2020, 3:49:31 AM6/14/20
to
On a sunny day (Sat, 13 Jun 2020 19:35:02 -0700 (PDT)) it happened
natewes...@gmail.com wrote in
<c4a8b8e7-68cc-4257...@googlegroups.com>:

>Only six years late, but I too was looking for something like what you described, and I found this.
>
>https://www.adafruit.com/product/2264

To get I/O from my more modern PCs I have cheap parport cards
I used those I/O for example to program PICs
and test i2c and spi chips.

Something like this:
https://www.ebay.com/itm/141973277356




Don Kuenz

unread,
Jun 14, 2020, 12:01:31 PM6/14/20
to
Interesting. Here's some Linux data on the card. Its WCH382 datasheet's
apparently only available in Chinese.

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WCH

Presumably you connect GPIO to P3 and P4, while U4 and U5 remain unused.

Danke,

--
Don Kuenz KB7RPU
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

David Brown

unread,
Jun 14, 2020, 12:37:09 PM6/14/20
to
On 14/06/2020 04:35, natewes...@gmail.com wrote:
> Only six years late, but I too was looking for something like what you described, and I found this.
>
> https://www.adafruit.com/product/2264
>

Looks good. FTDI devices connected to a USB port are a fine way to do
IO from a PC. They are easily controlled from Python (or any other
convenient language of your choice). I haven't used that particular
board, but I've used plenty of FTDI chips like that.

0 new messages