search

kkayal / bitlab

To extract a range of bits from a binary data source or to insert a range of bits into a binary data structure
MIT License
4 stars 0 forks source link

no_std support #1

Open wucke13 opened 3 years ago

wucke13 commented 3 years ago

Hi I would like to use this in a no_std environment. Is it possible to support this usecase as well?

kkayal commented 3 years ago

This idea appeals to me. I started playing with microcontrollers. However, I have no experiance in this area.

I use vectors. From the first 10 minutes of reading in the embedded rust book, it seems they need the stdandard library to work and implementing an alternative is not trivial?

Additionally, there is also a dependency to the num crate. I don't know if it can be be used in a no_std environment. I guess this needs some testing. If not, perhaps I can create a fork of bitlab for embedded systems which does not make use of the num crate.

These are just some initial thoughts. If you are experianced in embedded programming and can provide some sort of roadmap, I am all ears.

wucke13 commented 3 years ago

Hi, good to hear that!

Regarding num: A subset of the num features is no_std compatible. You can simply try whether your lib still compiles with default-features = false in num's section in the Cargo.toml. Maybe you then need to manually activate some no_std compatible features again, depending on what you use.

It is true, vectors require heap memory an therefore are not available ad-hoc in no_std. However, by including the alloc create and providing an allocator, vectors can work in no_std. Though it is advised not to use alloc if avoidable, because heap memory comes with quite some restrictions on embedded devices.

You might end up not needing vectors at all: no_std works nicely with iterators, so if it's possible to rewrite what now is based on vectors to be based off on iterators, that would be both an improvement in API IMHO as well as paving the way towards no_std. Last but not least, If I read withoutboats correctly, we will get Rust const_generics soon! That means we can abstract over the size of an array by a generic parameter. Maybe this could replace all current usage of Vectors as well?

kkayal commented 3 years ago

Thanks for the directions. Meanwhile I made my first steps into this direction, read quite a bit of documentation and realized that it will take long time to make it right.. At least for me.

It seems there is a strong dependency on the nightly rust tool chain. I failed to find a working "hello world" example incl unit testing using the stable tool chain. I found that a bit discouraging.

On the other hand, I start to think that web assembly is also an interesting target. It has similarities to no_std, but seems to be easier to achieve in compare to the world of embedded devices. This maybe a smaller intermediate step to achieve no_std support.

Anyhow, the most important thing that I honestly want to say is that it will take many months and you should not rely on my efforts if you need it for a professional project..

wucke13 commented 3 years ago

It seems there is a strong dependency on the nightly rust tool chain.

Why?

I failed to find a working "hello world" example incl unit testing using the stable tool chain.

That should not be an issue, you can use unit tests just like normal. Here is an example from a short yet excellently written crate which is pure no_std only and comes with unit tests.

On the other hand, I start to think that web assembly is also an interesting target. It has similarities to no_std, but seems to be easier to achieve in compare to the world of embedded devices. This maybe a smaller intermediate step to achieve no_std support.

That's probably right. Though, is there even work to be done for it? I would guess that your code works already in WASM.

Thank you for the heads-up. In the meantime, feel free to discuss any other questions and un-securities you have with regard to no_std, I'll do my best to help.