Surenoo SSD1320 based 320x132x4 display for RP2040 and/or Zephyr (review)

[rivimey]

Moved from #1856 which also has code.

Display P/N: SOG320132A_M383
Surenoo Display datasheet: http://surenoo.tech/download/03_SOL/0302_SOG/SOG320132A_M383.pdf
(a bit brief, but adequate)
Surenoo SSD1320 datasheet: http://surenoo.tech/download/03_SOL/0302_SOG/Controller/SSD1320.pdf
(includes command list)

Two interfaces present: one for the Raspberry Pi RP2040 SDK, using e.g. gpio_set_function(),
and one which I intended to be generic for Zephyr-RTOS, but which my lack of understanding
is hampering. I think the pico-sdk versions are essentially ok, but the zephyr ones are not
as yet.

I have copied over the group of functions u8g2_m_40_17_2 et al and I think adjusted them
properly, but I do not understand the choice of '17' here. Perhaps this area needs checking?
I have also put #if 0 / #endif the *nhd_powersave1_seq arrays because they weren't used. I
have no idea if they are correct for the 1320.

[rivimey]

@[olikraus] wrote:

I need to refuse this PR. Most of the code (u8x8_m functions) is generated and the csrc folder should not contain target specific functions (gpio and delay).
I suggest to create an issue instead. I will add your code and run the code generator. After this you could do the fine tuning. Would this be ok?

Absolutely fine with refusing this particular request (hence "review") in the title as I know I didn't structure it as an extension. I put this PR up because I wanted review of how this was working. Perhaps that wasn't the right option, sorry

Since the code was created I realized that the display actually uses two ssd1320 controllers, with two CS lines (I had misread the DS). The DS is unclear on how they are connected. It seems this could be dealt with by defining two instances of a 160x132 display and combining them with a third "controller" that directs requests appropriately to one or both child instance.

Is that the way you would suggest? Is there any other example of doing this?

[olikraus]

Did you check this issue: #1351

To me it looks like your display is identical to the display used in #1351
All in all support is included in latest version of u8g2.

Issue #1351 also discusses the two controller in one display problem: #1351 (comment)

[olikraus]

The DS is unclear on how they are connected.

DS? Do you mean DC?
DC is the "date / command" line, which is generated by u8g2. You just need to define a pin for this signal. Then connect the display DC input to that pin and tell u8g2 the pin number of that GPIO port as argument to the u8g2 constructor.

[rivimey]

DS = datasheet. The (entire) display mapping info is shown in this screen snip, but sadly although the intention seems to have been to show which controller controls which display lines, the illustrator has not mentioned columns 161..319 at all :( - the top half is just rotated to the bottom.

.

[rivimey]

Thanks for the pointer to #1351 I did see the first few comments in the issue but didn't realize it became more interesting later on.

The display @buildxyz-git posted docs for isn't exactly the one I'm using, but the docs are remarkably similar - down to the useless area mapping diagram I posted above. The Surenoo display doc is I would say a later version and has a little more info.

It's a pity we have to chose between 1320-controller doc v0.1 including command descriptions and 1320-controller doc v1.0 that excludes the commands!

[olikraus]

DS = datasheet.

Oh, ok.

but sadly

Yes, thats the fun part here: There is always some investigation and reverse engineering required.

doc v1.0 that excludes the commands!

This happens. Not sure why, but sometimes the controller vendor removes such information. Finding the information, doing some reverse engineering, putting puzzle pieces together can be challenging. As a company I can't go to the display vendor. This project has no budget, generates no profit and as a consequence there is almost no help from the display vendors (there are some exceptions...).
Well, I think u8g2 and the open source maker community are still too small to generate a notable sales amount.

Anyhow, I am always happy to add another display type to the list of supported displays :-) There is much more and better displays than those standard SSD1306 OLEDs. But adding support is only possible with the help of enthusiastic community members like you. I usually do not have the budget to buy and test those unknown devices.

So starting from here, the only thing what I can offer is this: Maybe you can use the existing constructor with your display and make some pictures from HelloWorld or FlipMode example, so that we see any display issues, which need to be fixed for your display.
If you are in luck, then the existing constructor already works as expected.

[rivimey]

Thanks for your comments. It would make sense to me to create a 'wrapper' which would make it seem that the two controllers were just one. Would this be possible/sensible?

[olikraus]

Would this be possible/sensible?

Should be possible, but I would not be able to do this (if this is the question).