LCD interface with DSK TMS320C6713

What you should always do in such circumstances is to obtain the datasheet for the peripheral device and study it until you thoroughly understand how the device works and what its pins do.

Pins RS, R/W, and E must be used to coordinate reading and writing between the DSP and the device.  The data being read or written will be on the D0..D7 lines.  In order to support other devices on the external data bus, for example the FLASH ROM that is on the DSK, you need to attach the address lines to a uniquely chosen address, implemented using a pattern-matching circuit (look up SN74AHC138 to get started) and assert the device-enable pin (presumably pin E) *only* when the specific device address is present on the EA* lines.  If RS stands for "read strobe" it may be necessary to devise a one-shot to convert the normal DSP/EMIF use of the RE, OE, WE, etc. lines on the external bus (transmitted from the DSK to the daughterboards via the two 80-pin connectors for peripheral control and data/address) to the specific logic signal sequence needed by the device.  You might be able to kludge that by using carefully chosen address lines as you suggested.  Vdd, Vee, Vss have specific requirements that must be found from the device data sheet.  For some devices you could assign them the way you have them, but for others you might need different voltages.  Also, the bus signals (WE, ED*, etc.) on the DSK are normally 3.3V, although I think the DSK used "5V-tolerant" buffer chips.  If your device needs 5V logic signals then you will need to use 3V/5V translation buffers.  You don't want to use "just wires" for the interconnection; in order to reliably add an external peripheral device that uses the bus signals, it must be on a printed-circuit daughterboard connected via the 80-pin connectors.  In another thread about a month ago I suggested an alternate supplier for those connectors, which are often not in stock at the usual component suppliers.

The last time I needed an LCD, I bought a "serial-enabled LCD" from SparkFun and accessed it via a serial port (similar to McASP) just like a traditional ASCII computer terminal.  That way somebody else had already done the work of building and programming the low-level LCD interface (using on on-board PIC microcontroller), and all I had to do was to send serial messages to it for display.  (The firmware also supported control codes to clear the display, move the cursor, etc.)

Hi, 

Thanks for your informative reply. Just to confirm, would I require an additional micro controller to communicate with the LCD? 

Referring to ".... If RS stands for "read strobe" it may be necessary to devise a one-shot to convert the normal DSP/EMIF use of the RE, OE, WE, etc. lines on the external bus (transmitted from the DSK to the daughterboards via the two 80-pin connectors for peripheral control and data/address) to the specific logic signal sequence needed by the device.  ..."

I thought LCD's usually come with a microcontroller or LCD driver ( are they the same?) ie HD44780 OR KS0066U. 

IF a micro controller is needed. So the confugration goes as..

DSK > Daughtercard connected to J4 EMIF > Microcontroller > LCD ?

Apart from that, i checked the "serial enabled LCD" from sparkfun. Is it any good? I read on forums and apparently its no good with backlight on? Or if im correct, the problem is only when using the LCD with an arduino microcontroller. If so, what alternatives are there?

cheers

Without spending time studying the specific device datasheets, I can't give detailed instructions.  As to microcontrollers, there are general-purposes ones (e.g. Atmel or PIC) and specialized LCD controllers.  You still would need a way for the DSP to communicate with whatever controlling device you use, and perhaps some interface logic circuitry.  If the LCD is to be accessed as an addressable peripheral device (using the external memory/address/control busses), then it is likely that you need some address-decoding logic to avoid having your LCD interface respond to data accesses that are not intended for that device.  It is conceivable that accessing the E, R/W, etc. pins as specific, carefully chosen, EA lines will work, if your DSP program performs suitable accesses in the proper order, but that is not the usual nor a recommended way to access an external device.

An alternative approach is to communicate with an external device via a serial port, if the device is designed for that sort of interface.  Some LCD controllers probably are suitable for that kind of interface.  I recently used the SparkFun serial-enabled LCD in a keypad-based user interface, with a PIC microprocessor (separate from the one on the SparkFun LCD card) running the whole application, and communicating with the serial-enabled LCD using one of the PIC's USART subdevices.  One could substitute a TI DSP for the PIC and follow the same procedure.  We didn't have any problems with the SparkFun device; the backlight intensity is programmable, but we left it at maximum brightness since power consumption was not an issue for us.  There is nothing about the SparkFun serial-enabled LCD that should be Arduino specific.

Hi, 

Just some quick questions,

I am using this LCD module http://www.pmb.co.nz/downloads/lcd_204a_series.pdf    (parallel interface)

It has a KS0066U LCD driver http://www.datsi.fi.upm.es/docencia/Micro_C/lcd/ks0066u.pdf

I wish to connect this to DSK320C6713. Would I require an additional microcontroller? From the previous post, I seem to require a daughtercard, could you link me up to some daughtercard options? I am really new to these software and hardware. 

So are my hardware connections are as below?

DSK > daughtercard > LCD

What is a recommended way to access an external device?

many thanks!

Jason,

Why are there two similar threads going for this? Are they looking at different issues?

What are you trying to do here? Do you need the DSP power of the C6713 with an LCD display added, or do you need to drive an LCD screen and happen to have a C6713 board available?

There is no need for a microcontroller (MCU) between the DSP and the LCD, but you will need some logic since the LCD display does not use the exact same signalling protocols. One of the prototyping daughter cards would work easily for this, but I doubt you will get it all done for a really low price (< US$90).

If you just need a processor that can drive an LCD display, then take a look at the TI MCU products and their development boards. The MSP430 line of ultra low-power processors has a three experimenter boards that include on-board LCDs, and one of these boards is only $99 for the whole board (see the choices here). The TI Stellaris ARM Cortex-M3 line of MCUs has a broad array of EVMs, Development Boards, and Reference Designs, some of which include 3-color graphic LCD panels and the processing power to drive those with useful information (see the choices here)..

So, depending on what you need to do, TI has different options available. But if what you really need to do is to learn how to connect D1 to D1 and connect two electronic devices together, then Douglas' advice is the final answer: studying the datasheets and learning the interface signals.

Regards,
RandyP

Hi, sorry for the confusion. It's cause I am new to all this too.

Basically, my project is based on a TMS320C6713 DSK. I require to interface a 20x4 alphanumeric LCD (parallel interface) with the DSK. I have read the data sheets of the DSK and the LCD and am able to understand to a certain extent. 

I read from a different post http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/37973.aspx#132694 that connects a FGPA to the LCD.

I read that FGPA is RAM based and loses its function programmed once the power goes off. I also guess that FGPA is an additional chip that I have to buy and hardwire to the DSK.

Alternatively, would the CPLD (provided on the DSK) be appropriate ? I found this youtube link that does it http://www.youtube.com/watch?v=277OJ2eIotA

Both FPGAs and CPLDs must be programmed ("burned") specifically for the application, which means that first you must design the logic functions for that device (using a development environment like Altium), and you will need support circuitry for those chips anyway, so we're back to designing a daughterboard.  The DSK's own CPLD is already fully programmed for a few specific logic functions, which do *not* include any support for an LCD.  If you have an LCD controller with a serial interface (typically SPI or I2C) then you can use the McBSP to communicate with the controller, following the serial protocol described in the controller's datasheet.  If you have an LCD controller with only a parallel interface (for communicating with the controller, not the LCD itself), then you must devise suitable logic to communicate with it using the DSP's EA*, ED*, WE, etc. bus lines, which in general is a non-trivial undertaking.  (In the original posting, it sounded like somebody had suggested a method of directly using the bus signals with no additional ("glue") logic, which would be very unusual but not necessarily impossible.)  I will attach a Microsoft Word-formatted document that describes the kind of interfaces that can be used for external DSP peripheral interfacing; some of what it says is specific to our own application, but much of it is generally applicable.

It sounds to me that you are in over your head, and should seek assistance from some local expert who can work interactively with you on this project.  (If you're a student, talk to your instructor.)

Link to the interfacing document mentioned above:

7870.Address.doc