Stand alone audio processor with 16x2 LCD ?

Hi Samba-guy

Can you share what processor / part you need to program from the DSP to further understand your requirement?

Thanks

Miguel

HI all

I agree that the 1701 would be a lower cost option for this. I do recall writing some code for an allegro LED driver at some point in time, a couple of years ago. I don't know the specifics of what's being needed here but I would assume it's not that complicated and either the 145x or the 1701 would work. With the 1701 being the lower cost alternative.

Like I said more information would be great. If you prefer to take this offline, please let me know

Miguel

Hi Miguel,

The LCD could be any 16x2 character LCD, for instance:

SPI interface: http://www.winstar.com.tw/products_detail_ov.php?lang=pt&ProID=341

I2C interface: http://www.winstar.com.tw/products_detail_ov.php?lang=pt&ProID=342

4- or 8-bit Parallel interface: http://www.winstar.com.tw/products_detail_ov.php?lang=pt&ProID=22

I agree with you and twidget that a cheaper SigmaDSP could do the audio job I need, but the goal here would be to avoid another compiler for the external MCU, with cost-/time-consuming learning-curve, more complex manufacturing process, only to drive some few screens to the LCD.

Regards.

IMO,

Although it might be possible to build a standalone system that drives an LCD, it would be a waste of DSP resources. Instead I would use a simple 8-bit ucontroller to drive the LCD and interface it with the DSP via GPIO.

Assuming your SigmaStudio project is small enough to fit alongside the kludged LCD "driver", its possible the ADAU1701 would also fit your project (- LCD driver) . The $$ savings by downgrading to the cheaper DSP can be rolled into the ucontroller. Although the ADAU1701 offers less memory, it does have built in ADC/DAC as well as a WB feature.

But yours is an interesting request and no doubt if AD provides a simple solution, Ill take back everything I just wrote.

Hi Miguel,

I have worked with these types of LCD drivers before. It's a 2x16 array of dot-matrix characters (typically 5x8 pixels or 5x11 pixels, I believe). The interface is typically an 8-bit or 4-bit parallel input with a few other pins that signify whether the data sent is control, character data, read, or write. There is also a latch that needs to be toggled.

The LCD driver differs from the LED driver in the sense that far more data needs to be sent - instead of a 7-segment LCD, you have a 2 x 16 character, 5 x 8 pixel display.

In my experience, it's easiest to use a cheap microcontroller with a UART or SPI port and have it send the data serially to a shift register, which then outputs the data in parallel format. The shift register essentially acts like a serial-to-parallel converter.

While it would probably be possible to implement this kind of functionality on the ADAU1701, I imagine it would be pretty inefficient.

If you're building a "one off" or still in the prototyping stage I'll make the following suggestion; you can save yourself a ton of grief by using a "serial OLED" module; GLO-216: 2x16 Multifont Serial OLEDs

These are "one wire" serial devices that couldn't be simpler to use; you send them an ASCII character string and done. They have LCD's if you prefer but once you see an OLED module you'll never consider LCD again. I use these things for in just about every project I do.

One of the "overlooked" uses of these serial displays is as an "inline debugger"; you can drop lines of code into your main code displaying messages as simple as "Made it to here" keeping in mind it only takes a single pin to do this. On DSP's and larger processors this might seem trivial, but on smaller devices where there aren't a lot of debugging resources this can be a great help.