How to use LiquidCrystal_I2C Arduino library with an ATmega328p?

Go To Last Post
38 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I recently got an Arduino Nano, however I don't want to program it with the Arduino IDE and sketches and such, but rather in raw C using Atmel Studio. 

 

I got this LCD display that comes with a nice I2C backpack and is Arduino (and hence I guess ATmega) compatible. 

 

According to the comments, people have had success interacting with it using the LiquidCrystal_I2C library. I'd use this library too, but it looks like it uses either Arduino.h or WProgram.h, both of which I believe are part of the Arduino library.

 

Is there a way to port/configure this library so that it can be used to program a raw ATmega chip? Or is there an equivalent library that would suit my needs? Or will I need to write my own library?

 

I also know that there are examples of people interacting with the LCD display without I2C but the advantage of I2C is there are less pins needed (2 instead of 8).

This topic has a solution.
Last Edited: Sat. Jan 27, 2018 - 06:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that there is nothing special about the mega328 chip on the uno apart from the bootloader that only serves to load the application code.
Atmel Studio7 can load an Arduino project. This will bring in the required libraries. You can then write code to your hearts content. You can do the same using Arduino tools but the editor is much nicer in AS7 and you have debugging.
I found this by googling mega328 lcd i2c backpack
https://github.com/swharden/AVR-projects/tree/master/ATMega328%202017-03-19%20i2c%20LCD%20backpack

Also note that you’re not going to gain much going away from Arduino.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is nothing special about driving an LCD display with I2C. Start by getting I2C working; the LCD bit is then trivial.

 

I2C search term hint... 'fleury'

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, if you want to get rid of Arduino's libraries (I do not see why) you might remove one library at the time (remaining goes on working, making it more comfortable to shoot trouble).

You can program with the Arduino IDE in pure C (in a *.uno or *.cpp file), as xxx-g++ (xxx being a lot of CPU/MCU) can compile pure C (I know this is ugly).

Advantages: you write/debug what is your idea. Other people's ideas are already debugged and you do not waste time (giving you time to read or -incl- getting new ideas)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

atmelodramatic wrote:
I got this LCD display that comes with a nice I2C backpack and is Arduino (and hence I guess ATmega) compatible.   

Note that the display/backpack neither knows nor cares what system it is connected to - Arduino, Raspberry Pi, PC, ARM, ARV, PIC, 8051, FPGA are all irrelevant.

 

The only thing that matter is that the controller - whatever it may be - sends the right signals.

 

This applies in general to any interface.

 

EDIT

 

Just to be clear, "sends the right signals" includes that those signals have the required electrical characteristics.

 

See #9.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 24, 2018 - 10:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Note that the display/backpack neither knows nor cares what system it is connected to - Arduino, Raspberry Pi, PC, ARM, ARV"

 

Do PC have a TWI plug (they know I2C, for temperature control, say; but can users use it without huge efforts). was puzzled with arv (wikipedia dos not know about it).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:
Do PC have a TWI plug

Never seen one as standard - but adaptors are widely available.

 

was puzzled with arv (wikipedia dos not know about it).

Shh... it's secret

 

