Skip to content
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

How can dynamically sized Vec<T> be using on STM32? #335

Closed
johnthagen opened this issue Mar 19, 2019 · 13 comments
Closed

How can dynamically sized Vec<T> be using on STM32? #335

johnthagen opened this issue Mar 19, 2019 · 13 comments

Comments

@johnthagen
Copy link
Contributor

johnthagen commented Mar 19, 2019

Cross post from rust-lang/rfcs#2480 (comment)

When evaluating using Rust for an embedded project at work, not having dynamic containers was a big drawback at the time compared with C++11/14 where the gcc-arm-embedded toolchain had versions of std::string and std::vector<T>. (C++ has it's own set of drawbacks, like exception-based error handling APIs, but in this one, fundamental case, it had a leg up).

Is there a way (even it's nightly) to use Vec<T> on something like the STM32F3DISCOVERY? It was a hard sell to recommend Rust over C++ without being able to safely use the heap.

Edit: We used heapless in some tutorials but we wanted to have true heap access available like is available for C++11/14 and the gcc-arm-embedded toolchain.

@therealprof
Copy link
Contributor

@johnthagen johnthagen changed the title How can Vec<T> be using on STM32? How can dynamically resizable Vec<T> be using on STM32? Mar 19, 2019
@johnthagen
Copy link
Contributor Author

@therealprof Thanks, yeah I had seen heapless and I changed the title to be more clear that we'd like to actually use the heap for true dynamically sized containers. heapless requires a fixed size up front.

@johnthagen johnthagen changed the title How can dynamically resizable Vec<T> be using on STM32? How can dynamically sized Vec<T> be using on STM32? Mar 19, 2019
@therealprof
Copy link
Contributor

You can use alloc-cortex-m to create a heap and combine it with heapless.

@japaric
Copy link
Member

japaric commented Mar 19, 2019

@johnthagen what @therealprof said. The quickstart template has an example: https://github.com/rust-embedded/cortex-m-quickstart/blob/master/examples/allocator.rs

@japaric
Copy link
Member

japaric commented Mar 19, 2019

(you don't need to specifically use alloc-cortex-m; any global_allocator will do)

@johnthagen
Copy link
Contributor Author

johnthagen commented Mar 19, 2019

@japaric Is this mentioned in the Discovery Book? And if not, would you accept a PR to add it? I think this would be a really great addition!

@johnthagen
Copy link
Contributor Author

(For anyone else finding this issue in the future, the embedded book has some discussion on this as well.)

@therealprof
Copy link
Contributor

I think this would be more appropriate for the book and/or the embeddonomicon with a reference in the discovery book. Any contributions in that directions would certainly be welcome.

@jamesmunns
Copy link
Member

I think we should also note (last time I checked) that alloc-cortex-m requires nightly rust to operate.

@johnthagen
Copy link
Contributor Author

I think we should also note (last time I checked) that alloc-cortex-m requires nightly rust to operate.

Correct, this RFC is currently being discussed to potentially stabilize alloc: rust-lang/rfcs#2480

@johnthagen
Copy link
Contributor Author

alloc is on track to stabilize for Rust 1.36.0: rust-lang/rust#59675

@MarcoIeni
Copy link

So:

  • The answer to the question is to use the alloc crate.
  • This issue was opened in order to mention this fact in the discovery book.

I think that no action is required here anymore and this issue could be closed.

@jonas-schievink
Copy link
Contributor

Yup, closing then. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants