Looking at the Proffie documentation, it looks like there are two OLED screen sizes that are currently supported - they being 128x32 and 64x32.
Have I understood that right or is there a line somewhere in the OS that can be adjusted for other screen sizes?
I have a module I’m told is 72 x 40, and if I add the bottom config bit for a 64x32, I get the battery level and cropped font names, but none of the bmp files show up, cropped or otherwise.
Just getting my head around what is and isn’t possible.
The current code in ProffieOS can support any width display, but for the height, only 32 and 64 pixels are supported. The SSD1306 always have 128 pixels width, but the display might not show all of those. The code currently assumes that the “shown pixels” are centered within those 128 pixels, so if that isn’t the case, then the code would need some changes.
When it comes to the height, ProffieOS currently assumes that it can use an int32_t or an int64_t to represent all the pixels in one column. Now, it wouldn’t be that hard to create an int40_t class, which would make it understand displays which are 40 pixels high, but it doesn’t exist today.
As for BMP files, are they 64x32? ProffieOS currently assumes the pictures are the same size as the display.
1 Like
Thanks for clarifying Prof. I’ve been experimenting this afternoon and have managed to get everything working that I need. The only real compromise I had to make is there’s only room for four characters in the font idents. But I’ll just stick to four characters in the config at the bottom of each preset so all good.
Thanks again.
Resurrecting this thread as I am working with a 64x48 OLED.
The images for it are no big deal as I just made 64x64s, but kept the desired content within the top 48 pixels, leaving 16 at the bottom unused.
But if we swap some of the hard coded values for variables in ssd1306 that the user could then override in the PROP_BOTTOM, then custom sizes could be specified that way, unaffecting the default behavior.
For example, I have this in ssd1306 to inject HEIGHT:
template<int WIDTH, class col_t, class POWER_PIN = PowerPINS<> >
class SSD1306Template : public Display<WIDTH, col_t>, I2CDevice, Looper, StateMachine {
public:
static const int HEIGHT = sizeof(col_t) * 8;
// Hook for custom heights like 64x48 OLEDs.
virtual int HardwareHeight() {
return HEIGHT;
}
then PROP_BOTTOM can have something like this
class MySSD1306 : public SSD1306Template<64, uint64_t> {
public:
using SSD1306Template<64, uint64_t>::SSD1306Template;
int HardwareHeight() override {
return 48;
}
};
There’s more code that deals with the message text, including scaling and number-of-lines and their location.
Is this something we could/should consider adding to ProffieOS?
I wonder if maybe the right way to make a display that is 48 pixels high is to make an unsigned 48 bit integer type, and then use that for “col_t”.
We already have support for using the template directly with INCLUDE_SSD1306
I just tried a 48-bit col_t idea. Text and battery meter work fine, but images freeze the board. 64 width isn’t divisible by 48 height, and ConvertLandscape doesn’t like that.
Any suggestion?
Looking at the code, it’s probably better to make it use uint32_t, but specify the height to be 48 pixels. We can do that with a bit of template magic.
I guess the question is: What things should work differently? I guess we need to be able to load smaller images for one thing, right?
With the workaround I had going, I used 64x64 images with desired content kept in the top 48. Native size would be ideal of course.
As far as text, I had a user config definable NumberOfTextLines (desired) and had scaling applied to make those fit.
Lastly, I made it wrap lines if they were too wide to fit, and scrolling to show newlines if they exceed the NumberOfTextLines .
@profezzorn No luck making an unsigned 48 bit integer type, did not try your comment of “make it use uint32_t, but specify the height to be 48 pixels” yet.
Should I open a PR so you can take a look at the basic “just override defaults” version that is working fine for me? (albeit working around image content to make it look right)
Yeah, the rotation code becomes a bit of a problem…
Thinking about this, and also the error message, we probably need to refactor the display code enough that we can have tests for loading images, that will make it much easier to make sure that nothing breaks when changing stuff.
I don’t quite understand the landscape vs portrait thing.
Wouldn’t the image just be made accordingly? (sideways) We have Flip 180 already, so if content is made portrait… doesn’t it just show up correctly?
As far as overhauling displaycode and making testing images easily, I’m not sure what you have in mind.
I am on a PR craze lately it seems, might as well throw what I have for ssd1306 up as well and see what you think.