Perl to control hardware

[toma]

It's been a while since I've controlled hardware with a perl program. Does anyone have any module recommendations or advice to share?

In the past I used a crude technique, which was to write a C program that talked to hardware through a parallel port. I called this C program from perl. I have heard that a PIC controllers are a better solution these days. Does anyone use perl to help out with using a PIC?

I need to control about 20 AD7564's (quad serial 12 bit D/A converters) and a few other little serial chips. I have no real-time requirements and I only need to build one unit.

Is there another approach I should be thinking about?

It should work perfectly the first time! - toma

[bikeNomad]

Perl is fine for hardware control as long as you aren't really speed-conscious. For dealing with serial I/O, I've used Device::SerialPort and Event. For dealing with the parallel port, you could use Inline. You don't say what OS platform you're on; if you're using Linux, you could use ioperm to gain access to the address ranges for the parallel port, or use /dev/parport. Under Win9x (DOS) you could use Inline directly to talk to the parallel port. Under NT, I'm not sure.

I wrote a module for dealing with external hardware through the I2C and/or SMBus (in my case, a smart battery and smart battery charger, but you could also get to CPU temperature sensors, serial A/D converters, etc.). Under Linux, there's already the i2c drivers and the lm-sensors project; if you use this, the bulk of the work is already done for you.

I also hacked one of the i2c-algo-bit device drivers to work with the Maxim SMBus interface card; if you're interested in this, /msg me.

[toma]

I have my choice of OS between Linux, WinNT, Win2000, and HP-UX 10.20.

It should work perfectly the first time! - toma

[bikeNomad]

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.

[kb2yht]

Most of my experiance with PIC's for HW controle is wiht using them as IO trunks to bitwise IO devices. With a Device that is allready Serial The PIC may not help much. Although thay do have on bord DAC's .

The model we use is that tasks not requireing EPICs and VME can use a
PC-linux -> RS232 -> PIC -> ( HWIO, steping motors , penumatics , ADC/DAC Etc... )

We genraly write a simple set of functions in Asm or C for the PIC, and then use the serial line to down-load and runtime specal functions in the PIC memory from PERL or C.

We can then call all the functions in the PIC as though thay are sub's in the controle program. this included all the passing of var's and such. Taken to its extream ( which wee have done for a Z80 MCU) , the controle system downloads all the softwhere to the MCU each time it's initalized.
If your current C program is just using the bits in the parallel port as bit's and not trying to time a serial clock, the PIC or Z80 can offer many more lines of IO, and make the controleing computer less important ( Ie. I use a HP caculator to do debuging work on my controlers once there installed. )

Bill N. to spell, perchance convay my self; Or stay mute, a lurker on the side