@JohnTheCoolingFan @vcrn After the changes for the i2c support, I think we can bump the project to 0.2 and release it on crates.io. I'm not sure what the process should be for when new releases should happen though. Thoughts?

As it stands, with_reliable_init is supposed to be called during construction, as closely as possible to build. Rather than worry about the order of the with_* methods, maybe it should just be another, mutually-exclusive build function that internally calls the first build, then toggles the display some number of times, then returns. The name could be something like build_toggled or build_init or maybe build_stable.

It may also be worth adding a initialize or stabilize method that does the same thing, so that the build method could just call the first build, then call the function, then return.

Normally, you can run examples with-

cargo run --example <example name>

Some crates, for example tokio and mlua have "this is available only with feature X enabled" badge on some types/functions/macros. Since disabled by default i2c module was added, it does not show in docs. Of course, there is a mention of such functionality so it won't disappear from docs completely, but I think adding API docs would be helpful for those who want to use it.

More info on how it's done: https://stackoverflow.com/questions/61417452/how-to-get-a-feature-requirement-tag-in-the-documentation-generated-by-cargo-do

Add a GitHub actions workflow which runs cargo build --all-features (#39)

The latest ravedude (v0.1.4) can't flash to Arduino Nano boards that uses the new bootloader (manufactured after January 2018, if I've understood it correctly). A solution has been implemented in ravedude (Rahix/avr-hal#247) but has not been released yet.

When a new version of ravedude is released, you'll be able to flash to the newer Nano boards with ravedude nano-new. At that point, it's probably a good idea to either put a note in the examples/README explaining how to modify the provided Nano examples, or copy-paste the examples and simply change the argument in the runners.

In the meantime, there's a workaround: change the argument to ravedude from nano to uno, or clone the latest commit of ravedude and use it to flash your board.

I've asked the maintainer of ravedude if they have some estimate of when the new version is to be released.

Has someone a working ESP32 example? I don't get it to work...

let peripherals = Peripherals::take();
let system = peripherals.SYSTEM.split();
let clocks = ClockControl::max(system.clock_control).freeze();
let mut delay = Delay::new(&clocks);

let io = IO::new(peripherals.GPIO, peripherals.IO_MUX);

let mut input = io.pins.gpio21.into_open_drain_output();
let mut i2c = I2C::new(
    peripherals.I2C0,
    io.pins.gpio14,
    io.pins.gpio13,
    100u32.kHz(),
    &clocks,
);
let mut i2c_expander = pcf8574::Pcf8574::new(i2c, true, true, true);
let mut lcd = LcdDisplay::new_pcf8574(&mut i2c_expander, delay)
    .with_cursor(Cursor::On)
    .with_display(Display::On)
    .with_blink(Blink::On)
    .with_lines(Lines::TwoLines)
    .with_cols(16)
    .build();
lcd.clear();
lcd.print("Test message!");

I don't get errors, but nothing is displayed.

So I am just getting started with embedded rust and while trying to use my lcd screen, as seen in the README.md I can't find the
LcdDisplay::new_pcf8574() function anywhere?
Neither does my programm compile, nor can't I find any reference to it in the documentation! What am I missing?

This is a request for support of connecting the display using PCF8574 I2C expander board. If there is an alternative crate (that supports both 16x2 and 20x4), please point me to it.

With #5 merged, there is not an uno subdirectory with an uno example. I'd prefer that the rest of the examples be moved into a nano subdirectory.

According to #42, ag-lcd doesn't build with the latest version of port-expander (0.5), but is only compatible with 0.3.

The nano example of using I2C should also be updated when this is done, as should any doc examples

I'm not sure that they do, currently.

Currently, to handle pins for the bus, all pins have to be downgraded and then passed to the .with_half_bus/.with_full_bus functions. I'd like to not have to downgrade, but I don't know if it's possible.

During review of a PR, @JohnTheCoolingFan and I discussed merging the two implementations of LcdDisplay by relaxing the requirements on the output pins. This issue is to investigate that and see if it's possible, then implement it if it is.

Description

Following the example, it worked very fine (arduino uno) but it when i reboot my arduino (disconnect from power and power back on), it displays no text.

In order to be sure, i reproduced the same thing in the arduino IDE, and this issue doesn't exist. Also, in order to debug this issue, i added a simple blinking LED and tried again and it works (the LED blinks) but the display is still blank. Thats why I am pretty sure the issue is with this driver.

It'd be great to get pointers to implement a fix if you're too busy to work on something like this right now. I'd take the issue on, with guidance.

Hey!

Thanks for putting this crate together. It's straightforward and just works.

Today, I tested this crate on my Arduino UNO (with my 1602 display). It works flawlessly.

(This is not really an issue, but just letting you know it works as you only tested on a nano)

Check out the embedded-hal-mock lib and see if we can use it for doc/integration testing.

The crate can only control one or two lines of an LCD.

I'll probably have a LCD with 4 lines soon, and will look into if I can implement the functionality to control all 4 lines.

Most of these could probably have an inline declaration. I'm not sure if it would hurt anything to do it for every function, actually, but for now, all of the getters and setters could be marked for inlining- set_blink, blink_off, set_position etc.

With error:

Error: Error: ENOENT: no such file or directory, scandir '/home/runner/work/ag-lcd/ag-lcd/target/avr-atmega328p/doc'

Almost all Cargo.toml files says the edition is 2018, but seems to be 2021. Is this correct? If yes, it should be updated.

This project builds with nightly because of an issue in rustc that appears to have been resolved. I need to build with stable and see if it works.