[solved]Problems with I2C LCD Display and ATtiny 84/85

Using Arduino Displays
1

Hello guys !

I am using:
Linux Mint 18.3 with Arduino IDE 1.8.5
I2C HD44780 LCD Display 16x2

I have some weird experiences and problems with my I2C LCD Displays I bought some time ago. I first started using it with the Arduino Uno and with the LiquidCrystal_I2C library. That worked like a charm and I continued and moved to the ATtiny 85. After some searching I found a library called LiquidCrystal_ATtiny and with that one it also worked for me, I was able to display everything with my I2C LCD Display. However a few weeks passed and I decided to enlarge the project and I needed a ATtiny 84 (because of more I/O pins). I used the same library as with the ATtiny85 but it now only shows me the first character of my string. So when printing "Hello World" it just shows "H". I moved back to the ATtiny 85 but now I have the same problem here, only dispalying the first characters of the string, even though it worked a few weeks ago. However I tried using different librarys, different ATtinys (as I hav a few) and also different displays but none worked, always the same error. Only moving back to the Uno and using the LiquidCrystal_I2C works. I cant find the problem, I even tried modifying the LiquidCrystal_I2C library to make it work with ATtinys but that was also a dead end :slightly_frowning_face:

This is what I added to the LiquidCrystal_I2C at begining

#if defined(AVR_ATtiny84) || (AVR_ATtiny2313) || defined (AVR_ATtiny85)
#include "TinyWireM.h" // include this if ATtiny84 or ATtiny85 or ATtiny2313
#define Wire TinyWireM
#else
#include "Wire.h" // original lib include
#endif

But I cant compile for ATtinys either with that modification.

And this is my simple code that worked a few weeks ago on the tiny85 and now doesnt:
#include <TinyWireM.h>
#include <LiquidCrystal_attiny.h>

LiquidCrystal_I2C lcd(0x3f, 16, 2);

void setup()
{
// initialize the LCD
lcd.init();

// Turn on the blacklight and print a message.
lcd.backlight();
lcd.print("Hello, world!");
}

void loop()
{
lcd.setCursor(0,1);
lcd.print("In loop!");
}

It just prints out:

H
I

I also tried adding 10k resistors to the SDA/SCL line but it did not make any difference. So I would be really thankfull if someone could help me with that or faced similar problems.

Best regards

elko 739

2

The library is broken. (coded wrong)
The write() function/method is telling the Print class that there was an error and to stop sending anymore characters.
That is why you only see the first character.
This was a common error in many "LiquidCrystal" libraries.

If I found the same library you are using,
Look in the .cpp file for this:

inline size_t LiquidCrystal_I2C::write(uint8_t value) {
 send(value, Rs);
 return 0;
}

And change it to this:

inline size_t LiquidCrystal_I2C::write(uint8_t value) {
 send(value, Rs);
 return 1; 
}

The return of 0 (zero) says that no characters were successfully processed which is an error.
That is why you only see the first character.

--- bill

3

Such an easy fix, why are the broken libraries still around?

4

Over the years lots of third party libraries have been produced.
Users have often placed them in the system libraries folder instead of the user libraries folder.
Internet tutorials and internet vendors advise and supply obsolete and hacked third party libraries.

Nowadays there is an IDE Library Manager which you can access via

Sketch->Include Library->Manage Libraries...

This has made a massive difference. Libraries must have version numbers and URL. The Manager can report the version and install or update as required.

Unfortunately many users have got old third party libraries in the wrong place on their PC.
Or have multiple libraries with the same class name(s) but different methods.

Simplest advice for LCD: install hd44780.h library and forget about all the duplicate "LiquidCrystal*.h" use.

The IDE reports which libraries it has used when it builds a sketch.
The IDE reports when it finds multiple libraries with the same name
Turn on verbose compilation via File->Preferences

David.

5

Thank you guys for the answers, I changed the line in the library and now it finally works with both ATtiny84 and 85 !! I still dont get why it worked in the beginning but maybe I messed up the librarys or something, anyways now it is fine ! I will give the hd44780.h definitely a try and see how it works :slight_smile:

Thank you !!

6

The Arduino team is actually to blame for many, if not most of the broken libraries out there.
The biggest thing they they did that created these types of problems was during the 1.0 release.
With the 1.0 release they changed some of header files and some of the API interfaces; how the Print class interfaces to libraries that inherit it is one of those changes.
Prior to the 1.0 release there was no way for libraries to tell the core functions, like the Print functions about any status or error information.
1.0 changed that and started to support some return status information.
While having return values is a good thing, the way the Arduino team did the 1.0 release was absolutely terrible.
They made some significant changes to APIs and header file names and they did it between the final release candidate and the final release.
This is against all standard s/w development/release practices.
i.e. you don't make a major change that breaks compatibility with existing code without doing any sort of test release cycle.
And for sure you don't do this after a final release candidate without having at least another test release to allow the broader community to test it.
They did this after they had done alpha releases, beta release, and even a few release candidates with no subsequent testing release prior to its final release.
The changes they did broke 100% of all the 3rd party libraries. That isn't a mistype what they did broke 100% of all the existing 3rd party code out there.
And they did it knowingly and intentionally.
Several of us were very vocal against this decision and even offered them solutions that would have ensured that the vast majority of existing code could continue to operate.
They stated they preferred to break everything claiming that by breaking all existing code rather than providing any sort of backward compatibility, it would force people to fix their code to the new interfaces faster.

