I2C Display Support

[Traumflug]

It escaped me for a while, somebody pushed code for I2C display support to the repo recently. Thank you for this!

Now, the unfortunate thing is, judging by the commit messages it apparently doesn't work, yet, still it went straight to branch experimental. So I did the following:

• Made a copy of experimental and named it i2cdisplay.
• Pushed this copy.
• Restored the former branch experimental.

With this done, it's a proper topic branch now. For those who fetched/pulled experimental recently, please do the following:

• If you made local commits on top of experimental, make patches from them with

git checkout experimental
git format-patch --keep-subject origin/experimental

• In any case, remove the local branch experimental then:

git branch -D experimental

• Then restore from the remote branch:

git fetch
git checkout -b origin/experimental
git checkout -b origin/i2cdisplay

• In case there were local branches, apply them on top of i2cdisplay with git am.

After having this done, branch i2cdisplay is exactly what was experimental before.

This new branch has a number of, well, messy commits, but also quite a number of good ones. I'll try to sort this before too long. The general implementation strategy looks very good!

... now scratching my head where I could find a device supporting I2C to allow testing ... :-)

[Traumflug]

Nice!

TBH, I couldn't resist to look into additional fonts, too, and found a whole lot of them on retro-gaming sites like this or this (650+ 8-bit fonts!). Even a converter for creating C files from pictures exists: Bitmap Converter.

Anyways. One thing I'm a bit unsure about is, how should we deal with Configtool? It's pretty obvious that people like you and me and @phord happily hack away on the firmware, but have or see little gain in adjusting Configtool, too. We put our extra #define into config.h somewhere and are done. On the other end of the spectrum we have users which barely manage to start a Python application. Those won't make Configtool more complete either. Configtool is a great thing, but it tends to fall behind.

Question: should we insist on new code to have an entry in Configtool before moving it to experimental/master? Or is it fine to have such technology inaccessible to generic users?

[Wurstnase]

Bitmap Converters are everywhere :)

I'm not very familiar with configtool. Last adaption costs me a lot of hours for just one additional drop down. The minimum requirement should be a TODO in the commits.

Edit: More tools

[Wurstnase]

How does the SSD1306 change its pixel in vertical or horizontal mode?

---->  ---->  ^ ^ ^ ^
---->  <----  | | | |
---->  ---->  | | | |
---->  <----  | | | |

other direction?

[phord]

One thing I'm a bit unsure about is, how should we deal with Configtool? It's pretty obvious that people like you and me and @phord happily hack away on the firmware, but have or see little gain in adjusting Configtool, too. We put our extra #define into config.h somewhere and are done. On the other end of the spectrum we have users which barely manage to start a Python application. Those won't make Configtool more complete either. Configtool is a great thing, but it tends to fall behind.

I think it's a good policy to require developers to update ConfigTool to match their code changes. But in practice I think it's ok to make that a complaining policy. Such as, "Thanks for adding this cool new feature. Please add it to configtool so we can accept it into the mainline." And then later, "Ok, I understand ConfigTool is obtuse and you don't speak python. I've added it for you here. Please review and tell me if I misunderstood."

But what I would really prefer is for ConfigTool to learn its options from the header files. It already learns the help text there. I agree it would be overkill to reinvent a GUI description language inside comments in the config headers. Some things would never make sense, such as the adjustPinVisibility function, and we would always tweak them in python. But the DISPLAY_TYPE options seem trivial to "learn" from board.generic.h. It might help us remember to keep the Doxygen current, too, if Doxygen-blocks was where it learned it from.

[Traumflug]

But what I would really prefer is for ConfigTool to learn its options from the header files. It already learns the help text there. I agree it would be overkill to reinvent a GUI description language inside comments in the config headers.

I hope the idea of Configtool is more than just adding some GUI-sugar on top of headers. A tool with just 1:1 relationships could be done easier. Configtool can do much more than just flipping switches, it also has the power to do things graphically (think of endstop locations, build room size defined by dragging them in a drawing), to do calculations (think of steps/mm calculator, thermistor table creation) or to give step by step instructions during printer setup. IMHO, the number of checkboxes and choices would not increase, but reduce over time :-)

