seeking USB interface/breakout board with 2x serial, GPIO...

Try somewhere like Hobbytronics or Sparkfun . There are some bits within the Arduino bits that may either collectively or singly fulfil your needs. You might not find all your required I/O oin one board, but if you are prototyping the small modules available from those companies might be suitable for some playing around with.

Alternatively, look at ST Micro who do development boards with ARM Core M0 on board which will have all theI/O you want on one board and could end up autonomous from your PC with the appropriate programming.

--
******************************************************************** 
Paul E. Bennett IEng MIET..... 
Forth based HIDECS Consultancy............. 
Mob: +44 (0)7811-639972 
Tel: +44 (0)1235-510979 
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. 
********************************************************************

Thanks for the suggestions. I'd already looked at Sparkfun etc., and hobbytronics seem to have very similar parts (UK-based, of coursde, which helps.) But following your prompting I took a closer look, and I think maybe I can use their servo controller as a digital output. This capability is buried a bit in the documentation but

I'm sure I could use one of the ST micro boards but that opens up a different can of development work which I was hoping to avoid; this is for a testing lashup to be done in a hurry. Famous last words...

Thanks Jon N

Look for a module with an FTDI chip on it - chips like the FT4232H make it easy to get 232 or 485 ports from USB, along with SPI, I2C, and digital I/O. For 485 interfacing, there are control lines to enable the driver any time you are sending, which is very convenient. They work fine from Linux or Windows, and there are Python modules available on the web. I don't think FTDI themselves make a since board that covers your requirements, but it might be just as convenient to get separate

232, 485 and I/O modules.

