So you've described how to initialize and use this one make/model, but how does one learn to figure this out? Is it reverse engineering the sample code? reading the spec sheet and applying the commands one at a time until you've figured it out?
But as a general rule, the manufacturers are not good at writing specs, not to the standards we expect in the US or in the EU. You sort of need to know what to look for. The relevant sections are 8.3.2, which describes the pixel format; and 9, which has the command table - albeit there's some specialized jargon in there. For example, the "drive this many rows" setting is called "set multiplex ratio" - whyyy.
Newhaven has its own spec for the entire module, with some sample code, but the code in their docs is often garbled and poorly-explained:
It helps if you've done it before, or have some introductory text that explains the sequence for a similar display.
It's also helpful if there's some demo code somewhere on Github, although it's really hit-and-miss. Most of these are devoid of comments and go through a lot of unnecessary steps, often for some platform you're not familiar with. At best, it's some Arduino cruft...
Anyway - the good news is that there is a fairly small number of dominant controllers, and that by now, they're mostly sane. In the early days, you had some weird memory layouts, etc.
If Your project includes a graphic display, there is one problematic issue worth addressing. The graphic displays usually come without their RAM memories, so the actual frame buffer is being held by MCU in its RAM and is being written to the display either by using I2C or SPI interface.
In other words, it requires the developer of preserving bulk region of memory for a frame buffer, the higher he resolution, the higher of RAM is needed.
While designing a circuit for fun it doesn't make a difference whether You're going to use an MCU based on ARM core with plenty of RAM/Flash, IOs and packed with features or not. On contrary, working on a commercial projects requires selecting the MCU that is going to be cost effective at first, allow to fit the code for Your design and have a little space left for a few extra features You want to add into the coding process. If Your design is going to be sold in numbers, the $10 difference in between Atmega328 and Atmega SAM4 goes in numbers as well. And that is highly related to the competition with Asian market You have already mentioned. And the companies asking for the electronic design will evaluate the project based on target price, not the MCU features and computing power.
A while ago I've been asked for the fertilizer mixer controller, that I've initially decided to fit into Atmega328 (cost effective) that will be interfaced to SSD1306 (I love OLEDs for their crystal clear and wide angle view) and started coding: startup (integrity check on RTC, recipes, timetable - yes, EEPROMs sometimes loose their data), main window, several setup windows: date & time, recipes, timetable, diagnostics, PID params, probe calibration, alarms and factory reset. It barely fit into the MCU (I had to quit the idea of adding MODBUS). But in this case the display is just a terminal: set&forget.
When elegance of a design comes to play, it is reasonable to explore more advanced (and pricey) MCUs, that allow using a dedicated graphic libraries, like LVGL - they can provide a lightweight graphic windows with buttons and such, which is more than drawing lines, circles and rectangles in a frame buffer.
My mentioned project is somewhere in between those two. I've developed a dynamically allocated windows system, but in a text mode. And yes, on that occasion I have used malloc() condemned by many. And I love it!
So you've described how to initialize and use this one make/model, but how does one learn to figure this out? Is it reverse engineering the sample code? reading the spec sheet and applying the commands one at a time until you've figured it out?
It's a bit of a pain. The manufacturer of the controller chip will usually have a spec like this:
https://docs.rs-online.com/421e/0900766b80d8d023.pdf
But as a general rule, the manufacturers are not good at writing specs, not to the standards we expect in the US or in the EU. You sort of need to know what to look for. The relevant sections are 8.3.2, which describes the pixel format; and 9, which has the command table - albeit there's some specialized jargon in there. For example, the "drive this many rows" setting is called "set multiplex ratio" - whyyy.
Newhaven has its own spec for the entire module, with some sample code, but the code in their docs is often garbled and poorly-explained:
https://newhavendisplay.com/content/specs/NHD-1.91-176176UBC3.pdf (see "Example Initialization Sequence")
It helps if you've done it before, or have some introductory text that explains the sequence for a similar display.
It's also helpful if there's some demo code somewhere on Github, although it's really hit-and-miss. Most of these are devoid of comments and go through a lot of unnecessary steps, often for some platform you're not familiar with. At best, it's some Arduino cruft...
Anyway - the good news is that there is a fairly small number of dominant controllers, and that by now, they're mostly sane. In the early days, you had some weird memory layouts, etc.
If Your project includes a graphic display, there is one problematic issue worth addressing. The graphic displays usually come without their RAM memories, so the actual frame buffer is being held by MCU in its RAM and is being written to the display either by using I2C or SPI interface.
In other words, it requires the developer of preserving bulk region of memory for a frame buffer, the higher he resolution, the higher of RAM is needed.
While designing a circuit for fun it doesn't make a difference whether You're going to use an MCU based on ARM core with plenty of RAM/Flash, IOs and packed with features or not. On contrary, working on a commercial projects requires selecting the MCU that is going to be cost effective at first, allow to fit the code for Your design and have a little space left for a few extra features You want to add into the coding process. If Your design is going to be sold in numbers, the $10 difference in between Atmega328 and Atmega SAM4 goes in numbers as well. And that is highly related to the competition with Asian market You have already mentioned. And the companies asking for the electronic design will evaluate the project based on target price, not the MCU features and computing power.
A while ago I've been asked for the fertilizer mixer controller, that I've initially decided to fit into Atmega328 (cost effective) that will be interfaced to SSD1306 (I love OLEDs for their crystal clear and wide angle view) and started coding: startup (integrity check on RTC, recipes, timetable - yes, EEPROMs sometimes loose their data), main window, several setup windows: date & time, recipes, timetable, diagnostics, PID params, probe calibration, alarms and factory reset. It barely fit into the MCU (I had to quit the idea of adding MODBUS). But in this case the display is just a terminal: set&forget.
When elegance of a design comes to play, it is reasonable to explore more advanced (and pricey) MCUs, that allow using a dedicated graphic libraries, like LVGL - they can provide a lightweight graphic windows with buttons and such, which is more than drawing lines, circles and rectangles in a frame buffer.
My mentioned project is somewhere in between those two. I've developed a dynamically allocated windows system, but in a text mode. And yes, on that occasion I have used malloc() condemned by many. And I love it!