Questions about scrolling

[gampam2000]

Hi,

It seems that scrolling is not working on my adapted driver, or I do not understand how it should work.
Can you explain to me what scrolling should do? Does oled.vscsad(scroll) move the complete frame by the scroll value to the right?

I have seen that you implemented it here differently.
Instead of the vscrdef(tfa, width, bfa) and oled.vscsad(scroll) you have here vscroll_area() and vscroll_start().
vscrdef seems identical to vscroll_area, but in vscroll_start you have a 2nd parameter for orientation?

Thanks & best regards

[nspsck]

Hi,

It seems that scrolling is not working on my adapted driver, or I do not understand how it should work.
Can you explain to me what scrolling should do?

Please have a read on this section.

If you have access to YouTube, here is what it should look like.

I have seen that you implemented it here differently.
Instead of the vscrdef(tfa, width, bfa) and oled.vscsad(scroll) you have here vscroll_area() and vscroll_start().

These functions serve the same purpose, just another name, with some tweaks that are easy to adapt. vscrdef() is equivalent to vscroll_area(), and vscsad() is equivalent to vsroll_start(). The orientation essentially changes the orientation of the display for you to scroll in another orientation than what is set to be with your .rotation(), and this part is doing the job, you can just leave it out if you want, aka, the st7789 driver should work out of the box.

Additionally, try this example, you might have to define these two paramenters if you haven't defined them in the tft_config.py.

Best Regards

[gampam2000]

If you have access to YouTube, here is what it should look like.

ok yes that's what i thought it should be like

Additionally, try this example, you might have to define these two paramenters if you haven't defined them in the tft_config.py.

If I run this program I see, first x00 is written at the bottom of the screen than 0x01 and 0x02,... is written from top to bottom. When it reached the bottom a black line is moving from top to bottom and underneath the new values appear. So instead of scrolling the screen it gets updated from top to bottom.

my oled initialization looks like this:

oled = st7789.ST7789(
    SPI(2, baudrate=40000000, sck=Pin(39), mosi=Pin(40), miso=None),
    240,
    536,
    reset=Pin(42, Pin.OUT),
    cs=Pin(45, Pin.OUT),
    dc=Pin(46, Pin.OUT),
    backlight=Pin(47, Pin.OUT),
    rotations=[(0x00, 240, 536, 0, 0), (0x60, 536, 240, 0, 0), (0xc0, 240, 536, 0, 0), (0xa0, 536, 240, 0, 0)],
    rotation=1,
    options=0,
    inversion=False,
    color_order=st7789.RGB,
    use_drawbuffer=True,
    )

oled.init()
oled.fill(st7789.YELLOW)

tfa = 0       # top free area
bfa = 0       # bottom free area

oled.vscrdef(tfa, 536, bfa)
...

The screen has a resolution of 240x536. Am I doing something wrong with the boundaries?

[nspsck]

Hi, if you do rotation=1, the display will be 536x240, and the 536 in oled.vscrdef(tfa, 536, bfa) is more than double the height, which results in a loop? Am not so sure, since your code is not complete.

[gampam2000]

Hi, thanks for your patience and help.

Ah ok so if I rotate then with and height get swapped? For now I will test with rotation=0

But still something is not working right at my side. I played around with the scroll.py test, but it writes the fist char in the last line and the second char is written on the top of the screen. The scree is not scrolled. Also changing bfa and tfa does nothing.

I created a simpler test program (see code below). My expectation was that it moves the "Test Scrolling" Text up 500 pixels. But it does nothing. Any Ideas why?

from machine import Pin, SPI
import st7789
import vga2_16x16 as font
import utime
import time