Thanks for your reply. I know about the FTDI chips, and the ability to use the in 'bit-bang' mode to use the pins as output lines (dunno about inputs, but don't care at the moment). In fact, this was the first thing I tried, using a USB-to-serial debug cable and flashing an LED via libftdi and Pytho n ;-)

Sadly I think the USB overhead makes this a bit of a non-starter. One of th e output lines needs to act like an odometer input (pulses up to a few tens of hertz) and this would take up all the time available. It may be that I could use some of the programmable capabilities of the servo boards to get something like what I need.

(I didn't spell all of this out in my origial posting; didn't want to go in to too much detail...)

Thanks J^n

I can't help you with finding a vendor, but I can make your task a bit easier. Your 5 volt I/O can probably be done with RS-485 I/Os. So you can find a board with just 232 and 485 ports. The RS-485 drivers/receivers are 5 volt I/Os (or 5 volt tolerant at least). Outputs can be used as-is and you get an output of each polarity. The inputs are differential which means the unused input needs to be biased to a mid level voltage using resistors to power and ground which can be made part of your cable.

--

Rick

I can't imagine USB "overhead" would get in the way of toggling an I/O at 100 Hz. They use USB for real time audio signals which are *very* time sensitive, much more so than 10 ms.

--

Rick

It should be okay at rates of a few tens of Hz - 100 Hz should not be a problem. But sampling by polling digital inputs using Python brings quite a number of variable delays which will limit the speed, especially if you are using a 12 Mbit USB device. USB audio uses different USB modes, kernel drivers, big buffers, and other tricks in order to get low-latency transfers.

So I would expect this to work fine with a USB2.0 FTDI device and reasonable host PC (with more than one cpu core) - but I would be more sceptical if the FTDI device was an older USB1.1 type.

Of course, it is also possible to be a little smarter here - rather than doing simple polling, you could connect the high-speed ("high-speed" in the PC world...) input to the SPI data in pin, and do continuous SPI reads (ignoring clock, chip select and data outputs) - that should get you sampling at a reasonable rate. There may be other tricks or modes available in the FTDI device, especially if it is one of the more recent ones.

12 Mbit/s is still more than 1 byte per us which is 10,000 times faster than what the OP is talking about. I would suggest you not refer to this as USB1.1 and 480 Mbps as USB2.0. They are full speed and high speed respectively. USB1.1 does not support high speed, but USB2.0 supports both speeds and so does not distinguish the two.

How fast can you poll a USB connection from Python on the rPi? If this uses most of the processor's performance at 100 MHz polling rate, I think I'd just give up on the rPi and find something else... permanently.

--

Rick

Yes, it's bit-bang. But FTDI chips have reasonably big buffers that you fill at USB speed. The data is clocked out of the buffer at the speed you have selected via the 'clock divisor' setting. If you are clocking bits out at 100Hz or thereabouts the 'USB overhead' should be invisibly small.

--
Tim

Or some simple logic attached to inputs used in FIFO mode grab data points using a regular clock and get the buffer in. Used the buffer mode for better I2C MONITOR mode sampling than built-in hardware. In that case we id some tricks and clocked on changes on any line to compress data.

Using external clocking on FIFO mode pins gives you poor mans digital mode scope. Buffer can be many points long.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate

That does depend of course on if your output depends on sampling an input (which means you may not be able to buffer your output pulses).

Original USB (not sure about the very latest USB version) has a time slot window of 1mS so at 100Hz that's a 10% unbuffered load which is still very doable provided you can process any required input sources in a reasonable amount of time.

With general purpose OS overheads however, the OP may need to switch to a RTOS in order to guarantee any such processing (if required) is done within the required deadline.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

A slightly laternal solution is to go for an FPGA solution, or a combined ARM/FPGA solution. Once you have the FPGA, you can build as many UARTs as you want.

FPGA and ARM/FPGA protoboards with USB Verilog code for common interfaces, including SPI, UART

There's no OS involved, and the boards are USB powered. Freeware IDEs are available.

You would need to add a small amount of additional hardware to handle the voltage conversion for the serial interfaces. Also, don't underestimate the effort involved in getting to grips with the FPGA. software environment, even if you're copying existing modules.

You probably want to avoid this option unless you're prepared for an 'adventure', but once you're set up, these boards are extremely flexible and powerful for the sort of thing that you describe.

But why? PIC32MX has 6 UARTs. We use 3 of them because some shared pins are used for other purposes. If you want 6 UARTs, you can have them all.

e

he

use the in 'bit-bang' mode to use the pins as output lines (dunno about inp uts, but don't care at the moment). In fact, this was the first thing I tri ed, using a USB-to-serial debug cable and flashing an LED via libftdi and P ython ;-)

f the output lines needs to act like an odometer input (pulses up to a few tens of hertz) and this would take up all the time available. It may be tha t I could use some of the programmable capabilities of the servo boards to get something like what I need.

o into too much detail...)

Hi Tim I know that people refer to this way of worknig the FTDI pins as 'bit-b anging', but I am meaning something different. Having a bit more of an old-school background, bit-banging to me means explicitly setting the pin Hi-Lo-Hi etc. via the API (libftdi, direct register control, or whatever). It is this that makes bit-banging in my terms very slow on the FTDI chips; you have the overhead of a full USB transaction per state change.

The regime you are suggesting, of filling a buffer with a pattern and havin g the FTDI chip send this out at a give rate, is of course much less processor- intensive. It might be the way for us to progress, it just may involve a bi t more thought than I was hoping to put into this 'lashup' project ;-/

Cheers Jon N

I was responding to something along the lines of "One of the output lines needs to act like an odometer input (pulses up to a few tens of hertz) and this would take up all the time available."

I agree with you that a tougher problem is a system which involves reading input(s), processing, driving output(s). Jon sounds as if he is OK for that - he just wants some more ideas to play with.

--
Tim

[snip]

Yes, that's what I was reacting to as well. The implication of my question was: is the decision to deactivate the pulse generator at some point in the future tied to some external event which needs to be processed ?

If so, you may not be able to buffer the output pulses if you cannot tolerate extra pulses after the deactivation signal.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world