Arduino uno and Adafruit rgblcdshield

Projects Programming
1

The following code produces unexpected results depending on which character is chosen for lcd.print from a char array that has up to 9 elements. Four of the locations print as expected, but three of them print the correct data preceded by 6 F's.

Why are the F's showing up for some of the lcd.print's

#include <Adafruit_MCP23017.h>
#include <Adafruit_RGBLCDShield.h>

char command[9];

void setup() {
Adafruit_RGBLCDShield lcd = Adafruit_RGBLCDShield();
lcd.begin(16, 2);
}

void loop() {
sprintf(command, "%c%c%c%c%c%c%c%c", 0xE1, 0x94, 0x0, 0x0, 0x0, 0x0, 0x0A, 0x80);
lcd.clear();
lcd.print(command[0], HEX); //print command[0] thru command[7] foe following results
}

// Print instruction Output results
// lcd.print(command[0], HEX); = FFFFFFE1
// lcd.print(command[1], HEX); = FFFFFF94
// lcd.print(command[2], HEX); = 0
// lcd.print(command[3], HEX); = 0
// lcd.print(command[4], HEX); = 0
// lcd.print(command[5], HEX); = 0
// lcd.print(command[6], HEX); = A
// lcd.print(command[7], HEX); = FFFFFF80

2

It looks like it's upgrading the chars to long integers when it does the HEX output. A long has 4 bytes, or 8 hex digits.

Note that char is a signed datatype. If a char has a 1 in the first bit position then it's negative and expanding it out to a long requires 1 to be repeated all the way to the left so that the first bit of the long is also 1. This then comes out as a "F" digit in hex.

If you declare the command[] array to be an array of bytes, then that's unsigned and the sign-extension doesn't happen when it's converted to a different type.

I'm not sure why it's expanding the chars to long.

3

I can see you are correct. Whenever there is a 1 in the first position it expands to a long. I tried to make the array bytes instead of char but ran into a bunch of type mismatches in other parts of the program that even explicit conversions didn't seem to fix.

I would appreciate it if someone could help find an answer to this problem. Here is the entire code so its all in context.

Thanks

Si4844.ino (7.86 KB)

4

I ended up fixing this by creating a function to convert the character to a byte before printing it to the LCD.