Hello. I'm making a voltimeter-amperemeter using an atMEGA328P, L7805, LM358, LCD 16x2 and some other components.
The problem is that even though the LCD turns on, it doesn't show the code or at least the white squares it should, and when I move the potentiometer that goes with it it doesn't change the contrast.
I am completely sure it can't be the schematic nor the code since they were given by our professors, so they can't be wrong. The pads are fine, there are no shorts, and the components should technically be good.
I attached the schematic, pcb and code (the red pad doesn't cross the other pads, it's a cable that goes on the other side (single sided baord)).
I hope you can give me a suggestion.

 

Welcome to AAC!

Your LCD initialization does not match the pin connections.

LiquidCrystal lcd(RS, E, D4, D5, D6, D7)

Check the pin connections given in the schematic diagram.

 

Hello. I'm making a voltimeter-amperemeter using an atMEGA328P, L7805, LM358, LCD 16x2 and some other components.
The problem is that even though the LCD turns on, it doesn't show the code or at least the white squares it should, and when I move the potentiometer that goes with it it doesn't change the contrast.
I am completely sure it can't be the schematic nor the code since they were given by our professors, so they can't be wrong. The pads are fine, there are no shorts, and the components should technically be good.
I attached the schematic, pcb and code (the red pad doesn't cross the other pads, it's a cable that goes on the other side (single sided baord)).
I hope you can give me a suggestion.

Hi,

I was going to say check the pin connections too that is a common error but MyChips beat me to it. If the pins are not connected right to the controller you may see nothing.

Also, a better way to run them is with an IC2 back pack module. You connect the module to the 1602 display and you communicate to the module using the IC2 protocol. The module then communicates with the 1602 display. The biggest difference is the IC2 module only requires two pins from the controller chip, along with V+ and ground. This saves a lot of controller pins for use for something else. You can ask your teacher about doing that.

 

Definitely I2C is the way to go. Far far easier... Also check your LCD module to see if it requires a backlight connection.

 

Definitely I2C is the way to go. Far far easier... Also check your LCD module to see if it requires a backlight connection.

I built my own LCD display module using UART communication, uses only one wire, along with power and GND.

 

The problem may exist in the circuit part or the code. I think the easiest way to check an LCD is to connect it with an Arduino and run the Arduino's buit-in 'hello world' code for LCDs.

If you do not pocess one please check that you've initialized the correct pins in your code. I mean the pins of the microcontroller that are connected to the LCD should be initialized in the code too. Also do not forget to connect the LED+ and LED- pins to VCC and GND respectively to turn on the backlight.

 

What is the LCD? Where is the datasheet? Most 16x2 LCDs use the same underlying chipset & protocol (hd44780, as I recall). And usually they are 4-pin or 8-pin I/O and you have to tell it which you're going to use. There is an initialization sequence. And you must talk to it at a speed it can respond to, and wait an appropriate number of miliseconds after each communication so it can execute it. Further, make sure you have the contrast adjusted properly. You'll need a trimpot and small circuit for that. If it's wrong, you won't see squares or anything else on the display, even though, they may be there.

i2c is great, but it is an unnecessary and added complexity. Talk with the LCD directly, which is trivial, and easy. I've done this many times- it takes almost nothing to do. First- identify what it is, and the data sheet.

Read and understand the datasheet. Seems hard- isn't. Go slow, take small steps. Small steps lead to big successes!

 

What is the LCD? Where is the datasheet? Most 16x2 LCDs use the same underlying chipset & protocol (hd44780, as I recall). And usually they are 4-pin or 8-pin I/O and you have to tell it which you're going to use. There is an initialization sequence. And you must talk to it at a speed it can respond to, and wait an appropriate number of miliseconds after each communication so it can execute it. Further, make sure you have the contrast adjusted properly. You'll need a trimpot and small circuit for that. If it's wrong, you won't see squares or anything else on the display, even though, they may be there.

i2c is great, but it is an unnecessary and added complexity. Talk with the LCD directly, which is trivial, and easy. I've done this many times- it takes almost nothing to do. First- identify what it is, and the data sheet.

Read and understand the datasheet. Seems hard- isn't. Go slow, take small steps. Small steps lead to big successes!

Hi,

I used direct communication with a PIC chip one time with a different LCD display. I had to write all the code myself because there was no library.
That takes a lot of pins though and that is one reason IC2 is so nice. It uses only two pins of your microcontroller chip, and also because the IC2 interface chips can have 8 (or more) different hard wired addresses, you can actually use up to 8 displays with a single microcontroller chip. If you try doing that without IC2 you will have to use a ton of i/o pins and maybe not even have enough. IC2 also has libraries that you can use so you dont even have to write much code. Typically just declare the class and a few setup instructions and suddenly you can display anything you want. That's the same with those seven segment displays too, just a different library.

So the benefits of IC2 include:
1. Only 2 i/o pins required for the microcontroller chip.
2. Able to use several LCD or LED displays all at the same time.
3. Wiring up is much easier as there are less wires from the uC chip to the display(s). That's an especially good point if you are using multiple displays.
4. The IC2 backpacks are made to solder right to the displays so you dont have much work there.
5. The IC2 backpacks are fairly cheap to purchase.

So really the only advantage to using the raw 1602 or other display is you dont have to buy an IC2 backpack or interface chip.
Ok one other advantage is without the IC2 backpack the entire display board is a little smaller.

Maybe you can come up with some other advantages and disadvantages.

 

Hi,

I used direct communication with a PIC chip one time with a different LCD display. I had to write all the code myself because there was no library.
That takes a lot of pins though and that is one reason IC2 is so nice. It uses only two pins of your microcontroller chip, and also because the IC2 interface chips can have 8 (or more) different hard wired addresses, you can actually use up to 8 displays with a single microcontroller chip. If you try doing that without IC2 you will have to use a ton of i/o pins and maybe not even have enough. IC2 also has libraries that you can use so you dont even have to write much code. Typically just declare the class and a few setup instructions and suddenly you can display anything you want. That's the same with those seven segment displays too, just a different library.

