[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Why waiting on the parport?


In manual mode it is not necessary to wait for tr_rdy. 
The problem may be caused by e.g.:

1. The parallel port is not in manual mode
2. The force bit in PARX_CONFIG is not set
3. Some other driver (e.g. the normal parallel port
driver) is interfering with your driver. Make sure that
the parallel port is disabled in kernelconfig.

Examples for manual mode can be found in the pardata and
the lcd driver in the elinux distribution.

Send me the code and your kernelconfig if the suggestions
above doesn't help.


-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com]On">mailto:owner-dev-etrax@xxxxxxx.com]On
Behalf Of Jonas Aaberg
Sent: Monday, May 14, 2001 1:44 PM
To: dev-etrax
Subject: Why waiting on the parport?


I've been trying with transfearing data over the parport1
on the Etrax 100LX, and I've noticed on a logical analyser 
that the parport1 sometimes misses commands, when I just set
*R_PAR1_CTRL_DATA lower 8 bits. But if I look if bit 17
in the *R_PAR1_STATUS_DATA register first and see if the
port is ready for transfear. Then it becomes correct.
But with this method I lose about half of the transfear
rate I had without any error checking.

With this as my inner loop I need 280ns per cycle, but if
#define EC 1, I need 700ns per cycle.

#define RW 17
	for (i = 0; i < c; i++) {
			lcd_s_par1_ctrl_data &= ~0xff;

#ifdef EC
			for(;(*R_PAR1_STATUS_DATA & (1 << WRITE_READY))!=(1<<WRITE_READY););
			*R_PAR1_CTRL_DATA = lcd_s_par1_ctrl_data =
			    lcd_s_par1_ctrl_data | (unsigned int)
#ifdef EC
			for(;(*R_PAR1_STATUS_DATA & (1 << WRITE_READY))!=(1<<WRITE_READY););

			*R_PAR1_CTRL_DATA = lcd_s_par1_ctrl_data =
			    (lcd_s_par1_ctrl_data & ~(1 << RW));

#ifdef EC
			for(;(*R_PAR1_STATUS_DATA & (1 << WRITE_READY))!=(1<<WRITE_READY););

			*R_PAR1_CTRL_DATA = lcd_s_par1_ctrl_data =
			    lcd_s_par1_ctrl_data | (1 << RW);

So my questions are, why is it like this? Why do I have to wait?
(Just for curriosity.) And is all those error checks nessecary?
Does someone have any ideas of speed improvments?


Jonas Aaberg               Email: aberg@xxxxxxx.ch
Supercomputing Systems AG  Web:   http://www.scs.ch
Technoparkstrasse 1        Phone: +41 (0) 1 445 16 00
CH-8005 Zuerich            Fax:   +41 (0) 1 445 16 10