LCD support hangs ATmega about repetier-firmware

[SCUBA82]

Unfortunately I have to join this issue.
I'm also using a PCF8574 portexpander which works fine with some example code.
Like peter to only response I get from repetier fw is "start" when I active the i2c lcd option. The problem is persistent between my GEN7 and my Arduino Mega1280.
What I've tried so far:

• corrected the i2c pin definition to my setup

• played around and double checked the i2c address as suggested (has to be 0x40 in my case).

• deactivated the i2c beeper, i2c keys and i2c encoder (thought they might interfere with each other).

• For GEN7 I've defined the SDA (17) and SCL (16) Pins in pins.h.

• tried different arduino ide's

  The only parameter's I'm not sure about are "UI_DISPLAY_I2C_OUTPUT_PINS " , "UI_DISPLAY_I2C_OUTPUT_START_MASK" and "UI_DISPLAY_I2C_PULLUP". So i haven't changed them.

Is this issue allready confirmed as a bug or are we still missing something in our config?

[repetier]

The values UI_DISPLAY_I2C_OUTPUT_PINS " , "UI_DISPLAY_I2C_OUTPUT_START_MASK" and "UI_DISPLAY_I2C_PULLUP are not needed for PCF, these are for MCP where you need to declare output pins in setup.

If you only see the start and then firmware hangs, the display is not responding as expected. The I2C communication fails to talk with the device. Make sure speed is set to 100000 hz.Also make sure SDA/SCL are the hardware i2c pins, but for gen7 16,17 should be the right one.
Have you already tried addresses 0x40 till 0x4e for PCF8574 This only works with UI_DISPLAY_TYPE 3, which is what I normally use with my i2c displays.

[SCUBA82]

I've seen the comments for UI_DISPLAY_I2C_OUTPUT_PINS and UI_DISPLAY_I2C_PULLUP but wasn't sure if there is any relation with the PCF too.
As far as i can see UI_DISPLAY_I2C_OUTPUT_START_MASK is used during i2c_init(void) which seems to set the uid.outputMask also for PCF configuration. But "0" might be correct here?

Yes, I've tried every possible i2c address (also those for the PCF8574A Version ... who knows ;-) ) Clockspeed is on 100000L (as default) and I've also corrected the SDA/SCL Pin definition in sd2pinmap.h although it might have nothing to do with the lcd part ( for atmega644 & 1284 they were defined with "uint8_t const SDA_PIN = 17; uint8_t const SCL_PIN = 18; there). In pins.h and fastio.h they are also correctly defined (hope pins.h is the master config?)

Thank you again for your help!

For what it's worth, once I got the addressing under the knee, it worked
liked a Charm! Don't dabble too much, just get the address correct and
wiring correct. I disabled RW pin and tied to ground if that helps

Peter

SCUBA82 [email protected] 11/27/12 12:09 PM >>>
I've seen the comments for UI_DISPLAY_I2C_OUTPUT_PINS and
UI_DISPLAY_I2C_PULLUP but wasn't sure if there is any relation with the
PCF too.
As far as i can see UI_DISPLAY_I2C_OUTPUT_START_MASK is used during
i2c_init(void) which seems to set the uid.outputMask also for PCF
configuration. But "0" might be correct here?
Yes, I've tried every possible i2c address (also those for the PCF8574A
Version ... who knows ;-) ) Clockspeed is on 100000L (as default) and
I've also corrected the SDA/SCL Pin definition in sd2pinmap.h although
it might have nothing to do with the lcd part ( for atmega644 & 1284
they were defined with "uint8_t const SDA_PIN = 17; uint8_t const
SCL_PIN = 18; there). In pins.h and fastio.h they are also correctly
defined (hope pins.h is the master config?)
Thank you again for your help!
—
Reply to this email directly or view it on GitHub.

BrainShare Link for Credit Card Payments: http://gst.to/1ic9w
BrainShare Link for Invoice Based Payments:
https://team.netcb.com/bs2013ttt
GWAVA Event - Pretoria 6 December 2012 - http://gst.to/bmqpt
GWAVA Event - Dar es Salaam 7 December 2012 - http://gst.to/m43c8

NETCB Limited | The Innovation Hub, Enterprise Building, 1st Floor, Unit
L15, Lynnwood, Pretoria | P.O. Box 100, The Innovation Hub, Pretoria,
0087, SOUTH AFRICA | Tel. [phone] | Fax. [phone] |
Directors: JP Burgers, H de Bruin, JC du Toit, J Foxcroft

[SCUBA82]

Hi peter! So this means your i2c Display allready works? wasn't sure about it cause the issue is still open.
Disabling the R/W Pin is something I haven't tried yet. Thank's for that. I remember repetier mentioned the "RS" pin in the forum but that must have been a typo.
I'll let you know how things go on.
Thank you all for your help!!

[SCUBA82]

No luck so far... started with a fresh fw, did only the configuration for my setup and tried each possible i2c address.. without any change. Tied the R/W to ground and disabled it's definition in fw and again tested each adress... nothing. Again tried the example i2c lcd program and it just works. (With 0x20)
I see that it might be only an addressing issue but I wasn't able to figure out the right one.

Next I'll disable the i2c lcd and only activate the i2c beeper/encoder to see if there's also a avr hang condition on this.

Just for my understanding:
@repetier: your wrote: "The original arduino libraries take an other address range, beacuse they take the half of the value."
Regarding to the datasheet of the PCF8574, it's address should be defintily 0x20 (with all A's to ground) and not 0x40. Is there a reason why you use duplicated values for the PCF8574 addressing and original values for the PCF8574A ?? (PCF8574A uses one more bit for addressing)

(Anyhow I've also tried the address range from 0x20 to 0x27 without any success... )

[repetier]

The first byte send is the address + read/write bit. The read/write bit is the least significant. I didn't want to always shift the address one bit left, so the shifted address without LSB bit set is the address used for type 3. You could also try type 4 which uses the liquid crystal library you used for testing. But make sure to include it in Repetier.pde so it gets included.

One other thing that could be is the timing for initalization. I tested it for several displays with success, but I already inserted some wait statements as you can see in the code. Perhaps you need some more waits. (see ui.cpp)

[boelle]

i wonder if @ghost still have an issue here?

if no one has the issue it could be closed and short up the list