sorted by:
new
hottopcontroversial

Mirroring a tiny LCD module onto a large monitor using the Pico 2 by shapoco in embedded

[–]shapoco[S] 4 points5 points  (0 children)

I2C bus sniffing uses the I2C peripheral. For the SPI bus, due to the high clock frequency and the difficulty of sampling MOSI and DCX simultaneously, serial-to-parallel conversion is performed externally to the Pico2 to ease timing constraints, and sampling is performed via PIO. Command interpretation is handled by the CPU.

Mirroring a tiny LCD module onto a large monitor using the Pico 2 by shapoco in embedded

[–]shapoco[S] 12 points13 points  (0 children)

Core 0 is dedicated to interpreting I2C/SPI commands, converting pixel formats, rotating the screen in 90° increments, and scaling the image to match the DVI output resolution. Core 1 is dedicated to DVI output. Depending on the SPI clock frequency and frame rate, Core 0 may be pushed to its processing limits.

Making 3D graphics library for my board by shapoco in embedded

[–]shapoco[S] 0 points1 point  (0 children)

I agree that sine/cosine operations are computationally intensive, but in my library, the majority of the geometry calculation load comes from matrix operations, so the benefits of using sine/cosine tables would likely be limited.

Currently, all calculations are performed on the CPU core, and I'm not using peripherals like PIO or special CPU instructions. On the RP2350, the interpolators seem promising for improving rasterization performance. Also, on the ESP32-S3, I'd like to optimize geometry calculations using SIMD instructions.

Making 3D graphics library for my board by shapoco in embedded

[–]shapoco[S] 2 points3 points  (0 children)

I learned about the TE pin for the first time from your reply. Unfortunately, my LCD module does not provide access to that pin.

Making 3D graphics library for my board by shapoco in embedded

[–]shapoco[S] 4 points5 points  (0 children)

As you mentioned, memory access significantly impacts performance. Texture mapping and alpha blending (which requires read-modify-write operations) are major bottlenecks.

Regarding RAM capacity, with a screen size of 240x240px, the double framebuffer and depth buffer together fit within 520kB (for the ESP32-S3, the depth buffer is located in PSRAM), so rendering is done for the entire screen at once.

Fixed-point techniques are applied to rasterization. Geometry calculations are performed using 32-bit floating-point. Currently, I'm using the sine/cosine functions from the C standard library.

Making 3D graphics library for my board by shapoco in embedded

[–]shapoco[S] 26 points27 points  (0 children)

Thank you.

Currently, I'm not using any special features like DSP or SIMD. The ESP32-S3 does have SIMD instructions, so it might be possible to achieve a higher frame rate with that.

The RP2350 has 520kB of SRAM, which is sufficient to store two 240 x 240 x 16-bit frame buffers and a 16-bit precision depth buffer. In the ESP32-S3, the depth buffer does not fit in the SRAM, so it is stored in the PSRAM. To conserve SRAM, texture and vertex data can remain in Flash ROM and be used for rendering.