Control Bare LCD With ATmega328p

To do it in a 'proper' way you need either an interface IC, or a controller that contains the required hardware - such as the PIC 18LF8490. A big issue is the number of pins required to feed the glass.

Do you have a suitable display to work with?, in my experience they are pretty well impossible to find.

You can get a demo board to play with from:


You can download the user manual, plus sample code.

Athosworld said:

Or do I have a driver IC between the ATMega and the LCD?

Click to expand...

Yes, definitely.

A graphics LCD panel needs complex multi-level drive signals; the controller ICs (for small panels, at least) have internal RAM that you [via the driver program] load the grey level or colour for each pixel in to, and the driver IC translates the grey or colour values to the correct voltage combinations for the panel.

The interface from the MCU - Arduino, PIC or whatever - can be two wire I2C (slowest), three or four wire SPI (reasonably fast) or parallel data bus (fastest), depending on the requirements, speed vs number of MCU pins needed just for the display.

These are a good example of a small display with integrated controller IC

They use a SPI interface and can be updated fast enough to display reasonable moving images, if you use a fast enough MCU.

I used a Seed Xiao (32 bit ARM CPU similar to arduino zero or M0) to run two of those, in my version of a Halloween project another user on mentioned; it's programmed via the Arduino IDE, after adding the seeed device library:


See the links in the description of this video for more info.


I've also used the common 128x160 1.8" TFTs with DSPIC MCUs; you need a device with a lot of RAM and storage to do anything much with graphics, though text just needs enough for the font data and working memory.

Over here are projects driving several different displays.



What is on the part (ARM Core as well) -





Regards, Dana.

A couple of useful YouTube pages:



And a PDF:

Attached are two AVR application notes (doc2569 and doc8103) about driving LCDs with general purpose I/O. (The ATMEGA328 is an AVR controller.)

Dick Cappels said:

Attached are two AVR application notes (doc2569 and doc8103) about driving LCDs with general purpose I/O. (The ATMEGA328 is an AVR controller.)

Click to expand...

Nice find

Just remember that there is a big difference between driving a segment-type display, needing fairly simple logic, and a pixel (dot) matrix that needs multi-level drive signals, as the OPs question was about.

Example - the small relatively low resolution display below, 320x240 pixel: The LCD panel itself has over 1000 individual multilevel drive signals in to it.
(1040 to be exact: 240 rows x 3 [for R G B at each pixel position] x 320 columns. The driver IC has somewhere around 1100 connections, between the panel connections, the control and data inputs, and power etc! )

The driver IC in the display module means the complete display module can work with as few as four signal connections from an MCU, plus power & ground, and there are arduino libraries to allow you to use it with minimal code. The libraries can be adapted for just about any other MCU with adequate RAM etc.

Can you post a picture of said dot matrix... It looks like others have assumed some type of LCD..

Is this a simple 8 x 8 led matrix?? If not, then a driver would make it easier.

Ian Rogers said:

Can you post a picture of said dot matrix... It looks like others have assumed some type of LCD..

Is this a simple 8 x 8 led matrix?? If not, then a driver would make it easier.

Click to expand...

That's because we read the post!

AC signal to drive that LCD

Click to expand...

Following on from his previous crazy posts it seems fairly obvious he's expecting to make a low cost COB system, while having no experience in programming or electronics, and no idea of the costs involved in having COB's manufactured.

OIC.... I possibly could, but like you said, he possibly couldn't.. These boards are sooo cheap I wouldn't bother!!

Looking to his "other" threads, it seems to be different LCD modules..

Nigel Goodwin said:

Following on from his previous crazy posts it seems fairly obvious he's expecting to make a low cost COB system,

Click to expand...

Im not “crazy”, just trying to learn to make something like that.

The COB part is totally irrelevant and if anything preventing you learning how to design, build and program electronic devices and systems.

It's just an alternate manufacturing technique for high-volume low-cost items. The original prototypes would have used conventional ICs and components.

To the above, I would add: The AVR controllers are pretty expensive, plus I don't particularly like the idea of shipping controllers with flash memory because they tend to stop working after a while. This is less of a problem with automotive grade chips but it still exists as a potential source problems.

