Palette based dithering

[mariusandra]

Get ready to support 3-color, 4-color and 7-color dithering.

This is a work in progress. The dithering is implemented, just need to hook it up to the drivers

3-color (black, white, red)

4-color (black, white, red, yellow):

7-color:

[ZarekParker]

I have a 7-color waveshare 7.5" and would be happy to help test this if needed - I've been trying to figure out how to get my display working

[mariusandra]

Hey @ZarekParker , thanks for this!

I only have B/W waveshare frames myself. I do have one with B/W and Red, but it stopped working for some reason. Thus I'm very happy to accept your offer to test it out. Waveshare did send me one 4-inch 7-color display for testing, but it's still in transit and should arrive any day now.

Will you be able to run this branch locally, or would you need a new docker image?
This doc describes what you need to get the controller running locally.

I'd like to test a bit before merging this in... hopefully even get my 3-color frame working somehow. So any help is very appreciated. I just managed to update the drivers for the frames I don't have to use the new dithering, but they may or may not work.

[mariusandra]

I'll merge this in and do any fixes in followups. Very curious to hear if this works, and/or what errors you get. A new docker latest tag should be out soon.

[ZarekParker]

@mariusandra I pulled the latest docker. I'm able to build locally if that helps. I'm running a raspberry pi 3b, lite OS 32-bit. I have Waveshare 7.3" (F) 800x480 7 Color (not implemented) chosen.

2024-01-17 03:07:40

• No cross compilation. Generating source code for compilation on frame.
  2024-01-17 03:07:40
  $ cd /tmp/tmp5ti1ifw6/frameos && nimble assets -y && nim compile --os:linux --cpu:arm64 --compileOnly --genScript --nimcache:/tmp/tmp5ti1ifw6/build_itwueqvyrfbk src/frameos.nim 2>&1
  2024-01-17 03:07:41
  Executing task assets in /tmp/tmp5ti1ifw6/frameos/frameos.nimble
  2024-01-17 03:07:41
  assets/web/index.html ... ok
  2024-01-17 03:07:41
  assets/fonts/Ubuntu-Regular_1.ttf ... ok
  2024-01-17 03:07:42
  Hint: used config file '/opt/nim/config/nim.cfg' [Conf]
  2024-01-17 03:07:42
  Hint: used config file '/opt/nim/config/config.nims' [Conf]
  2024-01-17 03:07:42
  Hint: used config file '/tmp/tmp5ti1ifw6/frameos/nim.cfg' [Conf]
  2024-01-17 03:07:42
  Hint: used config file '/tmp/tmp5ti1ifw6/frameos/config.nims' [Conf]
  2024-01-17 03:07:45
  .........................................................................................................................................................................................................................................................................
  2024-01-17 03:07:45
  /tmp/tmp5ti1ifw6/frameos/src/drivers/waveshare/driver.nim(21, 35) Error: type mismatch
  2024-01-17 03:07:45
  Expression: waveshareDisplay.EPD_7IN3F_Clear()
  2024-01-17 03:07:45
  2024-01-17 03:07:45
  Expected one of (first mismatch at [position]):
  2024-01-17 03:07:45
  [1] proc EPD_7IN3F_Clear(color: UBYTE)
  2024-01-17 03:07:45
  2024-01-17 03:07:45
  The command exited with status 1
  2024-01-17 03:07:45
  Failed to generate frameos sources
  2024-01-17 03:07:45
  SSH connection closed
  2024-01-17 03:08:52
• Generating scene: default
  2024-01-17 03:08:52
• Generating app: f7fea675-979d-479b-bb8f-ce2101b6c9cf (unsplash)

[mariusandra]

I just submitted a patch that hopefully fixes it. So please try again once the new image is available.

[ZarekParker]

Hmm, I pulled the latest docker and tried. That didn't work so I built locally to make sure, and still seem to be getting the same error:

2024-01-17 14:16:48
Hint: used config file '/tmp/tmpf3i551u2/frameos/config.nims' [Conf]
2024-01-17 14:16:52
.........................................................................................................................................................................................................................................................................
2024-01-17 14:16:52
/tmp/tmpf3i551u2/frameos/src/drivers/waveshare/driver.nim(21, 35) Error: type mismatch
2024-01-17 14:16:52
Expression: waveshareDisplay.EPD_7IN3F_Clear()
2024-01-17 14:16:52
2024-01-17 14:16:52
Expected one of (first mismatch at [position]):
2024-01-17 14:16:52
[1] proc EPD_7IN3F_Clear(color: UBYTE)
2024-01-17 14:16:52
2024-01-17 14:16:52
�[1m/tmp/nimble_35/githubcom_xmonadernimassets_0.2.4_d06724dd7b80fb470542ab932f3a94af78fe2eb1/src/nimassets.nim(3, 8) �[0m�[33mWarning: �[0muse the nimble packages malebolgia, taskpools or weave instead; threadpool is deprecated�[36m [Deprecated]�[0m�[0m
2024-01-17 14:16:52
The command exited with status 1
2024-01-17 14:16:52
Failed to generate frameos sources
2024-01-17 14:16:52
SSH connection closed

[mariusandra]

I pushed another change that could help with this.

[alexrudd2]

I can't quite tell; is this enabled for the Inky displays, or just the Waveshares? I have a red/back Inky and 7c3173c doesn't appear to do anything different.

Also, it looks like @ZarekParker is running a 32-bit OS, so I'm not sure nim compile --os:linux --cpu:arm64 is appropriate. I think uname -m will output arm7l for the 32bit chip.

frameos/backend/app/tasks/deploy_frame.py

Lines 62 to 63 in 8058198

	elif arch == "armv6l":
	cpu = "arm"

[ZarekParker]

uname -m does output arm71, happy to switch to 64-bit if needed. It got further:

2024-01-17 15:41:48

cd /srv/frameos/build && tar -xzf build_mfjyxwyutviq.tar.gz && rm build_mfjyxwyutviq.tar.gz
2024-01-17 15:41:48
cd /srv/frameos/build/build_mfjyxwyutviq && sh ./compile_frameos.sh
2024-01-17 15:41:54
[1/138] Compiling on device: DEV_Config.c
2024-01-17 15:41:54
[2/138] Compiling on device: EPD_7in3f.c
2024-01-17 15:41:55
[3/138] Compiling on device: lib/system/exceptions.nim.c
2024-01-17 15:41:55
In file included from @m..@s..@s..@s..@sopt@snim@slib@ssystem@sexceptions.nim.c:5:
2024-01-17 15:41:55
nimbase.h:264:35: error: static assertion failed: "Pointer size mismatch between Nim and C/C++ backend. You probably need to setup the backend compiler for target CPU."
2024-01-17 15:41:55
264 | #define NIM_STATIC_ASSERT(x, msg) _Static_assert((x), msg)
2024-01-17 15:41:55
| ^~~~~~~~~~~~~~
2024-01-17 15:41:55
nimbase.h:538:1: note: in expansion of macro ‘NIM_STATIC_ASSERT’
2024-01-17 15:41:55
538 | NIM_STATIC_ASSERT(sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof(NI)*8, "Pointer size mismatch between Nim and C/C++ backend. You probably need to setup the backend compiler for target CPU.");
2024-01-17 15:41:55
| ^~~~~~~~~~~~~~~~~
2024-01-17 15:41:56
Command exited with status 1
2024-01-17 15:41:56
SSH connection closed

[mariusandra]

Another fix. I wasn't able to run the code locally earlier (different computer), and made the previous changes here on Github without testing. I hope this version works now. I'll be able to run and test it in a few hours if it still fails. I should also get my waveshare 7-color frame soon (already in the country... so tomorrow?), and can then test even more.

@alexrudd2 this is only for the Waveshare drivers for now. Inky frames go through the inky python driver. The "inky impression" frames have their own built in dithering, but I don't know about the others. I'd like to remove the dependency on python altogether, but it's going to be a bit of work.

[mariusandra]

Also, it looks like @ZarekParker is running a 32-bit OS, so I'm not sure nim compile --os:linux --cpu:arm64 is appropriate. I think uname -m will output arm7l for the 32bit chip.

Interesting. I have a 32-bit raspberry pi zero w, which outputs armv6l for uname -m, and my 64bit pi zero w2 outputs aarch64. I guess that's why I missed it. Fixed now.

[ZarekParker]

Well good news: that most recent commit seems to have fixed the compiling and it got all the way through and seemed to have started.
Bad news: Nothing is showing on the display. I ran some waveshare demo code and verified that the display is connected and works

2024-01-17 17:04:39
Jan 17 10:04:39 frameos frameos[26772]: INFO Jester is making jokes at http://0.0.0.0:8787
2024-01-17 17:04:39
SSH connection closed
2024-01-17 17:04:40
driver:wavesharewidth=800height=480
2024-01-17 17:04:40
metricsstate="enabled"intervalMs=60000
2024-01-17 17:04:40
bootupconfig={"framePort":8787,"width":800,"height":480,"device":"waveshare.EPD_7in3f","interval":600,"metrics_interval":60,"scaling_mode":"cover","rotate":0,"background_color":"#ffffff"}
2024-01-17 17:04:40
http:startmessage="Starting web server"
2024-01-17 17:04:40
startRenderLoop
2024-01-17 17:04:40
renderwidth=800height=480
2024-01-17 17:04:40
metricsload=[0.85,0.55,0.35]cpuTemperature=57.996memoryUsage={"total":966750208,"available":838291456,"percentage":13.3,"used":62300160,"free":188682240,"active":283107328}cpuUsage=9.6
2024-01-17 17:04:41
startup
2024-01-17 17:04:42
startup
2024-01-17 17:04:44
startup

[mariusandra]

Ah, great that you got this far!

Looks like the frame is crashing on boot. I probably messed up something with the waveshare driver. I'll definitely get it fixed once my display arrives (this week?), but if you want to debug a bit further, the next step would be to SSH into the raspberry, and run

cd /srv/frameos/current
./frameos

... and see what extra errors are logged into the terminal. There might be a small stacktrace there that gives more clues.

[ZarekParker]

./frameos
//
Current environment: Raspbian
//
INFO Jester is making jokes at http://0.0.0.0:8787
fatal.nim(53) sysFatal
asyncfutures.nim(385) read
Error: unhandled exception: index 48000 not in 0 .. 47999 [IndexDefect]

[mariusandra]

So... good news. My display just arrived. I was able to fix the indexing bug and got the display rendering. I pushed it directly to main instead of making another PR. The bad news is that there's something still off, but we'll get there:

[ZarekParker]

Nice timing! With the latest docker I'm also able to get images to show up now, but like you it does seem a little off. Thanks for all the work getting it this far!

[mariusandra]

Great news, I got it working. See the next PR: #49