Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite modm:ui:graphic #660

Closed
TomSaw opened this issue Jul 13, 2021 · 12 comments
Closed

Rewrite modm:ui:graphic #660

TomSaw opened this issue Jul 13, 2021 · 12 comments

Comments

@TomSaw
Copy link
Contributor

TomSaw commented Jul 13, 2021

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

VID_20210713_211743.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.

@TomSaw TomSaw changed the title Rewrite GraphicDisplay Rewrite modm:ui:display Jul 19, 2021
@TomSaw
Copy link
Contributor Author

TomSaw commented Jul 20, 2021

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

TouchGFX

@rleh
Copy link
Member

rleh commented Jul 20, 2021

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.

@chris-durand
Copy link
Member

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.

@TomSaw
Copy link
Contributor Author

TomSaw commented Jul 20, 2021

Ok, at least it's a good resource. Their explanations are very nice to read.

@TomSaw
Copy link
Contributor Author

TomSaw commented Jul 22, 2021

Finally, my Workspace 🧮 and Neurons 🧠 are ready to get known to uPainter 🎨

  • I like the extra classes for geometries `class Line, class Rectangle, class Circle, class Ellipse'. Gonna migrate that too.

Questions @salkinium:

  • B: What's the current solution for fixed-point-arithmetics if there's any? CMSIS?

@TomSaw
Copy link
Contributor Author

TomSaw commented Jul 30, 2021

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.

@salkinium
Copy link
Member

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).

@TomSaw
Copy link
Contributor Author

TomSaw commented Jul 30, 2021

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?

@salkinium
Copy link
Member

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.

@TomSaw
Copy link
Contributor Author

TomSaw commented Jul 31, 2021

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 !

@TomSaw
Copy link
Contributor Author

TomSaw commented Aug 12, 2021

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?

@salkinium
Copy link
Member

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€).

@TomSaw TomSaw changed the title Rewrite modm:ui:display Rewrite modm:ui:graphic Sep 15, 2021
@modm-io modm-io locked and limited conversation to collaborators Sep 29, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Development

No branches or pull requests

4 participants