The ATMEGA48/88/168/328 family is a great tool for feeling your way around a new subject, and to a certain extent the Arduino platform would make life a lot easier than learning yet another assembly lanugage but if you really anticipate high volume production you would be best off because of cost and potentially reliability considering an IC designed specifically designed to perform this function. To wit: https://www.nxp.com/products/peripherals-and-logic/lcd-drivers:MC_71118

Dick Cappels said:

To the above, I would add: The AVR controllers are pretty expensive, plus I don't particularly like the idea of shipping controllers with flash memory because they tend to stop working after a while. This is less of a problem with automotive grade chips but it still exists as a potential source problems.

The ATMEGA48/88/168/328 family is a great tool for feeling your way around a new subject, and to a certain extent the Arduino platform would make life a lot easier than learning yet another assembly lanugage but if you really anticipate high volume production you would be best off because of cost and potentially reliability considering an IC designed specifically designed to perform this function. To wit: https://www.nxp.com/products/peripherals-and-logic/lcd-drivers:MC_71118

Click to expand...

I have lost touch with the rel aspects, question, if FLASH is only read, eg. program memory, is that lifetime
not quite good ? And if parameters written into FLASH using wear leveling on top of simple R/W cycle
lifetime make them long term solutions ? Not quite the resilience of real EEPROM or ferroelectric but
quite a few years of operation ?



Regards, Dana.

Dick Cappels said:

To the above, I would add: The AVR controllers are pretty expensive, plus I don't particularly like the idea of shipping controllers with flash memory because they tend to stop working after a while.

Click to expand...

What do you mean "after a while", as far as I'm aware lifetime of FLASH and EEPROM memory in microcontrollers is a good many years, if not decades.

FLASH endurance R/W cycles in processor typically minimum of 10,000 cycles (ATMEGA328 for example).

EEPROM in same processor 100,000 read/write cycles.

Application largely determines lifetime (non space applications, radiation aggravates threshold shift
of memory sense amps in space applications).

If application is DAQ taking KSPS and storing them in either memory lifetime not so long.

If music player doing read cycles only, long time....here are retention specs (Cypress PSOC) -




Regards, Dana.

I am only reporting my philosophy and experience.

I have been using AVR controllers since 2002 and already I have found several projects that stopped working because the flash memory got flaky just sitting on the shelf most of the time. Most of those were programmed with Atmel's AVRISP or STK-500.

I am now worried about a piece of test equipment on the market that the client started making and selling in 2016. That used the ATMEGA48 automotive temperature range part so I'm hoping they last longer than earlier parts.

My main point is that a special purpose chip will probably be less expensive and more reliable than an ATMEGA controller.

Dick Cappels said:

I am only reporting my philosophy and experience.

I have been using AVR controllers since 2002 and already I have found several projects that stopped working because the flash memory got flaky just sitting on the shelf most of the time. Most of those were programmed with Atmel's AVRISP or STK-500.

I am now worried about a piece of test equipment on the market that the client started making and selling in 2016. That used the ATMEGA48 automotive temperature range part so I'm hoping they last longer than earlier parts.

My main point is that a special purpose chip will probably be less expensive and more reliable than an ATMEGA controller.

Click to expand...

I've ever seen any issues with PIC's, perhaps it's a failing of the Atmel parts?.

Dick Cappels said:

I am only reporting my philosophy and experience.

I have been using AVR controllers since 2002 and already I have found several projects that stopped working because the flash memory got flaky just sitting on the shelf most of the time. Most of those were programmed with Atmel's AVRISP or STK-500.

I am now worried about a piece of test equipment on the market that the client started making and selling in 2016. That used the ATMEGA48 automotive temperature range part so I'm hoping they last longer than earlier parts.

My main point is that a special purpose chip will probably be less expensive and more reliable than an ATMEGA controller.

Click to expand...

Sounds wacko. If chip not meeting R/W cycles definitely silicon issue. But if code,
even the boot / startup code we often dont touch, its violating the write cycle limits,
and that is fixable. Might be interesting to do a simple bench test on a jig just writing the crap
out of FLASH to see if there is chip issue, otherwise tackle how code used it, if at all other
than reading it.


Regards, Dana.