Compiler Bug? local arrays not initialised correctly

[pjpankhurst]

I've just ported an LCD I2C library from Arduino along with an application I have developed to Z-Uno

After many hours of debugging I have finally discovered that the compiler doesn't seem to initialise local variables correctly if they are arrays.

An example piece of code is shown below:

void ZUNO_LCD_I2C::setCursor(byte col, byte row){
/*
byte row_offsets[4] = { 0x00, 0x40, 0x14, 0x54 };
if ( row >= _numlines ) row = _numlines-1;
command(LCD_SETDDRAMADDR | (col + row_offsets[row]));
*/
switch (row)
{
case 0: command(LCD_SETDDRAMADDR | col );break;
case 1: command(LCD_SETDDRAMADDR | (col+0x40) );break;
case 2: command(LCD_SETDDRAMADDR | (col+0x14) );break;
default: command(LCD_SETDDRAMADDR | (col+0x54) );break;
}

}

In the example the commented out code is what was originally there and doesn't work, the other code is the work around.

I have found similar issues in my own code, which I (bodge) fixed by moving the variables out of the function to make them global.

Any ideas whats going on here? Is this a bug in the compiler or some limitation I'm not aware of?

Cheers
Paul

[PoltoS]

is it on v2.1.1? in v2.1.0 we had a bug with local arrays not assigned

[pjpankhurst]

That would explain it, I was on v2.1.0

Will re-test it on 2.1.1 and verify the issue is solved

Thanks

[PoltoS]

Thanks! Seeking for a confirmation

[pjpankhurst]

I updated to 2.1.1 and Arduino 1.8.5..

The good news is it seems to have fixed some strange stability issues I was having since the port from Arduino. It does also seem to fix the initialisation problem on a piece of code I reverted back.

However, when reverting the piece of code in the example above it doesn't compile anymore. I assume the fix was in the translator, did the code parser change too?

I get the following:

ZUNO_LCD_I2C_ucxx.c:788: error 20: Undefined identifier '__xloc____cxx__ZUNO_LCD_I2C__method__setCursor_020505__urow_offs'

ZUNO_LCD_I2C_ucxx.c:788: error 22: Array or pointer required for '[]' operation

ZUNO_LCD_I2C_ucxx.c:788: error 45: operand invalid for bitwise operation

ZUNO_LCD_I2C_ucxx.c:788: warning 113: left & right types are

void,const-unsigned-char literal

Error. SDCC returned: 1

[p0lyg0n1]

Looks like a mangling problem in compiler. We didn't test new local array features with long method names. Can you provide a code of library for tests?

[pjpankhurst]

Copy of the library attached, its a port of the following:

https://github.com/marcoschwartz/LiquidCrystal_I2C/

I was going to push it back to the community once it was fully debugged.

On the old release of z-uno I had some stability problems with it, but they seem to have gone now, though I haven't tried printing out floats since the upgrade, which definitely had an issue before.

Also the print(c) in the printstr method is commented out as the compiler objected to that and I didn't get round to resolving it.

[p0lyg0n1]

Hi, I don't have any hardware to test it... I reworked the code to improve the stack usage. You can see the main ideas of auxilary methods, globals variables for parameter translation, decorating macroses instead of inlines etc. We use this approach in our libraries. Now your library compiles ok. You are right the mangling of local arrays doesn't work for methods (the functions is ok). We will fix this issue in the next release. The "workaround" was added currently . Please check this library with your hardware. I could broke something, but the code have to be clean enough to fix it yourself.
This is my test sketch (I never used this library & this LCD before, so maybe it's not a production variant I don't know the I2C address of the display module, 0x7a is "something for test" ):

Code: Select all

#include <ZUNO_LCD_I2C.h>
ZUNO_LCD_I2C lcd(0x7A, 10, 4);
// the setup function runs once, when you press reset or power the board
void setup() {
  lcd.init();
}
// the loop function runs over and over again forever
void loop() {
  lcd.println("Hello WORLD!!!");
  lcd.setCursor(2,2);
  lcd.printstr("Some string");
}

I am sorry, we have a big challenge with S2 now and I can't answer here often.

[pjpankhurst]

Hi,
Thanks for that, I'll test it as soon as I get a chance.
The LCD I was driving is quite a common device.. the LCD is a 2004A with an LCM1602 IC2 backpack on it (uses a PCF8574T chip).
Plenty of them cheap on Ebay if anyone wants one.

[petergebruers]

Thanks, p0lyg0n1. I did a quick test and it is OK. Ik can turn on the back-light, print some text and 2 floats. Display is a "1602" type connected to a PCF8574 chip like pjpankhurst mentioned.
I understand the strategy used to limit stack usage, I am going the same route with the ADS1115 lib that I am writing...