Marlin_Firmware/Marlin/ultralcd_st7920_u8glib_rrd.h

239 lines
7.0 KiB
C
Raw Normal View History

/**
2016-03-24 13:01:20 -05:00
* Marlin 3D Printer Firmware
* Copyright (C) 2016 MarlinFirmware [https://github.com/MarlinFirmware/Marlin]
*
* Based on Sprinter and grbl.
* Copyright (C) 2011 Camiel Gubbels / Erik van der Zalm
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
*/
#ifndef ULCDST7920_H
#define ULCDST7920_H
#include "Marlin.h"
#if ENABLED(U8GLIB_ST7920)
#define ST7920_CLK_PIN LCD_PINS_D4
#define ST7920_DAT_PIN LCD_PINS_ENABLE
#define ST7920_CS_PIN LCD_PINS_RS
//#define PAGE_HEIGHT 8 //128 byte framebuffer
//#define PAGE_HEIGHT 16 //256 byte framebuffer
#define PAGE_HEIGHT 32 //512 byte framebuffer
#define LCD_PIXEL_WIDTH 128
#define LCD_PIXEL_HEIGHT 64
#include <U8glib.h>
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
//set optimization so ARDUINO optimizes this file
#pragma GCC optimize (3)
#define DELAY_0_NOP ;
#define DELAY_1_NOP __asm__("nop\n\t");
#define DELAY_2_NOP __asm__("nop\n\t" "nop\n\t");
#define DELAY_3_NOP __asm__("nop\n\t" "nop\n\t" "nop\n\t");
#define DELAY_4_NOP __asm__("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t");
// If you want you can define your own set of delays in Configuration.h
//#define ST7920_DELAY_1 DELAY_0_NOP
//#define ST7920_DELAY_2 DELAY_0_NOP
//#define ST7920_DELAY_3 DELAY_0_NOP
#if F_CPU >= 20000000
#ifndef ST7920_DELAY_1
#define ST7920_DELAY_1 DELAY_0_NOP
#endif
#ifndef ST7920_DELAY_2
#define ST7920_DELAY_2 DELAY_0_NOP
#endif
#ifndef ST7920_DELAY_3
#define ST7920_DELAY_3 DELAY_1_NOP
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
#endif
#elif (MOTHERBOARD == BOARD_3DRAG) || (MOTHERBOARD == BOARD_K8200)
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
#ifndef ST7920_DELAY_1
#define ST7920_DELAY_1 DELAY_0_NOP
#endif
#ifndef ST7920_DELAY_2
#define ST7920_DELAY_2 DELAY_0_NOP
#endif
#ifndef ST7920_DELAY_3
#define ST7920_DELAY_3 DELAY_1_NOP
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
#endif
#elif F_CPU == 16000000
#ifndef ST7920_DELAY_1
#define ST7920_DELAY_1 DELAY_0_NOP
#endif
#ifndef ST7920_DELAY_2
#define ST7920_DELAY_2 DELAY_0_NOP
#endif
#ifndef ST7920_DELAY_3
#define ST7920_DELAY_3 DELAY_1_NOP
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
#endif
#else
#error "No valid condition for delays in 'ultralcd_st7920_u8glib_rrd.h'"
#endif
static void ST7920_SWSPI_SND_8BIT(uint8_t val) {
WRITE(ST7920_CLK_PIN,0);
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_1
WRITE(ST7920_DAT_PIN,val&0x80);
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_2
WRITE(ST7920_CLK_PIN,1);
val<<=1;
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_3
WRITE(ST7920_CLK_PIN,0);
ST7920_DELAY_1
WRITE(ST7920_DAT_PIN,val&0x80);
ST7920_DELAY_2
WRITE(ST7920_CLK_PIN,1);
val<<=1;
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_3
WRITE(ST7920_CLK_PIN,0);
ST7920_DELAY_1
WRITE(ST7920_DAT_PIN,val&0x80);
ST7920_DELAY_2
WRITE(ST7920_CLK_PIN,1);
val<<=1;
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_3
WRITE(ST7920_CLK_PIN,0);
ST7920_DELAY_1
WRITE(ST7920_DAT_PIN,val&0x80);
ST7920_DELAY_2
WRITE(ST7920_CLK_PIN,1);
val<<=1;
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_3
WRITE(ST7920_CLK_PIN,0);
ST7920_DELAY_1
WRITE(ST7920_DAT_PIN,val&0x80);
ST7920_DELAY_2
WRITE(ST7920_CLK_PIN,1);
val<<=1;
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_3
WRITE(ST7920_CLK_PIN,0);
ST7920_DELAY_1
WRITE(ST7920_DAT_PIN,val&0x80);
ST7920_DELAY_2
WRITE(ST7920_CLK_PIN,1);
val<<=1;
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_3
WRITE(ST7920_CLK_PIN,0);
ST7920_DELAY_1
WRITE(ST7920_DAT_PIN,val&0x80);
ST7920_DELAY_2
WRITE(ST7920_CLK_PIN,1);
val<<=1;
3 ms speedup for ST7920 and delay for BOARD_3DRAG and saving ~1k memory by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed). Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s. The delays are now pre-filled with the calculated values for 4.5V driven ST7920. A way to simply add __your__ timing into the configuration was made. At 4.5V 1.) The CLK signal needs to be at least 200ns high and 200ns low. 2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high. A nop takes one processor cycle. For 16MHz one nop lasts 62.5ns. For 20MHz one not lasts 50ns. To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles. Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin. Needs tests and feedback. Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V. Are the delays right? Please experiment with longer or shorter delays. And give feedback. Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
2016-06-04 07:54:20 -05:00
ST7920_DELAY_3
WRITE(ST7920_CLK_PIN,0);
ST7920_DELAY_1
WRITE(ST7920_DAT_PIN,val&0x80);
ST7920_DELAY_2
WRITE(ST7920_CLK_PIN,1);
}
#define ST7920_CS() {WRITE(ST7920_CS_PIN,1);u8g_10MicroDelay();}
#define ST7920_NCS() {WRITE(ST7920_CS_PIN,0);}
#define ST7920_SET_CMD() {ST7920_SWSPI_SND_8BIT(0xf8);u8g_10MicroDelay();}
#define ST7920_SET_DAT() {ST7920_SWSPI_SND_8BIT(0xfa);u8g_10MicroDelay();}
#define ST7920_WRITE_BYTE(a) {ST7920_SWSPI_SND_8BIT((uint8_t)((a)&0xf0u));ST7920_SWSPI_SND_8BIT((uint8_t)((a)<<4u));u8g_10MicroDelay();}
#define ST7920_WRITE_BYTES(p,l) {uint8_t i;for(i=0;i<l;i++){ST7920_SWSPI_SND_8BIT(*p&0xf0);ST7920_SWSPI_SND_8BIT(*p<<4);p++;}u8g_10MicroDelay();}
uint8_t u8g_dev_rrd_st7920_128x64_fn(u8g_t *u8g, u8g_dev_t *dev, uint8_t msg, void *arg) {
uint8_t i, y;
switch (msg) {
case U8G_DEV_MSG_INIT: {
OUT_WRITE(ST7920_CS_PIN, LOW);
OUT_WRITE(ST7920_DAT_PIN, LOW);
OUT_WRITE(ST7920_CLK_PIN, HIGH);
ST7920_CS();
u8g_Delay(120); //initial delay for boot up
ST7920_SET_CMD();
ST7920_WRITE_BYTE(0x08); //display off, cursor+blink off
ST7920_WRITE_BYTE(0x01); //clear CGRAM ram
u8g_Delay(15); //delay for CGRAM clear
ST7920_WRITE_BYTE(0x3E); //extended mode + GDRAM active
2016-03-15 03:10:57 -05:00
for (y = 0; y < (LCD_PIXEL_HEIGHT) / 2; y++) { //clear GDRAM
ST7920_WRITE_BYTE(0x80 | y); //set y
ST7920_WRITE_BYTE(0x80); //set x = 0
ST7920_SET_DAT();
2016-03-13 00:38:55 -06:00
for (i = 0; i < 2 * (LCD_PIXEL_WIDTH) / 8; i++) //2x width clears both segments
ST7920_WRITE_BYTE(0);
ST7920_SET_CMD();
}
ST7920_WRITE_BYTE(0x0C); //display on, cursor+blink off
ST7920_NCS();
}
break;
case U8G_DEV_MSG_STOP:
break;
case U8G_DEV_MSG_PAGE_NEXT: {
uint8_t* ptr;
u8g_pb_t* pb = (u8g_pb_t*)(dev->dev_mem);
y = pb->p.page_y0;
ptr = (uint8_t*)pb->buf;
ST7920_CS();
for (i = 0; i < PAGE_HEIGHT; i ++) {
ST7920_SET_CMD();
if (y < 32) {
ST7920_WRITE_BYTE(0x80 | y); //y
ST7920_WRITE_BYTE(0x80); //x=0
}
else {
ST7920_WRITE_BYTE(0x80 | (y - 32)); //y
ST7920_WRITE_BYTE(0x80 | 8); //x=64
}
ST7920_SET_DAT();
2016-03-15 03:10:57 -05:00
ST7920_WRITE_BYTES(ptr, (LCD_PIXEL_WIDTH) / 8); //ptr is incremented inside of macro
y++;
}
ST7920_NCS();
}
break;
}
#if PAGE_HEIGHT == 8
return u8g_dev_pb8h1_base_fn(u8g, dev, msg, arg);
#elif PAGE_HEIGHT == 16
return u8g_dev_pb16h1_base_fn(u8g, dev, msg, arg);
#else
return u8g_dev_pb32h1_base_fn(u8g, dev, msg, arg);
#endif
}
2016-03-15 03:10:57 -05:00
uint8_t u8g_dev_st7920_128x64_rrd_buf[(LCD_PIXEL_WIDTH) * (PAGE_HEIGHT) / 8] U8G_NOCOMMON;
u8g_pb_t u8g_dev_st7920_128x64_rrd_pb = {{PAGE_HEIGHT, LCD_PIXEL_HEIGHT, 0, 0, 0}, LCD_PIXEL_WIDTH, u8g_dev_st7920_128x64_rrd_buf};
u8g_dev_t u8g_dev_st7920_128x64_rrd_sw_spi = {u8g_dev_rrd_st7920_128x64_fn, &u8g_dev_st7920_128x64_rrd_pb, &u8g_com_null_fn};
class U8GLIB_ST7920_128X64_RRD : public U8GLIB {
public:
2016-06-22 20:22:17 -05:00
U8GLIB_ST7920_128X64_RRD(uint8_t dummy) : U8GLIB(&u8g_dev_st7920_128x64_rrd_sw_spi) { UNUSED(dummy); }
};
#pragma GCC reset_options
#endif //U8GLIB_ST7920
#endif //ULCDST7920_H