Is creating a one-click printer setup a solvable problem?

What I can do is to look up a few commits which add a choice or a checkbox and tag them. Configtool code is pretty repeating, so procedures can be repeated at another location for another #define.

Other than that I agree, making inclusion into Configtool mandatory is asking a lot. Probably too much. Having a Github issue here makes sure such things don't get forgotten.

[Traumflug]

Bitmap Converters are everywhere :)

D'oh. One simply has to save in XBM format. That's indeed easy :-)

[Wurstnase]

While trying to make a bmp-parser I test my code. Unfortunately I've got not that what I've expected.

This code in display-tick (of cause display_low_code is extended with low_code_logo)

      case low_code_logo:
        // Set horizontal adressing mode.
        displaybus_write(0x00, 0);
        displaybus_write(0x20, 0);
        displaybus_write(0x00, 1);

        displaybus_write(0x40, 0);
        for (i = 0; i < 512; i++) {
          displaybus_write(pgm_read_byte(&logo2[i]), (i == 511));
          if (pgm_read_byte(&logo2[i]) != 0xFF)
            debug++;
          if (i == 511)
            sersendf_P(PSTR("i = %su\ndebug: %u\n"), i, debug);
        }

        displaybus_write(0x00, 0);
        displaybus_write(0x20, 0);
        displaybus_write(0x02, 1);
        break;

prduces 384 non-0xFF-values while the complete array is 0xFF:

static const uint8_t PROGMEM logo2[] = {
0xFF, 0xFF...
};

What's going wrong here?

[phord]

How big is logo2's initializer list? What is the index of the FIRST non-0xFF byte?

I assume you checked that you initialized 'debug=0' somewhere, yes?

I'm not familiar with "%su", but I do see it in sendf.c. Still, I would also be suspicious of it unless I used it a lot already.

[Wurstnase]

logo2 has 512x 0xFF. debug is set to 0. With my first test I print any byte where I saw this issue. I thought this could be the issue I changed the code to count only non-0xFF-values.

I changed a little bit the debug code and print every i again. with PROGMEM:

0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xA6 0x2E 0xAF 0x01 0x01 0x01 0x01 
0x01 0x01 0x01 0x01 0x01 0x01 0x02 0x02 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x04 0x02 0x01 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x02 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x02 0x01 0x01 0x01 0x01 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 0x00 0x00 0x01 0x07 0x01 0x02 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x00 0x00 0x01 
0x01 0x01 0x01 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 
0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x06 0x01 0x01 0x01 0x02 0x01 0x03 0x03 0x02 0x02 0x01 0x01 0x01 0x03 0x02 0x00 0x00 0x00 0x05 0x01 0x01 0x02 0x01 0x01 0x04 0x02 0x02 0x03 
0x00 0x03 0x01 0x00 0x01 0x01 0x00 0x00 0x03 0x01 0x01 0x01 0x02 0x03 0x02 0x03 0x03 0x00 0x05 0x02 0x02 0x01 0x07 0x03 0x00 0x01 0x00 0x06 0x00 0x00 0x04 0x01 
0x01 0x02 0x01 0x02 0x07 0x02 0x00 0x01 0x02 0x02 0x01 0x04 0x03 0x05 0x00 0x00 0x00 0x00 0x06 0x03 0x02 0x02 0x02 0x03 0x05 0x02 0x01 0x01 0x00 0x00 0x00 0x01 
0x01 0x02 0x02 0x01 0x02 0x03 0x01 0x01 0x01 0x02 0x03 0x05 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 

i = 255
debug: 384

without PROGMEM:

