Getting GPIO out of a PC? Best way?

I hadn't bothered giving links, because I had assumed the OP was capable

(You really should get yourself a newsreader and a newsserver instead of that crap Google Groups interface that always messes up quotations.)

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.

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.

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.

Reply to
David Brown
Loading thread data ...

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

Reply to
haiticare2011

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. :)

Reply to
haiticare2011

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

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.

Reply to
David Brown

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.

Reply to
David Brown

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.

And certainly

Reply to
mike

USB. Pick your speed.

Reply to
krw

Sure, in any number of forms from bare uC chips, to development boards, to something like an Aardvark. There are many, many, options.

Reply to
krw

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

Reply to
krw

best. This

DMA

get,

fashion.

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.

?-)

Reply to
josephkk

@@@@@@@@@ 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. ?

Reply to
haiticare2011

Dude, you really need to learn some things about embedded systems.

--

Rick
Reply to
rickman

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.

Reply to
haiticare2011

David Brown

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

Reply to
haiticare2011

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 :-).

Reply to
upsidedown

So how would you do it? I am currently figuring on using a FTDI USB dev board - ? tia JB

Reply to
haiticare2011

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
Reply to
rickman

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 (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.

Reply to
sms

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.

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

--
Regards, 
Martin Brown
Reply to
Martin Brown

ou

Thanks. JB

form are

em,

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

Reply to
haiticare2011

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.