Weird screen issue, please help!

im using a 2.42" screen with an ssd1309 driver, the screen is seemingly split down the middle

1 Like

That’s normal behaviour when you use an arduboy hex file with a SSD1309 display. You can use my Python uploader script to upload and patch hex files on the fly for SSD1309 displays.

Edit:

If you’re uploading a sketch from Arduino IDE then I recommend to install my Homemade package. You can select an Arduboy homemade board with SSD1309 display

3 Likes

thank you so much!
also, wow! you have some amazing work!

3 Likes

Hi everyone!
First time here and of course experiencing some problems.
I decided to revive this topic since the problem here is pretty similar with mine.


I’m using MrBlinky’s Arduboy-homemade-package
Burned a bootloader (selected “Display: SSD1309” in Arduino IDE).
Then tried to upload several games - .hex files taken from Erwin’s collection.
For uploading used uploader-1309.py from Arduboy-python-utilities:

python3 ~/Desktop/Arduino/Arduboy-Python-Utilities-master/uploader-1309.py ~/Desktop/Arduino/Puzzle_2048_2048.hex
Password:

Arduboy python uploader v1.2 by Mr.Blinky April 2018 - Jan 2019

Loading “Puzzle_2048_2048.hex”
Found lcdBootProgram in hex file, upload will be patched for SSD1309 displays

Found Generic CDC at port /dev/cu.usbmodem14201

Flashing 22528 bytes. (176 flash pages)
############################################

Verifying 22528 bytes. (176 flash pages)
############################################

Upload success!!

Can not figure out why the image on the screen is split…
Will appreciate any help!

UPD: Loading a sketch via Arduino IDE works like a charm
But I would really like to have a ability to load hexes.

Unfortunately any .hex files built for Arduboy will give you the same problem because of the screen differences.

It might be possible to create a program that can retroactively edit the .hex files so they’re suitable for an SSD1309 system, but I expect that would be fairly difficult.
(It would depend on whether the screen manipulation code is always in the same place for one thing, which I think is unlikely.)

So in absence of evidence to the contrary,
you’ll either have to compile from source or replace your screen with an SSD1306.

You can however create your own .hex file when compiling from source,
so you’d actually only have to compile each game once,
after which you can just upload them with the python tool.

1 Like

I believe that’s what the uploader-1309.py program, mentioned above, is supposed to do.

1 Like

I have had a quick look at the Reversi code and it copies memory to the screen buffer directly rather than using the Arduboy2 library. I don’t understand what @Mr.Blinky has done for the various boards he supports but I am guessing he has just altered the standard library functions to cope for the different boards. Does the 1309 screen’s memory buffer / rendering mimic the standard screen?

Does the problem exist for all games or just this one?

@Mr.Blinky’s script does a search-and-replace to patch a hex for SSD1309:

…doesn’t look like the Reversi hex file contains the search string - not sure it is particular to that game or not though? Maybe something changed in the compiler that changed the search string?

1 Like

However, from the log it looks like it found something!

Right you are! Where in the source did you find the custom display code? I can’t find it…

Here …

… and here …

Plus many more.

Hey, thanks guys for taking a look at this.
It was not only Reversi game - also tried 2048 game. It was late so didn’t have a chance to try more…

The issue MrBlinky has resolved was left to right halves flipping. In my case it is top and bottom parts (not equal halves but looks like only top 8 lines) that are flipped - possibly the reason might be different.

Fair point.

I remember Mr Blinky working on something like that,
but I’d forgotten whether it was completed and working or not.

That probably wouldn’t explain the screen problem.

(For anyone reading this: don’t do your screen rendering like this.
Arduboy2 already has a function for writing whole frames from progmem to the screen,
and memcpy is just a waste of time, a for loop can usually outperform it.)

It’s definitely being used.

The setup function in reversi.ino calls MyArduboy::beginNoLogo,
which calls Arduboy2Core::boot,
which calls Arduboy2Core::bootOLED,
which uses lcdBootProgram.

Just to check, you are sure you’ve got an SSD1309 and not another model?

Otherwise the only explanation I can think of off-hand is that the screen you’re using has a different initial state for some reason.

the screen I have is this one: https://www.aliexpress.com/item/33044134713.html?spm=a2g0s.9042311.0.0.7a894c4dPiZHtM
How can I make sure it is not?

For other hand when I compile reversi from .ino sketch and upload it using Arduboy-homemade-package with selected there SSD1309 screen everything works perfect. So…

1 Like

Unfortunately I can’t see that - it just asks me to log in.

Hrm…

I would assume that means it definitely is an SSD1039,
(unless the same would work on a different kind of screen)
so maybe there’s a bug in the uploader?

@Mr.Blinky would probably have a better idea of what the problem might be.

1 Like

Hi nice to see another homemade Arduboy in progress.

I see you’re using a Pro Micro. Which wiring scheme did you use?

If you wired up the Pro Micro using standard wiring, you can use the uploader-1309.py script to upload original hex files.

However if you chose alternate wiring you can’t use the script. It still patches the display code but it does not patch any pin related code. So the display chip select pin will be left floating.

A floating chip select pin may cause behaviour like you are experiencing (shifted/flipped picture)

The reason why uploading through the IDE works correctly is probably because have chosen the correct wiring scheme (Alternate wiring).

TL;DR

Wire your Pro Micro using Standard wiring If you have, check the display modules CS is connected properly to GND

2 Likes

Thanks a lot @Mr.Blinky!
It definitely must be it. I used alternate wiring so that I could easily connect flash cart in the future. And yes - while uploading via IDE I selected the alternate wiring.
So if I understand correctly to have ability to upload .hex files + use flash cart I need to use standard wiring and extend my scheme with something similar described here:


Flash module is on the way so meanwhile will try to use standard wiring.
I’ve just found a A1015 transistor in my garage - what do you think, will it be fine?

That would be a 2SA1015. Although it’s more meant for audio amplification, rather than a switch. it should work fine.

1 Like

@MLXXXp, Thanks!
@Mr.Blinky, I think it’s worth mentioning in your git repository that patching binaries for ssd1309 screens does not work for alternate wiring. Or maybe there is a way to do something to make it work?
I’ve chosen it (alt wiring) because of more simple scheme, better sound and ability to use all colours of LED.
And 2.42" screen fits so good for arduboy purpose!

@Mr.Blinky, will the trick with ssd 1309 patching of .hex work for arduboy based on Leonardo/Micro board? (second column in your git Pin wiring table)

It should. The Arduboy uses the Leonardo bootloader and I believe @Mr.Blinky’s Cathy bootloader can be compiled for either a Leonardo or Micro. Many .hex files that run on the Arduboy are compiled for Leonardo rather than selecting Arduboy as the board type.

1 Like