0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x47 0xE2 0x74 0x07 0x41 0xE0 0x84 0x07 0x91 
0x05 0xA8 0xF4 0x20 0x51 0x37 0x42 0x30 0x93 0x89 0x00 0x20 0x93 0x88 0x00 0xDC 0x01 0xCB 0x01 0x80 0x5F 0x98 0x4D 0xAF 0x4F 0xBF 0x4F 0x80 0x93 0xEB 0x04 0x90 
0x93 0xEC 0x04 0xA0 0x93 0xED 0x04 0xB0 0x93 0xEE 0x04 0x04 0xC0 0x30 0x93 0x89 0x00 0x20 0x93 0x88 0x00 0x80 0x91 0x6F 0x00 0x82 0x60 0x80 0x93 0x6F 0x00 0x80 
0xE0 0x08 0x95 0x08 0x95 0x10 0x92 0x6F 0x00 0x08 0x95 0xAA 0x1B 0xBB 0x1B 0x51 0xE1 0x07 0xC0 0xAA 0x1F 0xBB 0x1F 0xA6 0x17 0xB7 0x07 0x10 0xF0 0xA6 0x1B 0xB7 
0x0B 0x88 0x1F 0x99 0x1F 0x5A 0x95 0xA9 0xF7 0x80 0x95 0x90 0x95 0xBC 0x01 0xCD 0x01 0x08 0x95 0xA1 0xE2 0x1A 0x2E 0xAA 0x1B 0xBB 0x1B 0xFD 0x01 0x0D 0xC0 0xAA 
0x1F 0xBB 0x1F 0xEE 0x1F 0xFF 0x1F 0xA2 0x17 0xB3 0x07 0xE4 0x07 0xF5 0x07 0x20 0xF0 0xA2 0x1B 0xB3 0x0B 0xE4 0x0B 0xF5 0x0B 0x66 0x1F 0x77 0x1F 0x88 0x1F 0x99 
0x1F 0x1A 0x94 0x69 0xF7 0x60 0x95 0x70 0x95 0x80 0x95 0x90 0x95 0x9B 0x01 0xAC 0x01 0xBD 0x01 0xCF 0x01 0x08 0x95 0x05 0x2E 0x97 0xFB 0x1E 0xF4 0x00 0x94 0x0E 
0x94 0x37 0x1C 0x57 0xFD 0x07 0xD0 0x0E 0x94 0xFE 0x1B 0x07 0xFC 0x03 0xD0 0x4E 0xF4 0x0C 0x94 0x37 0x1C 0x50 0x95 0x40 0x95 0x30 0x95 0x21 0x95 0x3F 0x4F 0x4F 
0x4F 0x5F 0x4F 0x08 0x95 0x90 0x95 0x80 0x95 0x70 0x95 0x61 0x95 0x7F 0x4F 0x8F 0x4F 0x9F 0x4F 0x08 0x95 0xEE 0x0F 0xFF 0x1F 0x05 0x90 0xF4 0x91 0xE0 0x2D 0x09 
0x94 0xA2 0x9F 0xB0 0x01 0xB3 0x9F 0xC0 0x01 0xA3 0x9F 0x70 0x0D 0x81 0x1D 0x11 0x24 0x91 0x1D 0xB2 0x9F 0x70 0x0D 0x81 0x1D 0x11 0x24 0x91 0x1D 0x08 0x95 0x0E 
0x94 0x45 0x1C 0xA5 0x9F 0x90 0x0D 0xB4 0x9F 0x90 0x0D 0xA4 0x9F 0x80 0x0D 0x91 0x1D 0x11 0x24 0x08 0x95 0xB7 0xFF 0x0C 0x94 0x54 0x1C 0x0E 0x94 0x54 0x1C 0x82 
0x1B 0x93 0x0B 0x08 0x95 0x2F 0x92 0x3F 0x92 0x4F 0x92 0x5F 0x92 0x6F 0x92 0x7F 0x92 0x8F 0x92 0x9F 0x92 0xAF 0x92 0xBF 0x92 0xCF 0x92 0xDF 0x92 0xEF 0x92 0xFF 
0x92 0x0F 0x93 0x1F 0x93 0xCF 0x93 0xDF 0x93 0xCD 0xB7 0xDE 0xB7 0xCA 0x1B 0xDB 0x0B 0x0F 0xB6 0xF8 0x94 0xDE 0xBF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 

