Simple I/O on Windows PC

Suppose I have an x86-based PC running Windows 7; I have a couple of simple
tasks:

o Write a single bit to a pin somewhere (perhaps connected to an LED)
o Read a single bit from a pin (perhaps connected to a push-button)

At what point over the last 20-30 years did something so simple become next
to impossible?! I used to do this all the time over ten years working with
hardware. IIRC it only took a single instruction to do so as well.

(I understand that this is straightforward enough using a microcontroller,
however all my development tools are on the PC!)

From what I've been able to discover, 'solutions' involve adding a parallel
port via USB (or possibly even PCIe, which I have inside the desktop). But
then what? It either seems to involve directly programming USB
(which looks horrendous), or accessing the port as a file LPT1 or whatever,
but that doesn't look like it will work well when there is lots of mixed,
disjointed input and output. It just doesn't sound right either. (And anyway
when I once tried the latter to drive an actual printer, it didn't work!)

I've even thought of communicating with the outside world via the speaker
(modulating my data into a WAV file which is then played), or with a
photodiode taped to a corner of my display which I then modulate with black
and white flashes! But then it starts to get ridiculous (and those last two
methods will be slow, only work for output, and require building circuitry
that I no longer have the knack for).

Is there in fact a simple, painless solution to this problem? It would
presumably take the form of:

o Some gadget or circuit to attach my PC
o Preferably with 8 bits of input and output
o Can be accessed directly with some software or other. Not necessarily with
direct port I/O, but function calls via a provided DLL perhaps (eg.
readbits(), writebits()).
o Is fast enough to do write at least a few thousand bytes per second

(I remember a few years ago having a kit or board that did some of this:
reading or writing a few bits (not 8 perhaps 4 or 5), connecting to USB,
accessed via a DLL, but it was too slow to be practical (perhaps only a
handful of updates per second) and I lost interest.)

-- 
Bartc 

On 21/06/13 11:13, BartC wrote:
> Suppose I have an x86-based PC running Windows 7; I have a couple of simple
> tasks:
> 
> o Write a single bit to a pin somewhere (perhaps connected to an LED)
> o Read a single bit from a pin (perhaps connected to a push-button)
> 
> At what point over the last 20-30 years did something so simple become next
> to impossible?! I used to do this all the time over ten years working with
> hardware. IIRC it only took a single instruction to do so as well.
> 
> (I understand that this is straightforward enough using a microcontroller,
> however all my development tools are on the PC!)
> 
> From what I've been able to discover, 'solutions' involve adding a parallel
> port via USB (or possibly even PCIe, which I have inside the desktop). But
> then what? It either seems to involve directly programming USB
> (which looks horrendous), or accessing the port as a file LPT1 or whatever,
> but that doesn't look like it will work well when there is lots of mixed,
> disjointed input and output. It just doesn't sound right either. (And
> anyway
> when I once tried the latter to drive an actual printer, it didn't work!)
> 
> I've even thought of communicating with the outside world via the speaker
> (modulating my data into a WAV file which is then played), or with a
> photodiode taped to a corner of my display which I then modulate with black
> and white flashes! But then it starts to get ridiculous (and those last two
> methods will be slow, only work for output, and require building circuitry
> that I no longer have the knack for).
> 
> Is there in fact a simple, painless solution to this problem? It would
> presumably take the form of:
> 
> o Some gadget or circuit to attach my PC
> o Preferably with 8 bits of input and output
> o Can be accessed directly with some software or other. Not necessarily
> with
> direct port I/O, but function calls via a provided DLL perhaps (eg.
> readbits(), writebits()).
> o Is fast enough to do write at least a few thousand bytes per second
> 
> (I remember a few years ago having a kit or board that did some of this:
> reading or writing a few bits (not 8 perhaps 4 or 5), connecting to USB,
> accessed via a DLL, but it was too slow to be practical (perhaps only a
> handful of updates per second) and I lost interest.)
> 

Look at <http://www.ftdichip.com> and pick a suitable USB module.  You
can use them for UARTs, SPI buses, or simple I/O pins.  FTDI provides
drivers, DLL's, and samples for many uses - you can also find plenty of
libusb based code on the net.  It all works on Windows or Linux.

