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

In article <m71aab$i4n$1@dont-email.me>, david.brown@hesbynett.no 
says...
> 
> On 19/12/14 14:27, rickman wrote:
> > On 12/19/2014 8:21 AM, jkn wrote:
> >> Hi David
> >>
> >> On Friday, 19 December 2014 11:34:29 UTC, David Brown  wrote:
> >>>
> >>> 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 Python ;-)
> >>
> >> Sadly I think the USB overhead makes this a bit of a non-starter. 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. It
> >> may be that I could use some of the programmable capabilities of the
> >> servo boards to get something like what I need.
> > 
> > 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.
> > 
> 
> 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.

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
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate

On 2014-12-19, Tim <tim@bugblat.invalid> wrote:
>
> 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.
>

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

On Fri, 19 Dec 2014 02:02:07 -0800 (PST), jkn <jkn_gg@nicorp.f9.co.uk>
wrote:

>Hi all
>
>I'm trying to source a prototyping/interfacing board to control via a desktop PC with USB port. Ideally it should have the following ports on it:
>
>- 1 RS-232 port
>- 1 RS-485 port
>- 'a few' (say 4 or more) 5V digital I/O lines
>
>I'm sure I can do all this via a USB hub and an appropriate selection of
>'hackaday'-type breakout boards. But ideally I'd like to source one board which
>can do the lot.
>
>Likely to be programmed in Python FWIW. I don't really want an rPi or something which has to have an OS on board and boot up etc; ideally this should all be powered from the host USB port.
>
>I've got a lot of links to possible combinations of modules via Sparkfun,
>Phidget.com, etc. etc., but nothing that exactly fits my needs. Can anyone think
>anywhere else I should be looking?
>
>    Thanks a lot
>    Jon N

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. 

www.knjn.com   FPGA and ARM/FPGA protoboards with USB
www.fpga4fun.com  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.
 

> >I'm trying to source a prototyping/interfacing board to control via a desktop PC with USB port. Ideally it should have the following ports on it:
> >
> >- 1 RS-232 port
> >- 1 RS-485 port
> >- 'a few' (say 4 or more) 5V digital I/O lines
> >
> 
> 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. 

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.

On Friday, 19 December 2014 14:48:56 UTC, Tim  wrote:
> >> 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 Python ;-)
> >
> > Sadly I think the USB overhead makes this a bit of a non-starter. 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. 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 into too much detail...)
> >
> >      Thanks
> >      J^n
> >
> 
> 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

Hi Tim
    I know that people refer to this way of worknig the FTDI pins as 'bit-banging', 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 having 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 bit
more thought than I was hoping to put into this 'lashup' project ;-/

    Cheers
    Jon N

On 20/12/2014 17:43, Simon Clubley wrote:
> On 2014-12-19, Tim <tim@bugblat.invalid> wrote:
>>
>> 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.
>>
>
> 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.
>

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

On 2014-12-23, Tim <tim@bugblat.invalid> wrote:
> On 20/12/2014 17:43, Simon Clubley wrote:
>> On 2014-12-19, Tim <tim@bugblat.invalid> wrote:
>>>
>>> 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.
>>>
>>
>> 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).
>>

[snip]

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

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