Re: Re: Perl to control hardware

Replies are listed 'Best First'.
Re3: Perl to control hardware by bikeNomad (Priest) on Jul 25, 2001 at 09:40 UTC
I remember reading about an NT program that one could use to change the IO permissions for another program. Sorry I can't give you a pointer to it right now, but it was available for free from a company that sold training for NT device driver writers If you can use Linux, it's easy to get to simple hardware. You'll have to have a more complicated driver if you need DMA or interrupts, though. Still, if it's just a parallel port, Linux is easy. Likewise for the I2C implementation (or, indeed, USB or anything else that there's drivers for). If you do, say, a Device::IOPerm, I'm sure people will use it. I'd do one, except that I don't need it right now. But Inline is your friend. I did find that there is insufficient support in the i2c bit-banging protocols for doing block reads and writes from the i2c bus. This may or may not be a problem for you; if you're connecting your i2c stuff via a simple buffer to a parallel port, it could be a problem. However, my module should give you Perl access to byte and word read and write. If you need block read/write, you may want to use a "real" i2c interface; either on the motherboard (hint: there's probably one going to your memory devices!) or an add-in board. Many single-board computers capable of running Linux and Perl have SMBus connectors on-board. Remember if you use a parallel port to disable any OS-level drivers that may be wanting to use it. I just compile my embedded Linux kernels without parallel printer or parport support; you could also use modules for these drivers (and not load them or unload them) or explicitly inhibit the parport driver.	[reply]

Replies are listed 'Best First'.

Re3: Perl to control hardware
by bikeNomad (Priest) on Jul 25, 2001 at 09:40 UTC

If you can use Linux, it's easy to get to simple hardware. You'll have to have a more complicated driver if you need DMA or interrupts, though. Still, if it's just a parallel port, Linux is easy. Likewise for the I2C implementation (or, indeed, USB or anything else that there's drivers for).

If you do, say, a Device::IOPerm, I'm sure people will use it. I'd do one, except that I don't need it right now. But Inline is your friend.

I did find that there is insufficient support in the i2c bit-banging protocols for doing block reads and writes from the i2c bus. This may or may not be a problem for you; if you're connecting your i2c stuff via a simple buffer to a parallel port, it could be a problem. However, my module should give you Perl access to byte and word read and write. If you need block read/write, you may want to use a "real" i2c interface; either on the motherboard (hint: there's probably one going to your memory devices!) or an add-in board.

Many single-board computers capable of running Linux and Perl have SMBus connectors on-board.

Remember if you use a parallel port to disable any OS-level drivers that may be wanting to use it. I just compile my embedded Linux kernels without parallel printer or parport support; you could also use modules for these drivers (and not load them or unload them) or explicitly inhibit the parport driver.

[reply]