Hobbyist tend to use parallel communication for interfacing with an LCD and all the libraries are for a specific type of microcontroller (Arduino or AVR) or LCD.

But, for a design engineer, it is often necessary to design with a microcontroller with optimum performance (may be because of power optimization or processing power or some specific peripherals of interest). In that case, it surely takes a lot of engineering time to develop libraries to interface with the specific LCD of choice with the specific microcontroller, if not provided by the manufacturer. How do the professional embedded system engineers deal with with it?

Example: For my case, I planned to use the STM32L476 microcontroller. I found the New Haven LCD with an I²C interface quite intriguing for my design. New Haven does not provide libraries for STM32L476, but they have example code for some other microcontrollers. I have to take the risk going through the datasheet and the examples and build my own. Does a professional follow this or I am heading towards wrong direction?

  • 2
    \$\begingroup\$ Sorry mate but I think that you do not understand the basics. What is the difference between Arduino and AVR. Arduino is not micro!!!. "Hobbyist tend to use parallel communication for interfacing with LCD" where did you get it from? For larger displays parallel interface is the only choice and modern hardware has support for it (eg DMA2D, LCD interface in STM32 micros). \$\endgroup\$ – P__J__ Jun 15 '17 at 10:47
  • \$\begingroup\$ It's safe to assume any mass produced LCD is tested by the manufacturer so they must have the code to drive it for at least one MCU or any hardware. Porting their library to your MCU is as simple as switching out their I2C register access routine and put in yours, and keep all register address/values. Well, if their library is open source. \$\endgroup\$ – user3528438 Jun 15 '17 at 13:59
  • \$\begingroup\$ "I have to take the risk going through the datasheet and the examples and build my own." - Well, that's what people do when building 'real' products and not just linking together some Arduino libraries for a quick proof of concept. \$\endgroup\$ – JimmyB Jun 16 '17 at 15:45

My question is, how do the professional Embedded System Engineers deal with with it.

It is a very simple task & professional coders do not have any problems to write such a simple code. They do not have any problems to port simple libraries from one system (or programming language to another).

Simplest but not the most efficient way is to split it into some levels of abstraction (for example - communication layer, display hardware layer, graphics primitives layer). Usually to get the most from the hardware something has to be merged.

If you ask this question it is very likely that you have to improve your programming skills.


It depends.

I have a personal LCD library that is pretty much split into two parts. One handles things like font rendering, goto_xy, breshenans line and circle drawing algorithms, gradient fills, overlays and such and is written almost entirely in ansi C, nothing platform specific at all (There is a header file for configuring display memory layout, screen geometry and such things).

The second part deals with "select_region(x1,y1,x2,y2)" and "blit_pixels... and such things and is highly device specific (Actually you will find that most of those screens use VERY similar commands). This is the only bit that needs real work to accommodate a new display.

Sometimes if performance is everything you can of course talk to the screen directly, but if your implementation is sane the limit will end up being the SPI bus speed most of the time, so ultimate software performance can take a back seat to maintainability.

For SPI mode drivers you will find that there are basically only really two types, one of which embeds the control/data selection in the serial stream and one that does not using a GPO line instead, cover those two and you pretty much end up writing a display_init routine (or sometimes even just some static const data) for each new device, the things really are that similar (Hint go for the GPO option unless your chip has hardware support for 9 bit SPI).


First off you need to master google. You will first find that only some lcds use a traditional parallel interface, spi, i2c and sometimes serial are often used. And that is only because there is a chip attached to the lcd panel to sorta make your life easier. You will find that you can sometimes find the display without the helper chip and buy microcontrollers from all the major vendors that have a lot of pins for driving displays directly. saving on parts and cost.

As far as how to the engineers software and hardware deal with this? It is like learning to drive to a new to you grocery store, you look at the documentation (map) plan your attack and then go do it, sometimes you get it on the first try sometimes it takes a few.

