Has anyone modified the SED1335F driver to
remove or drastically reduce the flicker on the display when updating the
graphics display buffer?
I am using the driver with a Planar EL display
and because of the faster refresh rate of this type of display I am seeing a lot
of noise on the display during writing to it.
I have switched the animation off and also
disabled the direct plotting options but I still get a lot of noise. The noise
is only present during writes to the graphics buffer.
I know this is an issue with memory arbitration
on the S1D13305 controller but I am sure there must be a solution, possibly
using the BUSY flag in the status register (and Z-World already implement this,
but it still gives noise)
Short of redesigning with the S1D13700 which is
not yet available here, I would like to at least get something
working.
Regards
Dave...
--- Very funny Scotty, now beam down my
clothes.!! --- http://www.v8carlton.com http://www.embeddedcomputer.co.uk ---
Reply by Ernesto Tolocka●April 5, 20042004-04-05
Dave:
I wrote my own driver, reading the BUSY flag, but I still have the
flickering problem. Is it possible to eliminate it
completelly?
Below is part of my code. The LCD data bus is connected to PORTA of
RCM2020 board.
void LCDWriteCommand (char command) {
//Write a command
//A0=1 //RD=1 //WR=0
#asm
push af
ld a,0x80 ioi ld
(SPCR),a ;PORTA=input
ld a,(PEDRShadow) and 0xcf ;Baja A0 y CS or 0xc0 ;Sube RD y WR ; ld (PEDRShadow),a ioi ld
(PEDR),a
-----Mensaje original----- De: Dave McLaughlin
[mailto:d...@v8carlton.com] Enviado el: lunes, 05 de abril de 2004
8:46 Para: Rabbitsemi Asunto: [rabbit-semi] SED1335F
graphics controller driver causing noise on the display
Has anyone modified the SED1335F driver to
remove or drastically reduce the flicker on the display when updating the
graphics display buffer?
I am using the driver with a Planar EL display
and because of the faster refresh rate of this type of display I am seeing a lot
of noise on the display during writing to it.
I have switched the animation off and also
disabled the direct plotting options but I still get a lot of noise. The noise
is only present during writes to the graphics buffer.
I know this is an issue with memory arbitration
on the S1D13305 controller but I am sure there must be a solution, possibly
using the BUSY flag in the status register (and Z-World already implement this,
but it still gives noise)
Short of redesigning with the S1D13700 which is
not yet available here, I would like to at least get something
working.
Regards
Dave...
--- Very funny Scotty, now beam down my
clothes.!! --- http://www.v8carlton.com http://www.embeddedcomputer.co.uk ---
Reply by Kent Johansen●April 5, 20042004-04-05
Hi There.
I have experienced LCD displays picking up noise from the data bus.
All accesses NOT going to the LCD will cause stripes.
The solution is to buffer the data bus lines.
Kent
>
> Dave:
>
> I wrote my own driver, reading the BUSY flag, but I still have the
flickering problem. Is it possible
> toeliminate it completelly?
>
> Below is part of my code. The LCD data bus is connected to PORTA of RCM2020
board.
> void LCDWriteCommand (char command) {
>
> //Write a command
>
> //A0=1
> //RD=1
> //WR=0
>
> #asm
>
> push af
>
> lda,0x80
> ioild (SPCR),a;PORTA=input
>
> lda,(PEDRShadow)
> and0xcf;Baja A0 y CS
> or0xc0;Sube RD y WR
> ;ld(PEDRShadow),a
> ioild (PEDR),a
>
> ;lda,(PEDRShadow)
> and0x7f;Baja RD
> ld(PEDRShadow),a
> ioild (PEDR),a
>
> nop
> nop
>
> wbusy:
>
> ioild a,(PADR);Leer del LCD
> and0x40
> jr z,wbusy;Esperar a que suba busy (bit 6)
>
> lda,(PEDRShadow)
> or 0xA0;Sube RD y A0
> ld(PEDRShadow),a
> ioild (PEDR),a
>
> lda,0x84
> ioild (SPCR),a;PORTA=out
>
> lda,l;ele
> ioild (PADR),a;Escribir datos
>
> lda,(PEDRShadow)
> and 0xbf;Baja WR
> ld(PEDRShadow),a
> ioild (PEDR),a
>
> lda,(PEDRShadow)
> or 0x40;Sube WR
> ld(PEDRShadow),a
> ioild (PEDR),a
>
> pop af
>
> #endasm
>
> }
> Regards,
> Ernesto.
>
> -----Mensaje original-----
> De: Dave McLaughlin [mailto:dave@dave...]
> Enviado el: lunes, 05 de abril de 2004 8:46
> Para: Rabbitsemi
> Asunto: [rabbit-semi] SED1335F graphics controller driver causing noise on
the display
>
> Has anyone modified the SED1335F driver to remove or drastically reduce the
flicker on
> the display when updating the graphics display buffer?
>
> I am using the driver with a Planar EL display and because of the faster
refresh rate of this type of
> display I am seeing a lot of noise on the display during writing to it.
>
> I have switched the animation off and also disabled the direct plotting
options but I still get a lot of
> noise. The noise is only present during writes to the graphics buffer.
>
> I know this is an issue with memory arbitration on theS1D13305 controller
but I am sure there
> must be a solution, possibly using the BUSY flag in the status register
(and Z-World already
> implement this, but it still gives noise)
>
> Short of redesigning with the S1D13700 which is not yet available here, I
would like to at least get
> something working.
>
> Regards
> Dave...
> ---
> Very funny Scotty, now beam down my clothes.!!
> ---
> http://www.v8carlton.com
> http://www.embeddedcomputer.co.uk
> ---
>
> click here
>
>
> Yahoo! Groups Links
> * To
>
--
Anakron Canada Inc. / Kent Johansen, Cand. Polyt. M.Sc.
Suite 640, 580 Hornby Street
Vancouver, British Columbia V6C3B6, Canada
Office: +1 604 642 0663 Cell: +1 604 728 3348
Reply by Dave McLaughlin●April 5, 20042004-04-05
Hi Kent,
There is no noise unless I am accessing the device so noise on the databus
in this case is not the issue.
----- Original Message -----
From: "Kent Johansen" <kent@kent...>
To: <rabbit-semi@rabb...>
Sent: Monday, April 05, 2004 4:26 PM
Subject: RE: [rabbit-semi] SED1335F graphics controller driver causing noise
on the display
> Hi There.
> I have experienced LCD displays picking up noise from the data bus.
> All accesses NOT going to the LCD will cause stripes.
> The solution is to buffer the data bus lines.
> Kent
Reply by zekillian●April 5, 20042004-04-05
Hello,
Here's a few parameters that you can try adjusting in the low-level
driver (SED1335F.LIB) to assist in meeting the timing requirements of
your graphic interface:
1. The TCYC_DELAY macro is set for a R2000 CPU running at 22.1Mhz, if
your CPU is running at a higher CLK rate, you may need to increase the
nop's in the macro to meet the I/O cycle to cycle timing of SED1335F
chip. (Refer to SED1335F data sheet)
2. In the _glInitLCDChip routine change the TC/R parameter, bump x1
until the desired screen result is obtained, try values from 47 to
64.
(Help's to eliminate flickering)
3. You can change the number of bytes to be written during the Horz
line retrace period. (i.e. The OP7100 products has time only to do 2
bytes whereas the OP7200 can do 4 bytes)
The code for the above is located below the mem_wait TAG in the
glSwapData routine. Remove/add the following section of code if
needed: (Must have an even number of bytes due to driver
implementation)
TCYC_DELAY // Write 1 Byte
ioe ldi
dec e
TCYC_DELAY // Write 1 byte
ioe ldi
dec e
Regards,
Ed Killian
Firmware Engineer
--- In rabbit-semi@rabb..., "Dave McLaughlin" <dave@v...>
wrote: > Has anyone modified the SED1335F driver to remove
or drastically reduce the flicker on the display when updating the graphics display
buffer? >
> I am using the driver with a Planar EL display and because of the faster refresh rate of this type of display I am seeing a lot of noise
on the display during writing to it. >
> I have switched the animation off and also disabled the direct plotting options but I still get a lot of noise. The noise is only
present during writes to the graphics buffer. >
> I know this is an issue with memory arbitration on the S1D13305 controller but I am sure there must be a solution, possibly using the
BUSY flag in the status register (and Z-World already implement this,
but it still gives noise) >
> Short of redesigning with the S1D13700 which is not yet available here, I would like to at least get something working. >
> Regards
> Dave...
> ---
> Very funny Scotty, now beam down my clothes.!!
> ---
> http://www.v8carlton.com
> http://www.embeddedcomputer.co.uk
> ---
Reply by Dave McLaughlin●April 6, 20042004-04-06
Thanks Nathan,
I have noticed that the latest buffered version
is much better. My main problem is that the EL display has a
<1ms display response rate so any flicker is very noticable. I am
also now setting the buffer lock during updates and unlocking when all updates
are done. This has reduced the flicker somewhat.
I think I may well be stuck with some flicker
and I am actively looking at designing around the new Epson S1D13700 as this is
software compatible and the arbitration bug is fixed too as far as I am lead to
believe. My problem at the moment is getting a device as they are about 10 weeks
away from stock.
I don't have any tri-state buffers as I
don't have any other device on the bus. I am using the RCM3000 core module
with the external bus enabled. I have also tested access to other locations on
the external bus and there was no noticable noise on the display from
that.
Regards
Dave...
--- Very funny Scotty, now beam down my clothes.!! --- http://www.v8carlton.com http://www.embeddedcomputer.co.uk ---
----- Original Message -----
From: Nathan Johnston
To: 'r...@yahoogroups.com'
Sent: Tuesday, April 06, 2004 1:15
AM
Subject: RE: [rabbit-semi] SED1335F
graphics controller driver causing noise on the display
I have done a fair bit
of work with the SED1335F using both ZWorldsgraphics.lib & SED1335F.LIB and also with separate
drivers which someone had worked on prior to the project being passed onto me.
Both take fairly different approaches to writing to the lcds graphics layer with a big difference in the amount of
flicker.
Project A using Zworld libraries: I did a lot of separate writes to the
screen (plotting individual pixels for graphs etc), and the flickering was quite
noticeable:
Project B: The software
was already half complete, so I had to continue using the approach that had
already been used and it turned out to be pretty good. They are buffering the
whole graphics layer in the rabbit, and updating the whole graphics layer in one
hit (rather than doing heaps of setpixels). The flickering from this approach much less
noticeable.
Both approaches were
using tri state buffers on the data bus so no issue
there...
