Post by Martin CoriaHello,
Have anyone successfully interfaced a Coldfire
MCF5272, MCF5282 (or similar) to an Epson S1D13505 or S1D13506 LCD controller?
We did interface a couple of different Coldfire
chips to a couple of Epson LCD controllers. The
details are really fuzzy for me (that project
ended years ago), but I searched my old email
messages and quoted some of them below. Many of
them were sent to this mailing list or were
followups to messages sent to this list; you
might be able to dig up some more info in the
archives. I searched for the file attachments
referred to in the email messages but couldn't
find them any more, sorry. Maybe someone I sent
them to still has a copy (search for a filename
containing "DOC050503" or
"sed1355.pdf"). Hopefully the email messages
will have something helpful. As I recall, the
trick was dealing with the /TA line, as the Epson
chip sometimes responds very slowly.
Steve
-------------------
I have received a lot of requests for information
about how we interfaced the Epson/S-Mos SED1355
LCD driver chip to the 5206e. We had problems
getting the Dallas Semiconductor delay chip we
first designed in and had to do some mods to
patch in another chip, but we have a new board
revision that works without any mods. I have
uploaded the relevant pages of the schematic to
http://www.link-comm.com/sed1355.pdf (link is now broken)
The board is set up to handle either the SED1355
or SED1356, although we haven't tested the
SED1356 yet. It is also set up to drive either
color or monochrome LCD panels, but we have only
used it with monochrome so far (we plan to test
color within the next few weeks - monochrome VGA
panels are getting hard to find). The VGA/CRT
output works reasonably well (we have only used
640 by 480 resolution), but I wouldn't want to
use it for my primary display as the image isn't
as steady as a normal computer video card
produces. That might be caused by how we have
the chip set up or something in our layout, so I
can't say for sure that it is the chip's
fault. I will be glad to answer questions about
the design if I can. If anyone has suggestions
about ways to improve it, I would like to hear about those too.
----------------------
We have used the Epson/Smos SED1355 with a 5206e
with 640x480 monochrome and color (TFT) LCD
screens. The interface didn't take much
glue; just a delay on the read line and a couple
of logic gates as I recall (please let me know if
you need details). We are planning to use a
Epson S1D13706 on a new 5272 design we are working on.
-----------------------
The SED1355 supports split LCD panels (most
full-VGA panels are organized like two smaller
panels stuck together, top half and bottom half,
which are updated at the same time), uses
external memory and supports external VGA
monitors with very little additional hardware
(the SED1356 is better yet for driving external
monitors). I don't know much about the S1D13706
yet, but I think it is intended for smaller LCD
displays, has built-in memory for the framebuffer
(which limits the amount of memory) and probably doesn't support split panels.
---------------------
On an earlier project we used an Epson/Smos
SED1355 (very similar to the 1356) with a
MCF5206e Coldfire to drive a 640x480 (VGA) LCD
panel. The interface wasn't quite glueless (we
used a delay line), but it wasn't too bad. On
our current project, we are using an Epson
S1D13706 with a MCF5272. We have it working with
a 160x160 monochrome display and are working on
switching to a 240x320 color display. We are
using one logic chip to generate the /TA signal
for the Coldfire from the busy lines of the LCD
driver and a backplane, so that interface isn't
bad either (although we are depending on an
unspecified timing value when the S1D13706 drives
its busy line inactive). Let me know if you need
more information about either interface.
----------------------
Post by Martin Coriai had little problems with my framebuffer driver. on bootup uclinux the
systems hangs somtimes after initializing the s1d13806....
What happens when it hangs? Is there a chance it
is a problem with the /TA timing rather than a
software problem? When using the S1D13706 with a
MCF5272, we found that the S1D13706's busy line
didn't go active quickly enough to de-assert the
Coldfire's /TA (we had it gated with the chip
select), so we changed to an active high wait
signal, put a pullup on it, and now rely on the
S1D13706 driving the busy line inactive (low)
when it goes inactive. I can't find a timing
specification for that, but it seems to
consistently drive low for 50nS, which the
Coldfire seems to consistently recognize (though
it would be better if it stayed active until the CS was de-asserted).
---------------------
Note that the CLKI frequency you use will affect
what frame rates are available. You might want
to run the numbers for your display resolution
and make sure you can get a frame rate close to
the max allowed for that display (hopefully 60Hz
or higher). If you can't find a combination that
works with BUSCLK/2, you might want to add a
separate clock for CLKI (the timing is even more
critical if you use the LCD driver to also drive an external VGA monitor).
Steve
At 09:22 AM 7/19/2004 +0200, you wrote:
Thanks for your help. What I coud do is to divide the BUSCLK by a factor of
2 and then feed the BUSCLK of the SED1355, and then use an oscillator of
25MHz for driving the CLKI.
Best regards
G. Guenzati
-----Messaggio originale-----
Da: ***@lists.wildrice.com [mailto:***@lists.wildrice.com]Per
conto di Arduini, David [LBRT/LNA]
Inviato: domenica 18 luglio 2004 17.45
A: ***@tiscali.it
Oggetto: [ColdFire] RE: Coldfire and Graphic Display Interface
I am not familiar with the 13505, but have looked at using the S1D1700,
S1D1705, but they are each very different. Although I can tell you this:
They sometimes have a big or little endian setting in the HW setup that
affects ho your ctrl signals work.
Also, generic mode max speed is 50Hz, so you can't use your CLKOUT unless
you slow it down. The alternative is to use a separate crystal or osc. for
the Epson part, or if you use an osc on the 5282, it could be shared, but it
may be too slow for your display. The frame clock for the display is
relative to the input clk to the Epson ctrl'ers (divide by x). On some
parts, the M68k mode is slower, and is only suitable for the older 68k
family and not ColdFire.
The Epson parts are not very easily understood from the datasheets, but
there are tools and advice available from Epson if you need more info.
Dave
Post by Martin CoriaSubject: R: [ColdFire] Coldfire and Graphic Display Interface
Date: Sat, 17 Jul 2004 17:47:14 +0200
Thanks Lon, this is what I thought could be right, but the application note
from Epson (x31bg010.pdf) is connecting just the opposite way.
One more question if you can answer. My MCF5282 is running at 64MHz. Can I
connect the BUSCLK output from the MCF5282 (still at 64MHz) or the 13505
cannot run more than 50MHz on the BUSCLK input?
Best regards
G. Guenzati
-----Messaggio originale-----
conto di Lon Hemmen
Inviato: venerdì 16 luglio 2004 17.28
Oggetto: RE: [ColdFire] Coldfire and Graphic Display Interface
I can't say for the 5282 but we use the 13505 with the 5307 and use Big
Endian with Generic Bus Interface
MCF5307 S1D13505
/BWE0 /WE1
/BWE1 /WE0
Lon
-----Original Message-----
Sent: Friday, July 16, 2004 09:12
Subject: [ColdFire] Coldfire and Graphic Display Interface
Can anybody give me a help?
I'am trying to interface the MCF5282 with a S1D13505.
Regarding the bus interface, I must configure the S1D13505 as
a Big Endian interface and Generic Bus Interface. In this
condition what is the right connection?
M5282 S1D13505
/BS3 /WE1
/BS2 /WE0
or
M5282 S1D13505
/BS2 /WE1
/BS3 /WE0
I would be really thankful for help. I think that if somebody
has interface an EPSON 13706 with a MCF5272 has faced this problem.
Cordiali saluti
G. Guenzati
---------------------------------
You were planning on using the TA (Transfer
Acknowledge) line on the CF to terminate the bus
cycle, weren't you? It is true that reads can
take a very long time when the display chip is
reading the memory for the purpose of updating the display.
I really need to get you a copy of our
schematic. I don't have it in electronic
form. What is the easiest way for me to do that?
---------------------
We are using a 240x320 (portrait) LCD display
with a MCF5272 using a Epson/Smos S1D13706 LCD
driver chip. We are relying on undocumented
timing to assert the /TA (transfer acknowledge)
line, but it seems to work fine (see the archive
or email me if you need more info about
that). If you can set it up so you don't need to
read back from it much, its performance is fine
(for a non-accelerated chip). If you need to do
a lot of reads (such as overlaying text on an
existing image when using less than 8bpp), it can
be very slow. If you don't need to have the
framebuffer memory integrated onto the chip, it
wouldn't be too hard to duplicate its
functionality in an FPGA. If you plan to drive
it with a clock source you already have in the
design, make sure you can hit an acceptable frame
rate. Or leave a pattern on the PCB to add a
dedicated clock source if that later turns out to
be necessary (there is more than one clock input
pin, selectable with software).
--------------------
Post by Martin CoriaSteve,
Thanks very much for your response,
and yes, I would greatly appreciate if you
could check your notes, last thing I need is to
come across some undocumented beheaviours.
I just scanned my notes (many pages) and am
attaching them as a PDF. Some of them concern
earlier designs that we didn't end up using, but
I didn't take the time to sort through them and
pull just the ones relevant to the final
design. The schematics (also attached) are the final design.
One thing I remembered as I looked through those
notes was that the reason we use the /WAIT line
in an unconventional way is because it didn't
switch quickly enough after the chip select went
active to keep the Coldfire from immediately recognizing /TA.
Post by Martin CoriaAnd I would be indebted if you can help with the
S1D13706 LCD hardware interface design. We want
to be able to interface to mono and color qvga
LCDs. Need to know how to design interface to achieve this.
We are using a QVGA display in portrait mode, but
had to add a chip to rotate the output of the
S1D13706 as it would only support our display in
landscape mode. I can dig up details on that if
you need it. The setup program for the S1D13706
(available from Epson for free) will let you play
with the timing constraints and see if you can
get a combination that works with your display.
Post by Martin CoriaWe have been planning to use a Netburner module,
but we are not entirely happy with what any
particular module can offer us. They all seem
to be just borderline, either memory, or chip
selects, or address lines or serial ports. They
all force us into compromises we would prefer not to have to make.
We used a module from Cogent (the CSB360) for
development, and modeled our custom hardware
after it. It is a nice board, with two possible
caveats. We managed to accidently erase and/or
lock flash sectors a couple of times. We have a
background-mode debugger, so we were able to fix
it ourselves. The brand of flash used on that
board uses a lock/unlock sequence that is easy to
do accidently if you go off "picking daisies" (as
our code often did when we were first getting
started). I don't know whether or not it would
be a problem in a production environment where
the code is stable. The other thing is that I
think the LCD controller is wired funny on that
board. There is a copy of an email message I
sent to Cogent about that included in the notes I am attaching.
Post by Martin CoriaThe ideal would be to do our own board, but we
are an applications company(we make machines),
we dont have the time or expertise for the
electronics, not at this level at least. Hence
we are looking for a module that has the cpu, memory and Ethernet as a minimum.
Another advantage of using a pre-made board is
that you may be able to use its boot monitor to
run your code, and not have to bring up your own
monitor. The CSB360 comes with MicroMonitor
preinstalled. MicroMonitor lets you set up
scripts that run automatically on startup, and
knows how to expand elf files (strip the debug
info to keep the size reasonable) directly into memory and run them.
P.S. I attached the PDF of notes to a separate
message. It is over 7MB and I didn't want everything to bounce if it did.
----------------------------------
I have just begun a design in which I need to
connect an Epson S1D13705 LCD controller to a
MCF5272. I have provided a table of the
interconnects between the two ICs. Epson has a
reference for connection to a 5307 which is the
basis for how I have interconnected. Has anyone
done this? Any feedback on this interface is
appreciated. I have the S1D13705 configured in
Generic 16bit bus mode #1 interface.
MCF5272 S1D13705
D[16-31] DB[0-15]
A[0-16] AB[0-16]
SDCLK BCLK
!TA !CS && !WAIT
!OE !RD
!OE RD/!WR
!CS4 !CS
DQM1/-BS0 !WE0
DQM1/-BS0 !WE1
!RESET_OUT !RESET
My biggest area of concern is connection of the
address bus and byte strobes. (A0 -> A0)?
Thanks for any insight/experience.
Brian
-----------------------
Post by Martin CoriaSteve,
Thank you very much! After glancing at your
schematics and notes I have a couple of quick
thoughts/questions if you don't mind.
- In your circuit for TA# generation from the
13706 WAIT# signal, where does the RDY signal come from?
It is generated by combining the signal from
several DSPs that are connected to the Coldfire's data/address bus.
Post by Martin CoriaIn my design, the 13706 is the only device
which will require external TA. Therefore my
intent was to use a tri-state inverter to
create TA#, with CS driving the output enable
and WAIT going to the input. Any thoughts?
I don't see why it would need to be tri-stated,
since the TA# pin on the Coldfire is always an
input (as I recall). If the output of the Epson
chip is ever pulled to the other logic state by a
resistor rather than an active driver, I think
buffering it as close as possible to the chip (to
minimize trace capacitance and therefore
rise/fall time) is a good idea. On an earlier
project we did with a 5206e Coldfire and a
different Epson LCD controller, we didn't gate
the TA# with CS and didn't have problems, but it
sure can't hurt. The primary problem I can
remember dealing with on the design we sent to
you was that the WAIT signal didn't go active
soon enough to deassert TA (it took about 15nS),
so the Coldfire terminated the bus cycle before
it even knew it was supposed to wait.
Post by Martin Coria- In your email to Cogent, you discuss the
connections of -BS0 to -WE1 and -BS1 to
-WE0(backwards). Could this not have been
addressed with the CNF4 pin on the 13706 which
sets the endian-ness of the databus?
I don't think that the problem is with the
connection of the data lines, but that the BS/WE
line that corresponds with each byte is connected
for the other byte. In other words, if doing a
byte-wide transfer on the lower byte, it would
signal that it was doing it on the upper
byte. Swapping the endianness would mess up 16-bit transfers.
Post by Martin Coria- Have you connected an LCD panel to this design yet?
Yes, it is in production.
Post by Martin Coria- From what I can discern from the Epson
datasheet on the S1D13706, in Generic#1 16bit,
the max CLKI frequency for 3.3Volt operation is
50MHz. It appears you are clocking at
66MHz. Is this an issue or am I misreading?
I can't remember. I remember there being
something about an internal frequency divider,
but I don't know if that addresses the spec or not.
Post by Martin Coria- What LCD panel(s) did you intend on using? My
customer is looking at an Optrex unit that has
two power supplies, one spec'd for 3.3V and the
other at 5V. It looks like Vil and Vih are reference to the 5V.
I can't remember, but it isn't Optrex. Ours is a
landscape display that we are running in portrait
mode by using another chip between the Epson
driver and the display to effectively rotate
it. Not a really nice design, but it seems to work.
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:***@link-comm.com
---
***@wildrice.com Send a post to the list.
coldfire-***@wildrice.com Join the list.
coldfire-***@wildrice.com Join the list in digest mode.
coldfire-***@wildrice.com Leave the list.