This took an eco system that had become very stable over the years and threw it into chaos and the community is still dealing with issues from that decision.

In this particular case the bug in the library wasn't directly do to the 1.0 changes but rather the way the author incorrectly implemented the return value.

Until recently (like the past couple of years) the Print class supported but ignored the return value.
Since the Print class ignored the return value, it didn't matter what value was returned.
Starting in IDE version 1.6.7 the Print class starting looking at the return value from the write() method.
If the return value from a library write() method is zero, Print will drop remaining characters in a multi-character string.

What can make this more complicated is that even though the Print class is a common service, it is implemented down in each specific core. i.e. down in the IDE AVR bundled core, and the 3rd party pic32core, and the DUE core, and the 3rd party teensy core etc...
So how it it is implemented can vary between board types since different boards can use different cores.
For example, Paul decided that he wasn't going to live with the "break the world" decision made when 1.0 was released.
So if you use a teensy board, many things that broke when using an UNO board, would still work with a teensy board.

Also because of the Print class being down in the core vs in a common area, it means that Print class checking return values is up to the individual core. Not all cores are updated at the same time and not all cores use the same code so depending on which core and which IDE version you have, there can be some variation of functionally when building code for different boards since different boards can use different cores.

With respect to the hd44780 library, I am the author, and normally I would advise using it as it has many capabilities that are not in any other lcd library. However, in this specific case, (using the ATtiny parts), I would advise caution.
The reason being that those parts have very limited flash and the hd4480 library will be larger than the library you are currently using. And this extra size can potentially be an issue in small flash sized environments.
Most of the reason is that code that is not being used is still being dragged into the linked image.
Unfortunately, there is no easy solution to fix this as it is due using C++ virtual functions and some decisions made by the gcc developers to remove some capabilities from the compiler that no longer allows removing unused C++ virtual functions.
I am very conscious of this and am working a solution for this but it will be a while as it requires changing the how things work under the hood in some very significant ways, hence it is not trivial.

So for the time being, while you can use the hd44780 library on the ATtiny parts, I would advise caution since it will use more flash than you may be comfortable with in that environment.

--- bill

7

Thank you very much for this detailed information ! Is was aware that with the new IDE the library manager was included but I didnt notice the huge impact it had ! Back when I started with the Arduino a few years ago things were easier, but I noticed that the IDE and in general the main coding was not the best way of doing it and with main coding I mean how libraries are done and such things are handeld/included etc. However I tried using differnet IDEs, Visual Studio, Atmel Studio.. but that just put another paint over the problems. I hoped that this would be better in the future as the development of the Arduino IDE moves on but hearing today that this is still a problem makes me a little bit sad. I also have to be honest and mention that over the last months I was very abscent and didnt spend much time in programming and did not recoginze that with the new updates big changes were made and as you are describing they did not turn good. But I think im getting off topic here now.... Anyways thanks for your effort and explanation hope to meet you again on the forum :slight_smile:

8

Back when I started with the Arduino a few years ago things were easier ...

Not sure what you are referring to.
Also, the things that I talked about in hd44780 that causes images to be larger than I would like them to be has nothing to do with the Arduio IDE. They are issues related to the way C++ virtual functions work and a few decisions that the gcc developers have made. Those issues will exist regardless of what IDE or build environment is used as they are issues with the C++ language itself and a capability that used to be in gcc to be able to catch unused virtual functions that was removed in more recent versions of the gcc toolset.
i.e. these same issues will exist when building linux apps that use C++ classes that involve virtual functions.

The Arduino IDE tools and the library manager in the IDE does not affect code size of a firmware image.
The library manager is used to install libraries. While how it is internally implemented does create some issues the main one being it creates a lot of manual work for the Arduino team to keep updating the available libraries in the library manager list, It is actually a very big improvement for the Arduino IDE users.
The IDE library manager makes libraries much easier to locate and install and ensures that the libraries are installed properly.
This has been very helpful for many users and Arduino community as a whole.

--- bill

9

For me, ONLY worked this:

See at the end of the post:

"LCD library used: GitHub - platisd/ATtiny85-LCD-library: ATtiny85 I2C LCD library (used for an interactive name tag)
TinyWireM used: GitHub - adafruit/TinyWireM: I2C library for Trinket and Gemma, adapted from BroHogan's code on Arduino Playground
==>>> Core used: GitHub - vprimachenko/ArduinoTiny: Arduino (^1.6) cores for Atmel ATTiny family"

Mainly CORE CONCERNS

Dav!d