i = 255
debug: 380

[triffid]

perhaps try with &(logo2[i]) in case the compiler is interpreting it as (&logo2)[i] - no type checking since pgmread family is macros which include cast to uint16 or uint32 depending on target chip.

Also, in the projects where I use PROGMEM it goes after the variable name rather than before, ie const uint8_t logo2[] PROGMEM = { ... }

not sure if either of these is your problem, but I use PROGMEM all over the place without issues

On 23 August 2016 at 14:58, Wurstnase notifications@github.com wrote:

logo2 has 512x 0xFF. debug is set to 0. With my first test I print any byte where I saw this issue. I thought this could be the issue I changed the code to count only non-0xFF-values.

I changed a little bit the debug code and print every i again. with PROGMEM:

0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xA6 0x2E 0xAF 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x02 0x02 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x04 0x02 0x01 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x02 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x01 0x01 0x01 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 0x00 0x00 0x01 0x07 0x01 0x02 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x06 0x01 0x01 0x01 0x02 0x01 0x03 0x03 0x02 0x02 0x01 0x01 0x01 0x03 0x02 0x00 0x00 0x00 0x05 0x01 0x01 0x02 0x01 0x01 0x04 0x02 0x02 0x03 0x00 0x03 0x01 0x00 0x01 0x01 0x00 0x00 0x03 0x01 0x01 0x01 0x02 0x03 0x02 0x03 0x03 0x00 0x05 0x02 0x02 0x01 0x07 0x03 0x00 0x01 0x00 0x06 0x00 0x00 0x04 0x01 0x01 0x02 0x01 0x02 0x07 0x02 0x00 0x01 0x02 0x02 0x01 0x04 0x03 0x05 0x00 0x00 0x00 0x00 0x06 0x03 0x02 0x02 0x02 0x03 0x05 0x02 0x01 0x01 0x00 0x00 0x00 0x01 0x01 0x02 0x02 0x01 0x02 0x03 0x01 0x01 0x01 0x02 0x03 0x05 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

i = 255 debug: 384

without PROGMEM:

0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x47 0xE2 0x74 0x07 0x41 0xE0 0x84 0x07 0x91 0x05 0xA8 0xF4 0x20 0x51 0x37 0x42 0x30 0x93 0x89 0x00 0x20 0x93 0x88 0x00 0xDC 0x01 0xCB 0x01 0x80 0x5F 0x98 0x4D 0xAF 0x4F 0xBF 0x4F 0x80 0x93 0xEB 0x04 0x90 0x93 0xEC 0x04 0xA0 0x93 0xED 0x04 0xB0 0x93 0xEE 0x04 0x04 0xC0 0x30 0x93 0x89 0x00 0x20 0x93 0x88 0x00 0x80 0x91 0x6F 0x00 0x82 0x60 0x80 0x93 0x6F 0x00 0x80 0xE0 0x08 0x95 0x08 0x95 0x10 0x92 0x6F 0x00 0x08 0x95 0xAA 0x1B 0xBB 0x1B 0x51 0xE1 0x07 0xC0 0xAA 0x1F 0xBB 0x1F 0xA6 0x17 0xB7 0x07 0x10 0xF0 0xA6 0x1B 0xB7 0x0B 0x88 0x1F 0x99 0x1F 0x5A 0x95 0xA9 0xF7 0x80 0x95 0x90 0x95 0xBC 0x01 0xCD 0x01 0x08 0x95 0xA1 0xE2 0x1A 0x2E 0xAA 0x1B 0xBB 0x1B 0xFD 0x01 0x0D 0xC0 0xAA 0x1F 0xBB 0x1F 0xEE 0x1F 0xFF 0x1F 0xA2 0x17 0xB3 0x07 0xE4 0x07 0xF5 0x07 0x20 0xF0 0xA2 0x1B 0xB3 0x0B 0xE4 0x0B 0xF5 0x0B 0x66 0x1F 0x77 0x1F 0x88 0x1F 0x99 0x1F 0x1A 0x94 0x69 0xF7 0x60 0x95 0x70 0x95 0x80 0x95 0x90 0x95 0x9B 0x01 0xAC 0x01 0xBD 0x01 0xCF 0x01 0x08 0x95 0x05 0x2E 0x97 0xFB 0x1E 0xF4 0x00 0x94 0x0E 0x94 0x37 0x1C 0x57 0xFD 0x07 0xD0 0x0E 0x94 0xFE 0x1B 0x07 0xFC 0x03 0xD0 0x4E 0xF4 0x0C 0x94 0x37 0x1C 0x50 0x95 0x40 0x95 0x30 0x95 0x21 0x95 0x3F 0x4F 0x4F 0x4F 0x5F 0x4F 0x08 0x95 0x90 0x95 0x80 0x95 0x70 0x95 0x61 0x95 0x7F 0x4F 0x8F 0x4F 0x9F 0x4F 0x08 0x95 0xEE 0x0F 0xFF 0x1F 0x05 0x90 0xF4 0x91 0xE0 0x2D 0x09 0x94 0xA2 0x9F 0xB0 0x01 0xB3 0x9F 0xC0 0x01 0xA3 0x9F 0x70 0x0D 0x81 0x1D 0x11 0x24 0x91 0x1D 0xB2 0x9F 0x70 0x0D 0x81 0x1D 0x11 0x24 0x91 0x1D 0x08 0x95 0x0E 0x94 0x45 0x1C 0xA5 0x9F 0x90 0x0D 0xB4 0x9F 0x90 0x0D 0xA4 0x9F 0x80 0x0D 0x91 0x1D 0x11 0x24 0x08 0x95 0xB7 0xFF 0x0C 0x94 0x54 0x1C 0x0E 0x94 0x54 0x1C 0x82 0x1B 0x93 0x0B 0x08 0x95 0x2F 0x92 0x3F 0x92 0x4F 0x92 0x5F 0x92 0x6F 0x92 0x7F 0x92 0x8F 0x92 0x9F 0x92 0xAF 0x92 0xBF 0x92 0xCF 0x92 0xDF 0x92 0xEF 0x92 0xFF 0x92 0x0F 0x93 0x1F 0x93 0xCF 0x93 0xDF 0x93 0xCD 0xB7 0xDE 0xB7 0xCA 0x1B 0xDB 0x0B 0x0F 0xB6 0xF8 0x94 0xDE 0xBF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

i = 255 debug: 380

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/190#issuecomment-241644025, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKBGp9yJGtV6XakBP_cCjP5pmEDy9Bjks5qipn5gaJpZM4GfW7z .

[Wurstnase]

Everything is the same.

pgm_read_byte(&(logo2[i]))
pgm_read_byte(&logo2[i])

const uint8_t logo2[] PROGMEM
const uint8_t PROGMEM logo2[]
const PROGMEM uint8_t logo2[]
PROGMEM const uint8_t logo2[]

This array works:

0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 
0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, 
0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 
0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 
0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 
0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0x7f, 
0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f, 
0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f, 
0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, 0xa8, 0xa9, 0xaa, 0xab, 0xac, 0xad, 0xae, 0xaf, 
0xb0, 0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7, 0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf, 
0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 
0xd0, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, 0xdf, 
0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef, 
0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff, 
0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 
0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, 
0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 
0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 
0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 
0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0x7f, 
0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f, 
0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f, 
0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, 0xa8, 0xa9, 0xaa, 0xab, 0xac, 0xad, 0xae, 0xaf, 
0xb0, 0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7, 0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf, 
0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 
0xd0, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, 0xdf, 
0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef, 
0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff

When I setup the array to uint16_t and cast it after pgm_read_word again to uint8_t the 0xFF-array works also.

[phord]

Interesting. Can you reliably read an array of 256 uint16's?

What version is your avr-gcc compiler?

[Wurstnase]

avr-gcc.exe (WinAVR 20100110) 4.3.3