oled = st7789.ST7789(
    SPI(2, baudrate=40000000, sck=Pin(39), mosi=Pin(40), miso=None),
    240,
    536,
    reset=Pin(42, Pin.OUT),
    cs=Pin(45, Pin.OUT),
    dc=Pin(46, Pin.OUT),
    backlight=Pin(47, Pin.OUT),
    rotations=[(0x00, 240, 536, 0, 0), (0x60, 536, 240, 0, 0), (0xc0, 240, 536, 0, 0), (0xa0, 536, 240, 0, 0)],
    rotation=0,
    options=0,
    inversion=False,
    color_order=st7789.RGB,
    use_drawbuffer=True,
    )

oled.init()
oled.fill(st7789.YELLOW)
    
foreground = st7789.RED
background = st7789.BLACK
oled.rect(0, 0, 240, 536, st7789.RED)

utime.sleep(1)

height = oled.height()
width = oled.width()
print("h:" + str(height))
print("w:" + str(width))

last_line = height - font.HEIGHT

tfa = 0       # top free area
bfa = 0      # bottom free area

oled.vscrdef(tfa, 536-8, 8)

scroll = 0


oled.text(
    font,
    "Test Scrolling",
    0,
    520,
    foreground,
    background)

for i in range(0,500):
    # scroll the screen up 
    oled.vscsad(i)
    time.sleep_ms(5)

[nspsck]

Ugh... Sorry, actually my bad. The RM67162 doesn't take those commands (0x33 and 0x37). Furthermore, I do not believe this IC even supports hardware scrolling, I checked the command list again and there is no definition to hardware scrolling there. (Section 6.1) Am sorry for the inconvenience that false assumptions have caused and sorry for wasting your time on trying this.

And thank you very much for testing and bringing it up!

[gampam2000]

Hi, oh ok. That solves this issue. Thanks for your support. I also found a newer datasheet (ver. 0.5) here: RM67162.pdf.

How could I archive a similar scrolling effect in software? Can i do this somehow with the micropython framebuffer?
I used before an SSD1307 display there you write/paint to the display but it is only shown after a .show() command is sent.

[nspsck]

Thanks for your support. I also found a newer datasheet (ver. 0.5) here: RM67162.pdf.

Sadly, there are also no indicators showing that scrolling is hardware-supported in this datasheet.

How could I archive a similar scrolling effect in software? Can i do this somehow with the micropython framebuffer?

Somehow like this. However, that could be very inefficient, depending on the compiler optimizations. What I would do is having the buffer fixed and not modify it at all. As pseudo code below (you should be implementing this in C):

# A bus to transfer data
bus
# The fixed buffer with contents already prepared.
buffer
# Area dimensions and positions
x, y, w, h
# Scroll directions
vertical, horizontal

# Assuming a vertical scroll, scrolling up
vertical_line_pointer = 0

while True:
    
    # sets the area to draw on the display
    set_area(x, y, x + w - 1, y + h - 1)
    
    # this defines how much data should be transfered to
    # the display
    length = (h - vertical_line_pointer) * pixel_size_in_ram
    
    # transfer the data starting from to the area starting from
    # area(0, 0), ends at area(w, h - vertical_line_pointer)
    bus.transfer(buffer.at_pointer(vertical_line_pointer),
                 length)

    # in case vertical_line_pointer is greater than 0, which means
    # we are starting at other lines rather than the first line in
    # buffer. We have to transfer the data from top of the buffer
    # into the bottom of the area.
    if vertical_line_pointer > 0:
        length = vertical_line_pointer * pixel_size_in_ram
        bus.transfer(buffer.at_pointer(0),
                     length)
    
    # makes the loop
    if vertical_line_pointer == h:
        vertical_line_pointer = 0

I used before an SSD1307 display there you write/paint to the display but it is only shown after a .show() command is sent.

yes, because the ssd1307 actually treats .show() (as, show whatever is in the buffer on the display) as a command. Whereas st7789 or st7735 are using a physical v-sync, (at least according to my limited knowledge) pin to achieve the same effect. So, that is not the same. And I have no idea how rm67162 achieves the same goal.