Closed TomSaw closed 3 years ago
Found another promising library not yet mentioned in modms GUI-Issues nor uPainter-Docs. It also builds up on DMA2D and the docs contain some good introduction to graphics on MCUs under Basic-Concepts
If I remember correctly the TouchGFX license does not allow usage on non-ST devices and/or has expensive fees if used in commercial applications.
If I remember correctly the TouchGFX license does not allow usage on non-ST devices and/or has expensive fees if used in commercial applications.
It's free even for commercial applications but the license only permits use with devices manufactured by ST.
Ok, at least it's a good resource. Their explanations are very nice to read.
Finally, my Workspace 🧮 and Neurons 🧠are ready to get known to uPainter 🎨
Questions @salkinium:
First sub-PR for ILI9341 is out: #664 I've also PR-ed the whole code for reference #665 👉 Please correct me if there's a better practice for my situation of contributing this huge thing in chunks.
What's the current solution for fixed-point-arithmetics if there's any? CMSIS?
There is none. There's a fixed point class in uPainter, however, it's a little outdated and not as flexible. This seems to be the most promising: https://github.com/MikeLankamp/fpm
Please correct me if there's a better practice for my situation of contributing this huge thing in chunks.
Just make one big PR and partition your changes into separate commits, since we can review the changes by commits instead of by files too (see the tab Commits).
Just make one big PR and partition your changes into separate commits, since we can review the changes by commits instead of by files too (see the tab Commits).
So then all changes will be in one branch ? Makes it difficult to evolve the single changes, doesn't it?
So then all changes will be in one branch? Makes it difficult to evolve the single changes, doesn't it?
Yes, you group them by commits and use fixup commits and interactive rebase to apply patches on you branch. This is a very typical git workflow and helps you break down large order-dependent changes.
You can even collaborate like this, if you carefully synchronize the rebase and force-pushes. We've done this recently for our STM32H7 work.
Okay, thanks i'm going to learn and apply this. Please go for review of #665. I'll partition into commits later cause 'some' change requests are expected. It's more efficient doing the partitioning to the end of the workflow !
I'm researching a board with DMA2D + Touch-TFT (ILI9341) to get my hands on the serious accelerators.
I could grab a STM32F429 Discovery for small money but can't determine the type of the assemblied Display. Also the appropriate modm:board:disco-f429zi doesn't leave a note.
The're more Disco-boards with backpacked TFTs and weak technical details. How do you source the display-types for STM32-boards?
According to the User Manual, the F429 Disco has a TFT ILI9341 display. I would however recommend the F469 Disco with a MIPI-DSI panel with capacitive touch, even tough it's expensive (~50€).
Changed some lines of the Display-API to make graphics appear faster by a factor.
PR containing the whole, latest codebase for reference: #665
Here's a little preview, running on STM32F0 @48Mhz
https://user-images.githubusercontent.com/738535/125512287-f0789d28-b91d-4732-8b4b-c6905b9cad61.mp4
The Number is rendered into a single monochrome Buffer witch is then streamed to different displays. Only the area of the Buffer is affected. Notice the noizy bottom half of the OLEDs. The flickering squares on the ILI9341 comes from debugging code. Soo yes, just a preview ;) Details about the implementation, the benefits and more examples coming soon.