Simple I/O on Windows PC

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