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

Question

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

Opened this issue 2 years ago · 7 comments

cguentherTUChemnitz commented 2 years ago

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

Answer 1 · 2023-04-06T12:41:05.000Z

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.

Answer 2 · 2024-01-14T13:10:55.000Z

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.

Answer 3 · 2024-01-14T13:13:16.000Z

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

Answer 4 · 2024-01-21T20:40:37.000Z

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

Answer 5 · 2024-02-04T15:23:14.000Z

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?

Answer 6 · 2024-02-04T16:09:56.000Z

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

Answer 7 · 2024-02-04T16:21:14.000Z

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)