Suggestions for optimizing LCD driver?

OpenMV Products
#1

Hi, I’m doing a project that need a display. The LCD library work well but the SPI transmission takes 28ms. And that reduced the frame rate significantly.

I think it may be worthwhile to optimize the py_lcd. If I can successfully do it, I’ll do a pull-request for sure. I think it will be nice to have rotation parameters inside py_lcd, so no need for another fb to do the rotation. Also, there should be another DMA write function, so the main code can continue while LCD is being written.

My question is, what is the best way to debug openMV firmware? I think I need to use logic analyzer to measure timing, and some method to do print to check variables. Is there any resources about that? This is the first time I do this level of modification to openMV firmware.

Should I just use HAL functions to manipulate IO to generate debug signal? What is the best way to print something? I see there is a SWO pin on openMV4 but I would prefer testing on openMV3 as the complication seems faster. Also, is there any tutorial about understanding micropython data structure?

Thanks

#2

Hi, printf() works in the IDE. Basically, you add printf() to your code and then compile the firmware. Then use the IDE to load the firmware binary.

Alternatively, you can use gdb and a swd device to load firmware and do low level debugging. However, the above option I mentioned can be done without any special tools.

As for the LCD driver, I’m working on a new bilinear/bicubic scaling pipeline with alpha blending for our new OpenMV Cam Pure Thermal project. The new pipeline will be used to add scaling to all methods in our firmware along with supporting generic pixel remapping to allow for smooth scaling support with lens correction and perspective warping (i.e. rotation, shearing, etc.) I will also be adding HDMI output support and I’ll probably improve the current driver more too. Also, I plan to add double buffering to the display driver which will decouple image capture from LCD output. Anyway, a lot of firmware fixes are coming down the pipe to fix these issues for our new product. However, when they will land one after another in the next 3 months.

If you need all these things done before then please go ahead and make the changes. However, don’t worry about doing a PR as we’ll have something really well thought out coming soon.

Also, is there any tutorial about understanding micropython data structure?

Nope, gotta read the code.

#3

Thanks! I’m wondering where will the printf goes? Does it goes from CDC or a uart port?
And thanks for the great news about the new LCD driver. I’m wondering if there will be DMA implemented? That is the most important feature for my application.

#4

printf() goes over the CDC and appears in the IDE serial terminal.

DMA for the LCD shield already works. However, the processor blocks until it’s all transferred.

However, that really isn’t the issue. The issue is that we have to pre-pare each line for sending to the display. As such, don’t expect the LCD shield to ever best fast.

For the OpenMV Cam Pure Thermal board we are about to release we are getting the hardware LCD driver on the STM32 working which refreshes an LCD automatically without the processor and using SPI.

…

That said… on the H7 plus we do have a lot of RAM. It would be possible to redo the driver to have a timer callback that flushed a cached frame buffer to the screen instead of the frame buffer directly. Then the screen would just be running all the time. I’ll think about doing this for the LCD shield.