plotters icon indicating copy to clipboard operation
plotters copied to clipboard

[Feature Request] no_std support for bare-metal embedded devices

Open cguentherTUChemnitz opened this issue 2 years ago • 7 comments

plotters already nicely integrates with slint, as visible in this example: https://slint-ui.com/releases/1.0.0/demos/plotter/

But one big selling-point of slint is to able to handle even embedded devices with very restricted memory setups, like STM-32 boards (300kb ram, 1mb flash). One nice example show-case is the on their web-page https://slint-ui.com/ running a printer management ui on STM32H7.

It would be great in my eyes if we can get the already great plotters capabilities even on those small devices, via the existing slint integration. Are there any plans to provide a feature flag setup for plotters to run in an no_std environment? Is this conceptually possible, given the current dependency setup?

best, Christian

cguentherTUChemnitz avatar Apr 06 '23 11:04 cguentherTUChemnitz

Greetings from Augsburg :)

Plotters is barely maintained at the moment. I'm actually the most active contributor even tough I just review incoming PRs.

I'd be happy to merge no_std support, but I don't have time to actively help you with the development. Note that the development version is on the "next-release-devel" branch.

AaronErhardt avatar Apr 06 '23 12:04 AaronErhardt

I'd also love embedded-graphics compatibility. That'd be so cool. Shouldn't be too hard to accomplish, from my first impressions.

EDIT: Never mind, I think it's quite a bit harder than I realized.

Finomnis avatar Jan 14 '24 13:01 Finomnis

@AaronErhardt Why is next-release-devel 102 commits behind master? What's the current workflow right now?

Finomnis avatar Jan 14 '24 13:01 Finomnis

@AaronErhardt Why is next-release-devel 102 commits behind master? What's the current workflow right now?

The reality is that nobody has time to manage the branches, so all fixes and non-breaking changes end up in master and the rest goes to next-release-devel. I wish I had more time for plotters, but I currently can't do more than occasional reviews and merges. If someone rebased next-release-devel on master I would be more than happy to merge it.

AaronErhardt avatar Jan 21 '24 20:01 AaronErhardt

From what I see, most of the std:: uses could simply be changed to core::. Not sure about the places where a Vec is used, but that might be replacable by a reference/slice. Any other usages of difficult-to-replace std uses I missed? @cguentherTUChemnitz did you look into this more deeply?

JuliDi avatar Feb 04 '24 15:02 JuliDi

From what I see, most of the std:: uses could simply be changed to core::. Not sure about the places where a Vec is used, but that might be replacable by a reference/slice. Any other usages of difficult-to-replace std uses I missed? @cguentherTUChemnitz did you look into this more deeply?

There are a bunch of Arcs for memory management, those are hard to change

Finomnis avatar Feb 04 '24 16:02 Finomnis

Hmm true, that requires at least alloc. Though searching for std::sync::Arc yields only 2 results. See https://github.com/search?q=repo%3Aplotters-rs%2Fplotters+std%3A%3Async%3A%3AArc&type=code Maybe that's managable? I mean it's only used for some chart state, that might not be necessary for no_std environments. (I have close to zero knowledge about the inner workings of plotters yet, so this might still have a huge impact)

JuliDi avatar Feb 04 '24 16:02 JuliDi