Have a question on Arduino? Ask our expert Simon Monk

I need to drive an I2C liquid crystal display (FEC: 206-3203) using an Arduino mini-pro, as part of the control system of an item of equipment to be manufactured in small quantities. I had hoped that using ready made libraries would speed the development, but it seems maybe not as much as I had hoped.

It seems that the LiquidCrystal_I2C library I downloaded is not suitable to drive this display - does anyone know of one that is suitable?

Failing that I need to choose the best way forwards. One approach would be to wire in an ISP connector and program it all in C. (I am not yet a very experienced C programmer but have coded several embedded projects including one using I2C. My core skills are power electronics and analogue.) Another approach would be to stay with Arduino code and use the I2C library to write display drivers using Sketch. This might be quicker if it works, but is it likely to hit a roadblock somewhere forcing me to start again and use C?

In either case there will have to be some trial and error because the data sheet for the display is only almost clear on how to use it.

Can you suggest another and better approach to try?

I need to drive an I2C liquid crystal display (FEC: 206-3203) using an Arduino mini-pro, as part of the control system of an item of equipment to be manufactured in small quantities. I had hoped that using ready made libraries would speed the development, but it seems maybe not as much as I had hoped.

It seems that the LiquidCrystal_I2C library I downloaded is not suitable to drive this display - does anyone know of one that is suitable?

Failing that I need to choose the best way forwards. One approach would be to wire in an ISP connector and program it all in C. (I am not yet a very experienced C programmer but have coded several embedded projects including one using I2C. My core skills are power electronics and analogue.) Another approach would be to stay with Arduino code and use the I2C library to write display drivers using Sketch. This might be quicker if it works, but is it likely to hit a roadblock somewhere forcing me to start again and use C?

In either case there will have to be some trial and error because the data sheet for the display is only almost clear on how to use it.

Can you suggest another and better approach to try?

Have you tried the I2C LCD library that comes with the Deuligne LCD deisplay?

http://shop.snootlab.com/lang-en/snootlab-shields/135-deuligne.html

You may find that you can adapt the C for this library to work with your Arduino sketch if the messages are different.

I tried this library, and its own Hello World demo gave me an error message at compilation:

C:\Programs\Arduino\libraries\Deuligne/Deuligne.h:68: error: conflicting return type specified for 'virtual void Deuligne::write(uint8_t)'

C:\Programs\Arduino\hardware\arduino\cores\arduino/Print.h:48: error:   overriding 'virtual size_t Print::write(uint8_t)'

If I could make the display respond at all, I imagine that would be about half the work of the entire project done.

I don't have time now to learn enough about C++, as distinct from C, to have a reasonable chance to correct this code, so:

The remaining question is whether it is better to write the display initialisation and subroutines to write to the display in Sketch, or whether it is better to wire in an ISP header and program it all in C, building on bits of code I have already written. Have you any insight into which is more likely to work out better?

Arduino sketches are just C, occasionally using C++ but only as libraries. Also, if you have written functions in C, you can just paste them into your sketch.

I would forget about trying to integrate any of you other code until you have got the simplest possible hello world example working with just the screen and an Arduino board.

If you have the datasheet for the I2C screen and know what kind of messages it expects, then use the Arduino Wire library (http://www.arduino.cc/en/Reference/Wire) to send it those messages.

Thanks for the advice. I decided to follow the sketch approach, but had to do something else first.

After dealing with something more time critical, I returned to this and found that searching by the display driver chip number did locate a workable library, even though the display type returned nothing that worked. The library is intended for an 8*2 display, not 16*2, but that is a minor point compared with it being possible to make the display respond at all.

The display data sheet included incomplete cut and pasted information from the chip data sheet, which is itself apparently transliterated from a language other than English. To make it work it would apparently be necessary to interpolate from the slightly incomplete or ambiguous, data presented, and even then, maybe use a little trial and error before it worked. Luckily someone has already found out what it means and written a library.

I really wish that Farnell could persuade suppliers to provide documentation that included all the required information, set down fair and square with no contradictions.

In the intervening time, of course, feature creep has expanded the requirement and I now need to control a motor speed with an analogue voltage, probably generated with PWM and an RC time constant, rather than just switching it on slow or fast as previously required. I have done that in C before, so it shouldn't be *too* much of a problem. {Famous last words?}