Forums

Simple I/O on Windows PC

Started by BartC June 21, 2013
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.)