Add support for Numworks

[DSchndr]

Could support for the Numworks rpi Hack be added?

With zardams spifb kernel module the framerate suffers a lot, there is tearing and also wasted cpu resources because of fbcp.

[juj]

That looks like a cool project, Doom in a calculator is certainly something :) Unfortunately I can not work on this, but perhaps someone may be intrigued to contribute support for it.

[DSchndr]

Well i could maybe do it :) How should an display be added to this project?

I think that it should be fairly easy to implement this "dumb display", because you just need to push the frames over spi without initialisation and all the other fun stuff.

[juj]

If you look at the commit history, you can find some standalone commits that add support for different displays. Following those can show the pattern for adding a new one.

E.g. see commits that added support for ST7735S, ST7789VW, KeDei v6.3 (although this one can be a bit messy), ILI9486L, ST7789.

In summary the path is to add a config variable to CMakeLists.txt, that adds a build #define, which routes to #include a display specific file that has the init commands if any are needed, and then a display specific header file configures the particular aspects of the display in question. (e.g. bus width, display pixel resolution, pixel format, SPI active high or low)

[DSchndr]

I've made somewhat of an progress, but there is only garbage on the display :P Looks like I've missed out on something and the st7789v gets only shit from the stm32 in the calc.

[juj]

It seems to be getting a deterministic repeating pattern, with no color data. I wonder if it might be interpreting the row/column address set commands as pixel data, filling the screen with those command bytes misinterpreted as pixel data. Try double checking the command numbers, 0x2a, 0x2b and 0x2c are the values that are used on many displays - perhaps they need to change. Also try disabling DMA, and also can try disabling the per pixel diff altogether via https://github.com/juj/fbcp-ili9341/blob/ccebad5362623c435dcb5be11cc891f246ec5c50/config.h#L111 That should send full frame updates, in case the row/column address commands have something off.

[DSchndr]

It looks like it is getting some kind of data, but still far from an correct frame. Disableing DMA and playing around with some options didn't really change much. Command Numbers should be correct, because they are from the st7789v datasheet.

#ifdef NUMWORKS

// Data specific to the Numworks (ST7789V) Display

#define DISPLAY_SET_CURSOR_X 0x2A 
#define DISPLAY_SET_CURSOR_Y 0x2B
#define DISPLAY_WRITE_PIXELS 0x2C

#define DISPLAY_NATIVE_WIDTH 320
#define DISPLAY_NATIVE_HEIGHT 240

#define DISPLAY_NATIVE_COVERED_LEFT_SIDE 2
#define DISPLAY_NATIVE_COVERED_TOP_SIDE 1

//those arent really needed
#define GPIO_TFT_DATA_CONTROL 25
#define GPIO_TFT_RESET_PIN 15
#define GPIO_TFT_BACKLIGHT 18

//#define MUST_SEND_FULL_CURSOR_WINDOW
#define DISPLAY_SPI_BUS_IS_16BITS_WIDE //"destination data width (16 bits)"
#define SPI_3WIRE_PROTOCOL
//#define SPI_16BIT_COMMANDS
#define UPDATE_FRAMES_WITHOUT_DIFFING 

/* DISPLAY_NEEDS_CHIP_SELECT_SIGNAL needed because of:
"when CS goes low, it activates the software chip select of the SPI controller, and then it triggers the configuration of the window in the display controller.
when CS goes high, it disactivates the software chip select of the SPI controller. Any data received on the SPI will be discarded."
*/
/* commented out because 
#ifdef NUMWORKS
  SET_GPIO_MODE(GPIO_SPI0_CE0, 0x01);
  CLEAR_GPIO(GPIO_SPI0_CE0); // set cs low
#endif
in initspi() in spi.cpp */
//#define DISPLAY_NEEDS_CHIP_SELECT_SIGNAL

#define InitSPIDisplay InitNUMWORKS

void InitNUMWORKS(void);

#endif`

[juj]

Closing out old issues, curious if this ever worked in the end?