SEO

I want to control an electronic switch that needs a couple of TTL level
signals. It is possible to use a Sun for this? I was thinking about
programming the parallel port, which has in the past been used in PCs,
but I'm not sure how easy it is on a Suns - I have a feeling it is not
so easy.

Suns available include a SPARCstation 20, Ultra 60 and Netra T1. Speed
is not an issue and I dont mind sticking a transistor on the output if
needed.

Dave <someplace@nowhere-nice.com> wrote:
> I want to control an electronic switch that needs a couple of TTL level
> signals. It is possible to use a Sun for this? I was thinking about
> programming the parallel port, which has in the past been used in PCs,
> but I'm not sure how easy it is on a Suns - I have a feeling it is not
> so easy.
>
> Suns available include a SPARCstation 20, Ultra 60 and Netra T1. Speed
> is not an issue and I dont mind sticking a transistor on the output if
> needed.

sure. why not? Parallel is parallel, and can drive a transitor or even
better, an optoisolator, then your load.

Cydrome Leader wrote:
> Dave <someplace@nowhere-nice.com> wrote:
>> I want to control an electronic switch that needs a couple of TTL level
>> signals. It is possible to use a Sun for this? I was thinking about
>> programming the parallel port, which has in the past been used in PCs,
>> but I'm not sure how easy it is on a Suns - I have a feeling it is not
>> so easy.
>>
>> Suns available include a SPARCstation 20, Ultra 60 and Netra T1. Speed
>> is not an issue and I dont mind sticking a transistor on the output if
>> needed.
>
> sure. why not? Parallel is parallel, and can drive a transitor or even
> better, an optoisolator, then your load.

The issue is how do I program the parallel port to give the outputs I
want? On a PC running DOS it was only necessary to write a byte of data
at whatever the IO port for LPT1 or LPT2 were. But on a multi-user
operating system like Solaris, it is certainly not going to be as easy -
no non-root user is going to be able to do it and it might not be too
easy for root to do (I have root access, so whether it needs root or not
is irrelevant to me, but I have no idea how to write the code to do this).

Anyone know what would be involved to write to the parallel port so I
can set the outputs to some precise values I want and keep them there
until I want to change them?

My guess is that this will be very difficult to do, but I don't know.

If anyone has any suggestions to how to get some TTL level signals from
a Sun I would be intersted. The Sun will have a GPIB board in it too,
but I cant find any cheap GPIB controlled switches.

On 2008-03-18, Dave <foo@coo.com> wrote:
> Cydrome Leader wrote:
>> Dave <someplace@nowhere-nice.com> wrote:
>>> I want to control an electronic switch that needs a couple of TTL level
>>> signals. It is possible to use a Sun for this? I was thinking about
>>> programming the parallel port, which has in the past been used in PCs,
>>> but I'm not sure how easy it is on a Suns - I have a feeling it is not
>>> so easy.
>>>
>>> Suns available include a SPARCstation 20, Ultra 60 and Netra T1. Speed
>>> is not an issue and I dont mind sticking a transistor on the output if
>>> needed.
>>
>> sure. why not? Parallel is parallel, and can drive a transitor or even
>> better, an optoisolator, then your load.
>
> The issue is how do I program the parallel port to give the outputs I
> want?

A Google for "Sun parallel port programming" yields many hits. )

