I have built a light organ device¹ to be connected to PC paraller port. The
shematic is pretty simple: there are 8 lamps which are controlled via
datalines of paraller port, i.e. one lamp per dataline. The device works
fine; if I boot from a DOS boot floppy, I can succesfully control lights by
writing data to paraller port, i.e. outportb(255, 0x378) switches all the
lamps on. I think this is clear to everyone.

The weird thing: when I boot into Linux, kernel itself seems to write some
"random" data to paraller port (by "random" I mean that lamps are flashing
very quickly (at 1-5 hz) and I can't see any sequenses in the data, but I
guess it's not actually random data). That makes the lamps flashing all the
time, and I'm unable to control them by outb() function. In other words, my
data sent to 0x378 gets overwritten immediately and I can't see any effect
on the lights. Use of the following code...

while(1) {
outb(0, 0x378);
}

.... causes lamps not to flash as much as normally, but that kind of code
doesn't make sense of course.

Ok, I thought there's some Plug'n'Play or parport stuff loaded or compiled
into the kernel, and maybe linux is polling printer or something. So, I
disabled Plug'n'Play and parport support and rebooted - what the h*ck,
lamps were still flashing. I even tried to compile very minimal kernel
without any optional stuff - no help. The same problem occurs with kernels
2.4 and 2.5 (however, I'm not able to test early 2.4 releases since they
can't be compiled with gcc 3.2). When I booted from Debian potato
installation CD which uses kernel 2.2, there were no flashing (I couldn't
run outb() test program because 2.2 had no support for ReiserFS, but I
guess everything would have been worked).

How can I be sure it's Linux kernel which is "interfering" paraller port?
Well, flashing starts immediately when kernel loads and boots, *before*
/sbin/init is started. So any daemon can't be causing the problem. It's
hard to say when exactly flashing starts, since kernel boots so fast.
Anyway, dmesg doesn't print any parport related messages, so I'm reeeally
confused about this problem. Any help is welcome, I'm specially interested
to hear if someone has succesfully controlled some DIY parport devices with
2.4 kernel.

Btw, neither BIOS parport mode (SPP etc.) nor BIOS Plug'n'Pray settings
solved the problem.

My machine has ECS K7S5A motherboard and I'm using Gentoo Linux
distribution.


¹) http://www.na.linux.hr/projects/xplsisnjasp/

--
Jaakko Holster
/* Student of Information Engineering, University of Oulu
Yliopistokatu 38 as 733, FIN-90570 Oulu
yaggo at ee oulu fi +358 41 436 0880 */

Report this post to a moderator

Jaakko Holster wrote:
> I have built a light organ device¹ to be connected to PC paraller port. The
> shematic is pretty simple: there are 8 lamps which are controlled via
> datalines of paraller port, i.e. one lamp per dataline. The device works
> fine; if I boot from a DOS boot floppy, I can succesfully control lights by
> writing data to paraller port, i.e. outportb(255, 0x378) switches all the
> lamps on. I think this is clear to everyone.
>
> The weird thing: when I boot into Linux, kernel itself seems to write some
> "random" data to paraller port (by "random" I mean that lamps are flashing
> very quickly (at 1-5 hz) and I can't see any sequenses in the data, but I
> guess it's not actually random data). That makes the lamps flashing all the
> time, and I'm unable to control them by outb() function. In other words, my
> data sent to 0x378 gets overwritten immediately and I can't see any effect
> on the lights. Use of the following code...
>
> while(1) {
> outb(0, 0x378);
> }
>
> ... causes lamps not to flash as much as normally, but that kind of code
> doesn't make sense of course.
>
> Ok, I thought there's some Plug'n'Play or parport stuff loaded or compiled
> into the kernel, and maybe linux is polling printer or something. So, I
> disabled Plug'n'Play and parport support and rebooted - what the h*ck,
> lamps were still flashing. I even tried to compile very minimal kernel
> without any optional stuff - no help. The same problem occurs with kernels
> 2.4 and 2.5 (however, I'm not able to test early 2.4 releases since they
> can't be compiled with gcc 3.2). When I booted from Debian potato
> installation CD which uses kernel 2.2, there were no flashing (I couldn't
> run outb() test program because 2.2 had no support for ReiserFS, but I
> guess everything would have been worked).
>
> How can I be sure it's Linux kernel which is "interfering" paraller port?
> Well, flashing starts immediately when kernel loads and boots, *before*
> /sbin/init is started. So any daemon can't be causing the problem. It's
> hard to say when exactly flashing starts, since kernel boots so fast.
> Anyway, dmesg doesn't print any parport related messages, so I'm reeeally
> confused about this problem. Any help is welcome, I'm specially interested
> to hear if someone has succesfully controlled some DIY parport devices with
> 2.4 kernel.
>
> Btw, neither BIOS parport mode (SPP etc.) nor BIOS Plug'n'Pray settings
> solved the problem.
>
> My machine has ECS K7S5A motherboard and I'm using Gentoo Linux
> distribution.
>
>
> ¹) http://www.na.linux.hr/projects/xplsisnjasp/
>

Just a mad idea - have you got pull-up resistors on the inputs to
your circuit? I am not quite sure, but it is possible that the
data lines are floating because the port was switched to tri-state
(Bit 5 in control register).

BTW, hijacking the port with outb is a bad idea. Have a look at the
parport driver hierarchy, you can do whatever you like by using the
driver only.

Kind regards,

Iwo

Report this post to a moderator

>> The weird thing: when I boot into Linux, kernel itself seems to write

>> some "random" data to paraller port (by "random" I mean that lamps are
>> flashing very quickly (at 1-5 hz) and I can't see any sequenses in the
>> data, but I guess it's not actually random data). That makes the lamps
>> flashing all the time, and I'm unable to control them by outb() function.

> Just a mad idea - have you got pull-up resistors on the inputs to
> your circuit? I am not quite sure, but it is possible that the
> data lines are floating because the port was switched to tri-state
> (Bit 5 in control register).

With my knowledge there's no need for pull-up resistors, because paraller
port data pins are connected to optocoupler's input pins. Though I'm not an
electronic guru Playing with control bit 5 didn't solve the problem.

The circuit in ascii format: (as I told, this works from DOS boot floppy)

opto
+-----+
data 0 o---------\/\/\----------| |---------
LPT 1 kohm in | | out 230V stuff
ground o------------------------| |---------
+-----+

Better picture available at
http://www.na.linux.hr/electronic/x...sp/LPT-show.png


> BTW, hijacking the port with outb is a bad idea. Have a look at the
> parport driver hierarchy, you can do whatever you like by using the
> driver only.

I know there are better ways than user-space outb, but in this stage I just
want to get this damn thing working ))

(...soon gonna give up and build an old P100 machine for mp3 playing &
driving light organ. (who would sell me an old ide harddisk?))

--
Jaakko Holster
/* Student of Information Engineering, University of Oulu
Yliopistokatu 38 as 733, FIN-90570 Oulu
yaggo at ee oulu fi +358 41 436 0880 */

Report this post to a moderator