Porting repetier to u8glib2

[WojciechBednarski]

Hello,

Are there any plans to implement u8glib2 (https://github.com/olikraus/u8g2) to repetier instead of a little deprecated and old u8glib ?

There are some clear advantages over older version of library, which can be found here: https://github.com/olikraus/u8g2/wiki/u8gvsu8g2#improvements , so I'm not going to repeat them. But one of the big advantage is that this library is using native SPI libraries, and custom spi is really painful on arduino DUE.

It's not clear to me how much work is this, I'm trying to figure this out, but here are people much, much more experienced than I'm and so maybe somebody could give some hints about it.

[repetier]

Interesting idea which I have to think about. Some things sound good but also have drawbacks like no loop to build display in several steps. Might speed up things but costs more memory and deltas are already short of memory. So here the old system has it's advantage. UTF-8 support is fine if we had utf-8 text. But that makes only sense if fonts contain also cyrillic, greek etc letters making fonts bigger. Here again memory gets an issue as we already need to limit languages to not exceed 64kb flash usage for data.

So it is not easy to say if this all is good or not. I have marked it as feature request, so I can investigate deeper when I get some time for such a big change. Might even end with the option to use one or the other method so non delta uses can have speed improvements (which needs to be proven) over reduced memory consumption.

[WojciechBednarski]

Well, I'm in no position to compare memory usage, because I simply haven't tested what's exactly the "cost" of it, and I can't find any direct comparisons between the two. However the highest benefits would be gained by people using Arduino DUE boards, and there I think there is plenty of spare room.

UTF support itself is not a dealbreaker for me, as I always think, that english language is much more precise in describing 3d printer functions than my native language, but the higher compatibility and much more modern approach of the updated library version is somehow convincing me personally.

The memory usage maybe can be optimized, also there is u8x8 text only API if needed for speed and poor-man's-texts-displays.

[olikraus]

GarrethX asked me to comment the port. So here is my comment&experience:

• The first/next loop is still there
• U8g2 is mostly compatible with U8g, a porting guide is here: https://github.com/olikraus/u8g2/wiki/u8gvsu8g2
• Fonts are compressed and require less flash rom compared U8g
• UTF-8 is an option. However fonts are already there.
• Most of the software can be ported in one day or so
• If you encounter any missing function, please create an issue on u8g2 github project

[repetier]

To be clear about memory problem - this exists only for nonlinear systems on AVR processors. Due solves all problems with 32 bit and more memory.

@olikraus Because the are more or less compatible I think a switch should be possible so we can switch directly between both libraries and compare speeds. Most important fact is good speed with software SPI. Most displays use that as there are problems sharing it with sd card spi or just because pins do not fit to hw spi pin. Therefore I have modified pin toggling to use fastio which is much faster then arduino solution with digitalWrite.

[olikraus]

For u8g2 I have removed all hardware specific code and included a more clear interface instead. For AVR architecture HW specific SW SPI exists already, however, this is not yet done for Due (and other ARM controllers). This means, U8g2 only has digitalWrite() based SW SPI. If it helps, i can take over Due specific SW SPI from U8glib.

[repetier]

I'm quite sure I have replaced even the u8g version of writes with fastio which reduces to the simple setting of the register - no further tests. If you compare this with arduino digitalWrite you see easily where their overhead comes from. All these tests if it is in write mode, not pwm, accessing registers over a table etc. are nothing you want in software SPI. So in this respect our u8g version is highly optimized, but not so flexible as pins are set on compile time to use macro magic to improve speed. Maybe that would be something I'd also do when porting. Here a simple example. In comments you have the original code which I replaced, also here for AVR.

static void u8g_com_arduino_do_shift_out_msb_first(uint8_t val) { / uint8_t cnt = 8; uint8_t bitData = u8g_bitData; uint8_t bitNotData = u8g_bitNotData; uint8_t bitClock = u8g_bitClock; uint8_t bitNotClock = u8g_bitNotClock; volatile uint8_t outData = u8g_outData; volatile uint8_t *outClock = u8g_outClock;

U8G_ATOMIC_START(); bitData |= outData; bitNotData &= outData; do { if ( val & 128 ) outData = bitData; else outData = bitNotData; val <<= 1; outClock &= bitNotClock; cnt--; // removed micro delays, because AVRs are too slow and the delay is not required //u8g_MicroDelay(); outClock |= bitClock; //u8g_MicroDelay(); } while( cnt != 0 );

*/ U8G_ATOMIC_START();

ifdef UI_SPI_MOSI

for(uint8_t cnt=0; cnt<8; cnt++ ) { WRITE(UI_SPI_SCK, LOW); WRITE(UI_SPI_MOSI, val&0x80); val<<=1; asm volatile("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" ::); //u8g_MicroDelay(); WRITE(UI_SPI_SCK, HIGH); asm volatile("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" ::); //u8g_MicroDelay(); }

endif

U8G_ATOMIC_END(); }

[olikraus]

Nice work. Of course i can not support high optimized software procedures for each Arduino board in u8g2 (there are too many different boards). Instead U8g2 now provides full support for SPI.h which includes the use of BeginTransfer and EndTransfer. This should ensure, that SPI cooperates with other devices on the same bus.

Anyhow, i just wanted to offer my support if there are any porting questions.

[repetier]

Sure I understand that this is a uncommon optimization level that is hard to generate in a general code supposed to work on many different boards. Unfortunately for the firmware this is a most, so I changed these few parts. I assume the number of parts where communication happens will also be only a few in your version, so adapting these places is no big deal. Apart from this , the u8glib version to handle it is a good compromise as it is faster then arduinos solutions and still uses variables instead. When I come to testing the library I will come back to your offer if I get any problems. Thanks.