Most of them talking about Java. (



--
"Be thankful that you have a life, and forsake your vain
and presumptuous desire for a second one."
[email me at huge {at} huge (dot) org <dot> uk]

Dave wrote:

<snip>
> The issue is how do I program the parallel port to give the outputs I
> want? On a PC running DOS it was only necessary to write a byte of data
> at whatever the IO port for LPT1 or LPT2 were. But on a multi-user
> operating system like Solaris, it is certainly not going to be as easy -
> no non-root user is going to be able to do it and it might not be too
> easy for root to do (I have root access, so whether it needs root or not
> is irrelevant to me, but I have no idea how to write the code to do this).
>
> Anyone know what would be involved to write to the parallel port so I
> can set the outputs to some precise values I want and keep them there
> until I want to change them?
>

<snip>

At the risk of stating the obvious, why not browse the sources at
http://cvs.opensolaris.org/source/xr...e/usr/src/uts/

-or-

Get clues from OpenBSD/FreeBSD/NetBSD sources.

This would be useful if you wished to add or modify a kernel driver.
Otherwise, take a look at 'lp' filters in any flavor of SVR4 to see
how folks talk to the parallel port. In most cases, it isn't very
complicated to talk to it. See also 'man -s 7 lp':

> The parallel printer adapters are character devices. The
> minor device number corresponds to the primary or secondary
> parallel printer adapter. Thus, minor device 0 corresponds
> to the primary parallel printer adapter, while minor device
> 1 corresponds to the secondary adapter.
>
> The parallel port behaves as described in termio (7).



Michael

On 2008-03-18, Dave <foo@coo.com> wrote:
> Cydrome Leader wrote:

[ ... ]

>> sure. why not? Parallel is parallel, and can drive a transitor or even
>> better, an optoisolator, then your load.
>
> The issue is how do I program the parallel port to give the outputs I
> want? On a PC running DOS it was only necessary to write a byte of data
> at whatever the IO port for LPT1 or LPT2 were. But on a multi-user
> operating system like Solaris, it is certainly not going to be as easy -
> no non-root user is going to be able to do it and it might not be too
> easy for root to do (I have root access, so whether it needs root or not
> is irrelevant to me, but I have no idea how to write the code to do this).
>
> Anyone know what would be involved to write to the parallel port so I
> can set the outputs to some precise values I want and keep them there
> until I want to change them?

man bpp

man ecpp

Verify which is supported on your system.

and pay particular attention to the IOCTLs documented.

And as long as nothing else has to use that port, chown it to
belong to a process which your program runs as and you won't have to run
it as root.

Note that it will be a symlink to another /devices entry and
that will be the one which you will have to chown. Actually, by
default, mine is crw-rw-rw- so if you only need to access it, and don't
have to worry about others trying to access it and conflict with what
you are doing, you don't need to change anything.

FWWI Mine has /dev/ecpp0 and does not have /dev/bpp0

> My guess is that this will be very difficult to do, but I don't know.

Not that hard, once you learn to use IOCTLs.

> If anyone has any suggestions to how to get some TTL level signals from
> a Sun I would be intersted. The Sun will have a GPIB board in it too,
> but I cant find any cheap GPIB controlled switches.

You could also pick up one of the older serial port chips
(separate I/O buses and status bits) and send characters to it to set
particular bits high or low. If you need a lot of them, use the 8 bits
and decode them into 128 addresses and a bit for "set high" or "set
low".

Enjoy,
DoN.

--
Email: <dnichols@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Also try "man bpp"

DoN. Nichols wrote:

>> Anyone know what would be involved to write to the parallel port so I
>> can set the outputs to some precise values I want and keep them there
>> until I want to change them?
>
> man bpp
>
> man ecpp
>
> Verify which is supported on your system.
>
> and pay particular attention to the IOCTLs documented.

Thanks for that, although I still cant see how to do this from the ecpp
man page. There are plenty of structures defined in that man page, but I
don't see what actually writes the data. Perhaps I am being thick!

We eventually found on eBay a GPIB controlled relay (actually 6
reed-relays in a box) so bought a couple of them for $60 the pair. Since
GPIB is going to be used to set up some test equipment, having a GPIB
card is not excessive for this.

But I would like to know how to use the parallel port.

>
> And as long as nothing else has to use that port, chown it to
> belong to a process which your program runs as and you won't have to run
> it as root.

Cheers. Nothing else needs to use it. I'm basically setting up a couple
of Suns to just run the test equipment.

I just spent 15 minutes trying to understand why I could not read my
GPIB controlled DVM, only to realise I'd connected the GPIB cable on the
Sun, but did not connect the other end to the DVM! Once that was sorted
out, I can read the DVM ok from a simple C program.

> Note that it will be a symlink to another /devices entry and
> that will be the one which you will have to chown. Actually, by
> default, mine is crw-rw-rw- so if you only need to access it, and don't
> have to worry about others trying to access it and conflict with what
> you are doing, you don't need to change anything.
>
> FWWI Mine has /dev/ecpp0 and does not have /dev/bpp0

Same here - /dev/ecpp0 but no /dev/bpp0

I think I have a recollection that bpp0 is for older machines - I
suspect my SPARC 20 has that.

>
>> My guess is that this will be very difficult to do, but I don't know.
>
> Not that hard, once you learn to use IOCTLs.
>
>> If anyone has any suggestions to how to get some TTL level signals from
>> a Sun I would be intersted. The Sun will have a GPIB board in it too,
>> but I cant find any cheap GPIB controlled switches.
>
> You could also pick up one of the older serial port chips
> (separate I/O buses and status bits) and send characters to it to set
> particular bits high or low. If you need a lot of them, use the 8 bits
> and decode them into 128 addresses and a bit for "set high" or "set
> low".
>
> Enjoy,
> DoN.
>

On 2008-03-18, Dave <foo@coo.com> wrote:
> DoN. Nichols wrote:
>
>>> Anyone know what would be involved to write to the parallel port so I
>>> can set the outputs to some precise values I want and keep them there
>>> until I want to change them?
>>
>> man bpp
>>
>> man ecpp
>>
>> Verify which is supported on your system.
>>
>> and pay particular attention to the IOCTLs documented.
>
> Thanks for that, although I still cant see how to do this from the ecpp
> man page. There are plenty of structures defined in that man page, but I
> don't see what actually writes the data. Perhaps I am being thick!

I haven't done it (yet) but I suspect that the IOCTLs are used
to set up which pins are input and which are output (except when
connected to a scanner where they get switched to a direction
appropriate for the moment), and then you can just do plain writes to
the port with a mix of bits specifying which pins are to be high and
which to be low, and your program has to remember the status for any
pins which you are not currently changing so it gets written the same as
it was. When you read you probably only get data from the pins which
are defined as inputs, and it either returns only a default value
(perhaps zero, perhaps one) for the pins defined as outputs, or simply
lets you verify the state of the output pins on the read cycles.

> We eventually found on eBay a GPIB controlled relay (actually 6
> reed-relays in a box) so bought a couple of them for $60 the pair. Since
> GPIB is going to be used to set up some test equipment, having a GPIB
> card is not excessive for this.

O.K.

> But I would like to know how to use the parallel port.

Well ... you're going to have to do some work (or perhaps find
some perl libs for the purpose) since we have more than exhausted my own
knowledge of the matter -- mostly going by memories of how the Motorola
6820 chips were used on my earlier systems and applying it to the IOCTLs
which are present in the system. Often, BTW, you'll find a lot more
useful information by reading the header files somewhere in the
/usr/include tree. A quick find run turns up four files to examine:

================================================== ====================
23:17:47 > find /usr/include -name ecpp\* -print
/usr/include/sys/ecppio.h
/usr/include/sys/ecppreg.h
/usr/include/sys/ecppsys.h
/usr/include/sys/ecppvar.h
================================================== ====================

>> And as long as nothing else has to use that port, chown it to
>> belong to a process which your program runs as and you won't have to run
>> it as root.
>
> Cheers. Nothing else needs to use it. I'm basically setting up a couple
> of Suns to just run the test equipment.
>
> I just spent 15 minutes trying to understand why I could not read my
> GPIB controlled DVM, only to realise I'd connected the GPIB cable on the
> Sun, but did not connect the other end to the DVM! Once that was sorted
> out, I can read the DVM ok from a simple C program.

:-)

What flavor of GPIB card -- sBus or PCI? I've got three sBus cards, but
can't afford the drivers from National Instruments. They are really in
love with those drivers -- they cost almost as much as the driver plus a
card together from them. :-)

>> Note that it will be a symlink to another /devices entry and
>> that will be the one which you will have to chown. Actually, by
>> default, mine is crw-rw-rw- so if you only need to access it, and don't
>> have to worry about others trying to access it and conflict with what
>> you are doing, you don't need to change anything.
>>
>> FWWI Mine has /dev/ecpp0 and does not have /dev/bpp0
>
> Same here - /dev/ecpp0 but no /dev/bpp0
>
> I think I have a recollection that bpp0 is for older machines - I
> suspect my SPARC 20 has that.

I've just checked, and one of my SS-5s running Solaris 2.6 has
that one. The other was on a Sun Blade 1000 -- somewhat newer and
faster. :-)

Enjoy,
DoN.

P.S. I appear to have you killfiled in rec.crafts.metalworking, but
I can't remember why, so I wasn't sure whether to reply or not.
:-)

--
Email: <dnichols@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Dave wrote:
> I want to control an electronic switch that needs a couple of TTL level
> signals. It is possible to use a Sun for this? I was thinking about
> programming the parallel port, which has in the past been used in PCs,
> but I'm not sure how easy it is on a Suns - I have a feeling it is not
> so easy.
>
> Suns available include a SPARCstation 20, Ultra 60 and Netra T1. Speed
> is not an issue and I dont mind sticking a transistor on the output if
> needed.

Dave,

As this is a standard Solaris device, the first place to look is the man
page for an open() and associated syscalls.

Assuming that it hasn't been locked by another process (print q,
whatever), you should be able to do an open() for a write, then write
single bytes to the port. Probably neeed get and set attributes calls as
well, to ensure you get raw data and no filtering. Keep a local copy of
the current value in your program. 'And' or 'or' to the local copy to
set or clear bits, then do a write to the port each time you change the
value. You may or may not get the printer strobe pulse as well, which
could be uesfull if you want to latch the data externally. It's easy to
test this by wiring 8 leds and series resistors across the port lines
and gnd to verify that the bits do in fact get set or cleared.

In short, just experiment - you are unlikely to do any damage to
anything and should only take a few 10's of minutes to write a quick
test program.

The best book for all this stuff is Stevens, "Advanced Programming in
the Unix Environment" - well worth the cost and probably cheap s/h on
ABE or Amazon...

Chris

----------------------
Greenfield Designs Ltd
Electronic and Embedded System Design
Oxford, England
(44) 1865 750 681