You'll be hard pushed to get thousands of bytes per second with
bit-banging, but it should be no problem with SPI or UART.

On Fri, 21 Jun 2013 10:13:47 +0100, "BartC" <bc@freeuk.com> wrote:

>Suppose I have an x86-based PC running Windows 7; I have a couple of simple
>tasks:
>
>o Write a single bit to a pin somewhere (perhaps connected to an LED)
>o Read a single bit from a pin (perhaps connected to a push-button)

I do not know about Win7, but at least in Win2000/XP the GiveIO driver
could be used to open  the whole I/O address space to the user
process.

Of course this works only for (ISA) I/O cards accessed by the IN or
OUT machine instructions.

This does not help with memory mapped peripherals.

On 06/21/2013 11:13 AM, BartC wrote:
> Suppose I have an x86-based PC running Windows 7; I have a couple of simple
> tasks:
>
> o Write a single bit to a pin somewhere (perhaps connected to an LED)
> o Read a single bit from a pin (perhaps connected to a push-button)
>
> At what point over the last 20-30 years did something so simple become next
> to impossible?! I used to do this all the time over ten years working with
> hardware. IIRC it only took a single instruction to do so as well.
>
> (I understand that this is straightforward enough using a microcontroller,
> however all my development tools are on the PC!)
>
>  From what I've been able to discover, 'solutions' involve adding a
> parallel
> port via USB (or possibly even PCIe, which I have inside the desktop). But
> then what? It either seems to involve directly programming USB
> (which looks horrendous), or accessing the port as a file LPT1 or whatever,
> but that doesn't look like it will work well when there is lots of mixed,
> disjointed input and output. It just doesn't sound right either. (And
> anyway
> when I once tried the latter to drive an actual printer, it didn't work!)
>
> I've even thought of communicating with the outside world via the speaker
> (modulating my data into a WAV file which is then played), or with a
> photodiode taped to a corner of my display which I then modulate with black
> and white flashes! But then it starts to get ridiculous (and those last two
> methods will be slow, only work for output, and require building circuitry
> that I no longer have the knack for).
>
> Is there in fact a simple, painless solution to this problem? It would
> presumably take the form of:
>
> o Some gadget or circuit to attach my PC
> o Preferably with 8 bits of input and output
> o Can be accessed directly with some software or other. Not necessarily
> with
> direct port I/O, but function calls via a provided DLL perhaps (eg.
> readbits(), writebits()).
> o Is fast enough to do write at least a few thousand bytes per second
>
> (I remember a few years ago having a kit or board that did some of this:
> reading or writing a few bits (not 8 perhaps 4 or 5), connecting to USB,
> accessed via a DLL, but it was too slow to be practical (perhaps only a
> handful of updates per second) and I lost interest.)
>

Get a Raspeberry Pi and either a) use that directly or b) connect to it 
from your Windows PC via the TCP/IP service of your choice. The 
Raspberry has enough GPIOs, there are enough drivers and it is quite 
easy to set up a server on it. Getting kBytes/s is said to be feasible 
although I haven't tested this myself.

Pere

Pere

On 2013-06-21, BartC <bc@freeuk.com> wrote:
> Suppose I have an x86-based PC running Windows 7; I have a couple of simple
> tasks:
>

You start by listing a simple task, but then move onto a far more
complicated task, so I will address the tasks separately.

> o Write a single bit to a pin somewhere (perhaps connected to an LED)
> o Read a single bit from a pin (perhaps connected to a push-button)
>

This one should be solvable by using the control lines on a traditional
serial port (and maybe a USB serial port as well).

There are several circuit designs in common use for programming AVR
microcontrollers via a traditional serial port by using the control
lines in a rather creative way. You could look at these circuits for
ideas about how to do this safely.

For example, Olimex have such a circuit listed on their website at:

https://www.olimex.com/Products/PIC/Programmers/PIC-PG1/

which might give you some ideas.