512 uint16_t's is ok.

It looks like, the compiler won't overwrite the PROGMEM not any time. I initialized the second array with 0x00-0xff and after that I've taken again the 0xff-array. But the most value stays at 0x00-0xff. Only the first values until 0x39 and the last values from 0xb8 are then 0xff.

[Wurstnase]

Ah not. I test it now with avr-gcc.exe (WinAVR 20100110) 4.3.3. First values up to 0x74 is 0xff and last values from 0x38 is 0xff.

The other tests were on avr-gcc.exe (GCC) 4.9.2 the current AVR-GCC from arduino.cc.

[Traumflug]

You do this on real hardware, right? Using SimulAVR has always a chance of tripping over a simulator bug.

Then I'd look into the generated assembly, the .s file. Initialised variables are at the end, search for 'logo2:'. This is 1:1 what goes into the binary.

[Wurstnase]

Right, I do this on real hardware. It is an original Arduino Nano with Atmega328p. The assembly shows me correct values (.byte -1 for 0xff)

[Wurstnase]

0x7F or 0xfe works. Only 0xFF gives me this strange behavior.

[Traumflug]

This one:

    for (i = 0; i < 512; i++) {

You count to 511 here, still you get 'i = 255' as debug output. Maybe 'i' is 8 bit and overflows? This might explain odd behaviour, because the compiler could use 'i' as offset, as well as increment the address pointer directly.

[Wurstnase]

i is the same uint16_t from low_code_clear.

Ah sorry for confusion. My fault for the debug-output only. PSRT("%su").

[Traumflug]

Then the '%su' in the sendf_P() should be a '%u'. 's' means 'short' = 1 byte.

[Wurstnase]

Yes, changed.

[Wurstnase]

Some more debug. I changed the logo2 to 0x00 upload the code. Then changed back to 0xff and this is my output:

0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

now with 0xfe and back to 0xff:

0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 
0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFE 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

This is the code I use for debug:

        for (i = 0; i < 512; i++) {
          my_byte = pgm_read_byte(&(logo2[i]));
          displaybus_write(my_byte, (i == 511));
          sersendf_P(PSTR("%sx "), my_byte);
          if (!((i+1)%32))
            serial_writechar('\n');
        }

my_byte is uint8_t. logo2[] is static const uint8_t logo2[] PROGMEM

make size:

ATmega sizes               '168   '328(P)   '644(P)     '1280
Program:  14698 bytes      103%       48%       24%       12%
   Data:   1007 bytes       99%       50%       25%       13%

[phord]

Do, do you mean you filled the array with 0x00 and programmed it, then programmed it with all 0xFF and programmed it again, and you get different results? Maybe there is something wrong with your chip, but I would expect it would have problems with program execution also.

Here is something that should be easy to check. Build the app with all 0x00 and copy the teacup.hex file to somewhere else. Then build it with all 0xFF. Compare the two .hex files and you will, presumably, see the only difference is the region of changed program bytes. There is one line per 16 bytes, there is a prefix of each address, and there is a checksum byte on the end of each line. Don't be confused by those. For example, here's what I see with this test, but with only 256 bytes:

diff teacup-FF.hex teacup-00.hex
30,47c30,47
< :1001D0000A00FFFFFFFFFFFFFFFFFFFFFFFFFFFF23
< :1001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F
< :1001F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F
< :10020000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE
< :10021000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEE
< :10022000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDE
< :10023000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCE
< :10024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBE
< :10025000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAE
< :10026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9E
< :10027000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8E
< :10028000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7E
< :10029000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6E
< :1002A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5E
< :1002B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4E
< :1002C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3E
< :1002D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2E
< :1002E000FFFF503A256C6420493A256C6420443A5B
---
> :1001D0000A00000000000000000000000000000015
> :1001E000000000000000000000000000000000000F
> :1001F00000000000000000000000000000000000FF
> :1002000000000000000000000000000000000000EE
> :1002100000000000000000000000000000000000DE
> :1002200000000000000000000000000000000000CE
> :1002300000000000000000000000000000000000BE
> :1002400000000000000000000000000000000000AE
> :10025000000000000000000000000000000000009E
> :10026000000000000000000000000000000000008E
> :10027000000000000000000000000000000000007E
> :10028000000000000000000000000000000000006E
> :10029000000000000000000000000000000000005E
> :1002A000000000000000000000000000000000004E
> :1002B000000000000000000000000000000000003E
> :1002C000000000000000000000000000000000002E
> :1002D000000000000000000000000000000000001E
> :1002E0000000503A256C6420493A256C6420443A59

I see similar (correct-looking) results when I repeat this with 512 bytes.

What do you see?

[Traumflug]

What do you mean with "change back"? Like overwriting these values at runtime? That's possible, but not as simple as assigning a variable.

If it's "change back" by uploading the binary again, the issue might be a faulty memory block on the '328. avrdude usually verifies what it wrote, but not when used with the -V flag. Also to keep in mind: a block of memory (256 bytes) full of 0xff is the same as an empty block, so the bootloader some tool in the toolchain might take some shortcut here and not write it. avrdude sends out an erase command by default, but AFAIK most bootloaders ignore this.

[Wurstnase]

Do, do you mean you filled the array with 0x00 and programmed it, then programmed it with all 0xFF and programmed it again, and you get different results?

Exactly.

avrdude usually verifies what it wrote, but not when used with the -V flag.

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0180
         0xff != 0xfe
avrdude: verification error; content mismatch

Oh my dear... Yes, while uploading and uploading I use the -V flag.

[phord]

Interesting. I didn't think of a bootloader bug. Maybe the bootloader accidentally skips pages which are all 0xFF.

Do you use "-D" on your avrdude commandline? This disables full-chip-erase and is needed on the ATxmega devices, but those devices should use page-erase along the way. Maybe a bootloader bug causes this to be missed.

       -D      Disable auto erase for flash.  When the -U option with
               flash memory is specified, avrdude will perform a chip
               erase before starting any of the programming operations,
               since it generally is a mistake to program the flash with‐
               out performing an erase first.  This option disables that.
               Auto erase is not used for ATxmega devices as these devices
               can use page erase before writing each page so no explicit
               chip erase is required.  Note however that any page not
               affected by the current operation will retain its previous
               contents.

[Wurstnase]

Do you use "-D"

No:

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "teacup.hex"
avrdude: input file teacup.hex auto detected as Intel Hex
avrdude: writing flash (14698 bytes):

[phord]

So I expect you will see the same error if you use uint16_t and fill it with 0xFFFF.

And it appears to be a problem in your bootloader. Can you upgrade your bootloader?

[Traumflug]

As I just changed above, it might well be another tool in the toolchain. avrdude might assume that Flash actually gets erased when it sends a command to do so, but the bootloader might just as well ignore erase commands, assuming relevant sectors get overwritten anyways.

To check I'd change a single (or few) byte to something non-0xff.

[Wurstnase]

I've never upgrade a bootloader. Will read something about it later.

An array with 0x00, lots of 0xff , 0x00 lost of 0xff, 0x00 has the same behavior.

An interesting post http://forum.arduino.cc/index.php?topic=46403.msg335801#msg335801

[Wurstnase]

Thanks for help. The old WinAVR was the problem. The avrdude was 5.10. With the newer 6.3 the flash will be erased!

[Wurstnase]

• low_code_clear needs a reset of the cursor
• vertical addressing mode only writes the left half of the display

but when you solve this:

[Traumflug]

Very nice!

vertical addressing mode only writes the left half of the display

That's likely an issue with the init sequence. The driver is capable of addressing 128x64 pixels, but has memory for 128x32 pixels, only. Still it sets up addresses for the larger memory if requested. See the comment here: https://github.com/Traumflug/Teacup_Firmware/blob/master/display_ssd1306.c#L95-L98

[Wurstnase]

That's likely an issue with the init sequence.

Thanks for the hint. I will change it.

[RaD]

Wow! How much the news arrived!