search

plotters-rs / plotters

A rust drawing library for high quality data plotting for both WASM and native, statically and realtimely 🦀 📈🚀
https://plotters-rs.github.io/home/
MIT License
3.67k stars 269 forks source link

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

Open cguentherTUChemnitz opened 1 year ago

cguentherTUChemnitz commented 1 year 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

AaronErhardt commented 1 year ago

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.

Finomnis commented 5 months ago

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 commented 5 months ago

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

AaronErhardt commented 5 months ago

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

JuliDi commented 4 months ago

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?

Finomnis commented 4 months ago

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

JuliDi commented 4 months ago

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)