wink

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, remains an issue with RPi (among many others) : Arduino is 5v (some clones had 5v-3v switch, to test 3v compliancy; were cheaper than official ones -un switch more....-, but I do not find them anymore-  , RPi -and many others- are 3v. One is likely to get more support/testing from the Arduino world than from the RPi (nanoPi is worse w/r support)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes - "sends the right signals" includes that those signals have the required electrical characteristics.

 

But the point is that what the controller is is irrelevant - all that matters is that it meets the interface requirements.

 

 

EDIT

 

I have now  added it to the earlier post.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 24, 2018 - 10:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Also note that you’re not going to gain much going away from Arduino.

I really just prefer working with raw C because in our embedded systems class we used C with a TI/ARM microcontroller. I wanted to switch over to AVR because it's pretty widely used so tutorials, help, samples, etc will all be readily available. Normal Arduino code just feels a bit weird to me and I've heard that eventually you'll wanna switch away from it anyways, so may as well start out with C especially since I'm comfortable with/good at it.

Brian Fairchild wrote:
I2C search term hint... 'fleury'

Shoot the guy has a library for interacting with the LCD as well as an i2c library! Although I suppose since I'm interacting with an i2c backpack not the display directly, the i2c library is gonna be the one I need?

My guess is the i2c backpack takes in commands over i2c and sends out the appropriate ones to the LCD directly(?)

Last Edited: Wed. Jan 24, 2018 - 02:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

atmelodramatic wrote:
I really just prefer working with raw C because in our embedded systems class we used C with a TI/ARM microcontroller. I wanted to switch over to AVR because it's pretty widely used so tutorials, help, samples, etc will all be readily available. Normal Arduino code just feels a bit weird to me and I've heard that eventually you'll wanna switch away from it anyways, so may as well start out with C especially since I'm comfortable with/good at it.
Silly question then but why this particular I2c interfaced LCD?

 

Now you set yourself of developing (and that means get working) BOTH an I2C and an HD44780 stack of software at the same time.

 

Wouldn't it be easier to take this in small steps. Start by getting one of the billion different HD44780 based LCDs with the usual 4bit/8bit interface choice. Get some proven code to drive that (you already have the "Fleury" suggestion) and now you have something that works.

 

If you want to "play" with I2C then do that separately but perhaps with some "simple" I2C device such as maybe an EEPROM or an RTC or similar. Again find some good proven code for it (if you are visiting Fleury for LCD you won't have to go very much further to find some good I2C/TWI code too).

 

Once you have working LCD and simple I2C THEN is the time to combine those skills and try and sire up this I2C interfaced LCD to the AVR instead. I don't see much point. LCDs with "backpacks" (I2C or UART) are usually all about reducing the number of wires from the micro to the HD44780 but on a 328 based Arduino it's not like the wires needed for a 4bit (really 7 wire) or even 8bit LCD interface are going to "eat all the pins".

 

Things like I2C-LCD are really about putting an LCD on a limited 8/14 pin micro. So why beat yourself up when you don't have to.

 

Oh and I followed your link to the LCD on Amazon. I note it says it has a choice of I2C or SPI. Don't know about anyone else here but I'd have said SPI was about 10 times simpler to operate than I2C so if you want to stick with that LCD but reduce complexity to get it working initially I'd find out how to select SPI ! (true SPI is probably another wire/pin or two over and above I2C)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The LCD in the Amazon link is a regular 16x2 with I2C backpack.    There is no possibility of SPI or UART (Serial).

 

Arduino has libraries for controlling it seamlessly.

Codevision has libraries for controlling it seamlessly.

 

Driving the LCD is nothing more than wiggling pins in the correct order.   The backpack just means that the LCD pins are wiggled by the PCF8574 port expander.

 

I and others have published code for C.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you can write plain c with arduino (or a mixture of C and c++) as c++ was an extension of C.

 

If your setup function countains everything you should have put into the main(),

and your loop fuction is void,

result, once arduino IDE has put things together , will behave ... like classical c mùain (and you can call arduino/arduino libraries functions, concentrating on *your* idea and using other people ideas).

 

If you write plain c and keep on using arduino libraries, cheating  to be c++ :

it will work (or not, as if it were real c)

you will be frowned upon, if you show your code ....(c++ has advantages an expert can explain and youll miss them)

 

"My guess is the i2c backpack takes in commands over i2c and sends out the appropriate ones to the LCD directly(?)"

yes:

 

The https://github.com/marcoschwartz...

is i2c specific from line 260; LCd delays are consistent (at first read )

 

Fleury LCd library is very interesting if you have a LCD wired on different ports, in a random(?) order : it copes with all this trouble in a pleasant way

but here, the > 6 wires are already soldered to a I2C- parallel adapter. Hobbyists seldom wire LCD at random orders - do not use every pins-

 

You should, if you want to "get rid" of arduino libraries, choose one library to replace  and use the other -if there are no interactions- ones to debug....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Driving the LCD is nothing more than wiggling pins in the correct order. 

Indeed, though the timing also matters ...

 

See #5

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

clawson wrote:
If you want to "play" with I2C then do that separately but perhaps with some "simple" I2C device such as maybe an EEPROM or an RTC or similar.

Probably best in this case would be a PCF8574 - because:

as david.prentice wrote:
The backpack just means that the LCD pins are wiggled by the PCF8574 port expander
 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
There is no possibility of SPI or UART (Serial).
So this is false advertising? ....

 

I didn't read the complete spec (which I would do if I were actually buying it) but certainly the headline lead me to believe it had SPI. Presumably this is a vendor who possibly does not understand the different between I2C and SPI ??

 

(now that I look at that page I don't actually see a detailed tech spec or a link to PDF or anything like that - how sad).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
So this is false advertising?

Apparently so.

 

Under "Product description" it says:

Feature: This module uses only two IO ports (sic?)
Blue Balcklight.

 

Package include:
2x IIC/I2C/TWI 1602 Serial LCD module

So no mention of SPI.

 

Presumably this is a vendor who possibly does not understand the different between I2C and SPI ??

Probably.

 

now that I look at that page I don't actually see a detailed tech spec or a link to PDF or anything like that - how sad

In the 'Reviews' section:

J. Blaha, Jr wrote:

NO Instruction were included

NO software or demo scripts or links were included in the box

Does not work as expected when powered by 3.3V to the LCD (5V is really needed for power)

 

To get it working without instructions required more than an hour of frustration. 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which, again, brings us back to the issue of buying cheap stuff from such places: https://www.avrfreaks.net/comment...

 

You gets what you pays for.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 24, 2018 - 05:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
You gets what you pays for.
Not necessarily, I think its more:

You pays ya money and ya takes yer chance.

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on.   This listing is a lot more truthful than many Ebay, AliExpress, ...

I doubt if the Vendor knows what she is selling.   So it is ignorance rather than dishonesty.

 

As a general rule,   Arduino libraries are well written, reliable and many are supported  by the Library Manager.

 

Unfortunately several different "LiquidCrystal_I2C" class have been written by different third parties.    They have different incompatible constructors and methods.    Which means that a punter installs a random "LiquidCrystal_I2C" library and finds that internet example sketches use a different "LiquidCrystal_I2C".

 

The solution is to abandon "LiquidCrystal_I2C" completely and install Bill Perry's "HD44780" library from the Library Manager.

It uses unique class name(s) which stops the ambiguity problem.   And most importantly,   it can diagnose 99.5% of wiring problems.   It will even detect the device automatically.

 

Regardless of mega328, mega2560, ... it is convenient to use these I2C displays.    The wiring is straightforward i.e. SDA, SCL pins.

If you are currently using other I2C devices,   it costs zero pins.

 

Incidentally,   Arduino sketches tend to use a consistent set of drawing methods.    It tends to be constructor(), begin(), backlight() that suffer from the third party feature.    So having chosen a library,   you have to do little more than check include, constructor, begin statements.

When HD44780 gets more established it will eliminate most punters' problems.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, 1rst ro be would be to answer :

does the I2c work on this circuit? -else, remains ... nothing-

 

IIRC, I use an I2C checker (tests each possible adress) which is shipped with the Arduino IDE -and was satisfied with it.

 

its adress is https://playground.arduino.cc/Ma...

(and nice links)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, of course the I2C scanner will detect all the devices on the bus.
The bus should have external pullup resistors. Preferably a single pair.
Many I2C backpacks come with pullups.
I think your scanner will not diagnose missing pullups.
Bill Perry's diagnostic will tell you.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
The solution is to abandon "LiquidCrystal_I2C" completely and install Bill Perry's "HD44780" library from the Library Manager.

 

I looked it up and it seems that it's also an Arduino library, which means I'll probably have the same issue of getting it to work right? But like someone said earlier, interacting with the PCF8574 directly through i2c should be easy, and I think someone has done just that, so hopefully that works?

 

david.prentice wrote:
Driving the LCD is nothing more than wiggling pins in the correct order.   The backpack just means that the LCD pins are wiggled by the PCF8574 port expander.   I and others have published code for C.

 

Where have y'all published the code? It's probably what I'm looking for!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the link i gave not solve the problem? What is holding you back?
Have you tested your display using Arduino?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This package is two separate boards: a 16x2 blue background/white chars LCD using a Hitachi HD44780 controller IC and a board that converts data in I2C format into HD44780 commands.   The I2C board is helpful if you only have two Input/Output pins available, instead of the minimum of six pins that are usually used for LCD controllers (D4,D5,D6,D7, E, RS).

 

Try reviewing this website: http://learning.grobotronics.com...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Does the link i gave not solve the problem?

I don't know why but I originally had it confused with another library that was Arduino based, my bad!

I think the guy who made the project you linked actually used the library I linked just a few posts ago as well, so it definitely should do what I need!

Simonetta wrote:
The I2C board is helpful if you only have two Input/Output pins available, instead of the minimum of six pins that are usually used for LCD controllers

While the nano does have a good number of pins, I don't want a good chunk of them (roughly a third) going towards just the LCD display!

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After reading the Amazon notes these are LCD's with PCF8574 I2C I/O expanders on them.

 

Davide Gironi  modified Peter Fleurys LCD library and then added another library for the PCF8574.  I use this library and it works great!

 

HEre's the link:

 

http://davidegironi.blogspot.com...

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, thank you a lot (I will try to make my own I2C expander, though it will be more expensive than prebuild -with pull up- ones: and I guess I will forget/badly solder pullups-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The whole thing about Arduino (in fact C++ in general) is that it's about reusing code. So once someone wrote <Wire.h> and it appears to all work then the temptation of anyone working in Arduino is that whenever you need I2C support you aren't going to reimplement it all from scratch but just now rely on that "solid building block" that already exists. So if this LCD is based on I2C (and the foregoing discussion seems to suggest it is) then it's going to be natural for any support libs for it to simply re-use <Wire.h> for the I2C interface so it's kind of inevitable that you are going to find any solution relying on that part of the Arduino framework.

 

So the bottom line is that if you want to use an "Arduino library" for driving this thing then you ARE going to have to bring <Wire.h> into the solution to. As others have said AS7 has the ability to import Arduino projects and the "clever bit" that actually does is that it works down from the high level and spots all the bits of the Arduino Framework that are used and when it spots <Wire.h> it will pull the code for that into the AS7 project too.

 

So if you are going to re-use Arduino libs use the "import" and accept the fact that it will bring in some of the core bits of Arduino with it.

 

The alternative would simply to be to study the support libs that exist and where they call things like Wire.begin() or whatever then replace that and all other I2C support with your own implementation of the same in "plain C". (though "Fleury" might be able to short circuit that a bit). But if you do that I kind of wonder what is "better" about using an I2C library written in C in one place compared to one written in C++ from within Arduino?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
So if you are going to re-use Arduino libs use the "import" and accept the fact that it will bring in some of the core bits of Arduino with it.

That's actually ok with me. When I say I don't wanna use arduino I meant more that I didn't wanna use their way of programming, i.e. a setup and loop method instead of a main, their project structure, etc.

If I can have my normal C project and still can use their libraries that's the best of both worlds! Is that What importing into Atmel studio would do?

Last Edited: Thu. Jan 25, 2018 - 03:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

atmelodramatic wrote:
my normal C project and still can use their libraries
Well you can't do it in C - it has to be C++ so you can call C++ functions so that all that really changes is that setup()/loop() in project.ino becomes a main() in project.cpp

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That also is cool with me since c++ is my preferred language, although I suppose I should pay atmention to what features avr-g++ actually supports.

 

Also, are Arduino libraries reliable performance-wise? I don't know much about their i2c and the LCD libraries specifically but I saw in someone's video that the digitalWrite() function had a 3.5us delay to change the pin output when in reality after writing to the PORTx register there should only be a 2 clock cycle i.e. ~125ns delay.

 

This makes me think that while arduino libraries are easy to use, they're not very efficient. Am I right in thinking this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Arduino digitalWrite is complicated by the "standard" numbering scheme for I/Os, which calls for run time calculation of PORT and bit.

Any functions that utilize the digitalWrite internally will also be slowed by this calculation.

There is always the option of doing direct pin manipulation bypassing the digitalWrite.

The Arduino library functions I have used are robust and seem to work with reasonable performance; however, in many cases I opt for writing my own, depending on application requirements.

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

digitalWrite is not efficient because it hides a lot of detail from the user so they don't have to know what port pin is involved, but you don't have to use it, see below:

 


// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin 17 (tx led) as an output.
  pinMode(17, OUTPUT);
  PIND = (1<< PD5);   //toggle rx led off
}

// the loop function runs over and over again forever
void loop() {
  PORTB |= (1<<PB0); //digitalWrite(17, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);              // wait for a second
  PORTB &= ~(1<<PB0); //digitalWrite(17, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);              // wait for a second
}

This is the blink demo using direct to port pin code, this example is for the pro-micro.

I had to look at the schematic to see what pin D17 mapped to.

In most cases, i2C and LCD's are so slow anyway what code is used to drive it is not the bottleneck.....

 

Don't worry about efficiency, worry about making the project work, then if speed is the problem, analyze where code changes will have a real impact. 

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem with this package is that there appears to be no documentation for the board that takes the I2C/SPI signals from the CPU and converts them into HD44780 commands used by the LCD board.  The HD44780 LCD board uses a minimum of six lines in 4-bit/no R_W mode and 13 lines in full 8-bit/RW mode.  I assume that the I2C/SPI board is using at least seven lines in 4-bit/RW mode (D4:D5:D6:D7:RS:E:RW).  However, without documentation (written in English), then you aren't going to know how these seven signals are mapped to the 8-bits of the I2C data byte.  It may use all 13 lines of the full 8-bit/RW mode spread over two I2C byte writes for each LCD character update.    And you don't know how to get the I2C/SPI module board to select between using I2C or SPI as an data input source from the AVR. 
In my humble opinion, it's time to leave the LCD controllers behind and switch to TFT displays.  They look so much better and can convey much more information to the user for a given screen display.  The ST7735-based 128x160 pixel displays are about the same price as the 16x2 LCD character displays.   Where these HD44780 LCD displays are still useful is in applications that only need a 16 char by 2 line display and need to operate with small amounts of total current.  Without the backlight LED turned on, the LCD displays use the smallest amount of current in milliAmps than any other display type by an order of magnitude.  However the white character-on-blue-background LCD module included in this package needs to have the backlight LED on in order to see what the characters are.

   I recommend using the Arduino LCD library with the 6-pin minimum requirement, along with a I2C-based I/O expander for other I/O switching that the application requires.  This approach will save a lot of development time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@simonetta

If you  read the q/A the unit uses a PCF8574.  I also supplied a link to C library that uses a modified Peter Fleury LCD driver that I use myself.  

 

The unit is in actuality very easy to use if in fact it is using the PCF8574

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As the others have mentioned, digitalRead/write are slow. It was a design decision they made. That doesn’t stop you from writing direct to the port sfrs if you so desire. I2c itself is relatively slow and character lcds even slower. So you really shouldn’t be too concerned about efficiency. Most of the core Arduino libraries are basically what you’d end up writing anyhow with the benefit of a zillion people testing them and plenty of examples. So you get a choice with Arduino - fly with their libraries and have an easy path or you can go off the beaten track and roll your own or mix n match. Note the Arduino installation comes with the core library source, so there’s nothing hidden.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson wrote

"Well you can't do it in C - it has to be C++ so you can call C++ functions so that all that really changes is that setup()/loop() in project.ino becomes a main() in project.cpp"

 

Well, you can cheat *.ino into putting pure C into an *.ino file  :

 loop does not contain anything (Arduino IDE generates -to utterly simplify- a while(1 == 1) {}; loop (in fact, it is a for(;;) see my link )

setup contains everything you would have put into a main()

No function can be called main, as main already exists see 

https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/main.cpp

 

Purists can frown upon this trick, but it seems a comfortable way to evolve from Arduino to pure C (keeping functions one needs and one has not yet ported)

Then balau https://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/

showed how to strip off arduino libraries (he was a student in computer science, and would not have posted bad code ... in 2011 )

 

OTOH : c++ seems to be more complicated than C : if one  wants to learn, why not use arduino as C++ examples? 

Last Edited: Fri. Jan 26, 2018 - 09:54 AM