Pins on MCP23017 Port Expander

[incorvia]

In our project we have a chip select, A0, and Reset pins all on a MCP23017. For this reason we'd need to modify the library to make sure that wherever these pins are used, that we are using our wrapper pins instead. Can you give me any pointers for making such a modification to this project?

Thanks

[incorvia]

On second thought, maybe it's easier to use a set pixel callback. Does u8g2 support avoiding display constructors entirely and just passing in a setPixel callback?

[olikraus]

You probably want to write your own/custom GPIO&Delay procedure:
https://github.com/olikraus/u8g2/wiki/Porting-to-new-MCU-platform#the-uc-specific-gpio-and-delay-callback

This function will always get A0 signal level has U8X8_MSG_GPIO_DC message (A0 is named as DC = data/command in u8g2).

For Arduino world, there is already a predefined Delay&GPIO procedure in U8x8lib.cpp: u8x8_gpio_and_delay_arduino. This procedure will handle all the GPIO messages including U8X8_MSG_GPIO_DC in the default path of the switch block. Ok, this is a little bit less obvious, because there is a mapping array, which automatically maps the U8X8_MSG_GPIO_DC msg to the correct arduino pin.
You could simply add a new case for the U8X8_MSG_GPIO_DC message and set the port expander pin accordingly.

A more clever method might be the following approach:
Let us have a look at the code in U8x8lib.cpp:

    default:
      if ( msg >= U8X8_MSG_GPIO(0) )
      {
	i = u8x8_GetPinValue(u8x8, msg);
	if ( i != U8X8_PIN_NONE )
	{
	  if ( u8x8_GetPinIndex(u8x8, msg) < U8X8_PIN_OUTPUT_CNT )
	  {
	    digitalWrite(i, arg_int);
	  }

Arduino pin numbers finally end up being in variable "i", which is then used for the digitalWrite command. You could define, that any number beyond 100 is used for the port expander, then the modification would look like this:

    default:
      if ( msg >= U8X8_MSG_GPIO(0) )
      {
	i = u8x8_GetPinValue(u8x8, msg);
	if ( i != U8X8_PIN_NONE )
	{
	  if ( u8x8_GetPinIndex(u8x8, msg) < U8X8_PIN_OUTPUT_CNT )
	  {
            if ( i < 100 )
	       digitalWrite(i, arg_int);
            else
               setPortExpanderPin(i-100, arg_int);
	  }

So in the constructor you could write

U8G2_SSD1325_NHD_128X64_1_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 13, /* data=*/ 11, /* cs=*/ 101, /* dc=*/ 102, /* reset=*/ 105);

This would mean, that cs goes to port expander pin 1, A0 to port expander pin 2 and reset to port expander pin 5.

[olikraus]

On second thought, maybe it's easier to use a set pixel callback. Does u8g2 support avoiding display constructors entirely and just passing in a setPixel callback?

This i do not understand. Display constructors are much more than pixel callbacks, so how is this related to setPixel callback. Moreover, the display does not know how to set/clear a pixel. These displays are very simple: There is just a RAM area, which can by filled via SPI/I2C. Or more simpler: Via the display bus you can:

• setup the display (on/off, brightness, etc)
• fill the display RAM with a bit pattern
  In 99% of all displays, you MUST turn the display on before anything is shown on the display. So a pure setPixel procedure will not help, because you must turn on the display first.
  And of course, every display has a different command for turning the display on.

[olikraus]

Any thoughts on my setPixel callback method instead? I've noticed this is popular in some libraries such as MCUFont to just pass in a setpixel callback and it'll handle setting the pixels while the library does the heavy lifting.

There is no set-pixel callback, but instead a horizontal/vertical line callback.
It is the second member of the u8g2 c structure (see u8g2.h, line 287), but i do not think, that this will help for your port expander.

[incorvia]

@olikraus thanks for your in-depth responses. I love the idea of using 100+ for port expander pins and I'll see if I can get that working.

In regards to your second response. I was looking at a library like this:

https://github.com/mcufont/mcufont/blob/master/docs/index.rst

You can see in this library you pass a callback to mf_render_aligned and that callback is what I would use to set pixels. Therefore I would use a separate St7565 lib to handle writing to the buffer, turning the screen on etc.

Was just curious, but that doesn't seem to be present here. No worries. I'll give the other option a go. Thanks!

[olikraus]

You can see in this library you pass a callback to mf_render_aligned and that callback is what I would use to set pixels. Therefore I would use a separate St7565 lib to handle writing to the buffer, turning the screen on etc.

ok, understand. There is another lib which expects a callback to set a pixel. But this is simple: You have to write a callback and inside there you call u8g2_DrawPixel procedure.
I see two problems here: Alpha values (pixel brightness) is not at all supported by u8g2. It is a pure black/white library. So, the anti-aliasing feature of that lib can not be used with u8g2. The other problem is, that the args (count, state) are not described in mcufont.

The other advantages are nice, but u8g2 also compresses and decompresses fonts and there is also a tool available for u8g2 which converts .ttf fonts to the internal (compressed) format.

[olikraus]

I had a look at mcufont. This is my conclusion:

• U8g2 includes a font rendering system like mcufont.
• U8g2 comes with its own "encoder" tool, which is called "bdfconv"
• TTF format is not directly supported by u8g2, but instead the u8g2 font tool chain uses otf2bdf for the conversion from TTF to BDF. MCUFont has a buildin TTF converter.
• MCUFont supports kening. This is not there with u8g2.
• Both u8g2 and MCUfont support UTF-8 and up to 64K glyphs per font.
• Both u8g2 and MCUfont use the same compression method (RLE)

I like the kerning algo in MCUFont, but unless you need this feature, i think the u8g2 internal font render engine is as good as MCUFont.

[incorvia]

Just to be clear I wasn't trying to support a battle :) Was only trying to figure out how to best take advantage of u8g2 lib.

I may end up trying both and using whichever ends up working better for my application.

[olikraus]

Just to be clear I wasn't trying to support a battle

Your hint was quite interessting. In fact i wanted to know whether i missed something in my own font render engine.

I may end up trying both and using whichever ends up working better for my application.

Yes of course, please do so. Maybe also consider compression ratio and decompression speed. I spent a good amount of time to improve this for u8g2.