> From what I've been able to discover, 'solutions' involve adding a parallel
> port via USB (or possibly even PCIe, which I have inside the desktop). But
> then what? It either seems to involve directly programming USB
> (which looks horrendous), or accessing the port as a file LPT1 or whatever,
> but that doesn't look like it will work well when there is lots of mixed,
> disjointed input and output. It just doesn't sound right either. (And anyway
> when I once tried the latter to drive an actual printer, it didn't work!)
>

> Is there in fact a simple, painless solution to this problem? It would
> presumably take the form of:
>
> o Some gadget or circuit to attach my PC
> o Preferably with 8 bits of input and output
> o Can be accessed directly with some software or other. Not necessarily with
> direct port I/O, but function calls via a provided DLL perhaps (eg.
> readbits(), writebits()).
> o Is fast enough to do write at least a few thousand bytes per second
>

If you use a traditional parallel port (instead of a USB one), this may
be possible.

I currently use a Wiggler based JTAG clone (from Olimex) which connects
to a development PC via the parallel port and works just fine under
Linux. There are multiple circuits available online which implement
such a Wiggler cable and you can look at them to get ideas about how
to connect to the parallel port.

With the cable design, you get several bits from the parallel port to
the device and one bit (via the Busy line) back to the PC. However,
all the traditional parallel ports these days are supposed to be
bi-directional so you should be able to improve on that.

As for the software side of things, have a look at the source code
for OpenOCD to see how it accesses a traditional parallel port. I've
only used OpenOCD on Linux, but I believe the parallel port interface
is also supported by OpenOCD on Windows.

However, having said all that, I agree with David; if your latter
requirement is your real requirement, you may want to look at the
FTDI based devices he suggests.

Simon.

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

On 2013-06-21, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> There are several circuit designs in common use for programming AVR
> microcontrollers via a traditional serial port by using the control
> lines in a rather creative way. You could look at these circuits for
> ideas about how to do this safely.
>
> For example, Olimex have such a circuit listed on their website at:
>
> https://www.olimex.com/Products/PIC/Programmers/PIC-PG1/
>
> which might give you some ideas.
>

Oops, that's the PIC one. I use a variant of the AVR one here:

https://www.olimex.com/Products/AVR/Programmers/AVR-PG1B/

Simon.

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

BartC wrote:

> Suppose I have an x86-based PC running Windows 7; I have a couple of
> simple tasks:
> 
> o Write a single bit to a pin somewhere (perhaps connected to an LED)
> o Read a single bit from a pin (perhaps connected to a push-button)
> 
> At what point over the last 20-30 years did something so simple become
> next to impossible?! I used to do this all the time over ten years working
> with hardware. IIRC it only took a single instruction to do so as well.

As the home computer was refined as a consumer product, the cost went down, 
the speed and capacity went up, but at the cost of complexity and 
brittleness.  Peripheral-Componenent-Interconnect being my favorite Faustian 
bargain there.

Another interface gizmo that hasn't been mentioned yet is the Bus Pirate: 
<http://dangerousprototypes.com/docs/Bus_Pirate>

	Mel.

"o pere o" <me@somewhere.net> wrote in message 
news:kq1bv1$j47$1@dont-email.me...
> On 06/21/2013 11:13 AM, BartC wrote:

>> Is there in fact a simple, painless solution to this problem? It would
>> presumably take the form of:
>>
>> o Some gadget or circuit to attach my PC
>> o Preferably with 8 bits of input and output
>> o Can be accessed directly with some software or other. Not necessarily
>> with
>> direct port I/O, but function calls via a provided DLL perhaps (eg.
>> readbits(), writebits()).
>> o Is fast enough to do write at least a few thousand bytes per second

> Get a Raspeberry Pi and either a) use that directly or b) connect to it 
> from your Windows PC via the TCP/IP service of your choice. The Raspberry 
> has enough GPIOs, there are enough drivers and it is quite easy to set up 
> a server on it.

I did get a Pi last year with a view to porting my tools across to it and 
working from that (I like to use my own languages and tools so that's a 
stumbling block). That partly worked, until it came to the terminal and 
keyboard capabilities I needed for my editor, but Linux terminal/keyboard 
handling was too crude.