There are examples for most of the popular display driver chips for most of the popular microcontrollers or architectures or the ones for the AVR (Arduino is not a microcontroller) might port directly or with a little help (the libraries might before Arduino yes, the sandbox/environment) or the mbed (another sandbox/environment set of libraries) or 700 others on github or wherever google takes you, or you just look at the datasheet and sometimes it takes minutes to get the display up sometimes hours.

Same goes for the hardware engineers, they look at the other part of the datasheet, the pinouts the electrical specs, power requirements, reference design, etc and plan and or just start on the schematic for the product/board.

Its all part of the job, professionals just do their job, not everyone is cut out or interested for this level work, some folks are better at applications, phone apps, whatever, video codecs, video games, etc, and some folks use libraries for these kinds of devices, but cant necessarily get their hands more dirty than that (Arduino)(some can but choose to not re-invent a wheel), and some can and will and love to get their hands dirty. Some write the libraries for others, the examples or drivers, etc. Some of the above mentioned jobs require wading through API documentation to learn how to make a gui program on some new to them environment, some have to read a book or look at examples or both to learn how to make a device driver for something, or look at the changes from the prior version of the operating system so they can tweak their existing drivers they are responsible for and/or write new ones as needed. Its all part of the job and how you get that title of "professional".

Yes you are on the right path, now with i2c sometimes it is just easier to bit bang, or bit bang first, then get through that and later, if ever, if supported by the mcu peripherals, use the mcu specific i2c peripheral. the latter runs better, but has a higher development cost (unless there is a good library already that just works) and is not portable. Bit banging, particularly with i2c, makes it so you can port your code from one mcu or family to another in sometimes literally minutes and have the display up, where if you use the built in peripheral that could be a long afternoon or day or week. A scope is not required but if this is your first time...required...or some other way to "see" what is going on, which you could kinda get by with another microcontroller polling gpio pretty fast and then using that as a logic analyzer. but for i2c you really want a scope because this is an open collector pulled up bus, and you can see when each side releases and takes over the bus which you cant see with a logic analyzer, and that timing may be important. the other fact is assume the manuals are at least a little bit wrong. they are never perfect, you have to "hack" your way through sometimes for lack of a better term.

the examples for other microcontrollers are going to help you with what registers to program in what order (sometimes matters, sometimes doesnt) and some values to poke in to those registers, which may or may not make sense when you compare the examples to the documentation for the device. you still have to come up with the basic i2c protocol support in order to deliver those register writes and perhaps reads (often you can get by with write only to some of these displays).

st parts are pretty popular, displays are a dime a dozen on ebay the nokia 5110 ones, there are some 64x64 and other sized oled ones, with i2c, spi, etc interfaces, plus a myriad of others. A handful of really popular display drivers (chips on the back) once you try one or two displays with those move on to the next...

  • \$\begingroup\$ you will also find that "professionally" individuals or companies will latch onto a particular brand or family of mcus and other products. Once you have your own or a trusted set of libraries for a part, then next thing you interface you dont have to go through the how do I write a program for this chip, and the how do I make the spi work for this chip, you just take a current program chip out the old peripheral support shove in the new, clean up and done. There are pros and cons to sticking to one thing vs shopping around. \$\endgroup\$ – old_timer Jun 17 '17 at 0:56
  • \$\begingroup\$ Its like only eating the same dish at a favorite restaurant or varying the dishes you get each time you go. Pros and cons. \$\endgroup\$ – old_timer Jun 17 '17 at 0:57
  • \$\begingroup\$ sometimes it is dictated by management, sometimes it is dictated by cost, sometimes to save five cents per board, you get to spend 1000 man hours porting to that new chip all the while doing the math as to how many units have to sell at a 5 cent savings just to cover your NRE, not to mention everyone elses billed time in engineering and manufacturing dealing with the change. eventually you are the boss that gets to dictate your favorite... \$\endgroup\$ – old_timer Jun 17 '17 at 0:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.