Forums

Simple I/O on Windows PC

Started by BartC June 21, 2013
On Friday, June 21, 2013 10:13:47 AM UTC+1, BartC wrote:
> 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.
1995.
> 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
Yes! Velleman K8055 http://www.velleman.eu/products/view/?country=be&lang=en&id=351346 or something very similar. K8055 could be better but it works out of the box. There are also more industrial solutions but rather more expensive. Also very easy to create same function using Arduino. In fact I would recommend getting an Arduino and having a play with it anyway.
"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:GfednVgK54qnxVnMnZ2dnUVZ8i2dnZ2d@lyse.net...
> On 21/06/13 14:43, BartC wrote:
>> 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"?
Just that: I've always used my own languages (and my own compilers, assemblers etc) and haven't grown out of the habit. Originally this was because I was building bare boards with no software to get started with, but I've since found using my own stuff to be very productive.
> 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
That's largely it. Linux ought to be the solution, but I just don't like it and as I said it's full of problems and things that don't work. -- Bartc
"Bob" <bobcousins42@googlemail.com> wrote in message 
news:9fdfe77b-6755-468f-98b8-c877c5ec3303@googlegroups.com...
> On Friday, June 21, 2013 10:13:47 AM UTC+1, BartC wrote:
>> 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 > > Yes! Velleman K8055 > http://www.velleman.eu/products/view/?country=be&lang=en&id=351346 or > something very similar. K8055 could be better but it works out of the box. > There are also more industrial solutions but rather more expensive.
Sounds familiar! Actually that's the one I've tried before, but I've just dusted it down and tried it again. Although the specs say 20msec command processing time, I'm managing to get over 100 bytes per second written to the output pins, far better than I remember. Although the effective throughput might be only 50 bytes/second (because of the need to signal each new byte), it seems simpler than any other solution so far. I can also drive it directly from my own software (via DLL functions).
> Also very easy to create same function using Arduino. In fact I would > recommend getting an Arduino and having a play with it anyway.
Yes, I've been playing with an Arduino, that's what gave me the idea to attempt something of my own. But the little 32KB board I have, comes with 256MB of software on the PC, with 6000 files in 2000 directories! That's a lot of software to get in the way and make any solutions using this rather unwieldy. -- Bartc
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) > >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.)
You're looking for the wrong hardware. Most "parallel port" hardware is specifically about driving printers. Search for one of the many PCIe DIO (Digital I/O) cards. Many of those come with drivers that let a user mode application wiggle the pins as desired. If you want to actually take interrupts from the device, some of the packages have the ability to reflex a bit of that to user mode, but in general you then get to write a Windows device driver. There are USB DIO devices as well, although (obviously) response times tend to be rather slower.
BartC wrote:
> Yes, I've been playing with an Arduino, that's what gave me the idea to attempt something of my own. But the little 32KB board I have, comes with 256MB of software on the PC, with 6000 files in 2000 > directories! That's a lot of software to get in the way and make any solutions using this rather unwieldy.
I don't see why you think the size/number of the files on the PC is relevant. Even if you have an Arduino, it doesn't mean you have to use the Arduino environment: you can program bare silicon directly in C or assembler. (Operating systems and environments: just say no :) ) I've recently done just that, since I wanted lower average power consumption than the Arduino environment would let me achieve. Programming an ATMega324 in C is trivial, and if you just wanted to do a blinky LED I'd be surprised if the total code size in the ATMega324 reached 100 bytes.
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) > >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.
Microsoft used to have an operating system (WinME and before) that booted from DOS and kept the DOS system it booted from protected, while operating. You could (and I did) type WIN into a DOS prompt to start it up and, when you shut it down you'd go back to the DOS prompt and could continue. Then they went to an operating system (WinNT and later) which supported direct booting without any prior DOS, used a different file system, and seriously began looking at security issues and keeping the hardware more protected than before. All this also meant they had to actually WORK HARD and completely reimplement old DOS emulation. The older O/S line actually had a REAL copy of the old DOS that it could use for emulation, so the emulation almost came for free. But the new O/S line doesn't preserve it, so Microsoft has to write stuff from scratch, which Microsoft did NOT like doing and planned to minimize as soon as possible. Earlier DOS systems were "modified" upon Windows boot-up to support (via WinOldAp running on the Windows protected mode side) traps into Windows so that DOS applications could call Windows functions. (An illegal instruction was used that would cause this trap and WinOldAp would then examine the immediate bytes following to decide what to do.) You could, for example, call the clipboard from DOS. The earlier Windows (WinME and before) would also allow you to use ctrl-ENTER to put a DOS box into full-screen mode. When you did that, WinOldAp would also then set up the protected mode I/O mapping so that the DOS box had complete access to all the I/O ports, rather than trapping them and emulating them. Win2000 had better DOS support (for example, it supported the earlier clipboard function calls.) Later WinNT O/S incarnations, such as WInXP and later, removed that support from their DOS emulation. (And removed the ability to directly access the I/O ports, as well.) That's just Microsoft. Meanwhile Intel and IBM PC compatible manufacturers were being greatly reduced in numbers by Intel's PCI initiative -- by design. The entry cost for anyone making a reflection wave bus system (PCI) was MUCH HIGHER than it was for incident wave (old ISA bus.) They sold the idea on "low power" but the real reason (and I know this from when I worked at Intel as an employee there) was because pricing would never increase as long as there were so many different players in the market and they needed to raise the cost bar. PCI was a way to do that. With that in place, there was another problem at Intel. More than half of their chipset bugs came from the ISA bus interface (southbridge and it's special out-of-band wiring to the northbridge.) The ISA bus supported a DMA mode that could not be directly supported by the PCI design (PCI supports only short bursts, but not the unending transaction lengths that ISA supported, nor the guaranteed timing... etc.) This was a BIG problem to continue supporting. So Intel began plans to eliminate the southbridge, entirely, and to terminate the ISA bus forever. This was ALSO consistent with raising the bar, because anyone (even me) could design and construct ISA bus boards for custom stuff. Getting rid of ISA meant, once again, that the bar was raised for vendors wanting into the PC space. Customers had no idea. As ISA disappeared, so of course did the parallel port and serial port. Older designs required ISA access. Some designs in the older chipsets either implemented these in separate superIO chips or in the southbridge itself. But without a southbridge in newer designs, the superIO had nothing to connect to and of course the non-existent southbridge could not do the work, either. This put anything like that onto the PCI, which was entirely new and couldn't use the old methods. And I don't recall that lasting long, if it ever happened at all. It was easier to just lose the parallel and serial ports. Mouse and keyboard were probably the longest thing to hang around. I suppose you could look at screwing around with those if your motherboard supports them. Anyway, I keep fully functioning ISA based systems around for exactly this reason. I can't design and wire wrap a PCI board (clock skew to data on 33MHz must be 2ns and uses a serpentine line to achieve it and the testing equipment is beyond my budget.) But I can easily do an ISA board in short order and I know it will work even before I test it.
>(I understand that this is straightforward enough using a microcontroller, >however all my development tools are on the PC!)
Yeah. I understand.
>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.)
What I did for this was to buy up a bunch of Texas Instruments LaunchPads when they were $4.30 each, shipping included. I've stacks of them. They attach to the USB and already include PC drivers to communicate over USB but using RS-232 COM port methodology on the Windows side (easy.) From the MSP-430 side, it's just a simple RS-232 driver bit of code. The board includes a complete set up for connecting in daughter cards, so I can wire up anything I want there. One application I did this way was to let me connect Mailstations (which only have a parallel port for printers and cost me $0 because no one wants them anymore) to the PC and transport files into the PC. But writing commands that could be passed between the PC and the LaunchPad software would be a walk in the park. No, not as easy as ISA programming directly, but at least you control things and can add capability as time permits. I wouldn't use an Arduino for this. WAY too expensive when compared to other choices. There are so many other much cheaper/better options around now. You should be able to get a system with USB support and daughter card connectors on it for $10 or less. Even 32-bit ARM based systems I get cost $10. Keep the costs low so you can buy a bunch of them and dedicate their daughter card designs to your application. Jon
"Tom Gardner" <spamjunk@blueyonder.co.uk> wrote in message
news:lZ0xt.110435$jM6.74585@fx13.am4...
> BartC wrote: >> Yes, I've been playing with an Arduino, that's what gave me the idea to >> attempt something of my own. But the little 32KB board I have, comes with >> 256MB of software on the PC, with 6000 files in 2000 >> directories! That's a lot of software to get in the way and make any >> solutions using this rather unwieldy. > > I don't see why you think the size/number of the files on the PC is > relevant. > > Even if you have an Arduino, it doesn't mean you have > to use the Arduino environment: you can program bare > silicon directly in C or assembler.
Sure, but I don't know how! And it's difficult to find out because people are expected to use tools like this so that the direct methods are not documented. The great, sprawling nature of the software (with the paths in some arguments being twelve-deep!) makes it hard to figure out what's what as well. I did manage to eliminate the GUI (an entire Java subsystem was included just for this purpose), but I was still left with a series of five programs that had to be run for each update, with some hairy-looking parameters. The last stage was uploading the binary program, and was invoked like this: C:\Arduino\hardware\tools\avr\bin\avrdude -CC:\Arduino\hardware/tools/avr/etc/avrdude.conf -q -q -patmega328p -carduino -P\\.\COM3 -b115200 -D -Uflash:w:filename.cpp.hex:i That would be a stumbling block even if I replaced all the other steps. The interface is USB, with apparently a COM port superimposed, but I've no idea what protocols are needed to rewrite the flash memory and restart the processor. -- Bartc
BartC wrote:
> "Tom Gardner" <spamjunk@blueyonder.co.uk> wrote in message > news:lZ0xt.110435$jM6.74585@fx13.am4... >> BartC wrote: >>> Yes, I've been playing with an Arduino, that's what gave me the idea to >>> attempt something of my own. But the little 32KB board I have, comes with >>> 256MB of software on the PC, with 6000 files in 2000 >>> directories! That's a lot of software to get in the way and make any >>> solutions using this rather unwieldy. >> >> I don't see why you think the size/number of the files on the PC is >> relevant. >> >> Even if you have an Arduino, it doesn't mean you have >> to use the Arduino environment: you can program bare >> silicon directly in C or assembler. > > Sure, but I don't know how! And it's difficult to find out because people > are expected to use tools like this so that the direct methods are not > documented. The great, sprawling nature of the software (with the paths in > some arguments being twelve-deep!) makes it hard to figure out what's what > as well.
I'm not sure which tools you are referring to in "tools like this". If the "tool" is the processor and you are programming bare silicon, you simply read the processor data sheet. If the tool is an execution environment (e.g. an o/s or Arduino) then read the documentation. if there isn't any, choose one that is documented! If the "tool" is the compiler/linker/downloader and debugging, then that is all taken care of by the IDE provided by Atmel. Windows, gag spit, but usable. There are a limited number of selections to be made, e.g compile for speed/size, which programmer/debugger you are using, but the choices are pretty straightforward (even if the resulting compiler switches etc aren't!).
> I did manage to eliminate the GUI (an entire Java subsystem was included > just for this purpose), but I was still left with a series of five programs that had to be run for each update, with some hairy-looking parameters. The last stage was uploading the binary program, and > was invoked like this:
Maybe the Java GUI's main benefit was to spit out the switches! Did you throw the baby out with the bathwater?
> C:\Arduino\hardware\tools\avr\bin\avrdude -CC:\Arduino\hardware/tools/avr/etc/avrdude.conf > -q -q -patmega328p -carduino -P\\.\COM3 -b115200 -D -Uflash:w:filename.cpp.hex:i > > That would be a stumbling block even if I replaced all the other steps. The > interface is USB, with apparently a COM port superimposed, but I've no idea > what protocols are needed to rewrite the flash memory and restart the > processor.
Neither have I, and I didn't want to either! I just used the Atmel IDE, and it worked.
On Friday, June 21, 2013 9:13:47 PM UTC+12, 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?! These are really to separate levels. If you want single bit IO, then and Serial-USB bridge device can do that, to the limit of the handshake lines. PC-end code is very simple. eg The FTDI UM232H can do this, with shorter turn around times than Full Speed bridges, and it also has other modes, which need more SW effort, but can give more IO.
> > 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.)
This starts to go beyond a USB-Serial bridge, but something like the UM232H has other modes, and with more work at the PC end, you can expand the IO. For the most flexible real-world end, you are probably best to use a Bootloader uC and a USB-Serial bridge. That way, you can avoid Windows bottlenecks if you need to. A Lowest cost combination for moderate IO, would be something like UMFT234XF+AT89LP52, and a smarter and faster combination might use UM232H+AT89LP51RB2 The LP51RB2 has bootloader in ROM, with easy access to UM232H-driven firmware updates, so that gives a flexible end, that can accept std COM connections.
"Tom Gardner" <spamjunk@blueyonder.co.uk> wrote in message 
news:XH2xt.156150$tu1.36428@fx20.am4...
> BartC wrote:
>> Sure, but I don't know how! And it's difficult to find out because people >> are expected to use tools like this so that the direct methods are not >> documented. The great, sprawling nature of the software (with the paths >> in >> some arguments being twelve-deep!) makes it hard to figure out what's >> what >> as well. > > I'm not sure which tools you are referring to in "tools like this". > > If the tool is an execution environment (e.g. an o/s or Arduino) > then read the documentation. if there isn't any, choose one that > is documented!
> If the "tool" is the compiler/linker/downloader and debugging, > then that is all taken care of by the IDE provided by Atmel. > Windows, gag spit, but usable. There are a limited number of > selections to be made, e.g compile for speed/size, which > programmer/debugger you are using, but the choices are pretty > straightforward (even if the resulting compiler switches etc > aren't!).
The 'tools' were the software, 'Arduino 1.0.5', '...based on Processing', which is a packaging of a gcc compiler (or is it g++) among other things. Very untidy when you look into it. My approach has always been far simpler and much tidier (it had to be because I didn't have 250MB of spare disk space!) But I'm fairly new to these new systems and I only just understand that an Arduino is itself a packaging of an AVR processor.
> If the "tool" is the processor and you are programming bare silicon, > you simply read the processor data sheet.
That's another valid approach of course, and what I used to do (in the early eighties). But that just brings me back to my original problem of needing to bootstrap such a newly built circuit by downloading code from a host computer. I think I can use my K8055 board to get started with that, and worry about speeding up the downloads later. -- Bartc