It's possible to get code into it in various ways, but not 'fluently' enough 
to make development brisk. (Also I don't like Linux and this thing only 
works with my TV!)

I decided to keep my development stuff on the PC. I also would quite like to 
have a go at building a microprocessor circuit of my own, where it would be 
nice if I could write/compile any code on the PC, and somehow download it 
onto this board. (This would likely use a dual-ported static ram, no flash 
memory or anything, so a handful of I/O pins to allow a few hundred bytes to 
be downloaded in under a second or so is all that's needed. I don't really 
want to toggle in machine code by hand; not in 2013...)

-- 
Bartc 

Also this board found on eBay that I have not used (yet):

Object: # 170865359189

http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=170865359189&ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649

On 21/06/13 14:43, BartC wrote:
> "o pere o" <me@somewhere.net> wrote in message
> news:kq1bv1$j47$1@dont-email.me...
>> On 06/21/2013 11:13 AM, BartC wrote:
> 
>>> Is there in fact a simple, painless solution to this problem? It would
>>> presumably take the form of:
>>>
>>> o Some gadget or circuit to attach my PC
>>> o Preferably with 8 bits of input and output
>>> o Can be accessed directly with some software or other. Not necessarily
>>> with
>>> direct port I/O, but function calls via a provided DLL perhaps (eg.
>>> readbits(), writebits()).
>>> o Is fast enough to do write at least a few thousand bytes per second
> 
>> Get a Raspeberry Pi and either a) use that directly or b) connect to
>> it from your Windows PC via the TCP/IP service of your choice. The
>> Raspberry has enough GPIOs, there are enough drivers and it is quite
>> easy to set up a server on it.
> 
> I did get a Pi last year with a view to porting my tools across to it
> and working from that (I like to use my own languages and tools so
> that's a stumbling block). That partly worked, until it came to the
> terminal and keyboard capabilities I needed for my editor, but Linux
> terminal/keyboard handling was too crude.
> 

Linux terminal/keyboard handling was "too crude" ?  I haven't heard that
one before.  Hands up those that can type "Anton&iacute;n Dvo&#345;&aacute;k" on a Windows
keyboard without using "character map".  I can't see many reasons why
you want want something more than ASCII for programming, but there you go.

Of course, the common way to do development work with the Pi is with
Linux on your desktop, connected to the Pi over the network.  Just
because you /can/ run your development tools, editors, etc., native on
the Pi, does not mean it is normally the best solution - your desktop is
going to be much more powerful.

Incidentally, what do you mean you like to use "your own languages and
tools"?

> It's possible to get code into it in various ways, but not 'fluently'
> enough to make development brisk. (Also I don't like Linux and this
> thing only works with my TV!)

It has an HDMI output.  You can connect that to your TV - but you can
also connect it to most monitors (at least, most half-decent modern
monitors, and most decent half-modern monitors).  And if you don't have
HDMI on your monitor, you can use a simple HDMI-to-DVI converter.

Of course, not liking Linux is a matter of taste.  But it sounds like
you are frustrated by with Windows philosophy of not letting you do what
you want with your own machine any more - maybe if you looked closer,
you would start to like Linux on your desktop.

> 
> I decided to keep my development stuff on the PC. I also would quite
> like to have a go at building a microprocessor circuit of my own, where
> it would be nice if I could write/compile any code on the PC, and
> somehow download it onto this board. (This would likely use a
> dual-ported static ram, no flash memory or anything, so a handful of I/O
> pins to allow a few hundred bytes to be downloaded in under a second or
> so is all that's needed. I don't really want to toggle in machine code
> by hand; not in 2013...)
> 

Dual-port ram for debugging and development went out of fashion at least
15 years ago.  For microcontroller work, you use a debugger (jtag or
similar) and download to the micro's internal flash.

Once we know what you are aiming for here, I'm sure you will get lots of
suggestions in this group.  But one thing they all have in common is
that you do your development on a PC and use a USB-connected debugger.
(If you were in the market for Ethernet connected debuggers, you
wouldn't be asking these questions.  And you won't use serial port or
parallel port devices unless you are stuck working with ancient tools
and micros.)