So the benefits of IC2 include:
1. Only 2 i/o pins required for the microcontroller chip.
2. Able to use several LCD or LED displays all at the same time.
3. Wiring up is much easier as there are less wires from the uC chip to the display(s). That's an especially good point if you are using multiple displays.
4. The IC2 backpacks are made to solder right to the displays so you dont have much work there.
5. The IC2 backpacks are fairly cheap to purchase.

So really the only advantage to using the raw 1602 or other display is you dont have to buy an IC2 backpack or interface chip.
Ok one other advantage is without the IC2 backpack the entire display board is a little smaller.

Maybe you can come up with some other advantages and disadvantages.

IMO a newbie should start with the basic 8/4 bit direct communication interface for the prime advantage of actually understanding simple digital interface protocols. This gives the background to understand how interfaces like i2c work instead of just parroting the designs of others. The LCD squares/nothing works phase is something every new builder should experience.

 

You'll have a better time trying to use the Arduino example code than writing your own.
https://docs.arduino.cc/learn/electronics/lcd-displays

 

…one reason IC2 is so nice.
…without IC2 you will…
IC2 also has libraries…
(&c)

Not to be picky but what at first looked like a typo is so consistent it’s some other sorts of error. Just a friendly correction, it’s:

I²C,
or I2C,
or IIC

because if stands for Inter-Integrated Circuit bus protocol.

Since I am already being annoyingly pedantic I will add that it was patented in 1981 by Philips who designed it as a low pin count method for serial communication among integrated circuits.

It started life at 100kb/s and has been updated several times to add both more speed (1Mb/s) and features like device ID. There is also a unidirectional UFm (Ultra-Fast Mode) that relies on push-pull logic to get up to 5Mb/s.

I²C is ubiquitous and is almost always the method of choice for inter-chip communications barring some requirement that it can’t meet. It is supported in hardware by every modern µC, and there are libraries for every platform you are likely to encounter.

We now return you to our regularly scheduled programming, already in progress…

 

But, no matter how simple I2C is, the OP is using a 1602 display without the intermediate I2C controller. He has already gone through the trouble if soldering up the parallel interface and us ready to go.
It is a great learning experience because it is one of the few 4-bit or 8-bit parallel interfaced peripherals available as a DIY part with good libraries for Arduino.
Now, let's stop wishing the OP had a different part and focus on the setup they do have.

 

Not to be picky but what at first looked like a typo is so consistent it’s some other sorts of error. Just a friendly correction, it’s:

I²C,
or I2C,
or IIC

because if stands for Inter-Integrated Circuit bus protocol.

Since I am already being annoyingly pedantic I will add that it was patented in 1981 by Philips who designed it as a low pin count method for serial communication among integrated circuits.

It started life at 100kb/s and has been updated several times to add both more speed (1Mb/s) and features like device ID. There is also a unidirectional UFm (Ultra-Fast Mode) that relies on push-pull logic to get up to 5Mb/s.

I²C is ubiquitous and is almost always the method of choice for inter-chip communications barring some requirement that it can’t meet. It is supported in hardware by every modern µC, and there are libraries for every platform you are likely to encounter.

We now return you to our regularly scheduled programming, already in progress…

Hi Ya'akov,

Oh thanks for the correction i do that now and then. I prefer the I2C or even i2c which is a bit more readable because of the 'i' and lower case 'L' similarities in some fonts.

It's interesting that you added a little history too because i think about that from time to time. I had used a serial communication similar to i2c back around 1974. I was experimenting with some 7400 series TTL back then, a very common logic series back then, and wanted a way for some circuits to be able to talk to other circuits without using a ton of wiring as in a parallel interface that could take 8 wires plus a ground. I cant remember the exact protocol but it was very similar to what we have today as i2c.
I've also used other protocols since then for uC's to talk to each other, and often they can be even simpler than i2c because they do not have to be as flexible.
i2c is great though because it became so much a standard. SPI is another one i think can reach higher speeds than i2c, but then i learned there is also i3c which is faster than i2c from what i read, although i have never used that one.

The one thing that did bother me about the "i2c" or in caps "I2C" lettering is that it sometimes makes us think about the wording, "eye to see" which could also be "i to c" which seems to imply that something called "i" is moving toward something called "c" or something from "i" is being transferred to something called "c".

But anyway thanks for bringing this up i'll try to remember for next time. The history part also brought back some memories from the now very distant past.

Perhaps is better that you did not let things like this go by without saying anything it actually helps to hear about the correct way to write it. Might help reduce confusion in the future.

 

You'll have a better time trying to use the Arduino example code than writing your own.
https://docs.arduino.cc/learn/electronics/lcd-displays

That's the way i do it now but with the PIC chips it's a little different. Back then i dont think there was any library yet.
Is there one now? Maybe you can find one for the PIC too.

 

I built my own long ago for PIC so I never had to look for one online. I have no idea - but again, you are somehow pulling the thread to a topic YOU want to talk about (PIC controllers snd libraries) instead of the Arduino-based controller the OP is using. If you look at his code, he is using the correct library.

Well to keep on topic, i use the Arduino i2c code more than anything else. I am using it as we speak
I actually find it easier to use than any other uC because the libraries are already intact and there are plenty of examples that are easy to find on the web.

So i recommend the Arduino also.

 

Like many threads, it is easy for this one to drift off topic since it can go in many interesting directions—but we should try to stay on track to assist the OP with the problem presented.

Of course starting a new thread on a side topic is always welcome.

(Moderation)